Обсуждение в Википедии:Руководство по стилю/Информационные поля

WT:MOSIBX
WT:МОСИБОКС
WT:МОСИНФОБОКС

Удаление бессмысленной болтовни

Я удалил следующее как бесполезный шум:

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

Чтобы пройти по нему:

«Общий подход» на самом деле не описывает это содержание.
"Рекомендуемый процесс создания шаблона инфобокса ..." не соответствует действительности, поскольку это не описывает реальный процесс, и не было достигнуто консенсуса относительно рекомендаций относительно того, что здесь находится. Раздел, который на самом деле предоставил рекомендуемый процесс создания такого шаблона, изначально не принадлежит странице MoS; это было бы вопросом для "Help:Infobox".
«просто для начала»: какая глупость.
"собрать как можно больше требований" - бессмысленная тарабарщина. Что будет "требованием" и как мы его "соберем"? Даже если бы это имело четкое значение, когда это не было бы "возможным"?
«Проверить базовый формат для нового шаблона» не имеет четкого значения и звучит как псевдожаргон из «Трона» .
«сначала как статическая таблица»: никто не разрабатывает шаблоны таким образом, и попытка сделать это будет в значительной степени контрпродуктивной, особенно учитывая то, как сегодня работает базовый код меташаблона для инфобоксов.
"затем, как только консенсус будет достигнут, перенести его в формат шаблона": Больше того же самого. Никому не нужно устанавливать консенсус перед использованием кода шаблона для кодирования шаблона.
"Шаблон следует пересмотреть перед его широким использованием в статьях на случай, если шаблон или определенные параметры потребуют модификации для минимизации повторной работы": Это действительно плохо разбирается из-за отсутствующих знаков препинания и некоторых других проблем с синтаксисом. Но на самом деле это просто совет "использовать предварительный просмотр и песочницу", который относится ко всей разработке шаблонов и не имеет ничего общего с MoS, включая MOS:INFOBOX . Это просто плохо повторенные основы из Help:Template .
«Если добавляются новые поля и параметры, статьи должны быть обновлены, чтобы отразить новые требования». Это явное заблуждение. Информационное поле, развернутое в статье, будет продолжать работать отлично; у него просто не будет дополнительных параметров (а «поля и параметры» избыточны). Статьи «должны» обновляться только в том случае, если существующий параметр был признан недействительным таким образом, что шаблон сломается, а мы этого не делаем. Старое имя параметра сохраняется как псевдоним параметра, или «устаревший» параметр (как |ethnicity=в ) просто делается так, чтобы вообще не выдавать никаких выходных данных.{{Infobox person}}
«Если параметры переименованы или удалены, многие статьи, скорее всего, не будут затронуты, поскольку посторонние параметры игнорируются». Это также фактически неверно. Если параметр был буквально переименован (т. е. изменен с одной строки на другую, без сохранения старого в качестве рабочего псевдонима), то, хотя оригинал стал бы «посторонним параметром», который был проигнорирован, это, конечно, повлияло бы на статью, удалив ранее отображаемую информацию из информационного поля. Опять же, мы этого не делаем; мы создаем псевдонимы для старых имен параметров на новые, чтобы этого не произошло. Если параметр полностью удален, произойдет то же самое (по намерению), но все равно повлияет на статью.

Буквально ни один кусочек этого беспорядка не имеет никакого отношения к этому руководству. —  SMcCandlish ☏ ¢ 😼 15:54, 7 января 2024 (UTC) [ ответить ]

Спасибо, руководство лучше без него. Вероятно, это было полезным руководством давно (оно было в руководстве 15 лет назад, я перестал за ним следить), но оно уже давно изжило себя. Ajpolino ( talk ) 23:10, 7 января 2024 (UTC) [ ответить ]

Согласен. Я поддерживаю удаление, поскольку язык не был полезен и, как указал SMcCandish, представлял собой запутанную чепуху. -- Ssilvers ( обсуждение ) 04:14, 8 января 2024 (UTC) [ ответ ]

MOS:КОЛЛАПС

На главной странице обсуждения MOS идет обсуждение того, поддерживает ли MOS:COLLAPSE использование свернувшихся инфобоксов, которые можно увидеть в Montacute House и Little Moreton Hall . Не стесняйтесь комментировать, если это вас интересует. ADHope ( обсуждение ) 11:42, 16 февраля 2024 (UTC) [ ответить ]

Статьи, связанные с городом, инфобоксы

Привет, я нашел несоответствия между городами по всему миру в Википедии, касающиеся формата изображений в информационном поле. См. статьи Нью-Йорк , Лондон , Ливерпуль и Чикаго против Ньюкасл-апон-Тайн , Праяградж и Хайдарабад . Какой формат изображений является принятым? Существует ли определенная норма или правило, определяющее формат изображений, которые следует размещать? Мое недавнее редактирование по Хайдарабаду было [1] отменено, сказав, что это непринятый формат. Какой формат является принятым? Поскольку я обнаружил, что во многих городах в Соединенных Штатах и во многих городах в самой Индии, таких как Нью-Дели и Мумбаи, используется другой формат. Также см. страницу обсуждения:[2] 456legend talk 00:58, 2 марта 2024 (UTC) [ ответить ]

Пожалуйста, примите участие в этом обсуждении, чтобы прийти к общему толкованию формата изображения инфобокса для статей, связанных с городом. Это было бы очень полезно. 456legend talk 01:06, 2 марта 2024 (UTC) [ ответить ]

Пожалуйста, любезно изложите свои взгляды и мнения 456legend talk 15:48, 6 марта 2024 (UTC) [ ответить ]

Этот вопрос ранее рассматривался в этом обсуждении (невероятно раздражающем для ссылки, потому что кому-то пришла в голову блестящая идея поместить скобки в заголовок раздела) : https://en.wikipedia.org/wiki/Wikipedia_talk:MOSINFOBOX/Wikipedia:Village_pump_(proposals)/Archive_203#Putting_captions_in_{{multiple_image}}_galleries_in_infobox. Формального консенсуса не было, но статус-кво ранее заключался в том, чтобы иметь одну подпись внизу, и это обсуждение точно не нашло согласия отойти от этого. Главная проблема — это пространство, которое в городских инфобоксах стоит очень дорого, учитывая, насколько они уже переполнены. Ваши альтернативы не того же размера, но вы все равно можете видеть, насколько больше места занимает альтернатива 2. ^{Обсуждение}Sdkb  03:55, 8 марта 2024 (UTC) [ ответить ]

@ Sdkb Извините, я не увидел ваш комментарий раньше. Тем не менее, разве мы не должны на самом деле достичь консенсуса в целях сохранения согласованности? 456legend talk 04:36, 12 марта 2024 (UTC) [ ответить ]

Согласованность хороша там, где она помогает нам применять лучшие практики и снижать нагрузку на обслуживание в ситуациях с функционально идентичными обстоятельствами. В этом случае, возможно, есть лучшая практика (на мой взгляд, альтернатива 1), но не большая нагрузка на обслуживание из-за непоследовательности (большая ее часть — это путаница/неопределенность, которую она создает относительно того, какой формат использовать), или функционально идентичные обстоятельства (например, в некоторых городах в их галереях гораздо больше узнаваемых достопримечательностей, и поэтому подписи нужно размещать рядом меньше). Sdkb  ^talk 04:53, 12 марта 2024 (UTC) [ ответить ]

Спасибо, что вы отметили эти аспекты. Также, учитывая вопросы, поднятые пользователем Huggums537 в архивном обсуждении, кажется разумным сделать вывод, что редакторам следует предоставить гибкость, как намекается в вашем заявлении, чтобы обязательно помочь в решении различных обстоятельств и потенциальной путаницы, обеспечивая более практичный и адаптивный подход. (Поскольку ваш пример имеет смысл и носит практический характер) 456legend talk 05:35, 12 марта 2024 (UTC) [ ответить ]

Я предпочитаю Альтернативу 1 по нескольким причинам. Во-первых, она занимает меньше места, что является преимуществом. Кроме того, она в целом выглядит более аккуратно. С точки зрения просмотра информации важно, чтобы информационные блоки оставались максимально компактными, при этом передавая все необходимые данные. Поэтому выбор Альтернативы 1 соответствует этому принципу. RWILD ✉ 13:29, 1 мая 2024 (UTC) [ ответить ]

WP:COLLAGE сообщает нам: Коллажи и монтажи — это отдельные изображения, иллюстрирующие несколько тесно связанных концепций, где перекрытие или аналогичное тщательное размещение компонентных изображений необходимо для иллюстрации точки зрения энциклопедическим способом [выделено мной]. Я бы сказал, что эти типы коллажей более декоративны и не достигают стандарта необходимости . Хорошее одно репрезентативное изображение, легко ассоциируемое с предметом (см. MOS:LEADIMAGE ), намного лучше, чем несколько изображений, особенно если они маленькие (размещены в ряд) и/или между ними недостаточно контраста. Слишком много привлекательности может отвлекать, а не приносить пользу. Кроме того, WP:INFOBOXPURPOSE сообщает нам, что экономичный инфобокс более эффективен, а большие инфобоксы могут иметь проблемы с доступом. В статье будет сказано, что Чарминар стал символом города . На этом основании это изображение в инфобоксе можно было бы квалифицировать как хорошее одно репрезентативное изображение . Cinderella157 ( обсуждение ) 00:30, 2 мая 2024 (UTC) [ ответить ]
Мне кажется, что целый город нуждается в нескольких разных фотографиях, чтобы быть представленным. ꧁ Zanahary ꧂ 06:39, 3 июля 2024 (UTC) [ ответить ]
Признаюсь, что считаю это обсуждение не совсем необходимым. Хотя я лично склоняюсь к краткости и экономии места «альтернативы 1», «альтернативная версия 2» не искажает и не дезинформирует наших читателей. Придумывание чего-то формального ради последовательности в вопросе сравнительно небольших вариаций довольно низко с точки зрения моего понимания того, что действительно нуждается в более формальном, общевики, принудительном консенсусе/правиле. Я просто не уверен, что мы должны выиграть от последовательности ради нее самой. Гортензии ( она/ее | обсуждение | правки ) 00:41, 2 мая 2024 (UTC) [ ответить ]
Альтернатива 1 на самом деле не представлена в порядке по часовой стрелке на мобильных разрешениях (которые составляют >60% нашей аудитории). Возможно, стоит это рассмотреть. :) Izno ( talk ) 02:48, 2 мая 2024 (UTC) [ ответить ]

MOS:FORCELINK

Запрещает ли MOS:FORCELINK ссылки на известные работы из инфобокса[[3]]? Я хотел бы получить разъяснения. Это кажется крайне либеральным толкованием, но если это правда, есть много биографических статей, которые ссылаются на списки наград/работ, которые нужно было бы удалить. Спасибо! Nemov ( talk ) 03:56, 3 марта 2024 (UTC) [ reply ]

Нет; MOS:FORCELINK применяется к ссылкам в тексте, а не к ссылкам, включенным вне текста, чтобы помочь читателям найти дополнительные статьи по теме: используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение. Текст должен быть понятен читателям, которые не могут следовать ссылкам.

Согласно этой интерпретации FORCELINK, нам не разрешается использовать шаблоны вроде Template:Antonio_Vivaldi или размещать списки «См. также» в конце статей. BilledMammal ( обсуждение ) 04:00, 3 марта 2024 (UTC) [ ответ ]

Правильно: его не следует использовать в IB. Посмотрите, почему у нас есть FORCELINK. - SchroCat ( обсуждение ) 15:46, 5 марта 2024 (UTC) [ ответить ]

Пока вы не найдете консенсуса относительно вашей интерпретации FORCELINK, вам действительно не следует менять статьи с таким обоснованием.[4] Немов ( обсуждение ) 15:58, 5 марта 2024 (UTC) [ ответить ]

Это не моя интерпретация. Это следование тому, что говорится в руководстве. Просто потому, что воины IB пытаются расширить его использование за пределы причин, по которым у нас изначально есть руководство, вы тот, кто должен пресекать нарушения. - SchroCat ( обсуждение ) 16:00, 5 марта 2024 (UTC) [ ответить ]

Я также попросил бы вас оставаться вежливыми. Очевидно, что ваша интерпретация отличается от интерпретации других редакторов, и вы не единственный арбитр того, «что говорится в руководстве». Вот почему разумно найти консенсус, прежде чем вносить изменения. Ссылки на работы использовались в биографиях в течение некоторого времени, в этой статье это было статус-кво до того, как вы представили это обоснование для изменения. Вот почему я задал вопрос здесь. Немов ( обсуждение ) 16:06, 5 марта 2024 (UTC) [ ответ ]

В том, что я сказал, нет ничего нецивилизованного, поэтому, пожалуйста, не пытайтесь играть в игры. Прочитайте руководство полностью, и вы поймете, почему у нас есть руководство, а также обратите внимание, что оно не дает никаких исключений для таких вещей, как IB. Сейчас не смотрю. - SchroCat ( обсуждение ) 16:13, 5 марта 2024 (UTC) [ ответить ]

В качестве примера, пожалуйста, посмотрите обзор этого инфобокса для Джеймса Эрла Джонса в качестве примера. Он включает чернила для работ и наград. Nemov ( talk ) 19:50, 5 марта 2024 (UTC) [ ответить ]
По мнению Джонса, «Работы», ссылающиеся на Джеймса Эрла Джонса на экране и сцене , и «Награды», ссылающиеся на Список наград и номинаций, полученных Джеймсом Эрлом Джонсом, нарушают дух MOS:INFOBOXPURPOSE :
Избегайте ссылок на разделы внутри статьи; оглавление предоставляет эту функцию.
Если раньше редакторы могли ссылаться на страницу James Earl Jones § Filmography или James Earl Jones § Awards and honors , то теперь ссылки находятся за пределами страницы. Однако ссылка не является сводкой ключевых фактов и не является кураторскими подборками. Подробнее от INFOBOXPURPOSE:
При рассмотрении любого аспекта дизайна информационного блока помните о его цели: обобщить (а не вытеснить) ключевые факты, представленные в статье.
— Багумба ( разговор ) 22:17, 5 марта 2024 г. (UTC) [ ответ ]

Целью Infobox должно быть другое обсуждение. Для Джонса я бы предложил сказать Список выступлений на экране и сцене , в то время как «Список наград» уже должен быть достаточно ясен. Я считаю, что полный список более нейтрален в отношении его достижений, чем вручную подобранный выбор. Поэтому я принимаю ссылку на список, концепцию, которая уже была частью {{ infobox classic composer }} , составленной в 2008 году и перемещенной в mainspace в марте 2010 года. -- Герда Арендт ( обсуждение ) 08:07, 6 марта 2024 (UTC) [ ответ ]

Назначение инфобокса должно быть предметом другого обсуждения : Не согласен. Поскольку мы говорим об инфобоксе, INFOBOXPURPOSE вполне уместно, особенно если некоторые интерпретируют, что NOFORCELINK не применяется к инфобоксам.— Багумба ( обсуждение ) 16:42, 6 марта 2024 (UTC) [ ответить ]

Сначала нам следует решить FORCELINK, поскольку это тема. Далее мы можем обсудить INFOBOXPURPOSE, если другие хотят получить разъяснения по поводу духа INFOBOXPURPOSE. Nemov ( talk ) 16:56, 6 марта 2024 (UTC) [ ответить ]

(ec) Я не понимаю, Багумба, извини. Возник вопрос: можно ли вернуть ссылку из инфобокса о композиторе на его работы, ссылаясь на FORCELINK, и ответ, который я прочитал (BilledMammal, Ли Виленски), — «нет», потому что руководство предназначено только для прозы. Вопрос о том, можно ли вернуть ссылку, ссылаясь на что-то еще, — это другой вопрос, который не следует путать с первым. — Герда Арендт ( обсуждение ) 16:58, 6 марта 2024 (UTC) [ ответить ]

Думаю, я тоже так думаю WP:NOTBURO . Вопрос для меня просто: «Принадлежит ли ссылка?» — Bagumba ( talk ) 17:30, 6 марта 2024 (UTC) [ ответить ]

NOFORCELINK применяется к прозе, а не к таблицам, инфобоксам и т. п. Ли Виленски ^{( обсуждение • вклад )} 22:19, 5 марта 2024 (UTC) [ ответить ]

Когда я просматриваю статью автора или исполнителя, я часто ищу список их работ. Вместо того, чтобы бегло просматривать статью и искать ссылку {{ Main }} или {{ further }} , я бы предпочел иметь такие ссылки в информационном поле. Это не значит, что эти ссылки следует исключить из текста статьи. -- Майкл Беднарек ( обсуждение ) 23:50, 5 марта 2024 (UTC) [ ответ ]

По крайней мере, два редактора (см. Vivaldi, и, пожалуйста, прокомментируйте там, чтобы оставить обсуждение в одном месте) все еще сомневаются, что это не относится к инфобоксам. Может быть, можно более четко указать в руководстве, что это относится только к прозе? -- Герда Арендт ( обсуждение ) 08:07, 6 марта 2024 (UTC) [ ответить ]

Как это может повлиять на инфобоксы, там говорится Используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение. Текст должен быть понятен читателям, которые не могут следовать ссылкам. Поскольку в инфобоксах нет прозы, мы не можем переписать информацию для чтения без требования. Смысл ссылки без принуждения в том, чтобы помешать людям писать сложную прозу и включать ссылку, которая объясняет всю информацию. Ли Виленски⁽^{обсуждение}^•^вклад⁾ 15:31, 6 марта 2024 (UTC) [ ответить ]

Конечно, это касается IB. Не выбирайте FORCELINK, а прочитайте его полностью. Руководство конкретно относится к тем, кто «может печатать статьи или читать офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок». Вы не можете просто игнорировать неудобную часть, с которой вы не хотите иметь дело. Эти ссылки не соответствуют цели IB и FORCELINK - SchroCat ( обсуждение ) 17:41, 6 марта 2024 (UTC) [ ответ ]

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

Более уместно то, подходит ли ссылка. В случае списка элементов, которые были бы слишком большими для инфобокса, это кажется подходящим решением. Это должно быть, как сказано выше, только для полных статей, а не для разделов. Ли Виленски ^{( обсуждение • вклад )} 19:53, 6 марта 2024 (UTC) [ ответить ]

Нет, это нарушает цель IB (изложенную в рекомендациях IB) и FORCELINK. Сколько рекомендаций вы хотите проигнорировать? IB появляется вверху страницы, на слишком видном месте и — в силу своего положения — несет много wp:weight , поэтому его нужно использовать правильно. Нахождение в IB выделяет поля, используемые над другой информацией в статье, и это поле — одно из тех, которые нарушают рекомендации. Поле типа «Работы: Полный список» говорит вам о чем именно? Все остальные поля в IB предоставляют фактоид. Поле даты рождения сообщает вам дату рождения человека; поле места рождения сообщает вам, где он родился. «Работы: Полный список» не сообщает вам никакой информации о предмете. Вы не можете игнорировать часть рекомендации, с которой не хотите иметь дело. Вы хотите использовать это поле? Найдите способ, который поддерживает как машинные считыватели, так и печатные версии — как четко указано в рекомендациях — а затем перепишите рекомендации. - SchroCat ( обсуждение ) 20:06, 6 марта 2024 (UTC) [ ответить ]

Похоже, что не так много поддержки в том, что FORCELINK запрещает ссылки на связанные статьи из инфобоксов, но я хочу прояснить MOS:INFOBOXPURPOSE, который был поднят Bagumba. Я открыл обсуждение ниже. Nemov ( обсуждение )

Никто не утверждает, что нельзя вставлять ссылки в IB. Это чучело. Также ложно утверждение, что FORCELINK не применяется. Никто не придумал способа, при котором «Работает: Полный список» будет иметь смысл для машинных читателей или на печатной странице. Опять же, если вы хотите использовать это поле, то найдите способ, который поддерживает офлайн-ридеров, переиздателей и печатные версии — как четко указано в руководстве — а затем перепишите руководство; в качестве альтернативы признайте, что нас не слишком волнуют офлайн-ридеры, переиздатели или печатные читатели, и внесите поправки в руководство независимо от них, но в настоящее время практика некоторых заключается в том, чтобы игнорировать руководство и делать то, что они хотят. - SchroCat ( обсуждение ) 22:13, 7 марта 2024 (UTC) [ ответить ]

