Re: PO-based Documentation Translation

[Danilo Segan <dsegan gmx net>]

�реда, 01. октобар 2003. 17:16:55 CEST — Tim Foster напи�а:
> > Text to be left untranslated is simply not marked for translation.
> 
> how about certain strings mid-message that shouldn't be translated ?
> There isn't really a way of protecting these, apart from a
> human-readable comment above saying "don't translate bla".
>

I'm used to seeing strings like this:
 'Erroneous tag %s found - aborting.'
with a comment that %s will be replaced with tag (untranslatable part).

msgfmt signals an error if one misses or misuses printf format  
specifiers.

So, like in any other case, developers need to take care about what is  
to be translated, and what is not.

> > Fuzzy match is standard in msgmerge.
> 
> can it match against a database of a few million source segments, or
> just against one other file ?

It can match against a number of files, by specifying several -C  
parameters. That's how I do it, and the only problem is that it's slow  
(with a "database" of 45k strings, it takes two hours [of cheap cpu  
time :] to complete matching for file of 500 strings).

> well, apart from our translation editor which is used by reviewers to
> mark translations as "good" or "needs review", we don't have any
> special tools. Using translation memory on a large scale, as I  
> mention in (c) above helps to ensure consistency - which I guess is  
> difficult to do in a more bazaar-like manner, as opposed to our  
> current cathedral approach.

Yes, "needs review" flag is nice, because otherwise, translators tend  
to mark those strings as "fuzzy", which get lost in the sea of machine  
fuzzy matches. So, I've decided to use a comment for specifying it, and  
even extended po-mode with simple functions that skip to next "unclear"  
translation, or the previous (I just derived them from fuzzy-finding  
functions; I'm not that familiar with Elisp).

I didn't want to insert it in the "program comment" ("#," -- where it  
naturally belongs), because then my PO files might be incompatible with  
everything else. I also standardize on mentioning bugs in original  
strings with '# bug', so egrep-ing is really not a hard task.

Of course, if there was some standard for these, it'd be all the better ;-)

Sure, all of this is 'manual hacking', as it is not 'tool/format  
supported', but it's good enough for me (for now).

Cheers,
Danilo