ICANN ha pubblicato due nuovi set di Second-Level Reference Label Generation Rules, le regole di riferimento usate per valutare come possono essere formate le etichette dei domini internazionalizzati al secondo livello. I nuovi LGR riguardano lo script Javanese e lo script Unified Canadian Aboriginal Syllabics; nello stesso aggiornamento ICANN ha modificato anche sette LGR gia esistenti.
La notizia puo sembrare molto tecnica, ma ha un impatto concreto per chi lavora con registry, registrar, marketplace e portafogli domini. Gli IDN non sono soltanto una questione di inclusione linguistica: sono un problema operativo di validazione, varianti, prevenzione della confusione visiva e coerenza tra cio che un registro permette, cio che un registrar vende e cio che le applicazioni finali riescono davvero a gestire.
Leggi anche: IDN e Universal Acceptance: ICANN misura la sfida dei domini multilingue
Cosa sono gli LGR di secondo livello
Gli LGR, Label Generation Rules, definiscono quali caratteri possono comporre un'etichetta valida in un determinato script o lingua e come devono essere trattate le varianti. Nel contesto dei domini, il punto e evitare che un nome apparentemente corretto venga accettato da un sistema e rifiutato da un altro, oppure che varianti troppo simili producano collisioni, confusione o opportunita di abuso.
Gli LGR di secondo livello non decidono da soli la politica commerciale di un'estensione, ma offrono un riferimento comune. Un registry puo usarli per costruire o aggiornare le proprie IDN table; un registrar puo usarli per ridurre errori in fase di ricerca e registrazione; un marketplace puo usarli per mostrare nomi multilingue senza trattarli come eccezioni ingestibili.
ICANN spiega che questi reference LGR servono a rendere piu trasparente e coerente il processo di revisione delle tabelle IDN e a facilitare le operazioni dei registri. E' un passaggio importante perche, senza regole condivise, ogni attore della filiera finisce per risolvere gli stessi problemi in modo diverso.
Javanese, UCAS e i sette aggiornamenti
Il nuovo rilascio aggiunge regole per Javanese e per Unified Canadian Aboriginal Syllabics, uno script usato per diverse lingue indigene del Canada. In parallelo, ICANN ha aggiornato gli LGR relativi a script arabo, lingua araba, lingua inuktitut, lingua giapponese, script giapponese, script latino e script latino con full variant set.
Il dettaglio numerico aiuta a capire la scala del lavoro: ICANN indica ora una copertura complessiva di 30 script e 32 lingue nei Second-Level Reference LGR pubblicati. Non e ancora l'intero universo linguistico di Internet, ma e una base sempre piu ampia per gestire domini multilingue con criteri tecnici documentati.
Leggi anche: IDN e LGR: perche la consultazione ICANN parla di accesso reale ai domini multilingue
Questo aggiornamento arriva dopo una fase di consultazione pubblica. La differenza rispetto alla discussione preliminare e' proprio qui: il tema passa dal "quali regole servono" al "quali regole sono ora disponibili come riferimento operativo". Per i registri che vogliono servire comunita linguistiche specifiche, il documento non e solo policy: diventa materiale da integrare nei processi tecnici.
Perche interessa a registry e registrar
Per un registry, un IDN non e semplicemente un dominio con caratteri non ASCII. Ogni carattere puo avere varianti, forme simili, relazioni con altri script e rischi di confusione. Se la policy non e chiara, si possono creare nomi difficili da distinguere, blocchi incoerenti o esperienze utente fragili. Se invece la policy e troppo restrittiva, una comunita linguistica puo non trovare nomi naturali nella propria scrittura.
Per un registrar il problema e diverso ma collegato. La ricerca del dominio deve sapere cosa proporre, cosa rifiutare, quando avvisare l'utente e come gestire le varianti. Anche il supporto clienti cambia: un errore di registrazione IDN puo essere piu difficile da spiegare rispetto a un normale dominio ASCII non disponibile.
I marketplace e gli investitori dovrebbero osservare lo stesso fenomeno con prudenza. Gli IDN possono aprire domanda locale reale, ma non tutti i nomi multilingue sono automaticamente liquidi. Servono compatibilita tecnica, domanda end-user, chiarezza di visualizzazione, gestione delle varianti e Universal Acceptance nei servizi usati dagli acquirenti.
Il collegamento con Universal Acceptance
Gli LGR risolvono una parte del problema: quali etichette sono valide e come si trattano le varianti. La Universal Acceptance riguarda invece il passaggio successivo: quei domini devono funzionare nei form, nelle email, nei sistemi di login, negli strumenti di analytics, nei CMS, nei marketplace e nelle interfacce di supporto.
Un dominio IDN puo essere tecnicamente registrabile e comunque incontrare ostacoli se un'applicazione non lo accetta correttamente. Per questo le due dimensioni vanno lette insieme. Gli LGR danno regole a monte; la Universal Acceptance misura la capacita dell'ecosistema di non rompere l'esperienza a valle.
Leggi anche: ICANN pubblica le linee guida UA: il test ora passa ai sistemi di registri e registrar
Il round 2026 dei nuovi gTLD rende il tema ancora piu rilevante. Ogni nuova estensione che punta a comunita linguistiche, mercati locali o identita culturali dovra dimostrare non solo di avere una stringa interessante, ma anche di saper gestire regole, varianti e compatibilita. Un TLD multilingue senza infrastruttura applicativa rischia di diventare una promessa difficile da usare.
La lettura Webinvest
La lettura Webinvest e' che gli IDN stanno uscendo dalla categoria "tema di principio" per entrare nella categoria "infrastruttura da mantenere". Un dominio multilingue vale davvero se puo essere registrato, risolto, digitato, mostrato, trasferito, venduto e usato senza attriti sproporzionati. Gli LGR di secondo livello sono uno dei mattoni necessari per arrivarci.
Per i registry, questo significa investire in policy e implementazione, non solo in marketing. Per i registrar, significa migliorare ricerca, carrello, controlli e assistenza. Per i domain investor, significa evitare l'errore di valutare gli IDN solo come scarsita linguistica: la domanda potenziale deve incontrare sistemi capaci di supportarla.
Il dato piu importante non e soltanto l'aggiunta di Javanese e UCAS. E' il fatto che ICANN continui a costruire una libreria di regole piu ampia e documentata. Ogni nuovo script coperto rende Internet un po' meno dipendente dall'alfabeto latino; ogni aggiornamento riduce l'incertezza per chi deve trasformare quella possibilita in prodotti, registrazioni e siti funzionanti.
Fonte: ICANN.
← Tutte le news