Bug 1461681 - Make bookinfo/publisher translatable
Make bookinfo/publisher translatable
Status: POST
Product: Publican
Classification: Community
Component: publican (Show other bugs)
future
All All
unspecified Severity low
: ---
: ---
Assigned To: Jeff Fearn
Ruediger Landmann
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-15 03:36 EDT by Raphaël Hertzog
Modified: 2017-06-20 02:41 EDT (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 864648 None None None 2017-06-15 03:36 EDT

  None (edit)
Description Raphaël Hertzog 2017-06-15 03:36:20 EDT
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 03:43:52 EDT
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 04:29:59 EDT
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 01:01:02 EDT
https://sourceware.org/gerrit/#/c/10/
Comment 4 Raphaël Hertzog 2017-06-16 03:57:11 EDT
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-18 23:49:57 EDT
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 02:11:18 EDT
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 02:18:12 EDT
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 05:45:58 EDT
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 18:41:35 EDT
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 02:41:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.