XLIFF Inline Markup SC

Hi all, I will not be able to attend the SC teleconference on Jun-14 (traveling to LocWorld). But since you have that hour booked up for the SC, maybe you still can work on the topic :) I'll send the GoToMeeting code to Bryan, Christian and Andrew so someone can start the session. I'm not sure, but Christian may be still in vacation. Arle has join the SC (welcome back). Arle, FYI, the meeting info is: XLIFF Inline Markup Subcommittee Teleconference Every second Tuesday of every month at 14:00 UTC 7:00am PDT, 8:00am MDT, 10:00am EDT, 11:00 Montevideo, 3:00pm London, 4:00pm Berlin. Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929 To help you with the meeting, here is a summary of the discussions we are having: --- Storing the native data. It seems we have a basic consensus on three forms: a) no storage b) storage inside the element (not in attribute) c) an attribute pointing to a storage location within the unit. We still have to define how the external storage should be represented. Maybe someone can come up with a proposal? --- IDs We are still discussing the IDs. One question: Should the standalone starting code representation and the standalone ending code representation use the same ID (which then could be used to link them) or different ones (and then we need an extra attribute (e.g. rid) in the ending code to link with its corresponding opening)? In other words: <sc id='1'/>text<ec id='1'/> or <sc id='1'>text<ec id='2' rid='1'/>" Christian has an action item to research the ID mechanism in XML. A second question is: In the case of the representation that stores the native data outside the segment, should we re-use the same id to point to the element storing the data, or use a different one? Andrew noted that using a different one would promote the separation of concerns. --- Editing hints Currently we have those properties: - canDelete - canReplicate - canReorder - canMoveOutOfParent We can have one attribute for each, or a single attribute with some value that can be decomposed (e.g. using OR). What should be the default for each one? Should we have also some way to define a file-level default? --- Span/markers -type elements One possible solution would be a general container with different attributes for each information, so overlapping spans could be represented in nested spans. Christian had an action item to post an email about this possible different implementation. --- Summary I've started to try to summarize our directions here: http://wiki.oasis-open.org/xliff/OneContentModel/Draft Nothing stable obviously, but the idea is to adjust the document as we finalize the markup. Cheers, -ys

Hi Yves,

Wishes for safe travel to you. I will try today to rearrange my schedule in order to attend and perhaps start the session. As it stands, I have another call from 7 - 8 PDT. If I cannot reschedule (I will know by midday, PDT), I will hope that somebody else can start the session.

Thanks,

Bryan


Original Message-----
From: Yves Savourel [ mailto:ysavourel@translate.com ]
Sent: Saturday, June 11, 2011 2:58 AM
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Inline code SC Meeting - June-14

Hi all,

I will not be able to attend the SC teleconference on Jun-14 (traveling to LocWorld).

But since you have that hour booked up for the SC, maybe you still can work on the topic :)
I'll send the GoToMeeting code to Bryan, Christian and Andrew so someone can start the session.
I'm not sure, but Christian may be still in vacation.

Arle has join the SC (welcome back).
Arle, FYI, the meeting info is:

XLIFF Inline Markup Subcommittee Teleconference
Every second Tuesday of every month at 14:00 UTC
7:00am PDT, 8:00am MDT, 10:00am EDT, 11:00 Montevideo, 3:00pm London, 4:00pm Berlin.
Teleconference meeting place:
https://www1.gotomeeting.com/join/408998929
Meeting ID: 408-998-929
You can use the following US phone number, or the VOIP option provided by GoToMeeting:
Dial 630-869-1010
Access Code: 408-998-929


To help you with the meeting, here is a summary of the discussions we are having:

--- Storing the native data.

It seems we have a basic consensus on three forms:

a) no storage
b) storage inside the element (not in attribute)
c) an attribute pointing to a storage location within the unit.

We still have to define how the external storage should be represented.
Maybe someone can come up with a proposal?


--- IDs

We are still discussing the IDs.

One question: Should the standalone starting code representation and the standalone ending code representation use the same ID (which then could be used to link them) or different ones (and then we need an extra attribute (e.g. rid) in the ending code to link with its corresponding opening)? In other words:

<sc id='1'/>text<ec id='1'/> or <sc id='1'>text<ec id='2' rid='1'/>"

Christian has an action item to research the ID mechanism in XML.

A second question is: In the case of the representation that stores the native data outside the segment, should we re-use the same id to point to the element storing the data, or use a different one?
Andrew noted that using a different one would promote the separation of concerns.


