Andreas Schwab <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Michael Geng) writes:
>
>> Is there a special reason why you use fprintf (... , stdout) and
>> fputs (stdout, ...) instead of printf and puts?
>
> Note that fputs (stdout) and puts are not the same.
Good point.
I'll bet that was why I
[EMAIL PROTECTED] (Michael Geng) writes:
> Is there a special reason why you use fprintf (... , stdout) and
> fputs (stdout, ...) instead of printf and puts?
Note that fputs (stdout) and puts are not the same.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH,
[EMAIL PROTECTED] (Michael Geng) wrote:
> On Sat, Oct 06, 2007 at 05:35:43PM +0200, Jim Meyering wrote:
>> [EMAIL PROTECTED] (Michael Geng) wrote:
>> ...
>> > file you extracted above is from the wc command. You can watch the genparse
>> > generated parser for it from
>> > http://genparse.sourcefo
On Sat, Oct 06, 2007 at 05:35:43PM +0200, Jim Meyering wrote:
> [EMAIL PROTECTED] (Michael Geng) wrote:
> ...
> > 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.
>
> It's nice to se
[EMAIL PROTECTED] (Michael Geng) wrote:
> On Sun, Oct 07, 2007 at 09:47:31AM +0200, Jim Meyering wrote:
>> [EMAIL PROTECTED] (Michael Geng) wrote:
>> ...
>> > The text is partitioned exactly as it is in the existing code of tail.c
>> > (I'm
>> > looking at a cvs archive copy from sept 9). This is
On Sun, Oct 07, 2007 at 09:47:31AM +0200, Jim Meyering wrote:
> [EMAIL PROTECTED] (Michael Geng) wrote:
> ...
> > The text is partitioned exactly as it is in the existing code of tail.c (I'm
> > looking at a cvs archive copy from sept 9). This is from tail.c:
>
> I think tail.c is still in sync, b
On Sun, Oct 07, 2007 at 02:48:43PM +0200, Bruno Haible wrote:
> Michael Geng wrote:
> > > 1) The gettext documentation [1] recommends to not make the _() arguments
> > > unnecessarily large.
> >
> > The text is partitioned exactly as it is in the existing code of tail.c
> > (I'm
> > looking at a
Michael Geng wrote:
> > 1) The gettext documentation [1] recommends to not make the _() arguments
> > unnecessarily large.
>
> The text is partitioned exactly as it is in the existing code of tail.c (I'm
> looking at a cvs archive copy from sept 9). This is from tail.c:
>
> fputs (_("\
>
On Sat, Oct 06, 2007 at 05:35:43PM +0200, Jim Meyering wrote:
> [EMAIL PROTECTED] (Michael Geng) wrote:
> ...
> > 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.
>
> It's nice to se
[EMAIL PROTECTED] (Michael Geng) wrote:
...
> The text is partitioned exactly as it is in the existing code of tail.c (I'm
> looking at a cvs archive copy from sept 9). This is from tail.c:
I think tail.c is still in sync, but...
Please don't use cvs anymore (use git instead).
Something went wron
On Sat, Oct 06, 2007 at 05:09:15PM +0200, Bruno Haible wrote:
> Michael Geng wrote:
> > My intention is in fact to invoke xgettext on the parser files which
> > genparse generates. ... You can watch the genparse
> > generated parser for it from
> > http://genparse.sourceforge.net/examples/wc_clp.
[EMAIL PROTECTED] (Michael Geng) wrote:
...
> 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.
It's nice to see the continuing improvements.
I noticed that you transformed the uses of f
Michael Geng wrote:
> My intention is in fact to invoke xgettext on the parser files which
> genparse generates. ... You can watch the genparse
> generated parser for it from
> http://genparse.sourceforge.net/examples/wc_clp.c.
OK, this kind of generated code is not bad; it's acceptable to have
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 scannin
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 so
15 matches
Mail list logo