Re: Information that need to be stored for the translation process
On Fri, Jun 09, 2006 at 04:11:35PM +0200, Nicolas François wrote:
> 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.)
Other threads also remind me that we need
+ Link to upstream
o can we update the original strings based on the upstream project
(what method)
o can we push the translation to the upstream project
(what method)
> * 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
>
>
> --
> To UNSUBSCRIBE, email to debian-i18n-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: