Hi Andreas...

You put my ideas on words better than me, thanks!

> Hi Daniel,
>
>> 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?
>
> The problem is the model for translation. I don't argue that the view
> translation will work for many situations - but in _all_ of them the
> model translation will work too and the model translation covers
> situations which the view translation can't handle.
>
> Given that I wonder what the goal of using view translations is after
> all. If it's only to reduce the lines of code being touched

IMHO The lines of code is not problem because:

- The modification, most of the times, is trivial and the few cases where
is not trivial are the cases that need to be handle in the model anyway.

- The biggest work to modify the strings in a 3.7 image is already done and
it's being tested for weeks in the Small-Land's image.

> then
> (again) let me point out the approach I was taking before - no code was
> harmed in the making of those translations. It does require a bit more
> "external support" as you can't augment the strings with #translated
> calls (or actually, maybe you even could...) but it didn't do any
> noticable modifications to the code (however, as I said in the IRC
> snippet there are some arguments that can be made for explicitly
> tagging strings by calls like #translated).
>
> If the goal is to have applications being blessfully unaware about
> translations then I would like to point out that this won't work
> anyway. A great example is here:
>
>   'Button Properties for ',myTarget name
>
> If you have that kind of construction it is impossible to localize it
> without changing code. That's just the way it is. An application (or
> framework) writer needs to anticipate the need for translation of
> various phrases and if she doesn't then that code needs to be touched.

Let me put another example: The English phrase 'start' has 2 meanings
(start the verb or start the noun).  These 2 meanings has different Spanish
translations ('empezar' or 'comienzo').  Nobody but the model writer knows
the meaning and the only solution (or the only I found) is to mark the
original string with more information, something like that:

   'start {noun}' translated.
or
   'start' asNounTranslated.
or
   'start' asNoun translated.

In this case Babel can look for the translation of 'start' as noun and in
case the specific translation for the noun is not found it can answer the
generic translation for 'start'.

> So in short, in my understanding the "view translation" is a
> fundamentally flawed model here. Don't go down this path - it puts the
> responsibility into places where it doesn't belong (the app is
> responsible for "localizing itself" not the menu). If you are concerned
> about the lines of code being touched then let's look at this specific
> issue.

And, as I said before, most of the dirty work is already done.

> It would be nice if you could clearly state what you are expecting from
> the view translations. I am not sure I got the gist of your arguments
> correctly.
>
> Cheers,
>  - Andreas

Cheers,

Diego