Может ли любой орган рассказать мне, как сделать динамический многоязычный веб-сайт в PHP и MySQL? Я понятия не имею об этом. Я искал в Google и не нашел хороших решений.
Может ли кто-нибудь предоставить мне пошаговое руководство? Если возможно, сделайте демонстрацию для многоязычного веб-сайта. Или, пожалуйста, напишите мне по любой ссылке, где объясняются подробности об этом.
Короткий ответ: короткого ответа нет, так как есть много переменных, которые нужно учитывать, и много работы. Так…
Длинный ответ: я собираюсь сломать его так же хорошо, как я могу, но нет ответа «хорошо для всех» на такой широкий вопрос, как ваш.
Во-первых, переменные задачи:
Список языков: будет ли ваш сайт находиться в предопределенном наборе языков или он будет разнообразным / неоднородным? Например, сайт может быть полностью двуязычным на двух хорошо определенных языках (или, например, я запускаю английский / каталонский / испанский сайт); или различные разделы могут быть доступны на разных языках (например, посмотрите на сайты MS: они в основном однородны, но такие вещи, как блоги, статьи в КБ и некоторые документы, доступны только в подмножестве предположительно поддерживаемых языков).
Источник перевода: есть ли контент, предоставленный вами на любом соответствующем языке вами или каким-либо сотрудником? Или некоторые версии запускаются через программное обеспечение для перевода с одного базового языка? Первый подход требует много дополнительной работы для создания содержимого, но дает более качественные результаты, чем второй.
Сами языки: как только у вас есть 1) и 2), вы должны знать, с какими языками вы работаете. Обратите внимание, что в случае, когда вы включаете диалекты (например, английский английский + английский английский или испанский испанский испанский или испанский испанский), вы можете столкнуться с некоторыми проблемами с «дублирующимся контентом» в поисковых системах, но подробности об этом слишком не по теме (просто упомянув, чтобы вы знали о потенциальных проблемах).
Вы ориентируетесь на языки в абстрактном (например, мой сайт предлагает три языка, не заботясь о том, где находится посетитель: это то, что у меня есть, поэтому выбирайте то, что вы предпочитаете); или, скорее, для разных регионов / стран? В более позднем случае все может стать более сложным, так как вам может понадобиться заботиться о других вещах, кроме языков (например, часовых поясах, валютах или соглашениях формата даты и времени, чтобы назвать их), но вы получаете возможность использовать специфические для конкретной страны ДВУ.
После того, как вы четко определитесь, начнем работать. Это наиболее важные задачи, которые вам необходимо выполнить:
Определение языка: наиболее разумным является использование параметра 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 и т. Д. Мои .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-запрос, но вы также можете размещать все сообщения в массиве и загружать его в память при загрузке скрипта. Пользователи всегда должны иметь возможность устанавливать язык, который они предпочитают, не полагайтесь слепо на заголовок языка, заданный веб-браузером.
Вы можете использовать простой язык 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);в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, которая должна быть многоязычной.
Одна из особенностей, которые большинство меня интересует, заключается в том, что клиент может спонтанно решить добавить или удалить язык.
По этой причине я не нацелен на добавление суффиксов проекта к таблицам базы данных, я не могу (и не хочу) изменять имена таблиц или обращаться к ним с использованием динамических имен, а также добавлять или удалять поля каждый раз, когда язык определен или удален ,
Я бы тоже не использовал файлы, просто потому, что мне нравятся базы данных, и они легко доступны.
И, наконец, я думаю, что в двух типах перевода:
Поэтому мой проект направлен на:
Это означает, что таблицы, поля которых будут иметь контент в одноязычном сценарии, теперь будут иметь пустое содержимое, потому что оно всегда будет в таблице переводов.
Это увеличит сложность запросов sql, но это позволит мне разработать инструменты для легкого перевода переводов. Кроме того, сложность sql будет существовать только один раз, только при реализации решения. Если эта реализация должным образом разработана, обслуживание / расширяемость сайта не должно быть серьезной проблемой.
Изменить :
После некоторого разговора с друзьями-разработчиками, я думаю, что решение, которое я предлагаю, слишком много на одной таблице.
Другой подход, который я буду изучать с этого момента, заключается в создании дополнительной таблицы для каждой «переводимой таблицы» следующим образом:
Эта схема наследует концепции от первой, но разделяет ее содержимое на таблицы. Это альтернативное решение может повысить производительность и изолировать проблемы (как проблемы с индексами).
Добавочная таблица переводов на «переводимую таблицу» будет создана в то же время, что и исходная.
И о запросах sql сложность остается прежней: для первого подхода требуется имя таблицы для поиска в таблице переводов, а вторая просто добавляет суффикс «_translations» в имени таблицы.