Патрулирование не открывая лишних страниц[править код]
Можно ли реализовать патрулирование из истории правок статьи, не открывая отдельных страниц как сейчас? И/или из вклада участника если в статье только одна правка. − Флаттершай — говор08:11, 29 января 2022 (UTC)
У меня тоже не работает. :( Я вроде нашел ошибку и исправил у себя. Написал запрос на исправления гаджета. Когда его исполнят, должно все заработать. — Алексей Копылов09:47, 29 января 2022 (UTC)
Имхо, «Навигационные окошки» ничем не могут помочь при патрулировании. Когда я навожу курсор на ссылку «История» в списке наблюдения, то благодаря «Навигационным окошкам» высвечивается список версий статьи, но без пометок, какие версии ранее просмотрены, а какие нет, и без возможности выделить те или иные версии, чтобы их сравнить. Так что по-любому приходится кликом правой кнопки мыши по ссылке «История» открывать историю в новой вкладке, что очень неудобно, когда статей с новыми изменениями в списке наблюдения много. Вот эта необходимость сначала входить в историю, а потом уже сравнивать разные версии очень замедляет патрулирование. А что касается того, чтобы прямо из истории видеть свежие изменения, то там просто маленький фрагментик показывается, вырванный из контекста, ничего толком не видно. V for Vendetta (обс.) 12:31, 4 февраля 2022 (UTC)
Патрулирование при помощи гаджета "навигационные окошки"@V for Vendetta, если навести мышку на "[непров.]" в списке наблюдения, то тогда в окошке появится разница отпатрулированной версии и текущей. В это же окошке будет кнопка "отпатрулировать". — Алексей Копылов02:20, 5 февраля 2022 (UTC)
Спасибо, Алексей! Удобный гаджет при патрулировании одной (!) правки. При двух и более надо смотреть каждую правку внимательно. -- Marimarina (обс.) 08:29, 5 февраля 2022 (UTC)
Можно и несколько патрулировать, если, конечно, общее число измерений невелико. Большое изменение, даже если одно, не помещается в всплывающее окошко. — Алексей Копылов07:11, 6 февраля 2022 (UTC)
А так уж и нужно согласие на АПАТ? просто я тут патрулирую за 3 участниками они в основном делают мелкие правки на множестве страниц 1200+730+920= 2850 за месяц,. Это больше половины патрулирований которые я совершаю. Вот я и подумала о том что было бы хорошо что бы у них был АПАТ. Но один из самых активных не отвечает уже долго но при этом правит. − Флаттершай — говор19:05, 28 января 2022 (UTC)
ПАТ или админ, @Флаттершай, которым примелькался ник, могут рекомендовать присвоение, на странице запросов к админам. Если параметры соблюдены и нет возражений, админ присваивает. Если соблюдены и есть, происходит обсуждение. После присвоения участнику сообщают на его СО. Если не-АПАТ просит стать АПАТом, или хотя бы интересуется на какой-то или чьей-то СО, как им стать, это доказывает, что он, по всей вероятности, вандал, и является достаточным, хотя и необязующим, условием, что он АПАТа никогда не получит. Игорь (обс) 15:13, 29 января 2022 (UTC)
Что "не так"? Я описал существующие правила. Ни у кого согласия не спрашивают, потому что это их не касается и на них не влияет, это для помощи ПАТам. Игорь (обс) 16:10, 29 января 2022 (UTC)
Все без исключения случаи. Есть мнение, что мы говорим о разных википедиях. Флаттершай меня поняла, когда я к ней обращался. Вы, видимо, не в курсе. Игорь (обс) 00:33, 31 января 2022 (UTC)
Предположу, что вы имеете в виду википедию на иврите. Это не было явно указано и, очевидно, большинство участников тоже «не в курсе». Поэтому несогласие коллеги вполне понятно. -- Klientos (обс.) 02:29, 31 января 2022 (UTC)
@IKhitron, я, например, уже довольно давно с вами общаюсь и поэтому понимаю, что вы имеете в виду, говоря "у нас". Но без такового знания это выражение выбивается из контекста, ибо, находясь "у нас" в рувики, вы говорите "у нас" про иврит-вики. Мне кажется, все-таки имеет смысл уточнять, особенно если речь идет об общих страницах, чем те, где вас лучше знают. Как вы думаете? Michgrig (talk to me) 06:14, 31 января 2022 (UTC)
Да. Без сомнения, если бы я не обращался к одному конкретному человеку, а просто писал это как часть обсуждения, ко всем. Здесь же, максимум, кто-то, читающий комментарий, обращённый к другому, не мог бы понять, о каком другом месте идёт речь, но, надеюсь, можно было понять, что речь идёт о другом месте, исходя из формулировки. Если бы первоначальный вопрос был "где это у нас", я бы понял намного быстрее суть заблуждения коллеги. Игорь (обс) 12:37, 31 января 2022 (UTC)
Предположу, что не всякий участник захочет, чтобы ему присвоили статус АПАТа (такие случаи уже вроде были). У каждого свои причины: неуверенность, боязнь «брать ответственность» за флаг и проч. Поэтому я считаю, что присвоение флага должно осуществляться только с согласия участника. Radmir Far (обс.) 19:53, 28 января 2022 (UTC)
У нас были участники, которые категорически были против, чтобы им присуждали флаг. Не говоря о том что получится некрасиво, если участнику присвоят флаг без его согласия, а потом при каком-то нарушении (действительном или мнимом) потащат на лишение флага. Согласие подтверждает, что участник как минимум ознакомился с требованиями ВП:ПАТ и готов их соблюдать. Vladimir Solovjevобс08:38, 29 января 2022 (UTC)
Да, это вопрос обязательств, которые человек на себя берёт. Проект добровольный, и нельзя просто так вешать на человека дополнительные и, вообще говоря, необязательные ограничения. −−APIA〈〈обс〉〉12:44, 1 февраля 2022 (UTC)
Запрет на выставление грифа малый текст[править код]
Наблюдаю вот такую фигню, не первый год по статьям в Вики, сам лично сталкивался пару раз, не успели написать статью а сразу или через день ставят гриф малый текст/будет удален через два дня все кто нипопадя. Но в Вики уже много лет сложился/существует неофициальный консенсус - 300 знаков=600 байт, и всё! это не малый текст. И посему предложение - выше этих цифр запретить ставить гриф МТ. Ставящим такое, писать предупреждение, что так делать нельзя. Мой последний пример Мерсинский метрополитен - при создании 932 байта = 466 знаков.+ последующая добавка - 1026 байта = 513 знаков. 77.38.185.12708:46, 28 января 2022 (UTC)
Вообще, эта рекомендация (не выносить на КБУ только что созданные короткие статьи) уже уже прямо прописана в соответствующем критерии. Почему ей не следуют, это другой вопрос. — Cantor (O) 09:00, 28 января 2022 (UTC)
Это отложенное БУ; шаблон {{subst:ds}} предназначен именно для новых статей. Также замечу, что 150—300 знаков видимого текста с пробелами и непосредственный текст статьи без учёта содержимого шаблонов, категорий, вики-разметки и ссылок на источники (а по смыслу надо добавить и «без учёта заголовков» — или как минимум, заголовков пустых разделов) — а это может существенно превышать 600 байт. NBS (обс.) 09:17, 28 января 2022 (UTC)
Все-таки не хватает гаджета Ле Лоя в виде модуля/общего скрипта, чтобы было написано, сколько в текущей статье символов, каков расчет, и, в случае если спустя два дня мт выполнен, шаблон может меняться не в кбу, а что-то иное. ~~~~ Jaguar K · 09:27, 28 января 2022 (UTC)
Вопрос, на что иное менять. Если просто убрать — статья с высокой вероятностью останется незамеченной с существенными недостатками (шаблон {{rq}} вместе с {{subst:ds}} редко ставят), а то и состоящая в основном из copyvio (некоторые новички именно так «спасают» статьи). NBS (обс.) 09:58, 28 января 2022 (UTC)
Никогда не было такого консенсуса. ВП:МТ: 300 символов связного текста включая пробелы + нетривиальные факты. В начальном виде это действительно КБУ, шаблон {{Deleteslow}} проставлен справедливо. А если участник настойчиво пишет такие недостатьи, его могут и заблокировать. Статья в основном пространстве должна сразу отвечать ВП:МТ. Igel B TyMaHe (обс.) 15:05, 28 января 2022 (UTC)
Предлагаю объединить этидве страницы и удалять выполненные запросы через два дня после выполнения или через 30 дней, если статья никого не заинтересовала, без архивирования. А сами архивызапросов к патрулирующим удалить. Кроме того, нужные и полезные списки вида Самые посещаемые страницы за 03.10.2021 предлагаю перенести на подстраницу, а через 30 дней удалять без архивации. Возможно, получилось немного сумбурно. Текст постоянно дополнялся и исправлялся в черновике с октября 2021 года. С уважением, Oleg3280 (обс.) 13:03, 15 января 2022 (UTC)
Их делили не для того, чтобы объединять, а для того, чтобы статьи, которые скорее всего соответствуют требованиям, патрулировались быстрее. И обсуждать это надо было не здесь, а на форуме патрулирующих. В этом разделе смешаны разные темы, так что непонятно, как оформлять возражения. Я не считаю конструктивным засыпать форум огромным количеством грандиозных предложений, разобраться в которых мало кто успеет, при этом без каких-либо пояснений, зачем это предложено. DimaNižnik14:23, 15 января 2022 (UTC)
На каждое предложение отвечать отдельно. Я готовил всё в черновике. Каждая тема оформлена отдельно. И не зависит от других тем.Oleg3280 (обс.) 14:26, 15 января 2022 (UTC)
И каким образом самые посещаемые страницы относятся к патрулированию? И зачем это всё надо? Кому мешают Архивы? Удалять необработанные запросы вообще не надо. DimaNižnik14:31, 15 января 2022 (UTC)
Вы их долго готовили, а остальные участники вынуждены разбираться во всём сразу. И не показано, что поломано, нет никаких разъяснений, зачем сделано то или иное предложение. DimaNižnik14:35, 15 января 2022 (UTC)
А принимать их или нет, пусть решает Сообщество. Для любого предложения нужно время, чтобы оформиться. Я не был готов осенью, только сегодня получилось. Извиняюсь, что, возможно, много тем сразу (здесь 4, на техфоруме 2). Oleg3280 (обс.) 20:10, 15 января 2022 (UTC)
Соглашусь, что обычно там нечего архивировать (по архивам и видно). Но тогда страничка вообще не должна выглядеть похожей на форум, чтобы на ней не было соблазна начать обсуждения, она должна выглядать в точности как ВП:ЗКАБ. Реплики во вкладах останутся. — 188.123.231.6014:38, 15 января 2022 (UTC)
Лучше оставить текущее оформление. В отличие от других архивов (например, админов или ботоводов), архивы запросов к патрулирующим ценности не представляют. Это моя точка зрения как патрулирующего. Могу ошибаться. Oleg3280 (обс.) 15:44, 15 января 2022 (UTC)
Бот помечает, но как частою не скажу. Вместо скрипта можно editnotice повесить, для ПАТ+ с готовой формой, для остальных пример заполнения (если нужно). Аналогично такому, скажем — c done, not done и подобными шаблонами. Но если неохота редактировать разделы по одному, то нужен скрипт, да. ~~~~ Jaguar K · 23:46, 15 января 2022 (UTC)
ВП:ЗКП — одна из мёртвых страниц. Какие-то анонимы пишут какие-то запросы по статьям, в которых они ничего не правили, затем бот эти запросы удаляет. Живые патрулирующие туда не заглядывают (и правильно делают); те страницы, которые бот изредка помечает как отпатрулированные, видимо, патрулируются независимо от запросов. При текущем положении дел эта страница только вводит в заблуждение. --217.118.92.519:41, 16 января 2022 (UTC)
Тут самое плохое то, что большая часть ежедневно дублируется. Наверно лучше бы было иметь список неотпатрулированнх статей, отсортированных по посещаемости, можно неполный, или какое-то количество этих статей, или свыше какого-то количества посещений. DimaNižnik16:19, 16 января 2022 (UTC)
Предлагаю удалить всекниги, так как они являются авторскими подборками статей для формирования книг, но быстро устаревают, так как статьи переименовываются или удаляются. А отдельную статью всегда можно сформировать в PDF-формате для чтения на компьютере. В англовики книги в прошлом году удалили. Точнее, как я понял, удалили пространство имён, а книги переместили в подстраницы участников. Возможно, получилось немного сумбурно. Текст постоянно дополнялся и исправлялся в черновике с октября 2021 года. С уважением, Oleg3280 (обс.) 13:03, 15 января 2022 (UTC)
Поддерживаю. PDF-вариант статьи полезен, возможность закачать несколько статей скопом в «книгу», возможно, была бы полезна (но непонятно зачем, если можно pdf по отдельности загрузить), но эта функция ушла в infinity fixing и недоступна. Можно в США заказать печатный вариант, который вообще никому не понадобится (и навряд ли издательство до сих пор предоставляет услугу и информация уже скорее всего неактуальна). А список в черновике ну прям вообще бесполезен. YarTim (обсуждение, вклад) 16:01, 15 января 2022 (UTC)
Подавляющее большинство этих книг в личных пространствах. Удалять что-то из ЛП активных участников без их согласия и без явных нарушений правил нельзя. А вот эти в общем пространстве, да, можно. Если никто в личное себе не заберёт. AndyVolykhov↔16:06, 15 января 2022 (UTC)
Это я все книги со словом Википедия:Книги оформил в эту категорию. Изначально там было только 5 книг. Все книги сообщества созданы обычными участниками и ничем не отличаются от книг в личном пространстве, кроме способа сохранения. Oleg3280 (обс.) 16:16, 15 января 2022 (UTC)
Удалить по аргументам номинатора. То есть подборки книг перенести в ЛП, и пусть там лежат навечно. Против зачисток "через 2 года". Вам дискового пространства жалко? Пусть в ЛП будут вечно. Это ж не левый материал. Удалисты. Саму функциональность убрать из движка, так как пользы от нее нет. И "10% от продаж Wikipedia press идет фонду" - считаю абсолютно неприемлеммым, per Krassotkin. Даже объяснять не буду, это очевидно. The-ultimate-square (обс.) 18:53, 23 января 2022 (UTC)
В прошлом году я проводил опрос. Всем участникам, принявшим участие в опросе, большое спасибо. Я пытался сопровождать американские регионы (23 апреля 2019 — 8 марта 2021) и востоковедную неделю (26 января 2020 — 29 января 2021), а также хоть что-то реализовать, но у меня не совсем получилось. По своему личному опыту скажу, что кураторство в тематических неделях — очень трудозатратная штука. К сожалению, сегодня тематические недели переживают определённый кризис в плане мотивации, поиска новых тем и привлечения новых участников. Предлагаю объединить все тематические недели в одну. Выбор тем свободный. То есть история, география, культура, музыка, фильмы, литература, наука, кулинария. Географические недели могут быть как по странам, так и по отдельным регионам или городам. Возможность проведения недели определяется степенью её готовности и наличием заинтересованных участников (не менее трёх). Длительность одной недели предлагаю сделать 14 дней. Одновременно не более 4 недель на Заглавной. Это позволит не дублировать текст Примите также участие в и упростит шаблон. Что касается мотивации, то предлагаю оставить это на усмотрение организаторов той или иной недели. То есть, кто создаёт неделю, тот проводит и награждает. Кроме того, объединение тематических недель позволитизбежатьненужных споров и сосредоточиться на статьях. А также вести все обсуждения тематических недель (в том числе организационные вопросы и выбор новых недель) в рамках этого проекта. В предлагаемый проект переносятся только новые или предложенные ранее тематические недели. Также вполне можно отказаться от шаблонов проведённых или запланированных недель, которые размещаются перед категориями. Тем более, что работа с категориями в таких шаблонах не работает, если они находятся в пространстве имён Проект. Также предлагаю не использовать карты для проведённых или запланированных недель. Участник, который актуализирует информацию, один, а тематических недель много. Достаточно вести общий список проведённых недель. Тем более, что будут возможны не только географические, но и общетематические недели. Сейчас у нас 7 проектов тематических недель плюс Проект:Востоковедная неделя (закрыт) и Проект:Тематическая неделя англоязычных регионов мира (на уровне идеи). Если кратко, то предлагаю объединить все проекты тематических недель для оптимизации организационных и человеческих ресурсов. Возможно, получилось немного сумбурно. Текст постоянно дополнялся и исправлялся в черновике с октября 2021 года. С уважением, Oleg3280 (обс.) 13:03, 15 января 2022 (UTC)
То есть вы предлагаете преобразовать что-то типа «Неделя Южного Уэльса» в «География Австралии», «История Австралии», «Эндемики Австралии»? Да, я думаю, что такое будет хорошей идеей, потому что интересы участников идут не по регионам, а по тематикам. YarTim (обсуждение, вклад) 16:21, 15 января 2022 (UTC)
Нет, я предлагаю все тематические недели проводить в рамках одного проекта. А тему определяет участник, создавший неделю. Oleg3280 (обс.) 16:24, 15 января 2022 (UTC)
Если кто-то чувствует, что есть силы вести какую-то неделю, её и оставить. А если сил уже нет, то объединять. Abiyoyo (обс.) 01:03, 16 января 2022 (UTC)
Я бы не объединял то, что хорошо или более-менее работает. Это я про проекты Тематическая неделя, ТН городов, ТН европейских регионов. По другим сказать не могу, так как не участвую в них. Для меня, конечно, было странным видеть закрытие проекта Востоковедная неделя. Однако думаю, что Востоковедную неделю так или иначе можно проводить в ПРО:ТН или в ПРО:ТНРРМ (Азиатская часть России+азиатские страны бывшего СССР) или даже в ПРО:ТНГ (допустим, Сингапур, Алматы, Гонконг, Токио, Новосибирск, Дели и др. — крупные города). А англоязычные регионы — в той же ТН, ТНГ (в 2012 году вообще 3 из 6 таких недель было), ТНЕР (если англоязычная страна в Европе) или ТНАР (если англоязычная страна в Африке). Объединять — это надо смотреть по активности проектов, как произошло с Востоковедной неделей. Разве что можно какой-то чёткий алгоритм сделать чередования недель. Плюс — да, я бы сделал все недели минимум 10 дней, в идеале бы — 14 дней. Brateevsky {talk} 14:13, 16 января 2022 (UTC)
Коллега я могу с вами согласится с тем, что у нас 8 рабочих ("Работу недели" забыли) +2 потенциальных проекта и это возможно несколько распыляет силы. Могу согласится и с тем, что кураторство трузоззатратная вещь. Но я не соглашусь с тем что слияние проектов решит ту проблему: 1) давайте вспомним как началось размежевание тематических недель и определение сроков (Там и карта уже проведённого на 2009 есть. Сейчас единая карта будет гораздо ляпистей). Как видно из той темы захотелось коллегам писать про то, а не другое и появился новый проект, а потом и другие. 2) Вот сейчас каждую календарную неделю видим по 5-6 тем на заглавной (3 от РН и по 2-3 от разных географических недель). У участников есть выбор писать в рамках одной из этих тем или же (если ни одна из тем не устраивает) подождать недельку новых тем и занимаясь чем то иным. Да выхлоп конкретных недель в отдельных проектах может быть низким, но есть у людей есть выбор. Если же тематические недели будут слиты, то это не сильно увеличит количество желающих писать о "замбиоках Тумбо-Юмбии" или "высоком стиле Кар-Кар-Кар" (Ну далека от меня условная Антарктида и не важно историческую, филателистическую, военную, географическую, железнодорожную или литературную специализацию тему недели вы выберите, ну "хоть убейте", но писать про неё я не буду, так как не интересно). И люди просто будут писать/дорабатывать статьи в иных проектах 3) По поводу проведения "при наличии заинтересованных участников (не менее трёх)". а) Вот именно подобный принцип (когда каждые 10 дней нужно было подтверждать заинтересованность в теме) сделало для меня старый вариант Работы Недели не интересным. "Можно голосовать, но не участвовать" б) А что делать если не будет трёх заинтересованных в конкретной теме участников. Ну например в июле условного 2222 года будет 10 участников каждого из которых заинтересует своя тема?-- Авгур (обс.) 21:18, 2 февраля 2022 (UTC)
Авгур. Большое спасибо за подробный комментарий. Что касается Работы недели, то последние 3,5 года там в основном мои итоги, поэтому и не упомянул. Только тематические недели. Всё, что я предложил выше, долго обдумывалось и не было сиюминутным решением. Думал предложить обсуждать и проводить все тематические недели в рамках одного проекта с одновременным проведением до 4 недель. Без карт, так как ими занимается один участник. Учёт проведённых недель можно вести простым списком. Oleg3280 (обс.) 22:22, 2 февраля 2022 (UTC)
Но тем не менее если Географическую неделю считать "первой", то Работа Недели является "нулевой" (то есть материнской по отношению к ГН). Притом у нас в рувики уже 14 лет одновременно действуют и Работа Недели и Тематические недели, а в других языковых проектах уцелело только одно. И это ИМХО плюс для рувики.-- Авгур (обс.) 08:42, 3 февраля 2022 (UTC)
Поскольку я столкнулся с отменой моих правок в статьях и меня направили сюда, обращаюсь к вам, и надеюсь, мне помогут здесь решить вопрос раз и на всегда... Я предлагаю, в статьях «Плотность», «метр» и многих других изменить степени с « м³ » на « м3 », поскольку так будет намного лучше и корректно видно степень... Первый вид ужасен, и его даже с телефона не увидишь, а вид, предложенный мной не нуждается в лупе... Поэтому, я предлагаю такое изменение, и надеюсь, что мне не придется устраивать войну правок ) С уважением, Dan watcher 32 (обс.) 11:06, 14 января 2022 (UTC)
Хм, у нас во многих статьях так мелко. Интересно, а нет варианта сделать среднее между ними? В статьях можно и ботом заменить, думаю. — Proeksad (обс.) 12:45, 14 января 2022 (UTC)
Proeksad, вряд-ли.. Если бы можно было, давно бы уже заменили.. Как видно, те, кто создавал статьи, использовали Ворд при написании степеней, но уже появилась команда, позволяющая сделать степень крупнее.. Я думаю среднее не нужно, данный вид « м3 » подходит абсолютно. Dan watcher 32 (обс.) 12:56, 14 января 2022 (UTC)
Да нет, значок куба, как и квадрата, подставляется в панели редактирования, поэтому если менять размер, то начинать надо оттуда. --Deinocheirus (обс.) 13:08, 14 января 2022 (UTC)
Deinocheirus, и как туда попасть, не могли бы вы дать ссылку на панель редактирования?.. Я менял эти степени в статьях, однако участник Lesless без объяснения причин откатывал их.
На любой странице, если нажать «править код», открывается панель редактирования. Под окном редактирования длинный список всяких значков, включая °, ², ³, ¾ и так далее. Вот прямо сейчас я их взял из этого списка — посмотрите кегль. То есть надо: во-первых, приходить здесь к консенсусу, что кегль для степеней надо единообразно увеличивать, а во-вторых, подавать техзапрос на его изменение в панели редактирования. — Deinocheirus (обс.) 13:39, 14 января 2022 (UTC)
Deinocheirus Да, я так и делал, однако как я писал выше, участник откатывал изменение степеней, без объяснения причин, и отправляя меня сюда.. Получается, шансов менять степени вручную нет, остается только подавать техзапрос? Dan watcher 32 (обс.) 13:43, 14 января 2022 (UTC)
Поддерживаю. В англовики такое зафиксировано в правилах ("Format exponents using <sup>, not special characters" en:MOS:UNITNAMES), такое написание обеспечивает единообразие с единицами с другими степенями типа Вт·м−2·К−1 и соответствует рекомендациям W3C и Unicode использовать разметку, а не юникодные символы в таких случаях, см. en:Unicode subscripts and superscripts. M5 (обс.) 13:51, 14 января 2022 (UTC)
В примерах к этому правилу другой шрифт, и спецсимвол становится больше верхнего индекса и выглядит лучше. Так что для начала было бы неплохо посмотреть, что в других скинах. Igel B TyMaHe (обс.) 15:04, 14 января 2022 (UTC)
Я нарушу правила об абсурде и объясню примером, почему так делать нельзя: Вот это в статьях сейчас м³. Вот это по факту предлагает топикстартер: м3 Смотрим на межстрочный интервал. Поэкспериментировал немного больше, выяснил, что лишний пиксел добавляется не из-за верхнего регистра. Так что возражение снимается. Igel B TyMaHe (обс.) 14:52, 14 января 2022 (UTC)
А вот наглядный пример из Плотность, почему так делать надо:
Плотность межзвёздной среды приблизительно равна 10−23—10−21 кг/м³. (текущая версия, степени разного размера)
Плотность межзвёздной среды приблизительно равна 10−23—10−21 кг/м3. (исправлено)
Кровь из глаз! Плюс степени кроме ¹²³ находятся за пределами блока Latin-1 и далеко не все шрифты их содержат. M5 (обс.) 15:19, 14 января 2022 (UTC)
Igel B TyMaHe Нужно делать так, чтобы степень было видно четко и невырвиглазно... Это как маленький текст при оформлении кредита, все нужно смотреть под лупой... Тут такого не должно быть и степени должны быть понятны рядовым читателям.. Например, г/см3 показывает, что степень относится именно к «см», то есть «грамм на сантиметр в кубе» — Эта реплика добавлена участником Dan watcher 32 (о • в) 16:43, 14 января 2022 (UTC)
Шрифт шрифту рознь.
Плотность межзвёздной среды приблизительно равна 10−23—10−21 кг/м3
Плотность межзвёздной среды приблизительно равна 10⁻²³—10⁻²¹ кг/м³
Unicode 14 00B2 стр. 3 "SUPERSCRIPT TWO = squared". Более ранняя версия: версии 1.0(/1.0.1) стр. 7/177 "00B2 SUPERSCRIPT DIGIT TWO = ISO SUPERSCRIPT TWO = squared", где ISO - General Scripts стр. 5/32 Юникод этим символом просто покрывал совметимость с ISO 8859-1. Ещё они есть в 2070 (1-9) стр. 113/283 блок Superscripis and Subscripts, где этот блок тоже Symbols стр 6/79 "Solely to provide compatibility with existing character sets." Описаний мало. Для истории можно посмотреть в других версиях. Но ориентировать нужно по последней версии. Unicode 14 22.4 Superscript and Subscript Symbols стр. 29/860 "Therefore, the preferred ... is by style or markup in rich text. " "However ... as part of the plain text" "from being interpreted like 23 by simplistic parsers" "The use of superscript two and superscript three is common legacy practice when referring to units of area and volume in general texts." Юникод как минимум не против использования "by style or markup in rich text", как максимум даже "preferred". "plain text" и "23 by simplistic parsers" вроде не встретить на вики-сайтах. Сунприат00:18, 15 января 2022 (UTC)
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
Добрый день, я столкнулся с отменой моих правок в статьях и меня направили сюда, поэтому обращаюсь к вам, и надеюсь, мне помогут здесь решить вопрос раз и на всегда... Я предлагаю, в статьях «Плотность», «квадратный метр» и многих других изменить степени с « см³ » на « см3 », а также все цифры, которые написаны как « ³ », или изменить эту функцию в панели редактирования, поскольку так будет намного лучше и корректно видно степень... Первый вид (« м³ ») ужасен, и его даже с телефона не увидишь, а вид, предложенный мной не нуждается в лупе и более контретно указывает на число в степени ... Поэтому, я предлагаю такое изменение, и надеюсь, что моё предложение примут, поскольку оно направлено на благое оформление деталей в статье. Данное предложение я уже выставлял в блоке «Вопросы», однако итога там нет. Dan watcher 32 (обс.) 11:59, 16 января 2022 (UTC)
(Коллеги, за форумом ВП:Ф-В многие не следят и не ждут, что там достигают консенсуса по каким-то глобальным вопросам.) Топикстартера полностью поддерживаю и давно уже заменяю юникодовые символы на разметку в шаблонах. Очень мелкий шрифт нарушает ВП:РТ — раз, символами не напишешь то, для чего этих символов нет, — два, символы надо где-то добывать — три, символы будут хуже искаться — четыре. Словом, тут всё достаточно однозначно, от юникодовых символов надо избавляться. Что касается предложения Proeksad создать среднее по размеру — такое существует: шаблон {{smallsup}}, скопированный из английского {{smallsup}}. Jack who built the house (обс.) 16:50, 17 января 2022 (UTC)
На всякий случай повторю: я в данный момент не спорю с утверждением "от юникодовых символов надо избавляться", но если это делать, то в том числе (или даже в первую очередь) - в панели редактирования, откуда они в статьи в основном и попадают. Остальное-то просто ботом можно потом поменять (если только никто не укажет на случаи, в которых это ботом делать нельзя). Что до кегля, думаю, он должен быть идентичен кеглю для сносок, чтобы не было разнобоя в таком тексте: «см3[a 1]:14». — Deinocheirus (обс.) 16:54, 19 января 2022 (UTC)
В текущем обсуждении шаблона {{Внешние ссылки}} возникла идея, что хотелось бы уведомлять заинтересованные проекты о новых обсуждениях ссылок по их темам. Поэтому я предлагаю создать шаблон для уведомления участников проектов по аналогии с d:Template:Ping project или en:Template:Mass notification. Тут есть возможность пойти по пути как Викиданных, и пинговать тех, кто записался на страницу участника (в нашем случае, видимо, придётся создать отдельные страницы в проектах, где будут только те участники, которые хотят получать уведомления), так и по пути английского раздела, и иметь централизованное хранилище таких групп. Лично мне по опыту участия в Викиданных первый вариант нравится сильно больше, так как позволяет участникам самим легко добавлять и исключать себя из уведомлений. — putnik20:33, 11 января 2022 (UTC)
Согласен, первый вариант самый удобный и простой, хотелось бы иметь эту возможность именно в таком виде. — evs💬13:22, 12 января 2022 (UTC)
Тут вопрос в том, что разные проекты могут хотеть участвовать в разных обсуждениях. Т.е. как определять что в обсуждение ХХХ нужно позвать проекты А, В и С? Т.е. как саму идею поддерживаю. Я считаю что у нас не везде уведомления на должном уровне. Но не очень понимаю кто и как будет определять какие проекты уведомлять. Sas1975kr (обс.) 19:38, 2 февраля 2022 (UTC)
Вопрос именно в том насколько объективна оценка что это принадлежит тематике проекта. И как это будет реализовано. Т.е. на конкретном примере КУ - проект сам определил какие категории его интересуют. И то возникают интересные коллизии с запутанной системой категорий. И попадаются статьи которые проект явно не заинтересуют. Т.е. я вижу что есть риски в правильной идентификации кому рассылать, если этим будут заниматься не проекты, а инициаторы дискуссии. Тем более когда там нет более менее объективного критерия типа категорий. В целом ведь почти все поддерживают идею рассылок. Критикуют чаще ее неточность, когда уведомления приходят не к тому кому надо и воспринимаются как спам.Я по сути идею поддерживаю, но пока смутно представляю как это будет работать и есть некоторые опасения. Возможно я плохо понял идею. Конкретные примеры обсуждений, и описание алгоритма как и кому будет рассылаться сильно бы помогли. Sas1975kr (обс.) 07:44, 4 февраля 2022 (UTC)
Есть риск и что один участник пинганёт другого когда не следовало. Пока ничего плохого от этого не случается. Если ложные оповещения будут слишком частыми, то сообщество поищет и найдёт выход. Думаю, сейчас это не причина отказываться от полезной функции. -- Klientos (обс.) 23:04, 4 февраля 2022 (UTC)
Я подумаю о том, чтобы обрабатывать ссылки on demand, когда они непосредственно видны пользователю, вместо обработки всех скопом при загрузке. Но у меня на Ryzen 7 5800X зависаний пока не замечается. Сергио (обс.) 02:02, 23 января 2022 (UTC)
@Serhio Magpie Ну я например как то раз хотела отпатрулировать правку а из-за того что скрипты загружаются не сразу и Instant Diffs создаёт если так можно сказать кнопки, моё нажатие сместилось из-за появления кнопок на откатить. Хорошо что участница мне нечего не предъявляла. − Флаттершай — говор07:44, 29 января 2022 (UTC)
Может, стоит по умолчанию создавать статьи в Инкубаторе, а уже после проверки патрулирующими переносить в Основное пространство? Например, в Фонде SCP так и делают: сначала статья создаётся на Полигоне, а уже потом, после доработок и проверок переносится в основное пространство. Делается это для поддержания качества статей на одном уровне. Мне вот не очень хочется, чтобы читателям приходилось читать статьи с заметными недостатками.
P.S. Кажется, может случится Эффект непрямого отскока, из-за чего Инкубатор стремительно переполнится. А у нас Патрулирующих не так много, чтобы хватало и на патрулирование правок в Основном пространстве, и на проверку статей для переноса из Инкубатора. Аноным (обс.) 09:18, 1 января 2022 (UTC)
Лично я стойкий противник Инкубатора и черновиков. Статьи должны создаваться сразу в ОП, это нулевой столп — "может редактировать каждый". Не скрытые пространства, а основное. Прямой ущерб, например, в том, что черновики бессрочно заблокированных участников не могут массово использоваться после блокировки. А так — положительный вклад остается независимо от последующих событий с учёткой. Igel B TyMaHe (обс.) 10:10, 1 января 2022 (UTC)
Против. Я использую личное пространство для черновиков, новые участники часто используют инкубатор. Многие создают сразу в основном пространстве. Oleg3280 (обс.) 13:29, 1 января 2022 (UTC)
Такое требование можно рассмотреть для новых участников... Особенно учитывая, что презентабельные ботостабы со сносками (и чепухой с точки зрения достоверности) без проверки не определить. — Proeksad (обс.) 17:20, 1 января 2022 (UTC)
Если наберется у нас достаточное число опытных участников заниматься рассмотрением таких статей, но что-то мне подсказывает, что не наберется. Статьи, написанные с новой учетки не патрулируются Богзнает сколько времени, то же и в Инкубаторе будет. — Юлия 70 (обс.) 14:37, 3 января 2022 (UTC)
Инкубатор немного для другого — чтобы новички могли научиться писать статьи без опасности, что кто-то удалит их труд посреди написания. Я уж не говорю о том, что опытные участники в Инкубаторе писать не должны. Vladimir Solovjevобс15:19, 3 января 2022 (UTC)
Была у меня в свое время похожая мысль - новые статьи анонимов и малоопытных участников принудительно отправлять в инкубатор, а право создавать статьи сразу в основном пространстве давать только тем участникам, у которых набралось достаточно созданных ими статей, перенесенных из инкубатора в основное пространство. В принципе у подобных идей есть определенные плюсы (вроде того, что меньше вероятность появления в основном пространстве откровенного хлама, подлежащего удалению). Но и определенные минусы тоже есть (как минимум, ВП:ВСЕ после этого придется отменить или серьезно пересмотреть). В общем, я за предложенную идею, и одновременно сомневаюсь в том, что сообщество ее поддержит. — Grig_siren (обс.) 10:26, 4 января 2022 (UTC)
Я бы отправил туда статьи анонимов. В конце концов в англовики им вовсе запрещается статьи создавать. Но в этом случае переполнение Инкубатора вполне вероятно. Сейчас статьи анонимов патрулятся в ОП. В Инкубаторе этого стимула патрулировать у большинства участников нет, а в Инкубаторе очень мало опытных помощников. — Pessimist (обс.) 11:01, 4 января 2022 (UTC)
Если человек взял себе труд зарегистрироваться, то это демонстрирует минимальную серьезность отношения к делу и дает возможность общаться с таким автором через СО. — Pessimist (обс.) 14:59, 4 января 2022 (UTC)
Как только регистрация станет условием, разрешающим то действие, ради которого редактор сюда зашёл, она тут же перестанет быть признаком «минимальной серьёзности отношения к делу», а только лишним техническим шагом вроде преодоления капчи, и ничто не обяжет редактора всё ещё помнить свой рандомно набранный пароль от реги завтра, к тому времени, как настоящие википедисты что-то напишут ему на СОУ. Чтобы к реге можно было «серьёзно относиться», её создание должно быть гораздо более затруднено, чем это есть сейчас (напр., подтверждением по смс на уникальный мобильный номер). Странно, что на форумах так часто появляются поводы объяснять это, а на СОУ тем временем действительно очень редко обращаются что к зарегам, чьи правки отменяются, что к анрегам на постоянном (или ещё не сменившемся) адресе. — 188.123.231.3607:07, 5 января 2022 (UTC)
Фанфик-проект немного глупая параллель. Всё-таки не стоит, наверное, де-факто это превратится в тягомотную премодерацию, а раньше это было просто право получить помощь от другого участника. Да и ресурсов в проекте немного, чтобы весь поток переносить туда. YarTim (обсуждение, вклад) 15:45, 4 января 2022 (UTC)
«чтобы весь поток переносить туда» — почему «весь»? Думаю, максимум процентов 5 и это большей части (скорее всего) коснётся политиков (типа едросов и тому подобных), а это в основном заказные статьи от анонимов, т.е. бывших исключённых из ВП или добровольно покинувших проект. Также можно рассмотреть вариант: меньше тысячи символов и без картинок или определённых разделов (литературы, примечаний и т.д.), также для тех, кто только что зарегистрировался и не имеет вклада или он меньше чего-то там, например, нет ни одной нормальной статьи (только заготовки). Это для В, Т, ПИ, ПАТ, АПАТ, А и т.д. не распространяется, иначе было бы абсурдно обсуждать. Никто же здесь не будет утверждать, что патрульные, админы и из других групп участники статьи не пишут. Пишут и ещё как… и этот трафик и должен быть основным, процентов 90, имхо. Зайва Игорь Леонидович (обс.) 17:03, 4 января 2022 (UTC)
В Википедия:Выживаемость статей есть хорошее исследование 2018 года насчёт того, кто что пишет. В августе и сентябре автоподтверждённые без АПАТ написали 3464 статей, участники без АПОД написали 1961 статей, анонимы написали 1838 статей. Так-то это много, сможет ли Инкубатор столько статей вынести? YarTim (обсуждение, вклад) 06:12, 5 января 2022 (UTC)
Инкубатор и сейчас в десятки раз меньше не может осилить… Поэтому если статья не переносится за период (кажись, две недели) в ОП опытными участниками, то боты автоматом просрочку переносят в ОП и выставляют на удаление для проверки всеми желающими участниками, можно ли данную конкретную статью оставить или нет (вроде, так сейчас это работает). Я в инкубаторе бываю несколько раз в год и то, если просят, завалы в основном на КУ разгребать помогаю. Практика показывает, что большая часть статей в Инкубаторе брошена, опытные участники сразу в ОП пишут, поэтому надо, наверно, голосовалку создать, нужно ли нам заготовки пропускать через Инкубатор или сразу публиковать и потом уже через КУ принимать решение об их судьбе. Завалы на КУ увеличатся, зато качество стабов в ОП возрастёт. Я любое решение поддержу, лично мне не принципиально, как большинство решит, так и поплывём… Зайва Игорь Леонидович (обс.) 06:53, 5 января 2022 (UTC)
Мне кажется, что в любом варианте премодерации лишь очень сильно возрастут ненужные завалы, мне кажется более оптимальным вариант, который есть сейчас: есть патрулирование, де-факто премодерация есть (многие ПАТы занимаются просмотром новых статей), но просто в виде проверки на отсутствие вандализма, спама и подобных нарушений. YarTim (обсуждение, вклад) 10:13, 5 января 2022 (UTC)
Сейчас премодерации нет ни де-факто, ни де-юре. Ибо просматривают постфактум. И просматривают бегло, немало статей ускользает: вплоть до вандальных страниц, которые даже ошибочно снимают с КБУ, или статей на чистом английском языке, в которые ставят категорию на русском языке… Да и значительная часть новых статей — это де-факто заливки низкого качества пример, пример — Proeksad (обс.) 14:51, 6 января 2022 (UTC)
Ну, постфактум - это через несколько минут после создания, никто из читателей банально не успеет увидеть. Проблема, наверное, что просто всё очень дорого с т. з. трудозатрат кроме того, что есть сейчас. YarTim (обсуждение, вклад) 14:57, 6 января 2022 (UTC)
Такое обсуждение уже было по реализации схемы англовики в рувики. Где-то даже были графики, надо бы найти. С уважением, Iniquity20:57, 4 января 2022 (UTC)
@Iniquity: Если проводить новое исследование, то оно должно касаться каких-то новых аспектов, которые ранее не рассматривались. Например, выживаемость статей инкубатора. В противном случае, смысла в нём будет мало - я не думаю, что по сравнению с прошлым разом статистика радикально изменится. — Emaus (обс.) 07:46, 6 января 2022 (UTC)
@Emaus, я думаю, кстати, что изменится. У нас же запустили задачи для новичков, что повышает общее количество правок начинающих редакторов. И вообще система помощи появилась. Про Инкубатор очень крутая идея. С уважением, Iniquity07:51, 6 января 2022 (UTC)
Надо всё-таки, какие-то новые гипотезы рассматривать. Два предыдущих замера показали сходство, то есть, статистика стабильна, и, скорее всего, дальше тоже будет изменяться мало. — Emaus (обс.) 03:29, 8 января 2022 (UTC)
Википедия:Выживаемость статей/Граница автоподтверждённого - это то, как изменилось бы выживаемость статей группы АПОД, если бы были изменены требования к этой группе (сейчас - 4 дня и 15 правок). "Ошибка первого рода" - доля удалённых статей у АПОД, "Ощибка второго рода" - доля выживших статей у УЧ. Данные не на 100% точные, так как считались только правки в живых статьях, что отличается от расчёта, который делает движок. — Emaus (обс.) 07:46, 6 января 2022 (UTC)
Как насчет небольшой косметической (?) меры. Сейчас при переходе на отсутствующую страницу высвечивается Вы также можете создать такую страницу, помочь в этом может руководство для быстрого старта. Может дописать что-нибудь из серии: Для написания первых статей в Википедии можно использовать Инкубатор. Новые участники хотя бы узнают о его существовании — Proeksad (обс.) 14:51, 6 января 2022 (UTC)
Как именно переписать-то. Если что, то англовики в принципе нельзя сразу зайти и создать статью. Но мы можем дать варианты: создать, создать в инкубаторе, экспериментировать в песочнице, сделать правки в других статьях (то есть не три варианта как в англовики, а четыре) — Proeksad (обс.) 16:07, 6 января 2022 (UTC)
Можно было бы для анрегов сделать так, чтобы после нажатия «создать страницу» предлагались бы опции: «Создать в основном пространсве — существует вероятность немедленного удаления» и «создать в инкубаторе». DimaNižnik15:36, 8 января 2022 (UTC)
Там уже есть «Новых и начинающих пользователей приглашаем создавать статьи в Инкубаторе, где вам окажут необходимую помощь в написании ваших первых статей». Думаю, стоит как-то лучше оформить, чтобы бросалось в глаза. Kylain Aixter (СО) 18:29, 13 января 2022 (UTC)
Против. После введения такой меры, в Инкубаторе начнётся настоящий ад. Там и так не справляемся с многими статьями, так ещё дополнительные будут. Нужно просто что-то делать с ним (с Инкубатором): привлечь больше участников, улучшить руководства и что-либо ещё. А так, я бы просто рекомендовал новичкам (как это сделано в мастере статей) создавать статьи в пространстве Инкубатора (то есть, описать это в руководствах). Kylain Aixter (СО) 18:16, 13 января 2022 (UTC)
Если бы новички ещё открывали эти руководства... Стоит при попытке создания статей сразу давать ссылку на инкубатор. — Proeksad (обс.) 16:55, 17 января 2022 (UTC)
Насильно в инкубатор отправлять не нужно. Нужно определить, что топикстартер хочет этим улучшить? Как показало уже цитированное исследование минимальные шансы на выживание имеют статьи участников как зарегистрированных, так и анонимов, которые первой правкой сразу создают статью и которая часто сразу отправляется на КУ или КБУ. Если пустить их всех в инкубатор, то поток этих статей перераспределиться туда. Может лучшим решением будет вообще запретить создание статей участниками имеющими малое число правок. Самые малые флаги сейчас ВП:Автоподтверждённые участники (4 дня и 15 правок) и ВП:Загружающие (две недели и 20 правок) - это вполне достаточный срок чтобы почитать правила и опробовать имеющиеся инструменты. Таким образом если разрешить создавать первую статью начиная с автоподтвержденных ил загружающих можно снизить нагрузку на КБУ, а те выжившие статьи созданные сейчас участниками не имеющими такого флага будут созданы чуть позже, когда этот флаг им будет присвоен. По поводу анонимов действительно можно либо запретить им создавать статьи сразу в основном пространстве (только через инкубатор), либо, если это технически возможно конечно, разрешить им создавать статьи после совершения определенного лимита правок. У АНОН100 статьи преимущественно выживают. Atylotus (обс.) 11:39, 19 января 2022 (UTC)
Против, это дело проекта.— Arbnos (обс.) 14:49, 29 января 2022 (UTC)
Согласен, первый вариант самый удобный и простой, хотелось бы иметь эту возможность именно в таком виде. — evs 💬 13:22, 12 января 2022 (UTC)
За, очень полезное предложение. Pessimist (обс.) 18:50, 19 января 2022 (UTC)
