September 1, 2015 at 10:28How to write software for the whole world
- Transfer
- Tutorial
Among software developers, it was always assumed that localization is a very expensive and time-consuming task, so it is always better to limit yourself to one language first, and add support for others later as necessary. Because of this attitude, nobody often thinks about supporting multilingualism in the early stages of developing new software, and many products are ultimately made in such a way that localizing them is then much more difficult than it should be.
In fact, in writing software that is subsequently easily localized, there is nothing terribly complicated if you start writing with the end result in mind. We are at Alconost
translated an article for you about techniques that can help you seriously reduce your workload at a time when your product will still become international.
Definitely the most important (and most ignored) localization preparation rule is to separate all lines visible to the user from the code that uses them.
The usual approach in this case is to store the text content of the product in separate resource files for each platform or language. For example, Java programmers should keep their display lines in ResourceBundle files .
Text in applications should never be structurally tied to application logic. The 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 thanks to new technologies that can automatically extract text content from code and send it to people for translation, and then publish ready-made 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 noticeably decrease. It is critical that the components of the program code and graphical interface are independent of the constant length of the displayed lines.
This, of course, will add work when creating a graphical representation of the text to the user, but there are many ways to do this correctly .
For everything except company logos or products, you should avoid using images, of which text is part, as translating this text content will be more difficult. Instead of just quickly translating the contents of the text file, you will have to hire graphic designers who will convert the images and place the translated text on them, separately for each language.
Code writers should always remember that other countries can:
Put all this in the checklist by which you check your code to prevent any hardcoding that could limit the multilingual use of your product.
Always use established international data storage standards. For example, use E.164 for phone numbers, ISO-8601 for timestamps, 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-speaking markets quietly implemented techniques in their code that worked only when using ASCII encoding . For example, changing one bit in an alphabetical character from ASCII switched its case from lower to upper. However, since then, the needs of the world have long exceeded the capabilities of ASCII, and now Unicode is accepted as the right way to encode text data and support international characters.
Even with some Unicode compatibility with ASCII, the best way to avoid string encoding problems is to abide by these rules:
Fortunately, some of today's most popular programming languages, such as Java, C #, and Objective-C, contain native Unicode support for string types. Their use turns the solution of the problem of international symbols into a commonplace.
Even if the application fully supports Unicode, it is likely that it stores data in a database, and a poor logical data structure can easily ruin all the work perfectly done in the code for compatibility with international encodings. For example, in a SQL Server database, the displayed rows should be stored in nvarchar types , while in MySQL it is best to use utf8mb4 .
Read more about Unicode in Joel Spolsky’s good introductory article .
The most common difference in displaying text is spelling from right to left , as in Arabic and Hebrew.
In a web application, the main problems that arise when translating into right-to-left languages can be resolved by simply changing the CSS property of direction 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, it will be much easier for translators to work with simple and clear text.
An overly technical language, similar to technical jargon, is unlikely to be well translated. Better use the usual phrases and terms instead of niche and rarely found.
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 make sure that the product supports international characters is a very valuable and not so much effort.
For example, imagine a web application for booking concert tickets. Suppose a test has already been written to check whether a user with the fake name "Ivan Ivanov" can reserve a seat and make sure that his name is correctly displayed on the ticket that he will receive after payment. Adding a simple test, which changes the username to “Ivan- 假 会 河 Ivanov-沖 鈈 批” and ensures that the same characters appear on the ticket after payment, will make sure that international character support works both in the application and database. This simple approach (sometimes called “ pseudo - localization ”) allows developers to check whether their application supports the transfer and storage of strings with international characters, without having to order a full professional translation of the productor solid linguistic knowledge of the developers themselves.
Automated tests are capable of more. With their help, you can check whether the fields read from right to left work correctly or whether international plural forms are supported , without having to redo the basis of the product code.
Developing software ready for international use is not as complicated as it might seem or what it once was. 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 affordable!
We at Alconost are always happy to help you with the professional localization of your software - quickly and efficiently .
About the translator
Translation of the article was done in Alconost.
Alconost localizes applications, games and sitesinto 60 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.
We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.
Read more: https://alconost.com
translated an article for you about techniques that can help you seriously reduce your workload at a time when your product will still become international.
Keep lines visible to the user separately
Definitely the most important (and most ignored) localization preparation rule is to separate all lines visible to the user from the code that uses them.
The usual approach in this case is to store the text content of the product in separate resource files for each platform or language. For example, Java programmers should keep their display lines in ResourceBundle files .
Text in applications should never be structurally tied to application logic. The 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 thanks to new technologies that can automatically extract text content from code and send it to people for translation, and then publish ready-made 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 become longer or shorter.
English phrases can become twice as long when translated into other languages, and in some languages they can noticeably decrease. It is critical that the components of the program code and graphical interface are independent of the constant length of the displayed lines.
This, of course, will add work when creating a graphical representation of the text to the user, but there are many ways to do this correctly .
Use images without text
For everything except company logos or products, you should avoid using images, of which text is part, as translating this text content will be more difficult. Instead of just quickly translating the contents of the text file, you will have to hire graphic designers who will convert the images and place the translated text on them, separately for each language.
Consider differences in calendar formats, time, phone numbers and currency systems
Code writers should always remember that other countries can:
- use a different format date and time ;
- to consider as days off other days of the week;
- use a completely different calendar system ;
- prefer to use week numbers rather than month names;
- be in the time zone with an offset step of less than an hour ;
- use a different system of measures ;
- use a different currency or several other than yours;
- have a different phone number format .
Put all this in the checklist by which you check your code to prevent any hardcoding that could limit the multilingual use of your product.
Always use established international data storage standards. For example, use E.164 for phone numbers, ISO-8601 for timestamps, 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-speaking markets quietly implemented techniques in their code that worked only when using ASCII encoding . For example, changing one bit in an alphabetical character from ASCII switched its case from lower to upper. However, since then, the needs of the world have long exceeded the capabilities of ASCII, and now Unicode is accepted as the right way to encode text data and support international characters.
Even with some Unicode compatibility with ASCII, the best way to avoid string encoding problems is to abide by these rules:
- never allow character encoding in ASCII;
- never rely on the fact that one byte is equal to one character;
- always use Unicode-compatible fonts and libraries.
Fortunately, some of today's most popular programming languages, such as Java, C #, and Objective-C, contain native Unicode support for string types. Their use turns the solution of the problem of international symbols into a commonplace.
Even if the application fully supports Unicode, it is likely that it stores data in a database, and a poor logical data structure can easily ruin all the work perfectly done in the code for compatibility with international encodings. For example, in a SQL Server database, the displayed rows should be stored in nvarchar types , while in MySQL it is best to use utf8mb4 .
Read more about Unicode in Joel Spolsky’s good introductory article .
Note that text is not always read from left to right.
The most common difference in displaying text is spelling from right to left , as in Arabic and Hebrew.
In a web application, the main problems that arise when translating into right-to-left languages can be resolved by simply changing the CSS property of direction for the entire system.
It also happens that the text is read from top to bottom , although much less frequently .
Text visible to users should be simple.
When localizing application messages for other markets, it will be much easier for translators to work with simple and clear text.
An overly technical language, similar to technical jargon, is unlikely to be well translated. Better use the usual phrases and terms instead of niche and rarely found.
Test basic multilingualism 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 make sure that the product supports international characters is a very valuable and not so much effort.
For example, imagine a web application for booking concert tickets. Suppose a test has already been written to check whether a user with the fake name "Ivan Ivanov" can reserve a seat and make sure that his name is correctly displayed on the ticket that he will receive after payment. Adding a simple test, which changes the username to “Ivan- 假 会 河 Ivanov-沖 鈈 批” and ensures that the same characters appear on the ticket after payment, will make sure that international character support works both in the application and database. This simple approach (sometimes called “ pseudo - localization ”) allows developers to check whether their application supports the transfer and storage of strings with international characters, without having to order a full professional translation of the productor solid linguistic knowledge of the developers themselves.
Automated tests are capable of more. With their help, you can check whether the fields read from right to left work correctly or whether international plural forms are supported , without having to redo the basis of the product code.
Embrace Global Opportunities
Developing software ready for international use is not as complicated as it might seem or what it once was. 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 affordable!
We at Alconost are always happy to help you with the professional localization of your software - quickly and efficiently .
About the translator
Translation of the article was done in Alconost.
Alconost localizes applications, games and sitesinto 60 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.
We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.
Read more: https://alconost.com