> > Right, we'd have to keep the "tr", "trn", .. calls and most of
> the infrastructure anyway. I'll give your approach a try. Maybe we
> > could externalize locale switching support into a mixin and make
> > optional this way. I will do some prototyping with this approach.
> >
> On a second thought I found a serious problem this this approach.
>
> Suppose we call a method like this:
>
> this.setText(this.tr("Hello %1!", name));
>
> if "tr" returns a static string, there is no way for the widget to
> convert it back into something that can be translated into a
> different locale.
Why did you want a static string converted back to a value for
translation?
I envisaged two scenarios:
1. Static loading of strings.
In this case this.tr will use the current locale to look up the
translated string, do the substitution (as above) and return the string.
That should work fine. No additional object instances are created and the
translation works using the current locale.
2. Dynamic loading.
This works as now - i.e. an instance of qx.locale.LocalizedString is
created and evaluating the string value is carried out in "toString".
Instances have to listen for changes to the locale and reload their
values. All localised strings will re-evaluate their current values but
using the new locale.
I don't see any problems with this. It would be a compile-time option. If
you want dynamic translation you enable it and take the hit of extra
objects. If you want fast and lean, you disable dynamic loading and
predetermine the locale and runtime.
Hugh
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
