维基百科:互助客栈/技术/存档/2017年8月

模块:CGroup/IT不工作

于Phabricator内跟踪
任务T104109

今天发现模块:CGroup/IT好像不工作了。不知道问题出在什么地方？查了一下历史版本，似乎在此版本之后，该模块页面代码部分的的语法高亮就失效了（但编辑模式下的语法高亮还是正常的）。怀疑可能是lua语法错误（或繁简转换语法错误）导致模块不工作，但是实在找不出来哪里有语法错误（一个猜测，可能藏有不可见字符导致？），当然也可能不是语法错误，而是其它问题....--百無一用是書生 (☎) 2017年8月2日 (三) 02:30 (UTC)

目前转换正常了（看来是临时故障），但是这个语法不高亮还是如故--百無一用是書生 (☎) 2017年8月2日 (三) 03:22 (UTC)

我要怎样才能将两个完全一样的东西合并

• 以下都是中国国家奥林匹克足球队连结
  • https://www.wikidata.org/wiki/Q987926#sitelinks-wikipedia
  • https://www.wikidata.org/wiki/Q23892237#sitelinks-wikipedia
• 以下都是残疾人奥林匹克运动会奖牌统计连结
  • https://www.wikidata.org/wiki/Q15922124#sitelinks-wikipedia
  • https://www.wikidata.org/wiki/Q2299775#sitelinks-wikipedia

请说要怎么样。

Simon 1996（留言） 2017年8月2日 (三) 23:31 (UTC)

• @Simon 1996：不是已经合并了吗？--A2093064#Talk 2017年8月3日 (四) 00:11 (UTC)

带参数的“内链”问题

链接带参数是不是不能用内链表示，而必须用<span class="plainlinks">[{{fullurl:某|参数}} 文字]</span>这样的方法？这样的方法在维基百科已经十分广泛使用，但产生的链接会与真正的内链有区别，例如颜色，此外内链能够自动生成鼠标悬浮时的文字而这样的链接不行。之前弄过{{fullurl}}模板但由于易出故障而高风险就被还原了。Minecraft Wiki会利用css自动识别外链形式的内链并移去链接的箭头，且Minecraft Wiki将所有的外链都改成了内链的颜色。（我也制作过Fullurl模块。）

不过，就真的不能直接制造出像某些特殊页面中的带有参数的内链吗？能否使用[[xxx|action=edit]]这样的形式。？--SolidBlock^留言 2017年8月7日 (一) 08:50 (UTC)

和这个phab:T25225有点像--百無一用是書生 (☎) 2017年8月8日 (二) 12:39 (UTC)

Tech News: 2017-32

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

最近更新

• 您可以查看在特定国家内的人喜欢阅读哪种维基百科语言版本。此工具称作Wikipedia Views Visualized。 [1]
• 架构委员会现已改称维基媒体技术委员会。您可以阅读新章程。 [2]

问题

• 当有人编辑您监视列表上的页面时，您可以获得电子邮件通知。您可以选择不接收小编辑的电子邮件。而目前这一功能存在问题，这导致有时有人在某一小编辑后作出了常规编辑，但您仍未接收电子邮件。开发人员正在修复该问题。直到此问题修复之前，您可以在您的参数设置中，在“用户资料”底部激活“当我的监视列表中的页面和文件有小编辑时也发送电子邮件通知我”。 [3]
• 感谢按钮有时对移动用户不工作。这是因为新的错误影响，现已修复。 [4]

本周晚些时候的更新

• MediaWiki的新版本将于8月8日部署于测试维基及MediaWiki.org。它将于8月9日部署至非维基百科wiki及部分维基百科，并于8月10日部署至所有wiki，参见日历。

将来更新

• 仍在Windows XP（以下简称XP）上使用Internet Explorer 8（以下简称IE8）的编辑者和阅读者将无法使用维基百科。XP上的IE8不能安全地连接wiki。当我们允许他们连接时，这意味着我们无法为其他人提供足够安全保障。如果您在XP上使用IE8的话，您可以安装并改用火狐（Firefox）52 ESR。大约0.1%的维基媒体wiki访问流量来自XP上的IE8用户。 [5]
• 维基百科链至章节的链接在不使用拉丁字母的语言中不能工作。您的浏览器地址栏中URL会显示拉丁字符（例如.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8）而不是wiki语言的章节标题。将来这些链接将改为对应wiki的文字。这将在接下来几个月解决。 [6][7]
• 浏览器“打印”功能打印的Wiki页面将拥有更新样式。新样式将会像您下载为PDF时那样。这将更好显示表格、信息框和标题。 [8][9]

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

2017年8月7日 (一) 21:45 (UTC)

跟XP说再见为何不彻底点呢^{[开玩笑的]}--Liuxinyu970226（留言） 2017年8月7日 (一) 22:36 (UTC)

另外我真是看不懂@Shizhao：在phab:T172379说了些什么。--Liuxinyu970226（留言） 2017年8月9日 (三) 09:03 (UTC)

我的意思是为什么三个来源，只有其中一个来源的数据不一样（在只计算用户访问数据的情况下），而如果feeds数据做了额外的处理，清理掉了更多的bot数据，那么就意味着最近一个月来访问量第一的wiki页面，第二的维基媒体基金会页面，其每天大多数的的访问量（数万计）都是来自于bot，这未免太奇怪了一点（而且pageview api 竟然还完全没有识别出这么多的bot流量）--百無一用是書生 (☎) 2017年8月9日 (三) 11:44 (UTC)

落实存档页保护

我看这几天方针人挺多的，特地来重提以前的讨论。

上回讨论

前期讨论

本人提议在Wikipedia:保护方针#临时保护的条件最下方增加下列句子：

• 对已确定将会在首页展示的文章／页面中进行半保护，直至文章／页面已经在首页展示完毕

并且更改下面句子：

• 对条目任何讨论的归存档，只允许作为历史记录来查看。

以上，--1233|^联系我 2017年3月13日 (一) 09:10 (UTC)

(？)疑问1.是否有明确的证据可以证明在首页展示的条目和图片是高风险页面。2.对于现有的条款“对条目讨论的归档，只允许作为历史记录来查看。”我有点疑惑，按照这所述这不就是属于永久保护了吗。——꧁༺星耀晨曦༻꧂（留言） 2017年3月13日 (一) 09:27 (UTC)

(：)回应1.保护页面不受破坏而已，已注册用户仍然可以编辑。2.我也想知道。--1233|^联系我 2017年3月13日 (一) 10:24 (UTC)

罕见的(－)反对：形同大举“预防性保护”。－ 执行编辑 Aotfs2013 留于 2017年3月14日 (二) 16:12 (UTC)

有保护不是预防性质的吗？就算高风险，也是经过评估之后，加上去的原因。其本质无异于恐怕受到破坏。而普通保护亦是预防进一步受破坏。所以结论是没有保护不是预防性质。--J.Wong 2017年3月15日 (三) 04:24 (UTC)

存档全保护亦无妨，终归无修改需要。不过这得端看每个讨论存档安排，譬如互助客栈方针区是一月一档，那最近一个月就应该暂时不保护，以便存档。但之前的存档，保护则可以大大减省维护成本，亦明显无编辑需要。--J.Wong 2017年3月15日 (三) 05:12 (UTC)

对于第一个提案，WP:保护方针#临时保护下面已经有了“重要注释：如果一个条目很活跃，可能是由于该条目在首页上有链接，或者是因为从外站有显著的链接，这种情况下该条目就很可能成为破坏的目标。一般在此情况下，不需对页面实施保护，但最好将这些条目加到监视列表中，这样自己对破坏可以及时恢复。”保护在首页展示的条目与维基百科的精神相斥。因为这将会阻挡大量的有益编辑，即使考虑到高可见性带来的破坏隐患，我相信我们的维基人会第一时间应对破坏。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 09:38 (UTC)

让我们看看前天在英文维基百科展示的God of War II。这个页面在大前天的时候，每天的浏览量不足1000，然而在登上首页后一瞬间就有了3万浏览量[10]。然而那时候这个条目只执行了移动全保护（首页的连锁保护）。相比之下，我们中文维基百科在13日展示的国立故宫博物院有4000+浏览量[11]。可以相信，我们没必要全保护在首页展示的条目。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 10:07 (UTC)

从上列数字看来的确无太大需要。存档呢？--J.Wong 2017年3月15日 (三) 10:43 (UTC)

我对第二项提案，把条目改成任何没有反对意见。但是，我对目前这项条款（保护存档页）抱有疑惑。从WP:保护方针的精神来看，“除非是高风险页面，否则保护只能用于那些已经被严重破坏的页面等其它情况（其它情况指:全保护被永久封禁用户的用户页、已去世维基人的用户页..）”，存档页没必要保护。然而从实际应用和反破坏的角度来看，万一存档被破坏者利用了，比如鬼祟破坏（恶意修改存档的他人留言，扭曲他人试图表达的观点），鬼祟破坏的特点使得阅览存档页的读者不会刻意去查看存档页的编辑历史，使读者可能会看到与以前讨论的内容不相符的观点。由于没有先例，我暂时没办法得出“保护存档”和“不保护存档”哪个更对维基百科好。不过抛开精神不管，保护存档对防止破坏来说无疑是有益的。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 11:45 (UTC)

综合维基上各项规则来看，人人可以编辑显然应该只适用于主名字空间、讨论空间及维基百科空间下各个讨论区。模板空间，高风险模板保护奉行已久。界面，如Mediawiki，及编码，如js、css，则仅有原作者或管理员级别以上用户始可编辑。用户页，用户页指引明言未得同意，不得编辑他人用户页。--J.Wong 2017年3月15日 (三) 13:43 (UTC)

我希望借此机会来明确存档保护的性质（全/半、编辑保护/移动保护、临时/永久）。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 16:45 (UTC)

个人建议全保护，永久，编辑保护。不过这个设定可能有争议，半保护亦无不可。另外，数量不鲜，除非abot愿意承包处理，否则作为可申请项目处理，即有人申请就可以作这种保护，管理员遇到亦可自行保护。--J.Wong 2017年3月16日 (四) 04:22 (UTC)

初步赞成，但应想到如何执行。本项涉及大量页面。--Temp3600（留言） 2017年3月15日 (三) 08:22 (UTC)

结论:容许对存档页面设置永久全/半保护。--Temp3600（留言） 2017年3月18日 (六) 10:42 (UTC)

我个人较赞成半保护，因全保护可能争议过大。--Temp3600（留言） 2017年3月18日 (六) 10:42 (UTC)

第二阶段讨论

提案：修改WP:保护方针有关存档页保护的条款

当下，保护方针对存档页保护的定位是临时保护。然而这个条款处于“临时保护”这个定位有点奇怪，如果是因为破坏而保护的话，则和临时保护章节下的第二条差不多。如果是为了防止鬼祟破坏而保护的话则应该属于“永久保护”的范畴。因此，我提议把这条移到上面的永久保护章节去。——꧁༺星耀晨曦༻꧂（留言） 2017年3月16日 (四) 06:42 (UTC)

• 议案相类，合并讨论。--J.Wong 2017年3月17日 (五) 07:46 (UTC)

(－)反对：全保护“不是用来预防可能会发生的破坏”--Maccomcre（留言） 2017年3月18日 (六) 00:51 (UTC)

@Maccomcre：那么阁下是认为应该把现有条款删除？因为现有的对存档页的条款和“若页面或图片近期被封禁用户进行顽固破坏或顽固编辑，则实施保护”的性质一样。都是用来防止破坏者进一步破坏的。——꧁༺星耀晨曦༻꧂（留言） 2017年3月18日 (六) 02:30 (UTC)

感觉坡滑大了。“预防可能事件”否决的更接近是凭据较少，带“水晶球”性质的保护；被近期顽固反复破坏、编辑的个别页面矛头对得则很清楚。——Artoria2e5_编 保持讨论完整，直接{{ping}}我回复。 2017年3月18日 (六) 03:54 (UTC)

那首页、高风险模板、Mediawiki界面、css及js编码及他人用户页呢？为何这些保护又不是“不是用来预防可能会发生的破坏”？又不是“凭据较少”？的而且确，维基百科是开放予众人编辑的，不过应该是局限于主名字空间、分类、帮助、普通较少连接的模板、维基百科内各空间下的讨论区等空间，但必须承认维基百科内有部分空间是要限制用户编辑。以减低维护成本。存档的而且确，仅供参阅已经可以，并毋须亦不应修改。维基百科存档众多，阁下肯定有鬼祟破坏时，可以有人第一时间发现？--J.Wong 2017年3月18日 (六) 05:06 (UTC)

“除非被保护页面是高风险页面”，条款的原本意思是低风险页面不需要预防，而存档是不常查看的页面，低风险，所以存档应该被严重破坏才能全保护。--Maccomcre（留言） 2017年3月18日 (六) 08:20 (UTC)

存档并非不常查看，在查找过去的讨论时往往要找存档。由于大多数存档页（比如:WP:VIP和互助客栈的存档）都是由机器人自动生成的，几乎没啥人监视。我认为，此类页面拥有中等可见度、低破坏几率、低反破坏效率、无需编辑的性质。论一个页面是否是高风险页面不仅仅是看这个页面是否是容易被破坏，而是要结合反破坏效率一起看。根据存档页极低的监视率，一旦受到鬼祟破坏（明显的破坏很可能会被最近更改巡查回退）则难以被发现。由于具有中等的可见度，不能保证阅览者里没有高级破坏者。并且，此类页面一般无需修改。而且，管理员也没有那么多精力盯着Special:未受监视页面看。综合以上所述，“无需编辑”的性质和维基百科的精神“人人皆可编辑”不冲突，加上此类页面是高风险页面（低反破坏效率并具有极高的信任度），我觉得应该实行保护。——꧁༺星耀晨曦༻꧂（留言） 2017年3月18日 (六) 09:27 (UTC)

始终不太同意，可见度比条目低，说是高风险都太过分，查看存档时自然也要先查看历史，查看历史自然便会找到鬼祟破坏。查看存档不事先查看历史是用的习惯有问题。--Maccomcre（留言） 2017年3月22日 (三) 00:18 (UTC)

有谁看任何一个页面都会去看编辑历史的？看一个页面的同时看编辑历史应该只是个别人的习惯。虽然这是一个好习惯，但你不能保证每个人都会去看编辑历史。同样，阁下也不能保证每个查存档的人都能发现鬼祟破坏。这就是为什么我认为存档页是“高风险”。——꧁༺星耀晨曦༻꧂（留言） 2017年3月22日 (三) 00:58 (UTC)

赞成保护。我同时赞成J.WONG的说法:"开放予众人编辑"的部分只限于那些编辑可以为维基带来好处的部分。编辑存档绝少对维基有好处。--Temp3600（留言） 2017年3月18日 (六) 10:46 (UTC)

===结案及公示===

1. 容许对存档页面设置永久半保护。

现公示七日。如无异议，即行修改。--Temp3600（留言） 2017年3月19日 (日) 10:10 (UTC)

• (－)反对，只是讨论了不够一星期便结案？太快了，而且讨论人数都少，中间还有人反对，根本不能当作有初步共识。--Maccomcre（留言） 2017年3月19日 (日) 11:48 (UTC)
  • @Maccomcre：那么，阁下觉得我上面说的话怎么样。——꧁༺星耀晨曦༻꧂（留言） 2017年3月21日 (二) 06:46 (UTC)
• 的确，过于仓猝，如果收窄范围至某几类存档或者只是经管理员评估过后觉得需要保护才施行永久全保护，又如何呢？--J.Wong 2017年3月19日 (日) 12:42 (UTC)
  • 用户讨论页的存档是否需要保护由该用户确认吧。——꧁༺星耀晨曦༻꧂（留言） 2017年3月19日 (日) 14:09 (UTC)
• 一位IP用户修改他人留言的编辑已被撤销。—john doe 120（talk） 2017年3月19日 (日) 15:11 (UTC)
• (－)反对，没必要这么做。除非存档页面被破坏多次，通常管理员会视情况实施保护。--小跃（捞出记录） 2017年3月22日 (三) 01:12 (UTC)
  • 阁下认为会有用户察觉到破坏？我觉得，除非有人盯着最近更改看，一个存档页被破坏者删了80%的破坏都没人会发现。——꧁༺星耀晨曦༻꧂（留言） 2017年3月22日 (三) 01:45 (UTC)
• 半保护会是一个可行方案。--1233|^联系我 2017年3月22日 (三) 06:57 (UTC)
• 讨论页存档的话我觉得全保护也没什么，本来就不需要编辑的地方。--浅蓝雪^❉ 2017年3月22日 (三) 15:47 (UTC)
• 我觉得还是容许永久半保护吧。全保护overkill。虽然现在想不到，但是如果真的出现需要编辑的情况，难道搞EP不成，现在EP处理比蜗牛还慢。Bluedeck 2017年3月25日 (六) 04:55 (UTC)
• 我想搞清楚，“临时保护”章节下的存档页是个什么情况。要不就是去掉这个条款（临时保护存档页本来就不应该出现在这里），要不就移动到“永久保护”章节。——꧁༺星耀晨曦༻꧂（留言） 2017年3月25日 (六) 10:06 (UTC)
• 应该移去永久保护。--J.Wong 2017年3月27日 (一) 03:49 (UTC)
• (＆)建议如果加个过滤器，用户编辑讨论存档页时予以标签，会否较省事？--578985s（留言） 2017年3月30日 (四) 15:49 (UTC)
  • 不省事吧。因为这得让人定期查看滥用日志。如果采用保护的方式，则可以利用机器人自动对存档进行保护。——꧁༺星耀晨曦༻꧂（留言） 2017年3月30日 (四) 16:29 (UTC)
  • 也是可以设立过滤器来收集数据，若然未能取得共识改修改方针，则此亦是可行之策。由其若然最后只设为半保护，则其实两者并行不悖。--J.Wong 2017年4月2日 (日) 01:04 (UTC)

小结

根据上面的讨论情况，有两位反对者，但也有一些支持意见。作为支持把“存档页保护”移动到“永久保护”的我来说，我有两个提案：

1. 把“存档页保护”移动到“永久保护”章节
2. 把“存档页保护”定性为“半保护”（提案2的前提是提案1）

我认为“存档页保护”在“临时保护”章节里就是一个错误，要不就移到“永久保护”要不就从WP:保护方针移除。不知道大家意见怎么样？并通知两位反对者user:小跃user:Maccomcre[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]——꧁༺星耀晨曦༻꧂（留言） 2017年3月28日 (二) 12:42 (UTC)

额，所以说，冷了？可以考虑公告一周无人反对就实施了？——꧁༺星耀晨曦༻꧂（留言） 2017年4月4日 (二) 07:45 (UTC)

就如此吧。--Temp3600（留言） 2017年4月4日 (二) 11:52 (UTC)

• 已开始公告。若一周后无人对上述提案提出反对意见，则移动具体条文到“永久保护”，并开启后续讨论（如何实施）。——꧁༺星耀晨曦༻꧂（留言） 2017年4月9日 (日) 16:07 (UTC)
• 赞成永久半保护。user:小跃user:Maccomcre[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]Bluedeck 2017年4月9日 (日) 21:29 (UTC)
• 若确实有需要，那永久半保护，是一个不错的办法。Wetrace欢迎参与人权专题 2017年4月27日 (四) 11:11 (UTC)

---

其实，我还想建议把用户讨论页的存档排除在外。或或者默认不保护用户讨论页存档，要让用户申请主动申请。——꧁༺星耀晨曦༻꧂（留言） 2017年4月10日 (一) 04:22 (UTC)

本提案可能与维基基金会政策有抵触

根据维基媒体基金会针对于半保护的规定：“Semi-protection ... is not intended for pre-emptive protection of articles that might get vandalized”（半保护…不是用来预防可能会发生的破坏），如果我理解无错的话，上面的提案应该是“即使存档没有破坏也可以半保护”，那么在无破坏时对存档实行半保护会违反上述规条，故即使上面提案有共识，基金会应该会行使WP:CONEXCEPT来阻止。这仅仅是我对于现在情况的理解，劳烦各位维基人（特别是行政员或以上权限的维基人user:Shizhaouser:Winguser:Kegnsuser:PhiLiPuser:Jimmy Xu[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]）确认一下本提案的合法性，谢谢。--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月10日 (一) 23:19 (UTC)

维基新闻的惯例是老新闻全保护--百無一用是書生 (☎) 2017年4月11日 (二) 02:25 (UTC)

个人见解，这个meta上的半保护页面似乎并不属于WP:CONEXCEPT所要求的基金会理事会公告。其次，半保护存档页面不太可能有实际危害到维基百科的风险，基金会不太可能出面阻止。--Wcam（留言） 2017年4月11日 (二) 02:48 (UTC)

