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"}}`
24 lines
732 B
JavaScript
24 lines
732 B
JavaScript
import { registerUnbound } from "discourse-common/lib/helpers";
|
|
import deprecated from "discourse-common/lib/deprecated";
|
|
|
|
registerUnbound("theme-i18n", (themeId, key, params) => {
|
|
return I18n.t(`theme_translations.${themeId}.${key}`, params);
|
|
});
|
|
|
|
registerUnbound(
|
|
"theme-prefix",
|
|
(themeId, key) => `theme_translations.${themeId}.${key}`
|
|
);
|
|
|
|
registerUnbound("theme-setting", (themeId, key, hash) => {
|
|
if (hash.deprecated) {
|
|
deprecated(
|
|
"The `{{themeSetting.setting_name}}` syntax is deprecated. Use `{{theme-setting 'setting_name'}}` instead",
|
|
{ since: "v2.2.0.beta8", dropFrom: "v2.3.0" }
|
|
);
|
|
}
|
|
return Discourse.__container__
|
|
.lookup("service:theme-settings")
|
|
.getSetting(themeId, key);
|
|
});
|