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
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.
[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
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