Placeholder Full-Width Mutation Check
The placeholder full-width mutation check catches runtime tokens whose ASCII syntax was accidentally converted into full-width Japanese characters.
Examples
{ "hello": "Hello {name}", "rate": "Progress: %{percent}%" }{ "hello": "こんにちは｛name｝", "rate": "進捗：％｛percent｝％" }hello: ASCII braces changed to full-width braces rate: percent/braces changed to full-width variants
The string may look readable in Japanese, but the application may no longer recognize the token syntax at runtime.
What LocaleQA checks
LocaleQA looks for placeholder-like source tokens whose ASCII token characters, such as braces, percent signs, or related punctuation, appear in the target as full-width variants.
The issue is common in Japanese workflows because IME conversion, manual editing, or copy/paste from documents can turn {name} into ｛name｝ or %{count} into ％｛count｝ without looking obviously broken to a reviewer.
What appears in the report
The report shows the affected JSON path and the token characters that appear to have changed width. Developers can confirm the runtime syntax, while PMs or vendors can correct the target string before delivery.
This differs from ordinary placeholder mismatch: the placeholder name may still be visible, but the syntax characters no longer match what the application recognizes.
When to keep or skip this check
It is rarely intentional to full-width a runtime placeholder delimiter. The surrounding Japanese punctuation may be full-width, but the token itself usually needs to remain ASCII.
Disable this rule only when the product deliberately uses full-width token syntax, which is uncommon. Keep it enabled for Japanese localization profiles, especially when files pass through CAT tools, spreadsheets, or manual review in editors that use Japanese IME input.
How to use the finding
LocaleQA reports the affected JSON path, the source and target values involved, and the rule that triggered the finding. Developers, localization PMs, vendors, and QA reviewers can use that as a specific file-level item to fix, approve, or discuss before release.
Some findings are valid exceptions. A migration file, documented style choice, or locale-specific convention may explain the difference. In those cases, teams can leave the string as-is or disable the check for that scan.
For Japanese projects, width, spacing, encoding, and katakana style often belong to the client style guide. Keep this check on when those conventions matter, and leave it off for projects where the pattern is not part of review.