Ada and Internationalization

Ada and Internationalization

[Michael Rohan]

Hi Folks,

I've checked Google and have not been able to find anything in Ada out
there for internationalized code.  There's support for Wide_Character
and Wide_Wide_Character but there doesn't seem to be libraries for
message strings.  Before starting down the path of writing from
scratch, wanted to check.

If nothing is available, I was considering taking Java .properties
files, somehow "compiling" them into an Ada package and implementing
something akin to Java's MessageFormat:

   Arguments : Message_Arguments;
   ...
   Arguments.Append ("a string");
   Arguments.Append (10);
   Arguments.Append (Pi);
   Put_Line (Message_Format ("facility", "msg001", Arguments));

Take care,
Michael.

Re: Ada and Internationalization

[Ludovic Brenta]

"Michael Rohan" <mrohan@ACM.ORG> writes:
> I've checked Google and have not been able to find anything in Ada out
> there for internationalized code.  There's support for Wide_Character
> and Wide_Wide_Character but there doesn't seem to be libraries for
> message strings.  Before starting down the path of writing from
> scratch, wanted to check.

GtkAda contains a binding to GNU gettext.  Look at
http://libre.adacore.com/GtkAda .

BTW, with GNU gettext, your internal encoding is likely to be UTF-8,
so you wouldn't be using Wide_Character or Wide_Wide_Character.

-- 
Ludovic Brenta.

Re: Ada and Internationalization

[Dmitry A. Kazakov]

On 30 May 2006 16:12:35 -0700, Michael Rohan wrote:

> I've checked Google and have not been able to find anything in Ada out
> there for internationalized code.  There's support for Wide_Character
> and Wide_Wide_Character but there doesn't seem to be libraries for
> message strings.  Before starting down the path of writing from
> scratch, wanted to check.
> 
> If nothing is available, I was considering taking Java .properties
> files, somehow "compiling" them into an Ada package and implementing
> something akin to Java's MessageFormat:
> 
>    Arguments : Message_Arguments;
>    ...
>    Arguments.Append ("a string");
>    Arguments.Append (10);
>    Arguments.Append (Pi);
>    Put_Line (Message_Format ("facility", "msg001", Arguments));

