Как начать пользоваться школой!

Интересно? Полезно?
Подпишись на обновления в блоге одним кликом!
Реклама на блоге
Начинаем знакомство с лучших постов
Бронирование гостиниц
Продвижение сайтов


Rambler's Top100
Рейтинг блогов

Powered by  MyPagerank.Net
Яндекс цитирования

Моя аська: 155ноль54семь9 (всегда invisible)
Мой скайп: remarka.reklama
Мой емайл: masterxbablorub@gmail.com

понедельник, 29 августа 2011 г.

Реализация мультиязычности на вашем сайте

Как-то странно, что этой теме посвящено так мало статей. Я, признаться, думал, что есть много красивых решений, но, немного погуглив, обнаружил только наборы плагинов. И никакой теории. Восполним этот пробел.

Реализация мультиязычности (сайта на нескольких языках) полностью зависит от постановки задачи. Фактически есть есть два возможных варианта: синхронный и асинхронный. В синхронном варианте (встречающемся не так уж и часто, как принято думать) все статьи и элементы сайта совпадают на разных языках. Или бытовым языком: на какой бы язык вы не перешли на сайте, все будет одинаково, только на другом языке.

В асинхронном варианте сайты неравнозначны. Это может быть и всего одна страничка на другом языке (http://tochkaopory.ru/ - http://tochkaopory.ru/indexen.php), и полноценный сайт (http://centrodent.ru/ - http://centrodent.ru/index.php?lang=en).

Типичный способ реализации синхронного варианта - удвоение полей. Т.е. на каждый язык добавляются поля на другом языке. Обычно к названию таких полей в таблице MySQL добавляется префикс. В шаблоне и виджетах добавляется обработка переменной, отвечающей за текущий язык - вместо поля NAME выводится, например, NAME{LANG}, где {LANG} может быть равной _RUS или _ENG в зависимости от выбранного языка. Работа это муторная и длительная, так что обычно у любой студии уже есть наработки на этот случай для нужных модулей в системе управления сайтом (CMS).

После полной реализации у пользователя есть единый вход, но на каждую новость/статью/единицу контента он должен заполнять и поля на другом языке.

Другой способ реализации синхронного варианта не является синхронным. Но тем не менее часто именно так используется. Ставятся два независимых сайта с одинаковыми настройками и заполняются на разном языке. Обычно такие сайты разведены по разным папкам или поддоменам. Управление ими чаще всего вырожадется в асинхронность двух версий спустя какое-то время. Да и требования к хостингу в таком случае вырастает. Вот пример такого сайта на трех базах MySQL: http://villa-severin.ru/

Асинхронные сайты чаще всего реализуются, как пример выше. Но есть еще два варианта реализации. Одностраничный и привязка контентной единицы к языку.

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

Привязка контентной единицы (статьи, новости, картинки и т.п.) к языку сложнее и требует существенного допиливания движка. К слову, мы делали это один единственный раз в своей практике. Суть: на нужный язык выводится только тот контент, который привязан к данному языку, а так все хранится в одной админке. В каком-то смысле это появление у контента еще одного измерения - языка. Обычно-то CMS обходится всего одним - привязкой к разделу или модулю. Если кратко вдаваться в технические детали, то у любой единицы контента при добавлении ее устанавливается критерий Язык. И в дальнейшем он определяет, на какой версии (по языку) статью или новость вывести. В итоге сайты на разных языках растут независимо, но каша в каталоге статей/новостей на разных языках все-таки смущает неопытных контентщиков.

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

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


10 коммент.:

Решение с дублированием полей на каждый язык - скажем мягко, неудачное. Рекомендую ознакомиться с тем, как работает соответсвующий плагин к Doctrine (ORM на PHP).

http://pastie.org/2447944

В итоге получится две таблицы в БД:
1. news c полями id | image | nb_comments
2. news_i18n c полями id | lang | title | text

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

Очевидно, что этот способ эффективен только в случае "синхронных" сайтов.

Вообще тема мультиязычности сайтов подразумевает множество решений, и серебрянной пули, тут разумеется не изобретешь.

По ссылке код объявления модели.

"Вообще тема мультиязычности сайтов подразумевает множество решений"

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

Но неоправданное клонирование сайтов ради лишнего языка меня всегда убивало наповал.

> Привязка контентной единицы (статьи, новости,
> картинки и т.п.) к языку сложнее

В чем сложность?

За лето я сделал 3 таких сайта.
Каждому элементу сайта делаешь обязательным выбор языка ну я еще и развел страницы на разных языках по разным меню.

Плюс при выводе в зависимости от языка выводишь в шаблоне нужные меню и некоторые элементы.

На Друпале это все достаточно просто реализуется.

Если сейчас набегут Друпаловцы и начнут тыкать в меня i18n -- да, знаю, что он существует. Но мне было проще сделать все через таксономию. А клиенту в конечном итоге все равно как это сделано.

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

причем при желании можно прикрутить гугл-транслейт или еще что для перевода в случае если статьи на нужном языке нету, но есть на другом

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

>причем при желании можно прикрутить гугл-транслейт или еще что для перевода в случае если статьи на нужном языке нету, но есть на другом

Пусть лучше пользователь вообще не увидит статьи на своем языке, чем увидит убожество автоматического перевода.

Баблоруб, не кидай людей, не хорошо:

http://bablorub.ru/index.php?type=402&idcat=4&theme=6312&next=420

Скорее, "не покидай". Но выводы сделаны, виновные наказаны.

Отправить комментарий

Популярные сообщения

Эту страницу: Twitter Facebook Favorites More