2023年政策修订增补工作正在进行中,欢迎参与!
  • Moegirl.ICU:萌娘百科流亡社群 581077156(QQ),欢迎对萌娘百科运营感到失望的编辑者加入
  • Moegirl.ICU:账号认领正在试运行,有意者请参照账号认领流程
本页使用了标题或全文手工转换

萌娘百科 talk:提案/已通过提案/主要改条目命名的提案(2022.09.06)

萌娘百科,万物皆可萌的百科全书!转载请标注来源页面的网页链接,并声明引自萌娘百科。内容不可商用。
跳转到导航 跳转到搜索
Commons-emblem-success.svg
这个页面“萌娘百科 talk:提案/已通过提案/主要改条目命名的提案(2022.09.06)”是萌娘百科现有方针、指引或其他规范文件的讨论案

序言

本提案主要包括
上一个提案之后……

关于条目命名指引的主要改动符号和地区词部分的提案(2022.05.30)因为逾期未发起投票而未通过。

在这之后,C8H17OH发起了【指引修订】关于允许成句类条目命名使用全角标点的条目命名指引修订案,扩大了在成句类条目条目名可使用符号的范围。

这个提案相比上个未通过的提案,主要有以下变更:

本提案不考虑的方面

与符号、地区词无关的问题,此提案不解决,即照搬现有的萌娘百科:条目命名,不做实质性改动。

参考
参考

站内

站外

注释我先不加了,暂时需要看的话可以看看上个提案,我要去看动画片了。—— あめろ 讨论 2022年8月1日 (一) 22:21 (CST)

提案正文

替换萌娘百科:条目命名全文

本指引规范条目(namespace=0,不含消歧义页面和重定向页面)的命名。消歧义页面和分类的命名可适当参考此指引。

条目名是条目的实际标题,可以通过两对方括号([[条目名]])链入,网址中也包含条目名(可能会被转义)。而不一定是显示标题,后者可以参与字词转换,可以用{{标题替换}}、{{NoteTA}}[+ 1]等模板或魔术字更改。

条目名区分大小写,但是首字母总是大写,可以通过{{小写标题}}使显示的标题上的首字母小写。条目名中空格与下划线等价,在页面标题上显示为空格。{{标题格式化}}用于处理标题中的消歧义前后缀以及子页面、[+ 2]名字空间前缀。

确定一个条目名需要先后通过#命名原则#符号和不常用文字的处理两个部分

  1. 一个合理的条目名应当至少满足命名原则中的一条,并应当尽可能满足数目更多的原则。若某一称呼与其他称呼相比,所满足原则的数目更多,则优先采用该称呼。
  2. 通过命名原则选出的名称可能含有各种符号和不常用文字,经过处理后方可作为条目名。

若无法通过这种方式选择一个更优的条目命名,则相关编辑应对此进行协商讨论。

有时条目名可能无法确定,此时可以先暂定一个条目名,并在页顶悬挂{{暂定标题}}模板,写清暂定标题的原因。若日后确定了条目名,可以通过“移动”操作来将条目重命名,并移除{{暂定标题}}模板。所有添加了{{暂定标题}}的页面都会显示在分类:需要更名的条目中,以便管理。

命名原则

官方名称优先原则

译名取官方译名,即作品著作权的持有者或条目描述人物所订定或认可的中文名,如取宝可梦民安友绘

  1. 若无官方译名,取正式译名,即获授权出版、播放或发行的作品译名。
  2. 若翻译质量特别差、严重偏离原文,则不取官方译名、正式译名,如不取我与亲爱哥哥的日常(天角)、三年E班(B站)。可以用注释、讨论等方法说明如此选取的原因。

[提案注释 1]

常用称呼优先原则

标题应当尽可能使用中国大陆最常见且较为正式的称呼,如取魔卡少女樱(B站)作为条目名,因为其比百变小樱(星空卫视)、百变小樱魔术卡(少儿社等)、百变小樱魔法卡(接力)、百变小樱 梦幻魔术卡(闽文音)更常见。如果没有,则可退而求其次,选择繁体地区(香港、台湾等)的称谓使用。[提案注释 2]

简体中文优先原则

原则上萌娘百科的条目命名优先级为:简体中文>繁体中文≫英文>日文等其他语言。外文标题可以翻译时尽量使用中文。
特别注意不要繁简混合命名,比如简体的消歧义后缀+繁体人物名,混合的标题会对搜索和语言转换带来影响。

另,对于条目名内含有日本汉字的情况,由于日文中包括大量现今简体或繁体中文已经不再使用的汉字,因此请根据实际情况对条目名进行一定的转写处理,而不要盲目照搬。具体的帮助性论述可见于Help:在条目名中可用与不可用的日本汉字一览

使用全称

惯例:请尽量不要使用简称或缩写来命名条目,除非这个“别称”只有它使用,或者这个“别称”大部分人都知道。尽量避免使用中文或外文缩写,除非该缩写已经被公认为专有名词,例如“苏联”、“IBM”等。

通用代称

有时条目中部分名称可通用,类似写作oo读作xx只要杀了oo我随便你搞,此种情况统一使用小写英文字母o和x替代(俗称通配符)。

尽量避免使用第三个通配符,如果有需要用到的情况,请先考虑命名是否合理。如“o最x的y”就会造成理解和检索困难,最终采取最常用的“喝最烈的酒”为条目名,其他用法在条目中附带介绍。

重名处理原则

一般而言,条目命名应当尽可能作出针对性的命名,而避免使用模糊不清晰的命名。当条目所描述对象具有另外的名称,或是更完整而又同等清晰的名称,我们就可以使用它们,如佐藤雏(而不是“雏(成神之日)”)、岛田半藏(而不是“半藏(守望先锋)”)等。

但在某些情况下,使用可能存在重名的名称可能才是一种更好的选择,这些情况包括:

  • 姓名为西洋人名的角色,全名过长的情况,如:露露(无彩限的怪灵世界)(而不是“露露拉露里·露拉拉里拉拉露露里里拉里·里拉拉露露拉拉露露拉拉里拉里”)、露易丝(零之使魔)(而不是“露易丝·法兰西斯·露·布朗·杜·拉·瓦利埃尔”)
  • 有歧义的名称更常用、知名度更高的情况,如:天使(守望先锋)(而不是“安吉拉·齐格勒”)、明日方舟:初雪(而不是“恩雅·希瓦艾什”)等。当下游戏等作品中的角色大量使用代号、网名等非传统人名的名称而导致重名,要求必须使用没有歧义的名称作为条目名没有意义。

请根据条目描述对象的实际情况灵活处理,而不要刻意为了回避歧义而选择并不泛用的名称。这种情况下,具体的命名规则详见萌娘百科:消歧义#条目名消歧义

符号和不常用文字的处理

“符号和不常用文字”在这里指除了汉字[注 1][+ 3][± 1]、Aa—Zz、0—9外的所有字符。为方便起见,下文的“符号”包含“不常用文字”。[± 2]

当名称含有符号和不常用文字时,应当对名称按照下列规则逐步处理。

字符的保留与否

