Publications / Поддержка мультиязычности в веб-проектах — базовые варианты реализации

Habr

Habr.com is a unique online community for IT professionals. This platform hosts in-depth articles, industry news, and engaging discussions, serving as a key resource for tech enthusiasts, developers, and IT specialists looking to stay ahead in the rapidly evolving world of technology.


 All publications for this publisher
Monday, 02 September 2013

Занимаясь проектами связанными с веб-разработкой я сталкивался с различными вариантами реализации подержки нескольких языков для сайтов, порталов и веб приложений. Здесь я описал базовые варианты реализации архитектуры БД, которые мне встречались чаще всего.
Думаю для новыичков в веб-разработке эта статья окажется полезной, а тех кто уже имет опыт построения мультиязычных систем приглашаю для обсуждения тех вариантов, которые вы предпочитаете.

1. Создание полей для каждого языка



Реализация: для каждого поля для каждого языка в таблице создается отдельная колонка
Особенности: при большом количестве языков, или при заране неизвестно количестве языков такой подход будет требовать изменения структуры БД каждый раз, когда понадобиться реализовать подержку нового языка.
Когда стоит использовать: когда заранее четко известно количество поддерживаемых языков, и каждая сущность должна сущестовать во всех языковых вариантах.

 

 

 

2. Создание таблицы локализации



Реализация: для каждой сущности требующей локализации создается две таблицы. Основная таблица, содержащая поля, которые не зависят от конкретного языка и таблица содержащая поля требующие перевода. Также в БД создается таблица со списком доступных языков.
Особенности: данный подход ползволяет реализовать достаточно гибкую расширяемость поддерживаемых языков. Структура этого варианта немного сложнее предыдущего и предполагает создание таблицы-саттелита для каждой таблицы содержащей локализуемые поля.

 

 

 

 

3. Использование сериализованных данных сложной структуры



Реализация: в каждое поле требующее перевода пишется информация в сериализованном виде, например в JSON, XML, binary, etc. Объект при этом может быть например словарем, в котором ключ — язык, значение — текст. Или любой другой структуры.
Особенности: главная особенность состоит в том, что целостоность данных зависит уже не только от базы данных, но и от механизма сериализации. Кроме того, в таком варианте также очень сильно снижается нормализация базы данных.

 

 

 

 

4. Отдельная запись в таблице для каждого языка



Реализация: в каждой таблице, которая описывает сущность требующую локализации поле с указанием языка, к которому относится запись. Также в БД создается таблица со списком доступных языков.
Особенности: данный вариант примечателен тем, что по сути одному объекту предметной области может соответствовать несколько объектов в БД и несколько связей. ЧТо может достаточно сильно усложнить бизнес-логику.

 

 

 

 

5. Отсутствие локализации на уровне БД. Использование внешних средств локлаизации


Данный вариант не относится напрямую к теме статьи, но думаю что упомянуть его стоит.
Реализация: способ реализуется за счет внешних подключаемых модулей (Google translate, Bing translate, etc.).
Особенности: данный вариант может применятся в том случае, если владелец ресурса хочет иметь возможность предоставить информацию как можно большему количеству посетителей. При этом следует понимать, что качество машинного перевода зачастую оставляет жлеать лучшего. Вариант может рассматриваться лишь как очень бюджетный (когда нет ресурсов на перевод каждой публикации) и перед его применением я бы рекомендовал хорошо подумать — а стоит ли вообще его реализовывать.

 

 

 

 

Хранение «статической» текстовой информации


Пару слов о хранении статической текстовой информации. Под ней я имею ввиду надписи на кнопках, информацию в футере и остальной текст такого типа, который в большинстве случаев не изменяется контент-менеджером, а при реализации одноязычных сайтов заносится прямо в шаблон. В случае многоязычного сайта для ханения такого текст может быть несколько вариантов:

 

 

 

  • Текст хранится в базе и кэшируется при запуске веб-приложения — вариант позволяет потенциально расширять количество поддерживаемых языков. По сути текст становится не статическим, а вполне динамическим контентом.
  • Текст хранится в ресурсных файлах — вариант по быстродействия быстрее предыдущего варианта, но для добавления языка необходима правка файлов веб-приложения
  • Для каждого языкового варианта создается отдельный шаблон, содержащий статический текст — на мой взгляд излишне избыточный вариант. Имеет те же недостатки, что и предыдущий.

 

 

 

Полезная информация


Read publication