Skip to main content
Building an Arabic-first Odoo theme that remains editable

Building an Arabic-first Odoo theme that remains editable

An Arabic Odoo theme should not be an English layout flipped at the end. It starts with Arabic content, reading order, typography, and the way editors build pages. It still has to support the website builder, ecommerce, translation, and future Odoo upgrades.

A page can look good in one screenshot after a large CSS patch. The harder test is whether an editor can change it, the shop and forms work in both directions, and the next Odoo update does not force a rewrite.

Decide whether a theme is necessary

Use standard website settings when the brand can be represented through existing colors, type, and building blocks. A custom theme makes sense when the product needs distinct components, editable business-specific snippets, Arabic commerce patterns, several coordinated presets, or versioned behavior that should ship as one module.

Changing one font and button color is not enough reason to create a new theme.

Treat the theme as an Odoo module

Keep the manifest, data, QWeb views, assets, translations, and images inside a clear module boundary. Extend Odoo templates through inheritance. Do not edit core website or web files.

This matters during upgrades. An inherited view can be reviewed against a changed parent. A direct core edit is easy to lose and hard to explain.

Start with a small token system

Define brand colors, surfaces, text colors, focus styles, spacing, radii, shadows, and typography before building pages. Connect these choices to Odoo and Bootstrap variables where possible.

Use an Arabic family with the weights that actually ship, and pair it with a Latin family after comparing x-height and visual size. A numeric 16px does not look identical in every script.

Load only needed files. Self-hosted WOFF2 assets and limited weights reduce network work and give the release a stable dependency.

Use logical CSS properties

Write margin-inline-start, padding-inline, border-inline-start, and inset-inline-end instead of duplicating left and right rules. Set the document dir correctly and let layout adapt.

Direction is not only alignment. Breadcrumb separators, progress arrows, carousels, icons with meaning, number fields, email addresses, and mixed-language product names all need review.

Use dir="auto" for user-generated strings when the first strong character should determine direction. Use bdi to isolate a short name or identifier inside a sentence with another direction.

Build snippets for editors

A useful snippet has editable text and images, safe defaults, responsive behavior, and options that a content editor can understand. Keep the markup semantic so navigation and headings still make sense without styling.

Do not hard-code important content into SCSS pseudo-elements or JavaScript. The website builder cannot translate or edit it reliably.

Test the full storefront

The home page is only one template. Review product lists, filters, product details, variant selection, cart, checkout, account pages, search, empty results, form errors, and long translated labels.

Test at narrow widths with realistic Arabic titles. Fixed card heights and hover-only controls usually fail here. Controls that appear on hover must also be reachable by keyboard and touch.

Keep JavaScript modest

Register behavior through Odoo assets and follow the framework conventions for the target version. Avoid a large animation bundle for an effect that CSS can deliver. Respect reduced motion and prevent scripts from blocking editing mode.

The theme is finished when editors can use it, users can navigate it in both languages, and the code can be installed and reviewed as a normal Odoo module. A polished home page alone is not that proof.