维基百科:互助客栈/方针/存档/2015年12月

有关于DYKC规则中的“原创”如何验证

关于红绿连的最终方案

批量议案

此处张贴一些关于现行方针的批量议案。这些议案均不或很少修改方针的实际内容,而是对于方针页面的结构层次、附属关系、术语用法加以调整。不过由于数量较多,仍然贴出以求社群认可。每个具体议案的内容、性质和目的将会在以下列表及讨论区中详细呈现。

议案名称议案内容
第一议案(已执行)合并Wikipedia:半保护方针Wikipedia:保护方针
第二议案(无 果)合并Wikipedia:维基百科不是词典Wikipedia:维基百科不是什么
第三议案(已执行)修改保护方针两处内容:允许用户请求无限期半保护其用户页面,以及声明全保护不用于高风险页面以外的预见性保护。
第四议案(已执行)Wikipedia:管理员解任投票页面中的方针部分剥离,合并到Wikipedia:管理员的离任

希望本次一系列的小修补能让方针的内容层次更加清晰,并在保持内容的前提下适当精简方针页面数量。如果可能,希望每个议案各自达成相应共识,并请大家在讨论时避免使用投票模板。

-- Bluedeck 2015年11月3日 (二) 03:08 (UTC)

第一议案讨论区

第一议案内容为合并半保护方针和保护方针。理由是前者并没有独立的必要,且叙述内容和核心观点均和后者相同。合并的好处是方针层次将更加整洁,同时保护方针页面长度仍可以控制在合理范围。合并后,WP:半保护方针页面摘下方针模板,其实质内容将反映在WP:保护方针#半保护一节当中。预计本提议实现后,WP:保护方针页面变成这个样子:User:Bluedeck/bibliotek/history/1446518872196(本草稿是第一议案和第三议案合并执行结果,所以包含两处实质性修改)。现将本第一议案张贴于此寻求共识。Bluedeck 2015年11月3日 (二) 03:09 (UTC)

请放心,这只是预览。如果第一议案通过而第三议案否决,我将不会把“私货”带进去,这也是分开讨论的好处。至于草稿没有体现半保护方针的合并,关于这一点,请参看当前的WP:半保护方针页面,可分为3部分:导言、“如何执行”的手册以及导航部分(忽视一个“重复一遍”的章节)。其中,只有导言部分包含了实际的方针内容,而导言段落的叙述内容均已在草稿中体现(其大部分已经在现行保护方针中存在)。Bluedeck 2015年11月3日 (二) 12:47 (UTC)
前者并没有独立的必要,且叙述内容和核心观点均和后者相同。合并的好处是方针层次将更加整洁,同时保护方针页面长度仍可以控制在合理范围。合并后,WP:半保护方针页面摘下方针模板,其实质内容将反映在WP:保护方针#半保护一节当中。
诚然,没人规定方针不能合并,但为了整洁而合并方针页面,这显然不是好理由;且本提案有涉及修改方针,非为单纯的合并,故当前顺序错了,应先讨论修改内容,有共识后再执行合并,现阶段投支持或反对票都不宜。--秋意假发浓(我已关闭了所有通知,所以@我看不到)留言2015年11月4日 (三) 18:18 (UTC)
我来说明。方针的系统性、逻辑性和层次性是非常重要的。自从我加入维基百科以来,虽然日渐熟悉各种方针,然而始终不敢说自己“系统性的”了解了维基的所有方针,这还不算指引。其原因就是我们的方针页面数量多,层次乱。即使这点小的修改远不能让没有维基经验的人从零上手毫无难度,然而进步总是好的。而且整理方针层次并不涉及实质内容,所以我觉得“为了整洁而合并方针页面”是一个值得去做的工作,也是很好的更新理由。由于涉及内容修改的提案,我已单独列出,故不会造成混乱——正如我上边所叙述的,如果第一议案通过,而第三议案否决,我将只把第一议案相关的内容更新进新的方针中去。至于结构性修改和内容性修改的讨论同时进行一事,我认为并无不当。最后,在共识有望的情况下减少投票模板的使用确实值得提倡。以上。Bluedeck 阿里君♥优酷酱 2015年11月4日 (三) 19:24 (UTC)
维基基本法?--Temp3600留言2015年11月5日 (四) 05:18 (UTC)
那不是WP:5P?说到这个,楼主似乎是想把目前类似欧美法系的地方往大陆法系上靠……各有利弊,我不反对就是了。 --达师 - 318 - 527 2015年11月5日 (四) 08:38 (UTC)
我这在做的事情像大陆法系的风格吗?我不这么觉得。剥离手册内容这种简化操作应该是正相反的情况。维基百科的方针不可能做到大陆法系的水平,法无禁止即可行,所以我也没有意愿往那上靠。Bluedeck 阿里君♥优酷酱 2015年11月5日 (四) 13:38 (UTC)
  • (+)支持都是保护,合并好看一些 --(叮当呀,谁都喜欢,小猫也自豪!) 2015年11月6日 (五) 09:40 (UTC)
  • 我认为方针与指引是写给用户看的,它并不是法条。我们不能保证任何用户都能如同阁下精熟你所述的内容,或了解保护与半保护的差别(比方说,我常看到资深用户以“条目内文不中立”作为删除理由,明明就没这条理由),会不会手机滑到一半觉得太长就跳过不看,谁知道?我认为,如果该页面有必要独立论述,则应分撰,反之就该合并;若单纯仅以页面长短或简洁与否作为分拆或合并理据,都是不适宜的,若说现在讨论的是百科全书条目,那就另论。--秋意假发浓(我已关闭了所有通知,所以@我看不到)留言2015年11月6日 (五) 20:49 (UTC)
