Türkçe Ürün Başlıklarını İ ve ı'yı Bozmadan Küçük Harfe Çevirmek: Feed Kuralı Rehberi

Google, ürün başlığının 1 ile 150 karakter arasında olmasına izin veriyor ve satıcılara vurgu amacıyla büyük harf kullanmamalarını söylüyor (Merchant Center Help). ERP sistemlerinden dışa aktarılan Türkçe kataloglar çoğunlukla büyük harflerle yazılmıştır; bu yüzden akla gelen ilk çözüm, her başlığı küçük harfe veya başlık biçimine (title case) çeviren bir kural yazmaktır. Türkçe veri tam da bu kuralda sessizce bozulur. Testimizde İZMİR ÇİZGİLİ KIŞLIK MONT ifadesinin varsayılan küçük harf dönüşümü 25 yerine 30 kod noktası döndürdü ve ISPARTA, ısparta yerine isparta oldu. Bu rehber, Türkçe ürün metinleriyle çalışan feed yöneticileri ve geliştiriciler için hazırlandı. Rehberin sonunda kendi altyapınızı test edebilecek, büyük/küçük harf kuralını düzeltebilecek ve sorunu her senkronizasyonda yakalayan bir kontrol ekleyebileceksiniz.

Türkçe harf dönüşümü neden sıradan kuralları bozar?

Türkçede iki ayrı harf çifti vardır: noktasız ı ile büyük I ve noktalı i ile büyük İ. Unicode büyük/küçük harf eşleme dosyası bunu açıkça belirtir: "I and i-dotless; I-dot and i are case pairs in Turkish and Azeri" (Unicode SpecialCasing.txt).

Varsayılan (dilden bağımsız) dönüşüm bunu bilmez. I harfini i yapar, İ harfini ise i artı üstte birleşen bir nokta (U+0307) olarak eşler. Aynı dosyadaki Türkçe kurallar ise I harfini ı, İ harfini düz bir i yapar. Azerbaycan Türkçesi de aynı kuralı izler.

Bir feed'de üç şey ters gider:

• Yanlış harfler. KADIN, kadin olur; YAĞI, yaği olur. Kelime hâlâ okunabilir, ancak yanlış yazılmıştır.
• Fazladan karakterler. İZMİR, i̇zmi̇r olur; yani iki fazladan, neredeyse görünmeyen kod noktası içeren bir dizeye dönüşür. Ekranda neredeyse doğru görünür, ancak bir filtrede, birleştirmede (join) ya da aramada izmir ile eşleşmez.
• Ters yönde yanlış büyük harfler. istanbul, İSTANBUL yerine ISTANBUL olur; başlık biçimi (title case) ise İç yerine Iç üretir.

Adım 1: Altyapınızın bugün ne yaptığını öğrenin

Herhangi bir kuralı değiştirmeden önce, başlıklarınızı dönüştüren kodun nasıl davrandığını kontrol edin. Aynı iki girdiyi çoğu feed hattının kullandığı çalışma ortamlarında denedik. Küçük harf testi için girdi ISPARTA İSTANBUL, büyük harf testi için istanbul ışık idi.

İki ayrıntı önemli. Birincisi, JavaScript'te argümansız kullanılan toLocaleLowerCase() varsayılan yerel ayarı (locale) kullanır; dolayısıyla aynı kod bir sunucuda ve bir dizüstü bilgisayarda farklı davranabilir. Dokümantasyon, "İstanbul".toLocaleLowerCase("en-US") çağrısının i̇stanbul, toLocaleLowerCase("tr") çağrısının ise istanbul döndürdüğünü gösteriyor (MDN). "tr" değerini her zaman açıkça verin.

İkincisi, PHP 8.2 ile strtolower() artık setlocale() ayarına bağlı değil ve yalnızca ASCII karakterleri dönüştürüyor (PHP manual). Güncel bir sürümde Türkçe locale ayarlamak bunu değiştirmez.

Adım 2: Gerçek başlıklardan bir test seti oluşturun

Kendi kataloğunuzdan, Türkçeye özgü her harfi kapsayan 10 ila 15 başlık seçin: İ, I, ı, i, Ş, Ğ, Ç, Ö, Ü. I ile başlayan bir başlık, İ ile başlayan bir başlık ve ML ya da GB gibi bir birim içeren bir başlık ekleyin. Aşağıda başlangıç için bir set var; varsayılan küçük harf çıktısı ile doğru çıktı yan yana gösteriliyor.

Son satıra bakın. Yalnızca tek bir harf farklı ve birkaç başlık üzerinde yapılan görsel bir kontrol bunu kolayca gözden kaçırır. Test setinin her harfi kapsaması gerekmesinin ve izlenimleri değil dizeleri karşılaştırmanız gerekmesinin nedeni budur.

Adım 3: Harf dönüşümü fonksiyonunu düzeltin

Aracınız locale seçmenize izin veriyorsa bunu tr olarak ayarlayın. İzin vermiyorsa dönüşümü kendiniz sarmalayın. JavaScript veya Node'da çözüm tek bir argümandır:

