Jak navrhnout systém připravený na lokalizaci

V této éře globalizace mají společnosti – včetně vývojářů softwaru – vždy zájem expandovat na nové trhy. To často znamená lokalizovat své produkty pro různé oblasti. V tomto článku vysvětlíme několik přístupů k návrhu datového modelu pro lokalizaci – konkrétně pro správu obsahu ve více jazycích.

Co je lokalizace?

Lokalizace je proces adaptace produktu na různé trhy. Je to významný faktor pro dosažení maximálního podílu na trhu z hlediska prodeje produktů. Když je lokalizace provedena správně, uživatelé budou mít pocit, že produkt byl vyroben pro jejich jazyk, kulturu a potřeby.

V místech, kde angličtina není běžným prvním jazykem, průzkumy ukázaly, že pro softwarový produkt jsou mnohem preferovanější místní jazyky. Tento článek MediaPost obsahuje některá zajímavá čísla o potřebě jiných jazyků než angličtiny, pokud jde o mezinárodní prodej.

Co můžete ztratit, když nelokalizujete?

Podívejme se na nešťastný příklad nelokalizace. Pro pohodlí zákazníků umožnil portál elektronického obchodu zákazníkům seskupovat jednotlivé nákupy do skupiny čtyř. Bohužel výslovnost slova „čtyři“ v japonštině zní jako jejich slovo pro „smrt“. Japonci se obvykle vyhýbají všem věcem spojeným s tímto číslem, protože je považováno za nešťastné. Netřeba dodávat, že prodej těchto produktů na japonském trhu nedopadl dobře.

Takže v odpovědi na výše uvedenou otázku můžete hodně ztratit, pokud svůj cílový trh pečlivě nenaplánujete.

Překlad obsahu jako lokalizace

Když přemýšlíme o lokalizaci, překlad obsahu je často úplně první myšlenkou, která nás napadne. Druhá myšlenka je „Potřebujeme robustní a efektivní databázový model pro ukládání přeloženého obsahu ve více jazycích“.

Předpokládejme, že jsme požádáni, abychom navrhli datový model pro vícejazyčnou aplikaci elektronického obchodování. Potřebovali bychom uložit textová pole jako product_name a popis produktů v různých jazycích. Také bychom museli ukládat textová pole do jiných tabulek, jako je customer tabulky ve všech těchto jazycích.

Abychom pochopili, jak navrhnout náš datový model s ohledem na překlad obsahu, prozkoumáme různé přístupy pomocí těchto dvou tabulek. Každý z těchto přístupů má pro a proti. Níže uvedené přístupy lze rozšířit na další tabulky ve vašem datovém modelu. Přesný přístup, který zvolíte, bude samozřejmě vycházet z vašich vlastních požadavků.

Přístup 1 – Přidání samostatných jazykových sloupců pro každé zamýšlené pole

Jedná se o nejjednodušší přístup z hlediska vývoje. Lze jej implementovat přidáním jednoho sloupce jazyka pro každé pole.

Výhody

• Je velmi snadné jej implementovat.

• Psaní SQL pro načtení podkladových dat v jakémkoli jazyce není nijak složité. Předpokládejme, že chci napsat dotaz pro získání podrobností o produktu a zákazníkovi pro konkrétní objednávku ve francouzském jazyce. Kód by vypadal takto:

  Z řádku objednávky o vyberte p.product_name_FR, p.description_FR, p.price, c.name_FR, c.address_FR, c.contact_name, product p, customer c Kde o.product_id =p.id a o.customer_id =c .id a id =<číslo objednávky>;

Nevýhody

• Neexistuje žádná škálovatelnost:pokaždé, když je přidán nový jazyk, je třeba do tabulek přidat desítky dalších sloupců.
• Může to být časově náročné, zvláště pokud mnoho polí potřebuje mít více jazyků.

• Vývojáři nakonec napíší dotaz uvedený níže, aby mohli spravovat všechny existující jazyky. Takže všechny SQL ve vaší aplikaci se musí změnit, když je zaveden nový jazyk. (Poznámka: @in_language označuje aktuální jazyk aplikace; tento parametr pochází z frontendu aplikace, zatímco backend načítá záznamy.)

  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_nameFROM order_line o, product p, customer c WHERE o.product_id =p.id AND o.customer_id =c.id AND id =<číslo objednávky>;

Přístup 2 – Vytvoření samostatné tabulky pro přeložený text

V tomto přístupu se k uložení přeloženého textu používá samostatná tabulka; v níže uvedeném příkladu jsme tuto tabulku nazvali translation . Obsahuje jeden sloupec pro každý jazyk. Hodnoty, které byly přeloženy z hodnot polí do všech příslušných jazyků, jsou uloženy jako záznamy. Místo ukládání skutečného přeloženého textu do podkladových tabulek ukládáme jeho odkaz na translation stůl. Tato implementace nám umožňuje vytvořit společné úložiště přeloženého textu, aniž bychom museli provádět příliš mnoho změn ve stávajícím datovém modelu.

Výhody

• Je to dobrý přístup, pokud má být lokalizace implementována na existující datový model.
• Jeden další sloupec v translation tabulka je jedinou změnou, která je potřeba při zavedení nového jazyka.
• Pokud je původní text v tabulkách stejný, neexistuje žádný nadbytečný přeložený text. Například:předpokládejme, že jméno zákazníka a název produktu jsou totožné. V tomto případě bude do překladové tabulky vložen pouze jeden záznam a v obou customer a product tabulky.

Nevýhody

