跳转到内容

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

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

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

快捷方式

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

  • 如果您需要就具体条目应当如何编辑才符合中立性原則寻求社区共识，请前往條目探討留言。
  • 請在主題欄简明扼要地寫出問題主旨，不要使用如「新問題」等無意義的文字。
  • 請勿公開姓名、地理位置、電話、Email地址等联系資料。我們通常只在此頁回應，並不利用Email或電話等私下回應。
  • 無關維基百科專案的問題，請往知識問答相關頁面询問。


請注重礼仪、遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击 ）。


發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

10月25日之后没有新回應的议题會移动至相应的讨论页或存档。跳至本頁的：目錄 · 底端

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 引進CampaignEvents擴充功能 36 9 ZhaoFJx 2024-10-29 08:44
2 為管理人員任免制度檢討等事 139 33 Ericliu1912 2024-10-27 05:43
3 管理人員申請預討论（2024年9月） 119 32 Ericliu1912 2024-10-27 05:49
4 IPBEG選舉改革 19 10 ZhaoFJx 2024-10-28 08:39
5 提醒：互联网档案馆暫時無法使用 4 3 Ericliu1912 2024-10-27 05:51
6 Internet Archive已暫停多日 17 11 雪雨73 2024-11-03 10:29
7 在本地啟用安全投票及electionadmin权限 36 10 魔琴 2024-11-01 14:10
8 Category:使用创建条目精灵建立的页面是否应有机器人自动移除？ 3 2 忒有钱 2024-10-28 00:34
9 亚洲月2024 18 10 魔琴 2024-10-29 14:17
10 能否折叠一下存档 8 5 Miyakoo 2024-11-01 00:00
11 Globan ban request against User:Won1017 4 4 魔琴 2024-10-26 15:55
12 关于仲裁委员会职权的疑问 84 18 Borschts 2024-11-01 00:36
13 仲裁委员会候选人在站外个人群组拉票一事 40 14 Ericliu1912 2024-10-31 18:46
14 仲裁委员会退选程序 12 9 Ericliu1912 2024-10-31 18:39
15 Luce與全景自由 3 3 沈澄心 2024-11-01 22:17
16 关于2024年11月仲裁委员会选举效力的问题 16 6 0xDeadbeef 2024-11-04 01:47
17 有哪裡可以查看用戶所有編輯過條目的編輯後瀏覽次數統計表嗎？ 2 2 ZhaoFJx 2024-11-04 02:19
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注：（重新整理）

維基專題與協作

Template talk:Duck § 更正默認提示文字？

@Cookai1205、Yoyolin0409：參見 WP:DUCK。確有理由更改、去除「一望而知」字樣。冀達成共識。— 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2024年9月24日 (二) 02:18 (UTC)

删除所有的纯繁简重定向

本主題或以下段落文字，在討論結束後應存檔至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.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/其他&oldid=48038436”