維基百科

維基百科討論:格式手冊/標點符號/存檔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」。