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

Оглавление
Первое обсуждение
Конец страницы
Новый пост

ВП:ВПИ
WP:VPIL

Раздел лаборатории идей в Village Pump — это место, где можно инкубировать новые идеи или предложения по общим вопросам Википедии для последующего представления для обсуждения на Village Pump (предложения) . Постарайтесь быть креативными и позитивными, комментируя идеи.
Перед созданием нового раздела обратите внимание :

Обсуждения технических вопросов проводятся на сайте Village pump (технический) .
Обсуждения политики проводятся на сайте Village pump (политика) .
Если вы готовы сделать конкретное предложение и определить, есть ли по нему консенсус, перейдите в Village pump (предложения) . Предложения, разработанные здесь, можно принести туда.

Прежде чем комментировать, обратите внимание :

Эта страница не предназначена для опроса консенсуса . Упрямые комментарии "Против" и "Поддержка" здесь, как правило, неуместны. Вместо этого обсуждайте идеи и предлагайте их вариации.
Хотите узнать, была ли у кого-то такая идея? Поищите в архивах ниже и просмотрите Wikipedia:Perennial suggestions .

Обсуждения автоматически архивируются, если остаются неактивными в течение двух недель.

« Архивы , 40 , 41 , 42 , 43 , 44 , 45 , 46 , 47 , 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 58 , 59 , 60

Сочетания клавиш политики полных имен в верхнем регистре

В таких эссе в духе, как WP:WTF? OMG! TMD TLA. ARG! и WP:ALPHABETTISPAGHETTI и WP:UPPERCASE , я стараюсь делать гораздо больше строчных полных названий при ссылках на политики, такие как WP:OriginalResearch или wp:competenceisrequired . Я лично обнаружил, что это в меньшей степени когнитивно ассоциируется с криком или адвокатурой, более понятно без необходимости наведения курсора и намного легче для глаз. Надеюсь, новые редакторы чувствовали то же самое.

Я хотел бы остановиться на двух вещах:

Не все подполитики имеют перенаправления как в нижнем регистре, так и в camelcase. Я просто хочу убедиться, что все они могут быть сделаны без противоречий.
На самих страницах политик ярлыки для подполитик всегда заглавные. Поэтому у нас есть (в RS) и WP:UBO , и USEBYOTHERS в качестве ярлыков в поле, но поскольку только UBO является аббревиатурой, почему мы не можем предложить второй ярлык WP:UseByOthers ? (Подобно во всем P&G.) Это просто индикатор того, что существуют и другие ярлыки, помимо ЗАГЛАВНЫХ букв.

Относительно незначительная вещь, которая не изменит фактическую функциональность чего-либо. Она просто заменяет предлагаемое написание полного имени (не аббревиатуры) ярлыков P&G с верхнего регистра на camelcase. SamuelRiv ( talk ) 19:26, 19 сентября 2024 (UTC) [ ответить ]

Чтобы предвосхитить возражение, что редакторы должны передавать открытый текст в P&G, как предлагается в эссе, на которые я дал ссылки: я согласен, это здорово, если редакторы действительно делали это с какой-то регулярностью. Что касается меня, то передача — это дополнительный кусок набора текста, который может быть не таким понятным, что я изначально ссылаюсь на P&G в обсуждении, что часто важно, поскольку я обнаружил, что люди в любом случае редко нажимают на ссылки. SamuelRiv ( talk ) 19:32, 19 сентября 2024 (UTC) [ ответить ]

Я не думаю, что вы, вероятно, получите какие-либо возражения по пункту 1. Я уже давно привык ссылаться на такие вещи в том регистре, который имеет наибольший смысл в предложении, которое я пишу (обычно строчными буквами или с заглавной первой буквой), и, если «показать предварительный просмотр» показывает это как красную ссылку, создавать перенаправление. Я не думаю, что кто-либо когда-либо отменял это. Мне придется немного подумать о пункте 2 — там есть опасность раздувания. Фил Бриджер ( обсуждение ) 19:50, 19 сентября 2024 (UTC) [ ответить ]

Для ясности по поводу #2: в поле в P&G, которое дает сочетания клавиш жирным синим текстом: одно - это аббревиатура, а другое - полное имя, поэтому в моем связанном примере поле гласит Сочетания клавиш: WP:UBO WP:USEBYOTHERS . Я предлагаю заменить сочетание клавиш полного имени в P&G с заглавных на camelcase, поэтому теперь поле гласит Сочетания клавиш: WP:UBO WP:UseByOthers . Я не уверен, где вы видите раздувание, поскольку ни один байт не добавляется и не вычитается, и функционально ничего не меняется. SamuelRiv ( talk ) 20:01, 19 сентября 2024 (UTC) [ ответить ]

Я вижу один возможный спорный момент: во многих скинах, включая legacy vector, поиск включает все перенаправления, и некоторые могут быть раздражены, увидев, что тонна перенаправлений заранее засоряет предложения, когда они хотят найти что-то еще после ввода первого слова. Лично мне гораздо больше нравятся перенаправления в стиле пункта 2. Аарон Лю ( обсуждение ) 23:29, 19 сентября 2024 (UTC) [ ответить ]

Legacy Vector search чувствителен к регистру? Так что если я начну искать "mrna", он выведет список, включающий "Mrna", "mRna", "mRNA", все из которых ссылаются на одно и то же? Если это так, и кто-то все еще использует такое программное обеспечение, то добавление или удаление перенаправлений с учетом регистра наверняка давно перестало быть причиной душевной боли для этого человека. SamuelRiv ( talk ) 07:26, 20 сентября 2024 (UTC) [ ответить ]

Существует множество способов поиска в Википедии, некоторые из которых нечувствительны к регистру и отображают список возможных результатов по мере ввода текста. Это включает внутреннюю поисковую систему, которая не зависит от используемого вами скина (вы видите одни и те же результаты в vector, vector legacy, monobook и т. д.). Thryduulf ( talk ) 11:29, 20 сентября 2024 (UTC) [ ответить ]

Я не думаю, что внутренняя поисковая система выводит несколько результатов на одну и ту же страницу из-за перенаправлений. Аарон Лю ( обсуждение ) 11:51, 20 сентября 2024 (UTC) [ ответить ]

Это имеет смысл. Тем не менее, мне больше нравится перенаправление CamelCase, поскольку оно очень четко показывает, где разделяются слова. Аарон Лю ( обсуждение ) 11:52, 20 сентября 2024 (UTC) [ ответить ]

Знаете, что разделяет слова четче, чем CamelCase? ~~Любые~~ пробелы. «Вы нарушаете нашу политику в отношении WP:BiographiesOfLivingPeople » и «Вы нарушаете нашу политику в отношении WP:biographies of living people ». Также его легче набирать; в основном не нужны новые перенаправления; и он выглядит гораздо менее странным для всех, кроме программистов. ( WP:biographiesoflivingpeople еще хуже.) — Cryptic 12:37, 20 сентября 2024 (UTC) [ ответить ]

Я не сторонник таких перенаправлений и просто повторяю заголовок. Пример UseByOthers ведет в раздел с другим названием. Аарон Лю ( talk ) 12:45, 20 сентября 2024 (UTC) [ ответить ]

Как и WP:Use другими . — Cryptic 12:55, 20 сентября 2024 (UTC) [ ответить ]

CamelCase требует немного меньше усилий для набора и все еще указывает, что ссылка является сокращением. Я думаю, что причина, по которой все заглавные буквы, заключается именно в том, чтобы различать их как перенаправления, и часть этой дифференциации должна быть сохранена. Аарон Лю ( обсуждение ) 12:58, 20 сентября 2024 (UTC) [ ответить ]

Лично я не считаю, что видимый текст ссылки должен быть дифференцирован как перенаправления. Это в первую очередь служит для кодификации термина (в заглавных буквах или в стиле «верблюжья кисть») как жаргона. Бывают моменты, когда это может привести к большей краткости, но в большинстве случаев выигрыш невелик, а цена — большая путаница для тех, кто еще не знает название пункта назначения и соответствующий текст. Например, часто ненейтральные точки зрения помечаются как WP:NPOV. Я понимаю точку зрения, что изучение жаргона сообщества является частью присоединения к этому сообществу. Однако я считаю, что в английской Википедии и так достаточно жаргона, и без того, чтобы каждое сокращение использовалось как жаргон. isaacl ( talk ) 15:55, 20 сентября 2024 (UTC) [ reply ]

Причина, по которой я бы рекомендовал использовать camelcase в качестве второго предлагаемого перенаправления (в маленьком поле перенаправлений в разделах P&G), в отличие от разнесенных прозаических версий (которые я также хотел бы видеть более используемыми редакторами), заключается в том, что camelcase также, по крайней мере, немного предполагает, что есть аббревиатура, которую люди используют, или, например, что новичок, следящий за обсуждением, может легче вывести «WP:UseByOthers ↔ WP:UBO». Если все здесь предпочтут указать «WP:Use by others», это меня устраивает; можно также указать три сокращения вместо двух: «WP:UBO WP:UseByOthers WP:Use by others». SamuelRiv ( talk ) 17:38, 20 сентября 2024 (UTC) [ reply ]

Более того, расшифровка сокращений может, по крайней мере, дать представление о том, что означает жаргон. Аарон Лю ( обсуждение ) 21:41, 27 сентября 2024 (UTC) [ ответить ]

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

