Re: [git for translators] How to always generate conflicts for merges?
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>:
Show 59 quoted lines
> 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".