Википедия:Обсуждение правил/Википедия:Техническое соглашение о датах и времени

Материал из Википедии — свободной энциклопедии
< Википедия:Обсуждение правил
Это старая версия этой страницы, сохранённая Carn (обсуждение | вклад) в 08:48, 14 июня 2021 (→Итог). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску

Немного стандартизации, для облегчения работы технических инструментов и людей, которые их обслуживают.

Вводное слово

Добрался я значит снова до работы над шаблоном {{ambox}} и модуля Модуль:Message box. В прошлый раз, три года назад, я остановился на работе с датами и попытке их вывести в удобный для читателя и категорий формат. В тот раз, поняв, что у нас нет нормальных инструментов для обработки русских дат (12 апреля 2020 или апрель 2020), прекратил разработку, а потом знаете что было. Так вот, вернувшись я более плотно занялся этой проблемой и обнаружил, что с прошлого раза ничего не изменилось. Готового инструмента определения дат, как не было так и нет.

Мы с двумя инженерами решили определить фронт работ, который нужно закрыть, чтобы понять, нужен ли этот инструмент и что нужно обрабатывать для того, чтобы он работал. И тут выяснилось...

Проблема

В нашем разделе Википедии абсолютный хлам в указании дат, которые используют шаблоны и модули. Вот возможные примеры:

  • 12-12-2222
  • 12.12.2222
  • 12-2222
  • 12.2222
  • 2222-12-12
  • 2222.12.12
  • 2222-12
  • 2222.12
  • 03-12-2222
  • 03.12.2222
  • 3-12-2222
  • 3.12.2222
  • январь 2222
  • 12 января 2222
  • Jule 12, 2222

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

Решение

Принять в качестве руководства Википедия:Техническое соглашение о датах и времени, который утвердит ISO 8601 как единственный возможный формат для технических дат и времени, что позволит как внешним инструментам парсить вики-страницы (тому же визреду в будущем будет легче работать с датами), так и редакторам не придётся постоянно смотреть какой из форматов даты верный. Это также облегчит разработку модулей и шаблонов.

План работы:

  • Принять в качестве руководства Википедия:Техническое соглашение о датах и времени. ->
  • Ботом начать вырезать неверные даты в шаблонах и модулях. ->
  • Поставить на все шаблоны с датами проверку на соответствие формату и если не соответствует, выводить предупреждение. ->
  • Если в течении полугода после принятия руководства все хорошо, то превратить руководство в правило.

Как-то так, предложения по тексту и названию приветствуются.

