Odoo in Arabic: What Arabic Support Actually Means

Ask a vendor whether Odoo supports Arabic and the answer is yes. The answer is also true. It is simply answering a question you did not ask.

What happens next is always the same. Someone changes their own user language, the screen flips over to the right, the menus come up in Arabic, and the room nods. That demonstration is real, and it proves exactly one thing: the interface has an Arabic translation and a mirrored layout. It tells you nothing about whether your customer will receive an invoice in Arabic, nothing about whether your product names exist in Arabic at all, and nothing about how a part number with a slash in it will look inside an Arabic sentence on a printed delivery note.

Our guide to Odoo in the UAE settles this subject in about a line: Arabic support is real, and it is not a switch. This is the long version of that line. Everything asserted below was checked against Odoo's documentation or its source, and the checks are listed at the end. Where we could not verify something, you will find a question to ask in the demo rather than a sentence we invented.

Three products hiding in one word

Separate these before you evaluate anything: they fail independently, and different people fix them.

The interface is the chrome: menus, buttons, field labels, the direction the screen runs in. It arrives with the software. Odoo holds languages as records, each carrying a direction, and the Arabic record that ships with the product carries right-to-left.

The data is what your company put in: product names, account names, unit names, the description that prints under the line. None of it arrives translated, because none of it arrived at all. Odoo will hold two languages for each of those values; it does not fill the second one in.

The document is what leaves the building. It is drawn by a different engine from the one drawing your screen, and its language is decided by a field on the customer record rather than by the person pressing print.

A demo shows you the first. Your customer receives the third. Nothing you saw covered the distance between them.

The interface: mirrored by a separate stylesheet, and it can silently fail to be

Right-to-left is not translation. The screen has to be mirrored — the menu moves to the right, the layout reverses, padding that sat on the left goes to the right.

Odoo does this by building a second stylesheet. When the current user's language is right-to-left, the framework compiles the normal stylesheet, pipes it through rtlcss — an external command-line tool — and stores the result as a separate asset bundle. Because the direction is read from the language of whoever is looking, two people on one database face in opposite directions at once. That is the ordinary case in a UAE finance team, and it works.

The failure is worth knowing. If that external tool is not present on the server, the code writes a warning to the log — You need rtlcss to convert css file to right to left compatibility — and returns the unmodified stylesheet. It does not stop and it does not raise. You get Arabic text in a left-to-right layout, which looks like a design flaw rather than a missing dependency, and the only record of the cause is a log line nobody is reading. Whether the tool is present depends on where your database runs and who built the server, so see the Arabic interface on the deployment you will actually run on — not on a laptop, and not on the vendor's demo instance.

The second interface question has no verifiable answer either. We will not tell you Odoo's Arabic translation is complete, because we have not audited it and neither has the person selling to you. Open the applications you will genuinely use — not Sales, which everybody demos, but inventory operations, maintenance, whatever your fourth application is. An untranslated label in a screen your storekeeper opens forty times a day is a training cost, and cheaper to find now.

The data: nothing arrives translated, and the gap is silent

This is where the disappointment lives, and it is entirely predictable. Odoo marks certain fields as translatable: on a product, the name and all three descriptions; the name of a unit of measure; the name of an account in the chart. A translatable value is stored per language, and the web client offers a control on the field for entering the other version.

Now the consequence nobody demonstrates. When a translatable value has no entry for the language being displayed, Odoo does not show a blank and does not raise an error. It falls back to the English value. That is right as engineering — an invoice with empty product names would be worse — and it produces a very specific failure in a bilingual company. Your customer's record says Arabic, your template is correct, and the invoice prints with headers, labels and terms in Arabic and the product names in English, because nobody ever typed them in Arabic. No test catches it, because nothing went wrong. The document is simply half of what was promised, and the first person to notice is the customer.

So bilingual master data is a project with an owner rather than a setting with a switch. It behaves like every other empty column in a migration — a question the old system never forced you to answer, arriving all at once — and it is one of the most under-scoped instances of that pattern.

Two disciplines make it survivable. Scope by document rather than by table: an Arabic name for an internal consumable nobody invoices buys nothing. And name the person who decides, because trade Arabic for a steel section, a cable gauge or a food additive is not general Arabic. The right term is a commercial decision — it is what your customer will quote back to you on the phone. A translator working without your sales manager in the room will produce something grammatical and wrong.

