MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xliff][follow-up] FW: Degrees of constraint
All,
I like Yves' idea because it is simple and well-defined, but my
understanding is that text within <mrk> tags is NOT translated (*). With
most inline tags (e.g., <html:b>), the text should be translated.
Would treating tags from another namespace as an <xlf:g> tag allow the text
to be translated?
Do any of the tool vendors have a screen shot of how the inline placeholders
are rendered within their tool? Unfortunately, I'm not familiar with them.
I'm a user of translation services, not a provider.
(*) The spec for <mrk> reads, "...an item that should not be modified". Ref
http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031
031.htm#mrk.
Regards,
Doug Domeny
Software Analyst
Ektron, Inc.
+1 603 594-0249 x212
http://www.ektron.com
-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Tuesday, July 27, 2004 4:52 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff][follow-up] FW: Degrees of constraint
Hi all,
The idea of the <Extend> element is certainly a smart workaround.
However, I'm starting to get worried about the amount of complexity this is
going to entails, and the large tree structure we going to end-up with.
Maybe (I'm just thinking aloud here), we could do with a simpler approach
with a little bit less flexibility, but still have enough to work with.
Imagine we define rules the two following rules as for what type of elements
can be used in extension:
1- The content of any extension elements inside a <source> or a <target>
must be part of the content of <source> or <target>. In other words, we
don't allow extension element that have a content not belonging to the
original text (like embedded comments). The only elements allowed are the
one that can "bracket" existing content (like <htm:b>). This way tools can
just treat them like <mrk> elements.
2- Extension elements that are empty are just treated like <mrk/>.
Another way to express this is to say that if you strip out the tags inside
a <source> or a <target> you should get the plain text content of the
<source> or <target>, nothing more, nothing less.
This way there is no need for special attributes to put in the extension
elements to tell the tool how to deal with them: you just treat them like
<mrk> elements a little bit special.
I don't think there a way to enforce such rules through a formal validation
using a schema. But maybe it's OK to not have a way to validate this, as it
seems logical (at least to me) to have only extension markup that add layers
of information on top of the existing text. Information not part of the text
can always be inserted using attributes in the extension elements.
By allowing extension in <source> and <target> we don't have the intend of
allowing to create new structures inside <source> and <target>, do we?
But maybe I'm trying to get away with something too simple and not formal
enough...
Cheers,
-yves
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.p
hp.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]