Википедия:Форум/Архив/Предложения/2018/06

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

Эта страница — часть архива форума Википедии.

Пожалуйста, не редактируйте эту страницу!
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Дополнительные поля для списков в шаблоне навигация[править код]

Предлагаю добавить в шаблон {{навигация}} несколько полей, предназначенных для ссылок на информационные списки и списки в рамках проекта, в которые добавлена данная статья. Дело в том, что списки также как и навшаблоны можно использовать для навигации между статьями, более того, когда элементов достаточно много, список был бы предпочтительнее. Однако попасть из статьи на список можно только если такая ссылка в статье есть, но такой практики в Википедии так и не сложилось. Кроме того, простая ссылка не настолько привлекает внимание, как навшаблон, или плашка, снабжённая значком. --Tucvbif???
* 18:55, 28 июня 2018 (UTC)

  • Не думаю что стоит делать комбайны, для таких списков стоит сделать может второй шаблон. С уважением, Iniquity 20:15, 28 июня 2018 (UTC)
  • Во-первых, использование списков для навигации из других элементов идея плохая — дополнительные клики. Если предметы действительно настолько связаны, что между ними должна быть адекватная и быстрая навигация, они объединяются в навигационную полосу / таблицу. Во-вторых, у нас нет ограничения по количеству списков, в которые входит предмет. Соответственно потенциально безразмерные шаблоны получаются. Ну и наконец, списки внутри проектов предназначены для координации работ, а не для навигации. Они должны быть удалены по окончанию работ. Давать на них ссылку из основного пространства вообще неправильно. Ну и наконец я бы сначала реорганизовал списки в принципе: решил вопрос с их значимостью, и, возможно, вынес в отдельное пространство. — VlSergey (трёп) 14:03, 6 июля 2018 (UTC)
      • А чем дополнительные клики отличаются от свёрнутого навшаблона? Более того, у ссылки «[показать]» очень небольшое поле клика, да и у ссылок в навшаблоне как правило размеры небольшие.
        Чем лучше безразмерный список списков по сравнению с безразмерными списками безразмерных навшаблонов?
        Есть ведь ещё один тип списка — глоссарий. Tucvbif???
        *         07:33, 9 июля 2018 (UTC)
        • Время реакции у клика по нав. шаблону и по отдельной странице различаются на порядки. По остальному: «АПОЧЕМУИММОЖНО». Нельзя. В частности, за «Награждённые Национальной медалью США в области искусств» я бы отбирал права на создание шаблонов, если бы можно было. — VlSergey (трёп) 16:29, 10 июля 2018 (UTC)
          • Пока норма не закреплена в правилах — можно. И вариант со ссылками на список — шанс снять часть возражений. Сейчас же любая попытка как-то ограничить навшаблоны натыкается на ожесточённое сопротивление. Tucvbif???
            *             09:02, 13 июля 2018 (UTC)

Убрать категории из викитекста[править код]

В настоящее время категоризация страниц происходит путём простановки конструкции [[Категория:Что-то]] прямо в исходный код страницы. у такого способа есть ряд недостатков:

  • Затруднение ссылок на категорию, например, в обсуждениях. Для этого нужно использовать неочевидную конструкцию [[:Категория:Что-то]]. Новички часто ошибаются и вместо ссылки получают сработавшую категоризацию страницы, а ещё удивляются, почему на месте ожидаемой ссылки на категорию ничего нет.
  • Частая ошибка новичков - попытка категоризации статьи путём вписывания её на страницу категории.
  • Возможные ошибки категоризации, например, рекурсивная простановка (например, см. фильтр правок №153).
  • Возможные технические ошибки. Например, категория, проставленная в шаблоне без тега noinclude, автоматически сработает во всех статяьях-включениях, а если её отбить энтером, то перенос строки тоже попадёт во все статьи.
  • Общее неудобство категоризации путём простановки такой квадратноскобочной конструкции в викитексте.

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

Моя идея заключается в том, чтобы изменить механизм категорий и полностью вынести категоризацию из исходного текста. Чтобы категории можно было добавлять с помощью отдельной строки, то есть внешне это будет похоже на существующий HotCat, но при этом в коде статьи никаких категорий не будет. Ссылка [[Категория:Что-то]] будет работать именно как ссылка. Страницы категорий не будут подлежать редактированию в виде кода, но должны иметь настройку "В каких пространствах имён разрешено", графу "Основная статья по теме", которую можно заполнить, и галочки "Метакатегория", "Скрытая категория", "Защищённая от простановки категория", "Не удалять даже пустую", "Категория только для основного пространства", которые, будучи выставленными, активируют соответствующее визуальное оформление и при необходимости технический механизм. При этом добавление статей в категорию станет возможным прямо с неё с помощью кнопки "Добавить страницу" (то есть превратить частую ошибку в работающий механизм).

При этом нужно будет изменить механизм простановки категорий шаблонами (т.е. когда от шаблона требуется внести статью в категорию и для этого в нём есть ссылка на категорию без noinclude). Например, с помощью конструкции {{#categorize|Какая-то категория}} - в этом случае всего-то потребуется выполнить ботозамену.

Дополнительный положительный эффект - упрощение социальной нагрузки. Например, из правила ВП:КАТ можно будет выпилить требование "Проставлять категории только в конце кода статей", из документации к шаблонам - требования использовать noinclude, из фильтров правок - срабатывания на ошибки категоризации, из ВП:ПАТ - раздел про патрулирование категорий. потому что сейчас технические проблемы решаются социальными методами (правилами, запретами и т.д.), что никогда не бывает эффективно. Зато социальные проблемы, например, вандализм, вполне можно будет решить техническими методами: некоторые категории защитить до сисопа от простановки, служебные категории запретить ставить в статьях и наоборот, запретить до сисопа полное удаление всех категорий из статьи, и так далее. Emo4ka ツ (обс.) 15:34, 27 июня 2018 (UTC)

  • (−) категорически против. Мне не трудно ставить категорию в конце статьи и на форуме. Не вижу никаких трудностей. То, что Вы предлагаете, реализовано не будет. Викитекст и редактирование исходного кода — это основа основ. Визуальный редактор — в текущем виде использовать невозможно. Oleg3280 (обс.) 15:42, 27 июня 2018 (UTC)
  • Статьи не добавляются в категории напрямую, а через исходный код в самой статье. Только так, а не иначе. Oleg3280 (обс.) 15:50, 27 июня 2018 (UTC)
  • Не нужно превращать ошибки новичков в норму. ВП:НДА. Oleg3280 (обс.) 15:52, 27 июня 2018 (UTC)
  • Со всеми предложениями по изменению движка лучше обращаться или на Phabricator, или продвигать их через Community Wishlist Survey (следующий будет в ноябре). На форуме в ру-вики можно максимум узнать, как много людей поддерживают предложение. Имхо, идея отделения невидимых в тексте категорий от видимого текста достаточно хорошая. Но маловероятно, что кто-то за неё возьмётся в обозримом будущем. Разве что её действительно поддержит много людей на Community Wishlist Survey. — putnik 15:56, 27 июня 2018 (UTC)
  • Кроме того, категории добавляются через исходный текст во всех проектах Фонда Викимедиа (нарушится совместимость). Это невозможно изменить (и не нужно), так как это на уровне движка MediaWiki. Oleg3280 (обс.) 16:00, 27 июня 2018 (UTC)

Итог[править код]

Ждите Community Wishlist Survey на Мете:) Локально это не решается. С уважением, Iniquity 16:15, 27 июня 2018 (UTC)

Предупреждение для новичков, создающих ЛС[править код]

Многие новички сразу после регистрации начинают писать статью на своей личной странице участника. Они это делают, даже если им в обсуждение поместить {{Hello}}, где есть все необходимые ссылки для того, чтобы начать правильно создавать статьи. Приходится вдобавок помещать им {{Нецелевая ЛС}}
Я предлагаю процесс предупреждения о нецелевом использовании личной страницы упростить и сделать так, как сделали в английском разделе — встроить в интерфейс соответствующее предупреждение (выделено розовым), которое появляется при создании новой страницы участника. --Jet Jerry (обс.) 17:12, 25 июня 2018 (UTC)

  • В этом предупреждении сказано: "Если вы создаете черновик статьи, создавайте его не здесь, а на подстранице". Участник думает: "Я создаю не черновик, я создаю статью", - и жмет на "сохранить". Так что идея-то хорошая, но формулировку надо дошлифовать. Vcohen (обс.) 18:19, 25 июня 2018 (UTC)
  • Отличная идея! Как же у нас много не сделано :( С уважением, Iniquity 19:09, 25 июня 2018 (UTC)
  • Здорово, и дать, помимо ссылки на страницу черновика, ссылку на страницу инструкции или инкубатор. Викизавр (обс.) 19:21, 25 июня 2018 (UTC)
  • О, да, мне тоже понравилась идея. Всеми лапами за.--С уважением, Стальная птица (обс.) 08:35, 26 июня 2018 (UTC)
  • Ещё стоит предупреждать (для их же пользы, чтобы не было мучительно больно) об истории правок, которую топором не вырубишь, для многих это совсем не очевидно. Первый естественный порыв — написать что-нибудь о себе, «если что, потом сотру», а потом всю жизнь сожалеют о написанном. — Mike Novikoff 02:46, 27 июня 2018 (UTC)

Аватарки для участников[править код]

Вроде обсуждали в Дискорде...

Но все же спрошу - почему бы не сделать так, чтобы зарегистрированные участники ВП могли иметь аватарки?.--Стальная птица (обс.) 12:59, 25 июня 2018 (UTC)

  • Как минимум НЕСОЦСЕТЬ. Ну и технически сложно — нужно подавать запрос на Фабрикатор, там вряд ли захотят делать. Викизавр (обс.) 13:02, 25 июня 2018 (UTC)
  • А где их показывать в ВП, кроме личных страниц? В историях статей, по аватарке на строку? Бред же. Ну и ВП блюдёт лицензионную чистоту всего своего контента, аватарки же в интернете в 99% случаев - пиратски стянутая откуда-то картинка, и ФЮ тут никак не пришьёшь. MBH 13:05, 25 июня 2018 (UTC)
    • В плане лицензии можно было бы давать выбирать из файлов под PD/CC-0 с Викисклада. Но вот показывать их реально негде. — putnik 13:08, 25 июня 2018 (UTC)
      • (ec) Разве что в popups зашить. Сейчас там показывается абы какое изображение, и отображается абы как. Скажем, навожу на вашу подпись - выскакивает зелёный пацифик метавики ... с земляным червяком и красным ножиком!. Почему из десятков ссылок на файлы отображается именно эта? пусть будет то, что сам юзер решит показывать. Retired electrician (обс.) 14:31, 25 июня 2018 (UTC)
        • Потому что это первый файл на странице, указанный явно как файл, а не завернутый в шаблон. Участник вполне может влиять на это, поставив первым самый важный для него файл. Abiyoyo (обс.) 14:40, 25 июня 2018 (UTC)
        • Хе-хе, в таком случае можно считать, что аватарки уже есть. :) ~Facenapalm 16:09, 25 июня 2018 (UTC)
  • Не нужно. Картинки в подписях вообще явно запрещены правилами. И неслучайно. Тут люди занимаются делом, картинки — лишний повод для конфликтов, разборок. Цель русской Википедии — создание энциклопедии и ничто иное. Картинки этой цели не способствуют, значит не нужны. Abiyoyo (обс.) 14:26, 25 июня 2018 (UTC)
  • Да, мне это тоже видится излишним. Только страницы загромождать. С простой подписью и то, бывает, самовыражаются так, что ух. Excellence (вклад) 15:37, 25 июня 2018 (UTC)
  • Не сказал бы, что это настолько уж лишнее, но пока не включат нормальный форумный движок, использовать их негде.--Tucvbif???
    *     15:41, 25 июня 2018 (UTC)
  • [title="Участник:Дарт Раптор"]:before {content:"👹";}
     ;-) Игорь (обс) 15:46, 25 июня 2018 (UTC)
  • У кого это там за графические смайлики сразу банят, у Лебедева или у Экслера? А уж в ВП тем более стоило бы помнить о диаметральной противоположности между LJ:КУПИТЬ_ГОЛОВАСТИКА и ВП:ДЕКОР (не говоря уже о ВП:НЕСОЦСЕТЬ). — Mike Novikoff 03:07, 27 июня 2018 (UTC)

Профиль участника вместо викистраницы[править код]

В текущем виде аватарку присобачить не к чему. При желании можно загрузить собственную фотку/произвольную картинку к себе на ЛС, следя за лицензионной чистотой (т.е. либо собственная работа, либо тривиальный значок, либо достаточно древняя картина) - это не только не запрещено, но и рекомендовано в ВП:ЛС#greenlist. Тем не менее, поднятая тема натолкнула меня на более глобальный вопрос - а что, если создать в Википедии систему профилей участников не в виде викистраниц, а в виде, типичном для других сайтов? Чтобы сведения, рекомендованные к отображению (языки и прочее из зелёного списка) можно было вписать в заранее заготовленные графы, статистика и основные сведения об участнике отображалась прямо в профиле (а не как сейчас - искать журналы, вклад и прочие сведения нужно в неочевидном месте), было место для викиорденов и юзербоксов и т.д., А всё персональное оформление сводилось максимум к цвету рамочек блоков и юзербоксам. Их, соответственно, внести в некую базу данных для централизованного выбора и добавления. У многих редакторов в ЛС есть полезные ссылки на правила, отдельные статьи и т.д. - для этого можно тоже предусмотреть место в профиле. Ну и аватарка, само собой. Emo4ka ツ (обс.) 14:51, 27 июня 2018 (UTC)

  • Это более ограниченная структура, позволяющая меньшее разнообразие личных страниц, чем нынешние личные страницы. Ну и зачем ограничивать потенциальное разнообразие? MBH 16:12, 27 июня 2018 (UTC)
  • Emo4ka ツ, инициатива наказуема — оформите свою личную страницу так, как Вы сказали, и предложите другим сделать также. Кадош (обс.) 19:19, 27 июня 2018 (UTC)
  • А зачем? Кто хочет тот свою ЛС оформит наичуднейшим образом, кто хочет тот вообще удаляет свою ЛС, а кто не хочет тот и не заводит. --P.Fiŝo☺ 19:47, 27 июня 2018 (UTC)

Заменить Указатель А — Я и Рубрикацию в левом меню[править код]

