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

[Josep Condal]

Hi Rodolfo, 

>>  Obviously, if the translation project is not to be reviewed by a 
>> second person, the translator can directly approve his own 
>> translations as a shortcut.

> 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. The fact that 
historically many times the translator of a PO file has been an 
entusiast of the application localized, doing it on a volunteer 
basis and in a context where no review was enforced does not
mean that it always will be always be like that.  As companies
or projects get more structured, processes tend to be less
dependant on individual heroism (a very good translator) and
more the work of a team with very diverse motivations. Therefore, 
I challenge that in the long term the translate attribute will be 
really redundant. IMO, it's a little bit like like saying that in 
development cycle, the test is not necessary because the developers 
are so good and motivated than never make a mistake or they are
Very minor, so as soon as the code compiles once, it can be released 
to manufacturing without further checking other than the one done
by the developer himself because the compiler did already a lot 
of checking.

>> Still I think there must be some way to indicate that it is a fuzzy 
>> match at file generation time from a filter's point if view,

> From the filter's point of view there is no need to indicate that a
> match is fuzzy at generation time. Translations are supposed to review

> the complete file and fix errors in segments that may have been marked

> as correct previously by mistake.

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.  My experience is
that the alarms are different if he knows that the segment is wrong for
sure (it is a fuzzy) or simply can be wrong because of a misunderstood 
translation. You simply review in a different way. If you put all 
segments in the same pot without any type of warning, the reviewer 
will be more error prone.

>> In the case of a fuzzy in the PO file:
>> translated="no"
>> approved="no"
>> state="needs-translation"
>> state-qualifier="fuzzy-match"
>>  
>> In the case of a translated item in the PO file:
>  
>> translated="yes"
>> approved="no"
>> state="needs-review-translation"
>> state-qualifier="exact-match"

> The values of "state" and "state-qualifier" attributes are not boolean

> and depend on the editor used to translate the file. 

> After translation you can have the following perfectly valid
situation:

>        translated="yes"
>        approved="yes"
>        state="final"
>        state-qualifier="leveraged-inherited"
        
> Only "approve" and "translated" can be used to determine for sure if
the segment state is fuzzy or not. 

> What should the XLIFF->PO filter do with a segment with translated set
to "yes" and "approve" set to no? Tricky problem > and exactly the
reason why I would base the decision in only one attribute.

> There are several editors now in the market that handle XLIFF files.
> Each editor uses the available attributes in a different way. It is
essential to avoid ambiguities, restricting 
> dependencies in attribute values to the minimum. 

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

In the second case, PO files are just temporary files that can be
deleted after the visual check so it's not really important what the
meaning of the attributes is.

Regards,

Josep.

Josep Condal
Managing Director
ApSIC S.L.
---
Caballero, 76 4-3
08029 Barcelona
Spain

T: +34 93 405 11 00
F: +34 93 430 81 77
@: pcondal at apsic.com
---