#1 - 2024-5-29 10:50
Hyary (‮✩ ‭<ゝω・)
EXEC_WIKI=BGM/. 工程项目:
❏ [组件] 音乐条目显示各曲目参与制作人员信息(本帖)
[组件+] 维基音乐条目可视化编辑套件



组件:https://bgm.tv/dev/app/3136
(联动 [组件 / 脚本] 动画条目显示各章节参与制作人员信息

2023 年 6 月,班古米维基系统新增了制作人员「参与」章节/曲目的功能,简单来说就是关联制作人员的时候,可以记录每个人具体负责哪几个章节/哪几首曲目。但是好像因为太麻烦了,就没有太多维基人有动力去填参与信息

每次写维基,去看到 MusicBrainz 每条曲目的制作人员信息,我就心痒痒,想着什么时候我们班古米也能整一个。
朝思暮想,悱恻之情终于化作开坑的勇气。所以就,锵锵✨



现在填写曲目参与信息能显示在条目页面上了,希望这能让诸位维基人能更方便地检查参与信息,也更有动力填写参与信息。

什么?每个关联都去核实填写实在是太麻烦了?分かる、分かるよ。其实我有一套自用的脚本和小组件,可以做到
只需要从特设网站页面复制整段的曲目 credit,就可以几乎全自动生成 infobox、曲目列表,然后精确自动关联制作人员
现在还在打磨,我会在接下来几个月里整理发布出来的
(现在是 python 脚本,但我想做成开箱即用的组件或网页 app,另外尽量衔接现有的自动关联组件


希望、希望大家很快就不再需要这个小组件了!(bgm48)
#2 - 2024-5-29 13:54
我刚知道原来可以填参与章节,之前真没注意(bgm88)
#2-1 - 2024-5-29 17:04
Hyary
没什么存在感的小 feature ,也还是记录着 bgm 在成为更专业的维基站点方向上的努力(bgm61)
#3 - 2024-6-2 16:07
(‮✩ ‭<ゝω・)
过审啦!请大家提建议反馈(bgm24)
#4 - 2024-6-3 01:43
mark 明天试试看(bgm64)
#5 - 2024-6-3 01:46
(爱来自扶她)
mark
#6 - 2024-6-3 02:55
(さよなら じゃあね 銀河系トマソン)
头次知道还有这个功能,mark
#7 - 2024-6-3 04:39
(宿題は8月32日に)
针不戳!刚出分曲目关联的功能时做过一段时间,之后就觉得太麻烦回归老习惯了(bgm38)
#7-1 - 2024-6-3 15:07
leins=pallange
好杀时间(bgm38)想找个什么资料和格式都满足的网站能一键同步(
#7-2 - 2024-6-4 02:21
aerbioer
leins=pallange 说: 好杀时间想找个什么资料和格式都满足的网站能一键同步(
哈哈,想想都刺激(bgm38)
#8 - 2024-6-3 14:44
(‮!noisolpxE ☆━⊂ ‭∩ ◕◡⛨)
为啥我开启后没显示↗↙(bgm38)
#8-1 - 2024-6-3 14:46
Hyary
刷新页面也没有吗?请问是什么浏览器?
#8-2 - 2024-6-3 14:49
ᛖᛚᛗᛟ
Hyary 说: 刷新页面也没有吗?请问是什么浏览器?
用的chrome,刷新也没用。
#8-3 - 2024-6-3 14:55
Hyary
𝑬𝒍𝒎𝒐 说: 用的chrome,刷新也没用。
那可能是跟什么其他插件冲突了,如果你愿意的话,请私信我插件列表
edit: 我的意思是组件列表
edit2: 感谢𝑬𝒍𝒎𝒐协助 debug!已找到跟其他组件冲突的原因,将会尽快更新
edit3: 已在版本 0.1.1 中修复
#9 - 2024-6-7 14:06
(‮✩ ‭<ゝω・)
版本 0.1.1 已发布。兼容像“2-7”格式的参与信息(例如这个条目的);修复了与某些组件的冲突
#10 - 2024-6-28 12:47
(‮✩ ‭<ゝω・)
版本 0.2.0 已发布。支持多张 disc(例如这个条目);修复了移动端/触屏的收起展开按钮不灵敏的问题
#11 - 2024-7-11 13:25
尝试了一个(还专门添加了一个人) 是非常好的组件 但是 对编辑的要求太高力(bgm38)
#11-1 - 2024-7-11 15:10
Hyary
好诶!就像我在正文中提到的,那个让你更轻松编辑参与信息的组件就快要发布了,届时请务必一试(bgm24)
(暴论:人物条目是维基编辑需求金字塔的顶端
#12 - 2024-7-16 10:48
(‮✩ ‭<ゝω・)
版本 0.2.1 已发布,小更新,兼容像“1.7-9, 2.1-3”格式的参与信息(例如这个条目的)
(这下应该没有漏掉的情况了吧
#13 - 2024-8-31 16:56
(‮✩ ‭<ゝω・)
版本 0.3.0 已发布,根据 infobox 内的信息呈现人名,也就是说,能显示别名和CV和各种组合了!看看这个作为例子的条目。更复杂情况我也验证过,就留给大家去探索和报 bug 了。

处理和匹配那些括号套括号的情况好难写,近乎让我找回了当年OI的感觉
infobox 是可以玩出花来,但维基人们还是要克制啊,比如说不要在制作人员后写所属公司/社团
朦胧中,那个有着真正别名系统的班古米在眼前变得越发真切
#14 - 2024-8-31 17:08
(色々な事をまだ勉強しています)
才知道那个参与是拿来干嘛的(bgm38)
#15 - 2024-9-7 19:23
在更新了“根据 infobox 内的信息呈现人名”之后 对于类似这种条目来说 做出来简直不要太美(bgm38)
以及 以我多年编辑音乐条目的经验 按照日本人的尿性 建议是否可以将参与制作人员信息显示的顺序调整为“艺术家、作词、作曲、编曲”?

#15-1 - 2024-9-9 07:10
Hyary
相关讨论
那我可以做一下,不过有没有其他可关联职位的顺序建议?另外这个顺序有没有比较正式的参考来源?
#15-2 - 2024-12-12 23:49
Hyary
鸽了三个月后加了(bgm24)
#15-3 - 2024-12-13 08:57
Freak
Hyary 说: 鸽了三个月后加了
好的感谢(bgm38)
#16 - 2024-11-30 14:08
你好,我是 条目职位自定义排序与折叠 的作者,希望彼此组件能更好地兼容。
我的组件修改了 infobox 的部分信息,而你的组件爬取了当前网页的 infobox 信息,造成了你的组件的部分错误,案例,详细描述如下:

我的组件会将满足自定义要求的职位信息进行折叠,同时在该条职位信息的子元素末尾增加一个折叠控件,其元素内容为:
<span class="tip side" data-refold-line="10"><i class="staff_sorting_icon">
  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 13 13" height=" 0.7em">
    <polygon points="0,12.5 13,12.5 6.5,0.5" fill="currentColor"></polygon>
  </svg>
</i></span>
其会被爬取并污染你的 parseCreatorGroup 函数,由于我对 staff_sorting_icon 类别元素在 CSS 中做了可显示区域的限制,该 SVG 并不会在曲目列表中显示,同时由于你功能的鲁棒性,该污染并不会对浏览器渲染的结果造成任何破坏,从用户体验来说是几乎无感的。
但特殊情况下,可能会导致你的同一人物多职位合并的功能失效 我昨天测试出来的,不知道为啥今天就复现不出来了...,因此建议还是进行修缮比较好。

我的修改建议是,将 #95 行的代码
const segments = parseCreatorGroup(raw.split('</span>')[1]);
更改为
const segments = parseCreatorGroup(raw.split('</span>')[1].split('<span')[0]);
#16-1 - 2024-11-30 17:26
Hyary
好诶(bgm24)
仔细看了一下,你不仅加了元素,还额外包了一层div,好强的侵入性(bgm43),修了

提议一下个人认为的音乐条目职位排序供参考,基于 #15 的讨论拓展而来:
"制作人", "艺术家", "作词", "作曲", "编曲", "脚本", "声乐", "乐器", "混音", "母带制作", "插图", "原作", "出版方", "厂牌"

下下个版本考虑从你的组件获取排序信息
(我应该不需要再 parse 一遍 StaffMapListJSON 吧
#16-2 - 2024-11-30 23:22
唯独惑
Hyary 说: 好诶
仔细看了一下,你不仅加了元素,还额外包了一层div,好强的侵入性,修了

提议一下个人认为的音乐条目职位排序供参考,基于 #15 的讨论拓展而来:
"制作人", "艺术家", "作词", "作曲...
感谢拷打
已经在着手去除内嵌的 div,原本的门槛在 li.style.overflow = 'hidden' 时,如果要保持高度的一致性,会有2px高度的文字溢出到 padding-bottom 区域...通过附加分层遮罩算是解决了,然后不知道为什么折叠的上下文防迷失功能在特殊情形下会出现Bug?再研究研究...(bgm38)
对于插入的 SVG,虽然图标用伪元素就可以呈现,但要实现触控点击...不直接依赖父辈的实体元素,实现有些困难...暂不考虑了

好的~音乐条目的职位排序会采纳的

嗯...是指你从 infobox 中获取用户自定义 / 默认设置排序后的职位顺序信息吗?应该是可以实现的,只要用户启用了该脚本,同时你的组件后于其获取
#16-3 - 2024-12-1 08:19
Hyary
唯独惑 说: 感谢~
已经在着手去除内嵌的 div,原本的门槛在 li.style.overflow = 'hidden' 时,如果要保持高度的一致性,会有2px高度的文字溢出到 padding-bottom 区域...
感谢精益求精!
基于渲染结果还得考虑启动顺序,希望能直接读取 localStorage 之类的
#16-4 - 2024-12-4 20:50
唯独惑
Hyary 说: 感谢精益求精!
基于渲染结果还得考虑启动顺序,希望能直接读取 localStorage 之类的
实现了一个基于 localStorage 的异步通信 接口
#16-5 - 2024-12-5 15:39
Hyary
唯独惑 说: 实现了一个基于 localStorage 的异步通信 接口
啊?我启发了什么?我也不好意思说什么,或者说“我看不懂啊”,因为你写得好认真好认真(bgm48) 谢谢你专门写这个 API !但是对不起,可我还是想说这有点过度工程了

TL;DR: 遵照 schema 定义的结构化数据本身就是一种 API

我原来的想法是:在你的组件里,用户用 StaffMapListJSON 设置,你在规范化 (normalize) 成 JSON 后存 localStorage 里。加载时,你的组件和我的组件都可以读这个 JSON,这样大家都不需要 parse StaffMapListJSON,只需要 JSON.parse() 过后按照你给的 schema 读自己需要的部分就行。
未来你那边想对这个 JSON 的 schema 做 breaking change 的时候,可以 1) 私信轰炸我催我升级组件;2) 新 schema 的存另一个 localStorage key,保留旧 schema 存原 key 兼容没跟着升级的组件
#16-6 - 2024-12-5 17:43
唯独惑
Hyary 说: 啊?我启发了什么?我也不好意思说什么,或者说“我看不懂啊”,因为你写得好认真好认真 谢谢你专门写这个 API !但是对不起,可我还是想说这有点过度工程了

TL;DR: 遵照 schema 定义的结构...
(bgm38) 原来是这个意思,我原本以为你是想让我来帮忙完成排序这个动作...我文档写得确实专业性不足,我再尝试解释一下。

目前这个接口就是用来完成固定场景的排序工作的,例如你的组件中各曲目参与制作人员信息基本只固定包含“艺术家、作词、作曲、编曲、声乐、乐器”,就可以将该信息按照接口声明内的方式封装写入 localStorage 的约定键值中,随后可以直接从 localStorage 另一个约定键值中读取排序后的结果。

你的想法是,想让我我将 StaffMapListJSON parse 后的数据存入 localStorage 中,嗯...其实是没有必要的,因为只要是存在键值中的数据都已经是被我规范化后的,能保证它一定能被 JSON.parse() ,只要是用户是通过我提供的UI进行设置的而不是直接修改键值对。
也就是其他脚本可以对存储 StaffMapListJSON 数据的 BangumiStaffSorting_${subjectType}StaffMapList 进行直接解析,获取职位次序,方法如下:
const jobOrder =
  // 1.保证能直接被JSON.parse,且获得一个数组
  JSON.parse(localStorage.getItem(`BangumiStaffSorting_${subjectType}StaffMapList`))
  // 2.扁平化多维数组
  .flat(Infinity)
  // 3.只获取排序信息,过滤boolean型的折叠信息
  .filter(item => typeof item === "string")
  // 4.活化字符串类型的正则表达式
  .map(item => item.startsWith('/') ? parseRegExp(item) : item)
  // 最终获得一维的数组,其元素包含用于精确匹配的字符串与用于正则匹配的RegExp,元素顺序就是所匹配的职位顺序

function parseRegExp(regexString) {
    const match = regexString.match(/^\/(.+)\/([gimsuy]*)$/);
    if (match) return new RegExp(match[1], match[2]);
    else return null;
}
以上算法不是最高效的,只是这样链式写功能分离地比较清晰
我发现我俩误解之源就是 StaffMapListJSON parse 的方式(bgm38),如代码所示你让我来帮你 parse 完全没这必要,我顶多可以帮你完成2,3两步,但没这必要,只是少两行代码...
要实现你的想法,我这边唯一要修改的就是要将默认设置写入 localStorage (目前是只存于脚本内的)

Over

接口写就写了,要不你先用用试试,再看哪种方法更好吧...
#17 - 2024-12-12 23:47
(‮✩ ‭<ゝω・)
版本 0.3.1 已发布,小更新
改用 API 获取关联信息,更环保了;加入了#15建议的默认职位排序
下回联动「条目职位自定义排序与折叠」
#17-1 - 2024-12-19 19:00
唯独惑
来吧~我准备好了,接口 功能已更新
#18 - 2025-1-5 02:14
https://bgm.tv/dev/app/704
貌似和这个组件有冲突(bgm41)启用之后收藏不了单曲了
#18-1 - 2025-1-5 08:34
Hyary
谢谢报bug(bgm61),已找到问题所在,将在下一个版本修复
#19 - 2025-1-19 12:12
(‮✩ ‭<ゝω・)
版本 0.3.2 已发布,小更新
支持从组件「条目职位自定义排序与折叠」读取职位排序;兼容组件「章节收藏#18
#20 - 2025-8-21 20:06
疑似 bug 汇报?(bgm38)
使用组件的过程中发现好像不是长按更改默认设置而是鼠标悬浮更改设置?
这样好像会导致点击事件和长按事件有冲突?组件介绍页面提到:
长按更改默认设置的灵感来自 Cedar 的「全站动态&好友动态切换完全版」组件。
测试 Cedar 的组件点击、长按事件是正常的。
#20-1 - 2025-8-23 14:35
Hyary
谢谢汇报(bgm70)
是有触摸屏又有鼠标的情况吗?
用更现代的写法重写了长按的处理方式,应该能兼容更多情况
等我的下次更新吧(bgm67)
#20-2 - 2025-8-23 17:04
Delphinm
Hyary 说: 谢谢汇报
是有触摸屏又有鼠标的情况吗?
用更现代的写法重写了长按的处理方式,应该能兼容更多情况
等我的下次更新吧
数位板 + 触摸屏 + 鼠标
但我记得把触摸屏关掉了,估计win把数位板也算触控设备了。(bgm38)
#20-3 - 2026-5-1 12:17
Hyary
Delphinm 说: 数位板 + 触摸屏 + 鼠标
但我记得把触摸屏关掉了,估计win把数位板也算触控设备了。
鸽了大半年后更了
#21 - 2026-4-10 22:26
(さよなら じゃあね 銀河系トマソン)
提个Bug
https://bgm.tv/subject/640700


对应的人物是这个
https://bgm.tv/person/71166 (つきみぐー、)

第二首曲目,可以点击跳转的 作曲、编曲、混音 (bgm38)
#21-1 - 2026-5-1 12:18
Hyary
催更成功
好诶,修了
#22 - 2026-5-1 12:16
(‮✩ ‭<ゝω・)
年更版本 0.3.3 已发布,小更新
主要是修小 bug 们