User:Pb75/sandbox

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

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

Notes

• 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

Wednesday November 9th, 2005

The objective of this article is to provide in-depth information on the localization of games based on the Source engine.
.

Quick note to mod developers

Two main rules should be observed by developers of Source games who wish to see their games localized quickly and efficiently:

1. Place all game texts in text files, not in BSP or VMT files
2. Provide close captions for all custom speech 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 Half-Life 2 third-party mods, but Official Half Life 2 Mods may also be localized, especially into #languages not supported by the Source engine and the Steam console. This article deals mainly with single-player games, but the concepts and recommendations are easily applicable to multiplayer games.

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

• MINERVA: localized into
• Ravenholm single-player mod
• Wivenhoe
• Combine Destiny
• Day Hard

Concepts

The following concepts are used in this article:

• localization:
• original game, original version of the game: the game which is being localized from the source language into the target language
• source language: the natural language which was used by the development team in the text elements of the game user interface and in the audio elements.
• target language: the natural language into which the localization team is translating the localizable content in the original game.
• localizable content: ##see below
• Source game: a game based on the Source engine
• development team: team or person who designed and published the original game
• localization team: team or person who localizes the original game

Localization process

The localization process can be broken down into several stages: Preparation

1. Finding a game to localize
2. #Determination of games suitable for localization
3. #Determination of target languages
4. #Identification of tools and resources

Production

1. #Determination of localizable content
2. #Creation of translation-ready materials (loc-kit)
3. #Translation
4. #Testing
   1. #Runtime testing
   2. #Bug management
   3. #Bug fixing
   4. #Community/beta testing

Publication and marketing

Finding a game to localize

The localization team can adopt a proactive approach and look for Source games to localize. Various #resources list the numerous modifications produced since the release of Half-Life 2 game and SDK. An established localization team can also expect to be approached by a development team and asked to localize the particular game. Whatever the method, it is important for the localization team to playtest thoroughly the game in order to determine if it is suitable for localization.

Determination of games suitable for localization

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

Objective criteria

Is the original version of the game finished and 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 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 new UI strings apart from a few chapter titles. 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.

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 #below point binary files for more info. For more information, see Wikipedia:Internationalization

Is the localizable audio content mirrored in closecaptions?

Speech and other intelligible localizable content should be mirrored in a closecaption or a commentary system. The prohibitive cost of re-recording voices in the target language is the reason why the only practical way to localize speech is to translate the closecaptions or commentaries, while leaving untouched the audio files from the original version of the game. If the implementation of the 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.

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 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 localization team's work much easier, especially when bugs and other quirks impede the progress of the localization project. In games with a rich back-story, such as in the case of Minerva's [1], the input of the game's writer can be invaluable to ensure the correct interpretation of ambiguous texts and speeches.

Determination of target languages

The target languages are first determined by the availability of linguists working in the required language combinations. Target languages are further determined by the person or team which contacts the localization team with the localization request. If the first objective of the localization is to allow the game to reach the widest audience, it is important to determine the target languages which will help the team to attain that goal. The metrics in the language section under | indicate in which languages the Steam console is used and the relevant percentages. 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 will use the default language of the Steam console even if it is not their preferred language.

Currently the languages which would reach 91% of Steam users are the following:

• English
• German
• French

insert pie chart e figures are In games chosen valve status

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.

Then, decide on the methods.

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 number 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 elements of Source-based games:

• Game menus
  • Main menus (e.g. Keyboard tab, Video tab, New Game menu)
  • Additional panels (logo, credits)
• Chapter titles find
• Heads-up display (HUD)
  • Standard elements (suit and ammo info)
  • Custom elements (HEV communications, notes)
• Closecaptions
  • Standard
  • Custom Subtitles (Ravenholm.jpg)
• Sounds
  • Standard sounds (suit, NPCs)
  • Custom sounds (radio ravenholm)
• Entities
  • Models e.g. text on health kits (eg HL2 PL)
  • Textures e.g. UCU on walls, posters (e.g Minerva PL)
• Readmes and manuals

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

Binary files

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

• BSP files Example: Combine Destiny
• VMT Example: Ravenholm (PRESENTS)
• tga, bmp

Text files

1. Standard files

The files listed below usually contain localizable strings.

• *.txt files
  • titles.txt
  • scripts.txt
  • valve_english
  • game_ui.txt
  • gamename_english.txt
  • credits.txt

• *.res files
  • models

Example: Combine Destiny text in weapon name

• • panel .res files

Example: Combine Destiny text in main panel name

(not recommended)

Audio

• media files
  • *.wav

Example: Ravenholm: Michael's sounds

Sound resources such as intelligible speech (Breencast, wivenhoe) present a different challenge. With an unlimited budget, the modding and localization team would be able to commission native speakers Perfect localization requires a re-recording of the sounds The text of all custom dialogues, monologues, radio comms, recordings should be reflected in closecaptions_english.txt or in a custom closecaption text file. Recording the localized versions is possible, but extremely expensive. Closecaptions provide a convenient workaround and are also user-friendly for the people who don't hear too well or at all.

The exception would be text content textures and models, such as the names of various Black Mesa labs or the health kit models. It would be quite weird to have German or French "Emergency Exit" signs in an American Black Mesa, although a text commentary (à la Lost Coast) would be useful

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 localzied version of the game.

Character corruption

Description: extended and special charatecters 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)

---