Katakana Style Mismatch Check

When glossary terms are supplied, this rule checks deterministic katakana long-vowel variants against the required target term style.

Japanese style guides often specify whether terms use long-vowel marks, such as ユーザー versus ユーザ or サーバー versus サーバ. A mixed file can look unpolished even when the translation is understandable.

The report shows the affected path, the glossary term style expected, and the variant found in the target string.

That gives localization PMs and vendors a style-guide cleanup list before client review. It is especially useful when multiple translators or translation memories contribute to the same JSON file.

Katakana long-vowel style is not universal. Some clients prefer older JIS-style forms, some prefer modern forms, and some product names intentionally break the general rule.

Disable this rule when no glossary style has been agreed or when katakana style is reviewed manually. Keep it enabled for Japanese profiles with a maintained glossary and explicit style-guide requirements.

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.