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] | [Elist Home]

Subject: RE: [xliff] Phases of alt-trans - use of alt-trans for change history

Question regarding use of <alt-trans>:
I have source text of "Edit HTML" that has been translated. Now I change the source text to be "Edit Source". This means that the new source text needs to be translated. I am currently including the old source and old translation in the <alt-trans> element.
Is it usually and customary to use <alt-trans> in this way?
Is this what is meant by "change control"?
If so, do I need to set an attribute, such as match-quality, to indicate that the <alt-trans> is provided to show the change history?
<xlf:trans-unit id="mnuEHtm">
    <xlf:source>Edit Source</xlf:source>
    <xlf:target state="needs-translation">Editer le code HTML</xlf:target>
        <xlf:source>Edit HTML</xlf:source>
        <xlf:target>Editer le code HTML</xlf:target>

Doug Domeny

-----Original Message-----
From: John Reid [mailto:jreid@novell.com]
Sent: Sunday, February 09, 2003 1:37 AM
To: >
Subject: [xliff] Phases of alt-trans

Hi All,
Yves originally suggested using the existence of the match-quality attribute to determine whether an alt-trans was leveraged or change control. Match-quality is free text that can contain a score or any arbitrary value based on the tool that generates the <alt-trans>. Unfortunately this makes it difficult to rely on that attribute.
Mark suggested adding a reason attribute to the <alt-trans> with the values 'TM Suggestion', 'MT Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar' and 'Rejected-Length'. This would allow us to mark an alt-trans as being leveraged ('TM Suggestion' and 'MT Suggestion') or change-control ('Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar' and 'Rejected-Length'). Thus, all <target>s in an <alt-trans> would have to have the same reason. Or, rather, a new <alt-trans> would be needed for each of the rejected reasons. This may create a lot of <alt-trans> but only if someone (the translator?) is doing a poor job. Likely there will only be very few of these.
I had suggested we use the origin attribute of <alt-trans> with the value 'this-file' to indicate a change-control. This would require enumerating that one value for origin and making any other values to begin with an 'x-', to be consistent. That just isn't very practical.
Maybe a combination Yves's and Mark's suggestions are the answer. Enumerate match-quality with Mark's values and allow extension.
I still stand by my suggestion of adding a state attribute to <trans-unit> for the reasons outlined. I also suggested to add Mark's reason values to state. However, I suggest that we not do that.

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

Powered by eList eXpress LLC