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

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

Breezeicons-apps-48-braindump.svg

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

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


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


发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 Mys 721tx滥权,任意封禁用户 51 14 Mys 721tx 2020-12-05 02:38
2 建议预设开启“讨论工具” 12 11 Impartial just 2020-11-29 14:01
3 关于是否可以在传统节日时大量发送祝福信息 28 16 Impartial just 2020-11-29 14:08
4 “到底哪一句话是广告?” 8 6 克劳棣 2020-11-26 23:24
5 咨询大家对于编辑界面的编辑提示的看法 5 3 AnYiLin 2020-12-04 18:24
6 社群首页改版 3.0 54 9 1233 2020-12-02 20:09
7 Parent monthly clean up category 模板坏掉了 3 3 Easterlies 2020-11-30 19:31
8 提议用机器人清理违反UP#11的用户空间页 7 5 IN 2020-12-03 02:07
9 如何提高将自行拍摄照片上传至维基共享资源的方法? 5 4 RavenclawOIer 2020-12-02 16:57
10 法律硕士(学位)并入条目 1 1 30000lightyears 2020-12-04 21:06
11 A/B test for the Reply tool 3 3 Sunny00217 2020-12-03 19:22
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时,
请先检查设定是否有误

Mys 721tx滥权,任意封禁用户[编辑]

Mys 721tx与u:ArikamaI在条目来源上发生争议,但没有避嫌,直接把u:ArikamaI永久封禁,而且Mys 721tx长期对用户不友善,任意封禁用户,请大家讨论一下如何解决这个问题。--203.145.94.220留言) 2020年10月20日 (二) 12:21 (UTC)

Wikipedia:可供查证:"添加或恢复内容的编辑者应承担举证的责任。所有引言以及任何被质疑或可能被质疑的内容均应使用内嵌引用来提供可靠、公开的来源。"User:ArikamaI数年持续创建劣质来源条目且警告后持续创建此类条目。该IP用户对此却视而不见,真是可笑。-Mys_721tx留言) 2020年10月22日 (四) 03:48 (UTC)
Wikipedia:申请解除权限/存档/2020年,ArikamaI说的“M3夜视狙击镜:内文与来源都来自英语维基中有"M3 Sniperscope"的条目。”是指英文维基百科某个或某些有提及“M3 Sniperscope”一词的条目,不是指页面名称为“M3 Sniperscope”的条目,在这一点上不像是“公然撒谎”。--Mewaqua留言) 2020年11月16日 (一) 16:44 (UTC)
全文中只有"M3夜视狙击镜为美军M1等红外夜视仪的改进型..."一段是en:M1 carbine所提及内容。条目中断言"M3夜视狙击镜为美军M1等红外夜视仪的改进型,在耐用性和有效射程上有了很大的提高"既不存在于英文条目中,亦不存在于其所列来源中。使用该来源的行为本身更展示了ArikamaI无辨别不可靠来源的能力。-Mys_721tx留言) 2020年11月17日 (二) 19:05 (UTC)
“有效射程(应该是指可视距离)上有了很大的提高”还是可以在列出的来源rt66.com的网页的内容推断得到,虽然该来源看似是非知名人士或专家的个人网页,非可靠来源。--Mewaqua留言) 2020年11月18日 (三) 03:52 (UTC)
另外,“它们主要被夜间哨兵...向民间出售的剩余物资。”一段可以在enwp“M1 carbine”条目找到对应的“They were used primarily in static defensive positions in Korea ... In total, about 20,000 sets were made before they became obsolete, and were surplussed to the public.”--Mewaqua留言) 2020年11月21日 (六) 13:22 (UTC)
  • 我觉得应该不至于永久封禁,封禁个半年当作警告也行呀。—— Eric Liu 创造は生命(留言留名学生会 2020年11月22日 (日) 09:16 (UTC)
    Wikipedia:封禁:"封禁不应被用作记录用户的警告,因为短暂的封禁一般均被视为惩罚性的封禁,而且对该用户也有不良的影响。"该用户就条目来源在9月、10月两次受到警告后公然创建完全无来源条目(D型消声榴弹发射器)。警告显然已起不到督促其改正其行为的作用。-Mys_721tx留言) 2020年11月23日 (一) 06:03 (UTC)
言下之意是长半年的封禁期并不能打消该用户建立相关条目的意愿?SANMOSA SPQR 2020年11月23日 (一) 08:35 (UTC)
即使如此,个人认为不至于一次就永久封禁。先给予相对短期的封禁,若无改善再永久封禁也不迟。他也是资深用户了,应当了解底线所在。—— Eric Liu 创造は生命(留言留名学生会 2020年11月23日 (一) 08:45 (UTC)
有人近期在迪美雅·芭辛丝姬阿布罗斯足球俱乐部条目加入大段无来源内容,但我觉得不会有人会向该位用户发出警告。--Mewaqua留言) 2020年11月23日 (一) 10:48 (UTC)
  • 参阅可供查证方针,缺乏来源的内容将可以被删除。条目的内容如缺乏可靠来源,可通过移除相关内容处理,亦在可条目挂上提示模板,也可在相关文句添加来源请求的注释,对于来源问题较严重的条目可提交到存废讨论。Mys 721tx君只是在2020年9月30日及10月4日在其讨论页发出两次警告,条目的内容如有问题应以删削处理并通过讨论寻求共识,封禁乃为最后手段,永久封禁更应在没有其他替代措施下才执行,在进行中之移除ArikamaI权限讨论亦未由第三方管理员结案,在此情况下便进行永久封禁,因此Mys 721tx君的做法并非没有争议。--Uranus1781留言) 2020年11月26日 (四) 04:38 (UTC)
    巡查豁免除权和封禁没有依赖关系,制止其持续创建无来源条目显然不需要等待除权结案结束后完成。该用户:
    1. 所创建条目自2009年系统性地缺乏来源,在11年中无改善。Wikipedia:可供查证:"添加或恢复内容的编辑者应承担举证的责任。"刚刚加入维基百科时创建缺乏来源条目尚可以不熟悉方针开脱。
      M1 76毫米坦克炮仅因英文原文来源充分而带有来源,不代表该用户创建条目的平均水平。
    2. L3A1刺刀中编造来源中没有的内容。该用户有意识地添加无关来源,因此可合理判断其知晓可供查证方针的存在。
    3. 在警告后公然创建无来源条目(D型消声榴弹发射器),完全否定了任何可能存在的善意。
    对上述行为视而不见是典型的诉诸中庸。-Mys_721tx留言) 2020年11月26日 (四) 05:18 (UTC)
过往因内容问题而被永封的用户多涉及屡次建立胡言乱语或内容空泛并符合快速删除的条目。可供查证方针已经说明可移除缺乏来源的内容,内容的翻译问题及有争议的内容可先行移除并在讨论页提出讨论,阁下提述之条目-诉诸中庸不但来源贫乏且绝大部分内文缺乏来源注释,以Mys_721tx君的观点不就是阁下所谓之劣质条目。--Uranus1781留言) 2020年11月26日 (四) 06:12 (UTC)
  1. 由于内容被永久封禁的用户显然不仅限于上述两种条件。以此推论对于屡次违反Wikipedia:可供查证的封禁不合理是换质不换位
  2. Wikipedia:可供查证还规定:"添加或恢复内容的编辑者应承担举证的责任。所有引言以及任何被质疑或可能被质疑的内容均应使用内嵌引用来提供可靠、公开的来源。"Wikipedia:封禁:"以下列出部分被认为需要对账户作出封禁的行为...持续的干犯其他方针与指引。"对屡犯者实施封禁理所应当。
  3. User:Uranus1781将其所犯谬误转移到谬误相关条目的质量中上,是稻草人论证
-Mys_721tx留言) 2020年11月26日 (四) 06:32 (UTC)
管理员辛苦了。晚辈也觉得或许可考虑改为中短期封禁,毕竟该用户贡献不少,永封似乎有点可惜。但仍尊重管理员的多方考量与判断。劳您费心了。--Hjh474留言) 2020年11月25日 (三) 12:57 (UTC)
英文维基有一种做法:资深用户在封禁6个月后提请解除永封,理由若为管理员采纳,即可解封;不知中文维基过去有没有类似的作法或案例。--Hjh474留言) 2020年11月26日 (四) 02:28 (UTC)
Standard offer需要用户保证此后不再进行导致封禁的行为。-Mys_721tx留言) 2020年11月26日 (四) 02:38 (UTC)
  • 回复 Mys_721tx君于2020年11月26日所作之辩解:
1. Mys 721tx君曰:“Wikipedia:可供查证:"添加或恢复内容的编辑者应承担举证的责任。"”如此,就不应故意忽略该方针所载之“否则,这些内容可能被移除。”而此乃内容方针,方针指出可移除因来源不足而被质疑的内容,却未有明文指出用户建立来源不足的条目将会被永久封禁,君如要引用此方针作为封禁理据,就必须对此作出合理解释,包括被封禁用户,维基百科:封禁方针亦明确指出“知会用户:在执行封禁时,管理员必须给予一个具体原因,让被封禁的用户知道自己被封禁的原因。在执行封禁的界面中,已有一些封禁原因可供选择,管理员也可以输入其他封禁原因。除非有特别原因,管理员应在被封禁的用户的对话页解释封禁原因,避免产生任何误会。管理员可使用一些标准通知模板”,惟 君截止2020年12月1日仍未有依据方针向有关用户作出通知及解释封禁原因,君自行采取封禁行动后,还得有用户在本页作出投诉才本页发表封禁的观点。
2. Mys 721tx君曰:“所创建条目自2009年系统性地缺乏来源,在11年中无改善”“刚刚加入维基百科时创建缺乏来源条目尚可以不熟悉方针开脱。”“M1 76毫米坦克炮仅因英文原文来源充分而带有来源,不代表该用户创建条目的平均水平。”ArikamaI君从2009年起至2020年10月间共建立1081个条目,有24个被删除,今年创建116个条目,没有1个被删除,而查阅 ArikamaI君近两三年所建立条目之情况,不符合 Mys 721tx君所称:“所创建条目自2009年‘系统性地’缺乏来源”。至于君称:“不代表该用户创建条目的平均水平”,如 Mys 721tx君在11年以来已发现其所创条目有平均水平的问题,那么为何长期以来都不在条目讨论页或在 ArikamaI君之讨论页,就内容的水平问题直接提出讨论,并可避免对水平作出主观的判断。
3. Mys 721tx君曰:“警告显然已起不到督促其改正其行为的作用”在下于上面所提出的是该不该封的问题,而是否永久封禁,也被多位编辑质疑。查阅 ArikamaI君的封禁记录,ArikamaI君之前并未有因为创建没有来源的条目作为理由的封禁,而大量以机器翻译的1周封禁也是2009年之事,近5年都没有被封禁。WP:BLOCK指出封锁应为最后的手段,Mys 721tx君作出永久封禁,而不是先作有限期的封禁,亦被其他编辑指出是否 Mys 721tx君定论有限期的封禁不足以令 ArikamaI君打消建立该类条目的意愿,非立即永久封禁不可。
4. Mys 721tx君曰:“对警告无效的用户予以封禁理所当然。避嫌是明显的红鲱鱼”好几位编辑提到 阁下对 ArikamaI君的永久封禁没有避嫌。既然 Mys 721tx君于2020年10月5日在Wikipedia:申请解除权限/存档/2020年寻求解除 ArikamaI君的权限,而 AT君亦已经着手处理,并知会双方 Mys 721tx君及 ArikamaI君提出各自的理据,亦有初步对话,Mys 721tx君在此事上已属其中一方。虽然在紧急情况下,管理员可对疑严重违规的用户作出必要的封禁,但紧急情况是指仍在建立胡言乱语、恶作剧、人身攻击的页面,或者大量建立宣传推广页面,至于 阁下提及“在警告后公然创建无来源条目(D型消声榴弹发射器)”显然不符合紧急情况,该页面也不符合快速删除,当时的情况远未达到须要立即封禁、即时制止,完全可先作出提报及由第三方管理员处理。如认为须要可提报到破坏或不当行为页面,不应绕过提报机制及交由其他管理员作出判断,自行执行永久封禁。
5. Mys 721tx君曰:“不代表该用户创建条目的平均水平”,君在批判其他用户创建条目的水平,以至包括11年前的条目,然而 Mys 721tx君是怎样评判创建条目的平均水平呢? Mys 721tx君在2009年至今创建63个条目,排除重建的条目有1个名下条目被删除,就随机查看弹道学创建时的情况 [1] 及同期对于英文版 [2] ,不就是没有任何来源之后由其他维基人修缮;
还有在2017年4月24日,Mys 721tx君而言已算近期创建的条目普通外科 [3] ,参阅同期的英文版条目是载有来源 [4] ,在中文版作为正式条目却连一个来源都没有,该条目更要在两周后才由其他用户挂上一堆包括缺乏来源等的问题模板,反映其他用户也发现该等问题,及后需由其他维基人作后续修缮。Mys 721tx君,这不就是违反WP:VWP:RSWP:OR。在下实难以了解 Mys 721tx君是如何评断“创建条目的平均水平”,尤其是 Mys 721tx君身为管理员已不是短时间,更不应指责其他用户创建来源受质疑的条目及批判平均水平,但自身又建立没有任何来源、有违方针指引的页面并长期没有自行修缮,若然以来源或内容问题对其他用户作出封禁乃至永久封禁,难免让其他用户产生宽己严人的观感及质疑,当然 阁下可能另有苦衷啦。--Uranus1781留言) 2020年12月1日 (二) 13:34 (UTC)
User:Uranus1781长篇大论中充斥着逻辑谬误:
  1. 警告及封禁理由本身早已解释封禁原因,"还得有用户在本页作出投诉才本页发表封禁的观点"是显然的烟雾弹。
  2. User:ArikamaI2011年起创建的条目存在问题显然不是自2011年起即发现此问题,User:Uranus1781是在偷换概念。
  3. User:ArikamaI持续创建劣质条目未经提删或封禁显然证明其创建条目符合方针是循环论证。
  4. User:ArikamaI2018年起所创建的355个条目中,最早的十个条目(S-5航空火箭弹索尔丹姆K6迫击炮CRV7航空火箭弹Fate/Apocrypha角色列表S-8航空火箭弹瓦尔特CCP半自动手枪SIG MG 710-3通用机枪SIG M1911半自动手枪大宇K12通用机枪S-13航空火箭弹)以及最近的十个条目(D型消声榴弹发射器Ksp M/39中型机枪刺刀座L3A1刺刀雷明登V3半自动散弹枪M3夜视狙击镜406毫米SK C/34型舰炮330毫米口径50倍径1931年型舰炮152毫米口径55倍径1930年型舰炮ROKS火焰喷射器)皆存在整段无来源内容。User:ArikamaI所创建条目系统性地缺乏来源是客观事实。User:Uranus1781所谓"而查阅 ArikamaI君近两三年所建立条目之情况,不符合 Mys 721tx君所称:'所创建条目自2009年‘系统性地’缺乏来源'"更是公然撒谎。
  5. 避嫌仅有一个IP用户和User:Catowen提到。到User:Uranus1781处却成了"好几位编辑",其虚张声势能力叹为观止。然而谬论重复再多仍是谬论。
  6. "虽然在紧急情况下,管理员可对疑严重违规的用户作出必要的封禁,但紧急情况是指仍在建立胡言乱语、恶作剧、人身攻击的页面,或者大量建立宣传推广页面,"更是User:Uranus1781编造的方针。
