Hur man designar ett lokaliseringsfärdigt system

I denna era av globalisering är företag – inklusive mjukvaruutvecklare – alltid intresserade av att expandera till nya marknader. Detta innebär ofta att deras produkter lokaliseras till olika områden. I den här artikeln kommer vi att förklara några tillvägagångssätt för att utforma din datamodell för lokalisering – specifikt för att hantera innehåll på flera språk.

Vad är lokalisering?

Lokalisering är processen att anpassa en produkt till olika marknader. Det är en framträdande faktor för att uppnå maximal marknadsandel när det gäller produktförsäljning. När lokaliseringen görs på rätt sätt kommer användarna att känna att produkten producerades för deras språk, kultur och behov.

På platser där engelska inte är ett vanligt modersmål har undersökningar visat att lokala språk är mycket föredragna för en mjukvaruprodukt. Den här MediaPost-artikeln innehåller några intressanta siffror om behovet av andra språk än engelska när det kommer till internationell försäljning.

Vad kan du förlora när du inte lokaliserar dig?

Låt oss överväga ett olyckligt exempel på icke-lokalisering. För kundernas bekvämlighet tillät en e-handelsportal kunder att paketera individuella köp i en grupp om fyra. Tyvärr låter uttalet av ordet "fyra" på japanska som deras ord för "död". Japaner undviker vanligtvis allt som är associerat med detta nummer eftersom det anses vara oturligt. Onödigt att säga att försäljningen av dessa produkter inte gick bra på den japanska marknaden.

Så som svar på ovanstående fråga kan du förlora en hel del om du inte noggrant planerar för din målmarknad.

Innehållsöversättning som lokalisering

När vi tänker på lokalisering är innehållsöversättning ofta den allra första tanke som vi tänker på. Den andra tanken är "Vi behöver en robust och effektiv databasmodell för att lagra översatt innehåll på flera språk".

Anta att vi ombeds designa en datamodell för en flerspråkig e-handelsapplikation. Vi skulle behöva lagra textfält som product_name och beskrivning av produkter på olika språk. Vi skulle också behöva lagra textfält i andra tabeller, till exempel customer tabell, på alla dessa språk.

För att förstå hur vi utformar vår datamodell med innehållsöversättning i åtanke kommer vi att undersöka olika tillvägagångssätt genom att använda dessa två tabeller. Var och en av dessa tillvägagångssätt har för- och nackdelar. Tillvägagångssätten som visas nedan kan utökas till andra tabeller i din datamodell. Självklart kommer det exakta tillvägagångssättet du väljer att baseras på dina egna krav.

Tillvägagångssätt 1 – Lägga till separata språkkolumner för varje avsett fält

Detta är det enklaste tillvägagångssättet när det gäller utveckling. Det kan implementeras genom att lägga till en språkkolumn för varje fält.

Proffs

Det är mycket lätt att implementera.
Det finns ingen komplexitet i att skriva SQL för att hämta underliggande data på vilket språk som helst. Anta att jag vill skriva en fråga för att hämta produkt- och kundinformation för en viss beställning på franska. Koden skulle se ut så här:
```
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 = ;
```

Nackdelar

Det finns ingen skalbarhet:varje gång ett nytt språk läggs till måste dussintals ytterligare kolumner läggas till över tabellerna.
Det kan bli tidskrävande, särskilt om många fält behöver ha flera språk.

