A Friend Told Me Games Can Be Translated in Real Time Now—and Somehow That Turned Into a Plan to Expand an Article Factory Across the World

How reading tools work

Listen reads the article aloud. Speed read shows phrases in sequence at your chosen pace. Language practice compares available translations. Save keeps a bookmark in this browser; find it in the player’s bookmarks.

Share this article
Advertisement
Advertisement

A friend recently told me about modern game-translation tools.

You select an area of the screen, the software reads whatever text appears there, and a translucent window overlays a translation. There may be some delay, but if the translation stage uses an LLM, it can do more than mechanically swap words. It can paraphrase dialogue into something that actually sounds natural.

My first reaction was simple: “Wait, are we already at the point where you can play foreign games without waiting for a localization patch?”

Then the investigation went completely off the rails.

OCR reads the screen. A translation model interprets the meaning. An overlay puts the result back on top of the original interface.

That architecture is not only useful for games.

And if you already have an article system producing high-quality versions in 12 languages, why not keep those 12 as the premium core, then use a local translation model to spread only the most popular articles into additional long-tail languages with almost no extra API spending?

We started with game subtitles.

We somehow ended up in a meeting about global publishing architecture.

1. Real-time game translation is basically four components

A real-time translation overlay looks magical until you break it apart.

Then it becomes even more interesting.

The basic pipeline is:

  1. Capture a selected region of the game screen.
  2. Use OCR to turn the text in the image into machine-readable text.
  3. Translate it with a translation engine, NMT system, or LLM.
  4. Draw the translated text back over the game as a translucent overlay.

Public Windows projects already use this architecture. OverlayTranslate OCRs a screen region and places translated text over the original location. SubLens continuously watches a game-screen region, detects new text, translates it, and displays the result in a transparent overlay.[1][2]

The old workflow was “take a screenshot, open a translation site, paste it, read it, switch back.”

The new workflow is closer to “tell the interpreter where to look and let them stay beside the game.”

Humanity has apparently decided to summon a resident interpreter next to every untranslated RPG.

2. Google Lens is useful, but it is not the same thing as a persistent game overlay

Google Lens can recognize objects and text in images, let users select text, and translate it.[3]

Google Translate also supports image translation. On desktop, users can upload an image and translate text inside it. On phones, camera-based translation is available. Google itself warns that accuracy can drop with tiny, blurry, or highly stylized text.[4]

So Lens is very close to the “eyes” of the system.

But the type of tool my friend described goes one step further.

Lens is essentially “read this image.”

A game overlay is “keep watching this region, and whenever new dialogue appears, process it automatically.”

The difference is not only translation quality.

Continuous capture, change detection, caching, window-focus checks, and drawing text back into the right place are the boring engineering details that make the experience usable.

AI gets the headline.

Plumbing gets you through the game.

3. “Google Translate is not an LLM, right?” became a more complicated question by 2026

If you think of older Google Translate, it was reasonable to separate it from systems such as ChatGPT.

For years, Google Translate relied heavily on neural machine translation designed specifically for translation.

But in December 2025, Google announced that it was bringing Gemini translation capabilities into Google Translate text translation, with an emphasis on more natural handling of idioms, slang, and context-dependent expressions.[5]

In February 2026, Google expanded Translate with AI-powered alternatives and explanations built on Gemini’s multilingual capabilities.[6]

For speech, Google later announced Gemini 3.5 Live Translate, a near-real-time speech-to-speech model covering more than 70 languages.[7]

So in 2026, saying “Google Translate is not an LLM” as a blanket statement is too simple.

The opposite claim is also too simple. We should not assume that every Translate request is literally routed through a general-purpose Gemini chat session.

Google has publicly described Gemini capabilities integrated into Translate, not the entire internal routing architecture.

The boundary is becoming blurry.

4. Free consumer Google Translate and an automation API are different things

At this point, the obvious thought is: “Then just translate every article with free Google Translate.”

Tempting.

