Может ли кто-нибудь сказать мне, как сделать динамический многоязычный веб-сайт в PHP и MySQL? Я понятия не имею об этом. Я искал в Google и не нашел хороших решений.
Может ли кто-нибудь предоставить мне пошаговое руководство? Если возможно, сделайте демонстрацию для многоязычного веб-сайта. Или, пожалуйста, напишите мне по любой ссылке, где он объяснит подробности об этом.
Короткий ответ: нет короткого ответа, так как есть много переменных для рассмотрения и много работы. Так что...
Длинный ответ: Я собираюсь сломать его так же хорошо, как я могу, но нет ответа "хорошо для всех" на такой широкий вопрос, как ваш.
Во-первых, переменные задачи под рукой:
Список языков: будет ли ваш сайт находиться в предопределенном наборе языков или он будет разнообразным/неоднородным? Например, сайт может быть полностью двуязычным на двух хорошо определенных языках (или, например, я запускаю английский/каталонский/испанский сайт); или различные разделы могут быть доступны на разных языках (например, посмотрите на сайты 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).Выбор языка: очень важно, вы должны предоставить своим пользователям возможность выбрать свой собственный язык, кроме того, чтобы настраивать аргументы GET на самом URL-адресе. Для нескольких языков "флаги" часто отлично работают, поскольку их можно понять, даже если страница первоначально отступила на язык, который пользователь вообще не знает. Для большего количества языков выпадающее меню кажется более эффективным (с точки зрения пространства просмотра), но вы должны обязательно добавить некоторые визуальные (то есть: нетекстовые) подсказки. Некоторые сайты заставляют вас выбирать язык при входе и иметь только ссылки на домашнюю страницу на каждом языке. Лично у меня есть три моих флага, стоящих поверх меню моего сайта, каждый из которых указывает на текущий адрес с измененным только аргументом языка. Такой код может работать довольно хорошо:
function translatedURI($new_lang) {
return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
}
Хорошо, что все, что я могу сейчас вынести. Я думаю, вам должно быть достаточно, чтобы поднять рукава и приступить к работе. Затем, если вы нажмете какую-нибудь стену на своем пути, вернитесь с конкретными вопросами, и я уверен, что вы получите более конкретные ответы.
Надеюсь, что это поможет.
Взгляните на эти вопросы:
И взгляните на класс Zend_Translate из Zend Framework.
Решением, которое я всегда использую, является создание таблицы базы данных со всеми возможными сообщениями. Для каждого сообщения я использую код (аббревиатуру), чтобы найти его. Так, например:
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. Пользователи всегда должны иметь возможность устанавливать язык, который они предпочитают, не слепо полагаться на заголовок языка, заданный веб-браузером.
Вы можете использовать простой язык 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);
Теперь я разрабатываю очень крошечную CMS, которая должна быть многоязычной.
Одна из функций, которые большинство меня интересует, заключается в том, что клиент может спонтанно решить добавить или удалить язык.
По этой причине я не нацелен на добавление суффиксов проекта к таблицам базы данных, я не могу (и не хочу) изменять имена таблиц или обращаться к ним с помощью динамических имен, а также добавлять или удалять поля каждый раз, когда язык определяется или удаляется.
Я бы тоже не использовал файлы, просто потому, что мне нравятся базы данных, и они легко доступны.
И, наконец, я думаю, что в двух типах перевода:
Поэтому мой проект направлен на:
Это означает, что таблицы, поля которых будут иметь контент в одноязычном сценарии, теперь будут иметь свой контент void, потому что он всегда будет в таблице переводов.
Это увеличит сложность запросов sql, но это позволит мне разработать инструменты для легкого перевода переводов. Кроме того, сложность sql будет существовать только один раз, только при реализации решения. Если эта реализация должным образом разработана, обслуживание/расширяемость сайта не должно быть серьезной проблемой.
Edit
После некоторого разговора с друзьями-разработчиками, я думаю, что решение, к которому я приступаю, имеет слишком большую плату за одну таблицу.
Еще один подход, который я изучу сейчас, - создание дополнительной таблицы для каждой "переводимой таблицы" следующим образом:
Эта схема наследует концепции от первой, но разделяет ее на таблицы. Это альтернативное решение может повысить производительность и изолировать проблемы (как проблемы с индексами).
Дополнительная таблица перевода на "переводимую таблицу" будет создана в то же время, что и исходная.
И о запросах sql сложность остается прежней: для первого подхода требуется имя таблицы для поиска в таблице переводов, а вторая просто добавляет суффикс "_translations" в имени таблицы.