维基百科

维基百科讨论:格式手册/标点符号/存档3

< Wikipedia talk:格式手册 | 标点符号
Jimmy-bot在话题“关于数值比值中的冒号问题”中的最新留言：1年前

增修標點符號格式手冊

最新留言：在2年前发布22条留言12人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年3月20日 (日) 08:14 (UTC)。

建議在標點符號格式手冊增修有關示亡號的使用，規範示亡號僅用作在列表中（包括點列式、表格或資訊框內）標記當前文字所表述的時間環境下此人已經逝世，例如在長壽節目製作播出期間演員或製作人員逝世，或是獎項追頒。{{金鐘獎特別貢獻獎}}、{{新闻联播播音员}}屬於合理使用示亡號的例子，而{{大紫荊勳章}}的例子就屬於濫用。--路西法人☆ 2022年1月14日 (五) 14:29 (UTC)

(＋)贊成，不然遲早會看到全部是示亡號的列表。--Wolfch (留言) 2022年1月15日 (六) 07:00 (UTC)
  囧rz……(＋)支持 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年1月25日 (二) 05:49 (UTC)
内容不可更新的纸媒列表使用示亡号比较常见，而内容可更新的网络列表是否必要使用？人总是要死的。乌拉跨氪 2022年1月17日 (一) 16:47 (UTC)
(＋)支持，甚至我覺得可以完全禁止使用，這個符號本來就不是什麼通用符號，再加上維基百科有內部連結，想知道一個人還在不在世用滑鼠放到上面不就知道了，點進長壽劇節目條目又不是想看甚麼「xx医院死亡演員列表」。至於獎項追頒應改為其他腳註符號，* † 之類的，又不是說活著拿獎的人就不能死，這樣會產生很多歧義。--Austin Zhang（留言） 2022年1月17日 (一) 19:36 (UTC)
(＋)支持。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年1月25日 (二) 04:33 (UTC)

@LuciferianThomas：是否提出正式修訂草案並作公示？—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月2日 (三) 11:20 (UTC)

(＋)贊成限定使用范围，不然迟早全都是方框。--字节 2022年2月4日 (五) 02:52 (UTC)
(－)反对，反对额外的示亡标识，根本上不加。用连接到条目则可解决，如果对应人名没条目，可以简单补充生亡年份来代替。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月8日 (二) 02:31 (UTC)
格式手冊可採「多數禁止，少數不建議」立場表達本站態度。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月8日 (二) 11:34 (UTC)
同Eric君顧着搞SPI忘了我提過這個（草--路西法人☆ 2022年2月15日 (二) 03:25 (UTC)
反對在任何條件中使用示亡號，Special:Diff/70179631，founder部分看似符合提案人的要求，但等到其餘三位辭世，豈不是founder一欄出現四次示亡號。--寒吉 2022年2月15日 (二) 05:02 (UTC)
創辦之時未離世，董事長之位會被取代（不是其獨有）。--路西法人☆ 2022年2月16日 (三) 02:21 (UTC)
那我還是一樣反對在任何條件中使用示亡號。董事長當然會被取代啊，所以我上頭只提「founder部分」，沒提董事長。--寒吉 2022年2月16日 (三) 11:41 (UTC)
founder部分不會啊，不就說了「創辦之時未離世」嗎？--路西法人𖤐 2022年2月18日 (五) 05:57 (UTC)
我的回覆有質疑「創辦之時未離世」這句話嗎？我的看法就是一律禁用示亡號，只是恰巧你在此處提案，我順便提出Special:Diff/70179631詢問founder部分是否符合提案的要求，你回覆不符合，而我沒質疑這部分啊，我只是回覆為何你要回覆我沒提到的董事長部份而已，且founder部分不符合提案仍不會改變我持一律禁用示亡號的看法。--寒吉 2022年2月19日 (六) 11:42 (UTC)

先說我本人的淺見。我認為在百科全書標示亡號完全沒必要。百科全書是要流傳千古的，也就是說，總有一天書上所有條目裡的所有人名都是死人，那就全都要標示亡號。全都要標就等於全都不標，標了還浪費時間精力。百科全書皆如此，不獨維基為然。

可行的用法，就是在實際生活上的用法，也就是事件來臨時相關人物已經不在了。例如候選人於競選活動開始前死亡（美國發生過），影業人員在影片發行前死亡（如英雄本色中的石燕子，不過有疑義）等等。但現在某些維基編輯的用法是看到哪個公眾人物死了，就忙不迭把相關條目全翻出來，一個一個替人標示亡號。所以這就涉及定義了：示亡號是用於表示看到條目時人已經不在了，還是表示事件發生時人已經不在了？我認為是後一種，各位呢？這點要列為方針嗎？

前面說到疑義，是有的事件發生不止一次。例如英雄本色上映時間各國不同，以何為準？還是就乾脆不用標了？

謝謝各位撥冗看我囉唆一堆細節。--以上未簽名的留言由2603:8000:500:FB00:5011:1E64:1DB0:C8F1 （討論）加入。 —以上未加入日期時間的留言是于2022年2月20日 (日) 08:14 (UTC)之前加入的。

此話題多日無新發言。個人理解部分維基人想要全面禁止使用示亡號的態度，不過在此方面諸位大概暫無共識。不如先漸進推行「多數禁止，少數不建議」一案，至少一路看下來應該沒有堅決反對此案者？不希望討論最終被存檔，付諸流水。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月2日 (三) 16:31 (UTC)

對於IP的留言，沒錯，就是說事件來臨時相關人物已經不在了才適用示亡號，而事件發生後才死亡的就是明顯濫用了。另對於Cwek君的說法，在Infobox裡加生卒年份尚有道理，在列表裡或navbox裡加生卒年份很突兀吧，加個標記（不一定要是框，你標個符號也算）無論如何看起來都比較合適。完全禁止不是不行，但例如獎項追頒（見{{金鐘獎特別貢獻獎}}）這些合情合理的使用方法都完全禁止就不太好了。--路西法人𖤐 2022年3月10日 (四) 01:52 (UTC)

新建一个去除图片介绍末尾标点符号的机器人

最新留言：在2年前发布7条留言7人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2022年5月31日 (二) 00:14 (UTC)。

根据MOS:。，图片介绍文字的末尾不应该添加标点符号，但是有相当多的地方还是没有注意到这一问题，包括一些典范条目（如宋朝科技）和优良条目。因此，能否增加一个机器人，来自动处理该问题？实现起来应该也不难。--Shenzhiming88（留言） 2022年5月13日 (五) 15:55 (UTC)

建议重新审视这条格式规范和共识。

  1. 首先，个人认为MOS:。中第二例在去掉末尾句号后反而更不美观和段落不清晰。
  2. 检查来看，该要求源自2013年由乌拉跨氪主笔并讨论和公示通过的格式指引，基于中华人民共和国《标点符号用法》（GB/T 15834—2011）[1]的附录A第一条，且不少机构的格式规范文件有参照此条做相同规定[2][3][4]。
  3. 但其一，公示通过前Gqqnb对该条提出了相反的格式意见，不过讨论以“标准”所定结束。没有找到其他讨论来强化该条指引的共识性。该标准为中国大陆的“GB/T”（国标/推荐），应该思考为什么这样做、是否这样做，而不是简单地“也要这样做”。
  4. 其二，也是比较重要的，仔细搜索看到了一些豁免解释和相反意见。
    1. 如果说明文字在图片或表格的正下方，则与一般文段句号的用法相同，在句末使用句号。[5]
    2. 针对科技论文图表中的注释句末是否用标点符号的问题，GB／T1．1—2009《标准化工作导则第1部分：标准的结构和编写》关于图题、表题和图注、表注的示例明确告诉我们：图题、表题的末尾不用任何点号；而图注、表注末尾要用句号。
      科技论文插图中除“注”“脚注”外，也有“说明文字”，三者通称图注。按照GB／T1．1—2009给出的示例，这类插图的“说明文字”末尾也要用句号。[6][7]
    3. 文章中有时会出现插图或表格等形式，其说明文字可能出现在上一段文字的末尾，也可能出现在图片或表格的正下方。如果出现在上一段文字的末尾，不管说明文字的长短，结尾都不用句号。如果说明文字在图片或表格的正下方，则与一般语段中的句号用法相同，结尾要用句号。[8][9]
    4. 如果出现在段尾，说明文字末尾通常不加句号。有时说明文字是一段话，前面已经使用了句号，在最后的结尾处仍不使用句号。
      如果说明文字在图片或表格的正下方，则与一般文段句号的用法相同，在句末使用句号。（如：行刑场景，上海，19世纪70年代。斩首为中国……。中国在1905年以枪决代替斩首。[10]
    5. （以上内容摘录仅用于学习、研究目的，版权归属原作者/书籍）。

关于“如果出现在段尾”，个人理解，可能指“正文-说明文字-表格/图片”的排版方式，这种情况下句号会分隔解释与“图或表”，从而不应。对于混排时悬浮（如右对齐）的图片下方的说明文字，除非不成句（如很短，中间没有任何逗号/句号/问号/惊叹号等），否则可能认为应加注句号以表示语句结束。 --YFdyh000（留言） 2022年5月13日 (五) 18:39 (UTC)

非常感谢User:YFdyh000提醒了我们关于题注可能存在的争议。
在2008年（比GB/T要早3年），en:Wikipedia:Manual_of_Style/Captions就已经被翻译成Wikipedia:格式手册/题注，但是只是作为参考，不是一个正式的指引。英文维基百科和一些语言的维基百科（如：ms:Wikipedia:Tajuk_imej）都是要求完整的句子，以句号结尾；也能发现另一些语言的维基百科对整句的是没有要求的，甚至多种形式会出现在同一篇条目中。
关于这些争议我们可以考虑以下方案：
1. 修改MOS:。使其与Wikipedia:格式手册/题注一致。这个方案的好处是可以与英文和一些其他语言的维基百科一致，在翻译条目时不必调整格式。
2. 修正Wikipedia:格式手册/题注，使其与MOS:。一致，避免指引和参考不一致的情况。这个方案的好处是和GB/T 15834—2011一致。
3. 如果现有共识已经不再被绝大多数编者接受，可以去掉MOS:。中关于完整的句子的指引。这个方案的好处是很可能会减少机器人编辑的次数，有利于减少碳排放。
另外，我们可以考虑将Wikipedia:格式手册/题注设置为指引。--zy26 was here. 2022年5月14日 (六) 03:50 (UTC)
我现在写英文比较多。我碰到的英文出版社关于图片题注是说，如果是一个完整句子，有主语谓语，则加句号。如果是短语，则不加句号。我自己做slides也是这样。
维基百科:格式手册/标点符号：“维基娘是维基百科萌拟人化后的美少女角色。由日本维基百科人创作”
这个例子有点儿怪。第一句是完整句子，第二句是残缺句（缺少主语）。我建议：题注第一句允许为短语。若题注多于一句，第一句用合适的标点符号结尾，后面的句子必须为完整的句子，用合适的标点符号结尾。
现在我倒是没有那么专注于《中华人民共和国标点符号使用规范》。我看楼主的参考资料大部分是中国的，可能中华民国台湾的用法是underrepresented。--Gqqnb（留言） 2022年5月15日 (日) 07:50 (UTC)

原來這個圖片說明的句點規定放在那裡啊，我之前一直找不到XD —— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月14日 (六) 16:42 (UTC)

我自己的做法是，noun phrase （短句）不放句號，完整句子就放。供參。--Temp3600（留言） 2022年5月20日 (五) 17:20 (UTC)

参考資料

  1. ^ https://people.ubuntu.com/~happyaron/l10n/GB(T)15834-2011.html
  2. ^ 咬文嚼字——图片下面的文字末不用句号
  3. ^ 中国科学技术大学 研究生学位论文撰写手册，
  4. ^ 党政机关公文中标点符号使用应遵循国家标准 四平市审计局 任传宝
  5. ^ 【业务学习】标点符号用法解读之句号 - 《蚌埠工商学院》编辑部
  6. ^ 科技论文图表中的注释句末应用句号 《西部医学》 2016年第11期1488-1488
  7. ^ 郝远.科技文稿中的图注、表注末尾用句号吗?[J].编辑学报,2014(1).
  8. ^ 新国标标点符号使用手册 兰宾汉 2014-9-16 出版社：中华书局
  9. ^ 《标点符号用法手册》 兰宾汉 2015年1月 商务印书馆，内容应同上
  10. ^ 网友摘录，《标点符号用法》解读 2012-9 作者: 教育部语言文字信息管理司 出版社: 语文出版社

非中文作品名中的半形標點符號是否應該修改成全形

最新留言：在2年前发布5条留言5人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2022年6月26日 (日) 08:14 (UTC)。

今年1月發現有用戶在大量條目將非中文歌曲名中的標點符號由半形改成全形，比如將「Yeah (Round And Round)」改成「Yeah（Round And Round）」[1]，還聲稱「括號全形是維基化」，誰要是回退他的編輯就是在破壞。但MOS:PUNCT中寫道：「輸入非中文內容時則應使用該語言規定的標準標點符號」，請問這句話在什麽情況下才適用？以「維基化」為理由，將英文中的半形標點符號改成全形，我認爲是顛覆常識的行爲。直到6月這位用戶還在我行我素繼續「維基化」，再這樣下去恐怕連Category:美國音樂專輯裡的條目都會被他一一改成全形。--1.162.90.235（留言） 2022年6月15日 (三) 04:32 (UTC)

我认为这种行为就是无意义的破坏，就像台和臺一样。除非社区打算对其作出明确的共识。--The Puki desu（留言） 2022年6月15日 (三) 15:02 (UTC)
如此修改无必要。请指明继续修改发生在哪些条目。如果括号内非原文自带内容，改为全形可能无问题，如此版本的将团体名括号改为全形。--YFdyh000（留言） 2022年6月15日 (三) 16:49 (UTC)
的確外語該用外語格式，但對方改為全形也無可厚非，上方告示自古沒人看。條目名稱是不用擔心，音樂命名方針有闡述全形半形的應用。 --Loving You Is A Losing Game 2022年6月16日 (四) 04:59 (UTC)

学术期刊/学报 标题

最新留言：在2年前发布9条留言6人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2022年8月3日 (三) 16:14 (UTC)。

