Hi Mirek,
I agree with your comment regarding
the addition of the 'phase-name' attribute to <alt-trans>, I mistakenly
assumed <alt-trans> was restricted to one <target>.
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 <>
05/12/2002 15:13
To
Mark Levins/Ireland/IBM@LOTUSINT
cc
Subject
RE: [xliff] Phase name attribute
use
Hi Mark,
Concerning the 'reason' attribute I like the idea.
I mean we could add it to
the proposal suggesting that the phase-name attribute will be removed from
<trans-unit> and <bin-unit> elements.
On the other hand I don't think adding the phase-name attribute to the
<alt-trans> element would help. There can be more than one <target>
element
inside the <alt-trans> and you could use just one phase-name attibute
in the
<alt-trans> element . Unfortunately you can't cover all the targets
by only
one attribute in the parent <alt-trans> element. By my opinion the
first
case you adduced - when (i.e. which phase) a particular <target>
was
introduced to the XLIFF document - is much more important for tracking
the
localization process. For the second case - if you know the order of the
phases you can sort <target> elements placed in the <alt-trans>
and then it
should be possible to find when the particular <target> element was
moved
from <trans-unit> element to the <alt-trans> element.
Best regards,
Mirek
-----Original Message-----
From: Mark Levins [mailto:]
Sent: Thursday, December 05, 2002 2:54 PM
To: Mirek Driml <MirekD
Cc:
Subject: Re: [xliff] Phase name attribute use
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 |
|
| <> |
|
|
|
To|
| 04/12/2002 15:46 |
xliff@li|
|
|
sts.oasi|
|
|
s-open.o|
|
|
rg |
|
|
cc|
|
|
|
|
|
Subject|
|
|
[xliff] |
|
|
Phase |
|
|
name |
|
|
attribut|
|
|
e 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:
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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
