Comment 8 for bug 298921

Martin, people are translating documentation in Launchpad today (so, your assertion is wrong). For anyone who's able to write DocBook I'd say they are a technical person (and they are likely not using it as such, since they are likely to be converting it to something else).

Now, can anyone clearly define a problem, please?

I can see several issues being mentioned in this bug report, so let me go one by one.

This I can say as much—subtitle translation support: won't fix.

DocBook (or most XML-based documentation formats) support: too much legacy issues (i.e. different handling in different communities), and too complex (I am not talking out of the blue sky: I have implemented a converter from DocBook to PO and back, and we'd need something even more complex here). Take note that DocBook support is a hard problem, because it's a problem with differing interpretation of it. If we are going to integrate it, we should integrate it with DocBook generation as well (i.e. over-the-web documentation creation), because then we can use a controlled subset of it. This is not something we need a bug for: it's not like we are going to forget about not providing support for documentation in Launchpad.

Improving translation of long documents with longer units of translation: we should do it. This will benefit not only current documentation translation in Launchpad, but all other use cases as well. If that's what you want to make this bug about, feel free to do so.

The other thing we can do is improve support for specific PO outputs coming from documents as well (i.e. xml2po has quite a few specific features for figures and similar, contained stand-alone elements and such). That's an interesting improvement which would basically only touch our UI, and that's where I think we can make the biggest improvement.