По мотивам прошлой темы. Решил немного расширить предложение, так как многих смущало, что пропадет ссылка. Предлагаю заменить «Указатель А — Я» и «Рубрикация» на «Содержание» с ссылкой на ВП:Содержание. С уважением, Iniquity 12:31, 25 июня 2018 (UTC)

  • Вполне хорошо, поддерживаю.
    Ещё, кстати, «Сообщество» и «Форум» друг друга дублируют, при этом первая страница гораздо полезнее, а ссылка на вторую в ней есть (т.е. вторую убрать из меню).
    Напомню всем, что увеличение числа ссылок не приводит к увеличению кликов, вместо этого внимание распыляется и лишние ссылки отбирают клики у более полезных. А в пределе, когда комплект хаотичен, в нём вообще не разберёшься. Лучше меньше, да лучше. — Mike Novikoff 04:30, 27 июня 2018 (UTC)
    • Не дублируют. С Форум можно сразу открыть связанные правки и также быстро перейти на запросы. Особенно с планшетов и телефонов. "ссылка на вторую в ней есть" даже хуже т.к. важна скорость навигации и путь покороче. В Сообщество куча всего, открывается медленнее и много всего прокручивать и навигация сложнее. --Sunpriat 18:43, 15 июля 2018 (UTC)
      • @Sunpriat: >С Форум можно сразу открыть связанные правки
        Этим инструментом пользуются пара редакторов.
        >В Сообщество куча всего, открывается медленнее и много всего прокручивать и навигация сложнее
        Куда прокручивать, если ссылка на форум во втором абзаце? Можно конечно ее еще сильнее выделить в шапке. С уважением, Iniquity 10:17, 18 июля 2018 (UTC)
        • Но пользуются же. Там ссылка на связанные и инструмент на 100% отрабатывают своё существование. / "втором"? А сколько прокручивать до этого "второго"? Из форума в популярные места можно попасть в два быстрых клика и страница грузится быстро (1,34с). Через сообщество нужно больше кликов, нужно прокручивать и загрузка заметно медленнее(3,29). В сайдбар бы вообще добавить ссылку на запросы - навигации и работы "сообщества" там даже больше. --Sunpriat 10:49, 18 июля 2018 (UTC)
          • >Но пользуются же. Там ссылка на связанные и инструмент на 100% отрабатывают своё существование.
            редакторы которые этим пользуются могут себе это включить самостоятельно
            >А сколько прокручивать до этого "второго"?
            Ровно 0 раз :)
            > В сайдбар бы вообще добавить ссылку на запросы
            Это не нужно читателю, даже мне как редактору это не нужно. 30 000 ссылок в сайдбаре это зло. С уважением, Iniquity 10:53, 18 июля 2018 (UTC)
            • Как и шаблон мониторинг так же могут "включить себе самостоятельно", секунду только он уж точно отъедает и показывает меньше. Кому-то полезно. пока оно на виду о нём узнают другие. / Ну покажите скриншотами как попасть на форум через сообщество прокручивая 0 раз со смартфона/планшета/ноутбука (настольный вид). Сколько нужно всего сделать, чтобы добраться через сообщество до запросов на книги, к графистам, к администраторам. --Sunpriat 12:58, 18 июля 2018 (UTC)
  • Может быть, немножко убрать воды про лучший способ и поставить ссылки на прочие способы навигации ближе к верху страницы. Tucvbif???
    *     17:28, 5 июля 2018 (UTC)
    • @Tucvbif: М, про воду, я даже и не знаю что можно оттуда убрать:) А про прочие способы навигации, это про какие? С уважением, Iniquity 18:08, 15 июля 2018 (UTC)
      • Я имею ввиду те ссылки, которые идут ниже по тексту надо поднять выше, а всё это «огромное количество знаний, собранных по всему миру… самый простой способ…» и т.д. — лишнее. Tucvbif???
        *         18:16, 15 июля 2018 (UTC)
        • @Tucvbif: А где и как предлагается рассказать читателю о поиске и общем количестве статей? Можно конечно подсократить, но не думаю что изменится сильно. Плюс ссылки снизу практически все есть в шапке. С уважением, Iniquity 10:19, 18 июля 2018 (UTC)
          • А зачем? Если я открываю содержание, меня интересует не общее количество страниц, а как попасть на нужную мне. Полезное содержимое на этой странице — строка поиска и ссылки на инструменты поиска, всё остальное, если не помогает понять, куда ведёт ссылка — не особо нужные украшения. А общее количество статей можно и на заглавной посмотреть. Tucvbif???
            *             11:45, 18 июля 2018 (UTC)

Фильтр правок на {{http[править код]

Перенесено на страницу Википедия:Форум/Технический#Фильтр правок на {{http. С уважением, Iniquity 19:20, 25 июня 2018 (UTC)

Для бота: 17:03, 24 июня 2018 (UTC)

Предлагаю сделать так, чтоб карандаш был подписью и располагался справа как раньше[править код]

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

Я один такой чтоль?

Ну или, как минимум, замените знак карандаша в этой, для 99 % редакторов, не нужной опции на что-нибудь другое. -- S, AV 15:19, 24 июня 2018 (UTC)

Итог[править код]

Локально проблема решена. Остальных жалею. -- S, AV 22:50, 24 июня 2018 (UTC)

Книга рекордов википедии[править код]

Предлагаю по аналогии с книгой рекордов гиннесса создать книгу рекордов википедии по чисто википедийным рекордам. --Vyacheslav84 (обс.) 14:22, 20 июня 2018 (UTC)

  • Толстую? Игорь (обс) 14:23, 20 июня 2018 (UTC)
  • О, тут рядом как раз накрутку счетчика обсуждают. Vcohen (обс.) 14:25, 20 июня 2018 (UTC)
  • Рекорды всегда интересны - вон как сейчас их описывают на мундиале: кто и сколько! Лишь бы всё было валидно. --Gennady (обс.) 17:15, 20 июня 2018 (UTC)
  • А можно для примера хотя бы штук 4-5 возможных номинаций в этом списке? --Grig_siren (обс.) 10:13, 22 июня 2018 (UTC)
  • Ну списки а-ля «Википедист года» некоторыми участниками публикуются, принципиальной разницы нет. Но вместо присвоения рекордов по субъективным показателям (с возможным последующим выпрашиванием рекордов) лучше мини-марафоны проводить, если честно. ~Facenapalm 10:54, 22 июня 2018 (UTC)
  • Самая обсуждаемая статья, ИС с самым коротким-длинным обсуждением, ИС с минимальным количеством правок на момент получения сатуса, наибольшее количество оспоренных итогов - можно много придумать, и, как мне кажется, это будет и интересно и поучительно. Интересно - просто любопытно посмотреть на статью, получившую ИС, имея пять правок. Поучительно - я, читая обсуждения посложным вопросам, нахожу много полезного. P.Fiŝo☺ 06:49, 23 июня 2018 (UTC)
    • Это все субъективно. И ничего по сути не дает. Ну потратили вы время и создали в черновике или где-то в другом месте статью. поместили одной правкой в ВП. И чем это по результату отличается от непосредсвенного редактирования в самой ВП? По памяти ИС одной правкой - Речной окунь. Sas1975kr (обс.) 07:13, 23 июня 2018 (UTC)
  • ВП:НЕСОЦСЕТЬ. И есть мнение что эти градации - ордена и плюшки могут как мотивировать, так и демотивировать. Т.е. их польза для проекта не доказана. И по итогу даже созданные с самыми добрыми намерениями и вроде бы никак не могущие привести к конфликту по итогу могут быть причиной еще больших конфликтов. Статьи года тому наглядный пример. А уж чего будут стоить рекорды "самый упертый участник", "самый конфликтный участник" и т.п. Вам мало текущих конфликтов вокруг того же ордена носорога?
  • П.С. Придумайте уже пару номинаций для Vyacheslav84, наградите его орденом и закрывайте тему. ;) Sas1975kr (обс.) 07:13, 23 июня 2018 (UTC)
  • Википедист с самым большим стажем, википедист с самым большим числом сроков в АК, википедист с самым большим числом итогов, википедист с самым большим числом статей и прочее. --Vyacheslav84 (обс.) 04:11, 24 июня 2018 (UTC)
  • А что, я за. Даже за создание печатного варианта. Я бы купил такой чисто для коллекции и на память. — OlegCinema 15:39, 2 июля 2018 (UTC)

Снизить проходной порог для арбитров[править код]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

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

Предлагаю снизить порог с 2/3 (66,7%) до 3/5 (60%). Подобное снижение порога никак нельзя назвать изменением радикальным, это лишь 10-я часть, коя практически и незаметна будет. Из аргументов могу также привести следующие:

1) Арбитр выбирается на полгода, а мы требуем от него проходной балл, как для админа, кои у нас должность априори бессрочная.

2) Маловероятно, что кто-то за эти полгода будет ответчиком более одного раза, а три, при том, с какой скоростью рассматриваются дела... это надо очень постараться.

3) И ответчик, и заявитель могут потребовать отвода кого-либо из арбитров и, насколько я помню, с этим проблем никогда не возникало.

Если сие будет принято, то, разумеется, станет правилом лишь на следующих выборах. Предлагаю проголосовать. Перенесено в качестве добровольного наставника участника Schekinov Alexey Victorovich. --Michgrig (talk to me) 16:27, 19 июня 2018 (UTC)

  • Это надо обсуждать на форуме правил. На то, что такой вопрос можно решать голосованием, нужен предварительный консенсус. Следует заранее договориться о том, какой нужен перевес для принятия изменений, простого большинства явно недостаточно. С уважением, --DimaNižnik 21:00, 19 июня 2018 (UTC)
  • Голосованием на форуме это не решить. Вообще надо не порог снижать, а обдумать переход на систему STV. Тогда есть шанс, что АК будет иным, кроме того он гарантированно будет избираться. Abiyoyo (обс.) 21:20, 19 июня 2018 (UTC)
    • Это будет как в известном мультике — «Вот вам лучшие из худших». --НоуФрост❄❄❄ 21:22, 19 июня 2018 (UTC)
    • STV подходит, когда обязательно нужен итог, независимо от обстоятельств. У нас ситуация иная, без АК Википедия вполне может прожить. И почти наверняка без АК она проживёт намного лучше, чем с АК, который будет избран не пойми из кого. Если АК не избирается, то возможно надо переходить на систему, в которой нет АК, а не заставлять участников всеми правдами и неправдами хоть кого-то туда избирать. — putnik 00:07, 20 июня 2018 (UTC)
  • Согласен с тем, что это вопрос не для голосования. Да и польза от снижения порога сомнительна — как сейчас идёт перетягивание каната вокруг 66-процентного барьера, так же оно будет идти и вокруг 60-процентного, а на выходе периодически будем получать арбитров, которым не доверяет почти половина активных участников. --Deinocheirus (обс.) 23:08, 19 июня 2018 (UTC)
  • А если понизить даже до 50 % + 1 голос и при этом расширить Арбком до 15—20 человек? (15 — необходимый минимум). Это так, в порядке бреда. — Postoronniy-13 (обс.) 00:49, 20 июня 2018 (UTC)
    • И видеть потом отводы всего АК с последующими сквозняками на тему ВП:НЕЧЕСТНО. Надо не голосование менять, а что-то в консерватории. Видимо, что-то с репутацией или полномочиями этого органа, если от участия в нем в массовом порядке уклоняются, причем, зачастую, даже его участники в прошлом. — Aqetz (обс.) 09:38, 20 июня 2018 (UTC)
    • Дополнение: и, наверное, среди «переваливших за полтинник» лучше ранжировать по числу голосов за, а не по проценту. Т.е. замерять популярность в плюс, а не размер «негативного фан-клуба». Явно негодных так, скорее всего, отсеем (на нынешнем этапе: негативные тенденции ещё не настолько возобладали). Хотя, возможно, предложение Abiyoyo (от 21:20, 19 июня 2018 (UTC)) лучше. — Postoronniy-13 (обс.) 09:49, 20 июня 2018 (UTC)
  • Если так хочется избрать арбитров с первого раза, то порог можно и до 30% снизить. Только зачем нам такой АК? Какой будет авторитет у его решений, если он и сейчас мягко говоря "не очень". --wanderer (обс.) 08:35, 20 июня 2018 (UTC)
    • А Вы прикиньте, кто скорее всего непроходной при «как сейчас» и при этом проходной при «полтиннике». И какие могут получиться примерные «конфигурации» Арбкома. (Только, плиз, на этой странице без конкретных никнеймов.) И может ли это работать (по-моему, «коалажней» не станет, а вот генерация идей и качество на выходе, плюс уменьшение нагрузки на отдельно взятого члена АК…) — Postoronniy-13 (обс.) 09:49, 20 июня 2018 (UTC)
      • {{удалено мной. --wanderer (обс.) 10:37, 20 июня 2018 (UTC)}} прислушаемся к мнению тех, кто там работал? --wanderer (обс.) 10:03, 20 июня 2018 (UTC)
        • А где у меня «до хрипоты, до драки»? Я всего лишь накидываю мысли, поскольку считаю это нужным. — Postoronniy-13 (обс.) 10:08, 20 июня 2018 (UTC)
          • Ну хрипота и драка не главное (хотя и они тоже вскоре могут объявится). Главное, что уже сейчас здесь отметились три бывших члена АК и напрямую написали "что чем меньше порог, тем дальше будут посылать". А вот про "генерация идей и качество на выходе, плюс уменьшение нагрузки на отдельно взятого члена АК" - ни слова. --wanderer (обс.) 10:14, 20 июня 2018 (UTC)
            • У меня хрипоты и драки не планируется (сначала контроль сознания, затем нажатие кнопочек «править» и тем более «сохранить»), а за других не отвечаю. || Давайте разделять вариант Schekinov'а и мой (попытаюсь одного из трёх переубедить ;)). Суть моего — в «срезе» по сообществу (точнее, конечно, той его части, которая на арбитражные выборы приходит) и в совокупном авторитете прошедших. При этом в глазах авторитетных участников A и B избранный арбитр C может иметь строго отрицательный авторитет, как арбитр или вообще как википедист/личность. Но если он такой лишь один из 15+? — Postoronniy-13 (обс.) 10:45, 20 июня 2018 (UTC)
              • Ну вот смотрите. Во-первых, чем больше арбитров, тем труднее найти консенсусное решение. Просто потому, что каждый из них человек и каждый смотрит на вопрос немного под другим углом. И насколько я помню теорию бюрократии, если состав коллегиального органа/совета/комитета расширить до 20 человек, то он утрачивает способность принимать решения. Поэтому 5 арбитров - хуже, чем 3, но лучше, чем 7. Во-вторых, нам не нужен срез сообщества, нам нужен работоспособный орган, который может принимать решения, разрешающие конфликты. И в третьих, не бывает совокупного авторитета, есть авторитет конкретных личностей. Например, если решение подписано условными Генкиным, Блантером и Томасом, то это автоматически давало +100 харизмы, да и с логикой обоснования у них как-то проблем не было. А иначе нужно очень-очень обстоятельное обоснование решения, но его как раз те, то сейчас не проходят, скорее всего написать и не смогут. --wanderer (обс.) 11:03, 20 июня 2018 (UTC)
                • И насколько я помню теорию бюрократии, если состав коллегиального органа/совета/комитета расширить до 20 человек, то он утрачивает способность принимать решения. Начну с того, что на цитированное утверждение попрошу пруфлинк. (То, что коллегиальный орган нельзя расширять за некоторый предел численности, интуитивно ясно, вопрос в хотя бы примерном значении «некоторого».) — Postoronniy-13 (обс.) 15:24, 20 июня 2018 (UTC)
  • (+) За--Kaiyr (обс.) 08:45, 20 июня 2018 (UTC)
  • В предложении нет оценки: как далеко будут посылать такой АК с его решениями. Мне кажется, что чем меньше порог, тем дальше будут посылать. — VlSergey (трёп) 09:24, 20 июня 2018 (UTC)
  • «а мы требуем от него проходной балл, как для админа, кои у нас должность априори бессрочная» — можно подумать, ситуация с админами — эталон. Нет, её решать надо. А арбитр и должен обладать большим доверием, чем администратор, влияния у него больше и работа сложнее. ~Facenapalm 10:17, 20 июня 2018 (UTC)
  • лучше меньше, да лучше. ShinePhantom (обс) 10:40, 20 июня 2018 (UTC)
    Владимир Ильич, конечно, выдающийся социальный мыслитель; но в нынешнем случае мы это самое «лучше меньше, да лучше» хлебаем полной ложкой. Без выбора пьём это варево (!). — Postoronniy-13 (обс.) 12:00, 20 июня 2018 (UTC)
    Необходимое примечание: это не выпад в отношении хоть кого-то из членов АК недавних созывов. Претензий к отдельным лицам не имею, да и не в лицах дело. — Postoronniy-13 (обс.) 12:10, 20 июня 2018 (UTC)
  • Согласен с высказавшимися. АК без легитимности, обеспеченной высокой поддержкой сообщества, работать не может. Замечу ещё, что в среднем результаты одних и тех же участников на выборах в АК существенно выше, чем на админских, так что изначальная постановка вопроса ошибочна. AndyVolykhov ↔ 11:09, 20 июня 2018 (UTC)

Итог[править код]

Не поддержано. -- S, AV 21:27, 22 июня 2018 (UTC)

Служебные категории с префиксами[править код]

Коллеги, в процессе работы натолкнулась на такое проблемное явление как служебные категории. Дело в том, что многие такие категории называются со слова «Википедия» (например: к:Википедия:Шаблоны). При этом есть категории, каторые начинаются с сокращения ВП (что в категориях неравносильно и не работает как алиас. Пример: к:ВП:Нет дефиса). Также есть немало служебных категорий без этого слова вообще (например: к:Страницы с петлями в шаблонах). А есть ещё служебные категории, начинающиеся со слов «Шаблоны», «Проект», «ПРО», «Портал», «Порталы», «Арбитраж» и т. д., при том что помимо них есть масса категорий безо всяких префиксов в названии. Такая ситуация весьма неудобна, как минимум она вызывает ошибки при простановке категорий, так как легко упустить из виду, что в одной категории префикс есть, а в другой похожей его нет.

Соответственно, предлагаю следующее:

  1. Разработать правила использования служебных префиксов в категориях. Возможно, некоторые вовсе не нужны? По крайней мере польза от префикса «Википедия» очень сомнительна. И привести все служебные категории к единообразию.
  2. Разработать механизм алиасов для категорий, чтобы проставленная Категория:ВП:Что-то автоматически преобразовывалась в Категория:Википедия:Что-то.

Emo4ka ツ (обс.) 13:56, 19 июня 2018 (UTC)

  1. Они есть - ну не сколько как правила, сколько как обычай - для категорий под не-статьи применяются соот. префиксы. Префиксы нужны, дабы служебные категории визуально/фильтрами отделять от категорий для статей. Привести к единообразию - да, хотелось бы: в частности стараются избавиться от двойных префиксов типа "Википедия:Файлы:" --> "Файлы:", "Википедия:Шаблоны:" --> "Шаблоны:", но это дополнительно нагружает движок (особенно в последнем случае, если категория идёт из самого шаблона, а не из документации к нему), в том числе и по причине большого числа таких категорий - поэтому это делается постепенно.
  2. Это уже технически невозможно при текущем движке. Только первый префикс является префиксом с тех.точки зрения (и только для него можно создать алиас). Переделывать движок под учёт иных префиксов вряд-ли кто-то будет - слишком много мороки. Alex Spade 14:19, 19 июня 2018 (UTC)
Ок, второе вычеркнула. Что касается первого, то какая-либо логика в простановке префиксов, конечно, просматривается, но для этого нужно очень сильно приглядываться. Например, для вполне себе статей основного пространства есть масса категорий с префиксами (типа к:Википедия:Статьи без ударений) и без них (типа к:Статьи, требующие проверки на грамматические и орфографические ошибки). Для документации шаблонов почему-то используется странная конструкция к:Шаблоны:Документация, а для прочих подстраниц - к:Википедия:Подстраницы шаблонов (содержимое её тоже весьма разнообразно по префиксам). Emo4ka ツ (обс.) 14:35, 19 июня 2018 (UTC)
Ну, бардака в названиях не-статейных категорий, согласен, (ещё) много. Ряд участников периодически работают над его уменьшением, но это не просто. Переименование категории тянет за собой правку в каждой странице из этой категории, а уж если это категория — категория шаблонов/изображений, то нередко движку может понадобиться перекэширование всех страниц, включающих этот шаблон/изображение, а если они ещё и непатрулированы были, то ещё и к частичному распатрулированию статей. Так что, в этом случае массовая быстрая унификация сделает только хуже... Alex Spade 21:21, 19 июня 2018 (UTC)
  • Создать то всё можно. Но работать не будет. Механизмы ведь не знают, что это категории. Ссылки внизу будут отображаться как ссылки, а не как включение. Запросы давать результаты не будут. Для этого надо всё менять, чтоб знало, о чём речь. Игорь (обс) 16:30, 19 июня 2018 (UTC)
  • На самом деле сымитировать существование такого пространства, а также реализовать зачёркнутую мной идею, можно просто с помощью викификатора. Проблема не столько в этом, сколько в отсутствии правил и руководств по категоризации, из-за чего возникает бардак, причём чем дальше, тем хуже: уже сейчас массовая быстрая унификация сделает только хуже (с), а дальше и страниц будет больше, и шаблонов, и категорий. Нужно сформировать принципы служебной категоризации, а потом пусть не "массово и быстро", но постепенно и целеустремлённо их реализовывать. Emo4ka ツ (обс.)
  • «На самом деле сымитировать существование такого пространства ... можно просто с помощью викификатора.» Я уверен, что это не так, и на всякий случай посоветовался с видными деятелями. Игорь (обс) 15:44, 20 июня 2018 (UTC)
  • Просто настроить автозамену "Категория:ВП:" и "Категория Википедии:" на "Категория:Википедия:". А в фильтр правок внести полный запрет на создание страниц первых двух видов с предупреждающим сообщением о том, как надо назвать категорию. (Разумеется, пока на это нет консенсуса, то и обсуждать нечего) Emo4ka ツ (обс.) 16:01, 20 июня 2018 (UTC)

Отмена "пограничной" зоны на выборах администраторов[править код]

Если посмотреть результаты и сопутствующие обсуждения прошлых лет, то видно, что преодоление планки в 2/3 означает избрание кандидата. Например, давний случай неизбрания кандидата, преодолевшего необходимый порог, привел к заявке в АК, что не способствует снижению напряженности в проекте. С другой стороны, избрание АК стабильно происходит по строгой отсечке, и никаких проблем с этой стороны не наблюдается. К тому же бюрократы отмечают некоторую перегруженность и нехватку времени. В связи с этим, как сообщество смотрит на идею отменить "пограничные" зоны, где бюрократы могут пересматривать итоги, и оставить избрание/неизбрание на усмотрение сообщества? - DZ - 05:20, 14 июня 2018 (UTC)

  • отрицательно. То, что в основном кандидаты получают все-таки флаг - это как раз нормально. А отмена зоны приведет к отчаянной борьбе за каждый голос со всевозможной законной и не очень агитациями, спящими виртуалами и прочему. ShinePhantom (обс) 06:28, 14 июня 2018 (UTC)
  • ВП:НЕПОЛОМАНО. Не надо отбирать хлеб у бюрократов и арбитров. «Некоторая перегруженность» это хорошо, а не плохо, — пусть всё будет в тонусе. Джекалоп (обс.) 06:40, 14 июня 2018 (UTC)
    • Джекалоп, как минимум одно "поломано" вы можете наблюдать прямо внизу последней заявки. Другое привело к заявке в АК, о чём я написал. И к чему тогда данная ссылка? - DZ - 06:56, 14 июня 2018 (UTC)
      • Что тут поломано ? Да, возникли вопросы. Да, получены адекватные ответы. Да, пообсуждали, обменялись мнениями, поспорили даже. И что в этом деструктивного ? Заявка в АК — тоже вполне нормативный способ регулирования разногласий. Всё по плану, ничего страшного. Джекалоп (обс.) 07:06, 14 июня 2018 (UTC)
      • Ничего такого там не заметно. Да, есть недовольные решением бюрократов. Но даже если принятое бюрократами решение окажется ошибочным, один случай — это ещё не поломано.--Tucvbif???
        *         07:10, 14 июня 2018 (UTC)
  • Против. Ограничение прав-обязанностей бюрократов — тонкая месть за неизбрание? Я до сих пор жалею, что «проспал» Статью 2017 года, тогда бы в одной номинации пьедестал выглядел бы по другому. Но то конкурс, ещё одна иконка в 2 местах, а здесь флаг википедиста. Если есть однозначное принятие или непринятие обществом человека, то в этом случае всё однозначно, а когда ситуация на грани, то надо разбираться и кому это не делать, как людям с высокой степени доверия общества? Есть вариант АК, им тоже доверяют. Если в шутку: не так уж и загружены бюрократы, чтобы им облегчать работу. — VladXe (обс.) 07:23, 14 июня 2018 (UTC)
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
    • Как же надоели реплики про "месть".. Один чуть ли не матом кроет, а предложишь ограничить ему эту опцию, сразу преследование. Здесь тоже. Ну, не избрали, и что? Ходить злобствовать и мстить? Что у вас за логика-то такая.. Хотя приплетение каких-то иконок оффтопом несколько показательно. Спасибо за мнение. - DZ - 07:37, 14 июня 2018 (UTC)
      • Извините, если наступил на больную мозоль, но специально набрано мелким шрифтом, чтобы показать, что это подкол такой, уж не ждал, что поведётесь. Закрыли тему. — VladXe (обс.) 07:45, 14 июня 2018 (UTC)
        • "поведётесь", "подкол" - проследуйте куда-нибудь вне вики и "подкалывайте" кого угодно. - DZ - 07:51, 14 июня 2018 (UTC)
  • Отрицательно. АК - коллегиальных орган, именно поэтому там можно делать строгую отсечку. Вы хоть один случай, чтобы хотя бы три арбитра ровно по границе избирались, знаете? Igel B TyMaHe (обс.) 09:37, 14 июня 2018 (UTC)
    • Вы меня не правильно поняли. Если создателя темы не устраивает, что в серой зоне принимают решение бюрократы, то (как вариант) это решение может принять АК. Про процедуру избрания АК в моей реплики ни слова. — VladXe (обс.) 10:14, 14 июня 2018 (UTC)
  • Вряд ли это сильно повлияет на загруженность бюрократов. Да и мнение их самих узнать интересно было бы. Excellence (вклад) 11:17, 14 июня 2018 (UTC)
  • Отрицательно. Совершенно не зачем ломать один из немногих предохранительных механизмов. И таки НЕПОЛОМАНО. --wanderer (обс.) 09:21, 14 июня 2018 (UTC)
  • «Зона» нужна как минимум на случай канвассинга и прочих деструктивных действий. Более того, ее надо расширять и вообще переходить к обсуждениям по аргументам. Последнее соображение не относится прямо к предложению, но косвенно также говорит в пользу нежелательности отмены «зоны». Abiyoyo (обс.) 11:03, 14 июня 2018 (UTC)
    • Abiyoyo, я уже у кого-то спрашивал, может, вы ответите: а судьи кто? Кто возьмет на себя ответственность подводить итог? Предлагаете нагрузить бюрократов, так они отмечали сложность даже при обработке текущего процесса. АК? ФА? Подводится итог, его автор обвиняется в конфликте с кандидатом (у нас это модно последнее время), итог оспаривается, уходит в АК, АК еще полгода-год его вывозит. У нас с такими "процедурами" вообще админов не будет. :) - DZ - 12:02, 14 июня 2018 (UTC)
      • Проблема судей возникает, когда вопрос важный, когда цена ошибки высока. Если же флаг легко присваивать и легко снимать (ср. ЗСПИ), то проблема судей перестает быть серьезной — not a big deal. Easy come, easy go. Поэтому расширение полномочий бюрократов, конечно, должно идти в связке с упрощением снятия и присвоения флага администратора. Сейчас — да, выбирают не администраторов, а святых. оттого такое внимание к малейшим деталям. Но это в целом оффтопик, конечно. На сегодняшний момент основная функция «зоны» — отсев явного деструктива в голосовании и отсев явно, грубо невалидных аргументов в пограничных случаях. Такова функция зоны сегодня. Abiyoyo (обс.) 12:09, 14 июня 2018 (UTC)
        • Ну, вот мы и пришли к тому, что сначала стоит решить вопрос про "not a big deal". Т.к. без этого переход к обсуждению скорее невозможен. А указанный вопрос, судя по недавним обсуждениям на форумах, решить будет не просто. - DZ - 06:29, 15 июня 2018 (UTC)
  • Создаётся впечатление, что для бюрократов эта «серая зона» только необходимость анализировать аргументы, что они принципиально не пользуются своим правом влиять на формальный количественный результат. Однако эта ситуация снижает напряжённость в сообществе и предохраняет от грубых ошибок. Единственной альтернативой могла бы быть обязательная конфирмация для попавших в эту зону (например через год), при этом и саму зону можно расширить, но я не уверен, что даже если от этого будет положительный эффект, он оправдает затраты на выработку новой редакции правила. --DimaNižnik 11:27, 14 июня 2018 (UTC)
  • В смежной теме Carpodacus всё объяснил очень доходчиво с точки зрения статистики. Серая зона нужна, даже если редко на что-то влияет — и её необходимость на выборах в АК тоже давно обсуждалась (и особых возражений не вызывала), только технически воплотить так никто и не сподвигся. --Deinocheirus (обс.) 12:44, 14 июня 2018 (UTC)
  • Хоть моя реплика ни на что и не повлияет (поскольку тут уже выступило довольно много противников предложенной идеи), но я выскажу поддержку предложению об устранении «серой зоны» на выборах админов и бюрократов. И вот почему: фактически «серая зона» — это легальный инструмент бюрократов по вычёркиванию голосов в ситуации, когда кандидат набрал более требуемого порога голосов, но по каким-то причинам не устраивает болььшинство бюрократов (наступил им на больную мозоль, например), и по добавлению недостающих до требуемого порога голосов в ситуации, когда кандидат не дотянул до этого порога, но большинство бюрократов ему симпатизирует. И не надо мне рассказывать про использование виртуалов на голосованиях — согласно правилам виртуалы, использующиеся для изменения уровня поддержки на выборах, должны блокироваться, а их голоса — вычёркиваться. Так что пока у нас будет «серая зона» (неважно, с какими границами), у нас будет возможен произвол бюрократов по ингорированию уровня поддержки кандидата сообществом. И это мне совсем не нравится. Так что я одобряю решения бюрократов, в которых их итоги совпадали с техническими результатами. Кадош (обс.) 21:28, 14 июня 2018 (UTC)
    • Теория заговора и подозрение в злых намерениях не выдерживают элементарной проверки фактами. Совсем недавно была ЗСА, где за кандидата было двое из активных бюрократов, по итогам он попал в серую зону, а флаг выдан не был. --Deinocheirus (обс.) 22:23, 14 июня 2018 (UTC)
  • Тут просили высказаться бюрократов… Должен честно признаться, что общего обсуждения у нас не было, поэтому говорю только от себя. По существу вопроса согласен с теми, кто говорит, что НЕПОЛОМАНО. Мы своим правом «вытягивать» или «топить» не «злоупотребляем», но я не исключаю, что когда-нибудь оно может потребоваться. Из того, что предложено выше, я, пожалуй, не стал бы с ходу отметать предложение коллеги Dimaniznik об обязательной конфирмации «серых» администраторов через год (или полгода) — это помогло бы избежать длительного эффекта от ошибочных решений. Хотя можно и оставить, как есть. — Adavyd (обс.) 22:43, 14 июня 2018 (UTC)
    • Мне тоже понравилось предложение Димы, но если развивать его мысль, то нужно оговорить, что делать в том случае, если по итогам конфирмации уровень поддержки окажется в «серой зоне». Я бы предложил в таких случаях отменять «серую зону» — иначе кандидат будет вынужден проходить конфирмацию до тех пор, пока он не выйдет за её границы (в ту или иную сторону). Кадош (обс.) 04:02, 15 июня 2018 (UTC)
      • Здесь согласен: одной конфирмации по итогу избрания достаточно, главное, чтобы меньше 63,(6) % голосов не было. — VladXe (обс.) 04:51, 15 июня 2018 (UTC)
    • Эта тема ни в коем случае не про "злоупотребление". Как раз наоборот, я выше писал, что по сути, почти всегда результаты трактуются по прохождению кандидатом отметки в 2/3. Поэтому было бы логично закрепить это. Та же конфирмация через год - тоже вполне годное решение. Но если всё всех устраивает, никто не настаивает. - DZ - 06:25, 15 июня 2018 (UTC)
  • (+) За Больше автоматизации и объективизации, меньше субъективности. Вообще бюрократы от админ только техн функции отличаются же?--Kaiyr (обс.) 05:33, 15 июня 2018 (UTC)
    • Субъективность сменится случайностью: кто-то, кто мог проголосовать в вики-отпуске, кто-то наоборот зарылся в написание статей. Либо тогда нужно сильно увеличить минимальное количество голосов для того, чтобы выборы признать состоявшимися.--Tucvbif???
      *       10:09, 15 июня 2018 (UTC)

Итог[править код]

Всем спасибо. Хорошо или плохо создавать подобные темы - это вопрос вторичный. Но послушать актуальное мнение никогда не вредно. Сейчас явно "пограничной" зоны на выборах администраторов считаются полезными. Дальше отвлекать внимание не имеет смысла, да и внимание тема больше не привлекает. Поэтому, полагаю, можно закрывать. - DZ - 09:51, 17 июня 2018 (UTC)

Автоматическое включение скрипта patlinkshl.js всем патрулирующим[править код]

Предлагаю автоматически подключать скрипт patlinkshl.js всем участникам получающим флаг патрулирующего. Более подробно о срипте можно прочитать в архиве форума патрулирующих. Скрипт подсвечивает ссылки на статьи разными цветами в зависимости от степени патрулированности: Ссылки на страницы с непатрулированной последней версией будут выглядеть так, на никогда не патрулировавшиеся - так. Автоматическое (не хочется писать "принудительное", но по сути - именно так) подключение скрипта поможет привлечь внимание патрулирующих к статьям не прошедшим патрулирование. Я уверен (впрочем, без опоры на цыфры), что в этом случае патрулирующие будут более активно патрулировать статьи. Могу сказать, что я, после подключения скрипта, стал более активно патрулировать статьи связанные с моими темами и практически не упускаю статьи ни разу не патрулированные. --P.Fiŝo☺ 09:27, 9 июня 2018 (UTC)

  • Нужна возможность отключения. — Vort (обс.) 09:46, 9 июня 2018 (UTC)
    • Присоединяюсь. Мне не хотелось бы видеть в статьях кучу разноцветных ссылок. --VAP+VYK 09:59, 9 июня 2018 (UTC)
  • Можно переписать с AJAX на использование Wikipedia JS API и перенести в гаджеты. Однако делать что-то обязательное это неправильно. — VlSergey (трёп) 10:11, 9 июня 2018 (UTC)
  • Я бы не хотел чтобы у меня ссылки в статьях принудительно раскрасились. Я разделяю патрулирование и другие действия с Википедией, не хочу никакого принуждения к патрулированию, даже мягкого. --WikiFido☯ 13:18, 9 июня 2018 (UTC)
  • Согласен, возможность отключения нужна обязательно. P.Fiŝo☺ 20:26, 9 июня 2018 (UTC)
  • Угу, вот для того и надо преодолевать этот наибижайший из деалищщ — получение пата, чтобы тебе принудительно подключили какую-то цензоред. Типа, чудохался-чудохался на этом ЗСП, и вот тебе награда: да, признаём, дорогой, что ты полный идиот, сам ничего подключать не умеешь и вообще не соображаешь ничего сам. — Mike Novikoff 01:06, 10 июня 2018 (UTC)
  • Принудительно - нельзя. Прорекламировать в ВП:Скрипты, ВП:ПАТ, в шапке ВП:ЗСП - можно. MBH 03:30, 10 июня 2018 (UTC)
  • А неплохо. Только хочется кнопку в интерфейсе, чтобы включать и выключать по желанию. −−APIA 〈〈обс〉〉 07:06, 10 июня 2018 (UTC)
  • Кошмар. Если я не патрулирую статьи на незнакомую тему, это вовсе означает, что мне следует изуродовать цветовую схему проекта и сделать работу в нём невозможной.—Iluvatar обс 16:09, 10 июня 2018 (UTC)
  • Не знаю. Мне наоборот нравится. Использую давно, ещё как бета-тестер. Если ссылка жёлтая (есть изменения), сразу смотришь, нет ли там вандализма. А если красная (то есть не патрулировалась), то это повод дополнить статью и проверить на вандализм. Oleg3280 (обс.) 20:22, 10 июня 2018 (UTC)
  • У меня такое ощущение, что некто решил отвадить последних могикан Рувики, на которых кое-как проект держится и развивается.--Dmartyn80 (обс.) 17:57, 11 июня 2018 (UTC)
  • Перевести в гаджеты, чтобы включалось одной кнопкой — за. Включать по умолчанию — категорически против. ~Facenapalm 18:07, 11 июня 2018 (UTC)
  • Я себе давно подключил, поначалу пользовался очень активно, сейчас, правда, уже не так. Но принудительно — не надо, в некоторых темах жёлто-оранжевой чуть ли не вся статья становится. --Deinocheirus (обс.) 14:21, 12 июня 2018 (UTC)

Итог[править код]

В общем, здесь видно, что консенсуса за принудительное включение нет. В то же время отдельной кнопкой - это был бы достаточно удобный инструмент. - DZ - 05:28, 14 июня 2018 (UTC)

Предложения по ПИ и КУ[править код]

1) Также подводящие итоги могут подводить предварительные итоги по любым другим номинациям на страницах «К удалению», не входящим в список перечисленных выше. В случае, если в течение недели к такому итогу не поступит возражений, кроме явно некорректных[3], такой итог может быть подтверждён и признан окончательным любым другим подводящим итоги (bolt от меня). Предлагаю, что бы ПИ могли подводить окончательные итоги после любого предварительного итога. И закрепить что предварительный итог может внести любой участник
2) По коммерческим организация и ВП:БИЗ - значимость (соответствие критериям) явно должна быть показана в статье или в обсуждение. Если этого не показано, то удалять сразу
3) ВП:БИЗ-2п. - заменить термин "системообразующих предприятий". Это ведь каждый раз делать анализ рынка, не только самой персоналии но еще и предприятия. Да и термин для предприятие вне СНГ крайне расплывчат.
4) Сделать бота собирающего все оспоренные итоги и все предв. итоги. Для начала хотя бы для анализа.
5) Вместо ВП:ПРОГРАММИСТЫ добавить "Остальные профессии". Принцип оставить тот же, Авторство, лауреат престижных..., освещение в профильных изданиях. --Čangals (обс.) 09:06, 7 июня 2018 (UTC)

  • К предложениям на форумах, думаю, отнесутся с большей благосклонностью, если они будут оформлены корректно как с точки зрения Википедии (викифицированы, корректное использование викисинтаксиса, гиперссылки), так и с точки зрения русского языка: орфография, пунктуация, согласования, выделение кавычками и пр. — VlSergey (трёп) 14:14, 7 июня 2018 (UTC)
  • 1) А за что вообще так дискриминируют ПИ? Предварительные итоги ни к чему никого не обязывают, их кто угодно может подводить. То есть вот я не ПИ - могу подвести итог, а получил ПИ - и привет, только определённые случаи? Что-то сгнило в королевстве Датском. 2) ВП:НЕБЮРОКРАТИЯ. Значимость всегда означает оставление. Удаление статей о значимых темах возможно только за нарушение формальных правил (ВП:МТ, ВП:ЧНЯВ, ВП:КОПИВИО, машинный перевод...) 3) для России понятие системообразующего закреплено законом. Другое дело, что список этот меняется. — Igel B TyMaHe (обс.) 15:49, 7 июня 2018 (UTC)
  • Предварительный итог может подводить кто угодно где угодно, даже ПИ, даже А. Тут ничего особо разрешать не требуется. Emo4ka ツ (обс.) 13:53, 8 июня 2018 (UTC)
    • В темах вне рамках полномочий ПИ, окончательный итог ПИ может подвести если предварительный итог перед этим был написан не любым участником, а именно ПИ. А так я согласен, предварительные итоги может подводить кто угодно и где угодно!
      Čangals (обс.) 14:10, 8 июня 2018 (UTC)
  • Вот что точно нужно, это ботообновляемый список незакрытых оспариваний и предитогов. --ЯцекJacek (обс.) 16:14, 8 июня 2018 (UTC)
  • @Changall:, @ЯцекJacek: Собрал списки предварительных и оспоренных итогов. --Emaus (обс.) 21:22, 21 июня 2018 (UTC)

Удаление ненужной кастомизации из навигационных шаблонов[править код]

С целью уменьшения технического долга предлагаю формализовать удаление следующих параметров из шаблона {{Навигационная таблица}} (и всех зависимых от них):

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

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

