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

[Rodolfo M. Raya]

On Tue, 2005-02-15 at 12:07 +0100, Josep Condal wrote:
> Hi Rodolfo, 

Hi,

> > You are right. The fact that most often translators dealing with PO 
> > files are the ones that mark a translation as approved makes the 
> > use of the translate attribute a little bit redundant.
> 
> Don't really agree with your point of redundancy. 

It's OK. I know it is arguably and there is no real obstacle for using 2
attributes. 

> 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.

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 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. Tools that can edit XLIFF files
are able to handle XLIFF documents generated from HTML, plain text, XML,
MIF, RC files and many other formats, where there are no requirements
for handling attributes of the <target> element.

FWIW, translation tools provide preview facilities. You don't need to
rebuild a PO file to see how your translation looks like while you are
translating. Anyway, this depends on the tool selected to do the job.

Regards,
Rodolfo
-- 
Rodolfo M. Raya <rodolfo at heartsome.net>
Heartsome Holdings Pte. Ltd.