Arapça başlığınız bozulmadı — mağaza onu farklı bir yönde okuyor

Arapça, Farsça ya da Urduca bir başlık bir mağazaya parantezi yanlış tarafta, "feat." künyesi en uca itilmiş ya da katalog numarası olmaması gereken bir yerde asılı hâlde ulaştığında, hiçbir şey bozulmuş değildir. Yazdığınız baytlar neredeyse her zaman ulaşan baytlardır. Değişen şey, metnin çizildiği kutunun temel yönüdür ve buna sizin başlığınız değil mağazanın sayfası karar verir. Bu yazı, hangi başlıklarınızın teslimden önce bozulacağını öngörebilmeniz için mekanizmayı yeterince kesin biçimde anlatıyor.

En baştan söylenmesi gereken bir şey var, çünkü dürüst duruş bu: sektörün hiçbir yerinde Arap alfabeli üst veri hata oranlarına dair yayımlanmış bir ölçüm bilmiyoruz. Sorun evrensel biçimde yaşanıyor ve tamamen ölçülmemiş durumda. Aşağıda hiçbir rakam yok, çünkü verilecek bir rakam yok.

Mantıksal sıra ile görüntü sırası iki ayrı şeydir

Unicode metni mantıksal sırada saklar — söylediğiniz, yazdığınız ve sesli okuduğunuz sıra. Görüntü sırası, bundan çizim anında, Unicode Standard Annex #9 (UAX #9) içinde tanımlanan Unicode Çift Yönlü Algoritması tarafından hesaplanır. Ek, bu ayrımı açıkça koyuyor: "The Unicode Standard prescribes a memory representation order known as logical order" ve "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."

Bu tek cümle, Arap alfabeli sanatçılara üst verilerinin perili olduğunu düşündüren olguyu açıklıyor: saklanan dizge tamamen doğruyken görüntü yanlış olabilir; görüntü doğruyken saklanan baytlar yanlış olabilir — ve ekranda bu iki hata birbirinin aynı görünür. Bunu bakarak denetleyemezsiniz. Dağıtımcınızın destek görevlisi de denetleyemez.

Sağdan sola bir dizgenin içindeki Latin kelime neden yer değiştirir

UAX #9 her karaktere bir çift yönlülük türü verir. Arapça, Farsça ve Urduca harfler AL'dir (sağdan sola Arap harfleri). Latin harfler L'dir. ASCII rakamlar EN'dir (Avrupa Sayısı), Arap-Hint rakamları ise AN'dir (Arap Sayısı). Boşluklar ve noktalamanın çoğu — parantezler, köşeli parantezler, tire ve nokta dahil — nötrdür; yani kendi yönleri yoktur ve yönü çevrelerinden alırlar.

Hasarı iki kural grubu veriyor.

Paragraf yönü, P2–P3 kuralları. Algoritma ilk güçlü yönlü karakteri arar ve temel yönü ondan belirler. Latin bir kelimeyle başlayan bir başlık, ardından gelen her şey Farsça olsa bile soldan sağa temel yön alır.

Nötr çözümleme, N1–N2 kuralları. N1 kuralı: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction." N2 kuralı: uzlaşmanın olmadığı nötrler paragraf yönünü alır. Ardından L2 kuralı görüntü için yeniden sıralar — "reverse any contiguous sequence of characters that are at that level or higher."

Bunları bir araya koyunca hata rastlantısal değil, belirlenimci hâle gelir. Latin bir kelime — bir remixçinin adı, feat., Vol. 2, bir katalog numarası, bir yıl — çevresindeki Arapçadan farklı bir gömme düzeyinde durur. Sınırındaki nötrlerin (boşluk, açılan parantez) bir yanında Arapça, öbür yanında Latin vardır; N1 uzlaşma bulamaz ve N2 onlara paragraf yönünü verir. Sağdan sola metin düzenleyicinizde bir yöne çözümlenen parantez, soldan sağa bir mağaza sayfasında öbür yöne çözümlenir ve parantez kopup ters döner.

