CUSTOM THEME DEVELOPMENT

WordPress Themes Built for Arabic and English, with RTL Architecture at the Foundation

Ignited Nepal builds custom WordPress themes for Qatari organisations and international brands publishing in Arabic, English, or both. Native Arabic RTL layout as a theme architecture decision, not a plugin override. Bilingual Gutenberg block library, design token system, ACF field groups for parallel Arabic and English content streams, and performance-first builds handed over with editorial documentation for both languages.

Request your Theme Development Brief → View the evidence →
Native Arabic RTL as a theme architecture decision · Bilingual Arabic/English Gutenberg block library · Design token system with Arabic typography considerations · WCAG 2.1 AA accessible HTML
This is for you if

Who This Is For

Your current WordPress site was built without Arabic as a first-class language. The Arabic content sits on an English layout with a direction switch applied by a plugin. Typography, spacing, and component alignment were designed for left-to-right reading and feel off in Arabic. Navigation elements, buttons, and form fields do not mirror correctly. You need a theme where Arabic RTL is built into the foundation, not retrofitted onto an English layout.

You have a WordPress site in English and you are adding Arabic to reach Qatari and GCC audiences. A translated version of your English theme is not the same as an Arabic-first design. Arabic typography has different size conventions, different letter-spacing requirements, different line height preferences, and a layout direction that affects every visual component. You need a bilingual theme that treats both languages with equal design attention.

Your content team publishes in Arabic and English and they are currently working around a system that was never designed for bilingual publishing. Arabic content may be going into the same fields as English content with manual direction overrides, or your editorial process requires developer involvement for tasks that should be editorial. You need a content architecture and block library that makes bilingual publishing as straightforward as single-language publishing.

What's broken

What's Broken

Your RTL Implementation Is a Plugin Override, Not a Foundation

The most common approach to Arabic on a WordPress site built for English is to install an RTL plugin that applies a direction swap to the stylesheet. The result is a site where most things are approximately right but component alignment, icon placement, number formatting, and form field layout have edge cases that the plugin did not anticipate. RTL implemented at the theme architecture level, with the layout grid, component design, and stylesheet all written for both directions from the start, does not have these edge cases.

Your Arabic Typography Is Using English Parameters

Font size, line height, letter spacing, and optimal line length all have different conventional values for Arabic text compared to Latin text. A stylesheet tuned for English body text will produce Arabic paragraphs that are either too small, too tightly spaced, or at an uncomfortable line length. Arabic display text has different size relationships to body text than Latin display text does. These are not aesthetic preferences; they affect legibility and the perception of editorial quality.

Your Bilingual Content Architecture Is Undefined

Publishing in Arabic and English requires a decision about how the two language versions relate in the content model: are they translations of each other stored as related posts via a plugin, parallel custom fields within a single post, or separate post types entirely? Each approach has different implications for editorial workflow, URL structure, hreflang implementation, and how the block library is structured. Most bilingual WordPress sites in the GCC have never made this decision deliberately.

Your Gutenberg Blocks Were Not Designed for Arabic

A block library built for English-language publishing carries assumptions about text direction, text density, and component layout that do not hold for Arabic. Pull quote blocks, card components, navigation patterns, and icon-with-text layouts all require RTL-specific design decisions. A block library that was not designed with Arabic in mind will produce predictable output in English and unpredictable output in Arabic.

What we engineer

What We Do

Design Token System With Arabic Typography Considerations

We build a design token layer that defines your colour palette, spacing system, border values, and separate typography tokens for Arabic and Latin character sets. Arabic font size conventions, line height, and letter spacing values are defined as named tokens distinct from the Latin typography scale. Every component references the correct token set for the language it is rendering.

Native Arabic RTL Architecture

We build the theme's layout grid, component library, and stylesheet with RTL as a first-class layout direction, not an override. The CSS logical properties approach, using start and end rather than left and right, produces correct layout for both Arabic and English without separate stylesheets. Navigation mirroring, icon placement, form field alignment, and button positioning are all designed for both directions from the first line of code.

Bilingual Arabic and English Gutenberg Block Library

We build a custom Gutenberg block library designed for bilingual Arabic and English publishing. Each block holds both Arabic and English content as separate, parallel field inputs. The block renders the correct language based on the active site language, using the correct typography tokens and layout direction for each. Editors can populate both languages in a single editing session without switching interfaces or applying manual direction overrides.

