Thoughts on improvement of the Camino Multilingual Release Process

The discussion about this started on the Camino l10n mailing list and Marcello asked me to write down my thoughts on this.
http://www.mozdev.org/pipermail/caminol10n/2007-June/002111.html

Currently it seems to me as Marcello collects all the localized data and repacks them into a Multilingual package based on the English one, which has been automatically created by Tinderbox (according to this article: http://wiki.caminobrowser.org/Status_Meetings:2006-10-11:Agenda)
In this article Marcello mentioned the thought putting all localization data in Camino's cvs.
From my point of view this will do some improvements:

• ability to automatically build a Camino Release, in English and Multilingual
• easier management of translations: if completed they can be moved (automatically?) into the release branch
• easier way of file management for translators

The negative aspects are already mentioned in the article above.

A way to make a cvs use more useful would be the use of a system taking care about the status of each translation. This is what I mentioned on the mailing list.
A server-side application (probably "simply" a web application combined with a Database) should save information like

• status of each file and whole translation, including which strings haven't been translated yet
• a system of reviewing, e.g. a file has to be validated by another person before it gets a 100% done status. This could help avoiding unreadable strings in nib files.

It should be combined with the (or a) cvs and automatically move completed languages in the appropriate release branch so an automatically build Camino Multilingual release can be made.
Developers could also mark files as "stable" or "kind of stable" so translators could start translation of files at an early point, and later on only translate the minor changes in these files. This would probably help releasing a Camino Multilingual version on time with more languages as work can be done over a longer period and not in two weeks or so. Also this would ensure that the translation is made on a "high level", improving the quality of Camino. Good work takes time, sometimes.

But this system also requires a client-side application, taking me to the next point.
As we now, AppleGlot is broken on Intel Macs and also not very useful.
A software like iLocalize is more the thing I wanted but unfortunately it's not for free and not extendable to use it with the above drawn scenario.
The solution would be the development of a new software for localization or adjustment of an existing open source project, if there is already one.
The new software should help the translator providing functions to easily show him/her where work is needed and how far the process has gone. It will also need funtions to use the cvs and of course to communicate with the server-side application.

Merging Camino L10n in the Camino development cvs and writing two new and useful applications.
Three points that would need a lot of hard work on and especially time.
The effect would be an easier to use and especially to manage system of creating a Camino Multilingual release, less work for the maintainer of Camino L10n (Marcello) and the several translation groups in coordinating the work and therfore more time for improving the translations and Camino.

Your thoughts are welcomed and needed if this should be realized one day.