Hi Daniel,

> Hi Diego.
>
> I would like to see Squeak be translatable in 3.7. The way I think this
> should end up is -
> * Translation tool is a package in SM.

ok.

> * Language implementations are packages in SM

ok.

BTW, What about including all the languages and the translator's tool in
the full image?
> * A few changes to frameworks added to Squeak image (String, Language).
> A first draft of this is already in the BFAV, and I'm willing to approve
> it right now, unless you want to update it first.

I'm going to prepare a new changeset with the current version. Please wait
for 1 or 2 days.
> These are all very clear and uncontrovertial IMO, and should proceed as
> quick as possible. Note that the above already mean that new packages
> can be written in a translatable way.

ok.

> Another matter you raise is the changes you mention to eToys translation
> framework. I also think this isn't a big problem. Post your changes,
> someone that knows something about eToys will review them (hopefully
> quickly), and assuming they're good, they'll get in.

Let's go step by step.  Let's work on bare-babel first, then the
image-translation and then theeToys.  Do you agree?

> Then there is the matter of making the applications/frameworks
> translatable. You say there is a changeset for this included in the
> SmallLand image. This should be posted to the list as usual so we can
> test and review it concretely on the alpha image, and be sure we're
> talking about the same thing.

I'll create a separated changeset with the changes all over the image.

> Scott brought up an alternative approach which makes the widgets
> translation aware, so that applications can get translation benefits
> with less changes. I like this approach. Note that GNU uses gettext, for
> example, which makes strings translatable with 3 additional characters
> per string - we should also strive to add a minimal burden on the
> applications. Even if you're willing to do the work for the stuff in the
> image, this needs to be maintained, and there is also a whole bunch of
> Smalltalk code out there that will need to be translatable. So putting
> some thought into minimizing the requirements from the applications is
> worth while.

I'm still not sure if this option will pay extra benefits. As I explained
before,translation-in-the-widgets is not enough to solve all the cases.  If we
stick ontranslation-before-the-widgets we'll have more involved methods but a
simpler concept.
> Could you create the equivalent of your 160 method change set ubt
> assuming Scotts change? it would be a good thing to see how many of the
> application changes are still required this way, in order to choose
> between approaches.

I have not problem to work on it but ONLY if this make sense.  From the
"framework" point ofview the work is, at least, more complex because we have to support both
ideas.
> I think this last matter of the application changes is the only risky
> bit, and I suggested two clear steps to get the decision made. I
> personally will review and approve/reject this part promptly if it is
> ready in the next couple of weeks - after that I will be busier.

I'll try to submit everything this weekend.

> Does this sound ok to you?

Sure! Thank you very much!!

> Daniel

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