維基百科:互助客棧 (全部)

維基百科,自由的百科全書
(已重新導向自 Wikipedia:互助客棧/全部)
前往: 導覽搜尋
捷徑
WP:VPALL

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容,請在互助客棧中選擇最合適的版面。

按此重新整理頁面

  歡迎光臨互助客棧!  
   
  互助客棧是維基人議事相助之處,用以討論消息、方針、技術以及編輯、求助等議題。
發表議題之前請搜尋先前文章,遵守指導禮儀任何與維基百科無關的問題,請前往知識問答
Breezeicons-apps-48-artikulate.svg
消息
Breezeicons-apps-48-cantor.svg
方針
Breezeicons-categories-32-applications-development.svg
技術
Breezeicons-apps-48-system-help.svg
求助
Breezeicons-apps-48-words.svg
條目探討
Breezeicons-apps-48-braindump.svg
其他
討論維基相關新聞與消息 討論方針與草案 解決或報告技術疑難 解決在維基百科中所遇疑難 條目模版主題相關探討 未符任何分區之議題
發表 | 監視 發表 | 監視 發表 | 監視 發表 | 監視 發表 | 監視 發表 | 監視

檢視全部討論

If you want to contact Chinese Wikipedia, please leave your message here.
我想要…… 請前往……
如何存取並有效安全存取維基百科的方法 如何存取維基百科
與繁簡處理有關的問題 字詞轉換
協助或尋求條目的改善意見 同行評審
參與即時討論或透過電子郵件進行討論 即時討論」或者「郵件列表

目錄

消息

英語社群將每日郵報列為不可靠來源

維基百科:英國每日郵報為不可靠消息來源. 中央社. 2017-02-09.  我們是不是也要跟進?臺灣杉 在此發言 (會客室) 2017年2月11日 (六) 08:28 (UTC)

這有點過激了吧,感覺跟一刀切地將蘋果日報當成不可靠來源一樣。—AT 2017年2月11日 (六) 10:46 (UTC)
這是打開潘朵拉的盒子。下一個是誰?今日俄羅斯?--Mewaqua留言) 2017年2月11日 (六) 13:05 (UTC)
中國人最熟悉的這家英國媒體,居然可信度「極低」?!(環球時報,2017-02-10)--Mewaqua留言) 2017年2月11日 (六) 13:11 (UTC)
「不過我們別忘了,維基百科裡還有不少涉及中國的條目被反華勢力把控,這些條目中所引用的信息大多來自沒有任何可信度的反華媒體的編造。」醉了,雖然說大多數涉及中國的條目確實是有一些(或者說不少)負面內容影響中立,不過畢竟這是官媒環球時報說的嘛,還是要呵呵滴……或許這可以當做某檔封鎖維基百科的原因之一呢……不好,跑題了……--№.N留言) 2017年2月11日 (六) 13:18 (UTC)
郝主任耿直哥:這裡不是百度百科,想改什麼條目您直接上手就成。。--DukeAnt維基姓黨,請您檢閱) 2017年3月23日 (四) 16:26 (UTC)
那個意思可以解讀為,不反華的媒體都是可信的媒體(但是似乎沒有任何一家媒體專門會去反對某個國家)--百無一用是書生 () 2017年2月13日 (一) 07:24 (UTC)
(!)意見雖說中文維基百科不必對《每日郵報》施以一刀切政策,不過在英文維基百科的可靠來源討論頁[1]上,對於《每日郵報》的口誅筆伐相當猛烈,鄙人也時常覺得《每日郵報》譁眾取寵,訛誤百出,中文維基雖不至於說要將其列為不可靠來源,但或許有必要對將其作為來源的條目及內容進行一下檢查。另:英文維基上分享了一個諷刺《每日郵報》的YouTube視頻[2]相當有趣,可以觀賞一下。----漸台子_CLTR (造訪敝台) 2017年2月13日 (一) 16:32 (UTC)
但是世界上就存在大紀元以及新唐人,雖然說它們大多所針對的是某檔而非一個特定國家,而且它們是為法輪功服務的。以前還曾有人在互助客棧里提請要把親法輪功媒體列為不可靠來源呢。--№.N留言) 2017年2月14日 (二) 02:45 (UTC)
話說我先前寫的2016奧運游泳小項條目有一部分來源就是每日郵報的……畢竟都是從英文維基翻過來的,不過我也是在剛好補完之後才發現這個消息的……--№.N留言) 2017年2月14日 (二) 01:11 (UTC)
自由時報電子報在2017-02-09的一則報道說「維基百科也呼籲不要使用國營媒體,如中國的新華社或伊朗的新聞電視作為消息來源」(新聞不可靠 維基百科封殺英國《每日郵報》),不知道是否屬實,原始出處在哪?--Mewaqua留言) 2017年2月14日 (二) 01:50 (UTC)
如果反對某一政黨的媒體是不可考來源,那麼支持某一政黨的媒體應不應該也算作不可靠?--Gqqnb留言) 2017年3月14日 (二) 01:25 (UTC)
無論如何百度百科互動百科不是可靠消息來源,我已經把這兩類來源進行了清理和刪除。--Walter_Grassroot 2017年2月15日 (三) 01:02 (UTC)
相對於正規媒體而言,包括維基百科在內的任何網絡百科全書都不是可靠來源。--№.N留言) 2017年2月15日 (三) 06:40 (UTC)
這就是諷刺的地方了。在不少範疇,維基百科的內容是比許多公共媒體更加可靠的。我們不把自己(及其他網絡百科)看作可靠來源,是因為它的編輯過程沒有正規評審程序,然而這並不意味那些有評審程序的媒體是可靠的。如《每日郵報》這種媒體,至少可以在某些範疇(科學之類的)列為不可靠來源,應該是無可爭拗的。鋼琴小子 留言 貢獻 2017年2月16日 (四) 02:21 (UTC)
Case by case,我舉雙手贊成把每日郵報從可靠來源中剔除。Bluedeck 2017年2月16日 (四) 16:12 (UTC)
所以要在方針開討論頁徵集意見?如果覺得同意,我就會在方針頁面開個討論串討論。臺灣杉 在此發言 (會客室) 2017年2月17日 (五) 14:01 (UTC)
建議在提案的時候,說明一下為什麼要這樣做(而不是簡單給出:英文維基也是這樣做)。——꧁༺星耀晨曦༻꧂留言|2017年監管員選舉) 2017年2月17日 (五) 14:12 (UTC)
(-)反對,未見必要性。在討論內容,尤其是內容方針的適用性問題上,一事(誰寫的、發表在什麼來源的什麼版面上的、什麼性質的文章、其中的什麼部分、用於說明什麼條目中的什麼內容——是不是可靠來源)一議是最好的方法。--Antigng留言) 2017年2月18日 (六) 03:08 (UTC)
(-)反對。每日郵報有些報道在其它「主流」媒體不易找到,例如政治不正確的難民負面新聞。--Mewaqua留言) 2017年2月18日 (六) 06:17 (UTC)
(*)提醒Liu116:不一定,已停止出版紙本書籍的大英百科全書仍然是可靠來源。--M940504留言) 2017年3月8日 (三) 02:37 (UTC)
  • 現時中文維基百科是否也有「不可靠來源」的列表?——愚蠢的人類 2017年2月22日 (三) 06:49 (UTC)
這種問題現在都不想回答了,否則肯定吵個三天三夜「你不中立」「你獨裁」「你血口噴人」……等等等等。昔年染指逐元祐,今日焚屋作道光。惟願核食不上島,東風卷進太平洋留言) 2017年2月23日 (四) 06:43 (UTC)
我認為不可靠來源的列表遲早都要建立,但還需要磨合期,凝聚共識。臺灣杉 在此發言 (會客室) 2017年3月2日 (四) 09:14 (UTC)
上面已經說了,建立這種列表毫無意義,因為來源的可靠性涉及其運用的場合,而運用場合是不可能窮盡的。--Antigng留言) 2017年3月3日 (五) 14:39 (UTC)
(!)意見:列一個「建議來源列表」或「不建議的來源列表」如何?如果「不可靠來源」的列表或「可靠來源」的列表有爭議的話,那麼「建議的來源」的列表或「不建議的來源」的列表應該可以吧?-- 宇帆普通留言·Flow留言·) 2017年3月3日 (五) 15:22 (UTC)
您可能沒抓住我的要點。我的意思是,說一個來源「是可靠來源」、「不是可靠來源」是沒價值的,「誰寫的、發表在什麼來源的什麼版面上的、什麼性質的文章、其中的什麼部分、用於說明什麼條目中的什麼內容——是不是可靠來源」才有價值。--Antigng留言) 2017年3月3日 (五) 15:39 (UTC)
但是搜索來源第一步用程式篩選的話,有列表會比較方便,程式就會協助我篩選出適合的來源再從中挑出需要使用的來源。如果搜索來源第一步就要分析「誰寫的、發表在什麼來源的什麼版面上的、什麼性質的文章、其中的什麼部分、用於說明什麼條目中的什麼內容——是不是可靠來源」的話,那來源搜索篩選程式豈不是要做一個複雜語意分析器和深度學習系統嗎?-- 宇帆普通留言·Flow留言·) 2017年3月3日 (五) 15:47 (UTC)
程序篩選本來就不太靠譜啊。--Antigng留言) 2017年3月3日 (五) 15:50 (UTC)
網路爬蟲爬到的來源數通常都有點多,不可能全部閱讀完,但若可以寫一個程式去掉一些不可靠來源的話,會方便一些,這時,列表是一個好選擇。-- 宇帆普通留言·Flow留言·) 2017年3月3日 (五) 15:54 (UTC)
找來源本身即是一項費時費力,但是需要精細化操作的工作。這樣的篩選通常是沒有價值的,比如對於某個人物,其履歷中一些細節也需要從他的個人blog里補充(此blog對介紹自己的內容屬於一次、非獨立可靠來源),事先排出掉反而不行。再比如,有些blog會貼出某些古代文獻的圖片,或者(我寫上海歷史建築條目)檔案館裡建築的圖紙,這部分內容不會因為其來源於blog而變得不可靠,也不能排除掉。--Antigng留言) 2017年3月3日 (五) 15:59 (UTC)
好吧,看來得寫深度學習系統來篩來源了 囧rz...寫程式的目的不就是要將費時費力的工作變成一鍵完成嗎,怎麼越來越麻煩。是覺得找來源也是一種演算法-- 宇帆普通留言·Flow留言·) 2017年3月3日 (五) 16:02 (UTC)
同意這列表是有爭論性,研究時會引起爭端。而我個人看法生先把共識的的地方先找出來(共識的地方就是爭端相對比較小的地方),這會是減少未來遇到的爭端的第一步。——愚蠢的人類 2017年3月4日 (六) 18:43 (UTC)

通知:2017年中國大陸社群聚會(第二次,2月16日)

根據Wikipedia:聚會/中國大陸社群聚會/2017年第2次的說法,參與者有守望者愛孟霧島聖蘇州宇文宙武Erquanmen上海工部局黑暗雄鷹等人,涉及文保編輯、大陸編輯缺乏原因等。(※)注意:以上內容僅為根據頁面編寫的普通通知,未代表個人立場-- 晴空·和岩 留言板 2017年3月1日 (三) 13:12 (UTC)

什麼意思?沒聽明白。——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★貢獻 2017年3月1日 (三) 16:06 (UTC)
我猜他的意思是:支持維基聚會,但不願意和親共者為伍。Juncta In Uno Omnia留言) 2017年3月2日 (四) 08:43 (UTC)
  • 誰是「親共者」?—john doe 120talk) 2017年3月3日 (五) 04:52 (UTC)
你們討論了「中文維基社群工程、科學類條目編輯者缺乏的原因」,請問討論結果如何?這點我比較好奇。鋼琴小子 留言 貢獻 2017年3月2日 (四) 10:38 (UTC)
這個其實很多人都可以duck出來-- 晴空·和岩 留言板 2017年3月4日 (六) 02:47 (UTC)
是,感覺明知故問。至少中國大陸維基編輯衰減是2014年開始的,原因麼,看看大陸維基活動這幾年是哪些人在堅持就明白了。galaxyharrylion留言) 2017年3月5日 (日) 13:19 (UTC)
大陸的路過,別以為自己的組織很偉大就是了。——路過圍觀的Sakamotosan 2017年3月6日 (一) 00:41 (UTC)
嗯,偉大..............................................................-- 晴空·和岩 ✎留言板·渥太華歷史的編寫 2017年3月15日 (三) 11:14 (UTC)
這裡有人說自己偉大了嗎?——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★貢獻 2017年3月23日 (四) 04:46 (UTC)
沒有實質討論內容的東西,即使能延長機器人自動存檔時間,又打算想延遲幾久,下次視訊會議?那可能每兩週要開一次。沒有實質內容的編輯所造成的機器人自動存檔延遲,將由手動存檔修正。除非出現有意義且無離題之討論。一個偉大加一堆點作為討論太 混了,湊 帳面數字?--180.204.133.125留言) 2017年3月15日 (三) 15:17 (UTC)
嗯,寫個通知都挨噴,你也是夠可以的。把時間用來回覆你這種不用維基賬號說話偷偷摸摸的人真的蠻奢侈的,不過我不妨奢侈一回。閣下這麼不喜歡點嗎,好哇,我上癮了,我還想多打幾個——..................................................................................................................................................開心嗎,哈哈哈哈。我覺得我還想多寫幾個這樣的通知,如果有需求的我免費服務哦-- 晴空·和岩 ✎留言板·渥太華歷史的編寫 2017年3月16日 (四) 12:12 (UTC)
謝謝分享!--上官留言) 2017年3月22日 (三) 20:03 (UTC)
忽然想到,我覺得各位討論中國大陸的維基社群目前的狀態,根本就是在進行2030維基願景的遠距討論會議了!歡迎參考議程規劃參考(目前正在翻譯中),把各位對維基媒體運動的未來願景,用更有架構的方式進行討論、紀錄、以及回報給國際社群參考。有任何問題也歡迎留言,祝發展順利。--上官留言) 2017年3月22日 (三) 20:25 (UTC)
沒有實質討論內容的東西,即使能延長機器人自動存檔時間,又打算想延遲幾久,下次視訊會議?那可能每兩週要開一次。沒有實質內容的編輯所造成的機器人自動存檔延遲,將由手動存檔修正。除非出現有意義且無離題之討論。一個偉大加一堆點作為討論太 混了,湊 帳面數字?--180.204.133.125留言) 2017年3月15日 (三) 15:17 (UTC)
嗯,寫個通知都挨噴,你也是夠可以的。把時間用來回覆你這種不用維基賬號說話偷偷摸摸的人真的蠻奢侈的,不過我不妨奢侈一回。閣下這麼不喜歡點嗎,好哇,我上癮了,我還想多打幾個——..................................................................................................................................................開心嗎,哈哈哈哈。我覺得我還想多寫幾個這樣的通知,如果有需求的我免費服務哦-- 晴空·和岩 ✎留言板·渥太華歷史的編寫 2017年3月16日 (四) 12:12 (UTC)
  • 根據Kou Dou意見,等待機器人存檔,在此附註說明--36.233.246.219留言) 2017年3月22日 (三) 06:21 (UTC)
  • 以此簽名紀錄有IP帳號刪除有簽名的內容,及註冊用戶編輯戰狀況--61.224.0.151留言) 2017年3月22日 (三) 07:34 (UTC)
  • 上列五段留言移動自互助客棧其他區,存檔事宜請交由機械人處理,存檔時間為最後留言起計七日後。本討論置於消息區可矣,請勿再施移動,亦請勿複製。討論區不宜保護,敬請各位自重。--J.Wong 2017年3月23日 (四) 11:49 (UTC)
  • 看不懂你們都在吵什麼,可能是我老糊塗了。--DukeAnt留言) 2017年3月23日 (四) 16:19 (UTC)

Overview #2 of updates on Wikimedia movement strategy process

Note: Apologies for cross-posting and sending in English. This message is available for translation on Meta-Wiki.

As we mentioned last month, the Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Each month, we are sending overviews of these updates to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a overview of the updates that have been sent since our message last month:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 2017年3月9日 (四) 19:42 (UTC) • 請幫助翻譯至您的語言Get help

翻譯一下:

我們上個月提過,維基媒體運動已經開始就維基媒體運動未來的戰略進行諮詢,這次討論將會遍及運動的每一個角落,直至2017年年底為止。討論的重點是我們運動的未來:我們要一起走到哪兒,還有我們要實現甚麼目標。
我們會定期向Wikimedia-l郵件列表元維基通報討論的最新進展,以及當月討論的焦點。要獲取這方面的最新消息,請在此處簽名。
上個月以來的討論進展如下:
要了解更多關於維基媒體運動策略的資訊,請瀏覽元維基為「2017年維基媒體運動戰略諮詢工作」而設立的專頁。

如果有不貼切的地方,請大家高抬貴手,別扔玻璃瓶,自己改正也可以。補充一下,按照計劃,在中文版負責協調戰略檢討諮詢工作的同工是VLui君,元維基看到的訊息也表示諮詢工作很有可能會在客棧展開(雖然個人對此有擔憂)。--春卷柯南歡迎參加協作計劃 ( ) 2017年3月15日 (三) 14:55 (UTC)

中文維基百科目前的情況

根據元維基上面的討論,一個用於排行維基媒體項目的列表正在開發中。
中文維基百科條目數:931399(全域排行第15名)[3]
頁面數:4911211(全域排行第8名)
編輯數:44833366(全域排行第11名)
管理員數量:82(全域排行第7名)
註冊用戶數:2351905(全域排行第5名)
活躍用戶數:7247(全域排行第8名)
文件數:44618(全域排行第11名)

以上資料截至2017-03-14 00:00:29(UTC)
無聊沒事做的消息推送者:꧁༺星耀晨曦༻꧂留言) 2017年3月14日 (二) 05:01 (UTC)
70~80W被徹底拋開了。——路過圍觀的Sakamotosan 2017年3月14日 (二) 06:48 (UTC)
感謝通知,不過條目的內容也要有條目的基本標準才得以保留下來。--小躍撈出記錄) 2017年3月15日 (三) 00:52 (UTC)
我就來吐個槽為什麼英文版可以加上Simple English……中文版加上zh-yue, zh-classical, zh-wuu, zh-gan吼不吼呀?全加上也好不到哪去 --碸中嘌呤的白磷萃取 打譜 2017年3月16日 (四) 11:14 (UTC)
在多語言維基媒體項目里,中文系語言分的很開的。。我都想提議在元維基和維基共享增設自動繁簡轉換系統。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 15:15 (UTC)

互動百科被央視315晚會曝光了

收費創建虛假醫藥詞條。--Fxqf留言) 2017年3月15日 (三) 12:23 (UTC)

嗯,然後呢。——꧁༺星耀晨曦༻꧂留言) 2017年3月15日 (三) 12:40 (UTC)
應該挪到VPN版。 --碸中嘌呤的白磷萃取 打譜 2017年3月15日 (三) 12:41 (UTC)
完成Kou Dou 2017年3月15日 (三) 23:45 (UTC)
可以在央視315晚會更新?--Wolfch (留言) 圓周率協作中 2017年3月16日 (四) 12:47 (UTC)
有必要發在互動客棧嗎。。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 13:36 (UTC)

We invite you to join the movement strategy conversation (now through April 15)

2017年3月18日 (六) 05:02 (UTC)

@星耀晨曦:來翻譯一下吧。--1=0歡迎維基人加QQ群170258339 2017年3月18日 (六) 05:06 (UTC)

翻譯

本文〈我們邀請您參加維基媒體戰略討論(4月15日截止)〉已由Gregory Varnum於3月15日至16日期間傳送到各個社群的客棧、自治體組織(在元維基設立)的討論頁、維基媒體運動的郵件列表和群發消息組。Nicole Ebber也已經在3月15日把類似的消息傳送到維基社團(Organized Group,基金會內部的組織和跨國維基組織,台大維基社這種外部的維基社團不算)和這些社團郵件列表。這個版本是為了方便翻譯、存檔而提供的。

各位維基人:

我們會在今天展開一場廣泛的討論,來確定未來維基媒體運動對世界的作用,並制定一套協作戰略,令維基媒體運動能夠發揮到這些作用。我們熱烈邀請您參與這個討論。

參加討論的方法有很多種。你可以參加現有的討論,也可以發起自己的討論:

A組討論:在自己所屬的自治體組織、基金會屬下的委員會和其他類似的組織進行討論(這些都是支持維基媒體運動的團體)。

B組討論(個人貢獻者):在元維基或者本地維基進行討論。

戰略討論分為三輪,第一輪討論由即日起,至4月15日截止。第一輪討論旨在討論維基媒體運動的未來,並以可能出現的討論議題為基礎,制定(策略討論的)主題。在未來15年內,我們想一起建立的東西、實現的目標是甚麼呢?

我們歡迎您,畢竟這個討論的機會是你我一起創造的。我們希望維基媒體運動同仁都能夠參加這場討論,令討論得到廣泛、多元的參與。

 祝
台安

Nicole Ebber(A組組長)、Jaime Anstee(B組組長)以及討論支援團隊

Translator:꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 09:04 (UTC)
整段譯文的舶來貨味道非常濃烈,所以我自己修了一次,只是出於尊重,沒把翻譯者的身分也替換掉。Sincerely是英文書信常用的祝頌語,切忌硬譯,應該翻譯為中文書信常用的祝頌語(教英文的書可能會這樣寫,卻並不表示這是最吼的),至少也應該翻譯成「祝好」之類的東西。討論A、討論B,在我看來沒有A、B組討論那麼貼切,因為各組討論的主題都是大同小異的,只是受眾不一樣。如果不是我要統計小精靈的強弱,還有瀏覽器不斷跳針,我可以來早一點。--春卷柯南歡迎參加協作計劃 ( ) 2017年3月18日 (六) 12:47 (UTC)
我們屬B組,但目前為止沒見任何相關討論也不知道該在哪裡發起討論,WP:維基媒體2030嗎?—以上未簽名的留言由源環對話貢獻)於2017年3月19日 (日) 10:25(UTC)加入。
是的。在元維基對應的討論頁也可以。——꧁༺星耀晨曦༻꧂留言) 2017年3月19日 (日) 16:19 (UTC)

維基共享的2016年年度圖片選舉的第一輪投票已經開始

誘導力場。第一輪投票將於2017年3月30日 23:59:59(UTC)結束。——꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 13:12 (UTC)

新玩具:Citationhunt(可譯作「獵殺來源請求」工具嗎?)

大家沒事的時候可以消除來源請求模板(感謝 User:fantasticfears 協助與英文社群維基人的討論整理): https://tools.wmflabs.org/citationhunt 歡迎挑戰看看自己吊書袋的能力呀! --上官留言) 2017年3月22日 (三) 20:08 (UTC)

工具中出來的頁面引文部分無法選擇複製.....--百無一用是書生 () 2017年3月23日 (四) 03:59 (UTC)

方針

是否應該讓國外名人的人名重定向?

本節達成共識,請參與下方方案討論。

使用中文維基一個比較不完美的地方我感覺就是英文重定向中文數量太少,其中最明顯的就是對於名人的人名重定向數量太少。根據我這兩天15小時+的測試,大約60%的有代表性的英文名人都無法重定向。舉一個例子,拿破崙的英文Napoleon,放入中文維基搜索時出來的結果很不理想。Alfred Adler,New York University,Kathleen Norris, Fannie Hurst, Ida Tarbell, Albert Payson Terhune, Rupert Hughes這些詞用英文wiki是直接進入的我認為在中文wiki上也應該需要直接進入。我的想法是對於代表性非常強的人名應該要加入重定向,沒有搜索到中文條目的轉鏈進入英文wiki或者選擇讓用戶創建。並且在英文重定向中文的總體數量需要增加(在西方人名,地名,事件上等有代表性的英文詞)。第一次寫提案,寫的非常草率,希望大家能補充,謝謝!--Py930828留言) 2017年2月13日 (一) 02:46 (UTC)

目前非中文重定向方針貌似尚未規範到外文人名的部份。之前的討論有Wikipedia:投票/非中文重定向頁面Wikipedia:投票/非中文重定向頁面第二次投票。前者似乎未達成共識,後者則未論及此部分。如各位認為有需要,或許可就此方面議題進行討論(外文人名、名詞等重定向)。-和平、奮鬥、救地球!留言歡迎加入維基Telegram群 2017年2月13日 (一) 03:02 (UTC)
(~)補充:這位新手曾在IRC-TG群各QQ群提問,表示使用搜尋功能輸入外文時,會顯示該條目尚未被創建,使其產生疑惑與不便(如果我的理解沒錯的話)。或許這方面也要考慮一下讀者和新用戶的感受與方便性,並做對應之調整(若技術上可行)。-和平、奮鬥、救地球!留言歡迎加入維基Telegram群 2017年2月13日 (一) 03:04 (UTC)
  • 囧rz...:原來外文人名不能做重定向的嗎,我一直有做而且沒人管。--星巴克女王(🎶歡迎參與音樂專題 2017年2月13日 (一) 09:55 (UTC)
  • 重定向的建立並不會影響主頁面,而設立重定向的意圖是「輔助導航與搜索」。因此,我覺得允許外文人名的重定向應該是一個比較理所當然的事情(當然,作為共識還是要徵詢的)。另外,對於維基百科條目內容的約束,我覺得社群其實存在「法無禁止即可行」的默契(如果我說錯了,請糾正我);從這點上說,WP:重定向似乎更適合去規定不應進行外文重定向的情況(黑名單),而不是畫個範圍來只允許列出的外文重定向(白名單)。--菲菇維基食用菌協會 2017年2月14日 (二) 03:42 (UTC)
  • (+)支持在遇到用原文搜尋時,結果不在頭兩三項的情況下,建立外文重定向(正如拿破崙的例子)。但在大部分情況下,原名應該可以直接搜尋得到,這時就應避免建立不必要的重定向。比如,我覺得Alfred Adler和New York University是不應該有重定向的。鋼琴小子 留言 貢獻 2017年2月14日 (二) 17:36 (UTC)
  • (+)支持:無條件支持。--水中撈躍 2017年2月15日 (三) 04:44 (UTC)
  • (+)支持,我覺得只要是能夠方便讀者和編輯更好地使用中文維基百科,這些做法都應該是有益及可以的。--Walter_Grassroot 2017年2月15日 (三) 08:16 (UTC)
  • (!)意見:因為出現豊臣秀吉(因為符合Wikipedia:重定向#非中文重定向問題第3條:日語異體字)跟駒都えーじ(因為符合Wikipedia:重定向#非中文重定向問題第4條:日語假名)這2個日語人名的重定向--林勇智 2017年2月15日 (三) 13:53 (UTC)
  • 這個。我覺得會建立一堆外文重定向,比如英語的,西班牙語的,藏語啥啥的。會不會給管理帶來困難。——꧁༺星耀晨曦༻꧂留言|2017年監管員選舉) 2017年2月15日 (三) 14:19 (UTC)
    • 要考慮常用語種的問題。不可否認的一個客觀現實是,當今的互聯網內容除中文以外,主要以英文為主[4]。--菲菇維基食用菌協會 2017年2月15日 (三) 16:28 (UTC)
  • (+)支持,英文名作為通行標識符用得很多。——Artoria2e5 保持討論完整直接ping我回復 2017年2月15日 (三) 17:21 (UTC)
  • (+)支持,理應如此。--Jerre Jiang  討論參與清理積壓站務  2017年2月16日 (四) 11:39 (UTC)
  • (*)提醒,人名重定向囊括了非中文的重定向,包含英文、日文、韓文、西班牙文等等的人物原名。--小躍撈出記錄) 2017年2月21日 (二) 02:46 (UTC)
  • (+)支持,在旁邊搜尋欄輸入Napoleon的話,即時給出的結果只有3個。因為Napoleon這頁面未被建立,所以不在顯示之列。在最下面雖然有「包含...Napoleon」的指示,但一般人可能以為是只有這3個結果。於Special:搜索輸入Napolean,則在第39項才找到拿破崙一世。大概由於首段註明的外文名分別是Napoléon Bonaparte和Napoleone Buonaparte,都不對應。所以我覺得沒太大歧義的話(同一個名字對應於名氣相若的兩個名人),都應該建立英語人名的重定向。--578985s留言) 2017年3月1日 (三) 15:21 (UTC)
  • (+)支持,應該開放Alfred AdlerNew York UniversityKathleen Norris, Fannie Hurst, Ida Tarbell, Albert Payson Terhune, Rupert HughesUY4Xe8VM5VYxaQQ留言) 2017年3月13日 (一) 09:56 (UTC)

一點舊討論

非簡寫的英文重定向

--Temp3600留言) 2017年2月17日 (五) 10:45 (UTC)

既然大家(大約共識見[5])認為模版可以(有人甚至認為應該)用英文,何以同樣方便大家 -更方便讀者- 的英文重定向如此多反對者?* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 07時43分28秒。
Hillgentleman提到「英文重定向」,我認為不能與「簡稱重定向」相提並論。例如將orange重定向到,這是「英文重定向」,似乎有過份濫用之嫌;但例如將OJ重定向到橙汁,這是「簡稱重定向」,只要大家認同「OJ」是常用的簡稱,重定向是可以接受的。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 07:51 (UTC)
Kevin「似乎有過份濫用之嫌」<---似乎?請你講清楚,濫用就是濫用,然則請舉理由。何謂「濫」?* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 07時56分59秒。
的命名不是起源於英文為母語的地區,假如仍容許英文作重定向,那麼法文、德文、意大利文等為何又不能作重定向呢?總之,我的立場是歡迎「簡稱重定向」,但對不必要的「英文重定向」有所保留。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:04 (UTC)
「為何又不能」??? 能! 請自便--> en:wikt:orange#Translations
Kevin請回答:何謂「濫用」?* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 08時10分29秒。
我所指的「濫用」是指建立不必要的重定向的行為。根據Wikipedia:投票/非中文重定向頁面第二次投票,只有一些特定的情況下(也就是在該次投票中由社群通過的那幾個情況),非中文重定向頁面才可被建立。因此,將orange重定向到實屬不必要。反而根據社群共識,學名Citrus sinensis重定向到橙是可以接受。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:39 (UTC)
「不必要」?維基 有很多物事都不「必要」。重要的是 有 無 用。 無論如何 有用無用,必要不必,亦非你Kevin一言而決。若有英國人,初學中文,想知orange 的中文是甚麼,則他可用orange之重定向。另外,我們在歐美有很多用戶,有時他們所在的網絡無中文輸入,則他可用orange之重定向,比要用網上中文輸入方便得多。* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 08時52分47秒。
「若有英國人,初學中文,想知orange 的中文是甚麼」,我認為他應該先到英文維基百科輸入orange,再在「其他語言」一欄點選「中文」進入中文維基百科的。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:57 (UTC)
  • 誠不能如是想,他人初遇維基,未必知他語連結之用,直來中文維基,鍵入英文搜尋,誠人之常情也。—孔明居士 2007年7月21日 (六) 09:00 (UTC)
Kevin你知道工程中 redundancy 之重要嗎?若英文維基暫停又如何?* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 09時02分58秒。
你也有你的道理。也許我們兩人先暫停爭論,聽聽其他人的意見吧。畢竟在中文維基百科,向來都沒有「為任何條目的英文名稱建立重定向」這個習慣。假如經社群充份討論後主流共識是接受這種做法,我當然尊重並不會阻止。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 09:08 (UTC)
我未見有人有興趣「為任何條目的英文名稱建立重定向」。現在我們講的是有用而無害的外語重定冋(即在任何情況下都不會誤導)可留。所以很難理解你可能會阻止那一種做法。* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 09時19分28秒。
你誤解了我的說話,我的意思是讓社群決定是否容許建立這類重定向。再拿回之前的討論作例子,外語國家名稱的重定向是被社群否決容許的,難道這類重定向是因為有「誤導」成份而被社群反對嗎? -- Kevinhksouth (Talk) 2007年7月21日 (六) 09:28 (UTC)
我插一句,目前的票數說明「社群否決容許」(即沒有產生是否存刪的共識)是對的,但不能說明「社群反對」「這類重定向」。— fdcn talk 2007年7月22日01:18 (UTC+8 7月22日09:18)
我無誤解你的說話;我根本不知你在說甚麼。『難道這類重定向是因為有「誤導」成份而被社群反對嗎?』-明知故問。請回到該討論頁討論這事。* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 09時39分45秒。
提刪[6]人指 {{d|這是中文維基,沒有需要的重定向。}} 。吾人有template:速刪,同樣重定向到template:delete 。這是中文維基,Thomsonlee反而用英文模板提刪。* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 07時54分41秒。

我依然希望維基人都看一看上面提及的投票和討論,作為定位技術的重定向,非中文本身不應有「濫用之嫌」,是多多益善的。— fdcn talk 2007年7月21日07:59 (UTC+8 7月21日15:59)

另外一個說法,假使重定向並不佔有多少資料空間,何以為了自認的「不必要」而犧牲讀者的「方便性」?:)--春日クリス 2007年7月21日 (六) 09:12 (UTC)

覺得討論太多的話不妨從Wikipedia:投票/非中文重定向頁面第二次投票#快速刪除的標準開始看起。--RalfX) 2007年7月21日 (六) 09:20 (UTC)

  • 就事論事,「orange」重定向到「」是錯誤的,按英語論,還有桔子,橙色等其他含義,其他語言可能還有其他解釋,除了「方便性」,作為百科全書,還需要「準確性」
  • 建議多參考Wikipedia:投票/非中文重定向頁面第二次投票
Isnow 2007年7月21日 (六) 09:22 (UTC)
同意。多謝提醒。Orange在英文維基百科是釋義頁。早前我們想得太抽象。* : -) ---Hillgentleman | | 二零零七年七月二十一號(星期六)格林尼治 09時26分40秒。
至少我覺得本來就是外國的東西是可以允許使用簡稱重定向的,但是外文重定向是沒有必要的。例如說新加坡的地鐵,在新加坡幾乎所有的中國人去坐的時候不會說去坐地鐵,反而都會說去坐MRT,這個時候,MRT已經作為這個事物的另外一個名字被廣泛使用了,所以應該重定向。但是它的全名卻沒有必要重定向,因為那應該是英文維基的內容。—人神之間擺哈龍門陣 2007年7月21日 (六) 13:22 (UTC)
全名為什麼在中文維基沒有必要?有人需要它來定位中文地鐵的條目。請給出不必要的根據。這問題以前討論過很多次了。— fdcn talk 2007年7月21日15:10 (UTC+8 7月21日23:10)
我的理解是既然他需要用英文來定位中國地鐵,那麼他必定可以找到相關語言的百科全書,再通過該頁上的鏈接到中文維基。可以說得例子是,英文維基沒有很多可以使用的中文重定向,那我們也想用中文來定位它的一些條目阿。—人神之間擺哈龍門陣 2007年7月21日 (六) 15:58 (UTC)
一、其它語言沒有這個相關跨語言鏈接呢?二、就算有,先找到外文維基,再跑回中文,有效率嗎?三、重要的是,這個非中文重定向究竟妨礙着什麼了不能允許存在?四、你還是沒有給出沒有必要的理由,通過火車能到達目的地不能說明汽車沒有必要。— fdcn talk 2007年7月21日16:43 (UTC+8 7月22日00:43)
我可以說出一個現實的理由,大陸的很多人是沒有權限編輯英維的,但他可以創建中文維基的非中文重定向。即使不談這個理由,放着一個可以方便讀者定位的技術棄而不用,我想不出有什麼道理,這非中文重定向根本無關中文政策的。其它語言維基都能允許外文重定向獨中文維基不允許有些奇怪。其實現在所討論的東西,都在Wikipedia:投票/非中文重定向頁面第二次投票里已討論過了。— fdcn talk 2007年7月21日16:53 (UTC+8 7月22日00:53)
  • 英文維基許諸文重定向,不論拉丁、西里爾、東亞皆可,甚或直用他文為條目名。—孔明居士 2007年7月21日 (六) 16:06 (UTC)

只要規定這些重定向不可使用於條目內文中,那我對這些重定向就沒有意見。例如,一個翻譯名稱有爭議的名詞,在其他條目中,仍然必須使用中文描述,可使用noteTA標籤,但絕對不能因為有爭議就去使用原文。--Jnlin討論) 2007年7月21日 (六) 18:49 (UTC)

    • 我認錯,在討論前研究不足,在英文維基試過幾種語言(中文、法語、日文),在相關條目均有重定向,既然這樣的東西不違反方針,又能夠方便用戶,當然很好,故(+)支持。其實從我原來說的很多東西應該能看出來我是很想讓維基對普通用戶更加方便的(而不是對老用戶,因為老用戶自己會有很多辦法)。並且建議相關內容形成方針,使得以後處理有個參照。—人神之間擺哈龍門陣 2007年7月21日 (六) 19:26 (UTC)
  • 可以重定向,不過需要清楚的是,中文和英文的詞不是一一對應的,簡單把某個有多個含義的英文單詞重定向有多個多個含義的中文條目中,是不合適的。—Ksyrie(Talkie talkie) 2007年7月21日 (六) 19:35 (UTC)
    • 對的,非中文的多歧義不能在中文維基進行闡述(比如建立消歧義),這是違反中文政策的。還有,非中文重定向如果存在不精確的情況,也是不能建立的。— fdcn talk 2007年7月22日00:24 (UTC+8 7月22日08:24)
  • 看了以上的討論,我也軟化立場了。既然容許外文重定向,希望能夠一視同仁,不要個別針對某類重定向(例如國家名稱)。而且連外文重定向也容許,簡稱重定向更沒有理由不容許。 -- Kevinhksouth (Talk) 2007年7月22日 (日) 03:09 (UTC)
    • (!)意見,昨天後來我又想了想,還是有點問題,例如英語一般一個詞語都會有幾個意思,那麼我們將其重定向到哪一個呢?比如China,我們是定向到中國中華人民共和國中華民國還是瓷器呢?—人神之間擺哈龍門陣 2007年7月22日 (日) 04:17 (UTC)
      • (:)回應,可以建立消歧義頁,已有ROC這個消歧義頁。—J.Wong 2007年7月22日 (日) 08:39 (UTC)
本節達成共識,請參與下方方案討論。

方案

討論至今,貌似已有共識。在此提出方案,看看大家認為如何?

  1. 允許條目主題之原文名稱重定向
    1. 例如:Alfred Adler重定向至阿爾弗雷德·阿德勒、New York University重定向至紐約大學
    2. 使用WP:名從主人原則。如果「原文名稱」包含數種語言,則那些語言都可以重定向。
  2. 允許有一定使用量的常用語種重定向
    1. 常用語種之判斷,第一種方式可參考各語種維基百科的用戶數量(暫時想不到其他方式)。
      • 根據2017年3月11日(六)00:00 (UTC)的數據,英語有30,420,626名用戶、西班牙語有4,535,276名用戶、法語有2,737,359名用戶、德語有2,599,852名用戶、漢語有2,350,767名用戶、俄語有2,065,026名用戶。
    2. 另一種方式,則是以聯合國官方語言為準,即:阿拉伯語漢語英語法語俄語西班牙語
    3. 另一種方式,則是允許使用人口數最多的十種語言漢語西班牙語英語阿拉伯語印地語葡萄牙語孟加拉語俄語日語德語
    4. 或者是直接允許所有語言的重定向。
    5. 當然若有其他方案也歡迎提出。

以上。-和平、奮鬥、救地球!留言歡迎加入維基Telegram群 2017年3月11日 (六) 03:50 (UTC)

  • 感覺「允許條目主題之原文名稱重定向」這個比較合理。--J.Wong 2017年3月12日 (日) 10:20 (UTC)
我記得以前是不鼓勵,不推薦,但也不反對。但大批量的創建這類重定向則會被視為惡意--百無一用是書生 () 2017年3月13日 (一) 03:24 (UTC)
第1種(原文)比較合理(第二種好像給得太廣了?),但仍然希望能涵蓋到一些化學、數學、電子方面的英語重定向。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月13日 (一) 03:29 (UTC)
@Artoria2e5對非中文重定向的方針似乎已經提及了對學術專有名詞的允許。——꧁༺星耀晨曦༻꧂留言) 2017年3月13日 (一) 10:08 (UTC)
  • 支持方案的第一條。對於第二條,感覺這種重定向沒什麼用(不能幫助搜索條目)。——꧁༺星耀晨曦༻꧂留言) 2017年3月13日 (一) 10:11 (UTC)
其實第二項主要是英文生詞,比如berlin之類。我贊成設五大語言。--Temp3600留言) 2017年3月17日 (五) 18:12 (UTC)
  • 原名重定向太廣了,要縮小範圍,像是人名重定向在下認為還OK。--小躍撈出記錄) 2017年3月22日 (三) 01:22 (UTC)

啟動WP:FACWP:FLN合併

根據上次的討論,在下已經重新修改合併為:

整併頁面草稿

現有頁面 對應草稿
WP:特色條目標準 User:Aotfs2013/特色條目及列表標準
WP:特色列表標準
{{Fapages}} User:Aotfs2013/FANFLpages
{{FLpages}}
WP:特色條目評選 User:Aotfs2013/特色條目及列表評選
WP:特色列表評選
WP:特色條目評選/header User:Aotfs2013/特色條目及列表評選/header
WP:特色列表評選/header
WP:特色條目評選/提名區 User:Aotfs2013/特色條目及列表評選/提名區
WP:特色列表評選/提名區
{{yesFA}} {{user:aotfs2013/yesFAOFL}}
{{yesFL}}
{{noFA}} {{user:aotfs2013/noFAOFL}}
{{noFL}}
{{FCpages/Preload FAN}} {{User:Aotfs2013/Preload FAOFLN}}
{{FCpages/Preload FLN}}
{{Preload FAN/auto}} {{User:Aotfs2013/Preload FAOFLN/auto}}
{{Preload FLN/auto}}
{{FAC}} {{User:Aotfs2013/FAOFLC}}
{{FLC}}
{{FAR}} {{User:Aotfs2013/FAOFLR}}
{{FLR}}
{{FAC/doc}} {{User:Aotfs2013/FAOFLC/doc}}
{{進行中的內容評選}} {{User:Aotfs2013/進行中的內容評選}}
WP:特色條目評選/提名區/header User:Aotfs2013/特色條目及列表評選/提名區/header
WP:特色列表評選/提名區/header
WP:特色條目評選/列表 User:Aotfs2013/特色條目及列表評選/列表
WP:特色列表評選/列表

討論區

說明:歡迎參與討論。- 執行編輯 Aotfs2013 留於 2017年2月23日 (四) 22:58 (UTC)

(?)疑問上次討論有進展了?——路過圍觀的Sakamotosan 2017年2月24日 (五) 00:28 (UTC)
@cwek:主要是依據書生跟柯南的意見,修改了合併方式並擬出可行的草稿。- 執行編輯 Aotfs2013 留於 2017年2月24日 (五) 00:49 (UTC)
(?)疑問:「WP:FAN」是論述「Wikipedia:愛好者內容」,標題是不是打錯字?--Mewaqua留言) 2017年2月24日 (五) 01:19 (UTC)
@Mewaqua:是...,已修正完成。- 執行編輯 Aotfs2013 留於 2017年2月24日 (五) 01:36 (UTC)
要合稱為特色內容嗎?--小躍撈出記錄) 2017年2月24日 (五) 03:00 (UTC)
@小躍:前次在下確實打算稱為「特色內容標準」;不過,把特色圖片拿出後,就只能叫「特色條目及列表」了。- 執行編輯 Aotfs2013 留於 2017年2月24日 (五) 04:36 (UTC)
叫特色內容沒啥問題,「內容」更多時候是指文字類。另外,為何也不把優良評選合併進來?還有一個潛在問題是,此前出現過一個條目到底算是條目還是列表的爭議...--百無一用是書生 () 2017年2月24日 (五) 06:51 (UTC)
@Shizhao:主要是因同級評選的頁面合併,影響較小,若要併入優良評選則需另外再作討論。若叫特色內容但不用於評選特色內容中的特色圖片,這樣可能會有些名不符實。- 執行編輯 Aotfs2013 留於 2017年2月24日 (五) 14:56 (UTC)
個人認為這種合併沒有任何意義和作用,不贊成。--7留言) 2017年2月24日 (五) 07:28 (UTC)
可以吸引多點人到特色列表評選?--Temp3600留言) 2017年2月24日 (五) 10:35 (UTC)
這是上次的提案理由:「目前的特優條目、列表、圖片評選參與的人數差異很大,幾乎是倍數差距,若能整合為一頁面-就如同行評審般,不論是特優條目、列表、圖片都能利用這樣的整合頁面進行評選,不但可增加效率,也能透過更多編輯的參與更進一步提升、保證特優條目、列表、圖片評選的品質。」順帶一題,閣下主編的路易斯安那州城鎮名單恐怕就是因特色列表評選的參與人數過少而落選FL的。- 執行編輯 Aotfs2013 留於 2017年2月24日 (五) 14:56 (UTC)
User:Aotfs2013/FANFLpages中「特色條目工具」似乎有些不妥,下面也有特色列表的內容。--【和平至上】~《💬》~《📝》 2017年2月25日 (六) 06:52 (UTC)
@和平至上:原則上此次合併只會合併標準與評選頁面,因此還是會有分特色列表、特色圖片。至於「特色條目工具」已經修改完成,感謝糾錯。- 執行編輯 Aotfs2013 留於 2017年2月25日 (六) 12:21 (UTC)
  • (※)注意:本草案是以爭議較小的平行整合為整合方式,至於上已移到下面面有其他編輯提及的垂直整合,非屬本草案內容。- 執行編輯 Aotfs2013 留於 2017年3月3日 (五) 01:13 (UTC)
  • (!)意見:可否把草案中的所有「FAOFL」直接以「F」取代?這樣既簡潔,又為以後的合併提供簡單的解決方案。

補簽名pinchuanc留言) 2017年3月6日 (一) 06:55 (UTC)

Fx/GA 三者合併

結案通知

由於討論過於冷清,我將以"無共識"結束討論。如有意分拆討論者請盡快完成。--Temp3600留言) 2017年3月17日 (五) 18:15 (UTC)

動議

經多日討論,雖爭議都不大,惟其中又以原合併案的爭議較中合併案、大合併案小的多;緣此,在下提出動議:先行進行僅涉及FAC/FLN平行整合、改變較小的原合併案,待實施後再待機進一步進行中、大合併案的討論。盼獲各位閣下支持。- 執行編輯 Aotfs2013 留於 2017年3月17日 (五) 18:31 (UTC)

(※)注意:此動議僅是確定本次提議推行的方向,實施細節可再討論。- 執行編輯 Aotfs2013 留於 2017年3月17日 (五) 18:39 (UTC)
@Mewaqua小躍ShizhaoJarodalienTemp3600、@和平至上Pin-Chuan_ChenCdip150葉又嘉Cwek、@SzMithrandirArtoria2e5林天蓬BoyuZhang1998Hat600,通知所有曾參與本討論的編輯。- 執行編輯 Aotfs2013 留於 2017年3月17日 (五) 18:39 (UTC)
(+)支持,做一點是一點,但傾向先FA/GA合併。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 19:15 (UTC)
(-)反對,同意SzMithrandir的意見,應該xA合併,不是Fx合併,條目和列表不同。--Maccomcre留言) 2017年3月17日 (五) 19:23 (UTC)
@Maccomcre:這個討論是評選合併不是將兩者合併,且標準上仍然有清楚分界,供閣下知悉。- 執行編輯 Aotfs2013 留於 2017年3月18日 (六) 09:15 (UTC)
不同種類的頁不應該放在一起評選,GA/FA都是條目,是同一類的,所以應該xA合併給人同時用不同的等級標準評選,而不是Fx評選合併。--Maccomcre留言) 2017年3月19日 (日) 11:43 (UTC)
嚴格來說列表也是條目,而在下也不認為放在一起評審有問題,如同行評審、新條目推薦也都未對條目分類。- 執行編輯 Aotfs2013 留於 2017年3月19日 (日) 13:34 (UTC)
(+)支持,Fx中的項目較為相近。--Temp3600留言) 2017年3月18日 (六) 10:36 (UTC)
(+)支持:有改進總比現狀好,只是執行方式可再微調。pinchuanc留言) 2017年3月18日 (六) 13:41 (UTC)
(+)支持:先通過第一案 再討論第二案--葉又嘉留言) 2017年3月20日 (一) 02:46 (UTC)
(-)反對:GA裡面有包含列表式的條目,況且也不建議合併,雖然自動結票可以改一些程式碼,不過還是要劃清FA/FL/GA之間的界限。--小躍撈出記錄) 2017年3月22日 (三) 01:18 (UTC)
@小躍:閣下似乎搞錯在下的意思了,此動議不涉及GA,而僅是FA/L間的平行整合。- 執行編輯 Aotfs2013 留於 2017年3月22日 (三) 07:32 (UTC)

提高DYK條目基本推薦資格要求

個人認為目前中文維基百科DYK要求過低,只要3000位元組就能獲得基本資格。然而3000位元組是什麼概念呢?這是我創建的一個條目:緊閉雙眼,這個條目可是都有4,596 個位元組哦。因此建議將DYK條目的位元組要求提升至5000位元組。--星巴克女王(❀教母改善計劃 2017年3月4日 (六) 07:11 (UTC)

(-)反對:那是因為有表格和訊息框占空間吧,萬一整篇條目只有文字跟圖片呢?3000位元組要1000字耶,你這樣的話乾脆直接廢除DYK要大家直接去優良條目評選算了。-- 宇帆普通留言·Flow留言·) 2017年3月4日 (六) 07:17 (UTC)
以前用infobox充足字數下限的DYK候選條目會遭到管理員反對,只是後來大家的尺度改變了,有的人甚至認為只要規則不禁止就怎樣也行(這也是幾次我跟某些淺資用戶在DYKC激戰的原因),才覺得這並不是甚麼大問題。--春卷柯南歡迎參加協作計劃 ( ) 2017年3月4日 (六) 10:16 (UTC)
@星巴克女王:請回去全部看完基本推薦資格再來問,你確定DYK規定是只要3000位元組就能獲得基本資格?又是一個陷入數字迷思的人。--114.38.188.173留言) 2017年3月4日 (六) 09:51 (UTC)
5000字節解決不了問題,我只要再加一個附有wayback machine存檔頁的來源,這條目也有希望達到5000字節。不如在正文字數上下功夫,就像亞洲月。--№.N留言) 2017年3月4日 (六) 07:15 (UTC)
(~)補充:話說維基規則里的坑還是蠻多的哩……混DYK這麼久了,發現的漏洞還真不少……--№.N留言) 2017年3月4日 (六) 15:36 (UTC)

並不認為目前中文維基百科DYK要求過低。畢竟大家投票時不是只看字數的。-和平、奮鬥、救地球!留言歡迎加入維基Telegram群 2017年3月4日 (六) 07:18 (UTC)

按照原樣。--小躍撈出記錄) 2017年3月4日 (六) 07:20 (UTC)
我認為有必要(對於非列表類條目)再加上一個正文純字數下限。鋼琴小子 留言 貢獻 2017年3月4日 (六) 14:08 (UTC)
應於基本推薦資格中加入扣除列表、InfoBox與來源後計算的3000位元組,這樣子就能保證該條目內容不錯。-- 寫作「源環」  讀作「PTMaea」  2017年3月4日 (六) 20:52 (UTC)
東拆西補,打不完的……——Artoria2e5 保持討論完整直接ping我回復 2017年3月5日 (日) 03:14 (UTC)

(-)反對:原樣。——Artoria2e5 保持討論完整直接ping我回復 2017年3月5日 (日) 03:14 (UTC)

  • user:星巴克女王user:春卷柯南user:和平奮鬥救地球user:Yinweichenuser:源環user:a2569875user:Liu116user:小躍user:Artoria2e5[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]請問是否有工具計算某個條目的正文字數?我認為可以將這資料與條目評選信息一同展示,讓評審者知悉與自行判決。--老陳留言) 2017年3月9日 (四) 01:34 (UTC)
    • 只知道有一個顯示選中區域字數的小工具可以作半自動判斷。理論上可以比那個小工具更自動、精確一點,自動選中所有的#mw-content-text > p(正文區域下每個直接下屬的段落(不含標題、代碼框等元素))計算字數並求和;不過即使這樣也還是需要有用戶(其實是瀏覽器HTML解析器)打開頁面才能準確計數,自動化起來比較煩。(可以用nodejs之類的寫個和瀏覽器捆綁的bot,但反正我是不想寫……)——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月9日 (四) 01:51 (UTC)
      • 我都用偏好設定中的字數統計功能來輔助。-- 寫作「源環」  讀作「PTMaea」  2017年3月9日 (四) 03:11 (UTC)
        • 嗯,說的就是那個東西。爬頁面解析、做beautifulsoup的事情去問問User:逆襲的天邪鬼User:WhitePhosphorus好了……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月9日 (四) 15:36 (UTC)
          • 只要處理DYK的機械人能夠加一個功能,分析條目源代碼,其實統計正文字數(即表格、模板、參考等以外的)應該不難。鋼琴小子 留言 貢獻 2017年3月9日 (四) 15:41 (UTC)
            • Antigng的BAG申請里有討論過bot計算正文字數的問題,我覺得沒那麼簡單。 --碸中嘌呤的白磷萃取 打譜 2017年3月9日 (四) 15:44 (UTC)
              • @WhitePhosphorus:總是對着源碼發功,不去管瀏覽器得到的網頁結構,當然搞不出什麼名堂。你要不要去WP:BOTREQ看看我那個方法?基本就是切掉第一段第一個粗體(輕小說標題)、所有lang不是zh的外文部分(輕小說標題)以及引用上標之後用某個小工具數字數加起來。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月16日 (四) 01:04 (UTC)
                • 我明明早就看過了……還在tg里贊過吧我記得。 --碸中嘌呤的白磷萃取 打譜 2017年3月16日 (四) 01:05 (UTC)
                • 老了,記性不好。現在遇到不驚訝的事情,記得最淺(按照各種壓縮算法的原則來說理應這樣?)、忘得最快……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 15:32 (UTC)
  • 訊息框都是內容一部分,條目是否符合DYK,應從整體質量考慮,沒必要硬性提高字數標準。DYK要的是條目符合關注度、可供查證、內容能表達條目主體要有的基本訊息。DYK作為鑑定新條目的標準,條目內容對條目主體覆蓋範圍較GA寬鬆也是正常的。就算把DYK內容字數硬性提高至5000字以上,但正文內容重覆,行文不順,未能清晰表達其意,大量內容未能查證,即使正文字數再多也不見得適合上DYK。--Thomas.Lu留言) 2017年3月9日 (四) 03:36 (UTC)
  • 「超過3000位元組」、「五日內重大修訂」、「無爭議模板」都是必要非充分條件。Thomas.Lu提到的一些條件比「位元組大小達到多少」充分多了。--逆襲的天邪鬼留言) 2017年3月9日 (四) 15:46 (UTC)

提議修改Wikipedia:非自由版權圖片大小的上傳上限

爭議連結,由於管理員Antigng提出掛Non-free reducee模板的質疑,10萬像素包含了從100000到109999,以至於在下掛模板,與他爭論過,但希望上傳上限能夠改成100000像素,以避免爭議。--小躍撈出記錄) 2017年3月6日 (一) 01:01 (UTC)

(+)支持,判處有期徒刑五年以下不代表可以判人五年零364天。--Innocentius Aiolos 2017年3月6日 (一) 04:39 (UTC)
(-)反對,10萬是任意挑選的一個數。除非有人證明100000像素和109999像素的非自由版權圖片在法律上的差別,否則oppose。--Antigng留言) 2017年3月6日 (一) 04:56 (UTC)
認為「10萬」可以達109999的說法明顯有違常識。 --達師 - 345 - 574 2017年3月6日 (一) 06:11 (UTC)
十萬就是十萬,為何會有個超越十萬的說法呢?若然要挑戰這項規定,則應為挑戰者提出證據證明放寬沒有問題。--J.Wong 2017年3月6日 (一) 06:35 (UTC)
證明100000和109999沒有差別是非常容易的事情。隨便舉個例子,此文件此文件在觀感上沒有任何的區別,沒有什麼細節內容因為尺寸的變化而變得看得見/看不見,然而它們的大小差了15%。說到底,還是那句話,10萬是隨意挑的一個數,其數值本身並沒有明確的物理意義,真正有意義的量是它的數量級。--Antigng留言) 2017年3月6日 (一) 06:42 (UTC)
定下十萬的首要意義是明確在某一數值處「切開」,任意大於該數值的大小都被我們認為是不可接受的。這比你所說的數量級更為重要。按你的要求,那麼十萬毫無意義(包括其數量級在內),因為沒有經過法庭判決,就無法證明任意數字的法律差別。 --達師 - 345 - 574 2017年3月6日 (一) 07:05 (UTC)
這十萬可以理解為在某一個準確的數切開,也可以是在某個數量級切開。如果把它理解為在某一個準確的數量上切開本身的合理性就有問題,上文已述,我想不出合理的理由這樣做。另一方面,之所以選擇十萬這個數量級,並不是有法律判決這個數量級以上為違法,而是因為這個數量級對應的圖片大小基本上就是正常排版情形下,我們在條目裡面能夠遇見的非自由版權圖片(不像自由版權的畫卷那樣可以很大)的最大尺寸。根據合理使用的要求,合理使用的圖片是為說明條目文本服務的,我們是在以文本中圖片的最大尺寸衡量非自由版權圖片的最大可能尺度。--Antigng留言) 2017年3月6日 (一) 10:35 (UTC)

《非自由版權圖片大小指引》是翻譯自英文版《非自由版權內容指引》相關段落,該段落於二零一一年八月廿四日加入,而討論時,表示加入此標準並非硬性規定,而是此標準在大部分情況下都適用。而如果未能符合此標準,則應該解釋為何不能。(「the number we feel comfortable around is about 0.1 megapixels in total size, which works for most movie posters, cover art, screenshots, and the like. But that is far from a hard limit. However, if you have an image that is not free and exceeds 1000px in one direction, you probably need good justification for that much detail.」)當時甚至有用戶提議加入範圍+/- 30%以防熱心用戶過份解讀。往後,一二年十二月十日則修訂為整數,十萬。是次修訂只是旨在提供更清晰標準,而非志在收窄規範。當然英文版立例精神是一回事,中文版是否要跟從則交由諸位決定。不過中文版翻譯時亦有寫道「大部分情況」,即謂可以有例外。當然,要例外,就要解釋了。即是如果少於十萬都已經能夠清楚顯示圖像細節,就應該解釋一下為何要大於十萬。--J.Wong 2017年3月6日 (一) 09:15 (UTC)

其實我不覺得因為有人上傳了一張大小為100001甚至999999的圖片然後就有人馬上過來打官司了。--逆襲的天邪鬼留言) 2017年3月6日 (一) 13:09 (UTC)

同意J.Wong意見。--Wcam留言) 2017年3月6日 (一) 13:41 (UTC)

贊同J.Wong說法,指引就是大部分情況需要遵守,如果不得已大於,必須解釋,這也是為了保護版權避免違反相關法律。--脳補。◕‿◕。讨论 2017年3月6日 (一) 15:03 (UTC)
總得找個位置立下死線,100000也好,110000也好。--Temp3600留言) 2017年3月7日 (二) 19:09 (UTC)
我支持設立一個死線,但可以有個上下浮動--百無一用是書生 () 2017年3月8日 (三) 08:09 (UTC)
上下浮動的範圍如果機器人不統一,也會有問題。 --碸中嘌呤的白磷萃取 打譜 2017年3月9日 (四) 03:43 (UTC)
我提議的死線已包含浮動上限,i.e. upper class boundary.--Temp3600留言) 2017年3月9日 (四) 03:52 (UTC)
不建議訂下所謂死線。有些圖若然縮得太細,會導致細節無法顯示。大於十萬的圖檔,應該由人手判斷其理由是否合適。理由合適即可。判斷為可大於十萬以後,所謂的上限就應該因圖而異。--J.Wong 2017年3月10日 (五) 16:36 (UTC)
@Wong128hk:你誤解了。這個死線是給bot判斷用,不是給人用。--Temp3600留言) 2017年3月10日 (五) 17:08 (UTC)
我的機器判斷程式的浮動上限為50總像素。--小躍撈出記錄) 2017年3月10日 (五) 23:51 (UTC)
50總平方像素麵積容限跟沒有幾乎無區別。至少請參照User:Cwek的容限(100,000*5%=5,000平方像素),確保自己不要把人做過的也標了。寫的什麼bot真是。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月11日 (六) 05:13 (UTC)
在下應該沒有理解錯誤……就是說不建議訂立十萬 +/- X% 的 +/- X%。而是機械人直接以十萬作判斷。若然過了,就提示上傳者填寫理由。再交人手判斷理由是否合適。因圖制宜,而非劃一縮到少於十萬,或十萬 +X%。這樣應該更符合指引精神,亦更貼合運作需要。--J.Wong 2017年3月11日 (六) 06:19 (UTC)
eagerbot 本來就不會把圖片縮小。它只會掛模版。--Temp3600留言) 2017年3月12日 (日) 17:30 (UTC)

非自由版權圖片太小了

關於改善WP:簡繁轉換中新添加的異體字轉換方針

針對最近對於WP:簡繁轉換中增加有關異體字的轉換問題,我覺得應該進一步修繕,原因是原來的指引沒有突出重點,我建議修改成這樣:

歡迎各位發表意見或者改善語句,如無反對意見,將會對指引進行修改。--Dqwyy談笑風生正在沉迷CLANNAD回復請ping 2017年3月9日 (四) 04:10 (UTC)

@Dqwyy::建議對於台/臺二字的部分,在「不應該對其進行手動轉換」改為「除非該處存在官方既定用法,而現有字不是官方用法,否則不應該對其進行手動轉換」之類的字句。pinchuanc留言) 2017年3月9日 (四) 04:50 (UTC)

感謝建議。不過我認爲維基百科是以第三方的角度來講述條目內容,如果官方有既定用法的話,也是沒有必要特地轉換成官方用字的。因爲這個轉換從某種意義上來講是「簡繁轉換」了。(果然我推測得沒錯,這個討論的重點還是放在「台/臺」的問題上 囧rz...--Dqwyy談笑風生正在沉迷CLANNAD回復請ping 2017年3月9日 (四) 05:07 (UTC)
我的意思是,機關名稱還是要以官方全稱為主。否則感覺會跟「名從主人」原則矛盾。當然,條目內的文字沒有必要限制。pinchuanc留言) 2017年3月9日 (四) 06:22 (UTC)
「台/臺」的問題上,基本上就是名從主人,先到先得,和3RR。有需要設這麼多方針嗎? --Hello World! 2017年3月13日 (一) 01:36 (UTC)
雖然關係不大,但是香港也是用「床」的。—AT 2017年3月9日 (四) 15:44 (UTC)
政府文件使用「牀」,民間應該因為輸入或者書寫方便而轉用「床」。現時小學就應該兩者都有教。此來源則講述「牀」如何變成「床」。而的而且確,「爿」本義就是「牀」。--J.Wong 2017年3月10日 (五) 03:01 (UTC)
先不對台和臺的問題發表意見。其他部分支持。--逆襲的天邪鬼留言) 2017年3月13日 (一) 05:43 (UTC)
對於同音同義異體字A/B:
  1. 如果所有地區皆常用A,罕用B→可將源碼B直接改為A,不宜使用轉換。
  2. 如果某些地區常用A而罕用B,某些地區常用B而罕用A→源碼文字先到先得,不得修改,同時全局轉換。
  3. 如果所有地區混用A/B→源碼文字先到先得,不得修改,不得使用轉換。
  4. 如果某些地區混用A/B,其他地區常用A而罕用B→源碼文字先到先得,不得修改,其他地區可使用轉換。—Chiefwei - ) 2017年3月17日 (五) 07:06 (UTC)
(:)回應:感謝您的建議,這樣表達起來簡潔多了。--Dqwyy談笑風生正在沉迷CLANNAD回復請ping 2017年3月20日 (一) 13:22 (UTC)
【以下留言來自Special:Diff/43701117】但是我覺得,對於影視、遊戲等的虛構人物、地名、物品名等,我覺得還是以官方的寫法為準。例如說英雄聯盟里的一個虛構地名——暗影岛,英雄聯盟台灣地區代理商官方是將其寫為「闇影島」,而不是「暗影島」,而且,在港澳台地區基本上都是這麼寫的,所以就應該以官方為準,寫成闇影島。(維基百科可能不會允許創建「闇影島」這個條目,但是由於我比較忙碌,一時找不到更好的例子,再說這個詞在一些條目中也有,於是就只好舉這個例子了)。-Sprt98留言
只要「闇影島」是常用寫法,我們自然就會拋開「它是異體字」這一點,在「闇影島」這個特例中以「闇」字為正。--逆襲的天邪鬼留言) 2017年3月21日 (二) 15:19 (UTC)
台服官方的確是闇影島,我是覺得繁簡處理會改成正體字嗎?比如說李傑,會寫成「傑」。-Neville Wang 奈威 2017年3月21日 (二) 15:42 (UTC)

{{封禁申訴}}模版的長時間存留的疑問

封禁方針「需要封禁的情況」段落修訂討論

Template:No consensus pilot retention的問題

修改保護方針

結論:容許對存檔頁面設置永久全/半保護。--Temp3600留言) 2017年3月18日 (六) 10:42 (UTC)
我個人較贊成半保護,因全保護可能爭議過大。--Temp3600留言) 2017年3月18日 (六) 10:42 (UTC)

提案:修改WP:保護方針有關存檔頁保護的條款

當下,保護方針對存檔頁保護的定位是臨時保護。然而這個條款處於「臨時保護」這個定位有點奇怪,如果是因為破壞而保護的話,則和臨時保護章節下的第二條差不多。如果是為了防止鬼祟破壞而保護的話則應該屬於「永久保護」的範疇。因此,我提議把這條移到上面的永久保護章節去。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 06:42 (UTC)

  • 議案相類,合併討論。--J.Wong 2017年3月17日 (五) 07:46 (UTC)
(-)反對:全保護「不是用來預防可能會發生的破壞」--Maccomcre留言) 2017年3月18日 (六) 00:51 (UTC)
@Maccomcre:那麼閣下是認為應該把現有條款刪除?因為現有的對存檔頁的條款和「若頁面或圖片近期被封禁用戶進行頑固破壞或頑固編輯,則實施保護」的性質一樣。都是用來防止破壞者進一步破壞的。——꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 02:30 (UTC)
感覺坡滑大了。「預防可能事件」否決的更接近是憑據較少,帶「水晶球」性質的保護;被近期頑固反覆破壞、編輯的個別頁面矛頭對得則很清楚。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月18日 (六) 03:54 (UTC)
那首頁、高風險模板、Mediawiki介面、css及js編碼及他人用戶頁呢?為何這些保護又不是「不是用來預防可能會發生的破壞」?又不是「憑據較少」?的而且確,維基百科是開放予眾人編輯的,不過應該是局限於主名字空間、分類、幫助、普通較少連接的模板、維基百科內各空間下的討論區等空間,但必須承認維基百科內有部分空間是要限制用戶編輯。以減低維護成本。存檔的而且確,僅供參閱已經可以,並毋須亦不應修改。維基百科存檔眾多,閣下肯定有鬼祟破壞時,可以有人第一時間發現?--J.Wong 2017年3月18日 (六) 05:06 (UTC)
「除非被保護頁面是高風險頁面」,條款的原本意思是低風險頁面不需要預防,而存檔是不常查看的頁面,低風險,所以存檔應該被嚴重破壞才能全保護。--Maccomcre留言) 2017年3月18日 (六) 08:20 (UTC)
存檔並非不常查看,在查找過去的討論時往往要找存檔。由於大多數存檔頁(比如:WP:VIP和互助客棧的存檔)都是由機器人自動生成的,幾乎沒啥人監視。我認為,此類頁面擁有中等可見度、低破壞幾率、低反破壞效率、無需編輯的性質。論一個頁面是否是高風險頁面不僅僅是看這個頁面是否是容易被破壞,而是要結合反破壞效率一起看。根據存檔頁極低的監視率,一旦受到鬼祟破壞(明顯的破壞很可能會被最近更改巡查回退)則難以被發現。由於具有中等的可見度,不能保證閱覽者里沒有高級破壞者。並且,此類頁面一般無需修改。而且,管理員也沒有那麼多精力盯着Special:未受監視頁面看。綜合以上所述,「無需編輯」的性質和維基百科的精神「人人皆可編輯」不衝突,加上此類頁面是高風險頁面(低反破壞效率並具有極高的信任度),我覺得應該實行保護。——꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 09:27 (UTC)
始終不太同意,可見度比條目低,說是高風險都太過分,查看存檔時自然也要先查看歷史,查看歷史自然便會找到鬼祟破壞。查看存檔不事先查看歷史是用的習慣有問題。--Maccomcre留言) 2017年3月22日 (三) 00:18 (UTC)
有誰看任何一個頁面都會去看編輯歷史的?看一個頁面的同時看編輯歷史應該只是個別人的習慣。雖然這是一個好習慣,但你不能保證每個人都會去看編輯歷史。同樣,閣下也不能保證每個查存檔的人都能發現鬼祟破壞。這就是為什麼我認為存檔頁是「高風險」。——꧁༺星耀晨曦༻꧂留言) 2017年3月22日 (三) 00:58 (UTC)
贊成保護。我同時贊成J.WONG的說法:"開放予眾人編輯"的部分只限於那些編輯可以為維基帶來好處的部分。編輯存檔絕少對維基有好處。--Temp3600留言) 2017年3月18日 (六) 10:46 (UTC)

===結案及公示===

  1. 容許對存檔頁面設置永久半保護。

現公示七日。如無異議,即行修改。--Temp3600留言) 2017年3月19日 (日) 10:10 (UTC)

  • (-)反對,只是討論了不夠一星期便結案?太快了,而且討論人數都少,中間還有人反對,根本不能當作有初步共識。--Maccomcre留言) 2017年3月19日 (日) 11:48 (UTC)
  • 的確,過於倉猝,如果收窄範圍至某幾類存檔或者只是經管理員評估過後覺得需要保護才施行永久全保護,又如何呢?--J.Wong 2017年3月19日 (日) 12:42 (UTC)
  • 一位IP用戶修改他人留言的編輯已被撤銷。—john doe 120talk) 2017年3月19日 (日) 15:11 (UTC)
  • (-)反對,沒必要這麼做。除非存檔頁面被破壞多次,通常管理員會視情況實施保護。--小躍撈出記錄) 2017年3月22日 (三) 01:12 (UTC)
    • 閣下認為會有用戶察覺到破壞?我覺得,除非有人盯着最近更改看,一個存檔頁被破壞者刪了80%的破壞都沒人會發現。——꧁༺星耀晨曦༻꧂留言) 2017年3月22日 (三) 01:45 (UTC)
  • 半保護會是一個可行方案。--1233|聯繫我 2017年3月22日 (三) 06:57 (UTC)
  • 討論頁存檔的話我覺得全保護也沒什麼,本來就不需要編輯的地方。--淺藍雪 2017年3月22日 (三) 15:47 (UTC)

快速保留中的提刪者被禁止編輯

禁止編輯四字連結到Wikipedia:編輯禁制方針,但此未生效。若是指封禁,那是在提刪前還是提刪後,記得之前有人跟我說是提刪時已經被封禁,那也很矛盾,被封禁不就不能提刪了。--A2093064#Talk 2017年3月14日 (二) 09:54 (UTC)

應該是說不斷的提刪吧?尤其是心生不滿之類的報復提刪?--小躍撈出記錄) 2017年3月14日 (二) 23:16 (UTC)

應該是提刪後。根據過去的經驗,管理員不可能因為提刪者有被封禁過的紀錄而直接快速保留的;提刪時已經被封禁更不可能,因為被封禁時不可能提刪。--M940504留言) 2017年3月15日 (三) 03:15 (UTC)
@小躍:不斷的提刪可以適用前一條「提刪者純粹以破壞或擾亂為目的」。--A2093064#Talk 2017年3月15日 (三) 09:45 (UTC)

有償編輯定義被無限上綱

因為曾素芬這個條目的存廢討論,我注意到一件事情:因為編寫者User:翁何文曾經在自己的對話頁表示曾素芬是他的友人[9],所以條目被掛上了Template:Connected contributor。但我認為這是隨意擴大了「有償編輯」的定義。如果因為「想幫朋友寫條目」是有利益衡突,那麼幫偶像寫條目、幫自己支持的球隊寫條目、幫自己最喜歡的食物寫條目,都有相似的情感因素,甚至熱情程度還勝過幫友人撰寫,大家通通都得來揭露一番才能寫作了嗎?

事實上在基金會的使用者條款之中,很明顯地只限定「Paid contributions」才是有需要揭露的編輯;而這個 Paid 的定義,在未揭露有償編輯問與答」中有明確的指出 compensation 是 an exchange of money, goods, or services,也就是金錢、貨品或服務的交換。除非有證明顯示該編輯替友人寫條目後可以換得友人付稿費、送禮物、請吃飯,或者按摩…不然單純的「條目主角是我朋友」根本不會構成必須揭露的理由。

希望社群能注意這樣無限上綱的現象。--Reke留言) 2017年3月18日 (六) 06:39 (UTC)

不好意思造成大家困擾,二十年前我曾在她的球技領域上協助過,所以是友人,然其在2002年已過世,至今已快十五年,我並不了解利益衝突、有償編輯的點在那?我本身是影視音樂幕後製作者,於2006年亦曾回保齡球界擔任中華民國保齡球協會秘書長,無論台灣或國外的球界或演藝圈人士都幾乎認識,只是單純想説為何維基𥚃沒有這人物的條目而給予編輯建立,建議應該以編輯的內容,是否包含真的涉及到不中立丶或商業宣傳來看待編輯建議,也請看該條目不可避免的一點,𥚃面提到了其過世的因素,這是屬於負面並不光彩之處,但基本上我必須中立的編寫,保存這人物的資料,畢竟是真正發生的事,誰會有償的請別人編寫其負面?更何況已過世十五年,誰要給我任何償?我不太能了解這部分。翁何文留言) 2017年3月18日 (六) 07:21 (UTC)

最近正在翻譯COI的內容……如果是有償編輯,就會使用「Connected contributor (paid)」模板了吧。另外依照英語維基百科的標準,普通的利益衝突(如自己、家人、朋友、政府雇員等等)還是建議主動提出關係、掛模板,並不建議參與直接編輯。而同樣是利益衝突項目之一的「有償編輯」(明確有金錢來往),就是必須要揭露相關聯的內容。--KOKUYO留言) 2017年3月18日 (六) 07:44 (UTC)

只要編寫的內容符合三大內容方針,編輯者再怎麼利益衝突也無妨。——꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 08:05 (UTC)

終於了解一件事,大家lD都幾乎不使用本名,就我沒去避免這lD名稱的部分,所以造成很多麻煩。總認為自己得為自己發出的文字負責,所以在網路照樣使用真名翁何文留言) 2017年3月18日 (六) 08:13 (UTC)
@星耀晨曦:我對這說法有保留,因為避免由有利益衝突者編輯是避嫌的做法。就如政府官員需要申報利益的情況。——愚蠢的人類
但是維基百科不一樣。它是百科全書,只要加入的內容符合三大內容方針和版權方針,有什麼必要讓利益衝突的編輯者避嫌。——꧁༺星耀晨曦༻꧂留言) 2017年3月20日 (一) 07:07 (UTC)

如果單純用利益衝突去提刪條目,當然不妥。但顯然提刪者並非因為有利益衝突而提刪。而本人覺得英文版指引的建議亦非難以實行,就是避免直接參與編輯,需要參與時就在討論頁邀請其他用戶去同行評審,無問題則可加至條目。終歸旁觀者清,關係對觀點有多少影響是難以評估的,可能自己確信我不會受到關係影響,但第三者眼中可能是另一回事。先交予其他人去評審就可以避免這種情況,又不會有明明我覺得沒問題,為何總要回退我的編輯,這種壞感覺。可以透過溝通去解決這些問題。這些和是否用真名並無太大關係。--J.Wong 2017年3月18日 (六) 13:15 (UTC)

我是不太了解提刪者是因何點而提刪,倘若要避免直接參與編輯,恐怕這個條目永遠不會有人提,會編輯維基的人不太知道這人物,所以肯定不會提,知道她的人也未必會編輯維基,光看她的戰績輝煌,生前也沒人提此條目(可能維基還沒成立),過世後15年內也並無任何人提編此條目,我只是剛好在學習編輯,才把這條目編輯起初稿來,我知道後面將有更多人來查此資料順便增加編輯,就由他們接手這才不失中立也可避免很多事。翁何文留言) 2017年3月18日 (六) 15:16 (UTC)
提刪的原因主要還是語句上有些主觀的寫法,比方說我們應該避免寫一個選手「成績優異」這樣帶有評論的語句,而應該寫「在5年之內得到國內所有一級賽事的獎項」或者「勝率連續3年保持7成以上」,這一類客觀的數據或紀錄。前者易被中文維基的一些編輯認定有「宣傳」嫌疑,我個人認為這樣的認定太過嚴苛,但是一個人人都可以編輯及提出質疑的社群,有這樣的提刪是免不了的。據理力爭就是了。--Reke留言) 2017年3月18日 (六) 20:09 (UTC)
我大概了解你的意思,但是人人可以編輯,卻沒有人來幫協助修飾語氣讓條目更完善,也是很可惜的一件事,當然也有很多編輯者提供了連結來源以增加其可信度。翁何文留言) 2017年3月19日 (日) 03:25 (UTC)
大家都是志工,有時難免無法要求其他人熱心幫忙。而且有時候不熟悉的人可以看出錯誤,卻很難改善。這點也是我們一直強調需要更多人加入,而且面對質疑要大膽回應,不要過早沮喪退出的原因。多多加油,其實很多老手以前早期的作品也是被嫌棄過的。--Reke留言) 2017年3月19日 (日) 10:39 (UTC)
昨天Wikipedia:利益衝突改了,我好奇修改完之後的內容會不會產生像中共所說的「擴大化」那樣的影響。--逆襲的天邪鬼留言) 2017年3月20日 (一) 14:44 (UTC)
目前暫時只是篇論述的話,我是覺得不用強烈評論。但看完內容後,根據推廣工作的經驗,這篇內容若嚴格執行,維基條目的寫作情況會大幅下降。我個人的觀點不應該去建議大家迴避所有沾得上邊的利益衝突,有金錢、貨物、服務交易的利益衝突都可以在「揭露」及「依循中立原則」的前題下進行,其他利益上更少的部分只需要提出心理建設,使他們了解維基的編輯形式會使他們心中的期待有所差距,這樣就可以了。--Reke留言) 2017年3月22日 (三) 06:38 (UTC)

修訂「維基百科不是什麼」「維基百科不是印刷品」段落

翻查記錄,《維基百科不是什麼》已有一段時間未曾更新。以下新舊條文並列,各位可藉此討論一下此段落是否需要更新。

現行條文

== 維基百科不是什麼 ==
=== 维基百科不是印刷品 ===
維基百科不是印刷品。維基百科沒有條目數量限制,只要題目能獲得查證並符合以下條件,即可寫成維基百科條目。

維基百科作為互聯網上的作品,可以包括鏈接、最新的資料等。維基百科的內部連結及重定向功能,也可以讓讀者搜尋到相關適合的條目。

這表示傳統印刷品的文字長度,並不一定適用於維基百科。但從實用性的角度考量,條目的大小應該顧及使用撥號連線的讀者。當條目變得過長的時候,可以考慮將條目分拆出幾個較小的條目,原條目的相應段落則保留原文的概要,並指向拆分出去的主條目。

這也表示你不用把比較冷門的條目直接指向其他同義的常用字詞,你可以保留此冷門條目的內容再加上「參考」一節,在這裡加上指向同義字的連結。

提議條文

== 風格 ==
=== 維基百科不是印刷品 ===
維基百科不是印刷品。維基百科並未有限制條目或者主題數量,只要條目能夠獲得查證並符合以下條件,即可寫成維基百科條目。維基百科有所為而有所不為,是故條目必須恪守相關內容方針,尤其各項五大支柱提述過的方針。收錄標準亦非僅僅不違反下列要求。

維持條目於合適長短有助於讀者存取及閱讀。決定條目長短時尤其需要顧及撥號連線或者移動瀏覽器使用者,因為長度會直接影響到下載時間(見Wikipedia:條目長度)。當條目逐步發展時,就可能需要分拆。分拆以後,原文則應該保留概要。(Wikipedia:摘要格式)傳統紙本百科全書之中,有些主題篇幅會較短、較穩定。而維基百科則可以收錄更多資料,亦可以提供更多鏈接,以及可以更新得更快。

== 百科內容 ==
單單真實及有用並不等於可以收錄入百科全書。維基百科條目毋須收錄每一個細節,而是應該總結經過評審及得到認可的知識。條目內容須可供查證,亦應附有來源,而其篇幅則應按合理比重分配。下列每段準則都會附有例子,但這些例子並非志在涵蓋所有情況。

歡迎提出意見,及其他修改方案。謹此。--J.Wong 2017年3月19日 (日) 14:46 (UTC)

「單單真實及有用並不等於可以收入百科全書」其中的「收入」是否可改為「收錄入」?之後的「維基百科條目毋須收入每一個細節」其中的「收入」是否可改為「收錄」?謝謝--Wolfch (留言) 圓周率協作中 2017年3月19日 (日) 19:33 (UTC)
已改。--J.Wong 2017年3月20日 (一) 03:04 (UTC)

有些加長了,我認為那一頁儘可能的維持簡明易懂比較好。--Jasonzhuocn留言) 2017年3月22日 (三) 09:12 (UTC)

的確此段內容有所增加,不過整體而言,長度應該無太大變化。--J.Wong 2017年3月22日 (三) 14:02 (UTC)

(+)支持加了鏈接清晰不少。——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 15:55 (UTC)

修訂「維基百科不是什麼」「維基百科不是詞典」段落

翻查記錄,《維基百科不是什麼》已有一段時間未曾更新。以下新舊條文並列,各位可藉此討論一下此段落是否需要更新。

現行條文

=== 维基百科不是詞典 ===
維基百科不是詞典、說明書或術語指南。如果您對使用維基技術編寫詞典感興趣的話,請到維基百科的姊妹計劃維基詞典。維基百科條目不是

  1. 詞典式的定義。維基百科既然不是詞典,請不要光為了寫定義而新建條目。條目通常應該由定義開始,如果你看到的條目只有定義,請嘗試添加適合百科全書的內容。
  2. 定義列表。不過,消歧義頁面可以用於闡明意思籠統的詞彙。維基百科也有專門領域的相關詞彙表。
  3. 說明書,也不是口語、行話或成語教材。維基百科並不用於解釋某些詞彙該如何使用、也不用於指導讀者成為方言通或者網絡術語專家。不過作為百科全書條目,某些意思相近、容易混淆的詞語可能需要特別着重解釋,如「公民」和「國民」的關係。某些個別口語詞也可能值得寫成百科全書條目。

提議條文

=== 維基百科不是詞典 ===
維基百科不是詞典、說明書或術語指南。維基百科條目不是

  1. 詞目。條目開首的確應該有完備定義或形容,但是除了定義之外,亦都應該有其他百科內容。如果無法擴充,只有定義,則不應收錄。當然,有時字詞的定義可能值得收錄。維基百科有姊妹計劃維基詞典專門收錄詞條。字典式定義應該匯出至該站。
  2. 定義列表。百科全書條目主題可以是各樣事物,有時字詞或短句本身就是百科題材。不過,一篇條目甚少會有多於一個定義互相分明無關或者其標題有多於一個用法。若然數字本身在文化或數學上相對重要,值得講述,則亦可收錄。
  3. 說明書,也不是口語、行話或成語教材。條目可用以描述語言、方言或俚語,不過就不應該成為語言教材。詳見「維基百科不是手冊、攻略書、教科書或科學雜誌」。維基百科有姊妹計劃維基教科書專門收錄語言教材。語言教材應該匯出至該站。

歡迎提出意見,及其他修改方案。謹此。--J.Wong 2017年3月19日 (日) 14:46 (UTC)

需要注意的一個事實:在百度百科中,詞條一詞與條目均是 article 的意思。#ForeverLove I miss the pillow talk. 2017年3月22日 (三) 14:43 (UTC)
修改為「詞目」吧,應該沒歧義了。--J.Wong 2017年3月23日 (四) 04:49 (UTC)

(+)支持鏈接處理更為完備。容易混淆詞彙要還留着嗎?——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 15:54 (UTC)

已更改。--J.Wong 2017年3月23日 (四) 16:18 (UTC)

關於匿名編輯IP地址改編後,編輯原先IP地址留言的問題

這是一個不重要的事件,因為發生的頻率比較低。不過最近發生了爭議,而且是方針的空白,因此,我想最好明確一下。

情況是,假如一名IP用戶,23.4.5.6,留下了一段留言。一段時間以後,另一個IP地址,23.4.8.9,對前者的留言進行了編輯(在之前發生的個例中,同樣修改了簽名)。問及為什麼後者編輯前者留言時,8.9君說到,5.6和我是一個人,IP變了而已。那麼就出現一個問題,這樣的編輯是否允許?

討論頁面指引說,不要編輯他人的留言。那麼問題的關鍵就在於,如何判斷23.4.5.6和23.4.8.9是不是一個人。在最近的一次爭議中,Innocentius認為,需要有8.9君提供可信的證據表明自己是5.6君,然後才可以編輯。或者至少,可以在5.6的留言後面加上一個新的簽名,向讀者解釋自己和5.6是一個人,然後由讀者判斷是否可信。不允許的是,直接編輯5.6的留言。而Antigng認為,AGF要求對編輯着善意推斷,所以巡查員遇到這件事情的話,就要geo IP查詢。除非發現兩個IP很可能不是一個人,否則不應該阻止8.9編輯5.6的留言,因為編輯自己的留言是一種權利。

在這件事情上,我的感覺是,如果你的IP變動了,那麼就不能再編輯以前的留言了,因為別人很難知道你究竟是真的是同一個人,還是在謊稱同一個人。巡查員不是CU,如果要求巡查員們AGF每一筆這種編輯,然後在geo IP,未免強人所難。所以我傾向於不允許這種編輯。我希望通過這個討論,達成一個共識,然後記載下來,避免類似爭議再次出現。Bluedeck 2017年3月20日 (一) 08:41 (UTC)

同意bluedech所言。--Temp3600留言) 2017年3月20日 (一) 08:55 (UTC)
完美的惡搞傀儡名字……[開玩笑的]——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 15:58 (UTC)
bluetech?(難聽)--Innocentius Aiolos 2017年3月23日 (四) 16:05 (UTC)
開車技術[開玩笑的]。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 16:07 (UTC)
bluedesk?-Neville Wang 奈威 2017年3月23日 (四) 16:08 (UTC)
File:Bluedicks.jpgUser:Bluedick。--Antigng留言) 2017年3月23日 (四) 16:11 (UTC)
認同,不過允許「聲明」,不能自行修改,因為應該由其他人根據編輯習慣,whois信息等去自行判斷是否屬實;而且修改「別人」的討論本身就是不允許的,避免漏洞,而且頻繁IP變動的話,這樣修改也顯得不實際。——路過圍觀的Sakamotosan 2017年3月20日 (一) 09:13 (UTC)
認同,我的意見如樓上Sakamotosan一樣。IP用戶不得擅自更改其它IP的留言,但可以在下面的討論中聲明自己是剛剛在上面參與過討論的另外一個IP。——꧁༺星耀晨曦༻꧂留言) 2017年3月20日 (一) 10:37 (UTC)
(-)反對,四件事情:
  1. 第一件事情,匿名用戶和註冊用戶一樣,有權利編輯自己的留言。這種權利是必須授予任何用戶的。一個用戶在衝動之時留了不恰當的言,事後他冷靜下來,當然可以,並且應該收回這些不恰當的留言,為了達到這個目的,他需要編輯自己的留言,比如刪除/划去過激的部分,而不是在下面留言解釋。再則,如果用戶不小心在留言之中暴露了自己的隱私,那麼他當然需要編輯留言,刪除這些內容,在下面解釋毫無用處。對註冊用戶是如此,對匿名用戶也是如此。
  2. 第二件事情,匿名用戶完全無法預測他的IP有沒有變動。註冊用戶掉登陸,提交編輯會出token error,此時他還需要至少再保存一次才能成功做出編輯。匿名用戶則不然,就算他前一秒鐘看過Special:我的貢獻,也沒有任何機制保證他後一秒鐘的編輯不會發生IP上的變動。如果方針/指引要求匿名用戶發現自己IP變動之後不修改自己的留言——那麼,實際上這是在要求匿名用戶做一件他自己都做不到的事情。
  3. 第三件事情,查證一個匿名用戶加入的內容是真實還是虛假的遠比geo IP來得複雜,前者還涉及透過google搜索相關的來源,後者只需要點開用戶貢獻頁下面的鏈接。而且修改他人留言在維基百科上本來就罕見,匿名用戶修改匿名用戶的留言,則更是罕見,故而完全不認同這件事對巡查員有過分的要求。退一步說,就算查證geo IP是一件相當複雜的事情,維基百科不強迫他人參與。沒有人強迫巡查員去回退他吃不準的編輯,何來「強人所難」之說?
  4. 第四件事情,維基百科的方針指引從來就不是為了保證一切制度沒有漏洞而設計的。維基百科不允許真人傀儡,不允許站外騷擾,但是它也只應該接受明確的證據,儘管這種對證據的苛求會誤放走很多進行上述不當行為的用戶。破壞方針如是說,只要用戶懷有改善維基百科的意願,那麼他們的編輯就不屬於破壞。善意推定指引要求用戶在沒有證據證明用戶的惡意的情形下,假定用戶懷有改善維基百科的意願。以上種種無不論證了以下這個我的個人觀點:在維基百科上,寧可漏判也不應該錯判。錯判的後果是很嚴重的,在現在這個案例之中,如果匿名用戶真的是在修改自己的留言,巡查員卻回退之,誰能確保這個匿名用戶不因此而認為那個巡查員是在誣陷用戶,又有誰能保證匿名用戶不會因此離開維基百科,維基百科再流失一位新用戶?--Antigng留言) 2017年3月20日 (一) 10:48 (UTC)
認同,沒有更新的意見。--Innocentius Aiolos 2017年3月20日 (一) 13:42 (UTC)
這種情況確實還是第一次見,如果不是常見問題,建議是個別問題個別分析。如果此時訂立規則,可能會有較多疏漏。是我的話估計根本看不見ip的變動而默認那兩個ip是同一個人了。。。[開玩笑的]--Tiger留言DDL是第一生產力 2017年3月21日 (二) 21:53 (UTC)
雖然我同意Antigng的主張,認為不應該將這種編輯完全禁止,不過我認為有必要先想想如果1.2.3.5主張他是之前的1.2.3.4並改了他的留言後,又有一個1.2.3.4上來主張他才是1.2.3.4並反對修改時,社群的處置原則。--Reke留言) 2017年3月22日 (三) 17:57 (UTC)
當下我會視同IP同一個人,所以我會回退另一個IP編輯,因為我不是CU,我也不能完全相信2個IP君誰說的話是真的,Antigng說「匿名用戶完全無法預測他的IP有沒有變動」,我們也沒辦法預測他就是剛剛的IP君,如果可以修改另一個人留言不算破壞的話,那就跟規定相違背了。-Neville Wang 奈威 2017年3月22日 (三) 18:43 (UTC)
理論上,任何一個帳戶都有可能被盜用,任何一個賬戶也可能是其他帳戶的傀儡或真人傀儡。您同樣也不知道。但是,在這種沒有找到充分證據的情形下,您是不能指認某個帳戶被盜/是另一個帳戶的傀儡,尤其是在很多跡象表明用戶編輯模式未出現明顯異常/兩個賬戶編輯傾向明顯不相同的情形下。修改他人的留言,使之傳達出完全不同的意思,當然屬於WP:VAND。同樣地,盜別人號、濫用多重帳戶雖不屬WP:VAND,但是危害性比VAND更大。然而如果沒有證據,「視不同IP不是同一個人」(這裡修改了您的留言,因為邏輯上,「視同IP同一個人」推不出它的否命題「視不同IP不是同一個人」)也正如「視某某賬戶為盜號者所有」、「視某某賬戶為真人傀儡」,都是不可以的。--Antigng留言) 2017年3月23日 (四) 09:27 (UTC)
我是按照規定「破壞他人留言」去回退並警告,如果他真的是剛剛的IP君,應該要在下方留言而不是修改原先的留言,不是認為他是傀儡或是遭到盜用。-Neville Wang 奈威 2017年3月23日 (四) 09:53 (UTC)
應該要在下方留言而不是修改原先的留言[來源請求],用戶都有權編輯自己的留言。--Antigng留言) 2017年3月23日 (四) 10:24 (UTC)
無語...-Neville Wang 奈威 2017年3月23日 (四) 11:08 (UTC)
其實前提就是每個用戶,包括IP用戶,都是一個「獨立的」賬號,所以優先會認為這樣是篡改他人對話。雖然我們可以通過whois,編輯習慣的去判斷這個IP用戶和另一個IP用戶是否同一個真實人,或者由其聲明,但是從執行上有不準確性,所以假定賬戶獨立容易執行,而且也同樣符合規則。——路過圍觀的Sakamotosan 2017年3月23日 (四) 12:31 (UTC)
提請注意CU在辨析IP時的用處僅限於比較瀏覽器種類異同。——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 15:58 (UTC)

西北太平洋缺乏關注度的熱帶氣旋條目保留與否

過去西北太平洋缺乏關注度的熱帶氣旋條目一向都會被刪除,可是有不少人(包括在下)認為所有西北太平洋的熱帶氣旋都應該保留,因此在下希望在此訂下共識,以決定這些條目保留與否。

在下認為這些條目都應該保留,因為:

  • 大部分西北太平洋的熱帶氣旋都曾經作出登陸。
  • 希望格式統一,不要在太平洋颱風季條目裏,有些有主條目,有些沒有。
  • 如果把這些條目合併至當年太平洋颱風季,將會有太大堆文字而造成閱讀困難。——Morgan Siu留言) 2017年3月20日 (一) 13:07 (UTC)
(!)意見:在風季條目之外另立時間軸條目,把相關事件記錄進去就好了。—以上有簽名的留言由R96340對話)加入。 2017年3月20日 (一) 15:28 (UTC)
移動至條目探討?--Innocentius Aiolos 2017年3月20日 (一) 17:45 (UTC)
我想提出者是為了在方針中制定關注度豁免(參見Wikipedia:存廢覆核請求#熱帶風暴盧碧 (2016年))而來到方針區提出—以上有簽名的留言由R96340對話)加入。 2017年3月21日 (二) 00:43 (UTC)
若另立時間軸,會變成只寫升降格時間。(參見颱風紅霞討論頁)——Morgan Siu留言) 2017年3月21日 (二) 01:22 (UTC)
那就不要只寫升降格時間就好了。或是有主條目的風暴寫升降格時間,沒有主條目的寫詳細發展過程這樣,反正也不是什麼嚴重的大問題。—以上有簽名的留言由R96340對話)加入。 2017年3月21日 (二) 01:36 (UTC)
還是那個問題——將會有太大堆文字而造成閱讀困難。——Morgan Siu留言) 2017年3月21日 (二) 07:27 (UTC)
全文用連貫性記述文字的話就不會有這個問題,我先寫寫看,真的看起來太冗長的話再想辦法Draft:2016年太平洋颱風季時間軸在期間歡迎繼續提出建議—以上有簽名的留言由R96340對話)加入。 2017年3月21日 (二) 08:06 (UTC)
那為甚麼不乾脆保留所有颱風頁面呢?——Morgan Siu留言) 2017年3月22日 (三) 00:31 (UTC)
因為有些颱風關注度不足。—以上有簽名的留言由R96340對話)加入。 2017年3月22日 (三) 01:05 (UTC)
(?)疑問:即是怎樣寫,可否寫一次試試看?——Morgan Siu留言) 2017年3月22日 (三) 14:29 (UTC)

版權如何滿足「原創性門檻」?

下述文件因為「只有簡單幾何圖形和文字,不滿足原創性門檻」,而落入公有領域:

相較之下,這些文件卻被認為存在版權(截至留言之時):

那麼,就出現了疑問

首先必須說明,一個文件有沒有滿足原創性門檻不是共識說了算的,此外文件是否收到商標保護和是否收到版權保護也沒有關係。即便如此,仍然有這種疑問,那就是大家是否都能同意,上面列出的有版權文件的原創性有很多在PD文件之下,無妨重標PD,移動到C區去。像中國集裝箱這種連看都不用看一眼就知道這種文件肯定不符合原創性門檻。除此之外,可否同意在任何人發現此種情況時,直接移交C區這一問題。我本人在認識到這一情況後,十分想直接把這些文件移到C區,但是由於文件數量太多,並且涉及法務,因此放置於此參考。Bluedeck 2017年3月22日 (三) 08:51 (UTC)

以前英文維基百科有個機器人可以自動移動被人工覆核的自由版權圖片到c區,不過現在好像掛了。要自己手動通過腳本來移動到c區。——꧁༺星耀晨曦༻꧂留言) 2017年3月22日 (三) 10:26 (UTC)

共享資源接受的圖片須在美國和其來源國同時屬於公有領域。不同國家的版權法對原創性門檻的規定完全不同,因此圖片是否在來源國符合原創性門檻往往不易判定。尤其是中國的圖像原創性門檻並不明確,並且commons:COM:TOO指出大陸法系國家(包括中國大陸)的原創性門檻較高,保險起見不適合批量轉移至共享資源。--Wcam留言) 2017年3月22日 (三) 12:15 (UTC)

中國銀行的logo,由於書法作品在中國受版權保護(commons:COM:TOO#China (PRC)),「中國銀行」四字由郭沫若題寫且郭沫若逝世並未超過50年,所以此logo毫無疑問不是公有領域。--Wcam留言) 2017年3月22日 (三) 13:23 (UTC)

不用批量吧,這種見一個移一個比較保險。跟共識沒關係的東西本來就不需要討論呀。另外中文檔案頁好像至今也無法用TW,Template:Copy to Wikimedia Commons還是挺好用的。--淺藍雪 2017年3月22日 (三) 15:58 (UTC)

一旦移錯了可能會被共享資源刪除,那裡有commons:COM:PRP,刪東西比這裡容易得多。--Wcam留言) 2017年3月22日 (三) 16:59 (UTC)

蒙牛、保利地產logo同樣因為含有書法內容,不應轉移。--Wcam留言) 2017年3月23日 (四) 12:47 (UTC)

修訂「維基百科不是什麼」「維基百科不是發表創新意念的地方」段落

翻查記錄,《維基百科不是什麼》已有一段時間未曾更新。以下新舊條文並列,各位可藉此討論一下此段落是否需要更新。

現行條文

=== 維基百科不是發表創新意念的地方 ===
維基百科不是發表您個人思想或分析的地方。維基百科不是

  1. 發表原創研究的地方。您個人的研究理論、原創理念、自創定義或詞語等,請到適當的評審機構、論文期刊或者其他網站宣布您的發現。維基百科會待您的研究經發表成為公認知識的一部份後,再作報導。維基百科的資訊並無須經過同行評審,但都力求做到可靠和可供查核。例如,編輯者可以引用文獻,讓內容可供查證。如果您想發表原創研究,請到維基百科的姊妹計劃維基學院
  2. 讚詞或批評。藝術作品和傳記應該成為百科全書條目的主題,但條目內容應是行外人所能理解的。
  3. 個人論文。百科全書是人類知識的總結,而不是宣傳您個人見解的道具。請見Wikipedia:非原創研究。假若某個人的意見值得百科全書記載,應該由其他外人來撰寫。您對維基百科的意見,請在相關頁面的討論頁留言,或者到元維基發表。
  4. 時事評論。雖說「家事國事天下事,事事關心」(語出顧憲成東林書院內的對聯),但維基百科始終不是發表這種意見的場所。條目內容應該適當平衡各方觀點。維基百科編輯者也應注意,所撰寫的題目應該具長期保存價值。
  5. 論壇或討論區。請謹記維基百科的目標就是要寫好百科全書。您固然可以在其他用戶的討論頁進行交流,也可以在條目的討論頁解決相關的問題。但請不要將您的討論放進條目當中。

提議條文

=== 維基百科不是發表創新意念的地方 ===
維基百科不是發表您個人思想或分析,或者公布新資訊的地方。依據非原創研究方針請勿於維基百科

  1. 發表原創或初級研究 ,例如提出新理論及解法、原創意念、自創定義或詞語等。如果在初級研究之中獲得成果,請於其他場所,例如論文期刊、其他紙本形式、開放研究或網上出版物發表。維基百科會等到一項研究獲得發表,得到同行評審及公認為知識以後,才提述此項研究。增加內容至條目時,請援引可靠來源,以證明內容可供查證,而非純粹個人意見。
  2. 發表個人創新意念。朋友間流行用語、新創酒局遊戲或自創舞步,如未得到多個獨立而可靠的二手來源介紹及報導,未符《關注度指引》,則未應建立相關條目。
  3. 發表個人評論文章。百科全書是用於總結人類知識,而非宣傳個人見解。有時候,某人意見可能值得收錄,不過應該由其他人去撰寫。若然想建立維基百科相關論述,請在自己用戶名字空間下,或者到元維基發表。
  4. 討論非維基事宜。請謹記維基百科目標在寫好百科全書。如有維基百科相關事宜需要討論,不妨於其他用戶的討論頁交流商議。亦可在條目討論頁解決條目相關問題。然而,請勿在條目內展開任何討論。亦請勿在條目討論頁展開無關該條目編輯的討論,又或者當作詢問處來尋求指引或技術協助。如果留言內容不符合討論頁指引,則可以移去。本站亦設有知識問答頁,無關維基百科的問題可以發至該處。

歡迎提出意見,及其他修改方案。此段例子有所更改,請注意。謹此。--J.Wong 2017年3月23日 (四) 16:16 (UTC)

技術

話說,中文維基百科的首頁是否應該改版了

根據Wikipedia:首頁的歷史,每三年就會更換首頁一次,上一次首頁更換是2012年年底,距今差不多三年了,而且中文維基百科的條目也接近百萬,為何不用新的首頁迎接這一突破呢?個人比較喜歡葡萄牙語首頁的風格,不僅超級美觀,還加入了將條目分享至社交網站這一特色。--星巴克女王(🎶歡迎參與音樂專題 2017年2月5日 (日) 15:46 (UTC)

設置中的「啟用站外分享與收藏功能」小工具就是可以做條目分享的。——路過圍觀的Sakamotosan 2017年2月6日 (一) 00:21 (UTC)
(+)支持。--SolidBlock留言初三罄竹難書的教育制度和中考使我無法活躍 2017年2月6日 (一) 05:35 (UTC)
那個分享區塊需要用腳本去寫,當然可以參見維基導遊。--水中撈躍 2017年2月6日 (一) 11:39 (UTC)
看了一下,那個分享功能應該可以不用腳本就能實現--百無一用是書生 () 2017年2月6日 (一) 13:12 (UTC)
移到VPM版?-- Stang 122 2017年2月7日 (二) 01:24 (UTC)
(+)支持,不過仍覺得目前版本是眾多語言中最簡潔美觀的。我有時間的話會試試自己做一個。可以考慮公開徵稿。題外話:老實說,整個維基百科的版面大體還是停留在十幾年前,完全錯過了近年來網絡設計風格的演變和瀏覽器技術的發展。要煥然一新的感覺,可參考[10][11][12]。忍不住要說現在的問題:頂欄和左邊欄浪費寶貴空間,不美觀,過於依賴小字體純文字連結而不是接觸面積更大的按鈕;搜尋是網站最最重要的元素,卻那麼小,躲在角落;條目版面不善(完全不)運用空白去區隔內容元素,正文、圖片、模板框、表格等常常堆在一起;整體字體太小,行距太窄,不易閱讀;瀏覽條目的章節結構極不方便(不像移動版),同樣左邊欄空間被浪費了。埋怨完畢。看來如果基金會不在乎用戶體驗的提升,我們也就只能改改首頁了。鋼琴小子 留言 貢獻 2017年2月7日 (二) 01:34 (UTC)
左欄(你指旁邊的工具欄?)和頂欄(帶搜索框部分)屬於軟件自帶的,如果移除,要參考RTRC(實時最新更改)那種使用腳本來重新排版,會依賴JS,而且JS掛掉可能變得很難看(?),搜索可以用inputbox插件放出來,不過會丟失下拉提示(肯定性)和直接跳轉(可能)(好像也是軟件提供的)。其他不涉及軟件部分的版面問題,不好說。——路過圍觀的Sakamotosan 2017年2月7日 (二) 02:20 (UTC)
純粹移除的話可以直接 CSS display:none,那玩意是比較早加載的。(但我們只要追加內容不是嗎?)導航倒是有用的提議,只是加東西的話不至於掛掉變得很難看:
var toc2 = document.getElementById('toc').cloneNode(true);toc2.id = 'side-toc';toc2.removeChild(toc2.querySelector('#toctitle'));toc2.style += ';position: fixed;width:10em;float:left;font-size:small;bottom:0';document.getElementById('mw-panel').appendChild(toc2)
(這個破例子正常工作的時候更難看)
至於行高,現在 line-height 已經是 1.5,夠了。我可不希望維基百科哪天變成小四(12pt)、中易宋體(Times)、開頭空兩格(一 Tab)。如果你覺得字體小,先去看看你的屏幕DPI設置,然後看看你是不是在用把serif當sans-serif的瀏覽器。
有些東西不是按鈕就不要做成按鈕形狀的鏈接。cf. Best Motherfucking Website & Motherfucking Website。——Artoria2e5 保持討論完整直接ping我回復 2017年2月22日 (三) 05:50 (UTC)
多補了點JS打了個會自動隱藏的小工具:User:Artoria2e5/Gadget-sidetoc.js。——Artoria2e5 保持討論完整直接ping我回復 2017年2月22日 (三) 06:11 (UTC)
(-)反對修改側欄和上邊框。和其他Wiki保持一致非常重要。-小烈 (找我?) 2017年2月13日 (一) 22:45 (UTC)
(+)支持刪除側邊欄並修改頂欄,要跟上扁平化的熱潮(笑。#ForeverLove I miss the pillow talk. 2017年2月26日 (日) 15:46 (UTC)
(-)反對改為葡語版首頁,(+)支持首頁改版。版面的移動沒有帶來內容的變化;此版已審美疲勞。期待更適合的改版方案。 2017年2月8日 (三) 09:35 (UTC)
  • 我也來(&)建議幾條:
    • 搜索框確實太不醒目,我也一直很想說這點。
    • 點擊特色條目的圖片能否直接進入條目?我想這更符合大多數讀者的習慣,他們點圖片是想看條目而不是看文件頁。(其他的或許也可如此)
    • 類似百度百科的首頁,添加個「用戶動態」板塊如何?滾動顯示最近更改的內容就好。
    • 動態熱門反映了讀者的需求,可以更醒目一點。比如每個條目一個div(技術可行的話加幾句介紹),顯示熱度排行(比如顏色深的更熱門)與變化趨勢,而不是僅僅一個鏈接。
  • 以上。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 12:32 (UTC)
不是說改為葡語的首頁,而是說借鑑他們好的地方。--星巴克女王(🎶歡迎參與音樂專題 2017年2月11日 (六) 03:06 (UTC)
(=)中立:比起日語、英語,目前的首頁挺美觀的,如果沒有做出更美觀的首頁,我就覺得沒必要換。--Dqwyy談笑風生正在沉迷CLANNAD祝各位新春快樂回復請ping 2017年2月8日 (三) 13:24 (UTC)
可以先徵集作品,以往改首頁都是要徵集作品的,如果徵集的作品不好則不予更換。--星巴克女王(🎶歡迎參與音樂專題 2017年2月11日 (六) 03:06 (UTC)
  • (&)建議:個人更傾向於開發全新的皮膚(個人更傾向於偏科技感的簡潔扁平化皮膚,如tumblrPinterest等網站的UI以及我的新簽名(笑))及更換主要模板的配色方案而不止限於首頁改版。--Jerre Jiang  討論參與清理積壓站務  2017年2月8日 (三) 14:40 (UTC)
(:)回應mw:Manual:Skins頑張ります。——路過圍觀的Sakamotosan 2017年2月9日 (四) 00:32 (UTC)
(+)支持詭異的Eric.k(注意那一點)-上我!的留言版逛逛吧~雖然沒什麼人 2017年3月17日 (五) 14:39 (UTC)
  • (+)支持,是該換了。#ForeverLove 你是我最無法收斂的全心付出 2017年2月19日 (日) 06:19 (UTC)
  • (+)支持改版但可考慮更多選擇,如Jerre Jiang君所言。Kou Dou 2017年2月20日 (一) 04:58 (UTC)
  • (:)回應改版,可以針對VR、APP 進行相關設計嗎?--小藍 找我 2017年2月20日 (一) 09:57 (UTC)
    • app最多也就是對首頁各欄目內容的展示方式做一些微調而已--百無一用是書生 () 2017年2月21日 (二) 02:54 (UTC)
      • app基本就是移動版渲染。——Artoria2e5 保持討論完整直接ping我回復 2017年2月22日 (三) 05:50 (UTC)
  • 支持考慮改版,反對「考慮一致」論,另外不建議改皮膚(工程量大)。英語那玩意其實有個很重要的優點:板塊明晰。——Artoria2e5 保持討論完整直接ping我回復 2017年2月22日 (三) 05:50 (UTC)
如果不考慮風格一致(左側邊、上邊欄)的話,建議請自行fork一個數據庫出去搞,或者像wikiwand做動態鏡像。至於板塊清晰度的話,現在也是版塊區分的(只是不是非常明顯的色彩差異,而且會有因為內容變化的上下移動)。我覺得「站點工具」、「參與維基百科」、「維基百科提醒您」部分倒是因為內容塊的移動不一定經常對齊,反而那部分可以考慮改版時進行對齊,會更好。——路過圍觀的Sakamotosan 2017年2月22日 (三) 06:15 (UTC)
  • (+)支持改版,現在的版面的確浪費了頂欄空間(從海納百川,有容乃大到已有927,575篇條目中間那一大塊),英日文雖然也有那一塊,但中文的特大。右邊六個聯結也不醒目。-- KRF留言) 2017年2月22日 (三) 06:06 (UTC)
英文版右邊9個鏈接是主題門戶,本地06年就有了,到10年了就消失了,當然本地主題門戶參與度不高。日文版幾乎和我們一樣空。——路過圍觀的Sakamotosan 2017年2月22日 (三) 06:22 (UTC)
葡萄牙版的標題頂,主要是兩個模塊(標題和6鏈入口)儘可能居中(並且模塊內都是居中的),這樣看上去空隙自然少了,好像很豐滿的樣子。而中文版現在主要右邊太靠右了,左邊為了貼近半球圖標就罷了,右邊的話空餘太多,自然顯得中間空曠。如果標題頂分10格的話,左6右4,並且右邊儘量居中,這樣就好些,左邊可以考慮放大字體並且儘可能向中間展開,這樣就不用中間再放些什麼了。——路過圍觀的Sakamotosan 2017年2月22日 (三) 06:29 (UTC)
  • (+)支持改版,看來是一項艱鉅的挑戰。--小躍撈出記錄) 2017年2月24日 (五) 03:09 (UTC)
  • (+)支持:雖然個人認為現在的中文首頁十分簡潔明了,但是看過葡萄牙語首頁後覺得中文首頁仍有很大進步的空間。我很喜歡以首頁改版迎接中文維基百科百萬條目的想法。--WindowPain留言 | 貢獻 2017年2月24日 (五) 07:06 (UTC)
    • (&)建議
      • 將首頁設計成漢語風格。希望配色、樣式能體現中文特色;
      • 更改首頁搜索框樣式、尺寸或位置。現有的搜索框不夠明顯,有沒有可能使用類似Wikipedia的inputbox?這也許與軟件有關,難以更改;
      • 新增與葡萄牙語首頁類似的主題門戶導航欄。主題門戶導航欄能讓讀者快速找到感興趣的主題(例如藝術與文化、科學、技術與工程、歷史、地理),也可以提高編輯者維護主題的積極性。--WindowPain留言 | 貢獻 2017年2月24日 (五) 07:06 (UTC)
      • 搜索框可以在首頁另加一個,但是不應修改右上角作為諸多工具存在的那個——做太醒目會喧賓奪主。門戶是好主意,漢語風格是什麼?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月5日 (日) 18:38 (UTC)
        • 如果主題門戶導航欄指的是pt:Portal:ÍndicePortal:首頁不就是嘛……就在首頁右上角條目數量底下。不過不夠醒目。 --碸中嘌呤的白磷萃取 打譜 2017年3月7日 (二) 14:17 (UTC)
        • 搜索框了解了。Portal:首頁略微隱秘……我覺得把裡面的主題拿到首頁會方便一點。漢語風格是指如書法之類的元素,可以考慮把「特色條目」、「你知道嗎?」等標題,甚至條目計數換成書法。不過倒是有辨識度低、簡繁轉換等的問題。--WindowPain留言 | 貢獻 2017年3月8日 (三) 07:54 (UTC)
          • 說到書法,總覺得有變成小學課本或者信息課Powerpoint作業的風險……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月8日 (三) 13:56 (UTC)
            • 確實!……書法和計算機字體搭配還是比較難和諧,搞得不好很有可能毀了現有的簡潔,這一點還是保守一點好。對於門戶目錄,我還是推薦的。估計距離百萬條目還有一年時間,先徵集作品評選吧。--WindowPain留言 | 貢獻 2017年3月11日 (六) 07:05 (UTC)
              • 文言維基的「經史子集」四個圖倒是不錯,可惜在現代人的中文維基沒那套分類。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 06:48 (UTC)

鹿角立鶴在新條目推薦中被擱置

維基百科:新條目推薦/候選中的鹿角立鶴(2月25日)在提名通過後,擱置近兩周未能進入首頁「你知道嗎?」欄目,還請管理員手動更新。--我是兔妹留言) 2017年3月12日 (日) 05:01 (UTC)

候選多一點的話,機器人就會更新了。機器人會掌控更新的頻率。--小躍撈出記錄) 2017年3月15日 (三) 03:01 (UTC)

關於mw:2017 wikitext editor的一些提議

因為我似乎找不到關於這個編輯器的其他討論所以我直接在這裏開新帖了。個人一開始使用的時候還可以的。但是某天字突然被放得很大加上默認的SimSun字體不甚美觀所以我暫時取消了。我認為在SimSun字體下,原來的字體大小會更好看。這個問題是否能通過自定義用戶頁CSS來改善?--一個正常人 中國文學義務 淫愛節義務 2017年3月13日 (一) 14:15 (UTC)

@一個正常人:可以,用F12找到你想要的那框字,右鍵複製選擇器得到選擇器,然後刪掉點過於精細的(這裡那裡第幾個子元素)定義就可以配上font-size塞進自己的common.css用了。問題是你真想用SimSun這個屏幕上的笑話、襯線字體來當默認「sans-serif」(非襯線字體)使用?早點去整個Inziu Iosevka SC(Iosevka 為等寬字體;日常閱讀可用包內的比例字體 Roboto SC)吧。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:24 (UTC)

@Artoria2e5:今天打開來看,發現特大的字體大小被還原了。另外,我只有編輯中文維基媒體計劃時瀏覽器會給出SimSun字體,其他語言的維基媒體計劃和其他MediaWiki網站默認看到的都是Consolas+新細明體。--一個正常人 中國文學義務 淫愛節義務 2017年3月14日 (二) 06:42 (UTC)
@一個正常人:或許和lang為某種zh有關。之前提到的CSS技巧其實也可以拿來改改字體,或者你可以直接參照m:User: Artoria2e5/global.css最後一段各種lang(zh)的部分批量覆蓋所有中文等寬格式。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 06:50 (UTC)

Tech News: 2017-11

2017年3月13日 (一) 15:25 (UTC)

(...)吐槽這期Tech News推送的有點早啊,以前都是凌晨推送的。——꧁༺星耀晨曦༻꧂留言) 2017年3月13日 (一) 15:28 (UTC)
第一條有意思,也就是多列參考資料表變成了官方標配。各本地自實現需要修改了?——路過圍觀的Sakamotosan 2017年3月14日 (二) 00:49 (UTC)
多列參考資料那個看看本地有什麼地方需要改的吧。另外模板又有的折騰了(倒是有助於性能優化)--百無一用是書生 () 2017年3月14日 (二) 02:35 (UTC)
多列參考資料目前需要社群共識後發出請求手工啟動--百無一用是書生 () 2017年3月14日 (二) 02:43 (UTC)
看了下技術要點和現有實現,references標籤只是提供一個ol.references,然後{{reflist}}提供一個div.reflist包裹來給於CSS級的分欄特性。而啟用自動分欄的話,會在標籤添加一個新參數,然後服務器的輸出就變成了div.mw-references-wrap,並提供響應式的動態(?,可以隨屏幕大小變動?)分欄。這個對{{reflist}}改動不少,可能需要先弄一個草稿用於實現自動分欄和手動分欄?——路過圍觀的Sakamotosan 2017年3月14日 (二) 03:19 (UTC)
reflist修改很可能做到Template_talk:Reflist#編輯請求:加入「autocol」參數這樣就夠了。另外準確地說是只考慮屏幕寬度。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:18 (UTC)
我覺得應該明確一些前提:references標籤應該保持不變的輸出,只有ol.references,用戶可以自行配置div來控制更細緻的設定,例如手工分欄、字體、手工的列表樣式控制等。references標籤設定responsive=1時則啟用自動分欄,實際輸出就是在ol.references包裹一個div.mw-references-wrap,div.mw-references-wrap相當於{{reflist}}的div.reflist,而自動分欄的方式實際也就是{{reflist|35em}}。現有references標籤無法自行配置style和class,所以會丟失{{reflist}}的liststyle屬性,需要還需在references標籤增加相應入口配置,這樣div.mw-references-wrap和{{reflist}}的div.reflist的表現一致。——路過圍觀的Sakamotosan 2017年3月15日 (三) 06:22 (UTC)
@cwek:首先,不應該有不要的輸出是DOM潔癖。其次,有一個認知上透明、功能單一的div,你硬想讓人家給你做個相應入口配置,這是身上有個傷口快好了還死抓又破了。再者,div.reflist本來在樣式上就是為了和ol.references表現一致而一樣做成小字號之類的東西的;因為一樣是div你就覺得這能等同嗎?多讀讀phab:T160498#3100944,謝謝。
那好,假設phab那群人給你做了這個屬性,並且就是安在div上面的。為什麼用戶應該期望參考資料一旦超過十條,就可以使用什麼酷炫屌炸的「隱藏功能」?為什麼一個好好的拿來給你傳個column-width的div從一塊透明的玻璃變成了一塊拿來寫字的白板?為什麼一個窄屏幕的用戶應該知道responsive除了為屏幕寬度不同的他人着想,還可以控制你這個隱藏功能?
我是支持給生成的ol.references加class/style的,然而給一個捉摸不定的div加這就很搞笑了。說到底,你就是認為兩層div不清真,不願意用reflist處理複雜樣式而已。這樣不行。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 16:48 (UTC)
2017年3月17日 (五) 01:07 (UTC)功能已經上線了,由於現在默認不啟用(references標籤只輸出ol.references),需要手工添加responsive屬性來啟用。可以本地測試下與一堆參考資料模板的兼容性,例如CSS選擇器、部分js腳本的匹配等。——路過圍觀的Sakamotosan 2017年3月17日 (五) 01:07 (UTC)

中文維基百科是否需要自動顯示多列參考資料?

在這裡徵集一下意見,以及如果我們啟用的話,本地還需要修改哪些東西?--百無一用是書生 () 2017年3月14日 (二) 02:43 (UTC)

請注意:請各位在投票之前讀一讀功能文檔,搞清楚自己支持、反對的是什麼。這個功能約等於默認設定{{reflist|35em}}(大概在phab上提的時候還可以定做一下),願意吃螃蟹嘗個鮮的可以玩一下。(不少條目已有類似的20em、30em設定,所以在這個意義上真也不是什麼新東西。)這個投票討論的問題在於是否默認設定,不通過的話也可以手動啟用功能,但是這樣做和大家現在reflist手動20em區別多大就不知道了。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:58 (UTC)

  1. (+)支持,另誰有空幫忙翻譯一下相關文檔?--百無一用是書生 () 2017年3月14日 (二) 02:43 (UTC)
    • 基本完成——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:09 (UTC)
  2. 暫且(-)反對,它變相是把默認設置由單欄變成自動多欄,而本身衹想在任何情況下顯示單欄的頁面,由於都沒有在references標籤或reflist模板設定任何參數,那麼它們都會變成自動多欄。如果衹針對reflist模板並已經設定分欄的頁面來啟用自動,則不反對。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月14日 (二) 03:50 (UTC)
    看上去是需要在references標籤添加多一個新屬性來啟用的,默認不加應該並不會影響。不過可能需要檢查需要改動的模板。——路過圍觀的Sakamotosan 2017年3月14日 (二) 03:54 (UTC)
    @Cdip150:請讀文檔中關閉responsive的模式。
    那麼就更反對了,我反而要在「不需要分欄」的時候加屬性,而「需要分欄」的時候卻不用加屬性,根本是本末倒置。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月14日 (二) 04:51 (UTC)
    @Cdip150:分欄與否取決於屏幕寬度,對於網頁這種會跟着窗口大小改變排版(不然字要往窗口右邊噴出去的)的東西,「不需要分欄」(「定死」)才是特殊要求。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:09 (UTC)
    「分欄與否取決於屏幕寬度」已經把<ol class="references">變得不純淨的說……所以加這個功能才是特別要求。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月14日 (二) 05:32 (UTC)
    @Cdip150:還是「讀文檔」。這個東西在實現上並沒有對本來的class做出什麼改變,而是將超過十條的列表在生成ol的HTML的時候另加上了一個「請js之類的東西考慮分欄」的class。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 20:20 (UTC)
    那也是漂染啊,衹是方法不同而已,最後還需調用屬性才能有個純淨版,所以還是(-)反對。我的意念是:我不調用任何東西的<references />的時候那就應該給我一個最原始的<references />功能,不然將來技術維護時要把原本的邏輯反轉來思考設計,會很易錯的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 01:31 (UTC)
    街燈說出了我的看法,Facebook like thumb.png。——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:05 (UTC)
  3. 暫且(-)反對,手動設定還比較好看。--小躍撈出記錄) 2017年3月14日 (二) 04:05 (UTC)(+)支持運作。--小躍撈出記錄) 2017年3月15日 (三) 23:38 (UTC)
    @小躍:讀文檔。機器看屏幕寬度這種事情比人熟練。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:13 (UTC)
    已讀,不過看到還要多設個隱藏自動分欄的按鈕就覺得很嘔氣。--小躍撈出記錄) 2017年3月15日 (三) 00:48 (UTC)
    那個東西不是按鈕。要禁用的話用{{reflist|1}}就好了,還是比references打起來短。要全域禁用的話可以給common.css加一行div.mw-references-columns { column-width: inherit; }。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:48 (UTC)
  4. 多列參考來源不是可以由{{reflist}}實現嗎。——꧁༺星耀晨曦༻꧂留言) 2017年3月14日 (二) 04:16 (UTC)
    那是手動的,這是官方提供的。另外討論放上面。——路過圍觀的Sakamotosan 2017年3月14日 (二) 04:47 (UTC)
    (現在討論的)多列參考資料是自動根據屏幕寬度啟用的。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 04:47 (UTC)
    官方能這樣做,但現在reflist的設計不是。——路過圍觀的Sakamotosan 2017年3月14日 (二) 05:02 (UTC)
    @cwek:看一下回復層級就知道我不是在跟你頂嘴啊……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 05:10 (UTC)
    「多列參考來源不是可以由{{reflist}}實現嗎。」,看語境。現在的{{reflist}}多列參考來源是手工配置的,而上面的多列參考來源是系統(以後)提供的。——路過圍觀的Sakamotosan 2017年3月14日 (二) 06:08 (UTC)
  5. (+)支持響應式設計有助於寬、窄屏閱讀。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 04:45 (UTC) 詳細理據:我認為這種設定有利於大多數條目,效果不好需要手動調整的應屬少數。如果反過來放着這種設定不用,可能會有編者手動或半自動加入 responsive 屬性,浪費人力物力。這個投票決定出的方案,無論是默認啟用還是禁用,都應選擇對於多數條目的最優解,以避免需要大規模手動調整的情況。要是有人搞到最後往WP:RFBAWP:BOTR提出什麼批量啟用、禁用響應式的bot,我可得好好頭疼一會。[開玩笑的]——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 03:16 (UTC)
    這就讓我想起玩異星工廠的一個例子,它在0.13引入了集裝搬運臂(比喻:插件自動分欄),同時改變了普通搬運臂抓取數量設定,使其從箱子、可堆疊設備、傳送帶上抓放數量隨科技升級而改變(比喻:默認不添加參數的話會自動分欄,而且輸出變得不乾淨),而舊版本傳送帶上的抓放永遠是只有1個(乾淨的輸出)。我就問過開發論壇,然後和我解釋有助於在低科技下儘早地用普通臂實現傳輸帶滿負載填充(典型的「為你好」),但是我需要的就是精確抓取,而且填充不就是集裝臂應該做的嗎(一個新參數能控制的行為,非要去碰默認舊行為)?所以只能等新版本去解決數量控制問題,或者我現在做的,把相應底層控制值清掉來屏蔽這個坑爹新特性。我提這個,就是要要說明,引入新功能不應該改變原有的功能或者默認行為,新功能加配置就能用(可能允許丟失一部分與新功能衝突的舊行為),不加一切如常。——路過圍觀的Sakamotosan 2017年3月15日 (三) 04:00 (UTC)
    你把一個方便從模板級別關閉的功能(本來也就是模板功能與之衝突)和遊戲的坑點相比較是十分可笑的。你重複了很多遍不乾淨,又說兩層div不好(用戶看得到嗎?連CSS選擇器都不管的事情),這個應算作潔癖。你認為默認功能只要有為你好的成分,需要一點手動關閉機制就很麻煩,只能說你是新功能恐懼症。(在遊戲這個例子中,你可能是對的;但在MediaWiki中你絕對不是。標籤貼歪了。)再重複一遍,和自動分欄功能衝突最大的手動分欄功能由單個模板創建,而修改模板進行處理輕而易舉。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:10 (UTC)
    乾淨就是為了方便現在reflist套入一個自定義div來實現更多功能,如果現在references默認啟用後,所有包括不需要分欄的情況都會包裹一個用戶無法控制的div,尤其會導致和現有自定義div有衝突的可能,我覺得這樣改變很糟糕。我只是不反對啟用自動分欄的行為,但反對改變了原有輸出的行為。使用新屬性去開啟新輸出,不是用新屬性去改回舊輸出,然後由用戶用新屬性或輸入入口去控制新輸出的疊加的用戶可控特性。——路過圍觀的Sakamotosan 2017年3月15日 (三) 05:20 (UTC)
    cwek對話頁 | 使用者貢獻)我說了多少遍了?div當然可以被用戶控制。功能衝突只有reflist會導致,reflist的解決方法我倆到這一步都已經很清楚。改變行為是更新的常態,如果只是沒手動規定分欄的變成自動分欄的話,我認為沒什麼可怕的。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:27 (UTC)
    所以你的以破壞舊有破壞來支持新特性,即使本身可以不會這樣做的想法很霸道,我作為用戶不接受,抱歉。——路過圍觀的Sakamotosan 2017年3月15日 (三) 05:35 (UTC)
    @cwek:即使查看的是舊版本頁面,渲染時引用到的也只會是新的reflist模板,對於使用了手動功能的用例沒有造成破壞的問題,而對於沒有手動定義部分的這個是你我觀點不同。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:45 (UTC)
    補充,我不認為我是新功能恐懼,只是新功能應該像被移除之後和過去的不明顯變化地添加,不應該去改變過去的行為。就像我提的遊戲例子,我需要任何地方的多數抓取的我可以使用新特性(集裝臂),就算移回舊版本遊戲會自動清除這個數據點一樣;但不要改變普通臂在傳送帶只抓取一個物件的行為,會導致的破壞不少,尤其論壇有人給了一種用控制電路利用補數的控制方法,但我已經用了控制電路來控制臂的啟閉,增加這樣的控制電路會加重功能承載的負擔,使設計複雜了,所以只能就是提議要麼更便捷的控制,要麼只能關閉控制參數。同樣,沒參數的references就輸出ol.references,用戶自行套div來控制更多效果;新功能只需要一個新屬性來啟用,畢竟我們還是要靠我們的包裝來控制是否用這個參數,如果還能提供入口來導入自定義div的屬性設置,在不影響系統提供div的功能,更好,就這樣。——路過圍觀的Sakamotosan 2017年3月15日 (三) 05:31 (UTC)
    @cwek:你我現在都完全知道衝突發生的例子十分同質化,且十分清楚如何從單個源頭避免衝突。這兩點就使這個情況和你的遊戲裡面的麻煩例子完全不同。話說你有沒有認真看過那個響應式是怎麼實現的?就一條CSS,
    .mw-references-columns{ column-width: 35em; }
    
    (你應該已經很清楚怎麼用CSS或者JS禁用了。)——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:41 (UTC)
  6. 兩個問題解決:1.如果不添加新參數的標籤是不分欄的話,2.預留class和style屬性入口,用於導入自定義參數。要不然不支持。如上面有人說,將ol.references弄得不乾淨。——路過圍觀的Sakamotosan 2017年3月14日 (二) 06:11 (UTC)
    看T33597的說明,現在是在功能部署生產線中,如果功能部署完成,並默認啟用的話,則references標籤默認分欄,需要添加responsive=0關閉;默認關閉的話,則默認不分欄,需要添加responsive屬性來打開。所以,(-)反對因為這樣默認就是不啟用分欄,可以通過屬性來打開,{{reflist}}容易配置自動或手動功能,對現有模板影響也不大。——路過圍觀的Sakamotosan 2017年3月14日 (二) 06:25 (UTC)
    「因為這樣默認就是不啟用分欄」的理據不充分。支持/反對應該基於多少(超過十條引用的)條目應該/不應該自動分欄決定,不然如果選擇了少數的一邊豈不是變成絕大多數的條目都需要添加某種(啟用/禁用)屬性優化閱讀?(我是信任這套東西的響應式判據,認為對於絕大多數條目有益。)——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月14日 (二) 20:23 (UTC)
    看技術文檔,原生references只有ol.references,{{reflist}}再在上面套多一個div.reflist來給樣式和手工分欄功能。現在帶響應式屬性的,看上去就是在ol.references上套一個div.mw-references-wrap來做分欄,相當於{{reflist}}原來的div.reflist功能。如果默認啟用,{{reflist}}的實現就成了div.reflist>div.mw-references-wrap>ol.references,會破壞掉原來手工分欄的設計,改動也不少。默認不啟動的話,可以保留{{reflist}}大部分的設計和參數,而且{{reflist}}也容易配置使用默認自動分欄或手工分欄或不分欄。不應該功能好而破壞就一些原有的設計習慣,應該儘量不影響。BTW,就像我玩的一個遊戲,引入了一個新功能,但同時也破壞了原有的一個特性,還balabala說有效提升效率,但本來新功能就是能提升該特性,原有特性可以不影響,這些設計有時太自大了。——路過圍觀的Sakamotosan 2017年3月15日 (三) 00:42 (UTC)
    你猜這說明什麼?說明你不知道CSS選擇器選了啥,並且還不會造模板。「破壞掉原來手工分欄的設計」的前提是:
    1. MediaWiki:Common.css裡面用到的column-count-width屬性無法在多層div嵌套的情況下工作(它可以)
    2. MediaWiki:Common.css裡面用到的div.reflist ol.references無法處理中間夾了一層元素的情況(不是>直接下屬,所以還是可以)
    3. {{reflist}}不能放一個類似於{{#ifeq:{{autocol|1}}|1|<-- try enable: -->{{#if:{{#ifexpr: {{{1|1}}} > 0 <-- 零和负数为无效值 --> |column-enabled|}}{{{colwidth|}}}|<--字符串不为空,说明手动设定两种参数至少用了一个,不应考虑自动-->0|1}}|0}}的東西,在手動指定的時候自動關閉responsive(我寫出來了,所以也是可以)
    再看看,問題在哪?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 01:10 (UTC)
    T33597#3082884寫道,默認啟用的話,則references標籤默認分欄,需要添加responsive=0關閉;默認關閉的話,則默認不分欄,需要添加responsive屬性來打開。如果假設默認不開啟,在oldid=43609425的reflist設計中,只需要判斷參數1是不是等於auto,是的話直接使用帶responsive的references標籤,輸出的結構div.mw-references-wrap>ol.references,common.js需要添加.mw-references-wrap來代替div.reflist原來的選擇器功能,而且主要使用reflist的話,就相當於「默認」啟用系統提供的自動分欄。如果參數1是數字的話,就是按照老reflist做法,而且通過設定第一次參數1判斷的默認值就能決定是否分欄(1就是1欄不分欄,auto就是自動分欄)。我覺得不默認啟用的改動更適合。——路過圍觀的Sakamotosan 2017年3月15日 (三) 01:32 (UTC)
    CSS和JQuery選擇器都是不死放個>就不會出事的。連MediaWiki:Common.css都不放還有人自己JS去放的話,只能說是脫褲子放屁做的孽多此一舉。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 01:35 (UTC)
    而且默認啟用的話,所有references輸出一定是div.mw-references-wrap>ol.references,需要手工responsive=0來壓制;默認不啟用的話,是乾淨的ol.references,外面可以在自行套div修飾,需要單獨啟用的話,只要加上responsive屬性則可。從兼容性考慮,破壞過去的麻煩,比定量增加啟用更好。——路過圍觀的Sakamotosan 2017年3月15日 (三) 01:38 (UTC)
    除非你直接對着「#mw-body-content」放>死定下來,不然ol外面會不會有東西都不是問題。自動多套一層div前面已經說了,不會造成CSS匹配失敗。至於「單獨啟用」論,我建議你讀我之前20:23 (UTC)的回應——這個投票最重要需要考慮的問題是怎麼做受益的條目最多,需要單獨禁用或啟用的條目最少。我可不想搞到最後去審一個加減responsive的半自動bot。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 01:43 (UTC)
    至於受益問題,這就像我說的BTW,引入一個新功能兼改變一個舊特性,還balabala地說提高該特性的效能,為你好的。你媽的,新功能不就是本來為了這個特性的效能提升嗎?改毛線舊特性啊?我把那些開發問到只能說考慮下個版本提供對這個特性的應用控制了。你是不是想這樣?——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:04 (UTC)
    我將代碼和需要用到的css拉到mw去測試(mw:User:Cwek/reflistmw:User:Cwek/common.cssmw:User:Cwek/reflist/testcases),配置好打開開發者工具箱看看三個參考列表的結構,再分析你的autocol寫法和參數1寫法那個好?mw默認是啟用的,直接references標籤的reflist就成了div.reflist>div.mw-references-wrap>ol.references結構,還出現默認1欄分成3欄的「bug」(估計是div.reflist給了1欄,div.mw-references-wrap給了2欄),必須用references加responsive=0才對。我覺得咋們想到的方向完全不在一條線上。——路過圍觀的Sakamotosan 2017年3月15日 (三) 01:58 (UTC)
    我當然知道參考列表的結構,所以才會知道你的CSS結構論是在鬼扯——你看,不也沒問題嗎(cannot reproduce; bug infertile?)?參數設計的問題是這套東西已成既定事實後模板細節討論的問題,拿來當反對理由是在瞎搞。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:06 (UTC) 另外autocol這個多出來的東西設計上假定的前提是手動啟用之前,不然我那個編輯請求也不會謙虛到默認禁用。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:08 (UTC)
    改毛線舊特性啊?本來舊特性就是手動添出來的,要怎麼改不是很明確嗎。還有一大堆沒用這特性的條目呢。我把那些開發問到說明他們自己也不知道自己文檔已經把該說的說完了。哪裡問的,我也去提醒他們一下。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:13 (UTC)
    我將默認不加responsive的情況放着testcases2(mw:User:Cwek/reflist/defalutmw:User:Cwek/reflist/testcases2),請解釋默認1欄也能分出3欄,而不是像testcases下auto分出兩欄是怎麼回事?——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:26 (UTC)
    補充,默認我的屏幕分辨率為1600,testcases的auto是2欄,只有使用響應式調試開到1920才會分出3欄。而testcases2在指定不分欄的情況,也能分出3欄。——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:40 (UTC)
    我知道的是:
    1. 默認一欄的情況在Common.css下由於認為是普通情況,沒有進行column數量的限定,和普通模式也差不多。
    2. div.reflist本身有縮小字體的作用,可能改變了普通寬度(廢話),導致可以多塞一欄。
    3. 雙重分欄的情況倒是很有意思:外面一層2 column的命令讓兩半內部的響應式分別考慮寬度,造成了自動分欄數量永遠為偶數的局面。
    你要的解釋在第二條。我勸你多用腦子和開發者工具的「computed」。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:38 (UTC)
    總之幫你修了mw:User:Cwek/reflist。建議回到高中化學、初中物理、小學科學溫習一下控制變量法。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:46 (UTC)
    大概明白了。所以如果默認不開啟的話,references的輸出就簡單很多,對我們用戶自定義div的考慮會比references多輸出一個div後還要考慮這個div行為的簡單多。另外不要破壞人家的設計,你的設計想法和我的相對乾淨的想法不一樣。——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:51 (UTC)
    另外還有{{refbegin}},它外面包裹的是div.refbegin,而且同樣支持手工分欄,中間允許包裹星號列項和沒responsive的references。如果默認啟用,又會變成兩層div的複雜css計算了。新功能的添加應該讓舊功能沒用明顯的變化,只有需要新功能是才將其體現出來;而不是讓新功能覆蓋舊功能,因為你難以推斷會不會破壞舊功能,可能甚至是沒想到的。——路過圍觀的Sakamotosan 2017年3月15日 (三) 02:57 (UTC)
    @cwek:到這一步我倒是建議給MediaWiki:Common.css提一個編輯請求,把div.reflist和ol.reference嵌套時「雙重縮小字體」的問題解決。這個現象確實很迷惑人。我去提吧,提完at你。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 02:55 (UTC)
    我認為不影響,的確很迷惑人,但是也是{{reflist}}的功能導致的「惡果(?)」。我們因為期望單純的ol.reference要縮小字體。而{{reflist}}的list允許自行列出參考項目,如果參照ol.reference來縮寫字體,對div.reflist縮小字體是沒錯,但是如果不使用list,就是默認輸出references,沒自動分欄特性的references也同樣輸出ol.reference,所以防止雙重縮寫,所以div.reflist ol.reference要放大回去。畢竟{{reflist}}和單純references經常混着用,不通過這樣會讓沒list的reflist等看上去和單純references渲染效果不一樣。——路過圍觀的Sakamotosan 2017年3月15日 (三) 03:09 (UTC)
    @cwek:結果發現Common.css那邊有嵌套時防出錯的代碼,搞什麼鬼啦!。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 03:09 (UTC)
    只要{{reflist}}旁顯示參數設置的話,自動分欄將移除之,是這樣的意思嗎?--小躍撈出記錄) 2017年3月15日 (三) 03:04 (UTC)
    @小躍:如果「之」指代的是自動分欄功能的話,你說的基本上對。reflist如果檢測到與分欄有關的選項就應該放棄自動模式,但liststyle不應受影響。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 03:09 (UTC)
    不要忘了,手工分欄並不是系統自帶的特性或功能。如果直接使用<reference />而不是模板的話,除非自己再套上一層div啥的,否則是不會有分欄的。現在這個新功能的問題是要不要所有的參考部分都可以自動的自適應分欄,而不用去手工一個個的調整。考慮這個問題應該首先假設不存在{{reflist}}的理想情況--百無一用是書生 () 2017年3月15日 (三) 04:04 (UTC)
    (:)回應,那麼衹有<references />而沒有{{reflist}},站在技術維護的角度而言,應該是要單欄,因為默認開啟自動分欄的話,正如之前所說,我要另加屬性來得到最原始的單欄版本,造成運算邏輯上的逆向理解,繼而容易造成出錯。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 04:12 (UTC)
    (:)回應user:Cdip150[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]],各種複雜模板①不會比條目總數多,②編者一般更有經驗進行處理。站在技術維護的角度而言,模板和腳本不多,比條目更容易控制;至於所謂運算邏輯上的逆向理解(即「禁用東西還要額外聲明」),閣下恐怕是沒有見過{{plainlist}}處理列表的例子——ul等語法默認的是「常見用法」,而list-style-type屬性提供包括禁用在內的罕見用法。自適應排版的禁用開關也是默認模式適合大部分情況,少數禁用情況需要特別聲明的例子。(div造成的所謂「技術問題」之前已有回覆。)——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:05 (UTC)
    plainlist本來就是一個已漂染的<ol>,不能拿來並論吧。而「編者一般更有經驗進行處理」,您想得太過美好了,事實上這次改變是兩邊的用家要在習慣上進行對換(即是全部人都要改習慣),稍為一個用家不知情用錯又要執他的攤子了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 05:17 (UTC)
    在常見與否的邏輯上作並論可沒問題。我想得美好是因為我都能做到啊,這不還有一個技術問題的客棧嗎。另外這次改變是兩邊的用家要在習慣上進行對換是狗屁。指定列數都是用的reflist參數,讓reflist在有任何手動指定的時候放棄自動處理這是顯而易見的事情。哪來的對調?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:20 (UTC)
    問題您拿一個不是根功能的東西來比較呢,所以我認為您的比較有問題。而現在習慣是「不想用就不請求、想用才請求」,而這次提議就變了「想用可不請求,不想用卻要請求」,這不是實實在在的對換嗎?最後請 閣下注意一下WP:文明。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 05:26 (UTC)
    @Cdip150而現在習慣是,這玩意還沒部署多久,哪有什麼習慣?注意一下WP:文明我也請閣下注意一下WP:SNOW。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:29 (UTC)
    SNOW?現在反對與支持不過對半而已。而且程序設計的應該是舊功能不變,新功能通過新控制參數來啟用,而不應該去改變舊功能的行為。——路過圍觀的Sakamotosan 2017年3月15日 (三) 06:08 (UTC)
    果然是我討論頁上那個詛咒起效了。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 06:37 (UTC)
  7. (+)支持,很多條目的{{reflist}}使用默認的單列顯示,但隨着參考資料的增多{{reflist}}也未隨之更新導致部分條目的參考資料排版過於冗長,如果能默認自適應是再好不過的了。--Jerre Jiang  討論參與清理積壓站務  2017年3月15日 (三) 01:54 (UTC)
  8. (-)反對:支持者的理由好像歪曲了事實,默認啟用才需要大規模修改,因為不論單欄還是多欄的頁面都需要修改。--113.52.109.48留言) 2017年3月15日 (三) 03:32 (UTC)
    @113.52.109.48:單欄頁面以未有特別注意處理的references和reflist為主,閣下認為「需要修改」的原因何在?reflist單個模板修改起來可是一勞永逸。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 04:56 (UTC)
    默認啟用要逐個把單欄頁面的reference添加responive=0或{{reflist}}添加|1來保持單欄,另外也要逐個把多欄頁面的{{reflist}}刪掉|2或|3才能自動分欄。而不默認啟用則不需要改動單欄頁面也能保持單欄,只需要逐個把多欄頁面的{{reflist}}的|2或|3改為|auto便行了。那麼哪個修改規模比較大?--113.52.80.16留言) 2017年3月15日 (三) 13:40 (UTC)
    閣下認為有哪些單欄是刻意所為,有保留價值?閣下認為reflist什麼時候會對於分欄這麼敏感?難道單欄的參考列表現在都是拿來畫字符畫的?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 16:29 (UTC)
    那類故意做法維基上多的是,只是很難分辨出是哪些,我又不是那些條目的編者,不會知道他們用單欄是為了什麼。如果你要用「不知道有哪些例子,所以維基上沒有那些例子……之後便可以把人家原本的單欄配置法顯示為自動屏幕分欄。」那樣滑坡謬誤式推論的話,繼續說下去也沒有意義。--113.52.81.19留言) 2017年3月15日 (三) 18:47 (UTC)
    乾脆爬歷史找reflist拆分欄最勤快的十五個編者,然後去討論頁問問算了。從排版的原則上說這樣刻意做是在坑視窗寬度不一樣的人。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 00:32 (UTC)
  • 對於技術小白的我來說,我只想知道這個新功能帶來的「自動分欄」在手機版視圖上是否也生效?如果可以的話,希望可以看到實際的測試效果。——꧁༺星耀晨曦༻꧂留言) 2017年3月15日 (三) 05:47 (UTC)
    • @星耀晨曦:用 [18] 測試的結果是沒有起效,因此報告了phab:T160497。手機屏幕變化不多,不過Android、iOS平板橫豎屏切換的時候大概還是有用的。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 05:57 (UTC)
  • 如果此項技術引入中文維基百科勢必會給一些「守舊」的維基人帶來刺激。如果引入後,維基人可以比較方便的選擇自動分欄還是手動分欄我就支持此項技術的引入(比如,現有的{{reflist}}不怎麼變。只不過,新加入參數auto對應引入後的自動排版)。——꧁༺星耀晨曦༻꧂留言) 2017年3月15日 (三) 06:08 (UTC)
    • @星耀晨曦:{{reflist|auto}}和{{reflist|1}}差不多方便,所以這還是得死爭好久。另外頂上提到,要在手機上有類似效果的話可以試試看{{reflist|35em}}。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 06:34 (UTC)
      • 不同吧,{{reflist|1}}就是1欄,也就是手工控制的不分欄。{{reflist|auto}}就是要求分欄,然後使用系統的分欄機制(當然可能還要放棄部分原來reflist有的特性,在新功能不提供接口來導入的話),當然現在的{{reflist|35em}}就是系統提供自動分欄的對應實現,差別就是所用div的class屬性不同而已。——路過圍觀的Sakamotosan 2017年3月15日 (三) 06:52 (UTC)
        • 我把前兩個並列是表示不同默認情況對於兩方顯式標記的影響。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 08:22 (UTC)
        • reflist參數控制方面,由於參數1本身就有控制分欄數或分欄寬度並正確處理相應值的輸入,而自動分欄(如果設為auto)和分欄行為(需要設入大於1或指定寬度值)是互斥的,所以如果單獨用autocol屬性來控制自動分欄行為,又同時設置分欄屬性,即參數1,會產生歧義,所以用參數1判斷是否需要分欄最好。而且默認參數1值為1,肯定要不分欄,所以不能讓{{reflist|1}}等用於{{reflist|auto}}。——路過圍觀的Sakamotosan 2017年3月15日 (三) 09:21 (UTC)
          • 現在直接打{{reflist}}也是不分欄啊。{{reflist|1}}的效果一模一樣。——꧁༺星耀晨曦༻꧂留言) 2017年3月15日 (三) 09:42 (UTC)
          • 我沒有說什麼{{reflist|1}}等用於{{reflist|auto}}的鬼東西,我說的是不通過或通過時另一方要手動顯式(explicitly)標記自己需要做的事情的情況。既然單個處理麻煩程度相當,就可以認為這事情在工作量上的決定只和需要或不需要的條目數量有關。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 17:17 (UTC)
            • 「{{reflist|auto}}和{{reflist|1}}差不多方便」我不應為這是「差不多方便」的問題,這已經兩個歧義問題,一個要求手工1欄(不分欄),一個要求自動分欄,我看不出這兩個有啥相同。而且{{reflist}}現在的配置就是相當於{{reflist|1}}。在啟用默認自動分欄並且reflist手工分欄控制部分不添加responsive=0壓制的話,(因為我的分辨率是1600的),就會出現想mw:User:Cwek/reflist/testcases2不分欄卻分3欄的問題,如果這樣出現不是符合用戶要求的期望外輸出,我認為這功能就是有問題的。——路過圍觀的Sakamotosan 2017年3月16日 (四) 00:58 (UTC)
  • 如果一些條目存在這樣使用:
{{refbegin|2}}
*{{cite XX|.....}}
*{{cite XX|.....}}
*{{cite XX|.....}}
<references>
{{refend}}