The document: a different engine, and a language decision that is not yours

Two facts about printed documents surprise nearly every buyer, and Odoo states both plainly.

The language of a document is a property of the counterparty, not of the user. A contact record carries a Language field, and Odoo's own help text says all emails and documents sent to that contact will be translated into it. The invoice report reads the partner's language and renders in it; the delivery note does the same, preferring the partner on the movement. So the Arabic invoice does not happen because a clerk was working in Arabic. It happens because somebody set a field on the customer, once, correctly — and it silently does not happen for every customer where nobody did. That field belongs in your master data cleanup, and it is routinely forgotten because nothing before Odoo depended on it.

A document is rendered in one language, not two. Odoo's developer documentation is explicit that the mechanism for rendering a report in the partner's language works only when calling an external template, and that you cannot translate part of a document by putting the language attribute on any other node. Read that twice if you have been promised a bilingual invoice. Arabic and English side by side is not a setting anyone switches on. It is a template somebody builds, and once built it is yours to carry across every upgrade: the ordinary trade set out in the boundary between configuration and customisation.

The screen and the page are drawn by different engines. Odoo's documentation states that PDF rendering is performed by wkhtmltopdf. Your web client is a modern browser; the PDF is not. Text that lays out perfectly on screen was laid out by different software from the text on the page your customer receives, and neither predicts the other. The document layout offers eight fonts, of which one — Tajawal — is documented as supporting Arabic and Latin scripts. Whether font, layout and engine together produce Arabic that reads correctly in your document is not something we will assert here. Print it, in Arabic, on the version you are buying.

Numbers and codes inside Arabic text

Now the defect class that catches people who did everything else right.

Arabic runs right to left. Numbers do not. When the two meet, the order in which characters appear is decided by the Unicode Bidirectional Algorithm, and what decides it is the characters with no direction of their own — the space, the slash, the hyphen, the bracket. The algorithm's own rule is that a sequence of these neutral characters takes the direction of the surrounding strong text when both sides agree, and that European and Arabic numbers act as right-to-left in their influence on those neutrals.

Read that again with a stock code in your hand. A product called PL-12/2026, a dimension written 1200 x 600, a ratio written 4 / 8: each is a small battleground of neutral characters inside an Arabic sentence, and the order they resolve to visually is not always the order you typed. The stored value stays correct throughout, so every server-side test passes — a test reads the value, not the pixels. The only instrument that detects this is a human looking.

Which is why the most valuable thing you can say in a demo is a request rather than a question:

Show me an Arabic delivery note, for a real customer whose language is set to Arabic, for a product whose name contains a slash and a number.

It costs ten minutes, and it tests the interface, the data, the template, the partner language field and the rendering engine in one artefact.

What to ask for, in these words

Structure the rest of the demo the same way — the Arabic supplement to the questions that separate a real vendor from a good presenter.

Ask for this	A weak answer sounds like	What you are actually testing
The Arabic interface on the hosting we will use	"It looks the same everywhere"	Whether the right-to-left stylesheet is generated on that deployment
Inventory operations and maintenance in Arabic, not Sales	The same two screens again, in Arabic	Translation coverage in the screens your staff live in
An Arabic invoice for a product we name, from our own list	A sample invoice built on demo data	Whether Arabic product names exist, and what prints when they do not
What a bilingual invoice would take	"We can do that in Studio"	Whether they know it is a template build with an upgrade tail
An Arabic document containing a code with a slash and a number	A screenshot	Bidirectional rendering in the engine that draws the page
Who writes the Arabic product names, and when	"We'll handle the translation"	Whether anyone has scoped the only part that is genuinely your work

The last row decides more outcomes than the other five together. A partner who has not asked who owns your Arabic terminology has not thought about Arabic — only about the language dropdown.

When Arabic is not negotiable, and when you are over-specifying

There is a version of this requirement that is a necessity, and a version that is an expensive habit. Companies buy the second while describing it as the first.

Where Arabic genuinely is non-negotiable, it is usually commercial. Government and semi-government customers specify it in the tender. Some corporate customers will not accept a delivery note their own receiving clerk cannot read — and they are right: a document nobody in the warehouse can read is not a control, it is paperwork. And if your staff read Arabic more comfortably than English, an Arabic interface is the difference between a system people use and one people work around.

