维基百科:互助客栈/方针/存档/2022年4月

提议为引用网络资源不填URL链接参数的行为设立警告或过滤器

今天巡查尹锡悦条目时发现有编辑照搬英文版和韩文版引入的网络资源，但是没有附上相应的网址。虽然相关问题已被本人修复，但本人觉得引用网络资源时一定要填网址，方便读者查找相关内容出处。在此提议设置警告或过滤器，提醒编辑者添加网址。--百战天虫（留言） 2022年3月10日 (四) 16:49 (UTC)

编辑差异？--Xiplus#Talk 2022年3月12日 (六) 04:13 (UTC)

是说这篇条目的？--百战天虫（留言） 2022年3月13日 (日) 07:10 (UTC)

对，最好再多提供几个其他条目的。--Xiplus#Talk 2022年3月15日 (二) 04:57 (UTC)

编辑差异见这里，相关问题纽黑文也有。--百战天虫（留言） 2022年3月16日 (三) 09:32 (UTC)

如果能提醒一下比较好，看了前面的尹锡悦，好像原编辑像是直接从视觉化编辑上复制的，也有可能不太熟悉使用 {{cite xxxx}}模板，也有些是直接用书目数据库提供的引用格式。如果用源代码模式复制参考文献比较好。--Kethyga（留言） 2022年3月24日 (四) 13:38 (UTC)

看过了，不过ref标签又不是仅能用在参考文献，也可能正常输入纯文字的情况吧？应该无法用过滤器判断。--Xiplus#Talk 2022年3月24日 (四) 13:43 (UTC)

如何判断？是说在应用Cite web模板时没有添加URL参数之类的操作吗？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年3月23日 (三) 17:03 (UTC)

T:cite news允许不用填url参数(有些来源只有线下资料)-- Matt Zhuang表示有事按“此”留言 2022年4月3日 (日) 06:13 (UTC)

应该这样说，Cite web一定要网址，但是Cite news不一定。--Ghren🐦🕒 2022年4月3日 (日) 07:19 (UTC)

技术上，{{cite web}}，{{cite podcast}}，{{cite mailing list}}三个模板，如果不填URL会报错。但目前的设定下，该条信息默认隐藏。如果社群觉得有必要的话，可以考虑取消隐藏，如不填URL直接红字报错提示编者。--Antigng（留言） 2022年4月11日 (一) 15:59 (UTC)

podcast不一定有网址吧，因为电台节目不一定有回播。当然没有回播的来源是不是好的来源是个问题。--Ghren🐦🕛 2022年4月11日 (一) 16:16 (UTC)

貌似按定义Podcast是有网址的，没有线上回播的其它视听节目来源可以用{{cite AV media}}，后者不强制要求填写url。当然技术上，强制填写url的模板种类也是可以配置的。--Antigng（留言） 2022年4月11日 (一) 16:41 (UTC)

也就是这里方法实际上是错误的。简单看了目前引用的一百例左右，基本上都有url，加上看似没有问题。--Ghren🐦🕒 2022年4月11日 (一) 19:11 (UTC)

设立站务维基

于Phabricator查看
编号T299590的任务

在下提议设立本站的站务用维基。前期讨论存档在此，概述如下：去年LTA模仿犯泛滥，困扰站务，故在下重提设立LTA命名空间。后由于此提议不可行，社群转而讨论设立LTA维基的可行性，部分建议认为新维基用途不宜局限于LTA，并提出站务维基的构想。另外，设立站务维基也有配合IP masking等方面的考虑。

目前站务维基设立大致需要讨论两方面内容：

1. 是否应设立，或只作为LTA维基
2. access的门槛和申请方式（CA志愿者认为不能SUL）

以上。 ——魔琴 [ 留言 贡献 ] 2022年3月4日 (五) 16:12 (UTC)

仍然认为没有设立之必要。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年3月4日 (五) 18:29 (UTC)

根据雪球法则 ,(－)强烈反对--Pavlov2（留言） 2022年3月5日 (六) 18:57 (UTC)

我上次来都没留意到，雪球法则不是随便抛出来就用来反对提案什么的，你好歹也解释一下吧。--路西法人𖤐 2022年3月15日 (二) 13:33 (UTC)

改票( ✓ )同意。sysop们辛苦了----仁爱亲诚的Pavlov2 2022年3月17日 (四) 15:50 (UTC)

反破坏工具的建立刻不容缓。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月29日 (二) 13:21 (UTC)

鸡肋。不会反对，但是不值得投入心力。--Ghren🐦🕐 2022年3月7日 (一) 05:28 (UTC)

不反对，虽然上次是说有条件支持，但还是觉得必要性不大。要两个维基之间切换以进行同一项目的维护工作偏麻烦。--路西法人𖤐 2022年3月8日 (二) 02:49 (UTC)