以目前条目华中科技大学学报（自然科学版）为例，目前的标题是“华中科技大学学报”，但是华中科技大学学报实际上分为医学版（ISSN 1672-0741）、自然科学版（ISSN 1671-4512）、社会科学版（ISSN 1671-7023）。

如果单独写“华中科技大学学报（自然科学版）”，条目名称直接用 华中科技大学学报（自然科学版） ？其中的括号用全角"（）"，还是半角"()？如果某期刊分为中文版和英文版，假如只写英文版的条目，是否可以起名为 XXXX (英文版)？这个有点类似自然杂志旗下的期刊，比如自然-生物技术 。--Kethyga（留言） 2022年7月10日 (日) 02:26 (UTC)

名从主人。个人建议全角，消歧义目的时用半角——半角括号内的，可能是原名不具有的原创归纳。如果无法名从主人，不写符号的华中科技大学学报自然科学版可能也不错。自然-生物技术感觉有点怪，自然生物科技或自然－生物技术可能更好。--YFdyh000（留言） 2022年7月10日 (日) 03:26 (UTC)
中国国家新闻出版署上倒是用的全角华中科技大学学报（自然科学版），且全角括号和前半部分无空格；但在不同的数据库中不完全一致，比如在CNKI上是华中科技大学学报(自然科学版)，使用的半角括号、括号与前半部分无空格，百度学术上同CNKI[2]。万方数据上同新闻出版署[3]。然后维普期刊用的是《华中科技大学学报：自然科学版》。中国国家图书馆中题名与责任是华中科技大学学报, 自然科学版[期刊] = Journal of Huazhong University of Science and Technology, Natural Science Edition。日本CiNii是华中科技大学学报. 自然科学版。中国科学引文数据库（CSCD）中华中科技大学学报. 自然科学版。Google学术上，参考来源数据库[4]。 --Kethyga（留言） 2022年7月10日 (日) 04:15 (UTC)
名从主人建议参考最显要的其自身出版、频繁引用的地方。其他地方，不乏因格式、排版等要求改动标点、字形等。而如果无法确定标准写法，选最好用的也可以，比如华中科技大学学报：自然科学版的可读性不错，其他可建立重定向。条目内容更重要，条目名待出现争议再改不迟。--YFdyh000（留言） 2022年7月10日 (日) 04:33 (UTC)
先移动至 华中科技大学学报（自然科学版） 了--Kethyga（留言） 2022年7月16日 (六) 11:29 (UTC)
事實上我在PDF看到的是半形括號，但是確實很多的學報的顯示方式都不同，名稱也有異，如果不肯定就通通重定向。--Ghren🐦🕛 2022年7月10日 (日) 04:43 (UTC)
很简单，因为很多期刊自己就不太在意自己期刊名字写法的细微区别--百無一用是書生 (☎) 2022年7月12日 (二) 02:39 (UTC)
已移動後者至自然－生物技术。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月24日 (日) 11:44 (UTC)

跨年份（度）的體育賽季條目命名

最新留言：在2年前发布9条留言6人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2022年8月14日 (日) 16:14 (UTC)。

2022年了，希望解決相關條目命名格式不一致的問題。過去討論存檔：2009年2月、2012年11月、2014年7月、2018年12月、2021年10月。

「2020–21 ABC（season）」在中維該命名為以下哪種（假設須加上「年」）

  1. 「2020－21年（度）ABC（賽季）」
  2. 「2020年－21年（度）ABC（賽季）」
  3. 「2020至21年（度）ABC（賽季）」
  4. 「2020年至21年（度）ABC（賽季）」
  5. 「2020/21年（度）（賽季）ABC」
  6. 「2020－2021年（度）ABC（賽季）」（年份全展）
  7. 「2020年－2021年（度）ABC（賽季）」（年份全展）
  8. 「2020至2021年（度）ABC（賽季）」（年份全展）
  9. 「2020年至2021年（度）ABC（賽季）」（年份全展）--寒吉（留言） 2022年6月30日 (四) 15:51 (UTC)
根据其他条目标题来看，部分用户创建条目时会用错连接号，所以可以考虑弃用，暂时支持8或9。--东风（留言） 2022年7月1日 (五) 03:20 (UTC)
補充說明，「賽季」對有些聯賽來說未必會使用到，例如以「聯賽」做結尾的體育聯賽，英格蘭足球超級聯賽（en:2022–23 Premier League）、中国男子篮球职业联赛（「2021-2022 中国男子篮球职业联赛」 或是官方命名 「2021-2022赛季CBA联赛」）、超級籃球聯賽（「2021-22 年(第 19 屆)SBL 超級籃球聯賽」，但條目直接使用常用準則命名即「第十九季超級籃球聯賽」）。另外Category:熱帶氣旋季也有牽涉到相關問題，只是維基上應該九成五以上還是牽涉到體育賽季較多。提供現存其他命名方式之一，「ABC2020賽季」（Category:广州足球俱乐部、Category:北京国安足球俱乐部赛季）。--寒吉（留言） 2022年7月1日 (五) 04:49 (UTC)
第七或第九種。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月1日 (五) 14:23 (UTC)
支持6，其次7。9也可以，但如果格式要全面统一就不合适，因为“2020年到2021年”我觉得也可以。--YFdyh000（留言） 2022年7月12日 (二) 03:22 (UTC)
是否全面統一還有待商榷，但至少同個聯賽的賽季格式要統一，比如Category:英格蘭足球超級聯賽就需統一，也須解決連接號問題。您是第一位提出要使用「到」字的用戶，過往討論都提出使用「至」字，所以我才只列出「至」字方案。--寒吉（留言） 2022年7月12日 (二) 04:15 (UTC)
「到」稍顯白話，「至」為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月12日 (二) 15:03 (UTC)

人物條目使用T:box

最新留言：在2年前发布15条留言7人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2022年9月20日 (二) 16:14 (UTC)。

--CaryCheng（留言） 2022年9月6日 (二) 07:54 (UTC)

相同意见，另外还有西方类似的剑标（T:KIA）。部分涉及示亡号的讨论Wikipedia:互助客栈/条目探讨/存档/2019年2月#李詠姓名的處理、Wikipedia:互助客栈/条目探讨/存档/2020年6月#條目內是否可使用示亡號？——Sakamotosan路过围观 | 避免做作，免敬 2022年9月6日 (二) 08:31 (UTC)
感謝，原來社群已有討論達成共識了。--CaryCheng（留言） 2022年9月6日 (二) 16:21 (UTC)
用戶:陳康健老師：本人覺得，名單中若出現逝者，把示亡號加於逝者，可以使讀者更清楚名單中有逝者；至於其他內容，本人並無特別的意見。
--以上未簽名的留言由陳康健老師（討論｜貢獻）於2022年9月6日 (二) 21:06加入。
終期於盡，將來這些頁面中的人都會加上示亡號，不如當初就不加。 紺野夢人 2022年9月6日 (二) 15:29 (UTC)
除少数情况原作有加（作品首次发行时人物已逝）而可做考虑和讨论，其他情况加入应为滥加。--YFdyh000（留言） 2022年9月6日 (二) 16:04 (UTC)
是的，但即使这种，也不会在正文里加入示亡號--百無一用是書生 (☎) 2022年9月7日 (三) 02:19 (UTC)
@陳康健老師：參閱上方Sakamotosan提供的討論記錄，社群已有共識在條目中不應加上{{box}}，僅有少數特殊情況可以例外。因此我將回退閣下過去數日編輯摘要為「加示亡號」及「加box」的編輯。--CaryCheng（留言） 2022年9月6日 (二) 16:21 (UTC)
建議把先前存檔討論部分內容及此次討論共識，例如說"「任內逝世」的加框，同時應該加腳註說明"，在Wikipedia:格式手册/标点符号開一個示亡號的段落說明，把Template:新闻联播播音员跟電視金鐘獎特別貢獻獎加註說明列成範例（或挑其他更適合的範例），並強調其他狀況一概不加。畢竟連同此次討論，關於示亡號的討論已經三篇了。--Anghualee（留言） 2022年9月9日 (五) 01:17 (UTC)
何时加、如何加并无共识，是依情况而定。至多达成何时不加的共识。中国科学院院士等终身制职务、荣誉的导航模板中，按此标准可能变成一大堆加框。有时，用删除线、星号等标识会更美观（以及網頁親和力稍逊的斜体、灰色字），方框示亡号过于突出，仅适合占比不多的情况，如少于三成或五成。--YFdyh000（留言） 2022年9月9日 (五) 04:47 (UTC)
同U:YFdyh000意見，目前社群共識為不加示亡號。至於作為範例的兩個模板，其實只是用{{box}}作註釋，改用星號或是其他符號加註也可以達到同樣效果。因此，我認為不需要在Wikipedia:格式手册/标点符号開一個示亡號段落說明。--CaryCheng（留言） 2022年9月9日 (五) 08:21 (UTC)
  • 所以你們比較偏好下次出現這種狀況的時候拉三篇討論存檔出來說社群有共識不加，下下次出現這種狀況的時候拉四篇討論存檔出來說社群有共識不加？這種都已經討論很多次的東西不往指引或方針放，整天回頭貼 oid 連結是有比較好？
  • 像承翰爸訃聞曝！兒名字「加方框」（內有警察犧牲、訃聞內容，不喜者勿點）就會有明確的時間點（公祭時間），這不就是大家有共識加框合情合理的狀況。那榮譽性質的清單並沒有特定時間點，而是持續增長，那本來就不應該加。那自然什麼佔比很多或者更進一步佔比逐漸上升的問題也不存在。
    • 另外感覺有些列表莫名其妙，就應該只列目前在職。其他情況應該另列清單，如離職、解職，另外開一個卸任列表或什麼的。已故更是應該另外開一個清單然後分類到Category:死者列表裏面（都在死者列表了自然也不用加框）。怎麼會是在那邊說這樣清單會有一大堆加框，會有這種情況是不是清單塞太多東西了？
  • 示亡號在單純未有任何加註的情況下就能讓人一望而知，為了避免示亡號而故意採用其他標記方式來原創標記方式再配合加註。這沒什麼不好啊，有人反對另外用中文訃聞或類似文件中不曾採用的方式標記嗎？我想也沒有吧。那弄個共識一樣加到指引裡面去嘛。
  • 搞不懂你們在對加指引抗拒什麼，那算了，抗拒就抗拒吧，不加文檔就不加文檔嗎。那至少偵測到輸入區域內有 box 模板時，在編輯送出時會卡一次送出，顯示紅色警告訊息再次要求使用者確認要不要送出編輯，總可以吧？不打算在方針指引幫助文檔中增加內容，那起碼技術面攔阻讓使用者知道有共識不要隨便加示亡號（box 模板）可以做吧？ --Anghualee（留言） 2022年9月9日 (五) 20:37 (UTC)
    如果期望列入方针/指引，请自撰条文并得到认可，然后通过公示期就可以了。目前来说，暂未想到怎样总结适当的标准和阐述。--YFdyh000（留言） 2022年9月10日 (六) 00:12 (UTC)
同U:YFdyh000意見，閣下可至Wikipedia:互助客栈/方针提案討論，經社群共識通過即可。--CaryCheng（留言） 2022年9月10日 (六) 11:37 (UTC)
既然有过往的讨论建议不添加，干脆将其纸面化，记入到格式手册中。如果可以的话，我希望连战亡的剑标（T:KIA）也类似看到。——Sakamotosan路过围观 | 避免做作，免敬 2022年9月10日 (六) 03:33 (UTC)

格式手冊的破折號用法與《中華民國教育部〈重訂標點符號手冊〉》不符

最新留言：在2年前发布11条留言5人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年10月14日 (五) 08:14 (UTC)。

如題，我發現維基百科:格式手冊/標點符號的破折號樣式（——）與《中華民國教育部〈重訂標點符號手冊〉》（──）不符，而且教育部《國語辭典簡編本》以及教育部《重編國語辭典修訂本》也是使用後者，是不是該修改格式手冊？

雖然上面顯示是一樣，但我用沙盒測試時，會出現中間有空格的情形。有一些條目也有這種狀況。

已獲得解答，謝謝大家！只有行動版頁面的破折號會有中間空格的問題，才讓我以為那不是正確的。 --Picture GN（留言） 2022年10月2日 (日) 11:19 (UTC)

参见破折号。你输入的对应Unicode编码似乎是U+2500。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月2日 (日) 11:28 (UTC)
然后搜了破折号，几乎全是U+2500，囧。不过结合说明，一般输入法用就是U+2014。使用标准手册的写法似乎不是事实上的计算机上算的输入法。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月2日 (日) 11:36 (UTC)
中间出现空格有可能还与字体库渲染的字型有关，有些dash的字型是顶左右两边，但也有些并不是，就导致两个字符间有“空隙”。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月2日 (日) 11:38 (UTC)
感謝指導！的確是字體的問題，我把維基百科調成桌面版畫面後就沒有中間空格的情形了。十分感激！--Picture GN（留言） 2022年10月2日 (日) 13:35 (UTC)
按照中华人民共和国GB/T 15834-2011（PDF、HTML）其破折号对应Unicode字符为U+2014，而非U+2500。而查询Unicode表，U+2500为制表符，U+2014才为单宽度横线，原页面样式应当无误，可能是中华民国教育部问题。HotaruTalk 2022年10月2日 (日) 11:42 (UTC)
我把頁面改成桌面版後，格式手冊的破折號即顯示正常，格式手冊的樣式的確無誤，感謝指導！--Picture GN（留言） 2022年10月2日 (日) 13:48 (UTC)
製作文件的人的問題吧，畢竟一般人對於 unicode 內部實際對應意義並不了解，看到一般的 dash 在字型顯示的情況下中間有空格，不明究理的情況下自然打出來的文件就會是那個樣子。W3C《中文排版需求書》裡面也講台灣教育部乙式括號在中國大陸視為破折號的一種，而破折號更是沒有區分台灣大陸，基本上就以《中文排版需求書》為準吧，畢竟裡面的專家學者對於unicode與網頁標準的了解，遠比公務員或者是一般學校職員靠譜多了。我好奇的是，那中文維基百科的U+2500U+2500有辦法透過什麼方式丟到某個分類，或者是讓機器人根據某種條件自動替換，來讓人有機會去清理。以及簽名的--能換成U+2E3A嗎？--Anghualee（留言） 2022年10月3日 (一) 16:33 (UTC)
没这个必要，发现随手修就是了。而且大部分的输入方法都是2个U+2014，而基本没见过用U+2E3A。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月4日 (二) 00:39 (UTC)
U+2E3A的部分我是問Wikipedia:签名的U+002DU+002D是否適合替換成U+2E3A，跟你們用U+2014U+2014而非U+002DU+002D可能類似，但不是U+2014U+2014換成U+2E3A。--Anghualee（留言） 2022年10月4日 (二) 07:55 (UTC)

