Arabic Game Localization, Engine-Level

Arabic localization, integrated at the engine level.

Translation is one stage. The integration that makes it ship — RTL, glyph shaping, font pipelines, runtime QA — happens inside the engine. Unity TMProOld via reflection, Unity 6 + BepInEx runtime, Unreal 5.4 / 5.6, GameMaker 1.x, Godot 4.5.1, C++/Lua, Switch MSBT, Divinity 4, ForzaTech (NoesisGUI) — a multi-agent pipeline drafts at scale; engine-level integration ships the result. Engines not listed — Cocos, Defold, Bevy, custom — start with a scope review. If the integration is buildable, I'll quote it. If it isn't, I'll say so in the same email.

12 Projects shipped
5M+ Words
8 Engines shipped on

Why Arabic?

You don't see this audience in your Steam dashboard. Arabic isn't a supported Steam interface language, so MENA demand doesn't surface in default analytics — studios shipping Arabic early are first-movers in their genre by the time anyone else notices.

Roughly 420M Arabic speakers worldwide. MENA-3 alone (Saudi Arabia, UAE, Egypt) has 85.8M gamers and reached $2.2B in 2025 revenue per Niko Partners — growing 8.5% year over year. Saudi Arabia's Public Investment Fund has $38B committed to gaming through Savvy Games Group. UAE adult gamer ARPU sits at $84.60 — among the highest globally. Niko's 5-year forecast puts MENA-3 at $2.8B by 2029.

One concrete signal from a third-party publisher: Capcom's FY26/3 sales data places Saudi Arabia in its second-highest market tier (100,000+ annual unit sales) — same tier as Australia, ahead of Russia. That's a single Arabic-speaking country reaching a major publisher's high-revenue tier on its own. Saudi is one entry point — the Arabic-speaking region spans 22 countries. Source: Capcom FY26/3 Earnings Supplement (slide: Sales Strategy — Global Sales Expansion).

What keeps most games out of that market is the language layer. Arabic translation alone isn't enough — RTL direction, glyph shaping, and font pipelines have to behave inside the engine, and studios often skip it for that reason. The integration work is the gap, not the audience.

That's the market. The rest of the site is about the person doing the work, and how to start a project.

Featured Work

Flagship

Baldur's Gate 3 — Full Arabic Localization (Fan Mod)

Divinity 4 wasn't built for Arabic. Now it renders it correctly.

Most Arabic mods for Western RPGs fail at the same place: runtime. The translation files exist; the engine renders them as disconnected letters, reversed words, or fallback-font boxes where the shaper gave up. The work was done — the engine just doesn't know what Arabic is.

Divinity 4, Larian's proprietary engine, was built for left-to-right scripts. Making it render Arabic correctly meant engine-level integration: bidirectional text, contextual letter shaping, RTL handling in UI, and font work to preserve the original visual feel. That happened alongside translation, not after handoff.

The multi-agent pipeline produced the draft at scale — 2.52 million words through the workflow — while integration ran in parallel inside the build. The mod renders the way the game was meant to read, which is the bar that matters.

Words
2.52M
Engine
Divinity 4
Scope
Engine integration
Status: Published on mod.io · View on mod.io

Forza Horizon 6 — Full Arabic Localization (Fan Project)

A closed first-party engine that stores its fonts as GPU meshes and ships no Arabic shaping. The binary formats were reverse-engineered from scratch to put Arabic on screen.

ForzaTech is Playground Games' in-house engine, with a UI layer built on NoesisGUI/AVUI. It had never been publicly reverse-engineered — Arabic requests from the community had sat unanswered for years with no tooling delivered. Strings live in a custom binary string-table format. Fonts aren't TTF: they're a proprietary .vfont/.vfont0 pair that stores every glyph as a pre-built GPU mesh. And nothing in the engine expects a right-to-left script — no Arabic shaping, no BiDi.

Every format was reverse-engineered with byte-identical roundtrip verification — the string tables across all 287 files, and the mesh-font formats from scratch. A TTF-to-mesh generator builds engine-valid Arabic glyphs (395 across the Arabic and Presentation-Forms-B ranges), reshaping and BiDi were added where the engine had none, and the locale archives were repacked slot-preserving around the engine's silent integrity checks. ~387,000 words translated end-to-end through the hybrid localization workflow and shipped inside the build — dialogue, UI, system text, fonts, RTL — not handed back as a CSV. Published on Nexus Mods as a fan project.

