Re: Anyone needs switching locales and themes at runtime?

> Hugh Gibson schrieb:
>  
>>> Just for curiosity, could you roughly explain what this connection
>>> between the widgets and associated theme entries is needed for? If
>>> the widgets use it to listen for theme changes, wouldn't it also be
>>> possible to re-layout everything in case of a theme change, thus
>>> making theme switching a more costly operation in favor of overall
>>> performance?
>>>    
>>>      
>> +1 for this.
>>
>> And I've been looking into the locale stuff and I'm not sure how you
>> would manage locale loading at runtime without having to have at least
>> some of the class structure that is present at the moment.
>>
>> You still need to indicate which strings can be translated, how plurals
>> are translated, and how complex strings are formatted (using %1, %2 etc).
>> The natural place for these is where the string is created. So you still
>> have to have all the existing calls to tr, trn, and trc. However, these
>> would just return a translated string rather than a localised string
>> object.
>>
>> It seems to me that there are two issues here:
>>
>> 1. Writing code to correctly handle language changes.
>> 2. The overhead of being able to dynamically change language.
>>
>> You are trying to remove the potential altogether by arguing that the
>> runtime overhead of the dynamic changes is too big due to all the
>> localised string objects.
>>
>> Why not compromise: have the potential for static translations where tr,
>> trn, trc just look up the appropriate string in the translation file and
>> give that back. That will reduce the number of objects and should make
>> applications run faster. It will use the existing function calls and
>> translation structure which you have to retain anyway.
>>  
>>    
> 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.
>  

> I'll keep you updated.
>  
>> But don't remove the code that sets up localised strings. Yes, you still
>> have to do the hard work and make sure that dynamic localisation works
>> for some controls but there is less pressure for that and classes could
>> be marked as supporting it or not. That gives more time for you (or the
>> community) to modify the classes.
>>  
>>    
>
> Best Fabian
>
>
>