跳至內容

維基百科:互助客棧/技術/存檔/2017年3月

新增連結
維基百科，自由的百科全書

請問維基百科上是否有關於中國大陸地圖定位不準的處理方略

本主題全部或部分段落文字，已移動至Template talk:Coord。執行人：Jimmy-bot（留言） 2017年3月5日 (日) 08:42 (UTC)。

模板{{藝人}}在外文名為日文時並不會正確地移除繁簡轉換

本主題全部或部分段落文字，已移動至Template talk:藝人。執行人：Jimmy-bot（留言） 2017年3月8日 (三) 16:42 (UTC)。

能否讓{{In use}}在給的期限過了以後不顯示

如題，比如{{In use|2小時}}，模版就會在最新版本的時間+兩小時後隱藏。其他的技術上目測都不難，只是對輸入時間的處理估計要用枚舉大法。另外想看看社群對此有沒有反對意見。 --碸中嘌呤的白磷萃取 打譜 2017年2月19日 (日) 08:27 (UTC)

只通過代碼的話沒辦法自動移除模板耶。雖然可以加個<span style="display:none">來隱藏。——꧁༺星耀晨曦༻꧂（留言|2017年監管員選舉） 2017年2月19日 (日) 08:44 (UTC)
啊咧，我不是改了措辭嗎，還會有這種誤解啊……總之就這意思。或者寫個機器人從根本上解決問題怎麼樣？ --碸中嘌呤的白磷萃取 打譜 2017年2月19日 (日) 09:01 (UTC)
表示我正在用手機看維基百科——꧁༺星耀晨曦༻꧂（留言|2017年監管員選舉） 2017年2月19日 (日) 09:03 (UTC)
Category:被擱置的條目。--A2093064#Talk 2017年2月19日 (日) 11:41 (UTC)
就算我輸入的是{{Inuse|3小时}}，超過2小時也會被加入分類（因為{{#ifexpr:{{#time:U}}-{{#time:U|{{REVISIONTIMESTAMP}}}}>7200|[[Category:被擱置的條目]]}}），太暴力了。 --碸中嘌呤的白磷萃取 打譜 2017年2月20日 (一) 01:40 (UTC)
同，因為{{In use}}參數不限定是時間，可能是描述性的語句（可以說「永久」，「直到我厭倦的時候」等），這樣根本判斷不出來計算時間。——路過圍觀的Sakamotosan 2017年2月22日 (三) 09:15 (UTC)
{{In use}}建議不超過2小時，所以我就這麼寫7200了。--A2093064#Talk 2017年3月1日 (三) 04:31 (UTC)

問：之前在自己的討論頁上啟用了Flow，後來更改用戶名之後，Flow版面依舊留在舊用戶名底下，該如何解決？

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行人：Dabao qian（留言） 2017年2月28日 (二) 17:45 (UTC)。

這個問題我來幫特克斯特問一下。該用戶曾經用過「Kty Dexter」這個用戶名，之前在自己的用戶討論頁上啟用了Flow，但是後來他在元維基申請把自己的用戶名改成了「特克斯特」，之後他的用戶頁也被移動到新名字下面，但是之前的Flow討論頁卻繼續留在了舊名字下面，新名字下面現在也重新創建了新的討論頁，請問這種情況該如何去合併？--Dabao qian（留言） 2017年2月28日 (二) 16:17 (UTC)

兩個用戶討論頁面而已。把User talk:Kty Dexter不留重定向的移動到User talk:特克斯特/flow或者啥啥的。——꧁༺星耀晨曦༻꧂（留言|2017年監管員選舉） 2017年2月28日 (二) 16:58 (UTC)
(：)回應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:]][[user:]]：沒用的，提示「目標頁面不允許flow-board內容」，難道必須由管理員來操作？--Dabao qian（留言） 2017年2月28日 (二) 17:47 (UTC)
要管理員把目標頁面的內容模型從wikitext改成flow-board。 --碸中嘌呤的白磷萃取 打譜 2017年2月28日 (二) 23:57 (UTC)
管理員也沒這個權限，只有flow機器人有。--Antigng（留言） 2017年3月1日 (三) 01:19 (UTC)
原來是這樣……我還以為管理員就可以隨便改內容模型了。 --碸中嘌呤的白磷萃取 打譜 2017年3月1日 (三) 01:20 (UTC)
好像全域Flow創建者才可以。——꧁༺星耀晨曦༻꧂（留言|2017年監管員選舉） 2017年3月1日 (三) 03:03 (UTC)
去回報給Flow技術員--小躍（撈出記錄） 2017年3月1日 (三) 04:53 (UTC)

