Diego,

> >  Diego,
> >
> >  If I understand correctly, the description you wrote means that
> > #translatedTo:for: the essential and others are the wrappers for it. I
> > don't think it adds too much complexity;
> 
> Its a more complex concept that impact on the translator's work. (In Small-
> Land we used non-programmers translators)

  Hmm.  How about if the tool provide a drop-down list like thing that
specifys the application and the language.  Then, the tool can show
the (list of) original phrases and words in one pane, and the
translated phrase in another pane.  Probably, it is not too much
burden for the non-programmer translators.

> > on the other hand, each
> > different external packages would be able to have its own dicitonaries
> > under its control.
> 
> This is one part of the new complexity.  The external package can provide
> aSet of phrases and not aDictionary.  The Dictionary will be produced as
> the intersection between the given Set and an specific language.

  It could...  but if there are two applications and they want to
translate an original phrase differently?

  Probably this merging into a dictionary upon package loading can be
a starting point for the base image.  So, I don't strongly oppose to
it, but I can't help imagining there will be a need to fix this
later.  (But again, if so, we can fix it later.)

> BTW, Did you remember (for example) how the World's Menu works? In the
> current structure is not so easy to categorize the phrases there.

  World menu phrases can be in the "base" translation dictionary.

-- Yoshiki