2023年政策修订增补工作正在进行中，欢迎参与！
  • Moegirl.ICU：萌娘百科流亡社群 581077156（QQ），欢迎对萌娘百科运营感到失望的编辑者加入！
  • Moegirl.ICU：账号认领正在试运行，有意者请参照账号认领流程。

萌娘百科討論:提案/未通過提案/關於標題符號問題的提案(2017.4.25)

萌娘百科，萬物皆可萌的百科全書！轉載請標註來源頁面的網頁連結，並聲明引自萌娘百科。內容不可商用。
跳至導覽 跳至搜尋

正文

提案緣由

在討論串[討論]關於條目標題中是否應當出現符號的問題中，各人對新的暫定規則仍有異議，且有人反映新規則描述不夠清晰，故提此案，以求進一步完善標題符號規則。

秋葉版新標題符號規則

下面是在經過眾多討論後由User:shirrak所寫，後根據User:Nostalgia提議之內容修改，且一部分管理層人員同意的新標題符號規則 

條目的命名原則上和條目描述事物使用的名稱一致，但是在基於搜索系統和技術限制等原因，仍然有一定的限制。

所有條目命名都應當首先使用大多數中文用戶最容易理解、最不容易混淆的文字，同時儘量確保其他人可以簡單且符合常識地連結到這些條目，除了要遵守命名規則之外，還應當遵守相關連結規則（消歧義和重定向），確保站內的連結的一致性，讓人有效地找到自己想找的內容。

為了方便其他人能順利找到內容，在遇上帶有符號的名稱時建議將沒有符號的稱呼，或者符號的變體版本稱呼重定向至有符号的称呼。

如果是同等规模的最常见译名，优先采用标点符号较少的译名作为标题。

由於技術限制，以下符號不能出現在條目命名中，但是你可以使用{{tl|標題替換}}一類的形式，在條目瀏覽時顯示那些符號。
:<code># < > [ ] | { }</code>
以下符号不能出现在条目名的开头：
:<code>% /</code>
以下符号不能出现在条目名的结尾：
:<code>/</code>

解釋

下面是對新規則的一些理解和舉例，由於本人才疏學淺，如有缺漏錯誤請指出。

  1. 在為詞條擬定標題時，應當儘可能選擇能被大部分用戶所識讀，並且不能超出《通用規範漢字表》中一二級漢字的範圍（即GB-2312字符集收錄的範圍）。如作品名中出現超出此範圍的漢字，則使用相近字建立詞條。
  2. 條目的命名需要能夠與站內已有連結的連結條目名一致，以讓用戶能夠更快地找到需要的內容。
  3. 在建立帶有符號的詞條後建議創建相對應的無符號版本重新導向
  4. 如遇到一個作品有多個譯名，且都為中國大陸常見譯名，選擇符號較少的收錄
  5. 以下符號禁止或有條件禁止出現在條目標題中，但是可以使用Template:tl的標題替換功能進行替換
    1. #，<，>，[，]，|，{，}不能出現在條目名的任何一處
    2. %，/不能出現在條目名開頭
    3. /不能出現在條目名結尾
  6. 除此之外除了在標準的104鍵或87鍵QWERTY鍵盤上能夠被輸入的符號外均不能使用。

如：Fate/kaleid liner 魔法少女伊莉雅 這樣的命名是允許的，但是Fate/kaleid liner 魔法少女☆伊莉雅這樣的命名是不允許的。（☆為不能被快速打出的符號）

千本樱這樣的命名是允許的，但是千本桜這樣的命名是不允許的。（非常用漢字）

NEW GAME!是允許的，但是NEW GAME!!是不允許的。（應當選擇符號少的命名，同時萌百站內已在大部分場合使用NEW GAME!，為了命名一致選擇前者）

以上，歡迎進一步討論

討論區

原討論串

在萌娘百科:條目命名中針對條目名稱中的特殊符號規定較為模糊，原文摘抄如下 

原则上条目名不应出现任何符号，能避免符号则不使用符号。当然有一些例外（比如消歧义，成系列等）。如果你不确定是否要加符号，请展开下面的【规范&例外】

规范&例外
（一）基本规范
条目名称中的标点符号(括号、冒号等)一般采用半角（英文）输入。
比如：【爱丽丝(旧作)】、【恋姬无双:诸葛亮】等。
为了方便习惯全角（中文符号）的用户，可以将全角的条目建立到半角的重定向。比如【爱丽丝（旧作）】可以建立到【爱丽丝(旧作)】的重定向。
另外，条目名称中请不要使用一些可能会与寻址符号、命令符号相冲突的符号，比如斜线(/)，英文句号(.)等。
（二）例外情况
外国人名的间隔号(中心点)——“·”(注)例外。英文中无此标点，中文只有全角，而半角的则是日文标点。所以外国人物名条目中的间隔号使用全角。除非你确信不添加“·”一定会导致混淆，否则请直接输入名称（如：赫敏，或者赫敏格兰杰）
成句类的条目，若中间有逗号“，”，使用全角逗号。如【○○很萌的，你们不要黑她】
必须要使用符号替代时，应使用可以方便打出的符号。

在實踐過程中，一些管理組成員對此方針解讀並不統一，部分人認為作品原名中的常見符號（如感嘆號，冒號等）應當保留，另一部分人認為不能出現任何符號，在此希望尋求一個具體的規範，以減少日後可能的爭執。--bbrabbitからの評論 #討論# 2017年4月3日 (一) 23:36 (CST)

圍觀。。建議 羅列出來吧--Zyksnowy（討論） 2017年4月3日 (一) 23:50 (CST)
個人認為一切使用中文或英文輸入法能夠在手機或鍵盤上輸出的符號都是可用的。
命名儘量貼近原名，以傳達完整的情感。--Shirrak（討論） 2017年4月4日 (二) 00:33 (CST)
觀點同上，我們完全可以將無標點進行重新導向，如果非要覺得標點影響搜索的話。 --巡查姬knt-sai~~あたしは天使じぁないわ【討論】 2017年4月4日 (二) 00:51 (CST)

衝突的符號指的是什麼，是不是要全部列出來比較好 --Yoonhakcher（討論） 2017年4月4日 (二) 01:57 (CST)

不接受的字符

  • 以下 ISO Latin-1 字符也不允許出現在頁面標題中：
# < > [ ] | { } /./ /../ �

#可以用♯或＃（全形）代替，< > [ ] | { }可以用＜＞［］｜｛｝（全形）代替（但只是特殊情況）。

  • 以下字符允許出現，但如果出現在標題開頭將導致不能連結：
% / ./ ../ : 半角空格 全角空格

% / :可以用％／：（全形）代替。

  • 以下字符允許出現，但如果出現在標題末尾將導致不能連結：
/. /..
  • 現時在條目名稱中可以使用"+"號。

維基百科:命名常規 (技術限制)

--Yoonhakcher（討論） 2017年4月4日 (二) 02:15 (CST)

一些相關的歷史討論列出備用：

個人認為現行規範沒有問題。一些續作和原作標題只相差符號，如我的妹妹哪有這麼可愛！和我的妹妹哪有這麼可愛。，如果要使用符號難以確定以哪個為主條目，同時全形半角也有時不好區分難以抉擇。因此應當儘可能不使用符號。

個人認為可能有爭議的是關於外國人人名中的分隔符的表述：除非你確信不添加「·」一定會導致混淆，否則請直接輸入名稱，這個一定會導致混淆不是很好界定，如果不能很好的解釋建議調整為的都加或者都不加。--W3jc（討論） 2017年4月4日 (二) 09:47 (CST)

引用部分討論：
【我提議刪除除非你确信不添加“·”一定会导致混淆，否则请直接输入名称（如：赫敏，或者赫敏格兰杰）】
【延續過去觀點，對大陸地區的瀏覽者搜索上沒有造成困難，中國一般打字軟體能輸入（漢字+26英文字母+一般標點符號）。希臘字母等特別符號換標題。「·」我是經常用的，支持用。】
都來自於Talk:討論版/存檔/2016年01月#重新啟動關於條目命名中標點符號的討論。但是任何一條都沒有得到重視。--Shirrak（討論） 2017年4月4日 (二) 12:25 (CST)

原名和常用譯名都存在符號的話，還是加上比較好吧，就算不考慮特殊符號，至少標點符號應該是沒問題

就算考慮到某些特殊符號不好打出來的問題，也應該是把不帶符號的簡寫形式重新導向到帶符號的完整形式

而且有些漢字比特殊符號還難打出來，甚至在部分設備上顯示不出來，比如鮟鱇魚--安迪布蘭頓大人（討論） 2017年4月4日 (二) 12:45 (CST)

考慮下這兩個條目：BanG Dream和BanG Dream!Girls Band Party
該系列作品的原文名里有一個嘆號（BanG Dream! 或 バンドリ!），而這兩個條目的名字，一個有嘆號，一個沒有
該把後面那個的嘆號去掉以保持同系列條目名一致嗎？然而後面那種明顯的主標題-副標題形式的名字，如果不用符號加以區分的話，不了解該作品的人甚至連斷句都會有歧義（如果是中文的話還可以用空格斷開，然而因為是英文，所以不可能單純使用空格斷句）--安迪布蘭頓大人（討論） 2017年4月4日 (二) 12:51 (CST)
用/搞成子頁面怎麼樣？--W3jc（討論） 2017年4月4日 (二) 17:42 (CST)
不反對將BanG Dream移動至BanG Dream!，也和分類一致。如果多數人贊同我會去移動。--Shirrak（討論） 2017年4月4日 (二) 18:25 (CST)

原則上條目名不應出現任何符號這一描述大家應該或多或少都知道。但是在實際應用的時候往往被尊重原作名稱的原因而豁免了規則。 ACGN作品中名稱帶符號的現象並不少見，不建議用硬性的規定直接制約，作品名稱中的符號有時也是不可或缺的。--The Patroller 雲霞貓♪ 2017年4月4日 (二) 12:57 (CST)

個人認為通常情況下應該尊重原作標題，保留中國一般打字軟體能輸入的符號，將不帶符號的名字重新導向到帶符號的名字

當然，如果原作名稱出現了很難打出來的符號，或者是導致條目無法被連結的符號，仍然得去掉--Ideal Patroller Akizuki（討論） 2017年4月4日 (二) 18:15 (CST)

@W3jcW君你在討論出結果之前直接將NEW GAME!相關條目更改，現在很多人也發表了觀點，也希望你能進行回應，之後再考慮相關操作。--Shirrak（討論） 2017年4月4日 (二) 23:09 (CST)

站長欽定了的還說什麼？當年就是因為我擔心有歧義才沒有動NEW GAME!的，現在只是補上這個操作，並沒有違反規範的地方。--W3jc（討論） 2017年4月5日 (三) 09:41 (CST)
冰娘當時在群中表明的是「看法」，但你無視其他人的見解就進行操作，上面這番話讓人感覺你不願意進行討論。晚上我或許會進行相關操作。--Shirrak（討論） 2017年4月5日 (三) 13:21 (CST)
個人希望討論是否可以把「鮟鱇」等處於擴展字符區的字詞納入「特殊符號」。
之前討論中有人將平假名、「☆」等符號都納入了特殊符號，理由是難以輸入。
擴展字符B區的字符同樣有這個問題，而且顯示上也得不到有效支持。--東山奈央（討論） 2017年4月5日 (三) 10:45 (CST)
鮟鱇疑似是mw的自動轉換，我在建立條目時輸入的都是鮟鱇。--Shirrak（討論） 2017年4月5日 (三) 13:21 (CST)
詞條名的建立不在自動轉換之列。現在已經移動完成鮟鱇魚、鮟鱇魚娘、鮟鱇魚舞曲三個詞條。--東山奈央（討論） 2017年4月5日 (三) 17:48 (CST)
不同意擴展區文字使用繁體，因為這些文字並不屬於特殊符號，而是屬於漢字，尤其是上面的𩽾𩾌，這兩個字是在大陸的《通用規範漢字表》中的國家規範漢字(詳見talk:鮟鱇魚)，更不應予以繁化(根據萌百的簡體中文命名原則)。建議不移動通用規範漢字表中的規範字。另外，若要求不使用擴展區文字，假設簡繁均在擴展區的元素Db, Sg, Bh, Hs, Ts, Og有了娘化形象和設定，條目該怎樣命名呢？—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 21:33 (CST)
漢字與技術上的特殊符號並不矛盾。特殊符號在計算機中，可以包括通用編碼以外的那些需要依存於環境的字符。
通用規範漢字表只能儘量去貼近，如果不符合使用條件的話也只能按照實際使用情形建立條目。--東山奈央（討論） 2017年4月6日 (四) 06:19 (CST)

根據上述看法總結為下：

  • 當原作品、原人物等名稱帶有符號時
  1. 若符號能被中國一般打字軟體輸入，如「!」、「%」、「~」等，可以使用，以爭取和原名保持一致。使用全形還是半角根據具體作品情況，一般情況下使用半角。若符號能被中國一般打字軟體輸入且不影響搜索等功能則可以使用，現階段能使用的符號，還有【! % & * - ~ +】。如果有後續的需要允許使用的符號，可在提問求助區提出，若判明無不良影響允許使用。符號不能作為頁面名第一個字符。除波浪線外，符號均使用半角改：2017年4月5日 (三) 21:34 (CST)
    • 可以出於方便搜索的理由將不帶符號的頁面名重新導向至帶符號的頁面名。
  2. 若符號不能被中國一般打字軟體輸入，如平假名和片假名，☆等，則不應使用作為頁面名。
  3. 儘量避免使用Unihan擴展B區漢字作為條目名。儘量避免使用Unicode擴展B區及以後漢字作為條目名。改：2017年4月5日 (三) 21:52 (CST)

不知是否合適？--Shirrak（討論） 2017年4月5日 (三) 20:57 (CST)

能被中國一般打字軟體輸入難以界定，不具備可操作性。如果一定要做到爭取和原名保持一致，建議列出所有可以在頁面名出現的符號。而所謂不能被中國一般打字軟體輸入的假名屬於日文字符，如果全部禁止需要修改規範簡體中文優先原則部分，且必須要求在條目名難以翻譯為中文或英文時不能創建，這對於新建條目十分不利。--W3jc（討論） 2017年4月5日 (三) 21:08 (CST)
不是標題一律半角符號嗎？ --巡查姬knt-sai~~あたしは天使じぁないわ【討論】 2017年4月5日 (三) 21:10 (CST)
關于波浪線有認為全形【～】比半角【~】效果好的看法。
既然認為「沒有可操作性」，先列出數個既不會引起搜索困難，又經常使用的符號作為允許之列。後續如果有需要的請在提問求助區提出。--Shirrak（討論） 2017年4月5日 (三) 21:21 (CST)
此外赫敏格蘭傑那個例子也該刪掉了。--Shirrak（討論） 2017年4月5日 (三) 21:24 (CST)
中國一般打字軟體如何定義？有些「一般打字軟體」可以打出擴展區文字—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 21:33 (CST)
另外，儘量避免擴B字，是指可以使用擴C，擴D，擴E和即將發布的擴F嗎？—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 21:35 (CST)
已經進行修改。--Shirrak（討論） 2017年4月5日 (三) 21:52 (CST)

進行了修改。成句（使用全形）和消歧義符號（半角括號與半角冒號）不在討論之列，在此加以說明。--Shirrak（討論） 2017年4月5日 (三) 21:34 (CST)

準確地說，應該是絕大部分「一般打字軟體」都可以打出假名和一些特殊符號( 別告訴我這個年代還有人用智能ABC) ，此外還有相當一部分輸入法可以輸入擴展區文字，至於顯示，以windows系統為例，vista及以後版本可顯示擴b，win8及以後可顯示擴c和擴d，最新的win10似乎還支持一部分擴e。如果要說手機的話，蘋果，三星，小米，vivo等品牌的手機有相當一部分型號至少可以支持顯示通用規範漢字表內的文字，個人認為輸入顯示困難不是不用擴展區文字的理由，望遠慮—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 21:54 (CST)
我很好奇萌百有多少使用XP的用戶，如果幾乎沒有，最多可以允許擴展B。然而根據你的表述擴展C及以後因為win7用戶的原因是無法使用的了。此外手機方面需要更多信息進行判斷，個人剛才試了一下，大量擴展B區的漢字無法顯示。--Shirrak（討論） 2017年4月5日 (三) 22:07 (CST)
手機方面，安卓系統的話只要使用思源黑體就能顯示部分擴bcde，三星小米等品牌默認是思源，而oppo等品牌可以在主題商店下載到思源。(win亦可通過裝字體實現更多文字的顯示，如思源黑，花園明朝等)擴b常用的只有很少一部分，而思源黑體是包括了全部通用規範漢字表內的擴展區文字的，這些文字包括:𠅤𠙶𠳐𡎚𡐓𣗋𣲗𣲘𣸣𤧛𤩽𤫉𥔲𥕢𥖨𥻗𦈡𦒍𦙶𦝼𦭜𦰡𧿹𨐈𨙸𨚕𨟠𨭉𨱇𨱏𨱑𨱔𨺙𩽾𩾃𩾌𪟝𪣻𪤗𪨰𪨶𪩘𪾢𫄧𫄨𫄷𫄸𫇭𫌀𫍣𫍯𫍲𫍽𫐄𫐐𫐓𫑡𫓧𫓯𫓶𫓹𫔍𫔎𫔶𫖮𫖯𫖳𫗧𫗴𫘜𫘝𫘦𫘧𫘨𫘪𫘬𫚕𫚖𫚭𫛭𫞩𫟅𫟦𫟹𫟼𫠆𫠊𫠜𫢸𫫇𫭟𫭢𫭼𫮃𫰛𫵷𫶇𫷷𫸩𬀩𬀪𬂩𬃊𬇕𬇙𬇹𬉼𬊈𬊤𬌗𬍛𬍡𬍤𬒈𬒔𬒗𬕂𬘓𬘘𬘡𬘩𬘫𬘬𬘭𬘯𬙂𬙊𬙋𬜬𬜯𬞟𬟁𬟽𬣙𬣞𬣡𬣳𬤇𬤊𬤝𬨂𬨎𬩽𬪩𬬩𬬭𬬮𬬱𬬸𬬹𬬻𬬿𬭁𬭊𬭎𬭚𬭛𬭤𬭩𬭬𬭯𬭳𬭶𬭸𬭼𬮱𬮿𬯀𬯎𬱖𬱟𬳵𬳶𬳽𬳿𬴂𬴃𬴊𬶋𬶍𬶏𬶐𬶟𬶠𬶨𬶭𬶮𬷕𬸘𬸚𬸣𬸦𬸪𬹼𬺈𬺓，思源黑體全部支持顯示。我的建議是:允許使用通用規範漢字表內的擴展區文字，通用規範漢字表外的也沒有太大意義，比如木字旁加個規的簡體字在擴e，win10和思源都不支持，這樣的字簡化也無益，不過通用規範漢字表內的建議使用。—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 22:21 (CST)
你剛才列出來文字後一半我電腦無法顯示。順便為了條目命名而要求手機用戶去安裝字體，是不是有點微妙感？--Shirrak（討論） 2017年4月5日 (三) 22:39 (CST)
＋1， 後半部分的字體無法顯示，這裡是Win10專業版。要讓訪客適應萌百，不如讓萌百適應訪客。附截圖：
300px
 —— 立花奏雪CFSO6459✉ / ☎ 2017年4月6日 (四) 03:26 (CST)
