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

维基百科,自由的百科全书
跳到导航 跳到搜索

Breezeicons-categories-32-applications-development.svg
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 修改CS1系列引文格式模板 68 18 Antigng 2021-04-12 10:07
2 In lang模块 12 5 BlackShadowG 2021-03-21 09:13
3 (续)以模组改写Namespace pagename模板 13 4 Sunny00217 2021-04-04 22:04
4 请求评论骨架完成,并讨论机器人引进作业 21 6 YFdyh000 2021-04-11 10:19
5 为Infobox station增加“邮政编码”参数 17 6 Pseudo Classes 2021-04-06 02:17
6 调整Status2模板为Status模板后的副作用 1 1 Jimmy-bot 2021-04-13 16:14
7 关于引文模组未知参数的清理方式 11 7 Antigng 2021-04-08 12:55
8 编辑提示 11 3 LuciferianThomas 2021-04-08 18:23
9 管理员不能对mediawiki名字空间进行管理操作了? 52 9 AnYiLin 2021-04-08 13:04
10 {{中国一级行政区信息框}} 2 2 星星 2021-04-04 10:22
11 地图模板错误 1 1 百战天虫 2021-04-03 22:10
12 Tech News: 2021-14 0 0
13 IABot又失灵了 1 1 Fran1001hk 2021-04-08 10:55
14 权威控制(Authority control)不显示 & 其他技术提问(表格) 3 2 YFdyh000 2021-04-08 17:47
15 {{=}}属不属于WP:魔术字? 13 6 Xiplus 2021-04-09 12:22
16 是否应将“回复”预设简繁转换为“回覆”? 2 2 Googol19980904 2021-04-09 15:24
17 Twinkle更新 (2021-04-09) @ad96204 3 2 Xiplus 2021-04-12 21:52
18 Template:Unbulleted list和Template:hlist问题 2 2 WhitePhosphorus 2021-04-12 21:19
19 “以本地时区显示签名时间”小工具先于图表加载时导致无限递归 3 3 Lt2818 2021-04-13 01:59
20 调整外部链接备份功能 1 1 卡达 2021-04-12 15:20
21 Line numbering coming soon to all wikis 1 1 Johanna Strodt (WMDE) 2021-04-12 23:09
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时,
请先检查设定是否有误

修改CS1系列引文格式模板

原标题为:修改Cite journal模板

如题,英维早已修改此模板,增设/修改了url-status、doi-access、hdl-access、citeseerx、s2cid等参数。提议加入这些参数。为了防止像之前两次讨论一样在无人关注的情况下存档,鄙人加入了不存档模板。--Zhuofan WuCien años de soledad 2020年11月28日 (六) 11:40 (UTC)

(+)支持,但是有一个(?)疑问:这个修改,需要把对应的模块从英文维基百科重新引进中文维基百科吗?--向前进朝着胜利的方向 2020年11月29日 (日) 08:35 (UTC)
是把对应的功能引进,而不是模块。毕竟我们的格式和英文版有些不一样,无法直接引进--百無一用是書生 () 2020年11月30日 (一) 02:45 (UTC)
这是迟早要做的,而且应该把全部Cite系列模板都一起翻修过。—— Eric Liu 创造は生命(留言留名学生会 2020年11月30日 (一) 01:17 (UTC)
  • 强烈支持,并建议尽快解决,目前有大量CS1模板的错误都是由这些参数引起的(尤其是doi-access,url-access和s2cid)另,目前中维的subscription=yes和registration=yes与英维的url-access=subscription和url-access=registration起到的效果是基本一样的,中维的dead-url=no和dead-url=yes与英维的url-access=live和url-access=dead的效果也是一样的,在修改模块时记得合并这两个参数。另外,之前的一次讨论中禁止了title的繁简转换,而quote参数却没有禁止,这次希望能一起处理一下。
    现在CS1模板真的缺少维护,很多参数都没有更新,希望这次能彻底翻新一下。--BlackShadowG留言) 2020年12月2日 (三) 16:02 (UTC)
(+)支持。应兼容现有及这些新参数(比如兼容dead-url=yes和url-status=dead)。之前在Wikipedia:机器人/作业请求#更正cite_news中的df未知参数也有讨论到这个问题。另外,也附议上面提到的禁止quote繁简转换的提议。-Peacearth留言) 2020年12月12日 (六) 00:29 (UTC)
(?)疑问。跟本议题关系并不直接:大家看一下条目BNT162里面 Cite_*模板有什么参数问题导致参考资料里有大量红链?是否与最近模板的修改有关?—以上未签名的留言由Zhenqinli对话贡献)于2020年12月12日 (六) 08:35 (UTC)加入。
Zhenqinli3、4、10三个来源文中根本没有给出,“url-status”、“s2cid”参数的引入就是本案在讨论的。name-list-style不太清楚。—MintCandy♫ 台州专题2021年新年贺词 2021年1月7日 (四) 08:45 (UTC)
(+)支持,没有s2cid等参数确实麻烦。--ときさき くるみ not because they are easy, but because they are hard. 2021年1月7日 (四) 07:26 (UTC)
(+)强烈支持|url-access=对于翻译者真的太麻烦了。--Austin Chang留言) 2021年1月17日 (日) 05:40 (UTC)
(?)疑问:目前中维和英维的参考模板的参数有什么差别?是否有可能将现有参考模板全部替换为英维版本?--Yining Chen留言|签名) 2021年2月1日 (一) 08:55 (UTC)
(*)提醒:那个…各位只表达支持的话意义不大,得请人来改…现在哪位有着手的意向吗?--安忆Talk 2021年2月1日 (一) 16:34 (UTC)
(+)支持引进,不过也建议顺便把说明中文化,我到现在还是不太清楚我到底有没有用正确还是胡搞瞎搞。 --无心*插柳*柳橙汁 2021年2月6日 (六) 11:42 (UTC)
(+)支持引进,另外想请问关于不是刊载在期刊上的单篇文章,是要用哪一种cite模板?---Koala0090留言) 2021年2月7日 (日) 04:51 (UTC)
题外(...) 吐槽,cite系列模板的常用参数也是常在乱用的,网页A转载的网站B提供的媒体C刊发的报道,作者是谁、出版者是谁,是web还是news,以及B和A是否原样转载了C的内容。--YFdyh000留言) 2021年2月7日 (日) 05:05 (UTC)
直接引用原始报道即可……--BlackShadowG留言维基百科20岁生日快乐! 2021年2月19日 (五) 11:07 (UTC)
牵扯太多方面……查证成本的增加,有时很难找到原始报道位置。;原始报道的网页失效,登录可见,或者内容被分为若干页而不利阅读;信息量欠佳,比如转载方额外提供了背景信息、图表等。;转载方有时是对来源可靠性或中立性的一个佐证。;按道理新闻报道用news,但经常界限不那么分明。;'出版者'参数应该填出版单位名,但基本没人这样干,有时被用作转载者等。--YFdyh000留言) 2021年2月20日 (六) 00:03 (UTC)
我举双手双脚(+)支持,如果四个不够我现在就去卤肉店买他几十只猪蹄(+)支持。同时我提议做绝一些,废弃掉dead-url等参数,开机器人进行自动化修改(url-status参数整合了dead-url、subscription等参数)。--Milky·Defer 2021年3月1日 (一) 14:28 (UTC)
  • 我同意对CS1系列模版彻底翻修。一些不常用的模版(如{{cite interview}})现在就全是瑕疵。--Milky·Defer 2021年3月10日 (三) 16:21 (UTC)

CS1移植及反馈

这不是投票 囧rz……,CS1模块看起来蛮复杂的诶,现在各位哪位有着手修改的意向吗?——BlackShadowG留言维基百科20岁生日快乐! 2021年3月4日 (四) 11:41 (UTC)
那个模块看起来超级复杂,真的能在现有基础上修改好吗 囧rz…… --Yining Chen留言|签名) 2021年3月6日 (六) 15:47 (UTC)
2015年12月13日的版本与enwiki的差别很小,zhwiki之后的版本也多是小修改、ep,感觉可以试试。不过相关页面和配置数据我没检查,没准会出现一些难题或bug。--YFdyh000留言) 2021年3月6日 (六) 16:33 (UTC)
已在推进移植,不过还不确定如何测试。--YFdyh000留言) 2021年3月6日 (六) 20:03 (UTC)
移植enwiki最新CS1基本架构完成,进入检查和调试阶段。精通Cite模板或Lua的用户请查阅Module:Citation/CS1提到的页面(比如testcases运行结果),协助检查有问题的地方。最终部署需由管理员或模板编辑员复审确认和提交。相关模板是否需更新我还未了解,文档估计会过时一部分。--YFdyh000留言) 2021年3月7日 (日) 00:04 (UTC)
模块讨论:Citation/CS1/testcases为例,左侧的“预期”是相应代码用当前正式模板(模块)渲染的结果,“实际结果”则是当前沙盒(移植并更新)的模块渲染的结果。两者代码有差异就会标橙,请自寻文本比对工具观察两者,并反馈哪些需要优化。--YFdyh000留言) 2021年3月7日 (日) 02:12 (UTC)
(*)提醒“lay summary”应该翻译成“简明摘要”。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月7日 (日) 02:18 (UTC)
 已修复,之前只查出是某种格式。--YFdyh000留言) 2021年3月7日 (日) 02:53 (UTC)
