Понимаю а каком монстре идет речь но все же не нужно так преувеличивать :) Я так же стараюсь все разрабатывать с учетом расширяемости до проекта в 100 000 уников в день но пока те ограничения что есть в котонте не позволяют его использовать на таких проектах потому смею утверждать не стоит так боятся за монстра.

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

Дальше на счет кучи полей, обычно сайт не делают больше 3-5 языков (больше то точно не сфера применения котонти там  уже индивидуальные разработки со своим блек джеком и кошками)  а вот для минимализации сделать обычный табы как я уже писал у многих ЦМС уже много лет и все там хорошо никто не путается и не боится переключит таб, думаю опасания напрасны так еще и тормозят развитие.

«640кб хватит всем» ©
Это я о том, что фраза «обычно сайт не делают больше 3-5 языков» сродни «обычно сайты содержат не более пары десятков страниц».
Дело не в том, что разработчики хотят сделать супер-комбайн, а в том, что надо смотреть на шаг вперед, точнее на шаг вокруг. Иначе, чуть что, придется опять переделывать.
Если речь идет о плагине, который решает одну узкую задачу, такой подход еще допустим. Но если речь идет о глобальном механизме, коим мультиязычность является, приходится «думать 2 раза» и заранее.  :)

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

На счет 7 пункта про избыточность - тогда сделать как сейчас в отдельной таблице - просто все запросы пропускать через 1 общу функцию для локализации не думаю что сильно потеряем в производительности (если не навешаете кучу ООП то все будет ок в функциональном програмировании есть запас быстроты не плохой)

Да, пока видится этот вариант.

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

Конструктивный диалог всегда полезен.

Дальше на счет кучи полей, обычно сайт не делают больше 3-5 языков (больше то точно не сфера применения котонти там  уже индивидуальные разработки со своим блек джеком и кошками)  а вот для минимализации сделать обычный табы как я уже писал у многих ЦМС уже много лет и все там хорошо никто не путается и не боится переключит таб, думаю опасания напрасны так еще и тормозят развитие.

На счет 7 пункта про избыточность - тогда сделать как сейчас в отдельной таблице - просто все запросы пропускать через 1 общу функцию для локализации не думаю что сильно потеряем в производительности (если не навешаете кучу ООП то все будет ок в функциональном програмировании есть запас быстроты не плохой)

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

То, что локализованные данные должны быть доступны в шаблонах однообразно и в единых переменных это идея правильная. 
Но на счет идеи отображать все поля для каждого языка — тут очень много узких мест. Вот только несколько из них:

1. Движок создавался с прицелом на гибкость и универсальность. Представим у нас портал (или скажем так энциклопедия/сборник документации) где языком не 2-3, а пара десятков. Тогда мы получаем вродебы из логичной идеи «монстра о восьми головах» и со списком полей на 5 листов.
2. Текущий механизм «ручного» написания шаблонов накладывает жесткие ограничения на возможность расширения количества полей. А если мы пытаемся обойти этот момент программной генерацией (на подобие экстраполей) — мы теряем возможность простого их контроля из шаблона (т.к. там их в реальности нет).
3. Вывод всех полей всем редакторам контента — геометрически повышает шанс запороть контент (кто-то полез править перевод, и случайно стер или изменил другое поле и привет-пока, концов не найдешь). Вариант который реализован сейчас более правильный — автор перевода имеет доступ только к переводу и источник на редактирование для него не доступен (по умолчанию). 
4. Опять же есть логика первоисточник-перевод. Если весь фарш сразу на экране, да еще с конентом работают несколько редакторов (пример документация тут на сайте), то отследить соответствие одного другому будет очень сложно. 
5. В случае, если у нас заметки длиннее пары строк, вариант 2-х колоночного отображения более удобен для перевода материала (не надо листать вверх-вниз постоянно ища в тексте нужную строку).
6. Не имея главного языка (или, скажем, как-то обозначенной версии, которая считается источником материала) мы попадаем в логическую ловушку, когда не можем выводить материалы списком и правильно сортировать их.
7. Добавляя поле (колонку) для каждого поля на каждом языке, мы получаем:
   • огромную избыточность, т.к. большая часть ячеек не будут заняты никогда
   • растущие тормоза, т.к. надо будет извлекать строки данных целиком и из нее делать выборки
   • сложность/невозможность строить универсальные запросы к БД

Именно поэтому, сейчас нет универсального решения «сверху». А изменение «снизу», ведет к необходимости сильно пересмотреть и проработать сам механизм. Начиная от задач и сценариев использования i18n, удобства UI и заканчивая способом хранения данных в БД, гибким API для плагинов, учетом перспектив испоьлзования не только «языков» (с «тупой» привязкой к странам), но и локалей. 

Вот к примеру у меня сайт на 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" или заменять) то в основной механизм доставать нужный пул контента в те же переменные - так на мой взгляд будет какойто стандрат работы и в любом месте будут использоваться одинаковые переменные но с разным содержанием для каждой локали, я думаю в каждом модуле / плагине добавить такой функционал для работы будет не сложно - тем более он будет примерно одинаковый для всех и скопипастить не составит труда и заменить на свои значения

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

Ожидаю оживления :) Всем спасибо!

Да, i18n не идеален, но решает многие задачи для простого мультиязычного сайта. Его проблема в том, что он не предоставляет единого АПИ для сторонних плагинов, а решает большую часть задач путем костылей-обработчиков под каждый из основных плагинов. И да, polls, в этот набор не входит. 
Отсутствие единого механизма это узкое место, о котором разработчики «трут» давно. В планах переработка есть, но по срокам, увы, пока сказать не возьмусь — реальная разработка движется очень медленно (думаю вы и сами в курсе).

Кроме того, сам по себе, плагин Polls тоже в списке на обновление. Правда, примерно с той же степенью неопределенности по срокам. 

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

Если есть желание и возможность дописать (или хотя бы попробовать) кусок кода для интернационализации Polls — будем только рады.

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

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

Как то так =)

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

Ведем беседу и уточняем :)

Мда, совсем не хороший метод, в моем понимании и думаю большинства

Ну так я особо вообще не насылаюсь, работайте в Open-cart, вместо товара выводите вашу стаью на нужнном языке. А так и тут среди плагинов в коробке имеется соответствующий неплохой плагин.

Вначале спросят, а потом еще и плюнут.

Что-то подобное есть в админке Open-cart

А так что-то мудтрить потом через месяц забыть логику, добавить новую страницу и все сломать ))

Еще несколько раз перечитаю попробую на деле, может не все так плохо)

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

Все совершенствуется. но как всегда под себя.

С недавних пор решил забивать на все CMS в пользу Cotonti, легко работать и расширять, одна любов  в общем:) Но тут вот предстоит проект не то магазин-каталог не то промо не то блог и на 3 языках. Посмотрел как обстоят дела с мультиязычностью - огорчился, ибо прийдется делать все немного правильно а немного через сраку "костыли" или я чего-то не знаю? Посерфил форум в поисках ответа по реализации мультиязычности - темы от 2009-2012 года и половина потерты уже, посмотрел на Github - есть кажется задачка похожая   но как то срок ее добавления и дата сегодня не спешит радовать :( Неужели мне прийдется отказаться от так любимого кота только из-за отсутствия мультиязычности? Может есть решение у кого-то?

Что скажет локомотив разработчиков, есть может что в планах (видел в сообщении о выходе 0915 Поддержка контента на разных языках будет улучшаться как в движке, так и на этом сайте. или это уже до версии 1.0.0) ?

Как же популяризировать и втягивать разработчиков в движуху кота ?)

Спасибо за ответы