(本章节标题:可用与不可用符号字符的保留与否[± 2]

符号和不常用文字[± 2]中满足下列属性之一的,在不涉及技术限制时可以保留

  • ASCII可显示字符(可打印字符)ASCII标点及符号[± 3]可以使用的有[± 4]“(空格) ! " $ % & ' ( ) * + , - . / : ; = ? @ \ ^ _ ` ~”[+ 4][注 2]
  • 以下中文标点符号所用字符:“。 ? ! , 、 ; : ( ) [ ] 〔 〕 【 】 — … “ ” ‘ ’ 「 」 『 』[± 5] ~ · 《 》 〈 〉 / ×[± 6]中的字符[± 7]
  • 在条目名中的用途为表达天文学、数学等现实科学中的特定含义的希腊字母[注 3],如小熊座α与梦境β受体阻滞剂与星辰[+ 5]
  • 若名称来自原文为简体中文的作品,则可使用“「」『』”;[± 6][± 5]
  • 若标题未经翻译而暂定,则可在不被系统阻止时,保留名称中原有的文字和符号;
  • 后续规则允许使用的字符[± 2]

其他字符[± 2]应避免使用。特别地,出于技术限制,标题包含“# < > [ ] | { }”之一或某些特定组合的字符的条目页面[± 8]无法被创建,详见Help:标题限制

例外:对于一个条目,若包含不可用符号的名称比不含该符号的更加常用,并且不含该符号无法正确表意和指代时,则可在创建/移动时的摘要,或在讨论页给出合理证据后,以包含该符号的名称作为条目名。[± 9]

统一格式

对于以下符号,统一使用规定的字符。若将用于条目名的名称中存在下列字符[± 2],在条目名中请一律使用(或改为)指定的字符。[± 10]这虽然在个别情况下不是最合适的,但有助于避免混乱。虽然这里涉及的不少字符难以用肉眼判断,但常见错误会被自动阻止,不必过分担心。[+ 6]

  • 空格使用“ ”(U+0020 space),而非其他各种空白字符。
  • 间隔号使用“·”(U+00B7 middle dot),而非“.”(U+FF0E)、“‧”(U+2027)、“•”(U+2022)、“・”(U+30FB)、“・”(U+FF65)等各种点[1]。在多数主流的电脑端中文输入法的中文输入状态下,按1键左侧的`键输入的就是这个符号。
  • 希腊字母使用希腊文字和科普特文字(Greek and Coptic)Unicode区段的字符。[+ 7]
  • 全角拉丁字母、阿拉伯数字换用改为[± 10]半角。
  • 专门的罗马数字字符换用改为用拉丁字母拼写的形式,如将“Ⅲ”换为改为“III(3个I)”[± 10]。实际上,使用拉丁字母拼写罗马数字并不是错误的,反而更为规范[2]
  • “〜”(U+301C wave dash换用改为[± 10]“~”(U+FF5E fullwidth tilde),前者多出现于日文中。
  • “‐”(U+2010 hyphen)、“−”(U+2212 minus sign)、“–”(U+2013 en dash换用改为[± 10]“-”(U+002D hyphen-minus),即键盘上直接输入的短横线。[+ 8]
  • “―”(U+2015 horizontal bar换用改为[± 10]“—”(U+2014 em dash),即通常的“半个中文破折号”。[+ 8]

下面的规定与消歧义有关,部分涉及系统运作:

  • 用于消歧义的括号和冒号,使用半角,如爱丽丝(东方Project旧作)恋姬无双:诸葛亮
  • 当条目名出现非消歧义用途的半角冒号时,需要在条目中使用{{ColonSort}}或以其他方式保证分类索引正确,对全角冒号不需要这么做。
  • 消歧义前缀中不要出现“/”,消歧义后缀中不要出现“:”和“/”。
通用规范

在作品著作权的持有者或条目描述人物另有公开的明确规定时,不必遵循本章节涉及的内容。[+ 9]

半角斜线“/”涉及子页面功能,当条目不用作子页面,官方名称中也不含“/”时,条目名中要尽可能避免“/”。使用“和”或“或”通常可以达到类似效果。[+ 10]

对于作品,在名称不满足官方名称优先原则时,副标题的表示方式应尊重原题。各种表示方式包括“主标题:副标题”、“主标题 副标题”、“主标题 -副标题-”、“主标题 ~副标题~”等。但具体符号(中西文、全半角等)根据条目名的文种进一步判断,见下[± 11]

在符合#可保留的字符[± 2]#统一格式的基础上,条目名中的标点符号应使用条目名对应文种中更加规范、通用的形式。这一般能解决问题,但以下情况需注意:

  • 对于中文条目名中的标点:
    • 直角引号“「 」”和“『 』”[− 1]日文中有时[± 12]也用作书名号),仅当原文为简体中文时,与原文一致当该符号所在名称满足官方名称优先原则常用称呼优先原则时可以使用[± 5],但应建立弯引号的重定向[− 2]。其它情况下,直角引号应转为弯引号或书名号。
    • 浪纹线“~”和“~”[− 1],当原文为日文或中文时,浪纹线的全半角与原文一致。其它情况下,使用更规范的“~”[3][1]。若使用了“~”,则应建立半角的重定向以应对其他条目中的链入。
    • 日文中的“。”“、”“・”与中文的“。”“、”“·”并非完全对应,不宜生搬硬套。
    • 两个及以上点号连用时,其全半角与原文一致,如竞女!!!!!!!!使用的就是半角。
    • 对形如“主标题 -副标题-”的标题,其副标题两侧[± 13]的横线,字宽接近或超过一个汉字的,用一个或多个“—”;其余的用“-”。[+ 8]
  • 对于英文等拉丁文字条目名中的标点:
    • 标点周围空格的有无,与原文一致,如Bright!Light!中并无空格。无法参考原文(比如原文该部分并[± 13]英文)时,按照规范的做法。
    • 弯引号(““ ””和“‘ ’”)并非中文专属,与直引号(“" "”和“' '”)也并非全半角关系。若原文为英文等拉丁文字且使用弯引号,则条目名与之一致,但应建立直引号的重定向。其他情况下,使用更常用、更易输入的直引号。撇号(“’”与“'”)同理。引号一律使用直引号“" "”和“' '”[− 1],而不是弯引号““ ””和“‘ ’”[− 1],撇号也使用直式。[± 14]
    • 对形如“主标题 -副标题-”的标题,副标题两侧[± 13]的横线用“-”。[+ 8]
  • 对于混合文种条目名中的标点,尽量参考官方名称或常用名称,跟随其用法,在条目名没有取官方名称等无法参考的情况下,再参考常用名称[± 15]。仍无法判断时,提供如下[± 16]方法以供参考,依照最先满足的方法判断。对于此类混合文种的标题可适当建立不同重定向以应对在其他条目中的链入。
    1. 有副标题时,主标题与副标题分别判断,主副标题之间的符号,在可以参考原文时,与原文一致,否则按主标题的文种判断;
    2. 不同文种的部分可以单独成句时,分别判断;
    3. 一种文字占主导地位时,整体使用该文种的标点;
    4. 含有中文时,整体使用中文标点。
  • 成句类条目标题中的通配符“o”“x”不影响成句系何种语言,例如o——o——被视为中文成句。
不保留的字符的处理

(本章节标题:不可用符号的处理不保留的字符的处理[± 2]

未被#统一格式#通用规范提及的不保留的字符[± 2]可灵活处理,例如:

上面只是举例,并不局限于以上方法,对特定条目可以有其他更合适的改法。[+ 12]

  • 在名称为乱码、空白等难以处理的情况下,用别称命名可能是更好的选择,即重新挑选一个符合尽可能多的命名原则的名称作为条目名。[+ 13]

若仅调整一部分字符会造成违和,可选择将其他部分一并调整。可以使用{{标题替换}}或{{NoteTA}}等模板替换标题。[− 4]

例外情况

部分条目不保留某些文字会不合适,主要表现为缺乏辨识度。[± 20]若待处理的条目名中本应[± 20](即不考虑本规则的情况下)不保留的文字满足以下全部条件[± 20],则可以保留:

  • 在所属文种中不构成单词,或与构成的单词含义无关在所属的语言中没有明确含义,或在条目名中的含义与原本的含义无关[± 20]
  • 不是装饰,也不是用其形状构成其他语言的词语[± 20](用形状的如Next New Wφrld中的“φ”[± 20]);
  • 以合适的方式(不刻意避免歧义)[± 20]处理这些文字后,条目名会与其他存在的条目产生歧义。而保留这些文字则无歧义。

若有条目符合此要求,那么该条目描述的对象出现在其他条目名中时也可以保留这样的文字。若有条目因此得以保留名称中的某些文字,那么在其他条目名中提及该条目描述的对象时,也可以保留这些文字[± 20]

[± 9]

注释

  1. 中日韩统一表意文字(CJK Unified Ideographs)及扩展区A—G(Extension A–G)中的字符,以及“〇”(U+3007 ideographic number zero)。此处的汉字为Unicode中具有Unified_Ideograph字符属性的字符,以及“〇”(U+3007 ideographic number zero)。它们基本位于中日韩统一表意文字(CJK Unified Ideographs)及其扩展(Extension)区段。若不确定,可于Unicode Utilities: Character Properties查看字符的属性,确认Unified_Ideograph的值。
  2. 美式键盘可以直接输入的字符一般都是此类。
  3. 增量符号“∆”(U+2206 increment)、求积符号“∏”(U+220F n-ary product)、求和符号“∑”(U+2211 n-ary summation)不算作希腊字母。

参考

  1. 1.0 1.1 《中文排版需求》§ 3.1.1.2 标号
  2. "Acrophonic Systems and Other Letter-based Numbers". The Unicode® Standard Version 14.0 – Core Specification § 22.3 Numerals. p. 853.
  3. 《标点符号用法》(GB/T 15834—2011)§ 5.1.6:“……浪纹线占一个字位置。连接号上下居中……”;《重訂標點符號手冊》(2008年修訂版),連接號一節:“占一個字的位置,居正中。”

Help:符号使用指南列为失效文档

与当前习惯出入过大;过于繁琐。

修改萌娘百科:字词转换指引

  1. 全文手工转换规则应该放在源码开头,同时各规则不能繁简混合,否则转换会失败。

改为:

  1. 条目中地区词的选取应尽可能符合下列更多如下规则(官方译名和正式译名的定义与萌娘百科:条目命名相同):
    • 分别选取各地的官方原名或官方译名(或者当对象出自其中一个地区时,其在该地的官方名称)[± 21]作为该地的[− 5]地区词;
      1. 若各地均无官方译名,则取各地正式译名,如取“魔卡少女樱”(B站)、“百變小櫻Magic咭”(无线电视等)、“庫洛魔法使”(东立等)分别作为中国大陆、香港、台湾的地区词。
      2. 若某地无官方译名,可以但不建议将该地的正式译名与其他地区的官方译名混在同一规则中;
      3. 若翻译质量特别差、严重偏离原文,则不取官方译名、正式译名。
    • 尽可能使用各地最常见且较为正式的称呼作为该地地区词,但不应将官方译名和常用译名混在同一规则中[− 6]

[提案注释 1]

将所有“(namespace=…)”改为“(namespace=…)”。

修改萌娘百科:消歧义

将“消歧义页面内容”的

  1. 消歧义页中的义项应使用原始页面名称,而不用管道符改变显示文字,以减少混淆,如不应让结衣(刀剑神域)显示成结衣

改为

  1. 消歧义页中的义项应使用原始页面名称,而不用管道符改变显示文字隐去消歧义前后缀[± 22],以减少混淆,如不应让结衣(刀剑神域)显示成结衣。但如果条目名是根据萌娘百科:条目命名#不保留的字符的处理[± 2]调整的,则可以改变显示文字为调整前的名称。

修改萌娘百科:重定向方针

#用途第1条的第3、4条

  1. 重定向至避免特殊符号的页面名;
  2. 将外文拉丁字母页面名重定向至ASCII字母页面名;

改为:

  1. 由处理符号和不常用文字前的名称重定向至处理后的页面名;
  2. 在处理符号和不常用文字的过程中产生的可能被链入的重定向;

在“特别地,当重定向目标存在多个有收录价值的歧义项时,应停止创建重定向并根据萌娘百科:消歧义方针进行消歧义。”前增加一段:

通过页顶搜索栏搜索时,全半角差异会被忽略,直接跳转到对应页面;在Special:搜索中,符号会被忽略。基于此,官方未使用过的与目标页面名仅全半角有差异的重定向不属于“改善搜索”的范畴,但这类重定向可能会符合“改善搜索”之外的用途。

提案通过后的操作

此章节讲解了若本提案通过,维护人员应当执行的、其他编辑者应当遵循的操作。由于因本提案而需要更名的条目很多,且部分不易发现,故不强求短期内处理完所有条目。

字词转换指引的修改涉及条目较少,不做详细说明。新条目和重定向直接按照更改后的萌娘百科:条目命名萌娘百科:重定向方针创建。旧条目需要对照以下几个方面处理:

更名

在本提案通过后,有大量条目需要更名。这类条目多是为了避免全角标点而以换用半角标点或空格或删除标点。

欢迎有经验的编辑者协助更名,但是,为避免混乱,不能仅移动页面,而需要负责处理后续#标题替换#重定向#内部链接#分类索引#分类页)。

注意:符号被放开一部分,不代表包含符号的名称就是好的,同之前一样,名称仍需要尽可能满足数目更多的原则。

主要检查的方向:

标题替换后的名称、条目的“一句话介绍”中的名称、信息栏中的名称通常是处理符号和不常用文字前的名称,可作参考。


整体上本提案扩大了可用的符号范围,但是有些条目的命名在本提案前可能就不符合指引,在本提案后依然不符合指引。之所以之前就没有遵循指引,可能是因为命名困难。“更名这样的条目”的优先级可以往后放。以下是部分这样的条目中包含的符号以及解决办法:

[+ 14]


#不保留的字符的处理中的例外情况,如μ's(“缪斯”、“Muse”与其他条目有歧义)、élf(“elf”与精灵(种族)有歧义)等,这些条目不更名。[+ 15]

标题替换

移动后需要检查是否还需要标题替换。移除不需要的标题替换。不局限于{{标题替换}}模板。

例如:

重定向

重定向方针发生变化,移动时应判断是否需要留重定向。由含半角标点的中文标题移动到全角标点的中文标题时,其重定向不再需要。

若重定向不再需要,则:

如果链入较少,维护人员在移动时可不留重定向,并尽快处理链入。若链入页面过多且无法尽快处理,则暂时保留重定向,待处理完链入后再删除/挂删。

其他有经验的编辑者在处理完链入后,于操作申请版提删重定向。

例如:

内部链接

如果条目更名后,重定向保留,可自由选择是否替换内部链接。

如果条目更名后,重定向不再需要,则链接应尽快被替换(可申请批量替换)。替换后删除/挂删/提删重定向。

分类索引

  • 更名后的条目存在非消歧义用途的半角冒号时,使用{{ColonSort}}等设置分类索引。
  • 更名后的条目以符号开头或消歧义前缀之外的部分以符号开头,重设合适的分类索引。不在开头时,也可选择设置。例如:

分类页

作品分类名一般跟随条目名,因此条目移动时,分类也应随之移动。

分类同样需要判断是否留重定向,并采用与#重定向相似的处理方法。

标题黑名单

管理员酌情将全角拉丁字母、全角阿拉伯数字加入标题黑名单或滥用过滤器,酌情删除标题黑名单中的.*?.*\?.*!.*\!.*\/.*。.*\=.*之全部或部分[± 23]

消歧义页

补回符号不是强制的,爱补补不用揪这个[± 8]

增删注释区

  1. 补。
  2. 完善标题格式化的功能说明。
  3. #关于各种汉字和非汉字,明确汉字的定义。
  4. 列举所有符号
  5. #希腊字母讨论
  6. 放松。
  7. 避免音标扩展、数学字母数字符号等区段中的希腊字母。现实科学中使用的希腊字母应该没有在希腊文字扩展区的吧……
  8. 8.0 8.1 8.2 8.3 #关于各种横杠
  9. 比如某个名字该用全角的时候偏要用半角。限定“公开的明确规定”以避免此规则被滥用。
  10. #关于「/」
  11. “作用”似乎更注重整体,而且就算意思重复了也不碍事(
  12. 避免误解为只能按照提到的方法处理。追加:根据暴走的喵兵卫的反应再加半句。
  13. ?̵͔͖̺͓̬̩?̙̥̪͓̣̟̟?̟̀?̢̯̻̠?̫̯̲̝́??̜̲̼͖̗̩?̬̗̭͟?̙̰̫̝͙͉ͅ ?̮͕̟͎͙̺̮?͚͔̦̥͚?͓̗̩͔?͉̫̰͎̥̳?̡次元假象门媒介回忆实验干扰意识。8月30日:参考Cesko的建议,调整位置。
  14. #关于各种符号,增加处理方法。
  15. 列举具体条目。

  1. 1.0 1.1 1.2 1.3 格式:去除多余括号。
  2. 重定向不总是需要。
  3. #关于各种汉字和非汉字,避免将“々”换为“𠚤”——虽然非“未经翻译而暂定”的标题要用“々”的情况可能不存在。
  4. 序言已提。
  5. “各地”……“该地”好像不通顺。
  6. 写死不好,上面已经说了“尽可能符合下列更多规则”了。

  1. 调整定义。
  2. 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 #关于可用与不可用符号的例外,Cesko与星海子,不用“符号”指代“符号和不常用文字”。
    • 符号 → 字符;
    • 可用符号 → 可保留的字符;
    • 不可用符号 → 不保留的字符。
  3. 精确ASCII字符中可用的字符范围。
  4. 胡祥又的建议,简化“去除字母数字和因技术限制而无法使用的字符后包括”
  5. 5.0 5.1 5.2 #关于通用规范中对于中文条目名中的标点的规定,令直角引号由常用度而非原文语言判断。
  6. 6.0 6.1 调整“/×”、“「」『』”的位置。
  7. 删除“以下中文标点符号所用字符”,避免产生“按用途判断是否保留”的歧义。
  8. 8.0 8.1 措辞。
  9. 9.0 9.1 #关于可用与不可用符号的例外,减少模糊的部分。作为特殊情况,移动到#不可用符号的处理(可能?)使流程更自然。移动不会引起逻辑问题,因为可用符号中有一条“后续规则允许使用的符号”。
  10. 10.0 10.1 10.2 10.3 10.4 10.5 减少歧义
  11. 明确“怎么进一步判断”
  12. 中文也可能被用作书名号。
  13. 13.0 13.1 13.2 #错别字
  14. 改英文条目名引号的使用,#关于通用规范正在讨论
  15. #摇人中Sytus、Qaolp0的建议。
  16. “以下”改“如下”。
  17. 17.0 17.1 移动“Ϡ → Sampi”的位置
  18. 改“去掉带附加符号的拉丁字母的附加符号”:汉语拼音ü转yu不是单纯去掉附加符号。
  19. #关于各种汉字和非汉字,“去掉附加符号”不总是属于“换用意义相近的字符”,因此另开一条。
  20. 20.0 20.1 20.2 20.3 20.4 20.5 20.6 20.7 参考Cesko的建议,微调。
  21. 清晰化。
  22. #关于消歧义
  23. 增“或滥用过滤器”;删,这些东西现已不在黑名单。

注释

  1. 1.0 1.1 将官方名称优先原则中字词转换的部分移动到了萌娘百科:字词转换指引,并参考关于字词转换指引的修订讨论续前提案#关于字词转换指引的修改部分做了一些调整
  2. 移动了官方名称优先原则中关于常用称呼的举例。

提案正文(最终版本)

替换萌娘百科:条目命名全文

本指引规范条目(namespace=0,不含消歧义页面和重定向页面)的命名。消歧义页面和分类的命名可适当参考此指引。

条目名是条目的实际标题,可以通过两对方括号([[条目名]])链入,网址中也包含条目名(可能会被转义)。而不一定是显示标题,后者可以参与字词转换,可以用{{标题替换}}、{{NoteTA}}等模板或魔术字更改。

条目名区分大小写,但是首字母总是大写,可以通过{{小写标题}}使显示的标题上的首字母小写。条目名中空格与下划线等价,在页面标题上显示为空格。{{标题格式化}}用于处理标题中的消歧义前后缀以及子页面、名字空间前缀。

确定一个条目名需要先后通过#命名原则#符号和不常用文字的处理两个部分

  1. 一个合理的条目名应当至少满足命名原则中的一条,并应当尽可能满足数目更多的原则。若某一称呼与其他称呼相比,所满足原则的数目更多,则优先采用该称呼。
  2. 通过命名原则选出的名称可能含有各种符号和不常用文字,经过处理后方可作为条目名。

若无法通过这种方式选择一个更优的条目命名,则相关编辑应对此进行协商讨论。

有时条目名可能无法确定,此时可以先暂定一个条目名,并在页顶悬挂{{暂定标题}}模板,写清暂定标题的原因。若日后确定了条目名,可以通过“移动”操作来将条目重命名,并移除{{暂定标题}}模板。所有添加了{{暂定标题}}的页面都会显示在分类:需要更名的条目中,以便管理。

命名原则

官方名称优先原则

译名取官方译名,即作品著作权的持有者或条目描述人物所订定或认可的中文名,如取宝可梦民安友绘

  1. 若无官方译名,取正式译名,即获授权出版、播放或发行的作品译名。
  2. 若翻译质量特别差、严重偏离原文,则不取官方译名、正式译名,如不取我与亲爱哥哥的日常(天角)、三年E班(B站)。可以用注释、讨论等方法说明如此选取的原因。
常用称呼优先原则

标题应当尽可能使用中国大陆最常见且较为正式的称呼,如取魔卡少女樱(B站)作为条目名,因为其比百变小樱(星空卫视)、百变小樱魔术卡(少儿社等)、百变小樱魔法卡(接力)、百变小樱 梦幻魔术卡(闽文音)更常见。如果没有,则可退而求其次,选择繁体地区(香港、台湾等)的称谓使用。

简体中文优先原则

原则上萌娘百科的条目命名优先级为:简体中文>繁体中文≫英文>日文等其他语言。外文标题可以翻译时尽量使用中文。
特别注意不要繁简混合命名,比如简体的消歧义后缀+繁体人物名,混合的标题会对搜索和语言转换带来影响。

另,对于条目名内含有日本汉字的情况,由于日文中包括大量现今简体或繁体中文已经不再使用的汉字,因此请根据实际情况对条目名进行一定的转写处理,而不要盲目照搬。具体的帮助性论述可见于Help:在条目名中可用与不可用的日本汉字一览

使用全称

惯例:请尽量不要使用简称或缩写来命名条目,除非这个“别称”只有它使用,或者这个“别称”大部分人都知道。尽量避免使用中文或外文缩写,除非该缩写已经被公认为专有名词,例如“苏联”、“IBM”等。

通用代称

有时条目中部分名称可通用,类似写作oo读作xx只要杀了oo我随便你搞,此种情况统一使用小写英文字母o和x替代(俗称通配符)。

尽量避免使用第三个通配符,如果有需要用到的情况,请先考虑命名是否合理。如“o最x的y”就会造成理解和检索困难,最终采取最常用的“喝最烈的酒”为条目名,其他用法在条目中附带介绍。

重名处理原则

一般而言,条目命名应当尽可能作出针对性的命名,而避免使用模糊不清晰的命名。当条目所描述对象具有另外的名称,或是更完整而又同等清晰的名称,我们就可以使用它们,如佐藤雏(而不是“雏(成神之日)”)、岛田半藏(而不是“半藏(守望先锋)”)等。

但在某些情况下,使用可能存在重名的名称可能才是一种更好的选择,这些情况包括:

  • 姓名为西洋人名的角色,全名过长的情况,如:露露(无彩限的怪灵世界)(而不是“露露拉露里·露拉拉里拉拉露露里里拉里·里拉拉露露拉拉露露拉拉里拉里”)、露易丝(零之使魔)(而不是“露易丝·法兰西斯·露·布朗·杜·拉·瓦利埃尔”)
  • 有歧义的名称更常用、知名度更高的情况,如:天使(守望先锋)(而不是“安吉拉·齐格勒”)、明日方舟:初雪(而不是“恩雅·希瓦艾什”)等。当下游戏等作品中的角色大量使用代号、网名等非传统人名的名称而导致重名,要求必须使用没有歧义的名称作为条目名没有意义。

请根据条目描述对象的实际情况灵活处理,而不要刻意为了回避歧义而选择并不泛用的名称。这种情况下,具体的命名规则详见萌娘百科:消歧义#条目名消歧义

符号和不常用文字的处理

“符号和不常用文字”在这里指除了汉字[注 1]、Aa—Zz、0—9外的所有字符。

当名称含有符号和不常用文字时,应当对名称按照下列规则逐步处理。

字符的保留与否

符号和不常用文字中满足下列属性之一的,在不涉及技术限制时可以保留

  • ASCII标点及符号,可以使用的有“(空格) ! " $ % & ' ( ) * + , - . / : ; = ? @ \ ^ _ ` ~”[注 2]
  • “。 ? ! , 、 ; : ( ) [ ] 〔 〕 【 】 — … “ ” ‘ ’ 「 」 『 』 ~ · 《 》 〈 〉 / ×”中的字符;
  • 在条目名中的用途为表达天文学、数学等现实科学中的特定含义的希腊字母[注 3],如小熊座α与梦境β受体阻滞剂与星辰
  • 若标题未经翻译而暂定,则可在不被系统阻止时,保留名称中原有的文字和符号;
  • 后续规则允许使用的字符。

其他字符应避免使用。特别地,出于技术限制,标题包含“# < > [ ] | { }”之一或某些特定组合的字符的页面无法被创建,详见Help:标题限制

统一格式

若将用于条目名的名称中存在下列字符,在条目名中请一律使用(或改为)指定的字符。这虽然在个别情况下不是最合适的,但有助于避免混乱。虽然这里涉及的不少字符难以用肉眼判断,但常见错误会被自动阻止,不必过分担心。

  • 空格使用“ ”(U+0020 space),而非其他各种空白字符。
  • 间隔号使用“·”(U+00B7 middle dot),而非“.”(U+FF0E)、“‧”(U+2027)、“•”(U+2022)、“・”(U+30FB)、“・”(U+FF65)等各种点[1]。在多数主流的电脑端中文输入法的中文输入状态下,按1键左侧的`键输入的就是这个符号。
  • 希腊字母使用希腊文字和科普特文字(Greek and Coptic)Unicode区段的字符。
  • 全角拉丁字母、阿拉伯数字改为半角。
  • 专门的罗马数字字符改为用拉丁字母拼写的形式,如将“Ⅲ”改为“III(3个I)”。实际上,使用拉丁字母拼写罗马数字并不是错误的,反而更为规范[2]
  • “〜”(U+301C wave dash)改为“~”(U+FF5E fullwidth tilde),前者多出现于日文中。
  • “‐”(U+2010 hyphen)、“−”(U+2212 minus sign)、“–”(U+2013 en dash)改为“-”(U+002D hyphen-minus),即键盘上直接输入的短横线。
  • “―”(U+2015 horizontal bar)改为“—”(U+2014 em dash),即通常的“半个中文破折号”。

下面的规定与消歧义有关,部分涉及系统运作:

  • 用于消歧义的括号和冒号,使用半角,如爱丽丝(东方Project旧作)恋姬无双:诸葛亮
  • 当条目名出现非消歧义用途的半角冒号时,需要在条目中使用{{ColonSort}}或以其他方式保证分类索引正确,对全角冒号不需要这么做。
  • 消歧义前缀中不要出现“/”,消歧义后缀中不要出现“:”和“/”。
通用规范

在作品著作权的持有者或条目描述人物另有公开的明确规定时,不必遵循本章节涉及的内容。

半角斜线“/”涉及子页面功能,当条目不用作子页面,官方名称中也不含“/”时,条目名中要尽可能避免“/”。使用“和”或“或”通常可以达到类似效果。

对于作品,在名称不满足官方名称优先原则时,副标题的表示方式应尊重原题。各种表示方式包括“主标题:副标题”、“主标题 副标题”、“主标题 -副标题-”、“主标题 ~副标题~”等。但具体符号要根据条目名的文种进一步判断,见下。

在符合#可保留的字符#统一格式的基础上,条目名中的标点符号应使用条目名对应文种中更加规范、通用的形式。这一般能解决问题,但以下情况需注意:

  • 对于中文条目名中的标点:
    • 直角引号“「 」”和“『 』”(有时也用作书名号),当该符号所在名称满足官方名称优先原则常用称呼优先原则时可以使用。其它情况下,直角引号应转为弯引号或书名号。
    • 浪纹线“~”和“~”,当原文为日文或中文时,浪纹线的全半角与原文一致。其它情况下,使用更规范的“~”[3][1]。若使用了“~”,则应建立半角的重定向以应对其他条目中的链入。
    • 日文中的“。”“、”“・”与中文的“。”“、”“·”并非完全对应,不宜生搬硬套。
    • 两个及以上点号连用时,其全半角与原文一致,如竞女!!!!!!!!使用的就是半角。
    • 对形如“主标题 -副标题-”的标题,其副标题两侧的横线,字宽接近或超过一个汉字的,用一个或多个“—”;其余的用“-”。
  • 对于英文等拉丁文字条目名中的标点:
    • 标点周围空格的有无,与原文一致,如Bright!Light!中并无空格。无法参考原文(比如原文该部分并非英文)时,按照规范的做法。
    • 引号一律使用直引号“" "”和“' '”,而不是弯引号““ ””和“‘ ’”,撇号也使用直式。
    • 对形如“主标题 -副标题-”的标题,副标题两侧的横线用“-”。
  • 对于混合文种条目名中的标点,尽量参考官方名称,跟随其用法,在条目名没有取官方名称等无法参考的情况下,再参考常用名称。仍无法判断时,提供如下方法以供参考,依照最先满足的方法判断。对于此类混合文种的标题可适当建立不同重定向以应对在其他条目中的链入。
    1. 有副标题时,主标题与副标题分别判断,主副标题之间的符号,在可以参考原文时,与原文一致,否则按主标题的文种判断;
    2. 不同文种的部分可以单独成句时,分别判断;
    3. 一种文字占主导地位时,整体使用该文种的标点;
    4. 含有中文时,整体使用中文标点。
  • 成句类条目标题中的通配符“o”“x”不影响成句系何种语言,例如o——o——被视为中文成句。
不保留的字符的处理

未被#统一格式#通用规范提及的不保留的字符可灵活处理,例如:

  • 换用意义或作用相近的字符:艾玛★奥加斯特 → 艾玛·奥加斯特,藤子不二雄Ⓐ → 藤子不二雄A
  • 用文字描述:88☆彡 → 88流星
  • 拉丁化(罗马化),以及使用不带附加符号的26个拉丁字母:Ϡ → Sampi,Japari Café → Japari Cafe
  • 主要用作装饰的符号,删除或替换为空格:千恋*万花 → 千恋万花;777☆SISTERS → 777 SISTERS

上面只是举例,并不局限于以上方法,对特定条目可以有其他更合适的改法。

  • 在名称为乱码、空白等难以处理的情况下,用别称命名可能是更好的选择,即重新挑选一个符合尽可能多的命名原则的名称作为条目名。

若仅调整一部分字符会造成违和,可选择将其他部分一并调整。

例外情况

部分条目不保留某些文字会不合适,主要表现为缺乏辨识度。若待处理的条目名中本应(即不考虑本规则的情况下)不保留的文字满足以下全部条件,则可以保留:

  • 在所属的语言中没有明确含义,或在条目名中的含义与原本的含义无关;
  • 不是装饰,也不是用其形状构成其他语言的词语(用形状的如Next New Wφrld中的“φ”);
  • 以合适的方式(不刻意避免歧义)处理这些文字后,条目名会与其他存在的条目产生歧义。而保留这些文字则无歧义。

若有条目因此得以保留名称中的某些文字,那么在其他条目名中提及该条目描述的对象时,也可以保留这些文字。

注释

  1. 此处的汉字为Unicode中具有Unified_Ideograph字符属性的字符,以及“〇”(U+3007 ideographic number zero)。它们基本位于中日韩统一表意文字(CJK Unified Ideographs)及其扩展(Extension)区段。若不确定,可于Unicode Utilities: Character Properties查看字符的属性,确认Unified_Ideograph的值。
  2. 美式键盘可以直接输入的字符一般都是此类。
  3. 增量符号“∆”(U+2206 increment)、求积符号“∏”(U+220F n-ary product)、求和符号“∑”(U+2211 n-ary summation)不算作希腊字母。

参考

  1. 1.0 1.1 《中文排版需求》§ 3.1.1.2 标号
  2. "Acrophonic Systems and Other Letter-based Numbers". The Unicode® Standard Version 14.0 – Core Specification § 22.3 Numerals. p. 853.
  3. 《标点符号用法》(GB/T 15834—2011)§ 5.1.6:“……浪纹线占一个字位置。连接号上下居中……”;《重訂標點符號手冊》(2008年修訂版),連接號一節:“占一個字的位置,居正中。”

Help:符号使用指南列为失效文档

与当前习惯出入过大;过于繁琐。

修改萌娘百科:字词转换指引

  1. 全文手工转换规则应该放在源码开头,同时各规则不能繁简混合,否则转换会失败。

改为:

  1. 条目中地区词的选取应尽可能符合下列更多规则(官方译名和正式译名的定义与萌娘百科:条目命名相同):
    • 分别选取各地的官方译名(或者当对象出自其中一个地区时,其在该地的官方名称)作为地区词;
      1. 若各地均无官方译名,则取各地正式译名,如取“魔卡少女樱”(B站)、“百變小櫻Magic咭”(无线电视等)、“庫洛魔法使”(东立等)分别作为中国大陆、香港、台湾的地区词。
      2. 若某地无官方译名,可以但不建议将该地的正式译名与其他地区的官方译名混在同一规则中;
      3. 若翻译质量特别差、严重偏离原文,则不取官方译名、正式译名。
    • 尽可能使用各地最常见且较为正式的称呼作为该地地区词。

将所有“(namespace=…)”改为“(namespace=…)”。

修改萌娘百科:消歧义

将“消歧义页面内容”的

  1. 消歧义页中的义项应使用原始页面名称,而不用管道符改变显示文字,以减少混淆,如不应让结衣(刀剑神域)显示成结衣

改为

  1. 消歧义页中的义项应使用原始页面名称,而不用管道符隐去消歧义前后缀,以减少混淆,如不应让结衣(刀剑神域)显示成结衣。但如果条目名是根据萌娘百科:条目命名#不保留的字符的处理调整的,则可以改变显示文字为调整前的名称。

修改萌娘百科:重定向方针

#用途第1条的第3、4条

  1. 重定向至避免特殊符号的页面名;
  2. 将外文拉丁字母页面名重定向至ASCII字母页面名;

改为:

  1. 由处理符号和不常用文字前的名称重定向至处理后的页面名;
  2. 在处理符号和不常用文字的过程中产生的可能被链入的重定向;

在“特别地,当重定向目标存在多个有收录价值的歧义项时,应停止创建重定向并根据萌娘百科:消歧义方针进行消歧义。”前增加一段:

通过页顶搜索栏搜索时,全半角差异会被忽略,直接跳转到对应页面;在Special:搜索中,符号会被忽略。基于此,官方未使用过的与目标页面名仅全半角有差异的重定向不属于“改善搜索”的范畴,但这类重定向可能会符合“改善搜索”之外的用途。

提案通过后的操作

此章节讲解了若本提案通过,维护人员应当执行的、其他编辑者应当遵循的操作。由于因本提案而需要更名的条目很多,且部分不易发现,故不强求短期内处理完所有条目。

字词转换指引的修改涉及条目较少,不做详细说明。新条目和重定向直接按照更改后的萌娘百科:条目命名萌娘百科:重定向方针创建。旧条目需要对照以下几个方面处理:

更名

在本提案通过后,有大量条目需要更名。这类条目多是为了避免全角标点而以换用半角标点或空格或删除标点。

欢迎有经验的编辑者协助更名,但是,为避免混乱,不能仅移动页面,而需要负责处理后续#标题替换#重定向#内部链接#分类索引#分类页)。

注意:符号被放开一部分,不代表包含符号的名称就是好的,同之前一样,名称仍需要尽可能满足数目更多的原则。

主要检查的方向:

标题替换后的名称、条目的“一句话介绍”中的名称、信息栏中的名称通常是处理符号和不常用文字前的名称,可作参考。


整体上本提案扩大了可用的符号范围,但是有些条目的命名在本提案前可能就不符合指引,在本提案后依然不符合指引。之所以之前就没有遵循指引,可能是因为命名困难。“更名这样的条目”的优先级可以往后放。以下是部分这样的条目中包含的符号以及解决办法:


#不保留的字符的处理中的例外情况,如μ's(“缪斯”、“Muse”与其他条目有歧义)、élf(“elf”与精灵(种族)有歧义)等,这些条目不更名。

标题替换

移动后需要检查是否还需要标题替换。移除不需要的标题替换。不局限于{{标题替换}}模板。

例如:

重定向

重定向方针发生变化,移动时应判断是否需要留重定向。由含半角标点的中文标题移动到全角标点的中文标题时,其重定向不再需要。

若重定向不再需要,则:

如果链入较少,维护人员在移动时可不留重定向,并尽快处理链入。若链入页面过多且无法尽快处理,则暂时保留重定向,待处理完链入后再删除/挂删。

其他有经验的编辑者在处理完链入后,于操作申请版提删重定向。

例如:

内部链接

如果条目更名后,重定向保留,可自由选择是否替换内部链接。

如果条目更名后,重定向不再需要,则链接应尽快被替换(可申请批量替换)。替换后删除/挂删/提删重定向。

分类索引

  • 更名后的条目存在非消歧义用途的半角冒号时,使用{{ColonSort}}等设置分类索引。
  • 更名后的条目以符号开头或消歧义前缀之外的部分以符号开头,重设合适的分类索引。不在开头时,也可选择设置。例如:

分类页

作品分类名一般跟随条目名,因此条目移动时,分类也应随之移动。

分类同样需要判断是否留重定向,并采用与#重定向相似的处理方法。

标题黑名单

管理员酌情将全角拉丁字母、全角阿拉伯数字加入标题黑名单或滥用过滤器。

消歧义页

补回符号不是强制的,不用揪这个。

讨论区

用于举例的条目名两端使用的标点符号

例如,“两个及以上点号连用时,其全半角与原文一致,如竞女!!!!!!!!使用的就是半角。”中,竞女!!!!!!!!外部是不使用标号,或是使用引号(“竞女!!!!!!!!”),还是方头括号(【竞女!!!!!!!!】)? あめろ 讨论 2022年8月1日 (一) 22:21 (CST)

随机翻了几个帮助文档,大部分举例外部都是不用标号标注的,确实用颜色来区分可能已经足够了。用中括号括注的只有少部分,而且一般不是作为例子而是作为需要强调的链接存在的。用引号标注的也只有少部分,我感觉这里的引号的作用是“用于需要着重论述或强调的内容”,普通的举例应该用不着。——  𝐶ℎ𝑖_𝑍𝐽𝟐【讨论】  2022年8月1日 (一) 23:01 (CST)

可用与不可用符号

若名称来自原文为简体中文的作品,则还可使用“「」『』”。

这个应该是原文为繁体中文的作品吧?——来自糟糕的妹控狗头人 2022年8月1日 (一) 22:43 (CST)

简体中文同样会使用“「」『』”,因为有人觉得美观。—— 屠麟傲血讨论) 2022年8月1日 (一) 22:45 (CST)
按照简中的标点符号用法 , 只有竖式排版才能用「」代替单引号 ,用『』代替双引号(来自《新华字典》第11版附录)。所以一般萌百的横式排版中要换回来。

--SkySakura2005讨论) 2022年8月1日 (一) 22:52 (CST)

没有必要死守那个规定,百科不是出版物。作品官方使用这个引号的也比比皆是。——From 引梦者浊华(讨论) 2022年8月1日 (一) 23:01 (CST)
简中的引号一般使用弯引号,如同繁简转换一样,繁体使用的直引号在这里变为弯引号很自然。但是有些简体中文作品仍然使用了直角引号,这时可名从主人。这方面在上个提案中也有讨论,我采纳了讨论结果。 あめろ 讨论 2022年8月3日 (三) 01:44 (CST)
在简中语境常用 “ ” 的情况下,使用直引号若是作者有意为之,我觉得可以保留。From Sucaiking the WAFighter 2022年8月20日 (六) 15:06 (CST)

关于名字过长人物名

  1. 在「重名处理原则」段落的“姓名为西洋人名的角色,全名过长的情况,”改为“人名全名过长的情况”况(主要针对类似于小屎丸非西洋出身但全名过长的一类人物)
  2. 需要一个明确的全名过长的标准

--信偶活如信混沌四神的喵某讨论) 2022年8月1日 (一) 22:48 (CST)

这个问题不在本提案的讨论范围内吧。“与符号、地区词无关的问题,此提案不解决”。——4O74Y74L74J7讨论) 2022年8月1日 (一) 22:55 (CST)

关于现有标题使用了希腊字母的条目

既然希腊字母的允许被去除,那么现存的标题中保留了希腊字母的条目(上次提案中星海有整理过)需要如何处理?全部都移动到拉丁转写吗?——4O74Y74L74J7讨论) 2022年8月1日 (一) 22:55 (CST)

部分解决方法我在那个串提了,剩下的可能就只能拉丁化了。要不让不喜欢希腊字母的User:星海子User:LuoxuchanUser:Leranjun发表下意见? あめろ 讨论 2022年8月3日 (三) 02:18 (CST)
可以考慮不溯及既往,日後慢慢彙整處理。—— Eric Liu 創造は生命(留言留名 2022年8月12日 (五) 02:50 (CST)

关于成句的通配符

这什么爱提不提的提案虽然我一时半会儿没想到具体例子,有没有一种可能存在“成句很短但是可替换部分很长”导致仅使用一个通配符也容易导致易于混淆?如果有,我认为应该添加这一种可能性,表明在这种情况下也不使用通配符。——   于是我放弃了二饼已读不回) 2022年8月1日 (一) 23:19 (CST)

这个其实是#通用代称应该解决的问题,我不太想在这个提案改,以后按指引的修订步骤修订即可。 あめろ 讨论 2022年8月3日 (三) 01:44 (CST)

关于通用规范

  1. 若原文为英文等拉丁文字且使用弯引号,则条目名与之一致——虽然但是,由于显示宽度的原因,弯引号在横文字中的观感属实不好。
  2. 其它情况下,使用更规范的“~”——这个符号似乎不是很方便打出?我欲打出时都需要切换至日文输入法,否则用中文输入法时输出的都是“~”。(好玩的是,日文里常见的“〜”我反而打不出)
  3. 对于作品,在名称不满足官方名称优先原则时,副标题的表示方式应尊重原题——一些常用非官方译名的标点符号未必和原题一致,关于搜不搜索得到之类的事先让我杞忧一下。
  4. 两个及以上点号连用时,其全半角与原文一致——没太理解这句话的包含范围,像日文里常有的“!?”中文里写作“?!”,像“!?!?!?”在我的理解里是应该写作“?!?!?!”,最起码也该是“?!?!?!”吧。

目前先想到这些。--某FFF团的高级火法 批判一番) 2022年8月1日 (一) 23:35 (CST)

对于您提出的第4点,依国标《标点符号用法》(GB/T 15834-2011),确有“4.3.3.4 当句子包含疑问、感叹两种语气且都比较强烈时(如带有强烈感情的反问句和带有惊愕语气的疑问句) , 可在问号后再加叹号(问号、叹号各一)。”但是实际使用中,“?!”常用于表示质疑(疑问占主体),而“!?”常表示震惊(惊叹占主体),真正“两种语气且都比较强烈”是不存在的。故我认为可能不应禁用“!?”。--Takeuchi.BadEditor (讨论留名) 2022年8月2日 (二) 08:50 (CST)
@Takeuchi 所以这里的问题又回到第三点,毕竟我并不是自译派。--某FFF团的高级火法 批判一番) 2022年8月2日 (二) 12:29 (CST)
关于第2点,我个人中文输入法环境(微软拼音/搜狗拼音)下要打出“~”一般是切换到全角形式(默认快捷键:⇧ Shift+空格)后⇧ Shift+`打出。——GuoPCまだまだ見つけるよ 新しい自分 ここから未来へ」 2022年8月2日 (二) 10:00 (CST)
感谢建议。
  1. 英文的弯引号是沿自上一个提案,当时没人反对就保留了。现在我认为应使用直引号,已改。
  2. 对于浪纹线我自己也是飘忽不定,我看看还有没有更多意见。
  3. 如果是萌百内的搜索的话,这不必担心,搜索时会忽略符号。在上个提案#关于系列作品标题中冒号的使用中Xzonn表示“官方没有明确的情况下,‘是否用冒号’的问题按照作品原始标题有无冒号来决定(日系游戏按日文标题,欧美游戏按英文标题)”,我认同他的看法。
  4. “?!”还是“!?”的问题,我认为不规定更好,有的作品如果在国内就是更倾向于“!?”,把它反过来反而别扭。
—— あめろ 讨论 2022年8月3日 (三) 01:44 (CST)
提议英文直弯引号名从主人。如“UNIONS” Road封面明显为弯引号,移动到直引号又需要一次新的标题替换才能使显示标题与内文显示一致;像"I"这样的则根据专辑封面明显判断为直引号。此外像满怀“love”接近中!这类混合文种的标题,根据下一条含中文/中文占主导原则应按中文标准使用引号,即名从主人使用弯引号,但这里引号括的明显是英文。基于以上两个原因,单纯指定纯英文使用直引号没什么意义,建议改回去。— 小鹿包18 Honoka55留言贡献・ 2022年8月5日 (五) 09:59 (CST)
双引号还好,然而像Sister’s还有Make ’Em Afraid这种在电脑上的显示只能让人一头雾水,如果有技术手段解决那就更好。--某FFF团的高级火法 批判一番) 2022年8月5日 (五) 13:52 (CST)
你说的有道理,高级火法说的也有道理,我认为改回去的可能性是有的,正是需要更多声音。对于满怀“love”接近中!,引号的是英文不影响引号所在的句子是中文,这是我根据《夹用英文的中文文本的标点符号用法(草案)》(PDF)和CY/T 154—2017《中文出版物夹用英文的编辑标准》得出的结论。 あめろ 讨论 2022年8月5日 (五) 14:40 (CST),修改错别字于2022年8月6日 (六) 00:11 (CST)
统一直引号恕我不敢苟同,现代阅读媒体已经对直弯引号的各种形式做出了各种适配,直引号本身也是在打字机时代受到技术和码位限制的产物。既然中文命名允许弯引号的存在,为何又限制英文命名不允许存在弯引号呢。个人认为此处遵从名从主人原则即可。——bob1301讨论) 2022年8月5日 (五) 10:49 (CST)
可能Windows不是现代阅读媒体吧……微软雅黑的弯引号始终是一个汉字的宽度,放到英文中极其丑陋。历史产物又不是不能用,就像你依然在用“-”(hyphen-minus),而没有用“‐”(hyphen)或“−”(minus)一样。英文命名不用弯引号理由有两点:1. 在很多中文设备上间距不好看;2. 不方便打。其中第1点是最主要的。不过你说的也有道理,我认为改回原来版本的可能性也是有的,正是需要更多声音。 あめろ 讨论 2022年8月5日 (五) 14:40 (CST)
如果保留弯引号,是否应允许进行标题替换,替换成能显示合适间距的字体(如多数设备自带的Helvetica)? 淮南皓月 🌙 2022年8月5日 (五) 20:20 (CST)
甚至可以写个全站js,把“[\s\w]+”中的弯引号按半角格式显示(暴论——bob1301讨论) 2022年8月5日 (五) 20:38 (CST)
标题替换哪有禁止过嘛。 あめろ 讨论 2022年8月6日 (六) 00:11 (CST)
英文标题中引号改以半角显示是做得到的,可以用{{标题替换|{{lang|en|{{PAGENAME}}}}}}。不套lang|en诚然丑,但也不单单是标题的问题,在正文中不套一样丑,而且看看萌百正文中用弯引号的英文页面,大多数都是没套的。所以标题和内文中应该统一由编者处理,强行规定直引号一样会有编者直接标题替换成不套lang的弯引号版,显示效果和直接弯引号命名不替换是一样的。内文摆烂了标题跟着摆烂也是一种做法,总不能要求内文也全部替换成直引号。对标题的规范可能就这一点是美观考量吧?感觉不太合适,不应强制规定“英文就直引号”来进行不必要的约束。— 小鹿包18 Honoka55留言贡献・ 2022年8月6日 (六) 04:02 (CST)
套了{{lang|en|}}后弯引号一样会显示一个汉字的宽度。--某FFF团的高级火法 批判一番) 2022年8月6日 (六) 09:49 (CST)
全部改成"太怪了,按照语境用就行,另外字体不止一种,太丑可以换,为什么一定要说某某字体显示不佳呢:“测”试"效‘果’(如果确认要统一直引号,我可能就要投反对票了)--有点怂的playymcmc007签名请用--~~~~哦讨论爆破) 2022年8月5日 (五) 22:36 (CST)
( ¿ ) 喵喵喵? 我改的英文,你拿中文举例子啊? あめろ 讨论 2022年8月6日 (六) 00:11 (CST)
是我看错了😂以上个人发言作废--有点怂的playymcmc007签名请用--~~~~哦讨论爆破) 2022年8月6日 (六) 00:32 (CST)

