----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112292/#review38740 -----------------------------------------------------------
Question is, why should it go into this function and not say into others that also accept a language string? Maybe this should go there somewhere as a static helper function? I mean yes, we are using this function from somewhere whose input is uiLanguages but maybe the fix is calling that "new" helper function from there? Or adding this code that checks the input format to all of the KCatalog functions that accept a language as string? Or? Chusslove, you there? What's your opinion? - Albert Astals Cid On Aug. 27, 2013, 1:14 p.m., Vishesh Handa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112292/ > ----------------------------------------------------------- > > (Updated Aug. 27, 2013, 1:14 p.m.) > > > Review request for KDE Frameworks, Albert Astals Cid, Aleix Pol Gonzalez, and > Chusslove Illich. > > > Description > ------- > > Make KLocalizedString::isApplicationTranslatedInto & QLocale::uiLanguages > compatible > > QLocale::uiLanguages returns "lang-script-country" whereas KCatalog > expects the format to be "lang_countr@script". We need to convert the > format before checking if the corresponding catalog exists. > > > Diffs > ----- > > staging/ki18n/src/klocalizedstring.cpp eab9216 > > Diff: http://git.reviewboard.kde.org/r/112292/diff/ > > > Testing > ------- > > Limited testing done. My QLocale::uiLanguages() returns "en-US" which is > correctly converted to "en_US". I haven't tested it with anything else. Any > tips on how I should go about testing this? > > > Thanks, > > Vishesh Handa > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
