views:

129

answers:

1

I've read somewhere (I dont recall exactly where) that Git (and probably any other good DCVS) is an excellent tool when you're translating some text.

I'm trying to figure out a workflow for this scenario, and the best I could get was something like:

  1. Use your own branch. Translate files as usual, commit as needed.
  2. When there are changes upstream, merge them with your own branch.
  3. Resolve the merge problems (those should be everywhere a text was added, since you probably translated all the text)

So, in the files marked by the merge, it should be easy to find out (with >>> markings) where the changes are. Anyway, I think I may be missing the point, and I'm even not sure about what happens when a change is found in a part of the file that was previously changed, and you previously marked as merged.

Thanks.

Edit:Ok, someone pointed out (in the comments) that the question itself wasn't clear. So specifically, what I want to know is if this workflow is correct, or if there is one (or more) way to do it better.

+2  A: 

Well, I have one app that I've been maintaining two branches to localize it like that, and let me tell you, it stops being fun really soon.

One thing that helps a bit is containing the localizable strings to their own lines, to ensure you don't get unnecessary conflicts.

But in the end, the real way to go is to have some m17n framework and have separate files for localization. Branching around doesn't quite scale.

kch
The case is that I already have the localizable strings in their own lines (even files), and I'm still not sure about what would happen with the added text after many merges.
Doppelganger
I my case I'm the sole developer on the localization branches, so I get to rebase instead of merging. Rebasing keeps things simpler.
kch