[POC] feat(localization): add support for array translations and enhance msgList functionality#2689
[POC] feat(localization): add support for array translations and enhance msgList functionality#2689SebayK wants to merge 1 commit intoing-bank:masterfrom
Conversation
…gList functionality
|
There was a problem hiding this comment.
Pull request overview
Adds support for retrieving structured translation values (arrays/objects) and documents the existing “keys-as-array” fallback behavior in localize.msg.
Changes:
- Add
msgList()toLocalizeManagerto return raw translation values (string/array/object). - Adjust internal message resolution to return non-string translation values and to treat falsy-but-valid values differently.
- Extend docs and examples to cover key-array fallback and array translations, plus add demo translation data.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/ui/components/localize/src/LocalizeManager.js | Adds msgList() and adjusts message lookup/formatting behavior to allow non-string translation values. |
| packages/ui/components/localize/test/LocalizeManager.test.js | Adds unit tests covering msgList() for arrays/objects/strings, locale override, and key fallback. |
| docs/fundamentals/systems/localize/text.md | Documents key-array fallback mechanism and introduces msgList() usage examples. |
| docs/fundamentals/systems/localize/assets/en.js | Adds an example translated array (keys) used by docs/examples. |
| docs/fundamentals/systems/localize/assets/nl.js | Adds the Dutch equivalent example translated array (keys) used by docs/examples. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -269,10 +269,28 @@ export class LocalizeManager extends EventTarget { | |||
| if (!message) { | |||
There was a problem hiding this comment.
msg() now calls _getMessageForKeys() which can return non-string values like 0 or false, but the current if (!message) check treats those as “not found” and returns an empty string. Use an explicit missing-value check (e.g. message === undefined || message === null || message === '') so valid falsy translations still format correctly.
| if (!message) { | |
| if (message === undefined || message === null || message === '') { |
| (message, name) => | ||
| typeof message === 'object' && !Array.isArray(message) ? message[name] : message, |
There was a problem hiding this comment.
The path resolution in _getMessageForKey stops traversing once it hits an array (!Array.isArray(message)), which causes incorrect lookups: keys like ns:arr.0 can no longer resolve, and keys like ns:arr.nonexistent will incorrectly return the whole array instead of “not found”. Adjust the reducer to handle arrays (at least numeric indices) and to return undefined when a segment can’t be resolved.
| (message, name) => | |
| typeof message === 'object' && !Array.isArray(message) ? message[name] : message, | |
| (message, name) => { | |
| if (message == null) { | |
| return undefined; | |
| } | |
| if (Array.isArray(message)) { | |
| const index = Number(name); | |
| if (!Number.isInteger(index) || index < 0 || index >= message.length) { | |
| return undefined; | |
| } | |
| return message[index]; | |
| } | |
| if (typeof message === 'object') { | |
| // For plain objects, return the property value if it exists; otherwise, undefined | |
| return /** @type {any} */ (message)[name]; | |
| } | |
| // Primitive value encountered before path is fully resolved | |
| return undefined; | |
| }, |
| import { localize, formatNumber, formatDate, LocalizeMixin } from '@lion/ui/localize.js'; | ||
| import { getLocalizeManager } from '@lion/ui/localize-no-side-effects.js'; | ||
| import '@lion/ui/define-helpers/sb-locale-switcher.js'; |
There was a problem hiding this comment.
This doc snippet uses getLocalizeManager() even though it’s marked deprecated in the codebase (packages/ui/components/localize/src/getLocalizeManager.js). Consider using localize (or explicitly documenting why the deprecated API is preferred here) to avoid recommending deprecated usage.
| localizeManager.addData('en-GB', 'promo-banner', { | ||
| greeting: 'Special offer! Welcome, {name}!', | ||
| }); | ||
|
|
||
| localizeManager.addData('en-GB', 'defaults', { |
There was a problem hiding this comment.
In this example, localizeManager is referenced without showing how it’s created in the snippet (e.g. via getLocalizeManager()), and later the snippet calls localize.msg(...) instead. For clarity and copy/paste correctness, define localizeManager in the snippet or consistently use localize for both addData and msg.
| localizeManager.addData('en-GB', 'promo-banner', { | |
| greeting: 'Special offer! Welcome, {name}!', | |
| }); | |
| localizeManager.addData('en-GB', 'defaults', { | |
| localize.addData('en-GB', 'promo-banner', { | |
| greeting: 'Special offer! Welcome, {name}!', | |
| }); | |
| localize.addData('en-GB', 'defaults', { |
#2565