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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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 <azydron@xtm-intl.com>
Date: Wed, October 03, 2012 5:23 pm
To: xliff@lists.oasis-open.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: azydron@xtm-intl.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">&lt;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: xliff@lists.oasis-open.org
[xliff@lists.oasis-open.org] on behalf of Rodolfo M. Raya
[rmraya@maxprograms.com]Sent: Wednesday, October 03, 2012 3:53 AMTo: Dr.
David FilipCc: Yves Savourel; xliff@lists.oasis-open.orgSubject: 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 "&gt;" 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:
david.filip@ul.ie<mailto:david.filip@ul.ie>On Wed, Oct 3, 2012 at 4:27
AM, Yves Savourel <ysavourel@enlaso.com<mailto:ysavourel@enlaso.com>>
wrote:&lt;---------------------------------------------------------------------To
unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.orgFor
additional commands, e-mail: xliff-help@lists.oasis-open.org


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