“Life is like a box of chocolates, you never know what you’re gonna get.” This famous saying applies to software in more ways than just one. When it comes to software, you can get a variety of codes: codes that make no sense to you, codes where the developer swears that the code is legible but then you realize they put no comments to tell you what to do, codes where there are too many comments for basic concepts (especially ones that say string happybday = “happy birthday” // this code is to hold the user greeting. Buddy, we know it’s okay), or just straight-up poorly written code. As someone who has double-dipped in language and computer science, I feel like I’ve seen all these examples, but especially with internalization in mind, it can be hard to know what to do and how to do it.
Enter: Jankenpon, pikachu, hakembo, ro-sham-bo! Or I guess you would call it, rock paper scissors. Using a github repository from user MOO-ICT, my team, Dayna Brown (she/her/hers), Nicholas Niculescu (he/him/his), and I focused on localizing the rudimentary code for what I call baby coders (coders who are just starting to code) into something localizable and fun. For me, as the one with the most coding experience, I had to fix a lot of bugs. Namely, the fact that the game didn’t actually end. Another problem was also variables that seemed to do something but were written into the code anyway. For example: there is a variable called “gameover” which you would think when set to true would cause the game to end. Instead it just returned. For those not familiar with software, a return usually gets out of the program or function, or it just returns a value. In this case, which you’ll see in the screenshot below, it did absolutely nothing. Even now, I don’t understand what that variable is supposed to do.
When it comes to internationalization, well it gets a little different. Nearly all of the strings of the game were hard-coded into the game which meant that we had to transport all of those strings into resource files…4 times (one for each language including English). On top of that, grammar had to be accounted for each language and while I wanted to do this programmatically, my team members reminded me that only Spanish required spaces so that was all that ended up happening. (Sad for the programmer in me but I digress) Just one little space added to my strings in the resource file for Spanish. But hey, sometimes that’s what happens in software.
Software sometimes requires the quick and dirty version over what is “correct” which is something this project taught me to deal with. Not every person you work with will want to do the “right” option, but rather, the simplest and easiest option. My group members simply didn’t have the energy for the right way and I was freaking out on how to include it as well. But at the end of the day, we still delivered a functional, localized program. Other than the hard coded strings, the UI elements needed to be changed for every language to account for specific changes in each language. For Chinese and Japanese, due to character size, the UI had to be completely resized to account for text expansion and clipping into other assets.
Overall, this project was fun on multiple levels: it was fun to fix essentially broken code, it was fun to work with my friends on a project we all understood, and it was fun to make a universal program for a mostly universal game.
So even if I don’t always know what kind of chocolates (code) are in my box (repository), at least I know now how to handle them.