該不該把影視作品、音樂與電子遊戲列表中的作品名稱加上書名號？

最新留言：在2年前发布19条留言10人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年10月15日 (六) 16:14 (UTC)。

我發現大部分的列表都沒有把作品名稱加上書名號，但我認為應該要加上比較正式，請問如果以這個方向進行編輯的話，應該不會被當成無意義的編輯而被回退或警告吧？ --Picture GN（留言） 2022年10月2日 (日) 17:50 (UTC)

除了作品列表，還是演員/配音員的條目的演出列表，不加上書名號好像是很常見的情況。如早見沙織。有加上的如尼古拉斯·凯奇。--Nostalgiacn（留言） 2022年10月5日 (三) 07:21 (UTC)

XX系列（遊戲、影視、文藝作品系列）的書名號位置？

最新留言：在2年前发布15条留言9人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年11月2日 (三) 16:14 (UTC)。

請問遊戲、影視、文藝作品系列（的正文，不含條目標題）需要加上書名號嗎？如果要加，「系列」二字該被囊括在書名號之中嗎？MOS:書名號僅提及「系列著作的選題名」，但是有些系列作品的名稱本身沒有「系列」二字，例如：星海爭霸系列、紅色警戒系列的各項遊戲名稱皆沒有「系列」二字。

各位認為下列哪一項比較好：

  1. XX遊戲/電影/小說系列
  2. 《XX遊戲/電影/小說》系列
  3. 《XX遊戲/電影/小說系列》

在此追問：作品的infobox當中的其他作品名稱建議加入書名號嗎？--Picture GN（留言） 2022年10月6日 (四) 18:48 (UTC)

名從主人原則，如果官方出品的時候作品的命名已經帶有「系列」，那麼就用「《XX遊戲/電影/小說系列》」；反之如果作品命名本身沒有「系列」，那麼就用「《XX遊戲/電影/小說》系列」。另外，在正文段落之中完全不用書名號（即「XX遊戲/電影/小說系列」）應該是不適當的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 19:02 (UTC)
謝謝指教！給了我明確的條目編輯方向。--Picture GN（留言） 2022年10月7日 (五) 00:54 (UTC)
好像这类作品系列性的条目，从命名到正文中都没有没有限定使用书名号，连“XX系列”这个命名逻辑也是基于作品的系列性自行产生的。而且命名常规也没有这个要求。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月7日 (五) 01:18 (UTC)
敝人糾結的點在於，該不該把「XX系列」視為創作/作品的名稱，如果是，則應該要加上書名號；如果不是，系列就不應該在書名號之中，但XX是否要加上書名號？--Picture GN（留言） 2022年10月7日 (五) 05:45 (UTC)
除非特指名称含“系列”的出版物，否则书名号内不要包含“系列”。是否加书名号看需求，是否有强调目的。--YFdyh000（留言） 2022年10月7日 (五) 06:10 (UTC)
大部分情况都是出了作品的主名，然后沿着主名衍生了多个分作品，在本站点中将这些事物概括成一个“系列”再统合编写。可能很少作品原名（或系列名）即为“XXX系列”。似乎不能一概而论规定如何添加书名号。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月8日 (六) 05:55 (UTC)
出版物本身是合集可能名称有“系列”。否则不应将总结而成的“系列”归入原名。--YFdyh000（留言） 2022年10月8日 (六) 07:32 (UTC)
我使用《XX遊戲/電影/小說》系列，也建議這麼用。除非作品名本身就有系列。-KRF（留言） 2022年10月7日 (五) 05:58 (UTC)
這種情況我通常不會加上書名號。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年10月7日 (五) 06:51 (UTC)
@Cdip150、@Cwek、@YFdyh000、@Ericliu1912、@Kerolf666：或許我們可以採用折衷的方式：將XX系列視為「複合名詞」（「XX」加上「系列」），換言之，就是將其視為「與XX（通常是作品名或作品名的一部分）劇情或世界觀相通的衍伸作品」，由於此不是著作名稱，而是大眾給這些作品的統稱，因此不使用書名號，而在正文中使用引號標註。（至少正文中第一次出現要加，下文可不限制是否加註引號）
敝人想在此詢問各位對這提議的意見。--Picture GN（留言） 2022年10月10日 (一) 00:10 (UTC)
所以變成《XX》「系列」？ --窝法乙烷 儿法梦碎 2022年10月15日 (六) 04:12 (UTC)
我的想法：「XX系列」（XX不加書名號）--Picture GN（留言） 2022年10月15日 (六) 06:16 (UTC)
「XX系列」這種情況下不可能是對的，就算是複合名詞也都是「《XX》」跟「系列」的複合。--Maccomcre（留言） 2022年10月23日 (日) 09:28 (UTC)

修订格式手册的标点符号中顿号的用法

最新留言：在1年前发布34条留言15人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年2月19日 (日) 16:14 (UTC)。

我发现好多条目中都有《书1》、《书2》或者是“引用1”、“引用2”的写法，但是根据中华人民共和国国家标准 GB/T 15834―2011：

所以这种写法应该不符合大陆的规范。但我不清楚其他地区是如何规定的。若规定一致，建议将该规范添加至Wikipedia:格式手册/标点符号中。是否也可以添加到过滤器中提醒呢？（检测》、《以及”、“这种字符） --Shenzhiming88（留言） 2023年1月28日 (六) 15:54 (UTC)

不至于，看得懂就好。另外你若只拿大陆标准来行事，有地域中心之嫌。--MilkyDefer 2023年1月28日 (六) 16:03 (UTC)
关于后一句话，由于我不太清楚其他地区的规定，所以我在原文中提到若规定一致，则可以加入。我不认为有地域中心之嫌。
另外我不认可阁下前半句。的确，肯定能看得懂，加入过滤器可能有些过了，但是既然是百科全书，就要尽可能保持严谨。例如，全角符号输入为半角符号，抑或大多数的别字，都不会影响读者的阅读。但的确不合统一的标准，同时部分挑剔的读者也会因为格式的不严谨而对其内容产生质疑。--Shenzhiming88（留言） 2023年1月28日 (六) 16:25 (UTC)
GB/T是推荐性规范，只作参考，有说“通常不用顿号”但未解释缘由，此时不必照单全收而要考虑原因和场景，不存在“应该不符合大陆的规范”。此事多次被提过（1、2），不过没有太多人关注，应是无需强制。该规范1995年版无此意见。--YFdyh000（留言） 2023年1月28日 (六) 16:32 (UTC)
虽然说“GB/T是推荐性规范，只作参考”，但是大陆似乎仅有该标准规定了标点符号的使用方法。“该规范1995年版无此意见”，但新国标出来后，旧的应该就废止了。“未解释缘由”，的确是的，但是该标准中似乎都没有解释缘由。此事多次被提过，但是我看了似乎都没有共识，所以又开了一个。阁下说了“可能不应推荐这种写法”，我觉得可以用蓝色问号标识，告诉编者最好不用该种写法。
( π )题外话：刚刚翻了一下标准，感觉别的地方也有些问题。标准中原文为“4.5.3.4 相邻或相近两数字连用表示概数通常不用顿号”，但维基百科上就变成了“相邻或相近的两中文数字连用表概数时不用顿号”。该种写法可能也是未被禁止的，建议改为蓝色问号标识的样式。--Shenzhiming88（留言） 2023年1月28日 (六) 16:52 (UTC)
对于2011版国标中的该建议，坊间也存在批评和拒绝采纳，如《民法典》“附则”中的顿号与标点符号规范化、救救顿号！——与《标点符号用法》商榷等。所以，可能不应推荐这种写法，但也无需禁止。  吐槽：总感觉以前讨论过类似的事。--YFdyh000（留言） 2023年1月28日 (六) 16:40 (UTC)
其他地区没有类似规定。而且在技术上应该不好实现。( π )题外话：弯引号之间用顿号挤压后可读性明显更高啊，但是你站好像没有标点挤压。--PexEric 💬|📝 2023年1月29日 (日) 04:12 (UTC)
大致來說，是因為書名號、引號本身已經有分隔字眼的功能，所以認為宜用不頓號。但實話，這個標準在大陸爭議也滿大的。--Ghren🐦🕓 2023年1月29日 (日) 09:29 (UTC)
个人倾向长一点成分间还是用顿号表停顿，没顿号分隔感觉气喘不上来。比如

媒体称赞作品是「近20年来最精彩的科幻小说」、「为日本近年来科幻小说之最」、「比肩《夜幕低垂》」[1][2][3]。

--洛普利寧 2023年1月29日 (日) 13:43 (UTC)
還是一如既往地反對這個提議，只有中國大陸有這種情況，其他情況下書名號之間的頓號屬於正常使用。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月30日 (一) 04:56 (UTC)
我只是觉得没有必要强制规范，我自己就不会写，很久以前省格子留下来的习惯，但会有人会特意补我的顿号。----Cat on the Mars 2023年1月30日 (一) 09:11 (UTC)
澳門法律上這種並列都會有頓號，例如澳門基本法第四十條：「《公民權利和政治權利國際公約》、《經濟、社會與文化權利的國際公約》和國際勞工公約適用於澳門的有關規定繼續有效……」、第263/2017號行政長官批示：「……《中華人民共和國憲法》、《澳門特別行政區基本法》及有關澳門特別行政區公共行政的法例等」、第264/2017號行政長官批示：「《綜合能力評估開考報名表》、《專業或職務能力評估開考報名表》及《開考履歷表》亦可以行政公職局提供的電子表格提交」，由此可見澳門政府並未採納該標準規範；澳門主流大多都是有頓號的。若然該規範在中國大陸本身都有爭議時，看來並不宜用於中維。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年1月30日 (一) 15:18 (UTC)
香港政府《政府公文寫作手冊》[5]雖然也說「標點符號的用法，可參考[…]的《中華人民共和國國家標準──標點符號用法》」（p. 3），但實際於附錄一提供的例子有頓號，如「樂團將演奏《十面埋伏》、《高山流水》和《彩雲追月》。」（p. 12）和「[…]故有“舉一反三”、“三番五次”、“三五成羣”等說法。」（p. 16）—— （留言） 2023年1月31日 (二) 13:08 (UTC)
既然如此，那就不添加这个大陆独有的标准了吧。但是是否有必要在格式手册中提及该情况，说两岸四地用法不同呢？--Shenzhiming88（留言） 2023年2月2日 (四) 14:52 (UTC)
@Shenzhiming88：那要看看你具體的提及方式是怎樣了。如果具體的提及方式合適的話，我倒是不反對這樣做。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月4日 (六) 07:57 (UTC)
我想的是在顿号章节的末尾处，添加如下内容：
注意：关于标有引号或书名号的并列成分之间是否使用顿号，两岸四地的标准不同。中国大陆的标准建议不用顿号，但若有其他成分插在并列的引号之间或并列的书名号之间（如引语或书名号之后还有括注），宜用顿号；台湾无明确规定；香港政府和澳门政府并未采纳该标准规范。--Shenzhiming88（留言） 2023年2月4日 (六) 08:24 (UTC)
我覺得可以，但感覺可能把馬來西亞與新加坡的情況也添加一下更好。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月4日 (六) 08:54 (UTC)
的确，但是我不太清楚这两个地区的情况，所以可能需要当地人的查证。--Shenzhiming88（留言） 2023年2月4日 (六) 09:40 (UTC)
@*angys*：能不能解説一下馬來西亞的對應情況？Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月5日 (日) 08:38 (UTC)
或许得请问@白布飘扬：君 angys →讨留奖 2023年2月5日 (日) 11:09 (UTC)
马来西亚本地的华文基本上还是会用上顿号，见：例一、例二。——白布飘扬（留言） 2023年2月6日 (一) 19:06 (UTC)

圖註的結尾的句號

最新留言：在1年前发布20条留言11人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年3月11日 (六) 16:14 (UTC)。

現行MOS:句號指出，「图片和圖表的描述……末尾不用句号。就算有时说明文字内容比较长，在前面的语段中已用句号，最后的结尾处仍不用句号。」

格式手冊的例子「维基娘是维基百科萌拟人化后的美少女角色。由日本维基百科人创作」我認爲不太好，「美少女角色」後應該用逗號。試另舉一組例子：

  •  
    维基百科标志
  •  
    维基娘是维基百科萌拟人化后的美少女角色
  •  
    维基娘是维基百科萌拟人化后的美少女角色。其雖非官方吉祥物，但已被官方和社群用於各類活動中。

第一張圖的圖註一般按短語理解，結尾不用句號爲宜。第二張圖的圖註可以構成句子，但是當短語處理亦可；結尾句號可加可不加。第三張圖的圖註顯然是兩個句子，尾句不加句號我是感覺到彆扭。

「視作短語的圖註結尾不加句號，視作句子/语段的圖註結尾加句號」可能更合適。但這樣的結果是，一眼看上去圖註結尾句號時有時無，表面上不夠統一。各位怎樣看？--洛普利寧 2023年1月22日 (日) 05:16 (UTC)

