Re: No call for Ada (was Re: Announcing new scripting/prototyping

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

David Starner <dvdeug@email.ro> wrote:
: On Sat, 17 Apr 2004 22:38:43 +0000, Georg Bauhaus wrote:
: 
:> Ludovic Brenta <ludovic.brenta@insalien.org> wrote:
:>  
:> 
:> : If you have strings
:> : meant for display to the end user, you should place them in a separate
:> : file and use gettext.
:> 
:> Ada is enough here I think, and has the advantage that you can
:> have an Ada compiler check the completeness of messages.
: 
: Problem #1: Translators don't necessarily know programming, and hence may
: mangle the code.

This looks like a problem with .po files as well as with Ada files.
One cannot automatically assume the existence of tools for one
or the other.

Translation between the Ada table shown and .po files isn't
difficult either. Only you don't need to scan the whole Ada program
for text message candidates. Which in a sense is like I/O sprinkled
all over the place. It smells like an aid for the lazy programmer
who doesn't want to be drawn into the "modularisation of messages".

: Problem #2: Instead of 2 message, 2 language table, imagine a 500
: message, 50 language table, which is being done in Gnome and KDE.

So what? Serious software development can't treat messages to
computer users like something that can be done just half way.

Or are you referring to the size of a complete table?

: Problem #3: There's dozens of tools out there that handle gettext (.po)
: files, include translation memories and other useful things. 

o.K.


: Problem #4: Even in theory, it would be much harder to write a tool to
: extract messages from a table embedded in source code and process them

In the Ada I gave it's trivial!  You just need to with and
use the message packages, program fragment below.
The existence of the .po extraction mechanism might be
caused by the failure to recognize that with true enumerations
in array declarations there is *no*need* for extraction!

Here is an excerpt from a 60 lines program that inserts default
(English) messages where a translation is missing.

   for L in Language loop
      for ID in Msg_ID loop

         if is_empty(Message(L)(ID)) then
            replacement := default_msg_list(ID);
         else
            replacement := Message(L)(ID);  -- leave untouched
         end if;

         put_line(Msg_ID'wide_image(ID)
                  & " => new Wide_String'"
                  & "("""
                  & replacement.all
                  & """)");
      end loop;
   end loop;


 
: Problem #5: Your format doesn't handle real-life issues where an error
: message is added late, and is only translated into Japanese, so you don't
: have complete translations, but they're far better than dropping back to
: English completely. (Any solution to this is going to exasperate #1 and #4
: and probably #2 as well.)

Why, with the above, and with the language/ID indexing of Message,
should I be dropping back to English *completely*?

The mechanism does need recompilation of the Ada source file containing
all(!) the messages. But if a message is changed, everything else
is likely to be unaffected. Completeness of messages can be checked
by an Ada compiler. No additional tools needed. No library calls
necessary that perform table lookup using strings.

(I'm not against a message file mechanism, but I'd prefer one
that isn't based on additional parsers. And please one that uses
a enumerated *types* to stand for all the messages.)

Problems not easily solved by either mechanism:  incompatible
grammars of natural languages, length of messages affecting
the program's output.

: Would you write your build-system in Ada instead of Make? Use the right
: tool for the job.

Right, and don't create an unnecessary job in the first place!
(BTW, I don't see what make has got to do with this?)


Georg