Я только бегло прочитал это обсуждение, но если проблема в том, что «полная ссылка» вводит в заблуждение некоторых пользователей, то почему бы просто не заменить ее на «См. список в [[другой статье]]» или «См. список в разделе [[#Section]]»? Thryduulf ( обсуждение ) 13:59, 8 марта 2024 (UTC) [ ответ ]

MOS:INFOBOXPURPOSE и ссылки на соответствующие статьи

В обсуждении выше, касающемся FORCELINK, был поднят вопрос MOS:INFOBOXPURPOSE .

При рассмотрении любого аспекта дизайна инфобокса помните о цели инфобокса: суммировать (а не вытеснять) ключевые факты, которые появляются в статье. (То есть статья должна оставаться полной, а ее резюме инфобокса игнорироваться, с исключениями, указанными ниже.) Чем меньше информации она содержит, тем эффективнее она служит этой цели, позволяя читателям с первого взгляда идентифицировать ключевые факты. По необходимости некоторые инфобоксы содержат больше, чем просто несколько полей; однако, где это возможно, представляйте информацию в краткой форме и исключайте любой ненужный контент. Избегайте ссылок на разделы внутри статьи; оглавление обеспечивает эту функцию.

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

Разъяснение по этому вопросу будет полезным, поскольку он затрагивает множество статей. Спасибо! Nemov ( talk ) 21:14, 7 марта 2024 (UTC) [ ответить ]

Да

Это нарушает INFOBOXPURPOSE (и FORCELINK). Запись «Работы: Полный список» не « позволяет читателям с первого взгляда идентифицировать ключевые факты ». Ключевые факты доступны только при переходе на другую страницу, что противоречит цели и духу того, чем должен быть и что должен делать IB. - SchroCat ( обсуждение ) 22:48, 7 марта 2024 (UTC) [ ответить ]
Согласно вышесказанному. Также не имеет особого смысла утверждать, что [[Список работ|Список работ]] приемлем, когда [[#Работы|Список работ]] нет, согласно Багумбе. Nikkimaria ( обсуждение ) 01:32, 8 марта 2024 (UTC) [ ответ ]
Согласно вышеизложенному. Пожалуйста, сделайте инфобоксы краткими и включайте только ключевые факты. -- Ssilvers ( обсуждение ) 01:40, 8 марта 2024 (UTC) [ ответить ]
В качестве примера Бетховена, Ludwig van Beethoven § Music подробно описывает его музыкальную карьеру и включает ссылку на полный список. MOS:INFOBOXPURPOSE гласит:
Избегайте ссылок на разделы внутри статьи; оглавление предоставляет эту функцию.
Кажется, что это нарушает дух этого руководства — ссылаться напрямую за пределы страницы, когда мы не ссылаемся на связанный раздел, который находится на странице (и в TOC). Для читателя более элегантно оставаться на странице, сначала читать более высокоуровневый контент и получать более подробные ссылки за пределами страницы из тела.— Багумба ( обсуждение ) 04:25, 8 марта 2024 (UTC) [ ответить ]
По словам Никкимарии выше. Ajpolino ( обсуждение ) 17:01, 13 марта 2024 (UTC) [ ответить ]

Нет

Ссылка на связанную статью, которая включает в себя полный список наград/работ, не запрещена MOS:INFOBOXPURPOSE. Я не возражаю против того, как это используется в Бараке Обаме . Однако эти ссылки не должны использоваться для контента, включенного в статью. Избегайте ссылок на разделы внутри статьи; оглавление предоставляет эту функцию . Оставив в стороне аргумент политики, причина, по которой эти ссылки существуют во многих различных статьях, заключается в том, что они полезны. Нам следует избегать усложнения поиска информации для конечных пользователей. Спасибо! - Nemov ( обсуждение ) 21:28, 7 марта 2024 (UTC) [ ответить ]
Нет . У нас есть возможность устанавливать собственные указания, поэтому я гораздо меньше убежден аргументами о том, что говорится/не говорится в руководстве, чем аргументами о том, что оно должно быть сказано. Мы обсуждали этот вопрос не так давно в этой теме , на которую, как я думаю, еще никто не ссылался, но которую я бы рекомендовал участникам прочитать. Цитирую себя оттуда:
Я всегда находил ссылки на списки в инфобоксах немного странными, но они очень релевантны теме, и данные читателей показывают, что их наличие важно для того, чтобы помочь читателям найти список. Единственной альтернативой, похоже, является их исключение, что не кажется оптимальным.
Sdkb  ^talk 03:29, 8 марта 2024 (UTC) [ ответить ]
Как я уже писал выше, такие ссылки на статьи, перечисляющие работы/награды, спасают читателей, заинтересованных в том, чтобы бегло просмотреть статью в поисках ссылки {{ Main }} или {{ Further }} . Предложение Багумбы ниже о возможности использования боковой панели кажется мне разумным. -- Майкл Беднарек ( обсуждение ) 04:52, 8 марта 2024 (UTC) [ ответить ]
Чтобы было ясно, я не говорил, что это должно быть разрешено. Я только сказал, что функциональность боковой панели, похоже, фактически является тем, за что некоторые спорят. — Bagumba ( talk ) 05:50, 8 марта 2024 (UTC) [ ответить ]
Не должно быть . Эти ссылки, будь то на разделы той же статьи или на подстатью, явно полезны для читателей, поэтому их следует разрешить, а в некоторых случаях даже поощрять. Если это противоречит текущему руководству, то руководство необходимо изменить. Thryduulf ( talk ) 11:08, 8 марта 2024 (UTC) [ ответить ]
Нет - подобно тому, что сказал Немов, политика запрещает ссылки на разделы внутри статьи, потому что для этого есть оглавление . Оглавление для ссылок на другие статьи отсутствует, и хотя можно утверждать, что раздел «См. также» служит этой цели, но должен ли раздел в самом низу статьи содержать необходимые ссылки, к которым читатель может получить доступ? Я думаю, что нет. Полностью поддерживаю размещение ссылок на другие статьи в инфобоксах. MyCatIsAChonk ( обсуждение ) ( не я ) ( также не я ) ( все еще нет ) 11:52, 8 марта 2024 (UTC) [ ответить ]
Нет . Я считаю, что список композиций композитора является наиболее нейтральным и полным резюме его достижений, и ссылка на него в начале — как в инфобоксе, так и в лиде — должна быть желательной, избавляя читателя от необходимости прокручивать страницу до раздела «Музыка» или навигационного поля нижнего колонтитула. Я не вижу формулировки руководящих принципов, противоречащей представлению такой ссылки в инфобоксе, — FORCELINK говорит о предложениях, а не о данных инфобокса; читатель печатной версии не обязан переходить по ссылке, но может прочитать, что печатная версия говорит о музыке. Почему бы не предложить ссылку в качестве удобства (оценочным) 99% читателей, которые смогут щелкнуть? Есть интерес, см. здесь. — Герда Арендт ( обсуждение ) 21:04, 8 марта 2024 (UTC) [ ответить ]
Нет . Ключевые факты некоторых видов предметов будут неизменно включать вещи, которые могут стать слишком большими, чтобы включить их напрямую. Нет смысла опускать их произвольно, исходя из их размера: у Бетховена больше композиций, чем может поместиться непосредственно в информационном поле, что не уменьшает их важности для читателя. Альтернативой ссылке было бы какое-то сворачивание или усечение, и то и другое явно затрудняет удобство использования для следования произвольному стандарту. ― 08:54, 9 марта 2024 (UTC) [ ответить ]novov (t c)
Нет , но ссылки должны быть максимально информативными, см. это более раннее обсуждение по теме . «Работы: Список композиций», как в информационном поле в верхней части этого обсуждения, дает больше информации, чем что-то тривиальное вроде «Работы: Полный список», и поэтому должно быть предпочтительным. Gawaon ( обсуждение ) 10:37, 9 марта 2024 (UTC) [ ответ ]
Строка, которая была удалена (четыре раза), была "Список композиций". При желании ее можно было бы сделать более точной, например, для Вивальди: Списки опер , концертов и других композиций . -- Герда Арендт ( обсуждение ) 11:19, 9 марта 2024 (UTC) [ ответить ]
Ну, если это можно сделать более информативным, это, пожалуй, даже лучше. В предыдущем обсуждении, строка, полученная для Россини, была "Работы: Тридцать девять опер · Другие композиции" (с двумя разными ссылками). Мне немного грустно, что в самой статье о Россини нет инфобокса. Gawaon ( talk ) 11:41, 9 марта 2024 (UTC) [ ответить ]
Нет, и не должно быть. Список произведений композитора — это «ключевой факт» или то, что, конечно, будут искать многие читатели. Он помогает читателю либо предложить список произведений (если он достаточно короткий), либо ссылку на список. Мы не должны пытаться заставить читателя сначала прочитать «высококачественный контент», прежде чем попасть туда, куда он хочет попасть. Помогите читателю, дав ему быстрые ссылки туда, куда он хочет попасть, не пытайтесь контролировать читателя, заставляя его следовать линейному пути контента, это патерналистски. Levivic ( talk ) 08:01, 10 марта 2024 (UTC) [ ответить ]
Также на мобильных устройствах нет TOC. Если взять пример Бетховена , чтобы добраться до списка композиций (без использования ссылки в инфобоксе), мобильный читатель должен прокрутить вниз несколько экранов (мимо инфобокса, мимо всего лида), открыть заголовок уровня 2 «музыка», а затем нажать на ссылку в шапке. Ссылка в инфобоксе значительно упростила бы это. Кроме того, ссылка должна вести на подраздел статьи, если нет отдельной подстатьи. Разместите ссылку «список произведений» в одном и том же месте в каждой статье о человеке со списком произведений. Это хороший веб-дизайн: предсказуемый, простой, стандартный. Levivich ( talk ) 20:57, 10 марта 2024 (UTC) [ ответить ]

Нет, согласно Миру Новову. Как я писал в октябре прошлого года , в нем дается список произведений [композитора], чего статья не охватывает полностью, потому что весь список его произведений не может быть рассмотрен в статье. Это другая статья. Она не пытается охватить ту же тему, что и [статья композитора]. Раздел «произведения» лучше всего резюмировать как ссылку на более длинную статью о его произведениях. Это, как я показал выше, именно то, для чего предназначена эта строка в информационном поле. 🌺 Cremastra ( talk ) 14:32, 10 марта 2024 (UTC) [ ответить ]
Нет. Когда у кого-то есть статья-список о его творческих работах, это обычно указывает на две вещи: (1) что создание этих работ является значимой частью известности этого человека, и (2) что он был настолько плодовит, что было бы непрактично перечислять все его работы в инфобоксе. Прямая ссылка на статьи «список работ» — это компактный, стабильный и легкодоступный способ донести эту важную информацию до читателей. Напротив: попытка перечислить все (например) в дискографии альбомов Джонни Кэша в инфобоксе, очевидно, невыполнима, а упоминание только конкретных работ по названию исторически было питательной средой для хлама и войны правок. ModernDayTrilobite ( обсуждение • вклад ) 15:06, 13 марта 2024 (UTC) [ ответ ]
Нет MyCatIsAChonk и Gerda Arendt. Spy-cicle💥 ^{Talk ?} 20:35, 15 марта 2024 (UTC) [ ответить ]
INFOBOXPURPOSE запрещает ссылки на разделы, насколько я понял, в нем не упоминаются ссылки на другие статьи. Я бы поддержал продолжение запрета ссылок на разделы. FORCELINK говорит не использовать ссылки, если читатель должен использовать эту ссылку, чтобы понять ссылку (или это мое обобщенное прочтение). Я не вижу, чтобы кого-либо из читателей смущал " Список произведений " (или что-то подобное), поэтому я не вижу, чтобы он запрещал такие ссылки на другие статьи. -- LCU Активно Неинтересно « @ » ° ∆t ° 02:23 , 16 марта 2024 (UTC) [ ответить ]

Нейтральный

Меня устраивают обе версии. GoodDay ( обсуждение ) 04:43, 8 марта 2024 (UTC) [ ответить ]

Этот вопрос настолько плохо сформулирован, что не стоит подходить к нему или голосовать за него. Любая информация в статье «связана» — вот почему эта информация находится в IB. Это можно считать таковым, если (связанное) место рождения разрешено, потому что оно связано. Могу ли я посоветовать вам сначала правильно сформулировать вопрос? - SchroCat ( обсуждение ) 22:19, 7 марта 2024 (UTC) [ ответить ]

Мне понадобятся две версии одного и того же информационного поля биографии, чтобы полностью понять, о чем идет речь. GoodDay ( talk ) 03:50, 8 марта 2024 (UTC) [ ответить ]

Вы можете просмотреть инфобокс Джеймса Эрла Джонса в приведенном выше обсуждении, в котором есть ссылка на его «полные работы». Каждый пример имеет ссылку, ведущую на полный список наград/работ/и т. д. Содержание в этих связанных статьях слишком велико для основной статьи. Также добавлен пример инфобокса Людвига ван Бетховена, в котором есть ссылка на список его композиций. Nemov ( talk ) 03:56, 8 марта 2024 (UTC) [ ответить ]

Возможно, спор заключается в том, следует ли модифицировать MOS:INFOBOX , чтобы разрешить функциональность WP:SIDEBAR в инфобоксе. Если так, то спор идет не о том, что MOS:INFOBOXPURPOSE в настоящее время говорит, а о том, что он может быть модифицирован, чтобы сказать.— Bagumba ( talk ) 04:31, 8 марта 2024 (UTC) [ ответить ]

Как бы выглядело что-то подобное для биографии? Немов ( обсуждение ) 04:36, 8 марта 2024 (UTC) [ ответить ]

MOS:INFOBOXPURPOSE говорит, что ibx должен суммировать (а не вытеснять) ключевые факты, которые появляются в статье . Однако некоторые хотят разрешить навигационные ссылки, как в боковой панели, которая не суммирует напрямую заметные достижения для читателя ibx.— Bagumba ( обсуждение ) 05:46, 8 марта 2024 (UTC) [ ответить ]

Учитывая, что это использование противоречит INFOBOXPURPOSE в его нынешнем виде (даже разумные голоса «нет» больше касаются «полезности» ссылок, чем их соответствия рекомендациям), то переработка рекомендаций для приведения их в соответствие с предлагаемым использованием была бы единственным способом избежать нарушений, которые влечет за собой такое использование, и избежать любого будущего неправильного использования IB (на основе этого «тонкого конца клина» неправильного использования, подобного этому). Изменение основы INFOBOXPURPOSE, я думаю, потребует централизованно объявленного RFC на основе формулировки, которая разрешает такое использование, но которая избегает любых других проблем. Не должно быть слишком обременительным изменить формулировку в PURPOSE, чтобы отразить текущее использование, но это нужно сделать правильно, а не просто игнорировать. - SchroCat ( обсуждение ) 07:03, 8 марта 2024 (UTC) [ ответить ]

Заскочил сюда, потому что у меня было похожее обсуждение на Wikipedia talk:Manual of Style/Linking (см. здесь ). Кажется, что главный аргумент в пользу "Да" заключается в том, что формулировка INFOBOXPURPOSE предотвращает подобные ссылки. Где бы начался RfC для изменения формулировки этого руководства? MyCatIsAChonk ( talk ) ( не я ) ( также не я ) ( все еще нет ) 11:48, 8 марта 2024 (UTC) [ ответить ]

Давайте посмотрим, чем закончится обсуждение. Учитывая, сколько статей это затрагивает, нам понадобится довольно четкий консенсус, чтобы сказать, что эти ссылки нарушают цель INFOBOX. Nemov ( talk ) 13:04, 8 марта 2024 (UTC) [ ответить ]

Кажется, что главный аргумент «за» заключается в том, что формулировка INFOBOXPURPOSE препятствует такого рода ссылкам : Но именно так и был сформулирован вопрос ( Запрещает ли MOS:INFOBOXPURPOSE... ). Это не был открытый вопрос «хорошая ли это идея...» — Bagumba ( обсуждение ) 13:12, 8 марта 2024 (UTC) [ ответ ]

Учитывая, что большинство разумных голосов «нет», которые не спрятали голову в песок, признают, что текущая практика не соответствует формулировке (« менее убеждены аргументами о том, что говорится/не говорится в руководстве, чем аргументами о том, что оно должно быть сказано », « Если это противоречит текущему руководству, то руководство необходимо изменить » и т. д.), они также больше склоняются к поддержке изменения формулировки (для чего нужен RfC), чем текущая позиция, которая больше склоняется к изменению формулировки. Те, кто игнорируют проблему, просто не читают руководство полностью или игнорируют те части, которые они не хотят признавать. Это можно было бы сделать правильно — это не та насущная проблема, которую нужно решать немедленно. Я подозреваю, что RfC, поддерживающий изменение формулировки, был бы хорошо поддержан, но, учитывая, что это меняет цель IB , это не то, что можно сделать наполовину, прокравшись через то, в чем другие могут захотеть принять участие. - SchroCat ( обсуждение ) 16:09, 8 марта 2024 (UTC) [ ответить ]

Подготовка к изменению MOS:INFOBOX

Учитывая, что за последние два дня было добавлено еще четыре голоса "нет", я считаю целесообразным подготовить RfC для изменения формулировок некоторых разделов в MOS:INFOBOX . Подводя итог аргументам: ссылки на "списки произведений/альбомов/опер/песен/другое" в инфобоксах не нарушают MOS:INFOBOXPURPOSE , поскольку они не являются ссылками на разделы внутри статьи и являются ключевыми фактами, к которым читатели могут захотеть получить доступ в начале статьи. Кроме того, эти ссылки не нарушают MOS:FORCELINK , поскольку FORCELINK имеет дело с предложениями, а инфобоксы не являются частью текста.

Вот предложения, которые я бы выдвинул в запросе предложений (RfC), и, пожалуйста, внесите изменения, дополнения или комментарии, которые, по вашему мнению, необходимы, до открытия запроса предложений (RfC):

Предложение A: Изменить первый абзац MOS:INFOBOXPURPOSE следующим образом: «Ссылки на другие статьи разрешены, но должны быть информативными: см. раздел ниже Ссылки на другие статьи».
Предложение B: Создать подраздел в разделе «Принципы дизайна» под названием «Ссылки на другие статьи» со следующим текстом: «Ссылки на другие соответствующие статьи, такие как списки произведений, могут быть использованы, но они должны быть максимально информативными (например, « Тридцать девять опер ⋅ Другие композиции » предпочтительнее, чем просто « Полный список »). Как и другие параметры информационного поля, ссылка также должна отображаться в тексте статьи».

- MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 13:25, 10 марта 2024 (UTC) [ ответить ]

Я не уверен, что RFC вообще необходим. Эти ссылки существуют уже довольно давно и без каких-либо инцидентов. Я поднял этот вопрос здесь, поскольку это было относительно новое возражение. Если будут внесены изменения, то бремя минималистов инфобоксов ляжет на плечи минималистов по изменению INFOBOXPURPOSE, чтобы прямо запретить ссылки такого типа. Однако, похоже, поддержка внесения этого изменения очень мала. - Nemov ( обсуждение ) 13:41, 10 марта 2024 (UTC) [ ответить ]

@ Nemov , я чувствую необходимость инициировать это из-за сильного сопротивления некоторых в Wikipedia:WikiProject Classical music . Просто посмотрите на Россини: многочисленные возражения против наличия там инфобокса, несмотря на наше собственное обсуждение здесь. Или посмотрите на Козиму Вагнер: это обсуждение быстро стало довольно неприятным. Были даже сравнения с нацистами ! Я считаю, что изменение политики — единственный способ по-настоящему стандартизировать IB во всех статьях, особенно для композиторов. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 14:00, 10 марта 2024 (UTC) [ ответить ]

(ec) Учитывая, что аргумент 4 оппонентов соответствует текущей формулировке MOS:INFOBOXPURPOSE, я согласен, что может потребоваться более широкое обсуждение. -- Майкл Беднарек ( обсуждение ) 14:04, 10 марта 2024 (UTC) [ ответить ]

Я согласен, что такой RFC может быть необходим (как тот, кто придумал «тридцать девять опер» в качестве канала, я бы поддержал B), но, пожалуйста, давайте не будем обсуждать, нужны ли нам вообще инфобоксы, иначе возможность небольшого улучшения будет упущена из-за разделения по этому более крупному вопросу, и над нами также будут нависать WP:ARBINFOBOX и WP:ARBINFOBOX2 . NebY ( обсуждение ) 15:54, 10 марта 2024 (UTC) [ ответить ]

Если у человека еще не было отдельного списка работ, но был развернутый список, встроенный в его биографию, также кажется непоследовательным, почему мы разрешаем ссылку на другую страницу, но не ссылку на похожий контент на той же странице. Поэтому для меня вопрос заключается в том, подходит ли ссылка на любой список, как внутренний, так и внешний по отношению к биографии.— Bagumba ( talk ) 14:51, 10 марта 2024 (UTC) [ ответить ]

Я согласен с Bagumba. Если список слишком сложен и/или обширен для того, чтобы суммировать его в инфобоксе, на него должна быть ссылка из инфобокса, независимо от того, является ли это разделом той же статьи или отдельной статьей. Это одинаково ценно для читателей в обоих местах. Thryduulf ( talk ) 14:57, 10 марта 2024 (UTC) [ ответить ]

Если список слишком сложен и/или обширен, чтобы суммировать его в инфобоксе... : Вот тут я пока не уверен, что нужна ссылка. Неизменно, в приличном лиде уже упоминаются избранные работы, но это ни в коем случае не исчерпывающий список. Если можно принять редакционное решение о том, какие работы следует выделить в прозе лида, почему нельзя аналогичным образом определить, какие работы следует выделить в инфобоксе, предоставив читателям быстрый обзор ключевых фактов, которые являются целью инфобокса? — Bagumba ( talk ) 15:11, 10 марта 2024 (UTC) [ ответить ]

@ Bagumba , сложность размещения известных произведений (как в статье Пабло Пикассо ) в информационном поле заключается в том, что это а) создает большой беспорядок в поле (просто посмотрите, какой длинный у Пикассо) и б) не работает для известных произведений с общими названиями. По теме пункта б, возьмем, к примеру, Бетховена: некоторые из его самых известных произведений — это Симфония № 5 и № 9, Концерт для фортепиано № 5, многие из его поздних струнных квартетов, его опера «Фиделио», много-много фортепианных сонат (включая очень известный «Лунный свет »), «К Элизе» и т. д. и т. п. Я хочу сказать, что перечисление произведений не всегда работает, и особенно это не работает для композиторов. Вот почему многие обсуждения, связанные с этим, вытекают из статей о композиторах: перечисление произведений не работает для таких монументальных и сложных фигур. MyCatIsAChonk ( разговор ) ( не я ) ( тоже не я ) ( все еще нет ) 23:42, 10 марта 2024 (UTC) [ ответить ]

Перечисление работ не работает для таких монументальных и сложных фигур : Но приличная статья уже принимает такие редакционные решения относительно того, какие работы следует упомянуть в прозе ведущего. — Багумба ( обсуждение ) 06:38, 12 марта 2024 (UTC) [ ответить ]

@ Bagumba , представьте себе лиды для статей о Малере и Бетховене. Если бы у нас было предложение для их самых известных произведений, составленное как в первом абзаце лида Сергея Прокофьева , они бы выглядели так:

- Среди произведений Бетховена есть такие широко известные произведения, как Пятая симфония , Девятая симфония и Пятый фортепианный концерт .

- Среди произведений Малера есть такие широко известные произведения, как Пятая симфония , Девятая симфония и Вторая симфония .

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

Вот почему нам нужно использовать параметр «Работы» в инфобоксе: предоставление быстрого доступа к списку работ, который гораздо более подробен, чем лид, дает читателю ясность, не путая названия работ. Но даже в этом случае посмотрите на некоторые композиторские FA в том виде, в котором они есть: работы Малера даже не упоминаются до абзаца 3 лида, и указаны только три; или посмотрите Рихарда Вагнера , чей цикл «Кольцо Нибелунга» является единственным произведением, упомянутым в лиде, помимо «Мейстерзингеров» ; или даже Густава Хольста , который говорит только о «Планетах» и игнорирует его другие работы. Все три из этих композиторов являются FA, и тем не менее их лиды не упоминают многие из своих работ. Нам нужны инфобоксы в этих статьях, чтобы обеспечить лучший доступ к списку композиций, чтобы читателям не приходилось щелкать, чтобы найти что-то, что должно быть очевидно с самого начала. MyCatIsAChonk ( разговор ) ( не я ) ( тоже не я ) ( все еще нет ) 10:48, 12 марта 2024 (UTC) [ ответить ]

Как кто-то указал выше, разве не для этого предназначено оглавление? Если есть желание, я бы поддержал отдельный вопрос (возможно, отдельный RfC, работающий в то же время), который предоставит новую формулировку, которая специально позволяет это. Если закрыть глаза на мелкие пункты, это станет большей проблемой позже, так что это можно сделать правильно сейчас, чтобы все было правильно. - SchroCat ( обсуждение ) 18:02, 10 марта 2024 (UTC) [ ответить ]

Разве не для этого предназначено оглавление? Зачем читателю искать оглавление и переходить по ссылке на то, что может быть или не быть интуитивно названным разделом, когда он может просто перейти по ссылке прямо туда, куда он в данный момент смотрит, особенно когда именно там находится информация (или ссылка на нее) в других статьях, и нет никаких указаний на то, что ему нужно это делать? Thryduulf ( обсуждение ) 18:10, 10 марта 2024 (UTC) [ ответить ]

Возьмем эту линию аргументации с Mycatisachonk, который использовал ее для поддержки своего голоса «нет». Учитывая, что это специально запрещено правилами, я не уверен, почему сдержанность в том, чтобы открыть это для комментариев сообщества. - SchroCat ( обсуждение ) 19:37, 10 марта 2024 (UTC) [ ответить ]

Эти вопросы кажутся подходящими для рассмотрения пункта ЦЕЛЬ, хотя как только он будет открыт, есть большая вероятность, что более широкая читательская аудитория может полностью не согласиться с изменением цели, поэтому вы можете подумать о включении Варианта 3 не изменять раздел (и, следовательно, не разрешать эти ссылки). Я подозреваю, что он получит очень мало !голосов, но его следует включить - чтобы избежать свершившегося факта , если не чего-то еще.
Если вы открываете RFC по этому поводу, выборочный подход FORCELINK должен быть рассмотрен для решения той части руководства, которая конкретно относится к тому, чтобы не ссылаться на части, которые бесполезны в то время, когда «Текст должен быть понятен читателям, которые не могут переходить по ссылкам. Пользователи могут распечатывать статьи или читать их офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок»: «Работы: Список работ» является нарушением руководящих принципов в их нынешнем виде. Наличие второго RFC, работающего одновременно с первым, было бы наиболее эффективным способом решения этого конфликта — это, безусловно, лучше, чем игнорировать проблему или притворяться, что ее нет. - SchroCat ( обсуждение ) 17:57, 10 марта 2024 (UTC) [ ответить ]
«Работы: Список работ» — это нарушение правил , которое можно легко устранить, заменив «Список работ» информативной фразой, например «См. Список работ Баха», см. раздел #Композиции» или аналогичной. Для этого не требуется RFC. Thryduulf ( обсуждение ) 18:12, 10 марта 2024 (UTC) [ ответить ]
Опять же, я не уверен, почему есть противники открытия доступа к нему для сообщества. «Работы: см. список работ Баха» по-прежнему является нарушением правил в их нынешнем виде . Возможно, для разнообразия это также получит более широкое участие и прочный консенсус. - SchroCat ( обсуждение ) 19:37, 10 марта 2024 (UTC) [ ответить ]
Я не против RFC, просто не думаю, что это необходимо. Thryduulf ( обсуждение ) 19:49, 11 марта 2024 (UTC) [ ответить ]
@ Thryduulf , как я уже сказал Немову выше, я чувствую необходимость инициировать это из-за сильного сопротивления некоторых в Wikipedia:WikiProject Classical music . Реализация «См. список произведений Баха» — отличная идея, которую я бы с удовольствием просто воплотил в жизнь, но в сообществе WPClassical существует сильное противодействие этой идее. Вот почему в основном нужен RfC — изменить руководящие принципы и официально разрешить использовать этот параметр по назначению. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 20:50, 11 марта 2024 (UTC) [ ответить ]
Я не возражаю. Я бы возражал против варианта 3, как он сформулирован выше. Это обсуждение решило главный вопрос, INFOBOXPURPUSE не запрещает эти ссылки конкретно. Этот RFC просто представляет предложение, которое дает некоторые рекомендации о том, как сделать эти ссылки более понятными. Nemov ( talk ) 21:13, 11 марта 2024 (UTC) [ ответить ]

Следующие шаги

Это обсуждение было проведено на WP:VPP , WT:BIOG и WT:BLP , поэтому этот вопрос был открыт для более широкого сообщества. Пока что нет единого мнения о том, что эти ссылки запрещают INFOBOXPURPOSE. Похоже, что эти ссылки поддерживаются сообществом, но, возможно, в будущем RFC можно будет получить разъяснения относительно их конкретного использования. MyCatIsAChonk , вы хотите продолжить? Вы можете использовать village pump для воркшопа по языку, если считаете, что он требует дополнительной работы. Nemov ( talk ) 14:19, 15 марта 2024 (UTC) [ ответить ]

Спасибо за распространение информации и обеспечение осведомленности людей об обсуждении. Я разместил сообщение на деревенской колонке для отзывов о формулировках предложений, поскольку обсуждение здесь в основном касалось достоинств RfC. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 18:15, 15 марта 2024 (UTC) [ ответить ]

RfC: Изменить INFOBOXUSE, чтобы рекомендовать использование инфобоксов

Похоже, что консенсуса по поводу такого изменения не существует.

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

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

Еще больше усложняет ситуацию то, что эта область (инфобоксы, их обсуждение, их содержимое, существуют ли они вообще на странице) считается спорной темой ( Wikipedia:Contentious_topics/Infoboxes ), склонной к интенсивным разногласиям и/или проблемному поведению при редактировании в различных ситуациях. Некоторые противники открыто называют это причиной осторожности при внедрении общих рекомендаций, касающихся инфобоксов (и/или что это предложение может быть недостаточно эффективным в его текущей формулировке), в то время как некоторые сторонники предполагают, что в целом некоторое движение в сторону обновленных рекомендаций для инфобоксов могло бы помочь смягчить эти проблемы.

-- slakr ^{\ talk /} 03:54, 18 июня 2024 (UTC) [ ответить ]

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

Ярлыки

WP:РЕКОМЕНДУЮBRFC
WP:RECINFOBOXRFC

Следует ли изменить INFOBOXUSE, чтобы рекомендовать инфобоксы для определенных видов статей? — Wug· a·po·des 20:37, 15 марта 2024 (UTC) [ ответить ]

Предложение: Старый текст: Использование инфобоксов не является обязательным и не запрещено для любой статьи. Включать ли инфобокс, какой инфобокс включать и какие части инфобокса использовать, определяется путем обсуждения и консенсуса между редакторами в каждой отдельной статье.; Новый текст
Использование инфобоксов рекомендуется для статей по конкретным биологическим классификациям , химическим элементам и соединениям , событиям , людям , поселениям и аналогичным темам с узкой и четко определенной областью применения. Широкие темы и обзорные статьи, такие как философия , время или математика, обычно лучше обслуживаются навигационными боковыми панелями, такими как {{ philosophy sidebar }} , {{ time sidebar }} , или {{ math topics sidebar }} . Заглушки обычно слишком короткие, чтобы оправдать инфобокс, и инфобоксы на них часто привлекают правки, расширяющие инфобокс, а не расширяющие статью.
Там, где используются инфобоксы, они не должны быть ни слишком короткими, ни слишком длинными. Они должны содержать основные факты, которые читатели разумно ищут с первого взгляда, например, дату рождения людей или количество протонов в элементе. Инфобоксы не следует использовать в качестве хранилищ для какой-либо разрозненной информации, связанной с темой, поскольку визуальный беспорядок может затруднить читателям быстрый поиск наиболее важной информации . Если информация важна, но слишком сложна для того, чтобы поместить ее в инфобокс, рассмотрите возможность использования ссылки на раздел или специальную статью по теме. Например, вместо того, чтобы пытаться решить, какие из произведений Моцарта следует перечислить в инфобоксе, поле «произведения» представляет собой ссылку на Список композиций Вольфганга Амадея Моцарта .

Предыдущие обсуждения

Предыдущие / Связанные централизованные RFC

Размещаю это в самом верху в качестве ссылки для закрытия и/или будущих обсуждений, поскольку я (и, вероятно, другие невовлеченные люди не будут иметь) понятия, пока не прочитаю несколько комментариев. :P Не стесняйтесь обновлять. -- slakr ^{\ talk /} 20:54, 3 июня 2024 (UTC) [ ответить ]

Википедия:Village_pump_(policy)/Archive_143#Infobox_RFC (май 2018 г.)
Wikipedia:Village_pump_(предложения)/Архив_202#RfC_on_ Establishing_a_biography_infobox_guideline (июнь 2023 г.)

Обсуждение

Поддержка После изучения обсуждений по инфобоксам за последние несколько лет у меня сложилось впечатление, что наши рекомендации не поспевают за фактическим консенсусом на практике. Например, вы заметили, что (надеюсь, исчерпывающий) список обсуждений за последние несколько лет включает биографии, в то время как статьи о химических веществах, поселениях и видах, по-видимому, имеют очевидный консенсус включать их там, где это возможно. Чтобы донести суть, 3,1 миллиона статей (почти 50%) имеют инфобоксы . Мы должны задокументировать этот консенсус. Областью разногласий, по-видимому, являются биографии, и притом особые виды биографий: субъекты, которые занимаются театральным, литературным, музыкальным или изобразительным искусством с широким признанием критиков, что затрудняет изложение их субъективных достижений в строке в поле. Несмотря на это, редакторы регулярно находили консенсус, что эти статьи лучше с инфобоксом, чем без него. Мы должны задокументировать этот консенсус и, как мы надеемся, сократить время, которое сообщество тратит на посредничество в относительно узкой области спора.
Цель предложения не в том, чтобы требовать, чтобы каждая статья имела инфобокс, на самом деле, оно дает конкретные рекомендации о том, когда инфобокс не следует использовать. Цель состоит в том, чтобы обобщить различные соображения, высказанные редакторами в ходе обсуждений, чтобы предоставить редакторам точные рекомендации и помочь улучшить принятие решений в истинных крайних случаях. Это бесполезно, когда у нас есть руководство, которое устарело на годы и не дает фактических рекомендаций, и сохранение его только для обработки небольшого подмножества биографических статей является чистым негативом. Давайте включим идеи из этих дебатов в руководство, но в качестве предостережений от консенсуса из практики, что инфобоксы являются частью нашего фирменного стиля. — Wug· a·po·des 20:37, 15 марта 2024 (UTC) [ ответить ]
Областью разногласий, по-видимому, являются биографии, причем конкретные виды биографий: субъекты, которые занимаются театральным, литературным, музыкальным или изобразительным искусством и имеют широкое признание критиков, что затрудняет изложение их субъективных достижений в краткие строки.
Я думаю, что это ошибочная идентификация. Логическая область разногласий — это любая тема, которую нельзя легко суммировать с помощью ключевых пунктов, из которых некоторые классы биографий являются просто наиболее заметными.
Мне кажется, что существование универсального консенсуса, который вы описываете, в лучшем случае подразумевается, и что вы преувеличиваете его широту. Кажется немного амбициозным приписывать это универсальное намерение не только Википедии, но и СМИ в целом.
Несмотря на это, редакторы постоянно приходят к единому мнению, что такие статьи лучше с информационным блоком, чем без него.
Зачастую этого не происходит, или же все сходятся во мнении, что информационный ящик — это свершившийся факт.
Это бесполезно, когда у нас есть руководство, которое устарело на несколько лет и не обеспечивает реальных рекомендаций, а сохранение его только для обработки небольшого подмножества биографических статей — это чистый негатив.
Он действительно дает реальное руководство, руководство заключается в том, что "вы должны использовать свою голову", как и многие другие области советов в Википедии. Если инфобоксы уже так широко распространены, как вы указали, почему, черт возьми, нам нужно (на уровне руководства) предписывать их использование? Никому не нужна помощь, зная, что статьи часто содержат их, это первая часть многих статей, которую привлекают для редактирования многие новые пользователи.
Мне кажется, что это похоже на аргумент о том, что «инфобоксы обычно-всегда хороши для статей», замаскированный под аргумент о том, что «„инфобоксы обычно-всегда хороши“ — это всеобщий консенсус». Мы действуем здесь на основе проверки и консенсуса, но нам также приходится самим приводить аргументы. Существует значительное тематическое пространство, где есть разумные аргументы о том, что использование инфобоксов там нехорошо или не нужно. Давайте будем интеллектуально честны в этом вопросе. Remsense诉21:09, 15 марта 2024 (UTC) [ ответить ]
Они есть в более чем 50% статей, и я предоставил запросы предложений (RfC) за два года, чтобы подтвердить свою позицию. — Wug· a·po·des 21:12, 15 марта 2024 (UTC) [ ответить ]
Более 50% статей имеют некоторое количество аспектов и дефектов. Если вы считаете, что это равнозначно явному нормативному консенсусу, то это то, что вы добавляете сверху.
Ваши запросы на комментарии касаются отдельных статей, и представлять их как поддержку такой универсализирующей позиции граничит с нечестностью.
Remsense诉23:12, 15 марта 2024 г. (UTC) [ ответ ]
Половина наших статей имеет эту функцию, и за последний год почти каждый RfC, который у нас был, привел к консенсусу по их включению, но я нечестен, потому что думаю, что это показывает общую поддержку этого? Пожалуйста, будьте серьезны. — Wug· a·po·des 23:41, 15 марта 2024 (UTC) [ ответить ]
RFC касались отдельных статей, они не отвечали на вопрос «должна ли каждая статья иметь инфобокс». Это другой вопрос, это тот, который мы здесь обсуждаем. Самое меньшее, что вы могли бы сделать, это сформулировать этот RFC как установление категорического консенсуса, а не просто отражение существующего. Remsense诉23:44, 15 марта 2024 (UTC) [ ответить ]
Речь не идет о том, должна ли каждая статья иметь инфобокс. Текст буквально включает рекомендации о том, когда их не следует использовать. Прежде чем называть меня нечестным или рассказывать, как сформулировать предложение, пожалуйста, прочтите само предложение и охарактеризуйте его точно. — Wug· a·po·des 23:52, 15 марта 2024 (UTC) [ ответить ]
Извините, "большинство статей, согласно определенным широким критериям". Полагаю, у меня также есть проблема с вашим критерием "узкий; четко определенный объем". Инфобоксы не очень хороши для статьи, основанной на их объеме, верно? Речь идет о том, есть ли четко определенные свойства самой темы. Четко определенный объем не означает, что объем хорошо подходит для представления в инфобоксе. Remsense诉02:04, 16 марта 2024 (UTC) [ ответить ]
@ Wugapodes . Remsense не назвал вас нечестным, это их неправильное толкование. Они просто попросили вас перефразировать свой вопрос. И это, конечно, не более невежливо, чем сказать редакторам «быть серьезными». ——Серийный номер 54129 14:06, 16 марта 2024 (UTC) [ ответить ]
Я сказал, что их фрейминг "граничил с нечестностью", и я принимаю, что меня встретили с такой характеристикой. Говорить это не было необходимости, чтобы донести свою точку зрения, поэтому я думаю, что я мог бы сказать это более снисходительно. Remsense诉14:10, 16 марта 2024 (UTC) [ ответить ]
- Почему вы выбрали именно эти примеры для таблицы? Почему игнорируется WP:RFCBEFORE ? И почему мы игнорируем WP:RFCOPEN с ненейтральным мнением в заявлении? - SchroCat ( обсуждение ) 04:23, 16 марта 2024 (UTC) [ ответить ]
- Я обновил таблицу, включив в нее информацию из более современной версии SandyGeorgia , хотя, вероятно, все еще есть пробелы. С учетом отсутствующих данных (как ни странно, все без консенсуса по ящику) она рисует немного иную картину, чем предполагаемая универсальная поддержка ящиков во всех биографиях. Я удалил запись, которая не была о том, включать ящик или нет, и убрал примечания, которые были весьма NPOV и местами вводили в заблуждение. Давайте попробуем сохранить нейтральность в верхней части. - SchroCat ( обсуждение ) 10:59, 16 марта 2024 (UTC) [ ответить ]
Поддержка . Предлагаемый текст отлично отражает практику использования инфобоксов, а также то, когда и почему они полезны. Прочитав некоторые обсуждения о том, предоставлять ли инфобоксы людям с менее легко обобщаемыми достижениями, и написав пару статей, подобных этой, о дневнике, актере и экономисте, я в целом считаю, что наличие инфобокса лучше, чем его отсутствие. Инфобоксы читабельны, они доступны и используются. Это хороший предлагаемый текст для руководства по стилю, чтобы внести больше ясности в то, как мы используем инфобоксы, особенно для новых редакторов, изучающих руководство по стилю. P-Makoto (она/ее) ( обсуждение ) 20:47, 15 марта 2024 (UTC) [ ответ ]
Я не думаю, что широкие темы и обзорные статьи, такие как философия, время или математика, обычно лучше обслуживаются навигационными боковыми панелями, такими как {{ philosophy sidebar }} , {{ time sidebar }} , или {{ math topics sidebar }} . Заглушки обычно слишком короткие, чтобы оправдать инфобокс, и инфобоксы на них часто привлекают правки, расширяющие инфобокс, а не расширяющие статью. требуется в это время. Это оффтопик для раздела и добавляет то, что я считаю ненужным руководством в придачу. Я бы даже сказал, что «заглушкам не нужны инфобоксы» категорически неверно, основываясь на моем гноминге по многим тысячам статей в поисках цитат, помимо предложения чего-то ненужного. Я также не хотел бы добавлять дополнительную поддержку боковых панелей, которые, хотя я согласен, могут быть использованы в этих местах, поскольку они часто занимают место (как предполагает по крайней мере одно другое место в MOS), которое можно было бы плодотворно использовать для других элементов, плавающих справа. (И я пришел к выводу, что боковые панели следует просто удалить как категорию, по крайней мере, в основном пространстве.)
В противном случае, я в целом приветствую эту попытку добавить поддержку в MOS для инфобоксов. В этом плане я даже думаю, что есть некоторые факторы в User:RexxS/Infobox factors (и на странице обсуждения), которые можно было бы перечислить в дополнение к тем, которые вы выбрали выше. Izno ( обсуждение ) 20:58, 15 марта 2024 (UTC) [ ответить ]
Я открыт для удаления примечания о боковых панелях. Целью было не рекомендовать использование боковых панелей, а скорее противопоставить типы статей, где инфобокс бесполезен (потому что что-то другое справляется лучше). Может быть, лучше было бы убрать навигационную боковую панель? Скажем, обширные темы и обзорные статьи, такие как философия, время или математика, как правило, не очень хорошо обслуживаются инфобоксами ? Я разделяю интуицию, что во многих заглушках есть инфобоксы, но из прочитанных мной обсуждений я не уверен, что их использование в заглушках — это то, что мы обязательно должны рекомендовать? Большая проблема, которая возникает в обсуждениях по ссылкам, заключается в том, что инфобоксы привлекают правки и могут затмевать содержимое страницы способами, которые не являются полезными, что усиливается на заглушках или коротких страницах. Поэтому, хотя есть много заглушек, в которых есть инфобоксы, мне интересно, будет ли обсуждение в рамках всего проекта рассматривать эту практику как нечто, что следует поощрять или нет? Я открыт для ответа «нет, все в порядке, удалите эту строку», но я подумал, что стоит проверить консенсус. Я даже думаю, что есть некоторые факторы в факторах User:RexxS/Infobox (и на странице обсуждения), которые можно было бы перечислить в дополнение к тем, которые вы выбрали выше. Действительно, я думаю, что в долгосрочной перспективе в пользовательских эссе есть много рекомендаций, которые можно включить в документацию всего проекта. Я хотел попытаться синтезировать самые последние обсуждения в качестве отправной точки, а затем перейти к более конкретным рекомендациям, которые редакторы в тематической области разработали на основе опыта. — Wug· a·po·des 21:28, 15 марта 2024 (UTC) [ ответить ]
Я думаю, что общее мнение о том, что у таких приложений обычно нет информационного поля, — это хорошее место, к которому стоит отступить.
Я не уверен, что их использование в заглушках — это то, что мы обязательно должны рекомендовать. Да, но вы идете дальше, чем «мы, вероятно, не должны рекомендовать» в «мы рекомендуем против», особенно когда вы включаете какое-то незначительное обоснование того, почему кто-то может захотеть избежать инфобоксов в таких статьях. Особенно такое благовидное обоснование, как «мы не хотим, чтобы люди редактировали короткие страницы с инфобоксами!». *указывает на общее направление всей Википедии, ее этоса и всего такого* :) Мы функционально никогда не удалим то, что может быть воспринято как «неприятные» правки, именно потому, что мы предполагаем добросовестность , и инфобоксы ничем не отличаются в этом отношении, на странице любого размера.
Было бы справедливо описать текущее использование инфобоксов в коротких статьях как «они, скорее всего, не будут иметь инфобоксов», но я не вижу в этом ничего, кроме того, что «короткие статьи, скорее всего, будут иметь более низкое качество», что более или менее соответствует состоянию вики. Izno ( обсуждение ) 23:59, 15 марта 2024 (UTC) [ ответ ]
Поддержка - помимо всех причин, приведенных Wugapodes, с которыми я полностью согласен, инфобоксы просто полезны в целом. Я буду придерживаться своей собственной идеи RfC, пока это не будет решено. Также, Wugapodes , вам может быть интересна таблица биографий музыкантов с инфобоксами, которую Герда Арендт собрала в прошлом году: см. обсуждение в Википедии:WikiProject Classical music/Archive 80#10 years . MyCatIsAChonk ( обсуждение ) ( не я ) ( также не я ) ( все еще нет ) 22:07, 15 марта 2024 (UTC) [ ответить ]
Поддержка -- Герда Арендт ( обсуждение ) 22:14, 15 марта 2024 (UTC) [ ответить ]
Являются ли перечисленные выше темы примерами или более окончательным списком? Я также видел, что у каждого языка и звезды есть инфобокс. Также следует ли создавать теги обслуживания? {{ Missing taxobox }} существует. 115.188.117.112 (обсуждение) 22:20, 15 марта 2024 (UTC) [ ответить ]
Они предназначены в качестве примеров, общее руководство — «темы с узкой и четко определенной областью применения», которые, как я думаю, охватывают языки и небесные объекты, а также дороги и другие вещи, которые я не могу придумать с ходу. {{ Missing taxobox }} , похоже, не используется ни в одной статье, и я думаю, что шаблоны обслуживания будут больше хлопот, чем пользы. Если не стоит делать дополнительный шаг для добавления информационного поля, то, вероятно, это не настолько важно, чтобы оправдать тег обслуживания. — Wug· a·po·des 22:24, 15 марта 2024 (UTC) [ ответить ]
{{ Отсутствующий taxobox }} используется в статьях; я добавляю его сам довольно регулярно. Просто нет отставания существующих статей, которым нужен taxobox и у которых его нет, и редко бывает, чтобы новая статья таксона была создана без taxobox (и редко проходит через NPP без добавления taxobox). Статьи, которые помечены как отсутствующий taxobox, обычно решаются в течение нескольких часов, и в любой момент времени обычно нет статей с отсутствующим шаблоном taxobox. Но он используется. Plantdrew ( обсуждение ) 20:17, 17 марта 2024 (UTC) [ ответить ]
Поддержка 🌺 Cremastra ( обсуждение ) 22:22, 15 марта 2024 (UTC) [ ответить ]
Поддержка - Это разумное предложение, которое отражает позицию сообщества по инфобоксам. Спасибо за работу по составлению этого. Nemov ( talk ) 22:51, 15 марта 2024 (UTC) [ ответить ]
Поддержка Текущая формулировка устарела ( добавлена в 2011 году ; любезно предоставлена ping @ WhatamIdoing ) и больше не отражает общепринятую практику. Информационные поля, как правило, полезны и должны быть включены, если информации достаточно. InfiniteNexus ( обсуждение ) 22:52, 15 марта 2024 (UTC) [ ответить ]
Спасибо за пинг. Wikipedia:Консенсус может измениться , и если это произошло (что определит этот RFC), то у меня нет никаких возражений против его изменения, и я не имею никакого особого представления о том, что должна быть написана в новой версии. WhatamIdoing ( обсуждение ) 22:56, 15 марта 2024 (UTC) [ ответить ]
Oppose . Это будет вопиющим нарушением компромисса ArbCom. Также, похоже, что здесь может иметь место агитация. -- Ssilvers ( talk ) 23:03, 15 марта 2024 (UTC) [ ответить ]
Где ваши доказательства того, что агитация имела место? InfiniteNexus ( обсуждение ) 23:19, 15 марта 2024 (UTC) [ ответить ]
Для прозрачности я разместил посты на WP:CENT и WP:VPP , и на моей странице обсуждения есть небольшое обсуждение, за которым наблюдают некоторые. Кроме этого, я не знаю, где еще это рекламировалось. — Wug· a·po·des 23:44, 15 марта 2024 (UTC) [ ответить ]
Также, Ssilvers, не могли бы вы более конкретно рассказать о «компромиссе ArbCom»? В пункте 6 статьи Infoboxes (2013) говорится, что «Арбитражный комитет рекомендует провести широко разрекламированное общественное обсуждение для решения вопроса о том, следует ли принимать политику или руководство, определяющее, какие факторы должны перевешивать за или против включения инфобокса в данную статью». Что, по сути, и есть. В этом случае, похоже, нет ничего, что мешало бы сообществу создавать политику или руководство относительно инфобоксов, совсем наоборот. Я что-то упускаю или вы ссылаетесь на другой случай? — Wug· a·po·des 23:49, 15 марта 2024 (UTC) [ ответить ]
Поддержка . Я думаю, что использование инфобоксов должно регулироваться так, чтобы они не были слишком длинными. Если инфобокс слишком длинный, он может закрыть почти всю сторону статьи и, что еще хуже, сместить изображения, которые были размещены там, где они должны быть. ▪︎ Fazoffic₍_{ʖ╎ᓵᔑ∷ᔑ}₎ 23:07, 15 марта 2024 (UTC) [ ответить ]
Возражаю против моего ответа выше,~~а также важное, фундаментальное наблюдение, сделанное Силверсом.~~ Во время какой-то внеклассной дискуссии с Гердой я случайно упомянул тот факт, что я не выразил свои настоящие мнения очень ясно здесь, в моем первоначальном !vote. Мое несогласие с этим RfC не имеет практически никакого отношения к ArbCom или агитации, и я не наблюдал буквально никакой нечестной игры от кого-либо еще в этом RfC, каким бы самоуверенным он ни был. Она предложила мне вычеркнуть эту часть, и я согласен, что это хорошая идея, так как мое прошлое замешательство не порождает ваше в будущем. Немного более четкое изложение моих чувств по постоянной ссылке выше . Remsense诉09:32, 7 апреля 2024 (UTC)Текущая формулировка также отражает консенсус и прекрасно ему служит. Было бы неплохо иметь некоторые рекомендации для инфобоксов относительно длины, но это, похоже, протаскивается поверх того, что является чрезвычайно широким универсальным правилом, затрагивающим большинство статей на сайте , сфера охвата которого столь же огромна, как и у любого RfC в истории сайта. Я отвергаю то, что здесь равнозначно свиной бочке, и настаиваю на том, что пункты следует рассматривать индивидуально для предложения, столь разветвленного. Remsense诉23:17, 15 марта 2024 (UTC) [ ответить ]
Я понимаю, что вы говорите, но инфобоксы по своей природе являются чрезвычайно широким универсальным понятием. И я не думаю, что текущая формулировка отражает консенсус, поскольку по какой-то странной причине большинство статей по перечисленным темам содержат инфобоксы. Должно быть, это сумасшедшая клика инфобоксов добавляет их, я полагаю, а не ~90% пользователей, которые просто относятся к ним как к стандарту. Dronebogus ( talk ) 15:53, 17 марта 2024 (UTC) [ ответить ]
Поддержка Wugaopodes. Информационные поля должны поощряться, но не быть обязательными. Приняв участие в нескольких упомянутых RfC, я рад, что другие редакторы чувствуют то же самое. Предлагаемая формулировка MoS будет отражать как широкое использование информационных полей, так и дюжину отдельных RfC, опирающихся на включение. Я припоминаю, что большинство этих споров об информационных полях возникло из-за споров о содержании некоторых параметров (в таких случаях можно было бы пойти на компромисс и полностью опустить эти детали). SWinxy ( обсуждение ) 01:25, 16 марта 2024 (UTC) [ ответ ]
Oppose Infoboxes хороши и должны использоваться. Однако, хотя 50% статей могут использовать их, слишком многие не содержат ничего, кроме повторения информации в первом предложении статьи. Это полная трата места и не добавляет статье никакой ценности. Дата рождения, указанная в этом тексте, является точным примером этого. Я был бы открыт для слегка измененного текста, который усиливает точку зрения не использовать слишком короткие инфобоксы. -- LCU Активно Неинтересно « @ » ° ∆t ° 01:52 , 16 марта 2024 (UTC) [ ответить ]
Это хороший момент, особенно для многих статей, которые просто не могут включать проверяемые даты рождения, смерти и другие параметры. Не все жили в Европе после 19 века с надежными записями о жизни. Такие люди, как Гай Веррес или Квинт Туллий Цицерон, не могут заполнять параметры в информационном поле с входом в область вымысла. Ifly6 ( обсуждение ) 23:20, 17 марта 2024 (UTC) [ ответ ]
Oppose . Remsense отмечает некоторые проблемы с первым абзацем, но он также смешивает четко определенную тему статьи с темой, которая может быть хорошо описана структурированными данными. В этом отношении не может быть единого размера, как было отмечено по крайней мере в двух предыдущих RfC в этом направлении ( 1 , 2 ), и многие из опасений, поднятых в этих обсуждениях, сохраняются с этим предложением.
Пункт 2 — это просто мусорный бак, если честно. Я согласен с точкой зрения Remsense о рассмотрении этого отдельно и отмечаю, что это, по-видимому, побудило по крайней мере одну поддержку (Fazoffic), которая не рассматривает более широкое изменение пункта 1. Но вдобавок ко всему, это предложение противоречит нескольким другим существующим частям руководства, которые оно не предлагает заменять, оно отбрасывает действительно полезные указания из предыдущей версии по разрешению споров, противоречит само себе и отдает предпочтение включению, основанному исключительно на том, считает ли кто-то что-то «базовым», в ущерб любым другим соображениям — способствуя чрезмерному упрощению и отрицательно влияя на нейтралитет. Nikkimaria ( обсуждение ) 02:12, 16 марта 2024 (UTC) [ ответить ]
Поддержка Использование инфобоксов де-факто стандартизировано в этих категориях, за исключением нескольких статей, в которых их не используют. Наша главная цель должна заключаться в обслуживании читателей, и поскольку такие статьи почти всегда содержат инфобоксы, это служит принципу наименьшего удивления , когда пользователь ищет информацию в правом верхнем углу статьи, он найдет указанную информацию в (разумно) последовательной манере. Я также не вижу, как их повторение основных фактов может быть измеримо вредным; они на самом деле не занимают так много места, особенно учитывая, что картинка, скорее всего, будет там в любом случае. ― 02:20, 16 марта 2024 (UTC) [ ответить ]novov (t c)
Поддержка , однако для заглушек, которые уже имеют инфобоксы, их не следует удалять без веских оснований (например, неиспользуемые утверждения и т. д.). Я считаю, что это нужно сохранить, чтобы помочь новым редакторам: если вы сомневаетесь, какой инфобокс включить и какие части инфобокса использовать, это определяется путем обсуждения и консенсуса между редакторами в каждой отдельной статье. RaFaDa20631 ( обсуждение ) 04:21, 16 марта 2024 (UTC) [ ответить ]
Oppose . Не каждая статья, соответствующая этим критериям, имеет достаточно информации для формирования жизнеспособного IB. Интересно, почему в таблице приведены примеры, отобранные с особой тщательностью (отсутствуют статьи, в которых, очевидно, не было консенсуса, и Sellers, перечисленные, несмотря на то, что у них уже есть IB). - SchroCat ( talk ) 04:37, 16 марта 2024 (UTC) [ ответить ]
@ SchroCat , можете ли вы предоставить ссылки на какие-либо отсутствующие RFC? Похоже, целью было перечислить все RFC об инфобоксах за последние два года, и я не думаю, что кто-то будет возражать против добавления в список упущенного RFC. WhatamIdoing ( talk ) 16:40, 16 марта 2024 (UTC) [ ответить ]
Я уже смело добавил три, о которых знаю (все без консенсуса, что сильно изменило вид таблицы). Я не отслеживаю и не слежу за ними (не говоря уже о том, чтобы комментировать их все), но вполне могут быть и другие. - SchroCat ( обсуждение ) 16:45, 16 марта 2024 (UTC) [ ответить ]
Выступаем против рекомендации инфобоксов для людей, не уверенных в некоторых других категориях. Для многих биографий до 1800 года и других недавних биографий недостаточно определенной информации, чтобы написать полезный инфобокс. Инфобоксы также занимают место и затрудняют размещение изображений. Если инфобоксы включены в стандартную комплектацию, нам следует отказаться от правил против сэндвича, чтобы статьи можно было правильно иллюстрировать. — Kusma ( обсуждение ) 05:54, 16 марта 2024 (UTC) [ ответить ]
- Я согласен со всем, что вы говорите (хотя сказал бы, что это биографии до 1900 года), но включил бы и недавние биографии как проблемные. У нас нет дат или мест рождения на уровне города для многих BLP, что оставляет IB с полями имени, национальности и рода занятий/известности. Это означало бы, что мы просто дублируем первое предложение, что не идеально. Также согласен, в частности, с Никкимарией выше относительно того, что два предыдущих RFC ( один из которых был всего девять месяцев назад ) отклонили идею из-за глубоко укоренившихся опасений: эта предлагаемая мера вызывает те же опасения. - SchroCat ( обсуждение ) 06:51, 16 марта 2024 (UTC) [ ответить ]
Возражаю против пункта 2, пункт 1 нуждается в доработке. Второй абзац полностью соответствует территории WP:CREEP и, кроме того, не так уж хорошо сформулирован, в то время как первый абзац, хотя и ближе к современной практике, чем к нынешнему устаревшему руководству, нуждается в редактировании для разрешения слишком широких категорий (например, примечание Кузмы о биографиях до 1800 года). ~~ AirshipJungleman29 ( обсуждение ) 06:44, 16 марта 2024 (UTC) [ ответить ]
Oppose . Текущий текст более лаконичен, ясен, последователен и неоспорим, чем предлагаемый текст. DrKay ( talk ) 07:50, 16 марта 2024 (UTC) [ ответить ]
Oppose . Из миллионов статей с инфобоксами почти ни одна не была оспорена; причина изменить формулировку здесь заключается в том, чтобы предоставить лучшее руководство по статьям, где в противном случае могли бы возникнуть разногласия по поводу использования инфобоксов. Это как раз те случаи, когда должно быть обсуждение, а не ссылка на правило. Я пишу много статей в журналах, и инфобокс обычно полезен в этих статьях, но иногда он не представляет никакой ценности, потому что почти ни в одном из соответствующих полей нет простых ответов. Я бы не хотел видеть правило, которое навязывает инфобокс статьям, в которых все редакторы, работающие над статьей, считают его вредным. И как упоминалось выше, что насчет постановления ARBCOM? Может ли этот RFC отменить это постановление? Что касается второго абзаца предлагаемой формулировки, я думаю, что он имеет благие намерения, но не будет полезен на практике — он предоставляет список вещей, которые следует учитывать, без способа решения вопроса: «они не должны использоваться в качестве хранилищ для какой-либо разрозненной информации» — дебаты о том, важна ли конкретная часть информации или нет, — это то, что возникает в этих дебатах, и эта формулировка не дает никаких указаний по решению этих вопросов (и я не вижу, как она могла бы это сделать). Большая часть остальной части абзаца имеет ту же проблему. Майк Кристи ( talk - contribs - library ) 12:08, 16 марта 2024 (UTC) [ ответить ]
Я не занимаю никакой позиции по поводу того, должны ли статьи иметь инфобоксы, но я хочу поблагодарить Wugapodes за то, что они начали это обсуждение. Закрывающим RfC действительно нужно некоторое руководство от сообщества о том, как решать эти вопросы, и любой прогресс в направлении такого руководства будет очень полезен.— S Marshall T / C 12:20, 16 марта 2024 (UTC) [ ответить ]
- Я бы особенно приветствовал руководство сообщества по двум конкретным вопросам. Во-первых, более четкие инструкции о том, что должно содержать спорное информационное поле, а что оно должно опускать; и, во-вторых, что делать, когда информационное поле ожидает простого списка из одного или двух слов, но в этой статье есть нюанс, который нужно решить. На данный момент я бы сказал, что при отсутствии консенсуса правильным результатом будет либо оставить спорный параметр пустым, либо написать «см. [заголовок]»? Не уверен, как выбрать.— S Marshall T / C 12:30, 16 марта 2024 (UTC) [ ответить ]
  То, что должно содержать или опускаться в информационном поле, крайне зависит от предмета… то, что работает в одной статье, не будет работать в другой. Слишком много переменных. Я не думаю, что «инструкция» возможна. Blueboar ( обсуждение ) 15:44, 16 марта 2024 (UTC) [ ответить ]
  Первое невозможно обобщить, за исключением того, что оно должно уважать WP:INFOBOX и содержать только ключевые факты — очень многие IB этого не делают. Второе проще: если короткая формулировка потенциально вводит в заблуждение, просто опустите ее. Если это что-то действительно важное, например, дата рождения или смерти, может потребоваться «неопределенно» со ссылкой. Johnbod ( talk ) 13:40, 23 марта 2024 (UTC) [ ответить ]
Oppose . Похоже, это решение, ищущее проблему. Предлагаемый новый текст выглядит как подарок для Wikilawyers. И почему предполагается, что «обсуждение и консенсус» не приведут к лучшему или, по крайней мере, разумному решению в отдельных случаях? Gog the Mild ( talk ) 13:55, 16 марта 2024 (UTC) [ ответить ]
Выступаю против большинства убедительных аргументов выше, особенно Никкимарии — один размер не подходит всем — и излишне ограничивающего локального консенсуса, который arbcom предписал устанавливать в каждом конкретном случае. Расползание инструкций — постоянная проблема. —— Серийный номер 54129 14:13, 16 марта 2024 (UTC) [ ответить ]
Oppose — это перебор. Утверждения типа «Заготовки обычно слишком короткие, чтобы оправдать инфобокс» не имеют для меня смысла; я бы сказал, что все заготовки, например, статей о видах, должны иметь инфобоксы для согласованности (и почти все они есть). — Йенс Лалленсак ( обсуждение ) 14:31, 16 марта 2024 (UTC) [ ответить ]
@ Jens Lallensack , пара других редакторов усомнились в предложении о заглушках. Вы бы все равно выступили против, если бы это предложение было удалено? WhatamIdoing ( talk ) 16:41, 16 марта 2024 (UTC) [ ответить ]
Oppose . Предложенный текст выходит за рамки; я не думаю, что по многим из предложенных деталей действительно есть консенсус. Текущая версия верна, даже если она преуменьшает распространенность инфобоксов, и, честно говоря, я не вижу проблемы в том, что несколько хорошо обсуждаемых статей не включают инфобоксы по той простой причине, что редакторы посчитали, что инфобокс не будет уместен в этой конкретной статье. — Compassionate727 ^{( T · C )} 14:51, 16 марта 2024 (UTC) [ ответить ]
Противостоять - расползание инструкций. Иногда лучше НЕ иметь правила и допускать гибкость. Да, гибкость в «правилах» иногда приводит к разногласиям (и даже жарким спорам). Дело в том, что я считаю это ХОРОШИМ. Это важная часть улучшения проекта.
Должны ли большинство статей иметь информационный блок? Вероятно. Должны ли быть он в статье X ? Это зависит от обстоятельств. Может быть, может и нет. Нам нужно изучить аргументы за и против — и это можно сделать только в каждом конкретном случае. Blueboar ( обсуждение ) 14:55, 16 марта 2024 (UTC) [ ответить ]
@ Blueboar , вас беспокоит, что слово «рекомендуется» будет неверно истолковано как «обязательно во всех случаях»? WhatamIdoing ( обсуждение ) 16:44, 16 марта 2024 (UTC) [ ответить ]
По сути, это слово-ласка первого лица, да. Remsense诉17:12, 16 марта 2024 (UTC) [ ответить ]
Немного... но, скорее, я не думаю, что нам нужно говорить это как-то иначе... ни «рекомендуется», ни «не рекомендуется». Оставьте это на усмотрение редакции. Не все должно быть прописано в «правилах». Blueboar ( обсуждение ) 19:05, 16 марта 2024 (UTC) [ ответить ]
Если говорить конкретно, я думаю, что использование слова «рекомендуется» здесь неверно. Следует сказать, что они должны использоваться или эквивалент — это уже руководство, мы обычно понимаем уровень строгости в том, что это значит. Если « следует использовать » звучит слишком сильно, это потому, что руководство слишком сильное. «Рекомендуется» выполняет функцию хеджирования и еще одного определителя, из-за которого люди беспокоятся об интерпретации. Remsense诉19:11, 16 марта 2024 (UTC) [ ответить ]
Я использую should в значении RFC 2119, когда пишу политики, но есть редакторы, которые считают, что should — более вежливый способ сказать must . WhatamIdoing ( talk ) 20:29, 17 марта 2024 (UTC) [ ответить ]
Поддержка . Обсуждения инфобокса — это трата времени, когда одни и те же редакторы снова и снова повторяют одни и те же общие аргументы. Противники говорят, что каждую статью следует рассматривать индивидуально, но если посмотреть на обсуждения, то можно увидеть, что аргументы, относящиеся к конкретной статье, редко предлагаются, а постоянные участники всегда дают одинаковый !голос. Тот факт, что в последнее время не было консенсуса против инфобокса, говорит сам за себя. Charcoal feather ( talk ) 15:51, 16 марта 2024 (UTC) [ ответить ]
Это ошибка выжившего, она не учитывает случаи, когда в статье нет инфобокса и никто не делает запрос на предложение, чтобы его добавить. Remsense诉15:52, 16 марта 2024 (UTC) [ ответить ]
Нерешительный противник , в значительной степени согласно Майку Кристи и Никкимарии. Я согласен с Вугом выше, что существует консенсус, установленный посредством редактирования, что некоторые широкие классы должны иметь инфобоксы по умолчанию; на ум приходят биологические таксоны, географические единицы - еще один пример. Я не против документирования этого консенсуса, но суть проблемы инфобоксов не в этом. Спор исторически велся о выдающихся биографиях, где этот текст ничего не решит; и суть вопроса не столько в широте, сколько в применимости структурированных данных и, в конечном счете, в эстетической чувствительности. Я думаю, что мы можем с пользой задокументировать некоторые рекомендации в этом отношении, документируя, какие типы данных хорошо подходят для инфобокса, а какие нет, оставаясь агностиком в общем вопросе о том, предпочтительны ли инфобоксы. Я согласен со многими людьми выше, что войны инфобоксов бесконечно разочаровывают, и чтение RfC инфобоксов заставляет меня чувствовать себя как в Дне сурка . Хотя я приветствую усилия, я не вижу, как это решает проблему. Vanamonde93 ( обсуждение ) 20:36, 16 марта 2024 (UTC) [ ответ ]
Oppose - Я не решаюсь принимать решение о добавлении инфобоксов или нет из рук опытных редакторов. Многие из этих обсуждений, которые я видел, включали внешних редакторов, у которых почти нет истории на страницах, на которые они пытаются добавить инфобокс, спорящих с редакторами, у которых есть многочисленные правки. Я не вижу убедительных причин для отмены давнего прецедента. Barbarbarty ( talk ) 17:51, 16 марта 2024 (UTC) [ ответить ]
RFC существуют отчасти для того, чтобы избегать локального консенсуса . Весь смысл RFC — просить «внешних редакторов» о комментариях. По этой теме нет политики, так что это не проблема опытного редактора. Nemov ( talk ) 00:25, 17 марта 2024 (UTC) [ ответить ]
Oppose - есть причина, по которой текущая позиция находится на месте - прекратить конфликт и редактировать войну между людьми, которые требуют, чтобы статьи имели инфобоксы, и теми, кто требует, чтобы они не должны были - эти споры были очень разрушительными и привели к болезненному делу Arbcom. Мы не хотим снова бередить эти раны. Nigel Ish ( talk ) 23:54, 16 марта 2024 (UTC) [ ответить ]
Поддержка Нам нужно привести старые политики в соответствие с текущим консенсусом; я бы предпочел создать хорошую энциклопедию, которая эффективно идет в ногу со временем, чем ту, которая остается статичной, чтобы защитить чувства редакторов. JuxtaposedJacob ( обсуждение ) 00:41, 17 марта 2024 (UTC) [ ответ ]
Что? Чувства редакторов — это то, что такое консенсус. Remsense诉02:05, 17 марта 2024 (UTC) [ ответить ]
Нет, «чувства редакторов» здесь — это именно это, их иррациональные эмоции. Консенсус — это согласование информированных мнений. И да, можно сказать, что текущий «консенсус» по некоторым статьям соответствует этому определению, но, как я вижу, «мнения» здесь никогда не были такими уж «информированными» изначально. Dronebogus ( talk ) 15:43, 17 марта 2024 (UTC) [ ответить ]
В модели консенсуса есть фундаментальный изъян, если она иногда подразумевает отказ от части или большей части в пользу того, что вы индивидуально считаете правильным в любом случае. Remsense诉20:10, 17 марта 2024 (UTC) [ ответить ]
Против в черновом варианте Я симпатизирую некоторому прогрессу в этом вопросе, но в черновике много проблем. Вугаподс справедливо определяет, что биографии являются типичным полем битвы. Я совершенно счастлив, что некоторые типы людей должны иметь поля, например, профессиональные спортсмены, политики и, возможно, кадровые военные, но я не поддержу никаких изменений политики, согласно которым они должны быть у всех людей. На самом деле, должно быть особое предостережение против добавления их к людям из сферы искусства, а также к людям, которых трудно классифицировать, если только нет четкой поддержки редакторов, которые работали над этой или связанными статьями . Это изменение значительно сократит конфликты. Johnbod ( обсуждение ) 03:37, 17 марта 2024 (UTC) [ ответить ]
Я должен добавить, что «Общие темы и обзорные статьи, такие как философия, время или математика, обычно лучше обслуживаются навигационными боковыми панелями, такими как {{ philosophy sidebar }} , {{ time sidebar }} , или {{ math topics sidebar }} ». придется убрать. Боковых панелей и так слишком много (под которыми, я надеюсь, вы подразумеваете нижние панели), и последнее, что мы хотим сделать, это поощрять еще большую датафикацию статей. Исследования показывают, что они редко используются читателями. Johnbod ( talk ) 15:13, 21 марта 2024 (UTC) [ ответить ]
Почему? У Пабло Пикассо есть инфобокс, и все же он, несомненно, человек из мира искусства, и при этом очень важный. Лично я часто прихожу в замешательство, когда у людей их нет там, где они, несомненно, были бы полезны и где уже были набросаны пригодные для использования примеры ( Джоаккино Россини — один из таких случаев). Если одним из результатов этого RfC будет то, что все люди получат или смогут получить инфобоксы, избежав утомительного и ненужно трудоемкого процесса обсуждения этого снова и снова на каждой отдельной странице, это уже будет огромным плюсом. И это позволит редакторам сосредоточиться на самом важном (создание и улучшение контента), вместо того, чтобы тратить свое время на повторяющиеся обсуждения. Gawaon ( talk ) 07:22, 17 марта 2024 (UTC) [ ответить ]
Ну и что? Я говорю, что никто из представителей искусства не должен иметь ИБС? Да, я вижу, что вы в замешательстве. Johnbod ( talk ) 15:13, 21 марта 2024 (UTC) [ ответить ]
Хотя никто не обязан посещать RfC, они могут отнимать много времени, когда статья, находящаяся под контролем людей, становится целью группы тех же людей, не проявляющих никакого интереса к теме. Вот что вызывает утомительную трату времени. Не все биографии подходят для подхода «один размер подходит всем», и они никогда не будут. Вот почему консенсус (подтвержденный на RfC всего девять месяцев назад) заключается в том, что текущая формулировка адекватно отражает реальность. - SchroCat ( обсуждение ) 08:13, 17 марта 2024 (UTC) [ ответить ]
Когда обсуждение зашло в тупик, это не консенсус. Обсуждение девять месяцев назад не смогло достичь консенсуса ни в одну сторону. Немов ( обсуждение ) 12:12, 17 марта 2024 (UTC) [ ответ ]
Он провалился — и называть его тупиковым — это неправильное описание. Завершение этого конкретного RFC, резюмированное как « «Информационные поля не включены и не опущены по умолчанию», является грубым консенсусным выбором », что является как консенсусом, так и максимально приближенным к « Использование информационных полей не является ни обязательным, ни запрещенным для любой статьи », насколько это возможно без прямого копирования. - SchroCat ( обсуждение ) 12:34, 17 марта 2024 (UTC) [ ответить ]
Я ценю, что вы вернулись через день, чтобы перефразировать это, и мне очень понравилась эта красочная интерпретация консенсуса. Немов ( обсуждение ) 21:59, 18 марта 2024 (UTC) [ ответить ]
Если вы считаете, что нейтральный замыкающий ошибся с интерпретацией консенсуса, не стесняйтесь оспаривать это, но никто не поднял никаких вопросов в то время, и это правильно. Моя первоначальная точка зрения (что консенсус был «подтвержден на RfC всего девять месяцев назад») остается в силе, несмотря на ваши попытки неверно истолковать и отрицать. - SchroCat ( обсуждение ) 22:07, 18 марта 2024 (UTC) [ ответить ]
Против в редакции Я согласен с заголовком, что инфобоксы рекомендуются, но в предлагаемом тексте отсутствуют биографии и слишком много другой болтовни о содержании блока. Грэм Бартлетт ( обсуждение ) 09:43, 17 марта 2024 (UTC) [ ответить ]
Самая сильная поддержка единственная причина, по которой некоторые статьи, которые обычно должны иметь инфобоксы, их не имеют, заключается в том, что статья или тема контролируется (смею ли я сказать WP:OWNed ?) горсткой могущественных оппозиционеров, которые все еще ведут войны инфобоксов, которые в противном случае закончились решительной, бесспорной победой фракции сторонников инфобоксов. Эта балканизированная , произвольная система не является тем, как должна работать очень стандартизированная энциклопедия. Dronebogus ( обсуждение ) 15:19, 17 марта 2024 (UTC) [ ответ ]
Как фанат инфобоксов номер один, вы должны знать, что нельзя писать «решительная победа». Кроме того, с каких это пор мы стали «очень стандартизированной энциклопедией»? Мы совершенно определенно, принципиально не такие . Remsense诉15:22, 17 марта 2024 (UTC) [ ответить ]
Мне надоело «игнорировать все правила». У нас много правил, это очень хорошие правила, и они почти всегда соблюдаются. IAR по сути «ничего страшного, если вы случайно их нарушите, потому что это не законы », по сути, совет для неопытных редакторов. Когда опытные редакторы цитируют IAR, это в основном означает «мое мнение лучше, чем устоявшаяся передовая практика, сформированная несколькими редакторами в течение длительного времени и принятая сообществом». Dronebogus ( обсуждение ) 15:30, 17 марта 2024 (UTC) [ ответить ]
Тогда это вы против фундаментального столпа. Remsense诉15:32, 17 марта 2024 (UTC) [ ответить ]
Я знаю, что это фундаментальный столп, но я думаю, что это настолько расплывчато, что может быть интерпретировано как угодно (в чем, я полагаю, и заключается смысл?). Я не совсем понимаю, в чем смысл/послание IAR, когда очевидно, что в Википедии есть правила, которые более или менее необходимо соблюдать, иначе мы не смогли бы наказывать людей за их нарушение. Dronebogus ( обсуждение ) 15:35, 17 марта 2024 (UTC) [ ответить ]
На мой взгляд, это настолько расплывчато, что может быть интерпретировано как угодно, что не является адекватной характеристикой. Это изначально социальный, а не индивидуальный столп: суть в том, что имеют значение намерение и дух правил, и если интерпретация правила в данной ситуации, даже та, которая не кажется слишком педантичной, согласована среди заинтересованных лиц, чтобы идти вразрез с духом правила, текст правила можно игнорировать. Это может быть адаптировано в будущий текст правила, но не всегда должно быть. Remsense诉15:42, 17 марта 2024 (UTC) [ ответить ]
Это прекрасное резюме. Может быть, это должно быть сказано вместо одного предложения без объяснений, которое можно легко интерпретировать как «lol go rando» Dronebogus ( talk ) 15:44, 17 марта 2024 (UTC) [ ответить ]
И я имею в виду страницу IAR, а не страницу Pillar. Dronebogus ( обсуждение ) 15:46, 17 марта 2024 (UTC) [ ответить ]
Это уже как бы есть. Политика гласит: «Если правило мешает вам улучшать или поддерживать Википедию, игнорируйте его». Внесение случайных изменений не улучшает и не поддерживает Википедию; реализация духа политики улучшает.
Я думаю, нам нужно больше IAR, а не меньше. Слишком много редакторов, особенно тех, кто начал редактировать в последние пару лет, похоже, считают, что все, что не разрешено, запрещено . Например, один старательный, преданный редактор сегодня спрашивает, примет ли Wikipedia:Citing источники один из самых распространенных стилей цитирования. (Это руководство буквально содержит слова, что может использоваться почти любой последовательный стиль — WP:PAREN , полностью числовые форматы дат, которые конфликтуют в британском и американском английском, и WP:Bare URL являются единственными исключениями.) WhatamIdoing ( обсуждение ) 05:25, 18 марта 2024 (UTC) [ ответ ]
И еще, раз уж я зашел об этом: смысл политик и руководств в том, чтобы проект работал. А не в том, чтобы можно было налагать санкции на людей. «Санкции» за «нарушение» WP:CITE указаны в его начале: Другие улучшат форматирование, если это необходимо. WhatamIdoing ( talk ) 05:27, 18 марта 2024 (UTC) [ ответить ]
Менее года назад вы получили сообщение о спорных темах о невежливости вокруг IB. Учитывая продолжающиеся помехи, которые вы пытаетесь создать по этой теме, мы близки к отчету AE. - SchroCat ( обсуждение ) 15:27, 17 марта 2024 (UTC) [ ответить ]
Я могу сказать то же самое о вас. Dronebogus ( обсуждение ) 15:31, 17 марта 2024 (UTC) [ ответить ]
Oppose . Одним из наиболее глубоко укоренившихся и разрушительных структурных недостатков Wikipedia является его тенденция к шаблонному построению статей, где вместо того, чтобы отражать, как источники пишут о чем-либо , Wikipedia вместо этого использует источники для установления «знаменитости», а затем выстраивает статью вокруг собственной серии меток, классификаций и соглашений. Это начинается с заголовка (выбранного для краткости, а не для описательной цели, и часто не нейтрального, даже если это случайно), далее внедряется через lede, который еще раз ограничивает потенциальный объем, а затем разбивает контент на разделы, основанные не на том, как источники обсуждают тему, а вместо этого на существующей практике Wikipedia для любой тематической дыры, в которую Wikipedia решила его втиснуть. Инфобоксы являются частью этого процесса и нередко заканчивают тем, что еще больше искажают статьи в искажения типа «вот как Wikipedia определяет вещи, не обращая внимания на источники», которые налагает шаблонное построение. Некоторые темы (на самом деле их очень много) не касаются четко определенных «событий», «людей», «поселений» или подобных, казалось бы, узконаправленных предметных классов, которые можно обобщить в стиле инфобокса, а вместо этого, согласно освещению в источниках, вокруг которых мы должны строить статьи, сложных взаимодействий конкурирующих идей в рамках текущего повествования, где то, является ли что-то «поселением», глубоко оспаривается. В таких обстоятельствах инфобоксы не просто навязывают ограничительную структуру содержанию статьи, они выбирают сторону. Навязывание (или даже «рекомендация») инфобоксов в таких обстоятельствах равносильно указанию нарушить WP:NPOV. AndyTheGrump ( обсуждение ) 16:42, 17 марта 2024 (UTC) [ ответить ]
Я не уверен, что понимаю. Вам не нравится это предложение, потому что вам не нравится... классифицировать вещи, потому что это NPOV называть Джорджа Вашингтона «личностью», Первую мировую войну «событием», или Правду или Последствия, Нью-Мексико «поселением»? Я припоминаю, что вы ввязались в этот странный постмодернистский мета-спор у деревенской колонки, когда я предложил запретить разделы «популярная культура». Дело в том, что я не думаю, что в информационном поле, которое сообщает мне, где родился Джон Стамос , или какой-то другой объективной информации, происходит «сложное взаимодействие конкурирующих идей в рамках текущего повествования». Dronebogus ( talk ) 16:50, 17 марта 2024 (UTC) [ ответить ]
Я не уверен, что понимаю. Я совершенно уверен, что вы не понимаете. Соответственно, я предлагаю вам отнести ваши пустые аргументы соломенного чучела куда-нибудь в другое место, а комментировать мой ответ оставьте людям, которые действительно способны его понять. AndyTheGrump ( talk ) 16:58, 17 марта 2024 (UTC) [ ответить ]
Называть меня глупым — не лучший контраргумент. Вы могли бы объяснить, в чем я не прав. Dronebogus ( обсуждение ) 17:00, 17 марта 2024 (UTC) [ ответить ]
Вы неправы, занимаясь пустыми спорами о соломенных чучелах. Если причина, по которой вы это делаете, заключается в том, что вы не можете понять мои аргументы, это ваша проблема, а не моя. AndyTheGrump ( talk ) 17:04, 17 марта 2024 (UTC) [ ответить ]
Это именно то необъяснение, которое я боялся услышать от вас. «Вы неправы, потому что вы неправы»? Как я должен чему-то научиться из этого? Dronebogus ( talk ) 17:07, 17 марта 2024 (UTC) [ ответить ]
Это RfC по Infoboxes. Это не ветка «объясните Dronebogus, почему аргументы соломенного чучела недействительны», и я не обязан вас чему-либо учить. Или вообще отвечать вам, если на то пошло . Я высказал свое мнение, а это все, что требуется для участия в RfC. AndyTheGrump ( talk ) 17:16, 17 марта 2024 (UTC) [ reply ]
Это та же стратегия аргументации, которую вы используете здесь . В произвольном порядке: выдвигайте неопределенные обвинения/жалобы, превращайте все в обсуждение систематических недостатков Википедии и либо отказывайтесь отвечать на возражения/вопросы, либо оскорбляйте пользователя, который их задает. Это может быть не ветка «объясните Dronebogus, почему аргументы соломенного чучела недействительны», но это и не «измученная полуотставная бывшая википедистская ветка Энди». Dronebogus ( обсуждение ) 18:05, 17 марта 2024 (UTC) [ ответить ]
Ответы на ответы на ответы редко бывают полезны в RFC, и эта ветка отклоняется от цели. -- LCU Активно Неинтересно « @ » ° ∆t ° 20:06, 17 марта 2024 ( UTC ) [ ответить ]
Oppose . Согласно рассуждениям пользователя:Johnbod . Somambulant1 ( talk ) 22:31, 17 марта 2024 (UTC) [ ответить ]

Oppose. Для многих коротких статей о древних деятелях инфобоксы — это просто повторы lede. Их наличие ничего не добавляет и открывает поле (каламбур) для скрытого вандализма. Недавним примером этого являются сотни статей, которые были по сути вандализированы правками только в инфобоксе, которые не соответствовали источникам с основным текстом. В этом виде войны правок, по таким статьям, как Гай Веррес — человек, чьи параметры инфобокса на самом деле равны трем — также есть связанная война правок, какой тип инфобокса использовать; если мы не хотим... в основном делегировать тип инфобокса проектам... что, как я считаю, противоречит политике, то мы обязательно ввяжемся в глупые «дебаты» о добавлении анахроничных вводящих в заблуждение фантастических изображений в инфобокс, следует ли использовать {{ infobox officeholder }} вместо {{ infobox person }} , и (также неоднократно) заполнение фактически неверных параметров, таких как |party=. (Большинство мирян этого не знают, но в Римской республике не было политических партий ; это не мешает невеждам воевать из-за правок |party=Optimatesили |party=Populares.) Ifly6 ( обсуждение ) 22:39, 17 марта 2024 (UTC) [ ответить ]
Oppose Множество комментариев, отмечающих дебаты вокруг использования инфобоксов в определенных статьях, но даже при их использовании они являются особым громоотводом для споров (например, в настоящее время существует длинный RfC по теме « Использование «страны инфобокса» для вымышленных государств» ). То, что инфобоксы могут быть спорными, не является причиной, по которой их нельзя использовать, но предполагает, что, возможно, не стоит писать в MoS идею о том, что они должны быть таковыми. Перечисление конкретных групп статей с определенным использованием инфобоксов лучше обрабатывать с помощью меньших и более конкретных MoS, адаптированных к этим статьям, а не на этом высоком уровне. Упоминание боковых панелей как потенциальной альтернативы — хорошая идея, хотя я бы также не стал их прописывать. Что касается заглушек, инфобоксы не редкость в заглушках, и «часто привлекают правки, расширяющие инфобокс, а не расширяющие статью», честно говоря, можно применить ко всем инфобоксам в любой длине статьи. Что касается второго абзаца, ограничение длины информационного поля в целом кажется полезным (меньше значит больше), но я также не уверен, что его следует предписывать на таком высоком уровне. CMD ( обсуждение ) 05:10, 18 марта 2024 (UTC) [ ответить ]
Против. Ненужная бюрократия. — Sandbh ( обсуждение ) 11:38, 18 марта 2024 (UTC) [ ответить ]
Поддержка в какой-то форме. Я согласен с общим основным мнением, что существующее руководство по инфобоксам не поспевает за реальной практикой в этой теме. Я не согласен с несколькими пунктами первоначального предложения Вугаподеса — в частности, я думаю, что «люди» следует убрать из первого предложения, поскольку биографические статьи являются исторически спорной темой для инфобоксов, и я согласен с предложением Изно удалить отрывок о боковых панелях. Однако я думаю, что предложение в остальном является разумным изложением того, что мы фактически делаем на практике, и я думаю, что принятие его (или его пересмотренной версии) было бы полезно для передачи практических ожиданий читателей и редакторов Википедии. ModernDayTrilobite ( обсуждение • вклад ) 14:24, 18 марта 2024 (UTC) [ ответ ]
В принципе, поддерживаю , но формулировка нуждается в некоторых изменениях. Инфобоксы уже являются стандартом для множества статей – современные должностные лица, современные страны, химические элементы и т. д. Текущая формулировка «Использование инфобоксов не требуется и не запрещено для любой статьи» таким образом явно устарела и не отражает реальности. Для многих других статей предоставление использования или неиспользования инфобоксов исключительно редакторам, которые работают над конкретной статьей, приводит к проблемам с правами собственности и множеству повторяющихся, ненужных и непродуктивных обсуждений. Срочно необходимы дополнительные указания о том, должен ли тот или иной текст иметь инфобокс, и поэтому этот RFC, несомненно, является шагом в правильном направлении.

Тем не менее, некоторые конкретные формулировки требуют больше работы или, возможно, их лучше вообще вырезать. Я думаю, что предложение «Общие темы и обзорная статья ...» можно смело вырезать, поскольку текст должен быть посвящен инфобоксам, а не боковым панелям, плюс это уже подразумевается в упоминании «тем с узкой и четко определенной областью применения» в предыдущем предложении. И я думаю, что совет против использования инфобоксов в заглушках следует удалить — добавление инфобокса в заглушку кажется разумным способом помочь ей расти, а утверждение «инфобоксы на них часто привлекают правки, расширяющие инфобокс, а не расширяющие статью» кажется полностью спекулятивным без подтверждающих его доказательств. Разве не может быть наоборот, когда правки инфобокса приводят к другим правкам за его пределами, будь то теми же редакторами или наблюдателями? «они не должны быть ни слишком короткими, ни слишком длинными» — это тривиальность и бесполезность, поэтому этот пункт тоже следует вырезать. "рассмотреть возможность использования ссылки на раздел" нарушает правило, согласно которому записи в инфобоксе не должны ссылаться на разделы в той же статье (что я считаю разумным — для этого и существует оглавление!), поэтому его тоже следует удалить (и перефразировать остальную часть предложения соответствующим образом). Но это детали — основная идея RfC разумна, это поможет как читателям (приводя к большей согласованности в появлении статей для связанных статей), так и редакторам (уменьшая необходимость в повторяющихся обсуждениях и предоставляя руководство в случаях, когда обсуждения все же происходят). Gawaon ( обсуждение ) 18:57, 18 марта 2024 (UTC) [ ответить ]

Нейтрально , хотя консенсусы (консенсусы?) поддерживают это дополнение, это кажется СТРАШНЫМ и не решает фактической проблемы. Королева Червей ^она / _они^{говорят} / _{преследуют} 20:35, 18 марта 2024 (UTC) [ ответить ]
Противопоставить в редакции В редакции может возникнуть конфликт с WP:INFOBOXPURPOSE и типом информации, размещаемой в инфобоксе - ... цель инфобокса: обобщить (а не вытеснить) ключевые факты, которые появляются в статье , и статья должна оставаться полной без инфобокса - т.е. то, что размещено в инфобоксе, должно поддерживаться текстом статьи, за немногими исключениями, как уже было указано. Cinderella157 ( обсуждение ) 02:05, 19 марта 2024 (UTC) [ ответ ]
Почему и где проект противоречит этому? Я не думаю, что это так. Gawaon ( talk ) 07:27, 19 марта 2024 (UTC) [ ответить ]
Я не говорил, что есть противоречие, а потенциальный конфликт, когда в черновике говорится: Они должны содержать основные факты, которые читатели будут разумно искать с первого взгляда... Это гораздо более субъективно, чем то, что я процитировал выше. Это может быть использовано в качестве завершения более строгого и обоснованного руководства в WP:INFOBOXPURPOSE . За несколькими исключениями, такими как химические данные, которые обычно табулируются в любом случае, информация в информационном поле должна быть ключевыми фактами, подкрепленными статьей. Cinderella157 ( обсуждение ) 12:16, 19 марта 2024 (UTC) [ ответ ]

Oppose как ненужное. Если что, руководство MOS должно быть больше согласовано с WP:WHENINROME , а язык в Manual of Style/Infoboxes должен быть изменен на: обычной практикой является отсылка к стилю/макету, использованному первым основным участником страницы, и редакторы не должны пытаться изменить установленный стиль/макет статьи, просто исходя из личных предпочтений или чтобы он соответствовал другим статьям . Isaidnoway (обсуждение) 10:42, 19 марта 2024 (UTC) [ ответить ]
Однако это касается только стилей цитирования. Gawaon ( обсуждение ) 11:07, 19 марта 2024 (UTC) [ ответить ]
Хотя WHENINROME является частью стилей цитирования, это не единственное руководство, которое у нас есть, которое имеет ту же идею. Выбор языка (BrEng против AmEng против других в MOS:RETAIN ), формат даты (в MOS:DATERET ), использование серийных запятых, стиль (в MOS:STYLEVAR ) и т. д. и т. п. — все это делается по принципу «первым пришел». Хотя есть некоторые ограничения и допуски в некоторых пунктах, где это может быть возможно изменить, общая концепция хорошо укоренилась в процессах WP; я, кажется, помню, что она была введена, чтобы избежать постоянного нарушения одних и тех же пунктов в нескольких статьях. - SchroCat ( обсуждение ) 11:11, 19 марта 2024 (UTC) [ ответ ]
Тем не менее, все это объединяет то, что они касаются исключительно стилистических выборов, которые оказывают очень мало влияния на процесс чтения. Кроме того, они не являются абсолютными, например, MOS:TIES может переопределять MOS:RETAIN . Использование или неиспользование инфобокса, с другой стороны, является важным решением о том, как должна выглядеть статья, и поэтому сильно отличается от таких чисто стилистических вопросов. Мы не говорим: «Может ли статья включать изображения, должно решаться первым основным автором и не может быть пересмотрено позже», и на то есть веские причины. Для инфобоксов это должно быть то же самое. Я не говорю, что каждая статья должна иметь инфобокс (конечно, нет!), а просто то, что его использование — слишком важное решение, чтобы оставлять его на усмотрение каждого человека. Gawaon ( talk ) 12:40, 19 марта 2024 (UTC) [ ответить ]
Несколько вещей. Во-первых, я не на 100 процентов согласен с концепцией (я думаю, что она дает слишком много власти одному человеку) и убрал бы возможность удалить неподходящего IB; однако я бы предпочел этот немного другой подход, а не тот, который не вовлекает людей с нулевым интересом к предмету, которые спускаются до требования ящика «просто так», без реальных мыслей или обоснований за этим — незнание предмета — худшая основа для решения иметь ящик или нет — и, к сожалению, это система, которая у нас есть на данный момент. Я также признал, что были ограничения на выбор, и да, TIES — один из них, но это немного соломенное чучело, когда дело касается IB.
Во время моего рассмотрения различных аргументов, выдвигаемых в обсуждениях IB, я видел, как IB описывались как стилистический выбор, а не стилистический выбор, текст, а не текст, контент и не контент, поэтому я не поддаюсь никаким попыткам классифицировать или классифицировать их (они, очевидно, являются каждым из этих двух и даже больше). Хотя IB «слишком большое решение, чтобы оставлять его на усмотрение отдельного человека», оно также не подходит для того, чтобы его навязывали «правилам!», и не подходит для принятия решения комитетом, который не понимает и не чувствует предмет. - SchroCat ( обсуждение ) 13:24, 19 марта 2024 (UTC) [ ответить ]
Разница между инфобоксами и другими проблемами заключается в том, что инфобоксы — это расширение , которое можно считать частью разработки статьи, а не заменой. Нет никакой потери или выгоды при изменении статьи с британского английского на американский английский, есть для добавления или удаления инфобокса. Например, я еще не добавил инфобокс для лида в Across 7 Street , но это не является неодобрением того, что кто-то добавит его позже Mach61 01:34, 22 марта 2024 (UTC) [ ответить ]
«Расширение» — не совсем правильный термин. «Повторение» более уместно. IB предоставляют упрощенное повторение вырванных из контекста фактоидов, которые часто вводят в заблуждение и которые обычно фокусируются на мелочах. Как я уже сказал выше, я имел в виду, что концепция « первого выбора» не является редкостью в WP, но не обязательно подходит для вопроса IB. - SchroCat ( обсуждение ) 06:49, 22 марта 2024 (UTC) [ ответить ]
Oppose , как я бы сделал, если бы предложение рекомендовало не использовать инфобокс в какой-либо конкретной области. Текущее руководство элегантно и сбалансировано и допускает гибкость. Отходя от гибкости, чтобы облегчить навязывание одной точки зрения, мы склонны сталкиваться с теми, кто придерживается другой точки зрения. Если условия подходят для инфобокса, то текущая формулировка позволяет использовать инфобокс, так что проблем нет. Однако в соответствии с новым предложением, если условия не подходят для инфобокса, но статья посвящена человеку (например), то новая формулировка может быть использована для навязывания инфобокса, и это навязывание, вероятно, будет оспорено, что приведет к потенциальному конфликту и инакомыслию. Это предложение не упрощает добавление соответствующих инфобоксов, но оно узаконивает добавление спорных и неуместных, тем самым открывая дверь для сбоев. SilkTork ( talk ) 14:08, 19 марта 2024 (UTC) [ ответить ]
Выступайте против инструкции creep . Some1 ( обсуждение ) 02:36, 20 марта 2024 (UTC) [ ответить ]
Поддержка Лично я нахожу информационные поля в некоторых статьях полезными и они помогают мне получить общее представление о важных фактах. ‍ Относительность02:56, 21 марта 2024 (UTC) [ ответить ]
А, так вам лично это нравится ? ——Серийный номер 54129 11:48, 21 марта 2024 (UTC) [ ответить ]
«Мне нравится» — это вполне разумный аргумент в данном контексте? Mach61 01:13, 22 марта 2024 (UTC) [ ответить ]
Нет, конечно, нет, я это знаю. Это потому, что, как чисто субъективная оценка, она не может быть преобразована в фактический стандарт стиля, который можно записать в PAG. Ура, ——Серийный номер 54129 16:28, 22 марта 2024 (UTC) [ ответить ]
Oppose per AndyTheGrump. Ajpolino ( обсуждение ) 13:48, 21 марта 2024 (UTC) [ ответить ]
Поддержка , тренд по этому вопросу довольно очевиден, особенно учитывая тот факт, что не было много успешных предложений по удалению инфобоксов из биографических статей, в которых они уже были. Плохо иметь фактические стандарты стиля, которые не записаны в PAG, и широкое принятие инфобоксов является одним из них. Mach61 01:25, 22 марта 2024 (UTC) [ ответить ]
Противостоять , инструкция ползучесть. Заглушить ( обсуждение ) 11:43, 22 марта 2024 (UTC) [ ответить ]
Oppose , дважды. Во-первых, я не согласен, что инфобоксы имеют смысл для всех биографий. Как уже отмечалось, деятели античности являются самым ярким примером — люди, которые являются просто строками на странице где-то, где даже если и предоставлены подробные биографические данные, они могут быть дико ненадежными и написанными кем-то столетия спустя (вспомните персов, о которых писал Геродот ). Принудительное использование инфобоксов — это просто просьба к редакторам, имеющим добрые намерения, придумывать что-то или овеществлять догадки, помещая их в инфобокс. Во-вторых, даже если вы не согласны, это не имеет значения. Если какой-то редактор хочет написать хорошо написанную и хорошо поддерживаемую статью без инфобокса... позвольте им. Отсутствие общей черты сильно отличается от чего-то вроде неточного содержания — это не «проблема», которую нужно исправить. Просто эта статья немного отличается, что безвредно и принято в Википедии, которая явно принимает множественные стили английского языка, множественные стили цитирования, множественные стили организации разделов и т. д. SnowFire ( обсуждение ) 15:34, 22 марта 2024 (UTC) [ ответ ]
↑↑↑↑ Это. - SchroCat ( обсуждение ) 15:56, 22 марта 2024 (UTC) [ ответить ]
Поддержка . Не только инфобоксы, как правило, являются хорошей идеей, но также существует фактический консенсус, что их следует использовать. Текущая нейтральная формулировка MOS вводит в заблуждение. Более того, предложение только рекомендует инфобоксы, но не требует их. Редакторы смогут определить, где следование рекомендации нецелесообразно. Tercer ( обсуждение ) 08:37, 23 марта 2024 (UTC) [ ответ ]
Это ложное утверждение, что существует фактический консенсус - это неправильно. Текущая формулировка не вводит в заблуждение (честно говоря, как это может быть?) И я думаю, мы все знаем уровни вики-правоведения, которые входят в нагруженный термин, такой как «рекомендует», где многие переведут «рекомендовать» как «настаивает на». Я не думаю, что кто-то не согласится, что они полезны в некоторых статьях по некоторым темам, но есть статьи, в которых они не подходят. - SchroCat ( обсуждение ) 09:33, 23 марта 2024 (UTC) [ ответить ]
Конечно, это вводит в заблуждение. Там говорится: «Использование инфобоксов не требуется и не запрещено ни для одной статьи» (выделено мной). Но, как я уже указывал, есть некоторые группы статей — например, современные должностные лица, современные страны, химические элементы и т. д. — которые просто всегда имеют инфобокс, и никаких обсуждений по этому поводу не требуется. Кроме того, предложение не предполагает, что инфобоксы подходят для всех статей, так почему же соломенное чучело в вашем последнем предложении? Gawaon ( talk ) 10:57, 23 марта 2024 (UTC) [ ответить ]
То есть есть IB по статьям, где есть консенсус, вы имеете в виду? Я изо всех сил пытаюсь понять, как это вводит в заблуждение. В моем предыдущем комментарии нет соломенного чучела, даже с учетом заглушек; некоторые полностью сформированные биографии также не гарантируют достаточной информации для создания IB. - SchroCat ( обсуждение ) 13:28, 23 марта 2024 (UTC) [ ответить ]
Полезно записывать общие консенсусы в PAG; это, по сути, цель PAG . Mach61 06:49, 24 марта 2024 (UTC) [ ответить ]
И широкий консенсус зафиксирован . - SchroCat ( обсуждение ) 07:18, 24 марта 2024 (UTC) [ ответить ]
Где? Gawaon ( обсуждение ) 07:28, 24 марта 2024 (UTC) [ ответить ]
Я думаю, что вы намеренно тупите. Текущие рекомендации хорошо отражают тот факт, что только 45 процентов статей имеют IB, независимо от того, насколько бессмысленны или вводящие в заблуждение некоторые из этих полей. - SchroCat ( обсуждение ) 07:44, 24 марта 2024 (UTC) [ ответить ]
Да, но есть некоторые типы статей, где наличие инфобокса обычно считается лучшей практикой. Например, почти в каждом фильме есть инфобокс, а те, у которых его нет, обычно имеют более низкое качество. Dronebogus ( обсуждение ) 07:52, 24 марта 2024 (UTC) [ ответить ]
Согласен, они хорошо работают в статьях о фильмах, но это не одна из областей, перечисленных в предлагаемой формулировке. И это только одна из причин, по которой предлагаемая формулировка так глубоко ошибочна. В ней есть одна тема, где использование считается спорным (сегодня вы удалили IB, который был бы применен предлагаемыми руководящими принципами, просто в качестве напоминания), но она не включает области, где их использование (и их полезность) является обычным явлением. Наличие списка областей, где они не являются спорными, является как излишним, так и INSTRUCTIONCREEP, а текущее руководство является и точным, и управляемым. - SchroCat ( обсуждение ) 08:10, 24 марта 2024 (UTC) [ ответить ]
«Да, но есть некоторые типы статей, где наличие инфобокса обычно считается лучшей практикой». Правильно, и в текущих рекомендациях нет ничего, что бы это прояснило. Вот почему их следует изменить. Остальное — детали — придумать лучшую формулировку может быть непросто, и я согласен (и указал в своем голосовании), что предложенное выше предложение требует дополнительной работы, но это то, что мы должны быть в состоянии выяснить. Gawaon ( обсуждение ) 08:46, 24 марта 2024 (UTC) [ ответить ]
Поддерживаю в принципе. Я не думаю, что фактическое утверждение о заглушках верно, и я думаю, что его следует удалить. Я также думаю, что нам нужно было бы создать некое "прецедентное право" (может быть, FAQ или сноска были бы достаточны? Или изменить формулировку на "рекомендуется, но не требуется"?), чтобы объяснить редакторам, что слово "рекомендуется" не означает "требуется" (особенно для людей, выступающих за инфобоксы). Таблица последних RFC поучительна: ни один RFC об инфобоксах за последние два года не закончился консенсусом против включения инфобокса. Я не припомню, чтобы видел RFC, предлагающий удалить существующий/давно существующий, в течение многих лет (я не совсем уверен, что устоявшиеся инфобоксы когда-либо получали RFC с предложением об их удалении, на самом деле). Поэтому я думаю, что переход от «скрупулезно беспристрастных, потому что мы не хотим, чтобы на нас кто-то кричал, спасибо» к «при прочих равных условиях мы склоняемся к включению инфобокса» неизбежен, и мы должны документировать эту реальность. Мы не должны продолжать говорить новичкам, что игровое поле равное, потому что — к лучшему или к худшему — это не так. WhatamIdoing ( talk ) 22:19, 23 марта 2024 (UTC) [ ответить ]
Поддержка . Информационные поля предоставляют читателям быстрый доступ к наиболее важной информации по теме, например, дата/место рождения и смерти, занимаемые должности, основные награды и т. д. Просматривая оппонентов, я не вижу веской причины не рекомендовать их. Jessintime ( обсуждение ) 14:45, 25 марта 2024 (UTC) [ ответ ]
Я не думаю, что рождение/смерть одинаково уместны для всех статей. Часть о наградах также была бы в значительной степени несущественной, особенно для более исторических личностей, где общественные награды не были обычным явлением. 128.227.1.32 ( talk ) 15:51, 25 марта 2024 (UTC) [ ответить ]
@ Jessintime : Тогда серьезный вопрос: порекомендуете ли вы инфобокс для «биографий» вроде Санаваллата II ? Что бы в нем было, если бы это было так? (Это крайний пример — это гипотетическая личность, которая, вероятно, даже не существовала, но слово «Сабаллат» было написано на одном сохранившемся куске папируса, и ученый начал выдвигать дикие предположения, что, возможно, это сын этого другого парня, но с таким же именем, или, может быть, внук. Но достойны ли «догадки одного парня» инфобокса, когда инфобокс обычно принимается, фактический фон в другом месте? Особенно, когда эти догадки на самом деле не имеют под собой научного консенсуса?) SnowFire ( обсуждение ) 20:19, 25 марта 2024 (UTC) [ ответ ]
Я не понимаю ваш аргумент. Инфобоксы были бы рекомендованы, а не обязательны. В некоторых статьях недостаточно информации, чтобы оправдать цель инфобокса . Конфликт по поводу инфобоксов в биографиях не касается коротких статей. Как отметили другие, не было ни одного RFC, который требовал бы удаления инфобокса, как в приведенном вами примере. Эта идея о том, что инфобоксы будут втиснуты в небольшие статьи, кажется нелепой. Даже самый ярый сторонник инфобоксов не согласился бы с этим. Наконец, если вы действительно считаете, что это проблема, то статус-кво на самом деле ничем не отличается. Нет никаких указаний, поэтому редактор может поместить инфобокс в любую небольшую статью, если захочет. Немов ( обсуждение ) 21:08, 25 марта 2024 (UTC) [ ответ ]
Наличие такого словоблудия, на которое могут указать редакторы, делает плохие информационные блоки гораздо более липкими и текстуально поощряет их добавление, когда такое поощрение не требуется. Разница есть. Remsense诉22:13, 25 марта 2024 (UTC) [ ответить ]
Это не отвечает на мой вопрос. Ничто не мешает этой воображаемой проблеме произойти сейчас. Nemov ( talk ) 23:21, 25 марта 2024 (UTC) [ ответить ]
Опять же, это вопрос степени. Люди, добавляющие неуклюжие вещи туда, где им не место, будут всегда, но эта фраза заставит это происходить чаще. Remsense诉05:58, 26 марта 2024 (UTC) [ ответить ]
Nemov: Я очень надеюсь, что это правда, но у меня мало уверенности, что это правда. В этой самой дискуссии несколько редакторов, похоже, выступают за то, чтобы каждая статья [type] имела инфобокс, неважно какой, неважно насколько бессмысленный. В любом случае, ваш последний аргумент режет все пути - если мы доверяем усмотрению редактора, то почему бы не сказать ничего по WP:CREEP ? SnowFire ( обсуждение ) 05:41, 26 марта 2024 (UTC) [ ответ ]
« Эта идея о том, что инфобоксы будут втиснуты в небольшие статьи, кажется нелепой » Не так ли? Слишком много редакторов читают «рекомендовать» как «обязательно». Есть много, очень много небольших статей, в которые бездумно помещают IB (это была одна из них, до недавнего времени). Как только вы начинаете искажать формулировку в сторону «рекомендовать», то вы увидите множество пустого дерьма, раздутого дерьма и/или тривиального дерьма, помещенного туда, где его на самом деле не должно быть, просто потому, что люди не включают свои мозги и не задаются вопросом, почему они слепо что-то добавляют, или недостатки и изъяны своего редактирования. Уже слишком много не продумано, когда дело доходит до IB, но вы, кажется, по какой-то причине не хотите поощрять это. - SchroCat ( обсуждение ) 05:57, 26 марта 2024 (UTC) [ ответить ]
Похоже, вы не доверяете редакторам Википедии. Gawaon ( обсуждение ) 07:21, 26 марта 2024 (UTC) [ ответить ]
Не все из них, не все время. Для этого и нужна политика. Remsense诉07:24, 26 марта 2024 (UTC) [ ответить ]
Однако здесь аргумент, по-видимому, заключается в том, что более подробная и реалистичная (= соответствующая реальной практике) политика/руководство будут злоупотреблять редакторами, и поэтому лучше их не иметь. Это немного странно. Gawaon ( talk ) 07:42, 26 марта 2024 (UTC) [ ответить ]
Кажется, это часть разрыва: детали не выполняют никакой полезной функции. Настоящее руководство вполне адекватно в качестве политики , которая, по моему мнению, должна быть дидактической, прежде чем она станет описательной. Remsense诉07:50, 26 марта 2024 (UTC) [ ответить ]
Когда вы пробудете здесь некоторое время, вы оцените точку зрения. Хотя 99 процентов действуют очень добросовестно большую часть времени (но не всегда), не у всех есть возможность производить или оценивать качественный контент. Не все думают, прежде чем действовать, и многие воспринимают MOS как своего рода фетиш, которого нужно придерживаться, даже принимая «рекомендовать» за «настаивать на». - SchroCat ( обсуждение ) 08:10, 26 марта 2024 (UTC) [ ответить ]
Я не знал, что «Руководство по стилю» для некоторых людей — извращение (да, я знаю, что означает слово «фетиш» в данном контексте, это шутка) Dronebogus ( обсуждение ) 19:15, 29 марта 2024 (UTC) [ ответить ]
Противоположность , инструкция ползучести и по SnowFire. Инфобоксы особенно проблематичны для биографий художников. Джип Орландо ( обсуждение ) 13:59, 27 марта 2024 (UTC) [ ответить ]
Условная поддержка предлагаемый текст лучше, чем текущий, архаичный текст, но формулировка несовершенна. «события» и «люди» — слишком широкая классификация, чтобы рекомендовать инфобоксы. Второе предложение не должно пропагандировать боковые панели (а математика должна быть написана строчными буквами). «они не должны быть ни слишком короткими, ни слишком длинными» — это, пожалуй, самый бесполезный совет, который можно было бы дать. Оставшуюся часть второго абзаца можно было бы немного сократить. В остальном это хорошее предложение. Текущая политика часто удивляет новых пользователей, которые считают инфобоксы неотъемлемой частью того, чем является Википедия, и нуждается в пересмотре. Toadspike ( обсуждение ) 11:17, 30 марта 2024 (UTC) [ ответ ]
Oppose Для многих из наших субъектов мало что известно о многих полях инфобокса, а о других существует значительная неопределенность, иногда ожесточенные споры. К счастью, многие из них также не имеют значения (например, количество и имена братьев поэта, как правило, не имеют никакого отношения к значимости этого писателя). Но эти параметры остаются в дизайне инфобокса; заполненные, они в лучшем случае отвлекают и часто вводят читателя в заблуждение, не имеют источника, не являются резюме статьи или просто неверны, а оставленные пустыми, они являются ловушками и искушениями для полезных редакторов, часто новичков, стремящихся внести свой вклад в энциклопедию, сделав ее более полной и очень часто сосредоточенных на инфобоксах как на лучшем или самом легком вкладе, который они могут сделать. Если опытные редакторы с обширными списками наблюдения и знакомые с предметом возвращают их, как бы осторожно они это ни делали, мы все равно оставляем новых редакторов с обескураживающим первым опытом редактирования; Если ни один из активных редакторов не внес статью в список наблюдения и не преодолеет свою усталость от защиты энциклопедии, ошибки остаются, а деградация энциклопедии накапливается. Поощрение распространения инфобоксов с такими предложениями может активно навредить проекту создания Википедии.

Это не следует игнорировать как просто вопрос биографий из античности - классической Греции и Рима и тому подобного. Информация о многих известных исторических и даже ныне живущих людях скудна. Многие исторические измерения не могут быть преобразованы из-за нашего неполного знания единиц измерения; даже содержание и даты любых законов, регулирующих их, часто фрагментарны или отсутствуют. Для войн, сражений и военных кампаний часто нет четких записей или исторического консенсуса относительно размеров вовлеченных сил, военных или гражданских потерь, или даже если кто-то может сказать, что победил, тем не менее, полезные или предвзятые редакторы заполняют эти поля древними преувеличениями или изобретают свои собственные. О растении, от которого зависела экономика города, мы знаем мало, кроме названия и того, что оно вымерло. Численность населения и демография известны лишь смутно и во многом оспариваются на протяжении всего времени; даже современное число приверженцев различных религий и ни одной из них, в отдельных странах и во всем мире, является предметом многих информационных споров, основанных на малом количестве или отсутствии доказательств. Это лишь несколько примеров из моего опыта; другие редакторы могли бы добавить гораздо больше областей изучения. В целом, это вовсе не только "свободные искусства", для которых инфобоксы иногда неуместны; во многих отношениях, это случаи, когда инфобоксы уместны, которые гораздо более ограничены, чем признает это предложение. NebY ( talk ) 15:34, 31 марта 2024 (UTC) [ ответить ]

Oppose есть много статей о событиях, в которых инфобоксы неуместны, например, когда многие поля «спорные» или «неизвестные». Это не только проблема древней истории, суммирование причин войн/геноцидов в инфобоксах больше вводит в заблуждение, чем проясняет. ( t · c ) buidhe 06:04, 1 апреля 2024 (UTC) [ ответить ]
Умеренная поддержка. Как человек, не имеющий четкого мнения ни в одном из направлений по поводу инфобоксов, мне кажется, что это предложение отражает текущую практику и может помочь ограничить войны правок по поводу инфобоксов. Sandstein 07:36, 5 апреля 2024 (UTC) [ ответить ]

Oppose - согласно очень хорошим аргументам выше. Информационные поля хорошо работают в сложных темах, таких как астрономия, наука, спорт и армия. Практически везде они повторяющиеся, вводящие в заблуждение, неинформативные и открыты для злоупотреблений и раздувания. Я видел цифру в 50%, указанную выше, когда речь идет об уже существующих информационных полях, но я бы поспорил, что большинство из них несут бессмысленную, повторяющуюся информацию и существуют исключительно как результат токсичного обсуждения где-то. Cassianto ^Talk 08:08, 8 апреля 2024 (UTC) [ ответить ]
Oppose . Инфобоксы иногда хороши, а иногда плохи. Природа Википедии (энциклопедии!) такова, что невозможно указать правилом, выиграет ли данная статья от него (за исключением очень ограниченных классов статей, например, элементов). Большинство случаев очевидны (следовательно, устоявшаяся практика), но многие являются пограничными. Лучше оставить это для обсуждения в каждом конкретном случае. Srnec ( обсуждение ) 13:59, 10 апреля 2024 (UTC) [ ответить ]
Выступайте против людей по Кусме и SC. voorts ( обсуждение / вклады ) 20:28, 2 мая 2024 (UTC) [ ответить ]
Немного опоздали на вечеринку, не так ли? Dronebogus ( обсуждение ) 05:48, 3 мая 2024 (UTC) [ ответить ]
Я бы сказал нет, так как RFC все еще открыт, что для меня означает, что... RFC все еще открыт! Remsense06 : 49, 3 мая 2024 (UTC) [ ответить ]
RFC открыт, потому что ни один невовлеченный администратор не потрудился закрыть его. Большая часть активности полностью прекратилась месяц назад. Dronebogus ( обсуждение ) 12:45, 3 мая 2024 (UTC) [ ответить ]
Поддержка . Предложение соответствует практике сообщества в отношении инфобоксов. Текущая формулировка устарела. Tar nis hed Path ^talk 03:31, 22 мая 2024 (UTC) [ ответить ]

Было несколько комментариев, в которых ARBCOM упоминался как препятствие для этого предложения. Независимо от результата этого обсуждения, ARBCOM не запрещает сообществу создавать руководство по использованию инфобоксов для биографий или любой другой темы. Мы должны прислушаться к опытным закрывателям, таким как S Marshall, которые указали, что руководство было бы полезным. Фактически, в течение 18 месяцев или около того, что я наблюдаю за этой темой, администраторы/закрывающие неоднократно говорили, что руководство по инфобоксам является логичным следующим шагом для предотвращения будущих RFC по этой теме. - Nemov ( обсуждение ) 14:24, 16 марта 2024 (UTC) [ ответить ]
Немов… что не так с RFC? Blueboar ( обсуждение ) 14:55, 16 марта 2024 (UTC) [ ответить ]
Blueboar… в RFC по поводу инфобоксов много ошибок.
Во-первых, инфобоксы — это очень специфичные для Википедии вещи. Вы не можете ссылаться на источник, чтобы сказать, нужен ли инфобокс.
Во-вторых, нет никаких политик или руководств о том, иметь ли инфобокс. Все, что у нас есть, это дело Arbcom, а Arbcom не имеет юрисдикции в отношении решений о контенте.
В-третьих, я никогда не видел аргумента, связанного с инфобоксами, которому я мог бы придать больший вес из-за разума или логики. Они сводятся к: «Мне нравятся инфобоксы» (ILIKEIT); «Мне не нравятся инфобоксы» (IDONTLIKEIT); «Во многих других похожих статьях есть инфобоксы» или наоборот (OCE); «Мы обычно помещаем инфобоксы в такие статьи» или наоборот (OUTCOMESBASED); и «Инфобоксы помогают нашим читателям легко находить факты» или наоборот «Инфобоксы крадут внимание у прозы» (оба имеют свои собственные эссе, и ни один из них я не нахожу особенно убедительным).
Поэтому, как я уже заметил, любой RfC об инфобоксе — это просто прямой опрос. Вы считаете цифры с каждой стороны, вычитаете очевидные носки и получаете общую сумму. Вот и все.
Нам нужны некоторые решения сообщества, с которыми можно работать. Конкретные, ясные, пожалуйста. «Это зависит» совершенно бесполезно на практике. — S Marshall T / C 21:58, 16 марта 2024 (UTC) [ ответить ]
Честно говоря, мы немного застряли, потому что, как вы сказали, это специфическая для вики конструкция, но она требует от нас возможности выносить собственные редакционные суждения о том, что важно, в том смысле, в котором WP:NPOV обычно не позволяет нам этого делать. Мы не можем отражать большой мир, если его нет. Я согласен жить с этим в рамках статус-кво, но я понимаю, что это продолжит вызывать проблемы. Remsense诉22:03, 16 марта 2024 (UTC) [ ответить ]
Я понимаю, что наличие «правила», которое было бы более определенным, чем «зависит… решайте на уровне статьи» , облегчило бы жизнь администраторам и закрывающим… но я не думаю, что это было бы лучше для самих статей (и это всегда должно быть целью политики, даже если это усложняет жизнь закулисным чудакам). Blueboar ( обсуждение ) 12:53, 17 марта 2024 (UTC) [ ответить ]
Я думаю, что «польза» для статей здесь незначительна, если не отсутствует, поскольку в большинстве случаев это просто приводит к тому, что инфобокс считается улучшением. Так что наличие правила, скорее всего, в конечном итоге поможет и статьям , и «закулисным чудакам». Dronebogus ( обсуждение ) 21:11, 17 марта 2024 (UTC) [ ответить ]
@ S Marshall , интересно, как, по-вашему, должна звучать идеальная причина для поддержки или противодействия инфобоксу. Вы надеетесь, что редакторы скажут что-то вроде: « doi :10.1177/1464884914545739 говорит, что инфобоксы «обеспечивают читабельность и быструю ссылку» на новостные события, и все истинные википедисты поддерживают читабельность и использование Википедии в качестве быстрой ссылки, поэтому, конечно, я думаю, что эта статья, связанная с новостным событием, должна иметь инфобокс»? Это более убедительно, чем «Основываясь на моем опыте, я думаю, что инфобокс был бы типичным и подходящим для этой статьи» или «Да, давайте сделаем инфобокс для людей, которые просто хотят найти базовый факт, особенно если они не являются носителями английского языка»? WhatamIdoing ( talk ) 05:40, 18 марта 2024 (UTC) [ reply ]
Я представляю себе счастливый мир, в котором у меня есть руководство, которое говорит что-то вроде предложения Вугаподеса, чтобы я мог оценивать !votes, говоря «Поддержка: соответствует WP:INFOBOXCRITERION#3». :) Я хочу, чтобы сообщество сказало мне, следует ли придавать больший вес тем, кто активно редактировал статью, и меньший вес тем, кто этого не делал; или же взвешивать всех википедистов одинаково. Мне все равно, что именно. В еще более идеальном будущем руководство могло бы подсказать мне, что делать, когда спорным является только один параметр инфобокса (что является предметом спора во многих RFC). Потому что я не придаю ни одному из этих примеров на три представления больше веса. — S Marshall T / C 07:41, 18 марта 2024 (UTC) [ ответить ]
Похоже, вы ищете заранее одобренные причины (похожие на «мы удаляем скопированные материалы» или «мы включаем в статью только те изображения, которые имеют образовательную ценность»), а мы предлагаем вам только тех редакторов, которые руководствуются здравым смыслом и здравым смыслом.
Я не уверен, есть ли у нас общее правило о том, чтобы придавать больший вес тем, кто активно редактировал статью, и меньший вес тем, кто этого не делал. WP:OWN предлагает, чтобы все редакторы были равны, и как только спор достигнет стадии RFC, возможно, мы отдадим приоритет мнениям невовлеченных редакторов. WhatamIdoing ( обсуждение ) 22:41, 23 марта 2024 (UTC) [ ответ ]
Я думаю, что существуют люди, которые имеют твердые взгляды на инфобоксы и приходят к RFC по статьям, которые они никогда не редактировали, чтобы !проголосовать или против включения инфобокса. Некоторые из них всегда !голосуют только одним способом. Возможно, это совершенно беспроблемное поведение, и я действительно должен придать этим людям больший вес, чем тем, кто трудился над статьей; но, также, возможно, нет? — S Marshall T / C 17:20, 24 марта 2024 (UTC) [ ответить ]
Это сложно. Мы не хотим отговаривать основных авторов статьи, но мы также не хотим позволять им переопределять взгляды остального сообщества. Но мы могли бы с тем же успехом сказать: «Некоторые из этих основных авторов никогда не добавляют инфобокс ни в одну статью, которую они пишут. Возможно, это совершенно беспроблемное поведение...»
Подходим ли мы к этому с точки зрения того, что инфобоксы действительно должны быть 50/50 в каждой общей предметной области? Действительно верно, что Template:Infobox человек с одинаковой вероятностью может быть желательным или нежелательным для случайно выбранной группы статей о людях? Я вытащил 10 страниц в статьях Special:RandomInCategory/WikiProject Biography . Восемь из них имели инфобоксы. Двое, у которых их не было, были Констанс Баррелл и Бен Фи — оба мертвы, и ни у одного из них нет фотографий субъекта.
Я обеспокоен тем, что мы сами себя загнали в состояние беспомощности и заламывания рук. «Это просто безнадежно – мы никогда не сможем решить, следует ли вставлять инфобокс в статью. Нам следует сдаться сейчас, потому что ни один совет или обоснование не могут быть обоснованными или лучше подбрасывания монетки». Дело в том, что игровое поле неровное; оно, по-видимому, сильно склоняется в сторону включения инфобоксов в большинство статей (например, большинство из двух миллионов статей о людях, почти все статьи о видах, но не в списки или статьи, для которых нет подходящего инфобокса [например, математика или философия – они, как правило, получают навигационные блоки в боковой панели]). В последний раз, когда RFC (или любое объявленное обсуждение) заканчивалось консенсусом против инфобокса, было так давно, что никто этого не помнит. У нас есть решение на практике. Редакторы голосуют ногами, и они голосуют за то, чтобы вставлять инфобоксы почти во все статьи. WhatamIdoing ( обсуждение ) 18:18, 25 марта 2024 (UTC) [ ответить ]
Я думаю, что нынешние обычаи и практика выглядят следующим образом:
Если наша статья о чем-то в основном неизменном с кучей количественных данных, например, о химическом элементе или соединении, железнодорожной станции или лекарстве, то инфобокс невероятно полезен, совершенно бесспорен и также, часто, абсолютно огромен. Никто не спорит об этих инфобоксах, и мне не нужны никакие указания по ним.
Если наша статья о чем-то с некоторыми количественными данными, но также и о некоторых вещах, которые могут различаться в разных источниках, поскольку они меняются со временем, например, о болезни, железнодорожной станции или национальном государстве, то infobox, скорее всего, полезен и в основном бесспорен, но требует регулярного обновления. В таких случаях один или несколько параметров infobox могут быть вопросом мнения, но мнения исходят от экспертов в данной области и передаются из надежных источников. Эти infobox полезны и в основном бесспорны. Мне не нужны никакие указания по ним.
Если наша статья относится к сфере деятельности WikiProject Mathematics, то в ней нет информационного поля, никакого полезного информационного поля придумать нельзя, никто не спорит, и мне не нужны никакие указания по этому поводу.
Если наша статья касается чего-то, не имеющего вообще количественных данных, а чисто вопросов мнения, и вам не нужна ученость, чтобы иметь мнение — здесь я думаю, например, о параметре жанра {{ Infobox song }} и {{ Infobox album }} — тогда вы получаете конфликт, потому что разные редакторы хотят опираться на разные источники, чтобы говорить разные вещи. В этом отношении я бы лично выиграл от некоторых параметров от сообщества, с которыми можно было бы работать, и наличие таких параметров помогло бы уменьшить трения и управлять спорами между редакторами до того, как мы дойдем до стадии RfC.
Если это что-то спорное и националистическое, то, конечно, это огромная проблема. Удивительно, как много RfC сводятся к «кто выиграл эту битву?» и «каковы точные цифры потерь?» с противоречивыми источниками с каждой стороны. По моему опыту, {{ Infobox военный конфликт }} невероятно чреват, гораздо более, чем {{ Infobox военный человек }} и {{ Infobox военная единица }} . (У нас есть редакторы, которые искренне считают, что сторона, удерживающая спорную территорию в конце битвы, является победителем, независимо от потерь и приказов командира другой стороны.) И, да, я посылаю в небо сигнал бэтмену сообществу, чтобы сказать: «Помогите!» Если это беспомощность, вырывающая руки, тогда ладно, я буду здесь вырывать руки.
Я знаю, я частично говорю о том, следует ли решать или удалять спорные параметры инфобокса, а не о том, следует ли нам вообще иметь инфобокс. Надеюсь, мы работаем над правилами и по этому поводу.
В какой-то степени наличие инфобокса — это отчасти стилистическое предпочтение. Мы позволяем предпочтениям автора статьи решать стилистические вопросы, например, в таких вопросах, как даты ENGVAR или DD-MM-YY или что-то еще.— S Marshall T / C 00:54, 26 марта 2024 (UTC) [ ответить ]
Можете ли вы привести пример темы, которая «касается чего-то, не имеющего количественных данных, а чисто вопросов мнения», и для которой у нас есть соответствующий инфобокс? Это не будет что-то вроде {{ infobox album }} , поскольку эти статьи включают в себя довольно много количественных данных (например, концертный ли это или студийный альбом, даты выпуска, место записи, продолжительность, имена различных людей и компаний, вовлеченных в него — по сути, единственное , что может быть оспорено, это музыкальный жанр, и это может быть оспорено только в узком диапазоне. Люди могут спорить о том, является ли альбом глэм-роком или арт-роком [два тесно связанных жанра], но никто не будет утверждать, что его лучше всего описать как фолк-музыку, или классическую индийскую музыку, или плавный джаз). WhatamIdoing ( talk ) 02:05, 26 марта 2024 (UTC) [ ответить ]
Классическая индийская музыка? В моем роке? Это более вероятно, чем вы думаете! Dronebogus ( обсуждение ) 05:50, 26 марта 2024 (UTC) [ ответить ]
Примерами, где все количественные данные являются вопросами мнения, могут быть исторические личности и часто исторические сражения. Например, Херевард Уэйк , чья жизнь засвидетельствована источниками, появившимися намного позже, которые расходятся во всех деталях. Анализируя этот инфобокс, можно сказать, что он состоит из его «имени», которое буквально означает «Бдительный армейский страж» и почти наверняка является когноменом; изображения, взятого из источника, датированного восемью с половиной веками позже, и изображающего людей, сражающихся с оружием, щитами и доспехами, которые совершенно не соответствуют времени и месту; его очень приблизительного года рождения, который является не более чем наилучшим предположением; его предполагаемого округа рождения, который не указан, сомнителен и, как отмечает SchroCat, на самом деле не был основан, когда он родился; его очень приблизительного года смерти, который является не более чем наилучшим предположением; его заявленных «других имен», которые также являются когноменами; и его «движения», историчность которого трудно установить.
Но этот инфобокс не был местом спора, и на самом деле те, с которыми я надеялся на помощь, обычно были там, где оспариваются только некоторые параметры. Я знаю, что это не совсем то, что поднял Вугаподс, но у нас есть много людей, думающих о политике, которые собрались вместе, чтобы подумать об инфобоксах. Когда есть настоящий конфликт между источниками, когда лучше заполнить спорный параметр чем-то вроде «см. текст», а когда лучше оставить его пустым? Примечание: на этот вопрос есть различные ответы в неясных местах, но я не уверен, в какой степени ответы отражают консенсус редакторов, которые думают об инфобоксах. Например, в Шаблон:Инфобокс военный конфликт/док#Использование говорится, что информация в инфобоксе не должна быть «спорной». Отошлите читателя к соответствующему разделу в статье или оставьте параметр пустым, вместо того чтобы делать необоснованные или сомнительные заявления. Но, например, во всей этой огромной суете о том, кто выиграл битву при Чавинде, вряд ли кто-то подумал, что нам следует оставить параметр пустым. — S Marshall T / C 09:18, 26 марта 2024 (UTC) [ ответить ]

Я не думаю , что добавление нового предложения на данном этапе — хорошая идея, особенно нового предложения, настолько отличающегося от первого. — LCU Активно Неинтересно « @ » ° ∆t ° 09:28 , 17 марта 2024 (UTC) [ ответить ]

Новое предложение

Предлагаемая формулировка: «Решение о том, включать ли в статью инфобокс или нет, должно приниматься редакторами, которые регулярно редактируют и поддерживают статью». -- Ssilvers ( обсуждение ) 01:55, 17 марта 2024 (UTC) [ ответить ]

Я перенес это в раздел комментариев из раздела «обсуждение», поскольку это не то, что люди обсуждали, и представлять это так, как будто это то, что обсуждается, сбивает с толку. — Wug· a·po·des 23:35, 21 марта 2024 (UTC) [ ответить ]

ВП:СНЕГзакрытие?

Я думаю, совершенно очевидно, что это никогда не получит достаточно широкого консенсуса для принятия. Что еще важнее, я не думаю, что это что-то решает — большинство статей с инфобоксами по сути не являются спорными (так что нет необходимости в руководстве по этому поводу), и, по моему мнению, спорные статьи связаны не с достоинствами самих инфобоксов, а скорее с предпочтениями наиболее известных редакторов. Я думаю, что это проблема, но этот жесткий подход явно не является решением. Dronebogus ( обсуждение ) 00:39, 21 марта 2024 (UTC) [ ответить ]

Нет. Может быть, консенсуса не будет, может быть, будет некий частичный консенсус для более скромного пересмотра, но пока рано говорить, пока обсуждение не завершится. Кроме того, «я не думаю, что это что-то решает» по сути означает «мне это не нравится», что, безусловно, НЕ является аргументом в пользу раннего закрытия (хотя это может быть или стать аргументом против предложения). Gawaon ( talk ) 06:21, 21 марта 2024 (UTC) [ ответить ]

Если бы я закрывал это, что, очевидно, не будет сделано, то в моем заключительном заявлении было бы отмечено, что все широкие !голоса до сих пор поддерживают или выступают против инфобоксов в целом, а все узкие !голоса касаются инфобоксов в биографиях. Я думаю, мы многому учимся.— S Marshall T / C 10:43, 25 марта 2024 (UTC) [ ответить ]

S Marshall . Я думаю, что это, возможно, будет неправильным выводом (я могу это сказать, потому что вы не закрываете!). Просматривая, можно заметить, что очень мало людей выступают против IB в целом , что подтверждается и моим опытом более широких обсуждений. «Точки защемления» находятся в конкретных областях, где есть проблемы. Разногласия (из этого обсуждения), похоже, касаются размера статьи, отсутствия достаточного количества ключевых моментов информации и определенных типов биографий. Люди, занимающие «звания» (политики, священнослужители, военные и т. д.), довольно неконфликтны (потому что этапы их карьеры можно перечислить в рамке); аналогично, спортсмены всех типов не вызывают проблем (спортивная статистика, членство в клубах и выступления на чемпионатах, кубках, олимпиадах и т. д. также могут суммировать этапы и достижения личности). Проблема (насколько я с ней сталкивался) касается гуманитарных наук, где карьера не определяется статистической разбивкой, которая может быть помещена в рамку. Для статей по гуманитарным наукам поле придает слишком большой ВЕСА мелочам. Таково мое мнение об этом обсуждении и некоторых более широких дебатах. - SchroCat ( обсуждение ) 11:01, 25 марта 2024 (UTC) [ ответить ]

Я думаю, что это больше, чем «звания» или «спортсмены», потому что это также, кажется, зависит от того, является ли человек историческим, и если да, то из какого периода. Есть пользователи, спорящие об этом выше, но это также верно на практике: из моего краткого взгляда на историю, я думаю, что никто никогда не пытался добавить {{ infobox noble }} к Lady Godiva . Интересно, что ее возможный сын Hereward the Wake берет {{ infobox person }} , в котором все параметры довольно расплывчаты, что, я думаю, подтверждает предположение о том, что наша практика непоследовательна в зависимости от того, кто редактировал статью.— S Marshall T / C 11:44, 25 марта 2024 (UTC) [ ответить ]

Я не уверен, что непоследовательная практика является проблемой, особенно когда Херевард указан в современном округе, которого не существовало. В более широком смысле, да, я думал о более поздних биографиях, которые я видел, а не о тех, что были из древности, где проблем еще больше. Я не знаю, почему биографии были включены в первоначальное предложение: в теме слишком много глубоко укоренившихся проблем для универсального правила. - SchroCat ( обсуждение ) 12:05, 25 марта 2024 (UTC) [ ответить ]

Согласен, что непоследовательная практика не является проблемой на данный момент. Предвидимо, если сообщество действительно придет к Соглашению об инфобоксах 2024, могут быть попытки упорядочить его, что может привести к большому объему работы для замыкающих RfC.— S Marshall T / C 12:14, 25 марта 2024 (UTC) [ ответить ]

Другие возможные подходы

Несколько человек сказали, что было бы хорошо иметь правило, которое уменьшило бы или устранило конфликты по поводу инфобоксов в отдельных статьях. Я также симпатизирую запросу S Marshall на руководство по закрытию RfC. Этот RfC пытается решить эти проблемы, установив правило; я не думаю, что оно будет принято, но проблемы остаются, поэтому я хотел получить представление о том, какие другие подходы могут получить поддержку. Идеи (некоторые из них упомянуты выше) включают:

Найдите другую формулировку RfC, которая могла бы получить консенсус для глобального стандарта, как это пытается сделать этот RfC. Несколько оппонентов сказали «против в черновом варианте», подразумевая, что другая версия может получить больше поддержки.
Придайте дополнительный вес в RfC мнению редакторов, которые активно редактировали страницу до RfC. Это может варьироваться от «Следует консультироваться только с активными редакторами» до «Если нет четкого консенсуса, то только тогда мнениям активных редакторов придается дополнительный вес». Первое из них было бы эквивалентно наличию INFOBOXVAR. Это правило, как правило, работает в пользу редакторов, выступающих против инфобокса, поскольку редко бывает так, что инфобокс есть в статье, и кто-то приходит и пытается его удалить.
Для GA и FA придайте дополнительный вес состоянию статьи на момент продвижения. Оправданием может служить тот факт, что несколько глаз просмотрели статью и согласились, что она приемлема с инфобоксом или без него. Это будет применяться в большей степени для FA, поскольку для FA больше рецензентов. Это правило также будет работать в пользу редакторов, выступающих против инфобокса, по той же причине, что и выше.
Разрешить требования согласованности на уровне проекта. Есть некоторые случаи, где (насколько я знаю) это не будет спорным — элементы, живые существа, дороги, вероятно, десятки других. Это всегда будет работать в пользу инфобоксов, но я не думаю, что это поможет, потому что даже если это не противоречит LOCALCONSENSUS, проблема не в элементах и дорогах, и в этих случаях уже есть фактический консенсус, который не нужно кодифицировать.
Ограничьте количество RfC в инфобоксах некоторыми способами. Я видел предложения, что редактору X следует разрешить начинать только определенное количество в год, или разрешить голосовать только за определенное количество в год, или что их не следует широко рекламировать. Я думаю, что это было бы бюрократическим кошмаром для полиции, хотя я могу понять, откуда исходит это предложение.

У меня есть некоторый скептицизм по поводу каждого из них, но проблема аргументов infobox никуда не денется. Можно ли что-то из этого подправить, чтобы сделать приемлемым? Есть ли другие идеи, которые можно попробовать? Майк Кристи ( обсуждение - вклад - библиотека ) 18:33, 21 марта 2024 (UTC) [ ответить ]

Я бы выступил против 2, 3, поскольку это похоже на попытки не допустить нарушения RFC WP:LOCALCONSENSUS . Как вы отметили, 5 будет кошмаром для исполнения и, вероятно, не принесет много пользы. Лучший аргумент против изменения политики заключается в том, что со временем подавляющее большинство этих разногласий прекратятся, потому что большинство RFC заканчиваются включением. Я не проверял, но не может быть многих из этих больших биографий, в которых больше нет инфобоксов. Я уверен, что найдутся редакторы, готовые спорить об этом вечно, но в конечном итоге этот бассейн иссякнет. Nemov ( talk ) 19:02, 21 марта 2024 (UTC) [ ответить ]

Я бы поддержал 2 и 5. Я бы выступил против 3, особенно для GAs -- Ssilvers ( обсуждение ) 19:14, 21 марта 2024 (UTC) [ ответ ]

1. На данный момент я нейтрален (конечно, это будет зависеть от формулировки), хотя, скорее всего, это будет так же WP:CREEPy, как и основное предложение выше. Зачем нужен список для тех областей, которые не являются спорными? Это просто бессмысленное изменение ради изменения, которое не повлияет ни на кого и ни на что. Для областей, которые являются спорными, они спорны, потому что у людей есть веские обоснования, почему список тривиальных фактоидов, подходящий всем, не подходит для этой конкретной статьи. Вот почему нет групп людей, которые массово удаляют ящики, потому что каждую статью нужно оценивать по ее достоинствам, а не по спонтанному выбору, основанному на незнании предмета. Я бы, возможно, поддержал 2, в зависимости от формулировки (как я уже сказал выше, большинство проблем возникает из-за того, что «люди, не имеющие никакого интереса к предмету, спускаются до того, чтобы требовать ящик «просто так», без каких-либо реальных мыслей или обоснований за этим»). Три я бы поддержал, если бы это не включало GA: помимо того, что они бывают разного качества, я видел, как один рецензент GA почти запугивал кого-то, чтобы тот получил IB во время обзора GA. Четыре, я думаю, перенесли бы нарушение на уровень проекта — и как вы контролируете, кто участвует в том или ином проекте? Это все еще не решает проблему тех статей, которые не подходят для IB. Пять я бы, возможно, поддержал, но согласен, что это было бы обременительно для контроля. Однако, если бы это прекратило некоторые повторения тех же цифр, появляющихся в статьях, которые они никогда раньше не редактировали и которые им не интересны, это, безусловно, стоило бы рассмотреть. - SchroCat ( обсуждение ) 20:31, 21 марта 2024 (UTC) [ ответить ]

Я думаю, что 1 — это лучший вариант на сегодняшний день, и это часть того, почему я считаю это обсуждение ценным независимо от конечного результата. Часть проблемы, которую я видел, заключается в том, что большинство аргументов относительно инфобоксов, как правило, были разбросаны по RfC, охватывающим годы, и в нестандартных местах. Даже когда я пытался получить полный список, это обсуждение в масштабе проекта указало на то, что все еще были некоторые, которые я упустил, несмотря на все мои усилия. Действительно трудно составить хорошее руководство, когда мнения настолько разбросаны, еще труднее, когда обсуждение в масштабе проекта рассматривается как принятие стороны. Лично я думаю, что в обоснованиях говорится совсем другое, чем в выделенных жирным !votes. Примечание о заглушках было встречено с подозрением, хотя ряд редакторов указывают на проблемы с короткими статьями. Другие не согласны с инфобоксами, которые являются пересказом лида, и это, как правило, хорошо сочетается с точкой зрения о коротких статьях. С другой стороны, есть некоторые аргументы, что для определенных тем (биологические таксоны были приведены в качестве одного из примеров) эта проблема не является такой уж большой проблемой. Это, кажется, связано с подобсуждением тем, хорошо подходящих для «структурированных данных». Таким образом, хотя «заглушки» (как в предложении), вероятно, не найдут консенсуса, поскольку они чрезмерно упрощают эти проблемы, в обсуждении есть связные нити, которые, как я думаю, могли бы привести к руководству, особенно если бы процесс составления был более чем одним парнем, читающим RfC за два года и выдвигающим идею. — Wug· a·po·des 00:00, 22 марта 2024 (UTC) [ ответить ]

Я тоже думаю, что если первоначальное предложение не достигнет консенсуса, то вариант 1 — лучшая альтернатива для реализации. Gawaon ( talk ) 07:22, 22 марта 2024 (UTC) [ ответить ]

Вариант 1 на самом деле не является предложением. Единственный способ получить достаточную поддержку — убедить редакторов, которые не считают, что есть проблема, или людей, которые думают, что это CREEP. Это будет трудно осуществить, поскольку есть значительный блок, который будет бороться с этим. Первый голос против здесь был обвинен в агитации за предложение с самого начала. Это жесткая толпа. Немов ( обсуждение ) 12:55, 22 марта 2024 (UTC) [ ответить ]

И один из сторонников был достаточно невежлив, чтобы описать людей как «кучку могущественных оппозиционеров» просто за то, что у них другое мнение. О чем вы? Учитывая, что мы говорим о небольшой части статей, и учитывая, что большинство людей в целом согласны с тем, что большинство IB работают в большинстве областей (в общем и целом), почему нужно менять формулировку? - SchroCat ( обсуждение ) 13:15, 22 марта 2024 (UTC) [ ответить ]

Потому что, как в частности отметил С. Маршалл, на самом деле закрывать обсуждения по спорным случаям сложнее, когда наши политики и руководящие принципы делают вид, что на самом деле нет никаких указаний, которые можно было бы дать. Если мы посмотрим на обсуждения за последние 2 года, а также на мнения в этом обсуждении, есть соображения , которые имеют широкое согласие, но поскольку мы не документируем это, закрывающим нужно либо быть знакомыми с годами прецедентов (чтобы иметь представление о линиях аргументации, которые постоянно возникают в этих дебатах), либо считать головы (придавая всем равный вес, поскольку политика гласит, что это бесплатно для всех). Первое означает, что решения являются произвольными в зависимости от того, какой вид закрытия вы получаете для этого конкретного RfC, а второе означает, что мы вознаграждаем редакторов, которые используют тактику обструкции или обструкции, пока они не получат нужную явку для своего предпочтительного результата. Хотя тематическая область может быть небольшой, проведение RfC каждые несколько месяцев, чтобы увидеть, какая фракция появляется больше всего или какой закрытие мы получим в этот раз, отнимает непропорционально много времени у других волонтеров. — Wug· a·po·des 20:35, 22 марта 2024 (UTC) [ ответить ]

Затем наложите мораторий на открытие RfC на IB. Остановите ту же группу редакторов, которые не заинтересованы в предмете, но появляются и нарушают и оскорбляют, независимо от того, какая это статья. Вот где начинается и продолжается разрушение: продолжающийся крестовый поход небольшой группы, чтобы продолжать давить, давить и давить. - SchroCat ( обсуждение ) 20:47, 22 марта 2024 (UTC) [ ответить ]

Также существует продолжающийся крестовый поход небольшой группы за сохранение статус-кво, в котором вы, несомненно, являетесь самым активным участником. Не называйте чайник черным . Dronebogus ( обсуждение ) 02:36, 24 марта 2024 (UTC) [ ответить ]

О, боже мой. Крестовый поход — это действие ради перемен , а не сохранения качества. - SchroCat ( обсуждение ) 06:35, 24 марта 2024 (UTC) [ ответить ]

Я знаю о педантичном определении «крестового похода», я пытался провести риторическую параллель. Каков обратный эквивалент крестового похода? Dronebogus ( talk ) 06:54, 24 марта 2024 (UTC) [ ответить ]

Это не педантизм, это просто стандарты. Если бы люди были в «крестовом походе», это включало бы массовое удаление IB, чего не происходит, даже в самых смехотворных случаях , потому что кто-то обычно возвращается, несмотря на то, насколько нелепым на самом деле является ящик. (Если вы хотите найти слово или правильное значение on, словарь или тезаурус будут идеальными компаньонами: я рекомендую их вам.) - SchroCat ( обсуждение ) 07:15, 24 марта 2024 (UTC) [ ответить ]

Я удалил это; я думаю, что инфобокс с нулевыми параметрами в использовании и без доступных данных, кроме «оккупации», объективно бесполезен и в этом случае создал стену хлама в коде. Так что да, даже я думаю, что инфобоксы, которые не могут предоставить никакой информации, бесполезны. Dronebogus ( talk ) 07:34, 24 марта 2024 (UTC) [ ответить ]

1 кажется очевидным и, что более важно, разумным . 2 по сути « WP:OWNership хорош», 3 не имеет никакого смысла (почему GA, которые являются просто статьями качества выше среднего, а не FA, которые являются наивысшим стандартом, которым может быть статья? И даже тогда что такого замечательного в произвольном статус-кво, кроме «кто-то, должно быть, лучше всех знал при рецензировании»?), 4 просто закрепляет проблемы балканизации, о которых я упоминал в основном обсуждении, а 5 в предложении заявлено как «бюрократический кошмар», поэтому текущее предложение изначально и терпит крах. Dronebogus ( обсуждение ) 12:26, 22 марта 2024 (UTC) [ ответить ]

Я выступаю против пункта 4, как не соответствующего руководству Wikipedia:Advice pages – руководству, которое существует, потому что всем надоели заявления составителей WikiProject, что они исключительно отвечают за решение, можно ли добавлять инфобоксы в «их» статьи. Обсуждение Wikipedia:WikiProject Composers/Infoboxes RfC привел к соглашению о том, что они не владеют статьями и не могут настаивать на том, чтобы другие редакторы придерживались предпочтений их группы, хотя их члены были и остаются свободны приводить убедительные аргументы против дезинформационных блоков (заключительное резюме для RFC находится в конце страницы; см., например, «WikiProjects могут свободно публиковать руководства и рекомендации, но не имеют полномочий переопределять локальный консенсус на странице обсуждения статьи») .

Еще до этого в политике Wikipedia:Consensus говорилось следующее: «Решения, принятые в конкретных случаях на основе консенсуса, автоматически не отменяют консенсус в более широком масштабе — например, локальные дебаты в WikiProject не отменяют более широкий консенсус, лежащий в основе политики или руководства. WikiProject не может принять решение о том, что для статей, входящих в его сферу действия, некоторая политика не применяется, если только они не убедят более широкое сообщество в том, что это правильно».

Мы не должны отступать в этом вопросе. Самоизбранные, самоназначенные группы редакторов не могут устанавливать правила, влияющие на кого-либо еще. WhatamIdoing ( обсуждение ) 23:03, 23 марта 2024 (UTC) [ ответить ]

Кажется , что большинство композиторов WikiProject: (или, по крайней мере, их голосующее большинство) все еще думают так, несмотря на то, что их способность осуществлять такую власть ограничена. WProject Gilbert and Sullivan в этом отношении еще хуже. По крайней мере, Wproject Opera, похоже, вступила в современную эпоху. Dronebogus ( обсуждение ) 02:43, 24 марта 2024 (UTC) [ ответить ]

О, я думал, что «Самостоятельно избранные, самоназначенные группы редакторов не могут устанавливать правила, влияющие на кого-либо еще» относится к вам и вашим приятелям в Discord. Johnbod ( обсуждение ) 02:54, 24 марта 2024 (UTC) [ ответить ]

Я даже не прикасался к Discord ни разу в своей жизни. Dronebogus ( обсуждение ) 02:57, 24 марта 2024 (UTC) [ ответить ]

WhatamIdoing , вы говорите: «Самостоятельно избранные, самоназначенные группы редакторов не могут устанавливать правила, влияющие на кого-либо еще», и это, безусловно, верно, и я согласен, что это означает, что вариант 4 выше невозможен. Я думаю, однако, что различные правила VAR и RETAIN можно считать исключением из того, что вы говорите, — возможно, поэтому некоторые редакторы их не любят. Эти правила ясно дают понять, что они не предоставляют «неоспоримого первенства» ранним версиям статьи, но на практике для активно поддерживаемой статьи VAR и RETAIN рассматриваются как правила, которым нужно следовать. Это означает, что когда происходит RfC по стилю статьи, большинство внешних мнений !проголосуют за продолжение исходного стиля, если они считают, что RETAIN применим. Любое правило, которое предотвращает споры по поводу инфобоксов, вероятно, должно выглядеть как INFOBOXVAR (т. е. 2 или 3 выше) или глобальное правило, всегда включающее инфобоксы в определенные классы статей. Это не обязательно аргумент в пользу создания любого из правил. Вместо этого я бы сказал, что мы должны решить, чего хотим: если мы не выберем ни правило 2/3, ни консенсус о том, чтобы всегда включать инфобоксы, мы не должны удивляться, если аргументы продолжат поглощать время редактора. Я не думаю, что вариант 1 выше имеет много шансов быть достаточно точным, чтобы разрешить аргументы, и это единственная причина, которую я могу придумать для добавления дополнительных правил в этой области. Майк Кристи ( talk - contribs - library ) 13:09, 25 марта 2024 (UTC) [ ответить ]

Я думаю, что мы могли бы предложить/рекомендовать "следовать шаблону, используемому в статьях со схожими темами". Мы просто не можем иметь тот, который говорит "WikiProject Getting My Way решает, получит ли вся эта предметная область инфобоксы".

В конечном итоге мы придем к тому, что инфобоксы станут стандартным, нормальным, ожидаемым и дефолтным (но не обязательным) элементом. Единственный вопрос в том, как долго мы будем этому сопротивляться. Я только что проверил 20 последних статей в Special:NewPages . 85% из них уже содержат инфобоксы. Самой старой из них чуть больше часа. Три, которые не содержат инфобоксов (пока), — это два BLP athletes и одно televisions show. Я реалистично ожидаю, что Template:Infobox sportsperson и Template:Infobox television будут добавлены, как только любой заинтересованный редактор заметит упущение.

Если мы хотим, чтобы редакторы не тратили время на споры по этому поводу, то, я думаю, нужно признать, что инфобоксы уже существуют в более чем половине статей и будут добавляться еще больше со временем. Дискуссии могут быть пустой тратой времени, но приведенные выше доказательства указывают на то, что они никогда не заканчиваются настоящим консенсусом по исключению инфобокса. Возможно, способ решить эту проблему — перестать сопротивляться инфобоксам. Это проигрышная война. WhatamIdoing ( talk ) 17:48, 25 марта 2024 (UTC) [ ответить ]

85% из них содержали инфобоксы в течение первого часа, а двое из оставшихся трех подобрали инфобоксы вскоре после этого. WhatamIdoing ( talk ) 23:52, 25 марта 2024 (UTC) [ ответить ]

Я не думаю, что это случай «сопротивления» инфобоксам в целом, это скорее случай возражения против инфобоксов в конкретных статьях. Это правда, что инфобоксы полезны и уместны в большинстве статей. НО… мы никогда не избавимся от всех споров, потому что также верно, что есть несколько статей, где наличие инфобокса вызывает проблемы (проблемы, которые решаются простым пропуском инфобокса). Пока руководство позволяет нам пропускать, когда есть консенсус об пропуске , я не думаю, что многие будут возражать против заявления, в котором говорится, что они считаются уместными в большинстве статей. Один размер подходит большинству… просто не всем. Blueboar ( обсуждение ) 00:14, 26 марта 2024 (UTC) [ ответить ]

Я бы тоже не хотел видеть инфобокс в каждой статье. Однако я думаю, что у нас есть меньшинство редакторов, которые категорически возражают против того, что они считают Wikipedia:Disinfoboxes , и которые, как я ожидаю, будут возражать против любых изменений, которые могут затруднить для них исключение инфобоксов из статей, которые им интересны. Даже что-то вроде «Инфобоксы считаются уместными в большинстве статей» или чисто фактическое и неоспоримо верное утверждение, например «По состоянию на 2024 год инфобоксы присутствуют в большинстве статей» может затруднить для них «сопротивление» «вторжению» инфобоксов в оставшееся меньшинство. WhatamIdoing ( talk ) 02:11, 26 марта 2024 (UTC) [ ответить ]

Но « По состоянию на 2024 год инфобоксы присутствуют в большинстве статей » было бы ложью. Вы не можете утверждать в MOS что-то, что не является правдой, не говоря уже о том, что это не «бесспорно правда». Согласно цифрам в верхней части этой ветки, это 45 процентов, что не является большинством, несмотря на вашу статистически незначимую выборку из десяти статей. (Из последних 20 страниц, которые я проверил, семь не имели IB, включая ЧЕТЫРЕ биографии.) - SchroCat ( обсуждение ) 04:12, 26 марта 2024 (UTC) [ ответить ]

Вы их написали, или это были заглушки, или и то, и другое? Dronebogus ( обсуждение ) 19:38, 29 марта 2024 (UTC) [ ответить ]

Новые идеи проекта

Вариант 1 гласит, что следует разработать новое предложение для улучшения текущего RfC. Но в настоящее время нет даже приблизительного плана того, как это может выглядеть. Есть идеи? Мои личные предложения заключаются в том, чтобы квалифицировать биографии, как правило, с инфобоксами, если у них есть дата рождения и дата смерти (поскольку инфобоксы являются устоявшимся и эффективным форматом для предоставления «текущего возраста/возраста на момент смерти» благодаря шаблонам автоматического расчета), или по крайней мере трех непротиворечивых параметров в общей сложности (что является хорошей метрикой для «полезно ли это?», аналогично минимуму «три источника» для известности). Dronebogus ( обсуждение ) 07:50, 24 марта 2024 (UTC) [ ответ ]

Или вообще исключить биографии как спорную область и использовать формулировку, которая отражает, что в некоторых областях (например, в кино) они считаются нормой. - SchroCat ( обсуждение ) 08:16, 24 марта 2024 (UTC) [ ответить ]

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

Кроме того, поскольку то, что делает инфобокс, если он не делает ничего другого, это помещает изображение в рамку (для статей, которые содержат изображения — а «почти все» редакторы, похоже, в целом согласны с изображением в каком-то рамке в правом верхнем углу — изображение стоит тысячи слов, говорят они) вместе с выделенным жирным шрифтом заголовком, размещение изображения в рамке таким образом также допустимо, поскольку оно в любом случае помещается в рамку тем или иным образом, и оно также служит целям информирования кого или чего. (Хотя, в любом случае, мы должны предписывать для таких изображений, насколько это возможно, сообщать читателю, когда это так.) Alanscottwalker ( обсуждение ) 08:36, 24 марта 2024 (UTC) [ ответ ]

Это будет смелым предложением: иногда не так важно, когда человек мог родиться, или, что эквивалентно, это не отражено адекватно в источниках. Люди часто добавляют «X век» в качестве даты рождения в статьи для деятелей античности, просто WP:BLUEing это — несмотря на то, что у деятеля нет заверенной даты рождения или даже более конкретной оценки в источниках. Я не думаю, что это ложь или настоящий чистый негатив, но это, честно говоря, не чистый позитив: если это должно быть выведено, это, вероятно, не должно быть в инфобоксе. Это отражает рефлекс, что инфобоксы должны существовать и быть заполнены в определенной степени, что не так, если вы не верите аргументу от наименьшего удивления выше, чего я не делаю. Remsense诉14:13, 24 марта 2024 (UTC) [ ответить ]

Я не думаю, что их следует использовать, если их нельзя заполнить. Но если вы можете заполнить их фактами из надежных источников и отказываетесь основываться на избитых не-аргументах, таких как «избыточность» или «статус-кво» или «гуманитарные науки что-то в этом роде», вот где у меня проблема. Dronebogus ( обсуждение ) 15:07, 24 марта 2024 (UTC) [ ответить ]

"не-аргументы" = WP:IDONTLIKEIT . Просто потому, что вам не нравятся мнения других людей, вы не можете игнорировать их вклад. Они полностью обоснованы, несмотря на вашу неспособность принять их как таковые. - SchroCat ( обсуждение ) 15:23, 24 марта 2024 (UTC) [ ответить ]

Хорошо, я заменю «не аргументы» на «плохие аргументы». Dronebogus ( обсуждение ) 05:49, 25 марта 2024 (UTC) [ ответить ]

Мой предыдущий комментарий все еще актуален. - SchroCat ( обсуждение ) 06:01, 25 марта 2024 (UTC) [ ответить ]

Я думаю, что избыточность как аргумент действительно имеет значение — в конечном счете, на мой взгляд, она основана на WP:NPOV . То, какую информацию вы сначала отображаете о цифре, отражает точку зрения, как и то, сколько раз вы указываете информацию. Мне больше нечего сказать, поскольку вы просто не видите в этом достаточной проблемы качественно, против чего у меня нет дополнительных аргументов, и мне придется списать это на «разумные умы могут отличаться». C'est la vie. Remsense诉16:31, 24 марта 2024 (UTC) [ ответить ]

Вы не сделали "смелого предложения", вы заявили non sequitur . Никто не выступает за добавление информации, которая "не отражена в источниках". Что касается исходной даты как NPOV, то это скорее цель написания того, что говорят источники. -- Alanscottwalker ( обсуждение ) 05:09, 25 марта 2024 (UTC) [ ответ ]

Я говорю, что именно это часто и происходит, когда инфобоксы рассматриваются как основа статьи. Remsense07 : 06, 25 марта 2024 (UTC) [ ответить ]

Нет, вам вообще не нужен инфобокс, чтобы что-то добавить в статью, не говоря уже о том, является ли этот блок «фундаментальным» или нет, а это значит, что ваша так называемая фундаментальность не имеет значения. -- Alanscottwalker ( обсуждение ) 12:16, 25 марта 2024 (UTC) [ ответить ]

Я согласен с этим, но не понимаю, в чем вы со мной не согласны. Remsense诉12:59, 25 марта 2024 (UTC) [ ответить ]

Я тоже. Dronebogus ( обсуждение ) 13:00, 25 марта 2024 (UTC) [ ответить ]

Я не согласен с тем, что что-то должно рассматриваться как «фундаментальное», чтобы произошел ваш парад ужасов. -- Alanscottwalker ( обсуждение ) 13:28, 25 марта 2024 (UTC) [ ответ ]

Конечно, это вопрос градусов. Remsense诉13:35, 25 марта 2024 (UTC) [ ответить ]

«Полезно ли это» — это очень субъективно, в отличие от «является ли это ключевым фактом», который записан в WP:INFOBOXPURPOSE . Некоторые шаблоны имеют массу параметров. Некоторые утверждают, что раз есть параметр, он должен быть полезным. Это приводит к раздуванию, потому что некоторые редакторы пытаются написать статью в информационном поле, а не учитывать принцип INFOBOXPURPOSE, что меньше обычно лучше. Cinderella157 ( обсуждение ) 03:18, 25 марта 2024 (UTC) [ ответить ]

Да, я согласен. Dronebogus ( обсуждение ) 04:32, 25 марта 2024 (UTC) [ ответить ]

Поспорьте с вашей уверенностью о "ключевом" в противовес "полезному", безусловно, ключевые факты могут считаться полезными, но кто-то предполагает, что действительно важно, как вы используете эти термины. Но все инфобоксы можно отредактировать, скажем, до поля изображения и поля подписи или любым другим способом, поэтому цель инфобокса может даже предполагать, что меньше значит больше. Alanscottwalker ( обсуждение ) 12:40, 25 марта 2024 (UTC) [ ответ ]

То, что вы описываете, это явно не инфобокс, а изображение. Reductio ad absurdum или нет, это очень плохой аргумент. Dronebogus ( talk ) 12:46, 25 марта 2024 (UTC) [ ответить ]

Нет, это не так. Это коробка с информацией внутри (изображения — это информация), так что скорее quod erat demonstrandum . Alanscottwalker ( talk ) 12:55, 25 марта 2024 (UTC) [ ответить ]

Информационное поле означает что-то конкретное в Википедии, и вы это знаете. Dronebogus ( обсуждение ) 12:58, 25 марта 2024 (UTC) [ ответить ]

Инфобоксы в Википедии — это гибкое кодирование для отображения блоков с информацией. Alanscottwalker ( обсуждение ) 13:02, 25 марта 2024 (UTC) [ ответить ]

Я почти уверен, что в этом обсуждении мы не говорим о подписях к картинкам. Dronebogus ( обсуждение ) 13:07, 25 марта 2024 (UTC) [ ответить ]

Подписи — это обычные информационные поля в информационных блоках, так что вполне очевидно, что мы ими являемся. -- Alanscottwalker ( обсуждение ) 13:09, 25 марта 2024 (UTC) [ ответить ]

Большинство пользователей считают их овеществленной частью интерфейса. Remsense诉13:09, 25 марта 2024 (UTC) [ ответить ]

Если под овеществленной вы подразумеваете упакованную информацию, то это различие без разницы. Но если под овеществленной вы подразумеваете суммирование информации, то это скорее общая цель для энциклопедии. -- Alanscottwalker ( обсуждение ) 13:20, 25 марта 2024 (UTC) [ ответить ]

Закрытие?

Прошло два дня с момента последнего голосования и три дня с момента последнего значимого редактирования без голосования. Обсуждение явно застопорилось, не достигнув ничего похожего на прогресс в направлении консенсуса или нового проекта, и голоса, похоже, склоняются к «против». Даже если бы внезапно появилась дюжина голосов «за», сообщество явно слишком разделено, чтобы договориться о каком-либо изменении текущих правил. Обсуждение открыто уже две недели, так что я думаю, что это достаточно времени для людей, чтобы высказать свое мнение. Я думаю, что это следует закрыть, поскольку нет консенсуса по изменению в текущем виде; нет предубеждений по отношению к другим или пересмотренным проектам . Dronebogus ( обсуждение ) 19:55, 29 марта 2024 (UTC) [ ответить ]

Да, похоже, консенсуса нет . Remsense诉21:05, 29 марта 2024 (UTC) [ ответить ]

Прошло всего две недели? Кажется, что прошло гораздо больше времени. Очевидно, что консенсуса нет, но это послужит полезным подтверждением того, что инфобоксы НЕ ожидаются/рекомендуются/обязательны для всех статей, и в частности для всех биографий, аргумент, который часто озвучивается в обсуждениях. Johnbod ( talk ) 05:21, 30 марта 2024 (UTC) [ ответить ]

Хотя консенсуса нет, я думаю, мы многому научились. Мы знаем, что есть много возражений по поводу биографий и исторических тем. Мы подозреваем, что почти нет никаких возражений против инфобоксов о химических элементах и соединениях, наркотиках, современных поселениях, современных национальных государствах, видах, железнодорожных станциях, звездах и других вещах с кучей надежных количественных данных. Я думаю, что это прогресс.— S Marshall T / C 10:56, 30 марта 2024 (UTC) [ ответить ]
Согласен — чтобы объяснить свою позицию, учитывая, что я определенно представил скептическую позицию по отношению к инфобоксам — когда мы делаем какой-то элемент 119 и 120 , у них почти наверняка должны быть инфобоксы. Тот факт, что они уже есть, мил и не вызывает возражений, но определенно, когда они существуют, инфобоксы обновляются немедленно . Remsense诉13:17, 30 марта 2024 (UTC) [ ответить ]
Голоса все еще поступают, поэтому имеет смысл дать этому поработать еще немного, прежде чем опытный закрывающий определит, что мы узнали. Хотя для новой формулировки, как здесь предлагается, может и не быть достаточного консенсуса, также, похоже, очень мало консенсуса, чтобы просто оставить текущий текст таким, какой он есть. Gawaon ( talk ) 11:29, 30 марта 2024 (UTC) [ ответить ]
Я думаю, что самая большая проблема, с которой я сталкиваюсь в текущих правилах, заключается в том, что нет хороших советов , когда статья должна иметь инфобокс. Вот почему меня также расстраивает статус-кво, по крайней мере, в отношении биографий — на самом деле есть веские причины, по которым некоторые биографии не имеют их, главная из которых — отсутствие проверяемой информации. Но текущая ситуация основана в основном на произвольных предпочтениях пользователей, смешанных с такими же произвольными неофициальными правилами. Ситуация в основном идентична между Людвигом ван Бетховеном и Клодом Дебюсси , но у одного было достаточно голосов, чтобы получить блок, а у другого — нет. Это не работающий прецедент. Я думаю, что в правилах должно быть сказано: «Если категория статей обычно включает инфобокс, должны быть явные, специфичные для статьи причины, чтобы исключить его». Dronebogus ( обсуждение ) 13:32, 30 марта 2024 (UTC) [ ответ ]
Согласен. На самом деле нет веской причины, по которой у Дебюсси нет инфобокса — конечно, мы знаем достаточно, чтобы создать его для него! С другой стороны, с некоторыми людьми из античности или другими, о которых известно очень мало, это действительно не так, и им лучше остаться без инфобокса. Gawaon ( talk ) 14:43, 30 марта 2024 (UTC) [ ответить ]
Есть веские причины, и они были объяснены на этой странице обсуждения. Я думаю, вы имеете в виду, что вам не нравятся причины , что довольно необычно. - SchroCat ( обсуждение ) 16:36, 30 марта 2024 (UTC) [ ответить ]
Проблема в том, что в политике или руководстве нет ничего, что привело бы к ожесточенной дискуссии, наблюдаемой в этой области. Вместо того, чтобы подталкивать одну или другую сторону, было бы полезно дать указания о том, почему или почему не следует использовать инфобокс. Это не разрешит споры, но, по крайней мере, закрепит их на чем-то более прочном, чем нравится/не нравится. -- LCU Активно беспристрастный « @ » ° ∆t ° 17:12 , 30 марта 2024 (UTC) [ ответить ]
Как я это вижу, текущая ситуация такова: «два человека дают два ответа на одну и ту же ситуацию; правильный ответ тот, кто пришел первым». Идеальная ситуация была бы такой: «два человека дают одинаковые ответы на одну и ту же ситуацию, потому что есть руководство». И руководство было бы похоже на то, что я сформулировал выше, и было бы частью MOS, а не какой-то неофициальной догмой, которая, очевидно, не соответствует действительности, вроде «инфобоксы особенно не подходят для биографий гуманитариев» (если это так, то почему они есть во многих упомянутых биографиях?) Dronebogus ( обсуждение ) 17:31, 30 марта 2024 (UTC) [ ответить ]
Вероятно, пришло время снова привести мой комментарий от 2018 года: «Есть типы статей, в которых у нас обычно есть инфобоксы, и типы, в которых их нет. Нет абсолютно никаких доказательств того, что «есть определенное ожидание со стороны читателей», что все статьи должны иметь инфобоксы, и я не верю, что это так. Подавляющее большинство типов статей довольно четко попадают в одну или другую группу, но некоторые типы по разным причинам оказываются посередине, и именно здесь концентрируются споры. Статьи, подходящие для инфобоксов, посвящены отдельным вещам , будь то люди, места, таксоны, события и т. д., где важными вещами, которые нужно знать о предмете, являются: а) то же самое для других членов этого класса вещей, б) объективные факты, которые легко проверить, и в) ясные и простые для изложения. Типы статей, не подходящие для инфобоксов, — это те, в которых не выполняется ни один из этих трех факторов, что включает в себя большинство статей по более широким темам и концепциям, но также и некоторые о вещах (например, о людях определенных типов)». Johnbod ( обсуждение ) 03:40, 31 марта 2024 (UTC) [ ответить ]
Согласен Как я уже говорил ранее, я считаю, что биографии спортсменов и политиков могут выиграть от инфобоксов, но с другой стороны, как было отмечено в отчете Signpost : «Инбоксы могут быть особенно неподходящими для областей гуманитарных наук, когда они повторяют информацию, уже имеющуюся в вводном разделе статьи, вводят в заблуждение или чрезмерно упрощают тему для читателя». Инбоксы в таких статьях обманчиво подчеркивают менее важные фактоиды, лишены контекста и лишены нюансов , тогда как раздел WP:LEAD может подчеркнуть и контекстуализировать ключевые факты о предмете. -- Ssilvers ( обсуждение ) 03:54, 31 марта 2024 (UTC) [ ответ ]
Отчет-указателя (!) 10-летней давности, который вы любите цитировать как евангелие. Я не спорю, что лид контекстуализирует факты, но буквально никто никогда не предлагал заменить лид инфобоксом. Это не игра с нулевой суммой. Статьи могут иметь и имеют лиды и инфобоксы. Dronebogus ( обсуждение ) 13:30, 31 марта 2024 (UTC) [ ответ ]

