RFC: i18n: strict translation call-to-catalog mapping

[Chusslove Illich]

> [: Thomas Zander :]
> First, any Qt tr call has a context (typically the class name), am I
> correct that i18n() still does the same thing?

It doesn't: context is added manually, when judged or reported to be needed.
(And this is how it always was.)

> Can you explain a bit more how things are untollerable? In my experience
> the current system scales rather well, but I could definitely be missing
> details here.

Conflicts happen very rarely in practice. But when they do happen, it goes
like this. After some time, some user will report "wrong translation of X"
in app Y. This will be forwarded to the translator of that language of app
Y, who will point out that in Y PO file everything is fine, translation is
proper. This will puzzle the programmer. Eventually, the problem will reach
someone who knows what's going on. That someone will tell to someone to tell
the programmer to add the context to message in Y PO file. The programmer
will do it, and case closed. Technically, it does scale rather well. But, I
don't know if you share this feeling with me, it's a ridiculous thing to
begin with. Especially since plain Gettext-based code has never had such
conflicts.

There is one more annoying problem with current system. One has to make sure
to call KLocale::insertCatalog() at proper place in the library code, so
that no i18n call within the library can be reached before
KLocale::insertCatalog(). This often results in lack of translation for
certain strings in app Y, and then we have to look for which X put
KLocale::insertCatalog() in wrong place (or put at all) an fix it. This is
also something that was never a problem in plain Gettext-based code.

> Next to that, I'm wondering how many catalogs we expect any normal app to
> actually load at runtime. I would think that most processes load 3 at most
> currently, maybe double that in frameworks.

In principle as many as there are separate pieces of code (libraries,
plugins) within the process, as each will (should!) draw in its own catalog.
For "plain" KDE app, currently that is at least 7: kdecore loads 6, the app
1. On the other end of the range is KDE PIM: KMail itself loads 16 catalogs,
atop what comes from kdepimlibs and kdelibs.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120404/4bb6f188/attachment.sig>