Source metadata
- Type: Official engine documentation
- Maintainer: Unity
- Accessed: 2026-04-15
- Primary URLs:
Key takeaways
- Unity treats localisation as a package-backed workflow. The docs frame localisation around localisation settings, locales, string localisation, asset localisation, and import/export support rather than around ad hoc hard-coded strings.
- Pseudo-localisation should happen early. Unity explicitly lists pseudo-localisation as a way to test how a project adapts to different localisations before translations have been produced.
- String Tables and Asset Tables are the central organisational units. UI text belongs in String Tables; region-specific art or other assets can live in Asset Tables.
- Locales are explicit project assets. Teams are expected to define the languages and regions they support, set a default locale, and map content against those targets.
- Localisation affects layout as well as text. The UI Toolkit workflow makes it clear that localised projects need to plan for changing text length, swapped assets, and region-specific presentation.
Notable claims
- Unity’s localisation overview lists string localisation, asset localisation, pseudo-localisation, and import/export as core package features.
- Unity’s UI Toolkit guide explicitly instructs teams to create locales first, then build String Tables and Asset Tables around them.
Relevance
This source primarily informs:
It also supports:
Open questions raised
- The official docs explain the tooling well, but say less about production ownership. Which discipline should usually own localisation keys, table hygiene, and translator handoff in a small team?
- Localisation and accessibility often collide in UI layout. Should the wiki eventually split technical localisation workflow from broader release-readiness concerns?