Hi Andreas & company.

Disclaimer:  I am not a Localization expert, but I have had to deal with
several aspects of this problem for years (my company sells its products in
many countries, in a few different languages).

Seeing as how the bulk of my experience is on Windows platforms, I am most
familiar with the localization scheme for that OS.  On Windows, you have
several resources available to your applications.  Other Smalltalks (VSE &
VA) make use of the regional settings (in the Control Panel).  Such things
as language, time zone, date/time format/separators, etc. can be controlled
in Squeak by having appropriate primitives in the VM (heck, they may already
be there -- I'm not a VM hacker).

On platforms where these things are not defined by the operating system,
then I would support the idea of a regional settings tool in Squeak, as you
have described.  Perhaps if the tool were used on all platforms, then, with
appropriate VM support, the Squeak regional settings tool could be used to
change the OS settings too.

As far as string translation goes, I'm afraid that this problem is *hard* to
solve.  I've tried many approaches, including hard-coded codes (symbols or
numbers that represent strings in a file), pool keys (whose values can be
re-loaded on demand from appropriately translated files) and several other
unsatisfactory methods.  Without natural language processing, I'm afraid
that hard-coded string substitution is the easiest thing I've seen.

Now, if we had some form of natural language processing, we could store
strings in a Sentence objects, whose grammar (i.e. string format) might be
driven by the language you've got loaded.  You might have to program the
Sentence objects (set their verbs, nouns, etc).  But I think this approach
would be generally unsatisfying too -- too much overhead (and the exceptions
to the rules in a given language would be tedious to manage -- not to
mention all of the slang terms).  Perhaps it would be OK in limited use, but
would not be acceptable throughout the image.

Another problem with localization is that it requires effort to maintain
over time.  People do a little bit of localization work, then they move on
and other people take up the baton.  Invariably, the whole product needs to
be proofed every so often, because too many people have made inconsistent
changes.

I think the first thing that needs to be done is to choose a *limited* list
of things that *need* localization.  I would tackle this problem a little at
a time and would focus on what is absolutely necessary.  The first thing on
my list would be time zones, date/time formats, etc.

Cheers,

---==> Chris