Hi everyone! As I see it, in Junio's approach you more likely to have a translation and original out of sync because you have to figure out whether the changes in the original are actually reflected in the translation, which could be a tedious thing to do again and again. In the approach that Ilya uses you HAVE TO manually fix just what has changed: you will have a content in the original language in places not yet translated. This approach abuses git a bit and, as I understand, works because all the repos with the translations were probably forked from the original repo so they are NOT unrelated. As the answer to the original problem I would ask if it really matters whether you have a conflict or not. Just fix conflicts, commit and review all the new stuff that was added in the commits just merged and fix it too. The process is still human-controlled: if you do forget to translate something, it will be left untraslated and is likely to be spotted soon. You want to have a conflict where there ain't one (a new content that does not exist in your translation). A conflict is when something has changed in different wayS since a common ancestor. 25.07.2019, 20:42, "Ilya Kantor" <iliakan@xxxxxxxxx>: > Hi Junio, > > There's a repo for each language, with the same file structure. > > For example, English version (upstream): > https://github.com/javascript-tutorial/en.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md > > Japanese: > https://github.com/javascript-tutorial/ja.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md > > As English version is updated, changes need to be delivered to translations. > That's done with "git pull upstream master" from translations. > > As the text structure (paragraphs) is the same, usually merges give conflicts exactly in the places where English version changed. > > Sometimes though, e.g. when a new chapter is added to upstream, the merge just goes through "successfully". > > That's what I'd like to avoid, as all changes need to be human-controlled. > > --- > Ilya Kantor > https://javascript.info > >> On 25 Jul 2019, at 19:37, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Ilya Kantor <iliakan@xxxxxxxxx> writes: >> >>> We're using Git to manage translations of an open-source book, and >>> most of time it works well. But there's also a problem. >>> >>> When we pull changes from upstream (English) to translation >>> (e.g. Japanese), git auto-merges them. >>> >>> Sometimes there conflicts, but not all the time. >>> >>> For example, when a new file is added to English, it just gets >>> auto-merged into Japanese. But all new changes must be >>> human-controlled, translated. >>> >>> Is there a way to force git always generate a conflict, even if >>> changes could be auto-merged? >> >> I am not sure what the workflow here and if it makes sense. When >> you have a file, "chapter47.txt", whose original is in English, the >> translation projects (there are N of them, one for each language) >> will have their own "chapter47.txt" that has translated text in the >> same place? It looks to me that, working that way, the project for >> translating into e.g. Japanese have no way to keep any of the >> original English version, in which case why are you even "merging" >> the English version in the first place? >> >> I would have understood if the original "chapter47.txt" is translated >> into "chapter47_ja.txt" and friends, like "chapter47_fr.txt", all of >> which sit next to the original "chapter47.txt". Then merging an >> updated version of the original from time to time would make perfect >> sense to me---that would give you a way to see what changed in the >> original (e.g. "git show --first-parent -m -p master chapter47.txt") >> to guide you find the places you would need to make corresponding >> changes to the variant of your language, e.g. "chapter47_??.txt".
