番組WIKI計画#1 - 2021-11-10 23:16
bangumi大西王 (天生万物以养人，人无一物以报天)
这是之前帖子的延续。
跑了一下脚本，修改掉了两万多个条目了（用的是我自己的账号，可以在我的维基编辑历史里看到）
（注：上面这段话是11月12日说的，指的是把/或者.分隔符统一为-分隔符。在你看到此帖的时候实际修改的条目数量要比这多，被修改条目也并非全是其他格式，包含部分格式1修改为格式2的情况。）
考虑到原帖充满了没有强制力/工作量太大/历史遗留问题太多之类的悲观情绪，在我觉得我部分解决了这一问题之后，有必要重新开一个帖子，讨论一下大家对日期格式的想法。讨论规则我觉得可以参照 https://bgm.tv/group/topic/365872
（同时也可以考虑一下这个讨论标准有什么不足之处需要改进）
需要讨论的问题:
1. 如何统一格式
2. 未定日期怎么写
前文以及下文提到的日期格式：
格式1: YYYY年M月D日 （m和d的含义是无前导0），YYYY年M月，YYYY（年）
格式2: YYYY-MM-DD（mm和dd的含义是有前导0）, YYYY-MM， YYYY
其他格式：“/”分割符或者“.”分隔符。
11-19: 暂停运行，有部分回复认为维基人并没有被充分的通知到，等到12月19日再继续按照本帖（或者相关新贴的讨论结果设置规则恢复运行）
11-16开始运行的脚本规则:===假装有分割线===
bot旧规则:（可以使用这个用户脚本方便的查看某次编辑到底修改了什么）
跑了一下脚本，修改掉了两万多个条目了（用的是我自己的账号，可以在我的维基编辑历史里看到）
（注：上面这段话是11月12日说的，指的是把/或者.分隔符统一为-分隔符。在你看到此帖的时候实际修改的条目数量要比这多，被修改条目也并非全是其他格式，包含部分格式1修改为格式2的情况。）
考虑到原帖充满了没有强制力/工作量太大/历史遗留问题太多之类的悲观情绪，在我觉得我部分解决了这一问题之后，有必要重新开一个帖子，讨论一下大家对日期格式的想法。讨论规则我觉得可以参照 https://bgm.tv/group/topic/365872
（同时也可以考虑一下这个讨论标准有什么不足之处需要改进）
需要讨论的问题:
1. 如何统一格式
2. 未定日期怎么写
前文以及下文提到的日期格式：
格式1: YYYY年M月D日 （m和d的含义是无前导0），YYYY年M月，YYYY（年）
格式2: YYYY-MM-DD（mm和dd的含义是有前导0）, YYYY-MM， YYYY
其他格式：“/”分割符或者“.”分隔符。
11-19: 暂停运行，有部分回复认为维基人并没有被充分的通知到，等到12月19日再继续按照本帖（或者相关新贴的讨论结果设置规则恢复运行）
11-16开始运行的脚本规则:
完整日期会被统一到YYYY-MM-DD（有前导0）
不完整日期（比如2020年春，2020-06等）不做修改。不完整日期牵扯杂志书号，暂不做修改（比如2008.2就无法区分是2号刊还是2月份。）
新的条目会被优先修改（因为新入库和最近被修改的条目会直接显示在/wiki页面中，会被优先抓取）
旧条目的修改轮转进行，全部条目更新会在最多45天内完成。
bot旧规则:
1. 动画区的其他格式统一到格式1。
2. 书籍区统一到格式2
3. 音乐区统一到格式2
4. 游戏区的其他格式会被统一为格式2
5. 三次元区的其他格式会被修改为格式2
6. 不完整日期（比如2020年春）不做修改。
我自己倒是觉得未定日期干脆不管也行，反正等开播了之后都会被统一掉。
以现在bgm的情况来看，年月日和'-'分隔符都没能丑到有人看不下去的状况
0000-00-00
混用等价于使用记法1?
等2023年春坍缩成2023年3月1日，就可以改写成2023-03-01了（bot来做）。要不然就是项目被砍，条目被删，就更无所谓时间怎么写了。
其实格式2还有一个危害是为了迎合YYYY-MM-DD，从“1997年3月”产生出“1997-03-31”或“1997-03-01”这些错误的日期信息。比如豆瓣那边的信长之野望7：将星录条目。
因此至少在游戏区和动画区希望能统一到格式1 (YYYY年M月D日)。
yyyy-mm-dd yyyy年m月d日
yyyy-mm yyyy年m月
yyyy yyyy
另外在书籍区用bot时请注意一下这种格式：
“开始: 2018-03-12 (2018年4月号)
结束: 2021-02-12 (2021年3月号)
备注: 同名原形短篇刊载于同杂志2017年9月号“
感觉用bot自动处理可能会变成”2018-04号“，杂志的刊号还是保留年月写法比较好吧。
主要是很麻烦，还要多爬一倍的页面。
至于未定的我也没想法。无所谓怎么写，等确定日期之后再统一也行。
相关信息缺失（*）的就不管了，不在讨论范围之内。
未定时间到是个问题
我懒，我直接用现在的账号跑算了，cookies失效了还能第一时间发现。
全改完大概第二，第一建了4w多的条目，暂时比不过
反而是绝大多数先前参与讨论的人提议/建议/赞同了全部统一为YYYY-MM-DD的格式。
从讨论基本结束到实际开始运行中间也过了一个星期。但是也没有看到“这两个区的维基人”参与讨论或者提出反对意见。
如果觉得原有的标准不好，或者自己失声了，可以再发一贴或者直接在这个帖子下面继续进行，我并不反对。
gist， MIT协议
其他的代码就没有什么开源的意义了，基本就是我自己写的一个低配轻量版的scrapy。别人想看懂怕是不如自己写一个来得快。
不过肯定反对那种无法正常排序的日期（以前多见于pokemon剧场版条目）。
有很多维基人是不会主动投票的，所以这同时也是让wiki人（或者直接说bgm用户）参与讨论（也就是投票）的手段。
我完全不反对，同时很赞同讨论出一个其他的结果（比如我一开始的提议是分区指定不同的标准，大多数回复都支持全站统一反而是出乎我意料的）。
但是我反对原本的情况: 许多人不参与讨论，或者认为讨论是没有必要的，然后因为参与讨论的人少而得不出一个结果。
而且把“YYYY年M月D日”转换为“YYYY-MM-DD”似乎比反向的转换更容易出错。
如果指的是系列主条目的话（比如这个，我看到有一个刚刚的编辑历史提到）系列主条目在编辑历史是缺失的
我前段时间高强度bangumi维基，近期没有那么多精力热情，没有及时参与小组讨论，所以就是我的责任……？
这个是我疏忽了。受影响的条目并不多（大概是11-11 16:00~11:12 14:00之间修改的一批条目）。人工检查了一遍，能找到的已经修复完了。
前面提到的问题大多是此情况。其他的比如同一条目内两个日期只修改了一个并不是遗漏了，在下一次运行的时候会修改剩下的那个日期（一般来说是第二天，或者45天之内）。而主系列条目未勾选是我用bgm网页手动回滚时遇到的bgm自身的bug。
如果觉得X格式不妥完全可以直接说X格式不妥，手工还是机器没有区别
管你是程序脚本的bug还是bangumi的自己的bug，你爬完结果就是书籍区出了一大堆问题，得有人帮你擦屁股，说白了那些错误是你爬完造成的
你那些主系列条目问题的屁股全是我一个人手动修改，忙活一晚上擦完的，改的我鬼火冒
然后现在你说你只是暂停一阵子，12月之后还想继续爬
我管你匠心不匠心精神你程序都不完善，现在在明知用你这个脚本后得有人帮你擦屁股的情况下后面还想继续进行全站改动，你是嫌你昨晚制造的麻烦不够大？
你到底明不明白昨晚那事的性质？你自己办的事给全站维基库大量书籍条目造成了损害，我挑明了这是一个比较大的事故，我真搞不懂为啥没几个人给你点明了，而且我还搞不懂为啥你给别人带来麻烦、给站点带来事故还能表现得如此理所应当一个道歉都没有
还有，日期格式问题不知道开贴讨论了多少次了，全站那么多维基人，你凭啥觉得自己一个贴里搞个投票站个队就能理所当然的开始修改全站所有区块的条目？你**谁啊？
剩下的你说的绝大多数我赞同。程序可能会有问题。区别在于如果发现了问题，我认为至今为止bot修改的条目数量并没有超出我个人能够独自解决的范围，如果发现了问题存在，我是可以自己进行修正的。同时因为bgm保存了所有的版本历史，在这个过程中也不会永久的丢失什么信息。只不过我昨晚21-23点并不在线，所以发现的问题没有立刻修复。
你们都直接默认格式2是更“正确”的格式，但“正确”的格式并不一定就是最合适的。
1. 大多数的中文维基站都是用格式1：维基百科，百度百科，萌娘百科
2. 格式2对于未定日期的表达力不如格式1，未定的保留xxxx年春字样，确定日期的写成YYYY-MM-DD，这又是一种新的不统一
3. 填写信息时为了迎合YYYY-MM-DD，从“1997年3月”产生出“1997-03-31”或“1997-03-01”这些错误的日期信息
4. 很多日本网站给的日期格式是X年X月X日，建条目一个个改成YYYY-MM-DD很烦
5. 把“YYYY年M月D日”转换为“YYYY-MM-DD”似乎比反向的转换更容易出错
6. 其实“这是现状”是个非常大的理由，因为现状（动画区和游戏区的大多数条目都是X年X月X日格式）是由大多数维基人的编写产生的，这就代表很大部分的维基人支持格式1
3感觉前面好像回复过了…年月日可以不写日，-dd也可以不写。甚至要用/或者.的话也不写/dd或者.dd，bgm本身没有一定要填三个数字的要求。
4在前一个帖子还算是问题，在这个帖子就不算个问题了，维基人用什么格式建条目都可以。只要有标准就可以自动转换。
5这两种日期识别起来没什么区别。
“上面这么多支持格式1（或者随便什么现在正在用的X格式）能不能提出一个“这是现状”之外的理由”
而我列举的这些确实是已经被提出来的支持格式1的理由。
我不满意的现状是“XX类条目用A”，“XX类条目用B”，仅仅“XX类条目一直都是用B”不是个合理的理由。
至少我个人认为，任何一次修改，永远是实用大于形式。如果格式一针对某一类词条，其表达效果比统一格式更为高效，分区就是有效的
yyyy-mm-dd - yyyy-mm-dd （连接号标准应该是en dash “–”, 不过考虑到便于输入，hyphen " - "甚至波浪号都行）
日期辅助信息个人喜好 2006-07-06 (C12) 这种
我提出是认为问题1可能会是个需要讨论的相关问题，这样看来我觉得你的观点已经足够充分了，书刊号跟日期相关但不是同一类问题。
2 对于写app或者分析数据来说，统一的字段和格式能简化非常多的麻烦，bgm有些 日/月/年 的格式一般的日期格式库无法解析的，不管是程序自动还是人工修改我都希望能统一起来
多日期的问题我前面已经解释过了，预期行为如此。某些特殊情况下不会识别出一个字段中的多个日期（为了识别是否是书号，就一定要识别日期前后的两个字符。如果这两个字符恰好又是另一个日期的前两个字符，就会暂时不识别第二个日期），第一次运行未识别出的日期会在后续运行中修改，这只是个省劲的做法，并非是遗漏。
bot我是保留了修改日志的，有必要的情况下是可以回滚的。
然后是屁股问题:
没必要和反对我觉得还是有区别的，在第二个维基管理员建议暂停的时候我就暂停了，你上面看到的第一个管理员明确反对虽然回复在上面，但实际上是更晚的回复了。
至于你引用的最后一段话，我反而觉得到时候帖子最后的意见未必是全站格式2。我期待的结果是能讨论出一个标准比如x区就应当用某某格式，以后遇到日期的相关讨论，我们能说我们之前已经讨论出结果，楼主你可以去看xxx帖子。我们决定了日期怎么写，部分日期（比如精确到月或年）怎么写，多余的备注信息又该怎么写
https://bgm.tv/subject/293389
https://bgm.tv/subject/129230
https://bgm.tv/subject/294994
https://bgm.tv/subject/320728
https://bgm.tv/subject/216481
https://bgm.tv/subject/91819
https://bgm.tv/subject/277078
除了发售日、发行日期、放送开始以外完全不需要动其他地方的日期，原本大多数维基人在备注里写的就是完整的自然句，为什么要改成YYYY-MM-DD？
既然站点都设计成wiki形式而不是data picker，那当然可以保留一定程度的灵活性，比如未定日期、需要有附加说明等等各种情况。
但是完全最标准的日期，有的用yyyy-mm-dd有的用XXXX年XX月XX日就没有什么必要了，这类应该是可以处理的（也是我之前理解的lz想处理的）。
(\d{4}) #年份(?:.(\d{1,2}))? #月份,可能没有
(?:.(\d{1,2}))? #日期,可能没有
- 有标准化字段就可以支持自定义日期格式显示，也不影响原来的描述与说明，最大的问题就是增加了编辑工作量 🌚
既然我们可以同意yyyy.mm.dd最好改成yyyy-mm-dd，为什么不都改成yyyy年m月d日或者反过来呢
- 前端验证，简易模式提供 date picker 解决，可以避开大量填写错误
- 前端转换，匹配页面内容转换为自己习惯的格式，还能实现浮动显示原格式
然而这也没解决问题因为那些特殊的模糊日期并不能靠精确的meta字段记录，就觉得还不如趁现在力排众议统一了了事。模糊日期的格式一个个列出来针对性地定义就完了呗，前后端分离一下，嫌不好看的就弄个自定义date picker让他们自己选自己喜欢的样式，做编辑时用其他格式的也自动转换成标准格式。
比如这个写的就是 连载开始
https://bgm.tv/subject/47162
还有之前的一个帖子，有人问为什么同一发行商的游戏列表中有两个条目排在了最后。后来发现是因为有的日期能识别，有的无法识别。无法识别的原因日期没有写在字段值的开头，而是写在了结束。这在条目中也是普遍存在的问题。
简短点，一个是以人为原作，一个人是以书为原作。
嘛，条目编辑上我的意见是加不加都行但加了就没必要删。（←指信息栏部分，不知关联部分。）
但我觉得还是跟这层楼说的一样有个标准比较好，讨论出个结果，知道有部分条目不需要进一步修改，另外有部分需要修改需要再修改为别的情况。否则直接回滚到运行之前的状态相当于一通下来什么都没做。讨论也没有什么推进。
前端提供选项大家自行选择。
目前如果你已经抓了数据，我建议跑一下目前的 key 和非标准特例，才好决定哪些 key 是需要转换的。
这个前端是指用户脚本吗
前端：设置里能启用个默认组件就好了。
音乐区有很多“yyyy-mm-dd M3”，书籍区也有很多“yyyy-mm-dd C83”，M3和C83还可能会用各种括号括起来。
还有一些是“日期 （刊号）”这样的格式，这些都算是特例吗？
一共21k+的条目，音乐6k 游戏1900，书籍5100，动画244，三次元240.
字段直接列在bgm的回复里不太好看，转成json也一起放在gist里面了。
看了这个列表感觉bgm也该有个类似巡查姬的职位，像统一代码格式一样统一一下wiki格式
keys.json包含所有的特例情况。
readme.md里面是具体的key和字段值，原本一共有2.2w条，但是gist放不下这么多，暂且先只放了前1w多条。
json统计的是字段数量而非条目数量
识别日期字段的时候可能漏了一些边界情况，比如只写了年月或者年写了两位数的。
1. 同人音乐+event名称的（可以统一成`yyyy-mm-dd (event名)`)，不如说绝大部分都已经是这样了
2. 影视、游戏后跟放映/发售国家的
3. 游戏后面跟平台的
4. 漫画杂志连载后面跟刊号的*
这些只要讨论出怎么处理日期和额外信息的定论，可以统一bot处理（推荐只对很明显的处理，凡是match不了常见pattern的全部导出手动处理，而不要直接跑）
* 如果有人不熟悉日本杂志，这里多说句。日本杂志月刊比较简单就是yyyy年m月号，但是频率比较快的（比如周刊、半月刊）刊号都有两个：
一个是yyyy年X号（X为一个当年内的连续编号）；
一个是yyyy年m月d日号（这个X月X日为nominal日期，一般晚于真实出版日期1到2个周期）
但是具体使用起来是很混乱的，官方自己同时混用
* yyyy年X号
* yyyy年m月d日号
* yyyy年m月d日X号
* yyyy年m月d日 No.X
* yyyy年m月d日 Vol.X
等一万种组合的情况屡见不鲜
推荐暂时先都改成日期 (刊号)就好，刊号本身不要动。但是可以导出一个list，把非标准的让维基人自己手动改（比如月刊如果没写成yyyy年m月号的，手动改对）。
（另外不排除有人可能把刊号日期当日期写进去的情况；我过滤了遍
字段名本身的话，“连载开始”和“开始”字段名统一这点应该没啥争议，可以用bot改。
实际上有的条目就是这么写的。开始字段只写了一个书刊号没写时间。但既然已经知道是书刊号了就没必要放在这个列表里了。
我感觉“yyyy-mm-dd (辅助信息)”的写法就挺好的。辅助信息可以包括发售平台，杂志刊号等等。否则虽然书刊号可以移到某个新的字段，游戏的多平台发售日期以及影视的多地区上映日期就很难处理了，每个日期专门写一个字段又太啰嗦。而正好bgm原本匹配条目日期时也只从条目字段的开头进行匹配。
大概类似这个js正则？
/^(?<year>\d{4})(?:-(?<month>\d{2}))?(?:-(?<day>\d{2}))?(?: \((?<extra>.*?)\))?$/.exec('1992-10-54 (C83)').groups复杂格式可以单独拉个列表人工改，类似我之前那个wiki语法错误的帖子，列表自动更新。
如果sai老板真的打算做bot功能的话，也可以暂时先用小破车跑着，等bot功能出来了再整合到bgm的bot功能。
带括号的有的是全角有的是半角，放置位置也不统一，可以再讨论规则给统一了。