User:Pb75/sandbox: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
No edit summary
Line 65: Line 65:


===Text content or strings===
===Text content or strings===
Strings are all types of textual content that is used to convey information to the player.
Strings are all types of textual content that are 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.
'''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).




====Files====
====Binary files====
Binary files are commonly used to host localizable strings. This is not recommended
*binary or packed files
*binary or packed files
**[[BSP | BSP files]] Example: Combine Destiny
**[[BSP | BSP files]] Example: Combine Destiny

Revision as of 05:08, 27 March 2006

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:

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
  • 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 are used to convey information to the player.

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).


Binary files

Binary files are commonly used to host localizable strings. This is not recommended

  • 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.
  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

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.

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)