На рассмотрении

+2

Перевод сайта. Интернационализация контента

Поло Арт Обновлен 3 года назад в категории CMS Общий функционал 7

Всем привет!

Создаём новый проект и столкнулись со следующей проблемой

https://readyscript.ru/dev-manual/dev_lang.html#dev_lang_initialization
Идентификатором языка является двухсимвольное обозначение языка. Например: en,de,ru. Идентификатор языка получается с помощью метода RS::Language::getCurrentLang. Метод возвращает текущий язык системы по следующему правилу:

Если это административная зона:
попытка использовать язык, установленный в cookie
попытка использовать язык браузера
возвращается базовый язык

Если это клиентская часть:
попытка использовать язык, установленный в cookie
попытка использовать язык текущего сайта
возвращается базовый язык

Вопрос. Для чего и зачем именно так сделано?!
Если сайт на английском, то всё должно быть на английском по дефолту. Заходит в админку, допустим, наёмный сотрудник, у которого локаль польская - и что он получит? Админку на русском!

Условие задано в файле /core/rs/language/core.inc.php в функции getCurrentLang() как:
if (\RS\Router\Manager::obj()->isAdminZone()) {
//Если это административная панель
$sysLangs = self::getSystemLanguages();

if ($request->cookie(self::COOKIE_ADMIN_LANG, TYPE_STRING)) {
//Ищем установленный язык в cookie
$current_lang = $request->cookie(self::COOKIE_ADMIN_LANG, TYPE_STRING);
} else {
//Ищем предпочтительный язык у браузера
$accept_langs = explode(',', $request->server('Accept-Language'));

ЗАЧЕМ?!

Я создаю core.my.inc.php, где убираю это условие, оставляю лишь:
if ($request->cookie(self::COOKIE_CUSTOMER_LANG, TYPE_STRING)) {
//Читаем параметр из cookie
$current_lang = $request->cookie(self::COOKIE_CUSTOMER_LANG, TYPE_STRING);
} else {
$site = \Setup::$INSTALLED ? \RS\Site\Manager::getSite() : null;
$current_lang = ($site) ? $site->language : $request->cookie(self::COOKIE_CUSTOMER_LANG, TYPE_STRING, \Setup::$DEFAULT_LANG);
}

Но все эти my в ядре это так, на время... пока не обновится что-то. А с второй версии очень многое обновилось.

Второй вопрос. Где взять полные файлы messages.lng.php и messages.js.php ?
Сидеть по строчке выковыривать очень и очень долго.

Третий вопрос. Что делать с тем, что строковые значения постоянно вместе с апдейтами, чуть-чуть, да изменяются?

Комментарии 7

  • Артем Полторанин 3 года назад

    Поло Арт, думаю все ответы на вопросы ЗАЧЕМ??? вы найдете, когда попробуйте создать хотя бы один проект с интернационализацией на ReadyScript.
    У нас предусмотрено достаточно много кейсов на перспективу. При входе в админку, если у вас более одного языка будет выбор прямо в форме авторизации. На фронте у клиента может быть также n языков и заложена возможность переключения языка прямо на сайте.

    Сейчас у нас уже есть проекты с интернационализацией. Вот, например, один: https://mybobbin.com/
    Для формирования языковых файлов есть утилита в настройках Системного модуля, просто воспользуйтесь ей.

    Кстати, чтобы закладывать кастомную логику в выбор языков не нужно городить my.inc., обратите внимание на RS\Language\Core::setCurrentLang($lang)
    Просто подпишитесь на очень раннее событие initialize и реализуйте свою логику установки дефолтного языка.

    • Поло Арт 3 года назад

      Артем, спасибо за ответы.
      Дело в том, что нам нужна не мультиязычность, а чёткий перевод, который будет всегда и для всех. Если английский, то никогда и никому не должен включиться русский. Спасибо за наводку, сегодня посмотрим.
      И, немного раскрою карты - в новом проекте перевод также на русский ;) просто это будет не интернет-магазин.

    • Поло Арт 3 года назад

      Артем, вот ещё замечания - языковые файлы сформировались, но!
      1. имеется довольно большое количество грамматических ошибок - надо бы вычитывать, не красит это такой прекрасный продукт
      2. утилита не сформировала строки для перевода пунктов меню. Например, "Каталог товаров". Я смотрю в /templates/system/resource/lang/, возможно, где-то ещё искать?

      • Артем Полторанин 3 года назад

        Утилита просто парсит конструкции {t}{/t} - в шаблонах, t() - в php, lang.t - в js.
        Пункты меню не попадают в данный файл. Обычно, разные языковые версии у нас запускаются в разных мультисайтах и там появляется возможность настроить блок на другую ветку меню и создавать другое меню для другого языка в админке.

        Но есть и другая возможность. Перегрузите шаблон отображения меню и оберните там вывод названия пункта меню функцией {t}{$item.fields.title}{/t} или {t($item.fields.title)} и добавьте в языковый файл нужные названия пунктов меню.

        • Поло Арт 3 года назад

          Артем, имелись в виду меню админки. Они нормально переводятся, хотя и не обёрнуты в {t}, например, {$elements.formTitle} которая выводит "Каталог товаров" вполне себе поддаётся переводу.

          В теме же... не вижу смысла в {t}, забьём напрямую, как необходимо.

        • Поло Арт 3 года назад

          Артем, да, и самое главное - всё пока идёт круто ;)
          Почему вы продукт RS используете только под интернет-магазин, я хз, возможностей здесь намного и намного больше.

  • Артем Полторанин 3 года назад

    Что делать с тем, что строковые значения постоянно вместе с апдейтами, чуть-чуть, да изменяются?

    Это действительно проблема, но из всех зол мы выбрали меньшее.
    Так как альтернативой было только использование коротких английских идентификаторов вместо фраз, это бы ухудшило читаемость шаблонов и усложнило разработку тем в разы. Этот вариант мы отклонили сразу.

    То есть, если у вас меняется строковое значение, измените его сразу в файле с переводом. Или при следующем формировании нового языкового файла с помощью утилиты, новая фраза просто появится в конце.

Написать сообщение