What is the language resource contamination and how to fix it?

The language resource contamination breaks the locale fallback mechanism when you include libraries with many translations. Localazy fixes it!

The problem with language fallbacks

The language resource contamination is also called language resource pollution, and it breaks the locale fallback mechanism when you include libraries with many translations. It’s a big deal for common libraries such as AppCompat, AndroidX, and Google Play Services.

When the app is built, the resources are merged, and so there is no way how Android could know what languages your actual app is translated to.

Imagine a simple situation; I can speak Czech (cs) and French (fr). So I configure my Android device like this:

Language resource contamination

The default language of your app is English (as for the majority of existing apps), and you’ve invested a lot of effort and money to translate your app to the French language. But I’m not going to benefit from it.

Why? Your app contains Czech (cs) resources included from AndroidX and so Android select my preferred choice, the Czech language, and every single string in your app is missing in this language and fallbacks to the default one. And you don’t want this to happen.

What is the solution to this issue?

The Android Gradle plugin comes with an easy to use solution. All you need to do is to specify locales that your app is translated to in your build.gradle file like this:

// ...

android {

  // ...

  defaultConfig {
    // ...    
    resConfigs "en", "fr"
  }

  // ...

}

// ...

This way, all other locales are omitted during the build process, and your app will work for me with French fallback precisely as desired.

I don’t want to specify locales manually!

And you shouldn’t! It can be a source of mistakes. What if you forget to include new translations or make a typo? There is no check, no warning.

Also, you need to think about it, at least, for every release. It’s adding another burden to your shoulders. Let’s fight it together 😉.

The Localazy Gradle plugin comes with an automated solution. You just need to make a few changes to your build script.

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'

// Add the special plugin for accessing Localazy data.
apply plugin: 'com.localazy.gradle.data'

// Move the Localazy configuration above the android section. 
localazy {
  // ...
}

android {
  // ...
  defaultConfig {
    // ...    
    // 
    resConfigs localazy.getResConfigs()
  }
  // ...
}

// ...

// Apply the normal Localazy plugin after the android section
apply plugin: 'com.localazy.gradle'

Follow the basic guide and upload your strings before introducing these changes to your build script as for this to work correctly, your translations have to be first uploaded and processed by our servers.

What about if I add more languages later?

This all is just about the resources contained in your APK or app bundle. All updated strings and new languages are automatically added to your app during the build process.

Localazy library integrated into your app uses its own resolution mechanism that is not affected by the resource contamination issue. It can download updated strings as well as new languages from our servers and use them even if they are filtered out by the process described above. OTA updates of your app’s translations are not affected in any way.

What should you consider?

You should provide your translations for all strings in the app and don’t rely on those provided by the libraries as you may easily end up with mixed translations in a way that is out of your control.

Translating the whole app correctly without side effects is not an easy job, and we try to help you with this tedious task as much as we can.