OASIS XML Localisation Interchange File Format (XLIFF) TC

I've added this to the proposed features in the wiki.   What if we put an optional attribute on XLIFF elements that match HTML elements? It would enable a quick "at-a-glance" HTML page to be created for review cycle. It would be important to specify that the attribute is not meant for round-tripping back into the original format.   I imagine this would be extended vs. core.   For example:   Have an optional format-style attribute to put on block and inline XLIFF elements that map to HTML, like this:   <group fs="html" >   <group fs="body" >     <trans-unit fs="div" >      <source fs="p" >Mick Jones renewed his interest in the Vintage <ph fs="strong" >'72 Telecaster Thinline </ph>guitar. <x fs="br" />He says <ph fs="q" >I love 'em</ph></source>     </trans-unit>     <trans-unit fs="div" >     . . .     </trans-unit>   </group> </group>   A simple XSL like this:   <xsl:template match="node() @*"> <xsl:copy>   <xsl:apply-templates select="@* node()"/> </xsl:copy> </xsl:template>   <xsl:template match="*" priority="2"> <xsl:element name="{ @fs }">   <xsl:apply-templates /> </xsl:element> </xsl:template>   Could make a nice at-a-glance review page like this:   < html >    < body >       < div >          < p >Mick Jones renewed his interest in the Vintage < strong >'72 Telecaster Thinline </strong>guitar. < br />He says < q >I love 'em</q>          </p>       </div>       <div>     . . .     </div>    </body> </html>   For that matter, in the example above we could skip the group elements and fs attributes and let the processor assume they were implied.   Bryan Schnabel Content Management Architect Phone: 503.627.5282 www.tektronix.com      

Hi Bryan, > What if we put an optional attribute on XLIFF elements > that match HTML elements? It would enable a quick > "at-a-glance" HTML page to be created for review cycle. a) Could/should this be related to the ‘disp’ attribute we currently have in inline markup? b) I've noticed things like "<ph fs="strong">'72 Telecaster Thinline</ph>". I assume you meant "<pc fs="strong">'72 Telecaster Thinline</pc>". Is that correct? c) How would <sc>/<ec> be handled? I assume <sc id='1' fs='b'/> and <ec rid='1' fs='b'/>. Is that correct? d) This feature looks somewhat similar to the dx:equiv-markup-open and dx:equiv-markup-close defined in XLIFF:doc[1]. In your example the value of fs is only an HTML element name. Would there be any reason to use full HTML markup instead? (so you could possibly specify class names, etc.). cheers, -yves [1] http://interoperability-now.googlecode.com/files/XLIFFdoc%20Representation%20Guide.pdf

Hi Yves, Replies below ________________________________________ From: Yves Savourel [ysavourel@enlaso.com] Sent: Tuesday, November 01, 2011 4:33 AM To: Schnabel, Bryan S; xliff@lists.oasis-open.org Subject: RE: [xliff] Add optional format attribute for quick at-a-glance review Hi Bryan, > What if we put an optional attribute on XLIFF elements > that match HTML elements? It would enable a quick > "at-a-glance" HTML page to be created for review cycle. a) Could/should this be related to the ‘disp’ attribute we currently have in inline markup? - could be. But I see my proposal as being purposefully narrow in scope, just for just-in-time review b) I've noticed things like "<ph fs="strong">'72 Telecaster Thinline</ph>". I assume you meant "<pc fs="strong">'72 Telecaster Thinline</pc>". Is that correct? - no thought was given to proposed elements in the inline SC. I just picked an existing 1.2 inline element. <ph> and <x> seemed okay; could have picked <mrk> or <g>. I would see this attribute going on any inline tag. c) How would <sc>/<ec> be handled? I assume <sc id='1' fs='b'/> and <ec rid='1' fs='b'/>. Is that correct? - Assuming <ec> is properly terminated, no need for the fs attribute. If escaped HTML markup existed, no need for fs attribute. Otherwise, yes (<sc id='1' fs='b'/>) d) This feature looks somewhat similar to the dx:equiv-markup-open and dx:equiv-markup-close defined in XLIFF:doc[1]. In your example the value of fs is only an HTML element name. Would there be any reason to use full HTML markup instead? (so you could possibly specify class names, etc.). - don't think so. The class attribute seems like overkill. I see my proposal as being purposefully narrow in scope, just for just-in-time review. Might think about linking attributes and even img/src, but with care to be narrow and focused on just-in-time review cheers, -yves [1] http://interoperability-now.googlecode.com/files/XLIFFdoc%20Representation%20Guide.pdf

>> b) I've noticed things like "<ph fs="strong">'72 Telecaster >> Thinline</ph>". I assume you meant "<pc fs="strong">'72 >> Telecaster Thinline</pc>". Is that correct? > > - no thought was given to proposed elements in the inline SC. > I just picked an existing 1.2 inline element. > <ph> and <x> seemed okay; could have picked <mrk> or <g>. > I would see this attribute going on any inline tag. Got it. But then I still would like to be sure that you meant "<g fs="strong">'72 Telecaster Thinline</g>" as using <ph> should not enclose text content. What I'm looking for is the re-assurance that using <ph> was a typo and not because you have a different understanding of <ph> than I do :) Talk to you soon, -ys

Agreed. ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] On Behalf Of Yves Savourel [ysavourel@enlaso.com] Sent: Tuesday, November 01, 2011 7:50 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] Add optional format attribute for quick at-a-glance review >> b) I've noticed things like "<ph fs="strong">'72 Telecaster >> Thinline</ph>". I assume you meant "<pc fs="strong">'72 >> Telecaster Thinline</pc>". Is that correct? > > - no thought was given to proposed elements in the inline SC. > I just picked an existing 1.2 inline element. > <ph> and <x> seemed okay; could have picked <mrk> or <g>. > I would see this attribute going on any inline tag. Got it. But then I still would like to be sure that you meant "<g fs="strong">'72 Telecaster Thinline</g>" as using <ph> should not enclose text content. What I'm looking for is the re-assurance that using <ph> was a typo and not because you have a different understanding of <ph> than I do :) Talk to you soon, -ys --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org