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

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

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

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

Во время последнего обсуждения я предположил, что TFA может быть WP: ожидающие изменения-защищен только до тех пор, пока он находится на Главной странице; и эта идея кажется новой. IP-адреса и неподтвержденные редакторы смогут публиковать сообщения, даже если их вклады не отображаются сразу; и вандализм можно было незамедлительно направить туда, где он был. Годных сотрудников TFA можно было бы поощрять для помощи регулярным патрульным, ожидающим изменений. Это также решило бы проблему определения того, когда произошел вандализм и кто его совершил (вечная проблема с небольшим количеством случаев вандализма, с которыми я сталкиваюсь - в основном это ссылки на страницы DAB, - которые могут быть скрыты за несколькими недавними хорошими изменениями и требуют копирования и вставки. из последней хорошей версии). Это не должно быть технически сложно реализовать; он может быть частью сценария, который добавляет статьи и удаляет их с главной страницы. Некоторым другим редакторам эта идея нравится,и мне было предложено начать обсуждение здесь. (Для протокола - я за.)Нарки Блерт ( разговор ) 10:36, 2 февраля 2021 (UTC) [ ответ ]

Отмечу, что одной из основных причин отказа от использования auto semi на TFA в прошлом является впечатление, что Википедия не так свободна для редактирования, поскольку наша самая видимая страница не редактируется для большинства аудитории TFA. Защита отложенных изменений позволяет избежать этого, по-прежнему позволяя пользователям вносить изменения, даже если есть небольшая задержка с публикацией их в реальном времени, поэтому это был бы достойный компромисс между неограниченным доступом и максимальной доступностью для нашей наиболее заметной страницы и избежанием бесполезной траты времени. время сообщества и потенциальный риск того, что плохой контент будет выставлен на всеобщее обозрение. С уважением, Пользователь: TheDragonFire300 . ( Свяжитесь со мной | Взносы ). 11:01, 2 февраля 2021 г. (UTC) [ ответ ]
В качестве дополнительной мысли - текст шаблона защиты должен быть адаптирован для TFA и приветлив. Нарки Блерт ( разговор ) 13:35, 2 февраля 2021 (UTC) [ ответ ]
И еще один - WP: ANI # Pacific swift - Сегодняшние TFA получили высокий уровень IP-вандализма (4 февраля 2021 г.). Нарки Блерт ( разговор ) 08:59, 5 февраля 2021 (UTC) [ ответ ]
Еще один, защита которого была отклонена - WP: ANI # Cheadle Hulme - Сегодняшние TFA получают высокий уровень IP-вандализма (5 февраля 2021 г.). Нарки Блерт ( разговор ) 11:42, 7 февраля 2021 (UTC) [ ответ ]
Это все изменения, внесенные в Cheadle Hulme в течение дня в TFA . Я вижу в общей сложности двух IP-вандалов, один из которых внес два изменения, а другой - одно, в то время как все остальные изменения IP являются конструктивными. Если бы какой-нибудь администратор защитил его при таких обстоятельствах, то, если бы я что-то не пропустил, их немедленно отправили бы в Arbcom за злоупотребления со стороны администратора. -  Радужный 12:37, 7 февраля 2021 г. (UTC) [ ответ ]
Я не администратор и не комментирую, должна или не должна быть защищена какая-либо конкретная страница. Тем не менее, я счел правильным размещать здесь все соответствующие сообщения ANI с тех пор, как я начал это обсуждение, независимо от того, помогают они моему предложению или вредят. Все свидетельства важны для достижения консенсуса. (Я не отслеживал WP: AIV или WP: RFPP , что было бы намного сложнее.) Нарки Блерт ( выступление ) 20:10, 19 февраля 2021 г. (UTC) [ ответ ]
Еще один - WP: ANI # Apollo 14 - Сегодняшние TFA получают высокий уровень вандализма IP и неконтролируемого контента (8 февраля 2021 г.). Нарки Блерт ( разговор ) 12:53, 9 февраля 2021 (UTC) [ ответ ]
И еще один - WP: ANI # Bernard A. Maguire - Сегодняшний TFA подвергся постоянному вандализму (11 февраля 2021 г.). Нарки Блерт ( разговор ) 00:23, 12 февраля 2021 (UTC) [ ответ ]
WP: ANI # Вандализм в отношении монет TFA Grant Memorial (12 февраля 2021 г.). Нарки Блерт ( разговор ) 05:42, 13 февраля 2021 (UTC) [ ответ ]
Другой - WP: ANI # Vandalism on Saturn (журнал) (14 февраля 2021 г.). Нарки Блерт ( разговор ) 07:30, 14 февраля 2021 (UTC) [ ответ ]
Сегодняшний выпуск - WP: ANI # Vandalism on Silesian Wars (15 февраля 2021 г.). Когда об этом сообщили в ANI, на главной странице оставалось всего пара часов. Cluebot и около шести зарегистрированных редакторов уже внесли в него правки; добавить защитного администратора, и это много работы.
Я заметил кое-что, чего раньше не замечал - User: TFA Protector Bot застрял {{ pp-move }} в статье 26 января с автоматическим истечением срока действия в полночь 15 февраля. Нарки Блерт ( разговор ) 17:34, 16 февраля 2021 (UTC) [ ответ ]
@ Narky Blert : В течение нескольких лет для всех будущих TFA (которые еще не имеют защиты от перемещения) было нормально получать краткосрочную защиту от перемещения, срок действия которой истекает в тот момент, когда статья перестает быть TFA. До ноября 2013 года это был ручной процесс; с тех пор это было поручено TFA Protector Bot, см. BRFA . Эта защита обычно применяется заранее (я думаю, вскоре после утверждения календарного слота), см. Журнал бота ; и использование является дополнительным к этому. - Red rose64 🌹 ( обсуждение ) 22:33, 16 февраля 2021 (UTC) [ ответ ]{{pp-move}}
Я не знал об этой процедуре (поэтому и упомянул о ней), но она мне показалась превосходной. Даже добросовестный ход рассмотренной статьи, поставленной в очередь, будет разрушительным по большому счету. Нам не нужны редиректы на главной странице.
Также - WP: ANI # Вандализм по метеорологической истории урагана Дориан (19 февраля 2021 г.). Нарки Блерт ( разговор ) 20:00, 19 февраля 2021 (UTC) [ ответ ]
И еще две - РГ: ANI # Вандализм на SS Мауна Лоа (19 февраля 2021) и WP: ANI # Несколько IP добавляющие порно или оскорбительного изображение в предположительно статье TFA (20 февраля 2021). Во втором я насчитал (среди прочих реверсий) семь WP: REVDEL, пока статья была на главной странице. Нарки Блерт ( разговор ) 00:53, 21 февраля 2021 (UTC) [ ответ ]
Другой - WP: ANI # Вандализм в отношении Маргарет (певица) (23 февраля 2021 года; также упоминается Левивичем ниже), который иллюстрирует проблему. Администратор WP: SILVERLOCKed страницы в течение 3 дней (что ИМО слишком много и в продолжительности и уровне); более близкая мысль, не являющаяся администратором, должна была быть опубликована на WP: RFPP, а не ANI. Нарки Блерт ( разговор ) 21:49, 24 февраля 2021 (UTC) [ ответ ]
@ Narky Blert : Это я закрыл эту тему; в этом случае дубликат уже был на WP: RFPP , поэтому наличие ANI-потока казалось излишним. С уважением, Пользователь: TheDragonFire300 . ( Свяжитесь со мной | Взносы ). 04:57, 2 марта 2021 г. (UTC) [ ответ ]
Широко распространено мнение, что ПК не работает / не может использоваться на сильно редактируемых страницах. Поэтому, наверное, никто этого не предлагает. - Изно ( разговор ) 15:44, 2 февраля 2021 г. (UTC) [ ответ ]
Это было доказано во время попытки бэкдора на ПК , статьями Барака Обамы и Джорджа Буша . Объем правок был настолько велик, что очереди по этим статьям постоянно задерживались, и поэтому было и до сих пор принято, что ПК не подходит для страниц, на которых будут редактироваться большие объемы правок, что могло бы произойти с TFA как вопрос курс. - Голубенький Бори v ^ _ ^ v Сильный мужчина отрицает ... 16:43, 2 февраля 2021 г. (UTC) [ ответ ]
По крайней мере, TFAs, рассматриваемые в этом обсуждении. В последнее время я видел несколько довольно тихих TFA. - Изно ( разговор ) 17:17, 2 февраля 2021 (UTC) [ ответ ]
К сожалению, я подозреваю, что набор TFA, которые были бы достаточно тихими для работы ПК, почти идентичен набору TFA, где ПК не нужен. Тридуульф ( разговор ) 01:30, 3 февраля 2021 (UTC) [ ответ ]
Как сторонник этого предложения и активный PCR, я не думаю, что это было бы непреодолимым для большинства TFA. Я отмечаю, что два приведенных примера являются сильно политическими темами, один из которых был в то время президентом Соединенных Штатов, а другой - менее полного срока назад. Vaticidalprophet ( разговор ) 06:04, 3 февраля 2021 (UTC) [ ответ ]
Я против превентивной защиты любого рода, особенно ожидающих изменений, которые заставляют добровольцев работать больше и редко бывают полезными. - WUG · а • ро · дез 1:53, 3 февраля 2021 (UTC) [ ответить ]
  • Поддержите какую-то защиту . Недопустимо, чтобы редакторы (очень предсказуемо!) Вандализировали такие статьи, как «Холокост в Словакии», пока они находятся на главной странице. Это подрывает нашу репутацию намного больше, чем любая защита. ( t · c ) buidhe 04:16, 3 февраля 2021 (UTC) [ ответ ]
  • Я должен отметить, что «высокая активность» - это довольно низкая граница - у PCR возникают реальные проблемы задолго до того, как, скажем, редакторы будут часто конфликтовать при редактировании. Я также не уверен, насколько точно мы можем сделать прогноз вероятной скорости редактирования TFA. Очевидно, мы можем предсказать сегменты «очень активные» и «вряд ли будут сильно редактироваться», но будет большая средняя категория, которую сложно заказать. Таким образом, я по-прежнему считаю, что ПЦР по-прежнему проблематична для любого использования TFA, которое действительно требует ПЦР. Nosebagbear ( разговор ) 07:35, 3 февраля 2021 (UTC) [ ответ ]
  • Если честно, я не категорически против этого. Полезность ожидающих изменений отличается от полузащиты: цель состоит не в том, чтобы уменьшить рабочую нагрузку для администраторов и патрульных, которые недавно вносили изменения (как другие правильно указали выше, ожидающие изменения эффективно действуют наоборот), а скорее во предотвращении вандализма. от того, что его увидят читатели, и, таким образом, возможно, подорвет репутацию проекта. На самом деле, если мне не изменяет память, в течение короткого периода несколько лет назад мы действительно начали упреждающе устанавливать защиту ПК на TFA после WP: AN.обсуждение из-за особенно неприятного LTA, который заменит изображения на TFA на чрезвычайно шокирующие. Традиционные проблемы с ПК на сильно отредактированных страницах не кажутся здесь большой проблемой, потому что защита будет длиться всего один день, а большинство TFA, похоже, не редактируются так часто, что большие задержки могут стать проблемой. По крайней мере, я бы, наверное, поддержал пробный период этой идеи. Mz7 ( разговор ) 07:53, 3 февраля 2021 (UTC) [ ответ ]
    Если подумать об этом немного дальше, я думаю, что уместным будет вопрос, как часто вандализм остается незамеченным дольше, чем, скажем, минуту на TFA. Незавершенные изменения лучше всего подходят для статей, в которых вандализм трудно быстро отменить, и теперь, когда я думаю об этом, поскольку TFA уже уделяет ему пристальное внимание в целом, возможно, что большая часть вандализма уже устранена внутри секунды, что делает потребность в ожидании изменений спорное. Mz7 ( разговор ) 08:02, 3 февраля 2021 (UTC) [ ответ ]
Насколько я могу судить, вандализм TFA редко, если вообще когда-либо, отменяется в течение нескольких секунд. Я слышал в среднем около 10-15 минут, что достаточно, чтобы создать проблемы для этих статей, особенно с тяжелым или гротескным вандализмом. Vaticidalprophet ( разговор ) 11:39, 3 февраля 2021 (UTC) [ ответ ]
Глядя на истории редактирования статей, которые я упомянул в первом абзаце (очень маленькая статистическая выборка): если ClueBot заметит это, в течение нескольких секунд; для человека - 1-40 минут (в среднем 8). Нарки Блерт ( разговор ) 14:24, 3 февраля 2021 (UTC) [ ответ ]
Я думаю, что уместным будет вопрос, как часто вандализм остается незамеченным дольше, чем, скажем, минуту на TFA. Это ключевой вопрос для меня. Если наша цель - предотвратить неудобства для читателя, нам необходимо знать, сколько вандализма в настоящее время мешает читателям. Я не думаю, что испытание изменит нашу способность смотреть на это, нам просто нужен кто-то, чтобы вычислить числа из истории страниц. Его также можно скрестить с дневными посещениями страниц, чтобы оценить количество читателей, которые действительно видели вандализм, например, этот вандализм длился 5 минут, так что в общей сложности 60 тысяч просмотров страниц в тот день --- вероятно, 5 тысяч человек видел это вместо статьи. По моему опыту, это то, что вы описываете, с добавленными глазами, обеспечивающими более быстрое возвращение, но знание среднего и других статистических данных было бы полезно и, вполне возможно, изменило мое мнение. Если защита ПК действительно является существенным преимуществом, я был бы готов поддержать ее использование в TFA. Он, по крайней мере, позволяет редактировать пользователям без учетных записей, и если мы создадим приятное сообщение, как предлагает Нарки, это может свести к минимуму потенциальный укус новичка . Так что в данном случае меня больше всего беспокоит полезность, потому что я редко видел, чтобы ПК решал больше проблем, чем вызвал. - WUG · а • ро · дез 20:13, 3 февраля 2021 (UTC) [ ответить ]
(Я полагаю, что математику в вашем примере не следует воспринимать буквально, но 5 минут 60 000 просмотров страниц - это примерно 209 просмотров - 5000 будут 60 000 в час . Ограничением этого подхода является то, что вандализм длится дольше, чем меньше просматриваемая страница есть, и просмотры страниц различаются в зависимости от часовых поясов в регионах, откуда большинство наших читателей. Но я думаю, что какой-то API где-нибудь может дать вам почасовые просмотры страниц.) - Билорв ( доклад ) 20:43, 4 февраля 2021 (UTC) [ ответ ]
  • Поддержка защиты отложенных изменений в качестве пробной : TFA отличается от других популярных страниц тем, что, скорее всего, там есть очень активный редактор, увлеченный статьей (тот, кто только что повысил ее до FA), а активность ограничена 24 часов (может быть, и в ближайшие несколько дней, пока ссылка на него все еще находится на главной странице). Я не могу говорить за всех таких редакторов (я был этим человеком только однажды), но, возможно, некоторые смогут просмотреть все изменения, по крайней мере, после того, как осядет пыль, и собрать любые изменения, которые являются продуктивными. Контраргумент состоит в том, что TFA - это хорошо известные статьи, и у них гораздо меньше шансов иметь проблемы, которые смогут решить новые и незарегистрированные пользователи. Но, вероятно, все еще есть небольшие улучшения в прозе, которых можно было бы ожидать в период TFA. Альтернативой может быть превентивная полузащита только некоторых TFA в зависимости от темы. - Билорв ( разговор ) 20:43, 4 февраля 2021 (UTC) [ ответ ]
  • Поддержка Внесено мало полезных изменений, вандализм - серьезная проблема не из-за количества вандалов, а из-за того, что мы получаем синяк под глазом, когда размещаем его на первой странице. Объем изменений, о которых идет речь, невелик. Так что это отличное использование ПК. Hawkeye7 (обсуждение) 04:33, 5 февраля 2021 (UTC) [ ответ ]
  • Тест поддержки , на мой взгляд, это идеальный баланс между сохранением целостности нашей мантры «любой может редактировать» и качеством наших избранных статей. Я склонен согласиться с Ястребом в том, что «сделано несколько полезных изменений» - до такой степени, что количество вандализма или бесполезных правок значительно превосходит количество случайных случайных исправлений орфографии (и любые серьезные правки / ошибки в любом случае лучше обсуждать на странице обсуждения) . Но в любом случае эта защита может устранить как вандализм, так и иногда полезные правки. Aza24 ( разговор ) 09:07, 5 февраля 2021 (UTC) [ ответ ]
    • Я просто хотел бы подтвердить мою поддержку; когда пару дней назад мой « Портрет музыканта» попал в TFA, было много случаев вандализма, почти все из которых можно было предотвратить с помощью ПК; другие исправления и правки были сделаны пользователями, которые не были ограничены ПК. Тест, безусловно, того стоит. Aza24 ( разговор ) 23:37, 1 марта 2021 (UTC) [ ответ ]
  • (nom) Я согласен с тем, что любые изменения должны производиться на пробной основе.
Моя идея для текста шаблона выглядит примерно так: «Добро пожаловать в сегодняшнюю избранную статью. К сожалению, эти статьи привлекают вандалов. Поэтому изменения, внесенные новыми редакторами, проверяются опытными редакторами, прежде чем они появятся для всеобщего обозрения. Обычно это занимает всего несколько минут. Если вы здесь, чтобы стать частью сообщества, цель которого - улучшить Википедию - спасибо и удачного редактирования! Возможно, вы найдете справку: редактирование полезного руководства для начинающих. Если вы здесь только для того, чтобы disrupt - прочь с тобой! " Нарки Блерт ( разговор ) 18:04, 5 февраля 2021 (UTC) [ ответ ]
  • Поддержка предотвратит мгновенную публикацию токсичных материалов или материалов, защищенных авторским правом, в таких популярных статьях. ~ HAL 333 02:58, 6 февраля 2021 (UTC) [ ответ ]
  • После уведомления, я еще не сказал об этом прямо здесь, поддерживаю как одну из сторон первоначального разговора. Vaticidalprophet ( разговор ) 13:53, 6 февраля 2021 (UTC) [ ответ ]
  • Против . Защита ПК требует значительного объема работы с минимальной пользой и не работает на страницах с большим объемом редактирования; те страницы, которые привлекают достаточно вандализма, чтобы сделать защиту стоящей, также будут теми страницами, на которых ПК не будет работать. ПК также имеет существенные дополнительные недостатки в дополнение к создаваемому им невыполненному техническому обслуживанию; нет возможности добавить резюме при отклонении редактирования, поэтому, отклоняя добросовестное, но неуместное изменение, невозможно объяснить причину в сводке редактирования; для проблем с BLP ПК оказывает небольшое влияние, поскольку он не влияет на то, что обрабатывает Google (они выбирают самую последнюю версию, даже если она не была одобрена); для утверждения / отклонения изменений в статье на уровне FA часто требуются специальные знания по теме,что горстка людей, которые работаютSpecial: очередь PendingChanges вряд ли будет; все предложение, по-видимому, основано на идее, что каждая или, по крайней мере, большая часть ФА будут в списках наблюдения людей, а это совсем не так. -  Радужный 08:00, 7 февраля 2021 г. (UTC) [ ответ ]
(Интересно видеть вас здесь - мне буквально просто интересно, что вы подумаете об этом предложении.) Как бы то ни было, "нет возможности добавить резюме при отклонении редактирования, поэтому при отклонении добросовестного, но неуместного редактирования невозможно объяснить, почему в сводке редактирования "неверно - поле сводки редактирования ... да, очередь ПК пуста, пока мы говорим, поэтому мой план сделать снимок экрана для" прямо здесь "придется подождать, но он размещен на видном месте с огромным жирным шрифтом: «ДОБАВИТЬ РЕДАКТИРОВАТЬ РЕЗЮМЕ, ЕСЛИ ТО, ЧТО ВЫ ОТМЕНАЕТЕ, НЕ ЯВЛЯЕТСЯ ВАНДАЛИЗМ». Vaticidalprophet ( разговор ) 06:37, 8 февраля 2021 (UTC) [ ответ ]
Вместо скриншота самого поля сводки редактирования вот скриншот из моих недавних публикаций PCR, показывающий их. Vaticidalprophet ( разговор ) 06:42, 8 февраля 2021 (UTC) [ ответ ]
Вызывает тревогу как отдельная вещь - узнать, что Google очищает самую последнюю версию на страницах PCP, хотя я понял, что это имеет небольшую задержку из-за общих причин вандализма (возможно, просто Google требуется несколько минут, чтобы очистить страницу). статья снова). Однако это проблема Google, а не наша. Я никоим образом не хочу, чтобы у них было единоличное право голоса при принятии любого из наших решений. Они должны измениться, чтобы удовлетворить нас, а не наоборот. Другие поисковые системы являются доступны. - Билорв ( разговор ) 00:56, 13 февраля 2021 (UTC) [ ответ ]
Примерно в 2014 году мне сказали, что Google очищает известные социальные сети каждые 20 минут. Наша цель как модераторов-добровольцев состояла в том, чтобы за это время избавиться от крупного коммерческого спама. IDK, если это типичное число, но наш лидер попытался, но не смог заставить их увеличить его до 30. Нарки Блерт ( разговор ) 06:05, 13 февраля 2021 г. (UTC) [ ответ ]
  • Поддержка Единственное отставание, которое может возникнуть с точки зрения ПК, - это одна страница, которую нужно будет регулярно проверять в течение всего срока (и, ну, ПК не такой большой по сравнению с некоторыми другими местами). И, что ж, хотя это может и не остановить все, по крайней мере, любое вандалистское редактирование (которое все равно нужно будет отменить, будь то ПК или нет) не будет заметно отображаться для каждого человека, который туда доберется ... RandomCanadian ( обсуждение / вклад ) 01:21, 12 февраля 2021 (UTC) [ ответ ]
  • Поддержка в качестве рецензента ожидающих изменений, я думаю, что дополнительная рабочая нагрузка будет минимальной по сравнению с преимуществами. При большом количестве глаз на странице хорошие изменения будут приняты быстро, а плохие не будут иметь заметных ссылок с главной страницы. Elliot321 ( обсуждение | вклад ) 05:57, 14 февраля 2021 (UTC) [ ответ ]
  • Поддержка - это кажется мне разумным компромиссом, который позволяет IP-адресам редактировать TFA и бороться с вандализмом. Другими словами, это наименее ограничительный способ эффективной защиты наших самых известных статей. (Защита одной статьи в день, безусловно, не приведет к перегрузке ПК, и статья в любом случае будет широко отслеживаться.) Давайте по крайней мере попробуем эту схему: я думаю, это будет эффективно. Внеочередное письмо ( разговор ) 07:18, 14 февраля 2021 (UTC) [ ответ ]
  • (nom) Чтобы повторить то, что я высказал ранее, на случай, если он может потеряться. В этой идее есть и пряник, и кнут. Это даст возможность быстро приветствовать новых редакторов и направить их в правильном направлении. Опытные редакторы знают, где искать или попросить о помощи; новички, по определению, этого не делают. Нарки Блерт ( разговор ) 07:50, 14 февраля 2021 (UTC) [ ответ ]
  • Поддержка . Речь идет о балансе положительной репутации Википедии как энциклопедии «любой может редактировать», против потенциальной негативной репутации вандализма и неточностей, которые вносятся, но не обнаруживаются. Я думаю, что защита от отложенных изменений - отличный компромисс, позволяющий людям редактировать, но предотвращающий появление глупой чуши в нашей самой известной статье дня. ƒirefly ( t · c ) 14:02, 14 февраля 2021 (UTC) [ ответ ]
    • Переход на сильную оппонента после того, как узнал, что FlaggedRevs (то есть модуль, стоящий за ожидающими изменениями) фактически заброшен, и никто из команды разработчиков MediaWiki не несет за него ответственности, и что в нем есть различные странные ошибки ( phab: T275322 , phab: T275017 ), которые, по-видимому, не решаются. Меньше всего мы хотим, чтобы странные ошибки MediaWiki отображались в TFA. ƒirefly ( t · c ) 09:42, 2 марта 2021 (UTC) [ ответ ]
  • Поддерживаю как пробу . Я согласен с RandomCanadian, короткий период времени с защитой отложенных изменений не создаст большого количества бэклога, и так много внимания уже уделяется TFA.
    Однако мне было интересно (именно поэтому я впервые голосую здесь, в Village Pump), где можно предложить совершенно новый тип защиты? Потому что что, если бы вместо того, чтобы помещать ожидающие изменения в TFA, вместо этого была бы защита «отложенных изменений»? В основном это будут незавершенные изменения, но с автоматическим утверждением по прошествии некоторого установленного времени. Установите время, немного большее, чем средняя продолжительность, необходимая для отмены вандализма, и я готов поспорить, что это резко снизит рабочую нагрузку в дни сильного вандализма, не внося вклад в отложенные изменения. Это будет защита только для TFA (случай страницы с высокой видимостью / трафиком в течение короткого периода времени). Но так как это необходимо создать и не о назначении существующей защиты, это 'Это скорее предложение о реализации в будущем. -Pinchme123 ( разговор ) 01:27, 18 февраля 2021 (UTC) [ ответ ]
    @ Pinchme123 : запросы на добавление функций следует отправлять в Phabricator . - Red rose64 🌹 ( обсуждение ) 14:26, 18 февраля 2021 (UTC) [ ответ ]
@ Redrose64 : Спасибо, что указали мне на Phabricator, так как я не знал об этом заранее. Но мой вопрос не о «отправке» запроса функции, а о том , чтобы предложить его для обсуждения перед запросом. Я не вижу особого смысла запрашивать новую фичу без обсуждения ее достоинств, особенно когда кажется, что запросы фичи делаются за пределами WP (поскольку Phabulator - это просто дочерняя организация Викимедиа, и мне пришлось создать новую учетную запись. просто чтобы увидеть страницу создания запроса функции). Итак, где я могу предложить эту функцию для обсуждения? - Pinchme123 ( разговор ) 16:16, 18 февраля 2021 (UTC) [ ответ ]
  • Напротив , в соответствии с радужным, а также из-за общего принципа использования TFA для выделения принципа «кто угодно может редактировать». Редактирование с задержкой - это не то же самое, что редактирование с немедленным воздействием, и использование ПК на такой заметной странице может повредить набору персонала. - Яир Рэнд ( разговор ) 06:25, 18 февраля 2021 (UTC) [ ответ ]
  • Комментарий . Я в коленном рывка противостоять лагерь за Переливающимся и Яир рандов, но я вижу проблему адаптации наших процессов , как мы развиваемся из «энциклопедии , которую может редактировать » в " энциклопедию , которую может редактировать". Если мы хотим использовать TFA для найма, то редактирование должно быть видно (почти) немедленно; более 30 секунд, я думаю, отнимут тот небольшой всплеск радости, который привел меня к редактированию здесь. Я считаю, что один из основных Проблемы, с которыми сталкивается Википедия по мере созревания, - это разрушение базы редакторов, поскольку становится все труднее и труднее попасть в дверь в качестве нового редактора. Есть ли какие-либо доказательства того, что новички берутся за редактирование через TFA? Я видел несколько новых редакторы конвертировали через ITN, но редко другие разделы главной страницы. Мои DYK иногда вносили существенные или исправляющие опечатки правки с помощью красных ссылок или IP-адресов, которые явно интересовались темой, и я даже очень иногда получал комментарии благодарности или осуждения с IP-адресов.Лично я ненавижу ожидающие изменения и почти никогда не принимаю существенные изменения, потому что на меня ложится бремя ответственности за них, и я знаю, что у других есть такая же проблема. Есть ли какой-то опосредованный ботами механизм, который мог бы немедленно автоматически принимать все, что выглядело добросовестно и не было явно проблемным? Можно ли настроить Cluebot для немедленного запуска при каждом редактировании TFA?Espresso Addict ( разговор ) 12:19, 18 февраля 2021 (UTC) [ ответ ]
  • Решительно поддерживаю попытку чего-либо после того, как сегодня TFA, Маргарет (певица) , постоянно подвергается вандализму, порождая еще одну ветку ANI . Я думаю, что работа по борьбе с вандализмом в TFA больше, чем работа, связанная с защитой статьи, а ущерб от вандализма в TFA больше, чем ущерб, связанный с тем, что никто не позволяет немедленно редактировать ее. Я не уверен, ПК это или полуавтомат, или что-то еще, но кое-что должно быть сделано ™. Я бы поддержал испытание этого или любого другого типа защиты. Или даже пробная версия ПК и полуавтомата, например A / B-тест . Я категорически против того, чтобы смириться с принципом «ну, вот оно что» и ничего не предпринимать. Категорически против того, чтобы ничего не пытаться . Левивич harass / hound 22:44, 23 февраля 2021 (UTC) [ ответ ]
  • Служба поддержкиПоскольку это избранная статья, расчет рентабельности здесь сильно отличается от большинства других. Новички хулиганят многие статьи, но также делают хорошие правки, чтобы это исправить. Для избранных статей вероятность того, что новичок сделает хорошее конструктивное редактирование, значительно снижается (из-за низкого потенциала для улучшения статьи как избранной), в то время как тот факт, что он находится на первой странице, означает, что количество вандализма существенно увеличивается. Лично я поддерживаю защиту отложенных изменений во всех избранных статьях из-за уменьшения пользы, которую может принести редактирование новичков. Качество многих избранных статей со временем значительно снизилось, поскольку для почти завершенной статьи гораздо более вероятно, что любое редактирование новичками будет бесполезным.Я думаю, что люди переоценивают то удовлетворение, которое люди получают от немедленных изменений; пока они осведомлены о ситуации с ожидающими изменениями, наиболее важным является то, что ваша работа вообще опубликована, а не точное время.Zoozaz1 ток 22:00, 24 февраля 2021 (UTC)[ответить]
  • Поддержка Самые последние TFAs следуют схеме, аналогичной Oryzomys gorgasi , TFA 26 февраля. В тот день было 62 правки. Из них 27 (примерно 44%) были с IP-адресов. За одним исключением, которое я видел, все были вандализмом. Почти все «законные» правки были внесены авторитетными пользователями, и большая часть этих правок была связана с устранением ущерба, нанесенного вандалами. Принцип «кто угодно может редактировать» является, по крайней мере, с моей точки зрения, средством и должен подчиняться цели создания энциклопедии, опираясь на коллективные знания. Venicescapes ( разговор ) 08:07, 28 февраля 2021 (UTC) [ ответ ]
  • Поддержка ; в целом отлично работает на dewiki на популярных страницах. Все статьи защищены ПК на dewiki, что приводит к долгому отставанию ( 7500 ожидающих изменений ), но это не кажется проблемой, когда защита ограничена 24 часами и выполняется выборочно на страницах, которые с большой вероятностью будут проверены. . ~ ToBeFree ( обсуждение ) 19:52, 1 марта 2021 (UTC) [ ответ ]
  • Поддержка каждого предложения; да, любой должен иметь возможность редактировать, что и будет в этом предложении, но Википедия не должна снова стать жертвой того, что ее называют веб-сайтом с неточностями, которые каждый может добавить. waddie96 ★ ( обсуждение ) 20:44, 1 марта 2021 (UTC) [ ответ ]
  • Поддержка. Кажется, я помню, как предлагал это несколько лет назад в одном из периодических разговоров о полузащите TFA. Это предотвратит демонстрацию вандализма в прямом эфире, но при этом позволит редактировать IP. Это может усложниться из-за большого количества правок, но в любом случае стоит попробовать. ~ ONUnicorn ( Обсуждение | Вклад ) решение проблем 20:57, 1 марта 2021 (UTC) [ ответ ]
  • Я не очень люблю защиту и ненавижу ожидающие изменения. Но, возможно, пора отойти от TFA в качестве нашего плаката для «кто угодно может редактировать» и поискать другие способы привлечь новых редакторов (TFA действительно не лучшее место для редактирования тестов). Я бы предпочел полукомпьютер , но не буду возражать против этого предложения. - Кусма ( t · c ) 21:25, 1 марта 2021 (UTC) [ ответ ]
  • Поддержка . Предпочитайте полукомпьютер. Меня прежде всего беспокоит читатель, а ЗАТЕМ редактор. Деннис Браун - 2 22:26, ​​1 марта 2021 г. (UTC) [ ответ ]
  • Поддержите, потому что это лучше всего послужит читателям. TFA получает большой трафик, и читателям оказывается медвежья услуга, если они сталкиваются со статьей, когда виден вандализм. Schazjmd  (разговор) 22:34, 1 марта 2021 (UTC) [ ответ ]
  • Без поддержки. Я считаю, что компьютер плохой, сломанный и бесполезный. Я думаю, что полусредство лучше во всех случаях. Однако, поскольку мы годами отказывались от полузащиты для FA, я остановлюсь на ПК. Я считаю абсурдным то, что мы не хотим использовать полуфабрикаты на FA. Мы попали в ловушку правил. Написано, что защиту следует использовать только после того, как произошел сбой, поэтому мы ждем, пока не увидим сбой. Но теперь мы следуем букве закона, а не духу! Дух состоит в том, чтобы предотвратить срыв. Конечно, для большинства статей мы не можем знать, когда произойдет сбой. Но избранные статьи подвергаются вандализму, как по маслу. Внезапный показ страницы 10 миллионам дополнительных людей в день (включая наши ДСС!) Почти наверняка приведет к вандализму. Немного о WP: IARсэкономит много времени и нервов. TL; DR: полузащита будет лучше, но я остановлюсь на ПК. CaptainEek редактирует Ho Cap'n! ⚓ 22:55, 1 марта 2021 г. (UTC) [ ответ ]
  • Комментируйте и возражайте . Возможность мгновенного редактирования лежит в основе этого проекта. И я думаю, что самый первый набег на Википедию многих редакторов связан с попытками основного редактирования. Это наш приветственный коврик. Мгновенное наблюдение за вашими изменениями в реальном времени вызывает острые ощущения и мгновенно подтверждает для новичков, что их подозрения относительно того, как все работает («любой может редактировать»), были обоснованными. Да, это включает в себя множество незрелых вандальных правок. Но такие глупые вещи, как ненормативная лексика, вставляются очень заметно. Но даже это помогает подсказать новые хорошие правки, чтобы попытаться исправить это. Другими словами, характер главной страницы «дикого запада» - важный способ привлечь новых пользователей, которые нам нужны. И даже некоторые из вандалов по мере взросления превращаются в хороших редакторов.Использование ПК делает ваши первые правки скучными, и люди, как правило, не задерживаются из-за скучных вещей.Джейсон Куинн ( разговор ) 02:22, 2 марта 2021 (UTC) [ ответ ]
  • Выступайте против использования ПК для TFA , но поддерживайте практически любую другую форму защиты (полуавтоматическая, расширенная подтвержденная и т. Д.). IMO, Pending Changes - это мерзость, которую не следует использовать вообще ни в какой статье и никогда. Это без необходимости увеличивает объем работы и делает редакторов ответственными за чужие правки. Это также чрезвычайно сбивает с толку и трудно понять как функцию, которая для перспективного использования TFA делает ее неприемлемой. TFA будут просматривать и редактировать многие неопытные редакторы. Мы не должны путать их, черт возьми, с таким чудовищем, как Pending Changes. Вместо этого просто полузащищайте TFA. Nsk92 ( разговор ) 02:47, 2 марта 2021 (UTC) [ ответ ]
  • Против. Похоже, что ветер сильно дует в одном направлении в этом, но я считаю, что это кажется излишним решением в поисках проблемы - предложенная проблема, которую я думаю, существенно минимальна по самой природе контекста. Если TFA несколько получат дополнительный трафик от IP-адресов и начинающих редакторов, они также получат повышенное внимание со стороны широкой части сообщества в течение тех же 24 часов, что и на главной странице. Кроме того, эти статьи, как правило, немного более надежны и отражают активное редактирование, чем средняя статья. Короче говоря, я не вижу, чтобы добавление ожидающих изменений существенно повлияло на защиту статьи от ошибочных, недобросовестных или иных проблемных правок в течение дня ее статуса избранного. Тем временем,это кажется абсолютно определенным, что окажет влияние на то, что традиционно было одним из предполагаемых преимуществ Избранной статьи: на набор редактора.
