Lo scenario
Sei il proprietario di un negozio online, con sede in Polonia. La maggior parte dei tuoi clienti proviene dalla Polonia e parla polacco. Ma vuoi vendere i tuoi prodotti anche all'estero e i tuoi clienti internazionali parlano principalmente inglese. Quindi vuoi che il tuo negozio online sia disponibile in entrambi i pollici e inglese . Ti aspetti anche che i tuoi prodotti vendano bene in Francia, quindi prevedi che dovrai preparare un francese anche la versione del negozio (e forse in spagnolo anche perché perché no?).
Vuoi che i tuoi utenti possano passare dalla versione polacca
alla versione inglese e ritorno.
E ovviamente vuoi che i dettagli del prodotto passino dal polacco all'inglese.
Come si crea un'applicazione Web multilingue?
Ci sono due tipi di testo nell'applicazione. Uno è statico dati:etichette dei pulsanti, intestazioni di tabelle, grafici (che spesso contengono testo). L'altro è il definito dall'utente dati, come nome del prodotto, prezzo del prodotto, descrizione del prodotto e così via. I dati sono normalmente presi dal database.
I dati statici sono ciò che vorresti scrivere come una stringa letterale nel tuo output. I dati definiti dall'utente sono dati che prendi dal tuo database.
Non parlerò di dati statici oggi. Qualsiasi framework web ragionevole gestirà l'internazionalizzazione dei dati statici. Consulta la documentazione del framework della tua applicazione web per i dettagli. Cerca parole chiave come "internazionalizzazione", "i18n", "localizzazione" o "traduzioni".
Oggi parlerò della struttura del database che usiamo solitamente qui su e-point per gestire i dati multilingua. Nel database del tuo negozio, probabilmente hai il product tabella che memorizza le informazioni su tutti i prodotti disponibili nel negozio.
Il product la tabella ha colonne come name , description e price . Quando traduci le informazioni sul prodotto in altre lingue, devi solo tradurre alcune colonne. Qui tradurresti solo il name e description , ma il price non cambia quando cambi lingua.
Quando aggiungiamo il supporto per più lingue, aggiungiamo una nuova tabella chiamata language_version , che memorizza tutte le versioni linguistiche disponibili nello store. Di solito aggiungiamo una colonna chiamata code e uno chiamato is_default (con un vincolo appropriato:solo una versione può essere quella predefinita).
Successivamente, dividiamo il product tabella in due tabelle:tabella product e tabella product_lv . Per ogni prodotto, ci sarà una riga nel product tabella e più righe nel product_lv tavolo; una riga per ogni versione linguistica. La tabella product_lv contiene solo colonne che devono essere tradotte:name e description . Le colonne indipendenti dalla lingua (come price , perché vendi allo stesso prezzo indipendentemente dal fatto che il tuo cliente parli inglese o polacco) rimani nella tabella product .
Facciamo lo stesso per ogni tabella che contiene dati tradotti. I dati tradotti vanno alla table_lv tabella, i dati indipendenti dalla lingua rimangono nella tabella principale.
Pro e contro
Uno svantaggio evidente è che tutte le operazioni di creazione, recupero, aggiornamento o eliminazione (CRUD) diventano un po' più complicate. Devi sempre unirti con una tabella delle versioni linguistiche aggiuntive per ottenere la descrizione giusta.
Il vantaggio di questo design è che non devi modificare lo schema del database quando aggiungi una nuova versione della lingua. Non sto dicendo che aggiungere una nuova versione linguistica sia facile. Dopotutto, devi tradurre TUTTE le descrizioni dei prodotti. Questa è una sfida organizzativa, ma dal punto di vista del database è abbastanza facile:tanti inserti.
Come si progettano i database multilingue?