Хотелось бы, чтобы участники, которые будут против этого изменения, продемонстрировали аргументированные способы кастомизации, которая является необходимой для оформления этого шаблона, а не желаемой конкретно его автором (что может быть обеспечено через личный CSS). @TenBaseT: stjn 17:18, 4 июня 2018 (UTC)

  • Кастомизации в этом вопросе не нужно. стиль_тела не оправдано менять вообще ни в каких случаях. Иногда участники окрашивают шаблоны «по смыслу». Оставлю за скобками насколько это оправдано, но даже в этом случае переопределять цвета чередования полос чет/нечет нет нужды, достаточно перекраски заголовков: так как цвет серый, то выравнивать его по тону не нужно вне зависимости от выбранной общей цветовой схемы. Наверное, в далеком будущем можно учитывать такие вещи как баланс белого и контраст по тону, но в ситуации кромешного ужаса с оформлением доморощенного зоопарка «красивых» шаблонов, о таких деталях думать явно рано. --Abiyoyo (обс.) 18:46, 4 июня 2018 (UTC)
  • Не понимаю, чем так не угодила кастомизация цветов? Что случится от того, что один шаблон будет окрашен голубым, другой — розовым, третий — зелёным? Качество статей от этого не упадёт. Да, может быть иногда кастомизация заходит слишком далеко, делая шаблоны нечитаемыми — как вариант, можно предложить набор приемлемых цветов.--Tucvbif???
    *     07:30, 5 июня 2018 (UTC)
    • Частично такие ограничения уже введены — в разделе ВП:ЦВЕТ указаны рекомендуемые значения для контрастности. — Vort (обс.) 07:36, 5 июня 2018 (UTC)
      • Речь не об этом, а о том, чтобы дать набор цветовых схем, которые можно было бы использовать в навшаблонах, карточках и других элементах статей: нейтральные, тематические. Хотя возможность задать цвета вручную я бы оставил для отдельных тем.--Tucvbif???
        *         07:49, 5 июня 2018 (UTC)
        • Если бы что-то предлагалось, а только запрещается. --VladXe (обс.) 07:51, 5 июня 2018 (UTC)
        • Запрет раскраски вообще тут не предлагается. Речь всего лишь только о частных параметрах чет/нечет и тело, которые даже в разных схемах одинаковые. Раскладушки — другой вопрос совсем. Перпендикулярный этому.--Abiyoyo (обс.) 12:26, 5 июня 2018 (UTC)
    • > Не понимаю, чем так не угодила кастомизация цветов?
      Зачем она? Покажите, где она может требоваться. Оставлять возможности ради возможностей в каждом инструменте — глупость. Я лично не видел, чтобы эти параметры хоть где-либо использовались с пользой, а не по личным преференциям, вносящим суматоху и неразбериху в оформление проекта. Если же что-то без них не может быть поправлено, это что-то надо править везде, а не на уровне отдельных шаблонов. stjn 10:53, 5 июня 2018 (UTC)
      • Вместо того, чтобы бороться с безвредной раскраской навшаблонов, которая как минимум не ухудшает навигацию, лучше бороться с лотухами, навшаблонами-раскладушками и с забиванием подвалов статей десятками шаблонов, ссылающихся на одни и те же статьи. Если же вы боитесь суматохи и неразберихи — читайте моё предложение на пару реплик выше.--Tucvbif???
        *         11:21, 5 июня 2018 (UTC)
        • Как вы можете посмотреть в моём вкладе, я регулярно борюсь и с тем, и с другим, обычно против одних и тех же лиц, которым хочется разрешить всё. Уж меня обвинять в том, что я мало делаю ради привнесения здравого смысла в эту сферу, не нужно. stjn 11:27, 5 июня 2018 (UTC)
          • Просто сравните вред от перечисленных мной явлений, или например от навшаблонов-раскладушек, от одного вида которых начинает болеть предплечье, навшаблонов с отбором по ОРИСС-ному критерию, шаблонного спама — и просто раскраской шаблонов в разные цвета, к тому же ещё почти всегда приглушённые. От последнего я не вижу вообще никакого вреда.--Tucvbif???
            *             11:52, 5 июня 2018 (UTC)
            • Если у вас есть силы и энергия постоянно талдычить сообществу на одну и ту же тему, которая зачастую заканчивается ничем, так как люди хотят одновременно обсуждать вкусовые вопросы аргументированно и не предоставлять никаких аргументов в пользу своего вкуса, — идите и обсуждайте. Первая ссылка была незакрытым обсуждением, так вот, сходите его и переоткройте вместо того, чтобы указывать другим, какие проблемы проекта им решать. stjn 12:18, 5 июня 2018 (UTC)
              • Если за существование безвредной опции нужны аргументы —
                1. Задача навшаблона — показать читателю, что по связанным темам он может найти ещё статьи. И яркая окраска призвана привлекать внимание читателя, увеличивая вероятность, что он задержится на сайте и может быть станет редактором.
                2. Если навшаблоны окрашены в разные цвета, и я перешёл по ссылке в навшаблоне на статью, где навшаблонов больше одного — по цвету мне удобнее найти тот навшаблон, который я исследовал.
              • Чем эти аргументы плохи?--Tucvbif???
                *                 12:29, 5 июня 2018 (UTC)
                • Вы точно понимаете, о чём говорите? Как вам раскраска фона навшаблона или, того хуже, чётных/нечётных помогает в идентификации (даже если принимать эту точку зрения)? stjn 12:34, 5 июня 2018 (UTC)
                  • Если уж цвет заголовка изменять можно, то тело и чересполосица (если её не отменить вообще) должны подстраиваться под его цвет, и если вы не придумаете способ автоматически выбирать цвет тела и чересполосицы — лучше оставить раздельное их задание. --Tucvbif???
                    *                     12:45, 5 июня 2018 (UTC)
                    • Вы можете дать конкретные примеры, где нужно настраивать тело и чересполосицу? Мне неинтересно общаться гипотезами, нигде реальной нужды в этом переоформлении нет, так как цвет заголовка и лэйблов никак не соотносится с цветом шаблона вообще.. stjn 13:03, 5 июня 2018 (UTC)
                    • Tucvbif в том, что вы говорите, есть разумная часть. но во-первых какое отношение это имеет к обсуждаемому вопросу? тут не обсуждается раскраска шаблонов вообще, а только чет/нечет и т. п. И кстати, если надо делать шаблоны разноцветными в пределах статьи, то это надо делать не раскраской самих шаблонов, а на мета-уровне раскрашивать последовательные вхождения какой-то радугой. Иначе вы никогда не получите предсказуемый резултат — в каком порядке какой шаблон с каким цветом куда попадет. То есть даже это опять же не вопрос кастомизации, а вопрос того, чтобы последовательные вхождения раскрашивать скриптом или как еще.--Abiyoyo (обс.) 13:19, 5 июня 2018 (UTC)
                      • Да, извиняюсь, я ошибся и не понял сначала, что речь о раскраске вообще не идёт. Однако параметр «стиль тела» используется не только для окрашивания. На самом деле таких шаблонов довольно немного: я насчитал около 400 из почти 5000.--Tucvbif???
                        *                         15:59, 5 июня 2018 (UTC)
  • Я бы чётко оговорил в документации {{Навигационная таблица}}, какие параметры можно менять, а какие не рекомендуется, наподобие тому, как это сделано en:Template:Navbox. — Джек (обс.) 07:53, 5 июня 2018 (UTC)
  • Поддерживаю удаление. Если с заголовками смысл смены стилей более-менее понятен, то тут чистая вкусовщина, которая приводит лишь к тому, что при использовании нескольких шаблонов в одной статье начинается разнобой. — putnik 16:55, 5 июня 2018 (UTC)

Контраст полей стиль_чётных стиль_нечётных[править код]

Отдельным пунктом можно обсудить устраивает ли сообщество текущие настройки {{Навигационная таблица}} в части цветов четных/нечетных строк. Были высказаны мнения, что контрастность четных и нечетных полос недостаточна. Ощущает ли такую проблему кто-то еще? Нужно ли делать четные строки темнее? Или, наоборот, все хорошо?

Вот как выглядит сейчас:

Abiyoyo (обс.) 21:07, 4 июня 2018 (UTC)
  • В районе текста различие между чётными и нечётными видно совершенно недостаточно, приходится приближаться к монитору и сильно вглядываться. В пустых местах это видно лучше, так что для корректного примера нужно заполнить текстом всё поле до правого края.
  • Пример 1:
  • Пример 2 - более лучшего разделения чётных и нечётных строк:
  • Пример 3 - Возможно стоит подумать о еще большей разнице между чётными и нечётными строками.
Я не знаю как это видят уважаемые коллеги, по мне так чем больше разница (в разумных пределах) - тем лучше. TenBaseT (обс.) 21:32, 4 июня 2018 (UTC)
Только цвет должен иметь (около)нулевую насыщенность (то есть серым) — гарантировать сочетание по тону, пока не запрещена раскраска шаблонов в разные цвета, невозможно. В примере 3 эквивалентом предложенного в третьем примере цвета (#e6e9ff;) по контрасту с белым является #eaeaea (см. [2] vs [3]) что соответствует:
  • Пример 4 -

--Abiyoyo (обс.) 21:54, 4 июня 2018 (UTC)

  • Во-первых, я вижу непонимание одной вещи. Зебра делается не для того, чтобы вы чётко видели отличие соседних строк. А для того, чтобы разница была настолько минимально заметна, чтобы переход между цветами в принципе улавливался глазом (дополнение: без вглядывания) и можно было отличить, что это не один ряд таблицы. Чем меньше отличие цветов, тем лучше для дизайна, он изящнее. Существующий цвет взят из английского раздела.
    Во-вторых, я уже когда-то экспериментировал с этим значением в сторону утемнения (до #f4f4f4), но впоследствии все свои эксперименты откатил, потому что мне показалось, что «слишком светло», на одном экране, а на другом это выглядело наоборот грязно. Цвет #f0f0f0 из второго примера своей темнотой начинает конфликтовать с самой цветовой схемой (это лучше заметно на этом примере — чётные контрастнее, чем фон заголовков слева, имея показатель контрастности 1,12 против 1,1). Если скажут, что никто вообще не различает рядов в первом примере, согласен на лёгкую корректировку, что-то вроде #f7f7f7 → #f5f5f5 (это будет на 40%). Строго говоря, гайдлайны нам вообще диктуют другие цвета, и показатель контрастности белого и наиболее светлого серого там точно такой же, как тут: #ffffff vs #f8f9fa — 1,05 (1, 2). — Джек (обс.) 04:22, 5 июня 2018 (UTC)
    • Коллега, это зависит от того, с чьей стороны смотреть. Если смотреть со стороны того кто пишет шаблон - может Вы и правы, но если смотреть со стороны читателя Википедии - то зебра делается именно для удобства отличия соседних строк, чтобы читатель справа вдалеке от заголовка чётко видел к какой строке относится та или иная информация. А Википедию мы делаем именно для читателей и для их удобства получения информации. Так что лучше "нестильный дизайн", чем неудобная простому читателю подача информации. TenBaseT (обс.) 04:56, 5 июня 2018 (UTC)
      • Эм. Вообще-то то, что я говорю, я говорю именно в свете подачи читателю информации. И дизайн — это не про стильность, вас обманули. Это именно про подачу информации. Дизайнеры существуют для того, чтобы помогать в ней, а не мешать. Поэтому я и говорю: различие должно быть таким, чтобы позволять глазу отличить ряды, но не больше. Не привлекать излишнего внимания. Это как раз будет мешать подаче информации, делать её неудобной. Или вы думаете, что в английской Википедии у всех другие глаза? — Джек (обс.) 05:09, 5 июня 2018 (UTC)
      • Возможно, я неточно выразился. «чтобы переход между цветами в принципе улавливался глазом» — имеется в виду: без вглядывания. Вглядываться, конечно, не должно быть нужно. — Джек (обс.) 05:13, 5 июня 2018 (UTC)
        • В этом и проблема, я в сегодняшнем дизайне границу конечно улавливаю, но это нужно сильно вглядываться. Причём проверялось на разных компьютерах с разными мониторами - везде одинаково. Как раз в этом и проблема - неудобно пользоваться навигационными шаблонами. TenBaseT (обс.) 05:17, 5 июня 2018 (UTC)
          • Ну не знаю, может дело в зрении. У меня таких проблем не возникало. Притом обратите внимание, что достаточность контрастности тут лучше определять на опыте, а не на субъективной оценке. Мы можем считать, что контрастность слишком мала, если будем специально всматриваться и давать оценку (мне вот тоже показалось так же, как вам, и я предложил изменить значение цвета, когда мы переводили шаблоны на модуль), но если мы не ощущаем проблем при реальном использовании (глаз выцепляет ряды, что бы нам там ни казалось), значит эта оценка неверна. Я не знаю, ваш ли это случай. — Джек (обс.) 05:41, 5 июня 2018 (UTC)
    • > А для того, чтобы разница была настолько минимально заметна, чтобы переход между цветами в принципе улавливался глазом и можно было отличить, что это не один ряд таблицы.
      Да, из этого следует, что показывать разницу на примерах, где строго по одной строке на ряд таблицы, бессмысленно — ты и так понимаешь, где граница рядов. Если бы все ряды имели фиксированное число строк, делать в них зебру имело бы смысл, только если бы в этой таблице были дополнительные колонки (цель — чтобы ты не сбился, когда переносишь взгляд с левых колонок на правые). Следующий пример будет более наглядным (цвета — как сейчас):
— Джек (обс.) 05:03, 5 июня 2018 (UTC)
  • F7 — нормально, F5 — можно, F0 — перебор. — Vort (обс.) 05:05, 5 июня 2018 (UTC)
    • Поддержу вариант с F5. Все примеры слишком контрастны, а на самом деле достаточно лишь самую малость подкрутить контраст. — putnik 17:03, 5 июня 2018 (UTC)
  • Есть ещё проблема с тем, что у некоторых пользователей неверно настроены видеокарта/монитор/ОС и они просто физически не могут различить светло-серый и белый. Если разобраться с причиной, то можно составить для них инструкцию как правильно настроить систему. Это лучше, чем всем подряд ухудшать дизайн. — Vort (обс.) 05:07, 5 июня 2018 (UTC)
    • Vort: пользователь не обязан догадываться о том, что там считают правильным инженеры, да и не может. И он (или она :-)) тем более не может пересадить себе зрительный аппарат разработчика. Скажем, ваш покорнейший прекрасно различает все оттенки приведённой ниже шкалы (благо и экран калиброван, и калибровочный пресет выбран под текущую освещённость) - но примеры 1 и 2 для него совершенно не годны. Либо достаточно контрастные 3 и 4, либо ничего. Лучше белый лист, чем намёк на цвет - некомфортно это. Retired electrician (обс.) 11:28, 5 июня 2018 (UTC)
  • If you cannot see different shades of black at positions 0, 1 and 2... and at the bottom right... different shades of white at 2, 1 and 0 — It's time to calibrate your monitor! — Vort (обс.) 05:34, 5 июня 2018 (UTC)
    • А какая связь тут с обсуждаемой темой ? На Вашем примере я нормально вижу отличие между 0, 1 и 2 фоном. При этом в шаблоне, когда он не просто залит цветом, а заполнен разным текстом (с разной толщиной, цветом и возможно разными языками) - тогда различия становятся менее чёткими, см. примеры выше. TenBaseT (обс.) 05:38, 5 июня 2018 (UTC)
      • Это для того, чтобы исключить случаи, когда пользователю не хватает контраста из-за неправильной работы его оборудования. — Vort (обс.) 06:01, 5 июня 2018 (UTC)
  • 1) Из примера выше на своём мониторе вижу границы 0-1-2. 2) (−) Абсолютно против варианта 4 и 3 — не смотря на желание инженера оставить единственный вариант раскраски навшаблонов (вспоминается: © «Шаг влево, шаг вправо — считается побегом. Прыжок расцениваю как попытку улететь. Стреляю без предупреждения!»), ещё достаточно навшаблонов других цветов (неголубых и светлых оттенков), удовлетворяющих правилам рувики, поэтому светло-фиолетовые и откровенно серые полосы на них смотреться не будут. Мне достаточно существующего варианта, не испортит впечатление от навшаблона и вариант 2. --VladXe (обс.) 06:37, 5 июня 2018 (UTC)
    • Ну вот и я предпочитаю вариант 2 (для загруженных текстом шаблонов). TenBaseT (обс.) 06:54, 5 июня 2018 (UTC)
      • Извольте, цвет фона не должен варьироваться в зависимости от того, загружен шаблон текстом или нет. — Джек (обс.) 07:05, 5 июня 2018 (UTC)
        • Я же объяснял где-то выше, мы не рассматриваем "сферического коня в вакууме". Мы должны отталкиваться именно от загруженных текстом шаблонов, потому что только в таких случаях вообще нужна чересполосица (зебра), именно для того, чтобы ассоциировать текст с конкретным заголовком. А в пустых шаблонах (или заполненных одним словом, как в первом примере Аби) цвет вообще не важен, так как он не несёт смысловой нагрузки. TenBaseT (обс.) 07:14, 5 июня 2018 (UTC)
          • Случаи, когда зебра не нужна (мешает) тоже надо рассматривать. Иначе и чёрно-белая раскраска подойдёт. — Vort (обс.) 07:25, 5 июня 2018 (UTC)
            • Разумеется, поэтому я больше склоняюсь к варианту 2, чем к варианту 4 (или к еще более радикальным цветам). TenBaseT (обс.) 07:28, 5 июня 2018 (UTC)
          • Чересполосица играет сугубо второстепенную, вспомогательную роль. В подавляющем большинстве случаев мы и так видим, что некоторые строки относятся к одной группе, а другие — к другой. При этом излишнее подчёркивание чересполосицы не помогает, а мешает. Например, в текущем виде шаблона кабинета министров Израиля средняя строчка выделена так сильно, что это выделение заставляет думать, что она чем-то отличается от соседних (более важная?). Я уже показал пример с другим шаблоном — здесь как раз тот цвет из варианта 2 агрессивно вмешивается в цветовую схему и перехватывает внимание с групп слева к себе.
            Дизайнеры — не дураки и продумывают, какие должны быть акценты. Акцент на строках в чересполосице должен быть минимален, потому что он сугубо искусственен; выделение не несёт никакой смысловой нагрузки, только зрительную помощь. Сама по себе чересполосица является спорным приёмом в дизайне, многие рекомендуют от неё отказаться. Я согласен на лёгкое отемнение, но на вариант 2 не согласен — это уже порча дизайна. — Джек (обс.) 07:41, 5 июня 2018 (UTC)
  • Вроде бы, чересполосица давно уже вышла из моды, сейчас принято отделять строки друг от друга отступами и выравниванием. Если оставить чересполосицу, смысла увеличивать контрастность я особо не вижу, деление на строки в навшаблонах нужно, чтобы найти ссылку по заголовку, в чём чересполосица не сильно помогает. Например, найдите в строке «Проекция на подвижные оси» «Внешнее кольцо», неужели чересполосица здесь помогла бы?
