Re: OOC Library and Locales

["Eric W. Nikitin" <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.

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.


> 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?  Are databases supposed to contain multiple
languages?  Or do you build separate databases for each
locale/language and somehow correlate them to one another?  Can this
mechanism be used to access resources other than text strings?


> >     * Calendar and Time Zones
> > 
> 
> Actually the Calendar interface is fairly robust since it uses the wildcard
> conventions for date/time used by C.  As you say, though, we do need support
> for unicode strings.  Not only can the Calendar module output generic
> strings
> but it can also parse generic strings given a parsing template.
>  
> > 
> >     * Numbers
> > 
> 
> Already supported.  May need to be extended and/or tested.


I like the Calendar interface, and considering the brief look I gave
to LocNumStr, it seems adequate.  The main problem, other than
needing support for LONGCHAR, is that they are dependant on the
global locale setting.  If I'm trying to format a table with dates
and monetary amounts in several languages, I'm going to have to keep
resetting the global locale.  Maybe this isn't as big a problem as I
think; can I get some other people's opinions here?

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?


> >     * 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.


> 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.   


There's one other thing I'd like to mention that I think should be
changed in the OOC Library.  Currently, we have two distinct
character classification facilities: CharClass and LocStrings.
CharClass is implemented in Oberon-2 and doesn't consider locales,
whereas LocStrings is a wrapper around C functions, which take the
global locale setting into account.  These should be somehow merged
together; perhaps leaving CharClass (and LongCharClass) with
locale-sensitive character classification and simply doing away with
LocStrings (and in the process, making Strings, and LongStrings,
locale-sensitive).  Opinions?


Thanks for the information and your feedback, Mike.  


Eric