[WJ-1191] Implement fallback locales #1669
Conversation
Splits up each step into a separate function:
1. translate() - The overall call, takes a list of locales
and a message key, and returns the finished
translated string.
2. get_pattern_locales() - Goes through a list of locales and returns
first one which has a translation for this
path and attribute.
Important TODO item here: add support for
locale generalization.
3. get_pattern() - Get a particular bundle and pattern from a
locale, path, and attribute.
4. get_message() - Get a particular bundle and message from a
locale and a path.
Missed this one in my pass.
Codecov Report
@@ Coverage Diff @@
## develop #1669 +/- ##
===========================================
- Coverage 40.50% 40.45% -0.06%
===========================================
Files 340 341 +1
Lines 10678 10744 +66
===========================================
+ Hits 4325 4346 +21
- Misses 6353 6398 +45
*This pull request uses carry forward flags. Click here to find out more.
|
This reverts commit ba7ebef. This massively inflates the diff and these unused imports are not helpful for preludes and other mass-import context. We should find a way to suppress the warning in this case.
See comment for rationale.
|
How is the locale list ordered if some of the generic locales has already been specified in the list? {
"locales": [
"en-US",
"zh-hans",
"en"
],
...
}Does it still try to insert |
| langids.push(langid); | ||
| } | ||
| langids | ||
| }; |
There was a problem hiding this comment.
Forgot this was used here, I should move the helper function below out somewhere public so it can get imported and used here too.
Yes, for each locale it tries all the generic forms before going to the next one. So it would check |
|
thanks @Zokhoi |
This PR resolves WJ-1191, which calls for two different, but related features:
en_USlocale, you won't actually get anything, even though we have lots ofentranslations. This is because all those translations are forenspecifically, so because there are no exact matches which include the regionUS, the search fails. Instead, we try increasingly generic forms of the locale until we find a match, before moving onto the next fallback locale. The order we use is taken from below:Present locale, no fallback
Two fallback locales were specified, but neither was used.
{ "locales": [ "zh_Hans", "en_CA", "fr" ], "messages": { "about": {}, "navigated-to": { "path": "/start" } } }yielded
{ "about": "关于", "navigated-to": "导航至 /start" }Missing locale, generic locale
The first locale was not present, so a fallback was used. However this too was not present, so increasingly general variants of this locale (
en-US-valencia→en-US→en) were checked until it found a match.{ "locales": [ "hy", "en_US_valencia" ], "messages": { "about": {}, "navigated-to": { "path": "/start" } } }yielded
{ "about": "About", "navigated-to": "Navigated to /start" }Mixed case
Each message is fetched separately, so which fallback locale is used depends on the particular message. This way partial translations of a language are supported. (For testing purposes the Vietnamese translation for login strings were removed.)
{ "locales": [ "vi", "zh_Hans", "en" ], "messages": { "login": {}, "login.toast": {}, "logout": {}, "logout.toast": {} } }yielded
{ "login": "登入", "login.toast": "您已登入。", "logout": "Đăng xuất", "logout.toast": "Bạn đã được đăng xuất." }No locales specified
A new error,
NoLocaleSpecified(error code 4105) has been introduced for this case.