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