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