GCC2 native language support now available

François Pinard pinard@iro.umontreal.ca
Sun Sep 27 13:16:00 GMT 1998

Hello, Paul.  You wrote to <translation@iro.umontreal.ca>:

> A new experimental version of GCC2 has native language support (NLS), so
> that it can generate diagnostics in languages other than the English
> default.  Please see: ftp://vger.rutgers.edu:/pub/gcc/ss-980813.tar.gz
> which contains a file ABOUT-GCC-NLS that explains the current status.

Following your invitation, I fetched the multi-megabyte distribution above and
extracted the said 18K file out of it.  It would be have been simpler that you
just send the file :-).  It essentially contains patches to `gettext'.

> So far, the only translation available is en_UK (British English),

Yes, the same as you did for `diffutils', years ago.

> and it is present mostly to test the NLS mechanism; for this reason, NLS is
> now disabled by default.

The distribution you made available apparently does not contain a POT file:

   0 pinard@raptor:~/tmp $ tar xfz ss-980813.tar.gz
   0 pinard@raptor:~/tmp $ find testgcc-980813 -name '*.po*'
   0 pinard@raptor:~/tmp $ find testgcc-980813 -name '*.pot'
   0 pinard@raptor:~/tmp $

> However, once translations to other languages are made available I would
> like to fold them into the distribution and enable NLS by default, as is
> done for other GNU packages.

If you want other translations, I suggest that you make the POT file available
to me, so I can upload it to the PO archives.  I'm appending a blurb, at end
of this message, meant for maintainers of newly internationalised packages.

Just for fun, I applied an old, picky and terse tool I made to check PO file
submissions, and got:

   0 pinard@raptor:~/tmp $ po-check testgcc-980813/po/en_UK.po

   Processing file `testgcc-980813/po/en_UK.po'
     Missing template `/home/ftp/pub/po/pot/-.pot'
   | :1: British English messages for GNU GCC
   testgcc-980813/po/en_UK.po:2: Invalid copyright format
   | :4:
   testgcc-980813/po/en_UK.po:7: Invalid version `'
   testgcc-980813/po/en_UK.po:0: No such translator `Paul Eggert' in `en'
   field `Project-Id-Version' still has initial default value
   found 1 fatal errors

The fatal error was detected by `msgfmt', the PO file compiler that comes
within `gettext'.

As for the choice of PACKAGE VERSION (PACKAGE is a misnomer here, it is really
meant to be the textual domain name), we are not set for handling dates as
versions, or to compare dates to version numbers and decide of the
chronological order.  It is best to use a uniform versioning scheme within a
single package.  If you really need and want to use dates, please describe
your scheme exactly to me, and I'll modify the translation project scripts
accordingly.  Let me suggest that you use `cc', with no capitals and no prefix
`g', for a single domain name.  If you think you need many textual domain
names, please also discuss the matter beforehand, as we try to achieve some
uniformity for them.

Hello, I hope you will not mind a canned reply.  You wrote to the translation
team coordinator, exploring how to use the Free Translation Project for your
package, but do not know exactly how or where to start.  Here is some advice.

The usual steps for internationalising messages in a package, as seen
from the maintainer viewpoint, are:

 1) mark translatable strings,
 2) modify main() to activate translation,
 3) add some Autoconf and Makefile magic,
 4) submit POT files to the translation project,
 5) be kind to national teams.

You might be quite familiar already with the first three steps, so I will
not elaborate on them for now.  (This canned reply is under construction.
There are surely a lot of things to chat about, but I'm just trying to
keep to the essentials, at least as I see them today :-).

| Submit POT files.  |

If you generated the POT file using a recent *pretest* of `gettext', the
POT file header should be correct as it stands, and resembles an unfilled
form, except for POT-Creation-Date, which has been filled automatically.
Do not try to fill it in any way.  (It might happen that Project-Id-Version
be filled in automatically at some later time, but from the time being,
leave it unfilled.)  The translators, exclusively, should take care of
the filling.  If you generated the POT file using other tools, or old
copies of `gettext' (including the official copy at the FSF), you should
make sure that the PO file header looks like virgin headers as above.
The Translation Project is very fussy about header conformance.

In your distribution, the POT file is probably named `po/PACKAGE.pot',
where PACKAGE is the name of your package.  Within the translation project,
your POT file is named `DOMAIN-VERSION.pot'.  DOMAIN is the textual domain
for your package, often the same as PACKAGE, but surely, all in lower case,
and with `gnu' or `g' prefixes removed.  VERSION may have one of the forms
N.M, N.M.O, or N.M-bO, using all numbers, or N.ML, where L is a lower
case letter.  (I should check this more closely.)  The translation project
needs being able to compare two VERSION and decides how to order them.
`N.M' comes before any `N.M.O' or `N.ML', but after any `N.M-bO'.  `N',
`M' and `O' are compared by their numerical value, and `L' is compared
lexicographically.  If for some reason, you just cannot use any of the
above schemes, please discuss this with the translation coordinator,
so the translation project might have to be adjusted for your package.

