Review Request 112292: Make KLocalizedString::isApplicationTranslatedInto and QLocale::uiLanguages compatible

[Chusslove Illich]

> 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.

Posted the review for KLocalizedString::availableApplicationTranslations:
https://git.reviewboard.kde.org/r/112401


- 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 at 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130831/5bbe079f/attachment.html>