[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