Bug 887707

Summary: RFE: Freeze XML that on which a particular translation is based.
Product: [Community] Publican Reporter: Ruediger Landmann <rlandman>
Component: publicanAssignee: Jeff Fearn 🐞 <jfearn>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.0CC: aigao, ismael, mmcallis, pkovar, publican-list, rlandman+disabled, rlandman, thildred, ykatabam
Target Milestone: 3.2Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 3.2.0 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 708278 Environment:
Last Closed: 2013-08-09 04:47:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ruediger Landmann 2012-12-17 03:55:17 UTC
[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-17 04:36:47 UTC
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 05:47:52 UTC
(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-12 01:57:36 UTC
HSS-QE has reviewed and declined this request. QE for this bug will be handled by IED.

Comment 4 Jeff Fearn 🐞 2013-07-12 03:32:52 UTC
$ 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 09:59:43 UTC
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 04:47:35 UTC
The fix for this bug has been shipped in publican 3.2.0