認同Lopullinen閣下的說法，短語不用句號，句子應用句號。(※)注意句2先前版本是「存在于图表中的短语式说明文字，其中部内容可用逗号，但末尾不用句号。就算是有些时候说明文字内容比较长，在前面的语段中已出现句号，最后的结尾处仍不用句号。」（粗體為後加）在下理解後句「说明文字内容⋯⋯最后的结尾处仍不用句号」仍僅適用於前句提到的短語式說明文字，不包括句子。Special:Diff/74616458中捍粵者閣下將「存在于图表中的短语式说明文字」修改成「图片和圖表的描述」使該段落變成適用於句子，但似乎沒有相關共識，應恢復成先前版本。另外Wikipedia_talk:格式手册/标点符号/存档3#新建一个去除图片介绍末尾标点符号的机器人曾討論是否應加句號。—— （留言） 2023年1月22日 (日) 12:49 (UTC)
收到！--－－勿用「進行」污染中文，要言簡意賅。　捍粵者 2023年1月22日 (日) 16:43 (UTC)
(＋)贊成“文字中已有句號或分號的語段應有恰當的標點收尾”。--Gohan 2023年1月23日 (一) 00:38 (UTC)
(＋)贊成。另外这方面的内容似乎移至MOS:CAP叙述更合适。--PexEric 💬|📝 2023年1月24日 (二) 06:37 (UTC)
(＝)中立：結尾是否要放上句點那是習慣問題，畢竟條目是應該寫給讀者看而不是自己看的。既然條目內容都是這樣了，那圖片當然也是這樣，不應一竿子改變這種習慣。就好比如：<ref></ref>標籤，請問您要放在句點前還是句點後？其實都行，因為是習慣問題。--Z7504非常建議必要時多關注評選（留言） 2023年1月30日 (一) 19:29 (UTC)
(＝)中立，习惯问题。个人偏好不加句号，主要我觉得图片下面的字无论是短语还是句子，放在文字旁都是补充内容，就好比是文本中括号内的内容。--Evesiesta🇩🇪❤️🇺🇦 2023年2月5日 (日) 09:39 (UTC)
@Evesiesta：一个句子不加句号没有问题，毕竟去掉句号就是短语。关键是复数句子只有最后一句不加句号。就算是文本中的括号内容，里面如果有多个句子，最后一个句子不以标点收束还是很奇怪。--洛普利寧 2023年2月6日 (一) 14:41 (UTC)
(？)疑問：為什麼要在圖片的說明文字區域裡面寫落落長的文章，導致需要討論文章結尾要不要用句號？--Anghualee（留言） 2023年2月8日 (三) 17:02 (UTC)
@Anghualee：不一定构成文章，但有时一句话不够用。以此条目正文图片为例。第一句话描述图片本身内容，第二句话呼应正文「長槍剋劍，劍剋斧，斧剋長槍」（WP:NFCC#8，版权图片应有助正文理解）。这用一句话可能不好表述。--洛普利寧 2023年2月9日 (四) 14:09 (UTC)
也就是說因為除了"遊戲的戰鬥畫面"這幾個字以外的正文需要圖片來達成你所謂的WP:NFCC#8，結果把正文放到圖片說明文字區域裡面。所以我問啊，你到底是為了有助正文理解加圖片（正文擺在正文，圖片擺在圖片，圖片底下說明文字寫"遊戲的戰鬥畫面"），還是加了圖片後為了理解寫了落落長的文章解釋圖片（正文刪掉，圖片擺上去以後，把落落長的正文塞進去）。很明顯前面是你所謂的WP:NFCC#8，後面不是。--Anghualee（留言） 2023年2月9日 (四) 23:51 (UTC)
再來我們講圖片理解這件事情，請問一下那張圖哪邊看出槍剋制劍？你當然會說名字左邊是武器，在有武器剋制的情況下，武器右下角有箭頭，箭頭代表了武器的剋制。Ok，拜託不要把上面那段加到已經落落長的說明文字裡面了。我問啊，為什麼不在圖片上面的武器畫一個圈，加一條線拉出去到旁邊，寫"武器圖示：劍"，在箭頭上面畫一個圈，加一條線拉出去到旁邊，寫"武器克制示意"，這樣圖片裡面指示清楚了，這個是劍，這個是箭頭。然後圖片說明文字就打武器克制示意圖（槍剋劍），不就好了？我為什麼需要知道右邊是羅伊啊？圖片右上角沒有嗎？--Anghualee（留言） 2023年2月10日 (五) 00:12 (UTC)
首先这是张游戏截图是版权图片。自行在上面加圆圈箭头修改是不合适的，换用盗版汉化版截图也是不合适的。而且这里是中文维基百科，应当假定读者只会中文。所以读者当然不知道「ロイ」是罗伊。
其次NFCC限制版权图片数量，而游戏条目一般只能放一张截图。配图的机会珍贵，所以应该选一张具有代表性的图片。如果只是为了展示战斗画面，那完全可以传上传一张枪对枪不互克的截图。既然选了一张存在武器互克的截图来展示，当然应该用文字描述细节，让读者看懂你想表达的内容。（要不您不看图片描述和相关条目，猜一下这张图片想说什么？）
最后你问图片第二句话为什么不放到正文。因为这句话就是描述这张图片的，而不是正文的一部分（对正文太过琐碎）。如果条目不放图片，或者换成对话界面的截图，这句话自然不会出现。--洛普利寧 2023年2月10日 (五) 04:56 (UTC)
著作權我本來是不想討論的，因為那個是另外一個問題。畢竟圖片來源是 http://www.hardcoregaming101.net/，你確定該網站有"擁有使用CC-BY-SA協定釋放該內容的授權／是該內容的原始作者"其中一種嗎？再來你提到 NFCC，NFCC十點是必須全部符合的，第十點的 abc 都齊備了嗎？
其次如果覺得圖像版權是你很關注的問題，可以完全採用 Mock 的方式從白紙開始，框出各個區域以文字描述這是狀態欄，除非你能主張連遊戲畫面中的區塊分佈都具備著作權，否則 NFCC 第一點應該有跟你說如果可以用自由材料加以替代。
我前面就說過了，除了"遊戲的戰鬥畫面"這幾個字以外，不是該丟到正文，就是瑣碎資訊。所以你拿這是中文維基百科云云，我是真的覺得，那你怎麼不把 DMG、Rapier 都解釋了咧。如果這些可以不用因為這裡是中文維基百科而提供相應的中文說明，那羅伊就不用。就我的認知而言，圖片的說明文字放"遊戲的戰鬥畫面"就好了。
至於你列出來的"這張圖片"，以我來講這像是一個勇者鬥惡龍類型的戰鬥畫面，就我認知上來說跟非遊戲玩家的一般人展示時（如果有人還記得我們應該要這樣做的話），圖片的說明文字放"戰鬥畫面"就好，我不會去介紹說這是什麼怪物、為什麼隊伍是三個人、PP是什麼、接下來戰鬥可能會有畫面抖動（或許吧）。
我也不喜歡拿英文維基百科舉例，畢竟這邊是中文維基百科。不過你要不要想看看為啥英語維基百科就是一句"A battle between two units in The Binding Blade."就解決了？--Anghualee（留言） 2023年2月14日 (二) 02:54 (UTC)
圖片來源是http://www.hardcoregaming101.net/沒有問題。遊戲截圖可以上傳者自己截，也可以別人（比如hardcoregaming101.net）截好我直接上傳。很顯然這張圖片不是以「CC-BY-SA」協議授權的（否則會傳到c站而不是這裏）。然後看NFCC#10：a) 圖像說明頁已經表明版權屬於Intelligent Systems和Nintendo；b) 版權標籤是{{Non-free game screenshot}}，文檔說明頁已經放置；c) 哪篇条目使用这张图片需要指明，这点文档也清楚地链接了火焰之紋章 封印之劍条目。
我想說明由於版權問題，遊戲截圖只能使用一張，而不能像Wikia通过大量图片来总结归纳。所以我需要通过文字發揮圖片最大的效用。正文沒說DMG所以我圖片沒解釋DMG，正文沒說Rapier所以我只說成劍而非刺劍，正文有說羅伊所以我圖片有說羅伊，正文有說伯爾尼所以我有說伯爾尼兵，正文強調武器互克所以我專門才用一句話來輔助說明。另外正文不是我寫的，圖片也不是我傳的。我只是根據正文的介紹，幫助圖片發揮更大的作用。我认为图片的一个核心价值是表现了枪克剑；而在陈述清楚这点的基础上，文字当然短一些比较好。如果读者都懂日文，那图注确实可以压缩成一句话；但这里是中文维基百科，読者は日本語がわかりません，我只能用多一些的文字说明左边的角色拿枪、右边的角色持剑。当然，确实我语文能力有限，没有想到更短的介绍文字。
關於英維的圖片用途您猜的對，就是爲了說明勇者鬥惡龍類型的戰鬥畫面。這個討論我注意到了一點，您懂的東西太多了。比如「ロイ」您假設讀者是會讀的，所以認爲標註羅伊多餘。這張圖片您也能猜到上傳者的意思，您可能認爲英維圖註第二句話也多餘。但是對於沒玩過勇者鬥惡龍的讀者，他們不會立刻往這方面想。能用文字說明白的東西，就不要让讀者去猜謎。而且就像您說的，說不定人家還猜你就想強調「DQ是4人隊伍、Mother是3人隊伍」。
英文維基百科只写「A battle between two units in The Binding Blade」的做法我認爲不夠好，没有完全发挥图片的价值。而且中文版圖片原來也只有這樣的描述，第二句是我加的。而且图片还应该有替代文字，英文版懒得写，中文版也懒得写。当然，这是通病。
最後回到正題。如en:Mother_(video_game)#Gameplay所見，有复数句话的图注释确实是存在的。--洛普利寧 2023年2月14日 (二) 14:25 (UTC)
@Anghualee：另外和您相反，我倾向再用一句话表明我传图片的目的，并尽可能和正文呼应起来。比如最近的火焰之紋章 Engage我就没传任何截图，因为我想传一个同时表现纹章士和Break的战斗截图，但没找到合适的图片；而信息框的图注可以和正文「遊戲視覺形象圖以琉爾為中心繪製」相呼应。其他游戏条目参选优良时，我也提过图注太简单的意见。如果您有想法，欢迎到PJT:VG讨论；毕竟现在关注图注编写的人还是很少的。当然，图注写法对本讨论来说就是离题了。--洛普利寧 2023年2月14日 (二) 14:49 (UTC)
關於"英維圖註第二句話也多餘"這件事情我簡單講一下，他是兩張圖片用一個圖片描述的方式描述，固定句型就是"左圖為XXX，右圖為XXX。圖片描述"（當然也可以右圖為XXX，左圖為XXX。左右先後看撰者習慣，至少我沒特別學過有對左右先後的相關規範）。就這樣。--Anghualee（留言） 2023年3月1日 (三) 13:11 (UTC)
这里有一篇文章对这个问题做了解释，供各位参考。--InstantNull（留言） 2023年2月9日 (四) 18:51 (UTC)
@Lopullinen：似乎有初步共識，可以考慮繼續推進。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年2月24日 (五) 01:52 (UTC)

Wikipedia:格式手册/标点符号#书名号新增使用Template:《的方法，修改使用代码的方法，并调整“效果为”的位置

最新留言：在1年前发布12条留言7人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年3月20日 (一) 16:14 (UTC)。

現行條文
维基百科提供了两种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下两种方法解决，而不应单純替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。
  1. 使用模板：
    • {{单双书号转换|需转换的作品名}}
    • {{引书号转换|需转换的作品名}}
    效果为：
    • 《需转换的作品名》
    • “需转换的作品名”
  2. 使用代码：
    • -{zh-hans:《;zh-hant:〈;}-需转换的作品名-{zh-hans:》;zh-hant:〉;}-
    • -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}-
    效果为：
    • 《需转换的作品名》
    • “需转换的作品名”
提議條文
维基百科提供了三种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下三种方法解决，而不应单純替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。
  1. 使用模板：
    • {{单双书号转换|需转换的作品名}}
    效果为：
    《需转换的作品名》
    • {{引书号转换|需转换的作品名}}
    效果为：
    “需转换的作品名”
  2. 使用模板：
    • {{《}}需转换的作品名{{》}}或{{〈}}需转换的作品名{{〉}}
    效果均为：
    • 《需转换的作品名》
  3. 使用代码：
    • -{zh-hans:《;zh-tw:〈;zh-hk:《;}-需转换的作品名-{zh-hans:》;zh-tw:〉;zh-hk:》;}-
    效果为：
    《需转换的作品名》
    • -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}-
    效果为：
    “需转换的作品名”
  1. 新增Template:《的方法，参见Template:《。
  2. 修改zh-hans:《;zh-hant:〈;为zh-hans:《;zh-tw:〈;zh-hk:《;，否则在香港繁体下，模板的结果和代码的结果不一致。
  3. 调整“效果为”的位置。
    ——小林子冲（留言） 2023年2月21日 (二) 05:28 (UTC)
三种方法本质都是一样的，只是代码实现上有所不同。对于格式手册写这么长太啰嗦了。直接写成下面这样就好：
{{《}}需转换的作品名{{》}}、{{〈}}需转换的作品名{{〉}}或{{单双书号转换|需转换的作品名}}
PS：另外还有一种方法是把双书名号改成单书名号，然后加入{{NoteTA|1=zh-cn:《;zh-tw:〈;zh-hk:《;}}。好像音乐类条目有这样的操作。--洛普利寧 2023年2月21日 (二) 13:54 (UTC)

(＆)建議：格式手册确实应修订部分条文，使站内的顿号用法得以规范化。可将以下代码加入手册供编者複製粘贴，在转换书名号的同时消除大陆简体模式下多餘的顿号： 

{{NoteTA
|1 = 〈=>zh-tw:〈; 〈=>zh-hk:《; 〈=>zh-cn:《; <!-- 中国大陆仅在双书名号之内使用单书名号 -->
|2 = 〉=>zh-tw:〉; 〉=>zh-hk:》; 〉=>zh-cn:》;
|3 = zh-tw:〉、〈; zh-hk:》、《; zh-hans:》、《; zh-cn:》《; <!-- 依中国大陆现行规范用法，书名号之间不加顿号 -->
|4 = zh-hant:》、《; zh-hans:》、《; zh-cn:》《;
|5 = zh-hant:」、「; zh-hans:”、“; zh-cn:”“; <!-- 依中国大陆现行规范用法，引号之间不加顿号 -->
}}

当然，更好的处理方式是将後三条转换规则加入全局转换。如遇特殊的例外情况，确需在标有引号或书名号的并列成分之间显示顿号，可手动添加-{}-以包含顿号。鑒於这种例外情况极其少见，故在此提议加入全局转换。--蕭漫（留言） 2023年3月1日 (三) 22:06 (UTC)

