Game Localization · All Services
Godot Engine Localization — Pipeline, PO Files, and LocQA
Native translators. Engine-specific expertise. LocQA in your build. Get a free quote →
Godot Engine uses a GNU gettext-based internationalization system — .pot template files generated from scene and script scans, filled-in .po files per locale, imported via the Project Settings → Localization panel. The pipeline is well-designed for indie and mid-size teams: it is entirely file-based, requires no third-party platform, and integrates cleanly with professional CAT tools. The challenge is completeness — every localizable string in GDScript, C#, or scene nodes must be explicitly wrapped in a tr() call for Godot to track it, and POT generation misses strings that are assembled at runtime or stored in resource files. SandVox handles Godot localization projects from POT audit through LocQA in a running build.
Common Localization Challenges
- Explicit tr() wrapping required — Godot only tracks strings that are passed through tr(), TranslationServer.translate(), or equivalent C# Tr() calls; hardcoded strings in GDScript, C# files, or resource properties that bypass tr() are invisible to the Localization Dashboard and will not appear in the POT export
- POT generation completeness — Godot’s built-in POT generator scans scenes and scripts for tr() calls but cannot detect strings assembled from variables at runtime, concatenated strings, or strings stored in custom Resource files
- Plural form handling — GNU gettext plural rules vary by language; each .po file requires a correct Plural-Forms header (German: 2 forms, Russian: 4 forms, Arabic: 6 forms), and Godot’s plural translation uses tr_n() rather than tr()
- CJK font rendering — Godot requires a DynamicFont with fallback fonts configured to cover Chinese, Japanese, and Korean glyph ranges; missing glyphs render as boxes at runtime with no error in the editor
- RTL text layout — Godot 4’s TextServer supports bidirectional text natively, but UI Control nodes require layout_direction = LAYOUT_DIRECTION_RTL set per node or globally; standard left-to-right layouts do not automatically mirror for Arabic and Hebrew
- GDScript vs. C# API differences — GDScript uses tr() and tr_n(); C# uses Tr() and TrN(); both should ultimately hit the same TranslationServer, but C# projects require a separate audit pass to confirm all Tr() calls are present
- Locale code format — Godot uses locale codes like ‘en’, ‘ja’, ‘zh_CN’, ‘pt_BR’ (with underscore, not hyphen); file naming and TranslationServer.set_locale() calls must match the format expected by the Localization panel
What We Deliver
- String audit — identifying all tr(), tr_n(), Tr(), TrN(), and TranslationServer.translate() calls, plus hardcoded strings that bypass the localization system
- POT template generation, review, and completeness check across GDScript and C# source files
- PO file translation per target locale using memoQ with per-project Translation Memory and Godot-specific terminology glossary
- Plural-Forms header configuration per language per CLDR plural rules
- CJK DynamicFont fallback configuration for Chinese, Japanese, and Korean builds
- RTL layout configuration and LocQA for Arabic and Hebrew UI Control nodes
- LocQA in a running Godot build — font rendering, text overflow, layout direction, runtime locale switching via TranslationServer
- Post-update delta POT export and re-translation for game patches and DLC
How a Project Works
- Scoping: Godot version (3.x or 4.x), GDScript vs C# vs mixed, platform targets (PC, mobile, console), string count via POT export
- String audit — confirming POT completeness against source files, flagging runtime-assembled strings and resource-stored text requiring manual extraction
- Translation by native-language translators with Godot-specific context metadata and character limit flags
- PO file delivery per locale with correct Plural-Forms headers, ready for placement in the Godot project locale directory
- LocQA in running Godot build — font rendering validation, layout testing, RTL direction verification, locale switching behavior
Languages Available
Japanese · Korean · Simplified Chinese · Traditional Chinese · German · French · Spanish (ES) · Spanish (LATAM) · Brazilian Portuguese · Italian · Russian · Polish · Arabic · Dutch · Swedish · Czech
Frequently Asked Questions
What Godot versions does SandVox support?
Godot 3.x and Godot 4.x — both use the GNU gettext .po/.pot pipeline with the same file structure. Godot 4 adds improved TextServer bidirectional text support and better CJK rendering infrastructure; we note engine version during scoping and flag any version-specific LocQA requirements, particularly for RTL and CJK builds.
How do I generate a POT file from my Godot project?
In Godot 4: Project → Tools → Extract Translations → Generate POT File. In Godot 3: Project → Export → Resources → Generate POT template. Both scanners look for tr() calls in GDScript and scenes. The generated POT is a starting point — a manual audit is needed to catch strings that are hardcoded without tr() wrapping or assembled at runtime outside the scanner’s reach.
Can SandVox deliver PO files ready for direct import into Godot?
Yes. We return locale-named .po files (e.g., ja.po, de.po, zh_CN.po) with correct Plural-Forms headers, ready for placement in your project’s locale directory or referenced via the Localization panel. Files are structured to import cleanly without manual editing.
Does Godot support RTL languages natively?
Godot 4 has native bidirectional text support via TextServer, but UI nodes do not automatically mirror for RTL locales — layout_direction must be set explicitly per Control node or at the scene root. LocQA for Arabic and Hebrew in Godot includes verifying that all UI Control nodes correctly flip their layout direction and that text alignment follows RTL reading order.
Start Your Godot Engine Localization Project
Tell us your word count, target languages, and timeline. We’ll send a fixed-price quote within one business day.