Enhance locale fallback mechanism#104
Conversation
|
|
|
@cwtuan Many products of our company are using the framework to process i18n messages, and the current locale fallback mechanism does not comply with the globalization standard, could you help to process this PR? |
|
I wondering why the key defined in a locale file but not defined in another locale file? |
|
@cwtuan During product development lifecycle, we should not be waiting for all of the translation for all locales are ready, and then release the product. So it is quite possible that the keys are not consistent for all locales. In this case, we want the locale fallback can take local user’s language preference into consideration. For example, if a product does not provide translation service for Traditional Chinese, but the translation for Simplified Chinese and English are ready, in this case, the product should provide Simplified Chinese GUI to Taiwan or Hong Kong users. Or even the Simplified Chinese not provided, the product should display English for them, rather than other foreign languages. |
|
@cwtuan any other advice to this PR? |
| escapeHtml: true, // disable escape html in variable mode | ||
| commonLocaleDataUrls: COMMON_LOCALE_DATA_URLS, | ||
| fallbackLocale: null, // Locale to use if a key is not found in the current locale | ||
| fallbackLocale: null, // Locales to use if a key is not found in the current locale, such as 'zh-CN;en' will use the key in locale 'zh-CN', if the specific key not exist in 'zh-CN', will fallback to 'en' |
There was a problem hiding this comment.
Should we add another parameters fallbackLocales with type of string[]? And make the original fallbackLocale deprecated.
There was a problem hiding this comment.
Hi @cwtuan
Thanks a lot for your great advice. Here attached the modification according to your suggestion, please have a kind review again.
…ud globalization standart.
|
bump |
| escapeHtml: true, // disable escape html in variable mode | ||
| commonLocaleDataUrls: COMMON_LOCALE_DATA_URLS, | ||
| fallbackLocale: null, // Locale to use if a key is not found in the current locale | ||
| fallbackLocale: '', /** @deprecated Locale to use if a key is not found in the current locale */ |
There was a problem hiding this comment.
I would suggest not to deprecate this option. It seems that your use case is very specific and this config would require changes for an otherwise stable feature.
A suggestion: Your case could also be handled by using a comma separated fallbackLocale sequence like: 'zh-CN,en-US' which would require some extra effort for your case, but would keep the config simple for most users.
5 participants
The preferred fallback locale should depend on the current locale, different locale maybe have different preferred fallback locale. For example, for Traditional Chinese (zh-TW), the preferred fallback locale should be Simplified Chinese (zh-CN), if the key does not exist in Simplified Chinese, it will fallback to English (en-US). In this case, the fallbackLocale can be set to
zh-CN; en-US.