Re: [all] readiness and translation process parameters

Hi David,

2012/7/4 Dave Lewis <dave.lewis@cs.tcd.ie>

>  Hi all,
> Prior to attempting a call for consensus on the readiness data category I
> wanted to address some of the outstanding issues listed at:
>
> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#readiness
>

Readiness is not yet on the list at
http://www.w3.org/International/multilingualweb/lt/wiki/Implementation_Commitments
and we are far from a call for consensus AFAIK.


>
>
> These were touched on by Pedro in Dublin and merited further discussion.
>
> I will address each separately in another post
>

I would hope that we will concentrate on filing the empty cells at
http://www.w3.org/International/multilingualweb/lt/wiki/Implementation_Commitments
within the next three weeks - that is already a challenge, given other, non
MLW-LT work items. It would be a shame if we don't have provenance and
quality related data categories, but a set of new proposals ;)



> , but my primary observation is that many relate to instruction
> specifically for translation to be carried out on the whole document. This
> is consistent with the overlap with ISO/TS 11669 observed in comments .
> Taking the ISO/TS 11669 related summary at: http://www.ttt.org/specs/
> these are essentially parameters to a translation job specification, but
> also work in progress and perhaps something that will be difficult to align
> with normatively in our timeframe (arle?).
>
> Therefore, I propose we do not include such translation job parameters in
> readiness because:
>
> 1) readiness is use to signal the point in time when some content is ready
> to be processed by a named process. It is agnostic to what that process is,
> it could be e.g. named-entity-recognition. So including _translation_
> process specific parameters is a scope mismatch and therefore overloads the
> intended semantics of the readiness data category.
>
> 2)  Translation process parameters may be more appropriate as separate
> data categories as they are more generally useful even when readiness is
> _not_ used.
>
> This implies a new data cateogry for translation parameters. I don't see
> many use cases for applying these at the local level (but please shout if
> you see them). Therefore we could propose a global data category transParam
> element that contains:
>

I see an overlap between translation parameters and specialRequirements -
the user probably will ask "how do they relate to each other"?


>
> A) a selector indicating part of the document to which the translation
> parameters apply  (often but not always"/html/body")
>
> B) a required transParamType
>
> C) a required transParamValue
>
> Where transParamType and transParamValue are given non-normative best
> practice definitions, ideally then aligned with ISO/TS 11669 as it matures.
> e.g.
>
> <its:rules
>   xmlns:its="http://www.w3.org/2005/11/its" <http://www.w3.org/2005/11/its>  version="2.0">
>  <its:transParam selector="/html/body" transParamType="*contentResultSource*" transParamValue="yes"/>
>  <its:transParam selector="/html/body/diclaimer" transParamType="*pivotLang*" transParamValue="en"/>
> </its:rules>
>
>
> The class of potential translation process parameters data categories
> could include:
>
> a) sourceLang, contentResultSource, contentResultTarget, pivotLanguage
> from the readiness comments
>
> b) the remaining  project related data categories ;
>
> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#Project_Information
>
> c) the post-editing parameters suggested in:
>
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jun/0050.html
>

I would disagree with this approach on two levels: first, if we don't have
two implementations making use of a) b) c), there is no value in trying to
push for them. Second, we run into the same issue as with
specialParameters. As Pedro pointed out at
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0001.html
we need people who solve the detailed issues to move this forward.

It's OK *not* to do many things mentioned in the requirements document. We
can also do ITS 3.0 at some point :) For now, we should concentrate on a
few topics and do them well.

Felix


>
>
> cheers,
> Dave
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow