[Pushkal-Gupta]

Five translated strings interpolate a variable that the English original does not have. Nothing ever passes that variable, so i18next leaves the placeholder in and the user sees it.

In the Portuguese log settings menu, the shortcut hint beside Expandir reads Pressione {{hotkey}} para expandir ou recolher where it should just read e.

What is wrong

common.json keeps the log viewer's shortcut letter under <action>.hotkey and the sentence explaining it under <action>.tooltip. The letter is the key you press, so it is the same in every language. German and Spanish keep that split:

"expand": { "hotkey": "e", "tooltip": "Tastenkombination {{hotkey}} zum Ein-/Ausklappen drücken" }

Portuguese has the sentence in both slots, so hotkey holds a {{hotkey}} of its own:

"expand": { "hotkey": "Pressione {{hotkey}} para expandir ou recolher",
            "tooltip": "Pressione {{hotkey}} para expandir ou recolher a secção" }

TaskLogHeader.tsx renders that value as the small hint on the right of the menu item and passes no variables, because the English value needs none. It affects expand, source, timestamp and wrap. download.hotkey in the same file is already d, which is what makes this look like a copy-paste slip rather than a decision.

Hungarian has the same shape in hitl.json: response.responded_by_user_name is Válaszolta: {{userName}}, where English has Responded by (User Name) and German has Beantwortet von (Benutzername).

Where	Now	After
pt, log settings, Expand / Source / Timestamps / Wrap	Pressione {{hotkey}} para ...	e / s / t / w
hu, HITL responder column	Válaszolta: {{userName}}	Válaszolta (felhasználónév)

The fix

The four Portuguese values become the letters, taken from SHORTCUTS.logs in src/context/keyboardShortcuts/shortcuts.ts, so the hint matches the binding that actually works. Portuguese keeps its own tooltip sentences, so no wording is lost.

For Hungarian I kept the translator's verb and only dropped the placeholder. I do not speak Hungarian, so please re-word it if Válaszolta (felhasználónév) reads badly.

The test

locales.test.ts gains one check: for every locale and key, the {{variables}} have to match the English original. Invent one and you get a raw {{...}} on screen; drop one and the value disappears silently.

Two things it has to get right, or it reports strings that are fine. Plural categories differ by language, so a translated foo_many often has no English key of its own category and has to compare against whichever form English does define. And count is exempt on plural forms, because i18next only reaches a plural form when count was passed. Without that, Italian and Portuguese error_many get reported for using {{count, number}} where English spells error_one as a plain 1 Error.

Checks

• locales.test.ts on its own: 28 pass
• reverting only the two locale files fails the new check with exactly these five keys, four in pt and one in hu, and nothing from the other 18
• eslint, prettier and tsc clean, and prek rewrites nothing for these three files
• full suite: 2222 of 2223 pass. The one failure is DagsFilters.test.tsx, which is already broken on main and is not touched here

No newsfragment: a translation fix with no behaviour change.

---

Was generative AI tooling used to co-author this PR?

• Yes - Claude Code (Opus 5)

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test