China Is Not a Locale. It’s a Publishing Stack.

A locale covers language and regional choices: text, formats, fonts, input, currency, and presentation. A China release can also involve route, rights, publisher, operator, approval, storefronts, accounts, payments, community, support, servers, identity, data, and ongoing updates. Think of those parts as a publishing stack. Language is the first visible layer, not the whole structure.

Your route may need only some layers. Name the ones you are leaving out and why. An unmade decision tends to reappear later as an account, contract, or technical dependency nobody owns.

Formal mainland publishing requirements and platform policies change. Verify the route for the actual title, platform, entity, and operating model before committing money or dates.

The same translation can sit inside two different releases

Imagine a PC game with Simplified Chinese text on its worldwide Steam page. Chinese-speaking players can understand the page, buy where the storefront is available to them, play the same global build, and contact the studio’s support team. That is a real piece of market work. It can be valuable. It is not the same project as formally publishing and operating the title in mainland China through an eligible local structure.

The second project may require a local applicant or publisher, approval work, a defined operator, platform and entity records, different service infrastructure, identity and minor-protection systems, data decisions, local support, moderation, payment operations, and a build/update process that matches the approved and distributed product. The exact list depends on the route. Assign those responsibilities to people and systems; a language file cannot carry them.

This distinction is not a reason to avoid China. It is how a small studio finds a version of the opportunity it can operate honestly.

The stack, layer by layer

1. The player promise

Start with the cheapest risk to test: the intended player may misunderstand the game.

The promise is the compact answer to four questions: What do I do? What kind of pressure or pleasure will I feel? What makes this game different? Why should I care now? The Chinese name, capsule, short description, trailer opening, tags, and first demo minutes should agree on those answers.

Translation can preserve a weak promise perfectly. Test the top of the stack early: give the assets to genre players without a spoken introduction, then ask them to explain the game back to you. When they describe a different game, you have found a positioning problem while it is still cheap to fix.

2. Language and product localization

Text translation is followed by font coverage, line breaking, input methods, UI expansion, subtitle timing, search terms, cultural context, support language, patch notes, error messages, and store metadata. “Simplified Chinese supported” is a product claim. It should describe the build accurately.

Do not send translators a context-free export and expect them to reverse-engineer the game. Provide screenshots, speaker and scene context, character limits, terminology, gameplay access, and a route for questions. Then test the localized build with the same seriousness as the source language.

3. The route

The route answers where and under what structure the game reaches players. For an overseas indie, useful choices might include:

• serving Chinese-speaking players through the international PC release;
• testing demand through localized assets, a demo, and community work without promising distribution;
• pursuing formal mainland publication and operation with an eligible partner;
• preparing a mainland mobile release with the relevant platform, filing, approval, SDK, and operating requirements.

These options form separate operating choices, not a maturity ladder. Choose the route your team can support after launch, even if it looks narrower on a pitch deck.

4. Rights and counterparties

Who owns the game? Who can authorize publication, localization, adaptation, marketing, and operation? Do music, middleware, actors, fonts, user-generated content, or licensed brands impose territory or modification limits? A partner cannot repair rights the studio never secured.

Then come the counterparties: publisher, operator, storefront, marketing vendors, localization provider, server host, customer-support provider, analytics processor, payment provider, and sometimes more. Every new party adds a contract, handoff, account, data path, and exit question.

5. Approval and platform eligibility

The NPPA’s official service guide for games authorized by overseas copyright holders describes an approval process and an applicant with relevant publishing qualifications. It also describes submission, content review, possible corrections, a decision, and publication of results. That is already much more specific than “we will get an ISBN.”

Platform eligibility can add its own evidence. Apple’s current App Store Connect reference, for example, separates China-mainland ICP information from the game approval number and supporting documents. One field does not silently satisfy the others.

An approval or verified platform record opens a gate. It does not supply audience fit, a strong store page, stable servers, trained support, a useful partner report, or an update roadmap.

6. Distribution and commerce

Which store or channel carries the product? Which company controls the account? Who sets availability, price, discounts, packages, keys, refunds, and release timing? Who can see sales and acquisition data? How does the studio reconcile reports and revenue?

These questions sound administrative until a launch needs a price correction and nobody on the call can change it. Put permissions and decision rights into the launch plan, not just the contract archive.

7. Runtime services

Login, identity, servers, matchmaking, cloud saves, entitlements, anti-cheat, chat, voice, moderation, payments, analytics, crash reporting, and customer support are not background details. They determine whether the game can be operated.

Map each service to an owner and failure mode. If an overseas analytics endpoint is unreachable, does the game fail to start? If verification is slow, is the player trapped at login? If a partner SDK changes, who tests the update? If the relationship ends, can the studio still patch the game?

8. Community and support

A Chinese social account becomes an operation only when someone reads what players say, classifies issues, replies with authority, sends product findings to the right team, and returns with an outcome.

Choose fewer surfaces and operate them well. Set response hours, escalation levels, tone, moderation boundaries, and a weekly product-feedback review. Preserve the vocabulary players actually use; it often improves store copy, tutorial text, and support search at once.

9. Data and accountability

Every account and SDK creates questions: what data is collected, for what purpose, where it goes, how long it remains, who can access it, and how a player can exercise applicable rights. Cross-border transfers add another layer. So do real-name systems, minor protection, voice, chat, and user-generated content.

Start by removing data you do not need and drawing the flows that remain. Threshold research comes later. Legal review becomes far more useful when counsel can see the product, entities, systems, data fields, endpoints, and contracts.

Why small teams get trapped between layers

Watch for sentences with no owner, especially “the publisher will handle China.” Ask which task that covers: approval submission, store operation, localization, media buying, build QA, servers, support, moderation, or data reporting. Then name the artifact and backup owner for each answer.

Another trap is letting the first vendor choose the route. A localization company sees a localization project. A marketing agency sees a campaign. A publisher sees rights and distribution. An SDK vendor sees an integration. Their expertise may be real, but the studio still has to own the product-level choice.

The third trap is announcing a date before the slowest dependency is understood. Public approval batches, partner optimism, or another game’s timeline cannot make your title controllable. Use ranges for internal capacity planning, but keep launch promises behind evidence-based gates.

A stack audit you can run this week

Create a table with one row per layer and five columns: desired outcome, current evidence, owner, next artifact, and stop condition.

For example, the localization row might require a tested Chinese name and store-page comprehension report. The partner row might require a responsibility matrix and account-ownership schedule. The SDK row might require a data-flow register. The storefront row might require verified access to a draft product page. The support row might require a staffed queue and escalation drill.

Mark a row green only when the artifact exists and has been checked. A confident meeting is not an artifact. A deck is not a working account. A submitted application is not an approval. A translated script is not a localized build.

Then choose the smallest vertical slice through the stack. For an international PC release, that could be a Chinese store page, a localized demo slice, one supported community surface, one support route, and a clean data inventory. For formal mainland publishing, it may be a partner-qualified content and rights assessment before production work expands.

Use the stack to stop one broad word, “China,” from hiding a dozen separate projects. Once the layers are visible, a small team can fund the ones that create evidence, reject the ones it cannot own, and postpone the ones that need a stronger product case.