I'm not saying one solution is right and everything else is wrong, I
think we should explore the tradeoffs.

Ok, these are the technical options as I see them -
1. Alternative A - every constant string that is displayed is sent
translated, every computed string is computed via a message that also
handles translation.
2. Alternative A + Andreas-style implicit translation - some magic used
to replace the constants, so that constant strings don't need to be sent
anything in particular. Computed strings still need to be computed, of
course. This approach was considered "too magic" by Diego, I don't have
an opinion yet. 
3. Alternative B - GUI translates any strings it gets, unless explicitly
told otherwise. This handles constant strings. Computed strings still
need to be computed and translated. I previously thought that it would
be neccesary to have a separate API to tell the GUI not to retranslate
already translated strings, but assuming it will default to not
translating things it can't find, that's not needed.

I think its clear that alternative 2 is nice because it doesn't require
changing any code. I also don't see any specific problem with this
magic. Of course, magic does have a way of taking its toll when you
don't expect it.

Between 1 and 3, we need to see the difference to different
applications.
A. Code in the image
A1. Diego has done the work, it is simple to understand and therefore
not a problem to get approved.
A3. Requires some changes to interface frameworks.
B. All other code in the world (SqueakMap, code ported from other
dialects..)
B1. Every application needs to be adapted along the lines of Diegos
work.
B2. Additional effort is required only to adapt computed strings.

> 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.
This is well understood by all parties to this discussion. To me what
this says is that we should try to standardize the string-building
mechanisms on ones that handle translatability, like babel provides
(maybe in a VW or ANSI compatible way). But handling computed strings is

A. A problem all alternatives share. 
B. A problem not all applications share. So options 2 or 3 would
probably make quite a few applications tranlatable out of the box.

> So in short, in my understanding the "view translation" is a fundamentally
> flawed model here. 
IIRC, you mentioned how the ANSI compatibility package would remove some
arbitrary costs to porting efforts between dialects. I care about that
too. We'll definitely get translatibility for applications - but maybe
we can do so in a way that doesn't add new costs to porting. That's my
goal. Translating views are just one way to get it, I'm open to
alternatives.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> 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 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.
> 
> 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.
> 
> 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