The Game Localization Handbook

I see there’s a [newer edition]https://www.jblearning.com/catalog/productdetails/9780763795931 of this book. Here’s a review of the first edition that I wrote on Epinions, so it’s a bit dated (with reference to hardware).

As video games become more respectable(?), an increasing number of books, magazines and web sites offer to divulge the “secrets” of game development.

The sexiest category is game design — stand in a crowd of game designers and you’ll hear them tossing around phrases like “tweaking”, “balancing”, “finding the fun”, and “removing the fourth wall”. Programmers get their fair share of glory, too — your eyes will glaze over as they discuss AI, game physics, 3D rendering, and the ever more complex game hardware. No one knows what producers really do, but they’re often quoted in interviews and they accept game awards, so whatever it is, it must be important.

Unfortunately, actually shipping a game involves inglorious tasks like testing and packaging, user interface implementation, and fulfilling all the detailed and sometimes conflicting requirements of publishers and hardware vendors. These tasks are often assumed to be “easy”, and they are — in the sense that digging a ditch is easy, yet grueling and time-consuming.

One of these mundane yet crucial areas is localization — the process of converting a program to run and appear correctly for a different part of the world. More and more, it is assumed that console video game (as opposed to a PC game), will be released in more than one region (US, Japan, Europe), and any game that encounters success is sure to have additional localizations performed (I worked on a special-case French localization of an arcade game for a client in Montreal, to satisfy the local statute requiring mostly French text in just about everything).

You can find a few articles here and there on localization, but now there is an entire book, Heather Maxwell Chandler’s The Game Localization Handbook, published as part of Charles River Media’s sizable Game Development Series. The book is ambitious in scope, covering the business case for localizations, degrees of localization, the various assets that need to be localized, planning, budgeting and executing the localization work either in-house or via outside vendors.

The author’s bio indicates she is a producer at Red Storm Entertainment, known as the developer of the Tom Clancy games. This background seems to correspond with the strengths and weaknesses of this book. As a producer, she ably presents an overview of the cost-benefit analysis for localization and the available levels of localization (ranging from none to just the packaging to full blown in-game text, graphics, and voiceovers). The itemization of production and marketing stages for localization and checklist of assets that potentially have to be localized fulfills the “handbook” part of the title. (Depending on what part of the production pipeline you’re in, it’s easy to overlook things like manuals that have to be translated and reprinted, graphic symbols that make no sense in other parts of the world, and things that just won’t fly in certain countries, e.g. Nazi symbols are not allowed in Germany)

But as an independent developer (as opposed to a publisher), Red Storm likely contracts out much of its localization work, and thus the Handbook provides tips on finding and negotiating terms with localization contractors while the section on in-house staffing is skimpy. And while I love seeing real sample project documents in these types of books (every practicing or aspiring game developer wants to know what people really charge), I’m a bit troubled by one sample quote that spreads a fixed cost over multiple languages. What happens if the publisher decides to forgo one language (and believe me, publishers change their minds all the time)? You can say, excuse me while I recalculate all the numbers, or more likely the publisher will take that increment out of your profit margin, if you have any left (one publishing executive stated at a recent conference that a deal that puts a developer out of business is a good deal).

Maybe there is an element of political correctness in avoiding criticism of publishers or localization contractors — as an independent game developer, you don’t want to antagonize them. But I’m a little surprised the book doesn’t mention that there can be many iterations due to shoddy work. On every localization project I’ve worked on, I’ve had coworkers point out that translations provided by the publisher were wrong (I highly recommend having an international staff). One group corrected half of their translations and then went on vacation without telling me which half was fixed.

The book is weakest, not surprisingly, in its treatment of the technical issues. The author hits a lot of the high points, but you get the feeling she’s regurgitating what she’s heard from the programmers on her team, or the snippets of developer interviews that are interspersed throughout the book. For example, she mentions that for localization, game code should be Unicode or double-byte enabled, rather than using single bytes for each character.

Things are a actually a bit more complicated — Unicode is an assignment of numbers to every possible text character in the world (so indeed you need more than one byte to represent that range of numbers), but there are a variety of ways to represent that within a program, including double-byte but also schemes that allow variable numbers of bytes, e.g. one byte for English text (same as ASCII) and as many bytes as necessary for other character sets. By the way, this isn’t particular to games — proper web pages are supposed to indicate what encoding they use, and quite possibly you’ve run into cases where one byte included regular characters plus just enough more to handle a few European languages (Latin-1).

And the treatment of console issues doesn’t indicate the true pain you can encounter when you’re not developing for PC’s with their gobs of memory. Start with a game running on a PC with 256MB, pretty much minimal today. A version running on the Xbox has only 64MB, which still isn’t too hard to work with. But then move down to the Playstation 2 with it’s 32MB. And then the GameCube with 24MB. If you double-byte all the text, you’re doubling the memory occupancy of that text (we’ll ignore issues with data size on disc).

Also, additional or larger user interface elements (larger buttons and menu items, name entry keyboards with more keys for a larger alphabet) take up memory. The author describes the difference between the NTSC TVs we’re familiar with in the US and the PAL TVs in Europe, but doesn’t note that the larger number of vertical lines also means a bigger chunk of memory used for display. (You can run into a lot of problems with the 60Hz vs. 50Hz difference, too)

But the biggest omission on the technical side isn’t in the details — rather it’s in the big picture. The author advocates, rightly, planning ahead for localization, and that is sufficient for well-defined tasks like translating the player manual. But the whole approach may leave the reader with the impression that as long as the programmers have used the right coding techniques it’s just a matter of dropping in translated assets when it comes time to make a European version.

This is why we have crunch times. Not only should you plan ahead for localization, you should have localization from the beginning of the project on. This doesn’t mean you have to have all the full German translations at the very start, but it does mean you should have prototype German builds early on so you can see there’s no way that word is going to fit on that tiny button.

And you’ll know early if the PAL version will run out of memory or have weird object collisions because of the different frame rate (I’ve run into both). On one game where I started doing regular PAL builds early in the projects, I really did just need to swap in translations at the end. On another project where it was more of an afterthought, the programmers didn’t even have PAL TV’s to test their changes.

Overall, notwithstanding programmer gripes, this book is a welcome addition to the game development literature (which was non-existent a decade ago).