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

维基百科,自由的百科全书
跳转至: 导航搜索

互助客棧消息发表 · 方针发表 · 技术发表 · 求助发表 · 条目探讨发表 · 其他 知识问答发表
快捷方式
WP:VPM
Breezeicons-apps-48-braindump.svg

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

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

請注重禮儀及遵守方針與指引,一般問題請至互助客栈/其他知识问答提出,留言后请务必签名(点击 Signature button from WikiEditor extension.svg )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 删除所有的纯繁简重定向 51 20 Bluedeck 2018-02-14 15:55
2 Citation needed的中譯 27 11 Leiem 2018-02-18 23:09
3 设置Topic名字空间的中文别名 37 10 星耀晨曦 2018-02-22 02:49
4 可否將現有的FA存檔統一重定向? 6 3 Z7504 2018-02-16 21:58
5 有关用户贡献中“滥用日志”一词的修改 27 15 Xiplus 2018-02-17 11:11
6 百万条目标志已开始投稿征集 25 15 Jane9306 2018-02-20 21:01
7 请求对User:台灣通過同婚了是否具有冒犯性进行评议 17 12 118.143.147.130 2018-02-20 00:24
8 建議將掛「存廢覆核」模板的編輯計入「添加刪除模板」標籤 2 2 Xiplus 2018-02-18 15:47
9 霧島聖解封Techyan事宜 11 8 Antigng 2018-02-18 23:48
10 广告项目 5 3 Bluedeck 2018-02-19 15:50
11 签名应不应该加两杠? 20 13 Sanmosa 2018-02-21 12:13
12 Category:引文格式1维护:未识别语文类型 1 1 Leiem 2018-02-19 10:17
13 建議停止使用Wikipedia:机器人/提议 1 1 Xiplus 2018-02-19 15:56
14 Wikipedia:已删除内容查询是否允许查询明显的人身攻击内容? 7 4 E8xE8 2018-02-21 21:00
15 有用户擅自删除讨论,如何处理? 2 2 Yhz1221 2018-02-22 05:18
更新圖例
最近1小時內
最近1日內
一週內
一個月內
逾一個月

删除所有的纯繁简重定向[编辑]

提议删除纯粹的繁简重定向,如哈薩克 => 哈萨克。这种重定向大多是早期(>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)
  • (-)反对:繁簡重定向屬於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)
我本来就是想说说新重定向的问题,这个讨论却向意想不到的方向发展了,(╯ ̄Д  ̄)づ╧═╧ 淺藍雪 2018年2月3日 (六) 14:12 (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)
不相关资源指的是dom树解析、动态渲染和外部资源DNS,处理和下载的时间。这些项目的时间有很多外部随机变量无法控制(比如解析dom树时CPU scheduler的行为),这个和条目长短不一定正相关,所以我说是无关变量,予以排除。Bluedeck 2018年1月28日 (日) 21:19 (UTC)
  • (=)中立,讀完以上的討論,本人覺得大量的繁簡重定向仍然有其必要性存在,不應全數刪除。--Janee談笑風生 2018年1月22日 (一) 09:24 (UTC)
  • (+)支持:既然已有字詞轉換系統,就毋須多餘的繁簡重定向。如果連地區詞轉換都可以仿效繁簡轉換處理的話,那就能省下更多的重定向。--M.Chan 2018年1月23日 (二) 03:43 (UTC)
  • (-)反对,月經性提議。Walter Grassroot留言) 2018年1月23日 (二) 03:47 (UTC)
  • (-)反对有时链接会出错,而且费事。--Ξぞ曱۩·💬· 2018年1月31日 (三) 20:46 (UTC)
  • (?)疑問:你们真nb,为什么老繁简redirect和新繁简redirect被混为一谈?  以及街灯的意思不是说新的也要建立吧?-- SzMithrandirEred Luin 2018年2月9日 (五) 20:41 (UTC)
"删除所有的纯繁简重定向"是要刪掉舊的吧。--Temp3600留言) 2018年2月10日 (六) 17:35 (UTC)
  • (-)反对,有時自动转换還是會出錯,例如鍾嶼晨事件在我建立繁體重定向之前使用繁體字根本無法連結到條目。--M940504留言) 2018年2月12日 (一) 15:43 (UTC)
    • 这种情况自然不在删除范围之内。有别的反对原因吗?Bluedeck 2018年2月14日 (三) 07:55 (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)
  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)
在下不敢僭稱古雅,但在下認為上述標籤,現代人看得懂,南方人看得懂,北方人看得懂,近代人也可猜到。118.143.147.130留言) 2018年1月29日 (一) 14:02 (UTC)
看得懂不代表合适,不支持此风气,目前某些方针行文也有此情况。--YFdyh000留言) 2018年1月29日 (一) 17:14 (UTC)
“老子写文爱这样,他人读文全靠猜”,对不? 囧rz...——路过围观的Sakamotosan 2018年1月30日 (二) 01:51 (UTC)
古風公文s:著作權法_(民國105年)s:第43/99/M號法令s:保護文學及藝術著作之伯恩公約,就不是現代中文?只有北方口語才是現代中文?
cwek閣下誤會了。溝通之前提為對方明白,所以在下強調現代人看得懂。
另,上述2,3,4號標示,連古風也稱不上。118.143.147.130留言) 2018年1月30日 (二) 11:54 (UTC)
{{非现代汉语}}要求現代標準漢語,而現代標準漢語是“白话文著作为语法规范与书面文体”。--YFdyh000留言) 2018年1月31日 (三) 02:57 (UTC)
  • 姑且「新文化運動」一下吧:本人提議如下:
  1. {{Fact}}用「來源欠奉」。此用於:內容缺乏來源,所以請求來源。
  2. {{Verify source}}用「來源不符」。此用於:內容與其所引據可能不符。
  3. {{Verify_credibility}}用「可疑來源」。此用於:引據之來源有可疑,如非官方fb、Youtube等。
  4. {{Third-party-inline}}用「查無佐證

