A batch of translation-forwarding bugs is being fixed in a separate PR — components that have a language prop but drop it before it reaches a child that translates its own labels. While auditing for those, a second class of the same problem turned up that cannot be fixed the same way.
These parents render a child that translates its own labels, but the parent has no language prop at all, so there is nothing to forward. The child therefore falls back to its en default and the label is permanently English no matter what language the consumer configured everywhere else. Fixing them means adding a new public prop, which makes each one a feat and a change to the public API rather than the one-line forward the other cases needed — hence this separate issue.
Where
Parent (no language prop) |
Child |
Label stuck in English |
limel-list — list-renderer.tsx:148 |
limel-list-item |
file-viewer.more-actions → "More…" |
limel-menu-list — menu-list-renderer.tsx:133 |
limel-list-item |
file-viewer.more-actions → "More…" |
limel-card — card.tsx:358 |
limel-action-bar |
action-bar → "Action bar" |
limel-info-tile — info-tile.tsx:284 |
limel-linear-progress |
loading → "Loading…", progress-bar → "Progress bar" |
limel-list-item is @private and is reached only through limel-list and limel-menu-list, so both of those need the prop for its action-menu label to ever be translated.
Impact
Every label above is an accessible name or a value text, so this is invisible on screen and only surfaces to screen-reader users — which is also why it has gone unnoticed. A Norwegian user navigating a list hears "More…" announced in English between otherwise Norwegian content.
Suggested fix
Add @Prop() public language: Languages = 'en' to limel-list, limel-menu-list, limel-card and limel-info-tile, matching the existing prop on the components that already have one, and forward it to the child in each render. Each component is its own feat commit, since each one independently widens the public API.
Worth considering at the same time: whether these components should keep gaining an identical prop one by one, or whether a shared default — a language on limel-config, or reading document.documentElement.lang the way limel-ai-avatar already does — is the better long-term answer. That question is worth settling before adding four more copies of the same prop.
A batch of translation-forwarding bugs is being fixed in a separate PR — components that have a
languageprop but drop it before it reaches a child that translates its own labels. While auditing for those, a second class of the same problem turned up that cannot be fixed the same way.These parents render a child that translates its own labels, but the parent has no
languageprop at all, so there is nothing to forward. The child therefore falls back to itsendefault and the label is permanently English no matter what language the consumer configured everywhere else. Fixing them means adding a new public prop, which makes each one afeatand a change to the public API rather than the one-line forward the other cases needed — hence this separate issue.Where
languageprop)limel-list— list-renderer.tsx:148limel-list-itemfile-viewer.more-actions→ "More…"limel-menu-list— menu-list-renderer.tsx:133limel-list-itemfile-viewer.more-actions→ "More…"limel-card— card.tsx:358limel-action-baraction-bar→ "Action bar"limel-info-tile— info-tile.tsx:284limel-linear-progressloading→ "Loading…",progress-bar→ "Progress bar"limel-list-itemis@privateand is reached only throughlimel-listandlimel-menu-list, so both of those need the prop for its action-menu label to ever be translated.Impact
Every label above is an accessible name or a value text, so this is invisible on screen and only surfaces to screen-reader users — which is also why it has gone unnoticed. A Norwegian user navigating a list hears "More…" announced in English between otherwise Norwegian content.
Suggested fix
Add
@Prop() public language: Languages = 'en'tolimel-list,limel-menu-list,limel-cardandlimel-info-tile, matching the existing prop on the components that already have one, and forward it to the child in each render. Each component is its ownfeatcommit, since each one independently widens the public API.Worth considering at the same time: whether these components should keep gaining an identical prop one by one, or whether a shared default — a language on
limel-config, or readingdocument.documentElement.langthe waylimel-ai-avataralready does — is the better long-term answer. That question is worth settling before adding four more copies of the same prop.