oasis-tcs / xliff-xliff-22 Goto Github PK

Specification Type

No response

Revision

No response

Detailed Description

Currently the spec references RFC 2119 which is only the first part of BCP 14. Since May 2017, BCP 14 also contains RFC 8174, which is very important for interpretation of normative keywords.
The keywords section should be changed to reference BCP 14 and also the normative reference should be changed from RFC 2119 to BCP 14.

Detailed Description

Some folders are use different case than the links to them.
This works on file systems that are not case sensitive (for example Windows, some MacOS disks)

But merge fails on Linux and some MacOS disks (the macos disk initialization asks if you want a case sensitive file system or not).

So merge fails with:

modules/resourcedata/specification.xml
../../elements/resourcedata/resourceData.xml
java.io.FileNotFoundException: ~/third_party/xliff-22.mihnita/xliff-22/modules/resourcedata/../../elements/resourcedata/resourceData.xml (No such file or directory)
        at java.base/java.io.FileInputStream.open0(Native Method)
        at java.base/java.io.FileInputStream.open(FileInputStream.java:216)
        at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
        at java.base/java.io.FileInputStream.<init>(FileInputStream.java:111)
        at java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86)
        at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:189)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:150)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:861)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:247)
        at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:342)
        at java.xml/javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:206)
        at com.maxprograms.xml.Merger.parse(Unknown Source)
        at com.maxprograms.xml.Merger.recurse(Unknown Source)
        at com.maxprograms.xml.Merger.recurse(Unknown Source)
        at com.maxprograms.xml.Merger.parse(Unknown Source)
        at com.maxprograms.xml.Merger.recurse(Unknown Source)
        at com.maxprograms.xml.Merger.recurse(Unknown Source)
        at com.maxprograms.xml.Merger.run(Unknown Source)
        at com.maxprograms.xml.Merger.main(Unknown Source)

In xliff-22/ we have:

• ./elements/resourceData
• ./modules/resourcedata (note the lowercase "d")
• ./attributes/resourceData

But modules/resourcedata/specification.xml includes things from ./../elements/resourcedata/ (lowercase "d", the folder uses uppercase "D")

<segment>
  <source xml:lang="cs"><pc type="quote">Blázen,
      chce dobýt točnu v takovém počasí</pc>, dodal slovy svého
      oblíbeného imaginárního autora.</source>
  <target xml:lang="en"><pc type="quote">Madman, he wants to conquer the
      pole in this weather</pc>, offered he the words of his
      favourite imaginary playwright.</target>
</segment>

The example above illustrates the use of type="quote" with <pc> element. The id attribute is required in each <pc> element, but the example is missing the attribute.

In addition to this, I personally don't like to put xml:lang attribute in this example. I think the original author's intent was to clarify what is source/target language in this example. But even without it, it should be sufficient to illustrate the use of type="quote" with <pc> element.

The example needs reordering according to schema

Add a section indicating that validation rules for core elements don't apply in full when the element is used inside a module.

Example: "id" attribute for <data> element must be unique inside <unit>, but when <originalData> is used in <unit> and also in <mtc:match>, duplication of "id" may be necessary.

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

In XLIFF 2.1 specification 4.2.3.4 sc, there is a constraint statement below:

The attribute isolated MUST be set to yes if and only if the element corresponding to this start marker is not in the same , and set to no otherwise.

This constraint makes perfect sense for <source> part . However, in translation process, not all <target> values might not be ready at a point.

<unit id="1">
  <segment id="seg1" state="translated">
    <source><sc id="1" type="fmt" subType="xlf:b"/>
        First sentence. </source>
    <target><sc id="1" type="fmt" subtype="xlf:b"/>
        最初の文。</target>
  </segment>
  <segment id="seg2">
    <source>Second sentence.<ec startRef="1" type="fmt"
        subType="xlf:b"/></source>
  </segment>
</unit>

The example above is invalid with the current XLIFF specification because <sc id="1" ...> in seg1 is not isolated="yes" although it does not have the corresponding <ec> element in seg2. The specification should be updated to clarify the constraint:

• This constraint always applies to <source> values in a <unit>.
• For values, this constraint is effective when all <segment>s in a <unit> have <target> elements.

Example Use Case

N/A

Compatibility Impacts

This specification update should have very small or no impacts to existing XLIFF applications.

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

XLIFF 2.1 specification section 4.3.1.31 state, defines the default value is "initial". In the processing requirements section, the following description is found.

Writers MUST NOT set the state attribute values to other than the default initial if and only if the segment element where the attribute is set doesn't have the child.

