Проблемы русского WordPress’а
Если вы решили поставить себе для сайта WordPress, то скорее всего столкнетесь с двумя главными проблемами: первая - локализация (перевод на русский), вторая - кодировка.
Локализация
WordPress это англоязычная разработка, поэтому весь «движок» имеет английский интерфейс. Разработчики для того, чтобы обеспечить перевод на другой язык предусмотрели т.н. модульный перевод. То есть создаются фалы в которых содержатся исходные сообщения и их перевод.
Некоторые технические подробности того, как в WordPress'е происходит «стандартная» локализация.
Принцип «модульного перевода» в том, что исходные файлы WordPress'а обрабатываются специальными программами и создаются три файла, в которых хранятся «положения» выводящих функций (объектный шаблон - Portable Object Template), список сообщений (Portable Object) и скомпилированный файл (Machine Object). То есть создается некий шаблон-каркас через который «пропускаются» выводимые сообщения. В теории это все красиво, но на практике для того, чтобы поменять перевод нужно заново компилировать po- и mo-файлы, что не совсем удобно. Кроме этого файлы локализации получаются «привязанными» к конкретной версии WordPress'а, что опять же не желательно. Ну и последний недостаток это то, что файлы локализации получаются достаточно объемными. Например, русская локализация занимает примерно 250 Кб, что может серьезно сказаться на скорости выполнения PHP-скриптов. Во всяком случае на localhost'е WordPress работает с вполне заметным притормаживанием.
На мой взгляд, использование именно такого алгоритма перевода не очень удачно, поскольку
- жестко привязанно к версии;
- перевод нужно делать с помощью специальных программ;
- большие результирующие файлы перевода.
Последнее замечание может оказать решающее значение, поскольку при большой посещаемости сайта при каждом обновлении страниц будет выполняться и загрузка с диска файлов перевода. Считывание файла с диска приводит к повышению загрузки процессора на сервере и, в итоге, админ может предъявить вам претензии, что ваш сайт сильно загружает систему. В зависимости от хостера, администратор может отключать сайт, при превышении, скажем 1% CPU.
Примерно три года назад, когда популярными были форумы без использования базы данных, и который, естественно я использовал, мой хостер предъявил мне претензии, что форум чрезмерно потребляет ресурсы. После анализа выяснилось, что база форума - файл который имел размер около 500Кб, создает эту самую проблему (было 1.5-2% CPU, посещаемость примерно 800 хитов в день). После переделки форума на MySql, то есть за счет отказа от использования такого файла, нагрузка упала примерно в 10 раз, до 0.1% CPU.
Вместо использования тяжеловесных файлов «po» и «mo» я предлагаю использовать другой алгоритм, который позволяет использовать всего один файл с переводом: Установка русского WordPress'а
Кодировка WordPress'а
Изначально WordPress устанавливает для себя кодировку UTF-8 (юникод). Все споры как раз и вертятся вокруг того, что это «универсальная» кодировка, поэтому и нужно ее использовать. Но, как выяснилось, основным агрументом в пользу выбора UTF-8 остается чисто субъективный подход: нравится/не нравится. Кроме того, UTF-8 обрасла различными мифами.
Забегая немного вперед, скажу, что у нас в рунете в основном используется другая кодировка Windows-1251. То есть русскоязычные хостинги скорее всего будут использовать именно эту кодировку по умолчанию, поскольку она не создает никаких проблем для русскоязычного пользователя. Вот именно выбор между Windows-1251 и UTF-8 создал такой жаркий спор.
1. UTF-8 - стандарт для Интернета, все к нему прийдем!
Уточнение. UTF-8 - это лишь один из множества стандартов. Windows-1251 - точно такой же стандарт. Более того, в браузеры встроена поддержка практически всех кодировок и, для того, чтобы убедиться в этом, достаточно зайти в меню браузера «Вид -> Кодировка».
2. UTF-8 более универсальна.
Уточнение. UTF-8 - это «переходная» кодировка UTF-16 (-32) или просто юникод (unicode) для Интернета. Все дело в том, что символы юникода определяются не одним, а несколькими байтами. Это позволяет закодировать не 256 символов, как в обычной 8-битной кодировкие, а примерно 90 тысяч (UTF-8) и более (UTF-16). Использование UTF-8 действительно даст возможность отображать на сайте сразу несколько языков, например французский, русский и испанский. Если ваш сайт планируется использовать как многоязычный, то особой альтернативы UTF-8 нет.
3. UTF-8 позволяет вставлять на сайт специальный символы (дроби, sup, sub и т.д.)
Уточнение. Теоретически вы можете вставить на своей странице такие символы (визуально имеется ввиду), но по правилам HTML, все спецсимволы должны быть представленны в определенном виде. Для каждого такого символа предусмотрена специальная синтаксическая конструкция. В этом случае отображение спецсимволов целиком ложится на браузер и уже не зависит от используемой кодировки.
4. UTF-8 позволяет корректно отображать любые языковые символы
Уточнение. Любая кодировка это всего лишь способ кодирования знаков. Само же отображение символа с определенным номером целиком зависит от используемого шрифта. То есть теоретически каждый юникодовский шрифт должен содержать в себе написания всех алфавитов (письмен). Но на практике подавляющее большинство шрифтов содержат в себе лишь написания «своего» языка и английский. Для того, чтобы в этом убедиться откройте таблицу символов и «поиграйтесь» с разными шрифтами и кодировками. В этом плане использование UTF-8 не дает никаких преимуществ перед «национальными» кодировками.
5. Для работы с UTF-8 нужны специальные программы.
Уточнение. Как выяснилось, современные программы позволяют корректно работать с UTF-8. Даже стандартный Блокнот позволяет сохранять файлы в кодировке UTF-8. Правда мне пока так и не удалось узнать о программе, которая позволяет «на лету» конвертировать текст в/из UTF-8 и Windows-1251: для этого придется либо пересохранить файл в нужную кодировку, либо воспользоваться буфером обмена.
6. С UTF-8 могут возникнуть проблемы на хостинге.
Уточнение. На большинстве русскоязычных хостингах по умолчанию установленна кодировка Windows-1251, включая и для базы данных. Поэтому для того, чтобы ваш сайт мог корректно сохранять свои данные, необходимо выполнить дополнительный SQL-запрос, указывающий БД использовать нужную вам кодировку. Если же этого не сделать, то возможны ошибки конвертации текстов, которые могут выражаться, например в «выпадании» каких-либо букв. Если говорить правильно, то ваши данные дожны быть в той же самой кодировке в которой они хранятся на сервере.
7. UTF-8 это «родная» кодировка WordPress'а.
Уточнение. Данное утверждение основанно на том, что при инсталяции WordPress прописывает UTF-8 как кодировку блога. Однако не стоит забывать, что в WordPress'е существует отдельно поле, позволяющее установить любую другую кодировку. Поэтому WordPress может работать в любой кодировке по желанию пользователя. Существует другая проблема, которая имеет чисто технический характер. В некоторых файлах жестко прописана кодировка UTF-8, например, при инсталяции, когда еще нет доступа к базе данных. Решение этой проблему очень не сложное, но, как показывает практика, то проще через «поиск/замену» изменить UTF-8 на нужную кодировку, тем более, что таких файлов очень немного.
8. Trackback'и корректно работают только в UTF-8.
Уточнение. Данная проблема напрямую связана с ошибкой в самом WordPress'е. Все дело в том, что при посылке Trackback'а, WordPress должен посылать и кодировку, но не делает этого. Подробнее об исправлении этого бага и дополнительных методах определения кодировки входящих текстов, см. здесь: «Проблемы кодировки trackback и ее решение». Никакого отношения ни к UTF-8, ни к Windows-1251 эта проблема не имеет.
9. Ping'и корректно работают только в UTF-8.
Уточнение. Пинги - похожий на трэкбэки механизм взаимодейсивия между сайтами. И точно также, как и в случае трэкбэками WordPress должен анализировать кодировку страницы чужого блога (тэг «meta charset»). Но, опять же не делает этого. Этот баг также имеет свое исправление: «Исправляем кодировку Ping в WordPress'е».
10. Существующие блог-клиенты нормально работают только в UTF-8.
Уточнение. Блог-клиенты это специальные компьютерные программы, которые позволяют, например, опубликовать новое сообщение на сайте, не заходя на сам сайт. К достоинствам блог-клиентов следует отнести оперативность, быстота работы, более удобный интерфейс по сравнению с web-интерфейсом сайта. Такие программы взаимодействуют с использованием технологии XML-RPC, которая встроенна также и в WordPress. В некоторых блог-клиенты можно указать кодировку блога, в других нельзя. Но, для того, чтобы ваш WordPress мог работать с любым блог-клиентом необходимо добавить всего одну строчку кода. Это также недочет, который допустили разработчики «движка». Что и где нужно исправлять в WordPress'е оставлю секретом. 
Постоянная ссылка: http://maxsite.org/?p=33
Версия для печати