关于符号的列举表示

这个分段名字怪怪的,不管了在替换萌娘百科:条目命名全文→通用规范→符号和不常用文字的处理中,提及了引号,但是““””、“‘’”未免太过奇怪 所以建议把和标题符号相关的加粗或者加个颜色方框之类的,例:““””--有点怂的playymcmc007签名请用--~~~~哦讨论爆破) 2022年8月2日 (二) 23:43 (CST)

《标点符号用法》里也是这样举例的,不奇怪。粗体也会有困境:只加粗这一处的话,与其他地方格式不统一;所有符号都加粗的话,间隔号那里会加大混淆。 あめろ 讨论 2022年8月3日 (三) 02:26 (CST)

摇人

@葫芦又Bob1301徴氷棠淮南皓月秋园世界Ericliu1912沼泽YpaafwLegend frogSytusQaolp0宇文天启方之易小文(顺序随机的),打扰了,能看看有什么要修改或补充的吗?我个人感觉到的问题是#通用规范中没有给一个特殊情况特殊处理的出路。 あめろ 讨论 2022年8月5日 (五) 01:24 (CST)

@C8H17OH,这个指引里没像成句那里一样写“中文用全角,英文用半角”,而是写了“使用对应文种中规范、通用的形式”,这是不是足够了?。因为全半角这个概念也会有疑问,如“。”的半角不是“.”而是“。”、弯引号不分全半角等。 あめろ 讨论 2022年8月5日 (五) 01:24 (CST)

