Re: Anyone needs switching locales and themes at runtime?

>>> 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