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
.
Introduction
This article describes the various processes involved in 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 and may also be localized, especially into languages not supported by the Source engine and the Steam console.
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
Games suitable for localization
Before the start of a localization project, it is important to determine if the game is suitable for localization. The following questions should help in the decision-making process.
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 content requiring localization?
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 best be undertaken only with the full support of the original development team. Without this support, localization efforts should be directed at games with easy access to localizable content. See #below point xxxx 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 information will not be accessible by the players.
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
- 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 investement 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
Text files
- Standard files
The files listed below usually contain localizable strings.
- *.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
Preparation
Translation
Tracking
- File list
- Version control system
- Folder structure
- File and folder naming convention
Testing
Methods
- checklists
- screenshooting
Tools
Fixing bugs
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)