What LocalizationHub reads

Six short pages on the engines, formats and systems behind the workspace: what is read directly, what needs a tool you configure, and what is still partial. Each one is written from the same tested record the compatibility notes use.

• Godot, read as it shipsA Godot project keeps its text in very different places: CSV tables, PO catalogues, scene properties, scripts, JSON databases, and — in some games — a custom binary story format. Each one is read as its own surface, never as “some strings in a folder”.
• Unreal, read from its own localisation containersUnreal keeps text in LOCRES containers, metadata sidecars and exported tables, then packs them inside archives. LocalizationHub reads the containers itself and orchestrates a verified tool only where the archive format requires one.
• Unity, through a helper you configureUnity text lives in Localization tables, TextAssets and serialized assets that only a type-aware reader can see. The text surfaces are read directly; the binary ones are handed to a pinned UnityPy helper.
• JSON and CSV, without guessing which string is textA JSON file is not a translation file. The analyzer reads structure you can point at, and when your schema uses its own field names you map them — instead of hoping the tool guessed right.
• Gettext PO and POT, with references intactPO is the format translators already know: msgctxt disambiguation, translator comments and source references. LocalizationHub keeps all of it when it reads the file, and writes it back on export.
• Translation memory that stays in the projectMatching runs against the memory inside the project you already have open. Nothing is uploaded to look for a suggestion, and no memory is shared with anyone you did not invite.

Statuses come from the project’s tested compatibility record. Every “read directly” line was validated against real game files or fixtures; partial support is written as partial, and an external tool is named as a tool you configure yourself.