[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] let's release a new version

From: Mikko Rantalainen
Subject: Re: [bug-gettext] let's release a new version
Date: Fri, 26 Oct 2018 09:23:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Bruno Haible (2018-10-25 16:05 Europe/Helsinki):
> Mikko Rantalainen wrote:
>> Is there any change to include real 3 way merge to next release?
>> ...
>> See also:
>> https://lists.gnu.org/archive/html/bug-gettext/2014-07/msg00007.html
>> The original repo seems to have vanished. I published my copy of the
>> referenced repo to github:
>> https://github.com/mikkorantalainen/gettext-3-way-merge
> Thanks for mentioning this. I realize the interaction between git
> and the po/ directory is a big issue. We plan to resolve this issue
> in a different way; a 3-way-merge for PO files will then be unnecessary.

Could you elaborate a bit more about your strategy for this? How do you
plan to resolve the issue without 3-way-merge?

As I see it, if you store .po files in any version control system that
supports branches, sooner or later you'll hit the situation where
version control system sees three different versions of the same file
(base, remote and local version) and version control system needs some
automated tool to resolve the situation. This is the thing that needs
the 3-way-merge and the only input available are three different
versions of a single .po file.

This is not strictly about git. Git just happens to be the first widely
used version control system where people really do merges often enough
to hit the problem. In theory, CVS and SVN did support merging but the
merge tooling was so bad that nobody noticed that .po files had a bit
different problems than any other file type because every file was hard
to merge.

Note that 3-way-merge would be a nice tool to have regardless of git or
version control software because it would allow work of multiple
translators to be easily combined without needing human input for
translations that do not have conflicts between different translators.
And one does not need generic n-way-merge because applying 3-way-merge
iteratively is enough. However, having just msgmerge and msgcat is not


reply via email to

[Prev in Thread] Current Thread [Next in Thread]