#1 2018-03-12 19:54:12

van der Decken
Member
Registered: 2018-01-30
Posts: 27

Minor issue with English locale other than en_US

TL;DR version: GCstar doesn't work properly with a non US english locale installed.

This code in GCOptions.pm:

Code:

    sub getFullLang
    {
        my $self = shift;
        (my $lang = $self->lang) =~ s/(.*)/\L$1\E_$1/;
        $lang =~ s/_EN/_US/; # Fix for english
        $lang =~ s/_CS/_CZ/; # Fix for Czech
        $lang =~ s/_cn_ZH//; # Fix for Simplified Chinese
        $lang =~ s/_ZH/_TW/; # Fix for Traditional Chinese
        $lang .= '.UTF-8';
        $lang = 'sr@Latn' if $lang =~ /^sr/;  # Fix for serbian
        return $lang;
    }

combined with this code in /usr/bin/gcstar

Code:

my $lang = $options->getFullLang;
$ENV{LANG} = $lang;
$ENV{LANGUAGE} = $lang;
$ENV{LC_ALL} = $lang;
$ENV{LC_CTYPE} = $lang;
setlocale(LC_ALL, $lang);

only works for English if the en_US locale is installed. If you have another English variant, like en_CA or en_GB installed instead, it fails. You get a warning whenever GCstar is started from a terminal:

Code:

Gtk-WARNING **: Locale not supported by C library.
    Using the fallback 'C' locale. at /usr/lib/arm-linux-gnueabihf/perl5/5.24/Gtk2.pm line 126.

Also, the "Use spelling checker for long text fields" in Settings -> Features -> Conveniences only allows American English spelling. Common words such as "colour" and "neighbour" are flagged as being incorrectly spelled.

The reason is this line in getFullLang:

Code:

        $lang =~ s/_EN/_US/; # Fix for english

This creates a string of en_US, which is then used to set the locale. Since I don't have that variant installed, I get the warning message, and the spelling checker uses its default list of words with American spelling.

I can get around the issue by changing that one line in getFullLang to:

Code:

        $lang =~ s/_EN/_CA/; # Fix for english

but that's a terrible hack. I have thought of a more "proper" fix, which would be to create separate US English/Canadian English/British English language settings (and their associated language files) and some other code changes when language is being handled, but that seems like using a sledgehammer to swat a fly.

The options loader is already using the LANG environment variable to set up the default language, so my initial thinking is to use this same information somehow to get the right country variant as well. But I'm still at the "wondering what to do about it" stage and I think it's time to take a walk, clear my head and see if anything better occurs to me.

Offline

 

#2 2018-03-14 10:27:17

kerenoc
Member
Registered: 2016-03-19
Posts: 227
Website

Re: Minor issue with English locale other than en_US

Maybe GCstar should differenciate between from one side the setting of locale used for the UI, the OS related operations (especially dealing with file names and file encoding) or the date formats and from the other side the setting of the language to get the translation resources.

That would mean that the 'fixes" in getFullLang should not be applied before setting the environment variables and only in the context of finding the name of the right files in GCLang. Some native English speaker should confirm that using the same translation strings for all English version is acceptable in terms of user experience.

Offline

 

#3 2018-03-16 01:58:58

van der Decken
Member
Registered: 2018-01-30
Posts: 27

Re: Minor issue with English locale other than en_US

That's pretty close to what I've been thinking.

I don't think that the use of one English setting for the UI is a problem. But it would be nice if the spelling check worked with the system locale settings. The cause of the warning message (and the subsequent failure of the locale dependant spelling checks) is that the program is trying to set the locale language to a variant that isn't installed. Which makes sense; you can't set a locale that isn't installed.

On a Linux system, the command:

Code:

locale -a

will get you a list of installed locales. I think it's probably reasonable to say "if the user selects a particular UI language, check the list of locales from 'locale -a' and set the system language setting to the first locale in the list that matches the chosen language.

Unfortunately, I couldn't locate anything in the POSIX library that returned that list. Maybe I just didn't see it, or maybe it's not there. If it's not there, executing the command itself on Linux is a workaround, but what about Windows?

Or maybe I'm overcomplicating it. Grabbing the LANG environment variable gets the currently selected locale. Maybe just assume that the current locale is the language that the user wants to interact with the system with and go with that. Forget about setting the various LC_* variables and just pass that value to the spell checking system?

Time to mull some more, I think. But I think I like that.

Offline

 

#4 2018-03-28 19:40:23

van der Decken
Member
Registered: 2018-01-30
Posts: 27

Re: Minor issue with English locale other than en_US

A further oddity:

Every so often, I noticed that the spell checking seemed to stop observing the locale in the middle of a session. I finally figured out what it was that was triggering it. As soon as I save the collection, GCStar starts ignoring the locale and goes back to American English spelling. I've taken the briefest of looks at the code and nothing odd jumps out at me, so it's time to dive in again.

Offline

 



Should you have a problem using GCstar, you can open a bug report or request some support on GCstar forums.