Nicolas, I think that we can actually separate process information from workflow.XLIFF files allow storage of <phase> elements, which can be "translation", "authoritative review" (the reviewer can make changes in the target), "reviewer recommendations" (reviewer adds comments in a file, but does not change the <target>), "approval" or any other that we can define.
For example:<phase phase-name="xxx" process-name="translation" date = "2006-01-25T21:06:00Z" contact-name="Alberto Martinez"
contact-email="alberto@martinez.com"> </phase> These phases are elements that can be used in a given worflow.If your workflow is translation - review - approval, then Pootle will enforce that a review phase is mandatory after a translation phase, and then an approval phase. You could also require only a single translation stage, or a workflow in which a file can be reviewed by N reviewer-recommenders (who mainly add comments to the file), and record N phases in the Pootle file (interstingly, with this method, reviewers can act at the same time, and their information and phase is added to the file when they upload... then the file is sent back to the translator, who in this case can act as "approver" (his translation editor must be able to display reviewer comments when in approver mode).
If we can define the roles, then we do not need to consider workflows in the encoding of the files, only in the process tool (Pootle).
Workflow can be defined for each project (a project being the set of files of a piece of software that will be translated to a given langauge, such as Gaim 1.5 for French). It can be inherited by default (from the language level), to simplify configuration, but changable.
If this is combined with allowing commit access (upstream) to whichever role the team decides (translator, approver) should give enough flexibility for any type of workflow. We will have to test a number of them to ensure that this assumption is correct.
Every string in the file can be associated to a specific phase. Some strings in the same file could be unstranslated, some translated but not reviewed, some reviewed. There are loopholes in the XLIFF definition, but they can be overcome with implementation specifications.
Javier Otavio Salvador wrote:
Hello Nicolas, Nicolas François <nicolas.francois@centraliens.net> writes:Here is a far from complete list of information that I think should be stored (assuming processes I'm used with, i.e. my understanding of the Debian French translation process): * Information about the processI agree that would be good, but read bellow.+ what is the process chosen by the translation team manager (or translators, etc.)That I disagree since all the whole team will use the same process (for example, the Brazilan team will use same process for every translation) and this shouldn't be duplicated. The language might select the process or be group of packages + language.+ goals (link to general goals, goals for a file, dates, etc.)Might be splited. For team and file. Again, avoiding duplicating.I think a status per file is needed. However a status per string could also be needed, so maybe the file status could be automatically generated based on the string status. (What to do if a file contains a string for translation and a string for review?)I think that file status migh be automatically set. In case of the file have pending strings for reviewing, those strings might be displayed for traslator for review in a separated part of display and the untraslated things above of it.* Dates I'm prety sure they are useful. I just don't know what dates are useful. We need to precise the processes first.That isn't the same of goals?