# General Translation Knowledge Base: Cosa devo verificare prima di lanciare un'app multilingue? URL: https://generaltranslation.com/it/kb/multilingual-app-launch-checklist.mdx Docs index: https://generaltranslation.com/llms.txt Description: Prima di lanciare un'app multilingue, verifica nove aspetti in ogni impostazione regionale supportata: percorsi utente completi, inclusi gli errori, rilevamento e cambio di lingua, variabili e plurali, valuta e fusi orari, espansione del testo, layout right-to-left, accessibilità, distribuzione delle traduzioni in produzione e URL per lingua scansionabili ai fini SEO. Per ogni verifica serve un criterio di superamento esplicito. Category: Internazionalizzazione Last updated: 2026-10-16 Authors: Jackie Chen Published: 2026-10-16 Una homepage tradotta può sembrare pronta mentre il checkout, gli errori di convalida o il flusso di reimpostazione della password sono ancora nella lingua di origine. Parti dai percorsi che un utente deve portare a termine e testali nella build di produzione. Prima di lanciare un'app web multilingue, verifica questi nove aspetti in ogni impostazione regionale supportata: 1. **I percorsi sono tradotti dall'inizio alla fine**, inclusi gli stati di caricamento, vuoti e di errore, le email e le notifiche. 2. **La selezione della lingua è coerente** alla prima visita, dopo il cambio di lingua e nelle visite successive. 3. **Variabili e plurali sono corretti** per ogni categoria di plurale prevista dalle tue lingue. 4. **Valuta e fuso orario sono impostati esplicitamente**, indipendentemente dalla lingua della UI. 5. **I layout reggono l'espansione del testo** su schermi stretti e con lo zoom del browser. 6. **Le lingue con scrittura da destra a sinistra** hanno direzione, layout e testo bidirezionale corretti. 7. **Le tecnologie assistive ricevono la lingua corretta**, oltre a etichette e nomi accessibili. 8. **La build di produzione include traduzioni complete** e i nuovi testi vengono tradotti prima del rilascio. 9. **Le pagine pubbliche hanno URL per lingua scansionabili** con metadati tradotti e `hreflang`. Testa i contenuti in ogni impostazione regionale supportata e verifica layout e interazione su dispositivi e browser rappresentativi. La verifica 9 riguarda solo le pagine pubbliche che vuoi far indicizzare. ## Verifica il comportamento di contenuti e lingue ### 1. Traducete l'intero percorso, inclusi gli stati di errore Scegliete un percorso critico, come la creazione di un account o il completamento di un acquisto. Verificatene gli stati di caricamento, vuoto, successo ed errore. Controllate pulsanti, finestre di dialogo, convalida dei moduli, segnaposto, etichette per l'accessibilità ed eventuali email o notifiche inviate durante il percorso. **Criterio di superamento:** ogni area del prodotto utilizza contenuti revisionati nella lingua di destinazione, salvo eccezioni intenzionali come il nome di un prodotto. Non compaiono chiavi grezze, marcatori di messaggi mancanti né fallback ingiustificati nella lingua di origine. **Con General Translation:** verificate che la versione inclusa nel rilascio sia l'output di [`gt translate`](/docs/cli/reference/commands/translate). ([`gt generate`](/docs/cli/reference/commands/generate) si limita a scrivere i modelli di origine, che vanno comunque completati con il testo tradotto.) I revisori correggono la formulazione nell'[Editor di traduzione della Dashboard](/docs/platform/dashboard/guides/reviewing-translations); se invece il vostro team modifica i file generati direttamente nel repository, eseguite [`gt save-local`](/docs/cli/reference/commands/save-local) in modo che le esecuzioni successive conservino tali modifiche. Per mantenere coerente la terminologia di prodotto tra app, documentazione e notifiche, assegnate termini di Glossario e prompt personalizzati condivisi tramite i [gruppi di contesto](/docs/platform/dashboard/guides/defining-context-for-translations) prima di generare le traduzioni. Le modifiche al contesto valgono per le nuove traduzioni e non riscrivono quelle esistenti. ### 2. Verifica le prime visite, il cambio di lingua e le visite successive Esegui i test con un browser pulito, una scelta esplicita della lingua, un ricaricamento della pagina, un deep link e una lingua del browser non supportata. Se l'app salva una preferenza di lingua nell'account, verifica anche l'accesso e la disconnessione. Annota quale impostazione prevale quando URL, preferenza salvata e browser non coincidono. **Condizione di superamento:** l'app applica questa regola in modo coerente e l'utente può rimediare a una scelta di lingua indesiderata. Per le app server-rendered, ispeziona sia la risposta iniziale sia la pagina dopo l'idratazione. Gli identificatori delle impostazioni regionali seguono lo standard BCP 47: `es-MX` ed `es-AR` possono essere target distinti per lo spagnolo messicano e per quello argentino. Verifica ogni target regionale che rilasci. Un selettore basato su cookie e le route con prefisso dell'impostazione regionale rispondono a esigenze diverse: controlla come l'app gestisce effettivamente gli URL. **Con General Translation:** definisci le lingue supportate, compresi i target regionali, nella [configurazione delle impostazioni regionali](/docs/react/guides/managing-locales). ### 3. Mettere alla prova variabili e categorie di plurale Testa conteggi come 0, 1, 2 e valori più grandi, quindi aggiungi casi per le categorie di plurale delle tue lingue di destinazione. Includi nomi con segni di punteggiatura, nomi di account lunghi e frasi in cui le variabili possono comparire in un ordine diverso dopo la traduzione. Evita di comporre una frase concatenando frammenti tradotti separatamente. **Criterio di superamento:** i valori restano intatti, la frase risulta corretta e ogni forma plurale richiesta ha un contenuto utilizzabile. Le [regole del plurale](https://cldr.unicode.org/index/cldr-spec/plural-rules) di Unicode spiegano perché una sola coppia di test singolare/plurale in inglese non basta. **Con General Translation:** [``](/docs/react/reference/components/plural) segue le regole del plurale dell'impostazione regionale: l'inglese ha due categorie cardinali, mentre l'arabo ne ha sei. Usa [``](/docs/react/reference/components/branch) quando la formulazione dipende da un valore esplicito, come il genere grammaticale di una persona, e [``](/docs/react/reference/components/var) per il testo dinamico, come un nome. I valori racchiusi in questo componente non vengono inviati all'API di traduzione. L'[articolo sulla pluralizzazione in React](/kb/how-to-handle-plurals-in-react) illustra il pattern di implementazione. ## Verifica formattazione, layout e accessibilità ### 4. Separa lingua, valuta e fuso orario Testa lo stesso importo e lo stesso istante con più impostazioni regionali. Imposta esplicitamente la valuta e il fuso orario previsti, dove il tuo prodotto li richiede. La sola preferenza linguistica non dice in quale valuta paga un cliente né a quale fuso orario fa riferimento un appuntamento. Ad esempio, questo codice formatta un importo esistente in USD secondo le convenzioni tedesche: ```js new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'USD', }).format(1234.5); ``` Formatta l'importo fornito senza effettuare conversioni di valuta. La formattazione può arrotondare le cifre visualizzate, quindi verifica il livello di precisione richiesto dal tuo prodotto. Allo stesso modo, specifica esplicitamente un fuso orario quando mostri un istante riferito a una località specifica: ```js new Intl.DateTimeFormat('en-GB', { dateStyle: 'medium', timeStyle: 'short', timeZone: 'Europe/Paris', }).format(new Date('2026-01-15T12:00:00Z')); ``` **Condizione di superamento:** separatori, valuta, data di calendario e ora visualizzata corrispondono al significato previsto dal prodotto. Includi un passaggio all'ora legale se i fusi orari supportati lo prevedono. Le API per i [numeri](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat) e per le [date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) espongono queste opzioni separatamente. **Con General Translation:** [``](/docs/react/reference/components/currency), [``](/docs/react/reference/components/datetime) e [``](/docs/react/reference/components/num) formattano i valori in base al locale attivo. Imposta valuta e fuso orario in base al significato che devono avere per la tua attività: cambiare la lingua dell'UI non deve modificare l'importo dovuto né il momento in cui si verifica un evento. ### 5. Verifica l'espansione del testo su schermi di diverse dimensioni Apri le schermate tradotte su viewport stretti e con lo zoom del browser attivo. Controlla la navigazione, i pulsanti, le tabelle, le finestre di dialogo e i messaggi di convalida. Includi stringhe tradotte lunghe e valori lunghi inseriti dall'utente: un titolo breve non mette alla prova il layout quanto un indirizzo completo. **Criterio di superamento:** il testo essenziale rimane leggibile e i controlli restano utilizzabili. Nessuna azione scompare dietro testo tagliato o elementi sovrapposti. Valuta il troncamento caso per caso, invece di usarlo per nascondere qualsiasi overflow. La [pseudolocalizzazione](https://lingui.dev/guides/pseudolocalization) può aiutare a far emergere problemi di layout e stringhe non contrassegnate prima che le traduzioni siano pronte. Affianca i test con le lingue reali, senza sostituirli, e non garantisce la qualità della traduzione. ### 6. Testa i contenuti right-to-left come requisito di layout Se supporti l'arabo, l'ebraico o un'altra lingua right-to-left, testa la direzione del documento, l'ordine di navigazione, i moduli e i contenuti con direzione mista, come indirizzi email e ID degli ordini. Usa le proprietà logiche CSS dove il layout deve seguire la direzione del testo e verifica le icone direzionali una per una. **Condizione di superamento:** il layout segue la direzione di lettura prevista e i valori left-to-right incorporati restano leggibili. Impostare il codice lingua non basta a impostare la direzione del testo: segui le [linee guida del W3C sulla direzione in HTML](https://www.w3.org/International/questions/qa-html-dir). ### 7. Controlla la lingua ricevuta dalle tecnologie assistive Verifica l'attributo `lang` della pagina, gli eventuali cambi di lingua all'interno dei contenuti, le etichette visibili, i nomi accessibili e il testo alternativo. Prova a navigare il percorso principale da tastiera e con uno screen reader. Un segnaposto tradotto non può sostituire un'etichetta di modulo sempre visibile. **Condizione di superamento:** il documento dichiara la lingua corretta, i controlli hanno nomi localizzati significativi e il layout tradotto rimane utilizzabile. Il W3C illustra le [dichiarazioni di lingua](https://www.w3.org/International/questions/qa-html-language-declarations), mentre le sue [linee guida sulle etichette dei moduli](https://www.w3.org/WAI/tutorials/forms/labels/) spiegano come associare correttamente le etichette. ## Verifica il rilascio che riceveranno gli utenti ### 8. Verifica gli asset di produzione e gli aggiornamenti delle traduzioni Esegui la build da un checkout pulito seguendo il processo di rilascio, quindi avvia quella build con ciascuna impostazione regionale supportata. Verifica che gli asset di traduzione siano presenti e vengano caricati correttamente. Modifica un messaggio sorgente in un branch di test e verifica che la pipeline di traduzione rilevi la modifica prima del rilascio successivo. **Condizione di superamento:** l'app fornisce le traduzioni previste senza dipendere da file residui dello sviluppo. Asset mancanti o una generazione non riuscita causano un errore visibile o un fallback esplicitamente accettato, anziché un rilascio parziale senza alcun avviso. **Con General Translation:** esegui [`gt validate`](/docs/cli/reference/commands/validate) per intercettare gli errori supportati nelle traduzioni inline prima di una chiamata API, quindi inserisci il [passaggio di traduzione incrementale prima della build](/docs/cli/guides/generating-translations). Questo passaggio riutilizza le traduzioni precedenti e traduce i contenuti modificati, così i nuovi testi possono essere distribuiti già tradotti nello stesso rilascio che li introduce. Il [tracciamento dei branch](/docs/cli/guides/branching) mantiene separati i branch di sviluppo paralleli. Le [automazioni di Locadex](/docs/platform/locadex/guides/configuring-automations) possono gestire gli aggiornamenti delle traduzioni tramite pull request. Nell'ambito di questo controllo del rilascio, testa il trigger configurato modificando un testo sorgente. Con il [flusso di lavoro di archiviazione locale](/docs/react/guides/storing-translations), l'app fornisce le traduzioni incluse nel bundle senza chiamate a General Translation in fase di runtime; gli aggiornamenti vengono distribuiti con una nuova build. Con la consegna tramite CDN, le modifiche pubblicate possono raggiungere l'app senza un nuovo deploy, in base alla versione delle traduzioni e alle impostazioni della cache. Testa questo percorso di aggiornamento. Conserva le credenziali private degli strumenti di traduzione nell'ambiente di build, al di fuori dei bundle per il browser. ### 9. Verifica la reperibilità delle versioni linguistiche pubbliche Per le pagine destinate ai motori di ricerca, verifica che ogni versione linguistica abbia un URL scansionabile, titoli e descrizioni tradotti, l'URL canonical previsto e alternative linguistiche valide. Controlla che i riferimenti `hreflang` siano reciproci e includano anche la pagina corrente. Se le alternative sono dichiarate in una sitemap, verifica che questa rispecchi le stesse relazioni tra le pagine. **Condizione di superamento:** ogni URL linguistico pubblico carica il contenuto previsto, è indicizzabile quando necessario e rimanda a versioni alternative effettivamente esistenti. Le [linee guida di Google sulle pagine localizzate](https://developers.google.com/search/docs/specialty/international/localized-versions) descrivono i metodi di annotazione supportati. Per un'implementazione in Next.js, consulta la [guida alla SEO multilingue](/kb/multilingual-nextjs-seo). Prefissi di percorso, sottodomini linguistici e domini nazionali consentono di avere URL distinti per ciascuna lingua. Un'intestazione `Accept-Language` o un cookie possono determinare la lingua di un visitatore, ma da soli non creano un URL scansionabile per ogni versione. Le [linee guida di Google sui siti multilingue](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) raccomandano URL separati. Una dashboard accessibile solo previa autenticazione potrebbe non aver bisogno di URL linguistici indicizzati: scegli la strategia di routing in base al pubblico del prodotto. ## Tieni un registro dei rilasci Registra la build, l'impostazione regionale, il percorso utente, il browser o il dispositivo, il risultato atteso, il risultato effettivo e il revisore. Assegna un responsabile a ogni errore. Una traduzione mancante nel checkout o un'azione principale illeggibile vanno trattate diversamente da una semplice preferenza di formulazione; inoltre, rendi esplicito ogni fallback accettato. Per una prima verifica rapida di un sito pubblico, il [Report Card](https://generaltranslation.com/report-card) gratuito di General Translation ne valuta la localizzazione. Non può analizzare i flussi autenticati né gli stati di errore, quindi affiancalo ai controlli sui percorsi descritti sopra. ## Domande frequenti ### Come si testa un'app multilingue? Esegui percorsi utente completi in ogni impostazione regionale supportata su una build di produzione, compresi gli stati di errore, le email e le notifiche. Verifica plurali, variabili, valute, fusi orari, layout, testo right-to-left e accessibilità, e definisci un criterio di superamento per ciascun controllo. ### Qual è il bug di localizzazione che sfugge più spesso? Gli stati di errore non tradotti. Messaggi di errore, convalida dei moduli, stati vuoti ed email transazionali restano spesso nella lingua di origine anche dopo che le schermate principali sono state tradotte. Verificali in modo mirato nel controllo 1. ### Che cos'è la pseudolocalizzazione? La pseudolocalizzazione sostituisce il testo di origine con un testo segnaposto più lungo e ricco di caratteri accentati, così puoi individuare problemi di overflow nel layout e stringhe non contrassegnate prima ancora di avere le traduzioni vere e proprie. Non sostituisce però i test con lingue reali. Consulta la [guida alla pseudolocalizzazione di Lingui](https://lingui.dev/guides/pseudolocalization). ### Le pagine multilingue richiedono URL separati per la SEO? Sì, per le pagine che vuoi far indicizzare. Google consiglia di usare un [URL separato per ogni versione linguistica](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), collegandoli tramite `hreflang`. Un cookie o l'intestazione `Accept-Language`, da soli, non generano versioni scansionabili. Per Next.js, consulta [SEO multilingue con Next.js](/kb/multilingual-nextjs-seo). ## Related questions - [Qual è la migliore libreria i18n per un'app React?](https://generaltranslation.com/it/kb/best-react-i18n-library.mdx): Le quattro principali librerie i18n per React sono gt-react di General Translation, react-i18next, Lingui e React Intl. Tutte e quattro renderizzano e formattano le traduzioni, ma solo gt-react è anche in grado di generarle, a partire dai testi scritti inline nel tuo JSX. Scegli react-i18next per continuare a usare i cataloghi e i plugin di i18next, Lingui per l'estrazione in cataloghi compilati e React Intl per FormatJS e ICU MessageFormat. - [Posso fare i18n senza file di traduzione?](https://generaltranslation.com/it/kb/i18n-without-translation-files.mdx): Sì. Con gt-react o gt-next, i contenuti restano inline nei tuoi componenti, all'interno di un componente ``, e le traduzioni vengono generate come output in fase di compilazione. Non ci sono quindi chiavi né file JSON per ogni impostazione regionale da scrivere e mantenere sincronizzati. - [Come si gestiscono i plurali in React?](https://generaltranslation.com/it/kb/how-to-handle-plurals-in-react.mdx): Non inserire la logica del plurale direttamente nel codice con controlli come n === 1. Per le app solo in inglese basta un semplice helper, ma le app multilingue richiedono regole del plurale locale-aware, che un componente i18n come `` di gt-react o gt-next gestisce per ogni lingua. - [Come si configura la SEO per un'app Next.js multilingue?](https://generaltranslation.com/it/kb/multilingual-nextjs-seo.mdx): Assegna a ogni lingua un URL dedicato, imposta l'attributo lang del tag html, fai puntare l'URL canonical di ogni pagina alla pagina stessa, aggiungi le alternative hreflang per ogni lingua, traduci titoli e descrizioni ed elenca tutte le versioni linguistiche nella sitemap. ## Previous and next questions - Previous question: [Conviene creare un sistema i18n in autonomia o usare General Translation?](https://generaltranslation.com/it/kb/general-translation-vs-in-house-i18n.mdx) - Next question: [General Translation e il framework di traduzione di Django: servono entrambi?](https://generaltranslation.com/it/kb/general-translation-vs-django-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.