1.4M Words, 4 Languages, 1 Month: Inside a run.loc Localization Success Story

What Was the Localization Challenge?

Have you heard of Blue Protocol: Star Resonance, continuing the legacy of the MMORPG Blue Protocol? An enormous fantasy world, hundreds of different quests in each area, and a handful of character classes with dozens of spectacular skills to fight enemies of all calibers, all wrapped in amazing art and available on PC and Mobile.

As you can guess, such a project brings with it a gigantic volume of text. By default, it’s written only in Chinese and English. Localization can come in handy to make sure more players around the world can embark on this immersive adventure.

But what if it’s November, the game has already become a hit in four western target markets, and you have a massive update release coming up? All the new languages need to be ready within three months, with the first results delivered by Christmas, so that player interest remains at its peak.

The volume is 1,400,000 words, and tackling localization would involve either a huge crew of linguists or raw AI output—but what about quality, testing, and, most of all, budget?

When we first spoke with A Plus about this case, classic localization and post-editing didn’t look like suitable solutions, neither in terms of pricing nor turnaround time.

Why Wasn’t Classic Localization the Best Fit?

Classic localization was too slow and expensive for the required volume and timeline.

For 1.4 million words, a traditional workflow would require large teams of linguists working in parallel. That would increase costs, extend turnaround time, and make consistency harder to control across languages.

We also considered standard post-editing, but it did not fully solve the problem. Reviewing AI output line by line would still take too long for the required deadline.

The main risks were:

The project needed a workflow faster than classic localization, more controlled than raw AI translation, and more targeted than standard post-editing.

And that’s where the combination of our run.loc process and good old LQA saved the day, allowing us to provide the localization quickly, ensure quality, and cut costs by more than half.

What Is run.loc, and How Does It Work?

It is a targeted post-editing workflow that prioritizes speed and precision. Instead of reviewing entire texts line by line, linguists jump directly to segments that are likely to contain errors.

These segments are identified through automated quality checks, allowing experts to focus their efforts where they matter most. The result? Faster turnaround times without compromising quality.

The run.loc workflow is built around five key steps, each combining automation with human expertise.

For a deeper dive into the methodology, explore our main run.loc article here.

How We Applied run.loc in the Project and the Challenges We Faced

At the very beginning of the project, our team faced a number of challenges that required immediate attention to stay on schedule and maintain high-quality localization. The main production challenges were:

The workflow had to remain flexible because the project changed while localization was already in progress.

How Did the Team Manage Scheduling and Communication?

First things first—to make sure the Allcorrect and A Plus teams stayed closely connected and addressed every issue proactively, we scheduled weekly sync-up calls.

As for the internal schedule, we also updated it together on a weekly basis, adding new linguists to handle the increased volumes and incorporating additional quality and consistency checks to keep up with the changing conditions. A major advantage was that the A Plus team entrusted us with all stages of the localization process, which gave us the flexibility to adapt quickly and implement solutions as new requirements arose.

How Did File Management Support Continuous Updates?

Our R&D team also developed a specialized tool that helped project managers save time by comparing different versions of the language pack, identifying changes in the source text, and uploading only the relevant translations back to the corresponding lines.

This helped project managers avoid unnecessary rework. Instead of manually checking every file version, the tool highlighted relevant source changes and helped upload only the necessary translations back to the correct lines.

This was especially important because live game localization often involves frequent file updates, small text changes, and shifting implementation requirements.

Better file comparison saved PM time and reduced the risk of missing or overwriting updated lines.

How Did Translation Quality Improve During the Project?

While early batches required more intensive human validation, as the translation memory was still being built, translation quality steadily improved with each new batch. Fewer issues were identified in quality scoring, the manual review workload for the linguists decreased, and the overall production cycle sped up. As a result, the process became increasingly predictable and efficient.

On a side note, as the project progressed, the team continuously added new references: they expanded the term base, incorporated additional style guide requirements following client feedback and issues spotted in LQA reports, and propagated gender and speaker information provided by the development team at a later stage into each line.

This led to improved consistency in terminology, a more accurate tone and style, and fewer corrections during the human validation of quality reports. With each new batch, the run.loc smart engine became better at understanding context, directly enhancing the final quality.

What LQA Results Did the Project Achieve?

By the final stage of the project, the efficiency of the run.loc workflow was clearly reflected in the results. The team completed LQA for the most important and sensitive content, and the outcome proved highly impressive. On average, testers reported between 1 and 3 linguistic and graphical issues per 1,000 words, depending on the language. This level of quality is considered excellent even for a traditional, fully human-driven localization approach.

Here’s the overall statistics breakdown:

Overall, run.loc not only accelerated the process but also delivered consistently high-quality results, demonstrating its effectiveness as a scalable solution for complex localization projects.

How Did run.loc Compare with Classic Localization and Post-Editing?

When we first looked at the A Plus case, our team decided to approach it from different angles, estimating different localization setups. Here’s what we got:

A side note from localization pros: handling consistency of the text when 1 team has 10 linguists is already quite a challenge, and involving more would bring very unexpected results—that’s why we set the limit of 10 linguists per team here.

To complete the whole pipeline picture, here’s the estimation of LQA for the most critical parts of the game:

This setup helped ensure a smooth release of Blue Protocol for the new locales with solid language quality without overextended timelines, and saving more than half of the budget.

LQA complemented run.loc by checking how localization worked inside the game, not only in CAT tools.

What Business Result Did run.loc Deliver?

A large-scale localization project, 1.4 million words, four target languages, tight deadlines, continuous updates, and no room for compromise on quality. A setup like this could have easily turned into a race against time, budget, and consistency. But with run.loc and a focused LQA approach, it became a well-structured and efficient process.

In just one month, with smaller teams and a budget cut by more than half compared to classic localization, we delivered solid results for a massive live game project. As the workflow evolved, quality improved from batch to batch, the run.loc smart engine became more context-aware, and human efforts became more targeted and effective. And when it came to final checks, the numbers spoke for themselves: excellent LQA results, low bug counts, and release-ready localization that proved speed and quality can absolutely go hand in hand.

The run.loc smart engine helped deliver a large-scale localization project—1.4 million words—in just one month, with smaller teams and a budget cut by more than half.

For the client, this meant faster readiness for new locales, controlled localization quality, and a more scalable process for future updates.

“A million-word localization project across multiple languages in just one month was probably one of the tightest schedules I’ve worked on. Normally, you’d have to either cut corners on quality or delay the release.
What helped was having a team that could keep up with the pace. We managed to deliver all languages on time, and by the end of the project we also had a much clearer process for asset management and future localization updates.”

—Kayla Zhang, Localization Manager at A PLUS JAPAN

What Did the Team Learn from This Project?

The project showed that large-scale localization with automation needs strong process ownership, not just technology.

A combination of pre-translation with preparation, terminology management, targeted human validation, file engineering, PM coordination, and LQA enabled run.loc to work.

“The hardest part was not the volume itself, but keeping every update synchronized across all languages. Once we implemented lockit version comparison and finalized the requirements after the initial feedback, the workflow became much more predictable.”

—Victoria Belyaeva, Team Lead

The team also learned that quality improves faster when LQA feedback is fed back into the production pipeline instead of being treated as a final separate step.

The biggest lesson was that run.loc succeeds when every production stage feeds into the next one.

It’s no exaggeration to say a project of this scale was quite a journey for the team—huge batches, multiple languages, enormous teams for each, and tight timelines. We learned much, we improved much, we proved much. And we’re ready for more!