win10未裝其他字體時默認的顯示結果的確是這樣。我以手邊的幾個手機為例，一個小米，一個vivo，一個oppo，系統均為最新版本，前兩者默認即可顯示上面這些字，oppo默認不顯示，但主題商店有思源黑體，下載後支持顯示，別的手機大家也可以試一下。退一步說，你這裡顯示出來的字不是也包括「鮟鱇」二字了嗎，實際上電腦從win vista開始都可以正常顯示這兩個字，最主要的是，這些字在國家標準的《通用規範漢字表》中。—Signed message from Honoka55(Message me·My contributions) 2017年4月6日 (四) 18:04 (CST)
《通用規範漢字表》，該表中7708和8043號漢字分別為𩽾𩾌二字。—Signed message from Honoka55(Message me·My contributions) 2017年4月6日 (四) 18:07 (CST)
前面舉了顯示的例子，那我舉幾個輸入困難的例子。
我電腦端使用某權威輸入法，手機端分別使用IOS原生、國產安卓系統自帶、國產第三方輸入法，4種輸入法均無法打出擴展區的「鮟鱇」兩字，相反能打出繁體的兩字。
這種全滅的結果，我認為存在明顯的「輸入困難」。--東山奈央（討論） 2017年4月6日 (四) 06:19 (CST)
「國產第三方輸入法」的話，像搜狗、QQ拼音這樣不負責的輸入法(有「缺字報告」和「自造字」等行為)支持擴展區字體幾乎不可能，像rime或字海兩分之類的輸入法都能支持擴展區文字(雖然很少人用這些輸入法)。—Signed message from Honoka55(Message me·My contributions) 2017年4月6日 (四) 18:04 (CST)
現在使用生僻中文字符的問題來自兩方面。一個是難以顯示，這個可以通過將這些漢字在伺服器上預先渲染成圖片之後發送到客戶端解決(不常用的漢字的Unicode碼和常用的分開的，很好識別，然後圖片不需要預先生成，只要根據要展示的內容畫一下就可以），在複製時可以考慮替換為原來的文字；另一個問題是搜索時不能找到的條目問題，這個主要是由於現在是根據文字的內容進行匹配的原因，我建議通過伺服器增加根據拼音建立索引，也就是安康，鮟鱇，an kang 都匹配 鮟鱇 解決搜索的問題。 RFC - - Shelikhoo（討論） 2017年4月6日 (四) 10:15 (CST)
同意類似的做法，但不建議使用圖片。我建議使用webfont，即在網站中存著一個字體文件，在顯示這些字時調用此字體，為減小空間占用，可以對該字體中的文字進行篩選，只留下在萌百需要的文字「如𩽾𩾌」、{{萌元素周期表}}中的擴展區漢字的元素，把不用的文字刪掉，這樣只需要很小體積的字體文件，然後即可實現無需用戶自己安裝字體也能顯示了。用圖片代替的話，會出現很多問題—Signed message from Honoka55(Message me·My contributions) 2017年4月6日 (四) 18:04 (CST)
關於此問題，以前也有過討論，在這裡。@Imbushuo去做facefont了，然而不知道後來怎麼樣了(#滑稽)—Signed message from Honoka55(Message me·My contributions) 2017年4月6日 (四) 18:12 (CST)
請注意這裡討論的是條目名是否可以包含擴展字的問題。
顯示方面上述的所有方法都無法解決地址欄和瀏覽器標題欄的問題。順帶一提我對上述的WOTT方案的流量耗費是否實用存疑。
輸入方面，個人不認為拼音化索引的實現對於萌百現實，而rime等輸入法又會陷入「讓用戶自己去下載新東西才能使用」的困局。
另外說句對簡化字方案施行的個人看法，個人覺得不要過分追求規範化方案一刀切，為了規範而把使用弄得異常麻煩就本末顛倒了。"咲"字根據規範應該創建到"笑"。--東山奈央（討論） 2017年4月7日 (五) 07:37 (CST)
我並不認為拼音化索引有什麼技術上困難的地方： 將條目名稱轉化成拼音不難，根據拼音建立索引也不難， 把完全匹配內容在拼音匹配內容之前返回也沒有技術上的難度。 請指明有實現難度的步驟。然後，我提出使用圖片的方案的原因之一在於可以比較方便的只將展示本頁面需要的內容發送到客戶端，而不是準備一個字體來處理全部的情況。之所以我提出了使用圖片而不是WebFont就是因為實現WebFont的難度很大，跨瀏覽器的WebFont支持更是悲催，有時候要生成4到5種格式的字體，這對於根據頁面內容抽取出實際需要的字來說很難，無論是實現上還是性能上。地址欄和標題欄的問題確實無法通過我提出的方法解決。 - - Shelikhoo（討論） 2017年4月7日 (五) 09:35 (CST)
WM基礎上添加拼音索引搜索是在之前討論過的議題，並且被萌百程式設計師斷言實現困難並否決的東西，不需要展開討論了。
關於圖片，通過一個個漢字的編碼來由伺服器判斷是否顯示圖片也是顯而易見嚴重影響性能並且複雜的設計，叫一個現役萌百程式設計師過來都可以當場否定。--東山奈央（討論） 2017年4月7日 (五) 16:11 (CST)
首先是關於擴展漢字以圖片展示的這個議題，如果你認為這個操作對伺服器的性能有影響(實際上影響不大，因為每次頁面修改完之後只需要一次對內容的掃描就可以對於要轉換內容的提取，並不需要每次都進行完全的掃描)不希望在伺服器進行這個操作，這個操作完全可以放在客戶端進行，僅在需要的時候向伺服器發起請求得到圖片(而因為同一個漢字的樣子是一樣的，沒有客戶端數據，這個圖片可以被CDN緩存，要是不想自己搞這個直接用unicode.org的都行 )。 --Shelikhoo（討論） 2017年4月7日 (五) 18:11 (CST)
然後是關於建立拼音索引的問題，整個問題分為幾部分，首先是將標題轉化為拼音，建立拼音索引，然後在搜索的時候利用拼音索引搜索內容。以上三個步驟均可以使用現有的算法和技術解決。希望能給出之前討論的內容，防止不必要的討論。 --Shelikhoo（討論） 2017年4月7日 (五) 18:31 (CST)
只要你能親自上陣或找到一個萌百程序組的人來聲明在半年內實現他們，那就可以防止不必要的討論了。
大象塞冰箱也是3步。就拿第一步說，標題轉換拼音，我不認為能找到可以授權萌百使用的音節轉換資料庫，以及個人手動錄入更是天方夜譚。
此外從開發成本考慮的話以萌百現在的人力我認為上述兩個提案的實現日期是近乎無限期的。--東山奈央（討論） 2017年4月8日 (六) 04:17 (CST)
@东山奈央把大象塞進去的第一步User:九江月/字典。大概就是這樣吧，基本上常用字都有，你要說擴展區的……很多連發音都沒有的，感覺沒什麼意義。--九江喵~ 2017年4月10日 (一) 00:04 (CST)
我提出的這兩個功能均沒有技術上的難度，也不需要大規模的人工數據處理。至於萌百程式設計師的人力這方面我不熟悉。這裡我先提出實現的技術方案和流程，說明實現沒有技術上的困難，至於人力上的問題就需要優先級上的權衡了。
首先是這個標題拼音搜索。將文字轉化為拼音有非常現成的數據，而且還可以免費使用。下載 http://www.unicode.org/Public/UCD/latest/ucd/Unihan.zip 然後解壓會看到 Unihan_Readings.txt 這個裡面就包括全部Unicode支持的中文的拼音，然後根據 http://www.unicode.org/copyright.html 的授權， 裡面有 (Any person is hereby authorized, without fee, to view, use, reproduce, and distribute all documents and files solely for informational purposes and in the creation of products supporting the Unicode Standard, subject to the Terms and Conditions herein.) 完全可以任意的使用，如果裡面拼音的aeiou的音標不要替換一下就可以。 然後就是把這個數據導入資料庫，然後根據這個進行文字到拼音的轉化。另外，現在萌百已經支持根據拼音對類別內的項目進行排序，因此沒有理由認為不能實現文字到拼音的轉換。在進行了拼音到文字的轉換之後就是建立拼音索引的問題，無論是MariaDB還是MySQL，到PostgreSQL等MW支持的資料庫都帶有FTS(Full Text Search, aka Text Search)功能，對於拼音的內容可以直接進行比較高效的搜索，搞個fts Dictionary並不難吧。如果這個不想採用，想自己造輪子也可以，使用n-gram的方法，在key-value類似的資料庫(leveldb,redis,用關係資料庫當這個也可以但是出於效率原因不簡易)中也可以實現相同的功能，而且還可以為拼音進一步優化。首先，根據性能和優化需求建立兩個參數CM,CI代表最大最小的n-gram中的n，對於每一個條目的標題，轉換為拼音(多音字的話考慮全部可能)，之後使用n-gram分詞(未來甚至可以考慮自然語言分詞)後，對於每一個分出來的詞作為key，然後條目名作為value，存入key-value資料庫(比如CM=3，CI=2的情況下，伊莉雅 => YiLiYa => {YiLiYa,YiLi,LiYa},=>是箭頭不代表數組元素)，如果有重複的且資料庫不支持數組，那麼就附加到原來的value後面或者在key的後面加上計數，之後索引就搞定了。然後是搜索，如果搜索的內容是中文且長度大於CI，內置的搜索無結果或用戶翻到了最後一頁(額外的條件可以是用戶已經登陸)，就觸發拼音搜索。拼音搜索在將中文轉化為拼音(和分詞上)於之前的過程相同，然後直接自資料庫中搜索並展示就可以,可選的，如果輸入的是拼音直接進行拼音搜索(搜索 伊里亞 => YiLiYa =查詢=> 伊莉雅，如果輸入的是 里亞 => LiYa => 伊莉雅)。
然後是非常用字的輔助展示，這個更簡單，就是在客戶端執行腳本，在標題和正文搜索非標準字，如果有就套上div，把裡面原來的字的透明度改成0，背景設置為對應的圖片的位置(之前提到了，unicode.org就提供這個，http可以通過公用的圖片反代解決)，然後就好了。
我並不認為我上面說的有什麼實現上的難度，儘管可能萌百的開發團隊沒有時間來開發，但是應該沒有任何技術上的困難，而且是十分值得期待的功能。 --Shelikhoo（討論） 2017年4月8日 (六) 15:20 (CST)
萌百用 ElasticSearch 做搜索，這方面（拼音索引，分詞等）的解決方案其實已經有很多現成的了。現在的主要問題是，這個搜索似乎沒好好調優過，導致用起來跟(Beep)一樣。-Ben | imbushuo | AS43126 - Biscuit, cookie or whatever (Discussion) 2017年4月8日 (六) 17:51 (CST)
大概只剩下「能否有足夠的人手實現」了吧。其實我想說不如奧卡姆剃刀一下。--東山奈央（討論） 2017年4月9日 (日) 19:54 (CST)
稍微再牢騷一句，其實我和討論一直都在跑題。討論的主題在於條目名是否應該使用擴展區文字。
我個人持有的觀點一直是：既然特殊符號(☆等)這種對於ACG作品標題完整性至關重要的符號都可以被排除在之外，那麼由上述議題得出更多問題的擴展區漢字似乎也沒有保留於條目名中。
條目名基本只會影響到地址欄和連結的顯示，而這個是無法解決的。因此我認為對於條目名更適合迴避擴展區漢字。
關於頁面中的顯示，本來就可以使用模板將頁面顯示的非擴展區漢字轉換為擴展區漢字，因此使用非擴展區漢字並不會影響擴展區漢字在標題的顯示。--東山奈央（討論） 2017年4月9日 (日) 19:54 (CST)

關於標點符號的使用

條目里不贊成使用任何的標點符號。嚴格的說，大部分標點符號在url和頁面上多多少少都會引發問題。

以下幾個是不應該或禁止使用的符號

  1. 「#」是id選擇，表示書籤，會自動轉跳到對應的id標籤，不建議手動在頁面搞適配
  2. 「:」將有可能導致協議或埠錯誤，有著潛在的不可控風險
  3. 「/.」、「/..」、「/」、「./」、「../」是相對尋址，會將有可能導致頁面連結到錯誤的地址，所以應該禁止使用「/」和「.」
  4. 「？」、「=」、「&」、「<」、「>」、「'」、「%」、「+」可能會存在有xss漏洞、sql注入、轉義傳值錯誤等不可控風險，但「(」、「)」單獨使用時是安全的
  5. 「[」、「]」、「|」、「{」、「}」這些符號已經被模板使用，不應該用作條目名，以防產生歧義或不可控錯誤

以下幾個是不建議使用的符號

  1. 全形符號：全形半角切換麻煩，「(」、「)」應當統一使用半角
  2. 「-」（減號或連接符）、「 」（空格）、「——」（破折號），有可能會引起文件名命名不規範或歧義，應使用「_」代替，如出現butter-fly和butterfly這種在不使用「-」就很難消除歧義的特殊情況，這種時候應使用「-」來區分
  3. 「·」(間隔號/中心點)，由於編碼問題可能會出現歧義，常見於中文翻譯過來的人名，建議直接連寫或用「_」而不建議使用符號「·」
  4. 「~」（波浪號），一般被用於副標題，應使用「_」來分割主標題和副標題
  5. 「$」許多js庫中被常用來當作選擇器的的方法名，有可能會引發問題，但在js受限的情況下問題不是很大，反正看著不舒服就對了
  6. 「*」雖然問題不大，但是常被用作消字符，容易引起誤解
  7. 「^」基本沒什麼用，實際上也看不清，但在其它情況下可能會引發問題的符號
  8. 基本上鍵盤上不存在的標點符號儘量不要使用，這只會使得搜索效率下降

以下幾個是問題不大，可以安全使用的符號

「!」、「_」、「,」、「\」、「@」、「(」、「)」、「"」、「;」

是不是感覺很少？所以為了防止有部分人搞不清楚哪些可以用，哪些不可以使用，我的建議是儘可能不要使用。

--九江喵~ 2017年4月5日 (三) 22:14 (CST)

你列出來的很多我也不贊成使用，但是[]等一些已經被包含在了mw的無效標題中。
所以我列出來了括號里的幾個啊，以避免「搞不清楚哪些可以用，哪些不可以使用」。
順便你最後打出來的感嘆號還是全形的。--Shirrak（討論） 2017年4月5日 (三) 22:34 (CST)
好吧= =「！」的問題是我的鍋，所以說我才討厭來回切換全形半角啊。至於括號里的問題，在你發表回復之前我就在寫回復了，所以並沒有看到。標點符號這種，我覺得應該明確寫出黑名單和白名單，沒有被寫明的屬於中間地帶，具體情況具體判斷。--九江喵~ 2017年4月5日 (三) 22:42 (CST)
的確，之前沒有列出來是我考慮不太周到--Shirrak（討論） 2017年4月5日 (三) 23:07 (CST)
有關全半角問題，當我看到以「全形半角切換麻煩」這樣的敘述出現時我感到十分驚訝。各位正在使用的中文輸入，一般情況下都是以全形作為默認標點符號的模式，那麼既然如此前述的切換麻煩的問題是不存在的。--Yoonhakcher（討論） 2017年4月5日 (三) 23:30 (CST)
我是指在搜索的時候區分「！」和「!」、「（」和「(」、「）」和「)」等這些符號，由於是兩種字符，你得到的結果是兩個完全不同的搜索結果。如果沒有明確聲明，用戶不可能知道你的詞條到底用的是什麼，但你也不可能每一次遇到全形和半角的都做一次轉跳。這不但用戶搜索麻煩，維護也麻煩。所以這方面我是不建議使用全形的。另一方面，你也可能會問，那我中文用全形，英文用半角不就好了？關於這個疑問，我目前並不能給出很好的解答，原則上確實是可以，而且也是可行的方案，但個人覺得這並不是一種好的解決方案。使用半角符號只是一種命名規範而已，我只是不建議全形符號和英文混用而已。--九江喵~ 2017年4月5日 (三) 23:54 (CST)
條目標題中使用半角符號是規範的一部分，另外冒號在條目命名里沒什麼問題，不管是mediawiki自己的命名空間還是專題消歧義部分都大量使用了冒號。又不是放開頭的。--bbrabbitからの評論 #討論# 2017年4月6日 (四) 00:01 (CST)
關於冒號的問題，我不建議使用的原因是有可能造成命名混亂Template:Http://www.baidu.com/function:delete--九江喵~ 2017年4月6日 (四) 00:13 (CST)
目前使用冒號的只有作品名本身有冒號的和專題需要加冒號的。還沒有出現冒號導致命名混亂的地方。如果你是說消歧義混亂的話那是另一回事。--bbrabbitからの評論 #討論# 2017年4月6日 (四) 00:21 (CST)

那些什麼「大陸常用輸入法能輸入的符號」太沒有操作性了，越搞越複雜最後都沒有人遵守。萌百原則上禁止條目名出現符號的原因在於MW條目名直接就是URL地址，這導致符號出現會導致各種稀奇古怪的錯誤。上面一大堆討論只有 九江月 提到了。

  1. 例子有很多比如條目結尾英文句話.經常導致出錯，每次伺服器端都需要大量低效設置來繞過
  2. ?&$*!這幾個MW自己在用 （比如 zh.moegirl.org/index.php?title=Talk:討論版&action=edit&section=23 ）出現很有可能導致mw錯誤
  3. CDN緩存容易出現判斷錯誤，大部分大陸CDN的符號支持都是一坨屎，不用CDN在前面擋著分分鐘被dos下線
  4. 全形符號難以輸入
  5. 全形半角混雜問題多年來一直出現造成大量維護麻煩
  6. 用戶通常不知道/不記得符號，條目加符號導致用戶找條目困難。
  7. 符號不同導致用戶編輯困難
  8. 最後也是最煩人的就是每隔一段時間就有人來討論版打嘴砲說要澄清符號使用。然後我們又得把之前說過的不能使用符號的原因（或者不能使用哪些符號的原因）再說一遍。這個成本非常之高，尤其是採用某些符號可用某些符號不行時。每次都得詳細解釋。

最後【標題名】出現符號如果非常有必要，也是可以通過條目內重設標題名實現（即條目依舊是不帶符號，通過{{DISPLAYTITLE:标题名}}實現）。然而這依舊會導致用戶混淆標題。所以我還是堅持舊版的條目名禁止使用一切符號，除非是為了消歧義目的。並且清理萌百所有目前帶有符號的條目以命混亂繼續發展。 --多功能型Baskice(給我留言) 2017年4月5日 (三) 23:38 (CST)

  1. 條目結尾的英文句號很少見到，如影響性能就加入黑名單
  2. ?和&是url查詢參數而不是mw特有的。?會被自動忽略不能作為條目名稱，而&不再查詢參數中時就是普通的符號，mediawiki能夠正確處理。跟在?後時會因無效參數被忽略
  3. 現在國內大的CDN提供商已經可以對常見特殊符號進行處理
  4. 中文輸入法默認就是全形
  5. 這個情況現在正在改善，目前大部分帶有符號的條目都是半角
  6. 搜索功能不是吃屎用的
  7. 創建了條目之後其他用戶編輯並不需要討論符號問題
  8. 就是因為符號使用問題不清不楚才要討論，打嘴砲有意思？--bbrabbitからの評論 #討論# 2017年4月6日 (四) 00:18 (CST)
的確，&會被url編碼（https://zh.moegirl.org/index.php?title=舰队Collection:潜水舰搭载电探%26防水式望远镜&diff=1076603&oldid=1076533 ），不影響操作。--Shirrak（討論） 2017年4月6日 (四) 00:29 (CST)
節操醬一直沒有說話，因為看法和站長相同——認為應當禁止一切符號出現在標題。
1. 條目結尾的半角符號經常不被識別為網址（比如QQ裡面發連結）
4. 搜狗手機輸入法、谷歌輸入法[來源請求]等部分中文輸入法，默認的符號全半角混雜，比如經常有人把簽名打成了4個全形波浪線。
5/6. 有沒有符號、不記得符號、全半角符號等問題，節操醬也覺得很頭疼。重點是：萌百的搜索功能就是吃屎用的——搜索功能經常不穩定、反應慢，特別是之前有熊孩子發現了搜索功能有缺陷，通過搜索功能的bug把萌百打癱瘓了，萌百修復之後好長一段時間都關閉了搜索功能，不知道bb2同學有沒有印象。
 —— 立花奏雪CFSO6459✉ / ☎ 2017年4月6日 (四) 01:57 (CST)
在QQ裡面的連結但凡有漢字就無法形成連結，必須轉成URL編碼（右鍵複製連結）。在電腦QQ進行測試，【! % & * - ~ +】中除了「-」，位於句尾時都可以包含在連結內，轉成URL編碼就更不用說了。國際版一直死機沒有測試，手機版這些符號都可以形成連結。倒是「:」和「()」電腦版位於句尾時不被包含在連結內。
蘋果自帶輸入法默認符號也是全半角混雜，但是其又同時包含了全半角的波浪線等。如果說因為找不到，連mw的基本時間戳打成全形波浪線，那也很無奈。
之前說條目命名之所以帶符號是為了貼近原名，個人認為貼近原名是比較容易記憶的。
如果【】內的符號被證明有風險另論--Shirrak（討論） 2017年4月6日 (四) 09:00 (CST)
問題是搜索再吃屎平時要用啊。就算條目標題里沒有特殊符號大部分人也是在搜索框裡搜索條目關鍵字而不是直接在url里打連結吧。目前萌百搜索不出來的條目大多數也不是因為包含特殊符號，而是因為條目譯名和用戶輸入的譯名不相符。因此就算沒特殊符號也不能說我們就不開搜索功能了吧。--bbrabbitからの評論 #討論# 2017年4月6日 (四) 21:46 (CST)
坑爹的是搜索功能有時候根本用不了啊…… —— 立花奏雪CFSO6459✉ / ☎ 2017年4月7日 (五) 00:00 (CST)
如果是因為這些技術原因，把它們統統寫到條目命名裡面說明不就好了，不加說明總會有人提問。
全形難以輸入就統一使用半角。
【! % & * - ~ +】這些都是已經在一些條目中應用的，我想知道現有的是否一律改成空格。
{{DISPLAYTITLE:标题名}}的R旗標無法生效，T旗標才能實現標題替換（{{標題替換}}）。--Shirrak（討論） 2017年4月6日 (四) 00:02 (CST)
我對「全形符號難以輸入」存疑。中文輸入法下大部分常見符號都是默認全形。
其實有沒有人考慮在規則中添加強制使用半角空格？--東山奈央（討論） 2017年4月6日 (四) 06:30 (CST)
然而實際上完全禁止使用的符號應該只有「# < > [ ] | { } /./ /../ �」這幾個而已，這些大部分都可以通過使用其他近似符號（如全形等）替代來處理，剩下的那一小部分是根本不可能用來命名條目的
「?」和「&」用於條目命名時也可以被自動轉換成「%3F」和「%26」從而避免和URL參數混淆
除了這幾個符號之外，基本上都是安全範圍內
另外不建議大規模移動既有條目，也不建議無腦將符號替換為空格，因為有的符號在句中或標題中是有含義的（比如&就有「and」「和」的含義）--安迪布蘭頓大人（討論） 2017年4月6日 (四) 06:51 (CST)

基於上述內容再次總結如下：

將 

原则上条目名不应出现任何符号，能避免符号则不使用符号。当然有一些例外（比如消歧义，成系列等）。如果你不确定是否要加符号，请展开下面的【规范&例外】

规范&例外
（一）基本规范
条目名称中的标点符号(括号、冒号等)一般采用半角（英文）输入。
比如：【爱丽丝(旧作)】、【恋姬无双:诸葛亮】等。
为了方便习惯全角（中文符号）的用户，可以将全角的条目建立到半角的重定向。比如【爱丽丝（旧作）】可以建立到【爱丽丝(旧作)】的重定向。
另外，条目名称中请不要使用一些可能会与寻址符号、命令符号相冲突的符号，比如斜线(/)，英文句号(.)等。
（二）例外情况
外国人名的间隔号(中心点)——“·”(注)例外。英文中无此标点，中文只有全角，而半角的则是日文标点。所以外国人物名条目中的间隔号使用全角。除非你确信不添加“·”一定会导致混淆，否则请直接输入名称（如：赫敏，或者赫敏格兰杰）
成句类的条目，若中间有逗号“，”，使用全角逗号。如【oo很萌的，你们不要黑她】
必须要使用符号替代时，应使用可以方便打出的符号。

修改為 

原则上条目名应尽量避免符号。当然有一些例外（比如消歧义，成系列等）。如果你不确定是否要加符号，请展开下面的【规范&例外】

规范&例外
（一）基本规范
条目名称中的标点符号(括号、冒号等)一般采用半角（英文）输入。
比如：【爱丽丝(旧作)】、【恋姬无双:诸葛亮】等。
为了方便习惯全角（中文符号）的用户，可以将全角的条目建立到半角的重定向。比如【爱丽丝（旧作）】可以建立到【爱丽丝(旧作)】的重定向。
除了前述的半角括号与半角冒号，下列符号的半角形式：感叹号（!），百分号（%)，“与”符号（&），星号/乘号（*），横杆（-），波浪线（~），加号（+）也允许使用在条目名中。
条目名称中请不要使用一些可能会与寻址符号、命令符号相冲突的符号，比如斜线(/)，英文句号(.)等。
（二）例外情况
外国人名的间隔号(中心点)——“·”(注)例外。英文中无此标点，中文只有全角，而半角的则是日文标点。所以外国人物名条目中的间隔号使用全角。
成句类的条目，若中间有逗号“，”，使用全角逗号。如【oo很萌的，你们不要黑她】
必须要使用符号替代时，应使用可以方便打出的符号。如果有其他希望添加的符号，可在提问求助区提出，若不会影响mediawiki正常功能可以加入。

--Shirrak（討論） 2017年4月6日 (四) 21:45 (CST)

(！) 這樣改的話 沒有說明禁止使用其他符號，有可能還會造成未來的嘴砲。 —— 立花奏雪CFSO6459✉ / ☎ 2017年4月7日 (五) 00:00 (CST)

初衷是條目命名更貼近原名，如果原來的「必須要使用符號替代時…」這半句需要被移除，那麼個人希望改一下措辭，表明當有人使用了不包含在規定內但又不影響正常功能、不妨礙輸入的符號時，應該提示其有提出請求這一方式--Shirrak（討論） 2017年4月7日 (五) 00:13 (CST)
關於「/」和「.」，這兩個符號目前在萌百的條目中也都有出現，特別是前者在Fate系列的作品條目，以及部分成系列作品的子頁面中大規模出現。--安迪布蘭頓大人（討論） 2017年4月7日 (五) 14:25 (CST)

我大概整理了一下這些符號的常用情景，並分別做出了一些規則和處理辦法。只是個人意見。（栗子不涉及翻譯的字詞準確問題，而是討論符號使用情況。）

  1. 由於星號/乘號（*）在日語中經常被用作與英語做區別的符號，所以一般趨向於保留。但在不涉及與其它語言做區別或不會引起衝突的時候，一般不予保留。值得注意的是，日語裡的星號是五角的星號＊（萌百上表達的是六角的），但我們應該使用六角的星號*（在萌百上表達的是五角的）我能怎麼辦，我也很絕望啊。（Rhodanthe*與英語單詞重複，會產生歧義，應該保留；your_song*和your song會引起衝突，應該保留。《星恋＊ティンクル》不會出現衝突，這種情況下不應該保留，應該命名為例如「星戀Twinkle」。
  2. 百分號（%）在表意時一般趨向於保留，否則一般不保留，但千分號（‰）、萬分號（‱）等不應該使用，應用文字代替或尋求其它方式。《1000%SPARKING!》（魔法老師op），這裡就應該保留。《草莓100%》、，則可以命名為「草莓100%」或「草莓百分之一百」或「草莓百分百」。
  3. 橫杆（-）改1,只有在表達編號或專屬的英文詞的時候應該予以保留，其它情況下一般不使用，而是應該使用（_）下劃線替代。縮寫的情況下應該使用全名或者用「_」取代補充完整。SCP-173、ISO9000-1（3個0，不是ISO9001）等編號容易混淆不易識別，所以需要明確區分。butter-fly和butterfly容易衝突，應該予以保留。「non-fiction」（非小說類文學作品）、「no-brainer」（無腦、不必動腦的事情），這些原本就存在於單詞內的應該保留。C3 -シーキューブ-，先忽略「魔幻三次方」、「C3魔方少女」這類既有名字，在只考慮符號應用的前提下應該命名為例如「C3_C方塊」或「C方塊」，這裡的C3作者的意思是「Cube×Cursed×Curious」，也是縮寫的表意；《しゅがてん！-sugarfull tempering-》應該命名為例如「糖調_sugarfull_tempering」或「糖調」或「sugarfull_tempering」，因為這裡的是しゅがてん和「KanColle/艦娘」一樣屬於縮寫，而縮寫本身選用的時候應該迴避一些常用詞彙，所以不影響表意和消歧義。
  4. 與符號（&），趨向於一般不使用，而用「與」、「和」等字代替表意。《エスカ＆ロジーのアトリエ〜黄昏の空の錬金術士〜》應該命名為例如「愛絲卡與羅吉的工作室_黃昏之空的鍊金術士」，按波浪線規則也可以命名為「愛絲卡與羅吉的工作室」。
  5. 波浪線（~），多用於各種gal和書籍副標題，本身無意義，不用於區別語義，一般不應該使用。《宝石吐きのおんなのこ~ちいさな宝石店のすこし不思议な日常~》應該命名為例如「口吐寶石的少女_小小的寶石店和稍稍不可思議的日常」；《星空TeaParty えくすとら ～「恋愛」はじまりました！～》應該命名為例如「星空TeaParty_Extra_戀愛已經開始」。
  6. 叉字符（×），這個問題比較難以處理，雖然一般不使用，但依舊可能會出現丟失語義等一些問題。《黄昏乙女×アムネジア》，這裡的×應該使用小寫英文字母代替並在前後加上「_」，命名為「黃昏少女_x_失憶」，如不會與英文單詞產生歧義的情況下也可以命名為例如「黃昏少女x失憶」。但如《kiss×sis》，先忽略「親吻姐姐」這類既有名字，在只考慮符號應用的前提下應該命名為例如「kiss_x_sis」，這個時候不應該省略「_」。
  7. 中心點（·），常見於人名，也有可能出現在一些改進型號的命名上，趨向於一般不使用或用「_」代替。人名一般不會出現歧義，直接連寫即可。對於全名超長的人應該使用簡寫。如梵谷或文森特·梵谷（文森特·威廉·梵·高）、畢卡索或巴勃羅·魯伊斯·畢卡索（巴勃羅·迭戈·荷瑟·山迪亞哥·弗朗西斯科·德·保拉·居安·尼波莫切諾·克瑞斯皮尼亞諾·德·羅斯·瑞米迪歐斯·西波瑞亞諾·德·拉·山迪西瑪·特立尼達·瑪利亞·帕里西奧·克里托·瑞茲·布拉斯科·畢卡索）、亞里亞（神崎·H·亞里亞），簡寫中重名的以消歧義處理如「亞里亞（緋彈的亞里亞）」。對於日語中喜歡用作分隔符的情況，如セ・ン・パ・イ，在用作條目名的情況下，應予以忽略，命名為「前輩」。《新・ロロナのアトリエ ～アーランドの錬金術士〜はじまりの物語》應命名為「新羅羅娜的工作室_阿蘭德的鍊金術士_起始的物語」或「新羅羅娜的工作室」。禁千二百十一式・八稚女、七十五式・改這類東西應命名為「禁千二百十一式八稚女」或「八稚女」和「七十五式改」。
  8. 其它打起來麻煩又無明顯意義的符號，一般不應該使用或禁止使用。如：「↑↓←→」（各種方向的箭頭）、「♥/★/△/▽」（各種黑白底色的心/星符號、各種黑白底色幾何圖形）、「♪/♬」（各種n分音符）、「「/」」（日語引號不應使用）。
  9. 括號「(」、「)」增1，儘可能在詞條中迴避使用括號，括號應該是用以處理消歧義的，不應該用以處理條目中本身可能自帶的括號（雖然這種情況比較少見），如果出現不可調和的這種情況，應該使用「_」做當副標題處理。
  10. 感嘆號（!）增2，一般不保留。該符號一般不影響表意。某些比較特殊的詞條WORKING!!（第二季）、WORKING!!!（第三季）應該通過命名為「迷糊餐廳（第二季）」、「迷糊餐廳（第三季）」來區別。「NEW GAME!」應該命名為「NEW_GAME」。フルメタル・パニック！，在忽略「全金屬狂潮」的情況下，應該命名為「fullmelt_panic」或「全金屬恐慌」。
  11. 斜槓（/）增3，禁止使用，作為替代的要麼使用反斜槓（\）、要麼直接去掉、要麼使用「_」代替。《未来/珈琲 彼女の恋》應命名為「未來咖啡 她的戀愛」等。
  12. 英文逗號（,）、中文逗號（,）增4，需要視情況使用，，成句、小說、遊戲等條目，若中間有逗號，中文或翻譯為中文的時候，使用全形逗號，否則使用英文逗號。如【oo很萌的，你們不要黑她】。【nozuonodie_whyyoutry】。

增改於--九江喵~ 2017年4月7日 (五) 14:50 (CST)

上面這些與其說是規則，倒是更像指南。具體在什麼情形下使用這些符號，是取決於編輯者的意願和了解；而最起碼的，是寫明這些符號在某些情況可以使用。當然也歡迎你把這些總結單開一個頁面，比如Help:符號使用指南一類的。
中心點那個，原文專門針對的是分隔人名用的，所以日文作品中的中心點一般不會用全形中心點進行代替。--Shirrak（討論） 2017年4月7日 (五) 14:10 (CST)
需要注意的是_和空格是一樣的 --宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2017年4月7日 (五) 14:14 (CST)

投票區（假）

強行投票是沒有意義的，建議儘可能取得共識再進行提案。--W3jc（討論） 2017年4月7日 (五) 09:42 (CST)

上面該說的已經說完了，拖著也沒有什麼意義。--Shirrak（討論） 2017年4月7日 (五) 10:39 (CST)

同意和反對是針對哪些內容而言的？= =--安迪布蘭頓大人（討論） 2017年4月7日 (五) 14:26 (CST)

超囧，秋葉說的稀釋效應不錯，我先撤除投票再做些修改吧，下面的中立意見再開投票時會移動過去。開投票本意是針對<pre></pre>中的內容的。
關於斜槓（/），子頁面的形式進行使用是正常用途，此外Fate系列也有大量使用，比較好奇的是斜槓會不會影響其他性能。顯示方面，有模板{{NoSubpage}}，不會出現令人討厭的情況了。
關於「.」，想問下被應用到哪些頁面了？
此外還有個頁面想問一下，末日時在做什麼？有沒有空？可以來拯救嗎？這個頁面的問號是如何處理比較好，類似於成句嗎？--Shirrak（討論） 2017年4月7日 (五) 15:04 (CST)
斜槓沒有影響，但會讓正常詞條被系統誤以為是子頁面，冒號同理。所以個人建議遇到非子頁面和命名空間的冒號斜槓，用全形字符表示。 --宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2017年4月7日 (五) 15:15 (CST)
數碼寶貝大冒險tri.、SILVER LINK.、feel.
發現各種語言的維基也允許這種格式的條目存在（通常是縮寫會用到，雖然上邊這三個全都不是縮寫= =），看來應該不會有問題？--安迪布蘭頓大人（討論） 2017年4月7日 (五) 15:06 (CST)
fgo的斜槓（/）我覺得應該要麼用（\）代替，要麼用全形（／），要麼刪除，要麼（_）。「.」不和「/」一起使用基本不會造成危害。（？）不能和（=）同時出現。（#）用全形符號。全形符號的特例其實就「／」、「，」、「？」、「＃」、「。」--九江喵~ 2017年4月7日 (五) 15:20 (CST)
全形斜槓難以輸入，不在考慮之列。反斜槓就完全違背意思了。這樣的話把「.」僅允許用於條目尾，而「/」不允許用於條目開頭或結尾如何？
同時關於末日時在做什麼？有沒有空？可以來拯救嗎？這個條目，把句中的全形「？」改成半角「?」，再去掉句尾的問號不知如何……
此外關于波浪線還有個麻煩的地方，最後是使用全形還是半角（之前副標題那個也有提到），不然容易造成混淆。--Shirrak（討論） 2017年4月7日 (五) 15:28 (CST)
我覺得要保留就三個問號一起保留，在標題里「?」會轉換成「%3F」所以一般不會有危險。或者直接沿用全形問號--安迪布蘭頓大人（討論） 2017年4月7日 (五) 15:35 (CST)
那麼在成句相關的部分加一條「或結構類似成句的條目」吧。長標題裡面有各種例子，比如於紫陽花盛放之際、同你相戀…--Shirrak（討論） 2017年4月7日 (五) 15:38 (CST)
  1. (＝)中立 --Yoonhakcher（討論） 2017年4月7日 (五) 11:10 (CST)

稀釋效應

過多的論述，會淡化提出的觀點，也讓人沒有心思看完，這就是稀釋效應。我也灌點水。

首先關於標題【條目標題中是否應當出現符號】，目前百科的有兩類條目使用完全不同的符號使用規則。成句是正常使用全形的標點符號的，而對於作品和人物條目符號使用確是完全不同。

上面扯那麼多全形很難輸入阿，在2012年建站早期，站長閣下不也是用全形符號寫成句（一對百合一對基，剩下一個是苦逼）。說全形什麼什麼是完全忽略萌百兩個系統同時存在的事實，一邊可以，一邊不可以，個人認為這才是引起全形半角使用爭議和疑惑的最大原因。

另外說到什麼為何?&$*!MW會誤判，那不就是為何維基百科用全形符號，不就是因為怕誤判嗎！？

由於搜索系統的問題，導致整個命名規則都要遷就它？這是不是太本末倒置，本來有符號的條目，創作人大多會以重新導向處理，方便搜索，都重新導向了，有符號沒符號都能搜索得到，有差嗎。考慮實際重新導向維護工作，這個搜索系統的問題根本是偽命題，因為進行了維護的條目，都有相關的重新導向。（搜索系統自改了以後，真心不行，我平時是什麼都搜索不到的。因為繁體字是搜索不到簡體命名的條目的。那麼問題來了，我是否應該搞一堆重新導向來幫助搜索？）--Notalgia-Contαct- 2017年4月6日 (四) 22:37 (CST)

是的，還請大量創建重新導向，要辛苦秋葉來維護了（笑） —— 立花奏雪CFSO6459✉ / ☎ 2017年4月7日 (五) 00:00 (CST)
以前是好好的，攻擊後，換了新系統是啥玩意都搜不出來，以那個搜索系統來說明，可以說出的笑話可多了。--Notalgia-Contαct- 2017年4月7日 (五) 23:23 (CST)
還有大陸地區用戶常用的貼吧q群微信這些，帶符號，尤其是URL結尾符號經常會識別不全引起錯誤--多功能型Baskice(給我留言) 2017年4月6日 (四) 22:53 (CST)
貼吧q群來個中文就沒法識別，要不咱不做中文百科了？--bbrabbitからの評論 #討論# 2017年4月6日 (四) 22:57 (CST)
我插一句，?&$*!這些符號在萌百當前版本的mw中均可以正常作為條目名稱，無論是出現在名稱頭、名稱中間和名稱尾部。不會引起mw的程序錯誤，也不會引起在條目內的引用不能成連結的問題。——Zyzsdy（討論） 2017年4月6日 (四) 23:52 (CST)
上面就是不斷有人強調什麼符號，什麼全形有什麼危險性，麻煩性，就是沒有想想現實是怎樣。正如你說【當前版本的mw中均可以正常作為條目名稱】，那麼符號的危險性，個人認為他們有些過分誇大了。
符號的使用對搜索什麼的，現在是還有人什麼都搜索不到，那麼是不是該反過來思考去改進搜索系統，還說遷就那麼系統，是不是不合實際。說真的現在搜索系統那麼糟糕，分類系統的優越性就出來了（笑），分類就是在搜索沒什麼用的時候用來找資料的。
沒有任何系統是完美的，上面的討論就是一直的什麼MV，搜索系統，人類行為心理學（搜索習慣，打字習慣）這些高大上的觀點上說，是不是有些堅離地。那麼實際上呢，就算有沒有符號，搜索上還是會有問題，標題不用標點，那麼用上帶有標點的標題搜索的人，搜索上不是一樣有困難，好像上面沒人想過這方面。
土辦法一直都有就是【重新導向】，處理符號問題，必須和【重新導向】一起說，因為這是兩條腿走路的問題。--Notalgia-Contαct- 2017年4月7日 (五) 23:23 (CST)

奧卡姆剃刀

上面有人一個一個符號說，有志氣。

實際上標題的命名方式是多種多樣的，過去的討論我也說過，暴走P的某專輯【オマエが歌うのかっΣ（´д｀； vol.1 】還有顏文字。

很多人不理解我提出的大陸輸入法論，這是一個接地氣的通俗說法，在肉食者在為了那個符號能用，那個符號不能用糾纏的時候，對於大部分人來說，我就是打幾個字，跟著創建條目。無法輸入就是複製粘貼的符號和字。我相信大部分人都是在用【QWERTY鍵盤】，打英文都是26個英文字母，打中文都是用3000多個常用字。而不是有空打希臘文，去打《康熙詞典》或者《說文解字》的生僻字，平時都用火星文的有為青年。

有些問題過度解讀了，過些問題過於學術了。讓我們用一下奧卡姆剃刀吧。--Notalgia-Contαct- 2017年4月7日 (五) 23:23 (CST)

濃縮

再次總結如下，將原文： 

原则上条目名不应出现任何符号，能避免符号则不使用符号。当然有一些例外（比如消歧义，成系列等）。如果你不确定是否要加符号，请展开下面的【规范&例外】

规范&例外
（一）基本规范
条目名称中的标点符号(括号、冒号等)一般采用半角（英文）输入。
比如：【爱丽丝(旧作)】、【恋姬无双:诸葛亮】等。
为了方便习惯全角（中文符号）的用户，可以将全角的条目建立到半角的重定向。比如【爱丽丝（旧作）】可以建立到【爱丽丝(旧作)】的重定向。
另外，条目名称中请不要使用一些可能会与寻址符号、命令符号相冲突的符号，比如斜线(/)，英文句号(.)等。
（二）例外情况
外国人名的间隔号(中心点)——“·”(注)例外。英文中无此标点，中文只有全角，而半角的则是日文标点。所以外国人物名条目中的间隔号使用全角。除非你确信不添加“·”一定会导致混淆，否则请直接输入名称（如：赫敏，或者赫敏格兰杰）
成句类的条目，若中间有逗号“，”，使用全角逗号。如【oo很萌的，你们不要黑她】
必须要使用符号替代时，应使用可以方便打出的符号。

修改為 

條目的命名原則上和條目描述事物使用的名稱一致，但是在基於搜索系統和技術限制等原因，仍然有一定的限制。

所有條目命名都應當首先使用大多數中文用戶最容易理解、最不容易混淆的文字，同時儘量確保其他人可以簡單且符合常識地連結到這些條目，除了要遵守命名規則之外，還應當遵守相關連結規則（消歧義和重定向），確保站內的連結的一致性，讓人有效地找到自己想找的內容。

為了方便其他人能順利找到內容，在遇上帶有符號的名稱時建議將沒有符號的稱呼，或者符號的變體版本稱呼重定向至有符号的称呼。

如果是同等规模的最常见译名，优先采用标点符号较少的译名作为标题。

由於技術限制，以下符號不能出現在條目命名中，但是你可以使用{{tl|標題替換}}一類的形式，在條目瀏覽時顯示那些符號。
:<code># < > [ ] | { }</code>
以下符号不能出现在条目名的开头：
:<code>% /</code>
以下符号不能出现在条目名的结尾：
:<code>/</code>

--Shirrak（討論） 2017年4月7日 (五) 23:11 (CST)

討論區

如果沒有特殊情況的話，就在一天後開始投票了？--Shirrak（討論） 2017年4月9日 (日) 02:36 (CST)

建議細化可以使用符號的情況。--W3jc（討論） 2017年4月9日 (日) 09:07 (CST)
現在的情況大概又是沉默既共識了。建議延長咨詢期，怕又有人事後說看不到，之後搞什麼反對意見區。--Notalgia-Contαct- 2017年4月9日 (日) 09:06 (CST)
倒數第二條表述很奇怪，雖然明白你的意思。「形式類似成句」這個描述也很曖昧，為保持統一性個人認為不屬於成句風格的標題也應該適用該規則。要不要考慮「實體全名適用」或者「非功能性符號」的表達方式？
然後規則沒有考慮「非中文標題」的情況，比如「NOW LOADING!!!!」若是適用倒數第二條的話，就會使用全形符號而變得很奇怪。
最後個人覺得應該給命名規則加上一條「同等規模的最常見譯名上，優先採用標點符號較少的譯名作為標題」。--東山奈央（討論） 2017年4月9日 (日) 19:54 (CST)
有點想當然了，以為非中文系列理所應當用半角，我去寫明。表述的話我調整成「功能性符號」吧。
最後這條會加上。--Shirrak（討論） 2017年4月9日 (日) 22:44 (CST)

問題還是很多，比如斜線/用於子頁面而不應作為條目名使用，感嘆號（!），百分號（%)，「與」符號（&），星號/乘號（*），橫杆（-），波浪線（~），加號（+）這些最好就不要加，也就不需要特別為成句再分什麼逗號，問號？。條目名需要間隔時用空格替換逗號--多功能型Baskice(給我留言) 2017年4月9日 (日) 22:51 (CST)

