Обсуждение шаблона:Product info

Содержание

1

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

Платформы не делятся по типу интерфейса, потому что есть гибридные типа Texture, Adventureland или Spellcasting 101. По типу ввода у одного INSTEAD есть ввод с клавиатуры (метапарсер), мыши и прямой доступ к обоим, по технической части интерфейс реализован на SDL, HTML и консоли одновременно. У Ink вариантов интерпретаторов вообще не счесть, и любой может стать отдельным продуктом.

Разработчиков Инстеда слишком много, чтобы перечислять в маленьком инфобоксе. Это же относится ко всем open source программам. Указывать одного автора неверно, в том числе потому что "первой версии" продукта может и не быть. Опять же, в open source популярен "постоянный релиз", и тогда сложно определить точку отсчёта. Сводить всех контрибуторов к автору первого коммита - это неправильно.

Платформа, интерпретатор и редактор - это очень неточные типы программ. К платформе может относиться несколько программ (у одного Twine три вида компиляторов), несколько редакторов (см. INSTEAD) и несколько интерпретаторов (см. Ink). Интерпретатор может быть встроен в редактор (см. Quest или Inky). Есть ещё встраиваемые библиотеки, как Ink или Protoparser.js. Интернет-ресурс может быть отдельной платформой со своим редактором (см. Квестер). У платформы может не быть вообще ничего из этого, потому что есть ещё мобильные платформы без Интернет-сайтов. Если брать классификацию с Вики, то интерпретаторы будут прикладным ПО, сайты - веб приложениями (непонятно что, но в интернете), а всё остальное - ПО для программирования.

Снимок экрана и подпись для снимка будут увеличивать размер плашки, особенно после логотипа, поэтому, по-моему, логичнее снимки экрана давать отдельно в тексте статьи (есть даже тег галереи).

Oreolek (обсуждение) 03:45, 20 мая 2018 (UTC)

2

Это не "большое переустройство". Здесь не предполагается переделки чего-то существующего или пересмотра имеющихся иерархий категорий и прочего. Всего лишь некоторая информация, которая иначе была бы записана в неструктурированном виде по статьям, будет структурирована. Просто лучше расставлять категории платформ и указывать форматы файлов для интерпретаторов в универсальном шаблоне, чем в разнобой руками по всем статьям. Как я не считаю "большим пересмотром" процесс указывания, что под платформу X пишут на языке Y внутри статьи простым текстом, так я не считаю "большим переустройством" указывания того же, только в табличке шаблона. То, что до сих пор представление подобной информации не унифицировано, - это как раз следствие попыток обсуждать на форуме, а не просто сделать. Как это не сделай - хуже текущего состояния точно не будет.

Тип интерфейса - это один из атавизмов карточки ПО из большой Википедии. В нашем контексте, действительно, несущественно, так что будем упразднять. Тут ещё несколько таких же параметров. Пока просто накиданы все, чтобы видеть всё, что теоретически можно сказать о программных продуктах ИЛ. Когда идеи по добавлению закончатся, начнётся время идей по удалению лишнего. К снимкам экрана это тоже относится. Думаю, это вообще в контексте ИЛ малополезно, так как дизайн среды как таковой несущественен, а у многих и вообще отсутствует в принципе за неимением интерфейса разработки, а дизайн конкретных игр на одной и той же платформе может быть совершенно разным.

Большое количество контрибьютеров в open source проектах обозначается термином "сообщество". Соответственно автор/мейнтейнер INSTEAD - это Пётр Косых, разработчики - сообщество. Да, поимённо сообщество в wiki не попадёт, но это в любом случае не хуже, чем сейчас, когда также указан максимум основной автор, только в неунифицированном виде. От подобного шаблона, как минимум, польза даже просто в том, что вся ключевая информация будет в таблице в начале статьи.

Пространство значений параметра «тип», думаю, имеет смысл в итоге свести к:

«Платформа» - всё то, что и сейчас платформы на wiki (парсерность, менюшность и гибридность возможно будет удобнее указывать по-прежнему вручную).
«Интерпретатор/Проигрыватель» - случай Frotz, Glulxe, Fabularium и пр., то есть ПО, предназначенного непосредственно для воспроизведения. Здесь основной упор на информацию о поддерживаемых форматах входных данных, потому что, например, Glulxe поддерживает Glulx в Blorb, а filfre - нет. Сейчас пока не скачаешь, не узнаешь.
«Интернет-ресурс» - случай IFhub, INSTEAD Games, а также возможно ситуаций типа Квестера, у которого есть встроенный форум, то есть нечто существенно большее, чем платформа. Вполне можно комбинировать с значением «Платформа», если это оправдано.
«Вспомогательное программное обеспечение/Средство разработки» - случай различных смежных инструментов: от Imaginate до упаковщиков Blorb. Конкретные пояснения уже в свободной форме ниже шаблона или в скобках после основного значения параметра. Вещи типа Glulx наверное тоже сюда, хотя в этом отношении надо как-то пересмотреть название в сторону большей нейтральности. Возможно просто «Программное обеспечение» по сути неофициальный синоним «Прочее».

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

Nikita (обсуждение) 13:48, 20 мая 2018 (UTC)

3

А зачем параметр «состояние», если он обновляется вручную? Читатель сам может понять, когда проект жив, а когда - нет, по дате релиза.

В РИЛ активность - это очень размытое понятие, новых версий QSP Classic и URQ-модуля INSTEAD не было уже 8 лет (при этом у QSP хотя бы с тех пор были новые коммиты). FireURQ два года Файл:Fireurq.zip То есть, может подняться война правок только за то, стоит ли считать QSP архивным.

