Реализация мультиязычности

[OAndrey]

Здравствуйте, столкнулся прямо с проблемой и на форуме уже много раз была тема такая сделать мультиязычность. По сути система это CRM в которой могут быть и товары, и различные функции для работы, вот как пример у меня построена система с товарами и учетом производства с каждыми этапами в которых работают люди с прониманием разных языков. Ну и на вскидку у меня 200 разных полей из которых примерно половина требуют мультиязычности, плюс варианты, создавать отдельно дополнительные поля под каждый язык это прям очень напряжно и банально потеряешься в них, надо индексы придумывать и т.д. Ну и карточки товаров тоже на нескольких языках для выгрузки на сайт.
Вывод: все таки мультиязычность это уже считается как стандарт в подобных системах, может стоит реализовать?

[alcompstudio]

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

Тут (я не специалист, не могу точно утверждать) может возникнуть проблема с количеством полей в БД (я с такой уже сталкивался, что при каком-то определенном наборе полей - MySQL не позволяет добавлять новые поля, они попросту не сохраняются). Если вы пишете, что у вас 200 полей и как минимум половине нужен 2-й язык, то это еще 100 полей для интерпретации системы на другом языке. А если еще + 1,2 ... N языков ? Я конечно, много не знаю, может и есть какое-то решение, но вот что сейчас вижу - это проблема в дополнительных полях (хотя и это ограничение, вроде можно обойти).

Но я тоже за мультиязычность - как системную опцию, было бы очень неплохо!

[alexinc]

Хорошее предложение. Но предлагаю начать хотя бы с введения часовых поясов для пользователей. В России 11 часовых поясов. Сейчас получается что в Красноярске назначают внутренние встречи по Мск времени, потому что в системе только одно время. Местами очень неудобно.

[nruslan2]

про часовые пояса +1! Реально нужная штука.

[Andres]

Помнится, в Opencart мультиязычность хорошо реализована:

• В админке в разделе "Локализация" добавляем языки, указывая локаль, нпример "en_gb" или "english", совпадающую с именем файла в языковой папке и код, например "en-gb"

• Указываем название языка, которое отображается пользователям

• Там же загружаем иконку (флажок)

• У пользователей появляется выбор языка (это уже есть в системе)

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



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

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

[nruslan2]

я бы если делал бы, ввел бы спец сущность в которой указывал бы вариативность под какой язык и как поле должно звучать в принципе даже не так сложно в реализации! надо подумать)) хотя часовой пояс мне более интересен и он имхо более необходим)

[Vladzimir]

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

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

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

[nruslan2]

Ну не знаю не знаю) в мозгу как правильно это сделать в рамках системы идея есть - описал кстати выше и уже убедился в ее состоятельности) напрягает что придется во многих файлах добавлять код не люблю такое надо минимально возможными средствами вписаться иначе обновление превращается в муку!
А вот часовые пояса практически готовы) (правда есть нюанс!)

[nruslan2]

Собственно часовые пояса готовы (но возможно есть нюанс!)

[OAndrey]

Ну не знаю не знаю) в мозгу как правильно это сделать в рамках системы идея есть - описал кстати выше и уже убедился в ее состоятельности) напрягает что придется во многих файлах добавлять код не люблю такое надо минимально возможными средствами вписаться иначе обновление превращается в муку!
А вот часовые пояса практически готовы) (правда есть нюанс!)

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