Centralized Localization in Modular Android Projects: Tech & ROI

App localization (l10n) for early-stage startups might happen 3 or 6 months after the launch. However, the app’s codebase internationalization (i18n) – setting it up to support a variety of languages – must occur on Day 1. Data shows that most apps (72%) stubbornly remain English-only. This suggests that 28% of apps adopt partial or full localization and gain an immediate competitive advantage. With this in mind, MVP Android Development should prioritize Minimum Viable Localization (MVL). However, while most app development is built around modular Android projects, using a centralized localization module is not that widely adopted.

Why do 72% resist? Mainly due to the effort required. The challenge lies in managing translation (text, measurement systems, rounding rules, plurals, translated length, and their UI presentation) as well as extracting hardcoded text across the codebase. This is where our architectural localization solution comes in: Day 1 app internationalization significantly reduces time and cost in launching localization later on. At You are launched, instead of scattering strings across modules, we use a centralized localization module: :core:localization. This ensures all translation strings live in one place, and every feature module can easily consume them without duplication or confusion. As a result, the early-stage startup has a scalable internationalization set-up that ensures smooth, cost-efficient, and reliable localization, which in its turn equates to business velocity and a high ROI.

In this blog post, we’ll describe our engineering approach to centralized localization in modular Android projects and how it helps startups move faster, save costs, and ship reliably in different locales. 

Why Modular Android Projects? A Business Perspective

Modular Android app development is now the industry standard. Each feature or layer is its own module. While there are definite benefits for developers, this also offers a range of business benefits. These are:

– Fast time-to-market: When you have each feature/layer as an independent module, you can have different teams or individual developers working in parallel. In addition, module independence directly means that no team should wait for the other. Hence, development is faster, so is time-to-market. 

– Saving cost of cloud computing & QA: One more benefit is that the QA team can test each module independently. It reduces costs and time, as the QA team no longer has to run code across the entire database when a single module changes. This is actually a big cost-saving category, as this reduces CI/CD costs due to saving massive amounts of cloud computing.

– App stability & loss prevention: each module is independent and has clear boundaries. If a specific module fails, the crash is contained. This prevents crashing the entire app. This, in turn, ensures reduced churn and saved Customer Acquisition Costs (CAC). 

Likewise, this logic extends to our proposed solution for centralized localization. Consequently, this way, localization is treated as an independent utility feature or, alternatively, an independent ‘core layer’. 

Why a Centralized Localization Module & Drawbacks of Default Android Resource Storage

Generally, localization can become messy in modular projects:

• You might duplicate keys across modules
• You risk inconsistencies between translations
• You increase the complexity of localization

While strings.xml, with its ability to decouple strings from the code, is built in, many modular Android projects end up structuring things like this:

app/
├── features/
│   ├── authentication/
│   │   └── src/main/res/
│   │       ├── values/     → login_title, signup_button (English)
│   │       └── values-de/  → German translations for login only
│   │
│   ├── payment/
│   │   └── src/main/res/
│   │       ├── values/     → checkout_pay, error_card (English)
│   │       └── values-es/  → Spanish translations for checkout only
│   │
│   └── cart/
│       └── src/main/res/
│           ├── values/     → cart_empty, checkout_pay (⚠️ Duplicate key!)
│           └── values-fr/  → French translations for cart only
│
└── core/
    └── design_system/     → (No centralized text layer)

So, if the translator needs to update the entire app into German, they will have to hunt down each feature separately. If they miss out on one folder, the entire feature remains untranslated. In addition, UI inconsistencies can easily arise if, for example, identical actions are named with different strings. For instance, ‘Submit’ on the payment page, but ‘Confirm’ in the cart feature. Finally, running local A/B tests would be a nightmare with this setup.

Instead, we avoid all that by keeping all strings.xml files inside a single module: :core:localization.

Here’s what the structure looks like in modular Android projects we work on:

core/localization/
└── src/
 └── main/
 └── res/
 ├── values/     → Default (English) strings.xml
 ├── values-de/  → German
 ├── values-es/  → Spanish
 ├── values-fr/  → French
 └── values-uk/  → Ukrainian

Consequently, each strings.xml contains the same keys, but different translations.

Therefore, this setup makes it much easier to hand off all translatable content to localization teams or translation platforms – everything is in one place, well-structured, and clearly separated by language. 

Minimum Viable Internationalization (i18n): Structuring the :core:localization Module

There are three critical elements that you should put into these XML files instead of hardcoding. They are:

1) user-facing UI strings. These are all the navigation buttons, error messages, headers, settings, etc. Often, when done in a decentralized manner, in some screens, users would see properly translated button names and checkout steps. Then, all of a sudden, an error would pop up untranslated. Consequently, this breaks UI consistency, undermines user trust, and increases churn.

2) dynamic date/time/currency formatting/ For example, the biggest item here is the difference between the US and European date formatting. Let’s take the 24th of June date: it’s 24.06.2026 in Europe, while it is 06/24/2026 in the US. After all, any app that deals with booking or informing about delivery or subscription renewal dates should correctly inform about that. In fact, simply localizing payment methods already gives a relative 51% conversion uplift. Additionally, simply showing prices in local currency already enables an average of 25% more conversions. 

3) language-aware plurals. In English, it is somewhat simple: 0 messages, 1 message, and 2+ messages. However, when the app hits the huge Indian market, it should say 0 संदेश (0 message). Then, quite a few Spanish-speaking countries require different rules for handling decimals. If it is a fitness app, or ride-sharing app, English 1.5 miles away in plural should become 1.5 milla de distancia (‘milla’ is singular). Finally, the market in the Arab world requires one of the most complex logics. As a result, without the centralized localization module, every feature would be overwhelmed with dozens of lines of if/else conditions for every single line of text. In Arabic, changing from 5 items to 12 items to 102 items requires a change of sentence structure, not only changing the grammatical form of plurals. 

How to Share and Use Localized Strings Between Android Feature Modules

To use localized strings from anywhere in the app:

1. Add the :core:localization dependency to your modular Android project

In your build.gradle.kts (or Groovy):

dependencies {
    implementation(project(":core:localization"))
}

This makes the strings available to your module.

2. Import the R class with an asset alias

Since each module might have its own R, we alias the one from localization:

import com.wishew.core.localization.R as LocalizableResource

We recommend always using this alias to clearly separate localization resources from local ones. Usually, when using such a scheme, there is nothing in the local resources of the feature module.

3. Access localized strings in your feature UI

Now you can reference any string from strings.xml using the alias:

val welcome = context.getString(LocalizableResource.string.welcome_message)

Or in Compose:

Text(text = stringResource(id = LocalizableResource.string.welcome_message))

Adding New Strings to Centralized Localization Module

Whenever you need a new string:

1. Open :core:localization/src/main/res/values/strings.xml
2. Add a new entry:

<string name="new_feature_title">Awesome Feature</string>

3. Copy the same key to other language folders (values-de, values-fr, etc.), providing translations.

✅ All languages are stored side by side, so it’s easy to keep them in sync, audit translations, and even hand over just the res/ folder to a translation agency or platform.

⚠️ Always keep the keys consistent across languages. Inconsistencies will result in fallback behavior or crashes.

Centralized Localization Pro Tips

• ✅ Use tools:ignore=”MissingTranslation” only in development; don’t forget to remove it before release.
• 🌐 Use translation management platforms (like Lokalise or Crowdin) as the single-module structure works perfectly with them.
• 💬 Keep strings descriptive but short — they may be rendered on small screens.
• Leverage Android native <plurals> to adapt your UI to regional grammar rules. For example, below is a localization snippet for the Ukrainian language:

For example, in the centralized localization module, it will look as follows:

<!-- core/localization/src/main/res/values-uk/strings.xml -->
<resources>
    <plurals name="cart_items_count">
        <!-- For numbers ending in 1 (except 11): 1, 21, 31... -->
        <item quantity="one">%1$d товар у вашому кошику</item>
        <!-- For numbers ending in 2, 3, 4 (except 12, 13, 14): 2, 3, 4, 22, 33... -->
        <item quantity="few">%1$d товари у вашому кошику</item>
        <!-- For all other numbers: 0, 5-9, 11-19, 20, 25... -->
        <item quantity="many">%1$d товарів у вашому кошику</item>
        <!-- For fractional numbers or as a fallback option -->
        <item quantity="other">%1$d товару у вашому кошику</item>
    </plurals>
</resources>

Then, in the UI, you can use it like that:

// In your Compose UI layer
val itemCount = 5 // This would come dynamically from your cart
Text(
    text = pluralStringResource(
        id = LocalizableResources.plurals.cart_items_count,
        count = itemCount // Passes the number to format the %1$d placeholder
    )
)

Developer Benefits of Centralized Localization

• Centralized management: All languages are in one module.
• Clean boundaries: Feature modules don’t own translations.
• Reusable resources: Share strings across multiple screens/modules.
• CI-friendly: Easier to validate translations and avoid regressions.
• Scalable: Add new locales without touching other modules.
• Translation-friendly: Ideal for translators — all strings are together, structured, and easy to update.

Modular Android Projects: Localization Needs By Industry

Firstly, the examples in the table below are household names. Most important to acknowledge that an early-stage startup should not strive to achieve full localization in as many languages as in the table. However, it shows high-level trends in each industry. For example:

• Presented companies treat localization as a core feature, not an afterthought. After all, their revenues depend on it. 
• Localization considerations depend on the target market, yet consider the international user. For instance, Nubank needed only 2 languages to completely cover the Latin market, but also has an English version to prepare for international expansion (e.g., into the US market) and cater to international investors. 
• B2B/SaaS apps tend to support fewer languages than travel or lifestyle apps. In B2B/SaaS, a few languages are enough to access global users, while in other industries, revenues depend on the ability to personalize experience, and localization is fundamental in that.

Gaming

In games, the ability to immerse means engagement, and this translates into ARPU (average revenue per user). In fact, localization for a gaming app often means from 200% to 300% more downloads in the target market. Consequently, the MVL approach focuses on localizing onboarding, core UI elements, and main components of the storyline. However, there is no need to translate lore, achievements, or character backstories early on.

E-Commerce & Retail

Above all, users have to provide their credit card details, be aware of delivery, and have confidence in the details of the purchase. If not done properly or with jarring mistakes, it will lead to a spike in cart abandonment rates and churn. In fact, localizing the checkout process for an e-commerce app means about 150% higher conversion rates.

While you may not need to translate product descriptions and titles, you certainly need to localize the checkout & delivery process and guides around it (including return and refund policy). 

Finance & Banking

In finance, most important to note that translation inconsistency or mistakes may lead to legal non-compliance and cost users’ trust. Therefore, early internationalization with a centralized core:localization module allows for preventing mistakes and translation omissions. Initially, MVL should cover: 

• legal consent disclaimer, 
• identity verification process, and 
• core account operations. 

Additionally, special attention should be given to the numeric notation system. 

Fitness & Lifestyle

Markedly, localization for apps in this category is a huge success factor. These apps often thrive on deep personalization; therefore, the highest-impact user journeys should be localized. Additionally, measurements should correspond to regional usage, e.g., pounds and miles for the US, kilograms and kilometers for a European user. Overall, MVL should focus on:

• onboarding, 
• notifications,
• core user journey, like goal setting or workout plans, 
• measurement system, and 
• subscription paywalls.

Healthcare & Telemedicine

Here, clinicians often can provide consultations in more languages than the app is localized for. Clear communication is a requirement, especially in terms of consent forms, symptoms, medications, and clinical instructions.

MVL focuses strictly on localizing doctor-patient interactions, while translating any medical articles or reference libraries can be postponed after the product-market fit is confirmed.

Travel & Hospitality

Localization here is a default requirement as the app operates cross-border. So, a person travelling from Tokyo anywhere in the world should be able to access the information in their native language. Similarly, so should the US national travelling to Tokyo. 

Therefore, MVL focuses on high-quality translation of booking confirmations, policies, and itinerary details. Consequently, to ensure speed and cost- efficiency, the reviews and descriptions should utilize AI for dynamic translation.

SaaS & B2B

Even though most SaaS & B2B apps target international markets, English is an expected linga franka there. Local language support is added when the app faces the compliance requirements.

As a result, localization here is minimal at the early-stage startup. Consequently, the interface often remains in English, and localization touches only billing and marketing materials. In fact, localizing this leads to a substantial decrease in churn of about 40%.

Android App Store Localization Statistics: Downloads vs In-app Revenue vs Hours

Firstly, in the top 10 countries by app downloads on Android, only 1 country’s spoken language is English. As a result, by not localizing, your app ignores countries with 46 billion app downloads. In addition, comparing English-speaking countries vs non-English ones, you can expect cost per install (CPI) and Customer Acquisition Costs (CAC) to be much lower. 

As mentioned earlier, 72% of all apps fight for the English-speaking market, which amounts to around 61 bn US dollars. At the same time, there is a significant tier-1 countries pool that collectively generates around 43 bn US dollars, with only 28% apps competing there. 

Source

Monetizing Users’ Attention: Localization for Ad Revenue

When apps don’t monetize with subscriptions or in-app purchases , they monetize via ads. For this, user attention expressed in time spent on the app is a major revenue driver. 87% of users’ attention globally is non-English and growing must faster than in English-speaking markets. Moreover, the data on the US time spent actually shows a slight drop. 

Also, localization in apps using an advertising monetization model increases their CTR by 42% and conversion by 22%. Considering this, their ad revenues often have a higher ROI than in English-speaking markets. 

Source

Final Words: Business Growth through Centralized Localization Tech Solution

For many successful companies, localization infrastructure impacts more than just access to a wider market. For example, think about experimentation and A/B testing, which are instrumental even for an early-stage startup. Here is Duolingo’s struggle with this:

“From past experiments, we knew that localization could significantly affect how learners interact with Duolingo. However, these A/B tests required engineering time, which could make the process inefficient—just changing the localized text was a small step that took outsized effort.

… this required us to programmatically revamp localization infrastructure, from the way that we reference copy in code to the way that we run localization experiments in the app. But there was a big payoff…”

Therefore, choosing centralized localization is a cost-efficient and far-sighted move for any Android project.

FAQ: Centralized Localization in Modular Android Projects: Tech & ROI