RE: [xliff] Phase name attribute use

[John Reid <JREID@novell.com>]

Hi Milan and All,

It is great to hear from you again, Milan. You make some very valid arguments. I agree that we need to do some reworking of the internal structure of <trans-unit>. As I researched this problem I found some overlooked attributes: <trans-unit> has the approved boolean attribute; <target> has a state attribute, currently with the values of 'needs-translation', 'needs-review', and  'needs-resizing'; <alt-trans> has the origin attribute. These may provide some help for the current issue. 

The following example uses the current definition of XLIFF. With expanded state values, the state can hold the info posited for reason in the <target>.

    <trans-unit id="1" phase-name="5final" approved="yes">
        <source>Cancel Report</source>
        <target phase-name="4review" state="Approved">Annuler le Rapport</target>
        <alt-trans origin="this-file">
            <target phase-name="3trans" state="Rejected-Inaccurate">Annuler le rapport</target>
        </alt-trans>
    </trans-unit>

As can be seen by the above example, the approved attribute of <trans-unit> is a special case version of state and is redundant. The 

However, it is more convenient to search the XLIFF at the <trans-unit> level for the state of the translation. Thus, the state attribute seems appropriate at the <trans-unit> level. For example, this:

    <trans-unit id="1" phase-name="2pretrans" state="needs-translation" approved="no">
        <source>Cancel Report</source>
    </trans-unit>

makes more sense to me than this:

    <trans-unit id="1" phase-name="2pretrans" approved="no">
        <source>Cancel Report</source>
        <target state="needs-translation"></target>
    </trans-unit>

especially when the <target> is not entered in the XLIFF file until translation. This makes me wonder if we really need to add yet another unenumerated attribute.

The original discussion came from Yves's proposal to distinguish between proposed alternative translations and historical translations via the existence of a match-quality attribute. This doesn't work since there is no way to conditionally make match-quality required. However, as can be seen above, we can specify an origin attribute value that says the alternate translations stored are historical, as was done using "this-file". 

Modifying your overall example:

    <trans-unit id="1" phase-name="5final" approved="yes">
        <source>Cancel Report</source>
        <target phase-name="4review" state="Approved">Annuler le Rapport</target>

        <!-- TRANSLATION HISTORY: -->
        <alt-trans origin="this-file">
            <target phase-name="3trans" state="Rejected-Inaccurate">Annuler le rapport</target>
        </alt-trans>

        <!-- ORIGIN OF (PRE)TRANSLATION: -->
        <alt-trans match-quality="50%" origin="Version 2.0">
            <source>Cancel All</source>
            <target phase-name="2pretrans">Annuler tout</target>
            <target phase-name="2pretrans" state="TM-Suggestion">Annuler Tout</target>
        </alt-trans>
        <alt-trans match-quality="100%" origin="Product Y version 1.0">
            <source>Cancel Report</source>
            <target phase-name="2pretrans" state="TM-Suggestion">Annuler le rapport</target>
        </alt-trans>
    </trans-unit>

So far, nothing new has been added to XLIFF 1.0 other than "this-file" value for origin. Yet, we have distinguished between the historical translations and the TM proposed translations, the reason for the alternate translations has been indicated, and the phase in which the target alternative translations was proposed has been recorded (along with the tool used in generating the proposal). There is some clean-up work that we could do but this suffices.

Milan points out the confusion between the phase of the trans-unit and the phase of the target. I agree. The approval state of the trans-unit is more important than the phase in which it was last touched, especially since these phases could vary greatly by vendor. If the phase-name and approved attributes were removed and the state were promoted to <trans-unit> it could hold that information. However, this proposal does create a confusion by overloading the state attribute; it should probably be the approval-state or the trans-unit-state or something less verbose to differentiate it from the target's state. I'll use tu-state (although I don't like it) for this discussion. It is this tu-state attribute that should have the values  "needs-translation", "needs-review", and  "needs-resizing", besides the "approved" value. It might also be that we need to specify that a <trans-unit> has more than one tu-state; e.g. "translation-approved needs-resizing".

    <trans-unit id="1" tu-state="translation-approved">
        <source>Cancel Report</source>
        <target phase-name="4review" state="Approved">Annuler le Rapport</target>

        <!-- TRANSLATION HISTORY: -->
        <alt-trans origin="this-file">
            <target phase-name="3trans" state="Rejected-Inaccurate">Annuler le rapport</target>
        </alt-trans>

        <!-- ORIGIN OF (PRE)TRANSLATION: -->
        <alt-trans match-quality="50%" origin="Version 2.0">
            <source>Cancel All</source>
            <target phase-name="2pretrans" state="TM-Suggestion">Annuler tout</target>
            <target phase-name="2pretrans" state="TM-Suggestion">Annuler Tout</target>
        </alt-trans>
        <alt-trans match-quality="100%" origin="Product Y version 1.0">
            <source>Cancel Report</source>
            <target phase-name="2pretrans" state="TM-Suggestion">Annuler le rapport</target>
        </alt-trans>
    </trans-unit>


In summary, the changes from the above are:
1. Add a new attribute to <trans-unit> to specify the state of the translation unit with the values of "needs-translation", "needs-review", "needs-resizing", "translation-approved",  "sizing-approved" and whatever else we may see as appropriate.
2. Add the origin value of "this-file" defined as designating an <alt-trans> containing previous and rejected translations from the current file.
3. Add new values to the state attribute in <target>: 'TM-Suggestion', 'MT Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar', 'Rejected-Length' and whatever else we may see as appropriate.

cheers,
john