维基百科:互助客栈/其他/存档/2022年1月


立场新闻已经被国安局处理,是否需要修改可靠来源等级

决定界面保护图标

愿意指导新手的人可以登记成为Growth团队功能的导师

征求各用户在2022年于AFXD计划“提删”的内容

DOVA-SYNDROME的音乐使用

结论:
不可以用于维基百科。--Nostalgiacn留言2022年1月11日 (二) 09:06 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

DOVA-SYNDROME的音乐是否符合标准,能直接上传到维基共享或者维基百科。

DOVA-SYNDROME的音源利用协议中说明,网站上使用这个协议的音乐是可以免费使用,允许商业利用,随意编辑。--Nostalgiacn留言2022年1月10日 (一) 02:53 (UTC)

似乎不行,因为仅限作“背景音乐”之用(ライセンスの范囲,1),而维基百科没有背景音乐的设定。此外,禁止事项之7是“コンバート等を行わず、エンドユーザーが容易に音源ファイルに音声ファイルとしてアクセス、复制が可能な状态での利用”,即所允许的使用,不能令用户方便下载音源档,但是上传到维基共享或维基百科的话,很容易下载。结论应是不可以在本站使用。—— 留言2022年1月10日 (一) 22:10 (UTC)

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

维基荣誉管理

大家好。本人在解决维基荣誉以及维基专题创作奖的时候发现均有大量积压特别是维基香港内容奖由上年3月开始积压,而其他奖项均有类似问题。是不是应该成立一个工作小组管理?--Dotaoffice 邀请您加入边缘人小组 2022年1月3日 (一) 12:12 (UTC)

荣誉部分我认领。--拒食木瓜 🎇心臓を捧げよ! 2022年1月3日 (一) 13:40 (UTC)
感谢--Dotaoffice 邀请您加入边缘人小组 2022年1月4日 (二) 08:45 (UTC)

…一个礼拜过去了依然没有人有什么感想吗?有一些维基专题创作奖例如无代表国家计划创作奖等均以废弃了一年多等,各位对此有什么意见吗?Dotaoffice 邀请您加入边缘人小组 2022年1月9日 (日) 13:48 (UTC)

目前有例如维基荣誉、维基香港内容奖、维基香港图像奖及维基ACG专题创作奖均算活跃可暂不讨论。或许是不是可以先讨论一下不活跃的维基奖励的处理方法然后再来考虑统一管理?Dotaoffice 邀请您加入边缘人小组 2022年1月9日 (日) 13:54 (UTC)
人手不足这个问题在不少地方也有,不会因为成立一个工作小组,就突然有很多人会真的去处理相关事宜。如果您在意此类积压的话,基本上就只能靠您自己坐言起行去处理,工作小组当然也可以成立,不过以我的经验来说,成效有限,您可以看看目前多如繁星的各个维基组织,到底有多少个真的发挥到组织性作用,更多的只是表态,到头来还是要靠各自抽空去处理。--AT 2022年1月9日 (日) 14:26 (UTC)
对的,当然我也没有这么天真,这个我也清楚知道。不过我依然想为主引起关注度及沟通渠道,只能期望这有用吧...--Dotaoffice 邀请您加入边缘人小组 2022年1月12日 (三) 09:56 (UTC)

关于Unblock-zh邮件列表的一些事

目前unblock-zh邮件列表的主要业务有:

  1. 帮助被迫使用代理者注册账号
  2. 授予IPBE以便编辑
  3. 回答关于普通IP段封禁的问题
  4. 普通封禁申诉

其中前两项占比约7成,第三项2成,封禁申诉最少。近30天内主要是我在回复收到的邮件,但因个人安排,约一周后,我能承担unblock-zh的工作量会下降到目前的1/4左右,若届时没有其他管理员来帮忙处理,我担心会出现邮件太长时间没有回复的问题。下面是一些我在回复unblock-zh邮件过程中遇到的问题,也顺便和大家分享:

  1. 此前因为我个人的问题,有几次让邮件积累了一周甚至更长,才一次性回复完。导致的问题是:有些人时隔一周多才收到回应(当然有些人发信后几个小时就恰好遇到我在回信)。理想的状态:我没有在回信的时候有其他管理员帮忙,其他管理员有事的时候我可以帮忙,总之持续有人在回信,这样大家工作量都不大。
  2. 从IRC等渠道,我发现有些人的邮件因为没写主题或含有特定的词汇等等,被邮件列表的反垃圾系统拦截。导致的问题是:管理员没收到邮件,发信人不知道自己的邮件没有被收到。
  3. 不同管理员授予IPBE时不同。虽然我本人遵照方针要求,会至少确认申请者有需要使用网络代理(确认其封禁信息),但其他管理员中也有并不要求这一点的(当然也有不认可我的做法,认为应该更严的)。而且,我在邮件沟通中能确认的也只有对方提供给我的,声称是自己看到的封禁信息,有心人完全可以仿造一个出来,我没办法辨别。导致的问题是:我对自己的工作(要求对方提供封禁信息以证明需求)产生了怀疑,不知道是否应该继续这样下去。
  4. IPBE授权后被证实使用傀儡者,有。即便有IPBE,使用代理,也有人因为编辑行为,甚至技术证据,而被发现运用傀儡账号。换言之,IPBE并不完全阻断对傀儡账号的查核。但是,也有没被发现的持有IPBE的傀儡,是可以想见的。

开这个讨论串,原本是想找人帮忙一起受理unblock-zh的工作,让社群了解unblock-zh的现状,但是发现有些问题,使得是否继续使用unblock-zh可能应该打个问号。需要解决的问题有:

  1. 如果有管理员有意愿帮忙回复邮件,但不知道怎么帮忙或操作上有困难的话,可以在这里弄明白。
  2. 当前情况下,IPBE的授权应当满足什么条件?我想这个条件在各种申请渠道应该相对统一。授权后应留下什么记录?例如unblock-zh的邮件记录链接是我授权中最常用的,里面可以查到申请人受到IP封禁影响的证据。

--Tiger留言2022年1月2日 (日) 18:28 (UTC)

是不是应该ping所有管理员来讨论啊?—— Eric Liu 创造は生命(留言留名学生会 2022年1月2日 (日) 21:21 (UTC)
没有管理员布告板主页的问题。要所有管理员注意的议题永远要全ping。--路西法人 2022年1月3日 (一) 09:12 (UTC)
据我在(你们所不承认的)QQ群中帮助新手的经验,大部分大陆新手都不能再一周之内收到邮件反馈。这对于新手的打击是致命的,有很多人因为长时间收不到邮件而放弃了编辑维基。有很多人因此在QQ群里质问,而目前在QQ群内没有站内管理员,因此我们只能表示无奈。--三万光年 GBAW 2022年1月3日 (一) 02:07 (UTC)
毕竟去年9月份基金会大挥铁拳之后管理员人手开始出现短缺,而关于管理员投票是否使用SecurePoll也是最近才出结果。--🔨留言2022年1月3日 (一) 03:40 (UTC)
和基金会行动关系不达,被除权的几位在邮件列表里本来也不算活跃,或者根本没有加入邮件列表。--Tiger留言2022年1月3日 (一) 04:46 (UTC)
关于第一个问题,我个人的意见是或许可以推举一到两位专门负责处理unblock-zh邮件的管理员来协助处理积压。如果目前的管理团队内部不能满足,就从社区里招募合适人选,推举有条件有经验愿意长期接手unblock-zh邮件积压的人去参选管理员,当然被推举的参选者应当能在协作处理unblock-zh积压的问题上有所承诺,能保持长期的耐心不是五分钟热度。
关于第二个问题,我个人认为只要我们坚持假定善意原则,就没有理由收紧IPBE。有一个统一的具体筛查标准固然最好,但在这个领域应该没法真正适用任何统一的标准。需要IPBE的理由应有尽有,洞察这些理由虚实的金科玉律却没几条,最后自然就只能统一放行,那些明显不成立的理由总归是少数。哪怕是全域IPBE,只要表明自己已经获得本地IPBE,监管员基本上也只能要一个就给一个,因为在这个问题上无法对别人刨根问底。当然每个管理员的个人标准不尽相同,愿意在这个问题上更加负责和仔细审核总是好的,只是整体上的收紧在我看来还是不贴合维基社区长远发展的需要,而且客观上增加了管理员自身的负担。况且在大陆没有IPBE约等于无法参与编辑,而纯破坏者却总是有各种各样的门路和歪点子来蒙混过关。所以把IPBE收的太紧到底是防君子防不住小人。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程2022年1月3日 (一) 03:43 (UTC)
关于筛查标准,我的意思不是你说的这个部分。事实上并没有管理员会去质疑“我住在中国大陆不得不用代理”、“我不会乱用权限”这个部分。邮件受理请求时,会要求申请者给出封禁详情,也就是多少挡一下其实根本不需要代理但是假装自己被封的人。但是这一点在站内申请的时候基本上从来不要求。这里就产生差异了,也就是我希望统一的部分。要么都要封禁信息,要么都不要。如果选择都不要的话,需要先把WP:IPBE方针改掉,因为里面要求用户需要“有真实的需求”。--Tiger留言2022年1月3日 (一) 04:45 (UTC)
另外,如果社群认为不需要封禁信息即授权,以及差不多完全放开授权的话,我会建议直接给所有注册用户加上这个权限,就是把ipblock-exempt直接添加到user用户组,还省掉申请和授权的麻烦。--Tiger留言2022年1月3日 (一) 04:53 (UTC)
如果是这个统一的意思我也是很赞成的诶,所谓“有真实的需求”本身就无法完全查证,其实也就只能靠自觉。况且WP:IPBE方针和中维的实际情况已经偏离了。IPBE原本是提供给有极端特殊原因被广域封禁误伤的极少数个例的,所以作为一种管理员权限的分支是会谨慎授予。这在其他社区是适用的,比如英维有单独IPBE的用户比管理员还要少的多,他们都各自有特殊原因。但到了中维反而正相反,一批批大陆新用户普遍需要获取IPBE才能参与编辑。IPBE原本的特殊前提根本就是完全不适用的,按照方针还要查阅申请者的编辑记录,这在中维等于逆反因果。IPBE在中维反而更像是一种辅助处理防火墙封锁问题的通行证。所以我个人完全支持简化授权过程,改成统一走一遍形式留个记录就是,减少审核负担。
再从这个角度出发,进一步考虑把IPBE直接下放的话阻力就大了。个人是觉得是有些冒进,但有可操作性,值得让社区仔细讨论讨论,我个人先给一个保守的支持。毕竟当下一个IPBE权限的申请问题就直接挡住很多潜在的编辑者了,很多人好不容易翻墙来维基了,一看自己IP是被封禁的估计就直接打消了今后的编辑欲望,潜意识里会产生“我编辑不了”的想法。而会进一步考虑“为什么怎么办”然后来申请IPBE的必然只剩下这当中的一部分人了。所以把IPBE直接添加到User用户组里对中维发展一定是有很大正面收益的。当然也和风险并存,IPBE说到底最初是管理员权限之一,IPBE变成默认持有可能会对日后查核锁定破坏者留下隐患。但如果申请流程本身已经极大简化,考虑这个问题意义也不太大了,所以我给一个保守的支持,不知社区整体态度如何。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程2022年1月3日 (一) 06:30 (UTC)
元维基的m:NOP全域方针本身禁止了在全域范围内随意使用代理的这种行为。到底要不要给中维开这个特例,让其豁免于全域方针,或是直接修改NOP全域方针,都应该不仅仅是由中维社群得出结论;如果中维开了这个先例,那土耳其,伊朗相关语言维基要不要这么做?中文其他维基项目要不要这么做?元维基和维基共享资源要不要因为有中文维基用户参与,所以也取消代理使用限制?因此这种类似“把ipblock-exempt直接添加到user用户组”这种请求可能会被直接拒绝,而且这个提议无论从各个方面上来讲也都是很令人疑惑的。--Yichen Ding留言|主账户2022年1月3日 (一) 14:02 (UTC)
你说的没错,但是见人就给的授权方式本质上和“把ipblock-exempt直接添加到user用户组”没什么区别,又和现行成文的方针矛盾,令我(作为方针的执行者)十分困惑。--Tiger留言2022年1月3日 (一) 14:37 (UTC)
LIPE的大量分发是无奈的情况,建议参考en,非带权限的用户可以分发短期得临时授权,时编辑强度情况来再申请时延长,逐渐为长期;有权限的可以提高初始值。不过有些地区的,过度依赖LIPE的就有点惊弓之鸟了。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月4日 (二) 09:37 (UTC)
当前实践已经是直接对所有使用代理者授予不限期的权限,同时六个月无编辑后除权的规则仍适用。--Tiger留言2022年1月4日 (二) 20:37 (UTC)
我早前已直接把自己的TG ID添加至相关页面,当积压过久的话,可以让申请者直接通过TG联系到我。--AT 2022年1月5日 (三) 07:51 (UTC)
能在QQ那边也给一个快速处理渠道么?--三万光年 GBAW 2022年1月5日 (三) 14:15 (UTC)
那您要看看有谁愿意去开通这个渠道啰。--AT 2022年1月5日 (三) 16:54 (UTC)
@AT:不知关联到tg的wikipedia-zh-help群组的QQ群组是否可以作为这个渠道。亦或者是否可以由大陆用户帮助注册账号并代替其申请ipbe?--三万光年 GBAW 2022年1月7日 (五) 02:12 (UTC)
我觉得把邮箱公诸如世不是好事,始终是个人资料。后者我更倾向由管理员处理,始终个人邮箱不宜随便给陌生人,管理员至少会保密,一般用户却无法排除泄漏风险。--AT 2022年1月7日 (五) 06:16 (UTC)
那就没办法了,乖乖等rfa呗(耸肩--三万光年 GBAW 2022年1月7日 (五) 09:25 (UTC)
如果给所有用户IPBE那么为什么还要封禁代理。改为被封禁的开放代理IP也可以注册帐号只是不能编辑,需要在讨论页用unblock模板,并且设立“IPBE授予员”或“IPBE授予者”用户组可以授予他人IPBE权限?桐生ここ[讨论] 2022年1月5日 (三) 13:50 (UTC)
初步支持给新用户授予ipblock-exempt的想法,但需不需要保持六个月无编辑就除权?如果保持这个规定,是不是可以用户注册时自动加入IP豁免用户组? ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月5日 (三) 15:54 (UTC)
不太同意自动授予,相当于所有用户豁免用户查核。而且对于破坏者的IP封禁将不起作用。现在的流程还可以检查来自哪里,是因为代理被封禁{{Blocked proxy}}还是破坏者{{Range block}}。桐生ここ[讨论] 2022年1月5日 (三) 16:14 (UTC)
  • 通过站内申请,可以根据用户贡献判断是否可信。
  • 通过邮件申请,可以判断申请者邮件地址是否临时邮箱,根据封禁ID判断是Blocked proxy还是Range block,根据IP判断是家庭网络还是服务器,根据这些内容判断陈述是否可信。
    比如一个中国大陆需要IPBE的用户,应该是被Blocked proxy,IP是服务器;如果是Range block,而且被封禁的IP是家庭网络,称其在中国大陆被封禁代理就值得怀疑。甚至是最近被封禁LTA的一个IP地址(不是IP段而且还是家庭网络),可以直接拒绝,但可以建议对方更换网络环境以免误伤。
桐生ここ[讨论] 2022年1月5日 (三) 16:38 (UTC)
我无论身在哪里都可以开proxy,都可以装作来自中国大陆啊。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:16 (UTC)
实际处理的过程中,我也经常对一些申请人有这个怀疑,然而没法去求证,也就都给权限了。--Tiger留言2022年1月6日 (四) 14:41 (UTC)
用户查核还可以看UA ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:21 (UTC)
复述。参考en的做法,说明合理就可以给一个临时的,非职权的时间较短(可以参考为6个月),之后如果编辑强度足够可以提高阈值,有职权起初阈值可以大些。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月6日 (四) 01:12 (UTC)
我觉得还有建立帐号的问题。如果不经过unblock-zh,要怎么给中国大陆用户注册帐号?反正我现在登录状态下都注册不了帐号。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:27 (UTC)
我觉得,动大的(比如自动授予、新设用户组等)都需要共识;然而目前应该优先讨论的是三天之后,避免IPBE授予积压的紧急方案。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:27 (UTC)
要讨论紧急方案的话,恐怕要把所有管理员都ping过来,目前似乎只有两位管理员参与了本节讨论。--Steven Sun留言2022年1月7日 (五) 07:36 (UTC)
Xiplus刚刚处理了七则请求,看起来这部分应该还是有管理员接手的。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 09:53 (UTC)
实际上是44则。--Xiplus#Talk 2022年1月7日 (五) 12:29 (UTC)
目前技术上能否做到允许通过代理注册账户并编辑自己的讨论页?--Steven Sun留言2022年1月6日 (四) 06:45 (UTC)
“允许通过代理注册账户”不行,这样 IP block 就没有意义了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 11:34 (UTC)
支持建立后自动封禁以方便管理员俭省一层功夫--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月6日 (四) 13:33 (UTC)
还有个不知技术上是否可行的想法:将“授予IPBE权限”的权限下放,分拆Unblock-zh,允许非管理员参与到授予IPBE权限的工作上来。因为目前本地缺少用户查核,管理员似乎也没有什么特殊的渠道去了解申请者是否可信。--Steven Sun留言2022年1月6日 (四) 13:47 (UTC)
即“IPBE授予员”。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 04:28 (UTC)
我反而觉得通过Unblock-zh处理IPBE等申请,可能存在个人隐私问题,甚至怀疑可能与m:Access to nonpublic personal data policy存在冲突--百無一用是書生 () 2022年1月12日 (三) 02:30 (UTC)
邮件列表不受隐私政策保护,自然没有违反Access to nonpublic personal data policy的问题。--Xiplus#Talk 2022年1月13日 (四) 14:03 (UTC)
邮件列表目前的处理方式是基于双方互相信任,申请人信任管理员不会泄漏邮件内容,管理员信任申请人提供的资料真实无误。如果想要保护申请人的隐私,目前想到2个办法: 1. 使用VRT邮件列表,VRT成员必须签NDA,优点除此之外还有方便管理邮件,标记未处理/已处理、合并多张工单、回应内容模板等等模板都是目前邮件列表无法做到的;缺点就是中国大陆的管理员就无法参与了。 2. 落实WP:CUP#3处理方式,优点有全面在站内处理、申请者不用再提供隐私资料、管理员也不用担心提供的资料是否可能伪造;缺点就是大大增加CU处理量,需要等待CU程序。--Xiplus#Talk 2022年1月13日 (四) 14:18 (UTC)
魔琴这连结是哪时候的新功能-- Sunny00217  2022年1月15日 (六) 09:10 (UTC)
@Sunny00217Google introducing a feature in Chrome 90 to create links to highlighted text on a webpage. 其实我还写麻烦了,写成这样就行了,可惜不支持字词转换。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月15日 (六) 11:09 (UTC)

一月十五日至一月十六日屏东维基编辑工作坊

如主旨,1/15-16 将于屏东进行线下的维基百科编辑教学活动。 编辑条目主要为高雄市、屏东县境内村里,如学员有触犯编辑规则请海涵,会在编辑活动结束后五天尽可能排除问题,如有漏网之鱼再烦请通知,非常感谢。 相关编辑纪录可参阅活动编辑纪录。 --Allenwang6212a留言2022年1月14日 (五) 11:19 (UTC)

阅,感谢告知。WP:VPD#关于可能的利用维基百科进行教育训练及其条目是否可能存在问题中的是你们的社团吗。--Ghren🐦🕑 2022年1月15日 (六) 18:14 (UTC)

千村狐免疑为基金会行动的罪魁祸首

笑话一则。不要给LTA关注度。--路西法人 2022年1月19日 (三) 03:49 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

这边(在伪基冲浪无意发现的)有证据表明,破坏者中的哈密瓜油、玛丽莲梦、Tongtonggood,本次GB的游魂、Walter Grassroot(正好是回退员,可以查看过滤器)为其真人傀儡。-- 680XtalkX签名白い雪が街に 优しく积もるように 2022年1月18日 (二) 13:37 (UTC)

旧闻。桐生ここ[讨论] 2022年1月18日 (二) 17:25 (UTC)
Old new is so exciting。而且LTA的话一个字都不要信。--Ghren🐦🕑 2022年1月18日 (二) 18:17 (UTC)
这都2022年了,还有人信LTA的任何一句话吗……too young too naive--三万光年 GBAW 2022年1月19日 (三) 00:17 (UTC)

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

IPBE权限能否考虑下放?

拉票相关问题

如果ping先前参与GA投票的编辑再次参与投票算不算拉票? --Loving You Is A Losing Game 2022年1月21日 (五) 03:36 (UTC)

如果被ping的人于之前的GA投票中仅投票而没有就条目内容作出讨论的话,个人认为算拉票(因为这是WP:JUSTAVOTE,是连讨论都算不上,继而不符合WP:APPNOTE所指的“曾经参与先前相同主题(或紧密相关主题)讨论的编辑”,当然如果有更多理据证明符合APPNOTE者则可以除外)。而如果被ping的人全部都在之前的GA都是投支持票的,则有可能干犯“在讨论中拉拢少部分你认为将全部支持你的立场者,也是不适当的”。--街燈電箱150號 开箱维修 2022年1月21日 (五) 12:14 (UTC)

国家资料模板

宜兰第一公民讨论 | 贡献)大量创建国家资料模板(旗帜模板),里面假假真真真真假假,希望有人检查并提删夹杂的私货(即原创研究)。--Txkk留言2022年1月25日 (二) 12:06 (UTC)

我真的不知道为什么总是有人往c站传自制旗帜,很有趣吗? ——魔琴 [ 留言 贡献 ] 2022年1月25日 (二) 12:36 (UTC)

他还没停止!--Txkk留言2022年1月25日 (二) 13:25 (UTC)

他向来很喜欢往各种地方添加旗帜,条目啊模板啊比比皆是。但滥建国家资料模板是另一个层次了,应当予以制止。—— Eric Liu 创造は生命(留言留名学生会 2022年1月25日 (二) 13:56 (UTC)

Test started

Please see Wikipedia:互助客栈/其他/存档/2021年10月#A/B test for New Discussion Tool. This started today.--Whatamidoing (WMF)留言2022年1月28日 (五) 03:57 (UTC)

提请解任管理员User:Iokseng

User:Iokseng通常只处理移动请求,这点我佩服他的坚持,其他管理员关注这方面的很少。但是,常年来我发现这位管理员在处理移动请求时有些按自身意向、喜好随意行事。而且面对质疑也不会解释说明,这对于普通用户来说没什么,对于有特殊权限的管理员不合适,故提请解任。--7留言2022年1月3日 (一) 06:22 (UTC)

请移步Wikipedia:管理员解任投票 绀野梦人 肺炎退散 2022年1月3日 (一) 07:24 (UTC)
既然都能丢出连结了,要不要先看看Wikipedia:管理员解任投票#发起解任投票第一行写了些什么?--Xiplus#Talk 2022年1月3日 (一) 07:45 (UTC)
有没有例子?--Dotaoffice 邀请您加入边缘人小组 2022年1月3日 (一) 12:37 (UTC)
(▲)同上,希望能给出具体例子。--Yichen Ding留言|主账户2022年1月3日 (一) 13:48 (UTC)
看当事双方最近的贡献应该就能明白了。—— Eric Liu 创造は生命(留言留名学生会 2022年1月5日 (三) 00:13 (UTC)
同意解任,管理员在任何决策都必须保持中立,我很清楚他对移动请求有不中立的立场,实在不适任。 2022年1月5日 (三) 07:33 (UTC)
@Iokseng 。我希望管理员作出一个合理的解释让我们得知一个更加全面的情况。Dotaoffice 邀请您加入边缘人小组 2022年1月5日 (三) 13:40 (UTC)
@Dotaoffice:就是拉法耶特侯爵的移动请求。我说明一下我对于名称没有偏好,如果觉得我的处理不适当,都可以与我沟通。至于更多的面向,此讨论串大概都有提到,在此就不重复了。--Iokseng留言2022年1月6日 (四) 00:10 (UTC)
以一件事解任,并不合适。且这里说似乎没有用处。--老衲留言2022年1月5日 (三) 13:42 (UTC)

只有在沟通无效的情况下才可以发起取消管理员权限的投票。
取消管理员权限的投票内容必需详细,指出管理滥权的原因,并根据编辑记录及用户贡献提出相关证据,如内容不符或原因不合理,可视作申请无效。

桐生ここ[讨论] 2022年1月5日 (三) 13:48 (UTC)
这是Jarodalien对管理员的骚扰 施压:关于该移动,Jarodalien自己就说过“请社群和管理员判断”,管理员做出的判断与他的要求不符,就在这对管理施压?--LarseKun留言2022年1月6日 (四) 10:02 (UTC)
@LarseKun:所以你需要请求管理员处理Jarodalien的如此情形吗?Sanmosa Immortal 2022年1月7日 (五) 04:02 (UTC)
@Sanmosa:也不明确这算不算对管理员骚扰。--LarseKun留言2022年1月7日 (五) 09:51 (UTC)
@Sanmosa:别的管理介入等一等。我想请问下:你觉得搜索引擎搜索结果和专业的文献相比,哪个更适合作为维基参考来源。--LarseKun留言2022年1月8日 (六) 05:46 (UTC)
依照Wikipedia:管理员解任投票,需要“等待讨论共识”,不知大家的意见如何,我认为目前的说明还不足以解任管理员--Wolfch (留言) 2022年1月6日 (四) 10:08 (UTC)
我觉得不至于解任。—— Eric Liu 创造は生命(留言留名学生会 2022年1月6日 (四) 11:36 (UTC)
假如提请人没法写出“详细投票内容,指出管理滥权的原因,并根据编辑记录及用户贡献提出相关证据”,建议关闭。--Ghren🐦🕗 2022年1月6日 (四) 12:11 (UTC)
我觉得他无非就是在清除异己,这点让我想起了WMCUG。Sanmosa Immortal 2022年1月7日 (五) 04:02 (UTC)
由于提请人未能提出相关证据,建议关闭。桐生ここ[讨论] 2022年1月7日 (五) 11:06 (UTC)
(-)反对提早关闭,建议尽快达成沟通无效,启动联署的共识。--Liuxinyu970226留言2022年1月11日 (二) 06:29 (UTC)
我不是提请人,但是我能提出证据:时雨羽衣的非法移动。根据命名常规的先到先得规则,如果存在符合名从主人惯例的名称,并于至少一处中文使用地区为常用名称时,条目标题应当使用该名称,而先到先得规则不起作用。然而,时雨羽衣的官方频道显示的名称为繁体中文,并至少于台湾等地区使用,该管理员却无视规定恣意移动。此外,根据地区词处理指引(当时指引地位未被确认,但是仍可起参考作用),当一个机构或人物已经有官方的汉字或中文名称时,临时解决方案为条目名称遵从名从主人原则。题外话,之前该管理员也有几起移动争议,但是被解任的几率也不大,就不浪费力气了,只是希望提出证据能起警告作用,毕竟管理员的行为不能太过放肆。 2022年1月7日 (五) 15:27 (UTC)
@Pseudo Classes:你这是典型误解方针的情形,名从主人不限制条目名称是用繁体或简体,他这样做是在回退繁简破坏,是遵守并执行方针的情形。Sanmosa Immortal 2022年1月7日 (五) 15:50 (UTC)
您才误解吧,哪里说明名从主人不限制条目名称是用繁体或简体? 2022年1月7日 (五) 15:59 (UTC)
这点你大可以问其他(与事件无关的)管理员,我认为我的理解无误。--Sanmosa Immortal 2022年1月7日 (五) 16:01 (UTC)
我直接引用方针的说明,怎会有误解的情形?方针从没写到不限制条目名称是用繁体或简体,那就不应该恣意延伸解读,一切皆以方针所述为主。 2022年1月7日 (五) 16:01 (UTC)
我可以告诉你十个管理有十一个都会这样处理。--Ghren🐦🕛 2022年1月7日 (五) 16:19 (UTC)
见下。 2022年1月7日 (五) 16:39 (UTC)
我认为100个监管员至少99.99999...个都不同意这种处理方式--Liuxinyu970226留言2022年1月11日 (二) 06:29 (UTC)
我们可不是维基文库啊。名从主人原则如果限制繁简那会是很恐怖的;总不可能把所有中国古代人事物移动到繁体名称吧。反过来说,命名常规亦无规定中文名称之繁简也要名从主人,法无禁止即可为。—— Eric Liu 创造は生命(留言留名学生会 2022年1月7日 (五) 16:08 (UTC)
法无禁止,但是有共识:讨论存档。举个例子,如果将中西區 (台灣)移动至中西區 (臺灣)属于繁简破坏,但是将東山區 (台南市)移动至東山區 (臺南市)则不属于繁简破坏,因为臺灣是主权有争议的地名,而臺南市是属于中华民国的行政区域,即台南市的主权为中华民国,如果今天要建立属于中国的行政区域,则可能另建立東山區 (台南市)的条目。简而言之,名从主人具有尊重主人选字的条件,这是共识,并不是自行延伸解读。您可以查看我的移动日志,您就能明白我一直关注名从主人的领域。 2022年1月7日 (五) 16:38 (UTC)
台与台之问题属于特殊情形,还牵涉异体字与显示问题,不可一概而论。—— Eric Liu 创造は生命(留言留名学生会 2022年1月7日 (五) 18:10 (UTC)
@Ericliu1912:请不要混淆视听,该共识包括但不限于台台异体字,这里只是用来引出共识,没有一概而论。更何况地区词处理指引也有提到,当一个机构或人物已经有官方的汉字或中文名称时,临时解决方案为条目名称遵从名从主人原则。 2022年1月14日 (五) 11:25 (UTC)
我不认为有什么共识就是。该等情形应当属于例外。另外地区词和单纯繁简是两回事。—— Eric Liu 创造は生命(留言留名学生会 2022年1月14日 (五) 14:20 (UTC)
你反对我的意见,当然会认为当时没有共识,真是令人遗憾。此外,该共识不存在例外不例外的适用时机,也不仅限定台台异体字,请不要混淆视听。最后,地区词和繁简转换确实不同,为避免混淆视听,已对留言径行删除。然而,唯一不会改变的是当时的共识,除非你另起讨论将其推翻,谢谢。 2022年1月14日 (五) 23:01 (UTC)
那是您自己的看法,顶多也只能算是一个特定范围内的共识。对我来说,该讨论完全集中在台台问题,要用此框架下得出的一些讨论结果放大套用于全站,实在不能说是妥当。这并不符合现实,也显然不应该得到执行,否则将破坏本站多数条目的基础,AT跟我所提到的只是其中一小部分而已。考虑到命名常规名从主人原则一段一字未提繁简,再考虑到其前后文字内容、延伸指引内容,我认为该方针所说的名从主人完全只有地区词上的名从主人,而其繁简只要显示上相同,便无差别。台台问题之所以需要另外讨论,便是因为显示起来不同,且为异体字,不单纯适用一般命名常规。—— Eric Liu 创造は生命(留言留名学生会 2022年1月15日 (六) 02:33 (UTC)
你认为,不代表方针如此,结果真是令人遗憾。然而,就算不论方针,该管理员在有反对意见的情况下,未经沟通协调,贸然移动页面,很明显就是滥权,更何况是有争议的移动和不明确的方针下执行。 2022年1月15日 (六) 06:30 (UTC)
关于对方针与指引的看法,我原句奉还阁下。我同意Iokseng阁下有时候行事上不一定完全正确,但他显然不是不能沟通,故我认为不至于解任。—— Eric Liu 创造は生命(留言留名学生会 2022年1月15日 (六) 19:46 (UTC)

应维持条目第一个重要版本所采用的标题

条目建立时是使用“时雨羽衣”

另外,

以下为“名从主人”原则仅起参考作用的情况:
1.人物:其所工作或隶属的机构、组织、公司的中文资料中出现他的中文姓名或译名的,“名从主人”原则仅起参考作用

--0906(回复请Ping我) 2022年1月7日 (五) 16:39 (UTC)
参考仍有作用,而先到先得则是直接不适用,请看清楚,谢谢。 2022年1月7日 (五) 16:41 (UTC)
这次移动似乎是依据讨论申请来执行,不过的确存在没有检查适用的规则,而且在讨论有反对的情况,就照常执行。的确需要注意到其中的问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月8日 (六) 03:42 (UTC)
上上次提请人发起的移动,也存在反对但是通过了,提请人倒是没来提请接任。最近的几次移动,提请人的申请没过,就来客栈提请解任了。--LarseKun留言2022年1月8日 (六) 05:46 (UTC)
@AT:可能要劳烦行政员解释一下了。究竟我和Pseudo Classes的解读哪个才是正确的?--Sanmosa Immortal 2022年1月9日 (日) 02:11 (UTC)
我用例子来回应。请问中国相关条目在中国使用简体之前是否都应该以繁体来命名,反之亦是如此?港台则只能用繁体来命名吗?--AT 2022年1月9日 (日) 04:43 (UTC)
@空氣小貓(顺便给个例子:老隆福建会馆)。Sanmosa Immortal 2022年1月9日 (日) 07:13 (UTC)
用字模式差异导致先到先得,似乎是基于创始初期就出现过抢位问题来避免这个问题(例如同一个事物的名称的不同用字模式,繁体抢简体或者反之),其中的核心就是认为只因用字模式差异不影响命名差异。现在的规则没有明确这个,但基于早期情况,似乎是这样去解读。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月10日 (一) 01:27 (UTC)
@Sanmosa:同上,但是恣意错误解读没有订定的规则绝对不被允许,更不用说执行方面。 2022年1月14日 (五) 11:28 (UTC)
(=)中立。--夏雪若留言2022年1月9日 (日) 12:33 (UTC)
  • 我不太同意Pseudo Classes君关于台南市的那段论断。東山區 (台南市)属于标题繁简混用。内地地铁车站条目也有很多全繁体命名的,按Pseudo的说法把他们移动到简体也不是繁简破坏了。Itcfangye留言2022年1月15日 (六) 10:51 (UTC)
@Iokseng我想请您解释一下您对向涵之的移动,AFC的被驳回的明显不完善的草稿为何会因移动请求而被您移动到条目空间?--🎋🎍 2022年1月25日 (二) 11:46 (UTC)
我当时判断的是移动请求的理由是否合理,而AFC也没有草稿不完整不能发布至条目的限制。原作者是以草稿(用户页的子页面)编写内容,他提出申请移动到条目,我看内容格式并无多大问题,就会予以处理。至于内容不完善的问题,我觉得应以关注度或存废讨论处理。--Iokseng留言2022年1月25日 (二) 12:09 (UTC)
@Iokseng您可以看一下编辑摘要,您做完移动后甚至有其他维基人指出草稿内容抄袭自百度百科,我现在向您申请将其移回草稿并进行修订版本删除。--🎋🎍 2022年1月25日 (二) 14:53 (UTC)
这那里抄了百度百科了?我硬是没看出来。--Ghren🐦🕛 2022年1月26日 (三) 04:01 (UTC)
  • (-)反对除权,至少目前看来证据并不充分,此外“只有在沟通无效的情况下才可以发起取消管理员权限的投票。”。在此讨论串发起之前,不知各位有没有就相关问题与Iokseng沟通过。——BlackShadowG留言2022年1月26日 (三) 15:12 (UTC)
    同上。--🎋🎍 2022年1月31日 (一) 11:30 (UTC)

InternetArchiveBot

InternetArchiveBot在条目屏东台电男子排球队于2022年1月31日的编辑在引用模板中新增参数“7”,实际上引用模板并没有参数“7”,不清楚这是不是个案,有需要回报给Cyberpower678吗?-- 2022年1月30日 (日) 18:08 (UTC)

对IABot最近1000笔编辑进行检查,只发现一笔有问题的编辑。--Yining Chen留言|签名页2022年1月31日 (一) 11:31 (UTC)

关于部分词汇的翻译(续)

本讨论接续Wikipedia:互助客栈/其他/存档/2020年6月#关于部分词汇的翻译,内文转自translatewiki.net由Lakejason0发布的讨论“关于通用术语表的部分错误的建议和部分条目相关疑问” https://translatewiki.net/wiki/Thread:Portal_talk:Zh/关于通用术语表的部分错误的建议和部分条目相关疑问

Sincerely,

Winston Sung留言2021年9月11日 (六) 17:13 (UTC)
Fandom ZH Community Central Admin

注:部分讨论已整并存档至Wikipedia:互助客栈/其他/存档/2021年10月#关于部分词汇的翻译(续)

关于zh-hans/zh-Hans-CN中account的翻译

已通过:
仅调整“户=>号”之部分,即以“账号”作为zh-hans/zh-Hans-CN account之译名。
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

  • 原文:account
  • 当前zh-Hant使用的翻译:帳號(已确认)
  • 当前zh-Hans曾使用的翻译:
    • 帐户
      • 根据讨论走向可先排除
    • 账户
      • 根据讨论走向可先排除
    • 帐号
    • 账号

由于当前翻译不一致,故在此希望各位能提供意见。--Winston Sung留言2021年9月17日 (五) 17:41 (UTC)

手机、电脑系统用字问题牵涉谷歌和微软,就目前老美对华日趋强硬鹰牌的现状下,这两家公司的系统开发部门指望有几个大陆血统的员工呢?想必大半的华人员工祖籍基本港台新马菲居多吧,基本可以肯定对大陆用词半知不解。由于当下疫情影响很难劝说两家公司改变有关做法,我打算先劝说一些对华还很友好的阿尔斯通、特斯拉等改变两字取舍问题,待国门放开后再设法择机访问两家公司总部当面讨论该等事宜。--Liuxinyu970226留言2021年10月13日 (三) 15:42 (UTC)




就我个人而言,用账有道理(列举政府文件的目的是在于论证“有人而且有很多人这么用”),而用帐也有道理(除去有人对用“帐”字的解释我不认为正确(也就是所谓“这是本字”,我的意见见上)以外,事实层面是,微软、Apple、Google、小米,等等,都用帐字)。用哪个都不至于有人很不舒服。如果阁下认为应当以无共识作结,我建议开个投票,反正该说的理由差不多都说完了。--Lakejason02022年1月5日 (三) 17:25 (UTC)

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

关于各变体中wikitext的翻译

已通过:
“wikitext”使用原文不另翻译。
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

无共识:
暂时搁置,日后再议。
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

  • 原文:wikitext
  • 曾使用的翻译:
    • 使用原文:wikitext
    • wiki文字/wiki文本
      • 注:字词转换(含地区词转换)后,“文本”转换为“文字”。
    • wiki代碼/wiki代码
      • 注:因wikitext属标记式语言,故“代码”不转换为“程式碼”。
    • wiki語言/wiki语言(wiki语言会和$wgContentLanguage混淆)
    • wiki語法/wiki语法(wiki语法会和m:Wiki syntax混淆)

注意:此讨论不影响“wiki markup language”译为“wiki標記式語言”/“wiki标记语言”。


由于目前翻译不一致,故在此希望各位能提供意见。--Winston Sung留言2021年10月12日 (二) 14:53 (UTC)


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

  • 原文:wikitext
  • 曾使用的翻译:
    • 使用原文:wikitext
    • wiki文字/wiki文本
      • 注:字词转换(含地区词转换)后,“文本”转换为“文字”。参见:plaintext(简体:纯文本;繁體:純文字;)、richtext(简体:富文本;繁體:富文字;)
    • wiki代碼/wiki代码
      • 注:因wikitext属标记式语言,故“代码”不转换为“程式碼”。

注意:此讨论不影响“wiki markup language”译为“wiki標記式語言”/“wiki标记语言”。



以“wikitext”使用原文不另翻译公示七日。--Winston Sung留言2021年12月26日 (日) 10:36 (UTC)



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

关于zh-hans/zh-Hans-CN中widget的翻译

  • 原文:widget
  • 当前zh-Hans曾使用的翻译:
    • 小工具
      • 与gadget译名冲突。
    • 微件
      • Android 11采用的翻译。
    • 挂件
    • 小部件
    • 小组件
      • 可能与components译名冲突。
    • 小器件
    • widget(使用原文)

https://phabricator.wikimedia.org/T296583https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/742246 --Winston Sung留言2021年12月1日 (三) 05:34 (UTC)

关于zh-hant/zh-Hant-TW中widget的翻译


https://phabricator.wikimedia.org/T296583https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/742246 --Winston Sung留言2021年12月1日 (三) 05:34 (UTC)

  • 能否麻烦您也看一下 Android 是怎么翻译的?手边没有不过应该也是个不错的参考基准,毕竟是很多人会接触到的软件。wctaiwan留言2021年12月1日 (三) 05:44 (UTC)
  • Android之zh-Hant-TW widget翻译未变更,仍为“小工具”,与gadget译名冲突。--Winston Sung留言2021年12月1日 (三) 06:02 (UTC)
  • 既然如此我还是倾向于小元件,感觉上意义比较接近,台湾人(因为微软译名的关系)应该也比较熟悉。未来有需要的话 components 可以翻译成元件或者是组件,不是专有名词的话应不至于有冲突的问题。wctaiwan留言2021年12月1日 (三) 06:21 (UTC)
  • 我目前是倾向于译为“微件”,一方面同时顾及音译及意译,另一方面显示时与其他命名空间名称二字对齐。参考资料:中华民国专利资讯检索系统[原文如此] https://twpat1.tipo.gov.tw/twpatc/twpatkm (无法产生静态连结。公开公告号: I459314,专利名称: 微件個人化及互動之架構及其方法 A STRUCTURE AND METHOD FOR WIDGET PERSONALIZATION AND INTER-WIDGETS COMMUNICATION。)--Winston Sung留言2021年12月1日 (三) 16:18 (UTC)
  • 按照在Microsoft Language Portal查到的资料,除了“小工具”以外大部分译为“控件/介面控件”或不翻译。--Winston Sung留言2021年12月2日 (四) 07:32 (UTC)
  • 依此看来台湾最常见的翻译应该是小工具(Windows + Android + 国教院 + iOS)。根据 Google,微件看起来应该是大陆用语,我个人还是觉得多数台湾人看到当下大概无法会意。与 Gadget 冲突这点确实是个难题,如果直接使用原文呢?还是干脆让它冲突算了...(不过说真的如果过个两三天都没有其他人有意见,我大概也不会坚持反对,毕竟只是我一个人的偏好。)wctaiwan留言
  • 台湾翻译是“小工具”,有冲突的话,不如直接用zh-Hans-CN翻译。桐生ここ[讨论] 2021年12月4日 (六) 18:54 (UTC)

回复工具翻译问题

其他讨论