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

Hi Yves, Jan, all,

 

Thank you very much for the comments. I had into account the three basic
points and I tried to integrate them in this new version below:

 

1) ‘contentFormat’: I agree and tried to integrate. I also changed the data
model and I added the comments in the notes (changes in yellow). 

 

2) 'processRequested'. I again agree, but it is more difficult. I provide
some first possible values (in blue)

 

3) The absolute value of "priority" is in a workflow, and what each value
would in fact trigger? I added both dateRequest/dateDelivery and priority
for two reasons:

            a) Certain CMS might not produce info about dateDelivery, but a
value for priority, which values are previously defined in a Service Level
Agreement. In some cases, the TMS can also produce the value for
dateDelivery with the actual date delivered, which could be used by the
client or CMS to verify the SLA accomplishment.

            b) Also, it is a common use the LSP to associate to “priority” a
certain value (rush) that produces an additional charge or pricing.

 

In any case, if you think this is covered we could remove it. I think it is
useful for this.

 

4) We also revised the contentResult to distinguish between source and
target (in green)

 

So, I modified the data category as follows:

 

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

 
<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 can be already  covered by other data categories.

 

Data model 

*        processRequested –value: NMTOKENS (possible NMTOKEN values to be
extended/revised/decided)

contentQuote

contentL10N

contentI18N

contentDtp

contentSubtitle 

contentVoiceOver

sourceRewrite

sourceReview

sourceTranscribe

sourceTransliteration

hTranslate 

mTranslate

hTranscreate

posteditQA

reviewQA

reviseQA

proofQA

[…]

*        contentType -values: MIME or custom values

*        contentTypeVersion –values: version value

*        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 

*        contentResultSource –value: yes / no 

*        contentResultTarget – 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 possible values
are:

possible NMTOKEN values: (To be extended and decided)

 

contentQuote: indicates that a quoting or pricing is requested, not to
perform the job

contentAlignment: in case the content is to add to a Translation Memory (?)

contentL10N: localize the content

contentI18N: internationalize the content

contentDtp: desktop publishing of content

contentSubtitle: subtitling of content

contentVoiceOver: voice-over of content

 

sourceRewrite: rewrite the source content (needs contentResultSource: yes)

sourceReview: review the source content (needs contentResultSource: yes)

sourceTranscribe: transcribe the source content (needs contentResultSource:
yes)

sourceTransliteration: transliterate the source content (needs
contentResultSource: yes)

 

hTranslate : human translation

mTranslate: machine translation

hTranscreate: human transcreation

 

posteditQA: human postediting of mTranslate

reviewQA: human review for quality assurance only the target text, without
the source text (see UNE 15038 “review”), by an expert for instance

reviseQA: human revision for quality assurance examining the translation and
comparing source and target (see UNE 15038 “revision”)

proofQA: human checking of proofs before publishing for quality assurance
(see UNE 15038 “proofreading”)

*        contentType: This indicates the format or the type of the content
used in the content in order to apply the right filter or normalization
rules, and the subsequent processes. For example, to express HTML we could
use:

*	contentType: text/html

*        contentTypeVersion: This indicates the versión of the contentType.
For example, to express HTML 3.0

*	contentTypeVersion: 3.0

*        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,
in case the CMS generates this and it is used by the Localization chain to
calculate the dateDelivery, based on a previously defined Service Level
Agreement. In some cases, the Localization chain can also produce the value
for dateDelivery with the actual date delivered, which could be used by the
client or CMS to verify the SLA accomplishment. Also, it is a common use the
LSP to associate to “priority” a certain value (rush) that produces an
additional charge or pricing.

*        contentResultSource: this indicates the format if the Localisation
chain needs to give back the original 

*        contentResultTarget: 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.

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

Pedro