> 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@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@latin, and a .desktop file contains Name[sr]= and Name[sr@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]
This means that localization for the said locales will be very obviously broken, given the prominence of strings from .desktop files. - Chusslove ----------------------------------------------------------- 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
