Review Request 118692: Fix reading of entries for language/country combinations
Matthew Dawson
matthew at mjdsystems.ca
Wed Jun 18 18:06:41 UTC 2014
> On June 18, 2014, 3:04 a.m., Oswald Buddenhagen wrote:
> > i don't see that you are proactively excluding the @modifier. it would seem that it's effectively part of the country, and the test works only because it's expected to fall back to de instead of de_AT anyway.
> >
> > there is another consideration ... matching follows a strict hierarchy, so an entry for de_DE will never be used to satisfy a request for de. arguably, that's correct - it becomes obvious when there is both de_DE and de_AT to choose from. even less, de_DE is used to satisfy a request for de_AT, which seems even more obvious. otoh, this stuff is mostly used for translating desktop files, so one can argue that being strict puts unreasonable demands on the population of the entries. i suggest you talk to albert.
Actually, QLocale doesn't give us a way to get the @modifier information currently. John mentioned that proper support is coming eventually, but right now we have no way of extracting it. Once support is available, @modifier support should be added. Right now any @modifier is stripped away, and any translation using it will be passed over.
I'm going by the specification here: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html that this is the right behaviour. I'm not sure what your second paragraph is saying, so I'm not sure how it deviates from that link. I tried finding a policy about desktop files and translation for KDE, but my Google-fu didn't find anything. I would think we should move towards following the spec above as much as possible, otherwise our menu entries will show up differently in other desktops.
- Matthew
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118692/#review60351
-----------------------------------------------------------
On June 16, 2014, 4: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, 4: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/41baab4e/attachment.html>
More information about the Kde-frameworks-devel
mailing list