Games and E-Learning Localization
Through our experience in games localization we recognise that there are additional requirements when it comes to games localization. Here we describe some of the pitfalls and things to look out for in the localization of software games. Standard software application localization is based on the requirements that software be internationalised, and that all of the elements that a user might expect to see formatted to his/her locale are externalised. Examples of this include; the date/time/number formats, text, icons, images and so on.
What makes the games localization process different from standard application localization? We feel that nothing differentiates the processes. The principles of localization best practices apply just as well to games as to any other piece of software.
The localization process may consist of the following steps:
- Baseline the product to ensure that what you are starting off with is exactly what is required.
- Identify and extract all of the localisable user interface elements.
- Pseudo-translate the product.
- Rebuild the product.
- Prepare a translation kit of the localisable text.
- Translate.
- Integrate the translated text. Resize the GUI elements.
- Perform functional testing and linguistic testing.
- Implement fixes.
Baseline the product
The baseline process involves building the product so that the base product is created. Ensure that the product is byte-for-byte the same as the base product, and where there are differences, confirm with the client that they are legitimate differences.
Identify and extract all of the localisable user interface elements
This is the process of text extraction, but also metadata extraction. Text in the code may be obvious to identify and extract. This category of resource includes anything that the user sees. Metadata in this context is data on the formatting or presentation of data in the user interface. This includes formatting information for numbers, date/time and currency.
Pseudo-translate the product
Pseudo-translation means that all of the extracted text is replaced with text containing accented and extended characters. Internationalisation testing has two useful outputs, namely, the identification of character and locale support issues and the identification of hard coded strings. When internationalisation testing is performed on the game or application, it will be easy to identify those strings not appearing as pseudo-translated. Hard coded strings are those strings that have not been extracted, and yet still appear in the user interface. In the case that character support is a problem for the game, corrupted characters will be visible in the user interface.
Rebuild the product
The product is rebuilt using the development environment as specified exactly by the client. Building the software may raise issues with character support. This part of the process also has input into the design of the translation integration process.
Prepare a translation kit of the localisable text
The extracted material is packaged and sent for translation. The localization kit should contain as much information about the game as possible. The games should be included, where legally possible, or detailed screenshots should be provided. This means the translators are not translating blindly and they will be able to see the context of their translations. We believe that a quality translation kit improves the quality of the translation output.
Translate
We recommend using a translation memory tool such as ForeignDesk or Trados, so that translations can be leveraged for future versions of the product. Translators should be aware of the idiom used in the games. The “All your bases are belong to us” localization effort is something to be avoided, even though this is ironically so memorable. Being aware of the constituency for the games is essential when translating so that appropriate terminology is used. If possible a glossary should be created, signed off and translated before the translation of the software begins. This will help enforce consistency between a team of translators. It is extremely important to decide beforehand what is to be translated and what is not. Some names may be inherently untranslatable. See our next article for a further discussion of this topic. Another important piece of information with which the translators should be provided is the nature and size of any space restrictions. Sometimes these will be obvious from the running software or screenshots, and sometimes there exists a hard restriction on the number of characters.
Integrate the translated text. Resize the GUI elements
On receipt of the translation, re-integrate the resources into the product. This means that the text and graphics are to be put into the running software. Translation into languages such as German and Spanish causes the English text to expand and require a larger amount of real estate. This has to be addressed in a sympathetic way so that the text remains readable. Some options available are to reduce the point size of the text, or to shorten the translation with an alternative.
Perform functional testing and linguistic testing
This stage of the localization process is crucial to creating a quality deliverable. The input to the functional testing process is a test script that is either created by the localization house or by the client. In either event, the test cases should be signed off as the correct approach. Linguistic testing includes signing off that the translations are appropriate in context, and also that locale support is correct for all relevant data. One approach that we use is to provide the translators with screenshots creating during the functional testing. It ensures that all translators will see the same screens and test coverage is guaranteed for linguistic testing. This approach means that the translators do not have to be product experts, but they get product knowledge from following the screenshots and being demonstrated the intended functionality.
Implement fixes
The output of testing will be a set of functional and linguistic bugs that need to be fixed. Translators may fix the linguistic issues and redeliver.
Deliver
At this point, you should be delivering a quality assured product. We have a general rule with regard to projects and that is, “no nasty surprises”. Part of our process is that we make interim deliveries to the client during the project and inform them of all aspects and issues during a project. By the time the client receives the materials, they have already seen the product and are aware of any issues that arose or any known issues affecting the product.