GNOME Bugzilla – Bug 725296
Unable to change language from english using the environment file
Last modified: 2018-06-29 23:27:34 UTC
I'm trying to change the language used by gnucash to swedish from the standard english. To do this i've changed the environment file so that it reads: # If you wish GnuCash to use a different language, uncomment the two parameters # below and set LANG to your preferred locale LANG=sv_SE LANGUAGE={LANG} GNC_DBD_DIR={GNC_HOME}/lib/dbd # GnuCash was not installed in the default location # XDG_DATA_DIRS will be set so that our documentation # and gsettings schemas are found. XDG_DATA_DIRS={GNC_HOME}/share;{XDG_DATA_DIRS};/usr/local/share;/usr/share I've also tried using nl_BE to see if that could work but it didn't. I can't find anything in the trace files concerning locale. This is a problem that I experience on two computers running the same OS and version of gnucash. The only thing i can find in the trace file is: * 16:16:22 WARN <qof.engine> [guid_init()] only got 2017 bytes. The identifiers might not be very random. * 16:16:49 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) To get more ideas on how to solve this i've asked the gnucash-user mailing list. Here they suggested i tried using LANG=Swedish_Sweden or set LC_ALL=sv_SE LANG=sv_SE LANGUAGE={LANG} . Neither one of these proposed solutions worked. Now I was told to report it as a bug so here I am. (Don't know if the severity is set to the correct level, I'll leave it as is.)
Thank you for the report. I'll add some additional findings. The original reporter has tried this on Windows 7. I have done the experiment on Windows XP as well with the same results. On linux (Fedora 20) changing the environment file does work to get a Swedish interface. So it appears to be Windows only. Additionally not all languages are affected. If I set LANG=fr LANGUAGE={LANG} The interface is properly translated into French. For completeness, I also tried 'sv' as locale instead of 'sv_SE' but that didn't help either.
(In reply to comment #1) > Thank you for the report. > > I'll add some additional findings. > > The original reporter has tried this on Windows 7. I have done the experiment > on Windows XP as well with the same results. > > On linux (Fedora 20) changing the environment file does work to get a Swedish > interface. So it appears to be Windows only. > > Additionally not all languages are affected. If I set > LANG=fr > LANGUAGE={LANG} > > The interface is properly translated into French. > > For completeness, I also tried 'sv' as locale instead of 'sv_SE' but that > didn't help either.
I'm using GnuCash 2.6.5 on Windows 8.1 and i's possible to change to French but not to Swedish using the aforementiond method. I wonder if I must download the Swedish translation somehow and put it in: GNC_DBD_DIR={GNC_HOME}/lib/dbd Or where is the translation file if it isn't in the package?
If I run gnucash from the command line (start cmd.exe in most Win versions) with an invalid tag, I get a line: > LANG=SV_SE gnucash The locale defined in the environment isn't supported. Falling back to the 'C' (US English) locale Note: the tags are case sensitive: language lowercase, region uppercase. Geert, in your mail you suspected some g*-lib. Do you know more? Did they perhaps split their -lang packages?
This came up again on the gnucash-user mailing list yesterday. John Ralls offered a workaround which I have verified to work on my Win XP test system. In the environment file set LANG=Swedish_Sweden LANGUAGE=sv That should make gnucash use the Swedish strings throughout its interface.
Also based on the mailing list conversation I looked at the code of gettext (an external library we use) and I'm pretty sure the bug is in that library. The background: Windows uses different names for locale. For Swedish (Sweden) for example the locale name is "Swedish_Sweden", when on unixlike systems it would be "sv_SE". The cope with this gettext defines a function setlocale_unixlike [1] which accepts both the Windows and the unix formats on a Windows system. This depends however on a language table [2] which is missing an entry for sv/Sweden. I have filed a bug against gettext [3]. Hopefully they agree and get it fixed soon. [1] http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/setlocale.c#n634 [2] http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/setlocale.c#n255 [3] http://savannah.gnu.org/bugs/index.php?44588
Added complication: due to sv not being recognized as a locale by gettext, g_win32_getlocale will never return it as possible locale. Our code depends on this though to find the path with the Swedish localized account hierarchy templates. As a result Swedish users can't set up new localized account hierarchies on Windows PCs. It's sad that my bug against gettext hasn't even been as much as acknowledged on the gnu bugtracker.
Umm, g_win32_getlocale doesn't depend on gettext anything. It uses Windows functions GetThreadLocale() and GetLocaleInfo(), then special-cases a few languages to set the correct script (latin or cyrillic) tag on the end - but if LC_ALL, LC_MESSAGES, or LANG are set in the environment then it just returns the first of those. Note that my work-around for setting the language locale to the Microsoftish Swedish_Sweden defeats this by setting LANG to an unusable value.
gnc_ea_get_locale_dir() is a separate problem from this bug. That whole function is a bug *except* for the call to g_win32_getlocale.
I have added a special-case check in the Windows bit of gnc_ea_get_locale_dir() for LANG="Swedish_Sweden" or LANG="Swedish_Finland" to work around the work-around.
Meanwhile I decided to give gettext a nudge in the right direction and submitted a patch to fix the bug I raised last year. Got confirmation today the patch got accepted and will be pulled into gettext "with the next gnulib sync". Looking at their git history this happens fairly regularly so I hope the next gettext release (0.19.8) will ship with the fix.
I wish I could remember what the heck I was talking about in comment 9. There is no such function, nor is there anything similar. Another somwhat related wrinkle turned up on the user list this week: Collation is wrong in Czech on Windows if LANG is set to cs_CZ in the environment file. Everything else is apparently correct, and if the user sets the locale in the Windows Control Panel collation is correct. The Windows C runtime locale is set from a unix-style locale by gtk_init() via the static function setlocale_initialization() at https://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c?h=gtk-2-24#n559. Collation in GncTreeViews is done by calling g_utf8_collate, and on Windows that's performed by converting the string from utf8 to the correct code page and running strcoll on the result. It would be much better to use Microsoft wide-character functions, but even then the result will only be correct if the locale is set correctly.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=725296. Please continue processing the bug there and please update any external references or bookmarks.