• Stále to vyžaduje změnu datového modelu.
• V tabulce mohou být zbytečné hodnoty NULL. Pokud je potřeba 1 000 polí pouze pro jeden podporovaný jazyk, nakonec vytvoříte 1 000 záznamů – a mnoho hodnot NULL.

• Složitost psaní SQL se zvyšuje se zvyšujícím se počtem spojení. A když je v translation tabulky, doby načítání jsou pomalejší.

  Pojďme znovu napsat SQL pro příkaz jazyka-management problem:

  VYBERTE CASE @in_language, KDYŽ 'FR' THEN tp.text_FR KDYŽ '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 .text_DE DEFAULT THEN c.name_EN, c.contact_nameFROM 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 =<číslo objednávky>;

Varianta přístupu k překladové tabulce

Pro lepší výkon při načítání přeloženého textu můžeme translation tabulky do více tabulek. Záznamy můžeme seskupit podle domény, tedy jedné tabulky pro customer , další pro product , atd.

Přístup 3 – Překladová tabulka s řádky pro každý jazyk

Tato implementace je docela podobná druhému přístupu, ale ukládá hodnoty pro přeložený text spíše do řádků než do sloupců. Zde je translation ID tabulky zůstává stejné pro hodnotu pole v jakémkoli přeloženém jazyce. Složený primární klíč {id , language_id } je uložen v překladové tabulce a ukládá stejné translation_id pro každé pole proti více language_id .

Výhody

• Tato implementace umožňuje vývojářům poměrně snadno psát SQL načítání dat.
• Pro tento model je také snadné napsat OEM.
• Při přidání nového jazyka nejsou potřeba žádné změny datového modelu; stačí vložit záznamy pro nový jazyk.
• Nedochází ke zbytečné spotřebě paměti, když sadu polí nelze pro jazyk použít.

• Složitost SQL načítání dat je snížena. Podívejte se na příklad níže:

  SELECT tp.text, p.price, tc.text, c.contact_nameFROM 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 =<číslo objednávky>; 
   

Nevýhody

• K načtení přeložených dat je potřeba relativně vysoký počet spojení.
• Časem může být v translation stůl. Protože existuje pouze jedna překladová tabulka, bude do ní uložen veškerý přeložený text. Když máte miliony polí k překladu a vaše aplikace podporuje velký počet jazyků, pak by dotazování jedné tabulky na překlad bylo časově náročnou činností. Překladovou tabulku však můžete rozdělit buď podle jazyků, nebo podle oborů, jak jsme zdůraznili v závěru druhého přístupu.

Co když zkombinujeme přístupy 2 a 3?

Konkrétně zkombinujeme variantu Approach 2 – rozdělení translation tabulka – s myšlenkou použití řádků v tabulce. Nevýhodu obrovských záznamů v translation vytvořením více tabulek na základě domény, jako jsme to udělali ve variantě Approach 2. Pokud je v doménové překladové tabulce značné množství záznamů, mohli bychom tabulky dále rozdělit podle jednotlivých polí.

Přístup č. 4 – Vytváření entitních vrstev pro přeložená pole a nepřeložená pole

V tomto řešení jsou tabulky entit, které obsahují jedno nebo více přeložených polí, rozděleny do dvou vrstev:jedna pro přeložená pole a druhá pro nepřeložená pole. Tímto způsobem pro každou vytvoříme samostatné vrstvy.

Výhody

• Pokud se jedná pouze o nepřeložená pole, není nutné spojovat překladové tabulky. Nepřeložená pole proto dosahují lepšího výkonu.
• K získání přeložených textů je potřeba relativně menší počet spojení.
• Je snadné psát OEM.
• SQL pro načítání přeloženého textu jsou jednoduché.
• Toto je osvědčený přístup pro začlenění více jazyků do různých entit.

Abychom to demonstrovali, zde je ukázkový dotaz, který načte přeložený text:

SELECT pt.product_name, pt.description, p.priceFROM 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 =<číslo objednávky>;

Lokalizace – překračování překladu obsahu

Lokalizace není jen překlad obsahu vaší aplikace do jiného jazyka. Pozornost si zaslouží také kulturní a funkční parametry. Například hodnota data je v Severní Americe formátována jako „MM/DD/RRRR“, ale ve většině Asie je zapsána jako „DD/MM/RRRR“.

Další příklad se týká zobrazení jmen v záhlaví aplikace. V USA je oslovování někoho křestním jménem přijatelné nebo dokonce preferované; v této kultuře je křestní jméno zákazníka zobrazeno v záhlaví, jakmile se zákazník přihlásí. V Japonsku je to však obráceně:oslovovat někoho křestním jménem je nezdvořilé nebo dokonce spíše urážlivé. Lokalizace by to vzala v úvahu a vyhnula by se použití křestních jmen pro japonské publikum aplikace.

Lokalizační parametry může být nutné uložit na zadním konci aplikace. To je do značné míry případ, kdy musíte navrhnout nějakou programovou logiku kolem lokalizace. Pravděpodobně můžeme všechny takové parametry kategorizovat do kulturních a funkčních kategorií a kolem nich postavit datový model.

Ještě jedna myšlenka o lokalizaci

Lokalizace je nezbytná, když globální značka proniká na místní trhy. Chcete-li lokalizovat aplikaci, podívejte se na celkový obrázek. Lokalizace je více než jen technicky dokonalý výkon. Znamená to také ovládat místní kultury, chování a dokonce způsoby myšlení a života.

Co dalšího lze udělat, aby byla aplikace lokálně adaptabilní? Dejte nám vědět své myšlenky v komentářích.