」。此用於:來源無佐證,需要第三方引證。 以上應該算是白話文了。如仍有文言文,那就抱歉了。「嶺南之地多古風,單音節詞即文言」。— 留言莫生氣 2018年2月9日 (五) 09:40 (UTC)

  • 如語意有差,那就更抱歉了。本人也是一知半解。— 留言莫生氣 2018年2月9日 (五) 09:42 (UTC)
  • 个人对“欠奉”、“故請求之”等的观感是古风,所以较不接受用于正式条文。“問題來源”有“此问题(设问)的来源”的歧义,不佳。另,目前没有要做修改的迹象。--YFdyh000留言) 2018年2月9日 (五) 14:36 (UTC)
  • @YFdyh000:看來粵語本身的古風太重了欸:現在香港也頗常用「欠奉」一詞。另:對各個模板的描述的建議也修改了一下。— 留言莫生氣 2018年2月10日 (六) 00:08 (UTC)
  • 此等標籤需用寥寥數字,就言簡意賅地傳情達意,以免佔用太多正文空間;所以應使用簡明扼要之單音節詞,所以帶有古風。
現代公文及法律條文使用古風中文,絕非文言文。118.143.147.130留言) 2018年2月10日 (六) 18:46 (UTC)

「觀感古風」是否原創研究?如此,模板上的「閱 論 編」又是否需要改為「查看、討論、編輯」?又例如,上面的「另:」又是否要改為「另外:」?「不合」又是否要改作「不符合」? 話說回來,我這一句的「是否」又要不要改為「是不是」?欠奉是古風我也沒有甚麼可說了。JC1 2018年2月11日 (日) 11:47 (UTC)

“观感”就是仅为个人意见。个人倾向是正式(非讨论)语句中尽量避免。如果空间和习惯足够,并不反对,且{{Navbar}}的默认非迷你版本是全称。--YFdyh000留言) 2018年2月12日 (一) 01:42 (UTC)
  • 在下所想正好相反。正式語句,包括條目首段及方針,應使用簡明扼要之古風中文,就如現代公文法律條文
內文使用單音節詞或雙音節詞皆可,視乎如何令讀者容易明白。
討論則可隨意使用廣泛認知之地區口語,例如,老婆老公,搞掂/搞定,靚女,啥,甭,咱。118.143.147.130留言) 2018年2月12日 (一) 11:00 (UTC)
值得参考。不过个人还是认为过于精要不易于理解阅读,还要出白话文解释,如同法律解釋。条目首段更应追求简明清晰,但不是精要。--YFdyh000留言) 2018年2月12日 (一) 17:07 (UTC)
    • 建议维持现状。另外,如果需要改,可以让用户设置自己喜好的叫法?(类似简繁转换,自己想用哪种用哪种)--Leiem留言) 2018年2月18日 (日) 15:09 (UTC)

设置Topic名字空间的中文别名[编辑]

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

我打算通过直接修改Flow扩展来得到一个中文名字空间,需要进一步的讨论。——꧁༺星耀晨曦༻꧂留言) 2018年1月31日 (三) 01:24 (UTC)

我发现从修改Flow扩展入手不能得到一个可以繁简转换的名字空间的名称,还是直接设置topic别名吧。——꧁༺星耀晨曦༻꧂留言) 2018年1月31日 (三) 08:33 (UTC)

如果一周后无人提出反对意见,则报请P站增设Topic名字空间的中文别名为话题。——꧁༺星耀晨曦༻꧂留言) 2018年2月3日 (六) 17:06 (UTC)

en:Wikipedia:Featured Topics如何区分? --达师 - 370 - 608 2018年2月5日 (一) 13:35 (UTC)
我觉得应该没人会把维基百科:特色话题和Topic:(话题:)扯上关系吧。——꧁༺星耀晨曦༻꧂留言) 2018年2月5日 (一) 18:14 (UTC)
另外设置alias在技术版提出可能更合适。 --达师 - 370 - 608 2018年2月5日 (一) 13:36 (UTC)
了解。——꧁༺星耀晨曦༻꧂留言) 2018年2月5日 (一) 18:14 (UTC)

(&)建議会话,因为topic是flow页的对话南极熊爱吃企鹅冰块 2018年2月7日 (三) 03:38 (UTC)