那樣的話就又回到原點了……「/」的話在Fate系列中使用較廣，有一定重要性。--Shirrak（討論） 2017年4月9日 (日) 23:02 (CST)
能夠加符號的原因上面已經討論的很清楚了，秋葉也表示就算去掉符號搜索系統的問題也還會存在，而且很多人直接用作品名搜索也會搜不到。再說去掉所有符號再加重新導向完全就是增加管理人員和伺服器負擔的吃力不討好的事情。--bbrabbitからの評論 #討論# 2017年4月9日 (日) 23:15 (CST)
然而使用符號也會帶來維護上的不便，例如和wiki系統衝突的符號如何處理、一個作品的衍生為多個名稱以哪個為主條目、符號大小寫不確定時如何抉擇等等。--W3jc（討論） 2017年4月10日 (一) 13:05 (CST)
衝突問題前面已經說過，mw會自行處理，不影響功能。
衍生為多個名稱這不是翻譯問題嗎？後來也加上了「優先使用符號少的譯名」。
符號大小寫是什麼？全形半角？半角全形相關寫的已經很清楚了。--Shirrak（討論） 2017年4月10日 (一) 13:12 (CST)
建議舉出一些例子來幫助大家理解。--W3jc（討論） 2017年4月12日 (三) 18:56 (CST)
我倒是很希望你舉一些例子，來看看如何解決呀……--Shirrak（討論） 2017年4月12日 (三) 19:23 (CST)
我的妹妹哪有這麼可愛！/我的妹妹哪有這麼可愛。 NEW GAME!/NEW GAME!! 俺物語！！ Now Loading!!!! 潛行吧!奈亞子 變態! 鎖鎖美同學@提不起勁 ZERO-G Black★rock shooter again & again Fate/Zero 索菲的工作室～不可思議之書的鍊金術士～ planetarian～星之人～/Planetarian ～星之夢‎～ ONE～輝之季節～ ‎ Saya's Song 艦隊Collection:16inch三連裝砲 MK.7+GFCS 降水概率80％→10％--W3jc（討論） 2017年4月13日 (四) 22:48 (CST)
我的妹妹哪有這麼可愛！是重新導向，NEW GAME!包含在上述規則中，俺物語！！是重新導向，Now_Loading!!!!、潛行吧!奈亞子、變態!包含在上述規則中，ZERO-G包含在上述規則中，Black★rock shooter是重新導向，again & again、Fate/Zero包含在上述規則中，艦隊Collection:16inch三連裝砲 MK.7+GFCS包含在上述規則中。
拋開紅鏈，需要考慮的是索菲的工作室～不可思議之書的鍊金術士～中的波浪線，根據目前的方案可以移動到半角波浪線；降水概率80％→10％中的箭頭可以改為橫槓。舉例子的時候還是建議慎重一點，太急效果不好。--Shirrak（討論） 2017年4月13日 (四) 23:11 (CST)
我的意思是具體列出這些條目該以什麼為條目名，否則我也可以說去看規範啊現在的規範都已經有說明了。--W3jc（討論） 2017年4月15日 (六) 15:04 (CST)
意思就是其中的一大半可以保持原名。不過現在規則已經被改動了。--Shirrak（討論） 2017年4月20日 (四) 07:51 (CST)
補一句，關於Fate的斜線問題我覺得用不墨守成規來解釋比較好。斜線本身確實是功能性符號，其他情形還是儘量避免為佳。但是整個Fate系列的標題都可以按照子頁面來解釋，很容易曲線救國，不需要更改。--東山奈央（討論） 2017年4月10日 (一) 17:11 (CST)
本來就可以用全形重新導向到半角的條目，現在是說半角什麼什麼影響，最簡單的方法就是用全形，半角的重新導向到全形的。反正都有重新導向，相較之下，反而全形不會引起上面提到的什麼子頁面的問題。
總感覺在某些A問題有迷之執著，跟著就因為這個執著引申出B、C問題，轉到說B、C問題上，明明解決了A問題，就根本沒有B、C問題。--Notalgia-Contαct- 2017年4月11日 (二) 21:37 (CST)
之前很多條目使用符號時用的是半角，比如半角感嘆號搜索了一下有300+條目，全形感嘆號不到100個，而且大部分是重新導向，所以想著是根據既有現象進行調整，畢竟不會有特別重大的差異。--Shirrak（討論） 2017年4月12日 (三) 19:23 (CST)
不如用斜槓還是用%2F吧。--九江喵~ 2017年4月12日 (三) 19:43 (CST)
在規則中寫著的，可以做的事情，需要做的事情，很多人都是選擇性看到【原則上條目名不應出現任何符號】，沒有看到可以用帶有【半角】、【全形】符號的進行重新導向，逆轉思考，當有【半角】、【全形】都有對相關條目進行重新導向，都具有合理性，「王車易位」本身的操作也具有合理性
而全面進行【全形】一方面避免上面提到的【半角】的潛在風險，也避免了成句使用【全形】造成的思想混亂，也保證了條目名稱的完整性（英文名用【半角】）。
糾結於保留標題與否，還是【半角】和【全形】與否，根本上就是個思維慣性。不能接受A不行就用B的想法。
對於規則上的【原則上】，我的理解是改革開放時期的「不宜提倡，不要公開宣傳，也不要急於取締」，關於符號的描述本身有其局限，那是根據只是收錄人物的時期制定，對於作品名稱的多樣化，沒有考慮到，而後來的實際操作，作品名有符號的名稱定向到沒符號的也是允許的，而且一些作品名帶有符號也保留至今，除了上面提到的Fate系列還有《LoveLive!》等，符號本身已經是作品名一部分。
條目命名就不是零和遊戲，是共融的，容許各類命名方式存在，只是那一個主次，我認為很多人都需要認真想想現實到底萌百是怎樣，那些條目都是怎樣寫出來的，一些議題反復出現，並不是空穴來風。--Notalgia-Contαct- 2017年4月12日 (三) 23:36 (CST)
全形有其便利，比如說會被統一url編碼，解決成句問題。但是在純英文的條目時，還是要面對半角，這和在成句時面對全形是一樣的。
而且某種程度上我不是很希望看到有生之年一類的改動，雖然批量替換能幫上一些忙。
到底我只是試圖以規則化來使符號使用合理化，避免一些移動。如果說不嚴謹但過於細密的規則限定了條目編寫，我個人不介意放棄這些規則。
或者針對全使用全形符號，明天再寫出另外一個方案來做選擇。--Shirrak（討論） 2017年4月13日 (四) 00:02 (CST)
規則本身並沒有寫得那麼死，也就是解讀的人轉到了牛角尖。
過去從簡化命名到全名原則的改動也沒有造成太大的問題，就算對比需要調整的內容所佔比例，萌百需要進行標點調整的佔總體比例並不是太多。
有時候並不是需要一朝反復，任何改變都需要適應期和轉換期。共筆型百科不是計劃經濟，現實上也是維護人員也不可能調動全部人去進行調整。
規則等多屬於是自由市場下的宏觀調控，引導出良性的發展和創作趨勢。簡單來說就是「格式是用來規範，而不是用來局限創作的」。--Notalgia-Contαct- 2017年4月13日 (四) 22:11 (CST)
那麼如果不對規則進行更改，是否還是難以保證不過度解讀的出現？個人是不願意看到這種移動來移動去的，但也擔心日後會有類似的論戰。想知道秋葉桑你認為規則是否需要進行變動，或是哪些變動。--Shirrak（討論） 2017年4月13日 (四) 23:11 (CST)