language参数建议维持原位置,不需要提前。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月7日 (日) 02:27 (UTC)
enwiki那边的设计,没有调整过。尝试调整未果,pages、引用等参数的展示仍在后面,需要研究怎么改。--YFdyh000留言) 2021年3月7日 (日) 03:34 (UTC)
display-authors参数好像有问题。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月7日 (日) 02:34 (UTC)
错误消息问题已修正。--YFdyh000留言) 2021年3月7日 (日) 03:34 (UTC)
  1. ['Coauthors'] = {'coauthors', 'coauthor'}参数不了解有多少在用,enwiki那边已经弃用且移除,找回相关代码有点麻烦。如果不多就清理掉算了。
  2. 加了两个本地的测试样本就曝出3+个问题,建议提供或补充更多复杂、不大常见或重要的本地用法到Module:Citation/CS1/testcases(或本讨论中提及)。帮忙修复自然更好,但请多做注解以免看不懂。
  3. enwiki弃用的deadurl参数要找回吗,可能大量条目在用,但机器人刷新或许也可。估计得找回。--YFdyh000留言) 2021年3月7日 (日) 07:01 (UTC)
dead-url肯定要保留,目前有机器人和编辑工具会把url-access=live和url-access=dead替换成dead-url=no和dead-url=yes,肯定有大量条目使用了dead-url参数。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月7日 (日) 07:29 (UTC)
应该逐步弃用dead-url。可以在一段时间内暂时保留dead-url,同时解决完相关问题后,再禁用该参数。--Yining Chen留言|签名) 2021年3月7日 (日) 11:17 (UTC)
提醒一句,url-status有四个可用值:live表示可以访问并且能得到正确信息;unfit或usurped表示虽然可以访问,但是已经得不到正确信息(域名过期被他人注册等情况);dead就是无法访问。因而我觉得应当逐步淘汰dead-url,先写个机器人把dead-url=yes/no改成url-status=live/dead;等到全部改完之后,废弃掉这个参数。另外,应该有个机器人处理一下accessdate等由两个单词组成的参数名当中,连接号到底要不要加的问题。 --Milky·Defer 2021年3月7日 (日) 13:32 (UTC)
  1. 感谢提醒,确实不太了解。已经试过几次,但反向移植url-status参数的代码没能成功,对代码理解不够深。
  2. 由本地管理员修改InternetArchiveBot的后台配置就能改用url-status参数填入,但当前CS1处于青黄不接的尴尬局面,两个参数都必须兼容。
  3. CS1各testcases中也注意到许多的格式问题,包括年份位置及格式已改变,参数显示缺失,某些参数顺序改变等。
  4. Module_talk:Citation/CS1/testcases/dates中提示无效日期的功能好像也因Module:Citation/CS1/Configuration中有某些错误而失效,调了几次还没弄清楚。有技术和时间的维基人还请支援。以及其中有显示缺失。
  5. accessdate好像英文维基是推荐加-,中文维基相反,我认为不加比较美观方便;用别名兼容就好,方便从enwiki翻译条目。--YFdyh000留言) 2021年3月7日 (日) 14:39 (UTC)
不认为应当以替代dead-url的方式引入url-status;本站作为百科全书,参考文献中附带链接的作用是且仅是为读者提供来源可供查证的出处;无论是网址无法访问还是访问后得不到正确信息,都意味着“无法再向读者提供可供查证的出处”,再行区分恐怕只能起到方便IABot工作的目的;为了IABot工作的便利,将较为简单dead-url=yes/no废弃并强制替换成较为复杂的url-status=live/dead/unfit得不偿失。更何况使用机器人全自动地将dead-url=no替换成url-access=dead是不现实的——人工标注dead-url=no既有可能是url-status=dead,也有可能是url-status=unfit(比如新华网死链基本是这种情形,该网站会定期删除页面,并且404页面直接重定向到首页)。--Antigng留言) 2021年3月7日 (日) 16:04 (UTC)
目前看兼容两者是合适的路子,现有和习惯用dead-url的继续用,是否让IABot启用url-status再看情况,翻译和复制enwiki的引用也不再故障。机器人直接替换内容不合适的,IABot更新则不同(有检查和数据库),虽然IABot也不乏误报——需要管理员去改配置和沟通,没办法,我现在看不了它的配置页面。--YFdyh000留言) 2021年3月7日 (日) 16:58 (UTC)
仔细检阅修改方案后表示(-)强烈反对;这个修改不像是在为本站的模板引入某种功能,而是将本站的模板以英文站的模板取而代之。且不论极高风险模板的修改应该遵循没有坏就不要修的模式——哪怕是一个参数显示位置的变化("Anonymous. Daniel Coit Gilman; Harry Thurston Peck; Frank Moore Colby , 编. The New International Encyclopædia. Dodd, Mead and Company. 1904: 906."更改为"Anonymous (1904). Daniel Coit Gilman; Harry Thurston Peck; Frank Moore Colby (编). The New International Encyclopædia. Dodd, Mead and Company:906.")都应当有明确的社群共识方能进行。此次修改涉及的Module:Citation/CS1/Date_validation/sandbox更是与所需达成的目标完全不相关——这样的修改不仅在实质上禁用了本站过往所允许而英文站不允许的"yyyy-mm"参数格式,还引入了一大堆英文世界特有的日期记录方法如“First Quarter”、“Second Quarter”、“Easter”等。作为中文维基百科,引入这类格式不必说没有意义,就算有意义也要明确的社群共识,逐一讨论才可以放行。如此囫囵吞枣一般将本站过去的共识彻底替代则是从根本上不可行。--Antigng留言) 2021年3月7日 (日) 16:38 (UTC)
修改移植准确说现处在alpha阶段,谈格式变动和采用还为时尚早。本站CS1模块就是从英文站模块移植过来的,2015年12月由Liangent提交的版本与enwiki当时的版本相差无几(有一些本地化调整),后续的变更也都是管理员或编辑请求来调整一些习惯,或者根据英维引入一些新参数,并没有特别独立化的东西,比较源码就能看出来。
目标自然是尽量保持现有格式和逻辑,但目前看因为enwiki在五年多来修订了不少地方,导致现有表现存在不少差异和bug——这是预期中的事情,仍需格式优化或变更审定,谈这是为全盘取代和代替共识有点过分,这对所有人没好处。也许您误会了我上面说的需要管理员等协助,我的意思肯定不能自行决定如此大的变更和提交,亦无法提交——因为我不是模板编辑员,且后续修正和完善需许多人协助。关于Module:Citation/CS1/Date_validation/sandbox之事我已撰写并将回应在您的讨论页,可能是一个不慎重导致的误会,以及我不认为机器人应该使用零保护的沙盒页面作为运行基准。中文维基决定拒绝的格式可在后续禁用、警告或者过滤器、机器人修正等多种方式解决。关于对enwiki“常用”参数的兼容,请见此讨论上一节的意见。--YFdyh000留言) 2021年3月7日 (日) 17:28 (UTC)
阁下多虑了。确实,英文维基百科的模板的格式和参数显示位置与中文维基百科有些差异,但中文维基百科的模板长久缺乏维护,很多英文维基百科已经新增的一些对引文明显有益的新参数都没有引入,目前应该解决的是把英文维基百科的多个参数先在sandbox中完成引进,至于参数的本地化处理,在新模版最终使用以前肯定是需要新的社群共识作为基础的。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月8日 (一) 11:59 (UTC)
现在开始谈 正式 修改还有点早吧,现阶段的主要目标不应该是先处理参数问题,然后再考虑格式吗 囧rz…… --Yining Chen留言|签名) 2021年3月8日 (一) 12:09 (UTC)
请大家检查目前未通过的测试用例,还有没有哪些是必须通过的。--GnolizX留言) 2021年3月13日 (六) 06:51 (UTC)
感谢User:GnolizX的大力改进。--YFdyh000留言) 2021年3月15日 (一) 15:54 (UTC)
是否应该使原CS1模块能正常支持的参考在更换新参考后不报错?比如第二个测试用例,和
{{cite encyclopedia/new|editor=[[Pete Palmer]] and Gary Gillette|encyclopedia=The 2005 ESPN Baseball Encyclopedia|title=Introduction|edition=1st Edition|year=2005|publisher=Sterling|location=New York|isbn=1-4027-2568-X }}
这个测试用例?另外,希望能将dead-url和url-status状态不一致的条目增加到一个分类中,方便维护。--Yining Chen留言|签名) 2021年3月18日 (四) 14:50 (UTC)
  1. 谢之雄; COAUTHORS. 《廣西年鑑》. 广西: 广西年鉴社. 2008. CSBN 45-1175.  引文使用过时参数|coauthors= (帮助),过时参数留空提示未知空参数可以提醒编者移除,有助于参数的弃用。
  2. 现行模块其实也有一段警告,见Category:引文格式1维护:冗余文本
  3. 是像“|author=和|last=只需其一”那样加到Category:含有冗余参数的引用的页面吗?--GnolizX留言) 2021年3月19日 (五) 03:06 (UTC)
    是,因为这两个参数也算是功能重复吧。--Yining Chen留言|签名) 2021年3月20日 (六) 14:45 (UTC)
    请阅Module talk:Citation/CS1/testcases/errors的test_redundant_parameters_8。--GnolizX留言) 2021年3月21日 (日) 04:38 (UTC)
