ReactNativeLocalization icon indicating copy to clipboard operation
ReactNativeLocalization copied to clipboard

getCurrentLanguage on iOS returns incorrect locale on iOS 10+ since 2.1.2

Open R1ckye opened this issue 5 years ago • 1 comments

https://github.com/stefalda/ReactNativeLocalization/commit/2a3e91c48095dd3d5fe58d1059179da438a882e1 changes the behaviour of -(NSString*) getCurrentLanguage significantly, however, on iOS 10+ it uses [[NSLocale currentLocale] localeIdentifier], which "is based on the device's Region Format settings, not the language." (see: here ). So for example if I set my simulator language to Hungarian, because my computer is set to en-US (and therefore, the simulator too), it returns en-US, instead of hu-HU or hu-US, which breaks my app. As suggested in the above linked StackOverflow thread, it should instead use [[NSLocale preferredLanguages] objectAtIndex:0]

R1ckye avatar Sep 23 '19 11:09 R1ckye

@R1ckye Thanks for opening an issue.

Note: In the meantime my code you're referring to has been changed significantly and the following are just some basic rules for Xcode language handling and a statement about my old edit.

Xcode handling

[[NSLocale currentLocale] localeIdentifier] and [[NSLocale currentLocale] languageCode] both take into account what's available as translation in your Xcode project settings to find the best available match, whilst [[NSLocale preferredLanguages] objectAtIndex:0] always returns the device settings.

I tested a new empty App with simulator set to German language and US Region.

This is the result, when running an App with only English translation being set in Xcode: Screen Shot 2020-02-02 at 15 12 20

As you can see, the best match is en due to missing localization inside the project. The region is always taken into account and correctly shows US.

As soon as I add the German translation to Xcode, the following is returned: Screen Shot 2020-02-02 at 15 12 46

So as soon as you would've added your required translations to Xcode, the returned result would have been correct. That's what most of RN localization components require.

But you are basically right, this handling is probably out of scope of React Native developers and it should've been just forwarded using preferredLanguages.

Current situation

The code has been changed significantly after my commit, see https://github.com/stefalda/ReactNativeLocalization/commit/81c8ec7b6be2b9865f73c819075ea605ee0ed2ac.

Screen Shot 2020-02-02 at 15 22 22

Xcode immediately gives a warning about @available being used wrong inside an if-clause. And somebody re-added the AppleLanguages fallback.

So, now this messed up again, but in another way :) A note in the docs that you need to add your supported languages to the Xcode project would have been enough, instead there's wrong code now reverting my edit.

I don't have the time to look further into this (sorry), still hope this helps you and others to understand what's going on.

winkelsdorf avatar Feb 02 '20 14:02 winkelsdorf