Thank you Thomas,
this way it would be able to use the po files created by generate.py
translation. Never thought about using this.tr in the map itself. Thank
your for the hint!
But shouldn't calling
qx.locale.Manager.getInstance().addTranslation(locale, map) at some
point after initialization override existing translations?
The comment for addTranslation in qx.local.Manager says:
* If <code>languageCode</code> already exists, its map will be
updated with
* <code>translationMap</code> (new keys will be added, existing
keys will be
* overwritten).
See
https://github.com/qooxdoo/qooxdoo/blob/release_5_0_1/framework/source/class/qx/locale/Manager.js#L318
Regards
Dietrich
Am 19.10.2015 um 22:13 schrieb thron7:
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 <http://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 <http://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