新官上任三把火，姑且越俎代庖，接一下火把。

基於個人的局限和偏見，我會選擇重製整段說明，以下是參雜了隔壁維基相關規則的重製版： 

條目的命名原則上和條目描述事物使用的名稱一致，但是在基於搜索系統和技術限制等原因，仍然有一定的限制。

所有條目命名都應當首先使用大多數中文用戶最容易理解、最不容易混淆的文字，同時儘量確保其他人可以簡單且符合常識地連結到這些條目，除了要遵守命名規則之外，還應當遵守相關連結規則（消歧義和重定向），確保站內的連結的一致性，讓人有效地找到自己想找的內容。

為了方便其他人能順利找到內容，在遇上帶有符號的名稱時建議將沒有符號的稱呼，或者符號的變體版本稱呼進行重定向。

由於技術限制，以下符號不能出現在條目命名中，但是你可以使用{{tl|標題替換}}一類的形式，在條目瀏覽時顯示那些符號。
:<code># < > [ ] | { }</code>

「要把一件事情做好，最重要的就是教育領導」，維護人員對規則解讀的統一性，才能保證規則能有效地作用。對任何規則的合理思辨都是有正面的作用的，畢竟任何規則也存在漏洞，需要的是靈活的應變機制。就如最近我對Help:消歧義頁的補充那樣，舊式的方式可以慢慢改，允許兩種類型的命名方式存在。

