[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xliff] Consolidation - Embedded XLIFF
Following up on the action item of last meeting, here is the consolidated information on the topic "Embedded XLIFF". -yvesTitle: Embedded XLIFF
Last update: Jun-03-2002
1. Status After Meeting
2. Discussion
2.1. Gérard's Proposal
3. Additional Information
3.1. Embedding a Full XLIFF
Document
3.2. Embedding One or More
XLIFF Constructs
3.3. Embedding Localization
Directives
Agreed to on principle, need to be worked on.
The original proposition came from Gérard (see email: http://lists.oasis-open.org/archives/xliff/200205/msg00004.html). The text and the example files are reproduced below:
Microsoft recommended proposal for XLIFF 1.1: make XLIFF tags a namespace
that can also be used in software and content data files. This proposal is an
add-on to Eric's proposal. The idea is to make XLIFF an open model XML schema so
that it can carry localization data and also the complete xml-based source file
as context.
Think of an xml based help file or web page that has its own schema that the
localization process has no knowledge about. We call it the user domain schema.
After the source authoring is done, the xml file is handed over to localization
engineers/process to add localization directives.
Currently, most processes need to extract resources into a canonical form, such
as a resource table. XLIFF is the export format of that form. The problem with
this is that the context information for the resources is lost. It is especially
the case for content localization.
Imagine that we keep the source file as the main vehicle for transforming data.
We insert localization directives directly into the source file but in XLIFF
namespace. (It is technically possible to make the same document be valid for
both the user schema and XLIFF schema.) Then, we can transfer the VERY SAME
SOURCE FILE to the localizer without losing any context information. This way, a
localizer can view the resources in two views:
1) The original source file view and
2) the table view for all trans units.
This way, content localization and software localization can be the same as long
as they both are xml based files. I rewrite the sample-xliff.xml file to
illustrate the idea. The first file is dialog.xml, which is an imagined windows
resource xml based format. Think of it as the XML based RC file. The second file
is the mixed content from both the user schema and XLIFF schema. You can see the
clear separation of information from two schemas. An XLIFF element is mostly a
child element to a user domain element to add localization directives. It can
have references to the user domain data such as to tell XLIFF where the source
text is located in the string table.
Dialog.xml (no XLIFF markup):
<?xml version="1.0" encoding="UTF-8"?> <WindowsResource xmlns:urn="urn:b" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="resource.xsd"> <Dialog name="foo" help-id="17" x="0" y="0" cx="100" cy="100"> <string id="id_102">Hello World!</string> <image mime-type="image/jpg" md5-checksum="0123456789abcdef"> 012345abcdefghijklmnopqrstuvwxyz012345abcdefghijklmnopqrs </image> </Dialog> </WindowsResource>
Dialog.xml with embedded XLIFF markup (Note that Gérard's example was done using the syntax from Eric's 1.1 proposal):
<?xml version="1.0" encoding="UTF-8"?>
<WindowsResource
xmlns:urn="urn:b" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="resource-xliff.xsd"
xmlns:xlf="xlf"
version="1.1" language="en-us" >
<!-- the new schema above imports the xliff schema as secondary schema -->
<xlf:header uri="http://www.xmlspy.com"
md5-checksum="A9FD64E12C"
content-creation-tool="XEmacs"
content-creation-tool-version="21.4"
content-creation-date="2002-04-23"
category="General"
mime-type="text/html"
source-language="en-us"
target-language="fr-fr"
product-name="String"
product-version="String"
build-num="String">
<xlf:instructions language="en-us" priority="1">
<xlf:html-content xmlns:h="http://www.w3.org/1999/xhtml">
Translate <h:b>this</h:b> document.
</xlf:html-content>
</xlf:instructions>
<xlf:comment language="en-us">
<xlf:author name="Some User" email="user@company.com"
phone="888 555 1212"/>
<xlf:text-content mime-type="text/plain">
Here's a simple text comment
</xlf:text-content>
</xlf:comment>
<xlf:style-guide language="en-us">
<xlf:contact name="Andrew Other" email="another@place.com"
phone="888 555 1212"/>
<xlf:link href=""my_style.doc"" mime-type="application/msword"/>
</xlf:style-guide>
</xlf:header>
<Dialog name="foo" help-id="17" x="0" y="0" cx="100" cy="100">
<xlf:group id="id_101">
<xlf:comment>
<xlf:text-content>Top level group</xlf:text-content>
</xlf:comment>
</xlf:group>
<xlf:resource-context type="dialog"></xlf:resource-context>
<string id="id_102">
<xlf:trans-unit id="id_102" sourceRef="text">
<xlf:alt-trans match-quality="98">
<xlf:target>Salut Monde!</xlf:target>
</xlf:alt-trans>
<xlf:alt-trans match-quality="medium">
<xlf:target>Bonjour Monde!</xlf:target>
</xlf:alt-trans>
</xlf:trans-unit>
Hello <xlf:bpt id="id_104" ref="id_105"><b></xlf:bpt>World!
<xlf:ept id="id_105" ref="id_104"></b></xlf:ept>
</string>
<image mime-type="image/jpg" md5-checksum="0123456789abcdef">
<xlf:bin-unit id="id_103" sourceRef="text" />
012345abcdefghijklmnopqrstuvwxyz012345abcdefghijklmnopqrs
</image>
</Dialog>
</WindowsResource>
For those less familiar with Eric's proposed version, the following example (not included in the original examples) is a similar file but using embedded XLIFF constructs that follow more closely the current notation:
<?xml version="1.0" encoding="UTF-8"?>
<WindowsResource xmlns:urn="urn:b"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="resource.xsd"
xlf:"urn:oasis:names:tc:xliff:document:embedded:1.0">
<xlf:header>
<xlf:note>Translate this document.</xlf:note>
<xlf:reference>
<external-file href=""my_style.doc"/>"
</xlf:reference>
</xlf:header>
<Dialog name="foo" help-id="17" x="0" y="0" cx="100" cy="100">
<string id="id_102">
<text>Hello World!</text>
<xlf:alt-trans match-quality="98">
<xlf:target xml:lang="fr">Salut Monde!</xlf:target>
</xlf:alt-trans>
<xlf:alt-trans match-quality="medium">
<xlf:target xml:lang="fr-CH">Bonjour Monde!</xlf:target>
</xlf:alt-trans>
</string>
<image mime-type="image/jpg" md5-checksum="0123456789abcdef">
012345abcdefghijklmnopqrstuvwxyz012345abcdefghijklmnopqrs
</image>
</Dialog>
</WindowsResource>
The meeting participants felt that providing some way to embed XLIFF-related data in other formats would be very beneficial. This can be broken down into three main types of use:
Scenario: The other XML format embed directly a full XLIFF document.
This is already possible because, in this case, the burden of allowing such construct falls completely on the other format. There is no special provision needed in XLIFF to allow this.
Scenario: This is the example given by Gérard. Here, "chunks" of XLIFF data are inserted in specific location of the other format.
This will require to define a schema (different from the XLIFF schema) that other formats can import in their own schemas. Such schema will provide sets of XLIFF elements and attributes declared and structured in a way they can be embedded in other constructs.
Scenario: This case is related to the previous one, but with a much finer granularity. The localization directives may not necessarily, in some cases, match directly XLIFF elements or attributes but they allow tools to map information to XLIFF constructs.
Localization directives are isolated elements or attributes in an arbitrary
XML document that indicate properties related to localization. Such properties
can be mapped in XLIFF construct. For example: maxbytes. In
addition, some of the directives may not exist as elements or attribute of XLIFF
itself, but may be need to create XLIFF.
We need to define a set of requirements, then a vocabulary. This vocabulary will most likely be a subset of XLIFF with a few additional constructs.
Localization directives are part of some work started under the ITS group, and also proposed as a possible activity for the W3C internationalization working group (under the topic of "localizability").
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC