[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] msgmerge --diff-to-previous (feature request)
From: |
Ineiev |
Subject: |
Re: [bug-gettext] msgmerge --diff-to-previous (feature request) |
Date: |
Mon, 31 Oct 2011 17:02:51 +0300 |
User-agent: |
Thunderbird 2.0.0.24 (X11/20100623) |
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.