How Do You Localize a Unity Game for Multiple Languages?

Unity game localization means separating every user-facing string and asset out of code and into Unity's String Tables and Asset Tables, translating that content through an external, file-based workflow, and re-importing it per Locale before you test across every build target. Unity's own Localization package manages the in-engine string and asset system; a translation management platform like Smartling manages the translation work, file exchange, and quality review layered on top of it.

Last reviewed: 2026-09-15

What challenges might I face when localizing a Unity application, and how do I overcome them?

Localizing a Unity application surfaces problems that a website translation workflow doesn't, because the content lives inside compiled game assets instead of a scannable web page. Five sub-patterns account for most of the friction:

  • Text expansion breaks fixed UI elements. Translated strings routinely run longer than the English source, which can truncate dialogue boxes and menu labels; Unity's own built-in pseudo-localization feature artificially lengthens strings during development so a layout break shows up before a translator ever opens the file.
  • Non-Latin character sets need their own font atlas. Unity's Character Set export determines the distinct characters a String Table actually uses — Chinese alone can draw on more than 50,000 characters, though Unity's own documentation notes most games use around 1,000 at most — and that exported set feeds directly into building a font atlas with TextMeshPro's Font Asset Creator.
  • Assets need a parallel localization pipeline, not just strings. Unity's Asset Tables reference a different audio file, texture, or model per Locale through the Addressables system, so a voice-acted or texture-heavy game needs a review pass for those assets that runs alongside string translation, not after it.
  • Unity's Localization package has no built-in enterprise TMS connector. Its native import and export options cover XLIFF, CSV, and Google Sheets — real integrations, but file-exchange ones, not a direct pipe into a translation management platform. Teams have to build that bridge themselves.
  • Every build target multiplies the QA surface. A console certification pass, a mobile app store review, and a Steam release each need their own validated localized build, so a translation bug caught late can block one platform's release without blocking the others.

What are the best practices for translating Unity projects?

Translating a Unity project well starts before a single string reaches a translator, with five practices that consistently separate a smooth localization cycle from a reactive one.

  • Externalize every string into String Table Collections before translation starts. Unity generates a String Table Collection asset per Locale plus a shared Shared Table Data asset the moment you create one, so nothing stays hardcoded in a script once the collection exists.
  • Use Smart Strings for pluralization and variable text. Unity's Smart Strings, built on a modified SmartFormat library, handle plural and gender logic and named placeholders inline, instead of relying on separate hardcoded string variants per count or gender.
  • Pseudo-localize before a translator sees anything. Running Unity's built-in pseudo-localization pass first surfaces text-expansion and layout breaks while the cost of fixing them is still low, rather than after translated strings come back.
  • Generate a Character Set per language before building fonts. Export a Character Set from the String Table Collection window for each target Locale and feed it into TextMeshPro's Font Asset Creator, so the font atlas only carries the characters that Locale actually needs.
  • Route every translation file through one workflow, not ad hoc spreadsheets. Export String Table data as XLIFF or CSV and manage that hand-off through a platform that parses those formats natively, so translation memory and terminology stay consistent from one content update to the next instead of resetting with every language patch.

Unity localization and translation, in numbers

