После того, как я сам недавно решил эту проблему (12 языков и считал) в производственной системе и столкнулся с некоторыми серьезными проблемами с производительностью, я бы предложил гибридную систему.
1) Храните языковые строки и переводы в базе данных - это облегчит взаимодействие с / update / remove элементов и будет частью вашей обычной процедуры резервного копирования.
2) Кэшируйте языки в простые файлы на сервере и извлекайте их по мере необходимости для отображения на странице.
Преимуществ здесь много - в основном это быстро! Я не имею дело с издержками соединения для MySQL или какими-либо замедлениями трафика во время передачи. (особенно важно, если ваш сервер БД не является локальным).
Это также сделает его очень простым в использовании. Сохраните данные из вашей базы данных в файле в виде сериализованного массива php и скопируйте содержимое файла, чтобы уменьшить накладные расходы на хранилище (это также ускоряет мой сравнительный анализ).
Пример:
$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'). Если файл существует, загрузите содержимое, разархивируйте и удалите сериализацию, и он готов к работе.
Пример * * тысяча двадцать-один
$file_contents = get_contents( 'my_page.de' );
$lang = unserialize( gzuncompress( $file_contents ) );
Как вы можете видеть, вы можете сделать кэширование специфичным для каждой страницы в системе, уменьшая накладные расходы, и использовать расширение файла для обозначения языка ... (my_page.en, my_page.de, my_page.fr)
Если файл НЕ СУЩЕСТВУЕТ, тогда запросите БД, создайте свой массив, сериализовайте его, распакуйте и напишите отсутствующий файл - в то же время вы только что создали массив, который необходим странице, поэтому продолжайте отображать страница и все счастливы.
Наконец, это позволяет вам создавать страницы обновления, доступные для непрограммистов, но вы также контролируете, когда появляются изменения, решая, когда удалять файлы кэша, чтобы они могли быть восстановлены системой.
Предупреждения и ловушки
Когда я держал все в базе данных напрямую, мы сталкивались с некоторыми ОСНОВНЫМИ замедлениями, когда наш трафик увеличился.
Попытка сохранить их в массивах с плоскими файлами была такой большой проблемой, потому что обновления были болезненными и подвержены ошибкам.
Не GZIP-сжатие содержимого файлов кэша сделало языковую систему примерно на 20% медленнее в моих тестах.
Убедитесь, что для всех полей вашей базы данных, содержащих языки, установлено значение UTF8-general-ci (или хотя бы один из параметров UTF8, я считаю, что general-ci лучше всего подходит для моего использования). Если вы этого не сделаете, вы не сможете хранить наборы не-Unicode символов в вашей базе данных (например, китайский, японский и т. Д.)
Расширение:
В ответ на комментарий ниже обязательно настройте таблицы базы данных с учетом языковых строк на уровне страниц.
id string page global
1 hello NULL 1
2 good_morning my_page.php 0
Все, что отображается в верхних или нижних колонтитулах, может иметь глобальный флаг, который будет запрашиваться в каждом созданном файле кэша, в противном случае запрашивайте их по странице, чтобы ваша система реагировала.