But using a consumer translation interface without per-character billing is not the same as having an officially supported, unlimited, free automation API.

Google Cloud Translation’s standard NMT pricing currently includes a monthly credit covering the first 500,000 characters, after which the standard listed price is $20 per million characters.[8]

Suppose an article has 5,000 characters.

Translate it into 50 languages and that is 250,000 characters.

Two such articles consume 500,000 characters.

Translate ten popular articles into 50 languages in one month and you reach 2.5 million characters. After the free amount, 2 million billable characters at the standard rate would be about $40.

That is cheap.

But it is not zero.

Google Cloud also lists separate input and output pricing for its Translation LLM.[8]

If “no recurring API bill” is a hard requirement, the clean design is not infinite cloud translation. It is a separate local-translation lane.

5. Local translation models are the obvious route for a zero-API-cost lane

This is where local translation models become useful.

Google’s MADLAD-400-3B-MT is published on Hugging Face with support listed for 419 languages and an Apache 2.0 license.[9]

Run it on your own machine and there is no per-request translation API bill.

That does not mean the true cost is literally zero.

It uses CPU or GPU resources.

It uses electricity.

It takes time.

But the scaling model changes. You are no longer paying a cloud vendor for every additional character.

The important caveat is that “419 languages supported” does not mean “human-level quality in all 419 languages.”

Quality can vary dramatically, especially for low-resource languages.

So local translation should not replace your premium 12-language output.

It should become the cheap experimental layer for languages you could not economically test before.

6. This is where the idea jumps from games to an article factory: keep the high-quality 12

If your multilingual publishing system already produces high-quality versions in 12 languages, there is no reason to downgrade them to cheap machine translation.

Those 12 are the mothership.

Imagine the core set includes Japanese, English, Korean, Simplified Chinese, Traditional Chinese, Spanish, Brazilian Portuguese, Indonesian, Thai, Vietnamese, French, and German.

If those versions have already gone through contextual rewriting, natural localization, heading adjustment, and quality checks, they are not merely 12 translations.

They are 12 cleaned semantic representations.

When creating an additional language, you do not necessarily have to translate directly from Japanese every time.

For some targets, English, Spanish, or Indonesian may be a better pivot.

But translation chains can accumulate errors.

So the correct approach is not “pick the closest language by intuition.” Test candidate source languages on a small benchmark and choose the route that best preserves numbers, names, negation, qualifiers, and meaning.

7. Do not translate every article into every language. Popularity is the filter

This is the most attractive part of the design.

If you have 5,000 articles, you do not need 5,000 articles times 100 languages.

Start with the popular ones.

For example, using the last 30 days of page views:

  • Top 10 articles: expand into 50 additional languages.
  • Articles ranked 11–50: expand into 20 additional languages.
  • Everything else: remain in the premium 12 only.

Or make it even simpler: every day, take the top 20 articles and translate only the missing article-language combinations.

Translations become assets once created.

So every day, the world map gets colored in a little more, starting from content that already proved people want it.

This is not “invade the entire planet with full infrastructure on day one.”

It is “send nearly free scouts everywhere and send the main force only where people respond.”

Much smarter.

Much cheaper.

8. A three-tier language model lets demand decide where quality investment goes

The added languages can be divided into three tiers.

Core: the current high-quality 12. LLM localization, strict QC, all articles.

Growth: additional languages that have started to generate real traffic. Local translation remains the default, but more articles are added.

Experimental: languages with unknown demand. Only popular articles are translated, and initial search indexing can be limited.

Then promotion is based on metrics such as visits, completion, next-article clicks, and repeat visits.

If nobody reads an Experimental language, leave it there.

If Polish starts producing traffic, move it to Growth.

If Turkish continues growing and reader behavior is strong, it becomes a Core candidate.

This removes the need for a meeting where everyone guesses, “Which language is going to be big next?”

Translation itself becomes market research.

9. Code-based QC comes first if you want the free model to stay free

If every additional translation is sent to ChatGPT with “Is this correct?”, the free-translation strategy quickly stops being free.