看了一下似乎没有模板内嵌套模板的测试(比如{{tsl}}、{{link-en}}),建议加上测试一下。--ときさき くるみ 2021年3月20日 (六) 17:14 (UTC)
加到测试用例里不知道为何会引用模板后大小超出限制,看来只能单独测试了,Lavrinc, Damon. Hennessey Venom GT: A $600k mid-engine Cobra for the 21st Century. Autoblog英语Autoblog.com. Weblogs, Inc.英语Weblogs, Inc.. 2010-03-29 [2010-03-29]. 这样。--GnolizX留言) 2021年3月21日 (日) 05:22 (UTC)
Cool,我觉得总体可行,(+)支持,不过还是建议复检一下引用模板是大小本身超限制还是有bug,另外我有意向补充一些测试例。--ときさき くるみ 2021年3月21日 (日) 12:17 (UTC)
感觉是测试用例太多的原因。源代码可以看到“Post‐expand include size: 2096666/2097152 bytes”,马上要用完了。--GnolizX留言) 2021年3月21日 (日) 12:50 (UTC)
那我就先直接扔在这了:Krebs, Robert E. Scientific Development and Misconceptions Through the Ages: A Reference Guide illustrated. Greenwood Publishing Group. 1999: 133. ISBN 978-0-313-30226-8. Fraser, Craig. Isoperimetric Problems in the Variational Calculus of Euler and Lagrange. Historia Mathematica. 1992, 19: 4–23. doi:10.1016/0315-0860(92)90052-D. Frame, J. S. Review: Mathematical Recreations and Essays, 11th edition, by W. W. Rouse Ball; revised by H. S. M. Coxeter (PDF). Bull. Amer. Math. Soc. 1940, 45 (3): 211–213. doi:10.1090/S0002-9904-1940-07170-8. 。我个人觉得现在比较缺少对s2cid、url-access等参数的测试。--ときさき くるみ 2021年3月21日 (日) 13:48 (UTC)
可以检查一下这套测试用例。--GnolizX留言) 2021年3月21日 (日) 14:32 (UTC)

仅解决url-status问题的补丁

已通过:
七日无反对和意见,通过--Antigng留言) 2021年4月12日 (一) 02:07 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

如果社群不介意dead-url=dead/live这种用法的话,实际上只需作下列三处改动即可实现url-status与dead-url的兼容:Module:Citation/CS1Module:Citation/CS1/ConfigurationModule:Citation/CS1/Whitelist,而不影响其它功能和显示。--Antigng留言) 2021年3月29日 (一) 09:36 (UTC)

请问能否提供一下测试样例?--BlackShadowG留言维基百科20岁生日快乐! 2021年3月29日 (一) 12:01 (UTC)
@BlackShadowG:,Module_talk:Citation/CS1/testcases/Antigng。--Antigng留言) 2021年3月29日 (一) 12:58 (UTC)
另url-status和deadurl并存且意义相同的情况下可以使用机器人加以清理,已提出相关申请。--Antigng留言) 2021年3月30日 (二) 07:22 (UTC)
支持此修改,但如果修改后两个参数效果相同的话,清理似乎没有必要。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月31日 (三) 10:23 (UTC)
上述修改合并之后,重复参数会自动归入Category:含有冗余参数的引用的页面,并且在条目里产生红字报错(效果请参见Special:Diff/65003187)。此外,清理重复参数也利于将来的维护(例如,当链接的状态发生变化时,如果存在重复参数,则有可能会出现改其中一个参数而忽略另一个参数的情况,而导致矛盾)。--Antigng留言) 2021年3月31日 (三) 15:00 (UTC)
如果现在已经确定要对CS1系列模板进行修改完善,那这个临时补丁的作用貌似不大,总之最后都会被修复。--Yining Chen留言|签名) 2021年4月1日 (四) 12:58 (UTC)
既然要修改完善CS1模块,那就应该讨论并制订详细的修改目标,取得共识之后一个改动一个改动分别测试合并,而不是像上面本人所反对的方案那样,一次性引入现行英文模板,为了解决少量的问题而引入大量本站不必要甚至有害的功能,例如df参数本站就有用户反对引入。这里提出的是永久性的解决url-status与dead-url兼容性的方案,而非临时方案。待该修改完成后将另开章节,依序引入url-access、doi-access等功能,直至上方社群所提出的要求全部完成。--Antigng留言) 2021年4月1日 (四) 15:59 (UTC)

对该方案加以公示,如有反对和/或改进意见请速提出。--Antigng留言) 2021年4月5日 (一) 15:19 (UTC)


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

本章节暂时不存档,直至问题解决。欲让机器人存档,请移除本模板。留言请置于本模板上方。

In lang模块

{{In lang}}模板中显示Module:In lang错误(模板固定链接:Special:PermanentLink/63906340,模块固定链接:Special:PermanentLink/63906389),有办法能够修复吗?感谢。--Yining Chen留言|签名) 2021年2月12日 (五) 02:07 (UTC)

粗看了一下是Module:Lang没有同步英文维基的版本,缺少name_from_tag这个函数。要更新的话最好还是走 ep 流程。 --砜中嘌呤的白磷萃取 打谱 2021年2月12日 (五) 03:24 (UTC)
感谢。已提交至Module_talk:Lang。--Yining Chen留言|签名) 2021年2月12日 (五) 08:59 (UTC)

现在输出的是语言的英文名称,是否需要改成中文?——BlackShadowG留言维基百科20岁生日快乐! 2021年2月28日 (日) 13:52 (UTC)

应该要。现在沙盒版本里的语言名称已经被汉化了,把开头的 In 改掉就行。不过我想问,这个模板和{{ja icon}}之类是不是重复了?英文版没有后者。 --砜中嘌呤的白磷萃取 打谱 2021年3月3日 (三) 03:58 (UTC)
@WhitePhosphorus:xx icon一类的模板在英文版是因为与本模板重复被删除了,我觉得这个模板不会重复且很有必要,因为使用xx icon一类的模板一次只能标记一种语言,如果网页有多种语言的话就得使用多个xx icon模板标记,这样的效果很不好,比如中文、英文和日文网页用xx icon模板标记会成为这样:(中文)(英文)(日语),而本模板可以兼容多个语言参数,希望将来本模板的显示效果可以与cite web模板的language参数一样,用于标记多语言的网页,如下:示例 (中文、英语及日语). 。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月4日 (四) 11:34 (UTC)
管理员可以先处理Module_talk:Lang的编辑请求。--Vozhuowhisper 2021年3月3日 (三) 11:02 (UTC)
报错了。--Yining Chen留言|签名) 2021年3月11日 (四) 14:32 (UTC)
Module:Lang已更新,In lang可以正常显示了。要是这个模板真的在中文维基启用的话那些xx icon模板就可以计划删掉了,{{In lang|ja}}的写法完全可以代替{{ja icon}},或者可以用字符更少的{{LL|ja}}写法。--Vozhuowhisper 2021年3月12日 (五) 14:45 (UTC)
另外还需要解决的问题是显示样式:(日语)(日语),本来中文英文维基都是用的右边的样式,但是英文维基cite web等模板后来改成了左边的样式,中文维基并未跟进。所以要么把in lang改成中文维基现在用的样式,要么把cite web等模板更新成英文维基现在的样式。--Vozhuowhisper 2021年3月12日 (五) 15:21 (UTC)
现行的{{ja icon}}的鼠标浮现文字是“连接到X语网页”。但像{{Cite book}}QWER (日语). 这里并没有什么网页可供连接。作为类似的式样,似乎要一起考虑。--洛普利宁 2021年3月12日 (五) 15:36 (UTC)
@Vozhuo:,我已经修改了模块把{{in lang}}的显示样式更改为{{language icon}}的样式了,而cite web一类的模板似乎是直接引用了{{language icon}}模板,因此出现了@Lopullinen提到的悬浮文字的问题。我认为可以吧language icon的默认悬浮文字去掉,因为目前似乎language icon不只是用于标记网页,有些编者也会使用language icon标记书籍的语言。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月21日 (日) 01:13 (UTC)

