维基百科:互助客栈/其他

维基百科,自由的百科全书
跳转至: 导航搜索

互助客栈消息发表 · 方针发表 · 技术发表 · 求助发表 · 条目探讨发表 · 其他 知识问答发表
快捷方式
WP:VPM
Breezeicons-apps-48-braindump.svg

本页讨论与维基百科有关的话题,但不包括新闻方针技术求助条目繁简处理

  • 如果您需要就具体条目应当如何编辑才符合中立性原则寻求社区共识,请前往条目探讨留言。
  • 请在主题栏简明扼要地写出问题主旨不要使用如“新问题”等无意义的文字。
  • 请勿公开姓名、地理位置、电话、电子邮箱地址等联系资料。我们通常只在此页回应,并不利用电子邮箱或电话等私下回应。
  • 无关维基百科项目的问题,请往知识问答相关页面询问。

请注重礼仪及遵守方针与指引,一般问题请至互助客栈/其他知识问答提出,留言后请务必签名(点击 Signature button from WikiEditor extension.svg )。


发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 ‎User:Panzer VI-II当上管理员后滥用职权 7 7 Z7504 2018-01-17 21:40
2 删除所有的纯繁简重定向 37 12 Bluedeck 2018-01-21 09:34
3 希望平反User:H1260156890 13 8 Cwek 2018-01-20 08:21
4 文内引用摆放的位置 1 1 Jimmy-bot 2018-01-21 08:42
5 增加unblock-zh票据工单系统站点的意见调查 32 11 Dingruogu 2018-01-16 22:03
6 建议Template:GA重定向 7 4 Xiplus 2018-01-15 10:44
7 如何对Flow(结构式讨论)的话题请求快速删除? 6 3 Xiplus 2018-01-17 23:19
8 设置Portal和Portal talk名字空间的中文别名 7 5 星耀晨曦 2018-01-18 23:48
9 Tat Flip乐队被经常骚扰! 2 2 NHC 2018-01-19 17:55
10 已删除的贡献 14 7 YFdyh000 2018-01-21 10:35
11 {{expand}}与{{asbox}} 2 2 YFdyh000 2018-01-21 10:26
12 Citation needed的中译 5 4 YFdyh000 2018-01-21 10:44
更新图例
最近1小时内
最近1日内
一周内
一个月内
逾一个月

‎User:Panzer VI-II当上管理员后滥用职权[编辑]

该用户是维基老手,但开了小马甲申请成为管理员后大部分时间都在行使特权,没有多少实质贡献,很多条目的有用内容都被他回退又不予以加上,令人很不愉快。183.240.197.187留言) 2017年12月30日 (六) 16:59 (UTC)

能否提供证据?--Wcam留言) 2017年12月30日 (六) 19:19 (UTC)
"令人很不愉快""开了小马甲",鸭子 一望而知User:Huleizhulei。--Innocentius Aiolos 2017年12月31日 (日) 05:56 (UTC)
当上管理员?他Panzer几天不见,居然就被“滥权行政员”变成管理员了?[开玩笑的]另,以阁下(鸭子 一望而知User:Huleizhulei)的编辑来看,存在许多让其他维基人无法接受的地方。--云间守望 2018年1月1日 (一) 11:19 (UTC)
前来围观。值此新年佳节来这么一出节目,我能笑一年。看来今年是充满欢笑的一年。--HAL Le Révocateur 2018年1月1日 (一) 14:35 (UTC)
注:此处原有文字,因为用户不文明发言,已由꧁༺星耀晨曦༻꧂留言)于2018年1月10日 (三) 07:57 (UTC)删除,尚祈见谅。若有异议请至互助客栈或向管理员反映。

删除所有的纯繁简重定向[编辑]

提议删除纯粹的繁简重定向,如哈薩克 => 哈萨克。这种重定向大多是早期(>10年前)MediaWiki尚不支持标题自动转换的遗留产物,如今MediaWiki已支持自动转换,无须建立重定向。经测试,删除不会对现有页面造成任何影响。保留这种重定向,不仅会使浏览器出现讨厌的跳转,更重要的是会破坏模板的页面识别,导致模板在目标页面下无法加粗。不如全部删除,以绝后患。--Yangfl留言) 2018年1月5日 (五) 07:51 (UTC)

(-)反对,编辑摘要仍会红字的,而且当繁简转换器失灵时,失灵期间还有重定向作后补。导航模板的连结本来就应该使用繁简一样的字,繁体条目在导航使用简体连结本来就不鼓励,反之亦然,加粗问题应当把导航连结的繁简修改为与条目名称一致来解决。(事实上删除了重定向还是要跳转,衹是把跳转过程改了在幕后做,而且其跳转过程比繁简重定向还更复杂)--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 08:26 (UTC)

