Scenariot
Du är ägare till en webbutik som ligger i Polen. Majoriteten av dina kunder är från Polen och de talar polska. Men du vill sälja dina produkter utomlands också och dina internationella kunder talar huvudsakligen engelska. Så du vill att din onlinebutik ska vara tillgänglig på både polska och engelska . Du förväntar dig också att dina produkter kommer att sälja bra i Frankrike, så du räknar med att du måste förbereda en fransk version av butiken också (och kanske spanska också, för varför inte?).
Du vill att dina användare ska kunna byta från den polska versionen
till den engelska versionen och tillbaka.
Och uppenbarligen vill du att produktinformationen ska byta från polska till engelska.
Hur gör du en webbapplikation på flera språk?
Det finns två typer av text i din ansökan. En är statisk data:knappetiketter, tabellrubriker, grafik (som ofta innehåller text). Den andra är den användardefinierade data, såsom produktnamn, produktpris, produktbeskrivning och så vidare. Data hämtas normalt från databasen.
De statiska data är vad du skulle vilja skriva som en bokstavlig sträng i din utdata. De användardefinierade uppgifterna är data som du tar från din databas.
Jag ska inte prata om statisk data idag. Alla rimliga webbramverk kommer att hantera internationaliseringen av statiska data. Se dokumentationen för din webbapplikationsram för detaljer. Leta efter nyckelord som "internationalisering", "i18n", "lokalisering" eller "översättningar".
Idag ska jag prata om vilken databasstruktur vi brukar använda här på e-point för att hantera flerspråkig data. I databasen för din butik har du förmodligen product tabell som lagrar info om alla produkter som finns i butiken.
product tabellen har kolumner som name , description och price . När du översätter produktinformationen till andra språk behöver du bara översätta vissa kolumner. Här skulle du bara översätta name och description , men price ändras inte när du byter språk.
När vi lägger till stöd för flera språk lägger vi till en ny tabell som heter language_version , som lagrar alla språkversioner som finns i butiken. Vi brukar lägga till en kolumn som heter code och en som heter is_default (med en lämplig begränsning:endast en version kan vara standard).
Därefter delar vi upp product tabell i två tabeller:tabell product och tabellen product_lv . För varje produkt kommer det att finnas en rad i product tabell och flera rader i product_lv tabell; en rad för varje språkversion. Tabellen product_lv innehåller endast kolumner som måste översättas:name och description . Kolumnerna som är språkoberoende (som price , eftersom du säljer för samma pris oavsett om din kund talar engelska eller polska) stanna kvar i tabellen product .
Vi gör samma sak för varje tabell som innehåller översatt data. Den översatta informationen går till table_lv tabell, de språkoberoende data stannar i huvudtabellen.
För- och nackdelar
En uppenbar nackdel är att alla operationer för att skapa, hämta, uppdatera eller ta bort (CRUD) blir lite mer komplicerade. Du måste alltid ansluta till en ytterligare språkversionstabell för att få rätt beskrivning.
Fördelen med denna design är att du inte behöver ändra ditt databasschema när du lägger till en ny språkversion. Jag säger inte att det är lätt att lägga till en ny språkversion. När allt kommer omkring måste du översätta ALLA produktbeskrivningar. Det här är en organisatorisk utmaning men ur databassynpunkt är det ganska enkelt:massor av inlägg.
Hur designar du dina flerspråkiga databaser?