Come mettere in minuscolo i titoli prodotto turchi senza rompere İ e ı: il playbook delle feed rule

Google consente un titolo prodotto da 1 a 150 caratteri e chiede ai merchant di non usare lettere maiuscole per dare enfasi (Merchant Center Help). I cataloghi turchi esportati dai sistemi ERP sono spesso scritti tutti in maiuscolo, quindi la soluzione più ovvia è una regola che metta in minuscolo o in title case ogni titolo. È proprio qui che i dati turchi si rompono senza far rumore. Nel nostro test, il lowercase predefinito di İZMİR ÇİZGİLİ KIŞLIK MONT ha restituito 30 code point invece di 25, e ISPARTA è diventato isparta invece di ısparta. Questa guida è per i feed manager e gli sviluppatori che gestiscono testi di prodotto in turco. Alla fine saprai testare il tuo stack, correggere la regola di casing e aggiungere un controllo che intercetti il problema a ogni sincronizzazione.

Perché il turco manda in crisi le regole di casing standard

Il turco ha due coppie di lettere distinte: la ı senza punto con la maiuscola I, e la i con il punto con la maiuscola İ. Il file Unicode sulle mappature maiuscolo/minuscolo lo dice chiaramente: "I e i senza punto; I con punto e i sono coppie maiuscolo/minuscolo in turco e azero" (Unicode SpecialCasing.txt).

Il casing predefinito (indipendente dalla lingua) non lo sa. Trasforma I in i e İ in i più un punto combinante in alto (U+0307). Le regole turche dello stesso file trasformano I in ı e İ in una semplice i. L'azero segue la stessa regola.

In un feed vanno storte tre cose:

• Lettere sbagliate. KADIN diventa kadin, YAĞI diventa yaği. La parola resta leggibile, ma è scritta in modo errato.
• Caratteri in più. İZMİR diventa i̇zmi̇r, una stringa con due code point extra praticamente invisibili. A schermo sembra quasi giusta, ma non corrisponde a izmir in un filtro, in un join o in una ricerca.
• Maiuscole sbagliate nella direzione opposta. istanbul diventa ISTANBUL invece di İSTANBUL, e il title case produce Iç invece di İç.

Passo 1: scopri cosa fa oggi il tuo stack

Prima di modificare qualsiasi regola, verifica come si comporta il codice che trasforma i tuoi titoli. Abbiamo passato gli stessi due input nei runtime usati dalla maggior parte delle pipeline di feed. L'input era ISPARTA İSTANBUL per il lowercase e istanbul ışık per l'uppercase.

Due dettagli contano. Primo: il semplice toLocaleLowerCase() di JavaScript, senza argomenti, usa la locale predefinita, quindi lo stesso codice può comportarsi in modo diverso su un server e su un laptop. La documentazione mostra che "İstanbul".toLocaleLowerCase("en-US") restituisce i̇stanbul e che toLocaleLowerCase("tr") restituisce istanbul (MDN). Passa sempre "tr" in modo esplicito.

Secondo: PHP 8.2 ha modificato strtolower() in modo che non dipenda più da setlocale() e converta solo i caratteri ASCII (manuale PHP). Impostare una locale turca non cambia nulla in una versione recente.

Passo 2: crea un test set con titoli reali

Prendi da 10 a 15 titoli dal tuo catalogo che coprano ogni lettera specifica del turco: İ, I, ı, i, Ş, Ğ, Ç, Ö, Ü. Includi un titolo che inizia con I, uno che inizia con İ e uno con un'unità di misura come ML o GB. Ecco un set di partenza, con il risultato del lowercase predefinito accanto a quello corretto.

Guarda l'ultima riga. Differisce una sola lettera, e un controllo a occhio su pochi titoli la farebbe sfuggire con facilità. Per questo il test set deve coprire ogni lettera, e per questo si confrontano le stringhe, non le impressioni.

Passo 3: correggi la funzione di casing

