User:Pb75/sandbox

Localization of HL2 Third Party Mods

// 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 eveything, encoding, test tips TEST FRENCH***, resizing panels

Wednesday November 9th, 2005

The objective of this page is to provide step-by-step instructions for the localization of Half-Life 2 third party mods.
.

Introduction

This article describes the various processes involved in the translation or localization of games based on the Source engine. The examples are taken from the following published single-player mods:

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

Localizable content

The first stage of the localization process is the identification of the scope of the project, i.e. localizable content. 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 in game resources

Text content or strings

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

Note 1: 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 would require 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 investement of resources can be easily avoided if all localizable strings of text are contained in self-standing text files.

Files

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

• text files

1. Standard files

The files below contain localizable strings.

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

1. Non standard files (not recommended)

• *.res files
  • models

Example: Combine Destiny text in weapon name

• • panel .res files

Example: Combine Destiny text in main panel name

• media files
  • *.wav

Example: Ravenholm: Michael's sounds

===Defining

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

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

---

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

---

French Localization Bugs

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

---