• 叠床架屋很好玩？-某人✉ 2022年3月12日 (六) 03:58 (UTC)
  • @AINH、Pavlov2：您可能有所误会。这是去年年初的命名空间案，当时讨论的MOS、LTA和维基专题，维基专题顺利成为名字空间；LTA命名空间虽然公示通过，但LTA命名空间因技术限制（仅特定权限的用户能访问特定名字空间的扩展不会在任何维基站点部属这跟当时WP:修订巡查状况很像，本地公示通过，但基金会技术人员说“此扩展不会在任何维基站点部属”。）而无法实施，被phab人员拒绝部属，phab:T299546，而基金会技术人员则建议创立新维基来达成“仅特定权限的用户能访问”的等价效果（先例 https://sysop-it.wiki.x.io phab:T256545）。phab:T299590。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月12日 (六) 04:18 (UTC)
    • @AINH：简而言之，这并非叠床架屋，而是去年的已通过的共识的提案，被基金会技术人员评估技术上可能有困难，而建议的折衷方案，与其说叠床架屋，我认为更是需求和工程师实作之间的冲突。同时基金会技术人员提出的折衷方案因与原始社群共识通过的提案有所不同，因此基金会技术人员才叫我们社群再讨论一次，然而现在大家因不了解实情又反悔，这样对基金会技术人员工程师很不礼貌。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月12日 (六) 04:31 (UTC)
      • 大家同意的技术上不可行的方案跟大家不同意的技术上可行的方案可是两回事。这只体现本地立法常常未有咨询技术意见的无奈事实而已。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年3月12日 (六) 09:28 (UTC)
        • (：)回应@Ericliu1912：并非未有咨询技术意见。相关扩展去年U:魔琴去meta问过了，他们说可以跑跑看流程，结果共识出来提到PHAB后却变成“此扩展不会在任何维基站点部属”；上次的Wikipedia_talk:修订巡查#引入修订巡查_(重提编辑审核/稳定版本)也是，一开始PHAB也有再尝试弄，但弄到一半又变成“此扩展不会在任何维基站点部属”；Help:图书也是，通过共识后说什么pdf繁简转换系统爆了，所以不部属。怎么能说“并非未有咨询技术意见”？是他们评估不够全面吧。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月12日 (六) 10:42 (UTC)

          @A2569875：他是说要有人维护吧（修订巡查是写最早版本的人的错，要在其他地方用得有人重写）--SunAfterRain 2022年3月13日 (日) 09:29 (UTC)

          • 结论还不是都“此扩展不会在任何维基站点部属”，照样就是无法使用。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月20日 (日) 07:28 (UTC)

Correction：LTA命名空间没过公示，但只是技术原因，本地在公示期间未提出其它反对意见。上次讨论站务维基的时候一片绿色，我重提一下又反应平平 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年3月12日 (六) 11:58 (UTC)

• 不反对-某人✉ 2022年3月12日 (六) 22:00 (UTC)

不反对。--在下荷花，请多指教（欢迎签到） 2022年3月21日 (一) 12:50 (UTC)

---

鉴于无反对意见，且即使计入讨论FlagRev的留言也已两次触及WP:7DAYS，故🕗 公示设立站务维基，为期7日，2022年4月9日 (六) 15:35 (UTC) 结束。 ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:35 (UTC)

是不是应该讨论了一些基本规则才公示较妥。--Ghren🐦🕛 2022年4月2日 (六) 16:33 (UTC)

(－)反对：我不认为现阶段值得建立独立于本站的系统。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年4月3日 (日) 05:38 (UTC)

你就当作这只是一个新命名空间，只是这个“命名空间”放得比较“远”。且本案原先就是命名空间案，但是被基金会技术人员说技术限制提出的折衷方案。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月3日 (日) 06:14 (UTC)

且不认为是“独立”只是为了做检视权限管控。且这也是本意—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月3日 (日) 06:15 (UTC)

两个站就是两个站。分开的必要性为何？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年4月3日 (日) 14:57 (UTC)

欲设置限制检视权限只能分设一站。 ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 01:03 (UTC)

@Ericliu1912. ——魔琴 [ 留言 贡献 ] 2022年4月14日 (四) 13:54 (UTC)

目前(－)倾向反对，架构和细节缺乏讨论，过于模糊。历史数据迁移会是麻烦事。打算如何避免门槛过高或过低、复制泄露内容？phabricator中有人提到基于Toolforge的工具，是否有可能。--YFdyh000（留言） 2022年4月3日 (日) 09:26 (UTC)

• 鉴于目前出现明确反对理由，公示暂停直到共识重新产生。--拒食木瓜 2022年4月3日 (日) 13:00 (UTC)

  应该先讨论（1）放在哪里，可以是WMF production、Cloud VPS或者Toolforge；（2）用途：只用于放LTA还是其他和站务相关；（3）名称：zh-lta/zh-internal/zh-maintanence等等。明确之前不应该立即公示。--GZWDer（留言） 2022年4月4日 (一) 18:16 (UTC)

  更关键的是，如何保障数据安全（完整性和防泄露），进入门槛是明确还是模糊审核，不然只是将数据转入看似安全的黑箱。--YFdyh000（留言） 2022年4月4日 (一) 18:42 (UTC)

  Toolforge上放不了MediaWiki实例吧。Cloud VPS的效果可以参考一下这个站点，但存在一个比较麻烦的问题是依赖于少数社群成员的维护（换句话说如果维护者不活跃了就很麻烦）。如果是如phab提案那样放到s5的话，那整体流程可以参考意大利语那个现成的例子。另外还需要确认的是准入门槛的问题。 Stang^★ 2022年4月5日 (二) 00:43 (UTC)