User:Pb75/sandbox

// Please do not edit while this article is in my sandbox //

Wednesday January 31st, 2007

The objective of this article is to provide an introduction to the localization of games based on the Source engine. Detailed tutorials on translation tools and testing processes will be added as they become available
.

Quick note to mod developers

If you don't have the time to read the entire article, but you would like to have your game localized with minimal effort, consider the following rules in designing your mod:

1. Place all game texts in text files. Do not place them in any kind of binary or compiled files (BSP, VMT, etc).
2. Provide closed captions and subtitles for all custom speech and audio elements.

Introduction

This article describes the various aspects of the translation or localization of games based on the Source engine. These games are most often Source mods that can be localized, especially into #languages not supported by the Source engine and the Steam console. This article uses third party single-player mods as examples, but the concepts and recommendations apply to multiplayer games.

The examples illustrating various concepts are taken from Half-Life 2 and the following published single-player mods:

• MINERVA
• Ravenholm single-player mod
• Wivenhoe
• Combine Destiny
• Rock 24

Concepts

The following concepts are used in this article:

• localization: the process of translating software user interfaces from one language to another and adapting it to suit a foreign culture.
• game, 'mod, modification: a game based on the Source engine
• original game, original mod: the game or mod which is being localized from the source language into the target language.
• source language: the natural language which was used by the development team to produce the textual and audio elements of the original game.
• target language: the natural language into which the localization team is translating the localizable content from the original game.
• localizable content: content which requires localization. (see below)
• development team: designer and publisher of the original game
• localization team: team or person who performs the localization of the original game

Localization process

The localization process can be broken down into several stages:

1. Preparation
   1. Finding a game to localize
   2. Determination of a game's suitability for localization
   3. Determination of target languages
   4. #Identification of tools and resources
2. Production
   1. #Determination of localizable content
   2. #Creation of translation-ready materials (loc-kit)
   3. #Translation
3. #Testing
   1. #Runtime testing
   2. #Bug management
   3. #Bug fixing
   4. #Community/beta testing
4. Publication and marketing

Finding a game to localize

The localization team can adopt a proactive approach and actively look for Source games to localize. Various resources (e.g. Source mods, [moddb.com ModDB], etc.) list the numerous modifications produced since the release of Half-Life 2 and the associated SDK.

An established localization team can also expect to be approached by a development team and asked to localize a particular game.

Whatever the method, it is important for the localization team to analyze and playtest the game thoroughly in order to determine if it is suitable for localization.

Determination of a game's suitability for localization

Before any localization work is undertaken, it is important to determine if the game is suitable for localization. Considering the following questions should help in the decision-making process.

Objective criteria

Is the original game finished?

Translating a game in the early and intermediate stages of its development can be a frustrating exercise, as the game's content is bound to change and the translation work may need to be redone. See also Is the original game stable?.

Is the original game stable?

Some games suffer from serious or critical bugs and may not allow the player to access all areas or quests of the game. The game might also crash on a significant number of systems. Undertaking the localization of an unstable or buggy game is not recommended before these issues are resolved.

Is there enough localizable content?

Some games feature custom models, new textures and innovative puzzles, but do not contain many new dialogs or custom voices. Localization of games that contain very little localizable content will probably not benefit significantly the gaming community, as the game can be played as is without much loss of information by players who have no or very little proficiency in the game's original language. See Localizable content below.

Is the localizable content easy to extract and edit?

In some games, localizable content is contained in files which need to be decompiled and recompiled to be localized. This is a work-intensive process and should be undertaken only with the full support of the original development team. Without this support or an in-depth knowledge of Source development tools, localization efforts should be directed at games with easy access to localizable content. See Localizable content for more info. See also Wikipedia:Internationalization for more information on best practices.

Is the localizable audio content mirrored in subtitles and closed captions?

Speech and other localizable audio content should be mirrored in a subtitling system.

The prohibitive cost of re-recording voices in the target language is the reason why, in most cases, the only practical way to localize speech is to translate the subtitles, while leaving untouched the audio files from the original version of the game. If the implementation of this workaround is not feasible, the audio content will remain unlocalized and an important section of the game's content will not be understood by the players who are not proficient in the source game's language.

