Vocawiki:讨论版

各讨论空间页面最新动态

缩写列表：

新

该编辑创建了新页面（见新页面列表）

小

该编辑为小编辑

机

该编辑由机器人执行

(±123)

该页面字节数的前后变化

2025年11月13日 (星期四)

17:54

User talk:Kim8394 差异历史 +312 4O74Y74L74J7 留言 贡献 （→关于导入页面：​ 新章节）​标签：新话题

關於設立本站點的討論版

本主题或以下段落文字，移动自 Talk:首页#關於設立本站點的討論版

很抱歉選擇此處來討論這個話題，但恕我難以找到比這更適合討論這個話題的頁面了。目前本站點的用戶日益增多，僅使用QQ群作為討論場所未免有些乏力。由此本人提議設立本wiki的討論版用以討論站務或申請權限，歡迎各位前來討論。--人间百态（留言） 2025年10月19日 (日) 22:26 (CST)

原则上(＋)支持 ，况且本站开放注册，今后肯定要在站内设立讨论版。至于具体采取何种形式，只要方便都行，比如把本页直接原地当作讨论版都行（。——4O74Y74L74J7（留言） 2025年10月19日 (日) 22:44 (CST)

(＋)支持 ，可以直接设在Vocawiki talk:讨论版，暂无需设立二级分区。 SaoMikoto（留言） 2025年10月19日 (日) 23:02 (CST)

(＋)支持 —— AdorN（留言） 2025年10月19日 (日) 23:04 (CST)

(＋)支持 -- Lower（留言） 2025年10月19日 (日) 23:11 (CST)

(＋)支持 —— 哈里布莱（留言） 2025年10月19日 (日) 23:33 (CST)

@SaoMikoto@AdorN@Lower@哈里布莱:我覺得把討論版設在Vocawiki空間更好，這樣對應討論頁可以討論關於討論版本身的問題而不必在討論版討論。 人间百态（留言） 2025年10月20日 (一) 15:43 (CST)

(＋)支持 Wecury（留言） 2025年10月22日 (三) 04:01 (CST)

如果无异议的话要不操作一下？放在Vocawiki空间的话需要设置一下$wgExtraSignatureNamespaces。--AdorN讨论⏰2025年10月22日 (三) 20:18 (CST)

试了下直接加__NEWSECTIONLINK__魔术字应该就行，如果设置$wgExtraSignatureNamespaces其他同命名空间的页面也会被影响到。—— Dreammu（留言） 2025年10月27日 (一) 11:53 (CST)

那也可以吧，虽然wmf那边应该都是设的 --AdorN讨论 ⏰︎ 2025年10月27日 (一) 12:11 (CST)

反正无论如何得搞个总结版便于跳转和查看最新发言（）——Lower（留言） 2025年10月22日 (三) 20:29 (CST)

只有一个版了为啥还要跳转（ SaoMikoto（留言） 2025年10月24日 (五) 23:29 (CST)

放在偶数空间那还叫“讨论”版吗？--過去最高を再々構築 2025年10月24日 (五) 23:32 (CST)

問題是討論空間就不是這麽用的，討論空間只能是對應頁面的相關討論存放處而非討論的主頁面。 人间百态（留言） 2025年10月25日 (六) 22:47 (CST)

但是不搁在讨论空间的话，“最新留言：多久之前 | X条留言 | Y人参与讨论”这一栏不会显示吧。——4O74Y74L74J7（留言） 2025年10月25日 (六) 22:54 (CST)

这个后台可以配置的。 SaoMikoto（留言） 2025年10月25日 (六) 23:06 (CST)

跟上面提到的那个配置有关，调了就行。 --AdorN讨论 ⏰︎ 2025年10月25日 (六) 23:06 (CST)

可以解决的话那都行。——4O74Y74L74J7（留言） 2025年10月26日 (日) 17:14 (CST)

大概是习惯问题，萌百系的都喜欢扔talk，我个人是觉得都可以。 SaoMikoto（留言） 2025年10月25日 (六) 23:08 (CST)

根据共识已完成移动。——4O74Y74L74J7（留言） 2025年10月27日 (一) 15:48 (CST)

很难不(＋)支持 --雷欧妮（留言） 2025年10月24日 (五) 23:28 (CST)

---

在移动之后，关于讨论版搁在Vocawiki还是Vocawiki讨论空间的问题又出现了新的技术问题及反对意见，故在此重新@人间百态@SaoMikoto@AdorN@Lower@哈里布莱@雷欧妮@JackBlock继续商讨此事，也欢迎更多意见，同时为大伙还未充分表达意见就鲁莽结案进行操作而道歉。我个人的意见还是能用就都行。——4O74Y74L74J7（留言） 2025年10月27日 (一) 17:16 (CST)

