Mobile game localization: Insights from a Department Lead

Gain inclusive insights and best practices from Denis Ivanov, Head of Localization at Belka Games, to enhance localization workflow for your mobile games. Read on to discover more.
Localization
Gaming
 01-31-2024        Ngan Phan
Mobile game localization: Insights from a Department Lead

Extracted from a webinar that can be found on Youtube, this blog post serves as a comprehensive recap.

Varied exchange files practices: A barrier to a lean process

Belka Games comprises 350+ employees dedicated to managing three mobile game titles that serve one million daily users. Along with these and further upcoming releases, all mobile game localization projects are overseen by Denis Ivanov, the head of the Localization department.

Denis collaborates with two mana gers, and together, the team of three engages with various contractors, including freelancers and localization studios, to ensure the comprehensive localization process for these game titles.

Before the team adopted the current process, the file exchange process varied depending on common practices shared within the team working on each localization project. The team used a CAT tool within the company, as well as Excel files or Google Sheets when collaborating with freelancers and contractors.

They extracted the text from the CAT tool, input it into a Microsoft Excel file, and then shared it with the contractor through Slack. Upon receiving the file from the contractor, they saved it on the manager’s device and transferred it back to the CAT tool. Consequently, this localization process caused difficulties for those working on the project.

A unified process, but still perplexing the localization team

As a localization team lead, Denis continues to work on building a unifying process, starting from selecting a contractor based on the results of the localization qualifying test to choosing tools and software to optimize operational costs and ensure the smooth flow of the entire workflow.

Learn the best practices for building a game localization process

Upon the transition, the Belka Games team switched from working on Excel files to using Google Sheets. Initially, this change was a breath of fresh air. Google Sheets proved to be fast and, importantly, free. The unique localization kits were consequently built around the use of Google Sheets.

However, the use of Google Sheets soon revealed its limitations.

In one project for the game title “Clockmaker,” the team placed texts in one localization kit and texts for bundles and LiveOps in another. As a result, they frequently felt disoriented, particularly during LQA testing.

When the contractor discovered a bug in a key, the team had no idea where the key was stored. Similarly, if the contractor found text errors, the team wouldn’t know where to locate the corresponding text. The challenge intensified when dealing with Japanese or Korean language text, with which the team was not familiar.

Solitaire - another game title proved to be an even greater challenge. Denis’ team used one loc kit as a draft, where texts were broken down into versions. The second loc kit held the final texts, and the third was for bundles with LiveOps.

Correcting any text in this process would potentially create chaos. Denis and the team had to address issues in the draft and both final versions, all while maintaining consistency and embarking on a meticulous search to identify and rectify all lines containing identical text.

The team also found it challenging to ensure the consistency of all game terms. Occasional human errors could lead to chaos in Google Sheets. Since too many teams had access to the texts, the system didn’t provide a way to restrict access.

As the challenges escalated, especially in projects involving the coexistence of different localization kits, Denis and the team began searching for features that were absolutely essential for comfortable and accurate localization. Unfortunately, the current workflow in Google Sheets fell short when addressing the complexity of the localization process. All these struggles made Belka Games’ team to search for a solution that provides:

  • Automation tools
  • Better access controls
  • A custom UI
  • A more straightforward way of tracking changes
  • Translation memory
  • A built-in glossary
  • Machine translation capabilities
  • Automatic QA and LQA checks

A transformation unleashes efficiency for localization workflow

After trying out a few CAT tools suitable for localization project managers but not for anyone else, Denis turned to Gridly due to its UI, which is similar to Google Sheets. This allowed the localization team to quickly adapt to the new processes with the required features mentioned above.

A game-changing transition

