OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-inline] Complex tag content


Hi Arle,

 

Thanks for the gnarly examples (yuck!). In each of these cases my guess is that you'd want to hide the ugliness in the skeleton, and expose just the translated parts in the trans-units, like this:

 

<xliff>

<header>

  <skeleton>

   <xlf_skel_module:p><xlf_skel_module:source idref="b1" />

        <script type="text/javascript">

    /* <![CDATA[ */

    function hivelogic_enkoder(){var kode=

    "kode=\"nrgh@%>,**=,40kwjqho1hgrn+wDudkf1hgrnBkwjqho1hgrn?l+.{@hgrn\\000,l+"+

    "wDudkf1hgrn.,4.l+wDudkf1hgrn@.{~,5@.l>,40kwjqho1hgrn+?l>3@l+uri>**@{>_%@{g"+

    "hnr,\\000+fghFrduFkrpiuj1lqwu@V{.;>45.@,f?3+fli6>,0+lDwghFrdufkh1rg@n~f.,l"+

    ".k>jwhq1oghnrl?3>l@u+ir*>@*>{~_%__kCuj3q33/____.ijkIugxInuslxm4otzxCY~1>A7"+

    "81C/iB6.iol9A/3.oGzjkIugxink4ujCq\\001i1/o1nAmzkt4rjkquoB6AoCx.lu-AC-A~\\0"+

    "01(nFxm6t662b1lmnLxj{Lqxvo{p7rw}{F\\\\\\0014AD:;4F2lE91lro<D261rJ}mnLxj{lq"+

    "n7xmFt4l332____44Dr}qwpunn7xmEtDrF91rx{Do00\\001F+D5GJ.;myHo{p:~x3{33z____"+

    "u{m\\00066b6xuomx{{LzrJuh.<Aq==x7=\\000b.\\177Ih\\177\\177xm,oh.{y:oxp{~33"+

    "____3{z\\000u6m66ubmx{oLxr{uz{Fx\\000mu.yIhqrt~m,.Hq4u\\0003~33:____z\\000"+

    "yqo\\001p{F+mntxC(jkqu@_%__ghnr_%@hgrn%>nrgh@nrgh1vsolw+**,1uhyhuvh+,1mrlq"+

    "+**,\";x='';for(i=0;i<kode.length;i++){c=kode.charCodeAt(i)-3;if(c<0)c+=12"+

    "8;x+=String.fromCharCode(c)}kode=x"

    ;var i,c,x;while(eval(kode));}hivelogic_enkoder();

    /* ]]> */

    </script>

   </xlf_skel_module:p>

  </skeleton>

</header>

<body>

  <trans-unit id="b1">

   <source>&copy; 2011&nbsp;Localization World&nbsp; |&nbsp;

     <inliner name="span"

              xlf_preserve_att_module:class="style21"> +1 208 263 8178</inliner>|&nbsp; </source>

   <target>Land</target>

  </trans-unit>

</body>

 

Just to illustrate a possible future mechanism (not meant to be a proposal), I've added some nonexistent XLIFF core and module elements (for example <inliner> would be core and <xlf_skel_module> would be a module), and a nonexistent method for preserving source attributes (xlf_preserv_att_module:source-attribute). And I left the text entities just as they are in source. I think you could make a case that ubiquitous text entities like copyright and nonbreaking-space could/should be thought of on the same level as letters or characters and can be moved, deleted, inserted, etc. (perhaps a contentious assumption).

 

And your second example is not only ugly, it is also (XML) malformed. Ignoring the malformedness, I'd still just stick the ugliness in the skeleton and expose the translator to the content:

 

<xliff>

<header>

  <skeleton>

   <xlf_skel_module:span dojoType="dojo.data.ItemFileWriteStore"

        jsId="jsonStore" data=""{&quot;identifier&quot;:&quot;id&quot;,

                               &quot;label&quot;: &quot;label&quot;,

                               &quot;items&quot;: [

                                  { &quot;id&quot;:&quot;AF&quot;,&quot;label&quot;:&quot;&lt;b&gt;IMx&lt;/b&gt;&quot;, &quot;type&quot;:&quot;continent&quot;},

                                  { &quot;id&quot;:&quot;AR&quot;,&quot;label&quot;:&quot; <!-- this div is malformed--><div class=\&quot;aaaa\&quot;    

                                   &quot;, &quot;type&quot;:&quot;<xlf_skel_module:source idref="a1" />&quot; }

                                  ]

                               }"

        ></xlf_skel_module:span>

  </skeleton>

