Arabic Game Localization, Engine-Level

Inscryption mixes UI.Text and TMP_Text across its interface — and Unity's two font-loading paths each break the other one. Font.CreateDynamicFontFromOSFont produces a working dynamic atlas that UI.Text needs, but its source-file path is null, so TMP_FontAsset.CreateFontAsset throws. new Font(absolutePath) gives TMP what it needs but kills the dynamic atlas, so UI.Text reports no Arabic glyphs. Either path alone leaves half the game broken.

The fix was a two-font architecture: keep both Font objects alive in parallel and route each consumer to the one it actually works with. TMP integration is registered as a fallback — Latin renders from the host font, Arabic from the registered Arabic fallback — instead of a direct font swap that would have lost Latin entirely. The shaping library was rewritten as cluster-based RTL so tashkeel (U+064B–U+0652) stays attached to its base letter through reversal.

5,807 entries translated through the hybrid localization workflow, integrated via a BepInEx plugin with Harmony patches into the game's Russian language slot. Published on Nexus Mods.

The Outer Worlds 2 ships in twelve official languages — Arabic isn't one of them. Obsidian's UE5.4 build uses Zen Loader / IoStore for game data, plus a parallel legacy pak format the game mounts alongside. Most modders working on UE5 fan localizations don't see the second pak; font replacement attempts fail because they assume IoStore is the whole story.

Full localization end-to-end: ~1.03 million words translated through the hybrid localization workflow, IoStore container repacking via retoc and UAssetGUI for the text layer, and a parallel legacy pak built with UnrealPak for font replacement across six font slots. UE 5.4's native HarfBuzz handles Arabic shaping and bidirectional ordering at runtime — the engine work is in the container plumbing, not the text shaper. Published on Nexus Mods.

Supergiant ships on a proprietary C++/Lua stack with no Arabic pipeline — strings sit next to game logic, fonts are bound at build time, and the existing localization layer wasn't built for RTL or Arabic glyphs. Going to a full Arabic build meant engine-level integration, not a file swap.

Roughly 456,000 words translated and shipped end-to-end through the hybrid localization workflow, with engine integration running in parallel: dialogue, UI, system messages, fonts, RTL behavior — all of it inside the build, not handed back as a CSV. Published on Nexus Mods as a fan project.

MSBT is Nintendo's proprietary binary format used across first-party Switch titles. No off-the-shelf toolchain handles Arabic inside it — strings are length-prefixed, encoded for Nintendo's runtime, and break the moment you touch them without understanding the structure. Off-the-shelf localization tools don't reach this far.

45,000 entries parsed out of MSBT, translated through the hybrid localization workflow, and reintegrated cleanly so the game loads them at runtime — length-prefix preserved, encoding intact, RTL behavior correct in-build. Published as a fan project.

MegaCrit's Slay the Spire 2 ships on Godot 4.5.1 with C# .NET 9. Localization data is bundled inside a 1.85 GB Godot PCK v3 archive — strings, fonts, scenes, and theme resources all packed into one container. Godot 4 has known RTL quirks: setting LayoutDirection to RTL doesn't right-align RichTextLabel paragraph text, and the engine's font fallback chain doesn't traverse cleanly to Arabic glyphs without engine-level intervention.

Full localization end-to-end: ~45,000 words translated through the hybrid localization workflow, the PCK v3 container reverse-engineered to extract source without unpacking the full 1.85 GB bundle, and a custom C# Harmony mod injecting Arabic font fallback into Godot's ThemeDB and patching MegaLabel and MegaRichTextLabel for runtime RTL alignment. Five Harmony patches in a 12 KB DLL. Published on Nexus Mods.

GameMaker Studio 1.x has a deserved reputation for fighting localization. Strings are baked into compiled data files, the runtime doesn't expose a clean text layer, and font handling assumes Latin glyphs. A lot of indie titles still ship on GameMaker, so pretending the engine doesn't exist isn't an option for serious Arabic work.

Full localization end-to-end: string extraction from the data files, font work for Arabic glyphs, RTL handling, translation through the hybrid localization workflow, and clean reintegration into the GameMaker runtime. Published as a fan mod.

Mobius Digital ships Outer Wilds with roughly eleven official languages. Arabic isn't one of them. The localization stack is closed — XML-driven, asset-bundle-bound, with no hook for an RTL language the game was never designed to accept. Adding Arabic meant pushing a non-supported language into that stack from outside.

The work was three-fold: matching Unity 2019.4.27f1 exactly so font asset bundles load (any other build version and they fail), writing a custom RTL fixer function inside the game's XML localization API, and running the full translation through the hybrid localization workflow. Published as a fan project.

A Team Cherry game update broke the existing Arabic mod for Silksong. The translation itself — produced by Play in Arabic — was intact, but the runtime hooks for RTL and alignment no longer matched the new build. The mod stopped working until someone reverse-debugged what changed and shipped fixes against the updated version.

That's the work this case study covers: alignment fixes and post-update repair across 39 iterations of SilksongRTL.dll, from broken to shipping again on the current build. Translation credit belongs entirely to Play in Arabic. The repair skill is its own discipline — and the exact problem any studio hits when a patch breaks their shipped Arabic build.