跳转到内容

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