After it shipped, translators working in other languages asked how it was done. The engine's text and font formats had no public documentation, so I reverse-engineered and published them as an open toolkit — any language community can now localize a ForzaTech game.

Words
387K
Engine
ForzaTech · NoesisGUI
Fonts
.vfont GPU mesh
Status: Published on Nexus Mods · View on Nexus Mods · Engine docs on GitHub

Inscryption — Full Arabic Localization (Fan Mod)

Two-font Unity rendering on an engine that exposes Arabic through neither path cleanly.

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.

Words
37.5K
Engine
Unity 2019.4.24f1
Architecture
Two-font + TMP fallback
Status: Published on Nexus Mods · View on Nexus Mods

The Outer Worlds 2 — Full Arabic Localization (Fan Mod)

Two pak archives. One is the engine's official future; the other is the legacy format the game still mounts. The Arabic build ships into both.

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. Text goes through IoStore; font replacement goes through the legacy pak. Both archives have to ship for Arabic to render correctly.

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.

Words
1.03M
Engine
Unreal Engine 5.4
Architecture
Dual-pak
Status: Published on Nexus Mods · View on Nexus Mods

Mixtape — Full Arabic Localization (Fan Mod)

Unreal Engine 5.6 split its container layout. The locres lives in the legacy pak — but the loader won't mount it without an IoStore trio sitting next to it.

Beethoven & Dinosaur's Mixtape ships on UE 5.6 with both Zen Loader / IoStore for cooked assets and a parallel V3 legacy pak holding the .locres, .locmeta, ICU data, and .ufont files. The translatable text is entirely in the legacy pak — but UE 5.6's loader refuses to mount a V3 pak alone for this game. The Arabic build ships the translated locres in a V3 pak alongside empty IoStore stubs (.ucas, .utoc) generated against UE 5.6's specific zen format — UE 5.3 / 5.4 / 5.5 stubs fail the version check.

Full localization end-to-end: ~17,600 words translated through the hybrid localization workflow across 2,721 locres entries spanning 64 namespaces. 64 .ufont files swapped to Noto Kufi Arabic. Translator credit injected directly into the locres (no byte-patching) so it renders on the main menu and pause screen. Feminine grammar applied throughout for the female protagonist's player-directed text. A five-phase audit pass (structural, meta-leak, English-leak, anomalies, and a song-citation phase covering bracket loss in [TRACK] patterns) caught 31 defects before ship. Published on Nexus Mods.

Words
17.6K
Engine
Unreal Engine 5.6
Architecture
IoStore stubs + V3 pak
Status: Published on Nexus Mods · View on Nexus Mods

Hades II — Full Arabic Localization (Fan Mod)

~456,000 words of Arabic on Supergiant's proprietary C++/Lua engine.

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.

Words
456K
Engine
C++/Lua
Scope
Engine integration
Status: Published on Nexus Mods · View on Nexus Mods

The Legend of Zelda: Tears of the Kingdom — Full Arabic Localization (Fan Project)

~778,000 words translated and reintegrated across 45,000 MSBT entries on a closed Switch format.

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.

Words
778K
Format
Switch (proprietary)
Entries
45,000 MSBT
Status: Published on Nexus Mods · View on Nexus Mods

Slay the Spire 2 — Full Arabic Localization (Fan Mod)

Five Harmony patches in a 14 KB DLL. Arabic ships into a 1.85 GB Godot PCK without modifying the bundle — text via the game's native override system, RTL and font fallback via runtime patching.

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 for analysis, with translations delivered through the game's native localization override directory rather than repacking the bundle. A custom C# Harmony mod injects Arabic font fallback into Godot's ThemeDB and patches MegaLabel and MegaRichTextLabel for runtime RTL alignment. Five Harmony patches in a 14 KB DLL. Published on Nexus Mods.

Words
45K
Engine
Godot 4.5.1 · C# .NET 9
Patches
5 Harmony
Status: Published on Nexus Mods · View on Nexus Mods

