Localization: An Engineering Decision, Not a Translation Job
Most teams discover localization the hard way: the product is built, launched, and doing well in one market, and then a second market opens up. Someone exports the interface text, sends it to a translator, pastes the results back in — and the layout falls apart. Buttons overflow, dates read as gibberish, and an Arabic sentence renders left-to-right against every instinct of the person reading it. The translation was fine. The software was never built to hold it.
That gap is where localization actually lives. Translating words is the visible 10% of the job; the other 90% is structural, and it has to be decided while the components are being written, not after. For an agency serving Canada, the Middle East, and Pakistan, this isn't an edge case — it's the default. Two of those three markets read right-to-left, and one of them makes a second language a matter of law. Building for one language and hoping the rest bolt on later is how you end up rebuilding.
Translation is the last step, not the whole job
The first thing a localizable product does differently is refuse to hardcode text. Every user-facing string lives in a resource file keyed by locale, never baked into a component, so a new language is a new file rather than a code change. That sounds obvious until you hit the parts that translation alone can't fix: pluralization and grammar. English has two plural forms; Arabic has six. A sentence like "you have 3 messages" can't be assembled by gluing a number to a noun — the surrounding words change with the count, and with gender. The standard answer is ICU MessageFormat, a syntax that lets translators express those rules per language instead of forcing English grammar onto everyone.
Formatting is the other quiet trap. Dates, numbers, and currency all differ by locale, and the browser already knows how to handle it through the built-in Intl API — as long as the code asks for a formatted value instead of stitching one together by hand. Get this right and 1,234.56 becomes ١٬٢٣٤٫٥٦ in Arabic and 1 234,56 in French Canada without a single conditional. Get it wrong and you're shipping the same bug in five places. Saudi Arabia adds a further wrinkle: the Hijri calendar runs alongside the Gregorian one, and financial and government contexts often expect both.
Right-to-left is a layout problem, not a text problem
The biggest misconception about Arabic and Urdu support is that it's about the text. It isn't — it's about the entire interface. In a right-to-left language, the navigation moves to the right, the progress bar fills the other way, the back arrow points the opposite direction, and a layout designed around "left" and "right" has to be mirrored wholesale. Do that by hand with per-language overrides and you've doubled your CSS and your bug surface.
The disciplined approach is to stop thinking in physical directions altogether. CSS logical properties — margin-inline-start instead of margin-left, inset-inline-end instead of right — describe layout in terms of where text begins and ends, and they flip automatically the moment you set dir="rtl" on the page. These have been safe to use without fallbacks across every major browser since 2021, so there's no real cost to adopting them from the first component. Not everything should mirror, though: phone numbers, brand logos, and media playback controls stay put, and text that mixes English and Arabic in one sentence needs proper bidirectional handling so it doesn't scramble. This is inclusive engineering in the same spirit as web accessibility — the quality is in the structure, not in a layer added at the end.
There's a typographic dimension too. Arabic and Urdu are cursive scripts whose letters change shape depending on their neighbours, so a font chosen for its Latin glyphs may render them badly or not at all. Choosing script-complete fonts and loading them without blocking the first paint keeps the experience fast — the same discipline that makes website performance pay off, applied to markets where fonts are heavier and networks are often slower.
In Quebec, a second language is the law
For Canadian-facing products, French isn't optional. Quebec's Bill 96 — an amendment to the Charter of the French Language — requires that commercial websites and apps reachable by Quebec residents present French content with prominence at least equal to any other language. The provision came into force on June 1, 2025, it applies to any business selling into the province rather than only those with a physical presence there, and the Office québécois de la langue française has begun issuing fines over English-only pages. A French link buried in the footer doesn't clear the bar; the French experience has to be as complete and as easy to reach as the English one.
That reframes localization from a growth tactic into a compliance requirement, and it rewards teams that built the seams in early. A product already structured for multiple locales adds French as configuration. A product that hardcoded English adds it as a retrofit — under a deadline that has already passed.
Build the seams in from the start
None of this requires a heavier stack; it requires a few decisions made up front. Route by locale so each language has its own indexable URL rather than a cookie that hides the translation from search engines. Detect the visitor's preference but always let them override it. Keep translations in a workflow that flags missing or stale strings before release, so a new feature can't ship half-translated. And test each language the way a native reader would actually use it, not by spot-checking that the page still loads.
Done this way, a new market is a launch, not a rebuild — the software already speaks the language, reads in the right direction, and formats the numbers the way the customer expects. If you're planning to serve Arabic, French, or Urdu audiences and want it engineered in rather than bolted on, the AppInnovative team can build it right from the first component — or tell you honestly what it takes to fix a product that wasn't.