如果基金会真的出面阻止的话，可以另外发新公告的嘛，所以仍有WP:CONEXCEPT的可能，当然出不出面阻止又是一回事了。--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月11日 (二) 04:47 (UTC)

已经有太多先例证明维基百科之中，不是所有页面都会开放予所有人编辑，包括“首页”、高风险模板、界面、.css/.js及他人用户页。存档页明显无任何编辑需要。还有别漏了“ARTICLES that might get vandalized”。WP:什么是条目--J.Wong 2017年4月11日 (二) 03:27 (UTC)

所以我在想元维基所谓Article究竟是否等于我们的WP:什么是条目，另外您举的基本上都是全保护的例，不是半保护（除了用户页(但这个通常在破坏发生后才会施行)）。又或者换句话说，如果上面结论是采用“全保护”的话，则应该无抵触；但采用“半保护”的话，则反而有抵触（如果他们所谓的Article包括所有页）。或者可否有熟悉基金会那边的人帮忙询问一下，免得他们真的出手阻止时场面会很尴尬。--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月11日 (二) 04:47 (UTC)

半保护的高风险模版比全保护的多很多。 --砜中嘌呤的白磷_{萃取 打谱} 2017年4月11日 (二) 05:01 (UTC)

照上文下理推断，很难相信articles并非条目，尤其下面加上“in english wikipedia”。--J.Wong 2017年4月11日 (二) 05:24 (UTC)

但是元维基上的政策页面也是放在主名字空间的说……另已见元维基相关询问已被提出，期待他们的答案。--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月11日 (二) 06:54 (UTC)

该文二○○五年建立之后一直就无太大变化，一○年加入meta:Category:Wikimedia_policies_and_guidelines。但翻查纪录，当年该用户是在整理页面分类，所以他同时亦将其他页面加入相应分类。而到底此文有否经过讨论呢，讨论纪录则遍寻不获。难道未经过讨论就可以成为全域方针？而真正全域方针亦似乎另有分类，正是meta:Category:Global_policies，内有各项全域方针正正影响着众多计划及规范着诸位参与者。--J.Wong 2017年4月12日 (三) 16:54 (UTC)

唯有等他们之后怎么答复吧，如果确认了该页本身有问题，又或一周后都无人答复的话，那就当本案没有问题了。--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月12日 (三) 21:46 (UTC)

• 元维基的一位管理员已回复：m:Semi-protection顶多当论述来用。而且这位管理员还给这个提案提了一个建议(Re "pre-emptive")。——꧁༺星耀晨曦༻꧂（留言） 2017年4月13日 (四) 02:21 (UTC)
  • OK，那么就当本案没有与政策抵触，可以继续公示。（话说元维基在最后给的建议似乎在暗示不太希望我们为了预防破坏而进行半保护？）--街燈電箱150號 开箱维修 抄表 检验证明 2017年4月13日 (四) 03:19 (UTC)
  • 他是在提议用过滤器解决，个人认为两者都可行。现时个人倾向半保护加过滤器。--J.Wong 2017年4月13日 (四) 04:06 (UTC)
    • 如果采用半保护，那么过滤器只用设置为标记标签就可以了。——꧁༺星耀晨曦༻꧂（留言） 2017年4月13日 (四) 15:43 (UTC)

两个方案

翻查纪录，该项明显是翻译出错，该句应该是指现时保护方针“历史只读”，即保护临时复还页面以便进行存废复核讨论，完全无关于讨论页存档。在加上参考其他保护项目及上列讨论以后，建议两个方案︰一、存档保护设为永久全保护，经评估或申请后实施，类似于高风险模板；二、使用编辑过滤器标签编辑并提示用户，如非必须，勿作编辑。--J.Wong 2017年4月11日 (二) 04:53 (UTC)

我个人认为半保护即可。而且我还认为除了个人用户讨论页之外的讨论页不需要申请就可以实施保护。——꧁༺星耀晨曦༻꧂（留言） 2017年4月11日 (二) 05:24 (UTC)

• 当下是什么情况(๑❛ᴗ❛๑^?)。现在已经证明存档页保护不会受到全域方针的影响。现在的分歧就在，保护的程度(全/半保护)。我个人是偏向半保护，并建议存档页保护默认不保护用户讨论页存档。——꧁༺星耀晨曦༻꧂（留言） 2017年4月16日 (日) 12:26 (UTC)
• 半保护加过滤器标签。--J.Wong 2017年4月16日 (日) 12:31 (UTC)

---

目前的情况，无后续意见。那么又公告一周。如果无反对意见，则认为以下条款：

1. 启用“存档页保护”
2. 对除个人用户讨论页存档以外的存档进行保护
3. 程度:半保护，保护时间:永久
4. 采用滥用过滤器来标签编辑存档的行为

具有社群共识。——꧁༺星耀晨曦༻꧂（留言） 2017年4月17日 (一) 03:21 (UTC)

楼上JWong君不是一直在说过滤器么。 --砜中嘌呤的白磷_{萃取 打谱} 2017年4月17日 (一) 06:00 (UTC)

对对，过滤器。已添加。——꧁༺星耀晨曦༻꧂（留言） 2017年4月17日 (一) 08:50 (UTC)

共识形成

历经多个月的讨论后，此方案在多次确认下，得到社群的共识，因此，存档页保护成为方针的内容，将写进WP:保护方针里。接下来就应该讨论讨论如何去保护中文维基百科里大量的存档。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:13 (UTC)

已加入保护方针中。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:35 (UTC)

后续讨论:对User talk下的讨论存档的处理

我建议采用“默认不保护，需用户主动申请”的形式。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:33 (UTC)

同意。而互助客栈等的讨论，则应以admin-bot批量保护。--Temp3600（留言） 2017年4月29日 (六) 16:31 (UTC)

可能需要技术猿。——꧁༺星耀晨曦༻꧂（留言） 2017年4月29日 (六) 20:13 (UTC)

• 咦。明明正值夏日，为什么空气那么冷。——꧁༺星耀晨曦༻꧂（留言） 2017年5月9日 (二) 15:30 (UTC)
• 不如让用户自行选择要不要保护。——Morgan Siu（对话｜贡献） 2017年5月10日 (三) 06:03 (UTC)
• (＋)同意。若能不需申请，直接做成一个自动化的选项是最好的。例如在讨论页上放置一个模板，机器人侦测到此模板即自动保护等。—以上有签名的留言由R96340（对话）于 加入。 2017年5月11日 (四) 04:30 (UTC)
  • 有没有可能不用机器人，直接授权用户自行保护用户讨论页存档，好像编辑提示（普通用户可以编辑自己用户页的编辑提示，其他页面则需要管理员才可以）——Morgan Siu（对话｜贡献） 2017年5月11日 (四) 06:11 (UTC)
    • 那也可以设置一个过滤器，其中包含一份用户讨论页存档名单，只允许管理员和讨论页对应用户编辑。想加入名单者可以去Wikipedia:防滥用过滤器/过滤器请求或者另开专页申请。这样的好处是讨论页存档名称有规律时，可以用正则表达式方便地匹配所有存档页。 --砜中嘌呤的白磷_{萃取 打谱} 2017年5月11日 (四) 07:22 (UTC)
      • 那就不如更进一步，授权用户自行选择要不要保护其用户页及其子页面。——Morgan Siu（对话｜贡献） 2017年5月12日 (五) 02:21 (UTC)
      • 此提议建议另开一段讨论，因为上面未曾讨论是否容许用户自行保护其用户页及其子页，而且牵涉到其他方针，包括《用户页方针》。--J.Wong 2017年5月12日 (五) 03:04 (UTC)

建议授权用户自行保护及删除自己的用户页及其子页面（用户对话页除外）

这样可以减轻管理员的工作量，反正用户页对其他人来说也没有编辑需要。——Morgan Siu（对话｜贡献） 2017年5月12日 (五) 06:08 (UTC)

把任何没有移动保护的页面移动到用户页后删掉，用户对话页也可以删了。--A2093064#Talk 2017年5月14日 (日) 13:27 (UTC)

@A2093064：对所有用户对话页实施移动保护。——Morgan Siu（对话｜贡献） 2017年5月15日 (一) 06:11 (UTC)

@Morgan Siu：那么所有条目也要移动保护吗，还有有些人会用移动讨论页来进行存档。--A2093064#Talk 2017年5月15日 (一) 06:35 (UTC)

@A2093064：只允许移动至用户讨论:Example/存档，或必须到移动请求进行。——Morgan Siu（对话｜贡献） 2017年5月15日 (一) 06:56 (UTC)

@Morgan Siu：那么条目移动到用户页呢。--A2093064#Talk 2017年5月16日 (二) 00:43 (UTC)

@A2093064：禁止条目移至用户页。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 03:31 (UTC)

@Morgan Siu：您的意思应该是要禁止非用户空间移到用户空间。那么有时新加入的维基人偶尔会在主条目空间误建用户页，这样的话其他用户就不能帮忙修正了。--A2093064#Talk 2017年5月16日 (二) 05:01 (UTC)

@A2093064：只是偶尔，可以到移动请求找管理员帮忙。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 05:04 (UTC)

@Morgan Siu：新的问题，如果有人在用户页广告又保护后，其他人就不能挂CSD G11了。--A2093064#Talk 2017年5月16日 (二) 05:07 (UTC)

@A2093064：不快速删除，用页面废存讨论。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 05:09 (UTC)

@Morgan Siu：本来应该快速删除的东西，为何要退而求其次存废讨论呢？--A2093064#Talk 2017年5月16日 (二) 05:10 (UTC)

@A2093064：保护用户页的好处比坏处多，就好像保护一个条目必定会阻止建设性编缉。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 05:14 (UTC)

@Morgan Siu：看看Wikipedia:条目所有权#用户页。--A2093064#Talk 2017年5月16日 (二) 05:23 (UTC)

@A2093064：没话可说，还原基本部：建议要申请才保护用户讨论页存档。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 05:28 (UTC)

• 从编辑需求出发感觉可行。并建议禁止用户保护具有讨论性质的用户页(即使不是用户讨论页)。不过这真的技术上做得到吗？我倾向“个人亲自去Wikipedia:请求保护页面申请”。——꧁༺星耀晨曦༻꧂（留言） 2017年5月15日 (一) 07:16 (UTC)

(－)反对，PER A209306 提到的条目所有权。维基人有权利编辑全站页面，甚至 MediaWiki 站点文本这些特殊内容有共识也可以修改。就算一般没有理由编辑用户页面，也不应该加以限制。有针对一个用户的破坏再批量临时半保护也不迟。

• 条目所有权方针: “用户页不是个人主页，并非用户所有”，“他们也有权编辑您的用户空间的其他页面”。
• 用户页指引: “不过空间的所有权还是归维基团体所有”，“其它用户也可以编辑你的空间”。

Dargasea^{t ‧ c ‧ s} 2017年5月16日 (二) 05:34 (UTC)

那么我也收回之前的建议。——Morgan Siu（对话｜贡献） 2017年5月16日 (二) 05:46 (UTC)

后续讨论:如何批量对除User和User talk以外的讨论存档进行保护

由于保护需要管理员权限，而且人工一个个保护太没有效率了，我建议开发一个admin-bot出来，批量保护。——꧁༺星耀晨曦༻꧂（留言） 2017年5月15日 (一) 07:20 (UTC)

• 我的意思是授权，不用任何人帮忙。可以问一下维基技术人员，应该可行。除了用户对话页，还会有讨论性质的用户页吗？——Morgan Siu（对话｜贡献） 2017年5月15日 (一) 10:10 (UTC)

上面是上回讨论。简而言之就是对除用户讨论名字空间(User talk:)下的存档页以外的讨论页面存档页进行永久半保护。此项已有社群共识，但没有具体实施方案从而搁置。我想放在这里，来看看有没有技术大佬来实现这个共识。我觉得，可以开发一个管理员机器人来批量保护。——꧁༺星耀晨曦༻꧂（留言） 2017年8月9日 (三) 16:28 (UTC)

[[::頁面名]]不再能连到条目

请问最近有什么变更使得 [[::頁面名]] 这样的语法无法再连结到页面呢，效果显示为 页面名 。我刚刚修复了一个长久以来正常的模板，但突然出现的错误，我相当怀疑是这个问题，我的编辑：1、2、3。--A2093064#Talk 2017年7月31日 (一) 13:57 (UTC)

[[::页面名]]不行，不过[[:页面名]]是可以的。页面名。（我好像没有见过[[::页面名]]这样的语法。）--SolidBlock^留言 2017年8月5日 (六) 05:12 (UTC)

虽然不标准，但这之前好像是可以的。--A2093064#Talk 2017年8月5日 (六) 06:23 (UTC)

可以使用[[:{{FULLPAGENAME::页面名}}]]：页面名。这样就可以保证创建链接了。--SolidBlock^留言 2017年8月7日 (一) 08:39 (UTC)

我猜你是不是搞错了？[[::頁面名]]以前能被解析器修正为[[:頁面名]]，现在可能规范过不行了，[[::頁面名]]的写法主要有一些模板会冒号之间插入旗标或者命名空间名，不插入的话就是直接可以指向主空间，以前的取巧写法，现在嗝屁了。——路过围观的Sakamotosan 2017年8月10日 (四) 01:00 (UTC)

是，应该是做了某些修正，使得两个冒号不再被当成一个冒号连结。--A2093064#Talk 2017年8月10日 (四) 01:05 (UTC)

在繁体模式下被调用了简体字型

请问系统是否又更新了？请尽快修正，谢谢 --Moonian‧^{♨一盅两件立即叹}‧_贡献 ^主要 _全部 2017年8月11日 (五) 01:16 (UTC)

能举个例子吗？--百無一用是書生 (☎) 2017年8月11日 (五) 01:31 (UTC)

再稍为研究一下，发现可能是浏览器的问题，因为Google搜索也有问题（Firefox 56b1，Chrome似乎没事）。抱歉打搅了！ --Moonian‧^{♨一盅两件立即叹}‧_贡献 ^主要 _全部 2017年8月11日 (五) 01:48 (UTC)

简繁转换错误？

你是主人我是仆，具体看IP用户的编辑注释留言 --我是火星の石榴（留言） 2017年8月7日 (一) 09:17 (UTC)

CJK Unified Ideographs Extension C里有“鍊”的类推简化字“𫔀”（⿰钅柬，U+2B500），Unicode还没收录把“拣”的偏旁换成“钅”的那个字（说起来真麻烦😒）。-- By Jimmy Young. (Talk) 2017年8月11日 (五) 05:36 (UTC)

文档内容调用模块时参数失效但直接调用则正常

参见testwiki:Template:Rub，在testwiki:Module:Ruby中，我将mw.getCurrentFrame():getParent().args的内容转换到args（表），然后在testwiki:Template:Rub/doc调用Rub模板，发现一切正常，mw.getCurrentFrame():getParent().args的域规规矩矩到了args中，但是如果是在Template:Rub页面用{{doc}}的形式查看，发现模板出现了异常，args完全变成了一个空表。但是直接使用{{Template:Rub/doc}}发现结果是正常的。不知道是不是模块:Arguments有什么问题。如果我将原模块中的mw.getCurrentFrame():getParent().args用模块:Arguments的相应方法代替，反而无论是间接查看文档还是直接查看文档页面都会出错。所以希望Lua高手帮忙修复一下。--SolidBlock^留言 2017年8月11日 (五) 09:58 (UTC)

建议给小工具中的RefToolbar 2.0的cite web增加dead-url参数

小工具里面有一个快捷插入参考文献模板的工具，即en:WP:RefToolbar 2.0，其中的cite web建议增加dead-url=这个参数，可以填yes来表示原连结已失效或填no来表示原连结未失效，详见此，最好是能够做成选项按钮啦。至于yes跟no的不同之处就在于那句“原始内容存档于YYYY-MM-DD”跟“原始内容存档于YYYY-MM-DD”。由于在下电脑水平有限，希望有人能帮忙增加此功能，谢谢。 --dqwyy（谈笑风生）^{環状線を走り抜けて}_{回复请ping/mute我} 2017年8月12日 (六) 13:55 (UTC)

(＋)滋磁

，咱一直手动加“|deadurl=no”的说。。。。--⌬胡萝卜 _{热烈庆祝化学成为动员令主题} 2017年8月12日 (六) 13:57 (UTC)

Chrome终于支援zh-hk

可能是旧闻，但也分享一下。Google Chrome自推出以来多年，语言设定长期只设“中文（繁体）”（zh-tw）及“中文（简体）”（zh-cn）两项，不设zh-hk，导致在未登入情况下浏览中文维基百科时，不可能自动显示“香港繁体”，至少到2017年初还是如此。然而，在过去数个月的某次更新中，Chrome的语言设定终于加入了“中文（香港）”（zh-hk）的选项。故香港的Chrome使用者只要预先设定使用“中文（香港）”，在未登入情况下浏览中文维基百科时便可自动显示“香港繁体”。--Kevinhksouth (Talk) 2017年8月13日 (日) 13:20 (UTC)

模板表格的绘制

请问如何绘制出如下表格：

查·论·编	XX化合物				[隐藏]
元素周期表区域
属性α的化合物	化合物A、化合物B
属性β的化合物	化合物C、化合物D、化合物E

（效果如上图所示，但没有表格的边框线）

即将（1）类型1（周期表式）（2）类型2（分类模板式）这两种类型的模板整合在一起。（点击蓝链查看模板）--Leiem（留言） 2017年8月13日 (日) 05:48 (UTC)

直接拼好像就行了。 --砜中嘌呤的白磷_{萃取 打谱} 2017年8月14日 (一) 01:06 (UTC)

thanks --Leiem（留言） 2017年8月14日 (一) 02:10 (UTC)

音频播放的问题

例如Help:IPA条目中有很多音频文件，播放声音的时候会打开新页面。有没有什么办法点击播放后在原页面播放的？--Leiem（留言） 2017年8月14日 (一) 07:40 (UTC)

Win 10.1 系统，Chrome浏览器。--Leiem（留言） 2017年8月14日 (一) 07:46 (UTC)

Tech News: 2017-33

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

最近更新

• 行政员现在可以将用户标记为已确认。以前只有监管员能在大部分wiki上实现这一点。之前允许管理员将用户标记为已确认的wiki不受影响。 [12]

问题

• 语言列表中显示对应语言版本条目是优良或特色条目的图标无法工作。边栏中链至共享资源分类的链接同样无法工作。开发人员正在修复这一问题。 [13][14]

本周更新

• MediaWiki的新版本将于8月15日部署于测试维基及MediaWiki.org。它将于8月16日部署至非维基百科wiki及部分维基百科，并于8月17日部署至所有wiki，参见日历。

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

2017年8月14日 (一) 23:28 (UTC)

维基百科:关注度/提报中的Template:Find sources

由8月12日起，维基百科:关注度/提报中的Template:Find sources 全都不能显示。是出了什么问题？--Nivekin※请留言 2017年8月15日 (二) 02:42 (UTC)

展开上限。——路过围观的Sakamotosan 2017年8月15日 (二) 02:50 (UTC)

所以是那位提报了700多条目的朋友引起的问题？--Nivekin※请留言 2017年8月15日 (二) 03:05 (UTC)

估计是，这应该是findsource所能容纳的极限（使用Lua代替解析器函数后，现在模板输出结果就是最小的展开长度），突然有种SM当年的日子？（笑）——路过围观的Sakamotosan 2017年8月15日 (二) 03:14 (UTC)

有关Location Map的图片描述

在国家的层面来说并没有什么太大的问题。但是到了小一些的层面，如州、省、市、县等，使用Location map就会出现英文图片描述该州省市县。例子，点开位置的部分，图片的描述（游标停在图片上面的框框）。是否可以修复？--owennson（聊天室、奖座柜） 2017年8月14日 (一) 17:12 (UTC)

svg图片，自己改一下上传一个中文的不就好了，或者改成多语言支持的svg版也行--百無一用是書生 (☎) 2017年8月15日 (二) 01:25 (UTC)

我不擅长改图再上传，但如何改成多语言支持的svg版？--owennson（聊天室、奖座柜） 2017年8月15日 (二) 06:14 (UTC)

Infobox election出错？

我翻译了2017年百慕大大选,但不知何解在只加入一张选举地图时会显示四张一样的选举地图，请问是否Infobox election出错？Tom...........（留言） 2017年8月15日 (二) 07:26 (UTC)

@Tombus20032000： 已修复--A2093064#Talk 2017年8月15日 (二) 09:57 (UTC)

最近更改即将到来的最新变化

我们目前依靠最近更改头部进行广而告之的做法可能要改一改了--百無一用是書生 (☎) 2017年8月4日 (五) 02:10 (UTC)