Dove lo strumento ti permette di scegliere la locale, impostala su tr. Dove non puoi, incapsula tu la trasformazione. In JavaScript o Node la correzione è un solo argomento:

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

I metodi standard delle stringhe di Python non hanno un argomento per la locale. Una soluzione affidabile è sostituire le quattro lettere speciali prima di chiamare il metodo predefinito. Abbiamo testato questa versione sulle prime quattro righe qui sopra:

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

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

L'ordine conta. Sostituisci prima İ e I, poi passa in minuscolo. Se metti in minuscolo per primo, l'informazione su quale fosse la maiuscola originale è già persa.

Passo 4: gestisci title case e unità di misura separatamente

Il title case aggiunge due problemi. Mettere in maiuscolo la prima lettera di ogni parola richiede l'uppercase turco, altrimenti iç çamaşırı diventa Iç Çamaşırı con il title() di Python. Inoltre una regola generica mette in maiuscolo le unità: 50 ML diventa 50 Ml.

Lo schema che usiamo è questo: metti in minuscolo l'intero titolo con la funzione turca, metti in maiuscolo la prima lettera di ogni parola con la funzione turca e salta qualsiasi token che inizia con una cifra o compare in una breve lista di unità (ml, gb, cm, kg). Su ISPARTA GÜL YAĞI 50 ML il risultato è Isparta Gül Yağı 50 ml. Senza la lista di unità, la stessa pipeline restituisce 50 Ml. Nota che Isparta è corretto: il nome della città inizia con una I maiuscola senza punto.

I nomi dei brand sono un caso a parte. Un brand scritto volutamente in maiuscolo (IKEA, HP) richiede una lista di esclusioni, perché Google chiede solo di evitare le maiuscole per enfasi e di usarle comunque dove appropriato, ad esempio per le abbreviazioni (Merchant Center Help). Tieni la lista breve e conservala nello stesso posto della regola.

Se gestisci queste regole in uno strumento di feed management, verifica come applica il casing. Le feed rules di Feedance elencano uppercase, sentence case e iniziali maiuscole tra le opzioni, e la pagina non indica quale locale usino: per questo eseguiamo questo test set su qualsiasi strumento, compreso il nostro, prima di affidargli testi in turco. Per una visione più ampia di quando basta una regola e quando vale la pena usare un modello di AI, leggi il nostro confronto tra titoli prodotto basati su regole e con AI.

Passo 5: individua i danni residui nei dati esistenti

Se una regola sbagliata è già stata eseguita, il punto combinante è ormai nei dati memorizzati. La normalizzazione Unicode non lo rimuove: nel nostro test, i seguita da U+0307 è rimasta di due code point dopo la normalizzazione NFC, perché non esiste una forma precomposta in cui combinarli. Devi trovarlo e rimuoverlo.

Questo controllo segnala ogni titolo che contiene il punto combinante in alto:

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

Dopo aver rieseguito la regola corretta su İZMİR, lo stesso controllo restituisce false. Eseguilo su title, description, brand, product_type e su qualsiasi campo custom_label, dato che le regole di casing spesso vengono applicate a più campi dei soli titoli.

Separatamente, se un canale segnala un errore di codifica, si tratta di un altro problema. La pagina "Invalid UTF-8 encoding" di Merchant Center indica che la causa è un problema nella codifica del testo e invita a dichiarare o convertire la codifica del file (Merchant Center Help). Il bug del casing produce UTF-8 valido, quindi non farà scattare quell'errore. Passa in silenzio, ed è per questo che bisogna testarlo.

Passo 6: trasformalo in un controllo a ogni sincronizzazione

Una correzione che nessuno ricontrolla regredirà la prima volta che qualcuno aggiunge una regola o cambia strumento. Usa questa checklist come gate di rilascio per qualsiasi modifica alle regole su titolo, descrizione o nome della categoria.

Il controllo sulla lunghezza intercetta i code point extra aggiunti dal lowercase predefinito. È una spia comoda anche quando non sai ancora quale regola abbia causato la modifica.

Dove questo metodo mostra i suoi limiti

