Styling and internationalization
This guide shows how to combine ComponentStyle and Internationalization manifests.
You will define a style, a translation block, and reference them from layouts conceptually.
1. Define a component style
Section titled “1. Define a component style”2. Define translations
Section titled “2. Define translations”The code must exactly equal the artefact’s spec.language (de or en - never a
regional tag like en-US), and with no namespace the content merges into the
_system bundle every component reads, overriding only the keys you set:
3. Use them in components
Section titled “3. Use them in components”Styles named _default apply to all components automatically. A named style like
corporateTheme is opted into per component via spec.selectedStyle:
The effective style merges the built-in _system defaults, then _default, then the
selected named style. See the ComponentStyle reference
for the full style structure and the list of supporting kinds; the
sales-dashboard sample
wires a named style the same way.
To theme a whole report at once, set selectedStyle on the ReportArtefact instead of
per component - pages and components inherit it as their default, and any element can
still select its own style (nearest ancestor wins). See
Style inheritance.
Translations apply globally by default. To scope a translation set to part of a
report, store it under a named spec.namespace and point pages or components at it
with i18nNamespace (inheritable, nearest ancestor wins). Text components can also
reference free-form keys with ${t('my.key')} in their value template. The full
token vocabulary and the bino add i18n --defaults scaffold are in the
Internationalization reference.
