[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals
Hi Ryan, all,
Sorry for the delay: I'm just swamped and can't find the time to read emails anymore.
I suppose some mechanism similar to the subType we're using in inline codes and other places could allow for custom values while making sure a top-level category is also declared.
> 1. Be able to specify optional custom values
> for match type in <mtc:matches>
Since we are discussing values for match type: I'm still not convinced that the latest list makes sense:
am - Assembled Match
ebm - Example-based Machine Translation
idm - ID-based Match
ice - In-Context Exact Match
mt - Machine Translation
tm - Translation Memory Match
- 'Example-based Machine Translation' should not be there IMO: it's just MT, what type of MT is not relevant (but could be a candidate for the subtype)
- 'In-Context Exact Match' IMO should be 'in-context' only: the fact that's an exact one is captured in the similarity (and it could be an in-context fuzzy too).
I assume you mean: allow more than one <mtc:matches> where we currently allow one? Not in *all* extensions point. right?
> 2. Support Reference Language in <mtc:matches>
> • Allow zero, one or more <mtc:matches> at each extension point, because
> you might have both recycling and reference language data.
> • Add an optional attribute reference=”yes|no” with no as default.
> Additionally, PR for a “reference match” would be to allow an xml:lang on the target- reference='yes\no' and allowing a different language for xml:lang in those with reference='yes' seems ok to me.
> different from the document and allow the <source> not to be present
> as it would be redundant information with the core <source>, e.g. Spanish
> reference for Quechua might look like this:
- source not being present... I don't know. If we do that for those 'matches' why not for the normalmatches as well? If the source is the same.
I think we mandated the source originally that's to simplify processing: testing for the presence of not of the source may be cumbersome for some processors (XSLT maybe?).
We would need to update the definition of what a "match" is as well.
hope this helps,