@屠麟傲血,字词转换指引的改动较上次删了一点东西。 あめろ 讨论 2022年8月5日 (五) 01:24 (CST)

#通用规范中提到的混合文种解决方案:“尽量参考官方名称或常用名称,跟随其用法。” 官方名称和一些媒体或自媒体使用名称可能冲突。这点明确一下比较好,都参考可能会引发争议。—— SytusTalk 2022年8月5日 (五) 10:54 (CST)
个人认为官方命名优先度在常用命名之上,除非无官方译名或因“翻译质量特别差、严重偏离原文”而改取常用命名。--Qaolp0 うさぎみずき (讨论) 2022年8月5日 (五) 11:22 (CST)
改了一下。 あめろ 讨论 2022年8月11日 (四) 04:29 (CST)
虽然有些( ¡ )题外话 ,不过像#关于现有标题使用了希腊字母的条目中的部分条目命名可能就符合“特殊情况特殊处理”的情形。之前μ's就因为这个问题讨论过一次。
如果最后必须要求希腊字母标题改名,不知道葫芦又有什么看法?是另开讨论重新命名,还是给此类特殊情况下的官方译名开绿灯(毕竟#可用与不可用符号中只是避免而非禁止不可用符号的使用,虽然同样要经过讨论)?如果重新命名,那么名称是什么?u's?muse?缪斯?--Qaolp0 うさぎみずき (讨论) 2022年8月5日 (五) 11:22 (CST)
我超,我想起来我为啥要允许希腊字母了,一下子被冲昏了头脑给搞忘了。 あめろ 讨论 2022年8月5日 (五) 14:40 (CST)
已发起讨论。 あめろ 讨论 2022年8月6日 (六) 00:29 (CST)
这种具有巨大知名度的名称还是开绿灯吧。如果μ's条目直接更改成缪斯、muse、u's之类的名称 , 反而会让一些只是为了上萌百检索的用户摸不着 头脑 ,看上去像矫枉过正 。——From不是Vup的冰糖 2022年8月5日 (五) 15:04 (CST)
好像不是啥重要的东西,没时间细看了,你们讨论,回头我只管投票 -- 宇文西修ิิۣۣۖۖۖ特拉瑟 2022年8月5日 (五) 11:52 (CST)
全半角那个只是因为以前的指引是有“一般应用半角”这样的表述,所以作为例外的情况才需要说“成句用全角”。既然指引已经重构了,那之前的表述如何就不重要了,根据当前草案的情况来定就好。——C8H17OH讨论) 2022年8月5日 (五) 15:02 (CST)
原文中有两句会自相矛盾: “一 种文字占主导地位时,整体使用该文种的标点;含有中文时 ,整体使用中文标点 。 ” 那如果在一个标题中含有中文但不占主导地位而英文占主导地位,那么是用全角还是半角?因此,建议改为“若标题中不含中文 , 一种文字占主导地位时,整体使用该文种的标点;含有中文时,整体使用中文标点 。 ”——From不是Vup的冰糖 2022年8月5日 (五) 15:04 (CST)
有说“依照最先满足的方法”,所以并不矛盾,不需要更改。—— 超级纯洁的小马娘秋园邀请你去地下室重马场一坐 2022年8月5日 (五) 15:08 (CST)
我没啥问题了,我对之前过气的那一版就没啥问题了,这一版也一样。虽然有点繁琐但总的来说是好的是必要的。—— 超级纯洁的小马娘秋园邀请你去地下室重马场一坐 2022年8月5日 (五) 15:11 (CST)
刷个票权,衷心希望不会因为一两个反对点而整个提案反对。——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月5日 (五) 18:07 (CST)
去掉希腊字母有点疑虑,不过已经有人提了。暂时看不出其他问题,上一版提案我就是支持的。 淮南皓月 🌙 2022年8月5日 (五) 20:20 (CST)
同意。感觉最好能在原则上允许包括希腊字母在内的任何常见字母的使用,而不仅仅是为几个特例开绿灯。
如果实在不能接受主要页面使用任意字母,那么至少应当允许重定向页面可以使用。我觉得作为一个百科网站,方便读者查找条目也是必要的;如果对于某一条目,读者只知道其含有希腊字母或其他特殊符号的版本,不知道该条目在萌百中的形式,从而误以为萌百中没有收录该条目,那就太不好了。--方之易小文讨论) 2022年8月7日 (日) 00:05 (CST)
常用名重定向自然是符合方针的。--某FFF团的高级火法 批判一番) 2022年8月7日 (日) 00:11 (CST)

谢谢大家,官方名称、开绿灯这些我会想办法处理的,有建议的话也欢迎提出来。 あめろ 讨论 2022年8月6日 (六) 00:29 (CST)

希腊字母讨论

缺人!缺人!上次和星海子讨论,以及在站外问了一些人的意见,我在这次提案去掉了希腊字母,但是这次来看仍然有一些人有疑虑,我意识到参与讨论的人还是太少了。因此,我觉得这个得再次深入讨论。来汴一汴汴一汴,大家认为在什么时候可以在条目名中用希腊字母?

这是星海子在2022年5月1日统计的数据,我不知道有没有新增:

名称包含希腊字母的主名字空间页面(含重定向↳)