在功能啟用並默認自動分欄的情況,會發生什麼問題,是否有影響?——路過圍觀的Sakamotosan 2017年3月15日 (三) 09:33 (UTC)

    • @cwek:會後一半偶數分,前一半二分。(不過本來就有圓點和數字的區別,我很好奇這樣看上去能更奇怪到哪裡去。)你能舉出問題我就能給出解法,MediaWiki:Common.css放一條div.refbegin.references-column-count > div.mw-references-columns, div.refbegin.references-column-width > div.mw-references-columns { column-width: inherit; } 就是。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 17:05 (UTC)
  • (+)支持,未見轉為自動分欄會有什麼問題。--J.Wong 2017年3月15日 (三) 11:06 (UTC)
  • (+)支持,技術問題我不懂,但純粹就最終的顯示結果來說,我支持預設自動分欄。由於中文文章通常比可以說明等量內容事項的西方語言文章簡短,因此比較需要利用斷行來減少版面右側過多留白的問題。--泅水大象訐譙☎ 2017年3月15日 (三) 11:40 (UTC)
    • @SElephant:這裏討論的的確衹有技術問題,而我們正討論如何使用的方法,事實上Cwek提出的方法一樣可以得到您想要的內建自動分欄顯示結果,而且也不需要像樓下Whhalbert所說做那麼多工作。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 12:35 (UTC)
  • (-)反對,估計要做的事情會是這樣:如果默認啟用,要改reflist模板和有關條目,也要逐個為單欄的條目加入responsive=0;如果默認不啟用,就只要改reflist模板和有關條目,單欄的條目則不用改。兩個方法效果都是單欄的繼續單欄,多欄的繼續多欄,最後效果都是一樣,但默認啟用卻要多花功夫,何不選一個較便捷的方法?--Whhalbert留言) 2017年3月15日 (三) 12:19 (UTC)
分欄的測試用例:User:Shizhao/reflist,請在各種屏寬下測試比較。另@Whhalbert:,自動多欄不是在任何時候都多欄,而是根據屏幕寬度自適應調整欄數,屏幕很窄的時候會自動變成單欄,屏幕很寬的時候甚至會自動變成3欄。而現在手工分欄做不到對屏幕寬度自適應調整,是死的。而且默認啟用的話,只需要更改幾個模板就行,除非認為大多數時候完全不需要自適應分欄,這時可能默認不啟用才有考慮的地方--百無一用是書生 () 2017年3月15日 (三) 13:13 (UTC)
@Shizhao:,都說明默認啟用自適應分欄「要逐個為單欄的條目加入responsive=0」,根本不可能「只需要更改幾個模板就行」的吧。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 13:28 (UTC)
可否舉個例,有哪些條目必須單欄?--J.Wong 2017年3月15日 (三) 14:36 (UTC)
不是必不必須單欄的問題,而是要保持條目原先的欄設定的問題,因為原先未設定自動分欄的條目,可能有其箇中的考量才不作設定(自動適應分欄也不是100%理想的),但默認啟用後而不對其做任何編輯的話,則那些條目在屏幕夠闊時自動分了欄,變相侵犯了其可能存在的單欄考量,所以才衍生了默認啟用後要逐個加入responsive=0的大規模工作以維持那些條目的原貌。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 15:45 (UTC)
你們的問題就是指不出有哪些考量,拿不出估計比例,做不了利害分析。你們現在怎麼整沒關係,就希望過一個月你們再來看看自己這個論據。什麼時候「保留原樣」變成公理了?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 16:25 (UTC)
您總不能因為「不知道他有甚麼原因」而就走去擅自整他的容啊……而且程式設計本來就不應該出現對已存在的用法出現改變的行為,不然就是Cwek所說的兼容性問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 16:48 (UTC)
@Cdip150:程序設計改變已出現的用法的行為的例子多得很。如果不改的話,Go語言到現在還是creat沒有create。如果不改的話,這世界的bug就全都變成feature了(鏈接是xkcd,請讀)。一團文字組成的列表居然還有「兼容性」可以討論,一團在屏幕寬度單一的時代估計出來「應該分1、2欄就夠了」的東西居然還可以不否決,我真不知道是不是我錯過了什麼reflist字符畫展。維基百科向來有WP:OWNWP:BOLD,也不知道什麼時候變成了「祖宗之排版方法不可變」的地方。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 17:00 (UTC)
用BOLD說明更改內容的顯示方式說明您完全不懂WP:BOLD:「如果您預計或看到有人反對您的條目版本,而是起源於您想要更改或刪除一些文章的本質內容,最好將您的異議在討論頁中列出,適當地引用不準確的文句,解釋您的理由和提供參考資料。」、「勇於更新條目可以是件好事,但勇於更新分類或模版常常是一件糟糕的事情。」更改界面、有爭議的修改從來就不是BOLD涵蓋的範圍。就算是管理員也不敢隨便修改界面內容。--Antigng留言) 2017年3月15日 (三) 17:06 (UTC)
@Antigng:將BOLD的對象改為半自動地拆掉別人的單欄處理,變成{{reflist|35em}}再看呢?——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 17:13 (UTC)
「這世界的bug就全都變成feature了」,但是原先的單欄做法本來就不是bug,根本沒有與bug相關的改變理由,閣下又用了一個不恰當的舉例進行比較。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月16日 (四) 03:49 (UTC)
user:Cdip150[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]硬編碼本身不是bug,硬編碼造成適應性不良就可以是UX bug了。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 00:34 (UTC)
無論你們討論的怎麼樣。。我希望我在為參考來源做引用的時候不用輸入那麼長(<references />)的標籤。能從目前比較流行的{{reflist}}來改善是最好的。無論怎麼樣,希望可以較為簡單的更換自動排版/手動排版,輸入的參數也不用那麼複雜。——꧁༺星耀晨曦༻꧂留言) 2017年3月15日 (三) 16:58 (UTC)
Artoria2e5君,印象中,曾幾何時,有一段時間有用戶喜歡用<div style="height: 400px; background:#eeeeff; padding:10px; border-color:#000000; border-width:1px; border-style:solid;"><div style="height: 400px; overflow:scroll; background:#ffffff;">框套在來源列表之外,固定框架長寬。這類算是必須單欄處理,否則好像會很礙眼。雖然不知道現在到底還有沒有,要找不知如何找尋……--J.Wong 2017年3月15日 (三) 19:24 (UTC)
@Wong128hk:這東西只固定了高度啊,實際上還是不影響分欄處理(其實固定寬度也還是不影響)。在mw:User:Artoria2e5/t1測試了一下,好像還行?(懶得編64個,所以壓到220px了)——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 20:25 (UTC)
  • 昨晚冷靜了一下,兩個問題:自動分欄,要(其實到時肯定會部署上來的);默認啟用,雖然看上去不錯,但是無法預測到意料之外的情況,所以出於兼容性的考慮,不太支持。不過至少reflist在調整後(用沙盒模擬了一下),看上去問題不明顯,所以對於是否默認啟用,只是功能上兼容性會很糟糕,但不反對或支持默認啟用。當然希望就是默認不啟用,要自動分欄的話,還不如直接用調整後的reflist。——路過圍觀的Sakamotosan 2017年3月16日 (四) 01:21 (UTC)
  • (-)反對,兼容性問題可能會很難收拾,更新一個功能是不應該導致舊做法出現任何一個錯誤,否則個別條目真的有錯誤時,要花很大資源去查找和修理,我比較支持上面用參數來啟用功能的做法,而反對默認。--Opky9407留言) 2017年3月16日 (四) 01:51 (UTC)
    • @Opky9407:目前已知可能出現錯誤的都和手動規定列數有關,增加Tracking category篩查即可。之前Cwek提到的refhead問題我已解決,你們有問題繼續說不就好了。哪有「很大資源」,不就是200大卡的食物嗎。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月16日 (四) 02:34 (UTC)
      • 你也說已知有問題,要篩查,即是要投資源,但是進行更新的原則本來應該對舊用法0修改,便能讓新舊功能同時運作。而且即使沒有發生編程錯誤,對舊用法進行根本上的輸出結果改變本來就是一種runtime上的兼容問題,是更新程序不該有的做法。--Opky9407留言) 2017年3月16日 (四) 03:05 (UTC)
        • 比喻有些不太恰當。按照你的比喻,舊用法可以看作是用戶自行hack添加的功能,而不是軟件本身的功能(開發沒必要照顧到用戶自己hack的東西)。新用法是為了適應技術發展,所做的對用戶更為友好的適應。或者說,用戶對單欄和/或手工分欄的需求更大,還是對自適應分欄的需求更大?至少對於小屏幕或移動設備,手工分欄是非常糟糕的體驗--百無一用是書生 () 2017年3月16日 (四) 03:47 (UTC)
          • 手動分欄也對移動視圖無效。都是直接一列下來。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 03:52 (UTC)
            • @星耀晨曦:我在那個phab:T160497的報告裡面診斷了一下問題,發現實際上自動分欄是生效了,只是屏幕字數限制寬度太低導致分不出欄的問題。推薦你做一個 囧rz...的表情……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月16日 (四) 13:29 (UTC)
          • 我不同意你的看法,適應新用法也要時間,不能因新用法的出現便立馬動舊用法的主意,而是應該新舊並行一段時間,適應了後才視情況決定舊用法的存留,而不是像現在馬上在舊用法上動土,令舊用法不能如以前般使用。--2017年3月16日 (四) 04:05 (UTC)
        • 「runtime兼容問題」這種比喻拿來跟打過gcc5 abi和glibc升級的人用有點過分了啊。這種人讀而不機讀的東西,哪有runtime不兼容這麼嚴重?

          在一個文本標記語言的輸出上糾結老排版行為是不是好、認為「前人特意分單欄」,就像是以「還有很多人用strlen數字數,說不定人家就是要字節數呢」一樣拒絕從ASCII遷移到UTF-8一樣(我今年倒還真見過一群用strlen數列數和字數的C程序)。本來做修改的目的就是批量改善這些老行為的局限之處,況且參考列表也好、ASCII/UTF-8也好都是程序或者讀者可以囫圇吞棗下去的東西,都是「沒多大事」級別的東西。如果無法在某個reflist或者references中觀測到這麼做的理由,同時發現分了之後在各種屏幕寬度下都沒多大事,那就應該當作不存在不做修改的強理由。如果發現個別條目這麼做的理由是編者自己屏幕窄不想分,那麼可以考慮用reflist另取一個在舊有屏幕寬度下不會分欄的尺寸。

          當然閣下可能是Visual Studio(非Unified Runtime,那玩意腦子正常得多)程序員,那個C++ ABI撲街是頻繁得多,習慣想到也是情有可原。不過那也算是你沒見過正常的Runtime基礎啊。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月18日 (六) 03:36 (UTC)

Artoria君及百無一用是書生君,如果是參考資料列表旁邊列有圖檔,自動分欄之下似乎會令到圖檔下出現一大片空隙。相反,不分欄則做到字包圖。參見此例。雖然可能並未能確切反映真實情況,不過仍請兩位就此回應一下。參考欄有圖檔並非少見,預設啟用自動分欄或者會破壞排版。--J.Wong 2017年3月18日 (六) 12:47 (UTC)
@Wong128hk:收到。瀏覽器的分欄,無論手動自動,估計都會受 CSS float 屬性元素的影響,按照某個最小寬度的位置做出決定。雖然我個人認為大部分這種東西應該放在「參見」而非「參考」,但分欄系統確實需要一個文字環繞float元素的模式。我今天有空的話看看怎麼做吧。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月18日 (六) 16:29 (UTC)
此問題已匯報至phab:T160830。--J.Wong 2017年3月19日 (日) 17:43 (UTC)
  • (-)反對:是條目歷史版本的不相容問題,上面承認了默認啟用會造成有條目的舊用法出現問題,即便篩查和修改,條目多年來的歷史版本仍會永遠被保留,默認啟用如果會造成那些歷史原本正常的舊單欄用法出現問題時,這對查看歷史或以前已被外部透過永久連結引用的舊版本很不利。因為條目歷史不能更改,當歷史版本顯示有問題時,會不可挽救。--Maccomcre留言) 2017年3月19日 (日) 11:31 (UTC)
    • 「無法挽救」是言重了。錯誤只影響機器生成的引用列表一段排版,造成的不便十分有限。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月20日 (一) 02:56 (UTC)
      • 即是最後還是有影響,不管它有沒有限,把本來肯定不會有不便的條目造成任何不便其實完全不應該,萬一有條目歷史版本的參考變形得很難看,連修改的機會都沒有。--Maccomcre留言) 2017年3月22日 (三) 00:13 (UTC)
  • (+)支持--耶穌會士張明山大師 2017年3月21日 (二) 13:14 (UTC)

可能受影響的模板

這裡列出部分可能受影響的模板,用於注意可能需要修改。有需要自行添加。——路過圍觀的Sakamotosan 2017年3月15日 (三) 11:39 (UTC)

列表只認為reflist有問題。別的都沒有任何控制分欄的選項啊。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 16:33 (UTC)

變成默認的話,那些模板事實上也難逃一改,因為它們本身都要使用純淨的<references />。一旦對那些模板修改,用了那些模板的條目難免又要檢修。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年3月15日 (三) 16:48 (UTC)
@Cdip150:你得給一個值得保留的例子,並且保證我不能舉出十個不該保留的例子。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 17:00 (UTC)

DYK更新好像出事了

DYK模板已經兩天沒有更,是不是出事了? -- 派翠可夫 (留言按此) 2017年3月14日 (二) 05:08 (UTC)

候選多一點,機器人就會存檔更新。--小躍撈出記錄) 2017年3月14日 (二) 23:10 (UTC)

Template:CC-notice

可能是Bug吧—以上有簽名的留言由R96340對話)加入。 2017年3月15日 (三) 08:19 (UTC)

似乎只是預覽的情況下沒有提供參數所致。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月15日 (三) 08:23 (UTC)
那大概弄個模板文件什麼的?—以上有簽名的留言由R96340對話)加入。 2017年3月15日 (三) 08:28 (UTC)

要不要新增帳戶密保問題

要不要新增帳戶密保問題 —以上未加入日期時間的留言是於2017年3月8日 (三) 16:42 (UTC)之前加入的。

請向P區建議。——路過圍觀的Sakamotosan 2017年3月9日 (四) 00:44 (UTC)
已有phab:T10460,建議看看建議是怎麼死掉的。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月16日 (四) 13:34 (UTC)

如果我想要將一段文字放到右欄,該怎麼做?

案發現場

如上--脂肪酸鈉留言) 2017年3月17日 (五) 00:58 (UTC)

@脂肪酸钠:已在b:Special:Diff/85278b:Special:Diff/85279完成,可以讀讀注釋。覺得有用的話可以做一個模板哦。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 15:00 (UTC)
做了一個b:Template:aside。有可能做成asideH/asideF這種格式更好,可我是懶得……——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 15:08 (UTC)
@Artoria2e5:感謝。感覺如果可以把<references />放到這個模板里的時候實現將腳註變成旁註的話,這個模板會更有用。我就隨便說說。--脂肪酸鈉留言) 2017年3月22日 (三) 05:31 (UTC)

Portal:國際關係

若問題放錯地方請見諒。請問 → → →

為何會出現拼圖?先前有圖示,但最近時有時無。--Tp0910留言) 2017年3月17日 (五) 19:02 (UTC)

@Tp0910:參看Template:Portal/Images的提示。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月17日 (五) 22:23 (UTC)
用手工?我以為是系統問題。我試試,先謝謝了。--Tp0910留言) 2017年3月18日 (六) 16:50 (UTC)
@Tp0910:不是叫你用手工啊!是叫你去那個模板文檔鏈接到的 module 的對應資料庫裡面,把 template 下的圖片放進去。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月18日 (六) 17:18 (UTC)
修好了,沒圖的要麼本來就沒圖,要麼就是Portal:首頁/列表里沒這個主題。--Qwhisper 2017年3月19日 (日) 13:42 (UTC)
感謝。--Tp0910留言) 2017年3月19日 (日) 18:38 (UTC)

要不要推出維基百科win10通用應用

要不要推出維基百科win10通用應用—以上未簽名的留言由Lilwe對話貢獻)於2017年3月18日 (六) 12:28(UTC)加入。

官方APP,雖然不是UWP而且體驗超差,但聊勝於無~~--Jerre Jiang  討論參與清理積壓站務  2017年3月18日 (六) 13:00 (UTC)

搜尋框是否有問題?

之前輸入繁體字時,會有顯示簡體字的相關條目,但現在郤不會。還有另一個情況,例如我輸入「沉默 1971」時,會顯示「沉默 (1971年電影) 」的條目,但現在也不會。請問發生甚麼事?--Onemansky留言) 2017年3月19日 (日) 14:35 (UTC)

同上,應該是相關代碼又有改動,還是希望能夠知道是哪裡的代碼的改動造成了這一情況,還是希望搜索框和HotCat輸入簡體字能同時顯示簡體和繁體的結果。--№.N留言) 2017年3月19日 (日) 14:42 (UTC)
phab:T160919已報告。——Artoria2e5 保持討論完整直接{{ping}}我回復 2017年3月20日 (一) 15:56 (UTC)
雖然問題算是解決了,但是還是有點問題:搜索框用簡體輸入其他名字空間的頁面時不能輸出對應的繁體頁面……HotCat也是一樣……--№.N留言) 2017年3月23日 (四) 02:10 (UTC)

怎麼使用其他語言的機器人

俄語維基百科中有個機器人「KrBot」可以自動更新模板中的匯率數據,ru:Участник:KrBot,他的操作者這ru:Шаблон:Валютный курс#How to copy the template to another wiki-project寫了怎麼處理,但我整明白。 --苞米() 2017年3月19日 (日) 20:12 (UTC)

Tech News: 2017-12

2017年3月20日 (一) 22:03 (UTC)

js寫的熱門動態

寫了一個用js顯示熱門動態top10的腳本User:Shizhao/uptrends.js,不知道首頁的熱門動態能否改用js來實現,而不用bot天天的去更新?

用法:在你用戶頁的的common.js頁面加入一行:

importScript('User:Shizhao/uptrends.js');

,然後在任意頁面加入一行:

<div id="uptrends" class="uptrends"></div>

。刷新頁面後就能看到了--百無一用是書生 () 2017年3月21日 (二) 10:07 (UTC)

吐槽一下編碼風格,i計數器累加可以用++,jQuery可以代勞HTML的DOM操作,結果一堆html生代碼拼湊。有點沒用盡特性吧。——路過圍觀的Sakamotosan 2017年3月22日 (三) 02:00 (UTC)
重寫了一下(嗯,我基本不信JQuery教……)。——Artoria2e5 討論要完整回復請用ping 2017年3月22日 (三) 13:25 (UTC)
那麼是否可以用這種js的方式在首頁的Template:Uptrends自動實時展示top10呢?(放到Mediawiki:common.js)。@Jimmy Xu:--百無一用是書生 () 2017年3月23日 (四) 12:38 (UTC)

數學公式顯示錯誤

Screen Capture 03 21 2017.png

右圖展示英文維基條目en:Cauchy–Schwarz inequality的部分內容。請問為什麼數學公式最後部份未能顯示出來?謝謝幫助!--老陳留言) 2017年3月21日 (二) 23:26 (UTC)

這個版本下, 我這裡顯示正常。 --碸中嘌呤的白磷萃取 打譜 2017年3月22日 (三) 01:40 (UTC)
可能需要到英文維基提出此問題。--老陳留言) 2017年3月23日 (四) 05:15 (UTC)

我們需要您的幫助來評估一個新的中文語言分析器在搜索引擎中的效果。

我們需要您的幫助來評估一個新的中文語言分析器在搜索引擎中的效果。

這個分析器的目的是將繁體中文和簡體中文都放入同一個索引中。這樣一來,無論您以繁體或簡體進行搜索,都將得到所有的結果。使用現有的搜索引擎時,如果您在中文維基百科上搜索「飓风」將得到1,128個結果;如果搜索「颶風」將得到1,835個結果。在使用新的分析器之後,無論您使用簡體或繁體都將得到2,355個結果,儘管結果的排序略有不同。新的分析器還能夠更好的識別您的查詢當中的多字詞。

當然,我們的分析器並不完美 -- 但我們希望最終的效果是利遠大於弊的。

在WMF Labs里有一個中文維基百科索引的副本(這意味着您可以搜索並看到結果的片段,但無法看到完整的文章)。您可以從這裡進行搜索: http://zh-wp-smartcn-relforge.wmflabs.org/w/index.php?title=Special:搜索

如果您有時間的話,請幫我們測試一下吧!從上面的鏈接進入lab,嘗試進行幾個查詢,看看您對結果是否滿意。如果您願意的話,還可以將此結果和現有的中文維基百科的搜索引擎的結果比較一下。

我們衷心的感謝您的任何反饋 -- 包括任何的意見和批評!

TJones (WMF)留言) 2017年3月22日 (三) 22:16 (UTC)

我記得以前有人繁簡搜索結果有差異,應該是這個問題的解決了。誰去嘗嘗如何?——路過圍觀的Sakamotosan 2017年3月23日 (四) 00:41 (UTC)
找到了,好像是T77967的解決方案?@SFSQ2012Liuxinyu970226Shizhao:能去看看這個解決如何?——路過圍觀的Sakamotosan 2017年3月23日 (四) 01:18 (UTC)
Sorry to reply in English. I can get translation help again if needed. The change should help T77967. Both examples from T77967 get the same number of results with the new language analysis. Generally, Traditional and Simplified searches should get the same results, but the results can be in a different order because exact matches are preferred. TJones (WMF)留言) 2017年3月23日 (四) 14:50 (UTC)

小作品鏈接樣式優先級不應高過消歧義橙鏈優先級

參數設置裡面有兩個和鏈接顏色有關的功能,一個是MediaWiki自帶的小作品標為深紅色,一個是有人寫的橙色標記消歧義。從使用上來說,既然知道一個頁面是消歧義,就顯然不是內容頁面,不用在意是不是小作品。

查了一下瀏覽器裡面的CSS匹配情況,發現是a.stub的CSS顏色規則寫在了a.mw-disambig之後,按照CSS「選擇器細度」相同時的處理規則取最後一個定義的話就會用到a.stub的顏色。要修復的話,可以整一下MediaWiki:Gadget-DisambiguationLinks.css,把a.mw-disambig改成a.mw-disambig.mw-disambig。CSS 3標準允許通過重複使用選擇器假裝提高「選擇器細度」(「很重要的話要說兩遍」的意思),從而提高規則的優先級。或者也可以加一個a.stub.mw-disambig的特例處理。

@Alexander Misel:請修復。——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 00:11 (UTC)

把英語維基的 common.css複製過來,再加上中文維基需要的碼

把 common.css分成兩部份,第一部份是英文維基的複製貼上,第二部份是中文維基style的額外需求。

好處是英語維基的 patch可以快速套用到中文維基裡,共享英語維基的碼。第二好處是兩者的 diff非常明顯。

Golopotw留言) 2017年3月23日 (四) 01:48 (UTC)

@import url?——路過圍觀的Sakamotosan 2017年3月23日 (四) 02:24 (UTC)
@import url能在common.css里用嗎?另外,據說不久要上templatestyle--百無一用是書生 () 2017年3月23日 (四) 03:47 (UTC)
試試唄,好像試過完整url會有效?——路過圍觀的Sakamotosan 2017年3月23日 (四) 06:55 (UTC)
不贊成。因為 page render會慢一個 request的時間。 Golopotw留言) 2017年3月23日 (四) 12:23 (UTC)
值得一試。——Artoria2e5 討論要完整回復請用ping 2017年3月23日 (四) 15:51 (UTC)

DYK機器人可能有BUG可能需要修正

@LiangentJimmy Xu

DYK機器人在特殊:Diff/43716962
誤將「植醇 編輯 | 討論 | 歷史 | 連結
讀成「植醇 }} **{{補充}}:感謝{{ping 編輯 | 討論 | 歷史 | 連結
推測可能是因為他是讀到「|」才終止,導致格式不正確時有停不下來的可能,這BUG可能有修理的必要,否則可能會導致Overflow。如果不能修理或我發錯地方也告知我一下-- 宇帆留言·歡迎簽到·) 2017年3月23日 (四) 07:38 (UTC)

存廢討論與模板問題

請問在頁面存廢討論中提出用戶頁刪除請求後是否需要放置模板,如果是,那放到哪裡?我試過在該用戶頁中放入{{Vfd|理由}}模板,但未能成功。--HK Reporter留言) 2017年3月23日 (四) 08:44 (UTC)

您編輯次數沒到50次不是自動確認用戶,觸發了過濾器編輯其他人的用戶頁時會被警告……所以提刪也是無效的,很抱歉。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 08:47 (UTC)
???27號過濾器不會阻止新用戶編輯他人用戶頁啊,想想閣下的用戶頁被IP破壞的時候。——꧁༺星耀晨曦༻꧂留言) 2017年3月23日 (四) 08:54 (UTC)
是的,過濾器日誌里那位老兄也只是被警告了,估計他/她沒有繼續。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 08:55 (UTC)

是否能快速尋找有來源但來源沒有掛references /的條目

如題,是否有方法可以快速找出有列出參考來源,但條目裡沒有用<references />,導致來源散亂在頁面最下方的條目。如果可以,是否可以用機器人在該條目底端加上

 == 參考來源 == 
 <references />

感謝。--KRF留言) 2017年3月23日 (四) 10:59 (UTC)

可以使用Category:參考文獻缺失的頁面跟蹤,但是並不是頁面底部,因為頁面底部還有導航模版、小作品、分類標籤等。至少是在分類和導航模板之間。——路過圍觀的Sakamotosan 2017年3月23日 (四) 11:07 (UTC)
那就人工掛上去好了,又可以刷編輯次數了,たのしー! --KRF留言) 2017年3月23日 (四) 11:58 (UTC)
@cwek:這分類跟沒有<references />無關吧,(剛不小心ping成Kerolf666了)。--A2093064#Talk 2017年3月23日 (四) 12:03 (UTC)
這題有請User:Tigerzeng來答。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 12:01 (UTC)
趁他還沒來先扯兩句,機器人搞這個太麻煩了,因為參考文獻的格式太多,不管繁簡問題就有「參考來源」「參考文獻」「參考資料」「資料來源」「參考」「注釋」「注」等等用法,{{reflist}}也有一大堆重定向模版。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 12:07 (UTC)
找有<ref>標籤但沒有<references />的條目?——꧁༺星耀晨曦༻꧂留言) 2017年3月23日 (四) 12:38 (UTC)
是的,找有<ref>但沒有<references />的條目,不能用機器人就用手工掛。 --KRF留言) 2017年3月23日 (四) 13:14 (UTC)
搞事!搞事!pywikibot有這個腳本,而且內置了四五種可能的標題(算上繁簡就是八到十種)。運行中發現問題還能手動添加。reflist模板也是一個道理。其實我也覺得挺麻煩的,所以一般就是遇到沒reflist的,就手動加上去。--Tiger留言DDL是第一生產力 2017年3月23日 (四) 13:21 (UTC)

求助

被嚴重騷擾該如何處理

方才與其他編輯進行討論時,該編輯竟試圖「人肉搜索」出在下的真實身分,甚至已經調查出一位無辜的「XXX」先生,在下感到相當的恐懼,愈想愈不對勁,這已經是嚴重的騷擾行為,想請問各位閣下:在下可以怎麼樣尋求協助?- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 17:49 (UTC)

並未發現明顯的威脅語句。——꧁༺星耀晨曦༻꧂留言) 2017年3月10日 (五) 17:54 (UTC)
@星耀晨曦:感謝閣下於信件中的關心。- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 18:59 (UTC)

(※)注意本求助已由管理員進行嚴正警告並刪除嚴重騷擾的修訂版本,已經獲得處理,謝謝!- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 18:55 (UTC)

感謝User:星耀晨曦關心此事,我必須做些說明,Aotfs2013的名字的資訊連結到現在都還留存在維基,而且連結還是Aotfs2013自己加上去的,Aotfs2013惡意汙蔑本人試圖「人肉搜索」,卻忽略自身於網路身分公開與否之謹慎性,並聲稱我的善意溝通是「嚴重」的騷擾行為,說真的,我的確不小心違反騷擾方針中真實性名乙節,但絕非「惡意騷擾」,反倒是Aotfs2013非常玻璃心、草莓族地認為我在「嚴重」騷擾,並惡意汙蔑本人試圖搜索實屬不可取,建議Aotfs2013應當藉此教訓,反思自己於網路上的編輯及言論是否自我公開而不自知,一昧的指控他人,卻不知自省,本人實屬無奈。-Jack.T 2017年3月11日 (六) 04:19 (UTC)
閣下的辯解十分荒謬,試問:關於環北站的編輯爭議討論中,有什麼必要使閣下使用「姓名」稱呼在下?說到這邊就不言自明了。至於閣下對於在下玻璃心、草莓族的污辱,在下非常難過閣下竟試圖透過抹滅在下的人格,來為自己已經受到嚴正警告的嚴重騷擾行為辯護,令人難以置信。- 執行編輯 Aotfs2013 留於 2017年3月11日 (六) 08:31 (UTC)
並不荒謬,因為妳自己在維基公開了真實姓名連結,所以我知道妳的名字,但卻不小心打了出來,如此而已,根本沒有經過任何必要性的考量,也沒有惡意騷擾之意。老實說,妳都直接認定別人不小心說出妳姓名叫「嚴重騷擾」,那妳真的有做到「善意推定」嗎?竟然直接誤導大眾我在「人肉搜索」妳,這不是抹黑什麼是抹黑?至於我為什麼會收到「嚴正警告」不就是妳自己在互助客棧告的狀嗎?妳自己都說妳相當的恐懼,請問我恐嚇妳了?威脅妳了?我只是不小心說出「妳自己公開」的真實姓名而已耶!妳自己可以決定這件事可大可小,但你卻選擇用非常手段的方式來對付其他維基人,試問:這樣真的比較高尚?真的比較厚道?-Jack.T 2017年3月14日 (二) 11:42 (UTC)
你說是他自己公開了真實姓名連結,請問證據何在?否則也只是你單方面的說詞,沒人看到你說的連結。現在大家只看到「他指控你騷擾他,你指控他抹黑你」這種情況,結果就是可能演變成各說各話,對你依然是沒有幫助的,因為你被封禁的原因是管理員採信,至於他採信什麼證據就要問封禁你的那位管理員,所以我不敢貿然說是不是來自這裡的指控騷擾。然而,令人感到遺憾的是,你在這裡向各位說離開維基百科,不知道是否因為被管理員給封禁的緣故,還是出自Aotfs2013在這指控你騷擾他?--36.233.189.97留言) 2017年3月15日 (三) 16:51 (UTC)
如上所述,證據連結「到現在都還存在維基」,建議36.233.189.97如果這麼好奇想知道,可以辦一個維基帳號我用系統傳E-mail給閣下連結,之所以不直接將連結貼在這裡,其一考量是Aotfs2013並不希望讓大家知道他的真實姓名,我擔心貼上來又構成WP:騷擾(雖然是她自己的編輯);其二是因為極度擔憂Aotfs2013會感到相當的恐懼,怕她的心靈受到太大的刺激,到時候萬一做出什麼傻事,我可擔當不起阿!-Jack.T 2017年3月16日 (四) 10:40 (UTC)
詳細封禁理由在騷擾方針指明無論真偽,張貼個人資料即為騷擾,除非該用戶自願提供。然而此非主因。主因在人身攻擊,及不必要接觸。證據正是此段。攻擊無助於討論及解決爭議,由討論爭議,到變成研究是否騷擾。如此,根本無濟於事。維基百科收錄準則在有否來源佐證,而非真偽,否則地心說可刪矣。盡早要求社群介入,總比爭議白熱化才交上來好。--J.Wong 2017年3月15日 (三) 17:52 (UTC)
@Wong128hk:理由是種說詞,並不是出於紀錄給人看見所被採信的證據(指Happy60907對Aotfs2013做出調查「XXX」先生的留言紀錄),而且沒代替Happy60907問,只是認為他若想知道被封禁是基於什麼證據而被管理員採信,叫他自己去向管理員要證據。你們二方的事情,其實是管不上邊,畢竟管理員已經將紀錄給刪除,一般權限的維基用戶(含未註冊的IP用戶)都無法被看見證據,不是出個說詞成為理由就是可以封禁,否則結果很容易會淪為濫權的或被人懷疑濫權,相信這是每位參選管理員都會知道(會不會遵守是另當別論)。當然不是懷疑或認為管理員濫權,而是紀錄被刪除就沒人看見,我只是以同理心去說罷了,剩下就是看Happy60907要不要去找你拿出證據,到時你再對他說就好了。--36.233.180.169留言) 2017年3月15日 (三) 18:37 (UTC)36.233.180.169留言) 2017年3月15日 (三) 18:45 (UTC)更新
監督員之間相互監督以防濫權。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 00:09 (UTC)
@36.233.180.169Wong128hk之所以會封禁我,是因為我說Aotfs2013是玻璃心、草莓族,她不甘受辱所以到Wong128hk留言板向管理員申訴,或許是我說話比較直吧,傷到她的幼小心靈了,我之所以會用玻璃心、草莓族是因為我曾經於台大PTT實業坊這樣使用過,期間也沒有因違反相關板規遭到水桶(類似封禁),但畢竟維基不一樣啊,我應該更注意發言才對,必須再次對傷及Aotfs2013的幼小心靈說聲SO SORRY。-Jack.T 2017年3月16日 (四) 10:40 (UTC)
如果Aotfs2013的個人信息在事發之前留在維基百科上,那麼Happy60907就不需要為此行為負責。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 10:48 (UTC)
我一編輯,就有人跟在我屁股後面尾隨,試問單兵如何處置?-Neville Wang 奈威 2017年3月11日 (六) 04:31 (UTC)
@Neville Wan:這也構成了騷擾,相信閣下的被騷擾遭遇跟大多數的騷擾一樣,令人感到困擾且不舒服。- 執行編輯 Aotfs2013 留於
請Happy60907注意,在進行意見討論的時候應該針對條目內容以及事件的本身,而不是針對編輯者個人或是其他參與者進行人身攻擊。任何時刻都必須善意推定他人的行為,不論是誰先開始引發爭端,請先保持冷靜並且思考問題解決的方式,並且說服他人並且達成共識,我相信這才是問題解決之道。--T.A Shirakawa(Talk - Mail) 2017年3月11日 (六) 09:58 (UTC)
感謝T.A Shirakawa的提醒。-Jack.T 2017年3月14日 (二) 11:42 (UTC)

