Andreas Raab <andreas.raab at gmx.de> wrote:
> Hi Diego,
> 
> > Against my feeling I'll take in my hands the work to try the famous
> > "Alternative B" (It means to make the translation in the widgets).
> 
> But why would you want to do this??? 
Probably because I asked we explore this alternative a little.

> I completely agree with your original
> POV - it's the model that needs to be translated not the view! Having "a few
> general translation methods" in a few cases just isn't going to cut it -
This is what I want to learn. If we see it stinks, I guess we'll go with
changing all the apps.

> there are way too many possible combinations of individual strings and the
> "backend translation" will only lead to endless variations of composed
> strings which absolutely require changes in the code to generally come out
> correctly.
I'm not convinced yet. AFAIK, most menus (buttons/syswin headers) are
not computed, which means that the widget just gets passed a string, and
can send it "translated" just as well as the model, but without touching
most applications. So what's the problem? how many cases do use computed
strings? is it that hard to use an alternative API in those cases that
tells the widget that translation is now happening on the application
side, and any strings are to be treated as literal?

diegogomezdeck at consultar.com wrote:
> Before going with the huge task I'd like to know what you're expecting
> exactly.
I expect to know 
1. Precisely whether it is huge, that is - what framework changes are
needed. 
2. A comparison of the application changes needed compared to
alternative A. 

Daniel