Applanga SDK Integration Overview

Applanga Mobile SDK Integration Overview

This article explains Applanga Mobile SDK Integration considerations for new and prospective users.

Table of Contents

1. When to use the Applanga SDK Integration?
2. Applanga Platform Availability
3. Integration Features
4. Device Language & Fallback Logic

When to use Applanga SDK Integration?

The Applanga mobile SDKs can be used to translate native, static app content into multiple languages. Applanga supports all ISO-639-1 languages and custom languages can be added on request. As long as an app is localizable, no additional development work is required to integrate Applanga into an existing app. Generally, a localizable app went through the process of internalization, often called i18n according to the development documentation of your app development framework, All strings in scope need to be externalized in dedicated string files e.g. string XML for Android or in .string files for iOS. In other words, strings cannot be hardcoded into the app.

Applanga Platform Availability

Applanga boasts the most native mobile integrations (SDKs) of all existing TMS which can be combined with other integration options such as the Applanga Rest API or CLI as required by the use case. The Applanga SDK integration sits above the basic localization architecture of the underlying operating system (OS) e.g. iOS or Android. For more information, please check the Applanga Integration Documentation.

Applanga currently integrates with the following SDKs:

• Android
• iOS
• React Native
• Flutter
• Unity

It is important to note that each SDK may not support all Applanga integration features. Refer to the Integration Documentation for more detailed information. The features highlighted here are available for Android and iOS SDKs.

Integration Features

Automatic String Upload

While in debug mode or with the Draft Mode activated, Applanga automatically pushes any new, not yet uploaded strings into the dashboard across all available languages already present in the app and within the connected Applanga project. Automatic string uploads will not overwrite original content if or when a string is changed at the code-level; this maintains a Source of Truth for all strings on Applanga (including your base language, e.g. English). If a developer needs to overwrite the content in the Applanga dashboard with the local version of the app, the content must be cleared from the dashboard first then strings are reuploaded. All changes to the translations are tracked via the changelog.

Please note Applanga will never autonomously push translations to an app. Translations can only be published by specific Applanga users with specific roles via the dashboard.

The Applanga Settings File & App Store Releases

The Settingsfile removes the need to manually add an API key and secret directly to the app code as part of the SDK integration. With this information, it establishes the connection between the Applanga platform, the Applanga dashboard, and the Applanga user’s integrated mobile app. Each project within the dashboard has its own Settingsfile.

In addition to the connection credentials, this file stores all translations and acts as a local database within the app. While translations can be updated over-the-air on app start, it is strongly recommended to include an updated Applanga Settingsfile with every regular app store release. Retrieving the latest version of the project Settingsfile can be automated via update script. For more information on this update script, please check the Applanga Integration Documentation.

With multiple languages and numerous strings, the Settingsfile may increase the size of the app; however, one settings file is significantly smaller than multiple string files for multiple languages which would need to be included in the app if no Applanga SDK integration existed.

OTA Translation Updates

While the Settingsfile may be from an earlier version of the app, the Applanga SDKs enable a mechanism called OTA (Over-the-Air) updates to keep all translations current. On app start-up, Applanga will send the translation version found locally as well as the device language to the Applanga servers. If the translations for the requested language were updated on the Applanga dashboard and the translation version is higher on the server, the SDK will download all changes made between its local version and the one on the server. This principle is called Delta Updates. It ensures the SDK does not download previously downloaded translations again and keeps the response size minimal. These downloaded updates are then cached in the app. They are available even when the app is offline and won’t be downloaded the next time the app starts.

Applanga uses a content delivery network (CDN) to accomodate for any number of update requests from around the world. This CDN resets in 10 minute intervals. That means that publishing new translations or making updates to already published translations may take up to 10 minutes until they are available via OTA updates in the app.

Draft Mode Features

On-Device Testing

All translations which are published or set as target are live to the users of an app integrated with Applanga SDK, but every string can also have a Draft Value. These Draft values can be displayed in the app via the Draft Mode This allows translators or testers to view those Draft Values of translations without publishing or even creating a new build for testing which significantly reduces testing time.

Anyone with the Draft Mode key and a build of the app integrated with Applanga SDK can enable Draft Mode via a four-finger, long hold gesture which opens a pop-up to log in and sets the app to Draft Mode. Once Draft Mode is enabled, the app will restart and display both draft and published strings with drafts taking priority. Testers can then navigate to the specific screen in the app to check for translation or functional errors. If a translation requires adjustment, the Draft value can be updated in the dashboard and these updated Draft values can then be reviewed on-device after a restart of the app.

JIRA Issue Creation

If a tester identifies a functional error, the Applanga JIRA integration allows testers to create Jira tickets from within the app. JIRA tickets created in this manner include a screenshot of the screen where the ticket was created. Ticket summary and description as well as issue category and assignee can be modified from within the Draft Mode as well.

Screenshots (Capture & Upload)

Draft Mode also enables Applanga users to capture and upload screenshots. The feature is easily accessed via a two-finger downward swipe. The Applanga SDK will also try to find and attach all string Ids to the screen from which a screenshot is captured with this method. On the Applanga dashboard, all uploaded screenshots and associated strings are combined in a Applanga Tagged for effortless tracking. Tags are created in two ways: they are manually generated in the Applanga dashboard, so they already exist and can be selected as an upload target, or directly in the Draft Mode menu.

Developers also have the option to automate the screenshotting process. Applanga can be integrated into automated test scripts that run through the app screen by screen. Existing scripts can be extended. Screenshots captured this way are then automatically uploaded to the Applanga dashboard.

The dashboard will always show the most recent screenshots to allow translators and testers to review the most recent changes.

Device Language & Fallback Logic

The Device Language, as specified in the device settings by the user, is used by the Applanga SDK to determine in which language an app should be served as well as for requesting updates. Applanga can also be integrated with an in-app language selector that would overwrite those device settings.

If only some strings of an app are available in the specified language, then those strings will appear translated while the remainder of the app will appear in the base language.

Applanga utilizes the following fallback logic to deliver the correct language to an app:

1. Dialect (such as French Canadian)
2. Language (such as French)
3. Base Language (the app’s original language, e.g English)

Please note the fallback logic does not work in reverse; if an app is only available in a dialect, but not the parent language, then the app will appear in the base language only. For Example, if an app is only available in Mexican Spanish (es-MX), but an app user’s device language is set to Spanish (es), then the app will appear in the base language (en).