POEditor
From time to time, someone sets their (mobile) app to read language files directly from the POEditor API.
Subsequently, for every language update made in POEditor, even for the smallest typo or text change, an update is pushed to their app. At a first glance, it’s a great idea. Users will always have the latest language version. It becomes unnecessary to deploy new versions of the code/binary/app every time a new translation is added or changed. Also, errors are corrected quickly and spread instantly to the user base.
As attractive as the benefits of reading language files from an API may appear, there are issues with this approach. Some of them might even kill your app or you users’ experience with it.
Some of the pitfalls of loading language files to your mobile app from an API are:
- you rely on the client bandwidth (which might not be great);
- an API request takes longer than reading a cached file. In fact, to download a single language file, POEditor requires you to make 2 requests, first to generate a link and the second to actually download the file. Imagine doing that for 5, 10 or 20 languages;
- your own app’s success might be lethal. Reading language files from an API may work during tests and when you don’t have many users, but it doesn’t scale well. Imagine a sudden burst of thousands of users. All those users would have to download the language files roughly at the same time. That stress would have to be transferred to the source of the files, in this case the API.
- APIs are usually throttled, queued, rate limited, have concurrency protections etc. This is to protect from abuse, faulty scripts or bad software design. It would be no surprise if some your users end up not receiving the content they ask for.
If you don’t want to risk running into such issues and want to keep your mobile app successful, we recommend taking the following measures:
- keep a cached version of the language files in the app. Even if you update it later, your users will always have a running app;
- read the updated language files from the API yourself. You can control better how often you do that, what to do when it’s not working and what your users get;
- keep an updated version of the language files on your own server or some CDN that is able to handle spikes, bursts;
- always have a fallback in case a language file doesn’t work, is corrupted or incomplete.
We hope these recommendations will help you on your quest to making your app multilingual. App localization is not a journey without challenges, but taking the right steps, it can be less of a pain.
If you wish to learn more about how to work with the POEditor API, have a look here.