Arabic Game Localization, Engine-Level

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: ~72,000 strings 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 400,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. Confirms the BG3 work isn't a one-off; this is the same engine-level approach at full RPG scale.

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.

47,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. The work demonstrates reach into closed proprietary formats most vendors won't touch — the same format-level commitment that real engine-level Arabic actually demands.

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: 6,749 entries 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. Proves the engine list in the hero isn't aspirational — GameMaker 1.x ships Arabic when someone is willing to do the engine work it requires.

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. Engine-level Arabic on a stack whose own localization system never planned for it.

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.