Март 2024 (UTC)

Я восхищаюсь решимостью, но это все еще аргументы «мне это не нравится» против «мне это нравится». Эти оценки можно сохранить для следующего RFC, в котором неизбежно будут участвовать многие из этих редакторов. Если сообщество желает урегулировать эти дискуссии одну за другой, пусть так и будет. При таком раскладе не может остаться много таких статей. Nemov ( talk ) 10:12, 31 марта 2024 (UTC) [ ответить ]

Опять же, инфобоксы — это довольно специфичная для Википедии конструкция. У нас нет внешних подтверждений или подкреплений, с которыми можно было бы работать, поэтому, к сожалению, нам приходится использовать мозги в этом вопросе, хотя обычно мы живем и умираем по V и NPOV. Remsense诉10:15, 31 марта 2024 (UTC) [ ответить ]

Согласен. Также нет исследований аппетита читателей или желания коробок. Множество заявлений от людей с обеих сторон дискуссий, но ноль фактических доказательств или исследований по этому поводу. - SchroCat ( обсуждение ) 12:33, 31 марта 2024 (UTC) [ ответить ]

Сказав это, я признаю, что если читатели принадлежат к тому же виду, что и редакторы, я думаю, что весьма вероятно, что многие читатели обожают инфобоксы — неубедительные и анекдотические свидетельства, но их много. Конечно, учатся ли они лучше из них — это взаимосвязанный, но отдельный вопрос. Remsense诉12:50, 31 марта 2024 (UTC) [ ответить ]

