RE: OOC Library and Locales

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

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

> 
>     The Locales module provides the means to list all available locales
>     and create Locale objects (based on language, country, and variant).
>     A Locale object has accessor methods for getting its language,
>     country, and variant settings.

Much of this is already available in OOC.

> 
>   Formatting and Parsing
> 
>     Numbers, dates, times, and messages all may require local-specific
>     formatting when they are displayed to a user.  Formatting facilities
>     require support for standard locale formats and user-defined
>     formats.  Parsing of data from these formats is also required.
> 
>     * Calendar and Time Zones
> 
>        Facilities are provided to represent time values (i.e., "time
>        stamps" and "time intervals") and calendar dates.  Operations for
>        formatting and parsing of date-time values provide all the fields
>        needed to implement the date-time format of a particular language
>        and calendar style.  Dates and time values are stored internally
>        in a locale-independent way, but can be formatted in a
>        locale-sensitive manner.
> 
>        (Calendar and Time Zone Support is available in the OOC Library
>        via the modules `Time' and `Calendar', but they lack support for
>        Unicode strings.  Also, because `Calendar' is dependant on
>        Locales, it will most likely have to be updated for any new
>        Locales modules.  This might also require that other changes be
>        made to the `Calendar' interface.)

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
> 
>        Numeric formatting and parsing is provided for both monetary and
>        non-monetary formatting and includes support for the following:
> 
>        * decimal point character 
>        * digit group separator
>        * digit groupings
>        * positive and negative sign characters
>        * currency symbols (monetary formats only)
>        * number of fractional digits displayed (monetary formats only)
>        * positioning information for signs and currency symbols
>          (preceding or following)
>        * percentages

Already supported.  May need to be extended and/or tested.

> 
>     * Messages
> 
>        Message formatting facilities are able to create message strings
>        based on a locale-specific pattern, with data such as numbers or
>        dates being inserted in appropriate places.  In this way, a
>        message can vary at run-time and still be applicable to the
>        current locale.
> 
>        For example, consider the text of a message that gives the number
>        of files on a disk drive (in English):
> 
>           The disk G contains 3 files.
> 
>        This message is built from two parameters: "3" and "G", but in
>        another language (in this case French) those parameters can be in
>        different positions:
> 
>           Il y a 3 fichiers sur le disque G.

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.

> 
>   Localized Resources 
> 
>     Locale-sensitive classes need access to locale specific resources,
>     which should be packaged and stored in an easily accessible manner.
>     The most common use of this mechanism is to provide text strings
>     such as error messages, menu items, titles, and so forth in the
>     appropriate language.  However, other resources, such as images,
>     should also be able to take advantage of this resource-packaging
>     mechanism.

OOC already supports localized strings in quite a flexible manner.  These
resource strings are stored in a set of ASCII files.  I believe LocText
and LocStrings implement this functionality.

IMHO, the resource strings are the most important element of the 
localization.  It would be very easy to extend this mechanism for
each application to support any number of strings.  If strings include
wildcard characters, the application can insert numbers or other
elements.

Michael Griebling