Arabic text with English product names

A camera catalogue promotes ArcView+ inside an Arabic heading. The English word looks familiar, but the plus sign appears at its other end: +ArcView. That is a different product label from the one the catalogue supplied, even though copying the text can return the intended string.

Most plain English names already display correctly inside Arabic sentences. The failures emerge at their boundaries: a terminal symbol, a numeric prefix, or a quantity that becomes visually attached to the name. A product name also needs to survive translation tooling without preventing the surrounding Arabic copy from being translated.

Keep the complete name as one field, describe its direction and language, and mark its translation policy separately. The same field contract should hold in a campaign heading, a price sentence and a comparison button.

Reproduce the suffix moving inside an Arabic heading#

The heading contains a complete English product name between Arabic words:

Problem

<h2 lang="ar" dir="rtl">اكتشف ArcView+ اليوم</h2>

The name's displayed sequence becomes +ArcView. The intended reading is an Arabic invitation surrounding the intact name ArcView+. Its plus sign is part of the name, not punctuation that belongs to the heading.

Better

<h2 lang="ar" dir="rtl">  اكتشف <span lang="en" dir="ltr">ArcView+</span> اليوم</h2>

The English name now has its own directional boundary and retains the sequence ArcView+. The Arabic words remain in their RTL heading. A plain span without dir would not provide this isolation.

The rendering patterns used here were measured in Chromium 151 on September 24, 2026. Firefox and Safari were not included in those measurements, so verify these fixtures in your supported browsers.

Do not remove the suffix to make the heading look right. If the suffix distinguishes this camera from another product, removing it changes the label the customer uses to identify it. Repair the boundary while retaining the catalogue value.

Names that already look correct still need a component contract#

The unsuffixed name ArcView stays intact between Arabic words without extra markup. That makes it a poor fixture for demonstrating the suffix bug. It remains useful as a passing case when testing a shared component.

A digit-first name exposes another boundary problem:

<p lang="ar" dir="rtl">الكاميرا المختارة: 360-Orbit</p>

The displayed name becomes Orbit-360. The digits and hyphen do not establish the same LTR context as a Latin prefix. Wrapping the complete name with dir="ltr" keeps 360-Orbit in its intended order.

Do not maintain different rendering rules for names that currently seem safe. Catalogue names can gain model numbers, suffixes or punctuation. A field-level boundary describes the meaning once instead of asking every heading and button to infer the current string's bidi risks.

The W3C guidance for inline bidi markup recommends tightly wrapping complete opposite-direction phrases. In this catalogue, that phrase is the whole English name, including its punctuation and intrinsic numbers.

This is a policy for known English product names. If a field can contain an Arabic localized name or another script, do not hard-code every value as English LTR. Keep the field's language and direction metadata aligned with the selected catalogue label.

Direction, language and translation are separate decisions#

For a name that must remain in English, these attributes answer different questions:

Use all three when all three statements apply:

<p lang="ar" dir="rtl">  تعرّف على  <span lang="en" dir="ltr" translate="no">ArcView+</span>.</p>

Setting lang="en" alone does not isolate the name. Setting dir="ltr" does not identify its language. Setting translate="no" does not fix a displaced plus sign. These attributes complement each other rather than replace each other.

MDN documents dir as direction metadata and lang as language metadata. Keep them scoped to the name rather than applying English or LTR to the full Arabic component.

Some brand labels are coined names rather than ordinary English words. Use the language metadata supplied by your content policy where it is known; Latin script alone is not proof of English. The examples here explicitly assume English catalogue labels.

Do not set a component's language to English simply to select a font. Language metadata should describe the text. Font styling belongs in the stylesheet and can be targeted to the name component independently.

Protect the name without freezing the Arabic copy#

The HTML translate attribute communicates whether content should be translated. Put translate="no" on the protected name, keeping the Arabic description and action text outside it.

Applying it to a whole campaign heading or product card can also exclude the surrounding copy from translation. That is too broad when only the catalogue name is meant to stay unchanged.

