User:Pb75/sandbox
French Localization Bugs
Moved to French_Localization_Bugs. 04:57, 9 Nov 2005 (PST)
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.
Scope of localization
The first stage of the localization process is the identification of the scope of the project, i.e. localizable content.
What is localizable?
The examples are taken from the following mods
Localizable content by functional game element
Standard localizable content can be found in the following game elements.
- Game menus
- Main panels (e.g. Keyboard tab, Video tab, New Game menu)
- Additional panels (logo, credits)
- Chapter titles
- Heads-up display (HUD)
- Standard elements (suit, ammo)
- 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 game resource (files)
Localizable content appears either in
- compiled game resources (binaries, graphics or packed text files)
text files
- tokenized text files
titles.txt scripts.txt valve_english game_ui.txt
- untokenized
Example: Combine Destiny text in weapon name
From a localization point of view, any resource that requires compiling, decompiling, (un)packing or converting should not contain localizable content. Editing these resources during localization presents serious or even critical drawbacks in terms of time and effort. Ideally, all localizable strings of text should be contained in self-standing text files.
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
Testing
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.
Minerva:fr draft translation
Moved to MINERVA:fr.