删除繁简重定向会发生三个问题:

  • 编辑摘要会出现红字
  • 仰赖繁简转换系统,运作负担比繁简重定向高
  • 条目超过某个长度后,连结不会转换

113.52.65.202留言) 2018年1月5日 (五) 08:53 (UTC)

  • 编辑摘要红字是假红字,点进去以后就会自动跳转,而且编辑摘要本来就是作为历史出现的,有错别字也不能改。且目前的条目早就严重依赖自动重定向,若是要解决这个问题,那得为每个条目都建一个同名繁简重定向。为了避免重定向/不加粗,势必要求在繁体文本中出现简体字,对平常使用繁体输入法的编者极度不友好,反之亦然。而且在幕后跳转的体验远胜于在浏览器跳转,在浏览器跳转会出现明显的卡顿,对读者不友好。--Yangfl留言) 2018年1月5日 (五) 09:07 (UTC)
    • 没有了繁简重定向,载入时间会其实更卡,因为幕后要多做一次搜索、转换、缓存转换结果、跳转、事后删除缓存,有繁简重定向就衹有跳转便行了。假红字使人误会在管理上比改手动改繁简还要困扰。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 09:21 (UTC)
      • 历史记录本就不是面向最一般读者的,作为管理本身就要判断一下,显然是要优化读者的体验而不是少部分管理的体验。对于热门页面,所有结果都是缓存住的,无论有没有重定向都没有影响。有重定向,在浏览器端体现为302,中国区到美国的rtt至少是200ms,而且还会更差。有一次重定向,打开页面的时间就要多加半秒不止,相比之下哪个更卡?--Yangfl留言) 2018年1月5日 (五) 09:37 (UTC)
        • 无论冷热门,明显也要多做一次搜索才知道哪个页面的缓存才对,多做一次表示服务端多了动荷,服务器有更大负担,缩短寿命。而且像管理员所说,繁简转换坏掉要怎么办?没修复之前就只有躺着让人看红字?还有转换限制问题要用重定向解决,每个都建立一个同名重定向其实真的较好。113.52.65.202留言) 2018年1月5日 (五) 10:13 (UTC)
          • 服务器缩短寿命?XD,服务器不用才掉价,你以为是桌面电脑?每个都建重定向,量级至少是十万级别,那才是真正巨大的负担。繁简转换开了那么多年,未见有坏的情况,而且我说的是纯繁简重定向,不含用字有差异的重定向。真要坏了还是考虑怎么打开网站的问题吧。--Yangfl留言) 2018年1月5日 (五) 10:31 (UTC)
            • 繁简转换是动态负担,重定向是静态负担,一个动态负担用的资源比千万个静态负担较重,所以一定是会减寿的,而且服务器换硬盘应该比换CPU更容易吧。繁简转换以前是有坏过许多次,在故障的时候很多条目变成满堂红我也是见过的。--113.52.65.202留言) 2018年1月5日 (五) 11:06 (UTC)
              • 无所谓动态负担还是静态负担,wiki缓存机制决定了不管是什么页面,哪怕是纯文字,都会有缓存,除非全局禁用缓存,不然这个动态负担一定会存在。炸掉只是偶尔一两次,我认为不应该为这不足1%的时间影响了99%的体验。--Yangfl留言) 2018年1月5日 (五) 11:56 (UTC)
                • 下面的测试证明了缺少重定向会产生较长的让人讨厌的跳转时间,动态负担明显是加了,删除重定向才真的是影响读者体验啊~-113.52.64.53留言
对于服务器性能问题,请看Wikipedia:不要担心性能。——路过围观的Sakamotosan 2018年1月8日 (一) 01:26 (UTC)
对于载入速度,我就找两个条目实测了10次,其实不论有无重定向都有出现了302:
  • 在搜索栏输入没有做重定向的繁体“于斯納爾斯貝里市”连到简体“于斯纳尔斯贝里市”条目,总载入时间平均花了2.66秒,302部分平均花了887ms
  • 在搜索栏输入有做重定向的简体“2004年澳门华榕大厦纵火案”连到繁体“2004年澳門華榕大廈縱火案”条目,总载入时间平均花了1.89秒,302部分平均花了355ms
