NB: Don't reply on digests, try to reply on the original posting/thread. > Re: Internationalization not working > ... > The typical issue with have with i18n/l10n is that every single > customer has different ideas and requirements. Until now, there was > no single case where the translation mechanism provided by qooxdoo > was usable as at is, without additions or modifications.
You mean, for your projects?! > One of the most frequent requests, even from customers not wanting to > have translations in a database, was that text files should be > external to the compressed qooxdoo application. They often need to > send out translation files to different translators, specialized in > different languages, add new translations without redeploying the > app, and the like. Neither keeping translations in a database, nor > having them compiled into the large qooxdoo-generated JS is an > option. Our concept is that translations are maintained in .po files (in the source/translation/ directory). But they have to be in place at build time, to check what is in sync with the current source code. There is no concept for adding translations or entire languages after the app has been generated. But you can have translations generated in separate files, so they don't blow up the code files. > > I can think of a mechanism which IMO would satisfy any possible need: > a private stack of translators for each object. The stack should > initially contain only a null translator, which returns what it gets > as translation, and the default qooxdoo translator. Whenever a > component isn't satisfied with what's on the stack, it can add its > own translator implementation. The translation mixin can then call > the top of the stack first, and continue going deeper into the stack > until one of the translators on the stack accepts the responsibility > of translation. Only the mixin needs to be changed for this mechanism > to work, all the rest is addition (a generic translation interface > plus the implementation of two translators - a null translator and an > adapter for the existing translator) and implies no changes to other > code. Even the generator can go about extracting strings exactly as > it does now. However, the mechanism would need to go into the Object > class. Sounds interesting, although you would probably implement custom translators better by subclassing, rather than by a stack. T. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
