Your Arabic title is not corrupted — the store is reading it in a different direction

When an Arabic, Persian or Urdu title arrives at a store with the bracket on the wrong side, the "feat." credit pushed to the far end, or a catalogue number floating where it should not be, nothing has been corrupted. The bytes you typed are almost always the bytes that arrived. What changed is the base direction of the box the text is being drawn into, and that is decided by the store's page, not by your title. This article explains the mechanism precisely enough that you can predict which of your titles will break before you deliver them.

One thing to say at the top, because it is the honest position: we know of no published measurement of Arabic-script metadata error rates anywhere in the industry. The problem is universally experienced and entirely unquantified. No figure appears below, because there is no figure to give.

Logical order and display order are two different things

Unicode stores text in logical order — the order you say it, type it and read it aloud. Display order is computed from that at render time, by the Unicode Bidirectional Algorithm defined in Unicode Standard Annex #9 (UAX #9). The annex is blunt about the split: "The Unicode Standard prescribes a memory representation order known as logical order," and "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."

That single sentence explains the phenomenon that makes Arabic-script artists believe their metadata is haunted: the stored string can be perfectly correct while the display is wrong, and it can be visually correct while the stored bytes are wrong — and on screen the two failures look identical. You cannot audit this by looking. Neither can your distributor's support agent.

Why a Latin token inside an RTL string moves

UAX #9 gives every character a bidirectional type. Arabic, Persian and Urdu letters are AL (right-to-left Arabic letters). Latin letters are L. ASCII digits are EN (European Number), Arabic-Indic digits are AN (Arabic Number). Spaces and most punctuation — including parentheses, brackets, the hyphen and the full stop — are neutral, meaning they have no direction of their own and inherit one from their surroundings.

Two rule groups do the damage.

Paragraph direction, rules P2–P3. The algorithm scans for the first strong directional character and sets the base direction from it. A title that begins with a Latin word gets left-to-right base direction even if everything after it is Persian.

Neutral resolution, rules N1–N2. Rule N1: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction." Rule N2: neutrals with no consensus take the paragraph direction. Then rule L2 reorders for display — "reverse any contiguous sequence of characters that are at that level or higher."

Put those together and the failure is deterministic, not random. A Latin token — a remixer's name, feat., Vol. 2, a catalogue number, a year — sits at a different embedding level than the Arabic around it. The neutrals on its boundaries (the space, the opening parenthesis) have Arabic on one side and Latin on the other, so N1 finds no consensus and N2 hands them the paragraph direction. A parenthesis that resolved one way in your right-to-left text editor resolves the other way on a left-to-right store page, and the bracket detaches and flips.

So نام آهنگ (Nima Remix) is not broken. It is one string being resolved in two contexts. Base direction is context, not content, and the store's context is not yours.

The one thing you must never do

Do not "fix" the display by typing the characters backwards until the preview looks right.

That produces a string that is wrong in logical order, right in exactly one rendering context, and broken everywhere else — including search, sorting, artist matching and every store whose page has a different base direction from the tool you fixed it in. You will have converted a display problem, which is recoverable, into a data problem, which is not.

UAX #9 does define characters for controlling this explicitly: the isolates LRI, RLI, FSI and PDI, and the marks LRM, RLM and ALM. They are the technically correct fix. They are also invisible formatting characters, and many delivery pipelines strip invisible formatting characters without telling you. Treat them as unreliable in a metadata field.

The structural fix: get the Latin token out of the middle

The mitigation that works everywhere, in every renderer, with no invisible characters, is structural. In order of preference:

• Use separate fields instead of mixed-direction strings wherever the data model offers them. A featured artist belongs at the artist-role level, not in the title. The Music Biz Music Metadata Style Guide advises crediting featured artists at the artist role level and not adding that data to the track or album release title; Spotify's public guidance is "You shouldn't include any artists' names in your track or release titles." A version belongs in the version field, whose entire job is distinguishing two recordings that share a title. Every Latin token you move into its own field is a bidirectional boundary that stops existing.
• Keep any unavoidable Latin token out of first position. First position sets the paragraph direction under P2–P3. A Persian title that opens with a Latin word is a left-to-right paragraph containing Persian, which is not what you meant.
• Avoid decorative punctuation at direction boundaries. Dashes, slashes, pipes and stacked brackets are neutrals sitting exactly where the algorithm has the least information.

Where a contract genuinely requires the billing in the title, the conventions are fixed and worth following exactly. Music Biz, on "feat." and "with": "when included in the title are generally lowercase and in English." Apple's style guide: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." That "not localized" instruction is doing real work here — do not translate "feat." into Arabic, Persian or Urdu in a title field. It is a machine-readable token, not a word.

Digits, and why yours may not be the digits you think

Three digit sets are in play:

These are not stylistic variants. They are different code points, and per the Unicode Character Database they do not even share a bidirectional class. UAX #9 rule W2 re-types a European number to an Arabic number when the nearest preceding strong character is an Arabic letter, so inside Persian text the two may behave alike at display time — but never in sorting, search or string comparison, because they are different characters. A "Vol. 2" typed with an extended Arabic-Indic ۲ and a "Vol. 2" typed with an ASCII 2 are two different strings that look nearly identical.

Pick one digit set per catalogue and never mix sets inside a single string.

How to check what you actually typed

The display cannot be trusted, so check the bytes. Three things are worth doing before every delivery:

1. Read the string as code points, not as glyphs. Any tool that shows you U+ values will tell you instantly whether that is a Persian ی (U+06CC) or an Arabic ي (U+064A), a Persian ک (U+06A9) or an Arabic ك (U+0643) — a distinction most fonts flatten and no proofreader can see. The same applies to a stray tatweel (U+0640), which no Unicode normalisation form removes, and to a zero-width non-joiner (U+200C) that a form field silently ate.
2. Paste the title into a left-to-right context and a right-to-left context and compare. If the punctuation lands differently in the two, you have a mixed-direction string and a Latin token that should be in its own field.
3. Compare against your previous release, character by character, not by eye. Split catalogues in Arabic script are almost always caused by a difference that is invisible: one release typed on a Persian keyboard layout, the next on an Arabic one.

Mazufa's tools run entirely in your browser — no audio and no text is uploaded — and they set dir="rtl" automatically when a title is right-to-left, so what you see while typing matches the context the string was written for. mazufa.com also hosts a free metadata checker that runs on your own device and flags several of the invisible cases: mixed digit sets, tatweel, stray or missing ZWNJ, Arabic-versus-Persian yeh and kaf, and non-NFC strings.

What to do before you deliver

Take your next release's title and artist name and do four things. Move every Latin token you can into its own field — featured artists to the artist role, versions to the version field. Make sure nothing starts with a Latin word. Normalise your digit set and remove any tatweel. Then read the string as code points once, and save that exact string as the canonical spelling you will reuse on every future release, without retyping it.

If a title still has to carry a Latin token in the middle, deliver it and accept that it will render differently in different places. That is a display outcome, not damage. The string is correct. Retyping it backwards to make one preview look right is the only way to make it genuinely wrong.

Sources

• Unicode Standard Annex #9, Unicode Bidirectional Algorithm (Revision 51, Unicode 17.0.0, 2025-08-13) — https://www.unicode.org/reports/tr9/
• Unicode Standard Annex #15, Unicode Normalization Forms (Version 57, Unicode 17.0.0, 2025-07-30) — https://www.unicode.org/reports/tr15/
• Unicode Character Database — character properties: bidirectional class, decomposition mappings — https://www.unicode.org/ucd/
• Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• Apple Music Style Guide — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/

The corpus gives version and revision dates for these documents, as listed above, and does not record a separate read date for them.