而且后者条目长度比前者还要长,后者有重定向下竟然还要比前者无重定向更快,可见繁简转换不但没有改善载入体验,繁简转换反而比重定向来得更差更卡。最后补个实测数据:
于斯纳尔斯贝里市
(透过繁简转换)
2004年澳门华榕大厦纵火案
(透过繁简重定向)
302时间(ms) 总时间(秒) 302时间(ms) 总时间(秒)
1 984 2.9 322 1.79
2 718 2.39 313 1.95
3 781 2.5 438 1.84
4 827 2.51 314 1.95
5 937 2.82 469 1.86
6 1234 3 423 1.9
7 765 2.62 313 1.64
8 734 2.47 297 1.72
9 812 2.51 330 2.22
10 1078 2.86 328 2.01
平均 887 2.658 354.7 1.888
--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 13:24 (UTC)
这个之前不是讨论过了吗?讨论的结果就是我的bot,自动挂{{繁简重定向}}。--Antigng留言) 2018年1月5日 (五) 14:36 (UTC)
这个题目不知炒了多少次冷饭了—— 囧rz... --街燈電箱150號 开箱维修 抄表 检验证明 2018年1月5日 (五) 14:50 (UTC)
简而言之:没坏别修。要找出所有符合条件的重定向要花费多少人力/给机器人编程调试时间?要建立规定后长期维护又要消耗多少人力/机器人力?为啥不节省下来干别的?—菲菇维基食用菌协会 2018年1月6日 (六) 18:21 (UTC)

反对。这里面含有编辑历史,shizhao上回把周润发的重定向删除了,被删除后无法透过直接点击找回(看不到那时候的编辑纪录了,要找回那个重定向必须从shizhao删除日志当中找)。等于把2004年以前,简体用户与繁体用户互相为对方建立重定向的历史性举动从直观的检索方式上一点一滴给抹除了。不要以为没有坏处,这种删除正在抹除中文维基的历史。--Jasonzhuocn留言) 2018年1月7日 (日) 03:35 (UTC)

如果保留繁简同等重定向,可以让页面一次性加载(重定向跳转被内化到相应页面请求中),不用依赖于繁简转换生成的隐藏302跳转。反而是链接解析部分无法识别重定向为解析页面时的预填黑才是bug吧。总之,没坏别修。——路过围观的Sakamotosan 2018年1月8日 (一) 01:31 (UTC)
我支持删除繁简重定向。我也觉得繁简重定向的用户体验不连续且糟糕,各种quirk不值得节省下来的处理器时间。看了街灯的时间对比,我觉得这个overhead完全可以接受。不一定要积极的清除掉所有的繁简重定向,但是主编想删哪个删哪个是可以的。Bluedeck 2018年1月10日 (三) 14:30 (UTC)
删除重定向才是真正的体验不连续和糟糕,因为重定向后会被系统内化,载入时不需要找寻跳转,删除了后系统没有了内化定向,系统要每次找寻,删除繁简重定向造成的不连续事实是长了。--113.52.65.21留言
采用软件的目的就是要将复杂度内化而不呈现在用户面前,就算为此付出处理时间也是值得的。“事实上,网站没有任何内容时服务器性能才是最好的,但这样的话要维基百科还有什么意义呢?”——WP:不要担心性能Bluedeck 2018年1月11日 (四) 14:52 (UTC)
你们才没资格说不要担心效能,因为你们支持删除重定向的其中一个理由是宣称要减少浏览器出现讨厌的跳转,你们本身已经是担心效能。113.52.80.230留言) 2018年1月11日 (四) 15:46 (UTC)
"要减少浏览器出现讨厌的跳转"这是担心UX不是担心效能。Bluedeck 2018年1月12日 (五) 02:42 (UTC)
浏览器的302跳转时间和次数越多意味着传输掉失的风险越多,若在网络较差的环境,删除繁简重定向令读者载入失败而要重载的潜在机会变大,这才真的更多地令用户体验不连续和糟糕,删除繁简重定向事实上才是影响用户体验。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 04:56 (UTC)
这两个方法都是一次302啊,其中时长的区别来自后端繁简转换逻辑,所以没有这个问题。Bluedeck 2018年1月12日 (五) 21:28 (UTC)
您也懂得说“时长的区别”啊——怎么可能没有问题啊……时长越多表示了不连续得越多,也表示浏览器逾时而掉线的机率越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月12日 (五) 23:47 (UTC)
某个操作响应超时的概率只和请求次数相关,这两个请求次数都是2,没有更容易超时的问题。Bluedeck 2018年1月14日 (日) 22:40 (UTC)
超时机率当然不衹和请求次数相关啊……2次请求之间的时间越长表示掉失第二次请求的机会越多。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 05:10 (UTC)
不是这样的,两次请求之间的时间越长,说明第一次请求的处理时间长,和第二次请求会不会更容易掉线无关。请求1处理完了关闭之后开始请求2的那一刻起,这个请求2和任何一个独立请求都没有区别。Bluedeck 2018年1月15日 (一) 22:25 (UTC)
“第一次请求的处理时间长”这个已经够了,因为第一次做长了,错过趁网络还好的时候做第二次的机会变大,两个请求事实上或多或少都会有关系。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 23:37 (UTC)
不是这样的,实际上一点关系也没有。服务器处理请求的耗时并不是网络稳定性的诸多因变量之一,网络稳定性仿佛投色子,不会因为等久一点再投,色子的某个结果的几率就变大或变小。你可以在网络稳定性良好的localhost做long polling,第一个请求等二十分钟再返回,第二个请求一样强壮。Bluedeck 2018年1月17日 (三) 05:53 (UTC)
两次请求是读者由按下连结至载入完成的这一整个过程的必经阶段,怎么都不可能视为无关系,而且网络稳定度的确是两次传输之间的时间越短则得到较接近的结果的机会越大,才不是投骰子那般没时间观的道理。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月17日 (三) 15:31 (UTC)
街灯君,不是这样的。。。。HTTP是个无状态协议。和投色子是一样的。Bluedeck 2018年1月20日 (六) 00:46 (UTC)
呃……这不仅是HTTP的考量来的。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月20日 (六) 05:45 (UTC)
那是什么考虑?跟HTTP没关系,跟TCP和更下层的协议就更没关系了。Bluedeck 2018年1月21日 (日) 00:18 (UTC)
  • (-)反对:繁简重定向属于zh版维基百科中不可或缺的--Z7504非常建议必要时多关注评选留言) 2018年1月13日 (六) 05:09 (UTC)
(-)反对,jasonzhuocn的理由已然足够。--Temp3600留言) 2018年1月15日 (一) 16:41 (UTC)
(+)支持不觉得这种东西有什么不可或缺的,1秒的延迟毫无所谓,先不说掉线不掉线,就算掉线又能有多少?写条目还要改模板才是真的烦。我对删除旧的重定向没什么看法,只是觉得没有任何必要建立的新的重定向--浅蓝雪 2018年1月20日 (六) 16:58 (UTC)
(つ°ω°)つ 浅蓝雪 Bluedeck 2018年1月21日 (日) 01:34 (UTC)

希望平反User:H1260156890[编辑]

他是被错误地封禁的。--CuSO4 2018年1月6日 (六) 04:20 (UTC)

Wikipedia:保护方针允许对能确认去世的用户的用户页进行保护,最后当事人声明只是退出而非去世则可。——路过围观的Sakamotosan 2018年1月6日 (六) 06:51 (UTC)
但是Wikipedia:封禁方针没有允许对去世用户进行封禁。--113.52.64.53留言) 2018年1月6日 (六) 07:31 (UTC)
可以去求助版看看?——路过围观的Sakamotosan 2018年1月6日 (六) 10:07 (UTC)
  • @Cwek 囧rz...我的重点不是这里。请仔细察看该用户的贡献记录:
    • 2016年7月12日 (二) 06:03 (差异 | 历史) . . (+88)‎ . . Wikipedia:页面存废讨论/记录/2016/07/06
    • 2016年7月12日 (二) 06:08 (差异 | 历史) . . (+3)‎ . . User:H1260156890(自己在自己的用户页上加入了{{death}}模板)
    • 2016年7月12日 (二) 06:48 Shizhao(讨论 | 贡献)封禁了H1260156890(讨论 | 贡献),到期时间为不限期 (账户创建停用、电子邮件停用、不能编辑自己的讨论页) (已去世)

该用户并没有去世!

望shizhao君自己注意一下:Smiley.svg@shizhao:--CuSO4 2018年1月9日 (二) 09:28 (UTC)

 已修复--百無一用是書生 () 2018年1月9日 (二) 09:55 (UTC)
最好不要“诅咒”挂掉,挂退休则可,如果不想继续的话。——路过围观的Sakamotosan 2018年1月9日 (二) 11:14 (UTC)
shizhao君始终没有解释是根据什么来封禁去世用户。--113.52.65.21留言) 2018年1月11日 (四) 05:15 (UTC)
只是出于安全考虑,防止账号被盗--百無一用是書生 () 2018年1月15日 (一) 01:59 (UTC)
防止被盗不是封禁方针允许的理由。113.52.80.25留言) 2018年1月15日 (一) 05:26 (UTC)
{{Death}}的模板文档有说明:“在用户页上自己挂上此模板可能会被认为已故,从而招致不限期封禁。请勿随意挂此模板。”--挤牙膏💬 2018年1月18日 (四) 17:35 (UTC)

突然好奇,除了用户自行挂过世模板以外还有什么办法可以让社群确认维基人已过世呢?有没有类似的方针或指引?----ParkerTian 2018年1月18日 (四) 21:57 (UTC)

非要说的话,可以用傀儡吧,因为账号假设只有一个真人操作,如果真人死了,理论上账号就不会再有操作,如果有的话,可能是傀儡。至于确认账户死亡,只能靠账户真人所熟悉的人去确认,实际上可能存在真人已死但没有确认到而没有挂标示的情况。——路过围观的Sakamotosan 2018年1月20日 (六) 00:21 (UTC)