title.toLocaleLowerCase("tr")
title.toLocaleUpperCase("tr")

Python'un standart string metotlarında locale argümanı yoktur. Güvenilir bir geçici çözüm, varsayılan metodu çağırmadan önce dört özel harfi değiştirmektir. Bu sürümü yukarıdaki ilk dört satıra karşı test ettik:

def tr_lower(s):
    return s.replace("İ", "i").replace("I", "ı").lower()

def tr_upper(s):
    return s.replace("i", "İ").replace("ı", "I").upper()

Sıra önemlidir. Önce İ ve I harflerini değiştirin, sonra küçük harfe çevirin. Önce küçük harfe çevirirseniz, harfin hangi büyük harf olduğu bilgisi zaten kaybolmuş olur.

Adım 4: Başlık biçimini ve birimleri ayrı ele alın

Başlık biçimi (title case) iki sorun daha ekler. Her kelimenin ilk harfini büyütürken Türkçe büyük harf kullanılmalıdır; aksi hâlde Python'un title() metodunda iç çamaşırı, Iç Çamaşırı olur. Ayrıca genel bir kural birimleri de büyütür: 50 ML, 50 Ml olur.

Kullandığımız yöntem şöyle: tüm başlığı Türkçe fonksiyonla küçük harfe çevirin, her kelimenin ilk harfini Türkçe fonksiyonla büyütün ve bir rakamla başlayan ya da kısa bir birim listesinde (ml, gb, cm, kg) yer alan her token'ı atlayın. ISPARTA GÜL YAĞI 50 ML girdisinde bu Isparta Gül Yağı 50 ml sonucunu verir. Birim listesi olmadan aynı hat 50 Ml döndürür. Isparta yazımının doğru olduğuna dikkat edin: şehir adı noktasız büyük I ile başlar.

Marka adları ayrı bir durumdur. Bilerek büyük harfle yazılan bir marka (IKEA, HP) için bir istisna listesi gerekir; çünkü Google yalnızca vurgu için büyük harften kaçınmanızı, kısaltmalar gibi uygun yerlerde ise kullanmaya devam etmenizi ister (Merchant Center Help). Listeyi kısa tutun ve kuralla aynı yerde saklayın.

Bu kuralları bir feed yönetim aracında yönetiyorsanız, aracın harf dönüşümünü nasıl uyguladığını kontrol edin. Feedance'ın Feed Rules özelliği büyük harf, cümle düzeni (sentence case) ve ilk harfi büyük yazma seçeneklerini listeliyor; sayfa hangi locale'i kullandıklarını belirtmiyor. Bu nedenle Türkçe metinlere güvenmeden önce bu test setini bizimkiler dahil her araca karşı çalıştırıyoruz. Bir kuralın ne zaman yeterli olduğu ve bir yapay zekâ modelinin ne zaman değer kattığı konusunda daha geniş bir bakış için kural tabanlı ve yapay zekâ ile üretilen ürün başlıkları karşılaştırmamıza göz atın.

Adım 5: Mevcut verideki kalıntı hasarı tespit edin

Hatalı bir kural zaten çalıştıysa, birleşen nokta artık saklanan verinizin içindedir. Unicode normalizasyonu bunu kaldırmaz: testimizde i ve ardından gelen U+0307, NFC normalizasyonundan sonra da iki kod noktası olarak kaldı; çünkü birleştirilecek önceden birleştirilmiş (precomposed) bir biçim yok. Bunu bulup kaldırmanız gerekir.

Bu kontrol, üstte birleşen noktayı içeren her başlığı raporlar:

import re
bad = [t for t in titles if re.search("̇", t)]

Düzeltilmiş kuralı İZMİR üzerinde yeniden çalıştırdıktan sonra aynı kontrol false döndürür. Harf dönüşümü kuralları çoğunlukla yalnızca başlıklara uygulanmadığı için kontrolü title, description, brand, product_type ve tüm custom_label alanlarında çalıştırın.

Ayrıca, bir kanal kodlama hatası bildiriyorsa bu farklı bir sorundur. Merchant Center'ın "Invalid UTF-8 encoding" sayfası, nedenin metnin kodlamasındaki bir sorun olduğunu söylüyor ve dosyanın kodlamasını belirtmenizi ya da dönüştürmenizi öneriyor (Merchant Center Help). Harf dönüşümü hatası geçerli UTF-8 üretir, bu yüzden o hatayı tetiklemez. Sessizce geçer; bunun için test etmeniz gerekmesinin nedeni de budur.

Adım 6: Bunu her senkronizasyonda bir kapıya dönüştürün

Kimsenin yeniden kontrol etmediği bir düzeltme, biri bir kural eklediğinde ya da araç değiştirdiğinde ilk fırsatta geri bozulur. Başlık, açıklama veya kategori adı kurallarında yapılacak her değişiklik için bu kontrol listesini bir yayın kapısı olarak kullanın.

Uzunluk kontrolü, varsayılan küçük harf dönüşümünün eklediği fazladan kod noktalarını yakalar. Değişikliğe hangi kuralın yol açtığını henüz bilmeseniz bile kullanışlı bir uyarı tetikleyicisidir.

