Константин (Автор тем)

Очевидно что при создании модуля обошли стороной HL блоки, функционал явно сырой.

1. Если при вызове HL Блока в getlist вставить "select" => array("*"), то значения вернутся непереведенные. Без этого параметра переводится.

2. Массив переведенных значений имеет дубли в названии ключей UF_UF_ и деже если после использовать функцию RenameRowKeys всё равно не переименовываются, она тоже не работает корректно

3. Выше пункты еще цветочки, в сравнении с работой с самими блоками из админки.
- зашёл в элемент - сохранил на русском
- переключил язык на En - сохранил - в таблице mm_hl_lang_selector появилась запись, но сбросился чекбокс.
- сохраняю повторно без правок - сбрасываются SITE_ID и LANGUAGE_ID в таблице базы
- сохраняю повторно - записывается новая запись и так до бесконечности

Вообще, зачем добавлять в таблицу SITE_ID когда привязка идёт к языку, это лишнее значение.

4. Не корректно работает обработка мультиполей. При сохранении вызывет ошибку https://72seo.ru/s/2024-01-24_130240.jpg

На данный момент работать с HL Блоками невозможно!
Очень хотелось бы чтобы доработали их в ближайшее время.

Прикладываю Видео по ошибкам https://youtu.be/NcbdbxpsxPQ

==========================

P.S. Поскольку документации нет совершенно по HL Блокам поэтому напишу сюда вызовы, вдруг кому пригодится

$hlblock = Modulemarket\Translator\Highloadblock\HighloadBlockTable::getById($hlblock_id)->fetch();
$entity = \Modulemarket\Translator\Highloadblock\HighLoadBlockTable::compileEntity($hlblock);
$entity_data_class = $entity->getDataClass();
$arRes = $entity_data_class::getList([
'order' => ['UF_SORT' => 'ASC'],
   'filter' => $arFilter,
])->fetchAll();

Также можно запустить переименование ключей, UF_UF_ на UF_
\Modulemarket\Translator\Highloadblock\HighLoadBlockTable::RenameRowKeys($arRes);
Только нужно саму функцию переписать

В файле /bitrix/modules/modulemarket.translator/lib/highloadblock/highloadblocktable.php функция RenameRowKeys
Заменить весь код на этот

// Замена UF_UF_ на UF_ / Кастом
       foreach ($row as &$subArray) {
           $newSubArray = array();
           foreach ($subArray as $key => $item) {
               $newKey = str_replace('UF_UF_', 'UF_', $key);
               $newSubArray[$newKey] = $item;
           }
           $subArray = $newSubArray;
       }

==========================

ОЧЕНЬ надеюсь, что функционал HL блоков получится сделать в самое ближайшее время.

"Сделать возможность перевода полей форм модуля Веб формы"

Сейчас есть куча форм и чтобы их адаптировать под каждый язык на публичке, нужно делать копии форм под каждый язык и потом в коде в каждом сайте вручную проставлять нужный ID формы.
Это достаточно хлопотно. Собственно данный модуль и решает вопросы подобных танцев с бубном в Инфоблоках, Highload блоках, Свойствах и очень в тему добавить поддержку Веб форм.

Скрин https://72seo.ru/s/2023-12-12_163056.jpg

"Не сохраняет значения других полей, пока не заполнено для базового языка."

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

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

"Сделать автоперевод метаданных"

Считаю, будет полезно сделать автоматический перевод метаданных разделов и элементов.
С возможностью в ручном режиме, по скрипту всей базы и при создании новых элементов.
Не совсем понял почему изначально при разработке автоперевода остальных полей это не было сделано.

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

"Поля Раздела на другом языке применяется только после повторного сохранения базовой языковой версии"

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

Это дико не удобно, постоянно сохранять раздел по 2 раза и переключаться между языками, теряется время.

Всё правильно работает при работе с элементами, значит можно правильно настроить для разделов.

Если включить автоперевод, то все типы полей переводит отлично, даже мультиполя, а вот с типом HTML/текст переводить не хочет.



Это только у товаров.

Сделал обновление модуля до версии 1.2.3 и пошли баги решения.
Опытным путем выяснилось, что проблема возникает в файле /bitrix/modules/modulemarket.translator/lib/inheritedproperty/basetemplate.php

Когда файл откатываю обратно то метаданные начинают работать.
Устраните, пожалуйста, данную ошибку.

При сохранении элемента в Highload-Блоке то поле с типом файл обнуляется, т.е. загруженная ранее картинка пропадает. Новую картинку уже не добавить.
В видео продемонстрировал как это работает.
Видео
https://youtu.be/RqN_D0Qi8OE

На узбекском языке очень много слов с апострофами ' которые вызывают ошибку при сохранении любого поля метаданных: раздела или элемента.
При этом если указать слово в названии раздела или элемента то данной ошибки нет.

Пример слова do'konida
Скрин ошибки https://disk.yandex.ru/i/-EHvHRk7BqD_ng

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

В модуле перевода есть файл класса обработки корзины basketclass.php
В нем перевод уходит в массив с наименованием $result["BASKET_ITEM_RENDER_DATA"], данный массив используется исключительно в обычном компоненте корзины в котором есть вспомогательный файл mutator.php в котором и происходит вся магия.

НО! Есть проблема в том, что при небольших компонентах работы корзины, не такие тяжеловесные как стандартные, данного файла просто нет, например в шаблоне компонента работы с плавающей корзиной https://disk.yandex.ru/i/h12_AYfigsJB2A т.е. в ней урезанные данные, которые используют обычный массив $arResult без изменений, а в него модуль как раз и не пишет данные.

Чтобы это обойти мне пришлось дописать костыли. В стандартном коде есть строчка:
if(!is_array($result["BASKET_ITEM_RENDER_DATA"])) return;

Т.е. если этого массива нет, то ни чего не переводить, я в это место и вставил кастомные строки чтобы данные всё таки переводились и уходили в шаблон компонента летающей корзины.
Чтобы данные появились в шаблоне нужно переводить массив $result["GRID"]["ROWS"], следовательно я пропустил его через модуль перевода:

foreach ($result["GRID"]["ROWS"] as &$Item) {
               if ($arRes = \FCIBlockElement::GetByID($Item["PRODUCT_ID"])->GetNextElement()) {
                   $fields = $arRes->GetFields();
                   $Item["NAME"] = $fields["~NAME"] ? $fields["~NAME"] : $fields["NAME"];
               }
           }

Получилась следующая логика - если массива $result["BASKET_ITEM_RENDER_DATA"] нет, то переводим $result["GRID"]["ROWS"],а если он есть то переводим по той логике как заложено было изначально в модуле перевода.
После чего летающая корзина перевелась.

Надеюсь, что вы доработаете модуль так, чтобы не нужно было изобретать костыли, чтобы не слетало после обновления модуля.