GitHub user glaterza edited a comment on the discussion: Proposal: a
translation guide, with shared principles and per-language conventions
Both PRs are up, and the drift has its own issue.
**#44395 — the `msgcat` fix.** Option 1, as you suggested: the one-line repair
(`--sort-output` plus `|| exit 1`) in the first commit, and the 2209-line
reformat as its own second commit so it reads as tool output rather than as
part of the change.
Every figure in that PR's body is re-verified against current master rather
than carried over from the measurements above: 473 wrapped entries → 38, 5118
messages before and after, identical msgid set, zero entries with a changed
extracted comment or flag, and `msgfmt --check-format` clean.
Worth noting, since it is the argument for the reformat commit existing at all:
within hours of opening, #44395 picked up a conflict because #44091 touched
`messages.pot`. I have rebased and re-normalized against current master, and
re-verified every figure above on the new base. But that is exactly the "2209
lines land on whoever next runs `babel_update.sh`" case, and it will recur for
as long as the template is published unnormalized.
**#44397 — the `--add-comments=i18n:` change.** Independent of #44395, and the
two can land in either order: they change different parts of `babel_update.sh`,
and the four `#. i18n:` comments apply to the template exactly as committed.
Whichever merges second wants `babel_update.sh` re-run to regenerate the
template — tool output, not a hand edit.
Verified end to end: the four comments extract from Python, TS and TSX and
reach all 30 catalogs, four per catalog, with untagged comments next to a
translatable string correctly not published.
One correction to carry forward: a full run stamps **24** `do-not-translate`
markers, not the 27 I mentioned earlier. `pivoted_xlsx`, `step-after` and
`step-before` are still listed in `do-not-translate.txt` but are no longer
extractable from source. That belongs to the drift below, not to either PR.
**The template drift — #44403**, as you invited.
I re-measured rather than reusing the figure above: **428 strings in source but
missing from the template, 109 in the template but gone from source**, at
`c426186a2e`. Raw 429/110, with whitespace-only variants excluded by the same
method as before. It was 416/109 when I posted that table — the template has
not been regenerated since 2026-09-02, so the gap widens with every PR that
adds a translatable string. The issue writes up why CI does not catch it, and
sketches the options; happy to open the PR for whichever direction you prefer.
A docs PR with the Translation Guide follows once #44397 lands, since it links
a heading that PR adds to `howtos.md`.
---
**A question rather than a finding**, because I cannot tell whether it is
deliberate.
`superset-frontend/scripts/po2json.sh` passes `--fuzzy` when building the
frontend language packs, so entries flagged `#, fuzzy` are published to the UI.
The Python side does the opposite: `pybabel compile` drops fuzzy entries unless
explicitly told to keep them. Same catalogs, opposite policies.
On master that covers a lot of ground — 26 of the 30 catalogs contain fuzzy
entries, and **34,617 of them carry a non-empty translation**, so they render
rather than falling back to English. Some catalogs are almost entirely in that
state: `th` 4863 of 5107 messages, `fi` 4862, `ko` 4603. It is long-standing
rather than new; Thai was already at 4823 before this year's backfills.
Fuzzy means machine-matched and unreviewed, not necessarily wrong, and the
entries I sampled in Thai read fine. But the failure mode is real: in 6.1.0 the
Italian connection form renders `Port` as *Importa* ("Import"), `Password` as
*Porta Broker* ("Broker Port"), `Username` as *Ricerca Query*, and `SSL` as
*CSS*, all four flagged fuzzy. Italian has since been cleaned to zero on master.
The flag was added in #34118, whose subject is a frontend crash fix, with no
note on the translation implications — which is why I am asking rather than
filing. If publishing fuzzy entries is intended, then marking a translation
"needs review" has no bearing on what users see, and it would be worth saying
so somewhere. If it is not, removing the flag would revert roughly 34k strings
to English across 26 languages, which is a call for you rather than a patch
from me.
GitHub link:
https://github.com/apache/superset/discussions/43562#discussioncomment-18488991
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