meta被折叠的部分是放在m:MediaWiki:Recentchangestext，而我们是放在MediaWiki:Recentchanges-summary，对应m:MediaWiki:Recentchanges-summary都是不会被折叠的。--A2093064#Talk 2017年8月4日 (五) 02:16 (UTC)

啊，忘了中文版这一点上和别人不一样了。但是按照目前的新样式来看，MediaWiki:Recentchanges-summary风格太不协调了，而且太占地方，说白了就是有些难看--百無一用是書生 (☎) 2017年8月4日 (五) 02:31 (UTC)

建议将MediaWiki:Recentchanges-summary的内容放回MediaWiki:Recentchangestext--百無一用是書生 (☎) 2017年8月4日 (五) 04:12 (UTC)

MediaWiki:Recentchanges-summary is collapsed only for users who use the Beta feature 用于编辑复核的新过滤器. The goal is to have a clearer interface. People using the Beta just need to click to open the collapsed panel and it will remain open.

At the moment, you are missing all information contained on MediaWiki:Recentchanges-summary while using the Beta feature, because MediaWiki:Recentchanges-summary is not used by the Beta feature. You are the only wiki doing it. The best thing to do would be to move the content of MediaWiki:Recentchanges-summary to MediaWiki:Recentchangestext

If you have questions about this particular point, please contact me. :) Trizek (WMF)（留言） 2017年8月4日 (五) 10:46 (UTC)

完成--百無一用是書生 (☎) 2017年8月9日 (三) 04:15 (UTC)

@Shizhao：，根据功能来看，不如将公告栏，质量提升部分放入MediaWiki:Recentchanges-summary，其他工具按照说明放入MediaWiki:Recentchangestext，如何？——路过围观的Sakamotosan 2017年8月10日 (四) 06:30 (UTC)

新版最近更改的原意是要默认折叠最近更改的头部内容，除了MediaWiki:Recentchanges-summary。这样才是新版的完整体验。如果非要露出一些内容来，建议用小工具解决--百無一用是書生 (☎) 2017年8月10日 (四) 09:02 (UTC)

除非想到新地方放这个，不然还是保留的好，太常用了。--Temp3600（留言） 2017年8月11日 (五) 17:01 (UTC)

@Shizhao：最近最近更改头部出现一行以前没有的字“在本页面追踪本wiki的最近更改。”也跟本节讨论内容有关吧？看了下好像是MediaWiki:Recentchanges-summary从外部带来的，有必要修一下吗--Kegns（留言） 2017年8月14日 (一) 16:12 (UTC)

改成啥？--百無一用是書生 (☎) 2017年8月15日 (二) 01:19 (UTC)

去掉……--Kegns（留言） 2017年8月15日 (二) 23:26 (UTC)

关于使用Microsoft Edge编辑中文维基百科

如题，本人自月初改用Microsoft Edge浏览器，但每次编辑中文维基百科都和自己编辑冲突，有时显示编辑冲突，再按下储存仍然显示编辑冲突；如是者十几次后方能储存页。请问其他维基人有遇上同样或类似情况吗？谢谢！ 另外，当我使用Firefox浏览器编辑时，直至现时为止没和自己撞过编辑冲突。--​小枫庄园（后花园） 2017年8月15日 (二) 16:00 (UTC)

连点两次会跟自己编辑冲突，但是...这是浏览器的问题吗？--A2093064#Talk 2017年8月18日 (五) 04:41 (UTC)

最新页面的黄色背景消失了

于Phabricator内跟踪
任务T173556

如题，Special:最新页面里面把未巡查的标记为黄色背景，但刚刚看好像消失了。--A2093064#Talk 2017年8月18日 (五) 04:39 (UTC)

好像所有的wiki都出问题了--百無一用是書生 (☎) 2017年8月18日 (五) 06:35 (UTC)

Tech News: 2017-34

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

最近更新

• 您现在可以在测试维基和mediawiki.org测试新增的Timeless皮肤。您可以在您的参数设置中启用它。您也可以在Phabricator报告错误。这将很快来到更多wiki。 [15][16]
• 您的监视列表现在已有取消监视页面的选项。您需要在您的参数设置中打开它。 [17]
• 如果表格有多个列，您经常可以选择您要排序表格的列。这对于使用Firefox或Safari浏览器的用户而言，可能在某些表格列中无法工作。这一问题现已修复。 [18]
• 相关条目扩展已显示维基导游上的相关页面。您现在会在条目底部看到相关页面与图片。之前链接显示在边栏上。希望使用该扩展的wiki可在Phabricator提出请求。

本周晚些时候的更新

• 视频现将在所有浏览器中以WebM格式播放。之前一些浏览器使用Ogg Theora（.ogv）格式。如果您使用Safari、IE或Edge浏览器，您在播放高清视频时播放速度会比较慢。此后我们将使视频质量更高，文件大小更小。您仍可以上传Ogg视频文件。这些会自动转换为WebM。这并不影响Ogg音频文件。 [19]
• 编辑窗口中的默认字体将在本周为某些用户更改。它将不再是浏览器默认字体，而是等宽字体。用户可在其参数设置中更改它。此更改只应用于一些Mac和iOS设备用户。 [20]
• MediaWiki的新版本将于8月22日部署于测试维基及MediaWiki.org。它将于8月23日部署至非维基百科wiki及部分维基百科，并于8月24日部署至所有wiki，参见日历。

会议

• 您可以参与IRC上的技术建议会议。在会议中，志愿开发者可以征求建议。会议将于8月23日 15:00（UTC）开始。参见如何加入。
• 您可以参与下周编辑团队的会议。在会议中您可以告知开发人员哪些问题是最重要的。会议将于8月22日 19:00（UTC）开始。参见如何加入。

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

2017年8月21日 (一) 18:00 (UTC)

Timeless皮肤值得期待。--1=0，欢迎加入WP:维基百科维护专题 2017年8月22日 (二) 00:23 (UTC)

Timeless觉得用在维基百科会好难看，可能meta，commons，维基旅游比较合适--百無一用是書生 (☎) 2017年8月22日 (二) 01:29 (UTC)

MediaWiki的Lua问题

为什么MediaWiki网站（包括维基百科、miraheze）的模块控制台（交互式）与真正的Lua不同。在Lua中，直接一行变量名称即可输出此变量的值，而MediaWiki则会输出错误。此外，打印table或function的值时，为什么在MediaWiki不会显示其编号？如下图所示：

> "something"
something --Lua
错误 --MediaWiki
> ={}
table: 00988600 --Lua
table --MediaWiki
> =print
function: 64359190 --Lua
function --MediaWiki

个人觉得是MediaWiki使用的Lua版本太旧。--SolidBlock^留言 2017年8月24日 (四) 01:55 (UTC)

正式Lua像table、function的数字更像是内存地址，为了避免暴露，特制版应该隐藏了。至于String那个，不知想说明什么？——路过围观的Sakamotosan 2017年8月24日 (四) 02:11 (UTC)

正式的交互式Lua可以直接在一行输入一个值以表示print。例如，直接输入一行"sth"效果等价于="sth"或print"sth"。--SolidBlock^留言 2017年8月24日 (四) 02:15 (UTC)

特制版有不同吧，WP:LUA有提及，就算table，function的输出同样需要调用等号。——路过围观的Sakamotosan 2017年8月24日 (四) 02:44 (UTC)

新功能？（快速预览）

刚才在日文版（IP用户状态），部分页面里，鼠标指向一个蓝链词条，会跳出一个快速预览，还有一个页面功能设置按钮，但部分页面又没有，这到底是怎么回事？

Get quick previews of a topic while reading a page

刚才我登陆状态看了一下自己的用户设置，好像也没有对应的项目？

我关心一点，近期有没有可能全wiki部署，并且默认启用状态？--我是火星の石榴（留言） 2017年8月21日 (一) 15:39 (UTC)

你说的是mw:Beta Features/Hovercards吧？--1=0，欢迎加入WP:维基百科维护专题 2017年8月21日 (一) 15:47 (UTC)

是，目前啥情况？简单看了一下，在进行A/B轮测试？ja已经算完成了？（但为什么只有部分页面才有）--我是火星の石榴（留言） 2017年8月23日 (三) 05:38 (UTC)

在中文维基应该可以通过参数设置的测试打开。打开以后应该就能用了吧。--1=0，欢迎加入WP:维基百科维护专题 2017年8月23日 (三) 07:19 (UTC)

这是哪一项啊？看着好像没有？--我是火星の石榴（留言） 2017年8月24日 (四) 06:00 (UTC)

Beta feature: advanced filters and more options for Watchlists, starting September 5

Hello!

Sorry to write in English. 请帮助翻译至您的语言!

As you may already know, the Global Collaboration team has created a Beta feature. This feature is on your wiki since few months: "用于编辑复核的新过滤器". You can activate it in your Beta preferences.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked. It adds new features that ease vandalism tracking and support of newcomers:

• Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
• Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
• Bookmarking to keep your favorite configurations of filters ready to be used.
• Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help.

You can know more about this project by visiting the quick tour help page.

What's new?

On September 5, the Beta feature will have a new option. Watchlists will have all features available now on the Beta Recent Changes improvements.

If you have already activated the Beta feature "用于编辑复核的新过滤器", you have no action to take. If you haven't activated the Beta feature "用于编辑复核的新过滤器" and you want to try the filters on Watchlists, please go to your Beta preferences on September 6. It will not be possible to try the filters only on Recent Changes or only on Watchlist.

Please also note that later in September, some changes will happen on Recent Changes. We will release some features at the moment available in Beta as default features. This will impact all users, but we will provide an option to opt-out. I'll recontact you with a more precise schedule and all the details very soon.

You can ping me if you have questions.

All the best, Trizek (WMF)（留言） 2017年8月24日 (四) 15:59 (UTC)

提议更改内容展开/合并功能的“合并”一词为“收起”

只是点小意见，对于“合并”一词在此处出现感到不自然而已。—以上有签名的留言由R96340（对话）加入于 2017年8月24日 (四) 07:07 (UTC)

可是我看到的是显示/隐藏。-游蛇脱壳/克劳棣 2017年8月24日 (四) 07:53 (UTC)

...

...

...

两个预设不一样（请见源代码）。--A2093064#Talk 2017年8月24日 (四) 08:41 (UTC)

呃！我现在看到的是展开/折叠，并无合并。另外，代码那么复杂干嘛？用{{hideH}}与{{hideF}}就好啦！-游蛇脱壳/克劳棣 2017年8月24日 (四) 16:43 (UTC)

