Обсуждение в Википедии:Руководство по стилю/Связывание

Перенаправление на другую статью в инфобоксе

Джоаккино Россини
Россини одет в жилет и пальто, держит трость и смотрит за пределы кадра.
Россини в 1865 году, фото Этьена Каржа
Рожденный(1792-02-29)29 февраля 1792 г.
Пезаро , Италия
Умер13 ноября 1868 г. (1868-11-13)(76 лет)
Пасси , Париж, Франция
РаботыСписок композиций

Два дня назад я открыл обсуждение на Talk:Gioachino Rossini , чтобы обсудить добавление инфобокса. Для тех, кто может не знать, WikiProject Composers имеет старую политику , которая запрещает инфобоксы в биографиях композиторов, но это было изменено в последние годы. Этот вопрос не об этом; скорее, это о включении чего-либо в возможный инфобокс Россини.

Справа находится предложенное мной информационное поле, похожее по стилю на Моцарта , Бетховена , Шопена , Шостаковича , Прокофьева и т. д. Включение ссылки на статью «Список композиций» в параметр произведений стало предметом споров. @Gerda Arendt и я заявляем, что включение оправдано, поскольку ссылка показывает, что Россини был известен как композитор, и это стандарт для многих других статей о композиторах . @Nikkimaria возразила , что MOS:FORCELINK , которая является частью Wikipedia:Manual of Style/Linking, запрещает такие типы ссылок следующим образом: «Текст должен быть понятен читателям, которые не могут переходить по ссылкам. Пользователи могут распечатывать статьи или читать их офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок». Я утверждал, что тот самый пункт списка, который процитировала Никки, также гласит: «Используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение ». (выделено мной) Информационные поля, конечно, не являются предложениями, но Никки обнаружила, что это все еще применимо, поскольку «это делает так, что читатели могут понять суть темы статьи, только перейдя по ссылке, а именно для борьбы с этим и существует NOFORCELINK».

Итак, теперь я здесь. Я понимаю, о чем говорит Никки, и понимаю, как это может относиться к инфобоксу, но я хочу услышать мнение людей, которые часто посещают MoS и выводят иногда нечеткие формулировки. Является ли включение ссылки «Список композиций» в параметр работ нарушением MoS? MyCatIsAChonk ( talk ) ( не я ) ( также не я ) ( все еще нет ) 00:18, 4 октября 2023 (UTC) [ ответить ]

Как уже отмечалось, MOS:INFOBOXPURPOSE также актуален: «ключевые факты на первый взгляд», без необходимости гнаться за ссылками. Nikkimaria ( обсуждение ) 00:20, 4 октября 2023 (UTC) [ ответить ]
Я всегда находил ссылки на списки в инфобоксах немного странными, но они очень релевантны теме, и данные читателей показывают, что их наличие важно для того, чтобы помочь читателям найти список. Единственной альтернативой, похоже, является их исключение, что не кажется оптимальным. И аргумент NOFORCELINK кажется довольно слабым, согласно аргументу MyCat. {{u| Sdkb }}  talk 00:58, 4 октября 2023 (UTC) [ ответить ]
Кроме того, это очень широко распространенная практика, используемая в таких FA, как Taylor Swift , поэтому запрет на нее был бы существенным изменением. {{u| Sdkb }}  talk 01:02, 4 октября 2023 (UTC) [ ответить ]
Я не уверен, какой вывод вы пытаетесь сделать из метаисследования, но оно не показывает, что читатели хотят читать эти ссылки или что они считают их полезными. Все, что делает программное обеспечение для отслеживания взгляда, это видит, какие части экрана привлекают взгляд. Вот почему что-либо в рамке, изображении или маркерах всегда отвлекает взгляд от текста. Это отличается от утверждения, что читатели хотят эти ссылки или активно ищут их. - SchroCat ( обсуждение ) 09:53, 9 ноября 2023 (UTC) [ ответить ]
Я считаю, что @ Sdkb намекает на то, что эти ссылки просто полезны . Независимо от данных читателей, люди с устройствами смогут легко переходить к другой информации через это поле, а те, у кого нет устройств, увидят «Тридцать девять опер» (см. второе предложение поля ниже). Если эти ссылки нарушают MoS, почему это не было поймано на Taylor Swift FAC? Потому что эти ссылки просто полезны, и это то, что действительно волнует редакторов. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 12:00, 9 ноября 2023 (UTC) [ ответить ]
Остальная часть предложения, о котором идет речь, похоже, была удобно забыта: «Текст должен иметь смысл для читателей, которые не могут переходить по ссылкам. Пользователи могут распечатывать статьи или читать их офлайн, а содержимое Википедии может встречаться в переизданной форме, часто без ссылок». Учитывая, что вывод без ссылок — «Список произведений», я не понимаю, как этот текст без ссылок соответствует требованиям политики. Другими словами, хотя некоторые люди смогут использовать ссылку, большое количество — нет, и наша политика заключается в том, что это не должно быть разрешено. Не стесняйтесь удалять несоответствующую запись в Taylor Swift, если хотите, но WP:LOCALCONSENSUS не может отменить политику. - SchroCat ( обсуждение ) 12:05, 9 ноября 2023 (UTC) [ ответить ]
Это решаемо, если мы создадим новый параметр для ссылки на страницу списка ( |list_of_works=)) и установим класс строки данных в коде инфобокса на class="noprint". Насколько я понимаю из noprintкласса, он удалит этот фрагмент текста из закрепленных версий. Шаблон: эпизод телевидения Infobox делает это со своей ссылкой на список эпизодов. Gonnym ( talk ) 12:09, 9 ноября 2023 (UTC) [ ответить ]
Не для повторных пользователей нашего бесплатного продукта, или для тех, кто читает офлайн. - SchroCat ( обсуждение ) 12:39, 9 ноября 2023 (UTC) [ ответить ]
Невозможно победить их всех. Я предпочитаю лучший пользовательский опыт для 80% пользователей, чем посредственный для 100%. Gonnym ( обсуждение ) 12:47, 9 ноября 2023 (UTC) [ ответить ]
Но это не мешает использованию быть противоречащим установленной политике. Если это должно измениться, это должно быть переписано после RFC, который специально позволяет нам игнорировать часть наших читателей. - SchroCat ( обсуждение ) 12:49, 9 ноября 2023 (UTC) [ ответить ]
Когда вы говорите «политика», вы имеете в виду этот фрагмент текста: Используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение. Текст должен быть понятен читателям, которые не могут переходить по ссылкам. Пользователи могут распечатывать статьи или читать офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок. ? Если так, то это руководство, а не политика. Кроме того, там говорится, насколько это возможно , ну, наличие класса noprint исправляет большую часть использования, и это проверяет требование «насколько это возможно». Если вы не имеете в виду другую политику, которую я пропустил в этом обсуждении, нет необходимости в RfC, если только вы не хотите его начать. Gonnym ( обсуждение ) 12:54, 9 ноября 2023 (UTC) [ ответ ]
Если вы счастливы, что игнорируете часть читателей и не обслуживаете их, то я мало что могу сказать — или даже хочу сказать. Я бы сказал, что это противоречит всему, что мы делаем, и как таковой RFC был бы единственным способом получить мнение сообщества о доле читателей, которым мы должны обслуживать, против тех, кого мы должны игнорировать. Это позиция, которая еще менее конструктивна, чем бесконечное проталкивание IB в ряд статей, но, я полагаю, все, что угодно, плывет по течению. - SchroCat ( обсуждение ) 13:02, 9 ноября 2023 (UTC) [ ответить ]
Насколько большую пользовательскую базу (тех, кто не читает онлайн или печатные версии) мы игнорируем? У вас есть процент? Я очень сомневаюсь, что он хоть сколько-нибудь близок к тому, о чем вы предполагаете. Gonnym ( talk ) 13:09, 9 ноября 2023 (UTC) [ ответить ]
Я согласен с Nikkimaria, что это не полезно для этого инфобокса. Первое предложение в заголовке Джоаккино Россини частично говорит о том, что он получил известность за свои 39 опер , так что мы уже знаем, что он известен как композитор. И, конечно, ссылка на Список композиций Джоаккино Россини уже есть в статье, в разделе "Музыка" в {{ see also }} , так что вам не придется долго искать.
С точки зрения практичности, если бы эта ссылка была добавлена ​​в инфобокс, прошло бы немного времени, прежде чем невовлеченные редакторы обнаружили бы, что она недостаточна, поскольку не сообщает никаких фактов, и начали бы добавлять примеры, которые они считали наиболее примечательными, сохраняя список в виде ссылки под последним примером. Это переросло бы в неприятный спор между редакторами о том, какие примеры включать, какие композиции «наиболее примечательны». Высказанные предположения не нашли отражения в прошлых событиях 15:28, 4 октября 2023 (UTC)
Что касается того, является ли это нарушением MOS, я бы сказал, что это не соответствует WP:INFOBOXPURPOSE , как отмечено. Это не быстрый существенный факт о предмете, что в Википедии есть статья о списке его композиций. Folly Mox ( обсуждение ) 00:58, 4 октября 2023 (UTC) [ ответ ]
Я должен пояснить, что ссылки на списки в инфобоксах не плохи во всех случаях. Особенно в отношении моего второго абзаца, если бы существовало общепринятое подмножество композиций, которые, как все знают, являются наиболее примечательными, это не проблема. У вас есть лучшие примеры со ссылкой на все внизу этого поля. Это очень полезно для обнаруживаемости, как отмечает Skdb выше в редактировании, с которым конфликтует мое.
Проблема в этом случае в том, что если не существует такого согласованного подмножества наиболее примечательных композиций, вы в конечном итоге вернетесь к отсутствию вообще. Folly Mox ( обсуждение ) 01:03, 4 октября 2023 (UTC) [ ответить ]
Быстрая мысль: будет ли что-то вроде Оперы, Кантаты и многое другое достаточно фактическим или будет противоречить WP:EASTEREGG или другой хорошей практике? NebY ( обсуждение ) 12:57, 4 октября 2023 (UTC) [ ответить ]
Я не совсем постоянный пользователь MOS, как ищет User:MyCatIsAChonk : я просто наблюдаю за несколькими страницами. Посмотрев, как инфобоксы в биографиях гуманитариев традиционно реализовывали это без проблем, и учитывая аргумент полезности, представленный выше User:Skdb , я чувствую, что хотя просто голая ссылка на другую статью не полностью соответствует MOS:INFOBOXPURPOSE , она служит читателю.
Сказав это, для этого случая есть дополнительная проблема в том, что Список опер Джоаккино Россини уже был отделен от Списка композиций Джоаккино Россини , который связывает его как «см. также» в своем первом подзаголовке lvl2. Если в главном предложении статьи говорится, что Россини «приобрел известность благодаря своим 39 операм» , это то, что я ожидаю увидеть в информационном поле, если ссылка включена в этот параметр. Если он примечателен остальными своими композициями, аналогично его известности из опер, мы могли бы связать обе статьи и обновить главное предложение, чтобы отразить это. Folly Mox ( обсуждение ) 15:26, 4 октября 2023 (UTC) [ ответ ]
Джоаккино Россини
Россини одет в жилет и пальто, держит трость и смотрит за пределы кадра.
Россини в 1865 году, фото Этьена Каржа
Рожденный(1792-02-29)29 февраля 1792 г.
Пезаро , Италия
Умер13 ноября 1868 г. (1868-11-13)(76 лет)
Пасси , Париж, Франция
Работы

@ Folly Mox , я совершенно не знал о списке опер, как глупо с моей стороны. Справа предложение два , с похожим форматом на Taylor Swift- мысли? MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 20:53, 4 октября 2023 (UTC) [ ответить ]

Может быть, это должны быть «Оперы» и «Другие композиции», однако? В конце концов, оперы — это тоже композиции. Gawaon ( talk ) 21:45, 4 октября 2023 (UTC) [ ответить ]
Это имеет больше смысла, спасибо - обновлено соответствующим образом. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 21:49, 4 октября 2023 (UTC) [ ответить ]
Может быть, Тридцать девять опер или что-то в этом роде, по принципу WP:EASTEREGG , по которому Оперы обычно должны ссылаться на Оперы и делать масштаб понятным даже без нажатия на ссылку? NebY ( обсуждение ) 08:06, 5 октября 2023 (UTC) [ ответить ]
Ну, в вышеупомянутом информационном окошке Тейлор Свифт не написано «10 альбомов» или «59 синглов»; там просто указаны альбомы, синглы и т. д. При этом, скорее всего, рядовой читатель будет гораздо лучше знаком с современными музыкальными практиками, чем с оперой, но как вы думаете, играет ли эта знакомость какую-то роль? MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 10:56, 5 октября 2023 (UTC) [ ответить ]
Один компромисс заключается в том, что если мы указываем номер, то нам затем приходится обновлять его всякий раз, когда номер меняется. Это, очевидно, меньше беспокоит BDP, чем кого-то в середине карьеры. {{u| Sdkb }}  talk 14:23, 5 октября 2023 (UTC) [ ответить ]
Очень хорошее замечание, я согласен - обновлено MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 15:25, 5 октября 2023 (UTC) [ ответить ]
Идея назвать ссылку «Тридцать девять опер» элегантно реализует принцип MOS:INFOBOXPURPOSE «ключевые факты с первого взгляда». Возможно, стоит включить его сюда или хотя бы в Wikipedia:Manual_of_Style/Infoboxes , поэтому я предложил его там. ◅  Себастьян Хельм  🗨 11:52, 23 октября 2023 (UTC) [ ответить ]
Большое спасибо. Я, скорее всего, открою RfC в Rossini, как только обсуждение там завершится. MyCatIsAChonk ( обсуждение ) ( не я ) ( тоже не я ) ( все еще нет ) 15:29, 23 октября 2023 (UTC) [ ответить ]
К вашему сведению
Участникам этого обсуждения может быть интересен этот RfC по той же теме: Wikipedia_talk:Manual_of_Style/Infoboxes#MOS:INFOBOXPURPOSE_and_links_to_related_articles . Sdkb  talk 03:31, 8 марта 2024 (UTC) [ ответить ]

После обсуждения в Википедии: Руководство по стилю/Ссылки/Архив_21#DL,_разделы,_и_мобильные_ридеры RFC, в котором было продемонстрировано единодушное мнение в поддержку смягчения правила «один раз на статью» для ссылок до «один раз на раздел», закрывающий RFC Майк Кристи внес совершенно разумную правку с целью наименьшего нарушения работы страницы, изменив введение MOS:DUPLINK следующим образом:

Как правило, ссылка должна появляться в статье только один раз , но она может повторяться, если это полезно для читателей, например, в информационных полях , таблицах, подписях к изображениям, сносках , примечаниях и при первом появлении.после свинцав разделе.

Разумно, конечно. Наименее разрушительно, конечно. Но... точно?

Сейчас, как никогда ранее, фактические правила, которые мы установили, противоречат утверждению: «Как правило, ссылка должна появляться в статье только один раз ». Независимо от того, было ли это верным раньше (учитывая длинный список исключений), после RFC это, безусловно, больше не кажется правильным.

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

ИМХО, нам следует стиснуть зубы, принять перемены и начать с чего-то вроде:

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

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

FeRDNYC ( обсуждение ) 15:47, 21 декабря 2023 (UTC) [ ответить ]

Мне это кажется разумным и точным изложением того, чем мы на самом деле занимаемся, хотя его можно было бы значительно сжать:

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

Похоже, это позволяет донести те же сообщения гораздо меньшим количеством слов.  —  SMcCandlish ☏ ¢  😼  01:52, 18 января 2024 (UTC) [ ответить ]
Звучит хорошо для меня. Gawaon ( обсуждение ) 14:25, 24 января 2024 (UTC) [ ответить ]

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

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

В любом случае,  готово FeRDNYC ( обсуждение ) 08:51, 22 марта 2024 (UTC) [ ответить ]

кто-то ... даже втиснул в сноску излишне многословное объяснение точно-неточного контекстного значения слова "major" Хех, оказывается, это тоже дело рук SMcCandlish ! FeRDNYC ( обсуждение ) 08:56, 22 марта 2024 (UTC) [ ответить ]
Спасибо за небольшую нормализацию материала; часто встречаются фрагменты «отстающего» текста, которые требуют доработки после столь существенного изменения, как прекращение «только одна ссылка на статью». Сноску можно сократить в некотором роде, но она основана на множестве иногда противоречивых соображений и является наилучшим балансом, который я смог между ними найти. Подробности см. на уровне #Section и в дублирующей ссылке.  —  SMcCandlish ☏ ¢  😼  10:14, 22 марта 2024 (UTC) [ ответить ]

Редактировать запрос

добавлять

−
+
{{пп-полу-неопределен|маленький=да}}

103.253.27.33 ( обсуждение ) 22:32, 14 января 2024 (UTC) [ ответить ]

 Готово Largoplazo ( обсуждение ) 01:01, 15 января 2024 (UTC) [ ответить ]

В настоящее время NOFORCELINK говорит Используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение. Текст должен быть понятен читателям, которые не могут переходить по ссылкам. Пользователи могут распечатывать статьи или читать их офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок. . Буквальное толкование этого Мое толкование этого заключается в том, что оно требует, чтобы каждое слово, которое можно было бы считать специальным (« турбовинтовой », « экшн-платформер », « преобразование Лапласа », « форзац », ...), было объяснено в тексте. Я считаю, что это невозможно и было бы плохим написанием, если бы это было возможно. Это уже всплывало раньше , поэтому я свяжусь со всеми, кто был в этом разговоре, но то, что побудило меня опубликовать здесь, это то, что я увидел запрос от Гога Мягкого в текущем FAC (номинированном Aoba47 ) на разъяснение «экшн-платформер». Я думаю, что запрос Гога согласуется с тем, что на самом деле говорит NOFORCELINK, но я не думаю, что изменение, которое они просят, желательно.

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

Я предлагаю вставить в NOFORCELINK форму слов, которая кодифицирует цитируемый "руководящий принцип". Я думаю, это будет трудно сделать, потому что мы не можем явно дать локальное обсуждение в WikiProject полномочия по сравнению с другими редакторами - это точка WP:LOCALCONSENSUS, о которой часто говорит SMcCandlish , и он совершенно прав. Я думаю, что стоит попытаться сделать, потому что в его нынешнем виде NOFORCELINK не имеет пункта об освобождении для редактора, который утверждает, что "драка за скамейку запасных" требует пояснения в тексте в статье о бейсбольном матче. Пример NebY в предыдущем обсуждении пародирует то, как будет выглядеть такая статья, и является лучшим аргументом, чем все, что я мог бы придумать.

Если мы не можем добавить что-то вроде этого, то, по крайней мере, нам следует ослабить руководство, чтобы было ясно, что есть исключения. Математика — самое очевидное исключение, как мне кажется, но формулировка должна яснее показывать, каковы пределы «насколько это возможно», и ослабить или убрать «Текст должен быть понятен читателям, которые не могут переходить по ссылкам».

Пинг из предыдущего обсуждения и текущего FAC: J Milburn , Lee Vilenski , Bagumba , Uanfala . Mike Christie ( обсуждение - вклад - библиотека ) 22:52, 17 января 2024 (UTC) [ ответить ]

Хотя, как всегда, я готов выслушать другие мнения, моя первая мысль о том, что «если знающие читатели считают, что поток слишком сильно прерывается встроенными объяснениями, не знающие читатели должны принять это и быть готовыми принять ссылки вместо этого или, если это абсолютно необходимо, пояснительную записку», — не согласиться. Мы энциклопедия , мы здесь, чтобы объяснять вещи не знающим читателям — это на самом деле наша миссия. Кодифицировать генерацию языка внутри группы и статей, которые можно понять, только если вы их уже понимаете, — это признание провала проекта. И я не считаю, что создание соломенного чучела во вступительных замечаниях — «Буквальное толкование этого требует, чтобы каждое слово, которое можно было бы считать специальным (« турбовинтовой », « экшн-платформер », « преобразование Лапласа », « форзац », ...), было объяснено в тексте» — полезно. Gog the Mild ( обсуждение ) 23:11, 17 января 2024 (UTC) [ ответить ]
Справедливое замечание по поводу соломенного чучела, поэтому я его вычеркнул и перефразировал. И я принимаю вашу общую точку зрения, но можем ли мы согласиться, что по мере того, как статьи становятся все более и более специализированными, спускаясь по фрактальному дереву той или иной темы от обзорной статьи до узкоспециализированных статей, таких как сноп (математика) , в конечном итоге NOFORCELINK становится активно бесполезным? Я утверждаю, что мы должны признать этот факт в формулировке. Майк Кристи ( обсуждение - вклад - библиотека ) 23:16, 17 января 2024 (UTC) [ ответить ]
Конечно, можем, и тогда мы сможем поторговаться о том, где провести черту. Можем ли мы также согласиться, что что бы ни было решено, это касается только FAC? Это не имеет никакого значения для любой статьи, не относящейся к FA, никто не собирается удалять текст за несоблюдение. GAN (и ACR) даже институционализировали несоблюдение. Gog the Mild ( обсуждение ) 23:37, 17 января 2024 (UTC) [ ответить ]
И я действительно с трудом понимаю, как «насколько возможно» равно «требует, чтобы каждое слово». Это просто не так, это требует «насколько возможно», и не более того. Так что сноп (математика) уже имеет свой «выход», и я с интересом жду, что там можно обсудить. Гог Мягкий ( обсуждение ) 23:37, 17 января 2024 (UTC) [ ответить ]
Оставив свое мнение в стороне, еще раз «ослабьте или удалите «Текст должен быть понятен читателям, которые не могут переходить по ссылкам».  ', вы пропустили это мимо людей, занимающихся доступностью? Их возражение обычно воспринимается как конец дискуссии. Gog the Mild ( обсуждение ) 23:47, 17 января 2024 (UTC) [ ответить ]
Я не думаю, что это совпадение, что заметив обсуждение FAC по этому поводу, я пришел сюда, так что вы правы — это, безусловно, будет в основном FAC, где это уместно. (На самом деле, это означает, что я должен опубликовать заметку об этом обсуждении в WT:FAC. Я сделаю это в следующий раз.) Но данные указания должны быть правильными, независимо от того, правда это или нет. Нет, я не спрашивал о доступности, но хорошая мысль, поэтому пингую Graham87, который всегда помогает в таких вопросах. Также пингую Дэвида Эппштейна , который, как я знаю, внес вклад в такого рода обсуждение в прошлом. Майк Кристи ( talk - contribs - library ) 00:17, 18 января 2024 (UTC) [ ответить ]
Я не думаю, что это имеет какие-либо особые последствия для пользователей с ограниченными возможностями. Graham87 ( обсуждение ) 03:12, 18 января 2024 (UTC) [ ответ ]
Я полностью согласен с мнением Майка Кристи, что буквальное объяснение каждого технического слова во многих случаях отправит нас вниз по бесконечной кроличьей норе подобъяснений и подпод-подобъяснений до такой степени, что ни один читатель не сможет прочитать статью. Обычные читатели не могут ее прочитать, потому что у них нет опыта усвоения всех подобъяснений по всей цепочке, а эксперты не могут ее прочитать, потому что они не могут найти фактическое содержание среди всех объяснений «Как вы знаете, Боб» вещей, которые они уже знают. Нам нужна золотая середина. Я думаю, что WP:ONEDOWN хорошо справляется с заданием целевой аудитории и, следовательно, устанавливает уровень того, какие термины требуют расширения и что можно предположить. Любое дальнейшее расширение за пределы этого уровня не поможет, потому что люди, находящиеся на уровень ниже, еще не готовы понять статью, и поэтому попытки сделать статью понятной для них бесполезны. Даже одного уровня расширения может быть слишком много. Например, текущее руководство по простым числам гласит: Простое число (или простое число ) — это натуральное число, большее 1, которое не является произведением двух меньших натуральных чисел. Здесь термины «натуральное число» и «произведение» связаны, но не объяснены, потому что если вы не знаете, как считать и умножать, вы не готовы узнать о простых числах. «Больше чем» не связано, но находится в одной лодке. Это не столько вопрос доступности, сколько вопрос того, чтобы сделать наши статьи самодостаточными для тех, кто может извлечь пользу из их прочтения. — Дэвид Эппштейн ( обсуждение ) 00:40, 18 января 2024 (UTC) [ ответить ]
У нас было много проблем с этим в прошлом, и это имеет репутацию одной из самых неприятных частей MOS. Это напрямую противоречит WP:SUMMARYSTYLE . Это требует, чтобы каждая ссылка была объяснена. Наше обычное решение в FAC и GA заключается в том, что мы не обязаны соответствовать MOS. Это было добавлено без консенсуса в 2015 году. [1] Настоятельно рекомендуем восстановить исходную версию: не заставляйте читателя без необходимости гоняться за ссылками: если технический термин можно просто объяснить несколькими словами, сделайте это. Hawkeye7 (обсудить) 00:50, 18 января 2024 (UTC) [ ответить ]
Категорически не согласен. Это нехорошее правило, потому что оно не создает метод, который заканчивается ограниченным числом расширений. Вполне возможно иметь высокотехнический термин, который можно просто объяснить с помощью очень небольшого количества слов, некоторые из которых сами по себе являются высокотехническими, но их можно просто объяснить с помощью очень небольшого количества слов, некоторые из которых сами по себе являются высокотехническими, но их можно просто объяснить с помощью очень небольшого количества слов и т. д. Фактически, цепочка объяснений может быть даже циклической. Нам нужно правило, которое указывает нам уровень объяснения, который подходит: какие высокотехнические термины нуждаются в расширении, потому что они являются техническими даже для людей, готовых прочитать статью, и какие высокотехнические термины следует оставить, потому что если вы их еще не понимаете, вы также не поймете ничего из того, что следует за ними. WP:ONEDOWN — это такое правило. — Дэвид Эппштейн ( обсуждение ) 00:58, 18 января 2024 (UTC) [ ответить ]
Да, мы уже это обсудили. И «не заставляйте читателя использовать эту ссылку, чтобы понять предложение» не означает «сделать материал понятным пятилетнему ребенку», это означает, что если предложение откровенно сбивает с толку среднестатистического читателя, то, вероятно, нужно его прояснить. Сбивает с толку означает «не уверен, что означает это слово», сбивает с толку означает «даже не может толком проанализировать предложение как осмысленное». Любая из наших статей по физике (если выбирать техническую тему наугад), например, гравитон и теория струн , и даже элементарные частицы, содержат множество технических терминов из главного предложения, но даже тот, кто не знает наверняка, что большинство из них означает, может извлечь хотя бы голую суть, даже если ему придется поискать что-то в словаре. Если они вообще не понимают ни одного из этих терминов, то им нужно начать с более базовой статьи. Мы не собираемся прямо в первом предложении объяснять, что такое квант, что такое физика, что такое частица, что такое точка, что такое гравитация и т. д. Все такие статьи, вероятно, можно было бы улучшить, но они не являются фундаментально сломанными.  —  SMcCandlish ☏ ¢  😼  01:44, 18 января 2024 (UTC) [ ответить ]
Всегда будет место для разногласий по поводу того, какие технические термины требуют объяснений, а какие нет, потому что у разных людей разный уровень знаний. Я знаю, что такое гравитон, но не знаю, что такое экшн-платформер . Это также может зависеть от типа статьи и от того, можно ли ожидать, что ее читатели будут знать термин. Я думаю, что этот вопрос наиболее важен в процессах FAC и рецензирования контента; я обычно объясняю термин, когда меня спрашивают, если только он не является интуитивно понятным для неспециалистов.

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

