| CrazyFreeMan |
|
|---|---|
|
Вечер добрый, хочу немного полемики добавить на форуме. С недавних пор решил забивать на все CMS в пользу Cotonti, легко работать и расширять, одна любов в общем:) Но тут вот предстоит проект не то магазин-каталог не то промо не то блог и на 3 языках. Посмотрел как обстоят дела с мультиязычностью - огорчился, ибо прийдется делать все немного правильно а немного через Что скажет локомотив разработчиков, есть может что в планах (видел в сообщении о выходе 0915 Поддержка контента на разных языках будет улучшаться как в движке, так и на этом сайте. или это уже до версии 1.0.0) ? Как же популяризировать и втягивать разработчиков в движуху кота ?) Спасибо за ответы |
|
| This post was edited by Ярослав Романенко (2015-03-17 20:30, 9 years ago) |
| Sergey |
|
|---|---|
|
английский ihttp://www.cotonti.mobi/page.php?al=example_nefertiti/en русский http://www.cotonti.mobi/page.php?al=example_nefertiti и не только языки, технология http://www.cotonti.mobi/page.php?al=Mobile_web_Slots Все совершенствуется. но как всегда под себя.
www.cotonti.mobi
|
| CrazyFreeMan |
|
|---|---|
|
Мда, совсем не хороший метод, в моем понимании и думаю большинства - установить модуль/плагин и у меня появляется еще вкладки при добавлении статьи с разными заголовками EN/RU/UA ..... Что-то подобное есть в админке Open-cart А так что-то мудтрить потом через месяц забыть логику, добавить новую страницу и все сломать )) Еще несколько раз перечитаю попробую на деле, может не все так плохо) |
| Sergey |
|
|---|---|
#40709 Ярослав Романенко: Ну так я особо вообще не насылаюсь, работайте в Open-cart, вместо товара выводите вашу стаью на нужнном языке. А так и тут среди плагинов в коробке имеется соответствующий неплохой плагин. Вначале спросят, а потом еще и плюнут. www.cotonti.mobi
|
| CrazyFreeMan |
|
|---|---|
|
Та при чем тут плюнул и опенкарт? Читайте внимательно! Я писал про визуальный метод реализации что в той системе очень удобно для примера. Я не товар выводить хочу а вообще весь контент и сайт То что в коробке кажется не дает полную мультиязычность (ну или я пока не разобрался как работать с статьями, категориями) Ведем беседу и уточняем :) |
| kushelbek |
|
|---|---|
|
можно для модуль новостей допилить, а именно: при создание новости будет n дополнительных полей для записи новостей, где n=число языков. То есть, человек будет сразу писать новость на n языках, а отображаться новсти будут от того языка который стоит у поситителя. Как то так =) |
| CrazyFreeMan |
|
|---|---|
|
Разобрался с мультиленгами, не так хорошо как хотелось но работает. На основные плагины и модули работает i18n а что про модуль Polls забыли?) очень нужно а функционала нет, и языковыми строками не выкрутится, будет решено или там есть нюансы?
|
| Macik |
|
|---|---|
|
Раз тема поднята, отвечу здесь. Да, i18n не идеален, но решает многие задачи для простого мультиязычного сайта. Его проблема в том, что он не предоставляет единого АПИ для сторонних плагинов, а решает большую часть задач путем костылей-обработчиков под каждый из основных плагинов. И да, polls, в этот набор не входит. Кроме того, сам по себе, плагин Polls тоже в списке на обновление. Правда, примерно с той же степенью неопределенности по срокам. Рад, что ты разобрался в целом с i18n. Приход новых людей на платформу, которые стараются разобраться в движке, мотивирует. Если есть желание и возможность дописать (или хотя бы попробовать) кусок кода для интернационализации Polls — будем только рады.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
| CrazyFreeMan |
|
|---|---|
|
Рано обрадоваля я мультиленгу. Он работает только на страницах модулей. Очень кривое решение. Вот к примеру у меня сайт на 2 языках, и я хочу выводить название категорий структуры в произвольном месте что б каждый раз не писать все в файлах а использовать админку а так же сразу перевести названия для удобности, установил плагин и18н перевел названия, в меню добавляю ссылку на раздел пейдж и тайтл {PHP.cot_cat.diagnostika.title} - удобно же - изменил в админке и на сайте изменилось, но если у нас несколько языков то в переменную {PHP.cot_cat.diagnostika.title} не перезаписывается на текущую локаль и тогда нужно извращаться типа <!-- IF {PHP.i18n_locale} == 'ua' -->{PHP.i18n_structure.diagnostika.ua.title}<!-- ELSE -->{PHP.cot_cat.diagnostika.title}<!-- ENDIF --> ну это хорошо если 2 языка и то решение совсем не очень. Посмотрел на возможность интеграции с Polls есть идеи но они так же костыли. Можно отказіваться от идеи такой интернационализации. Предлагаю подумать на счет как я писал выше, сколько локалей на сайте столько и делать полей при добавлении статьи/голосовалки/других модулей. Так работает у всех ЦМС, если не заполнил то используется по умолчанию первое, примерно так - есть плагин в котором описать что есть 3 локали и который дает возможность записать текущую локаль в глобальную переменную доступную всем, в самом плагине контент которого нужно переводить, проверять если добавились локали то нужно добавить для них поля тем полям которые подлежат переводу, типа по умолчанию есть поле title,text,data,id ( в модуле записано что для перевода нужны только title,text) - добавляем локаль - и в самом модуле записан маханизм - для каждой новой локали создать в таблице доп поле по типу язык_поле получиться кроме title,text,data,id будет title,text,ru_title,ru_text,data,id и т.д. потом если на сайте пользователь сменил язык (в условие добавить значение локали "ru" или заменять) то в основной механизм доставать нужный пул контента в те же переменные - так на мой взгляд будет какойто стандрат работы и в любом месте будут использоваться одинаковые переменные но с разным содержанием для каждой локали, я думаю в каждом модуле / плагине добавить такой функционал для работы будет не сложно - тем более он будет примерно одинаковый для всех и скопипастить не составит труда и заменить на свои значения Писал на коленке как вариант решения, может не все точно и правильно, нужно подумать - может уже были другие версии, опишите их и почему они не подходят, я пока не знаю всех тонкостей работы ядра кота и его ограничений но очень хочется довести до ума этот раздел фремворка Ожидаю оживления :) Всем спасибо!
|
|
| This post was edited by Ярослав Романенко (2015-10-17 19:33, 9 years ago) |
| Macik |
|
|---|---|
|
На счет первого абзаца — сейчас не прокомментирую, т.к. на память не помню. То, что локализованные данные должны быть доступны в шаблонах однообразно и в единых переменных это идея правильная.
Именно поэтому, сейчас нет универсального решения «сверху». А изменение «снизу», ведет к необходимости сильно пересмотреть и проработать сам механизм. Начиная от задач и сценариев использования i18n, удобства UI и заканчивая способом хранения данных в БД, гибким API для плагинов, учетом перспектив испоьлзования не только «языков» (с «тупой» привязкой к странам), но и локалей.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
| CrazyFreeMan |
|
|---|---|
|
Понимаю а каком монстре идет речь но все же не нужно так преувеличивать :) Я так же стараюсь все разрабатывать с учетом расширяемости до проекта в 100 000 уников в день но пока те ограничения что есть в котонте не позволяют его использовать на таких проектах потому смею утверждать не стоит так боятся за монстра. Дальше на счет кучи полей, обычно сайт не делают больше 3-5 языков (больше то точно не сфера применения котонти там уже индивидуальные разработки со своим блек джеком и кошками) а вот для минимализации сделать обычный табы как я уже писал у многих ЦМС уже много лет и все там хорошо никто не путается и не боится переключит таб, думаю опасания напрасны так еще и тормозят развитие. На счет 7 пункта про избыточность - тогда сделать как сейчас в отдельной таблице - просто все запросы пропускать через 1 общу функцию для локализации не думаю что сильно потеряем в производительности (если не навешаете кучу ООП то все будет ок в функциональном програмировании есть запас быстроты не плохой) Я же настаиваю что б к обсуждению присоеденялись все кто имеет или идеи или опыт реализации. Вместе что-то толковое да и придумаем, а так само точно ничего не получится. |
| Macik |
|
|---|---|
#41094 Ярослав Романенко: Про ограничения на реальных проектах я бы с удовольствием послушал в отдельной теме. (Мои проекты достаточно мелкие, чтобы упереться в ограничения. А эмулировать нагрузку очень синтетический метод).
«640кб хватит всем» © Про табы, согласен, в целом вариант имеет право на жизнь. (Есть некоторое ограничение в том плане, что сейчас интерфейс правки страниц находится в клиентской части, а не админке и завязан на тему оформления. Но тут тоже есть идеи).
Да, пока видится этот вариант.
Конструктивный диалог всегда полезен. https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