Yani نام آهنگ (Nima Remix) bozuk değildir. İki farklı bağlamda çözümlenen tek bir dizgedir. Temel yön içerik değil bağlamdır ve mağazanın bağlamı sizinki değildir.

Asla yapmamanız gereken tek şey

Önizleme doğru görünene kadar karakterleri ters yazarak görüntüyü "düzeltmeye" kalkmayın.

Bu, mantıksal sırada yanlış olan, tam olarak tek bir çizim bağlamında doğru görünen ve başka her yerde bozuk olan bir dizge üretir — arama, sıralama, sanatçı eşleştirme ve sayfasının temel yönü sizin düzelttiğiniz aracınkinden farklı olan her mağaza dahil. Kurtarılabilir bir görüntü sorununu, kurtarılamaz bir veri sorununa çevirmiş olursunuz.

UAX #9 bunu açıkça denetlemek için karakterler tanımlar: LRI, RLI, FSI ve PDI izolatları ile LRM, RLM ve ALM işaretleri. Teknik olarak doğru çözüm bunlardır. Ama aynı zamanda görünmez biçimlendirme karakterleridir ve birçok teslim hattı görünmez biçimlendirme karakterlerini size haber vermeden siler. Bir üst veri alanında onlara güvenilmez muamelesi yapın.

Yapısal çözüm: Latin kelimeyi ortadan çıkarın

Her yerde, her çizicide, görünmez karakter kullanmadan işe yarayan hafifletme yapısaldır. Tercih sırasıyla:

• Veri modeli sunuyorsa, karışık yönlü dizgeler yerine ayrı alanlar kullanın. Konuk sanatçının yeri başlık değil, sanatçı rolü düzeyidir. Music Biz'in Music Metadata Style Guide belgesi konuk sanatçıların sanatçı rolü düzeyinde künyelenmesini ve bu verinin parça ya da albüm yayın başlığına eklenmemesini öneriyor; Spotify'ın herkese açık yönergesi ise "You shouldn't include any artists' names in your track or release titles." Bir versiyonun yeri, tek işi aynı başlığı paylaşan iki kaydı ayırt etmek olan versiyon alanıdır. Kendi alanına taşıdığınız her Latin kelime, var olmaktan çıkan bir çift yönlülük sınırıdır.
• Kaçınılmaz bir Latin kelimeyi ilk konumdan uzak tutun. İlk konum, P2–P3 uyarınca paragraf yönünü belirler. Latin bir kelimeyle açılan Farsça bir başlık, içinde Farsça bulunan soldan sağa bir paragraftır ve kastettiğiniz bu değildir.
• Yön sınırlarında süs noktalamasından kaçının. Tireler, eğik çizgiler, dikey çizgiler ve iç içe parantezler, algoritmanın en az bilgiye sahip olduğu yerde duran nötrlerdir.

Bir sözleşme künyenin başlıkta yer almasını gerçekten şart koşuyorsa, kurallar bellidir ve harfiyen izlemeye değer. Music Biz, "feat." ve "with" için: "when included in the title are generally lowercase and in English." Apple'ın stil kılavuzu: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." Buradaki "not localized" talimatı gerçekten iş görüyor — bir başlık alanında "feat." ifadesini Arapçaya, Farsçaya ya da Urducaya çevirmeyin. O bir kelime değil, makinece okunan bir simgedir.

Rakamlar ve sizinkilerin neden sandığınız rakamlar olmayabileceği

Sahnede üç rakam kümesi var:

Bunlar biçimsel varyantlar değil. Farklı kod noktalarıdır ve Unicode Karakter Veritabanı'na göre çift yönlülük sınıfları bile aynı değildir. UAX #9'un W2 kuralı, en yakın önceki güçlü karakter bir Arap harfiyse bir Avrupa sayısını Arap sayısına yeniden türler; yani Farsça metnin içinde ikisi görüntü anında benzer davranabilir — ama sıralamada, aramada ya da dizge karşılaştırmasında asla, çünkü farklı karakterlerdir. Genişletilmiş Arap-Hint ۲ ile yazılmış bir "Vol. 2" ile ASCII 2 ile yazılmış bir "Vol. 2", neredeyse aynı görünen iki farklı dizgedir.

