Summary
Report blocks and dashboard widgets render a select field's option label from the object's hardcoded label, ignoring the locale bundle. The same field on a list view or a form renders the translated label correctly. The result is one screen showing a value two different ways.
Evidence
|
stored value |
analytics surface shows |
object label |
zh-CN bundle |
sales_channel |
domestic |
Domestic |
'Domestic' |
'国内' |
competitor_name |
cabot |
Cabot |
'Cabot' |
'卡博特' |
competitor_name |
orion |
Orion Engineered Carbons |
'Orion Engineered Carbons' |
'欧励隆' |
The decisive row is orion: the rendered string Orion Engineered Carbons bears no resemblance to the stored value orion, but matches the object's English label verbatim. So the analytics path does resolve the option label — it simply does not run it through the i18n bundle before display. (domestic → Domestic differs only in case, which is why this was initially and wrongly diagnosed as "the report groups by stored value".)
Same page, same records: the related list renders 卡博特 / 欧励隆 while the chart legend renders Cabot / Orion Engineered Carbons. The dashboard's global filter control also renders Sales Channel: untranslated.
Reproduce
- Declare a
select field with English option labels and provide zh-CN translations for those options.
- Put the field on a list view and as a dimension in a report block or dashboard widget.
- Load the console with browser locale
zh-CN. The list shows Chinese; the report/dashboard shows the object's English labels.
No authoring knob exists
DatasetDimension is exactly { name, label, field, type, dateGranularity }, and type is string | number | boolean | date | lookup — there is no select. The report config carries nothing for this either. So an app cannot opt into translated option labels on these surfaces.
Downstream impact
The only app-side fix is to write the option labels in Chinese in the object, which then renders Chinese for every locale — including the ones where the list side currently resolves correctly. That is a real loss, not a no-op, and it is the workaround we have been forced to take.
Environment
@objectstack/* protocol ^17.0.0-rc.1, console from @objectstack/console, driver-sql on SQLite, browser locale zh-CN.
Filed from a downstream app (hotcrm-heimao), tracked there as issue #55. Likely related to the view/report/dataset label translation gap we filed separately.
Summary
Report blocks and dashboard widgets render a
selectfield's option label from the object's hardcodedlabel, ignoring the locale bundle. The same field on a list view or a form renders the translated label correctly. The result is one screen showing a value two different ways.Evidence
labelsales_channeldomesticDomestic'Domestic''国内'competitor_namecabotCabot'Cabot''卡博特'competitor_nameorionOrion Engineered Carbons'Orion Engineered Carbons''欧励隆'The decisive row is
orion: the rendered stringOrion Engineered Carbonsbears no resemblance to the stored valueorion, but matches the object's Englishlabelverbatim. So the analytics path does resolve the option label — it simply does not run it through the i18n bundle before display. (domestic→Domesticdiffers only in case, which is why this was initially and wrongly diagnosed as "the report groups by stored value".)Same page, same records: the related list renders 卡博特 / 欧励隆 while the chart legend renders
Cabot/Orion Engineered Carbons. The dashboard's global filter control also rendersSales Channel:untranslated.Reproduce
selectfield with English option labels and provide zh-CN translations for those options.zh-CN. The list shows Chinese; the report/dashboard shows the object's English labels.No authoring knob exists
DatasetDimensionis exactly{ name, label, field, type, dateGranularity }, andtypeisstring | number | boolean | date | lookup— there is noselect. The report config carries nothing for this either. So an app cannot opt into translated option labels on these surfaces.Downstream impact
The only app-side fix is to write the option labels in Chinese in the object, which then renders Chinese for every locale — including the ones where the list side currently resolves correctly. That is a real loss, not a no-op, and it is the workaround we have been forced to take.
Environment
@objectstack/*protocol^17.0.0-rc.1, console from@objectstack/console, driver-sql on SQLite, browser localezh-CN.Filed from a downstream app (
hotcrm-heimao), tracked there as issue #55. Likely related to the view/report/dataset label translation gap we filed separately.