For a bilingual editorial product — articles, projects, services, all with per-locale titles and bodies — you have two indexing options: one index per locale, or one index with per-document locale keys. The right answer depends on how your users actually search.

One index per locale

Cleaner ranking, no cross-language noise, and each index can carry locale-specific stop words and synonyms. Downsides: cross-locale features (an Arabic user typing an English brand name) need explicit handling, and you carry two indexes to keep in sync.

One shared index with locale keys

Users searching in either language hit the same result set. This is exactly what you want when the content is genuinely bilingual and users mix languages in a single query — which they do, all the time, on Saudi products.

The tradeoff is ranking: without care, an Arabic query can rank English matches too highly because the English body is longer and denser. Filtering by the query language (detected server-side or by locale header) fixes most of the pathological cases.

The practical stack

For most portfolios the shared index wins. Split the title/excerpt/body per language in the searchable payload, keep a language filter attribute, and detect the user's language on ingestion of the query — not on the client. Reserve the split-index pattern for products where each locale has substantially different content, not just translations.