Simplify localization in iOS

Good day to all! My name is Nikolai, I am iOS-Lead at Touch Instinct . In the development process often have to deal with projects that need to work in several languages. I'll tell you what approach we came up with when working with localization.

Cons of basic approaches

There are several basic approaches for localizing an iOS application. First you need to decide whether the application is being developed using storyboards or not.

Using storyboards

You can localize the lines directly in the storyboard. However, with this approach there are a number of minuses:

• in the case of a large number of storyboards, localized lines are scattered around the project;
• the inability to use attribute lines, as well as lines that consist of several component parts;
• you still have to localize part of the lines in the code. This leads to even more variation in the application;
• In fact, there is no possibility to check something for another developer when conducting a code review.

No storyboards

In this case, we localize everything in the code. However, there are a number of drawbacks. The fact is that files with localization strings localizable.strings are magic. When such files change, the probability of an error due to the human factor is very high. Changes cannot be tracked until an error is found during the testing process.

Thus, although there are already ready mechanisms for localization in the iOS SDK, they have significant drawbacks. See here for more details.

We understand the goals

If the standard solutions do not cope, you should not immediately rush to make your "bike". Formulate goals to be achieved.

The main criteria that a future solution must meet are:

• integration of localization resources for all mobile platforms supported on the project. In mobile development, we most often do a project right under several platforms, usually iOS + Android. The same application on different platforms will use the same resources for localization. At the same time it should be possible to have specific lines for each individual platform.
• automatic addition of new localization lines in the project without the participation of the developer. If the application uses multiple languages, the resources will be filled either by a translator or an intermediary between the translator and the project. The mediator can be a manager or other team members. Giving access to the code to non-technical experts is moveton. It is best to keep localization resources somewhere in a third-party location. At the same time it is necessary that developers do not add these resources “hands” every time.
• detection of errors in the project when changing localization resources at the compilation stage. The standard approach, which uses NSLocalizedString, assumes that if the string itself changes to localizable.strings, but the code does not change, then the application will be released with an error. The very first screen for finding an error should be the project build process. Changes to the localization strings, as well as errors resulting from changes, must be obtained at this stage.
• no magic lines in the project. Any magical value in a project is evil. You can clean them in different ways. There is a path to the comments to the code or making magic values ​​in constants with speaking names.

Touch Instinct localization

Create a repository for strings

First you need to create a separate repository in your version control system. What should be stored in this repository? It's simple. Here json files of the common_strings_eng.json / common_strings_ru.json / etc type are stored. A separate json file is created for each language.
Consider the contents of such files. Json is a text format for describing data as key-value pairs, so we create a key-name for each localized string and use it in all files. Value is a localized value and will be displayed in the application itself.
Our company has a styleguide to unify the keys in all applications and make them consistent within each project.

An attentive reader may have several questions:

1) When filling in json files, you can make a mistake and, for example, forget to fill in the value for some key in a certain language?

Yes, it's true. However, here responsibility is escalated to the level of a translator or a single person. At the same time, you can easily create a script that goes through all the json files and shows where and what is missing in the files.

2) This system uses an “old” system for working with Plural . Is it convenient?

A small educational program, what is plural. In fact, these are noun forms depending on its quantity. Example: 1 day, 2 days, 5 days. Indeed, you can often hear from developers that working with the plural is difficult. However, we concluded that such resources are extremely small in applications. Receiving other benefits, this can be neglected. About work of the standard mechanism for work with plural in the form of the dictionary you can look here .

Now we have a separate repository in which localized resources for the project are created.

Example:

{ "common_global_error": "", "common_notifications_no_new_notifications": "    ", } 

Localize the application

A repository with strings must be connected as a submodule to your project. What does this give? If you do not need the latest version of the strings, you simply do not update the version of the submodule, and the translator / designers / other interested parties can easily create resources for the next versions.

In the process of developing our projects, we decided to use localization in the code, even if storyboards are used.

After connecting the submodule, we still need to somehow get the strings in the application to use them. To do this, create a script and add it to the build phases as a run script.
For the script itself, we will use php. However, you can rewrite it into any other scripting language.

We put this script to us in the project. Now add to our run script.

 php ./common_strings/import_strings.php 

Pre-call it, for example, "Localization". Very often, we have to see third-party projects that have run scripts that are not named in any way. Therefore, it is impossible to understand what is happening there.

')

Create in advance empty localizable.strings files in the project, as well as String + Localization.swift. After the first build (cmd + B), we have completed localizable.strings files in our project, as well as the String + Localization.swift file. If the script is not executed or is executed incorrectly, make sure that you have previously created these files, as the script is responsible only for filling.

An example of the finished file Localizable.string (Russian)

An example of the finished file String + Localization.swift

In addition, for ease of localization, create an extension for the String .

Now we can use strings from String + Localization in the project. For example:

 emptyLabel.text = .commonNotificationsNoNewNotifications 

However, this is no longer a magic string. When you hover on it, you can also see the translation of the word in a language that is most understandable to the developers of the project.

If the project uses the .commonNotificationsNoNewNotifications line, and then the translator removes it in the new version, then the developer will display a compilation error. Because this line no longer exists in the project and needs to be corrected. We predictively got an error about changing the resource and did not release it in production / gave it to testers / etc.

As a result, we get a system for working with localization, which meets all the goals. In this way, have already done several projects. I hope that this technique will help you simplify the process of localizing applications, as well as make it less dependent on developers.