然而其稻草人论证指名道姓,不得不予以反驳:普通外科一文正是因为英文条目质量不高才没有继续翻译。User:Uranus1781以"参阅同期的英文版条目是载有来源"暗示应当照抄英文条目来源更展示其对Wikipedia:可供查证中"引用的来源须明确支持条目中出现的信息"的无知。
-Mys_721tx留言) 2020年12月1日 (二) 20:32 (UTC)
如果User:ArikamaI一事的封禁标准成为“案例”,恐怕中文维基百科有一半活跃用户都有机会要“三振出局”(对用户发出警告留言也算作一次好球)。--Mewaqua留言) 2020年12月2日 (三) 04:46 (UTC)
是次封禁本身是根据User:ArikamaI无视警告创建无来源条目产生的。警告无效后予以封禁行之有年。封禁时间是对其活动持续时间的体现。如果作为判例显然需要考虑这些因素。-Mys_721tx留言) 2020年12月2日 (三) 04:58 (UTC)

我写的讨论被隐藏了,说与mys721_tx的这次封禁无直接关系。事实是有直接关系的,反映了mys721_tx一贯的滥权、轻罪重罚、选择性执法、对做出长期贡献的用户不友善、吹毛求疵玩弄维基制度,以及在理屈词穷时不敢直接出来对线,而是让其朋友或熟识的人出来辩解、拒绝正面回答问题并转移视线,辩解者使用不友善言辞对待维基编辑者等。这是屡次犯错却不知悔改,不知道维基百科编辑团队对于管理者重复犯规触纪如何处罚。当然我并不抱希望。例如我刚刚以友善和有建设性意义的评论作结尾,却被恶意隐藏。

我会立此存照并公开于适当场合。--周雁棠留言

@AnYiLinWikipedia:可供查证中白纸黑字“引用的来源须明确支持条目中出现的信息”。"来源中何处提到北京"这种简单问题都无法直接回答的小丑愿意表演跳梁就随他去吧。-Mys_721tx留言) 2020年12月2日 (三) 19:52 (UTC)

中文维基百科管理员就是如此辱骂编辑者的吗?复读机似的复读同一句没有意义的话,还有脸指责别人呢?我正面的、多次的解释清清楚楚,来源中有提到北京,这位却装作看不见。作为管理员,公然如泼妇一般跳脚骂人,按照维基规约应该怎么处罚?这样的行径比编辑瑕疵恶劣了多少倍?--周雁棠留言

    • mys721_tx对用户非常不友善,任意封禁用户,受害人不只ArikamaI和周雁棠,还有很多人,我觉得mys721_tx完全不符合作为管理员应有的态度。--203.145.95.13留言) 2020年12月3日 (四) 03:08 (UTC)
      对于上述用户,只有纵容其违反Wikipedia:可供查证才能称得上友善。en:Victim playing功夫真是令人叹为观止。-Mys_721tx留言) 2020年12月3日 (四) 04:18 (UTC)

别转移话题,你骂人就是错的。--周雁棠留言

跳梁:"乱蹦乱跳"。自2019年5月26日至今User:周雁棠共计加入31920字节文字,甚至指控他人“拒绝正面回答问题”。31920字节中却无一处解释其所谓来源如何提到北京。其所谓来源中总共五页提到北京,无一处提到索韦托。提到索韦托共五处,无一处提到北京。"来源中有提到北京,这位却装作看不见"是公然撒谎。跳梁是对User:周雁棠行为的客观描述。-Mys_721tx留言) 2020年12月3日 (四) 08:20 (UTC)

“ @Mys_721tx]]:,我的链接中有来源的,你搜索google中该书目的“索韦托 城中村”就可以检索到相关信息,如“南非这些打工的人,在所谓的有序城市化下,产生了一种“城不城、乡不乡”的情况。……这个就是索韦托。……它原来是一些打工的黑人在类似这种城中村,租一些比较差的房子。然后政府不允许,一开始搬到这个相当于二环以外……又把他们撵到四环外……”等内容,此外上下文还有大量佐证。您在回退中说“来源中没有”,怎么是“来源中没有”呢?而且在秦晖先生《南非的启示》一书中也有对南非索韦托这样的黑人聚居地和中国城中村的对比、南非种族隔离制度与中国户籍制度的详细对比。我所说的都有来源,请您查看我链接的具体内容,也希望您给出解释,谢谢。周雁棠(留言) 2019年5月26日 (日) 16:29 (UTC)”这篇文章是一个整体,作者就是在对比索韦托与北京的相似之处,我在讨论页做了多番解释,这位mys721_tx视而不见,只是复读一个没有意义的句子。现在骂人了又找借口,无论什么借口都不是骂人的理由,何况借口都不成立。你说我公然撒谎,为什么不正面回应我在讨论页提出的问题?还需要我把问的问题一一复制粘贴过来吗?周雁棠留言) 2020年12月3日 (四) 08:44 (UTC)

欢迎User:周雁棠向更多人其对Wikipedia:非原创研究的无知。-Mys_721tx留言) 2020年12月3日 (四) 09:08 (UTC)

我在讨论页已经解释的很清楚,二者是有关联的,表达的是一个系统的意思,而非无关的内容贴合。对于mys721tx各种出言不逊,我不想再浪费大家时间看吵架,有兴趣的请移步我的讨论页查看来龙去脉。恕不奉陪您没刷牙后的言辞。周雁棠留言) 2020年12月3日 (四) 09:16 (UTC)

User:周雁棠真是以为其站外那点龌龊无人知晓。其倒打一耙的能力无人能及。-Mys_721tx留言) 2020年12月3日 (四) 10:17 (UTC)

我将过程存照并且发在社交平台上,并加以评论,是我的权利。你管得了站内还管得了站外吗?是不是你先不尊重我、用冒犯式提问、对我多次选择性执法和不合理封禁、屡次拒绝回答我关于封禁的问题,我才如此回应的?是不是我好言好语给你说话,你却置之不理还一再加码封禁,我才在社交媒体上曝光的?你作为管理者对我刁难挑刺,算是龌龊还是堂堂正正?为什么封禁我你心里清清楚楚。现在还管到站外,你不觉得管的太宽里吗?当然,你也可以找个社交平台把事情论述一番、对我做出评价。周雁棠留言) 2020年12月3日 (四) 12:25 (UTC)

User:周雁棠于34601字节后仍未回答其所谓来源在何处提到北京,反而将如此简单之问题指为"冒犯式的提问"、"刁难挑刺"。在其公然承认违反方针("相关内容不必须需要特定来源"、"我对该事物非常熟悉")时明知故问,其虚伪程度可见一斑。-Mys_721tx留言) 2020年12月3日 (四) 18:12 (UTC)
请您先保持应尽之礼貌,否则您的任何辩驳都会苍白无力,以我之意见,缩短封禁时间,道歉,这是基本礼貌,而且在维基百科无处罚复合人员的情况下,避嫌是最大取消主观判定的最好方法--Catowen 学生狗快乐? 2020年12月4日 (五) 13:41 (UTC)
否则,弹劾--Catowen 学生狗快乐? 2020年12月4日 (五) 13:42 (UTC)
红鲱鱼。谬论重复多次不会成真。-Mys_721tx留言) 2020年12月4日 (五) 17:50 (UTC)
Wikipedia:文明:"不文明行为包括...轻率鲁莽地指控他人行为不当...说谎或欺诈"。User:Catowen两次以红鲱鱼论证将合理封禁指控为需要避嫌、在Wikipedia:封禁方针明确存在封禁复核机制时公然宣称"维基百科无处罚复合人员"。我要求User:Catowen正式于此道歉。-Mys_721tx留言) 2020年12月4日 (五) 18:38 (UTC)

建议预设开启“讨论工具”[编辑]

(&)建议如下:

由于目前“讨论工具”使用上大致畅顺,回复时自动缩排签名也运作正常,建议预设开启“讨论工具”,以便新手使用。

为何需要预设开启?
  • 新手目前在存废复核、存废讨论中,需要较频密地回复其他用户的留言。
  • 这些用户由于不谙维基语法,偶尔会没有使用缩排,使讨论混乱。
  • 与此同时,在存废复核中,经常看到用户忘记签名。
  • 在其他条目讨论页中,也有出现这个情况。
这个建议有用吗?
  • 有用。这样可以:
    1. 改善讨论排版及版面。
    2. 提升讨论的参与度。
    3. 提升新手参与讨论的体验。
    4. 可简化提及(Ping)其他用户的程序。
这个建议有害吗?
  • 没有。这个工具简单易用,不影响主名字空间、非讨论页等,亦鲜有出现技术问题或排版错误。
这个建议有效吗?
  • 理应比其他方式有效。其他方式可以是修改编辑提示、修改欢迎信息等,但效果将会没有那么明显。不是每个新用户都会详阅欢迎信息,也不会手动开启一个不熟悉的工具。因此,预设开启会是较有效的方式。
哪些用户应预设开启讨论工具?
  • 这个建议主要针对在本地注册的新用户。
为何不由其他用户修正?
  • 像是示例这样的讨论页,版面较乱,修正格式也需时。而且,有时用户会于上一条留言末插入自己的留言,可能令修正者陷入混乱。
IP用户呢?
  • IP用户受限制而不能开启“讨论工具”,这些用户可以考虑注册以便使用此工具;可能需用其他方式让IP用户认识如何留言,但则不在此讨论范畴内。一般来说,打算长期贡献的IP用户会注册账号,因此未必是主要的问题。

请踊跃参与讨论,感谢各位编者关心此提议,也欢迎提出意见。--14.0.180.204留言) 2020年11月4日 (三) 08:58 (UTC)

