OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  Version Control Commit by David.Filip

    Posted 08-06-2013 14:57
    Author: David.Filip Date: 2013-08-06 14:57:02 +0000 (Tue, 06 Aug 2013) New Revision: 293 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/?rev=293&sc=1 Removed: trunk/xliff-20/xliff-core-v2.0-wd02.pdf Modified: trunk/PR01_CommentsDisposal/xliff-core-v2.0-csprd01_PRsAnnotated.pdf trunk/xliff-20/elements/glossary/glossentry.xml trunk/xliff-20/elements/resourceData/reference.xml trunk/xliff-20/elements/resourceData/resourceItem.xml trunk/xliff-20/elements/resourceData/resourceItemRef.xml trunk/xliff-20/xliff-core-v2.0-wd02.html trunk/xliff-20/xliff-core-v2.0-wd02.xml trunk/xliff-20/xliff-core.html trunk/xliff-20/xliff-core.xml trunk/xliff-20/xliff20.xml Log: interim check in w/o pdf print out, it has only HTML printout for discussion in TC meeting ----------------------------------- Process and Agent definitions finished PRs and Constraints rehaul still in progress Othe major TODOs 1. resegmentation flag 2. Resegmentation PRs


  • 2.  Fwd: [xliff] Version Control Commit by David.Filip

    Posted 08-06-2013 15:04
      |   view attached
    All, please find attached the latest WIP version of the whole spec we will be through in the meeting Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie ---------- Forwarded message ---------- From: < workgroup_mailer@lists.oasis-open.org > Date: Tue, Aug 6, 2013 at 3:57 PM Subject: [xliff] Version Control Commit by David.Filip To: xliff@lists.oasis-open.org Author: David.Filip Date: 2013-08-06 14:57:02 +0000 (Tue, 06 Aug 2013) New Revision: 293 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/?rev=293&sc=1 Removed:    trunk/xliff-20/xliff-core-v2.0-wd02.pdf Modified:    trunk/PR01_CommentsDisposal/xliff-core-v2.0-csprd01_PRsAnnotated.pdf    trunk/xliff-20/elements/glossary/glossentry.xml    trunk/xliff-20/elements/resourceData/reference.xml    trunk/xliff-20/elements/resourceData/resourceItem.xml    trunk/xliff-20/elements/resourceData/resourceItemRef.xml    trunk/xliff-20/xliff-core-v2.0-wd02.html    trunk/xliff-20/xliff-core-v2.0-wd02.xml    trunk/xliff-20/xliff-core.html    trunk/xliff-20/xliff-core.xml    trunk/xliff-20/xliff20.xml Log: interim check in w/o pdf print out, it has only HTML printout for discussion in TC meeting ----------------------------------- Process and Agent definitions finished PRs and Constraints rehaul still in progress Othe major TODOs 1. resegmentation flag 2. Resegmentation PRs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Title: XLIFF Version 2.0 XLIFF Version 2.0 Working Draft 02 6 August 2013 Specification URIs This version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd02/xliff-core-v2.0-wd02.html (Authoritative) http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd02/xliff-core-v2.0-wd02.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd02/xliff-core-v2.0-wd02.xml Previous version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0-csprd01.html http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0-csprd01.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0-csprd01.xml Latest version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html (Authoritative) http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.xml Technical Committee: OASIS XML Localisation Interchange File Format (XLIFF) TC Chair: Bryan Schnabel ( bryan.s.schnabel@tektronix.com ), Individual Editors: Tom Comerford ( tom@supratext.com ), Individual David Filip ( davidf@ul.ie ), Localisation Research Centre Rodolfo M. Raya ( rmraya@maxprograms.com ), Maxprograms Yves Savourel ( ysavourel@enlaso.com ), ENLASO Corporation Additional artifacts: This prose specification is one component of a Work Product that also includes: XML schemas accessible from http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd02/schemas/ Related Work: This specification replaces or supersedes: XLIFF Version 1.2. 1 February 2008. OASIS Standard. http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html Declared XML Namespaces: urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.0 urn:oasis:names:tc:xliff:glossary:2.0 urn:oasis:names:tc:xliff:fs:2.0 urn:oasis:names:tc:xliff:metadata:2.0 urn:oasis:names:tc:xliff:resourcedata:2.0 urn:oasis:names:tc:xliff:changetracking:2.0 urn:oasis:names:tc:xliff:sizerestriction:2.0 urn:oasis:names:tc:xliff:validation:2.0 Abstract: This document defines version 2.0 of the XML Localisation Interchange File Format (XLIFF). The purpose of this vocabulary is to store localizable data and carry it from one step of the localization process to the other, while allowing interoperability between tools. Status: This document was last revised or approved by the OASIS XML Localisation Interchange File Format (XLIFF) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the Send A Comment button on the Technical Committee's web page at http://www.oasis-open.org/committees/xliff . For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page ( http://www.oasis-open.org/committees/xliff/ipr.php ). Citation format: When referencing this specification the following citation format should be used: [ XLIFF v2.0 ] XLIFF Version 2.0 . 6 August 2013. OASIS Working Draft 02. http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd02/xliff-core-v2.0-wd02.html . Notices Copyright © OASIS Open 2013. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the OASIS IPR Policy ). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name OASIS is a trademark of OASIS , the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark for above guidance. Table of Contents 1 Introduction 1.1 Terminology 1.1.1 Key words 1.1.2 Definitions 1.1.3 Key concepts 1.2 Normative References 1.3 Non-Normative References 2 Detailed Specifications 2.1 General Processing Requirements 2.2 Elements 2.2.1 Tree Structure 2.2.2 Structural Elements 2.2.3 Inline Elements 2.3 Attributes 2.3.1 XLIFF Attributes 2.3.2 XML namespace 2.4 CDATA sections 2.5 XML Comments 2.6 XML Processing Instructions 2.7 Inline Content 2.7.1 Text 2.7.2 Inline Codes 2.7.3 Annotations 2.7.4 Sub-Flows 2.7.5 White Spaces 2.7.6 Bidirectional Text 2.7.7 Target Content Modification 2.7.8 Content Comparison 2.8 Extension Mechanisms 2.8.1 Extension Points 2.8.2 Processing Requirements 2.9 Segmentation 2.9.1 Segments Representation 2.9.2 Segments Order 2.9.3 Segmentation Modification 3 Conformance Appendixes A XML Schemas and Catalog A.1 XML Schemas Tree A.2 XML Catalog A.3 Core XML Schema B Translation Candidates Module B.1 Module Specification B.1.1 Module Namespace B.1.2 Module Elements B.1.2.1 Tree Structure B.1.2.2 matches B.1.2.3 match B.1.3 Module Attributes B.1.3.1 id B.1.3.2 similarity B.1.3.3 matchQuality B.1.3.4 matchSuitability B.1.3.5 origin B.1.3.6 type B.1.3.7 subtype B.1.3.8 reference B.1.4 XML Schema C Glossary Module C.1 Module Specification C.1.1 Module Namespace C.1.2 Module Elements C.1.2.1 Tree Structure C.1.2.2 glossary C.1.2.3 glossentry C.1.2.4 term C.1.2.5 translation C.1.2.6 definition C.1.3 Module Attributes C.1.3.1 id C.1.3.2 source C.1.4 Example: C.1.5 XML Schema D Format Style Module D.1 Module Specification D.1.1 Module Namespace D.1.2 Module Attributes D.1.2.1 fs D.1.2.2 subFs E Metadata Module E.1 Module Specification E.1.1 Module Namespace E.1.2 Module Elements E.1.2.1 Tree Structure E.1.2.2 metadata E.1.2.3 metagroup E.1.2.4 meta E.1.3 Module Attributes E.1.3.1 category E.1.3.2 type E.1.3.3 appliesTo E.1.4 XML Schema F Resource Data Module F.1 Module Specification F.1.1 Module Namespace F.1.2 Module Elements F.1.2.1 Tree Structure F.1.2.2 resourceData F.1.2.3 resourceItemRef F.1.2.4 resourceItem F.1.2.5 source F.1.2.6 target F.1.2.7 reference F.1.3 Module Attributes F.1.3.1 id F.1.3.2 xml:lang F.1.3.3 mimeType F.1.3.4 context F.1.3.5 href F.1.3.6 ref F.1.4 Examples: F.1.5 XML Schema G Change Tracking Module G.1 Module Specification G.1.1 Module Namespace G.1.2 Module Elements G.1.2.1 Tree Structure G.1.2.2 changeTrack G.1.2.3 revisions G.1.2.4 revision G.1.2.5 item G.1.3 Module Attributes G.1.3.1 appliesTo G.1.3.2 author G.1.3.3 currentVersion G.1.3.4 datetime G.1.3.5 ref G.1.3.6 property G.1.3.7 version G.1.4 Example: G.1.5 XML Schema H Size Restriction Module H.1 Module Specification H.1.1 Introduction H.1.2 Module Namespace H.1.3 Module Elements H.1.3.1 Tree Structure H.1.3.2 profiles H.1.3.3 normalization H.1.3.4 data H.1.4 Module Attributes H.1.4.1 storageProfile H.1.4.2 generalProfile H.1.4.3 storage H.1.4.4 general H.1.4.5 profile H.1.4.6 storageRestriction H.1.4.7 sizeRestriction H.1.4.8 equivStorage H.1.4.9 sizeInfo H.1.4.10 sizeInfoRef H.1.5 Standard profiles H.1.5.1 General restriction profile ”xliff:codepoints” H.1.5.2 Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and ”xliff:utf32” H.1.6 Third party profiles H.1.7 Conformance H.1.8 XML Schema I Validation Module I.1 Module Specification I.1.1 Module Namespace I.1.2 Module Elements I.1.2.1 Tree Structure I.1.2.2 validation I.1.2.3 rule I.1.3 Module Attributes I.1.3.1 isPresent I.1.3.2 occurs I.1.3.3 isNotPresent I.1.3.4 startsWith I.1.3.5 endsWith I.1.3.6 existsInSource I.1.3.7 disabled I.1.3.8 normalization I.1.4 XML Schema J Specification Change Tracking (Non-Normative) J.1 Tracking of changes made in response to Public Reviews J.1.1 Tracking of changes in response to the 1st Public Review K Acknowledgements (Non-Normative) 1 Introduction XLIFF is the XML Localisation Interchange File Format designed by a group of software providers, localization service providers, and localization tools providers. It is intended to give any software provider a single interchange file format that can be understood by any localization provider. All text is normative unless otherwise labeled. 1.1 Terminology 1.1.1 Key words The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [ RFC 2119 ]. 1.1.2 Definitions Agent any application or tool that generates (creates), reads, edits, writes, processes, stores, renders or otherwise handles XLIFF Documents . Agent is the most general application conformance target that subsumes all specialized user agents. Enrich, Enriching the process of associating module and extension based metadata and resources with the extracted XLIFF payload Processing Requirements Enriching MAY happen at the time of Extraction . Note Extractor knowledge of the native format is not assumed while Enriching . Extract, Extraction the process of encoding localizable content from a native content or User Interface format as XLIFF payload, so that localizable parts of the content in the source language are available for Translation into the target language along with the necessary context information Extractor, Extractor Agent any Agent that performs the Extraction process Merge the process of importing XLIFF payload back to the originating native format, based on the full knowledge of the Extraction mechanism, so that the localized content or User Interface strings replace the source language in the native format Merger, Merger Agent an Agent that performs the Merge process Warning Unless specified otherwise, any Merger is deemed to have the same knowledge of the native format as the Extractor throughout the specification. Mergers independent of Extractors can succeed, but it is out of scope of this specification to specify interoperability for merging back without the full Extractor knowledge of the native format. Modify, Modification the process of changing core and module XLIFF structural and inline elements that were previously created by other Writers Processing Requirements XLIFF elements MAY be Modified and Enriched at the same time. Note Extractor or Enricher knowledge of the native format is not assumed while Modifying . Reader, Reader Agent an Agent that only renders XLIFF Documents provided by other Writers . Note Since XLIFF is intended as an exchange format rather than a processinmg format, many applications will need to generate XLIFF Documents from their internal processing formats, even in cases when they are processing an XLIFF Documents created by another Extracor . Translation a rendering of the meaning of the source text, expressed in the target language Writer, Writer Agent an Agent that cerates, generates, or otherwise writes an XLIFF Document for whatever pupose, including but not limited to Extractor , Modifier , and Enricher Agents . Note Since XLIFF is intended as an exchange format rather than a processinmg format, many applications will need to generate XLIFF Documents from their internal processing formats, even in cases when they are processing an XLIFF Documents created by another Extracor . XLIFF Document any XML document that declares the namespace urn:oasis:names:tc:xliff:document:2.0 as its main namespace, has <xliff> as the root element and complies with the XML Schemas and the declared Constraints that are part of this specification. 1.1.3 Key concepts XLIFF Core The core of XLIFF 2.0 consists of the minimum set of XML elements and attributes required to (a) prepare a document that contains text extracted from one or more files for localization, (b) allow it to be completed with the translation of the extracted text, and (c) allow the generation of translated versions of the original document. The XML namespace that corresponds to the core subset of XLIFF 2.0 is urn:oasis:names:tc:xliff:document:2.0 . XLIFF Module A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace. 1.2 Normative References [ BCP 47 ] M. Davis, Tags for Identifying Languages , http://tools.ietf.org/html/bcp47 IETF (Internet Engineering Task Force). [ HTML5 ] W3C, HTML5. A vocabulary and associated APIs for HTML and XHTML , http://www.w3.org/TR/html5/ W3C Candidate Recommendation 17 December 2012. [ NOTE-datetime ] M. Wolf, C. Wicksteed, Date and Time Formats , http://www.w3.org/TR/NOTE-datetime W3C Note, 15th Setember 1997. [ RFC 2119 ] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels , http://www.ietf.org/rfc/rfc2119.txt IETF (Internet Engineering Task Force) RFC 2119, March 1997. [ UAX #9 ] M. Davis, UNICODE BIDIRECTIONAL ALGORITHM , http://www.unicode.org/reports/tr9/ Unicode Bidirectional Algorithm. [ UAX #15 ] M. Davis, K. Whistler, UNICODE NORMALIZATION FORMS , http://www.unicode.org/reports/tr15/ Unicode Normalization Forms. [ Unicode ] The Unicode Consortium, The Unicode Standard , http://www.unicode.org/versions/latest/ Unicode Normalization Forms. [ XML ] W3C, Extensible Markup Language (XML) 1.0 , http://www.w3.org/TR/xml/ (Fifth Edition) W3C Recommendation 26 November 2008. 1.3 Non-Normative References [ XML I18N BP ] Best Practices for XML Internationalization , 13 February 2008, http://www.w3.org/TR/xml-i18n-bp/ W3C Working Group. [ LDML ] Unicode Locale Data Markup Language http://unicode.org/reports/tr35/ [ SRX ] Segmentation Rules eXchange http://www.gala-global.org/oscarStandards/srx/ 2 Detailed Specifications XLIFF is a bilingual document format designed for containing text that needs translation, its corresponding translation and auxiliary data that makes the translation proccess possible. At creation time, an XLIFF file MAY contain only text in source language. Translations expressed in target language MAY be added at a later time. The root element of an XLIFF document is <xliff> . It contains a collection of <file> elements. Each <file> element contains a set of <unit> elements that contain the text to be translated in the <source> child of one or more <segment> elements. Translations are stored in the <target> child of each <segment> element. 2.1 General Processing Requirements An agent processing a valid XLIFF document that contains XLIFF-defined elements that it cannot handle MUST preserve those elements. An agent processing a valid XLIFF document that contains custom elements that it cannot handle SHOULD preserve those elements. 2.2 Elements This section contains a description of all elements used in XLIFF 2.0. 2.2.1 Tree Structure Legend: 1 = one + = one or more ? = zero or one * = zero, one or more <xliff> 1 +--- <file> + +--- <skeleton> ? +--- <notes> ? +--- <note> + +--- <mda:metadata> ? +--- <res:resourceData> ? +--- <slr:profile> ? +--- <slr:data> ? +--- <val:validation> ? +--- At least one of ( <group> * or <unit> *) +--- <group> * +--- At least one of ( <group> * or <unit> *) +--- <notes> ? +--- <note> + +--- <mda:metadata> ? +--- <slr:data> ? +--- <val:validation> ? +---<any> * +--- <unit> * +--- <segment> + +--- <source> 1 +--- <target> ? +--- <ignorable> * +--- <source> 1 +--- <target> ? +--- <notes> ? +--- <note> + +--- <originalData> ? +--- <data> + +--- <mtc:matches> ? +--- <gls:glossary> ? +--- <mda:metadata> ? +--- <res:resourceData> ? +--- <ctr:changeTrack> ? +--- <slr:data> ? +--- <val:validation> ? +---<any> * +---<any> * 2.2.2 Structural Elements The structural elements used in XLIFF 2.0 are: <xliff> , <file> , <skeleton> , <group> , <unit> , <segment> , <ignorable> , <notes> , <note> , <originalData> , <data> , <source> and <target> . 2.2.2.1 xliff Root element for XLIFF documents. Contains: - One or more <file> elements Attributes: - version , required - srcLang , required - trgLang , optional - attributes from any namespace, optional Constraints The trgLang attribute MUST be present when the XLIFF document contains <target> elements that are children of <segment> or <ignorable> . 2.2.2.2 file Container for localization material extracted from a single document/source. Contains: - Zero or one <skeleton> element followed by - Zero or one <notes> element followed by - Zero or one <mda:metadata> elements followed by - Zero, one or more <res:resourceData> elements followed by - Zero or one <slr:profiles> elements followed by - Zero or one <slr:data> elements followed by - Zero or one <validation:validation> elements followed by - One or more <unit> or <group> elements in any order followed by - Zero, one or more elements from any namespace. Attributes: - id , optional - original , optional - srcDir , optional - trgDir , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional - attributes from any namespace, optional Constraints The value of the optional id attribute MUST be unique among all <file> children of the enclosing <xliff> element. 2.2.2.3 skeleton Container for untranslatable material pertaining to the parent <file> element. Contains: Either - Untranslatable text - XML elements from any namespace or - is empty. Attributes: - href , optional Processing Requirements Tools procesing an XLIFF file that contains <skeleton> elements MUST keep those elements unchanged. Tools creating an XLIFF file that contains <skeleton> elements MUST leave the <skeleton> element empty if and only if the attribute href is used. 2.2.2.4 group Provides a way to organize units into a structured hierarchy. Contains: - One or more <unit> or <group> elements in any order followed by - Zero or one <notes> element followed by - Zero or one <mda:metadata> elements followed by - Zero or one <slr:data> elements followed by - Zero or one <validation:validation> elements followed by - Zero, one or more elements from any namespace. Attributes: - id , optional - name , optional - srcDir , optional - trgDir , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional - attributes from any namespace, optional 2.2.2.5 unit Extracted translatable text. Contains: - One or more <segment> or <ignorable> elements in any order followed by - Zero or one <notes> element followed by - Zero or one <originalData> element followed by - Zero or one <mtc:matches> element followed by - Zero or one <gls:glossary> element followed by - Zero or one <mda:metadata> elements followed by - Zero or one <slr:data> elements followed by - Zero or one <validation:validation> elements followed by - Zero, one or more elements from any namespace. Attributes: - id , required - name , optional - translate , optional - srcDir , optional - trgDir , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional - attributes from any namespace, optional Constraints A <unit> MUST contain at least one <segment> element. The value of the id attribute MUST be unique among all <unit> children of the enclosing <file> element. A <unit> element is considered to be translated when all its <segment> children with translate attribute not set to no have the approved attribute set to yes . 2.2.2.6 segment Minimum portion of translatable text. Contains: - One <source> element followed by - Zero or one <target> element Attributes: - approved , required - id , optional - translate , optional - state , optional - subState , optional Constraints The value of the optional id attribute MUST be unique among all <segment> and <ignorable> children of the enclosing <unit> element. 2.2.2.7 ignorable Part of the extracted content that is not included in a segment (and therefore not translatable). For example some tools may use <ignorable> to store the white space and/or codes that are between two segments Contains: - One <source> element followed by - Zero or one <target> element Attributes: - id , optional Processing Requirements The value of the optional id attribute must be unique among all <segment> and <ignorable> children of the enclosing <unit> element. 2.2.2.8 notes Collection of comments. Contains: - One or more <note> elements Attributes: - fs:fs , optional - fs:subFs , optional 2.2.2.9 note A comment that contains information about <source> , <target> , <segment> or <unit> elements. Contains: - Text Attributes: - id , optional - appliestTo , optional - category , optional - priority , optional - attributes from any namespace, optional - fs:fs , optional - fs:subFs , optional 2.2.2.10 originalData Unit-level collection of original data for the inline codes. Contains: - One or more <data> elements Attributes: - fs:fs , optional - fs:subFs , optional 2.2.2.11 data Storage for the original data of an inline code. Contains: - Untranslatable text - Zero, one or more <cp> elements. Untranslatable text and <cp> elements may appear in any order. Attributes: - id , required - dir , optional - fs:fs , optional - fs:subFs , optional Constraints The value of the id attribute MUST be unique among all <data> children of the enclosing <originalData> element. 2.2.2.12 source Portion of text to be translated. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Attributes: - xml:lang , optional - xml:space , optional - dir , optional Constraints When a <source> element is a child of <segment> or <ignorable> and the optional xml:lang attribute is present, its value MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element. 2.2.2.13 target The translation of the sibling <source> element. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Attributes: - xml:lang , optional - xml:space , optional - dir , optional Constraints When a <target> element is a child of <segment> or <ignorable> and the optional xml:lang attribute is present, its value MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element. When a <target> child is added to a <segment> element, the value of its xml:space attribute MUST be set to preserve if the xml:space attribute of the sibling <source> element is set to preserve . 2.2.3 Inline Elements The inline elements at the <source> or <target> level are: <cp> , <ph> , <pc> , <sc> , <ec> , <mrk> , <sm> and <em> . The elements at the <unit> level directly related to inline elements are: <originalData> and <data> . 2.2.3.1 cp Represents a Unicode character that is invalid in XML. Contains: This element is always empty. Parents: <data> , <mrk> , <source> , <target> and <pc> Attributes: - hex , required - fs:fs , optional - fs:subFs , optional Example: <unit id= 1 > <segment> <source>Ctrl+C=<cp hex= 0003 /></source> </segment> </unit> The example above shows a character U+0003 (Control C) as it must be represented in XLIFF. Processing Requirements Writers MUST encode all invalid XML characters of the content using <cp> . Writers MUST NOT encode valid XML characters of the content using <cp> . 2.2.3.2 ph Represents a standalone code of the original format. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , optional - canDelete , optional - canReorder , optional - copyOf , optional - disp , optional - equiv , optional - id , required. - dataRef , optional - subFlows , optional - subType , optional - type , optional - fs:fs , optional - fs:subFs , optional - slr:equivStorage , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional Example: <unit id= 1 > <segment> <source>Number of entries: <ph id= 1 dataRef= d1 /> <ph id= 2 dataRef= d2 />(These entries are only the ones matching the current filter settings)</source> </segment> <originalData> <data id= d1 >%d</data> <data id= d2 >&lt;br/></data> </originalData> </unit> 2.2.3.3 pc Represents a well-formed spanning original code. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , optional - canDelete , optional - canOverlap , optional - canReorder , optional - copyOf , optional - dispEnd , optional - dispStart , optional - equivEnd , optional - equivStart , optional - id , required - dataRefEnd , optional - dataRefStart , optional - subFlowsEnd , optional - subFlowsStart , optional - subType , optional - type , optional - dir , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - slr:equivStorage , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional Example: <unit id= 1 > <segment><pc id= 1 dataRefStart= 1 dataRefEnd= 2 >Important</pc> text</source> </segment> <originalData> <data>&lt;B&gt;</data> <data>&lt;/B&gt;</data> </originalData> </unit> Processing Requirements The <pc> should not be used to represent standalone codes. Using a spanning code for standalone code may result in having text inside a span where the original format does not allow it. 2.2.3.4 sc Start marker of a spanning original code. Contains: This element is always empty. Parents : <source> , <target> , <pc> and <mrk> Attributes: - canCopy , optional - canDelete , optional - canOverlap , optional - canReorder , optional - copyOf , optional - disp , optional - equiv , optional - id , required - isolated , optional - dataRef , optional - subFlows , optional - subType , optional - type , optional - dir , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - slr:equivStorage , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional Example: <unit id= 1 > <segment> <source><sc id= 1 type= fmt subType= xlf:b />First sentence. </source> </segment> <segment> <source>Second sentence.<ec startRef= 1 type= fmt subType= xlf:b /></source> </segment> </unit> Constraints The values of the attributes canCopy , canDelete , canReorder and canOverlap MUST be the same as the values the ones in the <ec> element corresponding to this start marker. The attribute isolated MUST be set to yes when the <ec> element corresponding to this start marker is not in the same <unit> , and set to no otherwise. Processing Requirements Extractors MUST NOT use the <sc> / <ec> pair to represent standalone codes. Rationale: Using a spanning code for a standalone code can easily result in having text inside a span where the original format does not allow it. 2.2.3.5 ec End marker of a spanning original code. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , optional - canDelete , optional - canOverlap , optional - canReorder , optional - copyOf , optional - disp , optional - equiv , optional - id , optional - isolated , optional - dataRef , optional - startRef , optional - subFlows , optional - subType , optional - type , optional - fs:fs , optional - fs:subFs , optional - slr:equivStorage , optional - slr:sizeInfo , optional - slr:sizeInfoRef , optional Example: <unit id= 1 > <segment> <source>Text in <sc id= 1 dataRef= d1 />bold <sc id= 2 dataRef= d2 /> and<ec startRef= 1 dataRef= d3 /> italics<ec startRef= 2 dataRef= d4 />.</source> </segment> <originalData> <data id= d1 > </data> <data id= d2 >i </data> <data id= d3 >0 </data> <data id= d4 >i0 </data> </originalData> </unit> Processing Requirements The values of the attributes canCopy , canDelete , canReorder and canOverlap must be the same as the values the ones in the <sc> element corresponding to this end marker. The attribute isolated must be set to yes when the <sc> element corresponding to this end marker is not in the same <unit> and set to no otherwise. When the attribute isolated is set to yes , the attribute id must be used instead of the attribute startRef . The <sc> / <ec> pair should not be used to represent standalone codes. Using a spanning code for standalone code may result in having text inside a span where the original format does not allow it. 2.2.3.6 mrk Represents an annotation. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Parents: <source> , <target> , <pc> and <mrk> Attributes: - id , required - translate , optional - type , optional - ref , optional - value , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - attributes from any namespace, optional See the Annotations section for more details and examples on how to use the <mrk> element. 2.2.3.7 sm Start marker of an annotation. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - id , required - translate , optional - type , optional - ref , optional - value , optional - fs:fs , optional - fs:subFs , optional - slr:storageRestriction , optional - slr:sizeRestriction , optional - attributes from any namespace, optional See the Annotations section for more details and examples on how to use the <sm> element. 2.2.3.8 em End marker of an annotation. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - startRef , required - fs:fs , optional - fs:subFs , optional See the Annotations section for more details and examples on how to use the <em> element. 2.3 Attributes This section lists all the various attributes used in XLIFF core elements. 2.3.1 XLIFF Attributes The attributes defined in XLIFF 2.0 are: appliesTo , approved , canCopy , canDelete , canOverlap , canReorder , category , copyOf , name , dataRef , dataRefEnd , dataRefStart , dir , disp , dispEnd , dispStart , equiv , equivEnd , equivStart , hex , href , id , isolated , original , priority , ref , startRef , srcDir , srcLang , subFlows , subFlowsEnd , subFlowsStart , subType , subState , state , trgLang , translate , trgDir , type , value and version . 2.3.1.1 approved Approved - Indicates whether the holding <segment> element contains a translation suitable to be used when converting the XLIFF file to original format. Value description: yes or no . Default value: no Used in: <segment> . 2.3.1.2 appliesTo Comment target - Indicates the element to whom the content of the note applies. Value description: source or target . Default value: undefined. Used in: <note> . 2.3.1.3 canCopy Replication editing hint - Indicates whether or not the inline code can be copied. Value description: yes if the code can be copied, no if the code should not be copied. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 2.3.1.4 canDelete Deletion editing hint - Indicates whether or not the inline code can be deleted. Value description: yes if the code can be deleted, no if the code should not be deleted. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 2.3.1.5 canOverlap Code can overlap - Indicates that the spanning code where this attribute is used may enclose partial spanning codes (i.e. a start marker without its corresponding end marker, or a end marker without its corresponding start marker). Value description: yes or no . Default value: the default value for this attribute depends on the element in which it is used: When used in <pc> : no . When used in <sc> or <ec> : yes . Used in: <pc> , <sc> and <ec> Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= 3 dataRefEnd= 4 canOverlap= no />Bold, <sc id= 2 dataRef= 1 canOverlap= yes />both</pc>, italics<ec startRef= 2 dataRef= 2 /></source> </segment> <originalData> <data id= 1 >i1 </data> <data id= 2 >i0 </data> <data id= 3 >{ </data> <data id= 4 >}</data> </originalData> </unit> 2.3.1.6 canReorder Re-ordering editing hint - Indicates whether or not the inline code can be re-ordered. See Editing Hints section for more details. Value description: yes if the code can be re-ordered, no if the code should not be re-ordered. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 2.3.1.7 category Category - Provides a way to categorize notes. Value description: Text. Default value: undefined Used in: <note> . 2.3.1.8 copyOf Reference to base code - Holds the id of the base code of a copied code. Value description: NMTOKEN. The id value of the base code of which this code is a copy. Default value: undefined Used in: <ph> , <pc> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Äter <pc id= 1 >katter möss</pc>?</source> <target>Do <pc id= 1 >cats</pc> eat <pc id= 2 copyOf= 1 >mice</pc>?</target> </segment> </unit> 2.3.1.9 dir Indicates the directionality of a content. Value description: ltr (Left-To-Right) or rtl (Right-To-Left) Default value: default values for this attribute depend on the element in which it is used: When used in <source> : The value of the srcDir attribute of the <unit> element in which the unit is located. When used in <target> : The value of the trgDir attribute of the <unit> element in which the unit is located. When used in <pc> , or <sc> : The value of the dir attribute of the <source> or <target> element in which the element is located. When used in <data> : The value ltr . Used in: <source> , <target> , <data> , <pc> and <sc> . 2.3.1.10 disp Display text - Holds an alternative user-friendly display representation of the original data of the inline code. Value description: Text Default value: undefined Used in: <ph> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Welcome back <ph id= 1 disp= [UserName] dataRef= d1 />!</source> </segment> <originalData> <data id= d1 >{1}</data> </originalData> </unit> Note To provide a plain text equivalent of the code, use the equiv attribute. 2.3.1.11 dispEnd Display text - Holds an alternative user-friendly display representation of the original data of the end marker of an inline code. Value description: Text Default value: undefined Used in: <pc> . Example: <unit id= 1 > <segment> <source>Example of <pc id= 1 dataRefStart= d1 dataRefEnd= d2 dispStart= &lt;span> dispEnd= &lt;/span> >formatted text</pc>.</source> </segment> <originalData> <data id= d1 >cf1ulf1fs24 </data> <data id= d2 >cf0ulnone0f0fs22 </data> </originalData> </unit> In the example above, the dispStart and dispEnd attributes provide a more user-friendly representation of the original formatting codes. Note To provide a plain text equivalent of the code, use the equivEnd attribute. 2.3.1.12 dispStart Display text - Holds an alternative user-friendly display representation of the original data of the start marker of an inline code. Value description: Text Default value: undefined Used in: <pc> . Example: <unit id= 1 > <segment> <source>Example of <pc id= 1 dataRefStart= d1 dataRefEnd= d2 dispStart= &lt;span> dispEnd= &lt;/span> >formatted text</pc>.</source> </segment> <originalData> <data id= d1 >cf1ulf1fs24 </data> <data id= d2 >cf0ulnone0f0fs22 </data> </originalData> </unit> In the example above, the dispStart and dispEnd attributes provide a more user-friendly representation of the original formatting codes. Note To provide a plain text equivalent of the code, use the equivStart attribute. 2.3.1.13 equiv Equivalent text - Holds a plain text representation of the original data of the inline code that may be used when generating a plain text representation of the content. Value description: Text Default value: an empty string. Used in: <ph> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Open <ph id= 1 equiv= dataRef= d1 />File</source> </segment> <originalData> <data id= d1 >&amp;</data> </originalData> </unit> In this example the equiv attribute of the <ph> element is used to indicate that the original data of the code can be ignored in the text representation of the string. This could, for instance, help a spell-checker tool to process the content as Open File . Note To provide a user-friendly representation, use the disp attribute. 2.3.1.14 equivEnd Equivalent text - Holds a plain text representation of the original data of the end marker of an inline code that may be used when generating a plain text representation of the content. Value description: Text Default value: an empty string Used in: <pc> . Example: <unit id= 1 > <segment> <source>The jam made of <pc id= 1 dataRefStart= d1 equivStart= dataRefEnd= d2 equivEnd= >lingonberries</pc> is quite tasty.</source> </segment> <originalData> <data id= d1 >&lt;span class= link ></data> <data id= d2 >&lt;/span></data> </originalData> </unit> Note To provide a user-friendly representation, use the dispEnd attribute. 2.3.1.15 equivStart Equivalent text - Holds a plain text representation of the original data of the start marker of an inline code that may be used when generating a plain text representation of the content. Value description: Text Default value: an empty string Used in: <pc> . Example: <unit id= 1 > <segment> <source>The jam made of <pc id= 1 dataRefStart= d1 equivStart= dataRefEnd= d2 equivEnd= >lingonberries</pc> is quite tasty.</source> </segment> <originalData> <data id= d1 >&lt;span class= link ></data> <data id= d2 >&lt;/span></data> </originalData> </unit> Note To provide a user-friendly representation, use the dispStart attribute. 2.3.1.16 hex Hexadecimal code point - Holds the value of a Unicode code point that is invalid in XML. Value description: A canonical representation of the hexBinary XSD data type: Two hexadecimal digits to represent each octet of the Unicode code point. The allowed values are any of the values representing code points invalid in XML, between hexadecimal 0000 and 10FFFF (both included). Default value: undefined Used in: <cp> . Example : <cp hex= 001A /><cp hex= 0003 /> The example above shows a character U+001A and a character U+0003 as they should be represented in XLIFF. 2.3.1.17 href href - a pointer to the location of an external skeleton file pertaining to the enclosing <file> element.. Value description: IRI. Default value: undefined Used in: <skeleton> . 2.3.1.18 id Identifier - A character string used to identify an element. Value description: NMTOKEN. The scope of the values for this attribute depend on the element in which it is used When used in <unit> : The value must be unique within the <file> element. When used in <segment> or <ignorable> : The value must be unique within the <unit> element. When used in <data> : The value must be unique within the <originalData> element. When used in <mrk> , <sm> , <pc> , <sc> , <ec> or <ph> : The value must be unique within the <segment> or <ignorable> elements and inline elements with the same id in both source and target must be corresponding elements. Default value: undefined Used in: <file> , <unit> , <segment> , <ignorable> , <match> , <data> , <sc> , <ec> , <ph> , <pc> , <mrk> and <sm> . 2.3.1.19 isolated Orphan code flag - Indicates if the start or end marker of a spanning inline code is not in the same <unit> as its corresponding end or start marker. Value description: yes if this start or end marker is not in the same <unit> as its corresponding end or start marker, no if both markers are in the same <unit> . Default value: no Used in: <sc> , <ec> . Example: <unit id= 1 > <segment> <source><pc id= 1 >Warning: File not found.</pc></source> </segment> <mtc:matches> <mtc:match> <segment> <source><sc id= 1 isolated= yes />Warning:</source> <target><sc id= 1 isolated= yes />Attention :</target> </segment> </mtc:match> </match> </unit> In the example above the <sc> elements have their isolated attribute set to yes because they do not have their corresponding <ec> elements. 2.3.1.20 name Resource Name - The original identifier of the resource corresponding to the extracted <unit> or <group> . For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc. Value description: text string. Default value: undefined. Used in: <unit> and <group> . 2.3.1.21 dataRef Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <ph> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Error in '<ph id= 1 dataRef= d1 />'.</source> <target>Erreur dans '<ph id= 1 dataRef= d1 />'.</target> </segment> <originalData> <data id= d1 >{0}</data> </originalData> </unit> The example above shows a <ph> element that has its original data stored outside the content, in a <data> element. 2.3.1.22 dataRefEnd Original data reference - Holds the identifier of the <data> element that contains the original data for the end marker of a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <pc> . Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficiency<pc> is the operative word here.</source> <target><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficacité<pc> est le mot clé ici.</target> </segment> <originalData> <data id= d1 >&lt;EM></data> <data id= d2 >&lt;/EM></data> </originalData> </unit> The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements. 2.3.1.23 dataRefStart Original data reference - Holds the identifier of the <data> element that contains the original data for the start marker of a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <pc> . Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficiency<pc> is the operative word here.</source> <target><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficacité<pc> est le mot clé ici.</target> </segment> <originalData> <data id= d1 >&lt;EM></data> <data id= d2 >&lt;/EM></data> </originalData> </unit> The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements. 2.3.1.24 original Original File - A pointer to the location of the original document from which the content of the enclosing <file> element is extracted. Value description: Text. Default value: undefined Used in: <file> . 2.3.1.25 priority Priority - Provides a way to prioritize notes. Value description: Integer 1-10. Default value: 1 Used in: <note> . Note Please note that 1 is the highest priority that can be interpeted as an alert, e.g. an ITS Localization Note of the type alert. The best parctice is to use only one alert per an anotated element, and the full scale of 2-10 can be used for prioritizing notes of lesser importance than the alert. 2.3.1.26 ref Reference - Holds a reference for the associated annotation. Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation: When used in a term annotation , the value is referring to the resource providing information about the term. When used in a comment annotation , the value is referring to a <note> element. When used in a custom annotation , the value is defined by each custom annotation. Default value: undefined Used in: <mrk> or <sm> . Example : <unit id= 1 > <segment> <source>The <pc id= 1 >ref</pc> attribute of a term annotation holds a <mrk id= m1 type= term ref= http://dbpedia.org/page/Uniform_Resource_Identifier >URI</mrk> pointing to more information about the given term.</source> </segment> </unit> Constraints The value of the ref attribute SHOULD point to an element that is a child of the <unit> element where the parent of the attribute is located.

    Attachment(s)

    html
    xliff-core.html   442 KB 1 version