There are no special prerequisites for using Applanga but you need to have your App prepared for translation for the given Platform.

• On Apple devices your strings need to be in a .strings file in order to be automatically uploaded to the Applanga Dashboard. In order to have your dynamic texts localized, you have to use NSLocalizedString in your source code. Additionally you need to have Base Localization enabled for .storyboard and .nib files to have their static texts localized. At runtime, all static and dynamic texts will be automatically synchronized with the Dashboard.
• On Android devices your strings need to be in a string resource .xml file in the /res/values/ folder in order to be automatically uploaded to the Applanga Dashboard. To have your dynamic texts localized, you have to use getString in your source code. At runtime, all dynamic and static texts in your layout files will be automatically synchronized with the Dashboard.

Literally minutes.

There are some tweaks for the different platforms we support, but in general there are two parts: the SDK and the Applanga Settingsfile. The first can be placed inside your app with a single line of code, while the latter needs to be downloaded and copied into a folder inside your project.

The Applanga Settingsfile combines two features:

• For one, it is part of the regular integration and stores a unique identifier and some configurations to reduce the manual integration effort.
• Additionally, all translations on the Dashboard are saved in the Applanga Settingsfile.
• You should always download and include the latest version of the file within the build you submit to the app stores to ensure the most recent translations are included in your regular release. If your users have insufficient internet connection for live updates, the SDK will revert to the translation inside the Applanga Settingsfile on the device.

The app uses locally cached translations, either from the last successful request to Applanga, from the Applanga Settingsfile, or your actual string file within the app, so your users won’t be impacted if Applanga servers should not be reachable.

We implemented a series of systems that ensure service availability and so far we have not experienced any outages. If you need a guaranteed uptime, it's part of Enterprise-level plans only. Please get in touch for more information.

All our traffic is encrypted and we use an additional HMAC algorithm to make sure the data is not tampered with. We do not store or transfer any data that would identify your app’s users.

Up to 10 minutes. That is the period of time in which the content delivery network (CDN) in front of our servers updates.

There are several ways to translate your app with Applanga's help:

• You can simply translate it yourself, together with your team, or with remote external translators. Simply add them to your Team in the Dashboard.
• You can use the integrated machine translation tool (we recommend you only use it for testing purposes or if you are not worried about translation quality).
• To get the very best quality of translation we recommend using Transperfect Translation Services. Transperfect Translation can easily be ordered using are integrated Order Menu. Get in touch with us at support@applanga.com if you are interested in learning more.

As a manager, admin, or owner, you can add a description and a screenshot for every entry. With descriptions and screenshots translators are given greater context for each string.

Yes! Our internal team of professional Transperfect translators provide high quality translations and thoroughly review your content to ensure complete satisfaction. For more info, see the Translation Services section below or reach out to us directly.

Yes! Besides the integration for native mobile apps (SDKs) and our design tool plugins, we also have an API and CLI option to integrate with your website or web app.

Make sure your app is set to Draft or Debug mode. If that’s the case, try refreshing the page - it may take up to 30 seconds for strings to be sent from the app. Also, check the logs on the app start to find Applanga specific log messages informing you about the upload progress. If you’re still running into problems, find more troubleshooting information in our Integration Guides.

Base localization needs to be enabled in all Storyboard files. Learn how here.

These kinds of IDs are generated by iOS and refer to the ObjectID of the Storyboard Element. Unfortunately, Apple doesn't allow renaming of these strings.

It’s possible that the getString (Android)/ NSlocalizedString (iOS) method called on an already localized string. The method normally expects an ID, but if it’s presented with a string, it will create an empty ID with the string as the ID name. Make sure that getString/NSlocalizedString is used correctly where the described behavior occurs.

Yes, but you need at least one .string file in your project for every language. The file itself can stay empty.

Yes, but you need at least one .string file in your project for every language. The file itself can stay empty.

No. Applanga and Swift play nicely together.

