Как да проектирате система, готова за локализация

В тази ера на глобализация компаниите – включително разработчиците на софтуер – винаги се интересуват от разширяване на нови пазари. Това често означава локализиране на продуктите им за различни области. В тази статия ще обясним няколко подхода за проектиране на вашия модел на данни за локализация – по-специално за управление на съдържание на множество езици.

Какво е локализация?

Локализацията е процес на адаптиране на продукт към различни пазари. Това е важен фактор за постигане на максимален пазарен дял по отношение на продажбите на продукти. Когато локализацията е направена правилно, потребителите ще почувстват, че продуктът е произведен за техния език, култура и нужди.

На места, където английският не е често срещан първи език, проучванията показват, че местните езици са много предпочитани за софтуерен продукт. Тази статия на MediaPost съдържа някои интересни цифри за необходимостта от езици, различни от английски, когато става въпрос за международни продажби.

Какво можете да загубите, когато не локализирате?

Нека разгледаме един нещастен пример за нелокализация. За удобство на клиентите порталът за електронна търговия позволява на клиентите да обединяват индивидуални покупки в група от четири. За съжаление, произношението на думата „четири“ на японски звучи като тяхната дума за „смърт“. Японците обикновено избягват всички неща, свързани с това число, защото се счита за нещастно. Излишно е да казвам, че продажбите на тези продукти не вървяха добре на японския пазар.

Така че, в отговор на горния въпрос, можете да загубите много, ако не планирате внимателно целевия си пазар.

Превод на съдържанието като локализация

Когато мислим за локализация, преводът на съдържание често е първата мисъл, която ни идва на ум. Втората мисъл е „Нуждаем се от стабилен и ефективен модел на база данни, за да съхраняваме преведено съдържание на множество езици“.

Да предположим, че сме помолени да проектираме модел на данни за многоезично приложение за електронна търговия. Ще трябва да съхраняваме текстови полета като product_name и описанието на продуктите на различни езици. Също така ще трябва да съхраняваме текстови полета в други таблици, като customer таблица на всички тези езици.

За да разберем как да проектираме нашия модел на данни с мисъл за превод на съдържание, ще разгледаме различни подходи, като използваме тези две таблици. Всеки от тези подходи има плюсове и минуси. Подходите, демонстрирани по-долу, могат да бъдат разширени до други таблици във вашия модел на данни. Разбира се, точният подход, който изберете, ще се основава на вашите собствени изисквания.

Подход 1 – Добавяне на отделни езикови колони за всяко предвидено поле

Това е най-простият подход по отношение на развитието. Може да се реализира чрез добавяне на една езикова колона за всяко поле.

Плюсове

Много е лесен за изпълнение.
Няма сложност при писането на SQL за извличане на основните данни на който и да е език. Да предположим, че искам да напиша заявка за извличане на данни за продукта и клиента за конкретна поръчка на френски език. Кодът ще изглежда така:
```
Изберете p.product_name_FR, p.description_FR, p.price, c.name_FR, c.address_FR, c.contact_name от поръчка_line o, product p, client c Къде o.product_id =p.id и o.customer_id =c .id И id =<номер на поръчка>;
```

Против

Няма мащабируемост:всеки път, когато се добави нов език, трябва да се добавят десетки допълнителни колони в таблиците.
Може да отнеме време, особено ако много полета трябва да имат няколко езика.
В крайна сметка разработчиците пишат заявката, показана по-долу, за да управляват всички съществуващи езици. Така че всички SQLs във вашето приложение трябва да се променят, когато се въведе нов език. (Забележка: @in_language обозначава текущия език на приложението; този параметър идва от предния край на приложението, докато задният край извлича записи.)
```
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 КОГА 'DE' THEN c .name_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, продукт p, клиент c КЪДЕ o.product_id =p.id И o.customer_id =c.id AND id =<номер на поръчка>;
```

Подход 2 – Създаване на отделна таблица за преведен текст

При този подход се използва отделна таблица за съхраняване на преведен текст; в примера по-долу сме нарекли тази таблица translation . Той съдържа по една колона за всеки език. Стойностите, които са преведени от стойности на полета на всички приложими езици, се съхраняват като записи. Вместо да съхраняваме действително преведен текст в основните таблици, ние съхраняваме препратката му към translation маса. Тази реализация ни позволява да направим общо хранилище на преведен текст, без да правим твърде много промени в съществуващия модел на данни.

Плюсове

Добър подход е, ако локализацията трябва да бъде приложена върху съществуващ модел на данни.
Една допълнителна колона в translation таблицата е единствената промяна, необходима при въвеждане на нов език.
Когато оригиналният текст е еднакъв във всички таблици, няма излишен преведен текст. Например:да предположим, че името на клиента и името на продукта са идентични. В този случай само един запис ще бъде вмъкнат в таблицата за превод и един и същ запис се препраща и в customer и product таблици.

Против

Все още изисква промяна в модела на данните.
В таблицата може да има ненужни NULL. Ако са необходими 1000 полета само за един поддържан език, в крайна сметка създавате 1000 записа – и много NULL.

Сложността на писането на SQL се увеличава с увеличаване на броя на присъединяванията. И когато има много записи в translation таблица, времето за извличане е по-бавно.

Нека отново напишем SQL за изявлението на проблема с управлението на езика:

