Je Arabische titel is niet beschadigd — de winkel leest hem in een andere richting

Wanneer een Arabische, Perzische of Urdu-titel bij een winkel aankomt met het haakje aan de verkeerde kant, de “feat.”-vermelding naar het uiteinde geduwd, of een catalogusnummer dat zweeft waar het niet hoort, is er niets beschadigd. De bytes die je hebt getypt zijn vrijwel altijd de bytes die zijn aangekomen. Wat veranderd is, is de basisrichting van het vak waarin de tekst wordt getekend, en die wordt bepaald door de pagina van de winkel, niet door jouw titel. Dit artikel legt het mechanisme precies genoeg uit om te kunnen voorspellen welke van je titels stukgaan voordat je ze aanlevert.

Eén ding vooraf, want dat is de eerlijke positie: wij kennen nergens in de branche een gepubliceerde meting van foutpercentages in metadata in Arabisch schrift. Het probleem wordt overal ervaren en is volstrekt niet gekwantificeerd. Hieronder staat geen enkel cijfer, omdat er geen cijfer te geven is.

Logische volgorde en weergavevolgorde zijn twee verschillende dingen

Unicode slaat tekst op in logische volgorde — de volgorde waarin je hem uitspreekt, typt en hardop leest. De weergavevolgorde wordt daaruit berekend op het moment van renderen, door het Unicode Bidirectional Algorithm dat is vastgelegd in Unicode Standard Annex #9 (UAX #9). De annex is onomwonden over die scheiding: "The Unicode Standard prescribes a memory representation order known as logical order," en "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."

Die ene zin verklaart het verschijnsel waardoor artiesten die in Arabisch schrift werken denken dat hun metadata behekst is: de opgeslagen string kan volmaakt correct zijn terwijl de weergave fout is, en hij kan er visueel goed uitzien terwijl de opgeslagen bytes fout zijn — en op het scherm zien die twee fouten er identiek uit. Je kunt dit niet controleren door te kijken. De supportmedewerker van je distributeur ook niet.

Waarom een Latijns woord in een RTL-string verspringt

UAX #9 geeft elk teken een bidirectioneel type. Arabische, Perzische en Urdu-letters zijn AL (rechts-naar-links Arabische letters). Latijnse letters zijn L. ASCII-cijfers zijn EN (European Number), Arabisch-Indische cijfers zijn AN (Arabic Number). Spaties en de meeste leestekens — waaronder ronde haakjes, blokhaken, het koppelteken en de punt — zijn neutraal, wat betekent dat ze geen eigen richting hebben en er een overnemen van hun omgeving.

Twee groepen regels richten de schade aan.

Alinearichting, regels P2–P3. Het algoritme zoekt het eerste sterke richtingteken en stelt daaraan de basisrichting vast. Een titel die met een Latijns woord begint, krijgt links-naar-rechts als basisrichting, ook als alles erna Perzisch is.

Neutrale resolutie, regels N1–N2. Regel N1: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction." Regel N2: neutralen zonder consensus nemen de alinearichting over. Vervolgens herordent regel L2 voor weergave — "reverse any contiguous sequence of characters that are at that level or higher."

Zet dat bij elkaar en de fout is deterministisch, niet willekeurig. Een Latijns woord — de naam van een remixer, feat., Vol. 2, een catalogusnummer, een jaartal — zit op een ander inbeddingsniveau dan het Arabisch eromheen. De neutralen op de grenzen ervan (de spatie, het openingshaakje) hebben Arabisch aan de ene kant en Latijn aan de andere, dus N1 vindt geen consensus en N2 geeft ze de alinearichting. Een haakje dat in je rechts-naar-links-editor de ene kant op uitpakte, pakt op een links-naar-rechts-winkelpagina de andere kant op uit, en het haakje laat los en klapt om.

Dus نام آهنگ (Nima Remix) is niet stuk. Het is één string die in twee contexten wordt opgelost. Basisrichting is context, geen inhoud, en de context van de winkel is niet die van jou.

Het ene wat je nooit moet doen

“Repareer” de weergave niet door de tekens achterstevoren te typen tot de voorvertoning er goed uitziet.

Dat levert een string op die fout is in logische volgorde, goed in precies één rendercontext, en stuk overal elders — inclusief zoeken, sorteren, artiestenkoppeling en elke winkel waarvan de pagina een andere basisrichting heeft dan de tool waarin je het hebt gerepareerd. Je hebt dan een weergaveprobleem, dat te herstellen is, veranderd in een dataprobleem, dat dat niet is.

UAX #9 definieert wel degelijk tekens om dit expliciet te sturen: de isolates LRI, RLI, FSI en PDI, en de marks LRM, RLM en ALM. Dat is technisch de juiste oplossing. Het zijn ook onzichtbare opmaaktekens, en veel leveringsketens verwijderen onzichtbare opmaaktekens zonder je dat te melden. Beschouw ze als onbetrouwbaar in een metadataveld.

De structurele oplossing: haal het Latijnse woord uit het midden

De maatregel die overal werkt, in elke renderer, zonder onzichtbare tekens, is structureel. In volgorde van voorkeur:

• Gebruik aparte velden in plaats van strings met gemengde richting, overal waar het datamodel ze biedt. Een gastartiest hoort thuis op het niveau van de artiestenrol, niet in de titel. De Music Biz Music Metadata Style Guide adviseert gastartiesten te crediteren op het niveau van de artiestenrol en die gegevens niet toe te voegen aan de titel van de track of van de albumrelease; het publieke advies van Spotify luidt "You shouldn't include any artists' names in your track or release titles." Een versie hoort in het versieveld, dat als enige taak heeft twee opnames met dezelfde titel te onderscheiden. Elk Latijns woord dat je naar een eigen veld verplaatst, is een bidirectionele grens die ophoudt te bestaan.
• Houd elk onvermijdelijk Latijns woord uit de eerste positie. De eerste positie bepaalt de alinearichting onder P2–P3. Een Perzische titel die met een Latijns woord opent, is een links-naar-rechts-alinea met Perzisch erin, en dat is niet wat je bedoelde.
• Vermijd decoratieve leestekens op richtinggrenzen. Streepjes, schuine strepen, pipes en gestapelde haakjes zijn neutralen die precies daar staan waar het algoritme de minste informatie heeft.

Waar een contract werkelijk vereist dat de vermelding in de titel staat, liggen de conventies vast en is het de moeite waard ze exact te volgen. Music Biz, over "feat." en "with": "when included in the title are generally lowercase and in English." De stijlgids van Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." Dat "not localized" doet hier echt werk — vertaal "feat." niet naar het Arabisch, Perzisch of Urdu in een titelveld. Het is een machineleesbaar token, geen woord.

Cijfers, en waarom die van jou misschien niet de cijfers zijn die je denkt

Er zijn drie cijferreeksen in het spel:

Dat zijn geen stilistische varianten. Het zijn verschillende codepunten, en volgens de Unicode Character Database delen ze niet eens dezelfde bidirectionele klasse. Regel W2 van UAX #9 hertypeert een European Number naar een Arabic Number wanneer het dichtstbijzijnde voorafgaande sterke teken een Arabische letter is, dus binnen Perzische tekst kunnen de twee zich bij weergave hetzelfde gedragen — maar nooit bij sorteren, zoeken of stringvergelijking, want het zijn verschillende tekens. Een "Vol. 2" getypt met een uitgebreid Arabisch-Indische ۲ en een "Vol. 2" getypt met een ASCII 2 zijn twee verschillende strings die er bijna identiek uitzien.

Kies één cijferreeks per catalogus en meng nooit reeksen binnen één string.

Hoe je nakijkt wat je werkelijk hebt getypt

Op de weergave kun je niet vertrouwen, dus controleer de bytes. Drie dingen zijn de moeite waard voor elke levering:

1. Lees de string als codepunten, niet als glyphs. Elke tool die je U+-waarden toont, vertelt je meteen of het een Perzische ی (U+06CC) of een Arabische ي (U+064A) is, een Perzische ک (U+06A9) of een Arabische ك (U+0643) — een onderscheid dat de meeste lettertypen platslaan en dat geen enkele corrector kan zien. Hetzelfde geldt voor een verdwaalde tatweel (U+0640), die door geen enkele Unicode-normalisatievorm wordt verwijderd, en voor een zero-width non-joiner (U+200C) die een formulierveld geruisloos heeft opgegeten.
2. Plak de titel in een links-naar-rechts-context en in een rechts-naar-links-context en vergelijk. Landen de leestekens in de twee gevallen anders, dan heb je een string met gemengde richting en een Latijns woord dat in een eigen veld hoort.
3. Vergelijk met je vorige release, teken voor teken, niet op het oog. Gesplitste catalogi in Arabisch schrift ontstaan vrijwel altijd door een verschil dat onzichtbaar is: de ene release getypt op een Perzische toetsenbordindeling, de volgende op een Arabische.

De tools van Mazufa draaien volledig in je browser — er wordt geen audio en geen tekst geüpload — en ze zetten automatisch dir="rtl" wanneer een titel rechts-naar-links is, zodat wat je tijdens het typen ziet overeenkomt met de context waarvoor de string geschreven is. Op mazufa.com staat ook een gratis metadatacontrole die op je eigen apparaat draait en verschillende van de onzichtbare gevallen signaleert: gemengde cijferreeksen, tatweel, verdwaalde of ontbrekende ZWNJ, Arabische versus Perzische yeh en kaf, en strings die niet in NFC staan.

Wat je doet voordat je aanlevert

Neem de titel en artiestennaam van je volgende release en doe vier dingen. Verplaats elk Latijns woord dat je kunt verplaatsen naar een eigen veld — gastartiesten naar de artiestenrol, versies naar het versieveld. Zorg dat niets met een Latijns woord begint. Normaliseer je cijferreeks en haal elke tatweel weg. Lees de string dan één keer als codepunten, en bewaar precies die string als de canonieke schrijfwijze die je bij elke toekomstige release hergebruikt, zonder hem opnieuw te typen.

Moet een titel toch een Latijns woord in het midden dragen, lever hem dan aan en accepteer dat hij op verschillende plekken verschillend zal renderen. Dat is een weergave-uitkomst, geen schade. De string klopt. Hem achterstevoren overtypen zodat één voorvertoning er goed uitziet, is de enige manier om hem werkelijk fout te maken.

Bronnen

• 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 — tekeneigenschappen: bidirectionele klasse, decompositietoewijzingen — 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/

Het corpus geeft voor deze documenten de hierboven vermelde versie- en revisiedata, en legt er geen aparte leesdatum voor vast.