Een lokalisatieklaar systeem ontwerpen

In dit tijdperk van globalisering zijn bedrijven – inclusief softwareontwikkelaars – altijd geïnteresseerd in uitbreiding naar nieuwe markten. Dit betekent vaak dat ze hun producten moeten lokaliseren voor verschillende gebieden. In dit artikel leggen we enkele benaderingen uit voor het ontwerpen van uw gegevensmodel voor lokalisatie, met name voor het beheren van inhoud in meerdere talen.

Wat is lokalisatie?

Lokalisatie is het proces van het aanpassen van een product aan verschillende markten. Het is een prominente factor bij het behalen van een maximaal marktaandeel in termen van productverkoop. Wanneer de lokalisatie correct is uitgevoerd, zullen gebruikers het gevoel hebben dat het product is gemaakt voor hun taal, cultuur en behoeften.

Op plaatsen waar Engels geen gemeenschappelijke eerste taal is, hebben onderzoeken aangetoond dat lokale talen veel de voorkeur hebben voor een softwareproduct. Dit MediaPost-artikel bevat enkele interessante cijfers over de behoefte aan andere talen dan Engels als het gaat om internationale verkoop.

Wat kun je verliezen als je niet lokaliseert?

Laten we eens kijken naar een ongelukkig voorbeeld van niet-lokalisatie. Voor het gemak van de klant konden klanten via een e-commerceportaal individuele aankopen bundelen in een groep van vier. Helaas klinkt de uitspraak van het woord 'vier' in het Japans als hun woord voor 'dood'. Japanners vermijden doorgaans alle dingen die met dit nummer te maken hebben, omdat het als ongelukkig wordt beschouwd. Onnodig te zeggen dat de verkoop van die producten niet goed ging op de Japanse markt.

Dus, als antwoord op de bovenstaande vraag, zou je heel veel kunnen verliezen als je niet zorgvuldig plant voor je doelmarkt.

Contentvertaling als lokalisatie

Als we aan lokalisatie denken, is het vertalen van inhoud vaak de eerste gedachte die bij ons opkomt. De tweede gedachte is:"We hebben een robuust en efficiënt databasemodel nodig om vertaalde inhoud in meerdere talen op te slaan".

Stel dat we gevraagd worden om een datamodel te ontwerpen voor een meertalige e-commerce applicatie. We moeten tekstvelden opslaan zoals product_name en de beschrijving van producten in verschillende talen. We moeten ook tekstvelden opslaan in andere tabellen, zoals de customer tabel, in al deze talen.

Om te begrijpen hoe we ons gegevensmodel moeten ontwerpen met het oog op de vertaling van inhoud, zullen we verschillende benaderingen onderzoeken aan de hand van deze twee tabellen. Elk van deze benaderingen heeft voor- en nadelen. De onderstaande benaderingen kunnen worden uitgebreid naar andere tabellen in uw gegevensmodel. De exacte aanpak die u kiest, is natuurlijk gebaseerd op uw eigen vereisten.

Aanpak 1 – Afzonderlijke taalkolommen toevoegen voor elk beoogd veld

Dit is de eenvoudigste benadering in termen van ontwikkeling. Het kan worden geïmplementeerd door voor elk veld één taalkolom toe te voegen.

Pluspunten

Het is heel gemakkelijk te implementeren.
Er is geen complexiteit bij het schrijven van SQL om de onderliggende gegevens in welke taal dan ook op te halen. Stel dat ik een vraag wil schrijven om product- en klantgegevens voor een bepaalde bestelling op te halen in de Franse taal. De code ziet er als volgt uit:
```
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 = ;
```

Nadelen

Er is geen schaalbaarheid:elke keer dat een nieuwe taal wordt toegevoegd, moeten tientallen extra kolommen worden toegevoegd aan tabellen.
Het kan tijdrovend zijn, vooral als veel velden meerdere talen moeten hebben.

Ontwikkelaars schrijven uiteindelijk de onderstaande query om alle bestaande talen te beheren. Alle SQL's in uw toepassing moeten dus veranderen wanneer een nieuwe taal wordt geïntroduceerd. (Opmerking: @in_language betekent de huidige taal van de applicatie; deze parameter komt van de front-end van de app, terwijl de back-end records ophaalt.)

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

Aanpak 2 – Een aparte tabel maken voor vertaalde tekst

In deze benadering wordt een aparte tabel gebruikt om vertaalde tekst op te slaan; in het onderstaande voorbeeld hebben we deze tabel translation . Het bevat één kolom voor elke taal. Waarden die zijn vertaald uit veldwaarden in alle toepasselijke talen, worden opgeslagen als records. In plaats van de daadwerkelijke vertaalde tekst op te slaan in onderliggende tabellen, slaan we de verwijzing op naar de translation tafel. Deze implementatie stelt ons in staat om een gemeenschappelijke repository van vertaalde tekst te maken zonder al te veel wijzigingen aan het bestaande datamodel aan te brengen.

Pluspunten

Het is een goede aanpak als lokalisatie moet worden geïmplementeerd op een bestaand gegevensmodel.
Eén extra kolom in de translation tabel is de enige wijziging die nodig is wanneer een nieuwe taal wordt geïntroduceerd.
Als de originele tekst in alle tabellen hetzelfde is, is er geen overbodige vertaalde tekst. Bijvoorbeeld:stel dat een klantnaam en productnaam identiek zijn. In dit geval wordt er slechts één record in de vertaaltabel ingevoegd en wordt naar hetzelfde record verwezen in zowel de customer en product tabellen.

Nadelen

Het vereist nog steeds een wijziging in het gegevensmodel.
Er kunnen onnodige NULL's in de tabel staan. Als er 1.000 velden nodig zijn voor slechts één ondersteunde taal, creëer je uiteindelijk 1.000 records – en veel NULL's.

