Summary
A handful of console chrome strings are hardcoded English literals rather than bundle lookups, so they stay English on every non-English console. They are small individually, but they sit on the two screens a user looks at most — the list view and the create/edit dialog — and there is nothing an app can author to change them.
Evidence
Fresh database, @objectstack/console 17.0.0-rc.1, browser locale zh-CN, admin user, every app-owned label correctly Chinese. Harvested by walking the DOM and keeping text nodes that contain Latin letters and no CJK, with getBoundingClientRect() used to separate visible text from screen-reader-only text:
Visible
| string |
where |
Grid |
list-view mode switcher |
Gallery |
list-view mode switcher |
Avg: 39% |
list footer aggregate, on a percent column |
Sum: 119,200 |
list footer aggregate, on a number column |
The aggregate footer is the interesting one: the number is formatted, but the prefix is a hardcoded Avg: / Sum: . The aggregate kind is already known to the renderer, so this is a bundle lookup away.
Screen-reader-only (still worth fixing — it is what assistive tech announces)
| string |
where |
Complete the form fields, then submit or cancel. |
plugin-form modal + drawer, when the form declares no description |
Close |
dialog close button sr-only label |
For the record, the form-dialog string is not visible — we verified it is clipped (sr-only), correcting an earlier assumption on our side that it was a visible subtitle. It is emitted as:
e.description
? <Description>{e.description}</Description>
: <Description className="sr-only">Complete the form fields, then submit or cancel.</Description>so an app can only displace it by authoring a description, which makes a visible subtitle appear on every dialog. Adding visible UI to every form in order to remove an invisible untranslated string is not a trade an app should have to make — the fallback should come from the bundle.
Why an app cannot work around any of these
None of them corresponds to authorable metadata. They are not object labels, field labels, view labels or action labels — there is no key in TranslationData that reaches them. The console's own bundle already ships zh-CN, ja-JP, es-ES, de, fr, pt, ru, ko and ar and translates hundreds of neighbouring strings (detail.highlightFields → 「关键字段」, detail.sortBy → 「排序」, and so on), so these are omissions from an otherwise complete bundle rather than a missing capability.
Suggested fix
Move all five through the existing console bundle:
- the view-mode switcher labels,
- the aggregate-footer prefixes (keyed by aggregate kind, so
Avg / Sum / Min / Max / Count all land),
- the form dialog's
sr-only description fallback,
- the dialog close button's
sr-only label.
Filed from a downstream app (hotcrm-heimao), tracked there as issue #60.
Summary
A handful of console chrome strings are hardcoded English literals rather than bundle lookups, so they stay English on every non-English console. They are small individually, but they sit on the two screens a user looks at most — the list view and the create/edit dialog — and there is nothing an app can author to change them.
Evidence
Fresh database,
@objectstack/console17.0.0-rc.1, browser localezh-CN, admin user, every app-owned label correctly Chinese. Harvested by walking the DOM and keeping text nodes that contain Latin letters and no CJK, withgetBoundingClientRect()used to separate visible text from screen-reader-only text:Visible
GridGalleryAvg: 39%percentcolumnSum: 119,200numbercolumnThe aggregate footer is the interesting one: the number is formatted, but the prefix is a hardcoded
Avg:/Sum:. The aggregate kind is already known to the renderer, so this is a bundle lookup away.Screen-reader-only (still worth fixing — it is what assistive tech announces)
Complete the form fields, then submit or cancel.plugin-formmodal + drawer, when the form declares nodescriptionClosesr-onlylabelFor the record, the form-dialog string is not visible — we verified it is clipped (
sr-only), correcting an earlier assumption on our side that it was a visible subtitle. It is emitted as:so an app can only displace it by authoring a
description, which makes a visible subtitle appear on every dialog. Adding visible UI to every form in order to remove an invisible untranslated string is not a trade an app should have to make — the fallback should come from the bundle.Why an app cannot work around any of these
None of them corresponds to authorable metadata. They are not object labels, field labels, view labels or action labels — there is no key in
TranslationDatathat reaches them. The console's own bundle already ships zh-CN, ja-JP, es-ES, de, fr, pt, ru, ko and ar and translates hundreds of neighbouring strings (detail.highlightFields→ 「关键字段」,detail.sortBy→ 「排序」, and so on), so these are omissions from an otherwise complete bundle rather than a missing capability.Suggested fix
Move all five through the existing console bundle:
Avg/Sum/Min/Max/Countall land),sr-onlydescription fallback,sr-onlylabel.Filed from a downstream app (
hotcrm-heimao), tracked there as issue #60.