Treat the attribute as metadata for tools that support it. It is not a guarantee that every localization service, extraction step or browser translation feature follows your policy. Test the actual workflow used to prepare the Arabic page. W3C's translate-attribute guidance explains how translation instructions can be scoped within markup.

A build-time translation pipeline may process message resources before the final HTML exists. In that workflow, a translate="no" span added at render time cannot protect a name that has already been translated or altered in the source resource. Keep the catalogue label separate and insert it through the localization system's supported placeholder mechanism.

Provide translator notes explaining that the placeholder is a product name and whether its suffix must remain exact. The surrounding Arabic sentence still needs review with the real name inserted, particularly where word order or grammatical agreement depends on the product category.

Check the final HTML as well as the translation resource. A correct resource can still lose its wrapper if a rendering layer turns a rich-text placeholder into plain concatenated text.

Keep intrinsic numbers inside the name and quantities outside#

A camera model can include a number as part of its designation, while a purchase quantity belongs to the Arabic sentence. Do not infer that every nearby number belongs to the English name.

This sentence leaves the quantity exposed to the Latin run:

<p lang="ar" dir="rtl">اشتر ArcView 4 كاميرات لتجهيز الاستوديو.</p>

The quantity can become visually associated with the preceding name instead of the Arabic noun it counts. Isolate the name alone:

<p lang="ar" dir="rtl">  اشتر <span lang="en" dir="ltr" translate="no">ArcView</span>  4 كاميرات لتجهيز الاستوديو.</p>

For a model designated ArcView Studio 72, the intrinsic model number belongs inside the name's boundary:

<p lang="ar" dir="rtl">  اشتر  <span lang="en" dir="ltr" translate="no">ArcView Studio 72</span>  4 كاميرات لتجهيز الاستوديو.</p>

Review that exact model-and-quantity sentence in the browser. The intended boundary is clear in the data: the designation includes its model number, and the order quantity is a separate field. A single span around both would preserve the wrong grouping.

Keep catalogue numbers exact where they are part of the name. Quantities can follow the interface's numeric formatting policy. Do not apply a global digit conversion to the entire sentence and accidentally change a model designation along with the purchase count.

This distinction also separates names from SKUs. A sellable variant code may identify a product record, but it should not be substituted for the reviewed display name merely to avoid mixed-language copy.

A localized product title can be larger than the name#

A catalogue field called title may contain an Arabic category, an English name and an Arabic feature description. That complete field is not an English product name merely because one part is protected.

This wrapper is too broad for the title it contains:

<h2 lang="en" dir="ltr" translate="no">  كاميرا ArcView+ بعدسة واسعة</h2>

It labels the Arabic words as English, assigns LTR to the whole title and marks the entire title as protected from translation. The intended protected unit is only the catalogue name:

<h2 lang="ar" dir="rtl">  كاميرا  <span lang="en" dir="ltr" translate="no">ArcView+</span>  بعدسة واسعة</h2>

The Arabic title owns the category and feature wording. Its inserted name owns the suffix and English metadata. Review the exact mixed title in supported browsers, including its wrapped layout.

Represent those roles in the content model where possible. A brand or model designation can remain a separate field while the translated title uses a placeholder for it. If a CMS instead stores one unrestricted mixed string, the renderer cannot safely find the protected name by assuming that every Latin substring is a brand. A title may also contain ordinary foreign-language wording, specifications or approved aliases.

Use structured fields or supported rich-text placeholders rather than a regular expression that wraps whichever characters resemble the current product name. Otherwise a changed name can leave an old fragment protected, or an identical word in the description can receive the name's metadata accidentally.

This is the limit of the English-name helper: it should receive the designation, not the full localized title. Keep that distinction in its callers and in the content editors' field descriptions.

Treat the price as a separate formatted value#

A price sentence contains several semantic units: the product name, the price and the Arabic wording that connects them. Making the whole sentence LTR to protect the name also changes the context of that Arabic wording.

Keep the boundaries local. This illustrative catalogue uses an explicitly LTR price label in this example:

<p lang="ar" dir="rtl">  تتوفر  <span lang="en" dir="ltr" translate="no">ArcView+</span>  بسعر <span dir="ltr">AED 2,680</span>.</p>