Фактически, я бы сказал, что наличие процесса, при котором новых редакторов загоняют в разные статьи каждый день (какая статья представляет собой достойные редакционные стандарты), и это пространство становится первым местом, где они могут оценить удовольствие от участия в энциклопедии и получать удовольствие от непосредственного ощущения того, как эти изменения претворяются в жизнь, при одновременном сосредоточении надзора со стороны сообщества над этим пространством статей в естественной манере - все это звучит как именно тот баланс, который мы хотим установить, и почему это «не нарушено, не исправляйте» тип ситуации. Кроме того, TFA часто выигрывают от привлекаемого ими внимания с помощью суперкраудсорсинга: подавляющее большинство даже правок IP являются полезными, а не вредными, так зачем же склеивать работы, имея очередь (потенциально перекрывающихся) ожидающих правок.И эти очереди не всегда решаются с готовностью: я сам являюсь рецензентом ожидающих изменений и за последние годы зарегистрировал изрядный объем работы в этой области, и я могу вам сказать, что очередь, к которой обращаются, довольно изменчива. что касается как тематики статьи, так и времени суток. Наконец, это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.это просто не типичный сценарий (по сути проблемная статья), в котором такая форма защиты обычно рассматривается как наиболее оправданная.
Короче говоря, что касается авторов и сторонников выше, анализ затрат и выгод, на мой взгляд, сильно противоречит предложению. S п о ж рэпа ДАВАЙТЕ 04:28, 2 марта 2021 (UTC) [ ответ ]
В равной степени вероятно, что новый редактор, пытающийся отредактировать хорошо зарекомендовавшую себя статью (TFA), что-то испортит и получит уведомление или, что еще хуже, строгое пугающее предупреждение на своей странице обсуждения. Это также игнорирует тот факт, что ПК по-прежнему позволяет новым редакторам редактировать статью, одновременно удаляя стимул для по крайней мере некоторого вандализма / ДСС. Бывший. (пришлось немного покопаться): TFA с мая прошлого года - исправленные правки являются хорошо известным вандалом LTA (так же, как и для большинства статей в Википедии: Сегодняшняя избранная статья / май 2020 г.... - Я знаю, это обсуждение не новая идея); после защиты ПК LTA остановился, хотя все еще разрешал другие правки, не связанные с AC (изрядно было обычным вандализмом, некоторые из них были добросовестными, но ошибочными; но в любом случае ПК не создает тех же проблем, что и полузащита). В то время как ПК может быть неэффективным для некоторых статей, а может быть, даже для большинства, на TFA это, вероятно, будет лучшим из обоих миров: не показывать вандализм нашим читателям, но при этом позволять новым редакторам вмешиваться. Ура, RandomCanadian ( обсуждение / вклад ) 05:06, 2 марта 2021 г. (UTC) [ ответ ]
  • Поддержка . Использование ПК в TFA на самом деле не новая идея. Я и другие администраторы много раз применяли его заранее, чтобы защититься от длительного злоупотребления или в ответ на вандализм. Это были чрезвычайные ситуации, которые требовали выхода за рамки политики и отсутствия консенсуса, но каждый раз, насколько мне известно, мы не видели никаких проблем, на которые другие часто ссылаются при поиске использования ПК в TFA. В частности, у этой статьи достаточно внимания и активности, чтобы она не нанесла большого ущерба отставанию. Защищать одну из наиболее заметных статей от искажения, но при этом позволять новым пользователям вносить свой вклад, является беспроигрышным и, откровенно говоря, давно назревшим делом. - MusikAnimal talk, 02:09, 3 марта 2021 г. (UTC) [ ответ ]

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

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

Как один из наиболее активных PCR и один из первых разработчиков предложения, я с некоторым интересом слежу за дискуссией об ошибках на ПК. На самом деле я не наблюдал тонны этого в своей работе, поэтому мне интересно, насколько велика проблема - то есть какая доля людей, получивших ложноположительные результаты, куда-то жалуется. (Это касается не только вице-президентов, я несколько раз видел, как это поднималось в ПЕРМЬ.) Если большинство людей, получивших это, поднимают эту тему, то это довольно мало; Если это лишь верхушка айсберга, это может стать серьезной проблемой.
Что касается предложения - то, что меня выделяет, это то, что большинство голосов противников говорят: «Мы не должны этого делать, мы должны вместо этого защищать полузащиту», а не «Мы не должны этого делать, TFA должна быть статус-кво». ". Интересно, как будет выделяться распределение голосов по следующим двум предложениям:
«TFA находится либо под ожидающими изменениями, либо без защиты, только два варианта, полузащита полностью исключена и никогда не произойдет»
«TFA либо относится к полу, ПК, либо к нулевому; ранжируйте варианты по предпочтениям»
В любом случае это был бы интересный RFC. Vaticidalprophet ( разговор ) 03:11, 13 марта 2021 (UTC) [ ответ ]
Иногда я пользуюсь ПК (когда я не занят), и я не сталкиваюсь с ошибкой слишком часто (неулучшения и вандализм, увы, встречаются чаще), или когда я это делаю, это обычно не доставляет особых хлопот просто принять изменение - если у меня будет особенно много свободного времени, я оставлю уведомление об этом соответствующему редактору. Однако тот факт, что код не обслуживается и, по-видимому, в какой-то форме беспорядок, не является хорошим признаком, и, что ж, нам нужно взвесить, является ли риск развития дальнейших проблем меньшим раздражением, чем потенциально что-то делать с ДСС TFA. ... Ура, RandomCanadian ( обсуждение / вклад ) 05:42, 13 марта 2021 (UTC) [ ответ ]
Обновление: мне известно, что теперь существует BRFA, предназначенная для решения этой проблемы. Если это пройдет, я думаю, что откажусь от своих колебаний. Mz7 ( разговор ) 19:06, 15 марта 2021 (UTC) [ ответ ]
Я считаю, что исправления с помощью бота в долгосрочной перспективе неприемлемы. Поскольку появляется все больше и больше ошибок, которые нельзя исправить в расширении, мы не можем продолжать использовать ботов и другие хаки, чтобы обойти их локально. Я лично хотел бы, чтобы FlaggedRevs попал в обзор управления кодом, прежде чем расширять его использование. ProcrastinatingReader ( обсуждение ) 23:26, 15 марта 2021 (UTC) [ ответ ]
  • Почему бы нам не удалить рецензента ожидающих изменений? а выдать права на расширенные-подтвержденные? Я имею в виду, что цель ПК - это базовый флаг, чтобы остановить вандализм / очевидный DE, верно? Это похоже на менее экстремальную полузащиту. Так что, я думаю, нет смысла помещать это в отдельное право. Право должно быть объединено с расширенным подтверждением, а отдельное право должно быть удалено, я думаю (+ EC - разумный уровень «доверия» против чистого бессмысленного вандализма + они уже могут редактировать такие области, как Израиль-Палестина). Это также исправит эту конкретную ошибку. ProcrastinatingReader ( обсуждение ) 17:17, 16 марта 2021 (UTC) [ ответ ]
    ProcrastinatingReader , честно говоря, я не против. Еще в 2018 году я выдвинул эту идею на идею деревенского насоса для лаборатории идей , и она вызвала неоднозначную реакцию, и мой интерес к внесению изменений просто угас. (Оглядываясь назад, я действительно написал слишком много, хех. Краткость не была / не моя сильная сторона .) Mz7 ( разговор ) 19:42, 21 марта 2021 (UTC) [ ответ ]
    @ Mz7 : afaics есть два основных возражения:
    1. Чтобы люди получали разрешение, не зная, что они делают / прямо не просят об этом. Но это верно и для автоподтверждения: вы автоматически получаете несколько кнопок и, вероятно, не будете использовать многие из них. И для админки тоже. Вам не нужно использовать кнопку только потому, что у вас есть к ней доступ.
    2. Чтобы редакторы играли в систему / увеличивали количество редактирований, чтобы получить это. Я не думаю, что это правда по нескольким причинам. 1) То же самое можно сказать и о «привилегии» на редактирование в ARBPIA. 2) то же самое можно сказать и о страницах, которые в настоящее время автоматически подтверждены / защищены ECP (игровые правки означают, что теперь вы можете принимать запросы {{ edit protected }} на страницу, а PCR практически эквивалентен {{ edit protected }}, за исключением того, что он напрямую поддерживается программным интерфейсом).
    Так что ни одно из возражений не имеет смысла, imo. ProcrastinatingReader ( обсуждение ) 19:55, 21 марта 2021 (UTC) [ ответ ]
    Пока мы это делаем, почему бы вообще не отказаться от незавершенных изменений? Есть ли какая-либо причина, кроме невысоких затрат, чтобы сохранить его, вместо того, чтобы использовать другие формы защиты? Я часто замечал, что эксперименты в Википедии практически никогда не считаются провальными, часто потому, что люди следят за этим заблуждением. Фил Бриджер ( разговор ) 19:53, 21 марта 2021 (UTC) [ ответ ]
    Основное преимущество ожидающих изменений, с моей точки зрения, заключается в том, что они действуют как форма защиты от вандализма на страницах, не блокируя их способность IP-адресов фактически редактировать. Обсуждение Асартеи | Вклад 07:54, 25 марта 2021 г. (UTC) [ ответ ]

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

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

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

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

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

  • Почему? Белка Иванавектора ( деревья / орехи ) 22:17, 4 февраля 2021 (UTC) [ ответ ]
    Потому что это не политические или партийные офисы. Они просто тривиальны. GoodDay ( обсуждение ) 22:19, 4 февраля 2021 (UTC) [ ответ ]
    Зачем нам нужна глобальная политика или руководство или что-то еще по этому поводу? Если вы думаете, что данное поле преемственности является пустяком, обсудите это конкретное поле преемственности где-нибудь (страница обсуждения, WikiProject, TfD, есть много мест). Я искренне не понимаю, чего вы здесь пытаетесь достичь - нет никаких шансов, что будет достигнуто согласие относительно того, что у нас должны быть коробки преемственности для всего (бесспорный пример 10-го места квалификации в гонке British Touring Car Championship), но с формулировкой обсуждения вы не можете прийти к единому мнению (за или против) относительно какого-либо отдельного примера. Тридуульф ( разговор ) 02:18, 5 февраля 2021 (UTC) [ ответ ]
    Вы ожидаете, что по каждой отдельной статье биографии будет отдельное обсуждение ? В любом случае, я не совсем понимаю, о чем вы пишете. GoodDay ( обсуждение ) 17:29, 5 февраля 2021 (UTC) [ ответ ]
    Я ожидаю, что вы достигнете консенсуса по каждой отдельной преемственности. Это может быть страница обсуждения статьи или централизованное обсуждение. например, если вы хотите избавиться от старейшего живого премьер-министра Великобритании, вам необходимо обсудить, в частности, удаление поля преемственности «самый старый из ныне живущих премьер-министра Великобритании» из каждой статьи, в которой он появляется, с уведомлениями (по крайней мере) на странице обсуждения всех затронутых статей. Другими словами, вам нужно сделать то же самое, что и для любого другого массового изменения. Тридуульф ( разговор ) 22:26, ​​5 февраля 2021 (UTC) [ ответ ]
    Слишком много времени. В этих ящиках преемственности слишком много «бесполезных» тем, чтобы рассматривать их одну за другой. GoodDay ( обсуждение ) 22:30, 5 февраля 2021 г. (UTC) [ ответ ]
    Централизованное обсуждение ящиков для пожертвований для старейшего из ныне живущих премьер-министра Великобритании можно было бы провести на Wikipedia talk: WikiProject Politics of the United Kingdom . - Red rose64 🌹 ( обсуждение ) 23:40, 5 февраля 2021 (UTC) [ ответ ]
    Но пример с британскими премьер-министрами - лишь один из примеров таких банальных тем в ящиках для ответов. GoodDay ( обсуждение ) 23:41, 5 февраля 2021 (UTC) [ ответ ]
    Проблема в том, что мы понятия не имеем, какие еще блоки преемственности вы считаете тривиальными, поэтому мы (и, что наиболее важно, редакторы статей, в которых они публикуются) не можем узнать, согласны мы или не согласны. В то время как самый старый из ныне живущих премьер-министр Великобритании не кажется очень полезным, другие, такие как премьер-министр Соединенного Королевства, очень нетривиальны, и где провести границу между ними, необходимо определить на основе консенсуса. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC) [ ответ ]
    Такие темы, как «Самый высокий президент страны» , «Самый толстый премьер-министр страны» , «Самый старый гонщик на серийных автомобилях» , «Самый молодой гонщик на 100 метров» , будут банальными темами для сук-боксов. GoodDay ( обсуждение ) 02:18, 6 февраля 2021 (UTC) [ ответ ]
    Первые два, несомненно, были бы тривиальными, последние два, возможно, - все будет зависеть от того, придавалось ли этому какое-либо значение в надежных источниках. Однако короткий список тем (которые, как следует из беглого поиска, не используются), которые вы считаете тривиальными, никоим образом не способствует решению проблемы в моем комментарии. Тридуульф ( разговор ) 18:20, 6 февраля 2021 (UTC) [ ответ ]
    Я не знаю, в чем ваша жалоба. Возможно, если вы приведете примеры тем из раздела «Блокнот», которые, по вашему мнению, следует и не следует удалять, это поможет. GoodDay ( обсуждение ) 18:26, 6 февраля 2021 (UTC) [ ответ ]
    Я считаю, что их нужно обсуждать индивидуально или в небольших, тесно связанных группах (например, возможно, ящики преемственности, связанные с премьер-министрами Великобритании). Независимо от того, сколько примеров приведено здесь, вы не можете достичь консенсуса ни в чем, не перечисленном здесь, и чем больше примеров вы приведете здесь, тем больше вероятность крушения поезда. Тридуульф ( разговор ) 00:10, 7 февраля 2021 (UTC) [ ответ ]
    RFC уже идет полным ходом. Посмотрим, чем это закончится. GoodDay ( обсуждение ) 00:47, 7 февраля 2021 (UTC) [ ответ ]
    Консенсус в отношении того, что некоторые, но не все поля наследования следует удалить, но нет консенсуса в отношении удаления какой-либо из них - это потребует дальнейшего обсуждения. Это почти единственный способ, которым все может закончиться. Тридуульф ( разговор ) 02:20, 7 февраля 2021 (UTC) [ ответ ]
    Кроме того, я считаю, что Wiki-проекты обычно привлекают меньше внимания. По той же причине рассматривал возможность переноса еще одного RFC в Village Pump. GoodDay ( обсуждение ) 23:55, 5 февраля 2021 (UTC) [ ответ ]
    Ваше субъективное мнение о том, что что-то «занимает слишком много времени», не дает вам права игнорировать WP: CONSENSUS . Если вы предлагаете курс действий в отношении WikiProject и рекламируете обсуждение на соответствующих страницах обсуждения, но никто не возражает по прошествии разумного времени (~ неделя), вы можете продолжить и удалить поля последовательности, перечисленные в обсуждении. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC) [ ответ ]
    Если вы хотите рекламировать этот RFC в связанных проектах WikiProjects? тогда непременно сделайте это. GoodDay ( обсуждение ) 02:18, 6 февраля 2021 (UTC) [ ответ ]
    Если это обсуждение на самом деле касалось конкретных блоков наследования, которые были бы уместны, но поскольку обсуждение на самом деле представляет собой пустую и несфокусированную попытку избавиться от неопределенного списка блоков наследования, которые вам (или, предположительно, любому другому редактору) лично не нравятся, тогда невозможно знать, какие проекты и статьи актуальны. С другой стороны, если вы сделали соизволили перечислить эти коробки вы сочтете мелочи, то это бы я подозреваю , быстро стать Trainwreck из - за большое количество разрозненных ящиков редакторов будет иметь разные мнения о том . Тридуульф ( разговор ) 11:55, 6 февраля 2021 (UTC) [ ответ ]
    Поскольку мои опасения выросли из обсуждения в Джеймсе Каллагане , можно было бы сослаться на Политические WikiProjects. GoodDay ( обсуждение ) 18:41, 6 февраля 2021 (UTC) [ ответ ]
Все должны быть удалены, поскольку ссылки являются спамом из-за дублирования ссылок и чрезмерного размера. Никогда не понимал, почему у нас есть гигантские коробки с очень небольшим количеством ссылок в них, подавляющими разделы. Редактор контента определенно не согласен с тем, что эти ненужные блоки автоматически рассылаются спамом без учета чрезмерных или необоснованных ссылок. - Moxy : 0 00:04, 6 февраля 2021 г. (UTC) [ ответ ]
Очень просто, потому что многие (не все) поля наследования очень полезны для читателей. Тридуульф ( разговор ) 00:59, 6 февраля 2021 (UTC) [ ответ ]
Не уверен, насколько удобно для читателей дублирование lnks и overwhelm разделов. У нас есть протоколы для этих двух пунктов ... которые просто игнорируются спамерами по шаблонам. - Предшествующий неподписанный комментарий, добавленный Moxy ( обсуждение • вклад ) 01:19, 6 февраля 2021 г. (UTC) [ ответ ]
См. Мой ответ в разделе выше, чтобы узнать, почему дублирование не является проблемой, и я не согласен с тем, что презентация подавляющая. То, что некоторые поля наследования являются пустяками, не означает, что все поля наследования являются спамом. Тридуульф ( разговор ) 01:41, 6 февраля 2021 (UTC) [ ответ ]
Нам просто придется не соглашаться. Только практика размещения указывает на очень низкую ценность для сообщества. См. Также ссылки, размещенные в нижней части статей, потому что они дублируют существующие ссылки, и формат не отвечает нигде в других статьях. Ужасно, что эти поля более заметны, чем фактические тематические навигационные поля. Странно, что они не были исключены из мобильной версии как нежелательная нагрузка. - Moxy, 02:01, 6 февраля 2021 г. (UTC) [ ответ ]
Как размещение указывает на низкую стоимость? Конечно, этот формат не подходит для других частей статьи - см. Также ссылки и ссылки в полях последовательности имеют совершенно другое предназначение, чем ссылки в прозе. Вам нужно объяснить, почему дублирование проблематично. Тридуульф ( разговор ) 11:55, 6 февраля 2021 (UTC) [ ответ ]
Вот почему у нас есть руководство по этому поводу ... отвлекает читателей от действительно важных ссылок . Википедия: кризис оверлинков . Они настолько огромны, что редакторы прячут их в сворачиваемых шаблонах Авраам Линкольн # Внешние ссылки . Во многих других случаях их просто огромное количество ... массовый ссылочный спам Джон А. Макдональд # Внешние ссылки .-- Moxy, 17:59, 6 февраля 2021 г. (UTC) [ ответ ]
Вы объяснили, почему считаете, что слишком много ящиков является проблемой, и повторили свое мнение о том, что некоторые ящики имеют низкую ценность (с чем в основном никто не согласен). Однако вы не объяснили, почему наличие каких-либо ящиков проблематично или почему их позиция в статье указывает на это. Тридуульф ( разговор ) 20:24, 7 марта 2021 (UTC) [ ответ ]
Как я сказал в своем возражении выше, тот, кто когда-либо закроет это, окажется в безвыходной ситуации. Ни в одном из комментариев «да» нет единообразия. Кроме того, что вообще означает «определенное содержимое блока преемственности»? Кто решает, какие из них обсуждаются? Aza24 ( разговор ) 23:08, 24 марта 2021 (UTC) [ ответ ]

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

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

Фон (CS1)[ редактировать ]

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

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

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

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

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

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

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

