Ссылка-сокращение ВП:Ф-О

Википедия:Форум/Общий

Материал из Википедии — свободной энциклопедии
< Википедия:Форум
(перенаправлено с «Википедия:Ф-О»)
Перейти к навигации Перейти к поиску
Ссылка-сокращение ВП:Ф-О
Форум — Общий
Файл
Добавить тему
Архив (последний)
Обсуждение тем, связанных с Википедией, но не подходящих для других разделов форума, других обсуждений и страниц обсуждения статей.
Поиск по всему
форуму и архиву
Актуально
Голосования
Выборы, присвоение и снятие флагов
Заявки на флаг ПИ
  • Arachis99 (ПИ) — (?) заявка подана
Список изменений в правилах

Наличие шаблонов проектов важнее оценок в этих шаблонах[править код]

У нас существует негласная договорённость что нельзя проставлять ботом на страницы обсуждения шаблоны проектов {{Статья проекта}} без одновременного указания параметров оценок качества и значимости статей. А по какой причине такое положение появилось и есть ли от этого ограничения польза для проектов?

Наличие самого шаблона помогает со сбором статей по одной тематике в одну категорию, что влияет на отслеживание статей множествами способов и инструментами. Например помогает в PetScan делать выборки (правда сейчас это скорее про enwiki, где разрешают массово ставить шаблоны без оценок и там подключение к проектам статей более полноценно). Или например с недавних пор у нас публикуются ежедневные списки патрулирования в дискордах проектов компьютерных игр и музыки, где установлены эти шаблоны. Это помогает следить за правками от анонимов. Или можно просто проследить какой из проектов наиболее крупный по статьям в Википедия:Совет вики-проектов/Каталог проектов/Полный. И уверен, что с более распространённой практикой простановки шаблонов проектов, таких инструментов становилось бы больше.

А существует ли равноценная польза от первоочередной установки оценок качества и значимости в этих проектах? Кому-то эти оценки помогают существенно ориентироваться в рамках проектов так, что статьи без оценок являются нежелательными внутри проекта? Мне кажется что важнее объединить статьи одной тематики в первую очередь, а только потом указать их характеристики.

Или как относиться к тому, что проекте музыки без оценок сейчас 7700 статей, у компьютерных игр 235 и эти цифры, судя по вебархиву, существенно не меняются с годами. Получается что эти оценки внутри проектов не настолько значимы, что их заполнение не увеличивается со временем? Поэтому что изменится, если эти цифры неизвестных оценок увеличатся на 10 тысяч и может ли это хоть сколько расцениваться ненужным и вредным для проекта? Лично для себя я вижу это однозначной пользой. В той ситуации, когда изменения этих шаблонов пользователями происходят весьма вяло, вес прикрепления статьи к проекту существенно больше, чем обязательное требование заполнения оценок. Да мне и кажется что с практической точки зрения, с большей вероятностью созданные страницы обсуждения с готовым шаблоном скорее побудят заполнять параметры оценок, чем кто-то будет создавать страницы обсуждений с шаблоны с оценками с нуля. С моей точки зрения это негласное правило просто мешает наполнению проектов, с сомнительной пользой, да и прямо говоря с неясной целью (все статьи оценены и теперь таблица аккуратно заполнена и кто-то может однажды в неё заглянуть и?).

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

