Internationalize your App (II)
Internationalize your app (II)
Welcome to second part of this series of articles in which I explain an approach to the problem of how to manage the string files for a multi language app. If you have not read the first article, I really encourage you to do it by clicking here.
This time we will focus in the different components that forms the solution.
Overview
In the diagram above you can appreciate three vertical layers, from top to bottom: Android & iOS which represent the platform dependant strings, above we have Product strings which represent the single source of truth for the existing strings and last but not least, Weblate, which represents the tool for Product Managers to manage the product strings. Let’s break it down bit by bit.
Product strings (.po)
This represents the most important component in the diagram and it is the new guy in the block. This is a monolingual .po file which represents the new single source of truth for the product strings.
But, what is a .po file and how does it looks like? .po files comes from the GNU gettext internationalization(i18n) library. In other words, is one of the existing formats to get a text localized out there on the Internet and it is open source, which makes it compatible by many tools in the market, including Weblate (we will talk about it further in the article).
We use the monolingual approach, which means that there are as many .po files as languages you want to translate. Basically the same than Android or iOS do.
Let’s have a look at how a .po file looks like for two different languages (EN and ES).
From line #1 to #14 you can find the auto-generated headers. They are interpreted by the reader tool and we do not have to take care about them. From line #16 on you can see how .po file works actually. It is as easy as for the same msgid in both files different msgstr . As I said, it is the same mechanism than we do in Android with XML files or in iOS with property files (.strings).
It is important to take into consideration that this is not the only way to achieve the target solution, choose the format that best fit your needs as we chose gettext.
Android and iOS
With Android the solution to localize the text is pretty obvious since it is directly provided by the framework, the well known xml files.
On the other hand, the framework mechanism that iOS offers to translate the app is through NSLocalizedString , which indeed it is not the best solution out there since it is not type safe. See this interesting article to know more about the iOS standard localization tooling.
All in all, we decided to rely on SwiftGen to do make the work done. I will not explain how it works since it is out of scope of this article.
Both Android and iOS texts will be autogenerated by the strings framework (more information below) from the .po files.
Weblate
Weblate is one of the tools out there that allow us to manage the project strings from a fancy web user interface.
This tool is open source (SAS options available) so that we can install it in our servers.
If you are a developer you will not spend so much time in this tool, but if you are a Product Manager (or translator) the situation changes radically. Weblate (or any other translation tool that supports gettext) will be your reference site to watch and modify any existing string in the project.
The practical use case for us is: the main team adds a few new strings (within the .po file) to build some fancy new feature, then, if we had not this solution implemented we probably miss to translate those strings (nobody told us about them and no time to check feature by feature if new strings was added). At this precise moment Weblate comes into play and send the Product Manager/translator an email notification to let him/her know that new strings are pending to translate. Now, the Product Manager/translator translates all these untranslated strings (through a straightforward web tool) and all of a sudden those strings are included in the app for its next release version (there is some continuous integration magic here that I will explain in future articles).
All of this without developer interaction.
Again, choose the translator tool that fit best your needs.
Strings Framework
The strings framework is the icing of the cake for the solution as a whole. This framework is just a set of different scripts that, taking as an input the single source of truth (remember, our .po files), is able to generate string files for the different platforms. I.e. it generates a xml. file for Android and a .string file for iOS. Given the .po files from the example above, these would be the platform dependant results.
Android:
iOS:
In order to create the string framework we chose Python. Feel free to use the scripting language that best fit your needs. Tip: regular expressions will be your close friend for this job.
My last advice would be to create a new git project to host the framework so that it can be shared between different apps or modules.
That’s pretty much all about the solution overview. Stay tuned to know how to prepare the ground to, given an existing project, start using the solution.
