Локализация PHP и Gettext vs MyLang

Question

Локализация PHP и Gettext vs MyLang

Доброго дня всем!

Прошу Вебасист обратить внимание на проблему с приложением MyLang. В приложении существует перманентная проблема с обработкой файлов .mo и .po. Приложение, фактически, ломает эти файлы, из-за чего во фреймворке перестает полноценно работать локализация. Причем, в зависимости от выбранного спосособа локализации (PHP или Gettext), симптомы разнятся:
- MyLang + PHP: многие строки перестают переводиться вообще (не зависит от выбранного языка);
- MyLang + Gettext: не работает множественная локализация. Например: 1 отзыв, 2 отзыва, 5 отзыва (вместо 5 отзывов). Также не зависит от выбранного языка.

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

Проблема касается не только дополнительных локалей, но и оригинальной ru_RU.

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

С уважением.

4 ответа

+1

Плебей 1 августа 2019 13:06 #

Согласен. Но речь сейчас не о том.

+1

Alex 1 августа 2019 13:11 #

Отчасти да, но так же не могу работать с приложением MyLang + нет поддержки возможности перевода нужных мне плагинов

Добавить ответ

**Alex** · Answer 1

разработчикам вебасист давно было пора сделать самим поддержку языков и обязать всех сторонних разработчиков в магазине внедрять это в плагины

**Плебей** · Answer 2

Вот, к примеру, начало (шапка) оригинального файла shop.po:

msgid ""
msgstr ""
"Project-Id-Version: shop\n"
"POT-Creation-Date: 2013-02-11 12:44+0400\n"
"PO-Revision-Date: \n"
"Last-Translator: \n"
"Language-Team: shop\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=((((n%10)==1)&&((n%100)!=11))?(0):(((((n%10)>=2)&&((n%10)<=4))&&(((n%100)<10)||((n%100)>=20)))?(1):2));\n"
"X-Poedit-SourceCharset: utf-8\n"
"X-Poedit-Basepath: .\n"
"X-Generator: Poedit 2.0.6\n"
"Language: ru_RU\n"
"X-Poedit-SearchPath-0: .\n"
"X-Poedit-SearchPath-1: .\n"

и та же часть файла после пересохранения его в MyLang:

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"MIME-Version: 1.0\n"
"Content-Transfer-Encoding: 8bit\n"

Приложение неверно работает с файлами .po (соответственно, и .mo) и попросту ломает их. Здесь, как минимум, видим потерю правил множественных переводов "Plural-Forms". Размер оригинального девственного файла shop.po - 653389 B, его же размер после пересохранения приложением - 652932 B. С файлом shop.mo, соответственно, та же беда.

Уважаемая команда Вебасист, как вы тестируете сторонние приложения и плагины перед выпуском их в продажу? Или вас только предполагаемая маржа интересует?

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