跳转到内容

维基百科:互助客栈/技术/存档/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”