The reasons for keeping strings untranslated #️⃣

It’s a good practice to keep your strings out of your source code. And that means all strings, including those that are not supposed to be translated, such as ad identifiers, URL addresses, internal IDs, etc.

Also, there are valid reasons for not translating part of your app and keeping it in English (or your native language). We use this in our own apps. There is a page that asks people to help us translate the app, and it’s in English. Why?

First, we can’t be sure what is the language of the user and whether this part is already translated or not. And, she probably sees this because the app is not fully translated (or is untranslated for the user’s language at all).

Second, to be able to help with translating the app, the user should understand English well enough. So, if she’s not able to read the text of the page, she’s probably not the target audience of its message.

And there’s also a subtle third reason, it’s not important to translate this part of the app, and fewer strings means fewer investments - either money and time.

Three ways of excluding strings #️⃣

Before you upload your strings for translating, you should exclude those we talked about above. There are three ways how to do so:

Mark them as non-translatable #️⃣

There is an existing mechanism that allows you to define strings that you don’t want to translate by marking them as translatable="false". Localazy honors this and doesn’t upload strings with this attribute.

You can use it in your strings.xml like this:

<resources>

    <!-- This strings is excluded using standard Android way -->
    <string name="excluded_string_1" translatable="false">Excluded string 1</string>

</resources>

Exclude strings in the build script #️⃣

You can exclude strings based on their key/name by specifying them in localazy > upload > strings section of your gradle.build script. It allows you to exclude strings across all flavors or even in libraries without the need to specify all of them as translatable="false".

It’s as easy as:

localazy {
  // ...
  upload {
    // ...
    strings {
      exclude "excluded_key"
    }       
  }
}

You can also switch to the include-only mode or specify strings inside libraries or dynamic modules. See Localazy Gradle plugin for more information.

Exclude files in the build script #️⃣

As other translation platforms usually force developers to upload strings files, some of us, like me, already separated private and non-translatable strings to a dedicated file. Mine is called strings_private.xml.

With Localazy, you can easily exclude the whole file from being uploaded:

localazy {
  // ...
  upload {
    // ...
    files {
      exclude "*/strings_private.xml"
    }       
  }
}

The magic path */strings_private.xml tells the Gradle plugin to exclude strings_private.xml file from all flavors and all values folders. To specify that you don’t want to upload strings.xml from the free flavor and values-v11 folder use free:values-v11/strings.xml.

You can also switch to the include-only mode or specify files inside libraries or dynamic modules. See Localazy Gradle plugin for more information.

Localazy is intelligent! #️⃣

We all are humans and thus make mistakes. I myself uploaded strings that shouldn’t be translated for several apps. I always forget about correctly specifying what to exclude. Well, it’s entirely my fault because I simply don’t use translatable="false". You know, when you are in the flow, you concentrate on your code, and switching to resources XML is a distraction you want to minimize.

Well, my faults are good for you! We have extended our Gradle plugin with an analyzer that looks for the most common patterns and warns you before uploading strings in question.

The upload task exits with an exception when the analyzer is not sure about whether it should upload some of your strings or not.

However, a false positive detection may happen, and so there is an option to disable the analyzer. Do it in your build file like this:

localazy {
  // ...
  upload {
    // ...
    ignorePrivateStrings true   
  }
}

I made a mistake… what now? #️⃣

No problem at all. This could happen, and it happens to me as well.

However, Localazy doesn’t allow you to remove strings directly. It would cause much confusion. The base language is one-way synchronized from your app resources, and so we can’t remove them from your code too. There is also our no changes to your code politics we are committed to.

Don’t worry; it’s still very simple:

1. Exclude your strings in the build script or using translatable=false and re-upload them to Localazy.

2. Excluded strings are no longer available for translation, but our platform still manages them. They are marked as deprecated. If they don’t contain sensitive information, no action is necessary.

3. If you want them to be deleted, sign in to Localazy and go to your project. Now, in Translations go to MANAGE for the source language, filter deprecated phrases and delete them.

It’s simple, isn’t it?

The example on Github #️⃣

There is a small example project available on Github where you can see all the variants described above.

Dive deeper… #️⃣

Don’t miss what you should know before uploading your android strings guide to learn more about important topics related to mobile app localization.