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 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.
-

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.