Skip to content
DenkSoft
Web Design

Seven Technical Traps When Building a Kurdish and Arabic Website

Building a multilingual site does not end with translating text. Unless direction, fonts, number formats and search-engine signals are handled together, the site ends up “translated” but unusable.

8 min read

Kurdish (Sorani) and Arabic are written right to left. Opening a site to these languages requires more than adding a translation file. The seven points below are the ones that cause the most trouble in practice and are the easiest to overlook.

1. Direction flips the layout, not just the text

When you switch to an RTL language, the text does not merely align right; menu order, arrow direction, margins and the direction of progress bars all have to change. A design built on fixed “left margin” values breaks in RTL. The fix is to use direction-aware (logical) spacing and alignment, so the same code behaves correctly in both directions.

  • Use start/end instead of left/right.
  • Arrows and “next” icons must be mirrored in RTL.
  • The starting edge of horizontally scrolling lists changes.

2. Font choice: if letters do not join, the text is unreadable

Arabic and Kurdish letters connect to one another. When a font chosen for the Latin alphabet does not support that joining, the browser falls back to a substitute and the text looks both ugly and hard to read. These languages need their own font family and a correctly ordered fallback list. When a fallback font slips in, the problem is usually misdiagnosed as “the font is not being applied”.

3. Numbers and dates: which digits, which format?

Whether Arabic content shows numbers in Arabic-Indic digits (١٢٣) or Latin digits (123) is a choice — and it must be consistent. Mixing both on the same page erodes trust. Date order, the decimal separator and where the currency symbol sits relative to the text also change by language.

4. Telling search engines which URL belongs to which language

On a site where the same content exists in four languages, the search engine needs to know which URL to show for which language. That is achieved with language-URL mapping (hreflang) and a canonical URL per page. Left incomplete, the pages are treated as copies of each other and none of them ranks as it should.

  • Every language version must reference the others reciprocally.
  • A fallback mapping should be defined for the default language.
  • The sitemap must include all language versions.

5. The translation gap: half-translated is worse than untranslated

If the interface is translated but product descriptions remain in Turkish, the user assumes the page is broken. Translation completeness therefore has to be checked technically: which text field is missing in which language should be reported automatically. Otherwise a missing translation only surfaces when a customer notices it.

6. Content entry: the admin panel must be multilingual too

If the site is multilingual but the admin panel is not, every new piece of content gets entered in one language only and over time the site drifts back to being monolingual. The panel needs language tabs for each text field, so that adding a service or a post does not quietly skip the other languages.

7. The language-switching experience

A user switching language should not be dumped on the home page; they should land on the same page in the new language. Making the selected language visible in the URL also helps both sharing and search visibility. It looks like a small detail, yet it is among the most complained-about aspects of multilingual sites.

Conclusion

A multilingual site is not a site built four times; it is one system behaving correctly in four languages. Planned from the start, the additional cost of the points above is small. Retrofitted later, it usually means revisiting both the design and the content structure.

Message us on WhatsApp