I agree this is the usability problem and it makes translators' work significantly harder. I was facing this recently while working on the Czech lang pack, too.
The easiest way for me would probably be to add a new option into the "Compare strings at two branches" stage tool. It would look like this:
If a difference is detected:
a) Stage both versions
b) Stage the more recent string into the other branch
Using the b) option, the translator could perform the following operation:
- translate on, let us say, 2.1 branch - adding new strings and modifying the current ones
- the stage is committed
- use the "Merge strings from another branch" tool to merge new translations to 2.2 branch
- the stage now contains merge result and must be committed again
- use the "Compare strings at two branches" tool (with the new option set to b) to detect differences between 2.1 and 2.2. The recent modifications in 2.1 would be detected. But instead of staging both versions (as it does now), it would just stage the more recent version (which will probably be the change on 2.1) to the other branch (which would be 2.2 in this case).
- the stage now contains the updates and the third commit makes the branches synced
Although it still requires more steps to do manually, it would help.
Additionally, there might be a button at the stage screen called "Propagate changes to other branches" (with versions selector next to it). using it, all currently staged modifications would be applied to all selected branches. This would be handy when the translators accepts someone's contribution and wants it to be applied to all branches, not just the one suggested by the contributor. Such a button would actually prevent many differences between branches to even appear as the change would be applied to all selected branches. The workflow would be like:
- translate on, let us say, 2.1 branch - adding new strings and modifying the current ones
- on the stage screen, before the stage is committed, the versions 2.0, 2.1 and 2.2 are selected and the replication button is pressed (hey - the "replicator" is a cool name for this feature )
- the stage screen would be reloaded and it now contains the changes applied to all three branches
- the single commit would store the changes persistently
I like this. What others think?