One of the biggest mistakes people make with localization is treating localization as an afterthought. We’ve had a lot of trouble with this ourselves, and we wanted to think of a simple way that will make life easier for both our developers and our clients.

Localization on both platforms works by using a key-value based system. Each language is a set of key-value pairs, where the key is the identifier for that specific string, and the value is the translated string in a specific language. The platforms are smart enough to supply the correct language for the given key.

When the time came to translate our iOS and Android app, we realized immediately we were in a tough spot.

For starters, iOS and Android were using different keys for the same strings. To make matters worse, some strings (like error messages) were completely different and had different keys!

The client and translator would supply us a list of strings. For each platform, platform developers would then have to figure out which string belonged to which key, and input that into a table for their platform manually.

This meant at least 4 people had to take time out of their day just to update texts in the app. Not only that, we had 3 separate copies of the texts that we had to manage and keep in sync manually.

We’re engineers, we don’t do things manually if we can help it.

Google Sheets to the rescue

Google Sheets has quickly become the next Excel. Because we are working across two offices in different parts of Europe, we use Google Drive, Google Docs and Google Sheets for almost all important documents. It keeps all of our documents in sync, and makes it easy to share and collaborate remotely.

So, our first step was to import all of the strings into a Google Sheet, so we have a single place where the client can see and edit all of the texts, and our developers can see all of the changes.

We added three columns to the sheet. The first one for the iOS keys, the second one for the Android keys, and the last one for the actual texts. When we add more languages, we simply add another column at the end with the texts of the other language. Remember, the keys stay the same.

We try to keep iOS and Android keys and texts identical. This isn’t always possible because of platform differences, so we keep two key columns, one for each platform.

Saving time

The next step was figuring out how to automate the process of entering all of the data into the apps.

Android and iOS have different syntax for this. iOS uses a Localizable.strings file, while Android uses a strings.xml file to store all the string-key pairs for a given language.

"login_button_title" = "Login";

"forgot_password_button_title" = "Forgot password";

Localizable.strings (iOS)

<?xml version="1.0" encoding="UTF-8"?>

<resources>

<string name="login_button_title">Login</string>

<string name="forgot_password_button_title">Forgot password</string>

</resources>

strings.xml (Android)

We need a way to get all of the data from the Google Sheet, and encode it for a specific platform.

One of the reasons a lot of people like using Google Apps is their JavaScript based scripting API called Apps Script. It lets you create little apps with UI elements like menu items, windows etc. inside the Google app.

Sheets offers a way to get all of the data from a specific sheet. We can use that data to create files for Android and iOS automatically!

We created a Custom Export menu item for sheets, with iOS and Android options.

Each export option will fetch all of the data from the sheet, take the keys for the specific platform and create the file in the format we expect.

That way, all our engineers have to do is copy and paste the whole thing into their project. Much less work!

Giving clients power

One of the biggest advantages of this system is that we gave the clients the ability to change the strings whenever they want. Clients no longer need to ping us to change a specific text. We give them full access to the Sheet so they can change any string at any time. Whenever we are making a new build of the application, we include the new strings.

This makes all of our lives easier, which is something we value the most in our app development process.

You can check out the script we use on our GitHub!

Next steps

We would like to automate this process even more. One of our ideas is fetching the sheet data dynamically inside the app, or automating it during our continuous integration builds.

If you have ideas on how to improve this, or have a comment, feel free to discuss it below!