Мне нравятся работы некоторых современных художников, я была бы заинтересована попробовать создать про них статьи. Подскажите, пожалуйста, есть ли отдельные критерии значимости именно для современных художников и их работ в русской Википедии? Возможно, также где-то есть список признанных авторитетными источников относительно этой темы (особые сборники картин, энциклопедии и сайты)? Я, конечно же, изучу различные уже созданные страницы художников на предмет того, как на них подается значимость и какие источники используются. Но, если где-то уже есть "застолбленные" правила на этот счет, заинтересована "не изобретать велосипед", а придерживаться их. Заранее большое спасибо за помощь!?
Foxyra
(
обс.
)
11:40, 14 мая 2024 (UTC)
[
ответить
]
- ВП:КЗДИ
.
Rijikk
(
обс.
)
11:56, 14 мая 2024 (UTC)
[
ответить
]
- Изучить другие статьи, конечно, имеет смысл, но как образцы использовать их не очень правильно, потому что (
ВП:ДРУГИЕСТАТЬИ
) можно скопировать чужие ошибки, чужой ошибочный подход. В крайнем случае можно смотреть на статусные статьи. Нужно опираться на правила и руководства (коллеги привели выше).
Например, имеется ли значимость у
этого художника
?
Nikolay Omonov
(
обс.
)
18:44, 14 мая 2024 (UTC)
[
ответить
]
- Для работ нужно освещение в независимых и авторитетных источниках.
BilboBeggins
(
обс.
)
19:20, 14 мая 2024 (UTC)
[
ответить
]
- безусловно значимы действительные члены и
членкорры РАХ
, художники, чьи произведения находятся в коллекциях музеев уровня Третьяковки, Русского музея и Московского музея современного искусства, художники, чьё творчество подробно (лучше всего в форме персональных статей) разбирается в журналах ≪Диалог искусств≫, ≪
Артхроника
≫, ≪
Искусство
≫, ≪Артгид≫, ≪Кольта≫ и?т.?п. (журналах, авторами статей в которых являются авторитетные искусствоведы), художники, персональные выставки которых проходили на площадках уровня
ЦДХ
и
XL Галереи
. прочие художники могут быть значимы, а могут быть и нет (см. правило
ВП:КЗДИ
). есть
топ-50 самых влиятельных лиц в российском искусстве по версии журнала ≪Артхроника≫
, достаточно высокое место в этом списке, думаю, будет являться признаком значимости. списков авторитетных музеев, площадок и журналов/сайтов, наверное, нет (по крайней мере я не знаю об их существовании), а они были бы полезны, однако исчерпывающие списки всё равно составить затруднительно.??
Halcyon5
(
обс.
)
22:57, 14 мая 2024 (UTC)
[
ответить
]
В мобильной версии Википедии дизайн пометок о непроверенных правках, а также о просмотре стабильной версии статьи отображается как в десктоп-версии Википедии. Этот дизайн очень контрастирует с прежним. Кто-нибудь может объяснить как так получилось и когда вернут прежний дизайн для мобильной Википедии? ?
Gesanonstein
(
обс.
)
06:26, 12 мая 2024 (UTC)
[
ответить
]
Около месяца назад, мой бот перенял функцию автоматического отката, которой много лет занимался бот
Рейму Хакурей
?? (см.
Википедия:Форум/Архив/Общий/2024/03#Большое обновление антивандального бота
). На первых порах, принцип работы нового бота был похож на modus operandi Реймы: свежие правки оценивались с помощью википедийной системы
ML
(в народе ≪нейросети≫) ORES, подозрительные правки откатывались. Но как оказалось, у ORES есть недостатки: он устарел и уже не поддерживается разрабами Фонда. Надеюсь, что Фонд его не выключит в будущем, но кто знает? А замена ORES, названная LiftWing, пока совершенно не пригодна для использования, так как у неё очень много ложных срабатываний. Кроме того, случаются перебои и даже полные отключения ORES. Последний сбой длился около суток и вырубил не только всех антивандальных ботов, но и даже затронул викидвижок?? подсветку проблемных правок в списке свежих правок.
Так как я не могу повлиять на фондовских разрабов, решил пойти другим путём и создал собственный аналог ORES, работающий полностью независимо от систем Фонда. Разработка и тестирование первой версии окончено, сегодня запустил её на боевое дежурство. Это не замена ORES, обе системы работают параллельно и идеально дополняют друг друга. Что не обнаруживает ORES, обнаруживают мои алгоритмы и наоборот. По результатам тестов, объединённая система обнаруживает в два раза больше вандальных правок чем чистый ORES (использовавшийся Реймой или первой версией моего бота) и имеет более низкий процент ложных срабатываний. Но как у любой автоматической системы, ложные срабатывания всё равно будут.
Пользуясь случаем, решил перенести антивандальные функции на новую бото-учётку:
EyeBot
. Имя очень подходит к его деятельности?? обнаружению вандализма. Список всех автоматических откатов бот помещает здесь:
Участник:EyeBot/Отчёты/Автоматические откаты
. Сообщения об ошибочных откатах теперь подаются сюда:
Участник:EyeBot/Сообщения об ошибках
. Кому интересно участвовать в процессе проверки автоматических откатов, хочу предложить поместить эти страницы в список наблюдения. В будущем планирую перенести на эту учётную запись все другие антивандальные функции моего бота: автоматические блокировки, блокировки по запросу вандалоборцев, полузащиты и подачу запросов на
ВП:ЗКАБ
. --
Q-bit array
(
обс.
)
21:40, 10 мая 2024 (UTC)
[
ответить
]
- Это очень круто, спасибо. Мне тут ещё в укрочате написали, что грядёт
mw:Moderator Tools/Automoderator
- некий аналог реймы/клюбота, основанный на liftwing. Будем посмотреть.
MBH
22:41, 10 мая 2024 (UTC)
[
ответить
]
- Мы уже посмотрели на примере Реймы на что способен LW. Увы, совсем не на многое, если только в комбинации с чем-то и при том с очень высокими порогами (99+). Учитывая, насколько широк диапазон настроек в этой разработке (а значит и диапазон коэффициентов), боюсь, после её запуска для блокировки рувики не понадобится никакой РКН. При строгих настройках она будет откатывать в прямом смысле случайным образом.
Iluvatar
обс
23:09, 10 мая 2024 (UTC)
[
ответить
]
- Ну, как я понимаю, в отличие от многих нововведений фонда, это будет необязательной штукой: нас никто не обяжет её запускать (и анвику тоже), т.к. у нас есть лучшие боты.
MBH
23:13, 10 мая 2024 (UTC)
[
ответить
]
- Но ведь кто-то запустит. Особенно в малых разделах, на агностике. Даже странно. Неужели команда ML за год не провела анализ точности своей разработки? Или строгость коэффициента будет регулироваться в диапазоне 99.0-99.9?
Iluvatar
обс
23:19, 10 мая 2024 (UTC)
[
ответить
]
- Честно говоря, от ≪качества≫ этого LiftWing я тихо фигею. Вот
такую правку
LiftWing оценил
аж в 0.981
из-за чего Рейма даже подала запрос на ЗКАБ. Из-за этой единственной правки с того IP. Может вообще отключить LiftWing в Рейме? Он только резко увеличивает количество ложных запросов на ЗКАБ. --
Q-bit array
(
обс.
)
07:47, 11 мая 2024 (UTC)
[
ответить
]
- ЗКАБ Рейма подаёт только за повторные правки. Посмотри удалённый вклад.
MBH
09:20, 11 мая 2024 (UTC)
[
ответить
]
- У того IP нет ни одной удалённой/скрытой правки и ни одного срабатывания фильтра. И в /64 диапазоне нет. --
Q-bit array
(
обс.
)
11:13, 11 мая 2024 (UTC)
[
ответить
]
- Ну, там при обнаружении подозрительной правки вызывается очень простая функция, в которой и ошибиться-то негде:
if
(
suspicious_users
.
Contains
(
user
))
{
//репортим
}
else
suspicious_users
.
Add
(
user
);
И пополняется она только в этом месте. Не знаю, как могло зарепортить первую правку.
MBH
14:33, 11 мая 2024 (UTC)
[
ответить
]
- Совсем бесполезным лв не назовёшь:
эта правка
проскочила проверку оресом, паттернами и фильтрами правок и была обнаружена лишь лифтвингом (да, я вижу, что её отменил твой бот).
MBH
00:28, 12 мая 2024 (UTC)
[
ответить
]
- Даже испортившиеся часы дважды в день показывают правильное время. Если у LiftWing на одно правильное обнаружение приходится десять ложных срабатываний на совершенно ровном месте, то толку от этого механизма мало. --
Q-bit array
(
обс.
)
09:50, 12 мая 2024 (UTC)
[
ответить
]
- Это действительно круто! Спасибо большое за такую важную вещь!
Rampion
11:33, 11 мая 2024 (UTC)
[
ответить
]
Коллеги, я уже инициировал
обсуждение на форуме Викиданных
, но туда всё же мало кто ходит, а это вопрос не частный, затрагивающий множество статей. На Викиданных тенденция к созданию отдельных страниц на всяческих родственников знаменитостей (например, на новорождённых детей поп-звёзд), это соответствует тамошним правилам. В результате эти родственники во множестве вылезают у нас в инфобоксах в виде красных ссылок, а красные ссылки, как известно, нужны для того, чтобы кто-то создал на их месте статьи - что регулярно и происходит. Благодаря дискуссии на том форуме выяснилось, что есть возможность вручную подавить этот вывод для данной статьи, но это, как вы понимаете, очень локальное решение, и большинство участников о такой возможности даже не знает. Я вижу два возможных решения: 1) в соответствующих полях всё, что приходит с Викиданных, выводить чёрным без ссылки, а ссылки (на написанные или ненаписанные статьи) вводить только руками; 2) вообще не выводить эти поля в карточку по умолчанию, включая их вывод для конкретной статьи. Исходно я предлагал третий вариант: выводить поля в карточку только при наличии статей об этих людях в нашем разделе, - но говорят, что это вряд ли можно реализовать.
Андрей Романенко
(
обс.
)
12:06, 8 мая 2024 (UTC)
[
ответить
]
- Я недавно спрашивал у @
putnik
, можно ли сделать как-то так, чтобы ссылки в определённых свойствах не выводились вообще (там было про лево/правостороннее движение автомобилей) ? думаю, это вполне решение для такой ситуации.
stjn
12:12, 8 мая 2024 (UTC)
[
ответить
]
- По-моему, есть возможность для инфобоксов задать в общем виде, какие поля в отсутствие заполнения у нас подтягиваются из Викиданных, а какие в любом случае нет. Вот для родственников хорошо бы этого не делать (разве что речь о монархических династиях).
Deinocheirus
(
обс.
)
12:32, 8 мая 2024 (UTC)
[
ответить
]
- Поддерживаю вариант с полным подавлением родственников для всех, кроме монархов. Критически важных можно вписывать в карточку вручную. Хотя, если подумать, то и монархов и прочих дворян тоже можно вписывать вручную. ?
Cantor
(
O
)
13:55, 8 мая 2024 (UTC)
[
ответить
]
- И сдаётся мне, в случае реализации этого варианта ≪проблемные≫ категории со ссылками из ВД (
эта
и
эта
) разгрузятся как минимум наполовину.
(Для истории: сейчас там 1025 и 53 870 включений соответственно.)
?
Cantor
(
O
)
13:55, 8 мая 2024 (UTC)
[
ответить
]
- А почему удалять вообще всех родственников? Для некоторых связь с родственниками важна для статьи. И у нас во многих статьях почему-то есть информация в преамбуле. Например, даже про Михаила Ефремова.
- По-моему, в карточке информация более уместна, чем в преамбуле.
BilboBeggins
(
обс.
)
12:00, 9 мая 2024 (UTC)
[
ответить
]
- Я предлагал в шаблонах сделать отдельный параметр, позволяющий включать/выключать вывод родственников. Допустим, по умолчанию не выводятся, а при задании параметра ??выводятся. Это будет более универсальным решением. Хотя есть проблема в том, что если мы сейчас отключим вывод, придётся вручную править все статьи о той же знати (я, например, в своих статьях часто не заполнял параметры, а настраивал всё в ВД). Хотя можно действительно подавлять вывод, если статьи в нашем разделе не существует (если это возможно). Но всё равно даже в таком случае нужно сделать параметр, который позволит включить вывод там, где это нужно.
Vladimir Solovjev
обс
14:24, 8 мая 2024 (UTC)
[
ответить
]
- Подавлять полностью целое свойство по всей википедии не нужно. У вымышленных персонажей от этого нет никакого вреда и избыточного заполнения?? элементы создаются в исключительных случаях. Правильным было сделать универсальное решение для каких угодно свойств?? параметр, отключающий вывод элементов, у которых нет русских статей. Делать от обратного?? параметр для отключения исключений?? тоже сомнительное решение.
Solidest
(
обс.
)
17:49, 8 мая 2024 (UTC)
[
ответить
]
- В перспективе карточки персон надо разбить на модульные блоки. ≪Общие сведения≫, ≪деятельность как спортсмена≫, ≪деятельность как писателя≫, ≪деятельность как политика≫ и?т.?п., а также по необходимости ≪родственники≫. Я вижу идеальное решение примерно таким {{персона|писатель|спортсмен|политик|родственники <именованные параметры> }}. То есть при вызове указывать блоки данных, которые надо показать. Но это дело далекого будущего. Пока же можно придумывыать те или иные решения вида отдельного параметра ≪показать/подавить родственников≫ или отображать только синие ссылки. Причем вариант параметра должен быть opt-in, потому что по дефолту все будут забывать его ставить, а информация в ВД появляется и после создания статьи, что уже никто не отслеживает.
Abiyoyo
(
обс.
)
12:36, 9 мая 2024 (UTC)
[
ответить
]
- По хорошему да, инфобоксы должны собираться из модулей. Вопрос только в том, кто это будет делать. У нас сейчас вообще с инфобоксами проблема в том, что стремятся сделать их максимально универсальными, в итоге в них чего только не навешивается. Один только монстрообразный
{{
Государственный деятель
}}
чего стоит. Гораздо удобнее будет, если сделать шаблон-надстройку, к которому подключать только те модули, которые нужны. Да и поддержка станет проще, ибо не нужно будет при очередном изменении функциональности править кучу шаблонов.
Vladimir Solovjev
обс
13:18, 9 мая 2024 (UTC)
[
ответить
]
- Как бы в этой ≪прекрасной Википедии будущего≫ и так конской длины карточки (особенно для госдеятелей жуть) не сделать ещё в три раза длиннее… (когда с учётом половины посещений с мобильного надо бы наоборот).
stjn
22:05, 10 мая 2024 (UTC)
[
ответить
]
- Возможным путём решения проблемы длинных инфобоксов могли бы стать сворачиваемые по умолчанию модули. Правда для мобильной версии это, как я понимаю, работать не будет, но для настольной ? вполне себе.
Vladimir Solovjev
обс
08:00, 11 мая 2024 (UTC)
[
ответить
]
Сразу скажу, что я не понял куда просить, поэтому прошу здесь.
В общем, в статье про
кавказские письменности есть таблица
, где не очень понятно некоторое содержимое.
Не нашёл информацию про "маленькую
?
" (даже на клавиатуре МФА нет такого символа), тем более "
t??
", где ? уменьшена с помощью вики. Также непонятен кружочек внизу таблицы, где я сделал ссылку на "кружок сверху". Такие "моменты" я обозначил надписью "что это?". Спасибо за помощь. ?
GagogaSus
(
ОУ
)
22:52, 4 мая 2024 (UTC)
[
ответить
]
За последний ряд лет, когда у меня появился телефон с нормальной камерой, я сделал в поездках множество снимков разных объектов: дворцы, корабли, храмы и всякое такое. Там тысячи снимков и 80 ГБ в сумме. Я бы хотел загрузить многое из этого на склад, думаю, там есть достаточно фотографий, которые лучше, чем всё, что сейчас имеется на складе, но качественная загрузка одного фото на склад, с приведением ссылок в описании и категоризацией (часто нужную ветку категорий надо ещё создать), занимает где-то полчаса и у меня нет столько времени. Есть ли способ выложить всё это куда-то в интернет, чтобы заинтересованные лица могли сами грузить оттуда на склад то, что захотят? Я знаю про фликр, но году в 12-м (когда я им короткое время попользовался) он был сильно ограничен по количеству/объёму загружаемых файлов, 80 гигов я вряд ли на него так просто загружу. Есть ли ещё варианты решения данной проблемы?
MBH
17:57, 4 мая 2024 (UTC)
[
ответить
]
- Есть множество людей на Складе, которые загружают, не категоризируя. Это раздражает, да, но это лучше, чем не загружать вообще. Главное - чтобы в названии файла или в описании была информация, что это и куда категоризировать.
Vcohen
(
обс.
)
18:23, 4 мая 2024 (UTC)
[
ответить
]
- Я бы поспорил с таким подходом. Разгребать на Викискладе ещё более некому, чем тут. Вот прямо сейчас в категории
Commons:Category:Unidentified men
под 30 тысяч снимков, и большинство из них вполне идентифицируемые личности, но кто будет разбираться?
Андрей Романенко
(
обс.
)
01:18, 6 мая 2024 (UTC)
[
ответить
]
- Часто загружают фотографию (я не говорю про массовые заливки), чтобы тут же использовать ее в статье. Если снимок используется в каком-то языковом разделе в статье, то понятно, кто это. Такой процесс можно даже автоматизировать. Только в большинстве случаев результат будет просто "Писатели из России" или "Политики из Казахстана", потому что более частной категории для данного человека все равно нет.
Vcohen
(
обс.
)
07:24, 6 мая 2024 (UTC)
[
ответить
]
- Да и это уже неплохо. Там и так можно многое начерно раскидать по странам, и дальше таким фото уже будет больше внимания.
Я, например, всю Россию, может, и не смотрю, но те неопознанные, которые сваливаются в категории СПб и Москвы, периодически просматриваю.
И конкретно нам, русскоязычному сообществу, имеет смысл смотреть на фото
с кириллическими названиями
, которые уж точно никто кроме нас разбирать никогда не станет.--
Kaganer
(
обс.
)
16:20, 10 мая 2024 (UTC)
[
ответить
]
- Вы можете грузить в категории локаций, например - они, как правило, уже созданы как минимум для городов. --
Екатерина Борисова
(
обс.
)
23:50, 4 мая 2024 (UTC)
[
ответить
]
- На Викисклад можно грузить не по одному файлу, а сразу пакетом. Это можно сделать через мастер загрузки -
commons:Special:UploadWizard
. Также есть специальные инструменты загрузки
commons:Commons:Upload_tools/ru
. Свои советы по загрузке я описал тут
ru:b:Пакетная загрузка изображений на Викисклад
?
Butko
(
обс.
)
04:50, 5 мая 2024 (UTC)
[
ответить
]
- Если детальную категоризацию делать сложно, то поставьте хотя бы одну категорию, которая будет отображать географическую и хронологическую привязку. Например,
commons:Category:2017 in Moscow Oblast
- потом будет проще разобрать другим участникам ?
Butko
(
обс.
)
04:56, 5 мая 2024 (UTC)
[
ответить
]
- Хронологическая полезна далеко не всегда. Стоит подлодка как музейный экспонат - её интерьеры выглядят одинаково в любой месяц любого года. Я хронологически не категоризую.
MBH
09:33, 5 мая 2024 (UTC)
[
ответить
]
- Я согласен, эта ветка в общем случае совершенно бесполезна (только для частных типа ≪события такого-то года≫). Подобные категории можно ставить просто ботом по пересечению даты и места, но зачем? А вот место надо указывать.
A
ndy
V
olykhov
↔
09:37, 5 мая 2024 (UTC)
[
ответить
]
- Относительно категоризации:
- рассказать/показать общественности, как эти файлы исходно категоризованы.
Часть категорий наверняка можно соотнести с уже имеющимися на Викискладе, и в этом помогут другие участники (я, например).
- сделать на базе этой категоризации собственную систему пользовательских "категорий фотографа" на Викискладе (с названиями вида "Photographs of ... by MBH",
пример
) - по годам, по путешествиям, по темам...; такие категории принято помечать как скрытые шаблоном
{{user category}}
- Лично я придерживаюсь принципа, что крайне желательно, чтобы любое фото было категоризовано минимум по трём признакам, которые бы отвечали на вопросы "что снято?", "где снято?", "когда снято?" (для видовых фото - желательно, чтобы с точностью до сезона). Эти же сведения должны, по хорошему, присутствовать и в описании файла.
- заранее проверить и подготовить метаданные (убрав лишнее и добавив туда, к примеру, информацию об авторстве и лицензии);
лично я использую
Exif Pilot
с пакетным плагином
- При загрузке придется генерировать какие-то описания для каждого снимка, можно не очень детальные, но хотя бы примерно его описывающие.
- Естественно, лучше для каждой серии создать файл с описаниями заранее, и затем подсунуть на вход пакетному загрузчику.
- Если выбранный загрузчик это позволяет, я бы советовал генерировать описания сразу по-русски и по-английски
- Продумать систему именования файлов, т.к. дефолтные названия типа DSC9865243587 на Викискладе неприемлемы. Если сейчас имена файлов включают дату, то я советую от этого не отказываться и сохранять её в имени файла.
- Например, если серия фото какого-то объекта (или из какой-то поездки) имеет названия файлов вида
20240507_094116.jpg
, то я бы их превратил во что-то вроде Тема_2024-05-07_##.jpg или Тема_2024-05-07_by_MBH_##.jpg, где ## - порядковый номер в серии.
- Переименовывать при этом ничего не нужно - нужно добавить соответствия в тот же самый файл для пакетного загрузчика.
- Основная идея - сгенерировать "описательные названия" минимально трудозатратным образом, и так, чтобы они с гарантией ни с кем больше не пересеклись.
- Называть файлы кириллицей или латиницей - дело личного выбора.
- Загрузить весь массив снимков (и прокатегоризовать уже ранее загруженные), перенеся свою категоризацию "один в один";
можно использовать какой-то свой скрипт через API, или альтернативный пакетный загрузчик типа
Pattypan
.
Если для каких то групп фото удалось сразу найти готовое соответствие в основном массиве категорий, то их стоит сразу же помещать и туда тоже
- --
Kaganer
(
обс.
)
15:55, 10 мая 2024 (UTC)
[
ответить
]
- Я бы предложил так:
- - Если есть международная карточка, то оплатить доступ к flickr на месяц, и залить туда сразу всё, чтоб фото были в большем количестве мест в интернете, и если из commons чего-нибудь выкинут по причине "Буратино в кадре"
- - Заходить в категории по населённым пунктам. Добавить вручную в них {{Wikidata Infobox}}, оно добавит ссылку "Загрузить файлы в эту категорию"
- - Грузить через Upload Wizzard, без обработки. Если фото в RAW, то конвертировать не в JPG, а в TIFF с сжатием ZIP
- Названия-описания всё равно придётся генерировать самому, и это самая трудная для меня задача. Я сделал для этого скрипт на python
trolleway/placejpg: python docker/termux script for upload to wikimedia commons photos of buildings and vehicles (github.com)
, но мне не удалось скомпоновать его в нормальную программу для Windows.
Svetlov Artem
(
обс.
)
09:34, 13 мая 2024 (UTC)
[
ответить
]