Fix dates being on the wrong locale when setting an application language individually
Needs ReviewPublic

Authored by aacid on Aug 12 2019, 10:32 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

We were only setting LANGUAGE, but that does not set LC_TIME so the time was still
set to the "user" locale, we now set LC_ALL to switch the application completely to that language

Note we are not actually switching the posix locale, just all the
QLocale/ki18n related internals, strftime would still use the user
original locale. This is also the reason we don't really need to pass a
valid locale name to LC_ALL (i.e. we're giving it "ru" instead of
"ru_RU.UTF-8"), since the only thing we need to do is convince QSystemLocaleData::readEnvironment
and giving it "ru" is enough

Diff Detail

Repository
R263 KXmlGui
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 15036
Build 15054: arc lint + arc unit
aacid created this revision.Aug 12 2019, 10:32 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptAug 12 2019, 10:32 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
aacid requested review of this revision.Aug 12 2019, 10:32 PM

hmmm, now that i think about it LC_ALL probably needs a .UTF-8 suffix or something to be correct

But OTOH this is working fine for me.

comments?

asemke added inline comments.Aug 17 2019, 9:19 AM
autotests/kxmlgui_unittest.cpp
1089

does this test work? The name of the month is "январь" in russian, not "января".

aacid added inline comments.Aug 20 2019, 9:10 PM
autotests/kxmlgui_unittest.cpp
1089

Yes, it may surprise you, but i did actually run the tests before submitting this code change.

ltoscano added inline comments.
aacid updated this revision to Diff 64176.Aug 20 2019, 9:44 PM
aacid edited the summary of this revision. (Show Details)
aacid removed a subscriber: ltoscano.

update commit log

asemke added inline comments.Aug 23 2019, 7:14 AM
autotests/kxmlgui_unittest.cpp
1089

there is no declension in Russian for the nominative case. The name of the month is январь and not января, but it is первого января (on January 1st) and not первого январь.

https://doc.qt.io/qt-5/qlocale.html#monthName - QLocale must return the name of the month, meaning the nominative case and not one of its declensions.

1089

The question was rethoric. I was rather surprised about the validnes of the check you did here.

yurchor added inline comments.
autotests/kxmlgui_unittest.cpp
1089

AFAIK this is broken on Qt level. Cf. calendar widget in KOrganizer (Ukrainian)

https://bugs.kde.org/show_bug.cgi?id=256952

There are new specifiers for the primary and alternative month names in glibc but Qt does not implement them (must be something like "LLLL YYYY" instead of "MMMM YYYY" in formatting). Rafal Luzynski (the author of the glibc patch) in a private message (2018-01-25) promised me to send the patch for Qt but this has not happened yet.

asemke added inline comments.Aug 23 2019, 9:15 AM
autotests/kxmlgui_unittest.cpp
1089

This is maybe not Qt but the locale defintion files which are probably distro specific. I just checked on SLES and on openSuse.

for ukrainian:

LC_TIME=uk_UA.UTF-8 locale mon
січень;лютий;березень;квітень;травень;червень;липень;серпень;вересень;жовтень;листопад;грудень

for russian:

LC_TIME=ru_RU.UTF-8 locale mon
Январь;Февраль;Март;Апрель;Май;Июнь;Июль;Август;Сентябрь;Октябрь;Ноябрь;Декабрь

This is, except of capital letters for ru_RU, correct.

On Mac I get however

січня;лютого;березня;квітня;травня;червня;липня;серпня;вересня;жовтня;листопада;грудня

and

января;февраля;марта;апреля;мая;июня;июля;августа;сентября;октября;ноября;декабря

which is possessive case and is wrong if you reffer to the name of the month itself.

@aacid on your distribution you'll most probably get the same output as on my Mac. Under the assumption that Qt evaluates the locale definition files, your test will probably fail on other distributions which do this correctly.

asemke added inline comments.Aug 23 2019, 9:22 AM
autotests/kxmlgui_unittest.cpp
1089

@aacid the discussion about declensions in slawic languages is not relevant to your patch I'd say. Maybe it's better to use in the test a language like German or any other languages where we don't have this additional complication.

The original problem in LabPlot was reported by a windows user. The proposed fix won't fix the problem on windows. I think the only way to get the proper strings on Windows is to get the current language of the application, to create a QLocale with the proper language and to use QLocale::toString(const QDateTime &dateTime, const QString &format)... If this is correct, then we're are back to my original question I asked on IRC/Matrix - how to determine the current application language?

aacid added a comment.Sep 2 2019, 7:52 PM

The original problem in LabPlot was reported by a windows user. The proposed fix won't fix the problem on windows. I think the only way to get the proper strings on Windows is to get the current language of the application, to create a QLocale with the proper language and to use QLocale::toString(const QDateTime &dateTime, const QString &format)... If this is correct, then we're are back to my original question I asked on IRC/Matrix - how to determine the current application language?

Are you saying that the old code actually half works on Windows?

I find that surprising since it means that setting the LANGUAGE environment variable on Windows does things, which according to a quick internet search doesn't seem to be the case

asemke added a comment.EditedSep 14 2019, 7:45 AM

The original problem in LabPlot was reported by a windows user. The proposed fix won't fix the problem on windows. I think the only way to get the proper strings on Windows is to get the current language of the application, to create a QLocale with the proper language and to use QLocale::toString(const QDateTime &dateTime, const QString &format)... If this is correct, then we're are back to my original question I asked on IRC/Matrix - how to determine the current application language?

Are you saying that the old code actually half works on Windows?

What works on windows well is switching of the application language in general:

Here you see the current release candidate running on windows. The windows desktop is German, the application language in LabPlot was set to Ukrainian. This works well. What doesn't work is the handling of QDate/QDateTime that is shown in the menu on this screenshot and marked red. Originally this problem was reported to us for the German-English combination (desktop in German, application language English).

I find that surprising since it means that setting the LANGUAGE environment variable on Windows does things, which according to a quick internet search doesn't seem to be the case

I don't understand the whole mechanism here now but I see that kswitchlanguagedialog_p.cpp writes the new language into the new file klanguageoverridesrc. The content of this file for the example above is

[language]
labplot2=@ByteArray(uk:en_US)

I assume, based on this information, and not on the value of LANGUAGE which is not existing on Windows, the i18n-stuff is properly initialized and we show the correct strings.

Btw, klanguageoverridesr is put into QStandardPaths::GenericConfigLocation which is C:/Users/<USER>/AppData/Local on Windows.I'd say this is wrong and needs to go into the Roaming folder.

The original problem in LabPlot was reported by a windows user. The proposed fix won't fix the problem on windows. I think the only way to get the proper strings on Windows is to get the current language of the application, to create a QLocale with the proper language and to use QLocale::toString(const QDateTime &dateTime, const QString &format)... If this is correct, then we're are back to my original question I asked on IRC/Matrix - how to determine the current application language?

@aacid I solved this problem in 7a10577b52504f6466ecaaedefc8db8d84ffc3d9. This is not really nice but it works and I accept this hack, at least as a temporary solution, since we want to do the next release of LabPlot soon...