這事兒已經很明朗了:Aotfs2013擔心自己受到人身威脅,而Happy60907則不清楚WP:騷擾方針非惡意的貼出(疑似)個人信息。——꧁༺星耀晨曦༻꧂留言) 2017年3月11日 (六) 05:25 (UTC)

現在Happy60907說詞顯然與Aotfs2013不一樣,一方是認為被人肉搜索,另一方卻說他自己公開給他知道的,問題是留言會有紀錄的,有一方留言是大家可以看到,反而另一方是沒提出證據去說明對方是怎樣的公開,自然會被大家採信他留言紀錄,因為沒人看到他在哪公開給他知道,只看見他留言紀錄裡確實有寫出對方真實姓名,只不過管理員事後給刪除這筆,所以現在大家才會看不到。至於真實姓名是否為Aotfs2013所有,這並沒被證實與承認,只知道Aotfs2013是擔心對方人肉搜索而才感受到威脅。至少,這事件看起來也沒到刑法地步,不太明白Happy60907為何要說離開維基百科?--36.233.189.97留言) 2017年3月15日 (三) 17:00 (UTC)
我保證我沒有人肉搜索她,這都是她自己公開的訊息,不過說再多也於事無補,因為這個事件,我回退員及巡查員的資格也被拔了,雖說我已決定退出維基,但突如其來的撤銷權限舉動讓我覺得非常有疑問(完全不懂權限和這件事有什麼關係?我並沒有濫用回退員及巡查員的權限,自認都有做好每件回退及巡察工作,希望@Wong128hk:及@Alexander Misel:可以給個說明),為維基奉獻付出不少卻什麼都沒得到,或許就像人生如夢一場,離開不見得是件壞事,能另循它路充實自我也是不錯的!-Jack.T 2017年3月16日 (四) 10:40 (UTC)
本不想再回覆這痛苦的事,既然落幕了,也不願再浪費社群資源。不過,有必要澄清一點:閣下所公布的姓名絕非在下的真實姓名,在下也不識此人,在下純粹就閣下的行為感到恐慌,更擔憂閣下意圖對閣下所公開(資料挖掘)出的名字的主人不利;當然,在下也不會大費周章、冒著風險公開在下持有的身分證明文件澄清。到此為止。- 執行編輯 Aotfs2013 留於 2017年3月16日 (四) 10:51 (UTC)
提案《權限解除申請》純粹因為該方針規定「當管理員封禁任何一位依從權限申請方針獲得權限的用戶時,請同時提報,讓其他用戶覆核考慮是否為之除權。」或者有請@Alexander Misel:解釋決定。解釋之後,仍有不滿,則可提案至《權限解除申請》要求其他管理員覆核。其實經過多人提醒,何以閣下要瓜田李下,就不肯就事論事,總要對其他用戶配上不必要的形容詞呢?這樣亦陷你自己於不利。騷擾在維基之中其實比起其他方針更要求管理員即時應對。--J.Wong 2017年3月16日 (四) 12:07 (UTC)
@Wong128hk:請User:Wong128hk說明何謂「瓜田李下」?我如何「瓜田李下」?並詳細指出我所述之哪一段落、哪一句話不肯就事論事?配上不必要的形容詞這點我可接受,但前段務必請汝說明清楚,以免淪為子虛烏有之嫌。-Jack.T 2017年3月16日 (四) 13:15 (UTC)
  • @Wong128hk:我認為此番封禁不妥。根據WP:善意推定,當事人Happy60907承認自己並非有意貼出「個人信息」。那麼根據WP:騷擾:「在維基百科,除非張貼他人資料是無意且不具惡意的行為,否則僅憑試圖張貼他人資料已經足夠使公開資料者被立即封禁。」我覺得,對於此事件,監督過並對Happy60907提出警告即可。也根據WP:封禁方針的精神,封禁是防止破壞而不是用來懲罰的,按照Happy60907的說辭,已有明顯的悔改之意,封禁也無濟於事,反而有可能會造成當事人離開中文維基百科。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 14:54 (UTC)
Jack君,所謂瓜田李下所指是閣下行為及言語均易於引人誤會,就事論事何以須要配上不必要的形容詞呢?
星耀晨曦君,在這件事上,個人考量是單單人名,或者單單人身攻擊,個人都覺得毋須封禁,警告即可。所以Jack君張貼人名之後,本人亦只是警告。直至再收到投訴,見到Jack君使用不必要的形容詞,本人才開始思量是否需要封禁,亦開始思量再發警告,是否就可以制止人身攻擊。隨著爭議白熱化,會否越來越嚴重。而騷擾及人身攻擊均屬嚴重行為,在任何討論之中,以至在任何爭議之中,都並非必要,而且使用之後,爭議只會更趨激烈,對解決爭議毫無幫助,亦破壞討論風氣。一如本人通知封禁時所述,是次封禁志在令Jack君「了解維基百科不能容忍其行為,應改善及避免該不當行為持續」。本人亦難以視兩件事為單獨事件。--J.Wong 2017年3月17日 (五) 03:09 (UTC)
  • @Wong128hk:但依據WP:封禁方針,「需要封禁的情況→保護用戶或社群」乙節,我並沒有「持續人身攻擊」;另,「需要封禁的情況→防止破壞」乙節,我亦沒有「持續騷擾行為」,況且兩者亦非同一方針,這樣任意不依方針的封禁是否可以合理懷疑User:Wong128hk涉嫌濫權?這樣不符合比例原則的封禁使維基使用者在維基百科留下汙點該如何申訴平反?-Jack.T 2017年3月17日 (五) 12:57 (UTC)
  • 騷擾方針亦有此句︰「騷擾:反覆惱人與不必要的接觸、一再地人身攻擊、或威脅其他人停止編輯維基百科。各種形式的騷擾如未加以裁製,可能會造成百科全書的瓦解。」在下實在無辦法獨立對待兩個因同一件事而起的行為,亦無辦法排除閣下有進一步行動的可能。考慮到閣下貢獻不鮮,亦有擔任管理工作,此兩項嚴重行為只是因為一時未能冷靜,所以大幅縮短封禁期至三日,以祈三日之後,閣下明白維基應有的議事之道並能夠冷靜地參與相關爭議的討論。另外,閣下所援引段落亦有「封禁通常用於以下情況,但不限於這些情況」。--J.Wong 2017年3月17日 (五) 13:50 (UTC)
    • @Wong128hk:但問題我沒有「一再地人身攻擊」,況且當初不小心說出真實姓名與「一時未能冷靜」也完全搭不上邊,您卻直接認定兩個行為皆是因一時未能冷靜而合併看待是否有失公允?後者之人身攻擊係因Aotfs2013惡意抹黑本人進行「人肉搜索」(這樣的抹黑、個人臆測之行為是否可定義為您口中的「不肯就事論事」、「瓜田李下」?),故因急於一時澄清而用詞較為強烈,兩者雖出自於同一事件,但後者係與其延伸之事件相關而非與事件主體相同,故兩者應有所區別,亦請User:Wong128hk說明。-Jack.T 2017年3月17日 (五) 14:13 (UTC)
    • 兩事之間,時間相當短。兩次都屬於不必要接觸,都不是解決爭議之中必須,亦不是澄清必要的行為。恕在下無法區別對待兩件事。沒了那些不必要的形容詞,閣下一樣可以澄清。閣下一邊否認「一時未能冷靜」,一邊說「因急於澄清而用詞較為強烈」,難道不覺略有矛盾?至今,閣下上面提及Aotfs2013時,仍語帶輕挑、諷刺。或者閣下不屑其所為,但是否需要每次留言都表露出來呢?另外,僅憑現時所有證據,本人無法判斷「人肉搜尋」是否僅屬臆測,甚至是閣下所言的刻意抹黑,抑或是見到「人名」之後的合理推測。封禁目的並非要為閣下留下污點,而在令閣下更為熟習維基百科各項方針及指引。--J.Wong 2017年3月17日 (五) 16:50 (UTC)
  • @Wong128hk:我所否認之「一時未能冷靜」是指「不小心說出真實姓名」這件事情,而非指「因急於澄清而用詞較為強烈」這件事情,由於閣下上面說「此兩項嚴重行為只是因為一時未能冷靜」,因此字面上解釋為:閣下將兩件事情都理解成未能冷靜之緣故,我只是澄清前者與「一時未能冷靜」並無關聯,因此並沒有矛盾,閣下可能誤解我上面說的意思;其次,語帶輕挑、諷刺為閣下之主觀觀感,並非普世價值,故本人不做評論;另,不論是否為臆測或抹黑或推測,在事實尚未明朗前,單方面以「竟試圖人肉搜索」這樣的字眼來指控他人閣下認為是否必要及妥當?-Jack.T 2017年3月17日 (五) 18:15 (UTC)
  • 明白。若然這個人名他真的無提供過,而閣下突然列出名字,其惟恐有「人肉搜尋」,此謂之合理推測。若然其真的曾經以其現有帳戶公開過名字,及後又無再表示不希望他人去使用,而刻意指控閣下「人肉搜尋」,此謂之刻意抹黑。不過,正如之前所述,現有證據有限,恕無法判斷。--J.Wong 2017年3月18日 (六) 04:47 (UTC)

{{中國抗日戰爭}} 右邊界設定似乎不太正確, 請修正

https://zh.wikipedia.org/wiki/%E4%B9%9D%E4%B8%80%E5%85%AB%E4%BA%8B%E8%AE%8A

九一八事變條目下面 有3個區塊(我不知道該怎麼稱呼), 其中

查 论 编 中国抗日战争

點開後, 右邊界設定似乎不太正確, 另外2 個就沒這問題, 請修正

--Adyu留言) 2017年3月13日 (一) 11:10 (UTC)

複述一下樓主的問題,模版{{中國抗日戰爭}}中列舉的各項之間用了{{.w}}導致項目之間無法換行,於是右邊界過長。遺憾的是我懶得修 囧rz... --碸中嘌呤的白磷萃取 打譜 2017年3月13日 (一) 11:15 (UTC)
 已修復Special:Diff/43604855。-和平、奮鬥、救地球!留言歡迎加入維基Telegram群 2017年3月14日 (二) 00:04 (UTC)

關於頁面文章

請問我可以將英文維基百科的內容翻譯成中文,然後將內容貼上中文維基百科?又或者是將中文維基百科的內容複製,翻譯成粵語,然後將內容貼上粵語維基百科?—以上未簽名的留言由User3204對話貢獻)於2017年3月14日(二) 12:03(UTC)加入。

參見WP:翻譯守則。關於「將中文維基百科的內容翻譯到粵語維基百科」,得視粵語維基百科那邊的方針。一般情況下,只要標註翻譯來源就可以翻譯。——꧁༺星耀晨曦༻꧂留言) 2017年3月14日 (二) 12:11 (UTC)

我想建立『中華民國全球週一無肉日聯絡平台協會』條目

我想建立這個條目,但是出現 [本頁已被禁止建立和編輯,只有管理員可以取消此建立限制。因為標題「中華民國全球週一無肉日聯絡平台協會」和本地或全域黑名單 .*平.*台.* <autoconfirmed>配合。這通常是為了防止破壞性的編輯。] 想請管理員幫我建立,感謝

註:此處原有文字,因為屬於測試編輯,已由Kou Dou於2017年3月14日 (二) 22:38 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。
經過在下測試,該頁面可以正常建立。 --KRF留言) 2017年3月16日 (四) 14:08 (UTC)
autoconfirmed為自動確認用戶群組。-- Willy1018(留言) 2017年3月16日 (四) 14:11 (UTC)

阿爾及爾兩家清真寺的命名

阿爾及爾有家(新的清真寺英語Jemma Al Djazair,意即「阿爾及爾清真寺」)最近封頂[26]。我們已經有阿爾及爾大清真寺的條目。新的條目如何命名?新阿爾及爾大清真寺?我不建議用嘉瑪冠名,因為嘉瑪就是清真寺的音譯。--Whhalbert留言) 2017年3月14日 (二) 18:14 (UTC)

敝人外行,但考慮是否可以採用阿爾及爾清真寺大清真寺 (阿爾及爾)方式分別命名?Kou Dou 2017年3月14日 (二) 22:37 (UTC)

Rum-running的中文名

請問Rum-running英語Rum-running的中文名應該叫甚麼?我看過一個名叫「朗姆酒飛車」,但不知是否正確。--Fireboyma留言) 2017年3月16日 (四) 11:33 (UTC)

為何一直顯示合理使用圖片?難道是要列明來源嗎?

我在Portal:韓國流行音樂/新聞放入一張非自由版權的圖片,但是User:Jimmy-bot就一直放入:File使其不能使用,請問各位如何解決此問題(我認為是要列明出處吧) angys 2017年3月16日 (四) 15:39 (UTC)

非自由圖片只能在條目中使用。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 15:42 (UTC)
在維基共享里找自由圖片咯。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 15:46 (UTC)
根據Wikipedia:非自由內容使用準則方針第9條規定,非自由內容只被允許在條目中使用。另外Jimmy-bot的編輯摘要語焉不詳,已經造成很多用戶困擾,建議修改成例如「非自由內容只允許在條目中使用」,可包含WP:NFCC的鏈接。--Wcam留言) 2017年3月16日 (四) 15:48 (UTC)
(+)同意樓上。「合理使用」的名字也讓新用戶誤會過,以為怎麼用都是合理的。 --碸中嘌呤的白磷萃取 打譜 2017年3月16日 (四) 15:49 (UTC)
需要通知Jimmy。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 15:51 (UTC)
已通知。--Wcam留言) 2017年3月16日 (四) 15:55 (UTC)
之前jimmy在IRC上說只要把提醒模板做出來,他的bot就可以自動通知用戶。--Antigng留言) 2017年3月16日 (四) 16:02 (UTC)
我很久前寫過一個User:WhitePhosphorus/磷原子3號/FNFC,最近又調了調,大家看看怎麼樣,合適的話可考慮挪到template空間。 --碸中嘌呤的白磷萃取 打譜 2017年3月17日 (五) 13:17 (UTC)
額,這個提示開頭是「您創建的頁面」。如果出現往已經存在的頁面加入非自由圖片的情況,怎麼辦。——꧁༺星耀晨曦༻꧂留言) 2017年3月18日 (六) 04:54 (UTC)
已改成「您最近編輯的頁面」。 --碸中嘌呤的白磷萃取 打譜 2017年3月18日 (六) 11:16 (UTC)

正在編輯「習近平外事訪問列表」,誤操作放在了自己的用戶文件夾下,變成了User:/習近平外事訪問列表。如何解決?

如題。請問這個問題如何解決?謝謝~~—以上未簽名的留言由100.8.223.93對話貢獻)於2017年3月18日 (六) 04:21‎加入。

還請閣下告知您具體的賬戶以及該頁面位置?Kou Dou 2017年3月18日 (六) 04:24 (UTC)

謝謝您~~是這個 User:Abysshades/習近平外事訪問列表--Abysshades留言) 2017年3月18日 (六) 04:31 (UTC)

歡迎並感謝您參與維基百科的編輯,您所提出的問題已獲得解決,請繼續在習近平外事訪問列表完善該條目!先前頁面標題在被移動後已由敝人代為請求WP:快速刪除Kou Dou 2017年3月18日 (六) 04:33 (UTC)
非常感謝您的幫助--Abysshades留言) 2017年3月18日 (六) 04:34 (UTC)


如何正確上傳新聞圖片和屏幕製圖?

我知道在維基上,合理使用的媒體文件,是可以上傳的。

比如天津薊縣萊德商廈火災的圖片, File:天津薊縣萊德商廈火災.jpg

比如電視劇孽債的截圖, File:電視劇孽債_1995.jpg

比如周克華的通緝令照片, File:周克華.jpg


我在上傳50年以上前拍攝的照片時,添加一段 PD-China 代碼就可以成功上傳了,如 File:Nanyue Bible Institute.jpg

但我在上傳衡陽113火災的新聞照片時,嘗試模仿File:天津薊縣萊德商廈火災.jpg ,添加Non-free historic image 的代碼,預覽卻是不成功的,顯示「本媒體文件可能滿足快速刪除標準」。


所以我就嘗試先選最下方的那個"我想我合理使用了這個文件「選項,先上傳,文件為: File:Hengyang20031103fire.jpg


再嘗試按 File:天津薊縣萊德商廈火災.jpg的代碼改,結果沒有成功改了它的樣子,而是變為了「本媒體文件可能滿足快速刪除標準」。


所以我倒底應該怎麼上傳,才能成功上傳新聞圖片和屏幕截圖呢??以及這張 File:Hengyang20031103fire.jpg 又該怎麼改代碼呢?? 凡爾禮留言) 2017年3月18日 (六) 13:39 (UTC)

本分類的檔案禁止移動到維基共享資源

看圖。--Antigng留言) 2017年3月18日 (六) 14:04 (UTC)

所以我提議將我們上傳入口的C區入口調低些,新人完全不懂版權部分,什麼都往C區扔。C區只收兩種授權文件:一類非作品版權所有者但文件屬於公有領域的,一類是擁有作品版權所有且按照符合C區公共授權的。C區參見c:Commons:新手入門/許可協議的選擇c:Commons:Licensingc:Commons:Deletion policy。第一幅應該由於創作時間兼創作者已逝世超過50年,達到進入公有領域的條件,所以可以上傳C區,後者不是,所以只能在本地按照合理使用要求使用。——路過圍觀的Sakamotosan 2017年3月20日 (一) 04:40 (UTC)

回答@凡尔礼:的問題:上傳非自由版權圖片(「合理使用」圖片,例如屏幕截圖等等)請前往Wikipedia:上傳,在頁面的下半部分根據要上傳圖片的類型點選相應的鏈接,按要求完整填寫相關信息並上傳。另外,適用{{PD-China}}的圖片需在1996年已經進入公有領域才可上傳至共享資源,見{{Not-PD-US-URAA}}。--Wcam留言) 2017年3月20日 (一) 12:04 (UTC)

奧運會連結問題

{{GamesSport|Athletics|Format=d}}

我要將上文在任何一個奧林匹克代表團(例如:奧林匹克運動會卡塔爾代表團)都顯示為

Athletics田徑

有人願意幫忙嗎??

Simon 1996留言) 2017年3月18日 (六) 14:08 (UTC)

想新增頁面:中國金洋證券, 但WIKI卻說不行?

請求各位幫忙. —以上未加入日期時間的留言是於2017年3月20日 (一) 08:42 (UTC)之前加入的。

求救 不知如何貼上照片

--趙婷913留言) 2017年3月20日 (一) 03:24 (UTC)請問如何貼上照片 要審查嗎 謝謝

如果您想要使用的照片是您自己的作品且沒有在其他受版權保護的地方發表,那麼請到維基共享資源上傳,上傳後記下上傳後的文件名,直接在這裡使用即可。如果上傳的照片受版權保護,而您需要在條目中合理地使用照片(例如在麥當勞條目中使用麥當勞商標),請在中文維基百科任意頁面左邊的側欄中找到「上傳文件」,根據提示操作。建議您詳細閱讀Help:文件Wikipedia:文件使用方針後上傳照片。--Tiger留言DDL是第一生產力 2017年3月21日 (二) 22:00 (UTC)

新手編寫犯下錯誤,被提出存廢討論,請問如何解決。

本人在編寫超人X時犯下錯誤,現被提出存廢討論,請問如何解決問題。 本人原以暱名方式開設條目,卻沒留意條目標題,後誤以重新定向方法解決,因此被提出存廢討論。 現在可以以甚麼方法來繼續編寫條目呢? --Xurekat留言) 2017年3月20日 (一) 12:09 (UTC)

被提出存廢討論並不代表條目100%會被刪除。請前往相應的存廢討論頁面,詳細說明情況,並嘗試協商出解決辦法。--Wcam留言) 2017年3月20日 (一) 12:26 (UTC)

有關人物改名之後在內文中應當如何表述

RT,今天處理了一下兩個改了名字的快女的條目(楊洋楊菲洋紀敏佳紀丹迪),請問像這種情況應當如何敘述當事人的過往經歷?是一律用新名,還是改名前的經歷用舊名,改名之後再用新名?求解………--Dabao qian留言) 2017年3月21日 (二) 14:11 (UTC)

請幫忙協助編輯olympic/paralympic/體育 專題

這些都是翻譯不完整的 希望大家來翻譯

paralympic

olympic

綜合運動會

棒球

以色列棒球代表隊等多國代表隊

足球

沙盒

使用者:Simon 1996/沙盒1


我認為體育專題條目專注度且條目數都太少了!因此藉由不斷建立及擴充Olympics、Paralympics、Asian Games等等相關條目來提高對於體育賽事的專注程度。

不論是本人還是看到這個訊息的人,歡迎來編輯。希望可以在2018年冬季奧林匹克運動會前能夠完成所有的代表團的「總結」部分。

Simon 1996留言) 2017年3月21日 (二) 14:22 (UTC)

@Simon 1996:,根據您的貢獻,您應該在許多討論頁發了上述訊息,不是很贊成這様的作法。--Wolfch (留言) 圓周率協作中 2017年3月21日 (二) 14:57 (UTC)
我記得這也不是第一次他在互助客棧貼這個了,定期來這邊洗板--Liaon98 我是廢物 2017年3月21日 (二) 22:33 (UTC)

如何把自己的User:User/skin.css鏈接到自己用戶頁上?

我現在得把我自己用戶頁上每個類似div的style都複製一遍。。。好麻煩。請教如何導入User:燃燈/skin.css?我想用class一了百了。 --燃燈 談笑風生 微小貢獻 2017年3月22日 (三) 06:36 (UTC)

@燃灯:於Special:MyPage/common.js加入importStylesheet('User:燃灯/skin.css');--小躍撈出記錄) 2017年3月22日 (三) 07:13 (UTC)
@小躍:請問這麼做的話,最後是只有我一個人能看到css渲染後的效果,還是全站訪問我的用戶頁面的人都能看到?--燃燈 談笑風生 微小貢獻 2017年3月22日 (三) 07:22 (UTC)
剛剛試了一下,似乎是只能我自己看到。。。有沒有除了跪求改vector.css這種不能算辦法的辦法外的其他方式?抱歉打擾了 燃燈 談笑風生 微小貢獻 2017年3月22日 (三) 07:37 (UTC)

關於新條目推薦

近期未更新的條目早已符合新條目推薦獲選標準,但一直都沒有維基人提名,已五個月了還能提名嗎?中文維基百科助理編輯天蓬大元帥我愛維基 2017年3月22日 (三) 12:34 (UTC)

按照提名的標準來看,得足夠新吧……五個月,已經超過那個五天限制了,可以通過重大翻新來使其更「新」一些。 燃燈 談笑風生 微小貢獻 2017年3月22日 (三) 17:03 (UTC)

江蘇金壇區劃變更,需管理員批量更改Template:PRC admin模版庫

江蘇省金壇市15年1月部分鎮改街道、新設街道[27],4月市改區[28],區劃代碼變動較大。個人修正了少部分,發現工作量甚大,遂暫停。

希望管理員批量移動以下前綴開頭的子頁面(不含重定向頁):

  • 金壇市下轄鄉鎮變動:
    • 開發區改為東城街道:
      • Template:PRC admin/data/32/04/82/400/ -> Template:PRC admin/data/32/04/82/003
      • Template:PRC admin/list/32/04/82/400/ -> Template:PRC admin/list/32/04/82/003
    • 堯塘鎮改為堯塘街道:
      • Template:PRC admin/data/32/04/82/105/ -> Template:PRC admin/data/32/04/82/002
      • Template:PRC admin/list/32/04/82/105/ -> Template:PRC admin/list/32/04/82/002
    • 其他鄉鎮調整不適用批量移動,我可以手工完成。
  • 金壇市改金壇區
    • Template:PRC admin/data/32/04/82/ -> Template:PRC admin/data/32/04/13/
    • Template:PRC admin/list/32/04/82/ -> Template:PRC admin/list/32/04/13/

舊的代碼參考:[29], 新的代碼參考《中國鄉鎮行政區劃簡冊·2016》(001西城街,002堯塘街,003東城街)。劉振宇留言) 2017年3月22日 (三) 15:45 (UTC)

那個,關於編輯標籤……

今天在瀏覽某個被提刪的條目時,發現該條目是從草稿名字空間移動過來的(之前該頁面涉嫌侵權),然後我就順手把那個草稿的模板給刪了,然後再看編輯歷史,發現並未觸發「delete,模板被刪除」的標籤,然後我就作死在我的個人用戶沙盒掛上了一個{{D}}(該頁面本身並不符合CSD標準),準備看看移除此模板會不會觸發這兩個標籤,結果發現因為自己並非管理員,所以無法移除…… 囧rz...所以這兩個標籤到底會在什麼條件被觸發(難道說只在移除afd之類的時候),「模板被刪除」定義中的「新用戶移除模板」中的「新用戶」又指什麼?覺得編輯超過1000次的用戶應該已經不算新用戶了吧……很慚愧做了一個很naive的編輯…… 囧rz...--君の噓想い響き合うSymphony. 2017年3月23日 (四) 08:33 (UTC)

新用戶或頁面創建者。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 08:34 (UTC)
@WhitePhosphorus:好的,明白了,ありがとう…… 囧rz...--君の噓想い響き合うSymphony. 2017年3月23日 (四) 08:38 (UTC)
再補一句好了……警告您的過濾器代碼在Special:濫用過濾器/16。標籤的是Special:濫用過濾器/14,後者自動確認用戶都會觸發。 --碸中嘌呤的白磷萃取 打譜 2017年3月23日 (四) 08:41 (UTC)


條目探討

Kleetope中文譯名討論

根據文獻,Kleetopeen:Kleetope)是美國數學家Victor Klee[1]最先描述它們並命名為Kleetope[2]

Kleetope一詞是以該數學家的名字Victor Klee,加上多胞體字尾「-tope」
根據Google,Victor Klee數學家的中譯是維克多·克利查詢鏈結 鏈結本地截圖 (zh-tw = 維克多·克利),不知道翻成「克利多胞體」是否合適,想問社群意見。(Kleetope,Klee:克利,數學家名字、字尾「-tope」,多胞體)-- 宇帆普通留言·Flow留言·) 2017年2月21日 (二) 17:28 (UTC)

參考資料

  1. ^ Gritzmann, Peter; Sturmfels, Bernd. Victor L. Klee 1925–2007 (PDF). Notices of the American Mathematical Society (Providence, RI: American Mathematical Society). April 2008, 55 (4): 467–473. ISSN 0002-9920. 
  2. ^ Malkevitch, Joseph, People Making a Difference, American Mathematical Society .
我認為十分合適,但應該以(Kleetope)標識原名。鋼琴小子 留言 貢獻 2017年2月23日 (四) 18:20 (UTC)
但目前是沒有查到直接將Kleetope翻譯成克利多胞體或Kleehedron翻譯成克利多面體的中文文獻。不知道是否有違WP:可供查證的規定?-- 宇帆普通留言·Flow留言·) 2017年3月2日 (四) 10:59 (UTC)
(!)意見:目前是怕此舉會構成原創命名。-- 宇帆普通留言·Flow留言·) 2017年3月19日 (日) 09:24 (UTC)

占海特事件

關於荷蘭行政區劃條目

荷蘭的行政區劃條目太過老舊,荷蘭的行政區劃經常發生變化,已有的條目不去修正就馬上過時,比如布森,這個城市在2016年已經被合併進了Gooise Meren英語Gooise Meren。於是Template:North Holland Province這種模板就過時了,但無人修正,導致一直留着成了古董。比如該模板上面的安娜保羅娜、尼多普(Niedorp英語Niedorp)、維靈厄梅爾(Wieringermeer英語Wieringermeer)及維靈恩(Wieringen英語Wieringen)在2012年全都併入了新的Hollands Kroon英語Hollands Kroon,但模板上還留着。在下實在沒有那麼多精力去修正這些,就姑且先在這裡把這種情況說出來,待後來的編輯者參考修正。——ydcok留言) 2017年2月28日 (二) 08:40 (UTC)

其實所有行政區劃條目都有這個問題,尤其是不屬漢字文化圈的國家,更新十分緩慢。--owennson聊天室獎座櫃) 2017年3月1日 (三) 15:49 (UTC)
  • 各個國家的公共交通情況(如德國地鐵,經常臨時改線)也是這樣,在沒有參與編輯維基百科之前,一直覺得維基百科的東西肯定對,在發現這一問題後,想想最好還是看原語言(荷蘭文),不會就只能看英文了。。。--暖城2016-02-05留言) 2017年3月9日 (四) 19:34 (UTC)
漢字文化圈的行政區劃更新也不快啊,我說的是越南。--大南國史館從九品筆帖式留言) 2017年3月19日 (日) 23:23 (UTC)

建議改名:「Draft:音樂史」→「音樂史」

Draft:音樂史」 → 「音樂史」:從英語維基中重新翻譯--愚蠢的人類 2017年2月28日 (二) 19:05 (UTC)

草稿沒有改名問題,把內容搬過去後再刪除草稿即可。-KRF留言

管理員可以幫忙移動嗎?——愚蠢的人類 2017年3月1日 (三) 17:17 (UTC)

移動後再請管理員在原草稿重定向進行快速刪除即可。--4279計算過程 2017年3月11日 (六) 05:41 (UTC)

我一直很疑惑。。這種草稿移動到主名片空間留下來的重定向不屬於任何一個速刪標準。——꧁༺星耀晨曦༻꧂留言) 2017年3月11日 (六) 05:48 (UTC)
@星耀晨曦:如果用TW,直接自定義寫刪除理由就可以了;另外草稿頁面在英語維基百科中是「新條目專題」的常見頁面,可能可以把規定照抄一下。臺灣杉在此發言 (會客室) 2017年3月17日 (五) 03:44 (UTC)

氖燈、霓虹燈、霓虹招牌

建議改名:「王震緒」→「東山彰良」

希望以作家本人使用的筆名「東山彰良」作為名稱,個人認為是尊重作家。-Hierro 2017年3月3日 (五) 16:50 (UTC)

(+)同意您的觀點。-游蛇脫殼/克勞 2017年3月5日 (日) 04:55 (UTC)
(+)同意。作家條目以筆名命名、在條目內註明本名是非常常見的。Kou Dou 2017年3月5日 (日) 08:10 (UTC)
在此再次提出我的意見,1.常規沒有規定一定要使用筆名為名稱。既然沒有規定,就適用先到先得。有重定向,條目內也做了陳述,條目名稱不會影響到讀者檢索,花時間在改名討論,不如花時間在充實內容上。2. 作家本人沒有提出希望別人用筆名稱呼他的意見,編輯不用幫他做主張,我們也可以說,使用其本名是尊重其本人,其父母,及其家族。3. 條目中來源主要都是使用他的本名,以常用性來說,筆名並沒有比他的本名更常用,條目應該尊重來源。--Alfredo ougaowen留言) 2017年3月8日 (三) 15:55 (UTC)
我有疑問:取了筆名又不希望別人用筆名稱呼他,那取筆名幹嘛?他不希望他的筆名能在文壇發光發熱嗎?-游蛇脫殼/克勞 2017年3月8日 (三) 16:18 (UTC)
(:)回應用推測來決定條目怎麼寫,為原創研究或原創總結。他父母為他取了名字,我們也可以合理推測他父母希望別人用他的名字稱呼他。每個人有不同的想法,編輯的工作不是代替條目主人決定這件事,而是匯整可靠來源。條目原來名稱已經符合常規,就不用去改他,還需要耗費時間在討論條目名稱而不是增強條目實質內容,是很無益的事。--Alfredo ougaowen留言) 2017年3月17日 (五) 03:29 (UTC)

超越肉類公司名稱問題

我個人認為此名詞有生硬翻譯之嫌。暫未找到官方中文譯名,根據這些文章和其他類似報道,使用直接「Beyond Meat公司」沒有問題。故建議改用「Beyond Meat公司」作為標題。再者,「肉類」表述亦不準確,至少應改為「肉品」,以表達「肉類製品」之意。--Tiger留言整日Py日漸消瘦 2017年3月4日 (六) 02:33 (UTC)

