Introduction

As I round out my MIIS education and look back on work I’ve done over my two years here, I’m starting to recognize the importance of the classroom. Not the physical space—as I’m sure all of us stuck indoors during COVID-19’s reign can agree—but the idea of the classroom, and the testing ground it provides. Looking back, it becomes painfully obvious to me that I had only the vaguest ideas of how the language services industry worked when I started my time at MIIS, and little sense of what role I would play in it. The classroom, then, became not only a place to gain an education, but a place to put that education to work. It was a chance to make mistakes, and thinking back, I think I’ve overlooked what a chance that is.

In the field, though, starting and ending a job is a process, and one that can’t fully be taught in the classroom. In the classroom, if an imagined scenario presents an issue, hypotheticals can be changed in the blink of an eye, because they’re not real. They rely solely on the whims of those who thought them up, so in that sense, the education of the classroom can only go so far. In an actual job setting, however, you have very little control over the multitude of variables that come with any given project. From internal politics to budgetary restrictions, available manpower to legacy technology—these are all factors that lie outside the individual player’s ability when trying to develop client strategies. It takes a real testing ground with real stakes to drive home how that balance works, and to learn how to handle it.

Client Education

And in no better scenario was this idea presented to me than in my third semester practicum project. Working with a team of other students, we were brought on to advise a client in both the internationalization and localization of an educational game they’d been developing—internationalization of the game’s code, and localization of the site that supported it. To us, this sounded like the perfect opportunity to flex the skills we’d developed in project managing and localization engineering in a real-world setting. We’d already had a good deal of experience with the 24ways method of internalizing strings in Javascript code, and we figured that implementing it into the client’s code would be a cinch once we were set up with their database.

But this presented the first of our problems. While the code had been billed to us as entirely based in Javascript, once we delved into it, we realized there were several elements going on. There was a mixture of Javascript and Typescript files, and not only that, since the code had touched many hands over the many years of the game’s development, there were inconsistencies between files due to the different quirks of the various developers that had helped with the project along the way. As a monolingual game, these issues had never presented a problem for the client. However, as we looked to taking the code multilingual, we realized that we would have to adapt to our setting and figure out a strategy that both pushed our understanding of localization engineering and fit the client’s needs.

So we got to work figuring out our technical strategy first. Working alongside the client’s main code developer, we devised a way to adapt the 24ways methodology for both Javascript and Typescript in a way that would not chafe against the developer’s coding style. “What a victory,” we cried! “As long as we go through the code and wrap every available string with this method, we should be able to easily extract the strings for translation now!”

But that was only the tip of the iceberg, and our scope had been too singularly focused. Like the Hydra, with one problem solved, two more sprung up to take its place. With the string-wrapping method solved, all that was left was finding those strings in the code. As I play tested the game, creating a list of strings that I knew would have to be cross-referenced in the Git database and then extracted for translation, horror began to dawn on me. First, I noticed just how many strings had issues with concatenation within the code, which automatically flagged an internationalization issue for me. Not every language fits the same grammatical structure as English, so a new method of structuring how strings called-in variables and such would need to be employed. But that only addressed the strings we could find. The second issue that quickly became apparent was that more than half of the strings I came across were nowhere to be found in the Git repository we’d been given access to. According to the client, these strings were all held in a separate database and called into the code from there.

So we set to work preparing for how to educate the client. To tackle the first and most actionable issue, we proposed using a sprintf method to call variables in strings that could then be easily flagged in a CAT tool later on. For the second, we requested access to the database of strings, hoping we could further analyze what strings it held and how we could prepare to adapt them.

But simple ideas in theory don’t always have simple solutions. The main developer was less than thrilled with the sprintf method we’d come up with, since he wasn’t a fan of the printf structure to begin with. More than that, though, with all the inconsistencies passed on from developer to developer, implementing this methodology would mean combing through the code entirely—both everything that had already been written and everything to come. With the tight turnaround of new updates to the game, as well as the limited available manpower, things grew complicated. Finally, letting us into that database, we were told, would be a hassle, and had the potential to pose confidentiality issues down the line.

And so we were stuck between a rock and a hard place—as a non-profit primarily focused on the results of the English-language version of the game, the company would not be able to commit extra hands to such a massive undertaking, and since we ourselves were pro-bono localizers given only limited access to their database, we couldn’t fully supplement the work ourselves.

The reality sank in for us—this was simply not a project ready for internationalization. Of course, this was no singular fault of anyone involved, but an important part of client education is knowing how to do just that: educate. On the localization maturity model, the client had reached the Reactive stage, recognizing the desire from their players to have multilingual capabilities and reaching out to us to help with that goal. But making that happen is a two way street, and a lack of available manpower and the sheer scale of standardizing a code years in the making was not something either side was capable of doing.

Conclusion

So what were we to do? We held one final meeting with the client where we passed on our internationalization guide and our recommendations as to what they could do going forward. Maybe they were not ready at that point, but that was not to say they could never get there, and we wanted to encourage that mentality as they developed strategies for the future. They have the drive to internationalize, and with the right resources both on their side and on the side of the localizers they work with, I’m sure one day a multilingual version of their game will be possible. As I said, client education is a two-way street, and every street has its speed bumps. Knowing how to spot them, and how to let others know they’re there, is half the battle.

I’d like to thank my wonderful practicum team of Daniel Birriel, Justin Flaherty, Zachariah McFadden, and Jimmy Yang. Since this experience, we’ve all moved onto various other projects, and I would encourage any readers of this post to check out on their portfolio sites as well!