维基百科:互助客栈/方针/存档/2020年7月
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
维基百科图书馆文献传递指引
Wikipedia:关闭存废讨论指引的事实性修正
有关“2020年度香港四台冠军歌曲列表”、“Template:四台冠军歌曲列表”及各香港歌手“派台歌曲成绩”的四台定义讨论
提议立指引处理编辑冲突
暂无可行的方案。--Temp3600(留言) 2020年7月8日 (三) 16:59 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
现行编辑冲突的处理尚未有配套指引。已发生数次争议例如这个DYK案、和这次被和其他无关事件硬要混淆的争议事件。 建议订立相关指引,不然类似争议只会越来越多。 有的讨论是有讨论期的,这一盖掉,讨论期如何计算? 如果“编辑冲突”因为WP:AGF而不用追究责任,那我认为会需要有配套指引,例如被“编辑冲突”掉的编辑谁有责任还原?“编辑冲突”掉了难道就放着不管? 有讨论期的讨论(如评选、权限申请、公示中议案)被“编辑冲突”掉的话,期限如何重算? ...等问题。 为了避免更多“编辑冲突”造成的争议,建议社群讨论并订立相关配套指引。-- 娜娜奇🐰枫香花茶☕(宇帆·☎️·☘️) 2020年6月7日 (日) 18:38 (UTC)
- 简单而言,避免使用非mw附带的编辑器(官方编辑器暂时没听闻发生编辑冲突也照样保存的情况)。至于编辑冲突覆盖,如果及时留意的话,应该需要恢复吧。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月8日 (一) 01:20 (UTC)
- @cwek:“避免使用非mw附带的编辑器”没有用啊,他们又不肯换预设编辑器。且争议已经确实发生,且多次,也没人做善后处理。如果有人做善后处理User:Jarodalien还会不完全AGF吗-- 娜娜奇🐰枫香花茶☕(宇帆·☎️·☘️) 2020年6月8日 (一) 09:41 (UTC)
- 可以添加提醒类似“注意,使用非系统自带编辑器曾出现过多次编辑冲突覆盖问题,请勿如此使用”。至于这些评比被覆盖导致的时间问题,可以考虑:恢复后继续、保留旧票按新记录重开、不保留按新纪录重开。而编辑器问题,可以考虑:用过滤器发现编辑器特征来限制,针对用户的对页面的编辑禁止,等。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月8日 (一) 09:49 (UTC)
- 难办。任何要求编缉者事后承担责任的方案,都与维基百科不强逼人参与相冲突。--Temp3600(留言) 2020年6月10日 (三) 05:18 (UTC)
- 🤔 或者大不了除权(如果有的话)?举个例子,管理员可以选择不回复任何对自己的质疑、不看讨论页、编辑完了就跑,这是管理员的自由;其他人也有针对此问题罢免管理员的自由。同样地,如果哪个人不仔细检查自己的编辑那也是他自己的自由,大不了去掉巡退免权?173.75.41.7(留言) 2020年6月12日 (五) 15:20 (UTC)
- 除掉什么权?“使非WMF官方提供之编辑器之编辑权”?“编辑冲突权”?-- 娜娜奇🐰枫香花茶☕(宇帆·☎️·☘️) 2020年6月12日 (五) 15:41 (UTC)
巡退免权
囧rz... Sunny00217 2020年6月23日 (二) 09:57 (UTC)
- 除掉什么权?“使非WMF官方提供之编辑器之编辑权”?“编辑冲突权”?-- 娜娜奇🐰枫香花茶☕(宇帆·☎️·☘️) 2020年6月12日 (五) 15:41 (UTC)
- 🤔 或者大不了除权(如果有的话)?举个例子,管理员可以选择不回复任何对自己的质疑、不看讨论页、编辑完了就跑,这是管理员的自由;其他人也有针对此问题罢免管理员的自由。同样地,如果哪个人不仔细检查自己的编辑那也是他自己的自由,大不了去掉巡退免权?173.75.41.7(留言) 2020年6月12日 (五) 15:20 (UTC)
- 编辑冲突与巡退权本身无关。但又不能除掉“编辑权”。所以难办。--Temp3600(留言) 2020年6月12日 (五) 15:58 (UTC)
- 除非是禁止/w/api.php?action=edit,否则没意义-- Sunny00217 2020年6月17日 (三) 11:30 (UTC)
- 这些编辑会带有特定标识,如果无法解决编辑问题,可以用过滤器做限制。如果变本加厉的话,可能考虑配合特定页面的编辑禁止来代替。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月25日 (四) 02:36 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
关于修改《关闭存废讨论指引》的提议
关于WP:BLP#姓名隐私,条文应界定清楚
提议WP:SIS或WP:MOSSIS成为中文维基百科正式的格式指引
虚构人物的角色扮演照能否代替其合理使用剧照
为Wikipedia:列明来源与Wikipedia:格式手册添加例子
新增明显侵犯著作权之速删标准并整合Template:Copyvio
请求在编辑提示中增加有关WP:CONCOVID-19相关内容
最近本人看到每天都有用户进行COVID-19命名破坏,因此进行提议。
内容增加如下:
请勿进行COVID-19条目破坏,例如在条目中进行“2019冠状病毒病”、“2019冠状病毒疾病”、“2019年冠状病毒病”、“2019年冠状病毒疾病”、“严重特殊传染性肺炎”、“武汉肺炎”、“新型肺炎”、“新冠肺炎”等对COVID-19之称呼之间的转换,以及其致病病毒“SARS-CoV-2”、“2019-nCoV”、“武汉病毒”、“新冠病毒”、“中国病毒”等对SARS-CoV-2之称呼之间的转换,除非有共识支持,否则视同破坏。详见[[Wikipedia:COVID-19条目共识]]。
--枫叶(留言·贡献·签名·宅家不出门,为抗疫贡献!·反对武肺!) 2020年6月25日 (四) 08:46 (UTC)
- 不明所以。一句话禁武肺就反对。--Wright Streetdeck 端午节快乐 2020年6月25日 (四) 09:29 (UTC)
- 连提案都未看清楚就先说反对……还真行。 【和平至上】反对美国各地警方以过度武力镇压和平示威者💬 2020年6月25日 (四) 17:23 (UTC)
- (-)反对:看上去不会有用。--DRIZZLE (按此给我留言) 2020年6月25日 (四) 09:58 (UTC)
- (!)意见:感觉部分IP没有了解共识才进行破坏,因此提议是为了更好阻止用户进行COVID-19名称破坏。--枫叶(留言·贡献·签名·宅家不出门,为抗疫贡献!·反对武肺!) 2020年6月25日 (四) 10:31 (UTC)
- 恐怕不会有多少是无意,这还是有非常显眼的模板的情况。另外,WP:CONCOVID-19并不是方针。--DRIZZLE (按此给我留言) 2020年6月25日 (四) 15:41 (UTC)
- 已改成共识。--枫叶留·献·签 2020年6月27日 (六) 09:20 (UTC)
- 绝对(+)赞成:每日都有很多IP及新用户进行COVID-19命名破坏,也不知道是无意还是故意为之。增加编辑提示的话,起码可以挡掉那些无意进行命名破坏的用户。--CRHK128☎ 支持美国警察依法打击暴徒,恢复秩序 2020年6月25日 (四) 11:07 (UTC)
- (+)支持:可以减少非故意破坏。 【和平至上】反对美国各地警方以过度武力镇压和平示威者💬 2020年6月25日 (四) 17:51 (UTC)
- @Streetdeck:这个提案没有禁止使用武汉肺炎啊?Itcfangye(留言) 2020年6月25日 (四) 19:21 (UTC)
- 最大问题是有用户可能误解共识,认为用“新冠”替换原名就是执行共识,例如此,用户如认为自己替换字词是执行共识,那就挂模板也没用。--Uranus1781(留言) 2020年6月26日 (五) 02:36 (UTC)
- 已回退有关编辑。--CRHK128☎ 支持美国警察依法打击暴徒,恢复秩序 2020年6月26日 (五) 06:32 (UTC)
- 这个提示将会在那些页面出现呢。--Temp3600(留言) 2020年6月26日 (五) 07:21 (UTC)
- @Temp3600:会在任何条目的编辑区出现。--枫叶留·献·签 2020年6月26日 (五) 14:23 (UTC)
- 那我觉得影响范围太大了。绝大部分条目都与covid无关,还要每次写条目都颢示出来。--Temp3600(留言) 2020年6月27日 (六) 10:22 (UTC)
- 考虑到无论是中国病毒还是武汉病毒皆为歧视性名称,而2019冠状病毒病才是正确而且获得世卫承认的名称,我认为改为后者是绝对正确的做法,正如我们在维基百科内不会使用外号来称呼一个人一样,何况还是歧视性名称。维基断不可能用“黑鬼”、“暴徒”来称呼黑人的命也是命的支持者,用地堡男孩来称呼川普。以武汉病毒来称呼本来就是个错误,更正错误是天经地义的。WP:命名常规也严格禁用歧视性名称。反正最终还是得使用非歧视性的2019冠状病毒病或是严重特殊传染性肺炎,无论你政治取态如何。--owennson(聊天室、奖座柜) 2020年6月26日 (五) 07:24 (UTC)
- 问题是这个疾病中文选用的“中立的名称”各编者无共识。而且台湾官方也使用武汉肺炎的。--Starry🌟Home🏠连侬墙✍️▫武肺疫情☣️ 2020年6月26日 (五) 14:18 (UTC)
- User:StarryHome,台湾当局使用歧视性名称维基百科就要跟进吗?那学川普政府叫金正恩火箭人也可以啰?--owennson(聊天室、奖座柜) 2020年6月28日 (日) 07:10 (UTC)
- 我再强调一遍:各编者无共识。而且是否歧视存在争议。如果把埃博拉病毒、兹卡病毒等都改掉,我认为把武汉肺炎也改掉是合理的。--Starry🌟Home🏠连侬墙✍️▫武肺疫情☣️ 2020年6月28日 (日) 10:22 (UTC)
- 如果能找到合适替代材料,个人(+)支持都改掉。 DRIZZLE (按此给我留言) 2020年6月29日 (一) 13:00 (UTC)
- 我再强调一遍:各编者无共识。而且是否歧视存在争议。如果把埃博拉病毒、兹卡病毒等都改掉,我认为把武汉肺炎也改掉是合理的。--Starry🌟Home🏠连侬墙✍️▫武肺疫情☣️ 2020年6月28日 (日) 10:22 (UTC)
- User:StarryHome,台湾当局使用歧视性名称维基百科就要跟进吗?那学川普政府叫金正恩火箭人也可以啰?--owennson(聊天室、奖座柜) 2020年6月28日 (日) 07:10 (UTC)
- 问题是这个疾病中文选用的“中立的名称”各编者无共识。而且台湾官方也使用武汉肺炎的。--Starry🌟Home🏠连侬墙✍️▫武肺疫情☣️ 2020年6月26日 (五) 14:18 (UTC)
- 我在上方提出过置顶模板方案,现阶段我认为将置顶模板转化为编辑提示,但用词恐怕要增强一下警示性,以起阻吓作用。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年6月27日 (六) 04:01 (UTC)
- 不是已经有防滥用过滤器了嘛,其警示性恐怕不能说不强。 DRIZZLE (按此给我留言) 2020年6月27日 (六) 16:46 (UTC)
- 防滥用过滤器应该是在编辑提示的警示性都不能阻止相关修改的情况下才有警示性。如果编辑提示的警示性足够高,防滥用过滤器的触发次数会降低。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年6月28日 (日) 11:50 (UTC)
- 不是已经有防滥用过滤器了嘛,其警示性恐怕不能说不强。 DRIZZLE (按此给我留言) 2020年6月27日 (六) 16:46 (UTC)
- (-)反对:回退至原有编辑足矣,刻意提示有违WP:CENSOR。Hualin~希望の星は青霄に昇る(留言) 2020年7月4日 (六) 13:22 (UTC)
- (-)反对,不会听的还是不会看-- Sunny00217 2020年7月9日 (四) 03:08 (UTC)
足下与阁下
WP:礼仪里是否应当把阁下替换为足下,以结束目前维基社群对这一词汇的普遍误用现象?
|
|
--not a User:慎言慎行老法师写维基?写个屁! 2020年6月30日 (二) 13:16 (UTC)
- 请问“阁下”哪里误用?-游蛇脱壳/克劳棣 2020年6月30日 (二) 17:20 (UTC)
- @克劳棣:“阁下”目前通常是对政府首脑的尊称,传统上是下级对上级的敬称,而足下才是平级之间的互相使用的尊称。not a User:慎言慎行老法师写维基?写个屁! 2020年7月1日 (三) 16:30 (UTC)
- @慎言慎行老法师:请观语言变化,“阁下”目前显然是平级之间的互相使用的尊称。如君对此有所保留大可移步文言大典。AristippusSer(留言) 2020年7月1日 (三) 17:18 (UTC)
- @AristippusSer:然而“阁下”在维基百科条目内仍然被广泛认为是“excellency”在中文中的对应词汇,而后者一般仅限于对政府首脑使用 not a User:慎言慎行老法师写维基?写个屁! 2020年7月1日 (三) 17:24 (UTC)
- @AristippusSer:请观敬称与讽刺,大敬等于大不敬。别忘了御宅也是日语敬称,现在是废物的意思。维基百科对“阁下”一称的滥用对老用户可能已经习惯,但是对新用户可真的是会惊到呢,甚至会起一身鸡皮疙瘩。--173.68.165.114(留言) 2020年7月5日 (日) 05:44 (UTC)
- @慎言慎行老法师:"阁下"的Usage_notes。另外,条目归条目,讨论归讨论。条目的传主对于编者总是第三人称,不会是第二人称;一个维基人可能与另一个维基人对话,但是没有可能在条目中与传主对话。因此就算““阁下”在维基百科条目内仍然被广泛认为是“excellency”在中文中的对应词汇”,也不关维基人之间的讨论的事。-游蛇脱壳/克劳棣 2020年7月2日 (四) 05:49 (UTC)
- @克劳棣:那么不删除阁下仅加入足下一词您觉得怎么样?如果您认为能接受的话我就改为这个方案公示。not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 06:45 (UTC)
- 我个人觉得可以,不过这与您发文的目的“WP:礼仪里是否应当把阁下替换为足下,以结束目前维基社群对这一词汇的普遍误用现象?”可说背道而驰了吧?-游蛇脱壳/克劳棣 2020年7月2日 (四) 11:06 (UTC)
- @克劳棣:并不背道而驰,任何事情都要一步一步来嘛,我姑且先把目标一分为二好了。not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 16:21 (UTC)
- 我个人觉得可以,不过这与您发文的目的“WP:礼仪里是否应当把阁下替换为足下,以结束目前维基社群对这一词汇的普遍误用现象?”可说背道而驰了吧?-游蛇脱壳/克劳棣 2020年7月2日 (四) 11:06 (UTC)
- @克劳棣:那么不删除阁下仅加入足下一词您觉得怎么样?如果您认为能接受的话我就改为这个方案公示。not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 06:45 (UTC)
- 我感觉知道“足下”这词的人不比知道“阁下”的多吧 囧rz...--Super Wang※庆祝香港回归廿三年暨特区国安法顺利实施🇭🇰🇨🇳 2020年7月1日 (三) 09:16 (UTC)
- “足下”在古代似乎仅用于武人间,不合维基百科属性。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 22:51 (UTC)
- @Sanmosa:查无此说法not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 16:38 (UTC)
- (-)强烈反对提议。--🍀 CLOVER YAN (^_^) (回复请ping我) 2020年7月2日 (四) 08:17 (UTC)
- 足下,眼下您是谁的手下?——Hikaruangeel(留言) 2020年7月3日 (五) 13:04 (UTC)
经讨论修改如下
改进版提案
|
|
not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 16:41 (UTC)
- 公示一周,若无反对声音则如此修改。not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 17:06 (UTC)
- (-)反对现代汉语罕见,没有特殊必要修改。欲以“足下”相称者自会以“足下”相称。AristippusSer(留言) 2020年7月3日 (五) 19:39 (UTC)
- (!)意见,用“阁下”实际上是抬格,也就是将对方的地位抬升比自己高来表示尊敬。好像并没有问题?虽然我不喜欢这种文绉绉的小节。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月4日 (六) 02:43 (UTC)
- (!)意见 还是比较习惯使用“阁下”--Haoyu2002(留言) 2020年7月4日 (六) 03:50 (UTC)
- (!)意见:个人觉得改与不改都无所谓,原条文中也有等一词,若修改应属于小修改而已。gaosong2101 🏠 📫 📜 2020年7月4日 (六) 07:21 (UTC)
- (-)反对个别用户喜欢用足下称呼他人是他们的自由,也属于
等更为谦让的词句
,没必要特别更改。广九直通车(留言) 2020年7月4日 (六) 07:56 (UTC) - (+)支持:与“足下”意思相近,并列更好,就是这些细节位需要留意好。Kitabc12345 讨论 海南 打卡 2020年7月4日 (六) 12:35 (UTC)
- (+)支持。扫盲总是好的。--Discardpath(留言) 2020年7月4日 (六) 14:42 (UTC)
- 哈哈(+)支持,现在是习惯了,当初刚进维基百科的时候真的是每次一听到“阁下”就起一身鸡皮疙瘩。--173.68.165.114(留言) 2020年7月5日 (日) 00:23 (UTC)
- (-)反对,在此此词乏人问津—以上未签名的留言由Sunny00217(对话|贡献)于2020年7月9日 (四) 03:13 (UTC)加入。-2020年7月11日 (六) 23:02 (UTC)
关于在电影条目中罗列各地上映日期
关于各地的路名,关注度该依循何种标准?
- 目前有Wikipedia:关注度 (地理特征)与Wikipedia:一级行政区道路特殊收录限制列表与Wikipedia:关注度 (交通)
- 以Category:街道名消歧义里的条目为例。这类的道路条目,大多只有设施或交通段落能写。
- 是否应该重先检视这类的道路的关注度标准?
--P1ayer(留言) 2020年7月7日 (二) 08:01 (UTC)
- 现行维基百科:关注度 (交通)并没有有关道路关注度的实质标准。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:01 (UTC)
- Wikipedia:关注度 (地理特征)(1)指明Wikipedia:一级行政区道路特殊收录限制列表(2)优先适用。符合(1)但(2)另有限制的道路适用(2)及Wikipedia:关注度#通用关注度指引(3),符合(1)而(2)未有其他限制的适用(1),(1)未指明的适用(3)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 14:00 (UTC)
关于COVID-19警告模板违反维基百科指引的质疑
近期,由于COVID-19命名争议,有编者建立了{{Name of COVID-19}}和{{Name of SARS-CoV-2}}两个条目警告模板,而这两个模板均与Wikipedia:不要在条目中进行声明相冲突。但该页面为英文维基百科指引,在中文维基百科仅为论述。根据WP:剧透内容相关记载,2009年11月中文维基百科废除剧透模板的原因之一就是“没有足够坚实的基础可以令潜在剧情透露排除在“不要在条目中进行声明”方针之外。”而该页面并非维基百科方针,因此废除剧透模板似乎并没有足够的方针与指引作为依据。同时,中文维基百科仍然存在不少在条目中进行声明的模板。因此,希望社群能对是否将Wikipedia:不要在条目中进行声明列为中文维基百科指引达成共识。
- 若提议被否决,则应当恢复剧透警示模板{{Spoiler}}(存档),因为此模板同样属于声明模板,不应该被区别对待。
- 若提议通过,则应当删除所有在条目声明模板。如:{{Medical}}、{{Legal}}、{{Simplify}}、
{{UTC time}}、{{NoteUTC}}以及上文提到的{{Name of COVID-19}}和{{Name of SARS-CoV-2}}等
以上。——BlackShadowG★(留言) 2020年7月8日 (三) 08:55 (UTC)
- Wikipedia:剧透内容相关模板的废除并不只是条目声明?——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月8日 (三) 09:54 (UTC)
- 请注意WP:不要在条目中进行声明并不跟上面所说的两个UTC模板和Simplify模板冲突。这三个声明均不是免责声明。Itcfangye(留言) 2020年7月9日 (四) 01:08 (UTC)
- 支持删除大部分的声明模板--百無一用是書生 (☎) 2020年7月9日 (四) 01:16 (UTC)
- 或者可以引用IAR:原则和精神大于条文,如果因为“COVID-19命名争议”,共识上认为添加声明是有必要的,则可以考虑保留这些声明。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月9日 (四) 02:09 (UTC)
- (+)支持WP:不要在条目中进行声明精神,但需要修订该页面措辞。另外,该页面仅用于免责声明,和{{Simplify}}、{{UTC time}}、{{NoteUTC}}等模板无关。--DRIZZLE (按此给我留言) 2020年7月9日 (四) 06:12 (UTC)
- 也同样不认为的各种声明值得被鼓励,删除这些模板或者禁止在条目空间用这些模板是可以被接受的。另外NoteUTC之类的应该不算是声明吧,感觉那算是资料提示之类的,即便删掉也是会变成在行文中反复提及“在UTC时间的XX:XX”,这样也没啥意义而且使编者和读者都感到枯燥,所以这些不太应该被删。--Роу Уилсон Фредериск Холм(留言) 2020年7月10日 (五) 17:55 (UTC)
建议修改WP:NMUSIC中相关内容
Wikipedia:医学声明是不是正式声明
如果有编辑者于使用者页面中发布了违反港区国安法的内容会不会受警告及删除相关内容?
关于“应援色”及“粉丝名称”是否属于“爱好者内容”
条目中使用删除线
WP:HAM 任何人皆可以转交之问题
提议修订格式手册有关地区词的部分内容
重组Wikipedia:关注度 (组织与公司)指引排版
是否应该删除偶像明星广告代言相关内容
流量明星艺人代言产品获取代言费无可非议,但传统明星艺人代言广告从来没有被记录过。应删除相关内容。维基百科不应该沦为免费广告传播介质。 参考条目:蔡徐坤,吴亦凡.--Dbjm1(留言) 2020年7月7日 (二) 09:32 (UTC)
- @Dbjm1:什么是流量明星艺人?-游蛇脱壳/克劳棣 2020年7月8日 (三) 22:22 (UTC)
- @克勞棣: 参见流量明星,说白了就是新型娱乐业,是量产的大众偶像。 不同于传统偶像。没有出色的能力,靠面容和人设吸引粉丝,需要流量和话题维持热度。会以代言产品来反衬偶像人设。比如:xxx是xx名牌大使。什么的--Dbjm1(留言) 2020年7月8日 (三) 22:36 (UTC)
- (:)回应:那么我会认为,在有可靠来源的前提下,传统明星艺人只能列出“非营利机构”(如台湾血液基金会、董氏基金会、喜憨儿基金会)的代言,除非他的这项代言在某国家或地区内已经非常出名,让人看到此商品就想到他(如白冰冰的金蜜蜂冬瓜露)。但这不代表我认同流量明星艺人的代言产品就可以全部列出,而是这部分比较麻烦,尚需其他维基人的高见。-游蛇脱壳/克劳棣 2020年7月8日 (三) 23:00 (UTC)
- (:)回应:首先感谢回应。至少我知道的流量明星代言其实大部分都是商业广告,公益一般会单独列出。其次我建议应该全部删除,这样只会给编者带来不必要的麻烦,从读者的角度看我想除了少数极端粉丝其他人也不会想了解其代言了什么产品,更何况他们代言的广告真的很多。--Dbjm1(留言) 2020年7月9日 (四) 00:38 (UTC)
- 同意克劳棣的意见。-- Air7538#Talk 2020年7月10日 (五) 00:17 (UTC)
- (:)回应:首先感谢回应。至少我知道的流量明星代言其实大部分都是商业广告,公益一般会单独列出。其次我建议应该全部删除,这样只会给编者带来不必要的麻烦,从读者的角度看我想除了少数极端粉丝其他人也不会想了解其代言了什么产品,更何况他们代言的广告真的很多。--Dbjm1(留言) 2020年7月9日 (四) 00:38 (UTC)
- (:)回应:那么我会认为,在有可靠来源的前提下,传统明星艺人只能列出“非营利机构”(如台湾血液基金会、董氏基金会、喜憨儿基金会)的代言,除非他的这项代言在某国家或地区内已经非常出名,让人看到此商品就想到他(如白冰冰的金蜜蜂冬瓜露)。但这不代表我认同流量明星艺人的代言产品就可以全部列出,而是这部分比较麻烦,尚需其他维基人的高见。-游蛇脱壳/克劳棣 2020年7月8日 (三) 23:00 (UTC)
- 蔡徐坤的条目从去年开始一直是我在维护,当时这篇条目经过我的扩充、改善之后还高票登上DYK。广告代言段落原本是用文字段落表述,仅列举部分代言产品,并且附上了参考来源。前几周有粉丝改成列表,把所有代言产品都列了出来。--风云北洋※Talk 强烈支持《中华人民共和国香港特别行政区维护国家安全法》 2020年7月10日 (五) 17:07 (UTC)
- 我建议参考一下刘德华的写法。这是一篇优良条目,对广告代言的描述也是用文字段落列举一些主要的代言产品。--风云北洋※Talk 强烈支持《中华人民共和国香港特别行政区维护国家安全法》 2020年7月10日 (五) 17:20 (UTC)
- 在拥有可靠来源的情况下,不认为单纯的列举商业广告品牌属于“沦为免费广告传播介质”,广告代言也属于艺人出演的一部分。--无所事事/想要狗带 2020年7月10日 (五) 20:14 (UTC)
- 参考优良条目卡卡#商业价值一节(oldid=25523037也就是评选为GA时间点的版本时就已经存在)也列举了他的商业广告,在世人物条目不能因为“种类”不同而采取不同标准。--无所事事/想要狗带 2020年7月10日 (五) 20:20 (UTC)
- 我认为要写可以,但是不该一一罗列,毕竟不是每个都有可靠来源的内容都应该收录。 --无心*插柳*柳橙汁 2020年7月11日 (六) 16:49 (UTC)
(&)建议那可以改为允许记载3~5个知名商业类型广告,公益广告不限。但不允许使用表格记载商业广告。-Dbjm1(留言) 2020年7月13日 (一) 13:36 (UTC)
- 我个人认为列出代言产品没有什么意义,还不如写该明星怎么决定要代言哪些产品,或是他的代言能对销量造成多大的影响。如果一定要写的话,建议规定要有良好的第三方来源支持才能写入,不能用广告本身、该产品公司或艺人的官方新闻稿作为来源。--Yel D'ohan(留言) 2020年7月18日 (六) 01:32 (UTC)
提议规范管理员通告板(VIP,ANM,AN3)的处理程序、时限和方式
取消GAC通过后不能直接FAC的规定
有关COVID-19相关条目的讨论
建议向维基百科:格式手册/日期和数字中添加对于开始时刻的规范
由于某些国家、地区和行业可能会使用30小时制、36小时制等不常用的开始的时刻表示法,可能会导致管用0时刻开始的维基人阅读时产生约度障碍。如1月1日25时,实际上已经到达了24小时制的1月2日。
|
|
使用30小时制、36小时制等的模板另待起草。
--Huangsijun17(留言) 2020年7月12日 (日) 03:36 (UTC)
- 总体上(+)支持,但是写成“除非特别在条目或章节中声明,应当以二十四小时制的0时作为每日的开始时刻。”可能会更合适一些。原文听起来像只能使用二十四小时制,而且不接受30、36小时制模板之外的声明(如注释、或者T:深夜动画等)。gaosong2101 🏠 📫 📜 2020年7月12日 (日) 10:17 (UTC)
- 调适提案用辞。原有用辞存在语病。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月12日 (日) 10:54 (UTC)
- 因此十二小时制也被禁止使用了? gaosong2101 🏠 📫 📜 2020年7月12日 (日) 11:09 (UTC)
- 我对提案本身没有任何评论。用词而言,确实有这样的效果。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月12日 (日) 11:34 (UTC)
- 从OP的引文中我觉得OP可能没有想要表达这个意思。等OP回应吧,顺道ping一下@Huangsijun17:。gaosong2101 🏠 📫 📜 2020年7月12日 (日) 11:41 (UTC)
- 我对提案本身没有任何评论。用词而言,确实有这样的效果。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月12日 (日) 11:34 (UTC)
- 我是这个意思,可能是我表达不当。我是想将其和30小时制以及36小时制区分开,才用了24小时制这个词。——Huangsijun17(留言) 2020年7月13日 (一) 05:35 (UTC)
- 那我改一下:
|
|
- @Huangsijun17,您看这个是你想要表达的意思吗?--gaosong2101 🏠 📫 📜 2020年7月13日 (一) 08:31 (UTC)
- 另外,我个人提几个(!)意见:
- 声明了(通过模板、注释等方式)就可以,只能使用模板太局限了;
- 若官方不使用30小时制,或者该领域不常用,则不要刻意转换为30小时制;
- 对30小时制的时间应该提供注释或使用Template:Abbr,提供12小时制或24小时制的时间,以便读者阅读。这一点也许可以通过创建个模板自动转换时间解决。不过这样的话,声明也许就没什么必要了。 gaosong2101 🏠 📫 📜 2020年7月13日 (一) 08:31 (UTC)
- @Huangsijun17,您看这个是你想要表达的意思吗?--gaosong2101 🏠 📫 📜 2020年7月13日 (一) 08:31 (UTC)
- 好像有类似模板应该只有t:日本深夜动画?不一定是模板,可以是手写的提示?——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月14日 (二) 00:54 (UTC)
- 动漫区里自成一派,存在反汉语言习惯的,反翻译命名常规的规则。——Huangsijun17(留言) 2020年7月15日 (三) 01:56 (UTC)
- 各位,我创建了T:30h和T:36h模板。
{{30h|26:33}}
的效果:26:33。不过{{30h|19:30}}
就感觉怪啰嗦的,19:30,也许可以省略?本人编辑模板的能力有限,有能力的各位请踊跃修改。也欢迎大家对这种方式给予反馈。 gaosong2101 🏠 📫 📜 2020年7月15日 (三) 14:32 (UTC) - 悬浮显示注释的话手机用户怎么破?--Super Wang※DC不是贪食蛇,请勿盲目刷分 2020年7月18日 (六) 02:34 (UTC)
- 好问题……那改成类似t:tsl风格的如何?gaosong2101 🏠 📫 📜 2020年7月20日 (一) 09:24 (UTC)
COVID-19条目共识后续
拟议WP:UPNOT及WP:SIGPROB之修订
有鉴于WP:SOAP及WP:NOTBLOG,现拟议WP:UPNOT及WP:SIGPROB之修订如下:
|
|
|
以上。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 03:42 (UTC)
意见
分段1
- 所以阁下想全面废除Category:政治主张用户框模板内的模板?-游蛇脱壳/克劳棣 2020年7月1日 (三) 04:02 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 04:12 (UTC) 确实。你可以看一看6月27日的存废讨论和VPO发生什么事。
- (依据我的记忆,这好像是文言维基百科的模式。)ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 04:14 (UTC)
- “任何形式”包括用户框吗?那现有的政治用户框如何处置?全部删掉?--CRHK128☎ “一国两制”寿终正寝 2020年7月1日 (三) 04:30 (UTC)
- 确实。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:25 (UTC)
- 反对,我用户页放两句也要管?--Wright Streetdeck 香港人反抗 2020年7月1日 (三) 04:35 (UTC)
- @Streetdeck:请观目前有些使用者页面多年以来不仅仅是“两句”之言而已。阁下的页面我个人并无任何反对之处,然请阅读下列我所陈述的观点。至于要不要“管”,WP:NOTBLOG。使用者页面亦有其存在的意义与标准,所以当然要管理,不希望被管理者大可移步自建部落格。AristippusSer(留言) 2020年7月1日 (三) 04:51 (UTC)
- 我只支持禁止超过50字,否则反对。--Wright Streetdeck 香港人反抗 2020年7月1日 (三) 04:57 (UTC)
- 50字可以写的内容太多。基本上能够写50字,都肯定有重复述说或进一步阐释。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:25 (UTC)
- 我原本打算跟大家说容许20个字作为折衷办法,但我最后放弃了,因为我想到此前有个别用户的签名上即使只有14个中文字,也已经可以做到“进一步阐释”。14字就已经可以做到“进一步阐释”,何况50字?ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:39 (UTC)
- 另外,相关提议规定同时适用于签名,你在签名放50个字上去,很难不违反签名长度不得长于255的规定(因为你需要放置用户页、用户讨论页和用户贡献页的连结中的至少其中一个)。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:30 (UTC)
- 50字可以写的内容太多。基本上能够写50字,都肯定有重复述说或进一步阐释。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:25 (UTC)
- (!)意见:对于修订方针的方向,我持赞成态度。具体该提案细节尚未详细阅读,故暂不发表详细意见。然而针对一个我预期很多人可能会提出的问题我想发表一下看法。下列的发言很大概率会有大部分人认为全面禁止个人页面政治宣言过于极端,我亦觉得并不一定要以禁止的形式解决这一问题。以我的观点,个人页面政治宣传的衡量标准有一个较为主观的度:如果打开一个使用者页面,注意力马上被大量与编修百科无关的政治宣传吸引(具体例子目前颇多,此不一一列举),则违反百科使用者页面的初衷,相信任何理智参与讨论者都不会质疑。然而我认为在使用者页面上载录个人政见,并非一定与百科全书不相关;如果参与讨论一方认为让其他讨论者了解其根本政治立场有助于各方相互理解,我认为是一件好事。但是出于这个目的来说,大可以允许视觉上少量的,并非一眼望去所看到的主要内容的政治宣言存在,比如侧边栏中的用户框。
- 当然,或许这个意见从现有的社群氛围上不可行也未必可说,但我的希望是理智、善意的讨论能够在放任与禁止之间权衡一个合适的标准。假若这个希望无法实现,我更倾向于附议全面禁止任何不直接相关的政治立场表达,而不是纵容背离了百科修订者页面初衷的使用者页继续存在下去。(当然,认为自己的页面不可以没有政治宣言者完全可以考虑在维基百科以外另搭建政治宣言网站,并在自己的使用者页面上加入连结。只要不违反WP:SPAM,相信这一操作任何人都不会有反对意见。)AristippusSer(留言) 2020年7月1日 (三) 04:46 (UTC)
- 我认为在中文维基百科采用主观准则并不可行。中文维基百科的各位不懂得自制,采用主观准则会滋生各种不同阵营的用户的双重标准。若非如此,我也不会提一个如此严格,但是有明确的客观标准的提案。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:30 (UTC)
- @Sanmosa:我的主要担忧是,如果采纳现行的提案,那么新用户没有了解方针在使用者页面上随便提到了几句政治,虽然无伤大雅但却为潜在的恶意提删/投诉带来了空子。我确实同意中文维基百科在政治问题上比起他语种冲突都要更加严重(由于中文世界本来就有巨大的政治隔阂),也较为同情“不如直接全盘禁止”的立场,但是有鉴于维基百科的基本模型本来就建立在理性、对话、共识之上,我只想说:如果绝大多数用户(除去某几位极端主义者外)连如此简单的一个判断问题都无法进行理性的对话并建立共识,那么中文维基百科整体的存在,是否失去意义?AristippusSer(留言) 2020年7月1日 (三) 14:18 (UTC)
- (+)赞成。主要是应该避免与维基百科无关内容成为一眼望去看到的主要内容,简单、适量宣示的存在应该允许。能否明确订出一个简单、适量的客观标准是问题所在。 DRIZZLE (按此给我留言) 2020年7月2日 (四) 01:48 (UTC)
- 我认为在中文维基百科采用主观准则并不可行。中文维基百科的各位不懂得自制,采用主观准则会滋生各种不同阵营的用户的双重标准。若非如此,我也不会提一个如此严格,但是有明确的客观标准的提案。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:30 (UTC)
- (!)意见: 根据英文维基百科有关用户页介绍首段:“User pages are mainly for interpersonal discussion, notices, testing and drafts (see: Sandboxes), and, if desired, limited autobiographical and personal content.”意指可有有限的个人介绍及个人内容。
- 于同页“What may I not have in my user pages?”中也有指“Generally, you should avoid substantial content on your user page that is unrelated to Wikipedia.”意指用户页“应避免”有与维基百科无关的资讯,而并非完全禁止。[1]
- 中文维基百科制度应根据英文维基百科,突然改变并脱离英文维基百科制度似乎并不适合。--anson. 2020年7月1日 (三) 05:01 (UTC)
- WP:ENWPSAID。而且,中文维基百科的各位并不如英文维基百科的用户一般自制,那样英文维基百科的宽松规定在中文维基百科就会成为争论和违反规则的根源。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:23 (UTC)
- (:)回应:好,明白并理解。-anson. 2020年7月1日 (三) 07:33 (UTC)
- WP:ENWPSAID。而且,中文维基百科的各位并不如英文维基百科的用户一般自制,那样英文维基百科的宽松规定在中文维基百科就会成为争论和违反规则的根源。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:23 (UTC)
- 如果大家懂得自制、自重,我根本不需要作如此喧哗两成败的提案。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 05:23 (UTC)
- 对于用户页,(-)反对一刀切禁止声明政见等,但可以界定一个字数限制和占全页面的视觉面积比例,免得再出现争议。对于签名禁止表达政治观点则支持。另外,绝不追溯以往行为,也不应因为新规则通过就将用户以前的行为解读为不当。 Classy Melissa (批判一番) 2020年7月1日 (三) 05:44 (UTC)
- 另外,我注意到有个别用户在用户页表达政见时使用了不文明的文字,甚至直接是粗口。这种应该明确禁止。 Classy Melissa (批判一番) 2020年7月1日 (三) 05:51 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:04 (UTC) 就第一部分,如果新规定通过,只有在相关用户拒绝依照新规定改正的情况下,当刻相关拒绝改正的行为才会被算成扰乱,此前的不算。就第二部分,相关事宜已经有文明方针可以处理。
- 另外,我注意到有个别用户在用户页表达政见时使用了不文明的文字,甚至直接是粗口。这种应该明确禁止。 Classy Melissa (批判一番) 2020年7月1日 (三) 05:51 (UTC)
- 大方向上(+)支持WP:UPNOT修订,不过不太赞成全面删除此类文字,另外也对此提案的界定性感到迷惑,例如“和平至上”、“支持Copyleft”、“认为生命就是奇迹”算不算此提案中的观点。(+)支持签名中不应该加入任何与维基百科无关的宣告。--DRIZZLE (按此给我留言) 2020年7月1日 (三) 05:47 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:04 (UTC) “支持Copyleft”和维基百科某程度上有关,无论在旧规定抑或提议规定,都不受规则所限,而可以无限宣告、阐述。“和平至上”这并不完全是一个观点,而是一个思想概念的本身,既然没有说明是否支持或反对这个思想概念,那样就不是观点(即使这个是观点,就用户名为“和平至上”者而言,显示用户名无可厚非,也不应该算成违规);类似的词汇有“武士精神”。“认为生命就是奇迹”严格上而言应该删除,但我会建议各位将提议条文和获得保留的旧有条文(“争议热烈或语调激昂的文句”)结合解读,如果相关文句并非“争议热烈或语调激昂”,或许可以从宽处理。
- 由于相关讨论意外地牵涉到个别用户名,我有需要请相关用户表达一下意见。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:13 (UTC)
- @Sanmosa:我的用户名并未违反WP:UN,而签名内有用户名并无问题是常识,所以我认为,只要用户名并未违反WP:UN的要求,包含在签名内并没有任何问题。 【和平至上】支持通过港区国安法💬 2020年7月1日 (三) 12:44 (UTC)
- 至于用户页或签名其他内容,我暂时没意见,只要求划一的标准。 【和平至上】支持通过港区国安法💬 2020年7月1日 (三) 12:48 (UTC)
- @人人生來平等: 类似地,请问您如何看? KONNO Yumeto Au revoir, Hong Kong 2020年7月1日 (三) 14:05 (UTC)
- 正如Sanmosa君上面所述,显示使用者名称无可厚非,所以也无必要作出更改。至于禁止方面个人倾向仅可保留用户框,其他如签名规定则无意见。--人人生来平等 留言 2020年7月1日 (三) 16:25 (UTC)
- 另一个(?)疑问:条文里写
宣告自己信奉某宗教思想(包括但不限于基督教、伊斯兰教、佛教及无神论、不可知论等)本身不属于本条文所谓之“观点”。
然而,从语义上来说,宣告自己信奉无神论(狭义)几乎等同于宣告自己支持神不存在这一观点,提案人认为其中是否存在矛盾? DRIZZLE (按此给我留言) 2020年7月1日 (三) 13:53 (UTC)- 同样道理,从语义上来说,宣告自己信奉存在神的宗教几乎等同于宣告自己支持神存在这一观点。这是无可避免的,但为了保障基本的宗教自由,我只能如此。你视同例外吧。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 23:08 (UTC)
- 由于相关讨论意外地牵涉到个别用户名,我有需要请相关用户表达一下意见。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:13 (UTC)
- 我想说明一下为何设置字数限制并不可取:如上所言,我想到此前有个别用户的签名上即使只有14个中文字,也已经可以做到“进一步阐释”,但同时如果给予的字数限制过于严谨(容许的字数过少),那样用户根本连一个简单宣告也没可能做到,这样倒不如完全禁止宣告,否则势必两面不是人。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:08 (UTC)
- 签名可以全面禁止。用户页引入字数限制,即使用户进行少量“进一步阐释”,其实也问题不大。 Classy Melissa (批判一番) 2020年7月1日 (三) 06:27 (UTC)
- 但是“进一步阐释”本身已经违反了WP:SOAP,而且相关阐释很多时候都违反WP:5P4。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:31 (UTC)
- 更甚者,标点符号虽然不计算在字数内,但是也可以构成“进一步阐释”。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:34 (UTC)
- 我觉得只要是少量(譬如50字至100字),当IAR处理算啦,严重的话即使没有超过字数,也可以按SOAP处理。 Classy Melissa (批判一番) 2020年7月1日 (三) 06:41 (UTC)
- 中文维基百科的用户很懂得善用字数。这恐怕只能从严,不能从宽。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:12 (UTC)
- (▲)同上(-)不支持按字数限制。 DRIZZLE (按此给我留言) 2020年7月1日 (三) 16:44 (UTC)
- 我觉得只要是少量(譬如50字至100字),当IAR处理算啦,严重的话即使没有超过字数,也可以按SOAP处理。 Classy Melissa (批判一番) 2020年7月1日 (三) 06:41 (UTC)
- 更甚者,标点符号虽然不计算在字数内,但是也可以构成“进一步阐释”。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:34 (UTC)
- 但是“进一步阐释”本身已经违反了WP:SOAP,而且相关阐释很多时候都违反WP:5P4。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 2020年7月1日 (三) 06:31 (UTC)
- 全部(-)反对+(!)意见:管得太多。此事本来就是两个人的私人恩怨,一方非得要殃及池鱼,那就应该对扩大化报复的一方进行制裁,而被无辜牵连进来的人,没有任何理由让他们买单。现今方针已足以应对,没有必要修改。——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2020年7月1日 (三) 06:39 (UTC)
- (:)回应:用户页和签名的问题近段时间已经反复产生争议,波及的用户远不止这两位。如果没有客观的标准,以后还会有更多争议,这就是问题。我认为方针应该改。 Classy Melissa (批判一番) 2020年7月1日 (三) 06:43 (UTC)
- (▲)同上。阁下的用户页此前多次被提删也是因为这个问题(我不评论相关提删是否合理)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:12 (UTC)
- (?)疑问:烦请解释以下情况在通过本规则后的合法性。
- 第一:如果我指出因为AA政权在AA地方封锁维基百科,本人反对AA政权。
- 第二:假如我列数AA政权所做的坏事/丑闻/图片,而并没有指出对AA政权的立场。
- 第三:假如我对AA政权所做的事和自己的立场一字不题,但单纯展示政权的官方名称。
- 第四:本人展示没有宣名意义的颜色旗帜,例如黄色加黑色的旗帜。
- 敬请回答,谢谢。-anson. 2020年7月1日 (三) 08:01 (UTC)
- 回答如下:
- 与维基百科有关,合规。
- “坏事”和“丑闻”两词本来就已经具有立场论断,已经属于观点表达。至于相关列举本身是否合规,要视乎实际表达方式。
- 要视乎显示的方式及配合相关显示的其他相关元素。
- 如果相关旗帜本身并无(潜在)思想/意义,那样展示相关旗帜就并不是“作出发挥相关思想的行为”,因为“思想”在此处并不存在。
- 以上。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:08 (UTC)
- (!)意见:“简而言之,即‘有专案、组织地进行一系列的行为以达到某目标,尤其是为支持或反对某事物而作出抗争,或吸引人注意某事物’”中著名必须是“一系列行为”,似乎与是次修改本规意义不相符,敬请审视;另外,“以达到某目标”意义不明,请解释什么的目标才与此规抵触;此外,何谓吸引人注意?这里字眼容易引起争执,烦请修定一下。-anson. 2020年7月1日 (三) 08:24 (UTC)
- 在用户页和签名表达相关观点可能只是该“一系列行为”的其中一部分,而该“一系列行为”的其他部分可能包括留言的强烈政治意涵等。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:14 (UTC)
- “达到某目标”是旧有条文范围,非提议修订所牵涉的部分。请自行参见该段文字附上的英文原句。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:31 (UTC)
- “吸引人注意”很主观,只要有任何一个人认为相关宣告对他而言是很明显的存在,那就是“吸引人注意”。不过既然条文对于可能也不“吸引人注意”的宣告也予以禁止,“吸引人注意”应该就不是新条文的重点,所以如果就“吸引人注意”这一句进行争论,会是浪费时间。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 11:40 (UTC)
- (!)意见:个人认为全面禁止不现实。可以仅允许有限使用用户框来表达个人观点,禁止使用用户框以外的形式(如{{个人声明}}等模板或纯文字等)宣传与维基百科无关的个人观点。这样可以规范用户页的格式,以防部分用户在用户页张贴“大”字报。--Steven Sun(留言) 2020年7月1日 (三) 08:04 (UTC)
- 全面禁止其实很现实。文言维基百科就是这样做的。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:50 (UTC)
- 如果只能全面禁止或维持现状二选一,我倾向支持全面禁止。 Classy Melissa (批判一番) 2020年7月1日 (三) 10:53 (UTC)
- 几件事情:
- 用户的政治宣告宜少不宜多。横跨整行的明显已经不单纯只是宣告。
- 用户页有过度花俏的问题。这应当独立拿出来讨论。我认为用户名称的用户页(User:Example)应当禁止大量div 或 HTML code出现。测试请用沙盒。
- WP:5P4应当用明显的条目内容。
- 个人支持政治宣告应当为独立页面,并且相关页面的连结不应放于显眼处,除非该等宣告与维基百科有密切关系。
- 至于签名,我认为在签名添加具政治意涵的宣告均为不妥,且有可能无助讨论的继续。
- 个人认为,所有具政治意涵的用户框且则应当移至该框创建者的用户名字空间下,并以机器人作一次替换及删除所有redirect。--1233 (T / C) 2020年7月1日 (三) 08:19 (UTC)
- 我觉得这种规定是防君子不防小人罢了——如果不在用户空间和签名体现个人政治倾向就能叫做“君子”,反之就是“小人”的话。今天禁了用户页,明天又要禁什么?比起没坏别修,这个议题的问题更类似于“早晚都要坏,修也只是一时而已”。--Super Wang※庆祝香港回归廿三年暨特区国安法顺利实施🇭🇰🇨🇳 2020年7月1日 (三) 09:06 (UTC)
- 我觉得用户页的"简单宣示政治主张"早已坏掉。问题只是坏到哪一个地步。--1233 (T / C) 2020年7月1日 (三) 12:37 (UTC)
- 这里“禁”的目的并不是为了“防”,所以我不认同你的描述。这里“禁”的目的是为了杜绝相关已经发酵的争议,而不是“防”任何人。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 10:46 (UTC)
- 以上其他观点稍后回应。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 09:08 (UTC)
- 吐槽:本来政治用户框模板就是用来简单宣示政治立场的,但是被某些政治狂人带跑了…--Starry🌟Home🏠兜兜转转▫返到原点🏴 2020年7月1日 (三) 10:15 (UTC)
- 所以我才说中文维基百科的各位并不如英文维基百科的用户一般自制。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 11:30 (UTC)
- 个人觉得简单宣示还是可以的,关键在如何把握好简单宣示的度。 DRIZZLE (按此给我留言) 2020年7月1日 (三) 13:58 (UTC)
- 中文维基百科内能把握好简单宣示的度的人没几个。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 22:49 (UTC)
- 个人觉得简单宣示还是可以的,关键在如何把握好简单宣示的度。 DRIZZLE (按此给我留言) 2020年7月1日 (三) 13:58 (UTC)
- 所以我才说中文维基百科的各位并不如英文维基百科的用户一般自制。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 11:30 (UTC)
- (!)意见U:CRHK128、U:苏州宇文宙武等一大批被提删用户的用户页上都出现了横跨数行的政权标志(中国国旗、中国国徽、英国国旗等),出现这类标志的用户页更容易冒犯到其他编者。U:雾岛圣的用户页上出现了一面横跨五行的五色旗,但是并未对社群造成困扰。对于这类过于大的政治标志,应该结合其他内容限制使用(使用大面积旗帜后不允许再进行立场相同的其他声明),还是完全禁止此类标志?--jingkaimori(留言) 2020年7月1日 (三) 13:52 (UTC)
- (-)反对 壅人之口,掣人之肘。 KONNO Yumeto Au revoir, Hong Kong 2020年7月1日 (三) 15:44 (UTC)
- 那中文维基百科的用户懂得自制吗?ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 15:55 (UTC)
- 遂行株连之恶法? KONNO Yumeto Au revoir, Hong Kong 2020年7月1日 (三) 16:13 (UTC)
- “株连”何在?ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 22:36 (UTC)
- @Yumeto:请见:“认为自己的页面不可以没有政治宣言者完全可以考虑在维基百科以外另搭建政治宣言网站,并在自己的使用者页面上加入连结。只要不违反WP:SPAM,相信这一操作任何人都不会有反对意见。”
- 百科不是民主试验场,不是不加限制的言论自由平台。所谓“壅人之口”请君往与en:User:Jimbo Wales议之可矣。AristippusSer(留言) 2020年7月1日 (三) 16:21 (UTC)
- 那中文维基百科的用户懂得自制吗?ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 15:55 (UTC)
- (-)反对:现行方针足以解决相关问题,无修改之必要。且修改后弊大于利。--风云北洋※Talk 香港回归23周年 2020年7月2日 (四) 10:02 (UTC)
- 现行方针并不能解决相关问题。相反,现行方针是在制造相关问题。现时的AFD就是“现行方针制造相关问题”的一个好例子。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 04:48 (UTC)
- (-)反对:正常使用应该没有问题,滥用就还提请WP:AFD进行讨论。——Hualin~希望の星は青霄に昇る(留言) 2020年7月2日 (四) 14:21 (UTC)
- 问题在于现在根本没人在“正常使用”。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 04:48 (UTC)
- (-)反对:不如这样,仅允许使用可管控的有限用户框表达立场(?)not a User:慎言慎行老法师写维基?写个屁! 2020年7月2日 (四) 17:13 (UTC)
- 用户框本身的用词和机能重复的用户框的使用现时已经不受控。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 04:48 (UTC)
- (-)反对,反对文字狱。🌜山西特产批发零售™️🌽🌶️🍎🍠🐓🐐(留言) 2020年7月3日 (五) 03:21 (UTC)
- 双重标准下的提删似乎才是真正的“文字狱”。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 04:48 (UTC)
- (+)支持签名禁止与维基百科无关的宣传的限制(之前讨论过但没通过),但是(-)倾向反对用户页完全禁止政治宣告,个人认为有点矫枉过正,(&)建议限制到只能使用用户框表达。gaosong2101 🏠 📫 📜 2020年7月4日 (六) 07:43 (UTC)
- 用户框本身的用词和机能重复的用户框的使用现时已经不受控。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月4日 (六) 07:53 (UTC)
- 我已经看到您之前的同样的回复了,您能具体展开解释一下这个不受控是指的什么吗?现时如何不受控了?gaosong2101 🏠 📫 📜 2020年7月4日 (六) 08:04 (UTC)
- 你这样处理其实只不过是把相关语句由用户页本身转移到用户框而已。而且,使用多个机能重复的用户框也已经能构成重复述说或进一步阐释。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 02:26 (UTC)
- 那我觉得一刀切还是有点过了,限制只使用用户框可以避免出现“大字报”用户页,我觉得在目前这就足够了,如果未来又被人以各种奇怪的形式滥用了再修条文即可,不建议为了简单方便而提出懒政[开玩笑的]一刀切解决。另外我对用户框内容的观点同Help_talk:用户框#建议向文言文维基百科借鉴一下一个规定讨论中的大部分人,即内容遵守WP:CIV即可,特别是反对观点的用户框。有问题的用户框可以提删,从而减少用户页被提删的情况。gaosong2101 🏠 📫 📜 2020年7月5日 (日) 06:58 (UTC)
- 另外我觉得适当的表达政治观点可以让交流双方有更好的了解,避免踩雷[原创研究?]。gaosong2101 🏠 📫 📜 2020年7月5日 (日) 07:05 (UTC)
- 问题在于大家都没有把握好那个度的能力。如果有的话,我也不会提案,因为引发我提案的事件没有发生。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 08:44 (UTC)
- 我觉得我还是持原有观点,可以限制,但不要一刀切,如果限制后再次出现问题则再次讨论修改即可。被滥用或者部分用户缺乏程度把握的能力,可以归咎于条文的模糊,让他们钻了空子,因此可以考虑下面#要不要放宽一点章节中我的“观点量化”的方案,“限制仅能使用用户框,并且表达观点的用户框不得超过*个”,结合我上文中“有问题(如违反WP:CIV)的用户框可以提删”。另外,您说的“因为引发我提案的事件没有发生”是指?引发这次提案的原因不是U:痛心疾首提删U:CRHK128的用户页,然后U:CRHK128不满U:痛心疾首只提删了他一个人的用户页,进而大量提删其他人的用户页吗?gaosong2101 🏠 📫 📜 2020年7月6日 (一) 11:29 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:23 (UTC)
- gaosong2101 🏠 📫 📜 2020年7月10日 (五) 16:44 (UTC) 理解,不过我估计这次提案也很难有什么进展。
这只是导火线。远因绝对不是这个,但远因才是我提案的最主要的理由。苏州宇文宙武的用户页能多年来被多次提删,也就代表这问题已经很久了。
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:23 (UTC)
- 问题在于大家都没有把握好那个度的能力。如果有的话,我也不会提案,因为引发我提案的事件没有发生。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 08:44 (UTC)
(-)反对禁止涉政用户框。可以对用户页使用涉政用户框做出严格规范,如不得超过3个(多余的放在子页面),只能放在用户框的底端,只能在代码模式下第50行之后出现等 ——羊羊(留言 | 贡献) 2020年7月4日 (六) 12:36 (UTC)
- 你这样处理其实只不过是把相关语句由用户页本身转移到用户框而已。不全面根除,问题不可能解决。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 02:26 (UTC)
- (:)回应:但是严格规范后可以避免一点进个人主页就是涉政信息的情况。(另提出2点:用户页的涉政用户框只能采用一般大小的;用户签名不得含有链接至用户之用户框页面的链接) ——羊羊(留言 | 贡献) 2020年7月5日 (日) 09:05 (UTC)
- (+)赞成括号里提出的两点。gaosong2101 🏠 📫 📜 2020年7月5日 (日) 10:26 (UTC)
- (:)回应:但是严格规范后可以避免一点进个人主页就是涉政信息的情况。(另提出2点:用户页的涉政用户框只能采用一般大小的;用户签名不得含有链接至用户之用户框页面的链接) ——羊羊(留言 | 贡献) 2020年7月5日 (日) 09:05 (UTC)
- (+)支持:用户页不是个人网站,不能用来表达个人的政治观点,个人倾向于同意填补方针漏洞封杀类似的行为,以正视听。--百战天虫(留言) 2020年7月6日 (一) 11:41 (UTC)
- 请问当“除非相关观点跟维基百科有关(例如声明自己不接受任何维基荣誉),否则任何观点(例如自己的政治理念、宗教思想等)都不得以任何形式在用户页予以宣告”正在实行且此条款亦适用于签名时,现时在下的签名是否符合方针?--来自热烈庆祝贵市长沙地铁再获双线贯通的Hamish论 2020年7月6日 (一) 14:34 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:51 (UTC)
- 长沙地铁再获双线贯通的Hamish论 2020年7月6日 (一) 14:54 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:55 (UTC) “真是个好事情”属于观点,这就不行了。
那改成“贵市长沙地铁再获双线贯通真是个好事情”呢?--来自热烈庆祝贵市 - DRIZZLE (按此给我留言) 2020年7月6日 (一) 14:59 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 15:04 (UTC) 长沙地铁恢复通车和港区国安法通过两者存在分别:前者是非政治性的,而后者是政治性的。政治性的事情通常争议热烈或语调激昂,因此实际上在提议条文中被禁止。我再一次建议各位将提议条文和获得保留的旧有条文(“争议热烈或语调激昂的文句”)结合解读。
那这样似乎不也可以“热烈庆祝港区国安法通过”吗,和没限制有什么区别?
“热烈庆祝贵市长沙地铁再获双线贯通”是一个人的心理状态,不是观点。这方面没问题。 - 长沙地铁再获双线贯通的Hamish论 2020年7月6日 (一) 14:54 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:51 (UTC)
- 本人(+)赞成AristippusSer的观点,(-)强烈反对一刀切,我认为至少应该留下政治、宗教相关的用户框。--忒有钱🌊塩水あります🐳(留言) 2020年7月6日 (一) 14:57 (UTC)
分段2
- (!)意见:我想补充提出一个对现有提案的意见。设若现今通过全盘禁令,我较为担忧的问题是新使用者太过于容易无心触犯,为潜在的恶意检控提供口实。即使我们现在的讨论都是正当的,也有足够的证据表明除去全面禁止之外别无他法,若一定要对每个新使用者解释“中文维基百科禁止个人页面表达任何政治立场”的来龙去脉,我担心会令人反感而造成不好的影响。(文言大典确实有此规定已久,然而彼社区本来受众远小于此,也更加容易建立共识于合作)
- 其实,以我的看法,目前所有包括在此提案提出之前的讨论,所有的参与者最主要的诉求终归还是归结在用一只手可以数清的几个使用者目前的个人页面上。我不想在此点名批评演变成大字报,但是其中不乏有资深用户有恃而无恐,早已将方针指引当作戏谈,将反对意见当作常年提案,因此才会将这个问题推动到目前需要讨论“全盘禁止个人页面政治表述”的一步。我认为,对这些使用者的个人页面,依目前的方针完全可以强令要求其去除与维基百科不相关的政治宣言内容并转化为争议较小的表达方式(比如合理数量的用户框)。假如目前的方针就已经因为政治冲突而缺乏执行力度,又有什么理由认为更加强力的方针会让这些人退让?这才是问题最本质的一层,全盘禁止最终还是试图以非政治手段解决一个政治问题,后者如果不能得到解决恐怕新禁令也只会沦落成给“年年提删”火上浇油。AristippusSer(留言) 2020年7月1日 (三) 14:47 (UTC)
- 不认同“所有的参与者最主要的诉求终归还是归结在用一只手可以数清的几个使用者目前的个人页面上”。你完全低估了情况。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 15:54 (UTC)
- 是否低估情况为一说,然而先执行现有条例于最严重的触犯者,之后观其反应也可以对此讨论有参考价值。当然与此同时该讨论也应鼓励大众踊跃进行。AristippusSer(留言) 2020年7月1日 (三) 16:24 (UTC)
- 由于各方的双重标准,我不认为所有严重违规的页面都能够得到恰当处理,最近还有胡乱关闭相关存废讨论的情况,因此只有完全禁止才能够杜绝相关双重标准。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 22:40 (UTC)
- @Sanmosa:我仍认为如果无人站出来先处理那几个人,则这个提案最终也只是成为常年提删的一个插曲的下场而已。是否到了一定程度后可以绕过中文社区的官僚不作为,直接去MetaWiki RFC?我认为最为严重的几个触犯者已经严重违反了"Terms of Use: Civility — You support a civil environment and do not harass other users",一直在影向整个维基媒体的形象。如有需要我可以参与草拟提案。AristippusSer(留言) 2020年7月2日 (四) 23:31 (UTC)
- meta:Requests for comment/How to improve RfC Process看来meta rfc现在也是一滩浑水,若果如此我还是(+)支持这个提案好了(虽然不抱有通过的希望),至少把皮球踢到对方场地让他们去抱怨也要好一些。AristippusSer(留言) 2020年7月2日 (四) 23:38 (UTC)
- 由于各方的双重标准,我不认为所有严重违规的页面都能够得到恰当处理,最近还有胡乱关闭相关存废讨论的情况,因此只有完全禁止才能够杜绝相关双重标准。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 22:40 (UTC)
- 是否低估情况为一说,然而先执行现有条例于最严重的触犯者,之后观其反应也可以对此讨论有参考价值。当然与此同时该讨论也应鼓励大众踊跃进行。AristippusSer(留言) 2020年7月1日 (三) 16:24 (UTC)
- 不认同“所有的参与者最主要的诉求终归还是归结在用一只手可以数清的几个使用者目前的个人页面上”。你完全低估了情况。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 15:54 (UTC)
- (-)反对 壅人之口,掣人之肘。 KONNO Yumeto Au revoir, Hong Kong 2020年7月1日 (三) 15:43 (UTC)
- 那中文维基百科的用户懂得自制吗?ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月1日 (三) 15:54 (UTC)
- (-)反对WP:UPNOT修正案,但在此另提议隐退者的用户页面不得批评任何其他维基用户,除非返回,否则不合乎比例原则。(+)支持WP:SIGPROB修正案。Jusjih(留言) 2020年7月3日 (五) 02:35 (UTC)
- 如果大家仍拒绝承认现行方针正在制造问题此一事实,并意图使问题持续的话,我无话可说。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 04:52 (UTC)
- (+)支持:某人的选择性提删令我只好支持全面禁止,以免同类事件再次发生。--CRHK128☎ “一国两制”寿终正寝 2020年7月3日 (五) 05:31 (UTC)
- (-)反对(≠)不妥协:致@Sanmosa::就阁下所提出的方针修改提议中“除非相关观点跟维基百科有关(例如声明自己不接受任何维基荣誉),否则任何观点(例如自己的政治理念、宗教思想[3]等)都不得以任何形式[4]在用户页予以宣告”一段话,我在此提出问题:如果说要禁止这一类的观点宣告,就以宗教问题举例:那么请问阁下有对避免出现一个其他教教徒抑或是无神论者因为不知道对方信仰而导致冲突的出现的方法吗?如果没有,那么阁下为什么要提议禁止宣告自己的宗教信仰呢?--FinalFantasy※欢迎讨论※武汉加油! 2020年7月7日 (二) 11:39 (UTC)
- 请你先阅读整个拟议提案(包括注释部分)。拟议提案的注释3有提到“宣告自己信奉某宗教思想(包括但不限于基督教、伊斯兰教、佛教及无神论、不可知论等)本身不属于本条文所谓之“观点””。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:19 (UTC)
- (+)支持在签名中禁止政治、宗教相关内容,但(-)强烈反对在用户页禁止,理由见上。--忒有钱🌊塩水あります🐳(留言) 2020年7月10日 (五) 16:31 (UTC)
2 comments
两点:
- 第一,诸如“中文维基百科的用户(在用户页使用方面)不如英文维基懂自制”之类非同寻常的断言需要非同寻常的证据来支持,而这一点提案人并没有给出这种级别的证据。说得难听一点,请问阁下认识几位中文维基人,又认识几位英文维基人?他/她/它们是否有代表性?何以一杆子打翻一船人?
- 第二,双重标准,或者说选择性执法是一个问题,但是提案人给出的方案非但不能从根本上杜绝选择性执法的问题,反而可能会加剧这一问题。选择性执法的必要条件有二,一为模糊性立法,如答主所述;但更重要的是,普遍性违法——试想一下,如果不是普遍性违法,就算是立法层面上有模糊,只要受影响的用户数量有限,一视同仁地来一次大讨论一次性解决即可,又何来选择执法的问题呢?而不切实际的高规格立法恰恰是普遍性违法的根源。提案人的方案非但未有解决模糊性立法的问题——它依然是用自然语言描述的,何谓“观点”仍然是一个模糊的概念,反而大幅度拉高了立法的规格,使原先合法的变为不合法。那么问题就来了,大幅增加的存量和增量如何处理?没有程序可以判定页面是否含有与维基百科无关的观点;滥用过滤器当然不可以;巨量的执法任务落到少量,且要处理更紧急事务如主名字空间中新页面巡查,反破坏的用户手里,从哪个意义上来说都是催生选择性执法的温床。--Antigng(留言) 2020年7月3日 (五) 05:13 (UTC)
- 我对于Antigng拒绝承认事实深感遗憾。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月3日 (五) 05:56 (UTC)
- 简单的问题,闯红灯是不是普遍性违法,不闯红灯是不是高规格立法?。->>Vocal&Guitar->>留言 2020年7月4日 (六) 00:24 (UTC)
要不要放宽一点
开一个小口,允许表述不超过5个的观点?--Starry🌟Home🏠兜兜转转▫返到原点🏴 2020年7月5日 (日) 11:53 (UTC)
- (-)反对:怎么计算一“个”?一“个”是多少篇幅算一个?不论一个观点的展示多么扎眼(如用红色、整篇、超大字号等)都算一个吗?我觉得U:Sanmosa提这个提案的一个目的是为了解决当前条文中的模糊问题。(&)建议:如果要按照这个方向改,可以考虑限制仅能使用用户框,并且表达观点的用户框不得超过*个。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 05:56 (UTC)
其实我发现上面已经人已经表达过类似的观点,但是没有被整理起来,讨论的意图似乎不高,因此在这里整理一下。
首先,限制用户页中表达观点,特别是政治观点的原因是这些会对维基百科读者的观感造成负面影响[1]。
目前的用户页条文虽对此类内容有限制,但是过于宽松,可能会让部分用户“钻空子”,而一刀切的方式已有一些用户表示反对。因此,一种不是“一刀切”的解决方法是将展示观点的篇幅量化并限制。目前已知字数的限制的方式不合适,并已遭到上面多名用户的反对。另一种方式可以是限制用户框的数量,因此,对于用户页观点的表达的初步大致提案如下:
- 对于用户页的观点仅能使用标准大小(
div.wikipediauserbox
的大小不得超过240px × 47px,含padding和border但不含margin)的用户框来表达,并且 - 一个用户的用户页上的表达观点的用户框不得超过*个[2],并且
- 用户框模板违反WP:CIV、WP:SOAP等已有中文维基百科方针,或尝试对观点“进一步阐释”的,提删并由社群决定是否违规。
- 对于用户页的观点仅能使用标准大小(
欢迎批评指正。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 12:02 (UTC)
另注:条文中的“观点”继承Sanmosa上文中的对观点的定义,因为是初步大致的提案,因此达成大致共识后再润色。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:35 (UTC)
参考资料
- 阁下认为自己用户页是否合规,按照你的说法?-- Air7538#Talk 2020年7月6日 (一) 12:21 (UTC)
- 我用户页上的一些用户框是不符合这个规定的,如Template:User EACS 爱汉字、Template:User dictatorship等不符合“标准大小”规定,Template:user 百度百科 NO中的“百毒百科”、Template:User Anti-FLG中的“轮子”、Template:User dislike CPC中的“河蟹”用词疑似蔑称,违反WP:CIV。若该提案可以获得共识,我将主动修改我自己的用户页以符合规定,并修改或提删相关用户框。对于我用户页的其他的用户框和内容,我认为是符合这个规定的。 gaosong2101 🏠 📫 📜 2020年7月6日 (一) 12:49 (UTC)
- 好吧,举例就有的说了。(-)强烈反对统一所有用户框“标准大小”。对百度的蔑称个人认为无关紧要,如果非要改我也没啥说的。其他政治用户框暂时不发表意见。最后如果要往统一所有用户框大小则我会一直跟进讨论,如不讨论这个则你你们随意。-- Air7538#Talk 2020年7月6日 (一) 12:59 (UTC)
- 不是统一大小,而是限制表达观点用户框的最大大小。设置最大大小只是担心有人会创建巨型用户框,那就和这些条目设定的目的背道而驰了。不过目前好像还没有巨型用户框,我可以接受没有最大大小的限制。能够问一下,您对限制大小的反对是出自什么原因呢? gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:07 (UTC)
- 没看出 User EACS 爱汉字 这种哪里需要改,如果这都需要改是不是维基百科开始“白色恐怖”了?巨型用户框怎么了?那巨幅图片违法了吗?是不是也得打死?-- Air7538#Talk 2020年7月6日 (一) 13:13 (UTC)
- 那您对U:Sanmosa的原提案我猜测也是反对?改Template:User EACS 爱汉字的确有点牵强,但是给予太多允许的空间又会有人钻空子,特别是一些自律性较差的人。这些提案的一个目的是避免用户页大字报的情况,巨型用户框表达观点与目前的用户页大字报几乎无异。其他的媒体表达形式的确有争议,比如说用户页挂巨幅的国旗算不算“观点”的范畴,这个尚不明确,Sanmosa也没有对上面的类似提问做出回应。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:35 (UTC)
- 先不说反不反对,我的大概意思是如果所有用户框统一大小是无必要的,因为不仅用户框,图片,视频,音频,css,js等任何花哨的表现形式,即使没有往政治等方面靠,是不是也要管?现在用户页挂人挂大字报有任何可行的形式,如果到某个程度,规范别人用户页行为就显得太鸡肋了,是不是给个封禁来的快hhh?另外在wp空间讨论这些和建设维基百科没有啥关系的,挺无聊的,你们继续吧hhh。看一个人不顺眼不用看用户页看贡献历史日志操作就够了。-- Air7538#Talk 2020年7月6日 (一) 13:56 (UTC)
- 条例仅应用于用户页表达观点的情形,观点的定义参照上文Sanmosa。对于讨论这个有没有用我已经在上面的引言说了,还有之前User:CRHK128用户页被提删相关的事。我只是希望在一大堆讨论之后会产生一些正面的改变、不让这些讨论付之东流罢了,如果您不想讨论请不要给我泼凉水,谢谢。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 14:16 (UTC)
- 那您对U:Sanmosa的原提案我猜测也是反对?改Template:User EACS 爱汉字的确有点牵强,但是给予太多允许的空间又会有人钻空子,特别是一些自律性较差的人。这些提案的一个目的是避免用户页大字报的情况,巨型用户框表达观点与目前的用户页大字报几乎无异。其他的媒体表达形式的确有争议,比如说用户页挂巨幅的国旗算不算“观点”的范畴,这个尚不明确,Sanmosa也没有对上面的类似提问做出回应。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:35 (UTC)
- 不是统一大小,而是限制表达观点用户框的最大大小。设置最大大小只是担心有人会创建巨型用户框,那就和这些条目设定的目的背道而驰了。不过目前好像还没有巨型用户框,我可以接受没有最大大小的限制。能够问一下,您对限制大小的反对是出自什么原因呢? gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:07 (UTC)
- 我用户页上的一些用户框是不符合这个规定的,如Template:User EACS 爱汉字、Template:User dictatorship等不符合“标准大小”规定,Template:user 百度百科 NO中的“百毒百科”、Template:User Anti-FLG中的“轮子”、Template:User dislike CPC中的“河蟹”用词疑似蔑称,违反WP:CIV。若该提案可以获得共识,我将主动修改我自己的用户页以符合规定,并修改或提删相关用户框。对于我用户页的其他的用户框和内容,我认为是符合这个规定的。 gaosong2101 🏠 📫 📜 2020年7月6日 (一) 12:49 (UTC)
- (+)支持使用用户框。但(-)倾向反对限制数量,因为具体使用多少个难以确定。可以禁止用户重复使用同一个用户框。--Steven Sun(留言) 2020年7月6日 (一) 13:20 (UTC)
- 我个人可以接受用禁止重复使用同一或表达同一观点的用户框取替用户框的数量限制。gaosong2101 🏠 📫 📜 2020年7月6日 (一) 13:39 (UTC)
- 有部分用户框是重复的,只不过表述不一样,个人还是(+)倾向支持限制数量。 ——羊羊(留言 | 贡献) 2020年7月16日 (四) 22:24 (UTC)
- 不反对限制表达观点只能使用用户框。--1233 (T / C) 2020年7月10日 (五) 02:22 (UTC)
- (&)建议对于用户页的观点仅能使用标准大小 → 用户页出现的与政治有关的用户框仅能使用标准大小 ——羊羊(留言 | 贡献) 2020年7月16日 (四) 22:24 (UTC)
- 标准大小和用户框数量我不认为应该限制。大小方面,我不认为用户框的大小、字体的粗幼和激进的政见有直接的关系,只能算是观感问题。观点限制数量方面,我可以有无数个观点,从非政治上的观点(“反对歧视自闭症人士”和“支持器官捐赠”)、维基百科的观点(“条目数量和质素应保持平衡”和“反对编辑战”)到政治上的观点(“支持国安法”和“反对国歌法”),我不认为限制可以从数量中决定。最后,个人不反对规管一些确实违反文明和言辞过于激烈的用户框。个人认为如果要立下详细完整的限制,需要好好评价和定义“观点”两字。PS:所有观点只要有人反对,都会引起争议。而且订立相关规定如果是为了避免争议,那么就等于是“不许打仗,所以不许有立场”,这样看起来就很匪夷所思了。只要规则有漏洞,都总会有人沾,所以倘若真的有订立规则的必要,就要想得周到。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月20日 (一) 17:34 (UTC)
- (:)回应:
- 关于大小和数量:其实这个提案并不是想直接针对“激进的政见”的,比如,用户页用标准大小的文字写“支持香港独立”比用户页各种挂大英国旗、大号文字的就好很多。说回来,的确只是观感问题,目的是不要把用户页做成政治宣传页。
- 关于“不许打仗,所以不许有立场”:的确有道理,但是维基百科应该更专注于编写条目,而非表达或宣传编者的观点和立场。
- 关于“观点”的定义:其实本来观点是想继承上文中Sanmosa的对观点的定义的,但是上面的讨论也似乎很遗憾没达成什么共识 囧rz...
- 关于漏洞:漏洞的话总会有的,想要考虑到所有的情况蛮难的,遇到的话再补漏就好了 gaosong2101 🏠 📫 📜 2020年7月20日 (一) 18:22 (UTC)
- 因为我目前有个人工作要完成,我晚上才有时间回复,希望各位体谅🙏🏻。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月21日 (二) 05:09 (UTC)
拟议先行修订签名指引
|
|
上面的争议似乎主要集中在用户页表达观点方面,而实操中签名的政见也会导致用户之间的冲突,甚至比用户页更严重。不妨先禁止在签名中表达政见。在条文中加入“什么不算违反规定”,有助厘清条文规定的界线。 Classy Melissa (批判一番) 2020年7月13日 (一) 02:34 (UTC)
- (+)支持,签名加各种政见之类的比用户页对讨论造成的负面影响大多了。gaosong2101 🏠 📫 📜 2020年7月13日 (一) 08:39 (UTC)
- 不过这样说起来,依上述修订,人物纪念性的签名就不合方针了(如,KirkTalkRIP Prof.Hawking(1942.1.18-2018.3.14)),是否考虑过于严苛。--Kirk★ 0#0 2020年7月13日 (一) 14:57 (UTC)(2020年7月15日 (三) 14:24 (UTC)添加下划线以强调)
- @KirkLU:对,我建议在签名一刀切禁止所有此类表达,以免再有人争拗“什么是观点”“这算不算政见”云云。这也符合维基百科讨论页不得讨论与维基百科无关事物的规则。 Classy Melissa (批判一番) 2020年7月13日 (一) 23:33 (UTC)
- 与维基百科是否有关如何定义?有些用户从去年开始就用香港的事情绑架维基算不算与维基有关?。->>Vocal&Guitar->>留言 2020年7月15日 (三) 00:26 (UTC)
- 这个规定本来就已经比较严格了,所以至于“与维基有关”可以宽松点,这个算是有关。或者就再进一步,只允许以用户名为主体,和少量装饰性的元素,其他全部禁止。 Classy Melissa (批判一番) 2020年7月15日 (三) 05:24 (UTC)
- 标准依然由嘴定而非文字定,(-)反对。->>Vocal&Guitar->>留言 2020年7月16日 (四) 02:57 (UTC)
- 这个规定本来就已经比较严格了,所以至于“与维基有关”可以宽松点,这个算是有关。或者就再进一步,只允许以用户名为主体,和少量装饰性的元素,其他全部禁止。 Classy Melissa (批判一番) 2020年7月15日 (三) 05:24 (UTC)
- (?)疑问:每年的10月1日都会有不少中国维基人在签名后加上“庆祝新中国成立XX周年🇨🇳”、“庆祝中华人民共和国成立XX周年”之类的字句,那请问他们的行为受到这次修订签名指引的约束吗?--CRHK128☎ “一国两制”寿终正寝 2020年7月15日 (三) 07:10 (UTC)
- 会的。这种签名很可能会冒犯其他不认同中华人民共和国的人,所以本身就不宜出现。 Classy Melissa (批判一番) 2020年7月15日 (三) 07:43 (UTC)
- 那挺好的,我(+)支持。--CRHK128☎ “一国两制”寿终正寝 2020年7月15日 (三) 09:40 (UTC)
- 个人认为是这样的:加入自己的政见是人之常情,每个人都有自己的政治立场。在观感而言,不同的政见都难免会冒犯相反政治立场的用户,这很难避免。我认为加入政治立场可不禁止,但必要时可作规范。例如我说句“支持国安法”又或者“反对国歌法”,我没有冒犯的对象,自然就不能算冒犯支持国歌法和反对国安法的人。假如我说句“共匪”、“黑警”,就冒犯了支持共产党和支持警察的人,就理应节制。但是如果和维基百科无关的都要禁止,就未必太苛刻了。譬如现在疫情严峻,我在签名说一句“祝肺炎退散”、“减少外出,坚守在家”,这反映的是对世界早日和平的寄望,如果禁止实在不近人情。再比如节日,我写个“圣诞快乐”或者“新年快乐”,禁止也太苛刻。我不反对立这个规例,但是我认为这个规例应该松弛有度及具有弹性,不应该全部禁止。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月15日 (三) 16:57 (UTC)
- 问题在于大家普遍不能把握这个度,不然我当初就不用这样提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:33 (UTC)
- 个人觉得如果一个人的签名(不论是长期或是多个签名)一直使相对立场的人感到冒犯,那就可以请求他删除相关冒犯内容。如果连些节日快乐,肺炎退散都禁止的话,那我反对订立这条规例。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月16日 (四) 03:55 (UTC)
- 那不如说这个规定“告诉乃论”。用户签名通常情况下不管,但若有人反对,就必须改掉。 Classy Melissa (批判一番) 2020年7月16日 (四) 04:28 (UTC)
- 支持相关做法。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月16日 (四) 07:04 (UTC)
- 那不如说这个规定“告诉乃论”。用户签名通常情况下不管,但若有人反对,就必须改掉。 Classy Melissa (批判一番) 2020年7月16日 (四) 04:28 (UTC)
- 个人觉得如果一个人的签名(不论是长期或是多个签名)一直使相对立场的人感到冒犯,那就可以请求他删除相关冒犯内容。如果连些节日快乐,肺炎退散都禁止的话,那我反对订立这条规例。--SickManWP欢迎参与边缘人小组的行动·减少外出,坚守在家!发表于 2020年7月16日 (四) 03:55 (UTC)
- 问题在于大家普遍不能把握这个度,不然我当初就不用这样提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:33 (UTC)
(-)反对(-)不支持这种宽松策略。我(+)支持严格禁止一切含有与维基百科编辑无关的内容的签名,我甚至(+)倾向支持签名应该只有用户名(或者不会引起歧义的昵称)以及与该用户相关的链接。一个原因虽然是有些人利用签名发表政见而引发部分人群的反感,但是主要原因是:讨论页应该只探讨与条目编辑、改善维基百科有关的内容,签名的作用是告知相关讨论是由谁写下的,方便对话追踪;写“圣诞快乐”、“端午快乐”等虽然不会引起反感,但是这些文句没有必要、也不应该出现在讨论页当中,出现了也不会帮助提升条目质量、改善维基百科,反而占用篇幅,分散想要提升条目质量、改善维基百科的讨论者的注意力;签名的影响效果比用户页大得多,虽然签名有长度限制,但是用户的每一条讨论都会留下签名,100条讨论就是100个签名,使得就算很短的签名的宣传效果也远超“大字报”用户页,这甚至能让签名变相违反“每个观点可以使用有限的文字简单地宣告一次”的WP:UPNOT。以上。gaosong2101 🏠 📫 📜 2020年7月16日 (四) 07:49 (UTC)
- 已阅。--Super Wang※DC不是贪食蛇,请勿盲目刷分 2020年7月16日 (四) 09:34 (UTC)
WP:CONCOVID-19和重定向页
有用户提议快速删除武汉肺炎病毒、武汉肺炎中国大陆疫情等重定向页。根据WP:R#POV,重定向页可使用不中立名称。因此提议:
|
|
--GZWDer(留言) 2020年7月22日 (三) 09:33 (UTC)
(!)意见:应该重定向到名称争议的相关条目。—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月22日 (三) 12:42 (UTC)- 没看仔细。武汉肺炎病毒可以重定向到SARS-CoV-2,但武汉肺炎中国大陆疫情私认为应该(×)删除。新冠可比照办理2019冠状病毒病—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月23日 (四) 14:10 (UTC)
- (-)反对:没有必要,重定向页根据WP:R#POV处理就行了,方针>共识,没必要在共识页重复提及。——BlackShadowG★(留言) 2020年7月23日 (四) 02:38 (UTC)
- 吐槽,感觉是变相禁武肺(毕竟很多用武肺的都有内链)--枫叶留·献·签 2020年7月23日 (四) 08:41 (UTC)
修改WP:R6
我看了一看现行条文,我认为现行条文有构成冗长辩论之嫌。我请求修改现行条文如下:
“ | 为了确保所有使用者有充足的时间发表意见以及得悉改动,在七天内没有不同意提案的新留言或至少讨论达一个月以上的情况下,只要取得共识便可公示,为期七天。存档后如果要重新提出公示的话,应同时补回相关讨论连结,以便社群查阅。公示期间如果有新意见,请通过协商解决问题。 | ” |
以上。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 10:53 (UTC)
- 通知当时参与讨论的人:@AT、蟲蟲飛、Shizhao、和平奮鬥救地球、@DrizzleD、方的1P、Ericliu1912、CaryCheng。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 10:53 (UTC)
- 就算同意提案,也可以提出更全面的意见,我认为没有问题。—AT2020年7月5日 (日) 11:12 (UTC)
- 同意AT意见,我也觉得应该让更多人看一下提案内容,没必要急于通过提案。--虫虫飞♡♡→♡℃※留言 2020年7月5日 (日) 11:35 (UTC)
- @AT:问题在于如果一个提案仅因一个简单支持意见而窒碍公示,这就很不合理。再者,即使相关支持或中立意见有提出进一步提议,通常在相关提议合理、可行的情况下,原始提案人会接纳相关提议,于是支持原提议的用户会再一次表达支持意见,这就会使公示的日期不必要且不合理地延后。另外,冗长辩论可被视为游戏规则,现行条文或有与既有指引冲突的情形。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 11:49 (UTC)
- 另外,这里我设例说明一下现行条文的不合理之处:设有两个提案,一个提案完全没人理会(完全没人发表意见),一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。现行条文下,前者在提出的7日后即可送公示,后者则只可在提出的1个月后公示。明显更多人支持的提案竟然要比没人理会的提案晚一大段时间公示,这合理吗?提案的出发点虽好,但可能适得其反。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 11:57 (UTC)
- “一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”您的见解是当有人不断表达意见(无论正反),反而会造成提案无法公示,导致适得其反,这一点我也是非常理解的。不过,从切入角度来看,我的见解正好与您相反,我认为这项条文可以减省不必要的发言(例如您所说的“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”,因为作为一个支持共识的用户,期望的当然就是尽快公示,因此他们在这项条文下就不会持续发表同调意见,这样反而能够让提案尽快达到公示阶段,反之如果有异议也可以专注应对。显然地,不同用户不断表述同一立场的意见只会造成洗板,是毫无意义,您的见解是从滥用角度出发,我的见解是从善用角度出发。反过来说,如果有人同意提案,但同时提出更好的意见,难道又继续公示原提案吗?我想不是。比较妥善的做法理应是在深入讨论后,再考虑是否公示新提案。一个新提案不一定等于反对原提案,可以是建基于原提案的改进版本。因此,虽然我能理解您的忧虑,但是以目前状态来说我认为维持原状是较佳的选择。—AT2020年7月5日 (日) 12:18 (UTC)
- 我不认为你的想法实际。“减省不必要的发言”是不可能的,因为根本不会有人会管这回事:只要他们觉得可以支持,他们就会来表达支持。这和WP:PM实际上没什么人使用,而且使用率无法改善的情况无甚差别。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 14:48 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 14:52 (UTC)
- 那我再说一点实际的话“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”显然地,从来没有这样的例子,因此您的推论并不成立。就算“因为根本不会有人会管这回事:只要他们觉得可以支持,他们就会来表达支持。”,那也不会去到“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”这样的地步。从吸纳意见和周知角度来看,讨论时间长要比短好得多。—AT2020年7月5日 (日) 15:39 (UTC)
- “从来都没有这样的例子”的原因正是此前未曾施行如此不人性化的提案,因此你的推论本身并不成立。我认为确保公示期足够长已可确保用户得以被知会讨论存在。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 23:27 (UTC)
- 所以,您所说的“人性化”有没有考虑到建基于原提案的改善意见或其他增补项目时的应对吗?我之所以倾向维持原文,一来是考虑到这个问题。其二是当如果真有用户通过不断支持来拖延讨论的话,那已经是属于扰乱或GAME的行为,当告知后仍然持续的话这已经不是“因为根本不会有人会管这回事:只要他们觉得可以支持,他们就会来表达支持”的问题。只要有效地执行这项规定,即可达至减省不必要的同调留言的效果(也正好就是您提出的避免冗长讨论),没有什么是不可能的。实际上无论条文成立前后,都没有人会通过不断支持来拖延讨论时间,现实是大多数讨论都会在一段时间后趋于平淡,因此我认为您的想法是过虑,如果真的出现,也有我上述提到的对应方法,没有任何问题。—AT2020年7月6日 (一) 08:42 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 11:47 (UTC)
- “我认为社群大部分人都不清楚分条文所带来的实际影响,而当他们知道的时候,他们肯定会对现行条文持有反对声音。”这纯粹是您的推测。这项新增条文前后后也花了约一个月的时间,当然最初不知道不成问题,我上面已经有提到告知的重要性(其他规定也是如此)。如果仍然有人不同意的话可以提出修订(就像您现在做的事一样),共识过了的话自然可以改,没有任何问题。其次,如果您可以将原提案和改进提案视为不同提案,而原提案可以继续公示的话,那同样可以实行分部通过,条文并没有禁止分部通过,如果您觉得不够清晰,可以就这一点提出修订。您所说的“拉布”问题,也就重回到我提及的违反扰乱和GAME的范畴里面,由于在这方面已经作出限制,如出现拉布情况在告知后仍然持续的话,可以通过封禁来阻止。况且,通过推测有人以不断支持来拉布,从而提出修订,其实也没什么意思,因为不断反对也可以达到同样的效果,无论在这项条文成立之前还是之后,亦或改成您的版本,这个问题也不会消失,并且同样能够以封禁来处理。—AT2020年7月6日 (一) 12:18 (UTC)
- 是推测,不过是合理推测,不信你可以实验一下。另外,我认为在现行条文下,即使允许分部通过,新增的意见会同时影响各分部的公示开始日期,使分部通过变得毫无意义。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 13:52 (UTC)
- 那如我上述所言,您可以针对分部通过的问题提出修改。—AT2020年7月6日 (一) 14:17 (UTC)
- 但这系列问题是连锁的,我没能力分开,所以我在这里提出了这个修改。这就是无限循环。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:29 (UTC)
- 您的立论从一开始就是一个推测,我亦已经提出解决方案,您就当成是实验,稍为观望一下效果如何再决定也不晚?—AT2020年7月6日 (一) 15:19 (UTC)
- 问题在于你的所谓“解决方案”造成了无限循环,所以并不能解决任何事情。我不可能冒着被封的风险来“实验”,这是游戏规则。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 09:57 (UTC)
- 您的立论从一开始就是一个推测,我亦已经提出解决方案,您就当成是实验,稍为观望一下效果如何再决定也不晚?—AT2020年7月6日 (一) 15:19 (UTC)
- 但这系列问题是连锁的,我没能力分开,所以我在这里提出了这个修改。这就是无限循环。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:29 (UTC)
- 那如我上述所言,您可以针对分部通过的问题提出修改。—AT2020年7月6日 (一) 14:17 (UTC)
- 是推测,不过是合理推测,不信你可以实验一下。另外,我认为在现行条文下,即使允许分部通过,新增的意见会同时影响各分部的公示开始日期,使分部通过变得毫无意义。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 13:52 (UTC)
首先,在新条文有如此效果,而大家都未曾清楚新条文的实际含意时,如果我拿新条文来请“只要他们觉得可以支持,他们就会来表达支持”的人不要来支持的话,他们肯定认为我在扰乱,然后把我提报;你的“对应方法”于我而言其实是一个陷阱。(换言之,我认为社群大部分人都不清楚分条文所带来的实际影响,而当他们知道的时候,他们肯定会对现行条文持有反对声音。)“建基于原提案的改善意见或其他增补项目时的应对”和原有提案可视为不同的提案,如果原提案人有理由认为“建基于原提案的改善意见或其他增补项目时的应对”有需要进一步讨论(以至不可行)的地方,照样公示原有提案,但维持对“建基于原提案的改善意见或其他增补项目时的应对”的讨论(使之可另行公示通过)是一个办法,否则部分(因各种因素而变得)冗长的讨论很可能持续几个月也不能结案。(换言之,我认为现有条文窒碍了分部通过的可能性。)当然,如果原提案人认为“建基于原提案的改善意见或其他增补项目时的应对”所提出的意见合理,他肯定会修改自己的提案,并预留多一些的时间供讨论。“通过不断支持来拖延讨论时间”在现行条文通过前是不可能发生的,因为并没有那个不人性化的规定,这反而会令公示的日期变得更早。然而,这可能会成为以后拉布的一种策略。我认为现行条文的副作用远大于作用。 - “我认为社群大部分人都不清楚分条文所带来的实际影响,而当他们知道的时候,他们肯定会对现行条文持有反对声音。”这纯粹是您的推测。这项新增条文前后后也花了约一个月的时间,当然最初不知道不成问题,我上面已经有提到告知的重要性(其他规定也是如此)。如果仍然有人不同意的话可以提出修订(就像您现在做的事一样),共识过了的话自然可以改,没有任何问题。其次,如果您可以将原提案和改进提案视为不同提案,而原提案可以继续公示的话,那同样可以实行分部通过,条文并没有禁止分部通过,如果您觉得不够清晰,可以就这一点提出修订。您所说的“拉布”问题,也就重回到我提及的违反扰乱和GAME的范畴里面,由于在这方面已经作出限制,如出现拉布情况在告知后仍然持续的话,可以通过封禁来阻止。况且,通过推测有人以不断支持来拉布,从而提出修订,其实也没什么意思,因为不断反对也可以达到同样的效果,无论在这项条文成立之前还是之后,亦或改成您的版本,这个问题也不会消失,并且同样能够以封禁来处理。—AT2020年7月6日 (一) 12:18 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 11:47 (UTC)
- 所以,您所说的“人性化”有没有考虑到建基于原提案的改善意见或其他增补项目时的应对吗?我之所以倾向维持原文,一来是考虑到这个问题。其二是当如果真有用户通过不断支持来拖延讨论的话,那已经是属于扰乱或GAME的行为,当告知后仍然持续的话这已经不是“因为根本不会有人会管这回事:只要他们觉得可以支持,他们就会来表达支持”的问题。只要有效地执行这项规定,即可达至减省不必要的同调留言的效果(也正好就是您提出的避免冗长讨论),没有什么是不可能的。实际上无论条文成立前后,都没有人会通过不断支持来拖延讨论时间,现实是大多数讨论都会在一段时间后趋于平淡,因此我认为您的想法是过虑,如果真的出现,也有我上述提到的对应方法,没有任何问题。—AT2020年7月6日 (一) 08:42 (UTC)
- “从来都没有这样的例子”的原因正是此前未曾施行如此不人性化的提案,因此你的推论本身并不成立。我认为确保公示期足够长已可确保用户得以被知会讨论存在。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 23:27 (UTC)
或许我这样说:我不认为社群要重复一次失败的经历。基本上但凡是不人性化的提案,最终都会失败,而且为社群造成不必要的阻碍。 - 那我再说一点实际的话“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”显然地,从来没有这样的例子,因此您的推论并不成立。就算“因为根本不会有人会管这回事:只要他们觉得可以支持,他们就会来表达支持。”,那也不会去到“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”这样的地步。从吸纳意见和周知角度来看,讨论时间长要比短好得多。—AT2020年7月5日 (日) 15:39 (UTC)
- “一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”您的见解是当有人不断表达意见(无论正反),反而会造成提案无法公示,导致适得其反,这一点我也是非常理解的。不过,从切入角度来看,我的见解正好与您相反,我认为这项条文可以减省不必要的发言(例如您所说的“一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。”,因为作为一个支持共识的用户,期望的当然就是尽快公示,因此他们在这项条文下就不会持续发表同调意见,这样反而能够让提案尽快达到公示阶段,反之如果有异议也可以专注应对。显然地,不同用户不断表述同一立场的意见只会造成洗板,是毫无意义,您的见解是从滥用角度出发,我的见解是从善用角度出发。反过来说,如果有人同意提案,但同时提出更好的意见,难道又继续公示原提案吗?我想不是。比较妥善的做法理应是在深入讨论后,再考虑是否公示新提案。一个新提案不一定等于反对原提案,可以是建基于原提案的改进版本。因此,虽然我能理解您的忧虑,但是以目前状态来说我认为维持原状是较佳的选择。—AT2020年7月5日 (日) 12:18 (UTC)
- 另外,这里我设例说明一下现行条文的不合理之处:设有两个提案,一个提案完全没人理会(完全没人发表意见),一个提案则持续1个月有大量人表示支持,每日不间断,且无反对意见。现行条文下,前者在提出的7日后即可送公示,后者则只可在提出的1个月后公示。明显更多人支持的提案竟然要比没人理会的提案晚一大段时间公示,这合理吗?提案的出发点虽好,但可能适得其反。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 11:57 (UTC)
- 没有理由要等七天无讨论。要的是"讨论经历一段时间,都同意目前的方案。"这就是人为制造行政阻碍了。--Temp3600(留言) 2020年7月5日 (日) 15:03 (UTC)
- 不要期望所有用户每天都上维基,有时第六天就出现很多反对意见。例如AFD,即使有十票删除,也不能速删,等七天,这七天很重要,因为要好好收集意见,有些人忙,可以第七天才出来表达意见,因此我看不到有什么理据急于公示。--虫虫飞♡♡→♡℃※留言 2020年7月5日 (日) 15:18 (UTC)
- 我怎能阻止其他用户在公示期发表意见?如果每隔数日就有人来投票支持,那公示期不就无限延长?--Temp3600(留言) 2020年7月6日 (一) 12:34 (UTC)
- 哦,我有点明白了。你的意思应该是指"讨论至少要有一个月",只有特殊情况(有共识并无更多意见)才可以走快捷程序?--Temp3600(留言) 2020年7月6日 (一) 12:37 (UTC)
- 也可以这样说吧,这就像afd,如果持续有新留言,五周后才可以“无共识”结案;如果争议不下的最后留言七天内没新意见,也可以“无共识”结案。后者可以是14天,前者由于持续不断留言,所以是35天;相反,共识非常明显的,afd提删后讨论七天就结案。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 12:52 (UTC)
- 那先看看如何吧。虽然我有预感现行制度很难走下去。--Temp3600(留言) 2020年7月7日 (二) 07:28 (UTC)
- 同上。我认为这个规定很快就会名存实亡,如果有人提议严格执行规定的话,那样规定最后就会直接被废除。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 09:57 (UTC)
- 那先看看如何吧。虽然我有预感现行制度很难走下去。--Temp3600(留言) 2020年7月7日 (二) 07:28 (UTC)
- 也可以这样说吧,这就像afd,如果持续有新留言,五周后才可以“无共识”结案;如果争议不下的最后留言七天内没新意见,也可以“无共识”结案。后者可以是14天,前者由于持续不断留言,所以是35天;相反,共识非常明显的,afd提删后讨论七天就结案。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 12:52 (UTC)
- 这个问题在先前的讨论已经多次提到过。请参阅相关讨论的同时,搜索“周知”二字。谢谢。—AT2020年7月5日 (日) 15:39 (UTC)
- 不同意但尊重您的立法原意。那就先看看成效吧。--Temp3600(留言) 2020年7月7日 (二) 07:28 (UTC)
- 我正考虑使用IAR处理此提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月5日 (日) 23:35 (UTC)
- (=)中立:新旧版本条文看起来没有明显差异,我没有意见。--CaryCheng(留言) 2020年7月6日 (一) 04:34 (UTC)
- 另外,我质疑现行条文会构成无限循环,并窒碍IAR的正当运行。根据Wikipedia:何谓忽略所有规则#图表,如果一个用户有一个特定想法,但有违现行公示规则,原因是现行公示规则出现问题(规则错了)。图表会指示该用户改变规则,但改变规则本来就需要公示,这就如同回到原点。上方已经有人问我何时公示一个获广泛同意的提案,我就向他说明了现行公示规则,我不知道如果他就此有很大反应的话,我该如何回应他,因为我和他都陷入了循环。我可能因此需要不依图表运行IAR。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 11:59 (UTC)
- (※)注意:WP:IAR重点是有规则“妨碍”您“维护”维基百科,事实上绝大多数情况下是没有规则“妨碍”您“维护”维基百科。适用的例子很少,如管理员g8“删除以便移动”,这“删除”是没有提删的;管理员“大量删除”破坏者的g3页面,也是没有提删的;管理员g8删去解封后的全保护用户页,也是没有提删的等,这些是属于特殊情况,并非用户可以滥用IAR去违规。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 13:09 (UTC)
- 妨碍共识的执行也属于妨碍维护。我提到“上方已经有人问我何时公示一个获广泛同意的提案”其中的那个提案正是这样的情况。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 13:52 (UTC)
- 如果提案是确实有共识的,也不怕多放几天,七天很快就过去了,重大的提案更应该让更多人了解,没必要急于公示。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 13:58 (UTC)
- “七天很快就过去了”,问题在于现时的规定令提案实质上待在客栈的时间远不只七天,使必要的修改被延误实施,造成维护漏洞。有些措施是有即时性的,请理解。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:01 (UTC)
- 请您参看之前的讨论,这个问题已经有提及到,这是考虑到周知时间的问题。因此在特发情况下,管理员仍然可以通过IAR来作出即时应对。然而,跟紧急提案相比,由于非紧急提案占了绝大部分,因此条文的焦点放于非紧急提案上,紧急提案则交由IAR来处理就好。—AT2020年7月6日 (一) 14:17 (UTC)
- 问题在于社群内部有一定数量的用户把紧急提案当成不紧急提案一样处理,并因此反对应用IAR。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:32 (UTC)
- 请您参看之前的讨论,这个问题已经有提及到,这是考虑到周知时间的问题。因此在特发情况下,管理员仍然可以通过IAR来作出即时应对。然而,跟紧急提案相比,由于非紧急提案占了绝大部分,因此条文的焦点放于非紧急提案上,紧急提案则交由IAR来处理就好。—AT2020年7月6日 (一) 14:17 (UTC)
- “七天很快就过去了”,问题在于现时的规定令提案实质上待在客栈的时间远不只七天,使必要的修改被延误实施,造成维护漏洞。有些措施是有即时性的,请理解。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:01 (UTC)
- 如果提案是确实有共识的,也不怕多放几天,七天很快就过去了,重大的提案更应该让更多人了解,没必要急于公示。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 13:58 (UTC)
- 妨碍共识的执行也属于妨碍维护。我提到“上方已经有人问我何时公示一个获广泛同意的提案”其中的那个提案正是这样的情况。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 13:52 (UTC)
- (※)注意:WP:IAR重点是有规则“妨碍”您“维护”维基百科,事实上绝大多数情况下是没有规则“妨碍”您“维护”维基百科。适用的例子很少,如管理员g8“删除以便移动”,这“删除”是没有提删的;管理员“大量删除”破坏者的g3页面,也是没有提删的;管理员g8删去解封后的全保护用户页,也是没有提删的等,这些是属于特殊情况,并非用户可以滥用IAR去违规。--虫虫飞♡♡→♡℃※留言 2020年7月6日 (一) 13:09 (UTC)
- 另外,一个提案完全没人理会(完全没人发表意见),但在现行条文下,该提案在提出的7日后即可送公示这样的情况也是有问题的。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:03 (UTC)
- 两周没人发言是条文问题还是用户问题?显然易见。—AT2020年7月6日 (一) 14:17 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:24 (UTC)
- 的确如此。 DRIZZLE (按此给我留言) 2020年7月6日 (一) 15:15 (UTC)
- 所以没人发表意见是用户问题还是条文问题?区别冷门与否有何意义?—AT2020年7月6日 (一) 15:19 (UTC)
- 两者都有可能,所以你这个问题其实是没有既定的答案的,不然我也不会不回应你的问题。区别提案冷门与否的意义在于判别提案是否有共识支持,冷门提案既然无人支持,那就代表提案没有共识支持,但现行条文却把没有共识支持的提案和有共识支持的提案混为一谈。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 09:57 (UTC)
我认为你所提议的现行条文有鼓励将完全没人理会(完全没人发表意见)的提案送交公示的副作用。另外,假设你的“减省不必要的发言”思维真的能够实行(我认为这样反人性化的思维是不能够实行的),这就会令社群无法区别冷门提案和获得广泛支持的提案。
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:24 (UTC)
- 两周没人发言是条文问题还是用户问题?显然易见。—AT2020年7月6日 (一) 14:17 (UTC)
- 另外,我想解释一下公示期的作用:公示期是提案正式施行前的一段缓冲期,予用户足够时间获知提案存在,并采取进一步的行动(如有需要)。现行条文很明显无视了公示期的这一个作用,使间隔变得不必要地长,并且有扭曲讨论生态之嫌。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:07 (UTC)
- “现行条文很明显无视了公示期的这一个作用,使间隔变得不必要地长,并且有扭曲讨论生态之嫌。”无法认同。考虑到讨论时间以及周知时间,我认为一个月是一个妥当的标准,是有必要的。还是,您想重回仓卒讨论突然公示的荒诞时期?—AT2020年7月6日 (一) 14:21 (UTC)
- 我认为你将之前的情况称为“荒诞时期”过分夸张,相关情况只是很个别的例子,其实是应该个别处理的。我认为你当初提案的动作属反应过大,我一直以来也不认同你的提案。公示期才是真正应该带来周知时间作用的时间间隔,如果要像现在这样做的话,倒不如直接废除公示期。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:27 (UTC)
- 既然您不认同条文,您的修订本身也没有意义,我亦继续(-)反对。谢谢。—AT2020年7月6日 (一) 15:19 (UTC)
- 我不认同现行条文不代表提议修订没有意义。如果提议修订获得通过,我会认同那时候的条文。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:00 (UTC)
- 既然您不认同条文,您的修订本身也没有意义,我亦继续(-)反对。谢谢。—AT2020年7月6日 (一) 15:19 (UTC)
- 我认为你将之前的情况称为“荒诞时期”过分夸张,相关情况只是很个别的例子,其实是应该个别处理的。我认为你当初提案的动作属反应过大,我一直以来也不认同你的提案。公示期才是真正应该带来周知时间作用的时间间隔,如果要像现在这样做的话,倒不如直接废除公示期。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月6日 (一) 14:27 (UTC)
- “现行条文很明显无视了公示期的这一个作用,使间隔变得不必要地长,并且有扭曲讨论生态之嫌。”无法认同。考虑到讨论时间以及周知时间,我认为一个月是一个妥当的标准,是有必要的。还是,您想重回仓卒讨论突然公示的荒诞时期?—AT2020年7月6日 (一) 14:21 (UTC)
- (!)意见:是否可以折中一下,改成“七天内没有带有其他意见的新留言”。此方案只排除单纯支持、给出理据支持和单纯疑问的情况,而如果出现虽同意提案但仍有改进意见的留言,仍需要等待7天。--DRIZZLE (按此给我留言) 2020年7月6日 (一) 15:20 (UTC)
- 这个我支持。—AT2020年7月6日 (一) 15:23 (UTC)
- 这个更好点。--Роу Уилсон Фредериск Холм(留言) 2020年7月6日 (一) 22:56 (UTC)
- 这可以。—— Eric Liu 创造は生命(留言.留名.学生会) 2020年7月7日 (二) 00:07 (UTC)
- 大致支持,但想问一下单纯反对(不附任何理由或反建议)的意见是否仍可造成重算七日?(这个问题的答案不会影响我的支持意见)ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月7日 (二) 05:20 (UTC)
- 个人认为需要,因为这种意见一般也是需要讨论的,凡是需要讨论的意见都应该充分讨论以保证共识,从而需要等待7天。但反对者应该在这7天内给出恰当的理由。 DRIZZLE (按此给我留言) 2020年7月7日 (二) 05:46 (UTC)
- 悉。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月7日 (二) 05:48 (UTC)
- ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:06 (UTC)
- @Sanmosa:我认为“非扰乱性”不必要加,交给WP:GAME处理就好了。至于后者,条文改成“七天内没有新留言对提案的主题表达支持并非包含于提案本身中的想法的意见”如何? DRIZZLE (按此给我留言) 2020年7月10日 (五) 12:33 (UTC)
- 我认为言明“非扰乱性”比不言明好,其他方针指引好像也是如此处理的。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 13:49 (UTC)
- 个人觉得没必要,加上我也不反对。 DRIZZLE (按此给我留言) 2020年7月11日 (六) 13:03 (UTC)
- 我认为言明“非扰乱性”比不言明好,其他方针指引好像也是如此处理的。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 13:49 (UTC)
有一个新意见:应该要说明是“非扰乱性、非离题的”新留言。 - @Sanmosa:我认为“非扰乱性”不必要加,交给WP:GAME处理就好了。至于后者,条文改成“七天内没有新留言对提案的主题表达支持并非包含于提案本身中的想法的意见”如何? DRIZZLE (按此给我留言) 2020年7月10日 (五) 12:33 (UTC)
- 个人认为需要,因为这种意见一般也是需要讨论的,凡是需要讨论的意见都应该充分讨论以保证共识,从而需要等待7天。但反对者应该在这7天内给出恰当的理由。 DRIZZLE (按此给我留言) 2020年7月7日 (二) 05:46 (UTC)
- (+)支持,在公示期支持共识或者单单疑问不构成对共识本身的否定,不应重新计算公示期。但也要防止有人在公示期间不断提出反对进行POINT以致讨论无限延长的情况,所以应该对反对共识作出一定依据的规定,这和DYK之类的投票也是一样。~ƒ(方)^ρ~ 2020年7月7日 (二) 07:16 (UTC)
- (!)意见:我觉得U:AT版的现行条文较佳,DRIZZLE版较多争议性,究竟哪些情况适用?哪些情不适用?实际操作上较多争议。例如怎样的意见才是“新意见”?有些提案就是正反两面,理据都是那些,然后社群就可能因定义是否“新意见”而再添争议,这是不必要。--虫虫飞♡♡→♡℃※留言 2020年7月9日 (四) 12:13 (UTC)
- @蟲蟲飛:
此方案只排除单纯支持、给出理据支持和单纯疑问的情况,
任何反对意见都属于“其他意见”(即与提案不同的意见)。 DRIZZLE (按此给我留言) 2020年7月9日 (四) 13:09 (UTC)- 您的条文具体如何写?因为往后用户是看条文实际写了什么然后去实践。--虫虫飞♡♡→♡℃※留言 2020年7月9日 (四) 13:32 (UTC)
- “七天内没有带有支持提案本身以外的意见的新留言”如何?如果实在是还不清楚就再加一句注,“含单纯支持、给出理据支持和单纯疑问的情况,不含同意提案但仍有改进意见的留言等”。 DRIZZLE (按此给我留言) 2020年7月9日 (四) 14:02 (UTC)
- (:)回应:“七天内没有带有支持提案本身以外的意见的新留言”这样较佳,但我还是觉得AT版现行条文更佳,“七天没有新留言”一目了然,豪无争议。而且刚通过的提案,又未见在实践上发生什么问题,马上又走来改,这是“朝令夕改”,我觉得没必要。--虫虫飞♡♡→♡℃※留言 2020年7月9日 (四) 14:08 (UTC)
- 你似乎不把Temp3600当成人。Temp3600也是反对现行条文的人,条文没可能没有争议。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 09:42 (UTC)
- 而且,要说“朝令夕改”的话,开先例的是AT。根据这个例子,只要相关修订有必要,即使有可能存在“朝令夕改”的问题,也不代表不能改(也就是说,“朝令夕改”不代表没有修改的必要)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 10:04 (UTC)
- (:)回应:您提到的例子是得到您的同意,才撤回已通过的提案,原则上您可以不同意,然后他要按既定程序去推番已通过的提案。Temp3600并没有指出现行条文的问题。我觉得是由于AT的“一个月”的这用语吓怕了用户,其实简单来说就是“最后留言七天后”建议修订条文如下。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 12:47 (UTC)
- 注意:我并未有“撤回”已通过的提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 13:44 (UTC)
- (:)回应:您提到的例子是得到您的同意,才撤回已通过的提案,原则上您可以不同意,然后他要按既定程序去推番已通过的提案。Temp3600并没有指出现行条文的问题。我觉得是由于AT的“一个月”的这用语吓怕了用户,其实简单来说就是“最后留言七天后”建议修订条文如下。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 12:47 (UTC)
- (:)回应:“七天内没有带有支持提案本身以外的意见的新留言”这样较佳,但我还是觉得AT版现行条文更佳,“七天没有新留言”一目了然,豪无争议。而且刚通过的提案,又未见在实践上发生什么问题,马上又走来改,这是“朝令夕改”,我觉得没必要。--虫虫飞♡♡→♡℃※留言 2020年7月9日 (四) 14:08 (UTC)
- 您的条文具体如何写?因为往后用户是看条文实际写了什么然后去实践。--虫虫飞♡♡→♡℃※留言 2020年7月9日 (四) 13:32 (UTC)
- @蟲蟲飛:
- (-)反对,个人认为经过讨论时间后再进行公示较好。--奈威空白键 2020年7月10日 (五) 13:35 (UTC)
- 问题在于讨论时间不能每次都拖到一个月,有些事讨论一两个星期其实就可以公示了。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 13:44 (UTC)
修订二
|
- (-)反对:原文是“或”,删去“一个月”反而进一步收紧了标准,而不是相反。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:04 (UTC)
- (?)疑问:提案要求讨论七天才公示,也合理?您想一提案就公示?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:07 (UTC)
- (?)疑问@蟲蟲飛:我哪里说过想一提案就公示? DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:17 (UTC)
- 那您希望多少天讨论才公示?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:18 (UTC)
七天内没有新留言
→ “七天内没有新留言对提案的主题表达支持并非包含于提案本身中的想法的意见”,其他部分不动。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:28 (UTC)- 您的修订版就是太复杂,对条文的解读也较容易存在歧义,在实践上不容易。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:33 (UTC)
- 讲起来是有些复杂,简单来说就是,不可能影响共识形成的不算,使用常识。再次说明,此提案不影响虽同意提案但仍有其他意见的留言的情形,这种情况可能会影响到最终共识,因此仍然要以此计算7日。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:40 (UTC)
- 我这样听起来已经很复杂,何不简单地“七天没新留言”就公示?太多情景,太多附加条件,到最后就是社群很难自觉地依从,或者在公示前要先看一下您的“定义”和“情景”,这样就不好实践。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:45 (UTC)
- 现实是复杂的,如果要尽量适用现实情况并消除条文歧义,就必须把条文写复杂。复杂不是要一刀切的理由。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 14:17 (UTC)
- 我这样听起来已经很复杂,何不简单地“七天没新留言”就公示?太多情景,太多附加条件,到最后就是社群很难自觉地依从,或者在公示前要先看一下您的“定义”和“情景”,这样就不好实践。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:45 (UTC)
- 讲起来是有些复杂,简单来说就是,不可能影响共识形成的不算,使用常识。再次说明,此提案不影响虽同意提案但仍有其他意见的留言的情形,这种情况可能会影响到最终共识,因此仍然要以此计算7日。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:40 (UTC)
- 您的修订版就是太复杂,对条文的解读也较容易存在歧义,在实践上不容易。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:33 (UTC)
- 那您希望多少天讨论才公示?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:18 (UTC)
- (?)疑问@蟲蟲飛:我哪里说过想一提案就公示? DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:17 (UTC)
- (?)疑问:提案要求讨论七天才公示,也合理?您想一提案就公示?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:07 (UTC)
- (※)注意:讨论必须酝酿足够共识后才公示,而提案也须要“周知”,就是有些人虽然没有参与讨论,也应该有足够的时间让足够的用户去了解提案,因此七天是一个合理时间,也是维基的讨论惯例。就如afd,即使十票删除,完全没有保留票,条目也不应速删,而应该七天后才删去。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:24 (UTC)
- 对提案的主题表达支持包含于提案本身中的想法的意见是有利于共识形成的,没有理由单纯支持提案还要延长时间。让没参与讨论的人了解提案是公示期的工作。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:32 (UTC)
- “七天有没有留言”是一个客观的标准,没有争议;您的就存在不同的解读空间,容易起争议。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:36 (UTC)
- 我认为你是惟一会认为存在“不同的解读”的人。另外,我认为提案的用字已足够使一般用户理解。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 13:41 (UTC)
- 有争议是正常的。举个例子,如果法律规定杀人者一律死缓,那就减少很多争议,然而,实际上规定的是一个判刑范围。是不是因为给判刑范围容易起争议就不应该这样做呢?不是,因为有时候适当减刑是合理的。同样,单纯支持提案不用延长讨论时间是合理的,因此不能仅仅因为会有争议就不这么做。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:47 (UTC)
- 也没必要急于公示吧?七天内有意见,大家讨论一下,然后再公示,有什么问题?AT原先的提案就是要解决讨论几天就急于公示的的问题。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:55 (UTC)
- 这不代表就要连带拖累其他提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月10日 (五) 14:01 (UTC)
- 有例子吗?现在就提案太多,很多方针刚通过,就有人来提案修改方针,例如这个提案。我完全未看到有什么提案是非常紧急,都是一想到改,就走来改。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 14:34 (UTC)
- 新提案在任何情况下都并不会带来7日之内公示的结果。我怀疑阁下可能理解有些偏差。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 14:14 (UTC)
- 我没有说“7日之内公示”,可能话说得不清楚,我再解释一下:有意见,就讨论一下,酝酿足够共识后,公示七天。这样可以吗?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 14:25 (UTC)
- 我完全同意“有意见,就讨论一下,酝酿足够共识后,公示七天”,但是,如果新留言没有额外意见,不会影响共识,为什么还要多等七天呢?单纯支持导致提案公示期推迟并不合理。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 15:37 (UTC)
- @DrizzleD:已根据您意见修改了,请审阅。我觉得方针指引不能太复杂,越明确,越精简,越容易为社群所自觉地遵守。--虫虫飞♡♡→♡℃※留言 2020年7月11日 (六) 01:57 (UTC)
- 明确支持仍然可能会有其他意见,这种情况依然应该推迟公示期以便更充分讨论。 DRIZZLE (按此给我留言) 2020年7月11日 (六) 05:20 (UTC)
- @DrizzleD:已根据您意见修改了,请审阅。--虫虫飞♡♡→♡℃※留言 2020年7月11日 (六) 05:27 (UTC)
- @蟲蟲飛:做了点小修订,您看如何。--DRIZZLE (按此给我留言) 2020年7月14日 (二) 02:22 (UTC)
- @DrizzleD:(✓)同意,感谢帮忙修订﹗--虫虫飞♡♡→♡℃※留言 2020年7月14日 (二) 08:18 (UTC)
- @蟲蟲飛:同U:Sanmosa意见,还应该补回“或至少讨论达一个月以上”。 DRIZZLE (按此给我留言) 2020年7月17日 (五) 09:01 (UTC)
- 我觉得这样不如不改,因为和AT现行版本差别不大,而且我觉得AT现行版更好,没必要“为改而改”,而且AT才通过没多久,在现行条文没出现问题时,不宜“朝令夕改”,更不宜“为改而改”。--虫虫飞♡♡→♡℃※留言 2020年7月17日 (五) 09:40 (UTC)
- 你(和AT)只不过是选择性无视和回避问题而已,根本没考虑到实际可行性。或许我说白一些:这个条文本身就是一个问题。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月19日 (日) 05:55 (UTC)
- “选择性无视和回避问题”[来源请求]由始至终,提案人都未具体说明现行条文发生了什么问题,现行条文就是“七天没留言”就可以公示,不明白有什么问题?--虫虫飞♡♡→♡℃※留言 2020年7月20日 (一) 13:39 (UTC)
- 我究竟重复多少次了:“七天没留言”是近乎没可能做到的状态,除非是冷门提案,但冷门提案本来就不应该予以公示。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月25日 (六) 02:29 (UTC)
- “选择性无视和回避问题”[来源请求]由始至终,提案人都未具体说明现行条文发生了什么问题,现行条文就是“七天没留言”就可以公示,不明白有什么问题?--虫虫飞♡♡→♡℃※留言 2020年7月20日 (一) 13:39 (UTC)
- 你(和AT)只不过是选择性无视和回避问题而已,根本没考虑到实际可行性。或许我说白一些:这个条文本身就是一个问题。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月19日 (日) 05:55 (UTC)
- @DrizzleD:(✓)同意,感谢帮忙修订﹗--虫虫飞♡♡→♡℃※留言 2020年7月14日 (二) 08:18 (UTC)
- @蟲蟲飛:做了点小修订,您看如何。--DRIZZLE (按此给我留言) 2020年7月14日 (二) 02:22 (UTC)
- @DrizzleD:已根据您意见修改了,请审阅。--虫虫飞♡♡→♡℃※留言 2020年7月11日 (六) 05:27 (UTC)
- 明确支持仍然可能会有其他意见,这种情况依然应该推迟公示期以便更充分讨论。 DRIZZLE (按此给我留言) 2020年7月11日 (六) 05:20 (UTC)
- @DrizzleD:已根据您意见修改了,请审阅。我觉得方针指引不能太复杂,越明确,越精简,越容易为社群所自觉地遵守。--虫虫飞♡♡→♡℃※留言 2020年7月11日 (六) 01:57 (UTC)
- 我完全同意“有意见,就讨论一下,酝酿足够共识后,公示七天”,但是,如果新留言没有额外意见,不会影响共识,为什么还要多等七天呢?单纯支持导致提案公示期推迟并不合理。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 15:37 (UTC)
- 我没有说“7日之内公示”,可能话说得不清楚,我再解释一下:有意见,就讨论一下,酝酿足够共识后,公示七天。这样可以吗?--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 14:25 (UTC)
- 也没必要急于公示吧?七天内有意见,大家讨论一下,然后再公示,有什么问题?AT原先的提案就是要解决讨论几天就急于公示的的问题。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:55 (UTC)
- “七天有没有留言”是一个客观的标准,没有争议;您的就存在不同的解读空间,容易起争议。--虫虫飞♡♡→♡℃※留言 2020年7月10日 (五) 13:36 (UTC)
- 对提案的主题表达支持包含于提案本身中的想法的意见是有利于共识形成的,没有理由单纯支持提案还要延长时间。让没参与讨论的人了解提案是公示期的工作。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:32 (UTC)
- (-)反对:原文是“或”,删去“一个月”反而进一步收紧了标准,而不是相反。 DRIZZLE (按此给我留言) 2020年7月10日 (五) 13:04 (UTC)
- (+)支持。--风云北洋※Talk 欢迎参与第十八次动员令 2020年7月11日 (六) 02:39 (UTC)
(-)反对,除非补回不受重算影响的大期限。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:21 (UTC)- 已在拟议条文补回不受重算影响的大期限,但由于“一个月”的长度并不稳定(28日至31日),另加入对“一个月”的长度的定义(定义为28日)。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月19日 (日) 05:52 (UTC)
- (+)支持:如果有新的建设性意见 是可以七天之后再七天然后充分讨论,但也不能一直延长下去 30天就是兜底的存在。如果我没理解错的话。dot(留言) 2020年7月20日 (一) 04:49 (UTC)
- (▲)同上:我也觉得一个月一般的看法是30天,依惯例修正及精简注脚。--虫虫飞♡♡→♡℃※留言 2020年7月20日 (一) 13:36 (UTC)
- (-)反对:“一个月”本未定义,如果要这样改来改去,倒不如重新讨论“一个月”的定义。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 02:42 (UTC)
我有另一个想法
我认为原条文大体可以不变,但期限应该由1个月改为14日。1个月的时长本来就不固定,而且也过长,周知用1个月已经是浪费时间,而且也低估了维基百科用户接收资讯的能力。如果这个意见获得接纳,我认为容许简单支持意见造成重算七日是可以接受的。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月12日 (日) 02:32 (UTC)
- 您意思是现行条文只改三十天为十四天,全部维持不变?虫虫飞♡♡→♡℃※留言 2020年7月13日 (一) 11:21 (UTC)
- (-)倾向反对:在有有效意见的情况下,让讨论更充分一点不坏。 DRIZZLE (按此给我留言) 2020年7月14日 (二) 02:17 (UTC)
- 我不认为提案人在七日内没能力处理一个有效的意见。再者,14日已经是一个充分的时间长度,以往能讨论多于一个月的提案都是非常复杂的提案,一般提案并不需要这么长的时间。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月14日 (二) 05:29 (UTC)
- 这和七日没关系啊,这个日期仅应用于不断有新意见的情况,如果花3日就达成共识,无其他意见,那无论何版本都只需10天就可公示。--DRIZZLE (按此给我留言) 2020年7月14日 (二) 08:22 (UTC)
- 问题在于我这一版没有排除无效留言(也就是说:无效留言在我这一版能导致重算)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:19 (UTC)
- 同意User:DrizzleD君的看法,如果删去“14天”这一项,我会支持。--虫虫飞♡♡→♡℃※留言 2020年7月16日 (四) 13:18 (UTC)
- 问题在于我这一版没有排除无效留言(也就是说:无效留言在我这一版能导致重算)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:19 (UTC)
- 这和七日没关系啊,这个日期仅应用于不断有新意见的情况,如果花3日就达成共识,无其他意见,那无论何版本都只需10天就可公示。--DRIZZLE (按此给我留言) 2020年7月14日 (二) 08:22 (UTC)
- 我不认为提案人在七日内没能力处理一个有效的意见。再者,14日已经是一个充分的时间长度,以往能讨论多于一个月的提案都是非常复杂的提案,一般提案并不需要这么长的时间。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月14日 (二) 05:29 (UTC)
- 我的意思是:AT订的条文不切实际,不可能有效运作(名存实亡),也会助长冗长讨论、游戏规则和无视其他方针的行径。如果要令条文有效运作,只有不容许无效留言导致重算或缩短大限期才能做到这点。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月19日 (日) 05:48 (UTC)
- AT现行条文就是七天没有留言,就可以公示,未见有何问题;冗长讨论,所反映的是提案“充满争议”,反对声音此起彼落,这种情况更加不应硬通过,或者硬公示,应通过讨论达成共识,未见有什么问题。--虫虫飞♡♡→♡℃※留言 2020年7月20日 (一) 13:31 (UTC)
- 你的理解完全错误。(刻意制造)冗长讨论是WP:GAME所明确表明不允许的(对,我的意思就是AT制订条文这个行为本身就已经是助长游戏规则,因为他刻意制造了冗长讨论)。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 02:43 (UTC)
- 每个用户都有权反对提案,而重大提案更应得到绝大部分人的同意,而不是把“少数反对”视为Game,详见WP:CON。您对方针的理解也是错误的,详见WP:GAME:“游戏维基规则的编者试图恶意使用方针,通过在字里行间为自己明显的扰乱行为寻找理据,而方针原意并不支持这种行为。”因此,game的背后的理据应是用户违反了方针,而非因为坚持自己的“反对立场”就是game。--虫虫飞♡♡→♡℃※留言 2020年7月24日 (五) 02:51 (UTC)
- 问题在于你(和部分其他管理员)经常在未了解相关事件的背景的情况下错判相关用户未有违反规则,并因此实质上助长相关用户游戏规则的行径。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 03:01 (UTC)
- 要判断用户game,前提是用户确实违反了方针,而不是把“反对意见”视为“扰乱”或者“game”,请尊重每个用户参与讨论及“反对提案”的权利。--虫虫飞♡♡→♡℃※留言 2020年7月24日 (五) 03:26 (UTC)
- 看来你还是没有汲取之前的教训。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月25日 (六) 02:26 (UTC)
- 问题在于你(和部分其他管理员)经常在未了解相关事件的背景的情况下错判相关用户未有违反规则,并因此实质上助长相关用户游戏规则的行径。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 03:01 (UTC)
- 你的理解完全错误。(刻意制造)冗长讨论是WP:GAME所明确表明不允许的(对,我的意思就是AT制订条文这个行为本身就已经是助长游戏规则,因为他刻意制造了冗长讨论)。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 02:43 (UTC)
- 如果任何我认为合理的修正案并未能通过的话,我不排除因应实际需要而忽略这一部分的条文,但我会确保讨论和公示时间会维持合理的长度。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月25日 (六) 02:33 (UTC)
- (-)反对:对于违反WP:共识的方案,反对硬通过。--虫虫飞♡♡→♡℃※留言 2020年7月25日 (六) 03:37 (UTC)
为现有COVID-19共识增加豁免案例
|
|
如上。草案为暂拟,可以扩充&修改。—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月22日 (三) 12:42 (UTC)
- (+)倾向支持,同意草案。--枫叶留·献·签 2020年7月22日 (三) 14:39 (UTC)
- (+)支持:此举可有效防止编者因该共识而修改参考资料的标题或相关机构的名称另,建议将此作为规定(必须使用原有称呼),而非豁免。——BlackShadowG★(留言) 2020年7月23日 (四) 02:28 (UTC)
- (?)疑问:第二条是指“若在参考来源的标题中出现,正文也要跟原有称呼”,还是“若在参考来源的标题中出现,引用的标题也要跟原有称呼”?如果是后者,建议修改用字,如改为“在引用参考来源时,来源标题须跟从原有用字。”--【和平至上】支持通过港区国安法💬 2020年7月23日 (四) 02:33 (UTC)
- 肯定是后者,已修改。—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月23日 (四) 13:54 (UTC)
- @Sanmosa:可不可以做事实性修订直接写入共识?—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月23日 (四) 14:03 (UTC)
- 我建议一个字眼调整:“不常用”→“非上述规定可使用的”。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月23日 (四) 14:29 (UTC)
- (+)支持。--安全体验TM 2020年7月24日 (五) 10:21 (UTC)
- 针对拟议修改版本的第二部分,我建议改为定义“条目内文”不含参考资料。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月26日 (日) 05:10 (UTC)
- (✓)同意,更加简洁明了。—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月27日 (一) 23:34 (UTC)
- (+)支持。--忒有钱🌊塩水あります🐳(留言) 2020年7月27日 (一) 09:30 (UTC)
- 原则上(+)支持;(!)意见:似乎仍有一些相当特殊情况不宜使用“2019冠状病毒病”,建议第二条的“(参考)来源”改为“(参考)来源或外部链接”(例:2019冠状病毒病香港疫情相关争议#外部链接的2019冠状病毒病民间资讯应改为武汉肺炎民间资讯)另外有一些我暂时未能想到一个准确的描述。例如2019冠状病毒病香港疫情相关争议#其他争议一节“郭家麒认为...食卫局应尽力要求内地交代武汉肺炎是什么”,学名本质上必然隐含已经有明确的指涉对象,与“要求内地交代”隐含的不明确有冲突,改成“要求内地交代2019冠状病毒病是什么”总是怪怪的。--PastorPsy326(留言) 2020年7月27日 (一) 10:15 (UTC)
- 第二条即共识中提及的“除非有提及其他称呼的必要”。—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月27日 (一) 23:34 (UTC)
- 那句好像没有来源,如果有来源,建议直接改以引用方式行文即可。 【和平至上】支持通过港区国安法💬 2020年7月29日 (三) 11:51 (UTC)
依据Sanmosa上方意见,提出第二版修改草案:
|
|
- ^ 包括但不限于机构、文件等专有名词,如“北京市新冠肺炎疫情防控工作领导小组”“《新型冠状病毒感染的肺炎诊疗方案(试行第七版)》”不得改成“北京市2019冠状病毒病疫情防控工作领导小组”“《2019冠状病毒病诊疗方案(试行第七版)》。”
请复查。@一片枫叶、BlackShadowG、和平至上、SecurityXP、忒有钱、@PastorPsy326—Rowingbohe♫ 欢迎参加浙江专题和台州专题 2020年7月27日 (一) 23:34 (UTC)
- (✓)同意--枫叶 签名 DC18 3000编辑,冲啊! 2020年7月28日 (二) 11:45 (UTC)
- (✓)同意。--忒有钱🌊塩水あります🐳(留言) 2020年7月28日 (二) 12:04 (UTC)
防滥用过滤器进行标签、警告、阻止及封锁等动作的依据
关于维基语言问题
建议明确规定是否应加入空格
建议规定中文和其他在字词间应加入空格的语言混用时应在中文和该语言间加入空格。 两个连续的字词间有空格的语言的字词根据现行格式手册规定,应加入空格,此时,两种语言间不加入空格会使句子被分成两个部分,举个例子,“就拿this sentence来说。”,这个句子被空格分成了两个部分“就拿this”和“sentence来说。”,如果加入空格“就拿 this sentence 来说。”,就可以保证句子的连续性。 --列维(留言) 2020年7月24日 (五) 08:44 (UTC)
- 中英文混用时是应该加空格的。[来源请求][1]--【和平至上】支持通过港区国安法💬 2020年7月24日 (五) 12:24 (UTC)
- 呵呵,我恰恰认为汉语文章中只要有这种空格就不对。--7(留言) 2020年7月24日 (五) 13:02 (UTC)
- (✓)同意。-hiJK910 七一七二一or4B7NpHwbY 2020年7月24日 (五) 17:32 (UTC)
- (!)意见:请说出明确的理由,不要凭借感觉来。列维(留言) 2020年7月25日 (六) 10:02 (UTC)
- 中文行文一般都没有空格这种东西。(你没有签名,是谁啊)-hiJK910 七一七二一or4B7NpHwbY 2020年7月25日 (六) 08:57 (UTC)
- 不论什么语言,国际计量局都建议在阿拉伯数字与计量单位字母符号之间插入一个半形空格,不能在中文中一味否认空格啊。(上方已补上签名)列维(留言) 2020年7月25日 (六) 10:02 (UTC)
- 对于写汉语的人来说,国际计量局是个什么东西?为什么要听它(他?她?)的?外语世界写一个个词语都有空格呢。--7(留言) 2020年7月25日 (六) 10:08 (UTC)
- 建议你去删除中文维基百科所有的空格。列维(留言) 2020年7月25日 (六) 10:55 (UTC)
- 这个情况下,阿拉伯数字会被当成外语的一部分(如果把单位当成外语的话)。SANMOSA SPQR 2020年7月31日 (五) 07:17 (UTC)
- 用于“阿拉伯数字与计量单位字母符号”的规则就是你的最强论点吗?知道了。-hiJK910 七一七二一or4B7NpHwbY 2020年7月25日 (六) 10:22 (UTC)
- 请给出你的论点再在这里对我的论点阴阳怪气,“中文行文一般都没有空格这种东西”这句话根本不成立。列维(留言) 2020年7月25日 (六) 10:55 (UTC)
- 对于写汉语的人来说,国际计量局是个什么东西?为什么要听它(他?她?)的?外语世界写一个个词语都有空格呢。--7(留言) 2020年7月25日 (六) 10:08 (UTC)
- 不论什么语言,国际计量局都建议在阿拉伯数字与计量单位字母符号之间插入一个半形空格,不能在中文中一味否认空格啊。(上方已补上签名)列维(留言) 2020年7月25日 (六) 10:02 (UTC)
- 中文行文一般都没有空格这种东西。(你没有签名,是谁啊)-hiJK910 七一七二一or4B7NpHwbY 2020年7月25日 (六) 08:57 (UTC)
- 我记得现行格式手册(或其他方针指引)有相反的规定,不知道是不是我的错误印象。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月24日 (五) 13:59 (UTC)
- 我和你有着同样的印象,但奇怪的是,在格式手册的历史记录中找不到任何这样的内容,所以决定在这里申请统一一下。列维(留言) 2020年7月24日 (五) 15:16 (UTC)
- 原来是灰色地带,法无禁止。所以到底有没有明文规定啊,不然每次都要发生编辑战,真的有够麻烦(跟爱好者内容有87%像)。 --无心*插柳*柳橙汁 2020年7月24日 (五) 17:27 (UTC)
- 十年前就发生过编辑战了,见WP:PIRATE。另见Wikipedia_talk:格式手册/存档3#一个空格的问题--GZWDer(留言) 2020年7月24日 (五) 19:08 (UTC)
- 大陆似乎是一般不加空格的。港台不清楚。Itcfangye(留言) 2020年7月24日 (五) 22:59 (UTC)
- 香港好像没有统一标准。我个人偏好不加空格,除非牵涉到官方名,而官方名加了空格。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月25日 (六) 02:09 (UTC)
- 这追根究底完全是偏好的问题,我偏好加空格,包括阿拉伯数字也是,这样比较美观。就我所知专业印刷、排板等等都是会加的,或是系统自动会调整字短产生空格的效果。有些电脑系统中的功能加了空格会处理得比较好,例如拼字检查、断句和换行,不过这取决于具体系统是怎么写的,理论上也可以做成不用空格。--Yel D'ohan(留言) 2020年7月25日 (六) 06:40 (UTC)
- 找到了W3C的草案建议中外文中间要留空。--Yel D'ohan(留言) 2020年7月25日 (六) 06:45 (UTC)
- 偏好问题,真要统一其实很难。至少据我所知Word和WPS都有自动在外文两侧加空格的特性,因而确实很多编者没有这个自觉。再者说,今天我们要就中外文之间是否加空格规范,那明天是不是要规范一下C代码大括号换不换行、缩进用空格还是Tab、一个条目的长度是不是要严格控制在128K以内这些特别容易引起冗长讨论和不必要战争的问题啊?[开玩笑的]--BoyuZhang1998(留言) 2020年7月25日 (六) 07:21 (UTC)
- (-)倾向反对,是否应该加入空格应当由渲染器(如浏览器)来决定,不应该由编者来决定。举例来说现今大多数阅读软件都会自动将纯文本图书根据屏幕尺寸、分辨率、PPI等内容重新排版,编者只需要写出文字,不需要操心排版问题。但是目前中文的浏览器排版能力很薄弱,很多是借助网页请求来排版而不会自主排版,不过很多浏览器厂商已经意识到这个问题,默认排版格式可能存在影响阅读体验情况,于是乎现在浏览器开始加入“阅读模式”,对文字进行重新排版。但是如果编者手动加入空格就会导致对未来的排版引擎不兼容,因为浏览器排版和阅读软件排版一样,不会忽略文字,只是调整文字直接间隔,多了一个空格毕竟多了一个字符,再加上阅读器本身增加的字间距,就会导致“双倍空格”影响阅读。所以不要做让未来替现在擦屁股,不希望在未来浏览器的阅读排版普及后,还要发动大家手动删除空格。以上只是针对普通人来说,再说下视觉障碍人士使用的阅读器(朗读器),中文(汉语)朗读器几乎都会在空格、换行中做出停顿,所以这会影响听觉体验,甚至让人们无法分辨是换行还是空格。但是未来浏览器的排版引擎不会使得字之间“空格”引起的停顿,这是因为排版引擎,包括Word都不是空格,而是在英文与中文直接调整字体缩放,换句话说其中没有多一个字符,多一个字符会让机器无法分辨是保留还是去除。综上所述,倾向反对此提案。--176.103.9.248(留言) 2020年7月25日 (六) 08:23 (UTC)
- 补充下,当前桌面浏览器的“阅读模式”都是刚诞生的新东西,还不完美,不过你们可以体验下,Microsoft edge和Firefox都具备“阅读模式”功能,Chrome没有,但是有一个大神开发的扩展插件可以自动在中英文中调整缩进,以我个人来看,阅读模式只是一个过度技术,因为浏览器的作用就是渲染和呈现,这个功能未来不一定会被独立出来而是成为浏览器基本功能。--176.103.9.248(留言) 2020年7月25日 (六) 08:34 (UTC)
- (:)回应:当你在中英文之间加入空格时大部分本身会调整直接间隔的阅读器会不调整字体缩放,大部分情况下不会出现“双倍空格”的现象,至于中文朗读器,很少会有朗读器在空格处停顿,否则掺杂英文的语段因为必要的空格也会应先听觉体验。列维(留言) 2020年7月25日 (六) 09:54 (UTC)
- (:)回应:说话要讲证据的“当你在中英文之间加入空格时大部分[哪个/哪些?]本身会调整直接间隔的阅读器会不调整字体缩放,大部分情况下[哪个/哪些?]不会出现“双倍空格”的现象[来源请求]”,“很少会有朗读器[比如?]在空格处停顿,否则掺杂英文的语段因为必要的空格也会应先听觉体验。”。质疑完你说的,我再回应下,某些阅读模式、朗读器确实更“智能”了,可以判断上下文关系调整字体缩放以及朗读语速,但这不是绝对的,我不知道你有没有写过这方面的代码,如果程序要“智能”判断最常见方法是字典,有一套预先存在的规则,在规则内不会出错,但是超过字典本身就会出错,而不可能有一本字典保存所有语句的上下文关系,字典毕竟不是图书馆,这种智能总会因为编者不统一提高出错机会,我们不应该依赖这种智能。当然,您可以提出一套方针让全中文维基百科统一规则,这确实是个“好方法”,但是您让所有编者做了程序该做的事情后并不代表不会出错,因为浏览器、阅读器、朗读器不是为维基百科而打造的,其他网站不照做的话,程序还需要兼容他们,该发生的错误还是会发生。最后,实际上手动添加空格,这会导致维基百科鹤立鸡群,程序是需要做好维基百科的兼容性,而不是其他网站,建议您多看看在线新闻出版物,那些内容是阅读器、朗读器最常派上用场的地方,而阅读器、朗读器也是优先优化他们的格式。(附:日后回复可能会用其他IP)--176.103.9.248(留言) 2020年7月25日 (六) 11:34 (UTC)
- (:)回应:同理,“举例来说现今大多数[哪个/哪些?]阅读软件都会自动将纯文本图书根据屏幕尺寸、分辨率、PPI等内容重新排版,编者只需要写出文字,不需要操心排版问题。”“但是如果编者手动加入空格就会导致对未来的排版引擎不兼容[哪个/哪些?],因为浏览器排版和阅读软件排版一样,不会忽略文字,只是调整文字直接间隔,多了一个空格毕竟多了一个字符,再加上阅读器本身增加的字间距,就会导致‘双倍空格’影响阅读。[来源请求]”“以上只是针对普通人来说,再说下视觉障碍人士使用的阅读器(朗读器),中文(汉语)朗读器几乎都会[比如?]在空格、换行中做出停顿,所以这会影响听觉体验,甚至让人们无法分辨是换行还是空格。”再说现在站内既有很多加入空格的,也有很多不加空格的,何必还要对统一后可能会发生的错误而担忧呢?更何况两种情况下都又发生错误的可能。毕竟 Google、Microsoft 等公司的官方网站都会在中英文间加入空格,也没有出现所谓“双倍空格”“影响听觉体验”等“兼容问题”。[开玩笑的]列维(留言) 2020年7月25日 (六) 11:58 (UTC)
- (:)回应:一个最简单的阅读软件例子,打开Windows的记事本程序,在上面“格式”菜单中有个“自动换行”,这个就是最基本的排版,你可以关掉再写一段内容试试看。然后再说说朗读器,根据W3C规范是使用代码来断句和停顿的[2],一个TTS引擎开发指南也写了对于空格、换行和特殊符号时要特别留意和判断,并且针对相关字符做出停顿等操作[3]。另外您可以看下维基百科的空格条目了解下为什么会有喜好中英文之间加空格。虽说现今浏览器阅读体验(尤其是中文)还是很不完美,方针本意是好的,毕竟优秀的阅读体验大家都会喜欢,但是没有理由让编者来适配程序。给您几点建议:一、您自己使用可以自动为中英文中间添加缩进的阅读器或者浏览器扩展;二、您督促浏览器开发人员尽快提高阅读体验;三、您要求维基百科开发人员从服务器端的代码上为中英文间添加缩进。前两者是客户端上做出这种效果,最后一个是服务器端做出,都可以完美实现,对于第二点如果您有需要我还可以向您提供谋智(就是火狐浏览器中国公司)的联系方式,您可以把您的诉求阐述给他们,没准您超有说服力让他们提前实现了未来几年的工作。倘若您继续坚持让所有编者来做其他人该做的工作,那么我只好现在就(-)强烈反对了。--176.103.9.248(留言) 2020年7月25日 (六) 20:27 (UTC)
- (:)回应:记事本程序的“自动换行”与中英文之间间隔的排版无关,并不能解决有关这方面的问题,所以编者在排版方面并不是不需要操心的,并且此提案的目的并不是为了避开程式错误,其目的是让维基百科的排版统一,有关 TTS 方面本人确实不了解,暂时保留意见。列维(留言) 2020年7月26日 (日) 03:16 (UTC)
- 这样说吧,当前几乎所有主流浏览器对于中英文掺杂的文章渲染不好,这是大家有目共睹,我也是(✓)同意的,您试图通过添加空格形式改善阅读体验我也是理解的,但是也就是这几年高分辨率屏幕出来后桌面浏览器和电脑操作系统才真正开始重视显示和渲染,现在全英文下桌面浏览器显示效果已经能接近纸质了,但是中文下关心的很少,Chrome因为市场缘故这方面努力做的很少,Microsoft edge初期完全继承了IE能用就行的思想,就最近新BOSS带领下才有点作为,估计也就是三把火,烧完后可能也就没啥了,Firefox因为一开始就扎根大中华区所以这方面算是做的最早的一批了,但是这两年Firefox日子不好过,中国区那帮家伙现在重点早就投向了移动端,桌面这边也就是英语版有什么就拿来什么,基本不再基于本地市场向上游提供解决方案。所以这也是为什么Google、Microsoft网站上面中文内容都会添加空格“手动排版”。直至近期情况有了些转变,Chrome自从几年前攻克了在中国大陆架设更新服务器这个难题后,也开始逐渐重视这个市场,我相信这三家带领下排版会很快迎来改善,但是如果我们“手动排版”就恰好给这三家一个推迟研发此功能的理由,到时候吃亏的是大家。所以我的立场是不要让编者们做浏览器开发人员们该做的事情。实际上针对提高阅读体验我有几点建议:维基百科程序员可以在网页代码中自动调整字与字直接的间距,这个可以作为浏览器排版全面普及前的一种过渡技术,并且由于是代码层面实现,所以没有编者的事情,利于全站全面启用,以及未来全面关闭。第二,你们可以去给Firefox和Chrome社区留言,较人多要求后他们才有动力(认真的)。--176.103.9.248(留言) 2020年7月26日 (日) 13:40 (UTC)
- (:)回应:记事本程序的“自动换行”与中英文之间间隔的排版无关,并不能解决有关这方面的问题,所以编者在排版方面并不是不需要操心的,并且此提案的目的并不是为了避开程式错误,其目的是让维基百科的排版统一,有关 TTS 方面本人确实不了解,暂时保留意见。列维(留言) 2020年7月26日 (日) 03:16 (UTC)
- (:)回应:一个最简单的阅读软件例子,打开Windows的记事本程序,在上面“格式”菜单中有个“自动换行”,这个就是最基本的排版,你可以关掉再写一段内容试试看。然后再说说朗读器,根据W3C规范是使用代码来断句和停顿的[2],一个TTS引擎开发指南也写了对于空格、换行和特殊符号时要特别留意和判断,并且针对相关字符做出停顿等操作[3]。另外您可以看下维基百科的空格条目了解下为什么会有喜好中英文之间加空格。虽说现今浏览器阅读体验(尤其是中文)还是很不完美,方针本意是好的,毕竟优秀的阅读体验大家都会喜欢,但是没有理由让编者来适配程序。给您几点建议:一、您自己使用可以自动为中英文中间添加缩进的阅读器或者浏览器扩展;二、您督促浏览器开发人员尽快提高阅读体验;三、您要求维基百科开发人员从服务器端的代码上为中英文间添加缩进。前两者是客户端上做出这种效果,最后一个是服务器端做出,都可以完美实现,对于第二点如果您有需要我还可以向您提供谋智(就是火狐浏览器中国公司)的联系方式,您可以把您的诉求阐述给他们,没准您超有说服力让他们提前实现了未来几年的工作。倘若您继续坚持让所有编者来做其他人该做的工作,那么我只好现在就(-)强烈反对了。--176.103.9.248(留言) 2020年7月25日 (六) 20:27 (UTC)
- (:)回应:同理,“举例来说现今大多数[哪个/哪些?]阅读软件都会自动将纯文本图书根据屏幕尺寸、分辨率、PPI等内容重新排版,编者只需要写出文字,不需要操心排版问题。”“但是如果编者手动加入空格就会导致对未来的排版引擎不兼容[哪个/哪些?],因为浏览器排版和阅读软件排版一样,不会忽略文字,只是调整文字直接间隔,多了一个空格毕竟多了一个字符,再加上阅读器本身增加的字间距,就会导致‘双倍空格’影响阅读。[来源请求]”“以上只是针对普通人来说,再说下视觉障碍人士使用的阅读器(朗读器),中文(汉语)朗读器几乎都会[比如?]在空格、换行中做出停顿,所以这会影响听觉体验,甚至让人们无法分辨是换行还是空格。”再说现在站内既有很多加入空格的,也有很多不加空格的,何必还要对统一后可能会发生的错误而担忧呢?更何况两种情况下都又发生错误的可能。毕竟 Google、Microsoft 等公司的官方网站都会在中英文间加入空格,也没有出现所谓“双倍空格”“影响听觉体验”等“兼容问题”。[开玩笑的]列维(留言) 2020年7月25日 (六) 11:58 (UTC)
- (:)回应:说话要讲证据的“当你在中英文之间加入空格时大部分[哪个/哪些?]本身会调整直接间隔的阅读器会不调整字体缩放,大部分情况下[哪个/哪些?]不会出现“双倍空格”的现象[来源请求]”,“很少会有朗读器[比如?]在空格处停顿,否则掺杂英文的语段因为必要的空格也会应先听觉体验。”。质疑完你说的,我再回应下,某些阅读模式、朗读器确实更“智能”了,可以判断上下文关系调整字体缩放以及朗读语速,但这不是绝对的,我不知道你有没有写过这方面的代码,如果程序要“智能”判断最常见方法是字典,有一套预先存在的规则,在规则内不会出错,但是超过字典本身就会出错,而不可能有一本字典保存所有语句的上下文关系,字典毕竟不是图书馆,这种智能总会因为编者不统一提高出错机会,我们不应该依赖这种智能。当然,您可以提出一套方针让全中文维基百科统一规则,这确实是个“好方法”,但是您让所有编者做了程序该做的事情后并不代表不会出错,因为浏览器、阅读器、朗读器不是为维基百科而打造的,其他网站不照做的话,程序还需要兼容他们,该发生的错误还是会发生。最后,实际上手动添加空格,这会导致维基百科鹤立鸡群,程序是需要做好维基百科的兼容性,而不是其他网站,建议您多看看在线新闻出版物,那些内容是阅读器、朗读器最常派上用场的地方,而阅读器、朗读器也是优先优化他们的格式。(附:日后回复可能会用其他IP)--176.103.9.248(留言) 2020年7月25日 (六) 11:34 (UTC)
(-)倾向反对:就拿「this sentence」来說
,这样写即可避免出现歧义。 -- Suzuha Amane(留言) 2020年7月25日 (六) 12:00 (UTC)- 不好意思,我没表达清楚,“就拿 this sentence 来说”是一句话,我举的例子就是这句话。列维(留言) 2020年7月25日 (六) 12:10 (UTC)
- 我的意思是用引号框住中文之中内含空格的英文。 -- Suzuha Amane(留言) 2020年7月25日 (六) 18:13 (UTC)
- 不可能文中出现人名或专有名词全都加上引号,那不符合任何语言的使用习惯。--Yel D'ohan(留言) 2020年7月25日 (六) 19:50 (UTC)
- 人名请翻译为中文。 【和平至上】支持通过港区国安法💬 2020年7月26日 (日) 11:54 (UTC)
- 你叫那些写日本流行文化条目的人把 YOSUKE KOSUKE、Mitchie M、Sachiko M、World's end girlfriend 翻成中文看看。--Yel D'ohan(留言) 2020年7月28日 (二) 23:25 (UTC)
- 人名请翻译为中文。 【和平至上】支持通过港区国安法💬 2020年7月26日 (日) 11:54 (UTC)
- 不可能文中出现人名或专有名词全都加上引号,那不符合任何语言的使用习惯。--Yel D'ohan(留言) 2020年7月25日 (六) 19:50 (UTC)
- 我的意思是用引号框住中文之中内含空格的英文。 -- Suzuha Amane(留言) 2020年7月25日 (六) 18:13 (UTC)
- 不好意思,我没表达清楚,“就拿 this sentence 来说”是一句话,我举的例子就是这句话。列维(留言) 2020年7月25日 (六) 12:10 (UTC)
- (-)反对:改票,反对以任何形式加入空格。 -- Suzuha Amane(留言) 2020年7月26日 (日) 18:58 (UTC)
- 要不然这样,我反过来建议在格式手册中明确规定:中文和其他在字词间应加入空格的语言混用时,不应在中文和该语言间加入空格,除非牵涉专有名词。ꓢꓯꓠꓟꓳꓢꓮ SPQR 2020年7月26日 (日) 05:20 (UTC)
- 我偏好加空格,而且没看到任何禁止空格的理由。--Yel D'ohan(留言) 2020年7月28日 (二) 23:29 (UTC)
- (!)意见:我觉得其实这个应该由CSS实现。目前CSS的标准已经有相关提案了,见此文章以及CSS Text Module Level 4 Draft的
text-spacing
属性。IE早就有相关实现[4],但是照目前W3C的提案,text-autospace
属性已经重命名到text-spacing
了。所以我的(&)建议是可以先等等,等到这个W3C Draft通过或者有浏览器实现这个属性,虽然估计得等起码5年;现在手动加没什么太大必要,但是加了也不会有什么负面影响,我对手动加空格持(=)中立态度,但是目前应该对因加空格而产生的编辑战按照简繁破坏类似的方针处理,即,最初若有空格,则不要特意去掉,若最初没有空格,则不要特意加上。gaosong2101 🏠 📫 📜 2020年7月26日 (日) 18:54 (UTC) - (!)意见:楼主:在下认为"就拿“this sentence”来说"已无疑是正确的中文,我好奇什么时候一句合理的中文会出现"就拿 this sentence 来说"这样的词组或句子,晶晶体吗?但晶晶体并不是correct Chinese,因此讨论晶晶体要不要加空格是 meaningless 行为,这与“硫酸的口感接近什么饮料”一样是虚幻而不值得讨论的问题(因为硫酸根本不是饮料)。不然阁下举一个更长更完整且合理的中文句子为例,让大家讨论,如何?-游蛇脱壳/克劳棣 2020年7月26日 (日) 22:03 (UTC)
- (:)回应:举这个例子只是为了具有普遍性,实际的例子是存在的,例如“其中Google Chrome排名首位”(复制自 Google Chrome)列维(留言) 2020年7月27日 (一) 03:50 (UTC)
- 相关的例子还有游戏条目,看看《生化危机7_恶灵古堡》里面“PlayStation 4”、“Xbox One”和“Microsoft Windows”三个空格名词。 --无心*插柳*柳橙汁 2020年7月27日 (一) 04:03 (UTC)
- (-)反对,中文与其他文字、符号之间插入空格。中文中夹杂连续的其他文字、符号时,是否需要空格,应按照所插入文字、符号的规则来。--苞米(☎)💴 2020年7月27日 (一) 04:16 (UTC)
- (:)回应:请仔细阅读提案哦,提案和你的描述是一致的。列维(留言) 2020年7月27日 (一) 08:31 (UTC)
- (-)反对,中文与其他文字、符号之间插入空格。中文中夹杂连续的其他文字、符号时,是否需要空格,应按照所插入文字、符号的规则来。--苞米(☎)💴 2020年7月27日 (一) 04:16 (UTC)
(-)反对:有加和没加空格都一样,如果你要表达的是“this”和“sentence”,那为什么不直接讲“this和sentence”就好了Felix.tsai(留言) 2020年7月28日 (二) 14:16 (UTC)
- (:)回应:这个办法并不是可行的,不能再每个地方都这么用啊列维(留言) 2020年7月29日 (三) 07:11 (UTC)
没有空格不容易阅读,英文和汉字都紧紧贴在一起没有距离。如果两边都是汉字倒是觉得没关系,但是如果是汉字和其他语言,就会有一种“粘”在一起的感觉(尤其是英语这种字体宽度较窄的,如果是日语这种较宽的就没关系),比较难看。如果有距离就可以让人一看就知道:“从这里开始就不是汉语了,是其他语言了”。 -- 2A00:B700:0:0:0:0:2:2E4(留言) 2020年7月28日 (二) 14:26 (UTC)
- 我怎么有一种百乐🐇回来了的错觉--Super Wang※DC不是贪食蛇,请勿盲目刷分 2020年7月30日 (四) 08:56 (UTC)
- 感谢楼上让我和IP有了距离。要距离的话,隔行就肯定有距离,效果更明显。然而,我不认为距离是个好理由。SANMOSA SPQR 2020年7月31日 (五) 07:12 (UTC)
参考资料
- ^ CSS and International Text. 万维网联盟. 2016-07-19 [2020-07-27].
When non-ideographic text or numbers appear in ideographic text it is often preferable to separate the two with a little additional space.
- ^ https://www.w3.org/TR/speech-synthesis/#S3.2.3
- ^ http://www.festvox.org/docs/manual-1.4.2/festival_9.html
- ^ -ms-text-autospace.