既然是中文維基百科儘量要用中文,關於「肉類」還是「肉品」我找到了一個例子:超特肉類公司。肉品公司也可以找到一些例子,個人覺得都可以。個人支持用「超越肉類/肉品公司」來命名。--暖城2016-02-05留言) 2017年3月5日 (日) 08:54 (UTC)
儘量使用中文沒錯,但也要證明該名稱在中文圈內有普遍性,否則只是為了中文而中文。我上面舉出的例子正是證明了用英文原名在中文使用者中有先例,說明中文認知中對該公司的名稱是「beyond meat公司」,而非「超越肉品」。如果沒有人用「超越肉品」,僅僅為了中文而使用它,並無意義。
當然,如果能找出支持當前標題的可靠來源,當然不必更改標題。--Tiger留言整日Py日漸消瘦 2017年3月6日 (一) 01:17 (UTC)
在中文圈內有普遍性的前提是有一定知名度,如果只是一家小公司,談在中文圈內有普遍性是沒有意義的。儘量使用中文的一點考慮就是很多華人根本不會英文,把「beyond meat公司」他們連讀都讀不出來。。。就如上面說的小公司能找到來源來證明「這個中文名不合適」幾乎是不可能的,既然有「超特肉類公司」這樣的類似例子,不已經可以很好證明這樣的中文名是沒有什麼不合適嗎?維基百科也是支持原創譯名的,在沒有其他資料可以參考的情況下。--暖城2016-02-05留言) 2017年3月6日 (一) 08:13 (UTC)
原來維基支持原創譯名,在朝廷的統治下維基又跨出了一大步-Neville Wang 奈威 2017年3月6日 (一) 08:21 (UTC)
@Neville Wang: 很遺憾,討論的話請好好說話,這樣陰陽怪氣維基百科不歡迎你。--暖城2016-02-05留言) 2017年3月6日 (一) 08:23 (UTC)
@Neville Wang: 你去看看相關的方針再來說我以上說的有沒有錯。--暖城2016-02-05留言) 2017年3月6日 (一) 08:23 (UTC)
要是沒有陛下在,恐怕維基早已身敗名裂,恩威浩蕩,名揚四海。-Neville Wang 奈威 2017年3月6日 (一) 08:31 (UTC)
@Neville Wang: 呵呵,你既然叫我陛下,我命你面壁思過,改過自新,還不快快退下。。。別影響這裡的討論,整個被你弄得烏煙瘴氣的。--暖城2016-02-05留言) 2017年3月6日 (一) 08:36 (UTC)
確實,有一些譯名是原創的。——꧁༺星耀晨曦༻꧂留言|2017年監管員選舉) 2017年3月6日 (一) 09:27 (UTC)
@星耀晨曦: 原創譯名在維基是允許的,值得商榷的是怎麼樣翻譯更好。--暖城2016-02-05留言) 2017年3月6日 (一) 09:58 (UTC)
如果必須遵循命名常規中「使用中文」的要求,而又在中文社會沒有該事物的中文名稱的話,那只能是編者自己自行翻譯事物名。舉個我自己的例子,避難所 (波特·魯濱遜歌曲)當時翻譯時是沒有中文名的,就叫「Shelter」,我查詞典時還查到這個還能理解為「庇護」,而且從動畫MV的意思來看這個也合適,當時我完全可以用後者來噁心一下。——路過圍觀的Sakamotosan 2017年3月6日 (一) 09:39 (UTC)
@cwek: 支持!特別是一些比較小的/新的概念時,可能根本沒有對應中文,總需要有這麼第一個人來翻譯譯名,如果之後有更為合適的譯名(如官方譯名)再更改也不遲。比如德國的Aldi超市,之前條目名稱是阿爾迪超市,這也是德國華人使用最多的譯名,前不久因為進駐中國市場的關係,有了官方譯名,本人就及時將其更新至奧樂齊超市。--暖城2016-02-05留言) 2017年3月6日 (一) 09:56 (UTC)
(不能再歪樓了,但是我還是要歪一下):Move-to-front_transform也打算翻譯一下嗎?要是翻譯成「移動到前面轉換」我可不同意。--Tiger留言被識破不開心 2017年3月7日 (二) 06:58 (UTC)
「前置轉換」?譯不好的話請盡情笑吧。所以翻譯也是一個學問啊。——路過圍觀的Sakamotosan 2017年3月7日 (二) 07:05 (UTC)
「置前轉換」XD。-Neville Wang 奈威 2017年3月7日 (二) 14:07 (UTC)
好像也不錯,信達雅如何?——路過圍觀的Sakamotosan 2017年3月8日 (三) 00:50 (UTC)
少了文雅度,但大致上沒什麼問題。-Neville Wang 奈威 2017年3月8日 (三) 17:49 (UTC)
拋開其它問題,「超越肉類公司」可以收入維基百科:維基誌異 囧rz...——꧁༺星耀晨曦༻꧂留言|2017年監管員選舉) 2017年3月7日 (二) 16:08 (UTC)
  • 忽然想到了如果叫肉製品公司怎麼樣。。。純個人建議。。。--暖城2016-02-05留言) 2017年3月9日 (四) 19:30 (UTC)
Dear all, 感謝大家如此熱烈討論譯文,其實作為翻譯人我也覺得翻成「超越肉類公司」比較生硬,不過基於維基百科編輯原則,參考第二手資料的重要性,因此我目前查到網路上比較可靠的第二手資料,大多是翻成「超越肉類」ex. http://bw.businessweekly.com.tw/press/content.php?id=23936 (商業週刊);http://www.ettoday.net/news/20140307/332084.htm?feature=taiwanfood&tab_id=35 (東森新聞雲);http://www.chinatimes.com/newspapers/20160117000276-260209 (中時電子報)等,所以才會取用此翻譯名,以上供參考,謝謝。Plumablue 2017年3月16日 (四) 01:55 (UTC)
支持「超越肉類公司」,無論咋樣該用中文譯名。--暖城2016-02-05留言) 2017年3月18日 (六) 20:21 (UTC)
  • 這個議題已於3月初新竹社群聚會討論過,由於「超越肉類公司」這個譯名已被主流媒體報導過,應已取得編輯之審核過程,所以即使這個名稱可能不盡理想,仍須依照此可靠來源進行命名。臺灣杉在此發言 (會客室) 2017年3月16日 (四) 15:06 (UTC)

浮士德的微笑是哪裡有浮士德在微笑?

電視播放浮士德的微笑,請問該劇是哪裡與浮士德有關的,為什麼會取上「浮士德」的微笑,而不選擇取其他人名字做為的微笑?比如說:也可以叫雷芯語的微笑,因為劇中發展是緊扣女主角為軸心的。--1.170.209.224留言) 2017年3月6日 (一) 17:03 (UTC)

浮士德是用來借代出賣靈魂的人,看了下劇情簡介,應該是指策劃復仇的男主角,而不是指女主角。 --KRF留言) 2017年3月7日 (二) 01:50 (UTC)
看完了這部片,在下覺得他想要表達的應該是即使面臨困難與窘境,仍依然保持冷靜的淡淡微笑來想盡辦法解決一切的問題。--小躍撈出記錄) 2017年3月14日 (二) 03:52 (UTC)

基性火成岩 vs. 鹼性火成岩

程啟光條目遭嚴重破壞

請求恢復至3月1日的版本,並處理有關IP。[30] 謝謝!--Review-Renew留言) 2017年3月9日 (四) 21:04 (UTC)

由管理員AT回退。--小躍撈出記錄) 2017年3月14日 (二) 03:48 (UTC)

有關環北站的編輯爭議

背景

  • 2017年3月5日:在下重寫環北站條目,並於車站結構章節依管理單位的可靠來源標示第一月台為「往中壢方向」的月台。
  • 2017年3月6日07時05分:Happy60907閣下以「現時1號月台上面印的是往機場」為理由,將第一月台改為「往台北方向」
  • 2017年3月6日07時15分:在下回退Happy60907閣下的編輯,並根據方針向該閣下說明「請閣下附上可靠來源,目前的資訊來自桃園捷運公司官方網站的介紹。」
  • 2017年3月6日07時54分:Happy60907閣下以「我是親自到現場看的!請勿再次回退,否則將視為破壞行為!」為理由回退在下的編輯。在下恪守3RR方針,未再回退該筆回退。
  • 2017年3月6日07時54分:在下於討論頁向該位閣下說明回退理由,並警告「恣意刪除可靠來源內容的行為可能構成破壞」。
  • 2017年3月6日10時26分:該位閣下首度回應,聲稱自己已於現場確認,並提出一支不可靠的個人出版物為佐證,指出官方的來源不一定可靠。
  • 2017年3月6日10時41分:在下首度回應,敦促該閣下依據可靠來源可供查證等方針,提出可靠來源佐證其更動。
  • 2017年3月6日11時28分:該閣下辯稱它是「實際事物之呈現」不是「原創研究」,因此可將個人出版物認定為可靠來源進行引用。
  • 2017年3月6日11時39分:在下以可供查證駁斥「實際事物之呈現」也無法令個人出版物作為可靠來源
  • 2017年3月6日11時54分:該閣下聲稱已透過擔任桃園捷運公司公關的朋友確認桃園捷運公司所說的「往中壢方向」並非現在的營運模式,並要求讀者及在下自行打電話給桃園捷運公司確認。
  • 2017年3月6日12時24分:在下澄清並不是不認同現行並非「往中壢方向」的事實,並依據方針堅持該閣下提出可靠來源。
  • 2017年3月10日10時59分:由於等候多日仍未見該閣下補充來源,在下再次提醒「閣下依然未於頁面上提供可靠來源」。
  • 2017年3月10日14時28分:該閣下辯稱已提出一支個人出版物並打電話作為來源,並聲稱即使尚無法引用,也不代表內容錯誤,更指出維基百科不要求內容一定帶有來源
  • 2017年3月10日14時32分:在下說明「閣下既然移除了擁有可靠來源的內容,就需要也必須提供來源來佐證閣下修改後的內容。」
  • 2017年3月10日14時41分:該位閣下聲稱已經有管道(也就是打電話問任職桃園捷運公司公關的友人)證實在下所引用的來源是錯誤、不可靠的,並說他「當然且必須將錯誤的內容修改為正確的內容。」
  • 2017年3月10日15時53分:在下向該位閣下請求確認「將桃園捷運公司列為不可靠來源」,因為若確認桃園捷運公司為不可靠來源,在下需要將維基百科大量有關桃園捷運的內容重寫。於此同時,在下也強調,既然「無法舉出任何來源」那就等同原創研究
  • 2017年3月10日17時21分:該閣下解釋桃園捷運公司的來源因「官方文獻資料並不一定完全可靠,可能因其時空背景、筆誤等因素造成資料錯誤或不合時宜」而在此個案上變為不可靠來源。除此之外,該位閣下也持續辯解先前提出的個人出版物及打電話詢問就可證明其非原創研究,並要在下「承認錯誤」、「無須找這麼多理由來為自己開脫」,還要求在下及讀者自行查證。值得一提的是,該位閣下試圖人肉搜索嚴重騷擾在下,此行為已獲得管理員的嚴正警告(相當感謝管理員@Wong128hk本於制止騷擾維護方針的立場相助)。
  • 2017年3月10日17時34分:在下重申維基百科不可能要求讀者「讀者自行打電話或是到現場查證」,更不可能在來源寫「由Jack.T打電話確認了該月台的行車方向」。此外,在下也試圖以「自行透過不可靠的自行出版物研究、自行實地研究」來說明該位閣下確實屬原創研究,並持續要求該閣下在移除有可靠來源的內容後,其修改後的內容應具備可靠來源。

完整內容

依照維基百科方針,內容應附上可靠來源,閣下在環北站的編輯並未附上可靠來源,請閣下提出可靠來源,否則閣下恣意刪除可靠來源內容的行為可能構成破壞—以上未簽名的留言是由Aotfs2013對話 貢獻)於2017年3月6日 (一) 09:54 (UTC)加入。

@Aotfs2013:由於本人已親自於站體看過,但沒有於當下拍攝照片,因此特地幫閣下到Youtube搜尋影片,請從2分6秒開始觀看至2分21秒,並請注意月台上的文字,兩側月台皆為往機場及台北方向(因現時環北至中壢段尚未通車),因此依照WP:FUTURE第二點「即使已經有可以證實的資料,有系統地產生的未發生事項並不適合百科全書記載。」;另,閣下於編輯「車站結構」段落時,似乎極大或完全地依賴於某個單一的來源,並聲稱其為「可靠來源」似乎有失公允,官方文獻資料並不一定完全「可靠」,可能因其時空背景、筆誤等因素造成資料錯誤或不合時宜,並不能以此否定其他編者所做出沒有附註來源的貢獻(例如我就是親眼所見),建議閣下於未來編輯時能更尊重其他編者的編輯,多善用溝通管道而非直接回退,最後提醒您依據WP:SIGN,於他人留言版上留言時,請記得加上您的簽名,感謝您祝編安!-Jack.T 2017年3月6日 (一) 10:26 (UTC)

  1. 桃園捷運公司並未說明該圖係以模擬未來營運模式的方式繪製,且桃園捷運公司對於未來營運模式的標示方式與此顯然有極大差異(請參見對高鐵桃園站第一月台的標示方法);
  2. 閣下所提出的個人出版物應無法滿足維基百科對於可靠來源的要求;
  3. 「似乎極大或完全地依賴於某個單一的來源」與該來源是否為可靠來源並不相關;
  4. 「可能因其時空背景、筆誤等因素造成資料錯誤或不合時宜」部分,歡迎閣下提出可靠來源加以編修;
  5. 「建議閣下於未來編輯時能更尊重其他編者的編輯,多善用溝通管道而非直接回退」部分,對於可靠內容被未有可靠來源的內容覆蓋,回退並無不妥。

執行編輯 Aotfs2013 留於 2017年3月6日 (一) 10:41 (UTC)

@Aotfs2013
  1. 高鐵桃園站並沒有第一月台,不曉得您是在哪裡看到的?
  2. 針對桃園捷運站體內實景係針對既有「實際事物之呈現」而非「原創研究」,因此即便是個人出版之著作仍可作為可靠來源供考。
  3. 「極大或完全地依賴於某個單一的來源」的意思是有可能將其來源之「時空背景、筆誤等因素造成資料錯誤或不合時宜」部分誤用,此情形即是一例。
  4. 同上述第二點
  5. 來源網址皆已附給您參考,第二點亦說明其係「實際事物之呈現」,至於您個人認定此來源「可靠性不足」敝人認為實屬不公允,如閣下仍有疑慮,建議您可將此案例提交至互助客棧尋求廣大維基編者的意見,看看此案例是否可謂「可靠來源」。

Jack.T 2017年3月6日 (一) 11:28 (UTC)

  1. 請閣下仔細查看網頁中的「車站資訊圖」;
  2. 個人出版物僅可在特定情況下作為來源,請見WP:V,「實際事物之呈現」顯然不是被允許使用的特定情況;
  3. 請閣下提出桃園捷運公司說明該圖係詮釋未來營運模式及該圖因「時空背景、筆誤等因素造成資料錯誤或不合時宜」的可靠來源;
  4. 維基百科的內容建立在方針與指引之上,而如第二點所說明,維基百科並未允許個人出版物在「實際事物之呈現」的狀況下作為可靠來源。

執行編輯 Aotfs2013 留於 2017年3月6日 (一) 11:39 (UTC)

@Aotfs2013
  1. 為幫閣下釋疑,已親自致電向桃園捷運公司官方客服專線及我認識的桃捷公關張先生,確認該圖係屬未來(環北-中壢段)通車後使用,因此,A21車站立體圖不屬於現行規劃,請勿再擅自引用。如您有疑慮亦可親自致電桃園捷運客服中心+886 3 2868789。-Jack.T 2017年3月6日 (一) 11:54 (UTC)
根據現況及善意推定,在下認知閣下說的確為事實。然而,就算閣下已以電話確認,仍應提出可引用的可靠來源進行修編,維基百科不能在來源要求讀者「自行打電話確認」。- 執行編輯 Aotfs2013 留於 2017年3月6日 (一) 12:42 (UTC)
閣下依然未於頁面上提供可靠來源。- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 12:59 (UTC)
@Aotfs2013:已經告訴閣下您引用的來源是錯的,也已提出相關佐證及其他管道證實,現時雖無法從「網際網路」尋找到適合的來源作為連結引用之用途,但亦不代表頁面上的內容有錯誤,更何況維基百科並沒有強迫所有內容皆需加入「來源」,不曉得閣下這麼急迫於「加入來源」的用意為何?-Jack.T 2017年3月10日 (五) 14:28 (UTC)
閣下既然移除了擁有可靠來源的內容,就需要也必須提供來源來佐證閣下修改後的內容。- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 14:32 (UTC)
已經有管道證實您的來源是錯誤的當然就不可靠,請不要再強調閣下的來源是可靠的!(這是大前提)
閣下既然引用不可靠來源(錯誤的來源),我當然必須將錯誤的內容修改為正確的內容。-Jack.T 2017年3月10日 (五) 14:41 (UTC)
確認一下,閣下現在是提議將桃園捷運公司列為不可靠來源嗎?- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 15:53 (UTC)
閣下現在的行為,等於原創研究,因為閣下並無法舉出任何來源證明閣下的說法是正確的-即使它的確如此。- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 16:00 (UTC)
  1. 如上所述「官方文獻資料並不一定完全可靠,可能因其時空背景、筆誤等因素造成資料錯誤或不合時宜」,僅針對該個案因其「錯誤」而產生「不可靠」之情形。
  2. 早已將相關佐證及經官方客服/公關管道之證實結果回復予閣下,閣下亦表達「根據現況及善意推定,在下認知閣下說的確為事實。」,何來原創研究之說?本人不接受閣下事後亂扣別人帽子;承認自己錯誤不難,無須找這麼多理由來為自己開脫。建議XXX先生如有任何疑慮,可親自發函或致電予桃園大眾捷運股份有限公司,如以上方式皆不方便,亦可使用旅客信箱將閣下的疑慮及問題反映給官方,由官方以書面方式回覆給閣下,絕對會比現在兩造繼續爭論來的有意義多。-Jack.T 2017年3月10日 (五) 17:21 (UTC)
  1. 閣下難道想叫查閱的讀者自行打電話或是到現場查證?或是,閣下想在來源處寫說「由Happy60907打電話確認了該月台的行車方向?」。此外,閣下並無提出任何來源,僅是自行透過不可靠的自行出版物研究、自行實地研究,當然是原創研究。
  2. 閣下不知道刻意提一位「XXX」先生是有何居心?該位人士是誰?閣下難道試圖「人肉搜索」在下?令人感到恐懼及被騷擾
  3. 閣下是更動具備由管理單位桃園捷運公司提出的可靠來源佐證的內容的編輯,閣下自然有義務舉證,而非請讀者自行查證。- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 17:34 (UTC)

討論

說明:由於爭論遲遲無法結束,在下不得不請社群介入,對於消耗社群資源的部分在下深感抱歉。此外,這邊除邀請資深管理員@和平奮鬥救地球協助排解歧見外,也歡迎所有編輯閣下的參與,謝謝!- 執行編輯 Aotfs2013 留於 2017年3月10日 (五) 18:52 (UTC)

有必要將全部內容都轉載於此嗎?為何不直接給出連結就好,豈不是可讓討論版面看起來更簡潔?進入正題,我拆二點來說:
  • 這只是很單純的編輯糾紛,簡單地說就是User:Happy60907堅持採用Youtube影片做為來源,至於打電話詢問或發函查證都不是重點,剩下就是看User:Happy60907有沒有觸犯3RR遊戲維基破壞,只有這些才算是嚴重情節,需要由管理員直接封禁。但就目前來看,情況也不至於如此。此外,話說「維基百科並沒有強迫所有內容皆需加入來源」不知從何而來,這就要問User:Happy60907是引用哪套方針指引?
  • 原創研究只是主觀上,這可以請求來源就能解決的,那麼就要回歸到討論「User:Happy60907採用Youtube影片做為來源」可不可行的問題了。若結果可行,問題便解決;反之,若不可行,除了要移除Youtube影片的連結,還要對質疑的內文(原創研究?)提出{{fact}}來源請求。
我想對User:Aotfs2013說些忠告:說起來,這種事並不難解決,維基像社會縮影,來來去去編輯的什麼人都有,總會有人對維基不熟悉,若遇到的人是不想去瞭解並適應維基,這樣的人也遲早會被社群給推出維基門外,所以不用太對不理性的人去費時間、費心力,畢竟這一切有管理員看在眼裡的。--36.233.252.137留言) 2017年3月10日 (五) 20:02 (UTC)
  • 首先,對於「人肉搜索」這樣的指控以及嚴重騷擾,我必須做些說明,閣下的名字的資訊連結到現在都還留存在維基,而且連結還是閣下自己加上去的,我想閣下大概是老了還是記性不佳?不然難不成我有天大本事知道閣下叫XXX?雖然我在維基不少年了,各種編輯者來來去去也看了不少,自認大致方針也都略有接觸,但如今的確對WP:騷擾一節不夠了解,一時不小心將真實姓名PO在維基百科,並非有意違反方針,其本意並非「惡意騷擾」,而是「善意溝通」,也很感謝管理員即時依據方針做出適當處置及警告,以後必將不再發生此類情事。
  • 其次,閣下表示「User:Happy60907堅持採用Youtube影片做為來源,至於打電話詢問或發函查證都不是重點」這樣未免有些含血噴人?只挑好聽的為自己辯護?是因為經閣下說明Youtube影片為「個人出版品」,深知閣下懷疑其「可性度」,才自費尋求官方管道客服中心及我認識在其單位任職公共事務管理師(公關)進行近一步確認,怎麼會不是重點?且以上內容因本人深知直接引用在條目內可能會有不適合的問題,故一直沒有直接將其引用於條目,而是針對閣下的疑慮僅於討論頁做溝通說明之用,怎麼會有「堅持採用Youtube影片做為來源」一說?我連條目都沒有更新加入Youtube來源,閣下這樣說個人深表不以為然。另,「剩下就是看User:Happy60907有沒有觸犯3RR遊戲維基破壞」我加入維基多年還不至於會犯到如此等級的錯誤,不知閣下刻意提及此的居心何在?然而,「維基百科並沒有強迫所有內容皆需加入來源」這閣下在維基編輯那麼久難道都不清楚?況且我並非刻意不引用來源,而是現時「網際網路」上的確沒有適合的來源可供引用,得待日後有可供引用之來源時再補上。
  • 既然閣下已說明原創研究只是主觀上,那何來信誓旦旦的在我討論頁說「當然是原創研究」?最終還是交給社群討論「採用Youtube影片做為來源」可不可行?因當初Aotfs2013非常堅持使用「個人出版」之「Youtube影片做為來源」屬於「原創研究」,是不能引用在維基百科的,所以本人時隔至今仍一直未將本來源引用於條目,因此本人才建議Aotfs2013可尋求社群討論。
  • 最後,我已用盡各種管道提醒Aotfs2013其聲稱的「可靠來源」內容有「錯誤」,故不能稱其引用為「可靠來源」,但閣下卻不斷跳針其編輯為「桃園捷運公司提出的可靠來源佐證的內容的編輯」;以上說明之意思並非指「桃園捷運公司」的來源全然不可靠,而是明確指出「桃園捷運公司」有錯誤的來源不可靠,因此我所移除的編輯是有錯誤的不可靠來源,絕非像閣下所指「恣意刪除可靠來源內容」,望請社群給予公評。

Jack.T 2017年3月11日 (六) 01:03 (UTC)

說起來,我認為無需要為「消耗社群資源」而抱歉,二人糾紛之下無法解決也會不必要地消耗二人的精力和時間,如果社群介入討論可以解決問題,這是很合符經濟的做法。同時,所有維基人也是社群的一員,因此二人的糾紛所消耗的同樣是社群資源。
簡單一看,我理解爭論重點是一者認為「他認為現有已有來源的內容是錯誤的,而且對他的理解也提供了可以考證的方法」,另一者認為「前者所提供的考證方法不屬於可靠來源,所以不接受它是一個有效的真確性證明,而只能歸納為原創研究」。
我想Happy60907閣下需要理解的是,在維基百科不會因為一件事是正確,或者有很多人知道/相信就會放入條目,除非有可靠來源(及滿足方針的其他要求),尤其是閣下提出的內容和已有來源的內容有衝突,以及已有其他編者作出懷疑的時候更加如此。就如之前在客棧有編者的留言說,即使某事件有10億人類知道,如果沒有可靠來源也不應寫在維基百科上。請注意,各位並不是不相信閣下親眼所見及提供之佐證,而是這些理由在維基百科的系統下不太適合。閣下可能認為這種情況不合常理,但這些情況就是維基百科的特性,它既限制了維基百科,同時也塑造了維基百科。希望閣下能夠對所在的環境作出理解。——愚蠢的人類 2017年3月11日 (六) 01:22 (UTC)
基本上我並不反對任何編輯者針對我的編輯標註「來源請求」,因為目前的確沒有適合的來源可供引用;我無法接受的是Aotfs2013不斷將錯誤的不可靠來源回退至現有條目,並不斷宣稱其引用為「可靠來源」,即使已被證實為錯誤。很感謝User:愚蠢的人類給的肺腑之言,正如您所說,由於目前能找到的來源不太適合放入條目之中,所以我也一直沒有將我所提供之來源更新於條目,僅作為討論頁做溝通說明之用,但本人為此事件已發正式公文函請桃園捷運公司回復,有待日後正式公文回復後,將會使用公文掃描檔上傳至維基共享資源作為適合條目的引用。-Jack.T 2017年3月11日 (六) 02:07 (UTC)
維基百科:可供查證#可供查證不等同正確」有云:「來自於可靠來源的內容亦可能有誤,而若該內容能被其他可靠來源證明為錯誤,則亦有可能被刪除。」--Kolyma留言) 2017年3月11日 (六) 03:55 (UTC)
這段影片的2:08畫面很清楚顯示環北站第1月台標示「往機場 往臺北」,看起來不像是偽造,而且想不出有任何理由需要偽造,應足以證明官網公告內容的確與現況不符。台北捷運部分轉乘站(例如古亭站、中正紀念堂站)的各月台行車路線/方向曾經換過多次以因應不同時期的通車狀態,看起來該站未來也會是轉乘站,官網所載可能是未來的方案吧!--Kolyma留言) 2017年3月11日 (六) 04:09 (UTC)
Happy60907閣下若然理解現時已有的來源不適合更新題目,是否可再退一步,接受未有可靠來源之前不應該刪除現有已有來源的內容?我相信重點仍然在於「知道是正確」並不等於「可以套用於維基百科」,則可靠來源只能在有可靠來源下才能推翻,這除了更改現有內容外,也應該包括刪除現有內容。希望明察。——愚蠢的人類 2017年3月11日 (六) 05:32 (UTC)
為何要接受「已經證明是錯誤」的內容?--Kolyma留言) 2017年3月11日 (六) 06:05 (UTC)
閣下這個提問,正正在我上面的兩個回覆已經清楚解釋,所以閣下的提問令我很疑惑,閣下是不明白我所說的理據嗎?可否說明是什麼部份不清楚?——愚蠢的人類 2017年3月11日 (六) 08:10 (UTC)
@Kolyma:依據方針,要證明是錯誤需由其他可靠來源來證明,即使事實並非如此,仍應提出可靠來源來加以證實先前的內容是錯誤的,並以可靠來源佐證所更新上的內容,而這也是在下持續要求該位閣下提出可靠來源的原因。- 執行編輯 Aotfs2013 留於 2017年3月11日 (六) 08:08 (UTC)
不理解為何要堅持保留「真實世界」已經證明是錯誤的內容,卻不接受Happy60907君在正確內容上掛「來源請求」模板的提議?這樣做對維基百科跟廣大讀者究竟有何好處?如果只有方針才能打動你們,那麼期望你們考量WP:IGNORE:「如果有規則妨礙你恰當地改進或維護維基百科,請忽略該規則。」--Kolyma留言) 2017年3月11日 (六) 19:34 (UTC)
官方網站和實際情況有衝突?這種情況很少見,不過可以以中立語言把兩種觀點都寫進去,建議把實際情況放在前面,官方資料放在後面補充。——꧁༺星耀晨曦༻꧂留言) 2017年3月11日 (六) 05:30 (UTC)
官方網站資料錯誤的例子太多太多了,沒啥稀奇。--Kolyma留言) 2017年3月11日 (六) 06:19 (UTC)
寫上兩個觀點十分不妥,因為該位閣下所提出的內容並沒有任何可靠來源可以驗證,也沒有任何可靠來源可以證實先前在下所編輯的內容是錯誤的-維基百科的內容建築在可靠來源之上。- 執行編輯 Aotfs2013 留於 2017年3月11日 (六) 08:10 (UTC)
維基百科:來源/YouTube。——꧁༺星耀晨曦༻꧂留言) 2017年3月11日 (六) 08:33 (UTC)
@星耀晨曦:除了論述低於方針與指引(關於個人出版物)外,這篇論述也提到「不知名的用戶或單位在YouTube平台釋出的影片都是不可靠來源」,而該位閣下所提出的YouTube影片,就是由「不知名的用戶或單位」所釋出的。不論根據方針與指引或該篇論述,該位閣下提出的來源皆不可靠。- 執行編輯 Aotfs2013 留於 2017年3月11日 (六) 08:37 (UTC)
@Antigng:--71.188.98.67留言
不理解為何要排斥「真實世界」已經證明是正確的內容,也不接受Happy60907君在其上掛「來源請求」模板的提議?不理解堅持保留「真實世界」已經證明是錯誤的內容對維基百科跟廣大讀者究竟有何好處?如果只有方針才能令您動心,那麼請考量WP:IGNORE:「如果有規則妨礙你恰當地改進或維護維基百科,請忽略該規則。」--Kolyma留言) 2017年3月12日 (日) 06:15 (UTC)
以我來看,「真實世界」和「維基百科世界」是兩個不同的世界。就如不同的民族或者行業有不同的文化及價值觀一樣。比如說,一個宗教組織的在進行決定時,「我們來忽視來這個宗教信仰的理念,再做這個決定吧」,這樣令人很難想象。閣下所說的在「真實世界」的確是有去除錯誤、便利之好處,這個我是理解的。然而如果要把想法套用在維基百科,就需要維基百科的角度、理念來考慮是不是有好處。
WP:IGNORE的背後有一個含意:感到維基的規則有不充份之處、或者不合理之處,以致成為發展的礙障。而我對這個的看法就如之前的回答一樣:現在這個「暫時沒有可靠來源的話,引致結果顯示的只有錯誤的內容」的情況,就是維基百科的本質,這就是它的一部份。硬幣有兩面,只是我們現時看到的是黑暗的一面而已。從這樣的角度來看,我沒有感到這個情況是「不合理」。
我儘可能把想法說出來,是對事不對人的。我理解閣下提到的WP:IGNORE方針的意思,有點像法律上的酌情權,我不是認為不可以用,只是謹慎一點會比較好。歡迎閣下再繼續討論。——愚蠢的人類 2017年3月12日 (日) 14:18 (UTC)
我倒覺得WP:IGNORE正是鼓勵大家不要視此為宿命。--Kolyma留言) 2017年3月12日 (日) 16:02 (UTC)
還記得剛加入維基百科的時候,最被首頁這句「海納百川,有容乃大」給深深吸引,從加入維基百科以來,不敢說自己有多少貢獻,但也花在維基不少時間,發生這次事件讓我感到很是失望,或許大家都是希望讓維基更好而投入於此,卻沒想到希望讓維基更好的善意編輯卻因「方針」而被侷限,甚至遭受Aotfs2013明知故問的質疑!很感謝Kolyma管理員對於本次事件的關注及說明,或許一直以來我也沒想過會有離開維基百科的一天,不論本次討論結果如何,本人將尊重社群的討論結果,有勞各位!再會了-Jack.T 2017年3月14日 (二) 11:17 (UTC)
What a pity! ——꧁༺星耀晨曦༻꧂留言) 2017年3月14日 (二) 12:08 (UTC)
Well, 我認為還可以討論下去的。我的態度還是開放的,我上面的論述很大程度是善意地表達「我眼中現時對方針的主流看法及它的解釋」。但是關於WP:IGNORE什麽時候應該用,對這酌情權可以怎樣理解,我自己還不清楚。如果其他編者能多作解釋的話,我很願意跟隨社群的共識。但是如果各位看到我有錯誤卻不參與討論和解釋的話,我或許就會一直誤會社群的看法了。我亦對討論不是很熱烈而感到可惜。——愚蠢的人類

環北站目前為終點站

剛才注意到環北站目前為終點站,兩個月台都標示「往機場 往臺北」是合理的,這個討論應該可以結束了。Kolyma留言) 2017年3月12日 (日) 08:34 (UTC)

中壢站是未來的終點站--小躍撈出記錄) 2017年3月14日 (二) 03:46 (UTC)

「本名」是否含有「原名」、「舊名」的意思?

A·洛朗的條目名稱改為全名

如題。一名英文使用者在guestbook提出改名,考慮到命名常規中的「使用全稱」,幫助其到這裡提出移動請求,希望移動到「Joseph Jean Pierre Laurent」對應的中文譯名(如果有的話)。 --碸中嘌呤的白磷萃取 打譜 2017年3月12日 (日) 08:10 (UTC)

我已將名字翻譯成「約瑟夫·讓·皮埃爾·洛朗」,條目也已移動過去。原先的「A.」是天文記錄中對無命者(Anonymous)的記法。鋼琴小子 留言 貢獻 2017年3月12日 (日) 14:46 (UTC)
A·洛朗難道要A掉洛朗嗎?這完全不符合邏輯,名稱太懶散又短也不行。--小躍撈出記錄) 2017年3月14日 (二) 03:44 (UTC)

梁振英條目「對梁振英的辱罵用詞」章節

梁振英條目中,有一個章節單獨介紹「對梁振英的辱罵用詞」。這種寫法是否符合維基百科規範?Wpcpey未給出理由就回退了我的編輯,為了避免編輯戰,到這裡來討論。--地球81留言) 2017年3月13日 (一) 14:04 (UTC)

始終這些辱罵用詞在香港的不少媒體都有使用過 梁振英不角逐連任 香港民眾歡慶推「689」優惠活動 六合彩和賽馬「洩天機」 預視梁振英難連任 DSE考生不知梁振英叫「689」的由來,不應該刪除。--Wpcpey留言) 2017年3月13日 (一) 14:36 (UTC)

689隻算是別稱,尚未到辱罵程度。這類內容最重要是有多方來源,不能僅引用單方面的媒體報道。另外,蔡英文條目也「有被稱「空心蔡」與「Wonky」」章節,對於這類內容是否保留應有統一標準,而不是以主題人物的政治傾向和政治主張而定。--Thomas.Lu留言) 2017年3月13日 (一) 15:37 (UTC)
說明蔡英文條目「被稱「空心蔡」與「Wonky」的章節是放在「軼聞」章節下。沒見過哪個人物條目,把「對xxx的辱罵用詞」寫成一級標題的。--地球81留言) 2017年3月13日 (一) 16:16 (UTC)
他們還真是有想像力哈哈哈!--小躍撈出記錄) 2017年3月14日 (二) 03:41 (UTC)

有關印第安納步行者的回退

因為我在印第安納步行者看到俄克拉何马雷霆(大陸簡體)和俄克拉何馬城雷霆(俄克拉何马城雷霆,頁面的名稱)不一樣,所以我做了編輯和使用俄克拉何马雷霆取代奧克拉荷馬雷霆。稍後我的編輯被還原。我試著與另一個編輯理解為什麼,他提到了我的編輯是繁簡破壞行為。我們在對方的留言頁面上聊了幾天,但沒有協定。所以我真的想要第三方來幫助解決這個問題。

此外,我還有其他問題

  1. 我個人相信何不直接用目標條目的標題轉換去轉換超連結?的觀點「除非前後文的特殊需要,否則目標條目的標題手工轉換應該會是最準確的,如此也不會有條目名稱一改(如重新定向),所有指向該條目的超連結都須修改的問題」是一個很好的做法,你覺得怎麼樣?
  2. 我怎麼可能讓俄克拉何马城雷霆(大陸簡體)顯示在印第安納步行者頁面上,與此同時不違反繁簡破壞?
  3. 我使用頁面的名稱(俄克拉何马城雷霆)取代奧克拉荷馬雷霆是違反繁簡破壞?

為了避免編輯戰,到這裏來討論。謝謝您的幫助。--Winston留言) 2017年3月14日 (二) 02:59 (UTC)

