[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 1.2 to 2.0 Gaps and Proposals
As part of our exercise to map our 1.2 implementation (and challenges) to 2.0, we discovered the following gaps in core and modules that we would like to propose 5 features for. These are all based on real-world use cases at Microsoft and quite probably apply to other large companies that outsource content for localization.
Proposal 1: Add an optional build attribute to 2.0 <file> element in core.
In 1.2, the build-num attribute is important for us because, once we’ve handed off files to our suppliers to be localized, we expect localized files from the same build to be returned. We suspect we aren’t the only content providers doing this kind of validation. In 2.0, there is no file-level attribute we could use for this.
<file id=”1” original=”mainUI.resx” build="2011-11-23-133615307_windc.win8.beta.b01">
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
<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”>
Where, as noted in the 2.0 spec: The sub-category prefix is a string uniquely identifying a collection of values for a specific authority. The value is any string value defined by an authority. The prefix xlf is reserved for this specification…
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:
There is no equivalent in 2.0, so we’d like to make this much simpler by proposing an optional <reference> element on <segment> that can have an xml:lang attribute different from source and target in the main document.
<source xml:lang=”en-us”>hello world</source>
<reference xml:lang=”es-es“>hola mundo</reference>
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 group their notes or metadata in meaningful ways. This might be done so that a certain number of notes or bits of metadata can be processed in the same way, or simply grouped and displayed together, such as in an editor UI. Here are some examples:
As opposed to something less structured and more difficult to process:
<note id=“comment">This string cannot be longer than 100 characters</note>
Similarly, we’d like a name attribute for <mda:metadata>.
Proposal 5: Add optional change tracking attributes to <segment>.
When translation work may be shared across <segments> in the same file, for whatever reason, it is useful to track who modified a <segment> and when it was modified for billing purposes. This can be easily done when localization is done online in a database, but once it is offline and file-based, e.g. in an XLIFF file, having optional attributes defined on the <segment> would aid in capturing this information.
<segment id=”1” modifiedBy=”email@example.com” modifiedDate=”10/21/2012 5:28:13 PM”>
Please let us know your opinions on these proposals.
(Ryan King, Kevin O'Donnell, Uwe Stahlschmidt, Alan Michael)