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.

What are different aspects of Internationalization?

For the promotion of a software system or application, it should be available in all the different regions of the world. If it is not so, then the software artifact or the product remains confined to one region and is not exposed to the whole world.

Nowadays due to globalization, the software application developed in one region is used all over the world with the help of different regional standards and different regional standards. So there is a need felt for programming the software or application as such that it can be used easily and performs well when modified for use in different regions and languages.

In other words, we can say that there’s a need for internationalizing the product. Internationalization can be defined as a process of coding and designing a product in such a way that it can perform well and properly on any platform after modification for use in different regional standards and languages.

During the process of internationalization, the functionalities of the software product are kept safe and ensured. All the messages are kept externalized when they are being used in different languages, locales and standards.

Internationalization testing is well known as I18N testing. It is so called because there are 18 letters between I and N in the word internationalization.

Internationalization is implemented usually through pseudo-localization. This technique works on the principle of simulation of the local products. It involves many concepts that a localization center does when performing the localization of a software product.

Pseudo localization process involves 3 basic steps which have been discussed below:

- Messages files are translated by insertion of a suitable and specific suffix and prefix into every message file. Localizable non-message files are also modified but, they are not translated. Files in other formats are compulsorily modified in some way.
- The above pseudo- translated message files and other pseudo- translated files are installed in locale specified. Also the location is specified in the software product. For java resources, the files are named with a suffix relation to the required locale. Then the same procedure is followed for installation of the files.
- The software product is run or executed from the earlier specified locale. The GUI displays the prefixes and the suffixes that wre added to the file name instead of the default English names. All the files will run in their modified form including the localizable non message files.

The main advantage of this process is that one is allowed to use a software product including all its features without knowing the other languages. One can also translate the full files. Both internationalization and localization are a means for adapting a software product in different languages of the world.
- Internationalization seeks to make a software adaptable to any language but without modifying its internal structure.
- Internationalization and localization are together known as globalization.

An internationalized software product is fit for use in a defined range of locales. Several languages co exist in an internationalized system. A software system is considered fully internationalized only when the user has the choice to select the user interface language. The following are 4 pillars of the internationalization process:
- Computer encoded text
- Language
- Scripts
- Numeral systems.

Software Localization - some details in terms of how the process work - Part 7

In the previous post on the topic of Software Localization - Part 6, we worked through some of the differences between the team that tests the English version of the product, and the team that tests the various other languages of the product.
In this post, I will talk in more detail about some of the differences in styles of the teams and their handling of bugs. To some extent, there is a difference in the way defects are visualized between the product team that works on the English versions of the product, and the team that works on the various language versions of the product. Consider an example, whereby there is a functional issue in how the formatting of the name of the user is depicted. In English, a person may be referred as Mr. Smith, while in another country, it is considered impolite to address a person the application with just the surname, and the name should be referred as Mr. John Smith.
In the normal case, when such a defect is reported, the product team may not really understand the importance of this issue and the defect may be prioritized as being of lower importance while for the team that wants to sell this in another country, addressing this issue is of high importance. There needs to be a mechanism to ensure that such defects are considered with the importance that they deserve, and are not deferred or closed. Such issues are typically prioritized lower unless there is a mechanism where the Bug review Committee has representatives from the various locales; it is normally important that the Product Management of the product is sensitive to the various nuances.

Software Localization - some details in terms of how the process work - Part 6

In previous posts on the subject of localization, I have been writing about various processes and techniques employed in the process of localization, covering testing, and the processes used for tagging strings for localization. However, this post covers something different, the difference in teams between those who do overall product testing, and those who do the process of localization.
There is a big difference between the teams employed in the process of product testing and those who are involved in the process of localization. Teams involved in product testing are more in touch with functionality of the product, with the discussions related to the development of the functionality, the writing of test cases for these features, as well as the blackbox and whitebox testing of these features. The team is responsible for ensuring that the features work as well as they are supposed to and all bugs are shaken out of the system. It is the product team that finally certifies the product, and they typically do so for the English version of the product.
However, it is the localization team that is responsible for the certification of the various language versions of the product. The team does functional testing, but it is a reality that most of the functional bugs are found in the English testing of the product, and it is mostly localization bugs such as string corrections, layout issues, and wrong corrections that are found by the localization testing team. They would find the bugs that are mostly not needed to be fixed by the engineers on the product team, instead need to be fixed by localization engineers. Thus, the localization process is normally on a separate process from the product team processes.

Software Localization - some details in terms of how the process work - Part 5

