Vícejazyčné webové aplikace a relační databáze

23. srpna 2005

•

Snad každý, kdo se nějakou dobu zabývá vývojem webových aplikací, byl někdy postaven před problém vícejazyčnosti webové aplikace. Tento článek se pokusí nastínit některé techniky, které můžeme při vývoji vícejazyčné aplikace použít, především z hlediska relačních databází.

Jak na vícejazyčné aplikace?

Důvody, které nás vedou k vytvoření vícejazyčné webové aplikace, jsou naprosto zřejmé. Buď vytváříme software na zakázku, kde předem víme, že bude zákazník vícejazyčnost požadovat, nebo vyvíjíme software, který bychom chtěli nabízet i pro zahraničí klienty. V obou případech musíme zajistit naprostou jazykovou transparentnost aplikace, a to takovým způsobem, aby případná lokalizace aplikace pro další jazyk byla co nejjednodušší a nejlevnější. Jak tohoto ideálního stavu dosáhnout? Existuje samozřejmě vícero přístupů a způsobů.

Vícejazyčnost webových aplikací bychom mohli obecně sledovat (alespoň dle mého názoru) na dvou odlišných úrovních. První z nich je úroveň takzvané frontendové vícejazyčnosti a druhá z nich je vícejazyčnost na úrovni backendu aplikace. Tento článek bude pojednávat především o zajištění vícejazyčnosti backendu, jejíž realizace je o něco složitější, než realizace vícejazyčnosti na úrovni frontendu.

Vícejazyčnost frontendu – slovníkování a šablonovací systémy

Pod frontendem webové aplikace bychom si mohli představit prezentační vrstvu aplikace, konečné GUI aplikace. Tedy tu část aplikace, se kterou se setkává a běžně pracuje konečný uživatel. Realizace vícejazyčnosti na této úrovni není příliš složitá.

Velice dobrým a osvědčeným způsobem realizace vícejazyčnosti frontendu je využití některého kvalitního šablonovacího systému, který obsahuje podporu pro slovníkování. Při použití slovníku stačí pro každou stránku webové aplikace vytvořit pouze jednu šablonu. V těchto šablonách není plné znění textů v daných jazycích, ale pouze klíče, které ukazují na jednotlivé výrazy do překladového slovníku. Pro každý jazyk si musíme nadefinovat vlastní slovník, který má podobu textového souboru se strukturou klíč – překlad v daném jazyce. Aplikace je potom pouze zodpovědná za přepínání jazyků, respektive předání parametru typu jazyka pro šablonovací systém.

Oproti šablonovacím systémům bez podpory slovníkování zde získáme velkou výhodu, kterou je absence mnoha sad šablon. Vystačíme si pouze s jednou šablonou pro všechny jazyky. Bez použití šablonovacího systému je situace ještě svízelnější především v případě aplikací, které míchají aplikační logiku s XHTML kódem, tak typickým nešvarem mnoha PHP a ASP aplikací. Vytváření duplicitních PHP nebo ASP scriptů, které obsahují konkrétní překlady namíchané s totožným aplikačním kódem, je zcela jistou cestou do pekel.

Samozřejmě existují i jiné způsoby, kterými můžeme víceméně úspěšně zajistit vícejazyčnost frontendu webových aplikací. Zmíním například nástroj GETTEXT, o kterém na tomto serveru vycházel celý seriál. Přesto si myslím, že šablonovací systémy představují nejkomfortnější řešení, a těm, kteří ještě žádný ze šablonovacích systémů nevyzkoušeli, toto vřele doporučuji a přidávám pár odkazů na poměrně kvalitní šablonovací systémy:

Smarty (PHP) (viz též seriál na Intervalu)
Y.A.T.S (PHP)
Phptal (PHP)
Teng (C++, PHP, Python)
Velocity (Java)

Vícejazyčnost backendu

