Re: [git for translators] How to always generate conflicts for merges?

[Sergey Lukashev <lukashev.s@ya.ru>]

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@gmail.com>:
> 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@pobox.com> wrote:
>>
>>  Ilya Kantor <iliakan@gmail.com> 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".