В общем предлагаю отказаться от обязательного требования установки оценки про добавлении шаблонов проекта, и отдать в первую очередь приоритет добавлению самого шаблона, а только потом заполнению его оценок. И таким образом разрешить автоматизированное подключение статей к проектам ботами. Solidest (обс.) 13:09, 16 мая 2024 (UTC)[ответить]

  • Вот именно чтобы ботами этого не делалось, такое положение и установлено. Оно фиксирует хрупкий консенсус между теми, кто хочет заниматься статистикой проектов (подсказка: их меньшинство), и теми, кому «эта возня нафиг не сдалась» и кто не хочет наблюдать засорение списков наблюдения бессмысленными с их точки зрения правками. — Cantor (O) 13:39, 16 мая 2024 (UTC)[ответить]
    • Те кто занимается статистикой проекта — это те, кто следят за оценками статей или вообще любые участники проектов? Если первые, то хотелось бы услышать от них как они используют эти оценки, и как на них скажется добавление нескольких тысяч статей без оценок. Если вторые, то они от предложения выигрывают.
      Про тех кому «эта возня нафиг не сдалась» не очень понял — это те, кто не участвует в проектах? Массовое создание страниц обсуждений с шаблонами на их список наблюдения не повлияет — и так как неподключенными к проектам остаются старые забытые статьи разных авторов, а у всех крупных и новых статей шаблоны проектов в основном уже стоят. И так как это и будет всего 1 раз и СО можно будет отфильтровать в списке наблюдения в тот момент (да и правки ботов и создания новых страниц тоже можно будет одномоментно скрыть). Но и в общем говоря, списки наблюдения отдельных авторов играют не первостепенную роль, если это препятствует множеству участников проектов использовать их основополагающий функционал. Так что это причиной «хрупкого консенсуса» являться не может, одна из описываемых сторон к ситуации просто отношения не имеет. Solidest (обс.) 14:41, 16 мая 2024 (UTC)[ответить]
      • Я не могу ответить на ваш первый вопрос, потому что достоверно не знаю, кто они, и тем более не слежу за их деятельностью. Любое предыдущее обсуждение этих шаблонов вызывало жёсткое неприятие участников, которые именно пишут статьи, а не «меняют циферки» на страницах обсуждений (это, как и в предыдущей моей реплике, вольная цитата из одной из прошлых дискуссий). Если у меня будет время (если!), я попробую поискать в архивах, но не гарантирую, что смогу этим заняться.
        Далее. Я отнюдь не уверен, что участников проекта, пользующихся функционалом, как вы выразились, — действительно «множество»: в предыдущих дискуссиях я видел двух-трёх, ну максимум пять человек, выступавших за расстановку шаблонов, и гораздо большее количество их оппонентов. Пока я могу назвать только одного человека, который на моей памяти реально бы работал со статистикой проекта, — это коллега Bff, но он как раз и не входит в число тех, кто агитирует за массовую расстановку шаблонов. Прямой зависимости между позицией участника в отношении этих шаблонов и тем, участвует ли он в каком-либо проекте, как мне видится, тоже не существует: мы оба в одном проекте, но он этими шаблонами пользуется, а мне они скорее мешают. — Cantor (O) 15:09, 16 мая 2024 (UTC)[ответить]
        • Это не обсуждение о том нужен или нет механизм оценки статей и привязки к проектам, он уже есть и является основой крупных проектов на википедиях всех языков. Здесь обсуждение о том, что оценивание статей по значимости и качеству в этих проектах должны быть вторичными («циферки на страницах обсуждений») по сравнению с наличием самого шаблона. Противникам этих шаблонов, если у них это вызывает противоречивые чувства, следует начинать новые обсуждения о необходимости всей системы привязки статей к проектам, а заодно и существовании проектов на википедии как таковых (одно с другим прямо связано), где и им дружно скажут что они смотрят в прошлое. Если вам это не нужно или если вы этого не понимаете, то перед тем как декларировать что это никому не нужно, иногда лучше узнать почему это появилось, зачем это существует и как используется.
          Участников, пользующихся функционалом — много. Скорее всего даже больше, чем читают этот форум. И внутри тематических дискордов хватает (опять же с ежедневными сообщениями бота работают несколько человек и благодарят его создателя @A particle for world to form за создание, который кстати на днях вручную ставил эти шаблоны сотням статей, чтобы бот работал нормально и именно это не оптимальный процесс работы со статьями проекта и это есть причина этого обсуждения) и внутри общего дискорда википедии об этих шаблонах тоже постоянно поднимается речь. И как я уже писал потенциально этот механизм должен потенциально когда-нибудь стать основным по отслеживанию статей в проектах, как это уже сделано на других языках, вместо урезанного функционала {{Музыка:Общие проверки}}, который позволяет следить только за статьями с карточками и нав шаблонами. Но это опять же другой разговор.
          > Я не могу ответить на ваш первый вопрос, потому что достоверно не знаю, кто они, и тем более не слежу за их деятельностью.
          Поэтому просьба обсуждать и аргументировать здесь необходимость обязательного наличия оценок в шаблонах для проектов, а о существовании самой системы шаблонов выносить обсуждение в другую тему. Solidest (обс.) 15:46, 16 мая 2024 (UTC)[ответить]
          • Что ж, вижу, мы друг друга не понимаем. Отмечу только, что переход на argumentum ad hominem свидетельствует о слабости позиции того, кто это допускает. — Cantor (O) 15:58, 16 мая 2024 (UTC)[ответить]
            • Когда вам прямо указывают на ваш повторяющийся ошибочный подход, который вы притягиваете в обсуждение, лишь косвенно связанное с тем, о чём вы говорите, то странно пенять на риторику и рассказывать о слабости чужой позиции. Solidest (обс.) 16:10, 16 мая 2024 (UTC)[ответить]
  • Такое ограничение возникло, потому что имелись участники, которые квадратно-гнездовым способом расставляли плашки неактивных проектов и ничего в статьях при этом не делали. Помимо того, что такая деятельность мешает (например, СО статьи становится синим, что вводит в заблуждение: ожидаешь увидеть вопрос, а видишь плашку мёртвого проекта; кроме того, расставители плашек напрочь забивают проектные списки наблюдения (пример)), она ещё отвлекает внимание на объяснение участникам, что то, что они делают - имитация деятельности. Поэтому был выработан консенсус: плашки должны ставиться или автором статьи (создал - имеет право), или осознанно. Если ПРО:Музыка хочет расставить свои плашки по статьям, за которыми следит, нужно в проекте провести обсуждение (соответственно, проект-хозяин плашек должен быть активным), выработать консенсус и потом, со ссылкой на него, расставить плашки. Против этого возражать вряд ли кто будет. Если плашка - инструмент, то она должна использоваться и способствовать улучшению статей. А иначе так будут учётки ходить по СО и расставлять там плашки условного Проект:Хорватия, закрытого восемь лет назад. PS. Чтобы отслеживать статьи по категориям, не обязательно заморачиваться с плашками, можно просто использовать категории вида "ХХХ по алфавиту", этот способ гораздо удобнее и требует меньших телодвижений. ~ Всеслав Чародей (обс) 18:36, 16 мая 2024 (UTC)[ответить]
    • Ретроспективно глядя на ситуацию, кажется что проблема была в самих проектах, которые имели систему оценок, а не в наличии плашек в статьях. Но кажется что и сейчас было бы не лишним установить ограничение на то, каким проектам разрешается их иметь свои плашки, например по количеству активных участников или по количеству статей в сумме, и можно учитывать статус неактивности, который сейчас проставляют проектам на главную страницу. Но в общем не согласен с тезисами:
      > такая деятельность мешает (например, СО статьи становится синим, что вводит в заблуждение: ожидаешь увидеть вопрос
      И это снова про само существование этих шаблонов. Я не понимаю как разница в синей/красной ссылке на СО может хоть кому-то в чём-то мешать. В 90 % на этих СО оказываются неактуальные обсуждения 15-летней давности, либо бессмысленные фразы от анонимов. Зачем туда ходить за этим? СО создана для обсуждений и технической атрибутики, а не для поощрения любопытства и последующего разочарования за ним. И с моей точки зрения — именно объяснение участникам, что прикрепление плашек проектов является имитацией деятельности и является имитацией деятельности. Для первых это внутрипроектное слежение, а для вторых это просто ворчание.
      > забивают проектные списки наблюдения
      Вообще тот кто добавлял плашки отдельных стран озёрам всё делал правильно. Особенно учитывая что ставились и уровень статей их значимость. Это очевидная польза для отслеживания, а не вред. А то, что бот не способен это фильтровать — это проблема отслеживающего бота. И вот такие откаты из этого списка уже похожи на вредительство с заходом на ВП:МОЁ.
      > расставлять там плашки условного Проект: Хорватия
      У закрытых проектов обычно удаляются эти плашки: Википедия:Совет вики-проектов/Каталог проектов/Закрытые (и обычно это мелкие проекты, у которых их изначально и не было или и не должно было быть).
      > Если ПРО:Музыка хочет расставить свои плашки … Против этого возражать вряд ли кто будет.
      Вот буквально на днях такой вопрос с массовой простановкой плашек стоял в проекте компьютерных игр и преткновением стал обсуждаемый здесь консенсус про обязательную оценку статей при простановке этих плашек. Я был готов этим заняться и это было бы очевидно полезно для проекта, но мне не нужны в след слова о том, что по текущему консенсусу это делать нужно только с параметрами оценок сомнительной пользы, и что нельзя автоматизировать.
      > Чтобы отслеживать статьи по категориям, не обязательно заморачиваться с плашками
      Я про это написал когда упомянул шаблон общих проверок. Эти категории заполняются через механизм в карточках или нав шаблонах. Шаблоны ставятся не всегда и не везде. Категории ставятся иногда неправильно или не ставятся совсем. С текущей системой невозможно находить разом все статьи одной тематики. Их можно находить через изощренные способы (типа сканирования других категорий или викиданных), но с получаемыми данными ты ничего не сможешь сделать, так как у нас не приветствуется массовое проставление этих шаблонов без оценок. И вручную само собой никто не будет ставить это в сотни статей.
      И вообще раз здесь продолжает обсуждаться само существование этих плашек (что не является вопросом), а не необходимость в данных об оценках. И так как текущая ситуация с этими плашками — ака «хрупкий консенсус»/полумера мало полезен и с одной и с другой стороны. Раз всё ещё остаются люди несогласные с существованием оценок статей на страницах обсуждений (и подозреваю мечтающих вернуться к повсеместной простановке 50 вариаций шаблонов-заготовок внизу страниц). Может быть стоит провести опрос по удалению оценок статей с рувики у проектов вообще или наоборот к полной свободе по простановке этих шаблонов? С одной стороны будет отслеживание дедовскими методами как в 2007, красные ссылки на СО и кристально-чистые списки наблюдения у полторы землекопов, а с другой и современное отслеживание, и перспективы по развитию инструментов и полная статистика внутри одной тематики на всей википедии? (можно считать это риторическим вопросом) Solidest (обс.) 20:32, 16 мая 2024 (UTC)[ответить]
    • > можно просто использовать категории вида "ХХХ по алфавиту"
      Не во всех проектах это возможно. Например, в нашем проекте при таком подходе из сферы внимания вылетают почти все разработчики и издатели, потому что у них в качестве карточки используется простая {{Компания}} (сюда же люди и косвенно связанные темы) — то есть мы их даже не патрулировали! Решения два: в таких статьях проставлять либо что-то на СО, либо что-то в саму статью. Первое вроде бы проще и аккуратнее, поэтому я проставил (руками с простановкой уровня-важности) недостающие плашки на СО и написал бота, который ищет неотпатрулированные статьи именно по ним. ~A particle for world to form 21:29, 16 мая 2024 (UTC)[ответить]
  • В целом, конечно же, наличие шаблонов проектов не важнее оценок в этих шаблонах. Но в остальном этот вопрос имхо решается просто: если у проекта, в котором больше 5 (10? не суть) активных участников, есть выраженный этими 5 участниками консенсус на ковровую простановку плашек без уровней, и этот консенсус зафиксирован сторонним от проекта участником (не так, что Всеслав Чародей пишет о консенсусе в проекте ВО) — то такую ковровую простановку плашек надо разрешить.
    Проблема с плашками состоит в том, что когда-то давным-давно проектные плашки расставляли (к своему стыду я тоже к этому руку приложил) любые проекты независимо от числа участников. Это вызывало разумные возражения, что активности в проекте нет — а плашки на тысячах статей есть. Но в случае с активными проектами, такие как «Водные объекты», «Футбол», «Музыка» или «Компьютерные игры», такие возражения неприменимы — и эти проекты могут ставить плашки по своему усмотрению. Другое дело, что это должно быть итогом нормального обсуждения внутри проекта, а не волюнтаризма одного человека, см. ВП:МНОГОЕ. stjn 21:29, 16 мая 2024 (UTC)[ответить]

Как определить значимость современного художника?[править код]

Мне нравятся работы некоторых современных художников, я была бы заинтересована попробовать создать про них статьи. Подскажите, пожалуйста, есть ли отдельные критерии значимости именно для современных художников и их работ в русской Википедии? Возможно, также где-то есть список признанных авторитетными источников относительно этой темы (особые сборники картин, энциклопедии и сайты)? Я, конечно же, изучу различные уже созданные страницы художников на предмет того, как на них подается значимость и какие источники используются. Но, если где-то уже есть "застолбленные" правила на этот счет, заинтересована "не изобретать велосипед", а придерживаться их. Заранее большое спасибо за помощь!— Foxyra (обс.) 11:40, 14 мая 2024 (UTC)[ответить]

Что случилось с дизайном мобильной версии Википедии?[править код]

В мобильной версии Википедии дизайн пометок о непроверенных правках, а также о просмотре стабильной версии статьи отображается как в десктоп-версии Википедии. Этот дизайн очень контрастирует с прежним. Кто-нибудь может объяснить как так получилось и когда вернут прежний дизайн для мобильной Википедии? — Gesanonstein (обс.) 06:26, 12 мая 2024 (UTC)[ответить]

  • @Jon (WMF) changed the design without any prior notice to the communities with FlaggedRevs / изменил дизайн без какого-либо оповещения сообществ, где используется FlaggedRevs, см. phab:T364587. Когда это будет исправлено, пока непонятно. stjn 11:40, 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: Пожалуйста, проверь свой код внимательней, откуда-то эти запросы о разовых правках же идут. Вот ещё один совсем свежий случай: [1] + [2]. И там точно была одна единственная правка, специально перепроверил. Или вот: [3] + [4]. -- Q-bit array (обс.) 20:05, 11 мая 2024 (UTC)[ответить]
                    • Я отрефакторил код, эта функция действительно вызывалась дважды в случае лифтвинг-срабатывания, будем посмотреть. MBH 21:25, 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)[ответить]
    • Я согласен, эта ветка в общем случае совершенно бесполезна (только для частных типа «события такого-то года»). Подобные категории можно ставить просто ботом по пересечению даты и места, но зачем? А вот место надо указывать. AndyVolykhov ↔ 09:37, 5 мая 2024 (UTC)[ответить]
  1. Относительно категоризации:
    • рассказать/показать общественности, как эти файлы исходно категоризованы. Часть категорий наверняка можно соотнести с уже имеющимися на Викискладе, и в этом помогут другие участники (я, например).
    • сделать на базе этой категоризации собственную систему пользовательских "категорий фотографа" на Викискладе (с названиями вида "Photographs of ... by MBH", пример) - по годам, по путешествиям, по темам...; такие категории принято помечать как скрытые шаблоном {{user category}}
    • Лично я придерживаюсь принципа, что крайне желательно, чтобы любое фото было категоризовано минимум по трём признакам, которые бы отвечали на вопросы "что снято?", "где снято?", "когда снято?" (для видовых фото - желательно, чтобы с точностью до сезона). Эти же сведения должны, по хорошему, присутствовать и в описании файла.
  2. заранее проверить и подготовить метаданные (убрав лишнее и добавив туда, к примеру, информацию об авторстве и лицензии); лично я использую Exif Pilot с пакетным плагином
  3. При загрузке придется генерировать какие-то описания для каждого снимка, можно не очень детальные, но хотя бы примерно его описывающие.
    • Естественно, лучше для каждой серии создать файл с описаниями заранее, и затем подсунуть на вход пакетному загрузчику.
    • Если выбранный загрузчик это позволяет, я бы советовал генерировать описания сразу по-русски и по-английски
  4. Продумать систему именования файлов, т.к. дефолтные названия типа DSC9865243587 на Викискладе неприемлемы. Если сейчас имена файлов включают дату, то я советую от этого не отказываться и сохранять её в имени файла.
    • Например, если серия фото какого-то объекта (или из какой-то поездки) имеет названия файлов вида 20240507_094116.jpg, то я бы их превратил во что-то вроде Тема_2024-05-07_##.jpg или Тема_2024-05-07_by_MBH_##.jpg, где ## - порядковый номер в серии.
    • Переименовывать при этом ничего не нужно - нужно добавить соответствия в тот же самый файл для пакетного загрузчика.
    • Основная идея - сгенерировать "описательные названия" минимально трудозатратным образом, и так, чтобы они с гарантией ни с кем больше не пересеклись.
    • Называть файлы кириллицей или латиницей - дело личного выбора.
  5. Загрузить весь массив снимков (и прокатегоризовать уже ранее загруженные), перенеся свою категоризацию "один в один"; можно использовать какой-то свой скрипт через 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)[ответить]
  • У меня та же ситуация, только фоток 2 диска по террабайту каждый. Но я туда вообще в последнее время стараюсь поменьше грузить, обычно только то, что надо для моих статей (или для добавления в чужие, но не чтобы просто было). Там и так у меня кучу всего поудаляли из-за АП. Потому что тут памятник (НИЗЗЯЯЯЯ!), там в кадре что-то охраняемое АП (НИЗЯЯЯ!), RAW вообще не принимается, а обрабатывать всё у меня времени нет. А какие законы на АП в какой-нибудь Иордании или Гонконге, я вообще понятия не имею. Ну их. 𝓛𝓮𝓸𝗞 𝗮 𝗻 𝗱 11:40, 16 мая 2024 (UTC)[ответить]
Источник — https://ru.wikipedia.org/w/index.php?title=Википедия:Форум/Общий&oldid=137842870