There are no special technical or architectural prerequisites for using GL Strings/Applanga mobile SDKs, but you need to have your mobile app prepared for localization for the given platform.

• On Apple devices your keys need to be in a .strings file in order to be automatically uploaded to the GL Strings 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 keys need to be in a string resource .xml file in the /res/values/ folder in order to be automatically uploaded to the GL Strings 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 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 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, when you download the Settingsfile from GL Strings - manually, via SDK build script or via CLI - all translations currently in your project are saved in the Settingsfile.
• Therefore, 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 Settingsfile on the device.

Your mobile app will use locally cached translations, either from the last successful over-the-air update from GL Strings, from the Settingsfile, or your actual string file within the app, so your users won’t be impacted if Gl Strings' servers are not be reachable for any reason.

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 with us for more information.

All our traffic is encrypted and we use an additional HMAC algorithm to ensure 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 GlobalLink Strings:

• You can simply translate it yourself, together with your team, or with external translators of your choice. 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 Translations can easily be ordered using our integrated Order Menu. Get in touch with us 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 valuable context for each key value. Both types of context can either be added manually through the dashboard, imported, or uplodaded via an integration.

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 keys to be sent from the app. Also, check the logs on the app start to find the SDK specific log messages informing you about the upload progress. If you’re still running into problems, find more troubleshooting information in our Integration Documentation.

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

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

It’s possible that the getString (Android)/ NSlocalizedString (iOS) method called on an already localized string. The method normally expects a key, but if it’s presented with a string, it will create an empty key with the string as the key 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. GlobalLink Strings' iOS SDK 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 key names will be different, but if both platforms have the same source language text for an entry, there are features like linking, placeholder conversion 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 keys with the 'translatable="false"' attribute. Keys marked this way won't be uploaded to the dashboard by the SDK.

You can only delete on the key name level, including all source values and translations, but if you delete the keys only from the projcect and they are still present in the app's string file, they will be reuploaded by the SDK.

Alternatively, you can simply lock your keys using the locking functionality and they are now excluded from the translation scope.

Please follow the 3 steps below:

1. From your GL Strings project, export the language you want to remove. The export format should be XLIFF, as it allows users to export all of the keys' values most of the metadata (comments, status and 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 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 key values already existing in your project with (updated) values from the code level. This is done to maintain GlobalLink Strings as the source of truth, enforcing those changes - even to the source - are made on the dashboard.

The only way to update the value is to remove the current one for a given key 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 keys on the code level and those changes to be reflected in your project, the automated SDK upload can be disabled in the Project Settings and you could use the CLI integration instead. The CLI will recurrently upload your app’s string files and in turn also overwrite any values in your projects with the values from the source file.

Yes! You can apply character restrictions to key values in the base or target languages. Currently, this can only be done through our dashboard or manual import of certain file formats (xliff, Excel, CSV). You can read more about our character restriction feature here.

Yes. Links to be localized should be associated with a key name 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 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 Settingsfile from your connected project and insert the file into your app. 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.

Yes! Our Branching feature allows teams to keep different versions of their app in the same project. All integration options can be configured to point to a specific branch of your project. How you configure that depends on how Branches in your project should mirror your application’s development processes, release management, or app environments.

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 editor interface or directly inside the app with the SDK 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 o 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 key that is present in the app data locally.

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

Key names in a GlobalLink Strings project 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 length might be below 1024 characters.

Yes, you can implement the 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 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.

Since GL Strings is a web-based tool, we use text rendering behaviour that is inherited from the browser. In some cases, the browser can't determine if a character is meant to be right-to-left or left-to-right so it falls back to the default. However, the output when the translations are exported from GL Strings into the target file should display correctly, as long as the target file format also supports RTL.

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. GlobalLink Strings 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 keys in the project for those updated keys and create a separate order. See the Cloning Strings article for more information.

Yes, of course. You can test and evaluate most features of GlobalLink for free for a limited time.

See GlobalLink Strings' 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 GlobalLink Strings' 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 billing period. Downgrade changes will be enacted the following billing period.

To upgrade your subscription, please reach out to us at support@applanga.com.

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

TransPerfect operates globally. We can offer a wide range of billing and payment options and can bill you from a local entity.

Yes, you will be invoiced for any kind of GlobalLink Strings subscription.

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