���ϴ��¼�

The first localization task is not sending XML files for translation. It is identifying the complete experience that must work for each market.

Define Languages, Locales, and Market Variants

A language is not always a sufficient production target. Spanish for Mexico may require different terminology, formatting, regulatory wording, and commercial content from Spanish for Spain. French for Canada can differ from French for France. Chinese may require Simplified or Traditional script distinctions and market-specific usage.

Define each target at the level the product requires:

• language;
• script;
• region;
• country or commercial market;
• legal or regulatory jurisdiction;
• app-store market;
• supported currency and payment model;
• preferred tone, formality, and terminology.

Use broad language resources when they serve the complete audience well. Create regional or script-specific variants when user expectations, product requirements, or local obligations justify the difference.

Inventory the Complete User Journey

Map every surface where customers encounter language:

• onboarding, sign-in, and account recovery;
• navigation, buttons, dialogs, forms, and validation;
• permissions and privacy choices;
• search, filters, sorting, and empty states;
• errors, warnings, status messages, and confirmations;
• subscriptions, checkout, billing, and cancellation;
• push notifications and notification actions;
• widgets, shortcuts, deep links, and app links;
• embedded help, webviews, chat, and customer support;
• emails, SMS messages, and transactional communications;
• legal notices and consent language;
• Google Play listings, screenshots, products, and release notes.

This inventory prevents a common launch problem: a polished translated interface surrounded by source-language messages from backend systems, third-party components, or operational content.

Confirm the Technical Architecture

Document how the Android product is built and delivered:

• Kotlin, Java, or a mixed codebase;
• Jetpack Compose, traditional Views, or both;
• app modules and dynamic feature modules;
• internal and third-party libraries;
• Android App Bundles and language-resource delivery;
• server-driven UI or remote configuration;
• JSON, CSV, XLIFF, spreadsheets, or proprietary localization formats;
• repository, build, and continuous integration environments;
• existing language picker or locale-management code.

This information determines where content lives, how locales are detected, what can be automated, and which multilingual behaviors require engineering work.

Assemble a Localization Kit

A useful Android localization kit can include:

• source resource files;
• an export of all user-facing strings;
• build or test access;
• screenshots or screen recordings;
• Figma references;
• developer comments;
• resource-key descriptions;
• character or layout constraints;
• product terminology;
• style and tone guidance;
• translation memory from earlier releases;
• market-specific requirements;
• release schedule and priority workflows;
• reviewer names and approval responsibilities.

The goal is not to document every screen perfectly before work begins. It is to resolve the ambiguities and technical constraints most likely to create repeated questions, inconsistent language, or rework.

Prepare a Mobile App for Localization

Android separates many user-facing assets from application logic and stores them within the project’s res/ directory. At runtime, the system selects the resource set that best matches the active configuration.

Begin With Complete Default Resources

The default string file is normally:

res/values/strings.xml

It serves as the ultimate fallback when a locale-specific value is unavailable. The default resource set must include every resource the app requires. A localized file may contain only the strings that differ for that locale, but the unqualified default set cannot safely be incomplete.

The same principle applies beyond strings. If code refers to a required drawable, font, color, or other resource, an appropriate default must exist.

Android’s official localization documentation explains that a missing required default resource can prevent the app from loading under an unsupported locale. This makes default-resource completeness a release requirement, not an editorial preference.

Use Locale-Specific Resource Directories

A typical resource structure may look like this:

res/
├── values/
│   └── strings.xml
├── values-es/
│   └── strings.xml
├── values-fr-rCA/
│   └── strings.xml
├── values-pt-rBR/
│   └── strings.xml
└── values-b+zh+Hans/
    └── strings.xml

These examples represent:

• values-es: Spanish without a region-specific override;
• values-fr-rCA: French for Canada;
• values-pt-rBR: Portuguese for Brazil;
• values-b+zh+Hans: a BCP 47-style qualifier for Simplified Chinese.

Android supports language-only, language-region, and BCP 47 language-script-region qualifiers. Use the least specific resource that is correct for the intended audience, then add variants only where the content truly differs.

Understand Fallback Behavior

