The 82% Market You're Ignoring: A Game Localization Playbook
How to unlock the vast majority of global players, drive organic growth, and avoid common pitfalls—with insights from Alkonost CEO Alexander Murauski
Most game developers are leaving money on the table—lots of it. Only 18% of the world speaks English, which means if your game is English-only, you’re missing 4 out of 5 potential players.
I recently sat down with Alexander Murauski, CEO of Alconost, a localization company that’s been helping game studios go global for over 15 years. Alex shared insights from localizing hundreds of games and revealed why most studios are doing localization completely wrong.
Key Takeaways:
Start localization on Day 1, not as an afterthought - Building with 2 languages from the beginning solves 80% of future localization headaches
The “Base 10” languages cover 80% of the world’s population - Chinese, Spanish, English, Hindi, Portuguese, French, Arabic, Japanese, German, and Russian
AI reduces localization costs by ~30%, not 90% - Human review is still critical for quality
Localization without marketing presence is wasted money - You need more than just translated text to succeed in new markets
Use a proper localization platform from the start - Google Sheets breaks down after 10,000 lines and creates versioning nightmares
🎧 Listen on Spotify, Apple Podcasts, or Anchor
Speakers:
Joseph Kim. CEO at Lila Games.
Alexander Murauski. CEO at Alconost.
The Economics of Going Global
Why Localization Is Your Best Growth Hack
Alexander opened with a compelling Mr. Beast case study. By simply adding subtitles and voiceovers to his YouTube videos in multiple languages, the creator massively expanded his global audience. The same principle applies to games, but the impact is even more dramatic.
Consider these market realities:
App Store visibility: Apple and Google won’t feature your game in local stores without localization. No Japanese translation? No Japanese App Store featuring. Period.
Market expectations: In Korea, Japan, and China, 90% of users simply won’t accept non-localized products
Organic growth multiplier: Localized games see significantly higher organic downloads from app stores
The math is simple: translating into Spanish alone gives you access to 550 million speakers. Chinese opens up over 1 billion potential players. Hindi adds another 600 million. These aren’t just numbers—they’re untapped revenue streams.
Choosing Your Target Languages: Strategy Over Spray-and-Pray
The Two Approaches to Language Selection
Alexander outlined two distinct strategies for choosing which languages to localize:
1. The Sophisticated Approach (for funded studios):
Analyze unit economics for each market
Use tools like App Magic or Sensor Tower to study similar games’ performance by country
Calculate customer acquisition costs vs. ARPU by region
Consider marketing capabilities and local presence
Test markets with cheap auto-translations first, then invest in quality if ROI is positive
2. The “Base 10” Approach (for indies and smaller studios): Start with these language groups that haven’t changed in 20 years:
FIGS: French, Italian, German, Spanish (covers Europe)
CJK: Chinese, Japanese, Korean (covers Asia’s premium markets)
Additional high-impact languages: Portuguese, Arabic, Hindi, Russian
The Hidden Cost Factor Most Studios Miss
Here’s what Alex emphasized that most studios overlook: localization alone won’t guarantee success. You need:
Customer support in that language
Community management capabilities
Marketing presence (or at least partnerships)
Understanding of local payment methods and pricing
Without these elements, even perfect localization might not deliver ROI. As Alex noted, “Japan is a high-paying country, but advertising there is very expensive. Indonesia has lower ARPU but much cheaper advertising costs. Sometimes Indonesia is the better choice.”
The Technical Foundation: Start Right or Pay Later
Day One Localization: The Game-Changer
Alex’s most emphatic advice: “Localization should be started on day one.”
Starting with two languages (even if one is just a test language) from day one forces you to:
Build proper internationalization into your architecture
Implement language switching from the start
Extract strings into separate files instead of hard-coding
Consider currency and payment processor variations
Think about font support for different character sets
This approach solves what Alex estimates as “80% of your future localization challenges” before they become expensive problems.
Common Technical Pitfalls to Avoid
The Font Trap: Western developers using custom pixel fonts often discover they don’t support Japanese/Chinese characters. Asian developers face the reverse problem when localizing to Latin-based languages.
The German Problem: German text is typically 30% longer than English. Fixed-width UI elements that look perfect in English overflow catastrophically in German.
The Arabic Curveball: Right-to-left languages don’t just reverse text—they flip entire UI layouts. In Arabic Windows, the Start button is on the right.
The Context Crisis: “Cancel” can mean vastly different things depending on where it appears. Without context, translators guess wrong, breaking user experience.
Implementation: Tools and Workflows That Scale
Why Spreadsheets Are a Trap
Many studios start with Google Sheets or Excel for localization. According to Alex, this breaks down fast:
Performance degrades after 10,000 lines
No version control for multiple translators
Zero context for where strings appear
No structure for managing glossaries
Manual processes that don’t scale
The Professional Stack
Instead, Alex recommends using proper localization platforms from the start:
Key Features to Look For:
Git integration for automatic syncing
Context screenshots for translators
Translation memory to ensure consistency
Glossary management
Support for continuous delivery
Multiple file format support
Recommended Platforms:
Crowdin (Alex’s primary choice)
Lokalise
Phrase
Smartcat
These platforms typically integrate with your build pipeline, enabling true continuous localization where translators can work in parallel with development.
The AI Revolution in Localization
How AI Actually Works in Practice
Studios are increasingly asking about AI translation, but Alex reveals the reality is more nuanced than “just use ChatGPT”:
What Works:
AI can reduce costs by approximately 30% (not 90% as some expect)
Different AI models excel at different languages (Mistral for French, DeepSeek for Chinese, DeepL for Polish)
AI + human review delivers the best cost/quality ratio
What Doesn’t Work:
Raw AI without human review (inconsistent terminology, hallucinations)
Generic prompting without glossaries (key terms translated differently each time)
Expecting AI to handle sensitive content (many models refuse war/violence terminology)
Large glossaries that exceed context windows
The Optimal AI Workflow
Alex’s agency offers three tiers:
Premium: Human translator + human editor
Hybrid: AI translation + human post-editing (30% cost reduction)
Raw: Unedited machine translation (only for user-generated content)
The key insight: agencies like Alconost add value by knowing which AI to use for each language pair and content type, managing the technical pipeline, and taking responsibility for quality.
Working with Localization Partners
When to Use an Agency vs. Going Solo
Community/Crowdsourcing (like Minecraft):
Pro: Free
Con: Rarely achieves 100% completion, requires heavy management
Direct Freelancer Hiring:
Pro: Direct control
Con: Quality assessment challenges, heavy management overhead
Agency Partnership:
Pro: Managed service, quality guarantees, established workflows
Con: Higher cost than DIY
Evaluating Localization Agencies
Alex’s criteria for choosing a good agency:
Transparency: They should share translator credentials and create shared communication channels (like Slack) between your team and theirs.
Quality Verification: Request test translations and have native speakers on your team evaluate them if possible.
Technical Capability: They should guide you away from spreadsheets toward professional platforms and continuous delivery.
Long-term Thinking: The best agencies assign dedicated translators who stay with your game for years, becoming domain experts.
The Bottom Line: A 15-Year Case Study
Alex shared his favorite client story: a farm simulator that’s been running for 15 years. They started small with just two languages, gradually expanded to exotic markets, and now have translators who’ve been with the game for over a decade. These translators aren’t just vendors—they’re extensions of the development team who know the game inside out.
The lesson? Localization isn’t a one-time checkbox. It’s an ongoing investment in global growth that compounds over time. Start early, use the right tools, and build localization into your development DNA rather than treating it as an afterthought.
As Alex puts it: “Localization gives you scale.” In a world where 82% of potential players can’t access English-only games, can you afford not to localize?
Want to learn more about game localization? Connect with Alexander Murauski on LinkedIn or email him at am@alkonost.com
Discussion Transcript
**Joseph Kim** *00:00:06*
Hi, Alex, and welcome. I’m glad to have you here. Today we’re going to be talking about game localization, a topic that many people probably put off for too long.
I wanted to start with an interview I saw with Mr. Beast, where he talked about the massive impact localizing his YouTube channels into different languages had on his growth and success. That brings us to the economic impact of localization. In today’s climate of efficiency and ROI, people want to know what that impact looks like.
Could you characterize how you think about it? For game developers, what does localizing into one or several languages really mean for the bottom line?
**Alex Murauski** *00:01:02*
That’s a great question. I’m familiar with the Mr. Beast case because my kids are big fans. They used to watch him in their native language, and now they watch him in English. What he did was brilliant. By subtitling and adding voiceovers to his video clips, he gained a huge audience.
If you look at the numbers, only 18% of the world’s population speaks English. This means four out of five people won’t use a game or watch a video if it’s only in English. In countries like Korea, Japan, and China, 90% of people will not accept products that aren’t localized. They find it uncomfortable and simply don’t understand it.
By localizing, you gain access to a much larger audience of players around the world. For example, translating into Spanish gives you access to 550 million speakers, which is more than the population of the United States.
The Chinese language gives you access to more than 1 billion people, and Hindi adds another 600 million potential players who can buy your product. That is the economic effect of localization.
Some game developers see localization as a growth hack because it drives more traffic from the app stores. If you want to get more organic players from the App Store, Google Play, or Steam, you need to localize. The App Store, for instance, won’t feature you in a local store if your game isn’t localized for that region. They check if your game is localized into Japanese, and if it’s not, you won’t be accepted. You simply can’t enter that market. Not localizing limits your organic opportunity to attract more users.
For smaller games and apps, it’s not that expensive to localize into the top 10 languages, which cover 80% of the world’s population. If you localize into Chinese, Spanish, English, Hindi, Portuguese, French, Arabic, Japanese, German, and Russian, you cover a vast majority of the people on Earth.
It’s worth localizing at least the initial user-facing elements, like the game description, screenshots, and the first few levels. Localization gives you scale.
**Joseph Kim** *00:05:10*
So, you view localization primarily as a way to broaden reach, which in turn broadens the audience that can monetize in your game. You mentioned a few key languages that can dramatically expand reach beyond the 18% of English speakers.
How do you and your clients typically decide which languages to prioritize? What kind of analysis goes into that decision, and where do you draw the line between adding a few languages versus fifteen?
**Alex Murauski** *00:06:10*
Simply localizing isn’t enough to be successful in a new region. It really starts with your marketing capabilities. For example, if you want to localize for Japan, even with a successful game, you need customer and community support. Without that, localization won’t be very effective.
The first thing to consider is how you will drive traffic to your game in that new market. If the cost of player acquisition is too high, localization might not provide a positive return on investment. Sometimes it’s better to localize for Indonesia instead of Japan. Japan is a high-paying country, but advertising there is very expensive. In Indonesia, you have a large population that may pay less per user, but the advertising costs are much lower.
The language selection comes after you determine what’s possible from a marketing perspective. The ideal scenario is to first plan your promotion and marketing, and then localize. If you already have a presence in Japan or Korea—marketing people, advertising opportunities, local partners—then localization becomes a clear necessity.
A more basic scenario is to translate into the top 10 languages. For Europe, this is often abbreviated as FIGS: French, Italian, German, and Spanish. Then there’s CJK: Chinese, Japanese, and Korean. You can also add languages like Arabic, which covers a large population but requires extra development work for its right-to-left layout.
So the decision comes down to two things: your marketing capabilities in a given region, and then selecting the most popular languages among internet users. You can also look at the GDP of different countries to assess their paying potential.
**Joseph Kim** *00:09:55*
Alex, let me pause you for a second. There’s a bit to unpack in your comments.
First, it’s important for our audience to understand that localization isn’t just in-game. You’re talking about all the localization touchpoints. There’s the in-game content, but also the app description for the App Store, marketing materials, and community channels like Discord or your website. The first point is that developers need to consider multiple localization touchpoints.
Second, regarding the original question about how to decide which languages to localize for, I heard two things. First, you mentioned understanding the attractiveness of a region. For example, even if Japan has an extremely high ARPU, you need to consider the potential ROI.
Personally, when I look at attractive geographies, I use a service like App Magic to check the data for similar games. I’ll do a country-by-country split and analyze those markets. You mentioned just going with the “base 10 languages.” Do you recommend that to your clients as a default, or do you suggest they do an analysis like mine, looking at data from similar games to determine the attractiveness of specific countries?
**Alex Murauski** *00:12:03*
Regarding those 10 languages, that advice has been around for 20 years. Nothing has changed. Every game localizer would say to just go with those 10 languages for maximum impact.
However, if you’re a sophisticated game developer who cares about unit economics, or if you have investors looking for a return on marketing and advertising investment, you need to assess conversion across different channels. In that case, you would use services like App Magic or, for games and app stores, Sensor Tower, App Annie, or Similarweb.
You dig into the numbers. But that’s really the task of a chief financial officer, not an indie game developer.
**Joseph Kim** *00:13:11*
There’s one other point I wanted to bring up. You suggested that before localizing, you should also consider the required investment beyond just translation. You mentioned needing a marketing team in India for Hindi, or in Japan for Japanese.
So if you do localize for one of these countries, what do you recommend in terms of an on-the-ground presence for marketing or localization?
**Alex Murauski** *00:14:02*
I would definitely recommend having people responsible for marketing in each region. That’s a must.
This applies to larger studios. When they ship their game, they need to work with influencers and handle advertising in different markets. This requires a large marketing department or a dedicated marketing agency.
For small indie developers, the resources and opportunities are very limited. They can usually only publish their game on Steam, select all the languages Steam supports, and provide localized content like screenshots and game descriptions. That’s pretty much everything available to them. They just spray and pray.
**Joseph Kim** *00:15:24*
That sounds like most of the games industry.
**Alex Murauski** *00:15:30*
Yes. We work with many different game development studios, and 90% of them take the “localize to every language we can” approach to cover everything, everywhere. Sometimes it works, because people on the app store download more and it pays off.
But some companies are driven by finance, investors, and return on marketing investment. They test the waters first. For example, to test a market like Indonesia, they might auto-translate some content with Google or ChatGPT and publish it. If they see a positive return on investment, they will then redo the translation with higher quality.
They might also add a representative for community support or do more to get local coverage and influencers to stream the game. They start by stepping on very thin ice, testing the waters by localizing just a few assets to see what happens.
There are also A/B testing platforms like SplitMetrics. You can test how downloads or installs are affected by having a localized store page versus a non-localized one. Before you invest in full game localization, you can invest a small amount in this kind of testing to see how it might work.
**Joseph Kim** *00:17:46*
I would consider myself not deep enough on the topic of localization, and it seems there’s more to it than I had originally considered. I’d like to ask you a few more questions about that.
I can tell you how we’re doing it, which is probably not ideal. We tend to delay localization until the back end of the development cycle. After focusing on all the core game development issues, we integrate localization towards the end. It’s not quite an afterthought, but it’s close.
As an expert who knows the best practices, what is the best timing and process to maximize efficiency and reduce time and cost, instead of treating it as a last-minute task before launch?
**Alex Murauski** *00:19:06*
Yes. This is my best advice for any developer, whether it’s a game, an app, or a website: localization should be started on day one.
**Joseph Kim** *00:19:22*
Okay.
**Alex Murauski** *00:19:23*
If you have any ambition of localizing your game—whether into two, three, or even 30 languages—you should start with two languages from day one. One of them can even be your second language or an artificial one.
Starting with two languages immediately forces your game to be technically internationalized and ready for 20 languages, not just two. It compels you to think about how languages will be switched, so you implement a language switcher. You learn to use the right SDKs and avoid hard-coding strings into the code, instead extracting them into separate files. Supporting two files in parallel is manageable.
This process establishes good development hygiene from the very beginning. You learn to live with localization from day one, considering things like date, time, and number formatting. The SDKs and the programming language you’re using will have internationalization guidelines to help you. You’ll also think ahead about currencies and implementing different payment processors for various markets.
You’ll also have to think about fonts, which can be tricky. A common mistake occurs when a game is developed by Japanese or Chinese developers who use hieroglyphs. The fonts that support them are larger than those used in the Latin-based world. But the real problem arises when a Western developer tries to localize their game into Japanese. They may have a custom, immersive pixel font that only contains Latin letters. When they switch to Japanese, the font doesn’t support the vast number of new symbols. It’s rare for a custom font to support everything.
Another example is localizing to Arabic, where the layout is right-to-left. In an Arabic version of Windows, the “Start” button is on the right, not the left. Just being aware of these issues from the start, by working with two languages, solves 80% of your future localization challenges.
Adding more languages later becomes as simple as adding more files to your localizable assets folder. At that point, managing even two languages manually will start to feel tedious. Adding a single line of dialogue means inserting text into two separate files. This annoyance will naturally lead you, as an engineer, to a solution like a localization platform.
A localization platform integrates with your GitHub repository, takes your source language resource file, and allows it to be duplicated and translated into any number of languages automatically. It merges all the changes for you. You only have to work on the source file in GitHub; you make a commit, and you get a pull request from the localization platform with all the translations. The pain of managing localization is gone. It just works.
If you set up continuous delivery and nightly builds, you can integrate localization directly into your build pipeline. Your game gets localized almost automatically. With machine translation, it can be instantly localized into any number of languages. If you add human translators, they can work on the localization platform and have your updates translated by the next day. You get your localized build in almost no time.
This is how it should work. You don’t postpone localization; you make it continuous. My best advice is to start with two languages, and this will resolve almost everything else.
**Joseph Kim** *00:26:24*
So, your argument is that it’s better to think about localization from day one from the perspective of scalability. If you consider it from the beginning, you don’t have to go back and refactor code or redo art assets later.
For instance, you shouldn’t bake text into images, and you have to consider how language will be presented in the UI. Thinking ahead makes the entire process much more scalable and easier to manage in the future.
You mentioned fonts, and I remember one of the biggest UI problems for us in the past was German. We had a fixed amount of space, and the German text would always overflow.
Besides not planning for scalability from the beginning, what are some other common problems and mistakes you’ve seen when meeting with different studios? What can we avoid?
**Alex Murauski** *00:28:06*
There are two types of errors: technical and translation. A technical error, for instance, is when German text overflows because it doesn’t fit the size of a button. This can usually be fixed by the developers themselves, as they can see that something is visually wrong without needing to know German. No language proficiency is required for that kind of QA.
The trickiest mistakes in localization come from mistranslations, which often happen when a translation is done without context. For example, a button captioned “cancel” can be translated in many different ways and have different meanings depending on the language and context. Is it a verb, or are you confirming a cancellation? Without context, a translator can easily get it wrong.
The best way to solve this is by structuring the resources for translation. Instead of just an Excel file with strings, you could use a structured format like a JSON file. The structure could be something like: game screen one, save dialog, save button, with the caption “Save.” This structure provides context for the string. It tells both the translator and the developer that this specific “Save” is used here and not somewhere else in the project.
Another solution is providing screenshots. Some localization platforms can automatically find screenshots that match the strings being translated using AI or machine vision. This allows the translator to see the context, because while they always play the game, a universe can be too big to navigate to every single screen. We hunt for these mistranslations during the quality assurance stage, after the game is localized and we have a test build.
Finally, term consistency is critical. If characters in the game have names and reference each other, those names must be translated consistently, or it breaks everything. The same goes for artifacts or location names. If you have an axe that is later referred to as a hammer, it creates confusion.
This is why having a glossary—a book of every term and item description in the game—is a must. It helps ensure consistency throughout the story. The glossary and a style guide are common practice, and when we start localizing a game, the first thing we require from a client is to build a glossary. If they don’t have one, we build it for them.
**Joseph Kim** *00:33:11*
You mentioned a glossary and a style guide. I understand what a glossary is, but how does a style guide differ?
**Alex Murauski** *00:33:21*
A style guide provides context for the translator by describing the game itself. For example, it might specify how to address the player—formally or informally. This is very important in languages that have different forms of “you.”
The style guide also covers things like translating humor. Should it be recreated for the new culture, or translated literally with a reference? It provides context about the game that isn’t found in the text itself.
**Joseph Kim** *00:34:31*
Shifting to practical implementation, I see many small game studios use an Excel or Google spreadsheet. They’ll have English in column A, Spanish in column B, Japanese in column C, and so on.
You’ve identified several common problems with this approach. First, you mentioned a lack of structure and suggested a JSON file might be better to show where the text actually goes. Second, you talked about context. It would be helpful to see a screenshot of where a specific text string is used. And third, you mentioned the context of style, like whether the tone should be formal or informal.
With those points in mind, what is the best practical implementation? How can smaller studios avoid the common problems of the Google Sheet approach, and what is a better alternative?
**Alex Murauski** *00:36:44*
Google Sheets is a convenient and obvious way to manage localization. You can have tabs or columns for different languages. However, the main problem is performance. When a spreadsheet has more than 10,000 lines in one language, it can become very slow or even fail to open.
They are also easy to damage. If someone deletes something, it can cause problems, and while there is version history, sharing it with multiple translators risks corruption. For a very small project at the beginning, it might work. But the bigger issue is that every professional localization platform requires a key.
**Joseph Kim** *00:38:00*
What do you mean by “the key”?
**Alex Murauski** *00:38:02*
The common standard for localization resources is to store them as key-value pairs. The key is the name of the string, and the value is the string itself.
**Alex Murauski** *00:38:15*
Using key-value pairs is a common and structured approach. If you have a key, you already have some structure. For instance, you can use dots within a key to provide context that a plain string in a spreadsheet lacks. With a key, the developer knows the context of the string.
In a spreadsheet with no keys, the developer doesn’t know where that line of text appears in the code. This is unmanageable, though it might be okay for a very small game.
There’s also a terrible format: PO files, which are often used for website translation. In PO files, the source text itself acts as the key. This means if you fix a simple typo in the source text, the key changes, and all of your existing translations for that string disappear because the app can no longer find them.
Using spreadsheets can be convenient for calculating translation volume or sharing with freelance translators, but it only works for a very small amount of text. For any real project, your files must have a key-value structure. The best approach is to use a localization platform that organizes all your files in one place, so you don’t have to manage them manually.
**Joseph Kim** *00:40:13*
What is an example of a localization platform?
**Alex Murauski** *00:40:17*
There are plenty of them on the market. Some of the best are Crowdin and Tolg. There’s also Phrase and Smartcat. A simple Google search for “localization platform” will give you many options. We mostly use Crowdin in our work.
What developers like about these platforms is that they support every file format. You can even use your spreadsheets, but the spreadsheet just becomes a container for your localized resources. The actual localization work happens on the platform itself. The platform provides tools like a glossary, style guide, translation memory—which is very important—and integrations with various machine translation engines and modern LLMs. A localization platform allows you to organize your localization pipeline properly.
This leads to my second piece of advice: if you’re localizing for even two languages, use a localization platform from the very beginning. It doesn’t cost a fortune, but it organizes the process and makes it professional. We use Git repositories to store our code and professional IDEs to develop. We should use professional tools for localization as well, rather than just manually tossing strings into spreadsheets.
**Joseph Kim** *00:42:22*
Got it. Localization isn’t something a typical game studio does on a continuous basis, so working with a partner vendor like yours makes sense.
When choosing a partner, how should game studios evaluate different localization vendors? What metrics—like cost, turnaround time, or quality—should they consider when looking at a company like yours?
**Alex Murauski** *00:43:13*
Game development companies have several options for localization. The first thing developers often consider is hiring freelancers to do the job for free. This typically involves crowdsourcing, where members of a game’s community volunteer to translate in exchange for being credited. Minecraft is a famous example, with 80% of its translation done by the community. This is often the first approach indie developers consider.
However, community translation has its limits. Translation is real work, and for a large game, it’s unlikely that volunteers will complete 100% of the project without payment. The enthusiasm often isn’t enough to cover everything. This approach also requires management, including an editor and tools for managing glossaries and translation memory. It’s a tricky process, though some games are successfully translated this way.
The next option is to hire and pay freelance translators directly. This requires a localization manager on the developer’s team, a role that might be filled by a marketing manager, a content manager, or even one of the developers. The challenge here is finding reliable, cost-effective translators who deliver high-quality work. It’s also difficult to assess quality if you don’t speak the target language, so you might not discover a poor translation until users complain.
The best option is to work with a localization agency that handles everything. An agency has a pool of experienced game translators for dozens of languages, all with a proven track record.
When choosing an agency, I recommend prioritizing transparency. A good agency will tell you who the translators are, perhaps by providing blind CVs or their names. This makes the linguist part of your team, ensuring consistency for years to come. We have cases where the same translator has worked on a game for a decade. They know the game inside and out and work as needed, whether it’s one hour a week or one hour a month.
The agency provides both the pool of translators and the localization platform. If you don’t have a platform, the agency will recommend one and help you build the right process around it. You also get a dedicated localization manager at the agency who serves as your single point of contact. This person takes full responsibility for the project, which is crucial because it frees up the game developer’s internal resources.
So, how do you choose the right agency? First, as I said, look for transparency. They should be willing to share information about their translators. We often create shared Slack channels with clients, linguists, and project managers to speed up communication and problem-solving.
Second, ask for a test translation. This is especially useful if you have someone in-house or a loyal user who can assess the quality. Many companies come to us with 20 languages and no prior relationship, so a test translation is a great way to build trust and ensure quality. Translation style can be preferential, so we allow clients to choose from different linguists to find the best fit. If a game studio has a native speaker, like a community manager, they can assess these test translations and help build the perfect team for their project.
A good agency already has these teams ready. The key is that it shouldn’t be a black box. It must be transparent and technically equipped to support you.
**Joseph Kim** *00:50:53*
Can you give me an example of what it means for an agency to be “technically equipped?”
**Alex Murauski** *00:51:00*
For example, if you come to an agency with only a spreadsheet, they should advise you to use a proper localization platform. Even if your internal infrastructure is built around spreadsheets, the translation work itself should happen on a professional platform, which they can often provide.
This professionalizes the entire process. The platform manages glossaries, translation memories, and automated quality assurance checks. It enables structured pipelines, such as having one person translate and a second approve, or having a machine translate followed by human approval.
It’s impossible to manage this level of professional work by simply sharing spreadsheets among 20 people. That’s what I mean by being technically equipped.
**Joseph Kim** *00:52:15*
Okay, let me summarize what I understood. Your first point is that developers have several options. One is free, crowdsourced translation, but not every game has the popularity of Minecraft to make that work. A second option is hiring freelancers, but that comes with significant management overhead, variable quality, and a lack of awareness of best practices.
When it comes to choosing an agency, you recommend evaluating them on a few key criteria. The first is transparency—getting high visibility into who the translators are and what the communication processes look like.
Second is quality, which can be verified by requesting a test translation. This ensures the agency can meet your quality expectations.
Third is technical support—ensuring the agency has the right tools and infrastructure to handle localization professionally. Did I miss anything, or is that a good characterization of your points?
**Alex Murauski** *00:53:46*
On the technical side, the continuous delivery cycle is very important. The real pain starts when just two new lines are introduced into the game, and the agency needs to be able to translate them by the next day. Two lines in 20 languages means 20 people will be involved. Without a localization platform and proper management, this small change can break the entire communication and delivery pipeline. This is why continuous support is crucial.
Another important thing is quality assurance. There are several quality gates, starting with automated checks on the translated content. Then, a second linguist reviews the materials. Finally, there is localization quality testing, where linguists test the game in their regions, with their language enabled, to check all the screens and report issues. A quality localization agency will always discuss the full localization cycle, including testing.
**Joseph Kim** *00:55:52*
I have a few follow-up questions. We’ve been talking about in-game localization, but you also mentioned other touchpoints. It isn’t just in-game content; you have creative assets for marketing, community content, and ASO app store descriptions.
For your customers, how much of your business is in-game versus those other assets? And what do you generally do for those other localization touchpoints?
**Alex Murauski** *00:56:37*
For game development, 99% of our work is localizing in-game content. The best clients are games that live for 10 or 15 years and have seasonal events, like Halloween or New Year’s parties, to keep the content fresh.
When we work with apps or SaaS businesses, it can be more complicated. We handle both product and product marketing localization. This means translating the product itself, as well as related materials like help systems, reference guides, blog posts, advertising materials, and case studies.
This is rare for games, however. For games, the non-game content is usually part of the user journey. Developers typically have a small website or a simple landing page that’s easy to translate. It’s mostly app store descriptions, and that’s about it.
Influencer streaming is generally not localized, though some creators are starting to use AI for that. Overall, the user journey content outside of the game itself is very limited.
**Joseph Kim** *00:59:24*
I have one more follow-up question regarding the different localization solutions, and I think this will lead us into a bigger discussion about AI. You mentioned a few options. Crowdsourcing for free is rare. Some studios use freelancers. Many studios use agencies.
But an increasingly popular option, especially for smaller studios, seems to be AI. For example, you could have a spreadsheet with English text and use a service like ChatGPT or Claude to fill in the translations for other languages.
Can you talk about the use of AI in localization? Do you use AI? And what would you say to a studio that thinks they can just handle it all with AI instead of an agency?
**Alex Murauski** *01:00:54*
That’s a very good question. We definitely use AI. And AI isn’t just for small indie developers; the big studios with huge amounts of content are also using it.
In fact, they’re the most interested because they have the resources to choose between different LLMs and train them to produce better translations for their specific content. The biggest developers are the most interested because they have large budgets they want to cut.
**Alex Murauski** *01:01:48*
Clients were the first to come to us and ask if we could translate everything with ChatGPT. It seemed like it might work, but not in the way they imagined.
How it really works now is that you can translate with ChatGPT directly within a localization platform. You turn on automated translation, and you’ll get your output from ChatGPT, Claude, Gemini, or any other LLM, as they are all supported. It will translate well for some languages, but there are some tricks.
Not every LLM translates well into every language. For French, Mistral performs better. For Chinese, DeepSE is obviously superior. For most European languages, ChatGPT is okay, but for Polish, DeepL is still the best, even though it’s a traditional translation engine and not an LLM.
Selecting the proper engine is a key part of our service. Knowing the client’s content type and language pairs allows us to choose the best AI for the job. But AI doesn’t produce 100% quality on its own. It must be prompted properly, and the glossary, style guide, and a human reviewer are all critical. The reviewer checks all the translations. You could use basic machine translation, but then no one is responsible for the outcome. As an agency, we are responsible for the quality, so we must have that human check.
We negotiate with the client, explaining which AI is best for their specific content and language pair, and show them the test metrics to back it up. We agree to use AI with a human reviewer, which results in a price that is about 30% less. It’s not 90% or 100% less, because the reviewer is still reading and editing, which is not a huge time difference from translating from scratch. Even in the past, with translation memory, a human still had to review every text chunk to give it a seal of quality. What we sell is responsibility and quality. We guarantee our localization is good, and the client is paying for that insurance.
We are transparent about using AI when we negotiate. When a client asks for a price, we usually present three options. The first is a professional human linguist, plus another editor for review, depending on the budget. The second option is Machine Translation Post-Editing (MTPE). We agree to use a specific machine translation engine plus a human reviewer to cut costs for certain languages.
The third option is raw, unedited machine translation. This is only suitable if the client has the right content type for it, such as user-generated content in a chat or Airbnb comments. Nobody reviews those with a human; they are just machine-translated. The client chooses from these three options and always knows if we are using machine translation.
Some game developers rely 100% on ChatGPT and program translations through the OpenAI API. We were initially very afraid of this scenario as a business, but we’ve seen that it’s hard to automate translation effectively. You get unpredictable results.
Without a glossary, your translations will be inconsistent, with the same word translated in different ways depending on the LLM’s creativity settings. The models also hallucinate, inventing things that aren’t in the original text. Fixing this costs money. If you have a large glossary, it won’t fit into the LLM’s context window. You have to implement a system to retrieve parts of the glossary and insert them into the prompt. Furthermore, if you need to translate sensitive terminology about war, bombs, or chemicals, ChatGPT is often prohibited from discussing those topics and will refuse to provide a translation.
**Joseph Kim** *01:10:02*
Let me recap. It sounds like while some game studios use AI directly, the advantage of working with an agency like yours is that you also leverage AI, but you know which models are best and how to optimize them. You pass those cost savings—around 30%—on to your customers.
The value you add is in quality control, since AI isn’t perfect and can hallucinate. You also provide best practices and ensure the AI is used optimally. Is that a fair characterization?
**Alex Murauski** *01:10:54*
Yes. You get quality assurance for the localization, testing of the localized game build, and the technical setup, which includes choosing the right model.
You don’t have to write code to use LLMs for translation. You can’t just copy and paste a large JSON file into the ChatGPT window—it will get corrupted, and doing it for 20 languages is tedious manual work. The alternative is using the API, which requires development. You would essentially be reinventing the wheel. A localization provider handles all of this, and that platform access is basically free.
**Joseph Kim** *01:12:19*
To help our audience understand what it’s like to work with an agency, could you walk us through a case study? Please take us end-to-end, from the very start of a client engagement to the finish. What does that process look like?
**Alex Murauski** *01:12:48*
Every client is different. Let’s talk about one of my favorite clients, a studio that has been with us for over 15 years.
They started very small with a farm simulator game. You plant seeds, gather fruit, make juice, and sell it to grow your economy. It’s an evergreen game with characters that has kept users returning daily for 15 years.
They started with two languages for the US market, and it was a hit. At the time, it was a web-only game. We met them at a game development conference, which is a common way to meet new clients. We started by using spreadsheets. From the very beginning, a key issue was that some of their existing translations weren’t done by native speakers.
They had a large user base and active community managers. To go global, they decided to add four languages: French, Italian, German, and Spanish. This was when localization platforms were just beginning to appear. Our main value proposition was to organize an automated delivery pipeline for them.
We built a mixed team where their community and content managers worked alongside our localization managers in a shared Slack channel. They all collaborated within the localization platform, looking at the same resources. From that platform, their developers can now export string resources in different formats for iOS, Android, and web apps. It serves as the central repository for all their localizable content.
We know their monthly release cycle. Their writers have a long-standing process of creating content in Excel spreadsheets. Those spreadsheets are then uploaded to the localization platform, where they are translated, checked, and returned to the client.
As they needed more languages, including some exotic ones, we added more linguists to the team. About two years ago, they wanted to adopt AI-driven translations. We worked with them to build an AI workflow and pipeline. This happened at just the right time, as this type of AI-involved pipeline was becoming the new industry standard.
We followed our client’s lead, whether it was adding an exotic language, performing additional testing, or helping their community managers integrate teams. We created a system where their in-house translators and our translators could check each other’s work. We’ve worked with them for a lifetime, and our linguists have become an extension of their development team. They are players who know the game inside and out; they are the keepers of its localization. That’s why it’s my favorite case.
But the common journey for a new client can be quite different. It usually starts with a price inquiry. We get leads every day from studios asking how much it would cost to localize a game with a specific word count—say, 2,000 words or even 2 million words—into ten languages. When a client asks for a simple price quote, it often tells us they are already mature in their localization process. They know about quality, platforms, and setups; they just need the price.
As I mentioned, we always offer three options. We start by interviewing the client to understand what they really need. Every game has different content types, so we ask them to prioritize what needs the highest quality translation and what can be done with less. From there, we build a localization roadmap with a clear timeline. We create a Gantt chart showing all the stages so the client can see exactly how the project will be implemented.
Regarding pricing, it’s volume-based for text translation and hourly-based for localization testing. The more content a game has, the bigger the budget will be. Prices vary a lot, from six to eighteen cents per word, depending on the language. However, no one gives a final price without seeing the content, the game itself, and knowing which linguists will be involved.
When we create an estimate, we already have specific linguists in mind. If a huge game with a million words requires five linguists and months of work, we can often negotiate better rates with them, which translates into a better price for the client.
The process always starts with an interview to understand the client’s needs, followed by a rough estimate of price and time. Sometimes, a client will request test translations to select their preferred linguists. We provide samples from three to five high-quality linguists with different styles, allowing the client to choose the best fit. This is how we form the team.
Once the team is formed, we begin. We get the localization kit from the client—which could be anything from Excel files and JSON files to an existing project on a localization platform. We can work with anything.
**Joseph Kim** *01:24:16*
All right, great. That’s all the questions I have about your business. I thought maybe we could end with a little more of your personal story. We’re all on this earth trying to do interesting things and create value in the world.
Could you talk about how you got into this business and how you founded your company?
**Alex Murauski** *01:24:44*
My background is in mathematics and software development, and I still do some development at Alkonost. My passion is product development.
Over 20 years ago, I built a product and started selling it worldwide. It was obvious to me that the software had to be in English to sell well, so I translated it into languages I knew. I had several friends in a software developer community who were doing the same thing, but their software wasn’t localized. They asked me to help them translate it into English, and I did.
Then, I recommended my girlfriend, who translated software into German, to my friends. They started ordering from her, and I would simply pass the money from them to her. Everything was great until one of the clients said the translation quality was poor and demanded a refund.
My girlfriend was a native German speaker but not a professional translator. I wasn’t selling translations; I was just helping my friends. But because they were sending money through me, they considered it a service. That’s when I understood that if you take money for something, you bear responsibility for the quality. That moment, it became serious. I realized if I deliver something for payment, it must be high quality, so I found a better translator.
It started as a little business game for me, not too serious, because I had my day job as a software developer and revenue from my own software. This was a side hustle. But then I wrote an article in a local newspaper about my experience, and suddenly, translators started asking me to help them find work.
I told them I could give them translation work, but I would charge 50% of what the client pays. That was my margin, and that’s how it started. I announced in the community that I had translators for four languages who could help with software translation. I organized all the technical aspects—this was before localization platforms, so we dealt with XML files, .ini files, and all sorts of things that were easy to break.
I managed the technical side and communication with clients, and my translators did their job. It began with me translating software myself, then adding some friends, and it gained traction. More languages and more orders came in. I started doing some marketing and sales and hired managers to handle it all.
Last year, Alkonost had more than 100 full-time employees, who are our core team of localization managers. We also have 1,500 translators all over the world. That’s how the company grew from that small start.
**Joseph Kim** *01:29:38*
At what point did you decide to go all in? I assume with that much scale, you decided you shouldn’t be a software developer anymore and should focus on this business. What was your thought process when you decided to make that switch?
**Alex Murauski** *01:29:57*
It wasn’t money that made me decide. I had a very good salary at my day job as a software developer, and I also had revenue from selling my own software. But I understood that I had to build a company. With a day job, you’re alone, and you have this glass ceiling on how much you can earn.
Selling my own software as a solo developer was also limiting. It’s easier now with AI-assisted coding, but back then, developing products was very hard work. It didn’t provide enough money to hire someone, and I didn’t trust anyone with my source code. I was worried they would just go and sell my software on their own.
Somehow, I understood that I needed to be a company, not an individual. Building a company is a completely different thing than solo software development. It was a childhood dream of mine to build a company with a name and see it grow.
The realization came when I was negotiating with translators and with developers whose software was much more successful than mine. I was helping them localize, and I found myself surrounded by people who were creating things. I understood that a company was being born right at that moment. One of my translators became a manager, and it became the two of us, plus some translators. Then we invited more people, and it grew organically without any outside investment.
When I decided to commit to my own company, I quit my job with its very good salary. I had no money, was living in my parents’ house, and was even taking money from my mother to pay salaries.
While developing Alkonost, I was also involved in different startups, always trying to build something new. This DNA of doing something else is still with us in the company today. We are always inventing and developing products inside the company, not just focusing on localization.
For example, we use GPT, Gemini, and other LLMs to assess translation quality. We built a SaaS service that can assess the quality of translations using modern AI, and it’s available for free right now. We also have our Nitro translation service, where you can top up your balance, send a few lines of text, and have them translated into 20 languages by native human translators. We developed that system on our own.
This development culture helps us understand how developers think. When a client comes to us, we understand how they would organize their files for localization. This understanding is our key differentiator. We’re not a translation agency that translates everything, like marketing documents. We’re a localization agency that knows how developers think, how they work, and what they need. That is the main reason Alkonost exists and has been successful.
**Joseph Kim** *01:35:14*
I have one last question. It sounds like you’re developing an AI evaluation product for AI-powered translations. When you think about the future of Alkonost, say five years from now, where do you see the company heading?
Do you think you’ll have more of a product focus rather than a service focus, or will it be a blend? Are there other areas you plan to explore? I’d love to understand how you think about the future of your company.
**Alex Murauski** *01:36:11*
The future of Alkonost is absolutely in localization and languages. That is our main expertise.
**Joseph Kim** *01:36:19*
Sure.
**Alex Murauski** *01:36:21*
But it’s not only about the service; it’s also about the technical side and creating products around localization. For our technical stack, we started the Alkonost MT project, a lab where we experiment with AI and deliver different localization tools. This helps us stay on the cutting edge. With every new version of AI that comes out, we implement it into our technology stack.
I see Alkonost as a localization services vendor. As I like to say, we are like a tree, growing organically when there is sun and water. This is common for localization companies worldwide. We’re in a very competitive global market, with at least 100 direct competitors.
We will continue to grow organically, occasionally disrupting the market with new tools, platforms, or platform features. I believe that is the most organic path. We don’t have super big ambitions. I’ve been here for 20 years and have had lots of ambitions, but what has always worked is Alkonost doing localization.
As an entrepreneur, if it could be separated from the company, there might be some side projects. But those would be different businesses or different companies. I have plenty of other ideas, but when it comes to Alkonost, it will be about localization forever.
**Joseph Kim** *01:38:51*
Got it. Specialization and depth—that sounds great. Alex, that’s all the questions I have. Thank you so much for going into depth about your business and providing more context on localization. I don’t think people consider it enough, so I really appreciate the information you’ve shared today.
If people want to get in touch with you, how should they do that? Should they visit your website or find you on social media?
**Alex Murauski** *01:39:32*
The best way is LinkedIn. You can also email me at am@alkonost.com.
**Joseph Kim** *01:39:50*
Great. To our audience, thank you for your attention. We’ll catch you next time. Thanks, everyone, and thank you, Alex.
**Alex Murauski** *01:40:01*
Thank you, Joseph. Thank you for having me.