iOS and Android App Localization for Japan: A Step-by-Step Process

This is the operational side. If you have decided to localize and now need to actually do it — what files to touch, what order to work in, where the Japan-specific gotchas hide — this guide walks through it.

For the strategy and quality side, start with the complete guide to Japanese app localization. For the App Store listing, see the Japanese ASO complete guide.

Phase 1: Pre-Translation Engineering

Before any Japanese strings exist, your codebase needs to be ready to receive them. Most localization projects fail here. The strings get translated, the build ships, and three weeks later someone discovers that the receipt screen still shows English because that copy was hardcoded.

1.1 Audit for hardcoded strings

Run a pass to find every user-facing string that lives in code instead of a strings file.

iOS — search for Text(", NSLocalizedString(, LocalizedStringKey, and string literals passed to Label, Button, Alert. Anything not wrapped in NSLocalizedString or a SwiftUI string-key API will not localize.

Android — search for setText(", android:text=" with literal strings, and any Toast.makeText(context, "...", ...) with a hardcoded string. Anything outside strings.xml will not localize.

1.2 Set up Japanese as a real locale

iOS — in Xcode, select your project → Info → Localizations → add Japanese. Confirm ja.lproj directories appear for each .strings and .stringsdict file. If you use String Catalogs (.xcstrings), Japanese will show up as a column.

Android — create res/values-ja/strings.xml. Note the locale code is ja, not jp.

1.3 Plan for Japanese-specific resources beyond strings

Japanese localization sometimes affects:

• Fonts. System fonts handle Japanese, but custom fonts often don't. If you ship a custom font, you need a Japanese fallback chain.
• Images with embedded text. Any image asset with English copy on it (onboarding cards, marketing banners) needs a Japanese counterpart.
• Date/time formatters. Hardcoded date formats break Japanese expectations. See date and number formats in Japan.
• Sound and haptic feedback. Less common, but some apps use English voice prompts that need Japanese versions.

1.4 Set up .stringsdict for plurals (iOS) or quantity strings (Android)

Japanese has no grammatical plural — but the strings file system still uses the "other" plural rule. You still need to use plural-aware APIs because future-locale-correctness depends on it.

iOS .stringsdict for "%d items":

<key>%d_items</key>
<dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@items@</string>
    <key>items</key>
    <dict>
        <key>NSStringFormatSpecTypeKey</key>
        <string>NSStringPluralRuleType</string>
        <key>NSStringFormatValueTypeKey</key>
        <string>d</string>
        <key>other</key>
        <string>%dアイテム</string>
    </dict>
</dict>

Android strings.xml:

<plurals name="items_count">
    <item quantity="other">%dアイテム</item>
</plurals>

For Japanese, only other is used.

Phase 2: String Extraction and Briefing

2.1 Export strings to the format your translator can work with

iOS:

• String Catalogs (recommended for new projects): xcloc exports.
• Legacy .strings files: use genstrings or build-time export.

Android:

• Export values/strings.xml as XLIFF if your translator works in CAT tools, or send the raw XML.

Whatever format you pick, make sure each string carries its context comment. The single biggest cause of awkward translations is translators receiving strings out of context.

iOS: use the comment parameter to NSLocalizedString or the comment field in String Catalogs.

NSLocalizedString(
    "delete_account_button",
    comment: "Button at the bottom of the account settings screen. Triggers a confirmation dialog before deletion."
)

Android:

<string name="delete_account_button"
    description="Button at bottom of account settings. Triggers confirmation dialog.">
    Delete account
</string>

Do this for every non-trivial string. We have seen translation quality jump 40% from comment-richness alone.

2.2 Brief the translator on register and tone

Before sending the strings, send a one-page tone document that includes:

• The brand voice in three adjectives (e.g., "warm but expert," "precise and quick," "playful and casual").
• The chosen register (polite-neutral, plain, honorific, casual). See keigo in app copy for the framework.
• 5–10 do/don't pairs in Japanese, ideally pulled from competitor apps you do or don't want to sound like.
• Glossary of brand terms that should not be translated.
• Glossary of features with their preferred Japanese form (e.g., "Spaces" → 「スペース」 not 「空間」).

The translator will produce dramatically better output with this document than without it. It is also reusable for every future translation cycle.

2.3 Decide whether to use a translation memory (TM)

If your app updates frequently, set up a TM in a CAT tool (memoQ, Trados, Phrase, Lokalise) from day one. The cost of doing this on cycle two is much higher than on cycle one. Without a TM you will pay for re-translation of strings you have already paid to translate.

Phase 3: Translation and First-Pass Review

3.1 Avoid MTPE for consumer apps

Machine Translation Post-Editing — running text through DeepL/GPT and having an editor clean up — is fine for internal tools, B2B dashboards, or any app where the user is paid to use it. For consumer apps with retention dependencies, the editor's output still reads as MT-influenced.

We cover the technical reasons in why AI translation fails for Japanese. The short version: MT introduces a "shape" to Japanese sentences that natives can identify even after editing. Skip the MT step.

3.2 Have the translation done by one writer, not a team

Consistency of voice across the entire app matters more than throughput. A 3-person team translating in parallel produces strings that, when read in sequence by a user, feel like 3 different apps stitched together.

If your app is large enough that one writer cannot finish in time, split by domain (one writer does all account/auth, one does all content/feed, one does all settings) rather than randomly.

3.3 First-pass review by a second native speaker

The translator translates. A second native reviews. They flag:

• Register inconsistencies.
• Awkward phrasing that is correct but unidiomatic.
• Words that are technically correct but wrong for the brand voice.

This is not optional. Even excellent translators benefit from a second set of eyes; the iteration improves quality measurably.

Phase 4: In-Context Review

4.1 Drop strings into a build and screenshot every screen

Once the strings file is updated, build the app and walk through every screen, capturing screenshots. Many strings that read fine in a spreadsheet break in context.

Common in-context issues:

• Length overflow. A 12-character English button becomes 18 characters in Japanese. The button truncates or wraps. Rewrite for the constraint, don't change the layout.
• Unclear referent. "それを削除" ("delete it") in a list view where multiple items are visible. The translator did not have visual context.
• Wrong politeness for the screen. A casual error message inside an otherwise formal flow.
• Awkward line breaks. Japanese line-break rules are different — words should not split across lines if possible. See Japanese typography.

4.2 Review with the translator on the call

The translator should see the build, not just the strings. Even one hour of "here is the screen, here is your translation" produces better fixes than three hours of email back-and-forth.

4.3 Watch a native speaker use the app

Hire one Japanese user, watch them use the app for 30 minutes. Note every place they pause, frown, or backtrack. Those are the rewriting opportunities. This single test catches more issues than three rounds of internal review.

Phase 5: Platform-Specific Configuration

5.1 iOS specifics

• Region settings. Verify the app responds to NSLocale.current.regionCode == "JP" for Japan-specific behavior (currency, date format, phone number formatting).
• Info.plist localization. Localize permission strings (NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, etc.) by creating InfoPlist.strings in ja.lproj. Permission strings are user-facing and high-trust — Japanese users will deny if the explanation is awkward.
• App Tracking Transparency prompt. The ATT dialog text must be localized. This is one of the most critical strings in the app from a privacy-trust standpoint.
• Push notification text. If you send pushes from a backend, that backend needs to know the user's locale to send Japanese-localized pushes. Don't rely on the app catching it client-side.

5.2 Android specifics

• Locale qualifier. values-ja/ for Japanese; do not use values-jp/ (this won't work, locale codes use language not country here).
• Strings.xml escaping. Japanese punctuation 「」does not need escaping, but apostrophes and quotes used in copy do. Use \' and ".
• Permission rationale strings. Same care as iOS — Japanese users deny aggressively if the rationale is awkward.
• Notification channels. Channel names appear in Japanese system settings; localize them.

5.3 Backend strings

This is the silent killer. If your backend sends:

• Email confirmations
• Push notification payloads
• In-app messages from a marketing tool (Braze, Iterable, OneSignal, CleverTap)
• Receipts and invoices
• SMS

Each of these has its own localization pipeline. The mobile app might be perfectly Japanese while every email arrives in English. Map every backend message touchpoint and localize each. This is a coordination problem more than a translation problem.

Phase 6: Pre-Launch QA

6.1 The Japanese localization QA checklist

A workable QA pass covers:

• Every screen loads in Japanese with no untranslated strings.
• Every error message and toast shows in Japanese.
• Every push notification renders in Japanese on a JP-locale device.
• Every email/SMS triggered by the app arrives in Japanese.
• Date formats use Japanese conventions (2026年5月10日 or 2026/05/10, not 5/10/2026).
• Currency renders as ¥ with no decimal places.
• Phone numbers display in Japanese format (03-1234-5678, 090-1234-5678).
• Postal codes accept and validate Japanese format (〒100-0001).
• Names accept full-width Japanese characters; sort orders work for Japanese names.
• No untranslated text in screenshots used inside the app (e.g., onboarding images).
• Privacy policy and Terms of Service have a Japanese version linked from the app.
• Support email or chat responds in Japanese during Japanese business hours.

The fuller version is in testing Japanese localization before launch.

6.2 Test on a Japanese-locale device, not just Japanese language

Set the device's region to Japan, not just the language. Region affects currency, calendar, week start day, and several iOS APIs that language alone does not cover.

6.3 Submit a TestFlight or internal track build to native testers

Not internal review, not your translator's review. A handful of actual Japanese users who do not work in tech, ideally in your target demographic. Their reactions reveal what specs cannot.

Phase 7: Launch and Ongoing Maintenance

7.1 Localize the App Store listing as a separate workstream

The App Store listing is its own project. See the Japanese ASO complete guide. Don't ship the app launch without the listing being equally polished.

7.2 Set up a translation cadence for ongoing updates

Every release has new English strings. You need a workflow where:

1. New strings get extracted at code-freeze.
2. Translator turns them around in 24–72 hours.
3. Translations land before the build ships, not after.

The fastest way to lose Japanese trust is to ship features that show English copy "for now."

7.3 Monitor reviews and respond in Japanese

Every Japanese App Store and Play Store review gets a response, in Japanese, from a real person. Other Japanese users read the responses as a trust signal — see App Store reviews from Japanese users.

7.4 Track localization-aware metrics

Look at:

• Onboarding completion rate by locale.
• Retention by locale at D1, D7, D30.
• Conversion to paid by locale.
• Crash rate by locale (font fallback bugs sometimes show up here).

If JP locale metrics lag US by more than 25%, the localization is the most likely culprit. Iterate.

A Realistic Timeline

For a typical 1,500-string consumer app:

Phase	Time
Pre-translation engineering	1 week
String extraction and briefing	3–4 days
Translation	1–2 weeks
In-context review and revisions	1 week
Platform configuration	3–4 days
QA	1 week
Buffer	1 week
Total	5–6 weeks

The App Store listing (screenshots, copy, ASO) runs in parallel for the last 3 weeks.

Where to Go Next

• The 12 Most Common Mistakes in Japanese App Localization — what to QA against.
• Handling Japanese Text Expansion in Mobile UI — layout-specific gotchas.
• Testing Japanese Localization Before Launch — fuller QA checklist.
• Date, Time, Currency, and Number Formats in Japan — the format details.

---

We run this whole process for clients launching in Japan, including the parts your in-house team probably should not own (native QA, ASO listing, screenshot redesign). Contact us if you want a fixed-scope localization engagement.