> On Aug. 27, 2013, 1:47 p.m., Albert Astals Cid wrote:
> > 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?
I agree with Albert. I don't think this heuristic (which is what it is)
belongs to ki18n. Rather, it is upon the caller code to send in the language
in expected format. And the expected language format for ki18n is in fact
whatever directory name that appears as
${DATADIR}/locale/<language>/LC_MESSAGES/.
If I think of e.g. of the code in KLanguageButton, it itself should go
through guessing which languages are available and how to present them to
the user (far from trivial), and then to set up all the expected translation
systems to use this language. The expected systems are now Qt and ki18n,
but in principle could be more (maybe other platforms). So I don't think
this problem should be approached by making
LocalizedString::isApplicationTranslatedInto and QLocale::uiLanguages
(approximately) compatible.
- Chusslove
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112292/#review38740
-----------------------------------------------------------
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
