My name is Denis Ivanov, and I’m the Lead Localization Manager at Belka Games. Our company develops mobile games. We have three active projects—Clockmaker, Bermuda Adventures, and Solitaire Cruise—with a combined audience of one million daily users.
Their localization is handled by one team: ours. A vendor translates the game texts, and we add them to the lockits, which are then loaded into the games. We have sprints every two weeks, but our lockits are updated every day.
For as long as I can remember, we worked with Google Spreadsheets. Everyone was comfortable and familiar with it. But at some point, the thought popped into our heads that there must be something better.
When we went searching, we discovered Gridly, a localization platform. In this article, I’m going to talk about what made us go looking for alternatives to Google Spreadsheets, what enticed us about Gridly, how we ensured a smooth transition for the entire team, and what the outcomes were.
If it ain’t broke, why fix it?
Something wasn’t right. It wasn’t that Google Spreadsheets had done anything wrong. It’s just that its feature set wasn’t able to meet some of our needs. For example, when certain phrases were repeated, we had to copy them into a new event each time.
Glossaries were another problem. It was difficult to make sure that the correct terms for game elements were used everywhere in the translations. Inconsistency in game texts confuses players, and since we check and confirm terms in the source text in advance, we needed an additional tool to check the translations.
In addition to this, there were the ordinary human errors in spreadsheets when cells were accidentally edited or text was placed in the wrong ranges. Too many teams had access to the texts, and the system didn’t offer a way to restrict where to allow access.
All things considered, deep down, we wanted a change, one that would include:
- more extensive automation tools
- more flexible settings for access permissions
- the ability to customize the UI for a particular role
- a more transparent system for tracking changes to quickly locate and correct bugs case-by-case instead of scrolling through an endless history of changes and rolling back the entire document
- a built-in translation memory and glossary
- automatic QA checks and LQA models
Eventually, we became ready for the change, and I started searching for suitable options. Over a few months, we collected information on various computer-assisted translation (CAT) and content management system (CMS) tools. We tested them, discussed them, and considered their pros and cons, but for a long time, the search did not bear fruit. We needed something as similar as possible to Google Spreadsheets so that the team could quickly acclimate to the new processes, but with a more advanced feature set and an emphasis on localization. CAT tools did not satisfy the first criterium. They were only convenient for localization project managers. Everyone else would have been forced to suffer at the hands of their very hard-to-use interfaces.
A colleague from a collaborative project suggested I take a look at Gridly. As soon as I saw the web interface and a short tutorial, I knew instantly that it was what we needed. I looked at all the video clips and articles about Gridly in their knowledge base, tested it live, and immediately went to share my impressions with top management and the developers. We ran a few tests: loaded some of our texts into Gridly and tried to mimic the pipeline of one of our projects. It worked! We made a unanimous decision to proceed with the trial version, and we got down to work.
At first, we chose to transfer only one project, Solitaire Cruise, to Gridly. Solitaire Cruise was better suited to our goals than other projects because it was more often the subject of complaints regarding its spreadsheets and workflow. Most importantly, its storage format allowed us to quickly and conveniently move its texts to the new platform. The project’s technical team came on board pretty quickly, and we had a few meetings and discussions, after which we started making all the necessary preparations to transfer over.
Transferring smoothly without disrupting processes
We weren’t deeply integrated in Spreadsheets. In the spreadsheet itself, we were using a script (in Google Apps Script) that generated text files for each locale (language). When a button was pressed in the Unity Editor, the files were assembled in a folder, where they were parsed and used in the game.
The first challenge was to generate these files based on data from Gridly that was retrieved from an API. We had the option to use the existing Gridly plugin for Unity, but we chose not to for a number of reasons. In particular, it involves pretty deep integration, which we didn’t need. It was simpler to write our own solution, so we took the path of least resistance and did it ourselves.
It all started as an ordinary integration task: you send requests, you get data, you process it however you need, and you assemble it. But this is where we first realized that the API’s design is not particularly convenient. It’s like a layer cake: to get to the data in the cells of a spreadsheet, you have to make a bunch of requests about how to get this data.
In Gridly’s conceptual design, each spreadsheet (or “Grid”) has what are called “Views,” which give the web client a flexible way to adjust the appearance of columns of text and access to them. But it turns out that this applies to not only the presentation of data that you’re working within Gridly, but also the data you get using the API. In other words, when you are requesting cell Records using the API, you have to know exactly which View they’re in. Because tomorrow or the next day, someone might hide a column or delete a View entirely with one press of a button, and everything will break. Naturally, this wasn’t the most pleasant surprise, but we learned how to live with it.
Then we proceeded to plan the flow. We had to anticipate all potential needs, work out the little details, and foresee possible pitfalls (which there always are). Working with the project’s team, we put together a wish list and turned it into a to-do list.
To test things, we put the tool into use for the LiveOps team only. The test went well, and we started to transfer the entire project. We paid special attention to training. It doesn’t matter how amazing a tool is—if you take a careless attitude toward onboarding, you’re going to get chaos, dissatisfaction, and a universal response of “put it back the way it was.” Our company employs the rule of “joint decision-making.” We take constructive criticism seriously and can change the process if serious objections arise. If there were negative feedback, we would risk going back to Google Sheets, which we really didn’t want to do.
So, we put together two presentations. In one, we discussed the features of Gridly in general, and in the other, we showed in detail how the flow would change for testers, developers, QA specialists, localization managers, and narrative designers. To make things clearer, we made a step-by-step video of the entire process (which I received a few personal thank-you messages for). Then we welcomed feedback, put it into use, and made sure no one had any questions, criticism, or opposition. Only after that did we completely transfer everything.
Looking at the results—and assessing the benefits
Gridly’s features were reminiscent of an all-you-can-eat buffet: we wanted to put everything on our plate. We integrated the features that would give us the most noticeable boost.
Here’s what ended up on our plate:
- Branch creation. Now testers can separate changes that come from different sources. This is awesome when you’re working on two or three large localization tasks at one time.
- The Grid system, in which we can customize our own Views. This way, we can restrict access to Views and specific columns. Now each department only sees the information that’s relevant to them. Very few people can edit the text, which saves us from typos and partly protects us from human errors.
- Screenshots. We’ll be able to take screenshots in which the text that corresponds to a chosen key is highlighted on the screen and send them right through Gridly. We haven’t integrated this yet, but we’ve laid the groundwork.
- Built-in translation memory. The system automatically inserts text if certain phrases have already been translated, so we don’t do unnecessary work. In tandem with the built-in glossary, this really helps us keep texts consistent.
In addition, the process for development and testing has changed. Now we:
- Aren’t dependent on the time when builds are compiled. All locales can be loaded right into the build.
- Can import the localization files right into repositories, compare multiple localized files, etc.
- Can load only certain statuses, instead of all the localizations as a whole, when compiling localizations into a build or bundle.
- Made a locale validator that serves as an extra stage of verification.
Before Gridly, the flow for changing locales in a build looked like this:
Our current flow looks like this:
Sure, the flow hasn’t changed much—and that helped us make the switch to Gridly quick and seamless. All that’s changed is that, in the past, when there were bugs and edits in events, we had to pester the developers each time. But now, we only need the developer at the start of the process to enter the keys into the code. After that, it’s a joint operation between the Localization Manager and QA. Thanks to the new approaches and tools, the QA specialists themselves test and pull the localization changes for both downloadable content and the client. Developers are freed from the routine, and we reduce the amount of interactions and optimize our processes.
Because of the new features, localization has gotten way easier. During the transition period, many people wanted to go back to the tools they were used to, but now all the feedback is positive.
Summing up
We pursued several goals:
- excluding the developer from localization processes where possible
- adding features that we were missing in Spreadsheets
- ensuring a seamless transition to the new tool
Our mission was accomplished.
We had planned for all the optimizations to save time on QA, and that’s what happened. LQA takes two to three times less time than before. Here too, we achieved the desired result, and, most importantly, the change in processes didn’t sacrifice quality.
The transition has benefited our vendor as well. Gridly offers a great way to integrate with the CAT tools Memsource and memoQ. Alongside INLINGO’s team, we set up a seamless localization process, and now translations are instantly and safely entered into our Grids directly from memoQ.
Of course, you can’t have pros without cons. We’ve discovered two:
- The platform’s large feature set prevents it from being as fast as Spreadsheets.
- We are integrating a third-party service into our company’s processes, which is a complicated decision. We are dependent on someone else’s framework, code, development processes, and infrastructure. There should always be a plan B, in case the servers go down or there’s a buggy update.
Still, the pros outweigh the cons. Besides, Gridly has responsive customer service. We encountered a problem with scrolling, and it was fixed in literally a week. By comparison, with some tools, you can wait several months for a fix.
Overall, we can say that we didn’t lose anything by switching to Gridly—we have only gained from it. Solitaire Cruise has already transitioned to the new pipeline, and our other projects are next.
