Review Request 111178: KSwitchLanguageDialog: Reconsider how KLocalizedString is initialized

[Chusslove Illich]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111178/#review34888
-----------------------------------------------------------


Regarding the part in ki18n.

On the technical side:

Rather than doing configuration reading from new initializeLanguages
function, it should be done inside existing
KLocalizedStringPrivateStatics::initLocaleLanguages. initializeLanguages
should not call KLocalizedString::setLanguages at all, but only trigger
creation of KLocalizedStringPrivateStatics (by calling staticsKLSP I guess).
Inside KLocalizedStringPrivateStatics::initLocaleLanguages, configured
languages should be inserted after those from KDE_LANG environment variable
and before those from other environment variables, as that is the
traditional priority.

I also don't like setting the LANGUAGE environment variable. Why is that
necessary? In fact, it won't even work, due to a dirty trick ki18n is doing
internally. But before going into that...

On the philosophical side:

ki18n is a Gettext wrapper. As much as possible it should behave as pure-
Gettext translations would, plus advantageous "extras". In KDE3 and in KDE4
(for the most part), KDE was primarily thought of as a desktop environment,
and there one of the "extras" was heeding KDE's (the desktop environment's)
specific language settings. Hence the above mentioned priority chain of
KDE_LANG, KDE config, Gettext environment variables.

In KF5, however, the KDE desktop environment does not exist from the point
of view of frameworks. Each framework should be usable in a reasonable way
on its own, outside of a KDE desktop environment (as in a desktop
environment produced by the KDE community). So I'm wondering if ki18n should
at all continue to heed any non-Gettext language settings. For example,
imagine someone runs a ki18n-using application in a random desktop
environment, which does properly set up Gettext translations, but there is
also a leftover KDE/Qt-specific configuration; then, the ki18n-using
application would suddenly behave weirdly.

In particular, ki18n should not be trying to force settings on other
translation systems. Other translations systems should be configured on
their own, or there should be one global (desktop environment's) thingy that
configures them all, including, but separate from, ki18n.


- Chusslove Illich


On June 22, 2013, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111178/
> -----------------------------------------------------------
> 
> (Updated June 22, 2013, 5:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> -------
> 
> While looking at the code, it seems clear that it was something we all knew we had to think about but it was being delayed.
> Before I asked Andrea why he was stuck on so many tasks and one of them was the move of the KSwitchLanguageDialog (KLanguageButton epic).
> 
> What we did was to port the code in the dialog to read the values from QLocale, relying on KLocalizedStrings' hook to initialize QLocale properly.
> So we added that hook that reads the configuration that knows what language should be used to override the settings that Qt will use, which is the LANGUAGE env var.
> 
> NOTE: we removed the code that, after saying that the application should be restarted, tries to change the language on the fly. It didn't work well (the new things were translated, but not the old things).
> 
> This is an important change, because:
> - We use QLocale (thus $LANGUAGE env var) to define what language is being used
> - We will have to make sure how to map from QLocale naming to KDE naming (see all_language.desktop).
> - The languages KCM and KDE (kded, plasma, startkde... one of those) initialization will have to make sure that LANGUAGE will be correctly set in the KDE sessions
> 
> Thoughts?
> 
> Albert and Aleix
> 
> 
> Diffs
> -----
> 
>   kdeui/dialogs/kswitchlanguagedialog_p.cpp 7f5fe95 
>   staging/ki18n/src/CMakeLists.txt 8a40160 
>   staging/ki18n/src/klocalizedstring.cpp f8b44b9 
> 
> Diff: http://git.reviewboard.kde.org/r/111178/diff/
> 
> 
> Testing
> -------
> 
> not much
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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