本章节暂时不存档。欲让机器人存档,请移除本模板。留言请置于本模板上方。

(续)以模组改写Namespace pagename模板

上次讨论,现时Module:Namespace pagename应已完善,因此重提以模组改写Template:Namespace pagename一事。修改方案见此。依Wikipedia:保护方针#需讨论达成社群共识,将模板的功能使用模块改写须在此详细讨论后才可提出编辑请求,故将此项请求重新交至此以供讨论。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 02:12 (UTC)

请求评论骨架完成,并讨论机器人引进作业

各位使用者您好,RFC的主要说明页面骨架大致建立完成,剩下的页面与系统功能无关,因此可以进行准备工作。

目前要讨论的是引入两个机器人,User:Legobot以及WP:FRS的机器人。前者是RFC的主要核心机器人,属于全域机器人,需提出引入中文维基百科,可能还需要额外进行本地化处理;后者则是FRS运作的主要机器人,属于本地机器人,要进行修改、调整及测试。以上。台湾杉在此发言 (会客室) 2021年3月9日 (二) 05:31 (UTC)

(?)异议:还没有共识引入RFC,怎么就要申请机器人?--虫虫飞♡♡→♡℃留言 2021年3月10日 (三) 02:41 (UTC)
没有测试机器人的有效性,就无法进一步讨论是否引入,该测试与讨论是否引入RFC无关。此外,测试场合先不会在主要热门讨论页面(如互助客栈)进行,原有模式不受影响。--台湾杉在此发言 (会客室) 2021年3月10日 (三) 03:06 (UTC)
不要想着依赖于bot,bot只是辅助--百無一用是書生 () 2021年3月10日 (三) 07:31 (UTC)
虽然同意bot是辅助,但目前该机器人负担大部分RFC的功能任务,因此仍有引入必要。--台湾杉在此发言 (会客室) 2021年4月4日 (日) 11:08 (UTC)
(?)疑问:能否简要介绍Legobot的功能?--Yining Chen留言|签名) 2021年3月10日 (三) 12:25 (UTC)
WP:RFC里面有说明。--台湾杉在此发言 (会客室) 2021年3月11日 (四) 00:23 (UTC)
@Taiwania Justo:在RFC起步之际,手动维持半自动运行是否可行?贸然上机器人可能出许多问题。--YFdyh000留言) 2021年4月7日 (三) 11:21 (UTC)
手动可能会比较麻烦,因为LegoBot主要的功能有 (1) 将挂有{{rfc}}讨论的标题与摘要列于Wikipedia:请求评论/全部与其子章节 (2) 如果没有标明延长讨论措施,30日一到就自动撤除{{rfc}}模板以及自Wikipedia:请求评论/全部撤除该讨论的标题与摘要(不是存档,该讨论仍然会保留在原来的地方并仍可以继续进行)。如果要半手动,那就要有人去查询哪个讨论有挂这个模板,然后将标题摘要抄录在列表当中。--台湾杉在此发言 (会客室) 2021年4月7日 (三) 15:05 (UTC)
Special:用户贡献/YFdyh-bot,两个机器人经尝试已能运转,不过目前未设定自动运行,亦未申请权限。不支持编辑Flow讨论页,已在下方询问作者,可能需要增强,或改用ping通知。如果用ping通知,在专用页面上反复通知是否较好。我不确定未来有精力照顾该服务的稳定运转,所以如果有人或原作者原意接手,我很欢迎。--YFdyh000留言) 2021年4月7日 (三) 21:39 (UTC)
我觉得目前结构式讨论只用于使用者讨论页及知识问答,而这两个地方基本上不太会用到请求评论,而且未来不太可能将结构式讨论延伸到其他讨论页。我认为机器人可以在不需要对结构式讨论调整之下进行运转。--台湾杉在此发言 (会客室) 2021年4月10日 (六) 15:16 (UTC)
是指无法通知选用Flow作用户讨论页的用户,例如我的。--YFdyh000留言) 2021年4月11日 (日) 02:19 (UTC)
(?)疑问:RFC的讨论模式与本站客栈的提案公示模式完全不同,而且现在什么共识都没有,就要弄机器人,而机器人主人也拒绝协助,是否应先有共识采用RFC才好进行下一步呢?而且这是一个重大改革,影响很大,大家是否应讨论一下有没有必要进行这个大改革呢?--虫虫飞♡♡→♡℃留言 2021年4月7日 (三) 11:49 (UTC)
其实与提案公示不冲突。RFC仅作为通知有重大讨论需要参与,运作模式只有 (1) 标示RFC模板并进行分类 (2) 撰写中立的讨论摘要,没了。此动作可以在包含互助客栈等其他讨论页章节标示,公示七日、公告栏提醒讨论等方针指引讨论模式不会改变。--台湾杉在此发言 (会客室) 2021年4月7日 (三) 14:59 (UTC)
再者,机器人作者不是拒绝协助,而是提供程式码请我们自行研究,有任何问题可以请他协助。--台湾杉在此发言 (会客室) 2021年4月7日 (三) 15:07 (UTC)
改革不至于,不好用就不用,晾在那里不会有太大问题,讨论也可剪切移动。--YFdyh000留言) 2021年4月7日 (三) 18:50 (UTC)
(!)意见:我觉得提案人应论述一下提案想解决什么问题?而现时机制是否无法解决此问题?--虫虫飞♡♡→♡℃留言 2021年4月9日 (五) 02:11 (UTC)
在其他讨论页而非客栈页面开展讨论。将新讨论通知订阅了相关主题的感兴趣用户。在特定页面和模板中列出30天内活跃的这些讨论。讨论应该是作为局部征询意见及共识。--YFdyh000留言) 2021年4月9日 (五) 09:28 (UTC)

邀请机器人作者

现在会试图邀请Legobot作者来讨论RFC机器人事宜。@Legoktm:We are discussing the RFC on Chinese Wikipedia, and the procedure is copied from the English Wikipedia. Therefore, we need to import the Legobot to excuse the RFC procedure. Current issues are: (1) Localization for the Chinese version; (2) bot test. Thanks! 台湾杉在此发言 (会客室) 2021年4月5日 (一) 10:46 (UTC)

@Taiwania Justo: It's exciting to hear that another wiki wishes to use Legobot, but unfortunately I don't really have the time to help set it up on another wiki and maintain it. All of the code is public, I would suggest making a copy of it and adapting it to whatever this Wikipedia would like implemented. If there's anything I can do to make that process easier, please let me know. Legoktm留言) 2021年4月7日 (三) 04:57 (UTC)
@Legoktm:I have tried and deployed the rfcbot.php of harej-bots on user:YFdyh-bot. I noticed that it can't inform the Flow-board users (including me). Is this an expected behavior? And maybe this can be alleviated with like {{ping}} or {{mute}}?--YFdyh000留言) 2021年4月7日 (三) 21:28 (UTC)

为Infobox station增加“邮政编码”参数

拒绝:
拒绝请求,提案者声明后仍未见必要性,请确认必要性后再次提案,谢谢。 2021年4月5日 (一) 18:17 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

转介自Template talk:Infobox station#请求增加“邮政编码”这一参数。有用户请求为{{Infobox station}}增加“邮政编码”参数。根据方针,新增参数属于需要在客栈讨论的受模板保护模板修改事项,故现转介至客栈,供各位商议。先前的讨论有提到新参数的重要性或必要性的问题,供各位参考。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 07:37 (UTC)

@TogsetPseudo ClassesSANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 07:37 (UTC)
感觉不是必要信息,用来寄信吗;WP:NOT;未见英文维基有。--YFdyh000留言) 2021年3月22日 (一) 08:20 (UTC)
真的很必要吗?通常不必要。--痛心疾首
  • 同上,必要性似乎有限。Itcfangye留言) 2021年3月22日 (一) 14:11 (UTC)
  • 请各位反对这一提议的朋友们看看“分类:丹麦铁路车站”下的条目,现在因为Template:Infobox station没有“邮政编码”这一参数,分类:丹麦铁路车站下条目的邮政编码只能放在“位置”参数下(“位置”参数中括号内的四位数字即为车站的邮政编码),现在的状况很容易让部分中文读者不知所云(不符合中文的语言习惯)。 --Togset留言) 2021年3月23日 (一) 5:51 (UTC)
