Re: Structuring the manual for a language front end.

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 12 Jun 2001, Robert Bernecky wrote:

> Back in The Dark Ages, we built a fairly large system that
> required multi-lingual message capabilities. We dealt with some
> of the same problems that come here -- word order differences,
> formatting differences, etc., across languages. From what I've
> seen so far, it looks like gcc is part way there, although
> I might be behind the times here.

I don't see how your message relates to the one to which it is a reply 
rather than to any of the threads on diagnostic formatting.

> a. Each distinct message to be issued had a serial number assigned
>   to it, basically an enumerated type. For example MSG1234 might
>   report a segmentation fault.

I think it has essentially been concluded for GNU that the gettext
approach (where the message text is the unique key rather than any magic
number) is to be preferred to the catgets approach.  See the arguments 
about gettext versus catgets in the gettext manual.  See also the threads 
I referenced in <URL:http://gcc.gnu.org/ml/gcc/2001-06/msg00640.html>.

>         "File %s2 not found in function %s3. There have been %d4 of
>          these errors on: %s1."
>    The % strings defined both the parameter number to be inserted
>    there as well as giving an indication of the type of formatting

Supporting $ operand numbers in the printf reimplementation in 
diagnostic.c is a small matter of programming.

> This scheme permits easy extension to other languages, but does not
> directly support fancier facilities, such as different wording for
> parameters that can be singular or plural. It's main advantage is

Plurals are supported by gettext, through the ngettext function.

-- 
Joseph S. Myers
jsm28@cam.ac.uk