Hi Bryan,
The content of <data> is tool defined. You can’t rely on it unless you have created the XLIFF file.
I don’t see a need to restrict the HTML element names that you can put in an “fs” attribute. You can use HTML elements that require attributes if you define the attributes in your XSL stylesheet.
There is no place for storing HTML attributes in the XLIFF file and there is no need to add support for that in Core.
You are worried about images but you are using only HTML sources as example. Any solution added to the XLIFF standard should contemplate all possible formats, including images in an RTF file.
Regards,
Rodolfo
--
Rodolfo M. Raya rmraya@maxprograms.com
Maxprograms http://www.maxprograms.com
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Friday, October 05, 2012 6:17 PM
To: xliff@lists.oasis-open.org; xliff-inline@lists.oasis-open.org
Subject: [xliff] Propose 2 enhancements to @fs
Hello,
As I worked on issues identified by Yves regarding problems with the fs attribute, I made some discoveries, which lead me to propose a few minor enhancements to fs.
To restate the purpose of the fs attribute, I believe it is meant to enable a quick, in context review, in a browser. In other words, to make a stand-alone browser view from an unfriendly-for-review XLIFF file. It is not meant to be a final, publishable, HTML output. The workflow should be nimble, and mobile (i.e., we can quickly email the stand-alone HTML to reviewers who might read it on a computer, tablet, or phone). In a world where Web CMS systems are used to render web pages, this need becomes abundantly clear. In my own case, enabling translators to in-context-review translated XLIFF whose final home would be Drupal turned out to be a major challenge.
Summary: To make this a robust solution, we'd need to (1) add @fs to inline elements (perhaps restricting inline elements to only inline HTML values, as Yves suggests). And we'd need (2) to change our criteria for which HTML elements are valid fs values. We formerly restricted fs values to those HTML elements that do not require an attribute.
I propose we allow fs values that include HTML elements that require an attribute. To so this fs could rely on information set in the <data> element. Assuming using the <data> element in this role is okay, we could add elements like <img> to the list of acceptable values for the fs attribute.
I will illustrate with the following use case. Let's start with a simple translated XLIFF file, with no skeleton, with a few fs attributes, and with an image whose url is stored in a corresponding <data> element.
Start with the XLIFF file:
<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xliff:document:2.0 xliff_core_2.0.xsd" version="2.0">
<file original="xliff_example.html" fs="body">
<unit id="1">
<segment>
<source>History</source>
<target fs="h2">历史</target>
</segment>
</unit>
<unit id="2">
<segment>
<source>This is a <pc id="p1">good </pc>book.</source>
<target fs="p">这是一个<pc id="p1" fs="big">好</pc>的书。</target>
</segment>
</unit>
<unit id="1">
<segment>
<source>Science</source>
<target fs="h2">科学</target>
</segment>
</unit>
<unit id="2">
<segment>
<source>Science is <ph id="1" nid="222"/> good.</source>
<target fs="p">科学还是不错 <ph id="1" nid="222" type="image" fs="img" /> 的。</target>
</segment>
<originalData>
<data id="222"><img src="">
</originalData>
</unit>
</file>
</xliff>
Apply this XSLT to the XLIFF:
<?xml version="1.0"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0"
version="2.0">
<xsl:output method="xml" indent="yes" encoding="utf-8" />
<xsl:strip-space elements="*" />
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="xlf:xliff" priority="3">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<xsl:apply-templates />
</html>
</xsl:template>
<xsl:template match="*" priority="2">
<xsl:choose>
<xsl:when test="local-name()='ph' and @fs">
<xsl:variable name="nid" select="@nid" />
<xsl:variable name="attname">
<xsl:for-each select="ancestor::xlf:unit[1]//xlf:data[@id=$nid]">
<xsl:value-of select="substring-before(substring-after(.,' '),'=')" />
</xsl:for-each>
</xsl:variable>
<xsl:variable name="attval">
<xsl:for-each select="ancestor::xlf:unit[1]//xlf:data[@id=$nid]">
<xsl:value-of select="substring-before(substring-after(.,'"'),'"')" />
</xsl:for-each>
</xsl:variable>
<xsl:element name="{@fs}">
<xsl:attribute name="{$attname}" select="$attval" />
<xsl:apply-templates />
</xsl:element>
</xsl:when>
<xsl:when test="@fs">
<xsl:element name="{@fs}">
<xsl:apply-templates />
</xsl:element>
</xsl:when>
<xsl:when test="text()[not(parent::*[@fs])]">
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:transform>
The result is this HTML file:
<html xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
</head>
<body>
<h2>历史</h2>
<p>这是一个<big>好</big>的书。</p>
<h2>科学</h2>
<p>科学还是不错 <img src="" 的。</p>
</body>
</html>
Which renders nicely in the browser:
I am not sure how this will all look on the mailing list. So please feel free to unzip the attached demonstration, and run the batch file to see the results for yourself.
Thanks
Bryan Schnabel
Content Management Architect
Phone: 503.627.5282
www.tektronix.com
