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

[Thomas Zander]

On Tuesday 03 April 2012 20.05.14 Chusslove Illich wrote:
> At present (and since forever) it is practically indetermined from which
> catalog exactly an i18n() call will fetch the translation. All loaded
> catalogs in the process are tried in mostly arbitrary order, depending when
> and which library loaded them, and the first one that contains the
> translation is used.

Hmm, this looks bleak, I'm kind of surprised by this, though. Let me explain;

First, any Qt tr call has a context (typically the class name), am I correct 
that i18n() still does the same thing?
In that case the context AND the translation string together are searched 
through the collection of catalogs.
I'm wondering if you have any numbers on how often conflicting class names (and 
thus context names) appear in our frameworks.

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.

> it becomes untollerable in the scope of
> Frameworks. So the question is how to fix this.

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.
-- 
Thomas Zander