Модуль обсуждения:Защитный баннер

Неправильная категоризация в Википедии полностью защищенные шаблоны

Расширенно подтвержденные шаблоны в настоящее время ошибочно классифицируются как Категория: Полностью защищенные шаблоны Википедии . В этой категории есть примечание «По техническим причинам эта категория также ошибочно содержит расширенно подтвержденные защищенные шаблоны.», но ни этот комментарий, ни его сводка по редактированию не указывают, что это за «техническое объяснение». Я предполагаю, что этот модуль отвечает за заполнение этой категории? Можно ли объяснить эту причину? (ping @ Mr. Stradivarius , если вы знаете) ProcrastinatingReader ( talk ) 16:52, 28 августа 2020 (UTC) [ ответить ]

@ ProcrastinatingReader : Похоже, модуль нужно исправить, но я пока не уверен, какое именно исправление нужно. У вас есть пример страницы, которая неправильно классифицирована? — Mr. Stradivarius ♪ talk ♪ 00:56, 29 августа 2020 (UTC) [ ответить ]
И да, модуль отвечает за заполнение категории. В частности, список категорий находится в Module:Protection banner/config , примерно на две трети пути вниз. — Г-н Страдивариус ♪ talk ♪ 00:57, 29 августа 2020 (UTC) [ ответить ]
Г-н Страдивариус , примеры: Шаблон:Персонажи Лиги Справедливости , Шаблон:Атаки палестинских боевиков в 1960-х годах , Шаблон:Gs/topics ProcrastinatingReader ( обсуждение ) 01:29, 29 августа 2020 (UTC) [ ответить ]
Очень быстрый взгляд на 30 секунд чтения комментариев в конфигурации, но, возможно, проблема в том, что у нас нет Category:Wikipedia расширенно-подтвержденных защищенных шаблонов , и поэтому она решается по лестнице к полностью защищенным? Полное и окончательное предположение, хотя, вероятно, неверное... ProcrastinatingReader ( обсуждение ) 01:32, 29 августа 2020 (UTC) [ ответ ]
Хм, похоже, Mdaniels работал над чем-то подобным несколько месяцев назад. Я немного подправил конфигурацию sandbox, возможно, это сработает? Не совсем уверен, как проверить, хотя. Я попробовал изменить версию в Template:Palestinian militancy attacks in the 1960s на sandbox v, но это не переопределяет (я предполагаю, что пространство имен шаблона делает что-то вроде автоматического определения, чтобы вставить блокировку, следовательно, переопределяет мою ручную). И на этой ноте, просто интересно, почему существует {{ Pp-extended }} , а не просто используется {{ Pp }} (который используется для всех других защит и, по крайней мере, в исходном коде, кажется, делает то же самое, что и первый?) ProcrastinatingReader ( talk ) 01:47, 29 августа 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Похоже, что ваши правки сработали, и вы правы, нужно просто отредактировать эту таблицу так, чтобы расширенные-подтвержденные-защищенные шаблоны не попадали в случай по умолчанию. Лучший способ проверки — добавить несколько новых тестов в Module:Protection banner/config/testcases . К сожалению, предыдущие редакторы отредактировали конфигурацию, не обновив тестовые случаи, поэтому нам нужно будет исправить и существующие тестовые случаи. Для живого тестирования я рекомендую User:Jackmcbarn/advancedtemplatesandbox.js , который вы можете использовать для проверки песочницы на живых страницах без обновления основного модуля. — Г-н Страдивариус ♪ talk ♪ 01:57, 29 августа 2020 (UTC) [ ответить ]
Этот скрипт удобен, я думаю, что C&C рекомендовал мне его некоторое время назад, но я забыл о нем. Синхронизировал обновление, и оно, похоже, заполняет категорию (ужасно медленно, не совсем уверен, как программное обеспечение решает, когда обновлять категоризацию). Также исправил большинство тестовых случаев. Кстати, очень, очень хорошо документированные модули. Большинство платного кода, с которым я сталкиваюсь, имеют гораздо худшую документацию. Я на самом деле несколько удивлен, что вы не профессиональный разработчик. ProcrastinatingReader ( talk ) 17:16, 29 августа 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Спасибо за обновление модуля и исправление тестовых случаев! Это очень ценно. Я думаю, вам нужен второй дефис в названии категории, хотя: «Wikipedia extended-confirmed protected templates» с одним дефисом переводится как «protected templates that are extended-confirmed» (что бы это ни значило); «Wikipedia extended-confirmed-protected templates» с двумя дефисами переводится как «templates that have extended-confirmed protection», что, я думаю, нам здесь и нужно. — Mr. Stradivarius ♪ talk ♪ 14:08, 30 августа 2020 (UTC) [ ответить ]
Г-н Страдивариус , меня это изменение устраивает. Кстати, я искал полностью защищенную страницу и наткнулся на Category:Wikipedia полностью защищенные страницы . Каждая статья, непосредственно в этой категории, не полностью защищена, что меня немного смутило. Потом я понял, что это перенаправления. Мы, как правило, помещаем перенаправления в Category:Fully protected redirects , в которой 1375 участников. Есть идеи, почему некоторые также/вместо этого попадают в первую категорию, в которой всего 553 участника? Я думаю, это может быть потому, что они также защищены от перемещения (несколько примеров, которые я проверил, также находятся в Category:Wikipedia indefinitely move-protected pages ), но если это так, то, полагаю, нам нужен дополнительный случай конфигурации, чтобы отловить их, чтобы они не попадали в общую категорию. Если моя догадка верна, нам просто нужно изменить случай конфигурации на |all (вместо |edit), или мы хотим создать отдельную категорию для полностью защищенных перемещений?
Мой побочный вопрос: почему модуль добавляет их в несколько категорий? Я знаю, что это хорошее поведение, но какова логика кода, стоящая за этим? Он ищет категорию для каждого типа защиты отдельно (например: редактирование/перемещение проходят через иерархию для категории отдельно)? ProcrastinatingReader ( обсуждение ) 14:18, 30 августа 2020 (UTC) [ ответ ]
После некоторого дальнейшего копания это выглядит как беспорядок (но не со стороны этого модуля). Похоже, что этот модуль не отвечает за категорию полностью защищенных перенаправлений, это делается вручную и категория добавляется шаблонами перенаправлений, такими как {{ R полностью защищено }} . Итак, у нас есть некоторые перенаправления, которые не помечены замком и только в последнем cat, и другие статьи, которые помечены только замком, и, таким образом, только в категории полностью защищенных. Те, которые помечены и шаблоном, и замком, помещаются в оба. Это как бы делает категории отслеживания непоследовательным беспорядком и в результате немного бесполезными, на самом деле. Не уверен, как лучше всего это убрать? Я знаю, что мы можем проверить перенаправление с помощью Lua, поэтому мы всегда можем добавить это, но не уверен, как это повлияет на производительность? Нам, вероятно, понадобится бот, чтобы исправить страницы, подобные той, на которую я ссылался, тоже? ProcrastinatingReader ( обсуждение ) 14:30, 30 августа 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Я внес изменение, чтобы добавить дополнительный дефис, поэтому страницы должны начать медленно фильтроваться в новую категорию. Отвечая на ваш предыдущий вопрос, обновление выполняется очередью заданий , что может быть очень медленным для изменений категории, вызванных редактированием шаблона. Я видел, как это занимало месяцы. Что касается нескольких категорий защиты, этот модуль добавляет только одну категорию защиты на #invoke, но на странице может быть несколько шаблонов защиты, и, как вы обнаружили, есть другие шаблоны, которые также добавляют категории защиты. Чтобы исправить это элегантным способом, нам, вероятно, потребуется создать отдельный модуль для генерации категорий защиты, которые можно будет вызывать из всех различных задействованных шаблонов. — Г-н Страдивариус ♪ talk ♪ 15:04, 30 августа 2020 (UTC) [ ответить ]
Господин Страдивариус , хм, в этом случае что добавляет блокировку (в режиме чтения)? И почему эта штука не добавляет блокировку здесь? Они выглядят довольно похожими на меня? ProcrastinatingReader ( talk ) 15:07, 30 августа 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Это оболочка Template:Rcat , которая вызывает Template:pp-protected на основе уровня защиты от редактирования. — Г-н Страдивариус ♪ обсуждение ♪ 15:14, 30 августа 2020 (UTC) [ ответить ]
Господин Страдивариус , я понимаю. Разве не самый простой способ очистить это, просто удалив из {{ Rcat shell }} ? Тогда он будет вызывать только {{ Rfully protected }} , что добавляет нужную категорию. Единственной проблемой будет отсутствие блокировки, но мы можем это исправить, добавив в {{ Rfully protected }} что-то вроде: . ProcrastinatingReader ( talk ) 15:35, 30 августа 2020 (UTC) [ ответить ]{{pp-protected|small=yes}}{{pp|small=yes|category=no}}
Нет, не удаляйте его. Это сведет на нет работу, проделанную мной и другими (например, Пейном Эллсвортом ) за последние несколько лет, чтобы попытаться исключить использование специальных шаблонов, которые применяются только к определенному уровню защиты. Поэтому, когда страница имеет, она не должна также иметь никаких других шаблонов защиты, даже или подобных. Дело в том , что он автоматически определяет уровень защиты и не нуждается в настройке, когда страница повышается с полузащиты до полной защиты и т. д. Если вы обнаружите страницу (перенаправление или иное) в «неправильной» категории защиты, сначала примените WP:NULLEDIT и посмотрите, решит ли это проблему. -- Red rose64 🌹 ( talk ) 09:28, 31 августа 2020 (UTC) [ ответить ]{{rcat shell}}{{r protected}}{{pp-protected}}
Redrose64 , они находятся в неправильных категориях из-за встроенной ошибки в шаблонах. Редактирование null не решит проблему (кроме того, я не могу редактировать null полностью защищенную страницу). Пожалуйста, см. обсуждение выше. Изменение, которое я предложил, не должно бросать вызов вашим усилиям. {{ r protected }} учитывает и другие уровни защиты, поэтому перемещение {{ pp }} туда для этого случая не приведет к каким-либо негативным последствиям, насколько я могу судить. Если вы видите что-то, чего не вижу я, пожалуйста, объясните. Для ясности, я предлагаю переместить его только для случая полной защиты (который обязательно вызывает {{ r protected }} , поэтому это не приводит к каким-либо упущениям). Я не вижу абсолютно никаких сценариев, в которых это пойдет не так? Например, см. песочницы. ProcrastinatingReader ( talk ) 20:17, 31 августа 2020 (UTC) [ reply ]
Ну, PR , похоже, вы затронули старую проблему, которую мы замечаем и пытаемся исправить уже несколько лет. Только на этой странице обсуждения она восходит как минимум к 2016 году, когда {{ Redirect category shell }} был шаблоном {{ This is a redirect }} . Эта проблема касается не только Extended-confirmed-protected, но и других, таких как перенаправление {{ -r }} , которое защищено шаблоном. Похоже, что у этой проблемы так много слоев, что некоторые действительно хорошие администраторы и редакторы шаблонов, а также эксперты Lua пытались исправить ее, а затем, по-видимому, откладывали ее, чтобы заняться более серьезными проблемами, которые возникали. Это действительно крепкий орешек, поэтому я бы не возлагал надежд на решение в ближайшее время. Однако я сам надеюсь, что в конечном итоге она будет хорошо решена. PI Ellsworth   ed.  put'r there  12:01, 1 сентября 2020 (UTC)[ отвечать ]