Besides iOS and Android and their different flavors (e.g. Swift, SwiftUI, Kotlin, Jetpack Compose) we have SDKs for Flutter, React Native, Xamarin, and Unity. The Rest API or the CLI might also be suitable integration options, not only for mobile apps, but for any kind of string-based software localization use-case.

You can either create two separate projects - one Android and one iOS - or set up only one cross-platform project. Between the platforms, the string IDs will be different, but if both platforms have the same source language text for an entry, there are features like linking and the translation memory to match and reuse existing translations accordingly - you won’t have to translate the same text twice.

If you don’t want an entry translated in your app - in specific languages or in general - you can lock the entry using the lock symbol in the upper right-hand corner in the detail view or via the multi-edit actions.

On Android, you have the option to mark strings with the 'translatable="false"' attribute. String IDs marked this way won't be uploaded to the dashboard by the SDK.

You can only delete on the string Id level, including all source values and translations, but if you delete the string Ids only from the Dashboard and they are still present in the app, they will be reuploaded by the SDK.

Alternatively, you can simply lock your string Ids using the locking functionality and they can’t be edited anymore.

Please follow the 3 steps below:

1. From the Applanga dashboard, export the language you want to remove. The export format should be XLIFF, as it allows users to export most of the keys' metadata (comments, status and string length restrictions). We strongly recommend that you also create a manual backup of your project.
2. Delete the language from your project dashboard.
3. Update the Applanga Settingsfile and push a new app release.

Next time a user opens the app and the deleted language is selected, its content will also be removed from the SDK storage. The SDK storage will then apply the fallback logic and show the content in the base language (or the parent language if a dialect was deleted).

The SDK integration won’t overwrite any string values already existing on Applanga with (updated) values on the code level. This is done to maintain Applanga as the source of truth, enforcing those changes - even to the source - are made on Applanga

The only way to update the value is to remove the current one for a given string ID and save it with an empty value. Next time you start the upload, the dashboard will replace empty values with values found in the SDK.

Alternatively, if you want your developers to make changes to strings on the code level and those changes to be reflected on Applanga, the automated SDK upload can be disabled in the Project Settings and you could use the Applanga CLI instead. The CLI will recurrently upload your app’s string files and in turn also overwrite any values on Applanga with the values from the file.

Nope. If you foresee character limits within your app’s elements, such as buttons or menu items, there is a description field for each entry that can come in handy during the translation process to avoid overruns.

Yes. Links to be localized should be associated with a string ID in your code. Simply add the new link in the Target field and the link will be “translated” just like any other entry.

Yes! Please follow the Integration Guides for iOS or Android.

Yes! Please get in touch with us and we can help you out.

Yes, but not for every change. In order to make sure your app is shipped with the most recent version of your translations, we recommend you update the Applanga Settingsfile as part of compiling your release canditate. This will make sure that your app users with poor connection quality only have to download the small set of latest changes and not the whole language.

It should only take a few minutes to download the latest Applanga Settingsfile from the Dashboard and insert the file into your project. You can find scripts to automate the update of the Settingsfile as part of your build process in the SDK integration documentation in the platform-specific sections.

Advanced versioning options are currently in development; however, in the meantime here are a couple options to go about supporting different localized versions of your app:

• Support outdated IDs - Because some of your users might still use an older version of your app, you can just leave them in the Dashboard. This way, Applanga will maintain these string IDs, and they will not be deleted automatically. Newly added string IDs will be found, synced and added regularly to the same project on the Dashboard. They must be translated so that the localized versions containing these string IDs will include the localized content.
• Support different versions of the same IDs - If you have multiple versions for a single string ID, you should copy the current version of your app into a new project on the Dashboard and then edit and manage the string IDs in that project for the new version. Entries associated with the newly versioned string IDs can then be edited without affecting the original version of your app. Be sure to include the new Applanga Settingsfile into the newer version of your app.

If the design of your app changes between each version, make changes to the original text in the strings after copying the original strings into a new project created for the new version.