Backend webové aplikace představuje samotnou aplikační, nikoli prezentační logiku, která stojí nad databázovým systémem a zahrnuje i samotnou databázi. V tomto článku bych se chtěl věnovat především návrhu datové struktury, která by byla dostatečně flexibilní z hlediska vícejazyčnosti databáze a možnostem do aplikace jednoduše přidávat další jazyky.

Požadavky na vícejazyčnost

Než přistoupíme k samotnému návrhu řešení pro vícejazyčnost (backendu), musíme si nadefinovat požadavky, které tímto řešením budeme chtít splnit. Jinak totiž budeme uvažovat v případě, že předem víme, že aplikace bude pouze v češtině a angličtině, a jinak v případě, kdy je množina použitých jazyků otevřená. Náš návrh musí splňovat následující jednoduché, ale podstatné požadavky:

množina jazyků je neomezená
nevylučuje se ani použití atypických jazyků, jako je ruština nebo řečtina
přidání dalšího jazyka musí být co nejjednodušší
nesmí docházet k nekonzistencím a duplicitám v databázi

Databázový systém

Rozmanitost jazyků a národních abeced nezná mezí, a proto se ve světě počítačů používají nejrůznější kódování a znakové sady. Pokud vytváříme skutečně vícejazyčnou aplikaci, musí být i naše databáze schopná pracovat s různým kódováním. Stejně tak, jako pro češtinu volíme například znakovou sadu ISO-8859-2, jindy označovanou jako LATIN2, existují znakové sady i pro ostatní jazyky či skupiny jazyků. Asi nikoho neohromí informace, že existuje poměrně elegantní a ve své době jistě převratné řešení, kterým je Unicode a standard pro jeho kódování UTF-8. Podmnožinou Unicode jsou všechny v současné době existující znakové sady. Pro databázový systém, který má zvládat vícejazyčnost v rámci jedné databáze, je podpora Unicode velmi důležitá.

Většina v současné době používaných databázových systémů nemá s podporou Unicode zásadní problémy. Trochu zamrzí fakt, že na webu nejpoužívanější databázový systém MySQL s jeho podporou přišel dle mého názoru velice pozdě a to až od verze 4.1, která není ve stable verzi příliš dlouhou dobu. Navíc podpora Unicode v MySQL má stále ještě drobné mouchy. Naprosto bezproblémově si z dostupných databázových systémů s Unicode a UTF-8 poradí například PostgreSQL, Firebird, Interbase, MSSQL, ORACLE a mnoho dalších.

Datová struktura pro ukládání vícejazyčných dat

Výše jsme jako základní předpoklad uvedli použití databázového systému s podporou standardu Unicode. Tím jsme vyřešili problémy se čtením a ukládáním vícejazyčných textů do jedné databáze. Práce s takovými daty se pro nás stává naprosto transparentní. Nezbývá nic než poslední „maličkost“, a to je návrh datové struktury pro ukládání vícejazyčných dat. Nejprve uvedu dva způsoby, které jsou velmi rozšířené a dle mého názoru dosti nevhodné a nešťastné. Následovat bude příklad flexibilnějšího a čistějšího řešení.

Nevhodné řešení č. 1 – duplicita sloupců

Jak již nadpis napovídá, dostali jsme se k prvnímu ne příliš vhodnému, ale často používanému řešení. V tomto případě jednoduše v každé tabulce, kde potřebujeme ukládat texty ve více jazycích, duplikujeme textové atributy tolikrát, kolik jazyků používáme. Tento způsob znázorňuje obrázek níže, který představuje zjednodušenou tabulku pro ukládání článku v nějakém redakčním systému. Titulek a obsah článku jsou duplikovány pro další jazyk, v tomto případě němčinu. Pro další jazyky by se přidávaly další a další sloupce.

Proč je toto řešení nevhodné? Především proto, že při přidání dalšího jazyka musíme měnit datovou strukturu všech tabulek v databázi. To způsobuje, že toto řešení není příliš flexibilní, ani čisté z hlediska datového návrhu. Při větším počtu jazyků by nám vznikaly mamutí tabulky s velkou kapacitou řádku.

