Most Game Portal Localisation Budgets Are Spent in the Wrong Order

Localising a game portal pays off in a specific order: payments and store metadata first, interface second, in-game text last. Most operators invert it.

The usual localisation project starts with a spreadsheet of UI strings and ends when the spreadsheet is full. Six weeks later the portal has nine language options in a dropdown, the bounce rate in those nine markets has not moved, and nobody can explain why. The strings were never the bottleneck. The bottleneck was that a player in Jakarta or Casablanca could read the page fine and still had no way to pay you, no reason to trust the page, and no path to it from search.

Localisation for a games business is a stack of separate problems that happen to share a budget line. They have wildly different costs and wildly different returns, and they are almost never done in the order that returns the most money first.

🌍 The Web Is Half English and the Audience Is Not

Start with the size of the gap. As of August 2026, W3Techs measures English at 49.5% of all websites whose content language it can identify. Spanish and German sit at 6.0% and 5.9%, Japanese at 4.9%, French 4.5%, Portuguese 4.1%, Russian 3.4%. Turkish is 1.6%, Chinese 1.3%, Indonesian 1.2%, Arabic 0.6%.

Hold Arabic at 0.6% of websites next to what Arabic-speaking markets spend on games, and you have the whole argument in one line. The supply of content is nothing like the distribution of demand. English's share has been sliding for years — it was above 55% not long ago — but half the web still speaks a language that is not the first language of most people using it.

The demand-side number people quote is CSA Research's "Can't Read, Won't Buy": a survey of 8,709 consumers across 29 countries, published in 2020, finding that 76% prefer to buy products with information in their own language and 40% will never buy from a website in another language. Treat the vintage honestly — it is a 2020 study and it gets recycled well past its expiry date. But the direction has never been contested by anything credible, and the second figure is the one that matters more than the first. A soft preference costs you conversion rate. Four in ten refusing outright costs you the market.

That gap is not evenly distributed across your funnel, which is why the order of operations matters so much.

💳 Payments Localise Before Language Does

If your portal monetises, the first thing to localise is not a word. It is the checkout.

A translated page with a card form on the end of it converts badly in every market where cards are not how people pay. That is most of the markets worth expanding into. In much of Southeast Asia, MENA and Africa, the practical options are carrier billing, e-wallets, bank transfer rails and prepaid vouchers — and the operator or wallet you need is specific to the country, not the region. Getting this wrong is invisible in your analytics because it looks like disinterest. The player did not bounce at the language barrier. They bounced at the payment barrier, two screens later, and your funnel reports it as churn.

Three things to fix before any translation memory gets built:

• Price display in local currency, with local formatting conventions for decimal separators and currency position. Showing USD to a market that never thinks in USD adds a mental conversion step to every purchase decision.
• At least one payment method the market actually uses. If that is carrier billing through a mobile operator, the integration work dwarfs the translation work and should start first because it takes longest.
• Price points set locally, not converted. A $4.99 tier converted at spot rate lands as a nonsense number in most currencies and often at a price the market will not bear regardless of formatting.

None of this requires a single translated string. All of it moves revenue more than the strings do.

🏪 Store Metadata Is the Cheapest Localisation You Will Ever Buy

If any part of your catalogue ships as Android builds, localised store listings are the highest-return work per hour available to you, and it is not close.

Google Play lets you supply translated titles, short descriptions, long descriptions and creative assets per locale, and serves the localised listing when the user's language preference matches one you have enabled. Where you have not supplied a translation, Play offers the user a machine translation with a notice attached — which is a fallback, not a strategy, because it does nothing for how you rank inside that locale's search results. Play also supports custom store listings, which segment by country or install state rather than by language; those are a different tool for a different job, and confusing the two is common.

Published counts of how many locales Play supports vary between sources — figures from 51 to 83 circulate depending on how the counting is done and when it was done. Do not plan against a blog post's number. The Play Console's own language list is the only count that is current, and it is the one your release manager should be reading.

The reason this beats everything else on return is arithmetic. A store listing is a few hundred words. A portal is tens of thousands. The listing is what gets indexed by the store's own search, which is where the majority of organic installs originate. You are paying for a rounding error of translation volume against the entry point to a whole market's discovery surface.

🔤 Then Work Out How Much of the Product Actually Has Text

Here is the part that surprises operators licensing casual catalogues: most of the games do not need translating.

A well-built casual HTML5 title communicates through iconography, animation and a tutorial that is three taps long. Match-3, hyper-casual runners, physics puzzlers, dress-up, racing, bubble shooters — the text content is often a score label, a pause menu and a game-over screen. That is a genuine structural advantage of a casual licensed catalogue over narrative or mid-core content, and it means your localisation surface is smaller than the size of your library suggests.

What does need translating, ranked by how much it costs you to skip:

1. Game titles and category names. These are the labels a player scans before deciding to click anything. They are also the highest-density keywords on your site. Low word count, disproportionate impact on both conversion and search.
2. Navigation, onboarding and account flows. Sign-up, subscription terms, cancellation, help. Anything a confused player would otherwise resolve by leaving.
3. Legal and billing copy. Subscription terms in particular are frequently subject to local disclosure rules — this is not a place for approximate translation.
4. In-game strings. Genuinely last for most casual content, and for some titles genuinely never.

There is one hard exception worth budgeting for up front: text baked into image assets. A "PLAY" button rendered into a sprite sheet cannot be translated without a rebuild. When you are doing due diligence on a catalogue, ask whether UI text is drawn at runtime or baked into the art. The answer determines whether localisation of the games themselves is a text job or an art job, and the difference between the two is an order of magnitude in cost.

↔️ Right-to-Left Is a Layout Problem, Not a Translation Problem

