Localization versus translation
Before going into details on Russian software localization, I guess it is worthwhile to define localization and internalization in general. In common terms, software localization is the process of adapting a software application (its language and other locale-specific items) for use in foreign markets. Very important to understand that software localization includes translation, but not limited to this process.
Examples of activities in localization, which are not necessarily part of traditional translation: project management, software and online help engineering and testing, conversion of translated documentation to other formats, translation memory management, etc.
Another important difference between localization and translation is the fact that traditional translation is an activity usually performed after the source document has been completed. On the other hand, localization projects often run in parallel with the development of the source product to enable simultaneous delivery of all language versions.
Technical issues of Russian translation
From my experience in Russian software localization, the most evident issue here is a different length of UI items in English and Russian – Russian strings are in average 15-20% longer than English ones. There are cases when Russian user interface items are considerably longer, and software engineers have to use re-sizing, aligning and other “non-linguistic” techniques to fit them into localized interface. Here is just one example:
English: Rotate 90° CCW
Russian: Повернуть на 90° против часовой стрелки
Linguistic issues of localization
The main problem here is a lack of context. The messages, menu items and software strings are often dynamically concatenated from pre-defined words and phrases, so it makes almost impossible for a localizer to see them in context. For example, the same term can be translated into Russian differently, depending on a context: line – строка or линия, tab – табуляция or вкладка, etc. In cases like this, a localizer has to rely on his/her intuition and further thorough linguistic and functional testing.
Of course, in case of Russian software localization one has to take into account different rendering of plurals (in English only 2 possible outputs, e.g. 1 page printed, X pages printed, while in Russian the following options are possible: распечатана 1 страница, распечатаны 2 страницы, распечатано 5 страниц). In this case, the Russian localizer has to come up with a workaround, like Распечатано: X стр.
One more thing that makes Russian software localization tricky: grammatical genders (there are three of them in Russian: feminine, masculine and neuter). For example, English: picture/library/window was deleted, Russian: рисунок удален/библиотека удалена/окно удалено.
Cultural issues of Russian software localization
Localization also may take into account differences in culture, such as:
• Local holidays (e.g. Easter in Russia is celebrated on differents dates)
• Personal name and title conventions
• Comprehensibility and cultural appropriateness of images and color symbolism
• Ethnicity, clothing, and socioeconomic status of people and architecture of locations pictured
• Local customs and conventions, such as social taboos and popular local religions
Internalization and prerequisites of software development
When approacing a localization project, one should consider a few moments, that would save a lot of time and efforts in future. I listed some of them below (taken from the article by Zack Grossbart).
1. Get user-visible strings out of your code and into resource files. These strings include: titles, product names, error messages, strings in images and any other text the user might see.
2. Avoid strings concatenation, as appending one string to another almost always results in a localization bug.
3. Never hard-code date, time or currency formats.
4. Give strings room to grow and shrink.
5. Never sort in the browser.
6. Test early and often.
In this post, I touched upon only few issues and stumbling blocks of Russian software localization. If you want to know more, please check some links below.
Особенности локализации программного обеспечения на примере SCADA-системы WinCC
A Beginner’s Guide to High-quality Software Localization
Interesting post. Your comments on localization particularly so. Good luck and keep posting!
I haven’t had a chance to do any localization projects yet (running parallel with product development) but that sounds like a lot of fun. Hope I get the chance to try that soon. Interesting post and good luck.
Your post about localisation and particularly about Russian localisation is extremely interesting! I am leaving a reply on the topic “localisation vs translation”. Another difference is, in my opinion, the importance given to the activity of translating in translation projects compared to localisation projects. Often, in localisation projects, translation is seen as a small part of a bigger process, and unfortunately not as a pivotal part and one without which the whole process would not survive. In translation projects, on the other hand, more importance is given to the language process, perhaps due to a wider understanding of the complexity of the process. This is particularly true in literary translation, although not as much in other fields of applied translation. In literary translation people tend to be more aware of the time and effort it takes, while in localisation, translation almost becomes a mechanical task, a matter of equivalence, a concept that has been superseded in Translation Studies (Baker). As Pym argues, asking our translators to find mere equivalents, equals disregarding the complex evolution of the theory of translation studies (Pym) in the last 50 years. In my opinion, localisation should attempt to give more importance to the delicate work of translation, which is undoubtedly necessary for the localisation to occur.
Thank you, Anna, for your thoughts on “localization vs translation” topic.