Re: Anyone needs switching locales and themes at runtime?

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