PRC Admin 导航模板的小 bug

2017年8月10日，有编者在 Wikidata 浙江省条目中的“所在行政区”属性新增了“清朝，终于1912年2月12日”这一值，导致浙江全省各区导航模板 above 区域出现了诸如“清朝浙江省宁波市”这样奇怪的内容，已暂时删除相关属性，但考虑到增加带有“终于……”的值并没有什么问题，PRC Admin 导航模板是不是应该修复这一bug。—思域无疆_{大道 事体 机器} 2017年8月22日 (二) 22:41 (UTC)

• 另外国函[2015]75号相关的常州市行政区划没有跟进。—思域无疆_{大道 事体 机器} 2017年8月22日 (二) 23:11 (UTC)
• 而且从2015年至今中国区级行政区划大量调整，现有模板和数据维护门槛过高，我自己调整过宁波市4个区的区划相关模板，耗费大量时间移动相关的村一级模板和区划代码，可以想见由于区划调整造成的烂尾楼绝对不止常州市一个，应当有更高效的维护方法。—思域无疆_{大道 事体 机器} 2017年8月22日 (二) 23:15 (UTC)
  • 如果你能提供一个具有相同条件的修改方式可以至机器人作业请求请机器人协助。--Zest 2017年8月23日 (三) 16:40 (UTC)
• @Siyuwj： 正确的修复错误的方法不是移除数据而是修改Rank，例如这样。这不是导航模板的错误。--GZWDer（留言） 2017年8月24日 (四) 19:40 (UTC)
  •  Siyuwj觉得这挺赞的。—思域无疆_{大道 事体 机器} 2017年8月25日 (五) 00:24 (UTC)

给“显示预览”按钮增加地区字词转换菜单的小工具无效

启用该小工具后，虽然在“显示预览”按钮边显示出了转换菜单，但是无论在菜单中选择哪一项，效果都与未开启小工具前无异，显示的都是我在Special:参数设置中指定的语言变种。——Arnie97（留言） 2017年8月25日 (五) 13:00 (UTC)

User:Liangent我所使用的是正常的。按道理来说，可以启动或不启动实时预览。我是使用了实时预览的。--SolidBlock^留言 2017年8月25日 (五) 13:48 (UTC)

为什么在IE和手机QQ浏览器下无法正常使用TW

RT，两个方案（参数设置里的原版和天邪鬼版本）都不行，连脚本都加载不出，但是Firefox就能正常使用。--Dabao qian（留言） 2017年8月26日 (六) 01:36 (UTC)

• (～)补充：我错了，IE是本身就不支持，但是手机QQ浏览器本来是能用的啊，怎么说不行就不行了。除此之外，编辑首段，还有紧凑语言链接和内容翻译工具等测试功能也在手机QQ浏览器上显示不出来了。--Dabao qian（留言） 2017年8月26日 (六) 01:53 (UTC)
  • TW不能在IE浏览器中使用是开发者自行设定的限制。我在自己的版本中把限制解除了，但是，如果问题只在IE中出现，或者因为使用IE浏览器而导致错误编辑，您需要自行承担责任。--逆袭的天邪鬼（留言） 2017年8月26日 (六) 03:18 (UTC)
    • IE是只有TW不能用，其他脚本和测试功能都正常；手机QQ浏览器好多脚本和大部分测试功能都挂了。--Dabao qian（留言） 2017年8月26日 (六) 03:21 (UTC)
      • 我诊断不了手机浏览器的问题，只能让别人想办法了。不过呢，您可以再试试“天邪鬼版本”的TW……--逆袭的天邪鬼（留言） 2017年8月26日 (六) 03:29 (UTC)
        • 本来坏的还没那么多来着，刚刚手贱清除了浏览器缓存，甚至重装浏览器，结果除了W+其他小工具全挂了。（试了下，不止中文维基，包括粤语、吴语、日语在内的好多语言版本的wiki都是一个毛病，除了W+之外其他所有基于javascript的小工具在手机QQ浏览器全部加载不出来，就连ilh和NavFrame这种默认全局启用的也不行，目前正常的网站只有英文维基、C区和D区）--Dabao qian（留言） 2017年8月26日 (六) 04:30 (UTC)

显示Wikidata描述的小工具新鲜出炉

一直以来，维基百科手机app以及移动版都会在条目顶端附近显示维基数据的描述，而桌面版缺少这一功能。我今天下午制作了一个小工具弥补这一缺陷，大家可以试用一下。

importScript('User:Alexander Misel/WikidataDesc.js');

--1=0，欢迎加入WP:维基百科维护专题 2017年8月8日 (二) 02:06 (UTC)

https://img.vim-cn.com/fb/0a7f9427a7f65b6cccfc6684e888ca0ea5708d.png 看来可以用 😂 ホロ|Talk 2017年8月10日 (四) 09:25 (UTC)

app的菜单里有个编辑描述，要不要也加个编辑功能。 --砜中嘌呤的白磷_{萃取 打谱} 2017年8月10日 (四) 14:52 (UTC)

User:WhitePhosphorus我确实希望有这个功能，但不太会制作界面。我当时打算的是用这个api。界面我想象的是像HotCat那样的。--1=0，欢迎加入WP:维基百科维护专题 2017年8月11日 (五) 00:34 (UTC)

震惊！该工具目前已支持在页面直接编辑维基数据的描述！！！感谢User:逆袭的天邪鬼的贡献。--1=0，欢迎加入WP:维基百科维护专题 2017年8月13日 (日) 11:14 (UTC)

提议此工具加入中文维基小工具列表

User:ArthurLau1997、User:Ken Ookami Horo、User:Manchiu、User:Wang Qiliang和User:Alvinz 提议加入到Special:Preferences中的系统小工具页面。--1=0，欢迎加入WP:维基百科维护专题 2017年8月18日 (五) 10:46 (UTC)

User:S099001、User:Njzjz、User:Aotfs2013、User:鱼头炮和User:RabbitMeow欢迎大家反馈意见。--1=0，欢迎加入WP:维基百科维护专题 2017年8月18日 (五) 10:50 (UTC)

User:Wcam、User:Datou 1996、User:逆袭的天邪鬼、User:A2093064和User:Willy1018并参与讨论。--1=0，欢迎加入WP:维基百科维护专题 2017年8月18日 (五) 10:54 (UTC)

满不错的，不过放系统小工具应该弄个简单的说明页，并提醒用户会编辑到Wikidata。--A2093064#Talk 2017年8月18日 (五) 11:04 (UTC)

• (＋)支持：首先感谢编写者的贡献。我已试用一段时间，这确实是一个好用的功能。此功能大大方便了对维基数据描述的编辑，同时也有利于阅读者。我支持将之加入小工具列表。
  此外，我希望各位同仁考虑和讨论的是：是否应该对此设计某些保护措施。这个功能大大方便了对维基数据描述的编辑，这就意味着它既大大方便了维基数据的维护，也大大方便了对它的破坏。故此提出这个问题。我提出一些思路供各位参考，例如：维基百科的页面保护方针是否可以对该页面上用此工具进行维基数据描述的编辑行为生效？或者如果维基数据支持保护功能的话，是否可以设计一个程序或由维基人将有风险的维基数据描述保护起来？或者不需要技术性保护措施，依靠维基人进行监督维护就可以反破坏？
  这是我目前想到的问题，希望各位考虑。在下加入维基时间不长，资历尚浅。欢迎各位资深用户指导、帮助，不胜感激。--ArthurLau1997（留言） 2017年8月18日 (五) 11:29 (UTC)
• (＋)支持，真的是一个很实用的工具，引入到系统gadget想必是坠吼的。另外楼上所说的反破坏问题的确值得考虑。--RabbitMeow ∞ 谈笑风生通道 _{一秒的魔法，万寿之吾江！} 2017年8月18日 (五) 12:07 (UTC)
• (？)疑问：这个小工具是似乎只能从zh读取数据，不支持从zh-hans，zh-hant，zh-CN，zh-TW，zh-HK等转写？例如南京市，这个小工具加载不出来描述，但是在维基数据里面如果选zh语言，就能看到label为：中国江苏省省会^{简体中文（已转写）}。--曾晋哲（留言） 2017年8月18日 (五) 12:31 (UTC)
• (＋)支持，不过如果能调整一下小工具的触发方式就更好了（现在稍微有点灵敏，随便一点那个区域就弹出来了）。--Jerre Jiang 　讨论│参与清理积压站务　 2017年8月18日 (五) 14:19 (UTC)
• (＋)支持:同上所述，建议支持转写显示--Wang Qiliang · 一起来巡查 · 留言板 2017年8月19日 (六) 03:54 (UTC)
• (＋)支持--Alvinz ^论 2017年8月19日 (六) 10:46 (UTC)
• (＋)支持为什么不呢--Liuxinyu970226（留言） 2017年8月20日 (日) 12:41 (UTC)
• (＋)支持:是个好用的小工具。水可煮粥，亦可赛艇 ^{听取蛙声一片 人生经验} 2017年8月20日 (日) 17:53 (UTC)
• (＋)支持，相当实用的小工具。应尽快添加至界面。--千村狐兔（留言） 2017年8月21日 (一) 00:34 (UTC)
• (＋)支持实用的小工具。-- Willy1018（留言） 2017年8月21日 (一) 06:48 (UTC)
• (＋)支持实用的小工具。--Wang Qiliang · 留言 2017年8月26日 (六) 08:55 (UTC)

1=0的回复

1. 我个人不太支持获取维基数据上的中文语言变种的转写。如果都来编同一个变种（zh），那么我们能很快得到完善的维基数据描述，不管对于简体编者关注的方面还是繁体，就像中文维基只有一个一样。
2. 关于容易编辑了，也容易破坏了这一点。我认为，页面保护同样运用在小工具上不是做不到，只是这其实是在插手其他站（Wikidata）的维护工作。我们能做到的也许是不默认开启此小工具。
3. 小工具过于灵敏这一点我认为近期我们就可以解决。（已处理）
4. 小工具的提示文字建议为“显示与编辑页面的维基数据描述的工具。由于技术限制，显示结果不会进行简繁转换，请不要把原有描述在繁简上进行更改。”

以上--1=0，欢迎加入WP:维基百科维护专题 2017年8月19日 (六) 08:12 (UTC)

为何不直接转成简体、繁体和zh同时保存呢？--百無一用是書生 (☎) 2017年8月22日 (二) 09:17 (UTC)

