Обсуждение:Культурное наследие России/Технические средства

Статистика

Добавил для четырёх готовых регионов статистику. Она подводится в почти автоматическом режиме по параметру district=. Впрочем, не могу придумать, как её эффективно использовать. Пока это служебная вещь, позволяющая выявить некоторые ошибки базы, и просто красивая штучка, которую можно разглядывать. Принимаются предложения и замечания. --Alexander (обсуждение) 17:27, 1 августа 2014 (MSK)

А нельзя добавить информацию, сколько памятников имеют, например, фотографии и статьи в Википедии?--Ymblanter (обсуждение) 22:01, 1 августа 2014 (MSK)

Тоже разбитую по типам памятников, или общую для всех? --Alexander (обсуждение) 22:09, 1 августа 2014 (MSK)

Если по сложности исполнения эт две одинаковые задачи, то лучше разбить по типам. Если это сложнее, чем не разбивать, то хватит и статистики по районам. Идеал мне видится примерно таким, но я понимаю, что это не с нашими силами.--Ymblanter (обсуждение) 22:37, 1 августа 2014 (MSK)

Можно ещё всё то же с координатами.--Ymblanter (обсуждение) 22:42, 1 августа 2014 (MSK)

Теперь в этих таблицах можно потеряться=) --Alexander (обсуждение) 02:25, 2 августа 2014 (MSK)

Замечательно, большое спасибо.--Ymblanter (обсуждение) 09:15, 2 августа 2014 (MSK)

часть 2

А правильно ли я понимаю, что для определения победителей в номинации "охват памятников" у нас в ближайшем будущем может в каком-то виде появиться информация об наличии/использовании фотографий по всем памятникам? Если да, то, может, оттуда удастся извлечь еще какую-нибудь пользу: сделать что-то вроде того, что делает ‎ErfgoedBot, только с охватом всего массива памятников. Другими словами, на мой взгляд, было бы неплохо получить в каком-то виде табличку с номерами памятников в БД и числом фотографий соответствующей галерее, этакий одномоментный срез. Вдруг там найдутся чемпионы на 100 памятников в галерее и можно будет хоть немного уменьшить огромное число (~20000) неиспользованных фотографий? Собственно, сами картинки (как тут), вроде бы и не нужны. -- Ludvig14 (обсуждение) 20:58, 31 августа 2016 (MSK)

Наверное, будет, но только после того, как мы разберёмся с работой жюри. --Alexander (обсуждение) 21:28, 31 августа 2016 (MSK)

У меня есть скрипт, делавший что-то подобное для Тверской области, ради интереса запустил его на остальном (но будет очень медленно) --Bok (обсуждение) 00:42, 1 сентября 2016 (MSK)

Запустил на части страниц, как-то так --Bok (обсуждение) 03:03, 1 сентября 2016 (MSK)

Спасибо!! -- Ludvig14 (обсуждение) 08:37, 1 сентября 2016 (MSK)

Bok, было бы замечательно, если бы Вы при случае обновили статистику, а то после конкурса она безнадежно устарела. -- Ludvig14 (обсуждение) 09:52, 1 октября 2016 (MSK)

Ludvig14, в ближайшее время обновлю. --Bok (обсуждение) 20:36, 1 октября 2016 (MSK)

Ludvig14, для всех существующих списков обновил (Участник:Bok/Статистика). --Bok (обсуждение) 21:21, 2 октября 2016 (MSK)

Да, я видела, спасибо! Надеюсь, в ближайшем будущем это больше не потребуется. --Ludvig14 (обсуждение) 21:36, 2 октября 2016 (MSK)

Доступ в новый реестр по номеру объекта

Я немного порылся в API нового реестра и написал страницу, которая достает информацию об объекте по его номеру. Находится она пока что тут (надо вводить номер после id=, пример). Если это полезно, то можно было бы эту штуку привести в более приличный вид. Информация достается вся, что есть в реестре (разве что с многочисленными вариантами указания координат я запутался), а сама программа - PHP-скрипт, не требующий даже базы данных. К сожалению, никакой связи с номерами карточек на mkrf.ru/ais-egrkn в этих данных не нашлось. --Bok (обсуждение) 16:14, 19 сентября 2017 (MSK)

Отличная идея! Может быть, разместить этот скрипт на tools.wmflabs.org, чтобы не зависеть от сторонних хостингов? --Alexander (обсуждение) 20:38, 19 сентября 2017 (MSK)

Да, это было бы правильно. Ничего про него не знаю с точки зрения разработчика, но поизучаю тогда. --Bok (обсуждение) 22:10, 19 сентября 2017 (MSK)

Я тоже мало чего знаю, но там существует раздел (проект?) wikivoyage, куда у меня есть доступ, поскольку раньше на tools.wmflabs жили скрипты для карт (вроде бы тоже php). Если я вспомню пароль, могу поделиться доступом с другими. --Alexander (обсуждение) 22:50, 19 сентября 2017 (MSK)

Там оказалось всё (для этой цели) довольно просто, и самое простое - как раз создать новый проект, поэтому не стал с этим беспокоить. Ссылки выше исправил, они ведут уже на tools. Если кому-то нужно, могу описать процесс, также могу дать желающим доступ в ru_monuments.

Теперь нужно это ещё как-то оформить. --Bok (обсуждение) 16:10, 20 сентября 2017 (MSK)

Очень полезный инструмент! Спасибо. Добавил ссылку в шаблон {{monument}}. Работает если не используется ссылка в поле mkrf. --Insider (обсуждение) 16:43, 20 сентября 2017 (MSK)

Замечательно! Может быть, нам поле mkrf вообще убрать? Собирать постановления о включении в реестр — неблагодарное и, по-моему, ненужное занятие. --Alexander (обсуждение) 19:38, 20 сентября 2017 (MSK)

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

Ещё сейчас нашёл в реестре несколько объектов с однозначными номерами, вроде . Их вроде бы объединяет то, что они все находятся под охраной ЮНЕСКО и расположены в Москве или Казани. О списке объектов ЮНЕСКО, впрочем, в базе тоже забавные представления , да и вообще она полна ошибок. --Bok (обсуждение) 22:19, 20 сентября 2017 (MSK)

«Неэлитные» объекты с короткими номерами, оказывается, тоже бывают: --Bok (обсуждение) 22:29, 20 сентября 2017 (MSK)

Я боюсь, что для Минкульта номер объекта вообще не является чем-то существенным, и в один прекрасный день они решат их все поменять. Единственная гарантия стабильности — как раз постановления о включении в реестр, но, когда министерства окончательно перейдут на электронный документооборот, ничто не помешает им менять номера каждую неделю, имитируя тем самым бурную деятельность. --Alexander (обсуждение) 22:38, 20 сентября 2017 (MSK)

Пока что есть доступ к любым старым версиям реестра (а обновляется он строго порциями), в том числе и по API. Хотя это тоже не гарантия чего-либо. --Bok (обсуждение) 22:55, 20 сентября 2017 (MSK)

Женя, подумалось, нельзя ли сделать аналогичный доступ к нашему реестру? В статьях Википедии и на фотографиях повсеместно стоят шаблоны с 10-значными номерами, ссылки с которых раньше вели на kulturnoe-nasledie.ru, а теперь не ведут, в общем, никуда и в лучшем случае выходят на заглавную страницу наших списков. Между тем, нас не раз спрашивали, нельзя ли сделать эти ссылки более полезными и адресными. Базовая информация о памятниках доступна через Monuments_database/API. Может быть, сделать аналогичный php-интерфейс на этот случай? --Alexander (обсуждение) 07:36, 21 сентября 2017 (MSK)

Да, и это отличная идея, спасибо за ссылку на API! В плане кода это практически аналогия страницы с госреестром, поэтому никаких проблем тут нет, но сегодня, и, вероятно, завтра я этим заняться не смогу, к сожалению. Там же я нашёл еще одну интересную вещь - SQL-база, которая лежит прямо на tools (и оттуда легко к ней подключаться), в которой памятники хранятся в том же формате, что и в списках ,навскидку не хватает только knid-new. С ней тоже можно какие-нибудь интересные вещи придумать. --Bok (обсуждение) 23:13, 21 сентября 2017 (MSK)

Наконец-то добрался до этого, сделал черновик (распространять пока что лучше не надо) с информацией из API - . SQL-базой пока не занимался, только сделал несколько запросов, чтобы проверить, что она доступна и что-то выдаёт. --Bok (обсуждение) 04:54, 26 сентября 2017 (MSK)

