This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] gettext support for GCC 4.0 internal format, fix for PR translation/21364
- From: Bruno Haible <bruno at clisp dot org>
- To: Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, translation at iro dot umontreal dot ca
- Date: Mon, 30 May 2005 18:54:31 +0200
- Subject: Re: [PATCH] gettext support for GCC 4.0 internal format, fix for PR translation/21364
- References: <20050517113757.GD4930@devserv.devel.redhat.com> <Pine.LNX.email@example.com> <20050518170635.GB22344@sunsite.mff.cuni.cz>
Jakub Jelinek wrote:
> Ok, I wrote the necessary gettext support for the newly intoduced format
> string stuff
Thanks a lot. I have put out a new gettext-0.14.5 release that contains
support for GCC-4.0 format strings. (Based on your patch, plus additional
checking of %m directives, plus testsuite updates.)
> contains all errors it found (well, if there is already one bug reported
> for a msgid/msgstr pair, I have not included the rest of bugs), including
> fuzzy strings.
One cannot consider problems in fuzzy msgstrs as bugs, since these msgstrs
are not put into .mo files.
> Note that I have just used --language=GCC-source
Yes, this option should be used by gcc/po/exgettext.
> Where the solution was obvious, I have fixed the format string, where
> it was not obvious, I have added ", fuzzy"
Generally developers and maintainers should not interfere with the
responsibilities of the translators. Adding "#, fuzzy", as a stopgap
measure, is acceptable, since it gives back the responsibility to the
translator. However, changing the translation of a string in the PO file
is something a developer or maintainer should NEVER EVER do. Even if it
is your own mother tongue - the translators are assumed to have better
language skills than the developers have.
To fix this problem, the following steps are appropriate:
1) The gettext maintainer puts out a new gettext-0.14.5 release that
contains support for GCC-4.0.
2) The TP maintainers install this gettext-0.14.5 release for use by
the TP's robot.
3) The GCC i18n maintainer ensures that gettext >= 0.14.5 is used for
constructing the gcc.pot file.
4) The GCC i18n maintainer regenerates the gcc.pot file (it should
contain many "#, gcc-internal-format" annotations this time), and
submits it to the TP.
5) The GCC i18n maintainer does an 'msgmerge' of this new gcc.pot file
with the original .po files, using gettext >= 0.14.5. This will
automatically mark those messages as fuzzy that are not valid, matching
format strings. This step obsoletes Jakub's gcc41-po-fixes.patch.
6) The GCC i18n maintainer receives through the TP the updated translations
from the translators.
Steps 1 and 2 have already been done. You can go ahead with step 3 to 6.
Joseph S. Myers wrote:
> The fact is, when new .po files appear they will be committed from the TP
> versions without question, whether they are manually updated ones sent to
> gcc-patches by the TP Robot (I have de.po and zh_CN.po files recently sent
> to the list queued to commit) or auto-updated ones merged with a new .pot
> file. So changing the GCC without getting the change upstream is useless.
Yes. That's why it's essential that you resubmit a gcc.pot file to the TP
once you have ensured that it has the necessary "#, gcc-internal-format"