这和车站编号的分别是什么?SANMOSA 江南好,风景旧曾谙 2021年3月23日 (二) 07:15 (UTC)
然后说放在“位置”参数下其实也没什么大问题,日比谷图书文化馆苗栗县三湾乡立图书馆我不也是这样写,我甚至连括号也不写。SANMOSA 江南好,风景旧曾谙 2021年3月23日 (二) 07:20 (UTC)
@Togset泉水谷站,仅dawiki以相同方式写了2760,其他语言条目没有写。所以这是什么编码,确实有读者需要吗,是station通用的“邮政编码”吗。以及奇特的是,它的维基数据项中邮政编码目前是3660。请求来源。--YFdyh000留言) 2021年3月23日 (二) 09:24 (UTC)
抱歉插个话,@Togset:您在内文中插入分类的语法似乎有误,我已协助修正。--回廊彼端留言) 2021年3月23日 (二) 15:02 (UTC)
@YFdyh000丹麦国家铁路官网上泉水谷站的邮政编码为2760(网址链接:[1]),维基数据项中的相关数据我也进行了修改。 --Togset留言) 2021年3月24日 (二) 4:05 (UTC)
@Togset:打不开这个链接,"The request is blocked.",不知道为什么。[2]网页存档看,2016和2019年都是3660,存档最新状态,里面也是3660,没看到2760显示的位置。--YFdyh000留言) 2021年3月24日 (三) 05:27 (UTC)
@YFdyh000:用Tor浏览器试试 --Togset留言) 2021年3月24日 (二) 6:55 (UTC)
@YFdyh000:要用欧洲位置的IP才能看到。最新的存档显示那个邮政编号是Google地图给的。SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 08:48 (UTC)
@Sanmosa:假如我们这些翻译们足够功夫到家,向外国的地址寄信、寄快递或在外国找路就可以直接使用中文,而且还能够大幅降低学习外语的难度。因为假如您对一个事物足够熟悉,语言换了也不会太难;假如您对相关背景不够熟悉,凭空学习一门语言会非常难。我在通过中文文献了解外国国情时,总觉得假如外国国情是一本书,中文文献中的内容就像“摘要”,那我就想问问:“‘正文’哪里去了?”;而“正文”就是我们这些翻译需要补充的内容。我们中文维基百科编者应当比英文维基百科编者做得更好,因不是仅仅去做英文维基百科编者的追赶者。综上所述,在这一模板中补充“邮政编码”参数是非常必要的。 ——Togset留言) 2021年3月25日 (二) 2:31 (UTC)
前面的话很难懂。所以读者有相当一部分将条目当成工具书来查邮编吗,不应该是搜索引擎或相关资料网站查询吗。如果邮编是Google地图给的,恐怕也不满足列明来源,可靠性欠佳。--YFdyh000留言) 2021年3月25日 (四) 03:27 (UTC)
@Togset:同上,我依旧怀疑“2760”的真确性。另一方面,苗栗县三湾乡立图书馆并不是翻译条目,我认为直接在地名前加上数字而不写括号的表达方式已经足以让人意识到那组数字是一个邮政编码。SANMOSA ······ 2021年3月29日 (一) 06:17 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

调整Status2模板为Status模板后的副作用

关于引文模组未知参数的清理方式

之前讨论:Wikipedia:机器人/作业请求#更正cite news中的df未知参数

由于en:Module:Citation/CS1/Date validationModule:Citation/CS1/Date validation对日期格式的处理方法不同,中文模组没有|df=这个参数,复制文字或翻译文章常会出现Category:含有未知参数的引用的页面问题。这边准备着手清理相关的参数,包括|url-status=|doi-access=。在这之前集思广益一下,希望听听大家的高见,不晓得这些未知参数怎么处理比较好。

基本的方向有几个:一是修改中文模组,让中文也接受中文合适的日期格式。另一个是维持原样,直接把这些参数删了。欢迎大家发表意见。若能寻得共识,接下来这边会申请机器人作业定期整理。--Kanashimi留言) 2021年3月28日 (日) 08:11 (UTC)

上面的#修改CS1系列引文格式模板讨论的范围比较宏大,但是看来似乎还没有明确的结果。这边特别提出|df=这个参数,想听听大家的意见。 --Kanashimi留言) 2021年3月28日 (日) 08:45 (UTC)
然后CS1改版后,削除参数的参考来源会有什么损失。先修改Module:Citation/CS1/Whitelist使CS1不警告但也不处理如何。--YFdyh000留言) 2021年3月28日 (日) 13:10 (UTC)
方向二,英文维基百科对该参数的介绍:
  • df: date format; sets rendered dates to the specified format; does not support date ranges or seasonal dates; overrides the automatic date formatting described above. Accepts one value which may be one of these:
dmy – set publication dates to day month year format; access- and archive-dates are not modified;
mdy – as above for month day, year format
ymd – as above for year initial numeric format YYYY-MM-DD
dmy-all – set publication, access-, and archive-dates to day month year format;
mdy-all – as above for month day, year format
ymd-all – as above for year initial numeric format YYYY-MM-DD
而目前中文维基百科的引文都是统一使用ISO 8601中规定的YYYY-MM-DD格式,也有少量条目使用“YYYY年MM月DD日”的格式,并不存在英文维基百科中特有的“day month year”、“month day, year”这种格式,因此,这个参数完全没有引进的必要,加入维护分类让机器人全部清理掉就可以了。--BlackShadowG留言维基百科20岁生日快乐! 2021年3月29日 (一) 11:58 (UTC)
个人较为支持方向一(即:修改中文模组,让中文也接受|df=|url-status=|doi-access=等参数。需要提醒的是,后两者其实与日期年月日格式无涉,只是像比如dead-url=yes与url-status=dead之间的差异)。个人认为修改中文模组较能解决问题根本,毕竟就能省去使用机器人清理此类参数的麻烦了。要考虑到,若使用机器人清理的话,是永远清不完的,毕竟之后还是会陆续有其他人再将此类参数加到条目内。这样的话,机器人的任务会是永久的,如果机器人因故不运作了还得找替代品。不如直接修改模组,一了百了,还省得机器人在条目里多制造几笔编辑。-Peacearth留言) 2021年3月29日 (一) 14:37 (UTC)
|url-status=|doi-access=这两个参数上面的§ 修改CS1系列引文格式模板中在讨论引入,但是|df=参数似乎并没有引入的必要,也无法引入。您也可以看出,这个参数在英文维基百科中是用来调整英文独有的日期格式的,而在中文维基百科并没有日期格式的问题,因此|df=参数可能还是避不开清理。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月29日 (一) 16:27 (UTC)
了解。想了一下,我觉得您说的有理,|df=的部分就让机器人清理吧。而|url-status=|doi-access=的部分则采修改模组的方式(虽然可能会稍微复杂一点)。-Peacearth留言) 2021年3月30日 (二) 02:43 (UTC)
翻译文章总有问题,法语维基的CS1系参数名称是法语,只能机器人清理。--E.A.Crowley666✍️ 2021年3月30日 (二) 02:48 (UTC)

@BlackShadowGYFdyh000和平奮鬥救地球EdwardAlexanderCrowley:感谢各位提供意见。Wikipedia:机器人/申请/Cewbot/25 --Kanashimi留言) 2021年4月5日 (一) 21:37 (UTC)

应设立专门机器人负责维护引文日期格式,因为很多编者在搬运英维的参考资料时,会直接将其特有的日期格式“day month year”“month day, year”复制到条目中,这类格式不符合中文使用者的阅读习惯,并会造成条目的引文风格不一致,甚至同一条目内出现多种不同的日期格式。因此,有必要统一中文维基百科的日期格式,将“day month year”“month day, year”等英文格式强制转换为 ISO 8601 所规定的“YYYY-MM-DD”格式。--萧漫留言) 2021年4月7日 (三) 12:57 (UTC)
萧漫已经有了。--Antigng留言) 2021年4月8日 (四) 04:55 (UTC)

编辑提示

在此提议在Category:各年台湾电视剧分类中所有主空间页面编辑时自动显示以下编辑提示(利用MediaWiki:Common.js):

(源代码:U:LXFRNT/EN/TWTV)这是因为有关条目有很多部分都发现违反以上方针的内容,违规内容所占篇幅比其余内容多好几倍,类似{{BLP editintro}}处理。--LuciferianThomas留言 2021年3月29日 (一) 10:16 (UTC)

另一处理方法是建立过滤器警告Tigerzeng,不过就比较麻烦。--LuciferianThomas留言 2021年3月29日 (一) 10:25 (UTC)
目前只能检查单层分类,无法检查是否存在为某母分类,故您的提议无法以Common.js的做法达到。--Xiplus#Talk 2021年3月31日 (三) 09:01 (UTC)
那RegExp“\d{4}年台湾电视剧”呢?覆盖范围再高一点。--LuciferianThomas留言 2021年4月4日 (日) 09:06 (UTC)
@Xiplus?--LuciferianThomas留言 2021年4月7日 (三) 08:35 (UTC)
判断标题?技术上当然没问题。--Xiplus#Talk 2021年4月7日 (三) 10:56 (UTC)
分类标题。--LuciferianThomas留言 2021年4月8日 (四) 10:23 (UTC)

此外,不知是否能够利用MediaWiki:Mobile.js在流动版用户递交编辑前的编辑摘要prompt之上出现提示讯息(确保他们看得到)以在编辑器载入时出现一个overlapping div让用户阅读这些编辑提示后按确认再进入编辑,以让流动版用户也会看到编辑提示。--LuciferianThomas留言 2021年3月29日 (一) 10:16 (UTC)