To facilitate the transition from Google Sheets to Gridly, Denis highlighted key experiences for the entire team, viewed from the perspective of a localization lead:

  1. Learn the basic components of a Grid to establish the entire infrastructure in Gridly, including creating projects and databases.

  2. Transfer the glossary using Gridly’s built-in glossary function.

    One important note from Denis is that creating a glossary and transferring all the terms from Google Sheets into Gridly should be done before setting up Grids and transferring the texts. This practice saved Denis’s team a great deal of time in the second transition process compared to their first transition.

  3. Clarify logical tasks for developers, such as understanding how to work with the API.

    At this stage, Denis and his team introduced the concept of creating statuses, which they currently use to monitor the translation and testing stages.

  4. Establish access to Gridly with the system administrators, distributing credentials to everyone working with texts and translations.

    One important note from Denis is that creating a glossary and transferring all the terms from Google Sheets into Gridly should be done before setting up Grids and transferring the texts. This practice saved Denis’s team a great deal of time in the second transition process compared to their first transition. Access for QA specialists was restricted, while full access was granted to developers, enhancing security. Business development, marketing, and project managers were completely blocked from making edits.

Based on Denis and the team’s experience, 4 noticeable features in Gridly could play a game-changing role, and localization specialists should invest time in learning them:

  • Branch creation: Testers can now separate changes from different sources, which is a lifesaver when working on multiple significant localization projects simultaneously.

  • Customizable Views in the Grid system: This allows the localization lead to restrict access to certain Views and columns, ensuring each department sees only what’s relevant to them. This results in fewer people able to edit the text, reducing typos and human errors.

  • Screenshots: It is easy to capture screenshots with highlighted text and send them directly to Gridly.

  • Built-in translation memory and glossary: The system automatically inserts text if it has been translated before, helping the team maintain consistency in their texts.

Furthermore, there are some additional tips that Denis highly recommends from his own experience to help the entire localization team take full advantage of Gridly.

  1. Settle on a grid template that would serve as the basis for creating other grids, as manual edits would be required in the created grids.

  2. Include the functionality for pulling screenshots from Unity into Gridly as an improvement rather than in the initial iteration of the transition. This ensures that the focus remains on the migration process itself, which is more time-consuming and critical.

  3. Work in separate branches instead of a single branch. It was discovered that relying solely on the QA Verified status could lead to issues if someone were to change that status, causing the status and corresponding texts not to be pulled. One branch would serve as a draft, while the other would only contain QA Verified or Disabled statuses that cannot be changed.

  4. Maintain separate translation memories for each project to prevent legacy issues from impacting one another.

  5. Create a separate view for character limit monitoring, allowing for real-time tracking of the current character count. This is particularly crucial for UI designers and narrative designers.

  6. Divide your grids into multiple databases within the project. This will make it easier for you to navigate Gridly and keep your texts organized.

  7. Create statuses for each stage in your localization pipeline. This will make communication easier and help you understand what stage each line is currently at.

Developers freed up from routine work

As a result, the development and testing process improved significantly. Denis and the team no longer have to wait for builds to compile, can compare multiple localized files, and benefit from a locale validator for additional checks.

According to Denis, the flow hasn’t changed much. The only difference is that instead of bugging the developers every time there were bugs or edits, the Localization Manager and QA team now handle it together. This frees up the developers from routine work and optimizes their processes.

Important factors for a successful mobile game localization strategy

From Denis’s experience, in addition to a video game localization tool like Gridly, there are several factors that contribute to a successful game localization strategy. These include technical preparation, language selection, a lean team with effective processes, and localization quality assurance.

Technical preparation

In ensuring a smooth game localization process, technical preparation is paramount. Key considerations that Denis mentioned include:

  • Ensure Unicode support in the engine
  • Centralize storage for language-specific assets
  • Implement unique string IDs
  • Avoid combining two separate text strings
  • Incorporate bidirectional text support in the engine
  • Opt for easily readable fonts
  • Enable scalable UI for longer translations
  • Implement game code for displaying text in images

Choosing the Right Language for Localization

Belka Games initially focused on English and major European languages such as French, German, Spanish, and Italian before expanding globally and supporting Simplified Chinese, Korean, and Japanese because these languages cover the largest and most profitable markets.

In addition to these prominent languages for game localization, Denis also recognizes the significance of aligning the budget with the value that the target market can bring.

Denis notices that localization efforts might go unnoticed if the region’s proficiency in English is high. He also recommends collaborating with App Store Optimization specialists to test translations in app stores, evaluating the performance of titles, descriptions, and screenshots to make informed decisions.

Build effective processes: Fewer people–more clarity

