Re: OOC Library and Locales

[Michael van Acken <Michael.van.Acken@de.uu.net>]

"Eric W. Nikitin" <enikitin@apk.net> writes:

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

Also, if we get away from C we can achieve some kind of portability to
other Oberon platforms.  As far as I know, not one of the Oberon
Systems has locale support.  Unfortunately, portability is limited by
the Unicode support of the target system.

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

I would like to add that the plain text files used by these modules
are not sufficient, especially when we get into Unicode stuff.  A more
elaborate soluation would be best built upon XML, which has excellent
support for Unicode.  Also, with language specific data in XML
documents, we would be using an established technology for structured
documents, instead of ASCII files with an arbitrary, home-grown
syntax.

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

Having a `CharClass' module that is independent of the environment is
not a bad idea.  For some applications it is very important to have a
fixed definition of character classes.  For example, a parser should
not accept different identifiers, only because an `IsLetter'
definition has changed.

Also, language specific character classification comes usually at a
much higher cost, compared to just testing for some ASCII characters.
The XML definition of letters is really huge, and _very_ expensive.

-- mva