In the previous post in this series (how to get the right resources for localization purposes), we explored how to ensure that we have the right set of people for the translation process. In this post, we talk more about a specific type of testing that is required to determine whether the software is ready for translation.
In previous posts, we have talked about how the software localization process depends on ensuring that all the strings in the code are tagged in a way that they can be extracted and then sent for translation. However, since this tagging of the strings needs to be done by the development team as and when these strings are added, it is very much possible that some mistakes could be done during the process of adding the relevant tag information to the strings; and that these mistakes could actually end up being found out much later in the cycle.
A testing process that could determine these problems much earlier in the cycle is called 'mocked testing', a process that ensures that the software is checked periodically to see whether there are strings that are not properly tagged. What happens is that the software is validated in the various languages and the dialogues inspected to see whether the strings are showing up properly, or not. Such a process helps in ensuring that any mistakes that are made during the tagging of the strings is caught early; else it is very much possible that when the actual testing happens much later in the cycle, the problem is caught then and it becomes more expensive to make the fix.
However, this effort needs to be properly planned, since it is something that requires effort from the internationalization team as well as the testing team.

Software Localization - some details in terms of how the process work - Part 4

The previous post in this series (Part 3 of localization testing) talked about the time period when to start the process of doing the internationalization of the software, including getting the list of strings. In this post, I will talk more about the processes involved when you are trying to internationalize the code, more in terms of trying to ensuring maximum efficiency and cost reduction.
Most companies do not have the requisite talent for localizing the software, in terms of people who know the various languages in which the software needs to be localized, and for many, hiring and keeping people who know all this can be a task that they would rather outsource, and there are a number of companies that handle all this translation and localization work. However, before we get into this, there are more details that need to be explained.
Consider the case when your software needs to be internationalized. What is the process ? In the previous posts, we have talked about when to start the process, and how it is technically done, but not more details once the required strings are available for translation.
Well, during the translation process, the following is required:
- Line up resources in each desired language who can convert the various strings and return them back for incorporation
- For accuracy purposes, it is desired that these translations be reviewed through a formal review process. So, first the strings are generated for translation, these are translated, and then another language expert does the review
- Once the review is done, these are then incorporated and built into the software
- The software is now ready for internationalization testing, and there are 2 levels of testing required
- The first is functional testing where it is confirmed that the software works fine in the various desired languages. A language expert is not needed; in most cases, the tester takes the English language version and tests the other language keeping the English one in mind (except when the test cases specify a different need in the language version)
- Next, a language expert is needed to verify that the translations appear properly in the various sections of the application, the translations fit the context, and that there are no grammatical mistakes, etc. It is desirable to have a native language speaker do this level of testing.
-

Software Localization - some details in terms of how the process work - Part 3

In the previous post (Part of software localization), I was describing how the process of doing localization works, as well as the schedule in which this needs to be done. In this post, I will provide more details of what needs to be done.
In this post, I will go back to the beginning of a cycle, where the planning for a product development cycle needs to be done. Consider a product cycle for a product release that spans a period of 2 years. When the product cycle is planned, two of the key milestones in the schedule deal with the following 2 points:
1. The point in the schedule where the UI components in the application are frozen and all strings finalized
2. The release dates for the various language versions. There are 2 possible options, one where all the language versions of the product are released at the same time, and the other where the English and a couple of the more important languages are released earlier, and the other languages are released later.
The critical part of this planning is the time period required between these 2 milestones, since as said earlier, the actual work of generating the various locale translations, the testing, all this needs to happen in this time period. Make this too aggressive, and you will find the team stretching to meet the timeframes for the localization process.

Software Localization - some details in terms of how the process work - Part 2

In the previous post on this topic (Some details of software localization), I described the localization process at a high level, with not too many execution details. In this post, I will continue at the same high level, still continuing to explain the process of localization and its relation to the product schedule.
When you consider a product schedule, there are many milestones that you need to meet, with one of the milestones being a state whereby you freeze all the UI related content, specifically strings (these could be text on the dialogs, could be error messages, popups that appear when the mouse hovers over certain parts of the screen, etc). The milestone where the strings need to be frozen can be a single milestone in the second half of the schedule, or it could as part of periodic milestones where individual features are frozen in terms of their UI.
Once the strings are frozen, they can be pulled out (as described in the first post in this series), and then sent to the appropriate language vendors for translation. Once the translation happens and these translations are sent back, the translations can be incorporated in the product code (in a resource file that contains all the strings for different languages). The net result is, when the product is launched in a specific language, the application picks up the relevant language strings and shows them.

Software Localization - some details in terms of how the process work - Part 1

