[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#147624: gettext: xgettext seems vaguely unaware of pot extension
From: |
Mark Eichin |
Subject: |
Re: Bug#147624: gettext: xgettext seems vaguely unaware of pot extension (fwd) |
Date: |
21 May 2002 10:26:30 -0400 |
> It's not clear what you consider inconsistent.
The texinfo doc consistently (following the "picture") refers to the
PO Template and .pot file as the output resulting from xgettext:
| .-----<--- PACKAGE.pot <--- xgettext <---'
In reality, xgettext never outputs a .pot file -- by default it
outputs a domain-argument.po (or messages.po) file instead. The
default output should be consistent with what the workflow document
says is going on -- at very least it helps a gettext user (ie. a
developer) know that he's in the right place.
To further clarify, I'm talking about the filenames, not the content;
xgettext does generate the "right" content for a .pot file, just
doesn't name it like one.
> Do you suggest that some functionality be removed from xgettext?
No, unless "generating the file with the wrong name" is the
functionality you mean :-)
I'll note that in this case, I've found (since reporting this) that I
can take advantage of the current behavior by having a make rule:
xgettext -D . -D .. -d "$D" --keyword="N_" --keyword="_"
--keyword="translate" -f POTFILES.in
msgmerge --update $D.pot $D.po
rm $D.po
so later xgettext runs only merge in new values, so maybe it is
useful after all. Really, though, -j should be doing this [there's
another outstanding bugreport on that though.]