Как создать многоязычный веб-сайт

Ответ 1

Короткий ответ: нет короткого ответа, так как есть много переменных для рассмотрения и много работы. Так что...

Длинный ответ: Я собираюсь сломать его так же хорошо, как я могу, но нет ответа "хорошо для всех" на такой широкий вопрос, как ваш.

Во-первых, переменные задачи под рукой:

• Список языков: будет ли ваш сайт находиться в предопределенном наборе языков или он будет разнообразным/неоднородным? Например, сайт может быть полностью двуязычным на двух хорошо определенных языках (или, например, я запускаю английский/каталонский/испанский сайт); или различные разделы могут быть доступны на разных языках (например, посмотрите на сайты MS: они в основном однородны, но такие вещи, как блоги, статьи KB и некоторые документы, доступны только в подмножестве предположительно поддерживаемых языков).

• Источник перевода: контент, предоставляемый вами на любом соответствующем языке вами или каким-либо сотрудником? Или некоторые версии запускаются через программное обеспечение для перевода с одного базового языка? Первый подход требует много дополнительной работы для создания содержимого, но дает более качественные результаты, чем второй.

• Языки сами: как только у вас есть 1) и 2), вы должны знать, с какими языками вы работаете. Обратите внимание, что в случае, когда вы включаете диалекты (например, английский английский + английский английский или испанский испанский испанский или испанский испанский), вы можете столкнуться с некоторыми проблемами с "дублирующимся контентом" в поисковых системах, но подробности об этом слишком не по теме (просто упомянув, чтобы вы знали о потенциальных проблемах).

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

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

• Определение языка: наиболее разумным является использование параметра GET (что-то вроде? lang = en-us по URL-адресу). Кроме того, вы можете использовать некоторую геолокацию файлов cookie и/или IP для возврата, когда запрашивается URL-адрес без аргумента языка. Кроме того, если у вас есть средства, рассмотрите тему благоустройства URL (что выглядит лучше: example.com/index.php?lang=en-us или example.com/en-us/home?). Лично мне нравится модная версия ModRewrite для моего файла .htaccess, но это будет работать только на серверах на базе Apache.

• Управление контентом: независимо от того, извлекаете ли вы контент из БД (например, содержимое статьи), включайте файлы (типичные для панировочных сухарей, меню, заголовки сайта и т.д.) или любые другие средства, вам понадобятся каким-либо образом отделить каждую версию (язык) контента. Вот несколько примеров того, как это можно сделать:

  • Для содержимого базы данных, я рекомендую вам придумать шаблон для именования твердых полей и придерживаться его. Например, я добавляю _en, _es или _ca ко всем языковым полям моей БД. Таким образом, я могу получить доступ к правильному контенту с помощью выражений типа $row["title_$lang"].
  • Для включенных файлов снова используется соглашение об именах файлов. В моем случае у меня есть имена файлов, заканчивающиеся на .en.php, .ca.htm и т.д. Мои включенные вызовы выглядят как include("some-filename.$lang.php).
  • Время от времени вы будете выплевывать небольшие фрагменты текста непосредственно из вашего PHP-кода (например, при маркировке заголовков таблицы). Вы можете использовать файл include для каждого языка, определяющий массив "кусков" с теми же ключами, или таблицу DB, например, предложенную Гертом. Первый подход требует меньше усилий для разработки, последний должен меньше работать для поддержания (особенно если вы не работаете в одиночку).

• Выбор языка: очень важно, вы должны предоставить своим пользователям возможность выбрать свой собственный язык, кроме того, чтобы настраивать аргументы GET на самом URL-адресе. Для нескольких языков "флаги" часто отлично работают, поскольку их можно понять, даже если страница первоначально отступила на язык, который пользователь вообще не знает. Для большего количества языков выпадающее меню кажется более эффективным (с точки зрения пространства просмотра), но вы должны обязательно добавить некоторые визуальные (то есть: нетекстовые) подсказки. Некоторые сайты заставляют вас выбирать язык при входе и иметь только ссылки на домашнюю страницу на каждом языке. Лично у меня есть три моих флага, стоящих поверх меню моего сайта, каждый из которых указывает на текущий адрес с измененным только аргументом языка. Такой код может работать довольно хорошо:

function translatedURI($new_lang) {
    return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
}

4. Настройка CMS: если ваш сайт (или его часть) использует какой-то CMS, дискуссионный форум и т.д., все может стать довольно запутанным. Говоря по собственному опыту, у меня есть форум phpBB на моем сайте, разделенный на три основные категории (по одному на язык), таким образом, что они выглядят как три независимых форума (но пользователям просто нужно войти/зарегистрироваться на одном из них получить доступ ко всем языкам, так как они действительно являются категориями одной и той же платы). Тонкости, которые я должен был сделать для этого, плавно угрожали последним остаткам здравомыслия, которые я все еще сохраняю: S. В этих случаях я советую искать документы и функции поддержки конкретного программного обеспечения, которое вы используете.

Хорошо, что все, что я могу сейчас вынести. Я думаю, вам должно быть достаточно, чтобы поднять рукава и приступить к работе. Затем, если вы нажмете какую-нибудь стену на своем пути, вернитесь с конкретными вопросами, и я уверен, что вы получите более конкретные ответы.

Надеюсь, что это поможет.

Ответ 2

Взгляните на эти вопросы:

• Как бы вы преобразовали существующий веб-приложение в многоязычный файл
• Вопросы дизайна для интернационализации

И взгляните на класс Zend_Translate из Zend Framework.

Ответ 3

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

lang  id        message
en    login     Login
en    lostpass  Lost your password?
de    login     Anmelden
de    lostpass  Paswort vergessen?
nl    login     Aanmelden
nl    lostpass  Wachtwoord vergeten?

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

Ответ 4

Вы можете использовать простой язык PHP Multi Language Class - LangQuery

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

include("LangQuery.php");

$L=new LangQuery();

// Write Hello World
echo($L('hello_world'));

// Write Hello World Easier - In-line Echo Feature
// You don't have to write echo. Just add '>'
$L('>hello_world');

// Use in Strings
echo("Hello Universe. {$L('hello_world')} Hello Europe");

// Write my age with parameter
$L(">my_age",25);

// Write my name and age with parameters
$L(">my_name_age","Recep",25);

Ответ 5

Теперь я разрабатываю очень крошечную CMS, которая должна быть многоязычной.

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

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

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

И, наконец, я думаю, что в двух типах перевода:

• Веб-текст.
• Текст контента.

Поэтому мой проект направлен на:

• languajes Таблица с определенными языками.
• переводы Единая таблица, в которой будут отображаться все сообщения:
  • [pk] table_name имя таблицы, содержимое которой будет переведено.
  • [pk] имя_поля имя поля, содержимое которого будет переведено.
  • [pk] row_id идентификатор строки для элемента, который будет переведен.
  • [pk] язык язык перевода текста.
  • текст переведенный текст.

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

Это увеличит сложность запросов sql, но это позволит мне разработать инструменты для легкого перевода переводов. Кроме того, сложность sql будет существовать только один раз, только при реализации решения. Если эта реализация должным образом разработана, обслуживание/расширяемость сайта не должно быть серьезной проблемой.

Edit

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

Еще один подход, который я изучу сейчас, - создание дополнительной таблицы для каждой "переводимой таблицы" следующим образом:

• any_translatable_table: таблица, которая должна переводить любые ее поля
• any_translatable_table_translations: таблица, в которой будут сохранены переводы.
  • [pk] имя_поля имя поля, содержимое которого будет переведено.
  • [pk] row_id идентификатор строки для элемента, который будет переведен.
  • [pk] язык язык перевода текста.
  • текст переведенный текст.

Эта схема наследует концепции от первой, но разделяет ее на таблицы. Это альтернативное решение может повысить производительность и изолировать проблемы (как проблемы с индексами).

Дополнительная таблица перевода на "переводимую таблицу" будет создана в то же время, что и исходная.

И о запросах sql сложность остается прежней: для первого подхода требуется имя таблицы для поиска в таблице переводов, а вторая просто добавляет суффикс "_translations" в имени таблицы.