RE: [xliff] subState question

Hi Ryan,

This is a very good question.

As you noted, 2.0 doesn’t have any provision for specifying the type of candidate when using it in the main target element, and that would certainly be something quite useful.

I suppose based on the definition of subState nothing prevent you to use the Candidate module subState values there. Ideally we should have some defined way of doing this.

-ys

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, April 21, 2015 2:02 PM
To: 'xliff@lists.oasis-open.org'
Subject: [xliff] subState question

Hi XLIFF TC,

As a module, translation candidates support is not required. In the case where it is not used, if a target segment has been auto-translated, can subState be something like this:

<source>This tutorial teaches you how to create a simple "Hello, world" app.</source>

<target>Este tutorial te enseña cómo crear un simple "Hola, mundo" app.</target>

Basically use the values defined for match.type (http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#candidates_type) as subState values?

I see the following processing requirement for extension mechanisms, but not sure if this is intended to apply to subState or other “sub” values:

4.9.3 Processing Requirements

· A user extension, whether implemented using <mda:metadata> or using a custom namespace, MUST NOT provide the same functionality as an existing XLIFF core or module feature, however it MAY complement an extensible XLIFF core feature or module feature or provide a new functionality at the provided extension points.

Thanks,

Ryan

xliff message