Chris,

Thanks for the points.

> I'm afraid that hard-coded string substitution
> is the easiest thing I've seen.

Yes, and as a matter of fact that's really all I'm after here. But the key
issue is how much do we have to bend over backwards to support
localization?!

I've deliberately chosen my example of what I *don't* want to do because
I've done localization on Windows and, man, it's a pain in the neck to have
all these steps whenever you want to write some string that you eventually
want to be localized:
* define some name you can eventually remember (more often than not you
can't)
* perhaps even give it some numeric ID manually (haven't done any of that
stuff recently so I don't know if MSVC and companions got any smarter in
this respect)
* use the ID in the code (if you can remember it)
* define the string in the message catalog (e.g., completely out of context)
Been there, done that, hated it like hell and was not very productive :-(

What I'm really after is finding a much less intrusive way of "being
prepared" for an eventual translation. Thus my search for some sort of
string operator that's non-intrusive to use so that eventually we'll just
use that one (and are therefore automatically prepared for localization)
plus some sort of localization browser that gives us the crucial context for
a translation [We've done localization for a system that *generated* natural
language and man, if you can't see what the context is you are just
sooooooooooooo utterly screwed].

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf
> Of Norton,
> Chris
> Sent: Thursday, September 27, 2001 1:15 PM
> To: 'squeak-dev at lists.squeakfoundation.org'
> Subject: RE: Localization in code
>
>
> 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
>
>