Используйте его инструмент Link для добавления ссылок. В визуальном режиме просто введите, [[и он заметит, что вы хотите создать ссылку, и откроет инструмент для вас (альтернативно, нажмите кнопку на панели инструментов или используйте сочетание клавиш (=⌘K на Mac). Введите сочетание клавиш (например, WP:CORP) в поле поиска ссылок, и он предложит вам ссылку на полное название (например, Wikipedia:Notability (организации и компании) . Для отдельных разделов откройте страницу во вкладке и вставьте весь URL в свой комментарий. Например, я открыл WP:SIRS в другой вкладке, и вставка всего URL дает мне красиво отформатированную ссылку на Wikipedia:Notability (организации и компании)#Как применить критерии .

Предлагаю попробовать это в течение нескольких дней и посмотреть, понравится ли вам это. WhatamIdoing ( обсуждение ) 06:14, 25 сентября 2024 (UTC) [ ответить ]

@ WhatamIdoing Инструмент ссылки исходного режима на панели инструментов делает то же самое. Аарон Лю ( обсуждение ) 21:40, 27 сентября 2024 (UTC) [ ответить ]

Последовательность [[работает только в визуальном режиме. WhatamIdoing ( обсуждение ) 22:03, 27 сентября 2024 (UTC) [ ответить ]

Да, но значок ссылки на панели инструментов работает так же. (Кроме того, ConvenientDiscussions имеет встроенное всплывающее окно для помощи с вводом ссылок, которое автоматически дополняется, хотя и не расширяет перенаправление автоматически.) Аарон Лю ( обсуждение ) 04:17, 28 сентября 2024 (UTC) [ ответить ]

Поздний ответ, но это неудобно в обсуждениях. На практике редакторы хотели иметь стенографический способ как для ввода политики, на которую они ссылаются, так и для чтения и ссылки на нее. Проблема в том, что любой, кто годами не был на страницах обсуждений, понятия не имеет, с чего начать понимать, что они имеют в виду, поэтому camelcase, по крайней мере, является промежуточным вариантом, который смягчает две проблемы: крикливость и неразборчивость alphabettispaghetti. Замена в боковых полях является полностью пассивным уведомлением редакторов о том, что camelcase — это просто еще один вариант для ввода того, что они всегда печатают, хотя, конечно, (обычно) было бы предпочтительнее напечатать всю политику или связать ее с прозой. SamuelRiv ( обсуждение ) 22:21, 7 октября 2024 (UTC) [ ответить ]

Если мы собираемся продолжать рекламировать такие сокращения в {{ sh }} полях, я уверен, что это достаточно заметно, чтобы потребовать RfC или, по крайней мере, {{ централизованного обсуждения }} . Аарон Лю ( обсуждение ) 23:27, 28 сентября 2024 (UTC) [ ответ ]

Исправление черновика с помощью нового шаблона

Черновики давно критикуются как бэкдор к удалению. В New Pages Patrol (NPP) принято перемещать новые статьи, которые не готовы для основного пространства , в черновик. Таким образом, статьи, которые потенциально могут подойти для Википедии, но пока не подходят, сохраняются. Затем создатель статьи получает возможность улучшить свою статью, не дышите ему в спину со стороны NPPers или не отправляйте ее в раздел « Статьи для удаления» . Если кто-либо, включая создателя статьи, возражает против черновика, статью следует переместить обратно в основное пространство (черновик следует отменить). Это объясняется в DRAFTNO #6 и #7 . Для возражения не требуется никаких оснований.

Проблема: Однако у нас также есть правило, согласно которому черновики, которые не редактировались в течение шести месяцев, автоматически удаляются в соответствии с Критерием быстрого удаления G13 . Таким образом, благонамеренные Новые Страницы Патрулируют в одностороннем порядке черновики новых статей, которые еще не готовы для энциклопедии. Новые редакторы, создавшие статью, могут не согласиться с этим шагом, не зная, что они могут возразить. Новые пользователи могут разочароваться и вообще покинуть Википедию, а через шесть месяцев черновик удаляется в соответствии с CSD G13. Поскольку этот процесс происходит без обсуждений в сообществе, он приводит к тому, что черновик называют «черным ходом к удалению».

Решение: Эту проблему можно решить, не меняя политику или текущую практику . Нам просто нужно сделать очень очевидным для новых пользователей, что они могут возражать против черновика. Мы также можем сделать так, чтобы было легко отменить черновик (предполагая, что новый пользователь автоматически подтвержден ). Я предлагаю сделать это, добавив шаблон ко всем черновикам статей . Шаблон будет включать большую синюю кнопку , похожую на кнопку «Отправить черновик на рассмотрение!» в Template:AfC submission/draft , которая гласит «Возразить против этого перемещения». Нажатие этой кнопки либо: 1. Оставляет сообщение на странице обсуждения редактора, который подготовил черновик, уведомляя его о том, что было возражение против перемещения и требуя его немедленного отмены. 2. Автоматически перемещает страницу обратно в основное пространство или, если учетная запись редактора не может выполнить эту задачу, создает запись в Requested moves/Technical moves для этого эффекта. Последнее лучше, но и более технически сложно. Также было бы полезно добавить аналогичную кнопку в Template:Uw-articletodraft , предупреждение, которое обычно появляется при составлении черновика.

Реализация: Как только новый шаблон будет готов, его можно добавить в пользовательский скрипт MoveToDraft MPGuy , который является наиболее распространенным способом для NPPers составлять черновики статей. Его следует разместить над шаблоном AfC во всех черновиках статей.

Я был бы признателен за комментарии от технически подкованных редакторов, которые могли бы создать этот шаблон (или сказать мне, что это невозможно), от NPPers, которые пишут черновики статей, и от сторонних редакторов, которые имеют мнение о процессе написания черновиков. Toadspike [Обсуждение] 10:37, 26 сентября 2024 (UTC) [ ответить ]

Эта идея на самом деле не моя, она, очевидно, была вызвана последним RfA. Похожая идея ранее обсуждалась здесь , но в том обсуждении предлагалось требование , которому должны следовать все редакторы (политика), а не техническое решение, и это обернулось катастрофой. Чтобы предотвратить нечто подобное, я прошу всех участников сосредоточиться на улучшении текущей ситуации, а не на обсуждении морали черновиков в целом. Toadspike [Обсуждение] 11:03, 26 сентября 2024 (UTC) [ ответить ]

Уведомление пользователей, которые прокомментировали эту тему наиболее прямо в RfA: @ Alalch E. @ User:Onel5969 @ User:Hobit @ User:Fangz @ User:Nsk92 . Я также уведомил страницу обсуждения NPP и опубликовал сообщение в Discord. Я не уверен, как уведомить всех участников предыдущего обсуждения (кроме как сделать это вручную), и я не уверен, что это продуктивно, учитывая, сколько людей было вовлечено и насколько это вышло за рамки темы, поэтому я не буду этого делать пока. Toadspike [Обсуждение] 11:07, 26 сентября 2024 (UTC) [ ответить ]

Вы уверены, что хотите сделать это RfC? Есть ли где-то BEFORE? Аарон Лю ( обсуждение ) 11:32, 26 сентября 2024 (UTC) [ ответить ]

Хороший вопрос, я не уверен, применима ли метка RFC, поэтому я удалю шаблоны. Я искал способы уведомить людей и неправильно понял RFCBEFORE. Toadspike [Обсуждение] 11:34, 26 сентября 2024 (UTC) [ ответить ]

Oppose : Сообщение о черновике можно подправить, но большая кнопка для отмены этого шага приведет к большему количеству AfD, более высокой нагрузке на NPP, большему поведению BITEY и худшему удержанию редакторов. Место для черновиков невероятно ценно, и у людей есть невероятно извращенные представления об этом пространстве. Если бы мы сделали что-то подобное, то в конечном итоге мы бы отпугнули новых редакторов, потому что многим людям непросто научиться делать так, чтобы ваша статья соответствовала нашим сложным правилам менее чем за 7 дней (тег AfD). Место для черновиков дает им возможность работать над контентом, получать советы и писать статьи, которые действительно выживут в AfD и позволят им остаться. На самом деле нам нужно больше черновиков, и я взял на себя смелость начать делать это снова и призываю других делать это. Я большой сторонник удержания редакторов. Так делать нельзя. Привет, чувак, им Джош ( обсуждение ) 12:15, 26 сентября 2024 (UTC) [ ответить ]
Проблема с односторонним черновиком в том, что он также может быть невероятно едким, особенно когда делается по произвольным причинам, которые не имеют ничего общего с причинами, по которым что-то может быть удалено в AfD (хотя это менее распространено, чем тривиальные причины, по которым что-то отклоняется в AfC). Мы должны составлять меньше черновиков статей и не отправлять их в AfD, а вместо этого оставлять их в основном пространстве (с соответствующими тегами, где это оправдано), чтобы их можно было найти и улучшить, а не притворяться, что их не существует в течение шести месяцев, а затем удалять их. Thryduulf ( talk ) 12:34, 26 сентября 2024 (UTC) [ ответить ]
Я не уверен, что черновик хуже альтернатив - теги *также* кусаются, и один пользователь, пометивший статью и оставив ее в основной теме, может привести к тому, что другой пользователь увидит ее и решит присоединиться к AfD. Черновик может быть способом защитить статью, пока она не станет лучше. Но я думаю, что другая часть, с которой я имею проблему, - это отсутствие четких инструкций. Очевидно, что у некоторых людей есть проблема с черновиком, а у других нет, и у людей разные представления о том, для чего он нужен. Это нужно сделать более конкретным. В противном случае просто сказать "мы должны использовать черновик меньше" не приведет ни к каким положительным изменениям. Fangz ( обсуждение ) 12:43, 26 сентября 2024 (UTC) [ ответить ]
Я согласен с общим мнением – споры о большей или меньшей черновой обработке не решают проблему того, что новые пользователи в принципе не могут возражать против этого. Toadspike [Обсуждение] 12:47, 26 сентября 2024 (UTC) [ ответить ]
Я представляю себе шаблон (возможно, специально для относительно новых пользователей?) примерно такой:
1. Привет, эта статья была перемещена в черновик, потому что другой пользователь считает, что у нее есть потенциал, но она пока не готова для энциклопедии. ПРИЧИНА:
2. Вы можете продолжать работать над ним, пока он не опубликован, но учтите, что если его не редактировать в течение 6 месяцев, он будет удален. Вот несколько полезных ресурсов.
3. Когда вы считаете, что статья готова, вы можете отправить ее на рецензию, которая может дать полезный отзыв. []
4. В качестве альтернативы вы можете вернуть статью в основную энциклопедию в любое время и отредактировать ее, пока она является частью основной энциклопедии. См. WP: Draft Object. Однако обратите внимание, что если другие пользователи считают, что в статье есть неустранимые проблемы, она может быть выдвинута в качестве кандидата на удаление. Fangz ( обсуждение ) 12:54, 26 сентября 2024 (UTC) [ ответить ]
Мне нравится идея предупреждения пользователя. Аарон Лю ( обсуждение ) 12:59, 26 сентября 2024 (UTC) [ ответить ]
Тегирование никогда не приводит к автоматическому удалению статьи. –  Джо ( обсуждение ) 18:43, 26 сентября 2024 (UTC) [ ответить ]
По моему мнению, черновики статей должны (полу?) автоматически возвращаться в основное пространство после тайм-аута, а не удаляться. Или, по крайней мере, переоцениваться на предмет значимости. Я не вижу причин для автоматического быстрого удаления, кроме как для удаления через бэкдор. Fangz ( обсуждение ) 18:59, 26 сентября 2024 (UTC) [ ответить ]
Мне нравится эта идея. Но им нет, так что это немного спорный вопрос с точки зрения текущей политики. –  Джо ( обсуждение ) 06:16, 27 сентября 2024 (UTC) [ ответить ]
Почему они просто не могут улучшить его в mainspace, без жала от первоначального отклонения и шестимесячного обратного отсчета удаления, нависающего над ними? Я не понимаю, почему вы продолжаете представлять это как выбор между draftspace и AfD. –  Джо ( talk ) 18:46, 26 сентября 2024 (UTC) [ ответить ]
Причина в том, что «улучшение в основном пространстве» имеет свои собственные проблемы. Статья в основном пространстве должна совмещать полезность для читателя с полезностью для редактора. Это подразумевает формальные процессы и вики-жаргон для согласованности, унифицированные шаблоны для вопросов в статье, четкую и безжалостную маркировку проблем и так далее. Существует сильная тенденция к тому, что первый опыт редактора становится очень публичной и унизительной борьбой с устоявшимися редакторами, которые лучше понимают процессы Википедии, быстро отталкивая редактора или блокируя его. Также очень трудно улучшить этот опыт, поскольку это подразумевает фундаментальные изменения, затрагивающие самые разные вещи. Между тем, улучшение статьи в режиме черновика позволяет более неформальному процессу общения вести статью к приемлемому состоянию. Fangz ( обсуждение ) 19:10, 26 сентября 2024 (UTC) [ ответ ]
Недавно я немного поработал над статистикой просмотров страниц . Медианная статья получает около одного просмотра страницы в неделю. Так что если новая статья типична, то она не должна «быть полезной для читателя», потому что на самом деле читателей нет. Редакторы (особенно ребята из NPP и RecentChanges) могут просматривать совершенно новую статью несколько десятков раз в первый день, но как только рецензенты оставляют ее в покое, большинство статей просто не имеют большого трафика.
Я думаю, что причина, по которой мы не хотим «улучшать его в mainspace», заключается в том, что мы боимся, что забудем, что он там был, и годы спустя кто-то будет смущен, обнаружив, что статья WP:UGLY с тех пор была забыта. Мы используем черновик и другие угрозы, чтобы заставить других WP:VOLUNTEERS улучшить статью до нашего представления о приемлемом качестве. WhatamIdoing ( talk ) 20:40, 26 сентября 2024 (UTC) [ ответить ]
Я не знаю, рассматриваем ли мы разные пространства имен проектов, но «неформальный процесс коммуникации для приведения статьи к приемлемому состоянию» звучит как полная противоположность нашему текущему процессу AfC. –  Джо ( обсуждение ) 06:19, 27 сентября 2024 (UTC) [ ответить ]

Мне не нравится идея кнопки, но я думаю, что шаблон следует изменить. Я думаю, что наличие кнопки предполагает, что это опция по умолчанию, но я думаю, что ссылка приемлема. Fangz ( talk ) 12:37, 26 сентября 2024 (UTC) [ ответить ]

Это примерно то, что делает {{subst: draft article }}, но MoveToDraft по какой - то причине использует { {subst: AfC submission/draft }}. CFA 💬 12:41, 26 сентября 2024 (UTC) [ ответить ]
Для справки, я бы поддержал либо использование {{ draft article }} , либо создание нового шаблона с вашими предложенными изменениями. C F A 💬 12:44, 26 сентября 2024 (UTC) [ ответить ]
Все черновики AfC должны использовать шаблон AfC. Если вы говорите о кнопке «опубликовать сейчас», то она только для автоподтвержденных. Аарон Лю ( обсуждение ) 12:45, 26 сентября 2024 (UTC) [ ответить ]
Но статьи не являются по сути "черновиками AfC" после составления черновика. Людям разрешается самостоятельно перемещать их обратно в основное пространство, не задавая вопросов, или по желанию отправлять их в AfC. В шаблоне черновика AfC первый вариант не упоминается. C F A 💬 12:48, 26 сентября 2024 (UTC) [ ответить ]
Кстати, скрипт MTD был вчера изменен для использования {{ draft article }} . - MPGuy2824 ( talk ) 12:48, 26 сентября 2024 (UTC) [ ответить ]
Ой, я не заметил. Так-то лучше, по крайней мере. C F A 💬 12:49, 26 сентября 2024 (UTC) [ ответить ]
Интересно, перестанем ли мы когда-нибудь использовать неуместный и юридически необоснованный язык «публикации» в этом шаблоне. На этой вики это автор, а не рецензент AFC, который «публикует» его. WhatamIdoing ( обсуждение ) 20:43, 26 сентября 2024 (UTC) [ ответ ]
@ WhatamIdoing : Можете ли вы придумать лучшее слово? (Серьезно, я уже много лет пытаюсь и ничего не могу придумать.) –  Джо ( обсуждение ) 07:33, 27 сентября 2024 (UTC) [ ответить ]
Да: WP:MOVE . WhatamIdoing ( обсуждение ) 20:28, 27 сентября 2024 (UTC) [ ответить ]
Да, но тогда вам придется указать «переместить в основное пространство» или что-то в этом роде, и это кажется действительно жаргоном. «Переместить из черновика», может быть? –  Джо ( обс .) 04:49, 1 октября 2024 (UTC) [ ответить ]
Это сработает. WhatamIdoing ( обсуждение ) 05:19, 1 октября 2024 (UTC) [ ответить ]
Ну, это может решить проблему. Я не объясняю новым пользователям, как их статья превратилась в черновик, но, по крайней мере, есть простой способ это отменить. Я не буду отзывать это пока, может, у других есть мысли. (P.S. вы можете обновить User:MPGuy2824/MoveToDraft ) Toadspike [Обсуждение] 12:51, 26 сентября 2024 (UTC) [ ответить ]

Это лаборатория идей, поэтому никаких выделенных жирным шрифтом комментариев от меня, но у меня смешанные чувства. Я за смягчение опыта для новичков, но я против концепции автоматической отмены черновика. Если новый патруль страниц просматривает новую статью и перемещает ее в черновик, потому что она явно не подходит для основного пространства, создателю нужно сделать больше, чем просто сказать «Я возражаю», чтобы переместить свою явно неподходящую статью обратно. Недавно я предложил, чтобы все черновиковое пространство было защищено от перемещения на полууровне (предложение не было хорошо принято — достаточно справедливо). Это, вероятно, правило, которое я игнорирую больше, чем любое другое в Википедии, в основном имея дело со спам-фермами, которые пытаются злоупотреблять правилом для продвижения своего мусора. Кроме того, новый пользователь, чье сообщение помещено на карантин в черновик, и ему оставляют инструкции и список предложений с полезными ссылками, уже получает лучшее обращение, чем когда-либо получало или будет получать большинство редакторов, и если его реакция на это — яростное увольнение, то он, вероятно, в любом случае не подходит для совместной среды Википедии. Ivanvector ( ^{Обсуждение} / _Правки ) 12:57, 26 сентября 2024 (UTC) [ ответить ]
@ Ivanvector , знаешь шутку про "Если спросить трех человек, то получишь четыре мнения"? Интересно, если мы спросим трех NPPers, что значит "готов к mainspace", получим ли мы четыре мнения. AFAICT, "готов к mainspace" чаще всего означает "содержит как минимум столько же ссылок, сколько и медианная статья, но более высокого качества". Все дети в Лейк-Вобегоне выше среднего, и все новые статьи в Википедии, должно быть, тоже. WhatamIdoing ( talk ) 20:12, 26 сентября 2024 (UTC) [ ответить ]
Мне кажется, я смутно припоминаю обсуждение этой темы когда-то в не столь отдаленном прошлом. Folly Mox ( обсуждение ) 22:55, 26 сентября 2024 (UTC) [ ответить ]
176 комментариев от 22 редакторов, и у меня самого, вероятно, было 22 мнения. ;-) WhatamIdoing ( обсуждение ) 22:23, 27 сентября 2024 (UTC) [ ответ ]
Все страницы уже эффективно защищены от перемещения на полууровне . Для перемещения требуется (автоматически)подтвержденная учетная запись. SilverLocust 💬 07:17, 5 октября 2024 (UTC) [ ответить ]
Насколько я понимаю, черновик никогда не должен использоваться для предметов, проходящих GNG, и он должен быть стандартным только для таких вещей, как фильмы/сериалы/игры, которые находятся в разработке, но еще не начали производство. Предметы с спорной значимостью следует отправлять в AFD, чтобы проблема могла быть решена. ★Trekker ( обсуждение ) 13:00, 26 сентября 2024 (UTC) [ ответить ]
Темы, прошедшие WP:GNG, вообще не должны быть черновиками, вместо этого их следует помечать и обрабатывать с использованием обычных процедур сообщества. Я согласен, что фильмы/сериалы/игры/политические события, вероятно, лучше всего подходят для черновиков, но то же самое можно сказать и о потенциально значимых, но недостаточно проработанных статьях. Sohom ( обсуждение ) 13:33, 26 сентября 2024 (UTC) [ ответить ]
Это не соответствует нынешней форме Wikipedia:DRAFTIFY , и я не думаю, что это имеет смысл в любом случае. Статьи, которые не соответствуют GNG, не должны быть черновиками, они должны быть AfDed. Фильмы и т. д., которые находятся в разработке, не должны быть черновиками только потому, что они не находятся в производстве, и это не очень хорошее использование пространства для черновиков, потому что нет гарантии, что произойдет изменение ситуации для установления известности в течение 6 месяцев. Статьи должны быть черновиками, только если рецензент считает, что статью можно отредактировать до приемлемого состояния в течение временного окна. Это подразумевает проход GNG - т. е. веру в то, что потенциально существуют надежные источники. Помните, что GNG касается *темы*, а не состояния статьи. Fangz ( обсуждение ) 14:09, 26 сентября 2024 (UTC) [ ответ ]
На мой взгляд, правильное использование черновика — это своего рода альтернативная версия шаблона WIP. Признание того, что статья не готова и должна быть доработана, и, скорее всего, будет иметь несколько проблем, но в защищенной изолированной среде, чтобы избежать чрезмерно ревностной модерации и содействия непониманию случайных читателей, и без намека на то, что над ней работает первоначальный редактор. Для новых пользователей он должен предлагать менее формальный и жаргонный процесс обучения тому, как улучшить статью, чем методы, основанные на тегах, потому что последний должен сбалансировать необходимость информирования *читателей*, а также редакторов. Fangz ( обсуждение ) 14:23, 26 сентября 2024 (UTC) [ ответить ]
Если вы оцениваете, что статья проходит WP:GNG , то нет смысла в ее черновике, вы можете просто добавить шаблон {{ sources exist }} , патрулировать и двигаться дальше. В качестве альтернативы, если вы оцениваете, что статья не проходит WP:GNG , нет смысла тратить время создателя статьи, и вы должны WP:AFD /PROD ее.
Единственный случай, когда вам следует составить черновик статьи, — это если вы увидели статью, которая а) имеет обоснованные претензии на значимость/знаменательность, б) не соответствует/не доказывает значимости в ее текущем состоянии, в) была создана в течение последней недели или около того неопытным автором статьи. Sohom ( обсуждение ) 14:43, 26 сентября 2024 (UTC) [ ответить ]
Не уверен, то ли мы не согласны, то ли у нас есть какие-то семантические разногласия по поводу значения «проходит GNG».
Но в любом случае есть проблемы, выходящие за рамки заметности, на мой взгляд, это, вероятно, более полезно. Fangz ( обсуждение ) 15:08, 26 сентября 2024 (UTC) [ ответить ]
Если у статьи есть реальный шанс быть сохраненной или объединенной в АдГ, то ее не следует вносить в черновик.
Если статья определенно не подходит для AfD и нет возможности ее исправить, ее следует отправить в AfD. Thryduulf ( обсуждение ) 15:57, 26 сентября 2024 (UTC) [ ответить ]
Я думаю, тогда вы в значительной степени утверждаете, что процесс черновика должен быть полностью удален, и я с этим не согласен. У него есть свои преимущества. Он не должен быть обязательным процессом ни в коем случае, но так как некоторые пользователи предпочитают работать над статьями в виде черновика, а затем выкладывать их в общедоступную вики, это может быть лучшим решением определенных проблем, чем альтернативы. Fangz ( обсуждение ) 17:44, 26 сентября 2024 (UTC) [ ответить ]
Я не уверен, что пространство имен Draft: имеет какие-либо преимущества перед пользовательской «песочницей», а m:Research:Wikipedia, процессы и производительность m:Research:AfC говорят о том, что пространство имен Draft: — это то место, где статьи отправляются умирать.
Я думаю, что мы здесь попали в ложную бинарность. Варианты не "мусор в основном пространстве" против "автоматически удаляется как в черновике". Есть и другие варианты (например, липкие подсказки для нецитируемых статей, юзерификация, жирная заглушка, жирное слияние, разработка более последовательного и предсказуемого стандарта для оценки статей и т. д.). WhatamIdoing ( обсуждение ) 20:20, 26 сентября 2024 (UTC) [ ответ ]
Я думаю, можно утверждать, что этот ландшафт мог немного измениться с тех пор, как было проведено это исследование. Последние данные, которые рассматривают эти проекты, относятся к 2014-2017 годам. WP:ACTRIAL произошел после того, как было проведено это исследование, и политика Википедии изменилась с тех пор. Sohom ( обсуждение ) 20:48, 26 сентября 2024 (UTC) [ ответить ]
Возможно, что-то изменилось, и я никогда не отказываюсь от нового исследовательского проекта, если вы добровольно согласитесь его выполнить (я считаю, что все необходимые данные общедоступны), но, глядя на общую скорость удаления в этом пространстве имен, кажется маловероятным, что результат будет существенно отличаться. WhatamIdoing ( обсуждение ) 20:31, 27 сентября 2024 (UTC) [ ответ ]
Я думаю, тогда вы в значительной степени утверждаете, что процесс черновика должен быть полностью удален, и я с этим не согласен. Мне жаль, что я придираюсь к вам, но это самый яркий пример кругового рассуждения, которое завело нас в эту неразбериху: черновик должен быть хорош, потому что мы его делаем, поэтому мы должны продолжать это делать, потому что это хорошо. Буквально с того момента, как был создан черновик, и люди начали это делать (до этого эквивалентный процесс юзерфикации был прямо запрещен без предварительного обсуждения), другие указывали, что лежащая в основе логика не имеет смысла. Черновик предназначен только для статей, которые не следует удалять, но он также предназначен только для статей, которые не могут быть в основном пространстве. Но поскольку исправление хорошего контента на месте является частью политики редактирования, и почти все принятые сообществом причины удаления связаны с потенциалом статьи, а не с ее текущим состоянием, пересечение этих двух множеств функционально равно нулю (за исключением некоторых установленных консенсусом крайних случаев, таких как платные творения или предстоящие фильмы).
Вот почему попытки прояснить и улучшить политику в отношении черновиков — а я принимал непосредственное участие во многих из них — продолжают терпеть неудачу. Вы пытаетесь найти прочную основу для руководств, но ее просто нет. Нам действительно нужно прекратить пытаться найти квадратуру круга оправдания черновиков, как это практикуется сейчас, и начать спрашивать, чего мы, сообщество, на самом деле хотим добиться с его помощью и соответствует ли то, что мы делаем сейчас, этой цели. Пока что это выглядит не очень хорошо для лагеря «отправь их всех в пространство черновиков, и бог известности узнает своего собственного», потому что нет ни малейшего доказательства того, что это помогает улучшить контент, удержать редакторов или управлять рабочей нагрузкой NPP, и, как говорит WAID выше эмпирических исследований, мы пришли к прямо противоположному выводу. Но эта картина может измениться с большим количеством исследований — кому-то просто нужно активизироваться и сделать это! –  Джо ( обсуждение ) 07:01, 27 сентября 2024 (UTC) [ ответить ]
@ Joe Roe Черновики предназначены только для статей, которые не следует удалять, но также и для статей, которые не могут быть в mainspace. Именно поэтому draftspace вообще существует. Представьте, что вы видите статью со следующим содержанием: Николас Карлини — потрясающий исследователь в Google, работающий над состязательным машинным обучением . Статья создана примерно на прошлой неделе и взята с личной веб-страницы человека. При быстром поиске в Google вы видите, что этот человек существует и является исследователем в указанной компании, однако из-за вашего незнания тематической области состязательного машинного обучения вы не можете сразу определить влияние человека на эту область. Вы 1) WP:BITEly номинируете статью на удаление 2) оставляете контент для того, чтобы кто-то с ним разобрался (и надеетесь, что другой кто-то не выберет вариант 1) или 3) составляете черновик статьи с примечанием о том, что для подтверждения значимости требуются дополнительные источники? Сохом ( обсуждение ) 11:25, 27 сентября 2024 г. (UTC) [ ответ ]
@ Sohom Datta Ни один из них. Вы добавляете шаблон к статье, отмечая отсутствие источников, оставляете дружелюбное сообщение на странице обсуждения создателя, объясняя проблемы на простом английском языке, и оставляете заметку об этом в обсуждении Википедии:WikiProject Computer science . В зависимости от того, что обнаружили ваши исследования, вы можете добавить больше информации, добавить некоторые источники, которые могут или не могут продемонстрировать известность, удалить термины павлина и т. д. Да, это требует больше усилий, чем слепое черновик или AfDing, но гораздо важнее, чтобы все было сделано хорошо, чем быстро. Thryduulf ( обсуждение ) 12:37, 27 сентября 2024 (UTC) [ ответить ]
@ Sohom Datta , спасибо за создание Nicholas Carlini , чья первая версия не содержит гипотетического предложения, которое вы дали в своем комментарии выше. В вашем примере выше, почему это не может остаться в mainspace? Мне это, честно говоря, не нравится, и я бы немедленно вытащил слово «удивительно», но какова политическая основа для утверждения «эта статья действительно не может быть в mainspace»? WhatamIdoing ( talk ) 21:10, 27 сентября 2024 (UTC) [ ответить ]
@ Fangz Я не выступаю за ликвидацию черновиков, у них есть свои применения в качестве дополнительного пространства, где статьи могут разрабатываться с течением времени, чтобы им не приходилось соответствовать всем соответствующим политикам контента с самого первого редактирования. Я также не выступаю за ликвидацию всех черновиков, только за большую часть односторонних черновиков, потому что, как Джо выразился лучше, чем я, это не является чистой выгодой для проекта в том виде, в котором это практикуется в настоящее время. Thryduulf ( talk ) 12:46, 27 сентября 2024 (UTC) [ ответить ]
Есть нечто среднее между meets-GNG-mark-as-reviewed и fails-GNG-send-to-AfD: недавно созданные статьи, где источники в статье не подтверждают GNG, но где новый рецензент страницы не делал ДО поиска. Я думаю, что совершенно справедливо (и разрешено в текущем процессе черновика) сказать: «эта недавно созданная статья пока не демонстрирует GNG, но я верну ее создателю в виде черновика, чтобы он добавил еще несколько источников». Dclemens1971 ( talk ) 04:43, 29 сентября 2024 (UTC) [ ответить ]
Передача его в черновик без выполнения BEFORE — это определенно не то, что мы должны терпеть. Thryduulf ( обсуждение ) 10:21, 29 сентября 2024 (UTC) [ ответить ]
Это означало бы, что мы либо оставляем эти статьи без патрулирования (что, очевидно, нежелательно), либо даем новым патрульным страницам работу по поиску источников для каждой статьи, где оригинальный автор этого не сделал, что было бы идеально в, ну, идеальных условиях, но возлагает бремя фактического поиска источников энциклопедии на очень небольшую группу редакторов. По моему мнению, должен быть способ попросить оригинального автора добавить источники, чтобы показать, что он соответствует GNG, помимо простого добавления тега «знатность» и дела с этим. Chaotic Enby ( обсуждение · вклад ) 19:53, 1 октября 2024 (UTC) [ ответить ]
Я согласен с Chaotic Enby. Drafification — хорошее решение, потому что оно настоятельно поощряет автора улучшать статью и, что самое важное, выводит ее из основного пространства, чтобы она не была проблемой для невинных читателей — и при этом не заставляя участников NPP убирать чужие беспорядок. Cremastra ( обсуждение ) 20:06, 1 октября 2024 (UTC) [ ответить ]
Черновики [...] настоятельно рекомендуют автору улучшить статью . Это теория, но доказательства говорят о том, что на практике это происходит очень редко. Также нет никаких доказательств того, что большинство страниц, перемещенных в черновик, на самом деле являются проблемой для невинных читателей , а не проблемой для тех, кто хочет немедленного совершенства. Thryduulf ( обсуждение ) 20:47, 1 октября 2024 (UTC) [ ответить ]
Что касается желания попросить оригинального автора добавить источники, чтобы показать, что он соответствует GNG, помимо простого добавления тега "знаменитости" и дела с этим , мне интересно, возможно ли это сделать ненасильственным способом. Сейчас есть следующие варианты:
Просто спросите (что делает тег {{ notability }} ).
Задайте вопрос под угрозой удаления ( WP:BLPPROD и WP:PROD ).
Переместить статью в черновик: пробел (по сути, удерживая статью в заложниках, чтобы удалить ее, если вы сдадитесь или не сможете понять, как это сделать).
Отправьте в AFD сегодня.
AFAICT метод для "заставить другого WP:VOLUNTEER улучшить статью до моих стандартов" оказался довольно неуловимым. Но если вы хотите достичь этой точки, я предлагаю вам сделать маленький шажок к ней в форме принятия политики (любой политики, на самом деле) для того, чтобы на самом деле, прямо и недвусмысленно сказать, что каждая статья должна ссылаться по крайней мере на один источник. Пока сообщество не согласится, что это действительно требование, у нас нет надежды заставить их повысить требование вплоть до "показать, что оно соответствует GNG". WhatamIdoing ( обсуждение ) 00:20, 2 октября 2024 (UTC) [ ответ ]

Если новый редактор считает, что его статья готова для mainspace, он поместит ее туда. Он также с радостью отменит перемещение. Если новый редактор не уверен, он, вероятно, сначала попросит о помощи или воспользуется draftspace. Cremastra ( talk ) 19:35, 26 сентября 2024 (UTC) [ ответить ]

Я думаю, что беспокойство, выраженное Джо и другими, кто поддерживает теорию «бэкдора», заключается в том, что новые пользователи не знают, как отменить переход в черновик. Вы не согласны с этим предположением? Toadspike [Обсуждение] 19:53, 26 сентября 2024 (UTC) [ ответить ]

Я думаю, что большинство пользователей не знают, как отменить ход, да. Я также думаю, что мы не должны преподносить им это на блюдечке с голубой каемочкой, потому что это, вероятно, в значительной степени сводит на нет весь смысл черновика. Каково решение этой проблемы? Я не могу вам сказать. Cremastra ( talk ) 20:09, 26 сентября 2024 (UTC) [ ответить ]

Разве "весь смысл черновика" в том, чтобы сделать мое мнение о ценности предмета более весомым, чем мнение новичков? Безопасность через неизвестность как-то работает для этого, но ненадежно. WhatamIdoing ( talk ) 20:22, 26 сентября 2024 (UTC) [ ответить ]

Они не знают, как, может быть, но, что еще важнее, они не знают, что им это разрешено. Мы должны помнить, насколько необычен наш совместный процесс . Если неопытный редактор добавляет статью в Википедию, а затем ее быстро снимают с публикации с сообщением, что с ней что-то не так, они не подумают, хм, я не уверен, согласен ли я с этим, я собираюсь вернуться и/или обсудить это с моими коллегами-редакторами, чтобы найти консенсус. Они подумают, что кто-то, кто имеет право решать, что делать со статьями, отклонил мой вклад, и я просто новичок. В этот момент они либо сдадутся (большинство), либо проявят упорство и начнут пытаться удовлетворить сначала рецензента NPP, а затем череду рецензентов AfC, пока они, наконец, не сдадутся или не напишут GA, что, по-видимому, является примерно стандартом, применяемым AfC в наши дни. Даже очень опытные редакторы попадают в эту ловушку , потому что, хотя шаблонные сообщения пытаются сообщить обо всем спектре возможностей, имеющихся у пользователя (по крайней мере, сейчас, после того как я и другие потратили несколько лет на борьбу за это), действительно сложно сообщить, что мы все равны и у всех есть право голоса здесь, в рамках структуры черновик-рецензирование, которая неявно возвышает мнение рецензентов над другими. –  Джо ( обсуждение ) 07:31, 27 сентября 2024 (UTC) [ ответить ]

Я вытащил последние 10 статей, перемещенных в mainspace с помощью скрипта AFCH. Они:

607-я авиационная эскадрилья управления – 80 слов на Wikipedia:Prosesize , 2 ссылки: Stub на рейтинг качества статьи mw:ORES.
Уилл Патнэм – 296 слов, 15 рефери: Старт.
Герб Саскатуна – 380 слов, 4 ссылки: Начало.
Городской реализм – 304 слова, 4 ссылки: Начало.
Девара: Часть 1 (саундтрек) – 547 слов, 29 ссылок: класс C.
Почитай отца твоего и мать твою: правдивая история убийств Менендеса – 562 слова, 8 ссылок: класс C.
XP-21279 – 200 слов, 11 ссылок: Начало.
Система отмены запуска Crew Dragon – 641 слово, 23 ссылки: класс B.
Винс Зампелла – 536 слов, 18 ссылок: класс C.
Джеффри Кан – 179 слов, 14 рефери: Начало занятия.

Это в среднем 372,5 слов и 12,6 ссылок. Медианная статья имеет 338 слов и 4 ссылки. По сравнению с существующими статьями, 53% наших существующих статей имеют менее 372,5 слов, а 83% имеют менее 12,6 ссылок. Каждая шестая статья имеет меньше слов, чем самая короткая статья в этом списке. Одна из трех статей короче, чем вторая самая короткая статья в этом списке.

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

Кстати, за тот же промежуток времени из пространства имен Draft: было удалено более 100 страниц. Не стоит думать, что это означает, что удаляется более 90% черновиков, потому что удаления происходят неравномерно, а это относительно небольшой размер выборки, но это примерно то, чего я ожидал. WhatamIdoing ( talk ) 20:56, 27 сентября 2024 (UTC) [ ответить ]

Вывод: Я, к сожалению, не удивлен текущим состоянием этой дискуссии. Некоторые горячие споры не по теме граничат с поведением NOTHERE . Я очень разочарован, увидев это от опытных редакторов. Тем из вас, кто просто прокомментировал предложение: я очень вам благодарен.

Поскольку шаблон проекта NPP по умолчанию был изменен на Template:Draft article за день до начала этого обсуждения, я думаю, что мое предложение спорно. Я не вижу, как мы могли бы значительно улучшить этот шаблон, но я могу поднять некоторые незначительные изменения формулировок в Template Talk. Если кто-то хочет закрыть это обсуждение, это нормально; если другие хотят продолжить обсуждение других вещей здесь, я желаю вам всего наилучшего. Toadspike [Обсуждение] 21:16, 27 сентября 2024 (UTC) [ ответить ]