Questo è un metodo per il turco e l'azero, le due lingue che il file Unicode elenca per questa regola. Non copre i campi in alfabeto arabo; per quelli, vedi come strutturare i dati prodotto in arabo e inglese.

Non abbiamo prove che Google o un marketplace rifiutino un prodotto a causa di una i con o senza punto sbagliata. I costi documentati sono indiretti: titoli scritti in modo errato davanti agli acquirenti e stringhe che non corrispondono più ai tuoi filtri, join e alla ricerca interna. Trattalo come un problema di qualità dei dati, non di policy.

Il trucco della sostituzione nel Passo 3 gestisce le quattro lettere speciali, ma non è un'implementazione completa delle regole di casing Unicode. Le librerie basate su ICU e gli strumenti che espongono un'impostazione della locale coprono più casi limite di un wrapper scritto a mano. Se uno strumento che usi ha già un'opzione corretta per la locale turca, usala e conserva solo il test set. Non abbiamo testato come Channable, DataFeedWatch o Productsup gestiscano la locale turca, quindi non facciamo affermazioni in un senso o nell'altro; esegui il test set su di loro come faresti con qualsiasi strumento. I marketplace hanno poi le loro regole sui titoli, che si aggiungono a queste, trattate nelle nostre guide ai feed per Akakçe, Cimri, N11 e ÇiçekSepeti.

FAQ

Perché İZMİR diventa i̇zmi̇r quando lo metto in minuscolo?

Il lowercase Unicode predefinito trasforma la İ maiuscola con il punto in una normale i più un punto combinante in alto (U+0307). La regola turca trasforma İ in una semplice i. Il risultato sembra quasi corretto a schermo, ma contiene code point in più.

Google Merchant Center rifiuta i titoli con il punto combinante?

Non abbiamo trovato alcun rifiuto documentato per questo motivo. La stringa è UTF-8 valido, quindi non fa scattare l'errore "Invalid UTF-8 encoding". Il danno sono i titoli scritti in modo errato e i match falliti nei tuoi strumenti.

Devo inviare i titoli in maiuscolo, minuscolo o title case?

Google dice di non usare lettere maiuscole per enfasi e di mettere per primi i dettagli più importanti, dato che gli utenti di solito vedono solo i primi 70 caratteri o meno. Sentence case o title case con le lettere turche corrette soddisfano entrambi questo requisito. Quale converta meglio è un test da fare sul tuo account.

In JavaScript basta toLowerCase("tr")?

No. toLowerCase() non accetta una locale. Usa toLocaleLowerCase("tr") e passa la locale in modo esplicito, perché quella predefinita dipende dall'ambiente.

Perché setlocale non risolve strtolower di PHP?

Da PHP 8.2, strtolower() ignora la locale e converte solo le lettere ASCII. mb_strtolower() gestisce il testo non ASCII ma, nel nostro test, ha comunque restituito i̇stanbul per İSTANBUL. Applica la sostituzione dei caratteri del Passo 3 prima di chiamarla.

La normalizzazione Unicode può rimuovere il punto in più?

No. Nel nostro test, NFC ha lasciato i più U+0307 come due code point. Rimuovi il carattere in modo esplicito, poi riesegui la regola di casing corretta sul testo sorgente originale.

Questo problema riguarda anche l'arabo o altre lingue?

La regola vale per il turco e l'azero. Le altre lingue hanno i loro problemi di casing e normalizzazione, che questa guida non copre.

Quante righe di test bastano?

Quante ne servono per coprire ogni lettera specifica del turco e ogni posizione che può occupare: inizio parola, centro, fine e accanto a una cifra. Per la maggior parte dei cataloghi sono da 10 a 15 titoli. Aggiungi una riga ogni volta che emerge un nuovo difetto in produzione.

Controlla il tuo feed

Se vuoi vedere come il tuo feed attuale si comporta in termini di qualità di titoli e attributi, passalo nel nostro strumento gratuito di audit del feed di prodotto.