gettext for Ada

gettext for Ada

[Victor Porton]

Where can I get a gettext bindings for Ada?

In 2009 there was a discussion on the same question, and the inquirer was 
advised to use GtkAda.Intl in GtkAda.

It is not an ideal solution, because I do not want (me and my users) to 
install GtkAda only to get gettext support.

Is there are less heavyweight solution?

-- 
Victor Porton - http://portonvictor.org

Re: gettext for Ada

[Shark8]

On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
> Where can I get a gettext bindings for Ada?

I would actually advise against gettext usage, in general -- one of the big problems is that it's all string-based operations, meaning that there's going to be either a lot of text processing/parsing and/or somewhat ad hoc database (ie PO files) -- for a real translation solution which is lightweight and won't introduce foreign dependencies you can use Ada packages for exactly that purpose.

Ideally messages would be constructed w/ appropriate structure and rendered in the user/display language as needed... this is, however, a more complex solution than many are willing to accept as I've never actually seen it in usage. (Though, to be fair, I've only professionally worked on ONE project which had multilingual needs.)

> 
> Is there are less heavyweight solution?

-- Message Spec: project-messages.ads
Package Project.Messages is
  Type Disk is (Read_Error, Write_Error, Access_Error);
  
  Function Disk_Error( File_Name : String; Error : Disk ) return String;
End Project.Messages;


