From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: other/2857: i18n, translations does not work Date: Thu, 24 May 2001 05:36:00 -0000 Message-id: <20010524123602.23124.qmail@sourceware.cygnus.com> X-SW-Source: 2001-05/msg00717.html List-Id: The following reply was made to PR other/2857; it has been noted by GNATS. From: "Joseph S. Myers" To: Dennis Bjorklund Cc: Zack Weinberg , Mark Mitchell , Philipp Thomas , , , , 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