RE: OOC Library and Locales

["Griebling, Mike" <Mike.Griebling@alliedsignal.com>]

> From: Eric W. Nikitin [mailto:enikitin@apk.net]
> Hi,
> 
> "Griebling, Mike" <Mike.Griebling@alliedsignal.com> wrote:
> > > These C-like facilities are minimally sufficient, but are 
> nowhere near
> > > what Java and C++ provide.  And AFAIK, these modules do not 
> > > yet support
> > > LONGCHAR.
> > 
> > If you look carefully, you'll see we've already built on top of the
> > minimal C facilities.  
> 
> Yes, I know.  But, IMHO, the C facilities aren't that great: A
> program's locale is a global property, and it must be reset every
> time the program needs to process a different locale.  The only
> standard locale available is the "C" locale.  Unicode is not directly
> supported; wide and multi-byte characters are supported, but there is
> no guarantee that a particular system will support a "Unicode" locale.

The problem is also going to be support in the underlying OS of Unicode.
At the moment, I don't know of any OS that supports Unicode directly and
transparently.  The BeOS comes the closest with support for UTF built right
into the OS in a tranparent fashion (i.e., you can edit a text file and
insert any UTF character directly).  It can translate between UTF and 
other formats such as Unicode.

IMHO, making a class-like locales is not that big a problem.  Just create
another layer on top of the existing locale module and cache all the
settings
for a specific locale.

> In my mind, the whole point of this proposal is to try to do better
> than what's available in C.  Maybe we don't need all the "bells and
> whistles" of Java's facilities, but we could make things a bit nicer
> than what C has.

My point was that it may not be practically necessary to do a whole
lot better than what's in the C libraries.  We are especially lacking
in volunteers to do the work.

> 
> > The main addition is the localized strings.
> > 
> > > In order to move forward, we need to agree on what 
> exactly constitutes
> > > "complete" support for locales.  That is, what facilities 
> do application
> > > developers need in order to easily create 
> internationalized software?
> > 
> > The main need is for a way of providing localized text 
> strings and that
> > is already provided in OOC.  Everything else is bells and 
> whistles.  To
> > that end, the main omission is support for LONGCHAR in the 
> localization
> > modules.
> 
> You're talking about LocText and LocTextRider, right?  I looked at
> these some time ago, and they seem very much like the gettext/msgfmt
> facilities available on Unix.  I'm not sure I really understand how
> LocText and LocTextRider are supposed to be used.  How are databases
> created and maintained?  

Using your favourite text editor.  Hence OS support for Unicode is a 
prerequisite for getting this to work.  Does emacs support Unicode?

> Are databases supposed to contain multiple
> languages? 

A particular database or file contains a single language.  Multiple
databases are used, one for each supported language.  Note: A locale
definition is not the same as a language since many locales may
share a common language.
 
> Or do you build separate databases for each
> locale/language and somehow correlate them to one another?  

See above.  The correlation is done in the master files.  Here's
an example (from the LocText module):

   An example of this master file is shown below:
   
   PATH "/usr/lib/ooc/loc:/usr/lib/ooc/vo/loc"
   LOCALE "Deutsch (Deutschland)" 
     CATALOG   "de.cat" 
     SYSLOCALE "de_DE"
     INCLUDE   "ooc_de.cat"
   LOCALE "Deutsch (Schweiz)"     
     CATALOG   "de.cat" 
     SYSLOCALE "de_CH"
     INCLUDE   "ooc_de.cat"
   LOCALE "Deutsch (Ostereich)"   
     CATALOG   "de.cat" 
     SYSLOCALE "de_AU"
     INCLUDE   "ooc_de.cat"
   LOCALE "default"               
     CATALOG   "en.cat" 
     SYSLOCALE ""
     INCLUDE   "ooc_en.cat"
   
   Based on the entries in this file, the following catalog files
   will be expected in the same directory where the master file is
   found or in one of the "PATH" directories:
   
     de.cat
     en.cat
     ooc_de.cat
     ooc_en.cat

> Can this
> mechanism be used to access resources other than text strings?

Not in the existing modules.  What else would need to be localized?

> What happens in a multi-threaded environment?  Can you lock the
> global locale setting to make sure that no other thread changes it
> while you're in the middle of formatting something?

None of the OOC libraries or even the GC are set up to support 
multi-threading AFAIK.  I will be addressing multi-threading when
I finally get around to finishing my Oberon-2 to C++ translator
for BeOS.
 
> 
> > >     * Messages
> > > 
> > 
> > Partially supported already in OOC.  Just define a localized
> > string such as "The disk %s contains %d files." and then have
> > a simple parser as an extension in the application file in
> > the missing fields.  I believe OOC already uses such a mechanism
> > in the compiler.
> 
> As Tim mentioned in his email, positional information still needs to
> be added to this mechanism.

That's independent of the existing implementation.  You could layer
this support on top of what's there in either the application or
another add-on module.
 
> 
> > IMHO, the resource strings are the most important element of the 
> > localization.  
> 
> I also think that having a set of standard locales, which are
> available on all supported platforms, is very important.   

That will require some work and volunteers.  IMHO if you provide
the tools to define new language catalogs easily (as we have), it
should trivial for anyone interested to add the necessary strings
for their own language -- as long as an app uses our localization
facilities.
 
Michael