Википедия: Деревенский насос (предложения)

RfC: Что делать со ссылками на категории на Commons? [ редактировать ]

Что нам делать со ссылками на Commons в категориях? Майк Пил ( разговор ) 09:23, 12 декабря 2020 (UTC)

Всем привет. В настоящее время мы делаем ссылки из категорий здесь на категории Wikimedia Commons, используя {{ Commons category }}. В течение последних нескольких лет мы работали над синхронизацией ссылок на категории Commons между enwp и Wikidata , а теперь для пространства имен Category они полностью синхронизированы. В этих ссылках используются дополнительные ссылки в Викиданных, которые устойчивы к вандализму (должна существовать категория Commons для дополнительных ссылок), и они также соответствуют ссылке на боковой панели на Commons. Они также используются для отображения обратных ссылок на enwp из категорий Commons (как на боковой панели, так и в информационных полях).

В 2018 году я опубликовал RFC, чтобы переключиться на использование Викиданных для интервики-ссылок на Wikimedia Commons , что привело к условному одобрению внесения здесь изменений и созданию нового набора категорий отслеживания в категории Category: Commons Категории отслеживания Викиданных . Последующий RFC в 2019 году по удалению локально определенных ссылок на категории Commons, если они соответствуют дополнительным ссылкам Викиданных, не привел к консенсусу по удалению локально определенных ссылок на Commons.

Я хотел бы вернуться к этому, поскольку это относится только к категориям (т.е. это предложение не распространяется на статьи). В какой-то момент это также может быть применено к статьям, но для них нам нужно исправить проблему, из-за которой дополнительные ссылки Commons не отображаются на боковой панели (в опросе списка желаний сообщества 2021 г.) , и около 15 тыс. Статей не отображаются. синхронизировано с Викиданными (случаи, например, с множественными, несоответствующими или неуместными ссылками) из 560 тыс. статей. Это не проблема для ссылок в пространстве имен Category, которые теперь полностью синхронизированы с Викиданными.

Изменения в текущих ссылках

Я предлагаю следующие варианты использования {{ Commons category }}, которые будут применяться только в пространстве имен Category :

А1. Удалите {{ Commons category }} и оставьте только ссылку на боковой панели. Это самый простой вариант, поскольку MediaWiki будет автоматически отображать его там, где это возможно. Это повлияет на примерно 310 тыс. Категорий (категории отслеживания, перечисленные в A2 и A3). Примером того, как будет выглядеть ссылка Commons после этого изменения, является Category: 1817 in Vermont .

A2. Удалите локально определенные ссылки из категорий , т. Е. {{Commons category|Example}}-> {{Commons category}}. Это второй вариант, который легче всего поддерживать, так как, например, переименования категорий будут обновляться автоматически. Определенные вручную ссылки будут удаляться только в том случае, если они совпадают с дополнительной ссылкой Commons в Викиданных, поэтому это также позволит локальное переопределение. Это повлияет на около 290 тыс. Категорий в разделе Категория: ссылка категории Commons находится в Викиданных . Примером того, как будет выглядеть ссылка Commons после этого изменения, является Категория: Моделирование данных .

A3. Всегда определяйте ссылку локально , т. Е. {{Commons category}}-> {{Commons category|Example}}. Это наиболее сложно поддерживать, так как при изменении ссылки требуется редактирование ботом или вручную. Это повлияет на около 20 тысяч категорий по ссылке Category: Commons category из Викиданных . Примером того, как будет выглядеть ссылка Commons после этого изменения, является Категория: водоемы Ливана .

Добавление новых ссылок

Также предлагаю:

Б. Добавление бота {{ Commons category }}, где дополнительная ссылка категории Commons доступна в Викиданных

За последние несколько лет было добавлено много ссылок между Викиданными и Викискладом (в настоящее время насчитывается более 3 миллионов ссылок). Если мы выберем (A2) или (A3) выше, то их добавление ботом значительно увеличит количество ссылок на Commons. Эти ссылки уже доступны на боковой панели, поэтому, если мы выберем (A1) выше, в этом нет необходимости. Майк Пил ( разговор ) 19:52, 11 декабря 2020 (UTC)

Обсуждение (ссылки на категории Commons) [ править ]

Я предлагаю! Проголосовать за A1, A2 или A3 и сказать «да» / «нет» B. Если мы достигнем консенсуса по любому из этих вариантов, я напишу бота для его реализации и предложу его в Википедии: запросы ботов для окончательного обсуждения перед реализацией. Спасибо. Майк Пил ( разговор ) 19:52, 11 декабря 2020 (UTC)

Из RFC неясно, какие параметры по-прежнему позволят нам настраивать отображаемый текст и можем ли мы ссылаться на несколько категорий, причем обе эти категории возникают довольно часто (Commons имеет небольшую тенденцию к разделению категорий, поэтому мы хотим предоставляет ссылки более чем на один и имеет очень сильную тенденцию давать категориям действительно своеобразные имена, которые не совпадают с общеупотребительным английским названием). Я был бы решительно склонен отклонить любой вариант, который не позволял бы нам добавлять как минимум пояснительный текст к ссылке (например, для биографии архитектора, иметь одну ссылку для портретов объекта и одну ссылку для изображений их зданий. , четко обозначено, что есть что). -  Радужный 20:15, 11 декабря 2020 г. (UTC)

@ Радужный : это редкое явление в категориях (но несколько чаще встречается в статьях, что выходит за рамки данного RFC). Я могу реализовать что-то для A2, что по-прежнему будет позволять настраивать отображение текста, если это действительно необходимо, но это можно легко использовать для введения читателя в заблуждение . В любом случае ссылка на несколько категорий никогда не имеет смысла, так как вы можете либо напрямую указать соответствующую категорию из «Категория: Здания по X», либо просто указать для архитектора ссылку на «Категория: X», а затем читатели смогут просмотреть подкатегории на В остальном Commons - или вы можете улучшить категории в Commons. Спасибо. Майк Пил ( выступление ) 21:02, 11 декабря 2020 г. (UTC)

PS, эти намеренно пропущенные ссылки где-то отмечены / объяснены, пожалуйста? Если нет, может быть, их как-то отметить? Спасибо. Майк Пил ( разговорное ) 21:34, 11 декабря 2020 г. (UTC)

@ Майк Пил : каково ваше краткое и нейтральное заявление ? Приведенное выше утверждение (от тега до следующей отметки времени), превышающее 4500 байт, слишком длинное для обработки Legobot  ( обсуждение · вклад ), поэтому оно некорректно отображается в Википедии: запросы на комментарии / технические проблемы Википедии и шаблоны . - Red rose64 🌹 ( обсуждение ) 23:37, 11 декабря 2020 (UTC){{rfc}} 

@ Redrose64 : Название было своего рода резюме, я перефразировал его чуть ниже тега RfC для бота. Спасибо. Майк Пил ( разговор ) 09:23, 12 декабря 2020 (UTC)

Замечу, что я опубликовал нейтральную заметку об этом RfC на Commons: Commons: Village_pump # Commons_links_from_enwp_categories ( diff ), поскольку это напрямую относится к Commons. Спасибо. Майк Пил ( разговорное ) 20:11, 12 декабря 2020 г. (UTC)

• Я не уверен, почему это было заархивировано ботом во время работы, я вручную разархивировал его. Спасибо. Майк Пил ( выступление ) 13:04, 31 декабря 2020 г. (UTC)

  запоздалый @ Mike Peel : он был заархивирован в 02:40 30 декабря 2020 года (UTC), потому что с 18:17 20 декабря 2020 года (UTC) не было никаких сообщений, и настройки архивирования (это вверху этой страницы). ) включают параметр , который означает, что любая ветка, в которой не было новых сообщений в течение как минимум девяти дней, может быть архивирована. Архивирующие боты не могут определить, идет обсуждение или нет - они просто смотрят на самую последнюю временную метку. - Red rose64 🌹 ( разговор ) 20:11, 17 января 2021 (UTC){{User:MiszaBot/config}}|algo=old(9d)

• Просто обратите внимание, что я запросил закрытие для этого в Википедии: Доска объявлений для администраторов / Запросы на закрытие . Спасибо. Майк Пил ( разговор ) 12:59, 22 января 2021 (UTC)
  • Все еще ожидает, что кто-то закроет это ... Спасибо. Майк Пил ( разговорное ) 11:34, 2 февраля 2021 (UTC)
    • То же. Майк Пил ( разговорное ) 21:12, 8 февраля 2021 (UTC)
      • Тем не менее ... Майк Пил ( разговор ) 19:27, 15 февраля 2021 (UTC)
        • Звук сверчков приятный ... Спасибо. Майк Пил ( разговор ) 18:22, 20 февраля 2021 (UTC)

Обзор (ссылки на категории Commons) [ править ]

• Противопоставьте А1, даже не моргнув. Я уверен, что 99,9% читателей не знают, что боковая панель вообще существует, а в теме с большим количеством межъязыковых ссылок читатели никогда ее не увидят. Слабо выступайте против A2, поскольку я не вижу особых преимуществ в удалении возможности переопределения отображаемой метки. Если это единственные три альтернативы, тогда поддерживайте A3 , хотя я мог бы согласиться с A2 при условии, что есть средства для его отмены или отключения в обстоятельствах, когда то, что есть в Викиданных, не считается подходящим. Определенно выступайте против B , поскольку бывают случаи, когда мы намеренно не ссылаемся на Commons по данной теме. -  Радужный 20:18, 11 декабря 2020 г. (UTC)

  @ Радужный : как указано в описании A2, «это также позволяет локальное переопределение». Спасибо. Майк Пил ( разговор ) 09:17, 12 декабря 2020 г. (UTC)

• Противостояние A1 и Поддержка A3. Постоянный локальный контроль над адресатом ссылки упрощает работу пользователей. Кейт Д. ( выступление ) 20:30, 11 декабря 2020 г. (UTC)

  @ Keith D : Не могли бы вы подробнее рассказать, как это «упрощает работу для пользователей»? Спасибо. Майк Пил ( разговорное ) 21:03, 11 декабря 2020 г. (UTC)

• Обеспокоенность (а не возражение) ... Мы здесь, в WP.en, стали очень осторожно относиться к ссылкам на Викиданные (в любой форме). Бывают случаи, когда два проекта просто не говорят на одном языке, и это вызывает головную боль для обоих проектов. Понятия не имею, является ли это исключением ... но будьте осторожны. Blueboar ( разговор ) 01:28, 12 декабря 2020 (UTC)
• Поддержку A1 проще всего поддерживать с помощью имеющихся в нашем распоряжении инструментов и здравого смысла для защиты от вандализма. A1 - это вопрос того, чтобы привыкнуть к этому и знать, где искать. У шаблона может быть период прекращения поддержки, когда он говорит: «См. Боковую панель слева для ссылки на Commons», чтобы помочь обучению в переходный период. В случае неудачи A1 также будет поддерживаться A2 с добавлением бота (вздох ... посмотрите, насколько лучше A1?). Противостоять А3. - Зеленый C 02:38, 12 декабря 2020 г. (UTC)

  Подлинный вопрос и не надоедает, но как, по вашему мнению, «привыкнуть» будет работать? В скине, в которой более 50% читателей видят Википедию, A1 не просто изменил бы расположение ссылки, но полностью удалил бы ее.; с точки зрения читателей, это не было бы вопросом поиска другого места для перехода к Commons, но Commons внезапно, очевидно, перестало существовать. (Существующие читатели, вероятно, будут знать, чтобы спросить, куда они делись, но у новых читателей не будет причин подозревать, что ссылки когда-либо существовали.) Кроме того, у Википедии не просто одна когорта читателей; все время нас открывают новые люди. Большинство людей, просматривающих категорию, попали туда либо через поиск, либо по ссылкам в статьях Википедии и не являются инсайдерами, которые понимают причуды MediaWiki, и «ссылки со страниц Википедии на связанный контент появляются на этой странице» - это оченьустоявшееся соглашение, подкрепленное 20-летним опытом использования категорий и шаблонов навигационных ящиков. От типичного читателя нельзя ожидать, что он узнает, что если он ищет носитель, связанный с категорией, ему нужно переключиться в режим рабочего стола, если его еще нет, а затем щелкнуть загадочную "In other projects: Wikimedia Commons"ссылку, скрытую в боковая панель. -  Радужный 06:40, 12 декабря 2020 г. (UTC)

  Ой, это довольно серьезная ошибка. Я этого не заметил, так как никогда не использую мобильный интерфейс. Я посмотрел на Phabricator, чтобы узнать, есть ли существующий отчет об ошибке, но я не смог его найти, поэтому я запустил phab: T269992 . Спасибо. Майк Пил ( разговор ) 09:17, 12 декабря 2020 г. (UTC)

  Повторяю мой плагин для обсуждаемого здесь гаджета, который добавляет кнопку одним щелчком, чтобы просмотреть, как страницы будут выглядеть для читателей (которые в основном используют мобильное представление), а не для редакторов (которые редко, если вообще когда-либо). Вы будете удивлены, сколько вещей, которые вы считаете само собой разумеющимися, либо полностью отсутствуют, либо ведут себя совершенно по-другому ( наглядный пример посмотрите, какой беспорядок выглядит Пользователь: Майк Пил в мобильной версии). Если бы я поступил по-своему, мы бы отказались от представления для мобильных устройств и начали заново с нуля - я думаю, что нынешний скин безнадежно плох как для читателей, так и для редакторов - но я не могу представить, чтобы WMF когда-либо признал, что их любимый проект продвижение десятилетия - это полный лимон. -  Радужный 13:22, 12 декабря 2020 г. (UTC)

• Поддержка A1 . Ссылка Commons - это лишь один из примеров ссылок «другие проекты», и их автоматическое отображение как часть пользовательского интерфейса имеет больше смысла, чем добавление одного или нескольких шаблонов в каждую категорию. Если в мобильном интерфейсе эти ссылки не отображаются, это необходимо исправить. Возможно, удаление существующих шаблонов стоит отложить до исправления. ghouston ( разговор ) 02:18, 13 декабря 2020 (UTC)
• Противодействовать A1 , Противостоять A2 , Поддерживать A3 Постоянный локальный контроль над адресатом ссылки облегчает пользователям задачу. Как выразился Keith_D. Или, как я выразился во время последнего RFC: Oppose . Керри хорошо выразился. Меня уже давно беспокоят настойчивые попытки систематического массового удаления контента из Википедии в пользу неясного удаленного владения всем бот-фермой, известной как Викиданные. На днях нам нужно прийти к консенсусу сообщества по поводу практики в целом. Либо мы должны передать все возможное в Викиданные и согласиться с тем, что Викиданные будут управлять всемс этого момента, или нам нужно откатить Викиданные до категорий отслеживания и редких целей особой ценности. Эта бесконечная борьба за продвижение Викиданных вперед (или назад) на дюйм за раз в лучшем случае расточительна, а в худшем - разрушительна. Alsee ( разговор ) 16:26, 8 мая 2019 г. (UTC) [1]Крошечное количество энтузиастов Викиданных настойчиво пытается массово удалить контент, обманывая других редакторов в священном крестовом походе, чтобы сделать Викиданные властелином и правителем всего, что они исследуют. Среди других проблем типичный редактор нажимает CTRL-F, пытаясь найти контент, который они хотят изменить, но его там не было. Возможно, в конце концов они найдут в вики-тексте потенциально совершенно бесполезный шаблон, но там не будет никакой ценности. Редактор остается в затруднительном положении с невозможным редактированием, абсолютно без указания места, где происходит WTF, и без пути вперед. Alsee ( разговорное ) 16:31, 13 декабря 2020 (UTC)
• Поддержка A2 и B . Обычному редактору не нужно редактировать технические межпроектные ссылки. Ruslik _ Zero 20:38, 13 декабря 2020 (UTC)
• Противостоять A1 , Противостоять A2 , Поддерживать A3отмечая, что нам нужно будет явно препятствовать тому, чтобы редакторы из лучших побуждений удаляли ярлыки «потому что это есть в Викиданных», как это уже произошло с примером A3. Иногда разница между названием категории Commons и местным названием будет резкой, тем более что это будет использоваться в качестве прецедента для изменения способа представления ссылок категорий Commons в статьях: Commons уделяет больше внимания названию категорий во всем мире, чем любая отдельная Википедия имеет на титульных страницах, и в результате она выработала различные соглашения, и хотя это не так уж много по категориям («в» против «Ливана» в примере A3 едва заметно), это будет раздражать в тех случаях, когда это имеет значение. Я часто создавал категории в Commons с разными названиями из статей Википедии,например, используя средство устранения неоднозначности вместо «The». По общему вопросу согласен сAlsee ; наличие того, что читатель видит на странице, определенной в Викиданных, а не в отдельном проекте, неприемлемо рискованно с точки зрения вандализма или простой ошибки (на днях я исправил описание Викиданных на голландском языке, которое относило что-то к неправильному штату США) и вносит изменения недопустимо сложно; «Кто угодно может редактировать» - один из наших основополагающих принципов, мы хотим, чтобы читатели были привлечены к исправлению или обновлению чего-либо и получили удовольствие от просмотра их изменений вживую, и мы хотим, чтобы те, кто что-то добавляет или расширяет, исправляли связанные с этим вещи ( WP : SOFIXIT). Викиданные намеренно скрыты за отвесной стеной доступности, потому что они предназначены для профессионалов в области информации и потому, что ошибки в них потенциально влияют на все проекты. Поэтому я должен выступить против A2 и особенно A1 (точка зрения Радужного также чрезвычайно важна в отношении A1, и я удивлен, что WMF не знала об этом). Тем не менее, я не вижу вреда в запуске бота, пока мы сохраняем возможность передавать ссылки по конвейеру, когда наша категория переходит на новый заголовок и больше не соответствует таковому в Викиданных: реализована поддержка B, обеспечивающая A3 . Ингвадоттир ( разговор ) 21:01, 13 декабря 2020 (UTC)
• Противоположность A1 , Противоположность A2 , Поддержка A3 Местное управление обеспечивает необходимую гибкость. Другой аспект - это язык - мое впечатление, что Commons стремится больше использовать имена на местном языке, тогда как enWikipedia часто использует имена, переведенные на английский, что с большей вероятностью приведет к тому, что названия категорий потребуют местного контроля. Изменения, отличные от A3, предполагают соответствие 1: 1 между статьями Википедии и категориями Commons; была изменена Википедия, где я хотел добавить более одной ссылки категории Commons. ПсамафМа ( разговор ) 23:21, 13 декабря 2020 (UTC)
• В качестве номинатора, если это не было очевидно, я в долгосрочной перспективе предпочитаю A1 (но сначала нужно исправить эту ошибку с мобильным сайтом), сейчас я бы предпочел A2, поскольку он минимизирует дублирование данных - что является здесь фундаментальной проблемой. . Если у вас есть несколько копий одних и тех же данных, вам придется исправить каждую из них отдельно. Сохранение этой ссылки в Викиданных так же, как мы храним там интервики, является самым простым вариантом: тогда это тот же набор данных здесь, в Викиданных и в Викискладе (где эта ссылка используется для отображения многоязычного информационного окна). Тогда есть больше возможностей следить за ссылками и больше шансов, что кто-то обнаружит плохие ссылки и исправит их. Я говорю это как человек, который просмотрел и исправил тысячи неправильных ссылок на общие ресурсы enwp за последний год.

При необходимости я мог бы жить с A3, но это означает, что я буду продолжать бот / вручную синхронизировать изменения между Commons / Wikidata / здесь, что является просто дублированием усилий. С точки зрения вандализма, использование дополнительных / межвики-ссылок - самый безопасный способ, поскольку категория должна существовать, чтобы на нее можно было ссылаться (вы не можете изменить ее на какой-либо случайный фрагмент текста). В настоящее время нет категорий, которые ссылаются на несколько категорий Commons, и в этом редко возникает необходимость, но A2 все равно позволит это сделать, если это необходимо. Аналогично местному тексту, если это действительно необходимо (но названия категорий Commons по умолчанию английские). Крошечное количество ненавистников Викиданных склонны повторять ту же риторику всякий раз, когда упоминаются Викиданные, что на самом деле бесполезно (это все равно что утверждать, что все веб-сайты должны вернуться к статическому рендерингу, а не использовать базы данных: он не масштабируется). С B,В любом случае я счастлив - если мы этого не сделаем, мне не придется кодировать бота, но мы также не получим намного больше ссылок на Commons (и имейте в виду, что они исторически были ботами) все равно добавлены в категории). Спасибо.Майк Пил ( разговорное ) 18:05, 14 декабря 2020 г. (UTC)

• Поддержка A2 . Это лучший вариант из обоих миров. Это устраняет необходимость поддерживать две разные системы для привязки категории WP к эквивалентной категории Commons, но также обеспечивает гибкость и контроль при обработке особых случаев. -  Finnusertop ( обсуждение ⋅ вклад ) 16:42, 15 декабря 2020 г. (UTC)
• Выступайте против A1, если и пока не будет зафиксировано мобильное представление (согласно номинатору). Поддержка A2 при условии, что это не рассматривается как шаг к недопущению локального переопределения, которое останется необходимым по всем причинам, которые другие объяснили выше. Питер Коксхед ( разговор ) 17:50, 15 декабря 2020 (UTC)
• Противостоять A1 , неделя противостоять на A2 и поддерживать A3 по причинам, изложенным Iridescent. - Эвриал ( разговор ) 23:12, 15 декабря 2020 г. (UTC)
• Противопоставьте A1, A2, B, - Поддержите A3 по уже указанным выше причинам. Только смерть заканчивает долг ( разговор ) 15:36, 16 декабря 2020 (UTC)
• Противопоставьте A1 и A2 (очень сильно), B, - Поддержите A3 согласно Iri и другим выше. Проблема с A2 заключается в том, что (насколько я понимаю) все ссылки на текущие категории будут удалены, а "локальные переопределения" придется вручную повторно добавлять. «Соответствие Викиданных» - это совершенно ненадежный тест. Это был бы кошмар. Джонбод ( разговор ) 15:44, 16 декабря 2020 (UTC)

  @ Johnbod : Проверка заключается в том, что все ссылки между enwp + Wikidata + Commons синхронизированы, а не просто «совпадают с Викиданными». Если вы не согласны со ссылкой, то в A2 вам придется исправить ссылку (например, добавив локальное переопределение, которое мы затем проверили и исправили в Викиданных / Викискладе), или, лучше, исправив его в Викиданных, чтобы затем исправить везде), либо в A3 вам придется исправить ссылку (например, изменив локальное переопределение, которое мы затем проверим и исправим в Викиданных / Викискладе). В любом случае, работа, которую вам придется выполнять, очень похожа, это вряд ли кошмар. Напоминаем, что enwp / wikidata в настоящее время на 100% синхронизированы для категорий, о которых мы говорим. Спасибо. Майк Пил ( разговорное ) 20:44, 16 декабря 2020 г. (UTC)

• Еженедельная оппозиция A1 , Решительно поддерживаю A2 и категорически против A3, как описано ниже
  • Weekly Oppose A1 действительно, ссылки на другие проекты Викимедиа, с моей точки зрения, недостаточно видны для читателей Википедии, чтобы они могли щелкнуть по этой ссылке в боковом меню. Робби ( разговор ) 21:50, 19 декабря 2020 (UTC)
  • Полностью поддерживаю A2, с моей точки зрения, это на данный момент лучшее решение. Робби ( разговор ) 21:53, 19 декабря 2020 (UTC)
  • На самом деле, категорически против A3, это приведет к бесконечной работе ботов и ручной проверке категорий, удаленных или перемещенных в Commons. Робби ( разговор ) 22:33, 19 декабря 2020 (UTC)
• Я в целом поддерживаю A1 , но я думаю, что этот вопрос лучше оставить для более общего RFC, касающегося полей, которые мы помещаем в конце статей. Я также поддерживаю A2 как минимальный результат, поскольку он устраняет дублирование того, что является просто еще одной межвики-ссылкой в ​​конце дня, что мы уже приняли, управляя межвики-ссылками в Викиданных. Жестко противопоставить А3 . Я также выступаю против B, поскольку я не хочу, чтобы эти коробки продолжались; во-вторых, принудительное включение их ботом, по-видимому, отменяет очевидное желание редакторов редактировать определенные страницы. - Изно ( разговор ) 18:17, 20 декабря 2020 г. (UTC)
• Поддержка A2 для лучшей видимости соединения, но A1 мне тоже подходит . Мы должны максимально использовать Викиданные в таких бесспорных сценариях, как этот. - MarioGom ( разговор ) 14:16, 4 января 2021 г. (UTC)
• Противостоять A1, A2, поддержка Нейтральная A3, поддержка B . Это дает наилучшее сочетание наглядности и позволяет избежать ненужного дублирования усилий. Тридуульф ( разговор ) 16:05, 9 января 2021 (UTC)
• Меня не слишком заботит A1-A3 (хотя я думаю, что локальное определение лучше, цели en.wikipedia и wikidata не всегда совпадают, а определения иногда различаются). Однако я категорически противлюбое автоматическое или слепое добавление «категории общего пользования» (и я предполагаю, что тогда это также соглашение с выборочной A1). Есть много случаев, когда в категории общих ресурсов нет ничего, что добавляется к нашим статьям (все изображения уже используются, и, хотя в редких случаях, в категории общих ресурсов меньше, чем в en.wikipedia), и отправка людей в сообщества, чтобы найти меньше ( или то же самое), чем то, что здесь глупо и просто забивает наши статьи (особенно когда вы получаете целую серию сестринских ссылок). Обратите внимание, что в общих чертах иногда есть разные кадры одного изображения, поэтому, даже если количество изображений в обычных, больше, оно все равно не добавляется. - Дирк Битстра ^{T C} 14:11, 10 января 2021 (UTC)
• A3 (и A2, когда имена совпадают). Категории общих ресурсов слишком часто не имеют названий, соответствующих нашим.  -  SMcCandlish ☏ ¢  😼  08:33, 15 января 2021 г. (UTC)
• Противопоставьте A1 и A2. И поддержка A3 . И поддерживайте B, но только если там написано «Бот-добавленная ссылка». И Майк Пил , пожалуйста, прекратите удалять ссылки общих категорий, которые не совсем соответствуют английскому названию статьи или английским категориям статей. См. Эту разницу . Насколько я знаю, у вас нет таких полномочий. Это пример того, почему бот не должен удалять общие категории. Людям вроде тебя тоже не стоит этого делать. Я заметил из ваших сообщений, что вы в стиле ботовпри этом. Тот факт, что вы являетесь администратором, не означает, что вы имеете на это право. Покажи мне руководство. У меня десятки тысяч правок и в общем доступе, и в Википедии. Я знаю, что многие из этих попыток синхронизации не сработают из-за множества особенностей работы Commons и работы Wikipedia. Я предпочитаю аддитивный подход. Разрешить боту добавлять общие ссылки, но не позволять боту удалять общие ссылки. - Timeshifter ( разговор ) 04:18, 9 февраля 2021 г. (UTC)
  • Я следил за этим комментарием в [2] . Чтобы было ясно, претензии на полномочия и доступ администратора здесь неуместны. Спасибо. Майк Пил ( разговорное ) 20:54, 10 февраля 2021 (UTC)
• Противник A1 / A3, сильная поддержка B, поскольку большая часть читателей, вероятно, даже не знает, что такое «Wikimedia Commons», а «СМИ, связанные с ...» намного легче понять. - TheImaCow ( разговор ) 06:26, 23 февраля 2021 г. (UTC)

Преобразовать все английские варианты уведомлений в editnotices [ edit ]

Это предложение возникло в результате продолжающегося обсуждения в лаборатории идей о том, как уменьшить беспорядок излишних баннеров на страницах обсуждения, явление, которое приводит к слепоте баннеров , подавляющему и запутывающему новых редакторов и уменьшению видимости наиболее важных уведомлений.

Одна из выдвинутых мною идей, которая, кажется, получила особую популярность, заключается в том, что нет необходимости в том, чтобы на странице обсуждения появлялись уведомления о вариантах английского языка (например, {{ British English }}), а не просто как уведомление о редактировании, которое появляется в окне редактирования пока кто-то редактирует статью. Основное объяснение состоит в том, что никто не контролирует английский язык, используемый на страницах обсуждения, поэтому единственное место, где это нужно, - это editnotice. В связи с этим я предлагаю преобразовать все существующие объявления о вариантах на английском языке на страницах обсуждения в уведомления о редактировании на соответствующей странице. Это будет сделано с помощью задачи бота, а после завершения модуля: уведомление о варианте на английском языкебудет настроен таким образом, что при размещении на странице обсуждения статьи выдает уведомление об ошибке. {{u | Sdkb }}  ^talk 14:34, 10 января 2021 г. (UTC)

Обзор (английские варианты) [ править ]

• Поддержка в качестве номинатора. Для решения двух потенциальных проблем: (1) В тех редких случаях, когда на странице обсуждения обсуждается изменение варианта, предлагающий легко указать контекст. Я не могу придумать другой ситуации, в которой людям на странице обсуждения нужно было бы обратить внимание на вариант. (2) Для изменения editnotices в настоящее время требуются расширенные разрешения; Насколько я понимаю, это сделано по техническим причинам, а не из-за какого-либо редакционного консенсуса. Это проблема, которую в какой-то момент следует решать самостоятельно, но я не думаю, что это непреодолимое препятствие, поскольку большинство страниц, разработанных достаточно для того, чтобы помечать их с помощью уведомления о вариантах, контролируются редакторами, которые могут его изменять, и если нет, им будет предложено создать запрос на редактирование, что довольно просто.{{u |Sdkb }} ^talk14:34, 10 января 2021 г. (UTC)
• Поддержка Это хорошая идея, и ее следует реализовать при условии, что со временем будут решены любые технические проблемы (новое разрешение?). G en Q uest ^"scribble" 15:34, 10 января 2021 г. (UTC)
• Поддержка имеет двойное преимущество, поскольку одновременно улучшает как страницу обсуждения (за счет уменьшения беспорядка), так и экран редактирования (за счет отображения соответствующей информации), беспроигрышный вариант. - Павел ❬ разговор ❭ 16:55, 10 января 2021 (UTC)
• Против . Предложение кажется недоработанным, потому что в нем не говорится об использовании таких шаблонов, как {{ Use British English }}, которые я вижу чаще всего. Для страниц обсуждения мы могли бы использовать что-то вроде информационного окна, которое будет содержать ключевую информацию о статье, такую ​​как ее размер и рейтинг качества. Диалект лучше всего вписался бы в такое резюме свойств статьи. Эндрю 🐉 ( разговор ) 17:26, 10 января 2021 (UTC)

  Что касается шаблонов «использовать», то это не повлияет на них так или иначе; они будут доступны до тех пор, пока желательно обозначить вариант, но при этом недостаточно ошибочного редактирования, чтобы возникла необходимость в уведомлении. В дальнейшем мы могли бы обсудить, как часто делать что-то видимым и невидимым, но на данный момент я думаю, что перевод всех видимых уведомлений в формат editnotice - лучший первый шаг.

  Что касается вашей идеи гипотетического информационного окна на странице обсуждения, я бы предложил предложить ее на более широком обсуждении в лаборатории идей. Я мог бы поддержать его, если он реализован хорошо, но это выходит за рамки более узкого изменения, которого я пытаюсь достичь здесь. {{u | Sdkb }}  ^talk 19:12, 10 января 2021 г. (UTC)

• Отличная идея. Я подозреваю, что если бы на момент запуска этих шаблонов существовали уведомления о редактировании, этой проблемы бы не возникло. Шере Шпиль Чекерс 18:50, 10 января 2021 г. (UTC)
• Сильная поддержка, если она будет реализована, будет иметь огромное значение для уменьшения беспорядка на страницах обсуждения и, фактически, для повышения эффективности уведомлений о разнообразии на английском языке. Как я сказал в лаборатории идей, люди, которые игнорируют или игнорируют устоявшуюся разновидность английского языка, не собираются присутствовать на странице обсуждения и видеть это там. Таким образом, я убежден, что текущая позиция на странице обсуждения бесполезна. Aza24 ( разговорное ) 21:03, 10 января 2021 (UTC)
• Поддержка этого кажется способом сделать информацию более эффективной и в то же время уменьшить беспорядок на странице обсуждения. Тридуульф ( разговор ) 22:06, 10 января 2021 (UTC)
• Поддержите, мы уже делаем это для нескольких канадских статей ... например, Template: Editnotices / Page / Canada .... все еще не отображается в мобильной версии :-( - Moxy 🍁 01:06, 11 января 2021 (UTC)
• Поддержите отличную идею. Еще одно дополнительное преимущество состоит в том, что он уменьшает количество владельцев статей, не позволяя новым пользователям публиковать бесполезные теги engvar. Поскольку только администраторы, редакторы шаблонов и перемещатели страниц могут добавлять их, если мы заставляем их редактировать уведомления, это также дает возможность редакторам шаблонов и перемещателям страниц что-то делать. - WUG · а • ро · дез 2:54, 11 января 2021 (UTC)
  • Мне также нравится идея их полного удаления. - WUG · а • ро · дез 21:45, 13 января 2021 (UTC)
  • Редакторы шаблонов и переносчики страниц могут не захотеть делать что-то еще. Кажется, достаточно просто написать бота с необходимыми для этого разрешениями. Хромовая туманность (разговор) 23:20, 26 января 2021 (UTC)
• Поддержка для всех этого жанра извещений (engvar, форматов даты и т.д.), но - возможно еретический - я бы поддержал все топ-оф-страницы очистки уведомления вдаваясь в editnotices , а также, чтобы люди , которые просто хотят , чтобы посоветоваться статьи для информации не беспокоят их. Вне моего Кена ( разговор ) 03:17, 11 января 2021 (UTC)

  Помимо «Моего Кена» , под уведомлениями об очистке в верхней части страницы вы имеете в виду такие вещи, как {{ NPOV }} или {{ Оригинальное исследование }}? Я думаю, что эти уведомления очень необходимы с точки зрения читателя, поскольку читатели заслуживают знать, когда в статье есть серьезные проблемы, чтобы они могли прочитать ее с должной осторожностью и скептицизмом (да, люди всегда должны это делать , но они доверяют нам достаточно, чтобы де-факто часто этого не делают). Однако это более верно для некоторых уведомлений, чем для других; Я мог видеть случай для многих желтых стилей, таких как {{ Очистить голые URL}} будет преобразовано для отображения только редакторам. В этот момент возникает вопрос, не упускаем ли мы возможность превратить читателей в редакторов, предлагая им простую задачу. Все это имеет отношение к текущему обсуждению, так что, возможно, возьмите его в другом месте, если хотите развить его дальше, но я надеюсь, что мой комментарий является пищей для размышлений. {{u | Sdkb }}  ^talk 11:05, 11 января 2021 г. (UTC)

  Нет, вы правы, я имел в виду «желтые», которые в первую очередь касаются только редакторов. Помимо моего Кена ( выступление ) 21:26, 11 января 2021 г. (UTC)

  Я бы сказал, что изрядное количество желтых баннеров полезно читателям (например, шаблон: перекрашенный, позволяющий дальтоникам знать, что они могут неправильно интерпретировать что-то на странице, или шаблон: похожий на эссе ). Кроме того, поскольку я редактировал даже те, которые читатели, не являющиеся редакторами, могут счесть полезными, теперь сообщите, как я читаю. Например, при просмотре шаблона "Дебаты"не изменил бы то, как я что-то читал в прошлом, но теперь это наводит на мысль, что у людей может быть разветвленная точка зрения, может не быть большого использования обзоров / метаанализов (в случае научных статей) или их редактирования возможно, это была серия не связанных между собой дополнений. Они также полезны для редактирования - я отхожу от выполнения других задач, чтобы исправить статью, если я замечаю некоторые виды баннеров, в том числе когда я не собирался редактировать ее. - Ссуризури ( разговор ) 10:55, 12 января 2021 г. (UTC)

• Поддержка Отличная идея, этот баннер способствует ползучести, и я надеюсь, что это уменьшит ненужные конфликты, так как многие редакции с благими намерениями от новых редакторов и редакторов IP связаны с ENGVAR. - Том (LT) ( разговор ) 03:20, 11 января 2021 г. (UTC)
• Поддержка бесполезна на страницах обсуждения, полезна при редактировании, которое отображается в editnotice. Нет необходимости в новом разрешении и не должно быть доступным для всех редактирование editnotations, PMR и TPE могут это сделать. Если очередь TPER становится слишком длинной, мы можем заставить бота с TPE переносить дополнения со страницы обсуждения в editnotice. ProcrastinatingReader ( разговор ) 09:21, 11 января 2021 (UTC)

  Выступая в пользу использования скрытых шаблонов, таких как {{ Use British English }} в тексте статьи, как сказано Whatamidoing, и удаления всех уведомлений о редактировании и баннеров на странице обсуждения и преобразования их в скрытые шаблоны, такие как {{ Use British English }} . Как вариант, шаблон {{ article standard }}, как описано в ветке Левивича. Аргументы Левивича и L235 убедительны. ProcrastinatingReader ( обсуждение ) 15:15, 5 февраля 2021 (UTC)

• Поддержка по предложению ~ ToBeFree ( обсуждение ) 11:09, 11 января 2021 г. (UTC)
• Поддержка - уменьшение количества шаблонов страниц обсуждения и помощь новым редакторам в понимании Engvar в то же время звучит для меня как беспроигрышный вариант. Злой Гарпия ^{разговоры} 12:47, 11 января 2021 (UTC)
• Думаю, я против по симпатическим причинам. 2 причины: 1) Не думаю, что это технически осуществимо. Он просит сделать уведомление об изменении по существу для 6 миллионов страниц. Ужасно много инфраструктуры. (Кто-то скажет мне, что я ошибаюсь.) 2) Я действительно думаю, что правильным средством является полное удаление их со страниц обсуждения. Нам не нужно, чтобы они присутствовали одновременно в их каноническом месте в виде тегов статей и страниц обсуждения. (При необходимости замените статью.) - Изно ( обсуждение ) 14:41, 11 января 2021 г. (UTC)
  • @ Izno : Я думаю, что при текущем использовании модуля eng var было бы создано не более 41 000 уведомлений об изменении . - Пол ❬ доклад ❭ 18:36, 11 января 2021 г. (UTC)
    • Просто казуальная 41к. Эйеролл. - Изно ( разговор ) 18:44, 11 января 2021 (UTC)
      • Тривиально для бота. Тридуульф ( разговор ) 19:57, 11 января 2021 (UTC)
      • Банально это или нет, но совсем другая цифра в 6 мил. - Paul ❬ talk ❭ 21:14, 11 января 2021 г. (UTC)
        • Создание «для бота тривиально». Обслуживание и фильтрация сквозь шум в пространстве имен шаблонов, ищущих что-нибудь, кроме уведомлений об изменении? Да не очень. - Изно ( разговор ) 01:39, 12 января 2021 (UTC)
• Поддержка Это кажется хорошей идеей, к которой стоит стремиться. - Джейрон, 32 18:16, 11 января 2021 г. (UTC)
• Поддержка Уменьшение беспорядка на страницах обсуждения - хорошая идея. Remagoxer ( разговор ) 20:51, 11 января 2021 (UTC)
• Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
• Поддержка, а как насчет защищенных страниц? Может быть увеличение (неправильного) запроса на редактирование ENVAR, я думаю, вы бы также добавили en-varent сообщение на страницу обсуждения? (пожалуйста, пинг) DarthFlappy 18:53, 12 января 2021 г. (UTC)

  @ DarthFlappy : Я ожидал, что подавляющее большинство запросов на редактирование исходят от людей, которые пытаются редактировать защищенную страницу (которая не соответствует требованиям), нажимая кнопку, чтобы запросить редактирование, и заполняя форму. Вы могли заметить, что многие из них пусты - это потому, что люди не читают то, что отображается на их экране, и просто щелкают по большой синей кнопке «Отправить» (возможно, думая, что они запрашивают у них разрешение на редактирование). Но в любом случае я бы не подумал, что баннер страницы обсуждения действительно повлияет на содержимое запроса на редактирование. - Билорв ( разговор ) 23:49, 14 января 2021 г. (UTC)

• Противодействие Уилл только ухудшит баннерную слепоту. CaptainEek ^{редактирует Ho Cap'n!} ⚓ 20:41, 12 января 2021 (UTC)
• Поддерживают, но не масштабно, а только в качестве пилота. Насколько я понимаю, это может повлиять на миллионы статей, поэтому сначала попробуйте его в качестве пилотного проекта для сотен статей. Такие большие изменения лучше всего делать с помощью тестовых примеров, времени, нескольких запросов на комментарии и документации. Это уже пользуется моей общей поддержкой, и я также надеюсь, что в будущем снова поддержу, но это предложение как таковое не имеет ограничений. Для меня важен масштаб и темп изменений. Я ожидаю только документации добровольческого уровня, а не самой лучшей и полной, и я поощряю пилотную версию. Я признаю существование проблемы и чувствую, что она будет только расти. Возможны разные решения, и, возможно, нам придется использовать сразу несколько решений для решения этой проблемы. Пожалуйста, сначала разработайте это решение. Голубая малина(talk) 20:51, 12 January 2021 (UTC)
• Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)
• Возражать - Enwiki надо быть единственным изданием в мире, пишет одной работы , используя несколько разновидностей английского языка. Я согласен, что Engvar не настолько важен, чтобы иметь баннеры на страницах обсуждения, но решение состоит в том, чтобы удалить их полностью. Перемещение их в уведомление об изменении приведет к слепоте с уведомлением об изменении вместо слепоты с баннером на странице обсуждения, и это даже хуже, потому что теоретически уведомления об изменении содержат действительно важные вещи, даже больше, чем заголовки страниц обсуждения. Создание тысяч или миллионов уведомлений об изменении - это огромные накладные расходы и увеличение объема обслуживания. Уведомления о редактировании раздражают и в любом случае игнорируются. Они вообще не отображаются для мобильных пользователей. В целом, я думаю, что это скорее усугубит проблему, чем облегчит ее. Levivich  ^харасс /_гончая 04:53, 13 января 2021 (UTC)

  Это справедливый момент. Я думал, что примечание должно быть сокращено, буквально до маркированного списка вроде: «* В этой статье используется британский английский». В качестве альтернативы, у нас может быть один шаблон страницы обсуждения «Соглашения о статьях», который сильно урезан и обозначает стандарты, такие как разнообразие используемого английского языка - это предполагает, что существуют другие типы стандартов, кроме английского и разнообразия дат, которые могут применяться. Немного похоже . ProcrastinatingReader ( разговор ) 09:16, 13 января 2021 (UTC){{article standards|lang=British|dates=dmy}}

  Шаблон условных обозначений статей звучит как очень хорошая идея. Вероятно, есть и другие, помимо engvar и usedmy, но эти два - хорошие примеры. Я считаю, что иконография - самый эффективный способ сообщения такого рода вещей, но я не уверен, что все будут согласны с этим. Так что вроде небольшого британского флага где-нибудь, если он использовал BrEng, американский флаг для AmEng, что-то в этом роде. Levivich  ^харасс / _гончая 17:27, 13 января 2021 (UTC)

  Я согласен с тем, что уведомления должны быть ненавязчивыми и краткими. Что касается пункта «просто удалите их полностью», у нас уже есть, например, семейство шаблонов {{ Use British English }}, которые устанавливают стандарт, ничего не отображая, как вы описываете. Я не уверен, стоит ли / когда нам использовать это по сравнению с {{ British English }}, но я думаю, что в обстоятельствах, когда это достаточно важно, чтобы гарантировать баннер, этот баннер должен находиться рядом с тем местом, где он на самом деле применяется, что означает размещение его в примечании к редактированию рядом со статьей, а не в баннерах обсуждения рядом с докладом. {{u | Sdkb }}  ^talk 00:06, 14 января 2021 г. (UTC)

• Против. Мы должны сохранить баннеры для действительно важных вещей, таких как BLP, а не для правописания. ( t · c ) buidhe 18:35, 13 января 2021 (UTC)
• Выступайте против Грэма Бартлетта и CaptainEek. ~ HAL 333 22:19, 13 января 2021 г. (UTC)
• Поддержка : кажется, нетрудно. Баннерная слепота на странице обсуждения уже является серьезной проблемой, и ENGVAR не имеет отношения к чтению страницы обсуждения, он имеет отношение к редактированию страницы, поэтому он должен быть там, где это необходимо. Скипетр ( разговор ) 23:33, 14 января 2021 (UTC)
• Против : это абсолютно разумное предложение, но я бы предпочел удалить эти баннеры со страницы обсуждения. Я просто не покупаю тот вариант языка, который достаточно важен, чтобы гарантировать такое внимание, и вместо этого он просто вызовет слепоту читателя, где бы он ни появился. Я понимаю, что очень неприятно возвращать одни и те же добросовестные изменения правописания снова и снова (я потерял счет, сколько раз мне приходилось возвращать «взнос» обратно в «взнос» на BritEng Black Mirror серии статей), но я обнаружил, что большинство незарегистрированных редакторов не увидят уведомление об изменении, шаблон викикода илискрытый комментарий в середине слова, который постоянно меняется (я не знаю, почему последний не работает, но это не так), или, возможно, просто намеренно игнорирует их все. Поэтому я считаю, что это предложение, хотя и кажется логичной позицией здравого смысла для перемещения шаблона, просто создаст слепоту и практически не повлияет на предотвращение дублирования редактирования. - Билорв ( разговор ) 23:40, 14 января 2021 (UTC)

  @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}} ^talk 01:58, 15 January 2021 (UTC)

  I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)

  To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? Этот источник ненадежен, даже если это газета, которую читает миллион человек в день? Неправильно называть раздел «Противоречие», даже если вы видели еще 1000 статей с таким плохим заголовком? Во всяком случае, мне кажется, что «в этой статье используется австралийский английский, потому что она об австралийском шоу» намного легче объяснить, чем большинство распространенных ошибок. - Билорв ( разговор ) 09:37, 15 января 2021 (UTC)

  Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"

  Однако даже с этим я согласен с Нововым в том, что для страниц, на которых переключатели являются общими (это группа, которую мы обсуждаем здесь), лучше не заставлять кого-то делать всю работу, прежде чем давать им предупреждение. И дело не только в новичках - я не знал, что «рассрочка» было одним из слов, которые отличались друг от друга, пока вы не упомянули об этом выше, поэтому я легко мог представить себя совершающим эту ошибку. Принимая во внимание, что если есть editnotice, которое (опять же, мысля футуристически) автоматически обнаруживает, что «рассрочка» часто используется на этой странице и, следовательно, включает его в примеры, это позволит мне ничего не трогать. {{u | Sdkb }}  ^talk 13:05, 15 января 2021 г. (UTC)

• Поддержка - эта информация наиболее полезна для фактического редактирования страниц, а не для обсуждений. По логике вещей, он должен принадлежать этому месту, и такое перемещение было бы полезно для редакторов IP, которые «исправили» орфографию. Да, на странице обсуждения есть другая информация, которую следует прочитать, но многие люди ее не читают, и принятие желаемого за действительное не устранит этот факт. -Новов Т С 07:57, 15 января 2021 г. (UTC)
• Против . Инструкции ползут , чрезмерно навязчивы и просто приведут к большей слепоте редактирования уведомлений. Нейтралитет ^{разговоры} 19:43, 15 января 2021 (UTC)
• Противник за нейтралитет. Лично мне не нравятся уведомления об изменении, и я бы не хотел, чтобы другие уведомления об изменении, которые могли бы вторгаться в интерфейс редактирования. Возможно, что-то похожее на Шаблон: Использовать шаблон дат mdy было бы лучше. Целый ряд уведомлений о редактировании национальных разновидностей английского языка (иногда там, где они уже есть) был бы хуже, чем слепота баннеров на странице обсуждения, для создателей контента, тем более что им пришлось бы прокручивать уведомление об редактировании каждый раз, когда они редактируют. Кроме того, национальные вариации английского языка не так уж и важны, поэтому мы должны держать их на страницах обсуждений. P, TO 19104 ( обсуждение ) ( вклад ) 23:08, 15 января 2021 (UTC)
• Выступайте против Грэма Бартлетта и CaptainEek. Кавалерист ( разговор ) 03:14, 16 января 2021 (UTC).
• Против . Разновидности английского языка не настолько важны, чтобы их можно было разместить в качестве редакционного уведомления. Просто попытайтесь заметить, какое разнообразие используется в статье, и подражайте этому; если вы ошиблись, кто-нибудь поможет вам исправить. На мой взгляд, баннер страницы обсуждения существует только для того, чтобы попытаться предотвратить войны редактирования из-за этого материала, при этом одна сторона может указать на баннер. В остальное время он бесполезен ни на странице обсуждения, ни в качестве заметки для редактирования. KevinL ( он же L235 · t · c ) 20:07, 18 января 2021 г. (UTC)
  • В дополнение к этому есть несколько действительно важных уведомлений о редактировании (например, уведомления DS, которые создают блокируемые нарушения), и чем больше мы добавим уведомлений о редактировании, тем больше мы получим баннерную слепоту. Уведомления на странице обсуждения уже игнорируются; не будем предавать редакционные уведомления той же участи. KevinL ( он же L235 · t · c ) 20:09, 18 января 2021 г. (UTC)

  Хотя я понимаю ваш аргумент, честно говоря, формат editnotice уже существует прямо сейчас и размещен произвольно; Администраторы / TE / PMR разместят его сами или по запросу других редакторов, также в соответствии с текущей документацией для этих шаблонов. Страницы, на которых есть только уведомление о разговоре, обычно произвольны. ProcrastinatingReader ( разговор ) 20:12, 18 января 2021 (UTC)

  • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
    • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
      Лично я думаю, что нужно либо сократить это буквально до пункта, а не громоздкого уведомления, либо создать {{ стандарты статей }} для страниц обсуждения. Разумеется, у каждой опции разные цели: первая предназначена для предупреждения редакторов, пишущих о необходимости адаптации их языка, а вторая - для помощи редакторам в «исправлении» ошибок. Лично я не знаю других разновидностей английского языка, поэтому я делаю свои «ошибки» и позволяю кому-то другому копировать их исправления, если им интересно, так что, возможно, последнее будет умнее. ProcrastinatingReader ( разговор ) 20:26, 18 января 2021 (UTC)
      • Текущее уведомление о редактировании должно быть прекращено с предубеждением. KevinL ( он же L235 · t · c ) 20:52, 18 января 2021 г. (UTC)
        • Думаю, я использовал это уведомление об изменении. Но идея состоит в том, чтобы вставлять уведомление только в том случае, если его действительно нужно заметить, то есть существует хроническая проблема с многочисленными правками на странице. Так что вообще, на мой взгляд, добавлять не стоит. Грэм Бартлетт ( разговор ) 23:59, 18 января 2021 (UTC)

• Возражать - editnotices должен быть зарезервирован для важной article- и страниц конкретных инструкций, и должен быть использован в качестве минимально , как мы можем управлять. Открытие уведомлений о редактировании для общих рекомендаций о стилях статей приведет к беспорядку и значительно снизит полезность уведомлений о редактировании для этих заметок для статей и страниц. См. Также это обсуждение пару лет назад об этой конкретной вещи, которая привела к консенсусу, что уведомления о стилях не должны использоваться таким образом без признаков нарушения. В том же обсуждении несколько более умных пользователей, чем я, также предположили, что это приведет к загрязнению базы данных несколькими сотнями тысяч новых страниц и увеличению времени загрузки статей без какой-либо особо важной причины. Иванвекторская белка ( ^{деревья}/ _nut ) 01:04, 20 января 2021 г. (UTC)

  Кроме того, мы до сих пор не решили проблему, заключающуюся в том, что уведомления о редактировании не видны мобильным редакторам, поэтому они в любом случае не подходят для редакционных рекомендаций. Иванвекторская белка ( ^{деревья} / _орехи ) 01:06, 20 января 2021 (UTC)

• Предположите, что это предложение игнорирует тот факт, что уведомления о редактировании не отображаются на мобильных устройствах. SK2242 ( разговор ) 06:41, 20 января 2021 (UTC)

  Также не говорите уведомлений. Или, ну, они хорошо спрятаны. ProcrastinatingReader ( разговор ) 23:00, 21 января 2021 (UTC)

• Слабый противиться ; Сколько раз вы читали на AN или ANI напоминание вроде: «Уважаемый OP, вы пропустили ярко-оранжевое уведомление, когда разместили здесь?» Если они пропустят это, действительно ли мы думаем, что editnotice предотвратит необходимость для наблюдателей за страницей вернуться к правильной EngVar? Лично я считаю, что уведомления о редактировании следует оставлять для самых важных вещей, которые, если вы промахнетесь или пропустите, могут оказаться ограниченными в ваших привилегиях. счастливые дни, Линдсей ^{H Элло} 14:10, 22 января 2021 (UTC)
• Поддерживается, но только в том случае, если для вошедших в систему редакторов есть возможность отключить уведомления. Lugnuts ^{Fire иди со мной} 17:23, 22 января 2021 (UTC)
• Против того, чтобы было больше уведомлений об изменении . В визуальном редакторе и редакторе вики-текста 2017 вы должны щелкать, чтобы пропустить уведомления об изменении каждый раз, когда вы открываете эту страницу для редактирования. Также, как и говорит белка Иванвектора , вы перестаете их читать, когда они обычны. WT: MED имеет уведомление об изменении, которое я просматривал большинство дней за последние несколько лет, и я больше не знаю, что в нем написано. Когда нам нужно иметь примечания об используемом варианте языка, сделайте их все «невидимыми» шаблонами, которые содержат необходимую информацию в заголовке, например {{ Use British English }}. WhatamIdoing ( разговор ) 19:58, 22 января 2021 (UTC)
• Поддерживать. Как уже говорили многие другие, очень немногие редакторы действительно заметят баннеры на страницах обсуждения, особенно IP-адреса и новички. А несоблюдение инструкций ENGVAR часто приводило к разрушительным, бессмысленным войнам редактирования. Конечно, нам нужно помнить о том, чтобы не накапливать столько уведомлений об изменении, что люди перестанут обращать на них внимание, но это отдельное обсуждение того, как уплотнить уведомления об изменении. Хромовая туманность (разговор) 23:20, 26 января 2021 (UTC)
• Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor^(discuss) 22:10, 29 January 2021 (UTC)
• Поддержка , в идеале с сокращением уведомлений до самого необходимого. Возможно, просто эта статья написана на американском английском , и это не должно быть изменено без согласия. Узнать больше . Я считаю использование editnotices улучшением во многих отношениях. Страницы обсуждения становятся менее загроможденными. Новички, которые не знают о нашем подходе к английским разновидностям, с большей вероятностью узнают об этом и избегают нежелательных изменений. А более опытные пользователи, редактирующие статьи без сильных национальных связей, могут быстро понять, как им следует писать, без необходимости проверять страницу обсуждения или сканировать статью в поисках подсказок относительно предпочтительного сорта. вуб "?!" 23:35, 30 января 2021 г. (UTC)
• Поддержка - похоже, хорошая идея. Ролло Август ( разговор ) 17:32, 3 февраля 2021 (UTC)
• Возражать на Levivich и L235. AVS malnad 77 ^{разговор} 04:04, 5 февраля 2021 (UTC)
• Против . Уведомления об изменении затрудняют редактирование. Их следует использовать для важных дел. Espresso Addict ( разговор ) 07:54, 11 февраля 2021 (UTC)
• Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEPна самом высоком уровне, а также является результатом почти двух десятилетий консенсуса о том, что ни один стиль не имеет значения, за исключением некоторых ключевых моментов, касающихся повышения названия статей до уровня политики. Пока мы занимаемся этим, также просто избавьтесь для этого от баннеров на странице обсуждения. "Тихих" шаблонов, как в верхней части статьи, вполне достаточно.  -  SMcCandlish ☏ ¢  😼  18:01, 13 февраля 2021 г. (UTC){{Use British English}}
• Слабая поддержка , это один из вариантов уменьшения беспорядка. Эти шаблоны уже существуют как уведомления о редактировании, поэтому вопрос о том, должны ли они быть, требует отдельного обсуждения. В любом случае , в качестве тега страницы обсуждения или примечания к редактированию, они должны быть резко уменьшены в видимости / пространстве в соответствии с аналогичными комментариями выше, в первую очередь путем удаления флагов / других изображений в соответствии с духом WP: FLAGCRUFT . Откровенно говоря, эти уведомления можно было бы сократить до двух слов (например, «британский английский», «американский английский»), оставив где-нибудь согласованно на странице обсуждения / в примечании к редактированию. CMD ( разговор ) 17:46, 14 февраля 2021 (UTC)
• Возражать на SMcCandlish. Уведомления о редактировании должны быть зарезервированы только для важных инструкций / информации. - NSH001 ( разговор ) 10:04, 20 февраля 2021 г. (UTC)

Обсуждение [ править ]

• Если это будет принято, как это будет реализовано по сравнению с существующими редакторами, которые уже включают английское разнообразие? То есть см. Википедия: Избранные статьи / шаблоны Editnotice для получения списка всех медицинских заметок editnotices, которые уже включают английский вариант, включая настраиваемый список слов из статьи. (Не технарь, расскажите подробнее об этом в Dummy 101.) Сэнди Джорджия ( Обсуждение ) 16:46, 10 января 2021 (UTC)
  • В тех случаях, когда он уже находится в уведомлении об изменении, я думаю, мы просто оставим его там и удалим его только со страницы обсуждения. - Пол ❬ выступление ❭ 17:07, 10 января 2021 г. (UTC)

    Да, для таких страниц, как Template: Editnotices / Page / Rotavirus , он уже включен , поэтому бот просто удалит уведомление на странице обсуждения, а не добавит дубликат. Для той редкой страницы, которая имеет пользовательский язык editnotice, например Template: Editnotices / Page / COVID-19 pandemic , это было бы немного сложнее, но все же выполнимо; бот мог просто пропустить добавление чего-либо для editnotices, которые ссылаются на страницу в категории: английские диалекты . {{u | Sdkb }} ^talk 19:55, 10 января 2021 г. (UTC){{British English|form=editnotice}} 

• Перевод баннеров с разговора на уведомление об изменении помогает говорить, но делает еще более маловероятным, что люди прочитают уведомление об изменении. Я хотел бы увидеть черновик того, как именно будет реализовано это предложение (создать миллион новых уведомлений об изменении? Создать одно центральное уведомление об изменении с волшебным кодом, чтобы показать разнообразие языков?), И как именно оно будет выглядеть. Попробуйте отредактировать Дональда Трампа, чтобы увидеть, как может выглядеть уведомление об изменении. Johnuniq ( разговорное ) 22:59, 10 января 2021 (UTC)
  • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
  • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)
    • Я не уверен, насколько это осуществимо с технической точки зрения, но если шаблон editnotice касается форматирования (например, порядка даты), языкового варианта и т. Д., То могут ли они быть меньше и размещены вместе прямо над редактором? Это сделало бы его менее навязчивым, но при этом по-прежнему было бы легко найти все относящиеся к делу небольшие фрагменты правил переписывания информации. В качестве альтернативы они могут быть на расширяемой панели, как некоторые списки категорий в конце статей. - Ссуризури ( разговор ) 10:22, 12 января 2021 г. (UTC)

  @ Johnuniq , я считаю, что это потребует создания десятков тысяч уведомлений об изменении. WhatamIdoing ( разговор ) 20:01, 22 января 2021 (UTC)

• Многие редакторы старых времен, самые новые редакторы и практически все IP никогда не делают привычкой смотреть страницу обсуждения перед редактированием страницы статьи. Уведомления в английской версии на странице обсуждения бесполезны. G en Q uest ^"scribble" 23:30, 10 января 2021 г. (UTC)
  • Полностью согласен, и я считаю, что это предложение должно решить эту проблему. Текущее размещение английских разнообразных шаблонов практически незаметно для целевой аудитории. Aza24 ( разговор ) 00:10, 11 января 2021 (UTC)
    • Как новый редактор, я никогда намеренно не проверял перед редактированием, так что это, по крайней мере, некоторые анекдотические доказательства вашей точки зрения. Однако я не уверен, что это функция уведомления на странице обсуждения, но в визуальном редакторе некоторых статей есть небольшая подсказка прямо под заголовком (например, « Образование в Австралии» ). Я большой поклонник этих маленьких подсказок. - Ссуризури ( разговор ) 10:22, 12 января 2021 г. (UTC)
• Необходимость вмешательства администратора вынудит редактора, не являющегося администратором, который замечает изменение английского варианта, явно оправдано провести два сеанса редактирования на странице. Первым сеансом будет размещение защищенного запроса на редактирование. Во-вторых, действительно изменить разнообразие. Jc3s5h ( разговор ) 01:02, 11 января 2021 (UTC)
  • Учитывая, насколько редко следует менять разновидность английского языка, это звучит как преимущество для этого предложения - обеспечение того, чтобы это происходило только тогда, когда для этого есть веская причина. Тридуульф ( разговор ) 11:12, 11 января 2021 (UTC)
    • Я согласен с этим. Требование двух правок не является необоснованным для чего-то, что определяет, как написана вся статья. - Ссуризури ( разговор ) 10:22, 12 января 2021 г. (UTC)

• Я ожидаю, что оппоненты на основании того, что «мы не должны их иметь в первую очередь», действительно что-то предпримут с этим и предложат, чтобы мы удалили их всех вместе (если это предложение не будет принято). В противном случае вы зря тратите время. Aza24 ( разговор ) 06:08, 13 января 2021 (UTC)

  Противодействие переходу от второго лучшего решения (баннеры на странице обсуждения) к третьему лучшему решению (уведомления о редактировании) не является пустой тратой времени, даже если вы не предлагаете лучшего решения (без баннеров). Делать предложение, не имеющее достаточных шансов на успех, - пустая трата времени. Часто статус-кво остается «второстепенным», потому что это компромисс. Levivich  ^харасс / _гончая 06:16, 13 января 2021 (UTC)

  Вы ошибаетесь, если считаете, что это обсуждение не может привести к консенсусу по удалению их со страниц обсуждения без замены. RFC - это не голоса.

  Во-вторых, мы не теряем время зря. Мы должны предпочесть лучшее решение, как бы мы его не добились. Было бы логическим заблуждением утверждать, что мы также должны делать что-то в соответствии с нашей позицией, тем более что это добровольная миссия. (Если хотите, меня могут называть лицемером. :)

  В-третьих, это, пожалуй, наименее важная вещь на вики сегодня. Нам не нужна полярность с вашей стороны. - Изно ( разговорное ) 22:09, 13 января 2021 г. (UTC)

  Изно , буквально нигде я не сказал, что подобное обсуждение не может привести к консенсусу по удалению их со страниц обсуждения без замены , и я определенно не пытался намеренно создать «поляризм»; искажение фактов не приветствуется. Я думаю, я довольно ясно понимал, что было бы «тратой времени» - ситуация, когда люди, которые выступают против на основании того, что «мы не должны иметь их с самого начала», предложение терпит неудачу, но эти противники не начинают предложение убрать английские эстрадные баннеры. Потому что в ситуации, когда проблема поднимается, следовательно, не решена путем введения более серьезной проблемы, и ни одна из них не решена, - это пустая трата времени. Aza24 ( обсуждение) 22:39, 13 января 2021 г. (UTC)

• Очевидно, что лучшим решением был бы бот, который автоматически (и незаметно) исправлял орфографию и использование для любого обозначенного варианта (при условии, что вариант был обозначен) ... со сводкой редактирования, объясняющей, что было сделано и почему. Тогда редакторы могли просто писать, не беспокоясь о том, пишут ли они в обозначенном варианте. Blueboar ( разговор ) 14:00, 15 января 2021 (UTC)

  @ Blueboar : редакторы, которые пишут какой-либо новый контент, уже не должны слишком сильно беспокоиться об этом - это действительно о том, чтобы избежать повторного рефакторинга существующего текста снова и снова. - ^{Обсуждение} xaosflux, 11:45, 16 января 2021 г. (UTC)

• По крайней мере, баннеры должны быть уменьшены, а флаги или другие изображения удалены. Английские разновидности не всегда четко следуют политическим границам, и, во всяком случае, у нас есть WP: FLAGCRUFT для таких ситуаций в статьях, и все же флаги рассылаются спамом на страницах обсуждения. Их удаление также помогает уменьшить пространство и заметность для шаблона, который, вероятно, чаще всего виден при явном поиске. CMD ( разговорное ) 16:47, 17 января 2021 (UTC)

  Я согласен с тем, что баннеры следует обрезать, но я думаю, что флаги на самом деле очень полезны в качестве визуального обозначения, поэтому я думаю, что это элемент, который мы должны сохранить. {{u | Sdkb }}  ^talk 21:15, 14 февраля 2021 г. (UTC)

• My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)

  Trialpears , как я уже упоминал в своем голосовании!, Я вижу в этом основную проблему - есть множество ситуаций, в которых любой, кто подтвердил автоподтверждение, должен иметь возможность редактировать editnotice страницы, но не может (не из-за какого-либо редакционного консенсуса, но просто из-за какой-то внутренней технической структуры editnotices). Это проблема, которую мы должны решить (и если это произойдет, это может подтолкнуть нас к этому), но я не думаю, что мы должны ставить себе в затруднительное положение и отказываться от этого из-за этого. Это одновременно скрывает уровень потребности в решении проблемы и дает нам больше работы в будущем, когда она будет решена. {{u | Sdkb }}  ^talk 00:12, 13 февраля 2021 г. (UTC)

  Я чувствую, что в целом это было бы хорошей идеей, но я все же вижу некоторые причины для защиты. Вандализм в уведомлениях редактирования, скорее всего, не будет обнаружен большую часть времени, и даже если он будет обнаружен, большинство редакторов, вероятно, не будут знать, как его решить. Вложить в них дезинформацию могло быть намного хуже. Я бы определенно поддержал включение его для расширенных подтвержденных пользователей. Что касается реализации, ограничение регулируется MediaWiki: Titleblacklist, который может легко переключить его на требование автоподтверждения. Также должна быть возможность использовать вместо него фильтр редактирования, который мог бы вместо этого реализовать расширенное подтвержденное ограничение. - Trialpears ( разговор ) 21:26, 16 февраля 2021 г. (UTC)

слияния @ AfD (да, снова) [ править ]

Перемещено из Википедии: Village pump (лаборатория идей) / Архив 34 § слияния @ AfD (да, снова)

Да, я знаю, что это постоянное предложение, и да, я прочитал довольно много обсуждений в прошлом, и да, я действительно чувствую, что сейчас времена другие. Слияния часто остаются открытыми непомерно долго. Это непрактично, и система предлагаемых слияний явно борется с низким уровнем участия и интереса (не говоря уже о том, что в других областях нет). Более эффективно и рационально выставить статью на удаление, если вы хотите, чтобы она была объединена. Нравится вам это или нет, но на данный момент это может показаться фактом, основанным на моей ненаучной повседневной жизни. См., Например, 1 и 2, где единодушное согласие было достигнуто за неделю - это обычно занимает от месяцев до года или больше, если вы следовали «правильному» способу предложения слияния. В настоящее время некоторые пользователи будут! Голосовать «сохранить: слияние следует обсудить в другом месте», и я бы сказал, что чаще всего обсуждение не происходит в другом месте.

I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891 ^Talk _Work 23:22, 25 January 2021 (UTC)

• To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891 ^Talk _Work 23:38, 25 January 2021 (UTC)

  Eddie891 , я согласен (как я надеюсь, что все согласны), что система предложений слияния явно нарушена и нуждается в какой-то реформе. Я оставлю это другим, более знакомым, чтобы решить, является ли объединение его в AfD лучшим подходом, но я собираюсь попробовать что-то , и в худшем случае это не удастся, и мы вернемся к статус-кво.

  Поскольку это разработанное и действенное предложение, вы можете переместить его в WP: VPR , поскольку лаборатория идей не место для! Голосования. {{u | Sdkb }}  ^talk 03:18, 26 января 2021 г. (UTC)

• I think we should redirect RMergers to AFD and be done with it. (Regardless of that opinion, we should also make it doubly clear somewhere on WP:Deletion policy and/or WP:ATA and/or WP:AFD/AI that not-votes like "AFD is not for merging" get kicked to the curb.) --Izno (talk) 03:58, 26 January 2021 (UTC)
• Я полностью согласен с тем, что АдГ должен служить центральным звеном в работе, если только кто-то не представит веские причины для бюрократии, которая имеет полностью отдельные и неперекрывающиеся (по политике, если не на практике) процедуры слияния, удаления, составления и т. обсуждение любой статьи, которая, по мнению людей, не должна быть статьей - будь то «это должно быть перенаправление», или «ее следует объединить», или «это слишком рано, поэтому доработайте». -bɜ: ʳkənhɪmez ( Пользователь / привет! ) 04:09, 26 января 2021 г. (UTC)
• Я обеспокоен фактическим исполнением, а также разбавлением участия АдГ большим количеством статей о слиянии. Хотя обсуждение и закрытие не занимают слишком много времени, слияние требует больших усилий. Я не делаю АдД, которые имеют вероятный результат слияния, так как я не хочу их объединять, и без согласия кого-либо на это (скажем, nom), это рискует завершить обсуждение без фактического слияния разумные сроки. Nosebagbear ( разговор ) 10:15, 27 января 2021 (UTC)

  Однако даже в этом сценарии вы все равно получаете решение, и любой может действовать, не теряя двусмысленности. И это решение своевременное, и по статье видно, что статья давно в зубе. RFM похож на AFC, но могут пройти годы, а не месяцы, прежде чем вы узнаете. - Изно ( разговор ) 18:28, 27 января 2021 (UTC)

  Наибольшую роль в разбавлении AFD играет то, что пользователи проводят большие серии номинаций из 20+ статей за один день. Пока в январе было предложено 200 слияний, или около семи в день. Я не считаю, что добавление их к 100+ AFD, регулярно назначаемых каждый день, может привести к подавлению этого процесса. Eddie891 ^Talk _Work 18:35, 27 января 2021 (UTC)

  @ Eddie891 : Я бы не сказал, что рассуждения полностью чугунные. Вы хотели бы это изменение, потому что оно упростит выполнение слияний, предположительно поощряя больше. Это логически увеличило бы цифры намного больше, чем 7 / день (что было бы примечательно, но определенно терпимо). Если бы это не привело к резкому увеличению, то, вероятно, не стоило бы вносить изменения. Nosebagbear ( разговор ) 10:35, 29 января 2021 (UTC)

• Я редактирую WP с 2006 года ... и я даже не знал, что существует отдельный процесс слияния! Это определенно не получило широкой рекламы (когда это было создано?). У меня нет проблем с рассмотрением спорных предложений о слиянии через AFD. Зачем нам нужны две отдельные бюрократии? Blueboar ( разговор ) 13:19, 27 января 2021 (UTC)

  Вероятно, потому что он указан где-то в PEREN. : ^) - Изно ( разговор ) 18:28, 27 января 2021 (UTC)

• Кажется маловероятным, чтобы какой-либо опытный редактор не видел и не присутствовал на обсуждении слияния, подобном тому или иному . Я вспоминаю г-на Журдена, который с удивлением узнал, что всю жизнь говорил прозой, даже не подозревая об этом! Эндрю 🐉 ( разговор ) 09:37, 30 января 2021 (UTC)

• Комментарий : Общий объем невыполненных статей, подлежащих объединению, теперь составляет менее 12 месяцев (раньше это было более 2,5 лет), а объем невыполненной работы АдГ, в результате которого было принято решение о слиянии, снова составляет менее 90 дней и быстро сокращается. Просто чтобы вы знали. Всем, кто хочет помочь, теперь у вас есть для этого ссылки. С уважением, G en Q uest ^"scribble" 18:50, 27 января 2021 г. (UTC)
• Прокомментируйте , у меня такие же опасения, что и у Nosebagbear, но я вижу достоинства в идее о том, что вероятные оспариваемые кандидатуры могут быть выдвинуты в АдГ, а номинант предлагает слияние. Однако я бы выступил против всего, что помешало бы редакторам проводить смелые слияния / перенаправления (очевидно, что жирное удаление недоступно для большинства из нас по уважительной причине), в случае оспаривания они могут быть официально назначены (как это происходит сейчас). Кавалерист ( разговор ) 11:50, 29 января 2021 (UTC).
• I've never really understood why they're separate. If anyone wishes to only watch for deletion discussions or only watch for merger proposals, that can be handled via one of the several ways we already organize AfDs. AfDs don't get lost in talk page archives, are more centralized, and have a structure that can already result in merger. I say take this opportunity to reduce our number of complicated processes. Or perhaps try it out for a while? — Rhododendrites ^talk \\ 02:42, 30 January 2021 (UTC)
• Oppose Let us count the ways:

1. Mergers are inherently unproductive because they just move content from one page to another with low value-added
2. Mergers can mostly be done by anyone using ordinary editing tools, just as anyone can add, remove or move a section in an article
3. Deletion however is a specially restricted function because it makes the content inaccessible and is not easy to revert
4. AfD exists primarily for deletion, providing the clear consensus required for admins to use this specially restricted function
5. AfD is moribund too because it's no fun looking at junk
6. The longer the AfD list, the less likely that people will look through it and so participation will decline further
7. Already we see lots of AfD discussions being relisted again and again for lack of participation
8. AfD tends to attract zealots who tend to vote delete as a knee-jerk reflex, without regard to the merits of the topic and its potential
9. The proposal therefore risks turning mergers into deletions and content will be lost
10. Существуют технические ограничения на размер ежедневных журналов AfD из-за интенсивного использования шаблонов.
11. Процесс АдГ не масштабируется ни с технической точки зрения, ни с точки зрения человеческого фактора.
12. Лучшее место для привлечения внимания к слияниям - проекты, в которых работают профильные эксперты.
13. Но проекты тоже умирают
14. Основная причина того, что все умирает, - это чрезмерная задница, поведение на поле боя, занятость и конфликты.
15. Нам нужно сосредоточиться на содействии сотрудничеству, сотрудничеству и созданию контента, а не на поиске новых и лучших способов раздражать друг друга.

Эндрю 🐉 ( разговор ) 08:21, 30 января 2021 (UTC)

• I agree with merging merges into AFD. One place to discuss what happens to a stand alone page (delete, draftify, merge, etc) seems to make the most sense and will avoid the duplication of effort and dilution of attention that happens now with multiple processes. Levivich ^harass/_hound 15:15, 4 February 2021 (UTC)
• Поддержка включения его в AfD. Даже не знала, что WP: PROPMERGE существует (обратите внимание, большинство обсуждений слияния, которые я закрыл на WP: ANRFC, тоже не использовали такой процесс, а были просто обычными обсуждениями на странице обсуждения). Мне кажется, это бесполезный процесс. Лично я бы в любом случае взял слияния типа «пустой и перенаправляемый» в AfD. Это централизованное место, которое позволяет достичь окончательных результатов, тогда как многие обсуждения на страницах обсуждения занимают гораздо больше недель и все же заканчиваются минимальным участием. Мне не нравится, что некоторые администраторы отказываются признать консенсус слияния imo, мотивируя это тем, что АдГ не поддерживает слияния, даже если АдГ достигнет консенсуса по слиянию. Эта часть, кажется, зависит от закрывающего администратора (некоторые разрешают это, другие нет и говорят "можно обсудить в другом месте », из того, что я видел).ProcrastinatingReader ( разговор ) 16:06, 4 февраля 2021 (UTC)
• Поддержка Единственное место, где такая дискуссия вообще может привлечь внимание, - это АдГ - хотя участие ниже, чем должно быть, оно по-прежнему является наиболее посещаемым из таких процессов. Поскольку в прошлом слияние использовалось как скрытый метод удаления, называя его слиянием, но на самом деле не слияние чего-либо существенного, это имеет смысл. Вероятно, мы должны указать, что действие в таких обсуждениях, если нет участия, - это не мягкое удаление, которое мы используем для статей, а слияние, как неоспоримое. И то, и другое легко обратимо, если возникнут проблемы. Как Левивичговорит, что достоинство АдГ состоит в том, что если спорить, то можно прийти к заключению. Да, AfD имеет тенденцию привлекать людей, которые пытаются найти причины для голосования за удаление, но она также привлекает тех, кто ищет любую возможность для сохранения. Представители каждой партии всегда были уверены, что они составляют борющееся меньшинство. Я не уверен, как это отразится на слиянии - каждая сторона иногда предлагает найти компромиссное решение. Слияния не являются неконструктивными - они перемещают информацию, но они устраняют часто значительное дублирование и все накладные расходы, связанные с тем, чтобы быть отдельной статьей. ~~

• Нет, АдГ часто не приходит к заключению. Часто АдГ закрываются из-за отсутствия консенсуса. Или предполагаемый консенсус не сохраняется. Например, сегодня я закрыл АдГ . Обратите внимание, что было 8 предыдущих обсуждений! И обратите внимание, что никто не предлагал объединить субъект в семью Кеннеди , хотя это была очевидная альтернатива. AfD поощряет враждебный экстремизм Keep / Delete, а не более сложные компромиссы. Андрей 🐉 ( разговорное ) 23:47, 11 февраля 2021 (UTC)

Eddie891 , Как постоянный клиент AfD , у меня нет проблем ни с результатом слияния, ни с номинатором, предлагающим слияние как одну из альтернатив. И вы правы, что обсуждение слияния идет намного медленнее. Однако мы не должны просто преобразовывать слияния в обсуждения АдГ, поскольку очевидно, что это процесс удаления, а не слияния. Вместо этого нам нужен процесс, подобный AfD, где слияния перечисляются в центральном каталоге, сортируются и получают большую видимость, чем сейчас. _{Петр Конечны, он же Проконсул Пиотрус | ответ здесь} 11:57, 12 февраля 2021 (UTC)

• Я не понимаю, почему у нас так много политик для слияния, AFD, Prod, это просто безумие. Новичкам это сложно, и я уже несколько лет то и дело просматриваю Википедию и все еще нахожу что-то, потому что это не самый простой макет. В отношении предыдущей политики AFD я заявил, что, по моему мнению, с Prod следует отказаться, а слияние следует интегрировать в политику и процесс AFD, чтобы пользователям было проще находить и обсуждать. Я знаю, что Эндрю прокомментировал плохое качество некоторых слияний, но это должно быть частью процесса AFD, т.е. если редакторы решат согласовать слияние, тогда его следует оставить открытым для обсуждения уровня слияния. Дэвидстюартхарви ( разговор ) 16:03, 14 февраля 2021 (UTC)

Защита от отложенных изменений избранной сегодня статьи [ править ]

Идея автоматического применения WP: Semiprotection к WP: Сегодняшняя избранная статья (TFA) была избита до смерти; см. WP: PERENNIAL # Защита сегодняшней избранной статьи на главной странице . Я думаю, что последнее обсуждение было в июле 2020 года на WT: Сегодняшняя избранная статья / Архив 14 # Вопрос о защите . Ключевой аргумент (во всяком случае для меня) заключается в том, что мы меньше всего хотим отговаривать новых редакторов.

Тем не менее, всякий раз, когда статья с намеком на споры является TFA, она появляется на WP: ANI . Некоторые недавние примеры см. В Википедии: Доска объявлений для администраторов / IncidentArchive1057 # Холокост в Словакии - TFA, подверженная продолжающемуся вандализму (27 января 2021 г.), Википедия: Доска объявлений для администраторов / IncidentArchive1057 # Guadeloupe amazon - Сегодняшняя TFA подвержена продолжающемуся вандализму (28 января 2021), Википедия: Доска объявлений для администраторов / IncidentArchive1057 # Pyramid of Nyuserre - Сегодняшняя TFA подвергается постоянному вандализму (30 января 2021 года) и WP: ANI # пророчество Гитлера - TFA подвергается продолжающемуся вандализму (30 января 2021 года). Они также могут быть размещены на WP: AIV., который труднее искать. Я не видел сообщений о проблемах со статьями WP: DYK .

Во время последнего обсуждения я предположил, что TFA может быть WP: ожидающие изменения-protected for only so long as it is on the Main Page; and this idea seems to be new. IPs and unconfirmed editors would be able to post, even if their contributions didn't display immediately; and vandalism could be speedily dispatched where it belongs. A TFA's godaprents could be encouraged to help the regular pending changes patrollers. It would also solve the problem of working out when the vandalism occurred and who did it (a perennial problem with the small amount of vandalism I deal with - mostly involving links to DAB pages - which can be buried behind several recent good edits and require copy&paste from the last good version). It shouldn't be technically difficult to implement; it could be part of the script which adds articles to and removes them from the Main Page. Some other editors seem to like the idea, and it was suggested that I open a discussion here. (For the record - I'm in favour.) Нарки Блерт ( разговорное ) 10:36, 2 февраля 2021 (UTC)

Я отмечу, что одна из основных причин отказа от использования auto semi на TFA в прошлом - это создание впечатления, что Википедия не так свободна для редактирования, поскольку наша самая видимая страница не редактируется для большей части аудитории TFA. Защита отложенных изменений позволяет избежать этого, позволяя пользователям вносить изменения, даже если есть небольшая задержка с публикацией их в реальном времени, поэтому это был бы достойный компромисс между неограниченным доступом и максимальной доступностью для нашей наиболее заметной страницы и избежанием бесполезной траты ресурсов. время сообщества и потенциальный риск того, что плохой контент будет выставлен на всеобщее обозрение. С уважением, Пользователь: TheDragonFire300 . ( Свяжитесь со мной | Взносы ). 11:01, 2 февраля 2021 г. (UTC)

В качестве дополнительной мысли - текст шаблона защиты должен быть адаптирован для TFA и приветлив. Нарки Блерт ( разговорное ) 13:35, 2 февраля 2021 (UTC)

И еще один - WP: ANI # Pacific swift - Сегодняшние TFA получили высокий уровень IP-вандализма (4 февраля 2021 г.). Нарки Блерт ( разговор ) 08:59, 5 февраля 2021 (UTC)

Еще один, защита которого была отклонена - WP: ANI # Cheadle Hulme - Сегодняшние TFA получают высокий уровень IP-вандализма (5 февраля 2021 г.). Нарки Блерт ( разговорное ) 11:42, 7 февраля 2021 (UTC)

Это все изменения, внесенные в Cheadle Hulme за день в TFA . Я вижу в общей сложности двух IP-вандалов, один из которых внес два изменения, а другой - одно, а все остальные изменения IP являются конструктивными. Если бы какой-нибудь администратор защитил его при таких обстоятельствах, то, если бы я что-то не пропустил, их немедленно отправили бы в Arbcom за злоупотребления со стороны администратора. -  Радужный 12:37, 7 февраля 2021 г. (UTC)

Я не администратор и не комментирую, должна ли какая-либо конкретная страница быть защищена или нет. Тем не менее, я счел правильным размещать здесь все соответствующие сообщения ANI с тех пор, как я начал это обсуждение, независимо от того, помогают они моему предложению или вредят. Все свидетельства важны для достижения консенсуса. (Я не отслеживал WP: AIV или WP: RFPP , что было бы намного сложнее.) Нарки Блерт ( выступление ) 20:10, 19 февраля 2021 г. (UTC)

Еще один - WP: ANI # Apollo 14 - Сегодняшние TFA получают высокий уровень вандализма IP и неконтролируемого контента (8 февраля 2021 г.). Нарки Блерт ( разговор ) 12:53, 9 февраля 2021 (UTC)

И еще один - WP: ANI # Bernard A. Maguire - Сегодняшний TFA подвергся постоянному вандализму (11 февраля 2021 г.). Нарки Блерт ( разговорное ) 00:23, 12 февраля 2021 (UTC)

WP: ANI # Вандализм в отношении чеканки Мемориала Гранта TFA (12 февраля 2021 г.). Нарки Блерт ( разговор ) 05:42, 13 февраля 2021 (UTC)

Другой - WP: ANI # Vandalism on Saturn (журнал) (14 февраля 2021 г.). Нарки Блерт ( разговор ) 07:30, 14 февраля 2021 (UTC)

Сегодняшний выпуск - WP: ANI # Vandalism on Silesian Wars (15 февраля 2021 г.). Когда об этом сообщили в ANI, на главной странице оставалось всего несколько часов. Cluebot и около шести зарегистрированных редакторов уже внесли в него правки; добавить защитного администратора, и это много работы.

Я заметил кое-что, чего раньше не замечал - User: TFA Protector Bot застрял {{ pp-move }} в статье 26 января с автоматическим истечением срока действия в полночь 15 февраля. Нарки Блерт ( разговорное ) 17:34, 16 февраля 2021 (UTC)

@ Narky Blert : В течение нескольких лет для всех будущих TFA (которые еще не имеют защиты от перемещения) было нормально получать краткосрочную защиту от перемещения, срок действия которой истекает в тот момент, когда статья перестает быть TFA. До ноября 2013 года это был ручной процесс; с тех пор это было поручено TFA Protector Bot, см. BRFA . Эта защита обычно применяется заранее (я думаю, вскоре после утверждения календарного слота), см. Журнал бота ; и использование дополняет это. - Red rose64 🌹 ( обсуждение ) 22:33, 16 февраля 2021 (UTC){{pp-move}}

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

Также - WP: ANI # Вандализм по метеорологической истории урагана Дориан (19 февраля 2021 г.). Нарки Блерт ( разговор ) 20:00, 19 февраля 2021 (UTC)

And another two - WP:ANI#Vandalism on SS Mauna Loa (19 February 2021) and WP:ANI#Multiple IPs adding porn or offensive image in supposedly TFA article (20 February 2021). On the second one, I count (among other reversions) seven WP:REVDELs while the article was on the main page. Narky Blert (talk) 00:53, 21 February 2021 (UTC)

PC is widely agreed not to work/be practical on highly edited pages. That's why no one suggests it, probably. --Izno (talk) 15:44, 2 February 2021 (UTC)

This is something that was proven during the PC backdoor attempt, by the Barack Obama and George W. Bush articles. The volume of edits was so high that the queue on those articles were perennially backlogged, and so it was and still is agreed that PC is not suitable for pages that would see high volumes of edits, something which would happen with TFA as a matter of course. —A little blue Bori v^_^v ^{Takes a strong man to deny...} 16:43, 2 February 2021 (UTC)

At least the TFAs as considered in this discussion. I have seen some fairly quiet TFAs of late. --Izno (talk) 17:17, 2 February 2021 (UTC)

Unfortunately I suspect the set of TFAs that would be suitably quiet for PC to work is almost identical to the set of TFAs where PC is not needed. Thryduulf (talk) 01:30, 3 February 2021 (UTC)

As a supporter of the proposal, and an active PCR, I don't think this would be insurmountable for most TFAs. I note that the two given examples are highly political topics, one of whom was at the time President of the United States and the other of whom had been less than a full term ago. Vaticidalprophet (talk) 06:04, 3 February 2021 (UTC)

Я против превентивной защиты любого рода, особенно ожидающих изменений, которые заставляют добровольцев больше работать и редко приносят пользу. - WUG · а • ро · дез 1:53, 3 февраля 2021 (UTC)

• Поддержите какую-то защиту . Недопустимо, чтобы редакторы (очень предсказуемо!) Вандализировали такие статьи, как «Холокост в Словакии», пока они находятся на главной странице. Это подрывает нашу репутацию намного больше, чем любая защита. ( t · c ) buidhe 04:16, 3 февраля 2021 (UTC)
• I should note that "highly active" is a fairly low boundary - PCR starts having real issues well before, say, editors would be frequently edit-conflicting. I'm also not sure how accurate a prediction of a TFA's likely edit rate we can do. Obviously we can predict the "very active" and "not likely to be edited much" buckets, but there'd be a large middle category that is tough to order. As such, I continue to believe PCR remains distinctly problematic for any TFA use that would actually warrant PCR. Nosebagbear (talk) 07:35, 3 February 2021 (UTC)
• To be honest, I'm not totally against this. The utility of pending changes is different from semi-protection: the goal is not to reduce the workload for administrators and recent change patrollers (as others have correctly pointed out above, pending changes effectively does the opposite), but rather, to prevent the vandalism from being seen by readers and thus possibly bringing the project into disrepute. As a matter of fact, if my memory serves me right, for a brief period a few years ago, we actually did start preemptively putting PC protection on the TFA after an WP:ANобсуждение из-за особенно неприятного LTA, который заменит изображения на TFA на чрезвычайно шокирующие. Традиционные проблемы с ПК на сильно отредактированных страницах не кажутся здесь большой проблемой, потому что защита будет длиться только один день, а большинство TFA, похоже, не редактируются так часто, что большие задержки могут стать проблемой. По крайней мере, я бы, наверное, поддержал пробный период этой идеи. Mz7 ( разговорное ) 07:53, 3 февраля 2021 (UTC)

  Если подумать об этом немного дальше, я думаю, уместным будет вопрос о том, как часто вандализм остается незамеченным дольше, чем, скажем, минуту на TFA. Незавершенные изменения лучше всего подходят для статей, в которых вандализм трудно быстро отменить, и теперь, когда я думаю об этом, поскольку TFA уже уделяет этому много внимания в целом, возможно, что большая часть вандализма уже устранена внутри секунды, что делает потребность в ожидании изменений спорное. Mz7 ( разговорное ) 08:02, 3 февраля 2021 (UTC)

Насколько я могу судить, вандализм TFA редко, если вообще когда-либо, отменяется в течение нескольких секунд. Я слышал в среднем около 10-15 минут, что достаточно, чтобы создать проблемы для этих статей, особенно с тяжелым или гротескным вандализмом. Vaticidalprophet ( разговор ) 11:39, 3 февраля 2021 (UTC)

Глядя на истории редактирования статей, которые я упомянул в первом абзаце (очень маленькая статистическая выборка): если ClueBot заметит это, в течение нескольких секунд; для человека - 1-40 минут (в среднем 8). Нарки Блерт ( разговорное ) 14:24, 3 февраля 2021 (UTC)

Я думаю, что уместным будет вопрос, как часто вандализм остается незамеченным дольше, чем, скажем, минуты на TFA. Это ключевой вопрос для меня. Если наша цель - не допустить нарушения работы читателя, нам необходимо знать, сколько вандализма в настоящее время мешает читателям. Я не думаю, что испытание изменит нашу способность смотреть на это, нам просто нужен кто-то, чтобы вычислить цифры из истории страниц. Его также можно скрестить с дневными посещениями страниц, чтобы оценить количество читателей, которые действительно видели вандализм, например, этот вандализм длился 5 минут, так что всего 60 тысяч просмотров страниц в тот день --- вероятно, 5 тысяч человек видел это вместо статьи. In my experience it's as you describe with the added eyes bringing faster reversions, but knowing the average and other statistics would be useful and quite possibly change my mind. If PC protection really is a substantial benefit, I'd be willing to support its use on TFA. It at least allows users without accounts to edit, and if we craft a nice message as Narky suggests, it could minimize the potential newbie biting. So my main concern in this case is usefulness because I've rarely seen PC solve more problems than it caused. — Wug·a·po·des​ 20:13, 3 February 2021 (UTC)

(Я полагаю, что математика в вашем примере не предназначена для буквального понимания, но 5 минут 60 000 просмотров страниц - это примерно 209 просмотров - 5000 будут 60 000 в час . Ограничением этого подхода является то, что вандализм длится дольше, чем меньше просматриваемая страница есть, и просмотры страниц различаются в зависимости от часовых поясов в регионах, откуда большинство наших читателей. Но я думаю, что какой-то API где-то может дать вам почасовые просмотры страниц.) - Билорв ( доклад ) 20:43, 4 февраля 2021 (UTC)

• Поддержка защиты отложенных изменений в качестве пробной : TFA отличается от других популярных страниц тем, что, скорее всего, там есть очень активный редактор, увлеченный статьей (тот, кто только что повысил ее до FA), а активность ограничена 24 часов (может быть, и в ближайшие несколько дней, пока ссылка на него все еще находится на главной странице). Я не могу говорить за всех таких редакторов (я был этим человеком только однажды), но, возможно, некоторые смогут просмотреть все изменения, по крайней мере, после того, как осядет пыль, и собрать любые изменения, которые являются продуктивными. Контраргумент состоит в том, что TFA - это хорошо известные статьи, и поэтому вероятность возникновения проблем, которые смогут решить новые и незарегистрированные пользователи, гораздо меньше. Но, вероятно, все еще есть небольшие улучшения в прозе, которых можно было бы ожидать в период TFA. Альтернативой может быть превентивная полузащита только некоторых TFA в зависимости от темы. - Билорв ( разговорное ) 20:43, 4 февраля 2021 (UTC)
• Поддержка Внесено мало полезных изменений, вандализм - серьезная проблема не из-за количества вандалов, а из-за того, что мы получаем синяк под глазом, когда размещаем его на первой странице. Объем изменений, о которых идет речь, невелик. Так что это отличное использование ПК. Hawkeye7 (обсуждение) 04:33, 5 февраля 2021 (UTC)
• Поддержка , на мой взгляд, это идеальный баланс между сохранением целостности нашей мантры «любой может редактировать» и качеством наших избранных статей. Я склонен согласиться с Ястребом в том, что «сделано несколько полезных изменений» - до такой степени, что количество вандализма или бесполезных правок значительно превосходит количество случайных случайных исправлений орфографии (и любые серьезные правки / ошибки в любом случае лучше обсуждать на странице обсуждения) . Но в любом случае эта защита может устранить как вандализм, так и иногда полезные правки. Aza24 ( разговорное ) 09:07, 5 февраля 2021 (UTC)
• (nom) Я согласен с тем, что любые изменения должны быть пробными.

Моя идея для текста шаблона выглядит примерно так: «Добро пожаловать в сегодняшнюю избранную статью. К сожалению, эти статьи привлекают вандалов. Поэтому изменения, внесенные новыми редакторами, проверяются опытными редакторами, прежде чем они появятся для всеобщего обозрения. Обычно это занимает всего несколько минут. Если вы здесь, чтобы стать частью сообщества, цель которого - улучшить Википедию - спасибо и удачного редактирования! Возможно, вы найдете справку: отредактируйте полезное руководство для начинающих. Если вы здесь только для того, чтобы disrupt - прочь! " Нарки Блерт ( разговорное ) 18:04, 5 февраля 2021 (UTC)

• Поддержка предотвратит мгновенную публикацию токсичных материалов или материалов, защищенных авторским правом, в таких популярных статьях. ~ HAL 333 02:58, 6 февраля 2021 г. (UTC)
• После уведомления, я еще не сказал об этом прямо здесь, поддерживаю как одну из сторон первоначального разговора. Ватицидальный пророк ( разговор ) 13:53, 6 февраля 2021 (UTC)
• Против . Защита ПК требует значительного объема работы с минимальной пользой и не работает на страницах с большим объемом редактирования; те страницы, которые привлекают достаточно вандализма, чтобы сделать защиту стоящей, также будут теми страницами, на которых ПК не будет работать. ПК также имеет существенные дополнительные недостатки в дополнение к создаваемому им невыполненному техническому обслуживанию; нет возможности добавить резюме при отклонении редактирования, поэтому, отклоняя добросовестное, но несоответствующее изменение, невозможно объяснить причину в сводке редактирования; при проблемах с BLP ПК оказывает небольшое влияние, поскольку не влияет на то, что обрабатывает Google (они выбирают самую последнюю версию, даже если она не была одобрена); для утверждения / отклонения изменений в статье на уровне FA часто требуются специальные знания по теме,что горстка людей, которые работаютSpecial: очередь PendingChanges вряд ли будет; все предложение, по-видимому, основано на идее, что все или, по крайней мере, большинство ФА будут в списках наблюдения людей, а это не так. -  Радужный 08:00, 7 февраля 2021 г. (UTC)

(Интересно видеть вас здесь - мне буквально просто было интересно, что вы подумаете об этом предложении.) Что бы это ни стоило, "нет возможности добавить резюме при отклонении редактирования, поэтому при отклонении добросовестного, но неуместного редактирования невозможно объяснить, почему в сводке редактирования "неверно - поле сводки редактирования ... да, очередь ПК пуста, пока мы говорим, поэтому мой план сделать снимок экрана для" прямо здесь "придется подождать, но он размещен на видном месте с огромным жирным шрифтом: «ДОБАВИТЬ РЕДАКТИРОВАТЬ РЕЗЮМЕ, ЕСЛИ ТО, ЧТО ВЫ ОТМЕНАЕТЕ НЕ ЯВЛЯЕТСЯ ВАНДАЛИЗМ». Vaticidalprophet ( разговор ) 06:37, 8 февраля 2021 (UTC)

Вместо скриншота самого поля сводки редактирования, вот скриншот из моих недавних публикаций PCR, показывающий их. Vaticidalprophet ( разговор ) 06:42, 8 февраля 2021 (UTC)

Вызывает тревогу, как отдельная вещь, узнать, что Google очищает самую последнюю версию на страницах PCP, хотя я понял, что это имеет небольшую задержку по общим причинам вандализма (возможно, просто Google требуется несколько минут, чтобы очистить статья снова). Однако это проблема Google, а не наша. Я никоим образом не хочу, чтобы у них было единоличное право голоса при принятии решений. Они должны меняться под нас, а не наоборот. Другие поисковые системы являются доступны. - Билорв ( разговор ) 00:56, 13 февраля 2021 (UTC)

Примерно в 2014 году мне сказали, что Google очищает известную социальную сеть каждые 20 минут. Нашей целью как модераторов-добровольцев было за это время избавиться от крупного коммерческого спама. IDK, если это типичное число, но наш лидер попытался, но не смог заставить их увеличить его до 30. Нарки Блерт ( разговор ) 06:05, 13 февраля 2021 (UTC)

• Support The only backlog this would generate in terms of PC is one page which would need to be checked regularly for the duration (and, well, PC isn't that large of a backlog, compared to some other places). And, well, while it might not stop everything, at least any vandalistic edit (which would need to be reverted anyway, PC or not) won't be prominently displayed to every person who gets there... RandomCanadian (talk / contribs) 01:21, 12 February 2021 (UTC)
• Support as a pending-changes reviewer, I think the added workload would be minimal compared to the benefits. With the number of eyes on the page, good changes will be accepted quickly, while bad ones won't be prominently linked from the main page. Elliot321 (talk | contribs) 05:57, 14 February 2021 (UTC)
• Поддержка - это кажется мне разумным компромиссом, который позволяет IP-адресам редактировать TFA и бороться с вандализмом. Другими словами, это наименее ограничительный способ эффективной защиты наших самых известных статей. (Защита одной статьи в день, конечно, не приведет к перегрузке ПК, и статья в любом случае будет широко отслеживаться.) Давайте по крайней мере попробуем эту схему: я думаю, это будет эффективно. Внеочередное письмо ( разговор ) 07:18, 14 февраля 2021 (UTC)
• (nom) Чтобы повторить то, что я высказал ранее, на случай, если он может потеряться. В этой идее есть и пряник, и кнут. Это даст возможность быстро приветствовать новых редакторов и указать им правильные направления. Опытные редакторы знают, где искать или обратиться за помощью; новички, по определению, этого не делают. Нарки Блерт ( разговор ) 07:50, 14 февраля 2021 (UTC)
• Поддержка . Речь идет о балансе положительной репутации Википедии как энциклопедии «любой может редактировать», против потенциальной негативной репутации вандализма и неточностей, которые вносятся и не обнаруживаются. Я думаю, что защита от ожидающих изменений - отличный компромисс, позволяющий людям редактировать, но предотвращающий появление глупой чуши в нашей самой известной статье дня. ƒirefly ( t · c ) 14:02, 14 февраля 2021 г. (UTC)
• Поддержите как пробу . Я согласен с RandomCanadian, короткий период времени с защитой отложенных изменений не создаст большого количества бэклога, и так много внимания уже уделяется TFA.
  Однако мне было интересно (именно поэтому я впервые голосую здесь, в Village Pump), где можно предложить совершенно новый тип защиты? Потому что что, если бы вместо того, чтобы помещать ожидающие изменения в TFA, была бы защита «отложенных изменений»? В основном это будут отложенные изменения, но с автоматическим утверждением по прошествии некоторого установленного времени. Установите время, немного большее, чем средняя длительность, необходимая для отмены вандализма, и я готов поспорить, что это резко снизит рабочую нагрузку в дни сильного вандализма, не внося вклад в список отложенных изменений. Это будет защита только для TFA (случай страницы с высокой видимостью / трафиком в течение короткого периода времени). Но так как это необходимо создать и не о назначении существующей защиты, это 'Скорее предложение о реализации в будущем. -Pinchme123 ( разговор ) 01:27, 18 февраля 2021 (UTC)

  @ Pinchme123 : запросы на добавление функций следует отправлять в Phabricator . - Red rose64 🌹 ( обсуждение ) 14:26, 18 февраля 2021 (UTC)

@ Redrose64 : Спасибо, что указали мне на Phabricator, так как я не знал об этом заранее. Но мой вопрос не о «отправке» запроса функции, а о том , чтобы предложить его для обсуждения перед запросом. Я не вижу особого смысла запрашивать новую фичу без обсуждения ее достоинств, особенно когда кажется, что запросы фичи делаются за пределами WP (поскольку Phabulator - это просто дочерняя организация Викимедиа, и мне пришлось создать новую учетную запись просто чтобы увидеть страницу создания запроса функции). Итак, где я могу предложить эту функцию для обсуждения? - Pinchme123 ( разговор ) 16:16, 18 февраля 2021 (UTC)

• Противоположно , согласно радужному, а также из-за общего принципа использования TFA, чтобы выделить принцип «кто угодно может редактировать». Редактирование с задержкой - это не то же самое, что редактирование с немедленным воздействием, а использование ПК на такой заметной странице может повредить набору персонала. - Яир Рэнд ( разговор ) 06:25, 18 февраля 2021 (UTC)
• Комментарий . Я в коленном рывка противостоять лагерь за Переливающимся и Яир рандов, но я вижу проблему адаптации наших процессов , как мы развиваемся из «энциклопедии , которую может редактировать » в " энциклопедию , которую может редактировать". Если мы хотим использовать TFA для найма, то редактирование должно быть видно (почти) немедленно; более 30 секунд, я думаю, отнимут тот небольшой всплеск радости, который привел меня к редактированию здесь. Я считаю, что один из основных Проблемы, с которыми сталкивается Википедия по мере созревания, - это разрушение базы редакторов, поскольку становится все труднее и труднее попасть в дверь в качестве нового редактора. Есть ли какие-либо доказательства того, что новички берутся за редактирование через TFA? Я видел несколько новых редакторы конвертировали через ITN, но редко через другие разделы главной страницы. Мои DYK иногда вносили существенные или исправляющие опечатки правки с помощью красных ссылок или IP-адресов, которые явно интересовались темой, и я даже очень иногда получал комментарии благодарности или осуждения с IP-адресов.Лично я ненавижу ожидающие изменения и почти никогда не принимаю существенные изменения, потому что на меня ложится бремя ответственности за них, и я знаю, что у других есть такая же проблема. Есть ли какой-то опосредованный ботами механизм, который мог бы немедленно автоматически принимать все, что выглядело добросовестно и не было явно проблемным? Можно ли настроить Cluebot для немедленного запуска при каждом редактировании TFA?Espresso Addict ( разговор ) 12:19, 18 февраля 2021 (UTC)

RFC: необходимо удалить определенное содержимое поля наследования [ изменить ]

Должны ли мы удалить содержимое поля наследования, например следующее? Примеры: «Самый пожилой британский премьер-министр» . Что вы все скажете? GoodDay ( разговор ) 21:57, 4 февраля 2021 (UTC)

Обзор (поля наследования) [ править ]

• Yes. We ought not to have any of that trivia in succession boxes. There are often many boxes, dozens even, and additional clutter is unhelpful. One would be very hard-pressed to find reliable sources discussing how James Callaghan "succeeded" Alex Douglas-Home as the oldest British prime minister, and I dare say that no biography of either of them mentions it. Surtsicna (talk) 22:15, 4 February 2021 (UTC)
• Yes. Only posts with transitions (or successions) would need succession boxes. -- Kautilya3 (talk) 22:56, 4 February 2021 (UTC)
• Не здесь . Мелочи нужно удалить, мелочи быть не должно. Вопрос о том, является ли какая-либо конкретная преемственность мелочью, требует индивидуального обсуждения на соответствующем форуме - этого форума здесь практически нет. Тридуульф ( разговор ) 02:21, 5 февраля 2021 (UTC)
• Нет. Как говорит Тридюульф, тривиальные должны быть, нетривиальные - нет. Это нужно делать в индивидуальном порядке. - DJSasso ( разговор ) 18:03, 5 февраля 2021 г. (UTC)
• Да, я считаю, что поля наследования вообще не нужны, поскольку они обычно дублируют информационное окно, навигационное окно и / или текст. Когда это не дублирует, как этот пример, это часто тривиально, что не требует коробки для себя. ^{Обсуждение} Reywas92 19:36, 5 февраля 2021 (UTC)
  • Вы их не любите , а я считаю четкое и последовательное изложение чрезвычайно полезным. Блоки преемственности, информационные блоки, навигационные блоки и проза служат разным функциям, поэтому одна и та же ссылка, появляющаяся более чем в одном месте, - это хорошо. Некоторые поля наследования следует удалить, но большинство - нет. Что происходит с любым заданным ящиком наследования, может быть определено только путем согласованного обсуждения данного поля наследования. Тридуульф ( разговор ) 01:04, 6 февраля 2021 (UTC)
• Yes and would support getting rid of them all. Redundant and pointless clutter. Why not have separate boxes for marriages, spouses, and works dispersed througout the article while we're at it? ~ HAL333 02:50, 6 February 2021 (UTC)
  • What are they redundant to? Links in prose and links in succession boxes have different purposes so they are not redundant to each other. Boxes (for anything) scattered throughout the prose would be completely disruptive to the prose, which is why succession boxes are not placed in the middle of the prose? Thryduulf (talk) 11:58, 6 February 2021 (UTC)
• Да - не уверен, что они нам даже нужны для позиций, но определенно не для превосходной степени. Levivich  ^харасс / _гончая 17:22, 6 февраля 2021 (UTC)
  • Все в превосходной степени? А как насчет самых высоких зданий и самых длинных мостов? Мне эти коробки кажутся чрезвычайно полезными. Тридуульф ( разговор ) 18:24, 6 февраля 2021 (UTC)
• Комментарий : я считаю, что обоснованность или тривиальность блоков наследования следует обсуждать в каждом конкретном случае на соответствующей странице обсуждения. Не уверен, чего может достичь глобальное решение, так или иначе по «тривиальным» блокам преемственности, когда оно ничего не делает, чтобы установить, что тривиально, а что нет. PraiseVivec ( обсуждение ) 14:01, 7 февраля 2021 (UTC)
• Yes for purely trivia succession box such as "oldest living X" - unless said role is notable in its own right (not sure if this actually applies anywhere). Elliot321 (talk | contribs) 05:54, 14 February 2021 (UTC)
• Yes certain ones should be deleted. At a minimum, the spirit of WP:NAVBOX #4 seems applicable: There should be a Wikipedia article on the subject of the succession box.—Bagumba (talk) 10:11, 22 February 2021 (UTC)
• Зависит - Да, для «преемственности» «пожилых британских премьер-министров» в качестве пустяка, но без обсуждения других это будет зависеть от конкретного случая, это не должно использоваться в качестве консенсуса для удаления не цитируемых примеров. KylieTastic ( разговор ) 10:15, 23 февраля 2021 (UTC)

Обсуждение (поля наследования) [ править ]

• Почему? Иванвекторская белка ( ^{деревья} / _орехи ) 22:17, 4 февраля 2021 г. (UTC)

  Потому что это не политические или партийные офисы. Они просто тривиальны. GoodDay ( разговор ) 22:19, 4 февраля 2021 (UTC)

  Зачем нам нужна глобальная политика или руководство или что-то еще по этому поводу? Если вы думаете, что данное поле преемственности является пустяком, обсудите это конкретное поле преемственности где-нибудь (страница обсуждения, WikiProject, TfD, есть много мест). Я искренне не понимаю, чего вы здесь пытаетесь достичь - нет никаких шансов, что будет достигнуто согласие относительно того, что у нас должны быть коробки преемственности для всего (бесспорный пример 10-го места квалификации в гонке British Touring Car Championship), но с формулировкой обсуждения вы не можете прийти к единому мнению (за или против) относительно какого-либо отдельного примера. Тридуульф ( разговор ) 02:18, 5 февраля 2021 (UTC)

  Вы ожидаете, что по каждой отдельной статье биографии будет отдельное обсуждение ? В любом случае, я не совсем понимаю, о чем вы пишете. GoodDay ( разговор ) 17:29, 5 февраля 2021 (UTC)

  Я ожидаю, что вы достигнете консенсуса по каждой отдельной преемственности. Это может быть страница обсуждения статьи или централизованное обсуждение. например, если вы хотите избавиться от старейшего живого премьер-министра Великобритании, вам необходимо обсудить, в частности, удаление поля преемственности «самый старый из ныне живущих премьер-министра Великобритании» из каждой статьи, в которой он появляется, с уведомлениями (по крайней мере) на странице обсуждения всех затронутых статей. Другими словами, вам нужно сделать то же самое, что и для любого другого массового изменения. Тридуульф ( разговор ) 22:26, ​​5 февраля 2021 (UTC)

  Это слишком много времени. В этих ящиках преемственности слишком много «бесполезных» тем, чтобы их можно было рассматривать по очереди. GoodDay ( обсуждение ) 22:30, 5 февраля 2021 г. (UTC)

  Централизованное обсуждение ящиков для пожертвований для старейшего из ныне живущих премьер-министра Великобритании можно было бы провести на Wikipedia talk: WikiProject Politics of the United Kingdom . - Red rose64 🌹 ( разговор ) 23:40, 5 февраля 2021 (UTC)

  Но пример британских премьер-министров - лишь один из примеров таких банальных тем в ящиках для ответов. GoodDay ( разговор ) 23:41, 5 февраля 2021 (UTC)

  Проблема в том, что мы понятия не имеем, какие еще блоки преемственности вы считаете тривиальными, поэтому мы (и, что наиболее важно, редакторы статей, в которых они публикуются) не можем узнать, согласны мы или нет. В то время как самый старый из ныне живущих премьер-министр Великобритании не кажется очень полезным, другие, такие как премьер-министр Соединенного Королевства, очень нетривиальны, и где провести границу между ними, необходимо определить на основе консенсуса. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC)

  Такие темы, как «Самый высокий президент страны» , «Самый толстый премьер-министр страны» , «Самый старый гонщик на серийных автомобилях» , «Самый молодой гонщик на 100 метров» , будут банальными темами для сук-боксов. GoodDay ( разговор ) 02:18, 6 февраля 2021 (UTC)

  Первые два, несомненно, были бы тривиальными, последние два, возможно, - все будет зависеть от того, придавалось ли этому какое-либо значение в надежных источниках. Однако короткий список тем (которые, как следует из беглого поиска, не используются), которые вы считаете тривиальными, никоим образом не способствует решению проблемы в моем комментарии. Тридуульф ( разговор ) 18:20, 6 февраля 2021 (UTC)

  Я не знаю, в чем ваша жалоба. Возможно, если вы приведете примеры тем из раздела «Блокнот», которые, по вашему мнению, следует и не следует удалять, это поможет. GoodDay ( разговор ) 18:26, 6 февраля 2021 (UTC)

  Я хочу сказать, что их нужно обсуждать индивидуально или в небольших, тесно связанных группах (например, возможно, блоки преемственности, связанные с премьер-министрами Великобритании). Независимо от того, сколько примеров приведено здесь, вы не можете прийти к единому мнению по поводу чего-либо, не указанного здесь, и чем больше примеров вы приведете здесь, тем больше вероятность крушения поезда. Тридуульф ( разговор ) 00:10, 7 февраля 2021 (UTC)

  RFC уже идет полным ходом. Посмотрим, чем это закончится. GoodDay ( разговор ) 00:47, 7 февраля 2021 (UTC)

  Консенсус в отношении того, что некоторые, но не все поля наследования следует удалить, но нет консенсуса в отношении удаления какой-либо из них - это потребует дальнейшего обсуждения. Это в значительной степени единственный способ , которым это может закончиться. Тридуульф ( разговор ) 02:20, 7 февраля 2021 (UTC)

  Кроме того, я считаю, что Wiki-проекты обычно привлекают меньше внимания. По той же причине рассматривал возможность переноса еще одного RFC в Village Pump. GoodDay ( разговор ) 23:55, 5 февраля 2021 (UTC)

  Ваше субъективное мнение о том, что что-то «занимает слишком много времени», не дает вам права игнорировать WP: CONSENSUS . Если вы предлагаете план действий в отношении WikiProject и рекламируете обсуждение на соответствующих страницах обсуждения, но никто не возражает по прошествии разумного времени (~ неделя), вы можете продолжить и удалить поля последовательности, перечисленные в обсуждении. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC)

  Если вы хотите рекламировать этот RFC в связанных проектах Wiki? тогда непременно сделайте это. GoodDay ( разговор ) 02:18, 6 февраля 2021 (UTC)

  Если бы это обсуждение на самом деле касалось конкретных ящиков преемственности, которые были бы уместны, но поскольку обсуждение на самом деле представляет собой пустую и несфокусированную попытку избавиться от неуказанного списка ящиков преемственности, которые лично вам (или, предположительно, любому другому редактору) не нравятся, то это невозможно знать, какие проекты и статьи актуальны. С другой стороны, если вы сделали соизволили перечислить эти коробки вы сочтете мелочи, то это бы я подозреваю , быстро стать Trainwreck из - за большое количество разрозненных ящиков редакторов будет иметь разные мнения о том . Тридуульф ( разговор ) 11:55, 6 февраля 2021 (UTC)

  Since my concerns grew out of the discussion at James Callaghan, one would link to Political WikiProjects. GoodDay (talk) 18:41, 6 February 2021 (UTC)

All should be delete as links spam due to duplication of links and undue because of overwhelming size. Never understood why we have giant boxes with very few links in them overwhelming the sections. It's definitely a point of contention for content editor that these undue boxes are spamed automatically without consideration of over linking or unwarranted linking.--Moxy 🍁 00:04, 6 February 2021 (UTC)

Очень просто, потому что многие (не все) поля наследования очень полезны для читателей. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC)

Не уверен, насколько полезно для читателей дублирование lnks и overwhelm разделов. У нас есть протоколы для этих 2 пунктов .... просто игнорируемые спамерами по шаблонам. - Предшествующий неподписанный комментарий, добавленный Moxy ( обсуждение • вклад ) 01:19, 6 февраля 2021 г. (UTC)

Смотрите мой ответ в разделе выше, почему дублирование не является проблемой, и я не согласен с тем, что презентация подавляющая. То, что некоторые блоки наследования являются пустяками, не означает, что все блоки наследования являются спамом. Тридуульф ( разговор ) 01:41, 6 февраля 2021 (UTC)

Нам просто придется не соглашаться. Только практика размещения указывает на очень низкую ценность для сообщества. См. Также ссылки, размещенные в нижней части статей, потому что они дублируют существующие ссылки, и формат не отвечает нигде в других статьях. Ужасно, что эти поля более заметны, чем фактические тематические навигационные поля. Странно, что они не были исключены из мобильной версии как нежелательная нагрузка - Moxy, 02:01, 6 февраля 2021 г. (UTC).

How does placement indicate they are low value? Of course the format is not appropriate anywhere else in the article - see also links and links in succession boxes have a completely different purpose to links in the prose. You need to explain why the duplication is problematic. Thryduulf (talk) 11:55, 6 February 2021 (UTC)

Вот почему у нас есть руководство по этому поводу ... отвлекает читателей от действительно важных ссылок . Википедия: кризис Overlink . Они настолько огромны, что редакторы прячут их в сворачиваемых шаблонах Авраам Линкольн # Внешние ссылки . Во многих других случаях их количество просто огромно ... массовый ссылочный спам Джон А. Макдональд # Внешние ссылки - Moxy, 17:59, 6 февраля 2021 г. (UTC)

Блоки тем в дополнение к запретам тем [ править ]

Now that we have the capability of blocking editors from editing specific articles, is there a way that we can bundle together all articles within a specific topic area (e.g. post-1992 American politics, COVID-19, Beyoncé) so that an editor who has been topic-banned from editing in those areas could in fact be blocked from editing pages deemed to fall within those areas? BD2412 T 21:19, 8 February 2021 (UTC)

Thought about this before, and imo it seems to be technically infeasible. There's no special way to determine whether an article is really within the AP2 editing area. There are talk page DS notices ({{Ds/talk notice}}), but anyone can place that so relying on it would be problematic (eg I'd be able to place that notice on a random article to block people from editing it. highly likely to be abused). Of course, this assumes that the page blocking functionality could work with categories or templates, which it can't. ProcrastinatingReader (talk) 21:26, 8 February 2021 (UTC)

Еще одна проблема - статьи, которые содержат как запрещенный, так и незапрещенный контент. Например, статья за любой год, начиная с 1992 года, будет включать контент как AP2, так и не AP2. _{подписали,} Rosguill ^{разговор} 21:30, 8 февраля 2021 (UTC)

У меня было две мысли по поводу конкретных подходов. Один может быть по дереву категорий, где Tban относится к чему-то вроде страны или музыкального исполнителя. Другой вариант - вручную создать список на защищенной странице в пространстве проекта и ссылаться на него. Фактическая блокировка при редактировании, скорее всего, будет применяться только к страницам, находящимся непосредственно в Tban. BD2412 T 22:18, 8 февраля 2021 г. (UTC)

I don't think the DS notice is an issue - if someone places those maliciously, it just gets reverted (obviously if someone topic-banned hit an invalid one they would immediately raise the issue on WP:ANI or WP:AE or wherever is appropriate) and the user who placed it sanctioned if the maliciousness is self-evident. It's generally clear-cut so it wouldn't be an issue. The issue with articles that contain things both inside and outside the topic area is harder to deal with, though. --Aquillion (talk) 21:52, 15 February 2021 (UTC)

• I believe there was an RFc before pblocks were implemented discussing this and "category" style pblocks being too easy to game...CUPIDICAE💕 22:31, 8 February 2021 (UTC)

  См. M: Инициатива общественного здравоохранения / Частичные блоки # Блоки категорий для получения дополнительной информации об этом подходе. Whatamidoing (WMF) ( обсуждение ) 05:47, 10 февраля 2021 (UTC)

  Проблема с блоками категорий действительно двоякая. Кто угодно может их добавить, кто угодно может удалить. Что де-факто дает каждому возможность блокировать определенных пользователей (например, я могу добавить на эту страницу «Американскую политику». Это может быть быстро отменено, но все же). Третья проблема заключается в том, что идея защищенной страницы / списка администраторов может быть неосуществимой. Я не уверен, что администраторы действительно могут вести свой собственный список. Возможно, они смогут получить список категорий в определенный момент, просмотреть его и затем добавить на защищенную страницу, которая, по крайней мере, будет в основном завершена. Но в основном я не уверен, что это проблема. Я имею в виду, что уклонение от запрета темы определить несложно. Люди обычно быстро сообщают друг другу даже о малейших нарушениях. ProcrastinatingReader ( разговор ) 06:39, 10 февраля 2021 (UTC)

• Как упоминалось выше, это хорошая идея на бумаге, но она просто создаст больше проблем. ~ HAL 333 22:18, 10 февраля 2021 г. (UTC)
• Это нужно будет делать в каждом конкретном случае и потребует изменения кода, но это выполнимо. Один из способов сделать это - избавиться от нижнего лимита на блоки страниц, который, я думаю, составляет 10 или что-то в этом роде. Если бы это было очень большое число - скажем, 5000 - тогда в большинстве случаев было бы достаточно просто создать «моментальный снимок» списка страниц из категорий, вручную отфильтровать очевидные «ложные срабатывания», а затем заблокировать страницу человека со всех этих страниц. Это сделало бы журналы блоков очень длинными, но это выполнимо. Однако это не сработает для страниц со «смешанным содержанием», где запрет по теме, даже «в широком смысле», охватывает только часть, но далеко не все содержимое данной страницы. Я не вижу простого способа реализовать это в программном обеспечении без чрезмерного убийства.Он также ничего не сделает со страницами, которые не классифицированы должным образом или которые еще не существуют, но на которые распространяется запрет по темам. Итог: я думаю, что это хорошая идея, если вы принимаете ограничения и не считаете это чудодейственным средством для принудительного запрета тем . davidwr / ( talk ) / ( вклад ) 22:29, 10 февраля 2021 г. (UTC)

  Я не принимал непосредственного участия ни в одной из работ по частичному блокированию, но, судя по тому, что я слышал, возможность частичного блокирования кого-либо из 5000 страниц вряд ли будет приемлемой для Ops по причинам производительности / базы данных. Whatamidoing (WMF) ( разговор ) 21:40, 15 февраля 2021 (UTC)

RFC: Следует ли разрешить настраиваемый DISPLAYTITLE? [ редактировать ]

Should we use custom DISPLAYTITLE? We have dozens of titles where custom DISPLAYTITLE would be useful, such as thatPower and C Sharp (programming language). Using custom DISPLAYTITLE would allow us to bypass these restrictions and allow us to use any DISPLAYTITLE and deprecate the template {{correct title}} Aasim (talk) 20:22, 9 February 2021 (UTC)

• Нет. - Изно ( разговор ) 22:19, 9 февраля 2021 (UTC)
  • @ Изно : нужно уточнить? - Эль Милло ( разговор ), 22:21, 9 февраля 2021 г. (UTC)
    • Считайте возможным злоупотребление произвольными названиями. - Изно ( разговор ) 22:23, 9 февраля 2021 г. (UTC)
    • Не говоря уже о злоупотреблениях, подумайте, насколько сложно будет определить правильный заголовок, чтобы вы могли делать такие вещи, как базовые ссылки на страницу. Да нет. - Изно ( разговорное ) 22:36, 9 февраля 2021 (UTC)

Потребуется какая-то система, разрешающая только «допустимые» альтернативные имена - в настоящее время разрешены только модификации, которые приводят к тому же тексту (игнорируя форматирование / нормализацию). Для C # вам нужно разрешить добавление «#» (возможно, целесообразно закодировать как неподдерживаемый символ), но также удалить «Sharp» (сложнее закодировать, потому что он уже запрещает скрывать произвольные части заголовка страницы). Одна из возможностей - это отдельная программная функция, поэтому заголовок может редактироваться только пользователями с определенным разрешением, но я не думаю, что это получит большую поддержку, и это будет много работы с довольно незначительной выгодой. И все же проблема в том, что отображаемый заголовок не будет работать, если вы скопируете его в поле поиска или попытаетесь создать ссылку на него. -  В  Earwig  ⟨ ток ⟩ 22: 40, 9 февраля 2021 г. (UTC)

@ The Earwig : удаление символов из заголовка уже поддерживается с помощью трюка font-size = 0, хотя я думаю, что это обычно считается плохой практикой. - SD0001 ( разговор ) 14:03, 10 февраля 2021 г. (UTC)

Из Википедии: Название страницы # При изменении отображаемого заголовка раньше можно было скрыть текст, display: none;но теперь это запрещено. Имеет смысл есть и другие обходные пути, но я уверен, что это плохая идея. Во-первых, я не уверен, как программы чтения с экрана справятся с этим. -  В  Earwig  ⟨ ток ⟩ 14:39, 10 февраля 2021 (UTC)

Теоретически может существовать список допустимых замен, определенных регулярным выражением где-то или что-то в этом роде, поэтому полное слово «острый» можно заменить на «#» и т.п. - Аквиллион ( разговор ) 21:56, 15 февраля 2021 (UTC)

• Нет, по сути, по всем вопросам, уже поднятым Изно . - xaosflux ^Talk 00:10, 10 февраля 2021 г. (UTC)
• Я никогда не знал, что C # не в правильном названии. Это странно. Если это предложение будет одобрено, будет ли это технически возможно в настоящее время с изменением конфигурации или чем-то еще, или нужно будет написать код? Во всяком случае, мне кажется, что в идеале # следует поддерживать как символ в обычных заголовках, а не использовать взлом отображения заголовка. ProcrastinatingReader ( разговор ) 00:16, 10 февраля 2021 (UTC)

  @ ProcrastinatingReader : Что ж, чтобы включить # как законный заголовок страницы без взлома DISPLAYTITLE, вам все равно придется рассматривать его как особый случай, потому что # имеет особое значение в URL-адресах. davidwr / ( talk ) / ( contribs ) 00:27, 10 февраля 2021 (UTC)

  Ага. Если в заголовках поддерживался символ # , следует ли Foo # Bar перенаправить вас к статье «Foo # Bar» или к разделу «Bar» в статье «Foo»? - SD0001 ( разговор ) 14:04, 10 февраля 2021 г. (UTC)

  Как статьи справляются с этим? например HC Zemgale / LUA ? Или / (т.е. подстраницы) недопустимы в пространстве статьи? ProcrastinatingReader ( разговор ) 18:48, 12 февраля 2021 (UTC)

  В основном пространстве подстраница отключена (см. Пример Fate / stay night ). - Изно ( разговор ) 19:02, 12 февраля 2021 г. (UTC)

  Это технически возможно в виде изменения конфигурации (установка $ wgRestrictDisplayTitle на false) * Pppery * это началось ... 00:37, 10 февраля 2021 г. (UTC)

• Not arbitrary changes carte blanc, but I am open to allowing it on a case-by-case basis after a discussion similar to that of a controversial page-move discussion. I'm also open to allowing whole new classes of "DISPLAYTITLE" to be allowed e.g. "allow #", again, after an RfC for similar discussion for each proposed exception. This could be implemented by allowing DISPLAYTITLE when there is a 1-1 mapping from page titles to DISPLAYTITLE arguments in a "whitelist file" maintained by administrators. Of course, we are talking about a code change, and developer time isn't unlimited. I don't see this as a priority, but if developer- and tester-time is available, I'd favor it. davidwr/(talk)/(contribs) 00:24, 10 февраля 2021 (UTC)

ИМХО, я думаю, что злоупотребление немного маловероятно, учитывая, что большинство людей, заходящих в Википедию для редактирования, находятся здесь добросовестно и, вероятно, ничего не знают о том, как работает "DISPLAYTITLE". Кроме того, похоже, что DISPLAYTITLE все равно скрыт глубоко в VisualEditor, поэтому я не думаю, что произойдут злоупотребления.

А вмешательство в "DISPLAYTITLE" страницы можно рассматривать как разрушительное редактирование, точно так же, как мы относимся к войне за перемещение страниц, тенденциозным комментариям и т. Д. Аасим ( выступление ) 00:55, 10 февраля 2021 г. (UTC)

• Против. Это слишком раздражает и подвержено ошибкам, если отображаемое имя не может быть скопировано в вики-ссылку или в поле поиска. Также может сбивать с толку, если вы щелкнете ссылку в результатах поиска или где-то еще и перейдете на страницу с другим заголовком. PrimeHunter ( разговорное ) 15:38, 10 февраля 2021 (UTC)
• Против . Когда я работал в музыкальном технологическом стартапе, одной из наших головных болей были такие артисты, как Ke $ ha и NIИ. Мы постоянно наделяли такие вещи специальными корпусами, чтобы люди могли найти их в поиске. Да, досадно, что ввод «C #» в поле поиска вики приводит вас к C , поэтому вам нужно отметить путь до C-sharp, где вы, наконец, можете щелкнуть C # (язык программирования), который приведет вас к C Sharp (язык программирования) (на самом деле, я думаю, что последний шаг может быть нарушением MOS: DABPIPE ). Но, думаю, альтернатива была бы хуже. - РойСмит (разговор) 15:50, 10 февраля 2021 г. (UTC)
• oppose Насколько я могу судить, символы, разрешенные в названии, ограничены по уважительным причинам. В частности, # уже имеет значение в URL-адресах и поэтому будет настоящей проблемой для вики-ссылок. - GhostInTheMachine ^{поговорите со мной} 18:08, 10 февраля 2021 г. (UTC)

  Речь идет не о разрешении # в викилинках, а о разрешении настраиваемого DISPLAYTITLE. Аасим ( разговорное ) 21:51, 10 февраля 2021 (UTC)

  Я понимаю это, но представьте, как весело люди будут пытаться ввести вики-ссылку на страницу, которая имеет символ # в отображаемом заголовке. Является ли вики-ссылка A # B на страницу A # B или ссылку B на странице A? Ссылка на страницу называется A-something-else, но отображается как A # B? Если заголовок страницы отображается как A # B, какой должна быть ссылка? - GhostInTheMachine ^{поговорит со мной} 22:53, 10 февраля 2021 года (UTC)

• Проблема в том, что мы не хотим злоупотребления подменой заголовка. Возможно, в некоторых случаях мы могли бы иметь систему для отображения «технического заголовка» в менее заметном месте рядом с «отображаемым заголовком»? - Яир Рэнд ( разговор ) 06:19, 18 февраля 2021 (UTC)

  Мы могли бы использовать подход, подобный Wiktionary, и иметь страницу «Неподдерживаемые заголовки», где мы можем перечислить все неподдерживаемые заголовки. Тогда техническая сноска станет ненужной, и ссылки станут более четкими. Аасим ( разговорное ) 02:49, 21 февраля 2021 (UTC)

  Пожалуйста, дайте ссылку на эту страницу Викисловаря. - Red rose64 🌹 ( обсуждение ) 08:28, 21 февраля 2021 (UTC)

  Я имею в виду префиксную страницу «неподдерживаемые заголовки», и на ее подстраницах есть неподдерживаемые заголовки. См. Викисловарь: Unsupported_titles / Number_sign для примера. Для страницы C # мы могли бы расположить ее в Unsupported title / C-sharp, а затем заставить JavaScript изменить отображаемый заголовок на C #. Аасим ( разговор ) 08:40, 21 февраля 2021 (UTC)

  Похоже, что происходит какой-то JavaScript: при посещении страницы заголовок ненадолго отображается как «Неподдерживаемые заголовки / числовой знак», который затем заменяется одним символом «#». - Red rose64 🌹 ( разговор ) 09:00, 21 февраля 2021 (UTC)

RFC: соглашение об именах параметров стиля цитирования 1 [ править ]

Следует ли полностью удалить параметры без переноса из семейства шаблонов CS1 / 2? Primefac ( разговор ) 02:14, 10 февраля 2021 (UTC)

Фон (CS1) [ править ]

В 2014 году RFC определил, что все имена параметров в шаблонах Citation Style 1 должны иметь псевдонимы в нижнем регистре, разделенные дефисами между английскими словами, между (не внутри) акронимами или между английскими словами и акронимами. В документации эта версия с переносом в нижнем регистре должна отображаться как для "обычного использования". Это означало, например, что это будет отображаться как предпочтительный параметр, в то время как показывается как приемлемый, но не рекомендуется использовать. В последующие годы наблюдались различные тенденции и дискуссии, формально осуждающие многие параметры без дефиса, от небольшой горстки ( пример 2019 года ) до текущего списка.|access-date=|accessdate=который содержит более 70 статей. Многие из них представляют собой варианты предпочтительных / расставленных через дефис версий без дефиса, которые удаляются, чтобы снизить нагрузку на обслуживание и повысить единообразие между шаблонами (то есть «простоту использования»). Другие изменения включали то, что RefToolbar выдавал параметры с дефисом и настраивал генфиксы AWB для замены некоторых параметров .

В октябре 2020 года все параметры без дефиса были добавлены в «текущий список», ссылка на который приведена выше. В ноябре 2020 года был отправлен запрос бота (« Monkbot 18 ») на удаление или замену этих устаревших параметров, чтобы их можно было удалить из базового модуля и упростить код шаблона. Признавая, что эта задача носила в основном косметический характер, BAG и другие площадки (в первую очередь шаблоны для обсуждения ) исторически придерживались идеи «бремени обслуживания» как уважительной причины для подобных правок; см., например, Monkbot 17 , который заменил (косметически) один параметр на значение с лучшим именем для простоты использования.

Проблема для Monkbot 18 возникает из-за количества правок, которые он / должен был внести; по самым скромным подсчетам, количество правок, внесенных для этой задачи за двухмесячный период (ноябрь 2020 г. - январь 2021 г.), составляет около 1 миллиона правок; как обсуждалось на странице обсуждения задачи, по существу были удалены все параметры без дефиса, кроме пяти, но для полной «очистки» этих параметров все равно потребуется еще 2–3 миллиона изменений, которые займут до четырех дополнительных месяцев. Кроме того, противники бота также выразили обеспокоенность тем, что относительно небольшие дискуссии об отказе от этих параметров не достигли достаточно широкой аудитории, чтобы заслужить то, что, по их мнению, было радикальными изменениями.

Предложение (CS1) [ править ]

Существует три основных варианта в отношении семейства шаблонов CS1 / 2 и, в более широком смысле, задачи Monkbot 18.

• Вариант A : параметры без дефисов следует исключить и удалить; бот может продолжить свою работу.
• Вариант B ("статус-кво"): параметры без дефиса формально устарели, но не должны быть немедленно удалены. Устаревание может быть включено в генфиксы или выполняться вместе с другими некосметическими изменениями, но (без учета возможного дня косметического бота) не должно выполняться ботом самостоятельно.
• Вариант C : параметры без дефиса не должны быть устаревшими; прекращение поддержки не должно продолжаться, а утверждение бота должно быть отменено. Это также будет означать, что список устаревших параметров необходимо обновить, чтобы удалить параметры без дефиса.

Обратите внимание, что это обсуждение в первую очередь касается параметров шаблона CS1 / 2 и того, следует ли сохранять / поддерживать два полных набора параметров. Это не место для повторного рассмотрения различных дискуссий о задаче Monkbot 18; Вариант B предназначен для тех, кто считает, что задача не должна продолжаться.

Обзор (CS1) [ править ]

• Первый выбор , второй выбор B . Я был бы счастлив, если бы генфиксы AWB взяли на себя часть этого бремени, и я был бы счастлив, если бы это происходило немного медленнее, но это должно происходить, даже если иногда это неудобно для меня. Кроме того, когда какой-либо отдельный параметр достигает достаточно малого состояния (например, потенциально все еще используются тысячи использований, но не сотни тысяч статей), шаблон следует обновить, чтобы запретить использование этого конкретного параметра (а не просто рекомендовать его в документации), чтобы они не продолжали ползать обратно, потому что, эй, это все еще работает, так зачем мне беспокоиться? WhatamIdoing ( обсуждение ) 19:12, 10 февраля 2021 (UTC)

  @ WhatamIdoing : Genfixes AWB уже обрабатывает это через WP: AWB / RTP , поэтому ручное редактирование и другие боты могут помочь сократить список при внесении других (не косметических) изменений. GoingBatty ( разговор ) 04:12, 11 февраля 2021 (UTC)

  GoingBatty , вы уверены, что |accessdate=его заменят |access-date=редакторы, использующие текущую версию WP: AWB / RTP ? Думаю, убрали. - Jonesey95 ( разговорное ) 04:33, 11 февраля 2021 г. (UTC)

  @ Jonesey95 : Ты прав! Пока эта функция существует (а другие параметры все еще заменяются), редакторы удалили некоторые правила замены переносов. GoingBatty ( разговор ) 04:59, 11 февраля 2021 (UTC)

• Вариант А . Я поддерживаю завершение почти готового отхода от недифференцированных многословных параметров. См. Ниже более подробную информацию об этом процессе, который сейчас ставится под сомнение очень немногими редакторами после семи лет работы, и когда он завершен более чем на 90%. С любым другим шаблоном потребовалось бы несколько дней для стандартизации одного стиля имени параметра и преобразования всех включений. Единственная причина, по которой процесс для шаблонов CS1 / CS2 отличается, заключается в том, что используются миллионы включений вместо сотен. - Jonesey95 ( разговорное ) 04:33, 11 февраля 2021 г. (UTC)
• Вариант C . Это бессмысленно заставлять работать; см. расширенный комментарий в разделе обсуждения. Espresso Addict ( разговор ) 07:08, 11 февраля 2021 (UTC)
• B переходит к C. Если бы это было ограничено несколькими тысячами страниц, это не было бы большой проблемой. Но когда это более 3 миллионов страниц, возможно, должно быть наоборот - IE без дефиса. Множество бессмысленных ботинок, просматривающих миллионы страниц для незначительного изменения. Lugnuts ^{Fire, иди со мной} 08:20, 11 февраля 2021 (UTC)
• B, если не C Согласно комментариям выше; Многие редакторы явно довольны формами без дефиса, так почему бы не разрешить и то, и другое? Менять бессмысленно. Многие другие шаблоны позволяют использовать псевдонимы в качестве имен параметров. Я не вижу проблемы. Но мы там, где находимся, поэтому я предпочитаю B, а не C. Питер Коксхед ( разговор ) 09:04, 11 февраля 2021 (UTC)
• Вариант A (второй вариант B ), согласно Jonesey95. Давайте просто все упростим, как и должно быть. Продолжайте и заканчивайте работу. - NSH001 ( разговорное ) 10:18, 11 февраля 2021 г. (UTC)
• Вариант C . Это совершенно бессмысленное занятие. На мой взгляд, текст без дефисов лучше, так как они не переносятся в окно редактирования и могут быть подчеркнуты как опечатка, поэтому они хорошо видны в окне редактирования. Кейт Д. ( разговор ) 13:01, 11 февраля 2021 (UTC)
• C (первый выбор) или B (второй выбор). Я читал множество дискуссий по этой проблеме и никогда не видел ничего, что убедило бы меня в том, что отказ от поддержки действительно приносит пользу энциклопедии. Даже если мы предположим, что это так или иначе, реальное и очевидное нарушение, вызванное ботом до сих пор, и степень изменений, которые отмечает оператор бота, потребуются для выполнения задачи, очень ясно и очень значительно перевешивают то, что выгода. Тридуульф ( разговор ) 15:20, 11 февраля 2021 (UTC)
• Вариант А: это изменение немного болезненно, но его лучше редактировать в долгосрочной перспективе. Лучше внести это изменение, чем не делать этого. Лучшее время было пятнадцать лет назад, но сейчас второе лучшее время. Разрешите боту продолжить свою работу, избавьтесь от всех параметров и, когда все они будут удалены, начните генерировать ошибки цитирования. Elliot321 ( Обсуждение | вклад ) 17:09, 11 февраля 2021 (UTC)
• Option A. Unfortunately, the visual editor exists... but isn't useful for large editing projects and thus many people still use wikitext editing - condensing to one form (specifically the hyphenated one as it is easier to read for editors) will help ensure consistency between articles at least in the CS1 templates. Obviously this won't make every article easier to edit as there are articles with non CS1 style citations, but it'll help the millions that do use CS1 look the same to editors instead of having a hodge-podge of hyphenated names. I further agree with the bot continuing to run now, and then running maybe once per week or so after this initial run to fix any CS1 non-hyphenated parameter names. -bɜ:ʳkənhɪmez (User/say hi!) 17:13, 11 February 2021 (UTC)
• Вариант C. The point of templates and bots is that they should work to make editors' lives easier, not that editors should change the way they do things to make template and bot creators' lives easier. This bot has it completely topsy-turvy, and if the bot-approvals group has approved this then that is a problem with that group, not with a few unhyphenated parameters. I can't help feeling that that group is looking at the interests of a few bot operators rather than of the many more editors and still many more readers. There's no great complexity in having a few synonyms for template parameters, and there's no problem at all with exporting data - if the synonymic parameters point to the same place in code then they can be exported in the same format with no extra effort. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. Фил Бриджер ( разговор ) 18:21, 11 февраля 2021 (UTC)

  Суть шаблонов и ботов в том, что они должны работать, чтобы облегчить жизнь редакторам.. Точно так. Вот для чего нужен этот бот. Это упрощает чтение имен параметров (принимая их в целом, а не только дату доступа как таковую), уменьшает размер документации по шаблону, делает имена параметров согласованными. Все это в совокупности упрощает обучение использованию шаблонов цитирования. Это также упрощает обслуживание шаблонов. беспроигрышная ситуация. Единственная причина, по которой мы ведем это обсуждение, заключается в том, что программа списков наблюдения Mediawiki так плохо справляется с редактированием ботами. В противном случае это было бы проще простого. Некоторые люди здесь, кажется, ошибочно полагают, что это сделано только для продвижения интересов «нескольких операторов ботов». Что ж, я совершенно уверен, что Trappist (оператор этого бота) может обойтись без стресса, связанного с планированием, написанием и запуском этого бота. Он делает чертовски фантастическую работу,и заслуживает огромной похвалы и признательности за свою работу.Я не могу поверить, что через сорок лет после того, как я пришел в ИТ, мы все еще ожидаем, что пользователи будут рабами систем, которые должны им помогать. Вся цель этого бота - облегчить жизнь пользователям. FWIW, у меня также есть опыт работы в ИТ более 40 лет назад (был командирован на 2 года для работы над (очень успешным) проектом - математическое программирование больших данных для компании по страхованию жизни), и с тех пор мне часто приходилось поддерживать связь с ИТ-специалистами. . Я хорошо осведомлен о проблемах, которые могут возникнуть, когда вы просто позволяете системам становиться все более и более сложными, поэтому я ценю усилия траппистов (и многих других) по упрощению вопросов. - NSH001 ( разговор ) 23:37, 11 февраля 2021 г. (UTC)

  Уточнение: перечитывая это сегодня утром, читателям, которые не читают внимательно, может показаться, что я согласен с Филом Бриджером. Ничто не может быть дальше от истины, я до сих пор поддерживаю вариант А . Вариант C не имеет смысла по всем причинам, изложенным SMcCandlish. - NSH001 ( разговор ) 08:35, 12 февраля 2021 г. (UTC)

  И гиперболическая позиция Фила Бриджера ошибочна. Вариант Б никому ничего не навязывает. «Мне не нравится вариант А» не означает, что «может работать только вариант С». Вариант B - это статус-кво , и он ничего не сломал. Я довольно шокирован тем, насколько это очевидно, но по крайней мере 10 редакторов, кажется, не заметили. Я знаю, что в мире очень много популизма - много «Я бы очень сильно переживал по этому поводу, если бы это было правдой, и мне приятно притворяться, что это правда, поэтому я собираюсь притвориться, что это правда. " поведение. Но все это нужно оставить за дверью.  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC)

  No, my stance is not hyperbole or due to populism. The reason I reject option B is the word "immediately". It still leaves current consensus that unhyphenated versions of parameters will be removed, just not immediately, and it is that consensus that should change, however many years it has been stable for. I am happy with simplifying the documentation, but not with removal of the option. Phil Bridger (talk) 09:19, 12 February 2021 (UTC)

  As noted above: Deprecation is not synonymous with disabling. You're confusing replacement of the parameters as written in a template transcluded in a page, with removal of the runtogether parameter variant's ability to function in the template. Only option A would do the latter. We have many, many templates that support variant-spelling parameters but do not "advertise" them in the documentation, and it breaks nothing whatsoever to bot-replace them with the canonical version, just as the same bot will replaces calls to a redirect name for the template with the actual page name of the template. I.e., you're having a strong negative reaction to an argument that option B is not actually making.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)

  Option B very clearly says "but should not be immediately removed". Either the word "immediately" has some meaning, and this option would lead to removal, but just not immediately, or it has no meaning and has no business being there. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)

  SMcCandlish, this was explained in the previous discussion at CS1: ""Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go". So the intention is to error and then remove the functionality of these parameters, not simply not advertise them in the documentation. If you want to propose a variant of option C that removes the parameters from the documentation but still allows them to function, go ahead, but option B is not that. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)

  What I want to propose is a variant of Option B that removes the parameters from the documentation before letting some bot go around changing the articles on my watchlist as if the parameters are somehow bad. If the params are really bad, and if there's a consensus to that effect, then Step One is to take them out of the documentation (either by dragging them away in the dark of night, silently, like ninjas, or by transparently mentioning them as being deprecated, so everybody knows what's going on). The first phase of real deprecation is telling people to stop using something. Then you can start throwing up red messages and it's not so damned rude or surprising. — JohnFromPinckney (talk) 21:40, 13 February 2021 (UTC)

  Sure, I would support that variant, too. Or a variant that kept mention of those versions of the parameters but deprecated them. Whatever gets us closer to having consistency in the actual deployed templates being used in citations.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)

  This stuff should be in a tracking category, if that's what bots and other tools are going to work with. If we don't like the error messages, then we can disable them. This is just template and module code, it's not etched forver into a mountain face like Mt. Rushmore.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)

• Option C I agree strongly with Phil Bridger here. In other words, I fail to see what exactly is accomplished by making millions of cosmetic edits and then deliberately breaking things that would otherwise have worked. * Pppery * it has begun... 20:21, 11 February 2021 (UTC)

  Option B breaks nothing. You, et al., are providing an argument against option A, not an actual argument for C, and just ignoring B. Also, a !vote for C is an !vote for overturning a status quo that has been stable for years, in favor of chaos, yet without an actual rationale to do so. The closer should take that into account, per WP:NOTAVOTE. In the event of a "no consensus" result we still end up with the status quo. Things like this are why I keep telling people they need to write RfCs better. "Anything that can be misinterpreted will be."  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)

  SMcCandlish, option B supports disabling of the non-hyphenated parameters - that is a breaking change. The difference between A and B is speed, not outcome. Your !vote below suggests you want the non-hyphenated variants to remain supported, but of the options provided only option C accomplishes that. Nikkimaria (talk) 16:18, 13 February 2021 (UTC)

  Nope. See my response to same claim by Phil Bridger, above.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)

  Yep - see above. You can also look at what has happened with previously deprecated CS1 parameters such as |authorfirst= - they don't work. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)

  Which is perfectly fine, given enough time that people stop actually using them. Thus remove them from the template documentation and replace them in deployed template translcusions. Eventually the "monkey see, monkey do" effect of being exposed to deprecated parameter variants goes away, through decreased and eventually zero exposure. I'm mean, come on, that's what the point of deprecation is. It seems to me that you [plural] are coming from a "give me C or give me death" perspective, artificially conflating A and B because you just will not tolerate the idea of any parameter name variants ever going away for any reason. If I'm wrong about that perception, then please explain.  — SMcCandlish ☏ ¢ 😼  04:18, 14 February 2021 (UTC)

• Option C per Phil Bridger. Ealdgyth (talk) 21:28, 11 February 2021 (UTC)
• Option C - Commenting here probably falls under my doctors' lists of "things HF shouldn't do while he has a concussion", but I don't want to miss this discussion. While I understand that maintaining the citation templates is not a particularly easy job, in the end, rigidness in the citation template is not desirable. The citation templates should be easy to use, and having a couple aliases for the most common parameters makes it easier to use. And a trout to the bot guild for approving a bot task that was designed to deprecate template parameters with no consensus for that deprecation. Hog Farm _Talk 22:15, 11 February 2021 (UTC)
• First choice A, second choice B. Wikipedia source text is becoming increasingly complex and difficult to manage making it less accessible, except for the type of experienced editors participating here. Anything we can do to reduce complexity is a win, fewer options the better when plainly redundant. -- GreenC 22:41, 11 February 2021 (UTC)
• Option C per Phil Bridger, personally I prefer non-hyphenated parameters, and I find deprecating them to be an absolutely pointless exercise that breaks things for absolutely no reason other than to satisfy the cosmetic preferences of a few editors. Devonian Wombat (talk) 00:14, 12 February 2021 (UTC)
• Option C. Largely per Hog Farm. Keeping extremely commonly used aliases is helpful for editors using these templates. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)
• Support option C, neutral on option B, strongly oppose option A. My fingers are used to typing many of these parameter names without hyphens. Deprecating them and the accompanying gnomework of replacing them with the un-deprecated versions is already causing me significant hassle, both in trying to remember that really now they should be hyphenated, and in trying to pick out the important changes on my watchlist among all the pointless gnomery. Removing the unhyphenated forms altogether would be worse. —David Eppstein (talk) 01:41, 12 February 2021 (UTC)
• Option C. I'm with Phil Bridger and Hog Farm. I don't know if this is bike shedding or yak shaving, but it's just not productive and a bad look. Alternatives exist because it's simpler than remembering which of two common possibilities are acceptable, rather than forcing one or the other (as the other options do). Discussing efficiency because of a off-row character on the other hand (oh, so we're making this choice based on everyone using QWERTY?) is the kind of ignore-practical-facts reasoning that yield platypus-shaped end results. -- Mikeblas (talk) 01:52, 12 February 2021 (UTC)
• A is better in the long run, but B for now, and have the conversion covered by AWB genfixes and similar. Headbomb {t · c · p · b} 02:29, 12 February 2021 (UTC)
• Option C per Phil Bridger. SarahSV ^(talk) 02:51, 12 February 2021 (UTC)
• Option C. This "everything must be hyphenated" approach doesn't work well with the text editor. For some common parameters like |accessdate=, it is simply better being unhyphenated because the source text is quicker and easier for a human to parse because the parameter doesn't word wrap in the editor's textbox. Jason Quinn (talk) 03:09, 12 February 2021 (UTC)
• Option B. We should stop listing the nonhyphenated ones in the documentation at very least, so that between editorial shift and AWB/bot genfixes cleanup, we get more consistent over time. It's too soon for option A, if ever, because the templates serve us, we don't serve the templates. It's perfectly fine for templates to quietly support non-hyphenated variants so they don't just break if people try them. But we should not continue listing those variants in the docs. It's antithetical to the purpose of templating, for us to perpetuate inconsistency (without good reason, like an ENGVAR color vs. colour distinction). And it pointlessly makes the documentation longer and more complex for no gain at all; no one looking for how to specify the Archive.org URL needs to know anything but |archive-date=, and telling them |archivedate= also works is just stuffing pointless trivia into their head. Yes, do continue converting to hyphenated versions in genfixes and other automated edits (when doing something more substantive at the same time). Finally, option C is rather pointless. We've regularly been (gradually) deprecating various old parameter names, and it has worked just fine. Option B will not break anything, and will have (already is having) positive results.  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)
• Option B Option C. These are all valid aliases, as there is zero confusion between say |access-date= and |accessdate=. The status quo works fine: hyphenated is preferred because it's easier to read, but unhyphenated is acceptable because there is no ambiguity and evidently plenty of people type it that way. Cosmetic changes should adhere to policy. – Finnusertop (talk ⋅ contribs) 05:53, 12 February 2021 (UTC) Changed from B to C as I am opposed to the implications of the "formally deprecated" part of these valid aliases. – Finnusertop (talk ⋅ contribs) 09:26, 12 February 2021 (UTC)
• Option C first choice (B second). Editors should be allowed to use either hyphenated or non-hyphenated versions. Consistency is not better than flexibility here: the only people reading the parameter are editors, so let the editors decide whether or not they want to use a hyphen in their template parameters. I share the general concern about the disconnect between code writers and content writers, and the frustration with some template and bot maintainers imposing decisions on everyone without consensus. Fait accompli editing across millions of edits or transclusions is kind of a big deal. Levivich ^harass/_hound 07:20, 12 February 2021 (UTC)
• I Like C: I especially echo Levivich, Thryduulf|, and Phil Bridger's comments regarding these perennial, periodic, new surprises where editing articles is concerned. That is disruptive and we should just stop it. C, therefore, will bring the sanity back. GenQuest ^"scribble" 07:42, 12 February 2021 (UTC)
• Option C. These are templates for use by editors, they have no impact on readers, and it's a complete waste of time making rules and regulations about them and then writing bots to enforce those pointless rules. Not to mention that when AWB goes through "fixing" all these in an article, it can drown out the genuine edits and make it harder for people to track what's going on. Get rid of this ridiculous rule, delete it from AWB, and then maybe we can get on with actually building an encyclopedia.  — Amakuru (talk) 09:13, 12 February 2021 (UTC)
• Option C (which is the status quo ante). I just don't see what problem people are trying to fix, so follow WP:NBDF. The hyphenated parameters are useful and improve wikitext legibility, I personally prefer them, but allowing both forms makes things easier for editors. Deprecating them appears pointless, and removing them entirely seems actively harmful. It's created millions of pointless busywork edits clogging up watchlists for no good reason. We don't have a problem with template aliases, so why the concern about parameter aliases? None has been convincingly articulated. Modest Genius talk 12:10, 12 February 2021 (UTC)
• Since I have been pinged, neutral all round. I'm have nostalgia for the status quo for some reasons already presented (muscle memory, line breaks), but I recognize that once we pass through the valley of the shadow and emerge into the bright uplands yonder of a cleaner implementation, we'll have forgotten the pain. Mind you, I'll probably be 90 years old and beyond caring. But I have some implementation concerns in the Discussion. David Brooks (talk) 16:54, 12 February 2021 (UTC)
• Option C - Standardization of this sort may be useful to researchers or developers, but not to regular users. Adding citations should be as easy as possible. To that end, I want to minimize the chances that the interface will not know what I'm trying to do, or that I'll get an error because I entered an underscore instead of a hyphen. The rest of the internet is trying to increase flexibility to make user experience easy and intuitive. We do that too in many ways. But here we seem to be doing the opposite: removing flexibility and requiring users to know how we've worded/arranged things.
  I don't care if there's a bot that goes in an standardizes them afterwards or if someone runs AWB behind me. Again, I get the appeal of standardization. We should just be doing everything we can to make the experience intuitive for regular users. — Rhododendrites ^talk \\ 23:04, 12 February 2021 (UTC)
  • Alternative: Option D - let the bot and/or AWB standardize, but never disable the parameters. Standardization is good; degrading usability is bad. — Rhododendrites ^talk \\ 23:12, 12 February 2021 (UTC)

    I would certainly support your option D if it was on the table, but cannot support anything that says that this functionality should be removed, as option B (despite the illiterate claims above that it doesn't) clearly mandates. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)

• Option A with B as my second choice. Maintaining our complex citation templates is not an easy task, and if the people who are putting in the work want to do this to make their jobs easier, I'm in favor of it. Legoktm (talk) 23:48, 12 February 2021 (UTC)
• Option C with Option B as second choice: Modest Genius makes an excellent comment, as do several others. The community needs to stop wasting its time on this citation formatting nonsense and do the hard labor of introducing citations in articles instead, the place we actually have a front-facing desperate crisis which damages our reputation. I use |accessdate= and I have no intention to stop. I remember very clearly the process I went through of learning citation templates in 2014—they were confusing at first but I never had a single confusion in parsing "accessdate" as the two word phrase "access date", very clearly meaning the date you last accessed a reference. I can see that in theory this would be marginally better for new users, and I can see that in practice some people who don't like the look of "accessdate" are escalating it ("my opinion" becomes "the correct view" becomes "a moral imperative to enforce"), but this just doesn't outweigh the actual genuine pain it will cause editors like me to retrain a years-long developed muscle memory; almost every mainspace edit I make for months will have a disrupted flow (interrupts my thought process, wastes my time re-typing) if this is to change.
  As for the bot that has been wasting several minutes of my time per day, I strongly opposed it in the first place and have had more than enough of it. (No, I can't ignore it, because if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit.) BRFAs need wider advertisement when their scope is so enormous and their violation of WP:COSMETICBOT so overt. I don't accept that option B reflects past consensus in practice in that I can't remember anyone ever approaching me about my use of |accessdate= or changing it to |access-date= manually. Past local consensus among technical groups who don't work in article space, sure. But enwiki community consensus? No. — Bilorv (talk) 01:07, 13 February 2021 (UTC)
  • @Bilorv: if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit -- this always takes me aback. Just curious, but why not enable the "Expand watchlist to show all changes, not just the most recent" + "Group changes by page in recent changes and watchlist" settings? I see no bot edits, and they don't cover anything up. — Rhododendrites ^talk \\ 02:50, 13 February 2021 (UTC)
    • @Rhododendrites: appreciate the suggestion! It's never occurred to me that combining those would produce that functionality (there are so many complex combinations of Watchlist filters and Preferences options), but I've enabled those two and kept "Latest revision" on and enabled "Human (not bot)" as the Preference option "Hide bot edits from the watchlist" didn't seem to do that and now I think (small sample size in my watchlist atm) I see the latest change only, including if it's a bot, but only if at least one non-bot edit has been made (which is exactly desirable). — Bilorv (talk) 11:34, 13 February 2021 (UTC)
• Option A with B as my second choice. Maintaining the complex citation templates is not an easy task. AManWithNoPlan (talk) 02:52, 13 February 2021 (UTC)
• Option A on the basis that standardization is good. I don't actually care whether the hyphens are there or not, but it's better one way or the other rather than having a mix. In general I'd rather see us migrate away from using wikitext for reference information, though, it's like doing your finances in a text document. Thanks. Mike Peel (talk) 18:26, 13 February 2021 (UTC)
• Option A I have always preferred the hyphenated form personally because it allowed the spell checker to verify that there was no typo, whereas the unhyphenated form is always flagged as a typo, although the preview now informs me of errors. I disagree with the contention that humans can parse |accessdate= more quickly than |access-date=; spaces were invented for this reason. I also know the overhead that permitting multiple parameters that mean the same thing in templates entails. I'm aware that this has been cluttering my watchlist with Monkbot edits, but my !vote is to continue. Hawkeye7 (discuss) 22:12, 13 February 2021 (UTC)

  Note that this is mostly an WP:ILIKEIT rationale and dismisses the views of those who indicate that they can parse "accessdate" without issue as wrong without any evidence. It also dismisses the very real disruption caused to others as necessary to reduce overheads, whereas this overhead, even if it is a significant as some claim (for which no convincing evidence has ever been presented) it's still trivial compared to the disruption caused by Monkbot's edits and by the unnecessary disruption to editors using the templates. Thryduulf (talk) 15:29, 14 February 2021 (UTC)

• B or C. I've no strong preference between accessdate or access-date, both seem useable, if one is formally preferred then fine. However, the massive ongoing bot spam for something that has literally no effect on readers, and barely any on editors, is unwarranted. In addition to being everywhere on the watchlist, Monkbot makes it much harder to disentangle various series of diffs in the edit history for little benefit. A user making an edit inserting "accessdate" isn't an egregious issue that should cause a bot to come running, and such a bot action then obscures the edit in question from watchlists. CMD (talk) 18:18, 14 February 2021 (UTC)
• Option C. Removing a common way to type parameters in templates reduces ease of use for the end users. Having a bot going around and "fixing" these has a negative impact on the readability of page history and watchlists . No one in this conversation has demonstrated that the maintenance burden on the template is so significant that it would justify all of these downsides. It also seems that the maintenance burden is not something that would be difficult to track like accidental blue links to primary topic articles when non-primary topic articles were intended, since the template code are on the template pages.---- Patar knight - ^chat/_{contributions} 18:53, 14 February 2021 (UTC)
• Option C. The previous discussions linked above (a six-year-old RFC with seven people participating in it, which specifically promised that nothing would be depreciated, followed by a handwavy argument about maintenance burden), are not remotely sufficient to justify such a sweeping change. Yes, maintenance burden is a pain, but it affects a relatively small handful of bot authors; removing the most widely-used version of a template parameter affects a huge swath of editors, who need to be given deference here on account of being a larger group. And obviously there is not a standing consensus that maintenance burden justifies such changes (at least not one on a scale necessary to justify this), or this discussion wouldn't be so clearly split. Therefore, the unhyphenated version should never have been depreciated, which makes the bot's edits pointless clutter at best and an attempt to push through a controversial change without sufficient consensus via fiat accompli at worst. Furthermore, if maintenance burden is the only concern, obviously the solution is to reverse the 2016 RFC (which, again, had only seven people participating it and agreed merely to create the hyphenated versions as alternatives) and remove the hyphenated version, which currently sees little use and would therefore be far easier and less disruptive to discard. --Aquillion (talk) 22:12, 15 February 2021 (UTC)
• Option B-ish. I think it's reasonable to have the hyphenated forms be the canonical version of the parameter, but I see no reason to make mass-edits to change from one form to another or to change the usual rules about cosmetic bots here. I see no harm in Option C, but implementing Option A will trade current problems for new ones. --AntiCompositeNumber (talk) 02:15, 16 February 2021 (UTC)
• Strong Support A: standardization for template parameters is important & useful.

Mild Support B: the # of |accessdate= per page is too damn high (much of the time), so much so as to interfere with checking regular WP:GenFixes (i.e. many single-screen diffs become many-screen diffs) — I would Strong Support B IIF Monkbot was allowed to continue & hyphenate at least this parameter.

Strong Oppose C: antithesis of A.

~ Tom.Reding (talk ⋅dgaf)  19:23, 16 February 2021 (UTC)

• To whom is standardization for template parameters important & useful? Phil Bridger (talk) 20:39, 16 February 2021 (UTC)
• How and why is standardisation more important and useful than editors being able to improve the encyclopaedia without needing to know the exact format of parameter names and deal with watchlists and page histories full of cosmetic edits? Thryduulf (talk) 20:45, 16 February 2021 (UTC)

• Are y'all suggesting we bring back all deprecated parameters, and adding more so that every user may choose to use the parameter names that are most comfortable/understandable/intuitive to them? I'm ok with soft-deprecation - allowing both but discouraging/converting one, in bulk once via bot, then gradually/passively via WP:GenFixes & other tools, but that is not one of the options.
  Re: "watchlists": may be configured to ignore bots until it's done.
  Re: "histories full of cosmetic edits": the bot only requires 1 edit; hardly "full of"; regardless, there is community consensus for WP:CBD.   ~ Tom.Reding (talk ⋅dgaf)  12:16, 17 February 2021 (UTC)

  Yes, I am suggesting that all the two-word parameters should accept hyphenated and non-hyphenated varieties. It's fine for one to be preferred over the other in documentation but both should work and continue to work as this is by far the least disruptive to editors and allows them to spend their time producing/maintaining content rather than worrying about finicky syntax. I don't have massively strong objections to general fixes substituting one for the other when making non-cosmetic changes to the page, but I wouldn't actively encourage it as it will clutter diffs for no benefit. I strongly oppose bulk bot runs and making one option non-functional in the future. Thryduulf (talk) 15:29, 17 February 2021 (UTC)

  Re "Are y'all suggesting we bring back all deprecated parameters" - yep, that's spot on. They should never have been deprecated in the first place. This is a template, which sits in the background, and exists for editor convenience, nothing more. Deprecating parameters reduces that convenience. And it's well-established that bots and editors shouldn't be running through making cosmetic changes to wikitext that do nothing to alter the page, so those need to stop as well.  — Amakuru (talk) 12:48, 18 February 2021 (UTC)

• Option C, I guess, as I've not been persuaded as to the marginal utility of the hyphenated versions. Without that clarity, we shouldn't be doing these kinds of changes. (And if we had consensus, then B, but with documentation changes as the first step.) — JohnFromPinckney (talk) 01:48, 17 February 2021 (UTC)
• Option C If it works don't fix it. Andrew🐉(talk) 13:01, 17 February 2021 (UTC)
• Option A, strongly oppose option C: anybody working regularly on templates or modules will appreciate the value of settling on a single style for issues like parameter names. I don't care what the agreed style is, as long as it's consistent, and the argument about whether it should be hyphenated, underscored, camel-case or run-on has been settled with hyphenated as the preferred style. It is then nonsensical to fail to implement that style, and I'd prefer it was done as soon as possible. This whole debate is reminiscent of the date-linking wars where strong objections were made to unlinking dates, yet within a few months of a binding decision being reached to delink dates, everyone had moved on, and nobody today would even consider linking dates. Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is. --RexxS (talk) 19:46, 19 February 2021 (UTC)
• A or B but not C per Scott, Hawkeye, and RexxS. Usingahyphenismoreuserfriendly, andwhilethereissomeupfrontworkonourparttomaketheswitch, itisbetterinthelongruntohavesomedelimiterbetweenwordsinsteadofrunningthemtogether. Just like we stopped linking dates and no longer SmashWordsTogether, this is worth the temporary inconvenience. — Wug·a·po·des​ 00:46, 20 February 2021 (UTC)

  Notwhen it'sjust twowords :-P Levivich ^harass/_hound 08:10, 20 February 2021 (UTC)

  ...is what your comment would look like if we allowed people to use whichever method worked for them and still made it work. If we turn off those parameters, your comment wouldn't have appeared. If we allow people to use whatever works and use a bot to clean it up afterwards, your comment would look just like everyone else's after some period of time (during which your comment would still be functional, even if pairs of words were sometimes combined). :) — Rhododendrites ^talk \\ 20:15, 22 February 2021 (UTC)

• Option A for all the arguments already made at length in the CS1/CS2 talk pages over the years and the good arguments brought forward above. Definitely not Option C. --Matthiaspaul (talk) 02:06, 20 February 2021 (UTC)
• Option C. Such an absurd waste of time and energy and an enormous source of watchlist spam, all to achieve something that will make editing more difficult. Toohool (talk) 02:26, 22 February 2021 (UTC)
• Option A as standardizing is better in the long term. Let the bot continue its work. If people have a problem with their watchlist getting spammed, they have the option to filter out bot edits. AVSmalnad77 ^talk 05:59, 23 February 2021 (UTC)

Discussion (CS1)[edit]

Some suggestions regarding the options:

• Pedantry: "Non-hyphenated parameters" should read "Non-hyphenated multi-word parameters" in all three options. Parameters that contain only a single word or acronym do not need a hyphen.
• In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already.

Some history and a status update, for those here on VPP unfamiliar with the long history of updates and changes to the Citation Style 1 templates ({{cite web}} and its siblings): As far as I can tell, there are only six unhyphenated multi-word parameters left – |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= – out of an original population of many dozens. So far, through the work of scores of editors and bots over the seven years since we standardized on hyphenation of multi-word parameters, we have deprecated, removed from pages in affected namespaces, and then removed from the CS1 templates themselves (as WhatamIdoing suggests above), many dozens of different unhyphenated multi-word parameters in CS1/CS2 templates. All new multi-word parameters during that time have been introduced using only a hyphenated form. This RFC is essentially asking: should we finish the job, or leave it at over 90% done, in a sort of limbo state, with six parameters as exceptions to the overall pattern, just because those parameters are used in a lot of articles? – Jonesey95 (talk) 04:38, 11 February 2021 (UTC)

• Problem with "Option B": Option B is not the status quo. If it were, I'd be much happier. Since it's not, I don't know whether to !vote for A or B. The documentation at Cite web, for example, makes no mention of accessdate being deprecated. This means that users will be quite justified in blissfully adding and readding templates with accessdate, even after the bot has come through already and changed accessdate to access-date in 20 places. Each iteration tends to address fewer instances, but each run is a separate entry in my watchlist. Watchlist entries seem to be part of the complaint against this kind of work, so the first step should be turning off the faucet at the source, before spending energy to, um, bail out the boat. — JohnFromPinckney (talk) 06:37, 11 February 2021 (UTC)
  • The first sentence is true; all but six of the unhyphenated multi-word parameters have been formally deprecated and removed. As for "turning off the faucet at the source", that would be Option A, but in the past, when we have made red error messages appear in large numbers of articles as a first step in standardizing the citation templates and noting errors in them, there has been significant pushback. In order to avoid that pushback, the bot was acting to fix 90+% of the non-standard parameters before turning on the error messages, but that work has been stopped as well. Option A will allow that work to be completed. – Jonesey95 (talk) 15:09, 11 February 2021 (UTC)
    • I feel we are not understanding each other. "Deprecation" involves communication as a first step; removal is a second, later step. If we are going to have a bot changing pages (e.g., accessdate to access-date), causing some distress to the populace (and this is the status quo), then we should at least change the documentation to say that accessdate is deprecated, and is not a usable alias. I am strongly against a bot going around to change parameters to the "good" names when we don't ever tell the humans they shouldn't use the "bad" ones. That's just an endless cycle of watchlist-cluttering edits causing great irritation. If you want to avoid pushback, tell the people not to use the unhyphenated versions, then run the bot, then remove support some time later. — JohnFromPinckney (talk) 15:41, 11 February 2021 (UTC)
      • Deprecate in terms of the CS1 templates means to emit a red error message indicating deprecation. When we emit any red error messages for parameters in CS1 that are used often (or lack thereof for parameters that should be used more often), a lot of people get very irate. We do not change the documentation to indicate deprecation until after the module begins telling people inline about deprecation. So yes, you are not understanding each other, but it's a question of terms of art. --Izno (talk) 16:44, 11 February 2021 (UTC)
        • Why do people get irate? Because suddenly millions of readers go from nothing being wrong to seeing a load of red error messages all over hundreds of thousands of articles (and you couldn't seriously expect someone to debug a CS1 error as their first contribution). These citation templates aren't for us. They're for the reader and they need to be functional with low rate of error messaging 24/7 with no exception, because even small amounts of downtime have significant reputational damage. — Bilorv (talk) 02:54, 15 February 2021 (UTC)
          • I would be more sympathetic to such an argument of "significant reputational damage" if there weren't over 100,000 pages with active errors on them (and that's ignoring the hidden Category:CS1 errors: missing periodical) and another 250k in its sister (also hidden). --Izno (talk) 20:22, 15 February 2021 (UTC)
    • That "we" (who is that, some class of super-techies whose opinions count for much more than those of us "normal" editors?) get significant pushback when creating error messages is simply a demonstration that the wider community does not agree with what "we" have decided. The answer is to stop doing what you are doing, not to do it more stealthily. Phil Bridger (talk) 18:37, 11 February 2021 (UTC)
      • You are welcome to participate at Help talk:CS1, the same as any other editor. Decisions are made by consensus there, inline with how consensus is practiced everywhere else on wiki. Don't like a decision "we" made? Get involved. --Izno (talk) 18:42, 11 February 2021 (UTC)
        • I saw absolutely no discussion of the removal of the freetext editors field on the talk page. Where did that happen? I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)
          • The difference is between those people who think this is an encyclopedia and those who think that it's a playground for techies. Phil Bridger (talk) 20:43, 11 February 2021 (UTC)
            • Your ad hominem has no welcome here. Move along if that's the best you can offer to the discussion. --Izno (talk) 20:47, 11 February 2021 (UTC)
              • That is just the kind of reply that people who are here to create an encyclopedia tend to get from the techies. No response to genuine concerns but just an order to "move along". I have no wish to monitor whatever pages are used to ignore end users, but I have a right to expect that any decisions taken will respect the interests of everyone, not just a self-appointed clique of people who "know" what is right. Phil Bridger (talk) 19:53, 15 February 2021 (UTC)
                • It's the kind of reply to people who needlessly create category A and category B and then line themselves up in one or the other categories. If you (specific/personal) don't want to monitor whatever pages, that's your prerogative. Do know that it is your choice and you are responsible for that choice, and choices have consequences. Changes are always announced ahead of time and consensus is sought for non-obvious changes (and even obvious changes with non-obvious implementations), so you have no excuse not to tune in at least once every couple months when the regular "Shit is Changing" post gets made. Secondarily, the scare quotes are not indicated by this discussion, nor any prior discussion that I can see, whatsoever. I have not seen any such 'clique' nor any of the users who would prospectively be in such a 'clique' claim they "know" what is right. As I said, if you have nothing to contribute but smears and attacks and divisiveness, move on. --Izno (talk) 20:22, 15 February 2021 (UTC)
          • In reverse chronological order: the patch notes indicating removal, the removal discussion, the patch notes indicating deprecation, the deprecation discussion. 4 times mentioned over a period of half a year on that talk page, a pre-existing maintenance category indicating a soft deprecation, and my removal of over 4k instances of the parameter over the year and a half preceding that deprecation discussion. Basically by hand (my hand, as it happens). --Izno (talk) 20:45, 11 February 2021 (UTC)
          • As for I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all., I invite you the same as I invited Phil Bridger. You may watch and edit Help talk:CS1 at any time, the same as me. "I don't recognize these people" is a trash association to make and is the same kind of ad hominem that I have asked Phil so kindly to stop employing. It is certainly not sufficient cause to say "I don't like this change". --Izno (talk) 20:49, 11 February 2021 (UTC)
            • I think there's a genuine problem here that there's a disconnect between the editors maintaining the citation templates and the editors employing them to write and maintain articles. I didn't make the decision to abandon years of using citation templates (CS2 actually, but the same parameter changes are happening there too, even less announced) lightly. Espresso Addict (talk) 21:35, 11 February 2021 (UTC)

              The disconnect is real and significant. Someone whose skills and interest lie in writing or maintaining article content shouldn't need to care about what happens at pages like Help talk:CS1 (and how on earth is a new editor even meant to know that page exists?), let alone have to pay attention to discussions there. Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third. The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. We've ended up here because that hasn't been happening and a local consensus has ignored the needs of end users. Thryduulf (talk) 01:38, 12 February 2021 (UTC)

              I almost commented last night, and then put that version into a text file and went to bed. Now I have been spurred by a comment above to reply here. The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. If we prioritize different qualities versus this other supposed separate group, it's because we have the experience to do so. If you don't, let me reiterate, get involved. Come and say "I don't like this" or "this is a painful interaction" or X, Y, and Z, and provide a suggested fix. That's how consensus starts forming, like every other page or process on this website. Others will say "I don't want this to work like that suggested fix because A, B, and C". Then you discuss the tradeoffs and make a decision. If you're unwilling to step up and discuss the paper cuts, then we end up having mass RFCs or AN drama or what have you over what would otherwise be small issues or ones that could have been discussed informally with the ordinary "let's figure it out" consensus view of the world. That's a disconnect too, and blaming editors interested in one page versus those apparently disinterested is not the right way to move forward. Want something to be better? Ask. Propose. Cajole. Make the effort to put forth the minorest of social interactions required to start a discussion in the one place where everything about that thing is discussed. We're all volunteers and our heart is in just a right a place as yours, but if we should have disagreements, then we talk to each other and find out how to fix the problem or agree to disagree on the points of interest. Not have constant complaints of "they didn't listen to me". Consensus is not unanimity.

              The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. This is quite frankly an opinion lacking any community consensus whatsoever. We've recently approved an RFC allowing cosmetic edits on a regular basis and from what I could see in that discussion (and murmurings elsewhere), cosmetic edits might be closer to having consensus than not, it's just inertia that leaves us not performing them regularly. Moreover, hundreds of templates, and certainly all those which go through WP:TFD, have a process applied which causes breaking changes or which results in more-or-less cosmetic edits. Are you claiming that TFD does not have consensus as a process? That templates which are being cleaned up because of a talk page discussion on that template's talk page should be stopped? You want your cake (to not care about how things work) and eat it too (have all of your opinions and claims listened to, when they aren't even articulated in the first place). Get real. --Izno (talk) 20:22, 15 February 2021 (UTC)

              I fear this just demonstrates the truth of what Thryduulf writes. "The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head." is self-evidently false, as well as impolite. Speaking only for myself, what I actually want is to be able to get on with writing & improving articles, rather than having long side discussions on matters that aren't directly relevant. Espresso Addict (talk) 00:10, 16 February 2021 (UTC)

              get on with writing & improving articles Then do that. No-one is stopping you from not caring. I am just calling you hypocritical for raising a fuss when you don't and then changes happen elsewhere that affect you. Don't like it? Change your behavior. (I won't reply to you again.) --Izno (talk) 00:34, 16 February 2021 (UTC)

              The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. Both uncivil and not even close to correct. While it is possible that some, maybe even many, of the editors maintaining templates also write and maintain articles there are literally hundreds of editors writing and maintaining articles who have never been near a discussion about the template code, let alone written any code. Writing encyclopaedic prose and writing computer code are very different skills; nobody is or should be required to do both. However given that the purpose of this project is to write an encyclopaedia everything that is not writing an encyclopaedia should be done for the benefit of (first and foremost) readers of the encyclopaedia and (secondly) those who write and maintain the encyclopaedia. The convenience of those dealing with tools is least important. Thryduulf (talk) 00:23, 16 February 2021 (UTC)

              Writing encyclopaedic prose and writing computer code is a false dichotomy and a blatant misrepresentation of what the two paragraphs I had to say. I did not ask you to do both. Nor do I serve you (general) in your supposed role as an article writer. There are no (formal) hierarchies on this encyclopedia, and even considering yourself as supposedly above me or my efforts is the actual uncivil statement. Lastly, I place myself fully in both supposed groups given the thousands of articles where I have bettered their citations. (And as I said to Espresso, I will not reply in this section again.) --Izno (talk) 00:34, 16 February 2021 (UTC)

              My role here is not as an article writer (I do very little of that), I spend the majority of my time on the project trying to ensure that readers can find the content they are looking for and those that do write and improve articles without needing to worry about nonsense like this that will needlessly make their job harder. There might not be a formal hierarchy but their should be: (1) Readers are head-and-shoulders above anyone else. (2) Those who write and maintain the encyclopaedia a short way above (3) Those who support those write and maintain the encyclopaedia are a long way above (4) Those who hinder any of the above. I place myself in the third category alongside many of those who maintain templates. Thryduulf (talk) 21:02, 16 February 2021 (UTC)

• Comment. What is the merit of citation templates? Let alone the increasing creep to make them more and more rigid and harder and harder to use? The only reason I can see is to make it easier to export and sell data. No-one ever seems to give a thought to those who type citations manually; it is far harder to type "access-date" (which requires two hands and a hand movement) than "accessdate" (one hand, no move). I don't understand what the benefit of this change is at all. In fact, broadening this discussion, I don't understand why the freetext editors field was suddenly withdrawn this January. Personally I've decided to meet the latter change by reverting to writing out references by hand, which is easier, more flexible, and seems to have no downsides. Espresso Addict (talk) 07:04, 11 February 2021 (UTC)
  • Citation templates make standardizing citation style and look much easier. They can, for example, automatically standardize date display. Machine-readability is also a good thing, imo. I suppose access-date is slightly harder to type - but editors editing wikitext manually would probably not mind. Otherwise, tools for inserting these citations exist. Elliot321 (talk | contribs) 17:12, 11 February 2021 (UTC)
    • It's not slightly harder to type, it's a great deal harder to type for a touch typist. And here's an editor editing wikitext manually who does mind, enough to bother responding here. There's no tool I know of that creates citation template code in the form I prefer for ease of wikitext editing afterwards; they all make code soup that takes longer to fix than retype. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)

      A bit slower, yes, but I personally don't find it a great deal harder—touch typists generally have practised it a lot while learning. Nonetheless, I don't think ease of typing by some metric is the primary issue. isaacl (talk) 20:40, 11 February 2021 (UTC)

      Speaking as one of those touch-typists, and as a person who learned to type on an actual typewriter, I don't find the hyphenated version any harder to type, and I do recall my typing teacher saying that it was faster and easier to type words that were split evenly between hands, instead of all in one hand. WhatamIdoing (talk) 22:49, 11 February 2021 (UTC)

      Yeah, personally I imagine it has a greater effect for a hunt-and-peck typist. When I said a bit slower, I was thinking compared with a word of equal length that consisted only of letters. Of course, in this case, the hyphenated name has one more character which would comprise most of the difference for me. isaacl (talk) 23:02, 11 February 2021 (UTC)

    • I use citation templates myself, but I respect the wishes of those who prefer not to use them. It is precisely the fact that I use them that leads me to the opinion that obvious synonyms for parameters should not be removed, as proposed here. What on Earth is the problem with allowing both hyphenated or unhyphenated forms? All it means is a few extra bytes of storage, and no extra code if it is done properly. And the work has already been done, but this proposal is to undo it. Do we still live in the days when I started in IT working for one of the world's leading business information companies whose UK operations were all run from a computer with 1MB of memory and where all online programs were limited to 12KB? I thought we had moved on from there. Phil Bridger (talk) 20:34, 11 February 2021 (UTC)

      I am reminded of a story about a lady, who (decades ago) bought a large supply of personalized stationery and then discovered that the post office was renaming her street. She convinced the local postmaster into letting her continue to use the old address until her stationery was used up. This saved her some money and effort, but it had external costs. For many years to come, every mail carrier had to learn that "123 Main Street" wasn't on Main Street and wasn't number 123, but instead had to be delivered to the other side of town.

      Aliases are often low-cost in storage and computational terms, but they are not actually free. "Not free" can add up to a quite significant cost when it is repeated a million times. WhatamIdoing (talk) 22:56, 11 February 2021 (UTC)

• Although I sympathize with the desire for all templates to align with one standard (from a user's perspective, I would personally find it easier), I just don't think it's feasible at this point in time. In which case, I sympathize with those who think computers should make our lives easier, and just accept both formats. On the third hand, from an implementer's perspective, I appreciate that it adds a lot of noise to template syntax, if not implemented with a Lua module. Since the CS1-based templates are implemented with Lua, the overhead can be minimized, and so I think both formats should continue to be supported. I don't feel there is much advantage to converting en masse, by any mechanism. isaacl (talk) 20:40, 11 February 2021 (UTC)
• Pinging some previous participants in related conversations who may not yet be aware of this discussion: @SandyGeorgia, Jason Quinn, Oknazevad, Tom.Reding, Brainulator, DavidBrooks, SMcCandlish, David Eppstein, Matthiaspaul, Headbomb, Gracefool, Ss112, JG66, Mikeblas, Gonzo fan2007, Sariel Xilo, Modest Genius, and SlimVirgin:. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)

  Thanks for the ping, I was indeed unaware of this discussion. Modest Genius talk 12:16, 12 February 2021 (UTC)

• Does anyone have any evidence that having alias for parameters makes things harder for end users? In my experience as a trainer and long-time user, having multiple ways to achieve the same ends allows editors to spend their time and energy working on content rather than puzzling over making sure that the template parameters are named in exactly the right way. I've never met anybody who was comfortable enough to be dealing with templates in the first place who was not completely comfortable with the idea that "you can write it as either access-date or accessdate, it doesn't make a difference." (or similar). Speaking personally, I don't want to have to learn whether it is "accessdate", "access-date", "access_date" or "access date", I just want them all to be accepted so that whichever I input the template works and I can worry about more important things. Thryduulf (talk) 01:29, 12 February 2021 (UTC)

  The inconsistency across all templates does make things harder. Users have to either remember which templates only support one form and which one, or look it up each time. I appreciate though that there is extra complexity in trying to support lots of aliases, particularly for ones that aren't implemented with a Lua module (either each use is going to become more elaborate and verbose, or the template could delegate the detailed implementation to a helper template, with the top-level one only doing parameter normalization), so personally I wouldn't want to require that every template must support aliasing. Thus I think we're kind of stuck with inconsistency. isaacl (talk) 02:12, 12 February 2021 (UTC)

  This inconsistency should be tolerated. Some, particularly high-use, templates having aliases is important for the great number of people who use these templates. They don't have to remember was it |access-date= or |accessdate=. If it doesn't work on some other template, well fine. But eliminating aliases and simply making the computer say no on all templates makes things a lot harder for the vast majority of users. That inconvenience is far greater than the fact that a few lesser-used templates don't support aliases and you might need to take a look at the documentation sometimes. – Finnusertop (talk ⋅ contribs) 06:05, 12 February 2021 (UTC)

  Yes, as I said in another comment, I feel both forms should continue to be supported for the CS1-based templates. I'm pretty sure the vast majority of templates don't support both hyphenated and non-hyphenated parameters—for example, from what I can tell from the code and a quick test, {{Infobox}} doesn't. That's just the way it goes when trying to make as many aspects of Wikipedia markup accessible to as many editors as possible: standardization won't always happen, and often simpler markup will be preferred by more editors than more complex markup, even if it would add more functionality for users. isaacl (talk) 22:22, 12 February 2021 (UTC)

• Thanks to Nikkimaria for the ping based on my earlier involvement. I'm appallingly neutral (or torn) on the main topic but I earlier did some analysis that gives me concern about impacts on Template space in particular, if deprecation goes ahead fully. Here I'll use |authorlink= as a proxy for all six, because I personally type it more often. There are three areas that concern me: templates that indirectly invoke CS1, those that transclude CS1-invoking templates, and clones. I'm concerned about where and when red error messages appear, and documentation, in which I include both /doc and TemplateData.

1. There are many CS1-friendly templates that invoke one of the canonical templates; {{Cite encyclopedia}} is often used for example. Some use parameter rewriting, converting |authorlink= to |author-link= before passing it on.
   1. Does their documentation always give precedence to |author-link=? I think we caught them all during the earlier discussion, but I can't guarantee the quality of the search.
   2. Because the CS1 code never sees the deprecated parameter, should this template emit a red error itself during the substitution? Or maybe just forget about the mapping and have CS1 do it? And how hard is it to find templates with the parameter substitution code?
   3. If |authorlink= ever moves from deprecated to invalid, then all those mappings and documentation need to be trimmed in one fell swoop. Well, I guess the mappings can stay in place although they could trip up inattentive longtime users.
2. There are templates that simply transclude a pre-filled CS1-style template: for example embedding {{Cite book}} as a citation to a specific volume that is relevant to any use of this template. Have they all been fixed? If not, their user will see a red error message (correct?) that has nothing to do with their own usage.
3. There may be templates that are modeled on CS1 but roll their own expansion, although I don't know of any such. If they happen to use |authorlink=, should they also be brought in line?

Two final comments: there are more than six, if you consider variants like |author1link= and |authorlink1=. And in principle the arguments above apply to any page outside Template space that gets transcluded by someone, although I know that feature is rarely used. David Brooks (talk) 16:51, 12 February 2021 (UTC)

Shoulda said: the above applies to A and to some extent B but you can probably figure that out. David Brooks (talk) 16:57, 12 February 2021 (UTC)

DavidBrooks: There is a tiny army of editors at the ready to fix these templates. As far as I know, there are no transcludable templates that pass |authorlink=, your example, to any CS1 templates, so using those templates would not generate an error message. |accessdate= and the two or three remaining unhyphenated parameters being passed from template transclusions to CS1 templates were being processed by the bot before the bot was paused to hold this discussion. Once this discussion is closed, the bot will be able to resume that work, with human assistance, if the closure is a reasonable one. – Jonesey95 (talk) 17:13, 21 February 2021 (UTC)

@Jonesey95: I just addressed a related issue in Help talk:Citation Style 1, where by modifying the example given I found 3 templates that use |authorlink= in a CS1-style template that's used to reference a specific source: {{Barmakids family tree}}, {{Citeer web}}, {{Alox2}}. But this less restrictive query shows a few more (ignore the "DYK" archive, I think). Not sure if you meant this type of usage in your comment; I may be missing the context. David Brooks (talk) 05:05, 22 February 2021 (UTC)

