[xliff-tools] PO Representation Guide: The PO Header

[Asgeir Frimannsson]

On Tue, 15 Feb 2005 23:31, Rodolfo M. Raya wrote:
> On Tue, 2005-02-15 at 12:07 +0100, Josep Condal wrote:
> > For a human translator or reviewer, it makes a big difference to know if
> > something is a fuzzy or not.  I mean, if I get you right, you are making
> > the assumption that the human being can systematically correct what is
> > wrong either if it was a fuzzy or a previous error.
>
> I agree with you that it is very important for the translator to know if
> the segment is fuzzy, new or whatever.
>
> I did not complete my idea in the previous post. Let me try to go
> further.
>
> PO->XLIFF filter deals with the initial part of the translation process.
> The generated XLIFF file can be modified by TM and MT modules after the
> conversion is done and before the translator reviews it.
>
> If a segment in the PO file lacks translation, its state could be marked
> as "new" by the converter. If a there is a partial match in TM, it could
> be set to "fuzzy" after conversion. If there is an exact match in TM,
> the segment can be marked as translated, approved or whatever the TM
> system considers correct.

I assume by 'marking as new' you mean having 'approved' set to 'no' and 
'state' set to 'new'? Does this mean that translation units that have emtpy 
msgstr should, in addition to having 'approved' set to 'no',  have an empty 
<target> element with 'state' set to 'new'?

> After the TM translation process is completed, what the translator sees
> as indication of fuzzy or final is not what the PO->XLIFF filter
> originally wrote in the file. He sees the result of the pre-translation
> process.
>
> In the end, the translators may need to know if a translation is fuzzy
> or not, but that indication may not come from the conversion filter.
>
> What I tried to say is that it is not important from the filter point of
> view to know if a translation is fuzzy, new or what. The translator
> needs that information, but it can be altered by the TM system.
>
> One of the tests to do when writing an XLIFF filter is take a file,
> convert it to XLIFF, convert it back to the original format without
> translating and compare the original with the result. Both files, the
> original and the pseudo-translation, must be identical according to the
> source file format specification.
>
> To complete the test cycle described above you don't really need the
> "state" or "state-qualifier" attributes of the target element. This kind
> of tests are useful to determine the minimum information required for
> round-trip conversion.

I see your point here. A <trans-unit> must have the 'approved' attribute set 
to 'yes' for it not to be fuzzy when converting back to PO. And a 'fuzzy' PO 
message must have the 'approved' attribute set to 'no' when converting to 
XLIFF.

But I can't see why we shouldn't use the 'state' and 'state-qualifier' 
attributes when converting from PO to XLIFF to specify that it is a 'fuzzy' 
match. The XLIFF->PO converters does not need to care about these attributes, 
but it would be very useful for translators. It wouldn't matter if these 
values are overridden by other 'processes' such as TM matching, as the 
XLIFF->PO converter only cares about the 'approved' attribute.

So my suggestion is as follows:

PO->XLIFF:
 - fuzzy: 
    - 'approved' = 'no' (in <trans-unit>) 
    - 'state' = 'needs-translation' (in <target>)
    - 'state-qualifier' = 'fuzzy-match' (in <target>)
 - fuzzy or non-fuzzy and empty msgstr
    - 'approved' = 'no' (in <trans-unit>) 
    - 'state' = 'new' (in emtpy <target>)
 - non-fuzzy: 
    - 'approved' = 'yes'

XLIFF->PO
 - When 'approved' is 'yes', the message is not fuzzy
 - When 'approved' is 'no' the message is fuzzy

If vendors want to take the 'pessimistic approach' as mentioned earlier, they 
can always just run a script after conversion to change 'approved' to 'no' 
for all translation units.

> > I see you are referring to the XLIFF->PO.  I was refering to the initial
> > values of the PO->XLIFF transition to convey as much information as
> > possible from the home format to XLIFF, but I also expected returns to
> > PO for two reasons:
> > 1. To build the localized application at the end of the process
> > (normally when everything is raised to the "approved" level.
> > 2. To create intermediate PO files during translation or review but with
> > the only function to render the items in ordert to get some context or
> > simply to see how it looks, without having to finish all translation
> > (some type of preview feature.)
>
> When converting back from XLIFF to PO you can only expect translated
> text and something that tells you if the translation is final or not.
>
> Translation tools can't be forced to set "state", "state-qualifier" or
> any other attribute to special values. 

Agree. But that doesn't stop us from adding it [state and state-qualifier] to 
PO->XLIFF converters. We're simply adding more information, that tool vendors 
can embrace or ignore. There are pre-defined values for these parameters, and 
there is no reason why tools could not choose to implement support for at 
least the standard values.

cheers,
asgeir