Handle alternate locale names, long locale names #67
Conversation
| 'zh-cn': 'zh-Hans', | ||
| 'zh-hk': 'zh-Hant', | ||
| 'zh-tw': 'zh-Hant', |
There was a problem hiding this comment.
Not sure how common it is, but zh-SG and zh-MO normally map to zh-Hans and zh-Hant, respectively, based on official status.
index.js
Outdated
| return languageCode; | ||
| if (language.indexOf('-') > -1) { | ||
| // reduce longer locales (en-US, zh-Hant-TW) to shorter forms | ||
| return browserLanguage(supportedLanguages, language.slice(0, language.lastIndexOf('-'))); |
There was a problem hiding this comment.
This works, though reduce() would be more succinct, or just a for loop incrementing the end of the range of parts.join('-') to look up.
There was a problem hiding this comment.
I changed these to while loops and added tests for "en-US" -> "en" and "zh-HK" to "zh-Hant"
MapBox page showing name_zh-Hant is correct label: https://docs.mapbox.com/data/tilesets/reference/mapbox-streets-v8/
index.js
Outdated
| } | ||
| if (supportedLanguages.indexOf(languageCode) > -1) { | ||
| return languageCode; | ||
| function browserLanguage(supportedLanguages, language) { |
There was a problem hiding this comment.
This function isn’t recursive anymore, so nothing ever passes in language anymore. language can go back to being a local constant.
2 participants
As described in #66 , there are multiple ways to write Chinese-language locales and they are getting reduced to
zhbysetLanguageandbrowserLanguagefunctionsMy proposal is:
ALT_LOCALES, locales such aszh-HKwill be handled as OSM and Mapbox's supported localezh-Hantzh-Hans-CNshould be reduced tozh-Hansfirst and not a one time split tozhzh-HKexample page