> 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. > > > Kevin Ottens wrote: > 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) > > Albert Astals Cid wrote: > To be honest, as a user I'd be wildly confused if the menu item that says > Help->Change Application Language, only works when in KDE Workspace > > Kevin Ottens wrote: > Well, obviously khelpmenu wouldn't show the entry in that case. > > Albert Astals Cid wrote: > To be honest, as a user I'd be wildly confused that a menu item is shown > or not shown depending on the desktop environment I'm using. > > Aleix Pol Gonzalez wrote: > Ok, then we have a problem: > - We don't want ki18n to decide what language we run (chusslove) > - We don't want kde's QPlatformTheme to decide what language we run > (albert) > > Then who decides what language we are running? Only $LANGUAGE? > That's a problem because not only this button won't work, but we'll be > losing quite some features, potentially... > > Chusslove Illich wrote: > I say that the framework which contains the button should decide. I.e. it > should make all necessary settings before the respective translation > systems > initialize themselves. (But, to remind, I also don't object ki18n doing > this > at the moment, to avoid breaking the head with it right now.) > > As for ki18n switching to QtScript and QLocale, I'd rather not do it as > long > as there exist KDE-specific/improved frameworks providing the > functionality. >
Ok, so to understand what I should do myself. I should move it to initLocaleLanguages? Shouldn't I try to make sure that it is called before the application starts to be rendered? It's important that both ki18n and tr don't ever use a different language. Also please move the KJS vs QtScript into a different thread (or just an Epic in kdelibs cleanup). It's a huge task, though. - Aleix ----------------------------------------------------------- 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
