Scenariet
Du er ejer af en onlinebutik, der ligger i Polen. Størstedelen af dine kunder er fra Polen, og de taler polsk. Men du vil også gerne sælge dine produkter i udlandet, og dine internationale kunder taler hovedsageligt engelsk. Så du ønsker, at din onlinebutik skal være tilgængelig på både polsk og engelsk . Du forventer også, at dine produkter vil sælge godt i Frankrig, så du forventer, at du bliver nødt til at forberede en fransk version af butikken også (og måske spansk). også, for hvorfor ikke?).
Du ønsker, at dine brugere skal kunne skifte fra den polske version
til den engelske version og tilbage.
Og selvfølgelig vil du have produktdetaljerne til at skifte fra polsk til engelsk.
Hvordan laver du en flersproget webapplikation?
Der er to typer tekst i din ansøgning. Den ene er statisk data:knapetiketter, tabeloverskrifter, grafik (som ofte indeholder tekst). Den anden er den brugerdefinerede data, såsom produktnavn, produktpris, produktbeskrivelse og så videre. Dataene tages normalt fra databasen.
De statiske data er, hvad du ønsker at skrive som en streng bogstavelig i dit output. De brugerdefinerede data er data, som du tager fra din database.
Jeg vil ikke tale om statiske data i dag. Enhver rimelig webramme vil håndtere internationalisering af de statiske data. Se dokumentationen til din webapplikationsramme for detaljer. Se efter søgeord som "internationalisering", "i18n", "lokalisering" eller "oversættelser".
I dag vil jeg tale om, hvilken databasestruktur vi normalt bruger her på e-point til at håndtere flersprogede data. I databasen for din butik har du sandsynligvis product tabel, som gemmer info om alle produkter, der er tilgængelige i butikken.
product tabellen har kolonner som name , description og price . Når du oversætter produktinformationen til andre sprog, skal du kun oversætte nogle kolonner. Her vil du kun oversætte name og description , men price ændres ikke, når du skifter sprog.
Når vi tilføjer understøttelse af flere sprog, tilføjer vi en ny tabel kaldet language_version , som gemmer alle sprogversioner, der er tilgængelige i butikken. Vi tilføjer normalt en kolonne kaldet code og en kaldet is_default (med en passende begrænsning:kun én version kan være standard).
Dernæst opdeler vi product tabel i to tabeller:tabel product og tabel product_lv . For hvert produkt vil der være én række i product tabel og flere rækker i product_lv bord; en række for hver sprogversion. Tabellen product_lv indeholder kun kolonner, der skal oversættes:name og description . De kolonner, der er sproguafhængige (som price , fordi du sælger til samme pris, uanset om din kunde taler engelsk eller polsk) forbliv i tabellen product .
Vi gør det samme for hver tabel, der indeholder oversatte data. De oversatte data går til table_lv tabel, forbliver de sproguafhængige data i hovedtabellen.
Fordele og ulemper
En indlysende ulempe er, at alle oprette, hente, opdatere eller slette (CRUD) operationer bliver en lille smule mere komplicerede. Du skal altid tilslutte dig en ekstra sprogversionstabel for at få den rigtige beskrivelse.
Fordelen ved dette design er, at du ikke behøver at ændre dit databaseskema, når du tilføjer en ny sprogversion. Jeg siger ikke, at det er nemt at tilføje en ny sprogversion. Du skal jo oversætte ALLE produktbeskrivelser. Dette er en organisatorisk udfordring, men fra databasesynspunktet er det ret nemt:masser af indstik.
Hvordan designer du dine flersprogede databaser?