Hi Dietrich,
I suppose the thread you've linked to still holds true basically. The
approach of qooxdoo's translation system is to keep translations "close to
the code", so that in the generated app translations are bundled with the
code that actually uses them. Hence the need to internationalize libraries
on their own. I think this makes sense in most cases.
The drawback is that of brittle coupling of application and libraries. The
application depends on the foresight of the library maintainer. What if
your application want to use a language X which was not included in the
library?! This shouldn't be a big issue either, as you always can fall back
on the library's sources and edit the configuration and the translations to
suit you.
But, as you found out, it is also hard to 'override' in the app existing
translations that come with a library. In this case, I think your approach
with a mixin is quite viable. As you are using .addTranslation() you're
still hooking into the resolution process of the this.tr() calls at run
time. But as you are using keys that the library already might have
provided ("item" in your example) you are relying on the fact that your
translations take precedence. I'm sure you tested this and it worked, but
you are sort of relying on an internal implementation detail that might
change in the future.
But taking this as a given, what you could try is you could combine your
idea with qooxdoo's translation service. You could make your translation
map generic, with no hard-coded translations in it, e.g. like this:
getApplicationTranslationMap : function(locale) {
var map = {
"item" : this.tr("item")
};
var m = {};
for(var id in map) {
m[id] = map[id];
}
return m;
}
This relies on the fact that "item" is mapped to the translated string
according to the locale that is in effect at run time.
This would make your mixin generic and you could include it into the APPLES
and PEARS applications unchanged. Then just do the normal cycle of running
'translation' and translating the "item" key differently in each
application. You might run into situations where the translation of the app
gets overridden by the translation of the library, I'm not sure. See how it
goes!
You would still need to keep track of the keys in your translation map by
hand (short of generating it from the library's .po file ...). But there
are other projects that also have code (e.g. in the form of a static class)
just to list keys they want to register with translation, so you are not
far off.
HTH,
Thomas
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
