[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Best way to mark up an image in XLIFF 2.0?
Andrzej, There were 10 inline elements in XLIFF 1.2 and there are also 10 inline related elements in version 2.0. The old <x/> was replaced with <ph/>; <bx/> is now <sc/> and <ex/> became <ec/>. The old <g> is now called <pc>. The lonely <mrk> has two new friends: <sm/> and <em/>. Untranslatable data stored in <ph>, <bpt> and <ept> has moved to <originalData> and <data> or can be stored in the skeleton. A new element <cp/> was added to represent invalid XML chars and the ugly <sub> is gone. The seldom used <it> is missing in action. In the old XLIFF 1.x era we had 10 inline elements available. You used only <g> and <x/> while I only used <ph>. You will be able to work with <ph/> and <pc> in the future 2.x age. Except for the element names, nothing has changed for you regarding inline markup when generating XLIFF 2.0. Reading and processing third party XLIFF 2.0 will be a different story. Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com -------- Original Message -------- Subject: Re: [xliff] Best way to mark up an image in XLIFF 2.0? From: Andrzej Zydron <email@example.com> Date: Wed, October 03, 2012 5:23 pm To: firstname.lastname@example.org Hi Everyone, Apologies, I have been too busy to participate in XLIFF discussions but some things are too important not to comment. I appraciate the work of the committee but I concur with Rodolfo and Bryan. Many of the current proposals worry me: you cannot map different ontological entities onto the same representation. Any inline notation that includes in PCDATA any form of data that is not to be translated is at best misguided. My rule on this is very simple: 1. All file formats can be rendered as XML. 2. Within XML text there are only two types of inline elements: those that have content and those that do not have content 3. Inline elements can further be divided into those that are truly inline and those that are sub-flows In other words <g> </g> and <x/> are all that is required for inline content. I have been doing this for 10 years - it works and I have never ever found any limitations to this rule. The other things that worry me about some of the directions that XLIFF 2.0 is taking is trying to load workflow and state data onto XLIFF. I would counsel that ANY type of information that is not directly linked to the interchange of translatable data should be held outside of XLIFF. Best Regards, Andrzej Zydroń --------------------------------------- CTO XTM International Ltd. PO Box 2167, Gerrards Cross, SL9 8XF, UK email: email@example.com Tel: +44 (0) 1753 480 479 Mob: +44 (0) 7966 477 181 skype: Zydron www.xtm-intl.com On 03/10/2012 14:53, Schnabel, Bryan S wrote: The problem you face is that current inline elementsare not XSL friendly and interfere with the goal you have.I think the fact that the solution is not XSL friendly is just a side effect of the fact that the solution requires an XML hack. Sorry if this is worded too strongly. But if we use an XML vocabulary for our Localization Interchange File Format; and if our use case has XML source as its source; and if we say the way we recommend you store your source XML is to escape it; then it seems to me that we are prescribing an XML "no no" as a best practice.I don't blame people for rolling their eyes and saying "here he goes again." I guess if I'm the only one who finds this distasteful, I must be in the minority. And maybe I should just stop complaining. I guess the real test is to see if members of our community care one way or the other. I kind of feel like I'm representing people who see a need (for example) to include XLIFF in things like the DITA OT. XML friendliness is needed in cases like that.That said, I could certainly hold my nose and make the <data id="222"><img src="big-happy-smile.jpg"></data> approach work in XSL. And I could adapt my DITA-XLIFF Roundtrip for the DITA OT (for example) work okay. So luckily for me, it is just a philosophical gripe.Thanks for putting up with my semi-annual XML friendliness rants.________________________________From: firstname.lastname@example.org [email@example.com] on behalf of Rodolfo M. Raya [firstname.lastname@example.org]Sent: Wednesday, October 03, 2012 3:53 AMTo: Dr. David FilipCc: Yves Savourel; email@example.comSubject: Re: [xliff] Best way to mark up an image in XLIFF 2.0?">" doesn't need to be escaped in XML.Regards,RodolfoSent from my iPadOn Oct 3, 2012, at 7:48 AM, "Dr. David Filip" <David.Filip@ul.ie<mailto:David.Filip@ul.ie>> wrote:">" should be ">" in your data example:-)Dr. David Filip=======================LRC | CNGL | LT-Web | CSISUniversity of Limerick, Irelandtelephone: +353-6120-2781cellphone: +353-86-0222-158facsimile: +353-6120-2734mailto: firstname.lastname@example.org<mailto:email@example.com>On Wed, Oct 3, 2012 at 4:27 AM, Yves Savourel <firstname.lastname@example.org<mailto:email@example.com>> wrote:<---------------------------------------------------------------------To unsubscribe, e-mail: firstname.lastname@example.orgFor additional commands, e-mail: email@example.com