文内引用摆放的位置[编辑]

加unblock-zh票据工单系统站点的意见调查[编辑]

目前我们的站外查封申诉以邮件列表的形式处理。我作为处理的管理员不太喜欢邮件列表这个系统。我想弄一个类似英文维基百科UTRS的票据工单系统,并加以美观的设计。

我认为这样做的好处有几个:用户界面可用性增加(对管理员和用户都是这样)、可以自定美观的用户界面、安全性增加(全程HTTPS、HSTS)、可以让用户自行选择那些信息可以公开,哪些信息需要保密、增加条理性,等等。

虽然如此,不知道大家的想法如何。因为建立这个系统这个工作量不小,我怕建出来了没人用,或者大家可能提出我还没有想到的问题。所以我现在这里问一下。

若您感兴趣技术细节:User:Bluedeck/etc/sandbox/box1515612315922

另:这个系统可以和当前的邮件列表系统并行运作。

Bluedeck 2018年1月10日 (三) 14:11 (UTC)

  • 支持支持支持!蓝桌说的我都支持!反正我又不是滥权管理员--Yangfl留言) 2018年1月10日 (三) 15:01 (UTC)
好大一个坑。为啥不host在toollabs?--百無一用是書生 () 2018年1月11日 (四) 03:20 (UTC)
因为听说性能太糟糕而且申请条件苛刻所以懒得申请,反正我手头有空转的服务器资源,所以就自己host。Bluedeck 2018年1月11日 (四) 03:25 (UTC)
工单系统的数据备份会怎么做?--菲菇维基食用菌协会 2018年1月11日 (四) 03:27 (UTC)
OS-wise snapshot、根目录手动gzip、SQL dump、API 导出。Bluedeck 2018年1月11日 (四) 03:36 (UTC)
网站必须开设在wmf的服务器上。如果有这个系统的话,这个系统应当被认为是官方性质的申诉系统。开在wmf的服务器下,维护服务器的终极权限掌握在wmf的手里,这与系统的官方性是相称的。相反,如果在个人服务器上架设网站,维护服务器的终极权限掌握在特定用户手里,没有人有权监督该站的运行,这可能会导致问题。--Antigng留言) 2018年1月11日 (四) 08:59 (UTC)
这个要求(或者这个要求的精神)是出自哪里的,wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛?Bluedeck 2018年1月11日 (四) 14:46 (UTC)
“wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛”,出于技术原因强制终止部分出问题的程序,这样的案例比比皆是。--Antigng留言) 2018年1月11日 (四) 15:26 (UTC)
原来如此。Bluedeck 2018年1月11日 (四) 17:57 (UTC)
理论上有官方性质的系统不应该放在wmf控制以外的地方;toollabs申请很简单,性能虽然糟糕但是做这个功能够了。--哪位维基人能够一下打死五个? 2018年1月11日 (四) 15:41 (UTC)
已经从tooladmin申请了membership,那么,我试试这个VPS。如果可以,我就在这里host。另外还发了邮件问问WMF的想法。Bluedeck 2018年1月11日 (四) 16:48 (UTC)
  1. WMFLabs上的东西原则上不允许存储隐私内容,而WMF运营的mailman跟WMFLabs是相互独立的;
  2. 自建服务器缺乏保障隐私的方式;
  3. 自建服务器难以保证稳定;
  4. 看了下你的sandbox,拖库了怎么办?最起码没看到这方面的考虑,好歹也得hash几遍;
  5. 带这么个系统就意味着跟随配套的所有教程(站内的以及站外的,比如你们经常用的那个解决IP封禁问题的截图等)、指南(WP:IPBE等)、模板(T:Block review等)、用户页面(MediaWiki:Blockedtext等)都得改;
  6. 如果不能保证稳定性,并试图用邮件列表作为备用选项的话,那么上面这些就准备天天改吧;
  7. 同上,反而增加新手使用成本;
  8. 会有很多人用?快去查查今天unblock里面总共才几封邮件
  9. 这玩意上线第一天就来帮你进行一下压(D)力(D)测(o)试(S)
  10. 顺便心疼你花了的域名钱
  11. 这么有钱的壕直接上keyless SSL多好(笑)

--Techyan留言) 2018年1月11日 (四) 19:06 (UTC)