Suppose res/values-ja/strings.xml does not define the app title. Android can fall back to the title in res/values/strings.xml.

Fallback is useful for intentionally shared content, but it can also hide omissions. A missing Japanese translation may display in the source language without causing a build failure. Teams therefore need both technical validation and in-product language review.

Localize More Than Strings When Needed

Locale-specific resources can include:

• drawables and images;
• audio;
• fonts;
• XML assets;
• raw resources;
• product names and manifest-linked labels;
• localized graphics containing text;
• market-specific legal or instructional content.

Do not duplicate assets unnecessarily. A brand mark with no text may be appropriate across all locales, while a promotional graphic containing a headline requires a localized version.

Review Modules and Library Dependencies

Modern Android applications may receive resources from:

• the main app module;
• feature modules;
• internal shared libraries;
• third-party libraries;
• SDKs.

This matters when generating the supported locale list. Android Gradle Plugin can detect locales from app modules and library dependencies, so an otherwise useful library may introduce languages the product team did not intend to publish.

Review the final locale inventory before release. Where appropriate, configure resource filtering so the packaged app reflects the languages the product actually supports.

Explore Software Internationalization Services

A technically valid source file can still be difficult to translate well. Translation readiness depends on the way strings are written, identified, documented, and protected.

Move User-Facing Text Out of Code

Avoid hard-coded interface text:

Text("Complete your order")

Use a string resource instead:

Text(
    text = stringResource(R.string.checkout_complete_order)
)

Externalized content can be extracted, translated, validated, reused, and updated without editing application logic.

Review more than visible Text components. Hard-coded language can also appear in:

• error handlers;
• logs that surface to users;
• content descriptions;
• snackbars and toasts;
• validation messages;
• notifications;
• dialog builders;
• test data that reaches production;
• server-response mappings;
• embedded HTML.

Use Stable, Meaningful Resource Keys

A descriptive key gives developers, translators, and reviewers useful context:

<string name="checkout_complete_order">Complete your order</string>

A generic key does not:

<string name="button_17">Complete your order</string>

Good keys should:

• describe purpose or screen context;
• remain stable when English wording changes;
• distinguish identical words used in different ways;
• avoid embedding the complete source sentence;
• support reliable change tracking and translation-memory reuse.

For example, “Save” can describe storing a file, retaining money, or rescuing a game state. Separate keys reduce the risk of applying one translation to unrelated meanings.

Use the Right Android String Type

Android supports three primary string-resource types:

• <string> for individual strings;
• <string-array> for arrays of related values;
• <plurals> for quantity-dependent messages.

Choose the structure that reflects the application behavior. Do not flatten plural logic or concatenate fragments simply because a spreadsheet workflow is easier.

Mark Only Truly Nontranslatable Content

The translatable="false" attribute can protect strings that should remain unchanged, such as:

• internal identifiers;
• technical tokens;
• invariant product names;
• test values;
• URLs;
• legal marks that must retain an approved form.

Do not use it to bypass localization for customer-facing content. A string that is difficult to manage still needs an intentional language decision.

Add Translator Context

Short UI strings are often ambiguous outside the app. Useful context includes:

• the screen or feature;
• whether the string is a noun, verb, command, or status;
• the user action that triggers it;
• preceding and following content;
• variable meanings;
• maximum or preferred length;
• whether line wrapping is acceptable;
• audience, tone, and formality;
• screenshots or a test build.

Consider the word “Apply.” Depending on context, it may mean submit a form, use a discount, request a job, add a filter, or place a setting into effect. A screenshot and a short developer comment can prevent multiple review cycles.

Avoid Sentence Concatenation

Avoid building messages from independent fragments:

"Welcome, " + userName + ". You have " + count + " messages."

Translate a complete message with protected placeholders instead. Languages can require different word order, agreement, punctuation, and plural forms. Fragmented strings can make a correct translation impossible.

Protect Placeholders, Markup, and Escapes

Android resources may contain:

• %1$s, %2$d, and other formatting arguments;
• XLIFF placeholder tags;
• HTML or styled markup;
• escape sequences;
• line breaks;
• URLs;
• product codes;
• nonbreaking spaces;
• Unicode characters.