有沒有必要用機器人修復一下這種格式的引用

我由於嫌一個個手工改麻煩，Special:Diff/43232672其實就是用正則表達式替換的：

Find：<ref> *(http[^ {<]+ +[^ <\n][^<\n]*[^ <\n]) *</ref>
Replace with：<ref>\[\1\]</ref>

避開文字中有換行符的。大家覺著呢？--1=0，歡迎維基人加QQ群170258339 2017年2月15日 (三) 08:01 (UTC)

一共也沒幾個？ --碸中嘌呤的白磷萃取 打譜 2017年2月15日 (三) 08:06 (UTC)
改這樣也沒好多少啊！[網址 標題]格式資訊太少，幾乎可以說是裸網址。-游蛇脫殼/克勞棣 2017年2月15日 (三) 08:14 (UTC)
推銷一下Reflinks，很好用。——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月16日 (四) 17:35 (UTC)
麻煩的是還有那種單純一個網址的，還得打開網頁看標題才能修復。--Tiger（留言）你指尖的電光是我此生不變的信仰 2017年2月17日 (五) 15:39 (UTC)
@Tigerzeng：上面說了，用Reflinks。——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月22日 (三) 05:15 (UTC)
如果是垃圾連結，替換了反而看不出…--578985s（留言） 2017年3月1日 (三) 16:04 (UTC)

Template:Infobox_mineral的排版問題

剛參照英文維基百科創建了自然銅頁面，可是在我的chrome瀏覽器上Template:Infobox_mineral模板顯示不正常。像「類別」，「化學式」等這些說明文字全都成了豎行排版，導致整個模板非常長。猜測應該是「晶體慣態」一欄由於字很多，把說明文字擠成了豎排，但感覺這樣不甚美觀，請求熟悉技術的維基人修改下模板，使其和英文wiki的行為一致。感謝！

Abacn（留言） 2017年3月2日 (四) 00:10 (UTC)

請求更新Gadget-ProveIt 到最新版本

Golopotw（留言） 2017年3月4日 (六) 02:53 (UTC)

已更新--J.Wong 2017年3月4日 (六) 05:42 (UTC)

為什麼照片版權的PD-China授權協議不能以中文顯示

本主題全部或部分段落文字，已移動至Template talk:PD-China。執行人：Jimmy-bot（留言） 2017年3月14日 (二) 16:42 (UTC)。

Template:Infobox_country

Template:Infobox_country吉尼係數計算出錯？吉尼係數不可能大於1。－日月星辰【留言簿】 2017年3月4日 (六) 10:07 (UTC)

@Nickice：模版算的是基尼指數，就是百分比。也許需要改一下說明文字，免得誤會。 --碸中嘌呤的白磷萃取 打譜 2017年3月4日 (六) 15:06 (UTC)
話說參數都做成表格了，怎麼還沒人寫成Templateinfo……（x——Artoria2e5編 保持討論完整，直接ping我回復。 2017年3月5日 (日) 02:59 (UTC)

ORES的word list需要中文社群給出反饋和意見

於Phabricator內跟蹤
任務T109366

見Research:Revision scoring as a service/Word lists/zh和phab:T109366--百無一用是書生 (☎) 2017年2月28日 (二) 07:31 (UTC)

提了一個分詞的建議。Informal是應該手動來提出，還是該讓機器去比較這裡有那裡沒有？——Artoria2e5編 保持討論完整，直接ping我回復。 2017年3月4日 (六) 06:48 (UTC)
啊，機器人生成的兩個列表讀起來超搞笑！[開玩笑的]——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月5日 (日) 21:10 (UTC)

能否有技術能批量處理歌曲條目榜單成績和銷售認證一段的半角符號

如條目：小事情 (1世代歌曲)用了大量半角符號，不規範。其中有一些半角符號是模板問題，我可以修改，有一些不是模板問題，這些可否批量轉換為全形？如果有的話我就去修改singlechart模板了。--星巴克女王（❀教母改善計劃） 2017年2月28日 (二) 09:00 (UTC)

對於「不是模版問題」，似乎把(和)替換成（和）就行了吧。我沒看到有應該用半角括號的地方。 --碸中嘌呤的白磷萃取 打譜 2017年2月28日 (二) 09:09 (UTC)
@WhitePhosphorus：對的，請問機器是否能批量操作這些條目呢？--星巴克女王（❀教母改善計劃） 2017年2月28日 (二) 09:14 (UTC)
不能，除非半自動或事先挨個檢查確認。見WP:BOTPOL，上下文有關的修改。--Antigng（留言） 2017年2月28日 (二) 13:32 (UTC)
如上所述，首先要把您要改的條目全部列出來，然後半自動替換（其實維基內置的查找替換功能就行了）。畢竟機器人暴力改還是很可能會把不該改的地方改錯。 --碸中嘌呤的白磷萃取 打譜 2017年2月28日 (二) 14:51 (UTC)
囧rz...既然如此，只好人工修復了。由於工作量較大，希望有人能協助一下，呼叫一些音樂專題的參與者：@百战天虫：@CBNWGBB：@Hikki：@Panxing29：@David S. Hwang：@SSYoung：。中文維基百科目前要大規模修改的歌曲條目主要有三大類：1.告示牌年終榜單中的歌曲。2.各知名演出者的歌曲。3.Category:各年歌曲分類下的歌曲。--星巴克女王（❀教母改善計劃） 2017年3月1日 (三) 04:57 (UTC)
@星巴克女王： 大陸官方的語言標準是漢語中的純西文引用內部應遵守西文的標點規範，如果不考慮翻譯括號內西文的話，似乎就應該用西文標點。關於香港台灣的標準還請指教。倒是榜單的模板中「Billboard」一詞不應為斜體，作為廣為人知的商標也應該考慮翻譯。David S. Hwang（留言） 2017年3月1日 (三) 05:33 (UTC)
@David S. Hwang：：但是就算用半角也要所有條目全部改用半角，目前專輯條目是用的全形，和歌曲條目的格式不統一，希望大家一起參與討論出共識吧。--星巴克女王（❀教母改善計劃） 2017年3月1日 (三) 11:26 (UTC)
該用什麼標點也要共識了嗎……WP:PUNCT。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月6日 (一) 02:15 (UTC)
是說周榜單這裡的括號麼？這裡一般都是{{singlechart}}模板的問題吧，修復之後剩下的應該不多了（？）看到就隨手修改吧--#young[誰？] 2017年3月1日 (三) 15:05 (UTC)

關於熱帶氣旋警告信號（1~5）模板圖片的顯示問題

關於熱帶氣旋警告信號（1~5）模板圖片的顯示問題，Template:GDTY 不知道什麼情況，熱帶氣旋警告的模板變成{{GDTY|1}}，{{GDTY|2}}，……而不是圖片？ --Super 122 2017年3月5日 (日) 08:02 (UTC)

@Super 122：看一下源碼就知道了，合理使用被bot掐了。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月5日 (日) 20:00 (UTC)
@Artoria2e5：謝謝你！是機器人多了一個「:」的鍋，導致顯示怪怪的，刪掉就正常啦，

(～)補充原來是有版權問題。。--Super 122 2017年3月6日 (一) 05:55 (UTC)

Tech News: 2017-10

來自維基媒體技術社群的最新技術新聞。請將這些更新轉告給其他用戶。不是所有的更新都將影響您。翻譯亦已提供。

最近更新

  • 現在您在英語、法語、希伯來語和希臘語wiki上，即便您忘記附加符號也可以搜索並找到單詞。在您搜索時使用附加符號，但wiki不使用時也能工作。 [1]
  • 當您使用移動版視圖，並點擊另一語言的條目連結時，您將繼續以移動版視圖查看那個條目。此前同樣操作將更改為桌面版視圖。 [2]

問題

  • 部分監視列表小工具上周有一段時間不能工作。現已修復。 [3]
  • 在某位用戶的Special:Contributions頁面上點擊「大量刪除」的管理員將再次直接前往該用戶創建的頁面列表。這有一段時間不能工作。 [4]

本周更新

  • 您在桌面版視圖中，wiki文本編輯器和可視化編輯器之間切換的方式已更新。現改為下拉菜單。這與移動版視圖相同。 [5]
  • 「在過濾日誌中標記該編輯」複選框將從防濫用過濾器界面移除。這是因為編輯總會被記錄在濫用日誌中。 [6]
  • MediaWiki的新版本將於3月7日部署於測試維基及MediaWiki.org。它將於3月8日部署至非維基百科wiki及部分維基百科，並於3月9日部署至所有wiki，參見日曆。

會議

  • 您可以參與下周可視化編輯器團隊的會議。在會議中您可以告知開發人員哪些問題是最重要的。會議將於3月7日 20:00（UTC）開始。參見如何加入。

澄清

技術新聞由技術新聞編者準備，並由機器人發送 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2017年3月6日 (一) 23:23 (UTC)

svg文件的測試沙盒

本主題全部或部分段落文字，已移動至Help talk:文件。執行人：Jimmy-bot（留言） 2017年3月16日 (四) 16:42 (UTC)。

nowiki導致不可見字符

cite系模版的某些參數中加入nowiki標籤時會報錯說含有delete char，並列入Category:引文格式1錯誤：不可見字符中。示例：Special:diff/43515453。 --碸中嘌呤的白磷萃取 打譜 2017年3月7日 (二) 15:08 (UTC)

是不是和模塊:Citation/CS1/Configuration提到的 stripmarker 有關？——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月7日 (二) 17:02 (UTC) 建議找個沙盒模塊，多測試幾下unstripNoWiki。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月7日 (二) 17:07 (UTC)
我也很懷疑這個（而且enwp沒用這個函數且沒有這個bug（好吧這其實說明不了什麼）），就是比較犯懶……UTC的明天再說吧。 --碸中嘌呤的白磷萃取 打譜 2017年3月7日 (二) 17:11 (UTC)

Flow頁的描述欄里模版不會刷新

於Phabricator內跟蹤
任務T160265

總之，試著在WT:Flow tests的描述里放了個{{Bulletin}}，結果它一直沒更新……（如果我火星了，請無視我） --碸中嘌呤的白磷萃取 打譜 2017年2月24日 (五) 03:01 (UTC)

編輯後才會更新，這是Flow版本的缺陷。--小躍（撈出記錄） 2017年2月24日 (五) 03:29 (UTC)

不知道能不能{{purge}}呢……）——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月27日 (一) 13:52 (UTC)
這個方法用過了，沒有效用。--小躍（撈出記錄） 2017年3月2日 (四) 23:36 (UTC)

purge問題已報告為phab:T160265——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月11日 (六) 23:49 (UTC)

圖書功能測試站點反饋

於Phabricator內跟蹤
任務T128425
  1. Special:圖書不能渲染PDF
  2. 導出PDF：
    • 單列可以導出首頁PDF且沒有亂碼
    • 多列渲染失敗
  3. 導出TxT渲染失敗。——꧁༺星耀晨曦༻꧂（留言|2017年監管員選舉） 2017年2月24日 (五) 02:07 (UTC)
同。話說有沒有Infobox可以測試？ ——Artoria2e5編 保持討論完整，直接ping我回復。 2017年3月3日 (五) 16:20 (UTC)
是啊，能不能匯入infobox、navbox一類模板以便於進一步測試渲染效果呢？我簡單試了一下，感覺除了簡繁轉換和明顯不應該加入到頁面的浮動內容以外好像沒什麼問題。--逆襲的天邪鬼（留言） 2017年3月3日 (五) 16:51 (UTC)
有包含模組 (Model) 名字空間的頁面也能測試嗎？--　宇帆（普通留言·Flow留言·聯絡） 2017年3月12日 (日) 06:20 (UTC)

使用Special:內容翻譯時，T:chembox會在翻譯後轉換為表格形式

在原始碼中會變成表格，而不是模板。例如1,2-環己二醇。不知為何，其它模板似乎並不是這樣？--曾晉哲（留言） 2017年3月12日 (日) 07:58 (UTC)

可能是因為en:T:chembox就是直接用表格拼的。不過即使是這樣也不該拆開啊？建議上phab:報一個。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月12日 (日) 16:59 (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)

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)