So the first QC layer should be deterministic code.

A surprising amount can be checked automatically:

  • numbers, percentages, currencies, and dates are preserved;
  • URLs are unchanged;
  • heading counts have not collapsed;
  • Markdown or HTML remains valid;
  • titles and descriptions are not empty;
  • too much source-language text has not leaked through;
  • the output roughly matches the expected script or language pattern;
  • negation has not obviously disappeared;
  • proper nouns have not been mangled beyond recognition;
  • output length is not absurdly short or long.

If needed, use the local model again for back-translation into English and flag only large semantic deviations.

That is not perfect quality evaluation.

It is, however, very useful for preventing broken translations from being mass-published.

Save expensive LLM intelligence for suspicious cases rather than paying it to inspect everything.

10. “100 languages” is less important than making sure 100 languages are not 100 piles of junk

There is one final trap.

Creating 100 language versions does not mean search traffic becomes 100 times larger.

Google Search Central recommends separate URLs for each language version and hreflang annotations to connect them. It also recommends making the visible language of each page clear, including both content and navigation.[10]

Google also lists scaled generation of low-value pages—including automated transformations such as translating—as an example of scaled content abuse when the primary purpose is manipulating search rankings rather than helping users.[11]

So there is no reason to index every Experimental page the moment it exists.

Start with noindex if necessary.

Observe quality and demand.

Promote only languages that pass the quality gate.

Make sure readers can actually use the page.

Translate the interface, not only the article body.

Use language-specific URLs and correct hreflang relationships.

Preserve meaning.

And translate genuinely valuable source articles.

Only then does “more languages” become an asset instead of a multiplication machine for garbage.

The whole idea began with a friend talking about games.

“Apparently you can select part of the screen, read the text, use an LLM to translate it naturally, and overlay the result.”

That led to Google Lens, then to the changing boundary between Google Translate and LLMs, then to API pricing, then to local translation models.

And the final architecture was:

Keep the premium 12 languages exactly as they are.

Use local translation to spread only popular articles into additional languages at near-zero marginal API cost.

Let real demand determine which languages graduate to higher quality.

We started by overlaying one translated subtitle on a game.

We ended by overlaying new language layers on an entire publishing system.

Technology reuse often begins with this kind of completely reasonable derailment.


References (11)

  1. OverlayTranslate — Windows overlay translation tool using OCR and multiple translation engines github.com
  2. SubLens — real-time OCR-powered game dialog translator with continuous scan and transparent overlay github.com
  3. Google Search Help — Google Lens can select text and translate supported text through Google Translate support.google.com
  4. Google Translate Help — image translation on desktop and mobile; Google notes lower accuracy for small, unclear, or stylized text support.google.com
  5. Google, 2025-12-12 — Bringing state-of-the-art Gemini translation capabilities to Google Translate blog.google
  6. Google, 2026-02-26 — AI-powered context and translation alternatives in Google Translate using Gemini capabilities blog.google
  7. Google, 2026-06-09 — Gemini 3.5 Live Translate, near-real-time speech-to-speech translation in more than 70 languages blog.google
  8. Google Cloud Translation pricing — NMT first 500,000 characters per month covered by free credit, then standard per-character pricing; Translation LLM priced separately cloud.google.com
  9. Google MADLAD-400-3B-MT on Hugging Face — 419 languages listed, Apache 2.0 huggingface.co
  10. Google Search Central — Managing multi-regional and multilingual sites; separate URLs and hreflang guidance developers.google.com
  11. Google Search Central — Spam policies; scaled content abuse includes low-value pages generated through automated transformations such as translating when created primarily to manipulate rankings developers.google.com

Read this today

Each one answers a question readers of this article tend to ask next.

Browse all articlesMore on Friends and socializing

Advertisement

Find other articles

All articles

Mendoi-chan

Who runs this site

Mendoi-chan

She turns friction at work and in everyday life into clear structure and practical next steps.