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