Come progettare un sistema pronto per la localizzazione

In questa era di globalizzazione, le aziende, inclusi gli sviluppatori di software, sono sempre interessate ad espandersi in nuovi mercati. Questo spesso significa localizzare i loro prodotti per aree diverse. In questo articolo spiegheremo alcuni approcci alla progettazione del modello di dati per la localizzazione, in particolare per la gestione dei contenuti in più lingue.

Cos'è la localizzazione?

La localizzazione è il processo di adattamento di un prodotto a vari mercati. È un fattore importante per raggiungere la massima quota di mercato in termini di vendite di prodotti. Quando la localizzazione viene eseguita correttamente, gli utenti sentiranno che il prodotto è stato realizzato per la loro lingua, cultura e necessità.

Nei luoghi in cui l'inglese non è una lingua madre comune, i sondaggi hanno dimostrato che le lingue locali sono di gran lunga preferite per un prodotto software. Questo articolo di MediaPost contiene alcune cifre interessanti sulla necessità di lingue diverse dall'inglese quando si tratta di vendite internazionali.

Cosa puoi perdere quando non localizzi?

Consideriamo uno sfortunato esempio di non localizzazione. Per comodità dei clienti, un portale di e-commerce ha consentito ai clienti di raggruppare i singoli acquisti in un gruppo di quattro. Sfortunatamente, la pronuncia della parola "quattro" in giapponese suona come la loro parola per "morte". I giapponesi in genere evitano tutte le cose associate a questo numero perché è considerato sfortunato. Inutile dire che le vendite di questi prodotti non sono andate bene nel mercato giapponese.

Quindi, in risposta alla domanda precedente, potresti perdere molto se non pianifichi attentamente il tuo mercato di riferimento.

Traduzione dei contenuti come localizzazione

Quando pensiamo alla localizzazione, la traduzione dei contenuti è spesso il primo pensiero che ci viene in mente. Il secondo pensiero è "Abbiamo bisogno di un modello di database robusto ed efficiente per archiviare i contenuti tradotti in più lingue".

Supponiamo che ci venga chiesto di progettare un modello di dati per un'applicazione di e-commerce multilingue. Avremmo bisogno di memorizzare campi di testo come product_name e la descrizione dei prodotti in varie lingue. Dovremmo anche memorizzare i campi di testo in altre tabelle, come il customer tabella, in tutte queste lingue.

Per capire come progettare il nostro modello di dati tenendo presente la traduzione dei contenuti, esamineremo diversi approcci utilizzando queste due tabelle. Ognuno di questi approcci ha pro e contro. Gli approcci illustrati di seguito possono essere estesi ad altre tabelle nel modello di dati. Naturalmente, l'approccio esatto che sceglierai sarà basato sulle tue esigenze.

Approccio 1:aggiunta di colonne di lingua separate per ogni campo previsto

Questo è l'approccio più semplice in termini di sviluppo. Può essere implementato aggiungendo una colonna di lingua per ogni campo.

Pro

• È molto facile da implementare.

• Non vi è alcuna complessità nella scrittura di SQL per recuperare i dati sottostanti in qualsiasi lingua. Supponiamo di voler scrivere una query per recuperare i dettagli del prodotto e del cliente per un particolare ordine in lingua francese. Il codice sarebbe simile a questo:

  Select p.product_name_FR, p.description_FR, p.price, 
         c.name_FR, c.address_FR, c.contact_name 
  from order_line o, product p, customer c
  	Where o.product_id = p.id and o.customer_id = c.id
  	And id = ;
  

Contro

• Non c'è scalabilità:ogni volta che viene aggiunta una nuova lingua, è necessario aggiungere dozzine di colonne aggiuntive tra le tabelle.
• Può richiedere molto tempo, soprattutto se molti campi devono avere più lingue.

• Gli sviluppatori finiscono per scrivere la query mostrata di seguito per gestire tutte le lingue esistenti. Pertanto, tutti gli SQL nell'applicazione devono cambiare quando viene introdotta una nuova lingua. (Nota: @in_language indica la lingua corrente dell'applicazione; questo parametro proviene dal front-end dell'app, mentre il back-end sta recuperando i record.)

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN p.product_name_FR
                WHEN ‘DE’ THEN p.product_name_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN c.name_FR
                WHEN ‘DE’ THEN c.name_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND id = ;
  

Approccio 2:creare una tabella separata per il testo tradotto

In questo approccio, viene utilizzata una tabella separata per memorizzare il testo tradotto; nell'esempio seguente, abbiamo chiamato questa tabella translation . Contiene una colonna per ogni lingua. I valori che sono stati tradotti dai valori dei campi in tutte le lingue applicabili vengono archiviati come record. Invece di memorizzare il testo tradotto effettivo nelle tabelle sottostanti, memorizziamo il suo riferimento alla translation tavolo. Questa implementazione ci consente di creare un repository comune del testo tradotto senza apportare troppe modifiche al modello di dati esistente.

Pro

• È un buon approccio se la localizzazione deve essere implementata su un modello di dati esistente.
• Una singola colonna aggiuntiva nella translation table è l'unica modifica necessaria quando viene introdotta una nuova lingua.
• Quando il testo originale è lo stesso nelle tabelle, non c'è testo tradotto ridondante. Ad esempio:supponiamo che il nome di un cliente e il nome di un prodotto siano identici. In questo caso, verrà inserito un solo record nella tabella di traduzione e lo stesso record è riferito sia al customer e product tabelle.

Contro

• Richiede ancora una modifica nel modello di dati.
• Potrebbero esserci NULL non necessari nella tabella. Se sono necessari 1.000 campi per una sola lingua supportata, finisci per creare 1.000 record e molti NULL.