По-моему, всё отлично. Можно было бы показывать фотографию прямо на странице, а не ссылкой, но это не очень существенно. Кроме того, слово "русского" перед Викигидом можно опустить, поскольку никакого другого всё равно не бывает. "Муниципалитет" я бы перевёл как "район" или "муниципальный округ". Наконец, для красоты можно было бы сопоставить каждому ISO-коду название региона, но это, опять-таки, не принципиально. --Alexander (обсуждение) 06:47, 26 сентября 2017 (MSK)

Потому и черновик, что не до конца было доделано. Всё вышеперечисленное сделано, и строка поиска наверху заодно (она выглядит криво, но у меня пока что нет других идей). --Bok (обсуждение) 18:06, 26 сентября 2017 (MSK)

Спасибо! Я думаю, табличка будет лучше смотреться, если сделать её поуже и добавить чуть-чуть padding'а (особенно по вертикали), но это совсем мелочи. --Alexander (обсуждение) 18:48, 26 сентября 2017 (MSK)

Кстати, в марте заканчивается оплата домена kulturnoe-nasledie.ru. Если вдруг МК РФ не соберётся его больше проплачивать, может нам выкупить это доменное имя? Тогда не только статьи Википедии, но и другие ресурсы (коих полно), ссылающиеся на старый реестр, привели бы посетителей в Викигид. --Алексей (обсуждение) 11:31, 21 сентября 2017 (MSK)

Хорошая мысль, если это недорого. В финансовом плане я могу помочь, в организационном — вряд ли, поскольку никогда домены не регистрировал, но, может быть, Игорь что-то подскажет. --Alexander (обсуждение) 12:00, 21 сентября 2017 (MSK)

Я подозреваю, что выкупить не удастся. Но следить надо. Digr (обсуждение) 16:27, 21 сентября 2017 (MSK)

Сайт kulturnoe-nasledie.ru (и по совместительству расположенный по тому же IP-адресу old.kulturnoe-nasledie.ru) снова в онлайне. Только там теперь хрень какая-то, не связанная с ОКН. Это я к тому, что если здесь где-то ещё остались ссылки на этот сайт, то смысл они окончательно потеряли. --Алексей (обсуждение) 21:50, 1 июля 2018 (MSK)

Мне кажется, что ссылок не осталось. --Alexander (обсуждение) 21:57, 1 июля 2018 (MSK)

Одна нашлась - наш стартвый ресурс -- Ludvig14 (обсуждение) 00:54, 3 июля 2018 (MSK)

Исправил, спасибо. --Alexander (обсуждение) 22:31, 3 июля 2018 (MSK)

Число памятников по регионам

С помощью SQL-базы той же Commons Database посчитал число памятников в списках по регионам и типам памямятников. Если кому интересно, вот ссылка. --Bok (обсуждение) 00:00, 1 октября 2017 (MSK)

Спасибо. Может быть, ещё общую сумму в конце выводить? --Alexander (обсуждение) 09:22, 1 октября 2017 (MSK)

Хорошо, после следующего обновления базы сделаю. --Bok (обсуждение) 13:19, 1 октября 2017 (MSK)

Сделал. Расхождение с общим количеством в commons:Commons:Monuments_database/Statistics в два памятника, один из которых на странице Культурное наследие Узбекистана/Бухара, а второй был с опечаткой в поле "type". --Bok (обсуждение) 23:54, 1 октября 2017 (MSK)

Listing editor

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

Если желающих написать код не найдётся, можно, как уже предложил Женя, использовать визуальный редактор. Я также советую активно делить списки на разделы и подразделы (дабы не раздувать оглавление), как, например, сделано тут. --Alexander (обсуждение) 01:02, 6 ноября 2017 (MSK)

Могу попробовать сделать, только это будет не сильно быстро. Текущий Listing editor выглядит не сильно сложно, чуть меньше 2k вполне понятно написанных строк на JavaScript. Если срок в пару месяцев устроит - то займусь. --AlexeyBaturin (обсуждение) 09:55, 6 ноября 2017 (MSK)

Конечно, устроит. Спасибо! --Alexander (обсуждение) 11:03, 6 ноября 2017 (MSK)

Предлагаю глянуть первую экспериментальную версию, предварительно разобравшись с установкой.

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

Основная, но не единственная, известная проблема - невозможность редактирования и добавления объектов на страницы, где нет секций (т.е. заголовков второго уровня).

Как установить:

1) Участник:AlexeyBaturin/CulturalHeritageListingEditor.js скопировать в MediaWiki:Gadget-CulturalHeritageListingEditor.js

2) В MediaWiki:Gadgets-definition добавить строчку в секцию "experimental", примерно как здесь: Участник:AlexeyBaturin/Gadgets-definition-CulturalHeritageListingEditor

3) "Настройки" - "Гаджеты" - поставить соответствующую галочку. --AlexeyBaturin (обсуждение) 21:44, 17 января 2018 (MSK)

Вот, теперь заработало. Большое спасибо! Первая мысль — добавить возможность вставки в поле с названием кавычек и длинного тире, как это сделано в обычно ListingEditor. --Alexander (обсуждение) 22:47, 17 января 2018 (MSK)

Вторая мысль: сейчас ListingEditor как-то по-своему форматирует код страницы, скидывая многие поля на одну строку. Это неудобно потом редактировать в коде. Лучше, чтобы он сохранял текущую структуру, т.е. последовательность полей и их разбиение по строкам. --Alexander (обсуждение) 22:53, 17 января 2018 (MSK)

Есть еще вариант - приводить к "каноническому" виду, то есть к фиксированной последовательности полей с фиксированным разбиением по строкам. Он проще в реализации (в варианте сохранения структуры с переводами строк придется немного повозиться) и будет приводить все листинги к одной форме, что проще для дальнейшего редактирования. Но главный минус - сложнее понять разницу между двумя версиями листинга, если он изначально был не в "канонической" форме. Меня любой из вариантов устроил бы, хочу услышать еще мнения. --AlexeyBaturin (обсуждение) 23:22, 17 января 2018 (MSK)

А, я плохо сформулировал. Я как раз имел в виду "канонический" вид. Когда одной правкой изменяется всего один листинг, обычно можно понять, что там поменялось, даже если последовательность параметров сменилась. --Alexander (обсуждение) 23:34, 17 января 2018 (MSK)

Третья мысль: поля в левой колонке можно чуть сузить, а в правой — расширить. Там тоже бывают длинные значения. --Alexander (обсуждение) 22:53, 17 января 2018 (MSK)

Обновил Участник:AlexeyBaturin/CulturalHeritageListingEditor.js: добавил возможность редактировать листинги вне секций (но не добавлять), добавил возможность вставки кавычек и длинного тире в название объекта, сделал форматирование листинга при сохранении (можно посмотреть и обсудить), сделал пошире некоторые поля в правой колонке (левую не менял - возможно, порядок и группировку полей стоит обсудить и пересмотреть). --AlexeyBaturin (обсуждение) 22:35, 18 января 2018 (MSK)

Спасибо! По-моему, здорово, хотя разбивка по строкам немного непривычная. Я обычно ставил в первую строку monument, type, status; во вторую — lat, long, precise, и дальше уже так, как у тебя сделано. И ещё можно объединить year и author в одну строку. Впрочем, посмотрим, кто ещё откликнется.

Екатерина, пинг на тот случай, если Вы не следите за этой страницей постоянно. --Alexander (обсуждение) 02:23, 19 января 2018 (MSK)

Спасибо. Я не слежу, да, потому что не вполне понимаю, что именно тут обсуждается и делается. Кроме того, я не пользуюсь при редактуре визуальным редактором. И еще я не понимаю реплику про "невозможность редактирования и добавления объектов на страницы, где нет секций (т.е. заголовков второго уровня)". Если нет секций - нажимаю "править" в верхнем поле и спокойно правлю и добавляю, что надо, всё то время, что я этим занимаюсь. -- Екатерина Борисова (обсуждение) 00:55, 20 января 2018 (MSK)

Визуальный редактор тут совершенно ни при чём. Если пойти в меню Настройки-->Гаджеты и активировать gadget-CulturalHeritageListingEditor, рядом с каждым объектом в списке появится карандашик, позволяющий изменять отдельные параметры шаблона, не залезая в код. --Alexander (обсуждение) 01:11, 20 января 2018 (MSK)

А, вот теперь поняла. Активировала, большое спасибо. Это очень полезно, если секция длинная, а исправить надо какую-то мелочь в описании одного из объектов. -- Екатерина Борисова (обсуждение) 01:37, 20 января 2018 (MSK)

