维基百科讨论:格式手册/标点符号/存档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)