Обзор (CS1)[ редактировать ]

  • Первый выбор , второй выбор B . Я был бы счастлив, если бы генфиксы AWB взяли на себя часть этого бремени, и я был бы счастлив, если бы это происходило немного медленнее, но это должно происходить, даже если иногда это неудобно для меня. Кроме того, когда какой-либо отдельный параметр достигает достаточно малого состояния (например, потенциально все еще тысячи использований, но не сотни тысяч статей), шаблон должен быть обновлен, чтобы запретить этот конкретный параметр (а не просто рекомендовать его в документации), чтобы они не продолжали ползать обратно, потому что, эй, это все еще работает, так зачем мне беспокоиться? WhatamIdoing ( обсуждение ) 19:12, 10 февраля 2021 (UTC) [ ответ ]
    @ WhatamIdoing : Genfixes AWB уже обрабатывает это через WP: AWB / RTP , поэтому ручное редактирование и другие боты могут помочь сократить список при внесении других (не косметических) правок. GoingBatty ( обсуждение ) 04:12, 11 февраля 2021 (UTC) [ ответ ]
    GoingBatty , вы уверены, что |accessdate=его заменят |access-date=редакторы, использующие текущую версию WP: AWB / RTP ? Думаю, его убрали. - Jonesey95 ( разговор ) 04:33, 11 февраля 2021 г. (UTC) [ ответ ]
    @ Jonesey95 : Ты прав! Пока эта функция существует (а другие параметры все еще заменяются), редакторы удалили некоторые правила замены переносов. GoingBatty ( обсуждение ) 04:59, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант А . Я поддерживаю завершение почти законченного перехода от недефисных параметров, состоящих из нескольких слов. См. Ниже более подробную информацию об этом процессе, который сейчас ставится под сомнение очень немногими редакторами после семи лет работы, и когда он завершен более чем на 90%. С любым другим шаблоном потребовалось бы несколько дней, чтобы стандартизировать один стиль имени параметра и преобразовать все включения. Единственная причина, по которой процесс для шаблонов CS1 / CS2 отличается, заключается в том, что используются миллионы включений вместо сотен. - Jonesey95 ( разговор ) 04:33, 11 февраля 2021 г. (UTC) [ ответ ]
  • Вариант C . Это бессмысленно заставлять работать; см. расширенный комментарий в разделе обсуждения. Espresso Addict ( разговор ) 07:08, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант C Если бы он ограничивался несколькими тысячами страниц, это не было бы большой проблемой. Но когда это более 3 миллионов страниц, возможно, должно быть наоборот - IE без дефиса. Множество бессмысленных ботинок, просматривающих миллионы страниц для незначительного изменения. Lugnuts Fire, иди со мной 08:20, 11 февраля 2021 (UTC) [ ответ ]
  • B, если не C Согласно комментариям выше; Многие редакторы явно довольны формами без дефисов, так почему бы не разрешить и то, и другое? Менять бессмысленно. Многие другие шаблоны позволяют использовать псевдонимы в качестве имен параметров. Я не вижу проблемы. Но мы там, где находимся, поэтому я предпочитаю B, а не C. Питер Коксхед ( разговор ) 09:04, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант A (второй вариант B ), согласно Jonesey95. Давайте просто все упростим, как и должно быть. Продолжайте и заканчивайте работу. - NSH001 ( обсуждение ) 10:18, 11 февраля 2021 г. (UTC) [ ответ ]
    Обновление Добавить уточнение: я все еще очень надеюсь, что боту будет разрешено возобновить работу, но при этом условии: только если Monkbot 18 откажется от удаления полностью пустых строк в шаблонах цитирования . Обоснование этого можно найти в моем разговоре с Floydian в разделе обсуждения (это довольно простое изменение для бота). Пока я здесь, я добавлю вторую оговорку, также вытекающую из обсуждения: список статей, по которым запускается бот, должен быть отфильтрован, чтобы удалить статьи, которые уже были посещены ботом. Это сделано для того, чтобы уменьшить предполагаемую проблему «бот-спама», против которой возражают некоторые редакторы (кто сказал, что я не прислушиваюсь к возражениям?). - NSH001 ( разговор ) 06:52, 12 марта 2021 (UTC) [ответ ]
  • Вариант C . Это совершенно бессмысленное занятие. На мой взгляд, текст без переносов лучше, так как они не переносятся в окно редактирования и могут быть подчеркнуты как опечатка, поэтому они хорошо видны в окне редактирования. Кейт Д. ( разговор ) 13:01, 11 февраля 2021 г. (UTC) [ ответ ]
  • C (первый выбор) или B (второй выбор). Я читал множество дискуссий по этой проблеме и никогда не видел ничего, что убедило бы меня в том, что отказ от поддержки действительно приносит пользу энциклопедии. Даже если мы предположим в пользу того же аргумента, что это так или иначе, реальное и очевидное нарушение, вызванное ботом до сих пор, и степень изменений, которые отмечает оператор бота, потребуются для выполнения задачи, очень ясно и очень значительно перевешивают то, что выгода. Тридуульф ( разговор ) 15:20, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант А: это изменение немного болезненно, но в долгосрочной перспективе его лучше редактировать. Лучше внести это изменение, чем не делать этого. Лучшее время было пятнадцать лет назад, но сейчас второе лучшее время. Разрешите боту продолжить свою работу, избавьтесь от всех параметров и, как только все они будут удалены, начните генерировать ошибки цитирования. Elliot321 ( Обсуждение | вклад ) 17:09, 11 февраля 2021 (UTC) [ ответить ]
  • Вариант А . К сожалению, визуальный редактор существует ... но бесполезен для больших проектов редактирования, и поэтому многие люди все еще используют редактирование викитекста - сжатие в одну форму (в частности, форму с переносом, поскольку редакторам ее легче читать) поможет обеспечить согласованность между статьи хотя бы в шаблонах CS1. Очевидно, что это не упростит редактирование каждой статьи, поскольку есть статьи с цитированием, отличным от стиля CS1, но это поможет миллионам, которые действительно используют CS1, выглядеть для редакторов одинаково, вместо того, чтобы иметь мешанину из написанных через дефис имен. Я также согласен с тем, что бот продолжит работу сейчас, а затем будет запускаться, может быть, один раз в неделю или около того после этого первоначального запуска, чтобы исправить любые имена параметров CS1 без дефиса. -bɜ: ʳkənhɪmez ( Пользователь / передай привет!) 17:13, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант C. Суть шаблонов и ботов в том, что они должны работать, чтобы облегчить жизнь редакторам, а не в том, что редакторы должны менять свой подход к работе, чтобы облегчить жизнь создателям шаблонов и ботов. У этого бота это полностью перевернуто, и если группа одобрения ботов одобрила это, то это проблема этой группы, а не нескольких недифференцированных параметров. Я не могу избавиться от ощущения, что эта группа следит за интересами нескольких операторов-ботов, а не гораздо большего числа редакторов и еще большего числа читателей. Нет большой сложности в наличии нескольких синонимов для параметров шаблона, и нет никаких проблем с экспортом данных - если синонимические параметры указывают на одно и то же место в коде, то их можно без дополнительных усилий экспортировать в том же формате. Я могу'Я не верю, что через сорок лет после того, как я пришел в ИТ, мы все еще ожидаем, что пользователи будут рабами систем, которые призваны им помогать.Фил Бриджер ( разговор ) 18:21, 11 февраля 2021 (UTC) [ ответ ]
    Суть шаблонов и ботов в том, что они должны работать, чтобы облегчить жизнь редакторам.. Точно так. Вот для чего нужен этот бот. Это упрощает чтение имен параметров (принимая их целиком, а не только дату доступа как таковую), уменьшает размер документации по шаблону, делает имена параметров согласованными. Все это в совокупности упрощает обучение использованию шаблонов цитирования. Это также упрощает обслуживание шаблонов. беспроигрышная ситуация. Единственная причина, по которой мы ведем это обсуждение, заключается в том, что программа списков наблюдения Mediawiki так плохо справляется с редактированием ботами. В противном случае это было бы проще простого. Некоторые люди здесь, кажется, ошибочно полагают, что это сделано только для продвижения интересов «нескольких операторов ботов». Что ж, я совершенно уверен, что Trappist (оператор этого бота) может обойтись без стресса, связанного с планированием, написанием и запуском этого бота. Он делает чертовски фантастическую работу,и заслуживает огромной похвалы и признательности за свою работу.Я не могу поверить, что через сорок лет после того, как я перешел в ИТ, мы все еще ожидаем, что пользователи будут рабами систем, которые призваны им помогать. Вся цель этого бота - облегчить жизнь пользователям. FWIW, у меня также есть опыт работы в ИТ более 40 лет назад (командирован на 2 года для работы над (очень успешным) проектом - математическое программирование больших данных для компании по страхованию жизни), и с тех пор мне часто приходилось поддерживать связь с ИТ-специалистами. . Я хорошо осведомлен о проблемах, которые могут возникнуть, когда вы просто позволяете системам становиться все более и более сложными, поэтому я ценю усилия траппистов (и многих других) по упрощению вещей. - NSH001 ( разговор ) 23:37, 11 февраля 2021 (UTC) [ ответ ]
    Уточнение: перечитывая это сегодня утром, читателям, которые не читают внимательно, может показаться, что я согласен с Филом Бриджером. Ничто не может быть дальше от истины, я до сих пор поддерживаю вариант А . Вариант C не имеет смысла по всем причинам, изложенным SMcCandlish. - NSH001 ( разговор ) 08:35, 12 февраля 2021 г. (UTC) [ ответ ]
    И преувеличенная позиция Фила Бриджера ошибочна. Вариант Б никому ничего не навязывает. «Мне не нравится вариант А» не означает, что «может работать только вариант С». Вариант B - это статус-кво , и он ничего не сломал. Я довольно шокирован тем, насколько это очевидно, но, по крайней мере, 10 редакторов, кажется, не заметили. Я знаю, что в мире очень много популизма - много «Я бы очень сильно переживал по этому поводу, если бы это было правдой, и мне приятно притворяться, что это правда, поэтому я собираюсь притвориться, что это правда. " поведение. Но все это нужно оставить за дверью.  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC) [ ответ ]
    Нет, моя позиция не является преувеличением или популизмом. Причина, по которой я отвергаю вариант Б, - это слово «немедленно». Это все еще оставляет текущий консенсус о том, что версии параметров без дефисов будут удалены, но не сразу, и это консенсус, который должен измениться, сколько бы лет он ни оставался стабильным. Я доволен упрощением документации, но не удалением этой опции. Фил Бриджер ( разговор ) 09:19, 12 февраля 2021 (UTC) [ ответ ]
    Как отмечалось выше: устаревание не является синонимом отключения. Вы сбиваете с толку замену параметров, как написано в шаблоне, включенном на страницу, с удалением возможности варианта параметра runtogether работать в шаблоне. Только вариант А подойдет для последнего. У нас есть много-много шаблонов, которые поддерживают параметры варианта написания, но не «рекламируют» их в документации, и ничего не ломает, чтобы бот заменил их канонической версией, точно так же, как тот же бот заменяет вызовы на имя перенаправления. для шаблона с фактическим именем страницы шаблона. То есть, вы испытываете сильную негативную реакцию на аргумент , что вариант В самом деле не делают .  -  SMcCandlish ☏ ¢  😼 17:50, 13 февраля 2021 г. (UTC) [ ответ ]
    Вариант Б очень четко говорит: «но не следует сразу удалять». Либо слово «немедленно» имеет какое-то значение, и этот вариант приведет к удалению, но не сразу, либо оно не имеет значения и не имеет никакого отношения к этому. Фил Бриджер ( разговор ) 18:10, 13 февраля 2021 (UTC) [ ответ ]
    SMcCandlish , это объяснялось в предыдущем обсуждении на CS1.: "" Устаревание "по определению, используемому в контексте CS1 / CS2, означает, что если параметр используется, будет показано красное сообщение обслуживания, и оно появится в категории отслеживания. Это этап перед прекращением поддержки для параметра (в этом случае будет показано только сообщение "неподдерживаемый параметр" и, возможно, подсказка о новом параметре). Можно оставаться в этом состоянии в течение длительного периода времени, но идея заключается в том, что в конечном итоге функциональность будет идти". Таким образом, цель состоит в том, чтобы ошибиться, а затем удалить функциональность этих параметров, а не просто не рекламировать их в документации. Если вы хотите предложить вариант варианта C, который удаляет параметры из документации, но по-прежнему позволяет им функционировать, продолжайте, но вариант B не такой.Никкимария ( разговор) 20:09, 13 февраля 2021 г. (UTC) [ ответ ]
    Что я хочу предложить вариант вариант В , который удаляет параметры из документации , прежде чем дать некоторые боту идти вокруг изменения статей по лотам , как если параметры как - то плохи. Если параметры действительно плохие, и если есть консенсус по этому поводу , то Шаг первый - удалить их из документации (либо перетаскивая их в темноте ночи, тихо, как ниндзя, либо прозрачно упоминая их как устарел, поэтому все знают, что происходит). Первая фаза настоящего осуждения - это сказать людям, чтобы они перестали что-то использовать. Тогда вы можете начать подбрасывать красные сообщения, и это будет не так чертовски грубо или удивительно. -  Джон Фром Пинкни (разговор ) 21:40, 13 февраля 2021 (UTC) [ ответ ]
    Конечно, я бы тоже поддержал этот вариант. Или вариант, в котором упоминаются эти версии параметров, но они не рекомендуются. Что бы ни приближало нас к единообразию фактических развернутых шаблонов, используемых в цитировании.  -  SMcCandlish ☏ ¢  😼  04:15, 14 февраля 2021 г. (UTC) [ ответ ]
    Этот материал должен быть в категории отслеживания, если это то, с чем будут работать боты и другие инструменты. Если нам не нравятся сообщения об ошибках, мы можем их отключить. Это всего лишь код шаблона и модуля, он не выгравирован на склоне горы, такой как Mt. Рашмор.  -  SMcCandlish ☏ ¢  😼  04:15, 14 февраля 2021 г. (UTC) [ ответ ]
  • Вариант C Я полностью согласен с Филом Бриджером. Другими словами, я не могу понять, чего именно можно добиться, сделав миллионы косметических правок и затем намеренно нарушив то, что в противном случае сработало бы. * Ппперы * началось ... 20:21, 11 февраля 2021 (UTC) [ ответ ]
    Вариант Б ничего не ломает. Вы, и др., Обеспечивают аргумент против варианта А, а не фактический аргумент для C, и просто игнорируя B. Кроме того ,! Проголосуй за С является! Проголосуй за переворачивания статус - кво , который был стабильным в течение многих лет , в в пользу хаоса, но без реальных оснований для этого. Более близкий должен принять это во внимание, согласно WP: NOTAVOTE . В случае результата «отсутствие консенсуса» мы все равно остаемся с статус-кво. Вот почему я постоянно говорю людям, что им нужно лучше писать RFC. «Все, что можно неправильно истолковать, будет».  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC) [ ответ ]
    SMcCandlish , опция B поддерживает отключение параметров без дефиса - это критическое изменение. Разница между A и B - это скорость, а не результат. Ваш! Голос ниже предполагает, что вы хотите, чтобы варианты без дефиса продолжали поддерживаться, но из представленных вариантов только вариант C выполняет это. Никкимария ( разговор ) 16:18, 13 февраля 2021 (UTC) [ ответ ]
    Неа. См. Мой ответ на то же заявление Фила Бриджера выше.  -  SMcCandlish ☏ ¢  😼  17:50, 13 февраля 2021 г. (UTC) [ ответ ]
    Ага - см. Выше. Вы также можете посмотреть, что произошло с ранее устаревшими параметрами CS1, такими как |authorfirst=- они не работают. Никкимария ( разговор ) 20:09, 13 февраля 2021 (UTC) [ ответ ]
    Что совершенно нормально, если у людей будет достаточно времени, чтобы они перестали их использовать. Таким образом удалите их из документации по шаблону и замените их в развернутых трансляциях шаблонов. В конце концов, эффект «обезьяна видит, обезьяна делает», связанный с устаревшими вариантами параметров, уходит за счет уменьшения и в конечном итоге нулевого воздействия. Я имею в виду, давай, это то , что точка устаревания является . Мне кажется, что вы [множественное число] исходите из точки зрения «дай мне C или дай мне смерть», искусственно объединяя A и B, потому что вы просто не потерпите идеи о том, что какие-либо варианты имен параметров когда-либо исчезнут по какой-либо причине. Если я ошибаюсь в этом восприятии, пожалуйста, объясните.  -  SMcCandlish ☏ ¢  😼  04:18,14 февраля 2021 г. (UTC)[ ответ ]
  • Вариант C за Фила Бриджера. Элджит ( разговор ) 21:28, 11 февраля 2021 (UTC) [ ответ ]
  • Вариант C - комментарий здесь, вероятно, подпадает под список моих врачей, «что HF не должен делать, когда у него сотрясение мозга», но я не хочу пропустить это обсуждение. Хотя я понимаю, что поддержание шаблонов цитирования - непростая задача, в конце концов, жесткость шаблона цитирования нежелательна. Шаблоны цитирования должны быть простыми в использовании, а наличие пары псевдонимов для наиболее распространенных параметров упрощает использование. И форель гильдии ботов за утверждение задачи бота, которая была спроектирована так, чтобы не рекомендовать параметры шаблона, без единого мнения об этом. Обсуждение Hog Farm 22:15, 11 февраля 2021 г. (UTC) [ ответ ]
  • Первый выбор , второй выбор B . Исходный текст Википедии становится все более сложным и трудным в управлении, что делает его менее доступным, за исключением тех, кто участвует в этом виде опытных редакторов. Все, что мы можем сделать, чтобы уменьшить сложность, - это победа. Чем меньше вариантов, тем лучше, когда они явно избыточны. - Green 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?) - это своего рода аргументация, основанная на игнорировании практических фактов, которая приводит к конечным результатам в форме утконоса. - Mikeblas ( разговор ) 01:52, 12 февраля 2021 (UTC) [ ответ ]
  • A лучше в долгосрочной перспективе, но B на данный момент, и преобразование должно быть покрыто генами AWB и т.п. Headbomb { t · c · p · b } 02:29, 12 февраля 2021 (UTC) [ ответ ]
    Комментарий К сожалению, в данном случае оставлять это на усмотрение только генфиксов AWB было бы неэффективно и нежелательно. Поскольку на любой данной странице, вероятно, будет так много таких пармов, генфиксы, вероятно, затопят основное запланированное изменение, вызывая понятное раздражение. Гораздо лучше оставить это этому отличному боту, который ясно и открыто говорит о том, что делает - никаких неприятных сюрпризов. Вот почему я предпочитаю вариант A варианту B, но любой из них намного предпочтительнее варианта C. - NSH001 ( разговор ) 08:31, 7 марта 2021 г. (UTC) [ ответ ]
  • Вариант C за Фила Бриджера. SarahSV (разговор) 02:51, 12 февраля 2021 (UTC) [ ответ ]
  • Вариант C . Такой подход «все должно быть расставлено через дефис» плохо работает с текстовым редактором. Для некоторых распространенных параметров, таких как |accessdate=, просто лучше быть без дефиса, потому что исходный текст быстрее и легче разбирается человеком, потому что параметр не переносит слова в текстовое поле редактора. Джейсон Куинн ( разговор ) 03:09, 12 февраля 2021 (UTC) [ ответ ]
  • Вариант Б . Мы должны прекратить перечислять те, которые не содержат дефисов, по крайней мере, в документации, чтобы между редакционным сдвигом и очисткой генфиксов AWB / ботов мы со временем стали более последовательными. Еще слишком рано для варианта А, если вообще когда-либо, потому что шаблоны служат нам, а мы не обслуживаем шаблоны. Для шаблонов совершенно нормально поддерживать варианты без дефиса, чтобы они не сломались, если люди попробуют их. Но мы не должны продолжать перечислять эти варианты в документации. Это противоречит цели создания шаблонов, так как мы сохраняем несогласованность (без уважительной причины, например, цвет ENGVAR по сравнению с цветомразличие). И это бессмысленно делает документацию длиннее и сложнее без всякой выгоды; никто, ищущий, как указать URL-адрес Archive.org, не должен ничего знать, но |archive-date=и говорить им, что они |archivedate=тоже работают, - это просто забивать им в голову бессмысленные мелочи. Да, продолжайте преобразование в версии с дефисом в генфиксах и других автоматических изменениях (при одновременном выполнении чего-то более существенного). Наконец, вариант C бессмысленен. Мы регулярно (постепенно) отказываемся от поддержки различных старых имен параметров, и это отлично работает. Вариант Б ничего не сломает и даст (уже дает) положительные результаты.  -  SMcCandlish ☏ ¢  😼  04:21, 12 февраля 2021 г. (UTC) [ ответ ]
  • Вариант B Вариант C . Все это действительные псевдонимы, так как нет никакой путаницы между say|access-date=и|accessdate=. Статус-кво работает нормально: использование дефиса предпочтительнее, потому что его легче читать, но без дефиса приемлемо, потому что нет двусмысленности и, очевидно, многие люди набирают его таким образом. Косметические изменения должны соответствовать политике. -  Finnusertop ( обсуждение ⋅ вклад ) 05:53, 12 февраля 2021 г. (UTC) Изменено с B на C, поскольку я не согласен с последствиями «формально устаревшей» части этих допустимых псевдонимов. -  Finnusertop ( обсуждение ⋅ вклад ) 09:26, 12 февраля 2021 г. (UTC)[ ответ ]
  • Вариант C первый выбор (B второй). Редакторам должно быть разрешено использовать версии с дефисом или без него. Последовательность здесь не лучше, чем гибкость: единственные люди, читающие параметр, - это редакторы, поэтому позвольте редакторам решать, хотят ли они использовать дефис в своих параметрах шаблона. Я разделяю общую озабоченность по поводу разрыва связи между разработчиками кода и авторами контента, а также разочарование в связи с тем, что некоторые специалисты по сопровождению шаблонов и ботов навязывают решения всем без единого мнения. Свершившийся факт Редактирование миллионов правок или включений - это своего рода большое дело. Levivich  харасс / гончая 7: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 года (в котором, опять же, участвовало всего семь человек и согласились просто создать версии с дефисом в качестве альтернативы) и удалить версию с дефисом , которая в настоящее время мало полезен и, следовательно, будет намного проще и менее разрушительно утилизировать. -Aquillion ( разговор ) 22:12, 15 февраля 2021 (UTC) [ ответ ]
  • Вариант Б -иш. Я думаю, что это разумно, если дефисные формы будут канонической версией параметра, но я не вижу причин для массового редактирования, чтобы переходить от одной формы к другой или изменять здесь обычные правила для косметических ботов. Я не вижу вреда в варианте C, но реализация варианта A поменяет текущие проблемы на новые. - AntiCompositeNumber ( обсуждение ) 02:15, 16 февраля 2021 (UTC) [ ответ ]
  • Сильная поддержка A : стандартизация параметров шаблона важна и полезна.
