FAQ Frequently Asked Questions
- 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.
There are some tweaks for the different platforms we support but in general there are two parts: the SDK and the Applanga Settings File. 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.
- 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 into the Applanga Settings
Always include the latest version of the file within the build that you submit to the app stores to ensure that the translated content is available. If your users have insufficient internet connection for live updates, the SDK will revert to the translation inside the Applanga Settings File on the device.
When the app is initially started, the Applanga Settings File is parsed and all contained strings are put into a cache database, which in turn gets updated on every successful request to the Applanga backend. If, for example, the app doesn't have network, it still has all the cached strings from the Applanga Settings File. When a string is not found, neither through an update request nor in the Applanga Settings File, the SDK falls back to check if the string is in the strings files from the app itself.
Your latest changes will be always available for the SDK to fetch. We use the Amazon content delivery network (CDN) to distribute your translation through data centers all over the world and therefore provide high reliability, availability and redundancy.
- You can simply translate it yourself, together with your team or even with remote, external translators. Simply add them to your Team in the Dashboard - the number of accounts is unlimited.
- You can use the integrated machine translation tool (but we recommend you only use it for testing purposes or if you don’t worry about translation quality).
- To get the very best quality of translation we recommend using our professional translation services. We will implement an order menu into the dashboard soon. In the meantime, we will handle your orders personally. Get in touch if you are interested in knowing more.
Technical Issues & Platform Features
When locked, a string will then default to the Base Language and if there is no Base value either, to whatever value the operating system returns for that key. On Android you have the option to mark strings with the 'translatable="false"' attribute. Those strings won't be uploaded to the dashboard.
- 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 app on the Dashboard. They must be translated so that the localized versions containing these string IDs will have 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 app in the Dashboard and then edit and manage the string IDs in that app for the new version. Entries associated with the newly versioned string IDs can then be edited without affecting the original version of your app. Make sure to include the new Applanga Settings File into the newer version of your app.
Since it is not possible to perform the four-finger gesture on the simulator screen, we use other methods to start the Draft mode.
On iOS: while the app is running, hold Alt and click on the screen. Hold for four seconds.
On Android: while the app is running, click on the screen and hold for four seconds
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 when applicable.
Yes! We do support regional dialects.
If you want your app to be translated in Portugal (PT) as well as Brasil (PT-BR) you should add both languages to the Applanga dashboard.
If an app requests a dialect (e.g. PT-BR) the SDK will first check if there are translations in that language-dialect (PT-BR) but if a string is empty or the dialect does not exist it will fall back to the superordinated language (PT). If the string is empty there as well it will fall back to the base language.
If you only create and translate the regional dialect (eg. PT-BR) and not the original language (eg. PT), only users with their phone set to the region will get the translation. Everybody else that is requesting the original language or another regional dialect will get the Base Language localization.