KIO progress towards tier 1 framework?

[Chusslove Illich]

> [: 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 (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130710/3a1dee04/attachment.sig>