This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gettext support for GCC 4.0 internal format, fix for PR translation/21364


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.)

> ftp://sunsite.mff.cuni.cz/private/gcc-l10n/l10n-bugs.bz2
> 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"
annotations.

Bruno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]