因为有地区词的问题，所以觉得还是暂时不加此功能为好。--1=0，欢迎加入WP:维基百科维护专题 2017年8月24日 (四) 03:05 (UTC)

记得有个繁简转换的API啊，不支持地区词转换吗？--百無一用是書生 (☎) 2017年8月24日 (四) 03:30 (UTC)

小工具已加入列表

小工具目前已加入系统的小工具列表。User:Alexander Misel/WikidataDesc.js这个用户js页面将会保留，作为测试小工具和老用户迁移之用。小工具加入之事已在公告栏进行公告。有问题请及时反馈给我。--1=0，欢迎加入WP:维基百科维护专题 2017年8月24日 (四) 03:05 (UTC)

测试功能“内容翻译”的时区处理有误

以本地时区 UTC+8 为例，刚编辑过的页面会显示为 8 小时前编辑。——Arnie97（留言） 2017年8月27日 (日) 03:35 (UTC)

importScript返回403？

今日本人修改自己的common.js发现所有引入的文件返回403。

Request URL:https://zh.wikipedia.org/wiki/User:Wang_Qiliang/wikiplus.js?action=raw&ctype=text%2Fjavascript
Request Method:GET
Status Code:403 
Remote Address:91.198.174.192:443
Referrer Policy:origin-when-cross-origin

不清楚这是什么情况。请求帮助。--Wang Qiliang · 留言 2017年8月26日 (六) 08:57 (UTC)

补充：似乎这种地址就正常了：

Request URL:https://zh.wikipedia.org/w/index.php?title=User:Wang_Qiliang/wikiplus.js&action=raw&ctype=text/javascript
Request Method:GET
Status Code:200 
Remote Address:91.198.174.192:443
Referrer Policy:origin-when-cross-origin

--Wang Qiliang · 留言 2017年8月26日 (六) 09:00 (UTC)

貌似 已修复。--Antigng（留言） 2017年8月27日 (日) 04:37 (UTC)

刚刚看了似乎没有 已修复。--Wang Qiliang · 留言 2017年8月30日 (三) 04:01 (UTC)

$langcode.wikipedia.org/zh 中的 zh 为何义？

例如“en.wikipedia.org/zh”，直接转入该语言版本的首页。我试了除“w”与“wiki”之外的任何英文字母/单词都是“Page not found”。我以为此处的“zh”代表语言代码，但似乎并不是，若不信你们可以试试“en”、“ja”、“ko”、“ru”等任何语言代码。-- By Jimmy Young. (Talk) 2017年8月30日 (三) 12:02 (UTC)

不一定： https://en.wikipedia.org/wiki/Ru --巡查员AndyAndyAndyAlbert（讨论页|签到） 2017年8月30日 (三) 12:07 (UTC)

@AndyAndyAndyAlbert：请审题。你写的是“wiki/Ru”，不是“Ru”。-- By Jimmy Young. (Talk) 2017年8月30日 (三) 12:09 (UTC)

就是繁简转换的url重写，你可以理解为zh.wikipedia.org/(zh-cn)/$1 -> zh.wikipedia.org/w/index.php?title=$1&variant=zh-cn。——路过围观的Sakamotosan 2017年8月30日 (三) 12:11 (UTC)

唷！我竟然把它忘记了（脑子瓦特了，羞 --  By Jimmy Young. (Talk) 2017年8月30日 (三) 12:15 (UTC)

让维基变成黑底绿字的小工具现已支持vector皮肤

经过我从英文维基借鉴以及修改，该小工具不再只支持monobook皮肤，现已支持vector皮肤。大家可以在参数设置-小工具中启用。效果如右图。 --1=0，欢迎加入WP:维基百科维护专题 2017年8月26日 (六) 08:00 (UTC)

我先前稍微试用了一下，很好看，唯一的缺点是会让使用者名称旁的两个通知图示消失。--冥王欧西里斯（留言） 2017年8月31日 (四) 02:46 (UTC)

希望引入enwiki的File Upload Wizard

中文维基的Wikipedia:上传界面难看，且给人一个空模板让别人填，不必要地增大了上传文件的难度。假如一个新手，不懂代码，也不懂什么是模板，是否就传不了文件了呢？不得不说，在现在这个时代，文件上传向导（File Upload Wizard）是大势所趋。在C区人们也常常会使用类似的向导来上传文件。希望有人对此提议感兴趣。--1=0，欢迎加入WP:维基百科维护专题 2017年7月27日 (四) 10:23 (UTC)

相关过往讨论供参考：提议引入但不了了之、改上传界面的排版。 --砜中嘌呤的白磷_{萃取 打谱} 2017年7月27日 (四) 10:26 (UTC)

之前讨论过，在下也表示支持，不过最后不了了之，不知是否存在技术上的问题。--Jerre Jiang 　讨论│参与清理积压站务　 2017年7月27日 (四) 10:47 (UTC)

需要去P站提请求吧。——꧁༺星耀晨曦༻꧂（留言） 2017年7月27日 (四) 11:59 (UTC)

唉，等等。英文维基百科的File Upload Wizard不是Upload Wizard扩展，是用JS写的脚本。——꧁༺星耀晨曦༻꧂（留言） 2017年7月27日 (四) 12:30 (UTC)

确实不是。只是需要翻译的量有点大而已。翻译过来我觉得就可以用。--1=0，欢迎加入WP:维基百科维护专题 2017年7月27日 (四) 13:01 (UTC)

代码写在这里了，想用新的就去翻译吧。另MediaWiki:FileUploadWizard.js只有管理员才能创建。--Q_whisper 2017年7月30日 (日) 04:14 (UTC)

要建就先建立在Draft:MediaWiki:FileUploadWizard.js--1=0，欢迎加入WP:维基百科维护专题 2017年7月30日 (日) 04:45 (UTC)

建草稿没什么用吧，用不了也没法测试。--Q_whisper 2017年7月30日 (日) 05:06 (UTC)

用得了，也有法测试。测试完没问题自然就可以改到正式MediaWiki空间了。--1=0，欢迎加入WP:维基百科维护专题 2017年7月31日 (一) 02:53 (UTC)

@Vozhuo、星耀晨曦：小小地hack了一下，你们就可以在Draft:MediaWiki:FileUploadWizard.js这里改了。--1=0，欢迎加入WP:维基百科维护专题 2017年7月31日 (一) 03:03 (UTC)

would like to help if possible.--Temp3600（留言） 2017年7月31日 (一) 20:49 (UTC)

今天进行了一次测试。目前大部分文字已经翻译，建议大家一起检查一下。--1=0，欢迎加入WP:维基百科维护专题 2017年8月4日 (五) 08:01 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ special:permalink/455145181073到1085行还需要翻译，涉及到编辑摘要部分，抱歉我不太懂行话怕弄出翻译腔。另外要不要考虑繁简？ --砜中嘌呤的白磷_{萃取 打谱} 2017年8月4日 (五) 08:15 (UTC)

另外翻译的过程中发现Non-free architectural work、Non-free title-card、Non-free speech、Non-free AUSPIC、Non-free Finnish Defence Forces、Non-free with ND这些模板没有（也许还有）。--1=0，欢迎加入WP:维基百科维护专题 2017年8月4日 (五) 08:20 (UTC)

刚刚建了一个{{Non-free title-card}}，不过有些地方不太会翻译。另外Non-free speech、Non-free AUSPIC、Non-free Finnish Defence Forces这三个模板在英文维基使用量极少，所以也没太大必要跟着建，直接删掉选项就行。--Q_whisper 2017年8月5日 (六) 13:30 (UTC)

@WhitePhosphorus、Vozhuo、星耀晨曦、Datou 1996、Clear Sky C：简体版目前差不多了，欢迎大家来试用。有问题请随时更改。--1=0，欢迎加入WP:维基百科维护专题 2017年8月6日 (日) 04:30 (UTC)

会尽力支持阁下对维基基础建设和大陆维基发展-- 晴空·和岩 o(*≧▽≦)ツ┏━┓·协作计划·中国大百科全书维基对应条目 2017年8月6日 (日) 04:32 (UTC)

“请注意我们强调的是“完全由自己制作”。……”等红色框框内的内容，仍然还未正常显示。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月6日 (日) 05:29 (UTC)

@KOKUYO：这属于警告内容，默认是不显示的，只给特定的用户显示。--Q_whisper 2017年8月6日 (日) 11:41 (UTC)

知道了。我在看英语维基百科页面有出现，以为这是给所有人看的。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月7日 (一) 11:07 (UTC)

额。。怎么试用。——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 05:50 (UTC)

同上，怎么试用Orz...--Jerre Jiang 　讨论│参与清理积压站务　 2017年8月6日 (日) 08:20 (UTC)

找到了——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 08:28 (UTC)

我觉得最好在现在的上传页面写一个通知，“新版上传工具正在测试，欢迎试用”之类的，要不然测试量太少了。--Q_whisper 2017年8月6日 (日) 11:21 (UTC)

同意-- 晴空·和岩 o(*≧▽≦)ツ┏━┓·协作计划·中国大百科全书维基对应条目 2017年8月6日 (日) 12:54 (UTC)

{{Non-free architectural work}} {{Non-free Old-50}} {{Non-free Old-70}} {{Non-free with ND}}这四个模板还需创建，请大家协助。脚本里还有几个因为英文维基使用量极少所以注释掉的模板，要是有人觉的有用的话也可以创建。--Q_whisper 2017年8月8日 (二) 12:06 (UTC)

{{Non-free architectural work}}创建之前可临时使用{{promotional}}代替，例如File:New_Corpus_Christi_Harbor_Bridge.jpg--Wcam（留言） 2017年8月8日 (二) 12:25 (UTC)

关于工具中的连结

User:Wcam坚持做出这项编辑，将有着更多实际上传注意事项的“Wikipedia:合理使用”，改成仅说明使用原则“Wikipedia:非自由内容使用准则”。有鉴于这是帮助用户上传的工具，明显有更多参考指引的“Wikipedia:合理使用”能给予更多帮助，对此请各位提出意见。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月8日 (二) 01:39 (UTC)

另外“Wikipedia:非自由内容使用准则”列出的10项原则，在新工具都有提及或要求。

非自由内容使用准则十项原则与新工具早有的要求