要不要新增帳戶密保問題

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行人：--61.224.18.54（留言） 2017年3月16日 (四) 12:59 (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)

Tech News: 2017-11

來自維基媒體技術社群的最新技術新聞。請將這些更新轉告給其他用戶。不是所有的更新都將影響您。翻譯亦已提供。

本周更新

  • 您將可以在您的wiki中，多於一列地顯示來自<references />標籤的參考文獻。您實際看見的列數取決於您的屏幕大小。當然在一些wiki上已存在能夠實現該功能的模板。使用<references />標籤的模板將需要更新，此後更新將發生在所有參考文獻列表中。 [7][8]
  • MediaWiki的新版本將於3月14日部署於測試維基及MediaWiki.org。它將於3月15日部署至非維基百科wiki及部分維基百科，並於3月16日部署至所有wiki，參見日曆。

會議

  • 您可以參與下周可視化編輯器團隊的會議。在會議中您可以告知開發人員哪些問題是最重要的。會議將於3月14日 19:00（UTC）開始。參見如何加入。

將來更新

  • 部分舊瀏覽器今後將無法使用維基媒體wiki上的JavaScript。如果您的電腦上擁有舊瀏覽器的和，您可以升級到更新版本。 [9]
  • 模板中的CSS今後將存儲在單獨頁面中。 [10][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)

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)

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

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