De complexiteit van het schrijven van SQL neemt toe naarmate het aantal joins toeneemt. En als er veel records in de translation tabel, zijn de ophaaltijden langzamer.

Laten we opnieuw een SQL schrijven voor de probleemstelling voor taalbeheer:

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

Een variant op de vertaaltabelbenadering

Om betere prestaties te krijgen wanneer vertaalde tekst wordt opgehaald, kunnen we de translation tabel in meerdere tabellen. We kunnen de records groeperen op basis van domein, d.w.z. één tabel voor customer , een andere voor product , enz.

Aanpak 3 – Een vertaaltabel met rijen voor elke taal

Deze implementatie lijkt veel op de tweede benadering, maar slaat de waarden voor vertaalde tekst op in rijen in plaats van kolommen. Hier, de translation tabel-ID blijft hetzelfde voor een veldwaarde in elke vertaalde taal. Een samengestelde primaire sleutel {id , language_id } wordt opgeslagen in de vertaaltabel, en het slaat dezelfde translation_id . op voor elk veld tegen meerdere language_id .

Pluspunten

Deze implementatie stelt ontwikkelaars in staat om vrij eenvoudig SQL's voor het ophalen van gegevens te schrijven.
Het is ook gemakkelijk om OEM voor dit model te schrijven.
Er zijn geen wijzigingen in het gegevensmodel nodig wanneer u een nieuwe taal toevoegt; voeg gewoon de records voor de nieuwe taal in.
Er is geen onnodig geheugenverbruik wanneer een set velden niet van toepassing is op een taal.

De complexiteit van SQL's voor het ophalen van gegevens wordt verminderd. Bekijk het onderstaande voorbeeld:

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

Nadelen

Er is een relatief hoog aantal joins nodig om vertaalde gegevens op te halen.
Na verloop van tijd kan er mogelijk een groot aantal records worden opgeslagen in de translation tafel. Aangezien er maar één vertaaltabel is, wordt alle vertaalde tekst erin gedumpt. Wanneer u miljoenen velden moet vertalen en uw applicatie een groot aantal talen ondersteunt, dan zou het opvragen van één tabel voor een vertaling een tijdrovende bezigheid zijn. U kunt de vertaaltabel echter splitsen op basis van talen of vakgebieden, zoals we hebben aangegeven aan het einde van de tweede benadering.

Wat als we benadering 2 en 3 combineren?

In het bijzonder combineren we de variant van Approach 2 – het splitsen van de translation tabel - met het idee om rijen in een tabel te gebruiken. We kunnen het nadeel van enorme records in de translation table door meerdere tabellen te maken op basis van een domein, zoals we deden in de Approach 2-variant. Als er een aanzienlijk aantal records in de op het domein gebaseerde vertaaltabel is, kunnen we de tabellen verder opsplitsen op basis van afzonderlijke velden.

Aanpak #4 – Entiteitslagen maken voor vertaalde velden en niet-vertaalde velden

In deze oplossing worden entiteitstabellen die een of meer vertaalde velden bevatten opgesplitst in twee lagen:een voor vertaalde velden en een andere voor niet-vertaalde velden. Op deze manier creëren we voor elk aparte lagen.

Pluspunten

Het is niet nodig om vertaaltabellen samen te voegen als het alleen om niet-vertaalde velden gaat. Daarom presteren niet-vertaalde velden beter.
Er zijn relatief minder joins nodig om vertaalde teksten op te halen.
Het is gemakkelijk om OEM te schrijven.
SQL's voor het ophalen van vertaalde tekst zijn eenvoudig.
Dit is een bewezen aanpak voor het integreren van meerdere talen in entiteiten.

Om het punt te demonstreren, is hier een voorbeeldquery die vertaalde tekst zal ophalen:

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

Lokalisatie – verder gaan dan inhoudsvertaling

Lokalisatie is niet alleen het vertalen van de inhoud van uw applicatie naar een andere taal. Er zijn ook culturele en functionele parameters die aandacht behoeven. Een datumwaarde wordt bijvoorbeeld opgemaakt als 'MM/DD/YYYY' in Noord-Amerika, maar in het grootste deel van Azië wordt deze geschreven als 'DD/MM/YYYY'.

Een ander voorbeeld heeft te maken met het weergeven van namen in de applicatieheader. In de VS is het acceptabel of zelfs de voorkeur om iemand bij zijn voornaam te noemen; in deze cultuur wordt de voornaam van de klant in de header weergegeven zodra de klant inlogt. In Japan is het echter omgekeerd:iemand bij de voornaam noemen is onbeleefd of zelfs eerder beledigend. Lokalisatie zou hiermee rekening houden en het gebruik van voornamen voor het Japanse publiek van de applicatie vermijden.

Lokalisatieparameters moeten mogelijk worden opgeslagen aan de achterkant van de toepassing. Dit is in hoge mate het geval wanneer u programmalogica rond lokalisatie moet ontwerpen. We kunnen waarschijnlijk al dergelijke parameters in culturele en functionele categorieën indelen en het datamodel eromheen bouwen.

Nog een gedachte over lokalisatie

Lokalisatie is nodig wanneer een wereldwijd merk doordringt in lokale markten. Om een toepassing te lokaliseren, moet u naar het grote geheel kijken. Lokalisatie is meer dan alleen technisch perfecte prestaties. Het betekent ook beheersing van lokale culturen, gedragingen en zelfs manieren van denken en leven.

Wat kan er nog meer worden gedaan om een applicatie lokaal aanpasbaar te maken? Laat ons uw mening weten in de opmerkingen.