μ's使用希腊字母肯定都没有反对意见吧?对于希腊字母(其实其他有争议的符号也是)有几种处理方法

  1. 不允许希腊字母,将μ's作为#可用与不可用符号的“例外”(对于一个条目,若……则可……以包含该符号的名称作为条目名)看待;
  2. 仅在部分情况允许希腊字母(什么情况?);
  3. 不禁止希腊字母,依靠#官方名称优先原则#常用称呼优先原则#简体中文优先原则综合判断是否使用希腊字母;
  4. 有更好的办法?

星海子(可能包括珞珝、乐然)的意见我知道,理由是不易输入(不知是否有其他理由),是的,但这忽略了另一个问题:因不能使用希腊字母而需要思考规避希腊字母的条目名、替换标题、建立重定向……这些后果同样需要耗费精力。我支持不禁止希腊字母,我们还有别的方法来决定不使用某些希腊字母,这些我上次也说过了,如:

其他人认同哪种方法呢?无法得出共识的话(这条目命名的“特殊符号”也是汴了好几年了)可能还是得选择方法1,因为根据原“避免特殊符号原则”的精神,希腊字母也算特殊符号,新“符号和不常用文字的处理”不让用它也无可厚非。 あめろ 讨论 2022年8月6日 (六) 00:11 (CST)

@4O74Y74L74J7Qaolp0淮南皓月星海子,抱歉再次打扰了。 あめろ 讨论 2022年8月6日 (六) 00:17 (CST)

就算不保留,非整体读音一部分的单个希腊字母好歹转写成Alpha或阿尔法之类的吧……--某FFF团的高级火法 批判一番) 2022年8月6日 (六) 00:30 (CST)
ACG用希腊字母标题一为某些中二或卖萌标题取其形(比如OwOver),二为确立其计数(alpha=lv1,beta=lv2,omega=lv3啥的),取字母外形的全部不留,计数的酌情取中英文转型,含天文学背景的和你们喜欢的μ's保留,以上——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月6日 (六) 07:04 (CST)
(-)不支持 完全禁用希腊字母,尽量希望能够争取到2或者3。对那些用仅仅使用字形的装X支持完全转写,用于表示次序的个人认为应当保留。(天文学背景相关的实际上也包含于这一类,而且习惯上就是打希腊字母,用转写反而显得不便)——AKQ 代号 不可逆Talk/Contributions) 2022年8月6日 (六) 08:47 (CST)
附:如果有涉及到条目命名有自然科学相关内容要用希腊字母(如θ表示角度、ω表示角速度等)的时候也支持保留(虽然现在似乎还没有例子)
总之就是该用的地方(次序、科学等,通常都是小写)保留,只用字形的不保留。——AKQ 代号 不可逆Talk/Contributions) 2022年8月6日 (六) 09:27 (CST)
我在上一个讨论串中提出此话题的目的其实是希望重视一下禁用希腊字母后的遗留问题,至于最后讨论保留希腊字母与否我不持意见。
考虑到实际情况,个人认为单独绿灯以及未经讨论的移动可能会导致部分编辑组的不满甚至社群撕裂……最后保留希腊字母并依靠其他条款判断当然是好事,不过如果最后结论是完全禁止,那么提前讨论好备用名称(毕竟知名度在那里)同样可以省去后续的麻烦。
召唤一下相关用户:@LeranjunLuoxuchanBob1301西尾哈鲁卡胡祥又C8H17OH。--Qaolp0 うさぎみずき (讨论) 2022年8月6日 (六) 13:02 (CST)
我认为可以使用标题替换/格式化+带希腊字母重定向的方式进行条目命名,避免了创建条目时难以键入/希腊字母套壳等问题,同时使条目命名规范化————Erwwyh 2022年8月6日 (六) 13:11 (CST)
1也能接受,不过还是(☩)大致同AKQ 倾向2或3。不反对去掉自造词中的希腊字母,但β受体阻滞剂、小熊座α这种合乎常理的写法,也转写成beta、alpha甚至是用汉字代替,难免有多此一举之嫌。
( ¡ )题外话1 Φpera娘-->Opera娘的重定向是错的,实际上应该是Øpera娘(挪威文字母Ø,不是希腊字母phi)。我直接挪走了。
( ¡ )题外话2 游戏王龙辉巧卡组这一系列译名挺迷惑的。天棓三天龙座β指代的是同一事物,不知道翻译时为什么要糅合成天棓三β。 淮南皓月 🌙 2022年8月6日 (六) 22:19 (CST)
卡名原文:竜輝巧ドライトロン-ラスβベータ(日文,OCG) / Drytron Beta Rastaban (英文,TCG) / 辉龙机巧-天棓三贝塔(简体中文)
常用译名:龙辉巧-天棓三β(NWBBS) / 龙辉巧-天龙β(CNOCG)
打牌时的简称:β
( ¡ )题外话的题外话:真有人会在萌百查卡吗
--Cesko讨论) 2022年8月6日 (六) 22:57 (CST)
( ? )疑问 不知道有没有游戏王wiki?没有的话还是有可能的。--北湖3讨论) 2022年8月7日 (日) 20:05 (CST)
网页卡查——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月7日 (日) 20:09 (CST)
萌百的页面不同于ourocgEngie这些卡查,会详细写出每张卡的原型、设定、相关梗什么的,还是比较翔实的。但是内容收录不全。--夜醉听涛讨论) 2022年8月9日 (二) 22:43 (CST)
啊,原来卡名就是neta而不是真实的天文学名词。是我没注意。 淮南皓月 🌙 2022年8月8日 (一) 19:17 (CST)

统计下来是这样:

  • 方案1:星海子?、Erw?(我不确定);
  • 方案2:Legend frog、AKQ、淮南皓月;
  • 方案3:AKQ、淮南皓月、あめろ。

不相上下,那折衷选方案2如何?对于方案2,Legend frog和AKQ均提出了“取字母外形的不留,天文学的保留”,其余的可以进一步确定范围,例如PSY骨架王·ΖPSY骨架王·Ω的希腊字母要不要改。还需要解决的是,目前我还没想到一个合适的措辞可以在不把“μ's”作为特例看待时,将其包含进去。 あめろ 讨论 2022年8月8日 (一) 05:25 (CST)

μ's里希腊字母采用的是读音,也许可以从这里入手?--某FFF团的高级火法 批判一番) 2022年8月8日 (一) 10:46 (CST)
就现有的例子来看我觉得有可行性,“在标题中的读法与字母读音一致”就能排除大多纯装饰和stylize装酷的情况,还不用汴像Justiφ's这样的标题要移动到Justifies还是JustiPhi's/Justiphi's。 淮南皓月 🌙 2022年8月8日 (一) 19:17 (CST)
我先投个方案二,建议是成专有名词的保留,如ACG组合名及其衍生(μ'sεpsilonΦ等)、天文学名词、生物化学名词等(但生物化学名词真的有收录吗(
ACG组合及其衍生这一点可能还需要再讨论,比如其相关内容数量达到多少之后才允许之类的?——bob1301讨论) 2022年8月8日 (一) 11:32 (CST)
我还是和之前一样的观点。平时睁只眼闭只眼算了,如果非要明文允许,我觉得不行。—— ほしみ 2022年8月9日 (二) 22:49 (CST)
如果不允许,那么个人希望能在#提案通过后的操作中给出上方列表中条目名称的解决方案。如果在此处难以达成共识,如个人于前所述,我很担心在操作过程中发生冲突。
大部分非专属希腊字母可以直接按#不可用符号的处理一节处理,此处不展开。
天文学名称、生物化学名词可以直接改希腊字母(如上面提到的“天棓三β”可以改为“天棓三Beta”或“天棓三贝塔”,后者目前在站内应无使用例,不过可以参照前者)。
唯一难办的就是“μ's”——是按#不可用符号的处理拉丁化为“Muse”,还是有什么其他的解决方案?#官方名称优先原则在此处不符合#符号和不常用文字的处理之要求——通过命名原则选出的名称可能含有各种符号和不常用文字,经过处理后方可作为条目名(此处不考虑消歧义问题)。
( ¡ )题外话 考虑到目前希腊字母中近一半的内容均与LoveLive!系列相关,我希望相关专题主要负责人@胡祥又能够在此发表一下意见。--Qaolp0 うさぎみずき (讨论) 2022年8月9日 (二) 23:11 (CST)
如果用Muse的话会不会与Muse dash混淆,这样要么消歧要么改成喵斯快跑。这么看来如果硬要弄的话不仅是要修改的条目还有修改后重名的情况,总感觉是出力不讨好的事QwQ,如果矛盾只是输入和整理方面的,可不可以考虑下改善希腊字母的输入体验,比如说列一个比较方便的教程之类,整理或许找一个针对希腊字母特殊优化的字体便于显示?一个屑派蒙讨论) 2022年8月19日 (五) 16:51 (CST)
為了不讓整個提案因此無法通過,可以暫行擱置爭議,措辭如「希臘字母按個例判斷,若有需要可經社群討論」之類,亦可考慮不溯及既往。—— Eric Liu 創造は生命(留言留名 2022年8月12日 (五) 02:49 (CST)

希腊字母限定为现实科学中使用的符号(具体表述见#可用与不可用符号),其他的不好定义容易滥用所以不再增加。在#关于可用与不可用符号的例外中有一个草稿可以看看,虽然不是专门给希腊字母准备的,能够涵盖μ's。 あめろ 讨论 2022年8月26日 (五) 17:35 (CST)

关于各种横杠

上面各种横杠都可能被用作标题中的连接号或副标题标识;上面举例没有列出各红链。全站都没有出现的符号都没有列出。因为提案中允许的横杠有U+002D和U+2014两种,希望可以指定统一的改写规则并写到#统一格式中。 葫芦又 2022年8月8日 (一) 14:56 (CST)

刀神-不知火这个是命名错误,现在已经更正为刀神-不知火--夜醉听涛讨论) 2022年8月9日 (二) 22:26 (CST)
我对这些符号的处理没有迷茫,但我不知道如何编写。
  • hyphen、minus sign、small hyphen-minus都应换用hyphen-minus。
  • horizontal bar应换用em dash,fullwidth hyphen-minus看上去都是副标题在使用,那也用em dash吧。
  • 中文中,短横线连接号使用hyphen-minus,一字线连接号使用em dash(我觉得维基百科选的不好,我同《中文排版需求》一样认为是em dash),破折号使用两个em dash。但是若语义上应该用一字线,官方却偷懒使用了短横线时,那就跟着用。
(阴暗地爬行) あめろ 讨论 2022年8月11日 (四) 03:37 (CST)
我加了几笔,剩下的“灵活处理”吧,如-HEROIC ADVENT-。 あめろ 讨论 2022年8月19日 (五) 02:25 (CST)

关于各种符号

希望可以明确一下该如何改写。 葫芦又 2022年8月8日 (一) 14:56 (CST)

因为作者使用的符号想一出是一出,若试图在条目命名指引里明确各种符号该如何改写,那么指引会变成Help:符号使用指南那样又臭又长。不仅如此,对于一个具体符号的改写方法仍可能有覆盖不到的情况,具体改写方式也不一定能达成共识。如果对有的符号有一定经验,其实可以写在帮助里,虽然提案将其标为失效文档,但有需要的话可以重写。
但是,有些符号可能需要作为特例保留——如何判定特例是一个难题,我还是没想出来,但愿最后能够不草草了事吧。你有思路吗?——哪怕是一点点思绪。 あめろ 讨论 2022年8月22日 (一) 04:17 (CST)
这里的“明确如何改写”不一定要写到指引里。可以先考虑仅针对这几个例子明确如何改写,写到#提案通过后的操作中(或者不写,只在讨论区里说明)。今后遇到相同的符号可以有个参考,这就足够了。之所以拿出这几个符号,是因为这几个在现状里是“标题中保留符号”更常见,可能存在提案与现状不一致的情况,但提案里没有提及它们。把它们拿出来是为了提醒提案人不要漏考虑这些情况。如果提案人已经考虑过了并且确定了这些符号不能保留,因为这和现状是不同的,所以最好要同时确定要怎样处理它们。 葫芦又 2022年8月22日 (一) 16:02 (CST)
我刚在#更名加了部分条目的处理方法。 あめろ 讨论 2022年8月26日 (五) 17:35 (CST)

∀(U+2200,含义:对于全部/For All):有1个将关条目:∀高达(当前条目名为“逆A高达”),按现在的提案内容,均应改用“For All”或“All”--信偶活如信混沌四神的喵某讨论) 2022年8月19日 (五) 08:10 (CST)。
PS:英文名还真是写“Turn A”,大E了--信偶活如信混沌四神的喵某讨论) 2022年8月19日 (五) 08:13 (CST)

从来没有规定过“∀”应该换成啥。 あめろ 讨论 2022年8月19日 (五) 14:40 (CST)

关于各种汉字和非汉字

希望可以明确一下应该如何判断这些字符是否属于汉字,以及如果不允许使用的话应如何改写。 葫芦又 2022年8月8日 (一) 14:56 (CST)

(~)补充 ,〆(U+3006)另有一个字符乄(U+4E44)是位于Unicode的汉字区的,可能需要统一规定标题中应该使用哪一个。 葫芦又 2022年8月8日 (一) 17:53 (CST)
(~)补充 :两个是汉字,但很少有人把它们用作汉字的字符:
葫芦又 2022年8月8日 (一) 18:08 (CST)
先回复一下“卍”“卐”“”“丨”“丶”,我的想法是按照字符判断而不是看用途判断,这样可以降低难度,就像我在#可用与不可用符号的对中文标点符号的这次更改中所明确的一样。用途的话,如果经过#命名原则选出来的名称就是这样,那么使用也无妨。 あめろ 讨论 2022年8月9日 (二) 01:00 (CST)
希望:
横线全部使用-/—
█为有意义标题一部分,但或许■更妥当
摄氏度/角度可汉化
々 〆 江 翻译或转写为中文
〇 保留并建立带“零”重定向
卍 丶 丨 以上文希腊字母中火法的建议,作为标题中有发音一部分则留,否则换空格
——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月9日 (二) 15:30 (CST)
汉字就定义为“中日韩统一表意文字(CJK Unified Ideographs)及扩展A—G,以及‘〇’”吧。如何改写……不可用的符号很多,一个个交代的话指引会变得非常臃肿,且交代不完,为此我设置了#不可用符号的处理说明通常的做法。难以改写而不好去掉的,我正考虑改进#可用与不可用符号的例外规则,以使其能够保留。 あめろ 讨论 2022年8月10日 (三) 01:12 (CST)
  1. Unicode计划在9月13日推出Unicode 15.0,其中包括含有4,192个新汉字的扩展H区扩展H区草稿
  2. Unicode标准中有一个叫“中日韩兼容表意文字(CJK Compatibility Ideographs)”的区域,其中放置了例如“凉(U+F979)”(→“凉(U+51C9)”)这样的韩文多音字,用于和KS X 1001等其他标准兼容(也就是说,KS X 1001中多音字“凉(U+51C9)”和“凉(U+F979)”是两个不同的字,其中“凉(U+51C9)”被Unicode放在了中日韩统一区,那么“凉(U+F979)”仅在韩文中出现就放在了兼容区)。但其中“IBM 32兼容文字”部分有12个在统一区内没有对应的文字,它们是“﨎﨏﨑﨓﨔﨟﨡﨣﨤﨧﨨﨩”。其中“﨑”被列在了Help:在条目名中可用与不可用的日本汉字一览#在汉语内存在,且意义也无差别的汉字(现今汉语的异体字)中,属于“在条目名内不保留原字”的异体字,应改用“崎”。如果允许使用的汉字不包括中日韩兼容表意文字的话,就意味着兼容表意文字应改用对应在统一表意文字中的汉字(例如“凉(U+F979)”改用“凉(U+51C9)”),那么就需要考虑这11个没有对应的汉字要如何处理。不过现在萌百中只在我对普通的oo没有兴趣中出现了“﨤”,其他都没出现。
  3. “々”被排除,但不常用的“𠚤(U+206A4)”却在允许范围内。这就类似“|(U+007C)”因标题限制不能使用,但汉字“丨”却可以。也就是说,如果编辑者想要在标题中保留符号而将不可用符号按照“换用形状相近的字符”来处理,反而会用上更不常用的符号。