Стоит также поговорить об уведомлении usertalk, которое оставляет MTD, которое предлагает только один вариант: отправить на рецензию. Согласен в принципе, мы не должны обманывать людей, заставляя их думать, что черновик/AfC обязательны для типичного создателя статьи. —Рододендриты ^{говорят}\\ 13:29, 28 сентября 2024 (UTC) [ ответить ]

Strong Oppose Все, что он сделает, это уничтожит систему черновиков в ее нынешнем виде и в конечном итоге уничтожит Википедию. Это почти произошло между 2008 и 2012 годами, до того, как процесс черновиков стал доступен, когда Википедия была переполнена платными/coi редакторами, и не было эффективной системы для борьбы с ними. Неужели люди не понимают, что такое черновик? У каждого издателя есть процесс черновиков. Это НЕ путь к удалению. Так говорят критики системы, многие из которых получают деньги за то, чтобы противостоять ей и уничтожать ее. Это одна из основных гарантий, которые у нас есть против полного уничтожения Википедии. scope_creep ^Talk 11:46, 29 сентября 2024 (UTC) [ ответить ]
Этот комментарий почти полностью представляет собой предположения недобросовестности без доказательств. Пожалуйста, попробуйте вступить в дискуссию, а не просто поспешно выступить против изменения статус-кво, потому что это изменит статус-кво. Thryduulf ( обсуждение ) 12:56, 29 сентября 2024 (UTC) [ ответить ]
Это не бездоказательно, и я возмущен тем фактом, что вы назвали мой комментарий недобросовестным. Зачем бы я делал комментарий, если бы не знал, о чем говорю. Я работал в NPP/AFC с момента его создания и участвовал в некоторых ранних обсуждениях. Я знаю, как именно ведут себя редакторы UPE/платные редакторы. Это привело бы к исходу редакторов после того, как место заполонили бы рекламой. Это было бы бесплатно для всех. Реальность такова, что редактор, который опубликовал, не продумал это и не заглянул в архивы, чтобы увидеть, какова была ситуация тогда. scope_creep ^Talk 16:05, 29 сентября 2024 (UTC) [ ответить ]
"Поверьте мне, я там был" — это не доказательство. Ваш комментарий предполагает недобросовестность тех, кто с вами не согласен, и всех, кто отправляет новые статьи. Не каждый редактор получает оплату (и раскрытое платное редактирование явно разрешено), не каждое платное редактирование (раскрытое или иное) плохо, не каждый платный редактор (раскрытое или иное) пытается навредить энциклопедии, не каждое платное редактирование (даже нераскрытое) наносит вред энциклопедии. Thryduulf ( обсуждение ) 16:19, 29 сентября 2024 (UTC) [ ответ ]
Это верно в определенной степени, но большинство редакторов, которые создают современные биографические, организационные и продуктовые статьи, которые составляют большинство, являются незаявленными оплачиваемыми редакторами. Они не заботятся о наших интересах и никогда не заботились. scope_creep ^Talk 16:53, 29 сентября 2024 (UTC) [ ответить ]
Даже если это правда (и вы не предоставили никаких доказательств, ни вашего утверждения, ни его последствий, что эти статьи наносят вред Википедии и/или что черновик в его нынешнем виде и практика предотвращают этот вред), это не означает, что черновик в его нынешнем виде не может быть улучшен и что любые изменения в статус-кво будут означать смерть Википедии. Thryduulf ( обсуждение ) 17:02, 29 сентября 2024 (UTC) [ ответ ]
@ Scope creep , какой процент статей в черновиках, по вашему мнению, удаляется? WhatamIdoing ( talk ) 18:51, 29 сентября 2024 (UTC) [ ответить ]
Если черновики удаляются, то это потому, что их создатели отказались от них. Вот что такое G13. Возможно, следует приложить больше усилий, чтобы побудить авторов статей улучшать свои статьи после того, как они были перемещены в черновик (где их можно улучшать без вмешательства), но черновик — это не преднамеренное, злонамеренное удаление через бэкдор, и я не согласен, когда его характеризуют как таковое. Cremastra ( обсуждение ) 19:47, 29 сентября 2024 (UTC) [ ответить ]
Это двойной вопрос ? В комментарии, на который вы отвечаете, было сказано только «путь к удалению», а вы превратили его в четыре отдельные части:
преднамеренный
вредоносный
черный ход
удаление.
Я бы лично не охарактеризовал ни одно из них как злонамеренное, но я думаю, что часть из них преднамеренны. По моему мнению, утверждение, что никто никогда не отправлял пограничного субъекта в AFC вместо AFD (где на практике более низкие стандарты), было бы довольно необычным. Честно говоря, я не думаю, что мы все настолько глупы, что не можем понять, какой маршрут с наибольшей вероятностью приведет к желаемому нами результату.
Если мы характеризуем AFD как «входную дверь» для удаления, то, по-видимому, справедливо будет назвать прекращение действия статей в разделе «Черновик» «задней дверью».
Но в оригинальном комментарии просто говорится, что это не путь к удалению. Но если 90–95% всех статей, размещенных на этом пути, действительно в конечном итоге удаляются, то разве не справедливо сказать, что это один из наших путей к удалению? WhatamIdoing ( talk ) 20:22, 29 сентября 2024 (UTC) [ ответить ]
Oppose . Текущая формулировка тега дает понять любому, у кого есть хоть капля здравого смысла, что статья имеет потенциал, но в ее нынешнем виде она не готова для mainspace. Некоторые комментарии здесь от людей явно указывают на отсутствие понимания того, для чего нужен процесс черновика. Если статья в ее нынешнем виде проходит GNG, то есть только определенные обстоятельства, при которых ее следует черновиковать (например, платное редактирование), но если статья, вероятно, пройдет GNG, но не в ее нынешнем виде (например, недостаточно подробных источников из независимых, надежных источников, чтобы соответствовать стандарту), то это пример черновика. Когда я был более активен в рецензировании статей, я создал несколько пользовательских ответов, которые брали стандартное сообщение и немного его подправляли в зависимости от причины черновика (например, UPE, отсутствие GNG) или конкретной темы (например, NFOOTY, населенные пункты). В некоторых случаях эти сообщения содержали предложение напрямую связаться со мной, когда они посчитают, что статья готова для mainspace. Я полностью за создание статей, но меня также волнует качество и репутация Википедии, которая часто рассматривается как кульминационный момент для шуток о мусорной информации в Интернете. И я бы полностью не согласился с теми, кто говорит, что черновик не является чистой выгодой. На самом деле, я думаю, что это один из самых полезных инструментов, помогающих улучшить качество в WP. Всегда ли он используется правильно? Нет. Но это проблема образования отдельных пользователей, а не первостепенная проблема самого процесса. Onel 5969 ^{TT me} 14:34, 29 сентября 2024 (UTC) [ ответить ]
Я согласен с Onel5969. (Но также помните, что не следует оставлять !голосов, так как это лаборатория идей, а не официальное предложение). Cremastra ( обсуждение ) 14:36, 29 сентября 2024 (UTC) [ ответить ]
Извини, Кремастра. Онель 5969 ^{TT мне} 19:38, 29 сентября 2024 г. (UTC) [ ответить ]
Это может быть хорошо в теории, но это не соответствует тому, что происходит на практике. Особенно учитывая, что статьи перемещаются в draftspace из-за недостаточного качества, которое соответствует классу C или даже B. Если статья написана нейтрально и соответствует GNG, то нет никаких оснований перемещать ее в draftspace только потому, что кто-то мог (или не мог) получить плату за ее редактирование. Thryduulf ( talk ) 15:21, 29 сентября 2024 (UTC) [ ответить ]
@ Thryduulf : Вы имеете в виду конкретный пример, когда упоминаете статьи класса C или B? scope_creep ^Talk 16:13, 29 сентября 2024 (UTC) [ ответить ]
См. комментарий @ WhatamIdoing в этом обсуждении. Thryduulf ( обсуждение ) 16:15, 29 сентября 2024 (UTC) [ ответить ]
Этот список — состояние статей, когда они выходят из пространства Draft:. Для статей, которые попадают в пространство Draft:, вот текущий список:
Черновик: Sargodha Satellite Fields – 376 слов, 5 ссылок (причина: «нужно больше источников»)
Черновик:Näsir Zaman – 20 слов, 10 ссылок (причина: «нужно больше источников»)
Черновик: Ахсан Халил – 48 слов, 15 ссылок (причина: «нужно больше источников»)
Черновик: Мартин-Дж. Сепульведа – 232 слова, 9 ссылок (причина: «вероятно, скрытая реклама»)
Черновик:Грегори Бортц – 270 слов, 22 референса (причина: «вероятно, скрытая реклама»)
Черновик: Юрий Юрьевич Шикула – 40 слов, 3 ссылки (на самом деле ~150 слов; причина: «нужно больше источников»)
Черновик: Дуайт Карлтон Харрис – 151 слово, 3 ссылки (перемещено автором из-за отсутствия источников; тот же редактор добавил источники полчаса спустя)
Черновик: Железные дороги Родезии, 19 класс – 4 слова (это список), 0 <ref>, но указаны два источника (причина: «нет источников, индивидуальная причина»)
Черновик:De Zandbak – 107 слов, 5 ссылок (причина: «нужно больше источников»)
Проект: Киан Брекин (футболист) – 316 слов, 15 рефери (перемещено автором без указания причины, но было удалено на AFD в прошлом году)
Я пропустил перенаправления, некоторые циклические замены страниц и пару редакторов, перемещающих заявки AFC из пространства User: в пространство Draft:, и попытался включить только статьи, перемещаемые из основного пространства в пространство Draft:. Я не могу получить рейтинги ORES для этих статей, но на первый взгляд я думаю, что Start и C-class — это не необоснованное описание. WhatamIdoing ( talk ) 19:31, 29 сентября 2024 (UTC) [ ответить ]
Во-первых, спасибо за предоставление списка. Проблема в том, что при просмотре этих черновиков большинство из них являются добротными черновиками, а не "Особенно учитывая, что статьи перемещаются в черновик из-за недостаточного качества, которые относятся к классу C или даже B". Хотя я думаю, что можно было бы дать более подробное объяснение. Например, первый пример был бы лучше с "необходимыми более подробными ссылками из независимых, надежных источников", а не просто "необходимо больше источников", поскольку в черновике нет ни одной подробной ссылки из независимого, надежного источника. Второй и третий примеры представляют собой ту же самую проблему. Четвертый и пятый примеры правильно помечены как скрытая реклама (оба редактора были за это заблокированы - кроме того, в четвертом не было ни одной подробной ссылки из независимого источника). 6-й пример, хотя и имеет 3 источника, ни один из них не является подробным, и хотя это может быть разница в написании в переводах 2-й и 3-й ссылок, похоже, что тема статьи не упоминается ни в одной из них. 7-я статья не является настоящим примером черновика, так как она была перемещена автором. 8-я и 9-я статьи не имеют независимых надежных источников (для 9-й газета, на которую ссылаются, не имеет номера страницы, и ссылка, похоже, не выводит ничего подробного о хакерской лаборатории). Не уверен насчет 10-й, потому что история немного сумасшедшая, но, опять же, не выглядит как пример черновика.

Я думаю, это иллюстрирует некоторые недоразумения, которые создают люди, которым не нравится черновик. Вы смотрите на предоставленный список и думаете: «Ого, куча ссылок, большинство из которых не являются заглушками или микрозаглушками, какого черта они были черновиками?» Черт, я сам так делал, задаваясь вопросом, были ли все 10 сделаны одним редактором, который, возможно, не имел твердого понимания черновиков. Но затем вы погружаетесь в достоинства источников или проблемы upe, и оказывается, что все 8 черновиков кажутся оправданными. Onel 5969 ^{TT me} 20:32, 29 сентября 2024 (UTC) [ ответить ]

@ Onel5969 , интересно, могли бы вы немного лучше объяснить «газету» в 9-й статье. Вы говорите, что в статье «ноль независимых надежных источников», но традиционные печатные газеты являются независимыми надежными источниками. Затем вы говорите, что у нее нет номера страницы, но ссылка ведет вас прямо на отсканированную копию правильной страницы; цитируемая статья [название, указанное в цитате] находится в последних двух столбцах. Ничто из этого не делает газету менее независимой. Вас беспокоит, что статья, по-видимому, предшествует использованию имени в названии статьи («De Zanbak» означает «Песочница»)? WhatamIdoing ( talk ) 20:51, 29 сентября 2024 (UTC) [ reply ]

Может быть перевод, но, похоже, нет ничего, что связывало бы группу, упомянутую в этой статье, с De Zanbak. Но даже если и есть, agf, это все равно единственный глубокий независимый источник. Onel 5969 ^{TT me} 01:15, 30 сентября 2024 (UTC) [ ответить ]

Я рад, что мы согласны, что газета — это независимый источник. WhatamIdoing ( обсуждение ) 01:20, 30 сентября 2024 (UTC) [ ответить ]

Если новый редактор включает 5 источников в свою заявку, и она перемещается [куда-то, куда я ее не поместил], потому что «нужно больше источников» или «источников нет», сколько из них потратят время, чтобы узнать, что опытный редактор на самом деле имел в виду, что ни один из этих источников не содержит того, что я считаю существенным, глубоким освещением в независимых надежных источниках , а затем с уверенностью скажут: «На самом деле, этот опытный человек, имеющий полномочия удалить мою статью из Википедии, неправ, а я прав, я научусь оспаривать его и как и где выражать свою точку зрения таким образом, чтобы влиятельные люди меня выслушали», а не просто сдаваться в какой-то момент на этом пути? И прежде чем кто-либо это скажет, нет, только потому, что среди отговорившихся могут оказаться несколько недобросовестных редакторов, не оправдывает потерю добросовестных редакторов. Thryduulf ( обсуждение ) 21:29, 29 сентября 2024 (UTC) [ ответить ]

Думаю, в этом и заключается разница между редакторами, которые заботятся о качестве на WP, и теми, кто заботится о количестве. Но именно поэтому я сказал, что обоснование могло бы быть и лучше. Onel 5969 ^{TT me} 01:17, 30 сентября 2024 (UTC) [ ответить ]

Действительно ли это вопрос качества или количества?

Или в этом разница между редакторами, которые предпочли бы, чтобы страница прошла через Wikipedia:Articles для удаления или Wikipedia:Proposed article mergers, а не была бы в одностороннем порядке скрыта до тех пор, пока она не будет удалена без того уровня контроля со стороны сообщества, который мы ожидаем от AFD? Например, я не уверен, что «De Zanbak» — это жизнеспособная тема для статьи, но я думаю, что есть несколько способов, которыми мы могли бы решить эту проблему, и я не вижу, чтобы пространство Draft: помогало. Фактически, единственное, что делает перемещение этой страницы в пространство Draft:, отличается от перемещения этой страницы в пространство User:, так это: гораздо более вероятно, что она будет удалена в течение следующего года, если она находится в пространстве Draft:, чем если она находится в пространстве User:. WhatamIdoing ( talk ) 01:26, 30 сентября 2024 (UTC) [ reply ]

Ну, поскольку черновик не является «лазейкой для удаления» и не «сокрытием статьи», это определенно вопрос качества против количества. Короче говоря, черновик — это мера контроля качества. Это статьи, которые могут быть достаточно заметными для основного пространства, но просто не в достаточно хорошей форме, чтобы быть там. Но, как и другие средства в WP, добросовестные редакторы могут не согласиться с заметностью статьи, так, например, в статье De Zandbak, Jay8g (который отметил ее как заметную) и Jonathan Deamer (который ее черновик) могут счесть ее потенциально заметной, в то время как вы, WhatamIdoing, могли просто отправить ее в AfD, потому что не считаете ее заметной. Но это не значит, что система не работает. Возможно, мы можем подправить текущую формулировку в шаблоне, включив туда ресурсы о том, куда редактор может обратиться за помощью (например, AFC или Teahouse)? Онель 5969 ^{TT мне} 09:20, 30 сентября 2024 г. (UTC) [ ответить ]

Ну, поскольку черновик не является «лазейкой для удаления» и не «сокрытием статьи», вы говорите так, как будто добросовестные редакторы не могут не согласиться, но это просто неправда. Является ли что-либо из этого правдой — вопрос мнения (и, по моему мнению, согласующегося с представленными доказательствами). Thryduulf ( talk ) 10:07, 30 сентября 2024 (UTC) [ ответить ]

Привет. Нет, редакторы, конечно, могут иметь разные толкования и не соглашаться по вопросам. Однако в данном случае это не вопрос разногласий. Придерживаться этих взглядов указывает на отсутствие понимания того, что такое процесс черновика. Это не то, что такое черновик, это, как я уже сказал, просто мера контроля качества. Это все равно, что сказать, что это вопрос мнения, написал ли этот человек статью о себе или нет, что можно интерпретировать как не редактирование COI. Если статья просто скопировала и вставила информацию из Encyclopedia Brittanica, вы не можете сказать, что это ваше мнение, что это не копирайтинг. Я имею в виду, что я испытываю к вам огромное уважение, Thryduulf, и вы отлично справляетесь с WP. В WP есть вещи, которые субъективны (например, что именно составляет SIGCOV), в то время как другие объективны (например, редактирование UPE/COI, копирайтинг). То, что такое черновик, попадает в последнюю категорию. При всем этом мы можем не согласиться с тем, следовало ли или не следовало направлять черновик отдельной статьи. Вы говорите, что представленные доказательства показывают, что не было оснований отправлять эти статьи на черновик. Однако, если просмотреть источники, то становится ясно, что черновик был оправдан. Это разница во мнениях. Onel 5969 ^{TT me} 14:20, 30 сентября 2024 (UTC) [ ответить ]

По Вашему мнению, перемещение статьи в раздел «Черновик» — это просто мера контроля качества .

По моему мнению, перемещение статьи в раздел «Черновик» — это просто мера контроля качества , которая, по сравнению с доступными альтернативами размещения статьи в основном разделе, отправки ее в AFD или перемещения ее в раздел «Пользователь», существенно снижает вероятность улучшения качества и существенно повышает вероятность удаления статьи.

Ах да: Последние два пункта ( «существенно снижает вероятность улучшения качества» и «существенно увеличивает вероятность удаления статьи» ) — это не «мнения». Это объективные факты. WhatamIdoing ( обсуждение ) 22:17, 30 сентября 2024 (UTC) [ ответ ]

19-й класс железных дорог Родезии — это не список; это поезд, который был в эксплуатации в течение нескольких диапазонов времени. Даже если бы это был список, пустые заголовки и единственное содержимое, являющееся таблицей, далеко не start-class, возможно, даже substub. Аарон Лю ( talk ) 20:47, 29 сентября 2024 (UTC) [ ответить ]

Существующее содержимое статьи — это инфобокс и таблица. Таблицы — это формат, который предпочитает Wikipedia:Featured lists . Пустые разделы не запрещены, а рейтинги основаны на том, что уже есть. Я бы оценил это как |class=Listсегодня. WhatamIdoing ( talk ) 20:53, 29 сентября 2024 (UTC) [ ответить ]

только содержимое таблицы, вы вообще читали страницу? Это информационное поле полно контента, есть два, по-видимому, надежных источника, а сама таблица содержит около 20 строк контента. Thryduulf ( talk ) 21:33, 29 сентября 2024 (UTC) [ ответить ]

Извините, да, инфобокс тоже. Хотя я бы все равно не назвал это началом. Аарон Лю ( обсуждение ) 22:03, 29 сентября 2024 (UTC) [ ответить ]

Можем ли мы рассмотреть возможность изменения уровня ЕС?

Это всего лишь идея, и я хочу немного поработать над этим, но я думаю, что было бы полезно иметь ожидающие изменения на расширенном подтвержденном уровне. Это можно было бы снова назвать "PC2" (не путать с оригинальным PC2) или "PCECP". Идея заключается в том, чтобы помочь обеспечить соблюдение WP:ARBECR и подобных ограничений, когда неподтвержденным пользователям запрещен доступ к определенным тематическим разделам. На этом уровне правки неподтвержденных редакторов будут задерживаться для проверки, в то время как подтвержденные пользователи с расширенным статусом могут одобрять эти правки и, таким образом, брать на себя ответственность в соответствии с WP:PROXYING .

Я думаю, это было бы полезно для страниц, где (1) части статьи пересекаются со спорной темой, или (2) статья в целом пересекается со спорной темой, но не редактируется часто. Отлично Aasim 16:54, 27 сентября 2024 (UTC) [ ответить ]

Кажется, это может быть полезно. Его придется ограничить страницами, которые редактируются нечасто (вероятно, исключая все статьи о текущих событиях), чтобы не перегружать Pending Changes каждый раз, когда Reuters публикует новую историю или разгорается война правок. Главный вопрос: какую проблему вы пытаетесь решить? Toadspike [Обсуждение] 20:39, 27 сентября 2024 (UTC) [ ответить ]

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

PCECP по сути устранит опасения, что «недостаточно помех, чтобы оправдать защиту», буферизируя все неподтвержденные расширенные вклады, чтобы их пришлось одобрять, в соответствии с принципом «неподтвержденные расширенные могут делать только запросы на редактирование». Шаблоны, предназначенные специально для этого случая, такие как {{ edit protected }}, ломаются, когда страница не защищена. Потрясающе Aasim 22:00, 27 сентября 2024 (UTC) [ ответить ]

Проблема в том, что правило 500/30 специально разработано для того, чтобы не допускать новых редакторов из-за экстремального количества помех, как правило. Есть веская причина, по которой обе главные мировые войны ( арабо-израильский конфликт и русско-украинская война ) находятся ниже 500/30. И, как уже неоднократно упоминалось и стоит повторить еще раз, большой объем правок в данной статье является противопоказанием к CRASHlock.

Но самым большим камнем преткновения здесь является то, что пока не существует консенсуса по поводу расширенно-подтвержденного CRASHlock. Последнее обсуждение расширения CRASHlock до более высоких уровней защиты предшествовало XCP. Для этого нужен был бы формальный RfC, а не VP-спитбол. — Jéské Couriano v^_^v ^{threads critiques} 15:37, 28 сентября 2024 (UTC) [ ответить ]

Защита XCON имеет смысл для статей с высоким трафиком, но для статей с низким трафиком? Если правка незначительная, например исправление орфографических или грамматических ошибок, проблем быть не должно. Исправление орфографии и грамматики, как правило, находится за пределами спорных тем. Из WP:ARBECR : На любой странице, где ограничение не применяется с помощью расширенной подтвержденной защиты, это ограничение может применяться другими методами, включая ... использование ожидающих изменений.

Я бы, наверное, также установил фильтры злоупотреблений, чтобы видеть, находится ли страница в категории, которая в первую очередь посвящена спорной теме, а затем предупреждал бы и отмечал спорные правки. Отлично Aasim 16:22, 28 сентября 2024 (UTC) [ ответить ]

Большинство статей CT с низким трафиком не имеют никакой защиты, поскольку они никогда не видели количества вандализма, требующего защиты. Запросы на защиту, которые полагаются исключительно на принудительное исполнение арбитража и не содержат практически никаких доказательств вандализма, отклоняются. Аарон Лю ( обсуждение ) 23:26, 28 сентября 2024 (UTC) [ ответить ]

Да, я это понимаю, но проблема в том, что редактирование, не относящееся к XCON, будет одобрено на страницах, которые просматривает не так много людей. Ожидающие изменения по-прежнему позволяют пользователям, не являющимся XCON, вносить эти изменения, но их изменения должны быть одобрены, и их можно отменить, если они нарушают WP:ARBECR . Это также соответствует тому, как ожидающие изменения используются в статьях с низким трафиком для отслеживания (а не предотвращения) сбоев. Потрясающе Aasim 18:26, 29 сентября 2024 (UTC) [ ответить ]

