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

[Ineiev]

On 11/01/2011 01:55 PM, Chusslove Illich wrote:
>>> [: Chusslove Illich :]
>>> 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.
>> [: Ineiev :]
>> I think I don't understand this very well.
>
> I meant that additional set of fields would make less messages fit on screen
> at once (which is important for context), and even single longer messages
> may not fit on screen entirely.

I see; it does make sense.

> Thinking a bit more, if the diff would be embedded into previous fields,
> that would actually make it more backward compatible until tools are
> updated. Because then, at worst, editor's built-in diffing would display
> wrong result. With new set of fields, tools could go wrong from wrongly
> rearranging comments, not removing diff comments on unfuzzing, crashing, to
> silently writing invalid file.

Good point.

> Thinking yet a bit more, in fact we shouldn't think about backward
> compatibility at all, so long as the new functionality is optional. For
> example, when --previous option was added, in various projects i18n/l10n
> maintainers simply postponed its use until they judged translation tools to
> be sufficiently ready. That would be the case here as well.

In other words, it is going to be a very long term result anyway.

Are there any estimates of whether gettext maintainers are likely to accept
patches for the feature?

> (If diff format is fixed, also msgattrib could be updated to remove or
> undiff to previous, e.g. with --undiff-previous.)

Sure.

>>> [: Chusslove Illich :]
>>> 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.
>> [: Ineiev :]
>> 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.
>
> True, although if the diff format is fixed, it should be rather trivial to
> undiff, no?

True.

>> [: Ineiev :]
>> I see; we should either use another program (patch wdiff?) or admit that
>> msgmerge can't rely on those diffs.
>
> I personally would hope that there exists a diffing library/code which could
> be linked/copied into Gettext, such that the only thing remaining is to
> convert its internal diff representation into the textual diff according to
> agreed-upon format. So that an external process is eliminated.

I'm not aware of such code... the nearest candidate I see is GNU diffutils,
and I can't tell right now how hard it would be to adopt it for gettext.