RFC: i18n: strict translation call-to-catalog mapping
zander at kde.org
Wed Apr 4 19:00:41 BST 2012
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
More information about the kde-core-devel