Running a multilingual Odoo Website is where slug quality quietly breaks. When you publish a page in Arabic, Chinese, Russian, Greek, or Urdu, Odoo's native slugifier tends to strip non-Latin characters and fall back to a numeric or dash-heavy stem like /ar/page/12 — which is poison for organic search, share previews, and human readability. Native website.seo metadata lets you set titles and descriptions per page, but it gives you no governed, per-language URL strategy: you cannot reliably transliterate مرحبا-بالعالم into a readable Latin marhaba-bil-alam, keep a native-script slug where you actually want one, or guarantee that the same page carries a stable, non-colliding slug across each active res.lang. Teams end up hand-editing slugs page by page, which does not scale and drifts the moment a content editor re-saves a page.

This is what we build. The module adds a per-language URL layer on top of website.page and Odoo's ir.http routing so every published page resolves to a clean, translated-or-transliterated slug in each active language. Technically, we introduce a translatable slug field (fields.Char(translate=True)) driven by a compute/@api.depends chain over the page title and target res.lang, backed by a configurable transliteration engine — Unicode-aware romanization tables (ICU / unidecode-style mappings we ship inside the module data) plus per-language override rules you control from a settings view. A _slugify_transliterate() helper is wired into the page save flow and exposed to editors, so slugs are generated deterministically rather than typed by hand.

On the routing side we extend the controller/ir.http layer so incoming requests match the correct page by its localized slug, and we register 301 redirects (via website.rewrite) from any prior slug so you never lose accumulated link equity when a slug changes. Uniqueness is enforced with a per-language SQL constraint plus a collision-resolution strategy (numeric or contextual suffix) so two pages can never fight over the same localized path. Everything respects Odoo's multi-website and multi-company boundaries, and localized <link rel="alternate" hreflang> tags plus the XML sitemap are updated to emit the transliterated URLs, which is the part search engines actually reward. Access is governed through ir.model.access.csv and record rules so only website editors can alter slug rules. The engine runs identically on Odoo 17.0, 18.0, and 19.0 (Community and Enterprise), and remains scriptable through the standard XML-RPC/JSON-RPC API for bulk slug regeneration.

Because this is build-to-order, nothing ships until we agree on scope. After a short scoping call we confirm your target languages, transliteration conventions, redirect policy, and edge cases, then build against that specification with UAT on a staging database before go-live. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); additional languages, per-language custom romanization rulesets, multi-company or multi-website deployment, and bulk migration of existing slugs at volume increase the quoted scope. You receive a fixed quote after the scoping call — never a blind fixed price.