[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-11) Enforce <target> existence based on segment state
[ https://issues.oasis-open.org/browse/XLIFF-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64921#comment-64921 ]
David Filip commented on XLIFF-11:
----------------------------------
Modifiers are allowed to create target in the general core section http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#contentmodification
The core attribute @state http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#state has been defined as tracking the state of the *Translations* within segments. Key definitions under http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#d0e307 define Translation as rendering the source content in the target language. Target language content in Core can only be held in <target> elements. [trgLang is required if and only if targets are present and xml:lang on core <target> MUST be equal to the trgLang value].
The core section Segmentation Modification http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#segmentationModification
introduces a progressive state machine based on the values of the core attribute @state.
====================
From the above it follows:
1. That segements in sates "more advanced" than initial MUST contain Translations
2. In Core, Translations can be only held in <target> elements
-------------------Therefore:
3. A <segment> MUST NOT progress from the state "initial" if it doesn't have a <target> child.
The above shows that more advanced states already require existence of targets, but the reader will obviously benefit from stating this explicitly on the @state attribute and the implementer from the advanced validation enforcing targets on advanced state segments.
--------------
As a corollary, implementers not using the state will never receive warnings or errors for missing targets even with the new validation behavior because the default is initial and that doesn't REQUIRE Translation
----------------
Another corollary of the above is that existence of <target> children of ignorables cannot be enforced since they don't require translation and hence don't have state.
This strenghtens the case for providing a Merger guidance as per https://issues.oasis-open.org/browse/XLIFF-12
> Enforce <target> existence based on segment state
> -------------------------------------------------
>
> Key: XLIFF-11
> URL: https://issues.oasis-open.org/browse/XLIFF-11
> Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
> Issue Type: Improvement
> Components: other
> Affects Versions: 2.1_csprd01
> Environment: http://markmail.org/thread/4rzmqjlmcncl22bc
> Reporter: David Filip
> Assignee: David Filip
> Priority: Minor
> Labels: request_tc_discussion
> Fix For: 2.1_csprd02
>
>
> FROM:
> Ján Husarčík <jan.husarcik@gmail.com>
> file
> <?xml version="1.0" encoding="utf-8"?>
> <xliff xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
> xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en-US" trgLang="fr-FR" version="2.0">
> <file id="1">
> <group id="content">
> <unit id="1">
> <segment state="final">
> <source>1</source>
> </segment>
> </unit>
> </group>
> </file>
> </xliff>
> is reported as valid with state="final", while the <target> is not present.
> Could you please consider enforcing existence of <target> (even if it's empty) for segment states different from default?
> If you decide to do so, could you please update processing requirements in http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#contentmodification accordingly, and reference them (at least) in http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#state and http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#target
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]