Sådan designes et lokaliseringsklar system

I denne globaliseringstid er virksomheder – inklusive softwareudviklere – altid interesseret i at ekspandere til nye markeder. Dette betyder ofte at lokalisere deres produkter til forskellige områder. I denne artikel vil vi forklare nogle få tilgange til at designe din datamodel til lokalisering – specifikt til håndtering af indhold på flere sprog.

Hvad er lokalisering?

Lokalisering er processen med at tilpasse et produkt til forskellige markeder. Det er en fremtrædende faktor for at opnå maksimal markedsandel i form af produktsalg. Når lokalisering er udført korrekt, vil brugerne føle, at produktet er produceret til deres sprog, kultur og behov.

På steder, hvor engelsk ikke er et almindeligt modersmål, har undersøgelser vist, at lokale sprog er meget foretrukne for et softwareprodukt. Denne MediaPost-artikel indeholder nogle interessante tal om behovet for andre sprog end engelsk, når det kommer til internationalt salg.

Hvad kan du miste, når du ikke lokaliserer dig?

Lad os overveje et uheldigt eksempel på ikke-lokalisering. Af hensyn til kundernes bekvemmelighed tillod en e-handelsportal kunderne at samle individuelle køb i en gruppe på fire. Desværre lyder udtalen af ordet "fire" på japansk som deres ord for "død". Japanere undgår typisk alle ting, der er forbundet med dette nummer, fordi det betragtes som uheldigt. Det er overflødigt at sige, at salget af disse produkter ikke gik godt på det japanske marked.

Så som svar på ovenstående spørgsmål kan du tabe en hel masse, hvis du ikke nøje planlægger dit målmarked.

Indholdsoversættelse som lokalisering

Når vi tænker på lokalisering, er indholdsoversættelse ofte den allerførste tanke, der falder os ind. Den anden tanke er "Vi har brug for en robust og effektiv databasemodel til at gemme oversat indhold på flere sprog".

Antag, at vi bliver bedt om at designe en datamodel til en flersproget e-handelsapplikation. Vi bliver nødt til at gemme tekstfelter som product_name og beskrivelse af produkter på forskellige sprog. Vi skal også gemme tekstfelter i andre tabeller, såsom customer tabel på alle disse sprog.

For at forstå, hvordan vi designer vores datamodel med indholdsoversættelse i tankerne, vil vi undersøge forskellige tilgange ved at bruge disse to tabeller. Hver af disse tilgange har fordele og ulemper. De fremgangsmåder, der er vist nedenfor, kan udvides til andre tabeller i din datamodel. Selvfølgelig vil den nøjagtige tilgang, du vælger, være baseret på dine egne krav.

Fremgangsmåde 1 – Tilføjelse af separate sprogkolonner for hvert påtænkt felt

Dette er den enkleste tilgang med hensyn til udvikling. Det kan implementeres ved at tilføje en sprogkolonne for hvert felt.

Fordele

Det er meget nemt at implementere.
Der er ingen kompleksitet i at skrive SQL for at hente de underliggende data på et hvilket som helst sprog. Antag, at jeg vil skrive en forespørgsel for at hente produkt- og kundeoplysninger for en bestemt ordre på fransk. Koden ville se sådan ud:
```
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 = ;
```

Idele

Der er ingen skalerbarhed:Hver gang et nyt sprog tilføjes, skal dusinvis af yderligere kolonner tilføjes på tværs af tabeller.
Det kan være tidskrævende, især hvis mange felter skal have flere sprog.

Udviklere ender med at skrive forespørgslen vist nedenfor for at administrere alle eksisterende sprog. Så alle SQL'er i din applikation skal ændres, når et nyt sprog introduceres. (Bemærk: @in_language angiver det aktuelle sprog i applikationen; denne parameter kommer fra appens frontend, mens bagenden henter poster.)

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 = ;

Fremgangsmåde 2 – Oprettelse af en separat tabel til oversat tekst

I denne tilgang bruges en separat tabel til at gemme oversat tekst; i eksemplet nedenfor har vi kaldt denne tabel translation . Den indeholder en kolonne for hvert sprog. Værdier, der er blevet oversat fra feltværdier til alle gældende sprog, gemmes som poster. I stedet for at gemme faktisk oversat tekst i underliggende tabeller, gemmer vi dens reference til translation bord. Denne implementering giver os mulighed for at lave et fælles lager af oversat tekst uden at foretage for mange ændringer i den eksisterende datamodel.

Fordele

Det er en god tilgang, hvis lokalisering skal implementeres på en eksisterende datamodel.
En enkelt ekstra kolonne i translation tabel er den eneste ændring, der er nødvendig, når et nyt sprog introduceres.
Når den originale tekst er den samme på tværs af tabeller, er der ingen overflødig oversat tekst. For eksempel:Antag, at et kundenavn og produktnavn er identiske. I dette tilfælde vil kun én post blive indsat i oversættelsestabellen, og den samme post henvises til både customer og product tabeller.

Idele

Det kræver stadig en ændring i datamodellen.
Der kan være unødvendige NULL-værdier i tabellen. Hvis 1.000 felter er nødvendige for kun ét understøttet sprog, ender du med at oprette 1.000 poster – og en masse NULL'er.