葫芦又 2022年8月10日 (三) 12:26 (CST)
(…)吐槽 :MediaWiki似乎会自动把“凉(U+F979)”转换成“凉(U+51C9)”。就像自动把希腊文问号“;(U+037E)”转换成半角分号“;”那样。用&# ;转义可以防止自动转换。 葫芦又 2022年8月10日 (三) 14:49 (CST)
等价字符自动转换的事,在标题中也是同样的,见Help:标题限制#等价。 あめろ 讨论 2022年8月10日 (三) 16:55 (CST)
1.、2. 将定义改为 “此处的汉字为Unicode中具有Unified_Ideograph字符属性的字符,以及“〇”(U+3007 ideographic number zero)。它们基本位于中日韩统一表意文字(CJK Unified Ideographs)及扩展区(Extension)。若不确定,可于Unicode Utilities: Character Properties查看字符的属性,确认Unified_Ideograph的值。”
3. 把“换用意义或形状相近的字符”改成“换用意义相近的字符”可以吗?
—— あめろ 讨论 2022年8月10日 (三) 16:55 (CST)
如果不嫌复杂的话,这个定义确实符合对(Unicode标准里可以用的)“汉字”的认知,只要没人觉得部首和笔画“⺀(U+2E80)”“㇡(U+31E1)”之类的属于汉字就行。
我认为“换用字符”不应该根据字符的形状是否相近来判断,毕竟有太多符号和文字形状相近但意义完全不同。但如果直接把“换用形状相近的字符”删去的话,就可能需要多明确很多其他的事情。例如,可能需要对一些符号如何改写做规定,例如上面提及的形状相近但意义不同的横杠,“々”和“𠚤”、“〆”和“乄”和“㐅”是否可以认为意义相近,く形跳跃里用的假名“く(U+304F)”是改成汉字“𡿨(U+21FE8)”还是符号“〈”,以及带附加符号的拉丁字母(例如“é”)等。我认为“Walküre”和“Walkure”很难说是“意义相近”,就类似汉语拼音中的“ü”不能直接用“u”代替一样。 葫芦又 2022年8月11日 (四) 01:46 (CST)
不同语言对于相同字符的拉丁化方案都不一样,比如“ü”放汉语里推荐是“yu”,放德语里是“ue”,瑞典语把这东西叫做德语的“y”,按基本的去除所有附加符号应该是“u”……所以我觉得这东西甚至可能得给出一个严格的方案之类的((——bob1301讨论) 2022年8月11日 (四) 20:14 (CST)
大逆不道地说句:这种做法下最好的情况应该是能汉化时汉化,否则原文做条目名,拉丁文转写做重定向吧。——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月11日 (四) 20:55 (CST)
越严格,越难覆盖特殊情况,编辑者负担越大。 あめろ 讨论 2022年8月11日 (四) 22:49 (CST)
调整。 あめろ 讨论 2022年8月11日 (四) 22:49 (CST)
我突然想到啊,如果只是因为“々”和“𠚤”形状相似就删掉“换用形状相近的字符”,可能并不是这样调整的本意。做出这次调整本来的目的其实是:避免把符号改成使用汉字。例如“|”→“丨”、“々”→“𠚤”、“〆”→“乄”都属于把符号改成汉字。
把“换用形状相近的字符”删掉其实并没有封堵住上述的“〆”→“乄”,因为这两个字符的“意义或作用”是一样的。再举个更离谱的例子:众所周知日文中“ドル”按字符形状取自英语“$dollar”;而其他计量单位也有类似的现象,例如和制汉字“𬼁ドラム”(字形如“ℨ”,“勹”的撇和“乃”的横折折折钩合一起)在1880年左右被日本医药界广泛使用,它取自ʒdram”(药剂学质量单位“打兰”),这意味着如果标题需要使用“ʒ”,则完全可以以这两个字符“意义或作用相近”为由换用“𬼁”。
上面这个例子,本质上和下面这几个多发生在专有名词上的“形译”没有区别,都是直接搬运外文文字的形状,而且还造出了本语言本来不存在或不常使用的字:日文的“栃木”中文翻译成“栃木”、“飛騨”翻译成“飞𱅛”(“𱅛”字形如“马单”),越南文的“北𣴓Bắc Kạn”(“𣴓”字形如“氵件”)翻译成“北𣴓”,韩文的“李世乭이세돌”翻译成“李世乭”、“唜島말도”翻译成“唜岛”,方块壮字的“ndoeng”翻译成“岽”、“mboq”翻译成“呇”。没有造出新字的比如英文的“T-junction”翻译成“丁字路口”、“WoW”翻译成“山口山”。这几个的来源词和翻译的结果都是允许在标题中使用的字符,所以没事儿;但如果形译的来源词里包含不允许在标题中使用的字符,就会出现上面“ʒ”→“𬼁”这样的情况。也就是说,这种情况其实是“把符号改成汉字”造成的,而不是“换用形状相近的字符”造成的。
那么能不能因此就完全禁止“符号改成汉字”呢?也不行,因为就像#不可用符号的处理例子里的“Ⓐ”→A一样,还有很多字符本身不是纯文字但字符形状中包含文字(此处指汉字、A–Z、a–z、0–9)的情况。包含汉字的情况及举例如下:康熙部首“⼥”→“女”、笔画“㇠”→乙、苏州码子“〺”→“卅”、日本汉文注释“㆝”→“天”、画正字“𝍶”(字形如“正”)→“正”、电报符号“㋇”→“8月”、合字“㍿”→“株式会社”、“㋿”→“令和”、方框“🈶”→“有”、圆框“🉑”→“可”、括号“㈱”→“(株)”、“🉅”→“〔打〕”。
综上来看,可以先把原来的“换用形状相近的字符”表述加回去,但要限定只能改用“可用符号”;后半句(或者单独拆出一条)则说:如果字符“本身不是常用文字但字符形状仅由可用符号和常用文字构成或仅由常用文字外加方框、圆框或括号等构成”(或者看看怎么表述限定到上面列出的这几类),则“改成对应的符号及汉字”。这里需要考虑三个问题:
  1. 除了#统一格式#通用规范已经列出的和“符号改成常用文字”之外,是否还有其他“形状相近”或“意义或作用相近”但不能用于替代的字符。
  2. 除了“字符本身不是纯文字但字符形状中包含文字”之外,是否还有其他需要以“形状相近”或“意义或作用相近”为根据来把符号替换成汉字的情况。
  3. 构成上不仅有文字,还有图案或不可用符号的字符,例如“¥”→“Y”还是“元”“日元”(120元之春 ¥120 Stories)、“½”→“1/2”“二分之一”“2分之1”“一半”(½如梦)、“№”→“No”“No.”“Number”(No.78 №系档案馆)、“℃”→“C”“度”“摄氏度”(热爱105℃的你)、“©”→“C”“(C)”“Copyright”“版权”、“♳”→“1”“1号塑料”“聚对苯二甲酸乙二醇酯”“PET”等,要如何处理,如何和下一条的“用文字描述”协调搭配;或者也可以考虑如何措辞以避免对这些符号做出如何改用的强制规定。
葫芦又 2022年8月21日 (日) 08:17 (CST)
首先我要讲的是,#不可用符号的处理所列举的几个方法不是强制规定,而是提供一个参考。

若条目名是未经翻译的暂定标题(大部分“〆”肯定出现在暂定标题),则不需要担心“〆”被写成“乄”,有“若标题未经翻译而暂定,则可在不被系统阻止时,保留名称中原有的文字和符号”,它得以保留。

若条目名并非未经翻译,你担心的问题是“〆”、“ʒ”等字符有被换成汉字的可能性。若要避免它们被换成汉字,由于符号本身和使用场景千奇百怪,没有万金油能规定某些符号“应当”换成汉字之外的什么具体字符,所以只能”限制“它们换成啥。不知我这样分析是否正确。

在讨论如何限制前,需要明确两个问题:

  1. 这种字符是否确实有可能被换成汉字?“|”有可能;“々”和“〆”基本在日文出现,那么或翻译或暂定标题,均不会出现你所担心的情况;“ʒ”,你自己都说了“离谱”吧。
  2. 是否有必要限制?“有可能被换成汉字”是限制将它们换成汉字的必要条件,在我看来还有一个必要条件是“不使用指引的约束力就无法轻易解决问题”。通过常识你我都能判断这样命名不好我认为其他编辑者也知道这样命名不好,或者说不会执着于用一个生僻的汉字,我认为这样的限制不是未雨绸缪,而是杞人忧天。

—— あめろ 讨论 2022年8月22日 (一) 05:04 (CST),修改于2022年8月22日 (一) 05:17 (CST)

关于这两个字符:
“々”在中文中当然也会出现,例如中文里也可以写“谢々”,只是说“规范一点的写法”里第二个字也应该写出来“谢谢”。现在出现在标题中只有一个夏々,我觉得可能只是标题替换没加{{lj}}。问题在于我们并不知道未来会不会有人在中文内容的标题里也使用这个符号:日文“”翻译成中文全都改掉,那如果原文就是中文“谢々”,那这个符号还改不改。就类似“「」”也单独规定了“原文为简体中文”的情况。
“〆”在上面举了例子:拉链〆藏〆野润子都是翻译之后的译名。拉链〆藏的日文原文是“チャックシメゾウ”,翻译把“シメ”翻译成“〆”,是因为“”这个汉字出现在角色形象的服装上,推测“シメゾウ”的汉字写法是“〆蔵”,这才有了“〆藏”这个译名。〆野润子的日文原文是“〆野潤子”,常用译名中也是直接保留了汉字原字。这两个例子的出现都是因为如果不保留这个字就不知道还能怎么翻译了。另外,“〆”→“乄”不影响该符号正确表意和指代,不能根据例外保留“〆”。
上面两个字符都是会在正式标题中出现的,并不是暂定标题(只是现在还没有建好的条目当例子)。用“ʒ”→“𬼁”举例只是为了用相似但极其离谱的例子来说明提案条文的问题点在哪里,我也相信不会有人这么做。
关于是否有必要“限制符号改成汉字”的问题:如果能通过其他方式允许使用上面这些两个字符(及其他相似的情况)且限制其被替换,以及能处理好“|”→“丨”这样“(形状上的)作用相近的字符”被替换(而且原符号还不能用)的情况的话,确实没有必要对“限制全部符号改成汉字”做统一规定。处理“这三个字符(及其他相似的情况)不能改成汉字”需要考虑的要比“全部字符里面找哪些字符可以改成汉字”要少多了;是我之前因为认为这边可能行不通就向着那一边想过去了,结果就向着复杂的方向想过头了(但确实想出了结果)。
葫芦又 2022年8月23日 (二) 03:10 (CST)
“|”与“丨”这样的情况我放弃不管了,对其规定难度高,且这种情况出现概率小。
“々”换为前一个字,就算原文是中文不例外,但不必写到指引里了;
“〆”在中文中就用“乄”吧,没准能写到Help:在条目名中可用与不可用的日本汉字一览中。我见到Bangumi上“〆野潤子”被译作“乄野润子”,嗯,不错。 あめろ 讨论 2022年8月27日 (六) 22:32 (CST)
看了这么乱的内容,我有句暴论:干脆单独出一个提案来规划特殊汉字在标题的判断,然后单独拉个页面做个关于汉字命名的指引--有点怂的playymcmc007签名请用--~~~~哦讨论爆破) 2022年8月11日 (四) 21:38 (CST)
不需要,用常识即可。原本避免特殊符号原则只有几句话也没见几个人对汉字有争论。 あめろ 讨论 2022年8月11日 (四) 22:49 (CST)

别忘了“まず”()--信偶活如信混沌四神的喵某讨论) 2022年8月19日 (五) 07:58 (CST)

这东西叫ます。——bob1301讨论) 2022年8月19日 (五) 13:20 (CST)
(表示ます)有固定的读音,但没有固定的含义,并不符合日语中对汉字的特征描述,一般不认为是汉字,而是符号。就类似“cm”表示厘米、“ㄏㄏ”代替“哈哈”。
此外,(表示より)、𪜈(字形如“丨モ”,表示トモ)是连写两个假名的产物,仍然属于假名。
(横折,字形如“𠃍”“ㄱ”“⏋”,表示コト,来自)、𬼀(一点一撇,字形如“У”,表示シテ,来自)、𬼂(一竖一弯,字形如“𝒧”,表示なり,来自)、𬻿(一点一平捺,字形如“∸”,表示ナリ,来自)等,它们均来源于汉字,用法都是用一个字符代替两个假名,所以一般认为它们也属于假名。上面两种合称“合略假名”。
但其中的𪜈𬼀𬼂𬻿被Unicode标准放在了中日韩表意文字区,其Unified Ideograph均为Yes。如果按照上文给出的汉字的定义,这些都会被认定属于汉字。
把“キモい”写成“托い”的,应属于特殊借字(当て字),原字“”仍然是汉字。
还有一个:,是汉字“”的简写,和汉字“”同源同义。它在含义上和读音上都具有汉字的特征,完全可以认为是汉字的异体字。虽然一般都认为它是假名的小写。
葫芦又 2022年8月19日 (五) 18:26 (CST)
上面这些,尤其是𪜈等4个字符,出现了“和一般认知的汉字范围不同”的情况。现在仅在权御天下日语两个条目内容中出现了“𪜈”“𬼀”,都是作为假名使用的。现在提案中和上面的讨论都说“按照字符判断而不是看用途判断”,那么这些字符就都可以用在条目名中。但假如有人写了首歌取名《恋𬼀愛𬻿》,假如翻译这歌名的第一个人摆烂直接翻译成“恋_爱_”之后这个译名就流传开了,那么这个标题还要不要保留这两个字符? 葫芦又 2022年8月20日 (六) 03:34 (CST)
处理符号之前名称是通过#命名原则得到的(写在序言里的,如果不明显的话我强调下)。命名原则中我们有常用称呼优先原则简体中文优先原则,“恋_爱_”符合这两个原则,所以就用“恋_爱_”而不用“恋𬼀愛𬻿”。有趣的是,官方名称优先原则的内容是“译名取官方译名”,所以原名“恋𬼀愛𬻿”不符合此原则。
这种“和一般认知的汉字范围不同”的字符,通常不会被看作简体中文,不好打所以通常不会常用。 あめろ 讨论 2022年8月20日 (六) 22:25 (CST)
也就是说,如果根据#命名原则选出来的名称包含各种奇怪的汉字,只要它们的Unified Ideograph是Yes,就允许使用,而完全忽略它们是不是生僻字、有多奇怪、在传统观念上是不是汉字、是否方便输入等。之所以这样处理,是因为可以认为先进行的#命名原则这一步里已经有足够的力量去筛掉这些奇怪的字了,而如果哪个生僻字没被筛掉,那就说明用在页面标题里也没问题。
至于Unicode中的汉字可以有多奇怪,可以看看Unihan数据库参数“怪字”《汉字志异》葫芦又 2022年8月21日 (日) 04:35 (CST)

关于优先原则位置调整的一点建议

鄙人认为,应当将命名规范等一系列放在前面,使得编者了解哪些命名是合法的。

在编者对于已有规范有复数可选择名字的时候才考虑优先原则。

同时建议给一张优先顺序表,方便编者按照顺序考量。 —— 不出理律觉得世界是如此美丽(用这里找我) 2022年8月9日 (二) 12:21 (CST)

您的章节标题使用出错,我进行了排版错误纠正。—— 屠麟傲血讨论) 2022年8月9日 (二) 12:23 (CST)
整个页面就是命名规范,我不懂什么叫放在前面。
优先顺序我整不出来,也不是这次提案该做的。 あめろ 讨论 2022年8月9日 (二) 15:15 (CST)