These elements should be identified and validated automatically wherever possible.

A translation can be linguistically correct and still break the app if a key, placeholder, escape sequence, or markup element is changed.

English often distinguishes only “one” and “other.” Other languages can require additional quantity categories or different sentence structures.

A basic Android plural resource looks like this:

<plurals name="cart_items">
    <item quantity="one">%1$d item</item>
    <item quantity="other">%1$d items</item>
</plurals>

A target language may need a different set of supported forms. Translators should receive the complete plural structure, the meaning of the count, and an example of how the message appears.

Use Positional Placeholders

Numbered placeholders let translators reorder values:

<string name="order_summary">
    Order %1$s includes %2$d items.
</string>

The target language may place the order number, quantity, or noun in a different position. Positional arguments make that change possible without altering application logic.

Translate the Complete Message

Avoid assembling sentences from:

• separate prefixes and suffixes;
• independent nouns;
• adjective fragments;
• standalone punctuation;
• untranslated runtime labels.

Complete messages give linguists control over grammar, word order, agreement, and tone.

Plan for Grammatical Variants

Some products need different wording based on:

• formality;
• user role;
• grammatical gender;
• social context;
• market-specific conventions.

Android 14 added grammatical-inflection support for apps that provide appropriate gender-specific localized resources. This is an advanced option, not a requirement for every product. Use it only when the experience, language, and privacy model justify collecting or applying that preference.

Jetpack Compose does not require a separate translation-resource architecture. Compose normally consumes the same Android project resources used by traditional Views.

Retrieve Strings With stringResource

Text(
    text = stringResource(R.string.checkout_complete_order)
)

Formatted values can be passed through the same resource call:

Text(
    text = stringResource(
        R.string.order_summary,
        orderNumber,
        itemCount
    )
)

Retrieve Plurals With pluralStringResource

Text(
    text = pluralStringResource(
        R.plurals.cart_items,
        itemCount,
        itemCount
    )
)

The quantity selects the plural form. When the number also appears in the displayed message, it is supplied as a formatting argument as well.

Keep Composables Free of Hard-Coded Production Text

Review:

• buttons and labels;
• dialogs and bottom sheets;
• navigation items;
• empty states;
• snackbar messages;
• validation feedback;
• icons and content descriptions;
• preview content that may be copied into production.

Compose makes UI construction concise, which can make hard-coded text easy to introduce. Code review and static analysis should treat localizability as a standard quality requirement.

Handle Locale Changes as UI State

When the app locale changes, the interface must resolve the newly selected resources. Compose can recompose when configuration-dependent state changes, but custom locale handling must be implemented carefully.

Read locale-sensitive configuration through Compose-aware state rather than assuming a global locale lookup will trigger recomposition. Test language switching while the app is running, including navigation, dialogs, retained screens, and mixed Compose/View flows.

Preview Different Locales and Text Sizes

Compose previews can display a composable under a specified locale:

@Preview(locale = "es")

Use preview configurations to review:

• long-text languages;
• RTL locales such as Arabic;
• Japanese and other scripts with different line behavior;
• larger font scales;
• phone, tablet, foldable, and landscape layouts.

Previewing accelerates early visual checks, but it does not replace a complete localized build. Runtime content, navigation, backend messages, fonts, third-party components, and device behavior still need in-product testing.

Use Screenshot Testing Selectively

Compose Preview Screenshot Testing can compare rendered previews with approved reference images. It is useful for detecting visual regressions across selected locales, screen sizes, themes, and font scales.

Automated screenshots are most effective when teams choose representative high-risk configurations rather than generating an unmanageable number of snapshots.

Validate Mixed Compose and View Codebases

Compose and Views can share the same XML resources, but they may differ in:

• configuration handling;
• preview tools;
• accessibility implementation;
• custom component behavior;
• layout and text measurement;
• test frameworks.

Test transitions between the two systems and ensure both respond consistently to locale changes.

Android 13 introduced centralized per-app language preferences. Users can select an app language independently of the device language through system settings, while AndroidX provides backward-compatible options for earlier versions.

Distinguish Device and App Language