Block Pattern Library

We build pre-composed block patterns, full page sections assembled from your custom bilingual blocks, that editors can insert and populate without making layout decisions. Common section types, hero layouts, feature grids, testimonial rows, and call-to-action panels are available as single-click insertions with your brand applied and both language slots ready to fill.

ACF Field Groups for Bilingual Content Streams

We build Advanced Custom Fields field groups to support your bilingual content architecture. Whether Arabic and English are managed as post translations, parallel custom fields, or separate post types, the ACF implementation supports the editorial workflow you need and the URL and hreflang structure that is correct for your SEO requirements. Every field is documented in both Arabic and English.

SCSS Architecture

We organise the theme's stylesheet as a modular SCSS codebase with partials for tokens, typography, layout, components, and utilities, with logical property usage throughout for RTL correctness. The architecture is documented so any developer can navigate and extend it without needing to understand the RTL implementation from first principles.

Performance Optimisation

We optimise the complete asset load: Arabic and Latin fonts loaded with correct font-display strategies, no unused JavaScript, CSS scoped per component, images in modern formats with srcset attributes, and Core Web Vitals verified before handover. Arabic font files can be large; the loading strategy is a deliberate performance decision, not a default.

Accessible HTML

We build to WCAG 2.1 AA with attention to Arabic-specific accessibility requirements: correct lang and dir attributes for all content, appropriate reading direction for screen reader navigation, sufficient colour contrast across all token combinations, keyboard navigation that works correctly in RTL context, and focus states that are visible in both layout directions.

Git Handover and Editorial Documentation

We hand over on Git with a clean commit history, a developer README covering the token system, RTL architecture, block library, and bilingual content model, and editorial documentation written for your content team in both Arabic and English.

Request your Theme Development Brief →
What changes

What Changes

Before
After
Before The most common approach to Arabic on a WordPress site built for English is to install an RTL plugin that applies a direction swap to the stylesheet. The result is a site where most things are approximately right but component alignment, icon placement, number formatting, and form field layout have edge cases that the plugin did not anticipate. RTL implemented at the theme architecture level, with the layout grid, component design, and stylesheet all written for both directions from the start, does not have these edge cases.
After Arabic content on a theme where RTL is a first-class layout direction reads and presents correctly because every component was designed for it. There are no edge cases from a direction-swap plugin, no misaligned icons, no form fields that open in the wrong direction, no navigation that mirrors inconsistently. The Arabic experience is as intentional as the English experience.
Before Font size, line height, letter spacing, and optimal line length all have different conventional values for Arabic text compared to Latin text. A stylesheet tuned for English body text will produce Arabic paragraphs that are either too small, too tightly spaced, or at an uncomfortable line length. Arabic display text has different size relationships to body text than Latin display text does. These are not aesthetic preferences; they affect legibility and the perception of editorial quality.
After A block library where each block holds both Arabic and English as parallel fields means your editorial team publishes both languages in a single editing session, in the same interface, without manual direction overrides, without switching between language-specific admin panels, and without developer involvement for tasks that are editorial. Bilingual publishing becomes an editorial capability, not an operational complexity.
Before Publishing in Arabic and English requires a decision about how the two language versions relate in the content model: are they translations of each other stored as related posts via a plugin, parallel custom fields within a single post, or separate post types entirely? Each approach has different implications for editorial workflow, URL structure, hreflang implementation, and how the block library is structured. Most bilingual WordPress sites in the GCC have never made this decision deliberately.
After A design token system with separate Arabic and Latin typography tokens means your brand is expressed consistently in both languages, with the correct typographic conventions for each. Arabic headings are not simply larger versions of the Latin body font; they are sized, spaced, and weighted according to Arabic typographic convention, defined as tokens and applied automatically.
Before A block library built for English-language publishing carries assumptions about text direction, text density, and component layout that do not hold for Arabic. Pull quote blocks, card components, navigation patterns, and icon-with-text layouts all require RTL-specific design decisions. A block library that was not designed with Arabic in mind will produce predictable output in English and unpredictable output in Arabic.
After RTL implemented at the theme architecture level, using CSS logical properties, does not depend on a plugin to stay working. Plugin updates do not break your layout. A WordPress core update does not create RTL regression. The directional behaviour of the theme is structural, stable, and maintainable by any developer who understands standard CSS.
How it works