1. NFCC1：无自由等效作品。→“请记住，您将需要证明：”该红框便有提醒。
2. NFCC2：尊重作品的商机。→“请记住，您将需要证明：”该红框便有提醒。
3. NFCC3：有限使用。→“请记住，您将需要证明：”该红框便有提醒。
4. NFCC4：事前发表。→上传工具已经要求要提出档案来源，这必定代表。
5. NFCC5：内容。→上传工具已经告知非自由内容档案时，针对的条目应该有怎样的内容。
6. NFCC6：针对媒体的方针。→上传工具已经有要求。
7. NFCC7：至少一篇条目使用。→上传工具一开始便要求指定1篇条目。
8. NFCC8：条目中的意义。→“请记住，您将需要证明：”该红框便有提醒。
9. NFCC9：场合的限制。→上传工具一开始便要求指定1篇条目，并且对于其他类型的页面亦有防范。
10. NFCC10：图像描述页。→上传工具已经指定要填写了。

至于“Wikipedia:合理使用”提及的版权法律注意事项，上传工具根本没有篇幅提供，自然要使用连结提醒别人注意。一个是只是因为有人说它是方针所要放，一个是提供更多注意细节，例如不应该上传30秒以上的音讯档案。哪个有用明显很清楚。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月8日 (二) 02:05 (UTC)

关于非自由图片的规定当然要以正式方针为准，Wikipedia:合理使用里内容不多，连指引都算不上，并且其主要内容自2007年成型以来已有近10年未大幅更新，已不再适合作为指引新手之用，还有可能误导使用者。如果能有更准确且完备的指引（例如将Wikipedia:合理使用/草稿翻译完成并通过为正式指引），则更适合作为上传者参考。但在此之前，作为正式方针且必须普遍遵守的Wikipedia:非自由内容使用准则，强调再多遍也不为过。--Wcam（留言） 2017年8月8日 (二) 12:01 (UTC)

内容不多？至少是跟实际上传有关的指示内容，而且对于新手来说，这比你给的更有用。而既然是指示其他人页面，你觉得不符合现状，或者可以改得更好，就自己修改、或找人讨论修改，这点管理员应该懂吧？如果你后面的理由要成立，我归结两点：

1. “连指引都算不上”→看起来Wcam是主张，咱们维基百科除了方针指引的内部链接，其他都不应该添加。或许这些非方针指引的页面应该都删除，免得误导使用者。
2. “自2007年成型以来已有近10年未大幅更新”→看起来Wcam是主张，假设有个规则从2007年都持续运作、没什么变化、也没什么更新，他自己可以主张规则太旧，照自己的方法来。

我觉得这个维基百科运作机制的解释独步其他人。就像原来方针指引的共识，可以自动等同于某个页面添加什么连结的共识，怪不得我跟不上。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月9日 (三) 10:21 (UTC)

因为Wcam看起来会一直坚持下去，那我改成两个都放；如果Wcam觉得这合理使用的页面介绍不够好，那他自己应该勇于修改、或者提删该页面。@Alexander Misel、WhitePhosphorus、Datou 1996、星耀晨曦、Vozhuo：@Temp3600、Clear Sky C：你们几位觉得如何呢？--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月9日 (三) 10:39 (UTC)

(：)回应：我的确认为Wikipedia:合理使用的内容不够好，于是有参与过Wikipedia:合理使用/草稿页面的翻译，并希望其最终能成为正式指引。请问KOKUYO阁下在一味指责别人的同时，为此做过什么工作？如果一个页面不是正式方针指引的一部分，则其链接不适合出现在一个重要的功能性界面上的诸如“我已经阅读了维基百科XXX规定和标准”这样的句子之上，因为你提供的链接其实根本不是维基百科规定和标准的一部分。涉及到维基百科的规定，一定要以正式方针指引为准，因此我仍然不能完全赞同你两个都放的做法。如果使用诸如“我们建议上传者参考Wikipedia:合理使用中提供的建议做法”的表述，我认为才可以接受。--Wcam（留言） 2017年8月9日 (三) 14:17 (UTC)

我觉得Wikipedia:合理使用够用，或许也有很多人也觉得够用，觉得非常不够用的就只有你，结果说成是我的问题？还是2015年没有参与这个草稿翻译的维基百科人，都没有发表意见的权利啊，原来现在维基百科是这样运作的？或者今天维基百科的所有合理使用，都要经过你点头才能讨论，这个官威真的好大，或许我翻译这个工具前还得经过你的点头才行？至于你最后所说的意见，本身就是你误解维基百科的运作模式，完全没有意义。在这里，“两者并列”与以“方针指引为主轴”完全没有关系，你的做法只是增加没有实际用途的文字罢了。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月10日 (四) 01:27 (UTC)

两位都冷静一下，感觉这不是一个很大的问题呀，实在不行干脆将两个指引的内容合并到一起不就行了 囧rz...--Jerre Jiang 　讨论│参与清理积压站务　 2017年8月10日 (四) 01:49 (UTC)

Wikipedia:合理使用本来就得跟其他现有方针指引共通、互相补充，甚至该页面便提及“具体的‘合理使用’判断准则，请参见Wikipedia:合理使用准则。以下简单说明中文维基百科各种可能的合理使用形式，如果您有任何疑虑，欢迎到Wikipedia:互助客栈/求助询问。”。且维基百科本来就不存在只看方针指引的情况，任何方针指引都会有论述、资讯页、过往讨论纪录等，作为理解的这些规则的参考依据。但Wcam的理解好像跟大家不一样。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言）

不过@Datou 1996：您的意见确实不错，英语维基百科也是直接在Wikipedia:合理使用中插入Wikipedia:非自由内容使用准则的内容。这样修改合理使用页面后，上传工具这边就能同时保留非自由内容使用准则的内容、又能维持上传工具的简洁了。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の管理员（留言） 2017年8月10日 (四) 02:45 (UTC)

既然英文版也不嫌长，就包进去吧。互不相冲。翻译工程浩大，得慢慢来。--Temp3600（留言） 2017年8月11日 (五) 17:06 (UTC)

反馈

于Phabricator内跟踪
任务T173631

上传文件显示到“正在上传”界面就卡住了，虽然文件上传成功，但无法跳转到“上传成功”界面，我两次上传都遇到这种问题，应该不是我网络的问题。--Q_whisper 2017年8月17日 (四) 04:43 (UTC)

我也遇到同样问题。Chrome浏览器的Console显示Refused to display 'https://zh.wikipedia.org/w/api.php' in a frame because it set 'X-Frame-Options' to 'DENY'.，可能是中文维基api的设置的问题。--1=0，欢迎加入WP:维基百科维护专题 2017年8月19日 (六) 11:10 (UTC)

@Vozhuo：此bug已修复。上传文件的结果效果图--1=0，欢迎加入WP:维基百科维护专题 2017年8月21日 (一) 14:27 (UTC)

我最近在填使用的条目时总是出现“xxx该页面不属于条目名字空间。非自由版权文件只能在属于主名字空间的条目页面使用……”有人遇到这样的问题吗？--Q_whisper 2017年8月29日 (二) 06:46 (UTC)

我现在传什么图片都遇到上面的警告，死活传不上去，这是什么情况@Alexander Misel。--Q_whisper 2017年8月29日 (二) 13:51 (UTC)

我之前传文件都没有遇到这个问题啊。会不会是你填条目名称的时候有问题？--1=0，欢迎加入WP:维基百科维护专题 2017年8月29日 (二) 14:50 (UTC)

我测试了一下，确实有这个问题，跟繁简使用应该无关。--皇帝心态·被人利用·支持轮子·阻挡串联·强推站外封禁·滥权の疯狂病气管理员（留言） 2017年8月29日 (二) 15:16 (UTC)

经检查，问题出在天邪鬼的Special:Diff/45795149这笔编辑。因为var ns = pg.getAttribute('ns');这个变量返回的ns值其实是一个string类型的"0"，用!=运算符才能得到正确的比较结果。只有两边都是数值类型的时候才能用!==去判断。--1=0，欢迎加入WP:维基百科维护专题 2017年8月29日 (二) 16:03 (UTC)

建议将文件上传向导设为默认上传工具

经过前一阶段的测试和改进，文件上传向导已经具备了其应有的功能，而且简繁上也得到了支持。感谢User:KOKUYO、User:Vozhuo、User:Wcam等的参与。

现在正式建议该向导成为中文维基百科的默认上传工具，原版可以继续保留在WP:上传/old作为有经验用户的一个选择。欢迎大家表达看法。--1=0，欢迎加入WP:维基百科维护专题 2017年8月23日 (三) 09:59 (UTC)

想把UI改成OOjs UI,折腾了半天好麻烦....--百無一用是書生 (☎) 2017年8月23日 (三) 13:15 (UTC)

还有点遗漏，{{Non-free architectural work}} {{Non-free Old-50}} {{Non-free Old-70}} 这三个模板还没建，脚本里第1505行尚未本地化。--Q_whisper 2017年8月23日 (三) 13:18 (UTC)

由于中文维基没有ImageTaggingBot，所以1505行不用汉化。几个模板建起来应该不难吧。--1=0，欢迎加入WP:维基百科维护专题 2017年8月23日 (三) 13:52 (UTC)

支持使用上传向导。--Q_whisper 2017年8月25日 (五) 13:18 (UTC)

不用另外建立Wikipedia:上传/old的吧，直接Special:Upload就可以返回到旧版上传表单。--Dabao qian（留言） 2017年8月26日 (六) 03:00 (UTC)

是把原来的页面移动到Wikipedia:上传/old。要知道Special:Upload和现在的Wikipedia:上传也是有区别的。--1=0，欢迎加入WP:维基百科维护专题 2017年8月29日 (二) 03:04 (UTC)

(－)反对，没有繁简转换，单这个理由就足以令这个工具不适合作为默认的选项。另，提案人在没有公告征求意见，没有公告讨论结果的情形下自行修改了上传页面。--Antigng（留言） 2017年8月31日 (四) 10:55 (UTC)

[21][22]这是你说的没有简繁转换？我不懂你说哪里。--1=0，欢迎加入WP:维基百科维护专题 2017年8月31日 (四) 12:28 (UTC)

点击“点此开始上传向导” -> 点击左上角切换到另一个语言，页面又跳回到开始页面，似乎js不忍url里的variant参数--百無一用是書生 (☎) 2017年8月31日 (四) 12:48 (UTC)

其实认的，只不过左上角的语言变种切换不会认你还加载着js。提前在参数设置里设置好某种语言变种就好，谁会开了向导再改语言？--1=0，欢迎加入WP:维基百科维护专题 2017年8月31日 (四) 13:01 (UTC)