--- Editing hints

Currently we have those properties:

- canDelete
- canReplicate
- canReorder
- canMoveOutOfParent

We can have one attribute for each, or a single attribute with some value that can be decomposed (e.g. using OR).
What should be the default for each one?
Should we have also some way to define a file-level default?


--- Span/markers -type elements

One possible solution would be a general container with different attributes for each information, so overlapping spans could be represented in nested spans.

Christian had an action item to post an email about this possible different implementation.


--- Summary

I've started to try to summarize our directions here:
http://wiki.oasis-open.org/xliff/OneContentModel/Draft

Nothing stable obviously, but the idea is to adjust the document as we finalize the markup.


Cheers,
-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On another my call today - cannot start session ________________________________________ From: Schnabel, Bryan S [bryan.s.schnabel@tektronix.com] Sent: Monday, June 13, 2011 9:53 AM To: Yves Savourel; xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] Inline code SC Meeting - June-14 Hi Yves, Wishes for safe travel to you. I will try today to rearrange my schedule in order to attend and perhaps start the session. As it stands, I have another call from 7 - 8 PDT. If I cannot reschedule (I will know by midday, PDT), I will hope that somebody else can start the session. Thanks, Bryan
Original Message----- From: Yves Savourel [ mailto:ysavourel@translate.com ] Sent: Saturday, June 11, 2011 2:58 AM To: xliff-inline@lists.oasis-open.org Subject: [xliff-inline] Inline code SC Meeting - June-14 Hi all, I will not be able to attend the SC teleconference on Jun-14 (traveling to LocWorld). But since you have that hour booked up for the SC, maybe you still can work on the topic :) I'll send the GoToMeeting code to Bryan, Christian and Andrew so someone can start the session. I'm not sure, but Christian may be still in vacation. Arle has join the SC (welcome back). Arle, FYI, the meeting info is: XLIFF Inline Markup Subcommittee Teleconference Every second Tuesday of every month at 14:00 UTC 7:00am PDT, 8:00am MDT, 10:00am EDT, 11:00 Montevideo, 3:00pm London, 4:00pm Berlin. Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929 To help you with the meeting, here is a summary of the discussions we are having: --- Storing the native data. It seems we have a basic consensus on three forms: a) no storage b) storage inside the element (not in attribute) c) an attribute pointing to a storage location within the unit. We still have to define how the external storage should be represented. Maybe someone can come up with a proposal? --- IDs We are still discussing the IDs. One question: Should the standalone starting code representation and the standalone ending code representation use the same ID (which then could be used to link them) or different ones (and then we need an extra attribute (e.g. rid) in the ending code to link with its corresponding opening)? In other words: <sc id='1'/>text<ec id='1'/> or <sc id='1'>text<ec id='2' rid='1'/>" Christian has an action item to research the ID mechanism in XML. A second question is: In the case of the representation that stores the native data outside the segment, should we re-use the same id to point to the element storing the data, or use a different one? Andrew noted that using a different one would promote the separation of concerns. --- Editing hints Currently we have those properties: - canDelete - canReplicate - canReorder - canMoveOutOfParent We can have one attribute for each, or a single attribute with some value that can be decomposed (e.g. using OR). What should be the default for each one? Should we have also some way to define a file-level default? --- Span/markers -type elements One possible solution would be a general container with different attributes for each information, so overlapping spans could be represented in nested spans. Christian had an action item to post an email about this possible different implementation. --- Summary I've started to try to summarize our directions here: http://wiki.oasis-open.org/xliff/OneContentModel/Draft Nothing stable obviously, but the idea is to adjust the document as we finalize the markup. Cheers, -ys --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi all, In order to free Andrew up to run the meeting, I took on the role of secretary for today ??s meeting. My minutes are included below: [0] Attendance Christian Lieske (SAP) David Walters (IBM) Andrew Swift (SDL) Arle Lommel (GALA) We did not review or approve previous meeting minutes. [1] Run-through of wiki content [1.1] Storage options Andrew: We were discussing of how to store content of native markup. We have three options: (a) no storage; (b) storing it in the element; (c) pointing to an external reference. We want to make translation units independent so any external reference would have to be within the trans-unit rather than in the document skeleton or elsewhere in the file. Including the native content in the element is nice for editing, but if it is complex, it can get in the way. Arle: If TM interoperability is a goal, we need to support at least (a) and (b), since both of these are used. Andrew: There is also the issue of editing, where having access to the code is useful. [1.2] Editing hints Andrew: Editing hints. Should these be included in the specification. We identified four types: can the code be removed, replicated, moved in order, moved outside of a hierarchy location. Arle: There is a risk for this in complex formats. Andrew: It can't be decided independently of the file format. So do we have a way to pass this along with the file. Arle: I think it makes sense to have a way to indicate this with the caveat that there are risks. We'd need to have a way to specify this on a per-format basis somewhere else. Andrew: I'd see this as a bonus feature, not something required for a basic implementation. This is something that is extra that we have to do at this point, so the editing experience could be improved. Arle: Would it be a global declaration or on each tag, or both? Andrew: I don't know. Arle: Some times it would be nice to have a global statement, like saying you can remove <i> tags in HTML when going into Japanese Christian: I think an ITS-like mechanism would be good (it allows global and local rules). We also need to address when tags can be modified or added. Andrew: That is an interesting issue: where do we allow adding tags. Can we specify file-type-specific metadata about the allowable tags. Arle: If you allow adding, it bring in all sorts of logistical problems since different users could do different sorts of things David: If we start having specific rules for formats and include format-unique functionality, does it take us too far from the base function of XLIFF? Andrew: We want to remain agnostic, but we need to allow for extra things for editing. Arle: This is a fundamental tension. If you want to enable editing features, you have to be somewhat specific, and can't be generic. Andrew: And if you get something so generic that it can handle all file types, it won't be useful in real life. [1.3] Display values Andrew: Do we need display values to hide the ugliness of native codes? Should we have a shortcut that explains what the content is? What about linguistic equivalents (e.g., letting people know that &copy; = ©)? Arle: I think these equivalents are needed. For example you could get &#x0151; which is useless to a translator, who would need to know that it is actually Å? (o double acute). We need to consider the ergonomic requirements of users. [1.4] IDs Andrew: Issue of mapping tags using same ID or separate IDs. Christian: I've not had time to research the xml:id item. Arle: I think we might have to have some sort of ID that is global to allow for pairing across trans-unit boundaries David: the example of ??<sc id='1'>text<ec id='2' rid='1' /> ? should be ??<sc id='1' />text<ec id='2' rid='1' /> ? [1.5] Common attributes Andrew: Is there value in representing tags at a generic level so you know the purpose of the tags? David: It would be useful. But the problem right now is that there is a finite list that gets augmented all the time. Arle: We might want to look at a registry-type mechanism (external to the specification) for these things. i.e., if someone encounters something new they can submit them to be added to the list. David: That seems like a good way to handle it. [1.6] ??Nasty inline ? codes David: I posted some examples of codes with several hundred characters, whitespace, etc. Arle: Javascript in HTML tags is a common example that can get really bad. Christian: Those people should be disciplined ;-) Andrew: I've seen forty-line comments in HTML in some cases. There is some activity on the list to consult about this. [2] Other items Arle: Do we have any timelines for our work? Andrew: Not that I know of. We report back in the main committee as we go. We've hit some issues where we depend on decisions in the main committee, e.g., we don't know where segmentation is handled: is it part of the main format or do we have a <mrk type= seg />-type tag that we need to deal with. We need better coordination. But no on the timelines. Andrew: Things are moving along but we need stakes in the ground to work around. Christian: Will Arle be regularly participating? Arle: Yes. <end of meeting>

