Отклонено

Нормальная многоязычность

Идеальный Пиксель Обновлен 3 года назад в категории CMS Общий функционал 11

Нынешняя реализация многоязычности и ее поддержка, это огромный костыль.
Менеджить два магазина, это так себе идея.
Гораздо проще, чтобы в самом товаре, можно было сразу заполнить все необходимые переводы на другие языки.

Системные переменные, было бы неплохо давать править прямо в админ панели, в отдельном разделе вывести их и оттуда формировать языковые файлы для цмс.

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

У вас хорошая платформа, но постоянно ощущение, что вы сами ей никогда не пользовались по назначению или у вас отсутствуют проектировщики ui/ux как класс.

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

Ответить 0

Поло Арт 4 года назад
У ридискрипта вполне себе нормальная многоязычность, удобная. Плюс, реализовано как на уровне ядра, так и модулей.
Править файлы намного быстрее, чем мышкой в админке править переменные

Мы реализовывали как многоязычные, так и просто перевод с русского на русский (когда не интернет-магазин делали)
- Ответить 0
  
  Идеальный Пиксель 4 года назад
  Поло Арт, а можно пример работы "нормальной многоязычности"?
  
  Повторюсь, удобная локализация, это когда в рамках одного каталога, ты можешь задать товару описание на всех необходимых языках.
  А не создание отдельного сайта с языковым файлом для каждого языка. Такой вариант, это костыль а не решение.
  - Ответить 0
    
    Поло Арт 3 года назад
    Сейчас поступил запрос на реализацию многоязычности
    Тест висит у нас на http://rs5.t50.ru/
    В качестве теста переводится название одной категории принудительно, строка поиска и строчка рядом с выбором языка
  - Ответить 0
    
    Поло Арт 3 года назад
    Чтобы товары переводились, необходимо развивать систему, написать модуль, который будет реализовывать следующее - в карточке товара при редактирование поле названия дублируется согласно количеству языков в системе, то есть, что выплёвывает функция getSystemLanguages()
    И не только название, но и описание
  - Ответить 0
    
    Поло Арт 3 года назад
    И ещё сразу встаёт вопрос по поводу индексирования.
    Чтобы разные языковые версии нормально индексировались (а не только дефолтный язык), нужно ещё дописывать ;) Например, вводить маршруты /en /de и чтоб сразу по маршруту переключалось.
    - Ответить 0
      
      Поло Арт 3 года назад
      Но мы тут подумали и решили, что лучше делать на поддоменах, которые автоматически будут включать нужный язык. Так меньше писанины.
Ответить +2

Артем Полторанин 3 года назад
В 2012 году, когда мы только проектировали архитектуру ReadyScript, вопросу мультиязычности безусловно было уделено огромное внимание. Мы проанализировали реализации всех имеющихся подходов к мультиязычности, посмотрели как это все реализовано в открытых платформах OpenCart, Prestashop, и т.д.

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

Разный язык - означает по факту торговлю в разные страны. У любой трансграничной компании обычно ассортимент для каждой страны отличается. Соответственно возникает потребность фактически для "одного языка сайта" менять различные параметры товаров, выходящие за рамки Названия, описания (видимость, доступный остаток для продажи, возможно комплектации, возможно состав характеристик). Данная потребность фактически означает, что нужно заводить абсолютно другую карточку товара. Эти требования могут не появиться сразу, но они обязательно появляются, когда предприятие начинает реальную торговлю.

На разных языковых версиях интернет-магазина очень многое как правило должно быть отображено по разному - свои пункты меню, свои новости, свои статьи. На основном сайте у вас может быть 1000 новостей, а на зарубежной версии только 100 (потому что остальные неактуальны и тратить ресурсы переводчика необязательно). Акции, которые актуальны для вашего родного региона могут быть абсолютно неактуальны при продаже в соседнюю страну.

Технически, мультиязычность контента означает, что для получения сведения по каждой сущности обязателен join в SQL запросах, так как любая сущность делится на таблицу с основными данными (независящими от языка) + дополнительная таблица с идентификатором языка и полями. На MySQL это все очень тормозит при значимых объемах данных и от этого никуда не деться.

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

К слову сказать не мы одни выбрали такое решение, довольно крупная компания на букву Б тоже выбрала этот путь.
- Ответить +1
  
  Поло Арт 3 года назад
  Артем Полторанин, я надеюсь, что в рс никто не будет против, что мы на стоковых функциях всё-таки сделаем многоязычность для фронта?
  И вот почему
  а) есть страны, где в пределах одной страны минимум два языка фигурируют. Допустим, популярный и официальный. Далеко ходить не надо - это почти все страны бывшего СССР. А уж про Европу и говорить не приходится, там с десяток стран, где 2-3 языка официальных или даже больше.
  б) если каталог един для всех языков, то, мне кажется, совершенно не удобно следить за ассортиментом, даже при условии синхронизации с торговой системой.
  
  По поводу же Б... есть В, в коробке тоже ничего нет, зато есть
  mylang.dev
  и эту возможность клиенты В ждали много лет.
  
  С остальными моментами я бы поспорил, но это вне рамок этой темы, поэтому воздержусь :)
  - Ответить 0
    
    Артем Полторанин 3 года назад
    Поло Арт, безусловно в кастомных модулях вы можете делать абсолютно все что необходимо вашим клиентам.
    
    Мы не против самого явления - мультиязычность контента. Оно имеет место быть и в каких-то случаях оно все равно применяется. Просто в ReadyScript мы архитектурно никогда не закладывали данную возможность.
    
    Думаю, что наш путь развития - это доработка инструментов для более удобных переводов файлов интернационализации мультисайтов из админки.
    - Ответить +1
      
      Поло Арт 3 года назад
      Артем Полторанин, это радует
      
      На самом же деле, весь функционал вы уже написали :) Выше ссылка на наш тестовый рс, с фронта всё прекрасно переключается, используется стоковый функционал
      
      По сути, к этому функционалу нужно дописать модуль, который в админке динамическим элементам (вроде названий, описаний товаров и категорий) добавляет дополнительные поля(для перевода), согласно списку языков системы - туда даже можно цепануть автоперевод, как сделано в майленге том же. Плюс, где-то эти языки необходимо добавлять визуально, а не просто файликами. И это мы напишем в ближайшее время, раз никто не против :)
  - Ответить 0
    
    Сергей Филоненко 3 года назад
    Поло Арт, да все именно так.
    Оставить на сайте только один язык это обрубить себе в половину трафик заказов.
    И вы правильно сказали что это применимо в рамках одной страны.
    
    Если же делать отдельный сайт на ЕС, то да Артем прав что организационно цены, товары будут другими и смешивать все в кучу будет не верно.
    
    Вообщем, очень здорово что можно сделать и так и так. Жду модуль!)

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