MOUSE: P.I. For Hire — Full Arabic Localization (Fan Mod)

Unity 6's bundle writer drops bytes on round-trip. Arabic ships anyway — via BepInEx, an IL transpiler against the dialogue async state machine, and a runtime font fallback chain.

Unity 6 introduced a ManagedReferencesRegistry v1 metadata block that current open-source bundle writers can't preserve — round-tripping resources.assets through UnityPy or AssetsTools.NET silently loses 9,088 bytes across twelve distinct metadata regions. Static bundle patching isn't viable on this engine version. The Arabic build instead overwrites only the localization string-tables bundle (which round-trips cleanly) and does everything else at runtime: a 9 KB BepInEx 5 plugin creates a Dynamic SDF Arabic TMP_FontAsset, walks every loaded TMP_FontAsset via Resources.FindObjectsOfTypeAll, and appends the Arabic font to each fallback table — with a re-walk on SceneManager.sceneLoaded for fonts spawned later.

Full localization end-to-end: ~57,500 words translated through the hybrid localization workflow across 139 Unity Addressables string tables. A HarmonyX IL transpiler targets the dialogue async state machine (OnScreenDialogueController.<DisplayText>d__15.MoveNext) and rewrites the speaker-line concatenation so the speaker tag survives Arabic shaping. Font work uses sh-blabeloo with a custom cmap mapping Forms-B codepoints (U+FE80–U+FEFC) onto base glyphs; GSUB and GPOS tables stripped to prevent context-dependent substitution corruption against pre-shaped input. Published on Nexus Mods. Ships with Su4enka's BepInEx Unity 6 compatibility patch, included with explicit written permission from the author.

Words
57.5K
Engine
Unity 6 · BepInEx · HarmonyX
Architecture
Runtime IL transpiler
Status: Published on Nexus Mods · View on Nexus Mods

Undertale — Full Arabic Localization (Fan Mod)

GameMaker 1.x bakes strings into compiled data files and assumes Latin glyphs. Arabic ships anyway.

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.

Words
107K
Engine
GameMaker 1.x
Approach
Data-file extraction
Status: Published on Nexus Mods · View on Nexus Mods

Outer Wilds — Full Arabic Localization (Fan Project)

Arabic added to a localization stack that wasn't built to accept it.

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.

Words
52K
Engine
Unity 2019.4.27f1
Approach
Custom RTL fixer
Status: Published via Outer Wilds Mod Manager · View on outerwildsmods.com

Hollow Knight: Silksong — Full Arabic Localization (Fan Mod)

A Unity 6 game whose text runs through a forked, legacy TextMeshPro that was never built for a right-to-left script. Arabic is shaped and reordered at build time, before the runtime renders a single line.

Silksong runs on Unity 6 (6000.0.50f1), but its text doesn't go through stock TextMeshPro — it runs through a forked version living in the engine's own TMProOld namespace, with a legacy font schema and no dynamic font fallback. Dialogue, UI, and item text are driven from compiled asset bundles and flat YAML string tables, and none of that pipeline expects a right-to-left language.

Full localization end-to-end: 93,491 words extracted from the string tables and translated through the hybrid localization workflow in Modern Standard Arabic, then a build-time RTL transform that reshapes each line into Presentation Forms, reverses it per segment, masks placeholders and Latin runs, and preserves every engine tag so line breaks and page markers survive intact. A decompile of the game's own assembly settled where line breaks are converted — eight methods inside the game code, not the injector — so wrapping and reordering run at build time instead of fighting the runtime. A gender-consistency pass keeps the female protagonist addressed correctly across thousands of lines, alongside dialect and terminology passes over the full corpus. Reintegrated into the Unity runtime via BepInEx and published on Nexus Mods.

Words
93K
Engine
Unity 6 · TMProOld
Approach
Build-time RTL transform
Status: Published on Nexus Mods · View on Nexus Mods

Every project on this page was unpaid. I built this body of work without a contract behind it because the engine-level layer of Arabic localization isn't a category vendors are competing for yet — and the only way to prove the work was to ship it. From here, the work happens under contract.

How I Work

01 / Workflow

The Workflow

