Re: [xliff-comment] Determining what <note> elements refer to

[john corrigan <John.Corrigan@Sun.COM>]

Hi John,

Thanks for the good wishes, and apologies for being so quiet. I hope everyone is well.

Some context for my comments: I am currently working on a Editor application, that processes the output XLIFF documents produced by our workflow. I am trying to satisfy some user requirements for handling comments. For message files we extract any comments associated with a message and insert them into a <note>. These comments rightfully belong with the source. However, during the course of localization, translators and reviewers can add <note>s to <trans-unit>s, and as they refer mainly to the
translation, they rightfully belong with the target.

I have user requirements to treat these two classes of comments differently, e.g., display source comments when the source is selected, etc. There is talk, in the future, that the <note> elements associated with the <source> be written into the back converted original file format as a comment.

As I mentioned, I can do this by applying some convention to the 'from' attribute. However, a separate attribute seemed a cleaner approach to me, so I thought i would suggest it to see what people thought.

I'll leave discussion of skeleton files till another day. (-:

Regards,


John C.



John Reid wrote:
> 
> Hi John,
> 
> It's good to hear from you, again.
> 
> You wrote: "... However in <trans-unit> elements, the only way to
> determine whether a <note> refers to the <source> or the <target> is to
> rely on some convention for the 'from' attribute. ..."
> 
> Please, can you elaborate on how you see this being utilized? The 1.1
> spec says, "All child elements of <trans-unit> pertain to their sibling
> <source> element" Thus, a strict reading of this says any <note> in a
> <trans-unit> pertains to the <source>. Unless there is consideration to
> programmatically differentiate between notes relating to the <source> or
> <target>, exclusive of the other, there seems to be little advantage of
> adding the attribute.
> 
> You wrote: "Are there any plans to produce a standardized skeleton file
> format in future releases?"
> 
> There is a usefulness, if not a necessity, for this in the context of
> the profiles we wish to specify. In other words, a standardization of
> the skeleton file for files of the same file type, makes perfect sense.
> However, a standard skeleton file format could be impossible across file
> types. For example, the skeleton files generated for a DLL file must be
> remarkably different from those produced for an HTML file. However, it
> would be advantageous to create a standard skeleton format for HTML,
> another for DLLs, and others for those formats we specify profiles for.
> 
> cheers,
> 
> JohnR
> 
> To unsubscribe from this list, send a post to xliff-comment-unsubscribe@lists.oasis-open.org.

-- 
SunNetwork 2003 Conference and Pavilion
WHEN:  September 16-18, 2003
WHERE: Moscone Center, San Francisco
HTTP://www.sun.com/sunnetwork