[RFC PATCH]: honor LC_TIME variable (somewhat)

[Thiago Macieira]

On Tuesday 27 October 2015 10:58:17 Dirk Hohndel wrote:
> I'm sure I'm overlooking unintended consequences of this approach - which
> is why this is an RFC and not something I just committed to master

I'm not sure... this may be you're making a workaround instead of fixing it 
properly 10 lines above.

Your change works and it's not an accident. QLocale() returns the default 
locale, which is either something you set with QLocale::setDefault() or the 
system one (same as QLocale::system()). The system locale on Unix systems 
respects the multiple LC_* variables (at least LC_NUMERIC, LC_TIME, 
LC_MONETARY and LC_MESSAGES).

There are two problems, though. The beginning of the function you modified has 
this:

        if (!s.value("UseSystemLanguage", true).toBool()) {
                loc = QLocale(s.value("UiLanguage", 
QLocale().uiLanguages().first()).toString());
        } else {
                loc = QLocale(QLocale().uiLanguages().first());
        }

If the config file has UseSystemLanguage=false, does it follow that the user 
does not want the system time format either? Or just the language 
(LC_MESSAGES)?

Also, please note that this problem happens because of the else branch there. 
It gets the name of the system locale and then looks up the QLocale data for 
that name. As a consequence, you do not get the different settings if the LC_* 
variables were set to different values. This can be solved by simply removing 
that second branch. or replacing it with loc = QLocale()...

... except it was introduced in 2a8f32b8 "Fix date and time l10n", so there 
may be a reason why.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358