aaiss0927 opened a new issue, #75772:
URL: https://github.com/apache/airflow/issues/75772
### Description
`breeze ui check-translation-completeness` computes the canonical
translation status for the 20 non-English UI locales — per-file
required/missing/unused keys, TODO-aware coverage, plural-suffix handling — but
renders it only as rich tables for a human terminal. I propose adding a
**`--json`** flag that prints the same report as machine-readable JSON,
following the pattern `breeze ci verify --json` established in #73241: a
boolean flag, console narration suppressed (or sent to stderr), nothing but the
JSON document on stdout, so piping to `jq` is always safe.
Illustrative shape, from a real run on `main` (2026-10-27); exact fields
open to discussion:
```json
{
"languages": {
"ko": {
"files": {
"dag.json": {
"required": 253, "translated": 235, "missing": 18, "todos": 0,
"unused": 13,
"coverage": 92.9,
"missing_keys": ["allMapIndexes", "callbacks.callback_one", "..."],
"unused_keys": ["execution.title", "loop.iteration", "..."]
},
"hitl.json": { "required": 37, "translated": 37, "missing": 0,
"coverage": 100.0 }
},
"totals": { "required": 1296, "translated": 1258, "missing": 38,
"todos": 0, "coverage": 97.1 }
}
},
"complete": false
}
```
What this intentionally does **not** change:
- **The default output** — with no flag, rendering stays byte-identical to
today.
- **Exit-code semantics** — per the original design in #55327, missing
translations deliberately do not fail the command; `--json` is pure output
formatting, and CI gating is out of scope here.
- **The existing flags** — `--language`, `--add-missing`, `--remove-unused`
all keep working and compose with `--json` (e.g. report the post-modification
state as JSON).
- **No new checks or policy** — the flag only re-serializes data the command
already computes.
The implementation is small: extract the aggregation that currently lives
inside the table-rendering loop into a `build_completeness_report()` function,
and feed either the existing rich renderer or `json.dumps` from the same dict
(roughly 120–180 lines including tests). I plan to open the PR shortly after
feedback on the field shape — working on it.
**Acceptance criteria**
- [ ] `--json` prints a single JSON document on stdout and nothing else
(narration suppressed or sent to stderr), so piping to `jq` is safe.
- [ ] With no flag, output stays byte-identical to today; exit-code
semantics unchanged.
- [ ] Composes with `--language`, `--add-missing`, `--remove-unused`
(reports the post-modification state).
- [ ] Tests cover the report builder (missing/unused/TODO/plural cases) and
JSON-mode stdout purity.
### Use case/motivation
The repository already has three consumers of this report, and all of them
consume it as hand-copied or screen-scraped terminal text:
1. **The release process.** `dev/README_RELEASE_AIRFLOW.md` has release
managers run this check before each RC and paste its console output into dev@
emails (the `<OUTPUT_OF_I18N_COMPLETENESS_SCRIPT>` placeholder appears in two
templates), and the below-90%-for-two-consecutive-releases locale policy
(#65630) is applied by reading that pasted table. With `--json`, producing
those emails and checking the policy becomes scriptable.
2. **The CI job.** `basic-tests.yml` runs the check on every PR (job
`check-translation-completness`) as `breeze ui check-translation-completeness
|| true`, so the per-PR report the job was added for in #55327 is only visible
by opening the step log, and nothing consumes it. With JSON output, the job
could render a compact per-language summary to `$GITHUB_STEP_SUMMARY`, making
the report visible right on the job page — happy to wire that up in the same PR
or as a follow-up, whichever is preferred. (Side observation: #61885 showed the
step can break silently for months precisely because its output has no
consumer.)
3. **Agent and locale-team tooling.** The in-repo translation skill
(`.agents/skills/airflow-translations/SKILL.md`) has agents run this command
repeatedly and parse the tables from terminal output, and locale-team tooling
outside the repo tends to re-implement key diffing against the raw locale files
— diverging from the checker on plural forms, TODO stubs and unused keys. (The
ESLint `check-translations-completeness` rule also only checks key presence,
with none of the coverage/TODO/unused semantics.) This mirrors the accepted
motivation for `breeze ci verify --json` in #73241: structured output is
cheaper and less fragile for agents and scripts than scraping tables.
### Related issues
#55327 (origin and design intent of the CI job), #58637 (script → breeze
command conversion), #61885 (silent CI step failure), #73241 (`breeze ci verify
--json` precedent), #62982 (recent checker-accuracy improvements)
### Are you willing to submit a PR?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