如果建好了之后反而增加使用成本的话那我太失败了,我肯定是为了让使用更容易才建设这个的。sandbox里的数据结构是让你知道结构而已。安全方面,user.secret = SHA256(server_salt(m)), m=SHA256(client_salt(passphrase)),其中m的计算在客户端进行。稳定性方面,和服务器关系不大,现在哪个服务器不是99.999 uptime,关键是内存泄漏和exception别飞出去,这是我要解决的问题。最后我在这里问的是如果我做的好,大家用不用。如果我做出一堆垃圾来,那当然没人会去用 : /,你不用担心我做出垃圾之后逼着大家使用.... Bluedeck 2018年1月11日 (四) 20:35 (UTC)
是啊那你准备怎么解决#5、#6的问题?一般那VPS的uptime能上三个九就怪了,母鸡关几十分钟维个护都不带提前通知一声的;更何况机器稳定又怎么样,zhmrtbot都坏了多少次了
反正我感觉你如果实在闲就搞,但我个人不是很支持。并且技术上的讨论结束了之后不意味着社群就同意用这个东西(部分)替代现在的unblock机制了。--Techyan留言) 2018年1月12日 (五) 16:50 (UTC)
“并且技术上的讨论结束了之后不意味着社群就同意用这个东西(部分)替代现在的unblock机制了。”,我问的目的调查一下就是做出来之后社区用不用,不用我就不做了,不是为了讨论技术。“更何况机器稳定又怎么样,zhmrtbot都坏了多少次了”,所以说了不是机器的问题,而是软件的问题。还有,为了防止误会,再强调一遍,我调查的问题是:如果我做的东西好用,大家用不用,而不是如果我做出一个成天掉线的服务,还会硬要大家迁移到这上面。Bluedeck 2018年1月12日 (五) 20:51 (UTC)
是啊,我知道你的问题是这个,但是现在很明显没人在研究到底是用还是不用,反而都去计较技术方面的问题了。没什么人愿意出来研究到底用不用的原因一方面是话题被带跑了(锅当然我也得背);另一方面则是现在没个成品,或者一个像样的雏形,大多数人也很难定夺。这么说也只是提醒你一下,按照现在的讨论,完全有可能你做出来了东西但是社群不肯用。毕竟现在没有人明确地说支持。顺便,#5和#6的问题还希望解释一下,把话题往正道上带一带。--Techyan留言) 2018年1月13日 (六) 12:19 (UTC)
  1. 5,那就改呗,用模版改,这样只有改第一次比较费时。#6:上线之后肯定先腾出一段时间做稳定性测试啥的,没问题才投入使用。Bluedeck 2018年1月13日 (六) 20:26 (UTC)
直接用wiki账号认证登录不就好了--百無一用是書生 () 2018年1月12日 (五) 03:44 (UTC)
我研究一下api。Bluedeck 2018年1月12日 (五) 16:18 (UTC)
老实说,我觉得unblock-zh不便性让不少管理员却步,不太愿意处理(至少我是这样)。如果有更人性化的系统的话,处理上也比较容易。—AT 2018年1月12日 (五) 16:58 (UTC)
不能做一个建立在邮件列表之上的人性化的系统吗,而不是重新做一个新的系统出来。——꧁༺星耀晨曦༻꧂留言) 2018年1月12日 (五) 17:45 (UTC)
是吧,我也是这么想的,但是邮件列表能做的事情不多。只能美化一下界面,而且没有很多人用我这个模版。Bluedeck 2018年1月12日 (五) 21:12 (UTC)

真要搞的话不如重启引入OTRS系统的讨论。--云间守望对话 2018年1月13日 (六) 10:53 (UTC)

备注:在下十分信任Bluedeck的技术水平,只是考虑到隐私问题,建议还是放在维基媒体计划的服务器上。--云间守望 2018年1月13日 (六) 11:34 (UTC)
实际上这个系统的隐私和邮件列表的隐私没有区别,都是隐私内容所有管理员可见。Bluedeck是开发者兼管理员,所以本来就可见隐私内容。要说的话由于传输层安全的使用,这里只比邮件列表安全,而不是反过来。Bluedeck 2018年1月13日 (六) 20:33 (UTC)
什么叫好用什么叫不好用,没有一个客观的标准。空对空讨论“如果我的东西好用你们用不用”可能意义并不大,就像讨论“如果有一个完美的智能管理员机器人你们用不用”那样。所以还是建议先做出一点东西来再开展进一步的讨论。项目拿风险投资的时候也不是单纯有一个概念就可以的。--Antigng留言) 2018年1月13日 (六) 14:27 (UTC)
讨论的目的是为了知道有没有除了易用性之外的原因而会让大家不想使用的。比如上面有人提到的隐私问题,政策问题或者需求问题。如果有这样的问题存在,大家可以提出来,如果我觉得非技术性障碍太多,可以提前拉到,就是这个意思。Bluedeck 2018年1月13日 (六) 20:24 (UTC)
三个问题:
  1. 想不想使用:普通用户不会太关注这个问题,除非经常被封需要申诉;经常处理unblock的管理员讨论讨论就好了。
  2. 放在哪里:如果决定要做,把系统放在wmf控制的服务器上是比较合理的,而非个人的服务器,以免有一天这个人变成了破坏者
  3. 实现方式:OTRS是不是有现成的代码?可以把邮件对接到这个系统里,这样对于用户来说既可以邮件也可以上系统,而管理员有个统一的处理界面?
