|
The days of "all your base are belong to us" style translations might be thing of the past, but localization is still one of game development's Cinderella specialisms.
"A lot of people in the industry still don't understand localization very well," says Kate Edwards, chair of the IGDA's Game Localization Special Interest Group. "Many still think of it as something done at the end, but it is as much a part of the development cycle as coding or writing or designing."
But as the pressure for games to connect with a global audience grows, localization is starting to shed its afterthought status. When Sandra Pourmarin, localization manager at Ubisoft Montreal, joined the studio eight years ago, localization was closer in status to the testing department than the development team.
"All the localization resources were on a separate floor and worked as a service to the development team," she says. "Now the localization project manager is under the direct responsibility of the producers and we're on the same floor as the team. It's a huge improvement."
Localization is also starting to show that it's about more than translation as developers and publishers start to think more about how their games will go down in different parts of the world.
"Everyone perceives localization as language and for the most part it is but that is not all localization is," says Edwards. "Culturalization -- thinking about the use of symbols, environments, costumes, everything that isn't language -- is also part of the big umbrella of localization."
So how can developers and publishers make sure their international appeal is up to scratch? To find out we asked the localization pros who have worked on games such as Diablo III, Assassin's Creed and Fallout 3 for their helpful hints.
1. Make the context clear
Games often get translated before they are finished, so any text or speech handed over to the localization studios needs to be accompanied with detailed information about the context, says Irene Panzeri, content lead at localization studio Synthesis which has worked on titles such as Diablo III and Red Dead Redemption.
"Languages don't share the same grammar rules. In English 'you' is both plural and singular, but in French the singular is 'tu' and the plural 'vous' with the verb changing accordingly. Knowing how many people a character is talking to is a common dilemma for translators." Clarifying words with dual meanings is also important, she adds: "Does 'aim at the tank' mean aim at a fuel container or an armored vehicle?"
Assassin's Creed: Revelations
2. Let localization in early
Getting the localization team involved as early as possible can reduce crunch time headaches says Pourmarin. "With Assassin's Creed: Revelations the localization team worked with the development team on localization earlier and it really smoothed the process," she says.
"If we are aware of specific content that might be a challenge we can prepare for that and come up with options for how to address it rather than trying to do it in the rush time at the end of the project.
"For example on Assassin's Creed, we had cameras that needed to move to avoid showing some nudity that would be a problem in some countries. Being able to identify that early in the process is very precious. If you arrive late on a project with those issues there might not be time to tackle them properly and that will result in additional cost and harm the quality of the game."
|
Printer-Friendly Version
"While making Scourge: Outbreak, we initially made the mistake of cutting phrases into chunks, and storing text separately, so the code could string them together in the multiplayer mode to create phrases like '[Player 1] captured [Team 2's] flag!'," says Salleh. "But that meant these words were being translated out of context, and the game engine was stringing them together in a way that might make sense in English, but not in Spanish or any other language. So we had to go back through every message of this type, so that we didn't end up with Yod- speak like 'Captured [Team 2's] [Player 1] Flag! The' in other languages."
String sentence = Player.Name + " captured " + Team.Name + "'s flag";
=> John captured Red team's flag
In french this results in:
=> Jean a capturé équipe des Rouge drapeau
which does not work and should instead have been:
=> Jean a capturé le drapeau de l'équipe des Rouge
The problem is that you cannot append translated words in different languages; the structure of the sentence varies. One solution is to use sentences with replaceable parts:
String sentence = String.Format("{0} captured {1}'s flag", Player.Name, Team.Name");
Which can be translated to the following for French:
"{0} a capturé le drapeau de l'équipe des {1}"
For instance, if you send the translators:
"{0-PlayerName} captured {1-TeamName}'s flag" they can tell at a glance what those wildcards mean, and you'll have fewer cases of parameters getting switched accidentally.
A preprocess can later strip out the "-PlayerName" hint which isn't actually used by the code.
Regards,
Joe Hobbs - Recetas Faciles
I can't help but feel this detracts from the artistic merit of the game as a whole, but it comes down to the whole product vs artwork discussion in video-games. Maybe it doesn't matter, if it didn't interfere with the vision of the game in any meaningful way.
And of course, there are parallels in history, to how the church chipped away at nude statues and covered up crotches with leaves, as to be more in tune with the cultural sensibilities of the time. And if that is an apt analogy, then the issue is more clear. Art-pieces were often commisioned and given parametres, but it was the artist's interpretation and execution that determined the final outcome. Retrofitting that work detracts from the overall quality, as it does not come from the creator of the piece, and does not consider it in the same fashion.
Is then tailoring a work of art towards an audience about balancing the values of the product and the values of the art? Are video-games "different", and cannot be considered as one or the other, but only a amalgation of both? Am I babbling?
By the way, I read both pieces, and this piece certainly wasn't plagiarised from Gabriel Swan's article.
Frankly, Gabriel Swan's unpolished and badly-structured article reminds me of the time that I met a con-artist, who tried to snow me with buzzwords and industry-speak.
Admit you're wrong when you are, instead of trying to remove the evidence of it. I guess it's easier to hide faults than learn from them.
I made a point of showing this article to my gaming students. Localization is more than the language; it's also making sure your game can accommodate local cultural norms. The "my way or the highway" approach to game design that so many beginning students insist on is limiting rather than liberating.
If everyone got their way, preproduction, instead of being a tightly focused process of exploring the fun and validating core features, would turn into the cat-herding issue that production has become, and would end up solving nothing.
I wish these articles would focus on the idea that, no, frankly, there are some tasks that will always have lower dependencies and *should* be less integrated, and done at the end of the project, and the solutions presented understand that is the case, and just pointed out what things really should be considered ahead of time, rather than taking the stand that their discipline should be included in every key meeting.
So, some of the recommendations listed above are fine, but for instance, if every discipline got to appoint a "watchdog" as they author insists, you'd be committee'd to death on every game, and nothing would get made.
To paint the other extreme, RPG's are very text-intensive. The sooner you can get your 'text-freeze' in place the better, but in truth, RPG's are so text-intensive that you're bound to be localizing new stuff until the very last weeks of production. The 'text-freeze' simply doesn't happen.
I guess the same is true for games that have all sorts of installers and console deployments, or when publisher decisions regarding regions are late etc.. We've come to a point where our pipeline handles out-of-synch loca updates: text that was sent off to loca comes back as invalid because the original is already changed again. If you don't handle that robustly, loca is a huge mess.
One major issue is the impact loca can have on menu screens and in-game content, i.e. when using eastern language fonts, or supporting japanese keyboards for text-input. If you don't design around these things early, you're in for a big surprise later.
Also, I would add rule nr 0 : use unicode.
If you don't plan properly for this stuff, you will end up with shoddy results, which is a tragic outcome for a AAA game with an 8-digit budget. If you don't want your game to come across like a badly-dubbed foreign film, you need to have someone overseeing localization issues early enough to address them, and you need to try and lock your script as early as possible and then get the first translation pass done and the results into the game, as soon as possible. And you need testers who are fluent in each language, assigned to play everything in the game in that language and report anything which is incorrect or awkward in the context where it appears.
I have seen a number of localizations where the authentic font was replaced with Arial or something like this, which, in my opinion has negative effect to general atmosphere of the game. Personally, I never use such localizations and either buy an English version of the game or do not play it at all.
Probably, the reason is that it would not be much easier to implement a cyrilic font (in my region) similar to the original one by style, than an eastern language font.
- Vladislav Arkhipov, http://gameponder.blogspot.com/
The fourth section (Impose a text freeze) doesn't make much sense in today's development world. Nowadays no dev team can really impose a text freeze and respect it. If translators wait for that text freeze to happen before starting the translations, the localized versions would ship 3 months after the US version.
Using csv files is not a great approach either. Dev teams should invest time and resources developing a content management solution (or buy one) to store all the in-game strings and subtitles. This solution should support exporting to and from Excel, in a translator-friendly format that properly diffs every modified string to allow translators to be as efficient as possible. Ideally, this solution should also allow remote logins and a proper interface for translators to translate the last-minute additions and changes in the English texts. Some solutions out there even allow translators and loc testers to see their changes right away in the localized builds (the game connects to the server where the strings are stored to retrieve the latest localized data). This feature greatly reduces the time needed to fix certain localization bugs (mainly cutoffs, overlappings, line-break issues, etc.).
Another pet peeve of mine is when there is recorded voice dialogue that doesn't exactly match the text subtitle being shown, for whatever reason. I always turn subtitles on if the game has them, and I often notice that the recorded dialogue differs in a few words from the text being shown. Regardless of what the original script said, once you have localized voice samples in the game, try to make sure the subtitles for that language match what it says. I know it sounds like a minor thing, but a well-polished game should have accurate subtitles.
Modern AAA games can easily contain tens of thousands of text strings, which might be localized into a dozen or more languages. At ship time, AC:2 had voice localization in seven languages and text localization in fifteen languages, and if I recall correctly, there were more than thirteen thousand lines of dialogue that had to be localized into all of these languages. Even the most thorough reviews are going to miss a few things, you need time for your testers to find those things and you need time to fix them, and more time and testing after that to assure yourself that the fixes didn't break other things.
Instead of an actual text freeze, all the English texts (note I'm only talking about in-game texts here, not VO) should be properly proofread (by an English linguist) and approved (by the game's script writer) before the first translation request to minimize the amount of text updates and translation iterations the assets will need to go through. But I think it is completely normal if the dev team needs to add new strings and modify texts after this first translation request.
VO is of course a different story. You really need to freeze the English VO and subtitles before recording the localized VO, since you cannot normally afford re-recording the localized VO.
I recently had to loop over Asian performances and get the timing down to within .3 seconds and the language itself can take longer to say in English than some other languages. Happy to help with scripts, but overall, a lot of script writers never speak their scripts out loud, which should happen well before we get them with enough time for someone like me, with a degree in English and a good ability to write for spoken word, can tweak things to make them flow better when acted out.