Arabic, Hebrew, Persian and Urdu do not just need different words. They need the interface to run the other way, and this is where portals ship visibly broken work.

The modern approach is not a second stylesheet. Set dir="rtl" on the document and use CSS logical properties — margin-inline-start rather than margin-left, padding-inline-end rather than padding-right, border-inline-start rather than border-left. Flexbox and Grid already respect document direction, so a row-direction flex container flows right-to-left on its own once the direction is set. Browser support for logical properties has been solid across evergreen engines for years. If your portal was built in the last five years, retrofitting is mostly a find-and-replace plus a careful pass over anything absolutely positioned.

What does not mirror is the trap:

• Numbers stay left-to-right, including scores, prices and timers, even inside RTL text.
• Media controls do not mirror. Play, pause and progress bars keep their conventional direction.
• Game canvases almost never mirror. The game runs the way it was built. Flipping the chrome around an unmirrored canvas is correct; flipping gameplay is not.
• Logos and brand marks do not mirror, and neither do most icons that depict real objects.

Budget a real QA pass on native devices with a native reader. RTL breakage is the kind of defect that is invisible to a team that cannot read the script and glaring to everyone who can.

🔎 Machine Translation at Scale Is Now a Search Liability

The tempting shortcut — pipe the whole portal through machine translation, generate forty locale subfolders, wait for traffic — is riskier than it was two years ago.

Google's spam policies added scaled content abuse in March 2024, with enforcement following that May. The policy explicitly names automated translation among the transformations that can produce spam when the output adds little value for users, and it is deliberately method-agnostic: what is judged is whether pages were generated primarily to manipulate rankings, not what tool generated them. Machine translation is not banned. Machine-translating a large site into many locales, publishing it unreviewed and calling that international SEO is squarely the pattern the policy describes.

The workable version is narrower and duller. Translate the pages a human would actually land on and act on — category pages, the top of the catalogue, onboarding, billing — and have a native speaker review them. Leave the long tail in a language you can defend. Implement hreflang properly so the versions you do publish are served to the right audience instead of competing with each other. A portal with four genuinely localised markets outranks one with forty auto-generated ones, and it does not carry the tail risk.

📈 Choosing Markets Without Chasing Growth Rates

Newzoo's 2025 market report, as reported by PocketGamer.biz, put the global games market at $188.8 billion, up 3.4% year-on-year, with mobile at $103 billion and a 55% share. Regionally: Asia-Pacific $87.6 billion, Europe $33.1 billion, Latin America $8.3 billion, MENA $7.1 billion, with the Middle East and Africa flagged as the fastest-growing region at +6.8% year-on-year. Note that secondary write-ups of the same report quote MENA growth at 7.5%; where sources disagree, take the range rather than the flattering end.

The instinct on reading that is to localise for the fastest-growing region. Resist it. Regional growth rate tells you about the market's trajectory, not about your ability to reach it. A market you have no traffic in, no payment rail for and no acquisition channel into will not convert because it is growing.

A better selection method, in order:

• Start with traffic you already have. Pull your analytics by country and by browser language. Markets already sending you unlocalised traffic that converts worse than your baseline are your shortest path — the demand is proven and the friction is measurable.
• Then look at distribution you can actually get. If you have a route into a market — an operator deal, a portal partner, a store presence — that route justifies localisation more than market size does.
• Then consider language efficiency. Spanish and Arabic each open many countries with one localisation effort. Languages that map to a single national market have to earn their spend on that market alone.
• Only then look at growth charts. They are the last input, not the first.

🚫 How Portals Get This Wrong

• Shipping a language dropdown as the deliverable. The dropdown is the cheapest part and the one users notice least. If the checkout, the store listing and the support path are still English-only, you translated the wrapper.
• Translating without a glossary. Game and portal terminology needs to be fixed once and reused. Without a glossary, "level", "stage" and "round" come back as three different words per locale from three different translators, and the interface reads as machine output even when it is not.
• Ignoring text expansion in layout. German and Russian routinely run substantially longer than English; some languages run shorter. Fixed-width buttons designed against English strings break in both directions. Test with real translations, not with lorem ipsum.
• Localising the site but not the catalogue curation. Which games get featured should differ by market. Serving an identical front page everywhere and calling it localised is the most common version of this failure.
• Treating localisation as a project. Every new game, promotion and price change generates strings. If there is no ongoing process, the localised versions decay into a stale subset of the English site within two release cycles, which is worse than never having built them.
• Skipping the RTL QA pass because the strings came back and the page loaded.

🎮 Where a Licensed Catalogue Helps

Forestry Games has licensed games since 2017, with a catalogue of 1,049 HTML5 and Android titles and a services line covering licensing, white-label portals, branded game development and distribution. The company works with branded IP and holds brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros.

The relevance to this topic is narrow but real: a catalogue weighted towards low-text casual titles reduces the localisation surface of the games themselves, leaving the portal chrome — which you control and can localise once — as the main work. Two questions are worth asking any licensor before signing: whether UI text is rendered at runtime or baked into assets, and whether the licence permits you to modify game assets for localisation at all. The second one is a licence-scope question that catches buyers out after the fact.

🧭 What to Do Next

Before commissioning a single word of translation, run a two-hour audit. Pull your top ten countries by sessions and put conversion rate next to each. Find the ones converting below your site average despite decent volume — those are markets where something other than interest is failing, and localisation may be it. For each, check three things: whether a payment method those users recognise exists at checkout, whether your store listings are translated for that locale, and whether the category and title text they would search for appears anywhere on your site in their language.

Fix in that order. Payments, then metadata, then titles and navigation, then everything else. Most portals do it backwards and conclude that localisation does not work in their vertical. What did not work was translating the least valuable layer first and stopping when the budget ran out.