CVS and translations (was Re: Project Hosting)

[Christian Rose <menthos menthos com>]

Sorry for the lengthy response...


Zbigniew Chyla wrote:

> > I think a fundamental issue is being overlooked here. If we have no remotely
> > centralised CVS how are translators going to function. How is things like
> > mass document conversion for nautilus going to be organised.
>
> Thanks for mentioning translators in the discussion about ACLs and CVS
> accounts.
> Few days ago someone proposed creating some script to allow updating
> translations without CVS access and then removing "unneeded" accounts.

Personally, I'm not that positive about restricting CVS access for 
translators and only allowing access through a web or e-mail interface. 
I've used e-mail interfaces for submitting/retrieving translations 
before in other projects and since I learned to use CVS in gnome I 
definately don't want to go back.
I agree that it would be nice to allow this kind of feature for those 
who can't or don't want to use CVS, but I don't think it should be 
mandatory and "lot's of translator CVS accounts removed" in that 
process. I think that could be fatal.

The reason is that one of the advantages of CVS is control of the 
submission of your own work. By that I mean, when you've committed your 
work, you know your work *is* in and will be in the next release (unless 
*very* strange things happen).
Not so with other interfaces. When you submit your translations, you're 
dependant on the fact that not only CVS works, but also that the script 
backend for that interface works and will commit it rightly into CVS etc.
Let me just take the gnome translation status page on the web as an 
example. It is handled by a script that will often break. When it 
breaks, it will be days or even weeks until it is even noticed or 
fixed, for example if the maintainer of the script is on vacation (this 
has happened).

In the mean time, translation status is non-existing and translators 
don't know in what modules translations should be updated when strings 
have been added/changed. This is a big problem; basically translators 
are "lost" when the status isn't correct (I know I am). Right now, it 
isn't working for example, it hasn't been updated since Nov 30.

But even if the status isn't working, translators can still manage to 
update translations when they are noticed of the need in a particular 
module (for example when a module maintainer announces a pending new 
release to the gnome-i18n list).

Now think of the scenario where a new pending release of an important 
module is announced to the gnome-i18n list, translators translate and 
submit their translations via the interface, a couple of days pass and 
the module maintainer releases the new version.
*Then* it is nicely discovered that no new translations made it in 
because the submit-script happened to be broken all the time... That's 
what I'm very afraid of.

Even if the script maintainer should not be on vacation we all know that 
everyone isn't reachable all the time, sometimes people are away for a 
day or two. This could already be too much, because the "timeframe of 
notice to translators" we recommend to developers is two days: we wan't 
an announcement of a pending new version two days in advance to the 
actual release, so that we in the mean time can update the translations. 
If the submit-script doesn't work for one or two days, then...


> I'm one of the GNOME translators so let me ask you something. There are
> lots of files needing translations: famous .po files, files in .desktop
> format (.desktop, .directory, .profiles (gnome-print), .soundlist,
> ..gnorba (deprecated?)), .keys files (for gnome-vfs), lots of documentation
> in SGML format (placed in many directories) + images, files in XML format
> (.sheet (dia), .oafinfo (hopefully soon)), text files (gimp_tips.txt
> in GIMP), some application specific files (desc.* files in Gaby), etc.
> As I understand, you want to create appropriate script for _every_ file
> format (also for all new formats in the future) and hire someone to manage
> lists of these files (imagine adding translations to tens of new
> screensavers) and write new scripts?

I think that part of the discussion (not relevant to CVS policy) is 
probably more appropriate for the gnome-i18n gnome org list.

To answer your question: Yes, I think the goal is to be able to manage 
all types of translations, and the way to do it seems to be extracting 
strings from all the various formats into the applications single .pot 
file via the update script, and then copy them back on "make" of the 
application or directly hacking the app to get those strings from the 
relevant .po or something like that. Then there is only one central 
place for managing all the applications translateable content.
This has already been implemented for Glade XML resources by Kenneth.


Christian