Bug 1461681

Summary: Make bookinfo/publisher translatable
Product: [Community] Publican Reporter: Raphaël Hertzog <raphael>
Component: publicanAssignee: Nobody <nobody>
Status: POST --- QA Contact: Ruediger Landmann <rlandman>
Severity: low Docs Contact:
Priority: unspecified    
Version: futureCC: cbredesen, pere, rlandman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Raphaël Hertzog 2017-06-15 07:36:20 UTC
Hello,

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:

  <publisher>
   <publishername>Freexian SARL</publishername>
   <address><city>Sorbiers</city></address>
  </publisher>

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. :)

Comment 1 Jeff Fearn 🐞 2017-06-15 07:43:52 UTC
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.

Comment 2 Raphaël Hertzog 2017-06-15 08:29:59 UTC
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.

Comment 3 Jeff Fearn 🐞 2017-06-16 05:01:02 UTC
https://sourceware.org/gerrit/#/c/10/

Comment 4 Raphaël Hertzog 2017-06-16 07:57:11 UTC
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.

Comment 5 Jeff Fearn 🐞 2017-06-19 03:49:57 UTC
If you do publisher it will make one translation entry, instead you should specify all the specific tags you want translated.

Comment 6 Raphaël Hertzog 2017-06-19 06:11:18 UTC
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.”

Comment 7 Jeff Fearn 🐞 2017-06-19 06:18:12 UTC
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?

Comment 8 Raphaël Hertzog 2017-06-19 09:45:58 UTC
Yes, it's not (much) worse than <indexterm> (or even <para> which can get XML-heavy with itemized lists for example).

Comment 9 Jeff Fearn 🐞 2017-06-19 22:41:35 UTC
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.

Comment 10 Raphaël Hertzog 2017-06-20 06:41:26 UTC
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.

Comment 12 Petter Reinholdtsen 2020-10-30 10:01:00 UTC
Hi.  I am the original requestor for this improvement.  Is there any reason why this have not yet been fixed, or was it just forgotten?