Что лучший способ состоит в том, чтобы поместить систему перевода в php веб-сайт?

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

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

Пример:

`text`

id  variable
1   hello
2   bye

`text_translations`

id  textId  language  translation
1   1       en        hello
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));

• в вашем PHP / HTML создать массив из файла (на основе выбранного пользователем языка), например:

$texts = unserialize(file_get_contents('de.php'));

• в вашем PHP / HTML используйте переменные, например:

<h1><?php echo $texts['hello']; ?></h1>

or if you like/enabled PHP short tags:

<p><?=$texts['bye'];?></p>

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

Я недавно сам решил эту проблему (12 языков и больше) на производственной системе и столкнулся с некоторыми серьезными проблемами производительности по пути, я бы предложил гибридную систему.

1) Сохраните языковые строки и переводы в базе данных - это упростит взаимодействие с / обновлением / удалением элементов, а также станет частью ваших обычных процедур резервного копирования.

2) Кэшируйте языки в плоские файлы на сервере и при необходимости извлекайте их для отображения на странице.

Здесь много преимуществ - в основном это быстро! Я не имею дело с накладными расходами на соединение для MySQL или замедлением трафика во время передачи. (особенно важно, если ваш сервер БД не является локальным хостом).

Это также сделает его очень простым в использовании. Сохраните данные из вашей базы данных в файле в виде сериализованного массива 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') . Если файл существует, загрузите содержимое, разархивируйте и распакуйте сериализацию, и он готов к работе.

Пример

$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 лучше всего подходит для моего использования). Если вы этого не сделаете, вы не сможете хранить в своей базе данных наборы символов, отличных от Юникода (например, китайский, японский и т. Д.).

Расширение: В ответ на комментарий ниже обязательно чтобы настроить таблицы базы данных с учетом языковых строк на уровне страницы.

id      string              page        global
1       hello               NULL          1
2       good_morning        my_page.php   0

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

Я бы также предложил пакет Zend Framework Zend_Translate .

В руководстве содержится хороший обзор Как решить, какой адаптер перевода использовать . Даже если вы не используете ZF, это даст вам некоторое представление о том, что существует, и каковы плюсы и минусы.

Адаптеры для Zend_Translate

• Массив
  • Использование массивов PHP. Маленькие страницы;
  • простейшее использование; только для программистов
• CSV
  • Использовать файлы, разделенные запятыми ( .csv / .txt)
  • Простой текстовый формат файла; быстрый; возможные проблемы с символами юникода
• Gettext
  • Используйте двоичные файлы gettext (* .mo), стандартные для Linux;
  • поточно-ориентированный; требуются инструменты для перевода
• Ini
  • Используйте простые файлы ini (* .ini)
  • Простой формат текстового файла; быстрый; возможные проблемы с символами Юникода
• Tbx
  • Использовать файлы обмена терминологической базой ( .tbx / .xml)
  • Промышленный стандарт для строк терминологии между приложениями; Формат XML
• Tmx
  • Используйте файлы tmx ( .tmx / .xml)
  • Промышленный стандарт для межприложений перевода; Формат XML; читабельный
• Qt
  • Использовать файлы qt linguist (* .ts)
  • Межплатформенный каркас приложения; Формат XML; читаемый человеком
• Xliff
  • Использовать файлы xliff ( .xliff / .xml)
  • Более простой формат как TMX, но связанный с ним; Формат XML; удобочитаемый
• XmlTm
  • Используйте xmltm (*.xml) файлы
  • Промышленный стандарт памяти переводов XML-документов; Формат XML; читабельный

Если вам нужно предоставить веб-интерфейс для добавления / редактирования переводов, то база данных - хорошая идея.

Если, однако, ваши переводы статичны, я бы использовал gettext или даже простой массив PHP.

В любом случае вы можете воспользоваться Zend_Translate.

Небольшое сравнение, первые два из учебника Zend:

1. Простые массивы PHP : Маленькие страницы; простейшее использование; только для программистов.
2. Gettext : стандарт GNU для Linux; потокобезопасный; нужны инструменты для перевода.
3. База данных : динамическая; Худшая производительность.

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