對於技術限制的部分，我是參考隔壁維基Wikipedia:Naming conventions (technical restrictions)，又補充的，就補充吧，隔壁維基對很多符號的使用都有詳盡的說明舉例，以及既有的討論結果形成的規則，畢竟隔壁家大業大，遇到的情況比萌百豐富多了，實踐也比我們多。--Notalgia-Contαct- 2017年4月14日 (五) 11:07 (CST)

以這個為主體，修改了相關內容。個人希望編輯者不會因為符號被禁用而受到困擾。
某種程度上我也不願意寫出來一個長長的符號使用說明，對於編輯者來說是一種負擔。--Shirrak（討論） 2017年4月15日 (六) 16:48 (CST)
其實不用你寫，隔壁維基就有現成的，除非萌百裝了什麼奇怪插件，導致和同樣使用Medaiwiki的維基有差異，否則那些規則都是通用的。--Notalgia-Contαct- 2017年4月16日 (日) 10:48 (CST)
我不反對這個方案，但是個人擔心這個開放會引發不少潛在的編輯戰。
不過本人認為若實行這個方案，不妨將限制命名歧義上的內容統一移動到命名規則下，功能上將符號使用規範和命名限制規範分離。--東山奈央（討論） 2017年4月17日 (一) 09:38 (CST)
可能有些稀釋了，所以才說「維護人員對規則解讀的統一性，才能保證規則能有效地作用。」，有問題就問，不要藏匿。
那段文字的修改雖然是對【符號使用說明】的修改，但是也要考慮到條目命名的其他部分的整體性。斷章取義，轉牛角尖的情況是要避免。
開放符號，就要對條目命名的定義進行更多的描述「最容易理解、最不容易混淆的文字，同時儘量確保其他人可以簡單且符合常識」其實和我之前提到大陸一般打字軟體可輸入的內容是異曲同工的，火星文和大部分異國文字就一定不再允許行列之內了。--Notalgia-Contαct- 2017年4月17日 (一) 22:21 (CST)
這個比較稀鬆的方案也有它的好處，如果是尋求極端的命名，自然會被大家分辨出來。不出意外的話就今晚開始投票吧……--Shirrak（討論） 2017年4月18日 (二) 15:12 (CST)
(☩)意見 我想了一下，雖然@Nostalgia的主張我是認同的，但是單獨這個規則修改實質上沒有解決任何問題，很多問題點都被擱置。
如果真的放開限制，我建議配套建立一套條目命名的備忘錄，來記錄放開本限制之後涉及到的命名爭議的結果以便查閱和參考。--東山奈央（討論） 2017年4月20日 (四) 04:26 (CST)
是一個不錯的辦法。--Shirrak（討論） 2017年4月20日 (四) 07:51 (CST)
如果是類似萌娘百科_talk:提案/未通過提案/關於社區共識存檔機制的提案(2016.03.30),很抱歉，當年就沒有搞出來。就算以這個思路走，也會浪費不必要的人力去搞那些歸檔，去應付那些冗長，重複的問題。說實在，在不少論壇上也經常有，就算你指引寫到最小的地方，仍然有人不看指引，根據模糊的感覺來找茬。很多時候我只想說RTFM。--Notalgia-Contαct- 2017年4月20日 (四) 12:45 (CST)

