維基百科討論:格式手冊/標點符號/存檔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)
- founder部分不會啊,不就說了「創辦之時未離世」嗎?--路西法人𖤐 2022年2月18日 (五) 05:57 (UTC)
- 那我還是一樣反對在任何條件中使用示亡號。董事長當然會被取代啊,所以我上頭只提「founder部分」,沒提董事長。--寒吉 2022年2月16日 (三) 11:41 (UTC)
- 創辦之時未離世,董事長之位會被取代(不是其獨有)。--路西法人☆ 2022年2月16日 (三) 02:21 (UTC)
先說我本人的淺見。我認為在百科全書標示亡號完全沒必要。百科全書是要流傳千古的,也就是說,總有一天書上所有條目裡的所有人名都是死人,那就全都要標示亡號。全都要標就等於全都不標,標了還浪費時間精力。百科全書皆如此,不獨維基為然。
可行的用法,就是在實際生活上的用法,也就是事件來臨時相關人物已經不在了。例如候選人於競選活動開始前死亡(美國發生過),影業人員在影片發行前死亡(如英雄本色中的石燕子,不過有疑義)等等。但現在某些維基編輯的用法是看到哪個公眾人物死了,就忙不迭把相關條目全翻出來,一個一個替人標示亡號。所以這就涉及定義了:示亡號是用於表示看到條目時人已經不在了,還是表示事件發生時人已經不在了?我認為是後一種,各位呢?這點要列為方針嗎?
前面說到疑義,是有的事件發生不止一次。例如英雄本色上映時間各國不同,以何為準?還是就乾脆不用標了?
謝謝各位撥冗看我囉唆一堆細節。--以上未簽名的留言由2603:8000:500:FB00:5011:1E64:1DB0:C8F1 (討論)加入。 —以上未加入日期時間的留言是於2022年2月20日 (日) 08:14 (UTC)之前加入的。
- 會否有人於古代條目為所有人標上示亡號?--Temp3600(留言) 2022年2月23日 (三) 14:58 (UTC)
- 示亡號不應用於正文,也只應用於「進行中死亡」的情況。理論上是不行。--路西法人𖤐 2022年2月23日 (三) 15:46 (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)
建議重新審視這條格式規範和共識。
- 首先,個人認為MOS:。中第二例在去掉末尾句號後反而更不美觀和段落不清晰。
- 檢查來看,該要求源自2013年由烏拉跨氪主筆並討論和公示通過的格式指引,基於中華人民共和國《標點符號用法》(GB/T 15834—2011)[1]的附錄A第一條,且不少機構的格式規範文件有參照此條做相同規定[2][3][4]。
- 但其一,公示通過前Gqqnb對該條提出了相反的格式意見,不過討論以「標準」所定結束。沒有找到其他討論來強化該條指引的共識性。該標準為中國大陸的「GB/T」(國標/推薦),應該思考為什麼這樣做、是否這樣做,而不是簡單地「也要這樣做」。
- 其二,也是比較重要的,仔細搜索看到了一些豁免解釋和相反意見。
如果說明文字在圖片或表格的正下方,則與一般文段句號的用法相同,在句末使用句號。
[5]針對科技論文圖表中的注釋句末是否用標點符號的問題,GB/T1.1—2009《標準化工作導則第1部分:標準的結構和編寫》關於圖題、表題和圖注、表注的示例明確告訴我們:圖題、表題的末尾不用任何點號;而圖注、表注末尾要用句號。
科技論文插圖中除「注」「腳註」外,也有「說明文字」,三者通稱圖注。按照GB/T1.1—2009給出的示例,這類插圖的「說明文字」末尾也要用句號。
[6][7]文章中有時會出現插圖或表格等形式,其說明文字可能出現在上一段文字的末尾,也可能出現在圖片或表格的正下方。如果出現在上一段文字的末尾,不管說明文字的長短,結尾都不用句號。如果說明文字在圖片或表格的正下方,則與一般語段中的句號用法相同,結尾要用句號。
[8][9]如果出現在段尾,說明文字末尾通常不加句號。有時說明文字是一段話,前面已經使用了句號,在最後的結尾處仍不使用句號。
如果說明文字在圖片或表格的正下方,則與一般文段句號的用法相同,在句末使用句號。(如:行刑場景,上海,19世紀70年代。斬首為中國……。中國在1905年以槍決代替斬首。
[10]- (以上內容摘錄僅用於學習、研究目的,版權歸屬原作者/書籍)。
關於「如果出現在段尾」,個人理解,可能指「正文-說明文字-表格/圖片」的排版方式,這種情況下句號會分隔解釋與「圖或表」,從而不應。對於混排時懸浮(如右對齊)的圖片下方的說明文字,除非不成句(如很短,中間沒有任何逗號/句號/問號/驚嘆號等),否則可能認為應加注句號以表示語句結束。 --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)
參考資料
- ^ https://people.ubuntu.com/~happyaron/l10n/GB(T)15834-2011.html
- ^ 咬文嚼字——圖片下面的文字末不用句號
- ^ 中國科學技術大學 研究生學位論文撰寫手冊,
- ^ 黨政機關公文中標點符號使用應遵循國家標準 四平市審計局 任傳寶
- ^ 【業務學習】標點符號用法解讀之句號 - 《蚌埠工商學院》編輯部
- ^ 科技論文圖表中的注釋句末應用句號 《西部醫學》 2016年第11期1488-1488
- ^ 郝遠.科技文稿中的圖注、表注末尾用句號嗎?[J].編輯學報,2014(1).
- ^ 新國標標點符號使用手冊 蘭賓漢 2014-9-16 出版社:中華書局
- ^ 《標點符號用法手冊》 蘭賓漢 2015年1月 商務印書館,內容應同上
- ^ 網友摘錄,《標點符號用法》解讀 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)
- 事實上我在PDF看到的是半形括號,但是確實很多的學報的顯示方式都不同,名稱也有異,如果不肯定就通通重定向。--Ghren🐦🕛 2022年7月10日 (日) 04:43 (UTC)
- 很簡單,因為很多期刊自己就不太在意自己期刊名字寫法的細微區別--百無一用是書生 (☎) 2022年7月12日 (二) 02:39 (UTC)
- 已移動後者至自然-生物技術。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年7月24日 (日) 11:44 (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)
跨年份(度)的體育賽季條目命名
2022年了,希望解決相關條目命名格式不一致的問題。過去討論存檔:2009年2月、2012年11月、2014年7月、2018年12月、2021年10月。
「2020–21 ABC(season)」在中維該命名為以下哪種(假設須加上「年」)
- 「2020-21年(度)ABC(賽季)」
- 「2020年-21年(度)ABC(賽季)」
- 「2020至21年(度)ABC(賽季)」
- 「2020年至21年(度)ABC(賽季)」
- 「2020/21年(度)(賽季)ABC」
- 「2020-2021年(度)ABC(賽季)」(年份全展)
- 「2020年-2021年(度)ABC(賽季)」(年份全展)
- 「2020至2021年(度)ABC(賽季)」(年份全展)
- 「2020年至2021年(度)ABC(賽季)」(年份全展)--寒吉(留言) 2022年6月30日 (四) 15:51 (UTC)
- 列出過去討論中曾被引用的方針與指引:WP:格式手冊/標點符號#連接號、WP:命名常規#連接號的使用、WP:格式手冊#時間、數字、度量衡。
- 參閱WP:常用名稱:「條目命名應該儘量使用可靠來源中人、物或事項的常見的名稱」,討論達成共識之後應將共識加入WP:命名常規。
- 我的意見:支持6及9。--CaryCheng(留言) 2022年7月1日 (五) 02:59 (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)
- 是否全面統一還有待商榷,但至少同個聯賽的賽季格式要統一,比如Category:英格蘭足球超級聯賽就需統一,也須解決連接號問題。您是第一位提出要使用「到」字的用戶,過往討論都提出使用「至」字,所以我才只列出「至」字方案。--寒吉(留言) 2022年7月12日 (二) 04:15 (UTC)
人物條目使用T:box
- 需要討論的條目:陳百強、廖啟智、蔡若蓮等(詳見Special:用戶貢獻/陳康健老師中編輯摘要為「加示亡號」及「加box」等編輯)
- U:陳康健老師在數個條目中為逝去人物加上{{box}}。
- WP:格式手冊對於逝去人物是否加上{{box}}並無規範。
- 我認為在任何條目中為逝去人物加上{{box}}不是良好的格式,違反WP:格式手冊#不要花哨華麗。
- 請社群提供意見,是否應刪去逝去人物的{{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:死者列表裏面(都在死者列表了自然也不用加框)。怎麼會是在那邊說這樣清單會有一大堆加框,會有這種情況是不是清單塞太多東西了?
- 順便偷抱怨一下,那一堆前XXX職位分類是怎樣,像什麼Category:前無綫電視藝員、Category:前無綫電視新聞報導員。照最終人都會死的說法來講,人也都會離職啊。
- 另外感覺有些列表莫名其妙,就應該只列目前在職。其他情況應該另列清單,如離職、解職,另外開一個卸任列表或什麼的。已故更是應該另外開一個清單然後分類到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(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)
該不該把影視作品、音樂與電子遊戲列表中的作品名稱加上書名號?
我發現大部分的列表都沒有把作品名稱加上書名號,但我認為應該要加上比較正式,請問如果以這個方向進行編輯的話,應該不會被當成無意義的編輯而被回退或警告吧? --Picture GN(留言) 2022年10月2日 (日) 17:50 (UTC)
- 反對反對,認為在句子裏才需要加書名號。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年10月2日 (日) 18:01 (UTC)
- 個人認為應當加,為了省事或格式本身太亂可能不加,但加上應該是對的。MOS:書名號。此筆編輯中,「專曲」也許該用雙書名號?--YFdyh000(留言) 2022年10月2日 (日) 20:53 (UTC)
我認為如果可以的話,能夠把這個議題搬上檯面,讓社群對此產生共識,最終目標是在格式手冊載明此情況是否使用書名號。(目前的格式手冊沒有明顯的指示)--Picture GN(留言) 2022年10月3日 (一) 05:11 (UTC)- 此專曲如果指的是一首歌,就是使用單書名號,如果是一部專輯,則是使用雙書名號。我在網路上以此名稱查詢到的結果,是一首歌,因此使用單書名號。如果有錯誤的話,還請多多指教。--Picture GN(留言) 2022年10月3日 (一) 13:12 (UTC)
- --YFdyh000(留言) 2022年10月3日 (一) 18:57 (UTC)
- ( ✓ )同意,以上提議皆支持,但是歌曲與專輯同名的狀況確實需要熟悉該主題的人再度確認。--Picture GN(留言) 2022年10月3日 (一) 23:59 (UTC)
- 如果是像我這樣的普通讀者,看到<某某>或《某某》,並不會因為書名號的差異就立刻知道這其中一個是歌曲,另一個是專輯。我的建議是儘量在文字裡加以說明《某某》歌曲、《某某》專輯,這樣對普通讀者比較友好。另外,同意樓下的格式手冊內容,對於列表裡面,已經在表格寫清楚是歌曲或專輯了,倒是不必再加書名號。--生米一粒(留言) 2022年10月16日 (日) 22:22 (UTC)
- ( ✓ )同意--Picture GN(留言) 2022年10月17日 (一) 00:07 (UTC)
- 如果是條目名稱的話,不建議添加,因為相對於正文,沒有和正文般的上下文衝突,正文中最好是添加,而區分出上下文中它是一個作品名。——Sakamotosan路過圍觀 | 避免做作,免敬 2022年10月3日 (一) 02:15 (UTC)
- 我想請教您對於列表中(列表本身,不包含條目正文或條目名稱)的作品名稱要不要加書名號的意見。--Picture GN(留言) 2022年10月3日 (一) 05:07 (UTC)
- 按WP:LOW可加可不加。個人傾向是不在上下文中不加書名號。書名號是方便在語段中分詞的。列表(特別是表格式列表)已經清晰劃出了作品標題,再加書名號很臃腫。—洛普利寧 2022年10月3日 (一) 06:19 (UTC)
- 原來格式手冊有寫到,感謝您的提醒與意見!--Picture GN(留言) 2022年10月3日 (一) 11:39 (UTC)
- 學到新東西!-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年10月3日 (一) 14:51 (UTC)
- ( ✓ )同意:列表裡面都放看起來好臃腫
,像那個二十四史模ㄅ...(被拖走)--Anghualee(留言) 2022年10月3日 (一) 16:37 (UTC)- 這個舉例說服了我,看來有統一格式的列表確實不必要加上書名號。--Picture GN(留言) 2022年10月4日 (二) 00:05 (UTC)
- 洛君您說得有理,高見!我之前都沒想過。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年10月5日 (三) 14:22 (UTC)
- 除了作品列表,還是演員/配音員的條目的演出列表,不加上書名號好像是很常見的情況。如早見沙織。有加上的如尼古拉斯·凱奇。--Nostalgiacn(留言) 2022年10月5日 (三) 07:21 (UTC)
XX系列(遊戲、影視、文藝作品系列)的書名號位置?
請問遊戲、影視、文藝作品系列(的正文,不含條目標題)需要加上書名號嗎?如果要加,「系列」二字該被囊括在書名號之中嗎?MOS:書名號僅提及「系列著作的選題名」,但是有些系列作品的名稱本身沒有「系列」二字,例如:星海爭霸系列、紅色警戒系列的各項遊戲名稱皆沒有「系列」二字。
各位認為下列哪一項比較好:
- XX遊戲/電影/小說系列
- 《XX遊戲/電影/小說》系列
- 《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)
- 大部分情況都是出了作品的主名,然後沿著主名衍生了多個分作品,在本站點中將這些事物概括成一個「系列」再統合編寫。可能很少作品原名(或系列名)即為「XXX系列」。似乎不能一概而論規定如何添加書名號。——Sakamotosan路過圍觀 | 避免做作,免敬 2022年10月8日 (六) 05:55 (UTC)
- 除非特指名稱含「系列」的出版物,否則書名號內不要包含「系列」。是否加書名號看需求,是否有強調目的。--YFdyh000(留言) 2022年10月7日 (五) 06:10 (UTC)
- 敝人糾結的點在於,該不該把「XX系列」視為創作/作品的名稱,如果是,則應該要加上書名號;如果不是,系列就不應該在書名號之中,但XX是否要加上書名號?--Picture GN(留言) 2022年10月7日 (五) 05:45 (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)
- 所以變成《XX》「系列」? --窩法乙烷 兒法夢碎 2022年10月15日 (六) 04:12 (UTC)
修訂格式手冊的標點符號中頓號的用法
我發現好多條目中都有《書1》、《書2》
或者是「引用1」、「引用2」
的寫法,但是根據中華人民共和國國家標準 GB/T 15834―2011:
“ | 4.5.3.5 標有引號的並列成分之間、標有書名號的並列成分之間通常不用頓號。若有其他成分插在並列的引號之間或並列的書名號之間(如引語或書名號之後還有括注),宜用頓號。 | ” |
所以這種寫法應該不符合大陸的規範。但我不清楚其他地區是如何規定的。若規定一致,建議將該規範添加至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)
- ( π )題外話「可讀性明顯更高」→「明顯更易讀」。可讀性這些粗劣用語真是酸腐可笑。
- ——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年1月29日 (日) 09:50 (UTC)
- ( π )題外話&(:)回應:可讀性也是字體排印學術語,不單是余老所說閱讀、寫作用義。--PexEric 💬|📝 2023年1月30日 (一) 09:02 (UTC)
- (:)回應:無論是否術語也好,根本就不該用,即使是格式、排版也可只說易/好/難+讀/閱/看,不須畫蛇添足加個「性」字。
- ——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年1月31日 (二) 15:40 (UTC)
- (:)回應:所以「親水性明顯更高→分子明顯更容易透過氫鍵和水分子形成短暫鍵結」?-游蛇脫殼/克勞棣 2023年2月2日 (四) 16:59 (UTC)
- (:)回應濫用的是「性」字,不是術語其它部份,你那句可改成「明顯更親水」。——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年2月4日 (六) 14:06 (UTC)
- 你能不能不要在專業範疇上的用詞也這樣胡亂橫插一腳,「親水性」都已經算是化學範疇上的專有名詞了。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月5日 (日) 01:22 (UTC)
- 量度連續物理量的用字尚有度、量、力等字,「性」是用於酸鹼等二元對立的性質,這是定「性」和定「量」分析之別,量度分子有幾親水是連續量不是二元量,實在應該用「親水度」、「親水力」,而非濫套二元對立的「親水性」。--——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年2月5日 (日) 14:01 (UTC)
- 可是「親水性」這個專門術語又不是在下發明的,而且我懷疑它是否真的如閣下所說,是錯誤的濫套。至於閣下說「親水性明顯更高」可改成「明顯更親水」,我就不認同了,因為專門術語並非總是能無縫替換成普通詞語,如果您認為此更改是對的,在下倒想請教:肥皂和冬山河親水公園何者更親水?-游蛇脫殼/克勞棣 2023年2月5日 (日) 14:40 (UTC)
- 所以我才説你是「中華極端主義」。也容許我提醒你一點:中文維基百科不接受你這種原創研究,所以你可千萬不能把你這種觀點帶進條目裏,不然的話整個中文維基百科都要被你毀了。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη - Μπαλόνια πρέπει καταστραφούν 2023年2月6日 (一) 12:34 (UTC)
- 既然如此,為何閣下會認為「親水性明顯更高」可改成「明顯更親水」?明明肥皂只有「親水性」(或您建議的「親水度」、「親水力」)可言,肥皂根本無所謂「(比某物質)明顯更親水」。親水性是親水性,親水是親水。-游蛇脫殼/克勞棣 2023年2月6日 (一) 16:40 (UTC)
- 親水度只可用於比較化學物(質),不可用於公園;「(比某物質)明顯更親水」意在比較兩化學物質的親水程度,這樣說並沒問題;如只說某化學物(+很/甚為等詞)親水其實也不應有問題,「某物很親水」就解「某物的親水度高」。引伸回原問題,說某種排版形式(比另一種)易讀/難讀就夠,你又不是要量度它,你平時(不在量度物件時)會不會說該物長度/重量/高度很高?——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年2月9日 (四) 15:14 (UTC)
- 量度連續物理量的用字尚有度、量、力等字,「性」是用於酸鹼等二元對立的性質,這是定「性」和定「量」分析之別,量度分子有幾親水是連續量不是二元量,實在應該用「親水度」、「親水力」,而非濫套二元對立的「親水性」。--——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年2月5日 (日) 14:01 (UTC)
- 你能不能不要在專業範疇上的用詞也這樣胡亂橫插一腳,「親水性」都已經算是化學範疇上的專有名詞了。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月5日 (日) 01:22 (UTC)
- (:)回應濫用的是「性」字,不是術語其它部份,你那句可改成「明顯更親水」。——勿用「進行」污染中文,要言簡意賅。 捍粵者 2023年2月4日 (六) 14:06 (UTC)
- (:)回應:所以「親水性明顯更高→分子明顯更容易透過氫鍵和水分子形成短暫鍵結」?-游蛇脫殼/克勞棣 2023年2月2日 (四) 16:59 (UTC)
- ( π )題外話&(:)回應:可讀性也是字體排印學術語,不單是余老所說閱讀、寫作用義。--PexEric 💬|📝 2023年1月30日 (一) 09:02 (UTC)
- 大致來說,是因為書名號、引號本身已經有分隔字眼的功能,所以認為宜用不頓號。但實話,這個標準在大陸爭議也滿大的。--Ghren🐦🕓 2023年1月29日 (日) 09:29 (UTC)
- 個人傾向長一點成分間還是用頓號錶停頓,沒頓號分隔感覺氣喘不上來。比如
--洛普利寧 2023年1月29日 (日) 13:43 (UTC)媒體稱讚作品是「近20年來最精彩的科幻小說」、「為日本近年來科幻小說之最」、「比肩《夜幕低垂》」[1][2][3]。
- 個人傾向長一點成分間還是用頓號錶停頓,沒頓號分隔感覺氣喘不上來。比如
- 還是一如既往地反對這個提議,只有中國大陸有這種情況,其他情況下書名號之間的頓號屬於正常使用。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)
- 我覺得可以,但感覺可能把馬來西亞與新加坡的情況也添加一下更好。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月4日 (六) 08:54 (UTC)
- @Shenzhiming88:那要看看你具體的提及方式是怎樣了。如果具體的提及方式合適的話,我倒是不反對這樣做。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月4日 (六) 07:57 (UTC)
- 既然如此,那就不添加這個大陸獨有的標準了吧。但是是否有必要在格式手冊中提及該情況,說兩岸四地用法不同呢?--Shenzhiming88(留言) 2023年2月2日 (四) 14:52 (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)
- @Anghualee:不一定構成文章,但有時一句話不夠用。以此條目正文圖片為例。第一句話描述圖片本身內容,第二句話呼應正文「長槍剋劍,劍剋斧,斧剋長槍」(WP:NFCC#8,版權圖片應有助正文理解)。這用一句話可能不好表述。--洛普利寧 2023年2月9日 (四) 14:09 (UTC)
- 這裡有一篇文章對這個問題做了解釋,供各位參考。--InstantNull(留言) 2023年2月9日 (四) 18:51 (UTC)
- @Lopullinen:似乎有初步共識,可以考慮繼續推進。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年2月24日 (五) 01:52 (UTC)
Wikipedia:格式手冊/標點符號#書名號新增使用Template:《的方法,修改使用代碼的方法,並調整「效果為」的位置
|
|
- 新增Template:《的方法,參見Template:《。
- 修改
zh-hans:《;zh-hant:〈;
為zh-hans:《;zh-tw:〈;zh-hk:《;
,否則在香港繁體下,模板的結果和代碼的結果不一致。 - 調整「效果為」的位置。
——小林子沖(留言) 2023年2月21日 (二) 05:28 (UTC)
- ( π )題外話:單雙書名號可以設置地區詞處理,為什麼「標有引號的並列成分之間、標有書名號的並列成分之間通常不用頓號」不設置地區詞處理,甚至還有用戶說「有地域中心之嫌」?——小林子沖(留言) 2023年2月21日 (二) 05:34 (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)
- YF君原話是
- 那個討論我有看,也有發過言。Y君說的是不推薦也不反對,總之是沒有人明確反對在大陸使用此案就是了。您可以說有人提出在該討論說過該標準在大陸爭議,然後您反對,而不是直接說解決該討論的反對意見。謝謝。Ghren🐦🕚 2023年3月2日 (四) 15:21 (UTC)
- 您可以再讀一次討論,有留言指出雖然被列為標準但僅為新設且民間仍有不認同的聲音。--路西法人 2023年3月2日 (四) 14:43 (UTC)
- 上次反對的是直接兩岸三地都將之視為標準吧,但沒有反對在大陸使用此方案啊。--Ghren🐦🕓 2023年3月2日 (四) 08:11 (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:命名常規 (國際關係)中的
方針部分衝突。之前將國際關係命名常規升為格式指引的提案中已經有編者討論,但看來毫無進展。@維基百科最忠誠的反對者、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)
- @PexEric(*)提醒:WP:命名常規 (國際關係)中的方針部分並不涉及連接號。只有「外交代表機構命名」一節是方針,涉及連接號的是其他章節。--愛維基百科的CuSO4 2023年3月19日 (日) 09:21 (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)
- @Sanmosa:真是抱歉!要是一開始我意識到了不要地域中心,就不會提出這個討論串了。這樣常用的方針您提醒之後我才想起來,實在不應該。——愛維基百科的CuSO4 2023年4月3日 (一) 16:30 (UTC)
連接號一字線的符號選擇
提議:當前MOS:連接號一字線的符號選擇"U+FF0D - FULLWIDTH HYPHEN-MINUS"不是通行的做法。改用 U+2014 — EM DASH 是更好的選擇。
之前已經有多次討論,大部分編輯表示支持,但都沒有繼續推進:
- Wikipedia_talk:格式手冊/標點符號/存檔1#拋棄全形連字符(U+FF0D),改用em_dash(U+2014)字符表示「一字線」連接號
- Wikipedia_talk:格式手冊/標點符號/存檔2#又議格式手冊標點符號中的連接號
- Wikipedia_talk:格式手冊/標點符號/存檔2#連接號字符
總結起來:
- U+FF0D - FULLWIDTH HYPHEN-MINUS是短橫線 U+002D - HYPHEN-MINUS的全形版本,二者應該表達相同的含義,不應重複使用。既然短橫線已經選擇了 U+002D - ,一字線就應該選用其他字符。
- 使用 em dash 對字體渲染有更好的支持。
- 使用 em dash 作為連接號是中文印刷品中的主流選擇。
- 全形連字符U+FF0D - 從未被廣泛使用過。(除了中文維基百科)
- 多數中文字體對全形連字符的支持並不理想。
- 一字線應當恰好占據一個字符(即一個 em 長度)。
- 一字線應當恰好是破折號的一半。
因此建議推薦使用 U+2014 — EM DASH 作為一字線的符號,不再把 U+FF0D - FULLWIDTH HYPHEN-MINUS 作為推薦的符號,但也並不將其列為錯誤用法。
|
|
--InstantNull(留言) 2023年2月8日 (三) 20:15 (UTC)
- 不認同字符選擇與表達含義間存在關聯
- 在默認及常見字體中未見明顯證據
- 部分承認(即便在正規印刷品中,002d也有一定使用,雖然可能是誤用)
- 承認
- 在默認及常見字體中未見明顯證據
- 在微軟雅黑中2014略長於em,反之ff0d未見問題
- 未見可靠出處
- 綜上反對提案。--。->>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 - 的全形版本(您可以參考全形和半形了解更多),它們本質上是同一符號的不同字符表示,在中文裡同時混用是不恰當的。就如同我們不應該在中文裡同時使用半形「/」和全形「/」是一個道理。
- 關於(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)
- 1. 我關心的是中維常年使用ff0d,現狀是否對文章內容的表達產生了歧義?字符的定義在這裡並沒有特別強調的必要。即便如
- ( π )題外話:無論一字線用什麼符號,美國-墨西哥-加拿大協議按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)
- 是的,所以我其實並不建議將原符號算作錯誤使用。較好的做法是將標準改正,確保新條目和新文章使用正確標準,並向後兼容,讓社區自己逐漸修正。--InstantNull(留言) 2023年2月10日 (五) 17:30 (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)
- 獨裁社群果不其然硬是通過討論,而且已經明確指出問題了還只會裝傻。像這種公示7天只是意思意思走形式流程的獨裁社群,以後寫維基百科的人只會越來越少,因為這嚴重剝奪了編輯者的權益。--Z7504非常建議必要時多關注評選(留言) 2023年3月19日 (日) 16:33 (UTC)
- 當否人的言論蠢到你懷疑是不是反串。你該不會認為「-{}-」和「<!---->」也要改吧? --窩法乙烷 兒法夢碎 2023年3月19日 (日) 14:11 (UTC)
- ???—— Eric Liu 創造は生命(留言・留名・學生會) 2023年3月19日 (日) 05:22 (UTC)
- 那請問像是「{{lang-en}}」是要強迫用戶都改成使用「{{langU+2014en}}」才甘願嗎?這種鬼提案到底是誰想的也不動動腦筋,想當然只好(-)強烈反對啊。難道還要舉例嗎?獨裁的爛社群。--Z7504非常建議必要時多關注評選(留言) 2023年3月18日 (六) 10:39 (UTC)
- 並非格式不能自由,而是既然我們已經在格式方面達成共識了,並且格式手冊長期以來就有一致性的格式要求,那麼大家應該遵守共識,維護共識,積極創造條件以更好維護原本的共識,共識才是約束的條件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)
- 首先我建議這位編輯 stop crying. 您這樣將您不喜歡的提案怪罪於社群無助於解決任何問題。本提案自提出已有一月有餘,大部分編輯表示支持,對部分異議我也做出了解釋和調整。且有關議題在過去幾年已經多次做了充分討論,過往的意見也多數表示支持。整個過程公開透明,哪裡「獨裁」?何來「強行通過」?您有反對意見可以提出,社群歡迎建設性討論,但哭鬧不會使您的觀點更具有說服力,錯誤的習慣也仍然是錯誤。--InstantNull(留言) 2023年3月13日 (一) 04:53 (UTC)
- 格式手冊已修改。--Lt2818(留言) 2023年3月19日 (日) 13:49 (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)
- Eric Liu 創造は生命(留言・留名・學生會) 2023年3月20日 (一) 01:30 (UTC)
- 上方「受影響項目頁」連結中命名空間編號為10的就是模板。(似乎單獨列出的必要性不大?)--Lt2818(留言) 2023年3月20日 (一) 13:36 (UTC)
(我的意思是模板標題)——
- Eric Liu 創造は生命(留言・留名・學生會) 2023年3月20日 (一) 01:30 (UTC)
- 模板內U+FF0D內鏈--Lt2818(留言) 2023年3月14日 (二) 13:33 (UTC)
- U+2500影響的頁面也有40個,可一併處理。--PexEric 💬|📝 2023年3月19日 (日) 10:53 (UTC)
- 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)
還有沒有其他類似的符號?可以考慮一併列出。—— - 連接號#相關符號和破折號#電腦應用已經列的很詳細了,加上制表符里的U+2500,還有漢字「一」[開玩笑的]。--PexEric 💬|📝 2023年3月20日 (一) 14:31 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2023年3月20日 (一) 01:30 (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)
- 機器人可以只批量修正U+FF0D到U+2014(em dash),U+002D(en dash)本來就不用管;U+2500是制表符,用作頁面名是錯誤用例。--PexEric 💬|📝 2023年3月20日 (一) 14:22 (UTC)
- 個人以為,西班牙語人名的條目會受到這個震撼彈決定影響,是否通知WikiProject:西班牙、WikiProject:墨西哥、WikiProject:秘魯、WikiProject:古巴等?--Liuxinyu970226(留言) 2023年3月21日 (二) 04:13 (UTC)
- 人名應用「-」且現有多數條目已如此,不會受影響。--紺野夢人 2023年3月21日 (二) 07:41 (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)
- 我看了一下《重訂標點符號手冊》修訂版連接號,發現大概因為使用的字體不同,標楷體看起來還好,細明體就有點突兀。或許我們能問問教育部看看他們有無定論?--Kanashimi(留言) 2023年4月12日 (三) 07:33 (UTC)
- 但規範如此,沒辦法。《重訂標點符號手冊》的例句中就有「西元1811—1872年」。--Lt2818(留言) 2023年4月12日 (三) 07:21 (UTC)
- 我的意思就是這樣的頁面滿多的,搞不好比現在使用em dash的還多?那麼這樣會不會有紊亂的情況?畢竟本次提案的初衷之一也是為了避免紊亂。我個人在數字範圍的情況下其實比較偏好en dash,再怎麼說我們不是用中文數字,em dash實在太長了...--Kanashimi(留言) 2023年4月12日 (三) 06:54 (UTC)
- 個人向來反對沿襲西方常用之省略年份形式,並認為合理之命名格式為完整的「2022年—2023年」(前一個年可以省略,但後面不行,因為英文中「2023」的中文翻譯是「2023年」)。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年4月11日 (二) 13:34 (UTC)
- 我認為這不能算作中英混雜的情況。首先賽季是一個代碼或序列號嗎?個人認為不是,NBA也沒有硬性規定。其次明白英語維基的格式是怎麼來的,英語維基格式手冊建議時間跨度使用
- 我的意思是應該考慮到中英文交雜的情況,就現在看來似乎沒規範到這部分?另外就上面所提到的,許多年份已經採用 en dash,這個部分是否該統一?--Kanashimi(留言) 2023年4月11日 (二) 10:09 (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)
- @kanashimi:格式手冊/連結中「模板中的內部連結」:「目標為本頁面的內部連結會顯示為加粗無連結黑色正文。常見於模板調用中:如果模板A中有頁面B的連結,而頁面B又調用了模板A,那在頁面B的頁面上模板A處頁面B的連結會顯示為無連結文字;然而,若是頁面B重定向至頁面C,而頁面C中調用了模板A,而模板A中原應是C的連結處寫的是B,則B仍會是內部連結的樣子。系統在作出此判定的時候不會自動轉換繁簡,因此有時候要手動轉換模板頁內連結的文字。」。而且,在維基方針和指引中,好像有提及模板中的內部連結,要和目標原標題一致,不可有重定向。說白了,模板未能在目標頁面顯示加粗無連結黑色正文,導航只是做了一半而已。--以上未簽名的留言由Comrade John(討論|貢獻)於2023年4月14日 (五) 07:51 (UTC)加入。
名稱中有U+FF0D的條目基本移動完成。未移動的有這些情況:
- 被提刪的重定向。
- 名稱形如脫獄 -囚犯的戰爭-的條目,顯然不是連接號用例。
- 青山公路-葵涌段、大埔公路-沙田段等條目,搜了搜相應路牌的照片,有的像短橫線,有的像U+FF0D,不確定如何處理。
- WEEKEND-TIFFANY,移動被MediaWiki:Titleblacklist阻擋:「禁止移動多於9個大寫字母的頁面」。
--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(留言) 2023年4月22日 (六) 11:21 (UTC)
- @kanashimi:申請成常態性任務吧,大規模清理後,非使用em dash連接符號的條目標題會呈零星出現狀態,要定期監視清理。--約翰同志-條目裱糊匠(留言) 2023年4月18日 (二) 12:01 (UTC)
- 如果成為常態性任務,1個禮拜一次應該就夠了。並且作業內容會是對所有模板,不會只有列表中的。--Kanashimi(留言) 2023年4月18日 (二) 08:33 (UTC)
- @kanashimi:編輯沒問題。多語言模板也需要處理,預計編者們知道共識後,所建立的條目標題連接符號都會是em dash,預先處理多語言模板對處理偽藍鏈有利。如果成為常態性任務,清理頻率是幾多天一次 ?--約翰同志-條目裱糊匠(留言) 2023年4月18日 (二) 07:58 (UTC)
- 這個編輯沒問題。我覺得常態性的任務是不錯的想法,頁面被移動後在導航模板處的情況是有普遍性的,不只適用於這次的連接號。--Lt2818(留言) 2023年4月18日 (二) 04:14 (UTC)
- @Comrade John@Lt2818 請檢查機器人在Template:2006年世界盃外圍賽的編輯。若是妥當的話,這邊就會開始作業。多語言模板也需要處理嗎?或者乾脆申請成常態性的任務?--Kanashimi(留言) 2023年4月17日 (一) 22:49 (UTC)
- 上面已經列出過了,模板內U+FF0D內鏈。--Lt2818(留言) 2023年4月16日 (日) 02:56 (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)
- Unicode字符有語義,因此形近的符號不能互相混用。「.」是全形英文句號,由於港澳台標點統一置中,常被誤認作間隔號,中華民國《重訂標點符號手冊》修訂版即誤用「.」為間隔號,參見「間隔號#電腦輸入」。--蕭漫(留言) 2023年5月4日 (四) 18:52 (UTC)
- 大部分的外國人名都用「·」分隔姓氏和名字,但這個符號太難打出來了,倉頡碼是甚麼我至今也不知道。奇怪的是我在編輯框裡顯示的「·」是全形的,跳出編輯框在正式條目看反而變半形了。而「.」(ZXAE)能不能用?這也是全形符號。「/」全形斜線也只能開倉頡全形直接按斜線打出來,用ZX方法反而打不出來。--owennson(聊天室、獎座櫃) 2023年5月4日 (四) 11:32 (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年6月7日 (三) 02:55 (UTC)
- 建議更換字體。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年6月6日 (二) 17:48 (UTC)
- 間隔號沒有爭議,·不是全形符號。分隔號目前的規定是半形全形二選其一即可,中國大陸規定用半形,全形更多是日語中的用法。--InstantNull(留言) 2023年5月4日 (四) 05:51 (UTC)
- @Comrade John 感謝幫忙修復錯誤。不曉得現在修復的進度如何?我是不是只要加上檢測重新導向標的功能,再完成剩下的頁面就可以呢?--Kanashimi(留言) 2023年4月22日 (六) 22:42 (UTC)
- 話說目前就連接號而言還有什麼善後措施還沒做麼?—— Eric Liu 創造は生命(留言・留名・學生會) 2023年5月31日 (三) 04:18 (UTC)
- 條目分類也處理完了。算是告一段落。--Lt2818(留言) 2023年6月1日 (四) 16:32 (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
亦可。--Boreas Sawada 2023年10月22日 (日) 05:31 (UTC)
- 針對這一疑慮,對於不希望換行的空格,維基有相應的模板(Template:Spaces),或者直接使用 HTML
- 如果用半形加空格也會有換行的問題吧,比如「2 :
- 還有一種寫法是用「比號」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)
- {{ratio|5.5:1.9:1}}→5.5∶1.9∶1 --街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年9月14日 (四) 13:35 (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)
- 那兩個點距離太寬了,搭配數字起來比用冒號還要難看啊。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月23日 (六) 12:54 (UTC)
- 語義不同,外觀不同。「1:1:1」丑;「1:1:1」畸形、歧義;「1 : 1 : 1」門檻低但輸入和複製也不輕鬆,等寬和非等寬字體下有差異。1∶1∶1。--YFdyh000(留言) 2023年9月23日 (六) 08:51 (UTC)
- 建議新開一個章節,「比號」,因為比號並不屬於冒號。可在冒號節加入連接提示。
- 基於魔琴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)
- 比如%,成(三成,七成),分數和之類的。--落花有意12138 2023年10月3日 (二) 02:13 (UTC)
- 比號算是冒號的一種吧?似乎不在正式標點符號名單中。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年10月2日 (一) 09:05 (UTC)
- [8],部分語言下混用,但至少中文應當區分。--YFdyh000(留言) 2023年10月2日 (一) 09:35 (UTC)
- 宜用比號而非冒號?推薦使用比號,不得用冒號,難道還有什麼不推薦但也沒被否定的符號…?--洛普利寧 2023年10月2日 (一) 08:51 (UTC)
- (!)意見,其實比號並非正式的中文標點符號,所以我覺得應該規定在Wikipedia:格式手冊/日期和數字裏,而不是Wikipedia:格式手冊/標點符號,我的提議如下:
- 在MOS:NUMBER的最底下開新一個章節:
- 在MOS:冒號的最底下補充提示:
- 提議條文
另外,注意有一外形相似的「比號」(∶)用於表示比值,其使用法請見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)
- 然。希望Eric君和YF君能就新的討論給出自己的意見。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月28日 (六) 17:56 (UTC)
- 在我而言應該不能拿減號來類比,U+002D - HYPHEN-MINUS和U+2212 − MINUS在Unicode的定義上已很明明白白地告訴大家兩個都可以用於減號;但對於冒號U+003A : COLON和比號U+2236 ∶ RATIO,Unicode則沒有採取如此的定義。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年10月28日 (六) 12:55 (UTC)
- @Cdip150、Ericliu1912、YFdyh000。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月24日 (二) 10:42 (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)
- 英維的確一如引號的選擇,傾向使用ASCII符號,比號方面也是:en:MOS:MATHSPECIAL要求用冒號,不用比號。——(留言) 2023年11月7日 (二) 13:51 (UTC)
現在的情況是這樣,我們應該優先推薦較正確但難用的符號,還是易輸入但不非常正確的符號?即使是英文維基百科,似乎也沒有要求。—— - 如果有特殊情況(比如懶)而用冒號的話,應該也不算違反「應避免使用」吧?至於優先推薦,自然應該推薦語義正確的符號吧?不過我又想到讀者會不會搜冒號但搜不出來?英維用直引號""而不用彎引號“”似乎有這方面的原因(?) ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年11月7日 (二) 13:47 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2023年11月7日 (二) 12:52 (UTC)
- 「比號」不常用,可以作為某種推薦,但不應該強制使用。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年10月10日 (二) 09:23 (UTC)
- 我的意見是直接規範用半形冒號當比號就好了,畢竟這算是最常用、最容易輸入的方式。Sanmosa Ινα κραζω σοι 2023年11月10日 (五) 03:28 (UTC)
- 容易輸入為由解決不了格式規範化(各用各的)和用法爭議(如:兩側有無空格)。以前的連接號也不容易輸入吧。--YFdyh000(留言) 2023年11月10日 (五) 03:42 (UTC)
- 感覺可比性不高。(中文)維基百科大部分情況下都是用冒號當比號,而大部分冒號當比號的情況下都是用半形冒號,這跟各種連接號常用性相當或無法區分的情況不一樣。「直接規範用半形冒號當比號」如何「解決不了格式規範化」我無法理解,但兩側有沒有空格這點參考enwiki的辦法(兩側沒有空格)即可。Sanmosa Ινα κραζω σοι 2023年11月12日 (日) 23:10 (UTC)
- 容易輸入為由解決不了格式規範化(各用各的)和用法爭議(如:兩側有無空格)。以前的連接號也不容易輸入吧。--YFdyh000(留言) 2023年11月10日 (五) 03:42 (UTC)
新增「《」模板的用法
原標題為:建議Wikipedia:格式手冊/標點符號#書名號新增使用{{《}}的方法,修改使用代碼的方法,並調整「效果為」的位置
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
|
|
此前有過一次討論,但偏題到連續書名號之間是否要加入頓號的問題,並沒有對條文修改作實質討論。此處提出的修訂概要為以下三點:
- 新增Template:《的方法,參見{{《}}。此為高風險模板,說明使用頻率很高,適合加入格式手冊。
- 將
zh-hans:《;zh-hant:〈;
改為zh-hans:《;zh-tw:〈;zh-hk:《;
,否則在香港繁體下,模板的結果和手冊提供的代碼的結果不一致。 - 調整「效果為」的位置,使之更加直觀。
——小林子沖(留言) 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.0 1.1 1.2 王興全; 方忠. 现代出版物语言文字使用规范. 成都: 電子科技大學出版社. 2017: 227. ISBN 9787564750831.
- ^ 蘇培成. 大家小书 怎样使用标点符号 增订本. 北京: 北京出版社. 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)
- 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)
- 嚴格來說我認為沒必要使用示亡標識(包括西式的劍標),如果大量范用的話,可能變成了追著死人來標記(畢竟人固有一死……)?如果弱化的話,只允許特定情況下的使用,例如在描述他的某個重要職務上在任離世時標示。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年1月7日 (日) 05:20 (UTC)
- 我也有同樣的想法,但老實説我日常生活中也很少見到示亡號,好像也就報紙上說某府出殯的時候偶爾會看到幾次而已。Sanmosa Romeo and Qubilai 2024年1月7日 (日) 06:43 (UTC)
- AMA Manual of Style亦已棄用death dagger。Chicago中dagger現僅用於腳註。--Mys_721tx(留言) 2024年1月7日 (日) 23:42 (UTC)
- @Cwek †?? -Lemonaka 2024年1月19日 (五) 06:41 (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)
- 我個人理解的使用習慣其實與此一致,不過希望各地的編者出來看下,各地中文裡對於示亡號的用法同此是否一致?--Zhxy 519(留言) 2024年1月11日 (四) 14:44 (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)
- 圖書再版更多是版本學的問題,不太一樣--百無一用是書生 (☎) 2024年2月8日 (四) 03:33 (UTC)
- 「已經死亡有一段時間的不會用」[查證請求],圖書再版時會去除嗎。對於原作者去世多年,應該是不會用。紀念性對於保持原貌來說,不覺得不合適。--YFdyh000(留言) 2024年2月5日 (一) 21:11 (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)
- 國際關係中使用一字線,可以看Wikipedia_talk:格式手冊/標點符號/存檔3#連接號一字線的符號選擇,此次討論之後進行了大量移動。--Kethyga(留言) 2024年4月14日 (日) 09:17 (UTC)
- 我覺得閣下所言極是,以哈戰爭關注量極大,盼管理員處理定奪。—— 桁霽 晚來天欲雪,能飲一杯無 ↹ 苦辛 🇹🇱 2024年4月14日 (日) 09:06 (UTC)
- 應該將「以色列—哈馬斯戰爭」移動至「以色列-哈馬斯戰爭」才對吧?!這是個複合名詞,又不是表示「上海—北京列車」之類的起止。--自由雨日(留言) 2024年4月14日 (日) 08:59 (UTC)
- 感覺MOS:連接號對於A與B之間的事物(如上述以色列—哈馬斯戰爭,「連接號」不會讀作「至」、「到」),應該再明確一下。美國-墨西哥-加拿大協定似乎用「一字線」還有點爭議,像「吐魯番-哈密盆地」可能更傾向於「U+002d」。--Kethyga(留言) 2024年4月14日 (日) 09:10 (UTC)
- 贊同,連結號的格式規定確實不夠詳盡。鑑於其廣泛應用,社群應當盡快通過討論修訂完善。—— 桁霽 晚來天欲雪,能飲一杯無 ↹ 苦辛 🇹🇱 2024年4月14日 (日) 09:13 (UTC)
- 那麼是否應當將「伊朗-以色列代理人衝突」移動至「伊朗—以色列代理人衝突」?--—— 桁霽 晚來天欲雪,能飲一杯無 ↹ 苦辛 🇹🇱 2024年4月14日 (日) 06:32 (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)
- 吐槽,維基百科管理員不是領導層。--Kethyga(留言) 2024年4月14日 (日) 10:00 (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)
- 你這兩個連國標也不是啊--百無一用是書生 (☎) 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)
- 思考...那前輩您那兒一般更多用書名號表示還是用斜體表示?(或者其他方式)--—自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 13:10 (UTC)
- 我翻了一下目前我這兒常用的的寫作要求,都沒有這個要求...--百無一用是書生 (☎) 2024年8月12日 (一) 12:24 (UTC)
- 確實不是 囧rz……但在沒有國標的情況下,用於說明格式習慣還是沒問題的?畢竟很多格式習慣(尤其是在一些少有規範標準的地區)連這種程度的草案/行標都沒有思考...--—自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 07:05 (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 II、Final Fantasy III、Final 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)
- 那些只要維持台灣正體為原樣就好了吧……大陸並沒有這種中英混雜標題的問題?大陸《現代漢語詞典》只收了字母詞,沒收純英文單詞,是不認可任何英文單詞屬於中文的,所以正式名稱應該不會有這種中英混雜。--—自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 09:26 (UTC)
- 要執行的話,只要將帶書名號的名稱也併入轉換,其實根本不難,這比各類信息框模板語法簡單多了……--—自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 09:02 (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
- 我個人擁護Ghren前輩的曾在示亡號用法中提出過的意見:
- 我的邏輯就是「英語應該具有特權」。其他語言是用斜體還是用書名號是我目前暫未考慮的問題,但既然英語在大陸已形成某種習慣規範,那麼當外文是英文時,自然應當遵循該規範(在技術可以實現的前提下)。而且這其實和英語是不是有特權也沒有關係吧?如果頒布的規範是英語、印地語和日語而沒有頒布其他語言,我也會說,在頒布規範的這些語言中應當遵守,這不代表「英語、印地語、日語」就有了「特權」。——自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 11:57 (UTC)
- 我似乎並沒有提到「假設讀者會使用英語」?--—自由雨日🌧️(留言|貢獻) 2024年8月12日 (一) 11:45 (UTC)
- 這裡是中文維基百科,不應假設中文維基百科讀者會使用其他語言——包括更容易被人提到的,您所說的「全世界的法通語」的英語。儘管你在commons:講英文,會有更多的人看懂你想說什麼。--For Each element In group ... Next 2024年8月12日 (一) 11:41 (UTC)
- 該草案的內容很有參考意義,但書名號部分並非中國大陸歷來的格式習慣,而是新的規範要求。見作者 簡慶閩 來源 《語言文字報》第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我早就大力推進了()但我前面已指出(1、2),有規範草案的情況已經是「非常有參考意義」了。(另外,我驚奇地發現第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)
- 參考文獻應該從來就不適用標點符號格式手冊規則(比如中文文獻中使用的那些「.」「,」等符號GB/T 7714也不定性為「標點符號」而是「前置符」),應該與本次討論無關?--自由雨日🌧️(留言|貢獻) 2024年8月25日 (日) 05:14 (UTC)
- 糾正一下,我的問題是腳註中,中文書名、英文書名,是否都改斜體,因為模板一律不加中文書名號。我過往是均不斜體。如果書目名不斜體,與英文維基的規範是不一致的,見[12]。Template:Cite_book文檔允許英文書名加斜體,中文書名禁止。關於斜體,另參考Wikipedia_talk:格式手冊/存檔1(2005年)、Wikipedia_talk:格式手冊/標點符號/存檔2(2019年)等許多關於斜體美觀性、理解難度的討論。--YFdyh000(留言) 2024年8月25日 (日) 02:53 (UTC)
- 參考文獻處,如果是書名本身那不應使用斜體,就像中文書名不應加書名號,但如果是書名的一部分,應當使用斜體吧(就比如書籍標題是「《紅樓夢》賞析」,那麼參考文獻標題參數也應當帶有書名號)?「
- 也許比某些GB/T更有價值,推薦性質也差不多。那是個模板,我手動加的,省去留言複述。補充一下,我對純英文書名不用中文書名號,目前傾向贊成,不過「一般並不允許」存疑,「必須使用斜體」反對,過往有一些論述說「可以採用斜體、黑體或者下劃線表示」。如果確定為斜體,參考文獻等處的非中文夾帶英文書名均應使用英文斜體嗎,我通常會去掉……也稍有擔心多少比例的讀者理解是書名號作用。--YFdyh000(留言) 2024年8月24日 (六) 17:39 (UTC)
- 並非「類似GB/T」,肯定比GB/T更「不具規範性」啊……
- 該文似乎沒提到書名號?--自由雨日🌧️(留言|貢獻) 2024年8月24日 (六) 16:04 (UTC)
推進圖註結尾有無句號共識
前次討論,多數意見傾向「視作短語的圖註結尾不加句號,視作句子/語段的圖註結尾加句號
」,其餘意見認爲此爲習慣問題並表示中立。被指似有初步共識,可以考慮繼續推進;惜未推進。故而,折衷二方意見,總結共識:不應禁止「視作句子/語段的圖註結尾加句號」。建議對「句號」章節部分修改如下:
--— 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)
- 我沒看出矛盾啊?第一句說「短語式說明文字不用句號」,第二句說「即使有時說明文字較長,前面的語段已出現句號,最後結尾處仍不用句號」(即「街景」「維基娘」等的情況)。——自由雨日🌧️🌨️ 2024年11月5日 (二) 11:01 (UTC)
- 第一點意在突出閣下的「歸謬」並無「歸到謬」,關乎閣下的論證。--— Gohan 2024年11月8日 (五) 08:17 (UTC)
- 表意不清(甚至與最關鍵定語自相矛盾)的「標準」堪稱「不準」,不應被採用。不再贅述。— Gohan 2024年11月5日 (二) 10:48 (UTC)
- (+)支持,至少在澳門,的確有圖片描述一句不用句號,兩句或以上用句號的習慣,例如澳門政府、澳門日報、正報。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年10月28日 (一) 16:31 (UTC)
綜上理由,以及避免過度妥協,又鑒於引號等亦屬於適當的收尾標點,向社群提供以下四版本修訂案:
- 版本A:(清晰表明二種用法並存)
- 版本B:(最符合前次討論無人反對的多數意見,對各情形指引詳盡)
- 版本C:(減少上述中國大陸標準是否覆蓋「非短語式說明文字」的爭議)
- 版本D:(完全避免上述中國大陸標準是否覆蓋「非短語式說明文字」的爭議,然而範例不足而可能被人誤解)【此版本修訂已無「句2」,故本句上方的「句1」相應去除序號1】
|
— 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)
- 現行條文(即原條文)不僅是「
- 版本A一大缺陷在於,或是世界中文史上首次明確規定句段末尾可不用句號的規範——本人不想承受大有可能是惡果的此責。版本C、D對此不作特別規定,不「搞特殊」,平等視之,更爲靈活。--— Gohan 2024年11月5日 (二) 10:07 (UTC)
- 並不是說「必須特別規定」,只是原先有規定,且可以用版本A清晰表示「改變了過去的規定,現在兩種用法可並存」,不認為完全刪去有比A更好的好處。版本C中的「
- 爲何必須特別規定「
- 版本D未對「
- 版本D可謂完全出自中國大陸標準,爲何反對?「其餘標點符號規定」亦未強制任何情形必用句號,又爲何反對版本C?--— Gohan 2024年11月2日 (六) 08:59 (UTC)
- 版本太複雜了,總之我的意見跟Cdip150等人一樣,並希望能提供適度說明。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年11月2日 (六) 10:50 (UTC)
- 所有版本差異,是出於中國大陸有關標準(「
圖或表的短語式說明文字,中間可用逗號,但末尾不用句號。即使有時說明文字較長,前面的語段已出現句號,最後結尾處仍不用句號
」)是否覆蓋「非短語」具有爭議,而在不同程度上兼顧「避免此爭議」與「詳盡引導」而設。對於不在意此爭議的人而言,多數版本(在其上已有簡短説明)效果差異甚微,可一並支持,甚或評點優劣,選出最優版本。--— Gohan 2024年11月4日 (一) 10:56 (UTC)
- 所有版本差異,是出於中國大陸有關標準(「
擬定及公示
由於其餘版本被反對,擬採用並在不久後公示版本A,亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNull— Gohan 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)
- 或許可將「若屬短語」改為「若不是句子」。當然,這樣改依然有「『維基百科標誌』可以視作句子」的問題。但既然標準本身已存明顯爭議,我認為不必再在用詞細節上糾結;甚至完全放開——即允許「維基百科標誌」末尾也可帶句號——我也不反對。--自由雨日🌧️❄️ 2024年11月15日 (五) 18:57 (UTC)
- 不知道。@自由雨日。 ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年11月15日 (五) 18:51 (UTC)
- 若無前文,此語一般不視作句子?若可視作句子,請問如何修改?將「若為句子或語段」改爲「若非短語,而是句子或語段」可否?--— Gohan 2024年11月15日 (五) 09:58 (UTC)
異議解決,修訂為以下版本A-2,立即重行公示7日:
— Gohan 2024年11月18日 (一) 03:29 (UTC)
- 公示期屆滿,修訂通過。--— Gohan 2024年11月25日 (一) 04:40 (UTC)