(－)反对蕭漫的提議，上次討論確認不強制規定書名號及引號間用不用頓號才不過一個月不要立刻重提，不解決該討論的有效反對意見則不應通過此項。--路西法人 2023年3月2日 (四) 03:07 (UTC)
上次反對的是直接兩岸三地都將之視為標準吧，但沒有反對在大陸使用此方案啊。--Ghren🐦🕓 2023年3月2日 (四) 08:11 (UTC)
您可以再讀一次討論，有留言指出雖然被列為標準但僅為新設且民間仍有不認同的聲音。--路西法人 2023年3月2日 (四) 14:43 (UTC)
那个讨论我有看，也有發過言。Y君說的是不推薦也不反對，總之是沒有人明確反對在大陸使用此案就是了。您可以說有人提出在該討論說過該標準在大陸爭議，然後您反對，而不是直接說解決該討論的反對意見。謝謝。Ghren🐦🕚 2023年3月2日 (四) 15:21 (UTC)
YF君原話是可能不應推薦這種寫法，但也無需禁止：「可能不應推薦」仍然是對該案和此案的有效爭議意見。雖該留言未明確對大陸使用此案提出爭議，但也是指出了相關爭議，同樣需要回應。看來只是我們對我們自己說的話以及他人留言的不同理解，無須再爭論這點小事了。--路西法人 2023年3月3日 (五) 10:34 (UTC)
(－)反对。該方案在大陸有爭議，實務上執行者也不多。
唐普.新國標《標點符號用法》并列的引號、書名號間省略頓號規定的問題辨正[J].四川師範大學學報(社會科學版),2022,49(02):199-208.DOI:10.13734/j.cnki.1000-5315.2022.02.023.
[1]張同學.對標點符號用法中一條頓號用法規則的探討[J].傳播與版權,2020(04):22-24.DOI:10.16852/j.cnki.45-1390/g2.2020.04.009.
而且，據張龍的說法，「"《A》《B》和《C》""《A》《B》和《C》（D）"這兩類用法并不違反國標規定,是經濟實用的用法,應該成為頓號省略用法的取向;"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》"這五類用法中的頓號不可或缺。將前述7種用法中的書名號換為引號,亦然。 」（張龍.出版傳播中書名號或引號之間的頓號用法芻議[J].溫州大學學報(社會科學版),2021,34(03):61-66.）
此轉換方式會將"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》形式的頓號過度轉換。--Ghren🐦🕓 2023年3月2日 (四) 08:17 (UTC)
(－)反对，過於混亂的代碼，只會造成更多混亂--SunAfterRain 2023年3月10日 (五) 09:47 (UTC)

“A地－B地关系”是不是该用短横线？

最新留言：在1年前发布15条留言9人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年4月19日 (三) 08:14 (UTC)。

此话题无关“一字线的符号选择”，故另开一节。许多“A地－B地关系”条目标题用的是一字线，方针草案《WP:命名常规 (国际关系)》中谈及有关内容也用的是一字线，但是窃以为应该用短横线。按我对GB/T 15834-2011的理解，连接号只有表示“起止”时才该用一字线，而“A地－B地关系”中的连接号并不表示起止。

中华人民共和国外交部网站上有些类似情况也用了一字线[dash 1]。然而窃以为，国家标准与外交部网站不同的时候，参照前者会更合适，故仍应使用短横线。--爱维基百科的CuSO4 2023年3月14日 (二) 21:19 (UTC)

现MOS:连接号1-4中复合名词用短横线的指引规定似乎已经与WP:命名常规 (国际关系)中的方针部分冲突。之前将国际关系命名常规升为格式指引的提案中已经有编者讨论，但看来毫无进展。@維基百科最忠誠的反對者、Sanmosa、Ericliu1912、虹色分子：故ping曾参与讨论的各位编者，希望能引起重视。--PexEric 💬|📝 2023年3月18日 (六) 12:50 (UTC)
@PexEric(＊)提醒：WP:命名常规 (国际关系)中的方针部分并不涉及连接号。只有“外交代表机构命名”一节是方针，涉及连接号的是其他章节。--爱维基百科的CuSO4 2023年3月19日 (日) 09:21 (UTC)
抱歉，是我眼瞎了。那看来可以直接修正。--PexEric 💬|📝 2023年3月19日 (日) 09:38 (UTC)
但是看起來很怪。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月19日 (日) 09:58 (UTC)
如果你說的短橫線是半形那種我就(－)反对。中文文章就應為美觀起見按全形格式統一用全形標點。--——勿用「進行」污染中文，要言簡意賅。　捍粵者 2023年3月22日 (三) 14:10 (UTC)

这个问题其实很复杂，我在“一字线的符号选择”提案里其实有意回避了这个问题。其实按照中国的旧标准GB/T 15834―1995，这种情况无疑应该使用一字线。在新标准中，这个问题被过度简化成“复合名词”(compound noun)。但按照语义理解这里的双边关系是两个实体名词之间的联系，不能简单看成一个词，英文中用 en dash 而不是 hyphen 连接，表示“A和B的关系”而不是一种“名为A-B的关系”。--InstantNull（留言） 2023年3月20日 (一) 07:51 (UTC)

看了一下GB/T 15834―1995，并没有明确规定不同情况下符号的长短。例中的秦岭－淮河线也可以理解成表示起止，和新标准不矛盾；en:Qinling–Huaihe Line也是用em dash。我认为还是应参新标准用短横线，不知道其他地区是否有类似标准。--PexEric 💬|📝 2023年3月20日 (一) 15:10 (UTC)
U+002D（連字暨減號，-）比半字短，显示效果不好。此外，w3c中短横线推荐的 en dash（U+2013，–）。另像 牛頓-寇次公式感觉换成U+002D也是感觉短。--Kethyga（留言） 2023年3月25日 (六) 08:25 (UTC)
大家，能不能留意一下這裏是中文維基百科，不是“中國大陸維基百科”，中國大陸的那些國標在中國大陸以外的地區統統都不適用，因此為了中國大陸的那些國標有所變化而去動這些旁支末節的東西對於中國大陸以外的人來説毫無意義。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月28日 (二) 12:10 (UTC)
@Sanmosa：真是抱歉！要是一开始我意识到了不要地域中心，就不会提出这个讨论串了。这样常用的方针您提醒之后我才想起来，实在不应该。——爱维基百科的CuSO4 2023年4月3日 (一) 16:30 (UTC)
其實倒也不是這樣。畢竟一個國家或地區的官方標準是很有權威的，也可能成為常用情況，不一定不能適用。只是此處除了考量官方標準，還要考量視覺效果及其他地區使用問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月4日 (二) 08:28 (UTC)
所以不依靠大陸的國標，當其他地區不去定標準的時候，我們也只能依國標啊。而且台灣也有標準啊。--Ghren🐦🕚 2023年4月7日 (五) 15:03 (UTC)
倒也不是這樣説。我的理解是如果一個地區不去定標準的話，那個地區就是沒有標準，他們想用什麽符號就用什麽符號。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年4月9日 (日) 06:09 (UTC)

连接号一字线的符号选择

最新留言：在1年前发布115条留言23人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年6月17日 (六) 16:14 (UTC)。

提议：当前MOS:连接号一字线的符号选择"U+FF0D － FULLWIDTH HYPHEN-MINUS"不是通行的做法。改用 U+2014 — EM DASH 是更好的选择。

之前已经有多次讨论，大部分编辑表示支持，但都没有继续推进：

总结起来：

  1. U+FF0D － FULLWIDTH HYPHEN-MINUS是短横线 U+002D - HYPHEN-MINUS的全形版本，二者应该表达相同的含义，不应重复使用。既然短横线已经选择了 U+002D - ，一字线就应该选用其他字符。
  2. 使用 em dash 对字体渲染有更好的支持。
  3. 使用 em dash 作为连接号是中文印刷品中的主流选择。
  4. 全角连字符U+FF0D － 从未被广泛使用过。（除了中文维基百科）
  5. 多数中文字体对全角连字符的支持并不理想。
  6. 一字线应当恰好占据一个字符（即一个 em 长度）。
  7. 一字线应当恰好是破折号的一半。

因此建议推荐使用 U+2014 — EM DASH 作为一字线的符号，不再把 U+FF0D － FULLWIDTH HYPHEN-MINUS 作为推荐的符号，但也并不将其列为错误用法。

現行條文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“－”（U+FF0D）。中华人民共和国国家标准及中華民國教育部標準中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。

  • 连1：短横线用在：
  1. 化合物名称，如： β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。
  2. 连接号码，如： ISBN 978-0-12-155089-9 。
  3. 表示年月日，如： 2012-12-21。
  4. 连接复合名词，如： 南極-艾托肯盆地、比尔-朗伯定律。
  5. 产品的名称和型号，如： IA-64处理器。
  6. 汉语拼音、外来语内部的分合，如： 玛丽亚·斯克沃多夫斯卡-居里。
  • 连2：一字线可用在：
1. 相关项目的起止。
  • 正确： 法兰克福－巴黎
  • 错误： 法兰克福——巴黎、 法兰克福—巴黎、 法兰克福-巴黎
2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如： 1000－2000年、1－5千克。
提議條文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“—”（U+2014，即破折号的一半）。中华人民共和国国家标准及中華民國教育部標準中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。

  • 连1：短横线用在：
  1. 化合物名称，如： β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。
  2. 连接号码，如： ISBN 978-0-12-155089-9 。
  3. 表示年月日，如： 2012-12-21。
  4. 连接复合名词，如： 南極-艾托肯盆地、比尔-朗伯定律。
  5. 产品的名称和型号，如： IA-64处理器。
  6. 汉语拼音、外来语内部的分合，如： 玛丽亚·斯克沃多夫斯卡-居里。
  • 连2：一字线可用在：
1. 相关项目的起止。
  • 正确： 法兰克福—巴黎
  • 错误： 法兰克福——巴黎、 法兰克福-巴黎
2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如： 1000—2000年、1—5千克。

--InstantNull（留言） 2023年2月8日 (三) 20:15 (UTC)

  1. 不认同字符选择与表达含义间存在关联
  2. 在默认及常见字体中未见明显证据
  3. 部分承认（即便在正规印刷品中，002d也有一定使用，虽然可能是误用）
  4. 承认
  5. 在默认及常见字体中未见明显证据
  6. 在微软雅黑中2014略长于em，反之ff0d未见问题
  7. 未见可靠出处
综上反对提案。--。->>Vocal&Guitar->>留言 2023年2月9日 (四) 02:54 (UTC)
  • 不认同您对 (1) 的意见，Unicode符号本身是具有语义的，形似而不同义的字符都会进行分离，不应混用。en:hyphen和en:dash的用法是不同的；
  • 连接号用U+2014是有权威出处的，如台教标在线网页《重訂標點符號手冊》修訂版。大陆的GB/T 15834-2011虽然公开的是扫描件，不能确定码位，但也明显更像U+2014而不是U+ff0d。
--DvXg 📬 2023年2月9日 (四) 06:55 (UTC)
关于（1）我想不应该有疑问。正如David Xuang所说，Unicode对于每一个字符都有明确的定义。U+FF0D － 是 U+002D - 的全形版本（您可以参考全形和半形了解更多），它们本质上是同一符号的不同字符表示，在中文里同时混用是不恰当的。就如同我们不应该在中文里同时使用半形“/”和全形“／”是一个道理。
 
U+FF0D“－”在 macOS Chrome 下有衬线字体中的显示
关于（2）可以请您参考右侧的截图，U+FF0D － 在 macOS Chrome 浏览器中的显示效果。在正文中的是无衬线字体，在标题中的是有衬线字体，二者差异很大，标题中有衬线的字体显示效果非常不理想。
关于（6），我指一个字符宽即一个em 单位，参见Em (字体排印学)。
关于（7）我想多做一点解释。在英文中 en dash 和 em dash 的关系就类似于中文里的连接号与破折号之间的关系一样。传统上 en dash 的长度就是 em dash 的一半。类似的，中文里破折号既然已经广泛接受用两个em dash “——”表示，那么连接号用一个 em dash 才是符合惯例的。
--InstantNull（留言） 2023年2月9日 (四) 18:37 (UTC)
1. 我关心的是中维常年使用ff0d，现状是否对文章内容的表达产生了歧义？字符的定义在这里并没有特别强调的必要。即便如法兰克福—巴黎变为法兰克福-巴黎也不会产生另一种意义。
2. 我注意到这张截图是2018年，不清楚目前是否仍然有效，我持有的设备（Windows，Android，Ubuntu）上没有发现类似问题。我希望您能多举例以证实“多数中文字体支持不理想”的主张。
6. 建议实测。
7. 您个人的意见我无法评论。另我认同国标推中使用2014，但不认同维基百科需要调整。--。->>Vocal&Guitar->>留言 2023年2月10日 (五) 03:54 (UTC)
可否将您的意见理解为"将错就错"?再比如,我在这行句子中,全部错误地使用了半形标点.但这其实丝毫不影响您理解这段话的意思对吗?
常年使用不是一个合理的理由。本人实际上是推动将MOS:標點符號升格为指引的发起者之一，当时连接号码位选择并没有经过讨论，该错误一直遗留至今。中文维基在发展中必然会遇到需要标准化的需要。方便编辑输入和方便读者阅读、检索是必要的现实需求。甚至有一些读者会将维基百科的格式奉为标准，因此我们有义务提供准确的信息。再者我也提到，新指引只是不再把 U+FF0D 作为推荐的符号，不妨碍兼容已有的使用。
截图中的问题仍然存在。之前提到 U+FF0D 从未被广泛使用过，因此有部分中文字体对 U+FF0D 做了专门的字形设计而另一些没有，使得其在实际的主流字体中没有一致的外观。和您提到微软雅黑的问题一样，这是一个字形（glyph）设计概念。这篇文章中有提到，旧版微软雅黑的标点是过时的且不符合国标。这篇文章介绍了相关背景：“但绝大多数中文字体甚至一些西文字体对 U+2014“—”（Em Dash）的显示效果比西文标点 Em Dash 应有的宽度宽一些，基本符合一字线的形式要求。”
以上内容并非个人观点，我已提供了一些资料供您参考，这基本上是中文字体排版的共识。W3C中文支持文档明确写道：“《标点符号用法》（GB/T 15834—2011）中没有指定这三个符号的码位，但是基本上可以推断一字线是U+2014 EM DASH [—]”。--InstantNull（留言） 2023年2月10日 (五) 07:56 (UTC)
如果现在版本macos依然在em dash后面贸然加这么“长空格”的话，我不排除主动联系苹果官方解决该问题，话说这问题该怎么报告？--Liuxinyu970226（留言） 2023年3月21日 (二) 04:22 (UTC)
( π )题外话：无论一字线用什么符号，美國－墨西哥－加拿大協議按MOS:连接号指引应该用短横线，应移动到“美国-墨西哥-加拿大协议”。——小林子冲（留言） 2023年2月20日 (一) 20:17 (UTC)
我個人亦希望能夠規範連接號之使用。不過必須提醒，根據統計，目前本站至少有三千餘篇條目及其他三千餘個頁面之標題含有「－」（另有四千餘個重新導向，總計一萬出頭），更不用提內文了；因此，若要變更連接號標準，應考慮動用機器人進行移動。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年2月10日 (五) 08:32 (UTC)
是的，所以我其实并不建议将原符号算作错误使用。较好的做法是将标准改正，确保新条目和新文章使用正确标准，并向后兼容，让社区自己逐渐修正。--InstantNull（留言） 2023年2月10日 (五) 17:30 (UTC)
我倒是建議進行一次集中批量移動，一勞永逸。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年2月11日 (六) 10:57 (UTC)
(＋)支持提案。中文维基百科选用U+FF0D作为連接號是奇怪的事情，既不符合任何规范又不便于输入。--Lt2818（留言） 2023年2月10日 (五) 14:06 (UTC)
  囧rz……「一字线可以通过中文输入法输入破折号并删去一半得到」？我想說Windows10的倉頡輸入法並沒有這個功能。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年2月10日 (五) 14:22 (UTC)
