Is it possible to improve generating .pot files from English .docbook files?

[Thomas Friedrichsmeier]

Hi!

"Upstream" developer / documentation writer, here.

On Sun, 29 Jan 2017 18:23:27 +0100
Albert Astals Cid <aacid at kde.org> wrote:
> TBH I'm not sure what the problem is, is the problem that there are
> some extracted tests that shouldn't be translated since they are
> "commands" ?

This is a fairly technical documentation, much is explained by
(code) examples. These are contained in <programlisting/> elements.
These listings contain comments, and a few UI-labels, which should be
translated. However, naturally, most of the listings is actually
non-translatable code.

If there was a way to mark up up the translatable bits inside the
<programlisting/>s such that only those will be extracted, that would
probably help translators a lot. Is there a way to do this?

Regards
Thomas

> 
> Cheers,
>   Albert
> 
> > 
> > Op vrijdag 27 januari 2017 15:51:12 CET schreef Jaap Woldringh:
> > > Op 27-01-17 om 12:05 schreef Thomas Friedrichsmeier:
> > > > Hi!
> > > > 
> > > > Thanks a lot for your feedback, and sorry about the grief we're
> > > > causing! I was in fact totally unaware of this issue, so far
> > > > (we had worried quite a bit about making it easier to translate
> > > > rkward plugins, but never spent a thought on i18n of the
> > > > technical documentation).
> > > > 
> > > > In essence, the (most) problematic areas appear to the
> > > > <programlisting/> elements, and we use those quite a lot. Much
> > > > of the content of those areas is actually not translatable, of
> > > > course, but there are comments (and some labels) in between,
> > > > which should be translated. As a matter of fact, I think(TM),
> > > > that almost all of those comments and labels could reasonably
> > > > be treated as separate translation units, totally ignoring all
> > > > the XML surrounding them in the <programlisting/>s.
> > > > 
> > > > Hmm. Do you happen to know just how I could change the markup to
> > > > achieve just that?
> > > > 
> > > > Regards
> > > > Thomas
> > > 
> > > Hi, Thomas, thanks for this reply.
> > > 
> > > The problem that you mention is another one, which indeed ís a
> > > problem.
> > > 
> > > I guess most translators are not programmers themselves, but know
> > > their native language and English well enough to be able to
> > > translate from English into their own, satisfactorily, for normal
> > > texts.
> > > 
> > > Personally, as a retired math teacher, I am not really a
> > > programmer myself, but to a certain extend have dabbled with
> > > some, also modern, programming languages, of which Python is the
> > > latest one. And programming RPN calculators, of course, such as
> > > HP 67, 48 and 50.
> > > 
> > > I leave the program listings themselves as they are, right now,
> > > and while translating the texts I have to account for that, and
> > > explain. This means that I have to make at least a second pass
> > > through the whole document, just to get this right. Making an
> > > error in the program texts (except in the comments) may ruin the
> > > experience of the users. I am very cautious when translating
> > > names of variables, as I am not always quite sure whether they
> > > are standard names or not. Therefore:
> > > 
> > > I did think of this problem, but I don't think it's feasible (?)
> > > to print the texts, in a .po file, which should not be
> > > translated, in a very distinct letter, or colour (pity if a
> > > translator is colour blind :) ). But then one is still left with
> > > the necessity for explaining these untranslated texts, in the
> > > other messages. These I usually explain in one or two places
> > > between parentheses, when appropriate. But then: a handbook is
> > > never read straight from page 1 to page last, I assume.
> > > 
> > > It pleases me very much, reading in your answer, that you have
> > > understood this problem yourselves ... hope that you'll find a
> > > workable solution for this.
> > > 
> > > Regards,
> > > 
> > > Jaap Woldringh
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20170130/695cd83a/attachment.sig>