-- Package Body: project-messages.adb
-- Location: ./English/
Package Body Project.Messages is
  
  Function Disk_Error( File_Name : String; Error : Disk ) return String is
  Begin
    case Error is
      when Access_Error => Return "The disk Drive could not be accessed.";
      when Read_Error | Write_Error => Return "There was an Error " &
            (if Error = Read_Error then "reading from" else "writing to") &
             " the file """ & File_Name & """.";
    end case;
  End Disk Error;
End Project.Messages;

-- Package Body: project-messages.adb
-- Location: ./Japanese/
Package Body Project.Messages is
  
  Function Disk_Error( File_Name : String; Error : Disk ) return String is
  Begin
    case Error is
      when Access_Error => Return "ディスクドライブにアクセスできませんでした。";
      when Read_Error | Write_Error => Return "ファイル " & File_Name & ' ' &
            (if Error = Read_Error then "からの読み取り" else "への書き込み") &
             "中にエラーが発生しました。";
    end case;
  End Disk Error;
End Project.Messages;

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.

Re: gettext for Ada

[Jacob Sparre Andersen]

Shark8  <onewingedshark@gmail.com> wrote:

> On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
>> Where can I get a gettext bindings for Ada?

Included in GtkAda IIRC.

> I would actually advise against gettext usage, in general

I would actually advise in favour of GNU Gettext - or at least it's
mechanism:

+ The developer can write UI strings which make sense.
+ Translations can be distributed separately from the executables.

I'm working on a project where we're going to handle translations
similarly to how GNU Gettext does it.  (We can't use GNU Gettext
directly, since we're required to use a database as the translation
storage.)

The problem with GNU Gettext - and C printf() - is that you lose the
compile-time checking that formatting fields match the data passed.

Greetings,

Jacob
-- 
»And what about homo sapiens?
 Yes, we think that would be a very good idea ...« -- not Gandhi

Re: gettext for Ada

[Shark8]

> > I would actually advise against gettext usage, in general
> 
> I would actually advise in favour of GNU Gettext - or at least it's
> mechanism:
> 
> + The developer can write UI strings which make sense.
> + Translations can be distributed separately from the executables.

Those are the "plus sides" of the technique, but they shouldn't be completely divorced from the "minus sides". (ie we should have realistic/honest evaluations of the proposed solutions to whatever problem we're trying to solve.)

As always, the particular situation may indeed call for something you or I wouldn't normally recommend and, contrawise, pointing out the disadvantages of a proposed solution and/or offering alternatives is often instructive in how to solve the problem.

> 
> The problem with GNU Gettext - and C printf() - is that you lose the
> compile-time checking that formatting fields match the data passed.

Well, that is one of the general problems of formatting strings: they cannot be in-general guaranteed to be correct (at least w/o some really good static analysis).

It's also illustrative of why an actual structured approach to messaging would be much better: simple string-formatting of "You have %d meats." with 1 (one) yields "You have 1 meats." and thereby violates subject-verb agreement (of [non-]plurality). -- The structured approach would take things like this into account, as well as things like plural-forms and casings and construct a sort of "abstract grammar" [or something] which on rendering would yield the appropriate and correct forms for the user. -- Again, I haven't heard of this being used in many projects... but that's probably due to the complex nature of designing the underlying machinery/framework, compared to, say, calling "Copied 1 file(s)." a 'good enough' solution.

Re: gettext for Ada

[Dmitry A. Kazakov]

On 2017-11-20 20:59, Shark8 wrote:

> Well, that is one of the general problems of formatting strings: they
> cannot be in-general guaranteed to be correct (at least w/o some
> really  good static analysis).
> 
> It's also illustrative of why an actual structured approach to 
> messaging would be much better: simple string-formatting of "You have
> %d meats." with 1 (one) yields "You have 1 meats." and thereby
> violates subject-verb agreement (of [non-]plurality).
That does not apply to Ada which is typed. In Ada I would do:

    X : Meats := 1;

    Put_Line ("You have" & Image (X));

and Image (Meats) will produce "1 meat".

In my projects I customary add Image to many important types.

I a lesser number of cases I also add Get, Put (from string) and Value.

In some cases I add stream I/O operations as well.

In GtkAda projects I also add an implementation of GtkCellRenderer in 
order to be able show values in tree views.

Of I would never use gettext, not in a wildest nightmare.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> That does not apply to Ada which is typed. In Ada I would do:
>
>    X : Meats := 1;
>
>    Put_Line ("You have" & Image (X));
>
> and Image (Meats) will produce "1 meat".

This makes perfect sense - if you're only going to communicate in
English.  I can't see how you can extrapolate that to multiple
languages.  And definitely not multiple languages added dynamically
after compiling the program.

Greetings,

Jacob
-- 
Never attribute to malice what can adequately be explained by incompetence.

Re: gettext for Ada

[Dmitry A. Kazakov]

On 2017-11-21 20:15, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> That does not apply to Ada which is typed. In Ada I would do:
>>
>>     X : Meats := 1;
>>
>>     Put_Line ("You have" & Image (X));
>>
>> and Image (Meats) will produce "1 meat".
> 
> This makes perfect sense - if you're only going to communicate in
> English.  I can't see how you can extrapolate that to multiple
> languages.  And definitely not multiple languages added dynamically
> after compiling the program.

The only thing you need to change is Image for String argument:

    Put_Line (Image ("You have") & Image (X));

Image will make lookup for "You have" in the translation table. So will 
do Image for Meats when looking for "meat" and "meats".

It is not really that hard for Indo-European languages.

A top-down or a hieroglyphic writing system might be kind of difficult 
for Ada.Text_IO... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:
> On 2017-11-21 20:15, Jacob Sparre Andersen wrote:
>> Dmitry A. Kazakov wrote:

>>> That does not apply to Ada which is typed. In Ada I would do:
>>>
>>>     X : Meats := 1;
>>>
>>>     Put_Line ("You have" & Image (X));
>>>
>>> and Image (Meats) will produce "1 meat".
>>
>> This makes perfect sense - if you're only going to communicate in
>> English.  I can't see how you can extrapolate that to multiple
>> languages.  And definitely not multiple languages added dynamically
>> after compiling the program.
>
> The only thing you need to change is Image for String argument:
>
>    Put_Line (Image ("You have") & Image (X));
>
> Image will make lookup for "You have" in the translation table. So
> will do Image for Meats when looking for "meat" and "meats".

That assumes that all the languages you translate to have the same word
order.  I don't think that is realistic.

Greetings,

Jacob
-- 
The backhoe is the natural predator of the fiber optic cable.

Re: gettext for Ada

[Dmitry A. Kazakov]

On 23/11/2017 10:15, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
>> On 2017-11-21 20:15, Jacob Sparre Andersen wrote:
>>> Dmitry A. Kazakov wrote:
> 
>>>> That does not apply to Ada which is typed. In Ada I would do:
>>>>
>>>>      X : Meats := 1;
>>>>
>>>>      Put_Line ("You have" & Image (X));
>>>>
>>>> and Image (Meats) will produce "1 meat".
>>>
>>> This makes perfect sense - if you're only going to communicate in
>>> English.  I can't see how you can extrapolate that to multiple
>>> languages.  And definitely not multiple languages added dynamically
>>> after compiling the program.
>>
>> The only thing you need to change is Image for String argument:
>>
>>     Put_Line (Image ("You have") & Image (X));
>>
>> Image will make lookup for "You have" in the translation table. So
>> will do Image for Meats when looking for "meat" and "meats".
> 
> That assumes that all the languages you translate to have the same word
> order.  I don't think that is realistic.

It translates whole part of the sentence, e.g.

    Default    -> Locale
    "You have" -> "Du hast"
    "You have" -> "У тебя есть"

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> It translates whole part of the sentence, e.g.
>
>    Default    -> Locale
>    "You have" -> "Du hast"
>    "You have" -> "У тебя есть"

What would you do if the proper translation was

 n=0: Einki kjøt hevur tú.
 n>0: <n> petti kjøt hevur tú.

?

Greetings,

Jacob
-- 
"Any, sufficiently complicated, experiment is indistinguishable from magic."

Re: gettext for Ada

[Dmitry A. Kazakov]

On 23/11/2017 11:03, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> It translates whole part of the sentence, e.g.
>>
>>     Default    -> Locale
>>     "You have" -> "Du hast"
>>     "You have" -> "У тебя есть"
> 
> What would you do if the proper translation was
> 
>   n=0: Einki kjøt hevur tú.
>   n>0: <n> petti kjøt hevur tú.
> 
> ?

    Put (Image (n) & Image (Verb) & ' ' & Image ("Tail"));

Image (0) would return empty string. But first I would avoid sentences 
difficult to translate without having AI. Anyway a format string would 
have more problems with inflections.

BTW, for a right to left languages you could define "+" for strings that 
reorders arguments:

    Put (A + B + C); --> Put (C & B & A);

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

>    Put (Image (n) & Image (Verb) & ' ' & Image ("Tail"));
>
> Image (0) would return empty string. But first I would avoid sentences
> difficult to translate without having AI. Anyway a format string would
> have more problems with inflections.
>
> BTW, for a right to left languages you could define "+" for strings
> that reorders arguments:
>
>    Put (A + B + C); --> Put (C & B & A);

I can't see how you can do that without having a programmer sit down
with a translator for each language, and implement an "Image" function
for each parametrised, user-visible sentence in the application.  That
sounds quite costly to me.

Do you have an idea (or experience) doing it in an efficient way, which
doesn't make it prohibitively costly to add more languages?  (Or to
change the user interface for that matter?)

Greetings,

Jacob
-- 
"So this is how liberty dies, with thunderous applause..."

Re: gettext for Ada

[Dmitry A. Kazakov]

On 23/11/2017 13:14, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>>     Put (Image (n) & Image (Verb) & ' ' & Image ("Tail"));
>>
>> Image (0) would return empty string. But first I would avoid sentences
>> difficult to translate without having AI. Anyway a format string would
>> have more problems with inflections.
>>
>> BTW, for a right to left languages you could define "+" for strings
>> that reorders arguments:
>>
>>     Put (A + B + C); --> Put (C & B & A);
> 
> I can't see how you can do that without having a programmer sit down
> with a translator for each language, and implement an "Image" function
> for each parametrised, user-visible sentence in the application.  That
> sounds quite costly to me.

No. You do everything in English. When you run your program, each time 
an Image is called it creates or modifies an entry in the translation 
table backed by a single-file DB maybe with source file and line 
reference attached to the entry.

Once you decide to deploy your project, you walk through the DB entries 
and provide translations to the languages you want to support. The 
source line reference helps to understand the meaning of the sentence as 
a whole. The DB is deployed together with the application.

> Do you have an idea (or experience) doing it in an efficient way, which
> doesn't make it prohibitively costly to add more languages?  (Or to
> change the user interface for that matter?)

I don't do text messages translations, it is IMO pointless. If a user 
does not know English enough to understand a text message, he should 
walk away. However I used the schema described above once.

A GUI is a different thing. There is little choice because frameworks 
like GTK already implement one or another translation schema. GTK has an 
official method which I don't like and a semi-official one I prefer to use.

I have all texts (button names, tool-tip texts etc) coming as a string 
widget style property with the default value to serve as the English 
fallback. GTK widget styles are defined/overridden using CSS and can be 
reloaded using GtkCssProvider any time. The DB I described above is not 
necessary because in GTK you can walk all properties of a widget (and 
its children for containers). This how you can get a full list of all 
texts and devise some localized CSS' to deploy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Jacob Sparre Andersen]

Shark8 <onewingedshark@gmail.com> writes:

> It's also illustrative of why an actual structured approach to
> messaging would be much better: simple string-formatting of "You have
> %d meats." with 1 (one) yields "You have 1 meats." and thereby
> violates subject-verb agreement (of [non-]plurality). -- The
> structured approach would take things like this into account, as well
> as things like plural-forms and casings and construct a sort of
> "abstract grammar" [or something] which on rendering would yield the
> appropriate and correct forms for the user. -- Again, I haven't heard
> of this being used in many projects... but that's probably due to the
> complex nature of designing the underlying machinery/framework,
> compared to, say, calling "Copied 1 file(s)." a 'good enough'
> solution.

GNU Gettext happens to have a perfectly good solution to this problem.

Would you be able to implement handling of plural forms anywhere nearly
as well as GNU Gettext does it?  For all the languages you might have
users for?

Greetings,

Jacob
-- 
"[C programming] is like playing tennis on a minefield using hand
 grenade for a ball."                          -- Dmitry A. Kazakov

Re: gettext for Ada

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f@googlegroups.com...
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.

                                          Randy.

Re: gettext for Ada

[Shark8]

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? Also, shouldn't the stuff in Ada.Locales actually be proper enumerations rather than strings?

Re: gettext for Ada

[G. B.]

Shark8 <onewingedshark@gmail.com> wrote:
>
> 
> Also, shouldn't the stuff in Ada.Locales actually be proper enumerations
> rather than strings?


Given the volatility in the political world,
Ada enumerating locales will be an extraordinary 
achievement.

Re: gettext for Ada

[J-P. Rosen]

Le 21/11/2017 à 09:29, G. B. a écrit :
> Shark8 <onewingedshark@gmail.com> wrote:
>>
>>
>> Also, shouldn't the stuff in Ada.Locales actually be proper enumerations
>> rather than strings?
> 
> 
> Given the volatility in the political world,
> Ada enumerating locales will be an extraordinary 
> achievement.
> 
Moreover, there is an ISO standard for country and language strings; Ada
just refers to it.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: gettext for Ada

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:40dc6a79-9434-4b5a-bed0-50ee1dfb74c5@googlegroups.com...
> 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.

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

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

                                                 Randy.

Re: gettext for Ada

[Shark8]

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.

Re: gettext for Ada

[Randy Brukardt]

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

Re: gettext for Ada

[Shark8]

On Wednesday, November 22, 2017 at 5:30:28 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:f008ea86-60a5-411d-88ab-0130bcda63a8...
> 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.

Is it a case-insensitive string comparison? Because case-sensitive would make your cases explode exponentially if it weren't... and if they ARE case-insensitive I'd expect a lot of programmers (notably those of C backgrounds) to complain. (Or is there some sort of magic/syntax to determine between the two?)

In all, CASE-on-Strings is rather disappointing... it kinda comes off as an "Ada also does X like Java!"-feature like INTERFACE was/is. (Interface could have, and IMO should have, been far more useful than Java's notion.)

Something like extending CASE to renaming-packages or extending the GENERIC hierarchy sounds much more useful to me. {There are several interesting ways generics could be extended: (a) allowing non-generic packages as parameters, which would require some ability to specify characteristics about the publicly available properties of the specification [honestly, a LOT of work, but could simplify the construction of standard packages]; (b) allowing generic subprograms in a manner like current generic packages may be parametrized; (c) easing some restrictions on incomplete formal parameters, allowing a function returning said type to be used.}

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

Ah, I see.
I remember you mentioning that Janus/Ada had a few Ada 2005 features implemented and was wondering if perhaps something like updating Claw (or some similar SW package) was the/a motivating factor.

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

And? / I fail to see a meaningful distinction here.

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

No; it really wouldn't, there are enumerations that perfectly map to "I don't understand this"-states:

From my example:
  * Locale'(ZZ)
  * Language'(und)

If you're encountering unknown-to-Ada locale/language the correct thing to do is either FAIL (throw the appropriate exception) and/or DEFAULT to something that is known.

Re: gettext for Ada

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:d44669cc-9746-4c03-a0da-548cb945f4d5@googlegroups.com...
On Wednesday, November 22, 2017 at 5:30:28 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message
> news:f008ea86-60a5-411d-88ab-0130bcda63a8...
...
>> >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.

...
>In all, CASE-on-Strings is rather disappointing... it kinda comes off as
>an "Ada also does X like Java!"-feature like INTERFACE was/is.
>(Interface could have, and IMO should have, been far more useful than
>Java's notion.)

The proposed feature is "case-on-(simple)-composite-types". I was just using 
it specifically as "case-on-fixed-strings".

As far as case sensitivity goes, that's easy to write by hand if the string 
is short enough. I never use a case insensitivity routine for short strings 
like options or language names, even now in Ada 95:

    if Option_Slice = "Op" or Option_Slice = "oP" or Option_Slice = "OP" or 
Option_Slice = "op" then
         Do_Operation_Option;
    elsif Option_Slice = "Oz" or Option_Slice = "oZ" or Option_Slice = "OZ" 
or Option_Slice = "oz" then
         Do_Optimization_Option;
    else
         Option_Error (10);
    end if;

The above is quite common in my code (perhap premature optimation on my 
part, knowing that a function like To_Upper is many times more expensive 
than a string compare).

...
>> >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.)
>
>And? / I fail to see a meaningful distinction here.

Every time the underlying standard changes, the enumeration would have to be 
changed. That would make existing code incompatible (cases without others 
would no longer compile, some of the names could cause use clause conflicts, 
making existing code not compile, etc.) And the Ada Standard would have to 
be changed each such time. Doesn't make much sense.


...
>> 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).
>
>No; it really wouldn't, there are enumerations that perfectly map to "I 
>don't
>understand this"-states:
>
>From my example:
>  * Locale'(ZZ)
>  * Language'(und)

That would require mapping every one of the thousand plus strings to an 
enumeration literal. Do you realize how much code that would take? (Each one 
would require the equivalent of the if I gave above.) It would add a huge 
bulk to any program that used the Locale package (as would the necessary 
'Image table). Yuck.

                                            Randy. 

Re: gettext for Ada

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>     if Option_Slice = "Op" or Option_Slice = "oP" or Option_Slice = "OP" or 
> Option_Slice = "op" then
>          Do_Operation_Option;
>     elsif Option_Slice = "Oz" or Option_Slice = "oZ" or Option_Slice = "OZ" 
> or Option_Slice = "oz" then
>          Do_Optimization_Option;
>     else
>          Option_Error (10);
>     end if;
>
> The above is quite common in my code (perhap premature optimation on
> my part, knowing that a function like To_Upper is many times more
> expensive than a string compare).

Yes, but also prone to the sort of error where you copy the code for "+"
into the function "-" and forget to change the actual operation.

Re: gettext for Ada

[Dmitry A. Kazakov]

On 2017-11-28 01:48, Randy Brukardt wrote:

> The above is quite common in my code (perhap premature optimation on my
> part, knowing that a function like To_Upper is many times more expensive
> than a string compare).

I convert the source line to the preferred case as I read it in and then 
work with that source.

Then when comparing something against a set of alternatives 
if-elsif-elsif is a pretty bad choice. I put the alternatives into a 
table which is matched against the source using binary search (or hash 
if you prefer that). To make the table lookup case-insensitive is no big 
deal.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ovk4ss$b9u$1@gioia.aioe.org...
> On 2017-11-28 01:48, Randy Brukardt wrote:
>
>> The above is quite common in my code (perhap premature optimation on my
>> part, knowing that a function like To_Upper is many times more expensive
>> than a string compare).
>
> I convert the source line to the preferred case as I read it in and then 
> work with that source.

The is my preference, but there a lot of cases (like command line 
processing) where some parts are in mixed case (which you need to preserve) 
and other parts are case insensitive. Then you get the sort of code I 
showed, because individually converting slices is expensive and usually 
unnecessary (options usually are one or two characters in Janus/Ada 
programs).

                             Randy.

Re: gettext for Ada

[Dmitry A. Kazakov]

On 28/11/2017 23:41, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ovk4ss$b9u$1@gioia.aioe.org...
>> On 2017-11-28 01:48, Randy Brukardt wrote:
>>
>>> The above is quite common in my code (perhap premature optimation on my
>>> part, knowing that a function like To_Upper is many times more expensive
>>> than a string compare).
>>
>> I convert the source line to the preferred case as I read it in and then
>> work with that source.
> 
> The is my preference, but there a lot of cases (like command line
> processing) where some parts are in mixed case (which you need to preserve)
> and other parts are case insensitive.

Yes. I keep both strings and use one or anther where appropriate, e.g. 
when showing an error message, or when getting a string literal out of 
the source, the original works better. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gettext for Ada

[G. B.]

Shark8 <onewingedshark@gmail.com> wrote:

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


The set of locales may grow. ‘Last etc. would change.

Re: gettext for Ada

[Shark8]

On Thursday, November 23, 2017 at 1:25:50 AM UTC-7, G. B. wrote:
> Shark8 wrote:
> 
> > 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?
> 
> 
> The set of locales may grow. ‘Last etc. would change.

Why would you use 'Last or 'Succ on languages? -- If you're talking about setting up a generic-system, you'd make special values formal parameters:

Generic
  Type Language is (<>);
  Default,
  Unknown : in Language;
Package Translation_Base is
 --...
End Translation_Base;


Using enumerations also means that you can leverage discriminated records, making a solid foundation for true multilingual applications:

Type Language_String( Language : Ada.Locale.Language; Length : Natural ) is record
  Data : String( 1..Length );
end record;

--...

Package Language_String_Vector is new Ada.Containers.Indefinite_Vectors(
    Index   => Positive,
    Element => Language_String
  );

Subtype Multi_Lingual_Text is Language_String_Vector.Vector;

--...

Procedure Render( Text : Multi_Lingual_Text; Display : Some_Text_Device );

Re: gettext for Ada

[G. B.]

Shark8 <onewingedshark@gmail.com> wrote:

>> The set of locales may grow. ‘Last etc. would change.
> 
> Why would you use 'Last or 'Succ on languages? 

No type can be exempt from general Ada semantics.
That’s like asking why I would use 13 for Ada in the USA?


> Using enumerations also means that you can leverage discriminated
> records, making a solid foundation for true multilingual applications:
> 

It might be realistic to assume a set of languages 
that a program supports. The set might or might
not be a proper subtype.
In any case, I’d define a type that enumerates the
supported languages and “link” it to locales. The type 
thus provides decoupling in place of dependence
on an ever changing library type.

Re: gettext for Ada

[Shark8]

On Thursday, November 23, 2017 at 11:55:46 AM UTC-7, G. B. wrote:
> Shark8 wrote:
> 
> >> The set of locales may grow. ‘Last etc. would change.
> > 
> > Why would you use 'Last or 'Succ on languages? 
> 
> No type can be exempt from general Ada semantics.
> That’s like asking why I would use 13 for Ada in the USA?

I'm not saying the type should be exempt from the general semantics; I'm saying that the operations don't make sense in the context of language... and that fact could be put into the standard with something like:

"The order and position of the Language and Locale types should not be relied upon, particularly since the referenced standards may be updated and Package Ada.Locales may be updated at any time to reflect the current state of those standards; therefore, usage of 'First, 'Last, 'Succ, 'Pred, 'Val, and 'Pos are discouraged."

Getting the proper value when the OS (or some non-Ada library) returns a string could be done via the 'Value attribute; e.g.:

Function Get_Language return Language is
  Function OS_Get_Language return C_String
   with Import, Convention => C, Link_Name => "getlang";
Begin
  Return Language'Value( To_Ada_String( OS_Get_Language ) );
Exception
   When Constraint_Error => Return und;
End Get Language;

Re: gettext for Ada

[Randy Brukardt]

>> >> The set of locales may grow. 'Last etc. would change.
>> >
>> > Why would you use 'Last or 'Succ on languages?
>>
>> No type can be exempt from general Ada semantics.
>> That's like asking why I would use 13 for Ada in the USA?
>
>I'm not saying the type should be exempt from the general semantics; I'm
>saying that the operations don't make sense in the context of language...

I noted in a previous message that allowing a changing enumeration would 
potentially cause various incompatibilities between versions which could be 
significant. (And none of them involve 'Succ or 'Last :-). There's a reason 
that Ada doesn't have implementation-defined enumeration types (the topic 
has been discussed a few times in various contexts).

That said, there has been an informal proposal to allow the declaration of 
unordered enumeration types. Such types would not allow 'Pred or 'Succ or 
any ordering operator. Not sure if anything will happen with that proposal 
(no formal one has happened to date - and it is not clear how that would 
work in relation to generic formal discrete types). But such a proposal 
would not eliminate the incompatibilities associated with a potentially 
changing set of enumeration literals.

                                 Randy.
; 

Re: gettext for Ada

[Blady]

Le dimanche 19 novembre 2017 21:40:55 UTC+1, Victor Porton a écrit :
> Where can I get a gettext bindings for Ada?
> 
> In 2009 there was a discussion on the same question, and the inquirer was 
> advised to use GtkAda.Intl in GtkAda.
> 
> It is not an ideal solution, because I do not want (me and my users) to 
> install GtkAda only to get gettext support.
> 
> Is there are less heavyweight solution?
> 
> -- 
> Victor Porton - http://portonvictor.org

Hello,
Zanyblue (http://zanyblue.sourceforge.net) is full Ada.
"Globalization is supported by the ZanyBlue text library by providing routines to access and format messages in Ada sources (the i18n aspect of g11n) and localization via the externalization of messages strings to properties files."
See example ConnectFour:
https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/demo/connect_four/
HTH, Pascal.