放在讨论空间可能更方便扩展和小工具对讨论功能的原生支持，不过目前只是用DT的话看起来在非讨论页命名空间的讨论页加魔术字就好，但DT以外的讨论页扩展和小工具可能需要对此作额外适配。—— Dreammu（留言） 2025年10月29日 (三) 08:56 (CST)

讨论版放在讨论空间下方便最近更改选所有讨论空间快速追踪，放讨论空间更好点。—— JackBlock ( 会話 • 記録 ) 2025年10月27日 (一) 18:36 (CST)

考慮目前的人數情況，討論版已經足以滿足平時的討論需要，追蹤所有讨论空间更改並不成立。 人间百态（留言） 2025年10月28日 (二) 16:02 (CST)

关于标题首字母大小写敏感问题

由于目前Talk:首页中的讨论串暂时没有结论，暂且用这里当讨论版了，后续需要调整的话再移动。

此前由@amero提议，在mw后台调整了主空间和分类空间的大小写敏感配置，该配置会导致首字母大小写不同的两个标题/链接（如“ryo”和“Ryo”）被视为完全不同，即ryo和Ryo成为两个不同的页面，如果只有Ryo存在则内链ryo成为红链。

目前amero还在调整站内链接，为了临时解决链接问题，现在使用的非常邪恶的Hack是：通过魔改mw核心的语言转换功能，强行给所有标题额外添加大/小写变体，目前的效果为（仍以Ryo举例）：

• 在内部链接或url直接输入跳转时，如果使用大/小写标题（ryo），且对应的小/大写标题存在（Ryo），就自动链接或跳转到存在的标题（Ryo）。
• action=edit 等操作仍然能正常创建不存在的标题（ryo），即大小写仍然是独立的页面。

但考虑到这一更改可能会导致未来的不稳定性和兼容性问题，且站内用户对“大小写敏感”本身意见不一，在此征求各位的意见。目前我能想到的可能方案有：

1. 保持现状，效果和缺陷如上；
2. 保持大小写敏感，且在内链调整完成后去除上述Hack；
3. 恢复到首字母强制大写，然后使用Func的方案，效果可见群内讨论或icu:Category:小写标题；

欢迎各位前来讨论。 --AdorN讨论⏰2025年10月22日 (三) 21:18 (CST)

虽然我也没意识到内链会变得完全大小写敏感（如果因误解配置了大小写敏感，我自裁），不过不妨碍我本人的观点：

(－)反对 2.保持大小写敏感，且在内链调整完成后去除上述Hack（1还是3我暂时不评价）；

(－)强烈反对 对翻译后（尤其是片假名）含有英文进行首字母大小写敏感；

(＝)不反对 原名为大小写的全改为对应大小写，即小写标题改为小写（在我认知范围里P主只有Eve明确说过不要小写，虽然我暂没找到来源（）。————Lower（留言） 2025年10月22日 (三) 21:54 (CST)

召唤一下其他之前在群里对这事发表过意见的：@amero@Dreammu@星幻丶碎梦@Synzi@哈里布莱@JackBlock@Ryb --AdorN讨论 ⏰︎ 2025年10月24日 (五) 22:19 (CST)

(－)不支持 大小写敏感，强制首字母大写+使用{{小写标题}}即可。--雷欧妮（留言） 2025年10月24日 (五) 23:29 (CST)

《BONNIE & CLYDE》是一首原文为假名的歌曲。请问如果“对翻译后（尤其是片假名）含有英文进行首字母大小写”不敏感，条目名是否应当对非首字母的“ONNIE & CLYDE”大小写也不敏感？——あめろ 2025年10月29日 (三) 05:29 (CST)

实际上在没有大规模需要大小写页面并存的情况下改动该设置并不合理，如果要改善显示有上文3这种更合理的影响更小的方案。—— JackBlock ( 会話 • 記録 ) 2025年10月25日 (六) 00:12 (CST)

能用方案3的话还是挺好的，虽然我感觉如果没有历史包袱2也还好，说到底还是成本问题……—— Dreammu（留言） 2025年10月25日 (六) 00:22 (CST)

(＋)支持 1.保持现状。原文标题是小写就该保持小写，而不是强制大写后再挂{{小写标题}}修正。个人认为现在技术上能区分大小写，就先这样保持，Hack目前也挺好用。说到历史包袱问题，如果能修正完所有内链就更好了（ WecuryTalkContribs 2025年10月25日 (六) 00:52 (CST)

这几天忙，不想动脑，忙完再细看。 ——あめろ 2025年10月25日 (六) 13:42 (CST)

(＋)支持 分类/用户大小写敏感

(－)反对 其他的大小写敏感，很多内容都有大量社群/本人/平台混用首字母大小写，没有必要强行切割。比如Kikuo大部分平台账号都叫kikuo_sound, 那么kikuo 本身在某种程度上是更加常见常用的称呼；Echo/echo/ECHO本身作为英文词汇这三种写法都是常用的，那么区分首字母大小写反而可能会造成不必要的查询成本。

