Пользовательская экспертиза компонента Translate

Как я понял, чтобы стороннее дополнение вошло в очередной релиз, оно должно пройти "огонь, воду и ржавые трубы". Переродиться, обновиться и только потом прикрепиться к основным файлам движка. При условии, что большинству пользователей это интересно.
Evanescence, уже положил начало своим компонентом "Компонент мультиязычность". Но мне его работа не подошла, для одного проекта. Поэтому я "стырнетил" у него испанскую локализацию, у Boanro прибрал к рукам украинскую, добавил немного юзабилити и получилось то, что можно скачать у меня в файлах. Есть замена системных файлов, поэтому тестировать на "боевом" сайте не рекомендую.

Что он может переводить:

Пункты меню
Заголовки и ссылки виджетов
Типы контента
Категории
Типы полей с их группами
Свойства типов контента
Наборы типов контента
Все переводимые поля контента
СЕО заголовки, ключи, описания, где это доступно.

Недоработано:
Перевод групп пользователей
Перевод стандартных компонентов
Авто-перевод от яши в текстовых редакторах. Заполнение вручную работает.

В планах сделать оптимизацию, подключить к работе кэш.

Плюсы: Доступна опция авто-перевода от Яндекса. Разделение доступов по группам пользователей. Вы сами решаете какая группа какие переводы сможет вводить.

Минусы: Авто перевод от Яндекса работает только в редактируемом поле и не переводит весь контент сразу или по крону. Это своего рода стимул заполнять всё ручками носителя языка.

Немного скринов:
Админка
Список полей типа контента Статьи

Меню


Вид переводимого поля:
с не заполнеными переводами

с заполненым только UK

с выбранным языком перевода


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

В общем, к чему всё это:
нужно ли продолжать в этом направлении двигаться?
может что-то, где-то изменить для лучшей работы с несколькими языками на сайте?
либо это вообще никому не надо и можно оставить всё как есть сейчас и не стремиться попасть в очередной релиз? Нужно ли это в релизе?

Категория с сео


Вид переводимого текстового редактора зависит от текстового редактора


Вид в списке


Вид в записи


Демо снаружи можно глянуть тут http://a92200rg.bget.ru/articles. Хостинг халявный, поэтому может "подтормаживать"

Намного круче моего компонента)

нужно ли продолжать в этом направлении двигаться?

Думаю многим пригодиться, в вашем компоненте всё просто и понятно, любой новичок сразу разберется...
Надеюсь когда нибудь появиться в релизе)

нужно ли продолжать в этом направлении двигаться?

Конечно!

Как я понял, чтобы стороннее дополнение вошло в очередной релиз, оно должно пройти "огонь, воду и ржавые трубы"

А уже были прецеденты? =)

Как обсуждалось уже в разработке Evanescence для разных языков нужны разные url с указанием текущего языка, например
sitename.com/ru/article_name.html

И еще вопрос к сообществу: зачем? Где возникает потребность в таких (мультиязычных) сайтах в рамках основной концепции iCMS? И есть ли пример такого сайта на первой ветке чтобы познакомиться в реальных условиях такого чуда?

А уже были прецеденты? =)

Я много чего хотел "пропихнуть" в релиз, но Fuze со словами (в переводе с нецензурного), типа — "не надо", давал понять, что это действительно не получится.

Loadырь, я потому и спросил, что не видел еще ни одной сторонней разработки в коробке второго instant'a!
С другой стороны, кому действительно нужен тот или иной компонент может легко и просто установить его и использовать, тем самым исключается острая необходимость "тащить все" в коробку. Получается такая своеобразная модульность! А модульность это гибко и круто)) При этом Fuze всегда идет на встречу для создания наилучших условий для поддержания и развития этой модульности (пример постоянное добавление новых хуков).

не видел еще

Всё когда-то случается впервые

Мультиязычность — отличное расширение Двойки. Тем более в исполнении такого тщательного программиста, как Loadырь.
Но вот насчёт надобности её "в коробке" у меня есть сомнения. Скорее соглашусь с Val в том плане, что лучше сделать мультиязычность отдельным компонентом, а в движке предусмотреть всё необходимое для этого, чтобы в дальнейшем обойтись без правок системных файлов.

но Fuze со словами (в переводе с нецензурного), типа — "не надо"

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

Продолжать двигаться однозначно нужно.
В релизе нет. Возможность выбора это всегда хорошо. Да и не нужно стремиться всё в коробку внедрять и так много "вкусного подается на блюдце".
Отсутствие мультиязычности это самое слабое место у Инстанта… было)

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

не приписывайте мне того, чего я не говорил

Значит наш "посредник" добавлял ещё и свои мысли…

Где возникает потребность в таких (мультиязычных) сайтах в рамках основной концепции iCMS?

Вот и у меня пока только на одном проекте, связанном с наукой возникла необходимость делать переводы контента для иностранного контингента. С одной стороны этот компонент не совсем делает сайт мультиязычным. Так как не получится на одном сайте вести разный контент для разных иностранцев. Но он позволит иностранцам читать информацию на вашем сайте и перемещаться по нему без особого дискомфорта.

В релизе нет.

насчёт надобности её "в коробке" у меня есть сомнения

Отсутствие мультиязычности это самое слабое место у Инстанта...

Что касается "коробки". То тут палка о двух концах. С одной стороны, функционал полезный (не путайте с необходимым), с другой стороны всё, что не в коробке, теряет тех. поддержку со временем. Превращаясь в неработоспособное собрание букв и цифр. Вот и надо определить, настолько ли он полезный, чтобы быть в релизе или может, что-то поменять/добавить в функционале.

хуки нужные добавим

Спасибо. Это пожалуй основная задача этой темы.

Для меня достаточно иметь указанные хуки в движке, чтобы спокойно проводить обновления сайта. Но нужно ли такое вам, пользователи instantcms 2?

с другой стороны всё, что не в коробке, теряет тех. поддержку со временем. Превращаясь в неработоспособное собрание букв и цифр.

Это напрямую зависит от разработчик этого дополнения. Если он захочет своевременно обновлять (поправлять) код то и компонент будет всегда совместим. Когда мы говорим что в коробке компонент будет всегда актуален — то мы перекладываем работу по обновлению (поддержанию) кода компонента на разработчиков InstantCMS — они будут при подготовке очередного релиза проверять работоспособность компонента и вносить необходимые правки чтобы релиз был)), а это, в свою очередь, будет тормозить развитие системы в целом.

Но нужно ли такое вам, пользователи instantcms 2?

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

Это напрямую зависит от разработчик этого дополнения.

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

мы перекладываем работу по обновлению (поддержанию) кода компонента на разработчиков InstantCMS

Вижу в этом только положительное. Никто лучше них это не сделает.

это, в свою очередь, будет тормозить развитие системы в целом

Да этот компонент задержит выход релиза на 1-2 дня, что в период 3-4 месяца, не столь существенно. Но тут же опять таки сообщество поможет протестировать релиз-кандидат. Так сказать "командная" работа, а не работа разработчика-одиночки.

Если это очень узкоспециальные хуки (только для одного компонента)

Представьте, если 95 процентов содержимого страницы можно изменить этими хуками, то насколько они универсальны?

В конце-концов есть же галочка "вкл/выкл" в списке компонентов, для тех кому это не надо.

Кому ещё это не надо? Не стесняйтесь