I don't see how this is related to internationalization. It looks like 
stream communication (see S"Output attribute) or string formatting. In 
either case you convert data to/from stream/string.

For strings I have a small library which works this way, it has UTF-8 
support.

http://www.dmitry-kazakov.de/ada/strings_edit.htm

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

Re: Ada and Internationalization

[Georg Bauhaus]

On Tue, 2006-05-30 at 16:12 -0700, Michael Rohan wrote:
> Hi Folks,
> 
> I've checked Google and have not been able to find anything in Ada out
> there for internationalized code. 

When I do this, I make message printing suitable
for several languages right from the start, taking advantage
of the Ada type system. Collect the messages in an enumeration
type, i.e., name them. Then build an (abstract) Message type around
this enumeration. Then derive (compose) one type for each natural
language.

Advantages:

- Ada's coverage rules will make sure that translation won't
miss a single message.

- You can easily create an external messages collection for the
translators in XML, Excel, plain text, even gettext if you must,
because of the mentioned properties of the message type:
You have it in your program, so just write another main unit
that basically enumerates the values in the types made for
the messages, using the desired output format.

- No need to analyze the entire program using external tools,
no need to touch sources.


Disadvantage:

- It's not gettext, only Ada, so maybe it's less fashionable.

- It also requires that a programmer considers messages important
enough to be worthy of a type that can be checked by the compiler.


Using a Message type and the .properties approach are somewhat
similar, except that with a type, you won't have to leave the Ada
language: add the properties to a library package, e.g. in
constants, roughly:

   (en_US => (got_foo => ...,
              no_bar_please => ...,
              argh => ...),

   (fr_CA => (got_foo => ...,
              no_bar_please => ...,
              arhg => ...),
   ...


Georg 

Re: Ada and Internationalization

[James Dennett]

Dmitry A. Kazakov wrote:
> On 30 May 2006 16:12:35 -0700, Michael Rohan wrote:
> 
>> I've checked Google and have not been able to find anything in Ada out
>> there for internationalized code.  There's support for Wide_Character
>> and Wide_Wide_Character but there doesn't seem to be libraries for
>> message strings.  Before starting down the path of writing from
>> scratch, wanted to check.
>>
>> If nothing is available, I was considering taking Java .properties
>> files, somehow "compiling" them into an Ada package and implementing
>> something akin to Java's MessageFormat:
>>
>>    Arguments : Message_Arguments;
>>    ...
>>    Arguments.Append ("a string");
>>    Arguments.Append (10);
>>    Arguments.Append (Pi);
>>    Put_Line (Message_Format ("facility", "msg001", Arguments));
> 
> I don't see how this is related to internationalization. It looks like 
> stream communication (see S"Output attribute) or string formatting. In 
> either case you convert data to/from stream/string.

Formatting of strings for human readers needs to produce
output that is correctly localized, hence is always an
issue in an internationalized program, non?

-- James

Re: Ada and Internationalization

[Dmitry A. Kazakov]

On Wed, 31 May 2006 07:53:36 -0700, James Dennett wrote:

> Dmitry A. Kazakov wrote:

>> I don't see how this is related to internationalization. It looks like 
>> stream communication (see S"Output attribute) or string formatting. In 
>> either case you convert data to/from stream/string.
> 
> Formatting of strings for human readers needs to produce
> output that is correctly localized, hence is always an
> issue in an internationalized program, non?

I am not sure. It looks like a question of content. Formatting is a quite
low level thing. Mixing content and formatting can turn very surprising.
There are right-to-left and top-down languages, word ordering might change,
their number as well, numerals, ordinals, articles, inflexions etc.

[ Both as a customer and vendor I always try to avoid internationalized
programs. (:-)) ]

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

Re: Ada and Internationalization

[James Dennett]

Dmitry A. Kazakov wrote:
> On Wed, 31 May 2006 07:53:36 -0700, James Dennett wrote:
> 
>> Dmitry A. Kazakov wrote:
> 
>>> I don't see how this is related to internationalization. It looks like 
>>> stream communication (see S"Output attribute) or string formatting. In 
>>> either case you convert data to/from stream/string.
>> Formatting of strings for human readers needs to produce
>> output that is correctly localized, hence is always an
>> issue in an internationalized program, non?
> 
> I am not sure. It looks like a question of content. Formatting is a quite
> low level thing. Mixing content and formatting can turn very surprising.
> There are right-to-left and top-down languages, word ordering might change,
> their number as well, numerals, ordinals, articles, inflexions etc.

And these are included in my notion of internationalized
formatting, though for a wide range of languages we can
get away with supporting left-to-right, and just dealing
with issues of phrase lookup, word ordering and cardinality.

> [ Both as a customer and vendor I always try to avoid internationalized
> programs. (:-)) ]

That is increasingly difficult in many domains, though it's
certainly true that programming is somewhat simpler when
I18N is not a factor.

-- James

Re: Ada and Internationalization

[Dmitry A. Kazakov]

On Wed, 31 May 2006 08:27:38 -0700, James Dennett wrote:

> Dmitry A. Kazakov wrote:
>> On Wed, 31 May 2006 07:53:36 -0700, James Dennett wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>> 
>>>> I don't see how this is related to internationalization. It looks like 
>>>> stream communication (see S"Output attribute) or string formatting. In 
>>>> either case you convert data to/from stream/string.
>>> Formatting of strings for human readers needs to produce
>>> output that is correctly localized, hence is always an
>>> issue in an internationalized program, non?
>> 
>> I am not sure. It looks like a question of content. Formatting is a quite
>> low level thing. Mixing content and formatting can turn very surprising.
>> There are right-to-left and top-down languages, word ordering might change,
>> their number as well, numerals, ordinals, articles, inflexions etc.
> 
> And these are included in my notion of internationalized
> formatting, though for a wide range of languages we can
> get away with supporting left-to-right, and just dealing
> with issues of phrase lookup, word ordering and cardinality.

OK, but even then the target cannot be a simple stupid object like stream
or string. It should know how to translate a sequence of "precompiled"
objects into a proper sentence. There is a danger that it might quickly
become double dispatching, the thing we cannot effectively do in Ada.
Alternatively the target object should know the language and be intelligent
to determine parts of speech...

So I'd try to stay as much as possible on the side of objects being output.
They should know how to translate themselves according to the target
locale.

In a recent project I had a similar problem. In place of localization there
were different rendering devices: Text, HTML, GTK etc. It ended up with a
primitive operation defined on objects, that had a class-wide argument
controlling the output parameters. Needless to say, that I am not satisfied
with this design.

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

Re: Ada and Internationalization

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1b6kk4c3suwjg.84fral2281gm$.dlg@40tude.net...
...
> In a recent project I had a similar problem. In place of localization
there
> were different rendering devices: Text, HTML, GTK etc. It ended up with a
> primitive operation defined on objects, that had a class-wide argument
> controlling the output parameters. Needless to say, that I am not
satisfied
> with this design.

I had a similar problem with the formatting tool that produces the Ada
Reference Manual and other good stuff. (In fact, it is essentially the same
problem.) I ended up defining an "output object" abstract type, with
instances of the type for text, HTML, and RTF. The needed operations for
formatting and the like are defined for the abstract type. The formatting
engine takes an output object and writes to it as needed.

The design was fairly successful; Stephen Leake created a new type and
object to support TextInfo output. He was able to do that fairly
successfully with the interface already provided.

                         Randy Brukardt

Re: Ada and Internationalization

[Stephen Leake]

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

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1b6kk4c3suwjg.84fral2281gm$.dlg@40tude.net...
> ...
>> In a recent project I had a similar problem. In place of localization
> there
>> were different rendering devices: Text, HTML, GTK etc. It ended up with a
>> primitive operation defined on objects, that had a class-wide argument
>> controlling the output parameters. Needless to say, that I am not
> satisfied
>> with this design.
>
> I had a similar problem with the formatting tool that produces the Ada
> Reference Manual and other good stuff. (In fact, it is essentially the same
> problem.) I ended up defining an "output object" abstract type, with
> instances of the type for text, HTML, and RTF. The needed operations for
> formatting and the like are defined for the abstract type. The formatting
> engine takes an output object and writes to it as needed.
>
> The design was fairly successful; Stephen Leake created a new type and
> object to support TextInfo output. 

That's "TexInfo" :)

> He was able to do that fairly successfully with the interface
> already provided.

Yes, it is a good design.

Can't wait to do it again for Ada 2005 (2006?). Any update on the
schedule for that? I gather we are waiting for the ISO process to
grind thru.

-- 
-- Stephe

Re: Ada and Internationalization

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:ur725hx6s.fsf@acm.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:1b6kk4c3suwjg.84fral2281gm$.dlg@40tude.net...
> > ...
> >> In a recent project I had a similar problem. In place of localization
> > there
> >> were different rendering devices: Text, HTML, GTK etc. It ended up with
a
> >> primitive operation defined on objects, that had a class-wide argument
> >> controlling the output parameters. Needless to say, that I am not
> > satisfied
> >> with this design.
> >
> > I had a similar problem with the formatting tool that produces the Ada
> > Reference Manual and other good stuff. (In fact, it is essentially the
same
> > problem.) I ended up defining an "output object" abstract type, with
> > instances of the type for text, HTML, and RTF. The needed operations for
> > formatting and the like are defined for the abstract type. The
formatting
> > engine takes an output object and writes to it as needed.
> >
> > The design was fairly successful; Stephen Leake created a new type and
> > object to support TextInfo output.
>
> That's "TexInfo" :)
>
> > He was able to do that fairly successfully with the interface
> > already provided.
>
> Yes, it is a good design.
>
> Can't wait to do it again for Ada 2005 (2006?). Any update on the
> schedule for that? I gather we are waiting for the ISO process to
> grind thru.

Yes, I'm waiting for Ada Europe to give the go-ahead to make the final
version. Until then, it's kinda in limbo. I should really coordinate with
you so you can start your work on this now (there shouldn't be many changes
to the interface at this point). Ping me about this when I get back from the
meetings (which are next week).

                         Randy.