@ Aaron Liu Большинство статей CT с низким трафиком не имеют никакой защиты, поскольку они никогда не видели количества вандализма, требующего защиты. Запросы на защиту, которые полагаются исключительно на принудительное применение арбитража и незначительные или отсутствующие доказательства вандализма, отклоняются. Неправда, статьи в темах ECR могут и блокируются превентивно. На самом деле происходит то, что статьи с минимальными нарушениями обычно не попадают в WP:RFPP или не замечаются своенравным администратором. Mach61 19:53, 29 сентября 2024 (UTC) [ ответить ]

Неверно, статьи в темах ECR могут быть заблокированы и блокируются заранее.

Не могли бы вы привести пример? Существует длинный список отклоненных запросов RFPP на арбитражное принуждение. Аарон Лю ( обсуждение ) 20:42, 29 сентября 2024 (UTC) [ ответить ]

Посмотрите на этот обмен мнениями между администратором, который отказался защищать на основе ECR из-за отсутствия помех, и (бывшим) администратором, который объяснил им обратное. Mach61 19:46, 1 октября 2024 (UTC) [ ответить ]

Спасибо, теперь я понял «можно». Аарон Лю ( обс .) 20:59, 1 октября 2024 (UTC) [ ответить ]

Кажется разумным. Я всегда задавался вопросом, почему ожидающие изменения не развертываются чаще. Это кажется полезным инструментом, и есть много рецензентов ожидающих изменений, так что очень мало бэклога Cremastra ( обсуждение ) 14:18, 28 сентября 2024 (UTC) [ ответить ]

Поскольку есть достаточно людей, которые не любят или не доверяют ожидающим изменениям, трудно достичь консенсуса для их использования. См., например, Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article . Аномия ⚔ 14:41, 28 сентября 2024 (UTC) [ ответить ]

Ну, черт возьми, мне интересно , почему? — Jéské Couriano v^_^v ^{темы критика} 15:39, 28 сентября 2024 (UTC) [ ответить ]

Не могли бы вы пояснить свою точку зрения? Я ее не вижу. Anomie ⚔ 17:04, 28 сентября 2024 (UTC) [ ответить ]

@ Anomie : Прочитайте раздел «Предложение» на связанной странице. Тот факт, что RFC вообще существует, должен дать вам представление о том, почему CRASHlock так недоверчиво относится к значительному меньшинству редакторов. — Jéské Couriano v^_^v ^{threads critiques} 18:01, 9 октября 2024 (UTC) [ ответить ]

Все еще не вижу. Люди, предположительно, не доверяют ему, потому что был пробный период 14 лет назад, и администраторы enwiki не прекратили его использование сразу после пробного периода, ожидая консенсуса о будущем функции? Anomie ⚔ 18:43, 9 октября 2024 (UTC) [ ответить ]

Знакома ли вам идиома «верблюжий нос » ? — Jéské Couriano v^_^v ^{темы критика} 18:47, 9 октября 2024 (UTC) [ ответить ]

TL;DR, который я выношу из этой дискуссии, заключается в том, что вы все еще в ярости из-за того, что консенсус не пошел вам на пользу 12 или 13 лет назад, и предполагаете, что любой противник ПК разделяет эту причину и никакую другую. Я думаю, что вряд ли продолжение этого разговора приведет к чему-то полезному. Anomie ⚔ 18:59, 9 октября 2024 (UTC) [ ответить ]

Консенсус тоже не так работает. Консенсус может быть определен RfC, да. Но он может также развиваться просто по тому, как все уже делается, независимо от того, обсуждалось ли это формально.

Я думаю о примере, приведенном Technology Connections об «опасности, но иногда». Светодиодный светофор превосходит по энергосбережению и многому другому, но иногда на них скапливается снег и лед, поэтому они плохие. Аналогично, ожидающие изменения XCON помогут с обеспечением соблюдения WP:ARBECR , но иногда администраторы могут применять это к страницам вне политики, поэтому его не следует использовать снова. Правильным ответом было бы установить защитные ограждения политики, чтобы администраторы этого не делали. Отлично Aasim 19:00, 9 октября 2024 (UTC) [ ответить ]

Как RfC, принятый более 13 лет назад, все еще отражает консенсус сегодня? Я почти уверен, что, хотя некоторые мнения могли не измениться, другие определенно изменятся. Никто не говорит, что должны быть полные ожидающие изменения. Потрясающе Aasim 18:16, 9 октября 2024 (UTC) [ ответить ]

@ Awesome Aasim : RFC был специально связан, чтобы указать на одну из причин недоверия к системе ПК. Самый последний RFC по CRASHlock , как я уже сказал, предшествует XCP как концепции. — Jéské Couriano v^_^v ^{threads critiques} 18:20, 9 октября 2024 (UTC) [ ответить ]

Также, пожалуйста, объясните, что вы подразумеваете под "crashlock". Я не могу найти ни одного обсуждения или записи в глоссарии по "crashlock". Awesome Aasim 18:21, 9 октября 2024 (UTC) [ ответить ]

@ Awesome Aasim : Это должно быть ОЧЕНЬ очевидно из контекста. — Jéské Couriano v^_^v ^{темы критика} 18:26, 9 октября 2024 (UTC) [ ответить ]

Полагаю, вы единственный, кто использует эту терминологию, поскольку ее нет в WP:GLOSSARY или где-либо еще.

Тем не менее, это Idea Lab; это место для разработки идей, а не для демонстрации резкого сопротивления идеям. Именно для этого и существуют другие форумы; для опроса консенсуса. Следует отметить, что WP:ECP изначально был создан с целью обеспечения соблюдения арбитражных решений и общественных санкций. Он никогда не предназначался для чего-то другого; его просто использовали для других вещей de facto . Отлично Aasim 18:40, 9 октября 2024 (UTC) [ ответить ]

( конфликт редактирования ) Все эти вещи, которые вы считаете очевидными, на самом деле таковыми не являются. Вам следует попытаться объясниться лучше, а не решительно махать руками на что-то случайное. Аномия ⚔ 18:43, 9 октября 2024 (UTC) [ ответить ]

Очевидно, возможно, но все равно не имеет особого смысла. Я не уверен, как использование собственных специальных терминов с неясным подтекстом для принижения вещей, которые вам не нравятся, помогает общению или пониманию сообщества здесь. Cremastra ( talk ) 19:37, 9 октября 2024 (UTC) [ ответить ]

Я не понимаю. Люди не доверяют ПК из-за бюрократической ошибки в реализации эксперимента более 10 лет назад? (В нецентрализованной бюрократии, где постоянно случается всякая ерунда?) В RfC четко указано, что он не выносит нормативных суждений о ПК, и, похоже, !избиратели тоже этого не делают. SamuelRiv ( обсуждение ) 18:37, 9 октября 2024 (UTC) [ ответить ]

Это одна из причин, и, вероятно, самая главная для некоторых (кто считал, что неправильное обращение с пробой было попыткой навязать нам CRASHlock/FlaggedRevisions ). Другая причина в том, что с 2010 по 2014 год запросы на комментарии по CRASHlock вызывались не реже одного раза в год , и большинство из них писалось редакторами, выступающими за CRASHlock . — Jéské Couriano v^_^v ^{темы критика} 18:42, 9 октября 2024 (UTC) [ ответить ]

Хорошо, для тех, кто не в курсе политики WP, есть обзорная статья-мнение из WSP за август 2011 года, которая, кажется, отражает отношение и последствия. Похоже, что результаты закрытия RfC оставили администраторов в неопределенном состоянии относительно того, можно ли когда-либо применить или удалить PC. SamuelRiv ( talk ) 18:47, 9 октября 2024 (UTC) [ ответить ]

относительно того, может ли ПК когда-либо быть применен или удален, это было верно в 2011 году, когда это было написано, но более поздние RFC разрешили это. Anomie ⚔ 19:02, 9 октября 2024 (UTC) [ ответить ]

Не могли бы вы дать ссылку на указанные RfC? Все остальное, что было связано ранее, касается главной страницы. SamuelRiv ( обсуждение ) 19:56, 9 октября 2024 (UTC) [ ответить ]

Wikipedia:Pending changes/Request for Comment 2012 установил базовый консенсус для использования ПК, с Wikipedia:PC2012/RfC 2 и Wikipedia:PC2012/RfC 3 , проясняющими некоторые детали. PC level 2 , с другой стороны, так и не получил консенсуса для использования, и в конечном итоге в 2017 году был достигнут консенсус по удалению его из конфигурации. Шаблон:Pending changes discussions содержит много ссылок. Anomie ⚔ 22:14, 9 октября 2024 (UTC) [ ответить ]

Стоит отметить, что, насколько мне известно, RfC 2017 года — последний, касающийся любого аспекта CRASHlock. Как я уже сказал выше, для достижения консенсуса по расширенно подтвержденному CRASHlock потребуется новый RfC, поскольку изначально PC2 был уровнем полной защиты, а в RfC 2016 года не было задано ни одного вопроса о ECP!CRASHlock , ни один из которых не был особенно всеобъемлющим. (Последним всеобъемлющим RfC был clusterfuck 2014 года .) — Jéské Couriano v^_^v ^{threads critiques} 06:47, 10 октября 2024 (UTC) [ ответить ]

Я думаю, что основные причины, по которым редакторы не хотят расширять использование ожидающих изменений, носят практический характер: технической поддержки для исправлений (или разработки дополнительных функций) на горизонте не предвидится, несмотря на задокументированные ошибки; и неуверенность в способности сообщества управлять расширенным использованием. Конечно, есть редакторы, которые высказывают опасения из-за прошлой истории, но это уже стало фактором в других решениях, и на них, соответственно, повлияли, чтобы они были более определенными в отношении того, как будут проходить любые испытания. isaacl ( talk ) 18:55, 9 октября 2024 (UTC) [ ответить ]

Может быть, это то, что нужно...

Многокомпонентный RFC, спрашивающий, как следует применять ECR для существующих страниц, в том числе на основе активности. Высокотрафикным страницам понадобится расширенная защита задним числом, поскольку они, как правило, больше всего страдают от нарушений ECR. Низкотрафикным страницам — не так много, но мы можем использовать фильтры злоупотреблений и ожидающие изменения ECP для этого. Насколько мне известно, исправления орфографии и грамматики исключены из WP:ARBECR . Потрясающе Aasim 19:52, 1 октября 2024 (UTC) [ ответить ]

Я рассматриваю ECR в области PIA как абсолютный (без полной остановки редактирования теми, кто не соответствует 500/30), поэтому CRASHlock там в любом случае не будет рассмотрен. Я не уверен, применимо ли это также к WP:GS/RUSUKR (который попадает в область EE). — Jéské Couriano v^_^v ^{темы критика} 18:57, 9 октября 2024 (UTC) [ ответить ]

Можем ли мы построить предложение здесь?

Вот небольшой вступительный текст, который, возможно, поможет нам начать:

Каков наилучший способ применения WP:ARBECR к статьям?
- Вариант 1: Упреждающая защита XCON
- Вариант 2: Упреждающие изменения XCON, ожидающие своего решения
- Вариант 3: Редактировать фильтры
- что-нибудь еще?

Это, вероятно, неполное, у кого-нибудь еще есть идеи по этому предложению? Отлично Aasim 19:41, 16 октября 2024 (UTC) [ ответить ]

#### в [тема]

Должны ли статьи о годах в темах быть связаны в статьях? Например, первая ссылка The Little Girl Lost ведет на 1794 в поэзии . Ссылка выглядит как нарушение Wikipedia:OLINK , но конкретно не указано. Ссылки только на годы уже исчезли, но почему ссылки о темах активно не удаляются? Roasted ( talk ) 22:56, 28 сентября 2024 (UTC) [ ответить ]

Все началось в каком-то году, и ссылка на этот год со статьей о куче нерелевантной информации бесполезна. Но в статье о стихотворении, написанном в 1794 году, вполне разумно ссылаться на статью о других очень связанных вещах того года. Это не правило, но это оправданная точка зрения, особенно для стихотворений 230-летней давности, когда это своего рода чудо, что у нас есть какие-либо записи о стихотворении. Johnuniq ( talk ) 01:04, 29 сентября 2024 (UTC) [ ответить ]

Я думаю, что это оправданная точка зрения, особенно для тем, которые обсуждаются/ссылаются в статье. Это похоже на наш принцип WP:BIDIRECTIONAL для навигационных окон: если вы можете добраться от 1794 в поэзии до The Little Girl Lost , то было бы идеально, если бы вы могли вернуться назад.

Я думаю, что это более оправданно для более коротких/узких тем, чем для размашистых страниц. 1794 в поэзии — это нормально. 2023 в кино — это может быть не так. WhatamIdoing ( обсуждение ) 01:23, 29 сентября 2024 (UTC) [ ответить ]

Список немецких фильмов 2023 года , из которых вы можете по праву попасть в 2023 год в кино , может быть другой историей. Thryduulf ( обсуждение ) 10:19, 29 сентября 2024 (UTC) [ ответить ]

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

Еще один момент, который следует учитывать, — это форматирование. Сравните эти предложения:

«Маленькая потерянная девочка» — стихотворение Уильяма Блейка, опубликованное в 1794 году в его сборнике «Песни невинности и опыта» .
Это список немецких фильмов , выход которых запланирован на 2023 год .

Во-первых, метка ссылки — «стихотворение 1794 года», и если вы удивлены, что нажатие на «стихотворение 1794 года» переносит вас на стихотворение 1794 года , то, возможно, вы не обращали внимания на то, на что нажимали.

Во втором случае ссылка имеет метку «2023», и вы могли бы ожидать 2023 вместо фильмов 2023 года . Я бы предложил изменить эту ссылку так, чтобы она включала слова «в 2023 году» вместо одного года. WhatamIdoing ( talk ) 19:37, 29 сентября 2024 (UTC) [ ответить ]

Мои 2¢: удалить прямые ссылки, но поместить статьи "ГОД в ТЕМЕ" в раздел "см. также". Это устраняет любые проблемы MOS:EGG и, если что-то еще, больше соответствует аналогии с двунаправленными навигационными ящиками Mach61 03:35, 30 сентября 2024 (UTC) [ ответить ]

Мне это нравится.

