[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] [msgmerge] no-fuzzy-matching (enhancement rather than bug,

From: Marc Perrin
Subject: [bug-gettext] [msgmerge] no-fuzzy-matching (enhancement rather than bug, I guess)
Date: Wed, 14 Sep 2016 14:09:15 +0000



I find the documentation for this option a bit lacking (no word about msgctxt), but more importantly I think this option should be somehow split (msgid part vs. msgctxt part).


I’ve attached a very simple test case (files in, out, and commands).


This test case basically contains 4 different cases, and you can see that -N is a very strict mode (as soon as msgctxt or msgid differs, existing translation is not used) while the standard mode is very loose (existing translation always used (as fuzzy – except in the trivial case))

Here’s something I can’t do, with or without -N option:

-          I want to use fuzzy matching indeed, so that if my source text is slightly tweaked, the translator continues to sees its existing translation, but marked as fuzzy (i.e. “for review”)

-          but I don’t want to “auto-translate” i.e. new msgctxt => should not use existing translation.

I admit I see that from a point-of-view where msgctxt is an ID rather than a true context indication, so what is frustrating here is that msgmerge performs at once two operations that are quite different concepts in the CAT world (“refresh” (when ID remains identical and source changes) vs. ”auto-translate” (new ID)), and I’ve got no separate control over those two operations.


(Also, it would be nice to have an option to control the fuzzy threshold, but maybe it’s a bit too abstract / goes against design decisions… ?)









Attachment: test_case.zip
Description: test_case.zip

reply via email to

[Prev in Thread] Current Thread [Next in Thread]