Bug 887707
Summary: | RFE: Freeze XML that on which a particular translation is based. | ||
---|---|---|---|
Product: | [Community] Publican | Reporter: | Ruediger Landmann <rlandman> |
Component: | publican | Assignee: | Jeff Fearn 🐞 <jfearn> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.0 | CC: | aigao, ismael, mmcallis, pkovar, publican-list, rlandman+disabled, rlandman, thildred, ykatabam |
Target Milestone: | 3.2 | Keywords: | 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
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 |