跳转到内容

维基百科:互助客栈/技术

维基百科，自由的百科全书

快捷方式

本頁用作讨论在编辑时遇到的技术问题；發表問題或討論前，請先參閱常見問題解答、帮助信息、MediaWiki基本問題及搜索舊討論記錄。另請注意：

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


發表前請先搜索存档，參考舊討論中的内容可節省您的時間。
一般
條目與內容
頁面處理
用户行為
其他

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

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 我的Wikiplus无法在除Edge之外的浏览器使用 11 3 自由雨日 2024-08-07 17:16
2 2024年第31期技術新聞 6 5 Cwek 2024-08-04 17:06
3 考虑统一一下内联标签的样式？ 4 4 SunAfterRain 2024-08-04 15:11
4 哈佛注脚中日语字的转换问题 7 5 FradonStar 2024-08-04 19:03
5 2024年第32期技術新聞 3 3 魔琴 2024-08-10 22:53
6 Template:Lang 4 2 Kethyga 2024-08-10 20:39
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基百科技術議題與模板

Wikipedia:徵求意見/深色模式 § 導言

近期部署的深色模式（Dark mode）对页面内容带来了很多兼容性问题，需要修复。可参考mw:Recommendations for night mode compatibility on Wikimedia wikis。

修复工作需要修复许多模板、模块以及小工具，还有个别的页面也需要修复。这个征求意见的目的一是需要很多人帮忙查找问题并修复，二是一些页面如何修复可能会影响到页面本身的用色、排版设计，需要进一步讨论寻求共识。

--百無一用是書生 (☎) 2024年6月22日 (六) 12:34 (UTC)

MediaWiki talk:Gadgets-definition § 提議引入CollapsibleToggle作為預設啟用可選擇關閉的小工具

日前的討論將多個使用NavFrame的模板切換成了一般的mw-collapsible導致這些模板不再能透過點Head來展開或關閉，故在此提議引入CollapsibleToggle來讓這些模板可以恢復以前的行為。同時此小工具也為其他類型的mw-collapsible提供點未隱藏的區塊來展開的功能，具體測試樣例可以參考[1]（Beta Cluster）。--SunAfterRain 2024年8月4日 (日) 13:23 (UTC)

條目主題
非條目主題
提示
要將某一個討論加入上述列表中：
  • 在討論頁中的對應討論章節頂端加上{{rfc|xxx}}標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入{{rfc}}中。多個分類請使用管道符號分開，如{{rfc|xxx|yyy}}，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱維基百科:徵求意見。請在維基百科討論:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

话说，中文维基百科的首页是否应该改版了

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:首页。

根据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)[回复]
(＋)支持，不過仍覺得目前版本是眾多語言中最簡潔美觀的。我有時間的話會試試自己做一個。可以考慮公開征稿。題外話：老實說，整個維基百科的版面大體還是停留在十幾年前，完全錯過了近年來網絡設計風格的演變和瀏覽器技術的發展。要煥然一新的感覺，可參考[2]、[3]、[4]。忍不住要說現在的問題：頂欄和左邊欄浪費寶貴空間，不美觀，過於依賴小字體純文字連結而不是接觸面積更大的按鈕；搜尋是網站最最重要的元素，卻那麼小，躲在角落；條目版面不善（完全不）運用空白去區隔內容元素，正文、圖片、模板框、表格等常常堆在一起；整體字體太小，行距太窄，不易閱讀；瀏覽條目的章節結構極不方便（不像移動版），同樣左邊欄空間被浪費了。埋怨完畢。看來如果基金會不在乎用戶體驗的提升，我們也就只能改改首頁了。鋼琴小子 留言 貢獻 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)[回复]
  • (＆)建議：个人更倾向于开发全新的皮肤（个人更倾向于偏科技感的简洁扁平化皮肤，如tumblr、Pinterest等网站的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)[回复]
如果不考虑风格一致（左侧边、上边栏）的话，建议请自行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)[回复]

鹿角立鹤在新条目推荐中被搁置

维基百科:新条目推荐/候选中的鹿角立鹤（2月25日）在提名通过后，搁置近两周未能进入首页“你知道吗？”栏目，还请管理员手动更新。--我是兔妹（留言） 2017年3月12日 (日) 05:01 (UTC)[回复]

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

Tech News: 2017-11

来自维基媒体技术社群的最新技术新闻。请将这些更新转告给其他用户。不是所有的更新都将影响您。翻译亦已提供。

本周更新

  • 您将可以在您的wiki中，多于一列地显示来自<references />标签的参考文献。您实际看见的列数取决于您的屏幕大小。当然在一些wiki上已存在能够实现该功能的模板。使用<references />标签的模板将需要更新，此后更新将发生在所有参考文献列表中。 [5][6]
  • MediaWiki的新版本将于3月14日部署于测试维基及MediaWiki.org。它将于3月15日部署至非维基百科wiki及部分维基百科，并于3月16日部署至所有wiki，参见日历。

会议

  • 您可以参与下周可视化编辑器团队的会议。在会议中您可以告知开发人员哪些问题是最重要的。会议将于3月14日 19:00（UTC）开始。参见如何加入。

将来更新

  • 部分旧浏览器今后将无法使用维基媒体wiki上的JavaScript。如果您的电脑上拥有旧浏览器的和，您可以升级到更新版本。 [7]
  • 模板中的CSS今后将存储在单独页面中。 [8][9]

技术新闻由技术新闻编者准备，并由机器人发送 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

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)[回复]
  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)[回复]
    (：)回應@Cdip150：，各种复杂模板①不会比条目总数多，②编者一般更有经验进行处理。站在技術維護的角度而言，模板和脚本不多，比条目更容易控制；至于所谓運算邏輯上的逆向理解（即“禁用东西还要额外声明”），阁下恐怕是没有见过{{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)[回复]
@Cdip150：硬编码本身不是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)[回复]

可能受影响的模板

这里列出部分可能受影响的模板，用于注意可能需要修改。有需要自行添加。——路过围观的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)[回复]

要不要新增帐户密保问题

本主題或以下段落文字，移動自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)[回复]

如果我想要将一段文字放到右栏，该怎么做？

案发现场

如上--脂肪酸钠（留言） 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)[回复]

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

来自维基媒体技术社群的最新技术新闻。请将这些更新转告给其他用户。不是所有的更新都将影响您。翻译亦已提供。

最近更改

  • 除维基百科和维基新闻外，保存页面（Save page）按钮现已在维基媒体wiki站台改称发布页面（Publish page）或发布更改（Publish changes）。该更改日后也将应用到维基百科上，更改的关键原因是使其更清楚地表达编辑将立即更改页面这一点。当您保存新页面时将显示发布页面，而当您编辑现有页面时则将显示发布页面。 [11]
  • DMOZ不再工作。使用DMOZ的模板会被重定向到archive.org或其他镜像网站。DMOZ已从维基导游的RelatedSites扩展中移除。 [12]
  • 当您点击边栏上的页面信息时，您可以查看每月页面浏览量。开发人员也可以通过API获取它。 [13]
  • Linter扩展已在小型维基媒体网站上启用。这帮助编辑者查找一些wiki文本错误，这样就能帮助修复。日后同样会在其他维基媒体网站上部署，扩展今后也将能够查找更多错误。 [14]
  • MediaWiki-Vagrant便携式开发环境现已改用Debian Jessie。这意味着本地开发测试将更像在大多数维基媒体产品服务器上那样。 [15]

问题

  • 3月15日部分跨语言链接未被正确分类。现已修复。如果您仍然看见页面上的跨语言链接未被正确排序的话，其或许在一段时间后被修复，或者您可以编辑页面（但不做任何更改）并保存来修复这一问题。如果仍然不能工作，请报告相关问题。 [16]

本周更新

  • 当您通过可视化编辑器编辑时，您将可以切换书写方向，可将从右至左切换为从左至右，反之亦然。这对于使用从右至左书写语言的用户来说非常重要。您可以使用编辑菜单中的工具做到这一点。您也可以使用键盘快捷键，PC端Ctrl+Shift+X或在Mac系统中为Cmd+Shift+X。 [17]
  • MediaWiki的新版本将于3月21日部署于测试维基及MediaWiki.org。它将于3月22日部署至非维基百科wiki及部分维基百科，并于3月23日部署至所有wiki，参见日历。

会议

  • 您可以参与下周可视化编辑器团队的会议。在会议中您可以告知开发人员哪些问题是最重要的。会议将于3月21日 19:00（UTC）开始。参见如何加入。

技术新闻由技术新闻编者准备，并由机器人发送 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

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)[回复]

數學公式顯示錯誤

右圖展示英文維基條目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的解决方案？@SFSQ2012、Liuxinyu970226、Shizhao：能去看看这个解决如何？——路过围观的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)[回复]
试了下，搜维基百科结果数为128,189条，維基百科为121,281条，还是略有差异，不过比现在的好多了。感谢User:Liuxinyu970226、User:TJones (WMF)等人的跟进。（说实话，我当时刚来维基百科，只是想试下P区到底怎么用，所以报了这个bug，其实后来我自己都不管了）--SFSQ2012（留言） 2017年3月24日 (五) 14:29 (UTC)[回复]

小作品链接样式优先级不应高过消歧义橙链优先级

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Gadget-DisambiguationLinks.css。

参数设置里面有两个和链接颜色有关的功能，一个是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)[回复]
  • (！)意見：中文版的NavFrame和Collapsible table是以小工具的形式实现的，并不像其他语言那样是直接放在common.css和common.js中的，这样做的好处就在于注册用户可以自行选择是否开启这两项功能，这对于中文维基虚构作品类条目含有过多隐藏内容的现状非常有好处，关掉这两项功能可以把全部隐藏内容都展开显示，以方便巡查。如果共享英文版的代码，就会失去这一特色。所以，请慎重考虑。--Dabao qian（留言） 2017年3月24日 (五) 09:21 (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)[回复]

首页特色条目展出中的公示图被错误加上左图使用的margin

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Common.css。

MediaWiki:Common.css里面有一条规则，用来在特色展出图旁边加空白： 

#mp-2012 #column-feature img, #mp-2012 #column-good img {
    margin: 0.4em 0.9em 0.3em 0; /* 上 右 下 左 */
}

可是这个image打得太歪，打中了公式svg回落的img元素，结果变成了 https://archive.fo/WBlxt 或者 https://archive.fo/WBlxt/image 记录下来的样子。建议在img后面加一个:not(.mwe-math-fallback-image-inline)例外绕过。——Artoria2e5编 讨论要完整，回复请用ping。 2017年3月24日 (五) 02:41 (UTC)[回复]

 已修复，换了个方法写，以免:not()有浏览器不支持。Liangent（留言） 2017年3月24日 (五) 15:18 (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)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/技术&oldid=43736151”