Наиболее эффективный подход для многоязычного веб-сайта PHP

несколько вопросов:

1. Переводы
Кто будет переводить? Люди, которые также связаны с сайтом? Бюро переводов? При использовании Gettext вы будете работать с "pot" (.po) файлы. Эти файлы содержат идентификатор сообщения и строку сообщения (перевод). Пример:

msgid "A string to be translated would go here"  
msgstr ""

теперь это выглядит просто прекрасно и понятно для тех, кто должен перевести это. Но что происходит, когда вы используете ключевые слова, как Майк предлагает вместо полных предложений? Если кому-то нужно перевести msgid под названием "address_home", он или она понятия не имеет, должен ли это быть заголовок "домашний адрес" или что это полное предложение. В этом случае обязательно добавьте комментарии к файлу прямо перед вызовом функции gettext, например:

/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");

используя xgettext --add-comments=/// при создании .po файлы будут добавлять эти комментарии. Однако я не думаю, что Gettext можно использовать таким образом. Кроме того, если вам нужно добавить комментарии с каждый текст, который вы хотите отобразить, вы a) вероятно, сделаете ошибку в какой-то момент, b) вы весь скрипт будет заполнен текстами в любом случае, только в форме комментария, c) комментарии должны быть размещены непосредственно над функцией Gettext, что не всегда удобно, в зависимости от положения функции в вашем коде.

2. Обслуживание
Как только ваш сайт вырастет (еще больше) и ваши языковые файлы вместе с ним, это может стать довольно сложно чтобы поддерживать все различные переводы таким образом. Каждый раз, когда вы добавляете текст, вам нужно создать новые файлы, отправить файлы переводчикам, получить файлы обратно, убедиться, что структура все еще цела (нетерпеливые переводчики всегда рады перевести синтаксис, что делает весь файл непригодным для использования:)), и закончить с импортом новых переводов. Это выполнимо, конечно, но имейте в виду с возможными проблемами на этом конце с большими сайтами и многими другими языки.

лично я считаю более полезным управлять переводом с помощью (простой) CMS, сохраняя переменные и переводы в базе данных и экспортировать соответствующие тексты в языковые файлы самостоятельно:

1. добавить переменные в базу данных (например: id, page, variable);
2. добавить переводы к этим переменным (например: id, varId, language, перевод);
3. выберите соответствующие переменные и переводы, записи их в файл;
4. включите соответствующий языковой файл на свой сайт;
5. создайте свою собственную функцию для отображения текста переменных:

text('var'); или что-то вроде __('faq','register','lost_password_text');

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

плюсы:

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

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

3. открыть. Этот зависит от того, кто будет переводить. Вы можете обернуть CMS простым логином, чтобы предоставить доступ людям из бюро переводов, если это необходимо, и позволить им изменять только определенные языки или даже определенные части сайта. Если это не вариант, вы все равно можете вывести данные в файл, который можно вручную перевести и импортировать его позже (хотя это может произойти с теми же проблемами, что и раньше.). Вы можете добавить один из переводов, который уже есть (английский или другой основной язык) как контекст для переводчика.

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