Многоязычность

Фев
21

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

Основное, что нужно сделать, осознать, что многоязычность должна быть реализованна для:

Контента
Дизайна сайта

Первое, что приходит на ум для реализации многоязычности контента, тоесть информации в базе данных - это увеличение числа полей в базе, например добавлением title_rus, title_eng, title_eng. И в некоторых случаях это действительно легко, тем более, что в таком случае очень удобно будет пользоватся префиксами при выборках из базы данных.

Префикс же должен вытягиваться из глобального массива, относительно выбранного языка. И вот тут появляется маленький ньюанс в вопросе многоязычности сайтов. Скрипт, должен хранить переменную того, какой язык выбран, но нельзя забывать о поисковых системах и продвижении фактически нескольких разных сайтов, которые дарит нам многоязычность!

Самый легкий путь, это конечно же использование поддоменов и домена с основным языком по умолчанию. При переходе на другой поддомен распарсивать URL и получать язык. И поисковое продвижение в ажуре пользователи даже не заметят переходов на различные поддомены. Единственная сложность состоит в том, что прийдется делать 3 разных сайта, ведь этоже поддомены.

Но и из этого положения есть выход - использование канонических имен CNAME в DNS!

Запись типа CNAME (Canonical Name - Каноническое имя) дает возможность присваивать хостингу мнемонические имена. Мнемонические имена(псевдонимы) широко применяются для связки имени хоста с какой-либо функцией, или просто для сокращения имени.

Если для хоста имеется запись CNAME, содержащая его мнемонические имена, другие записи для данного хоста должны ссылаться на его реальное (каноническое) имя, а не на мнемоническое. В момент когда программы DNS встречают запись CNAME, они оканчивают запросы по мнемоническому имени и переключаются на реальное имя хоста.

Например:
ftp.domen.ru. CNAME domen.ru
mail.domen.ru. CNAME domen.ru
ssh.domen.ru. CNAME domen.ru

Такие записи CNAME дают возможность доступа к Вашему домену через адреса ftp.domen.ru, mail.domen.ru, и т.д. Без таких записей CNAME Вы не сможете подключиться к Вашему серверу по таким адресам.

Вот такая вот темка. Думаю, далее все уже смогут разобраться самостоятельно!

21 Комментов к “Многоязычность”

24 Февраль 2008 в 22:47
cyrillyun :

господи, зачем так сложно?
25 Февраль 2008 в 01:36
Тихонов Костя :

И не говари навыдумывают блин
25 Февраль 2008 в 16:58
cross :

Легких путей не ищем, а вот оптимальных – это к нам
25 Февраль 2008 в 17:02
cross :

Кстати, возможность реализовать многоязычность таким способом не все, что можно придумать.
25 Февраль 2008 в 22:43
cyrillyun :

насчет оптимальных – оптимальностью здесь и не пахнет
25 Февраль 2008 в 22:51
cross :

Покажи ссылку или расскажи, если желаешь, как правильней можно придумать?
26 Февраль 2008 в 16:35
Cisco :

Запутано как то написано, но два раза прочитав, понять можно
С удовольствием бы прочитал продолжение статьи, если оно конечно появится
Автору – респект.
26 Февраль 2008 в 17:57
cross :

Тема многоязычности расскрыта, подход ясен, кто знает, тот найдет все тонкости и плюсы подхода.
27 Февраль 2008 в 16:07
Миша Фадеев :

Хорошо сказано
4 Апрель 2008 в 10:48
Rom@n :

А что же будет происходить в случае динамического создания языковых версий сайта
Таблицы будут рости в пропорции N(языков)*М(кол-во текстовых полей)!
Но это же не все…. Как тогда быть с твоими каноническими и мнемоническими адресами?
4 Апрель 2008 в 20:59
cross :

Пусть будет 12 языков, хотя я себе такого предствать не могу

Что получаем? 12 каконических имен и 12*N таблиц в базе, допустим 150 таблиц в итоге.

А если ростить не таблицы, а префиксы необходимых полей? Вообще плевое дело…

Какие-то сложности? А это граничный случай…
4 Апрель 2008 в 21:01
cyrillyun :

сколько таблиц???в своем уме?? господи, ну и анальный же выход ты нашел. Видимо понятие локализации никто никогда не слыхал…
4 Апрель 2008 в 21:08
cross :

Я не оспариваю правоту чужого подхода, cyrillyun. Это лишь альтернатива для пытливых умов.

Сейчас работаю с сайтом на 1 языке с примерно 100 таблицами. Похоже, что в своем уме
4 Апрель 2008 в 21:14
cyrillyun :

почитай что-нибудь о проектировании баз данных… должно просветить…
4 Апрель 2008 в 21:19
cross :

Совершенно верно. А теперь продолжи мысль о том, как сайту понимать какой сейчас должен быть язык на сайте? (Ведь речь-то именно об этом)
4 Апрель 2008 в 21:33
cyrillyun :

сложно передать идентификатор культуры в запросе?
4 Апрель 2008 в 21:45
cross :

Допустим, “select … inner join … on … where t2.culterid=”.$culter

А где этот $culter взять? В $_GET, в $_SESSION или лучше в имени поддомена хранить и иметь 3 сайта вместо одно?

Ведь мы же на сео-блоге и с точки зрения простоты реализации и эффекта – поддомены выигрывают. Хотя опять таки, не за мною остается “Фее”. Возможно я не прав.
4 Апрель 2008 в 21:56
cyrillyun :

мда..
я правильно понимаю, что:
твоя задача, скажем, трехязычный сайт. ты планируешь для каждой версии сайта выставить собственный поддомен, и трижды клонировать базу данных для разных языков?
4 Апрель 2008 в 22:02
cross :

Не правильно. Я созданию 3 поддоменна, а организация структуры базы данных – любая из всех возможных…

Суть в том, что из URI вытягивается этот самый $culter, который поисковиком будет кушаться лучше, чем любой геммор с сессиями, ?culter=rus или /rus/ …

Я надеюсь теперь понятнее стало о чем речь
4 Апрель 2008 в 22:16
cyrillyun :

во -первых: “любая из всех возможных” – какой ты себе ее представляешь?
во -вторых: моё имхо – что это неудачная архитектура.
4 Апрель 2008 в 22:21
cross :

1. field_rus, field_eng, field_est
2. field = < rus >< /rus >< eng >< /eng >< est >< /est >
3. field = rus|eng|est
4. Комбинации

Суть поста не в структуре БД, а в структуре URL и пользе этого.