#1259 Compute PO fuzzies real match %

[Jean-Christophe Helary]

When we have the original PO source for a fuzzy (if the PO have been merged with the --previous flag, the previous message will be given with a #| comment.

• https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html (7.1.5 Operation modifiers)
• http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html (2.5.1 Fuzzy Messages)

That message string should be used to compute a real fuzzy match instead of using the PO default % (80% at the time of this writting, 60% if RFE#1258 is implemented).

[Didier Briel]

Implemented in SVN (/trunk).

Real fuzzy matches are loaded as an "external TMX" (with the name of the source file).
They are removed from the target because, once msgstr is modified, the fuzzy msgid (#| msgid) becomes meaningless.

Unless segments contain a single sentence, real fuzzy matches are only loaded if the project is in paragraph mode. This is consistent with [#621]. If this RFE is implemented, real fuzzy matches should behave accordingly.

False fuzzies (at 60%) are still loaded as before.
As of RFE [#1323], false fuzzies are not loaded anymore when there is a real one.

Didier

[Didier Briel]

Implemented in the released version 4.1.2 of OmegaT.

Didier

[Jean-Christophe Helary]

It appears that for such fuzzies, the "standard" fuzzy is still displayed with a 60% and the "new" fuzzy also appears with its real percentage. Which ends up being confusing since sometimes the new fussy's ranking is lower and does not appear right away.

For ex:
http://translationproject.org/PO-files/fr/util-linux-2.30-rc2.fr.po

#: disk-utils/fdisk.c:746
#, fuzzy, c-format
#| msgid "It is strongly recommended to wipe the device with wipefs(8), in order to avoid possible collisions."
msgid "The old %s signature may remain on the device. It is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order to avoid possible collisions."
msgstr "Il est fortement recommandé de nettoyer le périphérique avec wipefs(8), pour prévenir les problèmes de collision."

is displayed the following way in OmegaT:

1. [参考] The old %s signature may remain on the device. It is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order to avoid possible collisions.
   Il est fortement recommandé de nettoyer le périphérique avec wipefs(8), pour prévenir les problèmes de collision.
   <60/60/60% util-linux-2.30-rc2.fr.po>

2. It is strongly recommended to wipe the device with wipefs(8), in order to avoid possible collisions.
   Il est fortement recommandé de nettoyer le périphérique avec wipefs(8), pour prévenir les problèmes de collision.
   <50/51/53% util-linux-2.30-rc2.fr.po （他1分節）>

Would it be possible to only keep the new fuzzy in such cases?

[Didier Briel]

It appears that for such fuzzies, the "standard" fuzzy is still displayed with a 60% and the "new" fuzzy also appears with its real percentage.

This was documented on 2017-05-02: "false False fuzzies (at 60%) are still loaded as before."

Would it be possible to only keep the new fuzzy in such cases?

Do you mean, when the real fuzzy has a lower percentage than the false one?

Didier

[Jean-Christophe Helary]

On Jun 26, 2017, at 22:23, Didier Briel didierbr@users.sf.net wrote:

It appears that for such fuzzies, the "standard" fuzzy is still displayed with a 60% and the "new" fuzzy also appears with its real percentage.

This was documented on 2017-05-02: "false False fuzzies (at 60%) are still loaded as before."

I missed that. Sorry.

Would it be possible to only keep the new fuzzy in such cases?

Do you mean, when the real fuzzy has a lower percentage than the false one?

No. In either case since the real fussy is displayed as a normal fuzzy (source & target) while the "fake" fuzzy still displays a source different from the target. It is only confusing to see them both regardless of the %.

Jean-Christophe

[Didier Briel]

So, you mean do not load the fake fuzzy when there is a real one during parsing?
(There could still be cases where you can have a fake fuzzy from another segment.)

Didier

[Jean-Christophe Helary]

On Jun 26, 2017, at 23:34, Didier Briel didierbr@users.sf.net wrote:

So, you mean do not load the fake fuzzy when there is a real one during parsing?

Yes.

(There could still be cases where you can have a fake fuzzy from another segment.)

That was the case here (I removed fuzzy #2 when I pasted here because it was not relevant for the discussion).

On a side note, I wonder if gettext's 60% is really equivalent to OmegaT's 60%...

Jean-Christophe

[Didier Briel]

So, you mean do not load the fake fuzzy when there is a real one during parsing?

You can create a new RFE for that.

On a side note, I wonder if gettext's 60% is really equivalent to OmegaT's 60%...

I don't really think so, but I think 60% is a reasonable value.

Didier

[Jean-Christophe Helary]

On Jun 27, 2017, at 0:16, Didier Briel didierbr@users.sf.net wrote:

So, you mean do not load the fake fuzzy when there is a real one during parsing?

You can create a new RFE for that.

I will.

Jean-Christophe