Радикальное предложение, возможно, но что, если мы на самом деле организуем какой-то опрос, который спросит «нравятся ли вам инфобоксы» и «полезны ли они для вас»? Dronebogus ( обсуждение ) 13:31, 31 марта 2024 (UTC) [ ответить ]

Эй, конечно, почему бы и нет. Кажется, было бы действительно интересно и полезно, если бы мы получили 10 тыс. ответов читателей на 5-минутный опрос обратной связи. Remsense诉13:50, 31 марта 2024 (UTC) [ ответить ]

Кажется, что нужно преодолеть много препятствий, чтобы прийти к очевидному выводу. Большинству людей нравится возможность быстро найти сводку информации в инфобоксе. Общий цикл этих обсуждений отдельных статей выглядит так... случайный редактор видит большую статью без инфобокса. Они смело добавляют его.[5] Она возвращается с пометкой «найти консенсус в разговоре».[6] Если они сделают следующий шаг и создадут обсуждение, их встретят обычным хором «нам это не нравится» от многих редакторов здесь, а затем тем же «нам это нравится» от другой группы. Обсуждение на этом закончится, или кто-то создаст RFC. Случайный редактор, который посчитал это улучшением, скорее всего, просто пойдет дальше. Это не стоит бюрократической волокиты. Хорошо ли это для проекта? Облегчает ли это поиск информации для читателей? Ответ кажется очевидным, но иногда то, что очевидно, не очевидно для всех. Немов ( обсуждение ) 14:28, 31 марта 2024 г. (UTC) [ ответить ]