This description is hard to understand for implementors because "only if" with double negative. It is not really clear if following example is valid.

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0"
    srcLang="en" trgLang="fr">
  <file id="f1">
    <unit id="u1">
      <segment id="s1" state="initial">
        <source>Hello World!</source>
        <target>Bonjour le Monde!</target>
      </segment>
    </unit>
  </file>
</xliff>

Example Use Case

No response

Compatibility Impacts

N/A

Specification Type

XLIFF core specification

Revision

No response

Detailed Description

Investigate a possible error in the definition of srclang and trgLang in core schema. They are currently defined as:

      <xs:attribute name="srcLang" use="required" type="xs:language"/>
      <xs:attribute name="trgLang" use="optional" type="xs:language"/>

but xs:language is defined as an enumeration containing only the empty string to undeclare the standard xml:lang attribute in xml.xsd

There should be a way to associate a <note> element with a given <segment>. The "ref" attribute from XLIFF core namespace could be used for that but needs to be added to <note> in the schema.

We need to migrate the ISO templated XLIFF Version 2.2 repo from OASIS SVN

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

The Resource Data module provides a mechanism for referencing external resource data. To specify a reference item,<resourceItem> element is used. In the current specification, there is no way way to specify description of each resource item without attributes/elements from other namespaces. When a resource item is used as context reference, it is important to provide a description about the content, not just mimeType. XLIFF should provide a standard way to add description of each resource item.

There are two options to support this requirement.

1. Add new attribute description to <resourceItem> element.
2. Allow note element in <resourceItem> element.

1 is probably easier for XLIFF implementators. 2 is more consistent with other XLIFF elements.

Example of Option 1 above

<file id="f3">
  <res:resourceData>
    <res:resourceItem id="r1" mimeType="image/jpeg" context="yes" description="Config Screen 1">
      <res:source href="resources\en\registryconfig1.resources.jpg" />
      <res:target href="resources\lb\registryconfig1.resources.jpg" />
    </res:resourceItem>
  </res:resourceData>
  <unit id="1">
    <res:resourceData>
      <res:resourceItemRef ref="r1" />
    </res:resourceData>
    <segment id="1" state="translated">
      <source>Remove Registry Config</source>
      <target>Registrierungskonfiguration entfernen</target>
    </segment>
  </unit>
</file>

Example of Option 2 above

<file id="f3">
  <res:resourceData>
    <res:resourceItem id="r1" mimeType="image/jpeg" context="yes">
      <res:source href="resources\en\registryconfig1.resources.jpg" />
      <res:target href="resources\lb\registryconfig1.resources.jpg" />
      <notes>
        <note>Config Screen 1</note>
      </notes>
    </res:resourceItem>
  </res:resourceData>
  <unit id="1">
    <res:resourceData>
      <res:resourceItemRef ref="r1" />
    </res:resourceData>
    <segment id="1" state="translated">
      <source>Remove Registry Config</source>
      <target>Registrierungskonfiguration entfernen</target>
    </segment>
  </unit>
</file>

Example Use Case

No response

Compatibility Impacts

No response

Detailed Description

We should update the announcements section in the official XLIFF TC's webpage: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff#announcements
Here are some ideas of new items that can be included in that section:
-New module.
-Public review of the new version (once it will be online).
-The validation tool developed by Rodolfo.

New XLIFF 2.2 working draft documents in HTML format has local CSS/image links like below:

href="file:/C:/Users/rmray/Documents/GitHub/xliff-xliff-22/xliff-22/css/oasis-spec.css"

Fix these link issues.

Specification Type

XLIFF core specification

Revision

No response

Detailed Description

I have reviewed the latest version of our specification draft (the core section only so far).

Here are some typos and other minor issues I have found:

• Remove item 3 from Section 2 (Conformance) because XLIFF 2.2 is backwards compatible with 2.0 and 2.1 (see Appendix C)
• Remove spaces before closing tags in XML fragments
• Drop "2.1" when mentioning XLIFF in ITS module

Other changes/ideas that can be implemented in the spec to make it easier to read/follow:

·         Include a legend/number to all the examples so we can (cross) reference them in the spec. This could also allow to save some space in the spec as some examples are repeated (see, for example, examples in dataRefEnd and dataRefStart).

·         In the definitions of the inline elements, provide their expanded version of the abbreviations used in the names of the inline elements so their meaning becomes more transparent. We could use, for example, the values included in the first column of table 1 in page 51.

·          Simplify the definition of the element “unit”, the current definition is: “Static container for a dynamic structure of elements holding the extracted translatable source text, aligned with the Translated text.”.

·          Add an example in source and/or target elements.

Best,

Lucía

Specification Type

None

Revision

No response

Detailed Description

This issue can happens in the "5.8.8.2.2 Inline Elements" section in xliff-extended-v2.2wd.html