The name does not own the amount, currency or final full stop. Its plus sign does belong inside its wrapper. The price has a separate formatting contract and a separate value boundary.

For a localized currency formatter, preserve its complete output rather than copying this technical price style into every Arabic market. The relevant principle is separation of fields, not a universal currency order.

Test the price sentence when the amount changes, when a sale label appears and when the name changes to a longer model designation. The inserted offer text should not be moved inside the protected English name just because it appears next to it visually.

If a price sentence looks wrong, compare the name's exact string and the formatted amount independently before changing the entire component direction. A product label can be intact while a price is misformatted, or the reverse.

Buttons should keep the Arabic action and English name distinct#

A comparison button can express its action in Arabic while preserving the camera name:

<button type="button" lang="ar" dir="rtl">  قارن  <span lang="en" dir="ltr" translate="no">ArcView+</span></button>

Do not mark the whole button lang="en" or translate="no" just because it contains a protected name. The action is Arabic interface text. Only the name uses the English field contract.

Check the button's full accessible name as well as its visible label. An aria-label can replace the accessible name derived from visible text; a stale or untranslated attribute may therefore describe a different model even while the visible button is correct. MDN explains aria-label and when existing visible text can supply the name.

Where the native button's visible content already expresses its action, avoid maintaining a second manually assembled product label unnecessarily. If an attribute label is required, give it an explicit localization and update policy. HTML spans cannot be placed inside a plain-text attribute value to reproduce the same boundaries.

Also test compact buttons. Hiding the suffix or truncating the only distinguishing part of a product name can make two comparison actions look identical. Keyboard and screen reader checks establish action identity, while a visual check establishes that the displayed name remains readable.

Reuse a name renderer with a narrow contract#

Create a component specifically for known English catalogue names. Its callers should not have to remember the same metadata in every heading and button.

<section lang="ar" dir="rtl">  <h2 id="camera-heading"></h2>  <button id="camera-compare" type="button"></button></section>

Run this after the markup:

function englishProductName(name) {  if (typeof name !== "string" || name.trim() === "") {    throw new TypeError("Expected a nonempty English product name");  }   const value = document.createElement("span");  value.className = "product-name";  value.lang = "en";  value.dir = "ltr";  value.translate = false;  value.textContent = name;  return value;} function renderFeaturedCamera(name) {  const heading = document.getElementById("camera-heading");  const compare = document.getElementById("camera-compare");  if (!heading || !compare) throw new Error("Camera labels are missing");   heading.replaceChildren("اكتشف ", englishProductName(name));  compare.replaceChildren("قارن ", englishProductName(name));} renderFeaturedCamera("ArcView+");

The helper returns a new node for each occurrence because a single DOM node cannot occupy both locations. Both occurrences receive the same direction, language and translation metadata. textContent inserts the name as text rather than interpreting catalogue content as HTML.

The example demonstrates text composition, not the comparison action itself. In a live catalogue, bind that action to the selected product record. The displayed name is a label, not a substitute for its stable identity.

If the catalogue can select a localized Arabic name, use a renderer that accepts validated language and direction metadata from that content model. Do not send the Arabic name through this explicitly English helper. For genuinely unknown external labels, automatic isolation can be appropriate, with fixtures for their permitted content.

Preserve metadata through catalogue updates and translation builds#

A suffix bug can return after an otherwise correct first render. A product selector might replace the name's wrapper with a text node, or a rich-text translation renderer might drop its attributes while composing a new heading.

Test an update from the short base name to the suffixed name and then to the longer numbered model. Confirm that each occurrence is a complete name node with the same metadata after the update. Check headings, comparison buttons and any sticky purchase panel independently if they use different templates.

Do not embed directional control characters in the catalogue name to compensate for one template losing its wrapper. The stored field should remain usable for search, records and other interfaces. Repair the component that renders the value.

For server-rendered pages, inspect the initial HTML and the post-update DOM. A client-side correction that appears only after hydration can leave the first visible heading wrong. Conversely, correct server markup does not establish that later client updates preserve the same contract.