--哪位维基人能够一下打死五个? 2018年1月16日 (二) 14:03 (UTC)
  • (-)反对:没有必要,画蛇添足,粉饰镀金。galaxyharrylion留言) 2018年1月15日 (一) 14:34 (UTC)
    • 事实上unblock也没有必要,这个黑箱早已饱受诟病,而且一直都是被滥用的状态。galaxyharrylion留言) 2018年1月15日 (一) 14:38 (UTC)

建议Template:GA重定向[编辑]

如题,“Template:FA”有重定向至“Template:Featured article”、“Template:FL”也有重定向至“Template:Featured list”,那么“Template:GA”可否重定向至“Template:Good article”? 这应该合理吧,请讨论下,Face-smile.svg谢谢你--Z7504非常建议必要时多关注评选留言) 2018年1月12日 (五) 04:19 (UTC)

  • 合理而且这应该属于移动请求?--Yangfl留言) 2018年1月12日 (五) 11:54 (UTC)
    • 历史遗留问题,Template:Good article是GA条目右上角那个topicon.--云间守望 2018年1月13日 (六) 11:32 (UTC)
      • @WQL:正好就是有考虑这个才疑问,因为如果直接重定向,那么早期获选GA的讨论页还使用该模板的就无法显示了。唯一办法就是将现有的GA全部检查过,但很费时间--Z7504非常建议必要时多关注评选留言) 2018年1月13日 (六) 11:35 (UTC)
  • 要把{{GA}}替换成{{ArticleHistory}}吗?--Xiplus#Talk 2018年1月15日 (一) 01:47 (UTC)
    • 但不知道现有的GA还有几个在讨论页上是用“{{GA}}”的,另外(:)回应:是的,全数更换为“{{ArticleHistory}}”,因为现行存档在获选GA时也是使用ArticleHistory显示,而不用GA--Z7504非常建议必要时多关注评选留言) 2018年1月15日 (一) 01:57 (UTC)
      • 44个,算少,用个AWB半自动替换应该还行。--Xiplus#Talk 2018年1月15日 (一) 02:44 (UTC)

如何对Flow(结构式讨论)的话题请求快速删除?[编辑]

该如何对Flow的一个话题(Topic)请求快速删除?因为在上面放置模板不会进到Category:快速删除候选,我觉得最适合的请求位置应该是Wikipedia:修订版本删除请求了。目前似乎没有适合的处理方式,因此提出讨论。--Xiplus#Talk 2018年1月14日 (日) 08:56 (UTC)

我觉得可以在VFD处提出快删。Bluedeck 2018年1月14日 (日) 22:37 (UTC)

放在摘要里。如果放在摘要跟描述页的模板,如果该模板有分类,是会显示的。-- Willy1018(留言) 2018年1月15日 (一) 05:26 (UTC)

原来如此,那这个是没问题了。那么想要单独删除一则留言的话呢?--Xiplus#Talk 2018年1月15日 (一) 07:47 (UTC)
VFD说的就是删除一则留言的情况。因为模版请求的是整个页面的删除,VFD则可以任意请求删除的目标,或者像你说的那样RRD也行。Bluedeck 2018年1月15日 (一) 19:06 (UTC)
那我还是觉得RRD更适合删除一则留言的情况,比较接近deltalk+RD。--Xiplus#Talk 2018年1月17日 (三) 15:19 (UTC)

设置Portal和Portal talk名字空间的中文别名[编辑]

有些维基人希望翻译这两个名字空间的名称,@Liaon98CopperSulfateTenbeens

所以我提议设置PortalPortal talk这两个名字空间的中文别名为:主题主题讨论。——꧁༺星耀晨曦༻꧂留言) 2018年1月14日 (日) 10:23 (UTC)

(+)支持:已经成为实际的翻译惯例。--云间守望 2018年1月14日 (日) 14:41 (UTC)
(!)意见,纯粹主题两个字我第一时间联想到的是Topic:而不是Portal:,似乎会引起混淆,我建议用主题首页主题首页讨论。--街燈電箱150號 开箱维修 抄表 检验证明 2018年1月15日 (一) 23:45 (UTC)
(!)意见,Topic:应该是话题主题首页太过啰嗦,而且会让人想到真正的首页,何况Portal:下往往有一堆子页面,首页实在不妥。--Yangfl留言) 2018年1月16日 (二) 07:31 (UTC)
好像中文维基百科对Portal翻译为主题,很多模版也是主题。——꧁༺星耀晨曦༻꧂留言) 2018年1月17日 (三) 13:19 (UTC)
Gadget则可以译为小工具。——Arnie97留言) 2018年1月18日 (四) 14:50 (UTC)
这就是另一个议题了。——꧁༺星耀晨曦༻꧂留言) 2018年1月18日 (四) 15:48 (UTC)

