Re: gettext for Ada

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:f008ea86-60a5-411d-88ab-0130bcda63a8@googlegroups.com...
On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote:
...
>> I would make a set of parallel child packages with the same operations in
>> each. Then one could use an if (or maybe a case, if the proposed Ada 2020
>> extension comes to pass) to select them.
>
>Are you talking about a case-statement for selecting a child package, 
>perhaps something like:
> PACKAGE Actual_Messages RENAMES (CASE Language is
>   WHEN English => Messages.English, WHEN German => Messages.German,
>   WHEN French => Messages.French, WHEN OTHERS => Raise Program_Error)
>?? -- or something like case-selection on strings? -- or something 
>different altogether?

Case selection on fixed length strings (which these are). Would need an 
others clause, of course.

>> Or (perhaps better), use a full OOP design, with an abstract Root_Locale
>> type (with a set of dispatching operations), a series of specific Locale
>> types (English_Locale, French_Locale, etc.) giving implementations to 
>> those
>> types, and a map and factory to create objects of those types as needed.
>> (The Claw GUI Builder has an internal design much like this, other than 
>> the
>> factory, which didn't exist in Ada 95, so I had to use a massive case
>> statement instead. A factory would have been much better.)
>
>Do you still have the giant case, or did you opt to use the
> Generic_Dispatching_Constructor when Ada 2005 added it?

Claw is still pure Ada 95 code.

>> > Also, shouldn't the stuff in Ada.Locales actually be proper
>> > enumerations rather than strings?
>>
>> There's a near infinite number of possible Locales, so enumerating them 
>> is
>> next to impossible. We decided against even giving names to the most 
>> common
>> ones, as that would have led to endless debates about which ones are the
>> most important. The strings come from a freely available ISO standard, so
>> they will never change and are easy to find out and are maintained by
>> someone other than us Ada people (so no need for debates on our end on
>> topics outside of our expertise). This is the same reason that we depend 
>> on
>> character set standards rather than rolling our own character set rules
>> (even though the latter would be easier to maintain, we wouldn't really 
>> know
>> what we were doing).
>
>Er... "The strings come from a freely available ISO standard, so they will 
>never change"
>
>So why not enumerate the strings, that way proper cases can be done on 
>either languages and/or locales?

Because the underlying Standard changes frequently, adding new languages and 
locales. There is no practical way to do that for Ada enumerations. (Note 
that I said the "strings don't change", meaning that the meanings of the 
strings don't change, not that the *list* of strings doesn't change often, 
usually with new additions.)

>
>-- ISO 3166-1 Country & Territory Codes
>-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
>Type Locale is (
> AF, -- Afghanistan
> AX, -- Åland Islands
...

There are many hundreds of locales, and new ones are added periodically. 
Maintaining that in the Ada standard would be a nightmare, and what 
precisely would be the point? The same applies (even moreso) to languages.

In addition, this scheme would fail misreably if an OS update caused some 
unknown (to Ada) locale or language to be returned. That's not possible for 
the string scheme (as it matches both the ISO Standard and what OSes 
actually do).

                                          Randy.


                                         Randy.