The html content being extracted is

    <p>Image: <img src="example.png" alt="Text for the image"></p>

and it is extracted as:

<unit id="1">
  <res:resourceData>
    <res:resourceItem id="r1" mimeType="image/png" context="no">
      <res:source href="example.png" />
    </res:resourceItem>
  </res:resourceData>
  <segment>
    <source>Image: <ph id="ph1" fs="img"
        subFs="src,example.png\alt,Text for the image" /></source>
  </segment>
</unit>

But the alt element is localisable, and "Text for the image" should be extracted in a subflow <unit>, as described in the "4.7.4 Sub-Flows" section.

Authors

No response

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

Currently, Appendix A contains a template for registering a MIME type at IANA.

Considering that MIME type registration is done by OASIS staff, not by specification readers, the appendix should list the current MIME type to apply on XLIFF 2.x files.

Example Use Case

No response

Compatibility Impacts

No response

Authors

No response

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

Now that we don't have Schematron files as deliverables, rename Appendix B from “Machine Readable Validation Artifacts (Informative)” to sometging like “XLIFF Grammar Files (Normative)”.

See http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#coreValidation

Example Use Case

No response

Compatibility Impacts

No response

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

XLIFF 2.1 does not allow <notes> and <mda:metadata> specified at XLIFF document level. XLIFF document may contain multiple elements. An XLIFF user may want to set same notes or metadata for multiple files in an XLIFF document. But it requires to duplicate the same set of notes/metadata for all files in this case with XLIFF 2.1.
This proposal changes the XLIFF specification to allow <notes> and <mda:metadata> also specified at <xliff> element level.

Example Use Case

No response

Compatibility Impacts

Existing XLIFF application may completely skip notes and metadata at XLIFF level.

Original issue: rmraya/OpenXLIFF#13

Remove the requirement to register prefixes for subState attribute in next version of XLIFF

Authors

No response

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

I have reviewed last week the new version of the specification. I have found some minor capitalisation issues:

Example Use Case

No response

Compatibility Impacts

No response

Authors

No response

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

Change the description of "version" attribute, including the new enumeration (2.0, 2.1 and 2.2), stating that for this version of the specification "2.2" should be used.

See http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#version

Example Use Case

No response

Compatibility Impacts

No response

The example in section 4.2.3.3 pc is not wellformed.

<unit id="1">
 <originalData>
  <data id="1">&lt;B&gt;</data>
  <data id="2">&lt;/B&gt;</data>
 </originalData>
 <segment><pc id="1" dataRefStart="1" dataRefEnd="2">Important</pc>
text</source>
 </segment>
</unit>

It should have <source> element after <segment>.

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

Review comments for 5.9 Plural, Gender and Select Module

5.9.1 Introduction

This section may include generic description about

• What is plural, gender and select.
• Variation of linguistic expression depending on condition of variable parameters.
• Reference to Unicode CLDR/ICU specification (embedded link within description)

5.9.2 Module Namespace and Validation Artifacts

• "urn:oasis:names:tc:xliff:pgsm:1.0" - We may use "pgs" (same as prefix) instead of "pgsm". I assume "m" means "module". But other modules do not have "m".

5.9.5.1 switch

• The spec says "The text contains a comma-separated list of items". Examples in this section matches the description, but examples found in other section uses white space character as the separator instead. Because case uses white space character as delimiter, it's more consistent to use space as separator instead of comma.

5.9.5.2 case

• example is not matching the earlier definition. pgs:switch="plural:count gender:host_gender" uses space as variable separator. If we agree to change the spec of switch to use a space as separator, then we can keep this description.
• Valid gender keywords includes "anything else". For easier implementation, a token belong to "anything else" should be refined - such keyword should not contain any separator characters (space). Also avoid double quote, etc which may require escaping.
• Related to above - I understand there are more gender cases, but is it a problem if we limit gender keywords to only feminine, masculine, neuter and others? From implementator's point of view, "anything else" is not nice.

5.9.6.1 Plural

• "ICU" might be changed to "ICU MessageFormat" with embedded link.

5.9.7 Maximizing compatibility

• This section title might be changed to "Recommended practices". These notes are not limited to compatibility.

5.9.7.2 Keep the same order of the selectors

• "By keeping the generated text segments in the same order we can improve Translation Memory leveraging that relies on context..." - I'm not sure about this description. I agree consistent ordering can prevent unnecessary confusion, but most of translation memory implementations would not depend on order of "alternative" segments.

5.9.7.4 Generate separate localization packages for each language

• "In fact, some companies..." maybe more generic term instead of "some companies".

5.9.8 Annex, links

Some links might be moved to 1.2 Normative References / 1.3 Non-Normative Reference.

Example Use Case

No response

Compatibility Impacts

No response