如果一周后无人提出反对意见,则报请P站增设Topic名字空间的中文别名为会话。——꧁༺星耀晨曦༻꧂留言) 2018年2月7日 (三) 08:35 (UTC)
我幾乎很少聽到有人使用會話這個詞,我比較偏好使用話題。--Xiplus#Talk 2018年2月8日 (四) 12:55 (UTC)
虽然话题较会话更常用,但似乎“会话”更准确,几人的交谈,并不一定局限于一个话题。但如果倡导开一个话题只交谈一件事(无法强制;知识问答等公共区域应如此),则话题更好。--YFdyh000留言) 2018年2月8日 (四) 16:45 (UTC)
@YFdyh000:恐怕我更愿意支持使用话题,会话一词至少在大陆地区更倾向用于翻译session,也就是操作系统界面的会话,而不像是讨论系统。--Liuxinyu970226留言) 2018年2月9日 (五) 02:24 (UTC)
还是有的,聊天会话、临时会话。“对话”也许不错。突然发现好像看错了,@南极熊:“因为topic是flow页的对话”是什么意思,为什么话题转到“flow页”了,不是在说“Topic”的别名吗。--YFdyh000留言) 2018年2月9日 (五) 02:47 (UTC)
flow页在Topic名字空间之下。——꧁༺星耀晨曦༻꧂留言) 2018年2月9日 (五) 08:54 (UTC)
谢谢,我将Topic(话题、主题、议题)和Portal(主题,也可但未称专题)记混了。--YFdyh000留言) 2018年2月9日 (五) 14:32 (UTC)
可以同时设置多个名字空间的别名来着的。——꧁༺星耀晨曦༻꧂留言) 2018年2月9日 (五) 13:20 (UTC)
  • (+)支持中文名。Z23168春節與花蓮地震 2018年2月9日 (五) 10:36 (UTC)
  • 我認為話題較佳。--Janee慶祝寒假開始! 2018年2月10日 (六) 14:03 (UTC)
  • @星耀晨曦:7天已過,應已通過,請檢查下,Face-smile.svg謝謝你--Z7504非常建議必要時多關注評選留言) 2018年2月11日 (日) 08:53 (UTC)
    • 不是有用户认为会话也可以的吗。@YFdyh000:。——꧁༺星耀晨曦༻꧂留言) 2018年2月11日 (日) 12:47 (UTC)
      • 主要依照標題「設置Topic名字空間的中文別名」來判斷應已通過,如不符合請自行修正--Z7504非常建議必要時多關注評選留言) 2018年2月11日 (日) 12:49 (UTC)
        • 主要是有别的意见出现(虽然不是反对意见)。应该让讨论再延续几天。——꧁༺星耀晨曦༻꧂留言) 2018年2月11日 (日) 12:53 (UTC)
          • User:星耀晨曦為了避免爭議,還是先繼續討論後,如有共識再自行發佈公告期--Z7504非常建議必要時多關注評選留言) 2018年2月11日 (日) 12:56 (UTC)
            • 设置Topic的中文别名已经有共识了,目前在于设什么名字有点分歧(虽然不能叫分歧,因为可以设置多个别名)。——꧁༺星耀晨曦༻꧂留言) 2018年2月11日 (日) 12:59 (UTC)
              • 別名設啥我不在意,我在意的是最主要的顯示名稱是啥?--Xiplus#Talk 2018年2月11日 (日) 14:44 (UTC)
                • 似乎没有很明显的变化。URL里页面的topic前缀也不会变成“话题”。监视列表的topic也不会变成话题。顶多就是在搜索或者写内链的时候,话题和topic是等效的。——꧁༺星耀晨曦༻꧂留言) 2018年2月12日 (一) 07:58 (UTC)
                  • 如果不是修改頁面原始名稱(即如同網址顯示或頁面資訊裡的顯示標題),我就沒意見了。--Xiplus#Talk 2018年2月12日 (一) 09:14 (UTC)
      • 不反对“话题”。“话题”为默认显示可能更无争议,设置“会话”、“对话”等别名也无意见。--YFdyh000留言) 2018年2月12日 (一) 01:36 (UTC)

如果3天后没有反对意见,则将“设置Topic名字空间的别名为话题”报请Phab。——꧁༺星耀晨曦༻꧂留言) 2018年2月12日 (一) 12:15 (UTC)

題外話:為何主題:首頁仍是紅鏈?--M.Chan 2018年2月13日 (二) 03:37 (UTC)
这是我的锅:) 设置Portal名字空间的别名的patch预计在2018-02-14 18:00–19:00 UTC部署到生产集群上。——꧁༺星耀晨曦༻꧂留言) 2018年2月13日 (二) 05:19 (UTC)
由于我的失误,这个错误的patch被回滚了。正确的patch将于下一个窗口期部署(2018-02-15 19:00–20:00 UTC),我很抱歉。——꧁༺星耀晨曦༻꧂留言) 2018年2月14日 (三) 19:46 (UTC)

3天已过,无人反对。已经提交任务到phab。——꧁༺星耀晨曦༻꧂留言) 2018年2月16日 (五) 13:42 (UTC)

完成——꧁༺星耀晨曦༻꧂留言) 2018年2月21日 (三) 18:49 (UTC)

可否將現有的FA存檔統一重定向?[编辑]

如題,FA現名為典範,然而在FA存檔頁顯示現有的FA條目時,還有一些條目開頭為「維基百科:特色條目/xxx」,應統一名稱為「維基百科:典範條目/xxx」,故提交討論--Z7504非常建議必要時多關注評選留言) 2018年1月31日 (三) 06:44 (UTC)

這個找個機械人弄應該很快處理好。--J.Wong 2018年1月31日 (三) 10:27 (UTC)
為何要統一?過去通過的仍然是特色條目啊,留著舊的有何不好?技術問題?--Xiplus#Talk 2018年1月31日 (三) 11:34 (UTC)
  • 兩位,直說吧,因為舊有的特色條目並不會顯示出典範條目的存檔;典範條目的存檔也不會顯示原有的特色條目存檔。所以應將現有的特色條目存檔皆重定向至典範條目存檔,且往後存檔都應如此 囧rz...--Z7504非常建議必要時多關注評選留言) 2018年2月7日 (三) 07:58 (UTC)
    • User:Z7504在哪個/些頁面不會顯示?--Xiplus#Talk 2018年2月16日 (五) 13:50 (UTC)
      • 恩,有一些是有將特色重定向至典範了,不過還沒全部處理掉--Z7504非常建議必要時多關注評選留言) 2018年2月16日 (五) 13:58 (UTC)

有关用户贡献中“滥用日志”一词的修改[编辑]

近期有几位用户(包括在下)反映,用户贡献中的“滥用日志”一词有些不妥。“滥用日志”和“防滥用过滤器日志”有着严重的意义分歧;“滥用”一词带有贬义,而亦有新用户表示每次看到“滥用日志”时会觉得紧张和不适,误认为自己的编辑有疏漏。现征求社群意见,希望社群能考虑“滥用日志”的替代用词。--Innocentius Aiolos 2018年2月6日 (二) 01:46 (UTC)

