In today's world, it is difficult to have software that is released in only one language. For example, you may have a great product, and are releasing it in English, and it is earning some great amounts for your organization. However, by just restricting your software to a single language, you are losing out large potential regions where you could be earning much more money for lower incremental costs. So, when you are releasing your product only in English, you are missing out on sales in France, Germany, Italy and other European countries that work primarily in languages other than English; you are missing out on sales in Japan which is a large market; you are missing out the entire Latin and South American region; and you are missing out on smaller markets that are there in East Europe and the Middle East. In addition, there are possible deals with some OEM's that would require support in multiple languages. If you want to load your software as part of the software that laptop makers distribute, many of these want a software that is available in multiple languages to ease their software packaging process.
So you decide that it will make sense for you to release your product in other languages, and start planning for the same. Now, if your application has been coded properly, then it is simple to extract the UI elements of your software and send it off for translation into different languages. It can get more complicated when you have asset elements such as graphics and others that require translation (since there may be UI elements that have English text within the graphics - in which case these graphics will need to be re-done by taking the appropriate language text for each graphic and then re-doing the graphic), or if you are using SWF (Flash) files that need to be re-made for each language if there are language elements and the file needs to be done again for other languages.
However, all of these are process driven. There are subjective elements that need to be handled during the process, and for which the team needs to consult with experts on the processes needed for that language. For example, you may want to release the software to target the ever-growing Chinese market, and start the process of working on the translation and testing of the software in the Chinese Simplified language, and then find that when you are close to release, nobody told you of a specific testing process known as the GB18030, which is a mandate to ensure that the software is properly translated for the language. We had to submit the software to an actual testing and get the software certified that it passes GB18030. Similarly, when you look to release the software in Spain vs. Latin America, you will need to realize that there are some differences between Spanish and the language used in Latin America. The same goes for French and the language used in the French speaking parts of Canada (and in Canada, there are other mandates that you have to follow to respect the rules that software have to follow in terms of multi-language release).
There are other issues that you need to know, such as the difference between date notation (mm/dd/yyyy or dd/mm/yyyy) and the separators used in number (where the number 100000 is written as 100,000 in the US vs. 100.000 in many parts of Europe). Similarly, when you are releasing your software in Islamic countries, there may be cultural issues in term of depicting faces or the female form, and you need to ensure that all of these are already factored in.
In earlier releases of our software, in some cases, we did not know of some specific points and had to make quick changes when either the country specific person doing testing told us of the same, or we the pre-release tester who was more proficient in a certain language pointed out some things that we had missed, and all of these later changes takes more effort. Better to be as prepared as you can be right at the beginning.
So you decide that it will make sense for you to release your product in other languages, and start planning for the same. Now, if your application has been coded properly, then it is simple to extract the UI elements of your software and send it off for translation into different languages. It can get more complicated when you have asset elements such as graphics and others that require translation (since there may be UI elements that have English text within the graphics - in which case these graphics will need to be re-done by taking the appropriate language text for each graphic and then re-doing the graphic), or if you are using SWF (Flash) files that need to be re-made for each language if there are language elements and the file needs to be done again for other languages.
However, all of these are process driven. There are subjective elements that need to be handled during the process, and for which the team needs to consult with experts on the processes needed for that language. For example, you may want to release the software to target the ever-growing Chinese market, and start the process of working on the translation and testing of the software in the Chinese Simplified language, and then find that when you are close to release, nobody told you of a specific testing process known as the GB18030, which is a mandate to ensure that the software is properly translated for the language. We had to submit the software to an actual testing and get the software certified that it passes GB18030. Similarly, when you look to release the software in Spain vs. Latin America, you will need to realize that there are some differences between Spanish and the language used in Latin America. The same goes for French and the language used in the French speaking parts of Canada (and in Canada, there are other mandates that you have to follow to respect the rules that software have to follow in terms of multi-language release).
There are other issues that you need to know, such as the difference between date notation (mm/dd/yyyy or dd/mm/yyyy) and the separators used in number (where the number 100000 is written as 100,000 in the US vs. 100.000 in many parts of Europe). Similarly, when you are releasing your software in Islamic countries, there may be cultural issues in term of depicting faces or the female form, and you need to ensure that all of these are already factored in.
In earlier releases of our software, in some cases, we did not know of some specific points and had to make quick changes when either the country specific person doing testing told us of the same, or we the pre-release tester who was more proficient in a certain language pointed out some things that we had missed, and all of these later changes takes more effort. Better to be as prepared as you can be right at the beginning.
No comments:
Post a Comment