(＋)倾向支持方案三，本来我是支持1的，如果1有bug的话那么还是3比较好一点

——哈里布莱（留言） 2025年10月25日 (六) 23:18 (CST)

1. “有大量社群/本人/平台混用大小写”不是百科网站对条目名忽略大写的理由，请见我于2025年10月29日 (三) 05:29 (CST)在你后面发表的另一条发言。
2. 你混淆了名称与ID/slug/handle。在Kikuo的官网、Youtube、YouTube Music、Spotify、Bandcamp、Apple Music、Instagram、X（Twitter）、Patreon、pixiv、FANBOX、bilibili几个平台中，仅bilibili使用了“kikuo_sound”作为名称，这应该系“kikuo”已被注册而B站不允许重名（不论大小写）所致。其他平台若有“kikuo_sound”，均是作为ID而非名称出现。即便其在B站使用了“kikuo_sound”作为账号昵称，其B站投稿均使用首字母大写的“Kikuo”作为自己的名称。 ——あめろ 2025年10月29日 (三) 05:29 (CST)

   那为什么本人不用Kikuo_sound作为账号昵称？“kikuo”被注册跟“kikuo_sound”大小写似乎并没有必然关系。—— Lower（留言） 2025年10月29日 (三) 11:21 (CST)

我来发表我的观点，我支持AdorN的第二个方案，即区分首字母大小写，并在处理完残留链接后移除Hack。

1. 首先让我阐释MediaWiki为什么会做出“忽略首字母大小写并在标题上默认大写”这个功能：
   1. MediaWiki是西方人开发的一个软件，他们的拼音文字需要在标题、句首将首字母大写。忽略首字母大小写方便他们写出“[[Some concept]] is explained here.”与“I am referring to [[some concept]] here.”这样的代码，而不必“[[some concept|Some concept]]”或“[[Some concept|some concept]]”。
   2. MediaWiki是为维基百科设计的，维基百科是一个以介绍概念为主，而非介绍专有名词为主的百科，这意味他们在大多数情况并不需要各处一致的大写/小写，而是根据单词位置决定大小写。
   而Vocawiki情况则完全相反，我们是中文百科，不需要句首大写；我们介绍的作品、创作者的名称都属于专属名词，需要严格大小写。
2. “有大量社群/本人/平台混用大小写”不是百科网站对条目名忽略首字母大小写的理由。作为类比，有大量社群/官方/平台混用39music!中“music”的首字母大小写，请问Vocawiki条目名是否应该忽略首字母“M”的大小写？
   • a. 若答案为“是”：《Angelfish》也是一首原名为假名的歌曲，在B站搜索“angelfish”，前三个结果都是这首歌，而它们的标题分别为“Angelfish”“angelfish”和“AngelFish”。那么请问Vocawiki条目名是否应该忽略“F”的大小写？
     • a.x. 若答案为“是”：《Better Off Worse》在niconico、YouTube的投稿标题为“Better Off Worse”，而在B站的投稿标题为“BETTER OFF WORSE”。请问条目名是否应当对非首字母的“etter”“ff”“orse”大小写也不敏感？
     • a.y. 若答案为“否”，那为什么同样是首字母，第一个单词的首字母就要搞特殊呢？
   • b. 若答案为“否”，那为什么同样是首字母，位于字符串第一个字符的字母就要搞特殊呢？
   到这里你应该发现了，这应当是搜索引擎与重定向该解决的问题，而不是靠忽略条目名中某个位置的字母大小写解决的。

3. 区分条目名大小写有助于保持全站的对同一条目指代的统一，从而体现专业性。对于有明确大小写的条目，如《bug》（PJSK国际服和国服都使用全小写的标题），忽略首字母大小写允许用户写出[[Bug]]而他却观察不到任何异样，我已经修正过很多这样的链接了。对于大小写未明确指定的条目，哪怕站外怎么乱七八糟地用，至少在站内达成统一也是赏心悦目的。

   反对首字母大小写敏感的人，是自己想“一会在这边用大写指代该条目所述对象，一会在那边用小写指代该对象”，还是在为某个你想象中如此随性的人着想？还是害怕有人写错了大小写而产生红链？那你怕不怕他把全大写写成仅首字母大写/全小写而产生红链？你怕不怕他打错了单词而产生红链？这可不是靠忽略首字母就能解决的。再说，红链可以在Special:需要的页面一览，可以方便地通过脚本检查所有红链有无仅大小写不同的条目，可倘若首字母大小写不敏感，写错了首字母的链接又从何查起呢？

