This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Special handling of "%H" (Re: Support for %d$c format specifierin diagnostics.c)
On Thu, 31 Jul 2003, Ishikawa wrote:
> Ok, while I am waiting for the patch to support positional format
> specifiers in diagnostic (and formated output) routines being merged
> into mainline tree (hint, hint), I looked at
For the detailed review process to start, please submit a version of the
patch formatted according to the GNU Coding Standards. (There may then
need to be several rounds of technical review of the patch following
that.)
> I ran this modified msgfmt on the PO files under
> gcc/gcc/po directory.
>
> Funny, there was NO warning at all!
Please investigate why the specific translations there have been bug
reports about (e.g. bug 9390) did not generate warnings - have those
problems been fixed, or have the messages changed so that the translation
is now fuzzy?
> Now I believe that translators without being able to obtain help about
> unknown format-like specifiers such as %H, %T, %D simply marked dubious
> translation as "fuzzy" so that msgfmt won't complain :-(
Translators do not mark translations fuzzy - msgmerge does; see the
gettext manual. The sequence is: a translator translates a message
(possibly three years or more ago) that is in a particular version of GCC.
Later, a new version of GCC with an updated gcc.pot comes out. msgmerge
is run to merge the new gcc.pot with the old .po file. Entirely new
messages get listed with "" as translation, while messages that are
similar to the old ones get listed with the old translation marked as
fuzzy. In both cases, manual work by a translator is needed before the
message can be translated in GCC output, but the fuzzy translation serves
as a hint to the translator to reduce translation effort. (The *only*
function of a fuzzy message is as a hint to the translator, who may be
able to update it to the changed message quicker than doing a whole new
translation.)
> I found out that some translation simply ripped out %H, and other
> non-standard format specifiers (and leave familiar
> specifiers such as %s). Agh.
They did not. The old message had %s and no %H; they translated that.
Then the message in GCC changed to use %H, %D, etc. - so msgmerge marked
the translation fuzzy (after all, all the translator probably needs to do
is update the translation to use %H, %D, etc. - not retranslate the text)
- and the translator hasn't yet got back to that message to update it for
the change in GCC.
> It seems that most of the PO files were rather outdated. (At least
> the ones under my gcc mainline cvs check out hierarchy.)
Some mainline files may be out of date, because Mark checked updated files
into the 3.3 branch only before the release. Anyone with CVS write access
may download the current files from the TP site (see translation.html for
details) and check them into mainline CVS (check with Mark before updating
the branch files, but I suspect any updates of those will be welcome as
well as it saves work just before the release). Anyone may also
regenerate gcc.pot on mainline (with current gettext) if they want.
Note that translators only work on .pot files from release branches. So
changes to messages since 3.3 was branched will not be reflected in
translation work until 3.4 has branched and a new .pot file has been sent
to the TP. There is a finite translation effort and mainline is rather a
moving target, so we only try to have translators working on translations
of the most recent release branch.
> We need some serious awareness campaign efforts to the translation
> community to fix this state of the affairs by offering the improved
> tool and hopefully the positional parameter support soon. (I attach
> the draft note to translation community. Comments/feedback welcome.)
Please *only* discuss what is GCC-specific - i.e., the GCC-specific
formats and usage of %H. Translators will generally already know about
printf formats in general and positional parameters. The general parts of
the documentation might be of use in a general document for new
translators, but you'll need to work with the TP and gettext maintainers -
not the GCC maintainers - regarding getting such text into any such
document.
--
Joseph S. Myers
jsm@polyomino.org.uk