У меня почему-то при нажатии на карандашик открывается шаблон от другого памятника (конкретно тут: Культурное наследие России/Тульская область/Богородицкий район)--Ymblanter (обсуждение) 11:55, 20 января 2018 (MSK)

Какой именно объект: Усадьба Бобринских вроде бы правильно открывается. --Alexander (обсуждение) 12:09, 20 января 2018 (MSK)

Да, теперь у меня тоже открывается. Видимо, я это пытался сделать из диффа, и там что-тосъехало.--Ymblanter (обсуждение) 13:05, 20 января 2018 (MSK)

Нашлось нечто странное. Добавила при помощи карандашика к единичному объекту 15-значный номер. Добавился без проблем. А потом интереса ради сходила посмотреть из правки, как это прописалось. Выяснила, что в довесок к полю |knid-new= с 15-значным номером система добавила зачем-то и поле |complex= , которое тут было не нужно и я его не задавала. Это зачем и почему? -- Екатерина Борисова (обсуждение) 19:09, 23 января 2018 (MSK)

Это потому, что listing editor формирует шаблон по единой схеме независимо от того, заполнены поля или нет. Раз он знает поле complex, то и ставит его везде. Алексей лучше прокомментирует, но в моём понимании полностью переделать это трудно, хотя, может быть, для поля complex удастся прописать исключение. --Alexander (обсуждение) 19:16, 23 января 2018 (MSK)

Большинство полей прописываются, даже если значения у них пустые. Исключения - block, status, linkextra, doc, style, protection, dismissed - эти поля не будут прописываться в шаблон, если их значения пустые. Поменять несложно, главное определиться, как хотелось бы сделать. Про complex себе отметил, в следующем обновлении добавлю в список исключений. --AlexeyBaturin (обсуждение) 19:28, 23 января 2018 (MSK)

Спасибо. Там есть поле "10-значный номер комплекса" - наверно, стоит сделать так, чтоб complex прописывался лишь при заполнении этой графы. -- Екатерина Борисова (обсуждение) 19:47, 23 января 2018 (MSK)

Новая версия

Загрузил новую версию в Участник:AlexeyBaturin/CulturalHeritageListingEditor.js. Предлагаю потестировать.

Список изменений:

• [+] Возможность выбрать изображение из галереи Commons (WLE или Commons category)
• [*] При вставке кавычек или длинного тире, курсор сохраняет свое начальное местоположение.
• [*] Текстовое поле с ISO-кодом региона заменено на раскрывающийся список с названиями регионов.
• [*] При записи многострочного описания объекта, больше не добавляются теги <p>. Описание сохраняется в шаблон как было введено в форме - без изменений.
• [*] Listing editor не доступен больше при сравнении версий страницы.
• [*] Запись шаблона: type и status записываются на самую первую строку, year и author записываются на одну строку, complex и document добавляются только если они не пустые. --AlexeyBaturin (обсуждение) 21:09, 25 января 2018 (MSK)

  Большое спасибо.--Ymblanter (обсуждение) 21:56, 25 января 2018 (MSK)

У меня не работает теперь совсем, JavaScript parse error: Parse error: Invalid property name in file 'MediaWiki:Gadget-CulturalHeritageListingEditor.js' on line 761. --Bok (обсуждение) 00:10, 26 января 2018 (MSK)

Ага, ошибка, поправил у себя (правда, до конца не понял, почему оно так работает), можно установить. --AlexeyBaturin (обсуждение) 17:37, 26 января 2018 (MSK)

Отличная опция добавления изображений из галереи! Интересно, можно ли как-нибудь отмечать те объекты, для которых в списки не вставлено изображение, хотя в галерее они есть. --Alexander (обсуждение) 22:55, 26 января 2018 (MSK)

Сделал еще один гаджет: Участник:AlexeyBaturin/CulturalHeritageHighlightMissingImage.js. Качество - "сделано за полтора часа на коленке", но вроде бы работает. В заголовке у объектов без изображения появится красная надпись "в галерее WLM есть изображения", но хорошо было бы подумать, как отобразить это менее навязчиво. Установка аналогична, только CSS можно не прописывать. --AlexeyBaturin (обсуждение) 19:30, 27 января 2018 (MSK)

Спасибо! Проверял на странице Культурное_наследие_России/Московская_область/Ступинский_район. Объекты гаджет выбирает правильно, но потом, если пойти в редактор, почему-то говорит, что нет изображений в галерее. Как так получается?

Красная надпись выглядит вполне нормально. Другой вариант — добавлять эту надпись на то место, где должна быть фотография. --Alexander (обсуждение) 20:34, 27 января 2018 (MSK)

Подтверждаю проблему, в следующем обновлении починю. Причина: в редакторе стоит фильтр по *.jpg *.png *.gif, чтобы случайно не выбрать файл, который не является изображением, а в тех галереях - tif файлы. Новый же гаджет смотрит просто на наличие файлов, чтобы не делать сразу много запросов к Commons. --AlexeyBaturin (обсуждение) 20:45, 27 января 2018 (MSK)

Спасибо. Разве что хочу заметить, что слово "десятизначный" (во всплывающей таблице) - это одно неразрывное слово, и сокращать его можно только "10-значный", но никак не "10-ти значный". И заодно спрошу - где-то на наших просторах обсуждений упоминался весьма полезный скрипт на внешней ссылке (кажется, даже две версии, возможно, от разных людей), который группировал снимки с Коммонса по наличию шаблона CHM, показывал отсутствие этого шаблона, соответствие категорий и прочие полезные мелочи - я потерял эти ссылки. Ориентироваться тут очень сложно, может, уже раздельчик сделать с утилитами? --Figure19 (обсуждение) 16:10, 30 января 2018 (MSK)

Figure19, речь вот об этом? Раздел с утилитами создать, конечно же, нужно, как и существенно модифицировать информацию о списках, параметрах шаблонов и проч. Если есть возможность, начинайте. Будем признательны за помощь. --Alexander (обсуждение) 19:18, 30 января 2018 (MSK)

Да, спасибо --Figure19 (обсуждение) 11:55, 31 января 2018 (MSK)

Включаем?

Есть ли ещё вопросы к listing editor для культурного наследия? Если нет, давайте, наверное, включим его по умолчанию. --Alexander (обсуждение) 12:33, 24 февраля 2018 (MSK)

Почему-то не работает на страницах с подзаголовками, вроде Культурное наследие России/Калининградская область/Светлогорск, и на крымских страницах. Но это уже мелочи, можно и включать. --Bok (обсуждение) 13:44, 24 февраля 2018 (MSK)

И почему-то вообще не виден на всех объектах, кроме 1-го, на странице Культурное наследие России/Санкт-Петербург/Невский проспект --Ludvig14 (обсуждение) 19:53, 27 февраля 2018 (MSK)

Лёша, посмотри при случае, пожалуйста. --Alexander (обсуждение) 13:27, 4 марта 2018 (MSK)

Спасибо за обратную связь. Гляну, но раньше следующих выходных вряд ли успею починить, подзаголовки это проблемное место в текущей реализации. --AlexeyBaturin (обсуждение) 21:56, 4 марта 2018 (MSK)

А не надо ещё научить listing editor (отличная получилась вещь!) указывать архитектурный стиль? -- Ludvig14 (обсуждение) 12:59, 7 марта 2018 (MSK)

Новая версия 2

Загрузил новую версию в Участник:AlexeyBaturin/CulturalHeritageListingEditor.js. Предлагаю потестировать.

Список изменений, в соответствии с пожеланиями:

• [+] Появилась возможность указать архитектурный стиль.
• [*] Исправлено редактирование и добавление листингов на страницах с вложенными заголовками любого уровня.
• [*] Редактор включен на страницах культурного наследия Крыма.
• [*] Исправлено название полей "10-значный" и "15-значный". --AlexeyBaturin (обсуждение) 23:04, 14 марта 2018 (MSK)

Спасибо, вроде, все работает! Еще в порядке мыслей вслух. Ведь при одном из заполненных полей wiki или wdid второе однозначно вычисляется. Может, при случае стоило бы добавить какое-то удобство для использования этого обстоятельства? И вообще, в списках немало объектов с указанной ссылкой на Википедию, но не проставленным wdid (особенно этим отличается Москва). Я даже когда-то размышляла на тему сделать бота, который это поправит, но поняла, что своими силами не справлюсь. -- Ludvig14 (обсуждение) 12:53, 16 марта 2018 (MSK)