Det slutar med att utvecklare skriver frågan som visas nedan för att hantera alla befintliga språk. Så alla SQL-filer i din applikation måste ändras när ett nytt språk introduceras. (Obs! @in_language anger det aktuella språket i applikationen; den här parametern kommer från appens frontend, medan baksidan hämtar 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 = ;

Tillvägagångssätt 2 – Skapa en separat tabell för översatt text

I detta tillvägagångssätt används en separat tabell för att lagra översatt text; i exemplet nedan har vi kallat den här tabellen translation . Den innehåller en kolumn för varje språk. Värden som har översatts från fältvärden till alla tillämpliga språk lagras som poster. Istället för att lagra faktisk översatt text i underliggande tabeller lagrar vi dess referens till translation tabell. Denna implementering tillåter oss att skapa ett gemensamt arkiv med översatt text utan att göra för många ändringar i den befintliga datamodellen.

Proffs

Det är ett bra tillvägagångssätt om lokalisering ska implementeras på en befintlig datamodell.
En enda ytterligare kolumn i translation tabellen är den enda ändring som behövs när ett nytt språk introduceras.
När den ursprungliga texten är densamma i alla tabeller finns det ingen redundant översatt text. Till exempel:anta att ett kundnamn och produktnamn är identiska. I det här fallet kommer endast en post att infogas i översättningstabellen, och samma post hänvisas till både customer och product tabeller.

Nackdelar

Det kräver fortfarande en förändring av datamodellen.
Det kan finnas onödiga NULLs i tabellen. Om 1 000 fält behövs för endast ett språk som stöds, skapar du 1 000 poster – och många NULLs.

Komplexiteten att skriva SQL ökar när antalet kopplingar ökar. Och när det finns många poster i translation tabell är hämtningstiderna långsammare.

Låt oss skriva en SQL för problemsatsen för språkhantering 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 på översättningstabellmetoden

För att få bättre prestanda när översatt text hämtas kan vi dela upp translation tabell i flera tabeller. Vi kan gruppera posterna baserat på domän, det vill säga en tabell för customer , en annan för product , etc.

Tillvägagångssätt 3 – En översättningstabell med rader för varje språk

Denna implementering är ganska lik den andra metoden, men den lagrar värdena för översatt text i rader snarare än kolumner. Här är translation Tabell-ID förblir detsamma för ett fältvärde på alla översatta språk. En sammansatt primärnyckel {id , language_id } lagras i översättningstabellen och den lagrar samma translation_id för varje fält mot flera language_id .

Proffs

Denna implementering gör det möjligt för utvecklare att skriva SQL-filer för datahämtning ganska enkelt.
Det är också lätt att skriva OEM för den här modellen.
Inga datamodelländringar behövs när du lägger till ett nytt språk; lägg bara in posterna för det nya språket.
Det finns ingen onödig minnesförbrukning när en uppsättning fält inte är tillämpliga på ett språk.

Komplexiteten i SQL:er för datahämtning minskar. Titta på exemplet nedan:

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

Nackdelar

Ett relativt stort antal anslutningar krävs för att hämta översatt data.
Med tiden kan ett stort antal poster eventuellt lagras i translation tabell. Eftersom det bara finns en översättningstabell kommer all översatt text att dumpas i den. När du har miljontals fält som ska översättas och din applikation stöder ett stort antal språk, skulle det vara en tidskrävande aktivitet att söka i en tabell för en översättning. Du kan dock dela upp översättningstabellen antingen baserat på språk eller ämnesområden, som vi påpekade i slutet av den andra metoden.

Vad händer om vi kombinerar tillvägagångssätt 2 och 3?

Specifikt kommer vi att kombinera varianten av Approach 2 – dela upp translation tabell – med tanken att använda rader i en tabell. Vi kan enkelt övervinna nackdelen med att ha enorma poster i translation genom att skapa flera tabeller baserade på en domän, som vi gjorde i Approach 2-varianten. Om det finns ett stort antal poster i den domänbaserade översättningstabellen kan vi dela upp tabellerna ytterligare baserat på enskilda fält.

Tillvägagångssätt #4 – Skapa enhetslager för översatta fält och icke-översatta fält

I den här lösningen delas entitetstabeller som innehåller ett eller flera översatta fält i två lager:ett för översatta fält och ett annat för icke-översatta fält. På så sätt skapar vi separata lager för varje.

Proffs

Det finns inget behov av att gå med i översättningstabeller om det bara gäller icke-översatta fält. Därför får icke-översatta fält bättre prestanda.
Det krävs ett relativt färre antal anslutningar för att hämta översatta texter.
Det är lätt att skriva OEM.
SQL:er för att hämta översatt text är enkla.
Detta är ett beprövat tillvägagångssätt för att införliva flera språk mellan enheter.

För att visa poängen, här är ett exempel på en fråga som hämtar översatt text:

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å längre än innehållsöversättning

Lokalisering är inte bara att översätta ditt programinnehåll till ett annat språk. Det finns kulturella och funktionella parametrar som också kräver uppmärksamhet. Till exempel är ett datumvärde formaterat som 'MM/DD/ÅÅÅÅ' i Nordamerika, men i större delen av Asien skrivs det som 'DD/MM/ÅÅÅÅ'.

Ett annat exempel har att göra med att visa namn i applikationshuvudet. I USA är det acceptabelt eller till och med föredraget att kalla någon vid deras förnamn; i den här kulturen visas kundens förnamn i rubriken så snart kunden loggar in. I Japan är saker och ting omvända:att kalla någon vid deras förnamn är oartigt eller till och med snarare förolämpande. Lokalisering skulle ta hänsyn till detta och undvika användningen av förnamn för applikationens japanska publik.

Lokaliseringsparametrar kan behöva lagras i applikationens bakre del. Detta är mycket fallet när du måste designa någon programlogik kring lokalisering. Vi kan förmodligen kategorisera alla sådana parametrar i kulturella och funktionella kategorier, och bygga datamodellen runt dem.

En annan tanke om lokalisering

Lokalisering är nödvändig när ett globalt varumärke tränger in på lokala marknader. För att lokalisera en applikation, titta på helheten. Lokalisering är mer än bara tekniskt perfekt prestanda. Det innebär också att behärska lokala kulturer, beteenden och till och med sätt att tänka och leva.

Vad mer kan göras för att göra en applikation lokalt anpassningsbar? Låt oss veta dina tankar i kommentarerna.