Bug 887060 - Publican permits revnumbers in untranslated books that will cause translated packaging to fail
Summary: Publican permits revnumbers in untranslated books that will cause translated ...
Keywords:
Status: CLOSED DUPLICATE of bug 845432
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeff Fearn 🐞
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-14 00:33 UTC by Ruediger Landmann
Modified: 2013-07-04 05:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-04 05:23:40 UTC


Attachments (Terms of Use)
en-US Revision History with a mix of different revnumber formats (2.95 KB, application/xml)
2012-12-14 00:33 UTC, Ruediger Landmann
no flags Details

Description Ruediger Landmann 2012-12-14 00:33:30 UTC
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-14 01:06:54 UTC
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-14 01:14:44 UTC
(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 23:37:05 UTC
Does this problem still exist given the changes in BZ 845432?

Comment 4 Jeff Fearn 🐞 2013-07-04 05:23:40 UTC

*** 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.