Я сделал прототип скрипта, который синхронизирует значения в полях wiki/wdid/commonscat. Пока на коленке, но до ума постепенно можно будет довести. Попробовал на нескольких страницах - результат можно посмотреть и проверить в моих последних правках. Если устраивает - можно попробовать запустить на другом, большем, наборе страниц. Наверное, какой-то специальный аккаунт надо завести для автоматических правок? И что делать, если из-за ошибки в скрипте что-то испортится - получится ли простым способом массово откатить правки? --AlexeyBaturin (обсуждение) 22:05, 21 апреля 2018 (MSK)

По-моему, всё хорошо. Большое спасибо! Лучше завести отдельную учётную запись, которой присвоить флаг бота, и делать массовые правки оттуда. Если что-то пойдёт не так, есть, по идее, кнопка "массовый откат", но мы до сих пор ею не пользовались. Я пару раз что-то ботом косячил, но тем же ботом потом исправлял. --Alexander (обсуждение) 22:15, 21 апреля 2018 (MSK)

Может, еще можно брать с Викиданных категорию Викисклада, если она там прописана, а у нас отсутствует? Я прямо сразу же на такой случай наткнулась. А так, вроде, все хорошо, спасибо! -- Ludvig14 (обсуждение) 22:33, 21 апреля 2018 (MSK)

Мне кажется, что уже. --Alexander (обсуждение) 22:50, 21 апреля 2018 (MSK)

Да, действительно. Но тут почему-то не сработало и я добавила руками. -- Ludvig14 (обсуждение) 23:01, 21 апреля 2018 (MSK)

Бот отработал. Ситуацию с недозаполненым commonscat вроде бы починил. Если где заметите несоответствия - сообщайте. Единственное, что я заметил - для некоторых объектов на Викиданных в качестве commonscat выставлена категория WLE/WLM. Возможно, для нас избыточно ее прописывать в commonscat. --AlexeyBaturin (обсуждение) 23:53, 25 апреля 2018 (MSK)

Спасибо! Да, такие категории прописывать не нужно. Лучше вычистить их. --Alexander (обсуждение) 23:56, 25 апреля 2018 (MSK)

Вычистил у нас. --AlexeyBaturin (обсуждение) 20:03, 26 апреля 2018 (MSK)

И от меня спасибо! И да, боюсь, таких категорий на Викиданных немало. Я их там вычищала, когда на них натыкалась, и было это чаще, чем хотелось бы. -- Ludvig14 (обсуждение) 00:04, 26 апреля 2018 (MSK)

А wdid у разных объектов может быть одинаковым? Просто я замечал, что при описании объектов типа "дом, где родился имярек", "памятник имярек", "могила имярек" часто даётся ссылка на вики-страничку с жизнеописанием этого человека. В результате сейчас и у "дома", и у "памятника", и у "могилы" оказывается одинаковый wdid. Я также встречал, что для многосоставных объектов у каждой части даётся вики-ссылка на объект в целом, что тоже приводит к дублированию wdid. С этим что-нибудь делать? --Алексей (обсуждение) 14:38, 26 апреля 2018 (MSK)

Нет, такого не должно быть.--Ymblanter (обсуждение) 14:41, 26 апреля 2018 (MSK)

Да, лучше это исправлять. К сожалению, в поля wikipedia= и commonscat= иногда пихали хрен знает что, от статьи про человека до ссылки на общую категорию Викисклада типа 'Cultural heritage monuments in XXX'. --Alexander (обсуждение) 15:05, 26 апреля 2018 (MSK)

А как исправить? Просто подставленное ботом значение wdid убрать? --Алексей (обсуждение) 15:37, 26 апреля 2018 (MSK)

Ну да, и поле wikipeda= тоже. --Alexander (обсуждение) 20:48, 26 апреля 2018 (MSK)

Составил список ОКН с дублирующимися значениями полей wdid. --Алексей (обсуждение) 15:24, 4 мая 2018 (MSK)

Игорь, нужно дать права бота ‎AlexeyBaturinBot, чтобы делать разные массовые правки в списках. --Alexander (обсуждение) 22:07, 23 апреля 2018 (MSK)

Сделал. Digr (обсуждение) 22:10, 23 апреля 2018 (MSK)

---

Из мелких недоразумений. При попытке выбрать изображение из галереи Listing-editor "не видит" файлы с расширением tif (например объект 5010206000 на странице Культурное_наследие_России/Московская_область/Коломенский_район). --Ludvig14 (обсуждение) 11:55, 7 июля 2018 (MSK)

Конфликты редактирования

вот здесь при редактировании заодно и откатилась предыдущая правка - видимо, из-за конфликта версий (правка была записана после загрузки страницы с листингом)? --Bok (обсуждение) 14:00, 4 мая 2018 (MSK)

Проверил, проблему подтверждаю. Актуально и для обычного listing editor'а. Вопрос в том, что делать в случае возникновения таких конфликтов. В общем случае их простым способом разрешить нельзя (например, если редактируемый листинг удалили, или переместили), можно только какие-то частные случаи рассматривать. Самый простой вариант - блокировать запись при обнаружении конфликта, тоже выглядит не очень. --AlexeyBaturin (обсуждение) 21:03, 4 мая 2018 (MSK)

Вообще, при обычном конфликте редактирования движок именно это и делает: не даёт записать страницу и предлагает учесть изменения, сделанные другим участником. Поскольку правки через listing editor небольшие, я не вижу вреда в том, чтобы их блокировать и выводить сообщение типа "страница изменилась, попробуйте ещё раз с начала". --Alexander (обсуждение) 21:19, 4 мая 2018 (MSK)

Природные памятники

Адаптировал редактор для природных памятников: Участник:AlexeyBaturin/NaturalHeritageListingEditor.js. Предлагаю установить и потестировать. Из очевидного, можно обратить внимание на список полей, не уверен, что все из них актуальные и нужные. Из известных проблем - выключеная галочка "точные координаты" после сохранения показывается как точные координаты, но, думаю, надо в шаблоне поправить (не разобрался как это правильно сделать). --AlexeyBaturin (обсуждение) 20:28, 17 апреля 2018 (MSK)

Добавил. Большое спасибо!

Про лишние поля буду думать. --Alexander (обсуждение) 21:33, 17 апреля 2018 (MSK)

Серьезных проблем с редактором, вроде, не видно. По мелочам - не сообщается, что в галерее есть файлы и не показывается ссылка на Викиданные при наличии заполненного поля Wdid -- Ludvig14 (обсуждение) 23:21, 19 апреля 2018 (MSK)

Ссылку на Викиданные добавил в шаблон. --AlexeyBaturin (обсуждение) 10:09, 21 апреля 2018 (MSK)

Обновил гаджет, который отмечает листинги без изображений, чтобы он обрабатывал природные памятники: Участник:AlexeyBaturin/CulturalHeritageHighlightMissingImage.js, можно попробовать установить. Также поправил проблему, что скрипт выполнялся и искал листинги на всех страницах, а не только на страницах с культурным наследием и природными памятниками. Изменений много, вероятны новые проблемы, сообщайте если что-то будет работать не так. --AlexeyBaturin (обсуждение) 16:01, 21 апреля 2018 (MSK)

Лишние поля — квартал, год создания, автор объекта. Документы мы для природных памятников не указываем, но вообще это поле не лишнее. --Alexander (обсуждение) 23:26, 19 апреля 2018 (MSK)

Убрал лишние поля, обновил Участник:AlexeyBaturin/NaturalHeritageListingEditor.js. --AlexeyBaturin (обсуждение) 10:09, 21 апреля 2018 (MSK)

Спасибо! --Alexander (обсуждение) 10:18, 21 апреля 2018 (MSK)

Более общий вопрос (хотя, наверное, запоздалый). У нас уже есть список природных памятников Молдовы (правда, довольно криво оформленный), а в перспективе могут быть и другие страны. Насколько трудно будет адаптировать один listing editor под разные страны? Или это в принципе не получится, потому что у каждой будут свои поля? --Alexander (обсуждение) 23:26, 19 апреля 2018 (MSK)

Не сложно, особенно если оформить списки тем же способом, который есть для природных памятников и культурного наследия России. Основное - разобраться с шаблоном и скомпоновать форму. Из мелочей - сделать скрипт для сборки (полчаса работы). Если же оставить оформление как есть, то это дополнительные (не скажу, что большие, но сравнимые со всеми предыдущими пунктами вместе взятыми) затраты на добавление кнопок редактирования и добавления. --AlexeyBaturin (обсуждение) 10:26, 21 апреля 2018 (MSK)

