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

In the previous post of this series (Software Localization - some details in terms of how the process work - Part 7), I talked about how different countries can have certain requirements that are specific to those countries, and may not be easily understood by the product team that is typically working on the English version of the product. In this post, we talk about the matrix that is typically used for determining the number of locales in which the product is to be tested.
For any software applications that has gone through multiple versions, there will be many features that are built in previous versions and are not changed in the current version. In addition, typically, when an application is tested in languages other than English, the assumption is that functionally, the application tested in the English version would work fine in terms of its features, and the need to do functional testing in other language versions should be reduced.
In a previous post, I had already mentioned that both linguistic and functional testing in other languages can be more expensive than testing in English, and hence there needs to be some optimization of the testing effort in other languages (one would like to test all the application thoroughly in different languages, but costs add a big variable to this equation and need to be considered). As a result, what typically ends up happening is that an optimization matrix is drawn where the amount of testing on each language needs to be decided upon, and this also depends on various factors, including the importance of the respective language version on the overall sales of the product.
In the next post on this subject, I will write a continuation of this topic.

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.

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.