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