Jo-Jo Eumerus ( обсуждение ) 09:33, 18 января 2024 (UTC) [ ответить ]
Моя интерпретация того, как это должно работать, заключается в том, что важно объяснять информацию, которая требуется для понимания содержания. Если взять формулировку из моего поля зрения, то что-то вроде Джон Хиггинс сделал сенчури-брейк 104. - сенчури-брейк - это фраза, которая в текущей формулировке должна была бы объясняться в каждой статье о снукере как "серия ударов, которая дает счет более 100 за один ход", что является излишеством, за исключением статьи, на которую мы ссылаемся. Однако вы можете легко перейти от этого предложения, если вы не знаете, что такое сенчури-брейк, достаточно знать, что он что-то сделал.
Разница в том, когда информация требуется для будущего чтения в этой статье. Мы не должны заставлять читателей нажимать внешние ссылки, чтобы понять статью, которую вы читаете, но в то же время мы не должны заставлять читателей читать объяснение для каждого термина. Так, еще один пример, когда нам может потребоваться объяснение, это то, что событие было сыграно как турнир с двойным выбыванием . Я думаю, что большинству читателей будет трудно понять это, и даже если вы знаете, что это такое, вы не будете слишком беспокоиться о более позднем предложении, в котором говорится, что игроки, проигравшие один матч, будут перемещены на «сторону проигравших» сетки и будут исключены после второго поражения, например. Последнее, что мы должны сделать, это объяснить каждую ссылку в строке. Представьте, что нам пришлось бы объяснять, что такое цель , битва или таблица . Ли Виленски ( обсуждение • вклад ) 10:00, 18 января 2024 (UTC) [ ответить ]
Ключевые слова — насколько это возможно . Статьи не ограничиваются экспертами, но они не должны быть слишком сложными для людей с небольшим опытом. WP:ONEDOWN упоминается некоторыми ниже.— Багумба ( обсуждение ) 09:54, 19 января 2024 (UTC) [ ответить ]
Я подозреваю, что то, что я собираюсь здесь сказать, будет непопулярно, но это никогда не останавливало меня раньше. Я думаю, что пользователи могут распечатывать статьи или читать офлайн, и контент Википедии может встречаться в переизданной форме, часто без ссылок , это устаревшая концепция. Wiki говорит, что Вики ... это форма онлайн-гипертекстовой публикации Прямо здесь, в первом предложении, подчеркивается "онлайн", а также "гипертекст". Это фундаментальные атрибуты того, чем мы являемся.
Да, наша лицензия позволяет людям распечатывать статьи, и я уверен, что некоторые люди это делают, но это исключительно незначительный пограничный случай. И да, люди перепечатывают наши материалы в сети, но если они перепечатывают их в форме, которая не сохраняет ссылки, они делают это неправильно. Большая часть этого — SEO-корм, кликбейт или просто плагиат, который не соответствует даже тривиальным требованиям, предъявляемым CC-BY-SA. Мне плевать на качество опыта, предоставляемого этими низшими кормушками. Что касается чтения в автономном режиме, Enwiki — это 4,3 миллиарда слов , так что цифра 25 ГБ (вероятно, больше похоже на 3 ГБ в сжатом виде). ​​Даже у недорогих телефонов в наши дни достаточно памяти, чтобы загрузить всю enwiki. Так что нет никаких веских причин, по которым офлайн-опыт не может включать ссылки.
Я не говорю, что мы не должны предоставлять встроенные объяснения терминов, когда это уместно. Просто мы не должны позволять устаревшим концепциям того, как люди потребляют энциклопедию, быть существенным драйвером нашего стиля письма. Для нас хорошо сказать «мы позволяем (даже поощряем) вам делать это». Также хорошо сказать «мы потратим значительные ресурсы (XML-дампы и т. д.), чтобы помочь вам сделать это». Нехорошо говорить «мы ухудшим наш продукт, чтобы вы могли это сделать».
Я полностью поддерживаю идею сделать наш контент более доступным для людей с ограниченными возможностями, но я не уверен, что предоставление встроенных объяснений каждой ссылки является положительным шагом. Я знаю, что в моем собственном чтении краткое написание помогает моему пониманию. Если мне приходится продираться через вводные объяснения терминов, чтобы добраться до сути предложения, мне становится сложнее его понять. RoySmith (обсуждение) 16:54, 25 января 2024 (UTC) [ ответить ]
Было бы замечательно, если бы он устарел. К сожалению, привилегия пропускной способности неравномерно распределена по всему миру — миллионы пользователей офлайн-версий Википедии. Nikkimaria ( обсуждение ) 00:00, 26 января 2024 (UTC) [ ответить ]

Мне кажется правдоподобным мнение Гога о том, что изменение NOFORCELINK в основном повлияет на FAC, поэтому я поискал на продвигаемых страницах FAC использование NOFORCELINK и FORCELINK. Это находит только тех немногих рецензентов, которые используют это сокращение, а не просто запрашивают дополнительные объяснения без ссылки на MoS; безусловно, есть и другие рецензенты, которые делают то же самое. С этой оговоркой, вот некоторые из результатов. Некоторые из них кажутся явно законными запросами и именно поэтому у нас есть NOFORCELINK; другие, как мне кажется, запрашивают больше, чем нужно. Я попробовал поискать «gloss», но во многих результатах я нашел комментарий «поскольку нет ссылки на этот специализированный термин, нам нужен gloss вместо этого»; они не имеют отношения к делу, поскольку рецензент ясно говорит, что достаточно просто ссылки.

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

  • член Société Honoraire de Français от FAC для Лизы Новак . Номинанты Neopeius и Hawkeye7; рецензент просит объяснить The Rambling Man . Текущая формулировка в статье: член Société Honoraire de Français, который требует от студентов поддерживать средний балл A по французскому языку и средний балл B по всем остальным предметам . Я думаю, здесь было бы достаточно ссылки.
  • возможно, из-за симпатий к якобитам со стороны FAC к Томасу Харди (офицеру Королевского флота, умер в 1732 г.) . Номинатор Пикерсгилл-Канлифф ; рецензент просит объяснений Гога Мягкого. Текущая формулировка в статье: возможно, потому что, будучи тори, он продолжал поддерживать свергнутый Дом Стюартов после наследования Дома Ганноверов . Особенно учитывая, что это в лидерах, я думаю, что расширение было правильным решением.
  • Длинный список слов, включая gracile , holotype и braincase , в FAC для Bajadasaurus . Номинатор Йенс Лалленсак ; рецензент The Rambling Man. Этот FAC содержит дебаты об использовании NOFORCELINK с комментариями от нескольких рецензентов.
  • 137 брейк из FAC для чемпионата мира по снукеру 2022 года . Номинант Ли Виленски; рецензент Гог Милд. Я думаю, что это тот, который привел к последнему обсуждению NOFORCELINK.
  • фрегат в составе FAC для HMS Aigle (1801) . Номинант Ykraps ; рецензент Gog the Mild.
  • «металлическая литая пластина в выемчатой ​​(резной) эмали в FAC для Клонмакнойз Крозье . Номинант Ceoil ; рецензент Гог Мягкий. Текущая формулировка в статье упрощена, а не расширена: в выемчатой ​​эмали .
  • "Tribal Hidage" в FAC для подвесной чаши Benty Grange . Номинант Usernameunique ; рецензент UndercoverClassicist .
  • геройский комикс и странная угроза в FAC для The Spider (журнал) . Номинант Майк Кристи; рецензент UndercoverClassicist.
  • Чагатайская литература в FAC для Физули (поэт) . Номинатор Golden ; рецензент UndercoverClassicist.
  • Обратное использование: в FAC для I Don't Wanna Cry , номинированного Heartfox , рецензент MaranoFan подверг сомнению детали предложения, а Heartfox ответил, что этого требует NOFORCELINK.

Дэвид предположил, что WP:ONEDOWN — это принцип, который следует использовать для определения того, требуется ли что-то большее, чем ссылка. Мне нравится эта идея в теории, но я хотел бы увидеть, что она будет полезна при разрешении приведенных выше примеров. Например, в FAC для The Spider UC запросил толкования для «странной угрозы» и «героя целлюлозы». Является ли уровень ONEDOWN читателем, который знает о целлюлозных журналах, но не об этом? Если так, то толкование не нужно. Или уровень ONEDOWN — это читатель, который знает о журнальной индустрии, но не о целлюлозе? В этом случае толкование, вероятно, будет полезным. Майк Кристи ( talk - contribs - library ) 13:40, 18 января 2024 (UTC) [ ответить ]

Если говорить точнее, то, поскольку я, кажется, довольно часто появляюсь здесь, мой принцип заключается в том, что мы должны объяснять термин в тексте, если:
а) Мы считаем, что читателю важно понять этот термин, чтобы осознать его значение в статье.
б) Мы считаем, что по крайней мере значительная часть читателей не поймет этот термин автоматически, учитывая, что мы пишем, исходя из предположения, что наша аудитория, как правило, не обладает достаточными базовыми знаниями за пределами статьи .
в) Объяснение термина относительно «дешево» (то есть существует краткое, полезное объяснение, которое можно вставить в текст статьи, не создавая других проблем с читабельностью, многословием или общей варварностью).
Вторя Майку, мне нравится идея ONEDOWN как базового стандарта, но я хотел бы подчеркнуть его точку зрения, что это всегда будет нюансное решение: я бы предположил, что любой слишком монолитный набор правил, скорее всего, потерпит неудачу. UndercoverClassicist T · C 14:21, 18 января 2024 (UTC) [ ответить ]

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

Но мы всегда должны помнить: наша цель не в том, чтобы строго следовать рекомендациям. Наша цель — писать наилучшие возможные статьи. Рекомендации могут только помочь нам в этом, но они никогда не могут быть целью сами по себе. Когда мы начинаем оптимизировать наши статьи в соответствии с рекомендациями, качество статьи, как правило, улучшается, но неизбежно наступает момент, когда мы переоптимизируем , и качество статьи резко падает. Поэтому рецензент не должен совершать ошибку, слепо проверяя статью на соответствие определенным рекомендациям и возражая из-за несоответствия, возможно, даже не читая статью. Вместо этого рецензент должен всегда иметь в виду нашу главную цель (улучшить статью) и применять здравый смысл в отношении рассматриваемой статьи, спрашивая «можно ли улучшить эту статью, более строго следуя этим рекомендациям»? — Йенс Лалленсак ( обсуждение ) 16:12, 18 января 2024 (UTC) [ ответить ]

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

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

К счастью, многие из наших статей, даже FA, не объясняют в строке и часто даже не ссылаются ( перерыв на столетие , если взять один из примеров Ли выше, начало четвертого , правый фол-пойнт и другие, которые я упоминал ранее , или вторая желтая карточка , окантовка подачи или ложный плоский ). Они все равно хорошие статьи. Редакторам Википедии не следует говорить, чтобы они ухудшали их, чтобы угодить читателям печатных изданий способами, которые печатные издатели не могут и не делают. NebY ( обсуждение ) 18:13, 18 января 2024 (UTC) [ ответ ]

  • Я боролся с этим вопросом и как писатель, и как рецензент, и я все еще формирую свои собственные взгляды. Однако я считаю, что с самого начала нам нужно признать, что на каком-то уровне аудитория каждой статьи отличается: географически, образовательно, лингвистически. Я не думаю, что возможно или желательно, чтобы каждая статья была одинаково доступна всем читателям (я не выставляю здесь соломенного чучела — я не верю, что кто-то выступает за это — я только выражаю принцип). Таким образом, мне кажется, что руководство должно быть написано таким образом, чтобы объяснения могли быть предоставлены или запрошены на основе a) степени специализации в статье и b) редакционного суждения. Vanamonde93 ( обсуждение ) 18:28, 18 января 2024 (UTC) [ ответ ]
В ответ на предположение NebY о том, что встроенные объяснения приносят пользу только читателям печатных изданий: здесь следует рассмотреть более широкую картину. Очевидно, что есть люди, которые по причинам доступности не могут или не могут с такой же легкостью переходить по гиперссылкам (те, кто использует программы чтения с экрана). Существует также серьезная проблема когнитивной нагрузки , когда людям приходится уходить со страницы и, таким образом, прерывать поток концентрации, а затем возвращаться к ней: опять же, это проблема доступности, когда мы рассматриваем такие вещи, как СДВГ и дислексия, которые затрагивают значительную часть наших читателей. UndercoverClassicist T · C 18:37, 18 января 2024 (UTC) [ ответить ]
Это хорошие замечания, но я не утверждаю, что встроенные объяснения приносят пользу только читателям печатных изданий. Я выступаю против встроенных объяснений, которые являются деструктивными, указывая на то, что мы часто обходимся без них, совершенно справедливо, несмотря на NOFORCELINK, и в целом расширяя вашу квалификацию вашего хорошо сформулированного пункта (c) выше. Как вы продолжаете говорить, это всегда будет нюансированное решение; один полезный способ подойти к этому — «вставили бы печатные СМИ такое объяснение здесь?» NebY ( talk ) 19:03, 18 января 2024 (UTC) [ reply ]

Если термин можно объяснить двумя-тремя словами, то встроенное описание может быть уместным. Если нет, то я считаю, что ссылка сама по себе — лучший вариант. В конце концов, разве это не большое преимущество цифровой энциклопедии. Я бы, конечно, не провалил FAC из-за NOFORCELINK, но мог бы настоять на сноске, где нет ссылки. -- Ykraps ( обсуждение ) 18:56, 18 января 2024 (UTC) [ ответить ]

Я согласен с идеей применения WP:ONEDOWN как к объяснениям, так и к ссылкам. Текст должен быть понятен целевой аудитории , без перехода по ссылкам (но это не значит, что читатель может избежать сложных размышлений или перечитывания сложных предложений). Таким образом, идея «на ноль уровней вниз» может быть как связана, так и объяснена. Идея «на один уровень вниз» может быть только связана (для любых читателей «на два уровня вниз»; или для заполнения случайных пробелов в знаниях целевого читателя). Все, что «на два уровня вниз» или больше, остается несвязанным.
В теореме Скотта–Карри (созданной мной) значение множества очевидно (более чем на два уровня ниже), поэтому оно не имеет ссылки и, конечно, не имеет длинного определения. Кроме того, для того же слова нужна ссылка. В статье, не связанной с математикой, может потребоваться ссылка и объяснение («художник был вдохновлен концепцией множества , которое содержит отдельные неупорядоченные объекты»). — Bilorv ( обсуждение ) 21:44, 18 января 2024 (UTC) [ ответить ]
Я всегда считал, что «средний читатель» означает «средний читатель этой конкретной статьи ». Я бы предположил, что кто-то, читающий статью о футбольном матче, знает что-то о футболе. Читатель высокотехнической статьи, вероятно, имеет солидный опыт в этой области и ищет подробную информацию. Математические статьи иногда испытывают трудности в этом отношении, поскольку к ним может обратиться широкая аудитория, поэтому они, как правило, начинаются с простого и становятся более сложными по мере продвижения. WP:ONEDOWN также конфликтует с NOFORCELINK (как и WP:NOTPAPER ), но я бы предпочел применять первый вариант к ссылкам вместо неисполнимого NOFORCELINK. Hawkeye7 (обсудить) 00:50, 19 января 2024 (UTC) [ ответить ]
Рискуя вставить здесь много весел, стоит помнить, что есть много путей — DYK, Random Article, On This Day, TFA... — с помощью которых мы поощряем людей смотреть статьи за пределами их обычных областей знаний. Статьи также часто пересекаются с разными областями: я написал много биографий ученых, которые служили в армии, поэтому в итоге мы получаем довольно много технического языка и подробностей о званиях, подразделениях, войнах и так далее. Опять же, я думаю, что основная концепция здравая, но будет сложно превратить ее в жесткое правило, которое будет применяться ко всем типам статей. NOFORCELINK уже является частью MoS, и весь MoS имеет постоянное предостережение о том, что «все правила здесь следует рассматривать как общие рекомендации и игнорировать, когда это уместно»: по определению, когда рецензент цитирует его, он говорит, что, по его мнению, его следует применять здесь , а не то, что его следует слепо применять везде . UndercoverClassicist T · C 07:34, 19 января 2024 (UTC) [ ответить ]


Формулировка предложений

Выше достаточно поддержки для чего-то, основанного на ONEDOWN, чтобы попытаться сформулировать что-то здесь. В настоящее время NOFORCELINK говорит:

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

и ONEDOWN говорит:

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

ONEDOWN — это эссе, поэтому вместо того, чтобы ссылаться на него, я думаю, нам следует перефразировать его и резюмировать. Что насчет этих дополнительных предложений?

Текст должен быть понятен читателям, которые находятся на уровне или на одну ступень ниже уровня, который познакомит их с материалом. Например, в статье о спинальных медицинских проблемах будет достаточно ссылки на фасетэктомию без пояснения в строке; если термин используется в статье об общем медицинском лечении, может потребоваться пояснение в сноске, а в статье, которая вообще не о медицине, значение термина должно быть объяснено в строке.

Это всего лишь способ начать обсуждение формулировок; пожалуйста, критикуйте или предлагайте изменения или улучшения. Майк Кристи ( обсуждение - вклад - библиотека ) 15:05, 19 января 2024 (UTC) [ ответить ]

Мне нравится Ли Виленски ( обсуждение • вклад ) 15:40, 19 января 2024 (UTC) [ ответить ]
WP:ONEDOWN — это не эссе, а часть Wikipedia:Make technical articles understanding , которая является руководством по редактированию. — Bagumba ( обсуждение ) 16:04, 19 января 2024 (UTC) [ ответить ]
Должен признать, что мне нравится все, кроме конкретного примера: большую часть аудитории статей по спинальной медицине составляют пациенты , которым, возможно, поставили диагноз, например, цервикальная ризалгия, и они хотят узнать, что это значит — таким людям определенно нужно объяснить фасеттомию в контексте «это может быть операция, которая вам предстоит». Я бы предложил более абстрактную иерархию, в которой у нас есть три варианта:
1. Объясните термин в тексте (не обязательно полное определение или контекст, но достаточно, чтобы понять его функцию в данной ситуации)
2. Если вам кажется, что это слишком неудобно для чтения, добавьте EFN, поясняющий то же самое.
3. Если вы считаете, что это излишне, просто воспользуйтесь ссылкой.
Лично я бы отдал предпочтение модели, в которой 1. является стандартной и общепринятой практикой, 2. используется, когда объяснение не так уж важно, а читабельность/эстетический эффект кажутся существенными, а 3. используется только там, где термин считается как минимум на две ступени ниже ожидаемого читателем уровня, и считается, что и 1., и 2. потребуют чрезмерных компромиссов (например, что используется так много технических терминов, что объяснять/сносить их все неразумно). Однако я думаю, что я немного более воинственен, чем общее мнение по этому последнему пункту. 16:13, 19 января 2024 (UTC) UndercoverClassicist T · C 16:13, 19 января 2024 (UTC) [ ответить ]
Я лично считаю, что это слишком конкретно и слишком жестко, чтобы быть общим руководством. Мне нравится идея ONEDOWN, это хорошее эмпирическое правило, но, как уже было отмечено, я также думаю, что оно применимо только к частям наших статей. У нас часто нет таких четких иерархических уровней. Например, узкоспециализированная статья о римской вазе может привлечь значительное внимание общественности, если она выставлена ​​в музее. И поскольку нас здесь в основном интересует FAC: Каждая специализированная FA привлечет значительное внимание обычных читателей, когда она находится на главной странице как TFA. Я бы предпочел что-то более простое и общее здесь вместо этого. Возможно: Рекомендуется давать встроенные объяснения для терминов, которые имеют решающее значение для понимания текста или могут быть незнакомы целевой аудитории. Однако статья должна найти баланс между количеством и длиной встроенных объяснений и общей краткостью и читабельностью статьи. Йенс Лалленсак ( обсуждение ) 17:00, 19 января 2024 (UTC) [ ответить ]
Мне нравится это: возможно, стоит добавить предложение о том, что сноски иногда могут быть полезным компромиссом при стремлении к этому балансу? UndercoverClassicist T · C 17:10, 19 января 2024 (UTC) [ ответить ]
Да; лично я считаю, что сноски хороши, когда требуются длинные объяснения. Однако, когда дело доходит до простых определений терминов, они, по моему мнению, не намного лучше простых вики-ссылок (поскольку и то, и другое требует щелчка), по крайней мере, для онлайн-читателей. -- Йенс Лалленсак ( обсуждение ) 17:17, 19 января 2024 (UTC) [ ответить ]
Сноски включают ссылку на то место, где читатель был раньше, тогда как вики-ссылки этого не делают, но это довольно незначительная разница, поскольку у нас всегда есть кнопка «назад» браузера, а затем прокрутка/нажатие ctrl-f для перехода к тому месту на странице, где мы были. UndercoverClassicist T · C 17:19, 19 января 2024 (UTC) [ ответить ]
Я думаю, нам также нужно что-то, чтобы избежать ситуации, которую NebY спародировал в предыдущем обсуждении: если статья о бейсбольном матче попадает на первую страницу, многие читатели, которые ничего не знают об этом виде спорта, прочитают ее, но мы все равно не должны включать сноски *или* встроенные объяснения для таких терминов, как «иннинг», «база на мячах», «драка на скамейке запасных» или «правило инфилд-флай». Йенс сказал, что «это может быть незнакомо целевой аудитории». Мы редко должны ожидать, что целевая аудитория будет такой же, как общая аудитория Википедии, иначе это изменение формулировки ничего не даст. Майк Кристи ( обсуждение - вклад - библиотека ) 17:26, 19 января 2024 (UTC) [ ответить ]
Я твердо убежден, что если читателю необходимо искать ссылки, чтобы понять статью в общих чертах, что он, вероятно, и сделал бы для второго и последнего выражения выше, то это не «пример лучшей работы Википедии», поэтому не станет ни FAC, ни TFA, и поэтому гипотетический пример кажется спорным. Gog the Mild ( обсуждение ) 18:05, 19 января 2024 (UTC) [ ответ ]
Вы, возможно, правы, но мне кажется, что конечный эффект здесь тот же: в любом случае, мы не должны ссылаться на то, что статья ожидает, что необычайно технически подкованная аудитория избежит объяснения технических терминов, что перевешивает против строгого использования ONEDOWN и в пользу чего-то более похожего на то, что предлагает Йенс . UndercoverClassicist T · C 18:19, 19 января 2024 (UTC) [ ответить ]
@ Майк Кристи : Вы правы, что часть о целевой аудитории не идеальна. А как насчет: рекомендуется давать встроенные объяснения для самых сложных терминов статьи, чтобы максимально широкая аудитория могла напрямую понять статью в общих чертах, не переходя по вики-ссылкам. Это все еще сохраняет некоторый элемент ONEDOWN, поскольку он ограничен «самыми сложными терминами» («самыми сложными» относительно общей технической сложности рассматриваемой статьи). Но да, это означало бы, что даже статья о бейсболе должна давать такие объяснения в разумной степени (и я думаю, почему бы и нет?). Йенс Лалленсак ( обсуждение ) 23:40, 19 января 2024 (UTC) [ ответить ]
Конечно, это «разумная степень», которую будет трудно определить. Я думаю, что Brooklyn Dodgers 1, Boston Braves 1 (26 иннингов) , недавно повышенный FA, является хорошим тестовым случаем. Номинантом был Wehwalt ; Harrias просмотрел его, и в FAC состоялся обмен мнениями о том, был ли уровень жаргона соответствующим — стоит взглянуть на комментарии Harrias и SchroCat, поскольку ни один из них не является поклонником бейсбола. Если вы можете найти форму слов, которая поддерживает формулировку, с которой в итоге пришел Wehwalt, и которая прошла FAC, я думаю, это то, что мы ищем. Я считаю, что текущая формулировка NOFORCELINK не поддерживает версию FAC, и я не думаю, что ваша предложенная формулировка поддерживает ее. Или вы думаете, что статья на самом деле слишком перегружена жаргоном? Майк Кристи ( обсуждение - вклад - библиотека ) 03:43, 20 января 2024 г. (UTC) [ ответить ]
Как я уже сказал, спортивные статьи обязательно будут использовать спортивный язык. Как я отметил в комментариях выше Харриасу, на которые не получил ответа, это верно независимо от того, идет ли речь о бейсболе, футболе (как в FA, номинированной Харриасом, которую я проверил на предмет идентичного недостатка, который они нашли в моей статье, которую они рассмотрели), или крикете (который, если бы я выбрал одну из этих статей, наверняка бы более чем убедительно изложил свою точку зрения, но я применил правило милосердия ).
Невозможно избежать использования спортивного языка, и если вы медленно объясняете каждый термин по ходу дела, вы не только усложняете прозу для тех, кто может фактически использовать статью, но и вызываете проблемы WP:V , поскольку бейсбольный источник, который сообщает нам, что назначенный отбивающий забил с одним аутом и базы загружены на сквиз-плей после того, как не смог продвинуться на поп-флае, на котором было объявлено правило инфилд-флая, не остановится, чтобы объяснить каждый термин. Если ссылок недостаточно (а так и должно быть), редактору придется либо вставить свое понимание каждого термина, обратиться к множеству источников определений, либо упростить его, потеряв значение, важное для читателей бейсбола. Причины для этого кажутся недостаточно вескими. Wehwalt ( talk ) 11:42, 20 января 2024 (UTC) [ ответить ]
Я бы предположил, что встроенные объяснения попадают под действие WP:BLUE и не нуждаются в цитировании? У меня есть встроенные объяснения во всех моих FA, и я никогда не указывал для них дополнительный источник; это не материал, который «оспаривался или может быть оспорен». Йенс Лалленсак ( обсуждение ) 12:21, 20 января 2024 (UTC) [ ответить ]
Я не думаю, что можно использовать СИНИЙ для технического термина. Особенно, когда у вас есть специальная статья, чтобы объяснить это. В моей области фол и промах были бы чем-то, что имеет довольно много толкований, и правила могут быть довольно косвенными. На практике, используя такой термин, не так уж важно, что вы знаете, что это такое или как это происходит, если в следующем предложении говорится, что произошло дальше. Ли Виленски ( обсуждение • вклад ) 12:54, 20 января 2024 (UTC) [ ответить ]
Написание статьи невозможно без интерпретации источников. Это включает в себя интерпретацию терминов, используемых в источнике. Поэтому добавление встроенного объяснения на самом деле не добавляет новую информацию, которая каким-либо образом не подразумевается в нашем тексте, по моему мнению. Ссылаться на такие вещи — это излишество цитирования. Йенс Лалленсак ( обсуждение ) 13:12, 20 января 2024 (UTC) [ ответить ]
Но в том-то и дело, что если вы начнете так экстраполировать, вы ничего не цитируете. Объяснение того, что есть что-то, на самом деле не так просто, как объяснение того, что вы видите. Учитывая, что мы говорим о статьях уровня FA, я бы не был доволен такой статьей, которая просто излагает интерпретацию без единого источника. Ли Виленски ( обсуждение • вклад ) 15:47, 20 января 2024 (UTC) [ ответить ]
Я мысленно вызывал WP:BLUE , когда, например, источник говорит: «перестройка произошла во время правления Юстиниана» — я бы сказал, что неразумно предполагать, что все наши читатели знают его даты, поэтому я мог бы написать что-то вроде «перестройка произошла при Юстиниане, который правил между 527 и 565 годами н. э.». Предполагая, что эти даты не вызывают споров, я бы не просил конкретной ссылки, но в равной степени нет ничего плохого в том, чтобы сделать что-то подобное. [UC 1] UndercoverClassicist T · C 06:34, 26 января 2024 (UTC) [ ответить ]
  1. ↑ Смит 2020. Даты правления Юстиниана см. в Джонсе 1999.