Мягкая поддержка B : количество |accessdate=страниц на странице слишком чертовски велико (большую часть времени), настолько, что мешает проверке обычных WP: GenFixes (т.е. многие одноэкранные различия становятся многоэкранными) - я бы сильно поддержал B IIF Monkbot может продолжить и перенести хотя бы этот параметр.
Сильный Противостаньте C : антитезу A .
~  Том.Рединг ( обсуждение ⋅ 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, я полагаю , поскольку меня не убедили в предельной полезности версий, написанных через дефис. Без этой ясности мы не должны делать такого рода изменения. (И если бы у нас был консенсус, то Б, но с изменениями документации в качестве первого шага.) -  Джон ФромПинкни ( выступление ) 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 разговор 05:59, 23 февраля 2021 (UTC) [ ответить ]
  • Вариант C, если не B Хотя мне нравится последовательность, я изо всех сил пытаюсь понять, в чем заключается настоящая проблема. Я предполагаю, что они могут быть постепенно изменены ботом вместе с другими более полезными изменениями, но это просто косметика для кода и мешает истории редактирования. Обсуждение Reywas92 06:21 , 24 февраля 2021 (UTC) [ ответ ]
  • Вариант C . Преимущества для создателей ботов или шаблонов не перевешивают неудобств для других редакторов. Фрам ( разговор ) 08:13, 24 февраля 2021 (UTC) [ ответ ]
  • C . Я не вижу аргументов в пользу обязательного использования дефисов. Просто позвольте людям использовать оба, последовательность в этом не имеет значения. Заборы и окна 17:00, 24 февраля 2021 г. (UTC) [ ответ ]
  • Комментарий - по умолчанию я использую вариант D. Я отказываюсь использовать шаблоны цитирования и форматирую свои цитаты вручную. Это означает, что я могу игнорировать все глупые споры о параметрах и о том, что нет. Blueboar ( разговор ) 17:49, 24 февраля 2021 (UTC) [ ответ ]
    Да, и мы можем мгновенно очистить отставание WP: PHAB, написав статьи ручкой и бумагой. Мы можем решить многие технологические проблемы, отказавшись от технологий. Levivich  харасс / гончая 00:52, 25 февраля 2021 (UTC) [ ответить ]
  • Вариант C . Боты выполняют некоторую полезную работу, но их код можно изменить по мере необходимости. Здесь меня гораздо больше беспокоят обычные редакторы, которые используют шаблоны цитирования при ручном редактировании. Это живые люди, и их намного больше, чем ботов. Если сделать синтаксис шаблонов слишком жестким, их жизнь станет еще более неприятной. Дополнительная гибкость полезна и полезна для обычных редакторов. Nsk92 ( разговор ) 02:26, ​​25 февраля 2021 (UTC) [ ответ ]
  • Вариант C . Я набирал accessdate последние 15 лет или около того, иногда хватаясь за напиток другой рукой (клавиатура Qwerty). Зачем разрушать мою мышечную память и лишать меня глотка чая? - гадфий, 04:04, 25 февраля 2021 г. (UTC) [ ответ ]
  • Вариант C для Фила Бриджера Sea Ane ( разговор ) 21:53, 26 февраля 2021 г. (UTC) [ ответ ]
  • Вариант C , остановить сумасшествие, попадающее в списки наблюдения (хотя большая часть этого ущерба уже нанесена). Сэнди Джорджия ( Обсуждение ) 00:58, 2 марта 2021 (UTC) [ ответ ]
  • Лучше всего звучит C , за ним следует B. Удаление параметров, которые широко использовались в прошлом, сломает старые редакции статей и принесет очень мало практических преимуществ. - Кусма ( t · c ) 11:44, 2 марта 2021 г. (UTC) [ ответ ]
  • Вариант C . Другие уже задались вопросом, почему - спам в списках наблюдения, бесполезная трата времени и энергии, ненужное навязывание редакторам и т. Д. Я все больше склоняюсь к идее писать цитаты вручную (как уже упоминал здесь кто-то), просто для того, чтобы Избегайте постоянной возни с этими шаблонами. JG66 ( разговор ) 11:51, 2 марта 2021 (UTC) [ ответ ]
  • Вариант C на аквиллион. Monkbot никогда не должен был быть одобрен - In act (Guerillero) Parlez Moi 20:22, 2 марта 2021 (UTC) [ ответ ]
  • A или B Это похоже на выбор между ненужным наличием нескольких разных способов записи данного параметра и между стандартизацией постфактум с большим количеством мелких правок. Многие аргументы в пользу C, по-видимому, предполагают, что редакторы столкнутся с проблемами при написании параметров без дефисов, но я не вижу доказательств этого. Джо-Джо Эумер ( разговор ) 10:30, 4 марта 2021 г. (UTC) [ ответ ]
  • Вариант А . Из реального опыта я понимаю, насколько сложно поддерживать код без периодического устаревания. Опасения оппонентов перед неприемлемыми сбоями и неудобствами не соответствуют тому, с чем я столкнулся, когда бот работал, и ввод дефиса быстро стал моей привычкой. - Ворлдбрюс ( разговор ) 05:07, 7 марта 2021 г. (UTC) [ ответ ]
    Возможно, вы лично не сталкивались с нарушениями и неудобствами, но я столкнулся, и в этом и других обсуждениях есть очень много других редакторов, которые сообщили о недопустимых нарушениях и точно объяснили, почему неудобства не оправданы. Тридуульф ( разговор ) 20:29, 7 марта 2021 (UTC) [ ответ ]
  • Вариант А . Долгосрочная выгода стоит краткосрочного перерыва. В шаблонах слишком много несоответствий, из-за чего я трачу гораздо больше времени (например, это «image =» или «Image =» или «photo =» в этом конкретном шаблоне); мы должны двигаться к большей последовательности. Я бы поддержал сохранение параметров в рабочем состоянии в течение нескольких лет (но без документации и с предупреждением) для тех, кто действительно обеспокоен вводом дефиса, зная, что бот придет и изменит их. МБ 15:23, 7 марта 2021 г. (UTC) [ ответ ]
    Лучшее решение для "is it" image = "или" Image = "или" photo = "" - просто поддерживать их все. Таким образом, нет необходимости в каких-либо сбоях, краткосрочных или иных. Тридуульф ( разговор ) 20:31, 7 марта 2021 (UTC) [ ответ ]
  • Вариант A - стандартизация помогает упростить сопровождение кода, а это означает, что больше времени можно посвятить будущим улучшениям. Imzadi 1979  → 17:34, 7 марта 2021 (UTC) [ ответ ]
  • Перед нами стоит вопрос: следует ли полностью удалить параметры без дефиса из семейства шаблонов CS1 / 2? Да, безусловно, по большинству, если не по всем причинам, перечисленным выше. Должно быть реализовано согласованное именование параметров c. 2007 г., когда различные, независимо разработанные шаблоны cs1 | 2 были преобразованы для использования в качестве общего механизма обработки цитирования. В начале 2013 года en.wiki перешла на модуль: Citation / CS1.{{citation/core}}люкс. С тех пор около 180 вики-сайтов MediaWiki на других языках плюс некоторое количество вики-сайтов, не относящихся к MediaWiki, также перешли в набор модулей. За время, прошедшее с тех пор, как en.wiki перешла на набор модулей, мы добавили новые имена параметров для поддержки новой функциональности, и в то же время мы сократили довольно много имен параметров из-за избыточности, своеобразного стиля имени, неиспользования , и другие причины. Это сокращение включает большинство nonhyphenated неоднословных имен параметров , так что сегодня, только оставшиеся nonhyphenated имен параметров |accessdate=, |archivedate=, |archiveurl=, |authorlink=(и его два перечисленных форм), и|origyear=(имеется 263 основных имени параметра и 77 пронумерованных имен параметров). Принятие во всем мире набора модулей cs1 | 2 заставило нас добавить поддержку интернационализации. Неанглоязычные вики, использующие набор модулей cs1 | 2, должны сохранять все имена параметров на английском языке, потому что очень часто статьи, разработанные на en.wiki, экспортируются и переводятся на эти другие языки. Это означает, что полностью реализованный набор модулей неанглоязычной вики должен поддерживать 340 английских имен параметров плюс 340 локальных имен параметров. Я думаю, что лучше всего иметь единый согласованный стиль для многословных имен параметров, чтобы редакторам-переводчикам не приходилось узнавать или иметь дело с избыточными именами параметров (то же самое относится к начинающим редакторам на en.wiki). Шаблоны cs1 | 2 достаточно сложны, мы неЭту сложность необходимо усложнять, поддерживая списки синонимичных имен параметров, не имеющих семантического значения (например,|chapter=, |article=, |entry=, |section=И т.д., обрабатывают КС1 | 2 как синонимы , но, редакторам, передают разные значения - включение или бездействие дефис транспортирует не имеет смысла награждений). Так что да, параметры без дефиса [должны] быть полностью удалены из семейства шаблонов CS1 / 2, и поскольку мы не можем вернуться в 2007 год, чтобы сделать то, что мы должны были сделать тогда, мы должны сделать это сейчас, мы должны сделать это быстро, и мы должны это сделать. Мой предпочтительный вариант , но, если это необходимо должно, то (Вздох) B ; никогда другой вариант. - Монах-траппист ( разговор ) 00:50, 8 марта 2021 г. (UTC) [ ответ ]
    Спасибо за взвешивание, траппист; Я просто хочу, чтобы ты сделал это месяц назад. Ваше объяснение убедительно, но я все же считаю вариант А глупым, если мы хотя бы одновременно не изменим документацию, чтобы сказать пользователям: «Больше не используйте этот параметр». Бороться с ботами против редакторов-людей глупо, неэффективно и, возможно, даже опасно . -  JohnFromPinckney ( разговор ) 02:03, 8 марта 2021 г. (UTC) [ ответ ]
    Итак, суммируя аргументы траппистов: разработчикам намного проще иметь только несколько имен, поэтому мы должны нарушить работу редакторов и, следовательно, вики, чтобы облегчить их жизнь, независимо от затрат (ранее подробно объяснялось, как два имени делают одно и то же. вещь совсем не проблема для редакторов). Извините, но это ни в малейшей степени неубедительно: шаблоны существуют для поддержки редакторов, а не наоборот. Тридуульф ( разговор ) 03:06, 8 марта 2021 (UTC) [ ответ ]
    Нет. Траппист такого не сказал. Он услужливо объяснил, почему это изменение необходимо. За возможным исключением списков наблюдения, это изменение не серьезно "нарушает работу редакторов" (нельзя сказать, что необходимость ввода одного дополнительного символа является проблемой такого масштаба); наоборот, в долгосрочной перспективе это делает жизнь легче для редакторов, потому что есть только один простой, легкий для запоминания правила: все параметры мути слова использовать дефис для разделения слов. В списках наблюдения см. # Стоит отметить ниже, что кажется многообещающим решением. И если худшее дойдет до худшего и это решение не сработает для вас, то я сочувствую, но, по крайней мере, «сбои» будут временными, пока бот не закончит работу. - NSH001 ( разговор) 10:05, 8 марта 2021 г. (UTC) [ ответ ]
    Нет, сбой не временный. Мало того, что люди, вероятно, продолжат использовать «старые» параметры, но и удаление поддержки этих параметров из шаблонов означает, что миллионы старых ревизий будут содержать ошибки вместо того, чтобы просто отображать ссылки, как раньше. Создание ошибок в ссылках старых версий бесчисленных страниц, так что вам нужно поддерживать только 340 вместо 349 параметров (ну, даже не это, 340 параметров + 9 синонимов)? Похоже, что это большой сбой без особой выгоды. Фрам ( разговор ) 11:13, 8 марта 2021 (UTC) [ ответ ]
    На самом деле это не имеет значения, ссылки на старые версии страниц относительно редки, а сообщения об ошибках можно спокойно игнорировать - имеет значение только последняя страница. Они также страдают от удаленных шаблонов (которые могут быть гораздо более серьезными для страницы, поскольку фактически отображаются для пользователя) и вики-ссылок, которые стали красными, потому что целевая страница была удалена. Без сомнения, о других вещах, о которых я еще не думал. Человек просто принимает эти недостатки. Ничего серьезно не "нарушает". - NSH001 ( обсуждение ) 14:05, 8 марта 2021 г. (UTC) [ ответ ]
    Красная ссылка, потому что цель не существует, не проблема (это даже улучшение). Остальные - проблемы, и сознательное добавление большего, гораздо большего количества того же самого - серьезная проблема. Версия Сальвадора Дали 5-летней давности уже содержит около 10 ошибок: больше всего раздражают языковые ошибки. Но запланированная дефенестрация, например, accessdate внезапно добавит сюда 24 дополнительных ошибки. По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже, и отсутствие текущих будущих версий, которые станут лучше. Фрам ( разговор ) 14:33, 8 марта 2021 (UTC) [ ответ ]
    «По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже». Это неправда. Правки Monkbot 18 никак не влияют на отображение сообщений об ошибках; фактически это сократит (значительно) количество сообщений об ошибках, которые в конечном итоге будут отображаться, когда и если оставшиеся формально не рекомендуются, где «формально не рекомендуется» означает изменение набора модулей CS1 / 1 для фактического создания сообщений об ошибках. - NSH001 ( разговор ) 09:37, 11 марта 2021 (UTC) [ ответ ]
    Не ложь, просто стенография. Можно увидеть количество ошибок, которые будут существовать, посмотрев на количество правок, которые Monkbot делает для этого. Нет, Monkbot не вызывает ошибок напрямую, это вызывает устаревание; но эти двое принадлежат друг другу. Если выбран вариант C, то не будет «когда и если», остальные не будут официально считаться устаревшими, и не будут генерироваться сообщения об ошибках ни в исторических, ни в реальных версиях. Никто. Фрам ( разговор ) 10:56, 11 марта 2021 (UTC) [ ответ ]
    «Можно увидеть количество ошибок, которые будут существовать, посмотрев на количество правок, которые Monkbot делает для этого». Это очень вводит в заблуждение. Количество правок, сделанных ботом, не имеет никакого отношения к ошибкам, отображаемым в реальной версии (за исключением того, что, как я уже объяснил, они уменьшаются ). Здесь вы пытаетесь ввести читателей в заблуждение, подразумевая, что каждое отдельное изменение, выполняемое ботом, вызывает сообщение об ошибке, хотя на самом деле это происходит только с историческими версиями. Сообщения об ошибках в исторических версиях не имеют значения. - NSH001 ( обсуждение ) 12:00, 11 марта 2021 г. (UTC) [ ответ ]
    Нет, это не вводит в заблуждение, если читать настоящую беседу об исторических версиях. «удаление поддержки этих параметров из шаблонов означает, что миллионы старых ревизий будут содержать ошибки вместо того, чтобы просто отображать ссылки, как раньше». и "По сути, каждое редактирование, которое MonkBot делает для них, будет означать одну или несколько ошибок в каждой редакции истории или миллионы и миллионы старых версий, которые станут хуже, и нетекущие из будущих версий, которые станут лучше ». Это то, на что вы ответили, и это мы все еще обсуждаем. Мы можем не согласиться, являются ли ошибки в старых версиях проблемой или нет, или же затраты на поддержание нескольких синонимов в живых незначительны. или значительный; но, пожалуйста, не начинайте обвинять людей в том, что они «пытаются ввести читателей в заблуждение» (немного богато из-за того, что кто-то утверждает, что «access-date» проще в использовании и более значимо, чем «accessdate»). Фрам ( разговор ) 12 : 12, 11 марта 2021 г. (UTC) [ ответ ]
  • Вариант C И эта проблема в значительной степени объясняется тем, что я нахожусь в нынешнем положении. BAG не подходит по назначению и требует ядерной бомбардировки с орбиты. Только смерть заканчивает долг ( разговор ) 15:31, 8 марта 2021 (UTC) [ ответ ]
    СУМКА выполняет несколько функций. Он хорошо справляется с некоторыми из них - в частности, он довольно хорошо обеспечивает, чтобы боты делали только то, что их авторы намереваются делать, прежде чем они будут выпущены. Основная проблема заключается в том, чтобы гарантировать, что только задачи с консенсусом, который должен быть выполнен, и консенсусом для бота для выполнения работы, утверждаются - я не могу вспомнить случай, когда он не смог утвердить что-то, что должно быть одобрено, и это действительно остановило вопиюще плохие идеи от продолжения, но есть несколько случаев (включая этот), когда планка консенсуса была установлена ​​слишком низко, и небольшой локальный консенсус позволил боту работать без одобрения широкого сообщества. Если у нас есть боты, нам действительно нужен какой-то процесс утверждения, поэтому не уничтожайте того, что у нас есть, не придумав сначала чего-то лучшего.Thryduulf ( разговор) 16:54, 8 марта 2021 (UTC) [ ответ ]
    «только то, что их авторы намереваются сделать до того, как они будут освобождены». На техническом уровне это правильно - то, что BAG не делает, - это какая-то даже полуприличная работа по подтверждению того, что боты * продолжают * выполнять только те задачи, для которых они были первоначально одобрены, или что это одобрение в первую очередь имеет консенсус среди тех редакторов, на которых это * повлияет * на то, что задача желательна или необходима, или что есть явная выгода для тех, кто ее выполняет. Проблема с автоматическим редактированием редко заключается в техническом аспекте, это его экономическое обоснование. Если бы мы провели обзор текущих активных задач ботов (и редакторов, использующих автоматическое редактирование для выполнения массового редактирования), действительно ли вы думаете, что все они смогут указать на обсуждение, которое показывает уровень консенсуса, пропорциональный их влиянию на более широкие массы редакторов? ,а не обнесенный стеной сад (и термин, который я бы предпочел использовать здесь, поскольку он более точен, - это круговой рывок) 5 или 6 данных и машиночитаемых одержимых редакторов, которые этого хотят?Только смерть заканчивает долг ( разговор ) 08:30, 11 марта 2021 (UTC) [ ответ ]
    Что касается технического и бизнес-аспекта, я согласен, это была большая часть того, что я пытался подчеркнуть. Я также согласен с тем, что необходимо проводить регулярный обзор задач бота и автоматического редактирования. Есть некоторые, которые, я уверен, все еще имеют консенсус сообщества (например, антивандальные боты), но я не могу сказать, что это будет справедливо для каждой задачи. Я также согласен с тем, что должен быть активный консенсус редакторов, которые будут затронуты, прежде чем задача будет продолжена - в случае с monkbot почти все затронутые редакторы совершенно не знали, что это вообще было предложено. Тридуульф ( разговор ) 14:20, 11 марта 2021 (UTC) [ ответ ]
  • Вариант Б. Я легко вижу обе стороны этого спора. Как человек, работающий в сфере информационных технологий, я полностьюсогласны с тем, что ИТ должны, по возможности, в первую очередь обслуживать потребности пользователей, а не просто облегчать жизнь людям, обслуживающим системы. Я вижу слишком много систем, которые усложняют жизнь, чем нецифровая альтернатива, что просто смешно. Конечно, бывают случаи, когда что-то нужно исключить, потому что оно либо несовместимо с другими вещами, либо имеет бреши в безопасности, либо требует слишком много времени на разработку для обслуживания. Этот случай - один из последних, хотя я не уверен, какую дополнительную нагрузку на самом деле добавляют устаревшие (без дефисов) параметры. Я бы порекомендовал нам официально отказаться от непереносимых параметров и очистить их с помощью генфиксов AWB, но я не могу поддерживать продолжение работы с Monkbot 18, учитывая силу настроения против такой задачи. ЛичноМеня не волнует «спам в списках наблюдения», но очевидно, что многие люди волнуются, и мы не можем просто игнорировать их мнение, потому что «это облегчило бы жизнь нам, техническим специалистам». ƒirefly ( t · c ) 07:42, 10 марта 2021 (UTC) [ ответ ]
    Насколько я понимаю, есть структура для поддержки псевдонимов параметров, которые настраиваются в Module: Citation / CS1 / Configuration . Поскольку поддерживается много других псевдонимов, структура останется на месте. isaacl ( разговор ) 15:23, 10 марта 2021 (UTC) [ ответ ]
  • Вариант A / B, как указано выше.  Spy-cicle💥  Разговор ? 18:50, 10 марта 2021 г. (UTC) [ ответ ]
  • Вариант A , категорически против варианта C. Дефисы должны быть стандартными, и мы не должны их поощрять. Я не против продолжения поддержки версии без дефиса для B, но B также подразумевает, что бот не может выполнять свою работу, поэтому A так и есть. SportingFlyer T · C 12:57, 11 марта 2021 (UTC) [ ответ ]
    Почему следует отвергать одну версию над другой? Какая польза от энциклопедии, которая перевешивает сбои, вызванные прекращением поддержки давно существующей и широко используемой функции? Почему бот должен быть свободен и продолжать выполнять работу, по которой у него нет консенсуса? Тридуульф ( разговор ) 14:22, 11 марта 2021 (UTC) [ ответ ]
    Здесь мы пытаемся достичь консенсуса, верно? Я поддерживаю стандартизацию ссылочных тегов и не думаю, что у оппонентов есть веские контраргументы. Буду признателен, если вы позволите мне (и другим) высказать свое мнение без необходимости комментировать - вы не «правы», и мы не «неправы». SportingFlyer T · C 15:01, 11 марта 2021 г. (UTC) [ ответ ]
    Я не пытаюсь помешать людям высказывать свое мнение. Я пытаюсь заставить людей объяснить их и фактически опровергнуть аргументы, объясняющие предпочтения, отличные от их собственных. Почему стандартизация ссылочных тегов важнее, чем причины нарушения стандартизации? Почему желание избежать этого разрыва «плохой контраргумент»? Я могу быть или не быть «правым», но если вы не можете объяснить, почему принудительная стандартизация вопреки желанию очень значительного числа редакторов (которые не увидят никакой выгоды от такой стандартизации, но будут испытывать значительные постоянные нарушения из-за нее) в какой-то степени желательна. тогда нет никакой надежды на достижение консенсуса в отношении ваших взглядов. Тридуульф ( разговор ) 16:02, 11 марта 2021 (UTC) [ ответ ]
    Вы упрекаете меня за то, что я не возражаю против вашего аргумента, хотя ваш аргумент выше просто «Я не вижу в этом смысла». Мы работали над этим некоторое время, это обсуждалось на страницах обсуждений, это упрощает ведение энциклопедии, и это хорошая идея, чтобы закончить проект, а не откладывать его на потом пользователей, которым это не нравится. . Я также думал, что просто голосую здесь, я думаю, что это очевидно, и я не хочу втягиваться в долгие споры по этому поводу, поэтому я не только не оценил ваш ответ, но и был бы признателен, если бы вы оставили это только разговор идет вперед. SportingFlyer T · C 16:49, 11 марта 2021 (UTC) [ ответ ]
    Как и в случае со многими из этих типов вопросов, вывод, который делает каждый человек, во многом зависит от того, какое значение они придают относительным приоритетам различных факторов. Мы излагаем наши аргументы с учетом компромиссов, и другие могут использовать их, если хотят выяснить, какие компромиссы они хотели бы пойти. isaacl ( разговор ) 17:13, 11 марта 2021 (UTC) [ ответ ]
  • Вариант C Если нет проблемы с ботами, которые должны читать accessdate и access-date как одно и то же (и, похоже, нет проблемы из того, что было описано, поскольку боты могут это делать), то я не уверен, что принуждение Пользователи, которые уже пишут accessdate, чтобы сделать ошибку, когда они продолжают делать это после того, как его использование остановлено, что боты будут затем отмечать, чтобы люди могли решить, будет полезно сделать. Создание ситуации, которая расстроит и демотивирует добровольцев без уважительной причины, кроме «соответствия», не похоже на хороший план. Действительно, в исходном RfC 2014 года подчеркивалось, что «Установление этого единого соглашения об именах параметров не исключает существования любого другого псевдонима для параметра, просто для каждого параметра будет существовать версия с переносом в нижнем регистре».И некоторые из тех, кто поддерживает, сделали это, потому что: «Это значительно уменьшит путаницу редактора. Им не нужно думать о:» Это параметр, в котором слова собраны вместе, или это тот параметр, в котором они разделены знаком '_ '? «Надеюсь, это упростит использование шаблонов». - Пользователь: Макиен . Нам следует обратить внимание на то, чтобы боты читали различные способы, которыми пользователи могут написать слово или фразу в шаблоне. Я ненавижу, когда, например, я по ошибке использую заглавную букву, а шаблон не работает, и мне нужно разобраться, в чем проблема. Я не слежу за тем, как расстраивает, демотивирует и отталкивает добровольцев, изменяя принцип работы шаблона и создавая им проблемы, чтобы «уменьшить бремя обслуживания» для этих пользователей. Иногда такие вещи, как изменение функциональности, отталкивают пользователей. SilkTork ( разговор ) 01:09, 12 марта 2021 (UTC) [ ответ ]
  • Вариант C . Я не проверял, был ли этот перенос сделан в рамках RFC шестилетней давности с семью людьми или в рамках RFC семилетней давности с шестью людьми. Но никто не оспаривал, что это был RFC не менее шести лет с участием не более семи человек. Сейчас, похоже, есть большое количество пользователей, которые не согласны. Возможно, сказав им, что они «не видят более широкой картины», будет достаточно, чтобы заставить несогласных замолчать. Может быть, снова повторится «прием Визуального редактора». Кто знает будущее? Pldx1 ( обсуждение ) 15:07, 12 марта 2021 (UTC) [ ответ ]
  • Вариант А . Я не вижу реальных аргументов в пользу того, почему шаблоны цитирования должны представлять собой мешанину из двух разных имен параметров. Это бельмо на глазу, это заноза в заднице, и от этого нет никакой пользы. Есть несколько способов исправить это: чтобы новые имена параметров были интегрированы в каждый инструмент, каждую смежную задачу и каждый инструмент автоматического редактирования, и тогда, возможно, через десять лет 90% из них исчезнут (но оставшиеся 10 % будет волей-неволей разбросан по всему проекту и его невозможно будет выследить). Или мы могли бы просто сделать один короткий пробег и покончить с этим. Я, со своей стороны, был бы рад, если вопрос будет решен. jp × g 05:33, 15 марта 2021 (UTC) [ ответ ]
    Вы действительно подготовили какие-либо комментарии, оставленные другими? Существует по крайней мере полдюжины различных причин полезности нескольких форм параметров. Даже если выбран вариант А, нарушение работы не будет краткосрочным, а будет продолжаться годами по причинам, неоднократно объясненным в другом месте на этой странице. Тридуульф ( разговор ) 12:27, 15 марта 2021 (UTC) [ ответ ]
  • Вариант А . Со временем мы развиваем разные условности. Как только мы это сделаем, нам нужно очистить использование старых соглашений. Вариант B будет слишком медленным, и этот вопрос будет затягиваться еще много лет. Итак, во-первых, убедитесь, что вся документация недвусмысленно описывает использование только новых имен. Во-вторых, убедитесь, что все инструменты редактирования используют только правильные имена параметров и все правила genfix обновлены. Подождите, пока бот завершит полный проход, а затем обработайте старые имена параметров как серьезные ошибки - GhostInTheMachine поговорит со мной 15:36, 15 марта 2021 г. (UTC) [ ответ ]
  • Вариант C . Энциклопедия должна вестись для читателей и, при условии, для выгоды редакторов. Создание занятой работы и случайных условностей ради этого бесполезно. Stifle ( разговор ) 10:19, 16 марта 2021 (UTC) [ ответ ]
  • Комментарий: приведенный здесь аргументи в другом месте о том, насколько проще было бы работать разработчикам шаблонов и модулей в соответствии с Вариантом А, является полностью ошибочным и высокомерным. Он направлен на то, чтобы принести пользу небольшой подгруппе, которая не является ни потребителями энциклопедии, ни ее основными создателями. А именно, он требует оптимизации простоты работы и удобства для очень небольшого числа разработчиков шаблонов / модулей, а не оптимизации для (гораздо большего числа) редакторов статей. Компромисс должен принести пользу наибольшему числу; если усложнить задачу редакторам, пострадают читатели статьи, а они - самая большая группа из всех и причина, по которой существует энциклопедия. Это должно быть аксиомой, но энциклопедия здесь не для удобства авторов шаблонов и модулей. Лично я счастлив писать и улучшать шаблоны и ломать голову о squirrely,сбивающие с толку, а иногда и приводящие в ярость проблемы с шаблоном, просто чтобы облегчить работу редакторам. Если это слишком неудобно или слишком много работы для разработчиков шаблонов / модулей, им следует воздержаться от «помощи» и просто улучшить содержание статьи, а не стремиться облегчить себе жизнь.Матглот ( разговор ) 23:42, 20 марта 2021 (UTC) [ ответ ]
    Thryduulf сказал , что это лучше (и кратко) , чем я, здесь : « Те , кто заботится о механике шаблона всегда должны действовать таким образом , чтобы активно ставят читатель первым, редактора вторым и третьи программисты. » Точно. Матглот ( разговор ) 00:04, 21 марта 2021 (UTC) [ ответ ]
  • Вариант C (предпочтительно) или Вариант B (второй вариант) - Beyond My Ken ( выступление ) 03:06, 23 марта 2021 г. (UTC) [ ответ ]
  • Самый сильный возможный вариант C Согласно WP: KISS и WP: IFITAINTBROKE . Если он не сломан, не чините его и не тратьте время на бессмысленные задачи ботов. Мы должны сделать шаблоны простыми в использовании. Полезно иметь разные псевдонимы для одного и того же параметра. Настаивать на одном конкретном формате из-за некоторого представления о том, что является правильным, а что нет, - это WP: CREEP , и, как правило, не рекомендуется. RandomCanadian ( обсуждение / вклад ) 01:59, 24 марта 2021 (UTC) [ ответ ]
  • Вариант C . Если бы мы начали сегодня и писали новый шаблон для обработки цитат, я бы настоятельно рекомендовал использовать единый согласованный формат для имен параметров. Но это не так. Многие тысячи редакторов привыкли использовать версии этих параметров без дефиса, и я не вижу причин нарушать их редактирование, чтобы (якобы) облегчить жизнь горстке редакторов шаблонов. Система, которая у нас сейчас есть, работает нормально, я не вижу смысла тратить время на ее изменение. Чунтук ( разговор ) 20:41, 30 марта 2021 (UTC) [ ответ ]
    • Этот и подобные ему аргументы были бы более убедительными, если бы десятки параметров, состоящих из нескольких слов, без дефисов не были исключены из шаблонов цитирования CS1 за последние семь лет с минимумом драматизма. Мы говорим здесь об удалении последних шести, что сделало бы всю систему параметров согласованной, а не текущую ситуацию, в которой почти все параметры, состоящие из нескольких слов, содержат только дефисы, а шесть имеют варианты без дефиса. Вариант C предлагает прекратить семилетнюю работу, когда она будет завершена примерно на 90%. - Jonesey95 ( разговор ) 01:59, 1 апреля 2021 г. (UTC) [ ответ ]
      • Действия свершившегося факта, когда действия оправданы тем, что они уже осуществлены и которые трудно повернуть вспять, являются неуместными . Если вас беспокоит, что некоторые параметры имеют псевдонимы без дефисов, а другие - нет, давайте разрешим использование непереносимых параметров для всех. Никкимария ( разговор ) 02:20, 1 апреля 2021 (UTC) [ ответ ]
        • На Help Talk: CS1 было обсуждение до прекращения поддержки каждого многословного параметра в течение последних семи лет, а затем дальнейшее обсуждение на той же странице до прекращения поддержки этих параметров. За эти семь лет были внесены миллионы изменений страниц для удаления устаревших параметров со страниц в затронутых пространствах имен. До этого последнего раунда правок, внесенных Monkbot, я не мог найти серьезных возражений против этих правок. Все это сильно отличается от свершившегося факта: действия не оправдываются тем, что они были осуществлены, они оправдываются многократным обсуждением на соответствующей странице обсуждения и соответствующим документированием. Опять же, единственная разница между этой работой по стандартизации параметров и сотнями других шаблонов - это масштаб. -Jonesey95 ( разговор ) 15:30, 1 апреля 2021 г. (UTC) [ ответ ]
  • Вариант А . Немного поработав с шаблонами CS1, я поддерживаю вариант, обеспечивающий наибольшую согласованность и простоту использования среди статей. Хотя согласованность между статьями действительно не полностью реализована, поскольку в разных статьях используются разные способы написания дат или цитат, я думаю, что, по крайней мере, отключение |accessdate=в пользу |access-date=, et al. , упростит поиск экземпляров строк без необходимости использовать регулярные выражения или два отдельных поиска, чтобы получить все. Кроме того, разрывы строк в окне редактирования упрощают просмотр. В этом нет ничего особенного, но я думаю, что в конечном итоге перевод всего в форматы с дефисами принесет нам гораздо больше пользы в долгосрочной перспективе. - В РЕЙНУЛЯТОР 9 (РАЗГОВОР ) 19:18, 1 апреля 2021 (UTC) [ ответ ]

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

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

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

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

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

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

  • Спасибо Nikkimaria за пинг, основанный на моем предыдущем участии. Я ужасно нейтрален (или разорван) по основной теме, но ранее я провел некоторый анализ, который заставляет меня беспокоиться о влиянии, в частности, на пространство шаблонов, если прекращение поддержки полностью продлится. Здесь я буду использовать |authorlink=в качестве прокси для всех шести, потому что лично я набираю чаще. Есть три области , которые касаются меня: шаблоны , которые косвенно Invoke CS1, те , которые transclude CS1-вызова шаблонов и клонов. Меня беспокоит, где и когда появляются красные сообщения об ошибках, а также документация, в которую я включаю и / doc, и TemplateData .
  1. Существует множество шаблонов, поддерживающих CS1, которые вызывают один из канонических шаблонов; Например, часто используется {{ Cite encyclopedia }}. Некоторые используют перезапись параметров, преобразуя их |authorlink=в |author-link=перед передачей.
    1. Всегда ли их документация имеет приоритет |author-link=? Думаю, мы их всех поймали во время предыдущего обсуждения, но я не могу гарантировать качество поиска.
    2. Поскольку код CS1 никогда не видит устаревший параметр, должен ли этот шаблон сам выдавать красную ошибку во время замены? Или, может быть, просто забыть о сопоставлении и пусть CS1 сделает это? А насколько сложно найти шаблоны с кодом подстановки параметров?
    3. Если |authorlink=когда-либо переходит от устаревшего к недействительному , тогда все эти сопоставления и документация должны быть обрезаны одним махом. Что ж, я предполагаю, что сопоставления могут оставаться на месте, хотя они могут сбить с толку невнимательных давних пользователей.
  2. Существуют шаблоны, которые просто включают предварительно заполненный шаблон в стиле CS1: например, встраивание {{ Cite book }} в качестве ссылки на определенный том, имеющий отношение к любому использованию этого шаблона. Все ли они исправлены? В противном случае их пользователь увидит красное сообщение об ошибке (правильно?), Которое не имеет ничего общего с их собственным использованием.
  3. Могут быть шаблоны, смоделированные на CS1, но имеющие собственное расширение, хотя я не знаю ни одного такого. Если они используются |authorlink=, следует ли их также привести в порядок?
Два заключительных комментария: их больше шести, если рассматривать варианты вроде |author1link=и |authorlink1=. И, в принципе, приведенные выше аргументы применимы к любой странице за пределами пространства шаблона, которая кем-то включается, хотя я знаю, что эта функция используется редко. Дэвид Брукс ( разговор ) 16:51, 12 февраля 2021 (UTC) [ ответ ]
Надо было сказать: вышесказанное относится к A и в некоторой степени B, но вы, вероятно, сможете это понять. Дэвид Брукс ( разговор ) 16:57, 12 февраля 2021 (UTC) [ ответ ]
Дэвид Брукс : Крошечная армия редакторов готова исправить эти шаблоны. Насколько мне известно, не существует подключаемых шаблонов, которые передают |authorlink=ваш пример каким-либо шаблонам CS1, поэтому использование этих шаблонов не приведет к возникновению сообщения об ошибке. |accessdate=и два или три оставшихся без дефисов параметра, передаваемых из включений шаблона в шаблоны CS1, обрабатывались ботом до того, как бот был приостановлен для проведения этого обсуждения. Как только это обсуждение будет закрыто, бот сможет возобновить эту работу с помощью человека, если закрытие будет разумным. - Jonesey95 ( разговор ) 17:13, 21 февраля 2021 г. (UTC) [ ответ ]
@ Jonesey95 : Я только что затронул связанную проблему в справке: Citation Style 1 , где, изменив приведенный пример, я обнаружил 3 шаблона, которые используются |authorlink=в шаблоне в стиле CS1, который используется для ссылки на конкретный источник: {{ Семейное древо Бармакидов }} , {{ Citeer web }}, {{ Alox2 }}. Но этот менее строгий запрос показывает еще несколько (я думаю, игнорируйте архив "DYK"). Не уверен, имели ли вы в виду этот тип использования в своем комментарии; Возможно, мне не хватает контекста. Дэвид Брукс ( разговор ) 05:05, 22 февраля 2021 (UTC) [ ответ ]
@ Jonesey95 : Хорошо, похоже, вы починили {{ Alox2 }}. {{ Семейное древо Бармакидов }} и {{ Citeer web }} все еще нуждаются в исправлении (я сделаю их сегодня позже). Документация «Цитировать книгу (краткую)» в {{ Quicktemplates }} перечисляет не-некорректные |authorlink=, так что это подпадает под правило «предпочитать дефисные формы в документации». Я не искал |authorlink2=или |author2link=потому что они вряд ли появятся поодиночке. Дэвид Брукс ( разговор ) 19:17, 22 февраля 2021 года (UTC) ... контрольный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 Только дата, поэтому нарушайте 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) [ ответ ]
Нет, соответствующий редактор просто копировал / вставлял все, что они находили в любых статьях, которые они просматривали. (Пользователь также не узнал, что ссылки идут после знаков препинания, или что именованная ссылка, скопированная из другой статьи, может не быть объявлена ​​на целевой странице, или что в Википедии есть функция предварительного просмотра, позволяющая проверять ошибки. Не то чтобы я горько.) Согласен, без фактического осуждения, никто не знает, что они должны использовать или не использовать, поэтому списки наблюдения страдают от ненужного повторения. И я не могу указать такому пользователю на осуждение или согласие не использовать формы без дефиса, потому что их еще нет. -  JohnFromPinckney ( разговор ) 00:21, 22 февраля 2021 г. (UTC)[ ответ ]
Спасибо за это. Если редакторы на этой странице просто копируют цитаты из исходных биографий вики, то это хорошая новость - проблема исчезнет, ​​если боту просто разрешить продолжить и исправить проблему в исходных статьях. Я не думаю, что это правда, что нет единого мнения по поводу этого изменения: желаемый стиль был установлен в RfC несколько лет назад, и с тех пор был реализован на 90% без существенных возражений. Так что есть действенный консенсус, и нет смысла не доводить задачу до логического завершения. Возражения здесь сводятся к неприязни к большому количеству правок, вносимых ботами в списки наблюдения, а не к фактическим обстоятельствам дела. - NSH001 ( разговор ) 07:34, 22 февраля 2021 (UTC) [ ответ]
Рассматриваемый RfC имел только семь опор и касался только того, чтобы версия с дефисом существовала и была представлена ​​первой в документации. Я не знаю, как это можно трактовать как эффективный консенсус в отношении отказа от параметра, который до запуска бота, по-видимому, использовался чаще, чем вариант с переносом через дефис - и даже если бы мог, он был бы ограниченным . Возражение против бота состоит не только в том, что он много редактирует, но и в том, что он «исправляет» то, что не является проблемой. Никкимария ( разговор ) 14:01, 22 февраля 2021 (UTC) [ ответ ]
Именно это. -  JohnFromPinckney ( разговор ) 02:05, 23 февраля 2021 г. (UTC) [ ответ ]
Никкимария, первое заблуждение в вашем аргументе состоит в том, что вы предполагаете, что более широкое сообщество, если бы оно участвовало в первоначальном RfC, не согласилось бы с его выводом. Это не (совсем) случай - я почти уверен, что из различных вариантов, доступных для параметров, состоящих из нескольких слов (runon, camelCase, under_score, переносимость и т. Д.), Расстановка переносов все равно будет выбрана просто потому, что это легче всего читать в вики-тексте. Возможно, подчеркивание может быть лучше (оно не будет переносом строк), но большинству людей, за исключением, возможно, тех, кто имеет опыт программирования, будет гораздо удобнее использовать дефис, так что RfC пришел к очень разумному выводу. Но детали его реализации - другое дело. Вторая ошибка в вашем аргументе касается причины возражения против бота. В первую очередь,Наблюдаемый факт заключается в том, что некоторые редакторы сейчас поднимают огромную трату времени на этого бота, но ничего не говорят о том, что многие другие боты запускаются для всех других параметров CS1 / 2, выполняющих то же самое. Во-вторых, и я неоднократно наблюдаю это и в других RFC, редакторы склонны сосредотачиваться исключительно на предполагаемой краткосрочной проблеме, не принимая во внимание более широкую картину и более широкий контекст. Этот контекст уже был хорошо описан во введении к этому RFC и в приведенных там ссылках. Меня удивляет, что люди не видят, что весь смысл этой работы состоит в том, чтобы упростить и упростить использование шаблонов цитирования. Часть этого процесса - сделать имена параметров более значимыми и последовательными. Смешно оставлять беспорядок, унаследованный с первых дней создания шаблонов цитирования.с этими немногими оставшимися параметрами, торчащими, как больные пальцы. -NSH001 ( разговор ) 08:25, 25 февраля 2021 (UTC) [ ответ ]
Пожалуйста, объясните, почему разрешение, например, «accessdate» менее значимо, менее просто и труднее использовать для обычных редакторов. Это более широкая картина, более широкий контекст: преимущества на самом деле только для небольшой группы людей, которые имеют полное право изложить свою позицию и спросить, можно ли облегчить их жизнь, но не следует удивляться, когда выясняется, что в некоторых случаях их предпочтительное решение не поддерживается большей группой людей, которые не делают (или не так регулярно) шаблоны и боты. Размещение сообщений об ошибках на тысячах страниц для вещей, которые не являются ошибкой, но что некоторые люди решили, что больше не разрешено вообще, также теряет из виду более широкую картину. Фрам ( разговор ) 09:24, 25 февраля 2021 (UTC) [ответ ]
вы предполагаете, что более широкое сообщество, если бы оно участвовало в первоначальном RfC, не согласилось бы с его выводом . Я этого не знаю, и вы тоже, потому что с более широким сообществом никогда не консультировались . Мы можем быть разумно уверены, что обсуждение было бы гораздо менее односторонним, основываясь на последующих комментариях. Что касается второй части вашего пункта, как отмечает Фрам, совсем не ясно, почему отказ от широко используемых псевдонимов упростит использование шаблонов для обычного редактора. Никкимария ( разговор ) 13:33, 25 февраля 2021 (UTC) [ ответ ]
(отвечая обоим). Да, это просто. Для всех шаблонов цитирования CS1 / 2 существует очень простое правило: все параметры, состоящие из нескольких слов, используют дефис для разделения слов. Вот и все. Мертвых легко запомнить. Причем для подавляющего большинства параметров он уже реализован (осталось сделать только 5). Я не верю аргументу, что необходимость печатать ОДИН дополнительный символ - невыносимое бремя. Единственное веское возражение, которое я вижу, это то, что бот может наводнять списки наблюдения, но это временно, пока запуск бота не будет завершен. Так что мои соболезнования тем, кто чувствует раздражение (у меня нет - в моем списке наблюдения более 6000 страниц, и бот-спам меня не беспокоит), но раздражение будет временным. Если вас это действительно беспокоит, другие уже упоминали способ настройки вашего списка наблюдения, чтобы избежать этой проблемы.- NSH001 ( разговор) 07:35, 8 марта 2021 г. (UTC) [ ответ ]
Я рад, что вас лично не раздражает это изменение, но другие раздражают, и другие объясняют, почему скрытие проблемы не решает ее. Никто не предлагает удалить вариант с дефисом, просто поддерживая (часто более широко используемые) псевдонимы. Неуместно оправдывать изменение тем, что оно в основном осуществляется . Никкимария ( разговор ) 02:49, 12 марта 2021 (UTC) [ ответ ]
В списках наблюдения см. # Стоит отметить ниже , чтобы узнать о возможном способе уменьшения "сбоев". Я забыл ответить на замечание Фрама о более широком контексте: я думал об общем соглашении об именах и о том, почему бот упрощает его, но последний вклад Trappist в раздел опроса также объясняет более широкое рассмотрение, которое нам необходимо учитывать во всех несоответствиях. -Английские Википедии, которые позаимствовали наши шаблоны / модули CS1. - NSH001 ( разговор ) 10:40, 8 марта 2021 г. (UTC) [ ответ ]
Значит, решение проблемы редактирования бота против консенсуса для тех, кто возражает, чтобы перестать его смотреть? Вы не могли придумать это. Опять же, это долбаная энциклопедия, а не место, где технари диктуют редакторам. Найдите игровую площадку в другом месте или найдите настоящую работу, и вы обнаружите, что люди могут получать деньги за написание программ, только если они делают то, что их пользователи хотят от них. Фил Бриджер ( разговор ) 21:27, 21 февраля 2021 (UTC) [ ответ ]
Фил, твое первое предложение неверно. Этот бот был одобрен консенсусом в соответствии со стандартными процедурами. Действительно, его оператор пошел на все, чтобы кричать с крыш, что это «косметический» бот. Я проигнорирую ваши безудержные и беспочвенные личные нападки. Наконец, по вопросу о редактировании ботами и списках наблюдения, я отсылаю вас к сообщению Bilorv в 11:34, 13 февраля, выше, которое выглядит как хорошее решение (я просто добавлю оговорку, что я еще не тестировал его). - NSH001 ( разговор ) 08:25, 25 февраля 2021 г. (UTC) [ ответ ]

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

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

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

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

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

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

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

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