Я думал о том, чтобы сначала привести оформление к нашему виду. Он удобнее табличного, а кроме того позволяет добавлять координаты, ссылки на Викиданные и т.д. Я сам это сделаю рано или поздно, но, если у кого-то есть настроение, можно уже сейчас. --Alexander (обсуждение) 10:35, 21 апреля 2018 (MSK)

По поводу отображения точных координат разобрался и сделал вот такую правку в шаблоне, но не уверен в ее правильности. Если кто-то раньше считал, что просто добавление параметра precise с пустым значением означает, что координаты точные, то в таких листингах теперь будет указано, что координаты не точные. Надо решить, как мы считаем: в случае, если думаем, что только precise=yes означает точные координаты, то надо еще поправить шаблон monument, в противном случае надо внести изменения в listing editor. --AlexeyBaturin (обсуждение) 17:26, 21 апреля 2018 (MSK)

Хм, я всегда хотел, чтобы только precise=yes обозначал точные координаты, и мне казалось, что именно так я шаблоны и программировал. --Alexander (обсуждение) 17:37, 21 апреля 2018 (MSK)

WLM-2018

Поскольку listing editor'ом пользуются очень много, хотелось бы исправить пару мелочей, которые сейчас затрудняют последующую правку кода:

• после знака равенства всегда ставить пробел, иначе без подсветки синтаксиса потом совершенно невозможно читать (а иногда приходится)
• помещать knid= и complex= на одну строчку перед knid-new= (на следующей строчке), поскольку knid= и complex= логически связаны, а knid-new= от них совершенно независим
• для экономии места можно также объединить на одной строке commonscat= и protection=

Лёша, посмотришь? Заранее спасибо! --Alexander (обсуждение) 15:17, 15 сентября 2018 (MSK)

А нельзя прогнать бота по всем спискам сделать нулевые правки, а то диффы читать совершенно невозможно?--Ymblanter (обсуждение) 16:16, 15 сентября 2018 (MSK)

Если имеется в виду привести списки к точно такому же формату, как выдаёт listing editor, то это, боюсь, не совсем минутное дело. --Alexander (обсуждение) 16:24, 15 сентября 2018 (MSK)

Да, мне казалось, что любое редактирование страницы переводит все листинги на ней в новый формат, и простое добавление нулевых правок должно все их в новый формат перевести раз и навсегда. Но, возможно, я чего-то не понимаю.--Ymblanter (обсуждение) 16:43, 15 сентября 2018 (MSK)

Бот не делает правки через listing editor, а потому и нового формата так просто не создаёт. --Alexander (обсуждение) 16:47, 15 сентября 2018 (MSK)

При редактировании одного листинга через listing editor в дифе будет только редактируемый листинг, остальные не будут (не должны быть) затронуты. Сделать бота можно, не пять минут, но в целом ничего сложного. Вопрос в том, действительно ли мы хотим это сейчас, когда списки очень активно используются и редактируются? Можно по ошибке сломать все в разгар конкурса, или получить множество конфликтов правок --AlexeyBaturin (обсуждение) 16:49, 15 сентября 2018 (MSK).

Ага, спасибо за объяснения. Давайте пока оставим так, с диффами я как-нибудь разберусь.--Ymblanter (обсуждение) 16:55, 15 сентября 2018 (MSK)

Загрузил обновленную версию в Участник:AlexeyBaturin/CulturalHeritageListingEditor.js. --AlexeyBaturin (обсуждение) 16:40, 15 сентября 2018 (MSK)

Спасибо! --Alexander (обсуждение) 16:47, 15 сентября 2018 (MSK)

Лёша, при попытке добавить фотографии из галереи Listing Editor не видит находящиеся в галерее файлы с расширением tif. При случае посмотри, пожалуйста. Спасибо! --Alexander (обсуждение) 15:14, 20 октября 2018 (MSK)

Загрузил обновленную версию в Участник:AlexeyBaturin/CulturalHeritageListingEditor.js, но не проверил - не нашел примера такой галереи. --AlexeyBaturin (обсуждение) 17:28, 21 октября 2018 (MSK)

Алексей, если ещё актуально, можно проверить на ОКН 5000001983, 1002384000, 5000002703, 3800000653, ... --Алексей С. (обсуждение) 19:51, 21 октября 2018 (MSK)

Всё работает, спасибо. --Alexander (обсуждение) 20:25, 21 октября 2018 (MSK)

Добавление координат

У меня очень много времени тратится на ручное разбиение пары координат на два поля. Что если автоматически при добавлении в поле «Широта» значения вида NN.NNNNN, NNN.NNNNN, вида NN.NNNNN/NNN.NNNNN и ещё нескольких подобных из часто встречающихся разбивать на два значения и второе перекидывать в поле «Долгота»? Евгений Катышев (обсуждение) 14:11, 24 ноября 2020 (MSK).

Карточки объектов

На всякий случай продублирую сюда вопрос, который поднимала уже в рассылке. Обнаружила это дело, редактируя описания фотографий в лонг-листе конкурса. Если открыть фото объекта и кликнуть на 10-значный номер объекта, то открывающаяся карточка по клику на список в половине случаев тащат и на страницу в списках, где фигурирует объект, и точно прямо на объект, а в другой половине случаев - на страницу объекта, но очень сильно мимо объекта, приходится здорово скроллить страницу и искать на ней объект по названию или адресу. Логики в этом я не нашла (то есть почему в одном случае так, а в другом иначе), но, наверное, кто-то сможет вычислить, в чем баг, и поправить. А то искать "вручную" - долго и неудобно. -- Екатерина Борисова (обсуждение) 17:29, 6 ноября 2017 (MSK)

Я думаю, что нужна дальнейшая диагностика. Скорее всего, якоря не срабатывают при слишком большом количестве объектов на странице. Но, может быть, дело в чём-то ещё. --Alexander (обсуждение) 19:02, 6 ноября 2017 (MSK)

У меня да, не работают на очень длинных страницах в Firefox (в Chrome работают). Точно также не работают ссылки, например, со страницы свежих правок на эту страницу или в пивную. "Не работают" у меня заключается в том, что страница сразу при загрузке прокручиваются к якорю, в то же время ниже что-то ещё прогружается, и из-за этого потом страница пролетает вниз. Если при уже полностью загруженной странице щёлкнуть по адресной строке браузера и нажать Enter, страница благополучно проскролливается назад к якорю, при том не перезагружаясь. Других ошибок, чтобы совсем мимо переходило, мне не встречалось.

Пример того, где происходит ошибка - и вообще почти любой объект на той странице, кроме разве что самых нижних. --Bok (обсуждение) 19:22, 6 ноября 2017 (MSK)

А теперь почему-то ссылки в Пивную заработали, и на этой странице не сильно слетают, ещё несколько дней назад всё было не так. Теперь некоторые подозрения вызывают сворачиваемые элементы. --Bok (обсуждение) 19:32, 6 ноября 2017 (MSK)

У меня та же симптоматика (в смысле прокрутки, со ссылками на Пивную всё ОК). Я думаю, не надо стесняться сильнее разбивать списки. Более того, это всё равно придётся делать, если на каждый объект добавлять фотографию: начнутся проблемы с превышенным размером максимальных включений. В последнее время я старался разбивать списки на части, если в них было больше 150 объектов. --Alexander (обсуждение) 19:34, 6 ноября 2017 (MSK)

Всё-таки даже на маленьких страницах подкрутка чуть-чуть подскакивает, видимо, немного влияют сворачиваемые элементы, которые у меня загружаются развёрнутыми, а потом, уже по ходу дела, сворачиваются.

Разбиение списков, с одной стороны, напрашивается, а с другой, создаёт некоторые побочные эффекты. Я придерживаюсь тактики вынесения из списков отдельных сущностей, например городов в районных списках - тогда этих эффектов не возникает. Простое разбиение по адресам по алфавиту мне не очень нравится, я им стараюсь пользоваться только в крайних случаях. Кстати, в некоторые списки, разбитые по географическому принципу (из виденного мной Москва, Петербург, Воронеж, Волгоград), явно напрашиваются динамические карты с полигонами в оглавление. --Bok (обсуждение) 22:12, 6 ноября 2017 (MSK)

Если дело в сворачиваемых элементах, нужно, по-хорошему, спросить на Phabricator'е. Возможно, кто-то подскажет.

