Translation: Streamlining localization

Localization – A freelancer's point of view:

As a freelance translator who has been working on various published titles for various agencies and publishers in the past, I'd like to share my experience with anyone who is interested in organizing a faster and better localization process.

The ideal scenario is as follows:

If this database can be exported into a excel file, everything will be fine and translators will be overjoyed to be working with something properly documented and organized for a change.

The majority of poorly translated terms come into existence because the context/big picture was lost. – I have been working on material in the past where dialog entries, system messages and players' answers were happily presented together, without any indication about who is actually talking to whom. I spent more energy trying to figure out what's actually going on than actually thinking about what would be fun to read in this situation. 

Hiring a translator (edited):

Translators can translate about 12500 words/week, this includes checking, research and filing queries.
The cost can be anywhere from $90-$180/1000 words, depending on the people that are hired, their experience and the material. Hiring an agency to do the loca will eventually produce acceptable results, but it is neither the cheapest nor the fastest option. For games with < 50,000 words hiring one freelancer for every language pair will be enough.

Organizing: 

In theory setting up the database should be enough. All a team of translators needs is a bunch of excel files and some kind of "map" to know where the strings have been taken from. This "map" can be a beta or full version of the game, preferably with a number of console commands to trigger events, spawn items or jump to certain parts in the game. If this is not feasible, screenshots of the different scenarios within the game (interface main and sub screens etc.) will work as well.

If the context information for every bit of text is readily available, the translation process will be smooth and the results will be excellent.

Format: UTF8. Variables and non-translatable text should be marked by using characters like {} or [] that aren't used in a normal text.

Text: Text strings that are assembled from substrings usually don't work in any other language than English. That means that strings like "{prefix} {item name} of {suffix}" should be avoided, and sentences like "{mission name} failed because you {reason}" should be avoided as well, if possible. In theory it is possible to implement strings like those, but this will be more expensive than simply adding the strings individually. (The various permuations of above mentioned strings will be >70% matches that are translated at a discount).

Variables: When using variables, proper nouns, place names and numbers are unproblematic, at least for German. Simple sentences with numbers and nominative clauses like "{name} is now a level {number} {class name}" usually work (in German). Pronouns and any sentences where adjectives are used in tandem with variables are problematic: So sentences like "Your mighty {class name} is now level {number}" or "{name} needs to have their {item} equipped", will create problems. In oder to solve those problems, having a way of looking up those strings and analyzing their function is the cure.

String IDs: It helps tremendeously, if string IDs are meaningful. In a perfect world the string ID contains information about the function and context of the strings.

Examples:

This list could be continued endlessly. There's probably a guideline for designing string IDs available somewhere.

This article tries to give a general idea about what would be desirable from a translator's point of view. Any thoughts, comments and ideas on this subject are welcome.