[GNC-dev] Early locale initialization

[Geert Janssens]

Op vrijdag 19 maart 2021 02:19:46 CET schreef John Ralls:
> > On Mar 18, 2021, at 6:08 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op donderdag 18 maart 2021 13:56:35 CET schreef Derek Atkins:
> >> On Thu, March 18, 2021 7:58 am, Geert Janssens wrote:
> >> [snip]
> >> 
> >>> 3. While all three allow to tweak some environment parameters, only
> >>> linux
> >>> allows the user to do so via the environment file. For Windows and Macos
> >>> that
> >>> file is only read after locale is set. Whether that's a good thing
> >>> depends
> >>> on
> >>> the answer to question 2.
> >> 
> >> Are you saying that /etc/gnucash/environment (or the equivalent thereof)
> >> is not read/used on Windows or Mac?
> > 
> > No, it is used on all platforms. But it's only read after locale
> > initialization on mac/windows has been done. So for locale initialization
> > it only will affect linux. The other parameters in there (like
> > LD_LIBRARY_PATH tweaks and so on) will still affect all platforms.
> 
> No, it's read after the other initializations so that it will override them.
> As long as setlocale is called after loading the environment then the last
> computed locale is what GnuCash starts up with. I've tested that pretty
> extensively on both macOS and Win32, though not since last fall.
> 
Running this through a debugger I see setlocale gets called indeed afterwards 
but more by chance than by choice (the first time during gtk's 
initialization).

To zoom in on this: if I get you right the idea is effectively to allow users 
to set LC_ALL in the environment file and make it override whatever system 
locale was found (or fallen back to).

The code and comment in https://github.com/Gnucash/gnucash/blob/maint/gnucash/
gnucash-core-app.cpp#L424 certainly don't suggest that. For Macos and Windows 
it explicitly excludes the call to setlocale, with the suggestion it was 
already done. That's contrary to that intent.

I guess the part that complicates this area is that on both Windows and Macos 
there are two locales to take into account - the posix locale and the platform 
native one.

The windows branch of this code explicitly tries to set both to the same 
locale. If it finds LC_ALL, LC_MESSAGES or LANG it will use that for posix and 
then set the same for the Windows locale. In the absence of any of these it 
will start from the Windows locate and use that to also set the posix locale. 
To me that suggests the environment overrides should happen before calling 
this code. If you do it afterwards like we do now you may end up with out of 
sync Windows and Posix locales. I have no idea if that would have side-effects 
but I can imagine this could result in some obscure locale related corner case 
bugs.

If I read the mac branch of the code correctly, it always starts from the 
Macos locale and tries to derive a posix locale from it. A user can afterwards 
override that posix locale via settings in the environment file. The mac 
locale will never be updated to match any posix locale though. Again I don't 
know if that could be cause for issues.

Do you think a reverse mapping as in the Windows environment would be possible 
? I mean if users set LC_ALL (or related), can we use that to set the Macos 
locale for the gnucash process space ? I don't know enough of the platform to 
know whether Macos allows an application to change locales.

> The one thing that doesn't work is passing LANG/LANGUAGES in the Win32 CMD
> shell because that shell doesn't understand that. It should be possible on
> Powershell with something like $Env:LANG=nl_BE "c:\Program Files
> (x86)\gnucash\bin\gnucash.exe"; I've never actually tried that.
> 
Well, you can do the same in a Win32 CMD shell, but not on a single line.
set LANG=nl_BE
"c:\Program Files (x86)\gnucash\bin\gnucash.exe"
Will do it.

> On macOS the language fallback is used because Apple's localization can
> result in locales that libc thinks aren't legal, e.g. en_BE so we have to
> find something close or the user gets "C". That's done only when getting
> the locale from system preferences (aka "defaults").

I consider that a very nice refinement.

Regards,

Geert