[xliff-tools] The Fuzzy Flag

[Asgeir Frimannsson]

On Tue, 22 Feb 2005 20:59, Tim Foster wrote:
> Hey all,
Hi Tim!

> On Tue, 2005-02-22 at 02:17, Asgeir Frimannsson wrote:
> > >  - putting translations in the <target> element I think should be
> > > something that only a human can do.
> >
> > 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.
>
> Aha - didn't know that, thanks. So, perhaps then there's a case for
> the fuzzy text to appear as a <note> or <context> information ? (since
> you're still missing the source text of the fuzzy translation, it's
> hard to put it in either the target or alt-trans elements : if you do,
> you'll be warping the sense of the xliff spec, which wouldn't be good)

I can't see using <note> or <context> for fuzzy text as benificial, when we 
have the <target> element.
 
From the XLIFF 1.1. Whitepaper:

Section 3.1: "... The translation goes into a corresponding <target> element. 
The content of the <target> element depends on the stage at which the 
document is. Often tools set the initial translation text to the source text.

Doesn't this mean that the <target> element can contain unfinished 
translations aka 'fuzzy' translations?

As we're converting from one localisation format to another, I would put the 
fuzzy text from PO into a non-approved <target> element in XLIFF with state 
parameter set to needs-review-translation or similar. Yes, it is a 
compromise, as 'fuzzy' is used both for msgmerge and by translators. But as 
Bruno mentioned in an earlier thread, in an XLIFF based process, TM lookup is 
more likely to be done at the XLIFF side, not by msgmerge with PO 
compendiums. So in an XLIFF based process, the most likely cause for a fuzzy 
PO message is (from Bruno's earlier message):
 3) The translator may decide that s/he has produced only a half-finished
    translation, and mark it fuzzy.

But I see your point about not having non-humans put anything in the <target> 
element. And for the PO guide, we could mention the benefits and problems 
with each approach, and not enforce only one way of doing this? 

> > 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.
>
> I agree on the idea of doing a round-trip test to affirm than the file
> looks the same as the original. How about some logic in the code that
> writes out the resulting po along the lines of :
>
>  if (transunit.isFuzzy() && !transunit.hasTarget()){
>             writeFuzzyComment();
>             writeMsgId(transunit.getSource());
>             writeMsgStr(transunit.getContextItem("Fuzzy");
>         } else if (transUnit.hasTarget(){
>             writeMsgId(transunit.getSource());
>             writeMsgStr(transunit.getTarget());
>         } else {
>             writeError("No target translation done for " +
> transUnit.getId()); }
>
> We haven't implemented this in our tools (we just aren't caring about #,
> fuzzy at the moment), but it would get you around the problem of where to
> store the fuzzy translation. Pity there's no source text listed in the .po
> file with the fuzzy text...

I don't think it's such a big pity. As XLIFF in open source gains momentum, I 
think more and more fuzzy matching will happen on the XLIFF side. But I may 
be thinking ahead of myself :)

cheers,
asgeir