Description of problem: In svn/git based projects, translators usually run "publican update_po" to generate a localization revision number, together with name (option), email address (option), and message (mandatory). This command cannot be used in pressgang projects. The current workaround suggested by Rudi is that using "publican add revision" to generate a new number and manually edit the Revision_History.xml file to change the number to a sub-number. This works fine when we have only one or two localization entries. However, if the number of entries increases or if we have to reuse that file, it can be problematic. We do not save localized Revision_History.xml in any repo. If the translator who created it delete the file, it has to be done from the scratch. Manual work like this is time-consuming and error-prone. Hope you can come up with more efficient, semi-automated solution, hopefully in time for RHEV 3.3. Version-Release number of selected component (if applicable): not sure How reproducible: Always Steps to Reproduce: 1. In a pressgang-based documentation project, translate Revision History 2. Build the guide 3. Check the Revision History entries Actual results: No localization revision number/message is included unless running "publican add revision" command and then editing the file manually. Expected results: There should be more integrated step to generate the number, to add a message, and save that information for the subsequent updates. Additional info:
Created attachment 754747 [details] Localization revision number is a subnumber based on the en-US revision number
Comment on attachment 754747 [details] Localization revision number is a subnumber based on the en-US revision number In this screenshot, 3.2-37 is the most current en-US revision number, and we needed to manually create 3.2.37.1 for our localized version.
Thanks Yuko for providing so much detail. Just fixing the version and components up for now. As for some basic details getting it to generate the revision history entry will be trivial, however what we will need to figure out is how to store and get the revision history message to be stored.
Added in 1.2-SNAPSHOT build 201310081705. Server: Added the new TranslatedTopicSecondOrderData table to store the additional xml for each TranslatedTopic. Updated the REST Factories and entity model to hold the new parameter. When a new TranslatedTopicData is created it will attempt to get the previous TranslatedTopicData's Additional XML and insert it into the newly created TranslatedTopicData. UI: TranslatedTopics now have the ability to display additional xml and have it merged into the rendered view. This can also be turned off by unchecking the "Merge Additional XML" checkbox. Builder: The builder has been updated to merge the additional content into the original XML. This is done by using the same logic that publican uses. CLI: Added the "add-revision" command to provide a fairly similar user experience to publican. This command will add a revision to a Content Specifications revision history. The command has the following options: --date <DATE> The date for the revision entry. --email <EMAIL> The email of the author for the revision entry. --firstname <FIRSTNAME> The firstname of the author for the revision entry. --lang <LOCALE> What locale the revision should be added to. --rev-message <MESSAGE> Add a message for the revision entry. --revnumber <REVNUMBER> The revnumber for the revision entry. --surname <SURNAME> The surname of the author for the revision entry. The "firstname", "surname", "email" and "rev-message" options are all mandatory parameters. "rev-message" can be specified multiple times to include multiple revision messages. The "firstname", "surname" and "email" can be set in the [defaults] section of csprocessor.ini to save having to enter those parameters each time. eg: [defaults] firstname=Lee surname=Newson email=lnewson
Fixed in 1.2-SNAPSHOT build 201310161533 The add-revision command will now add to the proper revision history entry instead of just the latest version. I also fixed an issue where it wasn't taking into account revision numbers with leading zeros ie "1.2-01"
When adding a localised revision message to a content spec, the message will appear: a. Against the specific revision of the revision history topic if one is specified in the content spec pushed to Zanata. For example, if the spec includes "Revision History = [1234 rev:9876]", any localised revision history messages will be added to revision 9876 of topic 1234. b. Against the latest revision of the revision history topic to be pushed into Zanata. For example, of the content specification includes "Revision History = [1234]", and revision 9999 was the latest revision of topic 1234 to be pushed to Zanata, the localised revision history message would be added to revision 9999 of topic 1234.
Just realised when I was talking to Matt that I forgot to mention in comment #14 that when builds are done an editor link for the additional XML is also added to the topics.