UndercoverClassicist T · C 06:34, 26 января 2024 (UTC) [ ответить ]
(EC) Да, трудно или невозможно определить, что такое разумная степень. Но я думаю, что та же проблема применима к вашей первоначальной формулировке — я лично понятия не имею, как бы я применил ONEDOWN к своим статьям о динозаврах. Означает ли это, что я должен предоставить больше встроенных объяснений или меньше? Упомянутая статья о бейсболе, похоже, вообще не предоставляет никаких встроенных объяснений; это, похоже, не соответствует моему предложению или ONEDOWN?
Я начинаю думать, что лучше просто удалить MOS:NOFORCELINK. У нас все еще будет смысл Не заставляйте читателя без необходимости гоняться за ссылками: если технический термин можно просто объяснить несколькими словами, сделайте это. – что, кажется, уже достаточно хорошо охватывает нашу базу. У нас также есть руководство WP:MTAU, гласящее, что статьи Википедии должны быть написаны для максимально широкой аудитории , которое указывает на множество различных возможных способов сделать статью понятной, и ONEDOWN уже рассматривается там. Если в FAC статья слишком техническая, по нашему мнению, мы все равно можем добиться лучшей понятности, указав на эти руководства. -- Йенс Лалленсак ( обсуждение ) 12:15, 20 января 2024 (UTC) [ ответить ]
Я не уверен, что понял: вы предлагаете убрать Не заставляйте читателя гоняться за ссылками без необходимости: если технический термин можно объяснить несколькими словами, сделайте это из MoS? Мне кажется, что все здесь согласны с этим принципом: тогда это создает дискуссию вокруг слова без необходимости , и именно здесь могут проявиться нюансы каждой отдельной ситуации.Чрезвычайно ценно иметь возможность указать на страницу MoS, чтобы объяснить правило, которое обычно считается здравым смыслом, особенно когда мы делаем это очень часто («per MOS:NOFORCELINK » гораздо легче для пальцев и глаз, чем писать полное объяснение!). Читая снова, я не совсем уверен, где находятся границы NOFORCELINK, но я мог бы предположить, что цитируемая фраза была бы полезно включена в него. UndercoverClassicist T · C 13:06, 20 января 2024 (UTC) [ ответить ]
Я предлагал удалить эту часть: Используйте ссылку, когда это уместно, но, насколько это возможно, не заставляйте читателя использовать эту ссылку, чтобы понять предложение. Текст должен быть понятен читателям, которые не могут следовать ссылкам. Пользователи могут распечатывать статьи или читать офлайн, а контент Википедии может встречаться в переизданной форме, часто без ссылок . Теперь я боюсь, что это просто бесполезно. Означает ли это, что каждый важный термин должен быть объяснен в строке (что, возможно, «возможно»)? Мы бы сохранили Не заставляйте читателя без необходимости гоняться за ссылками: если технический термин можно просто объяснить очень немногими словами, сделайте это. Мы могли бы сформулировать это немного строже, если это необходимо. Но теперь я утверждаю, что этого предложения достаточно, и что альтернативные формулировки, предложенные выше Майком и мной, в основном излишни для этого и руководства WP:MTAU. Йенс Лалленсак ( обсуждение ) 13:28, 20 января 2024 (UTC) [ ответ ]
Как насчет того, чтобы не заставлять читателя без необходимости гоняться за ссылками: если термин, который является высокотехнологичным, учитывая вероятную читательскую аудиторию статьи, можно просто объяснить несколькими словами, сделайте это ? Майк Кристи ( обсуждение - вклад - библиотека ) 14:20, 20 января 2024 (UTC) [ ответить ]
Я не вижу здесь улучшения: да, это дает нам возможность обсудить границы высокотехнического , но мы также поняли в этом обсуждении, что определение «вероятной аудитории читателей» статьи и установление нижней границы уровня их знаний является сложным и, возможно, неразумным. Я думаю, что суть « Используйте ссылку, когда это уместно, но по возможности не заставляйте читателя использовать эту ссылку, чтобы понять предложение» здравая: если мы думаем, что все читатели поймут термин, не переходя по ссылке, нет необходимости его объяснять: и наоборот, « насколько это возможно» дает выход, если объяснение кажется непрактичным. '' UndercoverClassicist T · C 14:28, 20 января 2024 (UTC) [ ответить ]
Я просто не вижу, что добавляет это предложение («Используйте ссылку, когда это уместно…»). Как принудительное правило, оно не работает, потому что «насколько это возможно» можно интерпретировать как крайности. Как дополнительный совет, это все еще кажется избыточным по сравнению с тем, что у нас уже есть. Йенс Лалленсак ( обсуждение ) 14:45, 20 января 2024 (UTC) [ ответить ]
Я думаю, что есть разница в акцентах между если это очень технический термин (форматирование мое) — что предполагает, что мы обычно не объясняем, если только термин не является очень техническим — и, насколько это возможно, не заставляем читателя использовать эту ссылку, чтобы понять предложение , что склоняется к объяснению. Есть много терминов, которые могут быть не очень техническими, но которые многие из наших читателей, в силу возраста, родного языка, образования, интересов и т. д. ( WP:POPE ), не поймут — я думаю, мы должны ожидать, что редакторы, как правило, объяснят их, по крайней мере, когда их подталкивают к этому в FAC, если только нет веской причины поступить иначе. UndercoverClassicist T · C 14:51, 20 января 2024 (UTC) [ ответить ]
Но когда первое предложение говорит мне объяснять только «высокотехнические» термины, а другое говорит мне объяснять все термины, когда «это возможно», разве они просто не противоречат друг другу? Разве мы не должны хотя бы объединить их в одну связную точку, чтобы сделать это полезным? Йенс Лалленсак ( обсуждение ) 14:59, 20 января 2024 (UTC) [ ответить ]
Я не уверен: сравните инструкцию вроде:
В начале предложения используйте заглавную букву. Вы должны использовать заглавную букву для имен собственных.
Мы не понимаем, что эти два утверждения противоречат друг другу. С учетом сказанного, вы правы, было бы аккуратнее, элегантнее и вообще лучше объединить два утверждения в одно. UndercoverClassicist T · C 15:27, 20 января 2024 (UTC) [ ответить ]
Вы, вероятно, правы. Но все равно, очень неясно, что означает «насколько это возможно». Как бы вы применили это к статье о бейсболе, упомянутой Майком? Какая была бы веская причина не следовать этому правилу? Йенс Лалленсак ( обсуждение ) 15:43, 20 января 2024 (UTC) [ ответить ]
Я думаю, что было бы ошибкой ожидать или просить MoS быть жестким и быстрым: у нас уже есть множество намеренно расплывчатых заявлений того же рода, чтобы сделать любую индивидуальную реализацию вопросом нюансов, обсуждения и консенсуса. Пара примеров, которые я выбрал довольно случайно -- все выделено мной:
  • Необоснованные изменения одного приемлемого, последовательно применяемого стиля в статье на другой стиль, как правило, могут быть отменены.
  • Название должно быть узнаваемым названием или описанием темы, которое является естественным, достаточно точным, лаконичным и соответствующим критериям смежных статей. Если эти критерии противоречат друг другу, их следует сбалансировать .
  • [Для названий разделов] Обычно используйте существительные или словосочетания с существительными: «Ранняя жизнь», а не «В ранней жизни».
  • В редких случаях дефис может улучшить ясность, если переписанная альтернатива неуклюжа, но перефразирование обычно предпочтительнее.
UndercoverClassicist T · C 16:00, 20 января 2024 (UTC) [ ответить ]
"Насколько это возможно" - очень сильное утверждение, всегда можно включить пояснения. Я вижу здесь различные перекрывающиеся условия для вставки встроенного пояснения: термин
  • может быть неясным или неизвестным для вероятной аудитории читателей
  • вряд ли будет интуитивно понято в контексте
  • необходимо понимать, чтобы понимать предложение (или статью?) (или, говоря другими словами, непонимание будет иметь заметные последствия)
  • можно просто объяснить в нескольких словах.
Трудно сказать, можно ли это выразить несколькими словами. NebY ( talk ) 14:57, 20 января 2024 (UTC) [ ответить ]
Да. Лично я использую дополнительное условие: я предоставлю пояснения в строке, если термин не может быть легко понят даже при обращении к ссылке. Это тот случай, когда контекст имеет решающее значение для интерпретации термина. Йенс Лалленсак ( talk ) 15:36, 20 января 2024 (UTC) [ ответить ]
@ Майк Кристи : Я полагаю, что ваше дополнение «учитывая вероятную читательскую аудиторию статьи» необходимо, если мы признаем, что статья о бейсболе может обойтись без каких-либо встроенных пояснений, несмотря на наличие многочисленных технических терминов (как вы думаете, у нас уже есть консенсус по этому поводу?), поскольку в противном случае это условие не будет выполнено. Йенс Лалленсак ( обсуждение ) 15:32, 20 января 2024 (UTC) [ ответить ]

Я просто укажу, что объяснения «технического» языка не всегда должны быть встроенными. Сноски также являются хорошим способом позволить тексту в теле естественным образом течь для тех, кто понимает тему, и в то же время предоставлять пояснения на странице для тех, кто не улавливает каждый нюанс каждого слова или термина. Я лично предпочитаю, чтобы язык тела был достаточно понятным для как можно более широкого круга англоговорящей аудитории, но иногда это не всегда легко, не упрощая и не раздражая большую часть читателей, поэтому требуется некоторая гибкость в MOS, написании и читателях, хотя сомнительно, что вам когда-либо удастся угодить кому-либо, кроме одной из этих групп в любой момент. - SchroCat ( обсуждение ) 15:44, 20 января 2024 (UTC) [ ответить ]

Согласен, хотя слишком много таких вещей тоже могут мешать — особенно если я читаю тему, в которой я немного разбираюсь, я не хочу, чтобы меня постоянно вызывали к сноскам, чтобы я обнаружил, что они говорят мне о вещах, которые я и так знаю. Йенс/UC, можем ли мы использовать язык, который я упомянул в предыдущем обсуждении? если знающие читатели считают, что поток слишком сильно прерывается встроенными пояснениями, не знающие читатели должны принять это и быть готовыми принять ссылки вместо этого или, если это абсолютно необходимо, пояснительную записку . В идеале тест должен был бы всегда иметь нейтрального и знающего рецензента, который может оценить, можно ли выразить статью более просто. Если у нас нет такого рецензента, я не думаю, что мы должны настаивать на том, чтобы статья была полностью понятна без перехода по ссылкам к тому, кто является наиболее знающим рецензентом, который появится, независимо от того, насколько далеки они от знаний на практике. (Это часть более широкой проблемы FAC, связанной с отсутствием экспертных оценок по предметной области.) Майк Кристи ( обсуждение - вклад - библиотека ) 16:30, 20 января 2024 (UTC) [ ответить ]
Как насчет Не заставляйте читателя без необходимости гоняться за ссылками. Если технический термин можно объяснить, не нарушая поток статьи для знающего читателя, сделайте это ? Майк Кристи ( обсуждение - вклад - библиотека ) 16:49, 20 января 2024 (UTC) [ ответить ]
Мне в принципе нравится, за исключением того, что объяснения всегда будут в некоторой степени нарушать поток (некоторые редакторы даже считают, что встроенные цитаты, используемые внутри предложений, нарушают поток). Это должен быть компромисс. Может быть, написать "[…] без неоправданного нарушения потока […]"?
Что касается языка из другого обсуждения: предлагаете ли вы объединить его с заявлением NOFORCELINK? Я лично считаю, что это обращается к читателям («читатели должны принять …»), что неловко, поскольку у них нет выбора; мы должны обращаться только к авторам. Йенс Лалленсак ( обсуждение ) 17:57, 20 января 2024 (UTC) [ ответить ]
Я думал, что два предложения, которые я предложил, должны заменить всю существующую формулировку NOFORCELINK. Не уверен насчет "неправильно" — учитывая, что мы в любом случае находимся в сфере редакционного суждения, я бы склонен был опустить наречия, как маловероятно полезные. Но с ними или без них, считаете ли вы формулировку приемлемой? Майк Кристи ( talk - contribs - library ) 19:01, 20 января 2024 (UTC) [ ответить ]
Мне интересно, действительно ли нам нужно это другое предложение («если знающие читатели чувствуют…»). Кажется, там нет дополнительных советов/прозрений (?), и, по-моему, лучше короче/проще. Мне также интересно, можем ли мы обойтись без «для знающего читателя» в первом предложении; оно, кажется, ничего не добавляет и звучит так, как будто «знающие читатели» будут в приоритете (что не так). Вместо этого мы могли бы просто добавить несколько более конкретных советов. Что насчет: не заставляйте читателя без необходимости гоняться за ссылками. Если технический термин можно объяснить, не нарушая поток статьи, сделайте это. Встроенные объяснения или сноски могут быть особенно полезны, когда технический термин, скорее всего, неизвестен многим читателям и вряд ли будет интуитивно понятен в контексте; должен быть понят, чтобы понять предложение в общих чертах; или его трудно понять в контексте предложения, обратившись к статье, связанной с вики. (Формулировка частично основана на том, что NebY опубликовал выше). Я не уверен, нужна ли вторая часть, но дайте мне знать, что вы думаете. Йенс Лалленсак ( обсуждение ) 20:06, 20 января 2024 (UTC) [ ответить ]
Извините, я не совсем ясно выразился. Я хотел предложить изменить NOFORCELINK на Не заставляйте читателя без необходимости гоняться за ссылками. Если технический термин можно объяснить, не нарушая поток статьи для знающего читателя, сделайте это . Я надеюсь, что включение пункта о «потоке статьи для знающего читателя» охватывает бейсбольный случай, но «сделать это» не помешает нам расширить и объяснить как можно больше. Это попытка сказать то же самое, что и ONEDOWN, не требуя определения уровней, подразумеваемых ONEDOWN. Майк Кристи ( talk - contribs - library ) 20:10, 20 января 2024 (UTC) [ ответить ]
Меня устраивает эта формулировка. Я все еще считаю, что «знающий читатель» не нужен для предполагаемого значения (в конце концов, это относится к «нарушению потока», а не к каким-либо уровням). Я думаю, что бейсбольный случай будет охвачен, даже если мы его уберем. Но это второстепенный момент. Йенс Лалленсак ( обсуждение ) 20:31, 20 января 2024 (UTC) [ ответить ]
Я бы поддержал формулировку и замену Майка в качестве предложения. Предложение Йенса также работает: я бы предложил сократить вторую часть до более прямого предложения, что сноски являются вариантом для этой вещи: не уверен, насколько важен материал после особенно полезного , но я могу увидеть аргумент в пользу предоставления рецензентам строки типа «Я думаю, что этот термин вряд ли будет интуитивно понятен в контексте» или чего-то подобного. UndercoverClassicist T · C 20:13, 20 января 2024 (UTC) [ ответить ]
Я также поддерживаю предложенную Майком формулировку. Hawkeye7 (обсудить) 20:29, 20 января 2024 (UTC) [ ответить ]
Йенс, есть ли возражения, если я начну новый раздел, предлагая свою формулировку, чтобы посмотреть, есть ли консенсус? Я предпочитаю ее вашей формулировке, но если вы хотите обсудить ее дальше или подождать, чтобы увидеть, подтянутся ли другие, я не против. Майк Кристи ( обсуждение - вклад - библиотека ) 22:23, 20 января 2024 (UTC) [ ответить ]
Никаких возражений, пожалуйста, продолжайте! Йенс Лалленсак ( обсуждение ) 22:48, 20 января 2024 (UTC) [ ответить ]
В книгах я обычно нахожу сноски более подробными, что обеспечивает более высокий уровень знаний — это свойственно моему чтению? Многие сноски в Википедии также являются пояснительными и обширными, поэтому нажатие на сноску только для того, чтобы найти определение в словаре, может быть очень раздражающим. NebY ( talk ) 17:08, 20 января 2024 (UTC) [ ответить ]
Мы говорим о веб-странице, а не о книге — и это критическое различие. У нас есть целые статьи, в которые нужно углубляться. Лично я нахожу раздражающим натыкаться на стену техно-болтовни в области, в которой я не эксперт, хотя я также раздражаюсь, когда в статье о крикете мне нужно объяснять, какие термины (для меня) являются базовыми. Сноски могут обеспечить средний путь между ними. Я повторю то, что сказал в своем первом посте: «требуется некоторая гибкость в MOS, написании и читателях, хотя вряд ли вам когда-либо удастся угодить кому-либо, кроме одной из этих групп в любой момент ». - SchroCat ( обсуждение ) 17:20, 20 января 2024 (UTC) [ ответить ]

Предлагаемая формулировка

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

Я предлагаю изменить NOFORCELINK с

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

к

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

Это не формальный RfC, но если кто-то считает это необходимым, я могу сделать его таковым. В любом случае я бы предпочел подождать, пока мы не увидим, имеет ли эта форма слов значительную поддержку. Майк Кристи ( talk - contribs - library ) 23:03, 20 января 2024 (UTC) [ ответить ]