Kompleksiteten ved at skrive SQL stiger, efterhånden som antallet af joinforbindelser stiger. Og når der er mange poster i translation tabel, er hentningstiderne langsommere.

Lad os skrive en SQL til problemformuleringen for sprogstyring igen:

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 = ;

En variant af oversættelsestabeltilgangen

For at få bedre ydeevne, når oversat tekst hentes, kan vi opdele translation tabel i flere tabeller. Vi kan gruppere posterne baseret på domæne, dvs. én tabel for customer , en anden for product osv.

Fremgangsmåde 3 – En oversættelsestabel med rækker for hvert sprog

Denne implementering er ret lig den anden tilgang, men den gemmer værdierne for oversat tekst i rækker i stedet for kolonner. Her er translation tabel-id forbliver den samme for en feltværdi på ethvert oversat sprog. En sammensat primærnøgle {id , language_id } er gemt i oversættelsestabellen, og den gemmer den samme translation_id for hvert felt mod flere language_id .

Fordele

Denne implementering gør det muligt for udviklere at skrive datahentnings-SQL'er ganske nemt.
Det er også nemt at skrive OEM til denne model.
Ingen datamodelændringer er nødvendige, når du tilføjer et nyt sprog; indsæt blot posterne for det nye sprog.
Der er intet unødvendigt hukommelsesforbrug, når et sæt felter ikke gælder for et sprog.

Kompleksiteten af SQL'er til datahentning reduceres. Se eksemplet nedenfor:

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 = ;

Idele

Der kræves et relativt højt antal joinforbindelser for at hente oversatte data.
Med tiden kan et stort antal poster potentielt blive gemt i translation bord. Da der kun er én oversættelsestabel, vil al oversat tekst blive dumpet ind i den. Når du har millioner af felter, der skal oversættes, og din applikation understøtter et stort antal sprog, vil det være en tidskrævende aktivitet at forespørge i én tabel for en oversættelse. Du kan dog opdele oversættelsestabellen enten baseret på sprog eller fagområder, som vi påpegede i slutningen af den anden tilgang.

Hvad hvis vi kombinerer tilgang 2 og 3?

Specifikt kombinerer vi varianten af Approach 2 – opdeler translation tabel – med ideen om at bruge rækker i en tabel. Vi kan nemt overvinde ulempen ved at have enorme poster i translation tabel ved at oprette flere tabeller baseret på et domæne, som vi gjorde i Approach 2-varianten. Hvis der er et betydeligt antal poster i den domænebaserede oversættelsestabel, kunne vi yderligere opdele tabellerne baseret på individuelle felter.

Fremgangsmåde #4 – Oprettelse af enhedslag for oversatte felter og ikke-oversatte felter

I denne løsning er entitetstabeller, der indeholder et eller flere oversatte felter, opdelt i to lag:et for oversatte felter og et andet for ikke-oversatte felter. På denne måde opretter vi separate lag for hver.

Fordele

Der er ingen grund til at slutte sig til oversættelsestabeller, hvis det kun drejer sig om ikke-oversatte felter. Derfor får ikke-oversatte felter bedre ydeevne.
Der kræves et relativt færre antal joinforbindelser for at hente oversatte tekster.
Det er nemt at skrive OEM.
SQL'er til at hente oversat tekst er enkle.
Dette er en gennemprøvet tilgang til at inkorporere flere sprog på tværs af enheder.

For at demonstrere pointen er her et eksempel på en forespørgsel, der vil hente oversat tekst:

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 = ;

Lokalisering – Går videre end indholdsoversættelse

Lokalisering er ikke kun at oversætte dit applikationsindhold til et andet sprog. Der er kulturelle og funktionelle parametre, der også kræver opmærksomhed. For eksempel er en datoværdi formateret som 'MM/DD/ÅÅÅÅ' i Nordamerika, men i det meste af Asien skrives den som 'DD/MM/ÅÅÅÅ'.

Et andet eksempel har at gøre med visning af navne på applikationshovedet. I USA er det acceptabelt eller endda foretrukket at kalde nogen ved deres fornavn; i denne kultur vises kundens fornavn i overskriften, så snart kunden logger ind. I Japan er tingene dog omvendt:at kalde nogen ved deres fornavn er uhøfligt eller endda rettere fornærmende. Lokalisering ville tage højde for dette og undgå brugen af fornavne til applikationens japanske publikum.

Lokaliseringsparametre skal muligvis gemmes bagerst i applikationen. Dette er i høj grad tilfældet, når du skal designe noget programlogik omkring lokalisering. Vi kan formentlig kategorisere alle sådanne parametre i kulturelle og funktionelle kategorier og bygge datamodellen op omkring dem.

En ekstra tanke om lokalisering

Lokalisering er nødvendig, når et globalt brand trænger ind på lokale markeder. For at lokalisere en applikation, se på det store billede. Lokalisering er mere end bare teknisk perfekt ydeevne. Det betyder også at beherske lokale kulturer, adfærd og endda måder at tænke og leve på.

Hvad kan der ellers gøres for at gøre en applikation lokalt tilpasningsdygtig? Fortæl os dine tanker i kommentarerne.