Tech News: 2017-12

來自維基媒體技術社群的最新技術新聞。請將這些更新轉告給其他用戶。不是所有的更新都將影響您。翻譯亦已提供。

最近更改

  • 除維基百科和維基新聞外，保存頁面（Save page）按鈕現已在維基媒體wiki站台改稱發布頁面（Publish page）或發布更改（Publish changes）。該更改日後也將應用到維基百科上，更改的關鍵原因是使其更清楚地表達編輯將立即更改頁面這一點。當您保存新頁面時將顯示發布頁面，而當您編輯現有頁面時則將顯示發布頁面。 [12]
  • DMOZ不再工作。使用DMOZ的模板會被重定向到archive.org或其他鏡像網站。DMOZ已從維基導遊的RelatedSites擴展中移除。 [13]
  • 當您點擊邊欄上的页面信息時，您可以查看每月頁面瀏覽量。開發人員也可以通過API獲取它。 [14]
  • Linter擴展已在小型維基媒體網站上啟用。這幫助編輯者查找一些wiki文本錯誤，這樣就能幫助修復。日後同樣會在其他維基媒體網站上部署，擴展今後也將能夠查找更多錯誤。 [15]
  • MediaWiki-Vagrant可攜式開發環境現已改用Debian Jessie。這意味著本地開發測試將更像在大多數維基媒體產品伺服器上那樣。 [16]

