GitHub user glaterza added a comment to 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, 5117 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]