目前已经在测试功能里了。您的这个要求可能太急了点--百無一用是書生 () 2020年11月5日 (四) 01:13 (UTC)
我相信不是问题,目前一些语言的维基百科也是预设开启。--14.0.180.194留言) 2020年11月5日 (四) 04:27 (UTC)
有些小白连参数设置咋用都不知道,还是预设开启比较好,另外我觉得wikiplus也不错,直接点一下就编辑了,挺方便的--Catowen 2020年11月8日 (日) 01:03 (UTC)
(▲)同上:回复功能蛮方便的,默认开启也不会引起什么问题;不过Wikiplus受限于API,至少是自动确认用户(有经验的用户)才可以使用。--安忆Talk 2020年11月8日 (日) 01:29 (UTC)
  • (+)支持该提议,对新手甚是友好,亦避免乱糟糟讨论串和忘记签名。Zhuofan WuCien años de soledad 2020年11月8日 (日) 12:02 (UTC)
(+)支持Fire Ice 2020年11月8日 (日) 13:16 (UTC)
建议先了解一下项目进度比较好:mw:Talk pages project/replying--百無一用是書生 () 2020年11月9日 (一) 01:57 (UTC)
上述页面有提到:

This means the Reply Tool is now available as either a Beta Feature or opt-out user preference at all Wikipedias except for the following projects: English, Finnish, Gan, German, Inuktitut, Kazakh, Kurdish, Russian, Tajik, and Uzbek.

因此,可以是Beta Feature,或者是opt-out user preference,exception当中不包括中文维基百科。这建议理论上可以实行。--14.0.180.36留言) 2020年11月9日 (一) 03:43 (UTC)
(+)支持加入。另提醒IP用户:讨论工具有一大缺点就是缩排符号只有:,并不支援*-- Sunny00217  2020年11月14日 (六) 11:43 (UTC)
  • (+)倾向支持提议。基本上有益无害,不过要注意一下工具是否已经稳定。—— Eric Liu 创造は生命(留言留名学生会 2020年11月22日 (日) 09:17 (UTC)
  • (+)倾向支持加入,我其实不太习惯。“ 对新手甚是友好”,嗯⋯,其实不一定,我还是不太了解,源代码比较和平时写东西时一样(怕有人把条目当讨论工具写)。—ℑ𝔪𝔭𝔞𝔯𝔱𝔦𝔞𝔩 𝔧𝔲𝔰𝔱🎙️ 2020年11月29日 (日) 06:01 (UTC)

关于是否可以在传统节日时大量发送祝福信息[编辑]

如题,我觉得可以在中国传统节日时向所有活跃用户(主要是用户太多了)通过一个机器人(或者请求一位拥有大量信息发送权的用户)发送祝福信息,私以为这样可以让大家在编辑的时候感受到温暖,希望大家给出建议,感谢! --光猫猫 Talk 2020年11月14日 (六) 02:53 (UTC)

为什么是中国传统节日?俄罗斯传统节日不行吗?巴西传统节日也不行吗?难道这里所有活跃编者都来自中国吗?--14.0.180.147留言) 2020年11月14日 (六) 03:08 (UTC)
虽然不全是,但大多数都是中国人。因此我觉得没有问题,俄语只有俄国传统节日我觉得也没问题啊。--光猫猫 Talk 2020年11月14日 (六) 03:21 (UTC)
前提是需要给予用户不接受此消息的自由。--安忆Talk 2020年11月14日 (六) 03:09 (UTC)
嗯,也是,也可以在搞一个拒绝接收信息的单独列表。这样的话似乎就只能通过机器人实现了。--光猫猫 Talk 2020年11月14日 (六) 03:19 (UTC)
群发消息,未见诚意。Fire Ice 2020年11月14日 (六) 04:08 (UTC)
为何?群发的祝贺皆由社群讨论得出,乃是社群对社群的关心,何来没有诚意一说?况且新用户欢迎消息也是自动发送的消息,新用户欢迎是否也没有诚意?--光猫猫 Talk 2020年11月14日 (六) 10:50 (UTC)
确实没有诚意,正如欢迎新用户一样没有诚意。还记得某一年春晚有一个节目/歌曲叫“群发的短信我不回”。对于不知道欢迎词是群发的新用户而言,确实会误认为很有诚意,后来发现是机器人发的也就那样了。每年过节,真正好友之间自然会手动发祝福。所以群发祝福实在不是一个好举措。如果要弄的话,应该是白名单模式而不是黑名单模式,默认不接受,想要接受的就自己加入白名单,正如每年的动员令通知一样。--dqwyy (talk) 我们终将成为枫音乡的过客 2020年11月24日 (二) 06:26 (UTC)
我没所谓,反正有和没有于我而言无分别。SANMOSA SPQR 2020年11月14日 (六) 09:31 (UTC)
嗯,但是这个议案的目的在于让活跃的编辑感受到社群的关心。--光猫猫 Talk 2020年11月14日 (六) 10:51 (UTC)
与其如此筛选编者来发放祝福,不如在节日期间于{{ASN}}(或其它合适位置)里面挂上一条简洁的横幅
恭    祝    新    年    快    乐
类似这样,也可是其他形式。--14.0.180.147留言) 2020年11月14日 (六) 11:28 (UTC)
23333 似乎也可以--光猫猫 Talk 2020年11月14日 (六) 11:55 (UTC)
歪一下楼,去年春节的小老鼠Logo挺可爱的。明年是农历牛年,不知道社群有没有意愿再换一次特别Logo。--Steven Sun留言) 2020年11月14日 (六) 12:26 (UTC)
这么快讨论?(虽然我觉得是可以)SANMOSA SPQR 2020年11月15日 (日) 12:25 (UTC)
嗯....我觉得可以要请些人来参加讨论。如果没有问题的话我下周开始着手制作机器人,尽量在春节前完工。--メッキの光の勇者-猫🇨🇳去茶水室喝茶🐱 2020年11月15日 (日) 14:19 (UTC)
如果是机器人就反对,如果是手工发就不发表意见。祝福都用机器人来那何必呢,打扰人而已。--7留言) 2020年11月15日 (日) 14:58 (UTC)
同意上方诸位的讲法,群发讯息没有诚意。手工发还有一个优点,就是能够自己能够量身订造,说些感谢对方的话,这是群发讯息做不到的。另外ASN不建议放横额(个人论述有讲到),还有上面那个方案很像灵堂上挂的那种。--春卷柯南-发前人所未知 ( ) 2020年11月15日 (日) 15:03 (UTC)
群发缺乏诚意,会打扰、受宠若惊、花费当事人时间,以及浪费资源。订阅制或手动发没意见。挂标志前提是好看,其次再考虑文化问题。--YFdyh000留言) 2020年11月25日 (三) 20:48 (UTC)
在设置或者相关页面订阅消息,也是一个好办法。--Leiem留言·签名·维基调查 2020年11月26日 (四) 02:55 (UTC)

