Bug 895366
Summary: | RFE: ability to merge when pulling translations | ||
---|---|---|---|
Product: | [Retired] Zanata | Reporter: | Jack Reed <jreed> |
Component: | Component-Maven | Assignee: | Isaac Rooskov <irooskov> |
Status: | CLOSED WONTFIX | QA Contact: | Zanata-QA Mailling List <zanata-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | dchen, pbokoc, sflaniga, yshao, zanata-bugs |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-03-18 05:08:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jack Reed
2013-01-15 06:29:19 UTC
The new ETag support in Zanata 2.1, together with the upcoming Java client which caches based on ETags, should speed up repeated pulls to some extent.
> This would be problematic in situations where a user wants to push the latest translation files ASAP, because they have to update their local repo first.
When you push your local translation files, by default the server will auto-merge your changes with what's on the server.
In other words, you don't have to update your local repo first. In fact, you should push before pulling, or you may lose your local changes (until such time as we implement this RFE).
Note that client-side merging is likely to speed anything up, but the cache feature should.
Sorry, I should have made my use case clearer: I'm a docs maintainer rather than a translator, so I don't make any local updates to translation files. I need to pull the latest translations for the current branch of a Fedora release when I'm creating a new branch in git for the latest release, generate new pot and po files, and then push the combination of existing translations and new pot and po files to Zanata so translation can commence for the new release. So pulling is a required step to preserve translations but can be a roadblock with a big project. In fact, the pull stalled overnight so I've had to start again. Okay, thanks for the clarification. When creating a new branch, you could skip the step "pull the latest translations for the current branch of a Fedora release" and also "push the ... existing translations / po files". Instead, just push the new source/pot files to the new version in Zanata, and let CopyTrans copy any reusable translations from the old branch into the new one. I think CopyTrans should happen automatically as each document is uploaded (you can tell by the translation stats), but if not you can trigger it from the project version page in Zanata. If you need to build the translated documentation, I would do the pull last, not first. (By the way, CopyTrans should be quite a bit faster in Zanata 2.1 than in 2.0.) As docs maintainer, the idea is that you should not have to push any translations into Zanata, only source content. As the use cases can be covered by the work flow mentioned in comment #4, I took the liberty to close the bug as WONTFIX. |