bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Command line parsing of ls, tail and wc with genparse


From: Michael Geng
Subject: Re: [PATCH] Command line parsing of ls, tail and wc with genparse
Date: Sat, 6 Oct 2007 16:09:16 +0200
User-agent: Mutt/1.5.9i

On Sat, Oct 06, 2007 at 02:43:54PM +0200, Bruno Haible wrote:
> Hello Michael,
> 
> Regarding 
> http://lists.gnu.org/archive/html/bug-coreutils/2007-09/msg00129.html :
> 
> How does the internationalization of the usage strings work?
> 
> Usually generated files are not subject to xgettext scanning [1], only the
> source files are. (Otherwise when a translator wants to see some context,
> the tools show him some people of generated C code, beurk.)
> 
> The source file looks like this:
> 
> +/* genparse file starts here
> +#include <config.h>
> +#include <sys/types.h>
> +#include "system.h"
> +
> +c / bytes            flag    "print the byte counts"
> +m / chars            flag    "print the character counts"
> +l / lines            flag    "print the newline counts__NEW_PRINT__"
> +NONE / files0-from=F string  "read input from the files specified by"
> +                             "  NUL-terminated names in file F"
> +L / max-line-length  flag    "print the length of the longest line"
> +w / words            flag    "print the word counts__NEW_PRINT__"
> +#gp_include help_version.gp
> +
> +#usage_begin
> +Usage: __PROGRAM_NAME__ [OPTION]... [FILE]...
> +  or:  __PROGRAM_NAME__ [OPTION]... --files0-from=F__NEW_PRINT__
> +Print newline, word, and byte counts for each FILE, and a total line if
> +more than one FILE is specified.  With no FILE, or when FILE is -,
> +read standard input.
> +__GLOSSARY_GNU__(25)
> +__COMMAND__(emit_bug_reporting_address ())
> +#usage_end
> +genparse file ends here */
> 
> This is not the usual C syntax for strings. So, what I'm missing is:
> 
> - A patch to GNU xgettext so that it will support this syntax (extracting
>   strings from both the options and the usage part).
> 
> - A description of the syntax and an example how to place translator
>   comments, i.e. comments that the maintainer writes for the translators
>   (e.g. [2]).
>   Since /* ... */ is already taken, I assume you will need to introduce
>   another kind of comment syntax for this?
> 
> Bruno
> 
> 
> [1] 
> http://www.gnu.org/software/gettext/manual/html_node/po_002fPOTFILES_002ein.html
> [2] http://www.gnu.org/software/gettext/manual/html_node/Names.html

Hello Bruno,

I don't think that it makes sense to teach xgettext the syntax of genparse 
files. My intention is in fact to invoke xgettext on the parser files which 
genparse generates. For this reason my patch (from which you also extracted 
the portion above) adds src/ls-clp.c, src/tail-clp.c and src/wc-clp.c to 
po/POTFILES.in. 

You can look at those files from the genparse examples page which is accessible
through the genparse home page at http://genparse.sourceforge.net/. The genparse
file you extracted above is from the wc command. You can watch the genparse
generated parser for it from http://genparse.sourceforge.net/examples/wc_clp.c.
The __NEW_PRINT__ commands are set such that the text is partitioned exactly as
without this patch and you can verify with "make distcheck" that the existing 
translations still match.

Generally you are right, xgettext should not work on generated files, but I 
think
there will also be a huge benefit if existing translations do not break with a 
move 
to genparse.

Michael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]