KSwitchLanguageDialog: Reconsider how KLocalizedString is initialized

Review Request #111178 - Created June 22, 2013 and submitted

Information
Aleix Pol Gonzalez
kdelibs
Reviewers
kdeframeworks
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
not much
Albert Astals Cid
Chusslove Illich
Kevin Ottens
Aleix Pol Gonzalez
Kevin Ottens
Commit Hook
Aleix Pol Gonzalez
Review request changed

Status: Closed (submitted)

Albert Astals Cid
We should add a #warning or an epic item or something about the fact that "it doesn't work" as i noted in my first comment in the review.
  1. I added one, what do you think?
    
    http://community.kde.org/Frameworks/Epics/kdelibs_cleanups
Loading...