我感到阁下的一些想法和现实情况差距甚远。您一定还没读过我写的草稿。内容不变的情况下简洁化方针,这就是本议案做的事情。长度几乎不变的情况下精简掉一个页面,这就是草稿在呈现的状况。您担心“手机滑到一半觉得太长就跳过”,又声明“以页面长短或简洁与否作为分拆或合并理据,都是不适宜的”;您指出“如果该页面有必要独立论述,则应分撰”,却未见独立叙述的必要性为何。这是矛盾的逻辑啊。Bluedeck 阿里君♥优酷酱 2015年11月6日 (五) 22:03 (UTC)
晕。这事有这么复杂?您说您的议案要简洁方针,我也说了,没人规定不可以简洁方针。但是,只单纯为了“长度几乎不变的情况下精简掉一个页面”有何必要,您还是没有回答啊,这和有没有看过草稿怎又扯在一起?好,为何我会这样问?我们现在讨论的,是维基百科的方针或指引,它不仅仅是一个条目页面的存废,可能讨论后,认为没关注度就合并到主条目即可解决;而是在讨论要将半保护方针合并到保护方针里去;还有,您提案的合并,亦有涉及修改内文的部分,也不全是单纯地将B重复内文的部分合并到A;最关键的问题是,为何一定要简洁,页面美观清爽?看了心情舒畅?如果仅以此理由就要修改方针或指引,个人绝对反对。倘若继续保持现状不合并,又将导致谁的不便?或者合并后,网站速度会加快0.0000001秒?若以此类理由要修改社群方针是不必要的。最后,我一直很排斥这种斗争式的讨论法。不回答问题,反而先指责的思维就没意思了。请问,今日提案要合并的的是您还是我,怎么提案要合并的,不指出合并的必要性,反而要我来提出独立叙述的必要性,这种逻辑您自己不觉得怪?举例:A说秋意假发浓杀人,理由是“我觉得他有杀人”,“他看起来像杀人犯集团的一分子”,但A没有提出任何证据,接着要秋意假发浓证明自己没杀人?--秋意假发浓(我已关闭了所有通知,所以@我看不到)留言2015年11月7日 (六) 20:02 (UTC)
很抱歉,我没有想到会给您造成争斗的印象。我没有回答问题是因为您没有提出任何问题,仅仅叙述了观点(唯一的一个问句是“谁知道?”);我挑您的逻辑的毛病是因为在我看来真的是矛盾的。刚刚您增加了一个问题,“为何一定要简洁”,我的回答是简洁增强理解和层次性,这对于方针和读者都是好事。您指出“您提案的合并,亦有涉及修改内文的部分”,我再此第四次说明我没有这么做——只是沙盒合并,不是议案合并。您举出例子“A说秋意假发浓杀人……证明自己没杀人?”,实际正好相反:我是“没杀人”的主张方,要求对方拿出“杀了人”的证据。因为同一个方针硬要拆分成两页才是需要理由的行为(议题方反转)。实际上举证责任在这种议题可反转的情况下不起作用,请查看举证责任_(哲学)#批评。以上。Bluedeck 阿里君♥优酷酱 2015年11月8日 (日) 07:19 (UTC)
本例中可留在WP下,也可留在H空间下。我建议其他例子中的手册内容如果有重名则放在H空间里。Bluedeck 阿里君♥优酷酱 2015年11月7日 (六) 18:29 (UTC)

本议案执行完毕。Bluedeck Paris Attacks 2015年11月18日 (三) 20:03 (UTC)

第二议案讨论区

Wikipedia:维基百科不是词典Wikipedia:维基百科不是什么是较为明显的重复叙述,且并不能看出有特别需要强调的理由和效果。提议是合并前者到后者。以上。现将本第二议案张贴于此寻求共识。Bluedeck 2015年11月3日 (二) 03:48 (UTC)

请求合并的动机主要是为了精简方针页面的数量、降低导航难度以及理顺逻辑关系。方针页面区别于一般论述,应小心对待。大量没有经过仔细考虑的方针页面可能带来社群层面的隐患。由于当前Wikipedia:维基百科不是词典的内容远不足以支持其单列方针,故请合并。一般而言,我认为如果一个方针的某个侧面有特殊强调的必要,则应调整其篇幅,或者针对其撰写论述或方针解释。将其单列为一单独方针的做法会造成一定混乱。Bluedeck 2015年11月3日 (二) 12:57 (UTC)
应该不会一直弄到TL的程度。当前凡是有TL的部分不是手册内容太多就是话说的不系统导致冗长而信息量并不多。在以后的系列议案中,解决这个问题也是一个预想。Bluedeck 2015年11月4日 (三) 04:04 (UTC)

