[RFC PATCH]: honor LC_TIME variable (somewhat)

[Dirk Hohndel]

On Mon, Oct 26, 2015 at 08:11:57PM -0700, Thiago Macieira wrote:
> 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.

Ahhh, yes. Now this makes more sense. But we really only want this (month
and weekday names in the correct language) for the date, not for the time.
What this really means is that we'll likely need to really offer separate
language, date and time format options in the preferences...

Gah. I wanted to avoid that. My patch would provide a quick version to
give users what they want in 4.5.1. But for 4.6 we should do this right
and make both date and time format string user configurable.

/D