A user may keep the device interface in English while using a banking, messaging, or learning app in Spanish. The product must define which locale controls:

• application strings;
• dates and numbers;
• content recommendations;
• server responses;
• support language;
• legal content;
• market or currency behavior.

App language and commercial market are related but not identical. A user selecting French does not necessarily change country, currency, or legal jurisdiction.

Prefer Automatic Locale Configuration Where Appropriate

With Android Gradle Plugin 8.1 and later, projects can enable automatic locale configuration:

android {
    androidResources {
        generateLocaleConfig = true
    }
}

The project also declares its default locale in resources.properties. Android Gradle Plugin can then generate the LocaleConfig based on app and library resources.

Automatic generation reduces manual maintenance, but it increases the importance of resource governance. Every detected locale must be ready for release.

Support Earlier Android Versions

For Android versions before 13, teams may continue to use AndroidX APIs and an in-app language picker. Products migrating from custom locale logic should:

• preserve existing user choices;
• synchronize the in-app picker with system settings;
• avoid presenting two conflicting controls;
• restore selections after update, backup, or reinstall where supported;
• test process restarts and configuration changes.

Publish Only Complete Locales

A language should not appear in the user’s app-language menu simply because a dependency includes a small set of translated resources.

Before exposing a locale, verify:

• core UI coverage;
• critical user journeys;
• backend and notification support;
• help and legal content;
• accessibility strings;
• Google Play content;
• support ownership;
• testing status.

Adding a locale to the language menu does not localize the application.

Test App Bundle Language Delivery

Google Play can deliver language resources as configuration APKs according to the user’s language settings. When users add or change an app language, additional language resources may be delivered.

Test:

• the first launch after installation;
• switching to a newly added language;
• switching while offline or on a limited connection;
• fallback behavior before resources are available;
• dynamic feature modules;
• backup and restore;
• updates that add or remove locale support.

Correct translations can still feel foreign or produce incorrect results when the application hard-codes source-market conventions.

Use Locale-Aware Formatting

Review every place the app handles:

• dates and times;
• time zones;
• numbers and percentages;
• decimal and grouping separators;
• currency symbols and codes;
• measurement units;
• calendars and numeral systems;
• names and honorifics;
• addresses and postal codes;
• phone numbers;
• sorting, searching, and collation.

Use locale-aware platform and ICU-based formatting APIs rather than constructing presentation formats manually. Define which values follow app language, device region, account market, or a business-specific setting.

For example, changing the app language should not silently convert a customer’s account currency. Language, region, market, and currency need separate product rules.

Design for Text Expansion

Translated strings can be shorter or much longer than the source. Build interfaces that can accommodate:

• multiline labels;
• variable button widths;
• taller dialogs;
• wrapped navigation;
• longer form instructions;
• expanding error messages;
• dynamic content with placeholders.

Avoid fixed dimensions that only fit the source language. Truncation may hide the action, meaning, price, warning, or consent language a user needs.

Validate Fonts and Complex Scripts

Confirm that the font system supports:

• required glyphs;
• Arabic shaping;
• Indic scripts;
• CJK characters;
• combining marks;
• diacritics;
• punctuation;
• available weights;
• appropriate line height and baseline behavior.

Font fallback can change visual hierarchy, spacing, and brand appearance even when every character renders.

Test Phones, Tablets, Foldables, and Orientation

A layout that works on one phone may fail on:

• small devices;
• tablets;
• foldables;
• landscape orientation;
• split-screen mode;
• large accessibility text;
• dense or low-resolution displays.

Prioritize configurations using real product analytics, target-market device profiles, supported Android versions, and the risk of each workflow.

Prepare for Right-to-Left Languages

For Arabic, Hebrew, and other right-to-left experiences:

• use start and end instead of fixed left and right;
• allow layouts and navigation to mirror where appropriate;
• review directional icons;
• test mixed RTL and Latin content;
• validate numbers, prices, codes, and phone numbers;
• inspect form fields and cursor behavior;
• review charts, timelines, progress indicators, and gestures;
• test custom components and third-party SDKs.