（也許會是）投票區

正在加載中……
本次投票由Shirrak（討論 | 貢獻 | 封禁 | 用戶組）發起。
  • 投票開始時間：2017年04月18日 13:34 (UTC) | 2017年04月18日 21:34 (CST)
  • 投票結束時間：2017年04月25日 13:34 (UTC) | 2017年04月25日 21:34 (CST)
  • 投票總用時7天，正在計算中……

  • (＝)中立 我比較想看到一個整體重寫的版本，而不是僅僅修改以前的敘述，舉例儘可能詳細一點就更好了。重製版希望！--Yoonhakcher（討論） 2017年4月12日 (三) 20:24 (CST)
  • (＋)同意 --安迪布蘭頓大人（討論） 2017年4月19日 (三) 15:25 (CST)
  • (＋)同意 --bbrabbitからの評論 #討論# 2017年4月21日 (五) 22:04 (CST)

(☩)意見 不清楚具體修改細節，無法參與投票。建議列出與現行規範的對比、舉出示例，或通過提案方式進行。--W3jc（討論） 2017年4月23日 (日) 18:51 (CST)

我嘗試總結一下：
將規範中對命名的強制規則取消（比如是否平半角、是否使用特殊符號），將限制的職能下放到命名規範中，僅保留對因技術原因無法使用的字符的限制。
實際舉例來說以往「不能使用特殊符號、符號的全形半角」的限制全都取消，由命名規範和編輯者的知識範圍約束住。因為當下規則脫離了實質執行情況和使用習慣，而進一步限制會導致規則過分複雜，因此規則從簡。--東山奈央（討論） 2017年4月24日 (一) 08:45 (CST)
太過空泛的問題，讓人無法進行回應。對於空泛而大的問題，我也只能給出空泛而大的回應「隔壁維基對很多符號的使用都有詳盡的說明舉例，以及既有的討論結果形成的規則，畢竟隔壁家大業大，遇到的情況比萌百豐富多了，實踐也比我們多」，對符號的任何疑問，可以先到隔壁維基看完，維基哪裡那些看不懂，在仔細說。--Notalgia-Contαct- 2017年4月24日 (一) 21:58 (CST)
有人自告奮勇寫的，但是看了下維基，大部分符號似乎都是開綠燈，更多的規則是由於其收錄範圍的廣度決定的，所以我不是很想把符號使用具體到哪個符號應該如何如何，該刪還是不該刪，該移動還是不該移動。對維護人員我覺得其次，對編輯者實在是個大負擔。
似乎還剩下24小時，現在的結果看起來還是蠻尷尬的，還是說拖的時間太長了，慢慢都忘記了……--Shirrak（討論） 2017年4月24日 (一) 22:14 (CST)

(☩)意見 只要符合命名規範，並且是有效字符且系統支持，便沒理由進行限制。系統不支持的情況可以用DISPLAYTITLE。如果相關字符是F區用字或者是emoji加VS之類大多數環境目前不能正常顯示的情況，可以考慮在條目內附加圖片顯示正確的標題渲染方式，但並不是不使用相關標題的原因。至於說輸入問題的話個人認為可以忽略，因為大部分用戶都是用搜索或連結進入條目的，無論是透過站內還是站外的搜索或連結。C933103（討論） 2017年4月25日 (二) 10:58 (CST)

因此，個人認為並不需要拼音索引。另外，有關web font，由於IE9、Chrome 5、Firefox 3.6、Opera 11.1、Safari 5.1(含ios版)和Android 4.4原生瀏覽器以上都支持使用woff的web font，因此對瀏覽器支持的擔憂和對格式支持的擔憂對可以免除。C933103（討論） 2017年4月25日 (二) 17:13 (CST)

莫名其妙，討論都快完結了，就轉到【提案】。討論區同樣是具有達成共識的作用，移動到這裡完全是多此一舉。我覺得再拖一個月，還是一樣的結果。無意義地拉長討論時長，會導致參與者分散精力，最後離開討論。隨便你們了。--Notalgia-Contαct- 2017年4月28日 (五) 23:36 (CST)

