On 2011-04-20 15:46, Rimas Kudelis wrote:

Hi,

2011.04.20 16:37, Dwayne Bailey rašė:
I'd rather see us spending some time to create a way to inject and store arbitrary errors for PO files stored on Pootle. That way anyone can create a script that identifies problems, injects them into Pootle and allows translators to fix them quickly on Pootle in an environment that is familiar and safe.

What about automatically marking invalid translations as fuzzy in the .po file and adding a translator comment above them? This would be generic enough, and would not depend on Pootle at all.
It's a hack. It would mean that people writing checks must work on PO files, the checks I'm referring to are working directly on SDF files. You could script pogrep to find these, mark them fuzzy and inject them into the original PO files - but still a hack in my mind. Not all failing checks should be fuzzy, I reserve that for checks that break things.

The checks in Pootle are not actually written in Pootle but in the Translate Toolkit which is why you can run them against your PO files outside of Pootle. We already use a scheme for marking these when we use pofilter on the command line. Maybe that is an approach that should be examined, but it would still mean changing Pootle to read these comments when it finds them in a PO file.

Marking something fuzzy doesn't push it into a class of error with a specific agenda to fix. So I can't go through errors of type X. I will get all my fuzzy strings together in one lump with only a comment (which I must also now delete) to distinguish it from a proper fuzzy.

It has been my aim to make sure these checks cover gsicheck 100% as then for a Pootle user Pootle becomes the right place to fix these errors. They then don't need to decipher gsicheck output which is difficult. Pootle has a special openoffice checker that it gets from the Translate Tolkit so it is possible to write anything that is needed and then also doesn't depend on Pootle.

So either the checks are written to be a proper Translate Toolkit check so that it can show directly in Pootle, ideal (Unfortunately we haven't had any Oracle devs contribute changes to the checks so don't hold your breath). Or we have some way for outside checks to report their errors to Pootle and mark units for review.

Programmers will do anything as quickly as they can. Us localisers accept what we get which is why we're reading SDF snippets and strange error output. We spend quite a bit of time interpreting the results, we don't complain. I think there is a better solution that would mean that we can translate instead of pretend we're programmers as we interpret SDF output.

--

regards
Dwayne

--
-----------------------------------------------------------------
To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org
For additional commands send email to sy...@l10n.openoffice.org
with Subject: help

Reply via email to