Paine Ellsworth , вы видите какие-либо недостатки в моем предложенном решении? Очевидно, что это повлияет только на нишевый случай полностью защищенных перенаправлений с использованием одного из двух шаблонов (не других, которые останутся такими же сломанными, как и сейчас), но поскольку я не вижу, чтобы это вызывало какие-либо проблемы в этом случае, я думаю, что мое решение лучше, чем ничего, и, по крайней мере, оно сделало бы полностью защищенную категорию менее бесполезной для других целей. Отметив, что оболочка обязательно вызывает {{ r protected }} , я думаю, что это легко решаемый случай. ProcrastinatingReader ( talk ) 12:08, 1 сентября 2020 (UTC) [ ответить ]

Похоже, вы пытаетесь удалить шаблон {{ pp-protected }} из оболочки, изменив таким образом:
{{#переключатель: {{PROTECTIONLEVEL:редактировать}} |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}} |templateeditor={{pp-protected|small=yes}}{{Шаблон R защищен|embed=yes}} |extendedconfirmed={{pp-protected|small=yes}}{{R extended-protected|embed=yes}} |autoconfirmed={{pp-protected|small=yes}}{{R полузащищенный|embed=yes}}
к:
{{#переключатель: {{PROTECTIONLEVEL:редактировать}} |sysop={{R защищен|embed=yes}} |templateeditor={{pp-protected|small=yes}}{{Шаблон R защищен|embed=yes}} |extendedconfirmed={{pp-protected|small=yes}}{{R extended-protected|embed=yes}} |autoconfirmed={{pp-protected|small=yes}}{{R полузащищенный|embed=yes}}
это правильно? И затем, чтобы вернуть значок замка, который будет потерян, вы предлагаете вставить шаблон {{ pp-protected }} в шаблон {{ R fully protected }} rcat? Куда именно вы его вставите? PI Ellsworth   ed.  put'r there  12:38, 1 сентября 2020 (UTC) [ ответить ]
Paine Ellsworth, это верно. По вашему вопросу см. Template:R полностью защищен/песочница. Обе песочницы обновлены с изменением, которое я предлагаю.
(второй вариант — оставить оба шаблона как есть, но просто добавить |category=no в оболочку. Это работает так же, чтобы исправить нашу проблему категоризации, но поскольку в настоящее время половина полностью защищенных перенаправлений не используют оболочку, они не имеют блокировки. Я думаю, что вышеприведенный подход лучше, так как у нас есть блокировка во всех случаях, а также исправление категоризации). ProcrastinatingReader ( обсуждение ) 19:43, 1 сентября 2020 (UTC) [ ответ ]
Как и вы, PR , я не могу протестировать ваши изменения на полностью защищенных перенаправлениях; однако я могу протестировать изменения на перенаправлениях, защищенных шаблонами, и обнаружил, что они удаляются из шаблонов Category:Wikipedia template-protected при использовании {{ Redirect category/sandbox }} . Это наводит меня на мысль, что ваши изменения выполнят то, что вы хотите. Одна из проблем заключается в том, что ваши изменения не удалили перенаправление, защищенное шаблонами, из полностью защищенных страниц Category:Wikipedia , и это одна из наших главных проблем. Поэтому ваше решение вполне может быть хорошим частичным исправлением (которое потребует тестирования администратором для подтверждения); однако оно не решает другие важные проблемы, которые у меня есть с неправильной и ненадлежащей категоризацией, о которых я уже упоминал в другом месте на этой странице обсуждения. PI Ellsworth   ed.  put'r there  10:18, 2 сентября 2020 (UTC) [ ответить ]
Спасибо за тестирование, Paine Ellsworth . Проблема, которую вы отметили, к сожалению, не будет исправлена ​​этими изменениями, поскольку эта модификация, примененная к перенаправлениям TE, не будет работать таким же образом. Я полагаю, что для этого потребуется новое правило в модуле и некоторые изменения в шаблонах, но я не изучал случай перенаправлений TE подробно, поэтому предлагаю только изменение для случая полностью защищенного перенаправления. Возможно, позже рассмотрю другие случаи. Проблемы в других случаях также должны стать более очевидными, как только полностью защищенный кот не будет засорен ерундой.
Я протестировал свои изменения на Alissa (полностью защищенное перенаправление) с помощью скрипта templatesandbox, предложенного выше, и он правильно классифицирует это перенаправление. Если какие-либо администраторы захотят провести дальнейшее тестирование на живом перенаправлении, изменив его на sandbox, это было бы здорово. В противном случае, я думаю, есть достаточно доказательств, чтобы сделать это относительно прямолинейное изменение в ближайшие дни, если не будет возражений по техническим деталям. ProcrastinatingReader ( обсуждение ) 11:38, 2 сентября 2020 (UTC) [ ответ ]
Пожалуйста, ProcrastinatingReader ! Да, было бы очень полезно, если бы администраторы, которые работали над этим, протестировали перенаправления FP с изолированным кодом. Другой вопрос, который у меня есть, заключается в том, что, по-вашему, произойдет, если вместо размещения {{pp|small=yes|category=no}}в {{ R полностью защищенном }} rcat, какая будет разница, если мы просто добавим |category=noпараметр в существующий шаблон {{ pp-protected }} (который, конечно, перенаправляет на шаблон {{ pp }} ) в оболочке {{ Rcat }} ? Это даст тот же результат? Или вы думаете, что будут другие результаты? PI Ellsworth   ed.  put'r there  12:14, 2 сентября 2020 (UTC) [ ответить ]
Paine Ellsworth , с точки зрения категоризации это был бы точно такой же результат. Однако многие полностью защищенные перенаправления не используют оболочку, а вместо этого используют только {{ R полностью защищено }} . В результате у них нет значка замка в правом верхнем углу. Я думаю, что предложенный подход также исправит эту «ошибку» (если хотите), добавив замок и в этих случаях, и я думаю, что замок должен быть там, поэтому мои первоначальные мысли были о том, что это лучший подход. Поскольку вы (и другие) занимались этой проблемой в течение более длительного периода времени, чем я, мне было бы интересно услышать ваши мысли по этому поводу. ProcrastinatingReader ( обсуждение ) 12:33, 2 сентября 2020 (UTC) [ ответ ]
Я бы поддержал добавление шаблона pp в полностью защищенный rcat в качестве временного решения, а также поддержал бы добавление |category=noпараметра в оболочку для всех шаблонов защиты в оболочке. Можно также добавить шаблон pp в {{ R template-protected }} , {{ R extended-protected }} и {{ R semi-protected }} , поскольку при их использовании без оболочки они тоже не добавляют блокировку в верхнюю часть страницы перенаправления.
Лучшим решением в долгосрочной перспективе может быть поиск ботом всех защищенных перенаправлений и замена защитных rcats на оболочку rcat; однако некоторые редакторы могут жаловаться, если другие соответствующие rcats не будут также добавлены для оправдания использования оболочки. И это не может быть облегчено ботом. Это пришлось бы делать вручную, что потребовало бы целой армии Wikignomes. < вздох > PI Ellsworth   ed.  put'r there  13:29, 2 сентября 2020 (UTC) [ ответить ]
Я также рассмотрю эти шаблоны, когда у меня появится возможность, чтобы подтвердить, что это также не приведет к неблагоприятным последствиям. Я согласен, что нам нужно лучшее решение, чтобы действительно решить все компоненты этой проблемы. Я поднял идею бота выше. Проблема в том, что никто из нас не может управлять ботом (для редактирования полностью защищенных перенаправлений нужен adminbot). Не уверен, что у многих активных администраторов есть опыт и интерес в этой области, поэтому, если вы не хотите ввести RfA и управлять им, я думаю, что вопрос о боте спорный. WikiGnomes (даже если это возможно с точки зрения логистики) не поможет по той же причине, полностью защищенные запросы на редактирование обрабатываются вечность (и я видел только 1 или 2 администраторов, которые активно ими занимались). Маловероятно, что 1000 из них будут выполнены. Даже если бы они могли, это вдвое больше времени, затрачиваемого на одно перенаправление (время предлагающего + время администратора-проверяющего). ProcrastinatingReader ( обсуждение ) 15:01, 2 сентября 2020 (UTC) [ ответить ]

Защищено движением

Г-н Страдивариус , что вы думаете о том, что делать со страницами, защищенными от перемещения, на уровень, не относящийся к системному оператору? В настоящее время они просто по умолчанию переходят вверх по цепочке в Category:Wikipedia полностью защищенные страницы . Я видел тестовый пример для этого, который не сработал, поэтому я сделал Special:Diff/976938143 , но на самом деле это кажется неправильным. Не совсем имеет смысла классифицировать TE, защищенные от перемещения, в TE. У нас есть категории для защиты перемещения системного оператора, например ['all|template|all|sysop|move'] = 'Wikipedia move-protected templates', , но на самом деле нет ни одной для меньшей защиты перемещения, и кажется несколько глупым иметь «шаблоны Wikipedia template-editor move-protected»? Поэтому не уверен, какое решение будет здесь лучшим. ProcrastinatingReader ( обсуждение ) 19:11, 6 сентября 2020 (UTC) [ ответ ]

Почему бы не ввести отдельное дерево категорий для защиты от перемещения? Из Wikipedia:Move protection неясно, сколько существует различных уровней защиты от перемещения, кроме полностью защищенных от перемещения страниц . Другие важные биты:
  • Страницы, полностью защищенные от редактирования, также неявно защищены от перемещения.
  • Все файлы неявно защищены от перемещения; перемещать файлы могут только лица, занимающиеся перемещением файлов, и администраторы.
—⁠ andrybak ( обсуждение ) 21:38, 6 сентября 2020 (UTC) [ ответить ]
  • Я думаю, что в теории вы можете переместить защиту на все уровни, но в большинстве случаев не-sysop move-protect, не совпадающая с edit protection, — довольно редкий сценарий. Это случается на некоторых страницах mainspace (обычно для перемещения ECP), есть пара шаблонов, которые имеют это (edit=semi, move=TE). Я думаю, что многие из них являются действиями IAR, а не кодифицированы в руководствах, но тем не менее это разумная защита. Дерево категорий перемещения — это одна из идей, да, и ее не так уж сложно реализовать, по крайней мере, в модуле. Есть куча разбросанных шаблонов, которые также нужно будет перепроверить. Стоит отметить, что если бы мы это сделали, то такие вещи, как Category:Wikipedia move-protected templates, вероятно, должны были бы быть cat, содержащим только дочерние cats, поэтому нам нужно было бы убедиться, что никакие боты не будут этим обеспокоены. ProcrastinatingReader ( talk ) 22:02, 6 сентября 2020 (UTC) [ ответить ]
( конфликт правок ) Редактору ProcrastinatingReader : Я бы также хотел услышать мысли от Red rose64 , Martin , Anomie⚔ , wbm1058 , xaosflux и Jackmcbarn , которые были бы полезны по этому вопросу. Как «крепкий орешек», мы нуждаемся во всей помощи, которую можем получить. PI Ellsworth   ed.  put'r there  21:48, 6 сентября 2020 (UTC) [ ответить ]
@ Andrybak : Защита от перемещения имеет точно такие же пять уровней, как защита от редактирования, загрузки и создания, то есть отсутствует, полузащищенный, EC, шаблон и полный. Однако, поскольку IP-адреса и неподтвержденные редакторы не могут перемещать страницы, страница без защиты от перемещения фактически полузащищена для перемещений. Редко бывает страница, которая явно полузащищена для перемещений, но не имеет защиты от редактирования; это обычно ошибки, и при обнаружении их часто сводят к отсутствию защиты от перемещения ради аккуратности. -- Red rose64 🌹 ( talk ) 11:10, 7 сентября 2020 (UTC) [ ответить ]

Скрипты пользовательского пространства

У нас много кошачьего загрязнения, когда кто-то добавляет скрипт пользовательского пространства и вставляет // {{pp-template}}или что-то в свои файлы css/js, вызывая золотую блокировку и защищенную системным оператором категоризацию (например, User:GoldenRing/common.js , User:BeywheelzLetItRip/common.css , User:AHollender (WMF)/sandbox/2019–20 coronavirus pandemic data/2019–20 coronavirus pandemic data/styles.css и т. д.). Вместо того, чтобы IAdmins постоянно удаляли этот материал, возможно, было бы хорошей идеей для этого модуля просто не показывать блокировку или категоризацию (по сути, просто пропускать) любые файлы .js/.css в пользовательском пространстве (которые все защищены IAdmin, глобально)? ProcrastinatingReader ( обсуждение ) 22:15, 6 сентября 2020 (UTC) [ ответ ]

Сделано в песочнице, если кто-то хочет взглянуть. ProcrastinatingReader ( обсуждение ) 22:38, 6 сентября 2020 (UTC) [ ответить ]
Я посмотрел на код. В целом он выглядит хорошо — спасибо за вклад. :) Есть пара вещей, которые я бы изменил:
  • Вместо того, чтобы иметь код в Protected:isProtected(), я бы поместил его прямо в Protection:makeCategoryLinks(), или, может быть, лучше, поместил бы его в выделенный Protection:shouldBeCategorized()метод и вызывал бы его из makeCategoryLinks. Говорить, что пользовательские страницы .js или .css не защищены, когда они фактически защищены, немного сбивает с толку, и я думаю, что перемещение кода сделало бы намерение более явным и, возможно, позволило бы избежать будущих ошибок.
  • Это можно сделать с помощью некоторых тестовых случаев в Module:Protection banner/testcases .
Лучший — Mr. Stradivarius ♪ talk ♪ 15:32, 7 сентября 2020 (UTC) [ ответить ]
Г-н Страдивариус , спасибо за отзыв! Re bullet 1: Я вставил его :isProtected(), чтобы также остановить показ блокировки, а также остановить категоризацию, так как я думал, что показ золотой блокировки сисопа для этих типов файлов кажется немного вводящим в заблуждение и нежелательным. Также показалось хорошей идеей поместить их в «неправильные категории» cat, чтобы удалить их // {{pp-template}}, показалось хорошей идеей. Самый простой способ достичь всех пунктов — отредактировать :isProtected(). Конечно, открыт для мыслей о том, нежелательны ли какие-либо из этих исправлений сами по себе. ProcrastinatingReader ( talk ) 16:11, 7 сентября 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Понятно — если нам нужно также подавить значки замков, то я согласен, что :isProtected()это очень удобное место для добавления кода. Я думаю, что проблема заключается только в именовании, с чем я пытался справиться в песочнице. Я не смог придумать хорошее имя для метода, который означает «шаблон должен выводить категорию защиты и значок баннера/замка», поэтому я схитрил, создав псевдоним. Вероятно, есть лучший способ сделать это. Кроме того, я исправил тестовые случаи, которые, казалось, были сломаны в течение довольно долгого времени. — Г-н Страдивариус ♪ talk ♪ 14:24, 8 сентября 2020 (UTC) [ ответить ]
Господин Страдивариус , мне кажется, он хорош! ProcrastinatingReader ( обсуждение ) 19:27, 9 сентября 2020 (UTC) [ ответить ]
Господин Страдивариус , это хорошо для слияния в прямом эфире? ProcrastinatingReader ( обсуждение ) 19:08, 15 сентября 2020 (UTC) [ ответить ]
@ ProcrastinatingReader : Пока нет — отсутствуют некоторые тестовые случаи, и я заметил пограничный случай, который должен охватывать пользовательский код JS/CSS (т. е. пользовательские страницы имеют тип содержимого JS/CSS только в том случае, если они являются подстраницей; User:Foo.cssэто будет страница викитекста). — Г-н Страдивариус ♪ обсуждение ♪ 00:20, 16 сентября 2020 (UTC) [ ответ ]
Интересно. Технически эти страницы тоже могли бы быть CSS, если бы их вручную изменить. Лучший способ проверить все — использовать contentModel, я думаю, но это «возможно, дорогая функция»; проверка заголовка страницы, вероятно, справится с 99,9% случаев. ProcrastinatingReader ( talk ) 09:54, 16 сентября 2020 (UTC) [ ответить ]
Использование модели контента не должно быть проблемой, поскольку мы будем делать только один дорогой вызов функции. И я предполагаю, что результат будет кэшироваться на каждой странице, так что, вероятно, все равно будет только один дорогой вызов функции, даже если у нас будет несколько #invokes на странице. — Mr. Stradivarius ♪ talk ♪ 04:19, 19 сентября 2020 (UTC) [ ответить ]
Кроме того, проверка документации показывает, что извлечение модели контента для текущей страницы не учитывается при подсчете затратных функций, поэтому на самом деле не должно иметь никакого эффекта. — Г-н Страдивариус ♪ talk ♪ 07:18, 19 сентября 2020 (UTC) [ ответить ]
Я только что выложил код в открытый доступ — дайте мне знать, если заметите какие-либо проблемы. — Г-н Страдивариус ♪ talk ♪ 13:07, 19 сентября 2020 (UTC) [ ответить ]
Г-н Страдивариус , сейчас выглядит хорошо. Мне интересно одно. Я знаю, что категории не обновляются с содержимым немедленно, но я думал, что очистка с forcerecursivelinkupdate на странице немедленно обновила это? Попробовал на паре, но они не исчезают из Category:Wikipedia полностью защищенных страниц по какой-то причине - есть идеи? ProcrastinatingReader ( обсуждение ) 18:33, 19 сентября 2020 (UTC) [ ответ ]
Он не работал месяцами, если не дольше: см. Wikipedia:Village pump (technical)/Archive 181#Sending a POST to the API to purge . -- Red rose64 🌹 ( talk ) 21:45, 19 сентября 2020 (UTC) [ ответить ]

Перенаправление подкатегории

Категория: Полностью защищенные перенаправления немного бесполезна для целей обслуживания, потому что у нее 1500 членов без подкатегорий. В идеале это должно быть разделено, например, перенаправления альтернативного имени BLP, перенаправления, защищенные из-за вандализма, перенаправления проекта, защищенные превентивно и т. д. Кратко обсуждавшиеся выше в Module_talk: Protection_banner#Categorization_of_protected_redirects, г-н Страдивариус дал 3 варианта, которые, по моему мнению, являются лучшими. Я думаю, это можно легко сделать с помощью этого модуля. Мы могли бы создать кучу оберток и обойти именованную оговорку, добавив проверку заголовка для isRedirect, если обертка предназначена для перенаправления (вероятно, самый простой вариант). Они использовали бы ключ reason. Это также оставило бы открытыми параметры для каждого пространства имен, но мы не смогли бы использовать обычные данные баннера (это можно было бы обойти, имея суффикс -redirect в reason для cat, но извлекая данные из parent для lock). Есть также вариант 3 создания ключа перенаправления в алгоритме, но это, возможно, потребует некоторой работы (г-н С или Джек, возможно, знают лучше). ProcrastinatingReader ( обсуждение ) 14:53, 7 сентября 2020 (UTC) [ ответ ]

Обновлять

Составив небольшой список «проблем» категории защиты, не стесняйтесь добавлять/изменять. Думаю, мы сможем найти решения оттуда. Пейн Эллсворт может быть заинтересован? Относительно перенаправлений, я знаю, что г-н Страдивариус выше предложил идеи Добавить обнаружение перенаправлений как полноценный ключ к алгоритму категории защиты или новый модуль для работы с перенаправлениями. У меня также была идея добавить суффикс -redirect к причине. Я думаю, что подход с добавлением к алгоритму является лучшим, проблема перекрывается с неперенаправлениями, и я думаю, что это проще, чем иметь почти дублирующий модуль. Однако я думаю, что также может быть лучше сократить наши потери, сосредоточиться на исправлении и иметь категоризации, основанные в основном на уровне защиты и продолжительности (indef/temp), и предложить Petscan, если кто-то хочет извлечь из них полезную информацию. Например, чтобы выяснить расширенные подтвержденные защиты НЕ DS, можно использовать «не имеет шаблонов» на странице обсуждения «ArbCom Arab-Israeliforcement» + [...]. ProcrastinatingReader ( обсуждение ) 17:20, 26 сентября 2020 (UTC) [ ответить ]

В обоих случаях есть некоторые проблемы:

  • Категория: Страницы Wikipedia, защищенные от перемещения, должны уметь обрабатывать неадминистративную защиту перемещения (в настоящее время они просто переходят в полностью защищенный cat). Но поскольку каждый запуск модуля категоризирует только один раз, я думаю, что потребуется полностью изменить структуру дерева категорий (как и стандартные защиты), чтобы это работало гладко? Или мы можем просто смешать все в одну защищенную от перемещения категорию на уровень защиты (отбросить пространство имен) и предложить Petscan для категоризации пространства имен (вероятно, самый простой вариант?)
  • Категория: защищенные биографии живых людей Википедии неэффективна, и поэтому она (и ее подкатегории) почти пусты. Администраторы редко используют {{ pp-blp }} , Twinkle просто добавляет {{ pp-30-500 }} , например, Сушант Сингх Раджпут , с причиной защиты, обычно включающей «Нарушения политики биографий живых людей» (но не всегда). Несколько вещей, которые может сделать бот, но я отмечаю, что Petscan также может быть использован для той же цели, так что мы просто хотим выбросить {{ pp-blp }} и вместо этого классифицировать только по уровню защиты? Кажется, что это, по крайней мере, используется для полузащиты, но мне интересно, сколько полузащит просто смешано в других кошках, например, Категория: полузащищенные страницы Википедии (много, на первый взгляд). Аналогичная проблема с Категория: расширенные-подтвержденные-защищенные страницы Википедии .
Редактору ProcrastinatingReader : да, я очень заинтересован и внимательно за всем этим слежу. Многое из этого, кажется, выше моего уровня оплаты и кругозора, но я все равно читаю и смотрю, надеясь, что это будет решено теми, кто знает больше меня об этих вещах. PI Ellsworth   ed.  put'r there  15:57, 27 сентября 2020 (UTC)[ отвечать ]

Катонли

@ Mr. Stradivarius : Я внес изменение в sandbox, которое добавляет параметр под названием «catonly». Если это «да», то баннер/замок будет скрыт, и будет предоставлена ​​только категория. Добавлено 2 тестовых случая, которые пройдены. Это реализует этот TfD. Это хорошо? ProcrastinatingReader ( обсуждение ) 19:47, 15 июля 2021 (UTC) [ ответить ]

@ ProcrastinatingReader : Спасибо за реализацию! Я действительно ценю, когда кто-то тратит время на написание тестовых случаев. :) Похоже, вы забыли синхронизировать последние изменения из основного модуля (см. разницу), поэтому вам следует выполнить повторную синхронизацию и проверить, что ваши изменения по-прежнему проходят модульные тесты. Вероятно, нам понадобится еще один тестовый случай, чтобы показать, что значок замка отображается при |catonly=no. И, возможно, аналогичный для категорий, если вы хотите быть доскональными. Кроме того, я вижу, что вы дублируете шаблон UNIQ...QINU для обнаружения маркеров полос — это, вероятно, следует сделать отдельной переменной на случай, если ее нужно будет изменить в будущем. Код песочницы выглядит нормально, хотя, поскольку это условие if/then становится более сложным, я бы поддался соблазну разделить его на отдельную функцию для удобства чтения. Дайте мне знать, если вы хотите, чтобы я что-то прояснил, и как только вы исправите вышеуказанные проблемы, смело развертывайте код, если все модульные тесты пройдены. Лучший — Mr. Stradivarius ♪ talk ♪ 11:45, 16 июля 2021 (UTC) [ ответить ]
Спасибо за обзор! Добавил эти тесты и добавил тест для баннеров. Также разделил этот шаблон на переменную. Все тесты пройдены, поэтому я развернул код. ProcrastinatingReader ( talk ) 12:01, 16 июля 2021 (UTC) [ ответить ]

Запрос на редактирование защищен шаблоном от 3 февраля 2022 г.

Пожалуйста, добавьте следующее в Module:Protection banner/config около строки 772:

['all|module|all|extendedconfirmed|edit'] = 'Википедия расширенные-подтвержденные-защищенные модули',

Модули ECP в настоящее время относятся к категории:Полностью защищенные модули Wikipedia, это переместит их в категорию:Расширенные-подтвержденные-защищенные модули Wikipedia . AntiCompositeNumber ( обсуждение ) 23:27, 3 февраля 2022 (UTC) [ ответить ]

 Выполнено : Special:Diff/1069763876 . —⁠ andrybak ( обсуждение ) 23:50, 3 февраля 2022 (UTC) [ ответить ]
@ Andrybak Спасибо! AntiCompositeNumber ( обсуждение ) 00:02, 4 февраля 2022 (UTC) [ ответить ]

Проблемы с ожидаемыми изменениями наряду с общей защитой

В Chimpanzee страница одновременно ожидает изменений и полузащищена. {{ pp-pc }} не отображается, отображается только {{ pp-vandalism }} . Этого можно ожидать? — CX Zoom [он/им] ( давайте поговорим • { C • X }) 09:51, 5 августа 2022 (UTC) [ ответить ]

@ CX Zoom : Да, сообщается только об одном виде защиты — «более сильном». В этом случае выбирает полузащиту для редактирования, которая предотвращает все изменения неподтвержденными пользователями; в то время как выбирает ожидающие изменения prot, также для редактирования, что позволяет неподтвержденным пользователям вносить изменения, но не делает их видимыми, если они не приняты. Так что в этом случае полузащита является более сильной. -- Red rose64 🌹 ( talk ) 20:46, 5 августа 2022 (UTC) [ ответить ]{{pp-vandalism}}{{pp-pc}}

Использование простого английского языка для обозначения уровней защиты

Недавний громкий случай, когда читатели не понимают значки защиты в Recession , заставил меня пересмотреть текст подсказки, и, похоже, он оставляет желать лучшего. В настоящее время сообщения имеют вид: Эта статья полузащищена до 7 апреля 2022 г., 1:47 UTC. Читатели не знают, что означает «полузащищенный» или «расширенно защищенный», и очень немногие перейдут на страницу политики защиты, чтобы узнать. Я предлагаю изменить формулировку на простой английский, чтобы облегчить понимание. Для полузащиты я бы предложил, чтобы новые пользователи не могли редактировать эту статью до 7 апреля 2022 г., 1:47 UTC (обратите внимание также на два исправления грамматики: добавленную запятую и удаленную точку). Для EC, только опытные пользователи могут редактировать эту статью до... Мысли? {{u| Sdkb }} talk 18:21, 28 августа 2022 (UTC) [ ответить ] 

Идея кажется разумной в теории, но предложенные вами формулировки не работают, поскольку язык, используемый для полузащиты и для расширенной подтвержденной защиты, читается как синонимы друг друга. * Pppery * это началось... 15:10, 29 августа 2022 (UTC) [ ответить ]
Какое громкое дело? На странице обсуждения, похоже, ничего нет. -- Red rose64 🌹 ( обсуждение ) 09:15, 30 августа 2022 (UTC) [ ответ ]
@ Pppery , есть ли у вас альтернатива? Пользователи не будут видеть оба уведомления одновременно, и я не могу придумать интуитивно понятного слова для тех, кто находится в диапазоне редактирования 10-500, поэтому я не уверен, что мы можем сделать что-то лучше. Возможно, для EC, Новые и среднеопытные редакторы не могут редактировать... , но это немного более многословно.
@ Redrose64 , https://slate.com/technology/2022/08/wikipedia-recession-article.html. {{u| Sdkb }}  talk 14:29, 30 августа 2022 (UTC) [ ответить ]
Размышляя об этом некоторое время, я не могу придумать формулировку яснее, чем мое первоначальное предложение. Я не думаю, что проблема синонимов является блокировкой, поскольку подсказки не будут появляться рядом друг с другом, и интуитивно понятно, что между «новым пользователем» и «опытным пользователем» есть промежуточный уровень.
Страница конфигурации в настоящее время использует PROTECTIONLEVEL , поэтому ее улучшение потребует некоторого кодирования; кто-нибудь с навыками Lua будет заинтересован в этом? {{u| Sdkb }}  talk 18:06, 5 октября 2022 (UTC) [ ответить ]
@ Sdkb : Я решил быстро это сделать. Обратите внимание, что я полностью сосредоточился на замках здесь - обычный большой текст баннера не затронут, так как он виден реже, и я не уверен, что вы хотели что-то там менять. Я попытался сделать изменения как можно более легкими (так как множественные структуры классов в главном модуле с объектами, создаваемыми повсюду, в лучшем случае трудно изучить на месте), и я придумал базовый подход к конфигурации (см. здесь ) (Обратите внимание, что подтаблицы перемещения и загрузки могут быть излишними, так как я никогда не видел, чтобы их замки отображались нормально, но я все равно реализовал некоторые формулировки). Я также удалил подсказку из параметров шаблона и ecp в таблице баннеров, поскольку это нарушило бы обмен сообщениями (см. ветку чуть ниже), а также применил запятую, которую вы предложили выше, в форматировании времени, хотя я не уверен, стоит ли удалять точку (это возможно, но не элегантно, скорее всего, это проверка «заканчивается ли последнее сообщение на 'UTC'»).
Поскольку показывать тесты для этого модуля может быть довольно сложно, вот 4 основных уровня защиты с сообщениями по состоянию на текущую версию песочницы:Страница защищена Страница защищена шаблоном Страница расширенная-защищенная Страница полузащищена
Надеюсь, это примерно соответствует тому, о чем вы думали. Если у вас есть комментарии или пожелания, просто спрашивайте. Aidan9382 ( обсуждение ) 12:31, 9 декабря 2022 (UTC) [ ответить ]
@ Aidan9382 , извините за задержку с ответом. Выглядит отлично! Я бы поддержал реализацию. {{u| Sdkb }}  talk 06:02, 1 марта 2023 (UTC) [ ответить ]
@ Aidan9382 , просто хотел вернуться назад, где мы сейчас? Привет, Sdkb  talk 01:34, 6 марта 2024 (UTC) [ ответить ]
@ Sdkb : (Это было больше года назад? Боже, клянусь, это было не так давно) Я не вносил никаких изменений с момента последнего редактирования песочницы, связанного с этим, но эта версия должна работать, поскольку именно ее я использовал для генерации замков в своем сообщении от 9 декабря. Я повторно синхронизировал изменения конфигурации с текущей версией песочницы конфигурации, и изменения модуля уже все еще находятся в песочнице. Изменения для сообщений защиты приветствуются, поскольку я не лучший в написании такого рода вещей. Вы можете увидеть пример сообщения о замке в действии на User:Aidan9382/SafeEnvironmentTesting (вы можете настроить уровень демонстрации по мере необходимости для тестирования каждого замка — вы не можете тестировать несколько за раз, поскольку все индикаторы называются одинаково). Aidan9382 ( обсуждение ) 07:44, 6 марта 2024 (UTC) [ ответить ]

Подсказка/название не соответствует фактическому уровню защиты

В то время как символ, отображаемый шаблонами, такими как {{ pp-extended }} , и ссылка, размещенная за символом, автоматически соответствуют фактическому уровню защиты, подсказка/заголовок — нет. В частности, статья Россия в настоящее время полностью защищена и отображает золотой замок "F" со ссылкой, указывающей на раздел "#full" политики защиты. Однако ее атрибут заголовка — "Эта статья расширенно-подтвержденно защищена".

Это заметил Jishiboka1 в Talk:Russia и, вероятно, должно быть исправлено в модуле. ~ ToBeFree ( обсуждение ) 11:44, 1 октября 2022 (UTC) [ ответить ]

Примечание: после некоторых манипуляций с модулем и нескольких тестовых запусков я выяснил, в чем проблема. Похоже, что модуль полностью полагается на сам шаблон для текста баннера, который он использует, который извлекается из Module:Protection banner/config . Вы можете увидеть пример этого, если попытаетесь использовать {{ pp-template }} на полузащищенной странице — он отобразит текст баннера шаблона из конфигурации, но с уровнем защиты semi. Это работает большую часть времени, поскольку сообщения подсказки используют ${PROTECTIONLEVEL}, что означает, что сообщение адаптируется к уровню защиты страницы. Однако подсказка для ecp жестко закодирована для чтения This ${PAGETYPE} is extended-confirmed protected, отсюда и проблема. Решением этой проблемы может быть просто изменение сообщения подсказки на This ${PAGETYPE} is ${PROTECTIONLEVEL}, чтобы оно соответствовало формату других параметров. Aidan9382 ( talk ) 13:09, 1 октября 2022 (UTC) [ reply ]

Видимо, забыл это сделать. Исходя из обсуждения выше, можно ли This ${PAGETYPE} is extended-confirmed protectedизменить сообщение в строке 224, чтобы This ${PAGETYPE} is ${PROTECTIONLEVEL}избежать отображения модулем неправильного сообщения при использовании {{ pp-extended }} (или аналогичного)? Спасибо. Aidan9382 ( talk ) 18:38, 5 октября 2022 (UTC) [ ответить ]

 Завершено . PI Ellsworth  ,  ред.  put'r there  04:19, 6 октября 2022 (UTC)[ отвечать ]

Обратная связь по конфигурации шаблона

Некоторые строки в Module:Protection_banner/config могли бы больше соответствовать тому, как работает защита страниц в Википедии.

1. Шаблон защиты неиконизированной страницы не ссылается на Wikipedia:Request for edit , когда страница и ее страница обсуждения защищены, как указано в политике полузащиты . Было бы лучше, если бы это могло происходить автоматически, может быть, просто добавить это всегда на страницах обсуждения, когда они защищены? Если это невозможно, было бы хорошо, если бы в шаблоне была опция для добавления этой ссылки.

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

3. Можно ли изменить настройки по умолчанию так, чтобы small=yes устанавливался по умолчанию для статей, защищенных от редактирования (но не от перемещения или любой другой защиты на страницах обсуждения). Похоже, что это предпочтительная практика, так почему бы не сделать ее значением по умолчанию?

Дэниел Куинлан ( обсуждение ) 21:53, 10 июля 2023 (UTC) [ ответить ]

Редактор шаблонов защищен от перемещения?

(Относительно модуля:Защитный баннер/конфигурация#L-758 .)

Кажется бесполезным относить шаблон к категории:Шаблоны, защищенные шаблонами Википедии , когда он защищен только для перемещений , но не для правок . Например, Шаблон:Билл Клинтон находится в этой категории, но его можно свободно редактировать (но не перемещать).

Я предлагаю либо (A) удалить эту строку [редактировать: не добавлять ни одной категории], аналогично тому, как в настоящее время нет категории для страницы, которая является расширенно-подтвержденной защищенной от перемещения, но не защищенной от редактирования, или (B) создание новых категорий Категория: Шаблоны Wikipedia-редактора, защищенные от перемещения и Категория: Страницы Wikipedia, защищенные от перемещения (или аналогичные). SilverLocust 🃏 💬 02:26, ​​27 января 2024 (UTC) [ ответить ]

@ SilverLocust : Эта строка была добавлена ​​в 00:07, 6 сентября 2020 года в соответствии с обсуждением #Move-protected выше. – wbm1058 ( обсуждение ) 03:30, 8 февраля 2024 года (UTC) [ ответить ]
Если быть точнее, это изменение не было добавлено в соответствии с обсуждением на #Move-protected, оно было добавлено после обсуждения на #Move-protected, что изменение было не совсем правильным и должно иметь какое-то лучшее решение. Никто там не утверждал, что предоставленная сейчас категория правильная, просто она там для того, чтобы не было по умолчанию "полностью защищенных страниц".
Но это просто говорит о том, что вместо того, чтобы полностью удалить строку, вариант (A) заключается в том, чтобы переместить эту строку на вторую строку в protectionCategories (чтобы она имела более низкий приоритет, чем все категории под ней) и заменить ее на
[ 'all|template|all|templateeditor|move' ]  =  ''  -- в настоящее время нет категории для защищенных от перемещения страниц редактора шаблонов
И я полагаю, что может быть вариант (C) — объединение защищенных от перемещения страниц TE в шаблоны защищенных от перемещения шаблонов Категория:Wikipedia . SilverLocust 💬 13:46, 27 февраля 2024 (UTC) [ ответить ]
Первую строку protectionCategories (которая используется по умолчанию) также следует изменить на
[ 'all|all|all|all|all' ]  =  'Разные защищенные страницы Википедии' ,
как новую категорию отслеживания, а не по умолчанию «Полностью защищенные страницы Википедии», когда ни один из приведенных ниже вариантов не подходит. И это позволило бы просто удалить неправильные категории, а не втиснуть их в какую-то не совсем правильную категорию. SilverLocust 💬 20:11, 27 февраля 2024 (UTC) [ ответить ]

Запрос на редактирование 28 февраля 2024 г.

[ 'all|all|all|templateeditor|move' ]  =  'Страницы Википедии, защищенные шаблонами, кроме шаблонов и модулей' , [ 'all|template|all|extendedconfirmed|move' ]  =  'Шаблоны Википедии, защищенные расширенными подтвержденными шаблонами' ,

Пожалуйста, добавьте эти две новые строки (sandbox diff) в объект protectionCategories в /config, чтобы

  1. страницы, подобные перенаправлению Template talk:Db-a1, не будут ошибочно отнесены к категории Category:Wikipedia полностью защищенные страницы (через {{ pp-move }} , который вызывается {{ Redirect category shell }} ) и
  2. Расширенно подтвержденные шаблоны, такие как Шаблон:Война Израиля и ХАМАС, не будут отнесены ни к категории «Страницы Wikipedia с расширенной поддержкой подтверждения» (через {{ pp-move }} ), ни к подкатегории «Шаблоны Wikipedia с расширенной поддержкой подтверждения» (через {{ pp }} ), а только к подкатегории.

SilverLocust 💬 02:02, 28 февраля 2024 (UTC) [ ответить ]

Я могу внести это изменение сейчас, поэтому я сделаю свой собственный запрос. (Это отдельно от предложений в предыдущем разделе.) SilverLocust 💬 12:39, 1 марта 2024 (UTC) [ ответить ]

Небольшая ошибка

Я заметил, что полузащищенная статья, к которой применен шаблон расширенной защиты, отображает значок полузащиты, но с подсказкой, которая гласит: «Эта статья полузащищена#semi». Не самое главное, но если кто-то хочет избавиться от «#semi» в конце, это было бы неплохо. Sdkb  talk 21:09, 27 августа 2024 (UTC) [ ответить ]

Какая статья? Якорь не должен появляться, так как он должен быть частью ссылки блокировки, и некоторые мои быстрые проверки, похоже, не вызывают этот случай. Aidan9382 ( talk ) 21:39, 27 августа 2024 (UTC) [ ответить ]
Я нашел его на Tim Walz , у которого истек срок защиты EC (и я затем заменил его на полузащиту). Sdkb  talk 21:57, 27 августа 2024 (UTC) [ ответить ]
Мне кажется, все в порядке, подсказка просто "Эта статья частично защищена". Aidan9382 ( обсуждение ) 08:35, 28 августа 2024 (UTC) [ ответить ]

Значок перенаправления

Кто-нибудь смотрит? Значок BLACKLOCK на Asian News International против Wikimedia Foundation перенаправляет на Wikipedia:Protection_policy#full , но Wikipedia:Protection_policy#Office_actions было бы более уместно. Gråbergs Gråa Sång ( talk ) 18:41, 21 октября 2024 (UTC) [ ответить ]

Это потребует изменения кода модуля, поскольку конфигурация, отвечающая за определение ссылки, которую использует замок, определяется здесь , а офисное действие, с технической точки зрения, является просто обычной полной (административной) защитой. Единственный способ определить разницу для изображения — это явное использование {{ pp-office }} вместо {{ pp }} , поэтому что-то подобное нужно будет сделать и для обработки ссылки на изображение. Aidan9382 ( talk ) 18:50, 21 октября 2024 (UTC) [ reply ]
Хотя защита действий офиса реализована как полная защита, цель перенаправления — предоставить читателям дополнительный контекст и информацию. Я согласен, что имеет смысл, чтобы значок перенаправлял на наиболее релевантный раздел политики, Wikipedia:Политика защиты § Действия офиса . Просто для ясности, я комментирую только желаемый результат, а не техническую реализацию. Daniel Quinlan ( talk ) 18:58, 21 октября 2024 (UTC) [ ответить ]
@ Gråbergs Gråa Sång : Легко узнать, какой уровень защиты и когда он истекает. Есть две функции парсера , которые это делают:
  • {{PROTECTIONLEVEL:edit|Asian News International vs. Wikimedia Foundation}}→ сисоп
  • {{PROTECTIONEXPIRY:edit|Asian News International vs. Wikimedia Foundation}}→ бесконечность
  • {{PROTECTIONLEVEL:move|Asian News International vs. Wikimedia Foundation}}→ сисоп
  • {{PROTECTIONEXPIRY:move|Asian News International vs. Wikimedia Foundation}}→ бесконечность
Значение "sysop" обозначает полную защиту по любой причине. Эти значения считываются непосредственно из таблицы, и хотя этот модуль получает значения с помощью другого модуля (в частности, Module:Effective protection level ), а не функций синтаксического анализатора, базовые процедуры в программном обеспечении MediaWiki те же самые, и поэтому значения считываются из той же таблицы. Но причина защиты не хранится в таблице, она только регистрируется как запись в журнале. Модулю необходимо будет просмотреть этот журнал, поскольку наложение защиты может быть не самой последней записью в журнале защиты (хотя в данном случае это так). Модулю также необходимо будет делать это каждый раз при извлечении страницы, и это займет время. Я не думаю, что это хорошая идея. Придерживайтесь использования или и т. д., в зависимости от того, что наиболее подходит, поскольку они явно описывают ситуацию. -- Red rose64 🌹 ( talk ) 07:37, 22 октября 2024 (UTC) [ reply ]{{pp-office}}{{pp-vand}}
Если это невозможно, то это невозможно. Это было бы небольшим, но очевидным улучшением для читателя, и я предполагал, что изменение «перенаправления» на WP:BLACKLOCK было бы довольно тривиальным, хотя, конечно, ограничено WP:PINKLOCK и т. д. Чтобы сделать сравнение WP:OTHERCONTENT , значок WP:PINKLOCK (вверху справа) на баннере Module:Protection перенаправляет на WP:PINKLOCK , а не WP:GOLDLOCK . Gråbergs Gråa Sång ( talk ) 07:48, 22 октября 2024 (UTC) [ ответить ]
После быстрого просмотра кода модуля оказывается, что уже можно переопределить ссылку на замок в конфигурации на основе используемого шаблона, просто ни один из существующих случаев не использовал указанную функцию. Я изо всех сил старался воркшопить изменение в конфигурации песочницы на телефоне здесь . Aidan9382 ( talk ) 09:52, 22 октября 2024 (UTC) [ ответить ]
Хорошая находка. Это кажется многообещающим решением, и оно использует описательную ссылку. Дэниел Куинлан ( обсуждение ) 11:45, 22 октября 2024 (UTC) [ ответить ]
Лучше избегать использования цветных сочетаний клавиш, которые часто неясны людям по смыслу и используются реже, и вместо этого использовать более описательные сочетания клавиш, такие как WP:ECP или, что еще лучше, прямые и описательные ссылки. Дэниел Куинлан ( обсуждение ) 11:33, 22 октября 2024 (UTC) [ ответить ]

Если ни у кого нет дополнительных комментариев или предложений по этому поводу, я перенесу это изменение из песочницы в основную ветку, поскольку это кажется довольно бесспорным. Aidan9382 ( обсуждение ) 16:41, 22 октября 2024 (UTC) [ ответить ]

Я реализовал изменение конфигурации, теперь замки офиса будут ссылаться на раздел офиса в политике защиты. Aidan9382 ( обсуждение ) 18:54, 23 октября 2024 (UTC) [ ответить ]
Спасибо! Gråbergs Gråa Sång ( обсуждение ) 19:09, 23 октября 2024 г. (UTC) [ ответить ]
Выглядит хорошо. Офисные замки имеют правильное назначение, а замки полной защиты не изменились. Спасибо. Дэниел Куинлан ( обсуждение ) 19:19, 23 октября 2024 (UTC) [ ответить ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Protection_banner&oldid=1257784934"