Use CultureInfo.CurrentUICulture instead of ResourceLanguage resource?

[madd0]

In the README file, it says that the resource files need to have a ResourceLanguage key in order to identify the language that is being used. It gives as an example fr_FR. The ResourceLoaderExtension class then takes that value and creates a CultureInfo instance.

It appears, however, that the CultureInfo class is unable to parse cultures that use the underscore as a language/locale separator. I guess that the README file should be updated to use a hyphen and/or the class could make the replacement at runtime to support both syntaxes.

Then again, is using the ResourceLanguage key really necessary? I ran a test on a UWP app on Windows 10 (didn't run any other combinations) and CultureInfo.CurrentUICulture is consistently providing the expected value. This makes sense, given that this is supposed to be the CultureInfo instance used by the resource manager to look up culture-specific resources.

If anyone's interested in testing on other platforms, I can create a PR.

[rudyhuyn]

Thanks a lot for your feedback!

The underscore was a mistake, I will change the documentation.

For CultureInfo.CurrentUICulture, there is an issue. If you use the french version of Windows 10 for example and you launch an application only available in english, CultureInfo.CurrentUICulture will be equal to fr_fr instead of en_us. To summarize, CultureInfo.CurrentUICulture is the culture used by Windows, not by your app.

[madd0]

Sorry, but CultureInfo.CurrentUICulture is not the culture used in Windows. From the docs:

[It's] the current user interface culture used by the Resource Manager to look up culture-specific resources at run time.

I do agree that it might not always represent the language that the app is being displayed in, though. I just can remember in which cases.

My current test setup is a fr-FR OS with a en-GB language pack and the following language preferences (in order): fr-CH, qps-ploc, en-GB, es-CR. My app has the following resources: en-US (default), es, qps-ploc. When I run the app, CurrentUICulture is qps-ploc, because fr-CH is not supported by the app. If I put en-GB or es-CR at the top of the list, whichever has the higher priority will be selected.

So, on Windows 10 I can guarantee that using CurrentUICulture works. However, I do have a vague memory of having to use the "language in the language file" trick or something similar a few years ago when working on a Windows Phone 8 app, so maybe it is necessary to continue using this method for some of the other supported platforms... Unfortunately, I can't run the tests to confirm.

[rudyhuyn]

You missed something, try to create an app with default language set to "pt-BR" (appxmanifest) for example, CultureUI will be fr-CH in your case.

As I said, CultureUI is related to Windows, it can only one of the value of your preference: fr-CH, qps-ploc, en-GB, es-CR, nothing else.

If the app doesn't include one of them (or similar, fr-CH can be replaced by fr-FR is nothing is found), CultureUI will have an incorrect value.

On Oct 30, 2016, at 8:38 AM, Mauricio Díaz Orlich notifications@github.com wrote:

Sorry, but CultureInfo.CurrentUICulture is not the culture used in Windows. From the docs:

[It's] the current user interface culture used by the Resource Manager to look up culture-specific resources at run time.

I do agree that it might not always represent the language that the app is being displayed in, though. I just can remember in which cases.

My current test setup is a fr-FR OS with a en-GB language pack and the following language preferences (in order): fr-CH, qps-ploc, en-GB, es-CR. My app has the following resources: en-US (default), es, qps-ploc. When I run the app, CurrentUICulture is qps-ploc, because fr-CH is not supported by the app. If I put en-GB or es-CR at the top of the list, whichever has the higher priority will be selected.

So, on Windows 10 I can guarantee that using CurrentUICulture works. However, I do have a vague memory of having to use the "language in the language file" trick or something similar a few years ago when working on a Windows Phone 8 app, so maybe it is necessary to continue using this method for some of the other supported platforms... Unfortunately, I can't run the tests to confirm.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[madd0]

Hmm... Still can't reproduce... On Win 10 (1607), even an app with pt-BR as it's default language and only resources will still give me pt-BR as the CurrentUICulture even if pt-BR is not in my language list or anywhere else in my system. What configuration are you testing on?

[rudyhuyn]

You were right, this behavior is only with SL8.

An other reason I did it is due to the closest-match system used by Windows when a specific culture is not present: for example, if you PC is en-GB, Windows can use "en-US" if "en-GB" and "en" are not present.

Because SL8 is (unofficially) deprecated and the closest match is not a real issue in fact for us (cause PluralNet uses only the two letters id, an no more the full name (it was the case of the proto), I will change the code to use CultureUI if ResourceLanguage is not set!

Thanks for your feedback