倉頡輸入法「ZXAY」會得出一個 Em dash. 谢谢提醒，我已对修订条文做了改动。--InstantNull（留言） 2023年2月10日 (五) 17:44 (UTC)
原则上支持。但我的担心是，如果只是推荐使用U+2014，而不将U+FF0D视为错误，那会造成两者同时存在的混乱局面，还有可能导致一些编辑争议出现。但另一方面，如果要禁止U+FF0D，那修正目前条目中现有的大量U+FF0D感觉是一项不小的工程。当然可以用机器人处理，但也需要注意不应误伤，比如参考文献的标题如果原本用的就是U+FF0D的话我想不应该去修正？还有一些有关Unicode、字体排版等条目中也有确需使用U+FF0D的情况。--Stevenliuyi（留言） 2023年2月11日 (六) 18:45 (UTC)
為了避免新舊共存引發混亂，我個人建議對現有頁面進行一次集中批量移動。至於正文，可能需要研發小工具專門更改連接號，加快速度。參考資料的話更是一團亂，可能有本來就用這符號的，也可能有後來被改的，沒有辦法用機器人處理，只能比照正文，並研發小工具加速更改。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年2月12日 (日) 07:05 (UTC)
Wikipedia:格式手册/标点符号是不适用于参考文献的哈。--InstantNull（留言） 2023年2月13日 (一) 01:25 (UTC)
(？)疑問：有没有办法追踪有人有意或者无意地使用汉字“一”（壹）代替连接号“—”（U+2014），有些系统中汉字“一”和连接号肉眼区分不出来。快捷输入的问题，个人的方法是不少输入法（包括PC、手机）会提供自定义短语，比如设置成“一字线”的拼音或者其他码表，快捷输入应该问题不大。--Kethyga（留言） 2023年2月15日 (三) 11:17 (UTC)
在本人手机上U+FF0D的显示效果比PC网页上号。--Kethyga（留言） 2023年3月2日 (四) 06:20 (UTC)
它之所以叫“一字线”是有原因的哈哈。甚至可以说这是U+FF0D“－”的另一个问题：它太短了，和短横线太像而太不像“一”字了。故意用相近字形的字符替换不是 em dash 所特有的问题，正如同我们没有办法故意检测有人故意用数字0去替换字母O一样。在很多软件里也有自动替换功能，比如在Word里输入“--”会被自动替换成em dash--InstantNull（留言） 2023年2月16日 (四) 05:56 (UTC)
[0-9a-zA-z]一[0-9a-zA-z]这种情况也许是可以加入过滤器的（应该不会有假阳性），就是涵盖的范围可能还不是很够。--DvXg 📬 2023年2月17日 (五) 11:45 (UTC)
(＋)强烈支持。之前的讨论没有继续推进着实可惜，希望这次能一劳永逸解决中维连接号问题。--PexEric 💬|📝 2023年2月18日 (六) 08:48 (UTC)
(＋)支持：使用全角的连字暨减号（“－”，U+FF0D）作为“一字线”或“连接号”的确不是常用的做法。Em Dash（“—”，U+2014）在简体中文下是破折号的一半，输入起来很方便。
在大陆，中华人民共和国国家标准规定了一字线的符号（[6]），看起来有点像Em Dash，而不是全角的连字暨减号（连字暨减号看起来更短）。不过这是一个PDF文档，难以确定到底用的是哪一种。
在台湾，连接号条目里说了“台湾教育部《重订标点符号手册》修订版使用em dash作连接号。”
综合上述各地情况，支持将格式手册的连接号改为Em Dash（“—”，U+2014）。——小林子冲（留言） 2023年2月20日 (一) 20:06 (UTC)
(？)疑問：英维那边使用的连接号为 en dash（“–”，U+2013），而本地的 cite 系列引文模板自英维引进，其中用於连接页码的也是该符号，因此在站内有着大量用例。在本人的设备上看来，连字暨减号“－”（U+FF0D）太短，视觉效果很差，而 em dash“—”（U+2014）又显得过长了，超出了一个汉字的宽度。考虑到连接号最常使用的地方是在数字之间，故其长度如能与数字的宽度相仿理应看着最舒适。使用比汉字还宽的 em dash（U+2014）来连接数字，视觉效果似乎略显累赘。总之，这两个符号看上去都不如长度适中的 en dash（U+2013）美观，所以我们为什么不效仿英维，以 en dash 作为首选连接号？这样一来既能确保美观，又能与引文页码中的连接号保持一致。虽然参考文献使用的符号不必与正文相同，但如能使整篇条目中的连接号整齐划一，未尝不是更好的选择。--蕭漫（留言） 2023年3月1日 (三) 23:19 (UTC)
这里所有的讨论只针对内文和标题，不适用于文献引用。文献引用有另外单独的格式标准。维基百科:格式手册/标点符号第一段最后一句也说明了这一情况。--InstantNull（留言） 2023年3月2日 (四) 03:26 (UTC)
en dash未在《重訂標點符號手冊》修訂版--連接號中出现。em dash同时切合海峡两岸的规范，《重訂標點符號手冊》称为甲式連接號，GB/T 15834—2011称为一字线。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)
  公示7日。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)
我取消了提案中对“中华人民共和国国家标准及中華民國教育部標準中”字样的删除。提案人未解释删除原因，且【浪纹线“～”可与一字线通用】的陈述不见得在标准外普遍适用。--Lt2818（留言） 2023年3月12日 (日) 05:14 (UTC)
針對目前「－」廣泛使用之情況，應該要有些許過渡規定。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月12日 (日) 09:04 (UTC)
我觉得既然「往者不可谏，来者犹可追」，是否应该设立过滤器处理来者的问题。----Cat on Mars 2023年3月12日 (日) 12:02 (UTC)
過渡需要改模板（如Template:Bd）、移动页面（机器人或JavaScript可以完成）等，应该无需多数用户参与。设立过滤器我认为不必，易带来叨扰和沮丧感，弊大于利。用户习惯可以慢慢改。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)
我建議在公示期間，一併整理需要進行之善後措施。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月13日 (一) 14:00 (UTC)
我对一字线与破折号形式之间的关系说明做了微调。--InstantNull（留言） 2023年3月19日 (日) 08:40 (UTC)
  • 又是什麼鬼提案？顯然這個獨裁社群完全沒人考慮過比如Wikipedia:典范条目/列表、Wikipedia:特色列表/列表和Wikipedia:优良条目/列表運用在首頁的問題，然後就在公示了？講真的實在很不想說，但如果說了是不是跟沒說一樣硬是要強行通過？似乎仍舊沒有進步。─都早用習慣了，如果通過，是要全部替換嗎？看著辦吧，如果此提案過了，以後只會更少人願意寫維基百科，因為連個編輯方式都在管東管西的，完全失去所謂的維基百科本質：「自由的百科全書」。--Z7504非常建議必要時多關注評選（留言） 2023年3月12日 (日) 16:48 (UTC)
    首先我建议这位编辑 stop crying. 您这样将您不喜欢的提案怪罪于社群无助于解决任何问题。本提案自提出已有一月有余，大部分编辑表示支持，对部分异议我也做出了解释和调整。且有关议题在过去几年已经多次做了充分讨论，过往的意见也多数表示支持。整个过程公开透明，哪里“独裁”？何来“强行通过”？您有反对意见可以提出，社群欢迎建设性讨论，但哭闹不会使您的观点更具有说服力，错误的习惯也仍然是错误。--InstantNull（留言） 2023年3月13日 (一) 04:53 (UTC)
    就別在那邊自欺欺人了吧。獨裁就是獨裁，還說沒有說服力？這個可悲的獨裁社群意思就是說現在要把─全部強制換成U+2014嗎？到底是誰才沒邏輯啊？可悲獨裁社群，既然要通過提案就過啊，反正說了真的跟沒說一樣，只愛強行通過的獨裁社群。哪還需要公示？公示真的只是形式而已。也不會有人每天會願意為了這一槓吵，但是此種作法只會減少編輯者意願。啊本來維基百科就已經對新手很不友好了，再過這種鬼提案以後真的沒人要寫維基百科了。以後的新條目也會很難寫出來，因為都被前面的人寫完了，以前也講過很多次了。請問維基百科哪裡還稱得上是「別傷害新手」之說？而且維基百科還有多種條目是以比如「A國─B國關係」命名的，要不要全部條目名稱都改為「A國U+2014B國關係」？如果不要改，那就最好全部重定向處理。這提案當然是鬼提案啊。--Z7504非常建議必要時多關注評選（留言） 2023年3月13日 (一) 11:25 (UTC)
    Wikipedia:典范条目/列表等三个页面中的U+FF0D不是连接号用例，自然不受影响。─（U+2500）与本提案没有关联。维基百科的自由体现在多个方面，但格式并非其一。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)
    并非格式不能自由，而是既然我们已经在格式方面达成共识了，并且格式手册长期以来就有一致性的格式要求，那么大家应该遵守共识，维护共识，积极创造条件以更好维护原本的共识，共识才是约束的条件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)
    那請問像是「{{lang-en}}」是要強迫用戶都改成使用「{{langU+2014en}}」才甘願嗎？這種鬼提案到底是誰想的也不動動腦筋，想當然只好(－)強烈反对啊。難道還要舉例嗎？獨裁的爛社群。--Z7504非常建議必要時多關注評選（留言） 2023年3月18日 (六) 10:39 (UTC)
    ？？？—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月19日 (日) 05:22 (UTC)
    當否人的言論蠢到你懷疑是不是反串。你該不會認為「-{}-」和「<!---->」也要改吧？ --窝法乙烷 儿法梦碎 2023年3月19日 (日) 14:11 (UTC)
    獨裁社群果不其然硬是通過討論，而且已經明確指出問題了還只會裝傻。像這種公示7天只是意思意思走形式流程的獨裁社群，以後寫維基百科的人只會越來越少，因為這嚴重剝奪了編輯者的權益。--Z7504非常建議必要時多關注評選（留言） 2023年3月19日 (日) 16:33 (UTC)
    ？这是问题？模板的-和连接号有关系？--在下荷花，请多指教（欢迎签到） 2023年3月20日 (一) 02:10 (UTC)
    你可能根本没有阅读提案和如上讨论。提案要把U+FF0D改用U+2014，U+2500与本提案毫无关系；提案说的是“一字线”，与短横线en dash也没有关系。你的疑问都有人答复，善后工作也正在展开，装傻好像只有你一人。--PexEric 💬|📝 2023年3月21日 (二) 00:02 (UTC)
格式手册已修改。--Lt2818（留言） 2023年3月19日 (日) 13:49 (UTC)
公告一下其他方针指引的相关修订：Special:Diff/76538378、Special:Diff/76527276/76538520。--Lt2818（留言） 2023年3月27日 (一) 13:03 (UTC)
以及Special:Diff/76562752--InstantNull（留言） 2023年3月29日 (三) 00:51 (UTC)

需要進行之善後措施

应Eric Liu君建议，在此整理需要進行之善後措施。我先列出移动页面的部分，用机器人或JavaScript完成比较适合。

U+FF0D作为连接号出现在大量标题中，这些需要移动到U+2014（em dash）的名称。移动应留重定向，以避免破坏内外链接。根据页面性质及行动方式的不同，我分了三个类别，下面的链接是用Quarry查询得到的页面列表：

移动完成后，模板内指向被移动页面的链接会被重定向，这是个小问题。

--Lt2818（留言） 2023年3月13日 (一) 15:29 (UTC)