問題

  • 3月15日部分跨語言連結未被正確分類。現已修復。如果您仍然看見頁面上的跨語言連結未被正確排序的話，其或許在一段時間後被修復，或者您可以編輯頁面（但不做任何更改）並保存來修復這一問題。如果仍然不能工作，請報告相關問題。 [17]

本周更新

  • 當您通過可視化編輯器編輯時，您將可以切換書寫方向，可將從右至左切換為從左至右，反之亦然。這對於使用從右至左書寫語言的用戶來說非常重要。您可以使用編輯菜單中的工具做到這一點。您也可以使用鍵盤快捷鍵，PC端Ctrl+Shift+X或在Mac系統中為Cmd+Shift+X。 [18]
  • MediaWiki的新版本將於3月21日部署於測試維基及MediaWiki.org。它將於3月22日部署至非維基百科wiki及部分維基百科，並於3月23日部署至所有wiki，參見日曆。

會議

  • 您可以參與下周可視化編輯器團隊的會議。在會議中您可以告知開發人員哪些問題是最重要的。會議將於3月21日 19:00（UTC）開始。參見如何加入。

技術新聞由技術新聞編者準備，並由機器人發送 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2017年3月20日 (一) 22:03 (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)
  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)
    街燈說出了我的看法， 讚。——路過圍觀的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:RFBA、WP: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/reflist、mw:User:Cwek/common.css、mw: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/defalut、mw: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)
{{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)
  • (－)反對，估計要做的事情會是這樣：如果默認啟用，要改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:OWN、WP: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)
        • 「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)
  • (＋)支持--耶穌會士張明山大師 2017年3月21日 (二) 13:14 (UTC)
  • (－)反對：如果可能出現製造錯誤而不能改正的情況，只可以反對，否則有錯誤時恨錯難返。--HanasakiMomoko（留言）
    • @HanasakiMomoko：，沒有製造錯誤而不能改正的情況，都可以改正。上面說的錯誤現在的模式下同樣存在，而且可能更不好辦--百無一用是書生 (☎) 2017年3月31日 (五) 09:20(UTC)
      • 都已經確認了會有條目歷史的參考顯示有問題而且不能改正的啊。--Maccomcre（留言） 2017年 3月31日 (五) 15:46 (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)

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