(Боже, я бы хотел, чтобы навигационные панели были в этом разделе. Аарон Лю ( обсуждение ) 11:43, 30 сентября 2024 (UTC) [ ответить ]

Я думаю, что ключевой вопрос здесь (обосновывающий эту позицию) заключается в том, что хотя «2023 год в поэзии» может быть связан, поскольку это тот же год и в то время было опубликовано не так уж много поэзии, это не значит, что в отношении этого стихотворения будет уместно или полезно знать, какие еще 100 случайных стихотворений были опубликованы в том же году. Mrfoogles ( обсуждение ) 06:21, 13 октября 2024 (UTC) [ ответ ]

Боты расширения URL

Согласен, что короткие URL нежелательны. Однако не лучше ли было бы, если бы бот автоматически расширял эти URL, а не заносил их в черный список? Например, youtu.be в youtube.com/watch?v= , tinyurl.com/example в example.com (это его фактическая цель). Elominius ( критика | вклад ) 09:19, 30 сентября 2024 (UTC) [ ответить ]

Причина, по которой они занесены в черный список, заключается не в том, что они «нежелательны», а в том, что их можно (и уже использовали) использовать для обхода черного списка спама и других мер по борьбе со спамом. Если ссылка легитимна, нет причин, по которым пользователь, пытающийся ее добавить, не может ее расширить. Anomie ⚔ 11:25, 30 сентября 2024 (UTC) [ ответить ]

@ Anomie : нет причин, по которым пользователь, пытающийся добавить его, не может его расширить. Причина в том, что конечный пользователь не знает, что он должен это сделать, и сообщение не объясняет, что это то, что должно быть сделано (или как). И несколько сайтов используют более короткие URL-адреса, когда вы используете кнопку «Поделиться», которая является типом сокращателя URL-адресов, который идет только на один домен, как псевдоним домена, и поэтому не может быть использован в злонамеренных целях. Polygnotus ( talk ) 23:00, 7 октября 2024 (UTC) [ ответить ]

Я, конечно, вижу оправдание для того, чтобы рассматривать сокращатели, привязанные к одному домену (например, youtu.be), иначе, чем общие, например, tinyurl. Thryduulf ( обсуждение ) 23:22, 7 октября 2024 (UTC) [ ответить ]

@ Thryduulf : См. meta:Talk:Spam_blacklist#youtu.be. Polygnotus ( обсуждение ) 23:43, 7 октября 2024 (UTC) [ ответить ]

В этом случае, как я написал в VPT, бот может выполнить проверку черного списка и возврат, если развернутая ссылка попадает в черный список; или мы просто интегрируем механизм автоматического расширения в MediaWiki. Milky Defer 08:34, 10 октября 2024 (UTC) [ ответить ]

Это упускает из виду тот факт, что люди могут использовать URL-сокращатель для перехода по спаму или вредоносному ПО, даже если цель не заблокирована. Быстрая проверка различий того, кто делает это, показывает ссылку на сокращатель, и человек, проверяющий, должен быть полностью мотивирован, чтобы изучить, что произойдет, если он нажмет на нее. Если исходное редактирование добавляет ссылку на рынок или сомнительный сайт, его намного проще отменить. Мы не хотим бота, который благословляет внешние ссылки, расширяя их. Johnuniq ( talk ) 01:32, 11 октября 2024 (UTC) [ ответить ]

Возможно, бот мог бы обнаружить, кто добавил ссылку, если учетная запись проходит некоторые эвристические тесты на надежность, она будет считаться достаточно надежной для расширения. Однако много работы. Насколько большой проблемой являются короткие URL-адреса? -- Green C 02:50, 11 октября 2024 (UTC) [ ответить ]

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

Я думаю, что идеальным вариантом для MediaWiki было бы выполнение преобразования перед сохранением для расширения коротких URI до полной формы, затем проверка их по черному списку, а затем либо сохранение длинной формы, либо отклонение правки в зависимости от ситуации (сообщение об ошибке для отклоненной правки должно отображать как короткие, так и длинные URI, чтобы редакторы знали, какая ссылка вызвала срабатывание черного списка и почему). Я полагаю, что это должно происходить на уровне программного обеспечения? Мне также интересно, есть ли какие-то средства автоматического определения того, какие URI сокращены, или это придется делать вручную? (например, будет ли он знать, что http://sucs.org/uri/as является коротким URI (что приводит к сокращению URL ) без уведомления?) Thryduulf ( обсуждение ) 03:18, 11 октября 2024 (UTC) [ ответ ]

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

Чтобы развернуть его до длинной формы, требуется запрос заголовка, внешнего сайта или API, что может быть непрактично на интерактивном уровне MediaWiki.

. Сокращенные URL-адреса можно документировать; я создал страницу, которая документирует архивные URL-адреса: Wikipedia:Список веб-архивов в Wikipedia (включая некоторые из них с сокращенными URL-адресами). Легко начать технический документ Wikipedia:Список сайтов по сокращению URL-адресов в Wikipedia, и надеяться, что со временем люди найдут его и добавят знаний. -- Green C 04:06, 11 октября 2024 (UTC) [ ответить ]

Создание шаблона: Информационное поле Wikidata

Привет, я предлагаю создать шаблон под названием «Шаблон: Информационный блок Викиданных», который создает информационный блок на основе информации, существующей в Викиданных. Та же идея реализована в WikiCommons. См. https://commons.wikimedia.org/wiki/Wikipedia:Village_pump_(idea_lab)/Category:Quantum_computing и информационный блок раздела, в котором используется {{Информационный блок Викиданных}}. Ваше здоровье. Хуман Маллахзаде ( разговор ) 13:33, 1 октября 2024 г. (UTC) [ ответ ]

Использование Wikidata для инфобоксов обсуждалось здесь много раз и является на удивление (для меня) спорным. Некоторые конкретные инфобоксы включают информацию из Wikidata (iirc Майк Пил проделал некоторую работу над этим), но я не думаю, что один общий инфобокс, будь то извлечение информации из Wikidata или из чего-то другого, получит консенсус. Я оставлю заметку об этом обсуждении на Wikipedia talk:WikiProject Infoboxes и Wikipedia talk:WikiProject Wikidata . Thryduulf ( talk ) 13:42, 1 октября 2024 (UTC) [ ответить ]

Да... МНОГО сопротивления импорту данных из Wikidata в наши инфобоксы. Две основные проблемы — это проверяемость/надежность (хотя WD улучшили этот фронт, они все еще не соответствуют нашим политикам) и простота редактирования (необходимость заходить в WD для редактирования информации, появляющейся в WP, может сбивать с толку).

Поделюсь личным опытом замешательства... структура WD, ориентированная на данные, часто непонятна мне как текстовому редактору здесь, в WP. Когда я пытаюсь исправить ошибки в WD, мне это очень трудно сделать. Даже просто найти информацию, которую нужно отредактировать, сложно. То, как организованы и структурированы страницы WD, для меня чуждая абракадабра. Blueboar ( обсуждение ) 14:18, 1 октября 2024 (UTC) [ ответить ]

Wikidata — это хорошая идея, если нужен удобный интерфейс. Его использование было бы значительно облегчено, если бы вы могли редактировать данные здесь, и они были бы сброшены обратно в Wikidata. -- LCU Активно Неинтересно « @ » ° ∆t ° 14:39 , 2 октября 2024 (UTC) [ ответить ]

Именно так настроено большинство Wikivoyage. Это не автомагия (за исключением, возможно, немецкого языка), поэтому у вас есть полный контроль над тем, какие биты вы импортируете локально, а какие биты своего контента вы возвращаете в Wikidata. Этот контроль важен, поскольку некоторый контент отличается. Например, Wikivoyage обычно хочет поместить широту/долготу на вход в местоположение, а Wikidata обычно хочет центр. Нет необходимости переопределять местоположения друг друга, если они существенно различаются (например, вход в Disney World против центра Disney World). Когда они одинаковы, вы можете обмениваться ими туда и обратно. WhatamIdoing ( talk ) 04:23, 3 октября 2024 (UTC) [ ответить ]

В Commons есть только один тип инфобокса. У нас их много, и в них отображаются очень разные данные. Лично я бы хотел включить wikidata почти во все инфобоксы, но один общий инфобокс не может удовлетворить наши потребности. Аарон Лю ( обсуждение ) 14:14, 1 октября 2024 (UTC) [ ответить ]

Я действительно думаю, что этот тип инфобокса (возможно, в свернутом виде) является лучшей заменой инфобокса статей, для которых мы не можем создать никакого инфобокса, как квантовые вычисления . Эти данные включают ссылки на WikiQuote и его идентификатор библиотеки и т. д., что делает их доступными и под рукой. Я предлагаю использовать этот тип инфобокса в других разделах, таких как раздел «См. также», вместо верхнего, заменив многие существующие шаблоны, такие как {{Commons category}}. Хуман Маллазаде ( обсуждение ) 14:32, 1 октября 2024 (UTC) [ ответ ]

Эм, какое значение можно получить, используя d:Q17995793 для заполнения инфобокса для статьи Квантовые вычисления ? Действительно ли нам нужен инфобокс для этой статьи, чтобы прояснить, что предмет является примером «академической дисциплины», подклассом «вычислений» и является изучением «квантового компьютера» и/или «квантового превосходства»? Это прекрасный пример статьи, которая не нуждается в инфобоксе. Folly Mox ( talk ) 02:31, 2 октября 2024 (UTC) [ ответить ]

О, я вижу, вы хотите использовать инфобокс внизу статьи как навигационный блок? Это менее предосудительно, и также это другой вид блока на нашем жаргоне. Folly Mox ( обсуждение ) 02:44, 2 октября 2024 (UTC) [ ответить ]

@ Hooman Mallahzadeh , не каждая статья выигрывает от инфобокса. По моему мнению, квантовые вычисления — одна из них. Remsense ‥ 论06:14, 2 октября 2024 (UTC) [ ответить ]

@ Remsense Есть хорошие ссылки на WikiQuote, Wikiversity, Wikidata, WikiCommons, идентификатор авторитета Библиотеки Конгресса, которые прикрепляются к основной статье путем простого включения этого шаблона. Это большое преимущество для Wikidata-Infobox квантовых вычислений . Но сворачивание этого Wikidata Infobox по умолчанию кажется разумным. Hooman Mallahzadeh ( обсуждение ) 06:26, 2 октября 2024 (UTC) [ ответить ]

Мы уже можем это сделать, ссылаясь на те, которые важны внизу — это чрезвычайно распространено и уже сделано в этой статье! Однако это поднимает ключевой момент сопротивления этому. Мы не хотим передавать много на аутсорсинг в Wikidata, потому что мы не можем так же легко решить, что не показывать, чтобы не загрязнять статьи метаданными, которые могут быть полезны в базе данных, но являются функционально бесполезным мусором в статье энциклопедии. По сути, мы никогда не должны ожидать, что редакторам придется использовать Wikidata. Remsense ‥ 论06:28, 2 октября 2024 (UTC) [ ответить ]

Этот метод немного сложный, ⁣вставка кумулятивных ссылок «по одному шаблону» кажется мне более разумной. Hooman Mallahzadeh ( обсуждение ) 06:31, 2 октября 2024 (UTC) [ ответить ]

Нет, потому что решение о том, стоит ли ссылаться на Wikiquote в конкретной статье, должны принимать редакторы этой статьи. Remsense ‥ 论06:32, 2 октября 2024 (UTC) [ ответить ]

Я не согласен. Согласно эффекту Зейгарник , размещение ссылки Wikiquote, которая сейчас пуста, мотивирует пользователей завершить эту страницу и разместить какую-нибудь цитату об этой концепции. Хуман Маллазаде ( обсуждение ) 06:38, 2 октября 2024 (UTC) [ ответить ]

Наша работа не в том, чтобы создавать Wikiquote, но наша работа в том, чтобы не засорять статьи энциклопедии бесполезным мусором. Ваша позиция вызвала бы возмущение почти у любого редактора, которому небезразлично, как выглядят статьи, которые он пишет, и что именно они представляют читателям. Remsense ‥ 论06:59, 2 октября 2024 (UTC) [ ответить ]

Большинству читателей все равно. Те немногие, кому это небезразлично, удовлетворены тем, что находятся внизу. Аарон Лю ( обсуждение ) 11:34, 2 октября 2024 (UTC) [ ответить ]

Hooman Mallahzadeh , ваша идея единого шаблона общего назначения для создания ссылок на родственные проекты из связанного элемента Wikidata для использования в ==External links==разделе на самом деле звучит как хорошая идея, но люди в этой подтеме были сбиты с толку вашим использованием термина infobox (который находится в верхней части статьи). Однако это звучит идентично существующему шаблону {{ Sister project auto }} . Чем отличается ваша идея? Folly Mox ( обсуждение ) 12:35, 2 октября 2024 (UTC) [ ответить ]

Если идея заключается в том, чтобы показать некоторую исходную информацию, она также может быть похожа по концепции на широко используемый шаблон {{ Authority control }} . SamuelRiv ( talk ) 15:07, 2 октября 2024 (UTC) [ ответить ]

Правильно, {{ authority control }} уже вездесущ (~2 131 000 включений из 6 896 901 статьи, включая перенаправления), даже включен в вывод по умолчанию Wikipedia:ArticleWizard , и {{ authority control }} уже извлекает из Wikidata. Folly Mox ( обсуждение ) 17:54, 2 октября 2024 (UTC) [ ответ ]

Итак, учитывая все это, @ Hooman Mallahzadeh , я бы предложил просто создать/разветвить шаблон в этом направлении (или отредактировать существующий шаблон в его песочнице), поскольку эта базовая концепция не будет вызывать споров. Остальная часть обсуждения здесь — гипотетический беспорядок, пока люди не увидят, что именно вы имеете в виду, что может радикально отличаться от того, что уже используется в этих шаблонах выше. SamuelRiv ( обсуждение ) 18:41, 2 октября 2024 (UTC) [ ответить ]

Что-то вроде Category:Earth показывает, как сложно получить автоматическое, хорошее информационное поле, а не кучу странных записей. "Пример: "внутренняя планета Солнечной системы (Марс, Венера)" А Меркурий? Если вы по какой-то причине перечислите здесь остальных, перечислите их все... "Назван в честь: *почва (Земля) *земля (1, 地, 地球) *шар (2, 球, 地球)" Э-э, что? Понятия не имею, почему здесь показан японский язык. "Время возникновения: 4541-е тысячелетие до н. э. (свинцово-свинцовое датирование, возраст Земли, креационизм молодой Земли)" Да, мы определенно хотим здесь ссылку на креационизм молодой Земли... "Дата растворения, отмены или уничтожения: неизвестное значение (будущее Земли)" Даже не ссылка, просто текст, как будто это хоть как-то полезно. И это вряд ли какой-то малоизвестный пример. Fram ( talk ) 14:30, 1 октября 2024 (UTC) [ ответить ]

{{ Infobox person/Викиданные }} , кто-нибудь? - Выступление Qwerfjkl 18:42, 1 октября 2024 г. (UTC)[ отвечать ]

Какой замечательный способ внести непроверенную информацию (ошибки) и бессмыслицу в статьи Википедии. -- Ssilvers ( обсуждение ) 20:46, 1 октября 2024 (UTC) [ ответить ]

Непроверенная информация и неверная информация (то, что, как я предполагаю, вы подразумеваете под «ошибками») не являются синонимами. Не все в WikiData является непроверенным, неверным или бессмысленным. Thryduulf ( talk ) 20:51, 1 октября 2024 (UTC) [ ответить ]

@ Ssilvers Есть простой параметр, позволяющий включать только информацию со ссылками. Плохие ссылки существуют и могут быть легко исправлены с использованием тех же методов на обоих сайтах. Аарон Лю ( обсуждение ) 21:01, 1 октября 2024 (UTC) [ ответить ]

У Wikidata иные стандарты источников, чем у enwiki — сайты, которые по консенсусу enwiki считаются ненадежными, в Wikidata считаются вполне приемлемыми. Записи Wikidata также исключены из существующих механизмов очистки enwiki. Так что не все так просто, как вы предлагаете, применить одни и те же методы к обоим сайтам — у двух сайтов нет ни одинаковых методов, ни общего понимания того, что такое «плохая ссылка». Nikkimaria ( обсуждение ) 00:22, 2 октября 2024 (UTC) [ ответить ]

Кто -нибудь пытается выработать общее понимание, или все думают, что это нормально, что сайт отключен таким образом, даже если они могли бы помогать друг другу гораздо больше? Если у вас есть ссылки на обсуждения, я был бы рад их прочитать. Амир Э. Ахарони ( обсуждение ) 00:46, 2 октября 2024 (UTC) [ ответить ]

Я воспринимаю это как взаимную апатию в обеих базах пользователей: люди, которые пишут энциклопедию, не совпадают с людьми, которые хотят создать универсальную базу данных. Хотя результаты и неутешительны, было бы неразумно ожидать, что одна группа добровольцев будет действовать по стандартам другой. Remsense ‥ 论06:07, 2 октября 2024 (UTC) [ ответить ]

Затем мы должны сообщить Wikidata, почему и какие источники плохие и часто ложные. Я не вижу ни одного источника, который считался бы очень достоверным в Wikidata и удалялся бы на месте в Wikipedia. Аарон Лю ( обсуждение ) 01:10, 2 октября 2024 (UTC) [ ответ ]

[1]. Никкимария ( обсуждение ) 01:25, 2 октября 2024 (UTC) [ ответить ]

@ Nikkimaria , это был ответ мне? Просто один комментарий от одного человека? Амир Э. Ахарони ( обсуждение ) 02:15, 2 октября 2024 (UTC) [ ответить ]

Это не был ответ вам. Это было бы лучшим местом для начала вашего вопроса, хотя эта точка зрения также имеет значение. Nikkimaria ( talk ) 02:32, 2 октября 2024 (UTC) [ ответить ]

Спасибо, замечание принято. В таком случае нам как минимум нужно иметь переопределения параметров. Аарон Лю ( обсуждение ) 02:43, 2 октября 2024 (UTC) [ ответить ]

Любопытно, что один из аргументов в этом RfC - "FInd a Grave получен из надгробий". Разве не лучше было бы в таком случае сослаться на надгробие? Хотя, отклонившись от темы, отходим от темы. Аарон Лю ( обсуждение ) 02:46, 2 октября 2024 (UTC) [ ответить ]

Утверждение, что Wikidata неверны, — это всего лишь утверждение. Это вики, она тесно интегрирована с Wikipedia, и она может быть такой же правильной или неправильной, как и сама Wikipedia. Амир Э. Ахарони ( обсуждение ) 21:06, 1 октября 2024 (UTC) [ ответить ]

Да, мы знаем, что Википедия несовершенна… Вот почему мы НЕ считаем Википедию надежным источником и НЕ используем одну часть Википедии для проверки других частей Википедии. Blueboar ( обсуждение ) 21:18, 1 октября 2024 (UTC) [ ответить ]

Но что в этом плохого, если мы можем машинно проверить, что повторно используемая часть имеет источник? Речь идет не о поиске в Wikidata, а о повторном использовании исходного контента из Wikidata, по всем причинам, по которым {{ excerpt }} хорош. Аарон Лю ( talk ) 21:20, 1 октября 2024 (UTC) [ reply ]

Предлагает ли кто-нибудь использовать Wikidata для проверки информации в Wikipedia? Я так не думаю. Я определенно так не думаю.

Люди предлагают вставлять то, что написано в Wikidata, в английскую Википедию в некоторых случаях, когда это более эффективно. Их можно проверить так же, как и саму Википедию. Амир Э. Ахарони ( обсуждение ) 21:32, 1 октября 2024 (UTC) [ ответить ]

Я не думаю, что Википедия должна отдавать приоритет эффективности. Мы должны отдавать приоритет заботе. Если люди хотят повторно использовать исходный контент из Викиданных, они могут добавить контент и добавить источник. Мы не должны просто приглашать его некурируемым. Folly Mox ( обсуждение ) 02:41, 2 октября 2024 (UTC) [ ответить ]

Перефразируя Шрека: Но он курируется . Какая разница , курируется ли он редактором Википедии или редактором Викиданных? Викиданные — это не совсем отдельный сайт. Эти два сайта всегда были тесно связаны с точки зрения как сообщества, так и технологий, и имели одну и ту же конечную цель — свободное знание, редактируемое как вики. Если между ними есть различия в политике проверяемости, я бы подумал о том, чтобы попытаться навести мосты между ними, а не отвергать идею сотрудничества сразу. Амир Э. Ахарони ( обсуждение ) 13:43, 2 октября 2024 (UTC) [ ответить ]

Мы не должны оставлять курирование контента, включаемого в статьи, людям, которые обычно не просматривают или не редактируют указанные статьи напрямую. Мне это кажется совершенно очевидным. Remsense ‥ 论13:51, 2 октября 2024 (UTC) [ ответить ]

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

И в чем разница между изменением чего-либо в Викиданных, что будет включено в статью Википедии, и изменением шаблона в Википедии, что будет включено в другие страницы? (Кроме разницы в URL-адресе.) Или изменение изображения на Commons и Амир Э. Ахарони ( обсуждение ) 14:00, 2 октября 2024 (UTC) [ ответить ]

Процессы курирования между двумя сайтами совершенно разные. en.wiki в первую очередь курируется на уровне отдельных страниц, wikidata, по-видимому, в первую очередь курируется на перекрестных участках, где пересекается множество страниц. (Также стоит учесть, какая часть Wikidata создается ботами, извлекающими данные из других вики.) CMD ( обсуждение ) 14:03, 2 октября 2024 (UTC) [ ответ ]

Потому что они редактируют базу данных! Они могут даже не говорить по-английски, не говоря уже о нюансах того, как английская Википедия (или любой другой проект, чтобы быть ясным) может быть затронута тем, что они делают напрямую. Независимо от того, считаете ли вы, что это не совсем разные веб-сайты, это разные веб-сайты. Я действительно не думаю, что мне нужно вдаваться в социологию, чтобы обсудить здесь набор социальных фактов, которые довольно очевидны для всех, кто вносит вклад в проект Викимедиа. «Википедия — это один сайт, Викиданные — это другой» также должно ответить на ваш второй вопрос: если кто-то нарушает шаблон, для меня не является сдвигом парадигмы исправить это или попросить кого-то другого сделать это, потому что это происходит на том же самом веб-сайте . Вы свободолюбивы, и это нормально; любое решение по дизайну, которое предполагает такое качество участников в целом, было бы ужасным. Remsense ‥ 论14:11, 2 октября 2024 (UTC) [ ответить ]

Другой способ представить это так: это один и тот же веб-сайт с разными URL-адресами.

И я не уверен, что вы имеете в виду под "качеством участников" и "свободным духом" ближе к концу. В моем понимании свободный дух в свободной энциклопедии - это хорошо, но я подозреваю, что вы имеете в виду что-то другое. Амир Э. Ахарони ( обсуждение ) 19:08, 2 октября 2024 (UTC) [ ответить ]

Wikidata — это, безусловно, совершенно другой сайт, вездесущий в своих низких стандартах включения. Аарон Лю ( обсуждение ) 19:29, 2 октября 2024 (UTC) [ ответить ]

Это само по себе не проблема. Вы можете включить некоторые вещи из него в Википедию и исключить другие. Это более или менее то, что уже происходит в английской Википедии, но это происходит чаще в некоторых других языках, и это работает там довольно хорошо. Я не понимаю сопротивления, которое некоторые англоязычные Википедисты оказывают включению чего-либо из Викиданных. Амир Э. Ахарони ( обсуждение ) 16:14, 3 октября 2024 (UTC) [ ответ ]

Я согласен, что это не проблема. Я не согласен с тем, что вы сказали, что это один и тот же сайт и они тесно связаны. Аарон Лю ( обсуждение ) 17:11, 3 октября 2024 (UTC) [ ответить ]

Они:

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

Так что заставляет вас думать, что они не являются близкородственными? Амир Э. Ахарони ( обсуждение ) 22:06, 3 октября 2024 (UTC) [ ответить ]

Тесно связанные в плане базовой инфраструктуры и перекрывающихся целей не равнозначны тому, чтобы быть одним и тем же веб-сайтом с разными URL-адресами. По замыслу, каждый вики-сайт Wikimedia имеет свое собственное сообщество со своей собственной культурой, которое определяет свои собственные руководящие принципы и рабочие процедуры. isaacl ( talk ) 22:14, 3 октября 2024 (UTC) [ ответить ]

Все, что я пытаюсь сказать, это то, что он не сильно отличается от Commons. Он в чем-то отделен, а в чем-то тот же. Некоторые данные из Commons и Wikidata полезны в английской Википедии, некоторые — нет. Подчеркивать только различия, как это делают некоторые англоязычные Википедисты, некорректно и неполезно. Амир Э. Ахарони ( обсуждение ) 22:22, 3 октября 2024 (UTC) [ ответить ]

Все, что en.wiki берет из Commons, это по сути URL-адреса файлов. Это совсем другое место, чем en.wiki, с совсем другими нормами. CMD ( обсуждение ) 23:24, 3 октября 2024 (UTC) [ ответить ]

И, эм, файлы, а не только URL-адреса, верно?

Какие бы внутренние нормы ни были у Commons, английская Wikipedia берет из него много файлов. И то же самое может быть с Wikidata. Английская Wikipedia уже берет из него некоторые данные, и она может взять еще.

На самом деле я не поддерживаю использование общего инфобокса Wikidata в английской Википедии. Я просто пытаюсь понять сопротивление, которое некоторые редакторы английской Википедии испытывают, когда хотят включить что-либо из Wikidata. Амир Э. Ахарони ( обсуждение ) 03:12, 4 октября 2024 (UTC) [ ответить ]

Ключевые элементы сопротивления были объяснены в другом месте в этой теме. Они связаны с более низким качеством источников, более высокой уязвимостью к вандализму и сложностью редактирования Wikidata. Проблемы источников не распространяются на Commons, а изменение файлов там ограничено теми, у кого есть расширенные разрешения. En.wiki не импортирует файлы из Commons, хотя размещает файлы отдельно, когда они не подходят для включения в Commons. CMD ( обсуждение ) 04:17, 4 октября 2024 (UTC) [ ответ ]

Commons извлекает выгоду из общих требований, установленных Wikimedia Foundation по использованию медиа, поэтому файлы легко использовать в любой Wikimedia wiki. (Конечно, медиа, которые встраивают информацию, такую как годовая статистика, страдают от тех же проблем, что и Wikidata: их точность зависит от загрузчика.) Для тех, кто обеспокоен стандартами проверки в Wikidata, к сожалению, у меня нет хорошего предложения по созданию лучших процессов для проверки правок, сохраняя при этом подход «любой может редактировать, все проверяют». По своей природе данные очень плотные, поэтому я думаю, что попытка дважды проверить все входящие правки — более утомительная и обременительная работа, чем можно ожидать от добровольцев. isaacl ( talk ) 06:35, 4 октября 2024 (UTC) [ ответить ]

Однако редакторы Wikidata не курируют контент в статьях: это делают редакторы в вики, которые используют wiki-data. Wikidata — это исходная информация, и редакторы решают, какую из них включить. Вот почему я также считаю, что шаблоны должны включать переопределения параметров перед переключением на wiki-data по умолчанию. Аарон Лю ( обсуждение ) 19:30, 2 октября 2024 (UTC) [ ответ ]

Насколько мне известно, переопределение параметров — это то, что делается в Википедии на всех языках, на которых шаблоны извлекают информацию из Викиданных, и это имеет смысл. Если бы это не было где-либо, я бы очень удивился. Амир Э. Ахарони ( обсуждение ) 16:17, 3 октября 2024 (UTC) [ ответить ]

Wikidata Infobox на Commons появился из первоначальной работы, которую я делал здесь, на enwiki, — это та же кодовая база, что и {{ Infobox person/Wikidata }} и т. п., но она значительно развилась из-за большого количества конструктивных предложений на Commons. У нее есть два представления — одно для людей, одно для всего остального, и, как было показано, это работает очень хорошо в целом, и она намного более масштабируема и удобна в обслуживании, чем тысячи более специализированных шаблонов. Технически, Wikidata infoboxes сейчас довольно зрелые — и подобные им часто используются в разных языковых Википедиях. Wikidata также довольно хорошо интегрированы в различные рабочие процессы в Wikimedia в настоящее время (включая здесь, с WiR redlists ). Главный вопрос — социальный: заинтересовано ли сообщество enwp в продолжении Wikidata infoboxes и в том, чтобы тратить время и энергию на конструктивный вклад в улучшение данных и уточнение логики шаблонов, как это делают сообщество Commons и другие языковые сообщества Википедии. Спасибо. Майк Пил ( обсуждение ) 21:00, 1 октября 2024 (UTC) [ ответить ]

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

Возможно, нам следует изучить что-то более близкое к двунаправленной, но ручной синхронизации, которую использует Wikivoyages (например, для официальных сайтов и широты/долготы примечательных мест). Если вы этого не видели, то перейдите в свое любимое место отдыха на voy: (например, voy:en:Paris/7th_arrondissement#See) и прокрутите вниз, пока не найдете раздел, в котором есть [add listing]кнопки редактирования раздела рядом с обычными. Щелкните по нему, и вы увидите большое диалоговое окно. Справа найдите пустое место для Wikidata и введите известную достопримечательность (например, «Эйфелева башня»; она не сохранит редактирование, пока вы вручную не скажете ей это). Щелкните «быстрая выборка», чтобы увидеть, что предлагает Wikidata (а затем «Отмена» полностью, чтобы не вносить никаких изменений в статью или Wikidata). Также есть диалоговое окно, позволяющее выбирать отдельные биты (например, я хочу свой URL, но широту/долготу Викиданных, или удаленно заменить старую информацию в Викиданных новой информацией). Что-то вроде этого можно сделать, и можно даже настроить запрос источников. Добавление источников в Викиданные обычно довольно просто, так как вы просто выбираете тип (например, ISBN, DOI, URL...) и напрямую добавляете необработанный идентификационный номер/URL. WhatamIdoing ( talk ) 05:49, 2 октября 2024 (UTC) [ reply ]

Хотя я согласен с вашей оценкой процессов принятия решений WP, и я действительно считаю, что в идеале нам следует больше работать со структурированными данными WD, WD ничего не упрощает (вторя Blueboar выше), и, честно говоря (судя по моим попыткам поднять этот вопрос с ними), похоже, вообще не имеет никакого отношения к концепции UX. Интерфейс Commons работает хорошо, но как только он переносит вас для непосредственного редактирования полей Wikidata, вы оказываетесь в их сбивающем с толку интерфейсе, где то, что должно быть таким же базовым, как разница между «свойством» и «ссылкой» (и где добавлять ссылку, что рекомендуется, но что не является «ссылкой»), находится ниже нескольких минут документации. (Самое странное во всем этом то, что в WD Discord, похоже, люди неправильно размещают или не добавляют данные — это их задача №1 по обслуживанию.)

Проект (в его текущем состоянии) пригоден для использования, если мы сможем ограничить максимально возможное взаимодействие с пользователем в наших целях, но даже Commons не смог сделать это в полной мере. (Примечание: я могу свободно жаловаться на некоторую редакцию WD здесь, потому что я уже много раз поднимал эти же вопросы напрямую перед редакторами WD, часто с плохими ответами.) SamuelRiv ( обсуждение ) 15:03, 2 октября 2024 (UTC) [ ответ ]

Прежде чем я смогу поддержать более глубокую интеграцию Викиданных в статьи Википедии, мне бы хотелось иметь следующее:

очевидный маркер в викикоде, указывающий, откуда из Викиданных извлекается параметр (например, или что-то в этом роде), с возможностью локальной перезаписи или очистки параметра|parameter=:wd
более понятные сообщения об ошибках, которые позволяют людям, не имеющим опыта работы с Викиданными, понять, какой элемент данных отсутствует в шаблоне или не может быть понят, какие ссылки напрямую связаны со свойством элемента Викиданных, вызывающим проблему, или, если его нет, то одна ссылка на описание свойства и одна ссылка на исходный элемент

Я столкнулся с несколькими ошибками шаблонов, когда ошибка возникла в Wikidata, и ни в одном случае я не смог решить их самостоятельно. Если редакторы, выступающие за интеграцию Wikidata, здесь готовы приложить усилия, чтобы сделать свои шаблоны дружественными для редакторов Wikipedia со средними и ниже техническими способностями, то я мог бы рассмотреть возможность присоединиться, но в настоящее время они действуют как непостижимые черные ящики, и их эффект на практике заключается в лишении полномочий большого подмножества редакторов в этом сообществе. Folly Mox ( обсуждение ) 12:47, 2 октября 2024 (UTC) [ ответ ]

Я согласен с этим. Я помню фиаско, когда {{ start date and age }} кричали, когда неправильные вики-данные возвращали несколько дат для одного селектора. Должен быть способ, чтобы эти шаблоны сами ошибались, не перезаписывая ошибку внешними шаблонами-обертками. Аарон Лю ( talk ) 13:05, 2 октября 2024 (UTC) [ reply ]

«Добавление источников в Wikidata обычно довольно просто, поскольку вы просто выбираете тип (например, ISBN, DOI, URL...) и напрямую добавляете необработанный идентификационный номер/URL».

Случайный элемент [2], первая неиспользуемая запись: "таксон". "Добавить ссылку" открывает поле "свойство", которое дает раскрывающийся список с 5 вариантами. Я хочу использовать книгу, поэтому, полагаю, "указано в" будет правильным выбором. Открывается новый раскрывающийся список с бесконечным выбором, начиная с "человек"???, "человеческое поселение"???, картина, деревня, фамилия... Что это за писк??? Может, мне нужно ввести "книга", и я смогу продолжить? О, нет, на этом все заканчивается. Wikidata крайне неинтуитивно понятна и случайна. Fram ( talk ) 08:32, 2 октября 2024 (UTC) [ ответить ]

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

Да, просто введите название книги... Ожидать, что он угадает, какую книгу вы хотите процитировать, совершенно неразумно.
Вы также можете просто выбрать "ISBN-13" вместо "указано в". Аарон Лю ( обсуждение ) 11:38, 2 октября 2024 (UTC) [ ответить ]

Подобно собственному «неинтуитивному и случайному» синтаксису MediaWiki для вставки ссылок, Wikidata также имеет справочные страницы, такие как wikidata:Help:Sources, которые объясняют вам именно это. Аарон Лю ( обсуждение ) 11:43, 2 октября 2024 (UTC) [ ответ ]

Даже если можно научиться, прочитав руководство (я на это надеюсь!), я думаю, что их возражение против характеристики этого как просто «легкого» было достаточно справедливым. Remsense ‥ 论11:54, 2 октября 2024 (UTC) [ ответить ]

Добавить ссылку в Wikidata по крайней мере так же просто, как и в Wikipedia. То, что методы не одинаковы, не меняет этого. Thryduulf ( talk ) 11:58, 2 октября 2024 (UTC) [ ответить ]

Я не оспариваю это. Remsense ‥ 论11:59, 2 октября 2024 (UTC) [ ответить ]

Да. Fram ( talk ) 12:21, 2 октября 2024 (UTC) [ ответить ]

Одно отличие, на которое стоит обратить внимание, заключается в том, что на en.wiki можно выполнить поиск по Help:Citation и что-то найти, тогда как в Wikidata большинство страниц Help: являются элементами Wikidata. На Wikidata:Help:Sources есть руководство, но оно ведет только к источникам, которые являются либо элементами Wikidata, либо URL-адресами. CMD ( talk ) 12:31, 2 октября 2024 (UTC) [ reply ]

Хорошее замечание по поводу поиска с ошибками, но в главном меню есть кнопка "Справка".
Вы, кажется, пропустили раздел "Различные типы источников". Аарон Лю ( обс .) 12:44, 2 октября 2024 (UTC) [ ответить ]

Не знаю, как вы пришли к такому странному выводу. Раздел «Различные типы источников» — это руководство по созданию элементов Wikidata, а не по их поиску. CMD ( обсуждение ) 13:05, 2 октября 2024 (UTC) [ ответить ]

Он поможет вам сослаться на базу данных с идентификатором элемента (база данных действительно является элементом Wikidata, но обычно элемент для используемой вами базы данных уже создан), надгробие, Wikisource и архивные записи. Аарон Лю ( обсуждение ) 13:11, 2 октября 2024 (UTC) [ ответить ]

Эта ветка обсуждения посвящена утверждению о том, что добавление ссылки Wikidata «обычно довольно просто» в контексте сравнений с en.wiki. Если бы я сказал, что ссылаться на что-то в en.wiki легко, нужно просто создать для этого новую статью, я подозреваю, что люди не сочтут это убедительным аргументом или полезным вкладом. CMD ( обсуждение ) 13:16, 2 октября 2024 (UTC) [ ответ ]

Новые элементы в Wikidata не являются статьями. Их сложность далека от сложности новых статей. Тем не менее, автоматически сгенерированные справочные элементы, например, из URL, очень помогли бы. Аарон Лю ( обсуждение ) 16:21, 2 октября 2024 (UTC) [ ответить ]

Я думаю, вы недооцениваете трудности, с которыми люди могут столкнуться при создании элементов Wikidata. CMD ( обсуждение ) 03:02, 3 октября 2024 (UTC) [ ответить ]

Это действительно просто. Хотя кнопка «Создать новый элемент» в главном меню не так уж и заметна, шаги оттуда почти такие же простые, как заполнение {{ cite book }} . Аарон Лю ( talk ) 17:12, 3 октября 2024 (UTC) [ ответить ]

Создав элементы, это не так просто, как с помощью замечательного создателя цитат en.wiki, но помимо этого я не вижу смысла игнорировать множество людей, которые заявили, что им сложно анализировать Wikidata. CMD ( обсуждение ) 23:28, 3 октября 2024 (UTC) [ ответить ]

Автоматически генерируемые справочные элементы из URL-адресов планируются для Wikidata, и поскольку для их генерации будет использоваться Citoid, они будут такими же ошибочными и глупыми, как и здесь. Folly Mox ( обсуждение ) 16:14, 3 октября 2024 (UTC) [ ответить ]

И это означало бы, что вики-данные, включенные в Википедию, будут того же уровня качества, что и вики. Аарон Лю ( обсуждение ) 17:13, 3 октября 2024 (UTC) [ ответить ]

Это совсем не следует. Wikidata со ссылкой, сгенерированной инструментом, будет иметь похожие ссылки, как те, которые сгенерированы этим инструментом, если редакторы, участвующие в этом, те же самые, и если последующая проверка будет такой же. Но поскольку Wikidata имеет, например, плохих ботов, создающих статьи или добавляющих проблемные ссылки, и не имеет того же уровня контроля вандализма, как Wikipedia (хотя и здесь слишком много ускользает), конечный результат заключается в том, что качество Wikidata слишком часто намного ниже качества Wikipedia. Fram ( talk ) 18:07, 3 октября 2024 (UTC) [ ответить ]

Элементы, включенные в вики, будут тщательно проверены так же, как и основная вики, и я не уверен, о каких проблемных вкладах ботов вы говорите. Аарон Лю ( обсуждение ) 20:12, 3 октября 2024 (UTC) [ ответить ]

Например, CJMbot[3]. Последние правки включают создание элемента об очень малоизвестном авторе 17 века[4], а затем неделю спустя чтение тех же элементов и ссылок на него. Затем появляется другой бот и удаляет дублирующие элементы, но добавляет дублирующие ссылки на более ранние элементы. Хорошо идет... Я заметил этого бота, потому что в John Cage он добавил вторую дату рождения[5], полученную из Museum Dhondt-Dhaenens. Полностью непроверяемо, музей существует, но что имеется в виду? Какая-то база данных, каталог, информация внутри музея? Результатом является то, что, например, в информационном поле Commons вот уже почти два года отображается правильная и неправильная дата рождения. Fram ( talk ) 07:56, 4 октября 2024 (UTC) [ reply ]

Похоже, что этот бот испортил бесчисленное количество элементов Wikidata, многие из них скрытно, некоторые крайне явно. Некоторые опасения были высказаны на его странице обсуждения, но, несмотря на заверения в том, что владелец бота рассмотрит это, по-видимому, ничего не было сделано, и никто не заметил огромного количества сбоев. Что еще раз иллюстрирует мне, что мы должны использовать Wikidata как можно реже и не доверять им, как достаточно хорошим для добавления контента в enwiki. См. [6], химическое соединение, которое благодаря этому боту также является человеком с датой рождения и т. д. Не одноразовое, см. [7][8][9][10]... Fram ( обсуждение ) 10:12, 4 октября 2024 (UTC) [ ответ ]

Хорошо, это проблематично. Если посмотреть на его запрос на разрешения бота, он берет базы данных CSV, предоставленные музеями, и пытается сопоставить их с людьми, отсюда и комментарии о том, что «это действительно была проблема в данных». Пока не было никаких обсуждений о том, как бот связывает людей с химическими соединениями. Надеюсь, на этот раз я начну обсуждение на странице обсуждения, кто-нибудь заметит.
Однако, когда такие данные будут включены в Википедию, я уверен, что люди заметят любые неверные данные, как это сделали вы, и исправят их. В разделе «Последние изменения» также есть много правок, которые отображаются как проверенные вручную, так что не похоже, что их контроль над вандализмом настолько низок. Аарон Лю ( обсуждение ) 13:54, 4 октября 2024 (UTC) [ ответ ]

Извините, что разочаровываю вас, но да, их контроль вандализма действительно слишком, очень низкий. Я все еще жду, когда кто-нибудь отменит хотя бы одну из 5 вандалистских правок, которые я добавил в закладки более 2 дней назад, а сегодня потребовалось почти 4 часа , чтобы кто-то понял, что "Succcca ahahhaha" (английское описание: "TUA MADRE STR")[11] — это неправильное английское название " Властелина колец" . Если даже такие громкие статьи и такой вопиющий вандализм требуют так много времени для отмены... (И да, это означает, что инфобокс Commons также показывал это в течение 4 часов). Fram ( talk ) 15:04, 4 октября 2024 (UTC) [ reply ]

Вы задумывались о том, что все, кто это видел, делают то же самое, что и вы, и подсчитывают, сколько времени потребуется кому-то другому, чтобы это исправить? Вам не приходило в голову исправлять вещи, а не пассивно мешать работе вики, чтобы донести свою точку зрения? 15:59, 4 октября 2024 (UTC) Thryduulf ( обсуждение ) 15:59, 4 октября 2024 (UTC) [ ответить ]

Да, не хватает. Я говорю, что не слишком мало. Аарон Лю ( обсуждение ) 16:29, 4 октября 2024 (UTC) [ ответить ]

"Да, просто введите название книги": где? после поля "заявлено в"? "Заявлено в" сопровождается длинным объяснением, которое даже на моем широком экране заканчивается на "в котором утверждается..." без возможности доступа к остальной части этого текста. Какой смысл в выпадающем списке после выбора "заявлено в", если ни одно из них здесь не имеет смысла. Но ладно, я добавлю название книги после "заявлено в". Ой, я хочу включить книгу, у которой нет записи в Викиданных: невозможно (или что еще означает розово-красное поле?). Ах да, согласно вашей странице справки, если вы хотите использовать ссылку, которая еще не существует как элемент в Викиданных, вам сначала нужно создать для нее элемент. Так просто! Если вам действительно не повезло, это ссылка с разными изданиями, и тогда вам нужно создать два новых элемента Викиданных, прежде чем вы сможете использовать ее в качестве источника. Хотите использовать газетную статью в качестве ссылки? Сначала создайте элемент Викиданных для газетной статьи. В Википедии я выбираю раскрывающийся список для типа ссылки, которую хочу добавить (показываю только то, что я действительно могу использовать, а не «человек»), он показывает мне, какие есть стандартные поля, и мне не нужно создавать что-то еще только для того, чтобы иметь возможность что-то получить. Попытка редактировать Викиданные — это просто бесконечный источник разочарования, которого я с радостью избегаю и вообще не хочу причинять другим. Тем не менее, приятно видеть, как количество человеческих правок в Викиданных постоянно искусственно раздувается, например, заявляя, что я сделал 951 правку в Викиданных вместо дюжины или около того. Ну что ж, я добавил в закладки 5 фрагментов вандализма в Викиданных, чтобы посмотреть, как быстро они будут отменены, разве этот визит в Викиданные не доставил мне удовольствия? Fram ( talk ) 12:21, 2 октября 2024 (UTC) [ reply ]

где? после поля «указано в»?

Да, не зря параметр называется "stated in". Это более интуитивно, чем значок книги на панели инструментов редактора исходного кода.

который даже на моем широкоэкранном экране заканчивается словами «в котором подается иск...» без какой-либо возможности доступа к остальной части этого текста

Он полностью отображает мой стандартный 1080p.

Какой смысл в раскрывающемся списке после выбора «указано в», если ни один из пунктов здесь не имеет смысла?

Это похоже на то, как для параметра "author-link" TemplateWizard — визуальный способ вставки шаблонов — автоматически предлагает каждую статью, которая начинается с того, что вы ввели. Однако я согласен, что, как и TemplateWizard, Wikidata не должен автоматически предлагать что-то, когда вы ничего не ввели.

сначала нужно создать для него предмет. Так просто!

Это действительно просто. Хотя кнопка «Создать новый элемент» в главном меню не так уж и заметна, шаги оттуда так же просты, как заполнение {{ cite book }} .
Справедливое замечание о необходимости заполнять его дважды для элемента издания.

он показывает мне, какие стандартные поля

Wikidata тоже. Каждый класс объектов (обозначаемый тем, что вы ввели для «экземпляра») имеет рекомендуемый набор утверждений, которые вам следует заполнить; они будут автоматически предложены, когда вы нажмете кнопку «добавить утверждение». Аарон Лю ( обсуждение ) 12:58, 2 октября 2024 (UTC) [ ответить ]

Вы, должно быть, смотрите на совершенно другую Wikidata (и Wikipedia), чем я. Если Visual Editor так же плох, как Wikidata, то это еще одна веская причина не использовать его. Я не получаю значок «книга», я получаю красивый текстовый раскрывающийся список с «цитировать книгу», «цитировать веб», «цитировать новости» и так далее. Стандартные поля: вы утверждаете, что «Wikidata также делает». Нет, не делает. После того, как я добавляю название книги после «указано в», ничего не происходит. Я не получаю, например, параметр pages или «chapter» или что-либо еще. Мне просто нужно знать, какие из них ожидаются. Fram ( talk ) 13:15, 2 октября 2024 (UTC) [ ответить ]

Если изучение того, как редактировать Википедию, может быть немного крутым, то изучение того, как использовать Викиданные, похоже на то, что вы врезаетесь в кирпичную стену. Особенно на мобильном устройстве, я нахожу это просто бесполезным. Я искренне считаю, что это было бы легко использовать, если бы вам пришлось писать команды SQL. Это не нападение на концепцию Викиданных, а скорее критика ее реализации. -- LCU Активно Неинтересно « @ » ° ∆t ° 14:49 , 2 октября 2024 (UTC) [ ответить ]

Вы можете в основном SQL CMD ( обсуждение ) 14:57, 2 октября 2024 (UTC) [ ответить ]

Но не совсем удобно для пользователя. -- LCU Активно Неинтересно « @ » ° ∆t ° 15:25 , 6 октября 2024 (UTC ) [ ответить ]

Это довольно хорошие моменты. Аарон Лю ( обсуждение ) 16:22, 2 октября 2024 (UTC) [ ответить ]

Я считаю, что гаджет Drag'n'drop включен по умолчанию, и это 22-секундное видео: https://www.youtube.com/watch?v=jP-qJIkjPf0 показывает, что импорт источника напрямую из Википедии в поле ссылок в Викиданных занимает всего пару секунд.

Добавление ссылки вручную, подобной той, которую я добавил здесь, занимает всего несколько шагов:

Нажмите кнопку «Изменить» для этого элемента (если вы еще не редактируете элемент).
Нажмите «+ добавить ссылку».
Выберите тип ссылки из выпадающего списка. Это может потребовать немного предварительных знаний (эквивалентно знанию того, какой из множества шаблонов цитирования использовать), но обычно это предполагает что-то разумное, например "URL ссылки".
Вставьте URL-адрес (или другую ссылочную информацию) в поле.
Нажмите «Опубликовать».

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

Метод перетаскивания даже не требует особых усилий. Просто прокрутите список Википедий в конце элемента Wikidata и нажмите [ref] для языка, из которого вы хотите скопировать ссылку. Откроется копия статьи Википедии. Найдите ссылку, которую вы хотите повторно использовать, и перетащите ее. Копирование и вставка с помощью скрипта не кажутся мне сложной задачей. WhatamIdoing ( talk ) 04:18, 3 октября 2024 (UTC) [ reply ]

Итак, я сначала добавляю источник в Википедию, а затем копирую его в Викиданные, чтобы иметь возможность, э-э, использовать его в Википедии? Как это облегчает жизнь? Видео использует Ботанический сад Мейбери Гелвина [12] и добавляет вторую ссылку на штат, в котором он находится, Иллинойс. Так что если бы у нас был инфобокс, сгенерированный из Викиданных, он бы показывал, что он находится в Иллинойсе, как и сейчас. Помимо того факта, что штат больше не упоминается в Викиданных по какой-то причине... Он был добавлен в 2016 году (с датой поиска 2012 год, нехорошо) и удален больше года назад. Хорошо, что мы не полагаемся на этот сайт. Учитывая, что ни один из 5 примеров вандализма, которые я записал вчера, не был отменен, похоже, что борьба с вандалами на Викиданных все еще проблематична. Fram ( talk ) 07:38, 3 октября 2024 (UTC) [ reply ]

Инструмент предназначен для легкого импорта существующих ссылок. Инструмент для создания новых ссылок все еще должен быть создан.
Кроме того, элемент Wikidata был изменен на округ Шампейн, что кажется правильным. Аарон Лю ( обсуждение ) 13:57, 3 октября 2024 (UTC) [ ответить ]

Как сказал Chipmunkdavis ниже, инструмент даже не виден простым смертным, это переключатель в настройках? И я не утверждал, что округ Шампейн неверен, но если бы инфобокс был заполнен Wikidata, он бы изменился с "Иллинойс" (хорошо, информативно для большинства людей, желательно) на "округ Шампейн" (неинформативно для большинства людей, конечно, без "Иллинойс"). Или, если быть еще точнее, он бы удалил "Иллинойс" из инфобокса, но даже не добавил бы "округ Шампейн" на его место, так как в Wikidata округ Шампейн даже не упоминается... США тоже не отображались бы, так как они "ссылаются" на enwiki. Единственные ссылки в статье - это ошибки 404. Это не пример, который я специально выбрал, его привел WhatamIdoing (хотя, полагаю, невольно), но он типичен для Wikidata, даже спустя 10+ лет. Даже если обратиться к базовой статье, скажем, Иллинойс[13], в ней едва ли надежные источники. Fram ( talk ) 14:57, 3 октября 2024 (UTC) [ reply ]

Да, гаджет не включен по умолчанию и его нужно переключить.
Наименование местностей в пределах их провинций — это соглашение о стиле, независимое от данных. Инфобоксы могли бы легко сделать два вызова Wikidata для местоположения. Аарон Лю ( обсуждение ) 15:29, 3 октября 2024 (UTC) [ ответить ]

Кажется, это не по умолчанию. Мой интерфейс Wikidata (включая Mabery Gelvin Botanical Garden (Q5477670)) имеет различные ссылки Wiki внизу страницы и без значков [ref]. CMD ( talk ) 09:30, 3 октября 2024 (UTC) [ reply ]

Еще одно ключевое различие (по моему опыту) между WP и WD: в WP признается, что существует кривая обучения и барьеры входа для редактирования, и практически в каждом разговоре с вице-президентом поднимается вопрос о том, как смягчить это; в WD разговоры, которые у меня были, кажутся показательными, что редакторы считают, что он полностью интуитивно понятен по своей сути — либо они не верят, что могут облегчить его для пользователей, либо что трудности пользователей — это их собственная вина (это всего лишь впечатление, которое у меня сложилось из разговоров — признаюсь, я очень прямолинейно сообщаю о проблемах с интерфейсом). Кроме того, когда меня спросили, редакторы WD, похоже, не были заинтересованы в проведении экспериментов по взаимодействию с пользователем или изучении существующих данных UX.

Опять же, это не для того, чтобы нападать на WD без причины. Я верю в основную цель проекта, но в этот момент я чувствую, что должен кричать в любом направлении, чтобы заставить их проснуться. SamuelRiv ( talk ) 14:58, 3 октября 2024 (UTC) [ ответить ]

Эта проблема определенно существует в Викиданных, но она существует и в Википедии. Амир Э. Ахарони ( обсуждение ) 16:06, 3 октября 2024 г. (UTC) [ ответ ]

Что касается работы, необходимой для обновления Wikidata: когда я в последний раз вносил изменения, что, по общему признанию, было давно, мне пришлось пройти долгий путь, создавая элементы Wikidata для каждого значения свойства, которое я добавлял к цитате, которая еще не существовала, что привело к созданию дополнительных элементов Wikidata для значений свойств изначально созданных элементов и т. д. Если это все еще так, то я был бы гораздо более склонен обновлять Wikidata, если бы существовал инструмент, помогающий генерировать все дерево каскадных элементов Wikidata для одобрения отправки. isaacl ( talk ) 16:35, 2 октября 2024 (UTC) [ ответить ]

Продолжение

Хотя первоначальная предпосылка этой ветки является сложной. Я думаю, стоит перегруппироваться, чтобы обсудить конкретно некоторые другие концепции и возможности в отношении интеграции Wikidata, которые другие подняли до сих пор. В частности, я думаю, что все согласны с тем, что ряд функций потенциально жизнеспособны, если они двунаправленно прозрачны, т. е. пользователям Wikipedia не нужно учиться использовать Wikidata или покидать Wikipedia, чтобы извлекать или обновлять информацию. Мы довольно хорошо знакомы с этим, частично являясь способом работы кратких описаний, я думаю? Remsense ‥ 论03:46, 3 октября 2024 (UTC) [ ответить ]

Я считаю, что Wikidata извлекает краткие описания en.wiki (и другие языки?) для соответствующего поля только тогда, когда их нет в Wikidata, и аналогично en.wiki показывает Wikidata только в том случае, если нет краткого описания en.wiki (если только оно уже не отключено?). Wikidata также извлекает координаты и другие элементы, но я не знаю, возвращается ли большая часть этого двунаправленно обратно в en.wiki. CMD ( обсуждение ) 14:07, 3 октября 2024 (UTC) [ ответ ]

Вы можете узнать больше об использовании Wikidata в английской Википедии на Wikipedia:Wikidata . Более 100 инфобоксов используют Wikidata в той или иной форме. Смотрите Category:Infobox templates using Wikidata .

Другое измерение, которое игнорируется в этом разговоре, заключается в том, что редакторы английской Википедии имели бы возможность поддерживать другие языковые издания, если бы мы поддерживали взаимодействие между Викиданными и Википедией; со всеми другими языковыми изданиями Википедии. Существуют обоснованные опасения по поводу сложности интерфейса (для всех проектов Вики) и стандартов источников, но давайте займемся ими вместо того, чтобы давать полную свободу действий, отвергая любые синергии. ~ 🦝 Shushugah (он/он • говорить ) 23:24, 3 октября 2024 (UTC) [ ответить ]

Я знаком с нашими инфобоксами, использующими Wikidata. Однако те варианты использования, о которых я знаю, не являются двунаправленно прозрачными, как упоминает Remsense, поскольку для их редактирования вам действительно нужно зайти в Wikidata. CMD ( talk ) 23:31, 3 октября 2024 (UTC) [ ответить ]

Меня, вероятно, снова обвинят в «пассивном нарушении вики, чтобы донести свою точку зрения»[14], но для тех, кто верит, что в Wikidata есть хорошо функционирующая система патрулирования вандалов, вот 5 случайных фрагментов вандализма, которые я добавил в закладки на прошлой неделе, сюрприз, ни один из них не был исправлен. Они разнообразны: от того, кто создал статью о не имеющем источника нарушении BLP о непримечательном человеке[15], до того, кто случайно испортил некоторые метки[16] (что также влияет, например, на Commons), от неясного, но очевидного[17] до редактора, испортившего 4 разные статьи без каких-либо проблем[18], и заканчивая редактором Википедии со статьей enwiki, который погиб, сражаясь за Украину против России, подвергшись откровенному вандализму и оскорблениям[19]. Fram ( обсуждение ) 09:47, 9 октября 2024 (UTC) [ ответить ]

Хочу сделать очень короткое отступление, которое я собирался опубликовать до того, как это породит подтему: я действительно считаю, что пассивное нарушение — это непростая задача. Folly Mox ( обсуждение ) 12:49, 9 октября 2024 (UTC)[ отвечать ]

Оставив в стороне подробности, будет ли полузащита всех предметов, используемых на enwp, достаточной для того, чтобы смягчить страхи вандализма? Это предотвратило бы все эти примеры выше. Это уже тот случай, когда часто используемые предметы полузащищены, но я не очень хорошо знаю культуру полузащиты на Wikidata, чтобы предсказать, является ли реалистичным более низкий порог. Кажется, стоит признать это возможным условием поддержки среди многолетних дебатов «это мусор» против «это полезно» здесь. —Рододендриты ^{говорят}\\ 12:04, 9 октября 2024 (UTC) [ ответить ]

Если бы мы включили такой контент в Wikidata, выборки контента, которые мы фактически используем, попали бы под ту же самую качественную антивандальную линзу, которая работала годами. Аарон Лю ( обсуждение ) 12:10, 9 октября 2024 (UTC) [ ответить ]

Вы имеете в виду "из" Wikidata? Иначе я не совсем понимаю ваш комментарий. И нет, в текущей системе это не сработает, вандализм в Wikidata, который влияет здесь, не обнаруживается так быстро, как вандализм здесь (в целом, у нас есть вандализм, который сохраняется месяцами или годами). Мы можем включить изменения Wikidata, например, в «последние изменения», но тогда мы получим такие вещи, как это (например, «Dm Antón Losada Diéguez (Q3393880); 12:37 . . Estevoaei (обсуждение | вклад) (‎Создано заявление: Property:P1344: Q12390563)», что вообще не имеет отношения к Enwiki. Что типично, большинство изменений Wikidata, которые мы видим, представляют собой либо интервики-ссылки, английские описания (которые мы в любом случае не отображаем), либо такие вещи, которые никогда не будут показаны здесь. Fram ( обсуждение ) 12:46, 9 октября 2024 (UTC) [ ответить ]

Да, я имел в виду, извините. Вы действительно не получаете RC-патрулирование, но я думаю, что главная причина, по которой вандализм WD не обнаруживается, заключается в том, что он не выставлен на видном месте. Любой вандализм, который избегает первоначального RC-патрулирования, будет иметь мало шансов быть обнаруженным, если только вандал не обладает высокомерием (сравните с тем, кто уничтожил чьи-то вклады) или люди на самом деле не читают статью, что они и делают, и поэтому они исправляют. Если мы увеличим значимость таких данных, фактически используя их, мы также существенно увеличим противодействие вандализму. Я почти не вижу никакого вандализма в вики-данных, которые мы уже включаем в статьи. Аарон Лю ( обсуждение ) 17:23, 9 октября 2024 (UTC) [ ответить ]

По крайней мере, некоторые из приведенных мной примеров уже повлияли, например, на Commons, и никто не обнаружил этого оттуда. Когда описания Wikidata были отображены на enwiki, вандализм этих описаний не был значительно или быстро обнаружен на enwiki и возвращен на Wikidata. Это обсуждение RfC от 2017 года дает много примеров того, что идет не так, когда enwiki полагается на Wikidata для своих данных, а также дает (ближе к концу) примеры заметного вандализма Wikidata, продолжавшегося часами и повлиявшего на ряд статей enwiki, во время этого RfC. Это происходит постоянно. Fram ( talk ) 18:02, 9 октября 2024 (UTC) [ ответить ]

Палата общин не очень заметна.

длящийся часами

Ну и что? Это не ненормально для вандализма, даже в Википедии. Количество правок, которые сводят на нет откат, означает, что многие случаи вандализма, вероятно, все еще существуют. Есть один известный боксер, я забыл его имя, чей инфобокс был откровенно испорчен, а его прозвище было изменено на что-то вроде «имбецил»; его отменили только через четыре дня. Посмотрите на special:Diff/1241738467 , который отключил службу запросов обратной связи на несколько месяцев. Игнорируя простое исправление защиты, означает ли это, что все RfC следует запускать вручную? Нет. Аарон Лю ( обсуждение ) 18:35, 9 октября 2024 (UTC) [ ответить ]

Я сомневаюсь, что вандализм, перемещающий Румынию в Молдавию, продлится на enwiki часами. Это не какой-то подлый вандализм, это вандализм на лицо. Что касается вандализма Wikidata, который увековечивается в инфобоксах на многих языках (и не замечается и не исправляется людьми, работающими на этих языках), то теперь (более часа назад) у нас есть невозможная дата рождения Йохана Кройффа , одного из лучших футболистов всех времен, и, следовательно, статья имеет некоторую важность. Вандализм Wikidata виден на каталонском[20], астурийском[21], галисийском[22], "ha"[23], норвежском[24], валлийском[25] и т. д. Использование enwiki в качестве пула редакторов для контроля вандализма на Wikidata (к чему сводится приведенное выше предложение) не кажется продуктивным путем вперед для enwiki. Fram ( обсуждение ) 12:35, 14 октября 2024 (UTC) [ ответить ]

Вандализм, перемещающий Румынию в Молдавию, также не продлится часами на Wikidata. Дата рождения Йохана была возвращена через 7 минут после вашего комментария, и, таким образом, неправильная дата рождения простояла всего 1 час и 15 минут. И нет, это не из-за вашего комментария, так как тот, кто вернул, является частым патрульным RC. Мы видим, что в Wikidata есть контрвандализм. Что касается того, что вики не замечают этого, не забывайте, что в Европе сейчас рабочий день, и не забывайте о боксере. Аарон Лю ( обсуждение ) 12:56, 14 октября 2024 (UTC) [ ответить ]

Нашел редактирование боксера, о котором я говорил: Special:Diff/1249398659 . Аарон Лю ( обсуждение ) 13:04, 14 октября 2024 (UTC) [ ответить ]

Если вы начнете отрицать реальность, вряд ли будет полезно продолжать эту дискуссию. И нет, я не верю в такие совпадения. Когда я опубликовал предыдущие 5 фрагментов вандализма (через неделю после того, как они произошли), один был удален через 2 часа[26], а другие были восстановлены через несколько минут после моего поста (и повторный случай длился всего 3 часа, ура, я полагаю[27]?). Тем временем редактор делает всего один вандализм, который просто происходит сразу после моего поста здесь, но не заботится о другом вопиющем вандализме, таком как 18 правок здесь[28], который снова вандализирует каталонскую Википедию[29] и даже испанскую Википедию[30]. Менее непонятные статьи? Stromae , великий бельгийский певец: предпочитаемое изображение, испорченное в Wikidata, поэтому инфобокс, например, в каталонской Википедии или норвежской[31] часами показывает неправильное изображение (о, точно, в рабочее время, когда никто не пользуется Википедией...), как и Commons[32]. Неважно, что с мая норвежская Википедия с гордостью показывает в верхней части своего инфобокса, благодаря Wikidata: «Gary Lineker Golden Bollocks».[33] Очевидно, что использование Wikidata для распространения ваших инфобоксов глупо и безрассудно, и только дает вандалам дополнительный выход для забав. Fram ( talk ) 14:36, 14 октября 2024 (UTC) [ reply ]

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

Процитирую себя выше: «Использование enwiki в качестве пула редакторов для контроля над вандализмом в Wikidata (к чему сводится вышеприведенное предложение) не кажется продуктивным путем для enwiki». Wikidata рекламируется как хорошее решение для мультивики-данных, некоторые языки поддались этому утверждению, и теперь enwiki должна контролировать их вандализм? Каждый здесь может свободно зайти в Wikidata и заняться патрулированием вандализма, никто вас не останавливает. Некоторые даже утверждают, что если кто-то вроде Thryduulf знает, что вандализм затрагивает Wikidata и другие языковые Wikipedia, и не прилагает никаких усилий для патрулирования, то на самом деле он «пассивно нарушает» ландшафт WMF, нет, знание мира. И как объяснили выше многие редакторы, нет, это не «за тот же объем усилий». Не говоря уже о, например, еще не упомянутой проблеме дублирования усилий по администрированию с блокировками, защитой, ... необходимой с обеих сторон. Fram ( обсуждение ) 15:13, 14 октября 2024 (UTC) [ ответить ]

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

только дает вандалам дополнительную возможность поиграться

Нет, он удаляет розетки. Раньше вандалы могли испортить инфобокс из статьи в любом издании Википедии. Теперь, когда они совершают вандализм, им приходится испортить все сразу и быстрее возвращать изменения. Упрощенно: раньше у вандалов было около 80 мест для вандализма. Теперь у них всего около 20. Здравый смысл подсказывает, что вандализм, замеченный в испанской Википедии, устраняется быстрее, чем в каталонской Википедии. Wikidata централизует информацию, и, таким образом, контроль вандализма может быть менее дублированным.

Поскольку вы столь едко перечисляете вандализм в Wikidata, который отражается на каталонском издании, почему бы вам вместо этого не взглянуть на этот гигантский список вандализма в каталонской Википедии? Аарон Лю ( обс .) 15:21, 14 октября 2024 (UTC) [ ответить ]

Эта математика не математика. Если есть версия статьи в 80 Википедиях, и все они берут свои инфобоксы из Викиданных, то все еще есть 80+1 мест для потенциального вандализма, потому что есть еще остальная часть статьи — это предложение не избавляет от этого. Вандал, который хочет написать «какашка» в верхней части статьи в каталонской Википедии, теперь может сделать это либо в каталонской Википедии, либо в Викиданных, а тот, кто хочет предотвратить появление вандализма в этой статье в каталонской Википедии, должен следить за обоими. Nikkimaria ( обсуждение ) 15:36, 14 октября 2024 (UTC) [ ответ ]

Ах, вот что это значит. Справедливое замечание. Но информация в информационном поле, возможно, (одна из?) самая важная часть статьи, и математика там будет математикой. Аарон Лю ( обсуждение ) 16:44, 14 октября 2024 (UTC) [ ответить ]

Нет, если вы разрешите переопределения. Nikkimaria ( обсуждение ) 16:50, 14 октября 2024 (UTC) [ ответить ]

Рабочий день в Европе? Но сегодня День Святой Ангадрисмы . -- Red rose64 🌹 ( обсуждение ) 14:53, 14 октября 2024 (UTC) [ ответить ]

Они берут выходные в христианские праздники в Европе? Аарон Лю ( обсуждение ) 15:07, 14 октября 2024 (UTC) [ ответить ]

Вы были в Кардиффе 1 марта или в Дублине 17 марта? -- Red rose64 🌹 ( обсуждение ) 17:36, 14 октября 2024 (UTC) [ ответить ]

Я знаю, что есть великие святые, но я не думаю, что Ангадрисма — это тот случай, когда какая-либо страна берет отпуск. Аарон Лю ( обсуждение ) 17:47, 14 октября 2024 (UTC) [ ответить ]

Можно считать это контролем над вандализмом в английской Википедии, который также является контролем над вандализмом в Викиданных и Википедии на других языках. Амир Э. Ахарони ( обсуждение ) 13:34, 14 октября 2024 (UTC) [ ответ ]

Существуют простые реализации, которые, возможно, необходимо будет закодировать на уровне WMF, которые мы могли бы реализовать для отслеживания кросс-вики-вандализма из наших списков наблюдения, что, по сути, и есть то, о чем вы говорите: любое изменение материала, включенного из викиданных (или Commons и т. д.) в статью из списка наблюдения, должно приводить к уведомлению в списке наблюдения WP этого редактора (или в аналогично реализованном инструменте).

Конечно, если, например, каждая ссылка в статье становится связанной с викиданными (а это выходит за рамки OP), это слишком много элементов для размещения в списке наблюдения, но я не знаю, имеет ли это значение, поскольку количество ожидаемых изменений в элементах WD и Commons так мало (предполагая, что можно следить за отдельными свойствами, а не за целыми элементами). Но автоматизация процесса не должна быть проблемой, и уведомление между вики уже в некоторой степени выполнимо.

Конечно, это не решает то, что было сказано ранее, что WD чертовски ужасно редактировать, что на самом деле можно исправить, если редакторы признают это. SamuelRiv ( обсуждение ) 15:50, 14 октября 2024 (UTC) [ ответить ]

Wikidata — это WMDE, а не WMF. WhatamIdoing ( обсуждение ) 23:57, 16 октября 2024 (UTC) [ ответить ]

Проверяемость не гарантирует включение

Я начал новое эссе, User:Cambalachero/Проверяемость не гарантирует включение , перечисляя случаи того, что не следует использовать в Википедии, даже если у нас есть ссылки на это. У вас есть другие идеи или лучшие способы объяснить текущие? Cambalachero ( обсуждение ) 18:35, 3 октября 2024 (UTC) [ ответить ]

Вы могли бы рассмотреть возможность добавления чего-то о контенте "в популярной культуре", как указано в WP:IPC . В частности, он, как правило, не подходит для включения без вторичного источника. DonIago ( talk ) 19:14, 3 октября 2024 (UTC) [ ответить ]

Я предполагаю, что вы знаете о WP:Onus и просто пишете пояснительное эссе для него. Аарон Лю ( обсуждение ) 20:10, 3 октября 2024 (UTC) [ ответить ]

Да, этот раздел говорит очень мало. Он говорит, что иногда контент может не быть добавлен, даже если его можно проверить, но не объясняет, когда. И я часто видел «это можно проверить!» или «это есть в источниках!» в качестве защиты для нескольких других контентов, которые сомнительны по другим причинам. Cambalachero ( talk ) 13:00, 4 октября 2024 (UTC) [ ответить ]

Чем это отличается от WP:NOT ? Thryduulf ( обсуждение ) 13:15, 4 октября 2024 (UTC) [ ответить ]

Что - нибудь о сплетнях о знаменитостях (и даже не о знаменитостях!) также может быть уместным. Capital S asha ~ talk 13:12 , 4 октября 2024 (UTC) [ ответить ]

WP:RECENTISM и WP:10YEARTEST в частности, могут быть источником вдохновения. -- LCU Активно Неинтересно « @ » ° ∆t ° 19:34 , 5 октября 2024 (UTC) [ ответить ]

Это следует из нашего первого столпа , что «Википедия — это энциклопедия», и из его следствия, что Википедия не является беспорядочным сбором информации . Джейсон Куинн ( обсуждение ) 12:00, 6 октября 2024 (UTC) [ ответить ]

Жизненно важные статьи, но для красных ссылок

Я месяцами пытаюсь найти статьи, которые нужно создать и из которых тема важна, но их нигде не видно. Поэтому я планирую создать проект. Я просто хочу представить идею здесь и посмотреть, сможете ли вы придумать улучшения. 23:36, 5 октября 2024 (UTC) [ ответить ]🍗TheNuggeteer🍗

Статьи Wikipedia:Most-wanted и/или Wikipedia:Requested , вероятно, то, что вы ищете. Chaotic Enby ( обсуждение · вклад ) 23:44, 5 октября 2024 (UTC) [ ответить ]

Может быть, Wikipedia: Статья с широкими понятиями ? Важные статьи, как правило, посвящены довольно широким темам, например «Закон» или «Животные». WhatamIdoing ( обсуждение ) 00:49, 6 октября 2024 (UTC) [ ответить ]

Также может быть Special:WantedPages , хотя было бы неплохо отфильтровать его по пространству имен. Wikipedia:Most-wanted articles не обновлялась полтора года и включает только #–A в качестве начального символа заголовка и не фильтрует ссылки из включений шаблонов. Было бы здорово, если бы кто-нибудь мог сделать новый запрос для этой страницы с исправленными этими двумя проблемами. Folly Mox ( обсуждение ) 01:20, 6 октября 2024 (UTC) [ ответ ]

Эта идея меня заинтересовала, но я подозреваю, что это либо станет дубликатом запрошенных статей, либо станет машиной для штамповки заготовок, не уделяя им того внимания, которое мы пытаемся привлечь. Большой уродливый инопланетянин ( обсуждение ) 00:52, 6 октября 2024 (UTC) [ ответить ]

Тогда, может быть, я смогу расширить усилия Тамбаянских Филиппин по расследованию зарубок до проекта, охватывающего всю Википедию. 07:36, 6 октября 2024 г. (UTC) [ ответить ]🍗TheNuggeteer🍗

Как насчет еженедельного списка из 20 статей, которые важны в следующем порядке:

Сельское хозяйство:

Еда

Искусство и язык:

Архитектура
Картины
Литература

Инженерное дело, технологии и математика

Инженерное дело
Технологии
Математика

История

Исторические события и деятели

Медиа и драма

Фильмы и кино
Видео
Фотографии

Музыка

Альбомы
Песни
Художники

Наука

Землетрясения и штормы
Животные
Ученые

Философия

Религия
Социальные науки
Тенденции

Спорт

Деятельность
Спортивные команды и мероприятия

Видеоигры и война

Войны
Видеоигры

Есть возражения? 07:43, 6 октября 2024 (UTC) [ ответить ]🍗TheNuggeteer🍗

Как вы их определяете? Извлекаете из соответствующих Wikiprojects? CMD ( talk ) 07:52, 6 октября 2024 (UTC) [ ответить ]

Что вы имеете в виду? 07:54, 6 октября 2024 (UTC) [ ответить ]🍗TheNuggeteer🍗

Как можно было бы определить список из 20 жизненно важных ссылок такого разнообразного масштаба? Как можно было бы изначально найти ссылки? CMD ( обсуждение ) 07:57, 6 октября 2024 (UTC) [ ответить ]

Извлекая информацию из соответствующих WikiProjects, как вы и просили. 07:58, 6 октября 2024 (UTC) [ ответить ]🍗TheNuggeteer🍗

Уже создан черновик: Пользователь:TheNuggeteer/sandbox2 08:03, 6 октября 2024 (UTC) [ ответить ]🍗TheNuggeteer🍗

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

Вам может быть интересно ознакомиться с тематической таксономией WMF по адресу :mw:ORES/Articletopic § Таксономия, хотя если вашим источником желаемых красных ссылок являются WikiProjects, вероятно, самая простая и эффективная таксономическая схема будет включать в себя простое извлечение одной красной ссылки из двадцати самых активных WikiProjects. Folly Mox ( обсуждение ) 17:08, 6 октября 2024 (UTC) [ ответ ]

Автоматически добавлять дату архива

URL-адрес архива имеет следующий формат: www.web.achive.org/web/yyyymmdd/https:www.placeholder.com

Дату можно ввести автоматически при указании URL, вместо того, чтобы добавлять дату. Кто я? / Поговорите со мной! / Что я сделал? 05:03, 7 октября 2024 (UTC) [ ответить ]

Я знаю, что это относится к Архиву Интернета, но я, кажется, помню, что другие службы архивации имеют другие форматы URL. Alt.Donald Albury ( обсуждение ) 12:00, 7 октября 2024 (UTC) [ ответить ]

Может быть, мы сможем обнаружить ссылку (начиная с web.archive.org), и если это интернет-архив, то формат может быть использован. Другие архивы не используются в значительной степени, поэтому это не сильно повлияет на процесс. Кто я? / Поговорите со мной! / Что я сделал? 12:43, 7 октября 2024 (UTC) [ ответить ]

Это отличная идея. Archive.org не использует yyyymmdd, а, например, 20031224105129. Мне вручную приходится вставлять тире в соответствующие точки 2003-12-24105129 и удалять временную метку, так что в итоге получается 2003-12-24. Кажется очень и очень вероятным, что бот уже выполняет эту задачу, но чтобы убедиться, вы можете спросить на Meta или WP:VPT . Polygnotus ( talk ) 23:08, 7 октября 2024 (UTC) [ ответить ]

Хорошо, для заполнения шаблона цитаты нужен только URL архива. Дату можно просто заполнить автоматически

Кто я? / Поговори со мной! / Что я натворил? 02:47, 8 октября 2024 (UTC) [ ответить ]

Ping @ GreenC для формата даты archive.org WhatamIdoing ( обсуждение ) 17:43, 9 октября 2024 (UTC) [ ответить ]

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

Шаблоны {{ cite }} буквально не могут добавлять отсутствующий параметр или изменять его, потому что шаблоны могут изменять только свой вывод (т. е. отображаемый HTML), но не изменять ввод викитекста. Я полагаю, что строго говоря, это было бы возможно с subst:-ing, но заставлять всех делать это с {{ cite }} не получится.
Редактор (программное обеспечение) определенно может сделать это автоматически, но я почти уверен, что разработчики (по понятным причинам) не захотят вводить специальную обработку для определенных шаблонов на определенной вики. Кроме того, хотя визуальный редактор может скрыть необходимое изменение викитекста за кулисами, для редактора исходного кода это должно означать автоматическое исправление отправленного викитекста постфактум, и, насколько мне известно, в настоящее время это не делается по какой-либо причине.
Поскольку {{ cite }} обычно помещается внутри <ref>...</ref>, mw:Extension:Cite, вероятно, мог бы справиться с этой задачей, но, опять же, удачи вам в попытках убедить разработчиков.

Так что, я думаю, что "заполнять |archive-date=из |archive-url= того, пока пользователь редактирует ", вероятно, будет трудно продать. Хотя есть и другие соображения.

Поскольку отсутствующий или несоответствующий |archive-date=автоматически помещает страницу в Category:CS1 ошибки: archive-url , нужно ли ворчать редакторам по этому поводу (и, особенно , помещать красные сообщения об ошибках на отображаемой странице)? Функциональность fixemptyarchive и fixdatemismatch WP:WAYBACKMEDIC может легко исправить эти ошибки, так почему бы не запустить бота чаще, чем сейчас, каждые 2-3 месяца ? Не обязательно с его полной функциональностью, просто для этой конкретной категории. Я действительно не понимаю, почему это не может происходить ежедневно.
И если выразить это более радикально: |archive-date=нужен ли вообще отдельный параметр , если его содержимое просто дублирует содержимое другого параметра? Поскольку код CS1 Lua уже имеет некоторую специальную обработку для archive.org , почему бы просто не добавить также получение даты из URL? CS1 предшествовал появлению Lua, поэтому, возможно, это было слишком неудобно для реализации со старым функционалом шаблона, и требование к редакторам всегда включать этот параметр было неизбежным. Однако теперь это, похоже, не так. Архивная информация, похоже, не нужна для COinS (которая в любом случае не будет взята напрямую из викитекста), и я не знаю других причин, по которым она должна быть обязательной для ссылок archive.org (или любых других, которые включают дату).

Вполне возможно, что я упускаю что-то важное относительно статус-кво , поэтому надеюсь, что такие люди, как монах @Trappist и @GreenC , смогут вмешаться.

Gamapamani ( обсуждение ) 12:29, 12 октября 2024 (UTC) [ ответить ]

Большое спасибо за доработку предложения. Второе соображение имеет большой смысл. Добавление URL архива всегда выполняется вручную, даже если вы используете автоматический инструмент, поэтому я думаю, что имеет смысл удалить параметр и, используя Lua, найти дату из URL. Кто я? / Поговорите со мной! / Что я сделал? 14:23, 12 октября 2024 (UTC) [ ответить ]

--> Категория: Ошибки CS1: archive-url в настоящее время содержит 33 страницы. Я очищаю его каждые 15 дней. Последний раз он очищался около 1 октября. Не большая проблема. -- Green C 19:47, 12 октября 2024 (UTC) [ ответить ]

Конечно, я не имел в виду, что его следует очищать чаще, поскольку дела обстоят прямо сейчас. Я пытался сказать, что если бы |archive-date=ворчание в редакторе и на результирующей странице было бы удалено для archive.org , категория, вероятно, заполнялась бы несколько быстрее, но бот все равно мог бы с этим справиться. Gamapamani ( talk ) 02:59, 13 октября 2024 (UTC) [ ответить ]

Фотографии публичных личностей в инфобоксах

Здравствуйте. Я хотел бы предложить проект, касающийся фотографий в информационных блоках статей, касающихся руководителей и других публичных лиц. Я считаю, что в Википедии слишком много непоследовательности: фотографии варьируются от официальных, профессиональных портретов до фотографий, сделанных на природе, например, на сцене или во время прямой трансляции. Чтобы сохранить последовательность и сделать статьи Википедии более презентабельными, я бы хотел, чтобы мы по возможности использовали портреты указанных лиц, чтобы избежать нарушения авторских прав. Большинство статей о политиках следуют этой тенденции; поэтому я хотел бы распространить ее на всех публичных лиц, особенно тех, кто занимает или занимал должности уровня C. Я с нетерпением жду ваших мыслей и, пожалуйста, дайте мне знать, следует ли перенести этот тип обсуждения в другое место. MikeM2011 ( обсуждение ) 21:29, 7 октября 2024 (UTC) [ ответить ]

Не уверен, что вы хотите сделать, чего еще не было. Причина такой непоследовательности в портретах в том, что у нас просто недостаточно фотографов, чтобы фотографировать людей в общественных местах (или получать согласие на фотографирование людей в частных местах). Аарон Лю ( обсуждение ) 21:36, 7 октября 2024 (UTC) [ ответить ]

В сети доступно множество профессиональных портретов, которые мы могли бы использовать. Я не уверен, почему мы не можем использовать их с надлежащими ссылками в соответствии с соглашением о добросовестном использовании. MikeM2011 ( talk ) 02:12, 10 октября 2024 (UTC) [ ответить ]

Вы не можете этого сделать, потому что любой человек должен иметь возможность бесплатно сфотографировать себя в общественном месте, и мы не можем позволить себе разрешить массовую загрузку, а затем получить кучу исков. Аарон Лю ( обсуждение ) 02:34, 10 октября 2024 (UTC) [ ответить ]

К сожалению, правила для несвободного контента не позволяют использовать добросовестное использование заявлений на фотографии живых людей, и эта политика слишком строга, чтобы даже рассматривать возможность ее изменения (я даже не уверен, можем ли мы это сделать, или было ли это решено Фондом Викимедиа). Это означает, что во многих вещах, связанных с изображениями, мы не используем или не делаем то, что хотели бы , а только то, что можем с ограниченными изображениями, доступными нам. Я подозреваю, что под «статьями о политиках» вы имеете в виду политиков США, и у нас много хороших изображений и даже портретов, потому что многие официальные сайты публикуют свой контент по бесплатным лицензиям. Но попробуйте написать о политиках из других мест, и вам, скорее всего, придется иметь дело с той же нехваткой хороших фотографий по многим другим темам. Cambalachero ( обсуждение ) 03:58, 10 октября 2024 (UTC) [ ответ ]

Я считаю, что это требование чисто локальное. Мы его создали, и мы можем его изменить. Но я разделяю ваш скептицизм по поводу того, что мы выберем его изменить. WhatamIdoing ( talk ) 18:13, 11 октября 2024 (UTC) [ ответить ]

foundation:Resolution:Licensing policy says An EDP may not allow the material when we can reasonably be expected who's a free licensed file for the same purpose, such as a case of a practical portraits of living famous people. Аномия ⚔ 20:39, 11 October 2024 (UTC) [ reply ]

Показывать хорошие статьи на главной странице

Порталы (например, физический портал ) показывают хорошие статьи, так почему бы не на главной странице? Electrou (ранее Susbush) ( обсуждение ) 09:39, 8 октября 2024 (UTC) [ ответ ]

Да. Новые хорошие статьи могут быть номинированы на DYK. Порталы — это не тот шаблон дизайна, с которым стоит сравнивать, учитывая их непопулярность, и большинство хороших статей, честно говоря, не стоят того, чтобы их демонстрировать больше, чем мы уже делаем через DYK. Remsense ‥ 论09:43, 8 октября 2024 (UTC) [ ответить ]

Строчные или заглавные буквы в заголовках записей в соответствии с их истинным написанием.

ПРЕДЛОЖЕНИЕ: заголовки статей в Википедии должны быть написаны точно так же, как они написаны на их языках. С заглавными или строчными буквами.
Это предложение для всех Википедий. Каждые несколько лет я возвращаюсь к теме .
Почему здесь: потому что это самая большая и влиятельная Википедия. Мнение самых опытных редакторов может сделать возможным глобальный переход от принудительного использования заглавных букв в качестве инициалов в каждой отдельной статье к истинному и правильному написанию на ее родном языке.
Не могли бы редакторы en.wikipedia рассмотреть:

Не допускается переключение на заглавную/прописную начальную букву без грамматической причины. Не допускается нарушение правильного написания слов.
Если не чувствителен к регистру (в соответствии с Викисловарями того же языка), то, по крайней мере, толерантен к регистру .
При любом написании в SearchBox обе инициалы (заглавные и строчные) приведут к записи, написанной правильно:
например , коричневый (цвет) , Коричневый (фамилия), Коричневый (разрешение неоднозначности) ^{гипотетические примеры:} BROWN (компания), Коричневый (роман)

Я знаю, насколько сложным будет этот проект:
технически (ср. WP:Соглашения об именовании#Строчная первая буква , Шаблон:строчная буква и множество обсуждений),
но в основном психологически.
Я думаю, что выбор заглавных букв для всех записей в первые дни разработки википедий был огромной ошибкой. Теперь это очень трудно исправить. Но никогда не поздно поступить правильно.
Спасибо за внимание, википедист (неизбежно чувствительный к регистру), Sarri.greek ( обсуждение ) 16:54, 9 октября 2024 (UTC) [ ответить ]

но разве вы не говорите «литовский» с заглавной буквы «Л» и, следовательно, «викинианец» с заглавной буквы «В»? Аарон Лю ( обс. ) 17:12, 9 октября 2024 (UTC) [ ответить ]

Конечно, M @ Aaron Liu : , пожалуйста, извините мое незнание английской грамматики и любые опечатки. В своих личных записях я предпочитаю использовать строчные буквы Sarri.greek ( talk ) 17:18, 9 октября 2024 (UTC)[ отвечать ]

@ Sarri.greek : если вы имеете в виду изменение поведения заголовков страниц таким образом, чтобы они стали чувствительными к регистру, делая, например, Brown и brown разными страницами, то я не понимаю, какие преимущества это даст? Что изменилось сейчас, что заставляет вас думать, что консенсусы, достигнутые в ходе многочисленных предыдущих обсуждений, на этот раз будут другими? Thryduulf ( talk ) 17:08, 9 октября 2024 (UTC) [ ответить ]
M @ Thryduulf : На данный момент страница для цвета называется Brown . Необъяснимая заглавная буква. Я думаю, что это должно быть brown со строчными буквами или brown (color) [полное название]. Спасибо за внимание. Sarri.greek ( talk ) 17:15, 9 октября 2024 (UTC) [ ответить ]
@ Sarri.greek : Это может быть связано с техническими ограничениями — заголовки статей, начинающиеся с буквы, должны начинаться с заглавной буквы. можно использовать для принудительного отображения первой буквы заголовка статьи в нижнем регистре (как на iPhone ), но это не меняет фактического заголовка страницы в программном обеспечении (IPhone). Вы же не можете серьезно предлагать спамить этим шаблоном то, что наверняка будет в семизначных числах статей, верно? — Jéské Couriano v^_^v ^темы^{критика} 17:57, 9 октября 2024 (UTC) [ ответить ]{{lowercase title}}
M @ Jéské Couriano : >> должно начинаться с заглавной буквы<< Почему? Это было решение WMF? Решение английской Википедии? Извините, но я не понимаю технических причин этого первоначального подхода (или любого технического вопроса) писать цвет «коричневый» с заглавной буквы, когда это изолированное слово (не в предложении, не в названии книги или эссе, а просто слово). Спасибо. Sarri.greek ( talk ) 18:09, 9 октября 2024 (UTC) [ ответить ]
@ Sarri.greek : Это решение MediaWiki (читай: ПО). Вам нужно поговорить с разработчиками. (То, что разработчики получают зарплату от WMF, не означает, что WMF приняла решение о том, как обращаться с заголовками статей, тем более, что это произошло задолго до существования WMF.) — Jéské Couriano v^_^v ^{темы критика} 18:36, 9 октября 2024 (UTC) [ ответить ]
Я пытаюсь понять, как это может быть полезно. Если у нас есть заголовки в предложениях, разве первое слово не должно быть все равно заглавным? Chaotic Enby ( talk · contribs ) 17:30, 9 октября 2024 (UTC) [ ответить ]
Я считаю, что это предложение прекратить писать наши заголовки с заглавной буквы. WhatamIdoing ( talk ) 17:48, 9 октября 2024 (UTC) [ ответить ]
Что сделало бы все это еще более непоследовательным, поскольку заголовки разделов, например, предположительно, будут оставаться в том же регистре. Chaotic Enby ( обсуждение · вклад ) 19:18, 9 октября 2024 (UTC) [ ответить ]
Я в целом придерживаюсь мнения, что чувствительность к регистру в Википедии была ошибкой (и в значительной степени не согласен с этим аспектом WP:DIFFCAPS , хотя я, конечно, следую ему). Подобно тому, почему все статьи начинаются с заглавной буквы, чувствительность к регистру имела некоторый смысл, если вы посмотрите на происхождение Вики в целом, где они автоматически связывали слова CamelCase без необходимости в дополнительном синтаксисе. Поскольку Mediawiki больше этого не делает, необходимость в ведущей заглавной букве в значительной степени исчезла. И причина, по которой она все еще есть, заключается, как я думаю, в понимании того, что усилия (программно/технически, обновления контента и просто все «привыкают» к изменениям) не будут стоить усилий. Хотя я предполагаю, что большая часть технических усилий будет направлена на то, чтобы сделать миграцию максимально гладкой для читателей, поскольку Викисловарь уже позволяет (или, по крайней мере, кажется, позволяет читателям и редакторам) фактически начальные строчные буквы (но чувствительны к регистру). Я не исследовал достаточно, чтобы точно знать, что я бы поддержал или выступил против. Skynxnex ( обсуждение ) 18:31, 9 октября 2024 (UTC) [ ответить ]

Новые шрифты

Я всегда хотел увидеть другие шрифты в Википедии (кроме Comic Sans MS, он такой плохой). Попробуйте добавить другие шрифты. Electrou (ранее Susbush) ( обсуждение ) 16:09, 11 октября 2024 (UTC) [ ответ ]

Добавьте это в ваш Special:MyPage/common.css :

body { font-family : "название семейства шрифтов" ; }

, конечно же, заменив часть между двойными кавычками на фактическое семейство шрифтов. Аарон Лю ( обсуждение ) 16:32, 11 октября 2024 (UTC) [ ответить ]

Ок. Electrou (ранее Susbush) ( обсуждение ) 16:54, 11 октября 2024 (UTC) [ ответить ]

Мне нужен шрифт Ubuntu, могу ли я получить код? Electrou (ранее Susbush) ( обсуждение ) 17:04, 11 октября 2024 (UTC) [ ответить ]

поддерживает ли он шрифт Ubuntu? Electrou (ранее Susbush) ( обсуждение ) 17:13, 11 октября 2024 (UTC) [ ответить ]

Это не работает (я пробовал шрифт Ubuntu) Electrou (ранее Susbush) ( обсуждение ) 17:17, 11 октября 2024 (UTC) [ ответ ]

@ Electrou , какой веб-браузер и операционную систему вы используете? WhatamIdoing ( обсуждение ) 18:56, 11 октября 2024 (UTC) [ ответить ]

Я использую последнюю версию Google Chrome и использую мобильное устройство (при необходимости использую версию для ПК) Electrou (ранее Susbush) ( обсуждение ) 20:30, 11 октября 2024 (UTC) [ ответить ]

Как предполагает Chaotic Enby, вы не можете отображать Википедию в любом шрифте, которого нет на используемом вами устройстве. Если вы откроете Google Chrome и зайдете в настройки/предпочтения, там есть пункт (на моем ноутбуке он находится в разделе «Внешний вид»), который говорит что-то вроде «Настроить шрифты». Он должен иметь раскрывающееся меню со списком всех шрифтов. Если «Ubuntu» нет в этом списке, то ваше устройство не может отображать этот шрифт. WhatamIdoing ( talk ) 20:43, 11 октября 2024 (UTC) [ ответить ]

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

body { font-family : "предпочтительный шрифт" , "запасной шрифт" , "запасной шрифт" ; }

Например, моя страница пользователя лучше всего просматривается в шрифте Josefin Sans, но также имеет ряд резервных шрифтов, поскольку он доступен не на всех устройствах. Chaotic Enby ( обсуждение · вклад ) 21:38, 11 октября 2024 (UTC) [ ответить ]

Теоретически, вы также можете сделать загрузку шрифтов автоматически. Однако я не думаю, что это сработает, поскольку MediaWiki:Common.css — это верхняя таблица стилей, и я не уверен, загружается ли таблица стилей пользователя индивидуально. Аарон Лю ( обсуждение ) 21:47, 11 октября 2024 (UTC)

@import url('https://fonts.googleapis.com/css2?family=Ubuntu:ital,wght@0,300;0,400;0,500;0,700;1,300;1,400;1,500;1,700&display=swap');

[ ответ ]

Вы можете загружать шрифты с других серверов, таких как сервер шрифтов Google или прокси-сервер toolforge для сервера шрифтов Google, если вы выберете. Обратите внимание, что информация о реферере страницы будет отправляться на сервер шрифтов всякий раз, когда загружается шрифт (обычно она кэшируется, поэтому загружается нечасто), поэтому некоторые люди опасаются делать это. Также обратите внимание, что зеркало toolforge не рекомендуется для общего использования. isaacl ( talk ) 22:00, 11 октября 2024 (UTC) [ ответить ]

Я установил шрифт, но он не отображается. Electrou (ранее Susbush) ( обсуждение ) 07:55, 12 октября 2024 (UTC) [ ответ ]

Вы установили его на свой мобильный телефон? Chaotic Enby ( обсуждение · вклад ) 20:36, 11 октября 2024 (UTC) [ ответить ]

Страницы для сохранения в автономном режиме

Было бы очень здорово иметь приложение, с помощью которого люди могли бы загружать или сохранять Википедию для офлайн-доступа. Таким образом, те, у кого нет доступа к Wi-Fi (как у меня), смогут легко исследовать и редактировать материалы. HippieGirl09 ( обсуждение ) 14:13, 12 октября 2024 (UTC) [ ответить ]

Посмотрите на вкладку «Инструменты» на странице статьи. В моей системе одним из вариантов является «Загрузить как PDF». Другой вариант — «Печатная версия». Вы можете использовать его для печати в файл. На самом деле, вы можете загрузить всю английскую Википедию, но вам понадобится много места для хранения. Однако вам нужно будет выполнять все правки онлайн. Дональд Олбери 18:58, 12 октября 2024 (UTC) Отредактировано 19:01, 12 октября 2024 (UTC) [ ответить ]

@HippieGirl09 Официальные приложения Wikipedia для Android и iOS позволяют сохранять отдельные статьи для чтения в автономном режиме. Если вы заинтересованы в том, чтобы вся Wikipedia была доступна в автономном режиме, то вам стоит попробовать Kiwix. the wub "?!" 22:35, 12 октября 2024 (UTC) [ ответить ]

Добавление личной истории просмотров страниц

Я думаю, было бы здорово иметь возможность просматривать историю статей, которые вы просматривали в прошлом в веб-версии Википедии (я думаю, что это может быть уже в версии приложения?). Я прохожу через множество кроличьих нор Wikilink и хотел бы иметь возможность видеть список всех статей, которые я прочитал. Возможно ли это дополнение к программному обеспечению Википедии? Cleebadee ( обсуждение ) 21:10, 12 октября 2024 (UTC) [ ответить ]

Я предлагаю использовать историю вашего браузера (что может означать поиск браузера с удобным способом поиска в вашей истории). Я думаю, что многие пользователи будут чувствовать себя некомфортно, если история чтения Википедии будет легко доступна любому человеку на сервере Википедии. (Информацию, конечно, можно определить из журналов веб-сервера, но это менее удобно для злоумышленников, чтобы воспользоваться ею.) isaacl ( talk ) 21:32, 12 октября 2024 (UTC) [ ответить ]

В качестве аналогии, моя местная библиотека использует программное обеспечение, в котором есть опция сохранения записи о книгах, которые я выдал, которая по умолчанию отключена. При установке по умолчанию запись о книге, которую я выдал, стирается, когда я возвращаю книгу. Таким образом, если государственное учреждение потребует запись о книгах, которые я выдал, а я оставил опцию не сохранять запись, у библиотеки не будет информации для передачи. Государственные учреждения и другие стороны не могут получить записи, которых не существует. Кстати, я могу быть параноиком, но я это заслужил. У меня есть копии двух отчетов ФБР обо мне (через Закон США о свободе информации), один длиной около 200 страниц, а другой — 22 страницы. Дональд Олбери 22:05, 12 октября 2024 (UTC) [ ответить ]

Вы говорите, что Википедия должна разрешить это как опцию? Кажется, это был бы хороший способ сделать это, не заставляя людей использовать это. Может быть, это может быть инструмент, который отключен по умолчанию? Cleebadee ( обсуждение ) 03:28, 13 октября 2024 (UTC) [ ответить ]

Я говорю, что одно из соображений относительно того, следует ли вести запись того, что вы просматривали в Википедии, заключается в том, что если запись существует, ее можно запросить в суд или взломать. Другое соображение заключается в том, что если таких записей не существует, то Фонду Викимедиа не нужно тратить время и деньги на ответы на запросы правительства о доступе к этим записям или сопротивление им. Если бы я мог высказаться по поводу того, иметь ли такую возможность, я бы выступил против. Я думаю, что пользователи заслуживают права читать в Википедии все, что они хотят, не беспокоясь о том, что кто-то заглядывает им через плечо. Мы не можем помешать кому-то следить за тем, что смотрит читатель со своей стороны, но мы можем сделать все возможное для сохранения конфиденциальности в Википедии. Дональд Олбери 13:54, 13 октября 2024 (UTC) [ ответить ]

Будет ли наличие записи в самой Википедии способствовать ее взлому проще, чем если она будет доступна косвенно через историю поисковой системы? Cleebadee ( обсуждение ) 14:31, 13 октября 2024 (UTC) [ ответить ]

Вы можете отфильтровать историю браузера по веб-сайтам. В худшем случае вы можете поискать "Википедию" в истории. Аарон Лю ( обс .) 22:11, 13 октября 2024 (UTC) [ ответить ]

Мне кажется, что использование гипотетической истории просмотров Википедии и поиск Википедии в истории поисковой системы — это простые вещи для злоумышленника. Поэтому я не понимаю, почему добавление истории Википедии облегчит задачу злоумышленникам. Им легче взломать Википедию по сравнению с поисковыми системами? Cleebadee ( talk ) 20:12, 14 октября 2024 (UTC) [ ответить ]

Если вы хотите, чтобы данные синхронизировались между устройствами, вам нужно будет загрузить информацию на серверы Википедии; между тем, история обычно не синхронизируется по умолчанию. Это также дополнительная сложность для программного обеспечения с очень небольшой выгодой. Аарон Лю ( обсуждение ) 20:49, 14 октября 2024 (UTC) [ ответить ]

Я считаю, что Zotero Connector имеет эту опцию, которую вы можете активировать для домена wikipedia. То есть, если вы заинтересованы в отслеживании истории вашей wikipedia (и других веб-сайтов и чтения, и источников для редактирования WP и общих исследований + написания) помимо просто истории вашего браузера, Zotero — это хорошая вещь, которую нужно иметь под рукой. SamuelRiv ( talk ) 22:23, 12 октября 2024 (UTC) [ ответить ]

Хорошо, я раньше не слышал об этом сайте. Я пользуюсь iPad, так что не думаю, что смогу им воспользоваться. Cleebadee ( talk ) 14:29, 13 октября 2024 (UTC) [ ответить ]

Предложение главной страницы Википедии

Перемещено из WP:VPT

Я думаю, что главная страница Википедии была бы более познавательной и с разделом загадок, пословиц, идиом, мудрых высказываний. Знаете, коллекция из многих языков вокруг, их происхождение, прошлые значения, реформы, нынешние значения, примеры их использования в истории (прошлое и настоящее), их буквальные значения, дословный перевод на английский и т. д. Я не знаю, у кого есть лучшие идеи? Пусть Википедия также будет забавным местом для посетителей и читателей, чтобы всегда узнавать больше. Я с нетерпением жду, чтобы увидеть это к началу следующего года и в других языковых вики. Любые и все вклады принимаются. elias_fdafs ( обсуждение ) 20:02, 13 октября 2024 (UTC) [ ответ ]

@ Элиас Форталеза де ла Фуэрса Санчес : Я перенес вашу идею в лабораторию идей здесь, это не техническая проблема. — ^{Обсуждение} xaosflux 20:09, 13 октября 2024 г. (UTC) [ ответ ]

Хотя это больше похоже на Викисловарь или Викицитатник, я думаю, что в общем случае может быть плодотворная дискуссия о демонстрации избранного контента из родственных проектов. Folly Mox ( обсуждение ) 20:32, 13 октября 2024 (UTC) [ ответ ]

О, боже, еще одно предложение по редизайну главной страницы. Удачи с этим . -- Red rose64 🌹 ( обсуждение ) 20:51, 13 октября 2024 (UTC) [ ответить ]

Дело в том, что «мудрое высказывание» одного человека — это « глубина » другого . Я не думаю, что размещение их на главной странице, особенно в специальном разделе, было бы действительно энциклопедичным. Однако, как говорит Фолли Мокс, более общая концепция демонстрации контента родственного проекта (этимология слова, цитата и т. д.) могла бы быть интересной! Chaotic Enby ( обсуждение · вклад ) 21:03, 13 октября 2024 (UTC) [ ответить ]

Как насчет небольшого раздела с тем, что представляет собой родственный проект? Он может циклически повторяться ежедневно. Cremastra ( обсуждение ) 22:57, 13 октября 2024 (UTC) [ ответить ]

Это вполне может сработать! Chaotic Enby ( обсуждение · вклад ) 17:22, 14 октября 2024 (UTC) [ ответить ]

Сложность заключается в том, чтобы перенести что-то из другого проекта, что, по-моему, невозможно.внеmw: Страшная трансклюзия. Cremastra ( обсуждение ) 17:25, 14 октября 2024 (UTC) [ ответить ]

Я полагаю, вы имеете в виду свнестрашная трансклюзия? jlwoodwa ( обсуждение ) 18:54, 14 октября 2024 (UTC) [ ответить ]

Исправлено. Спасибо, Cremastra ( обсуждение ) 18:58, 14 октября 2024 (UTC) [ ответить ]

Проблема с идиомами и пословицами в том, что они, как правило, региональные. Они широко используются в некоторых областях, но едва упоминаются или даже неизвестны в других. На каждого пользователя, который видит такой раздел и говорит: «О, вот откуда взялась эта пословица», у нас будет несколько, которые скажут: «Что, это была пословица? Никогда о ней не слышал». Кроме того, объяснить свою предысторию просто невозможно из-за ограниченного текста в полях главной страницы. Возможно, DYK может быть лучшим местом для показа этих статей на главной странице. Cambalachero ( talk ) 13:18, 15 октября 2024 (UTC) [ ответить ]

Статьи об идиомах были бы полезны, особенно если бы они упоминали подводные камни при переводе с одного языка на другой. Однако я не думаю, что главная страница — подходящее место. -- Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 13:58, 15 октября 2024 (UTC) [ ответить ]

Как я обсуждал в Wikipedia:Village pump (proposals)/Archive 213 § Proposal: Create quizzes on Wikipedia , я предлагаю найти людей, заинтересованных в создании такого типа контента, создать страницу проекта и регулярно производить контент по любому графику, который вы можете себе позволить. На основе этого опыта вы можете попытаться выяснить, как сделать процесс устойчивым. isaacl ( talk ) 15:59, 15 октября 2024 (UTC) [ ответить ]

Я думаю, что это можно было бы поместить в Portal:Current events , сбоку под полем "2024 at Wikipedia's sister projects". Там много места, и "____ дня" может быть забавным. WhatamIdoing ( talk ) 00:03, 17 октября 2024 (UTC) [ ответить ]