From Denis’ experience, try to involve as few employees as possible in the localization pipeline. Also, it is desirable to minimize the developer’s involvement in this process as much as possible, as they are among the company’s highest-paid and most efficient employees.

At Belka Games, a unified localization process has been implemented for all projects. The localization manager and QA handle most of the work in this process, while the developer only needs to perform one step: initial localization key pulling.

Run localization quality assurance (LQA)

Screenshots are a great reference, but they are not always enough, according to Denis. During the localization tests, native speakers can feel and experience the game. These people can find truncations, incorrect line breaks, and non-consistent terms.

Frequently asked questions

What are the biggest operational challenges mobile game studios face with localization?

The most persistent challenges are fragmented file exchange processes, insufficient access controls, and the difficulty of managing multiple localization kits simultaneously across a live game with frequent content updates. When localization is spread across a CAT tool, Excel files, Google Sheets, and Slack messages, teams lose track of which version of a string is current, where a specific key is stored, and which texts have already been translated. For a studio managing several game titles with separate localization kits for base content, bundles, and LiveOps, this fragmentation can make even a simple text correction a time-consuming, error-prone process that risks introducing inconsistencies across all files.

Why do Google Sheets and spreadsheet-based workflows fail for mobile game localization at scale?

Spreadsheets work well for small, stable localization projects but break down under the conditions typical of live mobile games — multiple titles, frequent content updates, external contractors, and parallel localization kits for different content types. Without the ability to restrict access by role, any team member with view access can accidentally edit strings. Without dependency tracking, a text change in one sheet has no connection to related strings in other sheets. Without a built-in glossary and translation memory, terminology consistency depends entirely on individual translators remembering past decisions. And without audit trails or structured key management, finding the source of a bug during LQA — when neither the manager nor the contractor knows which kit holds the relevant key — becomes a significant investigation rather than a quick fix.

How should a mobile game localization team be structured to minimize bottlenecks?

Based on Belka Games’ experience managing three mobile titles with one million daily users, the most efficient model keeps the localization team small and the developer’s direct involvement minimal. A team of three — a localization lead and two managers — can oversee a full pipeline of translation and QA when the tooling is right. Developers should ideally be responsible for only one step: initial localization key pulling. All subsequent work — translation assignment, QA, bug resolution, and contractor coordination — should be handled by the localization team without requiring developer input. This preserves developer time for engineering work while giving the localization team direct control over quality and pace.

How should mobile game studios decide which languages to prioritize for localization?

Start with the languages that cover the largest and most commercially valuable markets for your game’s genre. For most mobile games, this means English and the major European languages — French, German, Spanish, and Italian — as a first tier, followed by Simplified Chinese, Korean, and Japanese, which represent some of the highest-revenue mobile gaming markets globally. Before committing to additional languages beyond this core set, assess whether the target region’s English proficiency is high enough that localization would not meaningfully affect conversion or retention. Collaborating with App Store Optimization specialists to test localized app store listings — titles, descriptions, and screenshots — is a practical way to measure the incremental value of each language before investing in full in-game localization.

What technical preparations must be in place before mobile game localization begins?

Eight technical requirements establish the foundation for a scalable localization process. The game engine must support Unicode to handle all target language character sets correctly. Language-specific assets — fonts, audio files, images with embedded text — should be stored in a centralized, structured location. Every translatable string must have a unique string ID to enable reliable key-based import and export. Text strings that logically belong together should never be split across separate keys, as split strings lose context and create ambiguous translation units. The engine should support bidirectional text for RTL languages such as Arabic and Hebrew. Fonts should be chosen for legibility across all target scripts. UI elements should be designed with scalable layouts to accommodate text expansion in longer target languages. And the game code should support rendering translated text within image assets where text is embedded in visual elements.

How do branches help mobile game studios manage localization for live games?

Branches allow teams to separate localization work for different concurrent projects — a major content update, a seasonal event, and a bug fix batch, for example — without those workstreams interfering with each other or with the live production content. Without branches, all in-progress translations exist in the same workspace as QA-verified production strings, creating the risk that an in-progress or unverified string accidentally enters the production pull. A two-branch structure that Belka Games found effective separates draft translations from a production branch containing only QA-verified and disabled strings — with those final statuses locked to prevent accidental modification. This approach eliminates a class of release errors where a status change by any team member could cause unverified strings to be pulled into the build.