Обсуждение

  • Ну а почему бы и нет? Вроде, как на первый взгляд, вещь полезная. Uchastnik1 (обс.) 18:49, 8 мая 2021 (UTC)[ответить]
  • Стандартизация нужна, потому сейчас в разных шаблонах ставится такое разнообразие дат, что чёрт ногу сломит. Считаю, что, в соответствии с ISO 8601, формат даты должен быть «2222-12-12», отражающий иерархию «год-месяц-число», а по-русски — «12 января 2222», как естественный. Kalendar (обс.) 19:04, 8 мая 2021 (UTC)[ответить]
  • Внутри можно ориентироваться на то как работает mw:Help:Extension:ParserFunctions/ru#.23time. ГОСТ ИСО 8601-2001 есть. Снаружи заставлять пользователей вместо 1.01.2000 1 января 2000 писать только 2000-1-1 бессмысленно, так как этот формат многим не знаком. В разных гостах по оформлению (напр. ГОСТ Р 7.0.97-2016 п5.10, ГОСТ 7.32-2001 п6.10.1), в выходных данных в любой книге люди видят не такой формат. Максимум для редакторов в статьях можно просить указывать цифры вместо слов (и форматы только те, что уже есть в гостах), т.к. #time поймёт цифры других форматов. --Sunpriat 20:23, 8 мая 2021 (UTC)[ответить]
    • @Sunpriat приведенные выше госты один уже не используется, а второй только для документов и печатной продукции, он не предназначен для представления дат и времени в других местах. Для других мест используется ГОСТ ИСО 8601-2001, который является своего рода локализированной версией ISO 8601.
      > Снаружи заставлять пользователей вместо 1.01.2000 1 января 2000 писать только 2000-1-1 бессмысленно, так как этот формат многим не знаком.
      Значит самое время заняться просветительской деятельностью, более того, это не может быть бессмысленно так как будет высвечиваться предупреждение о том какой формат необходимо ввести. С уважением, Iniquity 20:47, 8 мая 2021 (UTC)[ответить]
  • @Iniquity, имеет смысл оставить два варианта:
    1. для пользователей/участников —25.12.2020;
    2. для обработки внутри любых шаблонов/модулей + как вариант для отображения — 2020-12-25. — Ailbeve (обс.) 20:39, 8 мая 2021 (UTC)[ответить]
  • [1] — тогда нет проблем, выбирает оптимальный формат хранения/обработки, формат представления, и вперед. — Ailbeve (обс.) 20:54, 8 мая 2021 (UTC)[ответить]
  • Скрипты должны облегчать работу участников, а не усложнять. Общеупотребимы только 2 формата: 'YYYY-MM-DD' и для людей 'D.M.YYYY'. Нет проблем поддерживать оба: проверить на наличие точек в строке, если есть парсить один, иначе второй, иначе показать предупреждение с требованием вводить дату только в этих форматах. В скриптах и JSON использовать только ISO. Дело в том, что в российских СМИ фактически используется только формат 'DD.MM.YYYY' или 'D (без ведущего нуля) месяц (словом) YYYY'. Примеры: rg.ru, tass.ru, interfax.ru, lenta.ru. Хотя некоторые используют ведущий нуль, например, N+1. В иностранных АИ: Forbes, bbc, IMDB, YouTube… При добавлении АИ участники копируют даты в {{cite web}} с сайта-источника. Нет проблем заменить «8 мая 2021» на «8.5.2021», но полностью переписывать даты каждого источника на «2021-05-08» это мучение. — Vladis13 (обс.) 06:04, 9 мая 2021 (UTC)[ответить]
    • @Vladis13, по идее сейчас все источники в визуальном редакторе вставляются через генератор Citoid, который сам форматирует в нужную дату, а для обычного редактора есть ProveIt. Но в целом по обсуждению я уже думаю, что возможно числовые форматы деприкировать не стоит, а просто о них нигде не упоминать и заменять ботом. С уважением, Iniquity 11:48, 9 мая 2021 (UTC)[ответить]
  • Если говорить о датах в {{cite web}}, то вставкой источников через визуальный редактор можно пренебречь — это крайне неудобно и обычно делается с ошибками, и если там есть свой конвертер, то и ладно. Гаджет ProveIt вставляет даты как есть, никак не конвертируя. Тоже с гаджетами на вкладке «Ссылки на источники» панели редактирования. Хорошо бы, чтобы эти гаджеты, или даже викификатор, конвертировали даты перед записью страницы, чтобы снизить число мелких ботоправок, засоряющих историю. — Vladis13 (обс.) 23:54, 11 мая 2021 (UTC)[ответить]
