After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725296 - Unable to change language from english using the environment file
Unable to change language from english using the environment file
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Translations
2.6.1
Other Windows
: Normal normal
: ---
Assigned To: gnucash-documentation-maint
gnucash-documentation-maint
Depends on:
Blocks:
 
 
Reported: 2014-02-27 09:29 UTC by Arvid
Modified: 2018-06-29 23:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arvid 2014-02-27 09:29:33 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.)
Comment 1 Geert Janssens 2014-02-27 09:36:00 UTC
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.
Comment 2 Anders Lorentzson 2015-01-27 12:53:29 UTC
(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.
Comment 3 Anders Lorentzson 2015-01-27 13:02:44 UTC
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?
Comment 4 Frank H. Ellenberger 2015-02-17 15:39:31 UTC
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?
Comment 5 Geert Janssens 2015-03-20 08:49:58 UTC
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.
Comment 6 Geert Janssens 2015-03-20 09:19:16 UTC
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
Comment 7 Geert Janssens 2016-03-17 13:48:08 UTC
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.
Comment 8 John Ralls 2016-03-17 16:00:57 UTC
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.
Comment 9 John Ralls 2016-03-17 16:45:17 UTC
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.
Comment 10 John Ralls 2016-03-20 23:00:54 UTC
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.
Comment 11 Geert Janssens 2016-03-22 10:02:36 UTC
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.
Comment 12 John Ralls 2017-03-08 01:47:17 UTC
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.
Comment 13 John Ralls 2018-06-29 23:27:34 UTC
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.