Следующее обсуждение представляет собой архивную запись запроса на комментарий . Пожалуйста, не изменяйте его. Никаких дальнейших изменений в это обсуждение вносить не следует. Краткое изложение сделанных выводов следует ниже.
Существует твердый консенсус против ограничения незначительных правок антивандализмом, как это предлагается в предложении. Альтернативные предложения ограничить незначительные правки автоподтвержденными или расширенно подтвержденными редакторами получили значительную поддержку в обсуждении, но трудно сказать, насколько они обширны, поскольку многие респонденты не упомянули альтернативные предложения в своих комментариях. Следовательно, другой RFC, чтобы ограничить использование второстепенных правок автоподтвержденными редакторами, может быть в порядке. ( закрытие без прав администратора ) ( t · c ) buidhe 10:52, 23 марта 2021 (UTC) [ ответ ]


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

Обзор (мелкие правки)[ редактировать ]

  • Поддержка Суть, по-видимому, в том, что некоторые редакторы игнорируют правки "m" в списках наблюдения. Ни один опытный редактор не стал бы этого делать, потому что «m» правки могут быть такими же неправильными, разрушительными или разрушительными, как и «серьезные» правки. Вандалы могут использовать их для совершения вандализма, новички-редакторы добросовестно вносят проблемные изменения, а опытные редакторы могут делать то, что, по их мнению, является незначительным, но другие редакторы с этим не согласны. Действительно, все правки подлежат оспариванию. Задача списка наблюдения - отслеживать статьи . Более того, мы, по всей видимости, блокируем редакторов за незначительные правки. Функционал не только бесполезен, но и отрицателен. О незначительных изменениях можно сообщить через сводку редактирования и счетчик различий.ProcrastinatingReader ( говорить) 19:56, 15 февраля 2021 (UTC) [ ответ ]
  • Против . Я все время отмечаю правки как незначительные, хотя на самом деле они незначительны. Исправление опечаток и тому подобное не должно беспокоить редакторов, которые не хотят видеть эти правки. Если есть проблема с помеченными как второстепенные правки не второстепенными, выясните, как это исправить. Мы уже отмечаем, например, возможные изменения дат рождения и смерти. BD2412 T 20:03, 15 февраля 2021 (UTC) [ ответ ]
    • Примечание : я поддерживаю приведенные ниже предложения по ограничению незначительных правок либо автоподтвержденными, либо расширенными подтвержденными редакторами (предпочтительно последними). BD2412 T 04:56, 3 марта 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, особенно о злом , - это хороший способ сформулировать проблему imo. Пока через него могут проходить какие-то спорные правки, вся функция бесполезна. Допуск к антивандализму обусловлен тем, что он уже регулируется существующей политикой 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) [ ответить ]
    В качестве первого шага поддержите ограничение автоподтверждением . Предлагаю ограничение на продление подтверждено. Я понимаю аргументы в пользу, но в целом я против расширения роли EC, отняв привилегии у пользователей с автоподтверждением (другое дело - предоставить пользователям EC привилегии, которые в противном случае доступны только более ограниченным пользователям). Даже с этим мы не могли предотвратить каждую ошибку, ошибочно помеченную как мелкие, и не должны стремиться к этому. Большинство мелких правок, помеченных кем-то, например, с 2-месячным опытом и 100 правками, подойдут, а если нет, они вряд ли поймут это к 500-й правке. -  The  Earwig  ( разговор ) 06:46, 3 марта 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 }} обсуждение 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-адреса. Хотя мы, безусловно, можем улучшить наши рекомендации по использованию флажка второстепенного редактирования, уровень угрозы не требует ограничения редакторов с автоподтверждением, которым мы уже доверяем, с гораздо более мощными инструментами в их руках. - ГВП · · ро · дез 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 за сегодня, с которым я согласился с ним), что ограничение его автоподтверждением - хорошая идея. 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) [ ответ ]
  • Поддержка этого делает «запрос на незначительные изменения» основным значением разрешения на откат. Как только кто-то узнает достаточно, чтобы этого захотеть, мы должны дать ему это. power ~ enwiki ( π , ν ) 03:03, 2 марта 2021 (UTC) [ ответ ]
  • Противодействовать . Решение, которое было бы намного хуже, чем проблема, которую оно пытается решить. Незначительные правки полезны. Ограничение его для пользователей с автоподтверждением может решить большую часть злоупотреблений (поскольку большинство вандалов не являются AC); если вообще есть такое злоупотребление. RandomCanadian ( обсуждение / вклад ) 03:44, 2 марта 2021 г. (UTC) [ ответ ]
  • Против . Пометка правок как незначительных не очень полезна, но дает некоторые преимущества при просмотре истории редактирования статьи. Конечно, флаг «второстепенное редактирование» так же надежен, как и сводка редактирования (то есть не очень), и вам не следует делать что-либо автоматическое на основе наличия или отсутствия флага. - Кусма ( t · c ) 11:55, 2 марта 2021 г. (UTC) [ ответ ]
  • Поддержка . Должно быть привилегией. В настоящее время это хуже, чем бесполезность для вандализма и просто лишняя когнитивная перегрузка для добросовестных редакторов. Ролло ( разговор ) 22:06, 2 марта 2021 (UTC) [ ответ ]
  • Ограничение до расширенного подтверждения (автоподтверждение слишком легко обойти), потому что только опытные редакторы должны иметь возможность отмечать изменения как незначительные. Тогда, если я проигнорирую незначительные изменения, мне не придется беспокоиться о пропущенных изменениях, не относящихся к EC. Levivich  харасс / гончая 04:42, 3 марта 2021 (UTC) [ ответить ]
  • Предположим, я не думаю, что есть проблема, которую нужно решать. Я думаю, что мелкие правки - полезный инструмент для настоящих мелких правок. джорт ⁹³ | обсуждение 19:56, 4 марта 2021 (UTC) [ ответ ]
  • Противостоять Это решение в поисках проблемы. Многие пользователи, в том числе и я, не злоупотребляют мелкими правками. Это как запретить кому-либо есть пищу, потому что некоторые люди едят слишком много. Спасибо, Chicdat  Bawk   мне! 11:58, 6 марта 2021 (UTC) [ ответ ]
  • Противник Просто наказывайте тех, кто злоупотребляет этим. Небольшие правки в целом полезны для этого проекта. ~ HAL 333 22:16, 7 марта 2021 (UTC) [ ответ ]
  • Противостоять, как написано. Поддержка, ограничивая его автоподтверждением или расширенным подтверждением. - Ахехт (РАЗГОВОРНАЯ СТРАНИЦА) 20:23, 9 марта 2021 (UTC) [ ответ ]
  • Противодействие незначительным правкам четко определено в WP: MINOR , и они имеют хорошее назначение. Кроме того, многие люди, которые возвращаются к вандализму, не являются откатниками (как я) - предшествующий неподписанный комментарий добавлен Bop34 ( обсуждение • вклад ) 20:46, 9 марта 2021 г. (UTC)[ ответ ]
  • Против. Просто потому, что некоторые люди могут злоупотреблять незначительными правками, это не означает, что мы должны практически полностью отказаться от их использования для редакторов.  Spy-cicle💥  Разговор ? 18:49, 10 марта 2021 (UTC) [ ответ ]
  • Противятся, но готовы к реформе, если бы мы просто избавились от незначительных правок, это либо отпугнуло бы людей от внесения правок, которые просто исправляют орфографию или грамматику, либо затруднило бы тем, кто модерирует редактирование, выяснить, что является спамом, а что нет. Мы могли бы изменить это, если бы я сделал так, чтобы все правки меньшего размера (скажем, 100 байт, это просто пример) были помечены как второстепенные и не могли быть отменены как второстепенные. Когда я редактировал в Фэндоме (похожем на Википедию, за исключением игр), я отмечал правки, в которых я просто вносил небольшие правки в статьи (например, исправляю орфографию или грамматику), как незначительные, потому что, ну, это так. Если мы просто удалим возможность отмечать правки как незначительные, у людей может возникнуть чувство, что они должны радикально изменить статью. Я, наверное, повторяюсь, поэтому я предложу другой способ реформировать это.Просто отметьте все правки как незначительные по умолчанию. Да, есть вариант, но я думаю, что люди этого не знают. Другой способ реформирования - это, как я уже сказал выше, пометить все правки ниже определенного размера как второстепенные, и если кто-то попытается снять пометку как второстепенные, но все еще меньше этого размера, появится предупреждающее сообщение, позволяющее пользователю узнать, что Дело в том, что это помечено как второстепенное. Когда он превышает определенный размер, он не может быть отменен как второстепенный, если у пользователя нет специальных разрешений на это (т. Е. Он является надежным редактором Википедии). Это всего лишь мое мнение, но после прочтения всего вышеперечисленного я почувствовал, что должен внести свой вклад.иметь все правки, меньшие определенного размера, помеченные как второстепенные, и если кто-то попытается снять отметку с них как второстепенные, а они все еще меньше этого размера, появится предупреждающее сообщение, позволяющее пользователю узнать, в каком смысле они помечены как второстепенные. Когда он превышает определенный размер, он не может быть отменен как второстепенный, если у пользователя нет специальных разрешений на это (т. Е. Он является надежным редактором Википедии). Это всего лишь мое мнение, но после прочтения всего вышеперечисленного я почувствовал, что должен внести свой вклад.иметь все правки, меньшие определенного размера, помеченные как второстепенные, и если кто-то попытается снять отметку с них как второстепенные, а они все еще меньше этого размера, появится предупреждающее сообщение, позволяющее пользователю узнать, в каком смысле они помечены как второстепенные. Когда он превышает определенный размер, он не может быть отменен как второстепенный, если у пользователя нет специальных разрешений на это (т. Е. Он является надежным редактором Википедии). Это всего лишь мое мнение, но после прочтения всего вышеперечисленного я почувствовал, что должен внести свой вклад.Это всего лишь мое мнение, но после прочтения всего вышеперечисленного я почувствовал, что должен внести свой вклад.Это всего лишь мое мнение, но после прочтения всего вышеперечисленного я почувствовал, что должен внести свой вклад.Пылающий волк | Гордый Фурри и редактор Википедии ( обсуждение ) 01:08, 16 марта 2021 г. (UTC) [ ответ ]
    • Размер различия - ненадежный способ определить, что является второстепенным, а что нет. Перезапись всего абзаца не является второстепенной правкой, но если бы она использовала то же количество символов, она имела бы размер разницы в 0 байт. С другой стороны, добавление ссылки на архив к источникам может добавить 50-100 байт текста на каждый URI, но, поскольку это не вносит никаких изменений в прозу, было бы правомерно отметить это как незначительное изменение. Тридуульф ( разговор ) 01:23, 16 марта 2021 (UTC) [ ответ ]
  • Противодействовать предложенному варианту. Поддержка ограничения незначительного редактирования для редакторов с автоподтверждением / расширенным подтверждением. - Vulp здесь 04:56, 16 марта 2021 г. (UTC) [ ответ ]
  • Сильнейший противник Есть и другие решения нечестного использования «второстепенной» кнопки. Это, как предлагается, не должно выполняться. G en Q uest "scribble" 16:38, 16 марта 2021 (UTC) [ ответ ]
  • Боты поддержки , у ревертов есть очевидное место для мелких правок. Хотя опытные пользователи не все согласны с определением незначительного редактирования, они, по крайней мере, будут использовать его постоянно, что может быть полезно для просмотра правок конкретного пользователя. Однако они менее полезны при отслеживании последних изменений в списке наблюдения. Чтобы сделать их более полезными, я бы рекомендовал ограничить возможность включения мелких правок для пользователей WP: ECP, у которых, по крайней мере, было бы последовательное объяснение того, что является второстепенным / важным. Шушуга ( разговор ) 16:52, 16 марта 2021 (UTC) [ ответ ]
  • Против. Незначительные правки полезны. Не только для меня, чтобы использовать при исправлении опечаток или для того, чтобы помочь мне обойти мелкие правки знакомых мне редакторов, но и потому, что отмеченное "незначительное правка" плюс стандартная сводка редактирования, такая как "Исправленная опечатка", является явным красным флажком для проверки на вандализм. или другое разрушительное редактирование. -  Мубошгу  ( разговор ) 16:54, 16 марта 2021 (UTC) [ ответ ]
  • Против - при просмотре истории статьи может быть полезно увидеть, что редактирование было отмечено

как незначительные, например, изменение одной буквы для исправления опечатки. Это полезно, потому что помогает отличить незначительные правки от более серьезных изменений в статье. Ролло Август ( разговор ) 20:15, 20 марта 2021 (UTC) [ ответ ]

  • Против - может помешать дальнейшему редактированию ParallaxVision222 ( обсуждение ) 16:28, 22 марта 2021 г. (UTC) [ ответ ]

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

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