个人的建议是“过滤器日志”。--Innocentius Aiolos 2018年2月6日 (二) 01:46 (UTC)
(+)支持燃 灯巡查傀儡 2018年2月6日 (二) 01:50 (UTC)
(+)支持--NHC、才不是NPC呢哼!。:.゚ヽ(*´∀`)ノ゚.:。 2018年2月6日 (二) 02:00 (UTC)
(+)支持 过滤器日志 Bluedeck 2018年2月6日 (二) 06:59 (UTC)
(+)支持--YFdyh000留言) 2018年2月6日 (二) 10:25 (UTC)
如果得到共识,应当在此处(简体翻译)此处(繁体翻译)更改翻译。——꧁༺星耀晨曦༻꧂留言) 2018年2月6日 (二) 09:04 (UTC)
谢谢你!--Innocentius Aiolos 2018年2月6日 (二) 14:40 (UTC)
@星耀晨曦:英文為Abuse log而非Filter log,如要修改建議只修改本地,反對至translatewiki修改。--Xiplus#Talk 2018年2月10日 (六) 04:54 (UTC)
emmm。我对修改哪里没有偏向。——꧁༺星耀晨曦༻꧂留言) 2018年2月10日 (六) 09:32 (UTC)
(+)支持修改。另一个建议是改为“编辑过滤器日志”。--Tiger(留言) 2018年2月6日 (二) 12:05 (UTC)
易误解为动词的“编辑”。--YFdyh000留言) 2018年2月7日 (三) 09:40 (UTC)
啊,没错。--Tiger(留言) 2018年2月10日 (六) 06:54 (UTC)
支持「過濾器日誌」。--J.Wong 2018年2月6日 (二) 14:04 (UTC)
(+)支持有道理。Abacn留言) 2018年2月7日 (三) 00:16 (UTC)
(+)支持“过滤器日志”,总感觉“滥用日志”这个词怪怪的。--暗中观察的RabbitMeow 与兔喵对话 風の辿り着く場所 2018年2月7日 (三) 03:01 (UTC)
(+)支持 新方案过滤器日志,并且顺序为日志-封禁日志-过滤器日志
(+)支持改为“过滤器日志”或“编辑过滤器日志”。--Lanwi1(留言) 2018年2月8日 (四) 01:11 (UTC)
(+)支持(▲)同上Lanwi1 --云间守望 2018年2月8日 (四) 05:01 (UTC)
即无反对意见,公示7日之后进行修改...--Innocentius Aiolos 2018年2月9日 (五) 19:13 (UTC)
话说,这个修改应该去translatewiki吧? --达师 - 370 - 608 2018年2月14日 (三) 10:23 (UTC)
User:hat600英文為Abuse log而非Filter log,建議只修改本地。--Xiplus#Talk 2018年2月14日 (三) 11:46 (UTC)
我不认为一定要逐字对应。 --达师 - 370 - 608 2018年2月15日 (四) 16:15 (UTC)
translatewiki修改不須經過本地討論(translatewiki可能有自己一套翻譯的準則?不是很清楚),但本地既然有共識,同時避免translatewiki修改影響本地,建議在本地建立頁面。--Xiplus#Talk 2018年2月15日 (四) 23:53 (UTC)
公示已达7天,时间到后在本地页面进行更改至“过滤器日志”(滥权日志)。--Innocentius Aiolos 2018年2月16日 (五) 14:53 (UTC)
已改,補一個:Abusefilter-log-search。translatewiki想改個自己去吧。--Xiplus#Talk 2018年2月17日 (六) 00:15 (UTC)
+Abusefilter-log-linkoncontribs-text、Right-abusefilter-log、Right-abusefilter-log-detail、Right-abusefilter-hidden-log、Right-abusefilter-hide-log。--Xiplus#Talk 2018年2月17日 (六) 03:11 (UTC)

百万条目标志已开始投稿征集[编辑]

在这里投稿

  • 预计4月就到1000000了,已经五年没有标志了,1000000总要做一个吧南极熊爱吃企鹅冰块 2018年2月7日 (三) 04:36 (UTC)
  • 自动更新
  • 里程碑估計:(條目數最後更新:2018年2月21日 21:20 UTC,清除缓存
  • 中文维基百科自完成990,000条条目當日(2018年2月6日)截至今日(2018年2月21日),共用15天完成2,938条条目,平均每天增加195条,預計將於36天後(2018年3月29日)完成1,000,000条条目。
  • 中文维基百科自完成950,000条条目當日(2017年7月8日)截至今日(2018年2月21日),共用228天完成42,938条条目,平均每天增加188条,預計將於37天後(2018年3月30日)完成1,000,000条条目。
  • 中文维基百科自完成900,000条条目當日(2016年9月10日)截至今日(2018年2月21日),共用529天完成92,938条条目,平均每天增加175条,預計將於40天後(2018年4月2日)完成1,000,000条条目。
  • 中文维基百科自完成500,000条条目當日(2012年7月14日)截至今日(2018年2月21日),共用2048天完成492,938条条目,平均每天增加240条,預計將於29天後(2018年3月22日)完成1,000,000条条目。
  • 中文维基百科自正式成立(2002年10月24日)截至今日(2018年2月21日),共用5599天完成992,938条条目,平均每天增加177条。以此標準推算:

流程[编辑]

  • 公告栏公示及投票决定是否通过及发表意见:2.7至2.19投票,随时发表意见
  • 投稿(可与发表意见同时):2.10至3.1
  • 评选:3.1至至条目数达999000当日23:59 (UTC+8)
    • 评选投票规则:自动确认用户才能投票,票数最多的获胜
  • 预计4月上旬到1000000(以二月初速度统计)南极熊爱吃企鹅冰块 2018年2月7日 (三) 13:38 (UTC)

意见[编辑]

  • (+)支持:可以先擬定大概的流程,例如投稿期、評選期的長度等。--【和平至上】💬📝 2018年2月7日 (三) 09:15 (UTC)
  • (+)支持,同和平至上。--Janee慶祝寒假開始! 2018年2月7日 (三) 10:16 (UTC)
  • (+)支持,同上。--暗中观察的RabbitMeow 与兔喵对话 風の辿り着く場所 2018年2月7日 (三) 13:40 (UTC)
  • 雖然此前禁止改作維基百科標誌的問題已經得到解決,但是我不贊成樓主倉卒的做法。首先應該通知大家,我們要進行這項討論,將進行投票,選出紀念標誌。投票日期你們自己決定,但是至少應該設一個三天通知期,甚至一兩個星期的醞釀階段。反正中文版條目數不會在一個星期內衝破一百萬大關。--春卷柯南歡迎客官刻石留名 ( ) 2018年2月7日 (三) 13:52 (UTC)
(!)意見:我建議將評選期改成到達999000條目的當天23:59(UTC),因為確切時間較難考證,免得起爭議,而且最好規定自動確認用戶才能投票。另外是一輪制簡單多數制的投票嗎?--【和平至上】💬📝 2018年2月7日 (三) 15:24 (UTC)
我把北京時間改成了UTC+8,比較容易理解。--【和平至上】💬📝 2018年2月8日 (四) 09:40 (UTC)
  • “也许我们应该放点摇滚庆祝一下”。很久没见过改logo了,然后给100W条目的创建者们放点摇滚送点什么?——路过围观的Sakamotosan 2018年2月8日 (四) 00:55 (UTC)
  • (+)支持:為維基帶來新氣象吧!— 留言莫生氣 2018年2月8日 (四) 12:13 (UTC)
  • (+)支持,同和平至上。--Lanwi1(留言) 2018年2月8日 (四) 16:23 (UTC)
    • (+)支持同和平至上和Sanmosa--云间守望 2018年2月8日 (四) 16:29 (UTC)
  • (+)支持(&)建議不知道的維基人可以去參考先前參與每10萬為單位來設計logo或者簽名都是怎麼用的--Z7504非常建議必要時多關注評選留言) 2018年2月8日 (四) 16:35 (UTC)
  • (+)支持。上面Z7504提到的可以到Wikipedia talk:維基百科標誌/2012年特别標誌參考以前的評選方式、Wikipedia:維基百科標誌#中文維基百科歷年特別標誌則有之前的特殊logo。--S099001留言) 2018年2月12日 (一) 09:59 (UTC)
  • (+)支持。中文维基百科具有1兆条目是个好事情。--伤心CuSO4 2018年2月17日 (六) 12:34 (UTC)
  • (+)支持符合DYK標準有必要設置特殊標誌Z23168春節 2018年2月18日 (日) 13:56 (UTC)

除了標誌以外[编辑]

畢竟是一百萬條啊一百萬條,除了修改標誌,是否有其它活動? -KRF留言) 2018年2月10日 (六) 01:52 (UTC)

  • 說ㄚ,還是各位要把首頁換一個版本XDSmiley.svg--Z7504非常建議必要時多關注評選留言) 2018年2月10日 (六) 06:02 (UTC)
    • 首页更新的讨论需要很长时间,已经来不及了。 --达师 - 370 - 608 2018年2月11日 (日) 08:37 (UTC)

問個問題[编辑]

我有設計標誌的意願,請問字體一定要是free font嗎?--Janee慶祝寒假開始! 2018年2月14日 (三) 08:59 (UTC)

  • 自己随意选。欢迎设计。祝大家新春快乐Happy New Year! 2018年2月15日 (四) 01:47 (UTC)
    • 不用free字型不會有著作權之類的問題嗎?--S099001留言) 2018年2月15日 (四) 02:33 (UTC)
U:S099001,對啊?--Janee慶祝寒假開始! 2018年2月18日 (日) 10:13 (UTC)
那就用free吧Happy New Year 2018 新春快乐 2018年2月19日 (一) 00:14 (UTC)
free有啥可用?--Janee慶祝寒假開始! 2018年2月20日 (二) 13:01 (UTC)

请求对User:台灣通過同婚了是否具有冒犯性进行评议[编辑]

先前讨论参见:User_talk:台灣通過同婚了

User:Lanwi1最初以“误导性用户名”封禁,后称封禁理由改为“冒犯性用户名”。但是Wikipedia:用户名方针中并未提及此类用户名的封禁。 接着Lanwi1指之前方针中存在“维基百科不允许使用具有煽动性的名字。这包括具有冒犯性的名字——粗俗或过于表露的术语,用来吸引注意或会引起破坏的名字”的语句。可是这个用户名并不包含“粗俗或过于表露的术语”。在他的解释中,此用户名宣扬特定立场,会冒犯到其他编者[谁?]

请协助评议一下两点:

  1. 是否需要在Wikipedia:用户名增设(或恢复)“冒犯性用户名”章节?
  2. 此用户名是否具有冒犯性?

谢谢。--Kuailong 2018年2月8日 (四) 01:03 (UTC)

以下为个人意见:

  1. 在定义“冒犯性的用户名”时,应该考虑这样的冒犯是否具有普适性以及用户在注册账号时是否有冒犯意图。那么从普适性上来说,“同婚”显然不可能冒犯所有人——LGBT、pro-LGBT及无态度的人群都不会觉得这是冒犯。从用户在注册账号时是否具有冒犯意图来说:首先我们没有读心能力,我们不知道这个用户是否在意于冒犯anti-LGBT的人群;其次这个用户名并未带有亵语,也不能duck出用户有冒犯他人的故意;再次,考虑善意推定,在无证据的情况下,假定用户在注册账号时没有冒犯他人的故意是最符合善意推定的。
  2. 按照基金会非歧视方针,针对“员工或承办商”的“性别、性别认同、性别表现、性倾向”的歧视均被禁止(早期的非歧视方针中曾经禁止了针对用户的歧视[2])。退一万步说,哪怕WMF在修改政策后模糊了针对用户的“性别、性别认同、性别表现、性倾向”的歧视,也可能只是出于言论自由的容忍,而非有意鼓励歧视。同样的,在文明方针中,对用户性取向的攻击也是被认为是“相当严重的不文明行为”的。因此,在WMF方针禁止性倾向歧视与本地方针亦保护用户性取向的大前提下,以“冒犯”为由封禁名为“台灣通過同婚了”的用户,似乎不太与基金会及维基百科的精神相容吧?
  3. 封禁管理员提及了英文维基百科的方针,然而,请评价英文维基百科用户Samesexmarriage101为何未被以相同原因封禁?该用户存在不少编辑贡献,也早早地就被管理员tedder留意到过。

以上。--菲菇维基食用菌协会 2018年2月8日 (四) 02:30 (UTC)

相信如果採用冒犯一詞,甚麼獨立甚麼統一全部都需要封禁了。現在的「侮辱性用戶名」還不足夠嗎?所以第一項不必。由此引申,冒犯不具問題,用戶名有冒犯又如何?建議解封--JC1 2018年2月8日 (四) 03:45 (UTC)
  • 感到有些过了,他名字又不是“支持同性恋”--苞米() 2018年2月8日 (四) 04:02 (UTC)
    • 即便是“User:支持同性恋”我觉得也没什么大碍,现在社会并没有以前那么保守。--Leiem留言) 2018年2月18日 (日) 15:16 (UTC)
      • 这与社会认可关系不大,是用户名/签名是否持特定立场,是否会不利于社群协作,以及如何对待。--YFdyh000留言) 2018年2月18日 (日) 15:30 (UTC)
  • 个人提示:这件事情上,不要拿基金会方针说事情,基金会非歧视方针只限制基金会雇员,Lanwi1恐怕不是基金会雇员也不是基金会承办商雇员。
    个人观点:虽然我不反对同婚,对我而言不是冒犯的;但是我认为,这对于维基百科上不在少数的不支持同婚的人造成了很大的冒犯,的确会让他们之间的沟通变得困难。
    --云间守望 2018年2月8日 (四) 04:08 (UTC)
    • 请问你是怎么从这个用户名推导出特定立场的?“同婚”这个词明明就是中性的。用户名并不是“支持通过同婚”或“反对通过同婚”,只是你脑补出了支持同婚的意味,这样没有扩大解释之嫌吗?--Kuailong 2018年2月8日 (四) 05:52 (UTC)
  • 在我看來,這就像是取了一個叫User:香港一地兩檢的名稱,這名稱只是一個地名加上術語,沒有表達支持或反對,對於部分香港編輯來說可能有些敏感,但也只是「有些敏感」而已。「台灣通過同婚了」這名稱也是如此。 -KRF留言) 2018年2月8日 (四) 05:57 (UTC)
  • 身為台灣人,我是個人看不出來有冒犯之意。--Outlookxp留言) 2018年2月8日 (四) 06:29 (UTC)
  • 一句中立的事實陳述。如果有一個用戶名是User:我是同性戀者又是不是冒犯?--Nivekin請留言 2018年2月8日 (四) 06:37 (UTC)
  • 註:此處原有文字,因為泄露个人隐私,已由云间守望於2018年2月8日 (四) 18:07 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。
  • User:台灣通過同婚了之用户名,依本人之個人意見,不應被封。即使之後有机会有User:香港通過同婚了,也一樣(當然:你也可以說User:香港通過同婚了會讓人以為他是User:台灣通過同婚了,具誤導性,然後封了)。— 留言莫生氣 2018年2月8日 (四) 12:12 (UTC)
  • 个人观感是不太得当,有轻度的冒犯性/宣传倡导意味,会不利于编辑协作,但并未违反中文维基现有的用户名方针,冒犯性名称也可能尚无共识。表达立场在用户页比较得当。如果有“User:海地禁止同婚了”,是否同样得当,因此带来用户名大战和敌视实在无益。--YFdyh000留言) 2018年2月8日 (四) 17:06 (UTC)
    • 請說明此用戶名哪裡有宣導、冒犯或表達立場。-KRF留言) 2018年2月8日 (四) 21:05 (UTC)
      • 对于此类用户名,个人观感和理解是宣传、表达或倡导一个情况或立场,而不是单纯一个描述性或代表个人的用户名。Wikipedia:用户名:“如您不希望使用的真实姓名,请选择一个您自己和别人都觉得舒服的用户名,而且此用户名亦不应该影响该维基计划的运作。一个有争议的用户名或会予人坏的印象,因此请避免注册这些用户名。”,从上面以及封禁申诉的讨论看,对此类用户名的观感是有争议的。--YFdyh000留言) 2018年2月9日 (五) 00:39 (UTC)
  • 在下認為,如有用戶名是「我是同性戀者」或「我已同婚了」,屬個人選擇。「台灣通過同婚了」有代表台灣慶祝之觀感。118.143.147.130留言) 2018年2月19日 (一) 16:24 (UTC)

建議將掛「存廢覆核」模板的編輯計入「添加刪除模板」標籤[编辑]

目前「添加刪除模板」標籤僅限於添加頁面存廢討論或快速刪除模板,但其實在現存頁面加入「存廢覆核」模板也算是提刪的一種,故建議將掛「存廢覆核」模板的編輯計入「添加刪除模板」標籤。--M.Chan 2018年2月13日 (二) 08:58 (UTC)

已加入。--Xiplus#Talk 2018年2月18日 (日) 07:47 (UTC)

霧島聖解封Techyan事宜[编辑]

@AntigngWP:存廢覆核請求中提到了@Techyan在未掛速刪模板的情況下,速刪了不少重定向,有違規定,並且作出了封禁,可是在Techyan未有作出封禁申訴或任何解釋的情況下,不出半小時便由@霧島聖解封,理由是「未见techyan对有关条目进行R3等删除的处理有任何问题」。然而,速刪未掛有速刪模板的頁面顯然屬於違反wp:CSD的行為,亦違背了WP:管理員的避嫌原則,我希望霧島聖公開解釋一下解封的原因。謝謝。—AT 2018年2月15日 (四) 05:11 (UTC)

有意思了。--酷爱龙 2018年2月15日 (四) 15:36 (UTC)
L.JC1 2018年2月16日 (五) 08:44 (UTC)
所以为什么需要一个解封的公告板了。 囧rz...估计雾岛又很忙了→_→——路过围观的Sakamotosan 2018年2月16日 (五) 10:31 (UTC)
建议User:霧島聖解释此事。这件事会给人很大的遐想空间。--Eyewitness Tsai与我谈笑风生?) 2018年2月16日 (五) 14:54 (UTC)

(!)意見不要互煮Happy New Year 2018 新春快乐 2018年2月17日 (六) 08:34 (UTC)

  • 不是要互煮,只是這樣的爭議性操作,我覺得當事人有責任解釋一下。—AT 2018年2月17日 (六) 08:57 (UTC)
  • 當事人已經在我的討論頁作出解釋,各位可以參看一下,謝謝。—AT 2018年2月17日 (六) 10:59 (UTC)
  • 当事人解释了那我就回应一下吧。涉事用户被封禁不是因为他删了我认为不该删除的快速删除,这在我看来不是一个大问题(当然严格依方针仍然是个大问题,毕竟依车轮战方针,切勿于另一名管理员反对的情形下执行管理操作,应透过沟通解决管理争议)——如果这些页面在我保留之后,另一个用户再度提出快速删除,涉事用户做出删除的决定,那么这种行为本身并没有严重违反方针,也不至于封禁。如果事情果真如此,那么完全可以透过DRV进一步解决删除争议。涉事用户被封禁,是因为他在没有其他用户提出快速删除——换言之,页面没有挂快速删除模板的情形下快速删除了20多个页面。这种行为则与快速删除方针明显违背,且没有主观的余地——如果说判断条目是否合乎快速删除的标准有一定的主观性,页面挂模板没有则是完全客观的。再加上当事人知道快速删除方针的有关要求,我认为没有进一步警告涉事用户的必要。--Antigng留言) 2018年2月17日 (六) 13:15 (UTC)
  • @Antigng:对方提到了避嫌,您认为在这起事件中您是否应作为普通用户参与呢(提报VIP什么的)燃 灯巡查傀儡 2018年2月18日 (日) 00:36 (UTC)
    • 我从两个角度回答一下这个问题:
    • 第一,避嫌原则指出,管理员不得在一项事宜中同时扮演普通用户和管理员双重角色,具体到封禁的问题上,管理员不得因为仅反对某个用户的意见而对他执行封禁。确实,快速删除的部分条款没有完全客观的标准,一个管理员选择保留,另一个选择删除,是一种编辑争议,而我以普通用户身份参与了这一争议。然而,“条目是否符合快速删除的标准”和“快速删除条目时,是否应当确保条目挂上CSD模板”是两个独立的问题,我确信自己只以普通用户的身份参与了前者,而没有参与后者。我从未参与有关快速删除前是否该挂模板的讨论,也从未就挂模板的问题和涉事用户产生编辑争议。而封禁的理由只与第二个问题有关,与第一个问题无关,无论我对第一个问题持何种立场,都不会影响对第二个问题的判断。因此,我认为这一封禁没有导致我在在一个问题上同时扮演普通用户和管理员的双重角色。打个比方,如果A管理员和B用户在页面X中发生了编辑争议,而B用户则在回退的摘要中对C出言不逊。那么A管理员以违反文明方针为由剥夺B用户的编辑权限并不与避嫌原则冲突。
    • 确实,将用户提报至VIP是可能的解决方案。但是,在当天我发现这一问题(约16:50 UTC)时,已有十数个页面在20分钟内在没有挂CSD模板的情形下删除。而VIP请求通常的处理时间不会少于数十分钟,我担心这样的解决方案不足以应对迫切的问题,所以选择了自己处理。--Antigng留言) 2018年2月18日 (日) 15:48 (UTC)

广告项目[编辑]

大家好,目前作成了Template:樂意處理EP的管理員。我希望将这个模版内嵌到{{EP}}中去,这样每当有人EP,都会给列表中的管理员发出Ping,然后谁愿意接受这些ping,谁都可以加入该列表中去。这是我关于EP的最新的主意,大家觉得是否可以一试?Bluedeck 2018年2月15日 (四) 05:54 (UTC)

挺好呀,方便查找、呼叫管理员。别的管理员项目搞个分类也可以嘛,cat:愿意处理AR的管理员cat:愿意注册账户的管理员什么的,方便群众查找[開玩笑的]燃 灯巡查傀儡 2018年2月15日 (四) 06:41 (UTC)

  • (&)建議將EP改成編輯請求,不然需要請求的新手看不懂。我昨天也查了老半天XD--Janee慶祝寒假開始! 2018年2月17日 (六) 09:40 (UTC)
  • 還有,標題為什麼是廣告項目?--Janee慶祝寒假開始! 2018年2月17日 (六) 09:40 (UTC)
    • 讨论的是直接将本模版置入EP中,这样用户不需要知道本模版名称,每次EP都会调用。那么,就加入试试看。Bluedeck 2018年2月19日 (一) 07:50 (UTC)

签名应不应该加两杠?[编辑]

我看有些人签名前面都有两个横杠(——),我为什么没有?这怎么处理?Happy New Year 2018 新春快乐 2018年2月16日 (五) 02:04 (UTC)

  • 别人的签名都是这样的(我copy的)--example2018年2月15日 (四) 17:47 (UTC)我的是这样的Happy New Year 2018 新春快乐 2018年2月16日 (五) 02:06 (UTC)
  • 我一般不加,因为我签名设置与正文有一定的距离,不担心融入到正文里。使用默认签名的用户建议加上,以防止签名与留言混在一起。燃 灯 2018年2月16日 (五) 06:19 (UTC)
  • 我的也是自動有兩槓?奇怪?--Janee慶祝寒假開始! 2018年2月16日 (五) 11:09 (UTC)
  • 无要求。签名按钮会加--。WP:签名。--YFdyh000留言) 2018年2月16日 (五) 16:09 (UTC)
  • 原来是问为什么签名按钮自带"--"啊,这是编辑器自带的设定。——꧁༺星耀晨曦༻꧂留言) 2018年2月16日 (五) 16:36 (UTC)
  • 可以自己喵一个破折号。———Leiem留言) 2018年2月17日 (六) 05:31 (UTC)
    •   或者是“ほら!破折号上居然有字” Leiem留言) 2018年2月17日 (六) 05:34 (UTC)
    • 你那是底線,不是破折號。————————————這樣才是在破折號上面 -- tang891228 留言 2018年2月18日 (日) 17:43 (UTC)
  • 剩4个波浪号是没有自带横线的,签名按钮补多两个减号,手工打的话就是破折号。——路过围观的Sakamotosan 2018年2月17日 (六) 08:19 (UTC)
  • 这个要看个人喜好吧,我以前有段时间就是为了卖萌而不加两杠的。--伤心CuSO4 2018年2月17日 (六) 12:43 (UTC)
  • --~~~~+1。看個人喜好吧,我是習慣加上,不然我沒自訂簽名樣式,這樣看起來很像內文 --Suaveness對話貢獻 2018年2月18日 (日) 04:10 (UTC)
  • --~~~~+1。我認為應該避免使用破折號。-- tang891228 留言 2018年2月18日 (日) 17:43 (UTC)
  • (!)意見:建议还是在--和~~之间加个空格;以默认签名为例,--Username黏在一起并不好看。-- SzMithrandirEred Luin 2018年2月19日 (一) 02:14 (UTC)
    • 默认签名有空格吗。工具栏的签名按钮就是连着的。--YFdyh000留言) 2018年2月19日 (一) 08:51 (UTC)
      • 我的意思是默认的签名格式和字体等,不是那个按钮;在看你们讨论之前我都忘记有那个按钮存在了... -- SzMithrandir(留言) 2018年2月19日 (一) 16:40 (UTC)
    • 我的作法是直接在参数设置的簽名前面加上空格,畢竟自動產生的簽名也是--~~~~。-- tang891228 留言 2018年2月19日 (一) 18:03 (UTC)
  • 我个人自定義簽名中有一個横槓(—)的,不允使用横槓(或者說是破折號)感覺不像中文。— 2018年2月21日 (三) 04:13 (UTC)

Category:引文格式1维护:未识别语文类型[编辑]

  • 看了一下这个分类对应的英语Unrecognized language,这里的语文是不是写成语言会更好一点?--Leiem留言) 2018年2月19日 (一) 02:17 (UTC)

建議停止使用Wikipedia:机器人/提议[编辑]

因為Wikipedia:机器人/提议較少人使用,大部分的人都是到Wikipedia:机器人/作业请求提出請求,而且兩者的功能「機器人實現的功能建議」和「請求機器人幫助作業」其實沒有很大差異,也時常有人到作业请求提出新機器人提議,因此建議全部合併到Wikipedia:机器人/作业请求,也方便有意關注的人集中到同一位置。

已經將過久的提案存檔,部分移動到作業請求,若無人異議的話將在提議頁掛上{{Historical}}並增加引導至作業請求的提示訊息。--Xiplus#Talk 2018年2月19日 (一) 07:56 (UTC)

Wikipedia:已删除内容查询是否允许查询明显的人身攻击内容?[编辑]

如题。--E8×E8132) 2018年2月21日 (三) 04:01 (UTC)

  • 不允許。--安迪4討論|留名) 2018年2月21日 (三) 04:09 (UTC)
    • 现在有很多攻击其他用户的页面被查询后贴了出来。--E8×E8724) 2018年2月21日 (三) 04:17 (UTC)
      • @Bluedeck:請看一下你這次查詢的全部頁面,一堆屬於人身攻擊的,請求處理。--Zest 2018年2月21日 (三) 05:24 (UTC)
        • 我认为是可以的,之前也查询过类似“fuck”这样的页面。我在这里的标准同于RRD2一致,即“破坏、辱骂、人身攻击所造成的伤害能够通过单纯退回而消除则不需要RRD”,这种可以查询。个人认为“X是笨蛋”、“Y是狗屎”、“Z不得好死”均属于这类谩骂。另一方面,“X暗地勾结市长进行杀人活动”、“Y暗地里进行女厕所偷窥”、“Z的屁股上面有个痣”这种则需要RRD,而不能查询。请问这个标准是否合适?Bluedeck 2018年2月21日 (三) 09:05 (UTC)
          • 單純意見,此不屬任何方針指引,我反對提高任何沒意義、沒營養,單存發洩、謾罵的歷史能見度。--Zest 2018年2月21日 (三) 10:11 (UTC)
            • 这个页面的本意应该是把还有抢救价值的条目拖回来使作者能改进吧?不过好像找不到该页面相应的方针?--E8×E834) 2018年2月21日 (三) 13:00 (UTC)

有用户擅自删除讨论,如何处理?[编辑]

https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88/%E6%9D%A1%E7%9B%AE%E6%8E%A2%E8%AE%A8&diff=48275446&oldid=48274992

毫无理由地将“孟菲斯及其墓地金字塔吉萨金字塔群合并讨论”章节删除。我在存档扒了半天没找到才发现是被这么删掉了。--小烈 (找我?) 2018年2月21日 (三) 08:59 (UTC)

  • 善意推定的话,有可能是对方不小心按错了吧?自行加回去就可以了。如果反复删除又没有理由,可视作破坏。--♥GO BRUINS! 2018年2月21日 (三) 21:18 (UTC)