Примечание: «неправомерно» добавлено к предложенной формулировке в соответствии с комментарием ниже. Майк Кристи ( обсуждение - вклад - библиотека ) 13:01, 23 января 2024 (UTC) [ ответить ]
Просто для ясности, намерены ли вы сохранить другое существующее и очень похожее предложение в MOS:L ( Не заставляйте читателя без необходимости гоняться за ссылками: если технический термин можно просто объяснить несколькими словами, сделайте это. в дополнение, или это тоже будет заменено? Йенс Лалленсак ( обсуждение ) 23:24, 20 января 2024 (UTC) [ ответить ]
Моя ошибка — я намеревался заменить и это, поскольку я вижу это как часть NOFORCELINK. Я отредактировал вышеприведенный текст, включив этот текст в формулировку «до». Майк Кристи ( talk - contribs - library ) 23:38, 20 января 2024 (UTC) [ ответить ]
Как и выше, я бы поддержал эту формулировку в RFC (и обратите внимание, что я считаю второе предложение новой формулировки и первое предложение старой эквивалентными, но всегда лучше говорить людям, что делать , а не чего не делать.) UndercoverClassicist T · C 10:04, 21 января 2024 (UTC) [ ответить ]

Никаких возражений пока нет, и (включая Jens и Hawkeye7 выше) четыре поддержки этой версии. Если не будет никаких возражений в течение следующей недели или около того, я внесу изменения. Майк Кристи ( обсуждение - вклад - библиотека ) 11:41, 22 января 2024 (UTC) [ ответить ]

Мне кажется разумным. Ли Виленски ( обсуждение • вклад ) 13:50, 22 января 2024 (UTC) [ ответить ]

Мне нравится более раннее предложение Йенса Лалленсака в #Working suggestions (выше) добавить необоснованно : если технический термин можно объяснить, не нарушая необоснованно поток статьи для знающего читателя, сделайте это. Надеюсь, это передает, что некоторые знающие читатели могут быть несколько нарушены "упрощенной" версией, но это для общей цели сделать статью более доступной.— Багумба ( обсуждение ) 16:02, 22 января 2024 (UTC) [ ответить ]

Я обеспокоен тем, что это своего рода вещь, которая очень субъективна и может применяться непоследовательно в FAC, который, как было указано, является единственным местом, где это действительно имеет значение. По крайней мере, я хотел бы увидеть несколько примеров. Wehwalt ( talk ) 19:15, 22 января 2024 (UTC) [ ответить ]

Да, это субъективно, но так же и MOS:OVERLINK . Это само по себе не является остановкой шоу. — Bagumba ( обсуждение ) 07:42, 23 января 2024 (UTC) [ ответить ]
Верно. Но MOS:OVERLINK имеет длинный ряд примеров и других рекомендаций. Wehwalt ( обсуждение ) 12:28, 23 января 2024 (UTC) [ ответить ]

Я также больше симпатизирую точке зрения Гога, изложенной выше, - я бы предпочел предоставить привилегию читателю-неспециалисту. Nikkimaria ( обсуждение ) 03:14, 23 января 2024 (UTC) [ ответ ]

Я думаю, все согласны, что неспециалисту следует угодить. Такое предложение, как After Brooklyn was retired in order в верхней части третьего иннинга, Oeschger удвоился в центральное поле, чтобы начать домашнюю половину иннинга, и Powell пожертвовал им на третьей базе , от недавно повышенного FA, не может быть полезно объяснено неспециалисту, не испортив опыт чтения для любителя бейсбола. Текущая версия NOFORCELINK, на мой взгляд, не учитывает это ограничение, и пересмотренная формулировка призвана решить эту проблему — способствовать встроенным объяснениям (с «сделайте это» в конце пересмотренной формулировки), но признать, что это упрощение должно быть ограничено, чтобы не сделать статью непригодной для опытных читателей.
Вехвальт, предложение, которое я только что процитировал Никки, может служить примером, который вы ищете? И я бы сказал, что NOFORCELINK менее субъективен и более абсолютистичен в своей формулировке, и это плохо. Вам пришлось спорить о текущей формулировке NOFORCELINK в FAC для статьи о бейсболе. Не лучше ли было бы иметь версию, которая признавала бы роль суждения редактора? Майк Кристи ( обсуждение - вклад - библиотека ) 11:46, 23 января 2024 (UTC) [ ответить ]
Да, это был бы хороший пример. Wehwalt ( talk ) 12:31, 23 января 2024 (UTC) [ ответить ]
Однако я должен согласиться с точкой зрения Вехвальта о субъективности. Разве у нас здесь нет двойных стандартов? Очевидно, что для спортивной статьи нормально не объяснять ни одного термина, но статьи на другие темы должны это делать. Но что именно отличает спортивные статьи от других? Что касается моих статей о динозаврах, я мог бы утверждать, что объяснения разрушают поток для поклонников динозавров и, следовательно, ничего не объясняют. Означает ли новая формулировка, что мне это сойдет с рук? Йенс Лалленсак ( обсуждение ) 12:51, 23 января 2024 (UTC) [ ответить ]
В новой формулировке нет ничего о спорте; я бы ожидал, что она будет применяться ко всем статьям. Нет, я не думаю, что можно просто «ничего не объяснять» — предлагаемая формулировка гласит: «Если технический термин можно объяснить, не нарушая необоснованно поток статьи для знающего читателя, сделайте это». Рецензент может попросить дополнительных объяснений, и редакторам придется согласовать строку, в которой полученный поток «необоснованно нарушается». Да, это субъективно, но я не думаю, что мы придумали что-то лучше этого. Майк Кристи ( talk - contribs - library ) 13:01, 23 января 2024 (UTC) [ ответить ]
Я подозреваю, что во многих областях обсуждаемый вопрос просто невозможно объяснить в нескольких словах тем, кто ничего не знает о динозаврах, бейсболе или математике. Поэтому, признаюсь, я все еще немного встревожен тем, что мне приходится публиковать защиту рецензенту, который просит меня объяснить правило инфилд-флай , когда оно упоминается вскользь в статье о бейсболе; следует понимать, что некоторые статьи не являются базовыми знаниями в своей области и требуют определенного уровня знаний, прежде чем приступить к статье. Wehwalt ( talk ) 13:13, 23 января 2024 (UTC) [ reply ]
Я подозреваю, что во многих областях обсуждаемый вопрос просто невозможно объяснить в нескольких словах тем, кто ничего не знает о динозаврах, бейсболе или математике : я вижу разочарование от необходимости отвечать на комментарии, которые мы считаем неразумными или необоснованными, но разве было бы так уж трудно написать что-то вроде «да, эта часть немного специализирована, но нет хорошего способа объяснить все это, не нарушая потока (см. MOS:NOFORCELINK ), а детали действительно интересны только тем, кто уже знает основы»? Мне кажется, что предлагаемая формулировка, имея слово «неправильно» , дает очень четкий способ объяснить, почему в конкретном случае не было предложено встроенное объяснение. Я надеюсь, что рецензенты учтут собственное чувство того, насколько разрушительным будет объяснение, прежде чем предлагать такой комментарий — следовательно, если бы они действительно попросили объяснить, они бы сделали это, полагая, что это можно сделать, не вызывая серьезных проблем. UndercoverClassicist T · C 13:21, 23 января 2024 (UTC) [ ответить ]
@ Wehwalt : Конечно, нам нужно требовать определенный уровень знаний. Но если я правильно интерпретирую новую формулировку NOFORCELINK, это все равно означает, что мы должны объяснить по крайней мере некоторые термины (те, для которых объяснение имеет наибольший смысл, особенно когда они менее широко известны, но важны для предложения). Однако, пример статьи о бейсболе здесь не делает никаких попыток объяснить какой-либо термин, насколько я могу судить. Как это не нарушает новую формулировку NOFORCELINK? Йенс Лалленсак ( обсуждение ) 13:29, 23 января 2024 (UTC) [ ответить ]
Я все еще нервничаю по поводу «насколько это возможно». Строгий рецензент может настаивать на том, что это очевидно возможно и что это имеет приоритет — и недавно тоже было рассмотрено! Возможно, небольшая перестановка и перефразировка сработали бы: используйте ссылку, когда это уместно, но если технический термин можно объяснить, не нарушая излишне поток статьи для знающего читателя, сделайте это. Постарайтесь не заставлять читателя использовать ссылку, чтобы понять предложение. «Постарайтесь не делать этого» может быть слишком слабым, но откровенное «Избегать» может быть слишком сильным; есть ли что-то подходящее между ними? NebY ( обсуждение ) 14:00, 23 января 2024 (UTC) [ ответить ]
Статья не пытается обсуждать термины бейсбола, поскольку общепринятым способом помочь читателю было предоставление ссылок. Бейсбол, сконструированная игра с фиксированными и не всегда интуитивно понятными правилами, трудно обсуждать, а его термины трудно определить, если вы пытаетесь обсудить их или определить их без какой-либо ссылки на бейсбол вообще , что, по-видимому, понадобится гипотетическому читателю без знаний о бейсболе. Wehwalt ( talk ) 14:14, 23 января 2024 (UTC) [ ответить ]
Я не думаю, что какой-либо рецензент (или координатор) не согласится с тем, что объяснение правила инфилд-флай с первых принципов неоправданно нарушает текст — я не думаю, что любое изменение MoS может избежать упрямых рецензентов! Но тогда координаторы также уполномочены игнорировать возражения, которые не кажутся обоснованными. UndercoverClassicist T · C 14:29, 23 января 2024 (UTC) [ ответить ]
Я согласен, что эти термины нельзя объяснить читателю без знаний и без какой-либо ссылки на бейсбол. Я не об этом: я предполагаю, что есть много читателей с базовыми знаниями бейсбола, которые знают такие термины, как «иннинг», но могут испытывать трудности с некоторыми более специализированными терминами. Моя интерпретация новой формулировки NOFORCELINK (также основанная на объяснении Майка выше) заключается в том, что статья должна попытаться объяснить эти более специализированные термины там, где они имеют значение, когда это возможно (используя более базовую бейсбольную терминологию). Следовательно, статья о бейсболе должна будет предоставить некоторые объяснения, которые улучшат доступность статьи, чтобы соответствовать новой формулировке NOFORCELINK. Или я что-то не понимаю? Йенс Лалленсак ( обсуждение ) 14:32, 23 января 2024 (UTC) [ ответить ]
Я не знаю. Ничего необычного в игре не произошло, кроме того, что она продолжалась долгое время, что было необычным, что сделало ее примечательной. Если кто-то достаточно хорошо разбирается в бейсболе, чтобы следить за газетным отчетом или телевизионной трансляцией, то все должно быть в порядке. Конечно, таким образом кроется банка червей с последствиями для многих статей, если тест заключается в том, что если человек поверхностно знаком с предметом, каждый технический термин должен быть объяснен в строке. Wehwalt ( talk ) 14:47, 23 января 2024 (UTC) [ ответить ]
Мне нравится идея с примерами. Однако я думаю, что примеры должны быть целыми статьями, а не отдельными предложениями. Только статьи могут найти баланс между объяснениями и потоком чтения, который мы ищем; мы не можем сказать по одному предложению, какие объяснения полезны или мешают в данном контексте. Предложение с примером бейсбола, предложенное выше, на мой взгляд, вводит в заблуждение: большинство этих терминов уже упоминались ранее в статье, и по этой причине их никогда не следует объяснять в этом конкретном предложении . Я думаю, что контекст важнее самого предложения; поэтому целые статьи гораздо полезнее в качестве примеров. Йенс Лалленсак ( обсуждение ) 14:20, 23 января 2024 (UTC) [ ответить ]
Поразмыслив, я согласен, что целые статьи являются лучшими примерами, чем отдельные предложения, по той причине, которую вы указали — по крайней мере, чтобы продемонстрировать случаи, когда NOFORCELINK не следует применять. Статья о бейсболе, Brooklyn Dodgers 1, Boston Braves 1 (26 иннингов) , кажется, может подойти в качестве примера. Wehwalt, я понимаю вашу точку зрения, что в этой статье ссылки используются как способ помочь читателям, а не встроенные объяснения. Я думаю, что вопрос здесь в том, соответствуют ли текущая или предлагаемая формулировка NOFORCELINK этому подходу. (Или можно ли найти лучшую формулировку, чем текущее предложение.) Я думаю, что на комментарии, которые вы получили в FAC, было бы проще ответить предлагаемой формулировкой NOFORCELINK, потому что любой знающий читатель был бы раздражен практически любыми встроенными объяснениями в игровых абзацах. В описаниях игрового процесса бейсбола есть ожидание того, что читатель сможет их понять.
Я думаю, это означает, что нам нужно два примера: один, чтобы показать, когда NOFORCELINK не применяется, а другой, чтобы показать, когда он применяется. Как насчет радиоуглеродного датирования для последнего? Он объясняет термины, такие как «счетчик антисовпадений», и дает подробности о том, как работает ускорительная масс-спектрометрия, но не делает ничего, кроме связывания терминов, таких как тефра и варва , которые являются периферийными по отношению к основной теме. Майк Кристи ( обсуждение - вклад - библиотека ) 12:06, 24 января 2024 (UTC) [ ответить ]
Как обсуждалось выше, я не убежден, что NOFORCELINK не применим к Brooklyn Dodgers 1, Boston Braves 1 (26 иннингов) . Статья содержит термины, которые даже не упоминаются в базовой статье Baseball (например, «spicked» и «wild pitch»). Выше Уэволт отметил, что «если кто-то достаточно разбирается в бейсболе, чтобы следить за газетным отчетом или телевизионной трансляцией, то все должно быть в порядке», но NOFORCELINK просит немного больше: каждое предложение должно быть понятным, если это возможно, а не только статья в целом.
Если нам нужна другая альтернатива, я мог бы предложить Bajadasaurus . Вопросы NOFORCELINK этой очень технической и специализированной статьи широко обсуждались во время FAC, и результатом стал хороший компромисс (я надеюсь). Статья объясняет многочисленные термины, часто в глоссарии, иногда несколько в одном предложении. Я думаю, что она имеет максимум встроенных объяснений, которые возможны без неоправданного нарушения потока, и поэтому может быть примером для «верхней границы» (которая, я думаю, не достигается двумя другими примерами). Йенс Лалленсак ( обсуждение ) 14:29, 24 января 2024 (UTC) [ ответ ]
Wild pitch — это обычная игра в бейсбол, которая происходит в большинстве бейсбольных игр и соответствующим образом связана. Spiking в наши дни встречается реже, но не является чем-то неизвестным и соответствующим образом связана. Они были бы известны любому, кто обладает достаточными знаниями, чтобы следить за статьей о бейсболе. И статья о бейсболе прошла TFA, проверку на кислотность статьи, без каких-либо негативных комментариев относительно терминологии.
Что касается предлагаемой статьи о динозавре: без особых усилий я нашел в этой статье неопределенные технические термины, которые не связаны, например, с «дикой смолой» и «шипами». Начнем с «края» и «хрупкой деформации».
Я должен отметить, что статьи о динозаврах, по крайней мере, имеют преимущество в описании анатомических особенностей, которые аналогичны тем, что знакомы людям. Череп все еще остается черепом, фундаментальной вещью, которая остается с течением времени. Читатель, имеющий такой объект, понимает его интуитивно. Это совсем другая ситуация, чем бейсбол, который является искусственным видом спорта с идиосинкразической терминологией. Поэтому я не знаю, достигнем ли мы здесь общего языка. Wehwalt ( talk ) 14:55, 24 января 2024 (UTC) [ ответить ]
Более сложные бейсбольные термины можно объяснить, используя базовую бейсбольную терминологию, поэтому я не совсем понимаю проблему с «идиосинкразической терминологией». То, что люди с базовым пониманием бейсбола будут знать все эти термины, как вы говорите, — я не знаю. Но я очень сомневаюсь, что все эти термины находятся на одном уровне сложности — будут некоторые, которые сложнее других, и это кандидаты, которые могут заслуживать объяснений. Вот чего просит ONEDOWN: перевести предмет на более низкий уровень. И я бы даже сказал, что каждую статью можно написать «на уровень ниже», поэтому я не уверен, может ли быть статья, к которой NOFORCELINK «не применим». Йенс Лалленсак ( обсуждение ) 15:41, 24 января 2024 (UTC) [ ответить ]
ONEDOWN хорошо подходит для тем с одним, четко идентифицируемым «уровнем». А как насчет статей, которые таковыми не являются? Например, чтобы быть «знающим читателем» всей статьи об Элвисе Пресли , потребуется понимание музыки, кино и, в некоторой степени, военной и общей истории. Это также статья, которая, вероятно, привлечет очень широкую общую читательскую аудиторию. Как принцип ONEDOWN применим к этому? Nikkimaria ( обсуждение ) 06:18, 25 января 2024 (UTC) [ ответ ]
Я думаю, что ONEDOWN был написан с учетом технических тем и его трудно применить к статьям вроде Elvis Presley . Вот почему я надеялся, что «знающий читатель» будет достаточным для определения того, для кого пишется; это не зависит от уровней. Я просмотрел статью Presley, чтобы увидеть, что объясняется в строке (т. е. что можно считать из-за NOFORCELINK). Там не так много: ацетатный диск связан, но не объяснен, например, но отброшенные рентгеновские пластины можно считать встроенным объяснением для «ребр» в этом смысле.
Причина, по которой я хотел переписать NOFORCELINK, была не в том, что я не хочу объяснять вещи в строке во всех случаях, а в том, что я считаю ее формулировку слишком абсолютной. Я хотел бы формулировку, которая может быть использована для того, чтобы сказать, что редакционное суждение должно быть вовлечено в решение о том, насколько далеко заходить в объяснении. «Знающий читатель» — это попытка определить это, но если бы была приемлема еще менее определенная формулировка, я бы согласился с ней. Что-то вроде « Используйте ссылку, когда это уместно». Если возможно объяснить технические термины в строке, сделайте это, но используйте редакционное суждение относительно того, можно ли это сделать, не нарушая неоправданного потока статьи. . Я думаю, Вехвальт сделал суждение (для статьи о бейсболе), что почти любые встроенные объяснения будут нарушающими, и я согласен. Я не вижу, как текущая формулировка NOFORCELINK допускает это, и я думаю, что это следует исправить. Майк Кристи ( обсуждение - вклад - библиотека ) 08:11, 25 января 2024 г. (UTC) [ ответить ]
Я думаю, что это закончилось как тавтология: ненадлежащее , по определению, является вопросом оценки того, что [должно быть] . Как можно это оценить, если не с помощью редакционного суждения ? UndercoverClassicist T · C 08:53, 25 января 2024 (UTC) [ ответить ]
Справедливое замечание. Есть ли формулировка, которая вызывает редакционное суждение, которое вы могли бы поддержать? Майк Кристи ( обсуждение - вклад - библиотека ) 09:12, 25 января 2024 (UTC) [ ответить ]
Честно говоря, я бы не возражал против этой формулировки — лучшее — враг хорошего и все такое. Для меня есть много терминов — уместных , неуместных — которые уже требуют осуждения, но я вижу ценность в явном его применении. Однако я вижу ценность в подкреплении того, что это особенно субъективное «правило». UndercoverClassicist T · C 10:07, 25 января 2024 (UTC) [ ответить ]
Это более обнадёживает, чем я ожидал. Никки, а как насчет тебя? Ты указала, что согласна с Гогом, что мы должны отдавать предпочтение неспециалисту-читателю. Эта формулировка делает это меньше, чем существующая, подвергая это увещевание редакционному суждению. Ты бы возражал против этой формулировки? Майк Кристи ( talk - contribs - library ) 11:38, 25 января 2024 (UTC) [ ответить ]
Предлагаемая формулировка открыто ставит знающего читателя в привилегированное положение по сравнению с незнающим, что, по-видимому, противоречит основным ценностям Википедии. (Между прочим, я продолжаю считать, что такое фундаментальное изменение требует широко разрекламированного RfC.) Возникнет ли проблема в удалении «для знающего читателя» из предлагаемой формулировки? Это, по-видимому, решает воспринимаемую проблему, не делая явно необязательным понимание для неспециалиста. Gog the Mild ( обсуждение ) 12:52, 25 января 2024 (UTC) [ ответ ]
Согласен по поводу RfC. Я не хочу начинать его, пока у нас не будет хотя бы какого-то соглашения. К твоему мнению: как насчет формулировки, которую я предложил Никки выше: используйте ссылку, когда это уместно. Если возможно объяснить технические термины в строке, сделайте это, но используйте редакционное суждение относительно того, можно ли это сделать, не нарушая неоправданного течения статьи ? Майк Кристи ( обсуждение - вклад - библиотека ) 13:31, 25 января 2024 (UTC) [ ответить ]
Я не согласен с утверждением, что это противоречит ценностям Википедии, учитывая нашу образовательную миссию. Hawkeye7 (обсудить) 00:22, 30 января 2024 (UTC) [ ответить ]
Я подумаю об этом, но моя первая мысль — это отказ от ответственности. Это должно быть политикой, а эта формулировка, похоже, едва ли является руководством. Я имею в виду, что если есть разногласия и обе стороны обращаются к политике, чтобы урегулировать вопросы: это не поможет. Первая версия была ясной, хотя я и против нее.
Немного подумав, эта формулировка кажется даже хуже изначально предложенной. Она фактически говорит: «Пока у вас есть ссылка, неважно, имеет ли проза смысл для неспециалиста». Оригинал, по крайней мере, сохранил фиговый листок письма для широкой аудитории. Gog the Mild ( talk ) 13:54, 25 января 2024 (UTC) [ ответить ]
Да, я думаю, мы движемся в неправильном направлении. Nikkimaria ( обсуждение ) 00:00, 26 января 2024 (UTC) [ ответить ]

Я собираюсь прекратить попытки найти форму слов, которая может получить общую поддержку. Я все еще думаю, что существующая формулировка не отражает реальную практику, и было бы лучше найти формулировку, которая отражает то, что мы действительно делаем: мы пытаемся улучшить читаемость для неспециалистов, но причины, по которым мы не всегда движемся или не можем двигаться очень далеко в этом направлении, не признаются в текущей формулировке. Однако MoS — это руководство, а не политика, и в FAC номинатор всегда может сказать, что, по его мнению, применение правила MoS не имеет смысла для данной статьи. Майк Кристи ( обсуждение - вклад - библиотека ) 06:47, 26 января 2024 (UTC) [ ответить ]

Пример

Я сейчас читаю Beulé Gate от UndercoverClassicist . Следующее предложение напомнило мне об этом обсуждении:

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

Там девять разных связанных терминов, и я не знаю, что означает любой из них. Тем не менее, предложение имеет полный смысл, и я знаю, как щелкнуть, чтобы получить более подробную информацию о любом из них, если я захочу. Если бы это предложение было переписано с пояснениями в скобках для каждого из этих терминов, оно было бы безумно сложным и определенно менее читабельным. — Предыдущий неподписанный комментарий добавлен RoySmith ( обсуждение • вклад ) 00:22, 30 января 2024 (UTC) [ ответить ]

В текущей формулировке, если бы это было придирчиво в обзоре, я бы просил «насколько это возможно»: как вы говорите, невозможно включить встроенные объяснения для всего этого, не нарушая MoS и политику другими способами (создавая нечитаемое предложение). Если бы руководство было изменено на что-то вроде Используйте ссылку, когда это уместно, но если технический термин можно объяснить, не нарушая неоправданно поток статьи для знающего читателя, сделайте это. , я бы дал это как точную причину необоснованного включения: мы говорим об архитектурных мелочах, поэтому подробности здесь довольно несущественны для большинства читателей: ценность встроенных объяснений перевешивается стоимостью этого. Кстати: спасибо, что подняли этот вопрос здесь — это помогло мне заметить пару ошибок! UndercoverClassicist T · C 07:27, 30 января 2024 (UTC) [ ответить ]
Моя точка зрения выше здесь имеет смысл. Нужно ли нам знать, что такое дорический ордер, чтобы понять контекст? В этой части объясняется, что такое «поровый камень» (известняк), а «пендальский мрамор» довольно сильно выделяется тем, что это тип мрамора. Есть еще несколько запутанных вещей, таких как триглифы и мутулы, но я понятия не имею, как вы объясните их, кроме как архитектурные термины. Ли Виленски ( обсуждение • вклад ) 09:19, 30 января 2024 (UTC) [ ответить ]
По крайней мере, на триглифах и гейсоне есть фотография справа с подписью, которая делает их (надеюсь) довольно очевидными: я бы предположил, что это также сыграет некоторую роль в уровне возможной путаницы и, следовательно, в общей дискуссии о том, насколько необходимым/ценным будет встроенное объяснение. Как и в большинстве случаев в MoS, это анализ затрат и выгод. UndercoverClassicist T · C 09:46, 30 января 2024 (UTC) [ ответить ]
Я бы начал со второго месяца. 2A00:23C7:4F01:1201:894B:E257:1DF6:C83E (обсуждение) 21:52, 11 февраля 2024 (UTC) [ ответить ]

NOPIPE, конвейерные ссылки и VisualEditor

Редакторы, интересующиеся MOS:NOPIPE , а также использованием, созданием и изменением конвейерных ссылок в Visual Editor, могут быть заинтересованы в обсуждении, которое проходит на WP:VPT#Конвейерные ссылки с VisualEditor . Спасибо, Mathglot ( обсуждение ) 23:40, 3 февраля 2024 (UTC) [ ответить ]

Поскольку мы изменили политику дублирования ссылок, чтобы ссылки могли быть подходящими или неподходящими для первого раза в разделе, у меня были пользователи, которые изменили это для всех заголовков разделов (так что даже для заголовков четвертого уровня у них есть новая ссылка). Могу ли я подтвердить, что когда мы говорим о первом использовании в разделе, мы имеем в виду первое использование в заголовке второго уровня? Ли Виленски ( обсуждение • вклад ) 15:39, 4 февраля 2024 (UTC) [ ответить ]

С тех пор MOS был изменен на "главныйраздел"[2] — Багумба ( обсуждение ) 04:00, 25 февраля 2024 (UTC) [ ответить ]
Хорошо, но что означает «основной»? Только уровень 2? Уровень 3? Я думаю, что после уровня 3 это не подходит, но я вижу аргументы в пользу 3. SMcCandlish, вы добавили «основной» к этой формулировке. Каково было ваше намерение? - Favre1fan93 ( обсуждение ) 17:54, 26 февраля 2024 (UTC) [ ответить ]
Я не был уверен, что означает MOS, и начал это обсуждение на WT:SNOOKER , относительно статьи, над которой я работал ( 2024 German Masters ). Консенсус был в том, чтобы ограничиться уровнем 2 для статей о турнирах по снукеру. Я думаю, что стоит обсудить это для дальнейшего прояснения более широкого MOS, а не только для статей о снукере. Указание уровня 2, 3 и т. д., и, возможно, иметь разные критерии для статей на разные темы. AmethystZhou ( обсуждение ) 18:05, 26 февраля 2024 (UTC) [ ответ ]
«Major» — это уровень 2 (== ... ==). Gawaon ( обсуждение ) 18:12, 26 февраля 2024 (UTC) [ ответить ]
Скорее, «major» описывает глубину и важность контента. Если имелся в виду «уровень 2», то «уровень 2» — это то, как это будет читаться. Существует бесчисленное множество случаев заголовков L2 (обычно ближе к концу статьи), которые не содержат ничего, кроме одного или двух предложений материала, который является или граничит с мелочами. Между тем, некоторые статьи имеют различные подразделы L3, которые содержат большую часть фактического контента, каждый из которых длиннее большинства разделов L2 в большинстве других статей.  —  SMcCandlish ☏ ¢  😼  19:05, 26 февраля 2024 (UTC) [ ответить ]
Моей целью было сократить чрезмерное повторение ссылок, о котором сообщает Ли Виленски (что, очевидно, противоречит намерению изменения, одобренного сообществом в RfC, о ссылке более одного раза на статью), но без навязывания или намека на математически жесткое ограничение (мы всегда должны оставлять на усмотрение редактора то, что можно оставить). Различные очень длинные и подробные статьи разделены на несколько разделов, каждый из которых состоит из нескольких подразделов, которые являются «основным» или «главным» контентом, при этом заголовки уровня 2 просто действуют как группирующие рамки. Однако в большинстве случаев статьи разделены в основном или даже только на заголовки уровня 2, при этом большая часть контента находится непосредственно под ними. (И, конечно, есть еще тот факт, что термин/имя может появиться сначала на уровне 2, а затем повториться 1000 слов позже в подразделе уровня 3 или уровня 4 другого раздела; он все равно будет считаться повторно появившимся в другом основном разделе, просто также в подразделе более низкого уровня указанного основного раздела.) Один размер редко подходит всем, когда дело касается вопросов структуры статьи. Если мы считаем, что необходимо некоторое объяснение «основного» (или термина, которым он заменен), это можно поместить в сноску вместо того, чтобы делать пункт MoS об этом более многословным. Также важно помнить, что консенсус на самом деле в основном живет в обсуждении. Кто-то не может отбивать барабанную дробь, предпочитая, но неправильное толкование чего-либо в руководстве, если архив обсуждений о его внедрении в первую очередь противоречит им. Таким образом, и исходный RFC, и это обсуждение останутся очевидно уместными в любом споре об интерпретации.

Нормально и ожидаемо, что редакционный консенсус достигается на основе каждой статьи; мы относимся ко всему MoS таким образом в отношении пункта руководства, который имеет пространство для маневра в интерпретации, и это задумано. (Помните, что MoS не является политикой и предназначен для создания последовательного и полезного контента для читателей, а во-вторых, для урегулирования межредакторских споров о стиле, в широком смысле.) Хотя википроекты, приходящие к «локальному консенсусу» по такому вопросу в категории статей, иногда могут быть проблематичными в соответствии с политикой WP:CONLEVEL (а именно, когда предпочтения этих редакторов противоречат консенсусу на уровне всего сайта или конфликтуют с не менее принципиальными предпочтениями редакторов, которые не являются частью этой группы; см., например, WP:ARBINFOBOX ), в таком случае проблем нет, потому что все статьи в затронутой группе структурно одинаковы, поэтому постраничное повторное обсуждение одного и того же вопроса было бы излишней тратой редакторского времени.  —  SMcCandlish ☏ ¢  😼  19:05, 26 февраля 2024 (UTC) [ ответить ]

Я согласен, что нам не следует быть слишком предписывающими, но, возможно, небольшое дополнение, проясняющее это намерение, помогло бы? Например, «Основные разделы, как правило, будут подробными разделами с заголовком уровня 2, но локальный консенсус может определить, что раздел более низкого уровня является «основным». - adamstom97 ( обсуждение ) 19:45, 26 февраля 2024 (UTC) [ ответить ]
Согласен, что не помешало бы какое-то разъяснение. Очевидно, я неправильно понял, что подразумевается под «основным разделом», и подозреваю, что я не один такой. Хотя я мог бы просто изменить его на «раздел уровня 2», что упростило бы ситуацию. Gawaon ( talk ) 20:33, 26 февраля 2024 (UTC) [ ответить ]
Добавьте заметку, которая, однако, пытается более прямо рассмотреть некоторые из обоснований RFC в дополнение к тому, что было сказано выше. Главным моментом в RFC было то, что люди попадали непосредственно в [под]разделы с помощью перенаправлений и заметных ссылок из других статей. Хотя мы никогда не можем «предотвратить» кого-либо, ссылающегося, скажем, на неясный заголовок 5-го уровня по какой-то причине, это не распространено, и среднестатистический читатель поймет, что ему, возможно, придется немного прокрутить страницу, чтобы полностью понять материал. Однако, если подраздел тематически посвящен отдельной подтеме с различными перенаправлениями и частыми упоминаниями в других статьях, то, что этот раздел является довольно автономным, является преимуществом для читателей (особенно на мобильных устройствах).  —  SMcCandlish ☏ ¢  😼  21:21, 26 февраля 2024 (UTC) [ ответить ]
  • Действительно, SMcCandlish. Это было очень плохое изменение правил, поощряющих только обдуманные ссылки. Когда люди вступают в эти дебаты, это как если бы читатель не мог ввести цель в поле поиска. Занимает семь или восемь секунд. Тони (обсуждение) 04:37, 28 февраля 2024 (UTC) [ ответить ]

В настоящее время идет обсуждение применения MOS:FORCELINK в инфобоксах. Любые отзывы от знающих редакторов будут высоко оценены. Спасибо! Nemov ( talk ) 21:21, 5 марта 2024 (UTC) [ ответить ]

В статьях о культурах CJK (китайская, японская и корейская) к неанглийским терминам добавлено множество ссылок Викисловаря (обычно они используют Template:Linktext ). Это избыточная ссылка или нет? Я начал думать, что они избыточны, но не похоже, что MOS:OVERLINK напрямую говорит об этом. 172.56.232.211 (обсуждение) 05:56, 6 марта 2024 (UTC) [ ответить ]

«В статьях» не поможет. Конкретные примеры? -- Майкл Беднарек ( обсуждение ) 07:13, 6 марта 2024 (UTC) [ ответить ]
Вот примеры на корейском языке. Некоторые люди добавляют ссылки Викисловаря к тоннам корейских терминов. Разве это не избыточное связывание? Википедия не обязана предоставлять ссылку для каждого отдельного неанглоязычного лексического элемента. 172.56.232.211 (обсуждение) 03:21, 7 марта 2024 (UTC) [ ответить ]
Спасибо за ссылку. По моему мнению, ссылки на Викисловарь могут быть полезны и предоставлять дополнительную информацию, хотя я бы предпочел внутритекстовые переводы. Там, где они уже есть, ссылки на Викисловарь кажутся излишними. Противоречат ли эти ссылки MOS:OVERLINK, я не могу сказать. С другой стороны, они не вредны. -- Майкл Беднарек ( обсуждение ) 04:49, 7 марта 2024 (UTC) [ ответить ]
Отступая от темы, MOS:FOREIGN советует:

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

В эссе Википедия: Как писать лучшие статьи § Используйте другие языки экономно говорится:

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

Иностранные слова, которые не так распространены в английском языке, при их использовании должны иметь MOS : SIMPLEGLOSS.— Bagumba ( обсуждение ) 07:21, 6 марта 2024 (UTC) [ ответить ]
Я бы поостерегся делать это обычной практикой для таких статей. Тони (обсуждение) 06:44, 7 марта 2024 (UTC) [ ответить ]

В этой теме обсуждается, целесообразно ли использовать ссылку перенаправления в канале.

У нас с Джой возник небольшой редакционный спор по поводу моих действий после переезда после закрытия RM, приведшего к перемещению Бояны (реки) в Буну (Адриатическое море) . Я внес различные правки в статьи, которые ссылаются на полученный редирект "Бояны (реки)", и очищал ссылки, когда сталкивался со следующими типичными сценариями:

  1. [[Бояна (река)|Буна]]
  2. [[Бояна (река)|Бояна]]

Независимо от того, какой термин стоит после трубы — Буна или Бояна, я изменил ссылку (перед трубой) на «Буна (Адриатическое море)», мотивируя это тем, что ссылка в трубной ссылке всегда должна быть прямой, в результате чего получается:

  1. [[Буна (Адриатическое море)|Буна]]
  2. [[Буна (Адриатическое море)|Бояна]]

С другой стороны, Джой на своей странице обсуждения предположил , что если читателю представлен термин «Бояна», то разметка ссылки должна оставаться следующей:

  • [[Бояна (река)|Бояна]]

... и что изменение трубопроводной ссылки в данном случае на [[Буна (Адриатическое море)|Бояна]] является «бессмысленным занятием», которое не должно выполняться и заслуживает отмены.

Похоже, она не оспаривала изменение названия [[Бояна (река)|Буна]] на [[Буна (Адриатическое море)|Буна]].

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

Следует ли MOS более четко указать, что конвейерные ссылки и перенаправленные ссылки — это разные методы, которые не следует смешивать, и что перед конвейером следует использовать только прямые ссылки, а не перенаправленные ссылки?

MOS:DABPIPE говорит, что конвейеризация и перенаправления — это два разных механизма , а WP:PIPE говорит: «Не путайте конвейерные ссылки и перенаправления» . Но должен ли MOS:PIPE также что-то сказать об этом? Что-то вроде:

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

— Алалч Э. 23:53, 5 апреля 2024 (UTC) [ ответить ]

Joy прав. MOS нигде не говорит, что «перед вертикальной чертой следует использовать только прямые ссылки», и на то есть веская причина. Очень распространенное использование разметки вертикальной черты — просто удалить заглушку в скобках и написать eg [[Bojana (river)|]](без ничего после вертикальной черты). При сохранении страницы наше программное обеспечение автоматически преобразует такие ссылки в [[Bojana (river)|Bojana]]. Такие автоматически сгенерированные канальные ссылки хороши, очень распространены (на самом деле, я подозреваю, что это самый частый вид канальных ссылок), и благодаря нашему механизму перенаправления они продолжат работать, как и прежде, если страница была перемещена. Так почему же вам следует изменить невидимый URL на использование «Buna», если вы оставите видимое слово («Bojana») нетронутым? На самом деле нет причин так делать. Gawaon ( talk ) 06:35, 6 апреля 2024 (UTC) [ ответить ]
Я согласен с Joy и Gawaon . Я не понимаю, что "мы не хотим знакомить читателя с названием редиректа, которое он ранее не видел". Насколько я могу судить, единственные имена, которые видит пользователь, это то, которое didplayed каналом, и то, которое отображается в целевой статье, на которую ведет ссылка: перенаправляются ли они туда напрямую или через редирект, mskes не имеет никакого значения, с какими именами мы "знакомим читателя". Или я неправильно понял, что означает "мы не хотим знакомить читателя с названием редиректа"? Кроме того, есть несколько веских причин, по которым ссылки через редиректы могут быть желательны, например, тот факт, что ссылка останется действительной, если редирект будет перенаправлен или превращен в статью, и я не понимаю, почему кто-то может подумать, что такие причины становятся менее действительными только потому, что способ, которым ссылка didplayed в статье, отличается, в чем и заключается суть этого конвейера. Разница между конвейерной ссылкой и не конвейерной ссылкой заключается только в том, какой текст отображается для ссылки в статье, содержащей ее, и я не вижу причин, по которым механизм, посредством которого читатель переходит к целевой статье, должен зависеть от того, как отображается текст. «Ссылка в конвейерной ссылке всегда должна быть прямой ссылкой» не имеет смысла, если только у нас также нет «ссылка в не конвейерной ссылке всегда должна быть прямой ссылкой»; почему эти два случая следует рассматривать по-разному? JBW ( talk ) 13:43, 12 апреля 2024 (UTC) [ reply ]
Согласен. Как советует WP:NOTBROKEN , во многих случаях предпочтительнее ссылаться на перенаправление. Особенно если есть ретаргетинг или написана статья, как вы упомянули, гораздо проще для всех, если все обратные ссылки уже ведут в нужное место, а не кому-то приходится выяснять, какие обратные ссылки следует перенаправить. (Я сделал это некоторое время назад с несколькими сотнями страниц, ссылающихся на школьную сегрегацию , которые должны были ссылаться на школьную сегрегацию в Соединенных Штатах , и в конечном итоге выгорели.) Исключением будут непечатные перенаправления, такие как опечатки и нестандартные схемы устранения неоднозначности, на которые мы не должны намеренно направлять трафик. -- Tamzin [ cetacean needed ] ( they|xe ) 04:02, 18 апреля 2024 (UTC) [ ответить ]

MOS:GEOLINK приводит два примера: Сидней , Австралия; и Буффало, Нью-Йорк , США. Это создает двусмысленность, которую Pi.1415926535 и я согласились поднять здесь после того, как она возникла в GAN : заключается ли смысл двух примеров в том, что ссылка должна охватывать все слова, кроме названия страны, или они описывают два альтернативных подхода, то есть можно одинаково написать " Буффало , Нью-Йорк, США"? Если на то пошло, можно ли написать " Сидней, Австралия "?

Я думаю, что ясность в этом вопросе была бы полезна. Мне не очень важно, какой ответ будет принят, хотя, как я уже говорил на GAN, я думаю, что есть умеренное преимущество в доступности связанного текста, охватывающего только название города: мне трудно отличить черный от синего в небольших количествах, и, если бы я не изменил свой common.css, чтобы решить эту проблему, « Buffalo, New York » и « Buffalo , New York » выглядели бы для меня почти одинаково, из-за чего было бы неясно, куда я попаду, когда нажму на «New York». -- Tamzin [ cetacean needed ] ( they|xe ) 03:42, 18 апреля 2024 (UTC) [ ответить ]

Я понял, что ссылка должна в целом соответствовать названию статьи (например, Buffalo, New York как одна ссылка). Однако это усложняет ситуацию для мононимичных статей, таких как Sydney, в областях, где другие города (например, Campbelltown, New South Wales ) имеют более крупную единицу в названии статьи. Я определенно согласен, что следует использовать только одну ссылку независимо от стиля. Pi.1415926535 ( talk ) 04:50, 18 апреля 2024 (UTC) [ ответить ]
Я не вижу никакой двусмысленности в MOS:GEOLINK. Связывайте то, что должно быть связано, не связывайте то, что не должно быть связано, избегайте труб. -- Майкл Беднарек ( обсуждение ) 06:20, 18 апреля 2024 (UTC) [ ответить ]
Но в случае с Буффало, разве не только «Буффало» должно быть связано? «, Нью-Йорк» — это неоднозначность, включенная в заголовок статьи, а не часть общепринятого названия места, которое просто «Буффало», так же как общепринятое название Сиднея — «Сидней». Я не могу вспомнить ни одного другого места, где при выборе текста для ссылки мы бы заботились о том, как озаглавлена ​​соответствующая статья. — Тамзин [ cetacean needed ] ( they|xe ) 14:49, 18 апреля 2024 (UTC) [ ответить ]
Нет, поскольку название статьи — Буффало, Нью-Йорк , просто дайте ссылку полностью. Написание этого как [[Buffalo, New York|Buffalo]], New Yorkбыло бы просто излишне запутанным. Gawaon ( talk ) 15:30, 18 апреля 2024 (UTC) [ ответить ]
Я не вижу, что тут запутанного. Нашим читателям ясно, куда их приведет ссылка, и это гораздо важнее, чем несколько дополнительных байт вики-разметки. Это также обеспечивает согласованность в случае, когда статьи имеют непоследовательное разрешение неоднозначности из-за особенностей политики заголовков статей. В противном случае мы получаем что-то вроде «расстояние от Торонто , Онтарио, Канада, до Ниагарского водопада, Нью-Йорк , США». В любом случае, если это действительно так, что это руководство должно подчиняться политике заголовков статей при определении того, какие слова следует ссылать — что, опять же, кажется странным, но что поделать — это следует прояснить, ради меня и ради 206 других случаев использования только « Буффало , Нью-Йорк» (и 137 случаев « Финикс , Аризона» и т. д. и т. п.). -- Тамзин [ нужен кит ] ( они|xe ) 16:15, 18 апреля 2024 (UTC) [ ответить ]
Я не вижу ничего плохого в вашем примере. Ниагарский водопад — город поменьше Торонто, так что это не особенно удивительно. Думаю, если вы предпочитаете писать более сложным образом, никто вас за это не упрекнет, хотя я бы, конечно, упростил любой случай, с которым [[Buffalo, New York|Buffalo]], New Yorkсталкиваюсь в редактируемой мной статье, [[Buffalo, New York]]без всяких угрызений совести. (Хотя мне было бы лень прогонять его по статьям, которые я иным образом не редактирую.) Gawaon ( talk ) 17:42, 18 апреля 2024 (UTC) [ ответить ]
Ниагарский водопад — город поменьше Торонто, так что это не особенно удивительно ← Но интуитивно понятно ли это читателям? Просто выглядит несбалансированным. Если бы я увидел это как неспециалист, я бы подумал: почему одна ссылка только на город, а другая — на следующий уровень? Я не обязательно считаю, что подход, который вы отстаиваете, следует запретить, но кажется разумным разрешить любой из них, если он соответствует статье. — Тамзин [ cetacean needed ] ( they|xe ) 17:46, 18 апреля 2024 (UTC) [ ответить ]
Модели Bluelink, comma, blacktext обычно не связывают более крупные единицы ; мне было бы жаль, если бы это изменилось на blue, comma, blue . NebY ( обсуждение ) 17:57, 18 апреля 2024 (UTC) [ ответить ]

Далее, какое правило действует, если есть три субъекта, постепенно увеличивающиеся? Например: Грубешув , Люблинское воеводство , Польша. Так ли мы должны поступать? — Biruitorul Talk 21:13, 18 апреля 2024 (UTC) [ ответить ]

Обычно связана только первая (самая маленькая) сущность. Gawaon ( обсуждение ) 21:59, 18 апреля 2024 (UTC) [ ответить ]
Почему мы должны ожидать, что наши читатели будут знать, где (или что) находится Люблинское воеводство ? Кажется крайне произвольным — и решенным без особого участия сообщества. Dahn ( обсуждение ) 05:57, 19 апреля 2024 (UTC) [ ответить ]
MOS:GEOLINK говорит: «как правило, не связывайте более крупные единицы». Это не строгий запрет, а просто общая рекомендация. Здравый смысл применим, как всегда. Также, я полагаю, идея в том, что если читатели захотят узнать больше, они перейдут по ссылке на Хрубешув , где они легко найдут другую ссылку на Люблинское воеводство (фактически, в первом предложении). Gawaon ( talk ) 06:22, 19 апреля 2024 (UTC) [ ответить ]
Также, общее правило, из которого это логически следует: "По возможности не размещайте ссылки рядом друг с другом, чтобы не выглядеть как одна ссылка", так как это может сбить с толку наших читателей. Достаточно верно, и это применимо в этом случае так же хорошо, как и в других. Gawaon ( talk ) 06:29, 19 апреля 2024 (UTC) [ ответить ]

"MOS: ПЕРЕСЫЛКА" перечислены наПеренаправления для обсуждения

Перенаправление MOS: OVERLINKING было указано в перенаправлениях для обсуждения , чтобы определить, соответствует ли его использование и функция правилам перенаправления . Читатели этой страницы могут прокомментировать это перенаправление в Wikipedia:Redirects for discussion/Log/2024 April 25 § MOS: OVERLINKING до тех пор, пока не будет достигнут консенсус. Utopes ( обсуждение / продолжение ) 22:15, 25 апреля 2024 (UTC) [ ответить ]

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

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

Итак, это не жесткое правило или что-то в этом роде, просто какой-то язык, дающий людям понять, что ссылки — это то, к чему люди прикасаются, а не просто читают. Я не видел большого обсуждения этого в архивах этой страницы, но если у вас есть институциональные знания о предыдущем обсуждении, это было бы особенно кстати. Или, может быть, это уже обсуждалось в другом месте. Но я подумал, что подниму этот вопрос. Indignant Flamingo ( обсуждение ) 22:15, 23 мая 2024 (UTC) [ ответ ]

Я понимаю, что вы говорите, так как иногда я несколько раз в день нажимаю не на ту ссылку в своем списке наблюдения. Однако, помимо слишком близко расположенных ссылок на одной строке, которые уже не приветствуются, относительное расположение ссылок на соседних строках будет отличаться от одного устройства к другому в зависимости от ширины экрана. Я не вижу способа обойти это. Дональд Олбери 00:00, 24 мая 2024 (UTC) [ ответить ]
Несколько раз я видел, как MOS:SEAOFBLUE -исправляющие правки возвращались, с краткими сводками правок в духе "не так уж и много синего". Я думаю, что иногда есть беспечное чувство "большое дело, просто нажмите "назад" и щелкните нужную ссылку, [глупый]", и что SOB - это чисто косметический (и произвольный) MOS. Было бы хорошо иметь хотя бы пояснительную сноску, чтобы на обоснование можно было ссылаться как на обучающий момент. — Bagumba ( обсуждение ) 00:37, 24 мая 2024 (UTC) [ ответить ]
Это важный момент (доступность касается не только зрения), о котором стоит упомянуть. Черновой язык мне кажется хорошим. Спасибо, что подняли этот вопрос и составили черновик. Leviovich ( talk ) 16:39, 24 мая 2024 (UTC) [ ответить ]
Я добавил предложенный текст с небольшим изменением, чтобы соответствовать повелительному наклонению окружающего текста руководства. Я ценю ваши отзывы, и любые изменения, конечно, приветствуются. Я думаю, что нам следует заняться доступностью сенсорного экрана, но у меня нет очень сильных чувств по поводу основного текста, сноски и всего остального. Indignant Flamingo ( talk ) 18:14, 30 мая 2024 (UTC) [ ответить ]

Ссылки на географические места

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

Это такое глупое правило. Что означает Грин-Бей , США для читателей? Для географических мест единственное, чего нам следует избегать, это ссылки на известные страны (например, Париж , Франция). Если бы мы связывали небольшой город, мы должны были бы связать и город, и штат (например, Бирмингем , Алабама ), особенно для городов в такой огромной стране, как США или Китай. 120.16.11.84 (обсуждение) 21:24, 17 июня 2024 (UTC) [ ответить ]

Обратите внимание, что Green Bay — это страница устранения неоднозначности, и вы не должны ссылаться на нее в статье. В общем, для мест в Соединенных Штатах вы должны использовать штат или территорию, в которой находится место, например [[:Green Bay, Wisconsin|Green Bay]], Wisconsin, и не использовать «United States». Дональд Олбери 00:07, 18 июня 2024 (UTC) [ ответить ]
Ну, Висконсин не такой известный штат, как Калифорния или Техас, я думаю, ссылка должна быть "[[Green Bay, Wisconsin|Green Bay]], [[Wisconsin]]". 120.16.11.84 (обсуждение) 09:46, 18 июня 2024 (UTC) [ ответить ]
Нет, Грин-Бей, Висконсин, просто отлично. Любому, кто действительно хочет почитать о штате, нужно просто нажать один или два раза больше — ничего страшного, и это гораздо менее запутанно и менее вероятно приведет к ошибочным нажатиям. Gawaon ( talk ) 10:17, 18 июня 2024 (UTC) [ ответить ]
Всякий раз, когда я сталкиваюсь с неоднозначным географическим термином, который был передан и удвоен, как предложено здесь ( [[Qianxi, Guizhou|Qianxi]], [[Guizhou]]), я просто копирую его вниз, чтобы связать неоднозначное название полностью для чистоты и простоты ( Цяньси, Гуйчжоу ). Я ожидаю, что многие другие сделают то же самое. Folly Mox ( обсуждение ) 10:44, 18 июня 2024 (UTC) [ ответ ]
Ссылки предоставляют контекст, который может быть необходим неинформированному читателю, но мы не ссылаемся на предполагаемые знания или общие знания. Поэтому в большинстве контекстов мы не ссылаемся на apple , bridge или plant . При необходимости мы ссылаемся на уровень выше, поэтому в статье Granny Smith мы должны ссылаться на apple , но не на fruit или plant , которые находятся на большем расстоянии.
Географически это то же самое. Так, скажем, в Альфреде Лоусоне мы имеем «Он основал компанию Lawson Aircraft Company в Грин-Бей, штат Висконсин , для строительства военных учебных самолетов…» . Если читатель не понимает Грин-Бей, штат Висконсин , он может перейти по ссылке, чтобы узнать больше об этом месте, а статья о месте должна дать весь контекст, который необходим любому читателю для понимания географии, связанной с Лоусном. Штаты и высокоуровневые географические образования являются предполагаемыми знаниями, а штат (в данном случае) не является чем-то, что напрямую связано с рассматриваемой темой. —  HTGS  ( обсуждение ) 05:39, 20 июня 2024 (UTC) [ ответ ]

Необычная ситуация, связанная с привязкой пользовательского пространства к основному пространству

Итак, я был на Входит в состав только что после того, как поиздевался над грамматикой в ​​не связанной теме в другом месте. Это статья, в которой обсуждается весь подзаголовок уровня 2 процесса в Вики с точки зрения надежных источников: Входит в состав § Удаление из Википедии .

Внизу статьи, в разделе Внешние ссылки , мы приводим ссылку на эссе редактора, который поставил себе задачу удалить эту фразу из основного пространства: User:Giraffedata/comprised of . (Кстати, WP:COMPRISEDOF перенаправляет на то же эссе.) Мне пришло в голову, что это на самом деле не внешняя ссылка.

Руководство, к которому прикреплена эта страница обсуждения , гласит: В статьях не ссылайтесь на страницы за пределами пространства имен статей, за исключением статей о самой Википедии (в якоре MOS:DRAFTNOLINK ). Мне интересно, касается ли этот случай самой Википедии достаточно , чтобы ссылаться на эссе User:Giraffedata в тексте статьи. Я думал о разделе hatnote вроде {{ see also }} , но я хотел спросить здесь, чтобы узнать, что думают люди. Folly Mox ( talk ) 12:18, 30 июня 2024 (UTC) [ ответить ]

Если этот раздел останется, то он будет о самой Википедии. (Я бы сказал, что он не должен оставаться). Nikkimaria ( обсуждение ) 15:52, 30 июня 2024 (UTC) [ ответить ]
Во-первых, это важно и проверяемо, поэтому допустимо для включения. Во-вторых, можно ссылаться на страницы проектов в очень редких случаях, когда их можно считать как подходящими, так и надежными источниками. Возможно, лучше всего будет ссылаться на конкретную версию (если это не было сделано) и включать ссылку на архив. Всего наилучшего: Rich Farmbrough 21:05, 23 июля 2024 (UTC).[ отвечать ]
Основополагающий принцип заключается в том, что, освещая себя в энциклопедии, для сохранения нейтралитета мы хотим относиться к Википедии как к любому другому источнику. Часть этого заключается в том, чтобы относиться к ссылкам на контент на этом сайте за пределами основного пространства так же, как мы относимся к любой другой внешней ссылке. Sdkb  talk 05:52, 26 июля 2024 (UTC) [ ответить ]

Ясность и конкретность в примере реквиема

Раздел «Ясность ссылок» не рекомендует «Превин провел [[Реквием (Моцарт)|Реквием]] Моцарта», а затем раздел «Специфичность» говорит, что он предпочтительнее просто [[Реквием]]. Кажется, есть иерархия предпочтений, что имеет смысл, но она остается неявной, и мне потребовалось некоторое время, чтобы понять, о чем она говорит. Есть ли возможность/необходимость сделать иерархию более явной? -- Northernhenge ( обсуждение ) 05:42, 5 августа 2024 (UTC) [ ответить ]

Руководство по перелинковке в ITN

Вопрос для наблюдателей за этой страницей обсуждения: противоречит ли ссылка на премьер-министра Бангладеш и Тегерана в Template:In the News духу пунктов WP:OVERLINK о политиках и поселениях? Я считаю, что да, поскольку премьер-министры — это обычная профессия, а Тегеран — известная столица, но я хотел бы проверить здравомыслие, прежде чем потенциально начинать обсуждение. Спасибо! Ed  [обсуждение]  [OMT] 15:06, 8 августа 2024 (UTC) [ ответить ]

Я бы сказал нет обоим. Премьер-министр Бангладеш — это конкретная статья с полезной информацией, ссылка на общую статью о премьер-министре — это другое дело. Не все наши читатели уже были в Тегеране или близко знакомы с этим городом, поэтому я бы сказал, что эта ссылка тоже наверняка полезна. Gawaon ( talk ) 15:14, 8 августа 2024 (UTC) [ ответить ]
Спасибо, Gawaon ! Я ценю твои мысли. Ed  [обсуждение]  [OMT] 02:16, 10 августа 2024 (UTC) [ ответить ]
Ссылка на премьер-министра избыточна, когда жирным шрифтом выделена Шейх Хасина . Читатели обычно знают, кто такой премьер-министр, и могут перейти к ее биографии для получения дополнительных ссылок по теме, например, Премьер-министр Бангладеш . — Багумба ( обсуждение ) 02:55, 10 августа 2024 (UTC) [ ответить ]

"MOS: ПЕРЕСЫЛКА" перечислены наПеренаправления для обсуждения

Перенаправление MOS: OVERLINKING было указано в перенаправлениях для обсуждения , чтобы определить, соответствует ли его использование и функция правилам перенаправления . Читатели этой страницы могут прокомментировать это перенаправление в Wikipedia:Redirects for discussion/Log/2024 August 8 § MOS: OVERLINKING до тех пор, пока не будет достигнут консенсус. Обсуждение Queen of Hearts  20:34, 8 августа 2024 (UTC) [ ответить ]

Первоначально создано для Full-URL_wiktionary_link/doc#Alternatives, но, вероятно, относится к MOS:LINKING .

Несколько способов встроить ссылку Викисловаря в прозу:

ТонТипПример
Полуэнциклопедический [а]Полное заявление«Грузоперевозки» означают .... Поэтому ...
энциклопедическийСуществительное (специфическое)Согласно определению «острого соуса» в Викисловаре...
энциклопедическийСуществительное (немного неопределенно)Я прочитал определение слова «волшебная палочка» и узнал...
энциклопедическийСлова-как-слова (больше синего)Слово дядя может означать ...
Энциклопедический [б]Слова как слова (менее синие)Слово «дядя» может означать ...
ПолуэнциклопедическийГлагольная фраза (информационная)Викисловарь определяет «работу ног» как ...
ПолуэнциклопедическийГлагольная фраза (учебная)Слово «downtime» может относиться как к расслаблению , так и к простоям (по крайней мере, в американском английском; см. Викисловарь).
Только страницы обсужденияПредложная фразаСлово "downtime" может относиться как к расслаблению , так и к простоям . Ну, по крайней мере, в американском английском.
энциклопедическийУстранение неоднозначности в скобкахСм. лунный свет (Викисловарь).
ПолуэнциклопедическийКвалификаторСогласно Викисловарю, «грибная комната» — это...
Только страницы обсужденияКвалификатор в сторонеДыня — разновидность дыни (по крайней мере, согласно Викисловарю).
Только страницы обсужденияГлагольная фраза (повествовательная)Я поискал слово «кибер» и о боже, ...
Только страницы обсужденияЕхидное замечаниеВы уверены, что это хороший источник для ссылок в нашей статье? Викисловарь иногда может быть странным

Примечания

  1. ^ Не делайте целое предложение ссылкой, если оно будет длинным.
  2. ^ В этом случае не используйте курсив для выделения отдельных слов; вместо этого рассмотрите возможность использования кавычек.

—  Jruderman ( обс. ) 06:04, 11 августа 2024 (UTC) Jruderman ( обс. ) 06:04, 11 августа 2024 (UTC) [ ответить ]

Я не думаю, что согласен, что это относится к MOS. Также, почему вы используете полный URL для ссылки на Викисловарь вместо ссылки на интервики [[:wikt:]] , или {{ linktext }} или один из других шаблонов, перечисленных в {{ Wiktionary templates common doc }} ? Folly Mox ( обсуждение ) 14:14, 11 августа 2024 (UTC) [ ответить ]
Какой из существующих шаблонов «тонкого намека» для ссылок на Викисловарь вам нравится больше всего?
Хотите ли вы помочь мне изменить мой шаблон так, чтобы он принимал слаг и якорь вместо полного URL-адреса?
—  Jruderman ( обсуждение ) 16:31, 11 августа 2024 (UTC) [ ответить ]
Ах, теперь я понимаю, что одно из основных назначений вашего шаблона — это значок smol. Чтобы использовать слаг и якорь вместо полного URL (что звучит проще и соответствует типичному представлению для интервики-ссылок), вам нужно всего лишь изменить первую строку с на ( конечно , сохранив часть File:Wiktionary small.svg ). Я не уверен в вариантах использования полного URL и подумал, что они у вас могут быть.{{Plain link|1={{{1}}}|2={{{2}}}[[:wikt:{{{1}}}|{{{2}}}]]
Что касается моего первоначального комментария о том, относится ли таблица выше к MOS, я просто вижу, что она предлагает широкий спектр использования, а не описывает лучшую практику. Я не уверен, существует ли лучшая практика для связывания Викисловаря.
Мой первый комментарий в этой теме теперь, когда я снова его вижу, кажется мне очень сварливым. Пожалуйста, примите мои извинения за это. Я намеревался выразить тоном любопытство с вкраплениями замешательства.
Для оставшегося вопроса мой любимый тонкий намек — URL-адрес цели ссылки. Я не практикую размещение указателей на разных проектах в экосистеме Wikimedia, но многие редакторы это делают, и я не против. С наилучшими пожеланиями, Folly Mox ( talk ) 20:30, 11 августа 2024 (UTC) [ ответить ]

Веб-сайты и платформы социальных сетей

Моя правка в Miranda Sings была отменена, когда я добавил ссылку на статью в Instagram , потому что редактор посчитал, что это нарушение MOS:OVERLINK. Узнаваемые веб-сайты и платформы социальных сетей, как правило, не должны быть связаны, поэтому редакторы могут следовать вышеупомянутому правилу. Sparkbean ( talk ) 16:04, 11 августа 2024 (UTC) [ ответить ]

Но теперь вы добавили утверждение, что крупные веб-сайты не должны быть связаны с MOS:OVERLINK? Вы действительно так думаете? Лично я не думаю — я бы скорее сказал, что редакторы должны иметь право добавлять эти ссылки, если они считают их полезными. Здесь следует учесть тот момент, что крупные примеры веб-сайтов и тому подобное, как правило, устаревают гораздо быстрее, чем (скажем) крупные страны или города, например, кто еще помнит MySpace или Altavista? Gawaon ( talk ) 17:06, 11 августа 2024 (UTC) [ ответить ]
@ Sparkbean : Для протокола, я отменил ваше дополнение на данный момент. Давайте сначала посмотрим, сможем ли мы найти консенсус по этому поводу здесь. Как я уже сказал, лично я не думаю, что это должно быть там. Gawaon ( talk ) 17:11, 11 августа 2024 (UTC) [ ответить ]
Некоторые редакторы думают, что все знают Instagram, но я согласен с вашим ответом. Sparkbean ( talk ) 17:39, 11 августа 2024 (UTC) [ ответить ]

Многим редакторам остается неясным, как следует интерпретировать MOS:GEOLINK в отношении таких последовательностей, как Сидней, Новый Южный Уэльс, Австралия . Следует ли восстановить эту правку? Khiikiat ( talk ) 23:45, 11 августа 2024 (UTC) [ ответить ]

  • Комментарий. Это не совсем о MOS:GEOLINK, а о том, следует ли упоминать штат, когда речь идет о таком крупном городе, как Сидней, верно? Gawaon ( talk ) 06:27, 12 августа 2024 (UTC) [ ответить ]
    Нет, речь идет о MOS:GEOLINK. Текущие примеры неясны. Многие редакторы смотрят на примеры и приходят к выводу, что не следует связывать только страну. Khiikiat ( talk ) 07:14, 12 августа 2024 (UTC) [ ответить ]
    Пример Буффало, Нью-Йорк, достаточно ясно показывает, что вместо трех возможных ссылок (в плохой версии) следует сделать только одну (в хорошей версии). Gawaon ( обсуждение ) 07:50, 12 августа 2024 (UTC) [ ответить ]
    Я не думаю, что это достаточно ясно, потому что люди все еще путаются. Например, см. обсуждение Википедии: Руководство по стилю/линковке#MOS:GEOLINK выше. The Doom Patrol написал: WP:GEOLINK указывает на более крупную единицу , а не единицу(ы). Это относится к стране, как показано в прилагаемых примерах. Фактически, это руководство обсуждает только случай, когда две географические единицы разделены запятой, причем вторая единица — это конкретно страна. Khiikiat ( обсуждение ) 09:01, 12 августа 2024 (UTC) [ ответить ]
  • Комментарий В чем была причина замены примера «Буффало, Нью-Йорк» на «Лондон, Онтарио»? — Багумба ( обсуждение ) 07:30, 12 августа 2024 (UTC) [ ответить ]
    Я думаю, так понятнее. [[New York (state)|New York]]Только добавляет путаницы. Khiikiat ( обсуждение ) 09:00, 12 августа 2024 (UTC) [ ответить ]
  • Комментарий . Возможно, руководство следует изменить на что-то вроде этого: для географического местоположения, выраженного как последовательность двух или более территориальных единиц, свяжите только первую единицу. Khiikiat ( talk ) 09:02, 12 августа 2024 (UTC) [ ответить ]
    Мне кажется, это хорошо. Мы также могли бы добавить третий пример в форме город/поселок/деревня, штат, страна или что-то подобное, со связанным только первым именем, но я не думаю, что это должен быть большой город, такой как Сидней, где обычно опускают штат. Может быть, Куоткуан , Южный Ланаркшир, Шотландия ? Кстати, я не думаю, что нам нужен RfC для этого. Во-первых, это не очень спорно, и, более того, не определены разумные варианты. Gawaon ( talk ) 10:41, 12 августа 2024 (UTC) [ ответить ]
    Я перефразировал руководство, добавил пример Quothquan и закончил RfC. Если кто-то возражает, изменения можно отменить и обсудить снова. Khiikiat ( talk ) 10:46, 13 августа 2024 (UTC) [ ответить ]
    @ Khiikiat : Это все еще не решает проблему, которую я поднял выше в § Неоднозначность в примерах GEOLINK: остается неясным, говорит ли MoS людям, что они должны включать ", New York" в отображаемый текст ссылки, или допустимо, чтобы ссылка охватывала только слово "Buffalo", без ", New York". Я утверждаю, что первое было бы странным вторжением наших правил устранения неоднозначности заголовков статей в правила MoS для прозы, и менее доступно, учитывая, что только воротник запятой разъясняет, куда вы нажмете "New York". -- Tamzin [ cetacean needed ] ( they|xe ) 05:39, 14 октября 2024 (UTC) [ ответить ]
    Я думаю, что руководство в его нынешнем виде достаточно ясно: [[Buffalo, New York]], United Statesпредпочтительнее, чем [[Buffalo, New York|Buffalo]], New York, United States. Руководство можно изменить, но я подозреваю, что большинство редакторов поддержат его [[Buffalo, New York]], United Statesради простоты. Khiikiat ( talk ) 22:13, 14 октября 2024 (UTC) [ ответить ]
    Действительно. Gawaon ( обсуждение ) 22:15, 14 октября 2024 (UTC) [ ответить ]
    Если это то, что есть в руководстве, то в руководстве должно быть сказано это. В настоящее время требуется несколько выводов, чтобы прийти к этому, и мы можем видеть из этой страницы обсуждения, что не все интерпретируют текущую формулировку одинаково. Возможно, на этом этапе необходим RfC. -- Tamzin [ cetacean needed ] ( they|xe ) 01:52, 16 октября 2024 (UTC) [ ответить ]
    Или кто-нибудь мог бы просто изменить страницу, чтобы сделать ее более понятной. Gawaon ( talk ) 07:10, 16 октября 2024 (UTC) [ ответить ]
    Для этого потребуется консенсус относительно того, что именно это и подразумевается под этим значением, но я не думаю, что это было установлено. -- Тамзин [ необходимы китообразные ] ( they|xe ) 08:35, 16 октября 2024 (UTC) [ ответить ]
    Ну, быть WP:BOLD и посмотреть, откатился ли кто-то назад, обычно является самым простым способом узнать, есть ли консенсус. Gawaon ( talk ) 16:47, 16 октября 2024 (UTC) [ ответить ]
    Я хочу сказать, что сэкономлю время: я бы вернул его, потому что по этому поводу нет единого мнения. -- Тамзин [ необходимы китовые ] ( they|xe ) 17:31, 16 октября 2024 (UTC) [ ответить ]
    Почему бы тогда не добавить разъяснение, которое, по вашему мнению, было бы консенсусным? Насколько я могу судить, ничто в этой дискуссии не указывает на отсутствие консенсуса. Gawaon ( talk ) 17:57, 16 октября 2024 (UTC) [ ответить ]
    Если бы я менял это, чтобы отразить свое понимание того, как это правило обычно применяется, я бы добавил сноску, в которой говорилось бы: «Как связывание всего „ Buffalo, New York “, так и добавление только „ Buffalo “ являются приемлемыми. Один и тот же подход должен применяться последовательно на протяжении всей статьи». Все остальное было бы преувеличением консенсуса в любом направлении. -- Tamzin [ необходимы китовые ] ( they|xe ) 18:40, 16 октября 2024 (UTC) [ ответить ]
    Это действительно не согласовано, я бы сказал. Конечно, писать « Буффало » нормально, если это весь текст, который вам нужен, но какой смысл писать « Буффало , Нью-Йорк» вместо просто « Буффало, Нью-Йорк »? Gawaon ( talk ) 17:43, 17 октября 2024 (UTC) [ ответить ]
    Как я уже объяснял ранее, это и более последовательно (например, рядом с « Атланта , Джорджия»), и более доступно (« Буффало, Нью-Йорк » трудно отличить от « Буффало , Нью-Йорк »). Согласны вы с этим или нет, мне ясно, что текущая политика неадекватно объясняет, какой подход здесь правильный. Я начну RfC. -- Tamzin [ необходим кит ] ( they|xe ) 20:21, 17 октября 2024 (UTC) [ ответить ]

Неправильные сочетания клавиш

На мобильном телефоне использование сочетаний клавиш MOS:UL и MOS:OL перемещает их в конец соответствующего подраздела, так что нелегко понять, с чем они связаны. В последнем случае, по сути, кажется, что сочетание клавиш ссылается на следующий подраздел (MOS: CIRCULAR). Я не уверен, является ли это поведение особенностью моего мобильного телефона или общим для мобильных устройств в целом. Если последнее имеет место, кто-нибудь знает, можно ли что-то с этим сделать?

( Эдвин Нортумбрийский ( разговор ) 00:14, 24 сентября 2024 (UTC)) [ ответить ]

Просто вмешиваюсь, чтобы сказать, что могу воспроизвести проблему. Не уверен, что ее вызывает. Оба перенаправления нацелены на заголовки разделов, поэтому я не думаю, что это как-то связано с якорями или Template:Shortcut . На десктопе проблем нет. Firefangledfeathers ( talk / contribs ) 00:38, 24 сентября 2024 (UTC) [ ответить ]
Я довольно часто сталкиваюсь с этим на страницах projectspace с большим количеством сокращений подразделов ( MOS:PINYIN тоже так делает). Я всегда предполагал, что это как-то связано с тем, что браузер выясняет, где сфокусироваться, прежде чем все, что находится выше, закончится развертыванием. Я использую Firefox на Android. Folly Mox ( обсуждение ) 01:51, 24 сентября 2024 (UTC) [ ответить ]

Какие стили предпочтительны? Robertiki ( обсуждение ) 15:37, 28 сентября 2024 (UTC) [ ответить ]

Обычно я удаляю и вижу, как другие удаляют их, хотя я не знаю, есть ли для этого функциональная причина или это просто для повышения читабельности. DonIago ( talk ) 22:50, 28 сентября 2024 (UTC) [ ответить ]
Для страниц обсуждения их следует удалить, и я обычно так и делаю. Хотя я не так хорош в сводках правок. Обычно работает метод «cup/paste» поверх заголовка статьи. Gah4 ( talk ) 08:38, 30 сентября 2024 (UTC) [ ответить ]

отсоединениеНью-Йорк Ситив информационном окне?

Я заметил, что @ UrielAcosta отключил ссылку на NYC в инфобоксе, потому что так сказал MOS. Конечно, MOS говорил не о инфобоксе, а о тексте статьи? И почему вы хотите, чтобы Нью-Йорк (штат) был связан без ссылки на NYC? Если бы кто-то действительно хотел больше информации о том, где проживал Авраам Джошуа Хешель , разве город не был бы полезнее, чем более крупный и менее конкретный штат? Андре 🚐 05:16, 8 октября 2024 (UTC) [ ответить ]

Если что-то нужно связать, связывайте город с помощью MOS:GEOLINK и никогда не связывайте отдельно более крупные единицы, такие как штат, страна и т. д. — Bagumba ( обсуждение ) 05:22, 8 октября 2024 (UTC) [ ответить ]
Более того, чем проза, инфобоксы подвержены влиянию редакторов, которые хотят «единообразности» в статьях. Количество оттока на предполагаемом MOS:OVERLINK Нью-Йорка и других «крупных» городов не стоит этого. Я бы поддержал исключение для инфобоксов.— Багумба ( обсуждение ) 05:28, 8 октября 2024 (UTC) [ ответить ]
Разве подавляющее большинство грамотных читателей английского языка уже не знакомы с Лондоном, Парижем, Римом, Афинами, Каиром, Москвой, Мадридом, Нью-Йорком, Мехико, Дели, Иерусалимом, Лос-Анджелесом, Пекином, Токио, Сиднеем, Гонконгом, Лагосом, Рио-де-Жанейро, Стокгольмом, Гаваной и т. д.? Плюс Сакраменто и Сан-Франциско ближе к месту, где я живу? Cullen328 ( talk ) 05:31, 8 октября 2024 (UTC) [ ответить ]
Кроме того, незарегистрированные и новые редакторы постоянно исправляют, казалось бы, «отсутствующую» ссылку. Такие типы правок почти всегда находятся в инфобоксах. Принудительное применение этого просто создает отток, так как он будет бесконечно перемещаться туда-сюда. Я понимаю OVERLINK, но я бы пошел на компромисс ради бесконечного трафика инфобокса; недостаток незначительный.— Bagumba ( обсуждение ) 05:38, 8 октября 2024 (UTC) [ ответить ]
Я бы сказал, что, судя по написанному, MOS, похоже, не рассматривает инфобоксы. Похоже, инфобоксы очень часто являются первым, на что люди смотрят, когда открывают страницу. Поэтому я бы сказал, что инфобокс должен перечислять основные вещи и ссылаться на них для удобства использования. Другие рекомендации о том, чтобы не ссылаться на него, должны применяться к тексту статьи. Андре 🚐 06:07, 8 октября 2024 (UTC) [ ответить ]
Согласен, было бы лучше исключить инфобоксы из OVERLINK, для согласованности и простоты, если не для чего-то еще. Лично я нахожу правило OVERLINK «не ссылаться на основные примеры» довольно нелогичным и непоследовательным в любом случае. Почему Бельгия должна быть связана, а Франция — нет ? Или обе должны быть связаны, или ни одна? Я не могу сказать точно, склонен ссылаться, когда сомневаюсь, и думаю, что Википедия ничего не потеряет, если вообще откажется от этого правила. Gawaon ( обсуждение ) 07:51, 8 октября 2024 (UTC) [ ответ ]
Нью-Йорк и Лондон — это не только «общеупотребимые термины», но и уникальные названия столиц? (Возможно, есть технические средства, которые не позволяют связать эти два понятия в каком-либо информационном окне? Как насчет того, чтобы поразить кого-нибудь небольшим электрическим разрядом, если кто-то попытается это сделать? Скоро они научатся ! Martinevans123 ( обсуждение ) 13:26, 8 октября 2024 (UTC) [ ответить ]
Примеры OVERLINK включают повседневные слова, распространенные профессии, основные страны и языки и многое другое. Стоит ли нам теперь начать связывать доктора в инфобоксах или даже — если я правильно понял ваше последнее предложение — вообще отказаться от этого правила и связать его в тексте статьи? NebY ( talk ) 13:29, 8 октября 2024 (UTC) [ ответить ]
Я говорю о географических объектах, таких как страны и города, а не обязательно о чем-то еще. Gawaon ( talk ) 20:27, 8 октября 2024 (UTC) [ ответить ]
Разве мы не обсуждали это в прошлом году? В Википедии обсуждение: Руководство по стилю/Ссылки/Архив 21 § Ссылки на Нью-Йорк Сити ? Folly Mox ( обсуждение ) 13:16, 8 октября 2024 (UTC) [ ответить ]
Обсуждение здесь касается именно инфобоксов. — Bagumba ( обсуждение ) 13:39, 8 октября 2024 (UTC) [ ответить ]
  • Я не вижу принципиальной разницы между ссылкой на элемент в инфобоксе или где-либо еще. Нью-Йорк слишком известен и слишком неопределен, чтобы ссылаться практически где-либо. Тони (обсуждение) 02:24, 1 ноября 2024 (UTC) [ ответить ]

Я считаю, что было бы полезно сформировать консенсус и направить редакторов по применению MOS:GEOLINK к историческим странам и/или образованиям. Например, разногласия возникли по этому поводу в Talk:Josip Broz Tito § Infobox arrangement , где редакторы считают необходимым включить и связать субнациональную единицу, к которой принадлежало место, а в противном случае историческую страну, вот так:

Я цитирую аргументы первоначального автора предложения (@Thedarkknightli ) : « В случае Кумровца, Австро-Венгрия, как вы знаете, больше не существует; я имею в виду, что ни один из примеров в MOS:GEOLINK не включает страну, которая больше не существует. Что касается случая Любляны, я не думаю, что большинство читателей знают, что это часть Словении; также, как вы знаете, она не была столицей или крупнейшим городом Югославии, в отличие от Белграда ». – Vipz ( обсуждение ) 20:15, 8 октября 2024 (UTC) [ ответить ]

Не будет ли включение подсущности для первой сущности следующим?:
Кумровец , Королевство Хорватия-Славония , Австро-Венгрия OyMosby ( обсуждение ) 12:46, 9 октября 2024 (UTC) [ ответить ]
@ Vipz : Я согласен, что следует добавить руководство по этому вопросу. По моему мнению, MOS:GEOLINK также следует применять к последовательности исторических территориальных единиц, чтобы предотвратить море синего . В случае Тито каждая территориальная единица связана в тексте статьи, поэтому применение MOS:GEOLINK к информационному окну не представляет проблемы. Khiikiat ( talk ) 18:41, 9 октября 2024 (UTC) [ ответить ]
Основной вопрос, как и во всем, что касается ссылок, должен заключаться в том, дает ли ссылка читателю полезную информацию. Одним из соображений, когда дело доходит до нескольких последовательных ссылок, является то, будет ли одна адекватно вести читателей к другой. Например, даже если кто-то не знаком с тем, что такое Альберта и Канада, « Калгари , Альберта, Канада» подойдет, потому что Калгари ссылается на Альберту из своего лида, а тот, в свою очередь, ссылается на Канаду . Однако статья о существующем городе может не ссылаться так явно на страну, частью которой он когда-то был. Формулировка вроде « Кумровец , Австро-Венгрия » разумна, потому что статья о Кумровце не сразу объясняет, чем была Австро-Венгрия (на самом деле, она не упоминает ее ни разу). Но что-то вроде « Сирия Палестина , Римская империя » было бы излишним, поскольку Сирия Палестина существовала только как часть Римской империи. -- Тамзин [ нужен кит ] ( они|xe ) 22:58, 9 октября 2024 (UTC) [ ответить ]
@ Tamzin : Я понимаю вашу точку зрения. Но если важно связывать каждую территориальную единицу, последовательность можно разбить. Вот что было сделано в статье о Тито: Иосип Броз родился 7 мая 1892 года в Кумровце , деревне в северном хорватском регионе Загорье . В то время это была часть Королевства Хорватия-Славония в составе Австро-Венгерской империи . Если единицы связаны в теле, то нет необходимости связывать их и в инфобоксе. Исключение для последовательности исторических территориальных единиц открывает дверь для правок такого рода. Нормантас Батаитис сделал сотни и сотни таких правок. Я не вижу, как они приносят пользу читателю. Инфобокс должен быть кратким изложением основных фактов. Khiikiat ( talk ) 09:31, 10 октября 2024 (UTC) [ ответить ]
Я связываю исторические территориальные единицы только если историческая страна является федеративной. По моему мнению, следует указывать федеральные исторические территориальные единицы, чтобы читатель понимал состав исторических стран. Нормантас Батаитис ( обсуждение ) 11:12, 10 октября 2024 (UTC) [ ответить ]
Согласен, что более разнесенные фразы в прозе часто предпочтительнее, конечно. Но в infoboxen это не вариант, и я не очень верю аргументу SEAOFBLUE там, по крайней мере, когда он разделен знаками препинания. Текст в infoboxen окружен пробелами. Нет никаких эстетических или проблем с пониманием чтения, вызванных наличием двух ссылок, разделенных запятой.
Теперь, что касается различий, Вторая Испанская Республика — это немного более сложный случай, потому что историографически это считается одной итерацией непрерывной Испании . Нечто похожее на самом деле возникло в GAN для Capri-Sun , где Guerillero и я не согласились с тем, как характеризовать Германию в 1931 году ( Германия , итерация в ней называлась Германским Рейхом , или под-итерация в ней называлась Веймарской республикой ). Точный способ описания итераций стран — это то, что было бы хорошо для MoS прояснить, но в контексте этого обсуждения это немного отвлекающий маневр, я думаю. Хотя, как бы там ни было, я не согласен с [[Second Spanish Republic|Spain]]этим различием. Оно должно быть либо четко связано, либо не связано вообще. — Tamzin [ cetacean needed ] ( they|xe ) 18:01, 10 октября 2024 (UTC) [ ответить ]
Я согласен с последним пунктом. Это EGG , и мы предпочитаем избегать их по уважительным причинам. Gawaon ( talk ) 18:34, 10 октября 2024 (UTC) [ ответить ]
Я регулярно отключаю связь по MOS:GEOLINK (и часто перефразирую, чтобы избежать морей синевы), но всегда считал само собой разумеющимся, что GEOLINK не применяется к бывшим странам, которые не могут быть автоматически достигнуты за один клик или около того из связанного топонима, поэтому я не отключаю их. Я также предполагаю, что если есть два связанных топонима подряд, визуальное сходство (несмотря на отсоединенную запятую между ними) с морем синевы является необходимым злом. Я бы поддержал четкое изложение этих моментов в рекомендациях GEOLINK.
UrielAcosta ( обсуждение ) 00:38, 11 октября 2024 (UTC) [ ответить ]
Может быть, подпункт под GEOLINK, гласящий: «Исключение: если наименьшая единица является существующим местом, а наибольшая — нет, то приемлемо связать обе, как в Кумровце , Австро-Венгрия . Однако предпочтительнее разнести ссылки, когда это возможно, например, Кумровец , тогда часть Австро-Венгрии ». — Тамзин [ необходимо китообразных ] ( they|xe ) 05:35, 14 октября 2024 (UTC) [ ответить ]
Возможно, нюанс лучше оставить прозе, которая в настоящее время гласит, что Тито родился у отца-хорвата и матери-словенки в Кумровце , в тогдашней Австро-Венгрии , предоставляя надлежащий контекст в явной формулировке вместо последовательных ссылок. — Bagumba ( обсуждение ) 02:36, 10 октября 2024 (UTC) [ ответить ]
Я согласен с Tamzin. Подпункт нужен для бывших территориальных единиц, но я не уверен, что нужно включать каждую каскадную территориальную субъединицу, например, конкретное королевство Австро-Венгрия или республику Югославия. Peacemaker67 ( нажмите, чтобы поговорить со мной ) 22:11, 31 октября 2024 (UTC) [ ответить ]

RfC: Связывание трехчастных топонимов

Существует два распространенных способа ссылки на название места в формате «A, B, C», где статья озаглавлена ​​[[A, B]]. Оба способа можно считать справедливыми интерпретациями указания «связать только первый блок».

  1. Охватывайте связью только наименьший блок, при необходимости используя трубопровод.
    Буффало , Нью-Йорк, США
  2. Отображаемый текст должен соответствовать названию связанной статьи.
    Буффало, Нью-Йорк , США

Какой(ие) стиль(и) приемлем(ы)? Если оба, какой предпочтительнее другого?

Примечание: см. предыдущее обсуждение выше и выше. Это не вопрос о том, следует ли связывать «Нью-Йорк» с Нью-Йорком (штатом) в этом примере; в основном все согласны, что этого не должно быть. 20:57, 17 октября 2024 (UTC)

Обсуждение по RfC: Связывание трехчастных топонимов

Пинги для прошлых участников @ Gawaon , Khiikiat , Pi.1415926535 , Michael Bednarek , NebY , Biruitorul и Dahn . Переадресовано в WT:MOSACCESS . -- Tamzin [ нужны китовые ] ( they|xe ) 20:57, 17 октября 2024 (UTC) [ ответить ]
  • Оба приемлемы, подход 1 предпочтительнее . Подход 2, без сомнения, более распространен, но оба подхода используются в хороших и избранных статьях без проблем. В отношении MOS:RETAIN я не буду говорить, что подход 2 следует запретить, но я думаю, что подход 1 предпочтительнее по двум причинам:
    • Последовательность : Было бы странно, если бы руководство по прозе включало заголовок статьи, на которую ссылаются, учитывая, что политика заголовка статьи формируется на основе различных соображений, которые не применяются к прозе, таких как устранение неоднозначности и полупроизвольное правило WP :USPLACE . Читателю, который видит " Buffalo, New York , United States" рядом с " Boston , Massachusetts, United States", совсем не очевидно, почему эти два элемента обрабатываются по-разному. Гораздо чище и проще, чтобы ссылка охватывала точное место, на которое ссылаются, а не прикрепляла устранение неоднозначности, например ", New York".
    • Доступность : Единственное различие между « Буффало, Нью-Йорк » и « Буффало , Нью-Йорк » — это цвет запятой. Для тех, кто, как и я, с трудом различает синий и черный в небольших количествах, похоже, что нажатие на «Нью-Йорк» в первом примере перенесет вас в Нью-Йорк (штат) .
  • Главный аргумент, выдвигаемый в противоположном направлении, — это простота разметки, но это обычно самый низкий приоритет в решениях MoS, определенно ниже, чем доступность. Мы не должны делать наши статьи более запутанными для читателей только ради немного более короткого исходного кода. -- Tamzin [ cetacean needed ] ( they|xe ) 20:57, 17 октября 2024 (UTC) [ ответить ]
  • Никакого — я с трудом понимаю, почему не было бы необходимости связывать административное деление первого уровня, в большинстве случаев за пределами США (и даже США, но давайте предположим, что Буффало, Нью-Йорк — общепринятая практика в этом контексте). Кто мог бы считать округ Яломица или регентство Симеулуэ мгновенно узнаваемыми терминами на обширном пространстве мира? и если мы не связываем незнакомые термины, какой смысл вообще иметь внутренние ссылки? Похоже, кого-то раздражало наличие двух ссылок рядом друг с другом, и он придумал этот ужасный мораторий на наличие необходимых ссылок там, где они появляются рядом (хотя и аккуратно разделенные запятой); этот сбивающий с толку подход вообще не следовало бы пробовать , никогда . Dahn ( обсуждение ) 21:10, 17 октября 2024 (UTC) [ ответить ]
    Обычный аргумент против привязки сущности второго уровня заключается в том, что ее можно легко щелкнуть с первого уровня, если кто-то захочет. Как обсуждалось выше, исключения могут применяться, когда статья сущности первого уровня не обсуждает второй уровень в явном виде, в основном в случае бывших стран. -- Tamzin [ cetacean needed ] ( they|xe ) 21:17, 17 октября 2024 (UTC) [ ответить ]
    Исключения на самом деле являются нормой — большинство подразделений будут незнакомы никому за пределами этой страны. Вот почему «Буффало, Нью-Йорк» — это вводящий в заблуждение пример, который побудил некоторых чрезмерно усердных пользователей удалить ссылки на округ Олт и Валахию , что привело к абсурдному предположению, что округ Олт имеет такую ​​же известность, как Нью-Йорк, а Валахия — это понятие, похожее на США. «Его можно легко щелкнуть из [откуда-то еще]» можно сказать о каждой синей ссылке, поэтому я не понимаю, почему это когда-либо принималось в качестве весомого аргумента в каких-либо дебатах. Dahn ( talk ) 21:32, 17 октября 2024 (UTC) [ ответить ]
  • Вариант 2 по MOS:SPECIFICLINK . Это также обычная непереведенная ссылка, без лишнего текста: сравните [[Buffalo, New York]], United States(пять слов) с [[Buffalo, New York|Buffalo]], New York, United States(восемь слов). -- Red rose64 🌹 ( обсуждение ) 22:13, 17 октября 2024 (UTC) [ ответить ]
  • Комментарий — есть много ситуаций, когда уместно связывать место, подразделение и страну, и я думаю, что руководство должно больше поощрять это. Примеры: 1) Богдана , уезд Тутова , Молдавия ; 2) Харакланы , уезд Силадь , Королевство Венгрия . Скорее всего, среднестатистический читатель понятия не имеет, где находится/находилось любое из этих мест, так почему бы не связать их все? — Biruitorul Talk 05:59, 18 октября 2024 (UTC) [ ответить ]
  • Вариант 2 , потому что он короче в написании и приводит к согласованию связанного текста и заголовка связанной страницы. Более позднее дополнение: Также согласно WP:NOPIPE , как указал ниже Bagumba — не используйте ссылки с каналом, когда в этом нет необходимости, а здесь вам совершенно очевидно, что это не нужно. Gawaon ( talk ) 08:55, 18 октября 2024 (UTC), отредактировано 07:55, 19 октября 2024 (UTC)[ отвечать ]
  • Оба варианта приемлемы, не указывайте предпочтения ни для одного из них. Лично я предпочитаю вариант 2, который сокращает избыточный текст, который выглядит крайне глупо в редакторе и в diffs. Я полагаю, что он также сопоставляет текст ссылок с заголовками статей, что меня волнует меньше всего. Я не думаю, что мы должны закреплять здесь предпочтение лучшей практики. Согласен с другими выше, что во многих случаях может быть полезно связать несколько административных подразделений: не так давно у меня была причина упомянуть этнический поселок Яо Маншань (莽山瑶族乡), уезд Ичжан , Чэньчжоу , Хунань . Исключая контейнерный штат, это все еще четыре подразделения. Я оставил Хунань несвязанным, так как он появляется в User:Ohconfucius/script/Common Terms , но, вероятно, есть редакторы, которые будут спорить о связывании и его. Folly Mox ( обсуждение ) 09:52, 18 октября 2024 (UTC) [ ответ ]
  • Ссылайтесь только на наиболее специфичный элемент, особенно когда два других так хорошо известны. Тони (обсуждение) 10:25, 18 октября 2024 (UTC) [ ответить ]
  • Вариант 2. Нет смысла передавать и скрывать «Нью-Йорк», просто набрать его снова и отобразить. Согласно WP:NOPIPE :

    Излишние вертикальные линии затрудняют чтение вики-текста.

    — Багумба ( обсуждение ) 10:54, 18 октября 2024 г. (UTC) [ ответ ]
  • Вариант 2 не находит никаких конкретных причин исключать штат из муниципалитета, так как это как бы само собой разумеется. Также создает избыточные трубы по Багумбе . Takipoint123 ( обсуждение ) 02:20, 19 октября 2024 (UTC) [ ответить ]
  • Вариант 2 В этом конкретном формате кажется более интуитивным соответствовать названию статьи. Я также добавлю, что включение несвязанной страны в конце может быть несколько неуместным/излишним в любом варианте. Symphony Regalia ( talk ) 14:38, 19 октября 2024 (UTC) [ ответить ]
  • Никаких предпочтений. MOS должен это указать. Я полностью согласен с Folly Mox в этом и пошел бы еще дальше, сказав, что руководство по стилю должно быть четко указано, что нет никаких предписанных предпочтений. Оно должно перечислять некоторые вещи, которые следует учитывать, приводить примеры и в остальном полагаться на редакционное суждение. К вещам, которые следует учитывать, могут относиться MOS:NOPIPE и другие правила или руководства. Многое из этого будет зависеть от контекстно-зависимых факторов и личного суждения или консенсуса в статье. Почти во всех случаях слишком мало значит, чтобы предписывать единый стандарт, и это, скорее всего, приведет к большему количеству апелляций об исключениях и обходных путях. MYCETEAE 🍄‍🟫 — talk 22:03, 19 октября 2024 (UTC) [ ответить ]
  • Вариант 1 , но оба приемлемы, согласно Tamzin и интуитивности ссылок . Я не хочу, чтобы люди нажимали «Нью-Йорк» и сбивались с толку, отправляясь в Буффало. Я также считаю, что все аргументы, основанные на том, что лучше выглядит в викитексте или что легче набирать редактору, неверны. Решения о стиле не принимаются в пользу редактора викитекста. —  HTGS  ( обсуждение ) 00:50, 23 октября 2024 (UTC) [ ответить ]
    Я не хочу, чтобы люди нажимали «Нью-Йорк» и путались, что их отправляют в Буффало : Но именно поэтому мы избегаем последовательных ссылок, т. е. SOB. Это одна ссылка на <город, штат>, а не последовательные ссылки <город>, <штат>. — Bagumba ( обсуждение ) 04:37, 24 октября 2024 (UTC) [ ответить ]
    И отказ от ссылок, охватывающих темы на двух уровнях страницы, — это еще один шаг, который мы можем предпринять для того, чтобы сделать ссылки более понятными. —  HTGS  ( обсуждение ) 02:06, 25 октября 2024 (UTC) [ ответ ]
    Правильно. У читателей нет причин ожидать, что «Нью-Йорк» не будет ссылаться на Нью-Йорк там: они не знают, что MoS говорит, что этого не должно быть, и на практике бесчисленное множество статей ссылались бы на Нью-Йорк там. Используя другой штат, поскольку неоднозначность NYC/NYS усложняет ситуацию, есть 11 030 статей, содержащих либо , [[Boston]], [[Massachusetts]]либо [[<someplace>, Massachusetts|<someplace>]], [[Massachusetts]]. Эти ссылки отличаются от , например, [[Boston, Massachusetts]]цветом символа, ширина которого меньше миллиметра при стандартном увеличении. -- Tamzin [ cetacean needed ] ( they|xe ) 00:20, 27 октября 2024 (UTC) [ ответить ]
    Независимо от результата этого RfC, автономная ссылка на Массачусетс должна быть отключена согласно MOS:GEOLINK во всех этих случаях. MOS:GEOLINK уже очень ясно выразился по этому поводу, и это не то, что изменится. Gawaon ( talk ) 08:39, 27 октября 2024 (UTC) [ ответить ]
  • Одинарная ссылка Почти в каждом случае цель ссылки — перенаправить вас к статье об одном, однозначном местоположении. Ссылка должна быть написана в ее естественном формате (без кавычек). Более крупные регионы нужны просто для того, чтобы печатная форма привела вас в то же место, но мы на самом деле не ожидаем, что читатель захочет перейти непосредственно к статьям для более крупных регионов — т. е. мы перечисляем город по какой-то причине, более крупные регионы нужны только для того, чтобы сделать его однозначным и не являются целью сами по себе. Поэтому мы даем ссылку на город в его естественном формате (без кавычек), а затем добавляем все необходимое в виде обычного текста. Если окажется, что некоторые города в списке имеют ссылку, охватывающую разные части иерархии (например, Париж , Франция против Парижа, Онтарио , Канада), то это нормально.  Stepho   talk  01:21, 23 октября 2024 (UTC) [ ответить ]
    Ох, я действительно не согласен с последним пунктом. Я бы предпочел, чтобы список был последовательным, независимо от выбора между этими двумя вариантами. —  HTGS  ( talk ) 03:01, 23 октября 2024 (UTC) [ ответить ]
    Как бы вы перечислили эти 2 города?  Stepho   talk  03:10, 23 октября 2024 (UTC) [ ответить ]
    Если предположить, что это обычное прозаическое предложение, то у меня было бы что-то вроде: «Однако в 1894 году правительство Парижа , Франция, решило осуществить изменение, в то время как мэр Парижа , Онтарио, заставил город воздержаться…». Но, честно говоря, я бы все же предпочел противоположное ( … Париж, Франция решил осуществить изменение, в то время как мэр Парижа, Онтарио, не сделал… ) предложенному вами раздельному стилю. —  HTGS  ( обсуждение ) 21:40, 24 октября 2024 (UTC) [ ответить ]
    И для большинства списков то же самое (за исключением страниц с неоднозначностями). —  HTGS  ( обсуждение ) 21:42, 24 октября 2024 (UTC) [ ответить ]
    Согласен, но учтите, что то, что вы описываете, на самом деле является вариантом 2 («Отображаемый текст должен соответствовать названию связанной статьи»), поэтому вы фактически голосуете за него. Gawaon ( talk ) 07:23, 23 октября 2024 (UTC) [ ответить ]
    более крупные регионы нужны только для того, чтобы сделать его однозначным и не являются целью сами по себе : я не уверен, что «однозначный» — правильное слово. Для большой страны большинство людей никогда не слышали о большинстве некрупных городов, поэтому более крупный регион упоминается для предоставления контекста, существует ли такое же название города в другом регионе.— Багумба ( обсуждение ) 04:48, 24 октября 2024 (UTC) [ ответить ]
  • Определенно, вариант 2. Никакой гимнастики с трубой не требуется, а синий цвет, который видит читатель, недвусмысленно говорит ему, куда приведет его нажатие. E Eng 00:33, 27 октября 2024 (UTC) [ ответить ]
  • Ссылка "Buffalo" отдельно. Тони (обс.) 02:25, 1 ноября 2024 (UTC) [ ответить ]
    Как в Буффало , Нью-Йорк, США ? -- Майкл Беднарек ( обсуждение ) 03:01, 1 ноября 2024 (UTC) [ ответить ]
  • Комментарий: Привет, ребята. Я пришел сюда, чтобы поднять тесно связанный вопрос, а затем увидел это обсуждение и предыдущие. Я думаю, что примеры следует изменить, чтобы разрешить или поощрить подобные вещи:

Три очень красивых города:

То есть, во многих случаях предпочтительнее быть последовательным в том, как представлены ссылки, и, на мой взгляд, *не* обязательно, чтобы видимый связанный текст точно соответствовал заголовкам статей. Поэтому в этом примере я закодировал, [[Chicago|Chicago, Illinois]]чтобы добиться этого. Хотя кодирование [[Chicago, Illinois]]достигло бы более или менее того же самого, потому что "Chicago, Illinois" — это перенаправление на "Chicago". Отредактировано, чтобы добавить: Это предложение не соответствует ни варианту 1, ни варианту 2. — Mudwater ( Talk ) 01:55, 26 ноября 2024 (UTC) [ ответить ]
  • По крайней мере, исправьте описание того, что рекомендуется : для меня неверно говорить «Оба можно считать справедливыми интерпретациями руководства «связать только первую единицу». В строке «Буффало, Нью-Йорк, США» явно есть три единицы, и первая из этих трех единиц — «Буффало». Если мы собираемся сказать, что «Буффало , Нью-Йорк , США» ( [[Buffalo, New York]], United States) является предпочтительным форматом, нам нужна другая характеристика, чем если бы мы говорили, что для «последовательности из двух или более территориальных единиц связать только первую единицу». Например, мы могли бы сказать «связать только ту часть имени, которая используется в соответствующем названии статьи» или «связать только начальные части имени, которые образуют его традиционную идентификацию». (Нам также может потребоваться отослать читателя к MOS:USPLACE для традиционной формы описаний местоположений в США). —⁠ ⁠ BarrelProof ( talk ) 01:06, 3 января 2025 (UTC) [ reply ]
  • Комментарий: В большинстве случаев никто никогда не будет ссылаться на «Terre Haute», как предлагалось выше, только потому, что субъект родился там. Кого это волнует? (Если только этот город не оказал существенного влияния на известность субъекта.) Очень часто мы сталкиваемся с логикой не ссылаться из-за недостаточной релевантности или потому, что местоположение известно на международном уровне: меньшая и наименее значимая «деревня» («Terre Haute») против слишком известного большего местоположения («Чикаго»). В этом случае, кажется, ничего не нужно ссылать. Другой пример: «пригород Лондона, Лондон, Великобритания» — не ссылайтесь ни на что, если только пригород не имеет достаточного значения для субъекта (маловероятно).
Есть случаи , которые можно было бы связать логически. Допустим, годы становления личности прошли в деревне рождения: Адаладж , Гуджарат, Индия. Здесь статья об Адаладже будет разумно содержать ссылку на Гуджарат, если читатель действительно хочет узнать больше о штате. Помните, что один из 10 000 читателей, который действительно хочет узнать больше, на месте, может потратить 10 секунд на ввод цели в поле поиска. В противном случае мы имеем системную группировку, которую MOSLINK не зря не одобряет. Тони (обсуждение) 23:42, 17 января 2025 (UTC) [ ответить ]

ЯвляетсяМОС:СОБпросто проблема со стилями?

В настоящее время на странице есть MOS:SEAOFBLUE , который, в частности, гласит:

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

Что, по-моему, имеет смысл. Но разве это просто проблема таблицы стилей в Википедии? Гиперссылки HTML традиционно отображаются синим цветом и подчеркиваются, что позволяет отличить шахматный турнир от шахматного  турнира (в Википедии они, кажется, подчеркиваются только при наведении, по какой-то причине), что в значительной степени решило бы проблему. Или решило бы? Dingolover6969 ( обсуждение ) 11:20, 19 октября 2024 (UTC) [ ответить ]

Разницу все еще очень трудно обнаружить, поэтому я бы сказал, что это определенно не просто проблема таблицы стилей. Gawaon ( talk ) 11:33, 19 октября 2024 (UTC) [ ответить ]
Наведение курсора не является опцией на мобильных устройствах. Но уже есть проблема навигации, даже если они не являются ссылками «назад-назад». Согласно MOS:OVERLINK :

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

Это только хуже, когда это SOB.— Багумба ( обсуждение ) 11:57, 19 октября 2024 (UTC) [ ответить ]
Хотя большинство браузеров подчеркивают кликабельные ссылки при отсутствии каких-либо инструкций об обратном, многие веб-сайты в настоящее время предоставляют такие инструкции - например, https://www.legislation.gov.uk/, где ссылки синие и подчеркиваются только при наведении курсора. Наш скин Cologne Blue по-прежнему подчеркивает ссылки. -- Red rose64 🌹 ( talk ) 14:34, 19 октября 2024 (UTC) [ ответить ]
Несколько ортогонально, но я думаю, что « шахматный турнир » — плохой пример, поскольку это проблема, в первую очередь, из-за использования двух ссылок вместо более подходящей: « шахматный турнир ». И помимо этого, большинство проблем SOB, как правило, больше связаны с избыточным связыванием, чем с самим SOB. Когда есть SOB, и все ссылки подходят, возможность переписывания часто игнорируется, а иногда даже возвращается. —  HTGS  ( обсуждение ) 21:54, 24 октября 2024 (UTC) [ ответить ]
возможность переписывания часто игнорируется, а иногда даже возвращается к прежнему варианту : по-видимому, непременно кто-то будет гордиться компактной формулировкой — в противовес MOS:SOB Вместо этого рассмотрите возможность перефразирования предложения ( шахматный турнир )... — и будет утверждать, что любые дополнительные слова «не нужны». — Багумба ( обсуждение ) 09:22, 1 ноября 2024 (UTC) [ ответить ]

Примечательные исключения из SOB

Я заметил, что соображения MOS:LEADSENTENCE обычно перевешивают описанные здесь, и думаю, было бы полезно указать на это следующим образом:

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

«Оппенгеймер» —эпический биографический драматический фильм, написанный, срежиссированный и спродюсированныйКристофером Ноланом.

Orchastrattor ( обсуждение ) 18:24, 23 октября 2024 (UTC) [ ответить ]

Это не исключения, это одни из самых вопиющих и самых заметных нарушений. Они особенно неправильны, даже больше, чем примеры, приведенные в самой политике. Remsense  ‥ 论18:27, 23 октября 2024 (UTC) [ ответить ]
Если уж на то пошло, то это вдвойне неверно, потому что ссылки не сильно помогают читателям в понимании, а список жанров — не самое главное в фильме, так что это также нарушает MOS:FIRST . По моему мнению, в предложении lede для фильма должно упоминаться от нуля до одного жанра. — Тамзин [ необходимы китовые ] ( they|xe ) 00:34, 24 октября 2024 (UTC) [ ответить ]
Какое ужасное вступительное предложение... Море синего Мокси 🍁 00:55, 24 октября 2024 (UTC) [ ответить ]
Вы бы сказали, что вы стали Смертью, Разрушителем Миров, или? Remsense  ‥ 论01:00, 24 октября 2024 (UTC) [ ответить ]
Лол ....будь проще [3] Moxy 🍁 01:08, 24 октября 2024 (UTC) [ ответить ]
Да, конкретно есть MOS:LEADCLUTTER :

Не перегружайте первое предложение описанием всего примечательного в теме. Вместо этого распределите соответствующую информацию по всему лиду.

— Багумба ( обсуждение ) 14:44, 25 октября 2024 г. (UTC) [ ответ ]
Действительно, между этими двумя принципами часто возникает противоречие.
Мне интересно, являются ли реакции, приведенные выше, локальным консенсусом . Orchastrattor прав, что тонны вводных предложений статей о фильмах и других вводных предложений написаны таким образом. И у меня сложилось впечатление, что люди, которые посещают эту страницу обсуждения, больше заботятся о нарушениях SOB, в то время как многие другие редакторы более склонны игнорировать их, если это помогает предоставлять полезные ссылки.
Я не согласен с @Tamzin , что жанры не важны — они определяют аспекты фильма, о чем свидетельствует тот факт, что у нас есть категории для них. Предложение, подобное приведенному выше, не дает хороших вариантов — SOB не является оптимальным, но решение этой проблемы путем удаления ссылок уберет полезную информацию, и любое переписывание, чтобы избежать их, будет крайне неуклюжим. Я думаю, можно привести веские доводы в пользу того, что SOB — меньшее зло в этой ситуации. Sdkb  talk 02:57, 24 октября 2024 (UTC) [ ответить ]
В точку! Я никогда не люблю наваливаться как таковой: у меня есть твердые мнения, но они звучат как неприятно сильные, когда их оспаривают другие, которые думают так же. Remsense  ‥ 论04:06, 24 октября 2024 (UTC) [ ответить ]
Наши лучшие статьи о поп-культуре справились бы с этим морем синего списка жанров, переместив их в инфобокс с маркерами, чтобы сделать каждую ссылку понятной Pink Floyd , House (сериал) .... Шаблон:Infobox film — это странность для этого, которая приводит к этой проблеме, поскольку он пропускает жанры. Не все проекты имеют в виду доступность. Moxy 🍁 04:31, 24 октября 2024 (UTC) [ ответить ]
Много вещей определяющих и важных, но не идут в предложение lede. Это просто плохое письмо. Сравнить

Oppenheimer — биографический фильм 2023 года , написанный, срежиссированный и спродюсированный Кристофером Ноланом . Эпическая история с элементами триллера , повествующая о жизни Дж. Роберта Оппенгеймера , американского физика-теоретика , который помог разработать первое ядерное оружие во время Второй мировой войны .

Если бы в статье было больше информации о структуре фильма (которой нет, потому что, как и в большинстве статей о фильмах, она перегружена информацией о производстве и кассовых сборах), эпический/триллерный отрывок можно было бы переместить туда вместо второго предложения. Драматический фильм не нуждается в ссылке, потому что все три других жанра являются его поджанрами. Обратите внимание также, что ссылки SOB здесь скрывают проблемы с источниками: в тексте статьи цитируются только люди, сравнивающие его с триллером, а слово «эпический» появляется только в заголовках источников. Первое рассматривается в моем предложенном выше переписывании; второе потребует внесения изменений в текст, чтобы исправить. -- Tamzin [ cetacean needed ] ( they|xe ) 15:31, 24 октября 2024 (UTC) [ ответить ]
Мне на самом деле очень нравится эта переделка! Я не уверен, что она подойдет для всех подобных ситуаций, но в этой она отлично решает проблему, так что я согласен с поправкой. Sdkb  talk 15:42, 24 октября 2024 (UTC) [ ответить ]
Хотя я и считаю, что жанры, как правило, важны и должны упоминаться как можно раньше, нет необходимости нагромождать их в самом первом предложении, и WP:DEFINING (о категориях) не следует понимать как указание на то, как должно выглядеть первое предложение. —  HTGS  ( обсуждение ) 21:46, 24 октября 2024 (UTC) [ ответить ]

Случай с Оппенгеймером просто оскорбителен, так как ни один надежный источник никогда не называл фильм «эпическим биографическим триллером-драмой», не говоря уже об общем, и противоречит WP:FILMLEAD . Я его разнес. Эрик  ( обсуждение  |  вклад ) ( пинг мне ) 13:48, 25 октября 2024 (UTC) [ ответить ]

Не совсем фанат «эпоса с аспектами триллера » , переписать. «аспекты триллера» расплывчаты. Какие аспекты? это триллер или нет? Если что, этот подробный подход больше сбивает читателей с толку, чем помогает им, и нам нужно что-то прояснить, и десять разных людей вернутся с десятью разными интерпретациями. Определенно с Эриком в этом. Даже если мы найдем группу источников, применяющих жанры, предположение о любом гибриде формы, который не следует нашим стандартам жанра, вводит в заблуждение. Если жанр действительно является важным аспектом или чем-то таким сложным, это нужно будет прояснить в прозе. Что-то вроде The_Lighthouse_(2019_film)#Genre . Тем не менее, я обычно пропускаю жанры, которые уже объясняются общей структурой сюжета. Если в первом предложении говорится, что речь идет о реальной фигуре Дж. Роберте Оппенгеймере, то мы уже знаем, что это будет биографический фильм. Andrzejbanas ( обсуждение ) 13:54, 4 ноября 2024 (UTC) [ ответить ]
Я почти уверен, что я полусерьезно предположил, что нам лучше всего будет полностью убрать жанры из лида и позволить читателям делать собственные выводы на основе краткого содержания сюжета и всего, что было предоставлено в разделе «Прием». DonIago ( обсуждение ) 13:57, 7 ноября 2024 (UTC) [ ответить ]
Хотя я бы согласился с этим как с рефлекторным ответом «да», так часто у нас есть жанры, даже в хороших и художественных статьях, которые даже не упоминаются ни в одной прозе внутри статей. Хотя я не в MOS, и никто, похоже, не хочет это обсуждать, я обычно либо сохранял жанр в целом, либо пытался применять стандарты WP:WEIGHT . В отличие от более технических кредитов, которые можно легче решить, жанр настолько текучий и изменчивый, что требует особого намерения, и игнорировать его из-за его сложности в открытой энциклопедии также немного больше работы, чем большинство людей хотят иметь дело. Andrzejbanas ( talk ) 20:58, 8 ноября 2024 (UTC) [ ответить ]
Я бы не согласился с тем, чтобы оставить читателям угадывать жанр. Иногда краткое содержание сюжета не способно указать жанр, особенно для смежных жанров. Например, детективная фантастика#Классификации неполны (теперь существуют десятки поджанров, а также пересекающиеся комбинации, например, леди-детектив исторический романтический загадка запертой комнаты), но просто угадать между этими немногими не всегда возможно из краткого содержания сюжета. Кроме того, нет гарантии, что данный читатель вообще будет знать о существовании определенного жанра. WhatamIdoing ( talk ) 21:21, 30 ноября 2024 (UTC) [ ответить ]
Честно говоря, я думаю, что полусерьёзное предложение Дониаго хорошее.
[Удалено: пять абзацев философских рассуждений о назначении и полезности родов, а также об описании и субъективности художественных характеристик]
Конкретно я считаю, что жанр может быть ценным дополнением к инфобоксу, но не имеет места в первом абзаце, за исключением случаев, когда сам жанр вносит вклад в значимость темы согласно MOS:LEAD . Folly Mox ( обсуждение ) 15:48, 9 ноября 2024 (UTC) [ ответить ]
Я бы этого не поддержал. Жанры — это важные части информации, и они не более субъективны, чем некоторые другие вещи, которые мы обычно включаем в лид. Sdkb  talk 16:01, 9 ноября 2024 (UTC) [ ответить ]
Учитывая, сколько раз мне приходилось запрашивать источники для добросовестных, но неподтвержденных изменений жанра, я не думаю, что согласен с тем, что жанр относительно бесспорен, но я не знаю, о каких «некоторых других вещах» вы говорите. DonIago ( обсуждение ) 16:07, 9 ноября 2024 (UTC) [ ответ ]
Я сказал «субъективный», а не «неоспоримый» — безусловно, есть много спорных вещей, которые мы постоянно включаем в лиды, и было бы против WP:NEUTRAL не включать их. Что касается примеров субъективной информации в лидах, WP:REPUTATION — один из примеров, который приходит на ум. Sdkb  talk 19:07, 9 ноября 2024 (UTC) [ ответить ]

Редактор отменяет мою отвязку простых лет

Два возврата от User:LightNightLights : что делать? Тони (обс.) 00:50, 30 октября 2024 (UTC) [ ответить ]

Забавно, похоже, я тот, кто их добавил, но больше не имею этой статьи в списке наблюдения, поэтому не видел этого спора, пока вы не разместили здесь. Неудивительно, что я согласен с LightNightLights. Годы связаны в примечаниях, которые являются навигационными средствами, а не частью прозаического содержания статьи. Было бы совершенно бессмысленно говорить «не путать с 1776» и не ссылаться на 1776. -- Tamzin [ cetacean needed ] ( they|xe ) 04:16, 30 октября 2024 (UTC) [ ответить ]

См. обсуждение на этой странице обсуждения для получения дополнительной информации. Редактор удалил ссылки на WS Gilbert, ссылаясь на MOS:REPEATLINK , однако это неверно по MOS, так как это первое появление этих ссылок в его разделе, а MOS:REPEATLINK указывает на необходимость ссылаться на термин не более одного раза на основной раздел, при первом появлении , описывая основной раздел как заголовок уровня 2. Happily888 ( обсуждение ) 06:49, 30 октября 2024 (UTC) [ ответить ]

Делайте то, что лучше всего подходит читателям... если это огромная статья с несколькими разделами, нет ничего плохого в том, чтобы дать на нее несколько ссылок, чтобы облегчить навигацию, особенно для тех, кто не читает статьи целиком, а просто переходит к определенным разделам через оглавление. Moxy 🍁 02:29, 10 ноября 2024 (UTC) [ ответить ]
Зависит от того, насколько бесполезна ссылка изначально. Тони (обсуждение) 08:50, 10 ноября 2024 (UTC) [ ответить ]
Похоже, эта проблема решена.
Для сравнения, большинство «длинных» статей (т. е. 50% статей, которые имеют более чем текущее медианное значение Википедии в 13 предложений на статью) имеют примерно одну ссылку на каждые 20 слов или около четырех ссылок на каждые пять предложений. Ссылки не распределены случайным образом по всей статье (например, их больше в начале), но если вы думаете, что существует Wrong™ количество ссылок, может быть полезно сравнить ваши личные догадки со средними числами. (Более короткие статьи имеют более высокую плотность ссылок, около двух ссылок на предложение.) WhatamIdoing ( talk ) 21:30, 30 ноября 2024 (UTC) [ ответить ]

Обновление дляMOS:ДАТАССЫЛКА?

В дополнение к годам и датам, испанские правила Википедии (не уверен, как ссылаться на них отсюда, но там они есть как WP:ENLACESFECHAS) упоминают, что не следует связывать другие единицы времени – например, столетия и месяцы. Мне это кажется здравым смыслом. 1980fast ( talk ) 23:48, 28 декабря 2024 (UTC) [ reply ]

Как этоMOS:SEAOFBLUEотносятся к фразе типа "футбол квотербек"?

См. обсуждение здесь . ~WikiOriginal-9~ ( обсуждение ) 17:20, 2 января 2025 (UTC) [ ответить ]

"MOS:ВИНГСЬЮТ" перечислены наПеренаправления для обсуждения

Перенаправление MOS:WINGSUIT было указано в перенаправлениях для обсуждения , чтобы определить, соответствует ли его использование и функционирование правилам перенаправления . Читатели этой страницы могут комментировать это перенаправление в Wikipedia:Redirects for discussion/Log/2025 January 3 § MOS:WINGSUIT до тех пор, пока не будет достигнут консенсус. — Bagumba ( обсуждение ) 05:44, 3 января 2025 (UTC) [ ответить ]

Место рождения и т.п. в информационном поле могут ли быть связаны друг с другом?

Перемещено из WT:MOSBIO

Может быть, я совершенно не замечаю, но мне никогда не приходило в голову, что связывание Лондона или Нью-Йорка в инфобоксе Дэвида Боуи можно считать избыточным связыванием. Для меня это ситуация, когда причины, по которым избыточное связывание, как правило, плохо, не применимы. Это явно статьи, которые читатель хотел бы прочитать, вероятно, они имеют особое значение для предмета биографии. Однако по этому конкретному вопросу я пока не нашел никаких существенных обсуждений или словесных рассуждений (еще раз извиняюсь, если не замечаю). Просто кажется слишком догматичным убирать любой MOS:GEOLINK из инфобокса, поскольку это место является достаточно общим знанием — инфобокс отчасти предназначен для того, чтобы быть пространством для этой параметризованной информации. Remsense  ‥ 论03:43, 13 января 2025 (UTC) [ ответить ]

Просто нет необходимости ссылаться на такие вездесущие и общепонятные места, как Лондон и Нью-Йорк. ‑‑ Neveselbert ( обсуждение  · вклад  · электронная почта ) 20:44, 15 января 2025 (UTC) [ ответить ]
Я никогда не видел консенсуса, что MOS:OL применяется к инфобоксам или чему-либо, кроме прозы. Я знаю, что вы придерживаетесь такого мнения, Невесельберт, но в последний раз, когда мы обсуждали это , я обнаружил, что в большинстве FA для людей, которые родились или умерли в Нью-Йорке, либо была ссылка в инфобоксе, либо была ссылкой, пока вы ее не удалили, что говорит о том, что это вопрос редакционных предпочтений, а не чего-то, на что распространяется какой-либо глобальный консенсус. (Статья, с которой мы там не соглашались, позже прошла GAN без возражений против ссылки, FWIW.) Я бы поддержал добавление уточняющей формулировки в MOS:OL, чтобы решить эту проблему раз и навсегда. Это было бы просто, как добавление «в прозе» после основных примеров следующих категорий, которые, как правило, не должны быть связаны . Это не потребовало бы от людей ссылаться на Нью-Йорк в инфобоксах, но оставило бы это на усмотрение редакционных предпочтений, защищенных MOS:RETAIN , как и должно быть. -- Тамзин [ нужен кит ] ( они|xe|🤷 ) 22:31, 15 января 2025 (UTC) [ ответить ]
Хотя я полностью согласен с WP:OL , должно быть определенное место, где ссылка на Лондон приемлема. Должны ли быть связаны все профессии и инструменты Дэвида Боуи? – notwally ( talk ) 23:09, 15 января 2025 (UTC) [ ответить ]
Я тоже полностью согласен с WP:OL, но я также вижу пользу от ссылки даже на мегаполис в инфобоксе. Однако предложенная фраза «в прозе» проблематична, так как она допускает ссылки в таблицах, подписях и т. п. Я предлагаю смягчить WP:OL для «в инфобоксах». -- Майкл Беднарек ( обсуждение ) 00:17, 16 января 2025 (UTC) [ ответить ]
Только что заметил, на какой странице мы находимся. Стоит ли перенести это на WT:MOSLINK ? -- Tamzin [ нужны китовые ] ( they|xe|🤷 ) 00:42, 16 января 2025 (UTC) [ ответить ]
Меня устраивает то, что я считаю лучшим. Remsense  ‥ 论00:16, 17 января 2025 (UTC) [ ответить ]
Перемещено. -- Тамзин [ нужен кит ] ( они|xe|🤷 ) 04:23, 17 января 2025 (UTC) [ ответить ]
Инфобоксы очень заметны и подвержены множеству редакторов, которые не знают о MOS и будут постоянно «исправлять» и предоставлять недостающую ссылку. Я думаю, что было бы прагматично сделать исключение для мест рождения и смерти в инфобоксах, разрешив ссылку и положив конец бесконечному обороту. — Bagumba ( talk ) 09:23, 17 января 2025 (UTC) [ ответить ]
Следуя этой логике, вы могли бы также сделать исключение, разрешив ссылки на даты рождения и смерти. ‑‑ Neveselbert ( обсуждение  · вклад  · электронная почта ) 21:53, 17 января 2025 (UTC) [ ответить ]
Я вижу, как многие редакторы добавляют викиссылки к местам в инфобоксах. Я не знаю, видел ли я когда-либо, чтобы кто-то добавлял викиссылку к дате рождения или смерти в инфобоксе. Я уверен, что это происходит, но я не думаю, что где-либо можно было бы сравнить это с примером Багумбы. – notwally ( talk ) 22:21, 17 января 2025 (UTC) [ ответить ]
Я это видел, в том числе и недавно, когда кто-то пытался связать 29 декабря 2024 года (возраст 100 лет) со смертью и государственными похоронами Джимми Картера . ‑‑ Neveselbert ( обсуждение · вклад · электронная почта ) 22:49, 17 января 2025 (UTC) [ ответить ](2024-12-29)   
Как я уже сказал, я уверен, что это происходит, но я не думаю, что где-то это можно сравнить с примером Багумбы. – notwally ( talk ) 22:55, 17 января 2025 (UTC) [ ответить ]
Я думаю, что привязка даты смерти Джимми Картера в инфобоксе к статье о его смерти и государственных похоронах полезна, лаконична и легитимна. Я не видел простой привязки даты в инфобоксах уже много лет, и я предполагаю, что « По этой логике, … » — это соломенное чучело. -- Майкл Беднарек ( обсуждение ) 01:54, 18 января 2025 (UTC) [ ответить ]
Я просто наблюдаю, что может стать скользкой дорожкой. Ссылки на даты инфобокса подрывают дух WP:EASTEREGG . ‑‑ Neveselbert ( обсуждение  · вклад  · электронная почта ) 22:48, 21 января 2025 (UTC) [ ответить ]
Я не знаю, является ли привязка дат в информационных окнах широко распространенной проблемой (или нет?) — Bagumba ( обсуждение ) 02:16, 18 января 2025 (UTC) [ ответить ]
Насколько мне известно, OL не применяется к инфобоксам и другим шаблонам. Ли Виленски ( обсуждение • вклад ) 23:17, 17 января 2025 (UTC) [ ответить ]
Я думаю, что это определенно применимо, но есть различия, такие как в MOS:REPEATLINK . – notwally ( обсуждение ) 23:33, 17 января 2025 (UTC) [ ответить ]
  • Я думаю, что это избыточная ссылка. И хотя я не знаю - вероятно, редко попадание. За счет увеличения моря синего. Серьезно, кто-то думает, что читатель, видя, что он родился в Лондоне, скажет .. о, я должен нажать на это, чтобы узнать больше о том, что такое Лондон! 2603:7000:2101:AA00:7962:D7BF:E7BB:426E ( обсуждение ) 06:16, 18 января 2025 (UTC) [ ответ ]
    Повторяя акцент, сделанный в моем первоначальном посте — ну, да. Я думаю, что контекст того, где кто-то родился, очень часто представляет центральный интерес для его биографии, аналогично тому, как Пространство и Время связаны во Вселенной, несмотря на то, что (более или менее) появляются как общие термины, используемые там обычным образом. Ссылки предназначены для помощи в навигации, а не просто для помощи в навигации по незнакомым терминам — мы не связываем подавляющее большинство общих терминов, потому что читатель вряд ли захочет перейти к статье B, основываясь на том, о чем статья A, поскольку он уже понимает, в каком смысле B уместна. Место рождения — это ситуация, когда это не следует воспринимать как данность, ИМХО. Remsense  ‥ 论06:17, 18 января 2025 (UTC) [ ответить ]
    Однако Пространство и Время связаны со Вселенной , поэтому можно понять сделанное там исключение, в отличие от подавляющего большинства биографий, которые почти наверняка не связаны с Лондоном , например. ‑‑ Neveselbert ( обсуждение  · вклад  · электронная почта ) 22:40, 21 января 2025 (UTC) [ ответить ]
  • Я имею в виду, что руководство по ссылкам призвано помочь предотвратить море синего, верно? Я не понимаю, как можно сделать море синего в информационном поле. Вопрос о том, должна ли отдельная статья иметь ссылку, мне кажется, скорее является вопросом редакционного суждения, чем всеобъемлющей проблемой стиля. Я также согласен с Remsense, что эти ссылки часто могут быть полезны в биографиях и помогут читателям в их понимании. Кроме того, многие люди используют откат и другие инструменты против вандализма для редакторов, которые делают ссылки, и я видел, как администраторы запрещали новым пользователям делать это после одного или двух предупреждений. Мне бы очень не понравилась идея, что нового пользователя заблокируют, скажем, за добавление ссылки на провинцию Нигерии в информационном поле, поэтому я бы предпочел не расширять политику ссылок, чтобы включить это. GreenLipstickLesbian ( обсуждение ) 06:33, 18 января 2025 (UTC) [ ответ ]
    Я видел, как администраторы не давали новым пользователям знать об этом после одного или двух предупреждений : звучит как крайность для новичка из-за руководства (даже не политики). Рассмотрите возможность обзора Wikipedia:Administrator в будущем. — Bagumba ( обсуждение ) 06:45, 18 января 2025 (UTC) [ ответить ]
  • Лондон , Нью-Йорк и даты/годы в инфобоксах — это глупо. Они не должны быть связаны. Тони (обсуждение) 09:47, 20 января 2025 (UTC) [ ответить ]

"урожденная"

Мысли о связывании "née"? Есть 100 000 статей WP, использующих это слово. Я понимаю, что правила гласят, что "Если термин не имеет особого отношения к контексту статьи, слова и термины, понятные большинству читателей в контексте, обычно не связаны". И это не в том случае, когда я вижу его особенно важным для контекста статьи. Редактор и я, по общему признанию, имеем субъективные расходящиеся соответствующие мнения относительно того, следует ли его связывать. Ищу другие мнения. Спасибо. 2603:7000:2101:AA00:7962:D7BF:E7BB:426E ( обсуждение ) 06:22, 18 января 2025 (UTC) [ ответ ]

Это достаточно пограничный случай, чтобы не умереть на холме, имхо, т.е. достаточно много людей не будут знакомы с ним, поэтому стоит ссылаться. Remsense  ‥ 论06:27, 18 января 2025 (UTC) [ ответить ]
MOS:NEE советует связывать первое появление. — Bagumba ( обсуждение ) 06:54, 18 января 2025 (UTC) [ ответить ]
I would like to point out that we have Template:Nee for this exact reason, not everyone knows what it means. The OP has claimed it is a violation of WP:OVERLINK ("needless blue linking") as their only argument why it can't be used here, but has ignored several requests from me to clarify what part of OVERLINK they are citing. I have tried not to be BITEY, but there is no logical reason why the only instance of nee being used in this BLP article can't be linked for any readers that might not know the term. - Adolphus79 (talk) 07:21, 18 January 2025 (UTC)[reply]
Thanks Remsense and Bagumba -- I was hoping for a consensus view (which you have provided) .. and thanks to Bagumba for finding and sharing the MOS reference that had not been introduced previously into the discussion. And thanks for your civil discourse - my colleague who had a different view than mine (which Bagumba's find supports, and which I of course will respect) seems upset with me having expressed my fiew. 2603:7000:2101:AA00:C041:3E65:B966:1BAE (talk) 17:28, 19 January 2025 (UTC)[reply]
This isn't the forum for a WP:CONDUCTDISPUTE. —Bagumba (talk) 19:12, 19 January 2025 (UTC)[reply]
And it is blatantly not true, none of my comments came even close to being construed as "upset with the IP for having expressed their [v]iew". This thread was nothing more than an attempt at canvassing support for their opinion instead of P&G/MOS. They failed to intimidate me on my talk page, and WP:OTHERPARENT'd here. - Adolphus79 (talk) 22:57, 19 January 2025 (UTC)[reply]
It's an ordinary word in English. Don't link it: in context anyone with an IQ above 30 can see what it means. People with IQs below 30 should type it into the search box. Tony (talk) 09:45, 20 January 2025 (UTC)[reply]
So, you don't agree with MOS:NEE, or just purposely wanted to be insulting? - Adolphus79 (talk) 03:22, 21 January 2025 (UTC)[reply]
You're free to change consensus on that. —Bagumba (talk) 04:48, 21 January 2025 (UTC)[reply]

Script for wikilinking?

Is there a script like DisambAssist for mass changing of wikilinks? CNC (talk) 01:12, 25 January 2025 (UTC)[reply]

AWB/JWB is pretty good for it in my experience. Just two regexes in most cases: \[\[ *OLDLINK *\]\] → [[NEWLINK]]; \[\[ *OLDLINK *\|([^\]]+)\]\] → [[NEWLINK|$1]]. OLDLINK should start with a capture group that gets upper- and lower-case, e.g. [Ff]oo. If it's a case where ]]s syntax might be used, make sure that still works with the modified term. -- Tamzin[cetacean needed] (they|xe|🤷) 03:35, 25 January 2025 (UTC)[reply]
Thanks Tamzin, most of that code went over my head, but I'll check out JWB as haven't managed to get AWB to execute using Wine. To clarify, would this work for changing piped links to target the piped description instead? This is more less what I'm looking to achieve here, i.e. effectively fixing NOTBRKOEN based wikilinks for a specific target? For example replacing [[YouTube|YouTuber]] to [[YouTuber]] for all YouTube links en mass in articles? CNC (talk) 14:47, 25 January 2025 (UTC)[reply]
@CommunityNotesContributor: So, if you fire up JWB, you'll see in the Edit tab there's a "Replace" box and a "With" box. For piped links where you're only looking for a specific bit of piped text, you'd set "Replace" to \[\[ *[Yy]ouTube *\|YouTuber(s?)\]\] and "With" to [[YouTuber]]$1. Then check "Regular expression" and under "flags" put g. To handle an alternate syntax, click "More replace fields" and add a replace for \[\[ *[Yy]ouTube *\]\]r(s?)\b with all the other settings the same. There's a few more bells and whistles you could throw on there to handle edge-cases, but may be easier to just handle manually if they arise. If you want to better understand what the regex bits are doing, take a look at https://regex101.com/, or drop a line on my usertalk. :) -- Tamzin[cetacean needed] (they|xe|🤷) 19:42, 25 January 2025 (UTC)[reply]
Thanks for that, I understand it much better now with an example and will check out the documentation. I'm still in draft mode but will go to your talk page if I have problems with it, thanks for the invite :) CNC (talk) 14:10, 26 January 2025 (UTC)[reply]

Можем ли мы рассмотреть возможность переформулировки MOS:GEOLINK , чтобы разрешить исключение для связывания исторических государств, которые могут быть не так хорошо известны большинству людей?

Например, разрешая Ай-Ханум , Греко-Бактрийское царство . Греко-Бактрийское царство неизвестно большинству людей во всем мире; предоставление ссылки, как мне кажется, полезно. Правильно ли я понимаю, что мы хотим избежать ситуации MOS:SEAOFBLUE , поэтому мы не будем связывать страны? Мне кажется, что полезность ссылки перевесит эту эстетическую озабоченность в этом случае. seefooddiet ( talk ) 06:32, 28 января 2025 (UTC) [ ответить ]

Что-то подобное уже есть, см. «Если наименьшая единица — существующее место, а наибольшая — нет, то желательно разнести ссылки, когда это возможно». Gawaon ( обсуждение ) 03:22, 29 января 2025 (UTC) [ ответить ]
О, формулировка немного сбивает с толку. Этот принцип применяется даже в инфобоксах? seefooddiet ( talk ) 03:28, 29 января 2025 (UTC) [ ответить ]
Он был добавлен совсем недавно, см. обсуждение выше на #MOS:GEOLINK для бывших стран/субъектов, которые к нему ведут. Кажется, вопрос о том, как обрабатывать такую ​​ситуацию в инфобоксах, не был явно решен. Лично я бы посчитал приемлемым использовать этот стиль и в инфобоксах, но вы, возможно, предпочтете возобновить обсуждение выше. Gawaon ( talk ) 03:42, 29 января 2025 (UTC) [ reply ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Linking&oldid=1272535442"