RE: [xliff] 1.2 to 2.0 Gaps and Proposals

[Ryan King <ryanki@microsoft.com>]

Hi ALL, in last week’s TC call it was mentioned that I should work with the owners of the current features to get our requirements implemented for proposals that weren’t deemed as features. Can anyone tell me who the owner of the <file> element is so that we can discuss the implementation of the following:

•	Proposal 1: Add an optional build attribute to 2.0 <file> element in core.

I’m not sure if this requires an electronic ballot. I got the impression from the call that it doesn’t, but hopefully Bryan or David or someone else from the call will correct that if false.

Please let me know who I can work with on this.
Ryan

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, November 15, 2012 12:24 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals

Hi Ryan, all,


> Proposal 1: Add an optional build attribute to 2.0 <file> element in core.
> ..
> <file id=”1” original=”mainUI.resx” 
> build="2011-11-23-133615307_windc.win8.beta.b01">

I don't see anything wrong with this.



> Proposal 2: Be able to specify optional custom values for match type 
> attribute in the <mtc:matches> module.
> Content providers and Localization Suppliers base their cost and 
> billing models on match similarity and match types. Localization 
> suppliers charge us differently for ICE Matches, Exact Matches, and 
> Fuzzy Matches, and we might even want to get more granular than that 
> as our cost and billing models evolve with the business.
> In 2.0, the match type doesn’t support the values exact-match and 
> fuzzy-match, which were defined in the state-qualifier attribute in 
> 1.2. Instead of supporting these two, or any others that may not have 
> migrated from 1.2 to 2.0, as a separate attribute, the request is, 
> that like the discussion on state and sub-state in the Face-to-Face in Seattle, we add a sub-type to match type.
> This will allow us to add extra business logic to types, such as "tm" 
> or "mt", which are already defined in the spec.
> <match id=”1” similarity=”100.0” type=”tm/xlf:exact”> <match id=”1” 
> similarity=”75.0” type=”tm/xlf:fuzzy”> <match id=”1” similarity=”99.0” 
> type=”tm/custom:near-exact”>

I understand the need for the information, but to me, it seems the similarity give you whether a match is exact or not.

The example however, shows (I think) that you are thinking about categories that could be mapped differently to the similarity depending on projects. For example in one project a near-match corresponds to one range and in another to a different range, and you want to simply map that info to something common across your process, without having to carry the ranges around. If that's the case I wonder if XLIFF should define any default like xlf:exact, etc.

So I wouldn't see a problem with a sub-type there.

A side comment on the match type: especially, if we allow sub-type, I'm still not sure about the values currently listed.



> Proposal 3: Add an optional Reference Language to core.
> This is a crucial feature for Microsoft and other large companies that 
> localize minority languages. For example, it is typical that when we 
> localize from English into Quechua, localizers are more efficient and 
> provide much higher quality translation, when along with English 
> source, we provide them with Spanish target. In 1.2, Reference 
> Languages could be defined in an <alt-trans> element:

I see the use case and I've seen other cases like this, with Chinese (simplified/Traditional).

Could that be part of the match module?
Possibly with a new attribute (e.g. reference='yes|no' defaulting to no)

Adding something along with <source>/<target> is bound to cause additional PR issues. If it's part of the Match module, it just uses whatever the module PRs are.



> Proposal 4: Add an optional name attribute on <notes> in core and 
> <mds:metadata> module.
> We believe it will be typical for content providers to want to ...
> <notes name="comments">
>  <note id=“comment">This string cannot be longer than 100 
> characters</note>  <note id=“user">Developer@microsoft.com</note>
>  <note id=“date">10/21/2012 5:28:13 PM</note> </notes>

Sounds reasonable. We'll have to allow several <notes> and <m:metadadat> (I think (but I may be wrong) only one is allowed)) on the extension point.

The example makes me wonder about the long term life of XLIFF though: likely this type of info (author, timestamp) will be needed by other. Maybe a better way to address it would be to add attributes to the note and meta that carry the author and time stamp?
That would obviously work only if those two info are the only example you have in mind.



> Proposal 5: Add optional change tracking attributes to <segment>.
> ...
> <segment id=”1” modifiedBy=”translator@loc.com”
> modifiedDate=”10/21/2012 5:28:13 PM”> 
>    <source>hello world</source>
>    <target>hola món</target>
> </segment>

Here again I'm wondering if a "change track" module may be better?
You could use it not just on segments but other elements: notes.
The issue then would be how this gets updated if it's not a core component?
Actually if it's a core attribute, does it means it's not optional?
I'm not sure there is a way, even with a PR, to guarantee these data will be up-to-date.
But maybe that's ok?


cheers,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org