Also inspect the output of your translation build. Confirm that the name placeholder remains intact, the translated action stays Arabic, and the final element retains lang, dir and translation metadata. Testing only the helper function cannot establish those properties of a separate localization pipeline.

Check translation extraction before inspecting browser translation#

Choose one campaign heading and one comparison button from the fixture catalogue, then trace them through the actual localization workflow. Keep the selected product record constant so a naming change cannot conceal a translation change.

First inspect what the extraction step gives translators. Confirm that the name is either a documented protected placeholder or content carrying translation instructions that this tool supports. If the export contains only a flattened sentence, a later HTML attribute cannot restore the lost field boundary.

Next render the Arabic resource with the unchanged catalogue name. Inspect the inserted node's text and metadata, then review the full sentence visually. This separates a translator changing a protected label from a renderer losing its direction or language attributes.

Finally, if browser translation is part of the supported experience, test it on the rendered page as a separate workflow. Confirm that the name remains exact while surrounding text follows the selected translation behavior. Passing this browser check does not establish that a build-time resource extractor follows the same instructions.

Keep the fixture's expected label independent of the translated sentence. That makes an altered suffix visible in a text comparison even when the resulting heading still looks plausible. Use the browser review to establish reading order after character preservation has been checked.

Long product names need a wrapping decision#

Isolation controls directional interaction; it does not make a long name fit. A multiword model can wrap in a campaign heading while a comparison button has much less space.

Keep the suffix and model designation available wherever customers distinguish products. Do not solve a narrow layout by permanently removing + or the model's number from the stored label.

Avoid adding white-space: nowrap to every product name without checking the container. That prevents ordinary wrapping but can create overflow in a narrow card or button. MDN's white-space reference describes the wrapping behavior.

For prose and headings that must remain fully readable, allow wrapping and inspect the line breaks with the actual font. An unbroken imported name may need an overflow-wrap policy. A short suffix can be visually separated by a line break without the underlying string changing, so review whether the resulting label remains identifiable.

Where a compact component intentionally shortens a label, provide access to the complete name in an appropriate expanded or detail view. Do not rely solely on a hover interaction to reveal the distinction between products.

Test Arabic headings at supported zoom levels and narrow widths. Compare a correctly ordered but clipped name with a reordered name; those failures need different fixes.

Translation policy does not decide whether a name should be localized#

Preserving an English name is a content decision, not a universal rule for every brand or market. A catalogue may supply an approved Arabic name, a transliteration or an English name that must remain exact. Select the approved label first, then describe that label's metadata.

Do not use translate="no" as a reason to leave the surrounding product description or category label in English. A protected name inside Arabic copy is different from an untranslated paragraph of marketing text.

Keep alternative labels associated with the same product record rather than changing identity when the interface language changes. Search can support approved aliases under its own matching policy, while the rendered label follows the catalogue's selected name.

If content editors can replace a label, give them a field that records the naming policy instead of requiring them to paste HTML wrappers into the name itself. The component should own the markup. Editors should supply the exact name and any approved language information.

Review those choices with the people responsible for the catalogue and Arabic copy. Browser direction rules can preserve a label's sequence, but they cannot determine the commercially approved spelling or decide whether a particular name should be translated.

Verify the name in every sentence that uses it#

Build a camera fixture set with a plain Latin name, a suffix-bearing name, a digit-first name and a multiword model with an intrinsic number. Use the same values through the real catalogue surfaces.

Assert the catalogue string and final metadata, then review visible order in supported browsers. Copying and accessibility-tree inspection follow logical text order, so they cannot replace a visual check of the suffix. Check accessible wording separately where the name labels an action.

Repeat after catalogue selection changes, language switching and responsive layout changes. Keep one reviewed screenshot for each component context rather than assuming a passing product heading establishes the behavior of every button and price sentence.

For inserted English names, a free Ritla scan can report R021: Unisolated bidi hazards: phones, emails, Latin tokens inside Arabic text. R080 reports Intentional foreign-language runs missing a lang attribute; translation-tool handling and exact product identity still need the targeted checks above. Continue with Arabic and English mixed text for sentence composition or nested LTR content inside an RTL page for shared component boundaries.