[email protected] Re: Internationalization not working
Hi. > I think most people that are hitting issues with the translation > support, are wanting to have translations that simply can't be marked > in the application source code. > Instead, I assume, most people fetch this stuff from the database. On > the other hand, most love the fact that all messages of qooxdoo > widgets already have translations. 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. 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. 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. br, flj ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
