Software product localization - there may be base product changes

For somebody (people or teams) who have experience in releasing software products in multiple languages, they would typically have gone through a lot of learning in terms of how the nuances of different languages can cause changes in the base language product (in our case, and in most cases, the base language product is in English, and the product can be released in many other languages, for larger software products such as Operating Systems or MS Office or Photoshop, these can be many many languages).
However for a team that has so far been releasing software products in one base language and have now moved to try and release their product in other languages, it can be a fairly complex project. In simplistic terms, it is to make sure that all the strings used in the product (whether these be text on screens or on dialogs or error messages, etc) are all capable of being harvested, sent for translation and then reincorporated back into the product depending on the language in which the product is being released.
Based on this simple concept, things get more complicated as you proceed towards actually doing the project. There are additional schedule requirements, there is a lot more work for the developers since testing a product for localization reveals many changes that are required, there is the need to get external people who can do the testing of the product in the different languages (the language needs to be checked, as well as the functionality of the various parts of the product under different languages), and many other changes need to be planned (this post is not meant to be a full description of the process of getting a product localized for the first time - that is a massive endeavor that requires a lot of explanation). As an example, a simple text on an error message may turn out to be much longer in a language such as Russian or German, or reading from right to left in Arabic or Hebrew, and the error message may not display properly in such cases. Either the message needs to be re-written or the error message box needs to be re-sized, which also has implications for the help manuals that may need to be modified.
Ideally, a team planning to get their product localized for the first time needs to avail of the learning that other teams and products have gained over their cycles, and so either need to hire some people with the required experience for both development and testing, or atleast get a thorough discussion with teams that have done this. Getting a product localized for the first time is not that big a effort and can be done right, but it is also not something that you attempt without ensuring that you have done adequate preparation in terms of schedule and resources. Once you have done that level of planning, then you will still face challenges, but those should be fixable.

How to decide whether to add another language support to the software product

The time is long gone when you could have only English as the language in which you are planning to release your software. Over the past many decades, software products have seen an increasing amount of revenue coming in from releases made in different languages, to sell in different regions of the world. So, although sales in the United States may be still your highest source of revenue, an increasing amount of revenue comes in from sales in Japan, in Europe, in Latin and South America, and in the emerging regions of China and India (for the last 2, there is another challenge that you have to meet, namely about how to prevent piracy and have more legal sales of the product in these regions).
So, if you have an English only version of your product, what will happen is that you will sell it in the United States, Great Britain, Australia, (and other English speaking nations of the world), and to some extent, you will even sell the English language versions in some of the countries, selling it to those consumers who want the English language versions of the product. But, what about the Spanish speaking world, the Japanese speaking, the French speaking, and so on ? Well, in many of these regions, there will be also a reluctance to buy the product just because the company has not chosen to bring out a specific language release. So, it always makes more sense to release specific language versions of the product, and releasing with the same set of features as the English language version.
The process of creating multiple language versions of the software is much easier. What is basically required is to translate all the UI elements in the application (includes strings, error messages, text within images, and any other text that the user can see) The way that the software code is written makes it easy to extract all these UI elements, and send them off for translation. Once these are translated, these are then incorporated back into the software, and then tested to ensure that there is no functional issue, and no cases where the translation leads into text that is messy or otherwise not right.
If it is that easy, why not just translate the software into as many languages as required ? Well, the previous paragraph was an over-statement; the process is expensive both in terms of revenue and resources. The process is not so exact. It can happen (and this especially happens with Japanese, German and Russian) that the translated text is much larger than the English language version, and there needs to be effort spent to either increase the size where the text is to be fitted (and this would need to be done in all languages) or the text needs to be re-translated into something smaller. For large products, a complete translation, which also includes the thorough testing of the product, can run upto almost a million dollars.
So this why there needs to be thought about translation into a new language. Reasons for the same include:
- Marketing estimate of enhanced revenue
- Potential sales in that region over a period of time
- Negative image getting developed because of the lack of product in that language
- Need of a partner. In many cases, when doing deals with partners, the partner would want the product to be there in multiple languages, and if the language is not supported, the deal could be in danger

What are different aspects of localization?

Localization is just the opposite of internationalization. The process of localization involves the acceptance of an internationalized software system to a particular locale or region with its specific standards and languages.

- Localization testing also forms a part of testing and typically focuses up on localization and internationalization aspects of the software products or applications.
- To localize a software system or application one needs to have the knowledge about the sets of characters which are employed in the development of today’s software product and applications.
- It also involves the basic understanding of the risks associated with the employed sets of characters.
- Localization is carried out to determine how well the build of the software product has been interpreted with a particular desired target language.
- More often and mainly localization testing helps to know that how well a particular target language has been analyzed by the build.
- For localization testing there should be a functional support within that particular locale which has already been validated because the test is founded only on the results of the globalized validation.
- The product must be globalised to a high extent and if it is not so then it will not support a given language, you will not try to give preference to that language first. But still the person has to check that the report or application which you are delivering is in a working condition or not.

Process of localizing a software product
- The process of localizing a software product or application involves the full translation of a particular application of graphical user interface and accommodate graphics for a locale.

- It also includes translation of that application program into that particular native language in the same way as the localization of business can result in a big task because the main intention for the localization of business is to implement correct business processes and practices for a locale.

- There are so many differences in how a locale conducts business. The user interface and content files are the two basic things which are mainly edited during the process of localization.

- A checklist is referred side by side during localization so as to keep a track of the process. The localization testing checklist includes the following:
1. Rules for sorting
2. Conversions in upper case
3. Conversions in lower case
4. Rules to check spelling mistakes
5. Printers
6. Operating systems
7. Size of papers
8. Text flters
9. Key boards
10. Mouse
11. Date formats
12. Hot keys
13. Available memory
14. Measurements
15. Rulers for measurement

Localization process can be initiated on a system which consists of only a few number of translators, desk top publishers or DTPs, engineers and linguists.

But the localization process is done only when certain defined conditions are there i.e., to say if there is a combination of the following aspects:

1. Independent contractors.
2. In house resources.
3. Full scope services of the localization firm.
4. Since the localization process mainly involves the translation of all the native languages in to a particular aimed string and customization of the GUI or graphical user interface, it is appropriate for the targeted market.

The software products which are offered to the international market often have to suffer a lot of domestic or in house competition which results in the blending of the localized product into a particular native language.

After the translation of the language and the updating of the graphical user interface, localization testing is needed to ensure that the software product is working well and without any problem and it also ensures that the software product is well migrated to the international market.