До «но вы не можете этого ДОКАЗАТЬ!» Dronebogus ( обсуждение ) 14:32, 31 марта 2024 (UTC) [ ответить ]

Кажется, что придется преодолеть много препятствий, чтобы прийти к очевидному выводу.

Нет, нам нравится проверяемость в Википедии, если мы можем ее получить. Очевидно для вас, может быть, но, возможно, мы можем получить дополнительные полезные идеи из чего-то вроде этого. стоит обсуждения деревенского насоса. Remsense诉14:45, 31 марта 2024 (UTC) [ ответить ]

Читатели и редакторы — совершенно разные звери. Посмотрите здесь вопрос читателя о фотографии голого ребенка в статье. Рефлекторная реакция первого респондента о CENSORSED, прежде чем признать, что они не удосужились просмотреть статью. Другой редактор был чертовски груб с ними. Ответ редактора находится на совершенно ином пути по сравнению с реакцией читателя, поэтому я не уверен, что радикализация IB некоторых частей сообщества будет соответствовать тому, чего на самом деле хотят читатели. - SchroCat ( обсуждение ) 14:01, 31 марта 2024 (UTC) [ ответить ]

Я думаю, точнее будет сказать, что редакторы — это прекрасная, довольно специфическая разновидность в семействе читателей. Remsense诉14:07, 31 марта 2024 (UTC) [ ответить ]

