Integrate Android

with Localazy within minutes.

You can upload your strings directly from you IDE using our available libraries. The reason behind this is the advanced analysis of translatable strings. Localazy will find all strings and will also recommend ignoring common private strings if they are not flagged.

Is this way of uploading useful also for apps which already have translations? #️⃣

Of course, this works for both starting and enrolled apps. Moreover, you can easily migrate all your work into Localazy and finish your current unfinished translations sooner thanks to Localazy ShareTM.

Worried about your source code? Don’t be. All your source code remains only on your machine. The only thing uploaded to Localazy are the strings to be translated.

The Localazy Android Library is an optional component that offers numerous benefits to your app, including automated upload and Over-The-Air (OTA) updates. However, we understand that you may have reservations about integrating third-party libraries into your app.

As a result, if you prefer not to use the Localazy Android Library, you can still utilize our CLI (Command-Line Interface) without any dependency on the Localazy Android library.

When you configure the Localazy Gradle plugin or change its configuration, be sure to clean the project. We use caching and incremental builds wherever possible to speed up the building of your app. Without cleaning your project, the compiled classes may not be re-compiled, and changes not applied.

No. You can leave them unchanged. We automatically process them during the build process, update contained strings, and add missing ones.  We never touch your source files, but we always build your app with the most recent translation.

You don’t need to. Even if OTA updates are disabled, we add the most recent translation to your resources when you build your app. Our Localazy Gradle plugin does it automatically for you without touching your source files.

You don’t need to touch your source code at all.

Localazy works fully automatically and select the best matching locale based on the user settings.

It uses the same detection mechanism as Android.

The Localazy library allows to switch locales manually if you want to use it, but it’s not required.

If you, for some reason, need to work with locales manually, see the documentation for Localazy Android library: https://localazy.com/docs/android/localazy-android-library#working-with-locales

At this moment, all you need is our Gradle plugin. When you build your app, the latest version of XML is automatically downloaded. By default, automatic publishing is enabled and changes may take up to 15 minutes to apply.

You can skip this interval by publishing the latest release manually.

Also, it’s a good idea to run Gradle clean to remove data from the cache. We use also local caching to speed up the build process.

To test your new language availability, all you need is to switch your device language as Localazy follows user device locale by default. You can, of course, offer a language selector to your users if you would like to.

The plugin indeed changes the bytecode of your app in several places. It looks for certain patterns to identify where the changes are needed. However, it never sends your source code nor the bytecode to anywhere and all changes are made strictly to inject the OTA feature.

Honestly, any plugin you add to your project can access your source code, resources and bytecode and our plugin is no different from Firebase or Google Services in term how it changes your bytecode.

We are ready to sign a contract binding us to not send your source code, resources or bytecode anywhere and inject only code strictly needed for OTA features.

The second option is to use our CLI, but you will lose the comfort of the automatic resolution of your project structure and OTA updates.

You can easily exclude strings and files from upload. Make sure you do not include your Admob IDs and so on.

All your languages are uploaded only when the uploadStrings is run for the first time.

As it’s typical to upload only the base language for subsequent uploads, we have this behavior as a default choice. You can, however, enable uploading all of them.

In your Gradle file, add:

localazy {
  // ...
  upload {
    showUploadAll true
  }
}

And then refresh your project.

The default choice uploadStrings will be changed to uploadBaseStrings and uploadAllStrings, and so you can decide whether you need to upload all (recommended only if there is a reason for it) or upload just the base language.

Suppose you have a project where the source file is a JSON file with a row in the format:

"about.moreButton": "Learn more on our website",

When using the Localazy CLI to import to Android with Format Conversions (or when you just try to export the JSON file to Android XML inside the Localazy web platform), you might notice that the format is:

<string name="about_moreButton">"Learn more on our website"</string>

Now, you might think you should delete those start and end quotation marks in the body of the XML row to achieve this result:

<string name="about_moreButton">Learn more on our website</string>

However, you can keep the quotation marks in the Android XML file because it’s a supported construct used to correctly encode white characters that would otherwise be lost in all cases. Quotation marks ensure that the exact form of your strings is preserved after conversion.

In actual use, the text will render correctly on the device.

More information can be found on the Android Developers website: String Resources

Setting up OTA updates is straightforward with our SDKs. For Android, add the Localazy Gradle plugin to your build configuration and include a few lines of initialization code in your application class. For iOS, install the Localazy Swift SDK via Swift Package Manager or CocoaPods and add initialization code to your app delegate.

After integration, configure your project in Localazy to enable OTA delivery. This involves activating the service in your project settings.

Once set up, you can control the delivery through Release Tags in the platform, deciding when translations become available to your users.