> 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?
>
> Chusslove Illich wrote:
> 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 Illich wrote:
> Having in effect said that language codes for ki18n can be anything
> (simply
> used to construct directory path to test), why not have a function in
> ki18n
> like KLocalizedString::availableApplicationTranslations? It would go
> through
> all set data dirs and collect language codes from existing
> ${DATADIR}/locale/<language>/LC_MESSAGES/fooapp.mo paths, and return this
> list. This functionality would clearly belong to ki18n, and the code such
> as
> in KLanguageButton would then have an easier task, of only having to pair
> the language codes from different translation systems for display to user
> as
> a single known (and translated) language name entry.
>
>
> Albert Astals Cid wrote:
> FWIW That's what i kind of suggested in the other review Vishesh did.
>
> Chusslove Illich wrote:
> Posted the review for KLocalizedString::availableApplicationTranslations:
> https://git.reviewboard.kde.org/r/112401
Discarding this as it is no longer required.
- Vishesh
-----------------------------------------------------------
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
