Typically the main branch would be English, and everything else would follow from that. A French (say) translator would want to see the EN -> EN' diff to work out what corresponding FR -> FR' change to make in their branch.
Show this thread
If I had a Git repo containing text, and wanted to maintain separate branches for different language versions of that same text, is there a good workflow/process which would require any change to the main branch to be reviewed (i.e. translated) when it's merged to another branch?
-
-
-
Is this even a good idea? (Regardless of whether it is or not, I'd be interested to hear answers to the first question!)
Show this thread
End of conversation
New conversation -
-
-
Do the translators know how to use Git? I mean, are answers with git commands sufficient? Or are you looking for how to incorporate this workflow into existing translation apps?
-
There is the command `git difftool --dir-diff master^ master` (or any two commits) which will drop you into your favourite diff-viewer. This will show all the changes in English text. But I don't know how to correlate that to the translation branch.
End of conversation
New conversation -
-
-
The power of branching a file is the relative comparison of the same objects, and deltas. Given the entire contents would be fundamentally different, it is difficult to see how a delta in the English version would help the French version (which would need a non-equivalent delta.)
-
It would still need to be a very manual process, but knowing where the changes are would be a start.
End of conversation
New conversation -
-
-
Not sure if my answers helps. In one of the projects that required constant translation+adjustments, I had a google spreadsheet that I would share with anyone wanting to change it. A script that would write all the translations to files. The changes could go into a commit.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I would not use specific branches for languages. I would use subfolders to store the translation in each language. The translators can use their own working branches to catch up with the En text. Advances in the En text may not have a 1 to 1 relation with other translation
-
... advances. I don't think you should impose this rule. Git offers the advantage that they would see the diffs in the En text. You could do this with a word document that has track changes on and still use git. Whenever you start making changes you'd accept all current changes.
- Show replies
New conversation -
-
-
I would create a new org and have a different repo for each language as this way what’s available is more visible with normal tools
-
I should have explained a bit more context that I'm writing my own tool which will put some additional constraints on the structure of the text, while the tool might also be able to help with managing the translations...
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.