Red Hat Bugzilla – Bug 1461681
Make bookinfo/publisher translatable
Last modified: 2018-06-11 01:48:42 EDT
as suggested in https://bugs.debian.org/864648 it would be nice if bookinfo/publisher could be made translatable.
Here's the report I got:
I discovered this while working on The Debian Administrator's Handbook,
which uses publican. The en-US/Book_Info.xml file there include
publisher like this:
But these values are not made available for translation in
pot/Book_Info.pot. While it is arguable if publisher name should be
translatable, it is no doubt that city names sometimes must be
translated. I thus believe publican should make sure to include the
<bookinfo><publisher> content in POT files for translators to update. :)
In lib/Publican/Translate.pm there is a regex $TRANSTAGS which contains the list of tags to be translated, it just needs to be added in there.
Thanks for the reply, I know it's easy to do, but I don't want to do this in a Debian-specific patch. I'll just wait until it's done on your side.
That change only added "publishername" to $TRANSTAGS. I believe that marking "publisher" as a whole would make much more sense. First of, we really want to be able to translate the address too... as the bug report said, cities have translated names. And you really want to keep both data closely linked. If a translation is handled by another publisher, he might not want to share the same set of details as what was present for the publisher of the original version.
If you do publisher it will make one translation entry, instead you should specify all the specific tags you want translated.
I explained above why I prefer one translation entry: “If a translation is handled by another publisher, he might not want to share the same set of details as what was present for the publisher of the original version.”
You realise that if you do it at the publisher level then the translators get to have *all* the content of that tag as a single raw XML string?
Yes, it's not (much) worse than <indexterm> (or even <para> which can get XML-heavy with itemized lists for example).
The first example only happens when you have inline indexterms, block level indexterms get split up, this is because indexterm is one of the "dual state" tags in DocBook.
The second example shouldn't be valid at all as this was the specific example that lead us to stop using the KDE PO tools and write our own, which splits out the strings of nested blocks in to separate entries. If you have examples of that not working for para then that is a bug and we'll fix it :)
Personally I don't care about helping translators out that much any more, they never participate or represent there own interests, so as long as you are aware of the impact on them I'm OK with doing it at the publisher level.
My translators are rather willing to defend their own interests but they use Weblate to manage the translation and it has rather good XML checks and helper functions ensuring that the general structure of the original string is kept in the translation. And at least this offers the possibility to willingly diverge from the original XML structure in some cases.
In summary, please do it at the "publisher" level, I'm fully aware of the impact. Thank you.