Review Request 117132: Use QLocale for figuring out what languages we're translated into

[Chusslove Illich]

> On March 28, 2014, 4:43 p.m., David Faure wrote:
> > Looks wrong, QLocale looks at .ts/.qm files while we mostly use .po/.gmo files - different translation system.
> > 
> > Also doubly wrong because uiLanguages() returns the user preferences (e.g. for me "en, fr"), which has nothing to do with "how many languages are actually installed" (e.g. there could be about 54).
> 
> Aleix Pol Gonzalez wrote:
>     Then should we get a method to ask KLocalizedString what languages we have available for the application.
>     
>     In any case entry.desktop files are installed at bulk by kde-runtime, so it's actually already broken in KDE4. Actually, I get to ask to switch language and then I get to only choose the one.
> 
> John Layt wrote:
>     Yes, QLocale::uiLanguages() returns the list of user preferences, i.e. the LANGUAGE or LC_ALL or LC_MESSAGES or LANG envar on Linux (in order of preference).  The list of available KDE translations is different.  KLocalizedString has a new method for 5.0 availableApplicationTranslations(), but the docs state:
>     
>          * Get the languages for which there exists the translation catalog file
>          * for the set application translation domain.
>          *
>          * The application domain is set by \c setApplicationDomain.
>          * If the application domain was not set, empty set is returned.
>          * If the application domain was set, the language set will always
>          * contain at least the source code language (<tt>en_US</tt>).
>     
>     I suspect as we want the languages the user can switch the application into then it should be the right method provided the application domain is set by the application.

I missed that this patch is about translations available for a given application only. I switched to "globaly available languages" story, since it was again about entry.desktop files. And relying on them in this context was not very purposeful (i.e. Aleix's comment above).

Switching to KLocalizedString::availableApplicationTranslations here makes sense to me as well.


- Chusslove


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117132/#review54463
-----------------------------------------------------------


On March 28, 2014, 12:21 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117132/
> -----------------------------------------------------------
> 
> (Updated March 28, 2014, 12:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> -------
> 
> Instead of asking the file-system what languages the application is translated into, ask QLocale what languages we have available instead.
> 
> 
> Diffs
> -----
> 
>   src/khelpmenu.cpp 4f6ce7b 
> 
> Diff: https://git.reviewboard.kde.org/r/117132/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140409/68392b05/attachment.html>