In addition, the Macos code doesn't return the final locale string that was set. As a result the PINFO message to log the locale details to the trace file is partly bogus. Granted this was written with the Windows locale issues in mind, but again, it would be nice if this could be made consistent.
Regards, Geert Op donderdag 18 maart 2021 12:58:28 CET schreef Geert Janssens: > In a moment of distraction I started looking at the locale initialization > code in gnucash-core-app.cpp. > > If I understand the actual code properly it's not exactly working as I had > intended. So with this thread, I'd like to clear this out. > > For reference I'm talking about the code that starts here: > https://github.com/Gnucash/gnucash/blob/ > 1756f76079221f77904ccb9c9a504f9ebca2eb0e/gnucash/gnucash-core-app.cpp#L418 > > Locale initialization is strongly influenced by platform, so there are > different code paths to set locale. > 1. Macos will use set_mac_locale > 2. Windows will use set_win32_thread_locale > 3. Linux will fall through and use setlocale > > So far so good. > > Looking deeper, the linux method will search for an environment variables > LC_ALL or LANG in that order and uses its value as locale. If that fails, it > will fall back to the C locale. There is also code in place to allow the > user to override any of these variables by setting them in the gnucash > environment file. > > On Macos the code will first try to use the Macos proper locale setup code. > If that fails it falls back to locale "en_US.utf-8". Then it sets the LANG > variable to the same locale and proceeds with calling gnc_localeconv which > will fill in the locale details that will be used throughout the code. > > On Windows the code will first look for environment variables "LC_ALL", > "LC_MESSAGES" or "LANG" (in that order). If any of those exists it will try > to convert that to a locale. If that fails it will fall back to the system > default locale and if that fails it falls through to our main code which > then defaults to "C". > > > Putting these next to each other there are a few differences: > 1. the final fallback locale. On Macos that will be "en_US.utf-8", on the > other platforms it will be "C". Should we use the same default on all or > rather not ? > 2. Priority of locale source. On linux and Windows adding variables in the > environment will allow the user to override the default system locale. On > Macos it will only allow to set LANG or LANGUAGE variables, not locale. Do > we want to allow the user to override system locale via environment > variables or do we only want a fallback mechanism ? Do we want to allow the > user specify the locale to use for that fallback ? > I'll note the Macos code has a neat fallback trick in that it tries to find > a related locale in case the default doesn't work. Related in the sense > that it may be another language in same country or if that fails the > language without country. Downside is that in case of multiple fallback > options the one chosen may not be the one the user actually would have > preferred. > 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. > > Regards, > > Geert > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