Thank you Andrew and Arle for stepping up. And thanks to the attendees for moving things forward.   - Bryan   From: Arle Lommel [mailto:alommel@gala-global.org] Sent: Tuesday, June 14, 2011 7:59 AM To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] Inline code SC Meeting - June-14   Hi all,   In order to free Andrew up to run the meeting, I took on the role of secretary for today ??s meeting. My minutes are included below:   [0] Attendance ·          Christian Lieske (SAP) ·          David Walters (IBM) ·          Andrew Swift (SDL) ·          Arle Lommel (GALA) We did not review or approve previous meeting minutes. [1] Run-through of wiki content [1.1] Storage options ·          Andrew: We were discussing of how to store content of native markup. We have three options: (a) no storage; (b) storing it in the element; (c) pointing to an external reference. We want to make translation units independent so any external reference would have to be within the trans-unit rather than in the document skeleton or elsewhere in the file. Including the native content in the element is nice for editing, but if it is complex, it can get in the way. ·          Arle: If TM interoperability is a goal, we need to support at least (a) and (b), since both of these are used. ·          Andrew: There is also the issue of editing, where having access to the code is useful. [1.2] Editing hints ·          Andrew: Editing hints. Should these be included in the specification. We identified four types: can the code be removed, replicated, moved in order, moved outside of a hierarchy location. ·          Arle: There is a risk for this in complex formats. ·          Andrew: It can't be decided independently of the file format. So do we have a way to pass this along with the file. ·          Arle: I think it makes sense to have a way to indicate this with the caveat that there are risks. We'd need to have a way to specify this on a per-format basis somewhere else. ·          Andrew: I'd see this as a bonus feature, not something required for a basic implementation. This is something that is extra that we have to do at this point, so the editing experience could be improved. ·          Arle: Would it be a global declaration or on each tag, or both? ·          Andrew: I don't know. ·          Arle: Some times it would be nice to have a global statement, like saying you can remove <i> tags in HTML when going into Japanese ·          Christian: I think an ITS-like mechanism would be good (it allows global and local rules). We also need to address when tags can be modified or added. ·          Andrew: That is an interesting issue: where do we allow adding tags. Can we specify file-type-specific metadata about the allowable tags. ·          Arle: If you allow adding, it bring in all sorts of logistical problems since different users could do different sorts of things ·          David: If we start having specific rules for formats and include format-unique functionality, does it take us too far from the base function of XLIFF? ·          Andrew: We want to remain agnostic, but we need to allow for extra things for editing. ·          Arle: This is a fundamental tension. If you want to enable editing features, you have to be somewhat specific, and can't be generic. ·          Andrew: And if you get something so generic that it can handle all file types, it won't be useful in real life. [1.3] Display values ·          Andrew: Do we need display values to hide the ugliness of native codes? Should we have a shortcut that explains what the content is? What about linguistic equivalents (e.g., letting people know that &copy; = ©)? ·          Arle: I think these equivalents are needed. For example you could get &#x0151; which is useless to a translator, who would need to know that it is actually Å? (o double acute). We need to consider the ergonomic requirements of users. [1.4] IDs ·          Andrew: Issue of mapping tags using same ID or separate IDs. ·          Christian: I've not had time to research the xml:id item. ·          Arle: I think we might have to have some sort of ID that is global to allow for pairing across trans-unit boundaries ·          David: the example of ??<sc id='1'>text<ec id='2' rid='1' /> ? should be ??<sc id='1' />text<ec id='2' rid='1' /> ? [1.5] Common attributes ·          Andrew: Is there value in representing tags at a generic level so you know the purpose of the tags? ·          David: It would be useful. But the problem right now is that there is a finite list that gets augmented all the time. ·          Arle: We might want to look at a registry-type mechanism (external to the specification) for these things. i.e., if someone encounters something new they can submit them to be added to the list. ·          David: That seems like a good way to handle it. [1.6] ??Nasty inline ? codes ·          David: I posted some examples of codes with several hundred characters, whitespace, etc. ·          Arle: Javascript in HTML tags is a common example that can get really bad. ·          Christian: Those people should be disciplined ;-) ·          Andrew: I've seen forty-line comments in HTML in some cases. There is some activity on the list to consult about this. [2] Other items ·          Arle: Do we have any timelines for our work? ·          Andrew: Not that I know of. We report back in the main committee as we go. We've hit some issues where we depend on decisions in the main committee, e.g., we don't know where segmentation is handled: is it part of the main format or do we have a <mrk type="seg" />-type tag that we need to deal with. We need better coordination. But no on the timelines. ·          Andrew: Things are moving along but we need stakes in the ground to work around. ·          Christian: Will Arle be regularly participating? ·          Arle: Yes.   <end of meeting>

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

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