С картами есть две проблемы. Первая — в списках по-прежнему используется старый скрипт с tools.wmflabs.org. Если переводить эти карты на Kartographer (а только он умеет нормально рисовать полигоны), придётся отказаться от имеющихся значков и вообще немного сменить дизайн. Вторая — все или почти все нужные границы тут административные, т.е. их нужно подгружать непосредственно с OSM, но недавно выяснилось, что предложенный ранее способ (прописывать в Викиданных 'OSM relation ID' нужного элемента) в корне неверен, поскольку relation ID могут меняться. Иными словами, нужно поговорить с Yurik'ом, поскольку был какой-то другой способ (указывать ID Викиданных на OSM, а не relation ID OSM на Викиданных), но он не документирован и неясно, работает ли. --Alexander (обсуждение) 22:53, 6 ноября 2017 (MSK)

Вспомнил, что ошибки с якорями были раньше и в основных статьях, а потом они пропали. Скорее всего, дело и правда в разворачиваемом элементе, причём как раз в том, где сидит наш довольно кривой, написанный кем-то на коленке mapframe. Поэтому перевод карт культурного наследия на Kartographer — необходимый шаг. Надо этим заняться. --Alexander (обсуждение) 03:53, 7 ноября 2017 (MSK)

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

Есть идея перенаправлять ещё раз к якорю после загрузки страницы. Я не знаю, насколько это нормально, и не очень хорошо знаю js, однако эксперименты в личном js показали, что в этом может быть какой-то смысл. --Bok (обсуждение) 10:23, 7 ноября 2017 (MSK)

База данных и гаджеты

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

Есть и еще более кардинальное и гораздо более сложное в реализации предложение - перенести списки в какую-нибудь базу данных, например, в те же викиданные. Это, как я вижу, позволит гораздо проще писать разные приложения (ботов, listing editor, мобильные приложения) и легко экспортировать списки в разные форматы (тот же gpx, встраивать в википедию или куда-либо еще). --AlexeyBaturin (обсуждение) 18:32, 15 сентября 2018 (MSK)

Это важный вопрос, который я вынесу лучше в отдельную тему. Уже есть Commons:Monuments_database с доступом по API, и с ней можно много всего делать. Перенос списков памятников в Викиданные активно обсуждался на международном уровне пару лет назад, несколько стран перенесли-таки списки, но дальше процесс застопорился из-за занятости организаторов, а также из-за того, что в игрушку они наигрались. По факту мне известно только одно (связанное с памятниками) приложение, использующее Викиданные — это Monumental, который выглядит и правда красиво, но не очень нам подходит, поскольку его опция редактирования заточена под Викиданные, а мы постоянно добавляем новые объекты, т.е. нам нужно редактировать именно списки, а не делать мелкие исправления в Викиданных.

Преимущество Commons:Monuments_database в том, что уже есть бот, который ежедневно подгружает туда данные из наших списков. Недостаток Викиданных в том, что такого бота ещё надо писать.

Наконец, по первому вопросу ответ такой, что увеличить число шаблонов (точнее, размер включений) мы вряд ли можем — это делается на уровне движка, и мы вряд ли уговорим разработчиков, да и страницы, действительно, начинают тормозить дико. Так что единственный рабочий вариант — создание на внешних ресурсах или на tools.wmflabs каких-то приложений, позволяющих делать выборку из базы. Первое, что приходит в голову — это уже упомянутые списки по отдельным улицам, а также карты и gpx-файлы со всеми объектами из одного города. Конечно, это бы доступ к спискам сильно улучшило.

Пингую также Женю и Алексея. --Alexander (обсуждение) 20:25, 15 сентября 2018 (MSK)

А можно рассказать поподробнее про редактирование списков, а не мелких исправлений? Я правильно понимаю, что речь про массовое редактирование или добавление объектов? Как это вообще сейчас происходит с точки зрения пользователя? В викиданных добавить новый объект - не проблема. Если хочется сохранить возможность массового редактирования в том виде, в каком оно сейчас есть - можно сделать импорт/экспорт данных в нужном формате (можно как сейчас - с использованием вики-разметки и шаблона monument, а можно пойти дальше и сделать CSV/JSON/YAML/XML/whatever else), это не сложно. Реальный сценарий может выглядеть так: заходим на страницу Смоленска, задаем фильтр "Ленинский район", "без координат", нажимаем кнопку "редактировать как вики разметку", открывается большое поле для ввода со всеми объектами Ленинского района Смоленска без проставленных координат в виде шаблонов monument. Редактируем, нажимаем сохранить, обновляются все объекты в викиданных. --AlexeyBaturin (обсуждение) 21:16, 15 сентября 2018 (MSK)

Мне кажется, что именно что переносить куда-то списки пока что рано, а викиданные как основное место их хранения даже немного опасно — мало ли что кому что там с ними захочется сделать. А вот репликация в какую-то базу - да, это нужная вещь. Действительно, есть Monuments Database, но его «расширенные» таблицы со всеми, а не только несколькими стандартизированными для всех стран, полями недоступны, пока база обновляется, а обновляется она всё дольше и дольше, и в последнее время едва ли не дольше, чем не обновляется. Мне кажется, иметь собственный аналог только для наших списков нам вполне по силам, мало того, я уже тестировал что-то подобное для карточек природных памятников, сбор информации со всех страниц по ним занимал пару минут. По культурному наследию, конечно, будет больше, но можно и не строить базу методом "все снести и построить заново", как делается в Monument Database.

Экспорт в GPX по нескольким страницам вполне реалистичен и не займёт много времени, но мне пока что было не очень удобно этим заниматься - может быть, сегодня-завтра получится. К картам по одному городу я тоже уже подходил, мне показалось, что Leaflef заметно подтормаживает при тысяче-другой объектах даже при использовании MarkerCluster, но я с ним раньше не работал, и, может быть более опытные коллеги что-то подскажут. Пример тоже надеюсь показать, как только получится. --Bok (обсуждение) 21:22, 15 сентября 2018 (MSK)

Да, у меня тоже есть сомнения по хранению основной информации в Викиданных. --Alexander (обсуждение) 21:29, 15 сентября 2018 (MSK)

В любом случае, перенос списков куда-либо это дело непростое и длительное. Если даже вдруг решимся - то это перспектива нескольких месяцев, а то и лет.

А можно подробнее - в чем конкретно сомнения по викиданным? Кто/что может нехорошего сделать с нашими данными? И если все-таки база, но не викиданные - у нас есть возможности поднять свой сервер а-ля MongoDB, оставаясь в рамках инфраструктуры проектов Wikimedia? --AlexeyBaturin (обсуждение) 22:07, 15 сентября 2018 (MSK)

Во-первых, трудно отслеживать изменения. Сейчас мы просто смотрим Свежие Правки в Викигиде и видим, кто что делает, а на Викиданных придётся как минимум помещать 150,000 элементов в список наблюдения. Не знаю, кстати, выдержит ли он такое.

Во-вторых, на Викиданных просто много посторонних людей, которые где-то что-то изменяют, порой массово, при этом никого не спрашивая и не всегда разбираясь в вопросе. Например, немецкий раздел уже несколько лет носится с идеей переноса на Викиданные listing'ов, и были эпизоды, когда им там кафе и гостиницы просто удаляли, считая, что это какие-то странные элементы, которые нигде не используются. Не знаю, кстати, как сейчас с этим, и где посмотреть, в каких статьях тот или иной элемент используется. --Alexander (обсуждение) 23:18, 15 сентября 2018 (MSK)

Да, по поводу "сервер а-ля MongoDB" — я не знаю, что это такое, но, грубо говоря, инфраструктура Викимедиа предлагает нам только один ресурс, tools.wmflabs.org. Всё, что он позволяет делать — можно. Я, кстати, даже не знаю, где физически находится Commons:Monuments_database. Тоже там? --Alexander (обсуждение) 23:23, 15 сентября 2018 (MSK)

По отслеживанию изменений, если это понадобится - надо делать список всех 150К элементов на странице и смотреть связанные правки оттуда. Не то, чтобы это было очень удобно, но, видимо, реально.--Ymblanter (обсуждение) 23:28, 15 сентября 2018 (MSK)

Да, находится там. Это обычная SQL (Maria DB) база, доступная всем для чтения. Собственно, Maria DB там уже предустановлена и такие базы создавать легко, а получится ли там с MongoDB - не знаю, по умолчанию её там вроде бы нет. --Bok (обсуждение) 23:35, 15 сентября 2018 (MSK)

С GPX-экспортом никакой срочности! --Alexander (обсуждение) 21:29, 15 сентября 2018 (MSK)