(过滤器警告就也能覆盖流动版用户,不过还是那句较难设定)--LuciferianThomas留言 2021年3月29日 (一) 10:27 (UTC)
@LuciferianThomas:用这颜色也太刺眼的些...-- Sunny00217  2021年3月29日 (一) 14:48 (UTC)
我是直接拿了{{d}}的颜色……问题太严重了,现在还是得用红色吸引注意力;未来问题比较轻的时候可改为黄框黄底甚至白底。--LuciferianThomas留言 2021年3月30日 (二) 03:34 (UTC)

本章节暂时不存档。欲让机器人存档,请移除本模板。留言请置于本模板上方。

管理员不能对mediawiki名字空间进行管理操作了?

今天在处理Wikipedia:页面存废讨论/记录/2021/03/25#MediaWiki:JQuery-makeCollapsible.js、MediaWiki:JQuery-makeCollapsible.css时才发现管理员不能对mediawiki名字空间进行删除、移动和保护操作了,之前讨论的Wikipedia_talk:界面管理员#提议为界面管理员追加若干权限似乎实现了一部分?--百無一用是書生 () 2021年4月1日 (四) 02:18 (UTC)

自从界面管理员设立之后就不能了。要删除的页面是css/js。--安忆Talk 2021年4月1日 (四) 02:26 (UTC)
实际情况是,删除需要管理员权限,操作css/js页面需要界面管理员权限。所以要两个都有才行。--安忆Talk 2021年4月1日 (四) 02:27 (UTC)
是的,不过行政员可以临时授予自己介管权限来进行相关操作。--AT 2021年4月1日 (四) 09:06 (UTC)
(?)疑问:如果本地有共识,能否修改为“所有mediawiki名字空间的页面普通管理员都能删及还原,只是不能编辑”?否则很影响站务处理。而且css/js页面,现在普通管理员及行政员都能删,但两者删后都不能还原,这种系统问题能修正吗?--虫虫飞♡♡→♡℃留言 2021年4月2日 (五) 03:02 (UTC)
现在的情况是,管理员对此空间下的一般页面有着完全的操作权限,而界面管理员只能编辑。对于css/js页面,中维的界面管理员没有delete/move等权限,所以实际在进行删除、移动和还原等操作时还是需要同时任管理员和界面管理员。
前提案中所涉及到的九项新权限,在我看来都是必要的。编辑被保护的页面、移动(包括移动不留重定向)、删除和还原给予界面管理员在此空间下的自由,IP封禁豁免使它不受意外封禁的影响。诚然,通过回退员和IP封禁豁免者可以获得一部分不那么重要的权限,但它们可以被其他管理员移除,这是和用户组内置权限的本质区别。
我无法说服持有着管理员权限的诸位。我也想不明白为什么界面管理员在中维变成了界面编辑员,甚至编辑权限都不完整,在MediaWiki空间下只能编辑非全保护的页面。--安忆Talk 2021年4月2日 (五) 03:52 (UTC)
确实有必要添加权限。英文维基百科的界面管理员必须先有管理员权限,所以管理员已有的就不必重复。而本站允许单独申请,现有的权限不完整。
看了下你上次的提案,个人认为没有必要的是undelete(日文站点也没这个权限)与ipblock-exempt(需要的话可以另外申请),其他的支持添加。--Lt2818留言) 2021年4月2日 (五) 04:48 (UTC)
ipblock-exempt最好内置,因为不排除被恶意移除IPBE用户组的可能,比如有人现在将我从中移除出去,我是没办法再编辑的。delete和undelete相辅相成,比如可以在误删页面时即刻复原(MediaWiki空间下的页面通常高度可见并及时反映),英维是这样的。至少在MediaWiki空间给一下。--安忆Talk 2021年4月2日 (五) 05:09 (UTC)
要看每个站点的Special:ListGroupRights,英维的undelete属于管理员。undelete若能限制名字空间的话也不反对。恶意移除用户组的情况应该从源头解决,跟恶意封禁没两样。--Lt2818留言) 2021年4月2日 (五) 05:56 (UTC)
对比了一下群组权限,发现中维和英维的IA组权限竟一模一样,应该是当年讨论时漏掉了。如您所说,对IA来说,中日维的管理员是可选项,而英维是必须基于它。所以我认为照搬一下ja:特别:利用者グループ権限,再根据实际需要追加一项editcontentmodel,以及和move相关的两项即可。既然undelete在大维基均属于管理员,中维就不开创这个先例了。--安忆Talk 2021年4月2日 (五) 06:23 (UTC)
补充一下:管理员只能删除用户空间的JS/CSS(无法编辑、还原),MediaWiki名字空间的JS/CSS一点权限都没有。要使前项权限延伸到MediaWiki名字空间估计要改动软件代码,会影响全部站点。如此改动虽不会有安全问题(毕竟无权加新代码),但MediaWiki名字空间中JS/CSS页的删除通常伴随其他界面页的修改,仍然需要界面管理员相助。--Lt2818留言) 2021年4月2日 (五) 06:13 (UTC)
管理员可以编辑此空间下的一般页面吧,比如MediaWiki:Bad_image_list,应该也可以删除它。--安忆Talk 2021年4月2日 (五) 06:25 (UTC)
原先的表述可能有歧义,已经修改明确。--Lt2818留言) 2021年4月2日 (五) 06:29 (UTC)
管理员无法编辑css/js页面是正确的实现,而无法删除MediaWiki空间下的相关页面可能也是为了安全考虑,用户的common.js删就删了,全站的不行。所以IA应该有自己的delete权限。
单看这个话题,问题所在是IA“在理论上”可以操作MediaWiki空间下的css/js页面,但中维里单纯的IA还不能delete,得双持。而根本原因也正是我那个前提案所说的,是权限覆盖不足,得改。--安忆Talk 2021年4月2日 (五) 06:45 (UTC)
理由很充分,可考虑再次提案。--Lt2818留言) 2021年4月2日 (五) 06:53 (UTC)

重新提议为界面管理员增加权限

承接以上讨论,重提安忆君先前提案。本站允许单独申请界面管理员,而当前界面管理员的权限对于未兼任管理员者是不完整的。参考日文站点先例,提议为该用户组增加以下权限:

  • delete(删除页面)
  • editcontentmodel(编辑页面的内容模型)
  • move(移动页面)
  • move-subpages(移动页面及其子页面)
  • suppressredirect(移动页面时不在原页面创建重定向)

--Lt2818留言) 2021年4月2日 (五) 08:29 (UTC)