SELECT CASE @in_language WHEN 'FR' THEN tp.text_FR WHEN 'DE' THEN tp.text_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language WHEN 'FR' THEN tc.text_FR КОГА 'DE' THEN t .text_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, продукт p, клиент c, превод tp, превод tc КЪДЕ o.product_id =p.id И o.customer_id =c.id И p.name_translation_id =tp.id И c.name_translation_id =tc.id AND id =<номер на поръчка>;

Вариант на подхода на таблицата за превод

За да постигнем по-добра производителност, когато се извлича преведен текст, можем да разделим translation таблица на множество таблици. Можем да групираме записите въз основа на домейн, т.е. една таблица за customer , друг за product и др.

Подход 3 – Таблица за превод с редове за всеки език

Тази реализация е доста подобна на втория подход, но съхранява стойностите за преведен текст в редове, а не в колони. Ето translation идентификаторът на таблицата остава същият за стойност на поле на всеки преведен език. Съставен първичен ключ {id , language_id } се съхранява в таблицата за превод и съхранява същия translation_id за всяко поле срещу множество language_id .

Плюсове

Тази реализация позволява на разработчиците да пишат SQL за извличане на данни доста лесно.
Също така е лесно да се напише OEM за този модел.
Не са необходими промени в модела на данни, когато добавяте нов език; просто вмъкнете записите за новия език.
Няма излишна консумация на памет, когато набор от полета не е приложим за даден език.

Сложността на SQL-овете за извличане на данни е намалена. Вижте примера по-долу:

ИЗБЕРЕТЕ tp.text, p.price, tc.text, c.contact_nameFROM поръчка_line o, продукт p, клиент c, превод tp, превод tc, език l КЪДЕ o.product_id =p.id И o.customer_id =c .id И p.name_translation_id =tp.id И c.name_translation_id =tc.id И tp.language_id =l.id И tc.language_id =l.id И l.name =@in_language И id =<номер на поръчка>;

Против

Необходим е относително голям брой обединения, за да се извлекат преведени данни.
С течение на времето огромен брой записи може потенциално да бъдат съхранени в translation маса. Тъй като има само една таблица за превод, целият преведен текст ще бъде изхвърлен в нея. Когато имате милиони полета за превод и приложението ви поддържа голям брой езици, тогава запитването на една таблица за превод би било отнемаща време дейност. Въпреки това, можете да разделите таблицата за превод въз основа на езици или предметни области, както посочихме в заключение на втория подход.

Ами ако комбинираме подходи 2 и 3?

По-конкретно, ще комбинираме варианта на Подход 2 – разделяне на translation таблица – с идеята за използване на редове в таблица. Лесно можем да преодолеем недостатъка от наличието на огромни записи в translation таблица чрез създаване на множество таблици въз основа на домейн, както направихме във варианта на подход 2. Ако има значителен брой записи в таблицата за превод, базирана на домейн, бихме могли допълнително да разделим таблиците въз основа на отделни полета.

Подход №4 – Създаване на слоеве на обекти за преведени полета и непреведени полета

В това решение таблиците на обекти, които съдържат едно или повече преведени полета, се разделят на два слоя:един за преведени полета и друг за непреведени полета. По този начин създаваме отделни слоеве за всеки.

Плюсове

Не е необходимо да се присъединяват таблици за превод, ако става въпрос само за непреведени полета. Следователно непреведените полета получават по-добра производителност.
Необходими са относително по-малък брой обединявания, за да се извлекат преведени текстове.
Лесно е да се пише OEM.
SQLs за извличане на преведен текст са прости.
Това е доказан подход за включване на множество езици в обекти.

За да демонстрирате идеята, ето примерна заявка, която ще извлече преведен текст:

ИЗБЕРЕТЕ pt.product_name, pt.description, p.priceFROM order_line o, product p, product_translation pt, language l WHERE o.product_id =p.id И AND p.id =pt.product_non_trans_id И pt.language_id =l. id И l.name =@in_language AND id =<номер на поръчка>;

Локализация – Отвъд превода на съдържание

Локализацията не е просто превод на съдържанието на вашето приложение на друг език. Има културни и функционални параметри, които също изискват внимание. Например стойността на датата е форматирана като „ММ/ДД/ГГГГ“ в Северна Америка, но в по-голямата част от Азия се изписва като „ДД/ММ/ГГГГ“.

Друг пример е свързан с показването на имена в заглавката на приложението. В САЩ наричането на някого по собственото му име е приемливо или дори предпочитано; в тази култура първото име на клиента се показва в заглавката веднага щом клиентът влезе. В Япония обаче нещата са обратни:наричането на някого по собственото му име е неучтиво или дори по-скоро обидно. Локализацията ще вземе това предвид и ще избегне използването на собствени имена за японската аудитория на приложението.

Параметрите за локализация може да се наложи да се съхраняват в задния край на приложението. Това е много така, когато трябва да проектирате някаква програмна логика около локализацията. Вероятно можем да категоризираме всички такива параметри в културни и функционални категории и да изградим модела на данните около тях.

Още една мисъл за локализацията

Локализацията е необходима, когато глобална марка прониква на местните пазари. За да локализирате приложение, погледнете голямата картина. Локализацията е нещо повече от технически перфектно изпълнение. Това също означава да владеете местните култури, поведение и дори начини на мислене и живот.

Какво друго може да се направи, за да се направи приложение локално адаптивно? Кажете ни вашите мисли в коментарите.