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

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

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

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

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

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

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

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

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

Меню


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

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

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


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

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


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


Вид в списке


Вид в записи


Демо снаружи можно глянуть тут http://a92200rg.bget.ru/articles. Хостинг халявный, поэтому может "подтормаживать"
#3 6 мая 2016 в 12:22
Намного круче моего компонента)

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

Loadырь
Думаю многим пригодиться, в вашем компоненте всё просто и понятно, любой новичок сразу разберется...
Надеюсь когда нибудь появиться в релизе)
#4 6 мая 2016 в 12:54

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

Loadырь

Конечно!
#5 6 мая 2016 в 13:05

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

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

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

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

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

Val
Я много чего хотел "пропихнуть" в релиз, но Fuze со словами (в переводе с нецензурного), типа — "не надо", давал понять, что это действительно не получится.
#7 6 мая 2016 в 13:29
Loadырь, я потому и спросил, что не видел еще ни одной сторонней разработки в коробке второго instant'a!
С другой стороны, кому действительно нужен тот или иной компонент может легко и просто установить его и использовать, тем самым исключается острая необходимость "тащить все" в коробку. Получается такая своеобразная модульность! А модульность это гибко и круто)) При этом Fuze всегда идет на встречу для создания наилучших условий для поддержания и развития этой модульности (пример постоянное добавление новых хуков).
#8 6 мая 2016 в 13:36

не видел еще

Val
Всё когда-то случается впервые smile
#9 6 мая 2016 в 13:42
Мультиязычность — отличное расширение Двойки. Тем более в исполнении такого тщательного программиста, как Loadырь.
Но вот насчёт надобности её "в коробке" у меня есть сомнения. Скорее соглашусь с Val в том плане, что лучше сделать мультиязычность отдельным компонентом, а в движке предусмотреть всё необходимое для этого, чтобы в дальнейшем обойтись без правок системных файлов.
#10 6 мая 2016 в 15:10

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

Loadырь
Пожалуйста, не приписывайте мне того, чего я не говорил.
По сабжу — хуки нужные добавим при первой возможности. Весь функционал в релиз — тут нужно коллегиально думать.
#11 6 мая 2016 в 15:25
Продолжать двигаться однозначно нужно.
В релизе нет. Возможность выбора это всегда хорошо. Да и не нужно стремиться всё в коробку внедрять и так много "вкусного подается на блюдце".
Отсутствие мультиязычности это самое слабое место у Инстанта… было)
#12 6 мая 2016 в 15:51
Пусть даже не в коробку, но хотелось бы компонент, без изменения системных файлов
#13 6 мая 2016 в 16:08

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

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

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

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

В релизе нет.

Ne OS

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

WebMan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кому ещё это не надо? Не стесняйтесь popcorn
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.