Locale VM plugin always returns the default English on Mac Os

[stormwatch]

Dear maintainers:

It looks like the locale reported by the VM is not working as it should. No matter what I try, I always get the default: English. This was originally reported in the Cuis mailing list.

How to Reproduce

Change your OS locale to a language other than English.

I tried with Portuguese and Italian; currently I'm on Italian. The output of /usr/bin/locale is:

LANG="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_CTYPE="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_ALL=

And here is the configuration as reported by the UI:

In Squeak or Pharo (actually Glamorous Toolkit)

Evaluate

Locale current

In GT it prints as:

a Locale(en-PT)

Portugal is correctly reported, as the current configured country in the OS.

In Squeak it prints as:

a Locale(en-US <English (UNITED STATES)>)

In Cuis

Evaluate

Feature require: 'Locales'.
Locale current

It prints as:

a Locale(en-PT)

Speculation

It seems like it all boils down to Locale >> primLanguage. It always returns the null-terminated 'en�'.

Computer

MacBook Air, Intel, 2017
Mac OS Monterey 12.7.6 (21H1320)

Please let me know if you need me to try more things.

Thank you!

[hilaire]

Thanks for the report.
It is a blocking issue to deploy, for the first time, DrGeo on thousands of computers in Geneva schools, to teach programming.

[dcstes]

I am not using Mac OS but on Solaris I have LANG=nl_BE.UTF-8 at the UNIX level and in Squeak v6.1 alpha under "Preferences" there is #useLocale enabled :

In a Workspace:

Preferences valueOfFlag:#useLocale

evaluates to "true".

Locale current prints aLocale(nl-BE <Dutch;Flemish (BELGIUM)>)

the primLanguage instance method returns nl

Smalltalk listLoadedModules also shows LocalePlugin as loaded

[timrowledge]

Similar results on Pi - turning the locale preference on makes the Locale current value properly reflect what the OS reports.
Not entirely sure why we would have set it off as a default; but timezones are probably involved long with the matter. They always are.

[hilaire]

On my GNU/Linux Locale current reports the expected language and country code.
Last time I checked , one year ago, it worked as expected on Windows too.

[stormwatch]

Changing the value of useLocale to true makes no difference. E.g. in Cuis, Locale current returns a locale that prints as 'en-PT' instead of the expected 'it-PT' and Locale new primLanguage returns 'en�'.

[timrowledge]

