Tips for those planning to localize their project
Localization is a cornerstone for many development teams around the world. This issue is especially acute when the product market is not clearly defined and the team does not fully know its consumer.
Let's be frank: if your product is targeted at a wide audience, then English is clearly not enough. Of course, there are highly specialized projects and services like ours, when knowledge of the main international language is not a whim — a necessity, but the niche of such developments is extremely narrow. And now, thousands of teams around the world sooner or later run into the ceiling of one or two languages: one is English, and the second is native for the team (if it is not English-speaking). Further disputes, quarrels, attempts at localization and subsequent dancing with a tambourine begin.
')
In this publication, we have collected a number of popular tips and recommendations from both private developers and experienced Mozilla-level teams, in which more experienced comrades share with their colleagues the experience of localizing projects.
One of the most annoying mistakes in the course of localization is the “wooden” layout of the project, when the fields and buttons do not adapt to the text size. Everyone suffers from this: from the web to game developers. The more serious and difficult your project is in terms of the code part and the more difficult it is to get to the sizes of certain elements so that the entire page does not go along with the design, the more carefully you should treat the dimension of the elements.
Many experienced developers recommend always keeping a minimum of 30% margin (in each direction) for each localized interface element: depending on the language group, the dimension of the inscriptions can be modified both into a larger (Romance group languages) and a smaller (Asian languages) side. I think everyone at least once faced with the fact that some kind of inscription does not fit in the space allotted to it.
As can be understood from the text above, a significant role in the success of localization lies with the designers. According to the Standish Group, only 20% of the features and functions of the project ensure its competitiveness, but the developers themselves are not always able to unambiguously and objectively identify these key points. Therefore, it is necessary to pay attention to everything and everyone, because an error in the critical part of the project for the consumer, but not too high in the opinion of the developers, can play a crucial role.
You also need to understand that simply translate the entire project into the desired language - it does not mean to localize it. Different language groups and regions define different patterns of user behavior and what works for an English-speaking or Russian-speaking audience will not work in Asia and vice versa. It is not only about the content, but also about design solutions, monetary units, date format, etc.
All of the above, in fact - the lyrics for designers and project managers. The Mozilla team, which has a very solid experience in localizing products, gives more detailed advice for developers.
For example, the Mozilla Developer Network in its blog recommends that during the development to pay attention to the little things and in general to be neat. So, in their opinion it is extremely important to choose adequate names for tags (keys) during localization and we, based on the experience of our clients, agree with this statement. Labels, regardless of the degree of importance and role, "should always describe the line and its role in the interface." If the string is tied to a particular feature or pop-up window, the label should reflect this information.
Another aspect that Mozilla developers pay attention to is that localizers often work without context, apart from the project itself. To facilitate their fate, you should leave notes that would give them a guideline, in which direction to move. Moreover, all comments, again, must be executed in a single format and have unambiguous content. By the way, we will mention the uniqueness later.
In fact, the organization of localization is a test for attentiveness and tidiness: if the team is able to pass it successfully, then localization will not cause significant problems. The complexity of this quest non-linearly increases with the number of languages, and if the advice of the Mozilla team may seem far-fetched for one-sided translation, then when you need to translate and adapt the project for 10-15 languages, they suddenly find the meaning of the level of biblical revelations.
As it is not surprising, but the success of the localization process directly depends on the style of the development itself. If your project has temporary lines and blocks that, in the future (observable or not), will undergo changes, then you should refrain from localizing them. Of course, we all know that there is nothing more permanent than temporary, but this rule does not always work. Here it is worth being guided by the law of Murphy and expect everything (that is, the worst).
In order to competently and adequately organize the work, the localization team of the above described is still not enough. It does not matter if you use a specialized service for localizing products like ours or do this procedure in the old-fashioned way, manually. One of the most insidious threats at the localization stage awaits in the very process of communication. Yes, that's right: the most ridiculous and unpredictable mistakes occur when people do not fully understand each other. And it's not about the stupidity of the developers or immediate localizers, but in the communicative toolkit.
Very often localized are the so-called “native speakers,” or, if to put it in Russian, native speakers. Communication takes place either in the language of the primary source of the resource (if it is a direct localization from a language other than English to a third language), or by using the same English. Many developers forget that their familiar English-speaking vocabulary is different from the usual. Thus, communicating with a translator who is not too closely acquainted with one or other subtleties of professional vocabulary, semantic collisions may arise.
A common example is bus, bookmark, or simply words that have several meanings in English based on context (fire, right, set, date, and so on, the list is extremely long). It must always be remembered that at least one of the participants in the localization process (if you involve carriers), speaks and writes in a non-native language. Of course, there are specialists whose abilities allow them to communicate at the media level in several languages ​​at once, but this happens extremely rarely and is beyond the means of most teams. Be tolerant of localizers and remember that how clearly and unequivocally you communicate with them depends on how well the work will be done.
If you plan to localize any of your projects in the near future, we recommend using our Lokalise service . For three years of service development, we ate a pack of dogs on localization and translations.
Let's be frank: if your product is targeted at a wide audience, then English is clearly not enough. Of course, there are highly specialized projects and services like ours, when knowledge of the main international language is not a whim — a necessity, but the niche of such developments is extremely narrow. And now, thousands of teams around the world sooner or later run into the ceiling of one or two languages: one is English, and the second is native for the team (if it is not English-speaking). Further disputes, quarrels, attempts at localization and subsequent dancing with a tambourine begin.
')
In this publication, we have collected a number of popular tips and recommendations from both private developers and experienced Mozilla-level teams, in which more experienced comrades share with their colleagues the experience of localizing projects.
Measure seven times
One of the most annoying mistakes in the course of localization is the “wooden” layout of the project, when the fields and buttons do not adapt to the text size. Everyone suffers from this: from the web to game developers. The more serious and difficult your project is in terms of the code part and the more difficult it is to get to the sizes of certain elements so that the entire page does not go along with the design, the more carefully you should treat the dimension of the elements.
Many experienced developers recommend always keeping a minimum of 30% margin (in each direction) for each localized interface element: depending on the language group, the dimension of the inscriptions can be modified both into a larger (Romance group languages) and a smaller (Asian languages) side. I think everyone at least once faced with the fact that some kind of inscription does not fit in the space allotted to it.
As can be understood from the text above, a significant role in the success of localization lies with the designers. According to the Standish Group, only 20% of the features and functions of the project ensure its competitiveness, but the developers themselves are not always able to unambiguously and objectively identify these key points. Therefore, it is necessary to pay attention to everything and everyone, because an error in the critical part of the project for the consumer, but not too high in the opinion of the developers, can play a crucial role.
You also need to understand that simply translate the entire project into the desired language - it does not mean to localize it. Different language groups and regions define different patterns of user behavior and what works for an English-speaking or Russian-speaking audience will not work in Asia and vice versa. It is not only about the content, but also about design solutions, monetary units, date format, etc.
It is important not only outside, but inside
All of the above, in fact - the lyrics for designers and project managers. The Mozilla team, which has a very solid experience in localizing products, gives more detailed advice for developers.
For example, the Mozilla Developer Network in its blog recommends that during the development to pay attention to the little things and in general to be neat. So, in their opinion it is extremely important to choose adequate names for tags (keys) during localization and we, based on the experience of our clients, agree with this statement. Labels, regardless of the degree of importance and role, "should always describe the line and its role in the interface." If the string is tied to a particular feature or pop-up window, the label should reflect this information.
Another aspect that Mozilla developers pay attention to is that localizers often work without context, apart from the project itself. To facilitate their fate, you should leave notes that would give them a guideline, in which direction to move. Moreover, all comments, again, must be executed in a single format and have unambiguous content. By the way, we will mention the uniqueness later.
In fact, the organization of localization is a test for attentiveness and tidiness: if the team is able to pass it successfully, then localization will not cause significant problems. The complexity of this quest non-linearly increases with the number of languages, and if the advice of the Mozilla team may seem far-fetched for one-sided translation, then when you need to translate and adapt the project for 10-15 languages, they suddenly find the meaning of the level of biblical revelations.
As it is not surprising, but the success of the localization process directly depends on the style of the development itself. If your project has temporary lines and blocks that, in the future (observable or not), will undergo changes, then you should refrain from localizing them. Of course, we all know that there is nothing more permanent than temporary, but this rule does not always work. Here it is worth being guided by the law of Murphy and expect everything (that is, the worst).
Translators are our everything
In order to competently and adequately organize the work, the localization team of the above described is still not enough. It does not matter if you use a specialized service for localizing products like ours or do this procedure in the old-fashioned way, manually. One of the most insidious threats at the localization stage awaits in the very process of communication. Yes, that's right: the most ridiculous and unpredictable mistakes occur when people do not fully understand each other. And it's not about the stupidity of the developers or immediate localizers, but in the communicative toolkit.
Very often localized are the so-called “native speakers,” or, if to put it in Russian, native speakers. Communication takes place either in the language of the primary source of the resource (if it is a direct localization from a language other than English to a third language), or by using the same English. Many developers forget that their familiar English-speaking vocabulary is different from the usual. Thus, communicating with a translator who is not too closely acquainted with one or other subtleties of professional vocabulary, semantic collisions may arise.
A common example is bus, bookmark, or simply words that have several meanings in English based on context (fire, right, set, date, and so on, the list is extremely long). It must always be remembered that at least one of the participants in the localization process (if you involve carriers), speaks and writes in a non-native language. Of course, there are specialists whose abilities allow them to communicate at the media level in several languages ​​at once, but this happens extremely rarely and is beyond the means of most teams. Be tolerant of localizers and remember that how clearly and unequivocally you communicate with them depends on how well the work will be done.
If you plan to localize any of your projects in the near future, we recommend using our Lokalise service . For three years of service development, we ate a pack of dogs on localization and translations.
Source: https://habr.com/ru/post/334178/
All Articles