Review Request 111178: KSwitchLanguageDialog: Reconsider how KLocalizedString is initialized

Sun Jun 23 11:25:59 UTC 2013

> On June 22, 2013, 8:43 p.m., Chusslove Illich wrote:
> > 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.
> >
> 
> Albert Astals Cid wrote:
>     "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"
>     
>     True, using the existing KLocalizedStringPrivateStatics::initLocaleLanguages might make more sense, I'm confused though, it fills localeLanguages but then doesn't do anything with it and localeLangauges is only used in KLocalizedString::clearLanguages that is never called
>     
>     "I also don't like setting the LANGUAGE environment variable. Why is that necessary?"
>     
>     Because that's how Linux i18n works (e.g. is that qlocale_unix.cpp returns when you ask it about "which languages should the app run in") and we have to stop being a isle on our own and interact with the rest of the world, and KDE_LANG doens't make any sense on that regard. As you say "KDE" doesn't exist anymore as per frameworks, so if someone wants to change the language of an app, just set the LANGUAGE envvar. Of course this is linux only and a windows way ought to be found.
>     
>     "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."
>     
>     How would it run weirdly? Because it would obey KDE_LANG? Let's kill it as said in the previous paragraph :-)
>     
>     "ki18n should not be trying to force settings on other translation systems"
>     You mean the prependign setting of LANGUAGE with the KConfig of the app if KSwitchLangaugeDialog was used? IMHO you need that because QLocale::uiLanguages should return the languages we are really using.

Ok, the central issue here is not about QLocale::uiLanguages in particular,
but more generally, whether ki18n should try to propagate its own language
setting (wherever it comes from) onto all other translation systems that
might be in the process (and children processes). Other translation systems
include Qt, pure Gettext, and whatever else might be there on other
platforms.

As I said, in my opinion ki18n itself should not be doing this. On the other
hand, I agree that if the user says "I want this application in this
language", then (most of the time) that wish applies to everything in that
application's process and its children. So, I think that the framework which
is providing the user with this per-application choice, should also handle
setting up known translation systems for that to work. ki18n itself should
not read any configuration (nor KDE_LANG), instead doing the same as Gettext
does (stuff in KLocalizedStringPrivateStatics::initLocaleLanguages minus
KDE_LANG).

Now, I acknowledge that designing this outside of ki18n is an extra burden
at this point, and I don't volunteer to do it. So, to get on with the
things, I don't object having this now in ki18n. But it should be made in
this way: KLocalizedStringPrivateStatics::initLocaleLanguages should read
the config, with higher priority than environment variables (it can drop
KDE_LANG), and proposed initializeLanguages should be renamed to something
like updateLanguageEnvironment and do only:

  KLocalizedStringPrivateStatics *s = staticsKLSP();
  // ...use s->languages to update LANGUAGE...

There should be no call to KLocalizedString::setLanguages or
QLocale::uiLanguages. Additionally, I'd prefer if LANGUAGE were not touched
when nothing was read from the config, and if something was read, only those
languages to be added. New member variable in KLocalizedStringPrivateStatics
can be added for this purpose, say s->configLanguages.

You can also disregard what I said earlier about setting LANGUAGE not
working due to a dirty trick, I was wrong on that. I said it because ki18n
is modifying LANGUAGE right now (inside KCatalog) in order to trick *gettext
functions from Glibc into looking up translation language by language, so
that when the translation is found its language is known. *gettext functions
themselves do not provide this capability. But, KCatalog can, and does,
recover the original contents of LANGUAGE after the LANGUAGE-mangled
*gettext call is completed, so it will not mess up LANGUAGE externally.

- Chusslove

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

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/20130623/36b38501/attachment-0001.html>