Согласен, что это подгруппа, но в этом-то и суть: они не представляют всех читателей, а лишь очень специфическое ответвление, и эти двое очень разные! - SchroCat ( обсуждение ) 14:35, 31 марта 2024 (UTC) [ ответить ]

SchroCat, сбрось этот чертов WP:STICK на этот WP:OTHERCRAP Dronebogus ( обсуждение ) 14:09, 31 марта 2024 (UTC) [ ответить ]

Я понятия не имею, о чем вы говорите, и мне это еще меньше интересно. - SchroCat ( обсуждение ) 14:35, 31 марта 2024 (UTC) [ ответить ]

Инцидент, о котором вы только что упомянули? Dronebogus ( обсуждение ) 14:38, 31 марта 2024 (UTC) [ ответить ]

Я поднял обсуждение и привел два примера редакторов, которые плохо обращаются с читателями, по причинам, изложенным в моем комментарии, о разнице между ними. Обратите внимание, что я не назвал ни одного из редакторов, потому что называние и пристыжение не были целью — только пропасть во взглядах и ожиданиях между читателем и редактором. То, что вы настаиваете на том, что вы очень грубый редактор, является прекрасным примером эффекта Стрейзанд . - SchroCat ( обсуждение ) 15:10, 31 марта 2024 (UTC) [ ответить ]

Ну, это не совсем скрыто, если вы дали ссылку Dronebogus ( обсуждение ) 15:39, 31 марта 2024 (UTC) [ ответить ]

https://meta.m.wikimedia.org/wiki/Wikipedia_talk:MOSINFOBOX/Research:Which_parts_of_an_article_do_readers_read Moxy 🍁 03:00, 21 мая 2024 (UTC) [ ответить ]

