LTR and RTL multilingual delivery for any language your audience reads — inclusion is the goal, not text translated over a Western design. The team has direct fluency in English, French, and Arabic; other languages we deliver through partnerships with native-fluency translators. RTL languages (Arabic, Hebrew, Persian, Urdu) get right-to-left treatment for real — typography, bidirectional layout, mirrored components, locale-specific accessibility — not a CSS flip applied to an English design. Cultural localization gets the same care as engineering: images with target-language text, photography that fits the local context, iconography without foreign cues. Built for public agencies, healthcare practices, mission-driven nonprofits, and associations whose users actually need their languages.
URL strategy (subdir, subdomain, or domain per locale), content modeling that treats each locale as a first-class record, language-switcher behavior, and fallback rules for partially translated content. Decided in week one so the rest of the build doesn't have to be retrofitted.
Handoff format for the translator (export structure, glossary, style guide), review and sign-off cycle, and version control so an English copy edit doesn't silently invalidate the French and Arabic versions. Set up to run after we leave, not just during the build.
Bidirectional CSS, mirrored components and iconography where mirroring is correct, logical properties throughout, and pattern-by-pattern review of forms, navigation, tables, and mixed-direction content (RTL languages with embedded English terms, numerals, URLs). Applies to Arabic, Hebrew, Persian, Urdu, and other right-to-left languages.
Arabic font stack with proper shaping and diacritic support, French typographic conventions (non-breaking spaces before punctuation, guillemets where appropriate), and font loading tuned per locale so each language reads as native — not as a translation of English layout.
Manual review per locale by someone who reads the language, screen-reader pass per locale (screen readers behave differently across languages), keyboard navigation in RTL, and a launch checklist that signs off each locale individually rather than the site as a whole.
Per-locale image selection, iconography, and photography — content that fits the audience's cultural context, not Western stock with translated captions. Arabic-language site photography uses Arabic signage and culturally appropriate visual cues; French, Spanish, and other locale sites get the same culturally informed treatment. The principle: localization is content plus culture, not text-only.
Which locales, which content, who owns translation sign-off, what the editorial cadence looks like after launch. Written multilingual plan and a fixed scope at the end of the week.
URL strategy, content model, language-switcher behavior, fallback rules. Decisions made before the build starts so they aren't paid for in retrofits later.
Translator onboarded, glossary and style guide drafted, handoff and review cycle set up. Translation kicks off in parallel with build so neither blocks the other.
Locale-aware build across the chosen stack, RTL pattern work for Arabic, cultural content adaptation, per-locale QA as content lands. Weekly check-ins with the translator and the stakeholder.
Per-locale sign-off, multilingual SEO basics (hreflang, locale-aware sitemaps, canonical strategy), redirect plan for any existing locale URLs, and a handoff so the editorial team can run the translation workflow without us.
Locale scope, URL strategy, content modeling, translation workflow design. Written plan you can hand to any builder.
Best fit:You have an internal team or another agency doing the build and need the multilingual architecture decided first.
Architecture, build, RTL implementation, per-locale QA, launch. Translation managed inside the engagement.
Best fit:You want the whole multilingual delivery owned by one team end to end.
Full build plus ongoing translation operations — content updates, new pages, editorial review cycles across locales as your content changes.
Best fit:Your content changes often and you need locale parity maintained, not just delivered once.
Pricing is scoped after a discovery call.
Human translation. Auto-translate gets you most of the way and the last stretch is where the embarrassing errors live — the ones that misstate a clinical instruction, garble a legal disclosure, or mistranslate a community name. For the audiences we serve, that gap is the difference between a site that works and one that doesn't. We use human translators with subject-matter context and a review cycle.
Translation is the first layer. Real multilingual delivery also handles the visual and cultural layers — images with text in the target language (not English signage with subtitles), photography that reflects the audience's cultural context (not Western office stock for an Arabic-language site), iconography that doesn't carry foreign cultural cues, dates and numbers formatted per locale, and content sensitivity that matches the audience. For an Arabic site, we'll source photography with Arabic signage and culturally appropriate visual context — not a CSS-flipped English page with translated text overlaid. That's what real inclusion actually looks like.
Bidirectional CSS using logical properties, components reviewed pattern by pattern for whether they should mirror (navigation, progress indicators) or not (logos, media controls, numerals in some contexts), per-locale typography with proper shaping and diacritic support (Arabic in particular, but also Hebrew, Persian, Urdu), and per-locale QA by someone who reads the language. The same patterns apply to all RTL languages — not a direction: rtl rule applied to an English design and called done.
Often, yes — depending on the stack and the content model. Some platforms localize cleanly; others need the content model rebuilt first because they treat translations as duplicated pages rather than locale variants of one record. The discovery engagement tells you which situation you're in and what the path forward costs before you commit to the full build.
Any. Technically we deliver LTR (Latin-script languages: English, French, Spanish, German, Portuguese, Italian, etc.) and RTL (Arabic, Hebrew, Persian, Urdu, etc.) with the same locale-aware engineering and cultural localization approach. Our team has direct fluency in English, French, and Arabic — for other languages, we partner with native-fluency translators for the content side and apply the same engineering and cultural work on our side. The architecture scales; the translation and cultural layer scales by adding the right human.
Either. We have translators we work with for English, French, and Arabic, and we'll bring them into the engagement if you don't have your own. If you already have a translation vendor or in-house bilingual staff, we set up the workflow around them — the architecture, glossary, handoff format, and review cycle.
Locale-aware sitemaps, hreflang implementation, canonical strategy per locale, and per-locale metadata. Search engines treat each locale as a separate surface; the SEO work is per locale, not a single pass at the end. For engagements that continue past launch, ongoing SEO support per locale lives under the SEO & Online Visibility practice.
Discovery calls are free. Scope, timelines, and pricing are quoted after we understand what you’re solving.