模板部分似乎亦單獨列出為宜？—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月14日 (二) 06:18 (UTC)
模板内U+FF0D内链--Lt2818（留言） 2023年3月14日 (二) 13:33 (UTC)
Lt2818（我的意思是模板標題）—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月20日 (一) 01:30 (UTC)
上方“受影响项目页”链接中命名空间编号为10的就是模板。（似乎单独列出的必要性不大？）--Lt2818（留言） 2023年3月20日 (一) 13:36 (UTC)
U+2500影响的页面也有40个，可一并处理。--PexEric 💬|📝 2023年3月19日 (日) 10:53 (UTC)
PexEric還有沒有其他類似的符號？可以考慮一併列出。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月20日 (一) 01:30 (UTC)
连接号#相關符号和破折号#電腦應用已经列的很详细了，加上制表符里的U+2500，还有汉字“一”[開玩笑的]。--PexEric 💬|📝 2023年3月20日 (一) 14:31 (UTC)
(～)補充：还有连字号#字元編碼，以及U+2212的减号。看了一下，quarry:query/72451，只有几个重定向把减号当作连接号，处理紧迫性不高。--PexEric 💬|📝 2023年3月20日 (一) 14:46 (UTC)
发现其中有不少页面应该是用短横线的。建议不要用机器人全自动移动，而是在判断正确的符号后再行处理。
个人体会：中文中的连接号不一定和英文对应。英文同样是en dash，中文可以是短横线（比尔-朗伯定律，格式手册中的例子）或一字线（伏爾加—波羅的海水路，表起止）。--Lt2818（留言） 2023年3月20日 (一) 13:36 (UTC)
机器人可以只批量修正U+FF0D到U+2014（em dash），U+002D（en dash）本来就不用管；U+2500是制表符，用作页面名是错误用例。--PexEric 💬|📝 2023年3月20日 (一) 14:22 (UTC)
我的意思是，许多现有的U+FF0D标题应换用短横线“-”（U+002D），批量改为em dash“—”（U+2014）未必合宜。我昨天移动的丹寧-藤川彗星就是个例子。--Lt2818（留言） 2023年3月20日 (一) 15:15 (UTC)
可以考慮匯入站內頁面，手動清查，由機器人更新剩餘清單；並可以考慮另設排程移動頁面，就是把頁面放到那裡去機器人就會幫忙移動之類的。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月21日 (二) 10:22 (UTC)
另外，對於部分罕用或常遭誤用之連接號，甚至可以直接列出包含正文在內所有使用案例，以便社群協助修正。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月26日 (日) 16:58 (UTC)
應該儘快推動頁面移動，尤其在國際關係專題，連接號使用已經造成一些混亂了。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月27日 (一) 08:29 (UTC)
目前我已經處理多數條目。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月5日 (三) 13:53 (UTC)
(＆)建議：本提案所涉及内容仅包含修改U+FF0D到U+2014，要避免过度延展、放大讨论范畴。若需要机器人批量修正，那么就专注于清理U+FF0D。具体争议案例或专题需要社区解决的，交给社区另立专案讨论，逐步修改。--InstantNull（留言） 2023年3月29日 (三) 00:31 (UTC)

(？)疑問 我發現列表中有許多0000－0000年的例子。我記得之前有許多條目名稱與內文都採用了與英文相同，表示數字範疇的U+2013 – EN DASH。若要統一處理的話，是否應該改成U+2013 – 而非U+2014 — ？否則改過之後仍然不一致，不過是徒增混亂罷了。就算中文的部分要全部改U+2014 — ，對於中英交雜的情況（例如2015－16克里夫蘭騎士賽季這個標題？）該如何處理？ --Kanashimi（留言） 2023年4月8日 (六) 10:33 (UTC)

這個標題似乎没有中英交雜的情况？年份可以视作中文吧。--Lt2818（留言） 2023年4月9日 (日) 09:02 (UTC)
我的意思是應該考慮到中英文交雜的情況，就現在看來似乎沒規範到這部分？另外就上面所提到的，許多年份已經採用 en dash，這個部分是否該統一？--Kanashimi（留言） 2023年4月11日 (二) 10:09 (UTC)
我认为这不能算作中英混杂的情况。首先赛季是一个代码或序列号吗？个人认为不是，NBA也没有硬性规定。其次明白英语维基的格式是怎么来的，英语维基格式手册建议时间跨度使用2022–2023的形式，特殊情况下相邻两年可省略写作2022–23。按照使用中文原则，英文 en dash 即对应中文连接号 em dash（hyphen 对应短横线，英文 em dash 对应破折号——）。中文里并没有 en dash 这个符号，日常生活中它常被U+002D - 替代。同样，日常生活中人们也常用U+002D - 替代U+2014 — ，所以你能找到大量使用短横线的参考来源，但从规范化的角度考虑，个人认为较为合理的命名应该是NBA 2022—2023赛季或者2022—2023 NBA赛季，以及克里夫蘭騎士2015—2016赛季等等。而在模板或表格中，如果受到空间限制，我支持使用U+002D - 替代并省略相同的两位年份，例如2022-23赛季。
以上。希望有帮助。--InstantNull（留言） 2023年4月11日 (二) 12:49 (UTC)
個人向來反對沿襲西方常用之省略年份形式，並認為合理之命名格式為完整的「2022年—2023年」（前一個年可以省略，但後面不行，因為英文中「2023」的中文翻譯是「2023年」）。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月11日 (二) 13:34 (UTC)
个人倒是认为上面例子里“年”可以或者应该省略，因为“赛季”本身已经包含了年的含义了，加上反而可能有语义重复的嫌疑。--InstantNull（留言） 2023年4月13日 (四) 12:07 (UTC)
像1889–1890年流感大流行這種條目要一併處理嗎?--Kanashimi（留言） 2023年4月11日 (二) 22:54 (UTC)
应使用em dash，已移动。--Lt2818（留言） 2023年4月12日 (三) 05:20 (UTC)
名称中有en dash的页面。因为跟本次格式手册调整关联不大，我自己就先不处理了。--Lt2818（留言） 2023年4月12日 (三) 05:31 (UTC)
我的意思就是這樣的頁面滿多的，搞不好比現在使用em dash的還多？那麼這樣會不會有紊亂的情況？畢竟本次提案的初衷之一也是為了避免紊亂。我個人在數字範圍的情況下其實比較偏好en dash，再怎麼說我們不是用中文數字，em dash實在太長了...--Kanashimi（留言） 2023年4月12日 (三) 06:54 (UTC)
但规范如此，没办法。《重訂標點符號手冊》的例句中就有“西元1811—1872年”。--Lt2818（留言） 2023年4月12日 (三) 07:21 (UTC)
我看了一下《重訂標點符號手冊》修訂版連接號，發現大概因為使用的字體不同，標楷體看起來還好，細明體就有點突兀。或許我們能問問教育部看看他們有無定論？--Kanashimi（留言） 2023年4月12日 (三) 07:33 (UTC)
不知是何话题的定论？如果是em dash与en dash之别的话，后者不满足《重訂標點符號手冊》中“占一個字的位置”的要求。特定字體中字形突兀应该是小问题。--Lt2818（留言） 2023年4月12日 (三) 14:24 (UTC)

(？)疑問：所以機器人有在清理導航模板的內部連結嗎 ? 大量移動造成大量內連重定向，靠人手不可能全部清理，難道等到全部移動才着手清理模板的內部連結重定向嗎 ?--約翰同志－條目裱糊匠（留言） 2023年4月13日 (四) 20:02 (UTC)

這個部分有清單的話我可以做,只不過想問問必要性.--Kanashimi（留言） 2023年4月13日 (四) 23:01 (UTC)
@kanashimi：格式手冊/連結中「模板中的內部連結」：「目標為本頁面的内部链接會顯示為加粗無連結黑色正文。常見于模板調用中：如果模板A中有頁面B的連結，而頁面B又調用了模板A，那在頁面B的頁面上模板A處頁面B的链接會顯示為無連結文字；然而，若是頁面B重定向至頁面C，而頁面C中調用了模板A，而模板A中原應是C的連結處寫的是B，則B仍會是内部链接的樣子。系統在作出此判定的時候不會自動轉換繁簡，因此有時候要手動轉換模板頁內連結的文字。」。而且，在維基方針和指引中，好像有提及模板中的內部連結，要和目標原標題一致，不可有重定向。說白了，模板未能在目標頁面顯示加粗無連結黑色正文，導航只是做了一半而已。--以上未簽名的留言由Comrade John（討論｜貢獻）於2023年4月14日 (五) 07:51 (UTC)加入。
我指的是整個搬移作業...不過現在看起來也不需要了。--Kanashimi（留言） 2023年4月16日 (日) 04:43 (UTC)

名称中有U+FF0D的条目基本移动完成。未移动的有这些情况：

--Lt2818（留言） 2023年4月15日 (六) 14:39 (UTC)

@Lt2818：Kanashimi所說的未改為em dash，留有重定向內部連結的模板頁面清單，能不能夠列出來嗎 ?--約翰同志－條目裱糊匠（留言） 2023年4月15日 (六) 16:27 (UTC)
上面已经列出过了，模板内U+FF0D内链。--Lt2818（留言） 2023年4月16日 (日) 02:56 (UTC)
@Comrade John@Lt2818 請檢查機器人在Template:2006年世界盃外圍賽的編輯。若是妥當的話，這邊就會開始作業。多語言模板也需要處理嗎?或者乾脆申請成常態性的任務?--Kanashimi（留言） 2023年4月17日 (一) 22:49 (UTC)
这个编辑没问题。我觉得常態性的任務是不错的想法，页面被移动后在導航模板处的情况是有普遍性的，不只适用于这次的连接号。--Lt2818（留言） 2023年4月18日 (二) 04:14 (UTC)
@kanashimi：編輯沒問題。多語言模板也需要處理，預計編者們知道共識後，所建立的條目標題連接符號都會是em dash，預先處理多語言模板對處理偽藍鏈有利。如果成為常態性任務，清理頻率是幾多天一次 ?--約翰同志－條目裱糊匠（留言） 2023年4月18日 (二) 07:58 (UTC)
如果成為常態性任務，1個禮拜一次應該就夠了。並且作業內容會是對所有模板，不會只有列表中的。--Kanashimi（留言） 2023年4月18日 (二) 08:33 (UTC)
@kanashimi：申請成常態性任務吧，大規模清理後，非使用em dash連接符號的條目標題會呈零星出現狀態，要定期監視清理。--約翰同志－條目裱糊匠（留言） 2023年4月18日 (二) 12:01 (UTC)
多語言模板比較麻煩，我先處理純連結的部分。另外申請成常態任務的部分也得等等。--Kanashimi（留言） 2023年4月22日 (六) 11:21 (UTC)
@Kanashimi：我覺得如果不是在綠連裡面的連結，可能要先檢測一下目標頁面是否真實存在，甚至考慮直接更動連結至實際重新導向之目標。我已經看到好幾個錯誤連結的例子了。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月22日 (六) 12:18 (UTC)
例如說「1947年－1948年中華民國監察委員選舉」現在重新導向至「1947年—1948年監察院監察委員選舉」，不應將其直接改為「1947年—1948年中華民國監察委員選舉」；「阿富汗伊斯蘭酋長國 (1996年－2001年)」現在重新導向至「阿富汗伊斯蘭酋長國」，不應將其直接改為「阿富汗伊斯蘭酋長國 (1996年—2001年)」。此外，非主空間的頁面連結不適用格式手冊（例如不應直接將「維基百科:臺灣－斯洛伐克編輯松」改作「維基百科:臺灣—斯洛伐克編輯松」），也要特別注意，最好是先獨立列出清單，之後由社群檢視並手動處理。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月22日 (六) 12:22 (UTC)
感謝回報錯誤。已暫停作業。照理來說應該檢測重定向標的就好了？--Kanashimi（留言） 2023年4月22日 (六) 12:55 (UTC)

@kanashimi、Ericliu1912：根據我所發現並修復的Cewbot錯誤編輯，有兩類連結如Eric所說，先獨立列出清單，之後由社群檢視並手動處理：

一，原標題變得面目全非的內連重定向，例如「危地馬拉－印尼關係」現在重新導向至「危地馬拉—印度尼西亞關係」；「2014－15年也门政变」現在重新導向至「2014—2015年也門政變」；「印度－爱沙尼亚关系」現在重新導向至「愛沙尼亞—印度關係」。
二，應改為短橫線的內連重定向，例如「克伦斯基－克拉斯诺夫起义」，應改為「克伦斯基-克拉斯诺夫起义」；「馬克斯·馮·博克－波拉赫」，應改為「馬克斯·馮·博克-波拉赫」

Cewbot不懂分別，將內連的橫線一律改為Em dash，結果有部份編輯中部份內連變成紅鏈，影響導航，而且用戶要花額外時間找出並清理紅鏈，費時失事。 所以Cewbot在清理前，要先檢測重定向標的，不是所有內連，換Em dash就可以解決的。--約翰同志－條目裱糊匠（留言） 2023年4月22日 (六) 16:53 (UTC)

