Het scenario
U bent de eigenaar van een online winkel, gevestigd in Polen. De meeste van uw klanten komen uit Polen en spreken Pools. Maar u wilt uw producten ook in het buitenland verkopen en uw internationale klanten spreken voornamelijk Engels. U wilt dus dat uw online winkel beschikbaar is in zowel Pools en Engels . U verwacht ook dat uw producten goed zullen verkopen in Frankrijk, dus u verwacht dat u een Franse moet voorbereiden versie van de winkel ook (en misschien Spaans ook, want waarom niet?).
U wilt dat uw gebruikers kunnen overschakelen van de Poolse versie
naar de Engelse versie en terug.
En u wilt natuurlijk dat de productdetails van Pools naar Engels worden gewijzigd.
Hoe maak je een meertalige webapplicatie?
Er zijn twee soorten tekst in uw aanvraag. Een daarvan is statisch gegevens:knoplabels, tabelkoppen, afbeeldingen (die vaak tekst bevatten). De andere is de door de gebruiker gedefinieerde gegevens, zoals productnaam, productprijs, productbeschrijving enzovoort. De gegevens worden normaal gesproken uit de database gehaald.
De statische gegevens zijn wat u zou willen schrijven als een letterlijke tekenreeks in uw uitvoer. De door de gebruiker gedefinieerde gegevens zijn gegevens die u uit uw database haalt.
Ik zal het vandaag niet hebben over statische gegevens. Elk redelijk webframework zorgt voor internationalisering van de statische gegevens. Raadpleeg de documentatie van uw webtoepassingsframework voor details. Zoek naar zoekwoorden als 'internationalisering', 'i18n', 'lokalisatie' of 'vertalingen'.
Vandaag zal ik het hebben over de databasestructuur die we hier bij e-point gewoonlijk gebruiken om meertalige gegevens te verwerken. In de database voor uw winkel heeft u waarschijnlijk het product tabel waarin informatie wordt opgeslagen over alle producten die in de winkel verkrijgbaar zijn.
Het product tabel heeft kolommen zoals name , description , en price . Wanneer u de productinformatie in andere talen vertaalt, hoeft u slechts enkele kolommen te vertalen. Hier zou je alleen de name . vertalen en description , maar de price verandert niet wanneer u van taal verandert.
Wanneer we ondersteuning voor meerdere talen toevoegen, voegen we een nieuwe tabel toe met de naam language_version , waarin alle taalversies worden opgeslagen die in de winkel beschikbaar zijn. Meestal voegen we een kolom toe met de naam code en een genaamd is_default (met een passende beperking:slechts één versie kan de standaard zijn).
Vervolgens splitsen we het product tabel in twee tabellen:tabel product en tabel product_lv . Voor elk product is er één rij in het product tabel en meerdere rijen in de product_lv tafel; één rij voor elke taalversie. De tabel product_lv bevat alleen kolommen die vertaald moeten worden:name en description . De kolommen die taalonafhankelijk zijn (zoals price , omdat u voor dezelfde prijs verkoopt, ongeacht of uw klant Engels of Pools spreekt) blijf in de tabel product .
We doen hetzelfde voor elke tabel die vertaalde gegevens bevat. De vertaalde gegevens gaan naar de table_lv tabel, de taalonafhankelijke gegevens blijven in de hoofdtabel.
Voor- en nadelen
Een duidelijk nadeel is dat alle bewerkingen voor het maken, ophalen, bijwerken of verwijderen (CRUD) een beetje ingewikkelder worden. Je moet altijd meedoen met een extra taalversietabel om de juiste beschrijving te krijgen.
Het voordeel van dit ontwerp is dat u uw databaseschema niet hoeft te wijzigen wanneer u een nieuwe taalversie toevoegt. Ik zeg niet dat het toevoegen van een nieuwe taalversie eenvoudig is. Je moet immers ALLE productbeschrijvingen vertalen. Dit is een organisatorische uitdaging, maar vanuit het oogpunt van de database is het vrij eenvoudig:veel bijlagen.
Hoe ontwerpt u uw meertalige databases?