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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Поддержка по предложению ~ ToBeFree ( обсуждение ) 11:09, 11 января 2021 г. (UTC)
• Поддержка - уменьшение количества шаблонов страниц обсуждения и помощь новым редакторам в понимании Engvar в то же время звучит для меня как беспроигрышный вариант. Злой Гарпия ^{разговоры} 12:47, 11 января 2021 (UTC)
• Думаю, я против по симпатическим причинам. 2 причины: 1) Не думаю, что это технически осуществимо. Он просит сделать уведомление об изменении по существу для 6 миллионов страниц. Ужасно много инфраструктуры. (Кто-то скажет мне, что я ошибаюсь.) 2) Я действительно думаю, что правильным средством является полное удаление их со страниц обсуждения. Нам не нужно, чтобы они присутствовали одновременно в их каноническом месте в виде тегов статей и страниц обсуждения. (При необходимости замените статью.) - Изно ( обсуждение ) 14:41, 11 января 2021 г. (UTC)
  • @ Izno : Я думаю, что при текущем использовании модуля eng var было бы создано не более 41 000 уведомлений об изменении . - Пол ❬ доклад ❭ 18:36, 11 января 2021 г. (UTC)
    • Просто казуальная 41к. Эйеролл. - Изно ( разговор ) 18:44, 11 января 2021 (UTC)
      • Тривиально для бота. Тридуульф ( разговор ) 19:57, 11 января 2021 (UTC)
      • Банально это или нет, но совсем другая цифра в 6 мил. - Paul ❬ talk ❭ 21:14, 11 января 2021 г. (UTC)
        • Создание «для бота тривиально». Обслуживание и фильтрация сквозь шум в пространстве имен шаблонов, ищущих что-нибудь, кроме уведомлений об изменении? Да не очень. - Изно ( разговор ) 01:39, 12 января 2021 (UTC)
• Поддержка Это кажется хорошей идеей, к которой стоит стремиться. - Джейрон, 32 18:16, 11 января 2021 г. (UTC)
• Поддержка Уменьшение беспорядка на страницах обсуждения - хорошая идея. Remagoxer ( разговор ) 20:51, 11 января 2021 (UTC)
• Поддерживать. Это было бы более полезно в качестве примечания к редактированию - я знаю, что никогда не проверяю сначала, и мне больно открывать страницу обсуждения на новой вкладке (тем более, что у меня СДВГ, и иногда я забываю вариант, как только закрываю, сказал вкладка). В идеале похожие уведомления о стиле написания данной статьи также было бы здорово иметь в качестве уведомлений об изменении. Однако есть опасения, что, уменьшая беспорядок на страницах обсуждения, нам нужно не просто перемещать беспорядок (так сказать, убирая его под ковер). - Ссуризури ( разговор ) 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).
• Против . Разновидности английского языка не настолько важны, чтобы их можно было разместить в качестве редакционного уведомления. Просто попытайтесь заметить, какое разнообразие используется в статье, и подражайте этому; если вы ошиблись, кто-нибудь поможет вам исправить. На мой взгляд, баннер страницы обсуждения существует только для того, чтобы попытаться предотвратить войны редактирования из-за этого материала, при этом одна сторона может указать на баннер. В остальное время он бесполезен ни на странице обсуждения, ни в качестве заметки для редактирования. 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)
    • Да, см. Документ {{ British English }}. Это делается с помощью параметра, но идея (я думаю) в том, чтобы использовать оба. Чтобы прояснить, я не хочу сказать, что мы должны закрепить шаблон, который может не иметь смысла, но если мы не хотим, чтобы уведомления о редактировании языка, мы должны удалить их полностью, а не произвольную систему в настоящее время.
      Лично я думаю, что нужно либо сократить это буквально до пункта, а не громоздкого уведомления, либо создать {{ стандарты статей }} для страниц обсуждения. Разумеется, у каждой опции разные цели: первая предназначена для предупреждения редакторов, пишущих о необходимости адаптации их языка, а вторая - для помощи редакторам в «исправлении» ошибок. Лично я не знаю других разновидностей английского языка, поэтому я делаю свои «ошибки» и позволяю кому-то другому копировать их исправления, если им интересно, так что, возможно, последнее будет умнее. 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)

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

• Если это будет принято, как это будет реализовано по сравнению с существующими редакторами, которые уже включают английское разнообразие? То есть см. Википедия: Избранные статьи / Шаблоны 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)

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

Идея автоматического применения 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 (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)

Широко распространено мнение, что ПК не работает / не может использоваться на сильно редактируемых страницах. Поэтому, наверное, никто этого не предлагает. - Изно ( разговор ) 15:44, 2 февраля 2021 (UTC)

Это было доказано во время попытки бэкдора на ПК , статьями Барака Обамы и Джорджа Буша . Объем правок был настолько велик, что очереди по этим статьям постоянно задерживались, и поэтому было и до сих пор принято, что ПК не подходит для страниц, на которых будут редактироваться большие объемы правок, что могло бы произойти с TFA по причине курс. - Голубой Бори v ^ _ ^ v ^{Сильный мужчина отрицает ...} 16:43, 2 февраля 2021 г. (UTC)

По крайней мере, TFA, рассматриваемые в этом обсуждении. В последнее время я видел несколько довольно тихих 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)
• (nom) Я согласен с тем, что любые изменения должны быть пробными.

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

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

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

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

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

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

• Поддержка Единственное отставание, которое может возникнуть с точки зрения ПК, - это одна страница, которую нужно будет регулярно проверять в течение всего срока (и, ну, ПК не такой большой по сравнению с некоторыми другими местами). И, что ж, хотя это может и не остановить все, по крайней мере, любое вандалистское редактирование (которое все равно нужно будет отменить, будь то ПК или нет) не будет заметно отображаться для каждого человека, который туда попадет ... 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)
• Поддержите как пробу . Я согласен с 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)

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Поскольку мои опасения выросли из обсуждения в Джеймсе Каллагане , можно было бы сослаться на Политические WikiProjects. GoodDay ( разговор ) 18:41, 6 февраля 2021 (UTC)

Все должны быть удалены, поскольку ссылки являются спамом из-за дублирования ссылок и чрезмерного размера. Никогда не понимал, почему у нас есть гигантские коробки с очень небольшим количеством ссылок в них, подавляющими разделы. Редактор контента определенно не согласен с тем, что эти ненужные блоки автоматически рассылаются без учета чрезмерных или необоснованных ссылок - Moxy Mo 00:04, 6 февраля 2021 г. (UTC)

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

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

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

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

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

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

• Поддержите, поскольку есть много названий, которые должны иметь квадратные скобки [], но не могут. # тоже проблема. Но, возможно, это можно сделать с помощью механизма DISPLAYTITLE, который позволяет проверять злоупотребления. Фильтр редактирования может проверять наличие ошибок, если установлен стандарт для сопоставления имени. Обратите внимание, что есть и другие символы Юникода, внешне похожие на запрещенные. Грэм Бартлетт ( разговор ) 22:47, 24 февраля 2021 (UTC)
• Нет, по всем вопросам, поднятым Izno Sea Ane ( обсуждение ) 21:46, 26 февраля 2021 года (UTC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вариант А . Я поддерживаю завершение почти готового отхода от недифференцированных многословных параметров. См. Ниже более подробную информацию об этом процессе, который сейчас ставится под сомнение очень немногими редакторами после семи лет работы, и когда он завершен более чем на 90%. С любым другим шаблоном потребовалось бы несколько дней для стандартизации одного стиля имени параметра и преобразования всех включений. Единственная причина, по которой процесс для шаблонов CS1 / CS2 отличается, заключается в том, что используются миллионы включений вместо сотен. - Jonesey95 ( разговорное ) 04:33, 11 февраля 2021 г. (UTC)
• Вариант C . Это бессмысленно заставлять работать; см. расширенный комментарий в разделе обсуждения. Espresso Addict ( разговор ) 07:08, 11 февраля 2021 (UTC)
• B переходит к C. Если бы это было ограничено несколькими тысячами страниц, это не было бы большой проблемой. Но когда это более 3 миллионов страниц, возможно, должно быть наоборот - IE без дефиса. Множество бессмысленных ботинок, просматривающих миллионы страниц для незначительного изменения. Lugnuts ^{Fire, иди со мной} 08:20, 11 февраля 2021 (UTC)
• B, если не C Согласно комментариям выше; Многие редакторы явно довольны формами без дефиса, так почему бы не разрешить и то, и другое? Менять бессмысленно. Многие другие шаблоны позволяют использовать псевдонимы в качестве имен параметров. Я не вижу проблемы. Но мы там, где находимся, поэтому я предпочитаю B, а не C. Питер Коксхед ( разговор ) 09:04, 11 февраля 2021 (UTC)
• Вариант A (второй вариант B ), согласно Jonesey95. Давайте просто все упростим, как и должно быть. Продолжайте и заканчивайте работу. - NSH001 ( разговорное ) 10:18, 11 февраля 2021 г. (UTC)
• Вариант C . Это совершенно бессмысленное занятие. На мой взгляд, текст без дефисов лучше, так как они не переносятся в окно редактирования и могут быть подчеркнуты как опечатка, поэтому они хорошо видны в окне редактирования. Кейт Д. ( разговор ) 13:01, 11 февраля 2021 (UTC)
• C (первый выбор) или B (второй выбор). Я читал множество дискуссий по этой проблеме и никогда еще не видел ничего, что убедило бы меня в том, что отказ от поддержки действительно приносит пользу энциклопедии. Даже если мы предположим для того же аргумента, что это так или иначе, реальное и очевидное нарушение, вызванное ботом до сих пор, и степень изменений, которые отмечает оператор бота, потребуются для выполнения задачи, очень ясно и очень значительно перевешивают то, что выгода. Тридуульф ( разговор ) 15:20, 11 февраля 2021 (UTC)
• Вариант А: это изменение немного болезненно, но его лучше редактировать в долгосрочной перспективе. Лучше внести это изменение, чем не делать этого. Лучшее время было пятнадцать лет назад, но сейчас второе лучшее время. Разрешите боту продолжить свою работу, избавьтесь от всех параметров и, когда все они будут удалены, начните генерировать ошибки цитирования. Elliot321 ( Обсуждение | вклад ) 17:09, 11 февраля 2021 (UTC)
• Вариант А . К сожалению, визуальный редактор существует ... но бесполезен для больших проектов редактирования, и поэтому многие люди до сих пор используют редактирование викитекста - сжатие в одну форму (в частности, форму с переносом через дефис, поскольку ее легче читать редакторам) поможет обеспечить согласованность между статьи хотя бы в шаблонах 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)
• Вариант 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)
• Вариант А Я лично всегда предпочитал форму с дефисом, потому что она позволяла программе проверки орфографии проверять отсутствие опечатки, тогда как форма без дефиса всегда помечается как опечатка, хотя предварительный просмотр теперь сообщает мне об ошибках. Я не согласен с утверждением, что люди могут анализировать |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)