Not every asset should mirror. Brand marks, media controls, clock directions, and some data visualizations may retain their original direction. Make each decision according to meaning, not a blanket rule.

RTL quality requires more than displaying translated Arabic or Hebrew text. It requires validating layout behavior, navigation, inputs, icons, mixed-direction content, and complete user journeys.

Pseudolocalization transforms source-language content to simulate characteristics of other languages before real translations are available.

Android provides two pseudolocales:

• English (XA): adds accents, brackets, and text expansion to left-to-right content;
• AR (XB): simulates right-to-left and bidirectional behavior.

What English (XA) Can Reveal

• hard-coded strings;
• fixed-width controls;
• truncation and overlap;
• sentence concatenation;
• unprotected placeholders;
• text embedded in images;
• encoding problems;
• components that cannot grow.

What AR (XB) Can Reveal

• layouts that do not mirror;
• hard-coded left and right positioning;
• directional icons that remain incorrect;
• punctuation problems;
• mixed-direction text issues;
• form alignment defects;
• custom components that ignore RTL behavior.

Enable Pseudolocales in Test Builds

For a Kotlin Gradle build:

android {
    buildTypes.getByName("debug") {
        isPseudoLocalesEnabled = true
    }
}

Keep pseudolocales in developer-oriented builds. They are a test tool, not a production language offering.

Run Pseudolocalization Early and Repeatedly

Use pseudolocales:

• before the first translation handoff;
• during new-feature development;
• after major design-system changes;
• when migrating to Compose;
• when introducing per-app languages;
• before major multilingual releases;
• in regression testing.

Pseudolocalization does not evaluate translation quality. It improves the technical readiness of the product so professional translations can be implemented with fewer preventable defects.

Accessibility text is part of the product language and should follow the same translation, terminology, review, and release process as visible UI content.

Include Every Assistive String

Localize:

• content descriptions;
• TalkBack labels;
• hints and instructions;
• validation and error guidance;
• custom control names;
• image descriptions;
• captions and transcripts;
• status updates;
• live announcements;
• form labels;
• accessible names for icons.

Avoid hard-coded accessibility descriptions in Kotlin, Java, or Compose.

Use Compose Semantics Intentionally

Compose semantics provide meaning to accessibility services, testing frameworks, autofill, and other platform features. Standard components include useful semantics by default, while custom components may require explicit roles, descriptions, state information, or actions.

Do not add redundant descriptions that cause TalkBack to repeat visible text unnecessarily. Test the experience with the actual interaction flow.

Test in Every Target Language

Accessibility QA should cover:

• TalkBack reading and pronunciation;
• reading and focus order;
• RTL focus movement;
• localized actions and hints;
• dynamic announcements;
• error recovery;
• keyboard and switch navigation where relevant;
• font scaling and display scaling;
• truncation at large text sizes;
• custom controls.

Android 14 and later can support nonlinear font scaling up to 200%. Interfaces should be reviewed at the large text settings supported by the product’s target versions, not only at default size.

Use both manual testing with accessibility services and automated checks. Automated tools can find some missing semantics and structural issues, but they cannot judge whether localized instructions are clear, natural, or sufficient for the user’s task.

The installed app and its Google Play presence are separate localization surfaces. They should use consistent terminology, positioning, visuals, and market expectations.

Localize Store Listing Metadata

Prepare market-appropriate versions of:

• app name;
• short description;
• full description;
• release notes;
• promotional text;
• feature names;
• support and privacy references.

Work within current character limits and policy requirements. Adapt the message to local search vocabulary and customer priorities without stuffing keywords or promising ranking outcomes.

Localize Visual Assets

Review:

• phone and tablet screenshots;
• feature graphics;
• preview videos;
• captions;
• text embedded in images;
• device frames;
• localized UI shown in screenshots;
• market-specific benefits or proof points.

A translated description paired with source-language screenshots creates an incomplete storefront experience.

Localize Products and Subscriptions

Coordinate:

• product names;
• subscription titles;
• benefit descriptions;
• trial messaging;
• billing explanations;
• upgrade and cancellation language;
• purchase confirmations.

Use language that matches the app’s actual commerce flow and the terminology users will encounter after installation.

