Diego,

> I think that you're proposing can be thought as "translation in the view"
> and the path we follow with the current version of babel is "translation
> in the model".

  Hmm.  I'm not quite sure this distinction really applies here...  It
is rather "widget creation caller vs. callee", maybe?

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

  I think we would need both.

> If we follow the idea of making the model translatable, we have to touch
> all the models (just like we made).
> 
> I think a mix is not an option. I prefer more work but clear concept and
> not a mix of concepts just to reduce the amount of involve code.  The
> changeset you give as an example (the one with 160 methods) took me just 1
> hour of work.

  I don't feel it a mix of concept... There is a single core concept
that is a dictionary look up, and rest can be considered as
wrappers.

> On the other side there are a lot of things that don't match the
> model/view separation, example: is the name of a morph view or model? what
> about the menus?

  Yes.  I agree that this is not about Model vs. View.

-- Yoshiki