Looking at the most recent image I have to hand(23223 update), I see some confusion in the state of several extant Locale instances (and I don't see why there are several)
Locale knownLocales.

• a Dictionary with a single instance having the id isoLanguage = 'en' and isoCountry = nil, and no other ivars set to anything but nil
  Locale current.
• an instance with id isoLanguage = 'en' and isoCountry = 'US'. Of the other ivars only leadingChar is non nil, = 0 (yes, the SmallInteger, not even a Character)
  Locale currentPlatform
• an instance with id isoLanguage = 'en' and isoCountry = 'GB'. The only other non-nil ivar is currencySymbol which is codepoint 194 + codepoint 163. Which renders improperly in both Squeak on Pi and in my web browser, and in a text editor looks like 'Ã�£' .
  Looking at what the primitives return directly
  Locale new primCurrencySymbol. '�£'
  Locale new primDST. true
  Locale new primDecimalSymbol. '.'
  Locale new primDigitGrouping. ','

Locale new primLanguage. 'en <<<<< Note how pasting the result messed up the copy/paste/browser rendering. There is a Character null after the second char and likely that should have been chopped off in the prim code.

Locale new primLongDateFormat. '%d/%m/%y'
Locale new primMeasurement. true
Locale new primShortDateFormat. '%d/%m/%y'
Locale new primTimeFormat. '%T'
Locale new primTimezone. -420
Locale new primVMOffsetToUTC. 0

This is quite confusing. And there is little usage of any of it in the default image to help us work out the intended ways of using any of it.

[timrowledge]

In an image with preference set to use locale= true, try Locale current: nil and then explore Locale current. That should have cleaned out and rebuilt your Locale. Maybe.

[stormwatch]

In an image with preference set to use locale= true, try Locale current: nil and then explore Locale current. That should have cleaned out and rebuilt your Locale. Maybe.

It probably rebuilds the locale, but as before, the language is still wrongly reported as English because Locale>>primLanguage always returns 'en�'.

The other issues you observed might be related to this one.

Tested in a newly downloaded Squeak Image v 6.1 alpha 23242 64 bit. Print output in comments

Preferences valueOfPreference: #useLocale "false" 

Locale current "a Locale(en-US <English (UNITED STATES)>)" 

Locale allInstances "{a Locale(en-US <English (UNITED STATES)>) . a Locale(en-PT <English (PORTUGAL)>)}"

Preferences setPreference: #useLocale toValue: true "a Preference#useLocale true"

Locale current "a Locale(en-US <English (UNITED STATES)>)"

Locale allInstances "{a Locale(en-US <English (UNITED STATES)>) . a Locale(en-PT <English (PORTUGAL)>)}"

Locale current: nil "Locale"

Locale current "a Locale(en-PT <English (PORTUGAL)>)"

Locale allInstances "{a Locale(en-US <English (UNITED STATES)>) . a Locale(en-PT <English (PORTUGAL)>)}"

Locale new primLanguage "'en�'"

[eliotmiranda]

Eziquiel, can you take a look at the source? It’s in platforms/*/plugins/LocalePlugin and src/plugins/LocalePlugin/LocalePlugin.c

[timrowledge]

Looking at the code in https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/platforms/unix/plugins/LocalePlugin/sqUnixLocale.c around line 570 and up it seems like the only way you could get the effect of the LANG setting being ignored if by the phrase on lines is returning false and so the language ptr is not getting set. That then leaves it to the DEFAULT_LANGUAGE per line 52.

[dcstes]

Did the process "inherit" the environment LANG variable from its parent ?

On SqueakSource, there is a class OSProcess. http://www.squeaksource.com/OSProcess which can be loaded into a Squeak image and then:

OSProcess thisOSProcess environmentAt:#LANG

in a Workspace 'print it' evaluates (for me) to "nl_BE.UTF-8'.

This is to check whether the executable is launched with the LANG variable at the UNIX process level.

Perhaps in your case the executable is not getting the or any of the environment variables, perhaps due to some environment resetting.

Anyway, the LocalePlugin is used in a package like 'DrGeo' (for Cuis) which provides as an application localised messages, but those have to be explicitely installed (with the UNIX/POSIX msgfmt command). I think that OpenSmalltalk in itself does not provide a localised interface by setting the LANG environment variable, which is perhaps why in Preferences useLocale is disabled by default.

https://github.com/Dynamic-Book/drgeo uses the LocalePlugin and provides msgfmt files, but I think that many classes or applications do not provide this.

[dcstes]

Is OpenSmalltalk started from the command-line in a Unix shell ?

In a Unix shell echo $LANG should print the environment variable.

To get a list of the environment variables GNU coreutils "env" command would print the environment at the Unix shell command line level. Or "setenv" in csh or "export" in bash.

The OpenSmalltalk executable should then be started command line from the shell as a child process of the shell to inherit the environment from the parent.

Inside Smalltalk : OSProcess thisOSProcess environment

this returns a Dictionary instance with the values of LOGNAME, USER, HOME, MAIL, SHELL, LANG etc. as in the Unix shell

[eliotmiranda]

The VM can be started either on the command line or through the GUI on at least macOS and Windows. Under X11 we want it to be launched in either way but X11 delegates such schemes and so AFAIA there’s no standard way to launch through the GUI. But the user’s environment should be made available to the system irrespective of the launch mechanism.