Bug 887707 - RFE: Freeze XML that on which a particular translation is based.
RFE: Freeze XML that on which a particular translation is based.
Status: CLOSED CURRENTRELEASE
Product: Publican
Classification: Community
Component: publican (Show other bugs)
3.0
Unspecified Unspecified
unspecified Severity unspecified
: 3.2
: ---
Assigned To: Jeff Fearn
tools-bugs
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-16 22:55 EST by Ruediger Landmann
Modified: 2013-08-09 00:47 EDT (History)
9 users (show)

See Also:
Fixed In Version: 3.2.0
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 708278
Environment:
Last Closed: 2013-08-09 00:47:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ruediger Landmann 2012-12-16 22:55:17 EST
[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.
Comment 1 Jeff Fearn 2012-12-16 23:36:47 EST
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.
Comment 2 Ruediger Landmann 2012-12-18 00:47:52 EST
(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.
Comment 3 HSS Product Manager 2013-07-11 21:57:36 EDT
HSS-QE has reviewed and declined this request. QE for this bug will be handled by IED.
Comment 4 Jeff Fearn 2013-07-11 23:32:52 EDT
$ 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
Comment 5 Tim Hildred 2013-07-23 05:59:43 EDT
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?
Comment 6 Jeff Fearn 2013-08-09 00:47:35 EDT
The fix for this bug has been shipped in publican 3.2.0

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