Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to Chester Cheng from comment #0) > Description of problem: Translators have to add their own (localized) Revision History and this has been causing issues. We hope to remove this function in the future revision of publican. > > Version-Release number of selected component (if applicable): > > > How reproducible: > Always. > > Steps to Reproduce: > 1. Run "publican add_revision" > 2. Build with "rhpkg" > 3. > > Actual results: > The Revision History mechanism caused problems in the process of translating every book. > > Expected results: > Translators don't have to take care of the Revision History anymore. > > Additional info:
A couple of questions came up in my mind, if stop adding a revision history for localization; o How can we know the date which particular book was last translated? o Do we give up an opportunity to be credited as translator to a book? o How can a reader to identify which update is not localized, if it happens after initial localization work been delivered?
(In reply to Noriko Mizumoto from comment #3) > A couple of questions came up in my mind, if stop adding a revision history > for localization; > > o How can we know the date which particular book was last translated? > o Do we give up an opportunity to be credited as translator to a book? > o How can a reader to identify which update is not localized, if it happens > after initial localization work been delivered? These are all excellent, practical reasons why translators are now responsible for their own revision histories. The previous mechanism (incrementing the Project-Version-Id) was ineffective in capturing useful data about a translation. (There's also a technical side to this, because the RPM packages we produced with the old method almost always failed RPM validity tests.) However, we acknowledge that the documentation of this feature is poor, and that the poor documentation has led to many problems when people don't understand how to use and update revision histories. We will improve this documentation in a forthcoming release.
Some better instructions included in the Publican User Guide fe2d7c7..719c6e9 devel -> devel