mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Sergey Lukashev <>
To: Ilya Kantor <>, Junio C Hamano <>
Cc: "" <>
Subject: Re: [git for translators] How to always generate conflicts for merges?
Date: Fri, 26 Jul 2019 23:40:51 +0300	[thread overview]
Message-ID: <> (raw)

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" <>:
> Hi Junio,
> There's a repo for each language, with the same file structure.
> For example, English version (upstream):
> Japanese:
> 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
>>  On 25 Jul 2019, at 19:37, Junio C Hamano <> wrote:
>>  Ilya Kantor <> 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".

      reply	other threads:[~2019-07-26 20:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 13:42 [git for translators] How to always generate conflicts for merges? Ilya Kantor
2019-07-25 14:25 ` Santiago Torres Arias
2019-07-25 16:37 ` Junio C Hamano
2019-07-25 17:42   ` Ilya Kantor
2019-07-26 20:40     ` Sergey Lukashev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).