# General Translation Knowledge Base: Checklist per il test di localizzazione delle app multilingue URL: https://generaltranslation.com/it/kb/multilingual-app-launch-checklist.mdx Docs index: https://generaltranslation.com/llms.txt Description: Verifica nove aspetti in ogni impostazione regionale supportata su una build di produzione: percorsi completi, inclusi gli stati di errore e le email, cambio di lingua, plurali, valuta e fusi orari, espansione del testo, layout right-to-left, accessibilità, distribuzione delle traduzioni e URL per lingua scansionabili. Assegna a ogni verifica 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. ## Video The video is narrated in English, with English captions. [What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33 s) Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated. ## 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. Usate i [controlli delle stringhe hardcoded](/kb/find-hardcoded-strings) per individuare le stringhe letterali nella lingua di origine prima della verifica manuale. **Condizione 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, i revisori correggono la formulazione nell'[Editor di traduzione della Dashboard](/docs/platform/dashboard/guides/reviewing-translations). Condividete [termini di Glossario e prompt personalizzati](/docs/platform/dashboard/guides/defining-context-for-translations) tra i progetti dell'app e delle email prima di generare nuove traduzioni. Le modifiche al contesto valgono per le nuove traduzioni; rivedete deliberatamente la formulazione esistente anziché dare per scontato che sia cambiata anch'essa. ### 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. La [guida al rilevamento della lingua](/kb/detect-user-language) illustra la corrispondenza delle preferenze; la [guida al selettore di lingua](/kb/language-switcher) illustra le scelte esplicite e la navigazione accessibile. **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. ### 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. Nelle librerie React di GT, [``](/docs/react/reference/components/plural) seleziona le forme plurali specifiche dell'impostazione regionale, [``](/docs/react/reference/components/branch) mantiene le alternative condizionali all'interno dell'unità di traduzione e [``](/docs/react/reference/components/var) sostituisce localmente i valori dinamici. Testa ogni alternativa, non solo la frase predefinita; i valori inseriti dall'utente e racchiusi in [``](/docs/react/reference/components/var) non devono necessariamente essere inviati all'API di traduzione. **Condizione 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. Per i messaggi basati su catalogo, testa anche i rami dei tuoi [messaggi ICU](/kb/icu-message-format). (Consulta [Come gestire i plurali in React?](/kb/how-to-handle-plurals-in-react) per un pattern basato sui componenti.) ## 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. Cambiare la lingua dell'UI non deve modificare l'importo dovuto né il momento in cui si verifica un evento. I componenti [``](/docs/react/reference/components/currency) e [``](/docs/react/reference/components/datetime) di GT applicano una formattazione locale-aware con opzioni esplicite per valuta e fuso orario: testa queste scelte esattamente come faresti con le chiamate `Intl` riportate sopra. ### 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. **Condizione 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](/kb/pseudo-localization) 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. La [guida di Lingui](https://lingui.dev/guides/pseudolocalization) mostra un esempio di implementazione. ### 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. La [guida al CSS RTL](/kb/right-to-left-css) tratta spaziature, icone e valori con direzione mista. **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. Conserva le credenziali degli strumenti di traduzione nell'ambiente di build, al di fuori dei bundle per il browser. Con GT, esegui [`gt validate`](/docs/cli/reference/commands/validate), quindi [`gt translate`](/docs/cli/reference/commands/translate) prima della build. Puoi configurare la build in modo che si interrompa se la traduzione non va a buon fine. [`gt generate`](/docs/cli/reference/commands/generate) genera solo i modelli di origine. Se i revisori modificano l'output locale, usa [`gt save-local`](/docs/cli/reference/commands/save-local) per conservare queste modifiche nelle esecuzioni successive. Testa il percorso di aggiornamento che hai configurato: [Locadex](/docs/platform/locadex/guides/configuring-automations) dovrebbe creare o aggiornare la propria pull request di traduzione quando attivi il trigger configurato (push, pull request o manuale). Verifica che venga tracciato il branch previsto. Con le [traduzioni incluse nel bundle](/docs/react/guides/storing-translations), l'app distribuita può renderizzare i file forniti indipendentemente dal servizio di GT. Con la consegna tramite CDN, testa le modifiche pubblicate in base alla versione e alle impostazioni della cache, compreso l'eventuale ritardo prima che raggiungano gli utenti. ### 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](/kb/what-is-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; la [guida alla struttura degli URL](/kb/multilingual-url-structure) li mette a confronto. 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 (vedi [reindirizzamenti linguistici e SEO](/kb/locale-routing-seo)). 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. Il [Report Card](https://generaltranslation.com/report-card) gratuito di GT offre una prima valutazione della localizzazione di un sito pubblico, ma non può esaminare i percorsi che richiedono autenticazione né attivare deliberatamente i tuoi scenari di errore. ## 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. Ecco un esempio di registro compilato: | Build | Impostazione regionale | Controllo | Dispositivo | Atteso | Effettivo | Esito | | ---------------- | ---------------------- | ---------------------------------- | --------------- | --------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------- | | 4.12.0 (a1b2c3d) | `de` | 1. Carta rifiutata al checkout | Chrome, desktop | Errore in tedesco con azione per riprovare | Errore in tedesco, etichetta del pulsante troncata a 320px | Non superato: blocca il rilascio, responsabile assegnato | | 4.12.0 (a1b2c3d) | `pl` | 3. Carrello con 2, 5 e 22 articoli | Safari, iPhone | Forme polacche few e many | Forma `few` mostrata per 5 articoli | Non superato: correggere le chiavi del plurale | | 4.12.0 (a1b2c3d) | `ar` | 6. Impostazioni dell'account | Chrome, Android | Layout speculare, freccia indietro rivolta a destra | Come previsto | Superato | ## Related questions - [Come si trovano le stringhe hardcoded non tradotte?](https://generaltranslation.com/it/kb/find-hardcoded-strings.mdx): Esegui in CI un linter che segnali i letterali stringa visibili all'utente, come la regola no-literal-string di eslint-plugin-i18next per JSX, il controllo HardcodedText di Android Lint o il linter HardCodedString di erb_lint per Rails. Poi naviga nell'app con una pseudo-impostazione regionale per individuare il testo che i controlli statici non riescono a tracciare. - [Best practice per il selettore della lingua: UX, SEO e accessibilità](https://generaltranslation.com/it/kb/language-switcher.mdx): Indica ogni lingua con il suo nome nativo, ad esempio Deutsch o 日本語, ed evita le bandiere, che rappresentano paesi. Collega ogni opzione alla stessa pagina in quella lingua tramite un link scansionabile, memorizza la scelta in un cookie e non reindirizzare mai automaticamente un URL localizzato. - [Che cos'è la pseudo-localizzazione?](https://generaltranslation.com/it/kb/pseudo-localization.mdx): La pseudo-localizzazione è un test che sostituisce il testo di origine con una versione alterata, con caratteri accentati, allungata di circa il 40% e racchiusa tra parentesi quadre, così che stringhe hardcoded, troncamenti, font che non vengono visualizzati correttamente e frasi concatenate emergano prima ancora che esista una traduzione. Android include a questo scopo le pseudo-impostazioni regionali en-XA e ar-XB. - [Come si supportano le lingue RTL (right-to-left) in CSS?](https://generaltranslation.com/it/kb/right-to-left-css.mdx): Imposta dir="rtl" e lang sull'elemento html, perché lang da solo non cambia la direzione, poi sostituisci le proprietà CSS fisiche come margin-left con proprietà logiche come margin-inline-start. Le righe flex, le colonne della griglia e l'allineamento predefinito del testo si invertono da sole; translateX(), left e right no. - [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 proprio URL con prefisso, come /en/about e /es/about, quindi pubblica html lang, un canonical autoreferenziale, alternative hreflang con x-default, un titolo e una descrizione tradotti e una voce nella mappa del sito per ogni lingua pubblicata. Contrassegna con noindex le versioni non pubblicate. gt-next di General Translation instrada ogni lingua verso il proprio URL e traduce i titoli con getGT. ## Previous and next questions - Previous question: [Alternative a Transifex: General Translation vs. Transifex](https://generaltranslation.com/it/kb/general-translation-vs-transifex.mdx) - Next question: [Conviene creare un sistema i18n in autonomia o usare General Translation?](https://generaltranslation.com/it/kb/general-translation-vs-in-house-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.