CVS and translations (was Re: Project Hosting)

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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]