Модуль масового перекладу товарів Lingva - безкоштовна альтернатива Google Translate API

[drOC]

Вітаю, шановна спільното!

 

Хочу представити вам попередній реліз модулю з відкритим кодом для автоматизованого перекладу контенту для OpenCart.

 

Розширення працює в обхід стандартного API Google Translate, використовуючи незалежні та децентралізовані шлюзи проекту з відкритим кодом Lingva, які можна знайти у розділі Instances. Тим не менше, по результату, це ідентичні дані перекладача Google, але за посередництва незалежних провайдерів, які виконують роль шлюзу / проксі.

 

Оскільки наразі актуальним є переклад сайтів українською мовою, в той час як більшість постачальників все ще надає контент російською мовою, я вирішив зробити це розширення безкоштовним. Безкоштовним також є і сам доступ до шлюзів Lingva, проте кожен з них може застосовувати власні правила та квоти на кількість запитів. Тому перед використанням, ознайомтесь з умовами.

 

Модуль в процесі тестування, реалізований для OpenCart v4 та PHP8

Наразі підтримується переклад товарів, зокрема заголовків та описів. Інші поля ми генеруємо алгоритмічно, тому не бачу сенсу перевантажувати шлюзи зайвими запитами.

З метою обходу обмежень на кількість символів в запиті GET, реалізований по-строковий переклад полів товару description, який розділяється тегами нової строки та потім об'єднується і зберігається в базу даних. Це дозволяє перекладати довгі тексти, які закодовані з кирилиці шляхом urlencode, при цьому не порушуючи семантику речення.

 

При виникненні помилок, переклад товару ігнорується та записується в журнал, шлях до якого можна побачити в інтерфейсі модуля, вкладка "Інформація".

 

На даний момент, модуль працює задовільно перекладена база із ~1000 товарів, утім, поки що не публікую його в каталозі та не наводжу технічні подробиці, оскільки поточний реліз орієнтований на розробників, будьте ласкаві долучатися до критики, тестування та розробки!

 

Ліцензія MIT.

 

Проект на GitHub

 

[chukcha]

Увы это не альтернатива
Для простых текстов может быть,
можно использовать как  альтернативу  для перевода одно строчных (name, title), но не для описаний (description) c html форматированием

$string = urlencode(str_replace('/', '|', strip_tags(preg_replace('#<br\s*/?>#i', "\n", $string))));

и не больших текстов

explode('%0A', $string)

А если там под 100 абзацев?

[drOC]

Цитата

можно использовать как  альтернативу  для перевода одно строчных (name, title), но не для описаний (description) c html форматированием

 

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

возможно, в последствии будет доработано.

 

Цитата

str_replace('/', '|'

 

здесь возможно баг на стороне api lingva - в закодированном состоянии urlencode слеши интерпретируются как часть роутинга :/

 

Цитата

explode('%0A', $string)

 

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

 

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

 

собственно ответ, если 100 абзацев, то произойдет срез строки на 100 запросов и в последующем - склейка в результирующий запрос вставки.

также происходит проверка длины строки (абзаца), если она пуста, то запрос на перевод игнорируется.

если хотя бы одна часть выдаст ошибку по API, товар не переводится и событие добавляется в журнал со статусом error (например квота запросов исчерпана или любая другая ошибка). то есть имеется проверка на целостность строки.

 

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

проброс ведь все равно происходит к Google API, нужно просто сделать решение более универсальным или же допилить под свои нужды.

[drOC]

наверное, следует убрать strip_tags и nl2br, это было сделано до того, как понял, что слеши интерпретируются как роутинг (что вызывало ошибку 404 в ответе API). то есть сейчас в этой конвертации уже нет смысла, ведь теги обрабатываются корректно. а заменять только слеш на малоиспользуемый макрос | и обратно.

 

таким образом можно сохранить поддержку разметки.

 

спасибо за ваше замечание!

[chukcha]

Я не смотрел код lingvы но мне кажется они используют свой ИИ без ГуглАпи.По крайней мере с год назад такое было, потому как не каждый сервер апи поддерживал украинский.

[chukcha]

все же googleTranslate (free)
имитация браузера - отправка запроса на перевод
дальше уже перестало быть интересным, обходят ли квоту на 5к символов и частоту запроса

 scrapes through Google Translate and retrieves the translation without directly accessing any Google-related service,

 

 

[chukcha]

И..

в 4-ке есть раздел other
Перенесите в него "модуль"
С точки зрения модуля для OC4 - Это то что можно подключить через  layout
А у вас по сути - Утилита.
или же в раздел Language

[Baco]

ідея хороша, та на практиці перекладачів, поки не буде грамотно сформованого ШІ з перекладами, ми не зможемо отримати корректного перекладу великих текстів.

Цитата

I see nothing ->RU->я ничего не вижу->UA->я нічого не бачу->EN->I can not see anything

тобто імовірність, що "пошуковий ключ" буде корректно переведеним у контексті опису товару відповідно до релевантності, досить висока, проте...

[chukcha]

27.08.2022 в 14:48, Baco сказал:

ідея хороша, та на практиці перекладачів, поки не буде грамотно сформованого ШІ з перекладами, ми не зможемо отримати корректного перекладу великих текстів.

тобто імовірність, що "пошуковий ключ" буде корректно переведеним у контексті опису товару відповідно до релевантності, досить висока, проте...

Це не э завдання для автоперекладача.
Зменшити ручну  працю по перекладу, та форматування текстів. Наприклад - таблиці або списки.

Та обов'язкове вичитування - іноді таке видасть, що не знаєш що з цим робити.

Коли в тебе пару сотен сторінок (ок, пару тисяч) то тут немає питань
а коли за декілька десятків тисяч - ось тут є.. чималі.
Я знаю декількох, які більш 50 000 товарів перекладали, та вичитували. То було  десь роки за два. Як закон прийняли.
 

[chukcha]

вот еще
1. при отправке запроса используйте  urlencode

2. Проверяйте длину переводимого текста. Вы отправляете GET
Могу ошибаться, но помнится длина GET-запроса лимитирована 2к символа

[drOC]

Усім дякую за відповіді!

 

1. дані кодуються urlencode

2. довгі тексти діляться на частини по тегу переносу строки

 

оскільки підтримка тегів є пріоритетним завданням, думаю зробити це шляхом ділення не по <br/>, а взагалі по-тегово.

 

тобто якщо параграф <p> - передаватиметься контент параграфу <p>

якщо посилання <a> - передаватиметься вміст цього тегу.

 

для цього потрібно реалізувати парсер, таким чином, щоб передавати короткі семантичні проміжки тексту до API та потім об'єднувати їх знову в одне ціле

в той же час, важливо не виривати текст із контексту, для більш правильної інтерпретації перекладачем. якщо з <br/> семантика речення гарантована 100% то на рахунок перекладу окремих фраз в посиланнях, наприклад, я не впевнений.

 

також метою є мінімізація запитів API, навіть якщо ми маємо чималий список провайдерів, все одно, квоти є критичним моментом.