asemke added a comment.

  In D23119#524720 <https://phabricator.kde.org/D23119#524720>, @aacid wrote:
  
  > In D23119#519676 <https://phabricator.kde.org/D23119#519676>, @asemke wrote:
  >
  > > 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:
  F7349563: labplot_ukrainisch.png <https://phabricator.kde.org/F7349563>
  
  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 
nedds to go into the Roaming folder.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

Reply via email to