Про Leaflet, не подскажу как правильно сделать, но имею аналогичный опыт. Тормозит, даже на 500 точках ощутимо. Вот тут я делал просто - при перемещении карты удалял все существующие точки и подгружал через AJAX только точки видимой области (с лимитом 200, что не совсем правильно, здесь видимо и нужен MarkerCluster, до которого я не добрался). --AlexeyBaturin (обсуждение) 22:20, 15 сентября 2018 (MSK)

Кстати, про http://wvpoi.batalex.ru/map/ я ничего не знал, а штука классная! --Alexander (обсуждение) 23:18, 15 сентября 2018 (MSK)

Да, речь идёт про массовое редактирование или добавление объектов. Я это делаю в текстовом редакторе и потом загружаю большими порциями, что можно видеть, например, тут. Если какой-то гаджет сможет обновлять при этом элементы Викиданных, да ещё и создавать новые, то проблем, конечно, не будет. Просто, насколько я понимаю, никто до сих пор не написал ничего подобного. Те страны, которые переносили списки в Викиданные, банально стали считывать всё с Викиданных, делать мелкие исправления через Monumental, а крупных исправлений у них нет, поскольку списки полные и практически не меняются. --Alexander (обсуждение) 21:29, 15 сентября 2018 (MSK)

Сценарий понял, как я и предполагал. Это выглядит не проблемой, а несложной технической задачей (более простой, чем listing editor). --AlexeyBaturin (обсуждение) 21:35, 15 сентября 2018 (MSK)

Вот кстати, мне как раз было интересно, кто из занимающихся массовым редактированием/добавлением как именно это делает. Лично у меня быстрее всего получается, если конвертировать наши списки в табличный формат, потом редактировать их в Excel/LibreOffice Calc, а потом, собственно, конвертировать их назад. --Bok (обсуждение) 17:07, 16 сентября 2018 (MSK)

Наверняка я делаю это неоптимальным образом, но у меня никогда не ладилось с Excel. Поэтому я беру региональные списки, простым скриптом делаю парсинг, перевожу в наш формат (шаблон {{monument}}), а потом сортирую вручную. --Alexander (обсуждение) 17:20, 16 сентября 2018 (MSK)

Хотелось бы осознать, почему listing editor не подходит (не удобен, не оптимален, не привычен) для подобных операций. Массовое добавление - понятно, но это же делает какой-то скрипт. А дальнейшее редактирование с использованием вики-разметки/Excel? Может быть in-line редактирование сделало бы удобнее (как например здесь)? --AlexeyBaturin (обсуждение) 20:00, 16 сентября 2018 (MSK)

Сначала идея использовать Викиданные для хранения информации об ОКН показалась мне очень заманчивой. Но опасения, высказанные Александром, по поводу трудности отслеживания изменений и предотвращения хаотичности в редактировании данных посторонними людьми кажутся мне весьма серьёзными.

Хочу заметить ещё такой момент. Сейчас в шаблоне monument уже предусмотрено поле идентификатора Викиданных (wdid). Но как показала практика, в очень многих случаях весьма проблематично связать уже существующие в Викиданных объекты с элементами наших списков ОКН, особенно элементы ансаблей ОКН. Наверное, не проблемой будет разбить ансамбль в Викиданных на структурные элементы, которые упоминаются в Викигиде (ограды, решётки, мостики, дорожки, отдельные строения), но тогда непонятно, это будет связываться со статьями в других проектах (Википедии). Не будут же там писать отдельную статью о воротах какой-нибудь городской усадьбы где-нибудь в Сортавале!? (Дай бог, чтобы эта усадьба хотя бы в статье про Сортавалу была упомянута). В результате в Викиданных появится куча объектов, которые используются только в одном проекте - в Викигиде. Более того, мне кажется, не исключена ситуация, когда из-за проблем с разбиением ансамблей на структурные элементы, в Викиданных появятся разные несвязанные записи о фактически одном и том же объекте, но рассмотренные с разных точек зрения: например, как ОКН, как природный памятник, как статья в Википедии. Наверное, эта моя мысль выглядит весьма сумбурно. Я просто пытался таким образом показать, что перенос информации в Викиданные может не уменьшить количества хаоса в описаниях ОКН, а как раз наоборот.

По поводу производительности. На мой взгляд, сейчас не такая уж и плохая производительность. Существенно упасть в ближайшее время она не должна. Основная часть объектов культурного наследия всё же уже в базе. В последующие годы будут довыявляться ранее неучтённые, но вряд ли это процесс увеличит базу памятников в разы - скорее на проценты. --Алексей (обсуждение) 16:47, 16 сентября 2018 (MSK)

Да, сейчас у нас почти 150 тысяч. Около 20 тысяч ещё не выложено из старого реестра, плюс выявленные в некоторых регионах (в Курской 2000+ объектов, например, не говоря уж про археологию Краснодарского края), но кажется, что это всё максимум в полтора раза базу увеличит. --Bok (обсуждение) 17:07, 16 сентября 2018 (MSK)

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

По второму моменту, я считаю, что более подходящий вариант - иметь ОКН как отдельную сущность в викиданных. Ведь по сути, ОКН - это не сам объект, которых охраняется, а это запись об объекте в официальных документах (грубо говоря - строка в государственном реестре), со своим набором свойств и своим жизненным циклом. Не вижу противоречий и с тем, что информация об ОКН используется только Викигидом. Нигде же в правилах Викиданных не сказано, что данные обязательно должны использоваться в двух и более проектах? Тем более выше, в теме про Смоленск, указывали на желание иметь списки определенных ОКН и в статьях Википедии. --AlexeyBaturin (обсуждение) 19:43, 16 сентября 2018 (MSK)

Есть принципиальный вопрос. Учитывая, что на дворе 2018 год, и учитывая то, насколько плохо Викигид работает на обычных современных смартфонах, он может звучать несколько странно, но все-таки. Можем ли мы себе позволить отказаться от рендеринга шаблона monument на стороне сервера, а целиком вынести его на сторону клиента. Более простыми словами, можем ли мы отказаться от поддержки браузеров/клиентов, у которых выключен JavaScript, либо у которых поддержка JavaScript ущербная (Internet Explorer древних версий)? --AlexeyBaturin (обсуждение) 21:29, 15 сентября 2018 (MSK)

Тут я, видимо, ничего не могу сказать, поскольку не представляю, какими браузерами кто пользуется, и как всё это влияет на скорость загрузки страницы.

К слову, я бы не сказал, что чтение списков памятников со смартфона совсем уж неудобно. Наверняка есть способы сделать лучше, написать приложение и т.д., но если повернуть смартфон горизонтально, вполне можно пользоваться. --Alexander (обсуждение) 21:37, 15 сентября 2018 (MSK)

Оффтопик про смартфон. Я не скажу что все совсем плохо, как-то оно все-таки работает. Но пользоваться неудобно: во-первых, да, только в горизонтальном режиме можно работать, мне лично неудобно, во-вторых, у меня вмещается только один элемент на экране (невозможно понять, что в принципе есть в списках, невозможно доскролить, скажем, до 70-го элемента), в-третьих, смартфон тормозит, в-четвертых, с мобильным интернетом долго загружается. Кроме того, невозможно отфильтровать по улице и наличию фотографий. Учитывая все перечисленное выше, без подготовки на стационарном компьютере, на местности только с мобильным телефоном в Красноярске я не смог обнаружить, что стоит сфотографировать по путям моего следования. GPX тоже не особо помог, по причинам, обозначенным в теме выше. Мой личный вывод: без серьезной предварительной подготовки за стационарным компьютером или планшетом, пользоваться списками на смартфоне - невозможно, и быстро эту проблему не решить. --AlexeyBaturin (обсуждение) 22:50, 15 сентября 2018 (MSK)

Да, соглашусь. --Alexander (обсуждение) 17:20, 16 сентября 2018 (MSK)

Предложение: выводить кол-во элементов в галерее

Предлагаю в описании ОКН в тексте ссылки на галерею Викисклада выводить количество изображений в галерее. То есть вместо просто слова "галерея" выводить "галерея(0)" или "галерея(5)". Это позволит новым участникам сразу видеть эффект от своих загрузок (будет меняться это число). Ну и старые участники, время от времени посещая свои "любимые" странички, быстрее заметят, что у них появились свежие изображения ОКН.

