Vocawiki:討論版

各討論空間頁面最新動態

於指定時間內沒有符合條件的變更。

關於設立本站點的討論版

本主題或以下段落文字，移動自 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)

雖然有點岔開話題了，圖片頁面有建立單獨的格式要求的需要嗎，感覺除了分類也沒啥需要寫的吧（——4O74Y74L74J7（留言） 2025年11月8日 (六) 22:33 (CST)

有啊，圖片質量，圖片附錄信息，圖片版權。雖然現在講這些可能有些早，但早早的規範好圖片相關的問題未必是件壞事。 人間百態（留言） 2025年11月9日 (日) 17:09 (CST)

感覺叫「圖片管理方針」（或「文件管理方針」）更合適些？

如果要按照演唱者加分類的話不如直接用分類:可不歌曲，歌曲封面裡顯然不一定有歌姬，用分類:可不會造成困惑。當然如果圖里確實是歌姬的話大概沒啥問題。--AdorN討論 ⏰︎ 2025年11月9日 (日) 02:09 (CST)

Minerva刪除後的殘留相關需要清理

本討論串已被存檔。參見存檔頁：Vocawiki:討論版/存檔/2025年#Minerva刪除後的殘留相關需要清理