Наскоро ми се наложи да правя сайт с WordPress на Иврит. За незапознатите с особеностите на близкоизточните езици ще напомня, че се пишат от дясно на ляво и нямат главни букви. Освен това чуждите думи, изписани на латиница (или друга писменост, която се пише от ляво на дясно), както и числа, изписани с арабски цифри, се пишат както си трябва – от ляво на дясно. WordPress поддържа достатъчно добре всякакви писмености и езици, правилната локализация също е важно условие за одобряване на темите в wordpress.org. Аз обаче се сблъсках с един проблем на разширението Contact Form 7, който не е очевиден, когато сайтът е на език, изписван от ляво на дясно. В случая с Иврит обаче, въпреки че всичко останало по сайт сменяше посоката на подравняване на текста и елементите, полетата във формата оставаха подравнени вляво. Бърз преглед на генерирания HTML показа наличието на атрибути lang и dir на елемента, който съдържа формата, за манипулиране на които атрибути няма настройка. Проблемът е, че в моя случай тези атрибути имаха стойности като за английски локал, което не само, че обръщаше подравняването на текста, но би имало неприятни последици и за потребителите на екранни четци – ако екранният четец превключи на друг език, това би било най-малкото доста объркващо.

След кратко търсене в сайта на разширението и в Гугъл намерих въпрос, зададен от потребител, използващ Contact Form 7 в многоезичен сайт на английски и арабски. Неговият проблем беше подобен на моя – формите на арабски си оставаха подравнени вляво. Отговорът за мен изглежда доста нелепо: локала на формата се установява на базата на локала на администрацията по време на създаване на формата и се наследява при клониране на формата. При условие, че често в многоезичните (а и не само) сайтове администраторите на сайта използват локал, различен от този на публичния сайт, и като имаме предвид, че новите версии на WordPress дават възможност в администрацията потребителите да избират локал, различен от основния локал на сайта, това поведение на Contact Form 7 има сериозни последствия върху достъпността на сайта. Проблемът може да се отрази не само на потребителите, използващи екранни четци, но и на всички останали – въпреки, че разширението блокира валидирането на формите в браузъра, това може да бъде отменено от други разширения, и тогава съобщенията на браузъра ще са на езика, установен от локала на формата, а не на езика на сайта.

Понеже не намерих конкретно решение на проблема, освен да си сменям езика в администрацията – това не беше решение в случая – се зарових в кода на разширението. И намерих точно каквото ми трябваше – кука за действие, чрез което могат да се манипулират свойствата на обекта, отговарящ за генерирането на формата, точно преди превръщането ѝ в HTML. Ето и кодът, който написах:

function gonzo_fix_cf7_locale( $cf7 ) {
  $cf7->set_locale( get_locale() );
}
add_action( 'wpcf7_contact_form', 'gonzo_fix_cf7_locale' );

Това, което правя е просто – пренаписвам локала на формата с основния локал на сайта. Решението е универсално и ще работи винаги, когато формата е на същия език като сайта.