When running 'zanata pull' to update po files for a project, Zanata's current practice is to overwrite the local po files rather than merely download new and updated po files and merge them with the local ones. Unfortunately, with a huge book like the Fedora Installation Guide, the 'zanata pull' command can take hours to complete. I typically have to set it to download the files overnight. 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. The current method means that a huge amount of time can be taken up downloading files that are already held locally and are unchanged. If a merge facility is possible, that would be a great help for larger projects.
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.