(-)反对,基金会不会给过的,@Lt2818:别再提这个案了-- Sunny00217  2021年4月2日 (五) 08:58 (UTC)
@Sunny00217:你不妨解释一下为何日文维基百科的界面管理员有这些权限。--Lt2818留言) 2021年4月2日 (五) 10:20 (UTC)
目前持有额外权限的he跟ja,皆是合并在IA设立前就有的使用者群组(类似IA层级的权限),与现在您想要授予一些管理员层级权限的情况不同。--Xiplus#Talk 2021年4月2日 (五) 11:07 (UTC)
Sunny00217君的这个说法希望能给出确切来源。界面管理员默认只是管理员的附加用户组,而本站的情况有所不同。--Lt2818留言) 2021年4月2日 (五) 11:21 (UTC)
InitialiseSettings.php L9551及L9851,注解有对应的Phab工单编号。--Xiplus#Talk 2021年4月2日 (五) 11:33 (UTC)
@Xiplus:我指的是“基金会不会给过的”这个说法存疑,不是要验证你的发言。--Lt2818留言) 2021年4月2日 (五) 11:41 (UTC)
对配置更改的限制#被禁止的更改。--Xiplus#Talk 2021年4月2日 (五) 12:06 (UTC)
这个在之前的提案提到了,当时举的反例是ja,它有例外。ja之前有interface editor,现在也可以授权普通用户包含interface editor权限的interface administrator;中维仅可以授权普通用户interface administrator,而没有interface editor;其他语言不能授权普通用户interface administrator,这是关键的区别。加权限不行的话,加用户组可以吗?加一个interface editor。--安忆Talk 2021年4月2日 (五) 12:21 (UTC)
只要不包含edit*(js|css)权限就可以。--Xiplus#Talk 2021年4月2日 (五) 12:38 (UTC)
单设用户组当interface administrator的DLC有点儿让人迷惑…。用户组叫interface-administrator-extra,然后包含提到的几项权限,成为IA自动授权interface-administrator-extra?…--安忆Talk 2021年4月2日 (五) 12:46 (UTC)
这有点多此一举……只能说明他们这个限制是愚蠢的,可以尝试突破一下。实在不行你再申请个管理员就成。--Lt2818留言) 2021年4月2日 (五) 12:52 (UTC)
难。并且这是妥协之道,万一以后也有我这种单持的人呢,既然方针允许,就应该改正这个问题,或者,改变方针。--安忆Talk 2021年4月2日 (五) 13:04 (UTC)
我仅仅是基于Limits to configuration changes阐述事实,至于这么做好不好,是另一回事。--Xiplus#Talk 2021年4月2日 (五) 12:56 (UTC)
是,您说的是事实。只是要是把我上面说的那个做法提到phab上,他们说不定都能笑出声 囧rz……--安忆Talk 2021年4月2日 (五) 13:01 (UTC)
he在此限制出来之前就更改,ja则是在此限制出来之后的三个月,在ja之后就没有了(未确定被拒绝数量)。--Xiplus#Talk 2021年4月2日 (五) 12:43 (UTC)
已确认。事由是某站点欲为界面管理员增加编辑过滤器权限,本站情况与之不同。为减少以类似理由拒绝之可能性,我删除了提案中“编辑受保护页面”权限,不便之处需要通过解除相关MediaWiki页面之保护来解决。如果这样仍然拒绝,则要请他们改代码以允许管理员删除MediaWiki名字空间的JS/CSS页。--Lt2818留言) 2021年4月2日 (五) 12:32 (UTC)
问题在于这样一来,界面管理员就具有了大部分管理员权限,似乎不太妥当。除非界面管理员可以单独为MediaWiki空间下的css/js页面或全部MediaWiki空间页面设置这些权限--百無一用是書生 () 2021年4月2日 (五) 09:42 (UTC)
最可能有争议的应该是“删除页面”权限,其他的争议会小一点。该权限的必要性在于,现在单独的管理员和界面管理员都无法删除MediaWiki名字空间的JS/CSS页,必须有两个用户组才能完成,徒添困扰。由于本站的界面管理员都通过RfA程序产生,受信任程度不亚于管理员,即使用该权限处理存废讨论也无可厚非。--Lt2818留言) 2021年4月2日 (五) 10:34 (UTC)
日维的界面管理员是从界面编辑员迁移过去的(Merge bellow userrights from interface editor to interface administrator: ipblock-exempt, editprotected, editsemiprotected, editsitejson, delete and suppressredirect rights)然而,我们没有界面编辑员这一过渡,是直接引入的interface administrator,可它的权限还不及人家被取消的interface editor,甚至在某种角度来看还赶不上我们的模板编辑员,是不是不太合理?中维管理员共64项权限,何来“具有了大部分管理员权限”之说。方针写道:“…所以界面管理员的可信程度不应亚于管理员,甚至应该更高…”,其实际任免的流程和门槛也和管理员信任案无二,只是分管领域不同,何来“不太妥当”。--安忆Talk 2021年4月2日 (五) 10:53 (UTC)
64这个数值不准确,实际上管理员特有的权限只有31小项,本案提议授予其中4小项;但若把类似权限分类(例如删除跟反删除)成大项,则管理员特有删除、封锁、保护、过滤器、flow-create-board、markbotedits、move-subpages、editcontentmodel这8大项,而本提案涉及其中4大项(注:涉及不表示完全涵盖)。--Xiplus#Talk 2021年4月2日 (五) 11:38 (UTC)
64是这里列出的项目数。您给的工单我看了下,情况不太一样,或者说是不太适用。he和ja的IA是由interface editor合并进去的,但它们的IA都可以由非管理员用户来任,而其他的语言(除了中维)不是这样。所以,相似的中维应该也添加一本地例外。--安忆Talk 2021年4月2日 (五) 11:52 (UTC)
技术设置限制页面所载,其实背后逻辑就是要减少可修改“MediaWiki”空间之下及其他指定之“.css/ .js”页面之人数,降低保安风险。界面管理员能不能完全掌控这些页面根本不在考虑之列。照这个逻辑再推演下去,就是应该将界面管理员限制成只有现任管理员才能申请,那就逻辑及运作上完全自洽。若然不想有这个修改,那就要承认会有这些限制,并且接纳。完。--J.Wong 2021年4月3日 (六) 06:36 (UTC)
改方针也可,因为现在编辑权限也是受限的,这是最简单的方式。是不是要重新讨论下这个。--安忆Talk 2021年4月3日 (六) 06:46 (UTC)
(!)意见:删除页面拿掉,其他的可以整合进界面管理员权限。--Googol19980904留言) 2021年4月3日 (六) 08:28 (UTC)
delete是这次话题的起点。--安忆Talk 2021年4月3日 (六) 10:17 (UTC)
找到一处讨论界面管理员缺少权限的页面:phab:T201052。从根源上检讨该问题,我认为界面管理员机制并未带来安全性保障的质变,某种形式的变更复核会好得多。而既然设立了该用户组,就应使权责相配。如今一项操作依赖于两项权限,设计者难辞其咎。--Lt2818留言) 2021年4月3日 (六) 09:38 (UTC)
是没什么质变,只是用户组人数变少了,少到英维一千多管理员只有14个界管。和RfA一样的流程也没带来什么增益。--安忆Talk 2021年4月3日 (六) 10:11 (UTC)
认为IA有这些责任应是错误的期待,除了删除全站JS/CSS以外,都不是IA的工作,而是管理员的工作,界面管理员是“JS/CSS管理员”,不是“技术管理员”,这可能是源自于初期设立的命名不当,但现在必须纠正。--Xiplus#Talk 2021年4月3日 (六) 10:27 (UTC)
我没这个误解。刚刚研究了一下,要让管理员能删除全站JS/CSS只需改动此处代码,而让界面管理员仅能删除全站JS/CSS估计要另立权限。--Lt2818留言) 2021年4月3日 (六) 12:22 (UTC)
此回应是针对前次提议中对于editcontentmodel所列举的请求,以及AnYiLin认为内容模型可归作界面,这两件事。--Xiplus#Talk 2021年4月3日 (六) 12:55 (UTC)
对于究竟能不能并进IA,系统管理员有最终决定权,想这么提议的人请直接去问系统管理员,我们在这里讨论猜测没有意义。--Xiplus#Talk 2021年4月3日 (六) 13:29 (UTC)
个人觉得是可以看能不能新增一个权限叫deletejscssjson能删除那些内容模型的页面,原本的delete则排除之类的比要求添加delete来的实在。
话说@Lt2818:为什么需要加move?貌似不必要。-- Sunny00217  2021年4月5日 (一) 14:21 (UTC)
  1. 需要改软件代码,改完后全都站点都适用,就不只是中文维基之事了。
  2. 不是我加的……可以看编辑历史,我也无意再做更改。--Lt2818留言) 2021年4月5日 (一) 17:01 (UTC)
    ...ok,看到了,只是@AnYiLin:巡查回退没有move吧...-- Sunny00217  2021年4月7日 (三) 09:58 (UTC)
    有办法只应用到单一站点。技术上该怎么处理,这是系统管理员的事,但能不能这么做,也是他们决定的,请咨询他们。--Xiplus#Talk 2021年4月7日 (三) 10:57 (UTC)

早在近三月前,我便问过了编辑类权限。但,编辑类权限都要不来,我对删除类权限和其他杂七杂八的权限更不抱什么希望。提出这些讨论只是看看在社群共识下能否使系统管理员做出些许改变。--安忆Talk 2021年4月8日 (四) 05:04 (UTC)

{{中国一级行政区信息框}}

{{中国省份}}的文档里有说模板的正式名称应为模板:中国一级行政区,所以我做了一个{{中国一级行政区信息框}}来完善这项工作,新的模板以{{Infobox settlement}}为基础,原来的模板样式与Infobox settlement高度相似,估计也是参考的这个模板,所以直接用它来进行定制,方便维护。参数尽量减少,因为只有那几十个模板在用,太多参数没有必要。{{中国一级行政区信息框}}现在是一个初步的版本,有些细节可能不完善,大家可以帮忙完善这个模板。如果要替换到条目中的话需要改几个参数,参考示例。--Vozhuowhisper 2021年4月3日 (六) 04:11 (UTC)

看了一眼,差一个面积占全国百分比参数,和有时候陆地面积和总面积要分开排名,有时候会插入参考资料,拼接文字后变成:第3[4]名。🌟🌟Talk 2021年4月4日 (日) 02:22 (UTC)

地图模板错误

2021年太鲁阁号列车出轨事故及最近的几篇新闻动态条目的信息框地图在缩略图模式下,未能正确显示坐标标签,放大后显示正常,究竟是什么原因?--百战天虫留言) 2021年4月3日 (六) 14:10 (UTC)

Tech News: 2021-14

2021年4月5日 (一) 19:40 (UTC) —以上未加入日期时间的留言是于2021年4月6日 (二) 00:14 (UTC)之前加入的。

IABot又失灵了

如题[5]Fran·1001·hk 2021年4月8日 (四) 02:55 (UTC)

权威控制(Authority control)不显示 & 其他技术提问(表格)