Обсуждение (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 web , например, нет упоминания о том, accessdateчто она устарела. Это означает, что пользователи будут вполне оправданы в блаженном добавлении и чтении шаблонов с помощью accessdate, даже после того, как бот уже прошел и изменил accessdateна access-dateв 20 местах. Каждая итерация имеет тенденцию обращаться к меньшему количеству экземпляров, но каждый запуск - это отдельная запись в моем списке наблюдения. Записи в списке наблюдения, кажется, являются частью жалобы на такого рода работу, поэтому первым шагом должно быть отключение крана у источника, прежде чем тратить энергию на спасение лодки.-  JohnFromPinckney ( разговор ) 06:37, 11 февраля 2021 (UTC)
  • Первое предложение верно; все параметры, состоящие из нескольких слов, кроме шести, были официально объявлены устаревшими и удалены. Что касается «отключения крана в источнике», это был бы вариант А, но в прошлом, когда мы делали красные сообщения об ошибках, появляющиеся в большом количестве статей в качестве первого шага к стандартизации шаблонов цитирования и замечанию ошибок в них , был значительный отпор. Чтобы избежать этого отказа, бот исправлял 90 +% нестандартных параметров перед включением сообщений об ошибках, но эта работа также была остановлена. Вариант А позволит завершить эту работу. - Jonesey95 ( разговорное ) 15:09, 11 февраля 2021 г. (UTC)
    • Я чувствую, что мы не понимаем друг друга. «Устарение» предполагает общение в качестве первого шага; удаление - это второй, более поздний шаг. Если мы хотим, чтобы бот менял страницы ( например , accessdateна access-date), вызывая некоторое беспокойство у населения (и это статус-кво), то мы должны, по крайней мере, изменить документацию, чтобы сказать, что accessdateона устарела и не годится для использования. псевдоним. Я категорически против того, чтобы бот менял параметры на «хорошие» имена, когда мы никогда не говорим людям, что им не следует использовать «плохие» имена. Это просто бесконечный цикл правок, загромождающих списки наблюдения, вызывающих большое раздражение. Если вы хотите избежать возражений, скажите людям, чтобы они не использовали версии без дефиса,тогдазапустить бота, а через некоторое время удалить поддержку. -  Джон Фром Пинкни ( разговор ) 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)

    • Я сам использую шаблоны цитирования, но уважаю пожелания тех, кто предпочитает их не использовать. Именно тот факт, что я их использую, приводит меня к мнению, что очевидные синонимы параметров не следует удалять, как это предлагается здесь. В чем, черт возьми, проблема с разрешением как дефисных, так и неразборчивых форм? Все это означает несколько дополнительных байтов памяти и никакого дополнительного кода, если все сделано правильно. И работа уже проделана, но это предложение ее свести на нет. Живем ли мы по-прежнему в те дни, когда я начал работать в ИТ в одной из ведущих мировых компаний по бизнес-информации, чьи операции в Великобритании велись с компьютера с 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)

Произвольный перерыв 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) ... Y, а также {{ сочинения Баха (источники) }}, которые действительно были |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 -date only, поэтому нарушайте 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)

Значит, решение проблемы редактирования бота против консенсуса для тех, кто возражает, чтобы прекратить его смотреть? Вы не могли придумать это. Опять же, это долбаная энциклопедия, а не место, где технические специалисты диктуют редакторам. Найдите игровую площадку в другом месте или найдите настоящую работу, и вы обнаружите, что люди могут получать деньги за написание программ, только если они делают то, что их пользователи хотят от них. Фил Бриджер ( выступление ) 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)

Новый критерий быстрого удаления (не для Википедии) [ править ]

Это АдГ могло быть решено раньше, если бы существовал этот критерий. Это явно не для Википедии, и в любом случае это был WP: SNOW . Текст следует читать:

А х . Не для Википедии.

Страницы, подпадающие под категорию «Не для Википедии», «Не для Википедии». (шаблоны)

-Или что-то в этом роде. Он должен иметь номер A12. Пожалуйста, учтите это, так как это поможет избежать подобных ненужных АдГ в будущем. AnotherEditor 144 ^{Обсуждение | вклад} 21:56, 14 февраля 2021 (UTC)

Просто позвольте процессу поработать. Его не будет в течение недели. - Малькольмxl5 ( разговор ) 22:18, 14 февраля 2021 г. (UTC)

Ясно, что Википедия не слишком широка и субъективна для критериев быстрого удаления. Мне немного больше нравится AFD snow как критерий быстрого удаления, за исключением того, что иногда может пройти некоторое время, прежде чем кто-то придет и сделает все возможное, чтобы найти источники и сохранить статью. Ere Spiel Checkers 22:45, 14 февраля 2021 г. (UTC)

• Я, конечно, также согласен с тем, что фраза «не для Википедии» слишком широка и субъективна для CSD. Что касается SNOW, это не может быть CSD, потому что в этом случае будущие итерации статьи не будут соответствовать требованиям G4 . Возможно, лучшей идеей было бы создать некую категорию «запрошенного закрытия SNOW» (возможно, заполненную с помощью шаблона), чтобы уведомить администраторов о том, что запрошено закрытие SNOW. Внеочередное письмо ( доклад ) 22:59, 14 февраля 2021 (UTC)

  Разве для этого не потребуется сначала сделать WP: SNOW ориентиром? Adam9007 ( разговор ) 23:09, 14 февраля 2021 (UTC)

  Закрытие Snowball разрешено WP: XFD , что является рекомендацией. Таким образом, я думаю, что запрошенная категория закрытия SNOW будет действительна, хотя детали, вероятно, все же необходимо конкретизировать. (РГ: СНЕГ, вероятно, должен служить ориентиром, хотя я не думаю, что это необходимо для наших целей.) Чрезвычайное письмо ( доклад ) 23:25, 14 февраля 2021 года (UTC)

  Ok. Давайте поговорим о Википедии: критерии быстрого удаления и разберемся с этим. AnotherEditor 144 ^{Обсуждение | вклад} 07:33, 15 февраля 2021 (UTC)

• ( конфликт редактирования ) Это часто предлагаемый критерий для быстрого удаления, действительно настолько важный, что он является первой точкой в WP: NOTCSD . Кроме того, для справки в будущем правильное расположение предлагаемых критериев быстрого удаления - это Википедия: критерии быстрого удаления . Тридуульф ( разговор ) 23:01, 14 февраля 2021 (UTC)

  Ok. AnotherEditor 144 ^{Обсуждение | вклад} 07:28, 15 февраля 2021 (UTC)

