[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
Thanks Yves, see my inline to your inline. Please let me know if there is anything I can do to help you document and get this added to the specification. Do you feel we need to have a roll call vote on these items in the next TC call? Thanks, Ryan -----Original Message----- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Wednesday, November 28, 2012 7:48 PM To: Ryan King; xliff@lists.oasis-open.org 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. > 1. Be able to specify optional custom values for match type in > <mtc:matches> 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. 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). [ryanki] I think this makes sense. For example, there's no reason each of these couldn't be valid (note ic instead of ice): <match id=”1” similarity=”100.0” type=”ic/xlf:exact”> <match id=”1” similarity=”100.0” type=”mt/xlf:exact”> <match id=”1” similarity=”100.0” type=”tm/xlf:exact”> <match id=”1” similarity=”75.0” type=”ic/xlf:fuzzy”> <match id=”1” similarity=”75.0” type=”mt/xlf:fuzzy”> <match id=”1” similarity=”75.0” type=”tm/xlf:fuzzy”> > 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. I assume you mean: allow more than one <mtc:matches> where we currently allow one? Not in *all* extensions point. right? [ryanki] exactement :) > • 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 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: - reference='yes\no' and allowing a different language for xml:lang in those with reference='yes' seems ok to me. - 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?). [ryanki] in principle, we could carry around the redundant <source> the only side effect really being bloat to the XLIFF (but metadata will do that anyway...) I suggested it this way simply because <alt-trans> the previous element used for reference language in 1.2, does not require <source>, so this was for parity. We would need to update the definition of what a "match" is as well. hope this helps, -ys --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]