我看有一英文条目使用{{Authority control}},引用维基数据Q53093中的MBW(MusicBrainz work ID)代码是2e6a5df9-5a42-4223-97ea-1d4f359ee62b。可是当我加{{Authority control}}到相应中文条目时,却什么也没显示,是中文维基这里缺了什么吗?——George6VI留言) 2021年4月8日 (四) 06:32 (UTC)

中文维基的Module:Authority_control未收录P435。--YFdyh000留言) 2021年4月8日 (四) 09:47 (UTC)

另外有一个问题:我要怎么让这个表格的每一行(直向)宽度一样,宽度就随最宽的那一行的宽度而定,不要自动调宽度,就除了黑体字的之外其他都宽度一样?——George6VI留言) 2021年4月8日 (四) 08:50 (UTC)

{{=}}属不属于WP:魔术字

如题,上次的签名指引修订允许在签名中使用魔术字,相关条文:Wikipedia:签名#魔术字,然而刚才无意间看到了User:IN的一则留言Special:Diff/62308824,其指出User:乌拉跨氪的签名因含有{{=}}所以违规,并且发现该用户留下的方案正好是一个“=”符号无法使用的模式{{subst:resubst|=}}(这是技术限制,等于符号“=”会优先作为参数指定的关键字),参见测试Special:滥用日志/3687941。(注:{{subst:resubst|1==}}才能正常输出内容

根据T:=/doc

当使用模板时,里面参数中的HTML语法中含有等号会造成显示异常,就连nowiki也无法幸免。然而,使用{{=}}就没有问题。


—— T:=/doc

签名中会有技术问题偶尔需要使用{{=}}解决。

以上,欢迎讨论-- 五岁抬☎️·☘️) 2021年4月8日 (四) 10:11 (UTC)
不就是模板吗?{{=}}。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年4月8日 (四) 11:24 (UTC)
(:)回应Template:!也有对应页面。然后phab:T91154还没研究为何卡那么久没有部属。如果他不会变动的话,是想把它视为“软魔术字”、“伪魔术字”或“准魔术字”。-- 五岁抬☎️·☘️) 2021年4月8日 (四) 12:23 (UTC)
只是本站点设计成模板,如果你去mw看一下,mw没有将{{!}}弄成模板,而保留为魔术字实现。如果没记错,将{{!}}弄成模板比弄成为魔术字还要早(?)——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年4月9日 (五) 00:42 (UTC)
是的,从日志纪录以及存废讨论纪录Wikipedia:页面存废讨论/记录/2015/01/12#Template:!可以看到2006年12月15日因高风险模板被保护,2014年和2015年间则经历速删与AFD,理由为“已转为魔术字”随后改为软重定向。根据phab:T91154,英文维基en:template:=将之注解为“This template will soon be deprecated, as the {{=}} will soon be a Magic word.”很有可能未来某一天{{=}}会发生与{{!}}相同的遭遇。-- 五岁抬☎️·☘️) 2021年4月9日 (五) 02:25 (UTC)
技术上它本质就是模板,不需为其取额外的名称。--Xiplus#Talk 2021年4月9日 (五) 01:25 (UTC)
那是“现在”是模板,根据phab:T91154以及英文维基en:template:=注解“This template will soon be deprecated, as the {{=}} will soon be a Magic word.”,未来某天他会变成“不是模板”。“软魔术字”、“伪魔术字”或“准魔术字”可能不准确,那么就“候选魔术字”。-- 五岁抬☎️·☘️) 2021年4月9日 (五) 02:25 (UTC)
到时再处理?或者将其也纳入特例情况(因为技术上需要)。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年4月9日 (五) 03:36 (UTC)
您可以加上跟enwiki一样的描述,但不需为它取个名字。--Xiplus#Talk 2021年4月9日 (五) 04:22 (UTC)
当前是模板,修改前不是魔术字。这个=的效果不太可能改变,视作签名指引的例外就好,不涉及指引提到的理由。--YFdyh000留言) 2021年4月8日 (四) 11:54 (UTC)
所以我现在的签名还有问题吗?。。。。乌拉跨氪 2021年4月8日 (四) 13:42 (UTC)
无。--安忆Talk 2021年4月8日 (四) 14:06 (UTC)
我还没想到任何会将签名放在模板参数值的范例,谁能给个范例吗?(“{{subst:1x|~~~~}}”不受影响,要已展开的签名放在模板匿名参数才算)--Xiplus#Talk 2021年4月9日 (五) 01:32 (UTC)

是否应将“回复”预设简繁转换为“回覆”?

现在是预设转换为“回復”。简化字“復”和“覆”都简化为“复”,个人认为简体中文使用者用“回复”时多为表达“回覆”(即答复)的意义,而多用“恢复”来表达“回復”义。但这也可能只是我本人的使用习惯和所见,故望寻求社群共识。--Austin Zhang留言) 2021年4月8日 (四) 14:43 (UTC)

  • 百度百科说回复的意思是“答复、回答,一般多用于书信”[6],繁体字对应的就是“回覆”[7],而“回復”的意思是“复兴、恢复”[8],所以你的主张没错,确实应该如你所说进行修改。--Googol19980904留言) 2021年4月9日 (五) 07:24 (UTC)

Twinkle更新 (2021-04-09) @ad96204

近期变更
  • 速删:已加入CSD R8选项。
  • 连入:“连入/反链”功能现在已更名为“取消连入”,简称消连。
  • 设定:已从下拉式选单中移除“设定”连结,并在各功能表单中的右下角加入到对应功能设定页的连结,例如速删表单中的“速删设定”连结。

如果近期变更有任何错误,或是认为未来变更会造成任何问题,请在Twinkle讨论页互助客栈技术版Telegram群组Github择一报告。--Xiplus#Talk 2021年4月9日 (五) 05:37 (UTC)

简体模式下可以转换成“链入”“消链”而不是“连入”“消连”吗?谢谢。--砜中嘌呤的白磷萃取 打谱 2021年4月12日 (一) 13:21 (UTC)
完成。--Xiplus#Talk 2021年4月12日 (一) 13:52 (UTC)

Template:Unbulleted listTemplate:hlist问题

当条目同时使用Template:Unbulleted listTemplate:hlist,会让Template:Unbulleted list效果变成Template:hlist。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:23 (UTC)

具体是哪个条目,可否举个例子?我用预览测试似乎没有问题。--砜中嘌呤的白磷萃取 打谱 2021年4月12日 (一) 13:19 (UTC)

“以本地时区显示签名时间”小工具先于图表加载时导致无限递归

如题,图表是指 Graph 扩展画的图。复现方法:开启以本地时区显示签名时间,访问这个比较复杂的图表,必要时多刷新几次,等小工具在图表之前加载完,浏览器会卡死,控制台报错递归次数太多。一些测试:英文版工具似乎没有此问题。把mw.hook('wikipage.content')中的延迟setTimeout("checkScript();", 0);调高也可以避免该问题(毕竟这样基本就会在图表之后加载了)。 --砜中嘌呤的白磷萃取 打谱 2021年4月11日 (日) 02:51 (UTC)

今天我手动调试的时候也发现了这个问题,本来今天中午还想来报告的,结果发现刚刚好有人比我早一天报告了。我的问题是,为什么会发生这种事情,理论上用户签名跟图表应该是完全没有关系的才对啊--Milky·Defer 2021年4月12日 (一) 13:47 (UTC)
昨天测试了一下,因能力有限未查出原因。这个小工具看起来会遍历每个节点,估计与图表代码在操作相同对象时有冲突。不建议以调高timeout作为最终解决方法。--Lt2818留言) 2021年4月12日 (一) 17:59 (UTC)

调整外部链接备份功能

近期IABOT的故障事件频繁发生(例如phab:T269831en:User talk:Cyberpower678/Archive_76#IABot_Interface_down?),在经过造访其他语言维基百科时,特别发现了一项功能,就是透过布林值的方式去决定能否造访其他网站备份连结,以法语维基百科为例,其在类似Cite web标签的Lien web启用brisé le进行判断,无论其的参数值为何,一旦没有辨识到archive-url的值,便会将连结从预设的蓝色更改为红色,视同连结失效的状态,并搭配lien brisé的功能强制启动协助读者访问页面存档的功能。

据法语维基百科的功能展现,其站点备份不仅包含现在IABOT负责处里的互联网档案馆,更涵盖其他的网页备份服务,例如archive.is、Wikiwix、Google页库存档等服务,当然中文维基百科亦可调整涵盖常用的WebCite,在此提请大家讨论,并为相关的问题进行解套,以防止IABOT失灵所造成的编辑困扰。--🍫巧克力~✿ 2021年4月12日 (一) 07:20 (UTC)

Line numbering coming soon to all wikis

-- Johanna Strodt (WMDE) 2021年4月12日 (一) 15:09 (UTC)

翻译:

Emojiwiki对话页 | 用户贡献)于2021年4月13日 (二) 11:13 (UTC)翻译