From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-18 11:49:02 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!newsfeed.stueberl.de!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping Date: Sun, 18 Apr 2004 18:49:01 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <20040206174017.7E84F4C4114@lovelace.ada-france.org> <1073gv22t969q5a@corp.supernews.com> <40729B9D.30906@noplace.com> <1076000ef5oj06f@corp.supernews.com> <87d666wjq3.fsf@insalien.org> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1082314141 1490 134.91.1.34 (18 Apr 2004 18:49:01 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Sun, 18 Apr 2004 18:49:01 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:7311 Date: 2004-04-18T18:49:01+00:00 List-Id: David Starner wrote: : On Sat, 17 Apr 2004 22:38:43 +0000, Georg Bauhaus wrote: : :> Ludovic Brenta 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