“到底哪一句话是广告?”[编辑]

我认为,“到底哪一句话是广告?”这一问题是有意义的。维基百科:如何介绍自己的公司应删去以下文字:

“到底哪一句话是广告?”

好似询问“Fu*k中哪一个字母是粗口”一样,这个问题是没有意义的。

Fire Ice 2020年11月23日 (一) 15:23 (UTC)

(!)意见:不见得总是有意义。大多时候一段话若是广告,确实可以找出其中某几句是广告,但文字的组合千变万化,简直无穷无尽,所以也不排除“每一句话都不是广告,但这些话组合在一起却是广告”的可能性。所以我主张改写而不是删去那段文字。-游蛇脱壳/克劳 2020年11月24日 (二) 08:03 (UTC)
这种可能性我还真想象不出来……Fire Ice 2020年11月25日 (三) 14:28 (UTC)
可以想象,广告形式很多的--百無一用是書生 () 2020年11月26日 (四) 02:22 (UTC)
也可能有意义,也可能无意义。不过这句话本身似乎放在那里没帮助,我认为删掉也很好。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2020年11月25日 (三) 14:07 (UTC)
也觉得这段话没有意义,懂的都懂、看它没用,不懂的更加不懂。支持删去。--YFdyh000留言) 2020年11月25日 (三) 20:51 (UTC)
这句话看上去确实没有意义,支持删去。--向前进朝着胜利的方向 2020年11月26日 (四) 11:09 (UTC)
尔比南山

为民谋福

王者风范

八方咏赞

每句话都在称赞,到底哪句话在骂人?(藏头诗)

君知妾有夫,赠妾双明珠。感君缠绵意,系在红罗襦。妾家高楼连苑起,良人执戟明光里。知君用心如日月,事夫誓拟同生死。还君明珠双泪垂,恨不相逢未嫁时!---张籍《节妇吟》

到底哪句话在拒绝藩镇李师道的网罗入幕?(隐喻,言在此而意在彼)

对联:莲子心中苦,梨儿腹内酸---金圣叹

到底哪句话在表达与儿子诀别的酸苦?(谐音双关)

所以“没有一句话是广告,但是合起来整段话就是广告”有心要做,是有可能做得出来的。但是我也认为“好似询问“Fu*k中哪一个字母是粗口”一样”这个类比是非常不妥的,它太小看文字的变化多端。-游蛇脱壳/克劳 2020年11月26日 (四) 15:24 (UTC)

咨询大家对于编辑界面的编辑提示的看法[编辑]

当前在每个编辑界面当中都会出现这么一行小字:

这一行字的目的应当是提醒每位编者在编辑之前都应当注意的事项,但是就我的编辑体验而言,存在两个问题:

  1. 不够醒目。本身字号就小(甚至还没上面引用当中的字号大),下面还紧贴着一个巨大的、文字丰富的编辑框,用户一般不容易注意到这个提示文字。心急的新用户修改内容的时候注意不到提示会带来不少麻烦。
  2. 可视化编辑器根本不会显示这个提示。

个人希望将这个提示变得更为醒目,最好能像被封禁那样显眼的提示,但是我在这里想咨询一下大家的看法和体验。--MilkyDefer推迟咕咕 2020年11月26日 (四) 17:59 (UTC)

  • (+)倾向支持。—— Eric Liu 创造は生命(留言留名学生会 2020年12月4日 (五) 03:00 (UTC)
  • (&)建议:可以弄成向IP用户在初次编辑时展示的欢迎弹窗一样的形式,唯有确认方可继续。 --安忆Talk 2020年12月4日 (五) 03:09 (UTC)
    • 这是不是太烦了,徒增几次鼠标点击次数 --MilkyDefer推迟咕咕 2020年12月4日 (五) 09:46 (UTC)
      • 既然是必读的提示,点几次(貌似只需要点一次“确定”)才可以确保他读过了。--安忆Talk 2020年12月4日 (五) 10:24 (UTC)

社群首页改版 3.0[编辑]

维基百科:社群首页/改版,见下面的讨论。--1233 T / C 2020年11月28日 (六) 09:16 (UTC)


这是第二次本人的改版,改版后连同所有子页面的大小从 39541 字节减至 31707 字节,并且增加了导航,各不同的子类别亦作出适量的重新编排。改版后亦应该会更'mobile-friendly'。--1233 T / C 2020年11月27日 (五) 19:11 (UTC)

视觉效果我觉得好了不少,不过留白似乎有点多。--Easterlies 2020年11月27日 (五) 19:35 (UTC)
同,margin过大,考虑到大屏幕设备和兼容性,也要尽量用em而不是vh。如果可以的话,是否可以直接修改外联CSS以使用@media呢(站内的CSS可以识别到页面名称)。--安忆Talk 2020年11月28日 (六) 03:22 (UTC)
大屏幕设备本身的用户体验需要放大才会比较正常。这个设计在放大的时候会比较好--1233 T / C 2020年11月28日 (六) 06:21 (UTC)
能不能把下面六个方框按照2x3排列,我电脑上显示第一行5个第二行1个还是居左,强迫症要压不住了。--MilkyDefer推迟咕咕 2020年11月28日 (六) 02:10 (UTC)
@User:MilkyDefer:您需要减少Max screen width吗(--1233 T / C 2020年11月28日 (六) 06:21 (UTC)
能居中吗?公告栏都居中了……然后我看公告栏在电脑上还能适当再加宽一些。--MilkyDefer推迟咕咕 2020年11月28日 (六) 07:29 (UTC)
div限制,没办法(如果真的做了就会非常繁复)--1233 T / C 2020年11月28日 (六) 08:44 (UTC)
我了解这次是为了增进行动版体验才这么改版的,但我觉得这样分拆桌面版体验反而变差了。—— Eric Liu 创造は生命(留言留名学生会 2020年11月28日 (六) 03:16 (UTC)

增加了min-width 300px, max-width 提升至1080px,中间为75%。--1233 T / C 2020年11月28日 (六) 06:26 (UTC)
  • 这个大白边和新版vector的相性应该会相当高[开玩笑的]--Súper Wáng Adios Diego 2020年11月28日 (六) 08:12 (UTC)
  • 那个是960px max width,需要修改一下(--1233 T / C 2020年11月28日 (六) 08:47 (UTC)

Break 0.5[编辑]

  • 我可以(-)反对此改版吗 ? 有没有用户觉得2.0好过3.0 ? 为了增进行动版体验牺牲桌面版体验 ? 用行动版的用户有几多 ? 用桌面版的用户有几多 ? 改之前有没有问过社群和投票 ? 原来社群首页的页面竟然是某一用户的所有物,话改就改,真是令人惊讶。强烈建议转回原来版本。〈如果我错过任何改版消息,我对此抱歉,因为我不知道几时几日哪里出过改版消息〉-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 08:56 (UTC)
    • 有道理…要不先开个子页放修改中的版本,差不多了再看情况移过去。现在先用九月份的版本,直接实装是有些仓促。顺便一提,现在版本的内联样式,背景色和文字颜色的十六进制值的#号都没加… --安忆Talk 2020年11月28日 (六) 09:07 (UTC)
      • 很久以前,维基要进行改版面都有问过社群和投票吧 ? 为何这次没有 ? 如果我错过任何相关消息,我再一次对此抱歉。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 09:13 (UTC)
        • 把旧的版本放回去了。另外新版在维基百科:社群首页/改版#号是没有了必须,所以没有加出来…--1233 T / C 2020年11月28日 (六) 09:16 (UTC)
          • 感谢改回,新版本使我要花多少少时间去找页面,有点不方便。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 09:19 (UTC)
            • 改版的契机就是太多东西给堆在一起了,而且(正如Super Wang说过),UI的改版快出现了,所以就顺手改版而已。当然这类型的改版会有不同的意见,所以既然有人感到不便,那就开出来讨论。这页面每天都会有200-300人浏览,而这次的修改就是让移动端的读者也会有相约的体验而已。--1233 T / C 2020年11月28日 (六) 09:24 (UTC)
              • 改版要解决留白问题,否则宁愿等到最后一刻才改。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 09:30 (UTC)
                • 不理解留白的问题何意。--1233 T / C 2020年11月28日 (六) 09:34 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────就是桌面端太空了。如果要同时兼顾桌面和移动设备的话,我觉得必须要配置@media,可能需要common.css的配合(这样也能实现更好的样式,比如那几个方块的自适应)。 --安忆Talk 2020年11月28日 (六) 09:37 (UTC)
可以使用min/max/width div 配合。现在是因为把内容分类,只保留公告页,导致页面看起来比较“空虚”。现在的设定是 width: 0-400px 的时候300px,400-1440px的时候为页宽的75%,多于1440px时则是1080px。--1233 T / C 2020年11月28日 (六) 09:42 (UTC)
以提早进行改版的法语维基百科为例,不知是否萤幕问题,法语维基百科的页面右侧有一大片留白,这差别,和未进行改版的中文维基百科相比,极其明显,而且极其碍眼。阁下的社群首页的页面改版方案也是这样,而且页面左右侧有一大片留白,碍眼同时浪费版面。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 09:43 (UTC)
有些麻烦…还是觉得直接用class方便一些(尤其是下面的几个方块)。如果设计好的话,common.css改起来的流程也不麻烦。韩语维百的桌面视图挺好看的,其在移动设备上的表现也不错。--安忆Talk 2020年11月28日 (六) 09:49 (UTC)
那是故意的,详见这里这里。这也是改版的原意。@Comrade JohnAnYiLin:--1233 T / C 2020年11月28日 (六) 09:54 (UTC)
强加于人,要逼人接受的所谓“良好愿望”,宁愿等到最后一刻才改。--约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 09:58 (UTC)
所以我也回退,不过随时间堆积的资料对我感到不便。另外@AnYiLin:,我那段的div设定是:min-width 300px; width: 75%; max-width: 1080px;--1233 T / C 2020年11月28日 (六) 09:59 (UTC)
啊…那便留罢。不过下面几个方块那不尽如人意的适应性也是…故意的吗?我觉得单靠内联样式有点儿不够用,并且很麻烦…--安忆Talk 2020年11月28日 (六) 10:03 (UTC)
改了,现在应该是min-width 10em; width: 100%; max-width: 65em--1233 T / C 2020年11月28日 (六) 10:08 (UTC)
还可以,但仍喜欢2.0那种将各个方面折叠,即时看到里面的东西,而不是要到另一页面找东西。--约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 10:14 (UTC)
现在的问题其实和内容太多有关,且折叠并没有改善页面载入时间,所以才会拆开。而且新的导航其实也尝试解决那个难以回到主页的问题。--1233 T / C 2020年11月28日 (六) 10:18 (UTC)
2.0和3.0的页面载入时间,两者相比是如何 ?-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 11:10 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────@Comrade John旧版的平均需要7秒新版平均需要5秒
载入时间
测试结果 旧版 新版
开始载入 3.181 s 3.348 s
内容载入完成 6.735 s 3.996 s
全部载入完毕 7.571 s 5.091 s
以上,--1233 T / C 2020年11月28日 (六) 11:38 (UTC)
香港的测试数据均有相似结果:旧版新版--1233 T / C 2020年11月28日 (六) 11:45 (UTC)
旧版 对比 新版,取自另一个测试源(新版比旧版快)。旧版比新版快的测试。--1233 T / C 2020年11月28日 (六) 11:56 (UTC)
二哈二哈您这网速怎么比我在大陆用VPN都慢…--安忆Talk 2020年11月28日 (六) 13:02 (UTC)
First load time通常比较久。--1233 T / C 2020年11月28日 (六) 13:14 (UTC)
(*)提醒:<center>标签已过时,请使用CSS。而且公告区没有设置padding。另外做到网页自适应完全没有必要在桌面端大量留白,参考一下Wikipedia:首页/styles.css的做法,完全可以在不留白的情况下适配移动端。--Steven Sun留言) 2020年11月29日 (日) 01:35 (UTC)
反正所有人都可以修改,我有点看不懂,可否解释一下?现在我是期望避免出现页面css。--1233 T / C 2020年11月29日 (日) 04:18 (UTC)

分段1[编辑]

纯吐槽,现在新版的Vector是可以在设置中启用:偏好设定->外观->剔走使用旧版Vector(Uncheck the "use old vector" box)。(--1233 T / C 2020年11月28日 (六) 13:21 (UTC)
(...) 吐槽:新版不是很好看,还不如timeless。--安忆Talk 2020年11月28日 (六) 13:27 (UTC)
谁知道“使用旧版Vector”这个选项是否永久。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 13:51 (UTC)
不是,据说是去到2021 Q2后,此选项预设关闭,但是旧版Vector不会被取消,有点像Monobook - Vector Transition。--1233 T / C 2020年11月28日 (六) 13:55 (UTC)
如果旧版Vector仍在,还算好。-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 14:00 (UTC)
新设计对新Vector
旧设计对新Vector
两者的在新Vector页面时候的分别--1233 T / C 2020年11月28日 (六) 16:04 (UTC)
那么新设计在电话和平板电脑上呈现如何 ?-- 约翰同志-条目裱糊匠留言) 2020年11月28日 (六) 17:15 (UTC)
不理解,但应该差异不大。主要看是zh.wikipedia 还是 zh.m.wikipedia。--1233 T / C 2020年11月29日 (日) 04:14 (UTC)
新版的确清爽不少,但是每项公告的前缀表示完全和整体社群首页的设计违和啊,完全不是一种风格.....--百無一用是書生 () 2020年11月30日 (一) 02:53 (UTC)
话说新版社群首页,公告下那几个连结使用Template:Tabs或类似的模板是否可行 ? 这样将各个方面折叠,即时看到里面的东西的同时,其连结内容因实际上是新页面,社群首页的字节实际上很少,这样载入时间会比较快吧 ?-- 约翰同志-条目裱糊匠留言) 2020年11月30日 (一) 09:57 (UTC)
Template:Tabs完全是另外一种风格了--百無一用是書生 () 2020年12月1日 (二) 02:38 (UTC)
不能,而且这个会发生Transclusion的问题,结果仍然不能改善现时载入时间的问题。--1233 T / C 2020年12月2日 (三) 09:29 (UTC)
唉,好吧。-- 约翰同志-条目裱糊匠留言) 2020年12月2日 (三) 09:49 (UTC)
载入时间主要是受到下列因素影响:页面大小/使用的模板/有没有使用CDN等因素。如果使用类似Template:Tabs的模板,虽然页面大小减少,载入时间却可能更长。这和Loop类似。--1233 T / C 2020年12月2日 (三) 12:09 (UTC)

Parent monthly clean up category 模板坏掉了[编辑]

已解决。--Easterlies 2020年11月30日 (一) 11:31 (UTC)

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

{{Parent monthly clean up category}}好像被改坏掉了,以前才能逐月分类的,现在只有“未有月份分类之条目”这一类了。--⚠️警告:签名长度过长,请协助修改签名。解决该问题后,请删除这段文字。这个问题都是因为IN的错![开玩笑的] 2020年11月29日 (日) 04:44 (UTC)

 已修复,回退:Special:Diff/62978021Special:Diff/62978028Special:Diff/61050291/62978049Special:Diff/61050374/62978050。--Xiplus#Talk 2020年11月29日 (日) 05:55 (UTC)

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

提议用机器人清理违反UP#11的用户空间页[编辑]

截止我发言时,CAT:已索引页面里面的页面全是用户空间页。然而,根据Wikipedia:互助客栈/方针#用户讨论页是否适用于UPNOT中Easterlies的说法,这些页面全部违反WP:UT#11,因此我想请求机器人帮忙移除这些页面的INDEX魔术字。--⚠️警告:签名长度过长,请协助修改签名。解决该问题后,请删除这段文字。这个问题都是因为IN的错![开玩笑的] 2020年11月30日 (一) 05:03 (UTC)

各位抱歉,我上面打错了,“已”打成了“不可” 囧rz...。--马上我就要入维一周年了,还想再讨一个蛋糕…… 2020年12月2日 (三) 18:07 (UTC)

如何提高将自行拍摄照片上传至维基共享资源的方法?[编辑]

在维基共享资源协助移动照片多年,会发现总有固定几位使用者,始终把明显为自己拍摄的照片上传到这里,而不是直接在维基共享资源上传。这个是每个人的选择自由,所以并没有说要做什么,但我觉得这个现象值得来讨论。

目前这类使用者当中大部分都是中国大陆使用者,能想得到的大多数原因是IP被挡无法上传,但不知道如何申请维基共享资源的封锁例外权限。不过其他地方没有挡IP的问题,但还是如此,我碰到的说法例如懒得弄、曾被共享资源删除照片等等。

那么,我们要如何鼓励并提升将自行拍摄的照片,移动至维基共享资源的动力呢?台湾杉在此发言 (会客室) 2020年12月1日 (二) 14:58 (UTC)

协议吻合,直接转走。toollabs:commonshelper——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年12月2日 (三) 00:48 (UTC)
这系统问题吧,要跳转结果资讯会遗漏。也不知道网页系统是哪个天才做的--Zsfi留言) 2020年12月2日 (三) 05:21 (UTC)
是会有一些信息遗漏,但应该是我们这里的信息模板不规范所以没法导入相应信息?可以收工补充?——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年12月2日 (三) 07:43 (UTC)
可以在这里上传的表单上写一个提示语(应该可以实现的吧……),然后一定要写好到底怎么申请 IPBE 的文档,并且得让人找得到那些文档(甚至可以放进WP:WELCOME之类的地方)--From RavenclawOIer with love 2020年12月2日 (三) 08:57 (UTC)

法律硕士(学位)并入条目[编辑]

A/B test for the Reply tool[编辑]

Hello. 请帮助翻译至您的语言.

The mw:Editing team is building the Reply tool. This new tool was requested during the mw:Talk pages consultation 2019. If you want, you can turn it on now at Special:Preferences#mw-prefsection-betafeatures.

The Editing team would like to test the tool. They want to study whether it works better, especially for new editors. In the test, they will turn on the Reply tool for half of editors sometime during the week of 14 December 2020. They will not change preferences for the other editors. You will still be able to turn it on or off yourself in Special:Preferences.

The test will run for several weeks. The results will be posted at mw:Talk pages project/replying#Metrics in late January or February. The test results will help Wikipedia editors and the Editing team decide whether the tool should be turned on for everyone.

If your Wikipedia does not want to participate in this test, please contact me as soon as possible. Thank you. Whatamidoing (WMF)留言) 2020年12月2日 (三) 22:12 (UTC)

简而言之,WMF那面会在14号那周灰度一半的人来测试回复工具,不过不想用的话也可以自己在参数设置里关掉。--安忆Talk 2020年12月3日 (四) 05:43 (UTC)
我们不是预设开启了吗-- Sunny00217  2020年12月3日 (四) 11:22 (UTC)