Unity is a cross-platform game engine that allows users and developers to create 2-dimensional and 3-dimensional video games for computers, consoles, and mobile devices. Above is a demonstration of one of many Unity games, Endless Runner. Localized into three different languages — French, Italian, and Spanish — Endless Runner kindly provided a number of issues from the very beginning of the process. Take a look at the steps we took below:Quite simple, no? We thought so, too.

First, we had trouble even starting the game. We entered the asset store and, after hours of searches, finally discovered this demo version of the game. To the left, you’ll notice the blue button that says “Open in Unity”; this button originally had a text that read “Download now.” And so we did. Then, the button text directed us to open the game, and as we clicked on those words, we expected Unity to magically open up with Trash Cat ready to run.

But it didn’t. Well, that’s not completely true — it did, it opened with a window resembling the one on the right. The game didn’t open, though.

After a moment of bonding with Google, we realized that we were supposed to open a Unity project folder that was already existent on my system (but this brings up the obvious question: what if I don’t have one? I was lucky that I had one from course exercise, but what if I didn’t?). Then, the selected Unity game would open the actual Unity platform where we could find the asset store.


Under the downloads section, we finally found those treasures we were searching to open. We downloaded them once again in order to import all relevant assets into our Unity platform. Eventually feeling settled down, we were ready to kick off our localization process as we added the target languages, one of them being Korean. However, little did we realize that we would quickly hit another bump in the road.Notice the exclamation mark above on the main orange button. The source target text read, “Run!” which we translated into Korean. However, the game font “LuckiestGuy” not only failed to read Korean, but also Chinese, Japanese, and Russian. When we downloaded a Korean font “HoonJumbomamboB” that resembled the playful style of the source font and applied it to the Korean text, we believed we resolved this issue. But as the screenshot below already illustrates, the new font ended up applying to the original source text as well, defeating the entire purpose of designing according to each locale. 

As you may or may not have noticed, we took the easy way out of this issue: we avoided it completely by reverting back to Latin languages, French, Italian, and Spanish, and refrained from localizing the game into one of the CJK languages. Writing this reflection on the project, I wanted to take the extra step and actually find the solution that we never attempted. The screenshot to the right shows the “Terms” section in the I2 Localization Resources, and here is where I realized that a simple feature of I2 Localization allows us to change the font based on the selected language. It certainly was not a self-explanatory process because in order to enable that particular feature, I had to create a term to identify a font. I created the term “SmallFont” and designated its type as font, and then selected which font will be used for each language. Notice the “HoonJumbomamboB” font for Korean.


Once the fonts have been established, I went to the UI and selected the text to localize, where I realized that a Secondary Term field had been created. This newly created Secondary Term, which is context dependent, ultimately allowed changing the font according to each target language possible, without affecting the styles of other languages. The result can be seen below.The next challenge we faced was finding the strings. Albeit not terribly difficult to resolve, the issue was simply painstakingly long; initially, we believed we would find all the strings in the code, but it turned out they were all in the User Interface. We willingly played the game in order to find the strings; and eventually, we realized that there were more strings than we ever expected, all of which we organized into a spreadsheet to streamline the process of locating and translating the strings.



Couple other challenges we ran into were dropdown menus and truncation/crashing. For example, now that we had translated all the strings, our next process was to ensure that the user can switch the UI from one language to the next. Enter dropdown menus: and once again, we were challenged. While the selected language was viewable, none of the other options could be seen (see below).

We ultimately needed to adjust the height of the menu along with the font size because simply increasing the font size did not make the text appear (the menu space was too small for the text, so it would disappear). See below for the fixed results.

Finally, when we localized the game into a long, expansive language such as Spanish (occasionally) and Italian (frequently), we noticed that the texts on the menu bar were crashing. The easy solution was to change the position X value of the crashing texts as well as others, so that we not only avoid crashes but also maintain a good level of symmetry. However, the problem did not stop there, as moving texts along the X axis led to a truncation issue. Here, though, we were able to resolve the issue by not only changing the position X value but also redefining the “Horizontal Overflow” feature to “Overflow” from “Wrap.” Overall, Unity was a journey of its own that taught me the crucial lesson of trial and error, as well as thorough analysis of whichever designated platform and/or project. Undoubtedly great lessons learned! 

Categories: Localization

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: