Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

  • Поддержка в качестве номинатора. Для решения двух потенциальных проблем: (1) В тех редких случаях, когда на странице обсуждения обсуждается изменение варианта, предлагающий легко указать контекст. Я не могу придумать другой ситуации, в которой людям на странице обсуждения нужно было бы обратить внимание на вариант. (2) Для изменения уведомлений о редактировании в настоящее время требуются расширенные разрешения; Насколько я понимаю, это сделано по техническим причинам, а не из-за какого-либо редакционного консенсуса. Это проблема, которую в какой-то момент следует решать самостоятельно, но я не думаю, что это непреодолимое препятствие, поскольку большинство страниц, разработанных достаточно для того, чтобы помечать вариант уведомления, контролируются редакторами, которые могут его изменить, и в противном случае им будет предложено создать запрос на редактирование, что довольно просто.{{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)
  • Противодействие. Приведенные ниже аргументы убеждают меня, что это не лучшая идея. Я думаю, что лучше использовать "тихий" {{ Use American English }} и т. Д., А в худшем случае пусть гномы решают проблемы. - ГВП · · ро · дез 23:07, 16 марта 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)
  • Поддерживать. Это было бы более полезно в качестве примечания к редактированию - я знаю, что никогда не проверяю сначала, и мне больно открывать страницу обсуждения на новой вкладке (тем более, что у меня СДВГ, и иногда я забываю вариант, как только закрываю, сказал вкладка). В идеале похожие уведомления о стиле написания в данной статье также было бы здорово иметь в качестве уведомлений об изменении. Однако есть опасение, что, уменьшая беспорядок на страницах обсуждения, нам нужно не просто перемещать беспорядок (так сказать, убирая его под ковер). - Сюризури ( разговор ) 10:55, 12 января 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)
  • Поддерживаю, но не в масштабе, а только в качестве пилота. Насколько я понимаю, это может повлиять на миллионы статей, поэтому сначала попробуйте его в качестве пилотной версии для сотен статей. Такие большие изменения лучше всего делать с помощью тестовых примеров, времени, нескольких запросов на комментарии и документации. Это уже пользуется моей общей поддержкой, и я ожидаю, что в будущем снова поддержу, но это предложение как таковое не имеет ограничений. Для меня важен масштаб и темп изменений. Я ожидаю только документации добровольческого уровня, а не самой лучшей и полной, и я поощряю пилотную версию. Я осознаю существование проблемы и чувствую, что она будет только расти. Существуют различные возможные решения, и, возможно, нам придется использовать сразу несколько решений для решения этой проблемы. Пожалуйста, сначала разработайте это решение. Голубая малина(разговорное) 20:51, 12 января 2021 (UTC)
  • ПРОТИВОСТОЯТ editnotice баннеры гораздо больше раздражает , чем говорить странице уведомлений. Они замедляют редактирование. Грэм Бартлетт ( разговор ) 22:18, 12 января 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 : Ваше мнение о необходимости исправлять одно и то же слово снова и снова заставляет меня задуматься: что, если бы у нас был фильтр редактирования, чтобы, например, любой, кто пытается ввести «рассрочку» в статью, помеченную британским английским, получил бы большое предупреждение когда они пытаются опубликовать? {{u | Sdkb }} talk 01:58, 15 января 2021 г. (UTC)
    Я думаю, что для новых пользователей / IP неразумно не знать эту информацию перед редактированием. Да, они, скорее всего, не прочитают уведомление, но «есть уведомление, которое вы проигнорировали» намного лучше, чем «в нашем загадочном (для новых пользователей) пространстве имен WP спрятана политика, о которой вы даже не знаете». А учитывая, что разновидности английского языка во многом идентичны, иногда трудно сказать, в каком варианте написана статья; уведомление - хорошее напоминание. -Новов Т С 07:57, 15 января 2021 г. (UTC)
    Чтобы Sdkb , что это , возможно , что - то я мог бы поддержать, но я действительно не нравится редактировать фильтры , ориентированных на новичков , потому что это еще один барьер для входа. Если бы существовал способ сказать «буквально единственными изменениями в этой редакции являются неправильные орфографические изменения», то это было бы идеально. Я знаю, что прошу многого. По мнению Мира Новова , многие добросовестные правки, которые я вижу от новых пользователей / IP, которые я должен отменить, - это то, чего я не мог разумно ожидать, что они поймут. На странице обсуждения было обсуждение? Ведущий не упоминает об этом из- за веса? Этот источник ненадежен, даже если это газета, которую читают миллион человек в день? Неправильно называть раздел «Противоречие», даже если вы видели еще 1000 статей с таким плохим заголовком? Во всяком случае, мне кажется, что «в этой статье используется австралийский английский, потому что она об австралийском шоу» намного легче объяснить, чем большинство распространенных ошибок. - Билорв ( разговор ) 09:37, 15 января 2021 (UTC)
    Билорв , в моей идеализированной версии Википедии 2030 года, этот фильтр будет работать так, что кто-то войдет и попытается сделать плохой переход на другой вариант в рамках более тонкого редактирования, и когда они нажмут «Опубликовать», появится всплывающее уведомление с сообщением «Эй, вы переключили« рассрочку »на« рассрочку », что, похоже, идет вразрез с британским английским языком, используемым в этой статье. Хотели бы вы (а) публиковать, но сохранить британский английский? [Работает одним щелчком мыши] или (b ) публиковать все равно? "
    Но даже с этим я согласен с Нововым в том, что для страниц, где переключатели являются общими (это группа, которую мы обсуждаем здесь), лучше не заставлять кого-то выполнять всю работу, прежде чем давать им предупреждение. И дело не только в новичках - я не знал, что «рассрочка» было одним из слов, которые отличались друг от друга, пока вы не упомянули об этом выше, поэтому я легко мог представить себя совершающим эту ошибку. Принимая во внимание, что если есть 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).
  • Против . Разновидности английского языка недостаточно важны, чтобы их можно было разместить в качестве editnotice. Просто попробуйте заметить, какое разнообразие используется в статье, и подражайте этому; если вы ошиблись, кто-нибудь поможет вам исправить. На мой взгляд, баннер на странице обсуждения существует только для того, чтобы попытаться предотвратить войны редактирования из-за этого материала, при этом одна сторона может указать на баннер. В остальное время он бесполезен ни на странице обсуждения, ни в качестве заметки для редактирования. 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)
    • Уже есть уведомление о редактировании? Это ужасно. Удалим это. KevinL ( он же L235 · t · c ) 20:22, 18 января 2021 г. (UTC)
      • Да, см. Документ на {{ британском английском }}. Это делается с помощью параметра, но идея (я думаю) состоит в том, чтобы использовать оба. Чтобы прояснить, я хочу сказать, что мы не должны закрепить шаблон, который может не иметь смысла, но если нам не нужны уведомления о редактировании языка, мы должны удалить их полностью, а не произвольную систему в настоящее время.
        Лично я думаю, что нужно либо сократить его буквально до списка, а не большого уведомления, либо создать {{ стандарты статей }} для страниц обсуждения. Разумеется, каждый вариант преследует разные цели: первый предназначен для предупреждения редакторов, пишущих о необходимости адаптации их языка, а второй - для того, чтобы помочь редакторам «исправить» ошибки. Лично я не знаю других разновидностей английского языка, поэтому я делаю свои «ошибки» и позволяю кому-то другому копировать их исправления, если им это небезразлично, так что, возможно, последнее будет умнее. 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)
  • Поддержка : даже если люди проигнорируют уведомление, будет не хуже, чем сейчас. Это отличный способ помешать людям без надобности переключаться между английскими разновидностями. И, кроме того, поскольку все больше людей видят тот факт, что «вы можете помечать статьи по типам английского языка?», Будет больше людей, которые будут отмечать теги, что, в свою очередь, приведет к большей стандартизации и организации. Opal | zukor ( обсуждение ) 22:10, 29 января 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)
  • Категорически против: вместо этого удалите версии editnotice. Нам не нужно запугивать редакторов, особенно новичков, по поводу мелочей стиля каждый раз, когда они редактируют страницу . Если кто-то ошибается, какой-нибудь гном исправит это позже, как и все другие придирки стиля. MoS - это руководство, а не политика, и не без причины. Редактор не требуется, чтобы следовать ему при добавлении нового контента; они не разрешают прерывания и упорно менять материал , чтобы быть несоответствующими после того, как они попросили прекратить это делать. Пытаясь эффективно сделать следующее в MoS постатейного обязательной для редактирования страницы на всех является концом вокруг WP: РЕДАКТИРОВАНИЕ политика, является WP: BITEy , является WP: ПОЛЗУЧЕСТЬна самом высоком уровне, а также является результатом почти двух десятилетий консенсуса о том, что ни один стиль не имеет значения, за исключением некоторых ключевых моментов, касающихся повышения заголовка статей до уровня политики. Пока мы занимаемся этим, просто избавьтесь для этого от баннеров на странице обсуждения. "Безмолвных" шаблонов, как в верхней части статьи, вполне достаточно.  -  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, а убедившись , что editnotices должна быть еще ярче для пользователей , чтобы читать их. В идеале у нас было бы стандартизированное место в редакторе, отображающее английскую разновидность - а editnotices - хакерский - и плохой - способ в некоторой степени подражать этому. Elliot321 ( Обсуждение | вклад ) 01:45, 28 февраля 2021 (UTC)
    Elliot321 , стандартизованное место в редакторе - интересная мысль. Куда бы вы это вообразили? Есть ли какие-нибудь билеты на фабрики, которые смотрят, может ли WMF что-то добавить? {{u | Sdkb }} обсуждение 07:08, 3 марта 2021 г. (UTC)
    Sdkb, конечно, вот макет, который я сделал для редактора исходного кода (который я использую): File: English Variety mockup - source.png . Я не уверен, есть ли билеты на фабрику. Elliot321 ( Обсуждение | вклад ) 07:21, 3 марта 2021 (UTC)
    Elliot321 , мне кажется , это неплохо! Наведя курсор на слово «британский», возможно, появится всплывающая подсказка с примерами слов (в идеале, адаптированная к реальным словам, используемым на странице). Если вы пойдете дальше и превратите макет в более формальное предложение, я поддержу. Я прочитал об этом обсуждении, что определенно есть желание сделать языковой тег менее заметным, но просто разногласия по поводу того, как это сделать, поэтому я думаю, что ваше решение может иметь сильную поддержку, если оно будет реализовано. {{u | Sdkb }} talk 07:39, 3 марта 2021 г. (UTC)
    Sdkb да, это была бы моя идея.
    Теперь вопрос, как его установить? Хотя я полагаю, что шаблоны {{ Use blah English }} отлично справляются с этим, и это, вероятно, можно было бы обнаружить в редакторе. Elliot321 ( Обсуждение | вклад ) 07:43, 3 марта 2021 (UTC)
  • Поддержка Большинство пользователей не утруждают себя просмотром страницы обсуждения, если они не хотят публиковать там обсуждение. Новый пользователь может даже не знать, что есть страницы обсуждения! Это очень полезное предложение. 🐔  Chicdat   Bawk мне! 11:22, 5 марта 2021 г. (UTC)
  • Против . Я поддерживаю агрессивное сокращение беспорядка на страницах обсуждения, но это примечание к еще более заметному примечанию об редактировании не совсем точно отражает его важность (это проблема MoS, и я согласен с SMcCandlish, что мы не должны топтать по этому поводу редакторов, например, уведомление об изменении сделал бы). - Гозей ( разговор ) 16:37, 8 марта 2021 (UTC)
  • Я давно думал, что уведомление о вариантах должно размещаться на странице статьи, а не на странице обсуждения. Достаточно простой однострочной заметки типа «В этой статье используется британская орфография и грамматика» вверху страницы. Blueboar ( разговор ) 16:50, 8 марта 2021 (UTC)
  • Против согласно вышеизложенному.  Spy-cicle💥  Разговор ? 18:52, 10 марта 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)
    • Вы подчеркиваете, насколько большим будет это изменение, безусловно, действительно, хотя я не знаю, согласен ли я с тем, что переход к уведомлению об изменении делает еще более маловероятным, что люди прочитают уведомление об изменении - даже просто флаг Великобритания или США в уведомлении об изменении сделали бы больше, чем сейчас. Единственная альтернатива, которую я вижу в текущей ситуации или предложенном выше решении, - это полностью удалить английскую разновидность, что является более или менее невозможным сценарием. Aza24 ( разговор ) 00:10, 11 января 2021 (UTC)
    • Делаем форму editnotice меньше? ProcrastinatingReader ( разговор ) 09:25, 11 января 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)
  • Меня больше всего беспокоит то, что редактировать уведомления могут редактировать только переносчики страниц, редакторы шаблонов и администраторы. Я понимаю, что бот может сделать начальный ход, но как мы будем делать это в будущем? Я не возражаю, если следствием этого станет то, что такие уведомления станут более редкими, но в этом случае это должен быть осознанный выбор, а не просто оплошность. Я также не думаю, что это хорошее использование времени для значительного увеличения количества тривиальных WP: TPER с изменениями в уведомлениях engvar. - Trialpears ( разговор ) 21:46, 11 февраля 2021 г. (UTC)
    Trialpears , как я уже упоминал в своем голосовании!, Я вижу в этом основную проблему - есть множество ситуаций, в которых любой, кто подтвердил автоподтверждение, должен иметь возможность редактировать editnotice страницы, но не может (не из-за какого-либо редакционного консенсуса, но просто из-за какой-то внутренней технической структуры editnotices). Это проблема, которую мы должны решить (и если это пройдет, это может подтолкнуть нас к этому), но я не думаю, что мы должны ставить себе в затруднительное положение и отказываться от этого из-за этого. Это одновременно скрывает уровень потребности в решении проблемы и дает нам больше работы в будущем, когда она будет решена. {{u | Sdkb }} talk 00:12, 13 февраля 2021 г. (UTC)
    Я чувствую, что в целом это было бы хорошей идеей, но я все же вижу некоторые причины для защиты. Вандализм в уведомлениях о редактировании, скорее всего, не будет обнаружен большую часть времени, и даже если он будет обнаружен, большинство редакторов, вероятно, не будут знать, как его решить. Вложить в них дезинформацию могло быть намного хуже. Я бы определенно поддержал включение его для расширенных подтвержденных пользователей. Что касается реализации, ограничение регулируется MediaWiki: Titleblacklist, который может легко переключить его на требование автоподтверждения. Также должна быть возможность использовать вместо него фильтр редактирования, который мог бы вместо этого реализовать расширенное подтвержденное ограничение. - Trialpears ( разговор ) 21:26, 16 февраля 2021 г. (UTC)
    Sdkb Я не вижу проблемы с сохранением уведомлений о редактировании для людей, которые могут переопределить черный список - необходимость редактирования editnotices является довольно нишевой, и в большинстве случаев им следует использовать шаблоны, которых нет в черном списке и, следовательно, их можно редактировать.
    Пока запросы на редактирование выполняются быстро, это нормально. Может быть, больше людей должны подать заявку на переноску страниц? Elliot321 ( Обсуждение | вклад ) 07:29, 3 марта 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: ожидающие изменения-защищен только до тех пор, пока он находится на Главной странице; и эта идея кажется новой. IP-адреса и неподтвержденные редакторы смогут публиковать сообщения, даже если их вклады не отображаются сразу; и вандализм можно было незамедлительно направить туда, где он был. Годных сотрудников TFA можно было бы поощрять для помощи регулярным патрульным, ожидающим изменений. Это также решило бы проблему определения того, когда произошел вандализм и кто его совершил (вечная проблема с небольшим количеством случаев вандализма, с которыми я сталкиваюсь - в основном это ссылки на страницы DAB, - которые могут быть скрыты за несколькими недавними хорошими изменениями и требуют копирования и вставки. из последней хорошей версии). Это не должно быть технически сложно реализовать; он может быть частью сценария, который добавляет статьи и удаляет их с главной страницы. Некоторым другим редакторам эта идея нравится,и мне было предложено начать обсуждение здесь. (Для протокола - я за.)Нарки Блерт ( разговорное ) 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 Grant Memorial (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)
И еще две - РГ: ANI # Вандализм на SS Мауна Лоа (19 февраля 2021) и WP: ANI # Несколько IP добавляющие порно или оскорбительного изображение в предположительно статье TFA (20 февраля 2021). Во втором я насчитал (среди прочих реверсий) семь WP: REVDEL, пока статья была на главной странице. Нарки Блерт ( разговорное ) 00:53, 21 февраля 2021 (UTC)
Другой - WP: ANI # Вандализм в отношении Маргарет (певица) (23 февраля 2021 года; также упоминается Левивичем ниже), который иллюстрирует проблему. Администратор WP: SILVERLOCKed страницы в течение 3 дней (что ИМО слишком много и в продолжительности и уровне); более близкая мысль, не являющаяся администратором, должна была быть опубликована на WP: RFPP, а не ANI. Нарки Блерт ( разговорное ) 21:49, 24 февраля 2021 (UTC)
@ Narky Blert : Это я закрыл эту тему; в этом случае дубликат уже был на WP: RFPP , поэтому наличие ANI-потока казалось излишним. С уважением, Пользователь: TheDragonFire300 . ( Свяжитесь со мной | Взносы ). 04:57, 2 марта 2021 г. (UTC)
Широко распространено мнение о том, что ПК не будет работать / быть практичным на сильно редактируемых страницах. Поэтому, наверное, никто этого не предлагает. - Изно ( разговор ) 15:44, 2 февраля 2021 (UTC)
Это то, что было доказано во время попытки бэкдора на ПК , статьями Барака Обамы и Джорджа Буша . Объем правок был настолько велик, что очереди по этим статьям постоянно задерживались, и поэтому было и до сих пор принято, что ПК не подходит для страниц, на которых будут редактироваться большие объемы правок, что могло бы произойти с TFA из-за курс. - Голубой Бори v ^ _ ^ v Сильный мужчина отрицает ... 16:43, 2 февраля 2021 г. (UTC)
По крайней мере, TFAs, рассматриваемые в этом обсуждении. В последнее время я видел несколько довольно тихих TFA. - Изно ( разговор ) 17:17, 2 февраля 2021 (UTC)
К сожалению, я подозреваю, что набор TFA, которые были бы достаточно тихими для работы ПК, почти идентичен набору TFA, где ПК не нужен. Тридуульф ( разговор ) 01:30, 3 февраля 2021 (UTC)
Как сторонник этого предложения и активный PCR, я не думаю, что это было бы непреодолимым для большинства TFA. Я отмечаю, что два приведенных примера являются сильно политическими темами, один из которых был в то время президентом Соединенных Штатов, а другой - менее полного срока назад. Vaticidalprophet ( разговор ) 06:04, 3 февраля 2021 (UTC)
Я против превентивной защиты любого рода, особенно ожидающих изменений, которые заставляют добровольцев работать больше и редко бывают полезными. - WUG · а • ро · дез 1:53, 3 февраля 2021 (UTC)
  • Поддержите какую-то защиту . Недопустимо, чтобы редакторы (очень предсказуемо!) Вандализировали такие статьи, как «Холокост в Словакии», пока они находятся на главной странице. Это подрывает нашу репутацию намного больше, чем любая защита. ( t · c ) buidhe 04:16, 3 февраля 2021 (UTC)
  • Я должен отметить, что «высокая активность» - это довольно низкая граница - у PCR возникают реальные проблемы задолго до того, как, скажем, редакторы будут часто конфликтовать при редактировании. Я также не уверен, насколько точно мы можем сделать прогноз вероятной скорости редактирования TFA. Очевидно, мы можем предсказать сегменты «очень активные» и «вряд ли будут сильно редактироваться», но будет большая средняя категория, которую сложно заказать. Таким образом, я по-прежнему считаю, что ПЦР по-прежнему проблематична для любого использования TFA, которое действительно требует ПЦР. Nosebagbear ( разговор ) 07:35, 3 февраля 2021 (UTC)
  • Если честно, я не категорически против этого. Утилита ожидающих изменений отличается от полузащиты: цель не в том, чтобы уменьшить рабочую нагрузку для администраторов и патрульных, которые недавно изменили (как правильно указали другие выше, ожидающие изменения, по сути, наоборот), а скорее во предотвращении вандализма. от того, что его увидят читатели, и, таким образом, возможно, подорвет репутацию проекта. На самом деле, если мне не изменяет память, в течение короткого периода несколько лет назад мы действительно начали упреждающе устанавливать защиту ПК на TFA после 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 тысяч человек видел это вместо статьи. По моему опыту, это то, что вы описываете, с добавленными глазами, обеспечивающими более быстрое возвращение, но знание среднего и других статистических данных было бы полезно и, вполне возможно, изменило мое мнение. Если защита ПК действительно является существенным преимуществом, я был бы готов поддержать ее использование в TFA. Это, по крайней мере, позволяет редактировать пользователям без учетных записей, и если мы создадим приятное сообщение, как предлагает Нарки, это может минимизировать потенциальный укус новичка . Так что в данном случае меня больше всего беспокоит полезность, потому что я редко видел, чтобы ПК решал больше проблем, чем вызвал. - WUG · а • ро · дез 20:13, 3 февраля 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)
    • Я просто хотел бы подтвердить мою поддержку; когда пару дней назад мой « Портрет музыканта» попал в TFA, было много случаев вандализма, почти все из которых можно было предотвратить с помощью ПК; другие исправления и правки были сделаны пользователями, которые не были ограничены ПК. Тест, безусловно, того стоит. Aza24 ( разговорное ) 23:37, 1 марта 2021 (UTC)
  • (nom) Я согласен с тем, что любые изменения должны производиться на пробной основе.
Моя идея для текста шаблона выглядит примерно так: «Добро пожаловать в сегодняшнюю избранную статью. К сожалению, эти статьи привлекают вандалов. Поэтому изменения, внесенные новыми редакторами, проверяются опытными редакторами, прежде чем они появятся для всеобщего обозрения. Обычно это занимает всего несколько минут. Если вы здесь, чтобы стать частью сообщества, цель которого - улучшить Википедию - спасибо и удачного редактирования! Возможно, вы найдете справку: редактирование полезного руководства для начинающих. Если вы здесь только для того, чтобы disrupt - прочь с тобой! " Нарки Блерт ( разговорное ) 18:04, 5 февраля 2021 (UTC)
  • Поддержка предотвратит мгновенную публикацию токсичных материалов или материалов, защищенных авторским правом, в таких популярных статьях. ~ HAL 333 02:58, 6 февраля 2021 г. (UTC)
  • После уведомления, я еще не сказал об этом прямо здесь, поддерживаю как одну из сторон первоначального разговора. Vaticidalprophet ( разговор ) 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)
  • Поддержка Единственное отставание, которое может возникнуть с точки зрения ПК, - это одна страница, которую нужно будет регулярно проверять в течение всего срока (и, ну, ПК не такой большой по сравнению с некоторыми другими местами). И, что ж, хотя это может и не остановить все, по крайней мере, любое вандалистское редактирование (которое все равно нужно будет отменить, будь то ПК или нет) не будет заметно отображаться для каждого человека, который туда доберется ... RandomCanadian ( обсуждение / вклад ) 01:21, 12 февраля 2021 (UTC)
  • Поддержка в качестве рецензента ожидающих изменений, я думаю, что дополнительная рабочая нагрузка будет минимальной по сравнению с преимуществами. При большом количестве глаз на странице хорошие изменения будут приняты быстро, а плохие не будут иметь заметных ссылок с главной страницы. Elliot321 ( Обсуждение | вклад ) 05:57, 14 февраля 2021 (UTC)
  • Поддержка - это кажется мне разумным компромиссом, который позволяет IP-адресам редактировать TFA и бороться с вандализмом. Другими словами, это наименее ограничительный способ эффективной защиты наших самых известных статей. (Защита одной статьи в день, безусловно, не приведет к перегрузке ПК, и статья в любом случае будет широко отслеживаться.) Давайте по крайней мере попробуем эту схему: я думаю, это будет эффективно. Внеочередное письмо ( разговор ) 07:18, 14 февраля 2021 (UTC)
  • (nom) Чтобы повторить то, что я высказал ранее, на случай, если он может потеряться. В этой идее есть и пряник, и кнут. Это даст возможность быстро приветствовать новых редакторов и направить их в правильном направлении. Опытные редакторы знают, где искать или попросить о помощи; новички, по определению, этого не делают. Нарки Блерт ( разговор ) 07:50, 14 февраля 2021 (UTC)
  • Поддержка . Речь идет о балансе положительной репутации Википедии как энциклопедии «любой может редактировать», против потенциальной негативной репутации вандализма и неточностей, которые вносятся, но не обнаруживаются. Я думаю, что защита от отложенных изменений - отличный компромисс, позволяющий людям редактировать, но предотвращающий появление глупой чуши в нашей самой известной статье дня. ƒirefly ( t · c ) 14:02, 14 февраля 2021 года (UTC)
    • Переход на сильную оппонента после того, как узнал, что FlaggedRevs (то есть модуль, стоящий за ожидающими изменениями) фактически заброшен, и никто из команды разработчиков MediaWiki не несет за него ответственности, и что в нем есть различные странные ошибки ( phab: T275322 , phab: T275017 ), которые, по-видимому, не решаются. Меньше всего мы хотим, чтобы странные ошибки MediaWiki отображались в TFA. ƒirefly ( t · c ) 09:42, 2 марта 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)
  • Решительно поддерживаю попытку чего-либо после того, как сегодня TFA, Маргарет (певица) , постоянно подвергается вандализму, порождая еще одну ветку ANI . Я думаю, что работа по борьбе с вандализмом в TFA больше, чем работа, связанная с защитой статьи, а ущерб от вандализма в TFA больше, чем ущерб, связанный с тем, что никто не позволяет немедленно редактировать ее. Я не уверен, ПК это или полуавтомат, или что-то еще, но кое-что должно быть сделано ™. Я бы поддержал испытание этого или любого другого типа защиты. Или даже пробная версия ПК и полуавтомата, например A / B-тест . Я категорически против того, чтобы смириться с принципом «ну, вот оно что» и ничего не предпринимать. Решительно против того, чтобы ничего не пытаться . Левивич harass / hound 22:44, 23 февраля 2021 (UTC)
  • ПоддерживатьПоскольку это избранная статья, расчет рентабельности здесь сильно отличается от большинства других. Новички хулиганят многие статьи, но также делают хорошие правки, чтобы это исправить. Для избранных статей вероятность того, что новичок сделает хорошее конструктивное редактирование, значительно снижается (из-за низкого потенциала для улучшения статьи как избранной), в то время как тот факт, что он находится на первой странице, означает, что количество вандализма существенно увеличивается. Лично я поддерживаю защиту отложенных изменений во всех избранных статьях из-за уменьшения пользы, которую может принести новичок, редактирующий их. Качество многих избранных статей со временем значительно ухудшилось, поскольку для почти завершенной статьи гораздо более вероятно, что любое редактирование новичками будет бесполезным.Я думаю, что люди переоценивают то удовлетворение, которое люди получают от немедленных изменений; пока они осведомлены о ситуации с ожидающими изменениями, наиболее важным является то, что ваша работа вообще опубликована, а не точное время.Zoozaz1 talk 22:00, 24 февраля 2021 (UTC)
  • Поддержка Самые последние TFAs следуют схеме, аналогичной Oryzomys gorgasi , TFA 26 февраля. В тот день было 62 правки. Из них 27 (примерно 44%) были с IP-адресов. За одним исключением, которое я видел, все были вандализмом. Почти все «законные» правки были внесены авторитетными пользователями, и большая часть этих правок была связана с устранением ущерба, нанесенного вандалами. Принцип «кто угодно может редактировать» является, по крайней мере, с моей точки зрения, средством и должен подчиняться цели создания энциклопедии, опираясь на коллективные знания. Venicescapes ( разговор ) 08:07, 28 февраля 2021 (UTC)
  • Поддержка ; в целом отлично работает на dewiki на популярных страницах. Все статьи защищены ПК на dewiki, что приводит к долгому отставанию ( 7500 ожидающих изменений ), но это не кажется проблемой, когда защита ограничена 24 часами и выполняется выборочно на страницах, которые с большой вероятностью будут проверены. . ~ ToBeFree ( разговор ) 19:52, 1 марта 2021 (UTC)
  • Поддержка каждого предложения; да, любой должен иметь возможность редактировать, что и будет в этом предложении, но Википедия не должна снова стать жертвой того, что ее называют веб-сайтом с неточностями, которые каждый может добавить. waddie96 ★ ( разговор ) 20:44, 1 марта 2021 (UTC)
  • Поддержка. Кажется, я помню, как предлагал это несколько лет назад в одном из периодических разговоров о полузащите TFA. Это предотвратит демонстрацию вандализма в прямом эфире, но при этом позволит редактировать IP. Это может усложниться из-за большого количества правок, но в любом случае стоит попробовать. ~ ONUnicorn ( Обсуждение | Вклад ) решение проблем 20:57, 1 марта 2021 (UTC)
  • Я не очень люблю защиту и ненавижу ожидающие изменения. Но, возможно, пора отойти от TFA, как наш постер для «кто угодно может редактировать», и поискать другие способы привлечь новых редакторов (TFA действительно не лучшее место для редактирования тестов). Я бы предпочел полукомпьютер , но не буду возражать против этого предложения. - Кусма ( t · c ) 21:25, 1 марта 2021 г. (UTC)
  • Поддержка . Предпочитайте полукомпьютер. Меня прежде всего беспокоит читатель, а ЗАТЕМ редактор. Деннис Браун - 2 ¢ 22:26, ​​1 марта 2021 года (UTC)
  • Поддержите, потому что это лучше всего послужит читателям. TFA получает большой трафик, и читателям оказывается медвежья услуга, если они сталкиваются со статьей, когда виден вандализм. Schazjmd  (разговорное) 22:34, 1 марта 2021 (UTC)
  • Без поддержки. Я считаю, что компьютер плохой, сломанный и бесполезный. Я думаю, что полусредство лучше во всех случаях. Однако, поскольку мы годами отказывались от полузащиты для FA, я остановлюсь на ПК. Я считаю абсурдным то, что мы не хотим использовать полуфабрикаты на FA. Мы попали в ловушку правил. Написано, что защиту следует использовать только после того, как произошел сбой, поэтому мы ждем, пока не увидим сбой. Но теперь мы следуем букве закона, а не духу! Дух состоит в том, чтобы предотвратить срыв. Конечно, для большинства статей мы не можем знать, когда произойдет сбой. Но избранные статьи подвергаются вандализму, как по маслу. Внезапный показ страницы 10 миллионам дополнительных людей в день (включая наши ДСС!) Почти наверняка приведет к вандализму. Немного о WP: IARсэкономит много времени и нервов. TL; DR: полузащита будет лучше, но я остановлюсь на ПК. CaptainEek редактирует Ho Cap'n! ⚓ 22:55, 1 марта 2021 г. (UTC)
  • Комментируйте и возражайте . Возможность мгновенного редактирования лежит в основе этого проекта. И я думаю, что самый первый набег на Википедию многих редакторов связан с попытками основного редактирования. Это наш приветственный коврик. Мгновенное наблюдение за вашим изменением вживую вызывает острые ощущения и мгновенно подтверждает для новичков, что их подозрения относительно того, как все работает («любой может редактировать»), были обоснованными. Да, это включает в себя множество незрелых вандальных правок. Но такие глупые вещи, как ненормативная лексика, вставляются очень заметно. Но даже это помогает подсказать новые хорошие правки, чтобы попытаться исправить это. Другими словами, характер главной страницы «дикого запада» - важный способ привлечь новых пользователей, которые нам нужны. И даже некоторые из вандалов по мере взросления превращаются в хороших редакторов.Использование ПК делает ваши первые правки скучными, и люди, как правило, не задерживаются из-за скучных вещей.Джейсон Куинн ( разговорное ) 02:22, 2 марта 2021 (UTC)
  • Выступайте против использования ПК для TFA , но поддерживайте практически любую другую форму защиты (полуавтоматическая, расширенная подтвержденная и т. Д.). IMO, Pending Changes - это мерзость, которую не следует использовать вообще ни в какой статье и никогда. Это без необходимости увеличивает объем работы и делает редакторов ответственными за чужие правки. Это также чрезвычайно сбивает с толку и трудно понять как функцию, которая для перспективного использования TFA делает ее неприемлемой. TFA будут просматривать и редактировать многие неопытные редакторы. Мы не должны путать их, черт возьми, с таким чудовищем, как Pending Changes. Вместо этого просто полузащищайте TFA. Nsk92 ( разговорное ) 02:47, 2 марта 2021 (UTC)
  • Против. Похоже, что в этом направлении ветер сильно дует в одном направлении, но я считаю, что это кажется излишним решением в поисках проблемы - предложенная проблема, на мой взгляд, существенно минимальна по самой природе контекста. Если TFA несколько получат дополнительный трафик от IP-адресов и начинающих редакторов, они также получат повышенное внимание со стороны широкой части сообщества в течение тех же 24 часов, что и на главной странице. Кроме того, эти статьи, как правило, немного более надежны и отражают активное редактирование, чем средняя статья. Короче говоря, я не вижу, чтобы добавление ожидающих изменений существенно повлияло на защиту статьи от ошибочных, недобросовестных или других проблемных правок в течение дня ее статуса избранного. Тем временем,это кажется абсолютно определенным, что окажет влияние на то, что традиционно было одним из предполагаемых преимуществ Избранной статьи: на набор редактора.
Фактически, я бы сказал, что наличие этого процесса, с помощью которого новых редакторов загоняют в разные статьи каждый день (какая статья представляет достойные редакционные стандарты), и это пространство становится первым местом, где они могут оценить удовольствие от вклада в энциклопедию и получать удовольствие от непосредственного ощущения того, как эти изменения претворяются в жизнь, при одновременном сосредоточении надзора со стороны сообщества над этим пространством статей в естественной манере - все это звучит как именно тот баланс, который мы хотим установить, и почему это «не нарушено, не исправляйте» тип ситуации. Кроме того, TFA часто выигрывают от внимания, которое они получают от супер-краудсорсинга: подавляющее большинство даже правок IP полезны, а не вредны, так зачем же склеивать работы, имея очередь (потенциально перекрывающихся) ожидающих правок.И эти очереди не всегда решаются с готовностью: я сам являюсь рецензентом ожидающих изменений и за последние годы зарегистрировал изрядный объем работы в этой области, и я могу вам сказать, что очередь, к которой обращаются, довольно изменчива. что касается как тематики статьи, так и времени суток. Наконец, это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.
Короче говоря, что касается авторов и сторонников выше, анализ затрат и выгод, на мой взгляд, сильно противоречит предложению. S п о ж рэпе ДАВАЙТЕ 04:28, 2 марта 2021 (UTC)
В равной степени вероятно, что новый редактор, пытающийся отредактировать хорошо зарекомендовавшую себя статью (TFA), что-то испортит и получит уведомление или, что еще хуже, строгое страшное предупреждение на своей странице обсуждения. Это также игнорирует тот факт, что ПК по-прежнему позволяет новым редакторам редактировать статью, одновременно удаляя стимул для по крайней мере некоторого вандализма / ДСС. Бывший. (пришлось немного покопаться): TFA с мая прошлого года - исправленные правки являются хорошо известным вандалом LTA (так же, как и для большинства статей в Википедии: Сегодняшняя избранная статья / май 2020 г.... - Я знаю, это обсуждение не новая идея); после защиты ПК LTA остановился, хотя все еще разрешал другие правки, не связанные с AC (изрядно было обычным вандализмом, некоторые из них были добросовестными, но ошибочными; но в любом случае ПК не создает тех же проблем, что и полузащита). В то время как ПК может быть неэффективным для некоторых статей, а может быть, даже для большинства, на TFA это, вероятно, будет лучшим из обоих миров: не показывать вандализм нашим читателям, но при этом позволять новым редакторам вмешиваться. Ура, RandomCanadian ( обсуждение / вклад ) 05:06, 2 марта 2021 (UTC)
  • Поддержка . Использование ПК в TFA на самом деле не новая идея. Я и другие администраторы много раз применяли его заранее, чтобы защититься от длительного злоупотребления или в ответ на вандализм. Это были чрезвычайные ситуации, которые требовали выхода за рамки политики и отсутствия консенсуса, но каждый раз, насколько мне известно, мы не видели никаких проблем, на которые другие часто ссылаются при поиске использования ПК в TFA. В частности, у этой статьи достаточно внимания и активности, чтобы она не нанесла большого ущерба отставанию. Защищать одну из самых заметных статей от искажения, но при этом позволять новым пользователям вносить свой вклад, беспроигрышный и, откровенно говоря, давно назревший. - MusikAnimal talk, 02:09, 3 марта 2021 г. (UTC)

Ожидающие изменения ошибки [ править ]

(Перемещение обсуждения из архива.) К сожалению, сейчас существует масса ошибок, влияющих на ожидающие изменения: автоматически подтвержденные пользователи, чьи правки ошибочно задерживаются для проверки, администраторы не могут установить защиту от отложенных изменений и, очевидно, кодовая база ожидающих изменений полностью заброшен (нет активных разработчиков, разбирающихся в коде). См. Также обсуждение в Википедии: Village pump (Technical) #Pending Changes again . Я написал комментарий в обсуждении выше, выразив некоторую поддержку этой идеи, но если мы не можем гарантировать надежность программного обеспечения ожидающих изменений, я боюсь, что сейчас я не решусь поддержать его расширение. Mz7 ( разговорное ) 20:06, 12 марта 2021 (UTC)

Как один из наиболее активных PCR и один из первых разработчиков предложения, я с некоторым интересом слежу за дискуссией об ошибках на ПК. На самом деле я не наблюдал тонны этого в своей работе, поэтому мне интересно, насколько велика проблема - то есть какая доля людей, получивших ложноположительные результаты, куда-то жалуется. (Это касается не только вице-президентов, я несколько раз видел это в ПЕРМЬ.) Если большинство людей, получивших это, поднимают эту тему, она довольно мала; Если это лишь верхушка айсберга, это может стать серьезной проблемой.
Что касается предложения - то, что меня выделяет, это то, что большинство голосов противников говорят: «Мы не должны этого делать, мы должны вместо этого защищать полузащиту», а не «Мы не должны этого делать, TFA должна быть статус-кво ". Интересно, как будет выделяться распределение голосов по следующим двум предложениям:
«TFA находится либо под ожидающими изменениями, либо без защиты, только два варианта, полузащита полностью исключена и никогда не произойдет»
«TFA либо относится к полу, ПК, либо к нулевому; ранжируйте варианты по предпочтениям»
В любом случае это был бы интересный RFC. Ватицидальный пророк ( разговор ) 03:11, 13 марта 2021 (UTC)
Иногда я пользуюсь ПК (когда я не занят), и я не сталкиваюсь с ошибкой слишком часто (неулучшения и вандализм, увы, встречаются чаще), или когда я это делаю, это обычно не доставляет особых хлопот просто принять изменение - если у меня будет особенно много свободного времени, я оставлю уведомление об этом соответствующему редактору. Однако тот факт, что код не обслуживается и, по-видимому, в какой-то форме беспорядок, не является хорошим признаком, и, что ж, нам нужно взвесить, является ли риск развития дальнейших проблем меньшим раздражением, чем потенциально что-то делать с ДСС TFA. ... Ура, RandomCanadian ( обсуждение / вклад ) 05:42, 13 марта 2021 (UTC)
Обновление: мне известно, что теперь существует BRFA, предназначенная для решения этой проблемы. Если это пройдет, я думаю, что откажусь от своих колебаний. Mz7 ( разговорное ) 19:06, 15 марта 2021 (UTC)
Я считаю, что исправления с помощью бота в долгосрочной перспективе неприемлемы. Поскольку появляется все больше и больше ошибок, которые нельзя исправить в расширении, мы не можем продолжать использовать ботов и другие хаки, чтобы обойти их локально. Я лично хотел бы, чтобы FlaggedRevs попал в обзор управления кодом, прежде чем расширять его использование. ProcrastinatingReader ( разговор ) 23:26, 15 марта 2021 (UTC)
  • Почему бы нам не удалить рецензента ожидающих изменений? а выдать права на расширенные-подтвержденные? Я имею в виду, что цель ПК - это базовый флаг, чтобы остановить вандализм / очевидный DE, верно? Это похоже на менее экстремальную полузащиту. Так что, я думаю, нет смысла помещать это в отдельное право. Право должно быть объединено с расширенным подтверждением, а отдельное право должно быть удалено, я думаю (+ EC - разумный уровень «доверия» против чистого бессмысленного вандализма + они уже могут редактировать такие области, как Израиль-Палестина). Это также исправит эту конкретную ошибку. ProcrastinatingReader ( talk ) 17:17, 16 марта 2021 (UTC)

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

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

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

  • Да . У нас не должно быть ничего из этих мелочей в коробках для наследования. Коробок часто бывает много, даже десятки, и дополнительный беспорядок не помогает. Было бы очень трудно найти надежные источники, обсуждающие, как Джеймс Каллаган «сменил» Алекса Дугласа-Хьюма на посту старейшего британского премьер-министра, и я осмелюсь сказать, что ни в одной биографии ни одного из них это не упоминается. Сурцична ( разговорное ) 22:15, 4 февраля 2021 (UTC)
  • Да . Только сообщения с переходами (или последовательностями) будут нуждаться в блоках последовательности. - Каутиля3 ( разговор ) 22:56, 4 февраля 2021 (UTC)
  • Не здесь . Мелочи нужно удалить, мелочи быть не должно. Вопрос о том, является ли какая-либо конкретная преемственность мелочью, необходимо обсуждать индивидуально на соответствующем форуме - этого форума здесь почти нет. Тридуульф ( разговор ) 02:21, 5 февраля 2021 (UTC)
  • Нет. Как говорит Тридюульф, тривиальные должны быть, нетривиальные - нет. Это нужно делать в индивидуальном порядке. - DJSasso ( разговор ) 18:03, 5 февраля 2021 г. (UTC)
  • Да, я считаю, что поля наследования вообще не нужны, поскольку они обычно дублируют информационное окно, навигационное окно и / или текст. Когда это не дублирует, как этот пример, это часто тривиально, что не требует коробки для себя. Обсуждение Reywas92 19:36, 5 февраля 2021 (UTC)
    • Вы их не любите , а я считаю, что четкое и последовательное изложение чрезвычайно полезно. Блоки преемственности, информационные блоки, навигационные блоки и проза - все они выполняют разные функции, поэтому одна и та же ссылка, появляющаяся более чем в одном месте, является хорошей вещью. Некоторые поля наследования следует удалить, но большинство - нет. Что происходит для любого данного блока наследования, может быть определено только путем согласованного обсуждения данного блока преемственности. Тридуульф ( разговор ) 01:04, 6 февраля 2021 (UTC)
  • Да, и поддержу избавление от них всех. Избыточный и бессмысленный беспорядок. Почему бы не разбросать отдельные коробки для браков, супругов и работ по статье, пока мы ее читаем? ~ HAL 333 02:50, 6 февраля 2021 г. (UTC)
    • Для чего они избыточны? Ссылки в прозе и ссылки в последовательностях имеют разные цели, поэтому они не дублируют друг друга. Ящики (для чего угодно), разбросанные по прозе, будут полностью разрушать прозу, поэтому ячейки последовательности не помещаются в середине прозы? Тридуульф ( разговор ) 11:58, 6 февраля 2021 (UTC)
  • Да - не уверен, что они нам даже нужны для позиций, но определенно не для превосходной степени. Levivich  харасс / гончая 17:22, 6 февраля 2021 (UTC)
    • Все в превосходной степени? А как насчет самых высоких зданий и самых длинных мостов? Мне эти коробки кажутся чрезвычайно полезными. Тридуульф ( разговор ) 18:24, 6 февраля 2021 (UTC)
  • Комментарий : я считаю, что обоснованность или тривиальность блоков наследования следует обсуждать в каждом конкретном случае на соответствующей странице обсуждения. Не уверен, чего можно добиться тем или иным глобальным решением по «тривиальным» блокам преемственности, когда оно ничего не делает для определения того, что тривиально, а что нет. PraiseVivec ( обсуждение ) 14:01, 7 февраля 2021 (UTC)
  • Да для чисто пустякового поля наследования, такого как «самый старый из ныне живущих X» - если только указанная роль не является заметной сама по себе (не уверен, что это действительно применимо где-либо). Elliot321 ( Обсуждение | вклад ) 05:54, 14 февраля 2021 (UTC)
  • Да, некоторые из них следует удалить. Как минимум, дух WP: NAVBOX # 4 кажется применимым: в Википедии должна быть статья о поле наследования. - Багумба ( доклад ) 10:11, 22 февраля 2021 г. (UTC)
  • Зависит - Да, для «преемственности» «самого пожилого британского премьер-министра» в качестве пустяка, но без обсуждения других это будет зависеть от конкретного случая, это не должно использоваться в качестве консенсуса для удаления не цитируемых примеров. KylieTastic ( обсуждение ) 10:15, 23 февраля 2021 (UTC)
  • Да Ящики преемственности не нужны, в большинстве случаев это дубликат. Sea Ane ( разговор ) 21:43, 26 февраля 2021 (UTC)
  • Противодействуйте принятию решения об этом конкретном здесь, поддержите общее переосмысление последовательности / навигационных ящиков и того, для чего они подходят (если что-то еще). Большинство окон наследования в John Major менее тривиальны, но их так много, что они бесполезны для навигации и по умолчанию скрыты (как и безбожное количество навигационных ящиков). Если в статье более трех блоков последовательности, они, как правило, перестают быть полезными. - Кусма ( t · c ) 21:50, 1 марта 2021 г. (UTC)
  • Да - многие коробки наследования кажутся чистыми пустяками. Если статьи по теме нет, она не должна существовать как преемственность. Носфераттус ( разговор ) 04:05, 9 марта 2021 (UTC)
  • ? Oppose Confused, как этот RFC может что-то решать? RFC расплывчат, а ответы столь же неоднозначны; каждый, кто говорит «да», поддерживает что-то другое. Кто решает, какие из них тривиальны? Aza24 ( разговорное ) 23:34, 15 марта 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 в связанных проектах WikiProjects? тогда непременно сделайте это. GoodDay ( разговор ) 02:18, 6 февраля 2021 (UTC)
    Если это обсуждение на самом деле касалось конкретных блоков наследования, которые были бы уместны, но поскольку обсуждение на самом деле представляет собой пустую и несфокусированную попытку избавиться от неопределенного списка блоков наследования, которые вам (или, предположительно, любому другому редактору) лично не нравятся, тогда невозможно знать, какие проекты и статьи актуальны. С другой стороны, если вы сделали соизволили перечислить эти коробки вы сочтете мелочи, то это бы я подозреваю , быстро стать Trainwreck из - за большое количество разрозненных ящиков редакторов будет иметь разные мнения о том . Тридуульф ( разговор ) 11:55, 6 февраля 2021 (UTC)
    Поскольку мои опасения выросли из обсуждения в Джеймсе Каллагане , можно было бы сослаться на Политические WikiProjects. GoodDay ( разговор ) 18:41, 6 февраля 2021 (UTC)
Все должны быть удалены, поскольку ссылки являются спамом из-за дублирования ссылок и чрезмерного размера. Никогда не понимал, почему у нас есть гигантские коробки с очень небольшим количеством ссылок в них, подавляющими разделы. Редактор контента определенно не согласен с тем, что эти недопустимые блоки автоматически рассылаются спамом без учета чрезмерных или необоснованных ссылок. - Moxy 🍁 00:04, 6 февраля 2021 г. (UTC)
Очень просто, потому что многие (не все) поля наследования очень полезны для читателей. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC)
Не уверен, насколько удобно для читателей дублирование lnks и overwhelm разделов. У нас есть протоколы для этих двух пунктов ... которые просто игнорируются спамерами по шаблонам. - Предыдущий неподписанный комментарий, добавленный Moxy ( обсуждение • вклад ) 01:19, 6 февраля 2021 г. (UTC)
См. Мой ответ в разделе выше, чтобы узнать, почему дублирование не является проблемой, и я не согласен с тем, что презентация подавляющая. То, что некоторые поля наследования являются пустяками, не означает, что все поля наследования являются спамом. Тридуульф ( разговор ) 01:41, 6 февраля 2021 (UTC)
Нам просто придется не соглашаться. Только практика размещения указывает на очень низкую ценность для сообщества. См. Также ссылки, размещенные в нижней части статей, потому что они дублируют существующие ссылки, и формат не отвечает нигде в других статьях. Ужасно, что эти поля более заметны, чем фактические тематические навигационные поля. Странно, что они не были исключены из мобильной версии как нежелательная нагрузка - Moxy, 02:01, 6 февраля 2021 г. (UTC).
Как размещение указывает на низкую стоимость? Конечно, этот формат не подходит для других частей статьи - см. Также ссылки и ссылки в полях последовательности имеют совершенно другое предназначение, чем ссылки в прозе. Вам нужно объяснить, почему дублирование проблематично. Тридуульф ( разговор ) 11:55, 6 февраля 2021 (UTC)
Вот почему у нас есть руководство по этому поводу ... отвлекает читателей от действительно важных ссылок . Википедия: кризис оверлинков . Они настолько огромны, что редакторы прячут их в сворачиваемых шаблонах Авраам Линкольн # Внешние ссылки . Во многих других случаях их просто огромное количество ... массовый ссылочный спам Джон А. Макдональд # Внешние ссылки. - Moxy, 17:59, 6 февраля 2021 г. (UTC)
Вы объяснили, почему считаете, что слишком много ящиков является проблемой, и повторили свое мнение о том, что некоторые ящики имеют низкую ценность (с чем в основном никто не согласен). Однако вы не объяснили, почему наличие каких-либо ящиков проблематично или почему их позиция в статье указывает на это. Тридуульф ( разговорное ) 20:24, 7 марта 2021 (UTC)

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

Должны ли мы использовать собственный DISPLAYTITLE? У нас есть десятки наименований, в которых пользовательский DISPLAYTITLE был бы полезен, например, thatPower и C Sharp (язык программирования) . Использование персонализированного DISPLAYTITLE позволит нам обойти эти ограничения и позволить нам использовать любой DISPLAYTITLE и отказаться от шаблона {{правильное название}} Aasim ( обсуждение ) 20:22, 9 февраля 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 00:10, 10 февраля 2021 г. (UTC)
  • Я никогда не знал, что C # не в правильном названии. Это странно. Если это предложение будет одобрено, будет ли это технически возможно в настоящее время с изменением конфигурации или чем-то еще, или нужно будет написать код? Во всяком случае, мне кажется, что в идеале # следует поддерживать как символ в обычных заголовках, а не использовать взлом отображения заголовка. ProcrastinatingReader ( разговор ) 00:16, 10 февраля 2021 (UTC)
    @ ProcrastinatingReader : Что ж, чтобы включить # в качестве законного заголовка страницы без взлома DISPLAYTITLE, вам все равно придется рассматривать его как особый случай, потому что # имеет особое значение в URL-адресах. davidwr / ( talk ) / ( вклад ) 00:27, 10 февраля 2021 (UTC)
    Ага. Если в заголовках поддерживался символ # , следует ли Foo # Bar перенаправить вас к статье «Foo # Bar» или к разделу «Bar» в статье «Foo»? - SD0001 ( разговор ) 14:04, 10 февраля 2021 г. (UTC)
    Как статьи справляются с этим? например, ХК Земгале / LUA ? Или / (т.е. подстраницы) недопустимы в пространстве статьи? ProcrastinatingReader ( разговор ) 18:48, 12 февраля 2021 (UTC)
    Подстраница отключена в основном пространстве (см. Пример Fate / stay night ). - Изно ( разговор ) 19:02, 12 февраля 2021 (UTC)
    Это технически возможно в виде изменения конфигурации (установка для $ wgRestrictDisplayTitle значения false) * Pppery * началось ... 00:37, 10 февраля 2021 г. (UTC)
  • Не произвольные изменения карт-блан , но я готов разрешить это в каждом конкретном случае после обсуждения, аналогичного дискуссии, связанной с дискуссией о перемещении страницы. Я также открыт для разрешения совершенно новых классов «DISPLAYTITLE», например, «allow #», опять же, после RfC для аналогичного обсуждения для каждого предлагаемого исключения. Это может быть реализовано путем разрешения DISPLAYTITLE при отображении 1-1 заголовков страниц на аргументы DISPLAYTITLE в «файле белого списка», поддерживаемом администраторами. Конечно, речь идет об изменении кода, и время разработчика не безгранично. Я не считаю это приоритетом, но если есть время для разработчиков и тестировщиков, я бы предпочел это.davidwr / ( обсуждение ) / ( вклад ) 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)
    Да, это wikt: MediaWiki: UnsupportedTitles.js , в котором есть центральный список заголовков. Проблема в том, что попытка установить ссылку напрямую на отображаемые заголовки не сработает. - Яир Рэнд ( разговор ) 11:54, 2 марта 2021 г. (UTC)
  • Поддержите, так как есть много названий, которые должны заключаться в квадратные скобки [], но не могут. # тоже проблема. Но, возможно, это можно сделать с помощью механизма DISPLAYTITLE, который позволяет проверять злоупотребления. Фильтр редактирования может проверять наличие ошибок, если установлен стандарт для сопоставления имени. Обратите внимание, что есть и другие символы Юникода, которые внешне похожи на запрещенные. Грэм Бартлетт ( разговор ) 22:47, 24 февраля 2021 (UTC)
  • Нет, по всем вопросам, поднятым Izno Sea Ane ( обсуждение ) 21:46, 26 февраля 2021 года (UTC).
  • Выступайте против, если только фактический заголовок страницы не отображается на видном месте. - Кусма ( t · c ) 11:39, 2 марта 2021 г. (UTC)
  • Нет - согласно Xaosflux и Izno. Много потенциальных головных болей с очень и очень небольшой выгодой. ƒirefly ( t · c ) 13:33, 2 марта 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)
  • Вариант 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)
    Обновление Добавить уточнение: я все еще очень надеюсь, что боту будет разрешено возобновить работу, но при этом условии: только если Monkbot 18 откажется от удаления полностью пустых строк в шаблонах цитирования . Обоснование этого можно найти в моем разговоре с Floydian в разделе обсуждения (это довольно простое изменение для бота). Пока я здесь, я добавлю вторую оговорку, также вытекающую из обсуждения: список статей, по которым запускается бот, должен быть отфильтрован, чтобы удалить статьи, которые уже были посещены ботом. Это сделано для того, чтобы уменьшить предполагаемую проблему «бот-спама», против которой возражают некоторые редакторы (кто сказал, что я не прислушиваюсь к возражениям?). - NSH001 ( разговор ) 06:52, 12 марта 2021 (UTC)
  • Вариант C . Это совершенно бессмысленное занятие. На мой взгляд, текст без переносов лучше, так как они не переносятся в окно редактирования и могут быть подчеркнуты как опечатка, поэтому они хорошо видны в окне редактирования. Кейт Д. ( разговор ) 13:01, 11 февраля 2021 (UTC)
  • C (первый выбор) или B (второй выбор). Я читал множество дискуссий по этой проблеме и никогда не видел ничего, что убедило бы меня в том, что отказ от поддержки действительно приносит пользу энциклопедии. Даже если мы предположим в пользу того же аргумента, что это так или иначе, реальное и очевидное нарушение, вызванное ботом до сих пор, и степень изменений, которые отмечает оператор бота, потребуются для выполнения задачи, очень ясно и очень значительно перевешивают то, что выгода. Тридуульф ( разговор ) 15:20, 11 февраля 2021 (UTC)
  • Вариант А: это изменение немного болезненно, но в долгосрочной перспективе его лучше редактировать. Лучше внести это изменение, чем не делать этого. Лучшее время было пятнадцать лет назад, но сейчас второе лучшее время. Разрешите боту продолжить свою работу, избавьтесь от всех параметров и, как только все они будут удалены, начните генерировать ошибки цитирования. Elliot321 ( Обсуждение | вклад ) 17:09, 11 февраля 2021 (UTC)
  • Вариант А . К сожалению, визуальный редактор существует ... но бесполезен для больших проектов редактирования, и поэтому многие люди все еще используют редактирование викитекста - сжатие в одну форму (в частности, форму с переносом, поскольку редакторам ее легче читать) поможет обеспечить согласованность между статьи хотя бы в шаблонах CS1. Очевидно, что это не упростит редактирование каждой статьи, поскольку есть статьи с цитированием, отличным от стиля CS1, но это поможет миллионам, которые действительно используют CS1, выглядеть для редакторов одинаково, вместо того, чтобы иметь мешанину из написанных через дефис имен. Я также согласен с тем, что бот продолжит работу сейчас, а затем будет запускаться, может быть, один раз в неделю или около того после этого первоначального запуска, чтобы исправить любые имена параметров CS1 без дефиса. -bɜ: ʳkənhɪmez ( Пользователь / передай привет!) 17:13, 11 февраля 2021 (UTC)
  • Вариант C. Суть шаблонов и ботов в том, что они должны работать, чтобы облегчить жизнь редакторам, а не в том, что редакторы должны менять свой подход к работе, чтобы облегчить жизнь создателям шаблонов и ботов. У этого бота это полностью перевернуто, и если группа одобрения ботов одобрила это, то это проблема этой группы, а не нескольких недифференцированных параметров. Я не могу избавиться от ощущения, что эта группа следит за интересами нескольких операторов-ботов, а не гораздо большего числа редакторов и еще большего числа читателей. Нет большой сложности в наличии нескольких синонимов для параметров шаблона, и нет никаких проблем с экспортом данных - если синонимические параметры указывают на одно и то же место в коде, то их можно без дополнительных усилий экспортировать в том же формате. Я могу'Я не верю, что через сорок лет после того, как я пришел в ИТ, мы все еще ожидаем, что пользователи будут рабами систем, которые призваны им помогать.Фил Бриджер ( разговор ) 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)
    Нет, моя позиция не является преувеличением или популизмом. Причина, по которой я отвергаю вариант Б, - это слово «немедленно». Это все еще оставляет текущий консенсус о том, что версии параметров без дефисов будут удалены, но не сразу, и это консенсус, который должен измениться, сколько бы лет он ни оставался стабильным. Я доволен упрощением документации, но не удалением этой опции. Фил Бриджер ( разговор ) 09:19, 12 февраля 2021 (UTC)
    Как отмечалось выше: устаревание не является синонимом отключения. Вы сбиваете с толку замену параметров, как написано в шаблоне, включенном на страницу, с удалением возможности варианта параметра runtogether работать в шаблоне. Только вариант А подойдет для последнего. У нас есть много-много шаблонов, которые поддерживают параметры варианта написания, но не «рекламируют» их в документации, и ничего не ломает, чтобы бот заменил их канонической версией, точно так же, как тот же бот заменяет вызовы на имя перенаправления. для шаблона с фактическим именем страницы шаблона. То есть, вы испытываете сильную негативную реакцию на аргумент , что вариант В самом деле не делают .  -  SMcCandlish ☏ ¢  😼  17:50, 13 февраля 2021 (UTC)
    Вариант Б очень четко говорит: «но не следует сразу удалять». Либо слово «немедленно» имеет какое-то значение, и этот вариант приведет к удалению, но не сразу, либо оно не имеет значения и не имеет никакого отношения к этому. Фил Бриджер ( выступление ) 18:10, 13 февраля 2021 (UTC)
    SMcCandlish , это объяснялось в предыдущем обсуждении на CS1.: "" Устаревание "по определению, используемому в контексте CS1 / CS2, означает, что если параметр используется, будет показано красное сообщение обслуживания, и оно появится в категории отслеживания. Это этап перед прекращением поддержки для параметра (в этом случае будет показано только сообщение "неподдерживаемый параметр" и, возможно, подсказка о новом параметре). Можно оставаться в этом состоянии в течение длительного периода времени, но идея заключается в том, что в конечном итоге функциональность будет идти". Таким образом, цель состоит в том, чтобы ошибиться, а затем удалить функциональность этих параметров, а не просто не рекламировать их в документации. Если вы хотите предложить вариант варианта C, который удаляет параметры из документации, но по-прежнему позволяет им функционировать, продолжайте, но вариант B не такой.Никкимария ( разговор) 20:09, 13 февраля 2021 г. (UTC)
    Что я хочу предложить вариант вариант В , который удаляет параметры из документации , прежде чем дать некоторые боту идти вокруг изменения статей по лотам , как если параметры как - то плохи. Если параметры действительно плохие, и если есть консенсус по этому поводу , то Шаг первый - удалить их из документации (либо перетаскивая их в темноте ночи, тихо, как ниндзя, либо прозрачно упоминая их как устарел, поэтому все знают, что происходит). Первая фаза настоящего осуждения - сказать людям прекратить что-то использовать. Тогда вы можете начать подбрасывать красные сообщения, и это будет не так чертовски грубо или удивительно. -  Джон Фром Пинкни (разговор ) 21:40, 13 февраля 2021 (UTC)
    Конечно, я бы тоже поддержал этот вариант. Или вариант, в котором упоминаются эти версии параметров, но они не рекомендуются. Что бы ни приближало нас к единообразию фактических развернутых шаблонов, используемых в цитировании.  -  SMcCandlish ☏ ¢  😼  04:15, 14 февраля 2021 г. (UTC)
    Этот материал должен быть в категории отслеживания, если это то, с чем будут работать боты и другие инструменты. Если нам не нравятся сообщения об ошибках, мы можем их отключить. Это всего лишь код шаблона и модуля, он не выгравирован на склоне горы, такой как Mt. Рашмор.  -  SMcCandlish ☏ ¢  😼  04:15, 14 февраля 2021 г. (UTC)
  • Вариант C Я полностью согласен с Филом Бриджером. Другими словами, я не могу понять, чего именно можно добиться, сделав миллионы косметических правок и затем намеренно нарушив то, что в противном случае сработало бы. * Ппперы * началось ... 20:21, 11 февраля 2021 (UTC)
    Вариант Б ничего не ломает. Вы, и др., Обеспечивают аргумент против варианта А, а не фактический аргумент для C, и просто игнорируя B. Кроме того ,! Проголосуй за С является! Проголосуй за переворачивания статус - кво , который был стабильным в течение многих лет , в в пользу хаоса, но без реальных оснований для этого. Более близкий должен принять это во внимание, согласно WP: NOTAVOTE . В случае результата «отсутствие консенсуса» мы все равно остаемся с статус-кво. Вот почему я постоянно говорю людям, что им нужно лучше писать RFC. «Все, что можно неправильно истолковать, будет».  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC)
    SMcCandlish , опция B поддерживает отключение параметров без дефиса - это критическое изменение. Разница между A и B - это скорость, а не результат. Ваш! Голос ниже предполагает, что вы хотите, чтобы варианты без дефиса продолжали поддерживаться, но из представленных вариантов только вариант C выполняет это. Никкимария ( разговорное ) 16:18, 13 февраля 2021 (UTC)
    Неа. См. Мой ответ на то же заявление Фила Бриджера выше.  -  SMcCandlish ☏ ¢  😼  17:50, 13 февраля 2021 г. (UTC)
    Ага - см. Выше. Вы также можете посмотреть, что произошло с ранее устаревшими параметрами CS1, такими как |authorfirst=- они не работают. Никкимария ( разговорное ) 20:09, 13 февраля 2021 (UTC)
    Что совершенно нормально, если у людей будет достаточно времени, чтобы они перестали их использовать. Таким образом удалите их из документации по шаблону и замените их в развернутых трансляциях шаблонов. В конце концов, эффект «обезьяна видит, обезьяна делает», связанный с устаревшими вариантами параметров, уходит за счет уменьшения и, в конечном итоге, нулевого воздействия. Я имею в виду, давай, это то , что точка устаревания является . Мне кажется, что вы [множественное число] исходите из точки зрения «дай мне C или дай мне смерть», искусственно объединяя A и B, потому что вы просто не потерпите идеи о том, что какие-либо варианты имен параметров когда-либо исчезнут по какой-либо причине. Если я ошибаюсь в этом восприятии, пожалуйста, объясните.  -  SMcCandlish ☏ ¢  😼  04:18,14 февраля 2021 г. (UTC)
  • Вариант C за Фила Бриджера. Элджит ( разговорное ) 21:28, 11 февраля 2021 (UTC)
  • Вариант C - комментарий здесь, вероятно, подпадает под список моих врачей, «что HF не должен делать, когда у него сотрясение мозга», но я не хочу пропустить это обсуждение. Хотя я понимаю, что поддержание шаблонов цитирования - непростая задача, в конце концов, жесткость шаблона цитирования нежелательна. Шаблоны цитирования должны быть простыми в использовании, а наличие пары псевдонимов для наиболее распространенных параметров упрощает использование. И форель гильдии ботов за утверждение задачи бота, которая была спроектирована так, чтобы не рекомендовать параметры шаблона, без единого мнения об этом. Обсуждение Hog Farm 22:15, 11 февраля 2021 г. (UTC)
  • Первый выбор , второй выбор B . Исходный текст Википедии становится все более сложным и трудным в управлении, что делает его менее доступным, за исключением тех, кто участвует в этом виде опытных редакторов. Все, что мы можем сделать, чтобы уменьшить сложность, - это победа. Чем меньше вариантов, тем лучше, когда они явно избыточны. - Зеленый C 22:41, 11 февраля 2021 г. (UTC)
  • Вариант C для Фила Бриджера, лично я предпочитаю параметры без дефиса, и считаю, что отказ от них является абсолютно бессмысленным упражнением, которое ломает вещи абсолютно без каких-либо причин, кроме как для удовлетворения косметических предпочтений нескольких редакторов. Девонский вомбат ( разговор ) 00:14, 12 февраля 2021 (UTC)
  • Вариант C . В основном на свиной ферме. Редакторы, использующие эти шаблоны, могут сохранить часто используемые псевдонимы. Никкимария ( разговорное ) 01:17, 12 февраля 2021 (UTC)
  • Поддержка вариант C, нейтральный по варианту В, сильно противиться вариант А . Мои пальцы привыкли вводить многие из этих названий параметров без дефисов. Отказ от них и сопутствующий гномический труд по их замене нерекомендуемыми версиями уже вызывают у меня значительные затруднения, как при попытке вспомнить, что на самом деле теперь они должны быть расставлены через дефис, так и при попытке выделить важные изменения в моем списке наблюдения среди всех бессмысленная гномерия. Еще хуже было бы удалить все формы без дефиса. - Дэвид Эппштейн ( разговор ) 01:41, 12 февраля 2021 г. (UTC)
  • Вариант C . Я с Филом Бриджером и Хог Фарм. Не знаю, сбрасывание ли это велосипеда или бритье яка, но это просто непродуктивно и плохо выглядит. Альтернативы существуют потому, что это проще, чем запоминать, какая из двух общих возможностей является приемлемой, вместо того, чтобы форсировать одну или другую (как это делают другие варианты). С другой стороны, обсуждение эффективности из-за того, что персонаж находится вне очереди (о, значит, мы делаем этот выбор, основываясь на том, что все используют QWERTY?) - это своего рода аргументация игнорирования практических фактов, которая приводит к конечным результатам в форме утконоса. - Майкблас ( разговор ) 01:52, 12 февраля 2021 (UTC)
  • A лучше в долгосрочной перспективе, но B на данный момент, и преобразование должно быть покрыто генами AWB и т.п. Headbomb { t · c · p · b } 02:29, 12 февраля 2021 г. (UTC)
    Комментарий К сожалению, в данном случае оставлять это на усмотрение только генфиксов AWB было бы неэффективно и нежелательно. Поскольку на любой данной странице, вероятно, будет так много таких пармов, генфиксы, вероятно, затопят основное запланированное изменение, вызывая понятное раздражение. Гораздо лучше оставить это этому отличному боту, который ясно и открыто говорит о том, что делает - никаких неприятных сюрпризов. Вот почему я предпочитаю вариант A варианту B, но любой из них намного предпочтительнее варианта C. - NSH001 ( разговор ) 08:31, 7 марта 2021 г. (UTC)
  • Вариант C за Фила Бриджера. SarahSV (разговор) 02:51, 12 февраля 2021 (UTC)
  • Вариант C . Такой подход «все должно быть расставлено через дефис» плохо работает с текстовым редактором. Для некоторых распространенных параметров, таких как |accessdate=, просто лучше быть без дефиса, потому что исходный текст быстрее и легче разбирается человеком, потому что параметр не переносит слова в текстовое поле редактора. Джейсон Куинн ( разговорное ) 03:09, 12 февраля 2021 (UTC)
  • Вариант Б . Мы должны прекратить перечислять те, которые не содержат дефисов, по крайней мере, в документации, чтобы между редакционным сдвигом и очисткой генфиксов AWB / ботов мы со временем стали более последовательными. Еще слишком рано для варианта А, если вообще когда-либо, потому что шаблоны служат нам, а мы не обслуживаем шаблоны. Для шаблонов совершенно нормально поддерживать варианты без дефиса, чтобы они не сломались, если люди попробуют их. Но мы не должны продолжать перечислять эти варианты в документации. Это противоречит цели создания шаблонов, так как мы сохраняем несогласованность (без уважительной причины, например, цвет ENGVAR по сравнению с цветомразличие). И это бессмысленно делает документацию длиннее и сложнее без всякой выгоды; никто, ищущий, как указать URL-адрес Archive.org, не должен ничего знать, но |archive-date=и говорить им, что они |archivedate=тоже работают, - это просто забивать им в голову бессмысленные мелочи. Да, продолжайте преобразование в версии с дефисом в генфиксах и других автоматических изменениях (при одновременном выполнении чего-то более существенного). Наконец, вариант C бессмысленен. Мы регулярно (постепенно) отказываемся от поддержки различных старых имен параметров, и это отлично работает. Вариант Б ничего не сломает и даст (уже дает) положительные результаты.  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC)
  • Вариант B Вариант C . Все это действительные псевдонимы, так как нет никакой путаницы между say|access-date=и|accessdate=. Статус-кво работает нормально: использование дефиса предпочтительнее, потому что его легче читать, но без дефиса приемлемо, потому что нет двусмысленности и, очевидно, многие люди набирают его таким образом. Косметические изменения должны соответствовать политике. -  Finnusertop ( обсуждение ⋅ вклад ) 05:53, 12 февраля 2021 г. (UTC) Изменено с B на C, поскольку я не согласен с последствиями «формально устаревшей» части этих допустимых псевдонимов. -  Finnusertop ( обсуждение ⋅ вклад ) 09:26, 12 февраля 2021 г. (UTC)
  • Вариант C первый выбор (B второй). Редакторам должно быть разрешено использовать версии с дефисом или без него. Последовательность здесь не лучше, чем гибкость: единственные люди, читающие параметр, - это редакторы, поэтому позвольте редакторам решать, хотят ли они использовать дефис в своих параметрах шаблона. Я разделяю общую озабоченность по поводу разрыва связи между разработчиками кода и авторами контента, а также разочарование в связи с тем, что некоторые специалисты по сопровождению шаблонов и ботов навязывают решения всем без единого мнения. Свершившийся факт Редактирование миллионов правок или включений - это своего рода большое дело. Levivich  харасс / гончая 07:20, 12 февраля 2021 (UTC)
  • Мне нравится C : Я особенно повторяю комментарии Левивича, Тридуульфа и Фила Бриджера относительно этих постоянных, периодических, новых сюрпризов, когда дело касается редактирования статей. Это разрушительно, и мы должны просто прекратить это. C, следовательно, вернет здравомыслие. G en Q uest "scribble" 07:42, 12 февраля 2021 г. (UTC)
  • Вариант C . Это шаблоны для использования редакторами, они не влияют на читателей, и создание правил и положений, а затем написание ботов для обеспечения соблюдения этих бессмысленных правил - пустая трата времени. Не говоря уже о том, что когда AWB «исправляет» все это в статье, он может заглушить подлинные правки и затруднить отслеживание людьми того, что происходит. Избавьтесь от этого нелепого правила, удалите его из AWB, и тогда, возможно, мы сможем приступить к созданию энциклопедии. -  Амакуру ( разговор ) 09:13, 12 февраля 2021 (UTC)
  • Вариант C (который является статус-кво ante ). Я просто не понимаю, какую проблему пытаются решить люди, поэтому следите за WP: NBDF . Параметры, разделенные дефисом, полезны и улучшают читаемость викитекста, лично я предпочитаю их, но использование обеих форм упрощает работу редакторов. Исключение их поддержки кажется бессмысленным, а полное удаление - вредным. Он создал миллионы бессмысленных бесполезной работы правок засоряя без всякой списки наблюдения уважительной причины. У нас нет проблем с псевдонимами шаблонов, так зачем беспокоиться о псевдонимах параметров? Ни один из них не сформулирован убедительно. Скромный Гений говорить 12:10, 12 февраля 2021 (UTC)
  • Так как меня пингируют, нейтральный со всех сторон. У меня ностальгия по статус-кво по некоторым уже представленным причинам (мышечная память, разрывы строк), но я понимаю, что как только мы пройдем через долину тени и выйдем на яркие возвышенности в более чистой реализации, мы забыл о боли. Имейте в виду, мне, вероятно, будет 90 лет, и мне будет все равно. Но у меня есть некоторые проблемы с реализацией в Обсуждении. Дэвид Брукс ( разговор ) 16:54, 12 февраля 2021 (UTC)
  • Вариант C - подобная стандартизация может быть полезна исследователям или разработчикам, но не обычным пользователям. Добавление цитат должно быть максимально простым. С этой целью я хочу свести к минимуму вероятность того, что интерфейс не будет знать, что я пытаюсь сделать, или что я получу сообщение об ошибке, потому что я ввел подчеркивание вместо дефиса. Остальная часть Интернета пытается повысить гибкость, чтобы пользовательский интерфейс был простым и интуитивно понятным. Мы тоже делаем это разными способами. Но здесь мы, кажется, делаем наоборот: убираем гибкость и требуем от пользователей знать, как мы сформулировали / устроили вещи.
    Меня не волнует, есть ли бот, который стандартизирует их потом, или кто-то запускает AWB позади меня. Опять же, меня привлекает стандартизация. Мы должны просто сделать все, что в наших силах, чтобы сделать этот опыт интуитивно понятным для обычных пользователей. -Рододендриты говорят \\ 23:04, 12 февраля 2021 (UTC)
    • Альтернатива: Вариант D - позвольте боту и / или AWB стандартизировать, но никогда не отключайте параметры. Стандартизация - это хорошо; ухудшение юзабилити - это плохо. -Рододендриты говорят \\ 23:12, 12 февраля 2021 г. (UTC)
      Я бы, безусловно, поддержал ваш вариант D, если бы он был на столе, но не могу поддерживать ничего, что говорит о том, что эту функциональность следует удалить, поскольку вариант B (несмотря на неграмотные утверждения выше, что это не так) явно требует. Фил Бриджер ( выступление ) 18:10, 13 февраля 2021 (UTC)
  • Вариант А с вторым вариантом Б. Поддержание наших сложных шаблонов цитирования - непростая задача, и если люди, которые вкладывают в работу, хотят сделать это, чтобы облегчить свою работу, я поддерживаю это. Legoktm ( разговор ) 23:48, 12 февраля 2021 (UTC)
  • Вариант C с вариантом B в качестве второго варианта: Modest Genius дает отличный комментарий, как и некоторые другие. Сообществу нужно перестать тратить время на эту ерунду с форматированием цитат и вместо этого выполнить тяжелую работу по включению цитат в статьи, где мы на самом деле столкнулись с отчаянным кризисом, который наносит ущерб нашей репутации. я использую|accessdate=и я не собираюсь останавливаться. Я очень хорошо помню процесс изучения шаблонов цитирования в 2014 году - сначала они сбивали меня с толку, но у меня никогда не было ни единой путаницы при синтаксическом анализе «accessdate» как двухсловной фразы «дата доступа», очень ясно означающей дату, когда вы последний раз получил доступ к ссылке. Я вижу, что теоретически это было бы немного лучше для новых пользователей, и я вижу, что на практике некоторые люди, которым не нравится внешний вид "accessdate", увеличивают его ("мое мнение" становится "правильным представлением" становится «моральный императив, который необходимо принуждать»), но это просто не перевешивает реальную подлинную боль, это заставит редакторов, таких как я, переучивать многолетнюю развитую мышечную память;почти каждое редактирование в основном пространстве, которое я делаю в течение нескольких месяцев, будет иметь прерывистый поток (прерывает мой мыслительный процесс, тратит мое время на повторный ввод текста), если это нужно изменить.
    Что касается бота, который тратит несколько минут моего времени в день, я в первую очередь категорически против этого, и с меня его более чем достаточно. (Нет, я не могу игнорировать это, потому что, если я отключу редактирование ботов, я пропущу акты вандализма, неконструктивные изменения или теги очистки, которые будут скрыты последующим редактированием ботов.) BRFA нуждаются в более широкой рекламе, когда их объем настолько огромен и их нарушение WP: COSMETICBOT настолько явное. Я не согласен с тем, что вариант B отражает прошлый консенсус на практике, поскольку я не могу припомнить, чтобы кто-нибудь когда-либо обращался ко мне по поводу того, что я использую его |accessdate=или меняю его на |access-date=ручной режим. Конечно, прошлый локальный консенсус среди технических групп, которые не работают в области статей, конечно. Но консенсус сообщества энвики? Нет. - Билорв ( разговор) 01:07, 13 февраля 2021 (UTC)
    • @ Bilorv : если я отключу редактирование ботов, я пропущу акты вандализма, неконструктивные изменения или теги очистки, которые будут скрыты последующим редактированием бота - это всегда меня озадачивает. Просто любопытно, но почему бы не включить «Развернуть список наблюдения, чтобы отображать все изменения, а не только самые последние» + «Группировать изменения по страницам в последних изменениях и настройках списка наблюдения»? Я не вижу правок ботов, и они ничего не скрывают. -Рододендриты говорят \\ 02:50, 13 февраля 2021 (UTC)
      • @ Рододендриты : оцените предложение! Мне никогда не приходило в голову, что их объединение приведет к такой функциональности (существует так много сложных комбинаций фильтров списка наблюдения и параметров предпочтений), но я включил эти два и оставил «Последняя ревизия» включенным и включил «Человек (не бот)» поскольку параметр предпочтений «Скрыть изменения бота из списка наблюдения», похоже, этого не делал, и теперь я думаю (небольшой размер выборки в моем списке наблюдения на банкомате), я вижу только последнее изменение, в том числе, если это бот, но только если было сделано одно редактирование, не связанное с ботами (что в точности желательно). - Билорв ( разговор ) 11:34, 13 февраля 2021 (UTC)
  • Вариант А с вторым вариантом Б. Поддержание сложных шаблонов цитирования - непростая задача. AManWithNoPlan ( обсуждение ) 02:52, 13 февраля 2021 (UTC)
  • Вариант А на том основании, что стандартизация - это хорошо. На самом деле меня не волнует, есть дефисы или нет, но лучше так или иначе, чем смешивать. В общем, я бы предпочел, чтобы мы отказались от использования вики-текста для справочной информации, хотя это все равно, что делать свои финансы в текстовом документе. Спасибо. Майк Пил ( разговор ) 18:26, 13 февраля 2021 (UTC)
  • Вариант A Я лично всегда предпочитал форму с переносом через дефис, потому что она позволяла программе проверки орфографии проверять отсутствие опечатки, тогда как форма без дефиса всегда помечается как опечатка, хотя предварительный просмотр теперь сообщает мне об ошибках. Я не согласен с утверждением, что люди могут анализировать |accessdate=быстрее, чем |access-date=; по этой причине были изобретены пространства. Я также знаю накладные расходы, связанные с разрешением нескольких параметров, которые означают одно и то же в шаблонах. Я знаю, что это загромождает мой список наблюдения изменениями Monkbot, но мой! Голос продолжается. Hawkeye7 (обсуждение) 22:12, 13 февраля 2021 (UTC)
    Обратите внимание, что это в основном обоснование WP: ILIKEIT и отклоняет мнения тех, кто указывает, что они могут анализировать "accessdate" без проблем, как неправильные без каких-либо доказательств. Он также отклоняет очень реальные нарушения, причиненные другим, как необходимые для сокращения накладных расходов, тогда как эти накладные расходы, даже если они значительны, поскольку некоторые утверждения (для которых никогда не было представлено убедительных доказательств), они все еще тривиальны по сравнению с сбоями, вызванными Monkbot. правки и ненужные перерывы в работе редакторов, использующих шаблоны. Тридуульф ( разговор ) 15:29, 14 февраля 2021 (UTC)
  • В или С . У меня нет сильных предпочтений между accessdate или access-date, оба кажутся полезными, если формально предпочтительнее, то нормально. Однако продолжающийся массовый спам от ботов о том, что буквально не влияет на читателей и почти не влияет на редакторов, неоправдан. Помимо того, что он находится повсюду в списке наблюдения, Monkbot значительно усложняет выявление различных серий различий в истории редактирования с небольшой пользой. Пользователь, вносящий правку, вставляя «accessdate», не является вопиющей проблемой, которая должна вызвать запуск бота, и такое действие бота затем скрывает нужное редактирование из списков наблюдения. CMD ( обсуждение ) 18:18, 14 февраля 2021 (UTC)
  • Вариант C . Удаление стандартного способа ввода параметров в шаблоны снижает удобство использования для конечных пользователей. Наличие бота, которое «исправляет» их, отрицательно сказывается на удобочитаемости истории страниц и списков наблюдения. Никто из участников этого разговора не продемонстрировал, что бремя обслуживания шаблона настолько велико, что оно оправдало бы все эти недостатки. Также кажется, что бремя обслуживания - это не то, что было бы трудно отследить, как случайные синие ссылки на статьи по основным темам, когда предназначались статьи по неосновным темам, поскольку код шаблона находится на страницах шаблонов .---- Patar Knight - чат / вклад 18:53, 14 февраля 2021 (UTC)
  • Вариант C . Предыдущие обсуждения, упомянутые выше (RFC шестилетней давности, в котором участвовало семь человек, в котором конкретно пообещали, что ничего не будет обесценено, а затем последовал аргументированный аргумент о бремени обслуживания), отдаленно недостаточно, чтобы оправдать такое радикальное изменение. Да, бремя обслуживания - это боль, но она затрагивает относительно небольшую группу авторов ботов; удаление наиболее широко используемой версии параметра шаблона затрагивает огромное количество редакторов, которым здесь нужно уделять внимание из-за того, что они более многочисленная группа. И очевидно, что нетпостоянный консенсус в том, что бремя обслуживания оправдывает такие изменения (по крайней мере, не одно в масштабе, необходимом для оправдания этого), иначе это обсуждение не было бы столь четко разделенным. Поэтому unhyphenated версия никогда не должна была обесценена, что делает редактирование бота бессмысленно запутывание в лучшем случае и попытку протолкнуть спорное изменение без достаточного консенсуса через декретные Accompli в худшем случае. Кроме того, если бремя обслуживания является единственной проблемой, очевидно, что решение состоит в том, чтобы отменить RFC 2016 года (в котором, опять же, участвовало всего семь человек и согласились просто создать версии с дефисом в качестве альтернативы) и удалить версию с дефисом , которая в настоящее время мало полезен и, следовательно, будет намного проще и менее разрушительно утилизировать. -Аквиллион ( разговор ) 22:12, 15 февраля 2021 (UTC)
  • Вариант Б -иш. Я думаю, что это разумно, чтобы дефисные формы были канонической версией параметра, но я не вижу причин для массового редактирования, чтобы переходить от одной формы к другой или изменять здесь обычные правила для косметических ботов. Я не вижу вреда в варианте C, но реализация варианта A поменяет текущие проблемы на новые. - AntiCompositeNumber ( обсуждение ) 02:15, 16 февраля 2021 (UTC)
  • Сильная поддержка A : стандартизация параметров шаблона важна и полезна.
Мягкая поддержка B : количество |accessdate=страниц на странице слишком чертовски велико (большую часть времени), настолько, что мешает проверке обычных WP: GenFixes (т.е. многие одноэкранные различия становятся многоэкранными) - я бы сильно поддержал B IIF Monkbot может продолжить и перенести хотя бы этот параметр.
Сильный Противостаньте C : антитезу A .
~  Том Рединг ( talk ⋅ dgaf )   19:23, 16 февраля 2021 г. (UTC)
  • Кому важна и полезна стандартизация параметров шаблона? Фил Бриджер ( разговорное ) 20:39, 16 февраля 2021 (UTC)
  • Как и почему стандартизация более важна и полезна, чем возможность редакторов улучшать энциклопедию без необходимости знать точный формат имен параметров и иметь дело со списками наблюдения и историями страниц, полными косметических правок? Тридуульф ( разговор ) 20:45, 16 февраля 2021 (UTC)
  • Вы все предлагаете вернуть все устаревшие параметры и добавить больше, чтобы каждый пользователь мог выбрать наиболее удобные / понятные / интуитивно понятные для них имена параметров? Я нормально отношусь к мягкому устареванию - разрешаю и то, и другое, но обескураживаю / конвертирую один, массово один раз через бота, затем постепенно / пассивно через WP: GenFixes и другие инструменты, но это не один из вариантов.
    Re: "списки наблюдения": можно настроить игнорирование ботов, пока это не будет сделано.
    Re: "истории, полные косметических правок": бот требует только 1 правку; вряд ли "полно"; Тем не менее, сообщество согласилось с WP: CBD .    ~  Том.Рединг ( разговор ⋅ dgaf )   12:16, 17 февраля 2021 г. (UTC)
    Да, я предлагаю, чтобы все параметры, состоящие из двух слов, принимали варианты с дефисом и без него. Это нормально, если одно будет предпочтительнее другого в документации, но оба должны работать и продолжать работать, поскольку это наименее мешает редакторам и позволяет им тратить свое время на создание / поддержку контента, а не на беспокойство о привередливом синтаксисе. У меня нет серьезных возражений против замены одного исправления другим при внесении некосметических изменений на страницу, но я бы не стал активно поощрять это, так как это бесполезно загромождает различия. Я категорически против массового запуска ботов и того, чтобы в будущем один вариант не работал. Тридуульф ( разговор ) 15:29, 17 февраля 2021 (UTC)
    Re "Вы предлагаете вернуть все устаревшие параметры" - да, это правильно. Они никогда не должны были быть устаревшими. Это шаблон, который находится в фоновом режиме и существует для удобства редактора, не более того. Устаревание параметров снижает это удобство. И хорошо известно, что боты и редакторы не должны вносить косметические изменения в викитекст, которые ничего не делают для изменения страницы, поэтому и их нужно прекратить. -  Амакуру ( разговор ) 12:48, 18 февраля 2021 (UTC)
  • Вариант C, я полагаю , поскольку меня не убедили в предельной полезности версий, написанных через дефис. Без этой ясности мы не должны делать такого рода изменения. (И если бы у нас был консенсус, то B, но с изменениями документации в качестве первого шага.) -  Джон ФромПинкни ( выступление ) 01:48, 17 февраля 2021 г. (UTC)
  • Вариант C Если работает, не исправляйте. Эндрю 🐉 ( разговор ) 13:01, 17 февраля 2021 (UTC)
  • Вариант A, категорически против варианта C: любой, кто регулярно работает над шаблонами или модулями, оценит ценность использования единого стиля для таких проблем, как имена параметров. Меня не волнует, каков согласованный стиль, если он согласован, и спор о том, следует ли его переносить, подчеркивать, использовать верблюжий регистр или повторять, был решен с использованием переноса в качестве предпочтительного стиля. Тогда бессмысленно не реализовать этот стиль, и я бы предпочел, чтобы это было сделано как можно скорее. Вся эта дискуссия напоминает войны за привязку дат, когда были высказаны серьезные возражения против отмены увязки дат, но в течение нескольких месяцев после принятия обязательного решения об отсоединении дат все двинулись дальше, и сегодня никто даже не подумал бы об увязке дат. После того, как мы стандартизировали параметры, расставленные через дефис,будущие редакторы оглянутся назад и подумают, насколько бессмысленны и бесполезны подобные дискуссии. -RexxS ( разговор ) 19:46, 19 февраля 2021 (UTC)
  • A или B, но не C согласно Scott, Hawkeye и RexxS. Использование гифенизма или более удобного для пользователя, и то, что здесь есть некоторая предварительная работа на нашей стороне, позволяет использовать какой-либо ограничитель между словами вместо того, чтобы запускать их вместе. Так же, как мы перестали связывать даты и больше не SmashWordsTogether , это стоит временных неудобств. - WUG · а • ро · дез 00:46, 20 февраля 2021 (UTC)
    Notwhen it'sjust twowords :-P Levivich  харасс / гончая 8:10, 20 февраля 2021 (UTC)
    ... так бы выглядел ваш комментарий, если бы мы позволили людям использовать любой метод, который им подходит, и при этом заставили бы его работать. Если бы мы отключили эти параметры, ваш комментарий не появился бы. Если мы позволим людям использовать все, что работает, и использовать бота для очистки впоследствии, ваш комментарий будет выглядеть так же, как и все остальные, через некоторый период времени (в течение которого ваш комментарий все еще будет работать, даже если пары слов иногда комбинируются) . :) -Рододендриты говорят \\ 20:15, 22 февраля 2021 (UTC)
  • Вариант А для всех аргументов, уже подробно изложенных на страницах обсуждения CS1 / CS2 за эти годы, и хороших аргументов, приведенных выше. Определенно не вариант C. - Матиаспол ( разговор ) 02:06, 20 февраля 2021 (UTC)
  • Вариант C . Такая абсурдная трата времени и энергии и огромный источник спама в списках наблюдения - все для достижения чего-то, что затруднит редактирование . Toohool ( разговор ) 02:26, ​​22 февраля 2021 (UTC)
  • Вариант А как стандартизация лучше в долгосрочной перспективе. Пусть бот продолжает свою работу. Если у людей есть проблема с тем, что их список наблюдения попадает в спам, у них есть возможность отфильтровать правки ботов. AVS malnad 77 talk 05:59, 23 февраля 2021 (UTC)
  • Вариант C, если не B Хотя мне нравится последовательность, я изо всех сил пытаюсь понять, в чем заключается настоящая проблема. Я предполагаю, что они могут быть постепенно изменены ботом вместе с другими более полезными изменениями, но это просто косметика для кода и мешает истории редактирования. Обсуждение Reywas92 06:21 , 24 февраля 2021 (UTC)
  • Вариант C . Преимущества для создателей ботов или шаблонов не перевешивают неудобств для других редакторов. Фрам ( разговор ) 08:13, 24 февраля 2021 (UTC)
  • C . Я не вижу аргументов в пользу обязательного использования дефисов. Просто позвольте людям использовать оба, последовательность в этом не имеет значения. Заборы и окна 17:00, 24 февраля 2021 г. (UTC)
  • Комментарий - по умолчанию я использую вариант D. Я отказываюсь использовать шаблоны цитирования и форматирую свои цитаты вручную. Это означает, что я могу игнорировать все глупые споры о параметрах и о том, что нет. Blueboar ( разговор ) 17:49, 24 февраля 2021 (UTC)
    Да, и мы можем мгновенно очистить отставание WP: PHAB, написав статьи ручкой и бумагой. Мы можем решить многие технологические проблемы, отказавшись от технологий. Levivich  харасс / гончая 00:52, 25 февраля 2021 (UTC)
  • Вариант C . Боты выполняют некоторую полезную работу, но их код можно изменить по мере необходимости. Здесь меня гораздо больше беспокоят обычные редакторы, которые используют шаблоны цитирования при ручном редактировании. Это живые люди, и их намного больше, чем ботов. Если сделать синтаксис шаблонов слишком жестким, их жизнь станет еще более неприятной. Дополнительная гибкость полезна и полезна для обычных редакторов. Nsk92 ( разговор ) 02:26, ​​25 февраля 2021 (UTC)
  • Вариант C . Я набирал accessdate последние 15 лет или около того, иногда хватаясь за напиток другой рукой (клавиатура Qwerty). Зачем разрушать мою мышечную память и лишать меня глотка чая? - гадфий, 04:04, 25 февраля 2021 г. (UTC)
  • Вариант C для Фила Бриджера Sea Ane ( разговор ) 21:53, 26 февраля 2021 г. (UTC)
  • Вариант C , остановить сумасшествие, попадающее в списки наблюдения (хотя большая часть этого ущерба уже нанесена). Сэнди Джорджия ( Обсуждение ) 00:58, 2 марта 2021 (UTC)
  • Лучше всего звучит C , за ним следует B. Удаление параметров, которые широко использовались в прошлом, сломает старые редакции статей и принесет очень мало практических преимуществ. - Кусма ( t · c ) 11:44, 2 марта 2021 г. (UTC)
  • Вариант C . Другие уже задались вопросом, почему - спам в списках наблюдения, бесполезная трата времени и энергии, ненужное навязывание редакторов и т.д. Избегайте постоянной возни с этими шаблонами. JG66 ( разговорное ) 11:51, 2 марта 2021 (UTC)
  • Вариант C на акмиллион. Monkbot никогда не должен был быть одобрен - In Act (Guerillero) Parlez Moi 20:22, 2 марта 2021 (UTC)
  • A или B Это похоже на выбор между ненужным наличием нескольких разных способов записи данного параметра и между стандартизацией постфактум с большим количеством мелких правок. Многие аргументы в пользу языка C, по-видимому, предполагают, что редакторы столкнутся с проблемами при написании параметров без дефисов, но я не вижу доказательств этого. Джо-Джо Эумер ( выступление ) 10:30, 4 марта 2021 г. (UTC)
  • Вариант А . Из реального опыта я понимаю, насколько сложно поддерживать код без периодического устаревания. Опасения противников перед неприемлемыми сбоями и неудобствами не соответствуют тому, с чем я столкнулся, когда бот работал, и ввод дефиса быстро стал моей привычкой. - Ворлдбрюс ( разговор ) 05:07, 7 марта 2021 г. (UTC)
    Возможно, вы лично не сталкивались с нарушениями и неудобствами, но я столкнулся, и в этом и других обсуждениях есть очень много других редакторов, которые сообщили о недопустимых нарушениях и точно объяснили, почему неудобства не оправданы. Тридуульф ( разговор ) 20:29, 7 марта 2021 (UTC)
  • Вариант А . Долгосрочная выгода стоит краткосрочного перерыва. В шаблонах слишком много несоответствий, из-за чего я трачу гораздо больше времени (например, это «image =» или «Image =» или «photo =» в этом конкретном шаблоне); мы должны двигаться к большей последовательности. Я бы поддержал сохранение параметров в рабочем состоянии в течение нескольких лет (но без документации и с предупреждением) для тех, кто действительно обеспокоен вводом дефиса, зная, что бот придет и изменит их. МБ 15:23, 7 марта 2021 г. (UTC)
    Лучшее решение для "is it" image = "или" Image = "или" photo = "" - просто поддерживать их все. Таким образом, нет необходимости в каких-либо сбоях, краткосрочных или иных. Тридуульф ( разговорное ) 20:31, 7 марта 2021 (UTC)
  • Вариант A - стандартизация помогает упростить сопровождение кода, а это означает, что больше времени можно посвятить будущим улучшениям. Имзади 1979  → 17:34, 7 марта 2021 (UTC)
  • Перед нами стоит вопрос: следует ли полностью удалить параметры без дефиса из семейства шаблонов CS1 / 2? Да, безусловно, по большинству, если не по всем причинам, перечисленным выше. Должно быть реализовано согласованное именование параметров c. 2007 г., когда различные, независимо разработанные шаблоны cs1 | 2 были преобразованы для использования в качестве общего механизма обработки цитирования. В начале 2013 года en.wiki перешла на модуль: Citation / CS1.{{citation/core}}люкс. С тех пор около 180 вики-сайтов MediaWiki на других языках плюс некоторое количество вики-сайтов, не относящихся к MediaWiki, также перешли в набор модулей. За время, прошедшее с тех пор, как en.wiki перешла на набор модулей, мы добавили новые имена параметров для поддержки новой функциональности, и в то же время мы сократили довольно много имен параметров из-за избыточности, своеобразного стиля имени, неиспользования , и другие причины. Это сокращение включает большинство nonhyphenated неоднословных имен параметров , так что сегодня, только оставшиеся nonhyphenated имен параметров |accessdate=, |archivedate=, |archiveurl=, |authorlink=(и его два перечисленных форм), и|origyear=(имеется 263 основных имени параметра и 77 пронумерованных имен параметров). Принятие во всем мире набора модулей cs1 | 2 заставило нас добавить поддержку интернационализации. Неанглоязычные вики, использующие набор модулей cs1 | 2, должны сохранять все имена параметров на английском языке, потому что очень часто статьи, разработанные на en.wiki, экспортируются и переводятся на эти другие языки. Это означает, что полностью реализованный набор модулей неанглоязычной вики должен поддерживать 340 английских имен параметров плюс 340 локальных имен параметров. Я думаю, что лучше всего иметь единый согласованный стиль для многословных имен параметров, чтобы редакторам-переводчикам не приходилось узнавать или иметь дело с избыточными именами параметров (то же самое относится к начинающим редакторам на en.wiki). Шаблоны cs1 | 2 достаточно сложны, мы неЭту сложность необходимо усложнять, поддерживая списки синонимичных имен параметров, не имеющих семантического значения (например,|chapter=, |article=, |entry=, |section=И т.д., обрабатывают КС1 | 2 как синонимы , но, редакторам, передают разные значения - включение или бездействие дефис транспортирует не имеет смысла награждений). Так что да, параметры без дефиса [должны] быть полностью удалены из семейства шаблонов CS1 / 2, и поскольку мы не можем вернуться в 2007 год, чтобы сделать то, что мы должны были сделать тогда, мы должны сделать это сейчас, мы должны сделать это быстро, и мы должны это сделать. Мой предпочтительный вариант , но, если это необходимо должно, то (Вздох) B ; никогда другой вариант. - Монах-траппист ( разговор ) 00:50, 8 марта 2021 г. (UTC)
    Спасибо за взвешивание, траппист; Я просто хочу, чтобы ты сделал это месяц назад. Ваше объяснение убедительно, но я все же считаю вариант А глупым, если мы хотя бы одновременно не изменим документацию, чтобы сказать пользователям: «Больше не используйте этот параметр». Вести ботов, сражающихся с редакторами-людьми, глупо, неэффективно и, возможно, даже опасно . -  JohnFromPinckney ( разговор ) 02:03, 8 марта 2021 г. (UTC)
    Итак, суммируя аргументы траппистов: разработчикам намного проще иметь только несколько имен, поэтому мы должны нарушить работу редакторов и, следовательно, вики, чтобы облегчить их жизнь, независимо от затрат (ранее подробно объяснялось, как два имени делают одно и то же. вещь совсем не проблема для редакторов). Извините, но это ни в малейшей степени неубедительно: шаблоны существуют для поддержки редакторов, а не наоборот. Тридуульф ( разговор ) 03:06, 8 марта 2021 (UTC)
    Нет. Траппист такого не сказал. Он услужливо объяснил, почему это изменение необходимо. За возможным исключением списков наблюдения, это изменение не серьезно "нарушает работу редакторов" (нельзя сказать, что необходимость ввода одного дополнительного символа является проблемой такого масштаба); наоборот, в долгосрочной перспективе это делает жизнь легче для редакторов, потому что есть только один простой, легкий для запоминания правила: все параметры мути слова использовать дефис для разделения слов. В списках наблюдения см. # Стоит отметить ниже, что кажется многообещающим решением. И если худшее дойдет до худшего и это решение не сработает для вас, то я сочувствую, но, по крайней мере, «сбои» будут временными, пока бот не закончит работу. - NSH001 ( разговор) 10:05, 8 марта 2021 г. (UTC)
    Нет, сбой не временный. Мало того, что люди, вероятно, продолжат использовать «старые» параметры, но и удаление поддержки этих параметров из шаблонов означает, что миллионы старых ревизий будут содержать ошибки вместо того, чтобы просто отображать ссылки, как раньше. Создание ошибок в ссылках старых версий бесчисленных страниц, так что вам нужно поддерживать только 340 вместо 349 параметров (ну, даже не это, 340 параметров + 9 синонимов)? Похоже, что это большой сбой без особой выгоды. Фрам ( разговорное ) 11:13, 8 марта 2021 (UTC)
    На самом деле это не имеет значения, ссылки на старые версии страниц относительно редки, а сообщения об ошибках можно спокойно игнорировать - имеет значение только последняя страница. Они также страдают от удаленных шаблонов (которые могут быть гораздо более серьезными для страницы, поскольку фактически отображаются для пользователя) и вики-ссылок, которые стали красными, потому что целевая страница была удалена. Без сомнения, о других вещах, о которых я еще не думал. Человек просто принимает эти недостатки. Ничего серьезно не "нарушает". - NSH001 ( разговор ) 14:05, 8 марта 2021 г. (UTC)
    Красная ссылка, потому что цель не существует, не проблема (это даже улучшение). Остальные - проблемы, и сознательное добавление большего, гораздо большего количества того же самого - серьезная проблема. Версия Сальвадора Дали 5-летней давности уже содержит около 10 ошибок: больше всего раздражают языковые ошибки. Но запланированная дефенестрация, например, accessdate внезапно добавит сюда 24 дополнительных ошибки. По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже, и отсутствие текущих будущих версий, которые станут лучше. Фрам ( разговорное ) 14:33, 8 марта 2021 (UTC)
    «По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже». Это неправда. Правки Monkbot 18 никак не влияют на отображение сообщений об ошибках; фактически это сократит (значительно) количество сообщений об ошибках, которые в конечном итоге будут отображаться, когда и если оставшиеся формально не рекомендуются, где «формально не рекомендуется» означает изменение набора модулей CS1 / 1 для фактического создания сообщений об ошибках. - NSH001 ( разговор ) 09:37, 11 марта 2021 г. (UTC)
    Не ложь, просто стенография. Можно увидеть количество ошибок, которые будут существовать, посмотрев на количество правок, которые Monkbot делает для этого. Нет, Monkbot не вызывает ошибок напрямую, это вызывает устаревание; но эти двое принадлежат друг другу. Если выбран вариант C, то не будет «когда и если», остальные не будут официально считаться устаревшими, и не будут генерироваться сообщения об ошибках ни в исторических, ни в реальных версиях. Никто. Фрам ( разговорное ) 10:56, 11 марта 2021 (UTC)
    «Можно увидеть количество ошибок, которые будут существовать, посмотрев на количество правок, которые Monkbot делает для этого». Это очень вводит в заблуждение. Количество правок, сделанных ботом, не имеет никакого отношения к ошибкам, отображаемым в реальной версии (за исключением того, что, как я уже объяснил, они уменьшаются ). Здесь вы пытаетесь ввести читателей в заблуждение, подразумевая, что каждое отдельное изменение, выполняемое ботом, вызывает сообщение об ошибке, хотя на самом деле это происходит только с историческими версиями. Сообщения об ошибках в исторических версиях не имеют значения. - NSH001 ( разговор ) 12:00, 11 марта 2021 (UTC)
    Нет, это не вводит в заблуждение, если читать настоящую беседу об исторических версиях. «удаление поддержки этих параметров из шаблонов означает, что миллионы старых ревизий будут содержать ошибки вместо того, чтобы просто отображать ссылки, как раньше». и "По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже, и нетекущие из будущих версий, которые станут лучше ». Это то, на что вы ответили, и это мы все еще обсуждаем. Мы можем не согласиться, являются ли ошибки в старых версиях проблемой или нет, или же затраты на поддержание нескольких синонимов в живых незначительны. или значительный; но, пожалуйста, не начинайте обвинять людей в том, что они «пытаются ввести читателей в заблуждение» (немного богато из-за того, что кто-то утверждает, что «access-date» проще в использовании и более значимо, чем «accessdate»). Фрам ( разговор ) 12 : 12, 11 марта 2021 г. (UTC)
  • Вариант C И эта проблема во многом объясняется тем, что я нахожусь на нынешней должности. BAG не подходит для использования и требует ядерной бомбардировки с орбиты. Только смерть заканчивает долг ( разговор ) 15:31, 8 марта 2021 (UTC)
    СУМКА выполняет несколько функций. Он хорошо справляется с некоторыми из них - в частности, он довольно хорошо обеспечивает, чтобы боты делали только то, что их авторы намереваются делать, прежде чем они будут выпущены. Основная проблема заключается в том, чтобы гарантировать, что только задачи с консенсусом, который должен быть выполнен, и консенсусом для бота для выполнения работы, утверждаются - я не могу вспомнить случай, когда он не смог утвердить что-то, что должно быть одобрено, и это действительно остановило вопиюще плохие идеи от продолжения, но есть несколько случаев (включая этот), когда планка консенсуса была установлена ​​слишком низко, и небольшой локальный консенсус позволил боту работать без одобрения широкого сообщества. Если у нас есть боты, нам действительно нужен какой-то процесс утверждения, поэтому не уничтожайте того, что у нас есть, не придумав сначала чего-то лучшего.Thryduulf ( разговор) 16:54, 8 марта 2021 г. (UTC)
    «только то, что их авторы намереваются сделать до того, как они будут освобождены». На техническом уровне это правильно - то, что BAG не делает, - это какая-то даже полуприличная работа по подтверждению того, что боты * продолжают * выполнять только те задачи, для которых они были первоначально одобрены, или что это одобрение в первую очередь имеет консенсус среди тех редакторов, на которых это * повлияет * на то, что задача желательна или необходима, или что есть явная выгода для тех, кто ее выполняет. Проблема с автоматическим редактированием редко заключается в техническом аспекте, это его экономическое обоснование. Если бы мы провели обзор текущих активных задач ботов (и редакторов, использующих автоматическое редактирование для выполнения массового редактирования), действительно ли вы думаете, что все они смогут указать на обсуждение, которое показывает уровень консенсуса, пропорциональный их влиянию на более широкие массы редакторов? ,а не обнесенный стеной сад (и термин, который я бы предпочел использовать здесь, поскольку он более точен, - это круговой рывок) 5 или 6 данных и машиночитаемых одержимых редакторов, которые этого хотят?Только смерть заканчивает долг ( разговор ) 08:30, 11 марта 2021 года (UTC)
    Что касается технического и бизнес-аспекта, я согласен, это была большая часть того, что я пытался подчеркнуть. Я также согласен с тем, что необходимо проводить регулярный обзор задач бота и автоматического редактирования. Есть некоторые, которые, я уверен, все еще имеют консенсус сообщества (например, антивандальные боты), но я не могу сказать, что это будет справедливо для каждой задачи. Я также согласен с тем, что должен быть активный консенсус редакторов, которые будут затронуты, прежде чем задача будет продолжена - в случае с monkbot почти все затронутые редакторы совершенно не знали, что это вообще было предложено. Тридуульф ( разговор ) 14:20, 11 марта 2021 (UTC)
  • Вариант Б. Я легко вижу обе стороны этого спора. Как человек, работающий в сфере информационных технологий, я полностьюсогласны с тем, что ИТ должны, по возможности, в первую очередь обслуживать потребности пользователей, а не просто облегчать жизнь людям, обслуживающим системы. Я вижу слишком много систем, которые усложняют жизнь, чем нецифровая альтернатива, что просто смешно. Конечно, бывают случаи, когда что-то нужно исключить, потому что оно либо несовместимо с другими вещами, либо имеет бреши в безопасности, либо требует слишком много времени на разработку для обслуживания. Этот случай - один из последних, хотя я не уверен, какую дополнительную нагрузку на самом деле добавляют устаревшие (без дефисов) параметры. Я бы порекомендовал нам официально отказаться от непереносимых параметров и очистить их с помощью генфиксов AWB, но я не могу поддерживать продолжение работы с Monkbot 18, учитывая силу настроения против такой задачи. ЛичноМеня не волнует «спам в списках наблюдения», но очевидно, что многие люди волнуются, и мы не можем просто игнорировать их мнение, потому что «это облегчило бы жизнь нам, техническим специалистам». ƒirefly ( t · c ) 07:42, 10 марта 2021 г. (UTC)
    Насколько я понимаю, есть структура для поддержки псевдонимов параметров, которые настраиваются в Module: Citation / CS1 / Configuration . Поскольку поддерживается много других псевдонимов, структура останется на месте. isaacl ( разговор ) 15:23, 10 марта 2021 (UTC)
  • Вариант A / B, как указано выше.  Spy-cicle💥  Разговор ? 18:50, 10 марта 2021 г. (UTC)
  • Вариант A , категорически против варианта C. Дефисы должны быть стандартными, и мы не должны их поощрять. Я не против продолжения поддержки версии без дефиса для B, но B также подразумевает, что бот не может выполнять свою работу, поэтому A так и есть. SportingFlyer T · C 12:57, 11 марта 2021 г. (UTC)
    Почему следует отвергать одну версию над другой? Какая польза от энциклопедии, которая перевешивает сбои, вызванные прекращением поддержки давно существующей и широко используемой функции? Почему бот должен быть свободен и продолжать выполнять работу, по которой у него нет консенсуса? Тридуульф ( разговор ) 14:22, 11 марта 2021 (UTC)
    Здесь мы пытаемся достичь консенсуса, верно? Я поддерживаю стандартизацию ссылочных тегов и не думаю, что у оппонентов есть веские контраргументы. Буду признателен, если вы позволите мне (и другим) высказать наше мнение без необходимости комментировать - вы не «правы», и мы не «неправы». SportingFlyer T · C 15:01, 11 марта 2021 г. (UTC)
    Я не пытаюсь помешать людям высказывать свое мнение. Я пытаюсь заставить людей объяснить их и фактически опровергнуть аргументы, объясняющие предпочтения, отличные от их собственных. Почему стандартизация ссылочных тегов важнее, чем причины нарушения стандартизации? Почему желание избежать этого разрыва «плохой контраргумент»? Я могу быть или не быть «правым», но если вы не можете объяснить, почему принудительная стандартизация вопреки желанию очень значительного числа редакторов (которые не увидят никакой выгоды от такой стандартизации, но будут испытывать значительные постоянные нарушения из-за нее) в какой-то степени желательна. тогда нет никакой надежды на достижение консенсуса в отношении ваших взглядов. Тридуульф ( разговор ) 16:02, 11 марта 2021 (UTC)
    Вы упрекаете меня за то, что я не возражаю против вашего аргумента, хотя ваш аргумент выше просто «Я не вижу в этом смысла». Мы работаем над этим некоторое время, это обсуждалось на страницах обсуждения, это упрощает ведение энциклопедии, и это хорошая идея, чтобы закончить проект, а не откладывать его на потом пользователей, которым это не нравится. . Я также думал, что просто голосую здесь, я думаю, что это очевидно, и я не хочу втягиваться в долгие споры по этому поводу, поэтому я не только не оценил ваш ответ, но и был бы признателен, если вы оставите это только разговор идет вперед. SportingFlyer T · C 16:49, 11 марта 2021 г. (UTC)
    Как и в случае со многими из этих типов вопросов, вывод, который делает каждый человек, во многом зависит от того, какое значение они придают относительным приоритетам различных факторов. Мы излагаем наши аргументы с учетом компромиссов, и другие могут использовать их, если хотят выяснить, какие компромиссы они хотели бы пойти. isaacl ( разговор ) 17:13, 11 марта 2021 (UTC)
  • Вариант C Если нет проблемы с ботами, которые должны читать accessdate и access-date как одно и то же (и, похоже, нет проблемы из того, что было описано, поскольку боты могут это делать), то я не уверен, что принуждение Пользователи, которые уже записывают accessdate для совершения ошибки, когда они продолжают делать это после того, как его использование остановлено, что боты будут затем отмечать, чтобы люди могли решить, будет полезно сделать. Создание ситуации, которая расстроит и демотивирует добровольцев без уважительной причины, кроме «соответствия», не похоже на хороший план. Действительно, в исходном RfC 2014 года подчеркивалось, что «Установление этого единого соглашения об именах параметров не исключает существования любого другого псевдонима для параметра, просто для каждого параметра будет существовать версия с переносом в нижнем регистре».И некоторые из тех, кто поддерживает, сделали это, потому что: «Это значительно уменьшит путаницу редактора. Им не нужно думать о:» Это параметр, в котором слова собраны вместе, или это тот параметр, в котором они разделены знаком '_ '? «Надеюсь, это упростит использование шаблонов». - Пользователь: Макиен . Нам следует обратить внимание на то, чтобы боты читали различные способы, которыми пользователи могут написать слово или фразу в шаблоне. Я ненавижу, когда, например, я по ошибке использую заглавную букву, а шаблон не работает, и мне нужно разобраться, в чем проблема. Я не слежу за тем, как расстраивает, демотивирует и отталкивает добровольцев, изменяя принцип работы шаблона и создавая им проблемы, чтобы «уменьшить бремя обслуживания» для этих пользователей. Иногда такие вещи, как изменение функциональности, отталкивают пользователей. SilkTork ( разговор ) 01:09, 12 марта 2021 (UTC)
  • Вариант C . Я не проверял, был ли этот перенос сделан в рамках RFC шестилетней давности с семью людьми или в рамках RFC семилетней давности с шестью людьми. Но никто не оспаривал, что это был RFC не менее шести лет с участием не более семи человек. Сейчас, похоже, есть большое количество пользователей, которые не согласны. Возможно, сказав им, что они «не видят более широкой картины», будет достаточно, чтобы заставить несогласных замолчать. Может быть, снова повторится «прием Визуального редактора». Кто знает будущее? Pldx1 ( обсуждение ) 15:07, 12 марта 2021 (UTC)
  • Вариант А . Я не вижу реальных аргументов в пользу того, почему шаблоны цитирования должны представлять собой мешанину из двух разных имен параметров. Это бельмо на глазу, это заноза в заднице, и от этого нет никакой пользы. Есть несколько способов исправить это: чтобы новые имена параметров были интегрированы в каждый инструмент, каждую смежную задачу и каждый инструмент автоматического редактирования, и тогда, возможно, через десять лет 90% из них исчезнут (но оставшиеся 10 % будет волей-неволей разбросан по всему проекту и его невозможно будет выследить). Или мы могли бы просто сделать один короткий пробег и покончить с этим. Я, со своей стороны, был бы рад, если вопрос будет решен. jp × g 05:33, 15 марта 2021 г. (UTC)
    Вы действительно подготовили какие-либо комментарии, оставленные другими? Существует по крайней мере полдюжины различных причин полезности нескольких форм параметров. Даже если выбран вариант А, нарушение работы не будет краткосрочным, а будет продолжаться годами по причинам, неоднократно объясненным в другом месте на этой странице. Тридуульф ( разговор ) 12:27, 15 марта 2021 (UTC)
  • Вариант А . Со временем мы развиваем разные условности. Как только мы это сделаем, нам нужно очистить использование старых соглашений. Вариант B будет слишком медленным, и этот вопрос будет затягиваться еще много лет. Итак, во-первых, убедитесь, что вся документация недвусмысленно описывает использование только новых имен. Во-вторых, убедитесь, что все инструменты редактирования используют только правильные имена параметров и все правила genfix обновлены. Подождите, пока бот завершит полный проход, а затем обработайте старые имена параметров как твердые ошибки - GhostInTheMachine поговорит со мной 15:36, 15 марта 2021 г. (UTC)
  • Вариант C . Энциклопедия должна вестись для читателей и, при условии, для выгоды редакторов. Создание занятой работы и случайных условностей ради этого бесполезно. Stifle ( разговор ) 10:19, 16 марта 2021 (UTC)

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

Некоторые предложения по опциям:

  • Педантизм: «Параметры без переноса» следует читать «Параметры, состоящие из нескольких слов без переноса» во всех трех вариантах. Параметры, содержащие только одно слово или аббревиатуру, не нуждаются в дефисе.
  • В варианте C нет смысла предполагать, что «список устаревших параметров необходимо обновить, чтобы удалить параметры без дефиса»; в затронутых пространствах имен не осталось экземпляров этих устаревших параметров, поэтому поддержка для них будет вскоре прекращена, так же как уже была удалена поддержка для десятков параметров, состоящих из нескольких слов, без дефисов.

Немного истории и обновления статуса для тех, кто здесь, на VPP, незнаком с долгой историей обновлений и изменений шаблонов Citation Style 1 ({{ cite web }} и его братьев и сестер): насколько я могу судить, их всего шесть unhyphenated параметры несколько слов слева - |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, и|origyear=- из первоначального населения многих десятков. До сих пор, благодаря работе множества редакторов и ботов за семь лет, прошедших с тех пор, как мы стандартизировали расстановку переносов для многословных параметров, мы устарели, удалили со страниц в затронутых пространствах имен, а затем удалили из самих шаблонов CS1 (как предлагает WhatamIdoing выше), множество десятков различных параметров из нескольких слов без дефиса в шаблонах CS1 / CS2. Все новые параметры, состоящие из нескольких слов, за это время вводились только с использованием дефисной формы. Этот RFC, по сути, задает вопрос: должны ли мы завершить работу или оставить ее выполненной более чем на 90% в своего рода неопределенном состоянии с шестью параметрами в качестве исключений из общего шаблона только потому, что эти параметры используются во многих статьях? - Jonesey95 ( разговор) 04:38, 11 февраля 2021 (UTC)

  • Проблема с «Вариантом Б»: Вариант Б - это не статус-кво. Если бы это было так, я был бы намного счастливее. Поскольку это не так, я не знаю, голосовать за A или за B. В документации на сайте Cite , например, нет упоминания о том, accessdateчто она устарела. Это означает, что пользователи будут вполне оправданы в блаженном добавлении и чтении шаблонов с помощью accessdate, даже после того, как бот уже прошел и изменил accessdateна access-dateв 20 местах. Каждая итерация имеет тенденцию обращаться к меньшему количеству экземпляров, но каждый запуск - это отдельная запись в моем списке наблюдения. Записи в списке наблюдения, кажется, являются частью жалобы на такого рода работу, поэтому первым шагом должно быть отключение крана у источника, прежде чем тратить энергию на спасение лодки.-  JohnFromPinckney ( разговор ) 06:37, 11 февраля 2021 (UTC)
    • Первое предложение верно; все параметры, состоящие из нескольких слов, за исключением шести, были официально объявлены устаревшими и удалены. Что касается «отключения крана в источнике», это был бы вариант А, но в прошлом, когда мы делали красные сообщения об ошибках, появляющиеся в большом количестве статей в качестве первого шага к стандартизации шаблонов цитирования и замечанию ошибок в них. , был значительный отпор. Чтобы избежать этого отката, бот исправил более 90% нестандартных параметров перед включением сообщений об ошибках, но эта работа также была остановлена. Вариант А позволит завершить эту работу. - Jonesey95 ( разговор ) 15:09, 11 февраля 2021 г. (UTC)
      • Я чувствую, что мы не понимаем друг друга. «Устарение» предполагает общение в качестве первого шага; удаление - это второй, более поздний шаг. Если мы хотим, чтобы бот менял страницы ( например , accessdateна access-date), вызывая некоторое беспокойство у населения (и это статус-кво), то мы должны, по крайней мере, изменить документацию, чтобы сказать, что accessdateона устарела и не годится для использования. псевдоним. Я категорически против того, чтобы бот менял параметры на «хорошие» имена, когда мы никогда не говорим людям, что они не должны использовать «плохие» имена. Это просто бесконечный цикл правок, загромождающих списки наблюдения, вызывающих сильное раздражение. Если вы хотите избежать возражений, скажите людям, чтобы они не использовали версии без дефисов,тогдазапустите бота, а через некоторое время удалите поддержку. -  JohnFromPinckney ( разговор ) 15:41, 11 февраля 2021 (UTC)
        • Устаревший с точки зрения шаблонов CS1 означает выдачу красного сообщения об ошибке, указывающего на устаревание. Когда мы выдаем какие-либо красные сообщения об ошибках для часто используемых параметров в CS1 (или их отсутствие для параметров, которые следует использовать чаще), многие люди становятся очень раздраженными. Мы не меняем документацию, чтобы указать на устаревание, до тех пор, пока модуль не начнет сообщать людям об устаревании. Так что да, вы не понимаете друг друга, но это вопрос искусства. - Изно ( разговор ) 16:44, 11 февраля 2021 (UTC)
          • Почему люди сердятся? Потому что внезапно миллионы читателей переходят от того, что все в порядке, к появлению множества красных сообщений об ошибках в сотнях тысяч статей (и нельзя было всерьез ожидать, что кто-то отладит ошибку CS1 в качестве своего первого вклада). Эти шаблоны цитирования не для нас. Они предназначены для читателей, и они должны быть функциональными и обеспечивать низкий уровень сообщений об ошибках 24/7 без исключения, потому что даже небольшие простои наносят значительный ущерб репутации. - Билорв ( разговор ) 02:54, 15 февраля 2021 (UTC)
            • Я был бы более сочувствующим такому аргументу о «значительном ущербе репутации», если бы на них не было более 100 000 страниц с активными ошибками (и это без учета скрытых ошибок Категория: CS1: отсутствует периодическое издание ) и еще 250 000 в его сестре (также скрытый). - Изно ( разговор ) 20:22, 15 февраля 2021 (UTC)
      • То, что «мы» (кто это, какой-то класс супертехнологов, чье мнение имеет гораздо большее значение, чем мнение нас, «обычных» редакторов?) Получаем значительный отпор при создании сообщений об ошибках, - это просто демонстрация, с которой не согласны более широкие круги сообщества. что «мы» решили. Ответ - перестать делать то, что делаешь, а не делать это более скрытно. Фил Бриджер ( разговор ) 18:37, 11 февраля 2021 (UTC)
        • Приглашаем вас принять участие в Help talk: CS1 , как и любой другой редактор. Решения там принимаются консенсусом, в соответствии с тем, как консенсус практикуется повсюду в вики. Не нравится решение, которое приняли «мы»? Увлекаться. - Изно ( разговор ) 18:42, 11 февраля 2021 (UTC)
          • Я не видел абсолютно никакого обсуждения удаления поля редакторов свободного текста на странице обсуждения. Где это произошло? Я не думаю, что это совпадение, что все редакторы, имена которых я хорошо знаю по созданию / редактированию контента, голосуют B / C, а все редакторы, голосующие A, - это те, кого я вообще не узнаю. Espresso Addict ( разговор ) 20:08, 11 февраля 2021 (UTC)
            • Разница между теми людьми, которые думают, что это энциклопедия, и теми, кто думает, что это игровая площадка для технарей. Фил Бриджер ( разговорное ) 20:43, 11 февраля 2021 (UTC)
              • Вашему ad hominem здесь не рады. Продолжайте, если это лучшее, что вы можете предложить для обсуждения. - Изно ( разговор ) 20:47, 11 февраля 2021 (UTC)
                • Это как раз тот ответ, который люди, которые здесь создают энциклопедию, обычно получают от технарей. Никакого ответа на искренние опасения, а только приказ «двигаться дальше». У меня нет желания отслеживать, какие страницы используются для игнорирования конечных пользователей, но я имею право ожидать, что любые принимаемые решения будут уважать интересы всех, а не только самозваной группы людей, которые «знают», что правильно. Фил Бриджер ( разговор ) 19:53, 15 февраля 2021 (UTC)
                  • Это своего рода ответ людям, которые без нужды создают категорию A и категорию B, а затем выстраивают себя в ту или иную категорию. Если вы (конкретное / личное) не хотите отслеживать какие-либо страницы, это ваша прерогатива. Знайте, что это ваш выбор, и вы несете ответственность за этот выбор, и этот выбор имеет последствия. Об изменениях всегда объявляют заранее, и консенсус ищется в отношении неочевидных изменений (и даже очевидных изменений с неочевидными реализациями), поэтому у вас нет оправдания, чтобы не настраиваться хотя бы раз в пару месяцев, когда обычное «Дерьмо меняется» "сообщение сделано. Во-вторых, пугающие цитаты не указаны ни в этом обсуждении, ни в каком-либо предыдущем обсуждении, которое я вижу, вообще. Я не видел ни одной такой «клики», ни кого-либо из пользователей, которые в перспективе могли бы оказаться в такой группе.клика заявляет, что они «знают», что правильно. Как я уже сказал, если вам нечего внести, кроме клеветы, нападок и разногласий, двигайтесь дальше. -Изно ( разговорное ) 20:22, 15 февраля 2021 (UTC)
            • В обратном хронологическом порядке: патч примечание , указывающее на удаление , обсуждение проблемы , заметки патча , указывающие устаревании , устаревание обсуждение . 4 раза упоминалось в течение полугода на той странице обсуждения, ранее существовавшая категория обслуживания, указывающая на мягкое устаревание, и мое удаление более 4k экземпляров параметра в течение полутора лет, предшествовавших обсуждению устаревания. В основном вручную ( моя рука, как бывает). - Изно ( разговор ) 20:45, 11 февраля 2021 (UTC)
            • Что касается, я не думаю, что это совпадение, что все редакторы, имена которых я хорошо знаю по созданию / редактированию контента, голосуют B / C, а все редакторы, голосующие A, - это те, кого я вообще не узнаю. , Я приглашаю вас так же, как и Фила Бриджера. Вы можете смотреть и редактировать Help talk: CS1 в любое время, как и я. «Я не узнаю этих людей» - это пустая ассоциация, и это тот же вид рекламы, который я так любезно просил у Фила прекратить нанимать. Конечно, этого недостаточно, чтобы сказать: «Мне не нравится это изменение». - Изно ( разговорное ) 20:49, 11 февраля 2021 (UTC)
              • Я думаю, что здесь настоящая проблема в том, что существует разрыв между редакторами, поддерживающими шаблоны цитирования, и редакторами, использующими их для написания и поддержки статей. Я не принял решение легкомысленно отказываться от многолетнего использования шаблонов цитирования (на самом деле CS2, но и там происходят те же изменения параметров, даже менее объявленные). Espresso Addict ( разговор ) 21:35, 11 февраля 2021 (UTC)
                Разрыв реальный и значительный. Кому-то, чьи навыки и интерес состоят в написании или поддержании содержания статьи, не нужно заботиться о том, что происходит на таких страницах, как Help talk: CS1 (и как, черт возьми, новый редактор вообще должен знать, что эта страница существует?), Не говоря уже о том, чтобы иметь обращать внимание на обсуждения там. Те, кто действительно заботится о механике шаблонов, всегда должны действовать таким образом, чтобы на первое место ставили читателей, на втором месте редакторы и на третье программисты. Только раз должна когда - нибудь разорвать изменения или потребность в косметических правок, когда после детального обследования не буквально нет доступных альтернатив. Мы оказались здесь, потому что этого не происходило, и местный консенсус игнорировал потребности конечных пользователей. Thryduulf ( разговор) 01:38, 12 февраля 2021 (UTC)
                Вчера вечером я почти прокомментировал, а затем поместил эту версию в текстовый файл и лег спать. Теперь я был побужден комментарием выше, чтобы ответить здесь. Редакторы, использующие эти шаблоны для написания и поддержки статей, такие же, как редакторы, поддерживающие шаблоны цитирования. Продумайте это в своей голове. Если мы отдаем предпочтение различным качествам по сравнению с этой другой предполагаемой отдельной группой, то это потому, что у нас есть для этого опыт. Если вы этого не сделаете, позвольте мне повторить, принимайте участие. Подойдите и скажите «Мне это не нравится» или «Это болезненное взаимодействие» или X, Y и Z, и предложите предлагаемое решение. Вот так начинает формироваться консенсус, как и любая другая страница или процесс на этом веб-сайте. Другие скажут: «Я не хочу, чтобы это работало так, как предложено исправление из-за A, B и C».Затем вы обсуждаете компромиссы и принимаете решение. Если вы не желаете выступать и обсуждать сокращения бумаги, то в конечном итоге мы получим массовые RFC или драму AN, или что у вас есть по поводу того, что в противном случае было бы небольшими проблемами или теми, которые можно было бы неформально обсудить с обычными "давайте разберемся вне "консенсусного взгляда на мир". Это тоже несоответствие, и обвинять редакторов, заинтересованных в одной странице, по сравнению с явно незаинтересованными - неправильный способ двигаться вперед. Хотите, чтобы что-то было лучше? Просить. Предлагаю. Кайоул. Приложите усилия, чтобы продемонстрировать минимальное социальное взаимодействие, необходимое для начала обсуждения в одном месте, где обсуждается все, что касается этого предмета. Мы все добровольцы, и наше сердце находится в нужном месте, как и ваше, но если у нас возникнут разногласия,затем мы разговариваем друг с другом и выясняем, как решить проблему, или соглашаемся не соглашаться по интересующим вопросам. Не иметь постоянных жалоб на то, что «меня не слушали».Консенсус - это не единодушие .
                Только раз должна когда - нибудь разорвать изменения или потребность в косметических правок, когда после детального обследования не буквально нет доступных альтернатив. Откровенно говоря, это мнение, не имеющее какого-либо консенсуса в сообществе. Недавно мы одобрили RFC, разрешающий косметические правки на регулярной основе, и, судя по тому, что я мог видеть в этом обсуждении (и бормотании в другом месте), косметические правки могут быть ближе к достижению консенсуса, чем нет, это просто инерция, из-за которой мы не выполняем их регулярно . Более того, сотни шаблонов и, конечно же, все те, которые проходят через WP: TFD, применить процесс, который вызывает критические изменения или приводит к более или менее косметическим правкам. Вы утверждаете, что у TFD нет консенсуса как процесса? Какие шаблоны, которые очищаются из-за обсуждения страницы обсуждения на странице обсуждения этого шаблона, должны быть остановлены? Вы хотите, чтобы ваш торт (не заботился о том, как все работает), тоже съел его (чтобы все ваши мнения и утверждения были выслушаны, когда они даже не сформулированы в первую очередь). Будьте реальными. - Изно ( разговор ) 20:22, 15 февраля 2021 (UTC)
                Боюсь, это просто демонстрирует правду того, что пишет Тридюульф . «Редакторы, использующие эти шаблоны для написания и поддержки статей, такие же, как редакторы, поддерживающие шаблоны цитирования. Продумайте это через свою голову». самоочевидно ложно, а также невежливо. Говоря только о себе, на самом деле я хочу иметь возможность писать и улучшать статьи, а не вести долгие сторонние дискуссии по вопросам, которые не имеют прямого отношения. Espresso Addict ( разговор ) 00:10, 16 февраля 2021 (UTC)
                продолжайте писать и улучшать статьи. Тогда сделайте это. Никто не мешает вам не заботиться. Я просто называю вас лицемером за то, что вы поднимаете шум, когда вы этого не делаете, а затем в других местах происходят изменения, которые влияют на вас. Не нравится? Измени свое поведение. (Я больше не буду тебе отвечать.) - Изно ( разговор ) 00:34, 16 февраля 2021 (UTC)
                Редакторы, использующие эти шаблоны для написания и поддержки статей, такие же, как редакторы, поддерживающие шаблоны цитирования. Продумайте это в своей голове.Оба невежливые и даже близко не подходящие. Хотя возможно, что некоторые, а может быть, и многие редакторы, поддерживающие шаблоны, также пишут и поддерживают статьи, буквально сотни редакторов пишут и поддерживают статьи, которые никогда не были близко к обсуждению кода шаблона, не говоря уже о написании какого-либо кода. Написание энциклопедической прозы и написание компьютерного кода - очень разные навыки; никто не обязан делать и то, и другое. Однако, учитывая, что цель этого проекта - написать энциклопедию, все, что не является написанием энциклопедии, должно быть сделано в интересах (в первую очередь) читателей энциклопедии и (во-вторых) тех, кто пишет и поддерживает энциклопедию. Наименее важно удобство тех, кто имеет дело с инструментами. Thryduulf ( разговор) 00:23, 16 февраля 2021 г. (UTC)
                Написание энциклопедической прозы и написание компьютерного кода - это ложная дихотомия и явное искажение того, что я должен был сказать в двух абзацах. Я не просил вас делать и то, и другое. Я также не служу вам (в целом) в вашей предполагаемой роли автора статьи. В этой энциклопедии нет (формальных) иерархий, и даже считать себя якобы выше меня или моих усилий является фактическим нецивилизованным заявлением. Наконец, я полностью помещаю себя в обе предполагаемые группы, учитывая тысячи статей, в которых я улучшил их цитирование. (И как я сказал Espresso, я больше не буду отвечать в этом разделе.) - Изно ( разговор ) 00:34, 16 февраля 2021 г. (UTC)
                Моя роль здесь не в качестве автора статей (я делаю это очень мало), я трачу большую часть своего времени на проект, пытаясь убедиться, что читатели могут найти контент, который они ищут, и те, кто пишет и улучшает статьи без необходимость беспокоиться о подобной чепухе, которая без нужды усложняет их работу. Формальной иерархии может и не быть, но она должна быть: (1) Читатели на голову выше всех. (2) Те, кто пишет и поддерживает энциклопедию, намного выше (3) Те, кто поддерживает тех, кто пишет и поддерживает энциклопедию, намного выше (4) Те, кто препятствует чему-либо из вышеперечисленного. Я помещаю себя в третью категорию вместе со многими из тех, кто поддерживает шаблоны. Тридуульф ( разговор ) 21:02, 16 февраля 2021 (UTC)
  • Комментарий . В чем преимущество шаблонов цитирования? Не говоря уже об увеличивающейся ползучести, делающей их все более и более жесткими, более твердыми и сложными в использовании? Единственная причина, которую я вижу, - это упростить экспорт и продажу данных. Кажется, никто и не думает о тех, кто набирает цитаты вручную; Намного труднее набрать «дату доступа» (для чего нужны две руки и движение руки), чем «дата доступа» (одна рука, нет движения). Я вообще не понимаю, в чем польза от этого изменения. Фактически, расширяя эту дискуссию, я не понимаю, почему в январе этого года внезапно было закрыто поле для редакторов свободного текста. Лично я решил учесть последнее изменение, вернувшись к написанию ссылок вручную, что проще, гибче и, похоже, не имеет недостатков.Эспрессо-наркоман ( разговор) 07:04, 11 февраля 2021 (UTC)
    • Шаблоны цитирования значительно упрощают стандартизацию стиля цитирования и упрощают внешний вид. Например, они могут автоматически стандартизировать отображение даты. Машиночитаемость - это тоже хорошо, имо. Я полагаю, что дату доступа немного сложнее набрать, но редакторы, редактирующие викитекст вручную, вероятно, не будут возражать. В противном случае инструменты для вставки этих цитат существуют. Elliot321 ( Обсуждение | вклад ) 17:12, 11 февраля 2021 (UTC)
      • Печатать это не немного сложнее, это намного сложнее печатать слепым наборщиком. И вот редактор, редактирующий викитекст вручную, который не возражает, достаточно, чтобы ответить здесь. Я не знаю инструмента, который бы создавал код шаблона цитирования в той форме, которую я предпочитаю для облегчения последующего редактирования викитекста; все они создают «суп» кода, исправление которого занимает больше времени, чем повторный ввод. Espresso Addict ( разговор ) 20:08, 11 февраля 2021 (UTC)
        Немного медленнее, да, но лично мне это не кажется намного сложнее - слепые машинистки обычно много практиковались в этом во время обучения. Тем не менее, я не думаю, что простота набора по какой-либо метрике является главной проблемой. isaacl ( разговор ) 20:40, 11 февраля 2021 (UTC)
        Как один из тех машинистов слепого набора и как человек, который научился печатать на настоящей пишущей машинке, я не считаю, что печатать версию с дефисом труднее, и я вспоминаю, как мой учитель по машинописи говорил, что это было быстрее и легче. набирайте слова, которые были равномерно разделены между руками, а не все в одной руке. WhatamIdoing ( обсуждение ) 22:49, 11 февраля 2021 (UTC)
        Да, лично я полагаю, что это имеет больший эффект для машинистки, которая набирает обороты. Когда я сказал немного медленнее, я подумал о сравнении со словом такой же длины, состоящим только из букв. Конечно, в этом случае имя через дефис имеет еще один символ, который для меня будет составлять большую часть разницы. isaacl ( разговор ) 23:02, 11 февраля 2021 (UTC)
        Для меня проблема не в обычной клавиатуре, а в планшете. Опять же, на планшете так много боли ... · · · Питер Саутвуд (разговор) : 05:39, 2 марта 2021 (UTC)
      • Сам использую шаблоны цитирования, но уважаю пожелания тех, кто предпочитает их не использовать. Именно тот факт, что я их использую, приводит меня к мнению, что очевидные синонимы для параметров не следует удалять, как это предлагается здесь. В чем, черт возьми, проблема с разрешением как дефисных, так и неразборчивых форм? Все, что это означает, - это несколько дополнительных байтов памяти и никакого дополнительного кода, если все сделано правильно. И работа уже проделана, но это предложение ее свести на нет. Живем ли мы по-прежнему в те дни, когда я начал работать в ИТ в одной из ведущих мировых компаний по бизнес-информации, чьи операции в Великобритании велись с компьютера с 1 МБ памяти и где все онлайн-программы были ограничены 12 КБ? Я думал, что мы двинулись дальше. Фил Бриджер ( разговор) 20:34, 11 февраля 2021 г. (UTC)
        Мне вспоминается история о женщине, которая (несколько десятилетий назад) купила большой запас персональных канцелярских принадлежностей, а затем обнаружила, что почта переименовала ее улицу. Она убедила местного почтмейстера разрешить ей продолжать пользоваться старым адресом до тех пор, пока ее канцелярские принадлежности не закончатся. Это сэкономило ей деньги и усилия, но потребовало внешних затрат. В течение многих лет каждый почтальон должен был знать, что «123 Main Street» находится не на Main Street и не под номером 123, а вместо этого должна быть доставлена ​​в другой конец города.
        Псевдонимы часто дешевы с точки зрения хранения и вычислений, но на самом деле они не бесплатны. «Несвободно» может стоить довольно много, если его повторять миллион раз. WhatamIdoing ( обсуждение ) 22:56, 11 февраля 2021 (UTC)
  • Хотя я симпатизирую желанию, чтобы все шаблоны соответствовали одному стандарту (с точки зрения пользователя, мне лично было бы проще), я просто не думаю, что это возможно в данный момент. В этом случае я сочувствую тем, кто считает, что компьютеры должны облегчить нашу жизнь, и просто принимаю оба формата. С третьей стороны, с точки зрения разработчика, я понимаю, что это добавляет много шума в синтаксис шаблона, если не реализовано с помощью модуля Lua. Поскольку шаблоны на основе CS1 реализованы с помощью Lua, накладные расходы могут быть минимизированы, и поэтому я думаю, что оба формата должны поддерживаться. Я не считаю, что массовое преобразование каким-либо механизмом дает много преимуществ. isaacl ( разговор ) 20:40, 11 февраля 2021 (UTC)
  • Pinging некоторые предыдущие участники связанных с разговорами , которые могут быть еще не знают об этой дискуссии: @ SandyGeorgia , Джейсон Куинн , Oknazevad , Tom.Reding , Brainulator , Дэвид Брукс , SMcCandlish , Дэвид Eppstein , Matthiaspaul , Headbomb , Gracefool , Ss112 , JG66 , Mikeblas , Gonzo fan2007 , Сариэль Xilo , скромный гений , и SlimVirgin : . Никкимария( разговор ) 01:17, 12 февраля 2021 (UTC)
    Спасибо за пинг, я действительно не знал об этом обсуждении. Скромный Гений говорить 12:16, 12 февраля 2021 (UTC)
  • Есть ли у кого-нибудь доказательства того, что наличие псевдонима для параметров усложняет задачу для конечных пользователей? По моему опыту как тренера и давнего пользователя, наличие нескольких способов достижения одних и тех же целей позволяет редакторам тратить свое время и энергию на работу над контентом, а не ломать голову над тем, чтобы параметры шаблона были названы правильно. Я никогда не встречал никого, кому было бы достаточно удобно иметь дело с шаблонами в первую очередь, кого не вполне устраивала бы идея о том, что «вы можете записать это либо как access-date, либо как accessdate, это не имеет значения». (или похожие). Говоря лично, я не хочу знать, является ли это «дата доступа», «дата доступа», «дата_доступа» или «дата доступа»,Я просто хочу, чтобы все они были приняты, чтобы какой бы я ни вводил шаблон, он работал, и я мог беспокоиться о более важных вещах.Тридуульф ( разговор ) 01:29, 12 февраля 2021 (UTC)
    Несоответствие между всеми шаблонами действительно усложняет задачу. Пользователи должны либо помнить, какие шаблоны поддерживают только одну форму, а какие, либо искать ее каждый раз. Однако я понимаю, что существует дополнительная сложность в попытке поддерживать множество псевдонимов, особенно для тех, которые не реализованы с модулем Lua (либо каждое использование станет более сложным и подробным, либо шаблон может делегировать подробную реализацию на вспомогательный шаблон, причем верхний уровень выполняет только нормализацию параметров), поэтому лично я не хотел бы требовать, чтобы каждый шаблон поддерживал псевдонимы. Таким образом, я думаю, что мы застряли в непоследовательности. isaacl ( разговор ) 02:12, 12 февраля 2021 (UTC)
    Это несоответствие следует терпеть. Некоторые, особенно часто используемые, шаблоны с псевдонимами важны для большого числа людей, использующих эти шаблоны. Им не нужно вспоминать, было это |access-date=или |accessdate=. Если это не сработает с каким-то другим шаблоном, хорошо. Но устранение псевдонимов и простое заставление компьютера отказываться от всех шаблонов значительно усложняют задачу для подавляющего большинства пользователей. Это неудобство намного больше, чем тот факт, что несколько редко используемых шаблонов не поддерживают псевдонимы, и вам может потребоваться иногда взглянуть на документацию. -  Finnusertop ( обсуждение ⋅ вклад ) 06:05, 12 февраля 2021 г. (UTC)
    Да, как я сказал в другом комментарии, я считаю, что обе формы должны по-прежнему поддерживаться для шаблонов на основе CS1. Я почти уверен, что подавляющее большинство шаблонов не поддерживает параметры как с переносом, так и без него - например, из того, что я могу сказать из кода и быстрого теста, {{ Infobox }} не поддерживает. Именно так и происходит, когда вы пытаетесь сделать как можно больше аспектов разметки Википедии доступным как можно большему количеству редакторов: стандартизация не всегда происходит, и часто более простая разметка будет предпочтительнее для большего числа редакторов, чем более сложная разметка, даже если бы это было добавить больше функциональности для пользователей. isaacl ( разговор ) 22:22, 12 февраля 2021 (UTC)
  • В варианте C нет смысла предполагать, что «список устаревших параметров необходимо обновить, чтобы удалить параметры без дефиса»; в затронутых пространствах имен не осталось экземпляров этих устаревших параметров, поэтому поддержка для них будет вскоре прекращена, так же как уже была удалена поддержка для десятков недифференцированных параметров из нескольких слов. Этот аргумент прямо противоречит WP: FAITACCOMPLI . Кроме того, перестаньте называть их «обесцененными» - очевидно, что не было достаточного консенсуса, чтобы объявить их обесцененными с самого начала. Я понимаю, что это неприятно, когда что-то, как вы думали, было решено вот так развалиться, но это чрезвычайно важно.что радикальные изменения требуют большего обсуждения, прежде чем они будут реализованы; единственный способ, которым мы можем разумно поощрять это, - это отказ в разрешении таких вещей, как использование Monkbot здесь для определения политики, т. е. необходимо , чтобы сделать работу он сделал спорный, или люди будут иметь постоянный стимул принять легкий путь и избежать возиться с отнимающими много времени, часто расстраивает, и непредсказуемое (но необходимое) обсуждения до изменения этой величины. Это означает, что да, позволять и даже поощрять людей возобновлять использование параметров без дефиса, даже если вы думали, что наконец-то с ними покончили; если вы хотите избежать этого в следующий раз, сначала ищите более масштабные обсужденияпрежде чем вносить крупномасштабные изменения, чтобы избежать неожиданной отдачи, если окажется, что у вас нет консенсуса, о котором вы думали. Независимо от того, насколько это было сделано из лучших побуждений, мы абсолютно не можем рискнуть вознаградить использование инструмента для внесения широкомасштабных изменений без достаточного консенсуса - что означает, да, как бы болезненно это ни было, очень сознательно прикладывать гаечный ключ к коленным чашечкам предполагаемое улучшение, которое это изменение должно было установить, и намеренное его разрушение даже после того, как «цена» была оплачена. Это не идеально , но показывает, почему так важно проводить широкие обсуждения с участием многих пользователей, прежде чем вносить широкие изменения; наличие политика, эффективно устанавливаемая ботами, выполняющими массовые правки и устанавливая вещи как свершившийся фактпросто неприемлемо. Я могу посочувствовать тому количеству работы, которая была вложена в это, которая в результате будет потрачена впустую, но достижение четкого, однозначного консенсуса с участием большого количества редакторов должно было быть первым шагом для чего-то такого масштаба, чтобы вы не стали внезапно наткнулся на RFC, подобный этому, и обнаружил, что консенсус не такой, как вы думали. - Аквиллион ( разговор ) 10:07, 4 марта 2021 г. (UTC)

Произвольный перерыв 1 [ править ]

  • Спасибо Nikkimaria за пинг, основанный на моем предыдущем участии. Я ужасно нейтрален (или разорван) по основной теме, но ранее я провел некоторый анализ, который заставляет меня беспокоиться о влиянии, в частности, на пространство шаблонов, если прекращение поддержки полностью продлится. Здесь я буду использовать |authorlink=в качестве прокси для всех шести, потому что лично я набираю чаще. Есть три области , которые касаются меня: шаблоны , которые косвенно Invoke CS1, те , которые transclude CS1-вызова шаблонов и клонов. Меня беспокоит, где и когда появляются красные сообщения об ошибках, а также документация, в которую я включаю и / doc, и TemplateData .
  1. Существует множество шаблонов, поддерживающих CS1, которые вызывают один из канонических шаблонов; Например, часто используется {{ Cite encyclopedia }}. Некоторые используют перезапись параметров, преобразуя их |authorlink=в |author-link=перед передачей.
    1. Всегда ли их документация имеет приоритет |author-link=? Думаю, мы их всех поймали во время предыдущего обсуждения, но я не могу гарантировать качество поиска.
    2. Поскольку код CS1 никогда не видит устаревший параметр, должен ли этот шаблон сам выдавать красную ошибку во время замены? Или, может быть, просто забыть о сопоставлении и пусть CS1 сделает это? А насколько сложно найти шаблоны с кодом подстановки параметров?
    3. Если |authorlink=когда-либо переходит от устаревшего к недействительному , тогда все эти сопоставления и документация должны быть обрезаны одним махом. Что ж, я предполагаю, что сопоставления могут оставаться на месте, хотя они могут сбить с толку невнимательных давних пользователей.
  2. Существуют шаблоны, которые просто включают предварительно заполненный шаблон в стиле CS1: например, встраивание {{ Cite book }} в качестве ссылки на определенный том, имеющий отношение к любому использованию этого шаблона. Все ли они исправлены? В противном случае их пользователь увидит красное сообщение об ошибке (правильно?), Которое не имеет ничего общего с их собственным использованием.
  3. Могут быть шаблоны, смоделированные на CS1, но имеющие собственное расширение, хотя я не знаю ни одного такого. Если они используются |authorlink=, следует ли их также привести в порядок?
Два заключительных комментария: их больше шести, если рассматривать варианты вроде |author1link=и |authorlink1=. И, в принципе, приведенные выше аргументы применимы к любой странице за пределами пространства шаблона, которая кем-то включается, хотя я знаю, что эта функция используется редко. Дэвид Брукс ( разговор ) 16:51, 12 февраля 2021 (UTC)
Надо было сказать: вышесказанное относится к A и в некоторой степени B, но вы, вероятно, сможете это понять. Дэвид Брукс ( разговор ) 16:57, 12 февраля 2021 (UTC)
Дэвид Брукс : Крошечная армия редакторов готова исправить эти шаблоны. Насколько мне известно, не существует подключаемых шаблонов, которые передают |authorlink=ваш пример каким-либо шаблонам CS1, поэтому использование этих шаблонов не приведет к возникновению сообщения об ошибке. |accessdate=и два или три оставшихся без дефисов параметра, передаваемых из включений шаблонов в шаблоны CS1, обрабатывались ботом до того, как бот был приостановлен для проведения этого обсуждения. Как только это обсуждение будет закрыто, бот сможет возобновить эту работу с помощью человека, если закрытие будет разумным. - Jonesey95 ( разговор ) 17:13, 21 февраля 2021 г. (UTC)
@ Jonesey95 : Я только что затронул связанную проблему в справке: Citation Style 1 , где, изменив приведенный пример, я обнаружил 3 шаблона, которые используются |authorlink=в шаблоне в стиле CS1, который используется для ссылки на конкретный источник: {{ Семейное древо Бармакидов }} , {{ Citeer web }}, {{ Alox2 }}. Но этот менее строгий запрос показывает еще несколько (я думаю, игнорируйте архив "DYK"). Не уверен, имели ли вы в виду этот тип использования в своем комментарии; Возможно, мне не хватает контекста. Дэвид Брукс ( разговор ) 05:05, 22 февраля 2021 (UTC)
@ Jonesey95 : Хорошо, похоже, вы починили {{ Alox2 }}. {{ Семейное древо Бармакидов }} и {{ Citeer web }} все еще нуждаются в исправлении (я сделаю их сегодня позже). Документация «Цитировать книгу (краткую)» в {{ Quicktemplates }} перечисляет не-некорректные |authorlink=, так что это подпадает под правило «предпочитать дефисные формы в документации». Я не искал |authorlink2=или |author2link=потому что они вряд ли появятся поодиночке. Дэвид Брукс ( разговор ) 19:17, 22 февраля 2021 года (UTC) ... checkY, а также {{ сочинения Баха (источники) }}, которые действительно были |author2link =. Дэвид Брукс ( разговор) 21:42, 22 февраля 2021 г. (UTC)
  • Я хотел бы пояснить, что я имел в виду, когда изначально писал варианты, поскольку есть некоторая путаница. Мое намерение с «удалением» состояло в том, чтобы ссылаться только на устранение использования непереносимых параметров путем включения шаблона, а не на удаление из реализации самого шаблона (я назову это «отключением параметра»). Это также отличается от устаревания, когда что-то в документации и предупреждающих сообщениях обозначается как не рекомендуется. Помните, что первоначальная причина этого RfC состоит в том, чтобы прояснить, должен ли бот проходить через пространство статьи, удаляя использование параметра в качестве единственного действия. A, B и C соответственно продолжают удаление сейчас, удаляют только как часть других некосметических правок или в ситуации, когда разрешены только косметические правки., или не удаляйте. В случае A или B я не намеревался, чтобы они делали заявление о том, следует ли нам отключать параметр, когда это будет сделано. Это важный вопрос, но он не зависит от того, будет ли использование параметра удалено сейчас или позже. -   Earwig  альт  ⟨ разговор ⟩ 22:11, 13 февраля 2021 (UTC)
    Спасибо за разъяснения (кроме той части, где вы сформулировали варианты). К сожалению, теперь это означает, что мне не хватает опции : параметры без дефиса должны быть устаревшими и удалены позже . Фактический статус - кво , кажется: без дефисов параметры должны быть удалены в настоящее время и осуждаются позже , и удаление может происходить с помощью бота , который не делает ничего другого на странице (косметический только), но вернуться к странице , как часто , как это необходимо для повторных -удалены нерекомендуемые параметры, которые продолжают добавляться. -  JohnFromPinckney ( разговор ), 23:01, 13 февраля 2021 г. (UTC)
    Для контекста, это то , как я первоначально это сформулировал; примечание B и C поменяны местами. Разве не то, что вы хотите, именно вариант Б (в текущей формулировке)? Кажется, что описание B как «статус-кво» сбивает с толку. Вместо этого рассматривайте A как то, что бот делал до того, как он был остановлен, а B как то, что в настоящее время происходит с остановленным ботом, но с явным формальным осуждением. -   Earwig  альт  ⟨ разговор ⟩ 00:19, 14 февраля 2021 (UTC)
    Ммм, может быть, и в любом случае я очень благодарен за вашу ссылку на предварительную координацию RfC на Primefac's Talk . И я могу сказать, что ваша первоначальная формулировка была более ясной, чем формулировка, которую мы сейчас используем для собственно RfC. Тем не мение:
    1. Похоже, что нет единого мнения об удалении многословных параметров без дефиса. 2014 RfC определяется только что дефис версия должна существовать, и близко явно разрешены для не переносит.
    2. Если этот RfC предназначен для определения того, следует ли исключать использование дефисов, он плохо сформулирован, поскольку в нем упоминаются текущие действия ботов.
    3. Я не могу рассматривать вариант А как то, что делал бот до его остановки , потому что этот параметр не устарел. ( Заявление Nikkimaria о том, что прекращение поддержки "в контексте CS1 / CS2" означает, что будет показано красное сообщение обслуживания, я не могу принять, поскольку любой разумный поставщик программного обеспечения знает, что предварительное уведомление является первой частью прекращения поддержки. К сожалению, я обычно не работают «в контексте CS1 / CS2», поэтому раньше не возражали против этого несчастливого определения.)
    4. Вариант B, как написано на этой странице, представляет собой искаженный беспорядок не только из-за упоминания «статус-кво», но также из-за бит «Устарение может быть объединено в генфиксы ...». Упразднение, как указано выше, - это (первая) задача документирования, за которой следует (предположительно небольшой) шаг, вызывающий генерацию красных сообщений (я не уверен, что здесь происходит). Я не вижу, что нужно «связать в генфиксы». У меня было ощущение, что многие! Голосующие здесь рассматривали «удаление» как устранение обычаев, но, возможно, это из-за моего собственного замешательства. Ваш вариант C (и ваши исходные формулировки в целом) были намного яснее.
    Никаких действий ботов никогда не должно было быть, потому что (а) пока нет консенсуса об отказе от дефисов, (б) параметры еще не устарели, и (в) боты в основном редактировали accessdate => access Только дата, поэтому нарушайте WP: COSMETICBOT . Так что я думаю , я буду! Голосование за B, хотя я бы много , а выбрать исходный Вариант C. Этот документ , как написано было слишком неясно (по крайней мере для меня). -  JohnFromPinckney ( разговор ) 11:20, 14 февраля 2021 г. (UTC)
    Re RfC 2014 определил только то, что версия с переносом через дефис должна существовать : как указано в предложении, в документации также указано , что эта версия с переносом в нижнем регистре должна отображаться как версия для «нормального использования» . Отсюда мой комментарий выше: некоторые из нас недавно изменили документацию по нескольким часто используемым шаблонам, чтобы сделать версию с дефисом привилегированной, но я не могу гарантировать, что у нас есть и / doc, и TemplateData для каждого шаблона, который косвенно использует CS1 / 2. . Если в итоге мы получим и дефис, и без дефиса, одинаково допустимые (это C?), То настройка документации будет единственным изменением, видимым текущим редакторам. Можно ли предпринять более смелые усилия, чтобы выследить их всех? Дэвид Брукс ( разговор ) 19:45, 14 февраля 2021 (UTC)
    Если консенсус в пользу варианта C, то никому не нужно ничего отслеживать; мы можем оставить документацию как есть. Кстати, заявление, написанное там, также будет означать, что список устаревших параметров необходимо будет обновить, чтобы удалить параметры без переноса, - это еще одна отвлекающая манера и, похоже, не будет применяться вообще (поскольку accessdate даже не указан там еще нет).
    Если мы выбрали вариант А или Б, то да, документацию нужно немедленно менять. Не могу поверить, что для поиска веб-документации Template: Cite потребуется слишком много мужества , поскольку она не кажется ужасной экзотикой, но в таких случаях ее следует включить в настройку. -  JohnFromPinckney ( разговор ) 20:07, 14 февраля 2021 г. (UTC)
    • В RFC 2014 года приняли участие всего семь человек, это было шесть или семь лет назад. Терпеливо абсурдно обновлять документацию таким радикальным изменением только на основе этого, и любые такие изменения должны быть отменены в ожидании результатов более четкого RFC. Кроме того, в RFC 2014 года конкретно указано, что ничего не будет обесцениваться, поэтому, если вы полагаетесь на него как на оправдание каких-либо изменений, очевидно, что никакие версии без дефисов не могут быть обесценены до тех пор, пока / если новый RFC не отменяет их. - Аквиллион ( разговор ) 22:19, 15 февраля 2021 (UTC)
    Пожалуйста, прочтите резюме в верхней части этого раздела обсуждения. Вот краткое изложение этого резюме: Десятки параметров, состоящих из нескольких слов, без дефисов были объявлены устаревшими, удалены со страниц, а затем удалены из шаблонов Citation Style 1 за последние семь лет. Осталось всего шесть. За эти семь лет было введено много новых параметров, состоящих из нескольких слов, без дефисов. В настоящее время ситуация такова, что параметры, состоящие из нескольких слов, без дефиса являются стандартом, и осталось немного поработать, чтобы удалить последние шесть выбросов. К сожалению, похоже, что многие редакторы не включили полезные настройки «Развернуть список наблюдения, чтобы отображать все изменения, а не только самые последние» и «Группировать изменения по страницам в последних изменениях и списке наблюдения».чтобы правки ботов можно было скрыть, не теряя при этом видимости плохих правок, сделанных людьми, поэтому люди жалуются на то, что бот «забивает» их списки наблюдения. -Jonesey95 ( разговорное ) 23:59, 15 февраля 2021 (UTC)
    Однако все это не имеет никакого отношения к комментарию Аквиллиона . То, что в прошлом использовался неубедительный консенсус (в лучшем случае), чтобы оправдать удаление функциональности, не означает, что это удаление было хорошим делом или что бот редактирует (которые засоряют как списки наблюдения, так и истории страниц ненужными правками, скрывают ли они другие правки). или нет) следует продолжать. В самом деле, я сильно подозреваю, что будет поддержка для повторного включения уже удаленных параметров. Тридуульф ( разговор ) 00:27, 16 февраля 2021 (UTC)

Обратите внимание, ребята, что этот бот - разовый ; он может обрабатывать около 2 или 3 миллионов страниц, но он все еще разовый, то есть (если не будет отменен) он будет появляться только ОДИН РАЗ в истории любой статьи. Так что идея о том, что это «засоряет» истории страниц, является большим отвлекающим маневром . Если вас беспокоит, что это «засоряет» ваш список наблюдения, установите параметры, рекомендованные Jonesey95 и другими. Так что и это возражение отпадает. Также обратите внимание, что этот бот завершает работу. Как только это будет сделано, все - больше никаких ботов, вносящих такие изменения. На обвинение в том, что этот бот «нарушает работу» или что он каким-то образом «лишает функциональности», я не могу ничего лучше, чем скопировать вышеприведенное наблюдение Рекса: «После того, как мы стандартизируем параметры с переносом через дефис, будущие редакторы оглянутся назад и подумают, насколько убогим и такого рода дебаты - пустая трата времени ". - NSH001 ( разговор ) 19:30, 21 февраля 2021 г. (UTC)

Кроме этого, нет, это совершенно неточно. Рассмотрим Список людей из Пенсильванского университета . Когда я смотрю на последние 500 правок только сейчас, я вижу , что Monkbot был там семь раз: здесь (21:07, 19 октября 2020) и здесь (1:02, 28 декабря 2020) и здесь (17:21, 14 Январь 2021 г.) и здесь (21:21, 16 января 2021 г.) и здесь (01:53, 18 января 2021 г.) и здесь (15:30, 18 января 2021 г.) и здесь (20:54, 30 января 2021 г.) . Хотя это первое редактирование (от октября) ничего не изменило|accessdate=, остальные все делали, так часто, как находили новые дополнения к статье. Обратите внимание, что пятое и шестое редактирование произошло в один и тот же день .
Обычно я не блокирую редактирование ботов в моем списке наблюдения, потому что я хочу знать, что происходит с «моими» статьями, а боты обычно делают полезную и интересную работу. Просто (для меня) внезапный и непредвиденный поток множества правок (которые, похоже , не делали ничего, что меня действительно интересует) был весьма раздражающим. Повторение в списке людей из Пенсильванского университета действительно подняло мое кровяное давление, и это недалеко от меня "разрушительно". -  JohnFromPinckney ( разговор ) 21:15, 21 февраля 2021 г. (UTC)
Хм ... Октябрьское редактирование - это Monkbot 17 (а не 18), поэтому он не попадает в сферу применения этого RFC. Редакция 28 декабря - основное приложение этого бота. Остается 5 (в основном совсем небольших) неожиданных дополнительных правок ботом. Все они вызваны тем, что редакторы добавляют пармы, не соответствующие каноническому стандарту. Так что да, мне следовало ограничить свое заявление, допустив такую ​​возможность, извините за это. Понятно, что это должно происходить при отсутствии явного осуждения (пока) непереносимой формы. Возможно, заинтересованные редакторы используют какой-то инструмент для создания ссылок, который не генерирует каноническую форму, и в этом случае инструмент следует обновить. Как бы то ни было, это усиливает аргументы в пользу того, чтобы как можно скорее отказаться от неканонических форм и как можно быстрее продвигаться вперед с основной задачей. Уже поздно,и я скоро пойду спать. Прокомментирую несдержанное замечание Фила Биджера утром ниже. -NSH001 ( разговор ) 00:06, 22 февраля 2021 (UTC)
Нет, соответствующий редактор просто копировал / вставлял все, что они находили в любых статьях, которые они просматривали. (Пользователь также не узнал, что ссылки идут после знаков препинания, или что именованная ссылка, скопированная из другой статьи, может не быть объявлена ​​на целевой странице, или что в Википедии есть функция предварительного просмотра, позволяющая проверять ошибки. Не то чтобы я горько.) Согласен, без фактического осуждения, никто не знает, что они должны использовать или не использовать, поэтому списки наблюдения страдают от ненужного повторения. И я не могу указать такому пользователю на осуждение или согласие не использовать формы без дефиса, потому что их еще нет. -  Джон Фром Пинкни ( разговор ) 00:21, 22 февраля 2021 (UTC)
Спасибо за это. Если редакторы на этой странице просто копируют цитаты из исходных биографий вики, то это хорошая новость - проблема исчезнет, ​​если боту просто разрешить продолжить и исправить проблему в исходных статьях. Я не думаю, что это правда, что нет единого мнения по поводу этого изменения: желаемый стиль был установлен в RfC несколько лет назад, и с тех пор был реализован на 90% без существенных возражений. Так что есть действенный консенсус, и нет смысла не доводить задачу до логического завершения. Возражения здесь сводятся к неприязни к большому количеству правок, вносимых ботами в списки наблюдения, а не к фактическим обстоятельствам дела. - NSH001 ( разговор ) 07:34, 22 февраля 2021 г. (UTC)
Рассматриваемый RfC имел только семь опор и касался только того, чтобы версия с дефисом существовала и была представлена ​​первой в документации. Я не знаю, как это можно трактовать как эффективный консенсус для отказа от параметра, который до запуска бота, по-видимому, использовался чаще, чем вариант с переносом через дефис - и даже если бы мог, он был бы ограниченным . Возражение против бота состоит не только в том, что он много редактирует, но и в том, что он «исправляет» то, что не является проблемой. Никкимария ( разговорное ) 14:01, 22 февраля 2021 (UTC)
Именно это. -  JohnFromPinckney ( разговор ) 02:05, 23 февраля 2021 (UTC)
Никкимария, первое заблуждение в вашем аргументе состоит в том, что вы предполагаете, что более широкое сообщество, если бы оно участвовало в первоначальном RfC, не согласилось бы с его выводом. Это не (совсем) случай - я почти уверен, что из различных вариантов, доступных для параметров, состоящих из нескольких слов (runon, camelCase, under_score, переносимость и т. Д.), Расстановка переносов все равно будет выбрана просто потому, что это легче всего читать в вики-тексте. Возможно, подчеркивание может быть лучше (оно не будет переносом строк), но большинству людей, за исключением, возможно, тех, кто имеет опыт программирования, будет гораздо удобнее использовать дефис, так что RfC пришел к очень разумному выводу. Но детали его реализации - другое дело. Вторая ошибка в вашем аргументе касается причины возражения против бота. Во-первых,Наблюдаемый факт заключается в том, что некоторые редакторы сейчас поднимают огромную трату времени на этого бота, но ничего не говорят о том, что многие другие боты запускаются для всех других параметров CS1 / 2, выполняющих то же самое. Во-вторых, и я неоднократно наблюдаю это и в других RFC, редакторы склонны сосредотачиваться исключительно на предполагаемой краткосрочной проблеме, не принимая во внимание более широкую картину и более широкий контекст. Этот контекст уже был хорошо описан во введении к этому RFC и в приведенных там ссылках. Меня удивляет, что люди не видят, что весь смысл этой работы состоит в том, чтобы упростить и упростить использование шаблонов цитирования. Часть этого процесса - сделать имена параметров более значимыми и последовательными. Смешно оставлять беспорядок, унаследованный с первых дней создания шаблонов цитирования.с этими немногими оставшимися параметрами, торчащими, как больные пальцы. -NSH001 ( разговор ) 08:25, 25 февраля 2021 (UTC)
Пожалуйста, объясните, почему разрешение, например, «accessdate» менее значимо, менее просто и труднее использовать для обычных редакторов. Это более широкая картина, более широкий контекст: преимущества на самом деле только для небольшой группы людей, которые имеют полное право изложить свою позицию и спросить, можно ли облегчить их жизнь, но не следует удивляться, когда выясняется, что в некоторых случаях их предпочтительное решение не поддерживается большей группой людей, которые не делают (или не так регулярно) шаблоны и боты. Размещение сообщений об ошибках на тысячах страниц для вещей, которые не являются ошибкой, но что некоторые люди решили, что больше не разрешено вообще, также теряет из виду более широкую картину. Фрам ( разговор ) 09:24, 25 февраля 2021 (UTC)
вы предполагаете, что более широкое сообщество, если бы оно участвовало в первоначальном RfC, не согласилось бы с его выводом . Я этого не знаю, и вы тоже, потому что с более широким сообществом никогда не консультировались . Мы можем быть разумно уверены, что обсуждение было бы гораздо менее односторонним, основываясь на последующих комментариях. Что касается второй части вашего пункта, как отмечает Фрам, совсем не ясно, почему отказ от широко используемых псевдонимов упростит использование шаблонов для обычного редактора. Никкимария ( разговорное ) 13:33, 25 февраля 2021 (UTC)
(отвечая обоим). Да, это просто. Для всех шаблонов цитирования CS1 / 2 существует очень простое правило: все параметры, состоящие из нескольких слов, используют дефис для разделения слов. Вот и все. Мертвых легко запомнить. Причем для подавляющего большинства параметров он уже реализован (осталось сделать только 5). Я не верю аргументу, что необходимость печатать ОДИН дополнительный символ - невыносимое бремя. Единственное веское возражение, которое я вижу, это то, что бот может наводнять списки наблюдения, но это временно, пока запуск бота не будет завершен. Так что мои соболезнования тем, кто чувствует раздражение (у меня нет - в моем списке наблюдения более 6000 страниц, и бот-спам меня не беспокоит), но раздражение будет временным. Если вас это действительно беспокоит, другие уже упоминали способ настройки вашего списка наблюдения, чтобы избежать этой проблемы.- NSH001 ( разговор) 07:35, 8 марта 2021 г. (UTC)
Я рад, что вас лично не раздражает это изменение, но другие раздражают, и другие объясняют, почему скрытие проблемы не решает ее. Никто не предлагает удалить вариант с дефисом, просто поддерживая (часто более широко используемые) псевдонимы. Неуместно оправдывать изменение тем, что оно в основном осуществляется . Никкимария ( разговорное ) 02:49, 12 марта 2021 (UTC)
В списках наблюдения см. # Стоит отметить ниже , чтобы узнать о возможном способе уменьшения "сбоев". Я забыл ответить на замечание Фрама о более широком контексте: я думал об общем соглашении об именах и о том, почему бот упрощает его, но последний вклад Trappist в раздел опроса также объясняет более широкое рассмотрение, которое нам необходимо учитывать во всех несоответствиях. -Английские Википедии, которые позаимствовали наши шаблоны / модули CS1. - NSH001 ( разговор ) 10:40, 8 марта 2021 г. (UTC)
Значит, решение проблемы редактирования бота против консенсуса для тех, кто возражает, чтобы перестать его смотреть? Вы не могли придумать это. Опять же, это долбаная энциклопедия, а не место, где технари диктуют редакторам. Найдите игровую площадку в другом месте или найдите настоящую работу, и вы обнаружите, что люди могут получать деньги за написание программ, только если они делают то, что их пользователи хотят от них. Фил Бриджер ( выступление ) 21:27, 21 февраля 2021 (UTC)
Фил, твое первое предложение неверно. Этот бот был одобрен консенсусом в соответствии со стандартными процедурами. Действительно, его оператор пошел на все, чтобы кричать с крыш, что это «косметический» бот. Я проигнорирую ваши безудержные и беспочвенные личные нападки. Наконец, по вопросу о редактировании ботами и списках наблюдения, я отсылаю вас к сообщению Bilorv в 11:34, 13 февраля, выше, которое выглядит как хорошее решение (я просто добавлю оговорку, что еще не тестировал его). - NSH001 ( разговор ) 08:25, 25 февраля 2021 г. (UTC)

Читая некоторые из приведенных выше комментариев, я испытываю сильное искушение добавить сюда новое предложение: каждый редактор, который намеренно вносит изменение, которое добавляет сообщение об ошибке как минимум на 10 000 страниц, удаляется из своего редактора шаблонов . Конечно, исключая скрытых кошек, это не проблема; но никакое обесценивание какого-либо параметра не оправдывает такое нарушение работы основного пространства для читателей. Фрам ( разговор ) 08:30, 24 февраля 2021 (UTC)

Три ответа: Во-первых, сообщения об ошибках, отображаемые шаблонами CS1, отображаются консенсусом, а не одним редактором. Во-вторых, сообщения об ошибках, такие как те, которые отображаются в статьях в параметре Категория: ошибки CS1: неподдерживаемый , отображаются не потому, что один редактор изменил шаблон, а потому, что отдельные редакторы допустили ошибки при использовании шаблонов CS1. В-третьих, возражение против того, чтобы сообщения об ошибках появлялись в пространстве статьи, объясняется тем, почему бот работал до того, как были отображены сообщения об устаревших ошибках . Люди ненавидят отображение сотен тысяч мелких сообщений об ошибках, поэтому бот исправлял статьи до того, как модули CS1 были изменены для отображения ошибок устаревших параметров.
Однако предложение Fram по обратной связи дает повод задуматься; если здесь выбраны логические параметры A или B, чтобы можно было завершить последние 10% переноса многословных параметров CS1, возможно, нам не следует отображать сообщения об ошибках устаревших параметров (кроме, возможно, в режиме предварительного просмотра) в статьях до тех пор, пока Подавляющее большинство замен имен параметров завершены. - Jonesey95 ( разговорное ) 16:29, 24 февраля 2021 г. (UTC)
Спасибо, но помните Википедию: Доска объявлений для администраторов / Archive313 # Есть ли полуавтоматический инструмент, который мог бы исправить эти надоедливые ошибки "Cite Web"? 1 1/2 года назад? В отношении этого изменения также был «консенсус» среди крошечной группы редакторов, но без учета более широкого сообщества. Я надеялся, что этот эпизод научил некоторых людей, наиболее активно работающих с этими шаблонами, что, когда они предлагают изменение, затрагивающее многие страницы (и, конечно, когда они предлагают изменение, добавляющее сообщения об ошибках на многие страницы), они должны получить гораздо более широкий консенсус. первый. Тем не менее, я вижу в приведенном выше обсуждении людей, которые утверждают, что для этого нужно активировать красные сообщения об ошибках (большинство сообщений об ошибках, которые мы получаем сейчас, либо на очень небольшом количестве страниц, либо о фактических ошибках., например, невозможные даты), что не является ошибкой, но что-то не нравится некоторым операторам ботов и разработчикам шаблонов. Фрам ( разговорное ) 17:06, 24 февраля 2021 (UTC)
Три ответа: Во-первых, сообщения об ошибках, отображаемые шаблонами CS1, отображаются консенсусом, а не одним редактором. Я думаю, что это обсуждение сделало кристально ясным то, что многие из «консенсусов», используемых для внесения таких радикальных изменений, не являются отдаленно достаточными с точки зрения масштаба на WP: LOCALCONSENSUS ; опять же, если бы они были, у нас не было бы этого разговора. Если вы хотите внести изменение, которое существенно повлияет на сотни тысяч страниц, вам понадобится консенсус с участием очень большого количества пользователей, и его следует должным образом транслировать на форумах с высокой посещаемостью - «консенсус» из семи человек терпеливо недостаточно для изменения в этом масштабе, и развернуться и использовать ботов или шаблонных сообщений, чтобы затем попытаться применить это, составляетРГ: ФАИТАККОМПЛИ . - Аквиллион ( разговор ) 10:03, 4 марта 2021 года (UTC)
Я хочу, чтобы люди перестали повторять эту утку о «консенсусе из семи человек»; это слабая платформа для аргументации. Консенсус по поводу параметров, переносимых через дефис, существует уже семь лет и был подкреплен многочисленными дискуссиями об устаревании десятков отдельных параметров, состоящих из нескольких слов, в течение этих семи лет. Страница обсуждения, на которой происходило каждое из этих обсуждений, Help talk: Citation Style 1 , имеет 396 наблюдателей. - Jonesey95 ( разговорное ) 05:48, 11 марта 2021 г. (UTC)
На этой странице в десять раз больше, и я готов поспорить, что здесь больше людей, выступающих против отказа от поддержки, чем тех, кто поддержал ее в обсуждениях, о которых вы упомянули, вместе взятых. Повторение локального консенсуса для менее используемых параметров! = Соответствующий уровень консенсуса, чтобы избавиться от других параметров буквально из миллионов статей. Не говоря уже о том, что консенсус, который якобы был достигнут семь лет назад, даже не для осуждения, а просто для определения приоритетов. Никкимария ( разговорное ) 02:49, 12 марта 2021 (UTC)
  • Я хочу, чтобы люди перестали повторять эту утку о «консенсусе из семи человек»; это слабая платформа для аргументации. Консенсус в отношении параметров, разделенных дефисом, существует уже семь лет. Чтобы быть ясным, консенсус в этом RFC заключался в том, что параметры, разделенные дефисом, разрешены при условии недвусмысленного ограничения, что никакие параметры не могут быть обесценены. RFC особо не отдавал предпочтение параметрам без дефисов перед параметрами с дефисами, а в начале заявления прямо обещалось, что в результате никакие параметры не будут обесценены. Никогда не былобыл какой-либо консенсус (даже не слабый, локальный) об обесценивании параметров, поставленных через дефис; и, как следствие, амортизация, произведенная на этих основаниях, никогда не была действительной. И из этого обсуждения ясно, что такой консенсус никогда не был бы достигнут, если бы его искали (чего не было). Обсуждение между крошечным количеством людей без RFC, что напрямую нарушало тот самый RFC, который они пытались использовать. чтобы оправдать свои действиябез каких-либо дополнительных RFC или каких-либо усилий по достижению консенсуса или даже информированию более широкого сообщества о том, что они делали, это не «консенсус» в любом виде, форме или форме - давние консенсусы получают свое значение от большого количества людей кто их видел и принял, и в этом случае давний консенсус состоит (и остается) в том, чтобы сохранить параметры, записанные через дефис. - Аквиллион ( разговор ) 10:31, 16 марта 2021 г. (UTC)
Это не лучшая идея. В некоторых случаях многие шаблоны используются по ошибке, хотя ранее они не выявляли такие ошибки. Обнаружение и исправление таких ошибок - это хорошо. IAR - это политика, и если кто-то ломает кучу вещей, конечно, лишает их прав, но простое отображение сообщений об ошибках не является очевидной проблемой.
Что касается немого устаревания параметров, да, сначала замените, а затем объявите устаревшим. Я не думаю, что кто-то с этим не согласен. Elliot321 ( обсуждение | вклад ) 20:30, 3 марта 2021 (UTC)
Что ж, я, конечно, не согласен (и уже несколько раз был на этой странице). Если есть консенсус по поводу отказа от определенных параметров, то самое первое, что нужно сделать, - это отказаться от них, то есть сказать всем, чтобы они больше не использовали их, затем запустите ботов, чтобы заменить использование, а затем, в конечном итоге, показать красные сообщения и, в конечном итоге, полностью удалить поддержку устаревших параметров. Любой другой путь - безумие. -  JohnFromPinckney ( разговор ) 03:54, 4 марта 2021 г. (UTC)
  • Одно из возражений, которое я выдвинул против Monkbot18, которое не рассматривается в аргументе «статус-кво» (вариант A), заключается в том, что бот также вносит другие изменения, включая удаление пробелов и разрывов строк из шаблонов цитирования. Это неприемлемо для MOS: STYLERET . На мой взгляд, время, которое я потратил на отмену этих изменений в статьях, на которых я сосредоточен, было гораздо большим бременем, чем отсутствие или наличие дефиса в параметре. Если этому боту поручено поменять параметры местами, он должен ТОЛЬКО менять "accessdate" на "access-date" (и по сравнению с аналогичными переносами параметров), и абсолютно ничего.помимо этого. Вариант A следует рассматривать не как утверждение кода бота в том виде, в каком он написан в данный момент, а как задачу, для выполнения которой он должен был выполняться. - Флойдиан  τ ¢ 18:33, 7 марта 2021 г. (UTC)
    Что ж, это очень странно, потому что Monkbot18 очень осторожно сохраняет пробелы (за одним очень разумным исключением), поэтому я не понимаю, как это идет против STYLERET. Это правда, что он удаляет пустые / пустые параметры, но это хорошо, так как уменьшает беспорядок в викитексте. Он также делает несколько других хороших вещей, см. Пользователь: Monkbot / task_18: косметическая очистка шаблона cs1 . Не могли бы вы привести конкретные примеры правок, которые, по вашему мнению, вносятся неправильно? - NSH001 ( разговор ) 19:13, 7 марта 2021 г. (UTC)
    Если вы посмотрите на мои правки от 17 января, есть хороший список возвратов, но вот пример . - Floydian  τ ¢ 06:27, 8 марта 2021 г. (UTC)
    Ах, это "одно очень разумное исключение", о котором я говорил. Все остальные изменения, которые, по вашему мнению, вам нужно было внести в «очистку и стандартизацию первых 150 ссылок. Отменить глупый чертов MonkBot, вносящий стилистические изменения в тысячи статей по« консенсусу »примерно трех человек, и заблокировать его от внесения дальнейших изменений». edit относятся к другим редакторам / ботам, а не к Monkbot18. Я думаю, что пустая строка в шаблоне цитирования всегда не нужна и занимает ценное пространство в окне редактирования, но если это вас так сильно беспокоит, вы всегда можете вежливо спросить трапписта, и я уверен, что он удалит эту настройку для ты. - NSH001 ( разговор ) 07:15, 8 марта 2021 г. (UTC)
    В этом случае ваш пробег может меняться, и применяется STYLERET. Пустые строки облегчают выделение цитат из текста, а полосы прокрутки преодолевают аргумент о «ценном пространстве». Я пытался попросить убрать такое поведение. Меня встретили (* перефразировано) «код бота одобрен, работа продолжается». Так что я просто заблокировал этого чертового бота из 300 статей, над которыми работаю. Теперь, если кого-то беспокоит дефис в параметре, он может изменить его вручную. Просто как тот.
    Или, вы знаете, бот может продолжать вносить изменения в параметры, которые он должен . Мне не нужно спрашивать, это не входит в полномочия бота , удалите его. - Флойдиан  τ ¢ 15:43, 8 марта 2021 г. (UTC)
    Во-первых, вы говорите, что я пытался попросить удалить это поведение. Меня встретили (* перефразировано) «код бота одобрен, работа продолжается» . Это удивительно, поскольку я ожидал, что Trappist откликнется на такой запрос (важно выполнить эту работу, поэтому стоит внести небольшое изменение, подобное этому, чтобы избежать отката). Не могли бы вы указать мне на беседу, в которой вы сделали этот запрос и получили этот ответ?
    (позже) - ах, не беспокойтесь - я сам нашел Обсуждение пользователя: Trappist the monk / Archive 17 # Task 18 удаление ссылочного интервала . Похоже, ты не очень хорошо объяснил себя трапписту. FWIW, я могу понять, почему пустая строка для встроенных цитат в теле статьи мешает людям преобразовать ее в (ужасный) горизонтальный формат. Я снова касаюсь этого ниже, но я согласен с вами, что Monkbot18 не должен удалять пустую строку. (Надеюсь, траппист это читает). Но остальные изменения, которые он вносит, хороши и должны остаться. (На самом деле, чтобы быть точным, Monkbot должен удалить его в списках LDR или biblio, но не в основной части. Для простоты я бы сказал, просто не пытайтесь удалить его.)
    Во-вторых, или вы знаете, бот может продолжать вносить изменения в параметры, которые он должен . Это утверждение неверно. Бот был утвержден для выполнения задач, перечисленных по ссылке, которую я уже давал: Пользователь: Monkbot / task_18: косметическая очистка шаблона cs1 , и именно этим бот занимается. Помимо проблемы с пустой строкой, другие изменения полезны и ценны, они уменьшат потребность в большем количестве запусков ботов в будущем. Одна из причин, почему мне так нравится этот бот.
    Следующий фрагмент очень интересен (для меня), но в основном не по теме, поэтому я помещаю его в небольшой текст. Если вы хотите пойти дальше, не стесняйтесь обсудить это на моей странице обсуждения. Проблема беспорядка цитирования в основной части статей Википедии раздражает меня в течение многих лет, и особенно огромные проблемы, вызванные длинными горизонтально отформатированными шаблонами цитирования, которые, на мой взгляд, делают вики-текст трудным или невозможным для чтения и редактирования. Все это изложено в очень длинной «цепочке» (на самом деле это уже не цепочка): на моей странице обсуждения. Речь идет о способе размещения шаблонов цитирования, который я называю «ETVP» для «легкого визуального анализа», который во многом похож на цитаты в вашем примере, но также отличается в некоторых отношениях. Здесь стоит упомянуть о том, что у меня был трудный и утомительный опыт попытки ввести в текст статьи цитаты в формате ETVP. Предлогом для возврата меня было в основном то, что «он занимает слишком много строк» ​​в поле редактирования (отсюда «одно очень разумное исключение» выше), поэтому в конце концов я отказался от этого и сосредоточился в основном на других решениях (ETVP в WP: LDR или ETVP в списках библио с использованием кратких ссылок), что в большинстве случаев в любом случае является лучшим решением. Это'захватывающий парадокс, что вы, кажется, сошли с рук, используя большелиний, а не меньше, в сочетании с обильным использованием белого пространства - полная противоположность тому, что можно было бы ожидать. Итак, сейчас я подумываю добавить аналогичную опцию в свой сценарий ETVP - и благодарю вас за эту мысль. Однако нужно подумать.
    - NSH001 ( разговор ) 10:02, 9 марта 2021 г. (UTC)
    Пустые строки - единственная проблема, на которую я обращаю внимание. У меня нет проблем с обновлением устаревших параметров, у меня нет проблем с тем, что в моем списке наблюдения есть множество изменений, вносимых ботами. У меня действительно есть проблема с просмотром 250 статей, которые имеют в среднем 50 цитирований, чтобы снова вставить пустую строку в каждую. Это не одна из 6 задач, перечисленных в Пользователь: Monkbot / task_18: косметическая очистка шаблона cs1 .
    Есть также несколько автоматизированных инструментов, которые делают подобную ерунду, которую я сразу же возвращаю (например, Regex Citation Formatter ). - Флойдиан  τ ¢ 15:49, 10 марта 2021 г. (UTC)
    Похоже, здесь мы согласны, в частности, что вы поддерживаете вариант A , но только если Monkbot 18 откажется от удаления полностью пустых строк в шаблонах цитирования . Если бы вы могли подтвердить, что я правильно понимаю, это было бы очень полезно. Спасибо. - NSH001 ( разговор ) 10:00, 11 марта 2021 г. (UTC)
    Вы были бы правы, сэр! - Флойдиан  τ ¢ 15:36, 11 марта 2021 г. (UTC)

Стоит отметить [ править ]

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

  • в Special: Preferences # mw-prefsection-watchlist :
    • установите флажок Дополнительные параметры → Развернуть список наблюдения, чтобы отобразить все изменения, а не только самые последние
    • отметьте Показанные изменения → Скрыть изменения бота из списка наблюдения
  • в Special: Preferences # mw-prefsection-rc :
    • проверьте Дополнительные параметры → Группировать изменения по страницам в последних изменениях и списке наблюдения

Обратите внимание, что я (еще) не пробовал это сам, так как я уже доволен тем, как настроен мой список наблюдения. - NSH001 ( разговор ) 09:09, 8 марта 2021 г. (UTC)

Обратите внимание на более подробный RFC: приведенные выше инструкции являются средством для всех людей, поддерживающих вариант C, из-за «засорения списка наблюдения» и предполагаемых проблем, которые редактирует бот для редакторов, которые следят за вандализмом. Насколько я могу судить, ни один редактор, использующий указанные выше настройки, не возражает против изменений бота на основе проблем со списком наблюдения. Если не будет выдвинуто обоснованное возражение, я предлагаю не принимать во внимание все проблемы со списком наблюдения, поддерживающие вариант C, и руководствоваться приведенной выше рекомендацией. - Jonesey95 ( разговор ) 17:30, 8 марта 2021 г. (UTC)
Это обходной путь, который (а) не должен быть необходим, (б) не работает для всех, например, для тех, кто хочет видеть изменения бота (например, я делаю) и (в) не устраняет проблему только симптом . Кроме того, крайне неуместно предполагать, что большое количество обоснованных и рационально выраженных предпочтений редактора не учитывается. Тридуульф ( разговор ) 17:41, 8 марта 2021 (UTC)
Я пробовал этот обходной путь в течение последнего дня или около того. Еще в декабре я очистил свой список наблюдения и провел два с половиной месяца, пока бот работал. Я только что вернулся в Wiki и обнаружил, что бот был остановлен, но решил попробовать предложение Trappist. Пока все хорошо, это немного другое, но, по крайней мере, это делает список наблюдения более разумным, чем во время атаки бота! Мартин Шеффилдский ( разговор ) 20:23, 8 марта 2021 (UTC)
Я всегда был озадачен тем, что (некоторые) редакторы так возбуждаются большим количеством правок ботов. У меня более 6000 страниц в моем списке наблюдения (который я настроил для отображения изменений, внесенных ботами), и спам от ботов меня никогда не беспокоил. Я даже приветствую это, потому что они иногда напоминают мне статьи, над которыми я много работал, возможно, 7 или 10 лет назад, и которые мне действительно нужно посмотреть еще раз. Тем не менее, я понимаю проблемы редакторов, которые хотят иметь дело с вандализмом, поэтому этот новый параметр выглядит очень ценным и действительно должен устранить многие (но, вероятно, не все) возражения против "спама в списках наблюдения". - NSH001 ( разговор ) 10:40, 9 марта 2021 г. (UTC)
И что касается редакторов вроде меня, которых не беспокоит спам от ботов, можно ли считать, что кто-нибудь считает молчаливое большинство, которых либо не беспокоит «спам», либо которые, если они обеспокоены, недостаточно обеспокоены, чтобы прийти к этому РФК на это пожаловаться? Может, их стоит как-то взвесить при рассмотрении «консенсуса»? - NSH001 ( разговор ) 10:51, 9 марта 2021 г. (UTC)
Хорошо, учитывая, что большинство из них не будут знать, что это обсуждение существует, и просто продолжат добавление параметров, с дефисами и без них, как они всегда делали, я не думаю, что можно было так или иначе сказать, что их мнение есть - особенно с учетом того, что бот уже довольно давно не рассылает спам о своих ненужных изменениях (обсуждение открыто через месяц завтра, и я думаю, что оно было остановлено за день или около того до этого, и более чем несколько редакторов имеют мнение, что спорить с ботами / операторами ботов бессмысленно). Вместо того, чтобы цепляться за соломинку, чтобы дискредитировать или отвергнуть мнения, с которыми вы не согласны, возможно, вы могли бы вместо этого попытаться выслушать, почему они не согласны с изменениями, а не только их характер.Я также отмечаю, что вы полностью проигнорировали мое объяснение того, почему это на самом деле не решит проблему для всех, и проигнорировали, что нет причины, по которой проблема должна быть решена в первую очередь.Тридуульф ( разговор ) 11:49, 9 марта 2021 (UTC)
Ничто из этого не меняет того факта, что не существует консенсуса относительно обесценивания параметров без дефисов, и такого консенсуса никогда не существовало. Вместо того, чтобы пытаться убедить RFC ближе, вам следует спланировать, как вы собираетесь достичь этого консенсуса, если вы намерены и дальше удваивать его. - Аквиллион ( разговор ) 10:35, 16 марта 2021 (UTC)

RfC: отключить мелкие правки в английской Википедии [ править ]

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)
    • Note: I support the below proposals to limit minor edits to either autoconfirmed or extended confirmed editors (preferably the latter). BD2412 T 04:56, 3 March 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)
    Support limiting to autoconfirmed as a first step. Oppose limiting to extended confirmed. I understand the arguments in favor, but I generally oppose expanding the role of EC by taking privileges away from autoconfirmed users (giving EC users privileges otherwise only available to more restricted users is another thing). Even with this we could not prevent every mistagging of edits as minor, nor should we strive to. The majority of minor edits tagged by someone with, say, 2 months of experience and 100 edits will be fine, and if they aren't, they're not likely to figure it out by the 500th edit. — The Earwig (talk) 06:46, 3 March 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 wordsdeeds 07:25, 23 February 2021 (UTC)
  • Oppose per Mike Peel. --Jayron32 19:31, 24 February 2021 (UTC)
  • Oppose. If someone is inappropriately flagging non-minor edits as minor, that's a user conduct issue, not a reason to deprecate minor edits. Speaking as someone who's apparently made 318,850 minor edits, it's of no benefit and causes obvious disruption if readers who don't need to be made aware every time I quietly search-and-replace the misspelling "targetted" are unable to filter it from their watchlist. It would also make reviewing editors' contribution histories (whether it be for processes like RFA, or just "I'm looking for the diff of that edit you made last week") orders of magnitude more complicated, for no obvious benefit. ‑ Iridescent 19:45, 24 February 2021 (UTC)
  • Oppose - Personally I don't ever use it even if I'm indeed making minor edits... It really is too much effort clicking on one box everytime I want to save changes... that being said not using it isn't a reason to support and no reason has been given as to why this should be disabled in the first place. –Davey2010Talk 23:12, 24 February 2021 (UTC)
  • Oppose. I am somewhat sympathetic to the proposal but the problem and its scope need to be much better defined, and the proposed solution appears to be too radical. I mark copyedits as minor all the time; same for manual delsort edits. If the feature is used properly, I find it quite useful; if an edit is marked as minor in my watchlist or in a page history, I am much more likely to ignore that edit. I agree probably is some issue with the misuse of this feature, but at the moment I am unsure about the extent of the problem. Perhaps less radical solutions, such as limiting the class of users with the userrights to mark edits as minor, and trying to provide a more precise definition of what constitutes a minor edit would be useful and should be attempted first. Nsk92 (talk) 23:50, 24 February 2021 (UTC)
  • Oppose minor edits are useful to distinguish, well, which edits are minor. If minor edits are disabled, we have no way to distinguish here, so we lose information. Potentially faulty information - as improperly marked minor edits are - is worse than no information. Maybe limit to autoconfirmed, and in the worst possible case limit to extended confirmed, but removing entirely is not a good idea. Elliot321 (talk | contribs) 01:53, 28 February 2021 (UTC)
  • Oppose as proposed per Xaosflux. I am open to limiting minor edits to autoconfirmed or extendedconfirmed, but not as proposed. Twassman | Talk | Contribs 06:48, 28 February 2021 (UTC)
  • Support this makes "request minor edits feature" a main value of the rollback permission. Once somebody knows enough to want it, we should give it to them. power~enwiki (π, ν) 03:03, 2 March 2021 (UTC)
  • Oppose A solution which would be far worse than the problem it seeks to address. Minor edits are useful. Limiting it to autoconfirmed users might solve most abuse (since most vandals are non-AC); if there is such abuse in the first place. RandomCanadian (talk / contribs) 03:44, 2 March 2021 (UTC)
  • Oppose. While marking edits as minor isn't super useful, it does have some benefits when going through the edit history of an article. Of course the "minor edit" flag is just as reliable as the edit summary there (i.e. not very) and you shouldn't do anything automated based on the presence or absence of the flag. —Kusma (t·c) 11:55, 2 March 2021 (UTC)
  • Support. Should be a privilege. At present it's worse than useless for vandalism and just superfluous cognitive overload for good-faith editors. Rollo (talk) 22:06, 2 March 2021 (UTC)
  • Limit to extended-confirmed (autoconfirmed is too easy to get around) because only experienced editors should be able to mark edits minor. Then if I ignore minor-flagged edits, I won't have to worry about missing any non-EC edits. Levivich harass/hound 04:42, 3 March 2021 (UTC)
  • Oppose I don't think there is an Issue that needs solving. I think minor edits are a useful tool for actual minor edits. jort⁹³|talk 19:56, 4 March 2021 (UTC)
  • Oppose This is a solution in search of a problem. Many users, myself included, do not abuse minor edits. This is like not allowing anyone to eat food because some people eat too much. Thank you, 🐔 Chicdat  Bawk to me! 11:58, 6 March 2021 (UTC)
  • Oppose Just sanction those who abuse it. Minor edits are beneficial to this project overall. ~ HAL333 22:16, 7 March 2021 (UTC)
  • Oppose as written. Support limiting it to autoconfirmed or extended confirmed. --Ahecht (TALKPAGE) 20:23, 9 March 2021 (UTC)
  • Oppose Minor edits are clearly defined in WP:MINOR, and they have a good purpose. Besides, many people who revert vandalism are not rollbackers (like me) — Preceding unsigned comment added by Bop34 (talk • contribs) 20:46, 9 March 2021 (UTC)
  • Oppose Just becuase some people may abuse minor edits it does not mean we should essentially remove their use to editors almost entirely.  Spy-cicle💥  Talk? 18:49, 10 March 2021 (UTC)
  • Oppose, but open to reform, if we just got rid of minor edits, then it would either discourage people from making edits that are simply just spelling or grammar fixes or it would make it harder for those who moderate editing to figure out what is and isn't spam. A way we could reform this would be my making it so all edits under a certain size (say 100 bytes, this is simply an example) will be marked as minor and cannot be unmarked as minor. When I edited on Fandom (similar to Wikipedia except more for games) I would mark edits that are just me making small edits to articles (like fixing spelling or grammar) as minor because, well, they are. If we just removed the option to mark edits as minor then it might make people feel like they have to radically change the article. I'm probably repeating myself so I'm going to give another way to reform it. Just have all edits marked as minor by default. Yes, there is an option for this but I think people don't know that. Another way to reform, is, like I said above, have all edits under a certain size marked as minor and if someone attempts to unmark it as minor and its still under that size, a warning message pops up, letting the user know what the point of it being marked as minor is. When it gets over a certain size, it cannot be unmarked as minor unless the user has special permissions to do so (I.e they're a trusted Wikipedia editor). This is just my opinion but after reading all the stuff above I felt like I should contribute. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 01:08, 16 March 2021 (UTC)
    • Diff size is not a reliable way to determine what is and isn't a minor edit. A rewrite of an entire paragraph is not a minor edit but if it used the same number of characters it would have a diff size of 0 bytes. At the other end of the scale, adding an archive link to sources can add 50-100 bytes of text per URI but as it makes no change to the prose it would be valid to mark that as a minor edit. Thryduulf (talk) 01:23, 16 March 2021 (UTC)
  • Oppose as proposed, Support for limiting minor edit to autoconfirmed/extendedconfirmed editors.--Vulphere 04:56, 16 March 2021 (UTC)
  • Strongest Oppose There are other solutions to the dishonest use of the "minor" button. This, as proposed, should not be implemented. GenQuest "scribble" 16:38, 16 March 2021 (UTC)
  • Support Bots, reverts have an obvious place for minor edits. While experienced users don't all agree on definition of a minor edit, they'll at least use it consistently, which can be useful for reviewing edits of a particular user. They are less useful however, when monitoring recent changes of a watchlist. In order to make them more useful, I'd recommend limiting the ability to enable minor edits to WP:ECP users who'd at least have a consistent rationale for what's minor/major. Shushugah (talk) 16:52, 16 March 2021 (UTC)
  • Oppose Minor edits are useful. Not only for me to use when correcting typos, or to help me bypass minor edits by editors I recognize, but also because the "minor edit" checked plus a canned edit summary like "Fixed typo" is a clear red flag to check for vandalism or other disruptive editing. – Muboshgu (talk) 16:54, 16 March 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: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]. — The Earwig ⟨talk⟩ 07:37, 17 February 2021 (UTC)
  • Comment. I voted oppose above and indicated I would be open to limiting who can mark edits as minor. I've noticed several people have since suggested only allowing autoconfirmed users to mark edits as minor, but I was under the impression it was already limited to autoconfirmed users. If not, I see no reason why that shouldn't be the case. -- Calidum 21:11, 24 February 2021 (UTC)
    @Calidum: The present situation is that you dn't need to be autoconforemed to mark edits as minor, just be logged-in. --Redrose64 🌹 (talk) 17:12, 25 February 2021 (UTC)
  • Some of the topics I keep my eye on are prone to POV vandalism. Often the vandals attempt to hide their vandalism behind a “minor edit” tag. This is (counterintuitively) quite helpful when it comes to spotting and cleaning up such vandalism ... I have learned to pay extra close attention to edits that are marked as being “minor”. Thus, I would oppose doing away with the tag. Blueboar (talk) 23:03, 24 February 2021 (UTC)

Wikipedia:List of Wikipedians by number of edits[edit]

Hi! I propose to extend this ranking to the topbest 20,000 Wikipedians by number of edits, instead 10,000. Dr Salvus (talk) 14:17, 28 February 2021 (UTC)

@Dr Salvus: I have changed your "best" to "top" to try to avoid derailing the discussion. English is not your native language and I guess "top" better covers what you mean. PrimeHunter (talk) 14:37, 28 February 2021 (UTC)
Would this be possible to do? The obvious problem is that it might encourage Wikipedia: Editcountitis. Rollo August (talk) 19:32, 28 February 2021 (UTC)
It's certainly possible, but it's a bot-generated report, so is the bot operator (MZMcBride) willing to make the change? If they are, does the community desire it? I've placed a note at Wikipedia talk:List of Wikipedians by number of edits. --Redrose64 🌹 (talk) 09:58, 1 March 2021 (UTC)
  • While I think WP:WBE is a good thing in general along with other metrics that give positive feedback to editors efforts I worry that opening it up for low number of total edits is much more likely to encourage Wikipedia:Editcountitis. Since it's already split 1-5000 and 5001-10000 if it was increased I would suggest just 10001-15000 is added not all the way to 20000. KylieTastic (talk) 10:22, 1 March 2021 (UTC)
  • Meh, I'll be more interested in Wikipedia:List of Wikipedians by number of FA nominations. enjoyer|talk 10:30, 1 March 2021 (UTC)
    Enjoyer of World, that exists. I've redirected your redlink to the page. {{u|Sdkb}}talk 07:19, 2 March 2021 (UTC)
    Cool. enjoyer|talk 08:31, 2 March 2021 (UTC)
  • I strongly support ~12,000, support 15,000, weakly oppose 20,000, and strongly oppose anything past 20,000. 🐔 Chicdat  Bawk to me! 11:29, 1 March 2021 (UTC)
  • Double Meh! Edit counts are really pretty much meaningless as a metric. Why bother? GenQuest "scribble" 02:41, 2 March 2021 (UTC)
  • Triple meh! Editcountitis is the most succinct way of describing this; and well as GQ states they're a pretty much meaningless metric. RandomCanadian (talk / contribs) 04:01, 2 March 2021 (UTC)
  • Oppose. I agree with the editcountitis concerns. Additionally, beyond 10,000 (and arguably even beyond 5,000), the rankings are so high that it's not a very meaningful metric. {{u|Sdkb}}talk 07:22, 2 March 2021 (UTC)
  • I would be against that simply because 10k is more than enough as it is. The list as is arguably doesn't do much to improve the encyclopedia, not sure how expanding it would. Dennis Brown - 2¢ 12:01, 2 March 2021 (UTC)
  • Quadruple meh I would even support shortening the list. ~ HAL333 19:22, 4 March 2021 (UTC)
  • Support. I say, if people want a longer list, let them make a longer list. It can be on a subpage. If moving up the list encourages some editors to make productive edits, it's worth it. BD2412 T 19:37, 4 March 2021 (UTC)
  • Support per BD2412. Today's enumeration states, "As of Monday, 08 March 2021, 02:13 (UTC), The English Wikipedia has 41,101,321 registered users, 143,161 active editors, and 1,109 administrators. Together we have made 1,006,207,773 edits, created 52,919,998 pages of all kinds and created 6,266,459 articles." Make the length of the list as extensive as MZMcBride is willing to service it, even to the extent of 100,000 or even all actives, if available space is unlimited. If seeing their names on the list is the aspect that might inspire some editors into useful productivity, then the sky should be the limit. —Roman Spinner (talk • contribs) 03:30, 8 March 2021 (UTC)
  • Support increase to 20,000. The whole thing is just for fun. Wikipedia:List of Wikipedians by number of edits#Caveat lector and Wikipedia:Edit count#"Quality, not quantity" help to explain why the numbers are just numbers and not to be taken too seriously. I would think that new sub pages like Wikipedia:List of Wikipedians by number of edits/5001–10000 can be created for the next two batches of 5000. Then links to them can be added here Wikipedia:List of Wikipedians by number of edits#List of Wikipedians by number of edits. Those editors that are interested in tracking their numbers can follow them there and those that don't find it of interest can just ignore it as has happened up til now. MarnetteD|Talk 04:07, 8 March 2021 (UTC)
  • Mostly harmless I would be more interested to see a list ranked by content added. Content improved would also be an interesting metric if anyone can work out how to measure it. · · · Peter Southwood (talk): 07:38, 8 March 2021 (UTC)
  • Support per MarnetteD. I've been hanging around the bottom of the top 5,000 for a long time, and keeping myself on the list has occasionally provided motivation to edit. So presumably others could be motivated to stay in the top 20,000. Maybe that sounds immature, but it's more productive than seeking likes, re-tweets or right-swipes. Adrian J. Hunter(talk•contribs) 07:52, 8 March 2021 (UTC)
  • Comment: If people below the top 10,000 are interested in knowing how they rank, I think it'd be more useful to have a magic word that returns their rank (we'd presumably also want one that returns their count) than to have that information collected on a page. List pages are only useful when someone might want to look at them as a whole, rather than just seeking out a specific user. It's definitely conceivable that someone might want to look at the top 100 as a group, but I can't really envision anyone who's ranked 14,704th being interested in checking out the users above them in 14,600s or really having any use for the 10k-14k page at all other than finding themselves on it. {{u|Sdkb}}talk 01:20, 9 March 2021 (UTC)
    @Sdkb: How would such a magic word obtain the rank value, other than by referring to a list which does not (as yet) exist? --Redrose64 🌹 (talk) 14:11, 9 March 2021 (UTC)
    Redrose64, I'm not a strong programmer, so I can't specify implementation details. If we need to construct a database to query, that's of course fine, but that's different than having an editor-facing projectspace ranking page. {{u|Sdkb}}talk 19:05, 9 March 2021 (UTC)
  • 80/20 Rule rules Wikipedia it can be found everywhere; highlighting the approx top 20% prolific editors would be logical. -- GreenC 01:35, 9 March 2021 (UTC)
    GreenC, that is a good suggestion. Emir of Wikipedia (talk) 22:46, 10 March 2021 (UTC)
  • No objection, bit it would be much more useful to have (as well) a list (however long) restricted to just those who have edited in the last 1,3 or 6 months. Also the magic word thing per User:Sdkb above. The current 10k lists gets down to 9,433 edits - I'm not sure how much point there is in a listing below that. At some point not too far away we will have 10,000 editors who have each done 10,000 edits - perhaps that deserves a small celebration? Johnbod (talk) 14:17, 9 March 2021 (UTC)
  • Does this need any discussion here? Surely if anyone wants to create a longer list then it can be done, and if they don't then it won't be done. It's harmless, but pretty useless, so comes nowhere near any list of priorities. Phil Bridger (talk) 19:14, 9 March 2021 (UTC)

Bringing back the GA Cup[edit]

I simply propose bringing back the GA Cup, which was abandoned a few years ago, to reduce GA nomination backlog. You can read a bit more about my proposal here. If you would want to be involved in the GA Cup, let me know in the comments below. X-Editor (talk) 06:21, 3 March 2021 (UTC)

  • Support Why not? ~ HAL333 19:21, 4 March 2021 (UTC)
Exactly! This will help with the backlog a lot. Seeing as quite a bit of this year has passed already, maybe we could start the next GA Cup in mid-2021 and end it in mid-2022. The one after that will then start at the beginning of 2023 and end at the end of 2023. X-Editor (talk) 21:36, 4 March 2021 (UTC)
  • Support: That sounds helpful, the current backlog is extremely discouraging. - Astrophobe (talk) 23:11, 4 March 2021 (UTC)
  • Support I support anything that reduces the backlog. 🐔 Chicdat  Bawk to me! 12:17, 8 March 2021 (UTC)
  • For anyone interested in this topic, there's a current GA Backlog Drive through the month of March. Since around the start of the pandemic they've been running a drive every few months. Ajpolino (talk) 16:12, 8 March 2021 (UTC)
    As Ajpolino notes, there has been a GA drive every six months with decent levels of success. I guess it couldn't hurt to trial the GA cup again and I'd certainly participate, but I question whether interest in reviewing could be sustained for more than a month at a time.
    If we're looking for more radical solutions, what I will always say is to look at the report and note those with a lot of nominations open. Right now there are two users with a combined eighty nominations open who have conducted forty reviews ever. That's quite possibly the biggest single contributing factor to the backlog— people who write copious amounts of content but cannot be bothered to review in return. (Of course, most prolific ga writers restrict themselves to a reasonable number open at a time or review in turn (Sturmvogel 66 and The Rambling Man come to mind as prolific writers and reviewers), but there are a few who don't. And it's frustrating) Eddie891 Talk Work 16:29, 8 March 2021 (UTC)
    Eddie891, Why not use the quid pro quo system like they do at DYK? -- RoySmith (talk) 22:34, 8 March 2021 (UTC)
    We could also just limit editors to two or three open GANs. ~ HAL333 00:22, 15 March 2021 (UTC)
    Both of these are extremely reasonable options... even one GA review for every two GAs would do wonders... Aza24 (talk) 00:26, 15 March 2021 (UTC)
    In a world where Eddie designed the GA process, I would institute something along the lines of up to five GANs open at a time and a QPQ of two GANs for every one review above that baseline; but that sounds like a logistical nightmare Eddie891 Talk Work 01:04, 15 March 2021 (UTC)
    It's funny you say that, I had a similar thought process a few months ago. During the last GA drive I considered what GAN would look like if mirroring DYK, but it occurred to me that making QPQ would probably result in more low-quality reviews in addition to putting off prolific GA nominators (as much as they fill the backlog, there content creation is still extremely valuable). Having a different ratio seemed the ideal solution (1 for every 2, or 2 for every 3 etc.) but I came to the same conclusion that the logistics would be unrealistic... Having a limit on pending GANs seems more feasible though, this is already done at PR, FLC and FAC. Aza24 (talk) 01:35, 15 March 2021 (UTC)
  • Oppose until the format, consequences on other contests like WikiCup, guarantee of quality reviews etc. are made clear and agreed upon. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 16:43, 8 March 2021 (UTC)
@The Rambling Man: I'm not sure what the format of a new GA Cup would be, but I imagine it would be similar to formats of the previous GA Cups that were done several years ago. X-Editor (talk) 22:29, 8 March 2021 (UTC)
Before we all get carried away and vote for this, it needs to be properly defined. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 22:31, 8 March 2021 (UTC)
@The Rambling Man: I agree, which is why I want to ask you what you would do if you had the chance to organize this GA Cup? X-Editor (talk) 23:28, 8 March 2021 (UTC)
I haven't got a clue. I have never participated in it before, but you can't just vote to resurrect something without saying what it is you're going to actually do. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 07:40, 9 March 2021 (UTC)
@The Rambling Man: I think a similar format to the GA Cups done previously would be the best option. X-Editor (talk) 21:43, 9 March 2021 (UTC)
  • Oppose a certain editor's style of writing and nominating GAs springs to mind, and that I don't want to encourage. If you've been reviewing for a little while, you'll probably know who I'm talking about. Kind regards, Willbb234Talk (please {{ping}} me in replies) 18:05, 15 March 2021 (UTC)

Wiki Pages Having Links to Other Wikimedia Websites With the Same Topic[edit]

An example might be https://en.wikipedia.org/wiki/Jaguar would have a link to https://species.wikimedia.org/wiki/Parphorus_jaguar, and https://simple.wikipedia.org/wiki/Jaguar. Let me know what you think. AidTheWiki (talk) 16:06, 7 March 2021 (UTC)

  • This is already done... view WP on “Desktop mode”, and look at the sidebar. Blueboar (talk) 16:22, 7 March 2021 (UTC)
  • Also, look in the "external links" section, you should see that Janguar has a box calling out more information on wikispecies:Panthera_onca. — xaosflux Talk 19:57, 9 March 2021 (UTC)

notifications of indef blocked users[edit]

This is something that just kind of bothers me and I'm not sure I have a good solution to it but thought a discussion might be productive. Sometimes, very long-term users end up indef blocked, and over time many things they created are nominated for deletion. Notifying someone who has been blocked for years seems unproductive and kind fo like kicking them when they are down. I'm not by any means suggesting these nominations or notifications are done in bad faith, in many cases the notifications are done by automated tools anyway. And that might be where a tweak could be made. I use a script that automatically puts a line at the top of any user page or talk page telling me how long a user has been registered, what user rights they have, and will also inform me if they are blocked. For example, right now on my own user page it displays as A checkuser, oversighter, and administrator, 13 years 7 months old, with 96,136 edits. Last edited 27 minutes ago. If that functionality is compatible with Twinkle or other such tools, they could pop up and ask if the user is sure they want to notify, something like <USER> is blocked and their last edit was 342 days ago, do you wish to proceed?. Does that make sense and/or seem reasonable to anyone else or is it just me? Beeblebrox (talk) 20:11, 9 March 2021 (UTC)

I've been bothered by the same thing, and I think it's a reasonable suggestion. There are also people who've formally left the project, so it should account for people who haven't been blocked but are just plain gone. Acroterion (talk) 20:16, 9 March 2021 (UTC)
(edit conflict) Seems reasonable to me. I prefer to nominate pages for deletion manually rather than using Twinkle, and skip notifying indefinitely blocked users, or users who have been inactive for a long time (I'm not consistent about how long). Although, I once got personally attacked on Meta for not notifying an indefinitely blocked user ... * Pppery * it has begun... 20:19, 9 March 2021 (UTC)
  • Leaving the same courtesy notifications that you would on any unblocked user's talk page is not WP:GRAVEDANCING, not kicking them when they're down. And it's a mistake to assume that those notifications serve only that user. There have been numerous occasions when notices on an indef blocked user's talk page helped me find an old deletion discussion, or discern a pattern in their behavior. Such patterns have led to further cleanup and to the unmasking of sockpuppets. Perhaps such breadcrumbs aren't as important to admins, who I assume can see deleted pages and revisions. As a non-admin, I hope no one stops leaving notices on the talk pages of blocked users. --Worldbruce (talk) 23:13, 9 March 2021 (UTC)
  • I agree with what Worldbruce said above. Also a surprising number of highly productive editors have been indef-blocked, and they have often created significant pages, templates, images, etc., where a wider notification pool may be good. Furthermore, an indef-block is not always forever, and they might return one day to address any issues, or catch up, even if they miss the relevant discussion at the time. And if a page is bothering you, you can always unwatch it. However I also agree with Beeblebrox that people should have the information in a convenient place to opt out of notifying users. Ideally people should be taking the extra few seconds to look at contribs anyway, before choosing the relevant tickbox in Twinkle, but it is what it is. I would guess that it would be relatively easy to implement in Twinkle if it isn't already - you would want to speak to the Twinkle developers. -- zzuuzz (talk) 23:56, 9 March 2021 (UTC)
  • How many of these scripts respect {{nobots}} and might that be something indef'd editors can be made aware of? I get the reasons above about the benefits of allowing these notifications, but it strikes me as similar to don't template the regulars: it's not wrong or forbidden, but just kinda tone-deaf. We should be up-front about the option, and let current editors make their own decisions on whether to template indef'd editors. I'd be fine preventing it by default. — Wug·a·po·des​ 01:36, 10 March 2021 (UTC)
  • The problem here is that productive users have been blocked. For example, I was just reviewing the history of a couple of articles and noticed that Hullaballoo Wolfowitz had made some useful contributions. But they are currently blocked for a period of six months – a remarkably draconian and unproductive punishment. In such cases of obvious injustice, I will typically put that user's talk page on my watchlist so that I may observe any such notifications and take appropropriate action. HW's talk page has over 300 watchers and the notifications are for them as well as the primary user. So far, in that case, we have had one of Gerda's Precious anniversaries which serves to remind us that this block is disruptive. So, the appropriate action in this case is to remove the block – the OP should please oblige. Andrew🐉(talk) 11:47, 10 March 2021 (UTC)
    • See the ANI discussion which led to the block and especially note the discussion following it where the length was explained and endorsed. Andrew you might want to read up on WP:ADMINSHOPping. — Wug·a·po·des​ 20:38, 10 March 2021 (UTC)
      • An overly harsh block for pretty insignificant abuse. The effect of the block is worse than what it was addressing. Anyway for a 6 month block, notifications are still worthwhile to get on the topic of this discussion. Graeme Bartlett (talk) 00:06, 11 March 2021 (UTC)
        • An ... block for ... abuse. fixed that for you Graeme. You might want to try reading the discussion I linked, especially the part where I said even people defending HW pointed out a pattern of incivility, they simply try to excuse it through various means. If you're interested in more than just taking cheap shots at me and want to challenge the close, you know where AN is. — Wug·a·po·des​ 00:53, 16 March 2021 (UTC)
  • This is one I have struggled with, I don’t like the perception of grave dancing, but when nominating an article for discussion I have sometimes left a message for blocked users wondering if (hoping) one of their former collaborators might maintain a watch on their TP and have an interest in or knowledge of subject matter. Cavalryman (talk) 22:02, 10 March 2021 (UTC).
  • This is an interesting discussion. I'm not so concerned about any perceived awkwardness or impoliteness in leaving such a notice on a blocked user's talkpage, as I am in the productiveness of it. As people are saying, it is better to leave such a message rather than none at all, because then the message is at least seen, but if the user has few or no talkpage watchers, or if the user is not blocked, but simply inactive, then notifying just the first editor may not be productive at all. And even if the first editor is still active, they may not be the person who is most interested in the article. Some first editors make just the initial edit or two, and then leave the article, and it may get built up by other editors. I think it may be useful to have an added functionality in the automated tool to notify the first editor AND the most productive editor (perhaps with some added clause such as that the most productive editor should be unblocked, and have made an edit on Wikipedia in the previous month). SilkTork (talk) 09:21, 12 March 2021 (UTC)
  • What Silktork said. There are articles where one creates, but another fleshes it out and has more of a vested interest in the article, so expanding notifications to those people is worthwhile. As for notifying someone who is indef blocked, I certainly don't see it as gravedancing, it is simply treating them like anyone else here, which is technically what we are supposed to do unless they are actually banned. It may be less than ideal in some ways, but it is the lesser of the two available evils. Even if indef blocked, by being notified, they can at least know it up for deletion, and ask someone else to look into it (which isn't the same as proxy editing), or a talk page watcher can look into it, putting more eyes on it. Not every solution is perfect, but I think the current system is the least un-perfect. Dennis Brown - 2¢ 10:13, 12 March 2021 (UTC)
  • Just to be clear, the only thing I was even thinking of proposing was to ask for Twinkle or other tools to just have the option to double check if you want to proceed if the user has been blocked and inactive for say, six months or longer. I don't think we need a rule or anything. An example is User talk:Richard Arthur Norton (1958- ). This user checks in once or twice year, clears like 20 deletion notices off their page, and goes quiet again. Again, I don't think anyone is doing this maliciously, it just seems rather pointless. Beeblebrox (talk) 06:17, 13 March 2021 (UTC)
Alfred Dreyfus's talk page, 1895
  • This also bothers me when I see it. Especially since an indeffed user can't actually participate in the deletion process, it just seems unnecessarily cruel: "Hey asshole, that article you spent a bunch of time on is getting nuked, thought it might be funny for you to watch people debate about it without being able to respond in any way". Not nice! jp×g 18:43, 16 March 2021 (UTC)

Removal of "List of Transgendered People"[edit]

I have decided to write this once about it, but I think we should get rid of the "List of Transgendered People" article, even if it is blank. It may be a bit upsetting that it still exists. We have an updated article with "transgender" instead of the less respectful "Transgendered", so I suggest removing it. What's the use of keeping it if we already have a better one? [1] — Preceding unsigned comment added by 2603:6080:3040:2c2:10b9:203f:84e1:2a84 (talk)

List of transgendered people is a redirect to the "right" term List of transgender people. We keep it because it is a possible search term by readers that may not be aware of the more accepted terminology regarding transgender people - that is, while in the past "transgendered" was a term in use, it is discouraged over simply "transgender" but not everyone may know that. Those searching on the old term will get to the page with the right term and will be informed why this is the right term. --Masem (t) 17:13, 10 March 2021 (UTC)
Agreed with Masem. This discussion would go at WP:RfD. It should be closed here if it continues to draw responses. {{u|Sdkb}}talk 17:26, 10 March 2021 (UTC)
Also, it's a very old {{redirect with history}} that gets about 4 page views a day so deleting it might break external links. — Wug·a·po·des​ 04:27, 11 March 2021 (UTC)

References

  1. ^ List of Transgender People

Should we protect featured articles while on the front page?[edit]

Duplicate discussion. {{u|Sdkb}}talk 17:29, 10 March 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

At this point, it's almost a given that when a featured article is chosen, it will be a high target by vandals. It will be better semi-protect (or at least pending changes) featured articles for the duration that they're featured. Eridian314 (talk) 17:20, 10 March 2021 (UTC)

@Eridian314: You will be interested in #Pending-changes protection of Today's featured article. --Izno (talk) 17:24, 10 March 2021 (UTC)
Thanks. I didn't see that. Eridian314 (talk) 17:27, 10 March 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Subpages of redirects should redirect[edit]

I propose that subpages of redirects should redirect to the supage of the target page. This should apply unless there is an existing page at the subpage. For example, if you had a page ExampleRedirect which had a target of ExampleTarget, going to ExampleRedirect/SubpageA would send you to ExampleTarget/SubpageA. Now imagine that for whatever reason there was a subpage on ExampleRedirect/SubpageB that did have content on it. Going to ExampleRedirect/SubpageB would not redirect, as there was already content. I also have a proposed way for the system to do this. When you go to an empty page that is a subpage of another page, the code would check whether or not there was a redirect at that page. If there was it would redirect you as explained above. Like I said, it would only activate if you were at an empty subpage. One example of the effect of this change would be with Wikipedia:Criteria for speedy deletion. This change would cause going to WP:CSD/Creating a new criterion to redirect to Wikipedia:Criteria for speedy deletion/Creating a new criterion. βӪᑸᙥӴ • Talk • Contribs 13:33, 11 March 2021 (UTC)

It cannot be implemented with the current MediaWiki unless we add some global JavaScript (which would only work for users with JavaScript but that's most users). MediaWiki:Noarticletext could examine whether there is a parent page, whether it is a redirect, see where it redirects, and suggest it as a link, but it cannot make a redirect. PrimeHunter (talk) 13:55, 11 March 2021 (UTC)
I'm surprised that we still don't have this functionality after nearly 20 years. I'm sure this is something that will eventually be added into the software. --Heymid (contribs) 16:43, 12 March 2021 (UTC)
Unless I am misreading the scope of this proposal, in general I do not think this is necessary. For example, the full name Eric Barry Wilfred Chappelow redirects to Eric Chappelow, as does the abbreviated form E. B. W. Chappelow. I see no reason for Talk:Eric Barry Wilfred Chappelow/GA1 or Talk:E. B. W. Chappelow/GA1 to be created as redirects to Talk:Eric Chappelow/GA1. There are probably at least a handful of redirects going to every GA candidate in Wikipedia, to begin with. BD2412 T 17:15, 12 March 2021 (UTC)
The suggestion is not to create redirect pages but to automatically redirect if there is no page. There are many cases where a redirect would be pointless but probably do no harm. PrimeHunter (talk) 17:26, 12 March 2021 (UTC)
It would be useful in Wikipedia space, so for example WP:MOS/Abbreviations would automatically redirect to Wikipedia:Manual of Style/Abbreviations. (Whether or not this feature warrants the cost, I'm not clear.) isaacl (talk) 04:36, 13 March 2021 (UTC)
What do you mean is the cost? It's not hard to implement. --Heymid (contribs) 12:14, 13 March 2021 (UTC)
Every feature has a cost to develop, to test, to review, to get accepted for integration, to deploy, and to maintain. There is also an opportunity cost. Anyone is of course welcome to proceed with development and testing; you need support and effort from those managing MediaWiki development for other steps, which is more cost for the developer and others. Without more information, I'm not commenting on the relative priority of this particular feature in terms of its cost and in relation to all other backlog items. isaacl (talk) 19:49, 13 March 2021 (UTC)

Block the edit for non-registered users[edit]

I think to combat vandalism a solution might be blocked from editing for unregistered users. I think because many IPs are shared and vandal IPs are not punished. DrSalvus (talk) 23:06, 12 March 2021 (UTC)

Hi Dr. Salvus. See WP:PEREN#Editing for some background. This has been proposed a number of times. Also see WP:5P3. Thank you. Killiondude (talk) 23:23, 12 March 2021 (UTC)

Deprecate linking to Wikipedia books in templates and articles[edit]

I'm proposing that we formally deprecate linking Wikipedia:Books in templates and articles. Wikipedia books have not worked for many years now but are still included in various templates (e.g. {{Star Wars universe}}, {{Mercury (planet)}}, {{Abraham Lincoln}}) and maybe some articles—I recall seeing some in various "see also" sections. It seems unhelpful and unproductive to lead readers to a page that says the service in question is unavailable and points the reader towards external (third-party) sources; I speculate that most readers will see this as a dead end and not pursue it further. Around two years ago {{Wikipedia books}} and the relevant sidebar were suppressed, so I don't see why we should contradict that practice by still providing useless links in templates (and supposably articles). Aza24 (talk) 06:48, 13 March 2021 (UTC)

More info available at Wikipedia:Wikipedia book creator status.
Previous talk - Wikipedia:Templates_for_discussion/Log/2021_January_16#Template:Wikipedia_books - result = keep.
  • Support. I'm not fully read up on the history of Wikipedia Books, but it seems like an experiment we tried and that failed. We should clean up after ourselves, which means not continuing to link to it after it's dead. {{u|Sdkb}}talk 05:04, 14 March 2021 (UTC)
  • Support: as Sdkb says, let's clean-up after ourselves. GenQuest "scribble" 08:48, 14 March 2021 (UTC)
  • Support As a loose end to failed project, as Aza points out, this is just a dead end that does no service to our readers. Beeblebrox (talk) 20:45, 14 March 2021 (UTC)
  • Support Not a contentious suggestion and understandable. I like the principle of "cleaning up after ourselves." doktorb wordsdeeds 21:37, 14 March 2021 (UTC)
  • Support Wow, I had never even heard of these (which says a lot). ~ HAL333 00:18, 15 March 2021 (UTC)
  • Support Failed experiment, should be deprecated.--Vulphere 04:52, 16 March 2021 (UTC)
  • Support I have a ton of opinions about books and think it is a really difficult problem how to handle them. I think they have a non-negligible value if they ever get working properly again and even now there are a handful of people finding value in them. At the same time the namespace is filled with a lot of crap, the category system is in most cases a better tool for reading about a subject and linking to pages with large warning banners doesn't look good at all. I have previously proposed a technical way to hide these links without removing them so we could put them back if the issues are fixed at Wikipedia:Village pump (technical)/Archive 183#Mainspace book links but to be honest I am absolutley fine with just removing them as well. My solution, while workable, would definitely cause some confusion for non-technical editors and possibly weird formatting in places if someone touched whitespace around them. Straight up removal would also have the benefit of pruning the links if they ever need be re-added and should in theory only link to decent quality books. --Trialpears (talk) 16:19, 16 March 2021 (UTC)
    @Trialpears: The problem with the Category system is that its lists are essentially unstructured and can be very large; Books allow intelligent design. Also, book links are currently suppressed, much as you suggested. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)
  • Strong object. The OP's "service in question", as described at Wikipedia:Books, is the Collection extension (aka Book Creator). It is very much here and working. And w have a Books: namespace with lots of books in it. We deservedly ditched our useless in-house renderer, but the idea that it is nowadays "the service in question" is nonsense. As stated on Wikipedia:Books and elsewhere, "As a result of anticipated future solutions, template transclusions should not be removed from articles." We would first need to establish a consensus to abandon any thought of such future services, such as adopting the long-anticipated Collector, and also of supporting external services such as MediaWiki2LaTex at WMFlabs. Then we'd have to agree to abandoning the Book: namespace. Let's discuss those first and not go round breaking them. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)
  • Support per WP:NOTPAPER. If readers want to use an external service to print collections of articles, they may do so, but we have no need to maintain support indefinitely for services unrelated to our goal of building a wiki. As sdkb says, we tried books and it failed. Book:Star Wars and Book:Abraham Lincoln average 3 views a day each. Star Wars got more page views yesterday than the book gets in an entire year. Mark the namespace as historical, remove reader-facing links to it, and let it collect dust (I oppose deleting the namespace or pages per m:Keep history). We don't need to waste time maintaining support for a feature no one uses. — Wug·a·po·des​ 19:27, 16 March 2021 (UTC)

Modifications to the 'blocked user' frame for partial blocks[edit]

I think that on the contributions page for partially-blocked users, their block frame should have a less red background color, perhaps orange or even white. It should also state "This user is currently partially blocked." --Heymid (contribs) 12:13, 13 March 2021 (UTC)

I am fairly certain this is not possible today. --Izno (talk) 18:29, 13 March 2021 (UTC)
That's surprising, given that the block message is colored yellow on the Swedish Wikipedia. --Heymid (contribs) 20:48, 13 March 2021 (UTC)
Aren't the block frame and text fetched from MediaWiki-namespace pages? --Heymid (contribs) 20:56, 13 March 2021 (UTC)
It's customisable with the CSS class linked below, and probably MediaWiki:Logentry-partialblock-block, though I don't currently see how the proposed text can be gracefully added. Anecdotally, on more than one occasion I've seen the red block box and not noticed that it's a partial block. I think some slight differentiation might be useful. -- zzuuzz (talk) 21:47, 16 March 2021 (UTC)
Actually, I see the text already been added with MediaWiki:sp-contributions-blocked-notice-partial and MediaWiki:Sp-contributions-blocked-notice-anon-partial. -- zzuuzz (talk) 21:58, 16 March 2021 (UTC)
  • Why? Dennis Brown - 2¢ 10:48, 16 March 2021 (UTC)
  • It looks like this can be done in common.css - see phab:T246293. No opinion on whether we should do it. Andrew Gray (talk) 21:13, 16 March 2021 (UTC)

Wiki meets Sustainable Fashion[edit]

Hello, we are PulloJesicaNoemi and Irinarosarina. We are presenting a Grant, Wiki meets Sustainable Fashion. We are a group of Latin women interested in sustainable fashion, and our goal is to bring in and train 360 female volunteers to edit pre-existing articles and to create articles related to this subject. If you could please check out our project here and leave your comments, it would be greatly appreciated! PulloJesicaNoemi (talk) 14:00, 14 March 2021 (UTC)

Deleting part of an edit history[edit]

  • Currently, admins cannot delete only some of the edits in a page's edit history and leave the rest visible; he can only delete the page completely, and then undelete some of its edits, this wasting his time and the internet's time and Wikipedia's server's time. It would be useful if an admin could delete some of the edits in a page's edit history and leave the rest visible, all in one action. Anthony Appleyard (talk) 17:15, 14 March 2021 (UTC)
    • Seems like the feature you're suggesting already exists, it is called WP:REVDEL. Or WP:SUPPRESS, for even more thorough selective deletion (but being admin is not enough to use this last feature: it is reserved for oversighters). --Francis Schonken (talk) 17:32, 14 March 2021 (UTC)
The features you mention leave the history in place, but just hide the contents. I imagine what Anthony is referring to is a way to actually delete these revisions (Selective deletion). This is used to be fairly common, especially when dealing with voluminous vandalism. It can still be useful when dealing with these and other slightly niche things like history splits, or user pages. I imagine the introduction of Special:MergeHistory / Special:Log/merge has reduced the need for selective deletion even further, and that there is not really enough application left to introduce it as a new feature. There's almost certainly going to be an extension for MediaWiki which could do it, but I think it would be a hard sell. -- zzuuzz (talk) 18:44, 14 March 2021 (UTC)
When I first joined the oversight team, this was how it worked. Then revision deletion with the option to suppress as well came along and... it's just so much better, and the old way was deprecated. Easier to use, at least slightly more transparent, and allows an admin to revdel before asking for outright suppression, reducing potential harm. Beeblebrox (talk) 20:44, 14 March 2021 (UTC)

Please feel free to respond on the RfC on whether to say in the UPE template that the payer isn't necessarily the subject of the article[edit]

Just to try to keep it brief the instructions at WP:RFC#Publicizing_an_RfC say:

To get more input, you may publicize the RfC by posting a notice at one or more of the following locations:

  • One of the Village Pump forums, such as those for policy issues, proposals, or miscellaneous

I posted the RfC at 09:12, 25 February 2021 (UTC) and so far there has only been two editors (me and CUPIDICAE💕) without any clear consensus.

So please feel free to share any thoughts there at the RfC.

Jjjjjjjjjj (talk) 20:46, 16 March 2021 (UTC)