RE: [xliff] Propose 2 enhancements to @fs

Thanks for the input Rodolfo.

I agree with your statement about <data> being tool defined. For that matter aren't all, or nearly all XLIFF elements tool defined (or utilized at a tool's discretion)? I think your caution is a good one, that " You can’t rely on" {insert any feature that different feature is leveraging} "unless you have created the XLIFF file." So I think this true statement really effects fs no more than it effects many others.

It seems we are in agreement with your second point, no need to restrict HTML element names that you can put in @fs (except non-format types, like <script>). I'm not sure what you mean about "define the attributes in your XSL . . ." While I chose to illustrate my concept with XSLT - any transform scripting language could be used to leverage the fs attribute. It just needs to know how to find the metadata (in this case, the image url).

I'm also not sure what you mean about no need/place to store HTML attributes in the XLIFF file. I guess that's also up to the tool. If you want to reconstruct a source file to its original format as part of an XLIFF roundtrip, all the format information (if the source is HTML, that would include the HTML attributes) would need to be obtainable (internal, external, minimalist, maximalist, whatever). If the translated XLIFF file never needs to be reconstructed, no need for any original format information to be stored (HTML attributes, or any other).

I'll have to strongly emphasize my point when you say: "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." Let's be careful to not confuse the just-in-time HTML browser view from anything having to do with the source file format.

I just used that markup (<data id="222"><img src="" because it was recently cited as a recommended way to mark up images. The concept works exactly the same for other formats (like rtf). In that case, I guess the <data> would look more like this:

<source>Science is <ph id="1" nid="222"/> good.</source>

<target fs="p">科学还是不错 <ph id="1" nid="222" type="image" fs="img" /> 的。</target>

</segment>

<data id="222">{\*\fldinst {\rtlch\fcs1 \af31507 \ltrch\fcs0 \insrsid7281645 INCLUDEPICTURE "big-happy-smile.jpg" \\* MERGEFORMAT }}</data>

</originalData>

</unit>

We have

· a string of extracted RTF text, and

· a <ph> that holds its place (decorated with an fs attribute which assigns an HTML formatting direction *only for the just in time browser view* - not for anything having to do with the reformatting back to RTF), and

· a <data> element that holds the code for the RTF

I would barely need to modify the XSLT to generate the just-in-time browser view. In fact, I think I will also do an RTF roundtrip also to add as a sample.

Thanks,

Bryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Friday, October 05, 2012 3:04 PM
To: xliff@lists.oasis-open.org; xliff-inline@lists.oasis-open.org
Subject: RE: [xliff] Propose 2 enhancements to @fs

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">

<source>History</source>

</segment>

</unit>

</segment>

</unit>

<source>Science</source>

</segment>

</unit>

<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>

</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>

</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:

<head>

</head>

<body>

<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

xliff message