880311dd4d
- Themes can supply translation files in a format like `/locales/{locale}.yml`. These files should be valid YAML, with a single top level key equal to the locale being defined. For now these can only be defined using the `discourse_theme` CLI, importing a `.tar.gz`, or from a GIT repository.
- Fallback is handled on a global level (if the locale is not defined in the theme), as well as on individual keys (if some keys are missing from the selected interface language).
- Administrators can override individual keys on a per-theme basis in the /admin/customize/themes user interface.
- Theme developers should access defined translations using the new theme prefix variables:
JavaScript: `I18n.t(themePrefix("my_translation_key"))`
Handlebars: `{{theme-i18n "my_translation_key"}}` or `{{i18n (theme-prefix "my_translation_key")}}`
- To design for backwards compatibility, theme developers can check for the presence of the `themePrefix` variable in JavaScript
- As part of this, the old `{{themeSetting.setting_name}}` syntax is deprecated in favour of `{{theme-setting "setting_name"}}`
|
||
|---|---|---|
| .. | ||
| about | ||
| admin/backups | ||
| application | ||
| badges | ||
| categories | ||
| clicks | ||
| common | ||
| default | ||
| embed | ||
| exceptions | ||
| finish_installation | ||
| groups | ||
| invites | ||
| layouts | ||
| list | ||
| metadata | ||
| offline | ||
| pending_flags_mailer | ||
| posts | ||
| qunit | ||
| robots_txt | ||
| safe_mode | ||
| search | ||
| session | ||
| static | ||
| tags | ||
| topics | ||
| user_api_keys | ||
| user_notifications | ||
| users | ||
| users_email | ||
| wizard | ||