案發現場

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

@脂肪酸钠：已在b:Special:Diff/85278和b: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)

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

@Liangent、Jimmy 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)
你確認下吧，我見分類第一條條目，就是屬於沒有references標籤的。而且也沒有掛其他修葺標記（所以可能不是修葺標記的跟蹤分類），這個分類是由Category:有參考文獻錯誤的頁面找來的，而前者是系統自動跟蹤標籤，所以推測可能也是系統定義的跟蹤標籤。所以根據表現，推測可能就是用於跟蹤沒有references標籤的行為（或其中之一的功能）？——路過圍觀的Sakamotosan 2017年3月24日 (五) 00:41 (UTC)
再確認一下，可能真的不是，這分類功能應該是如果頁面有帶name無標籤體的ref，但沒有帶相同name有標籤體的ref的話，就會歸入這類，看來的確是搞錯了。——路過圍觀的Sakamotosan 2017年3月24日 (五) 00:51 (UTC)
@cwek：那分類似乎是跟「引用錯誤：沒有為名為...的參考文獻提供內容」這個有關。--A2093064#Talk 2017年3月24日 (五) 00:49 (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)

規範控制模板好像出問題了

早先中文維基在引入「規範控制」這個概念時，相關模板對比英文版專門特化了兩岸四地的圖書館編號參數。自從規範控制信息遷往維基數據之後，原先含有這些參數的條目都不同程度地出現了各種問題，比如含有NLC編號的「胡錦濤」條目，底下出現了一行紅字：

Lua錯誤 模塊:Authority_control的第241行：attempt to concatenate field 'NLC_URL' (a nil value)

請問該問題應當如何解決？--Dabao qian（留言） 2017年3月24日 (五) 09:33 (UTC)

NLC這東西很麻煩（好像站點也改了）要一個 ID 然後還要一個 URL。這個模塊的要求好像是你自己加一個NLC_URL的參數。——Artoria2e5編 討論要完整，回復請用ping。 2017年3月24日 (五) 13:52 (UTC)
去Wikidata:Wikidata:Project_chat#NLC (P1213) has some strange ID/URL mechanisms求助了。——Artoria2e5編 討論要完整，回復請用ping。 2017年3月24日 (五) 14:04 (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)
  • (！)意見：中文版的NavFrame和Collapsible table是以小工具的形式實現的，並不像其他語言那樣是直接放在common.css和common.js中的，這樣做的好處就在於註冊用戶可以自行選擇是否開啟這兩項功能，這對於中文維基虛構作品類條目含有過多隱藏內容的現狀非常有好處，關掉這兩項功能可以把全部隱藏內容都展開顯示，以方便巡查。如果共享英文版的代碼，就會失去這一特色。所以，請慎重考慮。--Dabao qian（留言） 2017年3月24日 (五) 09:21 (UTC)

模板Singlechart出錯了

「腳本錯誤：沒有此類模塊「WLink」。&titel=腳本錯誤：沒有此類模塊「WLink」。」把英文版的源代碼複製到中文版創建卻發生編譯錯誤，求解決。--星巴克女王（❀教母改善計劃） 2017年3月24日 (五) 15:28 (UTC)

數學公式顯示錯誤

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

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

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

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

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

3月11日的幾個條目已擱置兩周，請處理。--113.52.81.64（留言） 2017年3月25日 (六) 05:20 (UTC)

30天內有編輯卻被移動至存檔的IP用戶討論頁

在這則編輯記錄中可以看到，機器人將我在兩個小時前做過編輯的一個IP用戶討論頁移至存檔，是不是出了問題？ --KRF（留言） 2017年3月25日 (六) 07:17 (UTC)

