> [: Kevin Ottens :] > [ki18n not being tier 1] Means the set of frameworks which will use ki18n > will be reduced though. Maybe not a big deal, our needs for advanced i18n > features are likely not as high there than in applications (I'm unsure > about that statement honestly).
I'm not terribly certain on that either, but so far it seems to me that advanced features are mostly needed in higher-level parts of kdeui (dialogs), kutils, kparts, and widgety parts of kio. If I understood, these should be tier 3 onwards. > For locale it should be QLocale really. KLocale is likely to disappear at > some point. QLocale might not fulfill all your needs yet, but we'd need to > know what you miss sooner than later. I don't have in mind anything in particular here. If a locale provider is good enough for KDE software in general, then it is good enough for ki18n. I would put it the other way around: *if* there will exist KLocale, then it should do something above QLocale for KDE in general, and then ki18n should use it too. > Regarding the config provider, what use do you have for it in ki18n? There is already an ad-hoc, custom config solution in the Transcript plugin, by which scripting can be influenced (on per-language basis). I'd also like to enable some more debugging functionality for scripting, which would be controlled through config. Maybe I will have more ideas. I don't remember why I didn't use KConfig here in the first place, and now is as good moment as any to get rid of this custom config solution. -- Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel