How to write software for the whole world
Among software developers, it has always been assumed that localization is a very expensive and time-consuming exercise, so it is always better to restrict yourself to one language first, and add support for others later as needed. Because of this attitude, no one most often thinks about supporting multilingualism in the early stages of developing new software, and many products end up being made in such a way that localizing them later is much more difficult than it should be.
In fact, in writing software, which is subsequently easily localized, there is nothing terribly difficult if you start writing with regard to the final result. At Alconost, we have translated an article for you about techniques that can seriously reduce the amount of work for yourself at the moment when your product does become international.
Definitely the most important (and most ignored) rule of preparation for localization is the separation of all the lines visible to the user from the code that uses them.
')
The usual approach in this case is to store the textual content of the product in separate resource files for each platform or language. For example, Java programmers should keep their display strings in ResourceBundle files.
Text in applications should never be structurally tied to the application logic. Displayed lines should always be accessible for changes without affecting the operation of the application or other functionality.
What is interesting: this task is becoming less and less important for web applications due to new technologies that can automatically extract text content from code and send it to people for translation, and then publish ready localized content online - all this without any changes in the original application code. This approach can significantly reduce the effort and time to make the application multilingual.
English phrases can become twice as long when translated into other languages, and in some languages they can be significantly reduced. It is critical that the components of the program code and the graphical interface do not depend on the constant length of the displayed lines.
This, of course, will add work when creating a graphic representation of the text to the user, but there are many ways to do it correctly .
For everything except company or product logos, you need to avoid using images that text is part of, as it will be more difficult to translate this text content. Instead of someone just quickly translating the contents of a text file, you have to hire graphic designers who transform the images and place the translated text on them, separately for each language.
Code writers should always remember that other countries can:
Put all of this on the checklist that checks your code to prevent any hardcoding that can limit the multilingual use of your product.
Always use established international storage standards. For example, use E.164 for phone numbers, ISO-8601 for time stamps , ISO 639.2 for languages, ISO 3166 for countries, and tz database for time zones.
In the past, developers who created software for exclusively English-language markets quietly implemented techniques in their code that worked only when using ASCII encoding. For example, changing one bit in an alphabetic character from ASCII switched its register from lower to upper. However, since then, the needs of the world have long exceeded the capabilities of ASCII, and now Unicode is adopted as the correct way to encode text data and support international characters.
Even with some Unicode compatibility with ASCII, the best way to avoid problems with string encoding is to follow these rules:
Fortunately, some of the most popular programming languages today, such as Java, C # and Objective-C, contain built-in Unicode support in string types. Their use turns the solution of the problem of international symbols into a common thing.
Even if the application fully supports Unicode, it probably stores data in a database, and a poor logical data structure can easily destroy all the excellent work done in the code for compatibility with international encodings. For example, in SQL Server database, display strings should be stored in nvarchar types, and in MySQL it is best to use utf8mb4 .
You can read more about Unicode in a good introductory article by Joel Spolsky .
The most common difference in displaying text is from right to left , as in Arabic and Hebrew.
In a web application, the main problems that arise when translating into right-to-left-read languages can be solved by simply changing the CSS direction property for the entire system.
It also happens that the text is read from top to bottom , although much less frequently .
When localizing application messages for other markets, translators will find it much easier to work with plain and simple text.
Too technical language, similar to technical jargon, is unlikely to be well translated. Better use common phrases and terms instead of niche and rare ones.
Good developers instinctively write automated tests for the capabilities of the product they create. Adding a few more tests to the product verification kit to ensure that the product supports international characters is a very valuable and not such a big deal of effort.
For example, imagine a web application for booking tickets for concerts. Suppose a test has already been written to check whether a user with a fake name “Ivan Ivanov” can reserve a place for himself and make sure that his name is correctly displayed on the ticket that he will receive after payment. Adding a simple test that changes the username to “Ivan- 假 会 河 Ivanov- 沖 鈈 批” and keeps track of the same characters displayed on the ticket after payment, will make sure that support for international characters works both in the application and in the database. This simple approach (sometimes called “ pseudolocalization ”) allows developers to check whether their application supports the transmission and storage of strings with international characters, without having to order a full professional translation of the product or sound language knowledge from the developers themselves.
Automated tests are capable of more. With their help, you can check whether right-to-left-readable fields work correctly or whether international plural forms are supported without having to redo the basis of the product code.
Developing software that is ready for international use is not as difficult as it may seem or how it once was. By following these simple rules and doing a little more work at the beginning, you can create software products that are subsequently suitable for use in much larger markets than you planned. So, your useful product will become more accessible!
We at Alconost are always happy to help you with the professional localization of your software - quickly and efficiently .
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
In fact, in writing software, which is subsequently easily localized, there is nothing terribly difficult if you start writing with regard to the final result. At Alconost, we have translated an article for you about techniques that can seriously reduce the amount of work for yourself at the moment when your product does become international.
Store user-visible strings separately.
Definitely the most important (and most ignored) rule of preparation for localization is the separation of all the lines visible to the user from the code that uses them.
')
The usual approach in this case is to store the textual content of the product in separate resource files for each platform or language. For example, Java programmers should keep their display strings in ResourceBundle files.
Text in applications should never be structurally tied to the application logic. Displayed lines should always be accessible for changes without affecting the operation of the application or other functionality.
What is interesting: this task is becoming less and less important for web applications due to new technologies that can automatically extract text content from code and send it to people for translation, and then publish ready localized content online - all this without any changes in the original application code. This approach can significantly reduce the effort and time to make the application multilingual.
Note that the displayed lines may be longer or shorter.
English phrases can become twice as long when translated into other languages, and in some languages they can be significantly reduced. It is critical that the components of the program code and the graphical interface do not depend on the constant length of the displayed lines.
This, of course, will add work when creating a graphic representation of the text to the user, but there are many ways to do it correctly .
Use images without text
For everything except company or product logos, you need to avoid using images that text is part of, as it will be more difficult to translate this text content. Instead of someone just quickly translating the contents of a text file, you have to hire graphic designers who transform the images and place the translated text on them, separately for each language.
Consider differences in the formats of the calendar, time, phone numbers and currency systems
Code writers should always remember that other countries can:
- use a different date and time format;
- take weekends other days of the week;
- use a completely different calendar system ;
- prefer to use the numbers of weeks , rather than the names of the months;
- be in a time zone with a displacement step of less than an hour ;
- use another system of measures ;
- use another currency or several other than yours;
- have a different format of telephone numbers .
Put all of this on the checklist that checks your code to prevent any hardcoding that can limit the multilingual use of your product.
Always use established international storage standards. For example, use E.164 for phone numbers, ISO-8601 for time stamps , ISO 639.2 for languages, ISO 3166 for countries, and tz database for time zones.
Avoid ASCII, use Unicode
In the past, developers who created software for exclusively English-language markets quietly implemented techniques in their code that worked only when using ASCII encoding. For example, changing one bit in an alphabetic character from ASCII switched its register from lower to upper. However, since then, the needs of the world have long exceeded the capabilities of ASCII, and now Unicode is adopted as the correct way to encode text data and support international characters.
Even with some Unicode compatibility with ASCII, the best way to avoid problems with string encoding is to follow these rules:
- never allow encoding of characters in ASCII;
- never rely on the fact that one byte is equal to one character;
- always use Unicode-supported fonts and libraries.
Fortunately, some of the most popular programming languages today, such as Java, C # and Objective-C, contain built-in Unicode support in string types. Their use turns the solution of the problem of international symbols into a common thing.
Even if the application fully supports Unicode, it probably stores data in a database, and a poor logical data structure can easily destroy all the excellent work done in the code for compatibility with international encodings. For example, in SQL Server database, display strings should be stored in nvarchar types, and in MySQL it is best to use utf8mb4 .
You can read more about Unicode in a good introductory article by Joel Spolsky .
Note that the text is not always read from left to right.
The most common difference in displaying text is from right to left , as in Arabic and Hebrew.
In a web application, the main problems that arise when translating into right-to-left-read languages can be solved by simply changing the CSS direction property for the entire system.
It also happens that the text is read from top to bottom , although much less frequently .
Visible to users of the text should be simple
When localizing application messages for other markets, translators will find it much easier to work with plain and simple text.
Too technical language, similar to technical jargon, is unlikely to be well translated. Better use common phrases and terms instead of niche and rare ones.
Test basic multilingual support
Good developers instinctively write automated tests for the capabilities of the product they create. Adding a few more tests to the product verification kit to ensure that the product supports international characters is a very valuable and not such a big deal of effort.
For example, imagine a web application for booking tickets for concerts. Suppose a test has already been written to check whether a user with a fake name “Ivan Ivanov” can reserve a place for himself and make sure that his name is correctly displayed on the ticket that he will receive after payment. Adding a simple test that changes the username to “Ivan- 假 会 河 Ivanov- 沖 鈈 批” and keeps track of the same characters displayed on the ticket after payment, will make sure that support for international characters works both in the application and in the database. This simple approach (sometimes called “ pseudolocalization ”) allows developers to check whether their application supports the transmission and storage of strings with international characters, without having to order a full professional translation of the product or sound language knowledge from the developers themselves.
Automated tests are capable of more. With their help, you can check whether right-to-left-readable fields work correctly or whether international plural forms are supported without having to redo the basis of the product code.
Embrace global opportunities
Developing software that is ready for international use is not as difficult as it may seem or how it once was. By following these simple rules and doing a little more work at the beginning, you can create software products that are subsequently suitable for use in much larger markets than you planned. So, your useful product will become more accessible!
We at Alconost are always happy to help you with the professional localization of your software - quickly and efficiently .
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
Source: https://habr.com/ru/post/264841/
All Articles