Newnessimworks.com
Services · Practice 06

Multilingual websites built by people who actually speak the languages.

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.

Locales
LTR and RTL — any language
Translation
Human translators, not machine
Stacks
WordPress · Next.js · Payload · custom
Cultural layer
Beyond text — images, photography, iconography
What you get

Deliverables, no surprises.

Locale architecture

01

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.

Translation workflow

02

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.

RTL interface layer

03

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.

Locale-correct typography

04

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.

Per-locale QA pass

05

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.

Cultural localization

06

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.

How we work

5 phases. Same team start to finish.

  1. 01

    Scope

    Week 1

    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.

  2. 02

    Architecture

    Week 2

    URL strategy, content model, language-switcher behavior, fallback rules. Decisions made before the build starts so they aren't paid for in retrofits later.

  3. 03

    Translation workflow

    Weeks 2–3

    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.

  4. 04

    Build + QA

    Weeks 4+

    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.

  5. 05

    Launch

    Final phase

    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.

Fit check

Who this is for — and who it isn't.

This works if
  • You have multilingual users and they're underserved by your current English-only site.
  • You serve a French-speaking or Arabic-speaking audience — healthcare, public agency constituents, diaspora communities, international members.
  • You've tried an auto-translate plugin and the output embarrassed you, broke layouts, or both.
  • You need Arabic done right — RTL, typography, mirrored components — not approximated.
This doesn't if
  • You want a one-click plugin solution — we don't sell those and we don't recommend them.
  • You don't actually have multilingual users yet and want to build for an audience that may not arrive.
  • You want machine translation only — that's a different vendor; we don't compete on that.
Engagement

Pick the shape that fits.

Discovery + architecture

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.

Most engagements

Full multilingual build

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.

Build + translation operations

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.

FAQ

Questions we hear most.

Do you do auto-translate or human translation?

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.

What does cultural localization mean beyond translation?

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.

How does RTL implementation actually work?

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.

Can you take an existing English site multilingual?

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.

Which languages and writing directions do you support?

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.

Do you provide translators or do we?

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.

What about SEO for each locale?

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 first

Talk to us about your engagement.

Discovery calls are free. Scope, timelines, and pricing are quoted after we understand what you’re solving.