2023年政策修订增补工作正在进行中，欢迎参与！
萌娘百科 talk:提案/未通过提案/关于标题符号问题的提案(2017.4.25)
< 萌娘百科 talk:提案 | 未通过提案
正文
提案缘由
在讨论串[讨论]关于条目标题中是否应当出现符号的问题中，各人对新的暂定规则仍有异议，且有人反映新规则描述不够清晰，故提此案，以求进一步完善标题符号规则。
秋叶版新标题符号规则
下面是在经过众多讨论后由User:shirrak所写，后根据User:Nostalgia提议之内容修改，且一部分管理层人员同意的新标题符号规则
條目的命名原則上和條目描述事物使用的名稱一致，但是在基於搜索系統和技術限制等原因，仍然有一定的限制。
所有條目命名都應當首先使用大多數中文用戶最容易理解、最不容易混淆的文字，同時儘量確保其他人可以簡單且符合常識地連結到這些條目，除了要遵守命名規則之外，還應當遵守相關連結規則（消歧義和重定向），確保站內的連結的一致性，讓人有效地找到自己想找的內容。
為了方便其他人能順利找到內容，在遇上帶有符號的名稱時建議將沒有符號的稱呼，或者符號的變體版本稱呼重定向至有符号的称呼。
如果是同等规模的最常见译名，优先采用标点符号较少的译名作为标题。
由於技術限制，以下符號不能出現在條目命名中，但是你可以使用{{tl|標題替換}}一類的形式，在條目瀏覽時顯示那些符號。
:<code># < > [ ] | { }</code>
以下符号不能出现在条目名的开头：
:<code>% /</code>
以下符号不能出现在条目名的结尾：
:<code>/</code>
解释
下面是对新规则的一些理解和举例，由于本人才疏学浅，如有缺漏错误请指出。
- 在为词条拟定标题时，应当尽可能选择能被大部分用户所识读，并且不能超出《通用规范汉字表》中一二级汉字的范围（即GB-2312字符集收录的范围）。如作品名中出现超出此范围的汉字，则使用相近字建立词条。
- 条目的命名需要能够与站内已有链接的链接条目名一致，以让用户能够更快地找到需要的内容。
- 在建立带有符号的词条后建议创建相对应的无符号版本重定向
- 如遇到一个作品有多个译名，且都为中国大陆常见译名，选择符号较少的收录
- 以下符号禁止或有条件禁止出现在条目标题中，但是可以使用Template:tl的标题替换功能进行替换
- #，<，>，[，]，|，{，}不能出现在条目名的任何一处
- %，/不能出现在条目名开头
- /不能出现在条目名结尾
- 除此之外除了在标准的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)
一些相关的历史讨论列出备用：
- Talk:讨论版/存档/2015年06月#【预提案】修订Help:条目命名中的部分规则
- Talk:讨论版/存档/2016年01月#重新启动关于条目命名中标点符号的讨论
- Talk:讨论版/存档/2016年11月#关于作品名中的标点符号
个人认为现行规范没有问题。一些续作和原作标题只相差符号，如我的妹妹哪有这么可爱！和我的妹妹哪有这么可爱。，如果要使用符号难以确定以哪个为主条目，同时全角半角也有时不好区分难以抉择。因此应当尽可能不使用符号。
个人认为可能有争议的是关于外国人人名中的分隔符的表述：除非你确信不添加“·”一定会导致混淆，否则请直接输入名称，这个一定会导致混淆不是很好界定，如果不能很好的解释建议调整为的都加或者都不加。--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)
- 个人希望讨论是否可以把“𩽾𩾌”等处于扩展字符区的字词纳入“特殊符号”。
- 之前讨论中有人将平假名、“☆”等符号都纳入了特殊符号，理由是难以输入。
- 扩展字符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月5日 (三) 17:48 (CST)
- 鮟鱇疑似是mw的自动转换，我在建立条目时输入的都是鮟鱇。--Shirrak（讨论） 2017年4月5日 (三) 13:21 (CST)
根据上述看法总结为下：
- 当原作品、原人物等名称带有符号时
若符号能被中国一般打字软件输入，如“!”、“%”、“~”等，可以使用，以争取和原名保持一致。使用全角还是半角根据具体作品情况，一般情况下使用半角。若符号能被中国一般打字软件输入且不影响搜索等功能则可以使用，现阶段能使用的符号，还有【! % & * - ~ +】。如果有后续的需要允许使用的符号，可在提问求助区提出，若判明无不良影响允许使用。符号不能作为页面名第一个字符。除波浪线外，符号均使用半角改：2017年4月5日 (三) 21:34 (CST)- 可以出于方便搜索的理由将不带符号的页面名重定向至带符号的页面名。
- 若符号不能被中国一般打字软件输入，如
平假名和片假名，☆等，则不应使用作为页面名。 尽量避免使用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)
- 中国一般打字软件如何定义？有些“一般打字软件”可以打出扩展区文字—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: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)
- 我并不认为拼音化索引有什么技术上困难的地方： 将条目名称转化成拼音不难，根据拼音建立索引也不难， 把完全匹配内容在拼音匹配内容之前返回也没有技术上的难度。 请指明有实现难度的步骤。然后，我提出使用图片的方案的原因之一在于可以比较方便的只将展示本页面需要的内容发送到客户端，而不是准备一个字体来处理全部的情况。之所以我提出了使用图片而不是WebFont就是因为实现WebFont的难度很大，跨浏览器的WebFont支持更是悲催，有时候要生成4到5种格式的字体，这对于根据页面内容抽取出实际需要的字来说很难，无论是实现上还是性能上。地址栏和标题栏的问题确实无法通过我提出的方法解决。 - - Shelikhoo（讨论） 2017年4月7日 (五) 09:35 (CST)
- 手机方面，安卓系统的话只要使用思源黑体就能显示部分扩bcde，三星小米等品牌默认是思源，而oppo等品牌可以在主题商店下载到思源。(win亦可通过装字体实现更多文字的显示，如思源黑，花园明朝等)扩b常用的只有很少一部分，而思源黑体是包括了全部通用规范汉字表内的扩展区文字的，这些文字包括:𠅤𠙶𠳐𡎚𡐓𣗋𣲗𣲘𣸣𤧛𤩽𤫉𥔲𥕢𥖨𥻗𦈡𦒍𦙶𦝼𦭜𦰡𧿹𨐈𨙸𨚕𨟠𨭉𨱇𨱏𨱑𨱔𨺙𩽾𩾃𩾌𪟝𪣻𪤗𪨰𪨶𪩘𪾢𫄧𫄨𫄷𫄸𫇭𫌀𫍣𫍯𫍲𫍽𫐄𫐐𫐓𫑡𫓧𫓯𫓶𫓹𫔍𫔎𫔶𫖮𫖯𫖳𫗧𫗴𫘜𫘝𫘦𫘧𫘨𫘪𫘬𫚕𫚖𫚭𫛭𫞩𫟅𫟦𫟹𫟼𫠆𫠊𫠜𫢸𫫇𫭟𫭢𫭼𫮃𫰛𫵷𫶇𫷷𫸩𬀩𬀪𬂩𬃊𬇕𬇙𬇹𬉼𬊈𬊤𬌗𬍛𬍡𬍤𬒈𬒔𬒗𬕂𬘓𬘘𬘡𬘩𬘫𬘬𬘭𬘯𬙂𬙊𬙋𬜬𬜯𬞟𬟁𬟽𬣙𬣞𬣡𬣳𬤇𬤊𬤝𬨂𬨎𬩽𬪩𬬩𬬭𬬮𬬱𬬸𬬹𬬻𬬿𬭁𬭊𬭎𬭚𬭛𬭤𬭩𬭬𬭯𬭳𬭶𬭸𬭼𬮱𬮿𬯀𬯎𬱖𬱟𬳵𬳶𬳽𬳿𬴂𬴃𬴊𬶋𬶍𬶏𬶐𬶟𬶠𬶨𬶭𬶮𬷕𬸘𬸚𬸣𬸦𬸪𬹼𬺈𬺓，思源黑体全部支持显示。我的建议是:允许使用通用规范汉字表内的扩展区文字，通用规范汉字表外的也没有太大意义，比如木字旁加个规的简体字在扩e，win10和思源都不支持，这样的字简化也无益，不过通用规范汉字表内的建议使用。—Signed message from Honoka55(Message me·My contributions) 2017年4月5日 (三) 22:21 (CST)
- 稍微再牢骚一句，其实我和讨论一直都在跑题。讨论的主题在于条目名是否应该使用扩展区文字。
- 我个人持有的观点一直是：既然特殊符号(☆等)这种对于ACG作品标题完整性至关重要的符号都可以被排除在之外，那么由上述议题得出更多问题的扩展区汉字似乎也没有保留于条目名中。
- 条目名基本只会影响到地址栏和链接的显示，而这个是无法解决的。因此我认为对于条目名更适合回避扩展区汉字。
- 关于页面中的显示，本来就可以使用模板将页面显示的非扩展区汉字转换为扩展区汉字，因此使用非扩展区汉字并不会影响扩展区汉字在标题的显示。--东山奈央（讨论） 2017年4月9日 (日) 19:54 (CST)
- 我很好奇萌百有多少使用XP的用户，如果几乎没有，最多可以允许扩展B。然而根据你的表述扩展C及以后因为win7用户的原因是无法使用的了。此外手机方面需要更多信息进行判断，个人刚才试了一下，大量扩展B区的汉字无法显示。--Shirrak（讨论） 2017年4月5日 (三) 22:07 (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)
关于标点符号的使用
条目里不赞成使用任何的标点符号。严格的说，大部分标点符号在url和页面上多多少少都会引发问题。
以下几个是不应该或禁止使用的符号
- “#”是id选择，表示书签，会自动转跳到对应的id标签，不建议手动在页面搞适配
- “:”将有可能导致协议或端口错误，有着潜在的不可控风险
- “/.”、“/..”、“/”、“./”、“../”是相对寻址，会将有可能导致页面链接到错误的地址，所以应该禁止使用“/”和“.”
- “？”、“=”、“&”、“<”、“>”、“'”、“%”、“+”可能会存在有xss漏洞、sql注入、转义传值错误等不可控风险，但“(”、“)”单独使用时是安全的
- “[”、“]”、“|”、“{”、“}”这些符号已经被模板使用，不应该用作条目名，以防产生歧义或不可控错误
以下几个是不建议使用的符号
- 全角符号：全角半角切换麻烦，“(”、“)”应当统一使用半角
- “-”（减号或连接符）、“ ”（空格）、“——”（破折号），有可能会引起文件名命名不规范或歧义，应使用“_”代替，如出现butter-fly和butterfly这种在不使用“-”就很难消除歧义的特殊情况，这种时候应使用“-”来区分
- “·”(间隔号/中心点)，由于编码问题可能会出现歧义，常见于中文翻译过来的人名，建议直接连写或用“_”而不建议使用符号“·”
- “~”（波浪号），一般被用于副标题，应使用“_”来分割主标题和副标题
- “$”许多js库中被常用来当作选择器的的方法名，有可能会引发问题，但在js受限的情况下问题不是很大，反正看着不舒服就对了
- “*”虽然问题不大，但是常被用作消字符，容易引起误解
- “^”基本没什么用，实际上也看不清，但在其它情况下可能会引发问题的符号
- 基本上键盘上不存在的标点符号尽量不要使用，这只会使得搜索效率下降
以下几个是问题不大，可以安全使用的符号
“!”、“_”、“,”、“\”、“@”、“(”、“)”、“"”、“;”
是不是感觉很少？所以为了防止有部分人搞不清楚哪些可以用，哪些不可以使用，我的建议是尽可能不要使用。
--九江喵~ 2017年4月5日 (三) 22:14 (CST)
- 你列出来的很多我也不赞成使用，但是[]等一些已经被包含在了mw的无效标题中。
- 所以我列出来了括号里的几个啊，以避免“搞不清楚哪些可以用，哪些不可以使用”。
- 顺便你最后打出来的感叹号还是全角的。--Shirrak（讨论） 2017年4月5日 (三) 22:34 (CST)
- 好吧= =“！”的问题是我的锅，所以说我才讨厌来回切换全角半角啊。至于括号里的问题，在你发表回复之前我就在写回复了，所以并没有看到。标点符号这种，我觉得应该明确写出黑名单和白名单，没有被写明的属于中间地带，具体情况具体判断。--九江喵~ 2017年4月5日 (三) 22:42 (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)
那些什么“大陆常用输入法能输入的符号”太没有操作性了，越搞越复杂最后都没有人遵守。萌百原则上禁止条目名出现符号的原因在于MW条目名直接就是URL地址，这导致符号出现会导致各种稀奇古怪的错误。上面一大堆讨论只有 九江月 提到了。
- 例子有很多比如条目结尾英文句话.经常导致出错，每次服务器端都需要大量低效设置来绕过
- ?&$*!这几个MW自己在用 （比如 zh.moegirl.org/index.php?title=Talk:讨论版&action=edit§ion=23 ）出现很有可能导致mw错误
- CDN缓存容易出现判断错误，大部分大陆CDN的符号支持都是一坨屎，不用CDN在前面挡着分分钟被dos下线
- 全角符号难以输入
- 全角半角混杂问题多年来一直出现造成大量维护麻烦
- 用户通常不知道/不记得符号，条目加符号导致用户找条目困难。
- 符号不同导致用户编辑困难
- 最后也是最烦人的就是每隔一段时间就有人来讨论版打嘴炮说要澄清符号使用。然后我们又得把之前说过的不能使用符号的原因（或者不能使用哪些符号的原因）再说一遍。这个成本非常之高，尤其是采用某些符号可用某些符号不行时。每次都得详细解释。
最后【标题名】出现符号如果非常有必要，也是可以通过条目内重设标题名实现（即条目依旧是不带符号，通过{{DISPLAYTITLE:标题名}}实现）。然而这依旧会导致用户混淆标题。所以我还是坚持旧版的条目名禁止使用一切符号，除非是为了消歧义目的。并且清理萌百所有目前带有符号的条目以命混乱继续发展。 --多功能型Baskice(给我留言) 2017年4月5日 (三) 23:38 (CST)
- 条目结尾的英文句号很少见到，如影响性能就加入黑名单
- ?和&是url查询参数而不是mw特有的。?会被自动忽略不能作为条目名称，而&不再查询参数中时就是普通的符号，mediawiki能够正确处理。跟在?后时会因无效参数被忽略
- 现在国内大的CDN提供商已经可以对常见特殊符号进行处理
- 中文输入法默认就是全角
- 这个情况现在正在改善，目前大部分带有符号的条目都是半角
- 搜索功能不是吃屎用的
- 创建了条目之后其他用户编辑并不需要讨论符号问题
- 就是因为符号使用问题不清不楚才要讨论，打嘴炮有意思？--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)
- 如果是因为这些技术原因，把它们统统写到条目命名里面说明不就好了，不加说明总会有人提问。
- 全角难以输入就统一使用半角。
- 【! % & * - ~ +】这些都是已经在一些条目中应用的，我想知道现有的是否一律改成空格。
- {{DISPLAYTITLE:标题名}}的R旗标无法生效，T旗标才能实现标题替换（{{标题替换}}）。--Shirrak（讨论） 2017年4月6日 (四) 00:02 (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)
我大概整理了一下这些符号的常用情景，并分别做出了一些规则和处理办法。只是个人意见。（栗子不涉及翻译的字词准确问题，而是讨论符号使用情况。）
- 由于星号/乘号（*）在日语中经常被用作与英语做区别的符号，所以一般趋向于保留。但在不涉及与其它语言做区别或不会引起冲突的时候，一般不予保留。值得注意的是，日语里的星号是五角的星号＊（萌百上表达的是六角的），但我们应该使用六角的星号*（在萌百上表达的是五角的）
我能怎么办，我也很绝望啊。（Rhodanthe*与英语单词重复，会产生歧义，应该保留；your_song*和your song会引起冲突，应该保留。《星恋＊ティンクル》不会出现冲突，这种情况下不应该保留，应该命名为例如“星恋Twinkle”。 - 百分号（%）在表意时一般趋向于保留，否则一般不保留，但千分号（‰）、万分号（‱）等不应该使用，应用文字代替或寻求其它方式。《1000%SPARKING!》（魔法老师op），这里就应该保留。《草莓100%》、，则可以命名为“草莓100%”或“草莓百分之一百”或“草莓百分百”。
- 横杆（-）改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/舰娘”一样属于缩写，而缩写本身选用的时候应该回避一些常用词汇，所以不影响表意和消歧义。
- 与符号（&），趋向于一般不使用，而用“与”、“和”等字代替表意。《エスカ＆ロジーのアトリエ〜黄昏の空の錬金術士〜》应该命名为例如“爱丝卡与罗吉的工作室_黄昏之空的炼金术士”，按波浪线规则也可以命名为“爱丝卡与罗吉的工作室”。
- 波浪线（~），多用于各种gal和书籍副标题，本身无意义，不用于区别语义，一般不应该使用。《宝石吐きのおんなのこ~ちいさな宝石店のすこし不思议な日常~》应该命名为例如“口吐宝石的少女_小小的宝石店和稍稍不可思议的日常”；《星空TeaParty えくすとら ～「恋愛」はじまりました！～》应该命名为例如“星空TeaParty_Extra_恋爱已经开始”。
- 叉字符（×），这个问题比较难以处理，虽然一般不使用，但依旧可能会出现丢失语义等一些问题。《黄昏乙女×アムネジア》，这里的×应该使用小写英文字母代替并在前后加上“_”，命名为“黄昏少女_x_失忆”，如不会与英文单词产生歧义的情况下也可以命名为例如“黄昏少女x失忆”。但如《kiss×sis》，先忽略“亲吻姐姐”这类既有名字，在只考虑符号应用的前提下应该命名为例如“kiss_x_sis”，这个时候不应该省略“_”。
- 中心点（·），常见于人名，也有可能出现在一些改进型号的命名上，趋向于一般不使用或用“_”代替。人名一般不会出现歧义，直接连写即可。对于全名超长的人应该使用简写。如梵高或文森特·梵高（文森特·威廉·梵·高）、毕加索或巴勃罗·鲁伊斯·毕加索（巴勃罗·迭戈·荷瑟·山迪亚哥·弗朗西斯科·德·保拉·居安·尼波莫切诺·克瑞斯皮尼亚诺·德·罗斯·瑞米迪欧斯·西波瑞亚诺·德·拉·山迪西玛·特立尼达·玛利亚·帕里西奥·克里托·瑞兹·布拉斯科·毕加索）、亚里亚（神崎·H·亚里亚），简写中重名的以消歧义处理如“亚里亚（绯弹的亚里亚）”。对于日语中喜欢用作分隔符的情况，如セ・ン・パ・イ，在用作条目名的情况下，应予以忽略，命名为“前辈”。《新・ロロナのアトリエ ～アーランドの錬金術士〜はじまりの物語》应命名为“新罗罗娜的工作室_阿兰德的炼金术士_起始的物语”或“新罗罗娜的工作室”。禁千二百十一式・八稚女、七十五式・改这类东西应命名为“禁千二百十一式八稚女”或“八稚女”和“七十五式改”。
- 其它打起来麻烦又无明显意义的符号，一般不应该使用或禁止使用。如：“↑↓←→”（各种方向的箭头）、“♥/★/△/▽”（各种黑白底色的心/星符号、各种黑白底色几何图形）、“♪/♬”（各种n分音符）、“「/」”（日语引号不应使用）。
- 括号“(”、“)”增1，尽可能在词条中回避使用括号，括号应该是用以处理消歧义的，不应该用以处理条目中本身可能自带的括号（虽然这种情况比较少见），如果出现不可调和的这种情况，应该使用“_”做当副标题处理。
- 感叹号（!）增2，一般不保留。该符号一般不影响表意。某些比较特殊的词条WORKING!!（第二季）、WORKING!!!（第三季）应该通过命名为“迷糊餐厅（第二季）”、“迷糊餐厅（第三季）”来区别。“NEW GAME!”应该命名为“NEW_GAME”。フルメタル・パニック！，在忽略“全金属狂潮”的情况下，应该命名为“fullmelt_panic”或“全金属恐慌”。
- 斜杠（/）增3，禁止使用，作为替代的要么使用反斜杠（\）、要么直接去掉、要么使用“_”代替。《未来/珈琲 彼女の恋》应命名为“未来咖啡 她的恋爱”等。
- 英文逗号（,）、中文逗号（,）增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)
同意和反对是针对哪些内容而言的？= =--安迪布兰顿大人（讨论） 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)
- (＝)中立 --Yoonhakcher（讨论） 2017年4月7日 (五) 11:10 (CST)
稀釋效應
過多的論述，會淡化提出的觀點，也讓人沒有心思看完，這就是稀釋效應。我也灌點水。
首先關於標題【条目标题中是否应当出现符号】，目前百科的有兩類條目使用完全不同的符號使用規則。成句是正常使用全角的標點符號的，而對於作品和人物條目符號使用確是完全不同。
上面扯那麼多全角很難輸入阿，在2012年建站早期，站長閣下不也是用全角符號寫成句（一对百合一对基，剩下一个是苦逼）。說全角什麼什麼是完全忽略萌百兩個系統同時存在的事實，一邊可以，一邊不可以，個人認為這才是引起全角半角使用爭議和疑惑的最大原因。
另外說到什麼為何?&$*!MW會誤判，那不就是為何維基百科用全角符號，不就是因為怕誤判嗎！？
由於搜索系统的問題，導致整個命名規則都要遷就它？這是不是太本末倒置，本來有符號的條目，創作人大多會以重定向處理，方便搜索，都重定向了，有符號沒符號都能搜索得到，有差嗎。考慮實際重定向維護工作，這個搜索系統的問題根本是偽命題，因為進行了維護的條目，都有相關的重定向。（搜索系统自改了以後，真心不行，我平時是什麼都搜索不到的。因為繁體字是搜索不到簡體命名的條目的。那麼問題來了，我是否應該搞一堆重定向來幫助搜索？）--Notalgia-Contαct- 2017年4月6日 (四) 22:37 (CST)
- 还有大陆地区用户常用的贴吧q群微信这些，带符号，尤其是URL结尾符号经常会识别不全引起错误--多功能型Baskice(给我留言) 2017年4月6日 (四) 22:53 (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)
- 倒数第二条表述很奇怪，虽然明白你的意思。“形式类似成句”这个描述也很暧昧，为保持统一性个人认为不属于成句风格的标题也应该适用该规则。要不要考虑“实体全名适用”或者“非功能性符号”的表达方式？
- 然后规则没有考虑“非中文标题”的情况，比如“NOW LOADING!!!!”若是适用倒数第二条的话，就会使用全角符号而变得很奇怪。
- 最后个人觉得应该给命名规则加上一条“同等规模的最常见译名上，优先采用标点符号较少的译名作为标题”。--东山奈央（讨论） 2017年4月9日 (日) 19:54 (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)
- 我的妹妹哪有这么可爱！/我的妹妹哪有这么可爱。 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)
- 我倒是很希望你举一些例子，来看看如何解决呀……--Shirrak（讨论） 2017年4月12日 (三) 19:23 (CST)
- 建议举出一些例子来帮助大家理解。--W3jc（讨论） 2017年4月12日 (三) 18:56 (CST)
- 然而使用符号也会带来维护上的不便，例如和wiki系统冲突的符号如何处理、一个作品的衍生为多个名称以哪个为主条目、符号大小写不确定时如何抉择等等。--W3jc（讨论） 2017年4月10日 (一) 13:05 (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)
- 之前很多条目使用符号时用的是半角，比如半角感叹号搜索了一下有300+条目，全角感叹号不到100个，而且大部分是重定向，所以想着是根据既有现象进行调整，毕竟不会有特别重大的差异。--Shirrak（讨论） 2017年4月12日 (三) 19:23 (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)
- 其實不用你寫，隔壁維基就有現成的，除非萌百裝了什麼奇怪插件，導致和同樣使用Medaiwiki的維基有差異，否則那些規則都是通用的。--Notalgia-Contαct- 2017年4月16日 (日) 10:48 (CST)
（也许会是）投票区
- (＝)中立 我比较想看到一个整体重写的版本，而不是仅仅修改以前的叙述，举例尽可能详细一点就更好了。重制版希望！--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)
(☩)意见 只要符合命名規範，並且是有效字符且系統支持，便沒理由進行限制。系統不支持的情況可以用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)
本提案讨论区
这个提议感觉没有可执行性，而且并没有任何实质上的改观。 总之举个栗子：Ready Go
- Ready Go可以是指：
- Ready Go!
- Ready Go!(精灵宝可梦)——动画《精灵宝可梦》无印第五首片头曲。
- Ready Go!(大神与七位伙伴)——轻小说改动画《大神与七位伙伴》中的片头曲。
- Ready go!(Fate)——PSP游戏《Fate/Tiger Colosseum》中的BGM，完整版由榊原ゆい演唱。
- Ready Go!!
- Ready Go!!(魔法护士小麦R)——TV动画《魔法护士小麦R》的片头曲。
- Ready Go!!(温泉之花SpRING!)——游戏《温泉之花SpRING!》的片头曲。
- Ready!Go!
- 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)
投票区
看来没有继续讨论的意向了，那么就开始投票吧。
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)
- (＝)中立 - TLDR -Ben | imbushuo | AS43126 - Biscuit, cookie or whatever (Discussion) 2017年5月1日 (一) 22:27 (CST)
- (－)反对 首先这个提案投票本身就应当作为【如何避免发起坏投票】的例子之一给后续提案做警醒，投票讨论区里还内嵌了一个失败的投票，至少折叠下啊。我反对基于如下理由：
- 条目命名过往基准的“简体中文最常用名称优先”原则被“大多數中文用戶”这一说法替换，这会导致每次繁简译名有差时都会出现无意义争论。不符合萌娘百科针对简体中文用户提供内容的方针。这一条跟标点符号关系不大，与繁简政策更相关，私货意味严重。
- 有符号的条目名应当重定向到无符号的条目名，而不是反过来
- 下面的解释也很让人困惑，比如“/”符号在mediawiki系统内会被当作子页面。即 “Fate/kaleid liner 魔法少女伊莉雅”这样的条目会导致程序认为“kaleid liner 魔法少女伊莉雅”是条目“fate”的子页面。这与用户认知不符造成混乱。造成混乱的用法应当避免才是。“/”只用于子页面一个功能。
- 最后NEW GAME这个没有消歧义需求的条目根本不需要结尾的感叹号啊，一二期也都写在一起了。 --
多功能型Baskice(给我留言) 2017年5月6日 (六) 01:58 (CST)
果然又是稀釋效應上文我有提到「那段文字的修改雖然是對【符號使用說明】的修改，但是也要考慮到條目命名的其他部分的整體性。斷章取義，轉牛角尖的情況是要避免。」
站長閣下，不要斷章取義，現在不是完全重寫【條目命名】，而是對關於【符號使用說明】的修改。
另外，重定向是雙向的，「有符号的条目名应当重定向到无符号的条目名」，反之亦然。現在【LoveLive!】一類的條目都在用符號有妨礙到了嗎？使用符號與否本質上根本沒有影響。如果真要糾結搜索引擎，瀏覽者體現，先給我修好那個搜索引擎（相關問題上面也有說了）。
最後，上面也說了「有問題就問，不要藏匿。」，放了那麼久都不理會，也就是投票時才正式提出問題。套路都是套路。--Notalgia-Contαct- 2017年5月7日 (日) 08:35 (CST)
- (＝)中立 刚看到这个提案，不知为何没被at到…
讨论串太长了，大略地看了一下，不是很懂。大概意思是不是不追究标点的半角全角，尽量不用“!”、“·”什么的？其实个人更想尽量按作品、人物的原名来名命，除非特殊情况。
发了这么长时间提案，弃了一个投票，这个投票差两天就结束了才三人投票，这么长的讨论串下来像没结果一样，不尴尬么--小虹凤(≧∇≦) 2017年5月6日 (六) 14:15 (CST) - (＝)中立 吃瓜群众路过 --声优编集者 2017年5月6日 (六) 23:24 (CST)
- (＝)中立 --
Patroller KumoKasumi 2017年5月6日 (六) 23:30 (CST)
- (＝)中立 我暂时保留我的意见。--喧嘩八兵衛（Discussion） 2017年5月6日 (六) 23:31 (CST)
我作为编写者还能投票吗？估计是不能-Shirrak（讨论） 2017年5月6日 (六) 23:36 (CST) - (＝)中立 ——炙月·枫（讨论） 2017年5月6日 (六) 23:50 (CST)
- (＝)中立 你们都中立 我也很绝望啊 话说你们怎么都在投票区讨论起来了-Yurin_JasmineTalk with me 2017年5月7日 (日) 11:24 (CST)
- (＋)同意 那我来滋磁一下。——From AnnAngela the sysop (Talk) 2017年5月7日 (日) 11:29 (CST)
- (∅)弃权 ——太太太太太长了。。看了半天抓不住重点，怕断章取义了。只好弃权。不过就结果论，如果最后导致了萌百大批条目移动的鸡飞狗跳的结果，就视为我反对（这样可以吧。。）实在是不想折腾 --宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2017年5月7日 (日) 11:32 (CST)
觉得长的话上面有浓缩版 直接看那个就好-Yurin_JasmineTalk with me 2017年5月7日 (日) 11:49 (CST) - (＋)同意 我稍微花了一点时间看了一下，就上文所述的词条标点符号规范实际上是可行的，况且经过以上讨论后能有一个规范已是足够，我选择支持……--以上言论来自于巡查姬007君 _(:3 」∠)_（讨论） 2017年5月7日 (日) 14:59 (CST)
- (＝)中立 。节操酱保持“标题命名应尽量避免符号”的态度。 —— 立花奏雪CFSO6459✉ / ☎ 2017年5月8日 (一) 12:40 (CST)
- (＝)中立 --未济桥姬(☯太虚之门) 2017年5月8日 (一) 13:33 (CST)
- (＝)中立 有重定向的话应该就没那么多问题了吧——只在讨论版出现的卫宫酱 2017年5月8日 (一) 20:19 (CST)
计票结果
投票结束，有效票数共13票，其中同意2票，反对1票，中立10票，由于中立票数超过总票数半数本提案不通过，请管理员将本提案移动至萌娘百科_talk:提案/未通过提案--bbrabbitからの評論 #討論# 2017年5月8日 (一) 22:36 (CST)