Bu yöntemin sınırları

Bu yöntem, Unicode dosyasında bu kural için listelenen iki dil olan Türkçe ve Azerbaycan Türkçesi içindir. Arap alfabesiyle yazılan alanları kapsamaz; bunlar için Arapça ve İngilizce ürün verisini nasıl yapılandıracağınıza bakın.

Google'ın ya da herhangi bir pazaryerinin, noktalı veya noktasız i yanlış olduğu için bir ürünü reddettiğine dair elimizde kanıt yok. Belgelenmiş maliyetler dolaylıdır: alışveriş yapanların karşısına çıkan yanlış yazılmış başlıklar ve filtrelerinizle, birleştirmelerinizle ve dahili aramanızla artık eşleşmeyen dizeler. Bunu bir politika sorunu olarak değil, bir veri kalitesi sorunu olarak ele alın.

Adım 3'teki değiştirme yöntemi dört özel harfi ele alır, ancak Unicode harf dönüşümü kurallarının tam bir uygulaması değildir. ICU üzerine kurulu kütüphaneler ve locale ayarı sunan araçlar, elle yazılmış bir sarmalayıcıdan daha fazla uç durumu kapsar. Kullandığınız bir araçta zaten doğru bir Türkçe locale seçeneği varsa onu kullanın ve yalnızca test setini saklayın. Channable, DataFeedWatch veya Productsup'ın Türkçe locale'i nasıl ele aldığını test etmedik, bu yüzden bu konuda bir iddiada bulunmuyoruz; test setini, herhangi bir araca yaptığınız gibi onlara karşı da çalıştırın. Pazaryerlerinin bunun üzerine kendi başlık kuralları vardır; bunları Akakçe, Cimri, N11 ve ÇiçekSepeti feed'leri rehberlerimizde ele aldık.

SSS

İZMİR'i küçük harfe çevirince neden i̇zmi̇r oluyor?

Varsayılan Unicode küçük harf dönüşümü, noktalı büyük İ harfini normal bir i artı üstte birleşen bir noktaya (U+0307) eşler. Türkçe kural ise İ harfini düz bir i yapar. Sonuç ekranda neredeyse doğru görünür, ancak fazladan kod noktaları içerir.

Google Merchant Center, birleşen nokta içeren başlıkları reddeder mi?

Bununla ilgili belgelenmiş bir ret bulamadık. Dize geçerli UTF-8 olduğu için "Invalid UTF-8 encoding" hatasını tetiklemez. Zarar, yanlış yazılmış başlıklar ve kendi araçlarınızdaki başarısız eşleşmelerdir.

Başlıkları büyük harf, küçük harf ya da başlık biçimiyle mi göndermeliyim?

Google, vurgu için büyük harf kullanılmamasını ve kullanıcıların genellikle yalnızca ilk 70 veya daha az karakteri gördüğü için en önemli ayrıntıların başa konmasını söylüyor. Doğru Türkçe harflerle cümle düzeni ya da başlık biçimi bunu karşılar. Hangisinin daha iyi dönüştürdüğü, kendi hesabınızda yapacağınız bir testin konusudur.

JavaScript'te toLowerCase("tr") yeterli mi?

Hayır. toLowerCase() locale almaz. toLocaleLowerCase("tr") kullanın ve varsayılan değer ortama bağlı olduğu için locale'i açıkça verin.

setlocale neden PHP'nin strtolower fonksiyonunu düzeltmiyor?

PHP 8.2'den itibaren strtolower() locale'i yok sayar ve yalnızca ASCII harfleri dönüştürür. mb_strtolower() ASCII dışı metni işler, ancak testimizde İSTANBUL için yine i̇stanbul döndürdü. Çağırmadan önce Adım 3'teki karakter değiştirmeyi uygulayın.

Unicode normalizasyonu başıboş noktayı kaldırabilir mi?

Hayır. Testimizde NFC, i ve U+0307'yi iki kod noktası olarak bıraktı. Karakteri açıkça kaldırın, ardından düzeltilmiş harf dönüşümü kuralını özgün kaynak metin üzerinde yeniden çalıştırın.

Bu durum Arapçayı veya diğer dilleri etkiler mi?

Kural Türkçe ve Azerbaycan Türkçesi için geçerlidir. Diğer dillerin kendi harf dönüşümü ve normalizasyon sorunları vardır; bu rehber onları kapsamaz.

Kaç test satırı yeterli?

Türkçeye özgü her harfi ve alabileceği her konumu kapsayacak kadar: kelime başı, ortası, sonu ve bir rakamın yanı. Çoğu katalog için bu 10 ila 15 başlıktır. Üretimde yeni bir hata ortaya çıktığında bir satır ekleyin.

Kendi feed'inizi kontrol edin

Mevcut feed'inizin başlık ve öznitelik kalitesinde nasıl bir puan aldığını görmek istiyorsanız, onu ücretsiz ürün feed'i denetim aracımızdan geçirin.