跳转到内容

英文维基 | 中文维基 | 日文维基 | 草榴社区

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

页面内容不支持其他语言。
维基百科,自由的百科全书

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

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

根据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 作者: 教育部语言文字信息管理司 出版社: 语文出版社

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

今年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)

学术期刊/学报 标题

以目前条目华中科技大学学报(自然科学版)为例,目前的标题是“华中科技大学学报”,但是华中科技大学学报实际上分为医学版(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)

跨年份(度)的體育賽季條目命名

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

--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)

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

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

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

已獲得解答,謝謝大家!只有行動版頁面的破折號會有中間空格的問題,才讓我以為那不是正確的。 --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(PDFHTML)其破折号对应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)

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

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

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

XX系列(遊戲、影視、文藝作品系列)的書名號位置?

請問遊戲、影視、文藝作品系列(的正文,不含條目標題)需要加上書名號嗎?如果要加,「系列」二字該被囊括在書名號之中嗎?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》、《书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是推荐性规范,只作参考,有说“通常不用顿号”但未解释缘由,此时不必照单全收而要考虑原因和场景,不存在“应该不符合大陆的规范”。此事多次被提过(12),不过没有太多人关注,应是无需强制。该规范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)

圖註的結尾的句號

現行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:《的方法,修改使用代码的方法,并调整“效果为”的位置

現行條文
维基百科提供了种方法解决部分书名号使用地区差异,所以遇到部分书名号使用地区差异问题时应用以下种方法解决,而不应单純替换源码的双单书名号,否则会被视为繁简破坏。其中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地关系”是不是该用短横线?

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

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

MOS:连接号1-4中复合名词用短横线的指引规定似乎已经与WP:命名常规 (国际关系)中的方针部分冲突之前将国际关系命名常规升为格式指引的提案中已经有编者讨论,但看来毫无进展。@維基百科最忠誠的反對者SanmosaEricliu1912虹色分子:故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)

连接号一字线的符号选择

提议:当前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. 数值范围。在不引起歧义的情况下,可省略前一数值的单位或附加符号,如:10002000年、15千克
提議條文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为:短横线“-”(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. 数值范围。在不引起歧义的情况下,可省略前一数值的单位或附加符号,如:10002000年、15千克

--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:hyphenen: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/76538378Special: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)

@kanashimiEricliu1912:根據我所發現並修復的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)

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

相关讨论见此(尖刀蛏的同行评审讨论),简单地说就是我在各类格式手册(包括MOS:PUNCTMOS:MATHMOS: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)
@Cdip150Ericliu1912YFdyh000。 ——魔琴 留言 贡献 新手2023计划 ] 2023年10月24日 (二) 10:42 (UTC)
在我而言應該不能拿減號來類比,U+002D - HYPHEN-MINUSU+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)

新增「」模板的用法

原标题为:建议Wikipedia:格式手册/标点符号#书名号新增使用{{}}的方法,修改使用代码的方法,并调整“效果为”的位置

通過:
公示期間無異議,通過。Sanmosa 起視四境 而秦兵又至矣 2024年2月7日 (三) 06:22 (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:《的方法,参见{{}}。此为高风险模板,说明使用频率很高,适合加入格式手册。
  2. zh-hans:《;zh-hant:〈;改为zh-hans:《;zh-tw:〈;zh-hk:《;,否则在香港繁体下,模板的结果和手册提供的代码的结果不一致。
  3. 调整“效果为”的位置,使之更加直观。

——小林子冲留言2024年1月12日 (五) 16:03 (UTC)

(+)支持。 --窝法乙烷 儿法梦碎 2024年1月12日 (五) 18:20 (UTC)
(+)支持 看上去可以。--YFdyh000留言2024年1月12日 (五) 22:43 (UTC)
這低迷的討論量,覺得可以發公告順便公示7天速速解決。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 12:01 (UTC)
(+)支持--Taeas留言2024年1月17日 (三) 13:52 (UTC)
(+)支持加入新模版的資訊。不過老實說新舊條文我都看不懂,我一位編輯者在遇到要輸入書名號時,我該怎麼做?我可以直接依我所屬地區的方式輸入書名號可以嗎?還是說我一定要用模版或加入轉換的代碼?目前手冊的寫法沒有清楚告知我們在什麼情況下應該要做什麼;建議書2和書3應該分開來介紹,而不是一起放在書3下面。--C9mVio9JRy留言2024年1月20日 (六) 23:56 (UTC)
直接输入则其他地区的读者只能看到所输入的形式,可能不符不同地区的用法。调用模板等同字词转换代码,等同不同地区下使用本地区形式。不确定可以不使用,等待了解的人优化。--YFdyh000留言2024年1月21日 (日) 12:52 (UTC)
公用專換庫Music及單雙書名號轉換也能解決到。--Abcet10留言2024年1月21日 (日) 08:28 (UTC)
7日(9日)內無新意見,公示提案7日。Sanmosa Miyamoto Miyoko 2024年1月31日 (三) 05:42 (UTC)

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

示亡號、劍標過去討論

本頁面列出中文維基百科社群對使用示亡号剑标的歷次討論紀錄,以供未來發生編輯爭議時參考。

以上內容本來存於維基百科:格式手冊/標點符號/示亡號。因為相關指引已經通過,改存於此。Ghren🐦🕓 2024年2月7日 (三) 09:24 (UTC)

禁止使用示亡號

下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

示亡號套在已经去世的人的姓名的外面,以示已經逝世。其書寫形式為「   」。示亡號被禁止使用,理由為:

  • 示亡號為用來表示對逝世者的悼念之情的符號[1],以「表现出肃穆庄重的气氛和悼念悲痛的感情色彩」[2]。維基百科為中立的百科全書,不對逝世者持悼念之情。
  • 示亡號只在該人去世一兩年內使用,因為可能還有不少人並不知道他的去世。某人過世已久,則不再加示亡號[1]。使用示亡號不利於維基百科的更新。

另外,示亡號通常標注在逝世者的名字上,又另外有在逝世者下加黑線,逝世者的照片、生平事迹四周加黑框的[1]。不加在逝世日期、統治日期、任期結束日期等地方。

参考資料

  1. ^ 1.0 1.1 1.2 王兴全; 方忠. 现代出版物语言文字使用规范. 成都: 电子科技大学出版社. 2017: 227. ISBN 9787564750831. 
  2. ^ 苏培成. 大家小书 怎样使用标点符号 增订本. 北京: 北京出版社. 2017: 220. ISBN 9787200130164. 

目前維基百科所使用的示亡號並不合學者對示亡號的認識。維基百科對於標點符號的使用理應按照可靠來源而來。因此我提議在WP:格式手冊/標點符號加上以上內容。謝謝。Ghren🐦🕛 2024年1月6日 (六) 04:29 (UTC)

注意有不少模板和条目里面示亡號用于表示任内去世的人物,可以见Special:Search/template:hastemplate:box。--GZWDer留言2024年1月6日 (六) 06:14 (UTC)
「維基百科對於標點符號的使用理應按照可靠來源而來。」又错了……标点符号的使用属于风格指南,没有必要遵循任何可靠来源,而是维基人自己制定(因为风格指南的可靠来源总会是有争议的,遵守一家之言就会触犯另一个)。以英文维基为例,他们的风格指南就不是基于任何已有的可靠来源,而是透过社群讨论产生的,糅合了各种规范,其中不乏歪理(
我个人认为中文维基目前的示亡号用例就非常恰当,一是标记在作品面世前就死亡的贡献人的名字上,二是标记在任内死亡的职务终止日期上,这样的示亡号是中立且有实用语义的,非常有意义。这一传统已在中文维基建立多年且有实际意义,没有明显的需要推翻它的理由。
另如楼上所列,在空间紧要的地方以示亡号来标记任内死亡的人的名字,以几乎不增加文字长度的方式增加了资讯含量,是好事不是坏事。因此切勿更改无需更改的已有传统。我在另一侧的提议只是提醒大家注意示亡号的使用,并无挑战中文维基已有的示亡号传统之意。
且诸多外语维基百科也有用于表示「任内死亡」的标记,如果废除示亡号,那么中文维基就不得不新立新的传统来作类似表示,就是反复造轮子,毫无必要了。
顺附:王兴全、方忠和苏培成皆非知名的汉语言学家,又同为中国大陆人,他们撰写的专著(一次文献)甚至不能够作为中立的可靠来源(WP:V「任何人均可自创网站或自費出书,并借此声称自己是某领域的专家。」),中文维基百科更无必要根据这三个人说了什么来更改多年来养成的在实践中有实际意义的传统 (convention)。--Boreas Sawada 2024年1月6日 (六) 07:18 (UTC)
  • 「糅合了各種規範」:那就是參考可靠來源,再在可靠來源中選取合適的用法。不是不參考可靠來源。
  • 「一是標記在作品面世前就死亡的貢獻人的名字上,二是標記在任內死亡的職務終止日期上」:這是經典的原創研究。即使不考慮原創研究問題,我們使用標點也不應該背離大眾習慣。
  • 「中文維基百科更無必要根據這三個人說了什麼來變更多年來養成的在實踐中有實際意義的傳統」。在中文這樣使用示亡號之前,一早已經形成固定的規範。以上我徵引的著作盡可能用最新的,但早於八十年代,已經有論文指出示亡號的用法是這樣。(王啟明.示亡號  瑣探[J].語言研究,1987(02):49-51.)其他著作、論文對示亡號的說法也大約差不多。是中維變更了中文語境中數十年來養成的規範
  • 蘇培成先生乃是北京大学中文系教授。曾任中国语文现代化学会会长。您的「知名」打算要多知名才算?而且,以上著作都非自費出版的著作。
--Ghren🐦🕓 2024年1月6日 (六) 08:29 (UTC)
「那就是參考可靠來源,再在可靠來源中選取合適的用法。不是不參考可靠來源。」己方不支持的时候就指斥某一观点「原创研究」,己方支持的时候再怪诞无稽的理由都能被拿来用还屹立不倒,这是各语言维基百科的老毛病了(非常重要的提示:没有说您的意思,中维的人总是把话往自己身上想,然后说别人人身攻击,我可是怕了,是为了说接下来的这个例子),以英维的风格指南举例,他们要求引号必须用 straight quotes 不能用 curly quotes, 这在哪个出版界的风格指南里能够找到?!恰恰相反,出版业的共识就是绝对不能用 straight quotes, 必须用 curly quotes 且引号与 prime sign 要区分等等。英维强推 straight quotes 的理由是啥?说(以下为我记住的起码曾经出现过的理由) 1. 人们编辑来编辑去容易出问题(编辑本来就容易出问题,改就是了,还不能改了?而且英维可以给 en dash, em dash 乃至数学比号造出 templates 来方便规范输入,怎么 curly quotes 就不造一个呢,这样不就没有问题了吗?!)2. curly quotes 在早期 IE 浏览器版本上会带来搜索问题(IE 不是早亡了么?而且为了早期 IE 版本的浏览器内页面搜索问题就不用 curly quotes? 那 en dash, em dash 造成的问题怎么不说?)3. straight quotes 在「多数平台」上都更容易输入(更站不住脚了,难输入的东西多了,然而英维那么讲究,往往都会给它们建立 templates 来方便输入,怎么就 curly quotes 遭歧视?!)
如此站不住脚的歪理,竟能屹立 20 年不倒,就是要用 straight quotes, 这时候又有谁敢提可靠来源了?
但是话又说回来,风格指南这种东西,恰恰是很难有对、错或者标准、不标准之分的。就像在英语世界,几乎每家媒体、出版机构都有自己的风格指南一样。甚至,英语世界的风格指南也能做到短短几十年就变化一圈(像是英式英语中缩写是否加点的问题,从和美式英语一样加点到完全不加点也就不到 50 年的时间【当然各个媒体、机构采纳这一变化的时间以及进展过程并不同步】,然后最近英国政府又开始提倡在少数可能造成歧义的缩写上加点了)。因此,中维按照自己的传统制定风格指南没有什么问题,而且也一直是这么做的。
「『一是標記在作品面世前就死亡的貢獻人的名字上,二是標記在任內死亡的職務終止日期上』這是經典的原創研究」,这确实是我的观察。前者(贡献者于作品面世前死亡的,加注示亡号)也是事实上的起码中国大陆地区的出版业(含影视出版)的标准,常见于各种出版物(含影视出版物),后者是中维常见的惯例 (convention), 是对示亡号的功能展扩。这不是我发明的(实际上我从未这样做过),只是我观察到的。我在看到这样使用的时候,就理解为「此人在此日于任内死亡,因此其任期由于其人之死亡而结束」,从未理解为「这一日期死了」并感到疑惑,考虑到我并非智商超群之人,因此推断大多数人都能够正确地理解这一运用。
语言在实际运用中所形成的惯例是很强大的,往往会超越官方或者出版机构所制定的标准,这在一些其他的标点符号或者语法规则上也早有体现。
但示亡号的问题还更加微妙,因为实际上它并没有什么官方标准,它并未出现在两岸四地任何一个地方的官方或者出版机构的明文的风格指南中。学者自己的专著论述,不见得就与现实中的实际的已经形成的使用习惯一致。就好比您所列出的几位,都指出示亡号是用于对新近死亡之人的表示祭奠的,有强烈的感情含义。但在实际使用中,我们却很少见到有谁在灵堂的横幅上将「沉痛悼念✕✕✕」的人名加上示亡号(不是没有,但是不多见),而相反的,为作品面世前就死亡的贡献人添加示亡号却是处处可见的使用习惯(几乎已成定例),出现在中国大陆的出版物和影视作品中,在最近至少二三十年里的用法都是一以贯之的,这并非是维基百科的原创。
因此,并非是中维改变了中文语境中数十年来养成的规范,而是中文语境中对示亡号的用法惯例在过去几十年里已经是如此,中维只是根据人们的用法惯例来使用它(给日期添加示亡号倒确实是中维自有的用法展拓),您所说的另外的带有强烈情感和时效性的示亡号的使用规范,它是否真的曾经存在且作为大家认可的规范,我认为都是可疑的。
过去几十年里出版物(含影视出版物)的实际使用惯例应该 precede 学者在专著中的总结,中维也应当根据实际使用中的惯例来规范自己的风格指南。
顺,任内死亡的标记并不能够因为写明了死亡日期并透过比较死亡日期与任期结束之日的相同而被认为多此一举,因为一个人完全可以早上自然地结束了任期,而在晚上心脏病突发而死,这就不是任内死亡(任期是主动终结而非因死亡而终结)。因此对任内死亡的标记是有实际意义和必要的,并不是多此一举的。
我个人对于中维目前展拓示亡号的功用来标记任内死亡的做法是赞成的,因为 1. 中文读者很容易理解,不会产生误解;2. 几乎不会占据更多的空间,比标记十字架之类的方案更优。--Boreas Sawada 2024年1月6日 (六) 15:58 (UTC)
  • 我覺得straight quotes和curly quotes的例子不能拿來類比。straight quotes至少在unicode裏是被定義為quote來的。我認為格式手冊基本的制定邏輯應該是:維基百科上的技術、執行上問題>學界標準>學者論述>生活上的用例>技術標準>>維基人個人的論述、用法這樣子。(如果生活用例確實很多,應該高於學界標準)straight quotes的問題是「技術、執行上的問題」。最基本的,編輯器得像Word一樣支持自動轉換,也應該要能夠有方法將已有的條目作轉換這樣子。如果能做到,自然是應該取學界標準了。示亡號在你維的用法沒有任何學界的任何論述,日常生活用例所支持,只是最低層次的「維基人的個人用法」。像是前面這種有技術問題或者可靠來源支持的,那才有爭論的餘地。你維示亡號是沒有。
  • 「前者(貢獻者於作品面世前死亡的,加注示亡號)也是事實上的起碼中國大陸地區的出版業(含影視出版)的標準......」:是這樣,但是學者的論述還有後半部份呢。示亡號有時限性,只有短期內使用;而且有褒揚性,不會有被否定的人物加上示亡號的情況。學者說明示亡號怎樣去使用,歸根他們都是通過整理日常使用的方法的所得出來的。他們整理顯然較我們整理為好。你提出來的論述,也和他們提出來的論述,和我日常見的不矛盾。
  • 「靈堂的橫幅上將「沉痛悼念✕✕✕」的人名加上示亡號」:因為示亡號是以表示死亡、表現肅穆莊重的氣氛為目的。靈堂這個環境很明顯已經有這個含義。大家都知道他死了,就不需要了。
  • 任何人都可以任意將標點符號用法隨意展拓的話,那Wikipedia:互助客栈/条目探讨#小议示亡号的不当使用中,你所批評的用法也可以是合理的。那就天下大亂了。
--Ghren🐦🕒 2024年1月7日 (日) 07:23 (UTC)
我认为不能任意示亡。否则爱因斯坦条目里,就全是示亡号了。但是User:Chu_Tse-tien所说也有道理,我们可以有一个“任内死亡”标记。至于示亡号与“任内死亡”标记能不能是同一个标记,我认为可以。--Gqqnb留言2024年1月6日 (六) 08:11 (UTC)
(=)中立保持现状)。但是有一个想法,可以使用,但是对一般读者表示为默认关闭(不显示)状态,放在小工具里设置。--Leiem留言·签名·维基调查 2024年1月6日 (六) 09:01 (UTC)
小工具我想大概不是用在这种地方的吧。我倒还想用小工具打上专名号之类的东西呢,每次看到朱令铊中毒事件的时候都要问自己一遍,朱令铊是谁。--MilkyDefer 2024年1月6日 (六) 09:34 (UTC)
是不是應該統計一下示亡號在本站的使用情況?不只是前述模板,純代碼應該也有不少。長期來說,示亡號確實應該避免使用,否則死人客觀上越來越多,人名不就全都是示亡號。—— Eric Liu 創造は生命(留言留名學生會 2024年1月6日 (六) 09:37 (UTC)
{{box}}有12747個引用。純代碼就不清楚了。--Ghren🐦🕓 2024年1月6日 (六) 09:50 (UTC)
ping一下過去參加過討論的@Sakamotosan@YFdyh000@CaryCheng。另外可以參考Wikipedia:格式手册/标点符号/示亡号中列出的過去討論。--Ghren🐦🕓 2024年1月6日 (六) 09:53 (UTC)
(!)意見,澳門衹有在殯儀業界才會使用示亡號,其他場合基本上不使用。而從澳門的法律文件得知,死者名字(無論是否近期逝世)都不會加示亡號[9]。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年1月6日 (六) 11:57 (UTC)
(+)支持禁用示亡号。首先,中维现今绝大多数情况加框来表示“任内逝世”,这不是示亡号的用法,任何出版社也不会有如此习惯。官职导览模板的任内逝世应该在模板内用星号在底部引注;人物条目中逝世日期已在首行列出,给信息框的任内逝世日期加框,并无过多意思。另外,我怀疑{{Box}}最初用意都不是示亡号的。其次,示亡号是否是标点符号,是有争议的,完全不必往WP:格式手冊/標點符號里添内容。出版物的示亡号早先为署名时参与者逝世的标注,从而形成排版习惯,严格归类也是排版符号。显然,这样排版习惯的起源和推广,伴随着感情色彩之存在,这点是多数学者提到的。--PexEric 💬|📝 2024年1月6日 (六) 14:12 (UTC)
我給出的來源都是將它當作標點符號看待。--Ghren🐦🕚 2024年1月6日 (六) 15:34 (UTC)
支持。個人認為屆時條文中也應建議改用註釋說明取代。--西 2024年1月7日 (日) 00:30 (UTC)
提案是想僅正文禁用還是所有情況下一刀切禁用?正文禁用的話我肯定是舉雙脚支持的,但所有情況下一刀切禁用的工作量未免過於浩大(畢竟{{box}}也不是只有示亡號的作用)。Sanmosa Romeo and Qubilai 2024年1月7日 (日) 03:32 (UTC)
當{{box}}被當作示亡號來使用的話,應該完全被禁用。{{box}}的其他使用情況不受限制。比如說{{江苏行政区划史}}中省會加框的做法不受限制。--Ghren🐦🕑 2024年1月7日 (日) 06:37 (UTC)
這樣的話,那確定哪些頁面將{{box}}當作示亡號會非常重要,畢竟現在引用該模板的頁面有12,747個。Sanmosa Romeo and Qubilai 2024年1月7日 (日) 06:41 (UTC)
暫時我的看法是定立共識再一步步改。--Ghren🐦🕒 2024年1月7日 (日) 07:32 (UTC)
严格来说我认为没必要使用示亡标识(包括西式的剑标),如果大量范用的话,可能变成了追着死人来标记(毕竟人固有一死……)?如果弱化的话,只允许特定情况下的使用,例如在描述他的某个重要职务上在任离世时标示。——Sakamotosan路过围观 | 避免做作,免敬 2024年1月7日 (日) 05:20 (UTC)
我也有同樣的想法,但老實説我日常生活中也很少見到示亡號,好像也就報紙上說某府出殯的時候偶爾會看到幾次而已。Sanmosa Romeo and Qubilai 2024年1月7日 (日) 06:43 (UTC)
AMA Manual of Style亦已弃用death daggerChicago中dagger现仅用于脚注。--Mys_721tx留言2024年1月7日 (日) 23:42 (UTC)
@Cwek  ?? -Lemonaka 2024年1月19日 (五) 06:41 (UTC)
是的。——Sakamotosan路过围观 | 避免做作,免敬 2024年1月19日 (五) 06:48 (UTC)
不反对维持现状。不过box模板表达信息的话,使用螢幕閱讀器盲文显示机和纯文字图片浏览器的读者会无法获知。 ——魔琴 留言 贡献 新手2023计划 ] 2024年1月7日 (日) 06:45 (UTC)
如果说禁用的目的是“防止这类无意义的编辑”,那我支持。不过因为在生活中很少见过,我不确定使用示亡号是否会不够中立。- AdyaTalk 2024年1月9日 (二) 12:47 (UTC)
(+)支持禁止。濫用於很多影視劇條目中。Zhxy 519留言2024年1月10日 (三) 20:57 (UTC)
Template:限制使用:我认为应仅限于1.书籍或影视作品面世前,该演员/职员/编者等已经去世了,可以用示亡号(有不少书籍的编者页能看到示亡号);2.死于任上时。不应该用于:1.影视剧中某个剧中角色去世了,就在他的角色名加示亡号;2.单纯为了悼念在作品面世后多年去世的演员/职员/编者。--超级核潜艇留言2024年1月11日 (四) 05:49 (UTC)
我個人理解的使用習慣其實與此一致,不過希望各地的編者出來看下,各地中文裡對於示亡號的用法同此是否一致?--Zhxy 519留言2024年1月11日 (四) 14:44 (UTC)
对于书籍编者来说,示亡号有表示编辑负责人由于逝世无法对质的作用。维基百科不是这些人的作品,因此也没有必要单独列出。类似符号在汉语和英语中只有习惯用法而非正式定义。在缺乏定义时应考虑取消。--Mys_721tx留言2024年1月12日 (五) 09:29 (UTC)
如果书籍面试前很多年该作者就已经去世的话,并不会用示亡号,示亡号只用在近期去世的情况下,类似于{{最近逝世}}的作用。我没见过正式出版物中单纯死于任上会使用示亡号来表示的情况,烦请举例。此外,示亡号本身还有一层悼念、纪念的含义。无论在维基百科如何使用,都会有潜在的中立性问题--百無一用是書生 () 2024年1月12日 (五) 03:48 (UTC)
(+)支持:支持新增閣下提案的條文。--CaryCheng留言2024年1月17日 (三) 09:16 (UTC)
(+)支持--Taeas留言2024年1月17日 (三) 13:01 (UTC)
(+)支持在条目空间禁用示亡号。我在tg有参加过讨论,这边的论述已经很好了。加一点其他的说法就是WP:家父。维基百科既不是出版物的发行者,也不是发布成员名单的特定组织,为啥替人家做那种事?考虑维基百科文体,完全没理由是用示亡号。有害无利。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年1月18日 (四) 09:14 (UTC)
支持。--桃花影落飞神剑留言2024年1月18日 (四) 15:18 (UTC)
(+)支持,在中文圈裡好像都不是正式標點符號。-KRF留言2024年1月21日 (日) 01:32 (UTC)

將上案 公示7日Ghren🐦🕓 2024年1月24日 (三) 09:55 (UTC)


本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

后续处理

请管理员处理Wikipedia:机器人/作业请求#批量删除nav模板中的示亡号,内容页面引用还要再整理一下。--Jeffchu2014留言2024年2月12日 (一) 19:17 (UTC)

刪除線

借這題問一下,像Template:AKB48除了用示亡號,還用了刪除線,還有Template:虚拟YouTuber也用刪除線劃掉已結束活動的藝人,這種是否也應該禁掉?MOS:NOSTRIKE有論述說明為什麼不該用刪除線,但該指引還沒有採納。--C9mVio9JRy留言2024年1月21日 (日) 00:04 (UTC)

團體也用示亡號太誇張了吧?—— Eric Liu 創造は生命(留言留名學生會 2024年1月21日 (日) 05:23 (UTC)
粗體、斜體、下劃線、底線、刪除線等等在中文的使用方式沒有得到定義,本身就應盡可能避免使用。
為還在世的人物、團體加框是一種很不禮貌的做法,容易讓人誤以為他們已經死掉了,是一種很失禮的表達方式。即使上邊沒有規定,也不應該使用。--Ghren🐦🕓 2024年1月21日 (日) 09:55 (UTC)
不过Template:AKB48里用示亡号的都是解散了的团,用删除线的都是重组或未成功的企划。--无所事事/想要狗带 2024年2月7日 (三) 17:07 (UTC)
既然都提到刪除綫,我自己也很懷疑{{城巴機場快線}}中刪除綫的用法的恰當性。Sanmosa Miyamoto Miyoko 2024年1月29日 (一) 00:15 (UTC)
用示亡号表示废除似乎不太好,用删除线相对可能柔和一些。而且不建议使用删除线是考虑到屏幕阅读器不支持,这可能是对正常阅读者的逆向歧视。做法上是删除或者注释也并不太好,可能会导致链接关联丢失(因为提及案例多为Navbox,而且内容并非限定只能是现在时态,所以可以保留链接以代表其内容上的关联)。——Sakamotosan路过围观 | 避免做作,免敬 2024年1月30日 (二) 05:50 (UTC)
身為正常視覺的人我還是反對刪除線,取決於你電腦上的字型,有時候不容易看出被劃掉的是什麼字,例如可能很難判斷「西人三日」是「西人二口」還是「酉大三日」還是什麼排列組合,還有西方語言或符號的ceoɘɵɔ, iɨ, uʉ, ΛA, ſf, V∀也難以判讀。導覽框可以獨立弄一個類別即可,或是用星號加注。逆向歧視扯遠了,換掉刪除線不會對視覺正常的人造成任何不便,而是去除了對大家都不便的閱讀困難。難道坡道和電梯是對兩腳正常的人的逆向歧視嗎?--C9mVio9JRy留言2024年2月1日 (四) 06:30 (UTC)
如果从数据结构组织的话,我认为原地标注删除线,比七零八落的Group中额外抽出来描述,更为简单可行。另外我认为字体辨认的例子属于特定个例(并不是所有字符都能被删除线一遮盖就刚好对应另一个字)或者带有主观性。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月1日 (四) 08:09 (UTC)

示亡號的一个用法应当注意

示亡号在图书出版等领域,有以带框姓名表示书籍出版时已经去世的用法,如我之前编辑的“中国钱币大辞典”条目,它是由特定时间限定的,就是指这个人参与了书的编撰,但出版的时候已经去世了。--苞米()💴 2024年2月5日 (一) 04:16 (UTC)

我认为在特定的时间点,用这个是示亡号是可以的,比如在通常发给在世人物的奖项获奖者列表中,表示获奖者在获奖时已经去世。比加“十字符”更符合中文习惯,且不涉及宗教问题--苞米()💴 2024年2月5日 (一) 04:19 (UTC)

表格或許可以寬容一點。另外任何能加上(且有必要加上)十字號的場合,我覺得替換成示亡號並無不可,畢竟十字是從外文傳過來的。—— Eric Liu 創造は生命(留言留名學生會 2024年2月5日 (一) 07:08 (UTC)
示亡号一是表示近期事件发生时已经逝世(例如出版时已经逝世),已经死亡有一段时间的不会用;二是同时表示对死者的纪念和悼念。这两种在维基百科都是不合适的--百無一用是書生 () 2024年2月5日 (一) 08:37 (UTC)
“已经死亡有一段时间的不会用”[查证请求],图书再版时会去除吗。对于原作者去世多年,应该是不会用。纪念性对于保持原貌来说,不觉得不合适。--YFdyh000留言2024年2月5日 (一) 21:11 (UTC)
见AMA取消十字的决定。--Mys_721tx留言2024年2月5日 (一) 21:19 (UTC)
@Mys 721tx那是不是也要一併考慮禁止使用此符號?—— Eric Liu 創造は生命(留言留名學生會 2024年2月10日 (六) 14:58 (UTC)
剑标和示亡号作用等价时应当取消。{{KIA}}、{{Executed}}、{{DOW}}用来表示死因时不会随时间变化,不用限制。--Mys_721tx留言2024年2月10日 (六) 20:04 (UTC)
图书再版更多是版本学的问题,不太一样--百無一用是書生 () 2024年2月8日 (四) 03:33 (UTC)
有沒有一種可能是:這種用法也是不合適的?Sanmosa Défendre jusqu'à la mort 2024年2月6日 (二) 00:49 (UTC)

建議細化連結符號「-/—/-」的格式方針

以色列—哈馬斯戰爭使用的連字符是「—(\u2014)」;「伊朗-以色列代理人冲突」使用的是「-(\uff0d)」;機場名稱如果出現連字符,則使用的「-(\u002d)」。這樣的混用不能再持續下去了。應該統一起來。——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 03:49 (UTC)

@王桁霽:已经统一过了,参见MOS:连接号。----FradonStar|八闽风云 2024年4月14日 (日) 06:25 (UTC)
那麼是否應當將「伊朗以色列代理人冲突」移動至「伊朗以色列代理人冲突」?--——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 06:32 (UTC)
应该将“以色列—哈马斯战争”移动至“以色列-哈马斯战争”才对吧?!这是个复合名词,又不是表示“上海—北京列车”之类的起止。--自由雨日留言2024年4月14日 (日) 08:59 (UTC)
我覺得閣下所言極是,以哈战争關注量極大,盼管理員處理定奪。——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 09:06 (UTC)
(~)補充:中华人民共和国外交部中国-东盟关系用的就是短横线,并非一字线(虽然短横线这里不是\u002d,但中国大陆“-”和“-”通用的,参见标点符号用法。--自由雨日留言2024年4月14日 (日) 09:11 (UTC)
另,似乎所有的雙邊外交關係條目都使用了「一字符(—)」,如:「中国—日本关系」。按照《MOS:连接号》而言恐是錯誤的。但修改起來工程量就太大了。——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 09:08 (UTC)
国际关系中使用一字线,可以看Wikipedia_talk:格式手册/标点符号/存档3#连接号一字线的符号选择,此次讨论之后进行了大量移动。--Kethyga留言2024年4月14日 (日) 09:17 (UTC)
这似乎不是使用一字线还是短横线的问题,而是“一字线的字形”问题?对中国大陆来说,“-”和“-”都是短横线,任意选择,“—”是一字线。中维之前把“-”作为一字线,然后移动到了“—”,说明国际关系从之前到讨论后实际上用的都是“一字线”。--自由雨日留言2024年4月14日 (日) 09:20 (UTC)
感觉MOS:连接号对于A与B之间的事物(如上述以色列—哈马斯战争,“连接号”不会读作“至”、“到”),应该再明确一下。美國-墨西哥-加拿大協定似乎用“一字线”还有点争议,像“吐鲁番-哈密盆地”可能更倾向于“U+002d”。--Kethyga留言2024年4月14日 (日) 09:10 (UTC)
贊同,連結號的格式規定確實不夠詳盡。鑑於其廣泛應用,社群應當盡快通過討論修訂完善。——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 09:13 (UTC)
Ericliu1912 君已經把「伊朗-以色列代理人冲突」移動為使用一字線的版本了。推測社群領導層支持一字線在連結某事物雙方時的使用。——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 09:29 (UTC)
(...) 吐槽,维基百科管理员不是领导层。--Kethyga留言2024年4月14日 (日) 10:00 (UTC)
(+)贊成——  桁霽  晚來天欲雪,能飲一杯無  ↹ 苦辛 🇹🇱   2024年4月14日 (日) 10:02 (UTC)
「領導層」是什麼Orz —— Eric Liu 創造は生命(留言留名學生會 2024年4月14日 (日) 13:33 (UTC)

写了一个简单的{{顿号}}模板,或许可以适应不同地区的习惯

本来想命名为更方便使用的{{}},但该模板已经重定向至另一模板了,于是命名为{{顿号}}。因为见过有台湾等地的用户在含引号/书名号的并列成分之间加顿号、有中国大陆等地的用户在含引号/书名号的并列成分之间去掉顿号等操作,故作此模板,以避免可能存在的小格式问题上升至编辑战的风险,以及适应不同地区的习惯,或许比“先到先得”“全文统一(无实操指南)”之类的规则更好。当然,因为大陆地区之外并没有相关规范,可能也喜欢“不使用顿号”,而大陆地区部分用户也可能不认同国家推荐标准、反而“喜欢使用顿号”,故平时这一模板或许无需使用;但若有编者因个人习惯想作出类似的将原编者的行文“删去/添加顿号”的改动,则不妨直接改成用此模板,虽然仍有可能违背一部分人的习惯,但也许是相对来说最适应多数人的、且中立的处理。--自由雨日留言2024年6月21日 (五) 19:33 (UTC)

港澳台新马各地中文夹用英文书刊名格式规范?

目前,本格式手册要求将英文书刊名也使用中文书名号表示,且可不用斜体(除MOS:书名号第5条用例外,还有WP:格式手冊/序言章節#特定名字與標題的用例“The Pawnbroker》是一部由爱德华所写的一部小说……”等)。然而,中国大陆的文字规范与之几乎完全相反,一般并不允许将英文书刊名用书名号表示,且必须使用斜体,参看:《夹用英文的中文文本的标点符号用法(草案)》(第6.2条)、《中文出版物夹用英文的编辑规范(CY/T 154—2017)》(第10.1条)等等。所以在此询问其他地区的相关规范。我想,若均不用书名号,那么应当修改该规则;若仅部分地区(如中国大陆等)不使用书名号,应仿照单双书名号转换等方式来单独实现大陆简体等模式的格式规范。——自由雨日🌧️留言贡献 2024年8月12日 (一) 03:41 (UTC)

據我所知,香港的情況是正式情況下用書名號、任何情況下不得使用斜體。這種情況下使用轉換有技術上的困難。Sanmosa DC·恭賀樊振东奧運奪金 2024年8月12日 (一) 03:55 (UTC)
“任何情况下不得使用斜体”!还有这种事思考...技术上的困难是指?如果只考虑书名号的话,那只要使用-{zh-cn:<nowiki/>; zh-hk:《; zh-tw:<习惯格式>; <其他地区转换>}-代码(可写成模板)就可以轻松实现吧?如果还要考虑斜体的话,那就单建模板{{英文书刊}},将所有英文书刊名都用模板表示,应该也不难实现?——自由雨日🌧️留言贡献 2024年8月12日 (一) 04:08 (UTC)
“'”這個符號放在轉換代碼裏會產生問題,然而斜體的效果正需要這個符號來表達。Sanmosa DC·恭賀樊振东奧運奪金 2024年8月12日 (一) 11:41 (UTC)
你这两个连国标也不是啊--百無一用是書生 () 2024年8月12日 (一) 06:42 (UTC)
确实不是 囧rz……但在没有国标的情况下,用于说明格式习惯还是没问题的?毕竟很多格式习惯(尤其是在一些少有规范标准的地区)连这种程度的草案/行标都没有思考...--—自由雨日🌧️留言贡献 2024年8月12日 (一) 07:05 (UTC)
我翻了一下目前我这儿常用的的写作要求,都没有这个要求...--百無一用是書生 () 2024年8月12日 (一) 12:24 (UTC)
思考...那前辈您那儿一般更多用书名号表示还是用斜体表示?(或者其他方式)--—自由雨日🌧️留言贡献 2024年8月12日 (一) 13:10 (UTC)
书名号--百無一用是書生 () 2024年8月13日 (二) 03:31 (UTC)
有些作品名称在一地用汉字(中文)表记,一地用拉丁字母(英文)表记,比如zh-tw:Final Fantasy; zh-cn:最终幻想;。考虑到标题本身英文与否都涉及地区词转换,再要各地采用不同的标记方法,处理上就很难执行。正文或中文上下文中,所有标题都一样加书名号就ok。英语上下文里可以加斜体,比如「《最终幻想》(英語:Final Fantasy)」或信息框的original_name栏位。
PS:感觉书名号+斜体有些叠床架屋。而那个「不允许将英文书刊名用书名号」我都想开喷——中文上下文里不用中文书名号还用什么?中文读者为什么要知道英文用什么标记?那日文作品书名号是不是还要换成『……』?--For Each element In group ... Next 2024年8月12日 (一) 08:57 (UTC)
要执行的话,只要将带书名号的名称也并入转换,其实根本不难,这比各类信息框模板语法简单多了……--—自由雨日🌧️留言贡献 2024年8月12日 (一) 09:02 (UTC)
还有Final Fantasy IIFinal Fantasy IIIFinal Fantasy Artniks。而且带链接的内容好像还不好写到转换组里面
然后是「Final Fantasy VII 重製版」这种中英文夹杂的。「Final Fantasy VII」斜体不带书名号,而「《Final Fantasy VII 重製版》」带书名号不斜体,怎么看都很莫名其妙。
我的看法无论用英文还是其他什么文来写,都一样使用书名号。那份草案不适合中维。--For Each element In group ... Next 2024年8月12日 (一) 09:17 (UTC)
那些只要维持台湾正体为原样就好了吧……大陆并没有这种中英混杂标题的问题?大陆《现代汉语词典》只收了字母词,没收纯英文单词,是不认可任何英文单词属于中文的,所以正式名称应该不会有这种中英混杂。--—自由雨日🌧️留言贡献 2024年8月12日 (一) 09:26 (UTC)
《现代汉语词典》是词典不是百科全书,而传统百科全书也只会记录那些名著;而既然是名著,那自然是有中文译名的。但是,维基百科肯定会在正文中提及许多小众作品。
至少游戏作品这边,按过往的编辑经验,大陆这边是比港台更喜欢使用中文标题没错。但最近的议案现在在紧缩标题翻译。而大陆官方中文化也就是这十年的事情,早期游戏译名怎么处理就很成问题。出现台湾使用中文标题,大陆因为来源品质不够,反而得滚回原名的情况也不好说😂--For Each element In group ... Next 2024年8月12日 (一) 10:03 (UTC)

更深层的考虑,维基百科条目中会出现各种外语作品名。对于正文中的非中文作品名,应该全部罗马化,再像中文作品名一样加书名号。如「《आओ》}」写为「《aao》(印地語आओ)」,「かみざわ」写为「《kamizawa》(日语:かみざわ)」。毕竟可以合理假设,接受正常教育的中文读者都有能力辨识26个字母😂

同样的道理,英文标题如果不翻译成中文,那也应该罗马化。只不过,英文罗马化前后字面上一样,看起来就像直接使用了英文标题。「《The Pawnbroker》(英語:The Pawnbroker)」,括号里是隔离出来的英文上下文,使用{{lang|en}}包围并加上斜体。如果觉得写两遍「The Pawnbroker」啰嗦,也可以把括号扔了。

我想,按照「若非中文标题,即是罗马化外文标题」的逻辑来解释,而英语并没有「特权」,应该能更解决更普遍的问题。--For Each element In group ... Next 2024年8月12日 (一) 11:24 (UTC)

为何“英语并没有特权”,英语难道不是全世界的法通语(lingua franca)吗?--—自由雨日🌧️留言贡献 2024年8月12日 (一) 11:34 (UTC)
这里是中文维基百科,不应假设中文维基百科读者会使用其他语言——包括更容易被人提到的,您所说的「全世界的法通语」的英语。尽管你在commons:讲英文,会有更多的人看懂你想说什么。--For Each element In group ... Next 2024年8月12日 (一) 11:41 (UTC)
我似乎并没有提到“假设读者会使用英语”?--—自由雨日🌧️留言贡献 2024年8月12日 (一) 11:45 (UTC)
这个讨论是开始就是讨论「英文书刊名」。我的意见是,英语和其他语言一样,不需要专门特殊处理。
另外抱歉,我没有完全理解您上面两个问句回复。您可以再陈述一下您的意见吗?--For Each element In group ... Next 2024年8月12日 (一) 11:52 (UTC)
我的逻辑就是“英语应该具有特权”。其他语言是用斜体还是用书名号是我目前暂未考虑的问题,但既然英语在大陆已形成某种习惯规范,那么当外文是英文时,自然应当遵循该规范(在技术可以实现的前提下)。而且这其实和英语是不是有特权也没有关系吧?如果颁布的规范是英语、印地语和日语而没有颁布其他语言,我也会说,在颁布规范的这些语言中应当遵守,这不代表“英语、印地语、日语”就有了“特权”。——自由雨日🌧️留言贡献 2024年8月12日 (一) 11:57 (UTC)
抱歉我的表述引起了误解。我想我应该说是英文作品的格式是「孤例」。
维基百科在内容上有自己的风格,比如中立。那我想格式上,维基百科也可以有自己的风格,而非直接「照单全收」——您也不会要求我们遵循第二个链接的11吧。像参考资料,英维和中维的参考资料都用的WP:CS1,没有完全遵循某套规范(如大陆用GB/T 7714)。
具体实现上,一方面如您所说,确实有技术问题,包括我活跃的领域也有。像这个例子,链接位置插得不对,就会打断转换规则,令其无法奏效;不关注转换的人可能还看不出来。所以目前游戏领域的指引允许系列名称不加书名号,好让编者直接「XX系列」插链接。当然,我也希望技术问题能够早日解决。
另一方面是语义问题。比如最终幻想Artniks条目,外语标记部分是把「Final Fantasy Artniks」这串英文当成日语,因为这个游戏是日本作品,没有英文版。那么在正文中,这个标题该按英文处理吗?如果按英文标题处理,这个作品没有英文版,只是标题比较洋气而已;如果按日文处理,那就需要日文的处理方案,但是您还没想好;如果按中文标题来办事……那怎么把它解释成中文呢?所以目前我认为最容易执行的方法就是上面说的,直接理解成罗马化,省得考据党为属于哪种语言而吵架。
如果颁布的规范是英语、印地语和日语而没有颁布其他语言,因为这三个语言差别都很大,或许足够归纳出通用的外语作品名标记方法。而现在只有英语一个孤例,我们也看不出来方案撰写人的想法,不知道他背后的考量点是什么,就无法系统性的应用到其他语言。因为我既关注日文作品、也接触地区词,还专门加过几年书名号。如果没有易于执行的规则,我真的会宕机😂
以上是我的想法。还辛苦您像这个讨论那样,提出外语全盘(而不只是英语)作品名标记的应对方案。去书名号影响很大,如果只说英语免不了编者类推其他语言或东施效颦,最后导致更混乱的效果。希望早日实现既规范又易于执行的规则。--For Each element In group ... Next 2024年8月12日 (一) 13:16 (UTC)
PS:发现还有些要注意的方面。如果规定英文作品斜体,是否要用{{lang|en}}表明语义?条目标题是否要和英维那样,加上斜体字效果?--For Each element In group ... Next 2024年8月12日 (一) 15:00 (UTC)
我个人拥护Ghren前辈的曾在示亡号用法中提出过的意见格式手册基本的制定逻辑应该是:维基百科上的技术、执行上问题>学界标准>学者论述>生活上的用例>技术标准>>维基人个人的论述、用法……(如果生活用例确实很多,应该高于学界标准)。当然目前这一问题上我并不清楚她的意见。——自由雨日🌧️留言贡献 2024年8月12日 (一) 21:28 (UTC)+1
该草案的内容很有参考意义,但书名号部分并非中国大陆历来的格式习惯,而是新的规范要求。见作者 简庆闽 来源 《语言文字报》第818期的文章内容。--YFdyh000留言2024年8月24日 (六) 15:56 (UTC)
该文似乎没提到书名号?--自由雨日🌧️留言贡献 2024年8月24日 (六) 16:04 (UTC)
简庆闽这篇,我指的是,以前“缺乏有关标准”,并且历经数次修订和专家争论、曾有“很大分歧”,证明“中国大陆的文字规范与之几乎完全相反”是不全面的。并且标题是“草案”、“修订也不会停止”——虽然未见后续修订且已正式发布、被参考引用。--YFdyh000留言2024年8月24日 (六) 16:38 (UTC)
补充,关于“草案”(绿皮书),属于软性规范、引导试用,类似GB/T。[10][11]--YFdyh000留言2024年8月24日 (六) 16:49 (UTC)
并非“类似GB/T”,肯定比GB/T更“不具规范性”啊……要真是GB/T我早就大力推进了()但我前面已指出(12),有规范草案的情况已经是“非常有参考意义”了。(另外,我惊奇地发现第2个链接中出现了一个“+1”的标记,鼠标悬停显示“YFdyh000为此+1了。”这是新功能吗?!)--自由雨日🌧️留言贡献 2024年8月24日 (六) 17:19 (UTC)
也许比某些GB/T更有价值,推荐性质也差不多。那是个模板,我手动加的,省去留言复述。补充一下,我对纯英文书名不用中文书名号,目前倾向赞成,不过“一般并不允许”存疑,“必须使用斜体”反对,过往有一些论述说“可以采用斜体、黑体或者下划线表示”。如果确定为斜体,参考文献等处的非中文夹带英文书名均应使用英文斜体吗,我通常会去掉……也稍有担心多少比例的读者理解是书名号作用。--YFdyh000留言2024年8月24日 (六) 17:39 (UTC)
参考文献处,如果是书名本身那不应使用斜体,就像中文书名不应加书名号,但如果是书名的一部分,应当使用斜体吧(就比如书籍标题是“《红楼梦》赏析”,那么参考文献标题参数也应当带有书名号)?“也稍有担心多少比例的读者理解是书名号作用”是指?--自由雨日🌧️留言贡献 2024年8月24日 (六) 17:44 (UTC)
纠正一下,我的问题是脚注中,中文书名、英文书名,是否都改斜体,因为模板一律不加中文书名号。我过往是均不斜体。如果书目名不斜体,与英文维基的规范是不一致的,见[12]Template:Cite_book文档允许英文书名加斜体,中文书名禁止。关于斜体,另参考Wikipedia_talk:格式手册/存档1(2005年)、Wikipedia_talk:格式手册/标点符号/存档2(2019年)等许多关于斜体美观性、理解难度的讨论。--YFdyh000留言2024年8月25日 (日) 02:53 (UTC)
参考文献应该从来就不适用标点符号格式手册规则(比如中文文献中使用的那些“.”“,”等符号GB/T 7714也不定性为“标点符号”而是“前置符”),应该与本次讨论无关?--自由雨日🌧️留言贡献 2024年8月25日 (日) 05:14 (UTC)
有间接关系,既书名斜体的适用范围、对读者而言便利程度。--YFdyh000留言2024年8月25日 (日) 17:46 (UTC)

推進圖註結尾有無句號共識

前次討論,多數意見傾向「視作短語的圖註結尾不加句號,視作句子/語段的圖註結尾加句號」,其餘意見認爲此爲習慣問題並表示中立。被指似有初步共識,可以考慮繼續推進;惜未推進。故而,折衷二方意見,總結共識:不應禁止「視作句子/語段的圖註結尾加句號」。建議對「句號」章節部分修改如下:

現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 句2:圖、表的說明文字若屬短語,末尾不用標點(包括句号);若爲句子語段,末尾可用、可不用句号。

--— Gohan 2024年10月27日 (日) 04:57 (UTC)

就大陆简体模式而言,(-)傾向反對,因为与标点符号国家推荐标准直接相悖,且似乎不属于“书名号间不用顿号”这类有较大争议的标准(即标准基本和习惯一致)。其他地区不了解,(=)中立。--自由雨日🌧️留言贡献 2024年10月27日 (日) 22:51 (UTC)
  • 最初打算沿用前次討論無人反對的多數意見,正是眼見中國大陸表意不清(不清之處見下)的標準(「图或表的短語式說明文字,中間可用逗号,但末尾不用句号。即使有时说明文字较长,前面的语段已出現句号,最后结尾处仍不用句号。」),才折衷為以上二者皆可的方案。此方案甚至涉嫌過度妥協。況且,閣下細讀可知,提議條文與中國大陸標準相比較,互不相悖。
  • 中國大陸的標準(以上綠色文字)表意不清,只規定「……短語式說明文字」「末尾不用句号」,未規定「非短語式說明文字」末尾可否用句號,後續文字「……前面的语段……」似乎暗示該規定也覆蓋「非短語式說明文字」,範例亦有末尾無標點的「非短語式說明文字」——「……。這是某區街道一景」;但若該規定覆蓋「非短語式說明文字」,爲何最主要、關鍵的規定限定于「短語式說明文字」?故此標準含糊不定,用意不明。
    • 假如上述中國大陸標準如原指引條文理解、即覆蓋「非短語式說明文字」,則連中國大陸最親當局的正式來源都不遵守此標準。表方面,中國統計年鑒表格的說明文字常用句號結尾;圖方面,人民日報相片的靠左説明語段多有句號結尾,僅有靠右的説明圖源(◯◯ 攝)等的孤立短語無句號結尾,難以評判。但是中國統計年鑒用法足見,中國大陸在此的標準顯然與正式文本用法相差甚遠,維基百科不應盲從該標準。
    • 假如上述中國大陸標準不如原指引條文理解、即不涉及「非短語式說明文字」,則更需要修訂釐清理解有偏差的原條文及範例(「維基娘」),以正視聽。原條文的「維基娘」範例不符合此種理解下的中國大陸標準。
  • 此外,正如頓號一般,目前在方針指引層面無法解決各地用字模式的句號用法差異,故此方案已是兼顧各地用字模式的最佳選項,而原條文如上所示只是中國大陸標準的微調、並無兼顧各地差異,相對更差。閣下既然此前支持頓號的不同用法並存,同理現在亦應支持圖註結尾有無句號的用法並存。
--— Gohan 2024年10月30日 (三) 11:11 (UTC)
  • 连中国大陆最亲当局的正式来源都不遵守此标准”:语文方面的用法和是否“亲当局”无关,应当主要看语文学界的观点和用法。《中国统计年鉴》我似乎点不开细项?《人民日报》的图片,就我的理解和语感来说,它并非“图注”,它是由图片+文字共同组成的一则新闻短讯,可能图片是主要想突出的对象(重要性占70%),但文字仍是新闻的重要组成部分,而非仅仅是图注,这种情况我认为确实需要加句号;它和“在篇章中用于说明篇章内容的图片”是不一样的,后者的图片下方文字才是“图注”,它往往非常简短。而维基百科中使用图片几乎都是第二种情况。而(仅用于图注时)“不涉及“非短语式说明文字””的推论显非事实,因为“示例2”的语句结构“经过治理,本市市容市貌焕然一新。这是某区街道一景”和“维基娘是维基百科萌拟人化后的美少女角色。由日语维基百科人创作”基本一致。
  • 因此,阁下的论述并未说服我中国大陆的习惯并非“在前面的语段中已用句号,最后结尾处可用句号”。当然若其他地区有不同的习惯,我肯定不会反对他们遵循他们的习惯。前面分类讨论的意思是原则上我希望使用类似书名号模板的方式用于地区词转换,即大陆简体模式下不显示句号,其他有需要的模式显示句号。不过我考虑了一下,这样可能确实太过麻烦(您也知道我向来希望尽量“减少转换”)。因此,我决定收回前面“倾向反对”的意见,改为(=)中立
--自由雨日🌧️留言贡献 2024年11月1日 (五) 14:16 (UTC)
  • 原條文、提議條文、中國大陸有關標準均只涉及「説明文字」或「短語説明」,均未涉及「圖註」一詞。拘泥於是否「圖註」似乎離題。
  • 語文學界對此觀點如何?無論其觀點如何,中國大陸統計年鑒及人民日報(餘例見下)等正式文本均證明:實際上句號在圖表説明文字末尾常用。
    • 中國統計年鑒可經原始網址查看細項。更多人民日報乃至其他黨報用例自證:句號結尾絕非限於所謂「圖文組成」的「新聞短訊」,而是任何型式的圖片説明文字。
  • 您對「街道一景」等二例的分析正好印證上述我的分析:「……範例亦有末尾無標點的「非短語式說明文字」……但若該規定覆蓋「非短語式說明文字」,爲何最主要、關鍵的規定限定于「短語式說明文字」?」您能否回答此問?
    • 您是否認爲中國大陸有關標準(「图或表的短語式說明文字,中間可用逗号,但末尾不用句号。即使有时说明文字较长,前面的语段已出現句号,最后结尾处仍不用句号。」)即使特意以「短語式」為「説明文字」的定語,仍可管轄「非短語式說明文字」?如是,爲何?依據省略主語的文法,「图或表的短語式說明文字」會不會是第二句(「即使有时说明文字较长,前面的语段已出現句号,最后结尾处仍不用句号。」)的主語?
    • 注意:我從未認定「不涉及「非短語式說明文字」」,而是分別分析「假如……覆蓋「非短語式說明文字」」、「假如……不涉及「非短語式說明文字」」兩種理解,並認爲有關標準「含糊不定,用意不明」。以這種含糊不定、用意不明、脫離實際的格式標準限制維基百科不妥。
--— Gohan 2024年11月2日 (六) 08:58 (UTC)
  • 我仔细读了下中央媒体报纸,发现它们似乎有自己独特的格式,确实和标准不一样,例如《光明日报》,将“出土秦简的里耶古城一号井。”和“云梦县博物馆展出的睡虎地简牍(复制品)。”末尾都打上了句号,而它们显然属于短语。因此不能以中央媒体报纸用法不符合国家标准为由来说明句子之后应加句号,否则同样的逻辑就应推出短语后面也应加句号了。
  • ……范例亦有末尾无标点的“非短语式说明文字”……但若该规定覆盖“非短语式说明文字”,为何最主要、关键的规定限定于“短语式说明文字”?”我并非标准制定者,并不清楚这个问题。但示例中的“经过治理,本市市容市貌焕然一新。这是某区街道一景”显然表明:图片说明文字非短语时,末尾仍不用句号;就算有表意不清的问题,也至少不会是“应该用句号”。
--自由雨日🌧️留言贡献 2024年11月2日 (六) 09:21 (UTC)
  • 對於短語不用句號結尾,兩次討論衆人皆無質疑;故與本議題——大多數意見反對現行條文——截然不同。
  • 您既然不清楚中國大陸有關標準限定于「短語式説明」的原由,那麽應否不再以此標準作為管轄「非短語式説明」的論據?
--— Gohan 2024年11月4日 (一) 10:53 (UTC)
  • 我指出“短语不用句号结尾”是用归谬法论证“不能用央媒的用法来推得‘非短语用句号结尾’”,而非表达“短语应用句号结尾”。
  • 这一点是荒谬的。因为“推究国家标准/学界共识等的缘由”不应当是维基百科编者做的事情。正如假设某个译名完全不符原文发音且编者不知道它为何被那样翻译,只要其常用,便不可以“不知那样翻译的原由”为由不采用该译名。Ghren曾经在示亡号相关讨论指出:“格式手册基本的制定逻辑应该是:维基百科上的技术、执行上问题>学界标准>学者论述>生活上的用例>技术标准>>维基人个人的论述、用法”,我对此深以为然。
--自由雨日🌧️留言贡献 2024年11月4日 (一) 15:15 (UTC)
  • 閣下有無此意皆可。以普遍實際正規用法調整標點規範理所當然,中國統計年鑒、人民日報及Cdip150君等人提出的用例強而有力;不因閣下無此意而變得無力。
  • 表意不清、不能自洽的標準顯然不能作爲標準。顯非荒謬,亦非意在推究原由(為有關問法或許導致的誤解致歉)。中國大陸有關句號標準,顯不確定是否管轄非短語,自然不能作爲管轄非短語的論據。
  • 對所提次序不予置評。但就非短語式圖表説明末尾有無句號,您也提不出明確清晰的學界標準或論述;依此次序,若無技術困難,惟有輪到「用例」。
--— Gohan 2024年11月5日 (二) 10:10 (UTC)
  • 那些用例再“强有力”,也只能证明“图注结尾可用句号”,而无法证明“图注结尾必须用句号”,而我现在并不反对可用句号,所以实际上甚至是无关的论据。
  • 条文“即使有时说明文字较长,前面的语段已出现句号,最后结尾处仍不用句号。”及示例“经过治理,本市市容市貌焕然一新。这是某区街道一景”,就算存在表意不清的问题(即“图注的非短语结尾是否必须不用句号”有争议),也至少表明“可以不用句号”。
  • 标准和用例见上。
--自由雨日🌧️🌨️ 2024年11月5日 (二) 10:32 (UTC)
表意不清(甚至與最關鍵定語自相矛盾)的「標準」堪稱「不準」,不應被採用。不再贅述。— Gohan 2024年11月5日 (二) 10:48 (UTC)
我没看出矛盾啊?第一句说“短语式说明文字不用句号”,第二句说“即使有时说明文字较长,前面的语段已出现句号,最后结尾处仍不用句号”(即“街景”“维基娘”等的情况)。——自由雨日🌧️🌨️ 2024年11月5日 (二) 11:01 (UTC)
上方已有所提及,依據文法,「最後結尾處」,要麽是無所限(包括正文)的「最後結尾處」,要麽是繼承前一句主語的「圖或表的短语式说明文字最後結尾處」。前一種理解,顯然不合語序而且荒唐;後一種理解,不與範例自洽。而理解爲挖空「圖或表的短语式说明文字最後結尾處」中間三個字「短语式」的「圖或表的说明文字最後結尾處」更不合文法,亦不能與限定詞「短语式」及遣詞造句自洽。--— Gohan 2024年11月8日 (五) 08:16 (UTC)
第一點意在突出閣下的「歸謬」並無「歸到謬」,關乎閣下的論證。--— Gohan 2024年11月8日 (五) 08:17 (UTC)
(+)支持,至少在澳門,的確有圖片描述一句不用句號,兩句或以上用句號的習慣,例如澳門政府澳門日報正報。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年10月28日 (一) 16:31 (UTC)

綜上理由,以及避免過度妥協,又鑒於引號等亦屬於適當的收尾標點,向社群提供以下四版本修訂案:

  • 版本A:(清晰表明二種用法並存)
現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 句2:圖、表的說明文字若屬短語,末尾不用句号;若爲句子語段,末尾可用、可不用句号等標點。
  • 版本B:(最符合前次討論無人反對的多數意見,對各情形指引詳盡)
現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 句2:圖、表的說明文字若屬短語,末尾不用句号;若爲中間已有句号的語段,宜有句号或其他適當標點收尾。
  • 版本C:(減少上述中國大陸標準是否覆蓋「非短語式說明文字」的爭議)
現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 句2:圖、表的說明文字若屬短語,末尾不用句号;若爲句子語段,遵循其餘標點符號規定。
  • 版本D:(完全避免上述中國大陸標準是否覆蓋「非短語式說明文字」的爭議,然而範例不足而可能被人誤解)【此版本修訂已無「句2」,故本句上方的「句1」相應去除序號1】
現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 短語:圖、表的說明文字若屬短語,末尾不用句号。

Gohan 2024年10月30日 (三) 11:15 (UTC)

对版本A(=)中立(见上段讨论),对版本B、C、D反对。--自由雨日🌧️留言贡献 2024年11月1日 (五) 14:27 (UTC)
版本D可謂完全出自中國大陸標準,爲何反對?「其餘標點符號規定」亦未強制任何情形必用句號,又爲何反對版本C?--— Gohan 2024年11月2日 (六) 08:59 (UTC)
版本D未对“就算有时说明文字内容比较长,在前面的语段中已用句号”的情况如何处理进行说明。版本C认为“维基娘是维基百科萌拟人化后的美少女角色。由日语维基百科人创作”(即不加句号)是错误用法,这与中国大陆标准中“经过治理,本市市容市貌焕然一新。这是某区街道一景”(即不加句号不仅正确,甚至是必须)的用法相违背。--自由雨日🌧️留言贡献 2024年11月2日 (六) 09:24 (UTC)
爲何必須特別規定「就算有时说明文字内容比较长,在前面的语段中已用句号」的不明之物(圖或表的短語式説明文字?圖或表的任何説明文字?)?本手冊亦未統一規定脚註等用不用句號收尾,在現實中脚註結尾有無句號皆有。故不特別規定「就算有时说明文字内容比较长,在前面的语段中已用句号」之情形,版本C、D仍能達到如同脚註一般,有無句號並存之效。如果版本C去除「維基娘」兩例,您可否接受?--— Gohan 2024年11月4日 (一) 10:55 (UTC)
并不是说“必须特别规定”,只是原先有规定,且可以用版本A清晰表示“改变了过去的规定,现在两种用法可并存”,不认为完全删去有比A更好的好处。版本C中的“若为句子或语段,遵循其余标点符号规定”同太过模糊,我认为不如版本A。--自由雨日🌧️留言贡献 2024年11月4日 (一) 15:18 (UTC)
版本A一大缺陷在於,或是世界中文史上首次明確規定句段末尾可不用句號的規範——本人不想承受大有可能是惡果的此責。版本C、D對此不作特別規定,不「搞特殊」,平等視之,更爲靈活。--— Gohan 2024年11月5日 (二) 10:07 (UTC)
现行条文(即原条文)不仅是“明确规定句段末尾可不用句号”,甚至是“必须不用句号”,所以版本A(提议条文)显然不可能是所谓“世界中文史上首次”(就算是首次,那也是原条文“首次”),更遑论中华人民共和国国家标准的用例“经过治理,本市市容市貌焕然一新。这是某区街道一景”早已表示不用句号。--自由雨日🌧️🌨️ 2024年11月5日 (二) 10:25 (UTC)
請您細讀,現行條文並非如此規定,任何一句主語皆非「句段末尾」。中國大陸標準亦非如此規定(規範)。不再贅述。--— Gohan 2024年11月5日 (二) 10:29 (UTC)
版本太複雜了,總之我的意見跟Cdip150等人一樣,並希望能提供適度說明。—— Eric Liu 創造は生命(留言留名學生會 2024年11月2日 (六) 10:50 (UTC)
所有版本差異,是出於中國大陸有關標準(「图或表的短語式說明文字,中間可用逗号,但末尾不用句号。即使有时说明文字较长,前面的语段已出現句号,最后结尾处仍不用句号」)是否覆蓋「非短語」具有爭議,而在不同程度上兼顧「避免此爭議」與「詳盡引導」而設。對於不在意此爭議的人而言,多數版本(在其上已有簡短説明)效果差異甚微,可一並支持,甚或評點優劣,選出最優版本。--— Gohan 2024年11月4日 (一) 10:56 (UTC)

擬定及公示

由於其餘版本被反對,擬採用並在不久後公示版本A,亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNullGohan 2024年11月5日 (二) 10:48 (UTC)

即刻起公示版本A七日。--— Gohan 2024年11月14日 (四) 00:12 (UTC)
(?)異議:「维基百科标志。」不能视为句子吗? ——魔琴身份声明 留言 贡献 新手2023 2024年11月14日 (四) 20:29 (UTC)
若無前文,此語一般不視作句子?若可視作句子,請問如何修改?將「若為句子或語段」改爲「若非短語,而是句子或語段」可否?--— Gohan 2024年11月15日 (五) 09:58 (UTC)
不知道。@自由雨日。 ——魔琴身份声明 留言 贡献 新手2023 2024年11月15日 (五) 18:51 (UTC)
或许可将“若属短语”改为“若不是句子”。当然,这样改依然有“‘维基百科标志’可以视作句子”的问题。但既然标准本身已存明显争议,我认为不必再在用词细节上纠结;甚至完全放开——即允许“维基百科标志”末尾也可带句号——我也不反对。--自由雨日🌧️❄️ 2024年11月15日 (五) 18:57 (UTC)
我的提議改法無此問題。因爲需要同時滿足「非短語」與「是句子或語段」兩個必要條件,而「维基百科标志」顯然不滿足第一個必要條件。另外,短語式説明的標準(不變)尚不具爭議,而且獲得兩次討論多數意見認可。爭議一向在非短語式説明。--— Gohan 2024年11月16日 (六) 02:59 (UTC)
「不知道」是對「若無前文,此語一般不視作句子」,抑或是對其餘兩問?由於「若無前文,此語一般不視作句子」是對您的異議的直接回應,欲求您的看法;若對此無異議,則無需跟進處理。--— Gohan 2024年11月16日 (六) 02:57 (UTC)
@魔琴--— Gohan 2024年11月18日 (一) 02:37 (UTC)
再認真讀了一下,覺得您的版本可以。自由雨日版本並沒有解決這個問題。亦不反對维基百科标志末尾也可带句号,畢竟上方討論中也有類似用例。 ——魔琴身份声明 留言 贡献 新手2023 2024年11月18日 (一) 02:59 (UTC)

異議解決,修訂為以下版本A-2,立即重行公示7日:

現行條文
  • 句2:图片和圖表的短語說明,其中部内容可用逗号,但末尾不用句号。就算有时说明文字内容比较长,在前面的语段中已用句号,最后结尾处仍不用句号。
提議條文
  • 句2:圖、表的說明文字若屬短語,末尾不用句号;若非短語,而是句子語段,末尾可用、可不用句号等標點。

Gohan 2024年11月18日 (一) 03:29 (UTC)

公示期屆滿,修訂通過。--— Gohan 2024年11月25日 (一) 04:40 (UTC)