localized-strings
localized-strings copied to clipboard
Advanced locale fallback
If these features already exist, I didn't see them in the code and no documentation on it is available.
As seen below, the BCP-47 locale standard (as used by browsers) is multi-layered, as seen below:
Besides the language code, there are also parts for a script code, country code, variant, and extensions.
- zh (language code) — Chinese language
- Hans (script code) — written in simplified characters
- CN (country-code) — as used in China.
- bauddha (variant) — using a Buddhist Hybrid Sanskrit dialect
- u-nu-hanidec (extension) — using Han decimal numbers
The intent of these codes is SPECIFICITY. Each subsequent part of the code, if it is provided, conveys a specific extension on the language before it.
My suggestion is that this module implement the following procedure:
- Add a simple function to split locale codes into up to 5 parts as seen above.
- When localizing strings, first attempt to use the current language.
- If the current language does not contain the specified key, or the current language is not localized, strip the last part and try again.
- If no parts remain, throw an warning in the console and return the default language value.
Here is an example:
- The current language code is
zh-hans-cn-bauddha-u-nu-hani
. - The code makes a request to
localize-strings
with some localization data. - If the localization data contains a set of data for
zh-hans-cn-bauddha-u-nu-hani
, respond to that request as appropriate. - If the localization data does NOT contain data for
zh-hans-cn-bauddha-u-nu-hani
, or is missing that specific localization string, do not throw an error immediately. Instead, maybe throw a warning, then proceed to the next step. - Look in the localization data for
zh-hans-cn-bauddha
. If data isn't there... - Look in the localization data for
zh-hans-cn
. If data isn't there... - Look in the localization data for
zh-hans
. If data isn't there... - Look in the localization data for
zh
. If data isn't there... - Look in the localization data for the default locale.
The idea is that you could translate for 'zh', creating a baseline translation for all Chinese languages, then adding corrections for more specific locales, without having to copy and paste between languages and without having to make 'zh' your default locale.
HI @MasterEric, nice analysis... it seems feasible... it just needs to be coded...
I definitely vote for this. However, a challenge is working out which part is missing...
I'm in Australia, and our language code is en-AU
, which is '[language code]-[country code]' (we don't have alternate scripts).
There's definitely a fallback from en-AU
to en
- as we only differ in a few words from en
(also usually considered synonymous with en-US
)