Toto řešení je přesto vhodné pro malé nenáročné aplikace s menším počtem jazyků nebo se dá s úspěchem použít při nutnosti narychlo rozšířit stávající aplikaci, nebo pouze část aplikace s podporou dalšího jazyka. Při dodržení pevných pravidel pojmenování textových sloupců je do určité míry možné i aplikační logiku upravit tak, aby pracovala s různými jazyky genericky (například pomocí pre- nebo postfixu u názvů atributů).

Nevhodné řešení č. 1 – duplicita sloupců

Nevhodné řešení č. 2 – duplicita řádků

Další z nepříliš vhodných řešení zobrazuji následující obrázek – jedná se o duplikování záznamů v databázi takovým způsobem, že do tabulky přibude cizí klíč do tabulky jazyků, který udává, pro jaký jazyk je daný záznam určen. Řádek je v tabulce přítomný tolikrát, kolik jazyků je definováno.

Proč je pro změnu nevhodné toto řešení? Nevýhoda je zde jedna, a to zásadní. Pokud tabulka obsahuje i jiné údaje než textové atributy (v tomto případě reference na sekci, datum a autora), dochází k duplikování těchto dat do všech řádků všech jazyků. Toto je možná ještě větší prohřešek proti správnému databázovému návrhu než v prvním případě. Veškeré operace s těmito atributy by se musely vždy projevit ve všech záznamech. Nejenom, že plýtváme místem, ale hrozí zde také vznik nekonzistencí, které by se musely hlídat na úrovni aplikační logiky, a to je vždy velmi nebezpečné.

Ztrácíme zde také možnost použít jednoduchý primární klíč, který by se musel nahradit složeným primárním klíčem z původního id záznamu a id jazyka.

Nevhodné řešení č. 2 – duplicita řádků

Vhodné řešení – rozklad a oddělení tabulek s texty

Jakou tedy zvolit datovou strukturu, aby splňovala požadavky, které jsme si stanovili? Návrh bude vycházet z minulé metody s tím, že odstraní její největší nevýhodu, kterou byla duplicita nepřekládaných údajů. Příklad znázorňuje obrázek níže.

Řešení je následující. Všechny atributy, které potřebujeme překládat, osamostatníme do další tabulky, která bude k základní tabulce ve vztahu 1:N, kde N bude počet jazyků. V základní tabulce zůstanou pouze nepřekládané atributy. Tabulka jazyků je opět ve vztahu 1:N k tabulce s překlady.

Tímto způsobem docílíme vysoké flexibility datové struktury vzhledem k počtu jazyků. Při správné realizaci aplikační logiky nemusíme měnit ani datovou strukturu, ani aplikační logiku. Stačí pouze do tabulky jazyků přidat další záznam a aplikace se sama genericky přizpůsobí. Například administrační rozhraní webové aplikace začne nabízet pro vložení záznamu další jazyk navíc.

Samozřejmě, toto řešení má i určité nevýhody. Především tato datová struktura není jednoduše aplikovatelná na hotové projekty, protože by znamenala velkou změnu stávající struktury a aplikační logiky. Dalším problémem může být zvýšení počtu tabulek v databázi a nutnost spojovat tabulky při dotazování do databáze. V tom ovšem nevidím příliš velký probém, protože se jedná o jednoduché spojení přes celočíselný klíč. Výhody této metody a především čistota návrhu ovšem dle mého názoru převažují nad uvedenými nevýhodami.

Vhodné řešení – rozklad a oddělení tabulek s texty (plná velikost, cca 5 kB)

Souhrn

Jak to tak v životě bývá, uvedený příklad není tím jediným správným řešením, jak navrhnout vícejazyčný backend webové aplikace. Ve spojení s kvalitním šablonovacím systémem s podporou slovníkování, který se postará o vícejazyčnost statického frontendu, můžeme tímto způsobem s úspěchem vytvářet kompletně vícejazyčné internetové aplikace.