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

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

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

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

В мобильной версии Википедии дизайн пометок о непроверенных правках, а также о просмотре стабильной версии статьи отображается как в десктоп-версии Википедии. Этот дизайн очень контрастирует с прежним. Кто-нибудь может объяснить как так получилось и когда вернут прежний дизайн для мобильной Википедии? — 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)[ответить]
    • Очень хорошо, что поменялся, пусть таким и остаётся! Уже лет 5 мечтаю о том, чтобы мобильная версия стала выглядеть как десктопная и наконец-то всё начало сбываться! Xiphactinus88 (обс.) 14:26, 12 мая 2024 (UTC)[ответить]

Новый антивандальный бот 

Около месяца назад, мой бот перенял функцию автоматического отката, которой много лет занимался бот Рейму Хакурей — (см. Википедия:Форум/Архив/Общий/2024/03#Большое обновление антивандального бота). На первых порах, принцип работы нового бота был похож на modus operandi Реймы: свежие правки оценивались с помощью википедийной системы ML (в народе «нейросети») ORES, подозрительные правки откатывались. Но как оказалось, у ORES есть недостатки: он устарел и уже не поддерживается разрабами Фонда. Надеюсь, что Фонд его не выключит в будущем, но кто знает? А замена ORES, названная LiftWing, пока совершенно не пригодна для использования, так как у неё очень много ложных срабатываний. Кроме того, случаются перебои и даже полные отключения ORES. Последний сбой длился около суток и вырубил не только всех антивандальных ботов, но и даже затронул викидвижок — подсветку проблемных правок в списке свежих правок.

Так как я не могу повлиять на фондовских разрабов, решил пойти другим путём и создал собственный аналог ORES, работающий полностью независимо от систем Фонда. Разработка и тестирование первой версии окончено, сегодня запустил её на боевое дежурство. Это не замена ORES, обе системы работают параллельно и идеально дополняют друг друга. Что не обнаруживает ORES, обнаруживают мои алгоритмы и наоборот. По результатам тестов, объединённая система обнаруживает в два раза больше вандальных правок чем чистый ORES (использовавшийся Реймой или первой версией моего бота) и имеет более низкий процент ложных срабатываний. Но как у любой автоматической системы, ложные срабатывания всё равно будут.

Пользуясь случаем, решил перенести антивандальные функции на новую бото-учётку: 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)[ответить]
Источник — https://ru.wikipedia.org/w/index.php?title=Википедия:Форум/Общий&oldid=137779301