</header>

<body>

  <trans-unit id="a1">

   <source>country</source>

   <target>Land</target>

  </trans-unit>

</body>

</xliff>

 

Notice that I skillfully side-stepped the more pressing point made at today's SC meeting, that there needs to be a way of exposing the code (in extreme cases) to the translator. My answer does not address that scenario. And if I read your examples correctly, neither do they.

 

Thanks,

 

Bryan

 

From: Arle Lommel [mailto:alommel@gala-global.org]
Sent: Tuesday, June 14, 2011 12:11 PM
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Complex tag content

 

In line with today's discussion, I wanted to share an example of a complex inline code I found before the meeting:

 

<p>&copy; 2011&nbsp;Localization World&nbsp; |&nbsp;<span class="style21"> +1 208 263 8178</span>|&nbsp; 
        <script type="text/javascript">
/* <![CDATA[ */
function hivelogic_enkoder(){var kode=
"kode=\"nrgh@%>,**=,40kwjqho1hgrn+wDudkf1hgrnBkwjqho1hgrn?l+.{@hgrn\\000,l+"+
"wDudkf1hgrn.,4.l+wDudkf1hgrn@.{~,5@.l>,40kwjqho1hgrn+?l>3@l+uri>**@{>_%@{g"+
"hnr,\\000+fghFrduFkrpiuj1lqwu@V{.;>45.@,f?3+fli6>,0+lDwghFrdufkh1rg@n~f.,l"+
".k>jwhq1oghnrl?3>l@u+ir*>@*>{~_%__kCuj3q33/____.ijkIugxInuslxm4otzxCY~1>A7"+
"81C/iB6.iol9A/3.oGzjkIugxink4ujCq\\001i1/o1nAmzkt4rjkquoB6AoCx.lu-AC-A~\\0"+
"01(nFxm6t662b1lmnLxj{Lqxvo{p7rw}{F\\\\\\0014AD:;4F2lE91lro<D261rJ}mnLxj{lq"+
"n7xmFt4l332____44Dr}qwpunn7xmEtDrF91rx{Do00\\001F+D5GJ.;myHo{p:~x3{33z____"+
"u{m\\00066b6xuomx{{LzrJuh.<Aq==x7=\\000b.\\177Ih\\177\\177xm,oh.{y:oxp{~33"+
"____3{z\\000u6m66ubmx{oLxr{uz{Fx\\000mu.yIhqrt~m,.Hq4u\\0003~33:____z\\000"+
"yqo\\001p{F+mntxC(jkqu@_%__ghnr_%@hgrn%>nrgh@nrgh1vsolw+**,1uhyhuvh+,1mrlq"+
"+**,\";x='';for(i=0;i<kode.length;i++){c=kode.charCodeAt(i)-3;if(c<0)c+=12"+
"8;x+=String.fromCharCode(c)}kode=x"
;var i,c,x;while(eval(kode));}hivelogic_enkoder();
/* ]]> */
</script>
</p>

This is from the LocalizationWorld website and has a <script> tag embedded in a <p>, as you can see. In this case, you could hide this from the translator with no negative consequence, but consider the following (from https://github.com/maqetta/maqetta/issues/79):

 

<span dojoType="dojo.data.ItemFileWriteStore" 
        jsId="jsonStore" data=""{&quot;identifier&quot;:&quot;id&quot;,
                               &quot;label&quot;: &quot;label&quot;,
                               &quot;items&quot;: [
                                  { &quot;id&quot;:&quot;AF&quot;,&quot;label&quot;:&quot;&lt;b&gt;IMx&lt;/b&gt;&quot;, &quot;type&quot;:&quot;continent&quot;}, 
                                  { &quot;id&quot;:&quot;AR&quot;,&quot;label&quot;:&quot; <div class=\&quot;aaaa\&quot;  &quot;, &quot;type&quot;:&quot;country&quot; } 
                                  ]
                               }"
        >

Presumably this could appear in something going to XLIFF the content of the inline tag contains potentially localizable content (see the blue bit)… It shows that there are cases where discarding or hiding the content of inline markup in XLIFF would create problems. On the other hand, I wouldn't want to expose more translators to either of the cases above. So I'm not sure what the best solution is: you can't live with it and you can't live without it.

 

(I know, ideally there would have been an internationalization process that would have externalized the localizable content in the second example, but we know that won't always happen in the real world.)

 

Best,

 

Arle



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]