Re: [bug-gettext] msgmerge --diff-to-previous (feature request)

[Ineiev]

On 10/30/2011 10:17 PM, Chusslove Illich wrote:
> > > [: Ineiev :]
> > > I may not understand all usage scenarios, but there is no similar
> > > "previous" flag, is it?
>
> The idea here was that diffs go directly into existing #| fields, so a flag
> (or some other indicator) would be necessary to tell tools that previous
> fields now contain diffs.

I see.

> I would favor this solution, because the scenario
> with both #| and #! fields is too much clutter, especially when editing the
> PO file in a text editor.

I think I don't understand this very well.

> On the negative side, this would have less
> backward compatibility, e.g. for dedicated PO editors that automatically
> perform diffing. But they should be easily patchable.

I'd prefer a more compatible way: it wouldn't be practical to suggest all
our translators using a patched (or even too new) version of their editors.

> Either way -- using another set of fields or embedding into previous
> fields -- it has to be done carefully with respect to subsequent mergings.

Sure.

> If clean previous fields are not present but diffed previous fields are,
> msgmerge should undiff them and use that as previous fields when fuzzy
> matching.

It would be great, but I don't think this is really mandatory: when there
are no previous fields, msgmerge might just reject the item.

> I think that default wdiff-format delimiter for deleted text
...
> which has one extra space after -] and no indication of trailing space
> addition.

I see; we should either use another program (patch wdiff?) or admit that
msgmerge can't rely on those diffs.

> Therefore rather than leaving the diff format upon an arbitrary command, it
> should be fixed and well defined. This would be benefitial both for
> translators and especially for tools (e.g. PO syntax highlighting in text
> editors). Diffs in PO context should be such that it is possible to
> unambiguosly recover old and new text (like in the two examples above, of
> dedicated PO editor and subsequent merge). This implies that an escaping
> mechanism for diff delimiters should be present as well. I have defined one
> such diff format, documented here:
> http://pology.nedohodnik.net/doc/user/en_US/ch-diffpatch.html#sec-dpfrmembstr
> Worked nicely so far.

Looks very interesting.

> What could be variable is the diffing algorithm. For example, I like that
> word and non-word segments are diffed differently, such that words are
> atomic, but non-words are diffed by character. If an external command were
> used, its output should be parsed internally into the canonical diff format.

Or rather its output should be in the canonical diff format.

> (But note that calling an external command for each message would be
> prohibitively expensive in large-scale merges.)

Of course, it would be much faster if it were implemented internally;
it is not likely to fit into a small patch, though.