[xliff-tools] The Fuzzy Flag

Asgeir Frimannsson asgeirf at redhat.com
Mon Feb 21 18:17:41 PST 2005


On Thu, 17 Feb 2005 02:28, Tim Foster wrote:
> On Wed, 2005-02-16 at 15:05, Bruno Haible wrote:
> > This flag also occurs as side effect from msgmerge. I would therefore
> > not use the <target> element in this case, and instead give
> > <alt-trans><source>...</source> <target>...</target></alt-trans>
>
> +1
>
>  - putting translations in the <target> element I think should be
> something that only a human can do. We allow 100% matches in there, but
> don't mark the segment as being approved until a human does so (possibly
> via the "Approve All Segments" option, but even still, they have to take
> some action to make it so.

IMO there is a difference when converting files from another localisation file 
format. If 'fuzzy' was only used by msgmerge, I would agree, but it is 
commonly used by translators to mark an entry as needing-review. 

As Rodolfo mentioned in another thread, a good test is to convert and 
backconvert a file without changing it. The backconverted file should be 
excactly the same as the original, and when using an <alt-trans> element, 
this is not the case. 

> We wanted to make our xliff files as foolproof as possible, so that someone
> would really have to go to some trouble to unwittingly take a partially
> translated xliff file and import it into a database without the
> translation being complete.
>
> (the risk being, of course, that other projects could leverage from
> incomplete or unreviewed translations)

I assume you only export entries to TM that are marked approved='yes'? In that 
case, it would be a translator making a mistake, not a flaw in the workflow.

cheers,
asgeir


More information about the xliff-tools mailing list