[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: looking for a translation service for a gettext project
From:       Gudmund Areskoug <gudmundpublic () gmail ! com>
Date:       2006-05-30 14:54:28
Message-ID: 447C5CA4.8050504 () gmail ! com
[Download RAW message or body]

Hi Renato,

adding my DV experiences to your input, in case someone's interested in
getting some perspective on what's cooking on the proprietary side.

Renato Pavičić - Translator-shop wrote:
> Hello Shannon,
> 
> Well, I know how THEY feel! I am freelance translator (from Croatia),
>  and I gotta admit that PO files have been giving me a lot of 
> "professional" trouble. But, there are two solutions:
> 
> 1. You CAN translate PO files with Trados - But, you need lines
> (text) in "translated" lines! Take (ie) British-English PO, mark
> original lines as Trados-protected, and translate as usual!
> 
> If you need specifics on procedure (it it rather complicated), I can 
> give you instructions.
> 
> I know translators look like "spoiled brats", but it is not their job
>  to know programming. You can prepare the PO file, and send it to
> them as word doc file.

I wouldn't do that - context, comments etc.!

> 2. Deja Vu X
---snip---
> Firstly, on a plus side: ------------------------ - Usage of TM
> (translator-memory) database

What set DV aside from others, is that it has three DB options: MDB
(TM), TDB (term and subportions DB) and Lexicon (terms with override),
and can (auto)assemble translations with/from subportions from the TDB
and the Lexicon (to an extent from the MDB too, AFAIK)

> - Import of other TM DB (not directly,
> but there is a workaround - first export from old TM, then import
> into DV.

Depends what the DB format is.

> - Usage of spellchecker from MS Word -

Must check this, as I do my spell-checking outside DV: isn't using the
MS spellchecker optional?

> Filtering of lines - finished, empty, non-translated…

Plus: can filter on selection in source or target throughout file or
project.

> - When
> exporting, remembers original import path

...but not on a project level, so you'll have to redefine the path each
time if you hop between projects.

> Supposedly you can update imported file (I guess when the original is
> changed), but I have no experience on this

...iffy, and "but-y" IMHO.

> Limitations are following: (numerous, but don't give up!) 
> ------------------------------ - Before import, you gotta put "#,
> Lang = hr", into header of original PO to be translated (where "hr"
> stands for Croatian). DV needs to know import language pair, and this
> extra line is only meaning for that.
> 
> - During import it seems that DV wrongly interprets quotes over 
> multiple lines like: msgid "" "this is the first row, " "and this is
> the second row"
> 
> On export, they look like this: msgstr "" "this is the first row, and
> this is the second row"

Will check if there isn't a way to do this, that yields the correct
result. AFAIR, there should be.

> Consequently, PO header (with info on po file/translator) and is 
> treated as just another text line to be translated (no option for 
> preset, like in POedit), and this messes up translated file a bit. It
>  removes quotes from all of header, and all info in it is lost 
> (charmap, as most important) Gotta put all of them back by hand!

Have you notified Atril about this bug? They used to be receptive -
that's why they support po and pot files.

> - When translating: - cannot add words into spellchecker (it uses
> speller from MS Office, I guess it needs writing access, something
> that could be my personal, PC related issue, dunno)

I have to check this out, see above, it "should" be something in your setup.

> - trouble with
> "\n" tags - they do not visualy or practicaly break the row, so they
> remain inline with translated text

It also has a bug handling \n, introducing and not removing escape "\\n"
in both msgid and msgstr on export. AFAIR, it also let's you deal with
HTML-like strings "as is", rather than (nestedly) parsing the HTML,
which puts you in touch with another bug: not handling <>[] etc. in a
completely correct way (as placeables, e. g. omitting them at times,
missing DB content starting with them etc.).

> - trouble with multiple lines when
> no "\n" tag present - you cannot insert line break into translation
> 
> - When importing, DV does not recognize original "fuzzy" tags.
> 
> - Sometimes (rarely) it does not import properly: Some fuzzy lines
> are empty, also some translated. (but you can copy-paste from
> translated file)

Sounds like this could be solved, if investigated properly (when exactly
does one or the other happen) and notifying Atril.

> - Price: 400 euro for cheapest license

...and don't go for the cheapest one, go at least for the "Pro" version,
or you may well be disappointed.

> Conclusion: ----------- Beside all of the problems, it is 10 times
> better that troublesome! When I translate: - I spend less time to
> translate - I have TM DB

True. As a CAT, I've yet to see anything as good, all in all, despite
its bugs.

> One more thing - Since I am using DV only for KDE (yes, because it 
> rules! and I will make a pact with the devil for this), and NOT 
> commercially, I had a thought to approach DV development team and ask
>  them to make free version of DV, solely for PO files, solely for 
> non-profit work, but with TM DB import-export (it's a MUST!!!) If you
> find this idea interesting we can together try to approach them in a
> prepared, well explained manner. Maybe they ould like to become
> patronates? Like, "yes, we make money, but we are human"....

This sounds like a good idea. After all, they did pick up on introducing
gettext po/pot support into the app.

How I've used DV3 (and will be using DVX), is to run the files through
Kbabel and msgfmt for a once-over at least before delivery, and probably
Kbabel it as preprocessing too.

This said, I'd be a whole lot happier with such a tool a) running on
Linux and b) being open source.

I and a lot of other professional translators would still be happy to
pay for such a tool, to contribute to its development, maintenance and
occasional tweaking for special purposes. I've no idea, though if this
particular company could or would take such a step and still remain
alive and well. One hindrance in this case, is that the tool is built
around the MSJet DB enginge.

FWIW, BR,
Gudmund
[prev in list] [next in list] [prev in thread] [next in thread]