Follow-up to #596, which added the Filipino locale, short code fil
Make sure Tagalog (tl) falls back correctly to Filipino (fil), and set up the locale fallback logic correctly in general.
Enable Firefox users to request Tagalog (tl) -- As far as I know, only Chromium/Chrome users can request Filipino (fil). And likewise, Chromium/Chrome users cannot request Tagalog (tl).
Should have no impact to end-users, other than enabling Tagalog (tl) to return the translations in our config/locales/fil folder. Thank you to various contributors for that translation, most recently @brynmrk.
Summary of Changes
Set I18n.default_locale explicitly to English (en) (was only implicitly English before, as part of the default behavior of Rails)
Add Tagalog (tl) to the list of supported locales for our app.
Instruct the app that when a user requests Tagalog (tl), it should fall back to our Filipino (fil) translations... (and if there are gaps in the Filipino (fil) translation, fall back only for those specific missing strings to the default locale, which is now English (en).
In all other cases, only the default locale, English (en), is currently set up for fallback. This should only occur if there are gaps in translations. For example, this would occur if we add new strings to the English locale without adding the new strings to each other locale.
Again, to clarify: Fallback to English would only occur for the specific strings we haven't gotten translations for yet.
Technical version of the above bullet point: Update production's value of config.i18n.fallbacks from true (which is deprecated) to a more complex arrangement.
Tagalog (tl) falls back to Filipino (fil) first, then the default locale (English (en))
Everything else falls back only to the default locale (English (en))
Note: Fallbacks are only needed when the requested locale is missing the requested string. For lookup of each individual string, Rails will preferentially use the first locale in the list.
The list looks like this: [requested locale], [if requested locale was, tl, then fil goes here], en
Checklist
[x] Tested changes work properly
[ ] Added Unit Tests
[ ] CI Passes
[ ] Deploys to Heroku on test Correctly (Maintainers will handle)
[ ] Added Documentation (Service and Code when required)
Context
fil
tl
) falls back correctly to Filipino (fil
), and set up the locale fallback logic correctly in general.tl
) -- As far as I know, only Chromium/Chrome users can request Filipino (fil
). And likewise, Chromium/Chrome users cannot request Tagalog (tl
).tl
) to return the translations in ourconfig/locales/fil
folder. Thank you to various contributors for that translation, most recently @brynmrk.Summary of Changes
I18n.default_locale
explicitly to English (en
) (was only implicitly English before, as part of the default behavior of Rails)tl
) to the list of supported locales for our app.tl
), it should fall back to our Filipino (fil
) translations... (and if there are gaps in the Filipino (fil
) translation, fall back only for those specific missing strings to the default locale, which is now English (en
).en
), is currently set up for fallback. This should only occur if there are gaps in translations. For example, this would occur if we add new strings to the English locale without adding the new strings to each other locale.config.i18n.fallbacks
fromtrue
(which is deprecated) to a more complex arrangement.tl
) falls back to Filipino (fil
) first, then the default locale (English (en
))en
))tl
, thenfil
goes here],en
Checklist
Screenshots
Before
After