During my time discovering the finer nuances of software and games localization at MIIS, certain aspects of the process have enlightened me to practical strategies and techniques that could be leveraged for efficiency and process optimization. They are, namely, baked-in localization support and internationalization practices. Implementing or taking advantage of them requires a technical skillset that is becoming increasingly necessary in a PM’s repertoire and not merely reserved for the engineering team. I have often heard that localization project managers must wear many hats, because the localization process encompasses so many different types of tasks, but when software and video games are involved, computer scientist seems to be an unavoidable one.
Two of my colleagues, Nathaniel Bybee and Rebecca Guttentag, and I undertook the task of localizing a brief demo of “FPS Microgame”, a game developed using Unity. And, if it wasn’t already obvious, the nature of the task necessitated that we wear our own computer science hats. But along with our new roles came unique challenges requiring solutions that certainly took us out of our comfort zones. What follows are some of the steps we took to overcome those challenges in our attempts to track down and retrieve strings for translation.
From the beginning, we were able to utilize a pre-existing baked-in localization method known as “I2” [read: “eye” two] with Unity which significantly aided our efforts to track down strings. In fact, the very first strings, the title screen text and opening menu buttons for example, were easily retrieved for localization using this method. I2 works by allowing developers to attach a localization “component” to an object in Unity. This component contains all of the options and attributes necessary for smooth localization by targeting the strings and providing the localized versions to be stored in it. It even allows developers to localize images (with DTP in my case) and associate the localized versions to their respective languages so that when, say a language selector is used, the correct image is loaded in when switching languages. With source files available for easy access to strings, this entire process could easily be streamlined and become highly efficient. Since I didn’t have access to the source files, however, I was forced to do the usual work of recreating the text over a mask so that it would be editable and, therefore, detectable by a TMS. You can see my work below.
The major challenge we encountered after the initial strings and images, unexpectedly, was string concatenation. Anyone who’s done software or game localization might cringe at that term for good reason. It’s essentially a nightmare for localization and represents bad internationalization practices. If you look at the image below, you should see two strings with a logical coding statement between them. The nature of this particular block of code causes the entire string to be formed only when the code runs, but it’s impossible to translate accurately as is.
Fortunately, however, with a little bit of recoding, I was able to structure things so that the two potential strings this statement could make were separated and made into whole strings that could be wrapped in our I2 localization method. This allowed them to be stored in our list of strings and sent to translation with everything else.
The significance of this issue lay in internationalization best practices. Imagine a situation where the PM doesn’t know how to code and then they have to ask an engineer to step in and help. That’s wasted time that no one needs. Thus, internationalization became a critical issue in this case (and there were certainly far more that we didn’t get the opportunity to examine). It’s my hope that issues such as these can be evangelized to developers so localization processes might be optimized for software and gaming localization for the future.