Testing Japanese Localization Before Launch

Localization QA catches the bugs that surface only in JP locale — broken layouts, untranslated strings, formatting failures, font fallback issues. This article is a working QA checklist plus the rationale behind each step.

For broader process context, see the iOS and Android Japan localization step-by-step guide.

Why JP-Specific QA Matters

Three categories of bugs that only surface in JP-locale testing:

1. String-level bugs. Untranslated English, awkward phrasing, register inconsistencies, length overflow.

2. Layout bugs. Buttons truncating, lines wrapping awkwardly, fonts mismatched.

3. Format bugs. Wrong date format, currency with decimals, half-width punctuation, English error messages from backend.

A general QA pass on the English build will not catch these. JP-locale QA needs to be a separate workstream with its own checklist.

Who Should Test

Three types of testers, ideally all involved:

1. The translator

The person who wrote the JP strings should review the live build. They'll catch register drift, awkward phrasing, and contextual mismatches.

2. A second native speaker

Someone unfamiliar with the project. They'll catch what the translator's eyes glide over because they're too close to the work.

3. A target-demographic user

Not an internal team member. Someone in your target audience. They'll catch trust signals, cultural fit, UX friction. This is the highest-leverage test.

The cost of a 30-minute usability test with one Japanese user in your target demographic is low. The information value is very high.

The QA Checklist

Run through this on a JP-locale build, on a JP-region device.

Strings and content

Format

Dates in Japanese format (yyyy/MM/dd or 〇年〇月〇日).
Times in 24-hour format.
Currency as ¥ with no decimals (e.g., ¥1,000 not ¥1,000.00).
Phone numbers display with hyphens.
Postal codes display with hyphen (XXX-XXXX).
Address fields ordered prefecture → city → block.
Calendar week starts Sunday.

Punctuation and typography

No half-width Latin punctuation in Japanese sentences.
Quote marks are 「」 not "".
Bullet points are 「・」 not - or *.
No spaces between Japanese words.
No 「を/が/は」 orphans starting a line.
No 「。/、」 orphans starting a line.
Font rendering is correct (no font fallback to Mincho where Sans is expected).

Register and tone

Register is consistent within each screen.
Buttons use consistent verb form (noun, plain, polite).
No 「あなた」/「あなたの」 unless intentional.
No 「することができます」 — replaced with 「できます」.
No untranslated English idioms ("一石二鳥" used incorrectly, etc.).
Honorifics fit the brand voice.

Layout

No button truncation with "..."
No tab label truncation.
Modal titles fit within title area.
Footers wrap acceptably.
Empty states don't crowd content.
All buttons have a legible label at minimum dynamic font size.
Tested at 100% and 130% font scale.
Tested in both portrait and landscape (if app supports landscape).

Permissions and system

iOS permission strings (NSCameraUsageDescription, etc.) localized.
iOS App Tracking Transparency prompt localized.
Android permission rationale localized.
Notification channel names localized.
System dialogs from share sheets, save dialogs render in JP.

Backend / Server-Side

Server returns JP-localized error messages (not just English).
Server returns JP-localized email content.
CRM/marketing tool (Braze, Iterable, etc.) sends JP campaigns to JP users.
Stripe/payment receipts in Japanese where applicable.
Customer support chat widget greeting in Japanese.

App Store Connect / Play Console

Listing copy is JP-native, not translated US copy.
Screenshots are JP-style, with Japanese taglines and Japanese in-app screens.
Preview video has JP captions.
Promotional text is JP.
Privacy policy URL goes to JP page.
Support URL goes to JP page.
Privacy nutrition labels are translated.

Device Coverage

For physical-device testing:

iPhone: Latest model + one model from 2 years ago (length differences show up at smaller widths).
Android: Pixel + Samsung + one mid-range Android (Sharp, Sony, Xiaomi) — different vendors handle JP fonts slightly differently.
Tablet: iPad if your app supports it. Layout often differs from phone.

Test on JP region, not just JP language. Set the device's region to Japan.

Pseudo-Localization vs. Real JP Testing

Some teams test localization with pseudo-localization (e.g., [!!! Save !!!]) to flag UI strings that didn't get extracted. This is valuable but doesn't catch JP-specific issues.

Run pseudo-loc to confirm extraction completeness, then run real JP loc to confirm content quality.

Specific Bugs That Surface in JP Testing

Bug: untranslated push notifications

Symptom: User sets device to JP, app sends them an English push. Root cause: backend doesn't know user's locale. Fix: send locale with push subscription registration; backend looks up locale per user.

Bug: hardcoded English string in a fallback path

Symptom: Network error shows English message in an otherwise-Japanese app. Root cause: error fallback uses hardcoded English. Fix: extract every fallback string into the localizable resources.

Bug: date picker shows ambiguous format

Symptom: Date picker shows MM/DD or DD/MM and user can't tell which. Root cause: format string hardcoded for English. Fix: use locale-aware date formatter.

Bug: receipt arrives in English from Stripe

Symptom: Purchase succeeds; receipt email is English. Root cause: Stripe customer object doesn't have JP locale flag. Fix: set Stripe customer locale to "ja" on signup.

Bug: font fallback creates mismatched weights

Symptom: A line of text has bold Latin and regular JP characters. Root cause: Custom Latin font is bold; JP fallback uses regular weight Noto. Fix: bundle a JP font with matched weights (see Japanese typography).

Bug: postal code field doesn't auto-fill

Symptom: User enters 100-0001 expecting prefecture/city to populate; nothing happens. Root cause: JP postal-code lookup not integrated. Fix: integrate a postal-code-to-address API (Japan Post API or similar).

Bug: name fields don't accept full-width katakana

Symptom: User enters カタカナ, validation rejects. Root cause: regex set to ASCII characters only. Fix: allow Unicode input, validate appropriately for the field.

Bug: searches fail on katakana-hiragana variants

Symptom: the user searches 「カメラ」 and gets results, but a search for 「かめら」 (rare) returns nothing. Root cause: search index doesn't normalize. Fix: normalize at index time (kana folding) or at query time.

A Native Usability Test

The most underrated step in JP QA: a 30-minute usability test with one native user.

The protocol:

Install the app on a JP-locale phone.
Hand the phone to the user with no instructions.
Ask them to "use the app for 10 minutes as you normally would."
Observe. Note where they pause, frown, or backtrack.
After 10 minutes, ask: "What confused you? What felt off? Would you keep using this?"

You'll learn things no string-level review reveals. We've seen single 30-minute tests surface 5–10 issues that the translator and the dev team missed.

A Pre-Launch Sign-Off Document

Before submitting to the App Store / Play Console for the JP launch, create a sign-off document with:

Confirmation of every checklist item above.
Screenshots of 20+ key screens in Japanese.
Translator approval.
Native QA approval.
Engineering approval that backend localization works.

This forces explicit accountability for the launch quality.

Where to Go Next

We run JP-locale QA passes on shipping apps with native QA, layout review, and a usability test deliverable. Contact us for a fixed-scope QA engagement.