Совершенно аналогично
  • подвижный
  • объект
  • позволяет исключить
  • гравитационный волчок
  • Экваториальный момент
  • тангаж
  • эллиптично
  • дифференциальных уравнений,
  • колебательный ротор.
Проекция на подвижные оси
  • в первом приближении
  • составляющие гироскопического момента
  • жидкий угол крена
  • Внешнее кольцо
  • погрешности определения курса
  • апериодический прибор
  • Гироинтегратор
  • трансформирует
  • нестационарный суммарный поворот
механической логике
  • кожух
  • искажает
  • параметр Родинга-Гамильтона
  • Штопор
  • Управление полётом
  • прецессионный систематический уход
интеграл от переменной величины
  • неустойчив
  • Система координат
  • системы уравнений
  • периодический подвес
  • циклического интеграла
  • второго уравнения
  • системы уравнений
  • малых колебаний
  • Точность крена
  • угол курса
теории устойчивости движения
  • электромеханическая система
  • апериодический центр сил
  • Астатическая система координат
  • Булгакова
  • колебаниями корпуса
  • периодический интеграл
  • уравнения движения тела
  • проекции на касательную к его траектории.
--Tucvbif???
* 08:17, 5 июня 2018 (UTC)
  • Помогла бы, но самое главное в другом, когда ситуация ровно наоборот и нет отступов между строками, например нужно найти к каком заголовку относится «Управление полётом», что зачастую нетривиально. TenBaseT (обс.) 08:22, 5 июня 2018 (UTC)
  • Назначение навшаблона — помочь найти ссылку на нужную статью. По уже найденной ссылке искать заголовок смысла нет.--Tucvbif???
    *     08:26, 5 июня 2018 (UTC)
  • Что проще: просматривать сплошной список ссылок и по найденной в этом списке ссылке искать заголовок, или сразу перевести взгляд на колонку заголовков и найти нужный?--Tucvbif???
    *     08:33, 5 июня 2018 (UTC)
  • Можно попасть через ссылки на произвольную статью, найти навшаблон и узнать, к какой подгруппе относится эта статья. — Vort (обс.) 08:37, 5 июня 2018 (UTC)
  • Опять же, это — побочный эффект. Задача навшаблона — помочь найти ссылку на другую статью, а не показывать соотношения между понятиями.--Tucvbif???
    *     08:44, 5 июня 2018 (UTC)
  • Вот уж чего сюда не надо добавлять, так это «воздуха». Заглавной со строчками по два слова хватает. — Vort (обс.) 08:37, 5 июня 2018 (UTC)
  • Если «воздух» добавляется не за счёт снижения плотности подачи, а за счёт избавления от рамочек и полосочек — что в этом плохого?--Tucvbif???
    *     08:48, 5 июня 2018 (UTC)
  • Рамку проще распознать, поэтому она позволяет достичь бо́льшей плотности, чем разделение пустыми пространствами. — Vort (обс.) 09:02, 5 июня 2018 (UTC)
  • Давайте померяемся:
Почему мал гироскоп?
Совершенно аналогично
  • Подвижный
  • Объект
  • Позволяет исключить
  • Гравитационный волчок
  • Экваториальный момент
  • Тангаж
  • Эллиптично
  • Дифференциальных уравнений
  • Колебательный ротор
Проекция на подвижные оси
  • В первом приближении
  • Составляющие гироскопического момента
  • Жидкий угол крена
  • Внешнее кольцо
  • Погрешности определения курса
  • Апериодический прибор
  • Гироинтегратор
  • Трансформирует
  • Нестационарный суммарный поворот
механической логике
  • Кожух
  • Искажает
  • Параметр Родинга-Гамильтона
  • Штопор
  • Управление полётом
  • Прецессионный систематический уход
интеграл от переменной величины
  • Неустойчив
  • Система координат
  • Системы уравнений
  • Периодический подвес
  • Циклического интеграла
  • Второго уравнения
  • Системы уравнений
  • Малых колебаний
  • Точность крена
  • Угол курса
теории устойчивости движения
  • Электромеханическая система
  • Апериодический центр сил
  • Астатическая система координат
  • Булгакова
  • Колебаниями корпуса
  • Периодический интеграл
  • Уравнения движения тела
  • Проекции на касательную к его траектории

--Tucvbif???
* 09:28, 5 июня 2018 (UTC)

  • Против избавления от рамок. По основному предложению: текущий цвет, моему мнению, и правда слишком светлый, затемнить пожалуй не только можно, но и нужно. Не против варианта 2, а темнее уже перебор.--Luterr (обс.) 11:22, 5 июня 2018 (UTC)
  • Может Лебедева попросим порекомендовать нам цветовую схему для нав. шаблонов? :-) VlSergey (трёп) 13:55, 5 июня 2018 (UTC)
    • Может существуют научные работы по этой проблеме? Или все дизайнеры выбирают цвета строк «на глаз»? — Vort (обс.) 14:09, 5 июня 2018 (UTC)
    • Уже когда-то обсуждали у других уважаемых дизайнеров. Правда итоговый вариант там, думаю, никого не устроит, но чересполосицы там нет (за что я бы тоже лично выступил, если это обсуждать) :-) stjn 14:12, 5 июня 2018 (UTC)
  • Я вообще не считаю обязательным делать зебру (википедия - единственный сайт, на котором я её видел, вообще странная идея - и без зебры видно, что разные строки - разные строки), но если уж её делать, то более контрастно. Первый вариант страшно плох, 2 и 4 - норм, хотя можно и ещё чуть поконтрастнее. MBH 14:35, 5 июня 2018 (UTC)

Предварительный итог[править код]

По первому вопросу было возражение, но затем участник его снял. Некоторые участники были чуть осторожнее, чем исходное предложение. Не было приведено примеров осмысленного использования кастомных значений данных параметров. Таким образом есть аргументированный консенсус за отказ кастомизации по полям /стиль_(не)?четных/ и стиль_тела. По порядку работ ы с ними предлагается следующее: допускается исключение этих параметров, если нет явных, сильных оснований их использовать. то естье их надо либо убирать вручную, либо, если ботами, то проверять, нет ли там каких-то нетипичных значений, которые имеют хорошие причины появиться, а именно значений, не связанных с цветом (такое гипотетически возможно). Если после исключения параметров, ничего осмысленного не останется, то можно будет их закрыть на уровне navbox.

По второму вопросу мнения разделились. Несколько участников считают, что чресполосица не нужна вовсе, но это выходит за рамки поставленного вопроса, кроме того были возражения. Поэтому этот аргумент не рассматривался, особенно с учетом того, что как минимум двое занимают позицию «или нет чресполосицы вовсе или сильный контраст». Вместе с тем были засчитаны голоса сторонников полного убирания чресполосицы за значение ff.

По конкретным значениям подводить итог по аргументам едва ли реально — мнений много, они более связаны с индивидуалными особенностями. аргументы тут не помогают. Поэтому были посчитаны средние значения: 

Джек: #f7f7f7 .. #f5f5f5 (med: f6 = 246)
Vort: #f7f7f7 .. #f5f5f5 (med: f6 = 246)
putnk: #f5f5f5 (med: f5 = 245)
Retired electrician: #eaeaea | n/a  (med: ea = 234)
<s>VladXe: #f7f7f7 .. #f0f0f0 (med: f3..f4 = 243,5)</s>
VladXe: #f7f7f7 (med: f7 = 247)
TenBaseT: #f0f0f0 (med: f0 = 240)
Tucvbif : n/a ≈ ff = 255
Luterr: #f0f0f0 (med: f0 = 240)
stjn: n/a ≈ ff = 255
MBH: #f0f0f0 ..#eaeaea | n/a (med: ed = 237)