Как вам уже объясняли, это не показывает то, что вы хотите, чтобы это показывалось. Это не доказывает, что IB полезны, а то, что они отвлекают. Это подтверждает многочисленные другие исследования отслеживания глаз, которые показывают, что человеческий глаз всегда тянется к нетекстовым элементам на странице. Это не отвечает на вопрос, являются ли они желаемыми, полезными или выгодными. - SchroCat ( обсуждение ) 03:35, 21 мая 2024 (UTC) [ ответить ]

Я бы сказал, что это не доказывает ни того, ни другого. Remsense诉03:38, 21 мая 2024 (UTC) [ ответить ]

Основная область разногласий, по-видимому, касается биографий; возможно, стоит добавить дополнительные советы по другим областям и по тому, как обращаться с деталями в информационных полях, которые являются спорными/вызывающими споры. -- LCU Активно не заинтересован « @ » ° ∆t ° 12:01 , 31 марта 2024 (UTC) [ ответить ]
Жаль, что произошла откровенная агитация. Не думаю, что это повлияет на конечный результат, но я думаю, что мы можем и должны игнорировать голоса тех, кого пинговали. - SchroCat ( обсуждение ) 16:40, 5 апреля 2024 (UTC) [ ответить ]
Комментарий от потенциального завершителя : Я готов закрыть это, хотя, поскольку я принимал участие в одном запросе предложений (RfC) по добавлению информационного блока в конкретную статью, я хочу спросить, считает ли какой-либо редактор меня замешанным в этом деле, прежде чем я это сделаю; пожалуйста, см. это обсуждение в разделе «Запросы на закрытие» для получения более подробной информации.

Если в течение следующих нескольких дней не поступит никаких разумных возражений, ни здесь, ни по запросу на закрытие, я закрою обсуждение, если только кто-то другой не сделает это раньше. BilledMammal ( обсуждение ) 02:39, 21 мая 2024 (UTC) [ ответ ]

Поскольку ваше закрытие будет неадминистративным закрытием, кажется ли результат однозначно однозначным и вряд ли будет спорным (т. е. однозначный консенсус для определенного результата)? Hydrangeans ( она/ее | обсуждение | редактирование ) 04:02, 21 мая 2024 (UTC) [ ответить ]

Несомненно, что здесь нет консенсуса относительно изменения MOS, как признали выше различные люди, голосовавшие с обеих сторон. -- Ssilvers ( обсуждение ) 04:06, 21 мая 2024 (UTC) [ ответ ]

Это уже некоторое время находится на WP:CR , и ни один администратор, похоже, не заинтересован. Я не вижу причин, по которым неадминистратор не мог бы закрыть это, независимо от того, что говорится в этом эссе . Charcoal feather ( talk ) 12:15, 21 мая 2024 (UTC) [ ответить ]

WP:BADNAC является частью WP:Non-admin closure , которая является информационной страницей , а не эссе . В то время как эссе предлагают советы, которые в целом основаны на точке зрения, информационные страницы беспристрастно дополняют или разъясняют техническую или фактическую информацию о Википедии . Гортензии ( она/ее | обсуждение | редактирование ) 06:24, 22 мая 2024 (UTC) [ ответить ]

Статус страницы на самом деле не имеет значения (но см. Wikipedia:The different between policies, guidelines and essays , если эта тема вас интересует). Важно то, что разумные люди не хотят быть объектом гнева, и как бы вы ее ни закрыли — за, против или ни то, ни другое — кто-то, скорее всего, рассердится. Любой NAC, который пишет краткое заявление, является NAC, который может ожидать, что ему прочитают лекцию о BADNAC, а также дадут Неправильный Ответ™. WhatamIdoing ( обсуждение ) 07:31, 22 мая 2024 (UTC) [ ответить ]

Кто-то изменил это с эссе на информационную страницу месяц назад; я просто вернул его обратно. Leviovich ( talk ) 21:50, 22 мая 2024 (UTC) [ ответить ]

Одна из проблем с инфобоксами

Я не против инфобоксов, если их конструкция хорошо выполнена. Но слишком часто мы видим слишком раздутые блоки, потому что редакторы пытаются написать статью в инфобоксе и/или они заполнены сомнительными «фактами» (как в примере). Пример взят из небольшой операции на лодке, проведенной украинским спецназом на пяти десантных катерах RHIB . Им противостояли не менее двух российских флотов под командованием двух адмиралов. Из пяти задействованных лодок семь были захвачены или потоплены, а одной удалось скрыться! Украинцами, по-видимому, командовал полковник Сергей Лупанчук, которого нет в указанном источнике и, вероятно, не было ни на одной из пяти (или восьми) лодок. Возможно, он призрак одного из пострадавших.

Но мы не только получаем подобную чушь, мы получаем редакторов, которые ее восстанавливают! Cinderella157 ( обсуждение ) 00:52, 3 апреля 2024 (UTC) [ ответить ]

Я думаю, что это случай «тогда удалите неиспользуемый материал». И если редакторы восстанавливают плохой контент, это известно как «разрушение». Но я не понимаю, как «некоторые инфобоксы — это дерьмо с плохими ссылками» переводится как «это проблема, присущая инфобоксам». То есть, буквально любая форма контента может иметь такие проблемы. Dronebogus ( обсуждение ) 05:00, 3 апреля 2024 (UTC) [ ответить ]

^ "Командование Сил специальных операций подтвердило потерю военнослужащих в Херсонской области".

Я очень часто вижу противоречивую информацию между информационными блоками и статьями, в которых они появляются. Со временем информационные блоки имеют тенденцию накапливать фактоиды, которые не встречаются или не упоминаются в статье, и эти фактоиды почти всегда не упоминаются в информационных блоках. -- Ssilvers ( обсуждение ) 02:28, 3 апреля 2024 (UTC) [ ответ ]

Я не отрицаю, что это правда, но инфобоксы, против которых вы чаще всего выступаете, не являются таковыми. Это биографические инфобоксы с 4 или около того объективными, источниками, чрезвычайно базовыми фактоидами. Кажется, никто не работает над широко распространенными системными ошибками в инфобоксах сражений/войн, но все ведут себя как композиторы, тщательно разрабатывать один для предоставления конкретной, полезной информации — это святотатство. Dronebogus ( обсуждение ) 05:10, 3 апреля 2024 (UTC) [ ответить ]

что же тогда нам делать с множеством плохих инфобоксов? Вы говорите: «Кажется, никто не работает над широко распространенными системными ошибками в инфобоксах битв/войн», так как же нам способствовать этому? Потому что в настоящее время есть много редакторов, которые фокусируются на инфобоксах, а не на содержании статей, и яростно защищают раздутые и не имеющие источников инфобоксы. Bondegezou ( talk ) 06:14, 3 апреля 2024 (UTC) [ ответить ]

Вы пытаетесь создать какой-то миф? Кто эти "многие", будьте конкретны. Alanscottwalker ( talk ) 11:12, 3 апреля 2024 (UTC) [ ответить ]

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

Я думаю, вы нечасто общаетесь и смотрите биографии художников. Johnbod ( обсуждение ) 14:49, 22 мая 2024 (UTC) [ ответить ]

@ Bondegezou напоминание, что инфобоксы имеют обозначение CTOP, и любой редактор, занимающийся деструктивным поведением, чтобы восстановить в них неиспользуемую информацию, может быть отправлен в WP:AE при условии, что ему был дан совет на его странице обсуждения до обозначения CTOP. То, что некоторые редакторы демонстрируют поведенческие проблемы, касающиеся инфобоксов, не является аргументом против их использования. Tar nis hed Path ^talk 06:31, 28 мая 2024 (UTC) [ ответить ]

Если у вас есть правило, которое часто нарушается, разумно пересмотреть его. Bondegezou ( обсуждение ) 09:12, 28 мая 2024 (UTC) [ ответить ]

Эм, я думаю, именно об этом и был этот RFC? Сделать так, чтобы наши правила/руководства по использованию инфобокса лучше соответствовали реальной практике. Gawaon ( talk ) 10:44, 28 мая 2024 (UTC) [ ответить ]

Но в целом это отражает общую практику, учитывая, что менее половины наших статей имеют IB. - SchroCat ( обсуждение ) 11:16, 28 мая 2024 (UTC) [ ответить ]

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

Хоккиенинфобокс

В настоящее время идет обсуждение для достижения консенсуса по аспектам, включая макет и источники статьи на языке хоккиен . Вклад людей будет оценен. Remsense诉21:49, 10 мая 2024 (UTC) [ ответить ]

Встроенный тег обслуживания

Я понял, что это, вероятно, будет весьма полезно, поэтому я пошел и быстро создал . Надеюсь, другим это будет полезно! Remsense诉04:23, 11 мая 2024 (UTC) [ ответить ]{{Infobox clutter}}

Какое практическое правило вам нужно?

The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. Of necessity, some infoboxes contain more than just a few fields; however, wherever possible, present information in short form, and exclude any unnecessary content.

While this is certainly rhetorically helpful, I've found that this explication doesn't help a lot of the time, as strictly speaking only moves the issue down a rung: clearly, many people have broader notions of what "necessary" or "key" facts are, or how brief a "glance" is. Keeping in mind I do not want to reduce the effective flexibility of editors, it seems a concrete addition may help. There are problems I can already ascertain with this addition, but it's a starting point, perhaps:

As rules of thumb: information that is not easily recalled by the reader after perusing the infobox for under a minute may be worth removing, and lists longer than five or six items may have room for trimming.

Remsense诉 22:55, 29 May 2024 (UTC)[reply]

This would still be an arguing point, with personal views of who retains what based on personal experience of editors familiar with the subject (and have therefore retained) rather than a blind test. On the other hand, if it is not supported by the body of the article (and the article does not remain complete without the infobox) it is clearly not a key fact. I would say, that just because a field exists in an infobox does not mean that it should be used in a particular article. That might be more useful. Apart from that, I don't think that we are going fix bloat by trying to be more prescriptive. It takes a concerted effort such as happened at (Napoleon or Syrian civil war) to say this is just beyond a joke. Perhaps we need a list of infoboxes in articles by size so that the community can actively scrutinise the worst excess? Cinderella157 (talk) 00:15, 30 May 2024 (UTC)[reply]

I think including a list of reference articles in the guideline might be a possibility. Remsense诉 00:17, 30 May 2024 (UTC)[reply]

I strongly disagree with your argument above. The shorter the infobox, the more effectively it might help readers to identify key facts at a glance. It is essential to exclude content that is not "key". I find this instruction to be extremely helpful. Any discussion of what is key, necessary and able to be understood "at a glance", and what is "possible", may require discussion at the article's Talk page, but that should be, at least, the aspiration. "Under a minute"? A geographical or political infobox could take many minutes to digest, while many biography infoboxes should take 10 seconds. And any time you put an upper limit on something, people will argue that they should be allowed to put in all the stuff you can put in up to that limit. It must be a case-by-case discussion based on common sense and experience. -- Ssilvers (talk) 01:33, 30 May 2024 (UTC)[reply]

These are all extremely good and welcome points. I plucked one minute completely out of thin air: I want to reemphasize my suggestion was a scaffold interrogating what kinds of suggestions could work, and nothing more. Remsense诉 01:52, 30 May 2024 (UTC)[reply]

Birthplace as proxy for citizenship and nationality

I'm assuming WP:INFONAT should be interpreted to include countries without jus soli birthright citizenship when it says that the "citizenship" and "nationality" fields are not necessary when "birthplace" is filled out and the country for all three is the same? If that's not right, please let me know; I intend to clean up any articles that don't follow that. -- Beland (talk) 19:36, 30 May 2024 (UTC)[reply]

~~I agree.~~ Don't need more than one if they are the same. -- Ssilvers (talk) 20:44, 30 May 2024 (UTC)[reply]

Cool, I'll note that in the guideline for clarity. -- Beland (talk) 20:54, 30 May 2024 (UTC)[reply]

One caveat… take into account that a place may be part of different countries at different periods of history. For example, someone born in San Antonio, Texas in 1800 was born a Mexican, not an American. Blueboar (talk) 21:04, 30 May 2024 (UTC)[reply]

Sure; I would expect the country name to be given in the birthplace explicitly for cases like that. -- Beland (talk) 21:24, 30 May 2024 (UTC)[reply]

No. I strongly oppose the inclusion of countries without « jus soli ». For instance fr:François-Louis de Pesmes de Saint-Saphorin was born, and died, in the same Swiss town. But he was not Swiss, as there was no jus soli then (there still isn’t): he was a citizen of the Republic of Geneva, in which he never even lived. --Sapphorain (talk) 22:58, 4 June 2024 (UTC)[reply]

INFONAT does not preclude use of |nationality= when it does not match a person's birth country. —Bagumba (talk) 23:11, 4 June 2024 (UTC)[reply]

Sorry for the long message here, but I've been fixing a lot of articles to conform to WP:INFONAT, and have learned a lot about how these fields are used in practice. It would be nice to get a firm answer on whether or not the rule is going to change, because hundreds of thousands of edits are needed to bring articles into conformance regardless of what the rule is going to be.

Even for countries that do have jus soli, there are exceptions. For example, the children of foreign diplomats born in the United States, Native Americans before 1924, and people who have dual citizenship because they are the descendants of foreign nationals.

The alternatives I can think of:

Document citizenship for every single person, so when the field is missing, it can only mean that editors have not yet found sourcing and documented it (or it's a complicated case explained in the prose, if we don't change that rule).
Document citizenship for every person born in a country without jus soil or whose citizenship changed, does not match their birth country, or has dual citizenship. When the field is missing, it means either the country of birth has jus soil (but they may or may not be an exception) or that editors have not yet found sourcing and documented a citizenship mismatch or dual citizenship (or it's a complicated case explained in the prose, if we don't change that rule). Readers would be on their own to figure out which countries have jus soil.
Document citizenship only for people where it does not match their birth country or has changed. When the field is missing, it means either it matches the birth country and has not changed, or that editors have not yet discovered or documented a citizenship mismatch or change or dual citizenship, or it's a complicated case explained in the prose. (This is the current rule, before Sapphorain's revert and after the un-revert.)

I'd be interested to read if anyone would like to propose any other alternatives.

I assume the reasons we don't do (1) now are that this repeats the country name for 140,000+ biographies (I did a database dump scan) and perhaps over-emphasizes citizenship compared to other information in a "show me your papers" sort of way?

Documenting citizenship for everyone or more than half the world would require a lot of sourcing work. In many cases, I suspect whoever filled the citizenship field just assumed citizenship was the same as the birth country without confirming that or checking for dual citizenship or emigration or exception status. Maybe half the time the nationality field is filled out incorrectly, either simply duplicating the citizenship field or supplying their ethnicity instead of their legal nationality. I would want to require inline citations whenever these fields are used to protect against bad information, especially in BLP articles. Nearly all instances of the citizenship and nationality fields are currently without citations.

One way we could reduce incorrect use of these fields is to drop the nationality field entirely, and use the citizenship field for both citizenship and legal nationality. Needing to use nationality to indicate something other than citizenship is relatively rare, but for countries that make the distinction we should probably be careful to distinguish. So for example instead of just saying "citizenship=United Kingdom" we'd want to say "citizenship=British citizen" which has a differnt set of rights compared to "citizenship=British subject". If we care about which legal rights a person has, we'd also need to specify which colony they are attached to if they are not full citizens, for example "citizenship=United States national (American Samoa)" or "citizenship="British Overseas Territories citizen (Bermuda)". I've been operating under (3) and just making sure the colony name is mentioned in the birthplace, and that the article on the colony explains the citizenship/nationality status of people born there or links to an article that does.

A lot of people with Wikipedia biographies don't have books written about them, and unless their citizenship is notable in some way it's simply not mentioned in articles about them. Mentioning the countries they have lived in is a lot more common than specifying legal status if they have moved around. So even if we try to do (1) or (2), I'd expect to have a lot of blank citizenship fields, even more if we don't consider birth in a jus soli country to be proof someone isn't a diplomatic or dual-citizen or emigrant exception, and regardless for a lot of people in non-jus soli countries.

One of the nice things about (3) is that it greatly simplifies the infobox in certain complicated situations, and avoids a lot of disputes and factual errors that require us to become amateur immigration lawyers to figure out, which skirts the boundary of original research. For example, I came across someone born in the New Hampshire Grants in colonial British America. Technically, I think they were indisputably a British subject before 1776, then after the Declaration of Independence either a citizen of New York or New Hampshire, both of which claimed the territory. Then in 1777, the Vermont Republic declared independence, but it wasn't recognized, so there was a third citizenship claim. Even worse, the British continued to assert Americans were British subjects after 1776, and even after the 1783 Treaty of Paris ended the war, adding a fourth claim. Vermont became a state under the U.S. Constitution in 1791, and which I think made everyone there U.S. citizens, though that may depend on whether or not the U.S. Congress had yet passed a uniform nationality law. Recapitulating all this history by listing all the citizenships a person has had seems a bit much for a biography infobox. With (3), I can just say they were born in the New Hampshire Grants and if you care about their citizenship you can go and read about the sovereignty changes for that territory. Presumably any notable changes in citizenship that did not follow the changing sovereignty of the territory would be noted in the prose, which is where the current rules says complex cases should be explained.

Likewise, some colonies (e.g. Puerto Rico, Bermuda) have had different levels of citizenship and nationality extended to them at various times, sometimes retroactively, so to accurately describe a person's citizenship, we'd need to take their birth date and plug it into a timeline of nationality law changes for their birthplace, which might also require us to figure out where they were living when and the nationality of their parents. I came across another biography where someone was born in Puerto Rico just before the Spanish-American war. Based on Puerto Rican citizenship and nationality, it seems they were a Spanish subject for a while, then probably a stateless U.S. national, then probably a U.S. national and citizen of Puerto Rico, and then for people living into the later era of retroactive and birthright citizenship for PR, U.S. citizens to whom the constitution only partly applies, weirdly unless they move to a U.S. state. It was kind of nice to effectively just have the infobox say, they were born in Puerto Rico when it was part of the Spanish Empire and died in Puerto Rico when it was part of the United States; you can figure out the rest if you care and it's explained in the prose if it's important.

-- Beland (talk) 02:29, 5 June 2024 (UTC)[reply]

FTR, for an English-language article where removal of citizenship was disputed by Sapphorain, we have Charles Bonnet. -- Beland (talk) 02:32, 5 June 2024 (UTC)[reply]

Was disputed, and still is. And a real consensus should be reached in order to include the countries having jus soli in this rule.--Sapphorain (talk) 06:59, 5 June 2024 (UTC)[reply]

I count six involved editors so far including myself; only you have spoken in favor of excluding those countries. Ssilvers has said they are in favor of inclusion. Would you be satisfied if the others explicitly express an opinion in favor of inclusion? Do you want an RFC? -- Beland (talk) 07:10, 5 June 2024 (UTC)[reply]

What? I don't know what you think I am in favor of. I am in favor of EXCLUDING nationality and citizenship parameters if they are the same country as the person's birthplace. We don't need more than one parameter if they are the same, and we should keep infoboxes concise. -- Ssilvers (talk) 19:51, 5 June 2024 (UTC)[reply]

Sorry for the confusing phrasing; I was saying you were apparently in favor of including non-jus-soli countries in the rule that excludes these parameters. -- Beland (talk) 20:02, 5 June 2024 (UTC)[reply]

OK, thanks. -- Ssilvers (talk) 20:16, 5 June 2024 (UTC)[reply]

For the record, as an editor not yet involved in the discussion I think that adding the phrase "including countries without jus soli birthright citizenship" is fine. It's sufficient to include the nationality if it can't be guessed from the country. Peoples born in Spain are probably Spanish, those born in Germany are probably German etc. Add the explicit info in cases where these "rules of thumb" are violated, but don't make it more complicated than that. Gawaon (talk) 07:36, 5 June 2024 (UTC)[reply]

Broadly agree with this. Also worth keeping in mind that the concept of citizenship has varied over time, I would be wary of anachronisms from too strict a guideline. CMD (talk) 07:48, 5 June 2024 (UTC)[reply]

Well, then there should be a number of exceptions for particular cases. For instance, in a former country in Europe where about 95% of the population didn’t hold any citizenship at all, does having no precision on citizenship mean the person’s citizenship « can be inferred from birth place », or does it simply mean this person was not a citizen anywhere?!--Sapphorain (talk) 08:00, 5 June 2024 (UTC)[reply]

What would you propose to do for that country, add "citizenship=None" for 95% of the biographies? -- Beland (talk) 08:09, 5 June 2024 (UTC)[reply]

No, I would simply keep or add the indication of citizenship for 5% of the biographies.--Sapphorain (talk) 08:13, 5 June 2024 (UTC)[reply]

… Besides, the people without citizenship rights in some country are very far from representing 95% of the people of that country that deserve a wikipedia page. --Sapphorain (talk) 08:19, 5 June 2024 (UTC)[reply]

If we don't consider it important enough to note that someone is a citizen of the country they were born in when that's true for 95% of people born there, why would it be important to say that when it's only true for 5% of people born there? Was citizenship equivalent to nobility status in modern European countries? (What country are we talking about here, anyway?) -- Beland (talk) 08:26, 5 June 2024 (UTC)[reply]

Oh, if you're talking about Canton of Geneva#Republic of Geneva (1534/1541–1798, 1813–1815), it looks like "citizen" there and then meant a child of a bourgeois, the latter being the only people with voting rights. That does not sound much like the modern concept of citizenship, and I think it would be confusing to use the citizenship field to indicate that status. I would file that under "complicated cases that should be explained in the prose" with a link to the above or other explanatory article. -- Beland (talk) 08:31, 5 June 2024 (UTC)[reply]

FTR, Sapphorain also reverted removal of the nationality field from Jean Senebier, which just said "Genevan". From the article linked above, it appears the Republic had four levels of membership, each with different rights: habitant, natif, bourgeois, and citoyens. "Genevan nationality" could mean any of these, and it could easily be inferred that someone has Genevan nationality because they were born in the city-state of Geneva. If this person's level of membership is unknown, it seems like this field should be dropped from his infobox.

I do agree that this social structure is interesting and deserves mention in these biographies, but it's sufficiently different than modern structures that it needs explaining.

Jean-Jacques Rousseau is a more high-profile biography, and I see that the infobox doesn't mention citizenship or nationality, but the prose explains (with citation) that Rousseau was a citizen of Geneva, and a bit about what that meant. Would anyone object to giving the same treatment to Charles Bonnet (if a citation can be found to support the claim of citizenship) and Jean Senebier (if his specific level of membership can be determined)? -- Beland (talk) 17:14, 5 June 2024 (UTC)[reply]

Including such situations as plain and unadorned "nationality" or "citizenship" in the infobox feels it might mislead modern readers. People don't even know about the weird odd cases such as various British passport types and the American Samoan situation where distinctions still exist today. CMD (talk) 01:28, 6 June 2024 (UTC)[reply]

If more detail/clarification is needed, it should be given in the article itself, rather than the IB. -- Ssilvers (talk) 02:20, 6 June 2024 (UTC)[reply]

Abolishing or disfavoring the "nationality" field

As mentioned above, after going through thousands of biography infoboxes, I've noticed that the "nationality" field is used for ethnicity maybe half the time. Sometimes it's ambiguous (e.g. "Cuban") but often it's disambiguated either by a link (e.g. targeting Cuban people or Cuban nationality law) or it's something like "African-American". This violates WP:INFONAT, and before making tens of thousands of fixes, I'd like to get consensus for a solution to prevent this from re-occurring, which will presumably the guideline.

I can think of two good alternatives - abolishing the "nationality" field, or keeping it but preferring the "citizenship" field - but I'm open to other suggestions.

If we keep the "nationality" field, to avoid confusion with ethnicity, I would recommend:

Changing the field display name from "Nationality" to "National of", and possibly also changing the name of the template parameter to "national_of"
Requiring that the value be a country name (e.g. "Cuba") or legal category (e.g. "British subject"), not a demonym (e.g. "Cuban")
Specifying the territory they are connected to by their non-citizen status (e.g. United States (American Samoa), not "American"; same for citizenship e.g. "British Overseas Territories citizen (Bermuda)")

The vast majority of people are citizens of the country they are nationals of. Citizenship is generally more specific, so noting citizenship conveys more information and is less ambiguous. Saying that someone is a national of a given country doesn't necessarily imply that they are a non-citizen national. If we care about accurately noting the distinction for readers, we probably need to make non-citizen status more explicit. But if we're doing that in the display value anyway, it seems like there's no reason to keep two distinct fields, especially when one of them has a name that makes it prone to abuse. Formatting options I could think of:

Give the legal status like "citizenship=United States national" or "citizenship=British subject", and assume the phrasing (and the linked article) makes it clear enough this person is not a U.S. or British citizen, in the legal sense. (wikt:citizen notes that citizenship also has non-legal meanings.)
Explicitly note as non-citizen with something like "citizenship=None (United States national, American Samoa)" or "citizenship=United States national (American Samoa, non-citizen)".

Thoughts? -- Beland (talk) 21:30, 9 June 2024 (UTC)[reply]

For the vast majority of people, citizenship is a clear and simple attribute. Nationality has many, very diverse meanings. One of its biggest problems is that some people are certain they know what it means everywhere in the world. It's a dangerous descriptor to include in an Infobox, where a more detailed explanation isn't possible. Yes, I know we have footnotes and other tools to do that, but there is a never a guarantee that readers will follow such links. — Preceding unsigned comment added by HiLo48 (talk • contribs) 00:42, 10 June 2024 (UTC)[reply]

I think that "nationality" is a vague and unhelpful parameter. -- Ssilvers (talk) 00:11, 10 June 2024 (UTC)[reply]

Not sure what "citizenship" means, to be honest. Many countries are divided into "nations" e.g. the UK: I was born in Wales so I'm Welsh; I have Scottish parents so I'm Scottish; I lived most of my childhood in England making me English; or maybe I'm simply British. On the other hand, "nationality" refers to the country where you are a legal citizen. I'm torn here as the term is perfectly valid. How about "Citizen of" which sounds better than all the other suggestion so far, imo — Iadmc♫^talk 04:14, 10 June 2024 (UTC)[reply]

What concerns me there is your certainty that you know what nationality means, and that you believe that there is a single, universally agree meaning. There isn't. HiLo48 (talk) 06:49, 10 June 2024 (UTC)[reply]

Very few countries are divided like that, and as that consideration is not a legal one it is probably not something that should go in the infobox. It sounds like you are both a British national and a British citizen, which does not affect your personal or communal identity as someone from Wales, Scotland, England, or other. This is the case for most British nationals/citizens, although the UK is one of the places with a notable distinction between the two, eg. holders of BNO passports. The arisen confusion here between the legal concept of nationality and use as a term of self-identification is possibly another argument along with existing misuse towards the need for a change here. CMD (talk) 04:46, 10 June 2024 (UTC)[reply]

However, categories are often made like category:Welsh people which suggests that this is important to the subject more then category:British people. Should that person's nationality in the infobox be Welsh or British? — Iadmc♫^talk 04:56, 10 June 2024 (UTC)[reply]

BNO is a good point though — Iadmc♫^talk 04:58, 10 June 2024 (UTC)[reply]

Per MOS:INFONAT, the |=nationality field should not be used for most British people as they will have been born in the UK. When needed, the field would presumably say British, plus other citizenships. However, that is just for this specific infobox field; categories, lead/article prose, and even other infobox fields such as birthplace are areas of perenial discussion as to whether to include the UK nations (documented at WP:UKNATIONALS). CMD (talk) 05:11, 10 June 2024 (UTC)[reply]

I think what would fix the misuse of the |nationality= parameter is an actual |race-or-ethnicity= parameter. People are trying to put that information in the infobox, and they can't find the "right" thing, so they use whatever's closest.

If you want, we could program the infobox templates so that if the parameter gets used, it throws an ugly red error message about it being inappropriate content for the infobox.

If you don't want to go that far, we could probably code the template to reject or ignore specific common mistakes in the | nationality= parameter (e.g., "African American" or "Jewish").

More generally, there are really significant cultural differences around race and ethnicity. Some people think it's perfectly normal for everything you do to have some sort of racial or ethnic note attached to it. Some people think that it's valuable information for visibility and measuring our goals. And other people think that this information should be suppressed, so that no government has a handy way to figure out which people to round up during the next ethnic cleansing exercise. WhatamIdoing (talk) 06:50, 10 June 2024 (UTC)[reply]

I wonder how many other countries are like mine, Australia, where no questions are asked on the national census about either race, or ethnicity, or nationality? That means nobody has an official racial or ethnic label. (There is a question about ancestry. Around a third of respondents declare their ancestry to be Australian. Most of those people aren't Aboriginal.) In mentioning this, I'm not saying Australia's position is better or worse than others. I'm just highlighting the problem with defining these terms, and in assuming that there is any sort of international consistency in how these words are used. HiLo48 (talk) 06:59, 10 June 2024 (UTC)[reply]

According to the closing message, there was an overwhelmingly negative response to the idea of adding an ethnicity field in the 2016 RFC: Wikipedia:Village pump (policy)/Archive 127#RfC: Ethnicity in infoboxes. -- Beland (talk) 07:18, 10 June 2024 (UTC)[reply]

Yes. "Ethnicity" and "Race" feel racist to me. Just saying — Iadmc♫^talk 07:35, 10 June 2024 (UTC)[reply]

Note that I don't want an ethnicity field that actually works the way the other parameters work. I'm just saying that when people want to include that information and are looking for a place to stick it, the realistic options are:

we give them a place that doesn't screw up the articles (e.g., by throwing a big red error message that says "Don't use this, because we voted in 2016 to never put race and ethnicity information in the infobox" or that refuses to let the page get saved, or something like that), or
they continue to screw up the articles by shoehorning that information into an existing but incorrect field.

WhatamIdoing (talk) 02:53, 29 June 2024 (UTC)[reply]

If there simply aren't any fields that seem appropriate for ethnicity, I think that would solve the problem. It's not like people are going to shoehorn ethnicity into birth_date or something. -- Beland (talk) 07:31, 29 June 2024 (UTC)[reply]

I like the idea of keeping the "nationality" field as a honeypot and displaying a big red error message if anyone tries to use it, at least for a transitional period. In order to avoid widespread disruption of biographies, we'll want to remove the field (and add citizenship where needed) to tens or hundreds of thousands of articles. I'm currently working on biographies where both fields should have been omitted under the old guideline (where they were the same as the birth country). I'm doing countries with jus soli citizenship, but given the consensus in the previous thread was to include all countries in that rule, I'll do the non-jus soli countries next. Then I'll have to circle around and do the more complicated cases. If anyone would like to help, I can provide lists of articles; it's easy to zap them in a few seconds for most articles if using JWB or AWB. -- Beland (talk) 17:56, 12 June 2024 (UTC)[reply]

But note that, according to Nationality#Nationality versus citizenship: "Historically, the most significant difference between a national and a citizen is that the citizen has the right to vote for elected officials, and the right to be elected. This distinction between full citizenship and other, lesser relationships goes back to antiquity." – So maybe it would be better to allow continued used of the "nationality" field in cases where "citizenship" is not applicable? If we just straight out forbid the former, it seems very likely that the latter will very often be abused for it in cases where there actually was no citizenship. Using both in the same infobox can still be deprecated, since it seems there is no reason to do so. Gawaon (talk) 19:46, 12 June 2024 (UTC)[reply]

I'm writing this because of Beland's bold change to MOS:INFONAT today that "a |nationality= field should not be used." I must say I did not see that coming based on how the discussion went so far (there was a suggestion of changing it to "national_of", not dropping it altogether) and I do think that more deliberation is needed before such a change should possibly be made. Gawaon (talk) 19:53, 12 June 2024 (UTC)[reply]

Well, we certainly have plenty of time before I finish cleaning up articles under the old policy before I get to the new one.

There's not a clear-cut voting distinction across all countries between nationals and citizens. In the United States, for example, U.S. citizens who are residents of Puerto Rico cannot vote in federal elections, and non-citizen residents of some cities can vote for some local elections.

There are actually very few people whose nationality would be listed in an infobox...it would have to be someone with dual or naturalized citizenship or nationality, who is a non-citizen in at least one country. For example, someone who was born in American Samoa and also has Independent State of Samoa citizenship from parentage would be both a U.S. national (non-citizen) and Samoan citizen. What would you want to see in the infobox in such a case? -- Beland (talk) 20:48, 12 June 2024 (UTC)[reply]

Indeed. Beland's The vast majority of people are citizens of the country they are nationals of might be true-ish nowadays in the age of the nation-state, but it's not true of, say, much of medieval Europe. People were subjects of the monarch, not citizens. This even remained the legal situation in the British Empire until the 1940s, starting with the Canadian Citizenship Act, 1946 and the British Nationality Act 1948. Many people born outside Britain became British citzens with the right to settle in the UK and did so, transforming the country in many ways, until the law was changed again. NebY (talk) 20:51, 12 June 2024 (UTC)[reply]

All this is to say that we can never have a perfect solution to this. Citizenship is a much clearer word than nationality, which suggests ethnicity. As I indicated above, we should not have repetition, and if "citizenship" is given, it is because the person has moved out of the country of their birth, and it should be OK whether the person is/was a voting or nonvoting citizen, as long as they have qualified under the new country's citizenship laws, rather than just being a resident there. Further details and specifics, if needed, should be either described in the article or a footnote. -- Ssilvers (talk) 22:19, 12 June 2024 (UTC)[reply]

@NebY: Sure, but 1.) medieval and ancient biographies are a shrinking minority, because most records from that time have been lost, there were far fewer people alive, and new people keep being born, and 2.) for the vast majority of people who were non-citizen subjects of empires, we will omit both fields because status is inferred from the country of birth and either never changed because they never took an allegiance outside the empire or it changed along with almost everyone else in the country (e.g. due to independence). If how often we'd be using the field matters to whether or not we want to keep it, I can gather some statistics. I already have code that's looking at the birth century in these infoboxes to make cleanup faster. FWIW, I do know there are hundreds or thousands of people who should have been described as "British subject" by the nationality field who are instead marked with an ethnicity or colonial nationality like "Jamaican". We could help that by changing to national_of, though "National of British subject" looks more weird to me than "Citizenship British subject". -- Beland (talk) 23:19, 12 June 2024 (UTC)[reply]