Наконец, статьи имеют обыкновение устаревать.
Oreolek (обсуждение) 14:57, 12 июня 2018 (UTC)

4

Основная мысль была в том, чтобы пометить как архивные проекты типа первого ТОМа и пр., то есть официально свёрнутые, на поддержку и обновление которых надежды нет. Активность проекта - это уже просто по инерции противоположное значение. Считаете особого смысла нет? Там ещё предполагается по значению "Архивное" проставлять категорию заброшенных платформ - удобнее всё в одном месте описать, чтобы категоризация делалась чисто автоматически.

Можно значение "Активное" просто особо не использовать, если смущает, а только "Архивное" в очевидных случаях. У нас сейчас есть категория заброшенных платформ, наполняемая вручную, и конфликтов это особых не вызывает, так что с проблемой холеваров по данной теме мы не сталкиваемся. Думаю, справимся и с архивным состоянием продуктов.

Вообще же меня сейчас больше занимают следующие вопросы:

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

--Nikita (обсуждение) 15:43, 12 июня 2018 (UTC)

5

Не знаю, но я всегда за простоту. Тем более для редакторов. На статистику по играм, детализированную по языкам, платформам, жанрам и датам, всегда есть запрос. Статистику по инструментам конкретно РИЛ и на конкретном языке, да ещё активных в определённый год… пока никто не запрашивал. Парсер у вики действительно ужас, но у нас есть расширения на массивы, переменные и циклы, так что всё легче.
Oreolek (обсуждение) 06:33, 13 июня 2018 (UTC)

6

Мне в нескольких случаях нужна проверка вхождения подстроки в значение параметра. Например, если параметр "система" содержит подстроку "web", то вставляем категорию "Онлайн-платформы". Именно проверка вхождения подстроки, а не просто сравнение значений через #ifeq, потому что у "система" значение может быть разным, например, помимо "web" там ещё может быть много чего написано у платформ типа Inform или INSTEAD.

Обычно для этого используются шаблоны обработки строк и в частности Str find, но у нас тут его вроде нет. Что есть на замену для этой задачи?

По языку интерфейса я наверное уберу рекомендацию по прописыванию его свойством. Будет просто параметр для произвольной строки, если вдруг для какого-то продукта там требуются общие уточнения, например, как у HTML TADS существует русификация, но как отдельная версия.

Даты релизов наверное всё-таки имеет смысл сделать датами, чтобы, например, отслеживать "этот день в истории" и ловить дни рождения платформ. Игры всё равно в отдельных календарных категориях, так что им это не должно сильно помешать.

Параметр "состояние" как раз добавит простаты с автовставкой категории заброшенных платформ. Ну а его значение "Активное" наверное да, просто не надо особо педалировать.--Nikita (обсуждение) 14:30, 13 июня 2018 (UTC)

7

В синтаксисе MediaWiki ничего нет. Существует модуль String для расширения Lua, чтобы использовать Lua-код в шаблонах, но если их поставить, то это ещё сильнее увеличит нагрузку на сервер, а заодно ещё может нарушить безопасность, так что обходимся без подстрок. Oreolek (обсуждение) 15:19, 13 июня 2018 (UTC)

Условия использования

Немного не понял про условия использования (см. IFHub):

Некоммерческий открытый для чтения ресурс с необходимостью регистрации для комментирования и публикации

Абсолютно бесполезное предложение. Что такое коммерческий веб-ресурс и где они в РИЛ? Может ли ресурс быть закрытым для чтения? (Это тогда уже не информационный ресурс, а закрытая группа, как тот же чат в Discord) Анонимное комментирование было только на CremDB, и там закрыли. Анонимная "публикация" есть только на Википедии и разделе /ruvn Двача. Правила ресурсов могут быть краткими или жутко подробными, и обобщать их не пытается даже Википедия. Что означает этот параметр?
Oreolek (обсуждение) 02:31, 15 июня 2018 (UTC)

Re: Условия использования

Ну да, у IFHub я криво как-то написал.

Вообще это то, что в карточке сайтов на Википедии называется "Регистрация", например, см. Хабр или Портал государственных услуг. Просто я вместо "Регистрация" написал более нейтрально "Условия использования", но суть именно как у "Регистрации". В принципе, можно так и написать "Регистрация", если это со стороны кажется более понятным.

Использовать, конечно, не обязательно, но раз уж есть параметр, оставшийся от EULA программных продуктов, то можно и заполнить. Надо только, действительно, над формулировками больше задумываться.

Вообще с Product info я уже наверное закончил. Вроде есть всё, что я планировал, и оно работает так, как надо, плюс способно масштабироваться, например, переварит появление любой новой категории продуктов. В общем если имеются какие-то соображения, то высказывайте. Самое время их обработать.

Есть ещё задача по шаблону "Проекты и разработки" для вставки на страницу персоналии, который будет как "Игры автора" строить списки по свойствам "Разработчик", "Локализатор", "Администратор" и "Технический писатель", но это уже отдельная сущность.

С автопостроением списков по свойству я глянул, там опять какой-то безумный синтаксис, так что мне было лень ковыряться. Если есть время и желание, ну и вы с ходу помните, как это работает, то можете помочь, запилив аналог "Игры автора". Ну или я потом найду время разобраться и доделаю, чтобы можно было отображать ассоциированные проекты на страницах людей. --Nikita (обсуждение) 12:15, 15 июня 2018 (UTC)