Author: Adrian

App localization: reading language files from an API

App localization: reading language files from an API

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 userbase.

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.

Automating your localization workflow with POEditor API – Quick Guide

Whenever you get the chance to automate something to avoid repetitive manual work, go for it, because it will save you a lot of time and boost your productivity. That being said, let’s cut to the chase: the purpose of this article is to show you how to automate your localization workflow with the POEditor API. For this, we’ll go through a simple step by step guide. You’ll learn how to send your language data to POEditor and how to pull the translated work back into your software.

Knowledge of a programming language is required (any will do), but we’ll focus on the requests you need to make to the API.

All the information about the API is in the API Reference.

Before starting the actual work, get an API token from your POEditor account. You can find it in Account Settings > API Access.

Project setup

The first step is to create a project. Note that you need to do this only once and that you can also use the interface. It’s probably faster anyway.

Create a project:

curl -X POST https://api.poeditor.com/v2/projects/add \
-d api_token="e9eccebeccfr9wed638eb35f5e2d5600" \
-d name="Quick Guide"

Continue reading →

POEditor has a new Translation Memory Engine

esp_03Here at POEditor, we’re always trying to optimize and improve performance. For this reason, in the past few weeks, we’ve been really busy reconstructing our Translation Memory engine.

Given the growth rate of POEditor and the number of strings in large accounts, we began noticing some delay in the TM for suggested translations, especially when the system searched for translations of small strings (such as “Account” or “Cancel”). Some tests and debugging quickly pointed us to the database queries, which had become slower as the database increased.

We then took a radical decision, to move all the TM related searches to a dedicated search engine. After lots of research and tests, we choose Elasticsearch, which is based on the powerful Apache Lucene project. Elasticsearch is a flexible and powerful open source, distributed, real-time search and analytics engine, running on Java.

To cut the technical stuff short, the performance improved by a factor of more than 10 times in some cases and it’s expected that the future growth won’t affect the system performance as it did before this.

We would like to see you test the limits of the Translation Memory engine, with countless translations from old and new localization projects. You will surely be compelled by how this powerful piece of software enhances the automated part of the POEditor experience!

Continuous localization with Bitbucket integration

bitbucket-logoEver since we added the GitHub integration to POEditor, people have started requesting a Bitbucket integration. We’re not going to get into the GitHub vs. Bitbucket discussion, we’re just going to say they’re both pretty popular among software developers and both deserve the same attention. Today is the day Bitbucket fans get their version of this useful feature.

You can now set up the integration either via Project Import or directly from your Project Settings page. You’ll have to grant the POEditor APP access to your repositories and match your language files with the languages within your POEditor project.

Unfortunately though, Bitbucket users only get half of the pie. You can only import terms & translations from your repository, you can’t export them back from POEditor. This limitation comes from the Bitbucket API, which does not allow us to write anything in your repositories. The guys from Bitbucket promised at some point they’ll fix this, but it doesn’t seem very high on their priorities’ lists. You can change that by upvoting this enhancement on their issue tracker here. Pointing fingers done.

We hope you will enjoy this update and maybe one day we’ll be able to complete the feature with an export, if the guys there decide to offer us the possibility to do that via API. Questions and comments welcomed.