Review Request 111178: KSwitchLanguageDialog: Reconsider how KLocalizedString is initialized

[Kevin Ottens]

> On June 24, 2013, 2:18 p.m., Kevin Ottens wrote:
> > staging/ki18n/src/klocalizedstring.cpp, line 44
> > <http://git.reviewboard.kde.org/r/111178/diff/2/?file=165134#file165134line44>
> >
> >     Wondering, would that be something for the QPA platform theme then? So that ki18n stays passive, and this code is only activated if the app runs inside a KDE workspace?
> >     It would also avoid nicely ki18n dependency on kconfig (keeping then both tier1).
> 
> Chusslove Illich wrote:
>     Since the feature is on the application level, it should (?) still be
>     available when the application is not running inside KDE workspace. Thus I
>     mentioned that the framework providing the in-application language choice
>     should also do what is necessary for all expected translation systems.
>     
>     ki18n also depends on KJS, and it needs to start depending on a locale
>     provider (for formatting string arguments), so on KLocale. Removing KConfig
>     dependency alone then wouldn't make it tier 1.
>

Well, that's the thing I'm wondering... should it still be available outside a KDE workspace? I'm not so sure.

As for the framework providing the in-application language choice it's pretty much contained by KSwitchLanguageDialog and friends, so likely it has to do something about tr() too, but that's about it I think. I don't see people using more that tr and ki18n in practice.

As for ki18n any chance to make it use QtScript instead of KJS? And same question for the locale provider, shouldn't it be QLocale? (ok, I'm getting slightly off topic here, but there's already a patch attempting to use QLocale instead of KLocale)


- Kevin


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


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/20130625/c2c806ff/attachment-0001.html>