Hi Diego,

Thanks for the info. I was curious if there were any arguments we hadn't
already covered. I think right now adding #translated is the simplest thing
to do and therefore we really should go with it. As you know (I'm repeating
this here for the sake of others who are interested in this area) a key
piece of the work is to "flag" the strings we want to translate. What we do
afterwards with the flag is quite a different matter and so I'm perfectly
fine with either approach as long as it actually gets us rolling in the
area.

One of the good things about the implicit approach is that it's entirely
transparent, so even having a set of call to #translated won't confuse it.
The issue I am actually a bit more concerned about is how the table lookup
scales by the end of the day (e.g., we've got literally thousands of strings
that may have to be translated). But we can use the current version to see
how it plays out and look at what to do if it ever turns out to be a
problem.

Probably the most important issue in the overall approach is the "narrow
interface" for translation. Having just two critical methods (#translated
and #format:) makes it easy to play with different approaches further down
the road. Thanks for the good work.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Diego Gomez Deck
> Sent: Saturday, November 15, 2003 9:00 AM
> To: The general-purpose Squeak developers list
> Subject: RE: Warning: Large Babel translation update coming soon
> 
> 
> Hi Andreas,
> 
> > > The ~600 method changeset which converts the UI to use translated 
> > > strings will be incorporated soon... probably tomorrow (Saturday) 
> > > evening.  It sounds like the "explicit" approach has been 
> > > more or less agreed upon by the people who have an interest
> > > in translation issues. 
> > 
> > Oops. As a matter of fact, I missed Stef's post - so make 
> that "most" of the
> > people who have an interest in translation issues ;-)
> > 
> > Hey Stef, just out of curiosity: What were the major 
> arguments for and
> > against each approach? Can you give a brief summary of the 
> discussion?
> 
> 
> Implicit Translation:
> 
> (+) We have to modify less code. A quick statistics over Small-Land
> image give: 70 senders of #format: versus 611 senders of #translated. 
> NOTE: The Small-Land image is based on 3.5 and a lot of 
> removed stuff is
> translated (example: Scamper) so the number are not exact for a 3.7
> image.
> 
> (-) The translation is "installed" and it's not dynamic. In 
> the current
> Babel implementation the default language comes from the Project, it
> allows to have different projects in different languages.  But if you
> need another way to set the default language (like different languages
> per users in a web-application) only changing 
> String>>translated will do
> the job.  Also this "installing" procedure will break when the methods
> are recompiled, etc.
> 
> (-) We need to tag (more or less) 2000 strings using the 
> screening tool.
> It's a simple but large job to do.
> 
> (-) Uniformity.  To make a piece of the image translatable is 
> needed to
> change some code and to tag other strings.
> 
> (+) Transparency.  Some of us talked about the *benefit* of 
> programming
> without taking care of the translation.
> 
> 
> 
> Explicit Translation:
> 
> (-) More code to touch.
> 
> (+) More dynamic.
> 
> (+) It's already done and tested for months in Small-Land's image.
> 
> (+) Straight-forward concept: Do you want to translated a 
> piece of code?
> Avoid visible string concatenations using #format: and send 
> #translated
> to every visible string. (point).
> 
> (+) Transparency.  Some other talked about the in *inconvenience* of
> programming without taking care of the translation.
> 
> 
> > Cheers,
> >   - Andreas
> 
> -- 
> Diego Gomez Deck
> http://www.small-land.org
> 
>