> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
