[xliff-tools] The Fuzzy Flag

[Tim Foster]

Hey all,

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)

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

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

Yep - absolutely : just that the translator would have to make that mistake
and not some localisation engineer unwittingly importing a non-complete file
and have the process happily allow them to do that. Okay, it's not much of
a failsafe, but better than nothing.

	cheers,
			tim


-- 
Tim Foster - Tools Engineer, Software Globalisation
http://sunweb.ireland/~timf http://blogs.sun.com/timf
http://www.netsoc.ucd.ie/~timf