@Kerolf666：好問題，因為我問過了XD，請見1、2。--A2093064#Talk 2017年3月25日 (六) 09:58 (UTC)
看懂了，那這樣IP用戶能便利地看得到消息嗎？--KRF（留言） 2017年3月25日 (六) 10:02 (UTC)
經查Special:用戶貢獻/39.12.71.255，最後編輯是在2017年2月22日10:18:52 UTC的Special:diff/43313384，但是你在2017年3月25日08:19:23 UTC編輯過User talk:39.12.71.255，所以User:Jimmy-abot會根據Wikipedia:快速刪除方針#O3規定移動頁面--林勇智 2017年3月25日 (六) 13:06 (UTC)
@Kerolf666：既然30天無編輯了，可以認為他不使用那個IP了吧。--A2093064#Talk 2017年3月26日 (日) 05:43 (UTC)

{{#time:Y年n月j日H:i|+8 hours}}為何登出是正常UTC+8，為何登入後又變回顯示UTC+7？

我有測試過，{{#time:Y年n月j日H:i|+8 hours}}時間參數是沒問題的，有問題的是，我刷清後是登出狀態，看到是正常，怎麼登入後就突然時間倒退一小時？不是固定UTC+8嗎？--Kai（留言） 2017年3月26日 (日) 04:12 (UTC)

如果真的不行，我就撤下{{#time:Y年n月j日H:i|+8 hours}}不去用了。當初使用是讓人知道我編輯時是看UTC+8，而不是看UTC+0。--Kai（留言） 2017年3月26日 (日) 04:14 (UTC)
建議轉phab。——Artoria2e5編 討論要完整，回復請用ping。 2017年3月26日 (日) 15:24 (UTC)

運動模版問題

我要怎麼樣才能將

{{GamesSport|短道游泳|Events=30}}

在2013年亞洲室內暨武藝運動會形成


短道游泳(詳細)(30)

快來幫忙。Simon 1996（留言） 2017年3月27日 (一) 12:53 (UTC)

不已經是這樣了嗎？——Artoria2e5編 討論要完整，回復請用ping。 2017年3月27日 (一) 21:49 (UTC)

最新的安卓版賽風存在嚴重技術問題

本主題全部或部分段落文字，已移動至Wikipedia:知識問答。執行人：路過圍觀的Sakamotosan 2017年3月28日 (二) 03:38 (UTC)。

最近不能用TW處理頁面存廢討論

由於MediaWiki:Gadget-twinkleclose.js被更改，不能用TW處理頁面存廢討論……--Lanwi1(留言) 2017年3月28日 (二) 15:18 (UTC)

現在應該改好了。之前的修改同樣是因為不能用TW處理頁面存廢討論....--百無一用是書生 (☎) 2017年3月30日 (四) 02:53 (UTC)
於是使用Wikiplus的管理員也來抱怨了——同樣是不能處理頁面存廢討論。--逆襲的天邪鬼（留言） 2017年3月30日 (四) 04:01 (UTC)
現在沒問題，可以顯示「關閉討論」了。--Lanwi1(留言) 2017年3月30日 (四) 11:51 (UTC)
現在是開和不開VE都沒問題，但是，只要您開了Wikiplus……--逆襲的天邪鬼（留言） 2017年3月30日 (四) 12:08 (UTC)
我估計用Wikiplus的不多……--Lanwi1(留言) 2017年3月30日 (四) 14:19 (UTC)
也是，你們知道有這件事就行了。等真管理員來抱怨的時候再說吧。--逆襲的天邪鬼（留言） 2017年3月30日 (四) 14:54 (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)
我倒是有興趣知道為什麼搜尋框不能繁簡轉換，但是繁簡不同的連結還能運作？--113.52.81.134（留言） 2017年3月31日 (五) 11:59 (UTC)
@113.52.81.134：如果某個命名的一種書寫方式能被解析器的內鏈構造認出的話，能自動被轉換為對應的頁面。如果不行的話，只能靠重定向實現。但搜尋引擎部分沒有這個轉換的實現，如果感興趣，可以看下面「中文語言分析器在搜尋引擎中的效果」的解決，有開發已經接手，看上去效果還可以。——路過圍觀的Sakamotosan 2017年3月31日 (五) 13:33 (UTC)
取自「https://wiki.zwnes.eu.org/w/index.php?title=Wikipedia:互助客栈/技术/存档/2017年3月&oldid=59817928」