Re: gettext for Ada

[Shark8 <onewingedshark@gmail.com>]

On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:40dc6a79-9434-4b5a-bed0-50ee1dfb74c5...
> > On Monday, November 20, 2017 at 3:43:21 PM UTC-7, Randy Brukardt wrote:
> >> "Shark8" wrote in message
> >> news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f...
> >> On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
> >> > Where can I get a gettext bindings for Ada?
> >>
> >> ...
> >> >And then at compile-time select the proper language to build the
> >> >application via
> >> >GPR-projects, makefiles, or whatever paramaterizable build-system you 
> >> >wish
> >> >to use.
> >>
> >> Or, use parallel packages and select the correct one to use at runtime 
> >> based
> >> on Ada.Locales (A.19). That's the primary purpose of the Locales package,
> >> after all.
> >
> > Parallel packages? I've not heard the term before, how are they used & 
> > selected
> > at runtime?
> 
> 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? 

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

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

-- 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
 AL, -- Albania
 DZ, -- Algeria
 AS, -- American Samoa
 AD, -- Andorra
 ...
 ZZ  -- Unknown Country
 );

-- Enumeration of the ISO 639-3 alpha-3 code that identifies a language
-- See: http://www-01.sil.org/iso639-3/codes.asp?order=639_3&letter=%25
Type Language is (
  aaa, -- Ghotuo
  aab, -- Alumu-Tesu
  aac, -- Ari
  aad, -- Amal
  aae, -- Arbëreshë Albanian
  aaf, -- Aranadan
  aag, -- Ambrak
  aah, -- Abu' Arapesh 
  ...
  und, -- Undetermined
  ...
  zyp, -- Zyphe Chin
  zza, -- Zaza
  zzj  -- Zuojiang Zhuang 
 );

And, perhaps a Image function for Language which returns the lower-cased-string of the enumeration itself.