Is it possible to generate a single .pot file from Sphinx documentation?

Question

I'm undergoing the task of i18n / l10n the documentation of a largish project. The documentation is done with Sphinx, that has off-the shelf basic support for i18n.

My problem is similar to that of this other question: namely the fact a large chunk of the strings for each pot file is the same, and I would like my translators not to re-enter the same translation over and again. I would rather have a single template file.

My problem is not really merging the files (that is just a msgcat *.pot > all.pot away), but rather the fact that - for the domains to work when building the documentation in a particular language - I have to copy and rename all.pot back to the original file names. So my workaroundish way of working is:

1. Generate fileA.pot, fileB.pot
2. Merge the two into all.pot
3. cp all.pot fileA.pot + cp all.pot fileB.pot

Is there a cleaner way to do the same? gettext_compact brings me only half-way through my goal...

Rosyrot

Have you considered using a Translation Memory (which has unique source/translation key-values)? – Underwaist

@Underwaist - Yes I did, but that would considerably increase the complexity of the architecture without bringing any benefit to the outcome (over my present workaround). – Rosyrot

Answer 1

After over 7 months, extensive research and a couple of attempted answers, it seems safe to say that no - at least with the current version 1.1.3 - it is not possible to generate a single .pot file from Sphinx documentation.

The workaround described in the original question is also the most straightforward for automatically removing duplicate strings when merging the different .pot files into a single one.

Rosyrot

Answer 2

I see two possibilities here:

One is to hack Sphinx to not use domains at all… which I guess you won’t want to do for several reasons.

The other is: since you split by domains, the -M option of msggrep looks like it does what you need to do. Otherwise, the -N option can still be used to filter by source file(s).

That is, if the obvious solution doesn't work:

• generate fileA.pot, fileB.pot (also look at msguniq here)
• merge them into all.pot and give that to translators
• for x in file*.pot; do msgmerge -o ${x%t} all-translated.po $x; done

According to TFM, msgmerge only takes the (supposedly newer) translations from its first argument (the translated po file) that match the up-to-date source locations of the second argument (po file with old translations, or pot file = template with only empty msgstrings).

Widgeon

I'm not sure I got what the technical advantage of this solution is, over my present hack, could you please clarify? – Rosyrot

I understood your present hack to have all strings in the eventual fileA.pot and fileB.pot files and thought you wanted to clean them up. If that’s not the case I fear I did not understand your problem correctly, can you clear up how we can help? – Widgeon

The title of the question says it all already. :) Also, your answer seems to replicate - in a longer way - what the solution described in the question already does (try for yourself, the resulting .pot is already clean and does not need any more mangling)... or am I missing something? – Rosyrot

Answer 3

Add the following to your conf.py :

gettext_compact = "docs"

Mantoman