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

[Albert Astals Cid]

El dissabte, 28 de gener de 2017, a les 14:51:51 CET, Freek de Kruijf va 
escriure:
> Hi,
> 
> Below is a discussion about translating rkwardplugins.pot into Dutch on the
> rkwards-devel list. The developer is asking for an improved generation of
> the .pot file or suggestions on how to better write .docbook documentation
> in order to ease the translation of this type of documentation. I just
> inform this list about that discussion.

This thread is a textbook example of why top posting makes things hard to 
read.

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" ?

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