Script Inconsistency Check

LocaleQA checks for deterministic mixtures of full-width and half-width alphanumeric or punctuation characters inside localized strings.

In Japanese localization, width choices often follow a style guide. Accidental mixtures can come from IME conversion, copy/paste, translation memory matches, or editing only part of a product term.

The report shows the JSON path and the string that contains the suspicious character-width mixture. The report gives reviewers a specific item to compare against the project style guide.

The rule does not decide whether full-width or half-width is correct. It only highlights inconsistent mixtures that are hard to catch by eye in dense JSON files.

Some Japanese UI copy intentionally mixes widths, especially around product names, Latin acronyms, model numbers, or client-specific notation. Those should be accepted when the style guide requires them.

Disable this rule for projects with frequent intentional width mixing or where width review is handled linguistically. Keep it enabled for Japanese profile scans where product names, numbers, and punctuation must remain consistent.

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.