Hi Brian, You are correct that my examples don't solve the issue. I brought them up as problems, not solutions. (Maybe I'm the kind of person you come to hate: the one who says ?but what about this?? and never gives a solution.) I see a few issues with your response: If we don't push these things to the skeleton, but instead want to handle them as inline elements in the trans-unit (one of the three options we discussed), then we can't use your solution. This may be an argument for using the skeleton solution over the other options. To expose just the translatable part requires knowledge of what should be touched. Imagine that in my first example there was translatable content in there, how would we even identify it since this function is written in some proprietary hivelogic format? (I presume this function was written this way specifically to make it unintelligible.) Similarly, in the second case, automatically identifying what should be translated could be a real problem. So we are still left with the need for an elegant way to allow access when needed and hide it when not. I don't know if there is a generalizable solution to this problem. Good import filters would help, but who would write an HTML filter (for example) that can identify the hivelogic garbage and parse it? So there will always be a need for access to this kind of crap in an editor environment :-( This is the kind of thing that makes translators want to quit and take up something easy like rocket surgery? There are a lot of issues here, but these examples show why simple solutions sometimes don't work. Best, Arle On Jun 14, 2011, at 16:18 , Schnabel, Bryan S wrote: 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= x-msg://123/{&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

Hi Arle,   I didn't mean to say your examples did not solve the issue. I meant to say that I did not think your examples were not complex enough to require an elegant solution (i.e., I was side-stepping the real issue). My interpretation was that it was just a matter of asking, "does a translator need all the junk adjacent to the translatable strings for (a) context? Or (b) in order to adjust the junk based on the unique needs of the target language"? If 'yes', we then need to add the junk into the trans-unit; if 'no', we just stick it in the skeleton.   I assumed your examples led us the 'no' conclusion. But I now see that you meant them to lead us to the 'yes' conclusion (based on the scenario your two bullet points paint). This was not a problem with your examples - it was my misinterpretation of them.   To me the very interesting take-away from this thread is a philosophical one. I'll try to explain (but I'll probably not communicate this very well).   It sounds to me like you are saying it is the responsibility of the XLIFF spec to solve the problem of: *difficult-to-identify-translatable-vs-non-translatable-strings-within-dense-blobs*   My view is that it is the responsibility of the filter/tool maker to do the difficult job of identifying translatable vs. non translatable text. Therefore it is responsibility of the XLIFF spec to provide translators with (1) a clear place to translate translatable strings; (2) enough context to translate the strings accurately, and (3) ability to make adjustments to non-translatable content in cases where the target language causes a need for such adjustment.   (1) and (2) seem not too difficult (although not super easy by any means). And (3) seems to be the tricky bit that I confessed to be side-stepping.   Sorry that I muddied it up by misreading your examples.   (and for the record, I love the kind of person that looks deeply at problems - finding problems is the first half of finding solutions)   - Bryan   From: Arle Lommel [mailto:alommel@gala-global.org] Sent: Tuesday, June 14, 2011 2:02 PM To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] Complex tag content   Hi Brian,   You are correct that my examples don't solve the issue. I brought them up as problems, not solutions. (Maybe I'm the kind of person you come to hate: the one who says “but what about this…” and never gives a solution.)   I see a few issues with your response:   ·          If we don't push these things to the skeleton, but instead want to handle them as inline elements in the trans-unit (one of the three options we discussed), then we can't use your solution. This may be an argument for using the skeleton solution over the other options. ·          To expose just the translatable part requires knowledge of what should be touched. Imagine that in my first example there was translatable content in there, how would we even identify it since this function is written in some proprietary hivelogic format? (I presume this function was written this way specifically to make it unintelligible.) Similarly, in the second case, automatically identifying what should be translated could be a real problem.   So we are still left with the need for an elegant way to allow access when needed and hide it when not. I don't know if there is a generalizable solution to this problem. Good import filters would help, but who would write an HTML filter (for example) that can identify the hivelogic garbage and parse it? So there will always be a need for access to this kind of crap in an editor environment :-( This is the kind of thing that makes translators want to quit and take up something easy like rocket surgery…   There are a lot of issues here, but these examples show why simple solutions sometimes don't work.   Best,   Arle   On Jun 14, 2011, at 16:18 , Schnabel, Bryan S wrote: 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  

Hi Brian, Don't you love email discussions where we can misread each other? I don't know if you misread me: sometimes misreading is a valuable thing anyway :-) I don't know if I'm saying XLIFF should solve it. I rather think that this is a potentially difficult problem in general and that even if the filters solve it, they won't get a perfect solution. But this was in response to the issue of where the best place to store markup is. There were three options. Overall I would prefer to store the markup in the trans-unit because that simplifies many downstream uses. If the tag content is stored inline (rather than in a skeleton) it would make it easier to access the tag content when needed, but these examples showed both (a) why it is difficult (you get these gloppy messes of inline markup that you have to figure out how to display/hide) and (b) why the translator might need to get access to those gloppy messes even when the filter makes it seem that you don't need to pay attention to them. I would, of course, argue that identifying what to show or hide should be the filters' job, but the second example shows why leaving it exclusively to the filter can be a problem as well. I doubt any HTML filter would figure what to do with that spaghetti and get it right, so the assumption would be that it was non-translatable and only manual examination would show that it is (so your point 3 is very applicable since it actually would need to be addressed even though the default assumption would have been that it was not translatable). By the way, I'm impressed that you figured out that example 2 was malformed: I just thought it was ugly and unintelligible, but you confirmed it was a trifecta! Best, Arle On Jun 14, 2011, at 17:47 , Schnabel, Bryan S wrote: Hi Arle,   I didn't mean to say your examples did not solve the issue. I meant to say that I did not think your examples were not complex enough to require an elegant solution (i.e., I was side-stepping the real issue). My interpretation was that it was just a matter of asking, does a translator need all the junk adjacent to the translatable strings for (a) context? Or (b) in order to adjust the junk based on the unique needs of the target language ? If 'yes', we then need to add the junk into the trans-unit; if 'no', we just stick it in the skeleton.   I assumed your examples led us the 'no' conclusion. But I now see that you meant them to lead us to the 'yes' conclusion (based on the scenario your two bullet points paint). This was not a problem with your examples - it was my misinterpretation of them.   To me the very interesting take-away from this thread is a philosophical one. I'll try to explain (but I'll probably not communicate this very well).   It sounds to me like you are saying it is the responsibility of the XLIFF spec to solve the problem of: *difficult-to-identify-translatable-vs-non-translatable-strings-within-dense-blobs*   My view is that it is the responsibility of the filter/tool maker to do the difficult job of identifying translatable vs. non translatable text. Therefore it is responsibility of the XLIFF spec to provide translators with (1) a clear place to translate translatable strings; (2) enough context to translate the strings accurately, and (3) ability to make adjustments to non-translatable content in cases where the target language causes a need for such adjustment.   (1) and (2) seem not too difficult (although not super easy by any means). And (3) seems to be the tricky bit that I confessed to be side-stepping.   Sorry that I muddied it up by misreading your examples.   (and for the record, I love the kind of person that looks deeply at problems - finding problems is the first half of finding solutions)   - Bryan  

Hi Arle, Bryan, all, Interesting samples :) > <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; onclick= > &quot;clicktest();&quot;><div> &quot;, &quot;type&quot;:&quot; > country&quot; } > ] > }"> That one is a JSON text stored in the data attribute of a <span> element. And some of the JSON values that are translatable contain HTML codes. A set of cascading sub-filters can parse this: The main filter is the HTML Filter, and it switches to a JSON filter for the content of 'data', and the JSON filter switches to HTML filter for the content of the translatable values. Tools like Rainbow or memoQ and I'm sure others have such capability to call cascading filters. This is a good example of a case where the translatable text is a set of separate text units nested inside another one. In this instance the XLIFF challenge is more an issue of how to represent and reference sub-flows. > (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.) Yes, but at some point people need to get real in the real world. Assuming filters and formats should somehow put up with unlimited amount of badly coded or badly internationalized material is not helping anyone on the long term. There is a threshold where junk has to be acknowledged as such. I'm just not sure where is that threshold. Cheers, -yves

Hi all, Is there an XLIFF Inline SC meeting today? I tried to join, but nobody was there, as far as I could tell (I got a message about waiting for a moderator to join). -Arle

Apologies. I'd forgotten Yves was on holiday. I am not able to dial in at the appointed time. But it would have been nice if I'd sent a "no meeting today" notice. - Bryan ________________________________________ From: Arle Lommel [alommel@gala-global.org] Sent: Tuesday, July 12, 2011 7:03 AM To: xliff-inline@lists.oasis-open.org Subject: [xliff-inline] Meeting today? Hi all, Is there an XLIFF Inline SC meeting today? I tried to join, but nobody was there, as far as I could tell (I got a message about waiting for a moderator to join). -Arle --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Arle, all, > Is there an XLIFF Inline SC meeting today? > I tried to join, but nobody was there, as far > as I could tell (I got a message about waiting > for a moderator to join). That was entirely my fault. Sorry. I was in vacation last week. I had sent the logging info to a few regular attendees so someone could start the meeting if needed, but I completely forgot to notify the mailing list. Cheers, -yves