[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] SubFlows and inline codes
As per the TC call this morning, I am verifying that this thread resolved my question. Thanks, Ryan -----Original Message----- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, January 27, 2015 12:00 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] SubFlows and inline codes Thanks Yves for the reply. Our OM also maps all attributes in the inline codes, so we could serialize to JSON and preserve everything as well. The problem comes when we encounter what you described in your second paragraph: having to convert XLIFF to a translation package. In our case, our "package" is a cloud-based storage with a web editor. In any case, that seems to be a common challenge. Thanks for the TM detail as well. Ryan -----Original Message----- From: Yves Savourel [mailto:ysavourel@enlaso.com] Sent: Tuesday, January 27, 2015 11:48 AM To: Ryan King Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] SubFlows and inline codes Hi Ryan, I'm not sure if what we do can help much, but here it goes: Basically our OM maps all attributes in the inline codes, so it has access to everything. Round trips to JSON, etc. retain all that. As for other types of roundtrips--for example we have components that reads XLIFF2 and produce various translation package from that, including XLIFF1.2--we do it like you described: Store the original inline code and, if needed, spit it back. But this is obviously not ideal. On a side note: Nowadays many TM tools don't even bother to store the original codes, they just store the ids+types and use that to map the leveraged codes into the document. The only time you would/could need the original codes in the TM is for translations that have extra codes compared to the source. Not sure that helped... Cheers, -yves -----Original Message----- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, January 27, 2015 11:01 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] SubFlows and inline codes Hi, Yves, I'm curious about something. Our OM has a method that will take some text and if it finds an original code, it automatically encodes it for you using the appropriate inline tag and <originalData>. We also can decode the string so that it can be stored in our TM without XLIFF native tags. However, this round-tripping causes us to lose any attributes on the inline tags, such as canCopy or canRemove for example. The only solution to roundtrip the data seems to be to store this data as part of the TM or treat the XLIFF as a sort-of skeleton for the TM data. I'm wondering if you have this problem and if you have any solutions for it. Thanks, Ryan -----Original Message----- From: Ryan King Sent: Monday, January 26, 2015 3:06 PM To: 'Yves Savourel'; xliff@lists.oasis-open.org Subject: RE: [xliff] SubFlows and inline codes Thanks for the reply Yves. Your solution below is exactly the one we were thinking of using. Good to know there is no prescribed way (or convention) to do this that we'll violate. Thanks, Ryan -----Original Message----- From: Yves Savourel [mailto:ysavourel@enlaso.com] Sent: Monday, January 26, 2015 3:02 PM To: Ryan King; xliff@lists.oasis-open.org Subject: RE: [xliff] SubFlows and inline codes Hi Ryan, Here is my take: 1) Yes and no. Yes, the <img> element is stored as original data, but an XLIFF file does not necessarily has to provide original data element: They can be stored outside of the file or even simply re-generated when merging (based on the original file). There are quite a few other examples without <data>. In this case, I agree it may help to have the <originalData> present for people to understand better. 2) If I recall correctly, there is no prescribed order for the sub-flow units. And there is no prescribed mechanism to match a sub-flow unit with its corresponding part in the <data>. That is tool-specific. Some may use the text, some may replace the text by some markers, etc. Personally I would replace the extract sub-flow text in the <img> by some marker with the ID of the unit where the text has been extracted. Something like: <data id="1"><img title="[#@$=1]" src="btnStart.png" alt="[#@$=2]"/><data> But that is completely arbitrary. I hope this helps, -yves From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Monday, January 26, 2015 3:03 PM To: 'xliff@lists.oasis-open.org' Subject: [xliff] SubFlows and inline codes Hi TC folks, We've been working on an XLIFF 2.0 object model and came across some questions about subFlows and inline codes. It seems to me that the example for subFlows in the 2.0 spec is incomplete, specifically this example in section 4.7.4 Sub-Flow: Click to start: <img title="Start button" src="btnStart.png" alt="Click here to start!"/> <unit id="1"> <segment> <source>Start button</source> </segment> </unit> <unit id="2"> <segment> <source>Click here to start!</source> </segment> </unit> <unit id="3"> <segment> <source>Click to start: <ph id="1" subFlows="1 2"/></source> </segment> </unit> Where is <img> meant to be encoded in this example? It seems the more complete example should be: <unit id="1"> <segment> <source>Start button</source> </segment> </unit> <unit id="2"> <segment> <source>Click here to start!</source> </segment> </unit> <unit id="3"> <originalData> <data id="1"><img title="Start button" src="btnStart.png" alt="Click here to start!"/><data> </originalData> <segment> <source>Click to start: <ph id="1" dataRef="1"/><ph id="2" subFlows="1 2"/></source> </segment> </unit> Can TC folks verify that this is the correct implementation? Additionally, we have some questions around merge. I assume that there is implicit ordering based in the order of the @subFlow values and the unit id. Meaning, I know u=u1 should come before u=u2. However, how do I know that u=u1 refers to @title and u=u2 refers to @alt, and not @title and @src, or @src and @alt, when there is no id/ref mechanism for the original data attributes? Thanks, Ryan --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]