关于消歧义

  1. 序言一节中,“本指引规范条目(namespace=0,不含消歧义页面和重定向页面)”,我想知道为何排除消歧义页。消歧义页属于条目,也应遵守此规范,而重定向本不属于条目。
  2. 简体中文优先原则一节中,建议将“特别注意不要繁简混合命名,比如简体的消歧义后缀+繁体人物名”修改为“特别注意不要多语言混合命名,例如中文或英文的歌曲名+日文消歧义后缀”或其他合适的话。
  3. 修改萌娘百科:消歧义一节中,建议将“而不用管道符改变显示文字”修改为“而不用管道符隐去消歧义前后缀”。

—— ほしみ 2022年8月9日 (二) 22:43 (CST)

  1. 排除消歧义页的理由有两点:
    1. 消歧义页的命名已有方针级的政策指明,消歧义方针#消歧义页面名称说明“消歧义页为歧义词本身”;
    2. 消歧义页的命名无法参考该文档:
      • 命名原则方面,消歧义页涉及的是多个对象,而当前的命名原则均是为单个对象准备的。
        • 官方名称优先原则、常用称呼优先原则:多数情况下,歧义词本身没有官方名称和常用称呼,歧义项才可能有;
        • 使用全称:如果是缩写产生了歧义,消歧义页没法使用全称;
        • 重名处理原则也不是为消歧义页命名准备的。
      • 符号方面,有,它们不符合条目命名符号的处理。
  2. 有点想改,但我已经看见几个因改了原本预期的范围外的内容而不通过的投票了,不敢改咋办呀?
  3. 好的。
—— あめろ 讨论 2022年8月9日 (二) 23:36 (CST)
不敢改就不改。 あめろ 讨论 2022年8月11日 (四) 03:13 (CST)

希望先行通过没有争议的部分

相信大多数用户都乐见条目名可用符号的扩展,而且提案大部分也没有争议。除了文本表述方面的意见,目前争议比较大的部分包括:

  1. 形状近似符号的统一使用问题,包括高级火法提到的英文弯引号、波浪线,胡祥又提到的各种横线等
  2. 希腊字母
  3. 其他既存条目使用的特殊符号,包括胡祥又提到的各种符号、汉字与非汉字等

我认同Legend_frog“衷心希望不会因为一两个反对点而整个提案反对”的意见。希望可以将无争议的部分先行通过,其余部分可以在之后修正。

毕竟要一次就改到符合大多数人想法的状况很难,而全部讨论完不知是什么时候了,至少先让全角括号什么的能用吧。--Cesko讨论) 2022年8月10日 (三) 20:55 (CST)

规则已经比之前明确了,我担忧的是规则变明确使得难以睁一只眼闭一只眼,导致一些合理的标题会因先行通过的不完善的政策遭殃。 あめろ 讨论 2022年8月12日 (五) 04:31 (CST)

对于部分技术限制符号的全角符号

“出于技术限制,标题包含‘# < > | { }’之一或某些特定组合的字符的条目无法被创建”,在上次的提案中,曾经提到“不得已时可使用全角形式“#<>|{}”代替”,而后来被以“在标题中、重定向中几乎没有使用,且多数情况仍然需要替换标题、替换链接文字,并未减小复杂性”而移除。但当前没有使用不代表没有使用的需求、未来没有使用的可能,我个人认为若可以的话还是建议考虑一下对采用全角代替开绿灯。(虽然我知道你们的意见大概率还是不行,不过还是提出来一下,因为“利益相关”×)——4O74Y74L74J7讨论) 2022年8月11日 (四) 19:08 (CST)

我也是“利益相关”了,开放越多的符号,提案不通过的概率越大。 あめろ 讨论 2022年8月22日 (一) 05:20 (CST)
理解。——4O74Y74L74J7讨论) 2022年8月22日 (一) 10:37 (CST)

关于可用与不可用符号的例外

例外一节所述:「对于一个条目,若包含不可用符号的名称比不含该符号的更加常用,并且不含该符号无法正确表意和指代时,则可在创建/移动时的摘要,或在讨论页给出合理证据后,以包含该符号的名称作为条目名」。

而由于「符号包含不常用文字」,这句话可能可以被无限放大解释。请问这是否是提案本意?若否,可能需要加以限制。—— ほしみ 2022年8月19日 (五) 15:16 (CST)

没看懂 >﹏<,有没有例子? あめろ 讨论 2022年8月19日 (五) 20:56 (CST)
正是因为想不到例子,并且这句话可以扩大解释,我才觉得这句话有问题。或者说,为什么要留下这句话?—— ほしみ 2022年8月19日 (五) 21:01 (CST)
这句话是为了类似“你不叫用希腊字母,大家还想要μ's”的情况。如果没有这句话,希腊字母相关规定也不改,那μ's怎么办?事实上我还想继续扩大,因为我觉得目前的太严格了,很难满足这一条。 あめろ 讨论 2022年8月20日 (六) 01:10 (CST)
有这句话在可以无限使用任何字符,我认为不应该给希腊字母明文有此规定。并且这可以导致长期的扯皮,前段时间挪到这儿,过段时间挪到那儿。—— ほしみ 2022年8月20日 (六) 01:11 (CST)
这个规定不是专门给希腊字母准备的,而是弹性原则,有必要有弹性原则。“无限”“任何”有些牵强吧。我改了一版写在这个讨论串的后面,你们指教指教。 あめろ 讨论 2022年8月25日 (四) 05:26 (CST)
举个例子:哲♂学。在表示这个含义时肯定是包含这个♂的写法更常用,如果少了♂的话就会和普通的哲学混淆而无法正确指代。只要把前面这句话写到编辑摘要里,就可以使用这个符号作为条目名了。 葫芦又 2022年8月20日 (六) 01:50 (CST)
再举个“不常用文字”的例子:。这歌标题没法翻译,所以直接使用原名会更常用;如果转写成“me”就更混乱了,无法正确表意和指代。只要把前面这句话写到编辑摘要里,就可以使用这个不常用文字作为条目名了。顺便说,我没仔细了解这首歌,但从歌词的感觉来看,这个“”可能是取自“”,加在人称后表示这是对他的詈词,比如“███め”=█████;如果是这样的话,这标题真的没法直接翻译。 葫芦又 2022年8月20日 (六) 02:24 (CST)
修改后:❝
如果待处理的条目名中本不可用的文字满足以下全部要求:
  • 在所属文种中不构成单词与构成的单词含义无关;
  • 不是装饰,也不是用其形状构成其他文种的单词(用形状的如Next New Wφrld,用“φ”代替“o”构成“World”);
  • 在不刻意避免歧义的情况下,以合适的方式处理该文字后,条目名会与收录范围内的内容产生歧义,而保留该文字则无歧义。
则予以保留。若有条目符合此要求,那么该条目描述的对象出现在其他条目名中时也可以保留这样的文字。
❞ 求建议、意见。三个要求中的最后一个要求估计还有问题😨。 あめろ 讨论 2022年8月25日 (四) 05:26 (CST)
也可能没有问题。首先限制了”文字“,这是讨论”可否直接翻译“的前提;第一条表示它没法直接翻译;第二条排除花里胡哨的使用;第三条虽然怕,但我倒是想不出漏洞。 あめろ 讨论 2022年8月26日 (五) 17:35 (CST)
“收录范围内的内容”改成了“其他存在的条目”,因为前者太不确定了。 あめろ 讨论 2022年8月27日 (六) 17:49 (CST)
这叙述有点难懂--Cesko讨论) 2022年8月27日 (六) 21:56 (CST)
我不想这样,但为了避免“无限放大解释”只能增加限定。 あめろ 讨论 2022年8月27日 (六) 22:32 (CST)
总之大部分情况用不到,只有极少数符合。 あめろ 讨论 2022年8月27日 (六) 22:43 (CST)
举几个例子吧,让大伙看看措辞如何优化一下--Cesko讨论) 2022年8月28日 (日) 02:22 (CST)
μ'sélf符合当前的表述。其实就用“め”命名也合适,但满足不了当前的规定(Me与已有条目没有歧义)。「1」用这个命名也行,但也满足不了当前的规定(“「」”不属于文字)。 あめろ 讨论 2022年8月28日 (日) 04:40 (CST)

重新看了一遍,虽然不知道为什么要将“不常用文字”归到“符号”里,但这让“符号”这一用词有了两层含义:“符号”本身,与“符号和不常用文字”的合称。这容易引起混淆,也是星海说“可能可以被无限放大解释”的理由。“为方便起见”反而使得描述更加不便了。因此,我觉得可以将“符号和不常用文字”统称为“特殊字符”,也便于将文字和符号分开处理。

另外,“不可用符号”在一定情况下又可以使用,这个名称不恰当,可改为“避免使用的字符”(包含“避免使用的文字”“避免使用的符号”)。

具体到“不可用符号的处理”,则改为如下表述(包含其他措辞上的修改):

修改后的表述
避免使用的字符的处理

未被#统一格式#通用规范提及的避免使用的字符可灵活处理,例如:

文字

符号

上面只是举例,并不局限于以上方法,对特定条目可以有其他更合适的处理方法。

若仅处理一部分字符会造成违和,可将其他部分一并处理。

避免使用的文字的例外情况

部分条目的常用名称包含避免使用的文字,若更名将引起混乱和不便(例如μ'sélf等),故无法避免使用。因此,若待处理的条目名中包含的避免使用的文字满足以下全部条件,则可以保留:

  1. 在所属的语言中没有明确含义,或在条目名称中的含义与原本的含义无关;
  2. 不是装饰,也不是用其形状构成其他语言的词语(用形状的如Next New Wφrld,用“φ”代替“o”构成“World”);
  3. 以合适的方式处理那些文字后,条目名会与其他存在的条目产生歧义,或与官方名称、常用称呼差异过大。而保留那些文字则无歧义,且是官方名称或常用称呼。

若有条目的名称因满足以上条件而保留避免使用的文字,那么在其他条目名中提及该条目描述的对象时,也可以保留那些文字。

以上只是措辞上的修改,至于「1」又如何处理,就是另外的话题了,其他部分也想修改,可惜编辑框太小写不下了。

( ¡ )题外话 这些条目处理完条目名,又要建立包含特殊字符的重定向,还要标题替换,真是脱了裤子放屁。 --Cesko讨论) 2022年8月29日 (一) 01:03 (CST)

( ¡ )题外话 (+)强烈支持“这些条目处理完条目名,又要建立包含特殊字符的重定向,还要标题替换,真是脱了裤子放屁。”说的太对了!我也是这样想的。不过事与愿违,或因我太胆怯,才成了这样扭曲的结果。
用“符号”称“符号和不常用文字”,多少受到“避免特殊符号原则”的影响,并且文字本身也是一种符号(zhwp:文字),我才这样统称的。嗯,改一下“符号和不常用文字”的统称。
文字和符号的界限没有那么大。颜文字里面一堆文字都是在当符号用。所以我觉得“避免使用的字符的处理”里面文字和符号的处理没必要分开。
剩下的也有参考价值。 あめろ 讨论 2022年8月29日 (一) 20:04 (CST)
不论如何,这份提案已经比现有政策范围宽了很多,至于措辞问题,比起范围来说倒也不那么重要了。要一次就达到理想状态也是不太可能的,希望能按时发起投票吧,毕竟搞一次提案也确实是伤精费神。--Cesko讨论) 2022年8月29日 (一) 21:40 (CST)
这次不会被机器人骗了。 あめろ 讨论 2022年8月29日 (一) 22:20 (CST)

关于“&”字符是否可以用以及如何使用?

可以,属于ASCII标点及符号。该用的时候用。 あめろ 讨论 2022年8月27日 (六) 23:42 (CST)

关于通用规范中对于中文条目名中的标点的规定

如题,#通用规范中规定:

“直角引号‘「 」’和‘『 』’(有时也用作书名号),仅当原文为简体中文时,与原文一致。其它情况下,直角引号应转为弯引号或书名号。”

总感觉哪里怪怪的,在网友的帮助下我发现了这两个例子:

  • 其一,使用直角引号的不一定为书籍一类,例如「1」,这里是作为歌曲名称使用。在不影响搜索的基础上我认为遵从原名使用直角引号更美观。且对于歌曲的搜索场景更多应该是复制粘贴标题,在简体中文中使用直角引号的情况也愈发常见,去特意转换符号搜索的情况我认为是相对较少的。在两者皆不影响搜索的情况下,未必需要强求转换。
  • 其二,例如如果高中棒球队女子经理读了彼得·德鲁克,这里的正式译名直接舍弃了直角引号,这种情况应该以正式译名为准,在通用规范这条规定里是否应该特别强调一下,相关联的还有#可用与不可用符号

再者就是,这里的“仅当原文为简体中文时”,指的是标题原文?若是,改成“仅当原作语言为简体中文时,与原作标题一致”是否更明确?——この不審者小鞠こまりです 2022年8月28日 (日) 01:51 (CST)

我也觉得直角引号合适。别说歌曲了,各种作品标题都很多复制粘贴,要是可以不限制符号就好了,我不完全明白萌百的条目命名怎么畸形成这样子。你觉得这条规定怎样改合适?我甚至不反对完全允许直角引号,毕竟还有简体中文优先原则。
强调一下也行吧。就是又要变长了。
如果条目不是作品或作品中的内容呢?比如现实活动,或是一个作者的奇葩名字,那就用不成“原作”了。 あめろ 讨论 2022年8月28日 (日) 04:40 (CST)
想了一下改成这样子的?
直角引号‘「 」’和‘『 』’(有时也用作书名号),优先采用官方名称优先原则或常用称呼优先原则。其它情况下,直角引号应转为弯引号或书名号。
好难找到更多的例子啊……然后我想,还是按照在网路上常喊的来吧,就是官方名称优先原则或常用称呼优先原则。如果用的弯引号也不要强求直引号,直引号也不要再换成弯引号了。改成这样子,就不只是“仅当原文为简体中文时”了,如果作品译名或一些作者的名字里有直引号也可以不作转换。何况用哪种引号也没差,还有特地规定是不是在简中字环境下使用的太烦琐了。非必要不转换,我是这样想的。
emm……我还是感觉靠官方名称优先原则或常用称呼优先原则就能解决大部分情况,所以当初是为什么设立这条的——この不審者小鞠こまりです 2022年8月29日 (一) 20:32 (CST)
可行。
最开始就没考虑直角引号,之后上个提案中Eric Liu和星海提了才加进去,星海还说“应明确什么时候需要转写为“”,什么时候可以保留”,于是有了这条。没见人反对就沿用到这次提案了。 あめろ 讨论 2022年8月30日 (二) 03:38 (CST)

提案即将到期

本通知由人工机械体自动发出,可能存在发送时机不对、发送对象不对、重复发送等问题,如有问题请联系User_talk:AnnAngela。如果放置位置不对,请协助移动到讨论区域。

@あめろ 您好,您于【2022年8月1日晚上10点21分】发出的本提案即将到期,如不能在【2022年8月31日凌晨12点00分】前发起投票,维护人员将会按萌娘百科:提案#投票处理。——AnnAngela-abot讨论) 2022年8月29日 (一) 03:00 (CST)

(…)吐槽 麻了,又是“凌晨12点00分”--Takeuchi.BadEditor (讨论留名) 2022年8月29日 (一) 09:18 (CST)
根据方针以及上次提案的情况,本提案应当为2022年8月30日23时59分到期,而不是31日,虽然机器人不是像上次那样直接算错但现在的说法又有歧义。根据方针,“续发起逾期未投票提案的,视作反复发起不合格提案,进行处罚”,希望这次提案可以按时开启投票。——4O74Y74L74J7讨论) 2022年8月29日 (一) 10:14 (CST)
这回不会被你骗了😛。 あめろ 讨论 2022年8月29日 (一) 22:20 (CST)

错别字

