Software localization adapts a software product — its UI strings, documentation, and user-facing content — for specific target markets and languages. For game developers, software localization and game localization are the same workflow: exported string files, professional translation with Translation Memory, and verification in a working build. SandVox provides software localization for game developers, game engine plugins, developer tools, and consumer-facing applications with a technical user base.

Software Localization vs. Document Translation

Software localization is structurally different from document translation. Documents are self-contained — translate the text, return the document. Software localization requires: String file processing — translating structured data files (.po, .xliff, .json, .resx) where strings are referenced by ID, not sequential position. Placeholder handling — format strings containing variables ({name}, %s, {0}) must preserve placeholders in the correct syntactic position for the target language. Plural form handling — different languages have different plural rules (Russian has four forms, Arabic has six) requiring language-specific plural form configuration. Character encoding — software must use UTF-8 consistently to render all scripts correctly. Build verification — the translated strings must be verified in the running software, not just in a file editor, because rendering and layout issues are only visible in the actual product.

String File Formats in Software Localization

Software products use a wide variety of string file formats depending on the development stack. Common formats SandVox handles: .xliff (ISO standard, used by Xcode, Unity, custom engines), .po / .pot (GNU gettext, used by Godot, Linux software, web frameworks), .json (web applications, i18next, React Native), .resx (.NET applications, Unity), .strings (Apple iOS/macOS), .xml (Android), .arb (Flutter), .yaml (Ruby on Rails, various frameworks), .csv (custom engines, spreadsheet-based pipelines). SandVox processes all of these formats using memoQ’s native filters and Okapi Framework for non-standard formats, returning translated files in the exact format and structure received.

Technical String Handling

Software strings contain technical elements that require careful handling during translation. Format placeholders (printf-style %s/%d, Python {name}, C# {0}) must be preserved exactly — a missing or incorrectly positioned placeholder causes a runtime error, not just a visual issue. HTML and markup embedded in strings must not be altered — only the human-readable text between tags should be translated. Non-breaking spaces and special characters must be preserved where they affect rendering. String context matters: ‘Cancel’ in a dialog box translates differently than ‘Cancel’ as a verb in a sentence. Context notes and screenshots provided before translation begins prevent ambiguity that would otherwise require re-translation. SandVox’s QA workflow includes automated placeholder validation and tag checks via Xbench before delivery.

In-Build Verification for Software Localization

File-level QA on string files catches translation and formatting errors — it cannot catch how those strings render in the actual software. In-build verification is the stage where translated files are imported into a working build and the software is run in each target locale to verify: layout integrity (translated strings fitting their UI containers), font rendering (especially for CJK and RTL locales), locale-sensitive formatting (date formats, number formats, currency display), and functional behavior in localized flows. For developer tools and game engines, in-build verification often requires domain knowledge of the software’s own architecture — SandVox’s team includes engineers familiar with major game engine localization pipelines and developer tooling.

Frequently Asked Questions