[this RFE addresses "freezing" the XML against which a translation applies; splits this from RFE #708278] Description of problem: When documents are not branched carefully, it's very easy for translations to fall out of step with published books, making it very difficult to correct the translation of one particular version of a document without pulling in all the subsequent changes to the document. This can be solved with version control; but not all documentation projects use a version control system, and not all authors or translators are skilled in its use even when it exists. It would be good if Publican itself could "freeze" a version of the original language against which translations are applied.
How should this "freezing" interact with updating the POT files? 1: Should update_pot freeze the XML first then update the pot files? 2: Should there be an extra action to "freeze" the files then update_pot act on that freeze instead of the XML files? They offer different work flows, option 1 means less work in general, option 2 allows recreating the POT files from a known stable version, offering greater protection from POT corruption or loss.
(In reply to comment #1) > How should this "freezing" interact with updating the POT files? > > 1: Should update_pot freeze the XML first then update the pot files? > > 2: Should there be an extra action to "freeze" the files then update_pot act > on that freeze instead of the XML files? > > They offer different work flows, option 1 means less work in general, option > 2 allows recreating the POT files from a known stable version, offering > greater protection from POT corruption or loss. I think that the slight workflow change required by 2 is well worth it from the point of view of being able to recreate damaged or missing POT files without changing the "frozen" source XML. Any scenarios more complex than just recreating POT and PO files from the point at which they were ready for translation are VCS territory and beyond the scope of this bug.
HSS-QE has reviewed and declined this request. QE for this bug will be handled by IED.
$ publican trans_drop --help trans_drop Snapshot the source language for use in translation. Options: --help Display help message --config=s Use a nonstandard config file --common_config=s Override path to Common_Config directory --common_content=s Override path to Common_Content directory --nocolours Disable ANSI colourisation of logging. --quiet Disable all logging. --brand_dir=s Directory to source brand files from. To ssh://git.fedorahosted.org/git/publican.git 6ea5c0d..7a48a51 HEAD -> devel
I hope this is enough to verify the bug. I'll be moving to to verified, but I'll also NEED_INFO the requester, to make sure I understand the feature. publican-3.1.5-0.fc18.t62.noarch [thildred@thildred Virt_GSG]$ publican trans_drop [thildred@thildred Virt_GSG]$ ls beta.cfg en-US publican.cfg trans_drop zanata.xml [thildred@thildred Virt_GSG]$ diff en-US/Revision_History.xml trans_drop/Revision_History.xml [thildred@thildred Virt_GSG]$ [thildred@thildred Virt_GSG]$ diff en-US/ trans_drop/ Common subdirectories: en-US/images and trans_drop/images [thildred@thildred Virt_GSG]$ I think that the presence of a trans_drop directory, containing contents that match what is in the en-US directory at a moment in time is enough to verify the addition of this feature. Rudi, can you let me know if I need to do anything more to verify?
The fix for this bug has been shipped in publican 3.2.0