Tat Flip乐队被经常骚扰![编辑]

香港乐队Tat Flip,在维基编辑经常被骚扰,Tat Flip编上的是有时间,历史和实证,不是广告宣传.—以上未签名的留言由Fliproom对话贡献)于2018年1月16日 (二) 02:52 (UTC)加入。

参见WP:G11,并请在留言后以四个波浪号“~~~~”签名。--NHC、人家才不是NPC呢哼! 。:.゚ヽ(*´∀`)ノ゚.:。 2018年1月19日 (五) 09:55 (UTC)

已删除的贡献[编辑]

Special:DeletedContributions只有管理员能够查看,但本人认为此页并没有不能开放给其他用户查看的理由? 建议更改使用权限,否则请说明让我了解下,谢谢。--Janee谈笑风生 2018年1月18日 (四) 10:14 (UTC)

访问Special:DeletedContributions应该需要deletedhistory权限。如要开放这个权限给普通用户,应发起讨论。——꧁༺星耀晨曦༻꧂留言) 2018年1月18日 (四) 10:31 (UTC)
能否只开放看自己的?--Yangfl留言) 2018年1月18日 (四) 12:56 (UTC)
应该不行。——꧁༺星耀晨曦༻꧂留言) 2018年1月18日 (四) 13:52 (UTC)
我觉得不如让巡回自动拥有此权限,其他人可申请获得。不过即使开放了感觉用处不大,也很难有什么合理的理由须使用此权限。--Yangfl留言) 2018年1月18日 (四) 14:14 (UTC)
如果都能看那删除页面的意义也不存在了。--Kuailong 2018年1月18日 (四) 16:00 (UTC)
我认为删除页面的意义与此并无关连,用户只是纯粹查看自己所贡献的页面哪些被删除而已,不然在贡献报告里突然已删除的贡献变多了,也觉得奇怪(虽然此功能用处不大)。--Janee谈笑风生 2018年1月19日 (五) 03:37 (UTC)
这是content而不是history,当然似乎mediawiki没有只开放看已删历史的功能,这又是好大一个坑。--Yangfl留言) 2018年1月20日 (六) 06:48 (UTC)
查看被删除的历史项目,不含相关文本 (deletedhistory)。——꧁༺星耀晨曦༻꧂留言) 2018年1月20日 (六) 10:29 (UTC)
en:WP:RESEARCHER。--Xiplus#Talk 2018年1月20日 (六) 14:20 (UTC)
虽然有Wikipedia:监督,但并不能十分全面,所以不能全面开放。性能也可能是个问题,已删除修订版本似乎存放在另一个数据库中,可能缺乏充足缓存和处理能力。--YFdyh000留言) 2018年1月21日 (日) 02:35 (UTC)

{{expand}}与{{asbox}}[编辑]

分类:扩充中的条目提到{{expand}}用于超过小条目标准,但仍然缺乏内容的条目。小条目应该是指小作品,但有时候{{expand}}及{{asbox}}在同一条目出现,请问在这情况下应否删去其中一个?--Alvinz 2018年1月19日 (五) 09:26 (UTC)

均可。expand的扩充意图更显著,如果需要扩充什么内容不够明显,可以摘掉。--YFdyh000留言) 2018年1月21日 (日) 02:26 (UTC)

Citation needed的中译[编辑]

目前翻译成来源请求,不过各位会不会觉得译成需来源比较通顺?--RekishiEJ留言) 2018年1月19日 (五) 13:46 (UTC) 请求来源→需来源 2018年1月19日 (五) 13:47 (UTC)

我觉得应该是:需要来源,四个字更加清楚。--云间守望 2018年1月20日 (六) 05:57 (UTC)
“来源请求”已经名声在外了(1 2),不建议修改。--Yangfl留言) 2018年1月20日 (六) 06:37 (UTC)
不用考虑那些网站,反正我们改译名,它们到后来也会更名的。--RekishiEJ留言) 2018年1月20日 (六) 12:58 (UTC)
个人观感:“需来源”偏口语,简洁但不够书面和正式。“需要来源”很清楚,但也有点口语化。“缺来源”可能较简洁、书面和平实。“缺少来源”警示意味更浓、更急迫,匹配目前外观设计(背景着色)。“来源请求”不算好翻译,但已广为人知并变成特色之一。--YFdyh000留言) 2018年1月21日 (日) 02:44 (UTC)