BlogHow-to?InsightsBest Practices

How to Use Applanga for Multi-Platform Localization

Managing the localization process across multiple platforms can feel like double or even triple the translation workload! At Applanga, we can reduce that workload with some of our most popular features like placeholder conversion and the translation memory.

Many teams develop apps for two or more platforms – say, iOS and Android. When it comes to the localization process, it can feel like double the workload. However, with a mix of Applanga features specifically designed with that use case in mind, you can easily manage localization across multiple platforms.

In some cases, key names and values are the same and sometimes they differ. Applanga can help you avoid double the translation work and keep an organized project using our most popular features like tags, placeholder conversion, and the translation memory.


Managing multiple platforms within one Applanga project

This setup is recommended when:

  • multiple platforms use the same key naming conventions
  • maintaining uniformity of translation across multiple platforms takes precedence

Applanga allows users to connect different integrations to a single project. So if your app shares a lot of the same content across all different platforms, one project can be used to manage the translation process for such a setup. In this case, your team will just need to configure the two (or more) different integrations to point to the same Applanga project. Please note that each SDK integration can only point to one project at a time, while each project can integrate with multiple, different SDKs.

The use of a single project to manage the localization of multiple platforms can have several advantages over using multiple projects. The obvious advantage being that it’s just one project to keep track of. The single project can help streamline translation workflows and make it easier to upload screenshots for that valuable translation context. In this case, users only need to create one order to capture all content for translations and users only need to upload screenshots to one project.

To keep things organized, we recommend you dedicate a tag for each integration and even use tag categories to differentiate between tags associated with each integration. For example, tagging all entries from an Android integration with “Android” and all entries from an iOS integration with “iOS“. With the Applanga CLI or API, you can automate that tagging process during the upload. If you’re already using several tags and don’t want to add more, you could also use tag categories. Applanga tag categories include: iOS, Android, Web, and JIRA or even create your own custom ones. Just assign the respective category to the tag associated with each integration option. For more information on Applanga Tags and Tag Categories, see our tags page.

To further reduce the translation workload, users can link duplicates. In the context of this example, if both the Android and iOS apps’ content are almost identical while the key naming differs wildly, then the integrated Applanga project will end up with a lot of duplicates. Instead of sending these individually for translation, duplicates can be linked to one entry in Applanga. Whenever a translation (change) is applied to that single entry, all the others linked to it will inherit that same translation. If there is an outlier, a key that has the same content, but still requires a different translation, it can still be omitted from linking. See the Linking Strings documentation for more info.

Last, but certainly not least, users can use the new Placeholder Conversion feature to quickly export translations for either iOS or Android even though the strings only contain the appropriate variables for one of those. Placeholder conversion allows teams to use the same strings for both iOS and Android projects where only the placeholder would differ. This feature is only available for the CLI, iOS and Android SDK integrations. It can also be used with manual exports for both .string and Android xml file types via an advanced export option.

Single project considersations

If you are planning to use one project to manage the localization of multiple platforms, there are some considerations to keep in mind.

Applanga requires the use of unique key value pairs. Each key must be unique regardless of its source. If you are using the same keys, but with different values across platforms, then these keys cannot co-exist in the same Applanga project; the values would overwrite each other. In this case, users should ensure keys are unique across platforms or use a different project for each platform.


Managing multiple platforms with multiple projects

This setup is recommended when:

  • the release cycles and/or feature sets differ between platforms
  • different sets of languages should be supported for different platforms
  • the the translation status per platform needs to be visible at the project level

If you want to remove any possibility of confusion for team members and generally have the resource to put into ensuring the most precisie and specific transaltions, you could also manage the translation of multiple platforms using separate projects. However, these separate projects must reside with the same team to give the same set of users the same level of access to the same projects.

The use of two or more projects to manage the localization of multiple platforms can prevent confusion and reduce the need for excess tagging and tracking of source content from different platforms inside the same project.

In the case of multiple projects, to prevent doubling the translation workload, the Applanga Translation Memory (TM) can be used to apply the translations from one project to another. Users could e.g. upload Android content to one project, iOS contents to another, but only one project must be sent for translation. Once one project is translated and those translations are approved, simply translate the other project using the Translation Memory.

The TM will ensure consistent translations across both projects while translators avoid translating the same content twice. Even if there are some differences between the two sets of app content, the TM will ensure that you can reduce the number of strings included in a second translation order. See the Translation Memory documentation for the full outline of the process.

TM & multiple project considerations

If you are planning to utilize the Applanga Translation Memory and multiple projects to handle your multi-platform localization needs, there are some considerations to keep in mind.

The TM will need to be monitored and updated as new source text and translations are added to an Applanga project. The TM must also be maintained to ensure the most accurate and up-to-date translations. This can become a more time intensive task depending on the number of languages and entries supported by your app and the corresponding projects. However, a well-maintained TM will enforce translation consistency across an app’s multiple platforms.

If a TM cannot be maintained, then linking of strings within a single project may be a more appropriate option.




While it’s best to start with the multi-platform option that fits your needs, it’s not necessarily set in stone. Whether you start out with one project or more, if that workflow does not accomplish your desired localization goals you can always split or merge projects. However, if you do need to switch from one project to multiple or vice versa, this can be a labor intensive process. You’ll need to ensure that all existing translations are accounted for, all tags and tagged content must be copied between projects, screenshots must be migrated according to the project, and there can be no open translation orders.

Still have questions or need help with creating or migrating a cross-platform localization setup on Applanga? Reach out to us at support@applanga.com!



Related Articles