MultiLingual June 2016
Character corruption has always been a major issue in video game localization. So far, the video game industry has taken a mostly passive approach to solving this problem. Instead of proactively tackling the issues at the source and eradicating them completely, most companies rely on testers to flag individual issues as they are encountered during play tests.
This reliance on human testing makes for an extremely error-prone and risky approach, especially considering the sheer number of string updates most games go through with each build iteration; the number of languages video games are localized into nowadays; and the difficulty of triggering every single game string through a normal playthrough....
Although every game may approach font textures and character support in slightly different ways, most games I have localized relied on font textures generated from font files. Font textures are basically sets of glyphs the game calls up by using a character's hexadecimal Unicode value. This set of glyphs is normally generated by embedding the list of characters we want to support in the application the user interface (UI) team uses to convert the font file into font textures. If a given font file does not support the Spanish character ñ, for example, the generated texture will not contain a glyph for it and, as a result, this character will show up in-game as a square, a question mark or simply won't appear at all. If a font file does not support a character we need, we have two options:
Change the font. This is extremely risky to do after localization quality assurance (QA) has started, since the font size could change, affecting all menus and forcing you to potentially have to retest the game from scratch.
Add the missing characters to the font. Adding a new character to a font is a solution most companies will want to avoid....