A German, English and Arabic website: architecture, localization and RTL

German is the main commercial route for a company selling in Germany; English can serve international teams, and Arabic can serve founders in Europe, Middle Eastern buyers or German companies communicating with Arabic-speaking customers. Language is not a country: do not treat all Arabic readers as one market.

For each version, define the supported service, currency context, response language and content owner. A translated enquiry flow that nobody can answer creates an operational mismatch. Decide whether the offer is genuinely equivalent or needs a market-specific page before creating language links.

Research search language through customer interviews, actual query data and the terms used in procurement. A German query about having a website built is a buying question; an English technical query about RTL may be a developer’s implementation question. They can belong to the same topic cluster without requiring the same headline.

Give a page an internal identity separate from its visible title or slug. Store shared structure, assets and dates once, then join them to localized titles, text, metadata and link labels. This site uses a static multi-page build with English at the root and German and Arabic under their own prefixes.

A build should fail on missing translation keys, unknown internal link targets and missing assets. It should not silently fall back to English text inside an Arabic article. Keep equivalent content types across languages while allowing each locale to explain the subject naturally.

Subdirectories are a practical option for one company domain. Country domains or subdomains may make sense for separate operations, but they add governance. Choose for ownership and delivery constraints, not for an unsupported claim that one URL scheme ensures better search positions.

Use a self-referencing canonical for each fully localized document. The language alternatives describe the matching versions; they are not a reason to canonicalize German and Arabic to English. Provide reciprocal links that include each document itself and an appropriate x-default.

Keep the same cluster in the page head and sitemap if your build emits both, deriving them from one route registry. Hreflang mistakes are usually data problems: a missing sibling, a redirected target or a link to the homepage instead of the equivalent article. Test addresses and response codes as well as tag syntax.

Do not create automatic redirects based solely on IP or browser language. Offer a clear language choice and preserve the current page when switching. A visitor in Germany may deliberately want Arabic.

German readers may need a precise Leistungsumfang, delivery responsibilities, net-price assumptions and operational support. An Arabic reader considering the German market may need the relationship between local implementation and Arabic communication explained. English copy for a product team can use a more direct technical vocabulary.

Keep facts equivalent while changing the explanation. Names, published dates and calculated examples should not drift between versions. FAQs can be written naturally around each market’s terminology as long as they answer the same underlying concerns.

Build a small glossary for product names, industry terms and CTAs. Test titles and search snippets as standalone text: they appear outside the page’s direction context. Do not litter prose with invisible direction controls to repair a layout issue.

Set semantic direction at document or component level and use logical CSS for flow-relative spacing and borders. Then audit the layers logical properties do not control: transforms, icon meaning, source order, bidirectional runs, clipping and text splitting.

A backward arrow usually follows navigation direction; a play icon or a recognizable product logo usually does not. Keyboard order follows the DOM, so a visually mirrored layout can still feel wrong when tabbing. Avoid fixing a direction problem with arbitrary row reversal or a CSS order that contradicts the reading sequence.

Numbers, phone links, URLs and code need deliberate handling. Isolate Latin runs where needed, keep code left-to-right, and test the combination rather than translating a whole interface and hoping the browser resolves it.

.article-layout { gap: 2rem; padding-inline: 1rem; }
.callout { border-inline-start: 3px solid currentColor; }
.technical-run { direction: ltr; unicode-bidi: isolate; }
.code-block { direction: ltr; text-align: start; }

The measured boundary is documented in the RTL defects logical properties do not cover.

Select an Arabic family for actual reading, not because it looks visually similar to the Latin family. Check weight, line height, diacritics, numerals and Latin fallback. Arabic letter shapes depend on their neighbors; splitting a word into independent animated boxes can break shaping.

Give Arabic paragraphs a comfortable measure and test full text on a narrow screen. A line-height value that works in Latin may clip or crowd Arabic marks. A font fallback may unexpectedly capture Latin characters and change the look of mixed text. These are measurable questions.

This site’s technical articles preserve the original experiments on joining, line height and font metrics. Read them as recorded implementation evidence, then measure the fonts and runtime used in your own release.

For animated text, read why character splitting breaks joined scripts.

For reading rhythm, see the measured Arabic line-height floor.

For font pairing, see Arabic and Latin font metrics.

A shared template reduces drift, but an editorial workflow prevents it. Assign review responsibility per locale, record substantive updates and test equivalent links. A source change should make affected translations visible to the editor rather than silently publishing outdated text.

Budget translation, localization, asset alternatives and QA separately. A diagram containing embedded English text may need a localized companion; a code snippet may remain identical but its explanation should not. Prices and legal statements need an explicit review owner.

Keep image dimensions reserved and load below-the-fold media lazily. Load fonts needed for the current language rather than every family on every page. Avoid a translation or chart library when the static build can generate the required content.

Check the same route at small mobile, tablet and desktop widths. Switch languages from deep in an article and confirm that the destination is its equivalent. Test heading order, TOC, focus, forms, tables, numbers and code. Read the Arabic text with a native reader rather than relying on geometric checks alone.

Crawl every internal link and verify canonical and alternative addresses. Confirm that error pages and server endpoints behave as intended. Search the production output for staging hosts, missing assets and old contact details.

After launch, use language-specific search and enquiry data to decide what to improve. A complete multilingual experience is an ongoing publishing responsibility, not a one-time translation purchase.

For implementation: Explore the relevant service.