This issue is not a factor if the localization team has access to a large budget, a professional sound engineering facility and professional voice talents.

Subjective criteria

Is the game popular or fun to play?

If the localization team does not find the game appealing, the localization process, which includes long playtesting sessions, can quickly become a chore. Also, a game which is not popular with the gaming community in its original version will not probably fare much better when it is localized.

Is the development team helpful and easy to work with?

A competent and responsive development team can make the localization team's work much easier, especially when bugs and other quirks impede the progress of the localization project. Also, in games with a rich back-story, such as in the case of Minerva's archives, the input of the game's writer can be invaluable to ensure the correct interpretation of ambiguous texts and speeches.

Determination of target languages

Objective criteria

The following factors help determine the target languages into which the game should be localized.

Translators

Competent translators in the required language combinations are the first criterion. Translation is a complex art requiring a deep knowledge of the source and target languages as well as mastery of translation techniques and relevant terminology.

Some proficiency in the source and target language is usually sufficient to produce a readable target text. However, such a text will often fail to match the style and quality of the source text and the fact that it was translated will be immediately perceptible.

A good translation in the context of games is often transparent, i.e. the user does not realize that he or she is exposed to a translated text.

Localized resources

For the localization of games relying heavily on text and audio resources from Half-Life 2 or the SDK, it is crucial to reuse the available localized versions of these resources to avoid extra work. The closecaptions.txt file for Half-Life 2 contains over 20 000 words and translating it on top of the game files would present a significant workload.

Half-Life 2 text resources are fully localized into the following languages:

• French
• German
• Spanish
• Italian
• Russian
• Japanese
• Korean
• tbd

Subjective factors

Popular languages

If the objective of the localization effort is to allow the game to reach the widest audience, it is important to focus on the most popular target languages. The metrics in the language section of the Valve User Survey provide a rough indication in which languages the Steam console is used. This provides a rough indication of the most popular languages used by the gaming community. It has to be borne in mind however that some players use the default language of the Steam console even if it is not their preferred language.

Requested languages

The localization team may be tasked with the translation of the mod into a currently unsupported language. The project's scope will then invariably be larger, as on top of the custom content, all the base content reused from Half-Life 2 resources (closed captions, out-of-game UI, HUD, etc.) will have to be localized.

Localizable content

Before any work takes place, the game should be analysed in order to determine whether it is suitable for localization.

Then, the localization team should proceed to the precise identification of localizable content in order to determine the scope of the project.

Finally, the translation methods should be determined.

Localizable content is any piece of information that is not understandable by a person who does not speak the language used in the original version of the game. The information can take the form of text (see strings below) or sound (see audio below) and can appear in a several types of game elements hosted in a number of files.

For an effective localization of the game, it is essential to distinguish localizable content in the high number of files which make up a game. It is also important to determine which elements of localizable content should be localized and which methods should be used.

Localizable content in functional game elements

Standard localizable content can be found in the following functional game elements:

Out-of-game elements

These are elements which do not appear in the game itself, but are used to control various aspects of the game.

Among these elements, there are:

• Options and settings panels and tabs (
• New Game menu
• Save/Load Game menus
• Credits
• Readmes and manuals
• etc

In-game elements

• Chapter titles
• Heads-up display (HUD)
  • Standard elements (suit and ammo info)
  • Custom elements (HEV communications in MINERVA, written notes in Ravenholm)
• Closedcaptions/subtitles
  • Standard
  • Custom Subtitles
• Sounds
  • Standard sounds (suit, NPCs)
  • Custom sounds
• Entities
  • Models e.g. text on health kits
  • Decals e.g. CMB on walls, posters
• Videos

Localizable content by type

Strings

Strings are all types of textual content that are used to convey information to the player of the game.

Note: Some file types are better suited to host localizable content than others. From the point of view of localization, any resource that requires compiling, decompiling, (un)packing, converting, importing/exporting etc. should not contain localizable content. The reason is that re-engineering these resources during localization requires the same or nearly the same amount of work and the same level of tools' knowledge as was required during the engineering of the original version of the game. This investment of resources can be easily avoided if all localizable strings of text are contained in self-standing text files. There are other advantages of hosting localizable strings in text files, such as ease of maintenance (texts can be updated and corrected without reengineering and recompiling).

String containers

Non-text files

Binary and graphic files are commonly used to host localizable strings. This is not a recommended practice. See the Note above.

• .BSP
• .VMT
• .TGA
• .BMP
• .FLV
• .WMV
• .AVI
• etc.

Text files

The files listed below are designed to host localizable strings.

• scripts\titles.txt
• scripts\credits.txt
• resource\valve_<language>.txt
• resource\gameui_<language>.txt
• resource\hl2_<language>.txt
• resource\<mod_name>_<language>.txt
• resource\closecaption_<language>.txt

Sometimes, also the file types listed below contain localizable text:

• resources/*.res files
• scenes/*.vcd files

Note: This is not recommended, as code or scripts should be separated from text strings.

Audio

Sound resources such as intelligible speech present a different challenge. With an unlimited budget, the modding and localization team would be able to commission native speakers and re-recording all the sounds. In most cases, the text of all custom dialogues, monologues, radio communications, recordings should be reflected in closecaptions_english.txt or in a custom subtitles text file (script\titles.txt). Subtitles and closed captions provide a convenient workaround for audio localization and are also very convenient for players who don't hear too well or don't hear at all.

Tracking

• File list
• Version control system
• Folder structure
• File and folder naming convention

Testing

The localized game requires extensive testing in order to identify any issues introduced during the localization process.

Bugs

The issues can be any of the following:

Clipped strings

The localized text may be too long to display entirely in the allocated space in the UI. This is due to text expansion wgen translating into languages where the average word length is higher than in the source language.

Untranslated strings

Some strings may have been forgotten during translation and appear in the source language in the localized version of the game.

Character corruption

Description: extended and special characters do not appear in the game UI. Example: metastasis PL Possible reasons:

Methods

- checklists

- screenshooting

See Also

---

Most, if not all resources, that make up games based on an open architecture are easy to identify and modify. The modification can take many forms, including the translation of game texts and other language-dependent information into other languages.

, such as the Source engine, allow on one hand of games based on the Source engine is open in many respects and creates allows a straightforward localization of the various resources.

Notes

---

http://developer.valvesoftware.com/wiki/VGUI2:_Creating_a_panel

http://developer.valvesoftware.com/wiki/Creating_a_VGUI_Screen

http://developer.valvesoftware.com/wiki/Image:Ekg_vgui.jpg

http://developer.valvesoftware.com/wiki/Image:Granted_vgui.jpg

The usual practice is to set up a string ID in the bsp or vmt, reproduce the string ID in a text file (usually in the \scripts folder) and insert the actual English string in this text file:

Example titles.txt string_ID001 { This is a screen message! }

or, using tokenization, place it in a different file

resource\blackmesa_english.txt See http://developer.valvesoftware.com/wiki/VGUI_Documentation#Localization

Tokenization is used extensively for weapon names. See weapon_crossbow.txt

---

// Crossbow

WeaponData { // Weapon data is loaded by both the Game and Client DLLs. "printname" "#HL2_Crossbow"

---

The screen name of the crossbow appears in resource\hl2_english.txt

If the localizable content

Localizable content in game resources

===Defining

---

French Localization Bugs

Moved to French_Localization_Bugs. 04:57, 9 Nov 2005 (PST)

---

Notes

This applies both to developers who wish to release a multilingual mod and to translators who begin working on a released mod. Based on Localized_String#Localization

• Determine the need for a localized version
• Identify the resources requiring localization

Issues with cost: translation volume, new voice recording

• Identify the files that need to be added or changed: weapons, dialogs,
• Preparing the mod files: tokenization
• Translation and reuse of existing translations ([english])
• Testing
• Clipped strings
• Special case: languages not supported in Steam

more translation (HL2) and override the language (see Ts2do's tip)

• Tips - \n, tokenize everything, encoding, test tips TEST FRENCH***, resizing panels