Localization of mobile applications on the example of iOS. Implementation, support and development in the next versions
My colleague, Vyacheslav Budnikov , a leading developer of mobile applications for iOS, decided to share his experience in ordering localization of projects.
Localization of a mobile application involves translating the interface and adapting the software for use in another language. Tinkoff Bank mobile application is used only by Russian-speaking clients, so we did not have such a task. But the principle of localization was applied to restore order in the texts, to make it easier to read, check for errors and edit.
Consider the localization of text elements on the example of iOS. To do this, use the Localizable.strings list, which describes all the phrases in the format “key” = “localized value”. Each localization language has a different key value.
')
Important:
Localization was implemented in the development of MB 2.0 - the second version of the mobile bank Tinkoff. Initially, localized strings were carried out in Localizable.strings, filled in the missing strings before testing, modified and added new strings during testing. Next, they made a new assembly and checked everything. And so for each platform.
Naturally, errors occurred. Therefore, they included localization in the TZ and began to take all the values ​​from the documentation, which made it possible to synchronize the localization between the platforms and get rid of different localized names.
The method did not get rid of all the problems. There were situations when it was necessary to change the phrase only on one screen or only for one script. It was necessary to carefully look at the search results wherever the old key was, change it to a new one, observing the new logic. There were often errors that we saw only at the testing stage.
The next step was to use not localized strings in the code, but pointers to localized string constants. This eliminated the magic lines and misprints.
How to do it
An example of a functional description in a statement of work:
We write the TK text in the wiki and store it in html, in the source code it looks like this:
To search for such phrases, we use a script that finds these phrases and creates a list of “key” = “value” of the form: “main_continue” = “Next”. This is the main list of localized phrases that we will use in the application.
Further, on this list we create 2 more lists:
And save them to 3 files:
We replace these files in our project and collect it. Now you can use the localization keys as follows:
NSLocalizedString (LocKey_common_error, @ "");
If at the next localization update the project is not going to, then the necessary constants have been deleted or renamed. Therefore, we either change them in the code, or return to the TK.
Thus, with each change in the TZ, new files Localizable.strings LocalizableKeys.h LocalizableKeys.m are generated and the project is assembled. As a result, we get full compliance with the technical requirements and their implementation.
The advantages of our approach:
This approach will help bring order to the TOR, even if you do not have the task to translate the mobile application into other languages.
When writing autotests to identify objects on the screen, we need unique keys for all interface elements - a text input box, a button, and so on.
In the same way as in the localization, assign accessibilityLabel constants to the TK to the objects and add a style for processing phrases for autotests.
An example of a functional description in a statement of work:
We write the TK text in the wiki and store it in html, in the source code it will look like this:
As a result, we obtain:
In code, it looks like this:
Now for writing autotests you need an application and TK. For multiplatform applications, you can use the same autotest scripts for all platforms.
Introduction
Localization of a mobile application involves translating the interface and adapting the software for use in another language. Tinkoff Bank mobile application is used only by Russian-speaking clients, so we did not have such a task. But the principle of localization was applied to restore order in the texts, to make it easier to read, check for errors and edit.
Consider the localization of text elements on the example of iOS. To do this, use the Localizable.strings list, which describes all the phrases in the format “key” = “localized value”. Each localization language has a different key value.
')
Important:
- follow the writing of string keys in the code, otherwise, instead of a localized phrase, we get a “technical” phrase (the name of a constant);
- make sure that each key has localized values;
- make sure that localization on all application platforms is identical. If there is a new version of the application, you need to check existing phrases.
Where to begin
Localization was implemented in the development of MB 2.0 - the second version of the mobile bank Tinkoff. Initially, localized strings were carried out in Localizable.strings, filled in the missing strings before testing, modified and added new strings during testing. Next, they made a new assembly and checked everything. And so for each platform.
Naturally, errors occurred. Therefore, they included localization in the TZ and began to take all the values ​​from the documentation, which made it possible to synchronize the localization between the platforms and get rid of different localized names.
The method did not get rid of all the problems. There were situations when it was necessary to change the phrase only on one screen or only for one script. It was necessary to carefully look at the search results wherever the old key was, change it to a new one, observing the new logic. There were often errors that we saw only at the testing stage.
The next step was to use not localized strings in the code, but pointers to localized string constants. This eliminated the magic lines and misprints.
How to do it
- Add localizable.strings file;
- Add 2 files for string constants:
LocalizableKeys.h
LocalizableKeys.m; - For TK, choose a style for localized phrases.
An example of a functional description in a statement of work:
If you press the "Search" button ( main_continue ) on the screen 1.1 then ... "
We write the TK text in the wiki and store it in html, in the source code it looks like this:
"" (<span style="color:red">main_continue</span>) 1.1 Implementation
To search for such phrases, we use a script that finds these phrases and creates a list of “key” = “value” of the form: “main_continue” = “Next”. This is the main list of localized phrases that we will use in the application.
Further, on this list we create 2 more lists:
- For a header file: extern NSString * const LocKey_main_continue;
- Implementation: NSString * const LocKey_main_continue = @ "main_continue";
And save them to 3 files:
- Localizable.strings - the file in which the key-value localization for each localization language lies
"main_continue" = ""; "common_error" = ""; - LocalizableKeys.h
import <Foundation/Foundation.h> extern NSString *const LocKey_main_continue; extern NSString *const LocKey_common_error; - 3.LocalizableKeys.m
#import "LocalizableKeys.h" NSString *const LocKey_main_continue = @"main_continue"; NSString *const LocKey_common_error = @"common_error";
We replace these files in our project and collect it. Now you can use the localization keys as follows:
NSLocalizedString (LocKey_common_error, @ "");
If at the next localization update the project is not going to, then the necessary constants have been deleted or renamed. Therefore, we either change them in the code, or return to the TK.
Thus, with each change in the TZ, new files Localizable.strings LocalizableKeys.h LocalizableKeys.m are generated and the project is assembled. As a result, we get full compliance with the technical requirements and their implementation.
The advantages of our approach:
- the integrity of all keys is checked by the compiler. If such a constant was removed from the localization, the compiler will tell us about it when building;
- the name and value of the keys regulates the TZ;
- When writing code, you can use the contextual help, which significantly increases the speed of writing code;
- Another person who is following the localization is connected to the reading of the TOR.
This approach will help bring order to the TOR, even if you do not have the task to translate the mobile application into other languages.
An example of using the localization approach for autotests
When writing autotests to identify objects on the screen, we need unique keys for all interface elements - a text input box, a button, and so on.
In the same way as in the localization, assign accessibilityLabel constants to the TK to the objects and add a style for processing phrases for autotests.
An example of a functional description in a statement of work:
“If the“ Continue ”button ( main_continue btn_continue ) is pressed on screen 1.1 then ...”
We write the TK text in the wiki and store it in html, in the source code it will look like this:
« "" (<span style="color:red;">main_continue</span> <span style="color:blue;">btn_continue</span>) 1.1 » As a result, we obtain:
- AccessibilityKeys.h
#import <Foundation/Foundation.h> extern NSString *const AccKey_btn_continue - AccessibilityKeys.m
#import "AccessibilityKeys.h" NSString *const AccKey_btn_continue = @"bnt_continue"
In code, it looks like this:
UIButton *buttonRegistration; [buttonRegistration setAccessibilityLabel: AccKey_btn_continue]; [buttonRegistration setTitle: NSLocalizedString(LocKey_main_continue, @"") forState:UIControlStateNormal] Now for writing autotests you need an application and TK. For multiplatform applications, you can use the same autotest scripts for all platforms.
Source: https://habr.com/ru/post/271459/
All Articles