FTR, looking only at British bios (including the Empire) where the nationality or citizenship field is redundant to the birth country, I see 73 (.5%) for people born in the year 2000 and later, 9191 (58%) for the 1900s, 3920 (25%) for the 1800s, and 2532 (16%) for all previous time periods. -- Beland (talk) 19:37, 13 June 2024 (UTC)[reply]

Turns out there were a lot of "unknown date" in that "all other time periods" stat. I fixed my code to report more carefully, and can report there were 924 (5.9%) from the 1700s, 515 (3.3%) from all previous time periods, and 1093 (7.0%) unknown year (mostly no birth_date specified). -- Beland (talk) 03:06, 15 June 2024 (UTC)[reply]

2¢ Per WP:INFOBOXPURPOSE, the infobox is for "key facts", a supplement to the lead and the article should remain complete without the infobox. Also, the infobox cannot capture nuance and anything in the infobox must be sourced one way or another (not OR). It is unfortunate that most infoboxes were not designed in a way that recognises these principles but more on the principle of how much can we cram into it. Consequently, they are then populated on the same principle with the view that, if there is a parameter, we should use it - like Napoleon before it was recently hacked back in size. I just looked at Guglielmo Marconi (not quite a random choice). The infobox tells us that he was born and died in Italy and an Italian Senator but also lists his nationality as Italian. The opening sentence states he was an Italian^[1][2][3][4] inventor [though the number of references suggest doubt]. Isn't nationality in the infobox redundant here? We also see from the discussions here there is quite a lot of nuance to nationality and citizenship and these are somewhat modern concepts (but not exclusively - after all, what have the Romans ever done for us apart from the aqueducts and ...). These terms are round holes that don't correspond neatly to reality in many cases. What is sometimes important is what they identified as (ie a demonym rather than more strictly defined terms). This may not be a constant over their life, which is nuance in itself. Some principles to consider for bios: If it isn't in the lead's prose, it probably isn't a key fact. If it is fairly self evident, it is redundant. If it isn't fairly self evident, it is probably too nuanced for the infobox. If their notability isn't intimately tied to their nationality (or any other such distinction we might make) it isn't a key fact. In short, we can probably live without all such terms in infoboxes and it would be for the better. Cinderella157 (talk) 01:08, 13 June 2024 (UTC)[reply]

So what’s the solution? What about cases where people are born in one country but move to another one at an early age and the article clearly states they’re a national of the second one? Kay girl 97 (talk) 04:32, 26 June 2024 (UTC)[reply]

In the majority of cases, it would be better to use the citizenship field. CMD (talk) 04:50, 26 June 2024 (UTC)[reply]

What if we combine both of them into a parameter called |country=, displayed as Country or Nation? WhatamIdoing (talk) 02:57, 29 June 2024 (UTC)[reply]

What would that...mean? A person can be associated with one or more countries through birth, parentage, ethnicity, residence, citizenship, sports team... -- Beland (talk) 07:30, 29 June 2024 (UTC)[reply]

I don't think the infobox is the place to explore complex issues. Place of birth is simple enough. Citizenship can be useful, particularly if the person's whole notable career was in a single country that was not their country of birth. If the person has a more complex history of emigration, being "based" in other countries or otherwise "belonging" to other countries, then the body of the article can and should explain, and the infobox should refrain from introducing misleading, incomplete factoids. -- Ssilvers (talk) 17:50, 29 June 2024 (UTC)[reply]

@Beland, if we switch to a "country" model, a person who is associated with one or more countries could have both listed. A "country" approach is no more likely to have disputes about whether someone is "really" from that country than what we've already got with nationality and citizenship, and it is much less likely to have someone try to claim that "African-American" or "Jewish" is a "country". WhatamIdoing (talk) 22:09, 29 June 2024 (UTC)[reply]

Agree with WhatamIdoing… except I would have the parameter in the plural (“Countries”)… to make it clear from the outset that we can put more than one. Blueboar (talk) 22:28, 29 June 2024 (UTC)[reply]

I can see why that would be desirable for the purpose of coralling editors into following the guidelines, but my point is that for readers it would be rather vague. It doesn't specify any particular sort of relationship between the person and the countries listed, so it leaves readers to guess what is meant or read the article body. -- Beland (talk) 22:36, 29 June 2024 (UTC)[reply]

A "country" field is a very poor idea; ignore perhaps the immediate bunfight we would have in UK articles, it can get very vague going back in time. It raises exactly the sort of complex question we should be avoiding (pretty similar ones to the existing nationality field). Do we have regular issues about the citizenship field? CMD (talk) 01:17, 30 June 2024 (UTC)[reply]

Other than cases where it should be omitted because it's the same as the birth country (tens of thousands of instances), the problems I've seen with current practice are anachronistic errors where people are assigned citizenship of a colony instead of e.g. British subject (though this is also true for birth places), lack of explanation as to why it's not the same as country of birth or residence (nearly all the time), lack of citation (nearly all the time), and no indication that citizenship changed when the country itself changed status (e.g. independence from a colonial power). -- Beland (talk) 04:57, 30 June 2024 (UTC)[reply]

For cases where it's unclear which administrative level is appropriate to list for birth country, I always list both if there's no dispute that X is part of Y. Generally this is "Colony Name, Empire Name", but the same solution could be applied to the UK home nations in lists of countries, e.g. "Wales, UK; France". Looking at birthplaces as they currently appear in infoboxes, "UK" is omitted for about 85% of bios (on my todo list) where Wales is listed in the birth_place field. For those that list "UK" in birth_place, the home nation is omitted about 30% of the time.

Actually, I wonder if it should be a rule that both levels are always included in birth places for UK bios. This would help readers who don't know that e.g. Wales is part of the UK, and also those who don't know which home nation e.g. Birkenhead is in.

We generally seem to consider any entity listed in ISO 3166-1 as the top-level birth country. So for example, we don't write "Puerto Rico, United States" which would be disputed by editors pointing to the "belongs to but is not a part of" legal situation. -- Beland (talk) 19:31, 30 June 2024 (UTC)[reply]

In complex cases (where more than one country applies) I would think we would want the reader to go beyond the info-box and read the article. Blueboar (talk) 01:38, 30 June 2024 (UTC)[reply]

Sure, but if they need to read the article to understand what's going on, is it useful to have the field in the infobox? If the relationship is unspecified, will editors degree on which aspects of association with a country should be counted in populating this field? -- Beland (talk) 04:52, 30 June 2024 (UTC)[reply]

I think it would be very useful… populating the field with multiple countries alerts the reader to the fact that the subject has ties to multiple countries… (perhaps they moved… perhaps borders changed… perhaps they live in one place, but champion a cause in another… etc etc). Populating the field with multiple countries tells the reader that, in this case, things are complicated and that they need read further to understand why. Blueboar (talk) 12:31, 30 June 2024 (UTC)[reply]

So in the New Hampshire Grants case mentioned above, you would want the infobox to say something like "Countries Province of New York or Province of New Hampshire in British Empire (disputed), Vermont Republic, United States"? Or would this list be omitted under the rule that it's the same as the birth country, and only changed because the birth country status changed and not because the person moved?

Many Native Americans are currently listed in their infoboxes as having citizenship both to a native nation and the United States. If we add residence to the criteria for inclusion on the "Countries" list, under McGirt v. Oklahoma, parts of the Tulsa, Oklahoma metro area are considered to be Cherokee and Muscogee territory. Some people who live there are Cherokee citizens who also have US and Oklahoma citizenship, and some are descendants of white settlers who only have US and Oklahoma citizenship. Would we want to add "Cherokee" to the biographies of some white people based on where in the Tulsa metro area they live or were born (pretty hard to determine) or not have "Cherokee" on the list of countries because it's not fully sovereign and thus drop the most important affiliation from the infobox, or have some other rule? -- Beland (talk) 18:51, 30 June 2024 (UTC)[reply]

I don't think that last one will prove to be as complicated as it sounds. We can't add anything that can't be found in a source. Therefore, in the absence of a source affirming that the person was born in Cherokee or Muscogee territory (whichever is relevant), then we should not include it. That requirement alone solves nearly all of them. WhatamIdoing (talk) 23:53, 30 June 2024 (UTC)[reply]

If we do find such a source, however, what should be put in the infobox for that person? -- Beland (talk) 00:18, 1 July 2024 (UTC)[reply]

Why not list both, then? We could say something like "Tulsa, Oklahoma, US and Cherokee Nation reservation". WhatamIdoing (talk) 00:57, 1 July 2024 (UTC)[reply]

Adding "and Cherokoee Nation reservation" for an Oklahoman who isn't Cherokee seems a bit misleading, and Ssilvers would object that it's not related to that person's notability. If it's just a random quirk of geography that's not particularly relevant to the person's life, it is arguably not worth highlighting in such a prominent location. -- Beland (talk) 03:23, 1 July 2024 (UTC)[reply]

You should only include what's relevant, and I would expect in this case for reliable sources to normally only mention this particular situation when it is relevant. WhatamIdoing (talk) 02:01, 2 July 2024 (UTC)[reply]

Imo nationality of pre-modern states is a pointless concept to reduce to an infobox parameter, and I'm certain this has been discussed both here and in Template Talk:Infobox person before. Legal citizenship becomes similarly problematic when you go too far back. The common cutoff I see people casually use for the modern (European) state is the 1814 Congress of Vienna, but even that's too early for a lot of places that simply did not exist until much later (such as Germany and several other modern polities in Central and Eastern Europe, and that's just Europe).

I agree that citizenship is the most direct parameter to contain within an infobox, while anything else would just be too volatile. If there has to be a rule of thumb on historical citizenship, maybe it should be the rules of citizenship for the modern country -- like, how does modern Serbia interpret someone re-entering the country with former Yugoslav citizenship, for example. SamuelRiv (talk) 06:13, 13 September 2024 (UTC)[reply]

Not exactly sure what you mean about re-entering a country with a citizenship that no longer exists. Whether or not Serbia recognizes Yugoslav citizenship in any special way is somewhat irrelevant to the question of whether or not Wikipedia says that someone was in the past a citizen of Yugoslavia.

Serbia's rules do matter in defining who got citizenship at the creation of the country. For example, for someone who was born in Belgrade, Yugoslavia and currently has only Serbian citizenship, we would just omit the field. For someone born in Zagreb, Yugoslavia who got Serbian citizenship later, I would expect "citizenship=Yugoslavia, Croatia, Serbia" or "citizenship="Yugoslavia, Serbia", depending on their actual personal timeline. -- Beland (talk) 18:29, 13 September 2024 (UTC)[reply]

What does "ties" mean? Rishi Sunak was born in the UK, has grandparents from India and Pakistan, has a father from Kenya and a mother from Tanzania, studied, worked, and gained residency in the United States, and married an Indian citizen. Which of these, or others, make it into the infobox? Birthplace and Citizenship are fields that much more rarely raise such value judgements. CMD (talk) 01:34, 1 July 2024 (UTC)[reply]

I think in that case you would only mention the UK. Your parents' ties/places of origin are not really your own. WhatamIdoing (talk) 02:03, 2 July 2024 (UTC)[reply]

This both sidesteps the overall question and is far more reductive than how things often work. The 2024 Summer Olympics are coming up, where Joseph Fahnbulleh will be competing for the second time. After being born and spending his life in the United States, he went to the 2020 Summer Olympics to represent Liberia, for which he was no less than a flag bearer. CMD (talk) 02:20, 2 July 2024 (UTC)[reply]

[left]. Infoboxes are for key facts, not for lists of things that don't affect your notability and that should be explained clearly in the text below. -- Ssilvers (talk) 02:28, 1 July 2024 (UTC)[reply]

(Begin sarcasm) Wait… you mean infoboxes aren’t for claiming famous people as “one of us” (or, on occasion, as “one of them”)?

But, but… surely that would qualify as a key fact! (End sarcasm) Blueboar (talk) 18:58, 13 September 2024 (UTC)[reply]

No, dude. The purpose of infoboxes is to make sure that everyone knows the always key fact of where famous people died, as in: "Who was Christopher Columbus?" "He was a man who died in Valladolid, Castille." It is obviously not enough to state this in the body of the article. -- Ssilvers (talk) 21:07, 13 September 2024 (UTC)[reply]

For sportspeople

Just came across an instance that raises a question for the "drop the nationality field" project. {{Infobox basketball biography}} only has a "nationality" field, not a "citizenship" field. After some discussion at Talk:Julius Hodge with Rikster2, it appears we can and do infer nationality from the basketball rules. That is, if someone played for a national team, league rules require them to be a legal national of that country or a resident of a dependent area. However, I can't find any sources that say Julius Hodge (who was born in the United States but played on the Antigua and Barbuda national team) is a citizen of Antigua and Barbuda, as opposed to some other sort of national. Though after reading Antiguan and Barbudan nationality law, I'm not sure there's actually a difference between an A&B national vs. citizen, or if for that country those are effectively synonyms.

What should we do in these situations? It seems to me like "nationality" will often be read or written to mean "ethnicity", so I'd still like to avoid that. Many sportsperson templates seem to have a "national_team" parameter, so we could potentially add that here? That would avoid teetering on the edge of original research by inferring citizenship or nationality from team membership. We could also drop this from the infobox and leave complicated cases to the article body. -- Beland (talk) 03:29, 3 September 2024 (UTC)[reply]

... "nationality" will often be read or written to mean "ethnicity": (Notified here. I'm only commenting on this subsection) I don't think we need to bastardize the infobox for readers that have an incorrect understanding of English's nationality. To date, the basketball infobox only mentions national teams w.r.t. medals earned, in which case the country for which they competed will be adjacently shown (e.g. Derrick White). We shouldn't adopt a one-size-fits-all in assuming national team competition is equally notable among all sports segments.—Bagumba (talk) 03:53, 3 September 2024 (UTC)[reply]

As a basketball player who has played for a national team, he had to meet requirements thusly: page 5 From the FIBA manual (this is for 3x3 basketball but the rules are the same): “In order to play for the national team of a country, a player must hold the legal nationality of that country and have fulfilled also the conditions of eligibility and national status according to the internal regulations.” That absolutely qualifies inclusion in the nationality field. Frankly that’s all an infobox should need, national team representation is clear and verifiable. Rikster2 (talk) 14:07, 3 September 2024 (UTC)[reply]

It's not an error to read "nationality" as "ethnicity"; here in the States, that's how it's commonly used in casual conversation, referring to the national origin of one's family. Wikipedia templates are trying to use it in a technical sense most people aren't familiar with. I'm cleaning up the field site-wide, and I'd estimate that half of editors are not using it in the intended legal sense, and putting things like "African American". Which readers actually correctly interpret as a race or ethnicity, but those things are banned from infoboxes. -- Beland (talk) 00:17, 4 September 2024 (UTC)[reply]

I think it we want people to stop doing that, we either need to provide them with a 'correct' way to achieve their good-faith goal of recording someone's race/ethnicity, or prevent the |nationality= field from accepting anything that isn't on the pre-defined list. Template:Inflation, for example, only accepts certain country codes. We could pre-program a list of acceptable country codes, and have the infobox refuse to display anything else. WhatamIdoing (talk) 00:46, 4 September 2024 (UTC)[reply]

Rikster2 said on Template talk:Infobox basketball biography that their preferred solution was to eliminate this field entirely. Would there be any objection to doing so? I am currently going through and dropping all instances where it is simply the same as the birth country. After that's done, I could do another pass over the complicated cases and either tag them for a while to give authors time to transition that info, move the info to some other designated place, or simply drop it if the article already covers it adequately (which we could leave to inferences like "was born in" and "played on the national team for"). -- Beland (talk) 00:49, 4 September 2024 (UTC)[reply]

Rikster2 said on Template talk:Infobox basketball biography that their preferred solution was to eliminate this field entirely. Would there be any objection to doing so?: It instinctively feels like overkill. The field just needs to be used "properly", but I understand that might not happen either, esp. since infoboxes draw more drive-by edits than the same information that's in prose in the lead. It seems like an infobox MOS page might not draw the widest input. Perhaps ideas might come at WP:VPPOL on how to meld it better with the lead's MOS:NATIONALITY? Just a suggestion to cover all alternatives (I'm not passionate enough on this topic to contest it, nor do I have a better solution currently). —Bagumba (talk) 05:31, 4 September 2024 (UTC)[reply]

It's not an error to read "nationality" as "ethnicity"; here in the States ...: That's nothing more than generations of distortion by certain people to push a narrative that some citizens "really" aren't American.—Bagumba (talk) 01:41, 4 September 2024 (UTC)[reply]

It is better not to put it in the infobox and to explain the information in a more nuanced way in the article itself, unless the person is most famous for representing their country in international competition. -- Ssilvers (talk) 01:57, 4 September 2024 (UTC)[reply]

MOS:NATIONALITY is generally prominent in the lead sentence. If an infobox is just summarizing the article, it seems to follow that nationality should be present also, particularly when it cannot be inferred vis MOS:INFONAT. It seems this should be a centralized discussion/RfC, to have the lead and infobox be consistent, rather than making infobox decisions in isolation. —Bagumba (talk) 02:11, 4 September 2024 (UTC)[reply]

Partial strike. In prose its a bit amorphous what is being referred to, but it can be reflected more in the body, while a "Nationality" field is rigid, and editors will start enumerating verifiable, but less prominent ones.—Bagumba (talk) 02:25, 4 September 2024 (UTC)[reply]

Well, I've dropped this field from that infobox for now, and I'll see if any more unusual cases come up. -- Beland (talk) 06:11, 6 September 2024 (UTC)[reply]

If actions are to be taken on this then an actual consensus decision needs to be reached to remove it from the infobox in question. Manually striking it from one specific article is not a solution. Does this discussion serve as consensus to remove the nationality field or not (I have my doubts)? If so, someone needs to remove it as an option in Template:Infobox basketball biography. It is not appropriate to take this discussion as a grounds to just remove it from one article (Julius Hodge) while it remains on hundreds of others. Rikster2 (talk) 12:09, 7 September 2024 (UTC)[reply]
Why not? Sometimes trying it out at a small number of articles is a good way to test the change and see if it's helpful. WhatamIdoing (talk) 16:07, 7 September 2024 (UTC)[reply]
- Sounds like a fun way to get around trying to make the case for consensus. Rikster2 (talk) 16:35, 7 September 2024 (UTC)[reply]
  It sounds to me like an effective way to collect some data. WhatamIdoing (talk) 17:40, 7 September 2024 (UTC)[reply]
  I do not want to "get around" consensus, because making edits that have to get undone later would be a potentially huge waste of my time and the time of other volunteers.
  That is why I have started discussions at all three levels - article, template, and manual of style. Between here and Template talk:Infobox basketball biography#Nationality and Talk:Julius Hodge, I see some editors supporting removal, some abstaining, and no firm objection. Unless someone objects or points out something I've missed, I am comfortable gently proceeding with removal. We could stop and call an RFC and ask for more opinions from people who aren't interested in basketball, if you like, but I think folks who edit basketball biographies probably care more about this than the general editor population. If they follow articles but not templates or policy pages, they probably aren't aware of this proposal. Given that there are a huge number of pages where nationality should be removed under the existing policy of dropping it when it's the same as the birth country, I can get their attention by dropping those instances and noting in the edit summary that the field is being removed entirely. Then if a crowd appears and objects to the removal, we won't have anything that needs undoing. That will also boil the question down to a relatively small number of unusual cases, which would be informative to analyze if anyone's on the fence.
  There are several levels of removal from the template:
  1. Marking the parameter as deprecated in the documentation
  2. Stopping the parameter from displaying
  3. Removing the parameter completely, causing an error message if used
  It's certainly fair to want to avoid editors adding this parameter to new articles during the removal process. I just took the first step and marked it as deprecated in the documentation, linking to this discussion. That's easily undone if anyone objects, and will help raise awareness that this is happening before most of the work gets done.
  Having a parameter that people are used to using but which suddenly doesn't show up on articles anymore may cause confusion or cause editors to think there is a bug, but I won't object to doing the level 2 change if other editors want to. I was intending on removing the parameter from all affected articles first (keeping the actual use-cases for last), and then just doing the level 3 change unless the increased attention sways the prevailing opinion. Doing the level 3 change as soon as there's consensus at the template or policy level would cause a mess in a lot of articles, which I'd rather avoid. I can put whatever change people want to see into the template sandbox for testing. -- Beland (talk) 17:56, 7 September 2024 (UTC)[reply]

If sportspeople infoboxes want to show what national team the person is playing for, and this was has indicated by the |nationality= field, then those infoboxes should probably create a separate field name to indicate national team/eligibility (because that is not an obvious overload of that parameter) and start running through AWB now to replace it. Otherwise the nationality/ethnicity/citizenship confusion that we're talking about will just persist. And of the basketball players' infoboxes already out there, how sure are you that the nationality parameter does indeed represent their FIBA eligibility, especially for those players not on their respective national teams? SamuelRiv (talk) 06:02, 13 September 2024 (UTC)[reply]

Well, my opinion was about dropping the field completely from the infobox. My opinion about this specific article is that, if the field exists in the infobox, that it should be kept because it is a clear case of split/dual nationality. Thanks for giving me the opportunity to be 100% clear

Also, just to be clear, no other editor has agreed to your proposed changes to nationality at Talk:Julius Hodge as I write this. Rikster2 (talk) 19:19, 7 September 2024 (UTC)[reply]

Well, of the participants on Talk:Julius Hodge, you've said you want the field removed from the template entirely, I support that, and it's unclear to me what DaHuzyBru thinks about complete removal. I invite them to give their opinion here if they have one.

Given that you would like to have the field removed from the template entirely, in what order would you like the changes implemented? (The needed changes being: remove from articles instances with same country as birthplace, remove from articles remaining instances like dual nationality, stop the field from displaying, and cause the template to emit an error if used.) -- Beland (talk) 20:01, 7 September 2024 (UTC)[reply]

It already gets removed in cases where the nationality matches the birth country. As long as it is a field in the infobox that is the only situation where it should be removed. Cases of split nationality like Julius Hodge are the reason the field was kept at all I assume. Rikster2 (talk) 15:19, 11 September 2024 (UTC)[reply]

I wrote a script to check. Out of 21688 transclusions, 3835 have a single nationality that is the same as the birth country, and another 3098 that list a US state with American nationality. I will start by removing those with a deprecation edit summary, as proposed.

There are under 200 cases of dual nationality. Hundreds of bios are for people who have moved from one country to another but have only one nationality listed, and people who were born in a country that no longer exists (like Yugoslavia or the USSR). -- Beland (talk) 01:55, 12 September 2024 (UTC)[reply]

Removing "American" when they were born in the U.S. is purely MOS:INFONAT, it's not related to any potential deprecation. —Bagumba (talk) 13:49, 14 September 2024 (UTC)[reply]

Sure, I'm just advertising the deprecation in edit summaries, since I'm touching the same field in articles that use the template. -- Beland (talk) 15:41, 14 September 2024 (UTC)[reply]

Sign language translations in infoboxes

Has there been discussion before of how (or whether) to include sign languages in infoboxes? There has been a request at Talk:New Zealand#New Zealand Sign language video request, but once adequate media has been found or generated, I’m concerned that simply pasting a graphic or video into the infobox title section isn’t going to flow the best. There are only a handful of countries with official sign languages, but the potential here is quite a bit broader. — HTGS (talk) 06:14, 25 June 2024 (UTC)[reply]

I'd suggest an icon/link to accompany the pronunciation (which is either in the lead or in a footnote) instead. Nikkimaria (talk) 03:51, 26 June 2024 (UTC)[reply]

INFONAT, ethnicity and fictional characters

Seeing as everyone’s having so much fun discussing MOS:INFONAT: Does INFONAT apply to fictional characters? I lean slightly towards a no myself, so I figure I should check in. I ask following the addition of “Italian-American” to the Nationality field of Adriana La Cerva’s infobox (diff). Although I don’t think “Nationality” is the right field, I wonder if the fact of her ethnicity is at least worth considering as an important part of the characterization; that is, should it be down to editorial judgement, rather than being verboten by MOS? Or does this just open every (non-generically-white) character up to including their race in their infobox? — HTGS (talk) 23:09, 10 July 2024 (UTC)[reply]

Yes, I would apply the same standards to fictional people for those fields. Italian-American is an ethnicity, and so should not be in an infobox, and neither should religion. I'll drop those now. -- Beland (talk) 03:09, 3 September 2024 (UTC)[reply]

Italian-American is an ethnicity, and so should not be in an infobox doesn't come from anything though? The reason we don't list it in biographies is because the idea of real, human ethnicity is too complex to pin down in such a field. The ethnicity or religion of a fictional character can be complex, but is often simple and deliberate, as written by the creator. For Daredevil (Marvel Comics character), the answer of religion is straightforward, explicit and central to the character, it could certainly be argued that for Tony Soprano et al, their ethnicity is just as central. I'm happy to go along if there's good reason, but I can't see a rationale to follow if it's just "No Ethnicities in Infoboxes". — HTGS (talk) 07:27, 5 September 2024 (UTC)[reply]

For some real people, their ethnicity is just as simple and straightforward as for a fictional character, and there is no exception for them. For example, the ethnicity of Al Capone is straightforward and central to his life and occupation, but is not listed in his infobox. Reading the 2016 RFC on the "ethnicity" field, I see comments that say something like: the arguments and inaccuracy that would result from having this field available for complex cases is not outweighed by the benefit this field would provide in simple cases. -- Beland (talk) 16:37, 5 September 2024 (UTC)[reply]

There was also a 2016 RFC on the religion field. It has been removed from real-person biography infoboxes except for Template:Infobox religious biography, which only seems to be used for people with a religious occupation or who are part of the content of a religion. It seems consensus is not to include this field for people who simply have a strong faith-based motivation for some other occupation, which I assume is the Daredevil's situation. -- Beland (talk) 16:45, 5 September 2024 (UTC)[reply]

Ok, that's fine. I guess I just fall slightly further over on the spectrum between “This is useful for some cases” and “This will be a major temptation for most cases”. And as much as I agree with most of our userbase’s liberal atheist attitude, I suspect it goes too far at some points. (On that note, Daredevil’s article doesn’t mention his Catholic faith at all, despite it having a massive amount of coverage in sources, so maybe I’ll go bother that article, and leave this alone for the time being.) — HTGS (talk) 22:29, 5 September 2024 (UTC)[reply]

Following up on implementation of cleanup at Template talk:Infobox character. -- Beland (talk) 05:58, 6 September 2024 (UTC)[reply]

Tree lists

It seems different editors have different tastes regarding how {{Tree list}} should be used versus other list types. My impulse was they shouldn't be used at all in infoboxes, since they are visually noisy. The more I think about it, the more they seem fine, if a bit noisier than combining plain, definition, and lists like I am usually in the habit of doing. If there's more than one level of depth, it's probably not fit for an infobox to begin with, and so excludes the situation where tree lists could clearly be a superior choice. Remsense ‥ 诉 00:29, 17 August 2024 (UTC)[reply]

I would agree with the observation that these are noisy. There are cases of multiple levels (ie more than two) where tree lists might be appropriate. However, in an infobox, this would suggest a level of detail at odds with WP:INFOBOXPURPOSE. Cinderella157 (talk) 02:09, 17 August 2024 (UTC)[reply]

Duplication of images in infobox and body

Should an image that appears in the infobox also appear in the body of the article? (I would have thought that we do not duplicate images in this way, but if so, I would have thought that infobox images would be mentioned as one of the exceptions, where something may be placed in the infobox, but not in the body.) Nurg (talk) 23:40, 3 September 2024 (UTC)[reply]

Generally we should not, but infobox images are so small, there may be cases (articles on paintings for example) where a repetition is justified. Johnbod (talk) 00:01, 4 September 2024 (UTC)[reply]

Indeed. Some infoboxes have very many small images and are unstable too (e.g. Rome). Shuffling images out of reasonable placements and sizes in the body of the article because someone's put a tiny version in the infobox, then shuffling them back again with the next infobox change, could become quite disruptive. NebY (talk) 09:48, 4 September 2024 (UTC)[reply]

Lists in the |title= parameter

I just wanted to point to a recent dispute about how the |title= parameter for {{Infobox royalty}} at Talk:Xerxes I should be used. Remsense ‥ 论 23:21, 7 October 2024 (UTC)[reply]

Consistency among office holders

If a numbering is removed from an office holder's infobox. Should it be removed from that individuals' predecessors & successors' infoboxes? GoodDay (talk) 15:07, 12 October 2024 (UTC)[reply]

Or to put it another way, should you have added numbering to one office in one article[8], slow-editwarred to keep your insertion on the grounds of consistency[9][10], requested page protection to keep your addition[11] and then come here to seek a general ruling that reverting your addition requires comprehensive removal in other articles?

And are you proposing that in the name of Consistency among office holders we should number other offices in that article, and in articles about those holding other offices in that country, and in articles about vice-presidents in other countries? NebY (talk) 16:01, 12 October 2024 (UTC)[reply]

Numbering should only be added if "there is a well-established use of such numbering in reliable sources." Otherwise, don't add it. DrKay (talk) 17:16, 12 October 2024 (UTC)[reply]

@NebY: don't bite my head off, please. If the other editor isn't going to make the effort to delete the numbering from the related bios? Then neither will I. GoodDay (talk) 00:40, 13 October 2024 (UTC)[reply]

"end of the lead section of an article (in the mobile version)"

Есть ли причина в текущем первом предложении, где говорится, что инфобоксы появляются в «конце вводного раздела статьи (в мобильной версии)»? Всякий раз, когда я просматриваю мобильную версию, инфобоксы появляются после первого абзаца, который может быть в середине или даже ближе к началу вводного раздела. CMD ( talk ) 17:31, 16 октября 2024 (UTC) [ ответить ]

Я подправил, чтобы отразить мобильное позиционирование. CMD ( обсуждение ) 13:24, 22 октября 2024 (UTC) [ ответить ]

Почему параметр «координаты» выдает дублирующиеся координаты?

В статьях, таких как Убийство Джона Ф. Кеннеди , параметр координат приводит к тому, что координаты отображаются в правом верхнем углу страницы, а также в информационном поле. Зачем нам нужно, чтобы они появлялись дважды? Кроме того, полезны ли вообще координаты? Какой процент читателей вообще знает, как их интерпретировать? Если уже есть функция карты, нужны ли вообще координаты, не говоря уже о том, чтобы дважды? ~ HAL 333 (ГОЛОСОВАТЬ!) 16:19, 23 октября 2024 (UTC) [ ответить ]

Это не параметр координат сам по себе вызывает это, это фактический шаблон {{ coord }} - если вы изменили |display=inline,title, чтобы иметь только одно значение, он будет отображать координаты только в одном месте. Что касается того, должно ли это вообще отображаться, это, вероятно, вопрос для Village Pump, а не здесь. Nikkimaria ( talk ) 04:59, 24 октября 2024 (UTC) [ ответить ]

Принято с благодарностью. ~ HAL 333 (ГОЛОСУЙТЕ!) 16:16, 24 октября 2024 (UTC) [ ответить ]

Максимальная ширина изображения/ий в информационном поле

Каков оптимальный метод определения максимальной ширины изображения или группы изображений (например, национального флага и герба вместе) в инфобоксе, который задает общую ширину инфобокса? SilverBullet X (обсуждение) 16:34, 25 октября 2024 (UTC) [ ответить ]