Total:
234, 237, 240, 240, 245, 246, 246, 247, 255, 255 (med = 244.5 = #f4f4f4.. #f5f5f5)

Итого средним вариантом оказалось значения #f4f4f4..#f5f5f5. Одно из них следует использовать как базовое. Следует установить его и посмотреть. Допускается отклонение на пару пунктов вверх-вниз, если будут технологические причины к тому. Допускается незначительное (на пару пунктов) смещение в сторону синего спектра по аналогии с design guide. Эти детали инженеры и администраторы могут решить в рабочем порядке. Если после внесения изменений будут выявлены явные проблемы (напр. в виде массовых жалоб пользователей, большого недовольства и т. п.) то не ранее чем через месяц можно будет переоткрыть обсуждение.--Abiyoyo (обс.) 11:55, 9 июня 2018 (UTC)

  • Возражаю, написано ж: достаточно существующего, поэтому VladXe: #f7f7f7 (med: f7 = 247). --VladXe (обс.) 12:07, 9 июня 2018 (UTC)
  • Ну нет, простите, выбирать цвет усреднением весьма праздных оценок — это слишком. Путник сказал совершенно верно: «Все примеры слишком контрастны, а на самом деле достаточно лишь самую малость подкрутить контраст». #f1f1f1 будет порчей дизайна, ломкой цветовой схемы, как и #f0f0f0, — я много раз обосновал, почему. — Джек (обс.) 12:08, 9 июня 2018 (UTC)

Мнение VladXe поправил с учетом его замечание и пересчитал итоговое значение. Дальнейшие корректировки делать не буду, чтобы не началась торговля и игра на повышение/понижение.--Abiyoyo (обс.) 12:29, 9 июня 2018 (UTC)

  • Я думаю что если бы в обсуждении вопроса участвовали не только пользователи Дискорда, то результаты сместились бы в сторону более сильного затемнения, но что есть - то есть. Раз уж не пришли, значит мало кого интересует. Действуйте. TenBaseT (обс.) 07:23, 10 июня 2018 (UTC)

Итог[править код]

Были сделаны замечания, они были по возможности учтены в тексте предварительного итога. Возможно, результат в части конкретных значений цвета не устроит всех, но вопрос явно не стоит того, чтобы из-за него дальше ломать копья — типичный en:WP:BIKE. Что-то более-менее компромиссное нашлось, и ладно. Поэтому остановимся на том, что было зафиксировано в предварительном итоге.--Abiyoyo (обс.) 23:04, 11 июня 2018 (UTC)

О повышении качества статей и обоснованности[править код]

Уважаемые коллеги, Вы хорошо знаете, как часто информация в статьях обоснована ссылками на авторитетные, проверяемые и доступные источники; и к скольки конфликтам это приводит. Вы также знаете, что статьи (которые можно значительно улучшить) порой выставляют на удаление - а для начинающего неопытного участника это немалый стресс; он (порой обладая хорошими знаниями, но не обладая опытом работы в Википедии) может покинуть проект (пример - ктн Федорович). Предлагаю: для повышения качества содержания статей; улучшения обоснованности приводимой там информации; и для снижения риска конфликтов - выполнить работу по облегчению доступа к авторитетным, проверяемым и доступным источникам, в сочетании с облегчением работы по оформлению ссылок на них. Пример того, как это можно сделать (вероятно, не вполне идеальный) приводится в статье, для "Большой российской энциклопедии" (свёрнутая таблица).

Такую помощь участникам, как (вариант) свёрнутая таблица по Большой Российской Энциклопедии, можно включить в следующие разделы статей Википедии:

Возможно, кто-то скажет: "Эта информация в Википедии есть, зачем огород городить?" - и будет 100% прав (как опытный, осведомлённый участник). Прошу посмотреть небольшое обсуждение удаления статьи МРОТ в РФ. Ни выставлявший на удаление ("нет значимости"), ни автор - даже не пробовали найти эту статью в авторитетном, проверяемом и доступном источнике, где она была. Если у каждого участника будут под рукой ссылки на авторитетные источники, плюс возможность без больших затрат труда и времени сделать ссылку (не ломая голову над тем, сколько страниц в томе, какой у него ISBN, кто редактор и т.п.) - они будут это делать, качество статей повыситься, а число конфликтов уменьшится.

Предлагаю сделать таблицы, аналогичные таблице для БРЭ (или более подходящие средства) - для третьего издания Большой медицинской энциклопедии; для энциклопедии по безопасности и гигиене Международной Организации труда МОТ (вверху есть переключение на русский язык); для многих других авторитетных источников - и поместить их в места, где они будут под рукой, востребованы (примеры приведены выше). Спасибо! AlexChirkin (обс.) 15:30, 3 июня 2018 (UTC)

  • Проблема в том, что для Википедии нет авторитетных абсолютно по всем вопросам источников. Фил Вечеровский (обс.) 17:47, 3 июня 2018 (UTC)
    • Вы правы. Может быть, имеет смысл сделать более удобным доступ к тем, которые есть. Честное слово, я сам наткнуля на БСЭ онлайн - недавно и случайно... Вежливо "ткнуть носом" новичка в хорошо оформленный список авторитетных источников, да и с крайне наглядными примерами оформления ссылок на них - может быть полезно, мне кажется. — Эта реплика добавлена участником AlexChirkin (о • в)
  • Что кто-то даже не пытается искать - это другая проблема. Даже если вы им на личной странице список приведёте, они не будут смотреть. Igel B TyMaHe (обс.) 19:22, 3 июня 2018 (UTC)
    • Видете ли, если они не будут смотреть и на своей СО (к примеру - в шаблоне Hello) - это может быть полезно для выявления мотивов поведения: неопытный добросовестный участник, или пренебрегающий правилами участник. Даже в этом случае - какая-то польза может быть. — Эта реплика добавлена участником AlexChirkin (о • в)
  • Если "авторитет" не осиливает найти и оформить источник в статье - нужен ли этот мнимый "авторитет"? - DZ - 02:30, 4 июня 2018 (UTC)
  • Обычная модель поведения новичка. «Мне интересна тема X → пишу по ней статью → статья попала на КУ → ищу источники». Необходимо всячески доносить мысль о том, что последовательность должна быть обратной: начинать нужно с «ищу источники». Далее с опытом приходит способность находить в источниках интересную тему. Наилучшая иллюстрация и пример для новичков: общее состояние статей в проекте. Вот здесь, увы, большая проблема. Новичок с вероятностью >50% нарвется на статью без источников и попыток их искать. - Saidaziz (обс.) 05:26, 4 июня 2018 (UTC)
    • Необходимо всячески доносить мысль о том, что последовательность должна быть обратной - Более того, это уже сделано в ВП:СТАРТ. Только вот кто из новичков дает себе труд прочитать этот текст? --Grig_siren (обс.) 08:08, 4 июня 2018 (UTC)
      • В ВП:СТАРТ, в конце раздела "Шаг 7. Укажите в статье источники информации", как раз приводится ссылка на список авторитетных источников - очень хорошее решение. Если ссылки туда будут и в Инкубаторе; и со страниц о значимости (куда, как совершенно справедливо заметил Saidaziz, легко попадают новички), и других мест с указаниями новичкам - это будет полезно. Но желательно бы предельно подробно объяснить ему, как оформлять ссылку - то, что это легко делаете Вы не значит, что это легко сделать другим. Ниже Abiyoyo пишет: "делать источники более удобными к использованию ... для БРЭ, есть, например, шаблон {{БРЭ}}". То есть - не надо нагружать участников, особенно новеньких, заполнением всех полей шаблонов, типа ISBN для тома N ... энциклопедии. И вынужден добавить - к любому такому шаблону необходимо давать предельно наглядное описание, рассчитанное на полного чайника - как им пользоваться. Ещё, Grig_siren пишет: "вот кто из новичков дает себе труд прочитать". Хорошо, согласен. Ленивые, своё время стараются сберечь. Потом из-за этого конфликты, проблемы и т.п. Встречный вопрос - патрулирующие, по определению - не новички. Вы сталкивались со случаями, чтобы при патрулировании статьи, которая есть в БРЭ, БСЭ и др., и в которой нет ссылок на эти авторитетные источники, кто-то из патрулирующих добавил бы ссылку туда - в начале (патрулируемой) статьи? Не часто? А почему? Может быть - патрулирующему жалко тратить время на выяснение того, сколько страниц в томе N ... энциклопедии, и какой у этого тома ISBN? А ведь если при патрулировании маленькой статьи (которая есть в, например, БРЭ, стараться добавлять туда ссылку - это станет примером для других; и это даст возможность читателям получить информацию (когда статья в Википедии маленькая). Грубо говоря - можно: сделать средства для облегчения вставок ссылок на авторитетные источники; потом можно будет воспитывать участников - своим примером; примером поведения патрулирующих и других опытных участников. Пробегитесь по статьям Википедии о регионах РФ - похоже, их часто писали на основе БСЭ или БРЭ - и где ссылки на эти источники онлайн? — Эта реплика добавлена участником AlexChirkin (о • в)
        • В ВП:СТАРТ, в конце раздела "Шаг 7 ... - вот видите, как выясняется даже опытные участники не дают себе труд прочитать этот текст полностью. Потому что речь в данном случае идет о разделе "Шаг 3. Соберите источники информации", в котором явно прописано "Лошадь нужно запрягать впереди телеги, а о источниках думать прежде написания основного текста." --Grig_siren (обс.) 11:44, 4 июня 2018 (UTC)
  • Если бы существовал набор авторитетных источников по всем темам — Википедия была бы не нужна. А так — у нас есть Проект:Словники, смысл его немножко другой, но в обратном направлении его тоже можно использовать.--Tucvbif???
    *     07:13, 4 июня 2018 (UTC)
  • Идея делать источники более удобными к использованию — правильная. Обычно ссылки на энциклопедии оформляются при помощи специальных шаблонов. Их уже сделано немало, они собраны в категории К:Шаблоны:Справочники и энциклопедии. Конкретно для БРЭ, есть, например, шаблон {{БРЭ}}. Лучше и проще пользоваться им, а не вызывать каждый раз полный {{книга}}. Для БМЭ и многих других изданий готового шаблона может не быть. Это значит, что тут нужно просто править смело и делать их. Расширять страницу ВП:ИИН можно и нужно (опять же, править смело), хотя выходные данные для томов проще хранить, как сказано в шаблонах. А вот дать со страницы ВП:ИИН ссылку на шаблоны соответствующих изданий было бы неплохо. Кстати, титанический труд по систематизации списка энциклопедий выполнил участник Chronicler, см. ВП:ЭЭ. Его можно развивать и делать более доступным.--Abiyoyo (обс.) 08:03, 4 июня 2018 (UTC)
    • Вы меня правильно поняли - не будут новички тратить время на выяснение того, в каком томе БРЭ сколько страниц, какой у него ISBN и т.п.; шаблоны типа {{БРЭ}} - облегчают трудозатраты. Что я пытаюсь предложить (бестолково формулируя сви мысли): к списку энциклопедий дать (к каждой - индивидуально) шаблоны (Вы привели) или таблицы (как я дал для БРЭ), облегчающие аккуратное оформление ссылок + предельно понятные подсказки - как это использовать (пример) - и потом давать ссылки на это из инкубатора и др., как можно чаще. AlexChirkin (обс.) 11:29, 4 июня 2018 (UTC)
  • Предлагаю: для повышения качества содержания статей ... выполнить работу по облегчению доступа к авторитетным, проверяемым и доступным источникам, - все бы ничего, но если новички сами не заглянут в предлагаемое хранилище ссылок - то ничего в нашей и их жизни не изменится. Так что надо не столько создавать копилки хороших источников, сколько приучать народ к мысли о жизненной необходимости источников. --Grig_siren (обс.) 08:08, 4 июня 2018 (UTC)
  • у нас есть же шаблон {{внешние ссылки}}. Не годится разве? ShinePhantom (обс) 08:34, 4 июня 2018 (UTC)

И снова о колонках примечаний[править код]

Восстанавливаю на форум предложений, а не на общий, где тема была изначально, так как лучше подходит по смыслу. — Джек (обс.) 15:38, 23 июня 2018 (UTC)

Два года назад я предложил, чтобы шаблон "примечания" по дефолту выводил не одну колонку, т.к. в явном большинстве случаев это облагородит вид статей, в которых никаких дополнительных параметров в шаблон не передано (в таком случае примечания сейчас выводятся в одну колонку, узкой полосой вдоль левого края страницы, оставляя огромное белое поле справа). Поступил ряд нерелевантных возражений, поэтому предложение не было принято; с тех пор я неплохо набил себе правок в ОП, вручную вставляя в шаблон примечений |2, |3, |4, вплоть до |6, уродливые статьи остаются уродливыми, кому от этого стало лучше - непонятно. Предлагаю вернуться к обсуждению этого предложения, тем более, что были найдены ещё две альтернативы указанию числа колонок

  • указание ширины столбца вместо числа столбцов, например width=30em. Автоматически создаёт число колонок, зависящее от ширины экрана устройства, с которого просматривается статья; больше экран - больше колонок.
  • вот такой инструмент, делающий примерно то же самое, подключаемый разработчиками в конкретном разделе.

MBH 14:43, 11 апреля 2018 (UTC)

  • Я полагаю, установка конкретного числа колонок — устаревшее решение, не учитывающее то, что Википедию просматривают с экранов разной ширины, а в последнее время их диапазон сильно расширился. А вот последнее решение — автоматический подбор количества колонок в зависимости от ширины экрана, с исключением случаев, когда примечаний слишком мало, чтобы включать для них колонки, и случаев, когда ширина задана вручную, — это то, что было введено в английском разделе в сентябре 2017 года и было бы разумно ввести у нас. — Джек (обс.) 14:55, 11 апреля 2018 (UTC)
    • Могу сказать, что решение, основанное на втором варианте, при условии, что есть по меньшей мере десять примечаний, используется в другой википедии долго и успешно. Игорь (обс) 14:57, 11 апреля 2018 (UTC)
    • Небольшое уточнение: в enwiki это введено не в сентябре, а в начале июля. Причём простой вариант |30em там очень широко использовался (де-факто в статьях) к тому моменту уже несколько лет, теперь же автоматический подбор (для 10 и более сносок) включён по умолчанию, т.е. задавать параметры вручную в статьях вообще не требуется. Вот уже скоро год как это там внедрено, а ruwiki опять отстаёт даже не на один этап, а на два: до сих пор сплошь и рядом (по незнанию) лепят константу колонок, от которой надо вообще избавляться. — Mike Novikoff 19:40, 11 апреля 2018 (UTC)
      • Вычистить бы это ботом… Хотя бы что-то. |2? |3? Совсем не факт, что есть какая-то логика в их проставлении; скорее — у кого-то больше экран, поэтому он поставил 3 колонки, у кого-то меньше — поставил 2. Дальше, положим, пойдут {{sfn}}'ы, но и их стоило бы заменить на что-то типа |20em. У нас 84 528 случаев использования {{примечания|2}} и 9617 — {{примечания|3}} (дальше — меньше тысячи), что не радует. — Джек (обс.) 21:27, 11 апреля 2018 (UTC)
        • Да, именно так. Логики никакой нет, да и в документацию вообще не смотрят, ставят просто |2 или |3, глядя на один свой экран. В последний год я вручную заменяю это на |30em (иногда |35em), возражений обычно не бывает (иногда возражают из-за неосведомлённости, соглашаются после ссылки на документацию). Но вручную это займёт ещё много лет, лучше бы ботом. — Mike Novikoff 21:55, 11 апреля 2018 (UTC)
        • 95 тысяч правок для исправления поведения шаблона, которое при желании можно подавить через код, — это совершенно неприемлемо. stjn 13:54, 12 апреля 2018 (UTC)
          • +1 задача в бесконечный реестр «надо сделать и замусоривает статьи и сбивает людей с толку, но единовременно отвлечёт внимание, поэтому будем вычищать вместе с другими правками, чтобы, возможно, добить через 10 лет вручную». Реквестирую хранение этого реестра где-нибудь на страницах ВП для осознания, так сказать, масштабов. — Джек (обс.) 14:11, 12 апреля 2018 (UTC)
  • Первый вариант имеет всё те же возражения, по которым отклонили изначальное предложение.
    Второй вариант («инструмент»), созданный разработчиками, не «подключается в конкретном разделе», а может быть использован в форме <references responsive />. Он решает одну проблему — колонки в примечаниях будут использоваться, только если выводимых примечаний больше 10. По умолчанию колонки получаются шириной в 30em.
    На мой взгляд, было бы нормально реализовать второй вариант вместе с первым, но проблемы первого остаются: в width можно засунуть любые значения, 235px, 23ex, 25em, 18rem, 25vw и т. п. и это всё будет работать. По-моему, это неудобно ни редакторам, ни техникам: вместо одного вида значений получается десять видов значений, и все их надо будет поддерживать в дальнейшем, даже если column-width вдруг когда-нибудь морально устареет.
    По-хорошему, количество колонок 2, 3 и 4 надо заменять на что-то вроде «макс», «ср» и «мин». Должно быть какое-то простое множество значений, которое будет продемонстрировано в документации шаблона и которым смогут пользоваться простые участники. Должно быть и максимальное количество колонок (наверное, 4), чтобы 10 примечаний были читаемы и не превращались в ряды по 2 примечания на широких мониторах. Может быть, должен быть обход этого ограничения для {{sfn}}, хотя в этом я не уверен (что этот обход не будет использоваться не по назначению). stjn 15:16, 11 апреля 2018 (UTC)
    • Всё просто: <references responsive> и никаких гвоздей. Плюс поддержка |##em и |1 для редких особых случаев (в документации подчеркнуть, что случаи эти очень редкие). Всё остальное — лишнее. Думать тут незачем, «всё уже украдено», надо просто признать общемировую практику и следовать ей. — Mike Novikoff 21:55, 11 апреля 2018 (UTC)
      • Я про этот вариант и говорю, просто его 1) не объяснить просто так редакторам, все эти ваши разницы между 235px, 23ex, 25em, 18rem, 25vw в сравнении с вашим вариантом, 2) при необходимости использовать тот же {{sfn}} или просто желании сделать колонки поменьше на своём экране значения будут ставить совершенно на глазок (я знаю — я в одной ХС так же и поставил).
        Ваше преклонение перед «мировой практикой» отдельно взятого раздела мне в который раз не интересно. Как минимум, колонки шириной меньше 25em растягиваются на широких экранах уже совершенно неприлично, и вариант «мировой практики» т. н. «Википедии» нужно модифицировать, чтобы он не давал ошибок при нахождении на камень (русских википедистов). stjn 13:53, 12 апреля 2018 (UTC)
        • Да, «на камень» тут недавно приключилось, один раз за год. Ставлю это я, значит, 35em вместо |2, как обычно, через пару дней встречаю молчаливое непонимание. Ладно, бывает. Разъясняю им. Обычно на том и заканчивается благополучно, а тут вдруг бац: 20em! Вот о чём люди вообще думают? Но это, повторюсь, один раз за год такое. Недопонять и абьюзить, в принципе, что угодно можно. — Mike Novikoff 14:40, 12 апреля 2018 (UTC)
          • Неуверен, что лишний раз стоит людям давать возможность «недопонять и абьюзить». Вот и тут на самых широких экранах у человека будут 6 колонок, 7 колонок. С такой реализацией, несмотря на все плюсы предложения, это кошмар. С нынешними 7-колоночниками хоть людям можно показать, как это выглядит на экранах поменьше, и сказать «исправляйте». stjn 14:46, 12 апреля 2018 (UTC)
            • Кошмар, разумеется. 20em на FullHD — это 6 узких колонок (и ведь ни одного sfn!). Но кошмар не столь ужасный: на экране шириной 1152px колонок только три (ПДН: вероятно, они этого и хотели?), что тоже много и незачем, но можно и стерпеть. — Mike Novikoff 15:16, 12 апреля 2018 (UTC)
              • Не понимаю: 23em [4] (как раз семь колонок на моём мониторе) - «так надо», а 20em - уже кошмар? А сколько надо-то? Тут лучше бы заранее договориться. Retired electrician (обс.) 15:30, 12 апреля 2018 (UTC)
                • Ну это sfn’ы, короткие строчки. От этого и зависит. Смысл в том, чтобы как можно больше строк влезли без лишних переносов: это и аккуратнее, и меньше общий размер прямоугольника, занимаемого секцией «Примечания». (У меня выглядит так). — Mike Novikoff 16:02, 12 апреля 2018 (UTC)
      • Апдэйт некоторый: скрестить ужа с ежом вряд ли получится. При <references responsive />, как выяснено экспериментальным путём, невозможно сохранить автоматическое отсутствие колонок при наличии указанной ширины (браузеры этого не поддерживают, выше по DOM указанные колонки перекрывают ниже указанные).
        В английском разделе намеренно отключают автоматические колонки, если ширина указана пользователем, для нас будет абсолютной ошибкой последовать такому дурному примеру. Моё предложение про набор заданных значений, в этом плане, приобретает (для меня, конечно же) только больший смысл, потому что если через второй вариант невозможно убрать колонки у 10 сносок и менее, то он ничем не лучше нынешнего. stjn 15:09, 15 апреля 2018 (UTC)
  • Пусть будет по дефолту второй, адаптивный вариант. Если вдруг в конкретной статье он покажется корявым - можно в ней и исправить. Retired electrician (обс.) 16:34, 11 апреля 2018 (UTC)
  • За адаптивный вариант, и за избавление от всех |2, |3 по крайне мере для основных примечаний. Примечания других групп могут использоваться в таблицах, надо быть аккуратнее. Избавиться можно либо ботом, либо просто заставить шаблон игнорировать эти параметры. — Алексей Копылов 22:31, 11 апреля 2018 (UTC)
  • Касаемо |2 и |3 — сам регулярно и активно пользуюсь, могу подтвердить все, что по этому поводу написано: цифра ставится «на глазок», исходя из своего видения в данный момент. Что, конечно, неправильно, не учитывает других экранов, не поддается поддержке (Волшебное число) и может даже быть поводом к войнам правок (хотя это, наверное, ближе к теории). Я против первого предложения (|30em), так как оно в целом, хоть и в меньшей степени, повторяет все недостатки популярного сейчас варианта (наши колонки при уменьшении ширины экрана также «плавают» при постоянном их количестве). Второй вариант (адаптивное число колонок при 10+ рефах) я поддерживаю, так как «и овцы целы, и волки сыты». Однако, думаю, следует также учесть предложение коллеги Mike Novikoff об оставлении возможности жесткого задания колонок (|1 или |#em) для «особых случаев». Я согласен и с тем, что, в случае принятия, шаблон {{примечания}} в статьях надо будет ботом привести в надлежащий вид. — Aqetz (обс.) 06:13, 12 апреля 2018 (UTC)
  • Коллеги, а чем не устраивает текущий вариант? Я, например, если в статье больше 10 примечаний, сознательно ставлю 2. Кому нужно, ставят 3 или 4. Я не вижу проблемы. Если что-то менять, то добавить в шаблон расчёт количества колонок в зависимости от количества примечаний. Возможно, задать по умолчанию 2, но не запрещать участникам вручную ставить количество колонок в примечаниях или игноровать этот параметр. Oleg3280 (обс.) 07:21, 12 апреля 2018 (UTC)
    • Экраны бывают разной ширины. Даже у меня одного на столе не такой, как в кармане. Всегда ваш, Кэп. :-) — Mike Novikoff 07:50, 12 апреля 2018 (UTC)
  • А обсуждаемая чудо-сворачивалка вообще длину примечаний учитывает? Из описания не понял. В одной статье (написана по трём монографиям) — сплошные sfn’ы, в другой (по куче разных статей) — сплошные полные библиографические ссылки с длинными названиями статей и источников. Их же нужно по-разному обрабатывать. AndyVolykhov ↔ 13:35, 12 апреля 2018 (UTC)
    • Для коротких примечаний типа {{sfn}} как устанавливали значение вручную, так будем делать и дальше, только указывать желательно не количество колонок, а ширину (скажем, {{примечания|20em}}). — Джек (обс.) 13:48, 12 апреля 2018 (UTC)
      • В идеале хорошо бы и это автоматизировать, считать там среднюю длину примечаний или что-то такое. Или хотя бы найти какую-то стандартную рекомендуемую длину хотя бы для sfn’а, а то в «емах» мало кто считать умеет. AndyVolykhov ↔ 14:04, 12 апреля 2018 (UTC)
    • Здесь, как уже выше было сказано, стоит предусмотреть опции |1 (для долгих текстовых комментариев), «рыхло» (для линков) и «плотно» (для сфн-ов), и один из этих двух последних взять за дефолт. Наверное, по умолчанию всё же «рыхло». Retired electrician (обс.) 15:21, 12 апреля 2018 (UTC)
  • Не знал про инструмент и про возможность указывать не количество колонок, а ширину. (+) За то, чтобы автоматизировать и унифицировать. Что касается ботозамены, то явно задаваемое число колонок - безусловное зло, и его нужно вычищать ботом. А вот там, где была явно задана ширина столбца, нужно оставлять как есть.--Kaganer (обс.) 22:37, 21 апреля 2018 (UTC)
  • но проблемы первого остаются: в width можно засунуть любые значения, 235px, 23ex, 25em, 18rem, 25vw и т. п. и это всё будет работать - это не проблема, а удобство подгонки под ширину рефов конкретной статьи, убирать это не нужно. Максимальное количество колонок - тоже плохая идея, в статьях с сфн оптимально 6-8 колонок. Все эти "макс, мин, ср" - плохая и непонятно зачем нужная идея. MBH 00:31, 22 апреля 2018 (UTC)

