Information that need to be stored for the translation process (was: [translate-pootle] Wordforge)

[Nicolas François <nicolas.francois@centraliens.net>]

Hi Javier,

On Fri, Jun 09, 2006 at 04:58:19PM +0700, Javier SOLA wrote:
> 
> I also think that we should start imediatly an analysis of what 
> information might be interesting to have in a database and which 
> information should be in databases. It might even be interesting to have 
> the same information in both formats (every time an XLIFF file is 
> created or modified, the info is stored in a database, which would work 
> as a cache).

Lets try to get some inputs for this.

First (still on the storage of information ;), does the XLIFF standard
defines some fields for the process or for the storage of information
other than translations? Does it allow such fields without specifying
them in detail (implementation specific)?

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 process
   + what is the process chosen by the translation team manager (or
     translators, etc.)
     (some fields may be locked and rejected when merged back to avoid the
     translators or reviewer to change them)
     e.g. number of reviews, type of translator or reviewers, etc.
          how long do we wait before orfaning a translation if the
          translator is not available
   + linked translation (what languages are embedded in the file requested
     by the translator) (There is a term used in the Wiki for that, but I
     can't find it right now)
   + expected date for completion
   + goals
     (link to general goals, goals for a file, dates, etc.)
 * Roles/Users involved
   + author, licence (links)
   + previous translators
   + current translator
   + reviewers? (I don't think reviewers get any credit, or are kept for
     copiright issues currently, or kept to ping them when a new review is
     needed)
 * status. IMO, we should define some states
   + need to be translated/updated
     (here maybe we can differentiate whether there is a current
     translator or not; this could also be done by the presentation
     interface)
   + need to be reviewed
     (the translator change the status field when
   + reviewed x
     keep a counter of the reviews (or name of reviewers)

   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?)

 * Dates
   I'm prety sure they are useful. I just don't know what dates are
   useful. We need to precise the processes first.


And of course
 * Translations
   + the original string
   + the translation
   + the previous original string (after an upstream update)?
   + the previous translation (after a resquest for review)
   + comments
   + blockers? (a reviewer think the quality of the file is not sufficient)


Sorry, I understand that some of these points are already in the Wiki.
I'm still re-reviewing the Wiki specs. I hope I will be able to give some
comments here (on both mailing lists) or in the wiki.

Kind Regards,
-- 
Nekral