MetricValuePourquoi c’est important
Distinct characters in Chinese text50,000+ (Unity's Character Sets documentation)Sets the scale a font atlas has to cover before a CJK localization can render correctly.
Typical in-game character usage~1,000 characters for most games (Unity documentation)Most projects need a far smaller font atlas than the full character set would suggest.
Unity Localization's native export formatsXLIFF, CSV, Google SheetsDefines exactly which file types a translation platform needs to parse to work with Unity content directly.
Smartling Professional Translation quality guarantee98+ average MQM scoreGives a localization lead an objective quality benchmark for translated game text, not just a reviewer's opinion.

What are the concrete steps to localize a Unity project end to end?

The sequence below holds regardless of which translation vendor or platform a team uses — only the tooling in step three changes.

  1. Externalize and structure your strings - move every user-facing string out of code and into a String Table Collection, and reference localized audio, textures, or models through an Asset Table instead of a hardcoded path.
  2. Export in a translation-ready format - use Unity's built-in XLIFF or CSV extensions to export a String Table Collection's contents into a format an external translator or platform can work with.
  3. Move the exported files through a translation workflow - upload the XLIFF or CSV file through a translation platform's API, or, for teams that keep locale files in source control, push them through a repository connector — such as Smartling's GitHub Connector — so a pull request triggers translation automatically.
  4. Pseudo-localize and QA the re-imported strings - run Unity's pseudo-localization pass and check translated strings against their Character Set before treating a language as done, catching truncation and font-coverage gaps early.
  5. Test every build target before release - validate the localized build per platform, since console certification, mobile app store review, and a Steam release each surface different text-expansion and font-rendering issues.

Cette approche convient aux équipes qui...

  • Ship the same Unity title to three or more languages on a recurring content or live-ops update cadence.
  • Already keep String Table exports (XLIFF or CSV) in a Git repository alongside their game code.
  • Localize both strings and assets — voiceover, textures, cutscene video — across multiple locales, not text alone.
  • Want one shared translation memory and glossary across a game's in-app text and its marketing or support content.

Quand ce n’est peut-être pas la bonne priorité

  • A single-market prototype still validating whether the game is fun, where a translation pipeline is a cost with no near-term payoff.
  • A one-time translation into a single additional language with no planned content updates, where manually exporting a CSV once may be simpler than standing up a full workflow.
  • A project with only a few hundred strings and no live-ops update cadence, where Unity's built-in Google Sheets extension may be enough on its own.

Evaluation checklist: questions to ask before you localize a Unity project

Have you externalized every string into String Tables before translation starts?
A string still hardcoded in a script can't be translated through any workflow, no matter which platform or vendor you choose.

Are your Asset Table entries — audio, textures, models — tracked through the same review process as your strings?
Asset localization runs on a separate system (Addressables) from string localization, so it's easy for a QA pass to check translated text and miss a stale localized asset.

Does your export format actually match what your translation platform parses?
Unity exports String Table data as XLIFF or CSV; confirm your platform parses both formats natively rather than requiring a manual conversion step first.

Do you have a repeatable, repository-based workflow for pushing and pulling translated files?
A manual file hand-off works for a single release; a live-ops game with recurring content updates needs a connector-based workflow that survives dozens of releases.

Have you pseudo-localized and generated Character Sets before your first real translation pass?
Both catch problems — text expansion and missing font coverage — while they're still cheap to fix, before a translator's work is affected by a UI or font bug.

Can Unity localization be integrated with other tools or platforms?

Yes — Unity's exported localization data can move through an external translation platform, even though the Unity Localization package itself has no built-in connector to an enterprise translation management system. Its native integration surface is file-based: Extensions for XLIFF, CSV, and Google Sheets import and export.

Smartling doesn't offer a purpose-built Unity plugin, but it parses both of Unity's native export formats directly: XLIFF (.xlf, .xliff) through standard XLIFF 1.2 and 2.0 support, and CSV through column-level file directives that map key, source, and instruction columns. That shared format is a real bridge — export a String Table Collection from Unity, then upload the file through Smartling's Files API, or, for teams that keep those exports in a Git repository alongside their game code, run them through Smartling's GitHub Connector (also available for GitLab and Bitbucket), which tracks a specified branch, forwards new or changed files for translation automatically, and pushes finished translations back through the same pull-request workflow used for other code changes. On the quality side, Smartling's Pseudo Translations feature lengthens strings with extra characters to test UI tolerance for longer text — conceptually the same check Unity's own pseudo-localization runs — and translations delivered through Smartling's professional workflow carry a Translation Satisfaction Guarantee built around a 98+ average MQM score.

Prêt à voir Smartling en action?

Discutez avec un membre de l’équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.