@ ProcrastinatingReader , можно ли решить вашу актуальную проблему, изменив настройки prefs по умолчанию, чтобы отображались незначительные правки? Whatamidoing (WMF) ( обсуждение ) 21:55, 15 февраля 2021 (UTC) [ ответ ]
У меня проблема в том, что эта функциональность не имеет смысла. Я не думаю, что когда-либо имеет смысл скрывать мелкие правки в списке наблюдения. Тем не менее, сам индикатор может быть полезен, но он по-прежнему является избыточным для итоговой суммы + счетчик байтов. Я думаю, что Suffusion of Yellow и комментарии The Earwig лаконично выражают мои опасения. Моя вторая проблема заключается в том, что отдельные администраторы думают, что блокировка даже одного редактора за использование им второстепенного индикатора (например, или блокирование отдельных пользователей ) уместно. Я думаю, что проблема возникает достаточно часто, поскольку у нее есть раздел на странице политики ( 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 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) [ ответ ]
    Хороший вопрос, Эспрессо-наркоман . Я откопал несколько примеров блокирования редакторов за пометку правок как незначительных. В большинстве случаев, конечно, есть и другие причины блоков: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12 ] ] [13] [14] [15] [16] . -  В  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) [ ответ ]
    Мы должны переименовать его в Honeytrap 😅 Shushugah ( разговор ) 11:08, 22 марта 2021 (UTC) [ ответ ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать на соответствующей странице обсуждения. Никаких дальнейших изменений в это обсуждение вносить не следует.

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

Это то, что меня как бы беспокоит, и я не уверен, что у меня есть хорошее решение, но подумал, что обсуждение может быть продуктивным. Иногда долгосрочные пользователи оказываются заблокированными, и со временем многие вещи, которые они создали, подлежат удалению. Уведомление кого-то, кто был заблокирован в течение многих лет, кажется непродуктивным и похожим на то, чтобы пнуть его, когда он упал. Я ни в коем случае не предполагаю, что эти номинации или уведомления делаются недобросовестно, во многих случаях уведомления в любом случае делаются автоматическими инструментами. И это могло быбыть там, где можно было бы сделать настройку. Я использую сценарий, который автоматически помещает строку вверху любой страницы пользователя или страницы обсуждения, сообщая мне, как долго пользователь был зарегистрирован, какие права у него есть, а также сообщит мне, если они заблокированы. Например, прямо сейчас на моей странице пользователя он отображается как контрольный пользователь, надзиратель и администратор, возраст 13 лет 7 месяцев, с 96 136 изменениями. Последний раз редактировалось 27 минут назад. Если эта функция совместима с Twinkle или другими подобными инструментами, они могут всплывать и спрашивать, уверен ли пользователь, что он хочет уведомить, что-то вроде <USER> заблокировано, а его последнее изменение было 342 дня назад, вы хотите продолжить? . Имеет ли это смысл и / или кажется разумным для кого-то еще, или это только мне? Библброкс ( разговор) 20:11, 9 марта 2021 (UTC) [ ответ ]

Меня беспокоит то же самое, и я думаю, что это разумное предложение. Есть также люди, которые официально покинули проект, поэтому в нем должны учитываться люди, которые не были заблокированы, но просто ушли. Акротерион (разговор) 20:16, 9 марта 2021 (UTC) [ ответ ]
( редактировать конфликт ) Мне кажется разумным. Я предпочитаю назначать страницы для удаления вручную, а не использовать Twinkle, и пропускаю уведомление о заблокированных на неопределенное время пользователях или пользователях, которые долгое время неактивны (я не согласен с тем, сколько времени). Хотя однажды меня лично атаковали на Meta за то, что я не уведомил заблокированного на неопределенное время пользователя ... * Pppery * это началось ... 20:19, 9 марта 2021 (UTC) [ ответ ]
  • Оставление тех же бесплатных уведомлений, что и на любой странице обсуждения незаблокированного пользователя, не является WP: GRAVEDANCING , а не пинанием их, когда они не работают . Ошибочно полагать, что эти уведомления обслуживают только этого пользователя. Было много случаев, когда уведомления на странице обсуждения заблокированного пользователя indef помогали мне найти старую дискуссию об удалении или выявить закономерность в их поведении. Такие шаблоны привели к дальнейшей очистке и разоблачению sockpuppets. Возможно, такие хлебные крошки не так важны для администраторов, которые, как я полагаю, могут видеть удаленные страницы и исправления. Как неадминистратор, я надеюсь, что никто не перестанет оставлять уведомления на страницах обсуждения заблокированных пользователей. - Ворлдбрюс ( разговор ) 23:13, 9 марта 2021 г. (UTC) [ ответ ]
  • Я согласен с тем, что сказал выше Worldbruce. Также удивительное количество высокопроизводительных редакторов были заблокированы, и они часто создавали важные страницы, шаблоны, изображения и т. Д., Где более широкий пул уведомлений может оказаться полезным. Более того, indef-block не всегда вечен, и они могут однажды вернуться, чтобы решить любые проблемы или наверстать упущенное, даже если они пропустили соответствующее обсуждение в то время. А если вас беспокоит какая-то страница, вы всегда можете ее отменить. Однако я также согласен с Beeblebrox в том, что люди должны хранить информацию в удобном месте, чтобы не уведомлять пользователей. В идеале люди все равно должны потратить лишние несколько секунд на просмотр вкладов, прежде чем выбрать соответствующий флажок в Twinkle, но это то, что есть. Я бы предположил, что это было бы относительно легко реализовать в Twinkle, если бы это не былоt уже - вы бы хотели поговорить с разработчиками Twinkle. -zzuuzz (разговор) 23:56, 9 марта 2021 (UTC) [ ответ ]
  • Сколько из этих скриптов уважают {{ nobots }} и может быть это что-то, о чем могут быть осведомлены независимые редакторы? Я понимаю вышеупомянутые причины о преимуществах разрешения этих уведомлений, но мне кажется, что это похоже на отказ от шаблонов для постоянных клиентов : это не неправильно или запрещено, а просто глухо. Мы должны заранее сообщить об этой опции и позволить текущим редакторам принимать собственные решения о том, следует ли использовать шаблоны с независимыми редакторами. Я бы отлично предотвратил это по умолчанию. - ГВП · · ро · дез 1:36, 10 марта 2021 (UTC) [ ответить ]
  • Проблема здесь в том, что продуктивные пользователи заблокированы. Например, я как раз просматривал историю нескольких статей и заметил, что Хуллабаллоо Вулфовиц внес полезный вклад. Но в настоящее время они заблокированы сроком на шесть месяцев - в высшей степени суровое и непродуктивное наказание. В таких случаях очевидной несправедливости я обычно помещаю страницу обсуждения этого пользователя в свой список наблюдения, чтобы я мог наблюдать за любыми такими уведомлениями и принимать соответствующие меры. На странице обсуждения HW есть более 300 наблюдателей, и уведомления предназначены для них, а также для основного пользователя. До сих пор в этом случае у нас был один из Герды"Драгоценные годовщины", которые напоминают нам о том, что этот блок является разрушительным. Итак, соответствующее действие в этом случае - удалить блок - OP должен сделать это. Эндрю 🐉 ( разговор ) 11:47, 10 марта 2021 (UTC) [ ответ ]
    • См. Обсуждение ANI, которое привело к блокировке, и особенно обратите внимание на обсуждение после него, где длина была объяснена и одобрена. Эндрю , возможно, вы захотите прочитать о WP: ADMINSHOPping . - ГВП · · ро · дез 20:38, 10 марта 2021 (UTC) [ ответить ]
      • Чрезмерно жесткая блокировка для довольно незначительных злоупотреблений. Эффект от блокировки хуже, чем то, к чему он обращался. В любом случае, для 6-месячного блока уведомления все же стоит включить в тему этого обсуждения. Грэм Бартлетт ( разговор ) 00:06, 11 марта 2021 (UTC) [ ответ ]
        • Блокировка за ... злоупотребление. исправил это для вас, Грэм . Возможно, вы захотите попробовать прочитать обсуждение, которое я связал, особенно ту часть, где я сказал, что даже люди, защищающие HW, указывают на образец невежливости, они просто пытаются извинить это различными способами. Если вам интересно больше, чем просто дешево стрелять в меня, и вы хотите бросить вызов ближнему, вы знаете, где находится AN. - ГВП · · ро · дез 00:53, 16 марта 2021 (UTC) [ ответить ]
  • Это то, с чем я боролся, мне не нравится восприятие могильных танцев, но, выдвигая статью для обсуждения, я иногда оставлял сообщение для заблокированных пользователей, задаваясь вопросом, может ли (надеяться) один из их бывших сотрудников следить за их TP и интерес или знание предмета. Кавалерист ( разговор ) 22:02, 10 марта 2021 года (UTC). [ ответ ]
  • Это интересное обсуждение. Меня не так беспокоит какая-либо кажущаяся неловкость или невежливость в оставлении такого уведомления на странице заблокированного пользователя, поскольку я заинтересован в его продуктивности. Как говорят люди, лучше оставить такое сообщение, чем вообще ничего, потому что тогда сообщение, по крайней мере, видно, но если у пользователя мало или нет наблюдателей за разговорами, или если пользователь не заблокирован, а просто неактивен. , то уведомление только первого редактора может оказаться непродуктивным. И даже если первый редактор все еще активен, он может быть не тем человеком, который больше всего заинтересован в статье. Некоторые первые редакторы вносят только первоначальное редактирование или два, а затем покидают статью, и она может быть добавлена ​​другими редакторами.Я думаю, что может быть полезно иметь дополнительные функции в автоматизированном инструменте для уведомления первого редактора И наиболее производительного редактора (возможно, с некоторыми добавленными пунктами, например, что самый продуктивный редактор должен быть разблокирован, и внести изменения в Википедию в в предыдущем месяце).SilkTork ( разговор ) 09:21, 12 марта 2021 (UTC) [ ответ ]
  • Что сказал Силкторк. Есть статьи, в которых один создает, но другой конкретизирует это и имеет более личный интерес к статье, поэтому рассылка уведомлений этим людям имеет смысл. Что касается уведомления кого-то, кто заблокирован indef, я, конечно же, не рассматриваю это как могилу, это просто обращение с ними, как с любым другим здесь, что технически мы должны делать, если они на самом деле не забанены. В чем-то он может быть далеко не идеальным, но это меньшее из двух возможных зол. Даже если indef заблокирован, получая уведомление, они могут, по крайней мере, знать его для удаления и попросить кого-нибудь изучить его (что не то же самое, что редактирование прокси), или наблюдатель страницы обсуждения может изучить это, поместив больше глаз на это. Не каждое решение идеально, но я думаю, что нынешняя система наименее несовершенна. Деннис Браун - 2 10:13, 12 марта 2021 (UTC) [ ответ ]
  • Чтобы быть ясным, единственное, что я даже думал предложить, - это попросить Twinkle или другие инструменты просто иметь возможность дважды проверить, хотите ли вы продолжить, если пользователь был заблокирован и неактивен, скажем, шесть месяцев или дольше. . Я не думаю, что нам нужно правило или что-то в этом роде. Примером может служить выступление пользователя: Ричард Артур Нортон (1958-) . Этот пользователь регистрируется один или два раза в год, удаляет около 20 уведомлений об удалении со своей страницы и снова молчит. Опять же, я не думаю, что кто-то делает это злонамеренно, это просто кажется бессмысленным. Библброкс ( разговор ) 06:17, 13 марта 2021 (UTC) [ ответ ]
    • Почему бы не пересмотреть многие из этих, возможно, несправедливых, неопределенных блоков? Эти пользователи могут подумать: «Теперь я перейду к Википедии. Разблокирован ли я? Нет. Есть ли у меня силы запросить разблокировку? Нет, он просто будет отклонен. Моя страница обсуждения огромна? Да. Полно уведомлений об удалении, и я даже не могу дать обоснование для их сохранения. У меня так много идей для перезапуска, но администраторы действуют так, как будто я муха, которую они прихлопнули. Это наводит меня на мысль, что мне нужно уйти от Википедии сейчас. Увидимся ... никогда! " 🐔  Chicdat   Bawk мне! 11:22, 20 марта 2021 (UTC) [ ответ ]
Страница обсуждения Альфреда Дрейфуса , 1895 г.
  • Меня это тоже беспокоит, когда я это вижу. Тем более, что незарегистрированный пользователь не может на самом деле участвовать в процессе удаления, это просто кажется излишне жестоким: « Эй, придурок, статью, над которой ты потратил кучу времени, разрывают ядерным оружием , подумал, что тебе может быть забавно наблюдать за тем, как люди дискутируют по этому поводу. это без возможности ответить ". Не хорошо! jp × g 18:43, 16 марта 2021 г. (UTC) [ ответ ]
  • Предпосылка здесь благонамеренная, и мы всегда могли бы использовать ее в большем количестве, но я чувствую, что это, возможно, было переоценено. Во-первых, если вы заблокированы, почему вы все еще авторизуетесь здесь? Люди делают это только для того, чтобы продолжать попытки редактировать? То есть видит ли аудитория даже те сообщения, которые, как вы опасаетесь, они увидят? Во-вторых, мы говорим о людях, которые были такими хорошими людьми, что их заблокировали, и такими хорошими статьями, что их нужно удалить. Думаю, я просто раздражаюсь, но мне трудно вызвать сочувствие. Я бы предпочел потратить время / силы / ресурсы на людей, которые нечлены. Наконец, удаление произойдет или нет независимо от уведомления; Разве не так же вероятно - а может быть, даже больше - то, что «приятно» - это дать людям знать, что происходит, вместо того, чтобы оставлять их в неведении? Мы видим много вопросов в службе поддержки от людей, которые задаются вопросом, куда, черт возьми, подевалась такая-то статья. Мэтт Дерес ( разговор ) 20:13, 26 марта 2021 (UTC) [ ответ ]

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

Следующее обсуждение представляет собой архивную запись запроса на комментарий . Пожалуйста, не изменяйте его. Никаких дальнейших изменений в это обсуждение вносить не следует. Краткое изложение сделанных выводов следует ниже.
По общему мнению, эти ссылки не рекомендуются на том основании, что они плохо обслуживают наших читателей, судя по небольшому количеству просмотров страниц. ( закрытие без прав администратора ) ( t · c ) buidhe 10:37, 23 марта 2021 (UTC) [ ответ ]



Я предлагаю официально отказаться от ссылки на Википедию: книги в шаблонах и статьях. Книги Википедии не работают уже много лет, но все еще включены в различные шаблоны (например, {{ Вселенная Звездных войн }}, {{ Меркурий (планета) }}, {{ Авраам Линкольн }}) и, возможно, в некоторые статьи - я помню, что видел некоторые в различных разделах «см. также». Кажется бесполезным и непродуктивным приводить читателей на страницу, где говорится, что рассматриваемая услуга недоступна, и указывает читателю на внешние (сторонние) источники; Я предполагаю, что большинство читателей сочтут это тупиком и не будут продолжать его развивать. Около двух лет назад {{ книги Википедии }} и соответствующая боковая панель были заблокированы, поэтому я не понимаю, почему мы должны противоречить этой практике, по-прежнему предоставляя бесполезные ссылки в шаблонах (и, возможно, в статьях). Aza24 ( разговор ) 06:48, 13 марта 2021 (UTC) [ ответ ]

Более подробная информация доступна в Википедии: Статус создателя книги Википедии .
Прошлое обсуждение самого шаблона - Википедия: Templates_for_discussion / Log / 2021_January_16 # Шаблон: Wikipedia_books
  • Поддержка . Я не до конца ознакомлен с историей Wikipedia Books, но это похоже на эксперимент, который мы пробовали, но он потерпел неудачу. Мы должны убирать за собой, что означает не продолжать связываться с ним после того, как он мертв. {{u | Sdkb }} обсуждение 05:04, 14 марта 2021 (UTC) [ ответ ]
  • Поддержка : как говорит Sdkb , давайте уберемся за собой. G en Q uest "scribble" 08:48, 14 марта 2021 (UTC) [ ответ ]
  • Поддержка Как отмечает Аза, это тупиковый конец провалившегося проекта, который не приносит пользы нашим читателям. Библброкс ( разговор ) 20:45, 14 марта 2021 (UTC) [ ответ ]
  • Поддержка Не спорное предложение и понятно. Мне нравится принцип «убирать за собой». doktorb слова дела 21:37, 14 марта 2021 (UTC) [ ответ ]
  • Поддержите Вау, я даже не слышал об этом (что говорит о многом). ~ HAL 333 00:18, 15 марта 2021 (UTC) [ ответ ]
  • Поддержка Неудачный эксперимент, больше не рекомендуется - Vulp здесь, 04:52, 16 марта 2021 г. (UTC) [ ответ ]
  • Поддержка У меня множество мнений о книгах, и я считаю, что с ними действительно сложно обращаться. Я думаю, что они имеют немаловажную ценность, если они когда-нибудь снова начнут работать должным образом, и даже сейчас есть горстка людей, которые находят в них ценность. В то же время пространство имен заполнено большим количеством ерунды, система категорий в большинстве случаев является лучшим инструментом для чтения на определенную тему, а ссылки на страницы с большими предупреждающими баннерами выглядят не очень хорошо. Ранее я предлагал технический способ скрыть эти ссылки, не удаляя их, чтобы мы могли вернуть их, если проблемы будут исправлены в Википедии: Village pump (технический) / Archive 183 # Ссылки на книги Mainspaceно, честно говоря, я абсолютно нормально могу просто удалить их. Мое решение, хотя и работоспособное, определенно вызовет некоторую путаницу для нетехнических редакторов и, возможно, приведет к странному форматированию в некоторых местах, если кто-то коснется пробелов вокруг них. Прямое удаление также будет иметь преимущество в виде сокращения ссылок, если они когда-либо понадобятся повторно, и теоретически должно ссылаться только на книги приличного качества. - Trialpears ( обсуждение ) 16:19, 16 марта 2021 г. (UTC) [ ответ ]
    @ Trialpears : Проблема с системой категорий в том, что ее списки по существу неструктурированы и могут быть очень большими; Книги позволяют разумный дизайн. Кроме того, ссылки на книги в настоящее время запрещены, как вы и предлагали. - Ура, Steelpillow ( Обсуждение ) 17:35, 16 марта 2021 г. (UTC) [ ответ ]
  • Сильный объект . «Рассматриваемая услуга» OP, как описано в Wikipedia: Books , является расширением Collection (также известным как Book Creator). Очень много здесь и работает. И у нас есть пространство имен Books: с множеством книг в нем. Мы заслуженно отказались от нашего бесполезного внутреннего рендерера, но идея о том, что в настоящее время это «рассматриваемая услуга», - нонсенс. Как указано в Википедии: Книги и в других местах, « В результате ожидаемых будущих решений, включения шаблонов не должны удаляться из статей ». Сначала нам нужно достичь консенсуса, чтобы отказаться от любых мыслей о таких будущих услугах, таких как принятие длинных -предполагаемый сборщик , а также поддерживающих внешних сервисов, таких какMediaWiki2LaTex на WMFlabs. Тогда нам придется согласиться отказаться от пространства имен Book :. Давайте сначала обсудим это, а не будем их ломать. - Ура, Steelpillow ( Обсуждение ) 17:35, 16 марта 2021 г. (UTC) [ ответ ]
  • Поддержка на WP: NOTPAPER . Если читатели хотят использовать внешний сервис для печати сборников статей, они могут это сделать, но у нас нет необходимости поддерживать бессрочную поддержку сервисов, не связанных с нашей целью создания вики. Как говорит sdkb, мы пробовали книги, но ничего не вышло. Книги: «Звездные войны» и « Книга: Авраам Линкольн» в среднем по 3 просмотра в день. Вчера у « Звездных войн» было больше просмотров страниц, чем у книги за весь год. Отметьте пространство имен как историческое, удалите ссылки на него, обращенные к читателю, и позвольте ему собирать пыль (я против удаления пространства имен или страниц на метр: Сохраняйте историю ). Нам не нужно тратить время на поддержку функции, которую никто не использует. - Вуг · а · по · дес19:27, 16 марта 2021 (UTC) [ ответить ]
  • Поддержка Иногда я видел ссылки внизу статей и задавался вопросом, какую дополнительную информацию они предлагают. Кажется, что в некоторых случаях они скорее являются развилкой устаревшего контента. Jtbobwaysf ( разговор ) 05:59, 19 марта 2021 (UTC) [ ответ ]
  • Поддержка По сути, это внешняя ссылка. Чтение рекомендаций здесь Википедия: Внешние ссылки # Указание ссылки означает, что Викиучебники больше не соответствуют большинству (если не всем) из них. MarnetteD | Обсуждение 06:46, 19 марта 2021 (UTC) [ ответ ]
  • Не поддерживайте больше ссылок на мертвые пространства имен. 🐔  Chicdat   Bawk мне! 11:10, 20 марта 2021 (UTC) [ ответ ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать на соответствующей странице обсуждения. Никаких дальнейших изменений в это обсуждение вносить не следует.

RfC: сделать Template: Authority Control более удобным для чтения[ редактировать ]

Следующее обсуждение представляет собой архивную запись запроса на комментарий . Пожалуйста, не изменяйте его. Никаких дальнейших изменений в это обсуждение вносить не следует. Краткое изложение сделанных выводов следует ниже.
Существует сильная поддержка переделки шаблона авторитетного контроля, в котором используются понятные человеку имена ресурсов, чтобы они были узнаваемы для большего числа редакторов. Существует общая поддержка того, что предложение Фрама предпочтительнее текущей версии, но нет единого мнения о точной форме, которую может принять улучшенная версия. Альтернативное предложение, которое вызвало некоторую поддержку, - отказаться от всего шаблона или заменить его ссылкой на викиданные, что можно было бы обсудить на другом RFC, чтобы оценить, есть ли у этого предложения консенсус. ( закрытие без прав администратора ) ( t · c ) buidhe 01:24, 1 апреля 2021 (UTC) [ ответ ]


Следует ли переписать Template: Authority control, чтобы сделать его более удобным для чтения? Фрам ( разговор ) 10:12, 18 марта 2021 (UTC) [ ответ ]

Фон управления властью[ редактировать ]

Authority Control - это шаблон, который к настоящему времени включен в 1,7 миллиона статей enwiki: он показывает в виде ссылок ряд «уникальных идентификаторов» от организаций по всему миру. Все данные хранятся в Викиданных, здесь ничего не хранится. Предлагаемые RFC ничего не меняют в отношении того, как Викиданные с ними работают : речь идет исключительно о том, как мы хотим показать их на Enwiki.

В примере, взятом из Kenzabur Ōe , текущий результат шаблона Authority Control выглядит следующим образом;

Предложение по контролю полномочий[ редактировать ]

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

Выше представлен очень простой макет того, как это могло бы выглядеть. Это пример , а не обязательно конечный результат. Для других общих групп идентификаторов (например, веб-сайтов, посвященных искусству) можно добавить еще одну строку. Фрам ( разговор ) 10:14, 18 марта 2021 (UTC) [ ответ ]

Я хотел бы попросить людей не слишком сосредотачиваться на внешнем виде предложения: RfC касается принципов, фактический новый внешний вид может быть определен людьми с большими знаниями и талантом в области дизайна пользовательского опыта. Фрам ( разговор ) 10:16, 18 марта 2021 (UTC) [ ответ ]

  • Возможно, мне чего-то не хватает, но основная ссылка «Интегрированный авторитетный файл» ведет на немецкий веб-сайт Deutsche Nationalbibliothek, которого я ожидал в разделе «Национальные библиотеки»? Помимо этой проблемы, это действительно хорошее и разумное предложение. Мартин Шеффилдский ( разговор ) 10:25, 18 марта 2021 (UTC) [ ответ ]
    Да, я не знал, куда его положить. Насколько мне известно, это международный стандарт, но поддерживается Немецкой национальной библиотекой, а текст на странице написан на немецком языке. Эти детали (ну, это важные) нужно будет решить, если будет принят общий принцип предложения. Фрам ( разговор ) 10:43, 18 марта 2021 (UTC) [ ответ ]
  • Комментарий : Понятен ли термин «авторитетный контроль»? Мало кто из читателей, кроме библиотекарей, поймет, что это означает, и это звучит ... авторитарно? Стоит ли говорить об «уникальных идентификаторах» для ясности? Пэм Д 11:29, 18 марта 2021 г. (UTC) [ ответ ]
    Нет, не совсем. Это термин данных / библиотеки, а не термин читателя. Только смерть заканчивает долг ( разговор ) 11:41, 18 марта 2021 (UTC) [ ответ ]
    Это было бы лучше, но я думаю, это отдельная тема. Фрам ( разговор ) 11:54, 18 марта 2021 (UTC) [ ответ ]
    Я не совсем возражаю против этого термина, так как он имеет вики-ссылки, но в любом случае это не главное. Большинство случайных читателей, вероятно, даже не заходят так далеко на странице. ɱ (обсуждение) 13:58, 20 марта 2021 (UTC) [ ответ ]
  • Против удаления ссылок WP - я почти уверен, что это обсуждалось раньше, но и раньше это не останавливало Fram . Ссылки на, например, LCCN информируют пользователя об учреждении, предоставляющем AC, а ссылка (-ы) n81033861 ID предоставляют информацию. Оба нужны.    ~  Том.Рединг ( обсуждение ⋅ dgaf )   11:39, 18 марта 2021 (UTC) [ ответ ]
    • Почему вы должны требовать, чтобы читатель нажимал на непонятные аббревиатуры, чтобы получить информацию о том, кто выдал строку идентификатора, если вы можете включить ее гораздо более четко в шаблон, как указано выше? Большинство читателей статьи Oë вообще не поймут, что такое «NLG: 71274». В новом шаблоне они напрямую видят, что это ссылка на Национальную библиотеку Греции. Нужна ли им действительная ссылка на Национальную библиотеку Греции?из статьи Oe? Сомневаюсь, это не актуальная информация для этой статьи. Есть ли у них еще ссылка на страницу NLG ID? Да, это все еще включено. Но теперь, по крайней мере, они будут иметь лучшее представление о том, что им предлагается, без необходимости щелкать любую ссылку. Две ваши причины - это «информирование читателя об учреждении, предоставляющем грант», что в предлагаемой версии выполняется напрямую, а не требует щелчка: и ссылки идентификатора для предоставления информации, которая в предлагаемой версии также все еще существует, поскольку она все еще ссылка, которая по-прежнему ведет к той же информации. О, и не стесняйтесь ссылаться на предыдущие обсуждения, возможно, без личных комментариев. Фрам ( разговор ) 11:53, 18 марта 2021 (UTC) [ ответ ]
      • Вы подняли это здесь, на этой помпе (предложение) Village в июне 2018 года. Найдите «Option 2Names», что породило «Option 2Wikidata», «Option 2pencil» и «Option 2edit». Мне тоже сначала и другим понравились эти варианты, прежде чем я реализовал свое утверждение выше. Ничего личного, только факты о вашей личности. К сожалению, они выглядят как WP: Я этого не слышал и / или замедленное воспроизведение WP: FORUMSHOPPING .    ~  Том.Рединг ( обсуждение ⋅ dgaf )   15:43, 18 марта 2021 (UTC) [ ответ ]
        • О, это обсуждение крушения поезда, заканчивающееся отсутствием консенсуса, но с большой поддержкой того типа изменений, которые я предлагаю здесь? Да, такое обсуждение не мешает мне принести новый RFC два года спустя. Мне нравится «Ничего личного, только факты о твоей личности». хотя. Фрам ( разговор ) 16:22, 18 марта 2021 (UTC) [ ответ ]
    • Ссылки LCCN и т. Д. Служат дополнительной цели, уведомляя редактора, какой параметр они могут использовать ( |LCCN=), чтобы либо переопределить идентификатор WD, либо полностью подавить идентификатор. При предложенной схеме это определить намного сложнее. Такого отсутствия предвидения можно было бы избежать, если бы на странице обсуждения проводилось какое-либо обсуждение, которое вместо этого привело бы к очень плохому RfC.    ~  Tom.Reding ( talk ⋅ dgaf )   00:42, 19 марта 2021 (UTC) [ ответ ]
      • Несмотря на то, что шаблон использовался в 1,7 миллиона статей, возможность подавления ссылок использовалась на 43 страницах до того, как я недавно создал шаблон ACArt. Такая редко используемая возможность (которая в любом случае останется доступной, но может, если RfC будет успешной, потребуется лучшая документация) вряд ли оправдывает то, что шаблон намного труднее понять (и, следовательно, с меньшей вероятностью будет использоваться) для наших читателей. Это не «недальновидность», это правильное расставление приоритетов. Фрам ( разговор ) 08:23, 19 марта 2021 (UTC) [ ответ ]
        • Вы игнорируете ~ 2400 страниц, используя Категория: Страницы, используя авторитетный контроль с параметрами  (1,277). Тем не менее, конечно.    ~  Том.Рединг ( обсуждение ⋅ dgaf )   10:18, 19 марта 2021 (UTC) [ ответ ]
          • Для начала, сотни из них кажутся переадресациями, для которых не должно быть шаблонов авторитетного контроля. Но давайте вместо этого посмотрим на некоторые актуальные статьи. Первый, который я проверил наугад, Anthony St. John Baker , имеет тот же идентификатор в параметре, что и в Викиданных. Сиддхарт Басрур , добавленный тем же редактором на Викиданные, а через минуту на enwiki, так что это тоже не обязательно. И в любом случае возможность не исключается, в тех немногих случаях, когда она необходима, им просто придется немного усерднее проверить, чтобы сделать это правильно. Фрам ( разговор ) 10:43, 19 марта 2021 (UTC) [ ответ ]
            • По крайней мере, мы согласны с тем, что это предложение ограничит функциональность.
              Кроме того, 353 редиректа, для которых AC поощряется согласно Википедии: Контроль полномочий « Если необходимо, создайте новый редирект для переноса шаблона». Что касается RfC, вы ужасно дезинформированы.    ~ Том.Рединг ( обсуждениеdgaf )   11:37, 19 марта 2021 (UTC) [ ответ ] 
              Может, пора перестать атаковать Фрама («IDHT», «FORUMSHOPPING», «потрясающе дезинформированный», «просто факты о вашей личности» и другие)? Прочтите комнату: консенсус с вами не согласен. ProcrastinatingReader ( обсуждение ) 12:02, 19 марта 2021 (UTC) [ ответ ]
              Все факты актуальны для обсуждения.
              " Прочитать комнату "? Это не голосование ; это основано на заслугах, которых нет, кроме как «выглядит красиво». Представьте версию, в которой хранятся ссылки WP, затем мы можем перейти к обсуждению того, насколько выше станет шаблон, но это лучшая отправная точка, чем эта.    ~ Том.Рединг ( обсуждениеdgaf )   12:39, 19 марта 2021 (UTC) [ ответ ] 
              Если все, что вы видите в предложении, это «выглядит красиво», то я думаю, что мы закончили обсуждение вещей. Использование этого шаблона для переадресации , которую никто никогда не увидит и которая не служит практической цели в enwiki, вряд ли является причиной для того, чтобы сохранить шаблон как можно более неинформативным и непрозрачным. Фрам ( разговор ) 13:13, 19 марта 2021 (UTC) [ ответ ]
  • Поддержка улучшений - Фрам прав. Странные аббревиатуры, которые ни один читатель не ожидает знать , совершенно бесполезны. Вы можете навести на них курсор, чтобы увидеть, что они означают, поскольку они ссылаются на соответствующую статью, но читателям не нужно делать это, чтобы понять ее смысл. Представление шаблона в настоящее время бесполезно, и макет Фрама выше - это шаг вперед. Тем не менее, я думаю, с этим шаблоном можно сделать больше. Хорошая презентация «Национальных библиотек», в остальном все еще сомнительно imo. ProcrastinatingReader ( обсуждение ) 15:19, 18 марта 2021 (UTC) [ ответ ]
    • Когда я нахожу на них курсор, я получаю «Bibsys (идентификатор)», «BNF (идентификатор)», «CiNii (идентификатор)» и так далее. Не очень полезно. Фрам ( разговор ) 15:10, 19 марта 2021 (UTC) [ ответ ]
      Когда я нахожу на них курсор, я получаю «BIBSYS - это административное агентство, созданное и организованное Министерством образования и исследований Норвегии. Оно обеспечивает обмен, хранение и поиск данных, относящихся к исследованиям, преподаванию и обучению - исторически метаданные, связанные с библиотечные ресурсы ". и другие аналогичные превью статей. Я думаю, это зависит от того, включен ли у вас предварительный просмотр страниц (Настройки -> Внешний вид -> Включить предварительный просмотр страниц) или всплывающие окна навигации (Настройки -> Гаджеты -> Навигация). - rchard2scout ( обсуждение ) 09:15, 22 марта 2021 (UTC) [ ответ ]
  • Как было сказано в ходе обсуждения VPI , я поддерживаю общее изменение. У меня есть некоторые возражения по поводу предлагаемого внешнего вида, но, как я и просил, не в этом фокус. - Изно ( разговор ) 15:35, 18 марта 2021 г. (UTC) [ ответ ]
  • Поддержите , в общем, сделав его более читабельным. В настоящее время это просто аббревиатуры, которые никто не знает, с цифрами, которые ничего не значат. Я преувеличиваю, но если обычный читатель захочет получить более энциклопедическую «структурированную» информацию, его будет легко найти. Я понимаю, что аббревиатуры ссылаются на статьи о властях, но это второстепенная цель, которую нужно достичь. -  HELL KNOWZ    ▎ TALK 17:00, 18 марта 2021 (UTC) [ ответ ] 
  • Поддержка , чтобы сделать дисплей более удобным для человека. Есть возможности для дальнейшего улучшения, но предлагаемый дисплей значительно превосходит текущий пример выше. Schazjmd  (разговор) 17:02, 18 марта 2021 (UTC) [ ответ ]
  • Поддержите общую идею сделать шаблон более доступным для читателей. Разбивка на категории - хороший шаг. Я менее уверен в удалении идентификаторов и связанных сокращений: первое полезно, если читатель хочет скопировать и вставить его, второе - для понимания того, что они на самом деле представляют. Но это детали, которые можно прорабатывать постепенно. Я также согласен с приведенным ниже мнением о том, что теперь Викиданные - зрелый проект, этот шаблон (который на несколько лет старше) теперь в значительной степени избыточен. Возможно, стоит пойти дальше и запретить ссылки на авторитетные источники, которые не предоставляют никакой полезной дополнительной информации, по сути превратив шаблон в автоматизированный компонент раздела внешних ссылок. -  Джо  ( разговор ) 17:12, 18 марта 2021 г. (UTC) [ответ ]
  • Поддержку конечно, ежу понятно. Может быть, добавить тег TfD, чтобы больше людей увидели это обсуждение? Элли ( обсуждение | вклад ) 17:15, 18 марта 2021 (UTC) [ ответ ]
    • TfD - это не форум для RFC. Я размещаю его на WP: CENT .力(power ~ enwiki, π , ν ) 17:18, 18 марта 2021 (UTC) [ ответ ]
      • Я не предлагаю перечислять его в TfD как таковом, но поскольку шаблон находится в стадии обсуждения, указывающий, что в шаблоне был бы полезен, и TfD использовался для этого раньше (например, для определения того, должны ли мы свернуть {{ WikiProject banner shell }}. Элли ( обсуждение | вклад ) 18:06, 18 марта 2021 (UTC) [ ответ ]
        • Я не думаю, что нужна реклама этого RFC в 1 миллионе статей. Я не думаю, что «See TfM», появляющееся с каждым {{ tl }}, тоже необходимо ...力(power ~ enwiki, π , ν ) 18:09, 18 марта 2021 (UTC) [ ответ ]
  • Поддержка в самом общем смысле, поскольку я считаю, что шаблон можно улучшить. Однако я сомневаюсь в некоторых конкретных предлагаемых изменениях. Преобразование только во внешние ссылки без вики-ссылок или чисел отлично подходит для элемента, подобного приведенному выше примеру, с множеством идентификаторов, но может не подходить для элементов с меньшим количеством идентификаторов. Добавление разделов делает шаблон длиннее и с большей вероятностью будет перепутан с навигационным блоком. {{u | Sdkb }} обсуждение 17:37, 18 марта 2021 (UTC) [ ответ ]
  • Против. Хотя шаблон определенно можно было бы улучшить, я не верю, что это сделает Фрам. Этот RfC был начат без какого-либо предыдущего обсуждения, которое я видел на Template talk: Authority control , что было бы логичным местом встречи. Fram назначил шаблон для удаления , провел кампанию за удаление из него свойств (например, Musicbrainz ) и совсем недавно создал {{ ACArt }} для систематического удаления из него содержимого (в настоящее время он подлежит удалению ). Они, как правило, враждебно относятся к Викиданным и стремятся сократить использование Викиданных здесь. Кажется, что RfC - это троянский конь, который продолжает это делать. Спасибо. Майк Пил ( разговор) 17:40, 18 марта 2021 (UTC) [ ответ ]
    Это не веская причина возражать. В предложении не сказано, кто будет его реализовывать, и, предположительно, сама реализация будет предметом дальнейших обсуждений и / или проверки (+ AGF и т. Д.). Идея, лежащая в основе предложения, звучит (как вы сказали) и является предметом обсуждения здесь. Фрам оставил ссылку на этот RfC во время разговора о шаблоне, когда RfC был написан ( местный консенсус не может переопределить мнение сообщества по этому шаблону, который присутствует в 1,75 миллиона статей). ProcrastinatingReader ( обсуждение ) 17:53, 18 марта 2021 (UTC) [ ответ ]
    Если Fram не собирается его внедрять, им следовало бы найти кого-то, кто мог бы это сделать, прежде чем начинать обсуждение здесь (например, обсудить это на странице обсуждения шаблона, а не просто разместить ссылку на это обсуждение). Я сказал, что его можно улучшить, что обычно верно для большинства шаблонов, но не обязательно так (некоторые лишние пробелы облегчат чтение). Спасибо. Майк Пил ( разговор ) 17:59, 18 марта 2021 (UTC) [ ответ ]
    Это не похоже на особо сложное изменение LUA.力(power ~ enwiki, π , ν ) 18:06, 18 марта 2021 (UTC) [ ответ ]
    Это возражение безосновательно. Я тоже не согласен с решением Fram создать и добавить искусство AC, не добиваясь консенсуса сообщества (и, как таковой, поддержал удаление в TFD), но это предложение является явным возвратом Fram для правильного прохождения системы; стремление к консенсусу сообщества по поводу того, что (очевидно - по количеству поддержки) является разумным предложением. Также стоит напомнить всем, что это предложение не меняет количество показываемых ссылок, что в первую очередь послужило причиной спора на TFD AC art. Я бы призвал Майка к AGF . Aza24 ( разговор ) 08:31, 19 марта 2021 (UTC) [ ответ ]
    @ Aza24 : Я много раз общался с Fram по вопросам, связанным с Викиданными. Если предположить, что добросовестность в отношении них давно устарела, я поддерживаю здесь свою оппозицию. Они не тот человек, чтобы делать это. Спасибо. Майк Пил ( разговор ) 09:31, 19 марта 2021 (UTC) [ ответ ]
    Чувак, я надеюсь, ты никогда не предложишь RFC. Levivich  харасс / гончая 17:22, 20 марта 2021 (UTC) [ ответить ]
    @ Levivich : Я предлагаю их регулярно, но сначала я провожу предварительную работу (включая обсуждение, по крайней мере, с некоторыми людьми), чтобы ее можно было реализовать, если она будет принята. Спасибо. Майк Пил ( разговор ) 20:17, 20 марта 2021 (UTC) [ ответ ]
  • Поддержка в целом улучшения шаблона, хотя я не совсем уверен, как это будет выглядеть, я доверяю нашим технически подкованным редакторам. Я почему-то сомневаюсь, что Фрам пытается тайно атаковать викиданные или что-то в этом роде, предлагая это на очень заметной странице, безусловно, гораздо более заметной, чем разговоры о авторитетном контроле. Eddie891 Talk Work 17:58, 18 марта 2021 (UTC) [ ответ ]
  • ( редактировать конфликт ) Сильная поддержка. Они непостижимы для читателей - вы знаете, людей, которым Википедия призвана служить - в их нынешнем состоянии. Честно говоря, я тоже не ожидаю, что они превратятся в самую популярную часть проекта после этого, но они были бы намного лучше, чем «активно бесполезные». Ватицидальный пророк 18:00, 18 марта 2021 г. (UTC) [ ответ ]
  • Поддержка Там могут быть пользователи , которые нуждаются в идентификационные номера, но это определенное улучшение. SportingFlyer T · C 18:51, 18 марта 2021 г. (UTC) [ ответ ]
  • Поддержка Не нужны вики-ссылки на идентификаторы для каждого экземпляра шаблона. Для этого предназначена общая справочная ссылка. Точно так же новая версия более наглядна в отношении идентификаторов и не похожа на двоичный дамп абстрактных кодов. - Green C 20:49, 18 марта 2021 г. (UTC) [ ответ ]
  • Поддерживайте все, что облегчает понимание этого бизнеса читателями, иначе зачем мы вообще этим занимаемся? Библброкс ( разговор ) 23:54, 18 марта 2021 (UTC) [ ответ ]
  • Поддержите предложение здравого смысла, его гораздо легче понять, чем существующий метод. ThePlatypusofDoom (разговор) 01:20, 19 марта 2021 (UTC) [ ответ ]
  • Поддержка Удаление ссылки на идентификаторы Статья в Википедии - это компромисс, на который я более чем готов пойти, чтобы получить более понятный шаблон, в котором вам не нужно знать непонятные сокращения и смотреть на бессмысленные идентификаторы при использовании. Явное улучшение для читателей. - Trialpears ( обсуждение ) 10:14, 19 марта 2021 г. (UTC) [ ответ ]
  • Не уверен - я думаю, что поддерживаю основной вопрос вверху - что он мог бы быть более удобным для пользователя - но относительно фактического примера я не так уверен ... и это заставляет меня сомневаться, есть ли простой способ сделать он более удобен в использовании без значительного увеличения занимаемого пространства.
    Например, хотя раздел для библиотек кажется полезным, почему прямая ссылка на «SUDOC (Франция)» более полезна для читателя, чем вики-ссылка на то, что это есть, даже до ссылки на идентификатор? Я согласен с тем, что отображение самих идентификаторов, вероятно, не добавляет такой большой ценности, но кажется полезным иметь и вики-ссылку, и внешнюю ссылку (в этом случае почему бы и нет?связать идентификатор, а не что-то произвольное, например "внешний" или "ссылка"). -Рододендриты говорят\\ 14:54, 19 марта 2021 (UTC) [ ответ ]
    • Идентификатор SUDOC используется на 235000 страницах , но Sudoc получает только 12 просмотров страниц в день (неясно, сколько из них через текущий шаблон авторитетного контроля, а сколько по-другому). Предлагаемая версия (которая может быть улучшена, и «другой» раздел может быть одной из возможностей для этого) сразу же указывает нашим читателям, откуда берется информация: возможно, было бы лучше указать, на каком языке связана страница, но основы те же: если вы заинтересованы в норвежском государственном контроле над e, непременно нажмите на Bibsys: но вам не нужно сначала посещать нашу страницу Bibsys, чтобы знать об этом. Фрам ( разговор ) 15:08, 19 марта 2021 (UTC) [ ответ ]
      • Но это не объясняет, почему прямая ссылка, которая просто добавляет «Франция» (или даже «французский»), более удобна для пользователя, чем вики-ссылка на этот ресурс в дополнение к прямой ссылке. Похоже, что удаление вики-ссылок - основная часть этого предложения. Что меня беспокоит, так это то, что вики-ссылки кажутся весьма полезными, и что их сохранение иразбиение шаблона на разделы и / или объяснение того, что они собой представляют, может увеличить объем занимаемого пространства до некоторой степени, которую некоторые сочтут неприемлемой. Вот еще одна идея (в которой я не совсем уверен, но пока мы немного наплевать ...): иметь раздел для неанглоязычных источников и свернуть его по умолчанию? Очевидно, что мы затрагиваем темы за пределами англоязычного мира, поэтому их сохранение было бы важным, но это правда, что подавляющее большинство пользователей англоязычной Википедии не будут искать неанглоязычные ресурсы. -Рододендриты говорят\\ 15:22, 19 марта 2021 г. (UTC) [ ответ ]
  • Поддержка каждого предложения. ~ ToBeFree ( обсуждение ) 13:53, 20 марта 2021 (UTC) [ ответ ]
  • Поддержка изменений, если реализация тщательно обсуждается. ɱ (обсуждение) 14:04, 20 марта 2021 (UTC) [ ответ ]
  • Смешанный - (так что мой первый выбор был бы перенести весь процесс органа управления к викиданному все . Мы бы здесь на WP будет небольшим ненавязчивым окном , указывая редактор WD) ... Однако, если будут буду иметь орган управляйте ссылками здесь на статьи WP, я согласен с Фрамом, что нам нужно сделать их более понятными для среднего читателя. Необъяснимые сокращения и строки идентификаторов бесполезны. Так что более обширный шаблон получает мою нерешительную поддержку. Blueboar ( разговор ) 16:34, 20 марта 2021 (UTC) [ ответ ]
  • Альтернативное предложение , такое как User: Blueboar , я бы предпочел, чтобы Викиданные обрабатывали это напрямую, а Authority Control был шаблоном по умолчанию, а не что-то, что люди добавляли вручную. Тем не менее, с текущим шаблоном я бы сохранил / использовал ссылки вики, но улучшил читаемость, добавив разделы (Национальные библиотеки и т. Д.) И более описательные имена. Это станет более толстым шаблоном, и это стоит проверить. Мы можем измерить его эффективность, отслеживая количество просмотров вики-ссылок до и после. Необязательно, чтобы он был полезен для всех, но для тех немногих, кому он полезен, стоит попробовать поэкспериментировать! Шушуга ( разговор ) 19:26, 20 марта 2021 (UTC) [ ответ ]
  • Поддержка ; удаление чисел без понятного человеку значения улучшает отношение сигнал / шум. Я также поддержал бы пойти дальше и отображать ссылки только в Викиданных; Несмотря на библиотекарей и архивистов, эти ссылки представляют интерес только для таких специалистов. Ссылки в целом не помогают читателям, не соответствуют стандартам полезности, чрезмерной длины и т. Д., Которые мы требовали бы от внешних ссылок в любом другом контексте, и не заслуживают общего включения в более миллиона статей. Adumbrativus ( разговор ) 22:29, 20 марта 2021 (UTC) [ ответ ]
  • Альтернатива / поддержка : я согласен с общей сутью этого, включая лучшую компоновку и использование более простого английского языка. Тем не менее, я согласен с Blueboar, что более непосредственное взаимодействие с Викиданными имело бы смысл, и с Tom.Reding, что вики-ссылки важны (они позволяют читателю узнать, что это за базы данных и другие источники и что RS говорит о них, т.е. почему они должны заботиться / доверять тому, на что они собираются щелкнуть внешнюю ссылку.  -  SMcCandlish ☏ ¢  😼  21:11, 21 марта 2021 г. (UTC) [ ответ ]
  • Поддержите предложение в том виде, в каком оно написано, но ... Я более склонен полностью отказаться от шаблона, как указано ниже. Я всегда с осторожностью отношусь ко всему, что лишает редакторов enwiki контроля над тем, что появляется в статье enwiki (учитывая менее предпочтительный вариант ручного переопределения параметров шаблона), более подходящей была бы простая ссылка на Викиданные. Кавалерист ( разговор ) 22:17, 21 марта 2021 года (UTC). [ ответ ]
  • Поддержите общий принцип. Набор случайных чисел и букв мало что значит для большинства читателей, поэтому я думаю, что добавление контекста поможет. Я также могу использовать WikiData, если у нас все еще есть шаблон, по которому читатели могут легко щелкнуть. - ГВП · · ро · дез 22:20, 21 марта 2021 (UTC) [ ответить ]
  • Поддержите подобное изменение. Я думаю, что с точки зрения читателя текущий блок данных выглядит как нечто актуальное только для компьютеров, что-то внутреннее для Википедии, что не актуально для меня. С этим изменением, я думаю, читатели с большей вероятностью будут переходить к библиотекам и т. Д. Для получения дополнительной информации. Ссылки на наши собственные статьи об этих системах (все (identifier)ссылки), я думаю, должны быть добавлены в Help: Authority control . Для заинтересованных читателей это будет всего на один клик больше, и они не будут загромождать каждую статью. - rchard2scout ( обсуждение ) 09:15, 22 марта 2021 (UTC) [ ответ ]
  • Поддержка Мне было сегодня несколько лет, когда я действительно понял ... смутно ... что такое авторитетный контроль. Если мне потребовались годы, чтобы понять это, то это практически бессмысленно для новичков или читателей. На наших страницах не должно быть загадочной болтовни, все должно быть явно полезно для читателя. CaptainEek редактирует Ho Cap'n! ⚓ 22:01, 22 марта 2021 г. (UTC) [ ответ ]
  • Поддержите концепцию или сделайте ее более понятной. Если бы он был свернут по умолчанию, он занимал бы меньше места и был бы больше удален от большинства читателей, которым было бы наплевать, имея всю строку заголовка, чтобы объяснить, что это такое, тем, кто мог бы ее использовать: MB 03:45, 23 марта 2021 г. (UTC) [ ответ ]
  • Сильная поддержкавсе предлагаемые изменения: энциклопедия обслуживает читателей, а не редакторов или ботов. Шаблон очень неудобен для пользователя. Если это делает информацию вдвое доступнее, то стоит уменьшить ее вдвое. Кто-то, ищущий идентификаторы, может найти его, наведя курсор на URL-адрес, посетив URL-адрес или посетив Викиданные. Fram приводит веские аргументы в пользу низкого количества просмотров страниц, что означает, что никто не нажимает на эти вики-ссылки для поиска идентификаторов, которые предположительно полезны для читателя (насколько я могу судить, это, как правило, правда, а не только один приведенный пример), так что это не так. потеря для их удаления. Даже если все остальное не поможет, я надеюсь, что реорганизация в разделы по происхождению идентификатора, а не по текущему алфавиту, будет реализована, поскольку я не думаю, что противники выступают против конкретно этой части предложения.- Билорв( разговор ) 00:47, 24 марта 2021 (UTC) [ ответ ]
  • Поддержка Я симпатизирую тем, кто хочет ссылаться на статьи Википедии о различных базах данных, но эта функция не стоит унаследованной путаницы, связанной с предоставлением читателям большого набора незнакомых сокращений, это намного яснее. Aza24 ( разговор ) 02:06, 24 марта 2021 (UTC) [ ответ ]
  • Поддержка того, чтобы сделать шаблон более читабельным. Специфика может быть проработана позже, но даже если будет принят точный предложенный шаблон, я думаю, что это было бы улучшением. Айполино ( разговор ) 21:21, 25 марта 2021 (UTC) [ ответ ]
  • Поддерживайте что угодно, чтобы сделать шаблон более удобным для пользователя, но предпочитайте предложения User: Blueboar и других о более радикальном пересмотре и / или замене. TheEmeraldBeyond ( обсуждение ) 23:04, 26 марта 2021 (UTC) [ ответ ]
  • Поддержите создание удобочитаемого шаблона для среднего читателя Asartea Talk | Вклад 09:01, 28 марта 2021 (UTC) [ ответ ]

Альтернативное форматирование[ редактировать ]

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

Меня до сих пор смущает назначение шаблона Authority control. Я посмотрел на саму страницу шаблона, и там объясняется, ЧТО он делает, но не ПОЧЕМУ он это делает. Есть ли страница или обсуждение, объясняющее цель использования таких метаданных в наших статьях? Blueboar ( разговор ) 12:12, 18 марта 2021 (UTC) [ ответ ]

Он связан в шаблоне ... Справка: Контроль полномочий . Изно ( разговор ) 15:03, 18 марта 2021 (UTC) [ ответ ]
Однако большая часть информации на этой странице неверна или сильно устарела (сравните краткий шаблон управления авторитетностью из 5 ссылок, показанный для Александра Грэхема Белла, с текущим раздуванием 27 ссылок). По сути, все, что там описано, делается через Викиданные (и если есть сторонние приложения, которые напрямую полагаются на шаблон в enwiki, они должны быть переписаны кем-то более компетентным), а не через Enwiki, за исключением ссылки читателей на некоторые из перечисленных баз данных. . Каждый исследователь и приложение, которым требуются уникальные идентификаторы, должны делать это через Викиданные, которые являются источником, а не через enwiki, которые являются частичным зеркалом только для этой информации. Автобус это обсуждение, хотя и необходимо, отдельно от RFC. Фрам ( разговорное ) 15:17, 18 марта 2021 (UTC)[ ответ ]
Я чувствую, что этот шаблон существует только для того, чтобы люди могли массово добавлять его в статьи. Совершенно уверен, что он не дает читателям никакой пользы, по крайней мере, в его нынешней структуре, которая представляет собой просто неясную кучу цифр и сокращений. ProcrastinatingReader ( обсуждение ) 15:22, 18 марта 2021 (UTC) [ ответ ]
Как бы то ни было, я нашел его полезным в нескольких случаях, особенно в отношении сверки данных о BLP (конечно, не в качестве надежного источника). Иногда у меня были даты рождения, которые не совпадали в статьях на разных вики, и я мог использовать различные авторитетные элементы управления, чтобы выяснить, что было наиболее вероятно правильным. Я в основном рассматривал его как альтернативу WikiData, когда мне нужна структурированная информация о ком-то. Проблема, конечно же, в том, что авторитетный контроль не является надежным источником в том же смысле, что и WikiData. Мне было бы интересно узнать, какие возможные варианты использования он имеет для реальных читателей, которые не хотят редактировать страницу, на которой он находится. Perryprog ( обсуждение ) 13:05, 19 марта 2021 (UTC) [ ответ ]
Согласитесь с вышеизложенным, говоря, что шаблон бесполезен почти везде в Википедии. Викиданные должны выполнять сопоставление уникальных идентификаторов. Отражение этого в Википедии в лучшем случае странно (то есть для тех, кто понимает, что это значит); и совершенно непонятно для большинства. Я не могу поддержать предложение Fram OP об этом RfC (аккуратно организованная избыточность ... все еще избыточность ... она просто занимает еще больше места, а я бы уменьшил это пространство до нуля), но я с радостью поддержу любое предложение, которое препятствовать широкому использованию шаблона в английской Википедии. - Фрэнсис Шонкен ( разговор ) 16:00, 18 марта 2021 г. (UTC) [ ответ ]
Это уже было массово добавлено во все остальные статьи. Я думаю, что с 1,75 миллионами включений корабль отплыл, чтобы препятствовать еще большему использованию. Если мы не можем очистить / удалить его (что я бы поддержал), реформирование его, чтобы оно не было бесполезным, - это следующая лучшая вещь, имо. ProcrastinatingReader ( обсуждение ) 16:09, 18 марта 2021 (UTC) [ ответ ]
На самом деле это не зеркальное отражение , а отображение. Вы можете привести аналогичный аргумент в пользу удаления инфобоксов. Элли ( Обсуждение | вклад ) 16:47, 18 марта 2021 (UTC) [ ответ ]
Однако большинство информационных ящиков не отражают информацию Викиданных, а получают их локально: и, что более важно, большинство информационных ящиков говорят сами за себя, они добавляют свою собственную понятную информацию с прямым использованием для многих читателей (хотя и там значительная группа не делает этого) Мне они нравятся). Фрам ( разговор ) 17:01, 18 марта 2021 (UTC) [ ответ ]
Инфобоксы, получающие данные локально, являются скорее «зеркальным отражением», чем получение авторитетного контроля из Викиданных. Мне в целом нравится ваша идея реформирования шаблона. Элли ( обсуждение | вклад ) 17:03, 18 марта 2021 (UTC) [ ответ ]
Это полезно так же, как и ссылки. Вы можете найти дополнительную информацию по ссылкам или подтвердить содержание статьи. Спасибо. Майк Пил ( разговор ) 17:43, 18 марта 2021 (UTC) [ ответ ]
Ссылки подтверждают информацию, написанную в статье. Внешние ссылки, которые этого не делают, связаны директивой WP: EL , которая гласит: в Википедию не входит включение длинного или исчерпывающего списка внешних ссылок, относящихся к каждой теме. Ни одна страница не должна содержать ссылки из статьи Википедии, если ее включение не оправдано в соответствии с этим правилом и здравым смыслом . Бремя предоставления этого обоснования лежит на человеке, который хочет включить внешнюю ссылку. Авторитетный контроль - это исключение из правила, а не правило. ProcrastinatingReader ( обсуждение ) 18:24, 18 марта 2021 (UTC) [ ответ ]
«Внешние ссылки ... подчиняются директивам WP: EL» Нет. Это руководство . Этим ничего не «сковано». Кроме того, руководство Википедии должно описывать, а не запрещать текущую практику. Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 15:41, 19 марта 2021 г. (UTC) [ ответ ]
Как обычно, WP: JUSTAGUIDELINE - самое слабое из всех возможных объяснений. Как насчет WP: NOT # LINK ? ProcrastinatingReader ( обсуждение ) 15:52, 19 марта 2021 (UTC) [ ответ ]
  • Спасибо за указатель. Разве простой (маленький) блок со ссылкой на Викиданные (возможно, говорящий: «В Викиданных есть страница по этой теме: см. Здесь») не послужит той же цели? Blueboar ( разговор ) 18:05, 18 марта 2021 (UTC) [ ответ ]
Очень похоже на ссылку на Commons или Wikiquote? Это тоже неплохая идея. Lugnuts Fire иди со мной 08:04, 19 марта 2021 (UTC) [ ответ ]
Викиданные не совсем предназначены для просмотра, и это видно по их дизайну, так что направлять читателей таким образом не идеально. Он предназначен для извлечения, что и выполняет шаблон AC. -  Finnusertop ( обсуждение ⋅ вклад ) 10:35, 19 марта 2021 г. (UTC) [ ответ ]
  • Помимо выполнения того, что указано в названии, авторитетный контроль помещает статью в Википедии о предмете в связь с другими ресурсами на ту же тему. Он в основном делает то, что делает наш раздел внешних ссылок. Но в то время как многие ссылки в разделе EL быстро раздуваются и занимают слишком много места на странице, этот шаблон упаковывает тонны ресурсов в [относительно] небольшую коробку, спрятанную внизу страницы. Хотя большинство пользователей, вероятно, не замечают этого (такие же категории и другие элементы на краях статьи), я разговаривал с очень большим количеством библиотекарей, исследователей, архивистов и т. Д., Которые действительно это ценят. (Это ответ на данный подраздел, а не мнение о самом RfC). -Рододендриты говорят\\ 14:41, 19 марта 2021 (UTC) [ ответ ]
  • Разве это не часть идеи Викиданных, что такая информация должна быть перемещена туда? DGG ( разговор ) 06:02, 21 марта 2021 (UTC) [ ответ ]
    @ DGG : данные хранятся в Викиданных, это просто делает их видимыми в Википедии. Элли ( обсуждение | вклад ) 05:36, 22 марта 2021 (UTC) [ ответ ]
    • Нет сомнений в том, что данные полезны для библиотекарей и т. Д. Вопрос в том, действительно ли нам нужны / хотим, чтобы эти данные были видны здесь, на WP ... или мы хотим, чтобы данные были видны в Викиданных . Blueboar ( разговор ) 13:02, 22 марта 2021 (UTC) [ ответ ]
бывают случаи, когда такие идентификаторы необходимы, чтобы прояснить, о чем на самом деле статья, и они могут быть лучшей отправной точкой для получения дополнительной информации. Но иногда они непоследовательны, иногда ошибочны, особенно OCLC, и часто отражают простые вариации формата, особенно ISBN. Практика библиотек, столкнувшихся с этим хаосом, заключается в том, чтобы записывать все доступные идентификаторы, не пытаясь их согласовать - это больше в сфере библиографов. (Хотя я иногда прибегал к их анализу на WP, чтобы прояснить историю публикаций периодического издания, обычно в беседе p, потому что это в некотором смысле ИЛИ). Я никогда не пробовал работать с этим над викиданными, так как в прошлом качество было настолько неустойчивым, что могло обескураживать, но я знаю, что редакторы там пытаются очистить его, как могут). Тогда вопрос,как было сказано выше, именно эта часть принадлежит WP. Что касается журнальных статей, я думаю, что doi делает - это довольно надежно. Для книг я обычно указываю один ISBN, если возможно, для печатного издания, которое имеет тенденцию быть более стабильным (если только OCLC не записывает только электронную версию того, что на самом деле также является печатной книгой). Что касается идентификации людей, то ничего из того, что я знаю, не является надежным. Единственный источник для авторов, которого я знаю и который может оказаться совершенно ненадежным, - это LC примерно после 1960-70 годов и записи OCLC или записи международной каталогизации, полученные из LC, поскольку, если информация о личности автора не сразу очевидна из названия страницы книги, они просто копируют ее из Википедии - и, кажется, делают это все чаще. .s довольно надежный. Для книг я обычно указываю один ISBN, если возможно, для печатного издания, которое имеет тенденцию быть более стабильным (если только OCLC не записывает только электронную версию того, что на самом деле также является печатной книгой). Что касается идентификации людей, то ничего из того, что я знаю, не является надежным. Единственный источник для авторов, которого я знаю и который может оказаться совершенно ненадежным, - это LC примерно после 1960-70 годов и записи OCLC или записи международной каталогизации, полученные из LC, поскольку, если информация о личности автора не сразу очевидна из названия страницы книги, они просто копируют ее из Википедии - и, кажется, делают это все чаще. .s довольно надежный. Для книг я обычно указываю один ISBN, если возможно, для печатного издания, которое имеет тенденцию быть более стабильным (если только OCLC не записывает только электронную версию того, что на самом деле также является печатной книгой). Что касается идентификации людей, то ничего из того, что я знаю, не является надежным. Единственный источник для авторов, которого я знаю и который может оказаться совершенно ненадежным, - это LC примерно после 1960-70 годов и записи OCLC или записи международной каталогизации, полученные из LC, поскольку, если информация о личности автора не сразу очевидна из названия страницы книги, они просто копируют ее из Википедии - и, кажется, делают это все чаще. .Что касается идентификации людей, то ничего из того, что я знаю, не является надежным. Единственный источник для авторов, которого я знаю и который может оказаться совершенно ненадежным, - это LC примерно после 1960-70 годов и записи OCLC или записи международной каталогизации, полученные из LC, поскольку, если информация о личности автора не сразу очевидна из названия страницы книги, они просто копируют ее из Википедии - и, кажется, делают это все чаще. .Что касается идентификации людей, то ничего из того, что я знаю, не является надежным. Единственный источник для авторов, которого я знаю и который может оказаться совершенно ненадежным, - это LC примерно после 1960-70 годов и записи OCLC или записи международной каталогизации, полученные из LC, поскольку, если информация о личности автора не сразу очевидна из названия страницы книги, они просто копируют ее из Википедии - и, кажется, делают это все чаще. .DGG ( разговор ) 20:45, 22 марта 2021 (UTC) [ ответ ]
Помните WP: СКАЖИТЕ ГДЕ ОРЕААДИТ Если вы читали это в книге, используйте ISBN, напечатанный в книге. Мартин Шеффилдский ( разговор ) 22:23, 22 марта 2021 (UTC) [ ответ ]

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

Это еще одна вещь, которую следует учитывать при изменении элемента управления Authority, чтобы сделать его более удобным для читателей. В настоящее время шаблон вообще не отображается в мобильной версии. Шаблон, используемый в более чем 1,7 миллиона статей, должен быть виден читателям с мобильных устройств, которые составляют значительную часть читателей.текущий результат шаблона Authority Control выглядит так; Я читаю это с мобильного и вижу пустую строку. AVS malnad 77 разговор 17:47, 18 марта 2021 (UTC) [ ответить ]

Это обсуждается на странице обсуждения авторитетного контроля. Тем не менее, сегодня это верно для всех навигационных ящиков, и это сложная проблема. Изно ( разговор ) 18:01, 18 марта 2021 (UTC) [ ответ ]
{{ Authority control }} - это навигационный блок, и все навигационные блоки отключены в мобильном представлении. Это выдающаяся ошибка в течение нескольких лет; см. T124168 . -  Джо  ( разговор ) 18:08, 18 марта 2021 г. (UTC) [ ответ ]
К сожалению, он был помечен как низкий приоритет. Это объясняет, почему он ждал рассмотрения в течение многих лет. Я надеюсь, что они предоставят больше поддержки мобильным пользователям. AVS malnad 77 разговор 02:55, 19 марта 2021 (UTC) [ ответить ]
Повторное включение тривиально, но если бы мы это сделали, это выглядело бы, как в этом видео https://www.youtube.com/watch?v=eaos1s3UfLs . Я думаю, что это хуже, чем статус-кво, и для решения этой проблемы потребуется существенная переработка шаблона. Если бы у нас было согласованное направление, в котором мы будем его улучшать, я думаю, это было бы выполнимо. - Trialpears ( обсуждение ) 10:10, 19 марта 2021 г. (UTC) [ ответ ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать на соответствующей странице обсуждения. Никаких дальнейших изменений в это обсуждение вносить не следует.

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

На что должны быть похожи сообщение и интерфейс, которые появляются, когда вы нажимаете «поблагодарить» в различии или истории? На странице обсуждения справки: уведомления / спасибо было предложено изменить формулировку сообщения и добавить ссылку на страницу справки, чтобы сделать его менее запутанным. Итак, у нас есть:

  • Статус-кво: публично послать благодарность? Спасибо Отменить
  • Вариант А: Отправить спасибо? Спасибо Отменить Помощь
  • Вариант Б. Отправить благодарность ( помощь )? Спасибо Отменить

Смотрите здесь предварительное обсуждение (участников которого я уведомлю). Обратите внимание, что это не имеет обязательной силы, и нет никакой гарантии, что результат будет принят; это просто неофициальный опрос, чтобы узнать, нужно ли вносить изменения. Nardog ( разговор ) 07:53, 21 марта 2021 (UTC) [ ответ ]

  • А или В, предпочтительно А . Хотя это случай, когда благодарности регистрируются, слово «публично» вводит в заблуждение, поскольку только тот, кто кого благодарил, когда, даже за какое редактирование или на какой странице, является общедоступным, и только если вы перейдете в Special: Log , который ни один случайный пользователь даже не узнает о существовании. Следующее из обсуждения иллюстрирует потребность в изменении. Diegodlh сказал:

    Мне было непонятно, была ли уже отправлена ​​моя благодарность, и спрашивал ли меня, хочу ли я публично поблагодарить редактора, вдобавок к этому, или публично поблагодарить было единственным выходом.

    Пдеби сказал:

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

    Удаление «публично» устранит такую ​​путаницу, а добавление справочной ссылки поможет новичкам узнать, что делает функция, и меньше сомневаться в ее использовании, что приведет к увеличению удержания редакторов, если верить этим исследованиям . Nardog ( разговор ) 07:53, 21 марта 2021 (UTC) [ ответ ]
  • Поддержите изменение, желательно A - я всегда думал, что «публичная» формулировка на самом деле не соответствует действительности. ƒirefly ( t · c ) 08:20, 21 марта 2021 (UTC) [ ответ ]
  • Смена поддержки, желательно A - Спасибо за внимание к этим усилиям; если оно будет реализовано, ваше решение будет менее запутанным. Патрик. ツPdebee. (говорить) ( старомодно! ) 10:45, 21 марта 2021 (UTC) [ ответ ]
  • Комментарий: Во-первых, я бы предпочел, чтобы три заданных варианта имели похожие ярлыки, то есть варианты A, B и C вместо громоздкого «Status Quo», что сделало бы A и B более привлекательными для простого ввода. Во-вторых, страница справки значительно улучшена по сравнению с первоначальным обсуждением в 2019 году (если я могу так сказать). Первоначальное обсуждение оттачивает слово «публично» и его значение. Прочтите страницу справки, я надеюсь, вы найдете ее гораздо более поучительной, чем раньше. Наконец, вот соответствующие вопросы, которые я поднял в первоначальном обсуждении.к которым на самом деле никогда не обращались: а) «Благодарность» и «Отмена» должны быть кнопками, а не ссылками - они выполняют команды, они не переводят вас на новые страницы. Это упростит распознавание ссылки справки. б) страница справки предназначен для всей функции «Спасибо», а не просто для того, чтобы отвечать на вопросы «публично», что предлагает вариант B как более логичное размещение. c) Насколько я понимаю аргумент PrimeHunter (в предыдущем обсуждении), вариант A требует вмешательства разработчика, в то время как вариант B может быть выполнен только путем настройки системных сообщений. г) степень «публичности» вашей благодарности спорна - см. предыдущее обсуждение. Именно поэтому мы вносим изменения по правильным причинам. CapnZapp ( обсуждение ) 10:56, 21 марта 2021 г. (UTC ) [ ответ ]
    С этой целью вот альтернативный опрос:
    • Вариант А: публично послать благодарность? Спасибо Отменить
    • Вариант Б: Отправить спасибо? Спасибо Отменить Помощь
    • Вариант C: Отправить спасибо ( помощь )? Спасибо Отменить
    • Вариант D: Отправить спасибо ( помощь )?  Thank Cancel
    CapnZapp ( разговор ) 11:01, 21 марта 2021 (UTC) [ ответ ]
    Вы бросаете гаечный ключ посреди этого обсуждения. Отмена вариантов, когда другие уже участвовали, почти запутает людей, а вариант D даже не сравним с другими! Мы можем назвать статус-кво «Вариант 0», если захотим, и я не возражаю против вас или кого-либо, добавляющего варианты (при условии, что это изменение на том же уровне). Nardog ( разговор ) 11:19, 21 марта 2021 (UTC) [ ответ ]
    Я поднял проблему кнопки / ссылки в обсуждении 2019 года. Не отклоняйте мое напоминание, как если бы у меня была возможность внести свой вклад в ближайшее время, но упустите его. (Если вы считаете, что есть лучшее место, где мне следовало бы поднять этот вопрос, имеющий непосредственное отношение к теме, вам придется сказать мне, где) CapnZapp ( разговор ) 14:49, 21 марта 2021 г. (UTC) [ ответ ]
    в то время как вариант B может быть выполнен только путем настройки системных сообщений. Оказалось, что это не так. См. Комментарии Xaosflux. И A, и B требуют «вмешательства разработчика» (хотя B проще).
    Хорошо спасибо. CapnZapp ( разговор ) 14:50, 21 марта 2021 (UTC) [ ответ ]
    страница справки предназначена для всей функции «Спасибо», а не просто для того, чтобы отвечать на вопросы «публично», что предлагает вариант B как более логичное размещение. Я не следую этому аргументу. Какая часть варианта А предполагает, что он «просто отвечает на вопросы« публично » » (когда это слово даже не встречается в нем)?
    кнопки, а не ссылки. Это потребует еще более радикальных изменений, чем вариант A. А пока давайте сосредоточимся на том, что находится в пределах нашей досягаемости (а это как A, так и B). Вы можете запросить это изменение отдельно.
    степень «гласности» вашей благодарности спорна Эм ... так? Вы оспариваете мою характеристику («только тот, кто кого поблагодарил, когда, даже не за какое редактирование или на какой странице, является общедоступным»)? Nardog ( разговор ) 11:08, 21 марта 2021 (UTC) [ ответ ]
  • См. Технические примечания на сайте phab: T229168 для получения информации об изменениях программного обеспечения, которые могут потребоваться в процессе разработки. - Обсуждение xaosflux 12:25, 21 марта 2021 г. (UTC) [ ответ ]
    • @ Xaosflux : вариант Б уже возможен? Разве мы не можем просто создать MediaWiki: thank-confirm2 с содержанием «Публично {{GENDER: $ 1 | send}} спасибо? ([[Help: Notifications / Thanks | help]]" ProcrastinatingReader ( talk ) 12:41, 21 Март 2021 г. (UTC) [ ответ ]
      • @ ProcrastinatingReader : нет, так как интерфейсное сообщение не поддерживает ссылки (см. Пример здесь, в testwiki). Включение этого потребует изменения программного обеспечения, я думаю, что это обсуждение должно помочь собрать поддержку для лоббирования включения таких изменений. - Обсуждение xaosflux 12:54, 21 марта 2021 г. (UTC) [ ответ ]
        • А ну понятно. Действительно, это проблема. Разве функция, отображающая сообщения, не должна анализировать вики-текст? Например, на странице FlaggedRevs используются стандартные функции msg, и в этом шаблоне работает wikitext. Посмотрев на источник для благодарности, сообщение отображается с использованием JS (с использованием mw.msg) ( [17] ). Предположительно эта функция не поддерживает викитекст? Есть ли альтернативная функция JS? ProcrastinatingReader ( обсуждение ) 13:16, 21 марта 2021 (UTC) [ ответ ]
        • Покопался. Смотрите здесь . Если вместо этого используется mw.message (). Parse, он должен анализировать викитекст, верно? Так должно быть быстрое изменение? ProcrastinatingReader ( обсуждение ) 13:20, 21 марта 2021 (UTC) [ ответ ]
          • Нет, это тоже нужно изменить. Я понимаю, что вариант А может быть проще. В любом случае это повлечет за собой изменение jquery.confirmable.js. .parse () может вызвать проблемы XSS, поэтому это может быть сложно. Nardog ( разговор ) 13:23, 21 марта 2021 (UTC) [ ответ ]
            • Тем не менее, небольшое изменение есть. Что касается XSS? ProcrastinatingReader ( обсуждение ) 14:02, 21 марта 2021 г. (UTC) [ ответ ]
  • Предпочитают вариант B . Интерфейс обычно имеет (помощь) в скобках после текста, я думаю, перед действием. Например, здесь editnotice о незавершенных изменениях. ProcrastinatingReader ( обсуждение ) 12:33, 21 марта 2021 (UTC) [ ответ ]
  • Статус-кво . Важно отметить, что благодарности являются общедоступными, а не частными (любой может посмотреть журнал благодарностей), и это хорошо, чтобы поддерживать согласованность с другими вики (Wikidata, Commons и т. Д.). Постоянная видимая ссылка справки не особенно полезна, это еще одна ссылка, по которой можно неправильно щелкнуть, и если вы не знаете, что такое «спасибо», вы можете легко узнать (просто погуглите «спасибо» вики). Спасибо. Майк Пил ( разговор ) 14:26, 21 марта 2021 (UTC) [ ответ ]
    @ Mike Peel : Предложение потребует изменения программного обеспечения, поэтому оно будет «согласовано с другими вики», при этом ссылка по умолчанию будет указывать на mw: Special: MyLanguage / Help: Notifications / Thanks (см. Ссылки « Help». во многих частях МВТ). Nardog ( разговор ) 14:31, 21 марта 2021 (UTC) [ ответ ]
    @ Nardog : Значит, это должно быть кросс-вики-предложение, возможно, в мета-версии, или результат будет предложением разработчикам? Enwp не может самостоятельно решить изменить конфигурацию MediaWiki по умолчанию. Спасибо. Майк Пил ( разговор ) 14:45, 21 марта 2021 (UTC) [ ответ ]
    Ага, последнее. Как я сказал в начале, это просто для того, чтобы понять, сколько людей подумают, что это улучшение. phab: T229168 уже отмечен как «приветствие патча», но я боюсь, что они не приняли бы мой патч сразу, если бы не было «каких-либо исследований, говорящих о том, что это будет положительное улучшение», как они выразились. Nardog ( разговор ) 14:52, 21 марта 2021 (UTC) [ ответ ]
  • комментарий Я думаю, что в подтверждении нет необходимости. «Спасибо» должно быть одноразовым щелчком. Schazjmd  (разговор) 16:10, 21 марта 2021 (UTC) [ ответ ]
  • Насколько я помню, несколько человек выразили обеспокоенность по поводу предупреждения пользователей о том, что благодарности публикуются в открытом журнале. Таким образом, в настоящее время я поддерживаю сохранение текущего сообщения и добавление справочной ссылки для объяснения механизма благодарственных уведомлений. isaacl ( разговор ) 16:27, 21 марта 2021 (UTC) [ ответ ]
  • Поддержите изменение, желательно B - информация о том, что оно публично, не нужно и сбивает с толку, особенно с учетом того, что в Википедии почти все открыто. Когда я только начинал работать с WP, я какое-то время не благодарил людей, потому что предполагал, что странно сформулированное / неоднозначное «Публично отправить благодарность» будет автоматическим постом на странице обсуждения или чем-то в этом роде. Aza24 ( разговор ) 17:58, 21 марта 2021 (UTC) [ ответ ]
  • Статус-кво в отношении слова «публично», согласно Isaacl et al. По остальному без комментариев. - Изно ( разговор ) 18:11, 21 марта 2021 г. (UTC) [ ответ ]
  • Статус-кво Действительно? Это вообще стоит обсудить? G en Q uest "scribble" 18:53, 21 марта 2021 (UTC) [ ответ ]
    Довольно. Функция «спасибо» - это просто уловка, чтобы заставить нас выглядеть как сайт социальной сети, а не что-то, что должно тренировать клетки нашего мозга, которые следует использовать для улучшения энциклопедии. Фил Бриджер ( разговор ) 19:15, 21 марта 2021 (UTC) [ ответ ]
  • Статус-кво Всего без проблем. ~ HAL 333 02:30, 22 марта 2021 г. (UTC) [ ответ ]
  • Статус-кво Я бы поддержал вариант A или B, но ссылка на справку мне не нужна. Просто «Отправить спасибо? Спасибо, отменить» было бы хорошо. Элли ( обсуждение | вклад ) 05:35, 22 марта 2021 (UTC) [ ответ ]
  • Смена поддержки, желательно B. Мне всегда казалось, что это сбивает с толку. Вы попадаете туда, нажав «поблагодарить», а затем вас спросят, хотите ли вы «публично отправить благодарность», подразумевая, что есть частная альтернатива. Я бы даже был в порядке, если бы по этому поводу не было никакого подтверждения. MB 18:54, 22 марта 2021 г. (UTC) [ ответ ]
  • Статус-кво . Формулировка была изменена неспроста. Я отправил в битовое ведро благодарность за целые годы, потому что старый запрос (который ближе к A / B выше) звучал как «вы отправляете благодарность, вы хотите, чтобы он был общедоступным или частным?» Я, конечно, просто хотел, чтобы человека, которого я благодарил, поблагодарил, поэтому выбрал приватную опцию, которая на самом деле была опцией «вообще отказаться от отправки благодарностей». Важно прояснить, что благодарность является публичной, и другого варианта нет, так что формулировка статус-кво в порядке. SnowFire ( разговор ) 21:11, 25 марта 2021 (UTC) [ ответ ]

RfC: Нет нацистов[ редактировать ]

На WT: NAZI # Proposal есть постоянный RfC . Не стесняйтесь участвовать. Firestar464 ( разговор ) 01:54, 23 марта 2021 (UTC) [ ответ ]

Это было закрыто противником. Эмир Википедии ( обсуждение ) 14:32, 28 марта 2021 (UTC) [ ответ ]

Изменить смягчение конфликтов: инструмент раннего предупреждения[ редактировать ]

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

Давайте создадим цветной прямоугольный значок, который появляется в режиме предварительного просмотра , изначально на зеленом фоне, что означает, что «никто больше не менял этот раздел» (или что-то еще, что находится внутри окна предварительного просмотра). Как только он обнаруживает, что что-то изменилось (я думаю о уведомлении в списке наблюдения, сообщении «Просмотреть новые изменения с отметки времени », которое появляется вверху моего списка наблюдения), фон значка становится желтым, а сообщение внутри него изменяется. соответствующим образом (подлежит уточнению позже) вместе с, возможно, двумя или тремя маркированными ссылками или переключателями или чем-то еще, для возможных действий, которые необходимо предпринять. Если раздел, который я редактирую, полностью исчезнет (как это произошло вчера, когда бот заархивировал обсуждение Talk, пока я отвечал на него), значок становится красным.

Это было бы для изменений на диске; но мы можем пойти дальше. Давайте установим флажок на значке, который говорит: «Сообщите другим, что я работаю над этим разделом (или страницей)» (возможно, также второй флажок: «и сообщите им мою личность».) Затем, если они редактируют это также, их поле сразу станет оранжевым, давая им знать, что кто-то работает над тем же разделом (и, возможно, кто это, если я позволил). Это навеяно обзором ожидающих изменений, что дает вам возможность сообщить другим, что вы работаете над определенным изменением, предположительно, чтобы избежать конфликтов. Если вы поставите галочку в этом поле, тогда, если другие также выберут то же изменение для работы, они получат небольшое оранжевое сообщение о том, что кто-то работает над этим (возможно, даже их личность; я не помню). Улучшение: параметр «Настройки»: «По умолчанию делиться моей идентификационной информацией на значке предварительного просмотра, когда я редактирую раздел».

Я вижу в этом всевозможные преимущества, и у меня есть больше идей о том, какой текст разместить на значке и какие варианты могут быть возможны, но предложение становится все более актуальным, поэтому я остановлюсь здесь и открою его на пол. Матглот ( разговор ) 21:55, 23 марта 2021 (UTC) [ ответ ]

  • Поддержка Это было бы полезно. ~ HAL 333 21:59, 24 марта 2021 (UTC) [ ответ ]
  • Поддержка Было бы здорово получить предупреждение о конфликте, когда я нажимаю «предварительный просмотр», а не когда нажимаю «опубликовать». Не уверен в том, что вторая часть сообщения людям о том, что редактирование выполняется, возможно, реализуется в два этапа: первый - это предупреждение о предварительном просмотре, а следующий - улучшения. RudolfRed ( разговор ) 22:56, 24 марта 2021 (UTC) [ ответ ]
  • Комментарий не затрагивает ли этот вопрос конфликт редактирования на основе абзаца в бета-функциях настроек? Aza24 ( разговор ) 23:04, 24 марта 2021 (UTC) [ ответ ]
  • @ Mathglot : Я буквально начал работать над сценарием для первой части несколько недель назад. Мой долгосрочный план - каким-то образом выделить в окне редактирования слова, вызывающие конфликт; Я еще даже не начал с этой части. Если кто-то захочет, я могу опубликовать свою (ужасно некрасивую и глючную) незавершенную работу. Suffusion of Yellow ( разговор ) 23:13, 24 марта 2021 (UTC) [ ответ ]
    Но я бы хотел развеять заблуждение. Автоматическое слияние, когда вы не получаете конфликта редактирования, основано на строках , а не на разделах . Последнее, что я проверил, это просто передача трех ревизий в diff3 (который был предназначен для слияния кода, а не английского текста). То, что я хочу попробовать, основано на словах , поэтому конфликтов должно быть меньше. Suffusion of Yellow ( разговор ) 23:17, 24 марта 2021 (UTC) [ ответ ]
  • Если возможно, Support . Бисквит с ДМТ ( разговор ) 16:54, 1 апреля 2021 (UTC) [ ответ ]

Массовое удаление более 5500 заглушек[ редактировать ]

Произошло массовое создание более 5500 статей, которые не содержат ничего, кроме координаты, названия на фарси и утверждения, что что-то является «деревней». К сожалению, исходная база данных, которая использовалась для их массового создания, на самом деле включает насосы ( fa: تلمبه ), колодцы ( fa: چاه ), фермы и так далее; и единственный прозаический факт в получившейся статье на самом деле ложен, что делает эти плохие заглушкикоторые даже не дают правильного контекста для расширения. У нас есть конкретный список статей, которые, скорее всего, таковыми, основаны на статье, которая затем утверждает, что для записи в базе данных «нет данных о населении»; и редакторы ищут консенсуса, чтобы администратор мог их массово удалить. Также есть отдельное обсуждение автора статьи. Просмотрите и обсудите на доске объявлений с гиперссылками. Дядя Джи ( разговор ) 08:47, 28 марта 2021 (UTC) [ ответ ]

Стрелки[ редактировать ]

Я предлагаю Википедии прекратить публиковать имена массовых стрелков. Они делают это для известности. Они хотят, чтобы их запомнили как мучеников насилия. Не давайте им это. Это также клеймит членов их семей, которые не имеют ничего общего с их гнусными поступками. Публикуйте информацию о своем происхождении, возрасте, поле, расе, происхождении, но не об их имени. Не доставляйте им удовлетворения, продолжая пытать людей. - Предшествующий неподписанный комментарий добавлен Turtle595 ( обсуждение • вклад ) 21:00, 30 марта 2021 г. (UTC) [ ответ ]

  • Хотя я с пониманием отношусь к вашему делу, Википедия не подвергается цензуре . Мы избегаем использования имен несовершеннолетних и предпринимаем другие меры для защиты жертв. Наша работа как энциклопедии - нейтрально задокументировать заметные события. Если мы не будем использовать имена виновных, маловероятно, что это повлияет на уровень насилия в мире. Деннис Браун - 2 21:37, 30 марта 2021 (UTC) [ ответ ]
  • Хочу также добавить, что мы практически всегда руководствуемся достоверными источниками (в данном случае СМИ) при именовании обвиняемых. Практически во всех съемках, которые мы освещали, имя стрелка уже известно общественности. Я думаю, что желание Turtle595 отказать в признании массовым убийцам достойно восхищения, но на самом деле это не то, что мы можем сделать как энциклопедию. Дух Орла ( разговор ) 23:56, 31 марта 2021 (UTC) [ ответ ]

Сделать автоматическую вставку даты доступа для инструмента визуального редактирования цитирования всякий раз, когда мы вводим новую цитату[ редактировать ]

Как пользователь VisualEditor, мне было довольно приятно пользоваться их услугами визуального цитирования, но довольно неприятно указывать дату доступа каждый раз, когда я создаю новую цитату. Было бы лучше, если бы он автоматически вставлялся всякий раз, когда мы делали новую цитату с цитатой. - С уважением, Джероми Майкл 02:08, 31 марта 2021 г. (UTC) [ ответ ]

Дата доступа относится к тому моменту, когда вы проверили страницу, на которую указывает URL, а не к тому моменту, когда вы сделали ссылку или отредактировали статью. Как инструмент узнает, когда вы в последний раз проверяли URL-адрес? Мартин Шеффилдский ( разговор ) 06:04, 31 марта 2021 (UTC) [ ответ ]
@ Мартин Шеффилдский : Я думаю, это значения по умолчанию на текущий день? Когда мы цитируем, мы всегда видим страницу в один и тот же день. - С уважением, Джероми Майкл 07:32, 31 марта 2021 г. (UTC) [ ответ ]
Я не думаю, что это сработает. Например, есть много случаев, когда люди просто копируют цитату из одного места в другое, часто без повторной проверки. Если бы у него не было даты доступа в исходном месте, ваш механизм теперь будет создавать впечатление, что он был недавно проверен, что во многих случаях было бы ложным. Fut.Perf. ☼ 07:42, 31 марта 2021 г. (UTC) [ ответ ]
Точно. Также, если у меня есть цитата от Zotero, которая должна отражать дату сохранения копии PDF (или чего-то еще). Мартин Шеффилдский ( разговор ) 07:45, 31 марта 2021 (UTC) [ ответ ]
Увы, установка по умолчанию на текущую дату - это как раз то, что происходит с WP: ReFill ( пример редактирования ). Еще одна причина, по которой этот инструмент следует убить.
- Монах-траппист ( разговор ) 10:35, 31 марта 2021 г. (UTC) [ ответ ]

Союз между IP-адресом и учетной записью[ редактировать ]

Перед тем, как присоединиться к Википедии, я изменил IP-адрес. Я хочу "объединить" вклады IP-адреса в мою учетную запись. Д-р Salvus 13:04, 31 марта 2021 г. (UTC) [ ответ ]

  • @ Д-р Сальвус : Технической возможности для этого нет. G M G talk 13:06, 31 марта 2021 г. (UTC) [ ответ ]
    • @ GreenMeansGo : Мое предложение - сделать это возможным Д-р Сальвус 13:11, 31 марта 2021 г. (UTC) [ ответ ]
      • Доктор Сальвус , это было предложено в списке желаний 2019 года и ни к чему не привело. Кабайи ( разговор ) 13:17, 31 марта 2021 (UTC) [ ответ ]
        • В любом случае это невозможно, потому что невозможно определить, что все изменения с IP-адреса действительно были сделаны одним и тем же человеком. G M G ток 13:43, 31 марта 2021 (UTC) [ ответить ]
          • @ GreenMeansGo : нельзя ли использовать "Проверить пользователя"? Д-р Salvus 18:49, 31 марта 2021 г. (UTC) [ ответ ]
            • Не совсем. Политика m: CheckUser гласит, что данные хранятся только 90 дней. Я бы добавил, что, поскольку IP-адреса почти всегда переназначаются и могут использоваться несколькими людьми, наличие этих данных все равно не будет достаточным доказательством. - zzuuzz (разговор) 18:59, 31 марта 2021 (UTC) [ ответ ]
              • ^ G M G talk 19:44, 31 марта 2021 (UTC) [ ответ ]
  • Если вы намерены взять на себя ответственность за плохие последствия ваших предыдущих изменений, то это можно сделать, просто связав IP-адреса, которые вы использовали на своей странице пользователя. Если вы намерены использовать предыдущие правки для сбора шляп, это может закончиться только слезами. Фил Бриджер ( разговор ) 19:57, 31 марта 2021 (UTC) [ ответ ]

Должны ли мы продавать Википедию, пока Фонд Викимедиа не ищет и не забирает выручку?[ редактировать ]

Так что недавно я связался с другом и упомянул, что редактирую Википедию в свободное время. Он ошибочно предположил, что Википедия принадлежит мне, и предложил выкупить у меня проект. Я уверен, что могу получить от всего этого 5 миллиардов долларов, и я счастлив разделить это с нашими ~ 150 000 активными редакторами (что составляет около 3 миллионов долларов и сдача на человека). Википедия - это прежде всего сообщество, поэтому было бы неэтично сознательно продавать фальшивое название проекту без предварительного согласия моих коллег-редакторов. Так что вы скажете: вы хотите стать миллионером? Ответьте быстро, пожалуйста: я почти уверен, что продавать вещи, которыми вы не владеете, незаконно, поэтому нам, вероятно, следует закрыть эту сделку в течение следующих 24 часов. [ Первоапрельские дураки! ] Дух орла (talk ) 00:00, 1 апреля 2021 г. (UTC) [ ответ ]

Мы определенно должны. Как хорошо, мы должны , вероятно , облавы всех $ 3 пожертвований в Wikipedia получили и пролили , что среди нас, поэтому мы делаем больше денег возможно, потому что чем больше денег мы получаем, тем лучше. Все мы, редакторы, целый день ворочаемся по заднице, как бесплатные волонтеры, которые делают энциклопедию лучше, пора нам заработать на этом немного денег. А теперь поскорее, до того, как об этом узнает WMF. [ Первоапрельские дураки! ] D🐶ggy54321 ( давай поговорим! ) 00:11, 1 апреля 2021 г. (UTC)[ ответ ]
  • Это отличная идея. У WMF был свой шанс, но он проиграл . Однако мой друг Уильям только что сделал мне встречное предложение в размере 6 миллиардов долларов при условии, что мы поставим энциклопедию на колеса. Стоит ли нам пойти на это? - python coder  ( обсуждение  |  вклад ) 00:23, 1 апреля 2021 г. (UTC) [ ответ ]
Я посчитал, и это должно почти удвоить нашу заработную плату. Сделай это! Дух Орла ( разговор ) 00:32, 1 апреля 2021 (UTC) [ ответ ]
Ой ой https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Pythoncoder Natureium ( обсуждение ) 00:32, 1 апреля 2021 г. (UTC) [ ответ ]
Разорван ... https://en.wikipedia.org/wiki/Special:Diff/1015361823/1015427072 - кодировщик python  ( обсуждение  |  вклад ) 12:55, 1 апреля 2021 г. (UTC) [ ответ ]
  • Помощь: покупка Википедии может быть полезной. {{u | Sdkb }} talk 00:40, 1 апреля 2021 г. (UTC) [ ответ ]
    Если мы все объединим наши деньги, мы сможем купить их и сказать, что они принадлежат сообществу.
    это покажет им Тайрон Мадера ( разговор ) 17:07, 1 апреля 2021 (UTC) [ ответ ]
  • Сильное воздержание за ном. JJP Mas тер 00:49, 1 апреля 2021 (UTC) [ ответить ]
  • Определенно нет ! Нам не предлагают достаточно. Я вычеркнул свой предыдущий комментарий после прочтения справки: покупка Википедии . Я оскорблен тем, что кто-то предложил бы только 6 миллиардов долларов, когда цена Википедии составляет 63 469 965 175 772 420,69 долларов и все больше !!! Нам нужны реальные богатые инвесторы (а не те скряги, которые вы предоставили), которые готовы покупать Википедию по той цене, которую она оценивает. D🐶ggy54321 ( давай поболтаем ! ) 00:52, 1 апреля 2021 (UTC) [ ответ ]
  • Проблема в том ... WMF ВСЕГДА ищет! Они как Санта-Клаус ... всегда смотрят, кто непослушный, а кто милый. Blueboar ( разговор ) 13:23, 1 апреля 2021 (UTC) [ ответ ]
Это, вероятно, означает, что мы все получим штабеля угля, когда появится Святой Джимбо . REDMAN 2019 ( обсуждение ) 13:47, 1 апреля 2021 (UTC) [ ответ ]
  • Ты уверен, что сможешь даже уступить? Или вы имеете в виду плавать, как Wikipederoo ? Отсюда выражение «никогда не выпускайте мертвую лошадь на биржу» или что-то в этом роде ... Martinevans123 ( обсуждение ) 13:45, 1 апреля 2021 г. (UTC) [ ответ ]
  • Да, потому что мне нужны деньги. - Knowledgekid87 ( обсуждение ) 14:18, 1 апреля 2021 г. (UTC) [ ответ ]

РФК об ограничении мелких правок[ редактировать ]

Вопрос : Следует ли ограничивать функциональные возможности незначительного редактирования для группы пользователей (например, пользователей с автоподтверждением или расширенным подтверждением)?

  • Вариант 0 (статус-кво): разрешить мелкие правки только зарегистрированным пользователям.
  • Вариант A : разрешите мелкие правки только автоматически подтвержденным (или подтвержденным) пользователям.
  • Вариант B : разрешите незначительные правки пользователям с расширенным подтверждением.

Это продолжение этого RFC по эффективному отключению мелких правок. Поскольку тогда не было консенсуса, это делается для достижения более четкого консенсуса в отношении альтернативного предложения. (Я впервые запрашиваю комментарий, пожалуйста, дайте мне знать, если я делаю что-то не так.) Tol | Обсуждение | Contribs (ранее Twassman) 00:02, 1 апреля 2021 г. (UTC) [ ответ ]

  • Вопрос: А как насчет решения с гордиевым узлом, просто полностью избавьтесь от концепции "незначительного редактирования"? Это было учтено? - Троватор ( разговор ) 00:23, 1 апреля 2021 (UTC) [ ответ ]
    Вышеупомянутый RFC демонстрирует довольно явное несогласие с полным удалением мелких правок. -  ⊥ɥǝ  Ǝɐɹʍıƃ  ( ʇɐlʞ ) 00:30, 1 апреля 2021 г. (UTC) [ ответ ]
    Что ж, там говорится что-то вроде «ограничение политикой антивандализма возвращается», что на самом деле не является упрощением и добавляет еще один уровень того, что люди могут и не могут делать. Я говорю о том, что вся концепция «незначительного редактирования» полностью исчезает; дело не в том, что некоторые люди могут это делать, а некоторые нет; дело не в том, что существуют правила относительно того, когда это можно сделать; дело в том, что его просто не существует, и точка. Даже исторические правки больше не будут отличать второстепенные от второстепенных. Как будто его вообще не было. Я бы поддержал это. - Троватор ( разговор ) 00:37, 1 апреля 2021 г. (UTC) [ ответ ]
    Вы правы в том, что RfC был специально посвящен ограничению незначительных правок, а не удалению полностью, но я имел в виду, что многие из возражений против них также применимы к предложению об их полном удалении, поэтому я не вижу, что достижение консенсуса . -  ⊥ɥǝ  Ǝɐɹʍıƃ  ( ʇɐlʞ ) 00:45, 1 апреля 2021 г. (UTC) [ ответ ]
    Избиратели, возможно, не приняли во внимание преимущества подлинного упрощения на этот раз, учитывая, что ничего не было предложено. - Троватор ( разговор ) 00:47, 1 апреля 2021 (UTC) [ ответ ]
    Учитывая, что заголовок был «Отключить мелкие правки», я сомневаюсь в этом. Тол | Обсуждение | Contribs (ранее Twassman) 01:03, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка В, то А . Как я сказал в другом RFC, в настоящее время он так же полезен, как и злой бит . Смысл флажка второстепенного редактирования состоит в том, чтобы сказать «вы можете спокойно игнорировать это изменение»; пока вандалы, спамеры и "что делает эта кнопка?" типы могут его использовать, "мелкие" правки все еще нуждаются в проверке. Для новых пользователей это будет на одну вещь меньше, о которой нужно беспокоиться, и на одну вещь меньше, на которую будут кричать за неправильное использование. Suffusion of Yellow ( разговор ) 00:34, 1 апреля 2021 (UTC) [ ответ ]
    • Мне кажется, что это веская причина полностью удалить эту концепцию, а не ограничивать круг лиц, которые могут ее использовать. - Троватор ( разговор ) 00:42, 1 апреля 2021 (UTC) [ ответ ]
      • В самом деле, я бы тоже поддержал это. Но в другом RFC эта идея встретила серьезную оппозицию, поэтому давайте по крайней мере удалим ее, чтобы пользователи, скорее всего, были спамерами, вандалами или невежественными. Suffusion of Yellow ( разговор ) 00:49, 1 апреля 2021 (UTC) [ ответ ]
        • Мех, не могу радоваться этому. Если концепция бесполезна, удалите ее. Если мы не собираемся его удалять, то, поскольку я все равно проигнорирую его, мне все равно, кто может его использовать. - Троватор ( разговор ) 00:52, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка B, затем A Johnbod ( разговор ) 00:39, 1 апреля 2021 г. (UTC) [ ответ ]
  • Поддержите A, выступите против B согласно моим аргументам в предыдущем RfC. Я не сторонник расширения сферы действия EC, если это означает лишение прав автоматически подтвержденных пользователей. Порог EC слишком высок для такой незначительной функции (без каламбура), как эта. -  ⊥ɥǝ  Ǝɐɹʍıƃ  ( ʇɐlʞ ) 00:53, 1 апреля 2021 г. (UTC) [ ответ ]
  • Вариант A / B (в качестве инициатора запроса): новые пользователи часто злоупотребляют или неправильно используют незначительные правки, и это может ограничить эту функцию для пользователей, которым можно доверять, чтобы не злоупотреблять ею. Тол | Обсуждение | Contribs (ранее Twassman) 01:09, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка 0, категорический противник B : Я был шокирован, когда узнал, что обсуждение VPR, которое я мысленно отложил как «какая-то странная дискуссия между людьми с необычными мнениями, которая, вероятно, не выдерживает критики», пришла сюда, и я сначала подумал, что это первоапрельский RfC, который не был должным образом помечен. Я неохотно могу признать аргумент в пользу автоподтверждения (отбирает некоторых, но не всех людей с активно отрицательным количеством подсказок), но в целом считаю, что пример чрезмерной бюрократии в терроризме спамеров и вандалов, уносящих несовершеннолетних, полезная и по большей части несложная функция. Ограничение расширенным подтвержденнымвне пародии - знаете ли вы, как 500 правок звучат для того, кто не входит в Википедию? Мы используем расширенную подтвержденную защиту в качестве последнего средства для наиболее спорных и оскорбительных статей, чтобы убедиться, что они редактируются только людьми, которые слишком глубоко углубились, чтобы продолжать ее. Я не вижу смысла ограничивать что-либо заинтересованными участниками (B) или пациентом (A), что вполне можно лучше объяснить, заменив «Это [[тонкая ссылка | незначительное редактирование]]» на «Это второстепенное. edit [[менее тонкая ссылка | (когда ставить отметку в этом поле)]] ". Ватицидальный пророк 01:12, 1 апреля 2021 г. (UTC) [ ответ ]
    Кроме того, должно ли быть уведомление о списке наблюдения? Ватицидальный пророк 01:15, 1 апреля 2021 (UTC) [ ответ ]
    Я бы понял вашу точку зрения, если бы эта функция имела прямую выгоду для пользователя . Но (как и при автоматическом патрулировании) это может принести пользу другим людям . Каким образом удаление пострадает от нерасширенного подтвержденного пользователя ? Suffusion of Yellow ( разговор ) 01:21, 1 апреля 2021 (UTC) [ ответ ]
    Автоматическое патрулирование, не приносящее пользы конечному пользователю, - это то, что я всегда находил больше сказанным, чем правдой - наличие страниц, проиндексированных Google (и, соответственно, в верхней части для большинства предметов), действительно является преимуществом для автора страницы, поскольку это означает их работы будут просмотрены. Точно так же я не верю, что мелкие правки полезны только для других людей либо в самом прямом смысле «для редактора, напрямую, в пустоте», либо в смысле «редактор такими, какие они есть на самом деле, взаимодействуя с другими людьми» ( например, это очень важно задолго до того, как кто-то попадет в расширенный-подтвержденный, если у них есть 10% мелких правок или 90%). Даже в том смысле, что «один человек - остров», возможность помечать свои собственные изменения полезна для персональной категоризации и отслеживания. Я хотел бы перевернуть позицию, которую вы здесь представляете, чтобы ограничить мелкие правки,особенно, чтобы ограничить их только людьми с количеством правок, которое кажется абсолютно безумным для людей, которые сами не являются плодовитыми редакторами Википедии, на мой взгляд, потребуетгораздо более серьезные злоупотребления, чем я видел на практике или которые вы предлагаете. «Это должно быть возможно только для 0,1375% людей, присоединившихся к Википедии » - предложение, которое не должно происходить без серьезной причины. Ватицидальный пророк 01:30, 1 апреля 2021 г. (UTC) [ ответ ]
  • Поддержка B / A Поддержка B, но не возражает против A. Часто есть пользователи (часто новички), которые используют незначительные правки для вещей, которые, по их мнению, являются незначительными изменениями, но не незначительными правками Википедии . WikiVirus C (обсуждение) 01:48, 1 апреля 2021 г. (UTC) [ ответ ]
  • Вопрос: Что делать, если я вообще не хочу ограничивать мелкие правки? -  JohnFromPinckney ( разговор ) 01:50, 1 апреля 2021 г. (UTC) [ ответ ]
    • Тогда вы скажете «Вариант 0» и составите собственное предложение по такой теме, я думаю. Aza24 ( обсуждение )
  • Противостоять B Нет никакого реального предпочтения по A или 0. - U w U wug's this? 02:21, 1 апреля 2021 г. (UTC) [ ответ ]
  • Поддержите B как первый вариант, A как второй вариант. Чаще всего мелкие правки используются новичками, впервые изучающими Википедию, вандалами, спамерами и sockpuppets, что делает эту концепцию бесполезной по отношению к пользователям, не прошедшим автоподтверждение. Поскольку с автоподтверждением так легко играть, и маловероятно, что новый пользователь поймет суть к этому моменту, мы должны ограничить незначительные правки только теми, кто понимает, что они из себя представляют и какова их цель. Ураган на Яве, 04:03, 1 апреля 2021 г. (UTC) [ ответ ]
    Являются ли "большинство" использования мелких правок злонамеренными? Требуется ли месяц и 99,8625-й процентиль количества изменений, чтобы узнать что-то, что можно узнать, щелкнув ссылку, полученную из «незначительного редактирования»? Являются ли незначительные правки столь же спорными, как статьи об интенсивных глобальных политических спорах, нашим основным вариантом использования для ограничения действия 99,8625-го процентиля редакторов? Ватицидальный пророк 06:47, 1 апреля 2021 г. (UTC) [ ответ ]
    Я уже довольно давно занимаюсь RCP и контр-LTA действиями, поэтому осмелюсь предположить, что в большинстве случаев второстепенная метка используется либо злонамеренно, либо для тестирования, либо для отката тестов и вандализма. И да, мне потребовалось столько времени, чтобы полностью понять концепцию мелких правок. Ураган на Яве, 08:13, 1 апреля 2021 г. (UTC) [ ответ ]
    Если вы работаете в той части проекта, которая имеет дело с худшими правками, вы сопоставите по шаблону худшие правки со всем. Это не означает, что большинство мелких правок плохие, это означает, что большинство мелких правок, с которыми вы лично сталкиваетесь, плохие. Я не видел никаких аргументов в пользу внесения незначительных изменений, более ограниченных, чем фактический откат (любой автоподтвержденный пользователь может установить Twinkle), или даже столь же ограниченных, как это не похоже ни на то, ни на "тогда мы должны сделать ссылку на Help: Мелкие правки более очевидны »или« тогда не следует фильтровать мелкие правки в своем списке наблюдения ». (Я лично обращаю внимание на каждую разницу в статьях о списках наблюдения, которые меня больше всего волнуют, включая Amantio, использующий AWB поверх этогов случае, если за ними скрывается плохая правка.)Ватицидальный пророк 19:58, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержите B, затем A на насыщение желтого цвета. ProcrastinatingReader ( обсуждение ) 13:33, 1 апреля 2021 (UTC) [ ответ ]
  • Вариант 0 . Какую проблему это пытается решить? Спасибо. Майк Пил ( разговор ) 14:50, 1 апреля 2021 (UTC) [ ответ ]
  • Против B - Редакторы должны познакомиться с системой итогового редактирования задолго до 500 правок. Любой, кто очень обеспокоен отсутствием чего-либо из-за того, что это помечено как незначительное, может просто перестать фильтровать это из своего списка наблюдения. -  Godsy  ( TALK CONT ) 15:08, 1 апреля 2021 (UTC) [ ответить ]
  • Процедурное противодействие B, если это приведет к удалению этой возможности у администраторов или ботов ( @ Tol : это не входит в ваши намерения, не так ли?). - Обсуждение xaosflux 15:13, 1 апреля 2021 г. (UTC) [ ответ ]
    @ Xaosflux : Нет, я должен был прояснить это. Вариант B не удаляет эту возможность у администраторов или ботов. Я имел в виду удаление незначительных правок от пользователей-людей, которые не прошли расширенное подтверждение (боты не являются людьми, а администраторы в какой-то момент были XC). Тол | Обсуждение | Contribs (ранее Twassman) 19:18, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка A или B Я также видел, как злоумышленники злоупотребляли этой функцией. Цель этой функции - позволить незначительным изменениям, внесенным доверенными редакторами, быть менее заметными в списках наблюдения, а не в качестве привилегии для определенных редакторов. На мой взгляд, добавление требования к активности до его появления сделало бы эту функцию более полезной для тех, кто просматривает изменения. ( t · c ) buidhe 15:21, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка чего-то между B и A Изначально я собирался просто поддерживать B, но, как указано выше Годси, редакторы Википедии должны ознакомиться со сводкой редактирования до 500 правок, но становятся автоматически подтвержденными (насколько мне известно, я не совсем уверен ) легко сделать. Однако я полностью против Варианта 0, потому что любой пользователь может зарегистрировать учетную запись, а затем осквернить статью, пометив ее как незначительную. Следует отметить, что не все вандалы являются редакторами IP. Поэтому я думаю, что если бы мы сделали что-то между A и B (может быть, полуавтоматическое подтверждение или, возможно, отдельная вещь, предназначенная только для незначительных правок), то вандалам все равно было бы труднее делать то, что они делают лучше всего, не усложняя это навсегда пользователям вносить незначительные правки. Появился Дикий Волк! | Поймай их всех!( разговор ) 15:29, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка B, затем A. Я лично считаю, что каждый пользователь использует мелкие правки по-разному, но только с пользователями WP: ECP , будет ли вообще заметная закономерность. Пользователи, не использующие ECP, по определению, в любом случае будут иметь менее 500 правок. Shushugah ( talk ) 15:41, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка 0 - я смутно помню, как участвовал в предыдущем RfC, но это тот случай, когда то, что логически имеет смысл (либо A, либо B), на самом деле не имеет. Один из лучших "подсказок" RCP - неправильное использование мелких правок. Это значительно повышает эффективность, и уже одно это заставляет меня предпочитать "как есть". Nosebagbear ( разговор ) 16:04, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержите 0 с A как очень отдаленный второй вариант. Несмотря на все обсуждения здесь и в предыдущем обсуждении, я никогда не был уверен, что существует проблема, которую нужно исправить здесь, или что предлагаемые изменения действительно исправят ситуацию. Проблемы, с которыми сталкиваются люди, связаны с поведением пользователей, и ограничение использования функции второстепенного редактирования не решит этого. Тридуульф ( разговор ) 16:25, 1 апреля 2021 (UTC) [ ответ ]
  • Поддержка 0 В качестве детектора носков и вандализма флажок «Мелкие правки» является фантастической приманкой. AdmiralEek ( разговор ) 17:03, 1 апреля 2021 (UTC) [ ответ ]