Ki18n mostly ready

[Chusslove Illich]

> [: David Faure :]
> There's no way to keep the [insertCatalog] method for source compatibility
> and implement it somehow on top of the new solution?

The problem is that insertCatalog no longer has a meaning. Its purpose was
to add more translation catalogs into the current process, and all of them
would be searched for translation on a given i18n call. While in the new
system, all i18n calls are bound to a particular catalog (either through
TRANSLATION_DOMAIN define or setApplicationCatalog).

> I'm afraid of the porting effort created by all these source incompatible
> changes. If we can minimize that, it's all for the better.

For porting, my focus was on the case where for each library/application
there exists a different maintainer who will perform the update. In this
case, it is not much effort: throw out any insertCatalog methods, replace
with one TRANSLATION_DOMAIN define in private header (for libraries and
applications) or one setApplicationCatalog call (easier alternative for
applications).

Of course, in reality there is sometimes no maintainer, or an "incidental"
maintainer with piles of other things in the queue, and then porting becomes
some effort. I'll help :)

-- 
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/20130802/082010c5/attachment.sig>