Why is access control critical in mobile game localization and how should permissions be structured?

When too many people can edit the same content, human error multiplies — a typo introduced by a project manager, a marketing stakeholder overwriting a finalized translation, or a contractor modifying strings outside their scope can all propagate errors that are difficult to trace after the fact. Role-based access control prevents these errors by ensuring each contributor sees and can edit only the content relevant to their function. At Belka Games, the permission structure assigns full access to developers, restricted access to QA specialists, and read-only or no access to business development, marketing, and project managers. Separating columns into role-specific views further reduces the cognitive load on each user and prevents accidental edits to columns outside their area of responsibility.

How should mobile game studios structure localization kits to avoid content fragmentation?

The root cause of most localization kit confusion is splitting related content across multiple files or sheets without a clear organizational logic and without tooling that maintains connections between them. The most reliable structure stores all content for a single game title in a unified database, with separate grids organized by content category — base UI, narrative dialogue, LiveOps content, in-app store copy — rather than creating entirely separate kits for each content type. Dividing content into multiple databases within a single project, rather than entirely separate projects, keeps everything discoverable and interconnected. A glossary established before any text is migrated into the new structure ensures terminology consistency from the first string, avoiding the compounding inconsistency problems that appear when glossary terms are added retroactively.

What does effective LQA look like for mobile games beyond automated checks?

Automated QA catches the rule-based errors — truncated text, missing tags, character limit violations — that a script can reliably detect. But it cannot replicate what a native speaker experiences when actually playing the game. LQA with native speakers surfaces the issues that automated checks miss: text that is grammatically correct but reads awkwardly in context, translations that are accurate in isolation but inconsistent with the tone of adjacent strings, line breaks that disrupt readability in ways that only become apparent in the rendered UI, and terminology choices that feel wrong to a player familiar with the genre’s conventions in their language. Screenshots are useful reference material but are not a substitute for in-game native-speaker testing — both are necessary in a mature mobile game LQA process.

What lessons from Belka Games’ transition apply to studios switching localization tools?

Five practices made the Belka Games transition significantly smoother than their first tool migration. Setting up the glossary and transferring all terminology before creating any grids or migrating strings prevents the situation where strings are translated before consistent terminology has been established in the new system. Establishing statuses for each stage in the localization pipeline from the beginning makes it immediately clear what stage every string is at without requiring anyone to ask. Creating separate translation memories for each game title prevents terminology and translation decisions from one game from contaminating suggestions for another. Deferring the integration of screenshot pulling from Unity until after the core migration is complete keeps the focus on the more critical and time-consuming work of moving strings and infrastructure. And choosing a tool whose interface is familiar to the team — in Belka Games’ case, a spreadsheet-like UI — dramatically shortens the adoption curve.

How does Gridly support mobile game localization workflows?

Gridly provides the centralized infrastructure that replaces the fragmented file exchange and spreadsheet workflows that cause the most common mobile game localization failures. A spreadsheet-like Grid interface keeps the learning curve low for teams already familiar with Google Sheets, while adding the capabilities that spreadsheets cannot provide: role-based access controls with view-level permission settings, branch creation for separating concurrent localization workstreams, built-in translation memory and glossary that enforce consistency automatically, and character limit monitoring accessible through dedicated views for UI and narrative designers. Screenshots can be captured with highlighted text and sent directly to Gridly for translator context. Machine translation and automated QA checks reduce the volume of manual work at each cycle. And API connectivity allows developers to perform their single required step — localization key pulling — programmatically, freeing the localization team to manage the rest of the pipeline independently.


Learn more about effective localization quality assurance

Denis and his team’s insights in platform selection, focus on localization features, and consideration of other key factors provide a solid foundation for success in mobile game localization. Initially, Denis’ team was inclined to revert to the previous approach, but now, the feedback is consistently positive. The thorough implementation of these factors has significantly simplified the localization process.

Interested in learning more about localization for your mobile game? Sign up for a 14-day free trial with Gridly today.

Localization tips & trends, delivered.

Get the latest posts in your email