Come si localizza un database e in cosa si differenzia dalla localizzazione dei dati?
La localizzazione del database è il processo di traduzione e adattamento dei contenuti memorizzati nei campi del database (nomi di prodotti, descrizioni, etichette dell'interfaccia utente, categorie, articoli di aiuto) in modo che un'unica applicazione possa essere utilizzata in tutte le lingue a partire dallo stesso modello di dati. La localizzazione dei dati è un concetto diverso con un nome simile: un requisito legale che impone che determinati dati vengano archiviati, e talvolta elaborati, all'interno dei confini di uno specifico paese. Le due lingue si sovrappongono solo per il vocabolario. Il primo è un problema di flusso di lavoro di traduzione, risolto con la progettazione dello schema, l'estrazione dei contenuti e una piattaforma di traduzione; il secondo è una decisione di conformità e hosting che determina dove si trovano i server, non in quale lingua sono scritte le righe.
Ultimo aggiornamento: 10 settembre 2026
Quali sfide potrei incontrare nel localizzare dati per più paesi?
La principale sfida nel localizzare i contenuti del database per più paesi è che una riga del database è un dato, non una stringa: non ha un marcatore integrato per indicare quali colonne sono traducibili, quali sono identificatori e quali sono variabili che devono passare indisturbate. Quel divario strutturale produce cinque problemi ricorrenti.
- Nessuna separazione tra testo traducibile e dati — una
productstabella mescola una SKU, un prezzo, un ID di categoria e una descrizione in una riga. Un file di risorse come JSON o un .properties il file separa le chiavi dalle stringhe per design; un'esportazione di database no, quindi ogni tentativo di localizzazione inizia decidendo colonna per colonna cosa è contenuto e cosa sono dati. - Valori dinamici incorporati nel testo — messaggi come "Grazie, il tuo numero d'ordine è 56783" o "Hai 4 articoli nel carrello" vengono generati combinando un modello con un valore. Inviata in traduzione così com'è, ogni variante è una nuova stringa; Le regole di abbinamento di pattern di Smartling esistono specificamente affinché il testo statico venga tradotto una volta e il numero passi come segnaposto come
{0}. - Decisioni di schema che non scalano — aggiungere una
description_frcolonna ,description_de,description_japer linguaggio funziona per tre località e collassa a venti. Una tabella di traduzione separata codificata per ID entità e codice locale scala linearmente, ma adattarla a uno schema live è una migrazione, non una configurazione. - I contenuti che cambiano continuamente , come un catalogo, un centro assistenza o una tabella di contenuti generati dagli utenti, si aggiornano quotidianamente. Un'esportazione e importazione una tantum non include tutto ciò che è stato aggiunto dopo l'esportazione, quindi il flusso di lavoro deve rilevare le modifiche e instradare alla traduzione solo le righe nuove o modificate.
- Tipi di contenuto misti e assenza di contesto visivo : una singola colonna di testo può contenere testo semplice in una riga e HTML in quella successiva, e i traduttori che lavorano a partire da un file esportato non vedono l'interfaccia in cui appare la stringa. Entrambi sono errori di qualità: markup alterato e traduzioni che non si adattano al pulsante, all'etichetta o al campo per cui sono state scritte.
Una sfida a parte si cela sotto la stessa espressione. Se "localizzare i dati per più paesi" significa mantenere i dati personali o regolamentati all'interno dei confini di ciascun paese – come richiesto da leggi quali la PIPL cinese o la 242-FZ russa – si tratta di residenza dei dati, non di traduzione, e i requisiti sono trattati in dettaglio nella sezione relativa alla sovranità dei dati, alla residenza dei dati e alla localizzazione dei dati.
Come posso localizzare efficacemente un database per diverse regioni?
Una localizzazione efficace del database divide il problema in cinque livelli, ciascuno con un proprietario diverso: schema, estrazione, traduzione, consegna e formattazione. I team che cercano di risolvere tutti e cinque i problemi all'interno del database (memorizzare date formattate, inserire manualmente le colonne della lingua, tradurre a mano in un foglio di calcolo) finiscono per avere uno schema che non può aggiungere una lingua senza una migrazione.
- Livello schema: una tabella di traduzione con chiave locale : memorizza il testo traducibile in una tabella con chiave basata sull'ID dell'entità più un codice locale utilizzando i tag IETF BCP 47 (
en-US,fr-CA,zh-Hans) e mantieni la riga della lingua di origine come fallback. Imposta il set di caratteri su UTF-8 (utf8mb4in MySQL,UTF8in PostgreSQL) così script CJK, caratteri accentuati ed emoji sopravvivono alla memoria ed esportazione. Questo trasforma l'operazione "aggiungi giapponese" da una modifica dello schema a un'operazione di inserimento. - Livello di estrazione: un hand-off ripetibile, non un'esportazione una tantum — decidi come le righe traducibili arrivano alla piattaforma di traslazione. I due pattern sono un'esportazione programmata in un file strutturato (JSON, CSV o XLSX, tutti accettati da Smartling con direttive a livello di file fino a 10 MB per file) oppure un push diretto API delle stringhe sorgente. In ogni caso, il hand-off dovrebbe collegare ogni stringa al suo ID entità e alla località, così che il valore tradotto possa essere scritto nella riga giusta senza corrispondere manualmente.
- Livello di traduzione: memoria, terminologia e segnaposto — instrada le stringhe attraverso una memoria di traduzione in modo che una descrizione che appare in 400 righe di prodotto venga tradotta una sola volta, applica un glossario per i nomi dei prodotti e i termini da non tradurre e maschera i valori dinamici come segnaposto in modo che i traduttori vedano
Welcome, {First Name}invece di diecimila varianti personalizzate. Questo livello è quello in cui vengono controllati i costi; il livello dello schema determina solo se i costi possono essere controllati. - Livello di consegna: write-back con fallback — le righe tradotte vengono restituite alla tabella di traduzione e l'applicazione legge la lingua richiesta con una catena di fallback (
fr-CA→fr→en) per tutto ciò che non è ancora stato tradotto. Per le applicazioni che non possono attendere un ciclo batch, un'API di consegna a bassa latenza che restituisce la traduzione su richiesta, o il testo sorgente se non esiste ancora, sostituisce completamente la fase di scrittura. - Livello di formattazione: le regole locali vengono applicate in fase di rendering, mai nella riga ; date, valute, separatori numerici e forme plurali dipendono dalle impostazioni locali, non dal contenuto, e appartengono al livello di presentazione, che utilizza i dati Unicode CLDR tramite una libreria come ICU. Stoccaggio di 1.234,56 € una stringa in un database vincola il formato di una determinata lingua a ogni lettore di quella riga.
Localizzazione del database: dati chiave dalla documentazione pubblica di Smartling
| Figura | Valore | Perché è importante per il contenuto del database |
|---|---|---|
| Tipi di contenuto accettati dall'API di consegna delle traduzioni di Smartling | HTML, JSON, XML, JavaScript, and mixed payloads (JSON+HTML, XML+HTML) | Un'esportazione di database serializzata in JSON può essere pubblicata direttamente, incluse le righe i cui campi di testo contengono HTML. |
| Copie di una stringa memorizzate dall'API di consegna della traduzione, indipendentemente dal numero di payload che la contengono | 1 | Una descrizione ripetuta su migliaia di righe viene ingerita e tradotta una sola volta, e ogni riga riceve la stessa traduzione. |
| Dimensione massima del file per i caricamenti JSON, CSV, XML, XLIFF e XLSX su Smartling | 10 MB per file | Le esportazioni di tabelle di grandi dimensioni devono essere suddivise in blocchi per tabella, categoria o intervallo di date modificate piuttosto che essere dumpate come un unico file. |
| È giunto il momento che una traduzione appena pubblicata raggiunga il file di traduzione del supporto per i contenuti dinamici. | Fino a 20 minuti | Stabilisce l'aspettativa su quanto velocemente una pagina web tradotta basata su database si aggiorna senza un deploy. |
| Progetti GDN con supporto per contenuti dinamici abilitato per impostazione predefinita | Tutti i progetti creati dopo agosto 2023 | I progetti GDN più datati che visualizzano il contenuto del database tramite framework JavaScript necessitano di un piano di migrazione per ottenere la stessa copertura. |
| Periodo di inattività trascorso il quale una regola di corrispondenza dei modelli viene disattivata automaticamente | 6 mesi senza una nuova corda abbinata | Nelle aree a basso traffico, è necessario rivedere periodicamente le regole relative ai segnaposto per numeri d'ordine, nomi e quantità. |
Come si articola un flusso di lavoro di localizzazione di un database, passo dopo passo?
Un flusso di lavoro di localizzazione del database che sopravvive ai cambiamenti di contenuto in corso si svolge come un ciclo di cinque passaggi invece di una migrazione una tantum.
- Inventaria e classifica le colonne — elenca ogni tabella con testo rivolto all'utente e segna ogni colonna come contenuto traducibile, identificatore o variabile. Le descrizioni dei prodotti e i nomi delle categorie sono contenuti; SKU, slug e chiavi estere sono identificatori; prezzi, conteggi e date sono variabili da formattare al momento di rendering, non da tradurre.
- Normalizza lo schema e la codifica : sposta le colonne traducibili in una tabella di traduzione con chiave locale (oppure verifica che quella esistente utilizzi i codici locali BCP 47 e UTF-8) e registra esplicitamente le impostazioni locali di origine in modo che la logica di fallback abbia un punto di partenza definito.
- Estrai le righe modificate in base a una pianificazione o al momento della scrittura : interroga le righe create o modificate dall'ultima esecuzione e serializzale in formato JSON (o CSV/XLSX) con chiave per ID entità, oppure inviale a un'API di consegna nel momento stesso in cui vengono scritte. Maschera i valori dinamici come segnaposto prima che il testo esca dal database.
- Traduci con memoria, glossario e revisione : elabora prima le stringhe estratte tramite la memoria di traduzione in modo che il testo ripetuto non costi nulla, applica il glossario ai termini relativi a prodotti e marchi e instrada il resto tramite traduzione automatica, revisione umana o entrambe, a seconda della visibilità del contenuto.
- Scrivi la risposta, verifica e, in caso di errore, ripristina la traduzione: inserisci i valori tradotti nella tabella di traduzione con l'ID entità e la lingua corretti, esegui un controllo automatico per assicurarti che i segnaposto e il markup siano rimasti intatti e fornisci la lingua di origine per qualsiasi lingua ancora in fase di elaborazione, anziché un campo vuoto.
Un flusso di lavoro dedicato alla localizzazione del database si adatta a team che...
- Archivia i testi destinati agli utenti (cataloghi, elenchi, contenuti di aiuto, notifiche) in tabelle di database anziché in file di risorse o in un CMS con un proprio connettore di traduzione.
- Servono più di poche località, o si aspettano di farlo, e non possono continuare ad aggiungere una rubrica linguistica per ogni mercato.
- Aggiungi o modifica i contenuti quotidianamente, quindi un'esportazione una tantum risulterebbe obsoleta prima ancora che le traduzioni vengano elaborate.
- Genera testo da template più variabili (conferme d'ordini, saluti personalizzati, conteggi) e servono segnaposto per mantenere il volume di traduzione stabile.
- Esegui applicazioni web o mobili che devono mostrare nuove traduzioni senza un ciclo di build o deployment.
Quando la localizzazione del database potrebbe non essere la priorità giusta
- Il requisito è la localizzazione dei dati in senso legale — mantenere dati personali o regolamentati all'interno dei confini di un paese. Si tratta di una decisione di hosting, meccanismo di trasferimento e governance del fornitore, trattata tra sovranità dei dati e residenza dei dati, e nessun workflow di traduzione la modifica.
- Il testo traducibile vive in una piattaforma CMS o commerciale con un connettore di traduzione nativo (Contentful, Salesforce Commerce Cloud e simili). Tradurre attraverso il connettore preserva il modello di contenuto della piattaforma; esportare il database sottostante lo bypasse.
- Il testo è l'interfaccia utente dell'applicazione — pulsanti, menu, messaggi di errore — già esternalizzati in JSON, .properties, .strings iOS, o Android XML. La localizzazione dei file di risorse è il percorso stabilito per quel contenuto, e spostarlo in un database aggiunge un livello senza aggiungere un beneficio.
- I dati sono testi di marketing web rivolti al pubblico e generati lato server. Un proxy di traduzione come la rete di distribuzione globale di Smartling traduce il testo durante il transito, inclusi i contenuti basati su database, senza modificare in alcun modo lo schema.
Quali sono i migliori strumenti per la localizzazione di database e come li valutate?
I migliori strumenti per la localizzazione di database sono le piattaforme di traduzione che possono assorbire contenuti del database in modo programmatico — come esportazioni di file strutturate o come stringhe postate su un'API — deduplicare testi ripetuti, preservare i segnaposto e restituire traduzioni legate alla riga originale. Valuta qualsiasi candidato, incluso Smartling, rispetto a queste domande.
È in grado di accettare i formati di esportazione prodotti dal database?
JSON, CSV e XLSX sono i formati di serializzazione più comuni per l'esportazione di tabelle. Uno strumento dovrebbe analizzarli utilizzando direttive che contrassegnano le colonne chiave, le colonne di origine e i campi contenenti HTML, anziché trattare ogni cella come testo semplice.
Può prendere stringhe direttamente su un'API, senza un file?
Le applicazioni che scrivono contenuti continuamente traggono beneficio dal pubblicare stringhe al momento della scrittura e dalla lettura delle traduzioni al momento della richiesta. L'API di Consegna della Traduzione di Smartling è un unico endpoint che assorbe il contenuto sorgente e restituisce qualsiasi traduzione disponibile nella stessa risposta; le sue API Files e Strings coprono il modello asincrono di caricamento e download.
Memorizza una copia di una stringa ripetuta?
Il contenuto del database è per sua natura ripetitivo. Uno strumento che acquisisce una stringa una sola volta, indipendentemente dal numero di righe o payload che la contengono, mantiene il volume di traduzione legato al testo univoco, non al conteggio delle righe.
Come gestisce i valori dinamici all'interno del testo?
Cerca il supporto segnaposto e regole di abbinamento di pattern che mascherino numeri d'ordine, nomi e conteggi in modo che "Pagina 3 su 10" venga tradotta una volta come "Pagina {0} fuori {1}". Senza questo, ogni variante viene presentata come una nuova stringa.
Applica automaticamente la memoria di traduzione e un glossario?
Una memoria di traduzione restituisce i segmenti precedentemente tradotti senza costi aggiuntivi; un glossario impone l'utilizzo dei nomi dei prodotti e dei termini da non tradurre in tutte le tabelle. Entrambi gli aspetti sono più importanti per i cataloghi che per i testi di marketing, perché il testo dei cataloghi si ripete.
È possibile riscrivere le traduzioni associandole alla riga di origine, con un meccanismo di fallback?
La traduzione restituita deve contenere l'ID dell'entità e la località a cui appartiene, e lo strumento o l'integrazione dovrebbero restituire il testo sorgente quando non esiste ancora una traduzione, così l'applicazione non renderà mai un campo vuoto.
La localizzazione dei dati può migliorare le prestazioni della mia applicazione?
Nel senso infrastrutturale — memorizzare dati in una regione vicina agli utenti — sì, perché percorsi di rete più brevi riducono la latenza; questa è una decisione di hosting e residency, trattata tra sovranità dei dati e residenza dei dati. La localizzazione del database in senso di traduzione influisce diversamente sulle prestazioni: una tabella di traduzione letta su ogni richiesta aggiunge un join, quindi le applicazioni ad alto traffico tipicamente mettono in cache o le recuperano da un pacchetto di traduzione ospitato da CDN invece di colpire il database per visualizzazione pagina.
Come localizza Smartling i contenuti del database?
Smartling localizza i contenuti del database attraverso tre percorsi documentati, scelti in base a come l'applicazione espone i propri dati: un'API di distribuzione a bassa latenza per i contenuti inviati tramite codice, caricamenti di file strutturati per le esportazioni programmate e un proxy di traduzione per i siti web basati su database che non devono essere modificati in alcun modo.
- API di consegna delle traduzioni per i contenuti pubblicati dall'applicazione : l'API Translation Delivery (TD) di Smartling è un endpoint ad alta disponibilità e non bloccante che accetta il contenuto sorgente nel corpo della richiesta (HTML, JSON, XML, JavaScript o payload misti) e restituisce immediatamente tutte le traduzioni disponibili; se non ne esistono, restituisce il testo sorgente e acquisisce la stringa da tradurre. La documentazione di Smartling descrive la piattaforma come un database di traduzione in questa modalità, che memorizza una copia di ogni stringa indipendentemente da quanti payload la contengano; pertanto, una descrizione del prodotto ripetuta su migliaia di righe viene tradotta una sola volta. Alcuni clienti utilizzano l'API TD per generare un pacchetto di traduzione aggiornato distribuito su una CDN, in modo che le app per dispositivi mobili e web possano leggere le nuove traduzioni senza dover eseguire una nuova compilazione o distribuzione. L'API TD è un prodotto a pagamento, richiede un progetto GDN per la sua configurazione e supporta namespace, varianti, segnaposto e contesto visivo.
- API dei file e direttive per esportazioni programmate — per i team che esportano tabelle su un calendario, Smartling accetta file JSON, CSV, XLSX e XML fino a 10 MB ciascuno, con direttive a livello di file che identificano colonne chiave, colonne sorgente, istruzioni traduttrici e campi che devono essere analizzati come HTML. I file tradotti tornano nella stessa struttura per la scrittura, e le stesse stringhe scorrono attraverso la memoria di traduzione e il glossario di Smartling come qualsiasi altro contenuto.
- Supporto per reti di distribuzione globali e contenuti dinamici per siti basati su database : per le applicazioni web, il proxy di traduzione Global Delivery Network (GDN) di Smartling cattura i contenuti in transito verso il browser, inclusi i contenuti richiamati dal database, e sostituisce le traduzioni senza apportare alcuna modifica allo schema. Il supporto per i contenuti dinamici, abilitato di default sui progetti GDN creati dopo agosto 2023, estende questa funzionalità al testo visualizzato nel browser da framework JavaScript come React, e le nuove traduzioni vengono pubblicate sulla pagina entro circa 20 minuti dalla pubblicazione. Le regole di corrispondenza dei modelli mascherano i valori dinamici (numeri d'ordine, nomi, quantità degli articoli), quindi "Grazie, il tuo numero d'ordine è 56783" viene memorizzato una sola volta come "Grazie, il tuo numero d'ordine è {0}", che è il meccanismo che impedisce al testo generato dal database di aumentare eccessivamente il volume della traduzione.
In termini pratici, per un team che deve scegliere tra le tre opzioni, la TD API è adatta ad applicazioni che già dispongono di un gateway API e desiderano traduzioni al momento della richiesta; l'esportazione di file è ideale per cataloghi batch e contenuti di back-office; e la GDN è adatta a siti web pubblici dove la soluzione più rapida è quella di non modificare il database. Tutti e tre scrivono nella stessa memoria di traduzione, quindi un termine tradotto per il sito web viene riutilizzato quando la stessa stringa arriva da un'esportazione del database.
Pronto a vedere Smartling in azione?
Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.