(superset) 01/01: fix(i18n): stop fuzzy-matching new strings so adding one doesn't fail babel-extract

[ru...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rusackas pushed a commit to branch fix/i18n-no-fuzzy-matching
in repository https://gitbox.apache.org/repos/asf/superset.git

commit eb9eed42f378cb91563c05f0ab609caef29e25c9
Author: Evan <ev...@preset.io>
AuthorDate: Tue Jun 9 09:55:33 2026 -0700

    fix(i18n): stop fuzzy-matching new strings so adding one doesn't fail babel-extract
    
    babel_update.sh ran `pybabel update --ignore-obsolete` with fuzzy matching
    left on (the default). Adding a new translatable string therefore made Babel
    guess a "close" existing translation and mark it `#, fuzzy` in every language
    catalog. check_translation_regression.py keys on an increase in fuzzy entries
    (so it can ignore intentional deletions), so those spurious guesses tripped the
    babel-extract check on essentially every PR that merely added a string.
    
    Pass `--no-fuzzy-matching` so new/renamed strings land as cleanly untranslated
    (empty msgstr) instead of as a wrong fuzzy guess. This both fixes the false
    positive and improves catalog quality — the fuzzy matcher was producing
    inaccurate guesses (e.g. a new "valuename" string mapped onto an unrelated
    "table name" translation). The check still guards against `#, fuzzy` entries
    introduced another way (e.g. a committed .po edit). Docstring updated to match.
    
    Co-Authored-By: Claude Opus 4.8 <no...@anthropic.com>
---
 scripts/translations/babel_update.sh               | 13 +++++++++-
 .../translations/check_translation_regression.py   | 29 +++++++++++-----------
 2 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/scripts/translations/babel_update.sh b/scripts/translations/babel_update.sh
index 73c0ecfacc1..78689d38a5a 100755
--- a/scripts/translations/babel_update.sh
+++ b/scripts/translations/babel_update.sh
@@ -55,10 +55,21 @@ msgcat --sort-by-msgid --no-wrap --no-location superset/translations/messages.po
 cat $LICENSE_TMP superset/translations/messages.pot > messages.pot.tmp \
   && mv messages.pot.tmp superset/translations/messages.pot
 
+# --no-fuzzy-matching: when a *new* source string is added, Babel's fuzzy
+# matcher otherwise guesses a "close" existing translation and marks it
+# `#, fuzzy` in every language catalog. Those guesses are (a) usually wrong
+# (e.g. a new "valuename" string mapped onto an unrelated "table name"
+# translation) and (b) counted by check_translation_regression.py as a
+# regression, so every PR that merely adds a translatable string failed the
+# babel-extract check. Disabling fuzzy matching means new strings land as
+# cleanly untranslated (empty msgstr) instead — accurate, and no spurious
+# regression. Renames likewise drop the stale translation rather than
+# stranding a wrong guess; the string is re-translated by the community.
 pybabel update \
   -i superset/translations/messages.pot \
   -d superset/translations \
-  --ignore-obsolete
+  --ignore-obsolete \
+  --no-fuzzy-matching
 
 # Chop off last blankline from po/pot files, see https://github.com/python-babel/babel/issues/799
 for file in $( find superset/translations/** );
diff --git a/scripts/translations/check_translation_regression.py b/scripts/translations/check_translation_regression.py
index de5ca05b288..51aa496a6d1 100755
--- a/scripts/translations/check_translation_regression.py
+++ b/scripts/translations/check_translation_regression.py
@@ -20,20 +20,21 @@ Check that source-code changes don't cause translation regressions.
 
 What counts as a regression
 ---------------------------
-A regression is an *existing translation that a source change invalidated* —
-i.e. a string was renamed/reworded so its committed translation no longer
-applies. ``babel_update.sh`` (``pybabel update --ignore-obsolete``) surfaces
-exactly these as **newly fuzzy** entries: the old translation is fuzzy-matched
-onto the new ``msgid`` and flagged ``#, fuzzy``.
-
-Crucially, *deleting* a translatable string is **not** a regression. With
-``--ignore-obsolete`` a removed string is dropped from the catalogs entirely;
-no fuzzy entry is created. So a PR that intentionally removes a string (e.g. a
-security fix that stops rendering a value) legitimately lowers the translated
-count without introducing any fuzzies, and must not be flagged. We therefore
-key the check on the **increase in fuzzy entries**, not on a drop in the
-translated count (a drop happens identically for a benign deletion and a real
-rename, so it cannot distinguish the two).
+A regression is an *existing translation that a source change invalidated*.
+The check keys on the **increase in fuzzy entries** rather than a drop in the
+translated count, because a count drop happens identically for a benign
+*deletion* and a real *rename*, so it cannot distinguish the two — whereas a
+``#, fuzzy`` marker unambiguously flags a stranded translation.
+
+Note ``babel_update.sh`` runs ``pybabel update`` with ``--no-fuzzy-matching``,
+so *adding* (or renaming) a source string does **not** auto-generate a fuzzy
+guess against an unrelated existing translation — new strings land as cleanly
+untranslated (empty ``msgstr``). This deliberately avoids the prior behaviour
+where *every* PR that merely added a translatable string tripped this check on
+spurious fuzzies. As a result the check now guards against ``#, fuzzy`` entries
+that arrive another way — e.g. a committed ``.po`` edit — rather than ones the
+update step synthesises. *Deleting* a string is still not a regression: with
+``--ignore-obsolete`` it is simply dropped and no fuzzy is created.
 
 Usage
 -----