What is software localization ? Localization means releasing software that works in different countries the same way. For a person who is not experienced at this, they would wonder as to how the same software can work in different countries almost identically ? After all, if you look at the test that shows up in a software, the text is different in different languages, and it must be a lot of effort to get this done. Well, it is a lot of effort to get a software that works properly in different countries, but not as high as you might expect. Consider a website that showcases news or has articles (which means the site is almost entirely text based). Such sites would need re-writing the entire content into different languages, and the effort can be considerable, and for sites that depend on getting news out quickly, the amount of time involved can be considerable.
However, if you consider a software, there are 2 main elements. One element is the text that a user views (whether it be text on dialogs, or error messages) - this needs to be different in different languages. On the other hand, a huge amount of the internals of a software is the code, and this code does not need to be translated (which is a huge amount of effort savings), since this code is not visible to the users.
In this post, I will give a very high level summary of how the localization of software can be done, and then break this up in future posts. Inside the software, in any part of the code where there is an output of text that the user can see, there is a special section of code that identifies this is as a UI content. When this is done all over the software, all the text, error messages, information given to users, etc, all of this has a small identifier that marks that this section of code is different.
Next, a script is run that gathers all these sections of code that has an identifier, and presto, you get a large set of phrases. These are then sent off for translation into different languages, and when translated, are put back language by language into the software. So, when a user launches German version of the software, the code pulls out all the German translations, and shows those to the users instead of the English originals. Thus, you find that your software has become localized.
This is a simplified version of the entire process, and I will add more details in future posts.

Overview of Localization Testing and what are its focus areas.

Localization is a process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. Localization testing checks the quality of a product's localization for a particular target culture/locale.

Areas of focus in Localization testing
- Localization testing should focus on the areas affected by localization, such as UI and content, culture/locale-specific, language-specific, and region-specific areas.
- The localized checklist includes spelling rules, sorting rules, upper and lower case conversions, printers, size of papers, operating system, key boards, text filters, hot keys, mouse, date formats, measurements and rulers, available memory.
- Localization testing should include basic functionality tests, setup and upgrade tests run in the localized environment and plan application and hardware compatibility tests according to the product's target region.
- Availability of drivers for local hardware.
- Encryption algorithms.
- Focus on customization that could not be automated through the globalization services infrastructure.
- The quality is not usually checked during localization testing.
- Validation and verification of applications, linguistic accuracy, and consistency checks can be purchased separately.
- Localized testing can weed out potential errors, before they are localized and correcting them becomes costly.
- The advantage of localized testing is that it saves time.

Overview of Localization and what is Software Localization

Localization is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. Translating and adapting both the content (text and style) and the presentation (graphical and technical components) of an EXISTING product according to the language and cultural characteristics of the target audience or region for which it is intended.

- Localization testing are not strictly a part of the development of world-ready software.
- Localization becomes possible once you have developed world-ready software.
- The end result of localization is a product that is appropriate for the target locale's business and cultural conventions, appears custom built for the end user's cultural and linguistic background does not change the original intended meaning.
- Users can interact with a successfully localized product in their own language and in a setting that feels natural to them.

Software localization is the process of adapting a software product to the linguistic, cultural and technical requirements of a target market. Software localization is the translation and adaptation of a software or web product, including the software itself and all related product documentation.
- This process often requires a lot of work hours and tremendous effort from the development teams.
- There are a number of tools that were specifically created in order to simplify the localization process.

Software Localization Process

- Identification of what must be translated from a software.
- Adopting a localization strategy.
- Schedule for localization process should be established and deadlines should be created.
- Recruiting adequate, professional translators.
- Ensure the accuracy and coherence of translator's work.
- Consult the development team.
- Define a properly internationalized product that won't need to undergo changes for each of the envisaged foreign languages.
- Testing the product for each and every one of the languages in question.

Product Cycle: Setting a milestone to freeze all the UI elements of your product

In a typical Product Development model, the focus is on getting the newer features into the product. So, in the normal model, you have a list of new features that is decided in collaboration with Product Management and these are implemented over a period of time. The timeframe for this implementation can vary depending on the type of product development model being followed such as Scrum, Iterative, Waterfall, etc.
However, whatever be the cycle you may be following, it is critically important to have a specific milestone in your entire schedule where you no longer make a change to the UI components of your product. This could mean the layout of dialogs, the artwork such as icons and others used in your application, the error messages and text on dialogs, and any other such UI elements.
And why do you need to have such a milestone in your schedule ? Aren't you limiting the amount of changes you can do if you need to have such a time when you can longer make changes ? Well, there are certain dependencies that most products have. For product being sold internationally, there is a need to ensure that your product is translated into the languages in which it is being sold, and to do this translation and testing of the different language product takes time; now if you keep on changing some elements of your UI, this process of getting your product converted into an international version will become very inefficient and costs will increase, so the simpler solution is to ensure that you freeze your UI elements at some time, which gives enough time for the translation, and also allows the product QE to get a final set of specifications and design that they can test against.