Where companies over-specify, it is nearly always the same three ways. Translating an entire item master when a few hundred products carry the overwhelming majority of invoice lines. Insisting on bilingual versions of documents that never leave the building. Buying an Arabic interface for a finance team that has worked in English for fifteen years and will switch the language back within the week.

Whether the system has to work in Arabic as well as English is one of the drivers behind the ERP cost estimator, because it moves the template work, the data work and the testing work at once. Add it because a customer or a regulator requires it and the money is well spent. Add it because it seemed thorough and you have bought a second copy of every document to maintain.

The part that argues against hiring us

If all you need is an Arabic interface, you do not need an implementation partner. Installing a language is a documented administrative action that takes minutes, and any competent administrator can do it. Paying a consultancy for that is paying for a search result. If all you need is one Arabic invoice template, that is a small, well-defined piece of work people in this market will do for a fraction of an implementation engagement — and we would say so in the meeting.

If your customers are European trading houses, Indian suppliers and free zone entities that correspond entirely in English, our particular differentiator earns you nothing. Choose on what will decide your outcome — sector depth, upgrade discipline, who does the work — which is what choosing an Odoo partner is about.

And a harder one. We cannot write your Arabic product names. We can write the Arabic around them — the documents, the terms, the notices, the training material — but the word your customer uses for a specific grade of steel or a specific food ingredient lives inside your company and nowhere else. If nobody in your business will own that glossary and sign it, do not buy the bilingual scope at all. You will pay for a column that stays empty, and Odoo will quietly print English into it.

What we will claim, and nothing more

One thing, plainly: we write Arabic rather than translating it. The Arabic on your documents is composed as Arabic — its own structure, its own connectives, its own professional register — rather than passed word by word through a tool from an English sentence written first. Anyone who reads Arabic professionally can tell the difference in two lines, and every customer of yours who reads Arabic will be doing exactly that when your first invoice arrives.

We are not claiming an outcome from it, or that it is rare. We are claiming it is checkable, which is why this article exists in Arabic as well as English. If that version does not read as Arabic that was written rather than converted, disregard the claim.

Where this leaves you

Arabic in Odoo is not one capability with one answer. It is an interface that arrives with the product and depends on a component being present on your server; master data that arrives empty and falls back to English without complaint; and documents drawn by an older engine, in a language chosen by a field on your customer record.

The foundation is genuinely there, and against products where Arabic is a bolted-on afterthought that matters in this market. What is not there is the part that is yours: the terms, the templates, the customer language field, and somebody who looks at the printed page. Two instructions carry most of the value. Make the vendor print you an Arabic document containing a code with a slash and a number, on the version you are buying. And name, before you sign anything, the person who decides what your products are called in Arabic.

If e-invoicing is also in scope, that is a separate discipline with its own deadlines, set out in what UAE e-invoicing requires of your system. We have deliberately not stated what those formats require of language, because we could not verify it; put that question to your Accredited Service Provider in writing.

If you want the Arabic scope defined honestly before it is priced — including the parts we think you should not buy — that is part of what we do on an Odoo implementation.

Source note

All of the following was checked on 26 August 2026.

From the Odoo 19.0 documentation: that emails and documents sent to a contact are translated into that contact's language is the help text on the contact's Language field; that reports render in the partner's language, that this works only when calling an external template and cannot translate part of a document, and that PDF rendering is performed by wkhtmltopdf are in the developer documentation on reports; the eight document fonts, including Tajawal supporting Arabic and Latin scripts, are in the PDF reports documentation.

From the Odoo 19.0 source: language records carry a direction field, and the Arabic record ships right-to-left; the right-to-left stylesheet is produced by piping the compiled CSS through the external rtlcss tool, with a logged warning and the unmodified stylesheet returned when that tool cannot be run; translatable values are stored per language and fall back to English when the active language has none; the product name and descriptions, the unit of measure name and the account name are declared translatable; the invoice report takes its language from the partner on the invoice, the delivery note from the partner on the movement.

The behaviour of numbers and neutral characters inside right-to-left text is from Unicode Standard Annex #9, the Unicode Bidirectional Algorithm, revision 51, dated 13 August 2025. The language obligation is the article on language in UAE Federal Decree-Law No. 28 of 2022 on Tax Procedures, in the English text published by the Federal Tax Authority. Product behaviour changes between versions and tax obligations change by amendment; confirm both before relying on them.