Re: other/2857: i18n, translations does not work

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

The following reply was made to PR other/2857; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>, 
    Philipp Thomas <pthomas@suse.de>,  <Gabriel.Dos-Reis@cmla.ens-cachan.fr>, 
     <gcc-gnats@gcc.gnu.org>,  <gcc-bugs@gcc.gnu.org>, 
     <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 13:25:44 +0100 (BST)

 On Thu, 24 May 2001, Dennis Bjorklund wrote:
 
 > I don't think that is a requirement from fsf, but if that's how you people
 > want it. I talked with Philipp and last year, and then it was said that as
 > long as the paperwork is okay it doesn't matter.
 
 If we work differently from the standard FSF way - and, as long as the
 disclaimers are on file with the FSF and the people involved want to work
 otherwise, we can probably do so unless the FSF or SC say otherwise - then
 we should get the existing .pot and translations removed from the FSF
 translation system to avoid duplicated effort.
 
 > For example gnome keeps all the .po files in cvs (and not the .pot) and
 > let the translators send patches, or if they have write access to update
 > the files themself. And if someone needs help there is a mailinglist for
 > that. I think that is even simpler then the fsf system. One difference is
 > that fsf demands that you sign one of thier disclaimers and send in
 > first (i've done that).
 > 
 > I for one would like to keep the translation synced with the development
 > tree once it is complete. Even if that means I'll translate string that
 > will change again before the release. It's easier to keep the translation
 > up to date in that way. I don't see any use of having the .pot in the cvs
 > at all.
 
 If the people involved in translation for GCC want to work this way, then
 can you sort things out with the FSF people to avoid duplication, get in
 the old translations they have, and get the people who did them involved
 in updating them?
 
 The first priority is presumably getting up to date translations for the
 3.0 branch (and putting those on mainline as well, for now), before
 translating 3.1.
 
 Question: do the release scripts need to generate the compiled .gmo files?
 As those are binary, we surely don't want to put them in CVS.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk