Bug 887060 - Publican permits revnumbers in untranslated books that will cause translated packaging to fail
Publican permits revnumbers in untranslated books that will cause translated ...
Status: CLOSED DUPLICATE of bug 845432
Product: Publican
Classification: Community
Component: publican (Show other bugs)
3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Fearn
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-13 19:33 EST by Ruediger Landmann
Modified: 2013-07-04 01:23 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-04 01:23:40 EDT
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)
en-US Revision History with a mix of different revnumber formats (2.95 KB, application/xml)
2012-12-13 19:33 EST, Ruediger Landmann
no flags Details

  None (edit)
Description Ruediger Landmann 2012-12-13 19:33:30 EST
Created attachment 663275 [details]
en-US Revision History with a mix of different revnumber formats

Description of problem:
Publican 3 relies on a high level of consistency in the <revnumbers> of book Revision Histories to ensure that the Revision Histories of translations are sorted correctly when merged in.

When packaging the book in its original language, Publican does not have to sort the entries, so a much lower degree of consistency is permitted.

Authors therefore create revision histories that work fine for themselves, but which cause problems when translators try to package their work. (see attached example -- note the mix of x.y-z, x-z, x.y.z-r)

Version-Release number of selected component (if applicable):
3.0

How reproducible:
100%

Steps to Reproduce:
1. insert the attached Revision History into a book
2. run "publican package --lang en-US"
3. note that packaging works and Publican produces a valid SRPM
4. run "publican update_pot" and "publican update_po" for a language other than en-US
5. run "publican package" for that language
  
Actual results:
Publican cannot sort the entries from the translated language's Revision_History.xml file and packaging fails because the changelog is not in descending chronological order

Expected results:
And revision history that packages correctly in the original language should package correctly in translation (and any that would fail in translation should fail in the original language too).
Comment 1 Jeff Fearn 2012-12-13 20:06:54 EST
Are you saying that you want Publican to run the same sorting function on the source language revision history?
Comment 2 Ruediger Landmann 2012-12-13 20:14:44 EST
(In reply to comment #1)
> Are you saying that you want Publican to run the same sorting function on
> the source language revision history?

Yes; running the same sort on the source language would enforce compatibility when it came to sorting the translated rev histories.
Comment 3 Jeff Fearn 2013-01-14 18:37:05 EST
Does this problem still exist given the changes in BZ 845432?
Comment 4 Jeff Fearn 2013-07-04 01:23:40 EDT

*** This bug has been marked as a duplicate of bug 845432 ***

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