Если "нигде не упоминать", то ISO 8601 не должен помечаться как "обязательный", например, словами "должен использоваться" и тп. ~~‍~~ Jaguar K · 10:50, 13 мая 2021 (UTC)[ответить]
  • Я, в целом, за единообразие, и лично мне (лично мне) удобно и понятно записать текущую дату в формате 2021-05-08, но я возражаю против полного запрета на ввод дат в другом формате, хотя бы даже потому, что многие сноски переносятся в русский раздел Википедии из других разделов (в основном английского) с шаблонами, в которых даты записаны так, как это принято в тех разделах. Если наши шаблоны откажутся «переваривать» в том числе и перенесённые даты, это приведёт к очередному завалу в штрафных категориях, а таковых завалов и так слишком много, причём не особо заметно, чтобы такие завалы разгребались даже в тех местах, где это разгребание можно было бы производить ботом (как пример, параметр |url-status = в шаблонах {{cite web}}). — Jim_Hokins (обс.) 22:20, 8 мая 2021 (UTC)[ответить]
  • Бывает так, что полная дата не известна или примерна. В en:Template:Cite web#Date они вводятся в особом формате. Может добавить такие же, и обрабатывать их как-то иначе? — Vladis13 (обс.) 06:09, 9 мая 2021 (UTC)[ответить]
    • @Vladis13, сейчас ведется обсуждение на фабрикаторе по поводу недавнего введения Citoid формата YYYY-MM-XX, где XX указывает на неизвестность. Я там ругаюсь над технической реализацией, что ни один инструмент это не поддерживает, а они вводят. Но в целом такой формат интересен и в будущем, когда хотя бы #time будет его обрабатывать, то можно и добавить. С уважением, Iniquity 11:38, 9 мая 2021 (UTC)[ответить]
  • (+) За такое соглашение, но надо ясно указать, что знак минуса рядом с годом будет означать ключ, связанный с наличием или отсутствием указания на то, что это дата до нашей эры, а не как в ранних версиях ISO 8601, что «0000-01-01» это 1 января 1 года до нашей эры. Это и для ввода данных проще, меньше будет ошибок. А уж длительности мы в модулях рассчитаем правильно, примем поправки на отсутствующий нулевой год. ·Carn 08:40, 9 мая 2021 (UTC)[ответить]
  • Ещё есть такой момент, может он не совсем сюда, а конкретно к {{cite web}}, но я всегда стараюсь в нём писать дату словами из-за непоследовательной обработки:

Код Результат
{{cite web|url=http://example.com|title=Example|lang=ru|date=2020-08-09}} Example (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=de|date=2020-08-09}} Example (нем.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=en|date=2020-08-09}} Example (англ.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=fr|date=2020-08-09}} Example (фр.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=es|date=2020-08-09}} Example (исп.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=uk|date=2020-08-09}} Example (укр.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=fa|date=2020-08-09}} Example (перс.) (9 августа 2020).
{{cite web|url=http://example.com|title=Example|lang=zh|date=2020-08-09}} Example (кит.) (9 августа 2020).
Вот абсолютно непонятно, почему какие-то языки решают, что им можно отформатировать дату, а какие-то не трогают (ну точнее, для них такое не реализовано, к счастью). А вносить в источники французские или испанские наименования месяцев совершенно не хочется, в идеале бы прибить этот зоопарк при унификации. -- windewrix (обс.) 08:52, 9 мая 2021 (UTC)[ответить]
  • Лучше писать не словами, их потом распознавать может быть будет нужно, а, конечно, вносить изменения в код, причём поближе к источнику ·Carn 09:50, 9 мая 2021 (UTC)[ответить]
  • @WindEwriX, спасибо за кейс, да, это потом исправить надо будет. С уважением, Iniquity 11:33, 9 мая 2021 (UTC)[ответить]
  • Парсить словесные месяцы в параметрах — это ад. Вполне возможно уже есть какие-то модули, которые их парсят, в которых прописаны все варианты названий месяцев со всевозможными морфологиями, падежами, регистром и на разных языках… Но при создании сторонних скриптов (ботов, гаджетов) это большая проблема. Например, на Python можно выкрутится, перед парсингом каждой даты переключая локаль, но надо знать на каком языке месяц, и морфология не поддерживается, какой-нибудь «9 май 2021» не распознается. На Lua для модулей и в википарсере встроенных парсеров дат вообще нет. На JS та же фигня. AWB конечно вообще парсинг не поддерживает, там надо лес регэкспов городить. — Vladis13 (обс.) 11:34, 9 мая 2021 (UTC)[ответить]
  • Допустимы ровно 2 числовых формата: ГГГГ-ММ-ДД и ДД.ММ.ГГГГ. Порядок «от большего к меньшему» пишем через дефис, «от меньшего к большому» — через точку. В этом случае не возникнет никаких трудностей с пониманием дат, например, если числа и месяцы почему-то пишутся без нуля: например, очевидно, что нестандартная запись 9.5.2021 — это девятое мая две тысячи двадцать первого года, никаких альтернативных трактовок тут быть не может (американцы и казахи — ССЗБ). Для удобства машинночитаемого времени предлагаю использовать стандартизированный и общепринятый формат через дефис от большего к меньшему (например, 2021-09-05), его понимание живым человеком тоже очевидно и общеизвестно. Ну, ещё можно поддержать словесный формат «9 мая 2021» путём автоконвертации из машинночитаемого. Фред-Продавец звёзд (обс.) 10:59, 9 мая 2021 (UTC)[ответить]
  • Постоянно на служебных страницах пытаюсь ввести дату в формате ГГГГДДММ. 188.170.76.178 19:51, 10 мая 2021 (UTC)[ответить]
  • «Пусть потеет машина». Всё, что вводится пользователем, должно вводиться в удобном ему формате. В том числе потому, что много дат в шаблонах тянется из других разделов, а их вы никак не заставите следовать вашим местным хотелкам. так что пишите единый парсер для всех вариантов и бота, чтобы править. Igel B TyMaHe (обс.) 13:17, 11 мая 2021 (UTC)[ответить]
  • Добавил в таблицу немецкий. Я за то, чтобы для всех языков была расшифровка на русском. Oleg3280 (обс.) 14:33, 18 мая 2021 (UTC)[ответить]
  • Что не так с записью 18.05.2021? В Украине используется. Для шаблонов согласен 2021-05-18. Oleg3280 (обс.) 14:38, 18 мая 2021 (UTC)[ответить]
  • (+) За! Узнал об обсуждении из этого запроса, так как уже давно прошу вернуть функционал исправления даты и времени Bsivkobot. Бот отключен за выполнение несогласованных консенсусом действий, из-за этого пострадала важнейшая функция — обработка к дат к стандарту 8601. Считаю, что необходимо принять как можно скорее это предложение и реализовать то, что осталось нам в наследие: Участник:BsivkoBot/Формат дат ГГГГ-ММ-ДД. — Voltmetro (обс.) 15:58, 23 мая 2021 (UTC)[ответить]
  • Унификацию в данном случае можно лишь приветствовать, разнобой дат замедляет восприятие. eXcellence contribs 07:48, 25 мая 2021 (UTC)[ответить]

Промежуточный итог

Всем спасибо кто высказался! Из обсуждения можно сделать следующие выводы:
1. Явный консенсус за унификацию дат.
2. Отсутствие консенсуса за запрет ввода форматов отличных от "стандартного".

В связи с этим и с тем, что мы с участником @Carn допили модуль Calendar ( ну точнее он допилил, а я рядом стоял :) ) предлагаю следующее:
1. Принять, что руководство рекомендует как минимум поддерживать обработку "стандартной даты" для шаблонов и модулей, которые работают с датами и преподносят читателю их в нужном виде, это можно сделать через модуль Calendar или стандартными средствами MediaWiki.
2. Запустить бота, который будет в основных шаблонах, которые чаще всего переносятся заменять даты на стандартный формат. Это всякие предупреждения в статьях, карточки и источники. Отдельное внимание: данное соглашение никак не определяет что делать с форматом, когда каждый кусок даты записан в отдельный параметр {{примершаблона|20|05|1990}}. Бот не должен их пока трогать. Каждый из этих случаев должен рассматриваться отдельно.
3. Пока через модуль модуль Calendar поддерживаются все форматы дат, которые выше обсуждались. Ошибка выводится на совершенно нестандартные даты, нарушающие любой из стандартов. С уважением, Iniquity 16:57, 31 мая 2021 (UTC)[ответить]

Предварительный итог

Положения, указанные в промежуточном итоге, вписаны в будущее руководство (если не будет возражений).·Carn 18:28, 7 июня 2021 (UTC)[ответить]

Итог

Возражений не поступило, предварительный итог утверждён.·Carn 08:48, 14 июня 2021 (UTC)[ответить]

Источник — https://ru.wikipedia.org/w/index.php?title=Википедия:Обсуждение_правил/Википедия:Техническое_соглашение_о_датах_и_времени&oldid=114894365