Я разрабатываю веб-сайт на PHP, и я хотел бы дать пользователю легко переключаться с немецкого на английский.
Итак, политический перевод должен быть рассмотрен:
Должен ли я хранить данные и их перевод в таблице базы данных ((1, «Hello», «hallo»), (2, «Доброе утро», «Тег Guten») и т. Д.?
Или я должен использовать файлы «.mo» для его хранения?
Какой путь лучше?
Каковы плюсы и минусы?
Есть несколько факторов, которые вы должны учитывать.
Будет ли сайт обновляться часто? если да, кем? вы или владелец? сколько данных / информации вы имеете в виду? а также … вы часто это делаете (для многих клиентов)?
Я с трудом могу думать, что использование реляционной базы данных может привести к серьезным последствиям скорости, если у вас нет ОЧЕНЬ большого трафика (несколько сотен тысяч просмотров страниц в день).
Если вы часто это делаете (для множества клиентов), не думайте, что дальше: создайте CMS (или используйте существующую). Если вам действительно нужно учитывать влияние скорости, вы можете настроить его так, чтобы, когда вы закончите работу с веб-сайтом, вы можете экспортировать статические HTML-страницы, где это возможно.
Если вы часто обновляетесь, применяется то же, что указано выше. Если клиент должен обновить (а не вы), опять же, вам нужна CMS. Если вы имеете дело с большим количеством информации (больших и больших статей), вам нужна CMS.
В целом, CMS поможет вам быстро создать структуру вашего сайта, быстро добавить контент и не беспокоиться о коде, поскольку он будет повторно использоваться.
Теперь, если вам просто нужно быстро создать небольшой сайт, вы можете легко сделать это с помощью жестко заданных массивов и файлов данных.
После того, как я недавно занялся этим (12 языков и считал) в производственной системе и столкнулся с некоторыми серьезными проблемами производительности, я предлагаю гибридную систему.
1) Сохраните языковые строки и переводы в базе данных – это упростит взаимодействие с элементами / update / remove и станет частью ваших обычных подпрограмм резервного копирования.
2) Загрузите языки в плоские файлы на сервере и вычеркните их при необходимости, чтобы отобразить на странице.
Преимущества здесь много – в основном это быстро! Я не имею дело с накладными расходами на связь для MySQL или любым замедлением трафика во время передачи. (особенно важно, если ваш сервер БД не является localhost).
Это также сделает его очень простым в использовании. Храните данные из своей базы данных в файле в виде сериализованного массива php и GZIP, чтобы содержимое файла уменьшалось из-за нехватки памяти (это также делает его быстрее в моем бенчмаркинге).
Пример:
$lang = array( 'hello' => 'Hallo', 'good_morning' => 'Guten Tag', 'logout_message' = > 'We are sorry to see you go, come again!' ); $storage_lang = gzcompress( serialize( $lang ) ); // WRITE THIS INTO A FILE SUCH AS 'my_page.de' Когда пользователь загружает вашу систему в первый раз, file_exists('/files/languages/my_page.de') . Если файл существует, загрузите контент, un-gzip и un-serialize, и он готов к работе.
пример
$file_contents = get_contents( 'my_page.de' ); $lang = unserialize( gzuncompress( $file_contents ) );
Как вы можете видеть, вы можете сделать кеширование специфичным для каждой страницы в системе, чтобы уменьшить накладные расходы и использовать расширение файла для обозначения языка … (my_page.en, my_page.de, my_page.fr)
Если файл НЕ существует, тогда запросите БД, постройте свой массив, сериализуйте его, gzip и напишите отсутствующий файл – в то же время вы только что создали массив, который нужна странице, чтобы продолжить отображение страницы и все счастливы.
Наконец, это позволяет создавать страницы обновлений, доступные для не-программистов, но вы также управляете появлением изменений, решая, когда удалять файлы кеша, чтобы их можно было перестроить системой.
Предупреждения и ловушки
Когда я хранил все в базе данных напрямую, мы поразили некоторые ОСНОВНЫЕ замедления, когда наш трафик увеличился.
Попытка сохранить их в массивах с плоскими файлами была настолько сложной, что обновления были болезненными и подвержены ошибкам.
Не GZIP, сжимающий содержимое файлов кеша, заставлял языковые системы примерно на 20% медленнее в моих тестах.
Убедитесь, что все поля вашей базы данных, содержащие языки, установлены в UTF8-general-ci (или, по крайней мере, один из параметров UTF8, я считаю, что для большинства пользователей я использую general-ci). Если вы этого не сделаете, вы не сможете хранить не-юникодные наборы символов в своей базе данных (например, на китайском, японском и т. Д.),
Расширение: в ответ на приведенный ниже комментарий обязательно установите таблицы базы данных со строками языка уровня страницы.
id string page global 1 hello NULL 1 2 good_morning my_page.php 0
Все, что отображается в верхних или нижних колонтитулах, может иметь глобальный флаг, который будет запрашиваться в каждом созданном файле кэша, иначе запросите их по странице, чтобы ваша система реагировала.
Я также предложил пакет Zend Framework Zend_Translate .
В руководстве дается хороший обзор того, как решить, какой адаптер перевода использовать . Даже если вы не используете ZF, это даст вам некоторые идеи о том, что там и что за плюсы и минусы.
Адаптеры для Zend_Translate
Массивы PHP – это самый быстрый способ загрузки переводов. Однако вы действительно не хотите обновлять эти файлы вручную в редакторе. Это может работать в начале и на одном или двух языках, но когда ваш сайт растет, это становится очень трудно поддерживать.
Я советую вам установить несколько простых таблиц в базе данных, где вы держите переводы, и создать простое приложение, которое позволяет вам обновлять переводы (некоторые формы для добавления и обновления текстов). Что касается базы данных: используйте одну таблицу для хранения переменных перевода; используйте другое, чтобы связать переводы с этими переменными.
Пример:
`Text` переменная id 1 привет 2 bye
`text_translations` Перевод текста 1 1 привет 2 1 de hallo 3 2 en bye 4 2 de tschüss
Итак, что вы делаете:
создать переменную в первой таблице
добавьте перевод для него во вторую таблицу (на любом языке, который вы хотите)
После того, как вы обновили переводы, создайте / обновите языковой файл для каждого используемого вами языка:
выберите нужные вам переменные и его перевод (совет: используйте английский, если нет перевода)
создайте большой массив со всем этим, например:
$texts = array('hello' => 'hallo', 'bye' => 'tschüss');
file_put_contents('de.php', serialize($texts));
$texts = unserialize(file_get_contents('de.php'));
<h1><?php echo $texts['hello']; ?></h1> or if you like/enabled PHP short tags: <p><?=$texts['bye'];?></p>
Эта настройка очень гибкая, и с несколькими формами для обновления переводов легко обновлять свой сайт на нескольких языках.
Если вам нужно предоставить веб-интерфейс для добавления / редактирования переводов, тогда база данных – хорошая идея.
Если, однако, ваши переводы статичны, я бы использовал gettext или даже простой массив PHP.
В любом случае вы можете использовать Zend_Translate.
Небольшое сравнение, первые два из учебника Zend:
Я бы рекомендовал массивы PHP, они могут быть построены вокруг графического интерфейса для легкого доступа.
Будьте в курсе всех в мире, когда имеете дело с компьютером, обычно они знакомы с обычным английским языком, используемым в компьютере или Интернете, например, «О нас», «Домой», «Отправить», «Удалить», «Читать дальше» и т. Д. Вопрос: действительно ли они должны быть переведены?
Хорошо, честно говоря, некоторый перевод на эти слова на самом деле не о «обязательном», это все о «стиле».
Теперь, если это действительно необходимо, для общих слов, которые не нужно менять навсегда, лучше использовать файл php, который выводит массив lang только для локального и английского языков. И для некоторого содержимого, такого как блог, новости и некоторые описания, используйте базу данных и сохраняйте столько, сколько требуется для перевода языка. Вы должны сделать это вручную.
Использовать и полагаться на Google Translate? Думаю, вы должны думать 1000 раз. По крайней мере, за это десятилетие.