RE: [xliff] Phase name attribute use

[John Reid <jreid@novell.com>]

Hello Mirek, Mark, and All,

This discussion brings out some problems with the phase information as it is currently defined. Phase is a bit overloaded. First, phase is used for versioning the file and the parts of the file. This is the case in <trans-unit> and <bin-unit> where the phase can mark which have gone through a proofreading and which have not. Second, phase is used for specifying the origin of translations. This is the case for the phase-name in the <target> and <bin-target>. Thus, the phase of <trans-unit> may be different than phase of <target>. In addition, each <trans-unit> may have multiple <alt-trans> (>=0). An <alt-trans> may have a <source>, which is useful in providing fuzzy matches. 

For example, in the following, the <trans-unit> has had a final review, the <target> of the <trans-unit> was entered during the translation phase, and the <alt-trans> came into the file during pretranslation.

<trans-unit id="1" phase-name="5final">
  <source>Cancel Report</source>
  <target phase-name="3trans">Annuler le rapport</target>
  <alt-trans match-quality="50%">
    <source>Cancel All</target>
    <target phase-name="2pretrans">Annuler tout</target>
  </alt-trans>
</trans-unit>

In the above example, though, the phase associated with the fuzzy match is stored all the way down in the target rather than the more sensible position of in the <alt-trans>. One could easily imagine the scenario where another <alt-trans> is used to store translator entered translation that is acceptable but changed upon review, possibly because of context information; this information may be required for historical reasons or so the difference can be arbitrated by a final review. (I'll use case as the differentiator since my language skills aren't sufficient to create a better example. Please bear with me.)

<trans-unit id="1" phase-name="5final">
  <source>Cancel Report</source>
  <target phase-name="4review">Annuler le Rapport</target>
  <alt-trans>
    <target phase-name="3trans">Annuler le rapport</target>
  </alt-trans>
  <alt-trans match-quality="50%">
    <source>Cancel All</target>
    <target phase-name="2pretrans">Annuler tout</target>
  </alt-trans>
</trans-unit>

Here, as in the first example, there is no information in the <alt-trans> as to when it was entered in the file. The assumption is made that it entered at the time of the review since that is the phase of the <trans-unit>'s target. 

Now, if we remove the occurence of phase-name as proposed, we no longer know if the <trans-unit> has been reviewed or not. It can only be assumed, erroneously, to be at the phase of the last phase entered in the <trans-unit>, phase-name="4review". Since this information may be useful but is not required, I disagree with removing the phase-name from the <trans-unit> and <bin-unit>. This information becomes even more important as we split and recombine XLIFF files during their processing.

<trans-unit id="1">
  <source>Cancel Report</source>
  <target phase-name="4review">Annuler le Rapport</target>
  <alt-trans>
    <target phase-name="3trans">Annuler le rapport</target>
  </alt-trans>
  <alt-trans match-quality="50%">
    <source>Cancel All</target>
    <target phase-name="2pretrans">Annuler tout</target>
  </alt-trans>
</trans-unit>

Adding in the reason attribute, if I understand it correctly, we have the following.

<trans-unit id="1" phase-name="5final">
  <source>Cancel Report</source>
  <target phase-name="4review">Annuler le Rapport</target>
  <alt-trans reason="Rejected-Inaccurate">
    <target phase-name="3trans">Annuler le rapport</target>
  </alt-trans>
  <alt-trans match-quality="50%" reason="TM-Suggestion">
    <source>Cancel All</target>
    <target phase-name="2pretrans">Annuler tout</target>
  </alt-trans>
</trans-unit>

Although this does answer the question of the reason for the <alt-trans>, it still does not fix the problem of the deeply embedded phase-name. Also, if the reasons aren't strongly typed somehow (read 'enumerated') that information won't easily be interpretted. Thus we will have added more unusable data.

I don't have a strong opinion one way or the other about the reason attribute. It solves some problems but may introduce others, especially if it is required. It still needs some more work.

I do think we should add the phase-name attribute to the alt-trans as an optional attribute. Following along with Yves's original thoughts on this, the phase-name could be placed at the <alt-trans> level for any <alt-trans> that has a <source>. It would be placed in the target of any <alt-trans> that does not have a <source>. 

<trans-unit id="1" phase-name="5final">
  <source>Cancel Report</source>
  <target phase-name="4review">Annuler le Rapport</target>
  <alt-trans reason="Rejected-Inaccurate">
    <target phase-name="3trans">Annuler le rapport</target>
  </alt-trans>
  <alt-trans match-quality="50%" reason="TM-Suggestion" phase-name="2pretrans">
    <source>Cancel All</target>
    <target>Annuler tout</target>
  </alt-trans>
</trans-unit>

cheers,
john



From:  "Milan Karásek" <milank@m...> 
Date:  Tue Feb 20, 2001  6:35 am
Subject:  Version Control in the LIF file

Hello,

These are our suggestions Re the focus team "Status Flags-Version 
Control". 

We can control the versions of two objects in the localisation 
process:

- Source file
- Translation



-- Version of the source file

Once the producer releases files for translation, this source 
file can change its version during the localisation process. LIF file 
should support indicating the current version of the source file. 
I would refer to the information about the file version into the
<file> element.




-- Version of the translation

During translation, the data goes through the process which consists 
of machine translation, manual translation, proofreading, sizing, 
etc. 
Each of these phases should be stored in the LIF file as a version 
of the translation. The same for suggestions.




-- Version Metadata

Versions in the LIF file can be stored either as a version name only 
(without any detailed description) or with full description in 
a <version> metadata element. Using of the detailed info in the 
metadata is optional, but recommended. We can understand the version 
name as a reference to the metadata record and/or just as a brief 
description of the version.

Because the set of attributes for both of the objects is different, 
the version metadata will be divided into the source and translation
related elements: <src_version> and <trans_version>.


Here is an example of using version names as a brief and full 
description:

1. Brief

<file ver_name="HandOff 24 Jan 2001, by Jack Hill">
<pgrp ver_name="Translated by Henry">
<p>...</p>
...
</pgrp>
...
</file>



2. Full

<file ver_name="HandOff20010124">
<pgrp ver_name="02_Trans">
<p>...</p>
...
</pgrp>
...
</file>


<metadata>

<src_version>
<ver name="HandOff20010124" date="20010124T155524Z" 
UserName="Jack Hill" Note="Latest 
handoff before final release"
Company="Oracle" />
</src_version>

<trans_version>
<ver name="01_MT" date="19990514T155524Z" var="MT" 
tool="MTtool583.exe" UserName="John" />

<ver name="02_Trans" date="19991005T120000Z" var="Trans" 
tool="TransTool.exe" UserName="Henry" />

<ver name="03_Proof" date="19991101T120000Z" var="Proof" 
tool="ProofTool.exe" UserName="Mike" />

<ver name="04_Sizing" date="19991115T120000Z" var="Resize" />
</trans_version>

</metadata>




-- Version of the LIF file

We can also store version of the LIF file. It can be useful in case 
of splitting one LIF file into more files (e.g. for more translators 
who can work simultaneously on it). We can introduce a new element 
into the metadata, called <lif_version>.


I think the way we should go now is to establish a content of the 
version metadata elements for all three objects (original, translation
and the LIF file).


Milan