По поводу того, как это сделать. Очевидно, что не на стороне сервера, - производительность страничек и так на пределе. Скорее всего на JS со стороны клиента по тому же принципу, что встраивается ListingEditor. После загрузки страницы пробежаться по всем элементам класса "extiw" (с таким классом сейчас даётся ссылка на галерею). Сделать для каждого номера запрос на склад типа "https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=categoryinfo&titles=Category%3AWLM/1001463000" (подставив нужный knid), взять из результата categoryinfo параметр files (отдельно обрабатываются пустые категории) и подставить его в текст ссылки. --Алексей (обсуждение) 22:26, 21 сентября 2018 (MSK)

Я только за. Вообще, у нас уже есть Mediawiki:Gadget-CulturalHeritageHighlightMissingImage.js. Нужно, видимо, как-то его модифицировать? --Alexander (обсуждение) 22:50, 21 сентября 2018 (MSK)

Сделал, можно потестировать: Участник:AlexeyBaturin/CulturalHeritageImagesCount.js. --AlexeyBaturin (обсуждение) 20:36, 25 сентября 2018 (MSK)

Спасибо! В этой ситуации я бы предложил для тех объектов, где в списке нет фотографии, а в галерее есть хотя бы одна, выделять слово галерея красным цветом, заменив таким образом Gadget-CulturalHeritageHighlightMissingImage.js. Просто чтобы не плодить лишние сущности. --Alexander (обсуждение) 23:27, 25 сентября 2018 (MSK)

Мне не кажется, что так будет лучше: красный цвет нельзя найти через поиск по странице в браузере, а надпись можно. --Bok (обсуждение) 23:34, 25 сентября 2018 (MSK)

Спасибо Алексею! Выглядит именно так, как мне и мечталось. Также предложение Александра мне кажется очень полезным. Действительно, сам факт наличия изображений в галерее для ОКН без изображения при отключенном гаджете CulturalHeritageHighlightMissingImage не так бросается в глаза и поиск по странице тут не поможет. А если бы надпись "галерея" в этом случае выделялась цветом, не потребовалось использовать оба гаджета. Это наверное ускорило бы загрузку страницы. --Алексей (обсуждение) 00:15, 26 сентября 2018 (MSK)

Можно включить оба гаджета по умолчанию, никаких проблем, хотя я не знаю, как это повлияет на загрузку страницы. --Alexander (обсуждение) 00:19, 26 сентября 2018 (MSK)

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

Меня лично останавливает то, что красная надпись "[в галерее WLM есть изображения]" около названия ОКН выглядит страшновато, неестественно, потому в таком виде я бы не хотел включать ее по-умолчанию для всех. Может у кого есть идеи, как отобразить факт наличия изображений лучше? --AlexeyBaturin (обсуждение) 18:56, 13 октября 2018 (MSK)

Лёша, я бы попробовал выделять надпись "галерея (0)" красным цветом и одновременно на месте надписи "[в галерее WLM есть изображения]" писать серым шрифтом малого размера что-то вроде "есть неиспользуемые изображения". Тогда можно будет пользоваться поиском, не создавая лишнего визуального шума. --Alexander (обсуждение) 01:11, 14 октября 2018 (MSK)

• Спасибо, очень полезное дополнение! Также поддерживаю какое-либо обозначение объектов, где есть фотографии в галерее, но нет иллюстрации в списке. --Insider (обсуждение) 09:05, 26 сентября 2018 (MSK)

---

Почему-то для некоторых памятников Крымского полуострова в галереях выводится неправильное число фотографий. См., например, ОКН 8232031000, 8232030000, 8230457000. -- Ludvig14 (обсуждение) 11:18, 11 ноября 2018 (MSK)

Да, в коде баг. Поправил оба гаджета, Участник:AlexeyBaturin/CulturalHeritageImagesCount.js и Участник:AlexeyBaturin/CulturalHeritageHighlightMissingImage.js. Можно установить. --AlexeyBaturin (обсуждение) 14:37, 11 ноября 2018 (MSK)

Monuments database

Подскажите, пожалуйста, как связаны списки Культурного наследия с Monuments database? Где можно почитать про порядок обновления данных и прочее? И еще вопрос: как связаны между собой (будут связаны?) карточки объектов в Monuments database с новыми и старыми номерами? Например это и это - один и тот же объект из этого списка. С уважением --Gandvik (обсуждение) 13:49, 15 октября 2018 (MSK)

По 10-значному номеру Вы получаете информацию из списков Викигида (Monuments Database), по 15-значному — из реестра Министерства Культуры. У нас обновление данных происходит автоматически и ежедневно. --Alexander (обсуждение) 15:10, 15 октября 2018 (MSK)

Новый интерфейс списков

Лёша придумал вариант представления списков (чтобы его увидеть, нужно пойти в 'Настройки->Гаджеты' и активировать 'gadget-HeritageListings'), который я бы назвал не просто «улучшенным», а кардинально новым, поскольку он даёт читателю возможность подгружать все объекты одного города одновременно, сортировать по разным параметрам, показывать только объекты без фотографий и, наконец, даже небольшие правки вносить по типу listing editor'а.

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

Дальше цитирую Лёшу:

---

Что есть (основное)

• Объединение нескольких списков на одной странице. В приведенном примере все три списка по Томску объединяются в один общий, таким образом, не надо думать, в каком же списке находится нужный объект, сразу можно работать со всеми объектами.
• Разбиение объединенного списка на страницы, возможность выбрать количество элементов на странице. Это должно решить проблему с производительностью на мобильных устройствах.
• Возможность отфильтровать список по разным критериям (название с описанием, адрес, наличие фотографии, наличие координат, ...).
• Возможность отсортировать список (по адресу, по названию, по типу).
• Два вида отображения: полный (как было раньше) и компактный (только названия и адреса).
• Редактирование в том же месте, что и просмотр. Можно одновременно открывать несколько объектов для редактирования.
• Возможность тут же посмотреть все изображения галерей, не открывая новых окон.
• Автозаполнение описания изменений в случае простых правок (например, если изменены только координаты, или изменено только изображение).
• Экспорт в GPX и JSON только тех объектов, которые были выбраны фильтром. Например, можно выбрать все объекты без фотографии, но с проставленными координатами, и идти фотографировать то, что еще не сфотографировали.

Чего нет (основное)

• Реализация шаблона Monument не полная, некоторые моменты могут отображаться неправильно.
• Нет прогресса загрузки страницы и сохранения.
• Отсутствуют документы о постановке на охрану.
• Изображения, которые находятся не на Commons, не загружаются.
• Captcha, которая может возникнуть при редактировании, не обрабатывается (изменения будут потеряны).
• Экспорт в GPX может генерировать некорректный файл.
• Если во время редактирования перейти на другую страницу, изменения будут потеряны.
• Отсутствует карта.

... и еще куча мелких и крупных недоделок.

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

Преимуществах подхода в целом

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

Недостатки подхода в целом

• Увеличившаяся сложность, много (по сравнению с тем, что было) кода на JavaScript и не самая тривиальная сборка в гаджет.
• Как следствие - увеличение Bus factor. Например, невозможно отредактировать шаблон (добавить новое поле, добавить новое значение, ...), не прибегая к помощи разработчика.

---

Отказываться от такого интерфейса, по-моему, глупо, но нам нужно выяснить два вопроса:

1. Женя и Алексей, понимаете ли вы эту штуку настолько, чтобы делать в ней какие-то мелкие правки — например, добавлять новые поля шаблона {{monument}}?

2. Готовы ли мы использовать интерфейс, который рядовой участник (включая меня) никогда в жизни не сможет починить и наладить?

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

Существенно, что исходные списки никуда не деваются. В крайнем случае, если новый интерфейс перестаёт работать, и некому его починить, мы просто возвращаемся к спискам, как они есть сейчас, теряя только «надстройку».

Что скажете? --Alexander (обсуждение) 00:03, 24 декабря 2018 (MSK)

В целом у меня о JS весьма поверхностные представления, но сейчас посмотрел код - да, условно говоря, добавить поля в шаблон или редактор не кажется проблемой. Попробую попозже скопировать себе и что-нибудь поменять. --Bok (обсуждение) 04:35, 24 декабря 2018 (MSK)

Что касается перехода - как я понимаю, конкретно эту версию внедрять по умолчанию для всех (особенно анонимов) рано, но в целом стоит пробовать. К тому же если хочется подобный интерфейс, то это гораздо менее радикальное решение, чем выносить списки на какую-то отдельную платформу. --Bok (обсуждение) 04:35, 24 декабря 2018 (MSK)

Я думаю, с JS разберёмся. Хотя идея переносить много кода для исполнения на клиента мне не особо нравится. --Алексей С. (обсуждение) 12:41, 24 декабря 2018 (MSK)