Re: New Spanish PO file for `gcc'

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 4 Dec 2001, Martin v. Loewis wrote:

> Because translating such a large catalog takes many months to
> complete. Translators will usually not stop in the middle of their
> work. Instead, they will continue to translate, and submit their
> translation. They work at their own pace; it doesn't help to interfere
> or tell them what to do (just like translators shouldn't interfere
> with the maintainers, by demanding that they release a new version of
> the software just because they have completed a translation).

I'd presumed they'd update their in-progress work with a new .pot if one
comes out while they're working (rather than continuing to translate
messages that are no longer in GCC).

> > Can that antique .pot file be removed from the translation project
> > to avoid other translators using it?
> 
> No. Please understand that the translation is *not* of "little
> use". Instead, many messages will be useful unmodified in gcc 3.0;
> others may need slight modifications. Please don't diminish the effort
> that translators have put into this as "antique".

It is the .pot file I am saying is antique, not the translations.  I want
the efforts of the translators to be of maximal use, which seems to me to
mean always working from as current a .pot as possible.

> > Can such files be sent in gzip form (since some may approach or
> > exceed the 400k message size limit on gcc-patches)?
> 
> Not easily, although we may be able to work something out. One thing
> that can be done easily is to leave out the actual catalog, and only
> send an URL where to download the file. If that is desirable, I can
> change it right away. 

I think having them on gcc-patches is useful - but given that one such
notice <URL:http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00046.html> was
sent without the message with the .po file actually appearing, I suspect
that one must have been over the 400k limit, and compression would make
them more useful by making more of the actually reach gcc-patches.

> In the specific case of gcc, I think it would be useful to provide a
> PO template at the time the 3.1 branch is created, and perhaps another
> one shortly before the release. Please understand that it is
> absolutely not necessary that all messages are translated: users may
> never see some of the messages, so they'll get the impression that
> everything is translated even if it isn't.

Wouldn't the feature freeze on the 15th be a good date?  After then
messages will still change in the course of bug fixing, but there should
be fewer changes that there would be while non-bugfix changes are being
made.

> Every translations supercedes the previous one. For projects that
> maintain two branches (previous/current release) over a long time, we
> can arrange it to have two "active" templates. For gcc 3, if there
> will be a 3.0.3 release, it may be reasonable to publish an update for
> the 3.0 template, while also comtemplating publishing a version of the
> 3.1 catalog.
> 
> While I have your attention, may I ask that
> 
> http://gcc.gnu.org/ml/gcc/2001-11/msg00549.html
> 
> gets a response? There is a number of existing translations which
> don't show up in the GCC CVS. I'm willing to commit them if nobody
> else does, but I feel I need approval.

It isn't for me to approve the addition of these translations to CVS.  My
understanding is that properly working translation requires a lot of
Zack's changes that are on the mainline only, not the 3.0 branch, and so
these translations should go on the mainline only (with the aim of making
3.1 the first release properly supporting translation).  Ask the i18n
maintainer (Philipp Thomas).  Note that diffs between minor releases where
translations are added or changes made to them are completely untested -
the release script uses diff -a so that diffs between the .gmo files may
work, but until we try this we won't know whether this causes problems for
too many versions of patch, and 3.1.1 might be a better time for testing
this than 3.0.3.

-- 
Joseph S. Myers
jsm28@cam.ac.uk