#通用规范:“比如原文该部分并未英文”→“比如原文该部分并未使用英文”/“比如原文该部分并非英文”。 葫芦又 2022年8月30日 (二) 14:21 (CST)

#通用规范:“对形如‘主标题 -副标题-’的标题,副标题外的横线用‘-’”:“副标题外的横线”是指“副标题两侧的横线”还是“副标题以外的部分中出现的横线”?例如“nao complete anthology 2002-2009 -my graduation-”,是指“-my graduation-”还是“2002-2009”里的横线? 葫芦又 2022年8月30日 (二) 14:33 (CST)

谢谢! あめろ 讨论 2022年8月30日 (二) 15:11 (CST)

关于「/」

「/」是子页面符号,好像没有提应该要尽可能避免使用此符号?或者说,什么时候应该用,什么时候不应该用?—— ほしみ 2022年8月30日 (二) 22:38 (CST)

例如刚刚有人创建的“锯齿状/焰形刀剑”,/表达或的意思,我觉得这属于不当使用。—— ほしみ 2022年8月30日 (二) 22:40 (CST)

加在了#通用规范。 あめろ 讨论 2022年8月30日 (二) 23:15 (CST)

投票区

正在加载中……
本次投票あめろ[更多]讨论页贡献上传历史封禁及历史被删贡献移动日志巡查日志用户权限及日志用户查核发起。
  • 投票开始时间: |
  • 投票结束时间: |
  • 投票总用时 7 天,正在计算中……

结果#序言提到的注释,大部分到投票时仍没加。在这里解释一下思路吧。总体思路是减少不明确的部分,提高可执行性。

首先是将“避免特殊符号原则”的优先级提高。原本它是与其他原则并列的,导致若名称中有特殊符号,那么“官方名称优先原则/常用称呼优先原则”与“避免特殊符号原则”必将只能满足一方。

统一格式:看似复杂,其实有一半都在过滤器里面,把它写出来而已。

通用规范:在部分情况为官方名称/常用称呼让位;而在部分情况下规范标点符号用法,减少混乱,减小查证的需求。

不保留的字符的处理:在原指引中只有一句“原则上条目名不应出现任何符号,能避免符号则不使用符号。”,而提案总结了常见情况并罗列。

例外情况:在原指引中只有一句“必须要使用符号替代时,应使用可以方便打出的符号。”其一,“必须……时”足够模糊;其二,我微软输入法能方便打出的符号已经全在#可保留的字符里了。提案尝试明确了什么时候可以使用本应不保留的字符。

缺点也有,我利益相关可能不客观,提一嘴。太长肯定是一个缺点;没有完全跳出“避免特殊符号原则”的思维,仍在某些地方用了一刀切而不一定合适的规定。 あめろ 讨论 2022年8月30日 (二) 23:29 (CST)

@AnnAngela云霞蓝羽汇星海子玄微子弗霖凯LuoxuchanLeranjun。 あめろ 讨论 2022年8月30日 (二) 23:36 (CST)

@AkizukiSaitouBbrabbit宇文天启平塚八兵衛空翊Vcfch843875618HetmesAskalana不是液氮XzonnChko08022003Bete1geuse小乃LUO1PTsanconBYin西尾哈鲁卡WenzuxiaotSinonJZH沼泽Bob1301あめろDaigui屠麟傲血NemitsugiOtowaQaolp0胡祥又秋园世界淮南皓月高级火法Sytus一位史蒂夫Ericliu1912Jacklin612平平凡凡小小鞠正云明宏写条目的奶糖Sucaiking人间百态Mathreader磷化镓BearBin栀梦GrandomMilkBoy。 あめろ 讨论 2022年8月30日 (二) 23:39 (CST)

在讨论阶段参与了提案讨论的自动确认用户:4O74Y74L74J7,Cesko,Legend frog,@AKQC8H17OHChi_ZJ2ErwGuoPCHonoka55Playymcmc007SkySakura2005Takeuchi暴走的喵兵卫北湖3方之易小文夜醉听涛一个屑派蒙一脸天然呆不出理律。已经投票的,为了不打扰就去掉链接了。 あめろ 讨论 2022年8月31日 (三) 00:11 (CST)

管理员

同意
  1. (+)同意 一个问题是难以读懂,另一个问题是通过后可能需要一个明确的计划来执行。感谢提案发起人的努力。—— ほしみ 2022年8月30日 (二) 23:37 (CST)
    我看看这7天能不能先整理一批列表出来。 あめろ 讨论 2022年8月31日 (三) 00:23 (CST)
  2. (+)同意 基本没问题,执行到位就好。辛苦了。--单推人乐然※※※感光性受容体異常※※※ 2022年8月31日 (三) 11:45 (CST)
  3. (+)同意 唯请注意其可执行性--From KumoKasumi the Bureaucrat (Talk) 2022年9月3日 (六) 23:54 (CST)
  4. (+)同意 希望能有效执行。——From AnnAngela the Bureaucrat (Talk) 2022年9月4日 (日) 17:18 (CST)
  5. (+)同意 不论可执行性,提案里的很多东西绝对是有比没有强的。--SysOp 珞珝 [用户讨论] 2022年9月5日 (一) 02:49 (CST)
反对
弃权
  1. (∅)弃权 无法估量其影响及潜在风险,容我弃权。——From 引梦者浊华(讨论) 2022年8月31日 (三) 22:34 (CST)

巡查姬

同意
  1. (+)同意 与原指引相比,符号的使用更加合理,对原本执行上不明确的地方也进行了详细化。 あめろ 讨论 2022年8月30日 (二) 23:29 (CST)
  2. (+)同意 无条件支持。 葫芦又 2022年8月30日 (二) 23:29 (CST)
  3. (+)同意 萌百人苦符号久矣。——满足怪 BearBin康他喷他留名 2022年8月30日 (二) 23:31 (CST)
  4. (+)同意 对条目命名中符号的使用做了进一步规范  ——MilkBoy讨论贡献) 2022年8月30日 (二) 23:33 (CST)
  5. (+)同意 瑕不掩瑜,可以说这份提案为旷日持久的符号战争画上了一个圆满的句号--黑夜给了我一双眼睛,而我却拿它照亮人间(讨论) 2022年8月30日 (二) 23:35 (CST)
  6. (+)同意 无条件支持。 淮南皓月 🌙 2022年8月30日 (二) 23:37 (CST)
  7. (+)同意 原来是我把提案想的太复杂了。—— 屠麟傲血讨论) 2022年8月30日 (二) 23:41 (CST)
  8. (+)同意 希望能够前进一步。--某FFF团的高级火法 批判一番) 2022年8月30日 (二) 23:41 (CST)
  9. (+)同意 大体支持,个人认为唯一的遗憾就是因为涉及内容太多导致对新人很不友好……甚至我自己都因为此而被迫放弃后续讨论。如果可行的话可以考虑重写Help:符号使用指南,或者另开一份帮助文档。--Qaolp0 はなおし (讨论) 2022年8月30日 (二) 23:44 (CST)
  10. (+)同意 作为指引来说挺好的,目前没有发现致命问题。读者怎么操作的部分……期待帮助文档。From Sucaiking the WAFighter 2022年8月30日 (二) 23:52 (CST)
  11. (+)同意 整体上来说确实是一大进步,至少比没有好。—— 超级纯洁的小马娘秋园邀请你去地下室重马场一坐 2022年8月30日 (二) 23:53 (CST)
  12. (+)同意 嗯,同意的。怎么大家投票这么快呀——この不審者小鞠こまりです 2022年8月30日 (二) 23:54 (CST)
  13. (+)同意 引用二次刘的一句话:“我至今仍然認為本站條目標題預設採用半形標點符號——甚至(全)中文標題亦然——實屬不美觀、不合理且令人匪夷所思之選擇,並充分支持任何能夠(部分)推翻此一不當政策的提案。”——   于是我放弃了二饼已读不回) 2022年8月30日 (二) 23:57 (CST)
  14. (+)同意 没有问题——by 专注各话制作的正云明宏 2022年8月31日 (三) 01:39 (CST)
  15. (+)同意。非常感謝提案者之努力!辛苦了!—— Eric Liu 創造は生命(留言留名 2022年8月31日 (三) 02:50 (CST)
  16. (+)同意 在我关心的范围内无异议。--Mathreader讨论) 2022年8月31日 (三) 07:09 (CST)
  17. (+)同意 大体上无异议,至少解决了条目命名上一些亟待解决的问题。—— from DaiGui a.k.a. YukinasNekotalk」 2022年8月31日 (三) 08:49 (CST)
  18. (+)同意 这样不就是赢麻了(x——bob1301讨论) 2022年8月31日 (三) 09:23 (CST)
  19. (+)同意 这是好的。—— 🍭 纸飞机上的梦TalkSignature 2022年8月31日 (三) 09:34 (CST)
  20. (+)同意 有了规范且能够帮助解决当前存在的问题,这是ao的。--Nait_Talk 2022年8月31日 (三) 10:06 (CST)
  21. (+)同意 算是把以前标点符号问题提案的坑给填上了。--bbrabbitからの評論 #討論# 2022年8月31日 (三) 10:49 (CST)
  22. (+)同意 很多条目命名用半角符号太难看了。—— From GaP a NaïvePatroller 2022年8月31日 (三) 15:30 (CST)
  23. (+)同意 可。— SytusTalk 2022年8月31日 (三) 18:03 (CST)
  24. (+)同意 好-- 小乃讨论) 2022年8月31日 (三) 21:17 (CST)
  25. (+)同意 规范化,好—— 冬月下的二重奏 LUO1P 2022年8月31日 (三) 22:47 (CST)
  26. (+)同意 说实话极个别规则有为了折腾而折腾的感觉,但你问我滋瓷不滋瓷,那肯定是滋瓷的。—— Grandomtech-patroller 2022年9月2日 (五) 00:34 (CST)
  27. (+)同意 啊吧啊吧(—— 非专业技师一位史蒂夫  讨论·贡献 快来单推可爱的雏羽吧~ 2022年9月2日 (五) 19:49 (CST)
  28. (+)同意 通篇看了一遍,感觉挺好的,尤其是对之前“特殊符号”的界定。——Xzonn聊天) 2022年9月3日 (六) 10:24 (CST)
  29. (+)同意 无条件支持。--Vcfch843875618讨论) 2022年9月3日 (六) 20:03 (CST)
  30. (+)同意 进步的。——Bete1geuse1个标签:打嗝) 2022年9月3日 (六) 20:12 (CST)
  31. (+)同意 終於不用全部都用半角符號了......--By CHKO (Talk) @ 2022年9月5日 (一) 13:32 (CST)
  32. (+)同意 上次超时了太可惜了……--CONTINUE TO FIGHT WITH COVID-19!·P. W. T. 2022年9月5日 (一) 19:46 (CST)
  33. (+)同意 无意见。--94 42 233 2001-8 J-JREDiscussion) 2022年9月6日 (二) 00:22 (CST)
  34. (+)同意 总算抽出时间通读了一遍,无异议,很认可。-- 珞羽子(交流室) 2022年9月6日 (二) 10:09 (CST)
  35. (+)同意:解决了许多痛点。—— LN2 不是液氮 (讨论贡献) 2022年9月6日 (二) 12:08 (CST)
  36. (+)同意 很完备了,早该这样改了。-- Welcome to the Hotel California 2022年9月6日 (二) 16:33 (CST)
  37. (+)同意 无异议——From 西尾哈鲁卡 (讨论) 2022年9月6日 (二) 18:28 (CST)
  38. (+)同意 到这里都没什么可说的了--已经是一条死鱼的HetmesAskalana 2022年9月6日 (二) 19:27 (CST)
  39. (+)同意 終於不用都半形了,特殊符號也有規可循了。——空翊「留言」 2022年9月6日 (二) 20:32 (CST)
反对
弃权
  1. (∅)弃权 没时间细看了,大家认可就好。 -- 宇文西修ิิۣۣۖۖۖ特拉瑟 2022年8月31日 (三) 16:38 (CST)
  2. (∅)弃权 阿巴阿巴阿巴……不是我经常关注的领域,就弃了先。诸位觉得行就行吧。—— Jacklin612·🧾) 2022年9月6日 (二) 23:20 (CST)

拥有票权的自动确认用户

同意
  1. (+)同意 早该通过了--Cesko讨论) 2022年8月30日 (二) 23:37 (CST)
  2. (+)同意 {{利益相关}}。——CGSS topic CONTRIBUTOR the "Light wind colored" Legend frog (NAIVE) 2022年8月30日 (二) 23:59 (CST)
  3. (+)同意 这是好的。——GuoPC「Pray for you 心はもっと近くなる 何処にいようとも 2022年8月31日 (三) 08:05 (CST)
    ▼ 该投票无效,原因:无票权。
    (+)同意 规范固然为好,但希望不要矫枉过正。无论如何我很高兴能看到提案中大部分内容都是我所希望或是所能接受的。--Zero-Skytadokoro vs. User:JALALgl--やりますねい 2022年8月31日 (三) 09:20 (CST)
    ▲ 该投票无效,原因:无票权。
  4. (+)同意 解决了希腊字母问题后没有看到要反对的地方,整理过后的指引也便于后续修改,唯一的缺点就是太长了(详细点也是好的——AKQ 代号 不可逆Talk/Contributions) 2022年8月31日 (三) 14:02 (CST)
  5. (+)同意 可以接受--Takeuchi.BadEditor (讨论留名) 2022年8月31日 (三) 16:50 (CST)
  6. (+)同意 我提出的问题已经得到妥善解决了,特别是类似《逆A高达》中的“”。
    --信偶活如信混沌四神的喵某讨论) 2022年8月31日 (三) 18:10 (CST)
反对
  1. (-)反对 虽然我认同大多本提案的内容,这一票反对也不会影响本提案的通过,但很遗憾因我已经提及的原因,我说到做到地投一个反对,希望理解。——4O74Y74L74J7讨论) 2022年8月30日 (二) 23:42 (CST)
  2. (-)反对 英文标题禁止使用弯引号明显不合理。— 小鹿包18 Honoka55留言贡献・ 2022年9月2日 (五) 11:38 (CST)
弃权

无票权用户意见

同意
  1. (+)同意 甚至可以说这提案几年前就该有了。--いつもの景色 対峙 「もう一度コンテクストを探せ」(废人) 2022年8月30日 (二) 23:49 (CST)
  2. (+)同意 这个可以有-- VENI,VIDI,VICI萌百) 2022年8月31日 (三) 09:37 (CST)
  3. (+)同意 反正就完全同意嘛!谁叫萌百用wiki语法编呢?虽然这样有时能更方便地做出特殊效果,但对新手很不友好,符号冲突也很麻烦。仅仅对于方便来说,百度娘其实更好—-青空に白鷺讨论) 2022年9月4日 (日) 14:27 (CST)
反对
弃权

计票与结论

根据萌娘百科:提案:具有投票权的用户为:【管理员】、【巡查姬】、在讨论阶段参与了提案讨论的已注册达30天、遵守方针的活跃【自动确认用户】。在提案有至少2位管理员参与投票时,【投票有效】。

  1. 投票开始时共有8名参与站务的管理员;其中,
    • 5(+)同意
    • 0(-)反对
    • 1(∅)弃权
    • 2人没有参与投票(蓝羽汇、弗霖凯)
  2. 投票开始时共有44名正式巡查姬;其中,
    • 39(+)同意
    • 0(-)反对
    • 2(∅)弃权
    • 2人没有参与投票(SinonJZH、沼泽)。
  3. 共有18名有票权的自动确认用户参与了投票;其中,
    • 6(+)同意
    • 2(-)反对
    • 0(∅)弃权
  4. 另有4位无票权用户发表了意见。

当前提案有5位管理员投有效的【同意】或【反对】票,该提案投票有效

统计计票结果,全部投票之同意:反对票数量为50:2,【同意】票数大于【反对】,且管理员的【同意】票数不小于【反对】,【提案通过】。 あめろ 讨论 2022年9月6日 (二) 23:53 (CST)