Repository navigation
FEATURE: Localization fallbacks (server-side) - #1771
kaihao-zhao wants to merge 2 commits into
Conversation
The FallbackLocaleList object tells I18n::Backend::Fallbacks what order the languages should be attempted in. Because of the translate_accelerator patch, the SiteSetting.default_locale is *not* guaranteed to be fully loaded after the server starts, so a call to ensure_loaded! is added after the locale is set for the current user. The declarations of config.i18n.fallbacks = true in the environment files were actually garbage, because the I18n.default_locale was SiteSetting.default_locale, so there was nothing to fall back to. *derp*
![unblocked-local-kaihao[bot]](https://avatars.githubusercontent.com/u/304571795?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found.
About Unblocked
Unblocked has been set up to automatically review your team's pull requests to identify genuine bugs and issues.
📖 Documentation — Learn more in our docs.
💬 Ask questions — Mention @unblocked-local-kaihao to request a review or summary, or ask follow-up questions.
👍 Give feedback — React to comments with 👍 or 👎 to help us improve.
⚙️ Customize — Adjust settings in your preferences.
|
|
||
| # Include fallbacks module | ||
| require 'i18n/backend/fallbacks' | ||
| I18n.backend.class.send(:include, I18n::Backend::Fallbacks) |
There was a problem hiding this comment.
The globally enabled fallback backend does not distinguish pluralization metadata from ordinary messages. For :bs_BA on a Russian-default site, the configured chain is [:bs_BA, :ru, :en], so a missing i18n.plural.rule lookup can inherit Russian metadata. plurals.rb defines no :bs_BA rule; its Russian rule returns :few for count 2, while the Bosnian too_many_links entry defines only :zero, :one, and :other. Keep plural-rule metadata locale-specific rather than inheriting an incompatible site-language rule.
| # user locale, site locale, english | ||
| # TODO - this can be extended to be per-language for a better user experience | ||
| # (e.g. fallback zh_TW to zh_CN / vice versa) | ||
| [locale, SiteSetting.default_locale.to_sym, :en].uniq.compact |
There was a problem hiding this comment.
Translations now depend on SiteSetting.default_locale, but the global LRU in translate_accelerator.rb still keys results only by translation key, current locale, and backend identity. Changing the site default does not clear that cache, and multisite installations share it. For example, email_log.notification_already_read is absent in Swedish but present in German and French: a Swedish lookup cached with a German site default will keep returning German after switching to a French default or another site. Include the effective fallback chain in the cache key so these contexts cannot reuse each other's results.
| SiteSetting.default_locale | ||
| end | ||
|
|
||
| I18n.fallbacks.ensure_loaded! |
There was a problem hiding this comment.
This is the only invocation of the fallback loader. Background jobs and rake tasks set I18n.locale without passing through this filter, while the translation accelerator still loads only the current locale and disables implicit translation-file loading. If English has not already been loaded, a Swedish-default worker cannot resolve English fallbacks—for example, PendingQueuedPostReminder sends queued_posts_reminder subject/body templates that are absent from Swedish, producing “translation missing” email text. Load the fallback chain at the translation boundary, using the effective requested locale, rather than relying solely on controller setup.
2 participants
See title.