Arabic Game Localization, Engine-Level

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.

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.