Раздел предложений в Village Pump используется для предложения конкретных изменений для обсуждения. Перед отправкой :
Проверьте, не описано ли ваше предложение в разделе Perennial suggestions . Вы также можете поискать в разделе FAQ .
Эта страница для конкретных, действенных предложений. Рассмотрите возможность разработки предложений на более ранней стадии в Village pump (идеальная лаборатория) .
Возвращаясь к этому предложению , я хочу сделать значки более четкими и изящными; со временем я добавлю больше значков (например, хорошие статьи, аудиостатьи и т. д.). Я также хочу добавить региональные буквенные скрепки, например, 拡 (拡張, Kakuchō) будет японским значком расширенной защиты, то же самое с 満 (満杯, Manpai) для полной защиты.
Запрос новых иконок для Википедии. (Доступно всем)
2I3I3 ( обсуждение ) 16:25, 16 октября 2024 (UTC ) [ ответ ]
Согласен с другими, что эти новые значки выглядят устаревшими. Однако, если мы обсуждаем изменения в значках блокировки, то должен сказать, что фиолетовый цвет для защищенной загрузки неуместно безвкусен. Cremastra — talk — c 20:23, 17 октября 2024 (UTC) [ ответить ]
Я согласен и с радостью поддержу предложение сделать его темнее - может быть, #813ec3? Rexo ( обсуждение | вклад ) 20:33, 29 октября 2024 (UTC) [ ответить ]
Oppose. Я думаю, что градиенты или скосы делают эти значки менее четкими и гладкими, по крайней мере в их текущей версии. Значки также становятся менее читаемыми при меньших разрешениях, поскольку часть дужки навесных замков занимает больше места, делая фактический символ внутри меньше.
Кто знает, графический дизайн, похоже, снова медленно отходит от плоского дизайна, так что, может быть, через несколько лет? quidama talk 22:19, 23 октября 2024 (UTC) [ ответить ]
Нет. Нам не нужны иконки, которые выглядят так, как будто они были сделаны в Kid Pix . Лилиана UwU ( обсуждение / вклад ) 01:25, 7 ноября 2024 (UTC) [ ответить ]
Довольно сильно против попытки запустить скрипт геолокации при каждой загрузке, чтобы попытаться сделать динамические метки здесь. Если что (что мне тоже не нравится), метки должны следовать языку пользовательского интерфейса. — xaosflux Talk 17:39, 16 октября 2024 (UTC) [ ответить ]
Я понимаю различия, я просто предположил (так как я не говорю ни на каком другом языке, вы могли бы предложить конкретную версию). Также, позже я добавлю буквы на скобы.
2I3I3 ( обсуждение ) 19:16, 16 октября 2024 (UTC ) [ ответ ]
и значки* 2I3I3 ( обсуждение ) 19:16, 16 октября 2024 (UTC) [ ответ ]
Форматы файлов SVG могут быть переведены. Смотрите c:Commons:Возможность перевода/Узнать больше. WhatamIdoing ( обсуждение ) 23:33, 16 октября 2024 (UTC) [ ответить ]
Выступайте против того, чтобы основным (единственным) различием был цвет, поскольку это дает меньше информации, чем текущая схема, и бесполезно для тех, у кого нет способностей видеть цвет. — xaosflux Talk 17:41, 16 октября 2024 (UTC) [ ответить ]
Согласен с Xaosflux по этому поводу. Более того, две проблемы старой схемы иконок (цвет и "реалистичное" затенение, которое не очень хорошо смотрится на маленьких иконках), которые изначально были причинами изменений, присутствуют и здесь.Что касается региональных символов, было бы разумнее отображать их в зависимости от языковой версии, и поскольку каждая языковая версия уже устанавливает свои собственные стандарты для этого, мы не можем сделать больше. Chaotic Enby ( обсуждение · вклад ) 18:13, 16 октября 2024 (UTC) [ ответить ]
Согласен с Xaosflux, так как раскраска и затенение не очень хорошо смотрятся на маленьких значках. ‹ hamster717🐉 › ( обсуждайте что угодно!🐹✈️ • мой вклад🌌🌠 ) 20:33, 18 октября 2024 (UTC) [ ответить ]
Согласен , но только немного. Если бы вы добавили буквы, было бы лучше. Кроме того, решением для вашего региона-базирования может быть создание языкового базирования (например, "O" для "Office" станет "S" для "Schoolhouse" в теоретическом "перевернутом английском") Мастер ёжиков ( converse ) ( hedgehogs ) 14:33, 17 октября 2024 (UTC) [ ответить ]
Будут ли эти значки/цвета работать с темным режимом? Я также согласен, что буквы необходимы. Thryduulf ( talk ) 14:44, 17 октября 2024 (UTC) [ ответить ]
См. также Shackle . Это навесные замки, а верхняя U-образная часть — это скоба. WhatamIdoing ( talk ) 20:22, 17 октября 2024 (UTC) [ ответить ]
Я думал, что мы используем слово «сковать» для описания вещи по одному аспекту, чтобы избежать путаницы с защитой/блокировкой редактирования. Аарон Лю ( обсуждение ) 18:13, 2 ноября 2024 (UTC) [ ответить ]
Ну, нам не следует этого делать, потому что, как заметил @ WhatamIdoing , скоба — это часть замка. И простое использование слова «замок» позволяет избежать смешения, не называя вещи неправильными. (Даже количество букв одинаковое.) FeRDNYC ( talk ) 03:55, 3 ноября 2024 (UTC) [ reply ]
Еще одно решение в поисках проблемы. * Pppery * началось... 16:18, 17 октября 2024 (UTC) [ ответить ]
Согласно WP:WIKICLICHE, нас попросили не говорить об этом так много из-за проблем с цепочкой поставок – если мы будем использовать их слишком много, то в будущем мы можем столкнуться с огромным дефицитом. Но я надеюсь, что янетгенерируя больше тепла, чем света этим комментарием, или выплескивая ребенка вместе с водой. Cremastra — talk — c 20:22, 17 октября 2024 (UTC) [ ответить ]
Никогда не выплескивайте ребенка вместе с водой из ванны. Это загрязнит вашу систему сбора серой воды. Как и другие виды мяса, младенцы не подлежат компостированию, поэтому их следует сортировать в поток отходов на свалке, если иное не рекомендовано вашим муниципальным органом по управлению отходами. Folly Mox ( обсуждение ) Folly Mox ( обсуждение ) 20:46, 17 октября 2024 (UTC) [ ответить ]
Является ли вода в ванне той же водой, в которую я должен привести эту лошадь? Remsense ‥ 论21:40, 17 октября 2024 (UTC) [ ответить ]
Может быть, он находится под мостом — это объяснило бы все эти проблемы. jlwoodwa ( обсуждение ) 01:14, 19 октября 2024 (UTC) [ ответить ]
Псевдо-3D-затенение выглядит устаревшим по сравнению с текущими плоскими иконками. Большинство современных систем дизайна (включая codex, которая является новой системой дизайна для вики-сайтов Wikimedia) построены вокруг плоских иконок. -- Ahecht ( СТРАНИЦА ОБСУЖДЕНИЯ) 18:36, 17 октября 2024 (UTC) [ ответить ]
А как насчет таких значков, как избранный, хороший и аудио? 2I3I3 ( обсуждение ) 18:55, 17 октября 2024 (UTC) [ ответ ]
Просто для развлеченияВсе еще кажется шагом назад. Текущая иконка «Хорошая статья», помимо того, что имеет меньше отвлекающей тени и более удобочитаема, имеет единый стиль со многими другими нашими иконками. Текущая иконка «Избранная статья», хотя и не согласуется с другими, довольно уникальна и узнаваема по дизайну, в то время как эта выглядит как обычная звезда.Просто ради забавы я однажды сделал звезду «Хорошая статья» в стиле FA — конечно, она не предназначалась для какой-либо официальной реализации, выходящей за рамки моего личного сценария , но интересно посмотреть, как это будет выглядеть. Chaotic Enby ( обсуждение · вклад ) 22:14, 17 октября 2024 (UTC) [ ответить ]
что на самом деле- Аарон Лю ( обсуждение ) 17:10, 2 ноября 2024 (UTC) [ ответить ]
Вы когда-нибудь смотрели на значок избранной статьи в полный размер? (Если нет, посмотрите на File:Cscr-featured.png . Я подожду.) ...Нравится или объединяется со звездой GA @ Chaotic Enby , она на самом деле довольно гармоничного стиля с текущей звездой FA, которая (как отмечено) в настоящее время не соответствует ничему другому где-либо. Возможно, она хорошо известна/узнаваема — Chaotic, во всяком случае, так утверждает — но, честно говоря, у меня есть ощущение, что подавляющее большинство читателей никогда не видят ее больше, чем в масштабе булавочной головки, и даже не узнают настоящее полноразмерное изображение КАК наш значок FA. FeRDNYC ( обсуждение ) 04:10, 3 ноября 2024 (UTC) [ ответ ]
Я видел полную иконку FA; звезда GA просто взята из Cthulhu (...положительно). Это весело, но я думаю, что GA должна быть более в соответствии с остальными иконками рейтинга статей из-за некоторой меньшей строгости. Аарон Лю ( обсуждение ) 13:26, 3 ноября 2024 (UTC) [ ответить ]
Честно говоря, это определенно концептуальный дизайн, а не реальное предложение. Если уж на то пошло, я бы предпочел, чтобы нынешняя иконка GA была нашей официальной, так как она более гармонична с чем угодно, кроме звезды FA. Chaotic Enby ( talk · contribs ) 22:18, 4 ноября 2024 (UTC) [ ответить ]
К сожалению, это не визуальные улучшения. Это явный регресс в дизайне, и текущие значки хороши. Наша система специфична для английской Википедии, поэтому вполне уместно, чтобы их дизайн был соотнесен с английским языком. Remsense ‥ 论19:29, 17 октября 2024 (UTC) [ ответить ]
Покрасьте меня в тупик. Начиная с Re-instating this proposal , вы заставляете меня думать, что вы хотите оживить какое-то провалившееся предложение. Но затем я перехожу по вашей ссылке и вижу, что предложение привело к внедрению новых значков замка, которые; я полагаю, вы имеете в виду отменить . Я также не понимаю, что вы имеете в виду под региональными буквенными скобами ; вы имеете в виду статьи о , например, Японии? Или статьи, просмотренные кем-то, кто, как мы должны были предположить, может быть в Японии? Или кем-то, у кого японский язык указан в поле пользователя на его странице пользователя? Это английская Википедия, поэтому я не вижу, чтобы последние два были полезными вариантами, а первый приведет только к спорам и путанице , и у нас это уже есть . Текущие значки кажутся мне достаточно понятными, хотя я не знаю, как измерить «гладкий», я полагаю. Подводя итог: сбит с толку . — JohnFromPinckney ( обсуждение / редактирование ) 12:15, 18 октября 2024 (UTC) [ ответить ]
Я имею в виду региональные буквенные скобы, в основном такие же, как буквы на скобах, но с разными региональными переводами. (Это, вероятно, не сработает из-за поста @ Chaotic Enby .)
2I3I3 ( обсуждение ) 18:36, 18 октября 2024 (UTC ) [ ответ ]
Итак (просто чтобы проверить, правильно ли я понял), вы предлагаете в английской Википедии, чтобы японская Википедия использовала значки с японской символикой, а испанская Википедия использовала какой-то индикатор на испанском языке на замке и т. д. Да? — JohnFromPinckney ( обсуждение / редактирование ) 22:30, 18 октября 2024 (UTC) [ ответить ]
Сейчас выступаем против. Статус-кво в порядке. Но это действительно здорово, что вы вносите свои графические навыки в движение. Я уверен, что есть некоторые менее заметные области, которые могли бы действительно выиграть от ваших навыков. – Novem Linguae ( обсуждение ) 03:55, 23 октября 2024 (UTC) [ ответить ]
Oppose : Новые предложения хороши, но мне лично больше нравится стиль старых, и плоские значки также кажутся мне более современными. Региональные кандалы кажутся хорошей идеей, но, похоже, в этом предложении их нет, поэтому я просто скажу, что поддерживаю их (возможно, в старом стиле дизайна, как мне больше нравится). Mrfoogles ( talk ) 20:22, 23 октября 2024 (UTC) [ reply ]
Oppose per Remsense. Новые 3D-иконки выглядят как что-то из ранних дней Интернета. Плюс затенение делает иконки излишне «громоздкими» (не уверен, как это сказать). Nythar ( 💬 - 🍀 ) 22:33, 25 октября 2024 (UTC) [ ответить ]
Oppose и здесь. Речь не о статус-кво или сопротивлении переменам, я гораздо больше предпочитаю текущие значки предлагаемым заменам. (Субъективно, конечно) доводы в пользу текущих значков по сравнению с новыми:
Более плоский вид будет лучше отображаться при небольших размерах (поскольку эти значки на самом деле отображаются в размере, составляющем лишь малую часть от того, который они отображают в этой теме)
То же самое с более блочным шрифтом.
То же самое касается более толстых дуг скоб.
Узкие дужки и прямоугольный корпус придают предлагаемым замене вид дамских сумочек, а не навесных замков.
Размещение букв в текущих иконках более равномерное и точное; предлагаемые замены, похоже, были сделаны "на глаз". IMHO, SVG-арт такого рода лучше всего кодировать вручную (если не с нуля, то хотя бы в качестве завершающего этапа для очистки кода), с точными и единообразными размерами.
Я ценю усилия, и мне жаль критиковать, но я просто не в восторге от них. Текущий набор, OTOH, на самом деле довольно хорошо спроектирован и оптимизирован для своей цели, что является важным соображением при проектировании функциональных произведений искусства такого рода. Мне непонятно, что кто-то будет искать им замену, так как, ИМХО, на удивление мало возможностей для улучшения. FeRDNYC ( talk ) 13:19, 26 октября 2024 (UTC) [ ответить ]
Я думаю, что предложенные наборы могли быть крутыми во время предыдущего предложения. Эти замки были бы более уместны для чего-то вроде 2008 года. Это по той же причине, по которой светофоры всегда (сверху вниз) красные, желтые, зеленые. И почему двери поездов в британских поездах должны иметь двери, достаточно контрастирующие с остальным (см. PRM TSI ). Другими словами, использовать только цвет для различения недостаточно.
Кроме того, это та же причина, по которой логотипы становятся более плоскими. JuniperChill ( обсуждение ) 01:49, 2 ноября 2024 (UTC) [ ответить ]
Oppose - не поклонник предлагаемых иконок (см. также комментарий Nythar), и текущие замки работают довольно хорошо. Однако я бы поддержал редизайн иконок GA/FA (/различных иконок того же стиля) в стиле, похожем на текущие замки. Rexo ( обсуждение | вклад ) 20:30, 29 октября 2024 (UTC) [ ответить ]
Что, если мы сохраним оковы и хорошую иконку, получим новую избранную иконку и сделаем встроенную функцию, которая позволит оковам быть совместимыми с темным режимом? 2I3I3 ( обсуждение ) 03:07, 2 ноября 2024 (UTC) [ ответ ]
Это все еще не оковы. (И, Rexo, я не понимаю, почему символы качественной статьи должны подразумевать защиту и блокировку редактирования.) Аарон Лю ( обсуждение ) 17:07, 2 ноября 2024 (UTC) [ ответить ]
(для ясности: стиль, используемый во многих значках вики (включая FA/GA), кажется устаревшим, а замки выглядят более аккуратно, что, как мне кажется, может быть использовано в качестве основы для дальнейших редизайнов. Я не думаю, что это по сути приведет к тому, что символы качества будут подразумевать защиту.) Rexo ( обсуждение | вклад ) 13:54, 4 ноября 2024 (UTC) [ ответ ]
Я не думаю, что значки Norro или FA устарели, а использование замков для обозначения качества просто не имеет семантического смысла. Мы приняли замки, потому что они показывали, что статья была заблокирована для редактирования. Аарон Лю ( обсуждение ) 14:07, 4 ноября 2024 (UTC) [ ответить ]
@ Aaron Liu Я не думаю, что Rexo имеет в виду использование настоящих навесных замков; я думаю, она имеет в виду разработку более плоского дизайна, вдохновленного и похожего на наши значки защиты. Cremastra ( u — c ) 20:56, 4 ноября 2024 (UTC) [ ответить ]
Как это сделать, не беря элементы из замков? Аарон Лю ( обсуждение ) 21:32, 4 ноября 2024 (UTC) [ ответить ]
Я думаю, это можно сделать, взяв неблокируемые элементы, такие как текст и однотонный фон. Cremastra ( u — c ) 21:35, 4 ноября 2024 (UTC) [ ответить ]
Более или менее; по крайней мере, я думаю, что они имеют в виду именно это. Cremastra ( u — c ) 21:47, 4 ноября 2024 (UTC) [ ответить ]
извините за путаницу, но да, примерно так. Rexo ( обсуждение | вклад ) 22:32, 4 ноября 2024 (UTC) [ ответить ]
Я в замешательстве - замки выглядят нормально в темном режиме (Vector 2022)? Фон Office немного трудно разглядеть, но все остальное выглядит нормально. Rexo ( обсуждение | вклад ) 13:56, 4 ноября 2024 (UTC) [ ответить ]
Просто чтобы мы все были на одной волне в терминологии:
Они разные, понимаешь?
Кремастра ( u — c ) 17:12, 2 ноября 2024 (UTC) [ ответить ]
В нашей статье «Скоба» говорится: «Скоба — это также кусок металла похожей формы, используемый с запирающим механизмом в навесных замках . [1] ». Некоторые здесь, похоже, сбиты с толку, но любой, кто использует «скобу» для обозначения ручки значка, похожего на сумочку, прав. Anomie ⚔ 21:18, 2 ноября 2024 (UTC) [ ответить ]
\o/ Технически я прав, "Лучший вариант правильности!" (Вы можете удивиться, как редко это случается, к сожалению.) FeRDNYC ( обсуждение ) 03:43, 3 ноября 2024 (UTC) [ ответ ]
Ссылки
^ Робинсон, Роберт Л. (1973). Полный курс профессионального слесарного дела. Rowman & Littlefield. ISBN 978-0-911012-15-6.
Предупреждать об использовании встроенных изображений
Задача : Когда редактирование добавляет ссылку на файл без "|(\s*)?frameless" или "|(\s*)?thumb" внутри, предупредить пользователя и сказать ему, что он, вероятно, хотел добавить |thumb. Тем не менее, разрешить ему сохранить редактирование. Также может сканировать для каждого поддерживаемого формата, если это необходимо.
Необходимо более широкое обсуждение , но до тех пор {{ EFR }} . Основанием для этого запроса является одно случайное удаление двоеточия. Это больше похоже на то, что может быть поднято в Phab, если не что-то еще, но я не думаю, что нам нужен фильтр, чтобы предупредить людей использовать thumb. EggRoll97 ( обсуждение ) 23:52, 23 октября 2024 (UTC) [ ответить ]
Это было создано в результате и связано с темой VPI, но, конечно, я уведомил VPR. Аарон Лю ( обсуждение ) 00:55, 24 октября 2024 (UTC) [ ответить ]
Из VPR. Я не уверен, каковы наши стандарты для фильтров редактирования, чтобы иметь возможность прокомментировать уместность одного из них для этого. Но я могу сказать, что я определенно был виновен в том, что забывал добавлять thumbи не делал предварительный просмотр, что приводило к ситуациям, точно таким же, как связанное различие.
Если это не подходит для фильтра, мы, безусловно, должны добавить это в mw:Edit check/Ideas, чтобы PPelberg (WMF) и др. могли это рассмотреть. Привет, Sdkb talk 01:17, 24 октября 2024 (UTC) [ ответить ]
Я думаю, что проверка правок — гораздо лучшее место для этого, чем фильтры злоупотреблений, которые не позволяют сохранить всю правку. * Пппэри * это началось... 01:33, 24 октября 2024 (UTC) [ ответить ]
Фильтры редактирования могут предупреждать при первой отправке и позволять сохранять при второй отправке. Аарон Лю ( обсуждение ) 02:09, 24 октября 2024 (UTC) [ ответить ]
Звучит как хорошая идея! Аарон Лю ( обсуждение ) 02:09, 24 октября 2024 (UTC) [ ответить ]
На самом деле, нет, я не уверен, применяется ли проверка правок. На странице проекта он определяется как набор улучшений для визуального редактора , и я очень сомневаюсь, что редакторы допускают эту ошибку. Аарон Лю ( обсуждение ) 02:19, 24 октября 2024 (UTC) [ ответить ]
Ах, да, я забыл об этом. В таком случае нам может понадобиться другой вид предупреждения, возможно, похожий на добавленную ссылку на устранение неоднозначности. Sdkb talk 02:24, 24 октября 2024 (UTC) [ ответить ]
Это требует гораздо больше разработки, чем регулярное выражение. Аарон Лю ( обсуждение ) 11:41, 24 октября 2024 (UTC) [ ответить ]
Может быть, это хорошая идея для списка желаний сообщества больше, чем для чего-либо еще. Я не думаю, что фильтр редактирования — действительно лучший способ. Даже в режиме «только предупреждение» он будет ловить добросовестные правки и (временно) замедлять эти вклады. Это не значит, что это не проблема, просто фильтры редактирования могут быть не лучшим способом ее решения. EggRoll97 ( обсуждение ) 04:39, 25 октября 2024 (UTC) [ ответить ]
Я не вижу абсолютно никаких добросовестных причин, по которым кто-то может захотеть использовать встроенное изображение. Аарон Лю ( обсуждение ) 11:27, 25 октября 2024 (UTC) [ ответить ]
Технически многие формулы в математических статьях являются встроенными изображениями (см., например, series (mathematics) ). Они генерируются, а не транспонируются, но меня не удивит, если есть какой-то пограничный случай, когда изображение транспонируется в строку для аналогичной цели. Thryduulf ( talk ) 11:39, 25 октября 2024 (UTC) [ ответить ]
Такие случаи, когда MathJAX невозможно использовать, вероятно, невероятно редки и меньше, чем количество раз, когда люди подключаются к сети случайно. Аарон Лю ( обс. ) 11:53, 25 октября 2024 (UTC) [ ответить ]
Конечно, есть статьи, содержащие встроенные изображения для обсуждения символов (которые могут не иметь прямых представлений символов Unicode), например, редкие исторические буквенные глифы или элементы музыкальной нотации (см. Архаичные греческие алфавиты или Мензуральная нотация , чтобы назвать только две, над которыми мне довелось работать). Да, я думаю, что таких статей немного, но если они требуются статье, то потребуются многократно. Fut.Perf. ☼ 11:59, 25 октября 2024 (UTC) [ ответить ]
Мы могли бы добавить в белый список, возможно Аарон Лю ( обсуждение ) 12:02, 25 октября 2024 (UTC) [ ответить ]
Я не думаю, что это будет масштабируемо, учитывая количество потенциальных статей и количество потенциальных изображений. Что могло бы сработать, так это что-то в синтаксисе, что-то вроде "Я намеренно использую это изображение в строке" Thryduulf ( talk ) 12:05, 25 октября 2024 (UTC) [ ответить ]
...может ли добавление дополнительного пустого канала сработать? Мы могли бы сделать так, чтобы регулярное выражение прерывалось, если соответствующий встроенный файл встраивается в |]] Аарон Лю ( обсуждение ) 19:54, 25 октября 2024 (UTC) [ ответить ]
Из тестирования в моей песочнице мне кажется, что это будет работать во всех случаях, когда нет подписи, используемой как альтернативный текст (#10), поскольку это удаляет альтернативный текст. Глаголица#Characteristic использует подписи таким образом.
Однако, когда я свел результаты в таблицу ( Special:Permalink/1253409176 ), любые двойные вертикальные линии были интерпретированы как синтаксис таблицы, даже внутри ссылки на файл, так что все сломалось. Что все усложняет. Я также хотел бы знать, сломается ли что-нибудь для пользователей экранных ридеров.
Явный параметр inline=yes (который AIUI проигнорирует синтаксическим анализатором) может работать, но у меня не хватило времени, чтобы это проверить. Thryduulf ( обсуждение ) 20:58, 25 октября 2024 (UTC) [ ответить ]
Мы также могли бы сделать для случая 1 (без подписи) и случая 2 (с подписью). Регулярное выражение будет сканировать на наличие |inline|. Аарон Лю ( обсуждение ) 21:04, 25 октября 2024 (UTC) [ ответить ][[File:Slinky shrewsbury.jpg|inline|]][[File:Slinky shrewsbury.jpg|inline|caption]]
Если только это не будет интерпретировано как альтернативный текст или иным образом не запутает программы чтения с экрана, это может сработать. Thryduulf ( обсуждение ) 21:09, 25 октября 2024 (UTC) [ ответить ]
Кроме того, нам нужно убедиться, что он не конфликтует с какими-либо ботами по исправлению синтаксиса (или людьми). Thryduulf ( обсуждение ) 21:10, 25 октября 2024 (UTC) [ ответить ]
Другая мысль заключается в том, что нам нужно заставить VE вставить и этот параметр, иначе это приведет к предупреждению для следующего человека, который будет редактировать исходный код, что может привести к путанице и потере правок. Thryduulf ( обсуждение ) 01:19, 26 октября 2024 (UTC) [ ответить ]
У меня сложилось впечатление, что фильтры редактирования можно настроить только на проверку измененных абзацев. Аарон Лю ( обсуждение ) 18:06, 26 октября 2024 (UTC) [ ответить ]
( конфликт правок ) Я согласен с обоими этими предположениями, но я не знаю, есть ли другие применения, кроме математических статей. Однако моя главная мысль была в том, что добросовестные причины для использования встроенного изображения, какими бы редкими они ни были, почти наверняка существуют, и поэтому должно быть какое-то положение, разрешающее их. Thryduulf ( обсуждение ) 12:00, 25 октября 2024 (UTC) [ ответ ]
Есть много шаблонов, которые используют встроенные изображения, так что будьте осторожны. Я бы сказал, пожалуйста, не делайте слишком много предположений о том, как люди НЕ должны использовать wikicode. Люди более изобретательны с синтаксисом, чем вы ожидаете :) — Th e DJ ( talk • contribs ) 12:05, 25 октября 2024 (UTC) [ ответить ]
Да, все, что ограничивает встроенные изображения, должно применяться только к пространству имен статьи (и черновика?) Thryduulf ( обсуждение ) 12:06, 25 октября 2024 (UTC) [ ответ ]
Спасибо за примеры. Однако я думаю, что нам всем следует переключить внимание на идею переопределения |inline|, предложенную выше. С идеей переопределения редакторы, добавляющие новые встроенные изображения, могут увидеть, как предотвратить повторное появление сообщения, и продолжить свой веселый путь. Аарон Лю ( обсуждение ) 00:52, 26 октября 2024 (UTC) [ ответить ]
Хотя я согласен с @Aaron Liu в том, что эта конкретная проблема, по-видимому, характерна только для людей, работающих с викитекстом, и, как следствие, выходит за рамки проверки правок, спасибо @Sdkb за установление связи между этим запросом и проверкой правок!
То, что вы здесь моделируете — размышления о том, как политика/конвенция могут быть запрограммированы в процесс редактирования, — это именно тот тип практики, который мы хотим вдохновить с помощью Edit Check.
Надеюсь, вы все продолжите пинговать меня, когда появятся идеи такого рода... PPelberg (WMF) ( обсуждение ) 19:47, 25 октября 2024 (UTC) [ ответ ]
Мне нравится и я поддерживаю эту идею для того самого примера, который вы приводите (боже, какое большое изображение). Однако меня беспокоит только одно предупреждение, призывающее использовать эти параметры, — это то, что нужно очень четко указать заранее, что |frame, |frameless и |thumb НЕ могут использоваться в какой-либо комбинации вместе, поскольку эти три параметра являются противоречивыми. Когда эти конфликтующие параметры появляются вместе на одном изображении, это вызывает ошибку синтаксиса Bogus/Invalid Image Option, отслеживаемую Википедией, которая ежедневно порождает около дюжины новых случаев. Этим летом мы с другим редактором объединились и наконец устранили существующее отставание в 7000+ случаев активных недействительных параметров изображения, и это один из немногих типов ошибок, с которыми наше маленькое сообщество справилось и которые мы скашиваем, чтобы они не дали новых побегов и не разрослись снова. Моя главная проблема в том, что если Википедия не даст ясно понять, что их нельзя использовать вместе, люди могут подумать, что нет проблемы в том, чтобы просто добавить все варианты и покончить с этим (реакция «К черту все это»), что приведет к более высокой частоте повторного заполнения этого типа ошибки. Будет ли эффективным указание использовать только один (чтобы препятствовать комбинациям) или может быть разумным второе/дополнительное сообщение при (повторной) отправке в этих случаях? Zinnober9 ( обсуждение ) 05:53, 28 октября 2024 (UTC) [ ответить ]
Предложенное переопределение для фильтра редактирования выше вводит множественные подписи, что также является ошибкой линтера. Знаете ли вы, есть ли способ настроить расширение линтера так, чтобы переопределение было исключением? Аарон Лю ( обсуждение ) 12:52, 28 октября 2024 (UTC) [ ответить ]
Это далеко за пределами моих знаний. Jonesey95 знает больше меня, они могут знать, но я подозреваю, что это больше вопрос к WMF. Если бы были введены множественные подписи, меня беспокоит, как это будет работать и каковы элементы управления для определения того, какая подпись будет отображаться. Я думаю, что текущий синтаксис WP:EIS довольно прост, и люди сейчас делают с ним всевозможные непреднамеренные беспорядок. Zinnober9 ( обсуждение ) 15:50, 28 октября 2024 (UTC) [ ответ ]
Если бы было введено несколько субтитров, меня беспокоит, как это будет работать и как будут реализованы элементы управления для определения того, какие субтитры будут отображаться.
В настоящее время программное обеспечение хорошо справляется с этим: всегда отображая только последнюю подпись, как вы, вероятно, видели в песочнице Thryduulf. Аарон Лю ( обсуждение ) 16:58, 28 октября 2024 (UTC) [ ответить ]
Я сделал это, так как именно так я узнал об этом обсуждении. (см. обсуждение User talk:Thryduulf#Image syntax ). Несколько подписей, хотя и «обрабатываются» ожидаемым образом, не являются безошибочным синтаксисом в текущем коде WP:EIS , и текущий пример песочницы Thryduulf имеет четыре случая, демонстрирующих несколько подписей, каждый из которых вызывает недопустимые ошибки изображения (страница отчета Lint) (случаи 10 и 16, 11 и 17). Эти сообщенные ошибки из-за использования синтаксиса EIS являются возражением, которое я имею в отношении этого предложения. 22:11, 1 ноября 2024 (UTC) Zinnober9 ( talk ) 22:11, 1 ноября 2024 (UTC) [ ответить ]
Да, я понимаю. У вас есть возражения, если добавление только "|inline|" перед другим заголовком не вызовет ошибку линтера? Аарон Лю ( обсуждение ) 22:23, 1 ноября 2024 (UTC) [ ответить ]
Я поздно вхожу в эту дискуссию, так что простите, если я неправильно понял. Я прочитал ее дважды, и я не понял. Предложение заключается в том, чтобы запретить людям вставлять вызовы File:/Image:, если у них нет большого пальца или безрамочного? Если это предложение, я не вижу, как это разумно. Люди вставляют такие изображения все время и делали это десятилетиями, и в целом все в порядке. Я сделал полуслучайный поиск по запросу insource:/\[\[File:/ -insource:/thumb/и получил Список чемпионатов мира по спорту , Nephrozoa , Filozoa , Страны Соединенного Королевства , Папуа-Новая Гвинея на Тихоокеанских играх 2015 года , PubChem и более 100 000 других страниц, которые, похоже, не вызывают никаких проблем. Я думаю, что здесь может быть проблема XY . – Jonesey95 ( обсуждение ) 15:31, 28 октября 2024 (UTC) [ ответить ]
Не останавливать полностью, а предупреждать о новых добавлениях через фильтр редактирования, который не остановит их, если они сохранят второй раз или включат какое-либо переопределение. Аарон Лю ( обсуждение ) 16:54, 28 октября 2024 (UTC) [ ответить ]
Но зачем вообще останавливать или предупреждать о совершенно допустимом использовании, которое появляется на более чем 100 000 страниц без проблем? Что не так, например, с изображением, используемым в информационном поле в PubChem , которое не является встроенным изображением и не использует большой палец или безрамочный? Что не так с изображением, используемым в Short story , которое не использует ни большой палец, ни безрамочный и не является встроенным? Что не так с изображениями карты в Political Divisions of Bosnia and Herzegovina , которые не используют ни большой палец, ни безрамочный и не являются встроенными? Это всего лишь три легкодоступных примера из более чем 100 000 страниц. – Jonesey95 ( talk ) 03:45, 2 ноября 2024 (UTC) [ ответить ]
В случае с PubChem я не уверен, что изображение было добавлено правильно, поскольку, насколько я помню, имя файла должно быть указано напрямую как параметр в инфобоксах. Однако, по сути, каждая статья с филогенетическим деревом, шаблоном серии или списком стран с флаговыми значками будет затронута, что не очень хорошо. Chaotic Enby ( talk · contribs ) 04:22, 2 ноября 2024 (UTC) [ ответить ]
Произойдет ли эта остановка, если кто-то добавит шаблон с помощью {{ ambox }} или аналогичного окна сообщения на страницу? Эти шаблоны используют изображения, которые не являются встроенными, безрамочными или миниатюрами. Я думаю, что эта идея может потребовать существенного переосмысления. – Jonesey95 ( talk ) 04:39, 2 ноября 2024 (UTC) [ ответить ]
Оглядываясь назад, первоначальная проблема заключалась в случайном включении очень больших (с точки зрения размеров) изображений в полный размер, что является проблемой, но она значительно уже по объему, чем предлагаемое решение (и я согласен, что это непрактично). Добавление предупреждения только тогда, когда изображение превышает, скажем, 2000 пикселей в ширину или 1200 пикселей в высоту (больше, чем стандартное разрешение 1080p), вряд ли создаст неудобства для многих страниц. Однако мое внутреннее чувство подсказывает, что это должно быть сделано программно, поскольку то, что генерирует предупреждение, должно получить размеры изображения из Commons как часть анализа викитекста. Thryduulf ( обсуждение ) 04:49, 2 ноября 2024 (UTC) [ ответ ]
Если подумать, может быть, нужен только критерий ширины, так как что-то длинное и тонкое будет просто вертикально прокручиваться без особых помех? Большинство очень широких изображений, вероятно, следует использовать {{ wide image }} или большой палец. Thryduulf ( talk ) 04:52, 2 ноября 2024 (UTC) [ ответить ]
Это может сработать, но если мы хотим решить узкую проблему широких изображений, я не уверен, сработает ли фильтр редактирования в одиночку. Насколько мне известно, regex не может зайти на страницу файла и проверить его метаданные? (Или, может быть, фильтры редактирования имеют больше возможностей, о которых я не знаю) Chaotic Enby ( обсуждение · вклад ) 15:24, 2 ноября 2024 (UTC) [ ответить ]
Я не настолько хорошо разбираюсь в фильтрах редактирования, чтобы быть уверенным, но согласен, что вряд ли они это могут сделать. Thryduulf ( обсуждение ) 15:42, 2 ноября 2024 (UTC) [ ответить ]
Как вы сказали, это потребует гораздо больше работы, чем фильтр редактирования. Проблема также в том, что допустимых новых применений встроенных изображений без шаблона довольно мало. Аарон Лю ( обсуждение ) 17:05, 2 ноября 2024 (UTC) [ ответить ]
Проблема также в том, что допустимых новых случаев использования встроенных изображений без шаблона довольно мало. Вы в этом уверены? В этой теме отмечено множество примеров? Как часто проблемные (т. е. очень большие) изображения добавляются в строку случайно? Если только это не значительно больше, чем допустимое использование встроенных изображений, то оно того не стоит. Thryduulf ( talk ) 17:11, 2 ноября 2024 (UTC) [ ответить ]
Как часто допустимые изображения добавляются в строку? По рассказам, это случается довольно редко. Фактически, его использование в NCAA Division III — один из результатов на первой странице поиска — было ошибкой, которая существовала в течение 4 лет, прежде чем я исправил ее сегодня. Я готовил параграф, в котором оценивалась первая страница результатов поиска, когда понял, что не могу найти никаких рекомендаций по использованию немаленьких встроенных изображений вместо изображений без рамок в информационных полях и таблицах, поэтому половина моей основы для этого предложения может быть неверной. Аарон Лю ( обсуждение ) 18:09, 2 ноября 2024 (UTC) [ ответить ]
В случае с коротким рассказом, могли бы вы объяснить, какое изображение? Если вас беспокоит боковая панель, я почти уверен, что мы можем исключить пространство имен шаблонов, которое также склонно к таинственному волшебству. (Кроме того, фильтр редактирования не будет предупреждать только о существующих использованиях. Он будет предупреждать только о дополнениях и новых использованиях, которые не используют некоторые, например, шаблон флага Лихтенштейна (он обнаруживает только соответствующий викитекст)) Аарон Лю ( обсуждение ) 17:02, 2 ноября 2024 (UTC) [ ответить ]
RfC: Расширенные подтвержденные ожидающие изменения (PCECP)
Следует ли добавить в Википедию новый уровень защиты от ожидающих изменений — расширенные подтвержденные ожидающие изменения (далее сокращенно PCECP)? Потрясающе Aasim 19:58, 5 ноября 2024 (UTC) [ ответить ]
Фон
WP:ARBECR (насколько я понимаю) поощряет либеральное использование защиты EC в тематических областях, разрешенных сообществом или арбитражным комитетом. Однако некоторые администраторы отказываются защищать страницы, если только не было недавних сбоев. Расширенные подтвержденные ожидающие изменения позволят пользователям, не являющимся XCON, предлагать изменения для их одобрения кем-то расширенно подтвержденным и могут быть применены превентивно к этим тематическим областям.
Предполагается, что технически возможно иметь PCECP. То есть, мы можем иметь PCECP как "[auto-accept=extended confirmed users] [review=extended confirmed users]" Прямо сейчас может быть невозможно, чтобы расширенные подтвержденные пользователи просматривали ожидающие изменения с этой защитой с текущей итерацией FlaggedRevs, но это может произойти в будущем.
Опрос (PCECP)
Поддержка (PCECP)
Поддержка по нескольким причинам: WP:ARBECR применяется только к спорным темам. Исправление опечаток не является спорной темой. Во-вторых, WP:ARBECR поощряет использование отложенных изменений, когда защита не используется. В-третьих, отложенные изменения эффективно служат для разрешения непротиворечивых запросов на редактирование без необходимости создания нового обсуждения на странице обсуждения. И, наконец, это соответствует нашей политике защиты, которая гласит, что защита не должна применяться превентивно в большинстве случаев. Потрясающе Aasim 19:58, 5 ноября 2024 (UTC) [ ответить ]
Поддержка (per... nom?) ПК — это высшая форма непротиворечивых запросов на редактирование. Аарон Лю ( обсуждение ) 20:09, 5 ноября 2024 (UTC) [ ответить ]
Это лучше, чем EC, который уже ограничивает быть свободной энциклопедией больше. Как я сказал ниже, VisualEditor позволяет гораздо больше редактирования от новых людей, чем запрос редактирования, что заставляет людей использовать редактор исходного кода. Аарон Лю ( обсуждение ) 03:52, 6 ноября 2024 (UTC) [ ответить ]
Поддержка , функционально более эффективная форма запросов на редактирование. Объем ожидающих изменений все еще достаточно мал, чтобы с этим можно было справиться, и это может побудить предоставить право рецензента ожидающих изменений большему количеству людей, которые в настоящее время просматривают запросы на редактирование, особенно в спорных темах. Chaotic Enby ( обсуждение · вклад ) 20:25, 5 ноября 2024 (UTC) [ ответить ]
Поддерживаю, что это как вариант. Я особенно ценю эффект, который это оказывает на атрибуцию (потому что изменение напрямую приписывается человеку, который его хотел, а не редактору, который обрабатывал запрос на редактирование). WhatamIdoing ( обсуждение ) 20:36, 5 ноября 2024 (UTC) [ ответ ]
Поддержка : лучшая и более прямая система, чем упреждающая расширенная подтвержденная защита с последующими запросами на редактирование на странице обсуждения. Cremastra ( u — c ) 20:42, 5 ноября 2024 (UTC) [ ответить ]
Поддержка , Pending Changes имеет возможность взять на себя эту новую задачу. PC намного лучше, чем система запросов на редактирование как для новых редакторов, так и для рецензентов. Он также устраняет недостатки шлепка ECP по всему в спорных тематических областях. Toadspike [Обсуждение] 20:53, 5 ноября 2024 (UTC) [ ответить ]
Поддержка : согласно вышеизложенному. ПК всегда находится в состоянии низкого или очень низкого уровня ожидания, поэтому он полностью способен принять это изменение. ~/Bunny pranav :< ping > 11:26, 6 ноября 2024 (UTC) [ ответить ]
Поддержка : Я был бы рад увидеть это реализованным. Grab Up - Talk 15:14, 6 ноября 2024 (UTC) [ ответить ]
Поддержка Согласен с принципом JPxG, что лучше «иметь драму в живом проекте, чем мир в мертвом», но это гораздо менее ограничительно, чем упреждающая установка защиты EC для всех страниц WP:ARBECR . С точки зрения нового редактора, он испытывает задержку в положительном опыте реализации своей правки, но пока проверяющие ожидающие изменений рецензенты оснащены, чтобы минимизировать эту задержку, этот упущение кажется чистой выгодой. Новые пользователи получат обратную связь от опытных редакторов о том, как работать в самых сложных областях контента Википедии, а не спотыкаться. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 ноября 2024 (UTC) [ ответить ]
Поддержка Я не знаю, как обстоят дела в других областях, но в моей, из запросов на редактирование, которые я вижу, многие, может быть, даже большинство из них - это точка зрения/не требующие действий/бессмыслица/оскорбления, так что если это уже только ECR, то да, больше фильтрации - это хорошо. Selfstudier ( обсуждение ) 18:17, 11 ноября 2024 (UTC) [ ответить ]
Выступать против (PCECP)
Oppose Здесь много истории, и я последовательно выступал против WP:FPPR /FlaggedRevs примерно с 2011 года. Не вскрывая старые раны по поводу того, как был реализован/завершен первоначальный пробный период, ничего из того, что произошло с тех пор, не изменило мою позицию. Я считаю, что продолжение расширения FlaggedRevs станет еще одним шагом в сторону от нашего обязательства быть свободной энциклопедией, которую каждый может редактировать, фактически не решая никаких критических проблем, с которыми наши существующие инструменты еще не справляются. Хотя предложение включает Однако некоторые администраторы отказываются защищать страницы, если только не возникнет недавнее нарушение как проблема, я считаю это положительным моментом. Фактически, в этом и заключается весь смысл; защита должна быть превентивной, и должны быть доказательства недавнего нарушения. Если страница испытывает нарушение, защита может с этим справиться. Если нет, нет необходимости ограничивать чью-либо возможность редактировать. The Wordsmith Talk to me 03:45, 6 ноября 2024 (UTC) [ ответить ]
Wordsmith , относительно « Однако некоторые администраторы отказываются защищать страницы, если только не произошло недавнего сбоя , и я считаю это положительным моментом», ради интереса, я считаю это отрицательным моментом по ряду причин, по крайней мере в тематической области WP:PIA , в основном потому, что это субъективно/недетерминировано.
Правила WP:ARBECR не зависят от субъективных оценок качества правок. Редакторам, не являющимся членами EC, разрешено только делать запросы на редактирование. Это то, что мы им говорим.
Если редакторам, не являющимся членами EC, разрешено только делать запросы на редактирование, то нет причин оставлять страницы незащищенными.
Если редакторам, не являющимся членами EC, разрешено только делать запросы на редактирование, то нам не следует сообщать им об этом через заголовки страниц обсуждений и стандартные уведомления.
Похоже, что существует культура, основанная на оптимистичном убеждении, основанном на вере, что сообщество может видеть нарушения ARBECR, делать надежные субъективные суждения, основанные на некоторой системе ценностей, и соответствующим образом справляться с ними посредством действия или бездействия. Это не соответствует моим наблюдениям.
Многие грубые нарушения остаются незамеченными, несмотря на сотни тысяч правок, вносимых десятками тысяч участников.
Численность редакторов/администраторов, которые пытаются бороться с нарушениями ARBECR, очень мала, и их выборка пространства неизбежно является примером эффекта уличного освещения .
Тематическая область PIA в значительной степени не защищена, и в ней есть тысячи статей, шаблонов, категорий, страниц обсуждений и т. д. Случайность играет большую роль в обеспечении соблюдения ARBECR по разным причинам (и, возможно, это в какой-то степени хорошо, трудно сказать).
Отсутствие у Википедии инструментов для эффективного решения проблемы обхода бана в спорных тематических областях означает, что в настоящее время невозможно определить, является ли правка, внесенная не зарегистрированным в ЕС аккаунтом или нарушающим IP WP:ARBECR , которая напоминает приемлемую правку (лично мне, со всеми моими предубеждениями и ненадежной субъективностью), результатом действий полезного человека или рецидивиста, уклоняющегося от бана/члена сторонней активистской группы, использующего бэкдор.
Против Я решительно против идеи получения еще одного уровня защиты с единственной целью его использования в качестве упреждающего средства, что никогда не было приемлемым и не должно быть приемлемым. Просто отойдите в сторону от этого мира ..... сегодня 21:25, 6 ноября 2024 (UTC) [ ответить ]
Oppose , я ненавижу ожидающие изменения. Их широкое использование сломает вики. Мы должны быть максимально приветливы к новым редакторам, и мгновенное удовлетворение от редактирования вики должно быть на как можно большем количестве страниц. — Kusma ( обсуждение ) 21:47, 6 ноября 2024 (UTC) [ ответить ]
@ Kusma Не могли бы вы пояснить, что «их широкое использование сломает вики», особенно с учетом того, что в настоящее время у нас более строгая и менее дружелюбная защита EC? Аарон Лю ( обсуждение ) 22:28, 6 ноября 2024 (UTC) [ ответить ]
Приложение A — это 53-дневный бэклог ожидающих изменений dewiki. — Kusma ( обсуждение ) 23:03, 6 ноября 2024 (UTC) [ ответить ]
У нас уже есть похожий и больший бэклог на CAT:EEP . Все, что это делает, это перемещает бэклог в интерфейс, обрабатываемый серверным программным обеспечением, которое позволяет новичкам использовать VE для своих «запросов на редактирование», где в настоящее время они должны использовать редактор исходного кода из-за ограничений на страницы обсуждения. Аарон Лю ( обсуждение ) 23:06, 6 ноября 2024 (UTC) [ ответ ]
Невыполненные работы по dewiki составляют более 18 000 страниц. В CAT:EEP их 54. Неработоспособность дополнительных систем, таких как VE, не должна влиять на то, как мы разрабатываем политику. — Kusma ( обсуждение ) 09:40, 7 ноября 2024 (UTC) [ ответить ]
Отставание не будет больше, чем отставание EEP. (Кроме того, я имел в виду, что самый высокий запрос EEP был более 3 месяцев назад, извините.) Аарон Лю ( обсуждение ) 12:23, 7 ноября 2024 (UTC) [ ответить ]
... если количество защищенных страниц не увеличится . Я ожидаю увеличения защищенных страниц от предложения, даже если ужасающее предложение о превентивной защите больших классов статей не пройдет. — Kusma ( обсуждение ) 13:08, 7 ноября 2024 (UTC) [ ответить ]
Почему так? Аарон Лю ( обсуждение ) 13:33, 7 ноября 2024 (UTC) [ ответить ]
Большинство страниц PCECP должны быть страницами ECP (пониженного уровня?), поскольку у них меньше трафика/перебоев. Поэтому количество страниц, которые будут увеличены, не должно быть таким уж большим. ~/Bunny pranav :< ping > 13:35, 7 ноября 2024 (UTC) [ ответить ]
@ Kusma Разве потеря мгновенного удовлетворения от редактирования не лучше, чем создание запроса на странице обсуждения страницы ECP и незнание того, когда он будет рассмотрен и реализован. ~/Bunny pranav :< ping > 11:25, 7 ноября 2024 (UTC) [ ответить ]
С ПК вы также не знаете, когда будут реализованы ваши изменения и будут ли они реализованы вообще. — Kusma ( обсуждение ) 13:03, 7 ноября 2024 (UTC) [ ответить ]
Oppose — Кажется ненужным и только помешает другим добросовестным редакторам редактировать, не говоря уже об усилиях сообщества, необходимых для мониторинга и рассмотрения ожидающих запросов на изменения, учитывая, что некоторые области, такие как ARBIPA, применяются к сотням тысяч страниц. Ratnahastin ( обсуждение ) 01:42, 7 ноября 2024 (UTC) [ ответ ]
@ Ratnahastin Аналогично моему вопросу выше, не будет ли это поощрять больше добросовестных редакторов по сравнению с буквальным запретом на редактирование страницы ECP? ~/Bunny pranav :< ping > 11:32, 7 ноября 2024 (UTC) [ ответить ]
Есть очень веская причина, по которой я ссылаюсь на Community Resources Against Street Hoodlums в моем предпочтительном названии для схемы защиты, и ответ, как правило, нет, поскольку тематическая область, о которой мы в первую очередь говорим, является этнополитической спорной темой, которая, как правило, привлекает сторонников, заинтересованных только в «победе в войне» в Википедии. Это касается не только новых пользователей, но и авторитетных редакторов, которые имеют твердое мнение по теме и которые могут быть поставлены в положение рецензирования этих правок, как станет ясно из прочтения любого случайного арбитражного дела, посвященного Восточной Европе или Палестине-Израилю, даже после быстрого просмотра. — Jéské Couriano v^_^v темы критика 18:21, 7 ноября 2024 (UTC) [ ответить ]
Разве эти проблемы не видны в той же степени в запросах на редактирование, если они существуют? Аарон Лю ( обсуждение ) 19:10, 7 ноября 2024 (UTC) [ ответить ]
POV-pushing не является явно разрушительным/легкомысленным и более не подлежит удалению в запросах на редактирование. Аарон Лю ( обсуждение ) 16:45, 10 ноября 2024 (UTC) [ ответить ]
Но запросы на редактирование затрудняют фактическое воплощение этой точки зрения в активной статье. — Jéské Couriano v^_^v темы критика 17:22, 11 ноября 2024 (UTC) [ ответить ]
То же самое с ожидающими изменениями. Аарон Лю ( обсуждение ) 17:36, 11 ноября 2024 (UTC) [ ответить ]
Может быть, в какой-то фантастической стране, где редактирование не обязательно должно быть привязано к истории статьи. — Jéské Couriano v^_^v темы критика 18:08, 11 ноября 2024 (UTC) [ ответить ]
За исключением того, как именно так работают запросы на извлечение на GitHub. Вы вносите правки, а кто-то с правами рецензента одобряет их, чтобы завершить слияние. Здесь происходит «коммит», но ревизия не видна, пока не будет проверена и одобрена. Запросы на редактирование не являются запросами на извлечение, они эквивалентны «проблемам» на GitHub. Отлично Aasim 19:03, 11 ноября 2024 (UTC) [ ответить ]
Это может показаться неожиданным, но Wikipedia — это не GitHub. Хотя они оба являются совместными проектами, они очень отличаются во многих других отношениях. Thryduulf ( talk ) 19:20, 11 ноября 2024 (UTC) [ ответить ]
Oppose , как сказал JSS . Мне немного не по себе от того, в какой степени мы, по-видимому, приняли упреждающую защиту статей в спорных областях. Это может быть удобным способом уменьшить драму, с которой нам, администраторам и опытным пользователям, приходится иметь дело... но только ценой отказа от основного принципа, что редактировать может каждый. Я бы предпочел драму на живом проекте, чем мир на мертвом. jp × g 🗯️ 18:16, 7 ноября 2024 (UTC) [ ответить ]
Oppose Я один из тех администраторов, которые любят видеть разрушение, прежде чем защищать. Lectonar ( обсуждение ) 08:48, 8 ноября 2024 (UTC) [ ответить ]
Oppose как ненужное, похоже на решение в поисках проблемы. Более того, это *есть* Википедия, энциклопедия, которую может редактировать каждый; упреждающая защита страниц отпугивает вклады от новых редакторов. - Fastily 22:36, 8 ноября 2024 (UTC) [ ответить ]
Слабое противодействие Я понимаю, где эта защита была бы полезна. Но я просто думаю, что что-то может быть защищено EC или нет. Не обязательно думаю, что добавление еще одного уровня бюрократии особенно полезно. -- Takipoint123 ( обсуждение ) 05:14, 11 ноября 2024 (UTC) [ ответить ]
Нейтральный (PCECP)
Я ясно выразил свое несогласие со всеми формами FlaggedRevisions с 2011 года. Однако я не буду официально выступать против этого, чтобы избежать срыва процесса людьми, опровергающими мое несогласие. — Jéské Couriano v^_^v темы критика 02:36, 6 ноября 2024 (UTC) [ ответить ]
Я не фанат текущих ожидаемых изменений, поэтому я не могу это поддержать. Но это также не повлияет на мое редактирование, поэтому я не буду против этого, если это поможет другим.-- LCU Активно Неинтересно « @ » ° ∆t ° 14:32 , 6 ноября 2024 (UTC) [ ответить ]
Обсуждение (PCECP)
Кто-то, кто является экспертом в настройке mw:Extension:FlaggedRevs, должен будет подтвердить, что возможно одновременно иметь наш текущий тип защиты отложенных изменений и этот новый тип защиты отложенных изменений. Текущая конфигурация enwiki FlaggedRevs выглядит примерно так, как показано ниже, и может быть нелегкой в настройке. Вы можете отправить ping Ladsgroup или разместить сообщение на WP:VPT для получения помощи.
По сути, я пришел сюда, чтобы спросить, возможно ли это вообще или потребуется ли участие разработчиков WMMF или что-то в этом роде.
Для тех, кто не знаком, ожидающие изменения — это не то же самое, что помеченные ревизии, используемые на de.wp. PC был разработан фондом специально для этого проекта после того, как мы его попросили. У нас также был WP:PC2, но никто толком не знал, что это такое и как его использовать, и его поддержка была прекращена. Просто отойдите в сторону от этого мира ..... сегодня 21:21, 6 ноября 2024 (UTC) [ ответить ]
Является ли PC2 признаком возможности реализации? Аарон Лю ( обсуждение ) 22:27, 6 ноября 2024 (UTC) [ ответить ]
Зависит от того, что именно подразумевается под «реализацией». Конфигурация, в которой изменения, сделанные неподтвержденными пользователями, требуют проверки рецензентами, вероятно, будет похожа на то, что было удалено в gerrit:/r/334511 для реализации T156448 (удаление PC2). Я не знаю, возможна ли конфигурация, в которой изменения, сделанные неподтвержденными пользователями, могут быть просмотрены любым пользователем с расширенным подтверждением, в то время как обычные PC по-прежнему могут быть просмотрены только рецензентами. Anomie ⚔ 13:32, 7 ноября 2024 (UTC) [ ответить ]
Если посмотреть на документацию MediaWiki, то это невозможно. Тем не менее, в настоящее время предложение предполагает, что это возможно, и мы должны работать с этим (хотя я бы также поддержал разрешение всем расширенно подтвержденным просматривать все ожидающие изменения). Аарон Лю ( обсуждение ) 13:56, 7 ноября 2024 (UTC) [ ответ ]
Я думаю, что сводное заявление RfC немного неполное. Я понимаю, что функция ожидающих изменений вводит набор прав, которые могут быть назначены соответствующим группам пользователей. Я считаю, что вся логика основана на правах пользователей, поэтому нет способа обозначить, что одна статья может быть автоматически проверена одной группой пользователей, а другая статья может быть автоматически проверена другой группой пользователей. Таким образом, если только предложение не заключается в замене автоматически подтвержденных ожидающих изменений на расширенные подтвержденные ожидающие изменения, я не думаю, что указание «включено» в сводке является адекватным описанием. И если предложение заключается в замене автоматически подтвержденных ожидающих изменений, я думаю, что это должно быть явно указано. isaacl ( talk ) 22:06, 6 ноября 2024 (UTC) [ ответить ]
Предложение предполагает, что сосуществование технически возможно. Аарон Лю ( обсуждение ) 22:28, 6 ноября 2024 (UTC) [ ответить ]
В предложении не уточнялось, предполагает ли оно возможность сосуществования или возможность его включения, что может означать замену. Таким образом, я считаю, что сводное заявление (до временной метки, которая отображается в центральном списке RfC) является неполным. isaacl ( talk ) 22:31, 6 ноября 2024 (UTC) [ ответить ]
При повторном прочтении предполагается, что технически возможно иметь PCECP , но это явно не подразумевает сосуществование, вот как я это интерпретирую. В любом случае, было бы замечательно услышать от @ Awesome Aasim об этом. Аарон Лю ( обсуждение ) 22:42, 6 ноября 2024 (UTC) [ ответить ]
Ключевой вопрос, который следует прояснить, заключается в том, будет ли предложение включать в себя оба варианта или заменить текущий вариант новой версией. (Это связано с вопросом о том, требуется ли участие арбитражного комитета.) Кроме того, было бы правильнее не использовать в резюме ни одного слова, которое подразумевает, что единственной стоимостью является включение переключателя. isaacl ( talk ) 22:49, 6 ноября 2024 (UTC) [ ответить ]
Предполагается, что у нас может быть PC1, где только рецензенты могут одобрять правки, и PCECP, где только расширенно подтвержденные пользователи могут одобрять правки И вносить правки без необходимости одобрения. С текущей итерацией я не знаю, возможно ли это технически. Если для этого требуется переписать расширение или заменить его, это нормально. Если что-то все еще неясно, пожалуйста, дайте мне знать. Отлично Aasim 23:06, 6 ноября 2024 (UTC) [ ответить ]
Предлагаю изменить краткое изложение на что-то вроде: «Следует ли добавить в Википедию новый уровень защиты от ожидающих изменений – расширенные подтвержденные ожидающие изменения (далее сокращенно PCECP)?». В следующем абзаце можно дать дополнительные пояснения относительно того, кто будет проходить автоматическую проверку и кто будет выступать в качестве рецензентов с новым предлагаемым уровнем. isaacl ( talk ) 23:19, 6 ноября 2024 (UTC) [ reply ]
Ладно, готово. Я немного подправил формулировку. Потрясающе Aasim 23:40, 6 ноября 2024 (UTC) [ ответить ]
Я думаю, что включение части упреждающей защиты в заявление о фоновом режиме вносит путаницу. Насколько мне известно, упреждающая защита и следует ли нам использовать PCECP вместо ECP — это отдельные вопросы. Аарон Лю ( обсуждение ) 19:11, 7 ноября 2024 (UTC) [ ответить ]
В2: Если это предложение будет принято, следует ли применять PCECP в качестве упреждающего метода?WP:АРБЕКРтемы?
Особенно в статьях с низким трафиком, а также на всех страницах обсуждений. WP:ECP по-прежнему останется вариантом для применения поверх PCECP. Потрясающе Aasim 19:58, 5 ноября 2024 (UTC) [ ответить ]
Поддержка (превентивная PCECP)
Поддержка моих причин в Q1. Потрясающе Aasim 19:58, 5 ноября 2024 (UTC) [ ответить ]
Немного неоднозначно отношусь к защите страниц обсуждений, но полагаю, что это повысило бы значимость страниц с низким трафиком. Аарон Лю ( обсуждение ) 20:13, 5 ноября 2024 (UTC) [ ответить ]
Поддержка , в том числе на страницах обсуждения. Поскольку запросы на редактирование в основном обрабатываются через ожидающие изменения, защита страниц обсуждения также должна ограничить помехи и неконструктивные комментарии, которые часто встречаются там. (Изменив свое мнение, я не думаю, что применение PCECP на всех страницах было бы конструктивным решением. Правила ARBECR ограничивают участие редакторов с расширенным подтверждением, но дух правил заключается в том, чтобы применять это только на страницах с фактическими помехами, а не превентивно. 20:49, 7 ноября 2024 (UTC)) Chaotic Enby ( обсуждение · вклад ) 20:21, 5 ноября 2024 (UTC) [ ответить ]
Поддержка Я полностью не соглашусь с аргументом "нет" - мы должны упреждающе применять ECP (даже без ожидающих изменений). Это извращение логики - говорить "вы не можете (согласно политике) нажать эту кнопку", а затем отказываться фактически технически остановить вас от нажатия кнопки, хотя мы знаем, что вы могли бы это сделать. * Pppery * это началось... 20:52, 5 ноября 2024 (UTC) [ ответить ]
Поддержка ( вызвано ботом ) : Хотя я не согласен с ECR в целом, это лучший способ обеспечить его соблюдение, пока он существует. Конструктивные «запросы на редактирование» могут быть приняты, а правки, с которыми люди не согласны, могут быть легко отменены. Я немного обеспокоен тем, как это может повлиять на отложенные изменения (которые на данный момент имеют довольно небольшое количество активных рецензентов), но я уверен, что это можно выяснить. C F A 💬 23:41, 5 ноября 2024 (UTC) [ ответить ]
Противостоять (упреждающий PCECP)
Нет, я не думаю, что это необходимо в данный момент. Я думаю, что это должно быть применимо там, но я не чувствую, что это необходимый шаг в данный момент. Мы могли бы вернуться к этому позже. WhatamIdoing ( talk ) 20:37, 5 ноября 2024 (UTC) [ ответить ]
Нет, нам все равно не следует защищать превентивно. Подождите, пока не произойдет сбой, а затем выбирайте между PCXC или обычной защитой XC (я бы решительно отдал предпочтение первому по причинам, указанным выше). Cremastra ( u — c ) 20:43, 5 ноября 2024 (UTC) [ ответить ]
Mu - Это вопрос, который следует задать позже , а не одновременно с , поскольку ArbCom захочет рассмотреть любое такое предложение. — Jéské Couriano v^_^v темы критика 02:38, 6 ноября 2024 (UTC) [ ответить ]
Нет, я считаю , что это плохая идея. Критики Википедии уже используют идею о том, что она контролируется избранной группой, это только усилит это заблуждение. -- LCU Активно Неинтересно « @ » ° ∆t ° 14:36, 6 ноября 2024 (UTC) [ ответить ]
Абсолютно нет. Защита не нужна, если нет сбоев. Количество защищенных страниц должно быть небольшим, а количество страниц, которые кричат «посмотрите на меня!» в вашем списке наблюдения (все, что находится в разделе «Ожидаемые изменения»), должно быть как можно ближе к нулю. — Kusma ( обсуждение ) 21:44, 6 ноября 2024 (UTC) [ ответить ]
Нет необходимости в защите, если нет сбоев. Проблема в том, что ограничение ECR вводится в ответ на широкомасштабные сбои, на этот раз по всей тематической области в целом. Игнорирование точки зрения, явное включение непроверяемой или ложной (ненадежной) информации и многое другое представляет серьезную угрозу сбоя проекта. Если бы WP:ARBECR применялся широко без какой-либо защиты, я бы согласился, но WP:ARBECR применяется в ответ на сбои (или серьезную угрозу), а не упреждающе. Возьмем , к примеру, это долгое обсуждение ANI, которое закончилось WP:GS для русско-украинской войны (и ограничений ECR). А что касается Арбитражного комитета, ArbCom является последним средством , когда все другие попытки разрешить сбои терпят неудачу. См. WP:ARBPIA WP:ARBPIA2 WP:ARBPIA3 WP:ARBPIA4 . Самая ранняя ссылка на предшественника ARBECR в этом деле относится к третьему делу ArbCom. Отсутствие защиты в тематической области, которая имеет высокий риск сбоя, сродни отсутствию защиты шаблона с высоким риском. Единственное отличие в том, что небрежное редактирование шаблона с высоким риском создает технические проблемы, в то время как небрежное редактирование тематической области с высоким риском создает проблемы с контентом.
Либо страница защищена технически (что обеспечивает выполнение решения сообщества или ArbCom о том, что только определенные редакторы допускаются в тематические области), либо страница не защищена технически, но защищена социально (что затем дает возможность уклониться). Я не вижу, чтобы эта ситуация отличалась от бана редактора на всем сайте, а затем отказа блокировать его на том основании, что «блокировки должны использоваться только для предотвращения сбоев», игнорируя обстоятельства, приведшие к бану сайта.
PCECP позволит лучше обеспечить соблюдение аспекта сообщества. Новые редакторы не будут кусаться, если они найдут что-то, что нужно исправить, например, опечатку, они могут внести правку, и она будет одобрена. Более спорные правки будут отправлены на страницу обсуждения, где редакторы, не забаненные в этой тематической области, смогут ее обсудить. А откровенное продвижение POV и тому подобное будет отменено и никогда не будет даже увидено читателями.
Рабочий процесс будет выглядеть так: новый/аноновый пользователь вносит правку → правка задерживается для проверки → расширенно подтвержденный пользователь одобряет правку. Вместо текущего рабочего процесса (и причины, по которой упреждающий ECP не популярен): новый/аноновый пользователь вносит правку → пользователя встречает сообщение «эта страница защищена» → пользователь описывает, что он хотел бы изменить, но в плохо сформулированной форме → запрос на редактирование закрывается как «неясный» или что-то подобное. Awesome Aasim 14:21, 11 ноября 2024 (UTC) [ ответить ]
Согласно моему голосу выше. Ратнахастин ( обсуждение ) 09:00, 7 ноября 2024 (UTC) [ ответить ]
Абсолютно нет. Защита должна быть только профилактической. Кусма выразился лучше меня. Thryduulf ( обсуждение ) 13:49, 7 ноября 2024 (UTC) [ ответить ]
Согласно моему комментарию выше. jp × g 🗯️ 18:17, 7 ноября 2024 (UTC) [ ответить ]
Нет; см. мой комментарий выше. Я предпочитаю видеть разрушение, прежде чем защищать. Lectonar ( обсуждение ) 08:51, 8 ноября 2024 (UTC) [ ответить ]
Нет. Мы должны быстрее применять защиту в этих темах, чем в других местах, но не упреждающе, за исключением очень заметных страниц (которые в этих темах, вероятно, в любом случае защищены ECP). Любитель животных |666| 17:18, 11 ноября 2024 (UTC) [ ответить ]
Нейтральный (упреждающий PCECP)
Обсуждение (превентивное PCECP)
@ Jéské Couriano Не могли бы вы дать ссылку на указанное обсуждение ArbCom? Аарон Лю ( обсуждение ) 03:51, 6 ноября 2024 (UTC) [ ответить ]
Я не говорю, что такое обсуждение существует, но изменения в арбитражных мерах/дискреционных санкциях — это то, что они хотели бы взвесить. Арбитражная политика (включая темы WP:Contentious ) находится в их рулевой рубке, и это будет иметь серьезные последствия для WP:CT/AI и любых других случаев, когда ArbCom (а не отдельные редакторы, как дискреционная санкция) должен будет прибегнуть к правилу 500/30 в качестве явного средства правовой защиты. — Jéské Couriano v^_^v темы критика 04:58, 6 ноября 2024 (UTC) [ ответить ]
Это не мое прочтение WP:ARBECR . В частности, на любой странице, где ограничение не применяется через расширенную подтвержденную защиту, это ограничение может быть применено... с помощью ожидающих изменений ... (жирный шрифт добавлен мной для акцента). Но если есть консенсус не использовать это превентивно, пусть так и будет. Потрясающе Aasim 05:13, 6 ноября 2024 (UTC) [ ответить ]
Хотя я ценю дальновидность, что PCECP может захотеть использоваться в областях Arb, это кажется значительным размыванием разграничения между ролью Комитета и ролью сообщества. Традиционно спорные темы были сферой ArbCom, а общие санкции были сферой Сообщества. Часть логики сводится к тому, кто берет на себя вину, когда что-то идет не так. Сообщество не должно брать на себя вину, когда ArbCom принимает решение, и наоборот. Часть логики заключается в разделении властей. Если сообщество хочет сказать «ArbCom, вы будете обеспечивать это, и да поможет вам Бог», то это должно быть сделано путем внесения поправок в ArbPol . Часть логики носит практический характер. Если сообщество создает процесс, который дополняет существующий процесс Arb, что произойдет, когда Arbs захочет изменить этот процесс? Или даже полностью его прекратить? Итог: принятие PCECP для ARBECR, безусловно, является тем, что ArbCom мог бы сделать. Но я бы попросил сообщество рассмотреть более широкие структурные проблемы, которые возникнут, если сообщество примет его от имени ArbCom. CaptainEek Edits Ho Cap'n! ⚓ 05:18, 7 ноября 2024 (UTC) [ ответить ]
Интересно. Я бы сказал, что ArbCom должен иметь возможность переопределять мнение сообщества, если они действительно считают такие действия уместными и достойными потенциальной ответной реакции. Аарон Лю ( обсуждение ) 12:30, 7 ноября 2024 (UTC) [ ответить ]
Просто терминологическое примечание, хотя я понимаю, что многие думают об общих санкциях именно так, на странице Wikipedia:Общие санкции они определены как ... тип санкций Wikipedia, которые применяются ко всем редакторам, работающим в определенной тематической области. ... Общие санкции — это меры, используемые сообществом или Арбитражным комитетом («ArbCom») для улучшения атмосферы редактирования статьи или тематической области. Таким образом, структура спорных тем является формой общих санкций. isaacl ( обсуждение ) 15:22, 7 ноября 2024 (UTC) [ ответить ]
Что касается общего момента: я согласен, что сообществу обременительно налагать общую санкцию, которая добавляется поверх конкретного арбитражного средства правовой защиты. Я бы предпочел, чтобы сообщество работало с арбитражным комитетом над внесением поправок в свое средство правовой защиты, что облегчило бы сохранение описания санкции и ведение журнала ее применения вместе, а не разделение. (Я понимаю, что для этого конкретного предложения ведение журнала применения не является проблемой.) isaacl ( talk ) 15:30, 7 ноября 2024 (UTC) [ ответить ]
Расширенное подтверждение началось как концепция arbcom — 500 правок/30 дней — которую сообщество затем решило принять. Затем ArbCom решил сделать так, чтобы его средство правовой защиты соответствовало версии сообщества — так, что если бы сообщество решило, что расширенное подтверждение будет 1000 правок/90 дней, все ограничения ArbCom обновились бы. Я считаю, что это здоровый цикл обратной связи между ArbCom и сообществом. Сообщество могло бы четко выбрать (по крайней мере, на уровне политики, учитывая некоторые технические проблемы) принятие PCECP. Оно могло бы решить применить это к некоторым/всем страницам. Если ему удобно сказать, что оно хочет делегировать некоторые из страниц, которые это применимо, Арбитражному комитету, я думаю, что он может сделать это, не внося поправки в ArbPol. Однако я думаю, что ArbCom мог бы решить, что PCECP не будет применяться в некоторых/всех областях CTOP, учитывая, что Комитет освобожден от консенсуса в областях, входящих в его сферу действия. И поэтому в конечном итоге может быть разумнее сделать то, что предлагает isaacl. Best, Barkeep49 ( обсуждение ) 16:02, 7 ноября 2024 (UTC) [ ответить ]
Процедура "спорных тем" кажется чем-то, что сообщество должно полностью отражать и что в конечном итоге должны выработать и сообщество, и ArbCom. Если что-то расходится, то, вероятно, есть веская причина, по которой это расходится.
Что касается более широких структурных проблем, которые возникли бы, если бы сообщество приняло его от имени ArbCom , то уже существуют структурные проблемы с общими санкциями из-за неспособности сообщества принять новую процедуру CTOP для новых спорных тем. Хотя сообщество приняло содержание WP:ARBECR для других тематических областей, таких как WP:RUSUKR , они не принимают его по ссылке, а копируют весь текст дословно. Awesome Aasim 17:13, 7 ноября 2024 (UTC) [ ответить ]
Это не та же самая структурная проблема. Сообщество не много обсуждало принятие фреймворка спорных тем для собственного использования (по моему мнению, потому что это очень шаткое обсуждение, которое не интересует достаточно редакторов, чтобы прийти к консенсусу), но это не мешает тому, как арбитражный комитет использует фреймворк спорных тем. Это предложение предполагает, что сообщество автоматически накладывает свою собственную общую санкцию поверх любого случая, когда арбитражный комитет решает ввести конкретную санкцию. Таким образом, комитет должен будет каждый раз рассматривать, следует ли отменять дополнение сообщества, и запросы на внесение поправок, возможно, придется направлять как комитету, так и сообществу. isaacl ( talk ) 17:33, 7 ноября 2024 (UTC) [ ответить ]
До спорных тем были дискреционные санкции. Они стали очень запутанными, и поэтому комитет создал спорные темы, чтобы помочь прояснить границу между сообществом и комитетом (раскрытие информации: я помогаю составлять большую часть этой работы). В рамках этого комитет также установил способы, которыми сообщество может привязываться к спорным темам, если оно того захочет. Так что для сообщества этот выбор не сделан, что нормально. Но я делаю это, это область, в которой, в целом, ArbCom справляется лучше, чем сообщество, потому что больше внимания уделяется согласованности между областями, и когда возникает проблема (в основном только в этой одной области), я обнаружил, что ArbCom более гибко решает ее. Но сообщество также более готово принять GS, чем ArbCom — назначить что-то CT (что, я думаю, является хорошей идеей в целом), и поэтому достижение сообществом консенсуса о том, как оно хочет, если вообще хочет, привязываться к CT (и его эволюциям) или предпочтет заниматься своими делами (включая простое отражение того, что происходит в CT в то время, но не последующих изменений), вероятно, было бы хорошей мета-дискуссией. Но это также не кажется необходимым для этого конкретного предложения. Всего наилучшего, Barkeep49 ( обсуждение ) 17:41, 7 ноября 2024 (UTC) [ ответить ]
В3: Если это предложение не будет принято, следует ли применять ЕСП в качестве превентивного метода к статьям, подпадающим под действиеWP:АРБЕКРтемы?
Поддержка (упреждающий ECP)
Поддержка как второй вариант, но только для статей. Страницы обсуждения могут быть принудительно защищены только через возвраты и краткие защиты, поэтому я не вижу особых причин, по которым их следует защищать. Потрясающе Aasim 19:58, 5 ноября 2024 (UTC) [ ответить ]
Поддержка статей по Aasim. Страницы обсуждения по-прежнему должны быть открыты для запросов на редактирование. (Также меняю свое мнение, как указано выше. Если что, нам следует уточнить ARBECR, чтобы ограничение 500-30 применялось только в тех случаях, когда это необходимо, а не автоматически, для устранения неоднозначности. 20:52, 7 ноября 2024 (UTC)) Chaotic Enby ( обсуждение · вклад ) 20:20, 5 ноября 2024 (UTC) [ ответить ]
Поддерживаю согласно моему комментарию в предыдущем разделе. * Pppery * началось... 20:52, 5 ноября 2024 (UTC) [ ответить ]
Я согласен с Chaotic Enby и Pppery выше и считаю, что все статьи CT должны быть защищены. Я вообще не сторонник защиты страниц обсуждения, но это правда, что многие страницы обсуждения CT являются выгребными ямами ненависти, поэтому я не уверен, где я сижу по защите страниц обсуждения. Toadspike [Обсуждение] 20:57, 5 ноября 2024 (UTC) [ ответить ]
Противостоять (упреждающий ECP)
Oppose, потому что я считаю, что это плохая идея. Во-первых, простое составление списка всех охваченных статей может вызвать споры, которые нам не нужны. (Эта статья может быть охвачена, но действительно ли она охвачена? Разумные люди могут легко не согласиться с тем, являются ли некоторые статьи «в основном» об ограниченной области или «частично», и, следовательно, о том, применяется ли правило.) Во-вторых, когда речь идет о серьезной и очевидной проблеме, такой как вопиющий вандализм, было бы лучше, чтобы IP отменил его, чем бездумно следовать правилам. Важно помнить, что наши правила существуют как средство для достижения цели. Мы следуем им, потому что и в той мере, в какой они помогают в целом. Мы ожидаем, что администраторы и другие редакторы будут проявлять осмотрительность. Наша политика заключается в том, что Wikipedia: Если правило мешает вам улучшать или поддерживать Wikipedia, игнорируйте его. Это предложение о том, чтобы объявить, что политика IAR никогда не применяется к правилу о том, кто обычно должен редактировать эти статьи, и что проявление осмотрительности не допускается. WhatamIdoing ( обсуждение ) 20:42, 5 ноября 2024 (UTC) [ ответить ]
Хотя уже есть прецедент для упреждающей защиты, например, RFPP, мне это не нравится. Во-первых, поскольку страницы обсуждения (и, как следствие, запросы на редактирование) не могут использовать визуальный редактор, это значительно усложняет для новичков внесение правок, часто излишне в статьи, где нет никаких помех. Аарон Лю ( обсуждение ) 23:47, 5 ноября 2024 (UTC) [ ответить ]
Mu - Это в основном мое прочтение правила 500/30 в письменном виде. Все, что попадает под тему 500/30, должно быть подвергнуто XCP при обнаружении. Стоит отметить, что я не считаю это чем-то близким к идеалу, но и ArbCom тоже так не считал , и, учитывая обстоятельства реального этнополитического конфликта, который в последнее время только(что, в свою очередь, подпитывает сбои), единственным другим - даже худшим - вариантом была бы полная защита по всем направлениям во всем районе. Так почему же я не отстаиваю поддержку? Потому что, как и в вопросе выше, это ставит телегу впереди лошади, и это лучше обсуждать после окончания этого RfC, а не одновременно с . — Jéské Couriano v^_^v темы критика 02:47, 6 ноября 2024 (UTC) [ ответить ]
Конечно нет , страницы, которые не испытывают сбоев, должны быть открыты для редактирования. Ожидающие изменения никогда не должны широко использоваться, чтобы избежать ситуаций, подобных совершенно абсурдному 53-дневному бэклогу dewiki. — Kusma ( обсуждение ) 21:53, 6 ноября 2024 (UTC) [ ответить ]
Очень сильное противодействие , опять же, Кузма выразился превосходно. Защита всегда должна быть исключением, а не нормой. Даже в израильско-палестинской тематической области большинство статей не испытывают сбоев. Thryduulf ( обсуждение ) 13:50, 7 ноября 2024 (UTC) [ ответить ]
WP:RUNAWAY суммирует некоторые из тактик, используемых редакторами-нарушителями: а именно, их правки ограничиваются небольшим количеством страниц, которые просматривает очень мало людей , и наоборот, их правки могут быть распределены по широкому кругу статей, чтобы снизить вероятность того, что любой пользователь просматривает достаточное количество затронутых статей, чтобы заметить нарушения . Если пользователь действительно настаивает на продвижении своей повестки дня, он может не иметь возможности продвинуть ее на больших страницах, он может продвинуть ее на некоторых из более мелких страниц, где его правки могут оставаться незамеченными в течение месяцев, если не лет. Затем исследователи, раскапывающие информацию, наткнутся на статью POV и слепо процитируют ее. Хотя Википедию никогда не следует ссылаться в качестве источника, это все равно происходит. Потрясающе Aasim 14:35, 11 ноября 2024 (UTC) [ ответить ]
Согласно моему комментарию выше. jp × g 🗯️ 18:18, 7 ноября 2024 (UTC) [ ответить ]
Нет, см. мой комментарий к другим вопросам. Lectonar ( обсуждение ) 08:52, 8 ноября 2024 (UTC) [ ответить ]
Нет, мы никогда не должны защищать страницы превентивно. Cremastra ( u — c ) 16:35, 10 ноября 2024 (UTC) [ ответить ]
Нет, за исключением самых известных статей по каждой теме CT (вероятно, уже сделанных по текущим CT, но актуальных для новых). Любитель животных |666| 19:47, 11 ноября 2024 (UTC) [ ответить ]
Нейтральный (упреждающий ECP)
Обсуждение (превентивный ECP)
Я думаю, этот вопрос следует изменить на «...статьи по темам WP:ARBECR?». Аарон Лю ( обсуждение ) 20:11, 5 ноября 2024 (UTC) [ ответить ]
Как я уже говорил в другом комментарии , если эта концепция получит одобрение, я считаю, что сообществу лучше всего будет поработать с арбитражным комитетом, чтобы внести поправки в ее средство правовой защиты. isaacl ( обсуждение ) 15:34, 7 ноября 2024 (UTC) [ ответить ]
И как я уже говорил в другом комментарии, хотя я думаю, что сообщество может это сделать, я согласен с isaac, что было бы лучше сделать это таким образом, чтобы это работало с комитетом. Всего наилучшего, Barkeep49 ( обсуждение ) 16:03, 7 ноября 2024 (UTC) [ ответить ]
Общее обсуждение
Поскольку мы предполагаем, что PCECP возможен, а последние два вопроса определенно касаются политики, я думаю, что, возможно, это следует отнести к VPP, изменив заголовок на что-то вроде «Расширенные подтвержденные ожидающие изменения и упреждающая защита в спорных темах», чтобы отразить немного больший, чем рекламируется, объем? Аарон Лю ( обсуждение ) 23:53, 5 ноября 2024 (UTC) [ ответить ]
Я думаю, что предложения по политике здесь тоже приемлемы, хотя я понимаю вашу точку зрения. Хотя определенно есть совпадение. Это и запрос на техническое изменение, и установление политики/руководящих принципов вокруг этого технического изменения (или его отсутствия). Потрясающе Aasim 00:26, 6 ноября 2024 (UTC) [ ответить ]
Если это предложение будет принято, я предполагаю, что мы вернем ORANGELOCK , который использовался для первоначального воплощения Pending Changes Level 2. Предлагаемая блокировка уже есть в File:Pending_Changes_Protected_Level_2.svg , хотя ее нужно исправить с точки зрения имени (вероятно, должно быть что-то вроде Pending-level-2-protection-shackle.pngили Extended-pending-protection-shackle.png), кода SVG (верхняя кривая немного обрезана) и цвета (вероятно, должен быть темнее, но все еще четко отличаться от REDLOCK ). — python coder ( talk | contribs ) 21:43, 8 ноября 2024 (UTC) [ ответить ]
Я думаю, что светло-голубой цвет лучше для этого. Но в любом случае нам, вероятно, понадобится замок с галочкой и буквой "E" для расширенного подтверждения. Потрясающе Aasim 22:22, 8 ноября 2024 (UTC) [ ответить ]
Если мы добавим фильтр злоупотреблений, который блокирует строку «peepeepoopoo» и ее вариации, такие как добавление пробелов, это гарантированный вандализм, см. эти правки TheWikipede ( обсуждение ) 22:34, 5 ноября 2024 (UTC) [ ответ ]
Для запросов на фильтр редактирования есть специальная страница Wikipedia:Edit filter/Requested ( WP:EFR ), где, скорее всего, находятся люди, наиболее осведомленные о соответствующих соображениях и любых предыдущих запросах/обсуждениях, поэтому посмотрите ее. Thryduulf ( обсуждение ) 22:55, 5 ноября 2024 (UTC) [ ответить ]
Фильтр 46 ( история · журнал) («Какашки» вандализм) уже существует. WP:EFN , вероятно, лучшее место для публикации об этом. C F A 💬 23:48, 5 ноября 2024 (UTC) [ ответить ]
Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.
Хорошо, чтобы прояснить это, контент НЕ должен быть удален. Контент NSFW и NSFl должен быть показан, потому что Википедия - сайт, свободный от цензуры. Ни один контент не должен рассматриваться как приоритетный, и контент NSFW и NSFL должен рассматриваться так же, как и все остальные. Теперь я внесу предложение, что поскольку многие дети используют Википедию для изучения чего-либо, они могут столкнуться с этими вещами. В целях безопасности кровавый, оскорбительный и сексуальный контент должен иметь размытие или черный экран, и чтобы просмотреть изображение, они должны нажать на изображение и нажать Мне больше 18 или что-то вроде того, например, они натыкаются на русско-украинскую войну. В этой статье есть кровавая фотография. Вместо этого должно быть размытие или черный ящик, описание изображения все еще остается, и для того, чтобы просмотреть содержимое, они должны нажать на изображение, и оно запросит проверку, например, когда вы нажимаете на изображение, оно говорит, что на этом изображении есть кровь или что-то в этом роде, затем оно говорит, что вам должно быть 18 лет, чтобы просмотреть изображение или что-то в этом роде, затем есть кнопка с надписью «Мне больше 18 лет» или что-то в этом роде, затем, чтобы просмотреть содержимое, просто нажмите кнопку. Если это каким-то образом не работает, по крайней мере, добавьте отказ от ответственности вверху, говорящий, что в нем есть плохие вещи. Так что да, вот мое предложение. Datawikiperson ( talk ) 11:11, 6 ноября 2024 (UTC) [ ответить ]
Почему вы думаете, что дети не будут лгать и просто нажимать «Мне 18»? Также см. эффект Стризанда . 331dot ( обсуждение ) 14:23, 6 ноября 2024 (UTC) [ ответить ]
Это предлагалось много раз ранее. Это не сработало по нескольким причинам, включая то, что должно быть подвергнуто цензуре, в значительной степени зависящее от контекста и культуры (и даже субкультуры) — например, человек А может захотеть размыть фотографию женщины, кормящей грудью, но не фотографию огнестрельного ранения, в то время как человек Б может захотеть прямо противоположного. Если вы придерживаетесь точки зрения, что все, что кто-то хочет размыть, должно быть размыто, даже если другие этого не хотят, но это приведет к крайностям, таким как все изображения людей, которые размываются. Вторая причина заключается в том, что нет практической причины применять эту настройку в массовом порядке. На первый взгляд, изображения в Commons:Category:Sex и подкатегориях кажутся довольно бесспорными, но это очень быстро разваливается, когда вы видите, какие изображения это зацепит, например:
Секс → Книги о сексе → Книги о человеческой сексуальности, Книги о ЛГБТ
Пол → Биология пола → Определение пола → Гаплодиплоидия
Секс → Секс в искусстве → Секс (текст) → CIL XIII 000129 → Музей Сен-Раймон, Ra 196
Секс → Эякуляция → Эякуляция людей → Женская эякуляция → Руфус, Ле Пуаль
Пол → Женщины → Женские символы → Женские значки → Пустые заполнители для людей (женщины)
Так что это должно быть установлено по крайней мере для каждой категории, без подкатегорий, а их на Commons не менее тысяч. На уровне отдельных изображений вы смотрите на более чем 110 миллионов. И это при условии, что вы можете получить согласие (согласно выше). Thryduulf ( talk ) 11:57, 6 ноября 2024 (UTC) [ ответить ]
Я согласен с тем, что сказали выше Лектонар и Тридуулф. Если бы это было реализовано, то (поскольку большинство наших редакторов американцы) это было бы очень американоцентричным взглядом на то, что небезопасно - это был бы взгляд человека А Тридуулфа, а не мой. Единственный способ гарантировать безопасность - заблокировать все изображения, используя один из подходов на странице, упомянутых Лектонар, Фил Бриджер ( обсуждение ) 13:17, 6 ноября 2024 (UTC) [ ответить ]
Люди создали зеркала, такие как Hamichlol , это вариант для тех, кто хочет. Gråbergs Gråa Sång ( обсуждение ) 14:43, 6 ноября 2024 (UTC) [ ответить ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.
Добавить опцию ИИ-перевода для перевода статей с английского на неанглийский язык.
ИИ, безусловно, значительно улучшился к настоящему времени. Он может переводить на многие неанглийские языки лучше, чем традиционные переводчики. Я предлагаю добавить опцию перевода ИИ для перевода с английского на неанглийский язык статьи. Пользователь будет просматривать перевод ИИ, чтобы убедиться, что он правильный. Это повысит качество перевода. Я не предлагаю использовать ИИ для английских статей, это может иметь разрушительные последствия. Dark1618 ( обсуждение ) 18:50, 7 ноября 2024 (UTC) [ ответить ]
Это выходит за рамки данной темы, и об этом нужно спрашивать в каждой отдельной языковой редакции Википедии, поскольку именно они будут диктовать политику переводов на свои языки. — Jéské Couriano v^_^v темы критика 19:10, 7 ноября 2024 (UTC) [ ответить ]
Почему перевод на английский язык был бы разрушительным, а перевод с английского на любой другой язык был бы приемлемым? Английский просто оказался самым используемым языком в мире по некоторым меркам: за исключением этого он не имеет особого статуса. В любом случае, мы не можем здесь решать, что подходит для Википедий на других языках. Фил Бриджер ( обсуждение ) 19:33, 7 ноября 2024 (UTC) [ ответить ]
Хорошая идея! Это то, что я собирался предложить, но вы это приняли. В дополнение к вашему замечательному предложению я предлагаю, чтобы каждый перевод вики был одобрен носителем языка. Например, если кто-то перевел статью с английского на арабский, переведенная статья отправляется носителю языка арабского языка, по алгоритму, когда человек нажимает кнопку с надписью «отправить на утверждение» или что-то в этом роде, и араб, который получает переведенную статью, читает страницу Википедии и ищет любые ошибки, затем араб исправляет ее, и она публикуется для всего мира. И почему не может произойти обратное, когда статья переводится, скажем, с французского на английский язык, происходит то же самое: французская машина переводит статью, она отправляется на утверждение, беглый носитель английского языка идет и исправляет ее, затем она публикуется. Если это вымерший язык, ее исправит профессионал в этом языке, а что касается ставок, я имею в виду, что в Википедии есть по крайней мере 1 человек, который знает язык. В любом случае, хорошего вам дня! Ура! Datawikiperson ( обсуждение ) 10:10, 10 ноября 2024 г. (UTC) [ ответ ]
Я не уверен в технической стороне этого инструмента, но я вижу в английской Википедии постоянный поток статей, переведенных из родственных проектов, обычно без надлежащей атрибуции, иногда с неисправными шаблонами.Некоторые из этих переводов довольно хороши, вплоть до идиоматических фраз; другие выглядят как сырой машинный перевод, с ошибками, которые не допустил бы ни один человек, свободно владеющий целевым языком.Что касается первоначального предложения/идеи, потока машинных переводов из этого проекта в родственные Википедии, то это действительно выходит за рамки этого вопроса и должно быть представлено индивидуально в каждом языковом проекте. За исключением, может быть, себуанской Википедии . Folly Mox ( обсуждение ) 14:49, 10 ноября 2024 (UTC) [ ответить ]
Я иногда перевожу с английского на китайский и наоборот, и беру некоторые части из японских и корейских проектов, чтобы перевести их сюда, если информация и источники могут быть использованы здесь. И я настоятельно не рекомендую автоматизированные переводы ИИ с английского на другие языки, которые вы предлагаете, без дополнительных вкладов от целевых языковых проектов. Переводы ИИ на другие языки с английского не идеальны и могут иметь те же разрушительные последствия, которые вы не хотите видеть в английской Википедии. – robertsky ( talk ) 14:30, 11 ноября 2024 (UTC) [ ответить ]
«Википедия:Песочница перенаправления»
Песочница для тестирования перенаправлений, которая перенаправляет на Wikipedia:Sandbox и имеет уведомление песочницы, когда вы нажимаете для получения дополнительной информации об этой песочнице. Она может быть перенаправлена куда угодно и автоматически возвращается, как и все другие песочницы.
Я предлагаю это, потому что нам не разрешено перенаправлять песочницу , даже то, что там перенаправляется, поэтому я был обязан предложить что-то вроде этого. 67.209.128.161 (обсуждение) 08:28, 8 ноября 2024 (UTC) [ ответить ]
Что там тестировать, что это будет хорошо? Если вы сделаете ошибку при создании перенаправления, вы можете просто исправить ее. Remsense ‥ 论08:42, 8 ноября 2024 (UTC) [ ответить ]
Кроме того, если вы создадите учетную запись, вы сможете экспериментировать с перенаправлениями в своем пользовательском пространстве столько, сколько захотите. Thryduulf ( обсуждение ) 11:10, 8 ноября 2024 (UTC) [ ответить ]
Авторы должны указать размеры объектов.
Клише гласит: «Размер не имеет значения», но это имеет значение во многих вещах — картинах, скульптурах, ювелирных изделиях, кристаллах, во всем, что больше или меньше обычного, и даже если это обычный размер, если читатели не знают, что это такое. Имеет значение, имеет ли картина размер 2” на 3” или 2’ на 3’. Особенно в TPOD, потому что ее увидит больше людей, но на самом деле везде. Я предлагаю поощрять авторов указывать соответствующий размер в тексте или подписи к каждой фотографии, где это необходимо, и настоятельно рекомендовать редакторам, работающим над TPOD , указывать размер, когда это возможно. Если размер не указан в тексте, на который делается ссылка, эта информация часто содержится в «подробностях» фотографии, в дополнение к истории редактирования. Wis2fan ( обсуждение ) 04:51, 9 ноября 2024 (UTC) [ ответ ]
Верно ( MOS:ART, естественно, говорит об этом в тексте статьи), но огромное количество фотографий на Commons не содержат эту информацию - вероятно, большинство. Johnbod ( обсуждение ) 12:42, 9 ноября 2024 (UTC) [ ответить ]
Во-первых, простите за невежество, но что такое TPOD? Во-вторых, я не вижу здесь четкого предложения. Да, размер часто важен, но что, по-вашему, нам следует с этим делать? Мы можем уговорить редакторов указать размер, но мы не должны отклонять изображения без него. Фил Бриджер ( обсуждение ) 13:48, 9 ноября 2024 (UTC) [ ответить ]
Извините, я неправильно написал аббревиатуру — POTD. Сегодняшний (11/10/2024) POTD — пример того, о чем я говорю. Читатель знает, что короед крошечный, но почему бы не указать фактический размер? Дело не в том, что информация недоступна. Я нажал на фотографию, затем на «подробности». В описании фотографии говорится, что длина взрослого самца составляет от 4,0 мм до 5,5 мм. Я вернулся к посту и нажал на имя. Связанная статья содержит ту же информацию. На этот раз информация есть. Я согласен, это не всегда так. Но когда это так, она должна быть предоставлена, чтобы быть полной. Wis2fan ( обсуждение ) 04:54, 10 ноября 2024 (UTC) [ ответ ]
Подпись к изображению конечна, она не должна (и в большинстве случаев не может) включать все подробности об изображении и его объекте. Поэтому она должна включать только наиболее релевантную информацию, которая не всегда будет включать размер. Например, POTD за 8 ноября была фотографией Джона Тарлтона (офицера Королевского флота) 1860 года , является ли размер отпечатка действительно наиболее релевантной информацией или вы хотите узнать размер объекта? Можно поощрять людей указывать размер изображения и/или объекта в подписи, где это уместно, но это не всегда так, поэтому универсальное правило не будет уместным. Если вы хотите узнать, просто посмотрите на дополнительные детали. Thryduulf ( talk ) 14:37, 10 ноября 2024 (UTC) [ ответить ]
Thryduulf абсолютно прав, размер объекта на фотографии неважен, когда это человек. Размер не важен для сегодняшнего POTD (11.11.2024). Но я все еще думаю, что он важен, когда это лающий битл. И многое другое. Я также думаю, что писатель должен предугадывать вопросы читателя и давать ответы. Предложение о том, что если читатель хочет узнать размер объекта, он должен посмотреть на дополнительные детали, бесполезно. Я готов поспорить, что большинство читателей не знают, как их найти. Wis2fan ( talk ) 04:29, 11 ноября 2024 (UTC) [ ответить ]
Согласен , но только немного. Если бы вы добавили буквы, было бы лучше. Кроме того, решением для вашего региона-базирования может быть создание языкового базирования (например, "O" для "Office" станет "S" для "Schoolhouse" в теоретическом "перевернутом английском") Мастер ёжиков ( converse ) ( hedgehogs ) 14:33, 17 октября 2024 (UTC) 
Перемещено из Wikipedia:Edit filter/Requested/Archive 21 § Предупреждать об использовании встроенных изображений
Необходимо более широкое обсуждение , но до тех пор {{ EFR }} . Основанием для этого запроса является одно случайное удаление двоеточия. Это больше похоже на то, что может быть поднято в Phab, если не что-то еще, но я не думаю, что нам нужен фильтр, чтобы предупредить людей использовать 
.jpg/1280px-2015_0603-LGBTQ-4_(34631002910).jpg)
.jpg/1280px-Autel_votif,_MSR,_Mus%C3%A9e_Saint-Raymond_(7220963000).jpg)
