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][follow-up] FW: Degrees of constraint


I disagree. I liked Yves' idea of a sprinkled lean metadata element that would point to a full item to use the terminology example. Given the fact that this would be a registered namespace, parsing it should be ok.

<Gérard/> 

-----Original Message-----
From: David Pooley [mailto:dpooley@sdl.com] 
Sent: Wednesday, July 28, 2004 8:02 AM
To: 'xliff@lists.oasis-open.org'
Subject: RE: [xliff][follow-up] FW: Degrees of constraint

I agree also. I'm coming from the perspective of trying to create a
"generic" XLIFF editing environment. I'm going to have to make some
assumptions about the text in the <source> and <target> elements and I think
that assuming everything is translatable is a good start.

David Pooley
Software Architect
SDL International


-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com] 
Sent: Wednesday, July 28, 2004 3:50 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff][follow-up] FW: Degrees of constraint


I agree. All text nodes within <source> should be translated. Any text that
should not be translated should be in the skeleton file or other
<internal-file> in the header, as per Christian's suggestion.

-Doug



-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Wednesday, July 28, 2004 10:33 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff][follow-up] FW: Degrees of constraint


> ...For segmentation purposes, shouldn't "noun"
> and "Group of Islands" be in different <trans-unit>
> elements?

They actually should not be at all in any <trans-unit> I think--at least not
as content--since they are not part of the extracted text.

That's why I would be concern if extensions elements in <source> and
<target> were to introduce additional "structure" (I'm still not sure if
it's the right word). Having chunks of content not belonging to the actual
text of the <source> or <target> would seem to lead to much more work for
handling the text itself.

Christian's example of <olf:term> illustrates the way that would probably be
preferable when one needs to associate a lot of data with a specific part of
the <source>/<target> text.

Maybe there are scenarios where "embedded" content is the only way... I'm
trying to think of any, but come empty so far.

-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.



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.

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.php.



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