• La complessità della scrittura di SQL aumenta all'aumentare del numero di join. E quando ci sono molti record nella translation tabella, i tempi di recupero sono più lenti.

  Scriviamo di nuovo un SQL per l'istruzione del problema di gestione del linguaggio:

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN tp.text_FR
                WHEN ‘DE’ THEN tp.text_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN tc.text_FR
                WHEN ‘DE’ THEN tc.text_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c, translation tp, translation tc
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
  	AND id = ;
  
  

Una variante dell'approccio alla tabella di traduzione

Per ottenere prestazioni migliori durante il recupero del testo tradotto, possiamo dividere la translation tabella in più tabelle. Possiamo raggruppare i record in base al dominio, ovvero una tabella per customer , un altro per product , ecc.

Approccio 3:una tabella di traduzione con righe per ogni lingua

Questa implementazione è abbastanza simile al secondo approccio, ma memorizza i valori per il testo tradotto in righe anziché in colonne. Qui, la translation l'id della tabella rimane lo stesso per un valore di campo in qualsiasi lingua tradotta. Una chiave primaria composita {id , language_id } è memorizzato nella tabella di traduzione e memorizza lo stesso translation_id per ogni campo rispetto a più language_id .

Pro

• Questa implementazione consente agli sviluppatori di scrivere facilmente SQL per il recupero dei dati.
• È anche facile scrivere OEM per questo modello.
• Non sono necessarie modifiche al modello di dati quando aggiungi una nuova lingua; basta inserire i record per la nuova lingua.
• Non c'è un consumo di memoria non necessario quando un insieme di campi non è applicabile a una lingua.

• La complessità degli SQL di recupero dati è ridotta. Guarda l'esempio qui sotto:

  SELECT tp.text,
          p.price,
         tc.text,
          c.contact_name
  FROM order_line o, product p, customer c, translation tp, 
       translation tc, language l
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
               AND tp.language_id = l.id
               AND tc.language_id = l.id
               AND l.name = @in_language
  	AND id = ;
  
  

Contro

• Per recuperare i dati tradotti è necessario un numero relativamente elevato di join.
• Nel tempo, un numero enorme di record potrebbe essere potenzialmente archiviato nella translation tavolo. Poiché esiste una sola tabella di traduzione, tutto il testo tradotto verrà scaricato al suo interno. Quando hai milioni di campi da tradurre e la tua applicazione supporta un gran numero di lingue, interrogare una tabella per una traduzione sarebbe un'attività che richiede tempo. Tuttavia, puoi dividere la tabella di traduzione in base alle lingue o alle aree tematiche, come abbiamo sottolineato alla conclusione del secondo approccio.

E se combiniamo gli approcci 2 e 3?

Nello specifico, combineremo la variante dell'Approccio 2, suddividendo la translation tabella – con l'idea di utilizzare le righe in una tabella. Possiamo facilmente superare lo svantaggio di avere enormi record nella translation tabella creando più tabelle basate su un dominio, come abbiamo fatto nella variante Approccio 2. Se nella tabella di traduzione basata sul dominio è presente un numero considerevole di record, è possibile suddividere ulteriormente le tabelle in base ai singoli campi.

Approccio n. 4:creazione di livelli di entità per campi tradotti e campi non tradotti

In questa soluzione, le tabelle di entità che contengono uno o più campi tradotti sono suddivise in due livelli:uno per i campi tradotti e un altro per i campi non tradotti. In questo modo creiamo livelli separati per ciascuno.

Pro

• Non è necessario unire le tabelle di traduzione se si tratta solo di campi non tradotti. Pertanto, i campi non tradotti ottengono prestazioni migliori.
• Per recuperare i testi tradotti è necessario un numero relativamente inferiore di join.
• È facile scrivere OEM.
• Gli SQL per recuperare il testo tradotto sono semplici.
• Questo è un approccio collaudato per incorporare più lingue tra entità.

Per dimostrare il punto, ecco una query di esempio che recupererà il testo tradotto:

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = ;

Localizzazione:andare oltre la traduzione dei contenuti

La localizzazione non significa solo tradurre il contenuto della tua applicazione in un'altra lingua. Ci sono anche parametri culturali e funzionali che richiedono attenzione. Ad esempio, un valore di data è formattato come "MM/GG/AAAA" in Nord America, ma nella maggior parte dell'Asia è scritto come "GG/MM/AAAA".

Un altro esempio riguarda la visualizzazione dei nomi nell'intestazione dell'applicazione. Negli Stati Uniti, chiamare qualcuno per nome è accettabile o addirittura preferito; in questa cultura, il nome del cliente viene visualizzato nell'intestazione non appena il cliente effettua l'accesso. In Giappone, invece, le cose sono invertite:chiamare qualcuno per nome è scortese o addirittura offensivo. La localizzazione ne terrà conto ed eviterà l'uso dei nomi per il pubblico giapponese dell'applicazione.

Potrebbe essere necessario archiviare i parametri di localizzazione nel back-end dell'applicazione. Questo è proprio il caso quando devi progettare una logica di programma attorno alla localizzazione. Probabilmente possiamo classificare tutti questi parametri in categorie culturali e funzionali e costruire il modello di dati attorno ad essi.

Un altro pensiero sulla localizzazione

La localizzazione è necessaria quando un marchio globale penetra nei mercati locali. Per localizzare un'applicazione, guarda il quadro generale. La localizzazione è più di una semplice prestazione tecnicamente perfetta. Significa anche avere padronanza delle culture, dei comportamenti e persino dei modi di pensare e di vivere locali.

Cos'altro si può fare per rendere un'applicazione adattabile localmente? Fateci sapere che ne pensate nei commenti.