With an SDK integration, the content of the target text field represents what is currently live in your app. If that content is edited, the changes will be pushed to users and will be available the next time the app starts.

The second method to push translations is by approving the current Draft for a given entry. If approved, the Draft field content will move to the Target field.

The Draft field is used for translations in an unapproved state e.g. a proposed translation (change) that should still be reviewed before being published to Target. It is not visible to your regular users yet, but can be revised, tested, and QAed in the Dashboard or directly inside the app with the Applanga Draft Mode.

Yes! We provide a range of team and user management features that you can use to ensure only certain persons can approve translations to go live inside your app. Learn about the different Roles here.

Using Roles, admins and owners are able to assign the Translator role to other users. Translator roles are unable to alter the source or target text.

The language shown inside the the app (through the Applanga SDK) is determined by the phone language. If you want to preview another language, you will need to go to your phone’s settings and switch languages. If there is no translation available for the language selected, the Applanga SDK will always show the Base Language (most commonly English) as a fallback. See more here.

The SDK will fall back to the Base Language and, if that is not available either, to the original string that is present in the app data locally.

There are two ways to go about fixing this: 1) try to shorten the translations to match the length of the source entry or 2) use a smaller font size for particular languages.

NOTE: A good way of averting risk here is to use the description field associated with each text entry before translation. Insert character limits and/or screenshots where applicable.

iOS has two language lists: iPhone languages & preferred languages. Some languages, including Latvian, are only present in the preferred languages list.

IDs in Applanga can have a maximum of 1024 bytes wich is equivalent to a length of 1024 characters for most languages. Some special characters like emojis as well as some languages, for example Chinese, need more bytes per character in some cases and therefore the maximum ID length might be below 1024 characters.

Yes, you can implement the Applanga Rest API into your website or web app in a way that makes an update call to the API for every session of every user. Please do keep in mind that there is a traffic component to the Applanga pricing and every API call is counted against your limit.

We would rather recommend you update your backend or database on an hourly or daily cadence or even use the CLI to just update on every deployment.

You can separate your content into Branches based on language. This way, you can limit the number of languages in your Default branch and push over-the-air updates from it. The remaining languages can be added to another Branch, and you can merge it to the Default branch when needed.

Not at all! If you have your own translators (internal or external), you can create an account for them and add them to your app’s Team with the role “Translator.”

Yes. Applanga allows you to add resources to your projects, so you can create and add administrators, managers and translators for each of your app Teams.

If you would prefer to have our translators test your app in their native language, that is no problem. Just let us know.

No. We use industry standard CAT (computer-assisted translation) tools to develop translation memories for each project to ensure the best possible quality and price. Just let us know and we can merge translations into other apps and projects.

• If the original order is not yet in the processing status, the order can be cancelled and a new one can be created. This new order will capture the changes to the updated source content.
• If the order is already processing, you can wait until it is completed and submit a follow up order to include Outdated Translations.
• If the translations can't be delayed, you can create new string IDs in the project for those updated strings and create a separate order. See the Cloning Strings article for more information.

Yes, of course. You can test and evaluate all features of Applanga for free.

See Applanga’s full pricing structure, click here.

MAU stands for [M]onthly [A]ctive [U]sers and counts how many individuals use your app per month as a way to measure the traffic through update requests made to Applanga servers on a monthly basis. Only the first time a user opens the integrated app in a given month (and creates an update request) will increase the MAU count by one. Subsequent sessions of the same user in the same month will not increase the account.

Upgraded features are immediately available, and your account will be prorated for the current month. Downgrade changes will be enacted the following month.

When you're logged into your account, you can change your subscription in the Billing Menu or reach out to us directly at support@applanga.com.

We'll get in touch before that happens and, with your consent, move you onto a higher tier plan.

Paypal and credit card by default, but feel free to contact us for other payment options.

Yes, we offer invoicing for Enterprise-level plans. Please get in touch with us at support@applanga.com.

Please send an email with your questions to support@applanga.com