Use Custom Store Listings Purposefully

Google Play custom store listings can support differentiated messaging for selected countries, search terms, audience states, or campaigns.

Use them when the market or acquisition context genuinely requires a different proposition. Do not create variants that the localization and marketing teams cannot maintain across product updates.

Do Not Rely on Automatic Store Translation for Priority Markets

Google Play may display automated translations when an explicit localized listing is unavailable. Automated coverage can improve basic accessibility, but it does not provide the same control over terminology, persuasion, cultural relevance, screenshots, or product positioning.

For priority markets, publish explicit, reviewed listings and localized visual assets.

Apply AI With Appropriate Control

Android Studio and Google Play workflows increasingly provide AI-assisted translation options. These tools can accelerate first-pass coverage, but they do not remove the need for:

• approved terminology;
• product and screen context;
• technical validation;
• market adaptation;
• risk-based human review;
• in-app testing.

Use automation according to content type and consequence. Repeated low-risk interface text, regulated instructions, subscription terms, brand copy, and safety-critical messages should not automatically receive the same workflow.

Many Android localization problems originate outside the Android resource directory.

Review content delivered through:

• backend APIs;
• remote configuration;
• content management systems;
• server-driven UI;
• push notification services;
• webviews;
• embedded help centers;
• chat and support systems;
• transactional email and SMS;
• payment providers;
• identity-verification SDKs;
• map and location services;
• advertisements;
• third-party authentication;
• downloadable language packs;
• dynamic legal notices.

For each source, define:

• source-language ownership;
• supported locales;
• fallback behavior;
• translation workflow;
• caching and update behavior;
• version control;
• testing responsibility;
• analytics or issue reporting.

A fully translated strings.xml file does not guarantee a fully localized customer journey.

Android products evolve continuously. Localization should move with development rather than waiting for large, manual handoffs.

Detect New, Changed, and Removed Content

Connect localization to the systems where content changes:

• source repositories;
• resource exports;
• design tools;
• content management systems;
• release branches;
• build pipelines;
• Google Play workflows.

Track:

• new keys;
• modified source text;
• deleted or deprecated keys;
• moved content;
• changed placeholders;
• newly added locales;
• updates to screenshots and store listings.

Reuse Approved Language Assets

Translation memory stores approved source and target content for reuse. Terminology management controls product names, feature names, technical terms, abbreviations, and preferred language.

Together, they help teams:

• avoid retranslating unchanged content;
• maintain consistent product language;
• focus review on new and changed material;
• preserve decisions across releases;
• coordinate app, help, marketing, and support content.

Explore Translation Memory
Explore Terminology Management

Connect Strings With Context

Automated extraction should not strip away the information linguists need. Attach:

• screenshots;
• feature and screen names;
• resource keys;
• Figma references;
• developer comments;
• character constraints;
• build links;
• user-flow descriptions.

In-context review helps teams see whether a translation is appropriate for the screen, action, layout, and surrounding content.

Explore In-Context UI Localization

Automate Technical Quality Checks

Before localized resources return to the codebase, validate:

• XML structure;
• keys;
• placeholders;
• tags;
• escaping;
• plural completeness;
• locale naming;
• unexpected source-language text;
• required protected content.

Build validation should provide clear, actionable errors rather than forcing engineers to diagnose avoidable localization defects late in the release.

Protect Source Code, Builds, and User Data

Localization workflows may include source resources, screenshots, prerelease builds, product terminology, support content, and market-sensitive information. Define access according to role and project need. Use approved repositories and transfer methods, control build access, document retention expectations, and keep real customer data out of screenshots and test packages whenever possible.

For enterprise programs, governance should also identify who may export strings, approve terminology, review sensitive content, access test builds, and authorize a locale for release. Security controls should support the workflow without stripping away the context linguists and reviewers need to do accurate work.

Coordinate Release Approval

Define ownership for:

• language approval;
• terminology;
• engineering integration;
• build generation;
• linguistic QA;
• accessibility;
• Google Play content;
• final release signoff.

A locale is ready only when the required content and workflows are ready together.

Explore the Software Localization API
Read the Continuous Localization for Mobile Apps Guide