Hi Avi,

>> If we follow the idea of making the translation a responsibility for
>> the view we have to expand the protocol for all the widgets (morph,
>> mvc, html frameworks, etc) including some support to put on them
>> "expandable" strings to avoid the translation of every combination of
>> concatenated strings.  (The same idea behind the #format: method in
>> Babel but in the widgets).
>
> Rather than changing the protocol to have
> translated/untranslated/formatted versions of each method, I would
> instead increase the number of objects that respond to #translated, or
> say #translatedString.
>
> String>>translatedString
>  ^ self translated
>
> UntranslatedString>>translatedString
> "a wrapper around a string"
>  ^ string
>
> FormattedString>>translatedString
>  "a wrapper around a format string and args"
>  ^ format translatedString substituteArguments: args
>
> Then we just have to change the current UI methods to send
> #translatedString, and we can suppress translation or use formatting by
> changing the object that we pass into them.

I like the idea but this moves the translation to the model again.  In the
current version the translation-in-the-model option is handled with
combinations of #translated/#format: messages so the benefits are (more or
less) the same.

The motivation behind the idea of moving the translation to the view is to
touch less places.  IMHO it's not a big win because Squeak has a lot of
different view-frameworks (morphic, mvc, pdf/rtf generation, html
generation, STT, etc).

I have to say that I like more the translation-in-the-model because:

1) It solves the problems with 'start' as noun or verb because only the
model programmer knows the meaning.  To solve this problem in the view is
not possible so if we go we translation-in-the-view we'll have 2 concepts to
solve the translations (in view and in model).
2) It's already done and working in our Small-Land image.


Cheers,

Diego Gomez Deck
http://www.small-land.org