R37: Revised Validations Module proposal

[Kevin O'Donnell <kevinod@microsoft.com>]

Hi All,

 

Following the approval of the Validation feature in XLIFF 2.0, we spent some time thinking about our original proposal, researching available implementations and consulting with colleagues both internally and outside of our company. We’d now like to present a revised, simplified proposal for implementation in XLIFF 2.0.

 

For us, inclusion of localization validation rules remains a high priority in XLIFF 2.0, to support localization constraints and better software localization suitability. We believe this goal can be achieved with a straightforward Validations module that will encourage wide adoption and usage.

 

Background

Previously, we advocated a Validations feature that included pre-defined rules, custom rules and pattern matching using Regular _expression_. In our new proposal, we are dropping the proposal for custom rules and pattern matching and, instead, advocating a set of normative validation rules only.

 

Here’s a summary of the difficulties we found with proposals of pattern matching/custom rules:

·         Pattern Matching (with RegEx)

o   As the previous discussion proved, it is difficult to identify a single RegEx engine that will have broad industry acceptance

o   Currently, few RegEx engines have extensive UniCode support

o   RegEx is powerful, but requires strong technical skills to utilize fully – may prohibit adoption

o   RegEx is not human readable, compared to a standard rule set

·         Custom rules

o   Custom rules may lead to unpredictable content in an XLIFF document. Again, based on feedback we’ve heard, it’s preferable to have predictable rule set with strict processing instructions

 

If we start with a defined set of rules, we could always revisit the option to include Pattern Matching in XLIFF 2.x, giving us more time to examine the pattern matching idea (or develop a localization RegEx standard).

 

Revised Proposal

Our revised proposal is based on 5 normative validation rules only. We believe these will be useful and powerful additions to the XLIFF 2.0 feature set:

·         A defined list of rules will provide certainty and predictability (i.e. no custom rules), which should encourage widespread adoption among XLIFF tool providers

·         Tool creators can map the defined list of rules to their UI features (e.g. flagging rule violations, adapting editing functionality based on rules)

·         The list is not exhaustive (intentionally so), but provides coverage for the most common cases of localization validation we have seen

 

List of rules:

	Rule	Description	Example
1	strBegins	Test to verify that a target string begins with a defined value.	strBegins(nbsp;)
2	strEnds	Test to verify that a target string ends with a defined value.	strEnds(“.”) existsInSource=“yes”
3	mustLoc	Test for presence of substring in source text and verify existence of specific translated value in target string.	mustLoc(“email”, “Courriel”)
4	noLoc	Test to ensure presence of string/substring in target string, subject to its presence in the source string.	noLoc(“Microsoft”)
5	dblSpace	Test to verify that a certain number of double spaces exists in the target string.	dblSpace(0)

 

Notes/processing requirements:

·         The rules allow XLIFF agents to perform tests on given XLIFF documents. The processing agent may use its own business logic to determine how to interpret the result of the test (although the result will be a consistent pass/fail, regardless of the agent performing the test)

·         As with other modules, if a tool does not support the Validations module, it may ignore it, but must preserve the rules

·         The rules may be augmented with an optional qualifier (existsInSource) to only test upon existence of the valid condition in source string. In the given example above, the strEnds rule will only apply if the source text meets the condition (of ending with “.”). Without the existsInSource qualifier, the default validation applies based on the target text only

·         The rules may be placed at the File or Unit level 

·         At the file level, the rules are global

·         At the unit level, the rule applies to the target

·         At the unit level, it is possible to override a global rule

·         At the unit level, it is possible to disable a global rule

 

At this point, we’d like to hear feedback on the revised proposal. We will continue to refine the proposal and create examples for the specific feature implementation and appropriate syntax.

 

Thanks,

Microsoft Corporation.

(Kevin, Ryan, Alan, Uwe)