Translation runs through a multi-agent pipeline — a structured drafting system with multiple specialized passes, engineered for scale and consistency across thousands of strings. This is one stage of a larger, hybrid workflow.

The load-bearing stages come after: engine integration and technical QA. Drafting produces text; the rest of the pipeline is what makes that text ship correctly inside a game.

02 / Integration

Engine Integration

Engine integration runs in parallel with translation, not after handoff. The work happens inside the build: RTL behavior, font selection and fallback, character encoding, tag and variable preservation, and format-level work for closed binaries — Unity asset bundles, Switch MSBT, GameMaker data files, custom containers.

This is where most Arabic builds break, and where most localization vendors stop at a CSV. A string that translates cleanly in a spreadsheet still has to render correctly at runtime; getting it there is the part of the service that justifies the rest.

03 / QA & Maintenance

Technical QA & Maintenance

QA is a runtime check on the technical layer: does Arabic render, does it align, does the line break, does the font fall back, does the tag survive the engine. Reading text in isolation doesn't catch what only surfaces in a running build. Every project includes 30 days of technical maintenance after launch at no additional cost — if a patch breaks rendering, if a build update surfaces a regression, fixes are included. Beyond 30 days, maintenance continues on a paid retainer.

This is technical maintenance, not linguistic. A line that reads awkwardly post-launch is a separate scope, not a defect.

Service tiers and add-ons are below.

Services

Three engagement models, sized to where the build actually is. Under contract, integration is source-level — commits or patches that merge into your codebase, or a self-contained module, whichever fits your pipeline. The runtime-patch approach in the fan mods above is a constraint of fan modding (no source access), not the engagement model.

Entry · Pilot

Pilot

Integrated demo

For studios who want Arabic running in their actual build before committing to a full engagement. 1,000 words translated and integrated into a runnable, time-limited demo build — RTL, font fallbacks, glyph shaping, all working in the engine. Pipeline assets and source patches stay with the full engagement scope. If you continue, the pilot fee credits in full against the project. Includes 30 days of technical maintenance on the demo build. Delivered in 7 days.

$500 · 1,000 words · Credits to full engagement

Start a pilot
Default

Full Localization

End-to-end engagement

The default engagement model. Full script translated through the hybrid localization workflow, integrated at the engine level, and run through technical QA across menus, dialogue, UI, and edge cases. Includes 30 days of post-launch technical maintenance. Timeline scopes to wordcount and engine — most projects land between 4 and 10 weeks.

Scoped per project

Discuss your build
Time-critical

Rush Delivery

Under-two-week turnaround

For time-critical drops — patches, ports, and launches inside a two-week window. Every rush starts with a scope review: I look at the build, the wordcount, and the engine before committing. Same engine-level integration and technical QA as the full tier. Includes 30 days of post-launch technical maintenance.

Available upon scope review

Request a scope review

Paid add-ons

Linguistic review pass

An editorial pass not included in the default workflow. For studios who want a review layer on top of the multi-agent pipeline output. Available by request, scoped per project.

Maintenance retainer

Ongoing technical support past the included 30-day window. Monthly retainer covers RTL regressions, font issues, and build-incompatibility fixes triggered by patches and engine updates.

About and contact below.

I'm Hesham, based in Saudi Arabia. Every project on this site was run by me — translation, engineering, QA, final build. No subcontractors, no handoffs. The queue stays small on purpose: one or two projects at a time, scope locked before a contract is signed. If a job is too big for one person, I'll say so before you commit.

Under contract, the working model is the same as the projects above — one person, full stack, no handoffs — but with a written scope, fixed timeline, and source-controlled deliverables. If something blocks shipping, you hear it within 24 hours, not at the deadline.

Engagements run on a written scope, with NDA signed before any build is shared. Payment is staged: 50% on scope-lock, 50% on final delivery. Source patches and integration code transfer to the studio on final payment — no per-build licensing, no ongoing dependency on me. If your legal team needs custom terms, that conversation happens before scope-lock, not after.

Contact

Tell me what you're shipping. The more concrete the message, the more concrete the reply. First response within two business days — usually a couple of clarifying questions and an indicative timeline. NDA available before any build is shared.

Game name, engine, and email required.

— Hesham