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

Hi Pedro,

 

I think the list for processRequested looks like a very good progress.

It’s more and better than what I was thinking about.

 

I’m guessing we’ll probably have to define some of the terms we use (like what exactly ‘localization’ means in this context) just so everyone talks about the same thing. But that’s probably something for the specification overall: I don’t think we’ve started a list of defined terms.

 

Cheers,

-ys

 

 

From: Pedro L. Díez Orzas [mailto:pedro.diez@linguaserve.com] 
Sent: Monday, April 16, 2012 6:15 AM
To: public-multilingualweb-lt@w3.org
Subject: 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#process_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