globalize è ora nel Nimdzi Language Technology Radar

Nimdzi ha verificato globalize.now e l'ha inserito nel Language Technology Radar, il catalogo della società di analisi dedicato ai prodotti di language technology. globalize.now è un'infrastruttura di localizzazione basata su IA, e Nimdzi la classifica in due punti: tra gli strumenti di localizzazione per sviluppatori e tra gli strumenti LLM per la localizzazione. In questo post: cos'è il Radar, dove si colloca globalize e perché la localizzazione code-native è diventata una categoria a sé.

Cos'è il Nimdzi Language Technology Radar?

Il Radar è un database live di language technology, curato da Nimdzi Insights. Ha sostituito il vecchio Language Technology Atlas, una fotografia annuale del mercato, con un catalogo aggiornato di continuo. L'edizione 2026 riporta oltre 1.100 prodotti di 756 aziende.

I prodotti sono raggruppati in undici categorie, dai translation management system e dalla traduzione automatica fino al riconoscimento vocale e ai sistemi di interpretariato. Diverse categorie hanno sottocategorie, e un prodotto compare dove rientra la sua offerta principale, non ovunque una delle sue funzionalità possa adattarsi.

Come viene verificato uno strumento?

L'azienda invia i propri dati, e i ricercatori di Nimdzi li verificano confrontandoli con le informazioni pubbliche, con i briefing con il fornitore e con l'uso diretto degli strumenti. L'inserimento è gratuito. Nimdzi dichiara di non accettare commissioni per influenzare schede, classifiche o recensioni, ed è per questo che un inserimento ha peso per gli acquirenti.

Per globalize questo ha significato un giro di domande dal team del Radar prima che il profilo fosse segnato come completo. Su quali modelli e motori gira la traduzione. Se i controlli di qualità funzionano anche fuori dalla piattaforma. Come le correzioni vengono riportate sulle traduzioni future. Le categorie riflettono quelle risposte, non un'autodescrizione.

Dove si colloca globalize nel Radar?

globalize compare in due categorie.

Translation Management Systems, localizzazione per sviluppatori. Questa sottocategoria raccoglie gli strumenti pensati per i team di ingegneria, non per i team di traduttori. La differenza sta in dove avviene il lavoro. Un TMS classico è un workspace separato in cui le stringhe vengono sincronizzate in entrata e in uscita. globalize lavora nel repository, quindi il risultato è una pull request con i file delle lingue, non un export da una dashboard.

Large Language Models, strumenti LLM per la localizzazione. globalize usa i modelli linguistici per la traduzione e per un secondo passaggio di revisione che controlla significato, placeholder, termini del glossario e aderenza alla guida di stile in ogni lingua. La categoria è per gli strumenti in cui il modello è applicato specificamente al lavoro di localizzazione, non a una chat generica.

Puoi leggere il profilo sul sito di Nimdzi.

Perché la localizzazione per sviluppatori è una categoria a sé?

Perché sono cambiate le persone che rilasciano le stringhe. Qualche anno fa un team di prodotto passava i testi a un localization manager, che li faceva passare da un TMS e restituiva i file. Oggi un solo founder rilascia di martedì un'app Next.js costruita con Cursor o Lovable e la vuole in giapponese entro venerdì. Non c'è nessun localization manager, e nessuno vuole un'altra dashboard da tenere sincronizzata.

Questo cambiamento crea un «job to be done» diverso, cioè un bisogno concreto da risolvere.

classic TMS:  code  →  export strings  →  TMS workspace  →  translators  →  import files  →  code
globalize:    code  →  push  →  translated pull request  →  merge

Il lavoro lato sviluppo ha due parti. Prima di tutto, la codebase deve essere pronta per la localizzazione, e le app generate dall'IA di solito non lo sono. Arrivano con stringhe hardcoded nei componenti, senza chiavi e senza file di traduzione. globalize se ne occupa una volta sola, nell'app, quando connetti il repository. Poi, ogni modifica successiva va tradotta senza che nessuno debba ricordarsene. Dopo il setup, ogni push con testo nuovo o modificato torna come pull request con le traduzioni, già riviste dal passaggio IA e pronte per il merge.

Quindi globalize è un TMS?

No, anche se Nimdzi inserisce la sottocategoria per sviluppatori sotto la voce TMS. globalize si colloca tra la tua libreria i18n e il tuo motore di traduzione. Librerie come next-intl e i18next servono le traduzioni a runtime, e globalize continua a lavorare con quella che usi già. I translation management system come Lokalise e Crowdin gestiscono i flussi di lavoro dei traduttori. globalize produce e mantiene chiavi e file di traduzione, quindi un team senza traduttori non ha bisogno di quel livello di workflow. Se stai confrontando i due approcci, il confronto con Lokalise ne analizza le differenze.

Cosa fa globalize in un repository?

Si connette a GitHub o GitLab, analizza il repository e configura l'i18n se l'app ne ha bisogno, inviando la modifica su un branch da rivedere. Se l'app usa già next-intl, react-i18next, i18next o Lingui, mantiene quel setup e si limita a tradurre.

Da quel momento, tre eventi avviano un job di traduzione, tutti configurabili da te.

1. Un push con testo nuovo o modificato su un branch monitorato.
2. Una pull request, se attivi questa opzione.
3. Un job manuale dalla dashboard.

Ogni job traduce solo ciò che è nuovo o modificato. Le stringhe già presenti nella translation memory vengono riutilizzate e non vengono fatturate di nuovo. Il tuo glossario e le guide di stile per lingua si applicano a ogni job, e il passaggio di revisione segnala tutto ciò che richiede un intervento umano prima di arrivare al branch predefinito. Il risultato arriva come pull request che modifica solo i tuoi file di localizzazione.

I formati coprono web e mobile: JSON, gettext PO, XLIFF, YAML, Flutter ARB, string catalog Apple e risorse stringa Android. Il prezzo è per workspace, senza costi per utente, e la pagina dei prezzi riporta i piani attuali.

Perché un inserimento da parte di un analista conta, se sei uno sviluppatore?

Per la maggior parte degli sviluppatori cambia poco. Giudicherai globalize dalla prima pull request, e la prova gratuita serve proprio a questo. L'inserimento conta per altri due gruppi.

Il primo sono i team con un responsabile della localizzazione. Un localization manager che valuta strumenti legge Nimdzi, e un profilo indipendente e verificato gli dice che il prodotto esiste, funziona come descritto e rientra in una categoria che riconosce. È una conversazione più breve di una demo a freddo.

Il secondo sono gli acquirenti che lasciano un TMS classico. I team che passano da Lokalise o Phrase a un setup code-native vogliono sapere che l'alternativa sia reale prima di spostare un catalogo in produzione. Un inserimento nel Radar è uno dei pochi segnali, in questo mercato, che il fornitore non può scrivere da solo.

Quali sono i prossimi passi?

Nimdzi gestisce anche un TMS Feature Explorer, un profilo funzione per funzione di ogni strumento, e la scheda di globalize è in lavorazione. Quando sarà online mostrerà, voce per voce, cosa copre globalize e cosa deliberatamente non copre, come gli editor per traduttori e la gestione dei fornitori, che esulano da ciò per cui è pensato uno strumento code-native.

Nel frattempo, il modo più rapido per valutarlo è provarlo sul tuo codice. Connetti un repository, lascia che globalize esegua il setup e leggi la prima pull request tradotta.