Несколько соображений:
1. Переводы
Кто будет делать переводы? Люди, которые тоже подключены к сайту? Бюро переводов? При использовании Gettext вы будете работать с файлами '.po'. Эти файлы содержат идентификатор сообщения и строку сообщения (перевод). Пример:
msgid "A string to be translated would go here"
msgstr ""
Теперь это выглядит прекрасно и понятно для всех, кому нужно перевести это. Но что происходит, когда вы используете ключевые слова, как предлагает Майк, вместо полных предложений? Если кому-то нужно перевести сообщение с именем «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 может быть использован таким образом. Кроме того, если вам нужно добавить комментарии с каждым текстом, который вы хотите отобразить, вы а) возможно, допустите ошибку в какой-то момент, б) ваш сценарий будет заполнен текстами в любом случае, только в форме комментария, в) комментарии должны быть размещены непосредственно над функцией Gettext, что не всегда удобно, в зависимости от положения функции в вашем коде.
2. Техническое обслуживание
Как только ваш сайт вырастет (даже дальше) и ваши языковые файлы вместе с ним, может быть довольно сложно поддерживать все различные переводы таким образом. Каждый раз, когда вы добавляете текст, вам нужно создать новые файлы, отправить файлы переводчикам, получить файлы обратно, убедиться, что структура все еще не повреждена (нетерпеливые переводчики всегда рады перевести и синтаксис, создавая весь файл). непригодный для использования :)), и закончите с импортированием новых переводов. Конечно, это выполнимо, но имейте в виду возможные проблемы на этом уровне с большими сайтами и множеством разных языков.
<ч />
Другой вариант: объедините ваш второй и третий вариант:
Лично я считаю более полезным управлять переводом с помощью (простой) CMS, хранить переменные и переводы в базе данных и самостоятельно экспортировать соответствующие тексты в языковые файлы:
- добавить переменные в базу данных (например, id, page, variable);
- добавить переводы к этим переменным (например, id, varId, language, translation);
- выбрать соответствующие переменные и переводы, записать их в файл;
- включить соответствующий языковой файл на вашем сайте;
- создайте свою собственную функцию для отображения текста переменных:
text('var'); или, может быть, что-то вроде __('faq','register','lost_password_text');
Точка 3 может быть такой же простой, как выбор всех соответствующих переменных и переводов из базы данных, помещение их в массив и запись сериализованного массива в файл.
Преимущества:
обслуживание. Ведение текстов может быть намного проще для больших проектов. Вы можете группировать переменные по странице, разделам или другим частям на вашем сайте, просто добавив столбец в вашу базу данных, который определяет, к какой части сайта принадлежит эта переменная. Таким образом, вы можете быстро получить список всех переменных, используемых, например, в. страница часто задаваемых вопросов.
Транслейтинг. Вы можете отобразить переменную со всеми переводами всех разных языков на одной странице. Это может быть полезно для людей, которые могут переводить тексты на несколько языков одновременно. И было бы полезно увидеть другие переводы, чтобы понять контекст, чтобы перевод был как можно лучше. Вы также можете запросить базу данных, чтобы узнать, что было переведено, а что нет. Возможно, добавьте метки времени, чтобы отслеживать возможные устаревшие переводы.
Доступ. Это зависит от того, кто будет переводить. Вы можете обернуть CMS простым логином, чтобы предоставить доступ к людям из бюро переводов, если это необходимо, и разрешить им изменять только определенные языки или даже определенные части сайта. Если это не вариант, вы все равно можете вывести данные в файл, который можно перевести вручную и импортировать позже (хотя это может привести к тем же проблемам, что и упомянутые ранее). Вы можете добавить один из уже переведенных переводов (английский или другой основной язык) в качестве контекста для переводчика.
В целом, я думаю, вы обнаружите, что таким образом у вас будет намного больше контроля над переводами, особенно в долгосрочной перспективе. Я не могу вам ничего сказать о скорости или эффективности этого подхода по сравнению с нативной функцией gettext. Но, в зависимости от размера языковых файлов, я не думаю, что это будет большой разницей. Если вы группируете переменные по странице или разделу, вы всегда можете включить только необходимые части.