4. 这不是投票。解决问题需要的不仅仅是摆态度，还要讲理由。
5. 这不是技术问题，而是决策问题，我们有技术人员可以解决所谓的技术问题。
6. 不用担心历史包袱，我有自动化工具可以解决。及行迷之未远。

注释：

——あめろ 2025年10月29日 (三) 05:29 (CST)

1. 为什么专属名词的翻译需要严格大小写？
2. 《39music!》的各种问题就应该忽略。
   • a.为什么不忽略《Angelfish(Patirchev)》“F”的大小写？
     • a.x.为什么不应该对《BETTER OFF WORSE》等非首字母的大小写进行非敏感处理？
3. 有需要但没有重定向那是编者的错误。至于“搜索引擎与重定向该解决的问题”，请问这个是什么问题，忽略非首字母的大小写吗？那重定向本来就应该去做。
4. 为什么需要“全站的对同一条目指代的统一”，难道需要所有人都强迫使用某个歌名的一种翻译，而且为什么应该存在重定向（指所有的重定向，并非首字母），那不是违背了你这句话吗？此外要知道即使是官方翻译也未必准确，B站内官方机翻的不在少数。
   • 既然“全站的对同一条目指代的统一”本身不合理，那后面那些话自然不成立。
5. 为什么默认大写？——

Lower（留言） 2025年10月29日 (三) 11:52 (CST)

第一点哈里说的更对。—— Lower（留言） 2025年10月29日 (三) 12:51 (CST)

只谈第一点

• Vocawiki是中文百科不代表所有内容都是中文，英文在标题句首书写中的普遍规范就是首字母大小写，这不是根据哪个平台是什么语言为主而改变的。
• 站内对于作品等的标题并不都是所谓专属名词，绝大部分都是社群给的或者纯粹就是机翻的中英文翻译，很多连P主本人都不知晓。既然不属于专属名词，那么更没理由对第三方名词进行规范。

哈里布莱（留言） 2025年10月29日 (三) 12:03 (CST)

先总结一下我对各个方案的看法吧，方案1在有方案3的情况下除了能多创建一个首字母小写的页面感觉没什么其他的优势，而且解决方案确实比较野；方案2能够保持标题与页面名的一致性；方案3不用修改各处内链的大小写，且能做到在页面与列表外显首字母小写标题。不过看起来方案3的实现是强绑定小写标题模板的，虽然这应该也没啥问题就是了。

我想“技术上”肯定方案2更好，但对于实际运行还是方案3更好。尽管方案2中内链的问题都能使用重定向解决，但本来是大写标题的写小写内链可能就比较痛苦了，而且这种大写标题可能本来就是在大小写都可以的情况下产生的，特别是在英文转写的假名标题上。如果用重定向解决这意味着会需要特别多重定向，但如果不用重定向解决好像也没什么理由要求各处都强制它大写。bug作为使用假名作为曲名的曲目但是能找到官方英文命名来源的还是少数，毕竟就连流媒体也全是用的Bug或BUG，那这样到底需要为它创建这些重定向页面吗。一边说站内达成统一一边说要用重定向，感觉还是有点微妙的。—— Dreammu（留言） 2025年10月29日 (三) 10:38 (CST)

关于图片分类树

目前本站对于图片的分类尚没有一个清晰的规划，悬置大量无分类图片无论对于本站站务还是读者都无益处。由此鄙人提议设立User:人间百态/图片分类树为本站在图片分类方面的临时性指引，待Vocawiki:条目格式/图片设立后将合并其中。若有问题和意见欢迎提出，我将不胜感激。--人间百态（留言） 2025年11月1日 (六) 17:15 (CST)

感觉诸如分类:可不这种分类跟分类:可不歌曲在主站混在一起有点奇怪……？要不要考虑换个命名格式 --AdorN讨论 ⏰︎ 2025年11月6日 (四) 11:40 (CST)

(▲)同上 ，同时个人对“歌曲或专辑的作者”的分类以及“按对象分类”部分是否需要存有疑虑，以及真人相关分类在当前的分类树中是移除状态，或尚需商榷。其他分类的思路大体认可。

另外之后分类树应当会形成一份文件，图片分类合并进入即可。——4O74Y74L74J7（留言） 2025年11月8日 (六) 21:34 (CST)

我倒是覺得恰恰相反，目前的分類系統需要一個容納歌姬相關圖片和歌曲的母分類。將歌曲分類納入這個母分類中在邏輯上也是說得通的。至於4O74Y74L74J7所屬意見這裏已做修改。另外關於分類樹問題，我認為關於圖片分類的內容比起放在該頁面放在圖片格式的頁面可能更佳。--人间百态（留言） 2025年11月8日 (六) 22:14 (CST)

Minerva删除后的残留相关需要清理

本讨论串已被存档。参见存档页：Vocawiki:讨论版/存档/2025年#Minerva删除后的残留相关需要清理