• Так следует ли перенести это в обсуждение на странице CSD? Foxnpichu ( разговор ) 14:22, 15 февраля 2021 (UTC)
  • Только если у кого-то есть предложение о чем-то отличном от того, что предлагалось и отклонялось бесчисленное количество раз раньше. Также не беспокойтесь, если он не соответствует всем четырем критериям WP: NEWCSD . Тридуульф ( разговор ) 15:14, 15 февраля 2021 (UTC)
    • Интересно, нужно ли на самом деле изменить имя CSD с "быстрого удаления" - все хотят, чтобы плохие статьи удалялись быстро, поэтому, если CSD не имеет правильных критериев для соответствия странице, от которой я хочу избавиться, тогда мы следует просто расширить список еще немного - до чего-то вроде «не обсуждаемого удаления». WhatamIdoing ( разговор ) 06:42, 16 февраля 2021 (UTC)
      • Интересная идея. В идеале новое имя должно включать что-то, что указывало бы на то, что это исключение из стандартного процесса для исключительных ситуаций, а не то, что просто «что-то не нравится одному или нескольким редакторам». Тридуульф ( разговор ) 12:31, 16 февраля 2021 (UTC)
        • Это проблема. Если статья серьезно нуждается в удалении, лучше удалить ее немедленно. Foxnpichu ( разговор ) 23:05, 16 февраля 2021 (UTC)
          • А как насчет «Статьи о немедленном удалении» (или удалении и т. Д.)? G en Q uest ^"scribble" 17:39, 24 февраля 2021 г. (UTC)

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

Предлагается: эффективно отключить функцию "незначительные правки" в английской Википедии. Его использование будет ограничено только политикой антивандализма. Технически, разрешение на пометку как несовершеннолетнего будет ограничено откатниками, администраторами и ботами. ProcrastinatingReader ( разговор ) 19:56, 15 февраля 2021 (UTC)

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

