Review Request 118692: Fix reading of entries for language/country combinations

[Martin Gräßlin]

> On June 12, 2014, 1:58 p.m., David Faure wrote:
> > Looks good; but I'm surprised that it works :) the code for using fallbacks must be in there somewhere already then? (if de_DE not present then use de). 
> > This patch is only about not skipping these two entries (de and de_CH), but how will it then pick the right one? Could it be that it works by chance, because the first one wins or something? (where first could mean "in the file" or worse "in some data structure"...)
> >
> 
> Martin Gräßlin wrote:
>     I think it works because it's the order in the file. I do not know whether there are rules on how the order has to be in the file, I simply assumed common sense which would list "de" before "de_DE" or "de_CH".
>     
>     From reading the code I didn't find anything which looked like a fallback. It looked to me like a found value is overwritten when a translated comes in. But I might have missed something.
> 
> David Faure wrote:
>     I don't trust common sense, but "scripty" orders them indeed. Just possibly not people writing desktop files by hand (e.g. distros?)... I guess the "desktop entry spec" doesn't specify ordering.
> 
> Martin Gräßlin wrote:
>     the spec only specifies the parsing, but not the writing. In fact the only example is the other way around:
>     
>      Name=Foo
>      Name[sr_YU]=...
>      Name[sr at Latn]=...
>      Name[sr]=...
> 
> Chusslove Illich wrote:
>     So... support for handling the language codes listed by David is simply gone in KF5, as it stands? More precisely, if the user has set glibc locale to sr_RS at latin, and a .desktop file contains Name[sr]= and Name[sr at latin]= (in any order), what will be read by the current implementation?
>
> 
> Martin Gräßlin wrote:
>     @latin gets removed by QLocale, so it would pick Name[sr]
> 
> Chusslove Illich wrote:
>     This means that localization for the said locales will be very obviously broken, given the prominence of strings from .desktop files.
>

@John: is there a way to get the name including the modifier out of QLocale? If no, any chance that we get this into Qt 5.4?


- Martin


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


On June 16, 2014, 10:26 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118692/
> -----------------------------------------------------------
> 
> (Updated June 16, 2014, 10:26 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure, John Layt, and Oswald Buddenhagen.
> 
> 
> Repository: kconfig
> 
> 
> Description
> -------
> 
> Fix reading of entries for language/country combinations
> 
> This fixes a regression introduced in
> 988f09bb051dca0437ecec431ee44ed5b4a560d8.
> 
> The mentioned commit ensures that if the locale is e.g. "de_DE" the
> entry "de" will be used. But this breaks if there is a translation
> for another country. E.g. for "de_CH" it would also pick the "de"
> entry.
> 
> This change now operates on both just the language code and the locale.
> If an entry with the language code is present it will be picked. If
> another entry with the exact locale is found it will be overwritten.
> 
> 
> Diffs
> -----
> 
>   autotests/kdesktopfiletest.cpp 6c3af4c2cd55b9140c0cd48526947431ceb7e798 
>   src/core/kconfig.cpp a2598f8e8fce91a8de3f34b272e15a6c280a50db 
>   src/core/kconfigdata.h fdec85dc90467560bd312b72266ef0b3f243d076 
>   src/core/kconfigdata.cpp 109063d65e97bcb7ba08cf6e5a6f3acb885fe845 
>   src/core/kconfigini.cpp a882ee31150658f3e5cfb036362ff0583f71cbd9 
> 
> Diff: https://git.reviewboard.kde.org/r/118692/diff/
> 
> 
> Testing
> -------
> 
> unit tests still pass, but my knowledge about KConfig and locales is not sufficient to be sure that this is now 100 % correct.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140618/903b6548/attachment.html>