Cocoa.NSLocale.PreferredLanguages

Hello,
in apps compiled for several languages, sometimes one needs to adjust the left and the width of objects (for instance, adjacent labels) according to the width of the english/spanish/italian etc strings.
In order to detect the primary language I used this code:
dim s() as string = Cocoa.NSLocale.PreferredLanguages
gItalian = s(0) = “it”
gFrench = s(0) = “fr”
etcetera

Then, in the open event of the objects I would write:

if gItalian then me.left = me.left - 10 me.width = me.width + 10 end if

if gFrench then me.left = me.left - 14 me.width = me.width + 14 end if

As far as I recall, this worked OK, that is until I installed Sierra. Now I find that every language code is followed by “-US” as: it-US, fr-US and so on.
Therefore I had to modify the code in:
dim s() as string = Cocoa.NSLocale.PreferredLanguages
gItalian = left(s(0), 2) = “it”

Could the problem depend on my using macOSlibrary?
Anyway, I thought it good to raise the flag for those using the same technique.

Dont do it this way ?
Make one dynamic constant - gLanguage
In it put
for the default value - put in the language code for whatever language YOUR machine runs in

Then add each language you support with its language code
ie

          Platform = Any
          Language = Italian
          Value = it

          Platform = Any
          Language = French
          Value = fr

At runtime the value of gLanguage will be whatever language you support that is closest to the top of the users selected list of languages - something your method wont do

Or have the values the controls need to be adjusted by be a dynamic constant.

If I understand correctly, the problem with that approach will show that my app is localized for all the languages I have in System Preferences > Language & Region, even if my app actually supports only a couple of them.
Don’t you think that gLanguage should be set only for the few languages my app supports?
Or may be I should go back to my old way of compairing a dynamic constant; for instance:
gItalian = kEdit = “Modifica”

Meanwhile I saw in the Apple docs that from Sierra on (iOS 9), the code of Locale.PreferredLanguages is now always a five-letter code, made up of language and region delimited by hyphen; so, for instance, if as region I set US, each item of the array of preferred languages will be followed by -US (en-US, it-US, fr-US etc.); if I set France, I’ll get fr-FR, it-FR, en-FR, and so on.

Therefore i’ll follow your advice. Thank you.

@Joe Ranieri I’m going to refactor my approach as at present and in future won’t be anymore satisfactory.
Thank you.

[quote=330051:@Carlo Rubini]If I understand correctly, the problem with that approach will show that my app is localized for all the languages I have in System Preferences > Language & Region, even if my app actually supports only a couple of them.
Don’t you think that gLanguage should be set only for the few languages my app supports?
[/quote]
That what I said
Only put an entry in gLanguage for the languages you DO support

Yes
You get the LANGUAGE + LOCALE code (at least)
So for a system set to operate in the USA showing french you get fr-US
For a system set to to operate in Canada showing french you get fr-CA
And you may get subtypes for the language as well like Traditional Chinese (zh_TW) vs Simplified (zh_CN) + a locale code
So you could get zh_TW-US or zh_CN-US etc
So much fun

I agree. So much fun.

This ranks right up there with my love of handling dates & times
Everyone should just run on pipeline time (central or GMT-6) with NO DST and live with it :stuck_out_tongue: