Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Andre Heinecke]

> On Feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would nativeLanguageName ever return empty?
> 
> Andre Heinecke wrote:
>     I've just checked. It's a Windows thing. qlocale_win calls windows API getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx ). So Qt Developers would probably (and rightly) say "This is a Windows bug" and Indeed this might be fixed at some point in the far Future in Windows.
>     
>     But my Observation is Qt does not (and for Windows apparently can not) guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should try to handle this. As I don't know how this is for other platforms and it only adds a tiny overhead I also don't think this should be Ifdefed for Windows.
> 
> Albert Astals Cid wrote:
>     well, reading the documentation of the function never mentions it can be empty, and given all languages probably have a way to call themselves I as an api user find it surprising it returns empty. 
>     
>     sure I can agree it is a Windows bug, but why workaround it in every single call to nativeLanguageName instead of inside Qt code? 
>     
>     I mean, we probably even have this problem in other KDE code.
>     
>     And sure, Qt takes a while to update/release so temporarily we may want this workaround committed so our users get the fix earlier but I would really appreciate if you could create a MR for Qt that either documents that nativeLanguageName can return empty or one that makes sure it is not empty by doing the same fallback we do here.

I'm not a qt contributor and this issue is not important enough to me to spend the time with this. I'm pretty unwilling to work more on this. It would be easier just dropping the exotic languages for which this problem exists. (Although I really love the Plattdeutsch localisation of Kleopatra ;-) )
As a compromoise I've reported a bug https://bugreports.qt.io/browse/QTBUG-51323 and mentioned this in the patch.

The only other usages of nativeLanguageName in frameworks are sonnet and kconfigwidgets/klanguagebutton.


- Andre


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/#review92630
-----------------------------------------------------------


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> -----------------------------------------------------------
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> -------
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as a fallback. The idea is that a non native Name is better then no name (and a blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I think this fallback makes sense.
> 
> 
> Diffs
> -----
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> -------
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> ----------------
> 
> Dialog before the patch
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160223/6ff5e410/attachment.html>