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] Revised Committee Draft XLIFF 1.2 Spec


Dear Tony, all,
 
Thanks for the extensive reply.
 
My main concern was not the detail related to segmentation support. I was more the general feeling that we might have a challenge to ensure that XLIFF implementations clearly indicate what they do support and what they don't support.
 
Best regards,
Christian


From: Tony Jewtushenko [mailto:tony.jewtushenko@productinnovator.com]
Sent: Freitag, 12. Mai 2006 19:14
To: Lieske, Christian
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Revised Committee Draft XLIFF 1.2 Spec

 
Hi Christian:
 
That’s a good observation, but the intent of the segmentation support was not to necessarily to provide support for normalizing all segmentation operations or markup for localizable content.  That would be a very much out of scope for XLIFF given the complexity of the task.  Although I haven’t researched this extensively, in the segmentation SC we discussed issues related to this topic and concluded that additional segmentation metadata could be preserved extending by XLIFF with SRX.  However, no additional work was done by the SC to illustrate precisely how this could be accomplished, and I suggest that this would again be out of scope for a normative specification.  Perhaps we may publish an additional non-normative on segmentation process and markup at some point the future, but that’s out of scope for our present TC objective.
 
As the segmentation support is purely optional, no data loss would result from ignoring the segmentation markup and working strictly with source / target structures.  So I propose that the spec be modified with some of the language from Magnus, and add a suggestion that SRX may provide additional markup for preserving segmentation rules.
 
I would appreciate any feedback you have on this matter especially if you have a suggested alternative solution.
 
Regards,
Tony
 
 
-----Original Message-----
From: Lieske, Christian [mailto:christian.lieske@sap.com]
Sent: 11 May 2006 02:29
To: XLIFF TC
Subject: RE: [xliff] Revised Committee Draft XLIFF 1.2 Spec
 
Dear all,
 
I wonder about the repurcussions of phrases like "tool makers can include the spaces in the markup". How will tool users be able to know what a specific tool maker really supports in his XLIFF implementation?
 
Best regards,
Christian
 

From: Rodolfo M. Raya [mailto:rmraya@heartsome.net]
Sent: Mittwoch, 10. Mai 2006 19:20
To: Magnus Martikainen
Cc: XLIFF TC
Subject: RE: [xliff] Revised Committee Draft XLIFF 1.2 Spec
On Wed, 2006-05-10 at 02:17 -0700, Magnus Martikainen wrote:
Hi all,

Regarding point 5) below I would like to clarify that the segmentation markup is entirely optional and does not affect the functionality of the files as XLIFF files. The filter will ignore the segment boundaries when back-converting to the native format, and thus the entire content of the <target> element will be used, including content appearing outside of segments.

The segmentation markup is intended for tools such as translation memories to optimize recycling of previously translated content, and as such it often makes more sense to not include spaces between sentences in the segments (though that is entirely up to the tools). This does not in any way prevent users from editing the content between the segments, removing spaces or adding additional ones as needed. In fact it is fully allowed (and may frequently happen) that only part of the translated content in the <target> element is part of segments. 

The example in point 5) attempts to explicitly show this by not including the space characters in the segments (which normally gives better re-use when applying a TM). Perhaps we need to clarify the text in the specification to make that more explicit?

Hi Magnus,

Thanks for the explanation.

I would be happy if the text below the example is enhanced with a sentences stating that tool makers can include the spaces in the markup if desired.
Best regards,
Rodolfo
--
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.
 


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