81e4730037
- SUPPORTED_SUB_LANGUAGE_CODES[] that I introduced was pretty redundant when SUPPORTED_LANGUAGES[] already hold the information. The logic to ignore sub-languages (i.e. reduce the locale's "en-GB" to "en" is now located in getDefaultLanguage()). - SUPPORTED_BROWSER_LANGUAGES[] and SUPPORTED_LANGUAGES[] look so similar and hard to tell what the former is for at first glance. The functionality to map 'zh-CN' to 'zh-Hans' is now handled by resolveLanguageAlias(), which makes the intention clearer. This leaves us with a single list -- SUPPORTED_LANGUAGES[], whose key also tells us the desired language code to use. Also, clients now need to call `resolveLanguageAlias` to map any language code aliases, as they differ depending on how it is queried (e.g. `navigator.language` vs. `app.getLocal()` uses different standards). I think we no longer need to explicitly migrate existing user's 'zh-CN' into 'zh-Hans' because the rest of the system will always use the desired language code as long as 'resolveLanguageAlias' is called appropriately. e.g. the system uses `selectLanguage` and `selectLanguage` calls `resolveLanguageAlias`. |
||
---|---|---|
.. | ||
app.js | ||
blocked.js | ||
comments.js | ||
content.js | ||
file_info.js | ||
notifications.js | ||
publish.js | ||
reactions.js | ||
rewards.js | ||
search.js | ||
settings.js | ||
subscriptions.js | ||
sync.js | ||
tags.js | ||
user.js |