Hi Mirek et al, I think you make some very good points and agree that we should probably remove the 'phase-name' attribute from <trans-unit> and <bin-unit> as it can be retrieved, as you state, from the child <target>. I also think though that we should add this attribute to <alt-trans>, in doing this we will allow specification of when (i.e. which phase) a particular <target> was introduced to the XLIFF document AND when it was changed from a child <target> of <trans-unit> to a child of <alt-trans>. My take on 'phase-name' is that it should be used to indicate when an item (e.g. a <target>) was introduced into the XLIFF document. Following from this and extending on Yves' observations, I think that we should provide another attribute in <alt-trans> to indication the reason why a given <alt-trans> is an alternate translation. This attribute could be 'reason' and by making it required we could enforce more stringent use of <alt-trans>. Values for such an attribute that spring to mind are 'TM Suggestion', 'MT Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar' and 'Rejected-Length'. Since this attribute would be providing mostly informational content, it could be just free-format plain text, though I think a supplied list of values would allow for better tooling features, i.e. nobody would want to update a translation memory with a translation that was rejected for a misspelling, but an inaccurate translation for a given case may be useful. Anyone? Regards, Mark Mark Levins IBM Software Group Dublin Software Laboratory Airways Industrial Estate Cloghran Dublin 17 Ireland Phone: +353 1 7046676 IBM Tie Line 166676 Mirek Driml <
MirekD@moravia-it.com> 04/12/2002 15:46 To
xliff@lists.oasis-open.org cc Subject [xliff] Phase name attribute use Hi all, I've been looking at the phase-name attribute issue and also have discussed it with my coleague Milan Karasek who participated in XLIFF before. The result of my observation is: phase-name attribute is used for in <target> and <trans-unit> elements (and also in phase, bin-unit and bin-target elements) We use <source> and <target> elements inside the <trans-unit> element to keep the current translation. There are two cases: 1. there is no <target> element - i.e. the unit hasn't been translated yet hence we don't need to store any information about phase 2. there is <target> element containing phase-name attribute which says in which phase the translation unit occurs Since the current phase information can be retrieved from the <target> attribute I think we don't need phase-name attribute in the <trans-unit> element and my proposal is to remove it from there. Concerning alt-trans element and use of phase-name, following Yves' observation, I've found we can use it 1. to identify a different suggestion from a TM 2. to capture the evolution of translation during the translation process 3. to identify rejected translations ad 1) As Yves observered the different suggestion from the TM should always have quality-match attribute but no phase-name attribute until it wasn't used. ad 2) The evolution of translation during the translation process is fully covered by the phase-name attribute used in the <target> element that resides inside the <alt-trans> element. Only the <target> elements with phase-name attribute keep the text used during the process and the phase-name attribute defines which phase it was used in. ad 3) I'm not sure what exactly is meant by "rejected translations" a) if rejected translation is the translation that was used in the process and later it was corrected e.g. by proofreader then it is included in the case 2) and we can simply find what and when was changed b) if rejected translation is the suggestion from any other source than TM that has never been used then it should be stored in the <alt-trans> element without any phase-name and quality-match attributes Taking into account the observation above - my proposal is to remove phase-name atttribute from <trans-unit> element and to describe the use of the <alt-trans> element in the specification in more details to avoid any confusion. Similarly it would be removed from <bin-unit> element. I'm looking forward to your response. Best regards, Mirek PS: Milan is considering re-joining the XLIFF TC. Miroslav Driml SW Group Manager ============================= Moravia IT, a.s. Hilleho 4, 602 00 Brno, Czech Republic Phone: + 420-545-552-173 Fax: + 420-545-552-233 E-mail: mailto:
mirekd@moravia-it.com WWW:
http://www.moravia-it.com ============================= News and latest developments at:
http://www.moravia-it.com/news/ ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>