3 min. read
Custom Languages
Are you looking to provide a more personalized experience for some instances of your application? This is the way!
You may want to add a custom language that is derived from an existing language. It’s useful if you want to adapt some translations to another instance of your application, or to a specific customer.
The structure of a custom language is: existing language code
+ -
+ custom text
, where
custom text
can only contain alphanumeric characters and -
.
Examples: en-microsoft
or fr-BE-custom
.
Custom languages can be added like any other language.
Fallbacks work as expected. It means that if the en-microsoft.some_key
is missing,
then it will fallback to en.some_key
. So you only need to translate keys that should
be customized.
Note that fallbacks are chained, so en-US-custom
will fallback to en-US
that will
itself fallback to en
.
Just make sure to add config.i18n.fallbacks = true
to your config/application.rb
file.
You can find more information about this
here.
Using GetText syntax, it will only fallback to the source language. So either you create a fallback mechanism by yourself or you avoid fallbacking by translating everything in Translation.io for that custom language.
Custom languages can be added and used like any other language.
Custom languages can be added and used like any other language.
Language fallbacks will work as expected for any regional or custom
language. It means that if the en-GB
translation is missing,
then it will fallback to en
. So you only need to translate keys that
are different from the main language when you specialize a language.
Note that fallbacks are chained, so en-US-custom
will fallback to en-US
that will
fallback to en
.
You can find more information about Lingui fallback configuration here.
Custom languages can be added and used like any other language.