Internationalising Android Apps With Locale Resources

An app that feels natural in Melbourne may feel awkward in Montréal, Mumbai, or Madrid if its text, dates, currency, and layout are fixed in code. Internationalisation separates language-dependent content from application logic, while localisation adapts that content to a particular region and convention.

Android provides a resource system designed for this work. Text, images, dimensions, plurals, and layouts can be selected automatically according to the user’s locale. With a sensible resource structure, one codebase can support Australian English, Japanese, Arabic, and many other markets without duplicating screens or business logic.

For Android developers, the key is to treat locale support as part of the app’s design rather than as a final translation task. This approach improves accessibility, reduces maintenance, and makes regional details—such as Australian dollars, date formats, and spelling—consistent throughout the application.

Organise Resources By Locale

Begin with a default res/values/strings.xml file containing complete text in the language used as your fallback. Add regional alternatives in qualified directories, such as res/values-en-rAU/strings.xml for Australian English or res/values-fr/strings.xml for French. Android selects the most appropriate match for the device configuration.

Use resource names that describe their purpose rather than their visible wording. Names such as checkout_title, account_delete_message, and download_status remain useful when translations change. Avoid names like blue_button_text, because the same string may eventually appear in a menu, notification, or accessibility announcement.

Australian English is a practical example of regional variation. A Sydney user may expect “colour”, “ organise”, and “postcode”, while an American English resource might use “color”, “organize”, and “ZIP code”. Currency displays should also use Australian dollars where appropriate, rather than assuming the dollar symbol always represents the same market.

Keep User-Facing Text In XML

Never place visible sentences directly in Kotlin or Java when they can be stored as resources. A simple declaration might look like this:

<resources>
    <string name="welcome_message">Welcome back, %1$s</string>
    <string name="items_count">%1$d items</string>
</resources>

Retrieve the value with getString() and pass arguments through the format string. This allows translators to change word order without requiring code changes. It also gives Android Studio and translation tools a clear inventory of the content that needs review.

Resource text should include labels, error messages, dialog buttons, notification content, content descriptions, and empty-state messages. A label assembled from fragments such as "Welcome " + username can become grammatically incorrect in another language. Store the whole sentence and use named or positional placeholders instead.

Format Numbers, Dates, And Plurals

Locale-aware formatting is essential for prices, percentages, times, and dates. NumberFormat.getCurrencyInstance(locale) can display a value using the expected currency pattern, while DateTimeFormatter can apply local conventions to a LocalDate or ZonedDateTime. Do not manually insert commas, decimal points, or currency symbols.

Plural resources handle grammar that varies with quantity. Android’s plurals element can distinguish forms such as one item and several items:

<plurals name="photo_count">
    <item quantity="one">%d photo</item>
    <item quantity="other">%d photos</item>
</plurals>

The rules are language-dependent, so avoid assuming that every language has only singular and plural forms. For an Australian shopping app, a price such as $1,250.50, a date such as 18/06/2025, and a delivery estimate should be generated using locale-sensitive APIs rather than hard-coded patterns.

Support Different Writing Directions

Translations can change the size and direction of content. German labels may be longer than English labels, while Arabic and Hebrew require right-to-left presentation. Prefer responsive ConstraintLayout, flexible widths, and wrapping text over fixed coordinates or narrow buttons.

Use start and end attributes instead of left and right:

android:paddingStart="@dimen/screen_padding"
android:paddingEnd="@dimen/screen_padding"

Set android:supportsRtl="true" in the manifest and use directional icons where necessary. A back arrow, progress indicator, or decorative image may need mirroring, but brand marks and photographs usually should not be flipped. Test long translated strings in dialogs and toolbar titles to prevent clipping.

Test Locale Changes Properly

Changing the phone language is useful, but it is not enough. Android Studio supports pseudolocales that expose text expansion, missing translations, and accidental hard-coded strings. Test with large fonts as well, because users often combine language changes with accessibility settings.

Check layouts in portrait and landscape, on small screens, and on tablets. Test right-to-left languages, languages with accented characters, and locales that use different plural rules. A translation may fit on a Pixel device in Brisbane but fail in a compact handset used by a customer in Perth.

Use screenshot tests or automated UI tests for important flows such as sign-up, checkout, password recovery, and permission prompts. Verify that content descriptions are translated and that formatted values remain meaningful when the locale changes while the app is running.

Let Users Choose An App Language

Android’s system language settings are suitable for many applications, but some products need an in-app language selector. A travel, education, or customer-support app may allow users in Australia to switch between English, Mandarin, Vietnamese, or another language without changing the entire phone.

Store the selected language as a locale tag, not as a display name. Modern Android APIs and AndroidX AppCompat provide mechanisms for applying application locales, while older devices may require updating the application configuration and recreating affected activities. Persist the preference with a stable key and ensure that it is restored after process death.

Locale selection should also respect privacy and accessibility expectations. If an app collects language preferences or location data to personalise content, explain that use clearly and handle personal information consistently with Australia’s Privacy Act and the Australian Privacy Principles. Language choice should not require unnecessary location permission.

Connect Localisation With App Architecture

Keep localisation at the presentation boundary. View models and domain services should expose events, numbers, dates, or message identifiers rather than constructing English sentences. The activity, fragment, or composable can then resolve those values through resources using the current configuration.

This separation is particularly helpful in apps that use background work. A notification or service result should carry structured data, allowing the UI layer to format it for the active locale. When learning how components communicate, developers can review this bound service example and apply the same principle: keep communication data-focused instead of embedding presentation text in service code.

Translations should be managed like source code. Review additions, remove obsolete keys, and give translators context for placeholders, gender, character limits, and where a string appears. A professional translation workflow reduces the chance that a late feature introduces an untranslated button or an inconsistent term across screens.

A Practical Localisation Checklist

Plan locale support before building every screen. Decide which markets matter, define a fallback language, and identify values that need regional formatting. For an Australian launch, include en-AU testing rather than relying only on a generic English device setting.

Use this checklist during development and release preparation:

• Put every user-visible string in resources, including accessibility text and notifications.
• Use locale-aware APIs for currency, dates, times, numbers, and plural quantities.
• Test expanded text, right-to-left layouts, large fonts, and pseudolocales.
• Keep locale selection and translation keys separate from business logic.
• Review privacy implications when storing language, region, or location preferences.

Internationalised Android applications are easier to extend because their interface is no longer tied to one language or set of regional assumptions. Resource qualifiers, flexible layouts, and structured formatting provide a reliable foundation for reaching users across Australia and international markets while keeping the codebase maintainable.