noteTA轉換組中已經有相應的轉換(在模塊:CGroup/NBA中),一般情況下可以保持源碼。——路過圍觀的Sakamotosan 2017年3月14日 (二) 04:24 (UTC)
是的,但轉換組翻譯奧克拉荷馬雷霆成俄克拉何马雷霆(不是俄克拉何马城雷霆)。俄克拉何马城雷霆是頁面的名稱。--Winston留言) 2017年3月14日 (二) 04:41 (UTC)
轉換組的規則沒寫全。修正了一下。——路過圍觀的Sakamotosan 2017年3月14日 (二) 04:44 (UTC)
謝謝,試過但不能轉換奧克拉荷馬雷霆成俄克拉何马城雷霆 --Winston留言) 2017年3月14日 (二) 04:57 (UTC)

:::啊!!!!!你怎麼把全名轉簡稱的改了?——路過圍觀的Sakamotosan 2017年3月14日 (二) 05:12 (UTC)

I might mess up the stuff. I created a 沙盒 for you to test. --Winston留言) 2017年3月14日 (二) 05:17 (UTC)
先對好mapper做調整吧。——路過圍觀的Sakamotosan 2017年3月14日 (二) 05:24 (UTC)
轉換相應部分是用於全稱轉簡稱,或者全稱或簡稱地區互轉,所以只有俄市->俄/奧,奧城->俄/奧,俄市<->奧城,俄<->奧。所以不會有簡稱轉全稱吧。 ——路過圍觀的Sakamotosan 2017年3月14日 (二) 05:46 (UTC)

::: Maybe you can ignore 奧克拉荷馬市雷霆 as I really can find any reference --Winston留言) 2017年3月14日 (二) 06:10 (UTC) ::: Seems the rules are so complex to maintain/manage --Winston留言) 2017年3月14日 (二) 11:42 (UTC)

I am not sure but this information may help you.
  1. zh-hk:奧克拉荷馬雷霆 奧克拉荷馬雷霆
  2. zh-hans:Official name is 俄克拉何马城雷霆
  3. zh-tw: Official name is 奧克拉荷馬城雷霆 奧克拉荷馬城雷霆

--Winston留言) 2017年3月14日 (二) 12:15 (UTC)

大概明白了,待會重新mapper下。BTW,你之前是不是用翻譯器來寫中文的,為什麼突然用英文了?——路過圍觀的Sakamotosan 2017年3月15日 (三) 00:57 (UTC)
Yes you are right I use Google Translate. But as most of the people prefer chinese so I need to ask help using chinese. It really take me hours to finish my question. --Winston留言) 2017年3月15日 (三) 02:46 (UTC)
After checking my own 沙盒, i guess the translation problem is between zh-hant and zh-tw. --Winston留言) 2017年3月15日 (三) 02:50 (UTC)

Thanks for help fixing the template. I still want to know the answer for the following question

  1. 我個人相信何不直接用目標條目的標題轉換去轉換超連結?的觀點「除非前後文的特殊需要,否則目標條目的標題手工轉換應該會是最準確的,如此也不會有條目名稱一改(如重新定向),所有指向該條目的超連結都須修改的問題」是一個很好的做法,你覺得怎麼樣?
  2. 我怎麼可能讓俄克拉何马城雷霆(大陸簡體)顯示在印第安納步行者頁面上,與此同時不違反繁簡破壞?
  3. 我使用頁面的名稱(俄克拉何马城雷霆)取代奧克拉荷馬雷霆是違反繁簡破壞?

--Winston留言) 2017年3月15日 (三) 05:19 (UTC)

分開幾個問題解答吧。一般情況下如果原文用了其中一個地區的用詞,直接替換非意義更改的話,算是繁簡替換,是不允許的。其次,頁面命名來源於WP:命名常規的,一般這類繁簡用詞的話,如果常用,名從等都不適用的,一般選頁面創建時間優先,而「俄克拉何馬城雷霆」沒特別的命名爭議問題,也是最早的命名,所以一般用這個,而其他地區用名以重定向方式鏈入即可。——路過圍觀的Sakamotosan 2017年3月17日 (五) 07:08 (UTC)
謝謝, 但現在仍然不能成功翻譯一切。 奧克拉荷馬城雷霆(zh-tw)->俄克拉何马雷霆(zh-hans)。俄克拉何马城雷霆是理想的翻譯。感謝檢查--Winston留言) 2017年3月17日 (五) 23:22 (UTC)

建議鳳飛飛條目「歌唱特色」一節改名

在下建議鳳飛飛條目「歌唱特色」一節改名,改成「臺灣國語唱腔」或其他適合的名稱,因為我個人認為臺灣國語不是鳳飛飛的「特色」。

如果鳳飛飛都嫌不夠字正腔圓,那麼龍飄飄於櫻櫻、蔡咪咪、吳秀珠、楊小萍、張素綾又該怎麼算呢?這些臺灣歌手是如何能在1970年代的臺灣國語歌壇存在呢?1970年代幾乎每位臺灣歌手都把ㄅㄥ、ㄆㄥ、ㄇㄥ、ㄈㄥ(beng、peng、meng、feng)念成ㄅㄨㄥ、ㄆㄨㄥ、ㄇㄨㄥ、ㄈㄨㄥ(bong、pong、mong、fong)(直到現在還是),還有誰是真正字正腔圓的呢?

所以臺灣國語不是鳳飛飛的特色,各位意見如何?-游蛇脫殼/克勞 2017年3月14日 (二) 11:38 (UTC)

互動百科被央視315晚會曝光了

建議模板:着色異常改名

template:着色異常改為template:變色效應。(註:英語為 template: chromism)--Leiem留言) 2017年3月15日 (三) 14:45 (UTC)

兩個條目標題需要翻譯

光と影を抱きしめたままら·ら·ば·い_~優しく抱かせて,請懂日語的來翻譯一下。--Tiger留言DDL是第一生產力 2017年3月15日 (三) 22:50 (UTC)

(~)補充舞風りら。--Tiger留言DDL是第一生產力 2017年3月16日 (四) 11:04 (UTC)

  • 第一個:懷抱著光與影(「抱きしめたまま」也意指後面要做些什麼,這裡刻意不做翻譯。)
  • 第二個:搖籃曲~溫暖的抱擁(ららばい是搖籃曲的意思,但是這中間加的點由於我不清楚語境不好翻譯;)
  • 第三個:舞風 りら(藝名,如果方針允許的話不必做修正)。--Innocentius Aiolos 2017年3月16日 (四) 19:02 (UTC)
  • 另:咱不是不應該原創譯名嘛。--Innocentius Aiolos 2017年3月16日 (四) 19:03 (UTC)

Clip Studio Paint & ComicStudio

英文那邊有en:Clip Studio Paint,在維基數據上鏈接到中文和日文的ComicStudioja:ComicStudio,然後最近有人創建了Clip Studio Paint,我已經凌亂了。--Tiger留言DDL是第一生產力 2017年3月15日 (三) 22:50 (UTC)

根據en:Clip Studio Paint所說,Clip Studio Paint 在日本稱作ComicStudio,在北美稱作Manga Studio。——꧁༺星耀晨曦༻꧂留言) 2017年3月17日 (五) 07:10 (UTC)

「維根超市」命名重新定向為「Veganz」

維根對應的英文是VEGAN,而VEGAN是純素生活概念或純素者的意思。維根超市這個名字不能代表一家公司的名稱,就像是純素超市不是一家公司名的意思一樣。之前我是翻成「維根茲」主要是取音譯,因為該公司在中文參考文獻沒有對應的官方譯名,如果維根茲大家覺得不恰當,那我建議直接留下原德文名稱Veganz。台灣也有一家愛維根超市(http://www.iveganmart.com/) ,所以如果在搜尋引擎搜尋維根超市,會出現愛維根超市,很可能會誤導查詢者,因為這兩家超市是不同單位。請有權限的維基編輯人幫忙重新定向維根超市的條目名為Veganz,謝謝。Plumablue留言)2017年3月16日 (四) 02:09 (UTC)

補充說明:這個問題在3月初的新竹聚會上討論過,原來的「維根超市」譯名來源僅僅來自於部落格的原創翻譯,顯然並非可靠來源。臺灣杉在此發言 (會客室) 2017年3月16日 (四) 07:21 (UTC)
  • 反對直接使用德文的Veganz,因為這是中文維基,儘量使用中文比較好。個人覺得用搜索引擎搜索出來的結果出現愛維根的確可能是一種誤導,根據維基的方針,沒有官方譯名編者可以使用自己的原創譯名,所以個人覺得應該在「維根」和「維根茲」裡面選一個。--暖城2016-02-05留言) 2017年3月16日 (四) 09:16 (UTC)
    • 嗯,如果依照@暖城2016-02-05的論述,再加上「維根」這個名詞的來源也不太可靠,那是否同意@Plumablue的論述,將之改名為接近德語發音的「維根茲」?請各位討論以取得共識。臺灣杉在此發言 (會客室) 2017年3月16日 (四) 15:01 (UTC)
目前幾個選擇看來,維根茲應該是較適合的譯名,如果未來Veganz有官方的中文名稱的話可再正名。Lightening Snow 2017年3月16日 (四) 15:29 (UTC)
@Saisahi:致閣下,閣下的簽名中,必須有鏈向閣下用戶頁或者用戶討論頁或者用戶貢獻的鏈接。——꧁༺星耀晨曦༻꧂留言) 2017年3月16日 (四) 15:18 (UTC)

請關注於中華人民共和國條目發生的編輯爭議

--114.34.111.131留言) 2017年3月16日 (四) 03:19 (UTC)

確實有編輯爭議,不過不是在中華人民共和國,而是在Special:用戶退出。剛才我去檢查了一下頁面,發現頁面已被管理員全保護,估計接下來大家會冷靜下來討論的。--逆襲的天邪鬼留言) 2017年3月16日 (四) 03:20 (UTC)(備註:Special:Diff/43631296

模板cite news及cite web的accessdate該怎麼填?以及accessdate可否代替date?

以下移動自User talk:Ketsu1213

模板cite news及cite web的accessdate該怎麼填?以及accessdate可否代替date?@Ketsu1213:及各位維基人的看法是如何呢?-游蛇脫殼/克勞 2017年3月17日 (五) 06:07 (UTC)

按照英文維基百科的說法。date參數用來指明參考來源的出版日期,若出版日期不確定,則可以使用accessdate來代替。而accessdate參數用來指明,當初在加入參考來源的時候訪問原始參考來源的url時的日期。——꧁༺星耀晨曦༻꧂留言) 2017年3月17日 (五) 07:07 (UTC)
那麼如果出版日期確定,卻不填date,而填accessdate,而且填入的accessdate還不是出版日期呢?是否不恰當?-游蛇脫殼/克勞 2017年3月17日 (五) 08:16 (UTC)
如果加入參考來源的那天是該參考來源的出版日期,那麼沒毛病。如果不是的話,就改成date參數。——꧁༺星耀晨曦༻꧂留言) 2017年3月17日 (五) 08:43 (UTC)
那麼@Ketsu1213:君的編輯是錯誤的嗎?-游蛇脫殼/克勞 2017年3月18日 (六) 06:20 (UTC)

中華愛國同心會

這個頁面包含太多次連續而分散在條目各處的破壞,我完全找不到破壞的開頭在哪裡,請求協助 囧rz...—以上有簽名的留言由R96340對話)加入。 2017年3月17日 (五) 07:39 (UTC)

那就整條重寫一遍,而不是回退破壞吧。 --KRF留言) 2017年3月17日 (五) 14:33 (UTC)

好的orz—以上有簽名的留言由R96340對話)加入。 2017年3月17日 (五) 15:01 (UTC)

奧運會連結問題

{{GamesSport|Athletics|Format=d}}

我要將上文在任何一個奧林匹克代表團(例如:奧林匹克運動會卡塔爾代表團)都顯示為

Athletics田徑

有人願意幫忙嗎??

Simon 1996留言) 2017年3月17日 (五) 12:42 (UTC)

散騎侍郎

散騎侍郎應該能重定向到某個條目吧?我查不到什麼資料。--淺藍雪 2017年3月17日 (五) 15:43 (UTC)

請幫忙協助編輯olympic/paralympic/體育 專題

這些都是翻譯不完整的 希望大家來翻譯

paralympic

olympic

綜合運動會

棒球

以色列棒球代表隊等多國代表隊

足球

沙盒

使用者:Simon 1996/沙盒1


不論是本人還是看到這個訊息的人,歡迎來編輯。希望在2018年冬季奧林匹克運動會前能夠完成所有的代表團的「總結」部分。 Simon 1996留言) 2017年3月18日 (六) 04:31 (UTC)

我要求的並不只是評級而已,是要求徹底的編輯。Simon 1996留言) 2017年3月18日 (六) 08:56 (UTC)

中華民國勞動基準法的迴圈

中華民國勞動基準法重定向到勞動基準法,而後者是一個消歧義頁,其中一個歧義是中華民國勞動基準法,造成了迴圈,而且如此一來,中華民國勞動基準法根本沒有有意義的內容。

請問這該怎麼辦?-游蛇脫殼/克勞 2017年3月18日 (六) 14:12 (UTC)

已解決

--KRF留言) 2017年3月18日 (六) 14:14 (UTC)

關於在條目說明「韓國欠缺了高空末端防衛裝備」

請問,韓國部署薩德反導彈系統事件中「韓國目前主要反導武器是部署PAC-3型「愛國者」導彈系統和KM-SAM中距離反導系統,應付大規模彈道導彈襲擊時欠缺了高空末端防衛裝備」是屬於鴨子 一望而知,可以直接這樣寫在條目上;還是一個爭議?——愚蠢的人類 2017年3月19日 (日) 11:03 (UTC)

食譜的定義

義大利煎蛋主編Howard61313之意見,似乎是溫度算是食譜,他寫的「至少5分鐘起跳,通常則需耗時15分鐘」就是「必要信息」了。既然知道維基百科不是食譜,5分鐘起調用得着寫嗎?況且是何等溫度下都沒有說?--淺藍雪 2017年3月20日 (一) 11:27 (UTC)

  • (:)回應:用不用得著寫是一回事,重點是條目寫了這個東西,或是沒說什麼溫度之下,都不會使得這條目不符合DYK,投個什麼反對票。——Howard61313留言) 2017年3月22日 (三) 10:07 (UTC)
    • 私以為這是個因人而異的問題,而且我那個一開始並沒有加反對票模板。設若無人水票,反對票這麼招人恨的活我也早就不幹了。。--淺藍雪 2017年3月22日 (三) 10:41 (UTC)

臺灣競爭力論壇

該條目17/1/1被使用者@Aa1388zz:一次大量刪光,但過於大量刪除,建議使用者可否說明編輯的理由:移除長期無來源、非百科、破壞及錯誤內容。該單位最著名的事蹟就是2014年市長選舉期間使用不當方法的民調及特定立場的發言幫助特定候選人,內文都有不同單位的來源,所以我不解您的編輯理由。Zenk0113留言) 2017年3月21日 (二) 00:36 (UTC)

  • (:)回應:@Zenk0113:首先長期無來源且負面的內容得移除無問題,次維基百科不是資料庫故移除民調數據,再維基百科不是論壇故移除評論,最後明顯的錯誤或破壞如將此社團法人寫成政治團體亦以刪減改正。如編輯有誤還望協助更正。--東東留言 2017年3月22日 (三) 02:08 (UTC)
就算你覺得那是"負面內容",那也只是格式不對修改寫法即可!且相關內容都有不同來源佐正,為何連來源都刪掉?所以您指的長期無來源是指那段內容需要連來源都刪光光?至於爭議事件的重點是問法不是民調數據,刪掉民調數據也無訪。另外,至於他是社團法人或政府社團根本沒差,WIKI也沒規定這兩個種組織如何撰寫,更何況該團體的確在該事件上有重大爭議,那又如何明顯錯誤或破壞之說值得用刪掉來處理? Zenk0113留言) 2017年3月22日 (三) 02:35 (UTC)

請關注「我是歌手」相關條目

IP用戶最近創建我是歌手(第五季),標題格式錯誤。而我是歌手 (第五季)重定向至歌手2017,後者文內寫着「《歌手》2017原本是《我是歌手》第五季」。--Tiger留言DDL是第一生產力 2017年3月21日 (二) 13:59 (UTC)

要不要限制一下{{藝人}}系列模版「暱稱」、「綽號」參數的使用

巡查RC的時候,經常能看到新用戶們在藝人條目的這兩個參數上充分發揮他們的創造力。注意到在信息框中加來源的人十分鮮見,嚴格來說隨意添加暱稱和綽號可能會構成生者傳記方針中提到的「無來源或少來源的爭議內容」。這些搜索結果是zhwp的所有條目中,「暱稱」或「綽號」參數中超過兩項的條目。可以看到,其中有很多值得商榷。林振強中的「傻強」,算無來源的負面內容吧?何炅中的「遊戲王、老大」,綽號可能不需要唯一性,但這種實在是太平凡了,說不定某些學校每個寢室都有一個「老大」;「搜證王」,Google了一下,這似乎是單一事件中產生的綽號,真的有必要收入百科全書嗎?柯受良中的「亞洲第一飛人」,有違中立了吧?薛之謙中的「我薛、我謙」,這是愛好者網頁嗎?以上例子是想說明,這類參數很容易被不明真相的萌新加入不適當的內容;考慮到這類參數的百科性不高,我認為廢除都不為過,不廢除也得規範一下什麼樣的暱稱可以加入。 --碸中嘌呤的白磷萃取 打譜 2017年3月22日 (三) 03:37 (UTC)

  • (!)意見:早就有規範,須為經常出現在新聞媒體上的暱稱或綽號方可加入。所以參數本身並沒有問題,問題出在使用者身上。--Dabao qian留言) 2017年3月22日 (三) 09:23 (UTC)
  • 在有可靠來源的情況下,加入這個參數沒有問題。問題是使用參數的編者並不留意這一點。新建藝人條目的確實新手居多,除了「暱稱」,還會加進「三圍」、「體重」之類不存在的參數。還有沒弄清模板使用方法,不完整地複製粘貼其他條目源碼導致的錯誤。--Tiger留言DDL是第一生產力 2017年3月22日 (三) 12:36 (UTC)
    • (:)回應user:Tigerzeng[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]的確,使用這個模板的大多數都是IP用戶,而且很多都不會去看模板文檔,而是直接從既有條目複製現有模板再清空模板內容後使用,所以才會造成這樣或者那樣的問題。關鍵是這個模板早就加入了檢測未知參數的功能,如果有編者往裡面加入不存在的參數的話,在預覽時會出現紅字提示的。IP用戶和新用戶在保存編輯之前都是要強制預覽的,可是他們根本就不會去留意那些紅字。對於這個問題,一是要多點人手去清理那幾個追蹤分類,使得既有條目中不再含有不受支持的參數。二是下大力氣推廣可視化編輯器,藝人模板現已全面支持可視化編輯器,用它生成出來的模板不會出現這些問題。--Dabao qian留言) 2017年3月22日 (三) 12:58 (UTC)
  • 對參數暫時沒什麼意見,但柯受良中寫亞洲第一飛人是沒有違反中立的,很多來源都可以支持。--KRF留言) 2017年3月22日 (三) 13:47 (UTC)

新聞動態出錯了

標準石油的創辦人不是逝世的大衛·洛克菲勒,而是他爺爺約翰D洛克菲勒。管理員請修改一下 —以上未加入日期時間的留言是於2017年3月22日 (三) 16:42 (UTC)之前加入的。

請問該如何處理類似宋皇后 (嘉隆帝)這種姓氏+「皇后」+丈夫名號的重定向

維基百科有很多類似的重定向條目,是否應該把她們添加進對應的消歧義條目張皇后李皇后宋皇后裏,然後刪去對應的消歧義條目呢?或者是否應該為其他皇后條目創建此類重定向呢?比如為越南末代皇后阮有氏蘭創建阮皇后 (保大帝)阮有皇后 (保大帝),為輔天純皇后阮有氏嫻創建阮皇后 (同慶帝)阮有皇后 (同慶帝),為丁、前黎兩朝皇后楊雲娥非別創建楊皇后 (丁部領)楊皇后 (黎桓)。--大南國史館從九品筆帖式留言) 2017年3月22日 (三) 14:41 (UTC)

其他

將管理員的名字改為覆核員如何?

顯然管理這個字令人對管理員產生高人一等的印象。雖然權限上來說絕對是這樣的

理想化的管理員的工作實際上是透過參考方針、指引、共識,對一個決定(無論這個決定是個人的還是社群的)以客觀的角度進行覆核並付諸執行,所以也許改為覆核員也不錯的感覺。

順便還可以寫些覆核並非只有覆核員才能做,只是只有覆核員才能執行等等這類的東西,讓管理員更顯親民什麼的XD

只是問問--—歡迎參觀關注度不足博物館。以上有簽名的留言由R96340對話)加入。 2017年2月25日 (六) 17:21 (UTC)

早期有操作員的說法,因為sysop。—菲菇維基食用菌協會 2017年2月25日 (六) 17:24 (UTC)
testwiki:Special:ListGroupRights#reviewer。-- Stang 103 2017年2月25日 (六) 17:28 (UTC)
只要新人沒「先入為主」的念頭,就不會產生維基百科的管理員和其它地方的管理員是差不多的錯覺。——꧁༺星耀晨曦༻꧂留言|2017年監管員選舉) 2017年2月25日 (六) 18:56 (UTC)
  • 不如叫「資深用戶」吧。--persona non grata 2017年2月27日 (一) 02:53 (UTC)
  • 這個「管理」只是系統層面的管理,而非社群或者組織的管理。——路過圍觀的Sakamotosan 2017年2月27日 (一) 09:13 (UTC)
  • 我認為重要的是群眾對於現時維基管理員產生的印象是什麼。權力不對等不是問題,權力不對等的矛盾才是問題(不論是否有明確的制度,權力不對等總會在社會自然產生)。看到閣下使用的刪除線,我猜閣下感受到管理員和一般用戶的相處不是很和陸。請不要高估管理員稱呼的改變帶來的幫助,因為權力矛盾的存在和掌權者的稱呼沒有關系。管理員一字出於英文的Administrator,而「管理」一字給人擁有權威的印象,我建議改名為「行政員」、「事務員」、「常務員」、「理事員」等中性、概括、僅描述工作性質的用字。——愚蠢的人類 2017年2月27日 (一) 12:47 (UTC)

維基百科已有其他權限叫行政員+4179計算過程 2017年2月27日 (一) 13:43 (UTC)

  • (+)贊成,「管理」一字給人擁有權威的印象--葉又嘉留言) 2017年2月27日 (一) 14:20 (UTC)
  • 好奇,這個問題真的單純靠改名就可以解決麼?--J.Wong 2017年2月27日 (一) 15:17 (UTC)
    • 就像「官員」改稱「幹部」。--Mewaqua留言) 2017年2月28日 (二) 02:09 (UTC)
  • 若真的這麼做,我認為算是一個實驗的好機會,對結果有一個明確的推測,但事實有可能相異的實驗才是最有趣的實驗。如果管理員不再被稱作管理員,會發生什麼事情?並非期待會有什麼改變,而是看看會發生什麼事情—這才是實驗的真諦。--—歡迎參觀關注度不足博物館。以上有簽名的留言由R96340對話)加入。 2017年2月27日 (一) 15:27 (UTC)
  • 於是這樣一來濫權管理員就變成了濫權事務員了,這真是幫了大忙。:D Bluedeck 2017年2月27日 (一) 23:32 (UTC)
  • Template:清潔工--逆襲的天邪鬼留言) 2017年2月28日 (二) 10:57 (UTC)
  • 名字改叫:「朝鮮勞動黨」了,所以就是勞動而不是統治百姓了?galaxyharrylion留言) 2017年2月28日 (二) 11:38 (UTC)
  • (-)反對:在下認為沒必要。--Dqwyy談笑風生正在沉迷CLANNAD回復請ping 2017年2月28日 (二) 15:55 (UTC)
  • 對改名本身沒看法,但我估計真的改了成本會很大,有一大堆顯示文字要改,而且不能完全交給bot。 --碸中嘌呤的白磷萃取 打譜 2017年3月1日 (三) 03:22 (UTC)
  • (+)贊成,建議改名為「事務員」--​Vinct_1998留言)(叮噹呀,誰都喜歡,小貓也自豪!) 2017年3月10日 (五) 09:11 (UTC)
  • (-)反對改名,簡單明瞭,難道還要改成「史蒂芬」嗎?--小躍撈出記錄) 2017年3月15日 (三) 01:29 (UTC)

無意見。形象問題。--61.224.18.54留言) 2017年3月16日 (四) 12:56 (UTC)

  • (+)贊成,改名是第一步,不能因為這一步不能立即起效而連這一步都不邁出,在十分飢餓的情況下,第一口飯絕對不會讓你吃飽,但難道這就是不吃飯的理由?——平頭哥留言) 2017年3月21日 (二) 13:46 (UTC)

指引:如何迅速衝高編輯次數

正在發神經胡搞起草一篇偽指引:快速衝高編輯次數,不過寫到一半發現自己沒什麼幽默感... 放在這裡集思廣益 --KRF留言) 2017年3月4日 (六) 13:58 (UTC)

想要建設性的呢,還是破壞性的呢?--逆襲的天邪鬼留言) 2017年3月4日 (六) 15:13 (UTC)
是建設性的囉 --KRF留言) 2017年3月4日 (六) 15:20 (UTC)
可以先給自己設計個漂亮的用戶頁,然後找一些自動化或半自動化工具啊,例如巡查最近變更調整頁面分類修復列表格式不正確的導航模板英文日期格式修正參考文獻格式修正導航模板修正重定向處理消歧義什麼的。老手還可以去騙取AWB使用權。不懂編程的話用工具,如果懂編程的話還可以造工具啊,光是DEBUG就可以多刷很多編輯次數了。要是還沒玩夠的話,可以再找些成體系的條目,例如世界有兩百多個國家和地區,每個條目都編輯一兩下……在enwp很容易就能刷到延伸確認的哦。明明是破壞才好玩嘛,而且使用工具協助破壞既好玩又能迅速刷編輯次數哦。--逆襲的天邪鬼留言) 2017年3月4日 (六) 15:44 (UTC)
我想某位為了越南與台灣的自由民主而長期奮鬥的人看到之後肯定醍醐灌頂——他的目標都是永久半保護的。--逆襲的天邪鬼留言) 2017年3月4日 (六) 15:50 (UTC)
建設性地刷編輯次數(大霧,逃--Tiger留言整日Py日漸消瘦 2017年3月5日 (日) 03:12 (UTC)
(:)回應:我覺得用機器刷就不有趣啦 --KRF留言) 2017年3月5日 (日) 10:04 (UTC)
每一筆編輯我都有過目並最後按下enter才完成的哦。(搞不好還得人工返工一點也不輕鬆,如果閒得無聊幹這個也不錯--Tiger留言整日Py日漸消瘦 2017年3月5日 (日) 11:46 (UTC)
Category:引文格式1錯誤:日期,一共34,627個頁面,大多數機器人都修不來,因為太亂了。人去修的話不僅要仔細判斷,有些可能還要查查資料,實乃消磨光陰之利器。 --碸中嘌呤的白磷萃取 打譜 2017年3月5日 (日) 10:31 (UTC)
我發現似乎以前有特定機器人會加入錯誤的日期格式,例如這個[31] 考慮用其他機器人自動檢查這種錯誤?pinchuanc留言) 2017年3月5日 (日) 12:35 (UTC)
您說的這種比較簡單的修復已經有機器人在跑了:Liangent-bot。 --碸中嘌呤的白磷萃取 打譜 2017年3月7日 (二) 07:18 (UTC)
更新足球運動員傳記中的各項數據、資料,出場次數、進球次數每賽季都得更新(也可以每個月、每輪比賽、每天更新),遇上轉會還得改效力俱樂部和球衣號碼。實在閒的話可以把各種聯賽當前賽季的頁面寫好,每輪(或者每場比賽之後)更新積分榜、射手榜、賽果等等。一年之後編輯次數輕鬆上萬--如沐西風留言) 2017年3月7日 (二) 07:28 (UTC)
刷刷刷!!!用些有意義的身心健康編輯。像是改錯字、改病句。--小躍撈出記錄) 2017年3月15日 (三) 09:02 (UTC)

非自由版權圖片大小過大的自動過濾無需設立

不是說他沒侵犯版權,而是現在有2個bot在運作:一個負責指出圖片過大的問題,一個通過技術手段直接修復。既然可以自動修復,就無需設立這種過濾,因為即使觸犯也會馬上糾正。{{tl}}運行時可能條目已經存在,並沒有設立自動過濾器,只確保自動修復。這裡適合效仿,實施也有助於更多圖片並進一步到影響條目。-- 晴空·和岩 ✎留言板 2017年3月5日 (日) 11:19 (UTC)

看不出明顯的害處。--Temp3600留言) 2017年3月5日 (日) 11:47 (UTC)
反正只是標記而已,又有什麼樣的關係呢?--小躍撈出記錄) 2017年3月5日 (日) 11:50 (UTC)
既然Bot能自動修,而且上傳過大圖片不會馬上就有人找維基百科打官司,那麼影響操作的警告確實就有些多餘了。--逆襲的天邪鬼留言) 2017年3月5日 (日) 12:07 (UTC)
不要把希望全都寄託於bot--百無一用是書生 () 2017年3月7日 (二) 03:46 (UTC)
我個人建議是,至少別弄得像個警告一樣-- 晴空·和岩 ✎留言板 2017年3月7日 (二) 15:02 (UTC)
目前用的不是warning,而是notice--百無一用是書生 () 2017年3月8日 (三) 08:18 (UTC)
我只是覺得有點像而已-- 晴空·和岩 ✎留言板·渥太華歷史的編寫 2017年3月17日 (五) 10:57 (UTC)

要不要新增帳戶密保問題

我們不如開發一個bot自動掛「本條目需要補充更多來源」和「來源請求」的模板吧

反正有的人職業掛模板,挺辛苦的,弄個bot代勞也不錯[開玩笑的]-- 晴空·和岩 ✎留言板 2017年3月11日 (六) 12:31 (UTC)

WP:POINT。--Antigng留言) 2017年3月11日 (六) 12:31 (UTC)
感覺這機器人很難做出來啊。——꧁༺星耀晨曦༻꧂留言) 2017年3月11日 (六) 13:09 (UTC)
自動UNREFERENCED--Temp3600留言) 2017年3月11日 (六) 14:43 (UTC)
沒意義。unreferenced是給人看,讓人改善的。所有都掛和所有都沒掛效果沒什麼差別。--Antigng留言) 2017年3月11日 (六) 14:44 (UTC)
不過有些人確實寧可掛五個模板也不肯解決其中任何一個問題(比如加個分類)。--E8×E8353) 2017年3月11日 (六) 21:13 (UTC)
分類應該很好解決。機器人掛,然後從任務列表中完成就好了。--Leiem留言) 2017年3月12日 (日) 02:07 (UTC)
「寧可掛模板不肯解決問題」,可能是因為自己無法解決。比如難以決定加入哪個分類,來源查找困難。--Tiger留言內存清理 2017年3月12日 (日) 03:03 (UTC)
認同。-Neville Wang 奈威 2017年3月12日 (日) 03:59 (UTC)
認同+1。--Jerre Jiang  討論參與清理積壓站務  2017年3月14日 (二) 00:55 (UTC)
掛模板比較容易,解決問題往往得耗費心力。--Kolyma留言) 2017年3月12日 (日) 05:56 (UTC)
希望大家勇於解決問題,並避免只掛模板而不想解決問題。--Kolyma留言) 2017年3月12日 (日) 06:01 (UTC)
同意耗費心力。我想一些有經驗的編輯可能存在不想替人收拾殘局的心理。--Zhxy 519留言) 2017年3月13日 (一) 16:56 (UTC)
沒意義,倒不如幫忙搜尋合理的來源並加入條目中來解決問題,這是我們的責任。--小躍撈出記錄) 2017年3月14日 (二) 23:12 (UTC)
可否簡述有關的判斷邏輯?——愚蠢的人類 2017年3月19日 (日) 13:29 (UTC)
我的看法,只要有心,就可以寫一個完美的條目,掛版是要提醒主編者哪裡需要改善。-Neville Wang 奈威 2017年3月22日 (三) 07:17 (UTC)
其實不是主編也可以修。。。-- 晴空·和岩 ✎留言板·渥太華歷史的編寫 2017年3月22日 (三) 10:12 (UTC)
如果條目跟我所知有相關的話,我會去修改,如果不是,我就不動了。-Neville Wang 奈威 2017年3月22日 (三) 10:15 (UTC)
修條目是刷編輯數比較快的方法(大霧——꧁༺星耀晨曦༻꧂留言) 2017年3月22日 (三) 10:22 (UTC)

提議更改「上傳檔案」頁面的排版

備註:之前已經有不少用戶提出將其排版更改或加入警告標示等,詳見Wikipedia_talk:上傳
目前的排版非常容易令新手誤將版權圖片上傳到共享區,故提議重新排版或製作響導精靈來引導新手將圖片上傳至正確位置。就Wikipedia_talk:上傳所記錄,先前已有4個關於此問題的提議,但卻一直沒有人實行或再討論。建議仿照Wikipedia:建立條目精靈來修改介面。-- 源  環  2017年3月12日 (日) 10:45 (UTC)

我比較傾向改成維基共享的上傳精靈。——꧁༺星耀晨曦༻꧂留言) 2017年3月12日 (日) 12:18 (UTC)
+1--Jerre Jiang  討論參與清理積壓站務  2017年3月14日 (二) 00:57 (UTC)
無論何者,都需要管理員幫助更改。。。-- 源  環  2017年3月14日 (二) 13:37 (UTC)
可以先做一個草稿頁面出來,徵求大家意見。--Wcam留言) 2017年3月14日 (二) 18:34 (UTC)
@Wcam這樣子?-- 源  環  2017年3月23日 (四) 10:05 (UTC)
謝謝,我已將你的草稿轉移至Wikipedia:上傳/草稿並做了一點小改動,請大家繼續討論編輯完善。@星耀晨曦:@Datou 1996:--Wcam留言) 2017年3月23日 (四) 15:12 (UTC)
有沒有可能直接將UploadWizard擴展引入到中文維基百科?--Jerre Jiang  討論參與清理積壓站務  2017年3月23日 (四) 15:37 (UTC)

關於過於簡潔的重定向

閣下發現用戶Abacn創建過於簡潔的重定向,如萊伊爾,C. ,這樣子不符合重定向的規定,這樣子在下以提刪的方式來進行,請大家討論一下。--小躍撈出記錄) 2017年3月15日 (三) 00:15 (UTC)

通知:2017年中國大陸社群聚會(第二次,2月16日)

請管理員留意正在維基百科:互助客棧/消息發生的「編輯戰」

兩用戶在這幾天內來回的互相回退同一內容。——꧁༺星耀晨曦༻꧂留言) 2017年3月20日 (一) 13:54 (UTC)

已被Antigng 半保護7天,7天過後系統會自動解除此頁保護。 --碸中嘌呤的白磷萃取 打譜 2017年3月21日 (二) 13:08 (UTC)

提取已存檔之標題

通知:2017年中國大陸社群聚會(第二次,2月16日)

本話題因無新的實質討論引發爭吵而移動至本頁面,並於數日後存檔。未免編輯戰,將以存檔之標題提取出來供閱覽者觀看。--1.170.18.230留言) 2017年3月21日 (二) 10:03 (UTC)

著哪門子急啊,等機器人自動存檔不好嗎?之前有個討論,一群人隔三差五才來一句,把整個討論串拖了近半年,最後也成功歸檔了哦。--逆襲的天邪鬼留言) 2017年3月22日 (三) 12:38 (UTC)

條目有隱藏的內容該如何修正

少女時代影視作品列表 想請問如果該條目存在隱藏的內容該如何編輯或者修正? 嘗試過利用編輯編寫,但編輯完成後並沒有改善。 想請問是否我操作方式錯誤了?謝謝—以上未簽名的留言由Quintasong對話貢獻)於2017年3月22日 (三) 15:42(UTC)加入。

去掉{{hideH}}和{{hideF}}。——꧁༺星耀晨曦༻꧂留言) 2017年3月22日 (三) 16:27 (UTC)