Process

  1. 01

    Discovery and Bilingual Architecture Review

    We review your current site, brand guidelines, Arabic and English content requirements, editorial team workflows, and any existing bilingual configuration. We audit your current RTL implementation for the structural issues that need solving and make a recommendation on bilingual content architecture before development begins.

  2. 02

    Token System, RTL Architecture, and Component Design

    We define your design token system including separate Arabic and Latin typography tokens, specify the CSS logical properties approach for RTL layout, and design the component set for your bilingual block library. You review and approve before development begins.

  3. 03

    Theme Development

    We build the theme: SCSS architecture with logical properties, bilingual Gutenberg blocks, block patterns, ACF field groups, RTL-correct templates, and performance optimisation. All development happens in a staging environment. Your live site is undisturbed throughout.

  4. 04

    QA and Bilingual Testing

    We test every block, pattern, ACF field, and template in both Arabic and English. We verify RTL layout correctness at every viewport breakpoint, check Arabic typography rendering on Windows and macOS environments, run Core Web Vitals audits, and verify WCAG 2.1 AA compliance including Arabic-specific accessibility requirements.

  5. 05

    Handover, Documentation, and Launch

    We deploy to production, hand over on Git with a full developer README, and deliver editorial documentation in both Arabic and English. We are available for two weeks post-launch for questions that arise in real bilingual editorial use.

Request your Theme Development Brief →
Common questions

Frequently asked questions about Custom Theme Development

What is the difference between RTL as a theme architecture decision and RTL via a plugin?

An RTL plugin works by applying a CSS direction swap after the fact, inverting the layout of a theme built for left-to-right reading. The result is approximately correct in most places but produces edge cases wherever the original theme made explicit left or right positioning decisions, which every theme does. RTL built into the theme architecture uses CSS logical properties throughout, so start and end replace left and right in every layout rule. The layout is inherently direction-aware from the first line of CSS, producing correct results for both Arabic and English without exception handling.

How do you handle Arabic typography differently from Latin typography in the token system?

Arabic and Latin text have different conventional relationships between font size, line height, and letter spacing. Arabic body text typically requires a larger font size than Latin body text at the same nominal size to achieve equivalent visual weight and legibility, and Arabic display text has a different proportion to body text than Latin display equivalents. We define separate typography tokens for Arabic and Latin character sets, with size, line height, and letter spacing values set to the correct conventional values for each. Components reference the token set that matches the language they are rendering.

How do you implement hreflang correctly for a bilingual Arabic and English WordPress site?

Correct hreflang implementation for a bilingual site requires that every Arabic-language URL has a hreflang annotation pointing to its English equivalent and vice versa, and that both point to themselves with the correct language and region code. For Qatar specifically, hreflang="ar-QA" for Arabic content targeting Qatar and hreflang="en-QA" or hreflang="en" depending on your English audience scope. We implement this as part of the bilingual content architecture, whether through a translation plugin's built-in hreflang output or through a custom implementation in the theme for post type architectures where plugin output is insufficient.

Which Arabic fonts work best for WordPress editorial contexts?

For body text in editorial contexts, Noto Sans Arabic and Noto Naskh Arabic are reliable choices with good legibility across device types and operating systems, available via Google Fonts with subsetting support. For display and heading text, IBM Plex Arabic and Almarai offer clean modern presentation. For more traditional or cultural contexts, Scheherazade New and Lateef provide a more classical Arabic aesthetic. The right choice depends on your brand and content type. We advise on font selection as part of the token system design step and implement the loading strategy that minimises performance cost.

Can the bilingual block library support content where Arabic and English versions are different rather than direct translations?

Yes. The parallel-field block approach stores Arabic and English content as independent fields within the same block, so an editor can write different content, different emphasis, different examples, or different length in each language, rather than treating one as a translation of the other. This is particularly useful for brands where the Arabic-speaking audience and the English-speaking audience have different contexts or information needs. The URL and hreflang structure is configured to signal the relationship between the two versions to search engines correctly regardless of whether the content is a direct translation.

Start here

Arabic Content on Your WordPress Site Should Be Built for Arabic, Not Translated Into It

A bilingual theme where RTL is a foundation rather than an override, where Arabic typography has its own token system, and where your editors can publish in both languages without working around a system that was never designed for it is a different product from a translated English theme. We build the foundation correctly. Send us your brief.

Request your Theme Development Brief →