(!)意见同时昭,应扩充维基百科不是词典。--Temp3600留言2015年11月8日 (日) 12:02 (UTC)

第三议案讨论区

两处方针内容修改:

第一处:允许用户请求无限期半保护其用户页面。理由:实际处理保护请求时有先例,同时本规则可以节约编辑者不必要的时间浪费。
第二处:声明全保护不用于高风险页面以外的预见性保护。理由:实际处理保护请求时的默认性规则。在半保护方针中有阐明,但在全保护方针中没有。现在阐明。

修改后的效果参见第一议案讨论区提供的草稿页面。以上。现将本第三议案张贴于此寻求共识。Bluedeck 2015年11月3日 (二) 03:25 (UTC)

第一处:是的,这里只是允许用户申请永久半保护,如果用户的申请不合情理,管理员自然可以不予执行或者调整期限执行。第二处:例1(全)例2(半)。目前“不做出预见性保护”是管理员处理保护请求的常识性规则,无论半保护全保护均是如此,故加入全保护方针中去。Bluedeck 2015年11月3日 (二) 12:49 (UTC)
根据目前方针“如用户页遭破坏,用户本人有权利申请对用户页进行最长一年的半保护。”,我认为已足够保障编者。--Temp3600留言2015年11月3日 (二) 15:46 (UTC)
user:秋意假发浓[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]您提出的这一点,我是经过仔细考虑的。我来叙述不做预防性保护的原因:因为预防性保护会妨害一些正常的编辑,从而使得维基效率下降。然而,对于用户页而言,出于非用户意愿的编辑是不正常的,所以“不预防”的逻辑不适用。在这里,反而是预防性保护才能够提高维基系统效率。所以这两个处修改虽然表面上是向着相反的方向,而实际上目标是相同的。Bluedeck 阿里君♥优酷酱 2015年11月4日 (三) 19:11 (UTC)
不明白为何要永久保护。我认为一年保护已足够保障编者。--Temp3600留言2015年11月5日 (四) 05:16 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]以下是某用户的用户页被破坏情况:2012年8月31日,8次破坏。2013年3月11日,人身攻击。2013年4月7日,扰乱。2013年4月17日,破坏。2013年8月28日,扰乱。2013年8月28日,人身攻击。2013年11月18日,人身攻击。2013年11月29日,破坏。2014年1月18日,扰乱。2014年12月13日,扰乱。2015年4月24日,威胁。2015年4月29日,威胁。2015年6月12日,扰乱。2015年7月15日,人身攻击。2015年9月13日,被张贴版权内容。最后,几天前的2015年10月21日,被张贴版权内容。本用户页其间被多次保护,保护终止后,破坏即开始。最长一年并非足以满足所有需要。Bluedeck 阿里君♥优酷酱 2015年11月5日 (四) 19:33 (UTC)
  • (+)支持:之前闷声中立)原来还有这么夸张的案例,那我冒泡出来支持。-- SzMithrandir(留言2015年11月6日 (五) 00:31 (UTC)
  • @Bluedeck:您以个案作为修改方针的理据仍不充分。如果以您提出的草案做准,也不须用户提出,管理员应当主动介入才对,因为当前保护页面权限只赋予管理员(我修正,少数维基人就只单纯想挂着管理员三个字“官衔’,根本不碰站务,不过这不能强迫,只能说社群当初是怎么投票选的)用户可主动申请永久半保护页面,但重点来了,一、谁有这个权利同意或反对保护别人的用户页面?管理员?行政员?二、为何仅允许用户页可以预防性保护,非用户页面却不允许,这个议案完全没提到,未来如有维基人以此质疑时,社群对此争议如何回应?因此案一与案三绝对不可包裹讨论。小结:本议案“第二处”争议不大,第一处则不够具体。--秋意假发浓(我已关闭了所有通知,所以@我看不到)留言2015年11月6日 (五) 20:31 (UTC)
“请放心,这只是预览。如果第一议案通过而第三议案否决,我将不会把“私货”带进去,这也是分开讨论的好处。”--Bluedeck 回复 Cwek 2015年11月3日
“正如我上边所叙述的,如果第一议案通过,而第三议案否决,我将只把第一议案相关的内容更新进新的方针中去。”--Bluedeck 回复 秋意假发浓 2015年11月4日
我在此第三次申明:沙盒是沙盒,议案是议案。我从一开始就是把第一议案和第三议案分开提的,从没有打包过。因此我觉得您是不是没有顺序看完全部留言?您提出的“也不须用户提出,管理员应当主动介入才对... ... 管理员?行政员?”部分我没有看懂您的意思,可否重新叙述?您提出的“为何仅允许用户页可以预防性保护”问题,我已在2015年11月4日19点11分(UTC)回复,就在上面不远处,您是否阅读了?您指出“第一处则不够具体”,当前第一处的叙述为“允许用户请求无限期半保护其用户页面”,我认为已经讲得非常明白,那就是把目前的最高一年期限放开,不设上限,您觉得是哪里不够具体,我愿意回答。Bluedeck 阿里君♥优酷酱 2015年11月6日 (五) 22:08 (UTC)
看到您这段回复,我终于明白,您也是需要说明很清楚的。管理员不是法官,方针或指引不是法条,维基百科没有法庭。社群投票推选维基人来做管理员,不等于管理员就是裁判员。社群给管理员判断页面存废、封禁用户、删除或保护页面等的权限,但管理员仍然不是法官(七十余位管理员,几个有法律相关背景专长的我很好奇),仅仅因为社群把这些权限集中给某些维基人,如此而已。诸位路人若认为管理员是维基百科的法官、官员什么等,那就错了,他们只是打杂工,每天做其他维基人不愿碰的事(当然也有挂管理员名字不打杂的人,此处不讨论),换言之管理员没有权力准许或否决任何一个用户的行为,管理员封禁用户、保护与删除页面的行动出发点,都是为了忠实履行社群赋予的权限(各位可以想成“对事不对人”。当然,我这里还是举例)。所以,除非与此用户相关的行为已经影响到了社群,这时管理员才有必要主动介入,因为当前能封禁用户或保护、删除页面的权限,社群只赋予了管理员,但这不等于管理员的权限可以无限扩张。打字到这里,我想一同和诸位路人一起试想。各位想像一下,维基百科刚初创的时候,有没有设置管理员,是否任何人都可以自由的创建或者删除页面?其实这不光是维基百科会设置管理员,只要有一定规模的线上论坛也都会设置管理员。回题,这个提案是用户可以申请永久半保护自己的用户页,所以我问了:谁、核、准?管理员可以批准某个用户是否需要半保护,还是行政员?别忘了,保护或半保护页面的原则都是在发生破坏之后才会实行,何以用户页就例外可以允许在未受破坏的情况下就半保护,提案里面并没有说啊。请记得,即便是用户页,它还是一个页面。如果我们同意用户可以申请永久半保护自己的页面,那么未来用户也可以申请半保护其他页面,因此,我说这不具体。规则不是不能改,而是“怎么改”。另外,“节约编辑者不必要的时间浪费”的理由和议案一类似,都是“整洁”、“节约”。试问,如果未通过此提案,对所谓的“编辑者”造成多长的不必要时间浪费?我刚看了WP:VIP,也不是整页都提报用户页被破坏,若以这种理由提案修改方针,个人认为都是不必要的。--秋意假发浓(我已关闭了所有通知,所以@我看不到)留言2015年11月7日 (六) 20:49 (UTC)
这回我明白了。您提出的问题已经远远超过了本议案讨论的范围,您应当新开议题讨论。本修改只是修改一个时间上限,和权限怎么执行这种深层次问题完全无关。为防止误会,我需要说明这句回复不是一句敷衍。您的提问已经涉及到哲学层面问题,我无力解答。可以肯定的是,本修改并不触碰这个问题,以前怎么做,以后就怎么做。Bluedeck 阿里君♥优酷酱 2015年11月8日 (日) 07:05 (UTC)
  • (+)支持第一部分,第二部分我觉得现在对预见性编辑的定义有问题,高争议条目被永久半保护一段时间之后竟然被解开,理由居然是保护已很长一段时间没有破坏,不能以预见还有破坏维持保护?这不当然的吗,就是因为保护了才没有破坏啊。见溥仪--浅蓝雪 2015年11月18日 (三) 00:49 (UTC)
    • user:浅蓝雪[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]虽然是在探讨界面用语时明确的,不过不限期并非永久,只是不确定何时解除罢了。Bluedeck Paris Attacks 2015年11月18日 (三) 19:47 (UTC)
      • user:Bluedeck[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]嗯,我好像有点看混了,如果第二部分只管全保护我支持。--浅蓝雪 2015年11月19日 (四) 19:16 (UTC)
  • 如果没有更多意见,预计于UTC-6的2015年12月2日(星期三)上午完成该议案的执行。Bluedeck 2015年11月27日 (五) 17:40 (UTC)

第四议案讨论区

内容:将Wikipedia:管理员解任投票页面中的方针部分剥离,合并到Wikipedia:管理员的离任。此番修改后,Wikipedia:管理员解任投票将变为纯粹的操作性页面。目前Wikipedia:管理员的离任页面较短,可以承受一定规模的扩充而不至于过于冗长。以上。现将本第四议案张贴于此寻求共识。Bluedeck 2015年11月3日 (二) 03:54 (UTC)


本议案执行完毕。Bluedeck Paris Attacks 2015年11月18日 (三) 19:48 (UTC)

Shwangtianyuan的派生议案讨论区

注:本段落留言标题、位置和格式曾经Bluedeck编辑:[1]Bluedeck 2015年11月3日 (二) 16:38 (UTC)

本人还有一个议案(第五议案),就是建议将维基百科:回退不过三原则并入维基百科:编辑战,不知道各位是否可以接受。--Shwangtianyuan正义必胜!和平必胜!人民必胜! 请严格遵守中国国旗模板使用规则 2015年11月3日 (二) 04:40 (UTC)
建议将维基百科:回退不过三原则并入维基百科:编辑战,因为“回退不过三原则”可以看成是“编辑战”的一部分。--Shwangtianyuan正义必胜!和平必胜!人民必胜! 请严格遵守中国国旗模板使用规则 2015年11月3日 (二) 04:42 (UTC)

谢谢SzMithrandir的统计。这个议案我也有考虑,虽然不在日程上。Bluedeck 阿里君♥优酷酱 2015年11月5日 (四) 04:51 (UTC)
  • (-)反对:3RR部分不等于编辑战。随便3RR也算破坏(上上方说的有理...)--Engle跃】 2015年11月4日 (三) 10:09 (UTC)

暂定共识

近日社群对此议题的讨论开始减少,故作此小结:

第一议案:通过
第二议案:无共识,意见分为同意合并,应扩充Wikipedia is not a dictionary,及降格为指引三种
第三议案:“声明全保护不用于高风险页面以外的预见性保护”已无反对意见;“允许用户请求无限期半保护其用户页面”则共识较弱
第四议案:无反对意见,应可通过
Shwangtianyuan的派生议案:否决

希望社群加紧讨论,在以上数项议案中达成最终共识。--Temp3600留言2015年11月9日 (一) 17:26 (UTC)

如11月16日前仍未有其他讨论,建议通过第一议案、第三议案第一部分、及第四议案。--Temp3600留言2015年11月10日 (二) 16:38 (UTC)
无反对但也无复议,建议第四议案重新挂出。 --达师 - 318 - 527 2015年11月16日 (一) 12:03 (UTC)
@bluedeck:意下如何?--Temp3600留言2015年11月16日 (一) 15:44 (UTC)
就这样更新好了。这也算冷门议案的标准结局了。继续摆在这只会一天天更冷。Bluedeck Paris Attacks 2015年11月16日 (一) 19:59 (UTC)
(+)支持:可以了吧,该说的都说清楚了,就行了。其他人没参与进来,要么是觉得太复杂,要么是觉得肌无力,累感不爱,算了。而且这个争议性很小了,几乎可以算是管理员内部的站务,执行吧。-- SzMithrandirEred Luin 2015年11月17日 (二) 01:22 (UTC)
@bluedeck:嗯嗯,bluedeck您去改吧。--Temp3600留言2015年11月17日 (二) 15:20 (UTC)
关于第三部分我还有话说。。--浅蓝雪 2015年11月18日 (三) 00:53 (UTC)
看见了,那第三部分就再搁一会儿。Bluedeck Paris Attacks 2015年11月18日 (三) 19:52 (UTC)

小作品的判定条件问题

汉化译名和直译译名的处理

外文重定向问题

现存或已删除的条目内文可以大量复制到使用者页面吗?

wp:删除守则等7篇文章移动

2015年12月13日最新提案

我将对维基百科:命名常规的内容作出一些小修订,主要是有关汽车车系的条目要注意的问题。具体内容为(放入“交通工具名称”一节):

另外,若要创建有关汽车车系的条目时,请加入普遍使用的车厂名称,以“车厂+车系名称”为标准格式,例如“本田思域”、“丰田卡罗拉”。不要加入合资车厂的名称,例如“东风日产天籁”、“上海大众桑塔纳”,以避免地域中心

请各位对此提出意见,谢谢!--Shwangtianyuan正义必胜!和平必胜!人民必胜! 请严格遵守中国国旗模板使用规则 2015年12月13日 (日) 08:04 (UTC)

(+)支持。不过,可以举个例吗?刚刚我找了几则条目,但是找不到有类似您说的命名情形。--Bowleerin留言2015年12月13日 (日) 08:54 (UTC)
我看不懂这两类区别……是说后面的改成“东风天籁”还是“日产天籁”、“大众桑塔纳”(“上海桑塔纳”不靠谱吧)?Liangent留言 2015年12月13日 (日) 13:41 (UTC)
向二位统一(:)回应一下:有些新用户(尤其是从百度百科转来的用户)在创建有关汽车条目的时候,因为不知道维基百科的命名常规(新人嘛),可能会使用“合资车厂名称+车系名称”作为其标题(我之前在百度百科上已经看到了“郑州日产NV200”这个词条,在维基百科上绝对不行),这样的话可能会出现地域中心。--Shwangtianyuan正义必胜!和平必胜!人民必胜! 请严格遵守中国国旗模板使用规则 2015年12月14日 (一) 06:17 (UTC)
这是预防性的提案吗,目前没有事例?不过不要加入合资车厂的理由,我认为是关注度。仅当“东风日产天籁”存在显著的关注度(排除“日产天籁”),且“日产天籁”不存在条目或日产天籁条目过长,才可以创建独立条目。--Gqqnb留言2015年12月14日 (一) 07:41 (UTC)
可以说的上是预防性的提案。--Shwangtianyuan正义必胜!和平必胜!人民必胜! 请严格遵守中国国旗模板使用规则 2015年12月14日 (一) 08:19 (UTC)
不觉得有什么必要。内容短的用关注度提删,内容长的说“通篇都在讲‘日产天籁’,不管‘东风’什么事”,可以移动改正成日产天籁。--Gqqnb留言2015年12月14日 (一) 08:26 (UTC)

有没有兴趣允许条目级CSS?

就是允许把一些css添加到特定条目。本来反复使用内联CSS(<font style="xxx">...</font>),如果改用统一的条目级CSS,条目大小可以减少,加快浏览器加载速度。技术上就是创建一个模板来填写这些css,然后把javascript加到全局JS文件里去,在条目加载完毕时javascript读取这些css加到document.styles里。这并不是技术问题,而是方针问题。现在好像没现成的模板吧?有一些铁路条目、列表类条目等,使用前景色、背景色、调整文字大小比较频繁,条目级CSS能减少条目大小。不过我也知道格式手册要求不要过于花俏,所以问问看大家的想法。--Gqqnb留言2015年12月14日 (一) 08:21 (UTC)

可以用class做,但问题是得有人整理。大小么反正现在都gzip,差不到哪里去的。开放用这个不现实,太容易被破坏了。--Jimmy Xu 2015年12月14日 (一) 08:23 (UTC)
mediawiki:common.css--百無一用是書生 () 2015年12月14日 (一) 09:26 (UTC)

论述既然没有效力,怎么可以衍生出相应的维护模板?

翻译条目须在Talk页标上{{Translated page}}

依据CC BY-SA及早期的GFDL授权方式,翻译条目必须给出原文作者。{{Translated page}}的存在就是给翻译作者一个方便,不知为何使用率极低。许多产量丰富的翻译编者都忽视了要给出来源网址及作者的姓名,我认为中文维基应当落实CC协议的精神,而不是众所周知是从某语言翻译过来,就忽略不标了。我们应当在相应的方针里写入这条规则。毕竟英文维基的东西还是那边作者所有的,我们翻译过来,MediaWiki可没有帮我们标注翻译前的作者是谁,需要手动标上才行。--Jasonzhuocn留言2015年12月12日 (六) 07:32 (UTC)

存量有多少?--Antigng留言2015年12月12日 (六) 09:00 (UTC)
先完善相关方针吧,维基百科:翻译守则,看看还有没有其他指引顺便一块改。搞定这个以后,再请翻译大户把自己翻译的作品给补上。不过从源头来说,这应当是MediaWiki的一个插件功能,给作者一个表单填入来自某个语言的某条目,自动在talk页加上模板。--Jasonzhuocn留言2015年12月12日 (六) 09:08 (UTC)

刘嘉一向都有使用这个模板,不过包括我在内,不加这个模板的翻译编辑也不在少数。而且这样做并没有强制性质,其实如果某条目在参加特色/优良条目评选、新条目推荐候选的时候就已经表明该条目是翻译条目和原文语种,早晚这个事实也是要在讨论页出现的,虽然这个模板能够提供原文的连结,而上述的方法不能。自己曾经因为没有在某翻译条目的讨论页使用这个模板而在DYKC被某编辑呛声,当时就是用这个理由回应(PS. 结果这条目因为被某编辑挞伐,而要强行结束第一次评选而卷土重来,结果到了第二次才能当选)。--春卷柯南夫子 ( ) 2015年12月13日 (日) 08:59 (UTC)

真希望可以让电脑来完成这件事。除了英文版之外,各大语言版应该都有类似功能需求。--Jasonzhuocn留言2015年12月13日 (日) 12:34 (UTC)
机器怎么知道一个条目是不是翻译的呢?--Antigng留言2015年12月13日 (日) 12:38 (UTC)
在机器没有强人工智能以前。至少可以设个界面,给机器来源语言、条目名称,可以再加个版本。剩下交给机器做,减少我们user的负担。这些就当我在许愿。--Jasonzhuocn留言2015年12月13日 (日) 12:43 (UTC)
用content translation的,我兴许可以做一个bot帮助添加模板。维基百科:机器人/申请/Antigng-bot/12--Antigng留言2015年12月13日 (日) 13:30 (UTC)
开了个小工具对CX翻译的页面添加此模板,可以考虑设置为默认启用。Antigng把先前翻译的页面跑一遍也不错。Liangent留言 2015年12月16日 (三) 22:43 (UTC)

这个模板有version参数,可以指定翻译页面的历史版本,也许在可供查证方面算是优点。--578985s留言2015年12月14日 (一) 07:09 (UTC)

喜欢version参数。我会在编辑摘要里写翻译自XX语维基,这样符合要求吗?--Gqqnb留言2015年12月14日 (一) 07:35 (UTC)
以前就写过摘要,维基用GFDL时期还得在摘要列出五位作者。--Jasonzhuocn邀请台湾人加入 Wikimedia Taiwan2015年12月15日 (二) 05:45 (UTC)
近期翻译的都会上version参数。——路过围观的Sakamotosan 2015年12月15日 (二) 09:23 (UTC)

再提跨语言链接清理

目前对于条目中不应有裸的跨语言链接(如[​[:en:Example|例子]])应已有共识,故在此提出将此种方式的链接在此批量替换为{{ilh}}的形式。如此一则显示效果更加友好,一则能得到才女的机器人在中文维基有相应条目时进行清理,一则在社群对跨语言链接有其他共识时方便实现。

有鉴于目前有维基人出于各种原因不喜欢使用此模板,在此提出一折衷方案,即清理时会暂时跳过在此串中表明此意之维基人所编辑的条目。

在此欢迎各位对此任务提出意见,且请针对清理任务本身,对{{ilh}}的显示效果如有不满还请另开段落。以上。--Jimmy Xu 2015年12月14日 (一) 08:12 (UTC)

绿链万岁!--祝维基百科生日快乐的Carrotkit 2015年12月15日 (二) 05:28 (UTC)

不用说了,全部改红链-- Billy talking to HK People贡献 2015年12月15日 (二) 07:36 (UTC)
甜咸之争还有红绿之争……--Antigng留言2015年12月15日 (二) 12:18 (UTC)
tooltip表示应战(其实关掉现在默认的绿链脚本不就完事了吗?)——路过围观的Sakamotosan 2015年12月16日 (三) 01:37 (UTC)
绿链好,绿链妙,绿链棒得不行了!--祝维基百科生日快乐的Carrotkit 2015年12月16日 (三) 05:37 (UTC)
tooltip大法好,退绿保平安。This is the war!——路过围观的Sakamotosan 2015年12月16日 (三) 06:15 (UTC)
CPU一耗天地灭,赶快退绿保平安。-- Billy talking to HK People贡献 2015年12月16日 (三) 23:53 (UTC)
绿链赛高!不但能给看客进行提示,还能避免维基人的红链强迫症。——萌萌哒CFSO6459留言2015年12月17日 (四) 00:28 (UTC)
+1 。--广雅 范 2015年12月17日 (四) 12:08 (UTC)
蓝连万岁!消灭绿连英语Green link红连!(XD - 和平、奋斗、救地球!(留言)自然条目提升地质灭绝专题2015年12月17日 (四) 14:08 (UTC)

提议合并三大人物信息框模板

—以上未加入日期时间的留言是于2015年12月29日 (二) 00:42 (UTC)之前加入的。

修订封禁方针,处置绕过封禁者的编辑和创建的条目

目前中文版的封禁方针大抵承袭自英文版,不过看来缺少了一个环节,就是如何处置绕过封禁者所创建的条目和进行的编辑。这事情的原因是最近某万恶的恶搞破坏者乱写劣质东南亚条目,真令人气炸。还有最近另一个恶搞破坏者在互助客栈披露他人个人资料,并与少壮派展开回退战的事件(我总觉得这两个人就是中文版有史以来行径最卑劣的两个破坏者)。

英文版的规定是这样的:

被封禁用户所进行或借助他人进行的编辑

任何人都可以随意回退任何违反封禁方针的编辑行为,不作另行通知,也不需要理会回退不过三原则。然而这并不表示这些编辑因为由被封禁用户完成,所以就一定要被回退(明显有益的改动,例如改正错别字和回退破坏,可以予以保留),不过在不确定情况的推定中(presumption in ambiguous cases),相关编辑则应予以回退。(按:没读过法律不肯定这个的意思)

相反,维基人不得按照被封禁用户的指示建立或编辑资料(这种行为有时会被称为代理编辑),除非他们能够证明这些改动有根据或有建设,并拥有进行相关编辑的个人理据。对于在相同的处境进行与被封禁编辑/账号的行为一致的行为的新账号和只是为了这个目的而编辑维基百科的人士,适用于他们模仿的编辑者的补救措施也适用于他们(参见有关傀儡及真人傀儡方针)。

借助回退的封禁实施

回退编辑的时候,要留意不要恢复违反中立、可供查证、生者传记等基本方针的资料。随后如果被封禁用户的编辑被某编辑恢复,恢复者则需为这些内容负上全责。

绕过封禁者新创建的条目不可能予以回退,因为根本就没东西可以回退,却是快速删除的适用对象。任何编辑都可以在这些条目中使用{{db-g5}}或{{db-banned}}模板(按:中文版G5只适用于按照页面存废讨论删除,后来重新创建的条目)。如果被封禁用户以外的其他编辑曾经该条目或其讨论页进行善意编辑,通知他们该页面由被封禁用户创建是一个有礼貌的做法。接着才视乎情况再决定善后安排。

我衷心希望这条能够过,不过我不可能那么独裁,而且英文版的状况也不一定适用于我们。所以请大家踊跃发言,提出意见。--春卷柯南夫子 ( ) 2015年12月19日 (六) 10:02 (UTC)

(!)意见应以现行的方针解决。--Temp3600留言2015年12月19日 (六) 16:08 (UTC)
  • 某些被封禁用户(例如影武者和Labstore)被封禁之前仍然是有建设的,不过这并不表示比他们建设更少、破坏更多的用户也要受到同等对待。虽然英文版有禁止个别编辑编辑个别题材的条目的安排,不过有鉴于中文社群的不成熟,一刀切又会对某些情节较轻的被封禁者不公道,不这样的话就会令妥善执行这个方针变得更困难(没有人会喜欢有人到自己家捣乱吧?)。--春卷柯南夫子 ( ) 2015年12月20日 (日) 06:33 (UTC)

建议对已有简繁重定向进行提删保护或者悬挂模板让使用者不要将其提删

如题,个人认为简繁重定向已有的不删,但不建立新的是共识。在存废讨论三番两次的提删耗费人力时间。另外建议使用手段禁止新建简繁重定向。-- M26パンーシン重戰車SCR-510Хорошо 中華民國 104年 2015年12月30日 (三) 15:50 (UTC)

(+)支持简繁重定向已有的不删,甚至应列为Wikipedia:快速保留之事项,删除简繁重定向会为转换系统带来技术风险,过往一向都有繁简重定向被提删但都会因技术原因而(○)快速保留之事例(如Wikipedia:页面存废讨论/记录/2015/08/22#简体中文就被User:Jimmy Xu速留了)。
不过,(-)反对禁止新建简繁重定向,反而应该积极建立,以避免潜在的技术问题发生在新条目上。(“不建立新的是共识”源自哪里?)--街燈電箱150號 开箱维修 抄表 检验证明 2015年12月30日 (三) 17:32 (UTC)
暂时别拆成两个讨论串分散讨论吧,都去WP:VPMLiangent留言 2015年12月30日 (三) 18:19 (UTC)

DYK 提名人能否撤去提名?

昨日@追迹未来Amazingloong两位在被投反对票后撤去了各自的 DYK 提名(见前者之编辑后者之编辑),而追迹未来更是未经重大修订便再次提报了他的条目。这样的情况在如今的 DYK 规则中似未被禁止。然而在下以为这是一种近于作弊的行为,理由有二:

  1. 假如提名人在落选前 1 秒删去提名,随后又重新提名。该条目本应以落选计,而再次提名则等同于延长了投票期限。(这里还没有讨论落选条目再次提交是否需要满足“重大修订”之“重大”的要求)
  2. 在被反对后撤去提名,又重新提名,无异于洗去反对票。

社群此前是否已见此类情况?是否需明确 DYK 提名不可中途撤销,或撤销则以落选计,并且再次提报需满足“重大修订”之要求?--Zetifree (Talk) 2015年12月27日 (日) 12:33 (UTC)

  • 我认为我推的条目被用不恰当的理由“故意刁难”了,沟通无果。我不高兴了,所以“参考前例”我不推了,甘愿败选。另,我同意Zetifree的观点,希望社群尽快做出规定。我赞成需满足“重大修订”之要求,不然和作弊刷掉反对票没有两样。--Amazingloong留言2015年12月27日 (日) 13:20 (UTC)

(!)意见,这种案例多的是,敝人也希望堵塞这个漏洞,不过我认为“撤销了便要视修订期中断”的做法又未免太过苛刻,那我也初步提议另一个框架:“若条目在符合资格的情况下由主编者提出撤销提名,则自撤销之日起计X天内,同一个主编者不得凭同一个条目再参与推荐”(敝人认为X=7),也许大家可以按此探讨其可行性。--街燈電箱150號 开箱维修 抄表 检验证明 2015年12月27日 (日) 18:49 (UTC)

  • 这在上次讨论修改DYKC规则时我就有提出了(见上面街灯大的连结),但当时的意思是就算失败只要修订其还在,可以无限提名,一来鼓励继续修正问题,二来也不认为会有人这么有毅力一直提名,若是游戏规则也可以封禁,所以最后并没有特别堵掉这个问题--Liaon98 我是废物 2015年12月28日 (一) 00:43 (UTC)
可以接受。但建议加一条:撤销提名时应将讨论存档,并于再次提名时给出链接。目的是尽量防止中国房价这样,没有经过有效修改,若之前的反对者没有注意到二次提名,则反对票被洗刷的情况。--Zetifree (Talk) 2015年12月28日 (一) 03:25 (UTC)
这个我觉得也许可以交给机器人来做。--街燈電箱150號 开箱维修 抄表 检验证明 2015年12月29日 (二) 16:27 (UTC)
机器人很难侦测那个编辑是“撤销提名”吧。其实有规则我相信大家都会遵守。--Zetifree (Talk) 2015年12月31日 (四) 15:37 (UTC)