Commit Graph

5 Commits

Author SHA1 Message Date
David Taylor
f01ca1f22d FIX: Correctly process {{each}} in raw handlebars templates for themes 2019-02-07 10:08:43 -05:00
David Taylor
0b6be2cebc FIX: Correct deprecated theme settings in handlebars templates
Was overriding the incorrect `themeSetting.blah` syntax, instead of `themeSettings.blah`
2019-01-18 15:39:50 +00:00
David Taylor
24b59afe2a FIX: Wrap theme javascript inside IIFE to prevent using global namespace 2019-01-17 14:44:10 +00:00
David Taylor
5bfa661a87 FIX: Theme settings are referenced in JS by settings, not themeSetting 2019-01-17 12:24:21 +00:00
David Taylor
880311dd4d
FEATURE: Support for localized themes (#6848)
- 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"}}`
2019-01-17 11:46:11 +00:00