Katalog başına tek bir rakam kümesi seçin ve tek bir dizgenin içinde kümeleri asla karıştırmayın.

Gerçekte ne yazdığınızı nasıl kontrol edersiniz

Görüntüye güvenilemeyeceği için baytları kontrol edin. Her teslimden önce yapmaya değer üç şey:

1. Dizgeyi glifler olarak değil, kod noktaları olarak okuyun. U+ değerlerini gösteren herhangi bir araç, karşınızdakinin Farsça ی (U+06CC) mi Arapça ي (U+064A) mi, Farsça ک (U+06A9) mi Arapça ك (U+0643) mi olduğunu anında söyler — çoğu yazı tipinin düzleştirdiği ve hiçbir düzeltmenin göremeyeceği bir ayrım. Aynısı, hiçbir Unicode normalleştirme biçiminin kaldırmadığı başıboş bir tatvil (U+0640) ve bir form alanının sessizce yuttuğu bir sıfır genişlikli birleştirmeyen (U+200C) için de geçerli.
2. Başlığı bir soldan sağa bağlama ve bir sağdan sola bağlama yapıştırıp karşılaştırın. Noktalama ikisinde farklı yere düşüyorsa, elinizde karışık yönlü bir dizge ve kendi alanında olması gereken bir Latin kelime var demektir.
3. Bir önceki yayınınızla göz kararı değil, karakter karakter karşılaştırın. Arap alfabesindeki bölünmüş kataloglara neredeyse her zaman görünmez bir fark yol açar: bir yayın Farsça klavye düzeninde, sonraki Arapça düzende yazılmıştır.

Mazufa'nın araçları tamamen tarayıcınızda çalışıyor — hiçbir ses ve hiçbir metin yüklenmiyor — ve bir başlık sağdan solaysa dir="rtl" değerini otomatik olarak ayarlıyor; böylece yazarken gördüğünüz şey, dizgenin yazıldığı bağlamla örtüşüyor. mazufa.com ayrıca kendi cihazınızda çalışan ve görünmez durumların birçoğunu işaretleyen ücretsiz bir üst veri denetleyicisi barındırıyor: karışık rakam kümeleri, tatvil, başıboş ya da eksik ZWNJ, Arapça ile Farsça yeh ve kaf farkı ve NFC olmayan dizgeler.

Teslimden önce yapılacaklar

Bir sonraki yayınınızın başlığını ve sanatçı adını alın ve dört şey yapın. Taşıyabildiğiniz her Latin kelimeyi kendi alanına taşıyın — konuk sanatçıları sanatçı rolüne, versiyonları versiyon alanına. Hiçbir şeyin Latin bir kelimeyle başlamadığından emin olun. Rakam kümenizi tekleştirin ve tatvilleri kaldırın. Sonra dizgeyi bir kez kod noktaları olarak okuyun ve tam olarak o dizgeyi, her gelecek yayında yeniden yazmadan kullanacağınız kanonik yazım olarak saklayın.

Bir başlık yine de ortasında Latin bir kelime taşımak zorundaysa, onu öyle teslim edin ve farklı yerlerde farklı çizileceğini kabul edin. Bu bir görüntü sonucudur, hasar değil. Dizge doğrudur. Tek bir önizleme doğru görünsün diye onu ters yazmak, onu gerçekten yanlış hâle getirmenin tek yoludur.

Kaynaklar

• 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 — karakter özellikleri: çift yönlülük sınıfı, ayrıştırma eşlemeleri — 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/

Külliyat bu belgeler için yukarıda listelenen sürüm ve revizyon tarihlerini veriyor ve onlar için ayrı bir okunma tarihi kaydetmiyor.