You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In web development, language codes generally follow the RFC 1766 standard. In this standard, the language tag for Chinese is typically written as: zh-CN, zh-TW, zh-HK.
However, in Android and iOS, language codes follow the RFC 4646 standard, which further distinguishes Simplified Chinese (Hans) and Traditional Chinese (Hant). The language tags in this standard look like: zh-Hans-CN, zh-Hant-TW, zh-Hant-HK
When using getLocales().languageTag from expo-localization on an Android device (with system language set to Simplified Chinese), it will return this output:
[{"languageTag": "zh-Hans-CN"}]
This cannot be matched to existing AppLanguage, so it will rollback to English. Because AppLanguage naming follows RFC 1766, which is still widely used in browsers. Therefore, we cannot rename Chinese AppLanguage to following RFC 4646.
This patch is meant to solve this issue by converting the RFC 4646 output from the device into RFC 1766, just like how we handle incorrect languageCode on legacy Java devices (#4461).
With this patch, now using getLocales().languageTag will return the following output:
[{"languageTag": "zh-CN"}]
Based on #5384, the app can now correctly handle language tags with region codes. This allows it to match the existing zh-CN in AppLanguage and display Chinese when the app is opened for the first time, instead of rolling back to English.
It's hard to say RFC 1766 or RFC 4646 which standard is better, but both will likely coexist for a long time. Web development is unlikely to transition to RFC 4646, as it would break browser behavior, and W3C seem to prefer RFC 1766.
Always bear in mind that the golden rule is to keep your language tag as short as possible. Only add further subtags to your language tag if they are needed to distinguish the language from something else in the context where your content is used.
For now, Chinese is one of the few languages that requires mapping conversion. Most languages work as expected under either standard. So this patch only includes conversion mapping for Chinese. I prefer not to rewrite the logic in the later parts of the code.
Okay... There are so many variations of Chinese in the Android system language list.
For Simplified Chinese, there are zh-Hans-CN, zh-Hans-MO, zh-Hans-HK, and zh-Hans-SG. The previous exact match may not cover other Chinese variants, such as zh-Hans-SG. Please forgive me for using startsWith for fuzzy matching. To ensure no Chinese variant fallback to English.
Based on the reference, Android 7+ and iOS 9+ have started using zh-Hans / zh-Hant language codes, so this patch is also effective for iOS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
In web development, language codes generally follow the RFC 1766 standard. In this standard, the language tag for Chinese is typically written as:
zh-CN,zh-TW,zh-HK.However, in Android and iOS, language codes follow the RFC 4646 standard, which further distinguishes Simplified Chinese (Hans) and Traditional Chinese (Hant). The language tags in this standard look like:
zh-Hans-CN,zh-Hant-TW,zh-Hant-HKWhen using
getLocales().languageTagfrom expo-localization on an Android device (with system language set to Simplified Chinese), it will return this output:This cannot be matched to existing
AppLanguage, so it will rollback to English. BecauseAppLanguagenaming follows RFC 1766, which is still widely used in browsers. Therefore, we cannot rename ChineseAppLanguageto following RFC 4646.This patch is meant to solve this issue by converting the RFC 4646 output from the device into RFC 1766, just like how we handle incorrect languageCode on legacy Java devices (#4461).
With this patch, now using
getLocales().languageTagwill return the following output:Based on #5384, the app can now correctly handle language tags with region codes. This allows it to match the existing
zh-CNinAppLanguageand display Chinese when the app is opened for the first time, instead of rolling back to English.It's hard to say RFC 1766 or RFC 4646 which standard is better, but both will likely coexist for a long time. Web development is unlikely to transition to RFC 4646, as it would break browser behavior, and W3C seem to prefer RFC 1766.
For now, Chinese is one of the few languages that requires mapping conversion. Most languages work as expected under either standard. So this patch only includes conversion mapping for Chinese. I prefer not to rewrite the logic in the later parts of the code.
Before:
before.mp4
After:
after.mp4