- Ya
- 2 Septemba 2026, 07:32 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 3f79ee7
The five annotation tools in the PDF designer built their tooltip key by interpolating the tool type onto a "tool_" prefix, but the dictionary names those same five strings **************** No key the prefix could build existed, so next-intl rendered the key path itself and a member hovering the pen read **************** report circled exactly five of the six buttons. Spelling the five keys out fixes the tooltips in all 21 locales at once: the strings were already translated, nothing was ever missing from the dictionary. Record<AnnotationType, string> makes a sixth tool a typecheck failure rather than another tooltip that reads back its own key. Two holes in check-i18n-keys.mjs had to line up for this to ship, and both are closed here: - The guard skipped any call whose preceding 40 characters ended in `=`, meaning to skip the `const t = useTranslations()` binding. That binding can never match the regex the skip guards — it searches for `<bound name>(` — so the test only ever fired on `const label = t(...)`, exempting every assignment-form call in the repo, this bug's line among them. - For a dynamic key the guard checked only that the static prefix was a group. **************** is a perfectly good group; it just held no key starting with "tool_". It now also requires the partial final segment to match something in that group, which is the whole of what a dynamic key still allows checking. Removing the skip surfaced two dead `default:` fallbacks — not a next-intl option, passed as an ICU value to messages that have no such placeholder, so they never rendered. Both keys are in the dictionary; the arguments are dropped.