番組WIKI計画#1 - 2015-8-23 02:42
ビノタ
｜声明
使用本脚本造成的任何后果由用户自行承担，
BinotaLiu 与本脚本的其他贡献者不负任何责任。
不熟悉操作将导致不可预期的结果，
若您没有维基编辑经验，请务必考虑清楚再使用本脚本。
请仅于需要时使用，
勿用于刷编辑数！
使用前一定要看清楚本文的说明，
以免造成其他维基人的困扰！
Bangumi 是非盈利网站，
过多的编辑数会消耗 Bangumi 更多的服务器资源，
使用上请尽量以最小编辑数达到你的目的！
本脚本源代码（CoffeeScript）采用 MIT License 释出。
｜食用效果图
｜食用方式
在条目关联的编辑页上可以看到按钮「BRRS」、「BRRS 单行本」，两个模式可以选择。
则一模式进入即开始 Loading
俩模式唯一的差别只在于单行本模式只会出现单行本供编辑。
▲界面概览
▲展开详细信息编辑
▲预览编辑结果，左边是老版本，右边是新版本
▲确认完成点击提交
｜下载地址
GitHub
Greasy Fork
源代码
｜已知 Bug ：
暂无
｜声明
使用本脚本造成的任何后果由用户自行承担，
BinotaLiu 与本脚本的其他贡献者不负任何责任。
不熟悉操作将导致不可预期的结果，
若您没有维基编辑经验，请务必考虑清楚再使用本脚本。
请仅于需要时使用，
勿用于刷编辑数！
使用前一定要看清楚本文的说明，
以免造成其他维基人的困扰！
Bangumi 是非盈利网站，
过多的编辑数会消耗 Bangumi 更多的服务器资源，
使用上请尽量以最小编辑数达到你的目的！
本脚本源代码（CoffeeScript）采用 MIT License 释出。
｜食用效果图
｜食用方式
在条目关联的编辑页上可以看到按钮「BRRS」、「BRRS 单行本」，两个模式可以选择。
则一模式进入即开始 Loading
俩模式唯一的差别只在于单行本模式只会出现单行本供编辑。
▲界面概览
▲展开详细信息编辑
▲预览编辑结果，左边是老版本，右边是新版本
▲确认完成点击提交
｜下载地址
GitHub
Greasy Fork
源代码
｜已知 Bug ：
暂无
给一个条目加中文名后重现。
脚本里用了 ECMAScript 6 的功能，Chrome 好像还不支持。
https://developer.mozilla.org/ja ... cts/Array/findIndex
顺带问一下，之前没发现 Infobox 里也有一个条目类型，
但是我这个改类型的脚本没有改到 Infobox ，会影响么？
==== Update:
看起来只有影响到 Infobox ，
页面上方标题后方小字写的类型有改变，
这个可能要问 Sai 了 '_>`
总之我还是先改改脚本把Infobox 里的也改了吧
Infobox 好像只是改变字段而已、
反正本来就有值的字段不会影响、
没值的字段在条目页也不会显示出来、
其实 Infobox 里的类型根本就可以删除吧这样的感觉
连字符这个我倒是可以在脚本上忽略就好
原来这本amz没让上架orz
看现在好像都各自用着自己的格式……
ISBN用amz默认的10位最好 本身条目数量就最多 也容易被搜索到 13位那些个可能存在的连字符很影响搜索
日期感觉大多数情况下yyyy-mm-dd比较规范 不过这项的值系统识别能力还可以 可以识别多种计发
13 位是现在的规范，10 位是老规范（07 年 1 月以前），
但是和书的话 13 位跟 10 位是可以互换的，
公式就是我在 #8-20 写的，
现在如果看到用 13 位的条目要改成 10 位么？
日期如果是 Amazon 抓取的话都是 yyyy-mm-dd ，
但是也有人用 yyyy/mm/dd 、yyyy年mm月dd日 的也有，
这种情况在目录下看得很清楚，
例如我建的这个自用目录，
这日期看着就逼我强迫症发作啊
维基百科的话现在是会有几个机器人在自动维护条目，
遇到需要规范化的地方、机器人会自动帮你修正，
Bangumi 也需要导入么
by Sai
（来源：/group/topic/311622#post_1059999）
赠品1在抓ISBN的时候只吃数字，但好像也有结尾为X的序号……
栗：http://bgm.tv/subject/144168
已经修正了
刚才改了好多
快发PM
估计是 0.0.4 版的错 '_>`
我正在检查
果然还是不要改 Infobox 好了，
用的 Bangumi 源码内的 WikiTpl 函数，然后 Infobox 就坏了，求老板解释
研究中 '_>`
例如 http://bgm.tv/subject/134495 、
http://bgm.tv/subject/134496
后者是 アンソロジー ，觉得不属于漫画、画册等。
单行本的分类目前是有明文规定的么
请不要吓我
只是另外的做法好像也并没有什么坏的影响，普通的单行本跟主条目肯定类型一致，不一致的再标出来，似乎也可以。。。
太感谢了
除了前导 0 以外，
还加个个新功能「去中文名」，可能要麻烦您帮我测试一下了。
希望不是又一个会让我跪键盘的功能
应该很安全，应该（汗
我刚刚还手动在改呢
我去测一下
然后在复杂的情况下发现不能用
是1-29卷，已经去掉了中文名，30-56卷还有中文名，这时候怎么点都不能去中文名。
是否可能是去中文名这个数量有限？
1-29卷，没有中文名，30-56卷还有中文名，点去中文名<这个情况
另外还是要手动填一下“去中文名”这个编辑详情（
知名大长篇（
更新了，修好了，测试的时候帮你去中文名了
TIGER & BUNNY
替换之后会变成
TIGER & BUNNY
拿掉单行本的中文名、搜索就只会搜到系列
这个「去中文名」是个按钮，你要按了才会去的……你是不是误会了什么
我当然知道是个按钮
既有有中文名的又有没中文名的，有点乱，就理一下（
其实我觉得如果不熟操作的话这个脚本用起来好像有点危险
不是原作漫画来的
真的不是要回我么
标题是 (講談社のテレビ絵本)，应该是电视改编（？）
名称跟原作一样，但是讲的至少是同一个故事嘛，
条目是我建的，我当初应该是关联了原作选不同版本才对啊 '_>`
没有和原作有关联的职位 比如"原作"
名称跟原作不一样 和动画二期一样 出版时间也对得上
网上可以搜到图 不是作者画的 是那几个绘师画的
就是算不算漫画有点疑问 以前和油咖喱讨论过 绘本兼具漫画和画集的某些特点 更接近漫画一点
密码提示： 「话说这个网站内部能_____吗？」是什么条目的讨论？（四个字，简体中文）
就是把动画的画面直接截图做成绘本的东西（？
所以イラスト难道不是动画的么（
作者的话写讲谈社就好了吧
テレビ絵本只是个label名 有时候是为了编集/出版管理便利 和内容不一定一致
http://bgm.tv/subject/32998
封面没写0就不加
我觉得你们几位要不要讨论出一个严格的规范，
严格规范到序号格式、符号的使用、日期的表记方法等等
一般情况就是系列标题+半角空格+半角圆括号，填半角序号。
1. 序号遵从封面，一般不加0，插件默认不加就可以了。有需要加的情况（SAO），编辑者根据情况自行判断。
2. 括号默认用半角，全角…不好看。有几种情况需要使用其他括号，包括同名的不同作品、同作品的不同类型（小说漫画）、同作品的不同版本等，其他常用括号包括全角山括号〈〉（注意不是大于小于号，是中文的单重书名号）、半角角括号[]等，需编辑者自行判断。
3. 有时会有系列标题不同于单行本标题的情况，比如系列标题为常用的日文假名标题而单行本直接用了封面上的英文标题；也有系列标题结构复杂而单行本标题只用了核心标题的情况。我的做法是保持这个不一致，重视单行本封面原本标题，系列条目追加别名。对插件的希望是默认用系列标题填充，也提供其他标题填充的选项。
其他还有什么表记方法问题？
连载信息册数话数经常用/
每个字段用 | 区分太麻烦了（？
如果是我开发的话一定用 json ，各种省事
嘛现在还有个麻烦就是人名的姓跟名究竟要不要加空格，
Amazon 上导入的大部分人名中间都是有空格的，
但是这样会关联不上，
因为 Bangumi 上好多人名没有空格
就标准来说加不加好像都有道理，目前习惯上不加。
顺便问一下 infobox 第一行的 animanga/Manga 这个如果没修改会影响么？
解决方法就是再点一次，先选小说再选漫画之类的。
会连着 SAI 老板在 #20 点的功能一起 Release ，
不过因为要开学了我还在努力把手上的项目清掉，
所以(ry
大概要过很久才会更新吧
这问题出在 不知道的人点快了结果类型没改成功
更新后才用不了的？
先降级重装个0201用着再说...
测试了下180个单行本 最快一次15秒 最慢近40秒 和连接速度有关
序号起始后面能不能加一个 到__为止 默认取最大序号 比如我要改1-9卷和45-65卷
点预览以后 窗口焦点还是在原来的位置 希望回到顶部或者确认按钮处(后者方便点
不过我说的这个功能 能不能实现?虽然可以用叉掉1-44卷然后填45来改45-65卷 不过这样就要提交两次
似乎只作用了界面...
下个版本修好
试了一个系列发现没什么问题，不过预览的时候回车都被吃掉了我慌了一下……
不过这么说来音乐有系列么
http://bgm.tv/subject_search ... C%E3%83%AC!+F?cat=3
相关功能只能等填坑。
我是随便翻了几个类似的系列看到相互关联广播剧or其他。
感觉不明确说一下的话，这样关联的会越来越多啊。
普通模式也是0开始 有其他类型在里面倒无所谓
程序内处理时数组本来就是从 0 开始的，
如果用我在 #2 提供的排序脚本，排序号也是从 0 开始排……
使用上应该不影响
强烈建议从1开始排....
谢了 虽然还是没装 暂时没需求...
不过有个问题是有另外一个很好用的自动排序脚本是直接抓title的序号的（
这个状况持续很久了么？
变成一次只发送一个请求（一次只加载一个条目），所以大概会变比之前慢吧