• Поддержка Очевидно, что некоторые редакторы игнорируют правки "m" в списках наблюдения. Ни один опытный редактор не стал бы этого делать, потому что «m» правки могут быть такими же неправильными, разрушительными или разрушительными, как и «серьезные» правки. Вандалы могут использовать их для совершения вандализма, редакторы-новички добросовестно вносят проблемные изменения, а опытные редакторы могут делать то, что, по их мнению, является незначительным, но другие редакторы не согласны. Действительно, все правки спорны. Задача списка наблюдения - отслеживать статьи . Более того, мы, по всей видимости, блокируем редакторов за незначительные правки. Функционал не только бесполезен, но и является отрицательным. О незначительных изменениях можно сообщить через сводку редактирования и счетчик различий.ProcrastinatingReader ( говорить) 19:56, 15 февраля 2021 г. (UTC)
• Против . Я все время отмечаю правки как незначительные, хотя на самом деле они незначительны. Исправление опечаток и тому подобное не должно беспокоить редакторов, которые не хотят видеть эти правки. Если есть проблема с пометкой несущественных правок как незначительные, выясните, как это исправить. Мы уже помечаем, например, возможные изменения дат рождения и смерти. BD2412 T 20:03, 15 февраля 2021 г. (UTC)
• Выступайте против политики, которая должна быть незначительной только для искоренения вандализма; Я согласен с BD2412 в том, что такие действия, как исправление мелких опечаток, корректировка небольших пробелов и т. Д., По-прежнему должны считаться «незначительными» для целей патрулирования и проверки. Nuetral на перекрывающемся компоненте этого, удаление minoreditразрешения из «Все пользователи» - если оно часто используется не по назначению новыми пользователями, может быть полезным - но если это так, я думаю, что оно должно перейти к + extendedconfirmed и / или другим группам (т.е. rollbacker / patroller), которые в остальном помогают распознать, что редактор имеет здесь хоть какой-то опыт. - ^{Обсуждение} xaosflux 20:23, 15 февраля 2021 г. (UTC)
  • Идеально удачный вариант использования - это бот, который должен очистить неконтентные страницы обсуждения пользователей, объявив незначительное редактирование и используя их nominornewtalkразрешение - оператор может не беспокоить пользователей уведомлением о новых сообщениях. Хотя в первоначальном предложении были «боты», этот вариант использования не соответствует критерию «только антивандализм». - ^{Обсуждение} xaosflux 20:41, 15 февраля 2021 г. (UTC)

    Для ясности я имел в виду антивандализм только для редакторов-людей (боты могут использовать его, как и они). ProcrastinatingReader ( разговор ) 20:44, 15 февраля 2021 (UTC)

    @ ProcrastinatingReader : Хорошо, спасибо, любое использование бота уже должно регулироваться конкретным WP: BRFA для того, что они делают (и это почти всегда используется в дополнение к флагу b'ot). - ^{Обсуждение} xaosflux 20:52, 15 февраля 2021 г. (UTC)

    Что касается опечаток, исправление опечаток все еще может быть оспорено. Возможно, редактор ошибся и опечатка была намеренной. Что еще более важно, комментарий Suffusion of Yellow, особенно о зле , - это хороший способ сформулировать проблему, я думаю . Пока через него могут проходить некоторые спорные правки, вся функция бесполезна. Допуск к антивандализму обусловлен тем, что он уже регулируется существующей политикой WP: ROLLBACKUSE и WP: VAND и т. Д. И позволяет отфильтровывать чистый «мусор». Хотя я тоже согласен с удалением этого исключения. ProcrastinatingReader ( разговор ) 20:55, 15 февраля 2021 (UTC)

• Поддержка . Пока эта функция доступна спамерам, вандалам и невежественным людям, она бесполезна, как и зло . Это также источник ненужной драмы, когда пользователи невинно злоупотребляют им. Но если люди думают, что это предложение заходит слишком далеко, ограничение extendedconfirmedбудет хорошим началом. Suffusion of Yellow ( разговор ) 20:33, 15 февраля 2021 (UTC)
• Противостоять Почему? Майк Пил ( разговорное ) 20:35, 15 февраля 2021 (UTC)
• Поддержка , предварительно, отключение опции при редактировании вручную. Это просто не так полезно; даже опытные пользователи не согласны с тем, что это означает, и не используют его постоянно. Подсчет байтов - это гораздо более эффективный способ с первого взгляда идентифицировать «незначительные» изменения, поскольку он менее подвержен манипуляциям. Поскольку второстепенный флаг может быть установлен неправильно, почти никогда не разумно полностью отфильтровывать второстепенные правки, поэтому он просто действует как слабый сигнал намерения в истории страниц, избыточный для редактирования сводки и счетчика байтов. Однако не уверен в том, что это будет только антивандализм. -  В  Earwig  ⟨ ток ⟩ 20:37, 15 февраля 2021 (UTC)

  После прочтения возражений и рассмотрения альтернативных решений проблемы я не думаю, что это предложение в том виде, в каком оно написано, является правильным. -  В  Earwig  ⟨ ток ⟩ 19:13, 16 февраля 2021 (UTC)

• Противодействовать написанному. Возможно, имеет смысл еще больше ограничить круг лиц, которые могут отмечать правки как незначительные, но почти полное их устранение, поскольку это предложение заходит слишком далеко. Это использование бункерного бункера, чтобы уничтожить несколько шершней. - Calidum 21:11, 15 февраля 2021 г. (UTC)
• Поддержите идею отключения опции пометки правок как незначительных при редактировании вручную. Я действительно не вижу смысла делать только «второстепенное» резюме флага или предоставлять его администраторам или участникам отката. Если мы думаем, что это бесполезно, давайте полностью откажемся от него, вместо того, чтобы пытаться спорить, у кого достаточно опыта, чтобы его использовать. Единственное по-настоящему очевидное применение для мелких правок - это боты, редактирующие страницы обсуждения пользователей, как мудро сказал Xaosflux выше, поэтому боты, очевидно, должны сохранять право по этой причине. Изменения ботов уже можно отфильтровать из списков наблюдения, поэтому, кроме страниц обсуждения пользователей, не имеет значения, являются ли правки ботов незначительными или нет. ƒirefly ( t · c ) 21:35, 15 февраля 2021 г. (UTC)

  Другие варианты использования мелких правок включают (но не ограничиваются):

  • Исправления орфографии
  • Исправления заглавных букв
  • Исправления опечаток
  • Грамматические исправления
  • исправления жирным / курсивом
  • Список исправлений порядка
  • Исправления разметки (шаблоны, таблицы и т. Д.)
  • Небольшие исправления в комментариях (например, пропущенные слова)
  • Подписание неподписанных комментариев
  • Исправления пробелов
  • Добавление шаблонов, которые не влияют или оказывают минимальное влияние на контент (например, {{ По состоянию на }}, {{ Обновить после }}, {{ convert }})
  • Регулировка ссылок
  • Добавление / корректировка сноски
  • Защита / снятие защиты страниц (автоматически помечаются как второстепенные). Тридуульф ( разговор ) 21:53, 15 февраля 2021 (UTC)

• Очень сильная оппозиция . Существует (вероятно) проблема, которую необходимо решить в основе этого предложения, но нет никаких доказательств того, что (а) проблема широко распространена (т.е. что решение заключается в чем-то другом, кроме обучения и / или блокирования отдельных пользователей), ( б) ограничение мелких правок решит основную проблему; (в) ограничение предложенных незначительных правок в той мере, в какой это предлагается, необходимо или соразмерно, или (г) неизбежный сопутствующий ущерб вызовет меньше и менее значительных проблем, чем исходный. Поэтому еще слишком преждевременно выносить это на эту доску, не говоря уже о RfC - это явно не было продумано быстро, не говоря уже о неоднократных, полностью и глубоко. Тридуульф ( разговор ) 21:37, 15 февраля 2021 (UTC)

  Совершенно очевидно, что это не было продумано быстро, не говоря уже о том, чтобы неоднократно, полностью и глубоко. Я обсуждал это с другими редакторами в нескольких AN / ANI в прошлом и в этом году, и это прямо пришло из VPT на этой неделе. Так что это неправда. ProcrastinatingReader ( разговор ) 22:26, ​​15 февраля 2021 (UTC)

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

• Против . Большинство опытных редакторов часто используют второстепенные при выполнении абсолютно бесспорных исправлений опечаток, незначительных изменений форматирования, викификации и тому подобного. Это похоже на ситуацию с детской ванной. Espresso Addict ( разговор ) 00:36, 16 февраля 2021 (UTC)

  Дело в том, что одни люди извлекают выгоду из игнорирования правок, помеченных как незначительные, другие должны продолжать отслеживать все правки. Сейчас это похоже на то, что некоторые люди просто играют с младенцем, не по очереди занимаясь водой в ванне. Это нормально, когда есть достаточно людей, которые не отфильтровывают мелкие правки, но это означает, что фильтрация незначительных правок по своей сути не может масштабироваться, и это заставляет меня беспокоиться о том, чтобы рекламировать ее преимущества для всех. isaacl ( разговор ) 00:59, 16 февраля 2021 (UTC)

  Я думаю, мы говорим здесь о немного других вещах. Я рассматриваю это как сигнал от опытного редактора к опытному редактору, который говорит, что здесь нечего видеть, что однозначно полезно. Вы, я думаю, жалуетесь на то, что редакторы, которые отфильтровывают незначительные правки в списках наблюдения (или, как я, вообще не беспокоятся о списках наблюдения), возлагают бремя на других, чтобы они их проверяли. Это больше проблема в том, как настроены списки наблюдения, а не в том, что правки помечаются как незначительные / нет. Возможно, можно было бы разработать фильтр редактирования, чтобы отмечать изменения, которые явно не второстепенные, и удалять обозначение? Espresso Addict ( разговор ) 02:02, 16 февраля 2021 (UTC)

  К сожалению, сигнал не является надежным. Автоматическое обнаружение мелких правок - это проблема ИИ. Если он работает достаточно хорошо, не будет необходимости в ручной пометке. Это может быть хорошей идеей, но я не уверен, следует ли отдавать ей приоритет перед другими задачами разработчика, особенно с учетом вероятного высокого отношения усилий к выгоде. (Я ценю преимущество сигнала, если он точен, и написал об этом в разделе обсуждения.) Isaacl ( talk ) 03:13, 16 февраля 2021 г. (UTC)

  Я бы не стал категорически возражать против ограничения возможности отмечать правки как второстепенные, например, расширенным подтвержденным редакторами; или, что более полезно, позволить неопытным редакторам продолжать отмечать их (чтобы они научились делать это в соответствии с нормами сообщества), но игнорируя отметки (от неопытных редакторов) в презентациях списков наблюдения. Я не думаю, что в ближайшее время ИИ сможет достаточно точно их различать. Espresso Addict ( разговор ) 03:48, 16 февраля 2021 (UTC)

  В нем уже есть возможность фильтрации на основе опыта и незначительных правок (а также прогноза качества вклада), но я не думаю, что он может быть установлен для всех правок неопытных редакторов плюс немалых правок от опытных редакторов. Проблема надежности остается даже у опытных редакторов, поэтому кто-то должен проверять все незначительные правки. isaacl ( разговор ) 04:06, 16 февраля 2021 (UTC)

• Против, но готовы к реформированию . Обозначение второстепенного редактирования - это часть информации, как и сводка редактирования, которую следует рассматривать в контексте. Когда я вижу букву «m» рядом с уважаемым именем пользователя, это избавляет меня от необходимости просматривать правку. Когда это рядом с гигантским редактированием IPпользователь с повторной ссылкой с подозрительным резюме, это другое. По этой причине я не отфильтровываю их из своего списка наблюдения, но если кто-то еще захочет это сделать, он сможет. Тем не менее, я согласен, что неправильное использование небольшого поля редактирования является проблемой. Вот более скромное предложение: ограничьте его редакторами с автоподтверждением, и при первой проверке пусть программа генерирует всплывающее окно, которое быстро объясняет, что мы подразумеваем под «второстепенным». При этом мы могли бы занять более жесткую позицию в отношении неправильного использования коробки, поскольку никто не мог утверждать, что просто не знал. Это может приблизить нас к моменту, когда больше редакторов будут чувствовать себя комфортно, фильтруя незначительные правки из своего списка наблюдения. {{u | Sdkb }}  ^talk 07:19, 16 февраля 2021 г. (UTC)

  @ Sdkb : если я чего-то не упускаю , IP не может помечать правки как второстепенные (пожалуйста, укажите на любые различия, если вы их видите). Неподтвержденные пользователи могут - поэтому следующим «маленьким шагом» будет удаление этого доступа из списка «Все пользователи» и предоставление его «автоматически подтвержденным» пользователям. - ^{Обсуждение} xaosflux 14:30, 16 февраля 2021 г. (UTC)

  Вы правы; Я исправил свою гипотетическую ошибку. {{u | Sdkb }}  ^talk 18:34, 16 февраля 2021 г. (UTC)

  @ Sdkb : это оба шага, которые я могу поддержать, а также, возможно, ограничение в байтах для размера изменения, которое все еще будет помечено как незначительное. BD2412 T 17:57, 16 февраля 2021 г. (UTC)

  Ограничение байта может быть непростым; Отмена вандализма, закрывающего страницу, - очень допустимое незначительное изменение, поскольку оно явно не вызывает споров. В качестве альтернативы, может быть, запретить, если ORES помечает это как возможно неконструктивное? {{u | Sdkb }}  ^talk 18:38, 16 февраля 2021 г. (UTC)

  Что-то в этом роде определенно пригодится, да. BD2412 T 00:20, 17 февраля 2021 г. (UTC)

• Поддержка . Флажок усложняет процесс внесения каждого редактирования, что дает очень мало пользы другим редакторам и вызывает небольшое беспокойство, если, возможно, ошибаюсь. В среднем я каждый раз трачу от полсекунды до секунды на это решение. Подсчитывая, в сумме получается от 2 до 4 рабочих недель моей жизни за последнее десятилетие. - Джон Рединг ( разговор ) 08:28, 16 февраля 2021 г. (UTC)

  @ John of Reading : если вас это беспокоит, вы можете добавить эту строку в свой Special: MyPage / common.css, и вам больше не придется видеть это окно:

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

  - ^{Обсуждение} xaosflux 19:57, 16 февраля 2021 г. (UTC)

  @ Xaosflux : Я чаще всего использую флажок в AWB, а не в окне редактирования. Но если я скрою флажок или всегда оставляю его неотмеченным, а некоторые другие редакторы думают, что это различие важно, я не смогу правильно сообщить им, что большинство моих правок незначительны. - Джон Ридинг ( выступление ) 20:09, 16 февраля 2021 г. (UTC)

• Сильно возражайте как ненужное и бесполезное. Большая часть моих собственных правок незначительна, и мне нравится возможность разделять группы (хотя бы для меня). Нет причин, по которым другие люди должны тщательно просматривать мои правки, когда все, что я делал, это исправлял орфографию, исправлял формат даты или убирал пробелы перед ними <ref>и т. Д. -  Джон Фром Пинкни ( доклад ) 18:11, 16 февраля 2021 (UTC)
• Поддержите ограничение отметки "незначительное редактирование" для опытных пользователей. Это очень ненадежно для новичков. - Vis M ( разговор ) 21:04, 16 февраля 2021 г. (UTC)
• Противодействие Предполагаемое возвращение вандализма не обязательно незначительное. И тот факт, что флаг может быть неточным, точно так же, как и все остальное в Викпедии. Каждая отдельная страница, редактирование, сводка или что-то еще может быть неточным. Согласно отказу от ответственности «ВИКИПЕДИЯ НЕ ДАЕТ ГАРАНТИЙ ДЕЙСТВИЯ». Эндрю 🐉 ( разговор ) 23:12, 16 февраля 2021 (UTC)
• Возражать на BD2412 и xaosflux. Хотя я готов запретить редакторам, не прошедшим автоподтверждение, отмечать правки как «незначительные», я не согласен с основной частью предложения. Sdrqaz ( разговорное ) 20:42, 18 февраля 2021 (UTC)
• Ограничение до автоподтверждения. Любой потенциальный ущерб от неправильного использования флага второстепенного редактирования минимален - наравне с перемещением страницы. Требуется время, чтобы понять, что является второстепенным, а что нет, и мы уже ограничиваем IP-адреса. Хотя мы, безусловно, можем улучшить наши рекомендации по использованию флага второстепенного редактирования, уровень угрозы не требует ограничения редакторов с автоподтверждением, которым мы уже доверяем, с гораздо более мощными инструментами в их руках. - WUG · а • ро · дез 22:31, 18 февраля 2021 (UTC)
• Ограничить автоподтверждением . Мы уже запрещаем IP-адресам использовать ящик, и можно предположить, что новые пользователи также неопытны. Однако это определенно полезно для exconf +, и, поскольку это, в общем, второстепенная функция, autoconf также должен иметь к ней доступ. Был бы открыт для идеи Sdkb о появлении всплывающего окна, когда кто-то впервые ставит галочку в поле, хотя я не уверен, выполнимость этого со стороны программного обеспечения. - python coder  ( обсуждение  |  вклад ) 19:54, 19 февраля 2021 г. (UTC)
• Nein - мелкие правки - это правки, которые хорошо, незначительные. Если мы помечаем их как серьезные правки, это только приведет к потере времени редакторов в отставании патрулирования RC. - Предшествующий неподписанный комментарий добавлен Awesome Aasim ( обсуждение • вклад ) 03:15, 21 февраля 2021 г. (UTC)
• Ограничить автоподтверждением . Для опытных пользователей, особенно при работе с другими редакторами, это важный флаг. Любой, кто не доверяет флагу второстепенного редактирования, все равно может просматривать все изменения, так почему же может возникнуть необходимость в удалении этой функции? ThoughtIdRetired ( обсуждение ) 15:07, 21 февраля 2021 (UTC)
• Я категорически против предложенной идеи, но согласен с Pythoncoder (это второй RfC на сегодняшний день, с которым я согласился с ним), что ограничение его до autoconfirmed - хорошая идея. JJP ... МАСТЕР! _{[поговорить с] JJP ... господин?} 01:55, 22 февраля 2021 (UTC)
• Поддержка комментариями : (1) Администраторам должно быть разрешено помечать любые свои правки, связанные с вандализмом или нет, как «незначительные», если они считают это полезным для сообщества. Для остальных из нас (редакторов, не являющихся ботами) откат кажется таким же хорошим порогом, как и любой другой. (2) «Незначительное» может перестать быть оптимальным названием для тега. «Процедурный» может быть более подходящим? Понятия не имею, есть ли способ изменить это ради новых редакторов. - jameslucas ▄▄▄ ▄▄▄ ▄▄▄ 03:14, 23 февраля 2021 г. (UTC)
• Противодействовать Мелкие правки важны - небольшие изменения в разметке, написании, пробелах, заглавных буквах, изменения / обновления чисел, исправление опечаток: это мелочи, которые заставляют работать большую машину. Удаляя «мелкие правки» в качестве тега, вы рискуете завалить временную шкалу беспорядком и потенциально отговорить редакторов от внесения необходимых незначительных изменений. doktorb _слова ^дела 07:25, 23 февраля 2021 (UTC)
• Против Майка Пила. - Джейрон, 32 19:31, 24 февраля 2021 г. (UTC)
• Против . Если кто-то ненадлежащим образом помечает несущественные правки как незначительные, это проблема поведения пользователя, а не причина отказываться от незначительных правок. Если говорить от имени человека, который, по всей видимости, внес 318 850 мелких правок, это не принесет пользы и вызовет очевидные неудобства, если читатели, которых не нужно извещать каждый раз, когда я тихонько ищу и заменяю орфографическую ошибку "targetted", не смогут отфильтровать ее из своих список наблюдения. Это также сделало бы просмотр историй вклада редакторов (будь то такие процессы, как RFA, или просто «Я ищу разницу в той правке, которую вы внесли на прошлой неделе») на порядки более сложным, без очевидной выгоды. -  Радужный 19:45, 24 февраля 2021 г. (UTC)
• Против - Лично я никогда не использую его, даже если я действительно вношу незначительные правки ... Это действительно слишком много усилий, нажимая на одно поле каждый раз, когда я хочу сохранить изменения ... что, как говорится, не использовать его, не причина для поддержки, и не было объяснено, почему это должно быть отключено в первую очередь. - ^{Обсуждение} Дэви 2010 23:12, 24 февраля 2021 г. (UTC)
• Против . Я в некоторой степени симпатизирую этому предложению, но проблема и ее объем нуждаются в более четком определении, а предлагаемое решение кажется слишком радикальным. Я все время отмечаю отредактированные правки как второстепенные; то же самое для редактирования вручную. Если функция используется правильно, я считаю ее весьма полезной; если правка помечена как незначительная в моем списке наблюдения или в истории страницы, я с большей вероятностью проигнорирую это изменение. Я согласен, вероятно, это некоторая проблема с неправильным использованием этой функции, но на данный момент я не уверен в масштабах проблемы. Возможно, менее радикальные решения, такие как ограничение класса пользователей с правами пользователя отмечать правки как незначительные, и попытка дать более точное определение того, что составляет незначительное изменение, были бы полезны, и их следует попробовать в первую очередь. Nsk92 ( обсуждение) 23:50, 24 февраля 2021 г. (UTC)
• Противоположные незначительные правки полезны, чтобы различать, ну, какие правки незначительны. Если мелкие правки отключены, у нас нет возможности различить здесь, поэтому мы теряем информацию. Потенциально ошибочная информация - например, неправильно отмеченные мелкие правки - хуже, чем отсутствие информации. Возможно, ограничение до автоподтверждения, а в худшем случае - до расширенного подтвержденного, но полное удаление - не лучшая идея. Elliot321 ( Обсуждение | вклад ) 01:53, 28 февраля 2021 (UTC)
• Противодействовать согласно предложению Xaosflux. Я готов ограничить незначительные правки до autoconfirmedили extendedconfirmed, но не так, как было предложено. Твассман | Обсуждение | Вклад 06:48, 28 февраля 2021 (UTC)

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

Хотя флаг незначительных правок нельзя использовать для фильтрации всех правок, его можно использовать (визуально) для фильтрации правок от известных вам редакторов. Это преимущество, конечно, доступно только вам, если некоторые из ваших известных редакторов действительно используют этот флаг. isaacl ( разговор ) 21:13, 15 февраля 2021 (UTC)

@ ProcrastinatingReader , можно ли решить вашу актуальную проблему, изменив настройки prefs по умолчанию, чтобы отображались незначительные правки? Whatamidoing (WMF) ( обсуждение ) 21:55, 15 февраля 2021 (UTC)

У меня проблема в том, что эта функциональность не имеет смысла. Я не думаю, что когда-либо имеет смысл скрывать мелкие правки в списке наблюдения. Тем не менее, сам индикатор может быть полезен, но он по-прежнему избыточен для итоговой суммы + счетчик байтов. Я думаю, что «Суффузия желтого» и комментарии уховертки лаконично выражают мои опасения. Моя вторая проблема заключается в том, что отдельные администраторы думают, что блокировка даже одного редактора за использование им второстепенного индикатора (например, или блокирование отдельных пользователей ) уместно. Я думаю, что проблема возникает достаточно часто, поскольку у нее есть раздел на странице политики ( Wikipedia: Vandalism # Gaming_the_system ). ProcrastinatingReader ( разговор ) 22:22, 15 февраля 2021 (UTC)

Если бы вы могли настроить определенные редакторы, для которых мелкие правки будут отфильтровываться, это могло бы быть более полезным. Но, учитывая небольшой объем использования и объем накладных расходов, необходимых для такого уровня фильтрации, я не думаю, что это стоит затрат на разработку и постоянное поддержание. isaacl ( разговор ) 22:40, 15 февраля 2021 (UTC)

Как узнать, какие редакторы отфильтровать? Я думаю, что будет сложно составить исчерпывающий список редакторов, которые не могут использовать эту функцию. Если это локальный список, редакторам будет очень сложно его поддерживать (кроме того, если у вас есть скрытые незначительные правки, как узнать, какие редакторы неправильно используют второстепенную функцию для добавления в список, так как, ну, вы выиграли? не вижу их правок?) Если это глобальный список, я чувствую более бессмысленную драму ANI. Кроме того, это могут быть просто разовые правки, требующие более тщательной проверки, а не постоянная неспособность определить, что является незначительным, а что нет. ProcrastinatingReader ( разговор ) 22:44, 15 февраля 2021 (UTC)

Отдельные пользователи должны будут решить, кому они доверяют должным образом отмечать незначительные изменения, а затем соответствующим образом настроить свой список наблюдения. Но, как я уже сказал, я не думаю, что работа по реализации этого оправдывает выгоду. Я не осознавал, что текущие возможности фильтрации позволяют настраивать уровень опыта; Я не уверен, полезно ли это для чьего-либо списка наблюдения. isaacl ( разговор ) 00:03, 16 февраля 2021 (UTC)

@ ProcrastinatingReader , если функция не имеет для вас смысла, то почему вы предлагаете, чтобы определенные редакторы продолжали ее использовать?

Я думаю, имеет ли это смысл, зависит от того, какую версию списка наблюдения вы смотрите. Если каждое редактирование отображается отдельно, это может позволить вам пропустить множество правок, которые вы не хотите видеть (например, ClueBot отменяет простой вандализм , помеченный как «незначительный», но не как «ботовое» правка).

Флаг второстепенного редактирования также отображается в Special: RecentChanges . Это позволяет заинтересованным редакторам фильтровать (например) незначительные правки менее опытных редакторов, которые являются самой последней версией страницы . Я полагаю, что это будет интересный список как для патрульных, занимающихся антивандализмом, так и для людей, ищущих многообещающих редакторов. Whatamidoing (WMF) ( обсуждение ) 23:05, 15 февраля 2021 (UTC)

Ответ на первый абзац - это ваш второй абзац: чтобы ClueBot и Hugglers, устраняющие простой вандализм, могли и дальше исключаться из списков наблюдения. Это не столько ограничение для определенных редакторов, сколько ограничение для определенной цели . Даже лицам, выполняющим откат и администраторам, не разрешено отмечать как незначительные «грамматические изменения», например, в рамках этого предложения. ProcrastinatingReader ( разговор ) 23:21, 15 февраля 2021 (UTC)

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

Например, это изменение явно незначительное, но оно не имеет ничего общего с вандализмом. Тридуульф ( разговор ) 12:39, 16 февраля 2021 (UTC)

• Поскольку это предложение вряд ли получит консенсус в том виде, в каком оно написано, вот совершенно другое предложение, более узко направленное на то, что я вижу, является наиболее вопиющей проблемой: тот факт, что мы время от времени блокируем продуктивных редакторов за неправильное использование функции незначительного редактирования. Разрешить администраторам отключать флаг второстепенного редактирования для редактора как часть интерфейса блокировки, в том же духе, что и частичная блокировка или отключение электронной почты, но без ограничения возможности редактирования. -  В  Earwig  ⟨ ток ⟩ 15:21, 16 февраля 2021 (UTC)
  • Две мысли. Во-первых, возможно ли это технически? Если нет, я думаю, что это вряд ли пройдет через phab, и даже если это произойдет, мы столкнемся с проблемой, когда люди будут сообщать друг другу даже больше, чем сейчас, в ANI за «незначительные нарушения маркировки редактирования» для «незначительного блока редактирования». Во-вторых, эта функция все равно была бы бесполезна, я полагаю, это всего лишь мой идеализм; если редакторы не блокируются из-за этого, меня это не волнует. ProcrastinatingReader ( разговор ) 16:40, 16 февраля 2021 (UTC)

    В настоящее время невозможно, потребуется время разработчика. Полагаю, одно это делает его безнадежным. Но мне все еще интересно, как мы можем решить эту проблему более целенаправленно. -  В  Earwig  ⟨ ток ⟩ 16:52, 16 февраля 2021 (UTC)

    Действительно, в настоящее время это технически невозможно, но в последнее время было проделано много работы над частичными блоками, и пометка правок как незначительных - это то, что предоставляется только подгруппе пользователей, поэтому мне кажется, что это будет то, что будет возможно. с разумным объемом работы (правда, я не разработчик). Думать о способах решения реальной проблемы целенаправленно, чтобы не причинить серьезного сопутствующего ущерба, - это абсолютно правильный поступок, хотя - действительно, это то, что нужно было сделать до того, как прийти сюда с предложением, пусть только RFC. Тридуульф ( разговор ) 17:25, 16 февраля 2021 (UTC)

    @ The Earwig and ProcrastinatingReader : я создал для этого задачу phab, см. Phab: T274911 . Тридуульф ( разговор ) 17:29, 16 февраля 2021 (UTC)

    Поскольку minoreditэто отдельное право пользователя, если бы оно было назначено ботом, а не являлось набором разрешений для всех пользователей, его можно было бы удалить у любого, кто использовал его ненадлежащим образом. isaacl ( разговор ) 19:36, 16 февраля 2021 (UTC)

    @ Isaacl : Я думаю, ты тут перепутаешь некоторые термины? Можно было бы создать группу , включающую minoredit разрешение ; и можно было бы сделать его автоматически назначаемым один раз на пороге (например, extendedconfirmed), чтобы его можно было отозвать, но это много накладных расходов для такого небольшого разрешения (и я не думаю, что мы получим «боты» вообще задействованы в этом процессе). - xaosflux ^Talk 19:50, 16 февраля 2021 г. (UTC)

    Я мало о чем знаю, так что почти наверняка. Я не стал говорить о группах для простоты, и я не знал (или забыл) об автоматическом назначении один раз; мои извинения. Да, это будет накладными расходами, но меньше, чем расширение возможности частичного блока для поддержки блокировки пользователя от отметки незначительных правок. isaacl ( разговор ) 19:55, 16 февраля 2021 (UTC)

    Также было бы возможно, без каких-либо накладных расходов в общем случае или усилий по кодированию, создать группу, которая исключает возможность вносить незначительные изменения с помощью $ wgRevokePermissions . Этот способ также позволяет избежать проблемы, когда блоки воспринимаются как пятно в записях людей, на что указывает Suffusion of Yellow ниже. Тем не менее, я далеко не уверен, что все это действительно хорошая идея. * Pppery * началось ... 23:38, 16 февраля 2021 (UTC)

    @ Pppery : после быстрой проверки у нас есть ровно один проект, использующий эту настройку во всем WMF, и похоже, что они не использовали его более 10 лет, поэтому я шокирован, что он все еще существует (похоже, может быть объединен t pblocks - см. phab: T227618 ). Конечно, это оставляет «пятно» в журнале прав пользователя (например, w: ta: Special: Redirect / logid / 58001. - xaosflux ^Talk 00:11, 17 февраля 2021 (UTC)

    Насколько я помню, когда я работал с другой реализацией Wiki, которая имела аналогичную функциональность, она может быть полезна в корпоративной среде при определении групп пользователей и управлении их разрешениями. isaacl ( разговор ) 00:20, 17 февраля 2021 (UTC)

  • Это был бы фантастический источник драмы. Блок (даже частичный) - это не просто техническая неспособность что-то сделать, он (к лучшему или худшему) будет рассматриваться пользователем как «пятно» на его записи. Для такой тривиальной вещи это того не стоит. Suffusion of Yellow ( разговор ) 20:00, 16 февраля 2021 г. (UTC)
• Когда вы видите правку ± 10k, помеченную как незначительную, вы знаете, что редактор почти наверняка не подходит. Нарки Блерт ( разговорное ) 17:55, 16 февраля 2021 (UTC)
• По всей видимости, более семи тысяч пользователей были предупреждены за то, что они пометили несущественные правки как незначительные. Случалось ли когда-нибудь обратное ? IE "вы исправляете опечатки, но не отмечаете их как незначительные, пожалуйста, начните использовать флаг, или я перетащу вас в AN / I". Suffusion of Yellow ( разговор ) 19:52, 16 февраля 2021 (UTC)

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

• Я удивлен, что продуктивных редакторов блокируют за использование незначительных пометок редактирования. Есть ли больше случаев, чем тот, который упоминал уховертка выше? Этот конкретный случай кажется весьма необычным, поскольку редактор явно использует приложение iOS, которое не получает уведомлений и, следовательно, не отвечает на отзывы. Тот, кого заблокировали за вандализм, помеченный как несовершеннолетний, явно заблокирован за вандализм. Espresso Addict ( разговор ) 00:44, 17 февраля 2021 (UTC)

  Хороший вопрос, Эспрессо-наркоман . Я откопал несколько примеров, когда редакторы были заблокированы за пометку правок как незначительные. В большинстве случаев, конечно, есть и другие причины блоков: [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14 ] ] [15] [16] [17] [18] . -  В  Earwig  ⟨ ток ⟩ 7:37, 17 февраля 2021 (UTC)

• Комментарий . Я проголосовал против вышеупомянутого и указал, что готов ограничить круг лиц, которые могут отмечать правки как незначительные. Я заметил, что несколько человек с тех пор предлагали разрешить только автоматически подтвержденным пользователям отмечать изменения как незначительные, но у меня сложилось впечатление, что это уже было ограничено автоматически подтвержденными пользователями. Если нет, то я не вижу причин, по которым этого не должно быть. - Calidum 21:11, 24 февраля 2021 г. (UTC)

  @ Calidum : Текущая ситуация такова, что вам не нужно быть автоматически настроенным, чтобы отмечать изменения как незначительные, просто войдите в систему . - Red rose64 🌹 ( обсуждение ) 17:12, 25 февраля 2021 (UTC)

• Некоторые из тем, за которыми я слежу, подвержены вандализму от первого лица. Часто вандалы пытаются скрыть свой вандализм за меткой «незначительное изменение». Это (как ни странно) весьма полезно, когда дело доходит до обнаружения и устранения такого вандализма ... Я научился уделять особое внимание правкам, которые помечены как «незначительные». Таким образом, я бы против отказа от тега. Blueboar ( разговор ) 23:03, 24 февраля 2021 (UTC)

Штампы даты занятий [ править ]

Некоторые статьи имеют на странице обсуждения ярлык качества в виде уровней класса. Однако довольно сложно узнать, когда была сделана оценка, и часто оценка может быть несколько лет назад и не соответствовать текущему уровню статьи. Можно ли добавить отметку времени к этим оценкам (так же, как для шаблонов, указывающих на необходимость редактирования в самой статье)? В идеале это должно быть сделано задним числом, когда роботы будут добавлять временные метки ко всем уже выполненным оценкам. - Олле Терениус (UU) ( разговорное ) 11:17, 16 февраля 2021 (UTC)

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

Не то, чтобы у меня была какая-то подсказка или участие в проектах по оценке статей, но разве такое объединение не было бы потенциально трудным, особенно? когда задействовано больше, чем пара проектов? Я имею в виду, что статью (ныне вымышленную) « Военная музыка Польши» можно рассматривать как гипотетический случай. Польский проект им доволен и высоко оценивает его, но ребята из музыкального проекта видят, что в нем отсутствует кучка необходимой музыки, хм, всего, что им нужно. У военного экипажа может быть третье мнение о качестве статьи. И снова я понятия не имею, насколько реалистичен этот сценарий. -  JohnFromPinckney ( разговор ) 03:30, 17 февраля 2021 г. (UTC)

[Править конфликт] Хотя я вижу, что некоторым людям не нравится загромождать страницы обсуждений множественными оценками, для разных проектов характерны разные стандарты, и материал одного проекта хорошо освещается, а другой отсутствует. Как бы нам решить, чье мнение преобладает? Кроме того, если бы оценки были едиными, что произошло бы с оценками важности, которые явно различаются между проектами? Espresso Addict ( разговор ) 03:38, 17 февраля 2021 (UTC)

Я в основном согласен с этим, но некоторые проекты (например, военный википроект) проводят свою собственную оценку (например, рейтинги класса A). Это должно продолжаться. Но большинство проектов на самом деле не так активны или хорошо организованы, как MILHIST, и большинство рейтингов даже составляются не членами WP, а просто патрулями страниц и т. Д. Так что, возможно, что-то в системе должно улучшиться. ProcrastinatingReader ( разговор ) 05:26, 18 февраля 2021 (UTC)

Оценка per-wikiproject мертва, и ее следует просто исключить. Он уже официально перезаписан для GA и FA, и я не уверен, что это когда-либо произойдет за пределами MILHIST A-класса. Если MILHIST оценивает статью как A-класс, этот рейтинг должен применяться к качеству статьи в целом и может получить единственную метку времени, как это делают в настоящее время GA и FA. CMD ( разговор ) 07:21, 23 февраля 2021 (UTC)

• Это звучит как хорошая идея, и если бы это могли сделать боты, это могло бы оказаться несложным. Ролло Август ( разговор ) 09:18, 20 февраля 2021 (UTC)

Уведомление о RFC [ править ]

Пользователи могут быть заинтересованы в RFC на Википедии: Перемещение страницы / перенаправление удаления § RFC о предоставлении перенаправления удаления для перемещающих страниц . Спасибо, - DannyS712 ( разговор ) 23:29, 18 февраля 2021 (UTC)

Конкурс научной фотографии 2021 Россия нацелен на баннер CentralNotice [ править ]

1 марта стартовал « Конкурс научной фотографии 2021 » , традиционно фотомарафон проводится совместно с телеканалом «Наука», будет интересно. Приглашаем всех, кто интересуется наукой и умеет держать фотоаппарат в руках. Правила конкурса очень простые, призы есть где быть! Коллеги, для привлечения внешних участников мы предложили баннер конкурса через CentralNotice. JukoFF ( разговорное ) 11:43, 21 февраля 2021 (UTC)

Предложение CentralNotice по случаю Международного женского дня [ править ]

Было внесено предложение запустить баннер CentralNotice как для анонимных, так и для авторизованных пользователей с 1 по 10 марта в Международный женский день , подчеркнув проблемы гендерного разрыва. Предложение находится по адресу m: CentralNotice / Request / Int. Женский день 2021 . - Яир Рэнд ( разговор ) 11:36, 22 февраля 2021 (UTC)

Я всего лишь человек, но может кто - нибудь сказать мне , когда Международный женский день является ? Знаешь, свидание ? Ни одна из этих двух ссылок не говорит мне, когда должна быть эта проклятая штука. Думаю, все женщины уже знают это, но если мы все должны праздновать это или это должно что-то значить, почему это держится в таком большом секрете? -  JohnFromPinckney ( разговор ) 02:09, 23 февраля 2021 г. (UTC)

Международный женский день - 8 марта. - Малькольмxl5 ( разговор ) 02:25, 23 февраля 2021 (UTC)

Может быть, причина, по которой все женщины уже знают, когда это, в том, что они пытались щелкнуть ссылки или прочитать первое предложение Международного женского дня . ¯ \ _ (ツ) _ / ¯ Levivich  ^харасс / _гончая 02:29, 23 февраля 2021 (UTC)

Если вам не нравится Google, то есть эта отличная онлайн-энциклопедия, в которой есть статьи о подобных вещах и многом другом. Это называется Википедия, возможно, вы о ней слышали? Во всяком случае, вы можете найти их статью в Международный женский день , и в самом первом предложении говорится, что Международный женский день (IWD) ежегодно отмечается 8 марта во всем мире. там есть цитата и все такое! Тридуульф ( разговор ) 02:32, 23 февраля 2021 (UTC)

Да, друзья, спасибо, что предоставили настоящую дату вместе с язвительными замечаниями. Я был на 98,3% уверен, что кто-то скажет: «Но это прямо там большими <цветными> буквами!», И я просто не заметил этого. И да, я могла бы погуглить или поискать статью в WP о Международном женском дне , но я по глупости последовала за предоставленной ссылкой на Международный женский день , думая (вроде на автопилоте), что это должно быть оно .

И хотя это хорошо и правильно, что в Международный женский день (несвязанный) была указана дата, я все же думаю, что две другие страницы, которые имеют большое значение в «Международном женском дне», по крайней мере упомянули бы, когда это так . Знаете, для нас, невежественных людей, которые могут чему-то научиться. Я знаю, когда сегодня Рождество, четвертое июля и Новый год, но я еще не изучил IWD. Или, может быть, я узнаю это сейчас. -  JohnFromPinckney ( разговор ) 04:20, 23 февраля 2021 (UTC)

Вторая ссылка в ОП, вверху страницы: один глобальный баннер к Международному женскому дню 2021 года, доступный для всех мероприятий по гендерному разрыву примерно 8 марта. Levivich ^харасс / _гончая 04:27, 23 февраля 2021 (UTC)  

Ах, теперь я это вижу. У меня все равно ушла целая минута, даже с учетом ваших указаний Спасибо. -  JohnFromPinckney ( разговор ) 04:36, 23 февраля 2021 (UTC)

Пожалуйста. Как мужчина, я горжусь, что ты даже спросил дорогу. Levivich  ^харасс / _гончая 05:52, 23 февраля 2021 (UTC)

Международный мужской день - 19 ноября. Эмир Википедии ( разговор ) 21:51, 23 февраля 2021 (UTC)

Ну, снимай, все знают , что . Мелкая, привередливая деталь: я даже не знала, что есть Международный мужской день . -  JohnFromPinckney ( разговор ) 22:47, 23 февраля 2021 г. (UTC)

• Против - WP не должна заниматься адвокатской деятельностью - каким бы благородным оно ни было. Просто потратьте день на улучшение статей о женщинах. Blueboar ( разговор ) 15:33, 25 февраля 2021 (UTC)

Это не отстаивание причины, это уведомление, обращающее наше внимание на несколько событий, направленных на заполнение пробелов в энциклопедии. - Малькольмxl5 ( разговор ) 15:35, 25 февраля 2021 г. (UTC)

Подтверждая поддержку этого центрального уведомления. Вы можете не согласиться с защитой, но стоит отметить, что английская Википедия в целом занимается защитой, например, Wikipedia: инициатива SOPA , и, хотя сообщество не санкционировано, Фонд Викимедиа подал в суд на АНБ . Само по себе это мероприятие не является пропагандой и, в частности, является призывом улучшить контент в Википедии. Шушуга ( разговорное ) 15:49, 25 февраля 2021 (UTC)

Я стараюсь по возможности избегать частого празднования таких дней, потому что они часто служат предлогом для игнорирования актуальных вопросов до конца года, но если это побуждает людей принимать участие в мероприятиях, направленных на улучшение Википедии, тогда я не вижу причин для противостоять этому. Это не пропаганда, как когда я говорю людям, что они должны думать, чему я против. Фил Бриджер ( выступление ) 16:32, 25 февраля 2021 (UTC)

• Я считаю, что фактическое предложение по баннеру было сделано на мета. Исходное сообщение Яира Рэнда выше содержит ссылку. Вероятно, редакторы, желающие выразить поддержку / опровержение мнения, должны делать это там, а не здесь. Nsk92 ( разговор ) 18:11, 25 февраля 2021 (UTC)

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

На мой взгляд, было бы лучше разрешить редактирование страницы пользователя и ее подстраниц только «владельцу страницы». Например, если пользователь X создает свою страницу, только он сможет ее редактировать - Dr Salvus ( обсуждение ) 15:15, 25 февраля 2021 (UTC)

Есть много причин, по которым не «владельцы» захотят редактировать такие страницы. Статьи пользователя. Перемещение черновиков AfC. Пометка на удаление. Маркировка носков. Исправление синтаксических ошибок. Отключение категорий основного пространства. Удаление изображений добросовестного использования. Удаление оскорбительного содержания. Устранение нарушений авторских прав. Пользователь может быть альтернативной учетной записью. Это может быть учетная запись бота. Он может содержать общедоступную страницу / список для редактирования / обслуживания. А еще есть архивы страниц обсуждения пользователей. И т. Д. И т. Д. -  АД ЗНАЕТ    ▎ РАЗГОВОР 15:21, 25 февраля 2021 г. (UTC) 

Обратите внимание, что пользователям без автоподтверждения уже запрещено редактировать пользовательские страницы с помощью фильтра редактирования . Я не верю, что есть какая-либо причина, по которой пользовательские страницы должны быть ограничены таким образом, существует множество причин (как указано выше) для редактирования страниц в чужом пользовательском пространстве. - csc ^-1 20:49, 25 февраля 2021 г. (UTC)

Было бы полностью против существующего консенсуса сообщества в Википедии: Право собственности на контент и Википедии: Страницы пользователей # Право собственности и редактирование страниц пользователей . Как уже упоминалось, уже существует фильтр редактирования для предотвращения вандализма неподтвержденными редакторами пользовательских страниц, которые им не принадлежат. ✨ Эд говорить! ✨ 21:06, 25 февраля 2021 г. (UTC)

• Иногда могут быть полезны правки на пользовательской странице. В случае получения амбарных звезд это, безусловно, должно укрепить чувство уверенности. Ролло Август ( разговор ) 19:28, 28 февраля 2021 (UTC)

За последний год я трижды видел здесь это предложение. Почему бы не сделать это предложение WP: PERENNIAL ? 🐔  Chicdat   ^{Bawk мне!} 11:54, 1 марта 2021 г. (UTC)

• Должны ли мы , включая все страницы в UserSpace пользователя (страницы основного пользователя, связанной с ней странице обсуждения ... а также любые проектами / страницы песочницы и их ассоциированными страницы обсуждения) , или мы , ограничивающие это обсуждение на только начальную страницу пользователя? Blueboar ( разговор ) 13:34, 1 марта 2021 (UTC)

Добавление дополнительной информации в шаблоны [ править ]

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

Идеи

Я предлагаю вот что.

Принцип: прогрессивный, нейтральный или консервативный

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

Например. Это всего лишь пара исторических личностей, которые могут дать вам представление.

Прогрессивные: Ода Нобунага, Цинь Шихуан, Датэ Масамунэ и Цао Цао.

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

Нейтрально: Сунь Цюань, Санада Юкимура, Чжан Ляо, Минамото-но Ёсицунэ и Токугава Иэясу.

Те, кто не желает присоединиться ни к одной из сторон, будь то конфликт, война, религиозный вопрос и т. Д. И т. Д.

Консерваторы: Адольф Гитлер, Такеда Сингэн, Лю Бэй и Чжугэ Лян.

Тем, кто желает остаться в прошлом и защитить старые традиции.

Идеалы: амбиции, слава, талант, семья, решительность, мастерство, жадность или справедливость.

Слава: те, кто желает получить как можно больше славы и статуса.

Амбиции: те, у кого большие идеи в отношении будущего и мира.

Талант: те, кто желает проявить свой талант и заявить о себе.

Жадность: те, кто желает добиться всего, чего хотят, любыми способами.

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

Семья: те, кто ставит перед собой цель, единственно обеспечить, чтобы их семья, клан, бизнес и т. Д. И т. Д. Оставались сильными и стойкими.

Справедливость: те, кто желает убедиться, что зло не восторжествует, и защитить тех, кого они любят.

Мастерство: те, кто желает и дальше совершенствовать свое ремесло, будь то фехтовальщик, священник, кузнец, торговец и т. Д. И т. Д.

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

Слава: Симадзу Ёсихиро и Минамото но Ёсицунэ

Талант: Тоётоми Хидэёси и Курода Ёситака.

Жадность: Дун Чжуо, Токугава Иэясу, Мацунага Хисахиде и Лу Бу.

Судья: Санада Юкимура, Хосокава Тадаоки, Лю Бэй, Чжугэ Лян и Чжао Юнь.

Это даст вам представление.

Уровень: C, B, A или S.

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

СУБЪЕКТ: Цао Цао, Ода Нобунага, Чжан Ляо, Имагава Ёсимото, Чжугэ Лян, Цинь Ши Хуанг, Минамото но Ёсицунэ и Тоётоми Хидэёси.

Ответ: Курода Ёситака, Миёси Нагаёси, Хосокава Тадаоки, Акэти Мицухидэ и Симадзу Иехиса.

Это дает вам представление.

Мятежные: 1 ~ 15

14: Датэ Масамунэ и Отомо Сорин.

13: Миёси Нагайоши.

12: Ода Нобунага, Тоётоми Хидэёси и Курода Ёситака.

11: Имагава Ёсимото.

Это дает вам представление.

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

Это то, что я предлагаю, чтобы помочь Википедии помочь тем, кто хочет знать, что этот тип информации важен для любого заядлого лидера или новичка. Как и все, Википедия должна двигаться вперед. В противном случае те, кто этого не сделает, обречены на провал. Это все, что я могу предложить на данный момент. - Предыдущий неподписанный комментарий добавлен Azuchi1579 ( обсуждение • вклад ) 10:34, 26 февраля 2021 г. (UTC)

Зачем это нужно? Есть панель поиска. А о каких шаблонах вы говорите? Lettler ^{hello • вклад} 20:56, 27 февраля 2021 (UTC)

Было бы гигантской задачей классифицировать все темы статей в соответствии с их идеалами, не нарушая WP: NPOV ; Управление неизбежной войной при редактировании и продвижением POV потребует в десять раз больше усилий, не говоря уже о жалобах и судебных исках от субъектов статей, разгневанных тем, что они были классифицированы как «жадные» или поставлены в один ряд с Гитлером. Я не мог придумать лучшего способа загнать Википедию в землю. - Tera tix ₵ 04:52, 28 февраля 2021 г. (UTC)

Википедия: Список Википедии по количеству правок [ править ]

Здравствуй! Я предлагаю расширить этот рейтинг до 20 000 лучших википедистов по количеству правок вместо 10 000. Д-р Сальвус ( выступление ) 14:17, 28 февраля 2021 (UTC)

@ Dr Salvus : Я поменял ваше «лучшее» на «верхнее», чтобы не сорвать обсуждение. Английский - не ваш родной язык, и я думаю, что слово «верхний» лучше отражает то, что вы имеете в виду. PrimeHunter ( разговорное ) 14:37, 28 февраля 2021 (UTC)

Можно ли это сделать? Очевидная проблема заключается в том, что это может поощрять Википедию: Editcountitis . Ролло Август ( разговор ) 19:32, 28 февраля 2021 (UTC)

Это, конечно, возможно , но это отчет, созданный ботом, поэтому желает ли оператор бота ( MZMcBride ) внести изменения? Если да, желает ли этого сообщество? Я поместил заметку на Википедии: Список Википедистов по количеству правок . - Red rose64 🌹 ( разговор ) 09:58, 1 марта 2021 (UTC)

• Хотя я считаю, что WP: WBE - это хорошо в целом, наряду с другими показателями, которые дают положительные отзывы об усилиях редакторов, я беспокоюсь, что открытие его для небольшого количества общих правок с большей вероятностью будет способствовать Wikipedia: Editcountitis . Поскольку он уже разделен на 1-5000 и 5001-10000, если он был увеличен, я бы предложил добавить только 10001-15000, а не полностью к 20000. KylieTastic ( обсуждение ) 10:22, 1 марта 2021 (UTC)
• Мех, меня больше интересует Википедия: Список Википедистов по количеству номинаций ФА . наслаждающийся | обсуждение 10:30, 1 марта 2021 г. (UTC)
• Я решительно поддерживаю ~ 12 000, поддерживаю 15 000, слабо выступаю против 20 000 и категорически против всего, что превышает 20 000. 🐔  Chicdat   ^{Bawk мне!} 11:29, 1 марта 2021 г. (UTC)

Цитируйте отображение книги: авторы / вклад должны СЛЕДОВАТЬ за автором / заголовком, а не предшествовать им [ править ]

Здесь я редактирую Карла Марзани # Издатель Марзани и Манселл . Запись, вызывающая озабоченность, отображается как

• Кинг-младший, Мартин Лютер; Нельсон, Трумэн (1962). Предисловие. Негры с ружьями . Уильямс, Роберт Ф. Нью-Йорк: Марзани и Манселл. OCLC 340047.

Только в Википедии цитируется автор Предисловия. Это нехорошо, исправьте, чтобы запись выглядела так:

• Уильямс, Роберт Ф. (1962). Негры с ружьями . с предисловием Мартина Лютера Кинга-младшего; Трумэн Нельсон. Нью-Йорк: Марзани и Манселл. OCLC 340047.

Более того, поскольку «Предисловие» на самом деле представляет собой два отдельных эссе Кинга и одно Нельсона, было бы лучше иметь в качестве параметров «вклад1», «вклад2» и «вклад3». Ларри Кенигсберг ( разговорное ) 18:38, 1 марта 2021 (UTC)