Благодаря всемирному успеху и географическому охвату WordPress, довольно легко понять, почему полезно иметь возможность плавного перевода плагинов, тем и самого WordPress на другие языки.
Однако, это не обязательно делает это легко принятым, и для этого есть веская причина.
Локализация (или интернационализация, как ее иногда называют) является источником большого замешательства и общего беспокойства для многих разработчиков WordPress. В конце концов, мы веб-разработчики, верно? Мы не знатоки лингвистики, и намного проще просто наносить метки на поля в наших программах на простом английском языке.
Кроме того, идея попытаться выяснить, как самостоятельно перевести текстовые строки на другие языки (не говоря уже о том, чтобы кто-то другой сделал это за вас), может вызвать легкую тошноту даже у опытных разработчиков, у которых никогда не было необходимости или желания сделай это раньше.
Но поверьте мне … это на самом деле не так уж и плохо, и это может значительно увеличить полезность, а также пользовательскую базу ваших пользовательских плагинов и тем для WordPress. Давайте разберем его на кусочки размером с укус, начиная с основы.
Основы интернационализации и локализации
Давайте рассмотрим эту вышеупомянутую тошноту развития немного. То, как многие из нас учились кодировать, идея учета языковых соображений при написании PHP-программ в лучшем случае носила академический характер.
Большинство коммерческих проектов в области кодирования ориентированы на определенные области и имеют определенную аудиторию, и зачастую было разумным предположением продолжать работу без учета перевода.
Однако, поскольку плагины и темы WordPress в конечном итоге становятся гораздо более полезными, когда пользователь может использовать его на своем родном языке, нам необходим систематический способ исправить эту проблему.
Введите i18n — еще одну забавную аббревиатуру, чтобы заправить себе под пояс. Названный в связи с тем, что между i и n в слове «интернационализация» находится 18 букв, I18n описывает идею создания программных систем, предназначенных для перевода на другие языки.
Процесс фактического перевода этого программного обеспечения на конкретный язык называется локализацией или l10n (можете ли вы угадать, сколько букв между «l» и «n» в слове «локализация» ?). WordPress использует специальную платформу для обработки i18n, которая называется GNU gettext — де-факто стандартная система, которая используется практически во всех программах с открытым исходным кодом. GNU gettext — это просто библиотека вспомогательных функций PHP.
Так как он закодирован прямо в ядре, WordPress имеет ловушки, необходимые для того, чтобы вы, как разработчик, могли определять переменные текстовых строк в ваших темах и плагинах, а также стандартизированная система, обеспечивающая переводы для каждой строки на неограниченном количестве языков.
Анатомия процесса локализации
В общих чертах, процесс локализации довольно прост. Концептуально, есть три ключевых компонента процесса для темы или плагина:
- использование GNU gettext markers в вашей теме или плагине, который позволяет WordPress знать, какие строки переводить
- функция, связывающая маркеры в вашей теме или плагине с файлом, который предоставляет ключ перевода, и
- файл, который предоставляет ключ перевода, по существу создавая и взаимно-однозначные отношения между переводимыми строками и тем, каким должен быть перевод для данной строки.
Давайте поговорим немного подробнее о том, что делает каждый из этих трех компонентов.
Компонент № 1: GNU gettext маркеры, которые позволяют WordPress знать, какие строки переводить
Прежде всего, мы должны сообщить WordPress, какие строки мы хотим перевести. Это делается непосредственно в выходном коде вашей темы или плагина, оборачивая конкретную строку с помощью функции PHP, которая определяет тип локализации, которую вы хотите сделать, а затем пропуская исходную строку через фильтр, который вернет правильную версию.
Хотя существует множество функций, которые позволяют вам определять или выводить локализованные строки различными способами, на самом деле есть только две функции локализации, которые вы будете использовать в подавляющем большинстве случаев:
__( 'string', $domain ) Это двойное подчеркивание , и оно возвращает локализованную строку.
_e( 'string', $domain )
Это подчеркивание «е» , и оно выводит локализованную строку прямо в браузер
Обратите внимание, что и __ и _e принимают два параметра: строку и домен. В этом контексте домен является строго уникальным идентификатором и не более чем меткой, прикрепленной к конкретному файлу перевода. Это отношение определено в Компоненте № 2.
Компонент № 2: функция, связывающая маркеры в вашей теме или плагине с файлом, который предоставляет ключ перевода
В вашей теме или плагине вам нужно создать связь между строками, которые вы хотите перевести, и файлом перевода, который предоставляет ключ для перевода строки.
Это делается с помощью одной из двух функций PHP: load_theme_textdomain() для тем или load_plugin_textdomain() для плагинов.
В случае локализации темы вы будете использовать load_theme_textdomain() в вашем файле functions.php . Функция принимает два параметра, как описано ниже:
load_theme_textdomain( $domain, $path )
$domain : уникальный идентификатор, назначаемый вашим настраиваемым переводимым строкам
$path : путь к вашему ключевому файлу перевода в теме
Ключи локализации тем отключены от константы WPLANG в wp-config.php , но об этом мы поговорим позже.
Локализация плагинов работает очень похоже на локализацию тем, но с некоторыми отличиями. Устанавливается либо в основных файлах PHP, либо в подключаемом load_plugin_textdomain() i18n, load_plugin_textdomain() принимает три параметра, как описано ниже:
load_plugin_textdomain( $domain, $abs_rel_path, $plugin_rel_path )
$domain : уникальный идентификатор, назначаемый вашим настраиваемым переводимым строкам
$abs_rel_path : необязательная устаревшая функция $abs_rel_path с WP 2.7. По умолчанию это false или просто опускается — беспокоиться не о чем
$plugin_rel_path : относительный путь к вашему файлу ключа перевода. Если вам не удастся определить этот путь, по умолчанию будет использоваться корневой каталог, в котором находится файл. Хотя это по определению необязательный параметр, рекомендуется хранить файлы языковых переводов отдельно от файлов логики, и поэтому обычно хотят указать значение здесь.
В обоих этих случаях $domain является уникальным идентификатором, на который мы ссылались в Компоненте # 1, и служит только для определения взаимосвязи между строками в коде, которые требуют перевода, и Компонентом # 3, ключом перевода.
Компонент № 3: файл, который предоставляет ключ перевода
GNU gettext предлагает нам систематический способ предоставления механизма для создания отношений перевода строки один к одному между отдельными строками по умолчанию и их соответствующими переводами, а затем эффективной подачи этих различных переводов строк в WordPress. Это делается с помощью .PO и .MO .
Файл .PO — это файл, который предоставляет читаемый и редактируемый ключ перевода для определенного языка. Например, если ваша тема или плагин были написаны на английском языке и у вас есть .PO переводы для французского, немецкого и пиратского английского, у вас будет три соответствующих файла .PO : по одному для каждого из языков. Когда выполняется перевод конкретной строки, это происходит в этом файле.
Хотя файлы .PO для человека и легко редактируемы, они не идеальны для использования WordPress при практической обработке перевода. Вместо этого WordPress будет использовать файл .MO для его реального перевода. Файлы .MO — это скомпилированные файлы, которые могут автоматически генерироваться для вас при использовании вспомогательных инструментов, таких как Poedit. Каждый файл .PO имеет соответствующий файл .MO который обновляется каждый раз, когда .PO файл .PO .
Окончательный тип файла, соответствующий типу файла, — это файл .PO или .PO шаблона .PO . Файл .POT — это особый вид файла .PO который является точной копией любого из файлов .PO в экземпляре локализации, за исключением того, что он не имеет каких-либо переводов. Предоставление .POT файлов .POT позволяет любому легко создавать переводы для ваших тем и плагинов на свой родной язык с помощью вспомогательных инструментов.
Собираем кусочки
Теперь, когда мы знаем основные компоненты процесса локализации, давайте наглядно рассмотрим, как они работают вместе в WordPress. Рассмотрим следующую диаграмму:
Начнем с исходного кода программы.
Когда браузер изначально перемещается для вызова определенной страницы, процесс перевода инициируется, когда он распознает функции __() и _e() в исходном коде, обертывающем текстовые строки.
WordPress распознает эти функции, потому что gettext GNU встроен в ядро, и автоматически пытается их перевести. Ваш файл functions.php уже загружен в это время, и WordPress может использовать функции load_plugin_textdomain() или load_theme_textdomain() в файле functions.php чтобы идентифицировать соединение строк с расположением библиотеки (изображено на шаге 1 в диаграмма выше) .
load_plugin_textdomain() или load_theme_textdomain() информацию о локали из константы WPLANG заданной в wp-config.php (шаг 2 на диаграмме выше), и .MO соответствующий файл .MO связанный с .MO (шаг 3 на диаграмме выше) ,
Если существует правильно названный .MO , функции выводят переведенные строки в браузер (шаг 4 на диаграмме выше) .
Если файл с именем .MO с правильным именем не существует или для каких-либо строк, которые не имеют переведенных записей в файле .MO , вместо этого в браузер выводится словоблудие по умолчанию.
Наконец, файл .MO является скомпилированной версией файла .PO , который доступен для редактирования человеком. Аналогично, файлы .PO имеют файлы шаблонов, которые позволяют переводчикам легко изменять строки в вашей программе на другие языки.
Похоже, мне не хватает места в этой статье, чтобы проиллюстрировать все это несколькими примерами, которые действительно воплощают в жизнь весь концептуальный процесс в WordPress, но я дополню еще одну статью, которая углубится в реальный код, задействованный на следующей неделе.