現在這樣是算通過還是不通過呢……--Shirrak（討論） 2017年4月28日 (五) 23:56 (CST)
突然想到，半角冒號也不能作為條目開頭，以前見過一些幽靈條目，明明不存在卻一直顯示在鏈入頁面里（Special:鏈入頁面/天然），就是以冒號開頭的。不知道是bug還是別的什麼原因 --宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2017年5月2日 (二) 11:11 (CST)
半角冒號放在條目開頭會被自動省略，所以無需關注。
那些在「鏈入頁面」中以半角冒號開頭的條目，都是以前丟失的討論頁面（記得是以前的某個討論頁插件導致的）。內容已經不存在，而標題仍然存在於伺服器上，產生的bug。
 —— 立花奏雪CFSO6459✉ / ☎ 2017年5月3日 (三) 00:08 (CST)

本提案討論區

這個提議感覺沒有可執行性，而且並沒有任何實質上的改觀。 總之舉個栗子：Ready Go

  • Ready Go可以是指：
  1. Ready Go!
    1. Ready Go!(精靈寶可夢)——動畫《精靈寶可夢》無印第五首片頭曲。
    2. Ready Go!(大神與七位夥伴)——輕小說改動畫《大神與七位夥伴》中的片頭曲。
    3. Ready go!(Fate)——PSP遊戲《Fate/Tiger Colosseum》中的BGM，完整版由榊原ゆい演唱。
  2. Ready Go!!
    1. Ready Go!!(魔法護士小麥R)——TV動畫《魔法護士小麥R》的片頭曲。
    2. Ready Go!!(溫泉之花SpRING!)——遊戲《溫泉之花SpRING!》的片頭曲。
  3. Ready!Go!
    1. Ready!Go!(LOVELY×CATION2)——GAL遊戲《LOVELY×CATION2》中韮崎日向的角色歌。

這些是光ACGN圈子裡的東西（其實還有），並且忽略了大小寫差異。雖然也可以一刀切去掉全部符號，然後加上小括號作品名，簡單明了。對於Ready Go!可以命名為Ready Go!或者Ready Go，但是對於Ready Go!!卻要命名為Ready Go!或者Ready Go，實在是令人困惑。我覺得不一樣的標準只會造成更大的混亂，應該對這些做出更為明確的規範。--九江喵~ 2017年5月7日 (日) 00:18 (CST)

【對於Ready Go!!卻要命名為Ready Go!或者Ready Go】這個是哪裡體現了？--Shirrak（討論） 2017年5月7日 (日) 00:22 (CST)
【NEW GAME!是允許的，但是NEW GAME!!是不允許的。（應當選擇符號少的命名，同時萌百站內已在大部分場合使用NEW GAME!，為了命名一致選擇前者）】不是說「應當選擇符號少的命名」嗎？那麼要麼是1要麼是0，對於原本就是2個符號的，減少成為1然後和原本為1衝突（原本為1的可以繼續為1或者減為0），這樣的做法很奇怪啊。--九江喵~ 2017年5月7日 (日) 00:30 (CST)
但是這和你的例子不相干啊，NEW GAME是同一作品的第一和第二季，你上面的作品是6部不同作品的角色歌，而且有消歧義後綴，自然是該有多少符號用多少符號啊……
這個議題本來就是為了表明「把符號全都變沒」不是必要行為。NEW GAME的第一季是單感嘆號，理應把第二季的雙感嘆號重新導向過去吧。--Shirrak（討論） 2017年5月7日 (日) 00:48 (CST)

投票區

看來沒有繼續討論的意向了，那麼就開始投票吧。

re:秋葉：有人說在討論版上的共識不好找，而且那個討論串太亂，所以移到這裡來稍微清楚一點。

@Baskice，冥 血蝴蝶，Nostalgia，金萌桥姬，红魔狗头人，CFSO6459，蓝羽汇，Recital君，AnnAngela，弗霖凯，Shirrak @W3jc，兔兔耳宝宝，卫宫，一枚颜艺君，Nbdd0121，时间の神-优泠，Rg224，Hlwan03，PLAcenturion，Luenshi007，Kanate saikou，Luyouhao，声优编集者，Momo bly dblk，云霞，宇文天启，虹凤露丝.爱紫子萦，Imbushuo，Abc4473，平塚八兵衛

--bbrabbitからの評論 #討論# 2017年5月1日（一）21:09（CST）

@Baskice，冥 血蝴蝶，Nostalgia，金萌桥姬，红魔狗头人，CFSO6459，蓝羽汇，Recital君，AnnAngela，弗霖凯，Shirrak @W3jc，兔兔耳宝宝，卫宫，一枚颜艺君，Nbdd0121，时间の神-优泠，Rg224，Hlwan03，PLAcenturion，Luenshi007，Kanate saikou，Luyouhao，声优编集者，Momo bly dblk，云霞，宇文天启，虹凤露丝.爱紫子萦，Imbushuo，Abc4473，平塚八兵衛

ping壞掉了？--bbrabbitからの評論 #討論# 2017年5月6日 (六) 23:07 (CST)

正在加載中……
本次投票由Bbrabbit（討論 | 貢獻 | 封禁 | 用戶組）發起。
  • 投票開始時間：2017年05月01日 13:09 (UTC) | 2017年05月01日 21:09 (CST)
  • 投票結束時間：2017年05月08日 13:09 (UTC) | 2017年05月08日 21:09 (CST)
  • 投票總用時7天，正在計算中……

  1. (＝)中立 - TLDR -Ben | imbushuo | AS43126 - Biscuit, cookie or whatever (Discussion) 2017年5月1日 (一) 22:27 (CST)
  2. (－)反對 首先這個提案投票本身就應當作為【如何避免發起壞投票】的例子之一給後續提案做警醒，投票討論區里還內嵌了一個失敗的投票，至少摺疊下啊。我反對基於如下理由：
    1. 條目命名過往基準的「簡體中文最常用名稱優先」原則被「大多數中文用戶」這一說法替換，這會導致每次繁簡譯名有差時都會出現無意義爭論。不符合萌娘百科針對簡體中文用戶提供內容的方針。這一條跟標點符號關係不大，與繁簡政策更相關，私貨意味嚴重。
    2. 有符號的條目名應當重新導向到無符號的條目名，而不是反過來
    3. 下面的解釋也很讓人困惑，比如「/」符號在mediawiki系統內會被當作子頁面。即 「Fate/kaleid liner 魔法少女伊莉雅」這樣的條目會導致程序認為「kaleid liner 魔法少女伊莉雅」是條目「fate」的子頁面。這與用戶認知不符造成混亂。造成混亂的用法應當避免才是。「/」只用於子頁面一個功能。
    4. 最後NEW GAME這個沒有消歧義需求的條目根本不需要結尾的感嘆號啊，一二期也都寫在一起了。 -- 多功能型Baskice(給我留言) 2017年5月6日 (六) 01:58 (CST)
      果然又是稀釋效應上文我有提到「那段文字的修改雖然是對【符號使用說明】的修改，但是也要考慮到條目命名的其他部分的整體性。斷章取義，轉牛角尖的情況是要避免。」
      站長閣下，不要斷章取義，現在不是完全重寫【條目命名】，而是對關於【符號使用說明】的修改。
      另外，重新導向是雙向的，「有符號的條目名應當重新導向到無符號的條目名」，反之亦然。現在【LoveLive!】一類的條目都在用符號有妨礙到了嗎？使用符號與否本質上根本沒有影響。如果真要糾結搜尋引擎，瀏覽者體現，先給我修好那個搜尋引擎（相關問題上面也有說了）。
      最後，上面也說了「有問題就問，不要藏匿。」，放了那麼久都不理會，也就是投票時才正式提出問題。套路都是套路。--Notalgia-Contαct- 2017年5月7日 (日) 08:35 (CST)
  3. (＝)中立 剛看到這個提案，不知為何沒被at到…
    討論串太長了，大略地看了一下，不是很懂。大概意思是不是不追究標點的半角全形，儘量不用「!」、「·」什麼的？其實個人更想儘量按作品、人物的原名來名命，除非特殊情況。
    發了這麼長時間提案，棄了一個投票，這個投票差兩天就結束了才三人投票，這麼長的討論串下來像沒結果一樣，不尷尬麼--小虹鳳(≧∇≦) 2017年5月6日 (六) 14:15 (CST)
  4. (＝)中立 吃瓜群眾路過 --聲優編集者 2017年5月6日 (六) 23:24 (CST)
  5. (＝)中立 --Patroller KumoKasumi 2017年5月6日 (六) 23:30 (CST)
  6. (＝)中立 我暫時保留我的意見。--喧嘩八兵衛（Discussion） 2017年5月6日 (六) 23:31 (CST)
    我作為編寫者還能投票嗎？估計是不能-Shirrak（討論） 2017年5月6日 (六) 23:36 (CST)
  7. (＝)中立 ——炙月·楓（討論） 2017年5月6日 (六) 23:50 (CST)
  8. (＝)中立 你們都中立 我也很絕望啊 話說你們怎麼都在投票區討論起來了-Yurin_JasmineTalk with me 2017年5月7日 (日) 11:24 (CST)
  9. (＋)同意 那我來滋磁一下。——From AnnAngela the sysop (Talk) 2017年5月7日 (日) 11:29 (CST)
  10. (∅)棄權 ——太太太太太長了。。看了半天抓不住重點，怕斷章取義了。只好棄權。不過就結果論，如果最後導致了萌百大批條目移動的雞飛狗跳的結果，就視為我反對（這樣可以吧。。）實在是不想折騰 --宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2017年5月7日 (日) 11:32 (CST)
    覺得長的話上面有濃縮版 直接看那個就好-Yurin_JasmineTalk with me 2017年5月7日 (日) 11:49 (CST)
    大規模移動倒不會，具體內容請看提案而不是討論區，討論區我自己都沒仔細看完。--bbrabbitからの評論 #討論# 2017年5月7日 (日) 12:49 (CST)
  11. (＋)同意 我稍微花了一點時間看了一下，就上文所述的詞條標點符號規範實際上是可行的，況且經過以上討論後能有一個規範已是足夠，我選擇支持……--以上言論來自於巡查姬007君 _(:3 」∠)_（討論） 2017年5月7日 (日) 14:59 (CST)
  12. (＝)中立 。節操醬保持「標題命名應儘量避免符號」的態度。 —— 立花奏雪CFSO6459✉ / ☎ 2017年5月8日 (一) 12:40 (CST)
  13. (＝)中立 --未濟橋姬(☯太虛之門) 2017年5月8日 (一) 13:33 (CST)
  14. (＝)中立 有重新導向的話應該就沒那麼多問題了吧——只在討論版出現的衛宮醬 2017年5月8日 (一) 20:19 (CST)

計票結果

投票結束，有效票數共13票，其中同意2票，反對1票，中立10票，由於中立票數超過總票數半數本提案不通過，請管理員將本提案移動至萌娘百科_talk:提案/未通過提案--bbrabbitからの評論 #討論# 2017年5月8日 (一) 22:36 (CST)

因為中立票過多被取消有點可惜。其實這個提案相當於把實際執行的基準轉正而已，沒轉正的話就只好繼續按照習慣法，無視標點符號規則來執行了。--東山奈央（討論） 2017年5月9日 (二) 05:12 (CST)
總有人不去承認已經存在的東西。寄望於舊制度的人從來沒有確切貫徹過舊制度，而伴隨著不墨守成規的大膽編輯，新的觀點已經出現，沒有擊沉他的話，他就會壯大。
說到底，符號的使用就算不具有正統性，在理論上已經能說得過去了。--Notalgia-Contαct- 2017年5月13日 (六) 10:49 (CST)
取自「https://moegirl.icu/index.php?title=萌娘百科_talk:提案/未通过提案/关于标题符号问题的提案(2017.4.25)&oldid=5589830」