@Jonesey95: OK, looks like you fixed {{Alox2}}. {{Barmakids family tree}} and {{Citeer web}} still need to be fixed (I'll do them later today). The documentation of "Cite book (short)" in {{Quicktemplates}} lists the not-incorrect |authorlink=, so that comes under the "prefer the hyphen forms in documentation" rule. I didn't look for |authorlink2= or |author2link= because they are unlikely to appear alone. David Brooks (talk) 19:17, 22 February 2021 (UTC) ... Y, also {{Bach's compositions (sources)}}, which indeed had |author2link =. David Brooks (talk) 21:42, 22 February 2021 (UTC)

• I would like to clarify what I meant when I originally wrote the options, since there is some confusion. My intention with "removal" was to refer only to removal of usage of nonhyphenated parameters by transclusions of the template, not removal from the implementation of the template itself (I will call this "disabling the parameter"). This is also distinct from deprecation, which is designating something in documentation and warning messages as discouraged. Remember that the original reason for this RfC is to clarify whether we should have a bot going through the article space removing the parameter usage as its sole action. A, B, and C are respectively continue removing now, remove only as part of other non-cosmetic edits or in a situation where cosmetic-only edits are allowed, or do not remove. In case of A or B, I did not intend for them to make a statement about whether we should disable the parameter when this is done. This is an important question, but orthogonal to whether the parameter usage is removed now or later. — The Earwig alt ⟨talk⟩ 22:11, 13 February 2021 (UTC)

  Thanks for clarifying (except the part where you formulated the options). Unfortunately, it now means I'm missing the option: Non-hyphenated parameters should be deprecated now and removed later. The actual status quo seems to be: Non-hyphenated parameters should be removed now and deprecated later, and the removal can occur by bot which does nothing else on the page (cosmetic only), but will revisit the page as often as necessary to re-remove the non-deprecated params that keep getting added. — JohnFromPinckney (talk) 23:01, 13 February 2021 (UTC)

  For context, this is how I originally phrased it; note B and C are swapped. Isn’t what you’re desiring exactly option B (in the current formulation)? It seems describing B as the "status quo" is confusing. Instead, view A as what the bot was doing before it was stopped, and B as what is currently happening with the bot stopped, but with clear, formal deprecation. — The Earwig alt ⟨talk⟩ 00:19, 14 February 2021 (UTC)

  Mmm, maybe, and in any case I'm very grateful for your link to the pre-RfC coordination at Primefac's Talk. And I can say that your original formulation was clearer than the formulation we're now using for the RfC proper. However:

  1. There appears to be no consensus for the removal of non-hyphenated multiword parameters. The 2014 RfC determined only that the hyphenated version must exist, and the close explicitly allowed for non-hyphenates.
  2. If this RfC is intended to determine whether non-hyphenates should be deprecated, it's poorly formulated to the extent that it mentions the current bot activities.
  3. I can't view Option A as what the bot was doing before it was stopped, because the parameter has not been deprecated. (The statement by Nikkimaria that deprecation "in the context of CS1/CS2" means a red maintenance message will be shown is not something I can accept, as any reasonable software provider knows that advance notice is the first part of deprecation. Unfortunately, I don't usually work "in the context of CS1/CS2", so haven't argued before against this unhappy definition.)
  4. Option B, as written on this page, is a garbled mess, not only because of the "status quo" mention, but also because of the "Deprecation can be bundled into genfixes..." bit. Deprecation, as above, is (first) a documentation task, followed by a (presumably small) step to cause red messages to be generated (I'm not sure what's involved here). I don't see what would need to be "bundled into genfixes". I had the feeling that many !voting here saw "removal" as meaning elimination of usages, but maybe that's due to my own confusion. Your Option C (and your original formulations in general) were much clearer.

  There should never have been any bot activities, because (a) there's no consensus, yet, to deprecate non-hyphenates, (b) the params are not yet deprecated, and (c) the bots' edits have been largely accessdate => access-date only, so violate WP:COSMETICBOT. So I guess I'll be !voting for B, although I'd much rather choose your original Option C. This RfC as written has been too unclear (at least for me). — JohnFromPinckney (talk) 11:20, 14 February 2021 (UTC)

  Re The 2014 RfC determined only that the hyphenated version must exist: As called out in the proposal, it also said The documentation is to show this lowercase, hyphenated version as the one for "normal use". Hence my comment above: some of us recently tweaked the documentation of a few high-use templates to make the hyphenated version the privileged one, but I can't guarantee we got both /doc and TemplateData for every template that indirectly uses CS1/2. If we end up with both hyphen and no-hyphen equally valid (is that C?), then tweaking the documentation will be the only change visible to current editors. SHould there be a more valiant effort to track them all down? David Brooks (talk) 19:45, 14 February 2021 (UTC)

  If the consensus is for Option C, then nobody has to track down anything; we can leave the documentation as it is. BTW, the claim written there, This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters is another red herring and would, it seems, not apply at all (as accessdate isn't even listed there yet).

  If we chose Options A or B, then yes, the documentation should be immediately changed. I can't believe it will take too much valor to find the Template:Cite web documentation, as it doesn't seem terrible exotic, but it should be included in the tweaking in those cases. — JohnFromPinckney (talk) 20:07, 14 February 2021 (UTC)

  • The 2014 RFC had a participation of only seven people and was six or seven years ago. It is patiently absurd to update documentation with such a sweeping change based on that alone, and any such changes ought to be reverted pending the outcome of a more clear RFC. Furthermore, the 2014 RFC specifically indicated that nothing would be depreciated, so if you are relying on it as a justification for any changes then obviously no non-hyphenated versions can be depreciated until / unless a new RFC overturns it. --Aquillion (talk) 22:19, 15 February 2021 (UTC)

  Please read the summary at the top of this Discussion section. Here's the summary of that summary: Dozens of unhyphenated multi-word parameters have been deprecated, removed from pages, and then removed from the Citation Style 1 templates over the last seven years. There are only six left. During those seven years, many new, hyphenated multi-word parameters have been introduced, without unhyphenated aliases. At present, the situation is that unhyphenated multi-word parameters are the standard, and there is just a bit more work to do to remove the final six outliers. Unfortunately, it appears that many editors have not enabled the useful settings "Expand watchlist to show all changes, not just the most recent" and "Group changes by page in recent changes and watchlist" so that bot edits can be hidden without losing visibility of bad human edits, so people are complaining about a bot "clogging" their watchlists. – Jonesey95 (talk) 23:59, 15 February 2021 (UTC)

  None of that is however relevant to Aquillion's comment in the slightest. That a flimsy consensus (at best) has been used to justify removing functionality in the past does not mean that that removal was a good thing or that the bot edits (which clog both watchlists and page histories with unnecessary edits, whether they hide other edits or not) should continue. Indeed, I strongly suspect there would be support for re-enabling the parameters already removed. Thryduulf (talk) 00:27, 16 February 2021 (UTC)

Please note, folks, that this bot is a one-off; it may be processing some 2 or 3 million pages, but it's still a one-off, that is (unless reverted) it will only ever appear ONCE in any article history. So the idea that it's "clogging up" page histories is a big red herring. If you're bothered about it "clogging up" your watchlist, then please set the options recommended by Jonesey95 and others. So that objection falls by the wayside too. Please also note that this bot finishes the job. Once it's done, that's it – no more bots making this sort of change. To the charge that this bot is "disruptive" or that it's somehow "removing functionality", I can't do better than copy Rexx's observation above: "Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is." --NSH001 (talk) 19:30, 21 February 2021 (UTC)

Except that, no, that's completely inaccurate. Consider List of University of Pennsylvania people. When I look at the last 500 edits just now, I see that Monkbot has been there SEVEN times: here (21:07, 19 October 2020) and here (01:02, 28 December 2020) and here (17:21, 14 January 2021) and here (21:21, 16 January 2021) and here (01:53, 18 January 2021) and here (15:30, 18 January 2021) and here (20:54, 30 January 2021). While that first edit (from October) did nothing with |accessdate=, the others all did, as often as it found new additions to the article. Note that the fifth and sixth edits both occurred on the same day.

I don't ordinarily block bot edits from my watchlist because I want to know what's going on with "my" articles, and the bots generally do useful and interesting work. It's just that the (to me) sudden and unforeseen flurry of multitudinous edits (doing, it appears, nothing which really interests me) was quite irritating. The repetition on List of University of Pennsylvania people really got my blood pressure up, and that's not far off from "disruptive" to me. — JohnFromPinckney (talk) 21:15, 21 February 2021 (UTC)

Hmm... The October edit is Monkbot 17 (not 18), so doesn't fall into the scope of this RfC. The edit on 28 December is the main application of this bot. That leaves 5 (mostly quite small) unexpected additional edits by the bot. They are all caused by editors adding parms that don't conform to the canonical standard. So yes, I should have qualified my statement by allowing for that possibility, sorry for that. Understandable that this should happen in the absence of a clear deprecation (so far) of the unhyphenated form. Perhaps the editors concerned are using some cite-generating tool that doesn't generate the canonical form, in which case the tool should be updated. Whatever, that strengthens the case for deprecating the non-canonical forms ASAP, and for moving forward as fast as possible with the main task. It's late now, and I will be going to bed shortly. Will comment on Phil Bidger's intemperate remark below in the morning. --NSH001 (talk) 00:06, 22 February 2021 (UTC)

Naw, the editor concerned is/was just copying/pasting whatever they found in whatever articles they were looking at. (The user also hasn't learned that refs go after punctuation, or that a named ref copied from another article might not be declared on the target page, or that Wikipedia has a Preview function to allow checking for errors. Not that I'm bitter.) Agreed, without actual deprecation, nobody knows what they're supposed to use or not use, so watchlists get plagued with unnecessary repetition. And I can't point such a user to the deprecation or consensus not to use the non-hyphenated forms, because there aren't any yet. — JohnFromPinckney (talk) 00:21, 22 February 2021 (UTC)

Thanks for that. If it is the case that editors on that page are simply copy-pasting cites from the original wiki bios, then that's good news – the problem will go away if the bot is simply allowed to continue and fix the problem in the source articles. I don't think it's true that there is no consensus for this change: the desired style was settled in an RfC several years ago, and has been 90% implemented in the years since, with no substantial objection. So there is an effective consensus, and it makes no sense not to carry the task through to its logical conclusion. The objections here amount to a dislike of large numbers of bot edits appearing on watchlists, not on the actual merits of the case. --NSH001 (talk) 07:34, 22 February 2021 (UTC)

The RfC in question only had seven supports, and only concerned making sure a hyphenated version existed and was presented first in the documentation. I don't know how that could be read as effective consensus for deprecating a parameter that, prior to the bot run, seems to have been more commonly used than the hyphenated variant - and even if it could, it would be a limited one. The objection to the bot is not just that it edits a lot, but that it "fixes" something that isn't a problem. Nikkimaria (talk) 14:01, 22 February 2021 (UTC)

Exactly this. — JohnFromPinckney (talk) 02:05, 23 February 2021 (UTC)

So the solution to a bot editing against consensus is for those who object to stop watching it? You couldn't make this stuff up. Once again, this is a fucking encyclopedia, not a place for techies to dictate to editors. Find a playground elsewhere, or get a real job and you will find out that people can only get paid to write programs if thay do what their users want them to. Phil Bridger (talk) 21:27, 21 February 2021 (UTC)

Color code http and https links differently[edit]

Should we indicate by color code whether a link to a website has an SSL certificate? For example, Wikipedia shows a box/arrow that is blue. That's good because it is https. However, a site like CI, which has no SSL certificate and connects as http has the same color (blue) box/arrow. I suggest we turn that red. Charles Juvon (talk) 00:19, 11 February 2021 (UTC)

I think they could be coded to display a lock to show it is a secure connection. I remember seeing this on FANDOM. Aasim (talk) 04:27, 11 February 2021 (UTC)

I don't know what you two are talking about; I'm using Firefox 52 (yeah, I know) on Vista (can't help it) with the Modern skin, and I see a yellow lock next to the blue link for Wikipedia, and a blue box with an arrow coming out of it next to the blue link for CI. If I saw a red link, it would make me think a wiki target didn't exist, so it'd be confusing. IOW, for me, the "problem" is already solved. Ergo, no, we don't need to add an unexpected color to our hyperlinks. — JohnFromPinckney (talk) 06:29, 11 February 2021 (UTC)

JohnFromPinckney, Modern is not a maintained skin beyond what it takes for it to function from a PHP perspective. Don't use it if you want to have a good representation of what most people see today. (I am minded to hunt down the relevant CSS and have it removed if it still displays as such.) --Izno (talk) 15:29, 11 February 2021 (UTC)

Thanks for the tip, Izno. But: how am I supposed to know that? I was using Vector, but several things (Alerts, Notifications, show/hide on collapsed items) stopped working, so I tried one of the four other skins in my Preferences list. Modern didn't exhibit any of those problems, so I thought I was up to date. And besides: "Modern". IYKWIM.

And now, it seems that my obsolete skin is more functional (in terms of http/https icons) that what other WP users use. So I'm totally confused. — JohnFromPinckney (talk) 15:49, 11 February 2021 (UTC)

JohnFromPinckney, to answer the question in your edit summary, Modern has been a skin for at least a decade and offhand I believe it predates Vector. The name "Modern" is just a 'pretty' name. --Izno (talk) 15:59, 11 February 2021 (UTC)

I'm calling my lawyer to see about suing for false advertising. I require a remedy for the mental anguish I've endured... — JohnFromPinckney (talk) 16:03, 11 February 2021 (UTC)

Oh rats, here I was hoping I wouldn't need to block you for using Firefox 52 on Vista. C'est la vie. --Izno (talk) 16:08, 11 February 2021 (UTC)

Don't block me for using Vista; it's not my fault and, trust me, I'm suffering enough. You should block me for WP:THREAT. ;-) — JohnFromPinckney (talk) 16:20, 11 February 2021 (UTC)

Enforcing actual policy? Sounds like bologna. --Izno (talk) 16:29, 11 February 2021 (UTC)

I do not anticipate a change here. The previous differentiating "lock" for HTTPS was removed because they had become noise to most people (most sites were migrating or had been migrated to HTTPS by that time). They were removed in 1.23/1.24, nearly 7 years ago. It would be just as noisy for us to add something to unsecured links. Moreover, some websites do not keep up their actual certificates, so at best we are linking to something with HTTPS in the scheme but which we can only guess as being secured. Bad idea overall.--Izno (talk) 15:29, 11 February 2021 (UTC)

@Charles Juvon: You can change it for yourself only. This is the CSS rule to put in Special:MyPage/common.css:

/* Blue padlock for secure links */#bodyContent a.external[href ^="https://"] { background: url(//upload.wikimedia.org/wikipedia/commons/0/00/Lock_icon_blue.gif) center right no-repeat;}

With this rule, links to https: sites will get a blue padlock, links to http: sites will retain the arrow-out-of-box icon. --Redrose64 🌹 (talk) 16:39, 11 February 2021 (UTC)

We should prefer HTTPS links, but it's not important enough to the average reader to justify the extra visual clutter. It would be better to have some sort of bot or userscript that can change/highlight HTTP links for editors who opt-in (if it doesn't already exist). – Joe (talk) 16:46, 11 February 2021 (UTC)

For most common/big sites, MediaWiki does an automatic transform of HTTP to HTTPS since a year or two ago. There is additionally a bot for that to change the wikitext. RR above provides the perhaps-desired CSS for indicating which are secure; one could change it trivially for the reverse case. --Izno (talk) 17:10, 11 February 2021 (UTC)

Thank you all for considering my proposal and discussing it in such an informed manner. Special thanks to @Redrose64: for the CSS rule. I remain concerned about our readership. Most know not to click a link in spam email, but they might not expect WP to send them off to a bad site. There is another issue: Recently, I obtained an SSL certificate for my personal website. I had to remove every single http link in my site to obtain a certificate. So, I assume, there is an exception for large well known sites like WP. Is that correct? Charles Juvon (talk) 17:32, 11 February 2021 (UTC)

That's not a requirement to get an SSL/TLS certificate for anyone... where did you get it from? How could it possibly be enforced? Anyway, something like 10% of major websites still use HTTP, so it's not intrinsically dangerous to follow a link to one. Wikipedia itself has enforced HTTPS for years and I don't think it's our responsibility to point out that other websites don't; most people using a modern browser will already see a warning. – Joe (talk) 10:42, 12 February 2021 (UTC)

Agree with Joe. No need for Wikipedia to provide this clutter. This is a problem for browsers. Lack of TLS isn't inherently dangerous anyway. ProcrastinatingReader (talk) 00:18, 13 February 2021 (UTC)

@Joe Roe: I am not at SSL expert, but I definitely had to remove all http links from a Yahoo Business website as per their policy. Our own article on TLS is rather complicated, and it references many sources including this. Perhaps one can conclude that individual web hosting services are setting policy. Charles Juvon (talk) 17:45, 13 February 2021 (UTC)

@Charles Juvon: nothing in the document you linked to says anything about need to remove HTTP links to obtain a certificate. It says nothing about the requirements to obtain a certificate at all. All it says is that if you use HTTP resources on your site, browsers and other tools may warn that your site is insecure or has mixed content. Note that despite some confusing wording, this refers to resources only i.e. files that need to be loaded to render the page e.g. images (with <img> or whatever), fonts, scripts. It doesn't refer to hyperlinks (<a href> etc) on a website to other pages or websites. (I.E. Other sites or pages that may be loaded by the end user clicking on them, but which aren't loaded to render page.) Also, the very fact they mention this means it's possible to obtain a certificate even with insecure resources, let alone links. Otherwise you could never have a mixed content site. Nil Einne (talk) 17:23, 14 February 2021 (UTC)

Adding a reply button on all talk pages.[edit]

I believe this will help many beginner editors. When you click it you just type a message and then it automatically puts your signature. SoyokoAnis 19:21, 12 February 2021 (UTC)

This is part of the WP:Talk pages project. There's an ongoing discussion about experiences using the tool here. ProcrastinatingReader (talk) 19:23, 12 February 2021 (UTC)

It's an excellent suggestion that everybody wants. In addition to the Talk pages project tool linked to above, there is a script, User:Enterprisey/reply-link, that you can install. Levivich ^harass/_hound 21:13, 12 February 2021 (UTC)

Which doesn't allow an edit summary, so I don't use it. Doug Weller talk 19:58, 13 February 2021 (UTC)

It can be configured to allow an edit summary to be entered. isaacl (talk) 23:06, 13 February 2021 (UTC)

Almost nobody actually types meaningful manual edit summaries on talk page edits, and even the editors who use the edit summary option the most on talk pages will use pointless edit summaries such as c (meaning "comment") on occasion. Whatamidoing (WMF) (talk) 21:50, 15 February 2021 (UTC)

Sure; I was just addressing Doug Weller's issue. Looking at that editor's contributions made me think that admins are probably more likely to use edit summaries on user talk pages in order to explain their actions. isaacl (talk) 22:33, 15 February 2021 (UTC)

New speedy delete criterion (Not for Wikipedia)[edit]

This AfD could have been resolved earlier if there was this criterion. It was clearly not for Wikipedia, and it was a WP:SNOW anyway. The text should read as follows:

Ax. Not for Wikipedia.

Pages which qualify under Not for Wikipedia as not for Wikipedia. (templates)

-or something to that effect. This should be numbered A12. Please consider this, as it will help avoid future unnecessary AfDs like that. AnotherEditor144 ^{talk contribs} 21:56, 14 February 2021 (UTC)

Just let the process work out. It will be gone within a week. --Malcolmxl5 (talk) 22:18, 14 February 2021 (UTC)

Clearly not for Wikipedia is far too broad and subjective for a speedy deletion criteria. I'm a little more sympathetic to AFD snow as a speedy deletion criteria, except for the issue that sometimes it can be a while before someone comes along and does the legwork to find spources and save an article. ϢereSpielChequers 22:45, 14 February 2021 (UTC)

• I of course also agree that "not for Wikipedia" is much too broad and subjective for CSD. As for SNOW, it can't be a CSD because then future iterations of the article wouldn't be G4-eligible. Perhaps a better idea would be to create some sort of "requested SNOW closure" category (perhaps populated via a template) to notify administrators that a SNOW close had been requested. Extraordinary Writ (talk) 22:59, 14 February 2021 (UTC)

  Wouldn't that require making WP:SNOW a guideline first? Adam9007 (talk) 23:09, 14 February 2021 (UTC)

  Snowball closes are authorized by WP:XFD, which is a guideline. I thus think that a requested SNOW close category would be valid, although the details would probably still need to be fleshed out. (WP:SNOW probably should be a guideline, for what it's worth, although I don't think it's necessary for our purposes.) Extraordinary Writ (talk) 23:25, 14 February 2021 (UTC)

  Ok. Let's go to Wikipedia talk:Criteria for speedy deletion and sort this out. AnotherEditor144 ^{talk contribs} 07:33, 15 February 2021 (UTC)

• (edit conflict) This is a frequently suggested criterion for speedy deletion, indeed so much that it is point one at WP:NOTCSD. Also, for future reference, the correct location to proposed speedy deletion criteria is Wikipedia talk:Criteria for speedy deletion. Thryduulf (talk) 23:01, 14 February 2021 (UTC)

  Ok. AnotherEditor144 ^{talk contribs} 07:28, 15 February 2021 (UTC)

• So should this maybe be moved to the talk for the CSD page? Foxnpichu (talk) 14:22, 15 February 2021 (UTC)
  • Only if someone has a proposal for something different to what has been suggested and rejected countless times before. Also don't bother unless it meets all four of the criteria at WP:NEWCSD. Thryduulf (talk) 15:14, 15 February 2021 (UTC)
    • I wonder whether what's needed is actually to change CSD's name, from "speedy deletion" – everyone wants bad articles to be removed quickly, so if CSD doesn't have the right criteria to fit the page I want to get rid of, then we should just expand the list some more – to something like "undiscussed deletion". WhatamIdoing (talk) 06:42, 16 February 2021 (UTC)
      • Interesting idea. Ideally a new name would include something to indicate that it is an exception to the standard process for exceptional situations not something that's just for "things one or more editors dislike". Thryduulf (talk) 12:31, 16 February 2021 (UTC)
        • That’s the problem. If an article seriously needs deletion, it is best to delete it immediately. Foxnpichu (talk) 23:05, 16 February 2021 (UTC)

RfC: Disable minor edits on English Wikipedia[edit]

Proposed: Effectively disable the "minor edits" functionality on the English Wikipedia. Its usage will be limited by policy for anti-vandalism reverts only. Technically, the permission to mark as minor will be limited to rollbackers, admins and bots. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)

Survey (minor edits)[edit]

• Support The point is apparently for some editors to ignore "m" edits on watchlists. No experienced editor would do so because "m" edits can be as wrong, disruptive, or destructive as a "major" edit. Vandals can use them for vandalism, newbie editors in good faith with problematic changes, and experienced editors may make something they believe is minor but other editors disagree. Really, all edits are subject to dispute. The point of a watchlist is to monitor articles. What's more, we apparently block editors for minor edits related issues. The functionality is not only useless, it's a net negative. Minor edits can be communicated via the edit summary and the diff count. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)
• Oppose. I mark edits as minor all the time when they are, in fact, minor. Fixing typos and the like need not bother editors who don't want to see those edits. If there is a problem with non-minor edits being marked as minor, figure out how to figure those out. We already flag, for example, possible changes in birth and death dates. BD2412 T 20:03, 15 February 2021 (UTC)
• Oppose a policy that minor should only be for vandalism reversion; I agree with BD2412 that actions such as small typo fixes, small whitespace adjustments, etc should still qualify as "minor" for patrolling and review purposes. Nuetral on an overlapping component of this, the removal of the minoredit permission from "All Users" - if it is being misused frequently by newer users might be helpful - but if so I think it should go to +extendedconfirmed and/or other groups (i.e. rollbacker/patroller) that otherwise help recognize that an editor has a modicum of experience here. — xaosflux ^Talk 20:23, 15 February 2021 (UTC)
  • A perfectly cromulent use case is by a bot that has to make a non-content clean up to user talk pages, by declaring the edit minor and leveraging their nominornewtalk permission - the operator can avoid bothering users with a new messages notification. While "bots" were in the original proposal, this use case fails the "anti-vandalism reverts only" criteria. — xaosflux ^Talk 20:41, 15 February 2021 (UTC)

    For clarity, I meant anti-vandalism only for human editors (bots being able to use it as they do). ProcrastinatingReader (talk) 20:44, 15 February 2021 (UTC)

    @ProcrastinatingReader: OK thanks, any bot use should already be governed by a specific WP:BRFA for whatever it is they are doing (and this is almost always used in addition to the 'b'ot flag). — xaosflux ^Talk 20:52, 15 February 2021 (UTC)

    Re typos, a typo fix can still be disputed. Perhaps the editor got it wrong and the 'typo' was intentional. More importantly, Suffusion of Yellow's comment, especially about the evil bit, is a good way to phrase the issue imo. So long as some disputed edits can flow through it, the entire feature is worthless. The anti-vandalism allowance is because that's already governed by existing policy, WP:ROLLBACKUSE and WP:VAND etc, and allows pure 'junk' to be filtered out. Though I'm also okay with removing this exemption. ProcrastinatingReader (talk) 20:55, 15 February 2021 (UTC)

• Support. So long as this feature is available to spammers, vandals, and the clueless, it's as useless as the evil bit. It's also a source of needless drama, when users innocently overuse it. But if people think this proposal goes too far, limiting it to extendedconfirmed would be a good start. Suffusion of Yellow (talk) 20:33, 15 February 2021 (UTC)
• Oppose Why? Mike Peel (talk) 20:35, 15 February 2021 (UTC)
• Support, tentatively, disabling the option when making a manual edit. It's simply not that useful; even experienced users don't agree on what it means, and don't use it consistently. The byte count is a much more effective way to identify "minor" changes at a glance, since it's less prone to manipulation. Because the minor flag can be set inappropriately, it's almost never reasonable to completely filter out minor edits, so it simply acts as a weak signal of intent on page histories, redundant to edit summary and byte count. Not convinced about making it antivandalism-only, though. — The Earwig ⟨talk⟩ 20:37, 15 February 2021 (UTC)

  After reading the comments in opposition and consideration of alternate solutions for the problem, I don't think this proposal as written is the way to go. — The Earwig ⟨talk⟩ 19:13, 16 February 2021 (UTC)

• Oppose as written. It might make sense to further limit who can mark edits as minor, but eliminating them nearly wholesale as this proposal does goes too far. This is using a bunker buster to wipeout a few hornets. -- Calidum 21:11, 15 February 2021 (UTC)
• Support the idea of disabling the option to mark edits as minor when editing manually. I don’t really see the point of making the ‘minor’ flag CV only, or granting it to admins or rollbackers. If we think it’s useless, then let’s deprecate it fully, rather than trying to debate who is experienced enough to use it. The only truly clear use for minor edits is bots editing user talk pages as Xaosflux sagely said above, so bots should obviously keep the right for that reason. Bot edits can already be filtered from watchlists, so other than on user talk pages it doesn’t matter whether bot edits are minor or not. ƒirefly ( t · c ) 21:35, 15 February 2021 (UTC)

  Other uses of minor edits include (but are not limited to):

  • Spelling fixes
  • Capitalisation fixes
  • Typo fixes
  • Grammar fixes
  • bold/italic fixes
  • List order fixes
  • Markup fixes (templates, tables, etc)
  • Small corrections to comments (e.g. missing words)
  • Signing unsigned comments
  • Whitespace fixes
  • Addition of templates that have no or minimal impact on content (e.g. {{As of}}, {{Update after}}, {{convert}})
  • Adjusting links
  • Adding/adjusting hatnotes
  • Protecting/unprotecting pages (automatically marked minor). Thryduulf (talk) 21:53, 15 February 2021 (UTC)

• Very strong oppose. There is (probably) an issue that needs resolving behind this proposal, but there is no evidence presented for any of (a) the problem being widespread (i.e. that the solution lies with something other than educating and/or blocking individual users), (b) restricting minor edits will solve the underlying issue, (c) that restricting minor edits as much as is proposed is either necessary or proportionate, or (d) that the inevitable collateral damage will cause fewer and less significant problems than the original one. It is therefore way, way too premature to be bringing this to this board, let alone an RfC - it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth. Thryduulf (talk) 21:37, 15 February 2021 (UTC)

  it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth I've discussed this with other editors in multiple AN/ANIs last and this year, and this directly came from a VPT from this week. So that's not true. ProcrastinatingReader (talk) 22:26, 15 February 2021 (UTC)

  This is vague and lacking in so many ways I'm truly gobsmacked that multiple editors thought this was viable proposal. Thryduulf (talk) 23:02, 15 February 2021 (UTC)

• Oppose. Most experienced editors use minor a lot when performing wholly uncontroversial typo fixes, minor formatting changes, wikifying and the like. This feels like a baby–bathwater situation. Espresso Addict (talk) 00:36, 16 February 2021 (UTC)

  The thing is in order for some people to gain some benefit from ignoring edits flagged as minor, others must continue to monitor all edits. At present it's like some people just play with the baby without taking a turn dealing with the bathwater. Which is OK when there's enough people who don't filter out minor edits, but it means that minor edit filtering inherently fails to scale up, and that makes me uneasy about touting its benefits for all. isaacl (talk) 00:59, 16 February 2021 (UTC)

  I think we're talking about slightly different things here. I see it as a signal from experienced editor to experienced editor that says nothing to see here, which seems unambiguously useful. You, I think, are complaining that editors who filter out minor edits in watchlists (or, like me, don't bother with a watchlist at all) are placing a burden on others to check them. That seems more a problem in the way watchlists are configured, rather than with the principle of edits being marked as minor/not. Perhaps an edit filter could be devised to flag edits that are clearly not minor, and remove the designation? Espresso Addict (talk) 02:02, 16 February 2021 (UTC)

  The signal is unfortunately not a reliable one. It's an AI problem to automatically detect minor edits. If it works well enough, then there wouldn't be any need for manual flagging. That might be a good idea, but I'm not sure if it should be given priority over other developer tasks, particularly given the likely high effort-to-benefit ratio. (I appreciate the advantage of the signal, when accurate, and have written about it in the discussion section.) isaacl (talk) 03:13, 16 February 2021 (UTC)

  I wouldn't object strongly to restricting the ability to mark edits as minor to, say, extended confirmed editors; or more usefully, letting inexperienced editors continue to mark them (so that they learn to do it to community norms), but ignoring the mark (from inexperienced editors) in watchlist presentations. I don't think AI is going to differentiate them accurately enough any time soon. Espresso Addict (talk) 03:48, 16 February 2021 (UTC)

  It already has the ability to filter based on experience and minor edits (as well as a contribution quality prediction), but I don't think it can be set for all edits from inexperienced editors plus non-minor edits from experienced editors. The reliability issue remains, even with experienced editors, so someone ought to be checking all minor edits. isaacl (talk) 04:06, 16 February 2021 (UTC)

• Oppose, but open to reform. The minor edit designation is a piece of information, just like the edit summary, that has to be taken in context. When I see an "m" next to a reputable username, that saves me the effort of reviewing the edit. When it's next to a giant edit from an IP a redlinked user with a suspicious summary, that's different. For that reason, I don't filter them from my watchlist, but if someone else wants to do so, they can. That said, I agree misuse of the minor edit box is a problem. Here's a more modest proposal: limit it to autoconfirmed editors, and the first time someone checks it, have the software generate a popup that quickly explains what we mean by "minor". With that, we could take a harder stance on misuse of the box, since no one could claim they just didn't know. That might get us closer to a point where more editors feel comfortable filtering minor edits from their watchlist. {{u|Sdkb}} ^talk 07:19, 16 February 2021 (UTC)

  @Sdkb: unless I'm missing something, IP's can't tag edits as minor today (please point to any diff if you can see one). Unconfirmed users can - so the next "small step" up would be to remove that access from "All users" and give it to "autoconfirmed" users. — xaosflux ^Talk 14:30, 16 February 2021 (UTC)

  You're correct; I've fixed my hypothetical. {{u|Sdkb}} ^talk 18:34, 16 February 2021 (UTC)

  @Sdkb: those are both steps that I can support, along with perhaps a byte limit for the size of a change to still be marked minor. BD2412 T 17:57, 16 February 2021 (UTC)

  A byte limit might be tricky; reverting a vandal blanking a page is a very valid minor edit, as it's clearly uncontroversial. As an alternative, maybe disallow if ORES flags it as possibly unconstructive? {{u|Sdkb}} ^talk 18:38, 16 February 2021 (UTC)

  Something like that would definitely be useful, yes. BD2412 T 00:20, 17 February 2021 (UTC)

• Support The checkbox adds complexity to the process of making each edit, with very little benefit to other editors, and just a little anxiety at perhaps getting it wrong. On average, I guess I spend half a second to a second on this decision each time. Doing the math, that adds up to 2 to 4 working weeks of my life over the past decade. -- John of Reading (talk) 08:28, 16 February 2021 (UTC)

  @John of Reading: if it bothers you personally you can add this one line to your Special:MyPage/common.css and you won't have to see that box anymore:

  #mw-editpage-minoredit {display: none;}

  — xaosflux ^Talk 19:57, 16 February 2021 (UTC)

  @Xaosflux: The checkbox I use most is the one in AWB, not the one in the edit window. But if I hide the checkbox, or always leave it unchecked, and some other editors think the distinction is important, then I'll be failing to signal correctly to them that most of my edits are minor. -- John of Reading (talk) 20:09, 16 February 2021 (UTC)

• Strong oppose as unnecessary and counter-helpful. A large percentage of my own edits are minor, and I like the ability to keep the groups separated (if only for myself). No reason other people should have to pore through my edits when all I did was correct spelling or fix date formats or eliminate the spaces before <ref>, etc. — JohnFromPinckney (talk) 18:11, 16 February 2021 (UTC)
• Support limiting the "minor edit" checkmark to experienced users. It is very unreliable when used by newbies. - Vis M (talk) 21:04, 16 February 2021 (UTC)
• Oppose A supposed vandalism revert isn't necessarily minor. And the fact that the flag might not be accurate is just like everything else on Wikpiedia. Every single page, edit, summary or whatever might not be accurate. Per the disclaimer "WIKIPEDIA MAKES NO GUARANTEE OF VALIDITY". Andrew🐉(talk) 23:12, 16 February 2021 (UTC)
• Oppose per BD2412 and xaosflux. While I'm open to stopping non-autoconfirmed editors from marking edits as 'minor', I am in disagreement with the bulk of the proposal. Sdrqaz (talk) 20:42, 18 February 2021 (UTC)
• Limit to autoconfirmed Any potential damage from misusing the minor edit flag is minimal---on par with moving a page. It takes time to figure out what's minor and what's not, and we already restrict IPs. While we can certainly improve our guidance on using the minor edit flag, the threat level doesn't warrant restricting autoconfirmed editors who we already trust with much more powerful tools in their hands. — Wug·a·po·des​ 22:31, 18 February 2021 (UTC)
• Limit to autoconfirmed. We already prevent IPs from using the box, and new users can be assumed to be similarly inexperienced. However it is definitely useful for exconf+, and seeing as it's, well, a minor feature, autoconf should have access to it as well. Would be open to Sdkb's idea of having a popup the first time someone ticks the box, though I'm not sure as to the feasability of this on the software end. —pythoncoder (talk | contribs) 19:54, 19 February 2021 (UTC)
• Nein - minor edits are edits that well, are minor. If we mark them as major edits, then it will only waste more editors time in the RC patrol backlog. — Preceding unsigned comment added by Awesome Aasim (talk • contribs) 03:15, 21 February 2021 (UTC)
• Limit to autoconfirmed. For experienced users, especially when working with other editors, this is an important flag. Anyone who does not trust the minor edit flag can still look at all edits, so why could there possibly be a need to remove this functionality?ThoughtIdRetired (talk) 15:07, 21 February 2021 (UTC)
• I very strongly oppose the idea as proposed, but agree with Pythoncoder (this is the second RfC today I've agreed with him on) that limiting it to autoconfirmed is a good idea. JJP...MASTER!_{[talk to] JJP... master?} 01:55, 22 February 2021 (UTC)
• Support with comments: (1) Admins should be permitted to mark any of their edits, vandalism-related or not, as ‘minor’ if they they deem doing so beneficial to the community. For the rest of us (non-bot editors), rollback seems as good a threshold as any. (2) ‘Minor’ may cease to be the optimal name for the tag. ‘Procedural’ might be more apt? No idea if there’s anyway to change that for the sake of new editors. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄ 03:14, 23 February 2021 (UTC)
• Oppose Minor edits are important - the little changes to markup, spellings, white space, capitalisation, changes/updates to numbers, correcting typos: they are the little things that make the bigger machine work. By removing "minor edits" as a tag, you run the risk of flooding timelines with clutter, and potentially dissuade editors from making necessary minor changes in the first place. doktorb _words^deeds 07:25, 23 February 2021 (UTC)

Discussion (minor edits)[edit]

Although the minor edits flag isn't a reliable one to use for filtering all edits, it can be used (visually) to filter edits from editors you know. This advantage is, of course, only available to you if some of your known editors actually use the flag. isaacl (talk) 21:13, 15 February 2021 (UTC)

@ProcrastinatingReader, would your actual problem be solved by changing the default prefs settings to show minor edits? Whatamidoing (WMF) (talk) 21:55, 15 February 2021 (UTC)

The issue I have is that the functionality doesn't make sense. I don't think it ever makes sense to actually hide minor edits in a watchlist. The indicator itself may be helpful nevertheless, but is still redundant to the summary + byte count. I think Suffusion of Yellow and The Earwig's comments put my concerns succinctly. My second issue is individual admins thinking blocking even a single editor for their use of the minor indicator (eg or blocking individual users) is appropriate. I think the issue is frequent enough, per it having a section in a policy page (Wikipedia:Vandalism#Gaming_the_system). ProcrastinatingReader (talk) 22:22, 15 February 2021 (UTC)

If you could configure specific editors for which minor edits would be filtered out, it might be more useful. But given the low amount of usage, and the amount of overhead processing required for that level of filtering, I don't think it's worth the development and ongoing sustaining cost. isaacl (talk) 22:40, 15 February 2021 (UTC)

How do you know which editors to filter out? I think it'd be difficult to create an exhaustive list of editors who are incapable of using the feature. If it's a local list, it'd be very difficult for editors to maintain it (besides, if you have minor edits hidden, how do you know which editors are misusing the minor feature to add to the list since, well, you won't see their edits?) If it's a global list, I sense more pointless ANI drama. Plus, it may just be one-off edits that require more scrutiny rather than continuous inability to determine what is minor or isn't. ProcrastinatingReader (talk) 22:44, 15 February 2021 (UTC)

It would be up to individual users to decide whom they trusted to properly flag minor edits, and then configure their watchlist accordingly. But like I said, I don't think the work to implement this warrants the benefit. I didn't realize the current filtering capability allowed for level of experience to be configured; I'm not sure if that is useful or not for one's watchlist. isaacl (talk) 00:03, 16 February 2021 (UTC)

@ProcrastinatingReader, if the function doesn't make sense to you, then why do you propose that certain editors should continue to use it?

I think that whether it makes sense depends upon which version of the watchlist you're looking at. If you have each edit displayed separately, then it could let you skip a lot of edits that you don't want to see (e.g., ClueBot reverting simple vandalism, which is marked 'minor' but not as a 'bot' edit).

The minor edit flag is displayed in Special:RecentChanges as well. This allows interested editors to filter (for example) for minor edits by less-experienced editors that are the most current version of the page. I imagine that this would be an interesting list for both anti-vandalism patrollers and people seeking out promising editors. Whatamidoing (WMF) (talk) 23:05, 15 February 2021 (UTC)

The answer to the first paragraph is your second paragraph: so that ClueBot, and Hugglers, reverting simple vandalism can continue to be filtered out of watchlists. It's less restricting it to certain editors, and rather restricting it for a certain purpose. Even rollbackers and admins wouldn't be allowed to mark as minor "grammar changes", for example, under this proposal. ProcrastinatingReader (talk) 23:21, 15 February 2021 (UTC)

That's the problem with this proposal - vandalism fixing is only one of many valid reasons to mark an editor minor, including grammar changes (a I wrote a non-exhaustive list above). You seem to be assuming that everybody uses Wikipedia in the exact same way you do, which is flat out wrong. Thryduulf (talk) 12:28, 16 February 2021 (UTC)

As an example, this edit is very clearly a minor edit yet it has nothing to do with vandalism. Thryduulf (talk) 12:39, 16 February 2021 (UTC)

• Since this proposal is unlikely to get consensus as written, here's a completely different suggestion, more narrowly targeted at what I see is the most egregious problem: the fact that we occasionally block otherwise productive editors for misuse of the minor edit feature. Allow admins to disable the minor edit flag for an editor as part of the blocking interface, in the same vein as partial blocks or disabling email, but without restricting the ability to edit. — The Earwig ⟨talk⟩ 15:21, 16 February 2021 (UTC)
  • Two thoughts. The first, is it actually technically possible? If not, I think it’s unlikely to get through phab and even if it did we run the issue of having people reporting each other even more than now to ANI for “minor edit marking violations” for a “minor edit block”. The second, the feature would still be useless imo, but that’s just my idealism talking I suppose; if editors aren’t being site blocked for it then I don’t care as much. ProcrastinatingReader (talk) 16:40, 16 February 2021 (UTC)

    Not currently possible, would require developer time. That alone makes it a bit hopeless, I suppose. But I'm still interested in how we can solve this problem in a more targeted way. — The Earwig ⟨talk⟩ 16:52, 16 February 2021 (UTC)

    Indeed it isn't currently technically possible, but a lot of work has recently been done on partial blocks and marking edits as minor is something that is given to only a subset of users so it strikes me that it is something that going to be possible with a reasonable amount of work (I'm not a developer though). Thinking of ways to solve the actual problem in a focused way that doesn't cause massive collateral damage is absolutely the right thing to be doing though - indeed this is the sort of thing that should have been done before coming here with a proposal, let alone an RFC. Thryduulf (talk) 17:25, 16 February 2021 (UTC)

    @The Earwig and ProcrastinatingReader: I've created a phab task for this, see phab:T274911. Thryduulf (talk) 17:29, 16 February 2021 (UTC)

    Since minoredit is a separate user right, if it were to be assigned by bot instead of being a permission set for all users, then it could be removed from anyone who used it inappropriately. isaacl (talk) 19:36, 16 February 2021 (UTC)

    @Isaacl: I think you might be mixing up some terms here? It could be possible to make a group that includes the minoredit permission; and it would be possible to make it auto-assign-once on a threshold (like extendedconfirmed) such that it could be revoked - but that is a lot of overhead for such a small permission (and I don't think we'd get "bots" involved with this process at all). — xaosflux ^Talk 19:50, 16 February 2021 (UTC)

    It's not something I know a lot about, so almost certainly. I elided talking about groups for simplicity, and I didn't know (or forgot) about auto-assign-once; my apologies. Yes, it would be overhead, but less than enhancing the partial block capability to support blocking a user from flagging minor edits. isaacl (talk) 19:55, 16 February 2021 (UTC)

    It would also be possible, without any overhead in the common case or coding effort, to create a group that removes the ability to make a minor edit using $wgRevokePermissions. This way of doing it also avoids the issue of blocks being seen as a stain on people's record that was pointed out by Suffusion of Yellow below. That said, I am far from convinced that any of this is actually a good idea. * Pppery * it has begun... 23:38, 16 February 2021 (UTC)

    @Pppery: from a quick check we have exactly one project using that setting in all of WMF, and it looks like they haven't used it in over 10 years so I'm shocked it is still around (looks like may get merged in t pblocks - see phab:T227618). It does leave a "stain" on the user's rights log of course (e.g. w:ta:Special:Redirect/logid/58001. — xaosflux ^Talk 00:11, 17 February 2021 (UTC)

    As I recall when I was working with another Wiki implementation that had similar functionality, it can be useful in a corporate setting when defining user groups and managing their permissions. isaacl (talk) 00:20, 17 February 2021 (UTC)

  • This would be a fantastic source of drama. A block (even a partial block) isn't just the technical inability to do something, it's (for better or worse) going to be viewed by the user as a "stain" on their record. For something as trivial as this, that doesn't seem worth it. Suffusion of Yellow (talk) 20:00, 16 February 2021 (UTC)
• When you see a ±10k edit marked as minor, you know that the editor is almost certainly up to no good. Narky Blert (talk) 17:55, 16 February 2021 (UTC)
• Apparently more than seven thousand users have been warned for marking non-minor edits as minor. Has the opposite ever happened? I.E. "you're making typo fixes but not marking them as minor, please start using the flag or I'll drag you to AN/I". Suffusion of Yellow (talk) 19:52, 16 February 2021 (UTC)

  When training I always say that if you are in any doubt about whether and edit is minor assume it isn't as the worst that will happen is someone will give you friendly advice, but marking a major edit as minor could lead to people getting angry at you. Thryduulf (talk) 21:06, 16 February 2021 (UTC)

• I'm surprised that productive editors are being blocked for their use of minor edit marking. Are there more cases than the one mentioned by The Earwig above? That particular case seems highly unusual as the editor is apparently using an iOS app that does not receive notifications, and hence is not responding to feedback. Someone being blocked for vandalism marked as minor is clearly being blocked for vandalism. Espresso Addict (talk) 00:44, 17 February 2021 (UTC)

  Good question, Espresso Addict. I dug up some examples of editors being blocked for marking edits as minor. In most cases, there are other reasons for the blocks, of course: [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]. — The Earwig ⟨talk⟩ 07:37, 17 February 2021 (UTC)

Class date stamps[edit]

Several articles have on the talk page a label of quality in the form of Class levels. However, it is quite difficult to find out when the assessment was made and often the assessment may be several years old and not corresponding to the current level of the article. Would it be possible to add a time stamp on these assessments (in the same way as for the templates indicating need of editing in the article itself)? Ideally, this would be done retroactively with robots going through and adding time stamps to all those assessments already made. --Olle Terenius (UU) (talk) 11:17, 16 February 2021 (UTC)

Hmm, interesting thought! The benefit would have to be weighed against the potential for watchlist clutter. I think the first reform that needs to happen with quality assessments is getting them unified to one per article, rather than having one per project per article. {{u|Sdkb}} ^talk 03:14, 17 February 2021 (UTC)

Not that I have any clue or involvement in article-assessing projects whatsoever, but wouldn't such a unification be potentially difficult, esp. when there are more than just a couple projects involved? I mean, consider the (currently fictional) article Military music of Poland as a hypothetical case. The Polish project is happy with it and assesses it highly, but the Music project folks see that it's missing a bunch of the necessary music, um, stuff they require. The Military crew might have a third opinion of the quality of the article. And again, I have no idea how realistic this scenario is. — JohnFromPinckney (talk) 03:30, 17 February 2021 (UTC)

[Edit conflict] While I can see some people don't like cluttering talk pages with multiple assessments, it's common for different projects to have different standards and for one project's material to be well covered while another one's is lacking. How would we decide whose opinion prevails? Also, if the assessments were unified, what would happen to the importance assessments, which clearly differ between projects? Espresso Addict (talk) 03:38, 17 February 2021 (UTC)

I mostly agree with this, but some projects (like the military wikiproject) do their own assessment (eg A class ratings). That would have to be allowed to continue. But most projects are not really that active or well organised as MILHIST, and most ratings are not even done by WP members but just page patrollers etc. So something should improve about the system, probably. ProcrastinatingReader (talk) 05:26, 18 February 2021 (UTC)

Per-wikiproject assessment is dead, and should simply be deprecated. It is already formally overwritten for GAs and FAs, and I'm not sure it ever happens outside of MILHIST A-class. If MILHIST rates an article as A-class, that rating should apply to the quality of the article as a whole, and could receive a single timestamp much as GA and FA currently do. CMD (talk) 07:21, 23 February 2021 (UTC)

• This sounds like a good idea, and if it could be done by bots, it might not prove too difficult to do. Rollo August (talk) 09:18, 20 February 2021 (UTC)

Notification of an RFC[edit]

Users may be interested in the RFC at Wikipedia talk:Page mover/delete-redirect § RFC on granting delete-redirect to page movers. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Science Photo Competition 2021 Russia targeting CentralNotice banner[edit]

On Marth 1, the «Science Photo Competition 2021» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 11:43, 21 February 2021 (UTC)

CentralNotice proposal for International Women's Day[edit]

A proposal has been made to run a CentralNotice banner for both anonymous and logged-in users from March 1-10 for International Women's Day, highlighting gender gap issues. The proposal is at m:CentralNotice/Request/Int. Womens day 2021. --Yair rand (talk) 11:36, 22 February 2021 (UTC)

I'm only a man, but can somebody tell me when International Women's Day is? You know, a date? Neither of those two links tell me when this damned thing is supposed to be. I guess all the women already know it, but if we're all supposed to celebrate it, or it's supposed to mean something, why is it kept such a big secret? — JohnFromPinckney (talk) 02:09, 23 February 2021 (UTC)

International Women's Day is 8 March. --Malcolmxl5 (talk) 02:25, 23 February 2021 (UTC)

Maybe the reason all the women already know when it is, is because they tried clicking the links, or reading the first sentence of International Women's Day. ¯\_(ツ)_/¯ Levivich ^harass/_hound 02:29, 23 February 2021 (UTC)

If you don't fancy Google, then there is this nifty online encyclopaedia that has articles about things like this and much more. It's called Wikipedia, you might even have heard of it? Anyway, you can find their article at International Women's Day, and in the very first sentence it says International Women's Day (IWD) is celebrated on 8 March every year around the world. it's got a citation and everything! Thryduulf (talk) 02:32, 23 February 2021 (UTC)

Yes, friends, thanks for providing the actual date along with the snide remarks. I was 98.3% sure somebody was going say, "but it's right there in big <color> letters!", and I had just completely overlooked it. And yes, I could have googled, or looked directly for a WP article on International Women's Day, but I foolishly followed the provided link to International Women's Day, thinking (sort of on autopilot) that that must be it.

And while it's good and right that International Women's Day (the unlinked one) included the date, I still think two other pages which make a big deal out of "International Women's Day" would at least mention when it is. You know, for us ignorant people who might learn something. I know when Christmas Day and the Fourth of July and New Years Day are, but I haven't learned IWD yet. Or maybe I'll know it now. — JohnFromPinckney (talk) 04:20, 23 February 2021 (UTC)

Second link in the OP, top of the page: One global banner for International Womens day 2021, available for all gender gap activities around the 8th of March. Levivich ^harass/_hound 04:27, 23 February 2021 (UTC)

Ah, now I see it. Still took me a whole minute, even with your directions. Thanks. — JohnFromPinckney (talk) 04:36, 23 February 2021 (UTC)

You're welcome. As a man, I'm proud you even asked for directions. Levivich ^harass/_hound 05:52, 23 February 2021 (UTC)