Предварительный итог[править код]

1. Можно наблюдать консенсус за использование механизма автоматического разбиения списка примечаний на колонки при количестве примечаний от 10 aka адаптивных примечаний. На Фабрикатор будет подан соответствующий запрос.

2. Возникли разногласия вокруг реализации совместимости этого механизма с возможностью указания ширины колонки: одни предлагают ничего не изобретать и отключать автоматическое разбиение при указанной ширине, другие предлагают ввести набор стандартных значений типа мин, ср, макс. В отличие от варианта с указанной шириной, это позволит сохранить возможность отключения разбиения на колонки при количестве примечаний до 10. Также это будет удобнее редакторам и упростит возможность поддержки. Эти аргументы представляются в целом разумными.

Сохранение возможности указания ширины мотивируется необходимостью подгонки под ширину примечаний конкретной статьи. Я бы также добавил сохранение совместимости с английским разделом и сохранение возможности включить колонки для примечаний, даже если их меньше 10 (например, в специальных местах).

Таким образом, ничего не мешает совместить оба варианта, предлагая редакторам как базовый вариант указывать особый параметр для узких примечаний, типа {{sfn}}, и для широких, типа комментариев (предлагаю такие значения и использовать: узкие и широкие), но оставляя возможность указания ширины в явном виде. Я поговорил с основным сторонником варианта со стандартным набором параметров, и по этому вопросу удалось достигнуть согласия.

3. Есть консенсус, что указание заданного числа колонок неприемлемо, 2 или 3 колонки участники выбирают как бог (или размер экрана) на душу положит. Таким образом, действие этих параметров будет отключено, Викификатор будет их постепенно убирать, также вместе с другими правками это могут делать боты. 4 колонки и более будут рассматриваться шаблоном как значение узкие, такие значения также могут автоматически заменяться. Работоспособность значения 1 будет сохранена.

4. Насчёт ограничения сверху на число колонок консенсуса не достигнуто, этот вопрос предлагается обсудить позже.

5. В сухом остатке получается такая конфигурация:

  • {{примечания}} — стандартные адаптивные примечания (ширина — 30em);
  • {{примечания|узкие}} — узкие адаптивные примечания (ширина — 20em);
  • {{примечания|широкие}} — широкие адаптивные примечания (ширина — 40em);
  • {{примечания|ширина}}, где ширина — значение, типа 30em, — неадаптивные примечания заданной ширины;
  • {{примечания|1}} — примечания всегда в одну колонку.

— Джек (обс.) 15:38, 23 июня 2018 (UTC)

  • Хороший предытог. Только непонятно какие величины могут использоваться, только em или весь зоопарк? Викизавр (обс.) 15:57, 23 июня 2018 (UTC)
    • Следует использовать em, как связанный с кеглем. Техническое ограничение вводить не вижу смысла — я ни разу на практике не видел, чтобы кто-то использовал другие величины (поиск ничего не находит, хоть и не успевает обойти все страницы), а ввод ограничения потребует добавления сложного алгоритма анализа строки. При необходимости оно может быть введено. — Джек (обс.) 16:47, 23 июня 2018 (UTC)
  • А проблема, когда из-за примечания|2 или |3 или |XXem образуется огромный кусок белого пространства, будет решена? (напр. Сеута (Синалоа), Итабаси, Ракальмуто, Нойберг-им-Бургенланд) X0stark69 (обс.) 18:38, 23 июня 2018 (UTC)
    • Присоединяюсь к вопросу. — VladXe (обс.) 19:56, 23 июня 2018 (UTC)
    • В подавляющем большинстве таких случаев (когда из-за карточки раздел примечаний уползает вниз) примечаний меньше 10, и они выстраиваются в колонки, хотя не должны. Соответственно, при адаптивных примечаниях они выстраиваться в колонки перестанут, и раздел уползать вниз не будет (уползает он, только если примечания поделены на колонки). — Джек (обс.) 20:20, 23 июня 2018 (UTC)
      •  Джек — плохое решение: есть редакторы, которые, которые полностью перешли на Ш:sfn в статьях (даже стабах), где все сноски короткие, многоколоночное отображение сносок показано начиная с 4 сносок — представьте статью с 9(!) записями типа Фамилия, год, стр. в одну колонку. Можно добавить ключ |sfn (или |короткие) для такого случая? (адаптивное примечание с уменьшенным порогом начала адаптации)? Причём примечания лучше сделать узкими по умолчанию. — VladXe (обс.) 07:07, 2 июля 2018 (UTC)
        • В этом есть какая-либо реальная проблема? stjn 17:13, 3 июля 2018 (UTC)
          • Большое белое пространство справа от сносок в Примечании. Сейчас параметры |2 — |4 позволяют компактно разместить короткие сноски в количестве от 4 до 9, после предполагаемого изменения этого сделать будет нельзя. — VladXe (обс.) 20:37, 3 июля 2018 (UTC)
            • Есть ли проблема в «большом белом пространстве», когда примечания умещаются в полэкрана? У нас каждый любит сидеть настраивать оформление страниц под себя, но так ли важно в небольших статьях иметь примечания в 4 колонки? stjn 22:00, 3 июля 2018 (UTC)
              • Четыре — это много, но 2-3 колонки по 4-5 слов смотрятся эстетичнее, чем одна такая же. Просто посмотрите на 6 коротких сносок в один столбец и увидите, насколько нерационально используется экранное пространство при соотношении сторон экрана 16:9. — VladXe (обс.) 22:26, 3 июля 2018 (UTC)
                • Границу, после которой примечания могут выстраиваться в колонки, настроить мы не можем. Даже если бы и могли, идея, что 6 коротких примечаний в один столбец представляют собой какую-то реальную проблему, спорна (чем тогда это принципиально отличается от 6 более длинных примечаний, которые тоже могут оставлять белое пространство справа?). Участники высказывались за автоматическое принятие решения о том, нужны ли колонки, исходя из того, что, когда примечаний меньше 10, они не нужны. Вы можете вручную включить колоночность, если считаете это необходимым, для того и вводится возможность задавать ширину вручную ({{примечания|20em}}). Надеюсь, это снимает ваши вопросы. — Джек (обс.) 23:26, 9 июля 2018 (UTC)
    • @X0stark69: Решена уже сейчас. После перехода на новые примечания ничего не сломается. — putnik 05:07, 4 июля 2018 (UTC)
  • Я не понял, что значит адаптивные/неадаптивные. Будет ли разница между {{примечания|широкие}} и {{примечания|40em}}? — Алексей Копылов 19:53, 23 июня 2018 (UTC)
    • В одном случае примечания будут становиться одноколоночными, если их меньше 10 (и многоколоночными, если их больше 10), в другом случае всегда будут отображаться разбитыми (что не всегда оптимально). stjn 20:00, 23 июня 2018 (UTC)

Итог[править код]

Насколько я понимаю, все проблемы решены, возражений нет. Подождём ещё пару дней, и можно приступать. — Джек (обс.) 05:29, 11 июля 2018 (UTC)

  • Мы ждём потенциальных возражений или технической реализации? В моих статьях я УЖЕ могу править на "|узкие" или убирать число колонок? --Томасина (обс.) 10:55, 18 июля 2018 (UTC)
Источник — https://ru.wikipedia.org/w/index.php?title=Википедия:Форум/Архив/Предложения/2018/06&oldid=94428632