Christian, Denis,I see the localisation infrastructure as a tool of the translator (or localisation manager for a package in a language). If the translator has commit right, he can give the tool the data to do automatic commits, instead of doing them manaully. Only the person that has the rights in CVS/SVN will be able to commit to a project. As usual, no other commits would be allowed (except when PO files are updated with new POTs). We are not talking about different sets of people. At the end it is the upstream project who is in control by giving commit rights. Some poeple might commit manually and some might tell the infrastructure to do it for them (it is much better if for the same package and language, the team works only against CVS or against the infrastructure).
Inside the groups of people who use the infrastructure, they can use completelly different workflows. You might have a "French" workflow, which is automatically inherited by all French projects, unless overriden by specific parametrization for given package.
Christian Perrier wrote:
Yay, sure, my definition was a little bit a shortcut. Of course, when a given package/software has several trnslatable areas, the system should offer a method to register only some of them.
yes.
Yes, this would be the idea. The filters will produce PO files (for OpenOffice or Mozilla) and convert back before sending changes back. No special permission from the upstream package is needed for using the infrastructure, as the result for the package is just a CVS commit from somebody who has rights (in both cases), or some other way of upstream communication in which the infrastructure emulates what you would do by hand.The push module will of course need to be able to send the translations in whatever format is needed by upstream (PO, XLIFF, Mozilla stuff, whatever...)I do not understand how Debian developers will communicate with the infrastructure. Could we pick a random package and define the different processes?
javier