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

[Chusslove Illich]

>> [: 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.

>> [: Chusslove Illich :]
>> 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.
>
> [: Ineiev :]
> 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.

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.

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.

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

>> [: 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?

> [: 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.

-- 
Chusslove Illich (Часлав Илић)

signature.asc
Description: This is a digitally signed message part.