W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2012

[ACTION-50]: Explain process triggers in more detail

From: Pedro L. Díez Orzas <pedro.diez@linguaserve.com>
Date: Fri, 13 Apr 2012 12:26:18 +0200
To: <public-multilingualweb-lt@w3.org>
Message-ID: <DDF17A65E94C41378FB5A10F9D6212EC@newlas.local>
Dear all,

 

I send you the text I would include in the requirements explaining more in
retail the process trigger. I realized that sourceLang is also necessary. 

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>< 

 
<http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#proces
s_trigger#process_trigger> process trigger

 

provides the basic information to guide the localization process. Id est, it
contains the minimal basic coordinates to activate the processes or
workflows in a localisation chain. Other information that might be useful or
needed is already  covered by other data categories.

 

Data model 

*        processRequested –value: code or plain text 

*        contentFormat -values: plainText, xml, html3, html4, html5. 

*        sourceLang – value: standard ISO value

*        pivotLang - value: standard ISO value 

*        targetLangs - values: standard ISO values 

*        dateRequest –value: date and time 

*        dateDelivery –value: date and time 

*        priority –value: numeric 

*        contentResult –value: monolingual, multilingual 

Notes 

*        processRequested : This is thought to encode “the actions” or the
“workflow” that are requested, that is, the process wanted to be triggered.
A priori, the values could be user defined, since it is hard to generalize a
set or combinations of actions for specific workflows. Some examples are:

*	HTrans-HRev-LOC: this content needs to be human translated (Trans)
and human revised (HRev) and localized (LOC)
*	HTrans-: this content needs only to be human translated (Trans)
*	MTtrans- HRev: this content needs to be machine translated and human
revised.
*	WF-12022: refers to a predefined workflow code that is defined by
the client and LSP in advance

*        contentFormat: This indicates the tagging format used in the
content in order to apply the right filter or normalization rules, and the
subsequent processes, for example, the “Title” of a content can be plainText
and does not need to be filtered;  and the “Long Description” of the same
content can be html4 and needs to be filtered or treated regarding this.
Also, this might an impact in the cases of using MultilingualWeb-LT metadata
in plainText fields or contents.

*        sourceLang: this value indicates the source language for the
current translation requested. It is different from the Data Category
“provenance - source language”, since this indicates the language the
original source text was and sourceLang indicates the current source
language to be used for the translation that can be different from the
original source.

*        targetLangs: this value indicates the target languages for the
current translation requested.

*        pivotLang: this indicates the intermediate language in the case is
needed. This is necessary for example for two scenarios:

*	1) Going for example from a source language to two language variants
(eg. Into Brazil and Portugal Portuguese), it is more effective (chipper) to
go to one first (being this first variant a "pivot" language) and to revise
later to the second variant.
*	2) Going for example from a language to another using an
intermediate language (eg. Going from Maltese into English and from English
into Irish, because there is not direct Maltese into Irish available
translation).

*        dateRequest: this is the date/time of the the request.

*        dateDelivery: this is date/time for delivery the translation or
localization

*        priority: this indicates the priority using a numbering convention.


*        contentResult: this indicates if the resulting translation, in the
cases of several target languages, should be delivered in several
monolingual content files or in a single multilingual content file.

The information in dateRequest, dateDelivery and priority can be combined to
calculate relative priorities. For instance, a content sent the 25-01-2013
for delivery before the 30-01-2013 with priority “3” will be delivered later
than a content sent the 27-01-2013 for delivery before the 30-01-2013 with
priority “1”.

<<<<<<<<<<<<<<<<<<<<<<<< 

If you agree with this we can close this action. 

I hope this helps.

 

Pedro

 
Received on Friday, 13 April 2012 10:27:58 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 June 2013 00:24:55 UTC