User:Pb75/sandbox

From Valve Developer Community
Jump to navigation Jump to search

Localization of Games based on the Source Engine

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

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

If you don't have the time to read the entire article, but you would like to have your game localized with minimal effort, you shoudl observe two main rules in designing your mod:

  1. Place all game texts in text files, not in BSP or VMT files.
  2. Provide close captions for all custom speech and audio elements.

Introduction

This article describes the various aspects of the translation or Wikipedia:Translationlocalization 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:

Concepts

The following concepts are used in this article:

  • localization: the process of translating software user interfaces from one language to another and adapting it to suit a foreign culture.
  • 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 to produce the textual and audio elements of the game.
  • target language: the natural language into which the localization team is translating the localizable content from the original game.
  • localizable content: ##see below
  • Source engine 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 performs the localization of 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 and the associated SDK. An established localization team can also expect to be approached by a development team and asked to localize a particular game. Whatever the method, it is important for the localization team to analyze and playtest the game thoroughly 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. Considering 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 or unfinished 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 many new dialogs or custom voices. 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.

Example: Causality Effect

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 in most cases 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 this 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.

This issue is not a factor if the localization team has access to a large budget, a professional sound engineering facility and professional voice talents.

Example: The Fall of Wivenhoe

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 with the gaming community in its orginal 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

Objective factors

The following factors determine the target languages into which the game is to be localized.

  • available competent translators in the required language combinations
Translation is a complex art requiring a deep knowledge of the source and target languages as well as mastery of translation techniques and relevant terminology. Some proficiency in the source and target language (college level) is usually sufficient to produce a readable target text, but such a text will often fail to match the style and quality of the source text and the fact that it was translated will be immediately perceptible. A good translation in the context of games is often transparent, i.e. the user does not realise that he or she is exposed to a translated text.
  • available localized versions of the text resource files reused from the Half-Life 2.
Half-Life 2 resources are fully localized into the following languages:
    • French
    • German
    • Spanish
    • Italian


esavailable in (list of languages)

Subjective factors

Popular languages

If the objective of the localization effort is to allow the game to reach the widest audience, it is important to focus on the most popular target languages. The metrics in the language section of the Valve User Survey 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


Requested language

The localization team may be tasked with the translation of the mod into an unsupported language. The project's scope will then invariably be larger, as on top of the custom content, all the base content resused from HL2 resources (closed captions, UI, HUD, etc.) will have to be localized.

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

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

Quality assurance

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


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)

Notes

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

  • 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
Retrieved from "https://developer.valvesoftware.com/w/index.php?title=User:Pb75/sandbox&oldid=47116"