Please send ready POT files to `translation@iro.umontreal.ca', using MIME,
`mailshar', `uuencode' or any other popular means ensuring its integral
transmission.  Use the string "DOMAIN-VERSION.pot" somewhere in the
subject line of your invoice.  (The translation project robot will not
accept processing POT files directly without some authentication scheme,
and none is set up currently.)  A POT file may only be processed once by
the translation project.  Another submission *must* use a newer VERSION.

If this is easily doable for you, accompany or preceede your submission by
a message to the same address, telling some URL where translators could
find a distribution corresponding to your POT file.  Such distribution
does not have to be otherwise official, it does not even have to compile:
its goal is only to provide finer context for strings to be translated,
whenever translators need such references.  Of course, the URL will be
published to national teams.

The very first time you submit a POT file, the translation project also
need to know which email address to use for notifications, and if you want
PO files sent in full to you (instead of a mere URL where to find them).

You should also decide if you require translation disclaimers or not for
your package.  Translation disclaimers are written papers, kept by the Free
Software Foundation, meant to prove that the translation is freely usable,
if such proof is ever needed.  For packages meant to be distributed by the
FSF, you should normally require them.  For non-GNU packages, the safest
is to require them, yet some translators object to these disclaimers.

For the translation project to accept a PO file submission, the translator
should be already clear with the FSF, for when disclaimers are required
for the package, and the translator should be also clear with the proper
national team for submitting PO files directly for the given package.
This gives some mean to teams wanting to distribute the work load or to
ensure some quality level.

| Be nice to teams.  |

You may submit POT files as often as you want.  You might try to not
exhaust translation teams by overflowing them, but maybe this might also
be over-protective.  So far, we never received a complaint.

Please do everything in your power to respect the autonomy of translation
teams.  Do not try to push nor pull on teams or translators, or otherwise
interfere with them.  If a team does not work fast enough to your taste,
this is a matter between the team and the users for that national language,
don't take that responsibility of teams on your shoulders.  In fact, let the
teams solve their own problems if any, never *never* try to arbitrate them.
The teams are warrant of the linguistic quality of their translations, each
team sets its own methods, priorities and goals, and teams should ultimately
decide if they let individual translators submit PO files (this is what
most do), or want to revise them first.  It would defeat the purpose of the
teams if you were directly accepting PO files from individual translators,
or were having "contracts" with them.  If people write to you, wanting to
volunteer as translators, direct them to `translation@iro.umontreal.ca',
and the translation coordinator will send them appropriate documentation.

Translators now have efficient means, which they are free to use or not,
for sending PO files to the translation project in such a way that they get
automatically validated, somewhat corrected for minor things, and uploaded
to PO central archives.  You get notified right away.  It can be made a
quick process.

As a maintainer, keep well split your perception of responsibilities.
You are responsible of the programming quality of your package, but national
teams are solely responsible for the linguistic quality of translations.
If you ever receive linguistic gripes from users, direct users and gripes
to national teams.  To find where to forward linguistic problems for some
language LL and the textual domain DOMAIN of your package, try this:

	LANGUAGE=LL gettext DOMAIN '' | grep Language-Team

or using `csh' syntax:

	(setenv LANGUAGE LL; gettext DOMAIN '') | grep Language-Team

If any other question remains, be comfortable enough to ask them to
`translation@iro.umontreal.ca'.  I'm much slower than the translation
project robot, but I'll be happy to help if I can.

				Your translation coordinator


François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

More information about the Gcc mailing list