Cewbot無法辨識的情況基本都是重新導向目標並非只是原標題中連接號更改後的樣子。若按照Kanashimi君所說，檢測重新導向最終目標頁面，應該能夠解決。另外還有管道連結問題，我不太確定機器人怎麼辨認並清除冗餘的連接號相關管道連結？—— Eric Liu 創造は生命（留言・留名・學生會） 2023年4月22日 (六) 17:09 (UTC)
@Comrade John 感謝幫忙修復錯誤。不曉得現在修復的進度如何？我是不是只要加上檢測重新導向標的功能，再完成剩下的頁面就可以呢？--Kanashimi（留言） 2023年4月22日 (六) 22:42 (UTC)
@kanashimi：我只修復我所監視的頁面，其已全數修復。至於是否加上檢測重新導向標的功能，先加上，然後找一些頁面試行，只談論是否加上，不會知道結果如何。--約翰同志－條目裱糊匠（留言） 2023年4月22日 (六) 22:48 (UTC)
話說同類型的標點比如／、·是不是也要規範一下？這兩個全形符號也不太容易打出來。--owennson（聊天室、獎座櫃） 2023年5月2日 (二) 23:52 (UTC)
间隔号没有争议，·不是全形符号。分隔号目前的规定是半形全形二选其一即可，中国大陆规定用半形，全形更多是日语中的用法。--InstantNull（留言） 2023年5月4日 (四) 05:51 (UTC)
大部分的外國人名都用「·」分隔姓氏和名字，但這個符號太難打出來了，倉頡碼是甚麼我至今也不知道。奇怪的是我在編輯框裡顯示的「·」是全形的，跳出編輯框在正式條目看反而變半形了。而「．」（ZXAE）能不能用？這也是全形符號。「／」全形斜線也只能開倉頡全形直接按斜線打出來，用ZX方法反而打不出來。--owennson（聊天室、獎座櫃） 2023年5月4日 (四) 11:32 (UTC)
Unicode字符有语义，因此形近的符号不能互相混用。「．」是全形英文句号，由於港澳台标点统一置中，常被误認作間隔號，中華民國《重订标点符号手册》修訂版即誤用「．」為間隔號，参见“间隔号#電腦輸入”。--蕭漫（留言） 2023年5月4日 (四) 18:52 (UTC)
我覺得這個例子顯示官方的文件有待商榷、不可盡信，代表上述討論中所引用的根據也有疑義，必須等待官方重新審核過。也就是說搞不好我們提出意見，官方重新審核後，可能會改變。--Kanashimi（留言） 2023年5月4日 (四) 22:15 (UTC)
這跟字型有關係吧，我發現在思源黑體裏面·（U+00B7）與‧（U+2027）都是全形的，而在思源宋體裏面·（U+00B7）是半形的，‧（U+2027）是全形的。--⚞︎★⚟︎ 2023年5月22日 (一) 19:59 (UTC)
我個人認為間隔號應該占滿一格，目前本站使用的間隔號雖然符合相關標準，但顯示上是半形，看著很不舒服。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年5月31日 (三) 04:18 (UTC)
建议更换字体。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年6月6日 (二) 17:48 (UTC)
@魔琴：我在電腦上瀏覽所用之字體為苹方，這是許多電腦之預設字體。除此之外，還有很多字體也這樣顯示。是以遇到上述情況之時，要求使用者自行更換字體顯然不是多麼可行或有效率的辦法。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年6月7日 (三) 02:55 (UTC)
或许知道懂网页设计开发的同学能提供更好的方案，比如在Wikipedia:Wikiplus中间隔号（U+00B7）就显示成一个汉字宽度，另外间隔号在我的电脑上好像不到1/3或1/4个汉字的宽度，见截图。比如知乎上这位说的：“在CSS3中，可以用@font-family的「unicode-range」屬性搭配中文字體來解決這個問題。最近版本的Webkit和IE8都已經支援。” 参见 为什么在有些软件环境下中文里的中圆点（间隔号）是半角的？ - 知乎
还有，在我的电脑上，标题处的一字线感觉明显大于一个汉字。--Kethyga（留言） 2023年6月7日 (三) 09:26 (UTC)
除此之外，还发现一个问题，大陆使用的引号，维基显示上时前半部分后半部分显示一样，可能也是字体的问题，见 CSS unicode-range特定字符使用font-face自定义字体，通常效果可以看一下《标点符号用法》（ GB/T 15834—2011）。感觉可能是维基媒体的中西文字体排版的问题。--Kethyga（留言） 2023年6月7日 (三) 10:21 (UTC)
@Ericliu1912：中国大陆常见的微软雅黑也是半宽。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年6月7日 (三) 11:05 (UTC)
更正：可看K君上方的截图，似乎连半宽都没有…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年6月7日 (三) 11:08 (UTC)
話說目前就連接號而言還有什麼善後措施還沒做麼？—— Eric Liu 創造は生命（留言・留名・學生會） 2023年5月31日 (三) 04:18 (UTC)
条目分类也处理完了。算是告一段落。--Lt2818（留言） 2023年6月1日 (四) 16:32 (UTC)

关于数值比值中的冒号问题

最新留言：在1年前发布46条留言14人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年11月23日 (四) 00:14 (UTC)。

相关讨论见此（尖刀蛏的同行评审讨论），简单地说就是我在各类格式手册（包括MOS:PUNCT、MOS:MATH、MOS:DATENUM）中均没有找到在数值比中应使用全形冒号（形如2：1）或是半形冒号（形如2:1）的相关规定（也有可能是我没找到合适的归类）。如果社群未做规定，可以把比值冒号这个命名规则添加进格式手册。----FradonStar|和而不同是君子 2023年9月14日 (四) 08:15 (UTC)

我能想到有三种方法：
  • 2:1（半角冒号）
  • 2 : 1（半角冒号两旁有一个空格）
  • 2：1（全角冒号）
参考一下，LaTeX是这么写比值的： 。--ItMarki探討人生 2023年9月14日 (四) 09:17 (UTC)
中国大陆常见字体，冒号等符号会设计在一格的左侧，所以全角冒号的2：1看起来像这样「2:  1」。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月14日 (四) 10:58 (UTC)
另外用全角冒号会使比能在冒号后换行，如2：
1 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月14日 (四) 11:02 (UTC)
如果用半形加空格也会有换行的问题吧，比如“2 :
1”。----FradonStar|和而不同是君子 2023年9月14日 (四) 11:34 (UTC)
针对这一疑虑，对于不希望换行的空格，维基有相应的模板（Template:Spaces），或者直接使用 HTML &nbsp; 亦可。--Boreas Sawada 2023年10月22日 (日) 05:31 (UTC)
還有一種寫法是用「比號」U+2236 ∶ RATIO，效果是 2∶1，對比半形冒號是 2:1。語義上可能用該符號較佳，但不清楚是否常用或是否有中文標準，有文章[7]認為「最新的《现代汉语词典》（第7版）在“比例”一词的举例中，明确地使用了两点居中的比号。因此，上述例子中用的两点靠下的冒号，均应改为两点居中的比号。」（LaTeX印象中沒有區分比號和冒號，但在LaTeX中，二元運算符與關係符的空格大小有差異，如
 （將冒號作為二元運算符，接受前後兩個數為輸入，輸出其比值）與
 （冒號預設是關係符）。—— （留言） 2023年9月14日 (四) 11:50 (UTC)
其實可以用Template:Ratio來顯示：{{ratio|4|3}}→4∶3；{{ratio|16|9}}→16∶9。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年9月14日 (四) 12:01 (UTC)
(＋)支持。—— （留言） 2023年9月14日 (四) 12:06 (UTC)
(＋)支持(？)疑問：产生这个问题最开始是因为有编辑对某物种长宽高的比“5.5：1.9：1”当中的冒号有质疑，但英维模板的doc当中说明了这种模板不适合三个数值及以上的比例，有没有办法在{{ratio}}的基础上做出{{ratio|5.5|1.9|1}}可显示的效果呢？--FradonStar|和而不同是君子 2023年9月14日 (四) 13:01 (UTC)
{{ratio|5.5:1.9:1}}→5.5∶1.9∶1 --街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年9月14日 (四) 13:35 (UTC)
了解了，感谢。那我认为这个话题应该可以结束了。----FradonStar|和而不同是君子 2023年9月14日 (四) 15:32 (UTC)

建议在WP:格式手册/标点符号#冒号新增一条：

冒5：表示数学上的“比”时应使用「比號」U+2236 ∶ RATIO，如2∶1。也可以使用模板{{ratio|3:2}}、{{ratio|3|2}}或LaTeX（应该怎么写？）。

 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月22日 (五) 08:59 (UTC)

(＋)支持。----FradonStar|和而不同是君子 2023年9月23日 (六) 01:38 (UTC)
可是在實踐上並不常用，最常用的還是普通冒號「:」。「比號」用起來也挺麻煩。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年9月23日 (六) 06:31 (UTC)
(＋)贊成。或者“宜使用”来避免“麻烦”，但至少应优先用，不过英文等上下文中是否要使用，应该考虑一下。是否类似除号用/还是÷，也是输入问题。--YFdyh000（留言） 2023年9月23日 (六) 06:50 (UTC)
使用「比號」有什麼實際好處嗎？實際上根本沒人會用。 Ghren🐦🕓 2023年9月23日 (六) 08:31 (UTC)
语义不同，外观不同。“1:1:1”丑；“1：1：1”畸形、歧义；“1 : 1 : 1”门槛低但输入和复制也不轻松，等宽和非等宽字体下有差异。1∶1∶1。--YFdyh000（留言） 2023年9月23日 (六) 08:51 (UTC)
那兩個點距離太寬了，搭配數字起來比用冒號還要難看啊。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年9月23日 (六) 12:54 (UTC)
指U+2236太宽吗，我这里看与“1 : 1”是一样的，但两个点偏下而非居中，不确定是否就该如此。等宽下的“1 : 1”反而很宽很丑。--YFdyh000（留言） 2023年9月23日 (六) 13:07 (UTC)
建议新开一个章节，“比号”，因为比号并不属于冒号。可在冒号节加入连接提示。
提議條文

比1：表示数学的比时宜使用「比號」U+2236 ∶ RATIO，不应用冒号。

  •  2∶1
  •  {{ratio|2:1}} 2∶1 或 {{ratio|2|1}} 2∶1
  •  <math>2:1</math>   或 <math>2\mathbin{:}1</math>  
基于魔琴2023年9月22日 (五) 08:59 (UTC)版。——落花有意12138 2023年9月30日 (六) 16:22 (UTC)
宜用比号而非冒号？推荐使用比号，不得用冒号，难道还有什么不推荐但也没被否定的符号…？--洛普利寧 2023年10月2日 (一) 08:51 (UTC)
比如%，成（三成，七成），分数和 之类的。--落花有意12138 2023年10月3日 (二) 02:13 (UTC)
但是我的感觉是，分数表示「比运算的结果」，而不是比本身……可能您的意思是「不应用冒号替代比号」。--洛普利寧 2023年10月3日 (二) 13:16 (UTC)
比號算是冒號的一種吧？似乎不在正式標點符號名單中。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月2日 (一) 09:05 (UTC)
[8]，部分语言下混用，但至少中文应当区分。--YFdyh000（留言） 2023年10月2日 (一) 09:35 (UTC)
(！)意見，其實比號並非正式的中文標點符號，所以我覺得應該規定在Wikipedia:格式手册/日期和数字裏，而不是Wikipedia:格式手册/标点符号，我的提議如下：
提議條文

比值 以阿拉伯數字表示数学的比时，應使用「比號」——「∶」（U+2236 ∶ RATIO），不应用冒号（:或：）；也可以LaTeX表示。若數值以漢字表示，則比值之間應使用漢字「比」，不應混用任何符號。汉字、阿拉伯数字都可使用，但應保持上下文局部體例一致。

  • 正确：4∶3、16∶9、五比二、 
  • 错误：4：3、16:9、五∶二

「比號」可透過{{ratio}}模板取得。

提議條文

另外，注意有一外形相似的「比號」（∶）用於表示比值，其使用法請見Wikipedia:格式手册/日期和数字#比值。

懇請各位參詳。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年10月9日 (一) 18:25 (UTC)
「比號」不常用，可以作為某種推薦，但不應該強制使用。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月10日 (二) 09:23 (UTC)
但“不宜用”的力度太弱。格式指引就应规范用法，且允许常识性例外。或者阐述为“宜用比号字符取代冒号等不规范形式”来推荐和给出理由。--YFdyh000（留言） 2023年10月11日 (三) 06:22 (UTC)
同意在MOS:DATENUM中以推荐用法（而非强制用法）列出。我们也没有禁止用连字暨减号U+002D - HYPHEN-MINUS来代替减号U+2212 − MINUS。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月13日 (五) 09:10 (UTC)
@Cdip150、Ericliu1912、YFdyh000。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月24日 (二) 10:42 (UTC)
在我而言應該不能拿減號來類比，U+002D - HYPHEN-MINUS和U+2212 − MINUS在Unicode的定義上已很明明白白地告訴大家兩個都可以用於減號；但對於冒號U+003A : COLON和比號U+2236 ∶ RATIO，Unicode則沒有採取如此的定義。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年10月28日 (六) 12:55 (UTC)
然。希望Eric君和YF君能就新的讨论给出自己的意见。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月28日 (六) 17:56 (UTC)
不太懂牵扯到减号和需要什么意见。列出推荐做法就好了。--YFdyh000（留言） 2023年10月28日 (六) 18:00 (UTC)
@Ericliu1912：改为“应避免使用冒号”，如何？并非强制，而是说用比号更好；遇到冒号的也能依此句改为比号。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年11月7日 (二) 11:57 (UTC)
@魔琴：現在的情況是這樣，我們應該優先推薦較正確但難用的符號，還是易輸入但不非常正確的符號？即使是英文維基百科，似乎也沒有要求。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年11月7日 (二) 12:52 (UTC)
如果有特殊情况（比如懒）而用冒号的话，应该也不算违反“应避免使用”吧？至于优先推荐，自然应该推荐语义正确的符号吧？不过我又想到读者会不会搜冒号但搜不出来？英维用直引号""而不用弯引号“”似乎有这方面的原因（？） ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年11月7日 (二) 13:47 (UTC)
英維的確一如引號的選擇，傾向使用ASCII符號，比號方面也是：en:MOS:MATHSPECIAL要求用冒號，不用比號。—— （留言） 2023年11月7日 (二) 13:51 (UTC)
英維那套未必值得參考，中維這裏總不能說全形的方引號「」輸入比較麻煩所以不推薦用方引號吧。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年11月8日 (三) 16:00 (UTC)
大概是怕有些人的設備顯示不出來…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年11月8日 (三) 16:14 (UTC)
大部分的電腦或手機能夠打出U+FF1A的「：」或U+003A的「:」，而不是U+2236的「∶」，且U+FF1A的「：」、U+003A的「:」與U+2236的「∶」這3者都很近似，若要說U+2236的「∶」是指冒號 (數學)用法的話，則冒號 (數學)這個標題得要修改--林勇智 2023年11月9日 (四) 14:32 (UTC)
主要是太難打，不符合實際使用，我在此之前也壓根兒不知道有這種符號。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年11月9日 (四) 18:04 (UTC)
我的意見是直接規範用半形冒號當比號就好了，畢竟這算是最常用、最容易輸入的方式。Sanmosa Ινα κραζω σοι 2023年11月10日 (五) 03:28 (UTC)
容易输入为由解决不了格式规范化（各用各的）和用法争议（如:两侧有无空格）。以前的连接号也不容易输入吧。--YFdyh000（留言） 2023年11月10日 (五) 03:42 (UTC)
感覺可比性不高。（中文）維基百科大部分情況下都是用冒號當比號，而大部分冒號當比號的情況下都是用半形冒號，這跟各種連接號常用性相當或無法區分的情況不一樣。“直接規範用半形冒號當比號”如何“解決不了格式規範化”我無法理解，但兩側有沒有空格這點參考enwiki的辦法（兩側沒有空格）即可。Sanmosa Ινα κραζω σοι 2023年11月12日 (日) 23:10 (UTC)
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:格式手册/标点符号/存档3&oldid=80333138”
返回到项目页面“格式手册/标点符号/存档3”。