跳转至内容

维基旅行:旅行者茶馆/2022

来自维客旅行

以前悬停在链接上时有描述,但现在这些描述显示为空白,有人能修复这个问题吗。我认为这可能发生在目录消失的时候。 Tai123.123讨论2021年11月7日 05:49 (UTC)[回复]

对我来说它仍然有效。 SHB2000 讨论 | 贡献 | meta.wikimedia 2021年11月7日 07:42 (UTC)[回复]
你是指带有图像和部分文章文本的弹出窗口吗?对我来说,有弹出窗口,但应该有文本的部分是空的。我认为它们以前不是这样划分的,所以是否发生过某种变化? –LPfi讨论2021年11月7日 09:04 (UTC)[回复]
我看到了三种类型,我习惯的那种,有或没有文本,以及水平分割的、没有文本的那种。某些版本可能来自我的缓存。 –LPfi讨论2021年11月7日 09:06 (UTC)[回复]
感谢您发布此说明。我已提交一个 bug 报告。
如果您那里仍然有效,那么您可能正在使用小工具“导航弹出窗口:页面预览和编辑功能在悬停在内部链接时弹出”。尝试在隐私/隐身窗口中进行查看,以查看简化的页面预览(几乎所有读者都能看到的内容)。 WhatamIdoing讨论2021年11月7日 16:38 (UTC)[回复]
谢谢你提交了 bug。我大约三分之一的链接都能看到文本,包括我很久没访问过的页面,所以这可能是 WMF 的缓存,而不是我的问题,它负责处理这些。Phabricator 可能需要一个示例文章和其中的一个示例链接。 –LPfi讨论2021年11月7日 18:43 (UTC)[回复]
谢谢!我看到的(链接)带有照片但没有文本。 Tai123.123讨论2021年11月7日 19:01 (UTC)[回复]
@Jdlrobson 已经整理好了这个 bug。我不知道修复需要多长时间,但它已经启动了流程。 WhatamIdoing讨论2021年11月9日 16:32 (UTC)[回复]

──────────────────────────────────────────────────────────────────────────────────────────────────── 顺便问一下,有没有办法让导航弹出窗口显示一张更有趣的图片,而不是文章中的任何一张列表/标记图片?很遗憾,当我悬停在一个链接上时,出现的图片通常是机场或其他不美观的交通基础设施,而不是目的地更具代表性的有趣图像。 —Granger 讨论 · 贡献2021年11月29日 16:06 (UTC)[回复]

据我所知,没有直接的方法可以做到这一点。我怀疑 @Quiddity (WMF) 可以给出确切的答案。 WhatamIdoing讨论2021年11月29日 22:13 (UTC)[回复]
我只能指向该小工具的文档(w:zh:Wikipedia:工具/导航弹出窗口#Features),其中表明 可以覆盖显示的图像(参见 2a 和 2b 的对应项目符号)。我没有使用该特定功能的经验,因此建议您在沙盒中进行测试,如果您遇到任何困难,请在文档的讨论页上提问。 Quiddity (WMF)讨论2021年11月29日 22:37 (UTC)[回复]
@Quiddity (WMF): 谢谢!为方便他人参考,我将相关项目符号复制到此处。
  • 预览中显示的图像可以通过在文章中添加一个图像提示来控制,形式是一个不可见的 HTML 注释<!-- popup [[File:Desired_Preview_Image.jpg]] -->.
我尝试在 广州 中实现这一点,但没有成功——弹出窗口仍然显示一个来自 广州#Get in 的无聊的火车站,而不是文章中的第一张图片,也不是 HTML 注释中的图片。我将等待一段时间,看看是否有缓存需要更新,如果没有,我将询问文档的讨论页。 —Granger 讨论 · 贡献2021年11月30日 21:07 (UTC)[回复]
@Granger 两天后,我在隐身模式下也看到了相同的火车站。但是,它对小工具有效。所以可能不是缓存问题。 SHB2000 讨论 | 贡献 | meta.wikimedia 2021年12月2日 07:02 (UTC)[回复]
我是否可以理解为 HTML 注释的修复仅适用于“导航弹出窗口”小工具,而不适用于未注册用户和未启用小工具的用户看到的“页面预览”?是否有办法修复页面预览(而不是导航弹出窗口小工具)? @WhatamIdoing, Quiddity (WMF):Granger 讨论 · 贡献2021年12月2日 10:55 (UTC)[回复]
另一个建议,添加文件并将大小设为 1px。以前从未尝试过,但我很快就会尝试。 SHB2000 讨论 | 贡献 | meta.wikimedia 2021年12月2日 10:59 (UTC)[回复]
那似乎也无效。 SHB2000 讨论 | 贡献 | meta.wikimedia 2021年12月2日 11:01 (UTC)[回复]
对于扩展版本(PagePreviews),未注册用户看到它使用另一个扩展(PageImages)来选择图像。它目前如何工作的详细技术文档位于 mw:Extension:PageImages#Image_choice。但是,有一个正在进行的讨论,并且看起来有一位志愿者开发者正在进行一些开发工作,在 phab:T91683(“允许编辑者控制页面图像”)中,关于使其更易于编辑器覆盖。希望这有帮助! Quiddity (WMF)讨论2021年12月2日 20:26 (UTC)[回复]
谢谢!看起来有一些选项可以更改选择图像的算法。我认为最简单的修复方法是将 $wgPageImagesLeadSectionOnly 设置为 true,这样 PagePreviews 只会使用导言部分的图像。然后我们可能需要确保文章在导言部分有图像(这本身也是一件好事)。其他人对此想法有什么看法? —Granger 讨论 · 贡献2021年12月3日 06:52 (UTC)[回复]
许多主要目的地和星级文章在导言部分缺乏图像。对于我创建或大量编辑的文章,我避免使用导言部分图像,以免与横幅图像冲突/竞争。我通常将第一张图像放在“了解”部分。--Nelson Ricardo讨论2021年12月4日 01:28 (UTC)[回复]
有时导言图片(例如在 锡安国家公园 中看到的)实际上可以解决问题。我通常喜欢在导言中包含一张,但并非总是如此,例如在 哈茨山国家公园 中(但你看到的是一棵无聊的树)。 SHB2000 讨论 | 贡献 | meta.wikimedia 2021年12月4日 01:36 (UTC)[回复]
@Nelson Ricardo 2500: 在那种情况下,如果我们实施我的建议,我认为我们需要要么在这些文章的导言中添加图像,要么接受它们的预览将没有图像。对我来说,为了避免在许多文章预览中出现这些无聊的机场和火车站的图像,这是值得的。我宁愿预览中没有图像,也不愿看到一个不起眼的火车站。当然,如果有人有其他建议,我持开放态度。 —Granger 讨论 · 贡献2021年12月5日 13:28 (UTC)[回复]

通用行为准则执行草案指南评论期结束

感谢您一直以来对通用行为准则执行指南的评论和想法。您的回复有助于建立一个更强大的通用行为准则。

如果您尚未发表评论,现在是时候了,因为起草委员会一直在 开会更新执行指南。起草委员会希望在进行更新时考虑所有评论。请在 11 月底之前提交任何评论。委员会希望在年底前完成修订,修订后的指南将在完成后尽快发布。

通用行为准则的下一步包括关于执行指南批准的讨论。11 月 29 日将举行一个 关于批准的讨论

维基媒体基金会将就指南的批准向董事会提出建议。这将为通用行为准则流程的下一步提供信息。

此致, Zuz (WMF)讨论2021年11月25日 15:53 (UTC)[回复]

与社区技术交流:社区愿望清单调查的未来

大家好!

我们,负责 社区愿望清单调查 的团队,诚邀您参加我们的在线会议。会议将于 11 月 30 日星期二),17:00 UTC)在 Zoom 上举行,持续一小时。 点击此处加入

议程

  • 社区愿望清单调查 2022 的变更。请帮助我们决定。
  • 成为社区心愿单调查大使。帮助我们在您的社区宣传 CWS。
  • 问答

形式

会议不会录制或直播。会议记录将匿名公开在 Meta-Wiki 上。演示文稿(议程中除问答环节外的所有要点)将以英语进行。

我们可以用英语、法语、波兰语、西班牙语、德语和意大利语回答问题。如果您想提前提问,请在 社区愿望清单调查讨论页 上添加,或发送至 sgrabarczuk@wikimedia.org。

Natalia Rodriguez社区技术经理)将主持本次会议。

邀请链接

希望见到您! SGrabarczuk (WMF)讨论2021年11月26日 20:03 (UTC)[回复]

即将举行的董事会选举反馈征集

董事会正在准备一项关于即将举行的董事会选举的反馈征集,时间为 2022 年 1 月 7 日至 2 月 10 日。

虽然详细信息将在征集开始前一周最终确定,但我们已确认至少有两个问题将在本次反馈征集中提出。

  • 如何最好地确保新兴社区在董事会中的公平代表性?
  • 候选人在选举期间应有多少参与度?

虽然可能会增加额外问题,但运动战略与治理团队希望为社区成员和分支机构提供时间来考虑并准备上述已确认问题,然后再开始征集。社区成员也可以在征集期间组织本地讨论。您可以在 此处找到有关此即将举行的反馈征集的更多信息。

此致, Zuz (WMF)讨论2021年12月23日 23:46 (UTC)[回复]

年龄证明

在英国、美国以及可能还有其他一些国家/地区的页面上,我们说你需要出示身份证件才能证明你已年满 18/21 岁(或其他年龄)才能进入酒吧或购买酒精饮料。

我想对于年轻人来说这是对的,但保镖难道不能相信一个 50 岁的人吗?这里大多数商店都要求看起来比 30 岁年轻的人出示身份证,我认为这给了很好的余地(饮酒年龄是 18 岁),足以让一些非青少年外国游客口渴。

我们是否应该明确说明,这些要求何时以及何时不适用于看起来不像青少年的人?你可能不想随身携带护照,而这通常是你唯一可接受的身份证件。其他身份证件在全球范围内是否普遍被接受?

LPfi讨论2022年1月4日 16:19 (UTC)[回复]

我们考虑过一篇关于 青年旅行 的文章,以探讨年轻人旅行时可能遇到的好处和担忧。也可以在 带孩子旅行老年人旅行 中提及。/Yvwv讨论2022年1月4日 16:21 (UTC)[回复]
在美国,法律并不要求你出示身份证;法律要求企业遵守销售年龄。因此,每家企业都有自己的政策决定如何遵守法律。我见过一些地方对除了明显是老人之外的所有人都查 ID,也见过一些地方似乎根本不查 ID。通常的做法是由员工估计年龄,只对看起来更年轻的人查 ID,但没有标准。 WhatamIdoing讨论2022年1月4日 16:58 (UTC)[回复]
我想在这种情况下的 50 岁的人可能会被算作“明显的老人”,这意味着他们不需要在那里出示身份证。这里以前也是这样,但现在 30 岁成了一个明确的标准,也许是因为某个宣传活动。 –LPfi讨论2022年1月4日 20:58 (UTC)[回复]
当我刚来美国时,我曾被拒绝进入酒吧和拒绝在酒类商店获得服务,因为我没有携带护照,当时我只有澳大利亚驾照。现在有了美国驾照,我可以用它作为年龄证明,但在拿到驾照之前,我的澳大利亚驾照是否被接受为年龄证明,结果好坏参半。我想这可能取决于州,因为我注意到在纽约我的澳大利亚身份证比在芝加哥更容易被接受。
在新加坡,他们对这个规定确实非常严格;外国签发的身份证卡通常不被接受,马来西亚身份证除外,有些商家会接受。如果你在新加坡工作或学习,你会获得工作许可证和学生证,可以作为你的身份证件,但如果你是游客,你必须携带护照。 The dog2讨论2022年1月4日 21:08 (UTC)[回复]
纽约有很多酒吧要求所有人都出示年龄证明,无论他们多大。任何想去酒吧的人都应该带上带照片的身份证件,以免被拒绝入内。 Ikan Kekek讨论2022年1月4日 21:09 (UTC)[回复]
LP,我知道有一家餐厅的标准是“白头发”。在那家餐厅,一位 50 岁的人可能需要出示 ID。(那家餐厅通常雇佣青少年做服务员,你可能不希望你的生意取决于一个 16 岁的人是否猜对了年龄。) WhatamIdoing讨论2022年1月5日 22:06 (UTC)[回复]
很久以前(大概是 2011 年?)。在亚特兰大,一家酒吧接受我的加拿大驾照作为年龄证明 ID。 OhanaUnited讨论页 2022年1月5日 22:41 (UTC)[回复]
我 56 岁了,在纽约经常需要出示 ID,尽管现在情况有所不同,因为你必须出示 ID 和疫苗接种证明(而且,出于安全原因,我几周没有进过酒吧了)。 Ikan Kekek讨论2022年1月5日 23:50 (UTC)[回复]
由于美国和加拿大之间的密切关系,加拿大驾照与其他外国驾照不同。同样,新西兰驾照在澳大利亚被认可的可能性也比其他外国驾照大。 The dog2讨论2022年1月7日 06:39 (UTC)[回复]

Wiki Loves Folklore 回归!

请帮助翻译成您的语言

您被诚挚地邀请参加 Wiki Loves Folklore 2022,这是一个在维基共享资源上组织的国际摄影比赛,旨在记录不同地区的民间传说和非物质文化遗产,包括民间创意活动等等。比赛每年于 2 月 1 日至 28 日举行。

您可以通过拍照、录音、录像和 提交 您的作品参与此共享资源竞赛,为您的地区丰富民间传说记录。

您还可以 组织一次本地竞赛,并帮助我们翻译 项目页面,以帮助我们用您的母语传播信息。

如果您需要任何帮助,请随时联系我们的 项目讨论页

此致,

Wiki Loves Folklore 国际团队

--MediaWiki message delivery讨论2022年1月9日 13:14 (UTC)[回复]

社区愿望清单调查 2022

2022年社区愿望清单调查现已开放!

本次调查是社区决定社区技术团队来年工作重点的过程。我们鼓励大家在1月23日截止日期前提交提案,或评论其他提案以帮助改进。社区将在1月28日至2月11日期间对提案进行投票。

社区技术团队专注于为有经验的维基媒体编辑者提供工具。您可以尝试用任何语言撰写提案,我们会为您翻译。谢谢,我们期待您的提案! SGrabarczuk (WMF) (讨论) 2022年1月10日 18:10 (UTC)[回复]

关于董事会选举的反馈意见征集现已开放

董事会选举的反馈意见征集现已开放,并将于2022年2月7日结束。

通过本次意见征集,运动策略和治理团队正在采取不同的方法。这种方法整合了社区在2021年的反馈。意见征集不是以提案为主导,而是围绕董事会提出的关键问题展开。这些关键问题源于对2021年董事会选举的反馈。目的是激发关于这些关键问题的集体对话和协作提案开发。

在本次意见征集中将提出两个已确认的问题

  1. 如何最有效地确保当选候选人拥有更多元的代表性?董事会注意到选拔代表维基媒体运动全部多样性的候选人的重要性。目前的流程偏向于北美和欧洲的志愿者。
  2. 对候选人在选举期间的期望是什么?董事会候选人传统上需要完成申请并回答社区提问。选举如何能提供对候选人的适当洞察,同时又能尊重候选人作为志愿者的身份?

还有其他一个可能在意见征集中提出的关于选拔流程的问题。这个问题仍在讨论中,但董事会希望尽快提供已确认问题的洞察。希望如果还有其他问题,将在意见征集的第一周准备就绪。

参与讨论。

顺颂,

运动策略与治理团队, Zuz (WMF) (讨论) 2022年1月11日 17:44 (UTC)[回复]

XTools编辑计数器选择加入

有一个名为XTools的有用工具,它可以显示您或其他人的编辑数据,例如您编辑最多的页面、每月编辑次数以及其他一些有趣的统计数据。它在很多方面都很有帮助,例如了解编辑者是活跃还是不活跃,查看某人是更专注于主空间还是项目空间,以及跟踪您编辑最多的文章的质量。

对于许多项目(包括大多数大型项目),所有XTools统计数据默认都已选择加入。然而,在Wikivoyage上,大多数统计数据都需要手动创建Special:MyPage/EditCounterOptIn.js,这使得它的用处大大降低。我们是否有兴趣让XTools在Wikivoyage上默认选择加入? Vaticidalprophet (讨论) 2022年1月8日 17:51 (UTC)[回复]

我更喜欢目前的系统,我认为它能更好地保护隐私。 --评论者 Selfie City (讨论) (贡献) 2022年1月8日 19:14 (UTC)[回复]
我个人没有强烈意见,但我认为,只要有人表达了隐私偏好,我们就应该尽可能支持。 WhatamIdoing (讨论) 2022年1月8日 22:20 (UTC)[回复]
我同意。想了解自己统计数据的人可以自行选择加入。了解他人的统计数据可能很有用,但我认为隐私问题更重要。我非常担心一个人能通过你在维基百科及其相关网站上的活动了解多少信息,但至少并非所有信息都能轻易获得。大多数人都不理解其中的问题,所以我们不能指望他们选择退出任何东西。 –LPfi (讨论) 2022年1月9日 12:50 (UTC)[回复]
我倾向于目前的系统。无论是主空间还是项目空间的编辑,都可以看到,只是要授权才能看到他们贡献最多的文章。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年1月13日 23:43 (UTC)[回复]
(一个月后),我现在支持@Vaticidalprophet的提议,因为我想知道某个编辑者在未注明出处的情况下内部复制了哪些文章(包括他们创建的页面和他们改进但未创建的页面)。我不会提及该编辑者的姓名,但我很乐意通过电子邮件告知。同样,还有另一位编辑者添加了数百个在错误文章中列出的条目——包括他们创建的页面以及他们改进过的页面。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年2月2日 10:55 (UTC)[回复]

与社区技术团队交流

你好

我们,负责社区愿望清单调查的团队,诚挚邀请您参加我们的一次在线会议。会议将于1月19日星期三),18:00 UTC在Zoom上举行,时长一小时。此外部系统不受WMF隐私政策的约束。点击此处加入

议程

  • 请携带您的提案草稿,与社区技术团队成员讨论您的改进提案的问题。

形式

会议不会录制或直播。会议记录将匿名公开在 Meta-Wiki 上。演示文稿(议程中除问答环节外的所有要点)将以英语进行。

我们可以用英语、法语、波兰语、西班牙语和德语回答问题。如果您想提前提问,请在社区愿望清单调查讨论页添加,或发送至sgrabarczuk@wikimedia.org。

会议将由社区技术经理Natalia Rodriguez主持。

邀请链接

期待您的到来! SGrabarczuk (WMF) (讨论) 2022年1月18日 00:21 (UTC)[回复]

订阅“教育月讯”——向他人学习并分享您的故事

尊敬的社区成员:

来自EWOC Newsletter团队和维基媒体基金会教育团队的问候。我们非常高兴地宣布,我们迎来了“教育月讯”(This Month in Education)的十周年。我们邀请您通过在您的讨论页订阅该月讯在接下来的月讯中分享您的活动来加入我们。维基媒体教育月讯是一份月度通讯,收集来自世界各地在教育中使用维基媒体项目内容的社区成员撰写的文章,由EWOC Newsletter团队与教育团队合作发布。这些故事可以为您带来新的尝试想法,并提供关于我们社区成员在其环境中运行教育项目的成功和挑战的宝贵见解。

如果您的联盟/语言项目正在发展自己的教育计划,请记住利用此月讯与更广泛的、对教育充满热情的运动分享您的故事。您可以提交您自己语言的月讯文章,或为教育月讯提交双语文章。一月份提交文章的截止日期是1月20日。我们期待阅读您的故事。

此月讯的旧版本可在完整档案中找到。

有关该月讯的更多信息,请访问Education/Newsletter/About

如需更多信息,请联系spatnaikwikimedia.org。


关于《教育月讯》 · 订阅/退订 · 全球消息传递 · 团队:ZI Jony (讨论)2025年11月9日星期日 22:00 (UTC)

运动策略与治理新闻 – 第5期

运动策略与治理新闻
第5期,2022年1月阅读完整新闻


欢迎阅读第五期《运动策略与治理新闻》(前身为《通用行为准则新闻》)!改版后的新闻通讯将分发有关运动章程、通用行为准则、运动策略实施补助金、董事会选举和其他相关MSG主题的新闻和活动。


本通讯将按季度分发,而更频繁的更新也将每周或每两周发送给订阅者。如果您想接收这些更新,请在此订阅

  • 关于董事会选举的意见征集 - 我们邀请您就即将举行的WMF董事会选举提供反馈。此次意见征集于2022年1月10日上线,并将于2022年2月7日结束。(继续阅读
  • 通用行为准则批准 - 2021年,WMF就如何执行《通用行为准则》政策文本征求了社区意见。修订后的执行指南草案应于3月提交社区投票。(继续阅读
  • 运动策略实施补助金 - 随着我们继续审查几项有趣的提案,我们鼓励并欢迎更多旨在实现运动策略建议中特定举措的提案和想法。(继续阅读
  • 新闻通讯的新方向 - 随着UCoC新闻通讯过渡到MSG新闻通讯,请加入促进团队,设想并决定这个新闻通讯的新方向。(继续阅读
  • Diff博客 - 查看维基媒体Diff上关于MSG的最新出版物。(继续阅读

Zuz (WMF) (讨论) 2022年1月20日 08:21 (UTC)[回复]

Wikivoyage的影响

如果您对设计感兴趣,我鼓励您花点时间看看苏丹维基百科的主页。在我看来,他们似乎采用了Wikivoyage的轮播系统。 WhatamIdoing (讨论) 2022年1月21日 16:51 (UTC)[回复]

这真的很有趣。我一直觉得英文Wikivoyage比英文维基百科做得更好的一点是,它的主页更现代化、更好看。目前的英文维基百科主页设计于2006年3月,在互联网时代已经是非常久远了。 Gizza (roam) 2022年1月22日 03:48 (UTC)[回复]
英文Wikibooks的主页看起来像是很久以前设计的,比维基百科的还要老气。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年1月22日 03:51 (UTC)[回复]
题外话,但说到首页设计,w:nv: 有彩虹渐变,我一直很喜欢,即使可能不是每个人都喜欢。 —Justin (koavf)TCM 2022年1月23日 10:19 (UTC)[回复]
w:se:(萨米语)进行了专业重新设计,并融入了具有文化相关性的元素。 WhatamIdoing (讨论) 2022年1月23日 21:31 (UTC)[回复]
这很有趣,因为它看起来具有响应式设计,而我在任何维基上都没有见过。 —Justin (koavf)TCM 2022年1月23日 21:42 (UTC)[回复]

桌面改进更新与办公时间邀请

大家好。我想给大家更新一下桌面改进项目,该项目是维基媒体基金会Web团队在过去几年里一直在进行的。

该项目的目标是让界面对读者更加友好和舒适,对高级用户更加有用。该项目包含一系列功能改进,使得阅读和学习、页面内导航、搜索、语言切换、使用文章标签和用户菜单等更加容易。

对读者和编辑者来说,改进已在24个维基上默认可见,包括法语葡萄牙语波斯语维基百科。

这些更改仅适用于Vector皮肤。 MonobookTimeless用户不受影响。

自上次更新以来部署的功能

  • 用户菜单 - 侧重于通过视觉突出用户链接的结构和目的,使导航更加直观。
  • 固定页眉 - 侧重于允许访问重要功能(登录/登出、历史记录、讨论页等),而无需用户滚动到页面顶部。

有关该项目包含功能的完整列表,请访问我们的项目页面。我们也邀请您访问我们的更新页面

已部署的功能和当前正在开发的目录


如何启用改进

全局偏好设置
  • 可以在偏好设置的“外观”标签页中单独选择加入,通过取消选中“使用旧版Vector”框。(它必须为空。)此外,还可以使用全局偏好设置在所有维基上选择加入。
  • 如果您认为这对本维基的所有读者和编辑者来说都是一个很好的默认设置,请随时与社区展开对话并与我联系。
  • 在对所有人可见更改的维基上,已登录用户始终可以选择退出旧版Vector。新Vector的侧边栏中有一个易于访问的链接。

了解更多并参加我们的活动

如果您想关注我们项目的进展,可以订阅我们的通讯

您可以阅读项目页面,查看我们的常见问题解答,在项目讨论页发表意见,并参加我们的在线会议(1月27日星期四),15:00 UTC)。

如何加入我们的在线会议

谢谢!!

代表维基媒体基金会Web团队, SGrabarczuk (WMF) (讨论) 2022年1月24日 22:11 (UTC)[回复]

关于通用行为准则执行指南审查的最新动态

大家好,


通用行为准则(UCoC)执行指南》已于2022年1月24日发布,作为在整个运动中应用通用行为准则的拟议方式。有关指南的评论可以在这里分享,或在Meta-wiki讨论页上分享。

将于2022年2月4日15:00 UTC、2022年2月25日12:00 UTC和2022年3月4日15:00 UTC在Zoom上进行讨论。加入UCoC项目团队和起草委员会成员,讨论指南和投票流程

时间表可在Meta-wiki上找到。投票期为3月7日至21日。查看投票信息页了解更多详情

您可以在此处阅读完整公告。感谢所有迄今为止参与的人。


诚挚地,

运动策略与治理
维基媒体基金会

Zuz (WMF) (讨论) 2022年2月4日 09:36 (UTC)[回复]

机场文章的脚本错误

新年快乐。从布里斯班往下,信息被替换为脚本错误,显示红字:“脚本运行时间已超时。” 有人知道是什么原因以及如何修复吗? --ThunderingTyphoons! (讨论) 2022年1月11日 11:51 (UTC)[回复]

这似乎是一个Lua问题,一个页面上有太多模块。你知道它以前能用吗?是否添加了很多新条目?这个页面上使用的模板是否被更改,导致它调用了多个模块? —Justin (koavf)TCM 2022年1月11日 11:57 (UTC)[回复]
谢谢 Justin。按顺序回答您的问题:是的,没有(都确定)。我不知道。--ThunderingTyphoons! (讨论) 2022年1月11日 11:59 (UTC)[回复]
嗯。奇怪的是它刚开始就停止了。作为一个对模块不太了解的人,我建议快速修复的方法是将文章按大陆分开,并在phab:提交一个工单。比我聪明的人可能知道更多(但这总是对一切都适用的:/)。 —Justin (koavf)TCM 2022年1月11日 12:01 (UTC)[回复]
现在对我来说可以用了。也许是由于临时的负载问题导致处理器时间测量溢出(或更改了限制)?无论如何,最好不要触及极限。Wikivoyage在处理方面相当繁重;有没有办法优化列表模板,或者其他方法可以避免某些页面变得非常耗费处理资源? –LPfi (讨论) 2022年1月11日 13:33 (UTC)[回复]
对我来说也工作正常。如果这个问题成为一个反复出现的问题,我们可以提交一个Phabricator工单。我认为在需要拆分文章(无论是使用不同的颜色标记还是单独的子文章)之前,我们还有14个机场左右。--ThunderingTyphoons! (讨论) 2022年1月11日 15:03 (UTC)[回复]
听起来像是PEIS限制,如果有人好奇的话。我之前也问过,但没找到任何能完全理解开发人员如何决定限制的人。解决方法很简单:拆分大型页面,优化模板。 WhatamIdoing (讨论) 2022年1月11日 16:32 (UTC)[回复]
大部分时间用于获取Wikidata数据集,您可以在HTML代码中了解到。它包含一个NewPP limit report。获取实体大约需要6秒,这是一个巨大的值,可能是由于复杂的机场数据集(并且由于软件添加而随时间增加)。Lua总计算时间接近10秒限制,也就是说,有时它能工作,有时不能。我将英文Wikivoyage的一个副本放在了德语Wikivoyage上,地址是de:Benutzer:RolandUnger/Flughäfen。它证实了获取实体所需的巨大计算时间。但它也显示列表脚本可以优化,因为它总共只花了8秒计算时间,比英文Wikivoyage少2秒。这个更短的计算时间可以防止任何Lua时间错误。
在正常情况下,在地点文章中可以获取最多250个不同的Wikidata数据集,正如您从de:Halle (Saale)中可以看到的。当然,Scribunto_LuaSandboxCallback::getEntityScribunto_LuaSandboxCallback::callParserFunction的计算时间应该减少。有时我会在phabricator上报告bug,但只进行了微小的修复。 --RolandUnger (讨论) 2022年1月11日 16:46 (UTC)[回复]

由于我们很难对内存进行根本性的更改,并且依赖于开发人员,我建议我们提前拆分此文章。我们可以在本地控制页面上的模板和脚本数量,因此我们应该留意可能导致失败的页面。 —Justin (koavf)TCM 2022年1月11日 18:27 (UTC)[回复]

而且,现在纽约市附近也出现了故障。 —Justin (koavf)TCM 2022年1月11日 18:32 (UTC)[回复]
能有人再检查一下这个文章吗? -- Matroc (讨论) 2022年1月12日 04:07 (UTC)[回复]
算了——我重新发布了文章,没有任何更改,可以看到文章。重新加载页面后又出现错误。如果 ?action=purge(清除文章),可以显示页面——这让我认为内存也是一个问题…… -- Matroc (讨论) 2022年1月12日 04:15 (UTC)[回复]
  • 我们可以从该文章中移除Wikidata调用,而不会造成太大损害。列出的每个机场都有一个指向其Wikivoyage文章的维基链接,因此Wikidata和维基百科图标并非真正必需。我们不妨鼓励读者点击内部链接,阅读我们的文章,而不是访问维基百科或Wikidata。 —Granger (讨论 · 贡献) 2022年1月12日 19:52 (UTC)[回复]
请查看机场文章/沙盒。这篇文章基于Module:Marker (目前通过Template:Listing/sandboxTemplate:Marker/sandbox,而不是Module:Map
如果您比较机场文章与机场文章/沙盒的LUA配置文件,您会发现前者下载了85个Wikidata实例,而后者为零。这就是为什么加载时间大大缩短的原因。为了正确比较加载时间,您应该清除文章缓存,同时打开以下两个链接
  1. https://wikivoyage.cn/w/index.php?title=Airport_articles&action=purge
  2. https://wikivoyage.cn/w/index.php?title=Airport_articles/Sandbox&action=purge
如果有共识朝着这个方向发展,我将完成新的模块,以便在坐标缺失时检索坐标,但是请注意,任何时候坐标都会从Wikidata下载(因为它们没有明确写在列表模板中),这仍然会影响性能(比今天少,但仍然有影响)。 --Andyrom75 (讨论) 2022年1月18日 14:10 (UTC)[回复]
JustinThunderingTyphoons!LPfiWhatamIdoingMatrocGranger:你们的反馈在
  1. 使用当前模板(坐标 -以及潜在的其他信息 - 无论在维基代码中写了什么,都会从Wikidata下载)
  2. 使用新的模块(不从Wikidata下载坐标)
  3. 使用新的修订模块(仅当列表模板中未提供坐标时,才会从Wikidata下载坐标)。
请告知,我将相应地进行操作, --Andyrom75 (讨论) 2022年1月19日 08:41 (UTC)[回复]
我认为#3应该没问题,特别是如果有一个机器人每[x]天从Wikidata检查坐标并导入它们。 —Justin (koavf)TCM 08:43, 19 January 2022 (UTC)[回复]
和Justin一样。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 08:49, 19 January 2022 (UTC)[回复]
我乐意接受任何可行的方案。--ThunderingTyphoons! (讨论) 10:09, 19 January 2022 (UTC)[回复]
如果#3易于实施且不太重,我认为那是理想的解决方案。我们应该将大部分坐标复制到列表——最迟在模板到期时——但仍将不时有新的列表,并且它们不总是列出坐标。机器人导入坐标会很好,但我认为新机场文章的创建频率很低,如果养成习惯或者在列表缺少坐标太多时被提醒,都可以手动处理。–LPfi (讨论) 10:37, 19 January 2022 (UTC)[回复]
我更喜欢#3,不使用机器人。有时我不想使用Wikidata的坐标(例如,当我想用入口的坐标,但它们需要景点中心的坐标)。 WhatamIdoing (讨论) 16:22, 19 January 2022 (UTC)[回复]
我更喜欢#3,并带有机器人,机器人仅在文章中缺少坐标时才下载坐标。有时我们的坐标与WD明显不同,像河流这样的巨大特征的列表是一个极端例子。
在其他文章中,在文章中包含坐标的另一个好处是,这会在全屏地图上显示标记(来自目的地文章右上角的图标)。Wikidata坐标不会在全屏地图上显示。 AlasdairW (讨论) 23:19, 19 January 2022 (UTC)[回复]
我刚刚更新了模块,现在如果列表项中不存在坐标,它会从Wikidata检索坐标。
文章中的效果(有80个带有坐标的列表项,5个没有)是,现在只查询5个Wikidata实体以获取坐标。正如预期的那样,这会导致加载时间增加,由于有太多因素影响它,很难估算(这就是为什么有时原始文章完美渲染,有时在底部出现LUA错误),但大致来说,我认为至少增加1秒。
在投入“生产”之前,您可以随意使用“Template:Listing/sandbox”而不是“Template:Listing”进行一些测试,并在您确信可以切换时告知我。
投入生产后,我们应该监控此类别,以确保没有其他文章会汇聚到这里。该类别中的任何页面都需要修复。附注:那里已经有几篇文章了... --Andyrom75 (讨论) 17:21, 19 January 2022 (UTC)[回复]
我已经清理了所有“Pages_with_script_errors”。剩下的两个是出于不同原因。
  • User:Buzzy:使用291个标记,带有291个Wikidata参数但无坐标;使用该模块并添加坐标将解决问题。
  • User:Pbsouthwood/Dive_sites:使用553个标记;太多了。我猜唯一的解决办法是将页面分成两个或多个子页面。
--Andyrom75 (讨论) 23:42, 19 January 2022 (UTC)[回复]
在没有进一步反馈的情况下,我大胆地将新修订的模块投入生产。如果您注意到任何问题,请及时指出(并@我)。正如预期的那样,User:Buzzy页面已自动修复,尽管它需要近8秒来处理代码(非常接近10秒的限制)。另一页将像之前解释的那样随机失败。 --Andyrom75 (讨论) 20:02, 20 January 2022 (UTC)[回复]
我认为#3是一个可行的解决方案。
  • 考虑更改编辑器,以便在需要时自动从Wikidata提供缺失的纬度/经度坐标。(将小数点右边的数字最多截断到6位)。否则手动输入纬度/经度?
  • 机场文章很快就会达到臭名昭著的99个限制。也许使用彩色标记来避免编号问题?
  • 地图 - 也许使用分组和显示。1张主地图用于所有(带有图例指向每个区域)- 分组的单独地图,例如非洲、亚洲等。或者一个页面链接到主地图,以感兴趣的区域为中心。这也可以减少地图构建成本。如果时间允许,我会尝试做一个例子。-- Matroc (讨论) 06:07, 21 January 2022 (UTC)[回复]
  • 我制作的示例 - 如果您感兴趣,这个示例将保留几天 - 示例 -- Matroc (讨论) 18:50, 21 January 2022 (UTC)[回复]
Matroc,如果你在第一点中谈论的是列表编辑器,我可以告诉你,Wikidata同步是可能的,但应由用户明确请求(不是自动的),并且关于坐标,它已经将数字四舍五入到小数点后6位。 --Andyrom75 (讨论) 17:22, 21 January 2022 (UTC)[回复]
太好了!谢谢你的意见!-- Matroc (讨论) 18:50, 21 January 2022 (UTC)[回复]

图片参数不再有效

在像{{see ..., image=name.jpg, ...}}这样的列表中,图片在地图框地图上不再显示。--FredTC (讨论) 06:57, 21 January 2022 (UTC)[回复]

我今天在塔斯马尼亚国家公园注意到了这一点。我只是忽略了它,因为我认为这是一个单一文章的问题,并且下面已经列出了图片,但似乎是全站范围都出现了。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 07:00, 21 January 2022 (UTC)[回复]
@Andyrom75: 需要再次/更好地测试他的更改{{Marker}}。更改前的版本运行正常。 -- andree 07:13, 21 January 2022 (UTC)[回复]
FredTCSHB2000,正如andree所说,我确认我需要处理这个问题。目前我专注于坐标。抱歉带来暂时的不便。
只有一件事。通过“name”参数传递图片相对容易,并且不会影响性能,但是从Wikidata下载图片可能会影响页面加载时间(请参阅上面关于坐标的讨论,社区决定采用解决方案#3)。
我可以采取相同的方法,但让我们记住附带影响。--Andyrom75 (讨论) 09:37, 21 January 2022 (UTC)[回复]
好的,当然。哪个有效的我都可以。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 09:39, 21 January 2022 (UTC)[回复]
FredTCSHB2000,现在手动输入的图片已显示在地图上。要使用Wikidata的图片,我想听取更多反馈。虽然我注意到module:map已经这样做了,所以我认为性能不会变得更糟。--Andyrom75 (讨论) 10:21, 21 January 2022 (UTC)[回复]
除非运行一个机器人定期将WD同步到WV文章,否则我们无法排除从WD获取图片,这需要非平凡的逻辑来避免覆盖手动输入的图片……在我看来,如果一个页面出现超时错误,就该将其拆分或优化软件/增加限制。但这个特定的功能是我个人最喜欢的标记功能,我非常非常强烈反对删除它! ;-) -- andree 11:46, 21 January 2022 (UTC)[回复]
Andree,刚刚实现了Wikidata图片检索。性能影响约为10%(显然取决于需要此服务的列表/标记的数量)。User:Buzzy页面重新进入Category:Pages with script errors :-( 让我们监控该类别,以确保没有其他文章会流向那里。 --Andyrom75 (讨论) 17:17, 21 January 2022 (UTC)[回复]
目前地图标记的“鼠标悬停”事件没有图像指示。--FredTC (讨论) 11:01, 21 January 2022 (UTC)[回复]
FredTC,我不确定我是否理解您的意思。您能告诉我您在看哪个文章和哪个列表/标记吗?--Andyrom75 (讨论) 11:42, 21 January 2022 (UTC)[回复]
受影响的文章需要刷新(例如,进行一次编辑+不更改任何内容+按“发布”),可能需要一些时间才能自动完成。 -- andree 11:51, 21 January 2022 (UTC)[回复]
我在罗马南部尝试了一下。左侧的see-22有一个图像,附近的see-19没有图像。“鼠标悬停”信息没有显示差异;只有当你点击标记时,你才会得到图片(22)或文本变粗(19)。我对文章做了一些改动,但这并没有改变“鼠标悬停”行为。--FredTC (讨论) 12:19, 21 January 2022 (UTC)[回复]
嗯,我甚至无法用旧的标记模板获得鼠标悬停(但问题也可能是我的设置,或者有其他地方发生了变化……无论如何,我从未使用过这个,只是点击过地图上的标记)。既然我们谈到了,外部链接在标记中也没有被突出显示。-- andree 12:31, 21 January 2022 (UTC)[回复]
FredTC,老实说,我不记得地图上有过这样的行为。当您将鼠标悬停在文本中的蓝色维基链接上并激活了“导航弹出窗口”小工具时,会发生类似的行为。但是,这是由地图扩展服务器端管理的,因此我们不应该能够从客户端更改它。--Andyrom75 (讨论) 16:20, 21 January 2022 (UTC)[回复]

列表和标记上的维基百科图标

西南国家公园塔斯马尼亚国家公园,我注意到维基百科图标变了。有原因吗?我更喜欢旧的。--SHB2000 (讨论 | 贡献 | meta.wikimedia) 07:21, 21 January 2022 (UTC)[回复]

似乎是由于上述原因…… -- andree 07:40, 21 January 2022 (UTC)[回复]
@Andyrom75:? SHB2000 (讨论 | 贡献 | meta.wikimedia) 07:42, 21 January 2022 (UTC)[回复]
SHB2000,已修复。我忘了en:voy图标与it:voy图标不同。--Andyrom75 (讨论) 08:37, 21 January 2022 (UTC)[回复]
感谢修复:-) SHB2000 (讨论 | 贡献 | meta.wikimedia) 08:39, 21 January 2022 (UTC)[回复]

NA 创建坐标在0,0

根据template:see,当NA添加到see列表时,它不应创建标记,但如果您查看瑞典帝国“Skattkammaren”,它具有NA的坐标,在0,0处有一个标记,而实际上不应有标记。如何修复? Tai123.123 (讨论) 01:58, 22 January 2022 (UTC)[回复]

@Andyrom75:,你是不是不小心做了什么?优胜美地国家公园是另一个坐标集中在0,0的例子。
我只想说完全省略坐标。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 02:00, 22 January 2022 (UTC)[回复]
Tai123.123SHB2000,我可以修复它,但我想知道为什么在纬度/经度参数为空时插入“NA”? --Andyrom75 (讨论) 08:15, 22 January 2022 (UTC)[回复]
不确定。我通常只是留空,但出于某种原因,许多文章都使用“NA”。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 08:16, 22 January 2022 (UTC)[回复]
Andree,鉴于您过去曾处理过Template:MarkerModule:Map,也许您可以告诉我为什么采用“NA”坐标方法而不是留空。这个问题可以通过两种方式解决:恢复“NA”方法或机器人清理“NA”出现。在it:voy,我们从不使用“NA”,这里大约有250篇文章使用它,检查其中一些文章,我倾向于认为这是一个错误用法,但这只是我的观点。--Andyrom75 (讨论) 08:25, 22 January 2022 (UTC)[回复]
原因在于,有时列表在Wikidata中有坐标,但我们实际上不需要这些坐标。大多数是像节庆活动这样的东西,它们有(更糟的是,如果每年都在不同的地方举行)举办城市的坐标——但我们不需要。所以这里的人们决定使用NA来强制删除列表中的坐标,即使它们在WD中有。 :) -- andree 08:51, 22 January 2022 (UTC)[回复]
Andree,抱歉迟回复,但我周六出去玩了,天气很好 :-P
我认为如果节庆活动地点发生变化,应该像价格、开放时间等信息一样定期更新。我仍然不明白为什么需要这些“NA”坐标。您认为值得重新讨论吗?--Andyrom75 (讨论) 19:19, 22 January 2022 (UTC)[回复]
在某些情况下需要讨论,但我认为不应该总是有标记。我遇到的典型例子是,节庆活动(或任何其他活动)在一个已经列出的地点举行。我认为在方向参数中指向该地点比放置两个重叠的标记要好。–LPfi (讨论) 20:29, 22 January 2022 (UTC)[回复]
如果它是一个列表,并且您指定了WD,它会自动变成一个标记…… -- andree 20:34, 22 January 2022 (UTC)[回复]
NA 的存在不正是为了避免这种情况吗?–LPfi (讨论) 20:38, 22 January 2022 (UTC)[回复]
是的…… -- andree 21:57, 22 January 2022 (UTC)[回复]
阳光明媚的星期六?我不知道你在说什么——今天一整天都在下雨、下雪、刮风! :-D
请查看Template_talk:Marker#Coordinates being created without being manually setTemplate_talk:Marker#Wikidata lat/longs。可能还有其他讨论,但底线是WD和WV有不同的目标。所以WD的坐标可能对WV没有兴趣,但对维基百科或某些数据挖掘可能很有趣。IMO,有时只选择我们需要的WD数据没有“耻辱”,所以NA对我来说是可以的(但最终,我从来没有使用过它,也不特别关心)。而且最重要的是,我真的不想参与重新讨论这个话题——既然你碰了这个东西,打开了潘多拉的盒子,你就要自己去论证…… :-P -- andree 20:33, 22 January 2022 (UTC)[回复]
Andree,很遗憾听到这个消息,所以我想我还是不要告诉你我光着脚在海边散步……一月份在这里也有些不寻常,但为什么不呢 :-P
回到正题。
在你链接的讨论中,我发现了以下几点
  • 列表可能链接到错误的Wikidata实体(例如,组织活动的协会而不是活动本身),因此我认为应该删除Wikidata参数。
  • Wikidata上的信息是错误的(不仅是坐标),因此我认为应该更新/更正Wikidata信息,以便为所有使用Wikidata的WMF项目提供此好处 — 但请记住,WD信息只是在本地信息缺失时的备用方案。
LPfi,如果我正确理解了您的观点,您描述的是两个或多个列表具有相同位置的情况。如果是这样,我认为这是可以的。让我们想想亚洲商店,它们位于同一栋建筑的不同楼层,或者西方的购物中心,里面有不同的餐馆。
尽管如此,如果社区对重新建立“NA”功能有真正的共识,我会这样做的,尽管我认为这不是一个好主意。--Andyrom75 (讨论) 09:29, 23 January 2022 (UTC)[回复]
在亚洲大都市,商店、餐馆等在同一栋楼的不同楼层是很常见的(不是购物中心,只是一个N楼的商业建筑),而且由于所有这些都得到了广告宣传(通常是当地语言),所以很难弄清楚要去哪里 :-D
在我看来,节日活动类似于一个大型机场。让我们考虑一下JFK或CDG。我们有参考坐标来“在世界上”定位它,然后如果我们想指出特定事物(例如,航站楼、租车处、停车场、商店等),我们仍然可以使用通常与Wikidata无关的标记。
话虽如此,我仍然不赞成“NA”功能,但我会遵循社区的意愿。--LPfi (讨论) 09:59, 23 January 2022 (UTC)[回复]
LPfi,在亚洲大都市,商店、餐馆等在同一栋楼的不同楼层是很常见的(不是购物中心,只是一个N楼的商业建筑),而且由于所有这些都得到了广告宣传(通常是当地语言),所以很难弄清楚要去哪里 :-D
在我看来,节庆活动类似于一个大型机场。让我们考虑一下JFK或CDG。我们有参考坐标来定位它“在世界上”,然后如果我们想指出特定事物(例如,航站楼、租车处、停车场、商店等),我们仍然可以使用通常与Wikidata无关的标记。
话虽如此,我仍然不赞成“NA”功能,但我会遵循社区的意愿。--Andyrom75 (讨论) 10:35, 23 January 2022 (UTC)[回复]
如果坐标在特定情况下有用,当然应该包含它们,就像我说的关于相邻商店一样。NA在标记弊大于利的情况下很有用,我见过它在几种情况下都很有用,所以我认为它应该可用。再举一个例子:对于搬迁的节庆活动,你说坐标应该被更新。是的,它们应该。但明年的地点可能在某个我无法轻易找到坐标的地方(比如网站上用一个我不知道的本地术语命名的地点),删除去年的误导性坐标,我只会从WD获得总部地址,而在另一个城镇。–LPfi (讨论) 10:54, 23 January 2022 (UTC)[回复]
NA 有用的一个案例是Wikidata的纬度/经度是一个不对游客开放的办公室。节庆活动可能从游客中心售票,但“设在”一个工业区,因为他们将设备存放在那里。WP仍然想要工业区的办公室地址。
另一个例子是英格兰#保护信托,其中英格兰遗产委员会拥有办公室的纬度/经度,但旅行者对他们管理的城堡等感兴趣,不应该试图访问办公室。 AlasdairW (讨论) 10:59, 23 January 2022 (UTC)[回复]
LPfiAlasdairW,依我看,如果一个节庆活动的实体坐标是组织节庆活动的协会的坐标,那么这个坐标就是错误的,应该从这里移到协会实体(如果存在的话)。
不过,在此期间,我将努力恢复此功能,但我仍然希望社区的决定会走向另一个方向 :-) --Andyrom75 (讨论) 14:53, 23 January 2022 (UTC)[回复]
我只是想加入合唱——我认为NA功能对于上述情况很重要。感谢您为此所做的工作,Andyrom75。—Granger (讨论 · 贡献) 15:16, 23 January 2022 (UTC)[回复]
我也支持NA,过去在某些情况下使用过它,例如当多个兴趣点位于大致相同的坐标时。 --评论来自 Selfie City (讨论) (贡献) 18:47, 23 January 2022 (UTC)[回复]
我已经恢复了NA功能。请检查并告知我。--Andyrom75 (讨论) 23:24, 23 January 2022 (UTC)[回复]
现在好了,谢谢 Tai123.123 (讨论) 23:30, 23 January 2022 (UTC)[回复]
@Andyrom75:。有些文章使用N/A。是否很难让该变体也能工作,或者我们应该搜索这类文章?我没见过n/a,但根据Wiktionary,这是正确的拼写,所以也可能需要检查一下。–LPfi (讨论) 12:07, 25 February 2022 (UTC)[回复]
LPfi,我建议使用一种方法来避免使用Wikidata。这种方法将写入模板手册,并且已经使用“NA”的文章将是其工作方式的清晰示例。因此,我建议查找并替换所有其他类似情况。--Andyrom75 (讨论) 13:14, 25 February 2022 (UTC)[回复]
搜索 insource:"lat=N/A" 只返回了一篇文章。我之前已经处理了几篇。这是查找它们的方法,还是我可能遗漏了一些?(我也尝试了n/a和等号周围的空格)。 LPfi (讨论) 13:53, 25 February 2022 (UTC)[回复]
我认为已经全部改好了。--Andyrom75 (讨论) 14:43, 25 February 2022 (UTC)[回复]
好的,谢谢。 –LPfi (讨论) 2022年2月25日 18:38 (UTC)[回复]

Helsinki/Central 上元素未显示

Helsinki/Central 上的地图有问题。页面加载时,地图最初会显示文章中所有元素的所在地,但随后它们会立即消失,并且无法恢复。可以通过点击文章文本中的元素来单独查看,但无法在地图上一次性查看所有元素。Helsinki 的其他子页面上的地图似乎都可以正常工作,只有 Central 页面有问题。是什么原因造成的? JIP (讨论) 2022年1月23日 19:33 (UTC)[回复]

其他文章中的地图也存在同样的问题。/Yvwv (讨论) 2022年1月23日 19:44 (UTC)[回复]

我今天编辑了几个页面 FavershamSittingbourne,它们在我的电脑和手机上都显示了地图框架元素。--RobThinks (讨论) 2022年1月23日 20:37 (UTC)[回复]

现在问题似乎已经消失了。 Helsinki/CentralFavershamSittingbourne 上的地图元素现在工作正常。 JIP (讨论) 2022年1月23日 23:38 (UTC)[回复]
JIP,抱歉昨天(近两小时)的暂时不便,但我之前在处理前一个话题。正如你所见,在你最后一条帖子前10分钟,我已经解决了。--Andyrom75 (讨论) 2022年1月24日 09:20 (UTC)[回复]

借助新的模块,我抓住了机会对所有至少有一个标记/列表的文章进行了分类,这些文章包含冲突信息,因此存在外部链接(url参数)且名称为维基链接而非纯文本(name参数)。

在这种情况下,我只是忽略了url参数,等待任何志愿者来修复。

但是,我想知道这个选择是否适合社区,或者是否有不同的处理这些情况的意见。--Andyrom75 (讨论) 2022年1月24日 14:39 (UTC)[回复]

我刚看到 Denver 在这个类别里,因为它在丹佛国际机场的列表名称中有一个维基链接。我不认为这是一个问题,但其他人可能不同意。 AlasdairW (讨论) 2022年1月24日 23:15 (UTC)[回复]
AlasdairW,关于丹佛,你可以比较以下几点:
--Andyrom75 (讨论) 2022年1月25日 12:08 (UTC)[回复]
谢谢。我已经移除了维基链接。我认识到这是保持一致性的最佳方法。但是,在机场有专门文章的特殊情况下,我仍然不完全确定这对读者来说是否最有帮助。现在外部链接比内部链接更显眼。当维基链接存在时,仍然可以通过点击维基链接旁边的图标来访问外部链接。 AlasdairW (讨论) 2022年1月26日 22:28 (UTC)[回复]
SHB2000 撤销了对丹佛的编辑,并可能希望在此发表评论。
更有力的论据表明维基链接在列表名称中是可以的,例如Castles。这里有几个城堡的名称中包含维基链接。在这种情况下,城堡没有外部链接,说“纽伦堡城堡,纽伦堡”而不是“纽伦堡城堡”似乎过于冗长。 AlasdairW (讨论) 2022年1月26日 23:08 (UTC)[回复]
我的想法是,如果我们有该兴趣点的链接,那么我们就不需要包含外部链接——外部链接应该放在所链接的文章中。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年1月26日 23:25 (UTC)[回复]
AlasdairW, SHB2000,在 it:voy 上,正如你们所见,例如在 it:Aeroporti in Italia,我采用了不同的方法,出发点是假设最初列表名称中不应包含维基链接(因此我们通常会删除这些维基链接)。
基本上,如果 it:voy 上存在与提供的 Wikidata 参数关联的文章,模板会自动显示带有相关维基链接的 Wikivoyage 图标,这样名称就可以自由地容纳 URL。
您认为这种方法是否也适用于 en:voy?--Andyrom75 (讨论) 2022年1月27日 15:22 (UTC)[回复]
通常情况下,如果我们有一个文章要链接,我们就会链接它,而外部链接应该在相关文章中找到。我主要在内部链接是红链时使用内部和外部链接。–LPfi (讨论) 2022年1月28日 08:37 (UTC)[回复]
同LPfi。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年1月28日 08:40 (UTC)[回复]

去年页面浏览量

全站页面浏览量去年显示了一个奇怪的模式。我们有两个大的高峰。第一个高峰,然而,并没有与独立设备数的高峰相关(第二个高峰则相关)。

为了看得更清楚,在图表中点击“从零开始”选项可能会有帮助。 WhatamIdoing (讨论) 2022年2月5日 04:01 (UTC)[回复]

二月和三月的第一高峰与 2018 年 2 月的高峰相似。对我们许多人来说,那是在接近封锁期间,因此很可能是由 armchair travellers 引起的,这与八月第二个高峰不同,那时旅行对许多人来说更容易。从 2020 年 5 月开始,平均每月页面浏览量约为之前月份的三分之二。其他语言的趋势也有一些相似之处。
查看个别文章,《八十天环游世界》 的受欢迎程度从九月份的第 65 位上升到上个月的第 4 位。一部非常宽松地改编自该书的 BBC 电视连续剧于十二月下旬开始播出,这显然导致了这一现象。 AlasdairW (讨论) 2022年2月6日 00:42 (UTC)[回复]

大家好,能否有人指点一下文章下显示的“相关页面”链接的解释在哪里?谢谢, Peter (Southwood) (讨论): 2022年2月6日 13:07 (UTC)[回复]

Template:Confused 应被包裹在 noexcerpt span 中

根据我在 Wikimedia 支持台提出的问题TheDJ 解释说问题是由 Template:Confused 未被包裹在 <span class="noexcerpt"> ... </span> 中引起的。我建议我们这样做,因为它对读者/编辑来说几乎没有成本,并且可以提高与 Wikimedia API 的兼容性。(其他模板,例如 Template:Other uses,已经被包裹了。)

我似乎有权限自己做这件事,而且看起来很简单,但我不太想这样做,因为我在编辑 Wikimedia 模板方面没有任何经验,而且我不知道它们的潜在问题。如果我们同意应该这样做,我希望有经验更丰富的人来完成这项更改。 Brycehughes (讨论) 2022年2月15日 13:52 (UTC)[回复]

这似乎是显而易见的,所以我进行了更改。如果有人发现任何问题,请检查或撤销。在 bug 讨论中,也推荐了“role=note”,但我不太确定那是什么作用,所以没有添加。–LPfi (讨论) 2022年2月15日 14:11 (UTC)[回复]
谢谢。奇怪的是,API 调用的“extract”值现在只是一个 \n 字符。我大声地想……你做的更改会这么快地传播到 API 吗?该死的,我应该在发帖之前立即测试的。我想我会给它几天时间再试一次,如果它仍然很奇怪,我会在别的地方跟进。 Brycehughes (讨论) 2022年2月15日 14:26 (UTC)[回复]
我把图片移出了文章,以防万一它引起任何奇怪的问题。看看会发生什么。 Brycehughes (讨论) 2022年2月15日 14:40 (UTC)[回复]
我首先尝试将所有内容包含在 <span></span> 中,但这导致了 ":" 失效。似乎它使用的是第一段,而 ":" 行被解释为第一行。 Extension:TextExtracts 没有说明如何绕过这个问题。添加一个空行?但 span 不应该跨越段落。HTML 的 "?" ?–LPfi (讨论) 2022年2月15日 15:17 (UTC)[回复]
你认为 ":" 是 TheDJ 在回应的后半部分提到的内容吗?我认为他可能是在说我们不应该使用 ":" 进行缩进,而应该使用他建议的 CSS 样式——这可能会一举两得,但也似乎与我们使用 ":" 处理模板中的更大问题有关。我想知道这个 CSS 样式是否在任何地方都有记录。我可以问他(但我有点讨厌打扰那些人)。 Brycehughes (讨论) 2022年2月15日 16:55 (UTC)[回复]
可能是的,对所有这些。MediaWiki 最初应该将 ":" 渲染为 <span ...>,但我猜现在太晚了。我不知道将 ":" 更改为其他内容对所有模板会有什么副作用,但也许这里的一些技术人员可以发表评论。–LPfi (讨论) 2022年2月15日 20:22 (UTC)[回复]
好的,我跟进了我的 MW 帖子。我会汇报。 Brycehughes (讨论) 2022年2月15日 22:35 (UTC)[回复]
LPfi,如我承诺的。就我个人而言,我不太在意这个。如果您想看看 TheDJ 的建议,那太棒了。但我不太确定它们的重要性,如果您现在没有精力,我很乐意将其搁置,以后有机会再提出。谢谢, Brycehughes (讨论) 2022年2月22日 18:04 (UTC)[回复]
我晚点看看。如果一周后我还没有在此评论,请提醒我。–LPfi (讨论) 2022年2月22日 18:24 (UTC)[回复]
好的。谢谢。 Brycehughes (讨论) 2022年2月23日 00:39 (UTC)[回复]
LPfi,正如我承诺的。就我个人而言,我不太在意这个。如果您想看看 TheDJ 的建议,那太棒了。但我不太确定它们的重要性,如果您现在没有精力,我很乐意将其搁置,以后有机会再提出。谢谢, Brycehughes (讨论) 2022年3月2日 19:35 (UTC)[回复]
谢谢。我想我会在某个时候做的——不知道它是如何工作的让我很困扰——但我认为我最好把它留到以后。–LPfi (讨论) 2022年3月2日 19:58 (UTC)[回复]

调查:帮助改进 Kartographer

您是否使用 Kartographer(mapframe)创建交互式地图?如果您的答案是肯定的,我们希望听到您的声音。请参加我们的调查,帮助改进 Kartographer!您在使用它时遇到什么问题?您希望看到哪些新功能?欢迎所有经验水平和使用 Kartographer 的各种工作流程的编辑参与。

调查地址: https://wikimedia.sslsurvey.de/Kartographer-Workflows-EN/

  • 调查开放至 3 月 31 日。
  • 完成调查大约需要 10-15 分钟。
  • 调查是匿名的。您无需注册,我们也不会存储任何识别您身份的个人数据,例如您的姓名或 IP 地址。

不幸的是,调查仅提供英文版本,但我们已尽最大努力使用简单的英语并添加视觉示例。如果英语不是您的母语,使用浏览器中的翻译工具可能会有帮助。

背景:Wikimedia Germany 的 Technical Wishes 团队目前正在开发 Kartographer 扩展。在过去的几个月里,我们一直在开发一个解决方案,以使该软件在尚未提供该软件的维基上可用。在项目的下一阶段,我们计划改进 Kartographer 本身。由于 Kartographer 在此维基上被大量使用,我们非常希望听到您的体验。有关我们使用 Kartographer 的工作以及地理信息重点领域的更多信息,请访问我们的项目页面

感谢您的帮助! – Johanna Strodt (WMDE) (讨论) 2022年3月21日 08:51 (UTC)[回复]

我们最好的地图专家是谁?我们有什么问题?这是一个非常重要的机会来请求我们所需的东西,我们不应该错过。我们还有 10 天。我们能做什么,来帮助他们理解我们需要什么? WhatamIdoing (讨论) 2022年3月21日 19:09 (UTC)[回复]
作为喜欢尝试动态地图的人,如果我想要两样东西,那就是我们拥有
这不就是使用不同的地图投影(例如“极地方位等距投影”吗?底层的工具是否提供该选项? ShakespeareFan00 (讨论) 2022年3月22日 07:39 (UTC)[回复]
@Andyrom75, @JIP, @Matroc, @FredTC,你们都在上面提到了地图问题和模板。请点击 https://wikimedia.sslsurvey.de/Kartographer-Workflows-EN/ 并将您的情况告诉 Johanna?调查中有几个问题(例如,您主要是读者、编辑者还是模板维护者?),第三页全部是关于问题的。有地方可以添加您自己的文字,并且附上之前讨论的链接很有帮助。
已完成。谢谢 @WhatamIdoing 的通知。 Andyrom75 (讨论) 2022年3月22日 16:35 (UTC)[回复]
啊,糟糕。我才刚看到这个调查。我记得这个扩展有一个问题,就是如果点跨越了 180 度经线。点不会并排显示,而是绕过本初子午线。您可以在斐济的 Taveuni 中看到这一点。(其他地方,如基里巴斯、阿拉斯加的阿留申群岛、俄罗斯的楚科奇和南极洲也可能出现这种情况)。 OhanaUnited讨论页 2022年4月12日 14:36 (UTC)[回复]

加入与 Maggie Dennis 的社区韧性和可持续性对话时段

您可以在 Meta-wiki 上找到该消息的更多语言版本。

Wikimedia Foundation 的 社区韧性和可持续性团队正在举办一个由其副总裁 Maggie Dennis 主持的对话活动。

本次通话的讨论范围包括:运动战略、董事会治理、信任与安全、通用行为准则、社区发展和人权。带上您的问题和反馈,让我们聊聊吧!您也可以提前将您的问题发送给我们。

会议将于 2022 年 3 月 24 日 15:00 UTC 举行(查看您当地时间)。

您可以在 Meta-wiki 上阅读详情

此致, Zuz (WMF) (讨论) 2022年3月21日 11:38 (UTC)[回复]

《通用行为准则》执法指南的批准投票现已结束

您可以在 Meta-wiki 上找到此消息的其他语言版本。

问候,

《通用行为准则》的修订执行指南的批准投票过程已于 2022 年 3 月 21 日结束。超过 2300 名维基媒体人参与了我们运动不同地区的投票。感谢所有参与此次过程的人!监督小组目前正在审查投票的准确性,因此请耐心等待,他们需要两周时间完成工作。

投票过程的最终结果将在此公布,以及相关的统计数据和评论摘要,一旦可用。请访问投票者信息页面了解后续步骤。您可以用任何语言在 Meta-wiki 的《通用行为准则》项目讨论页上发表评论。您也可以通过电子邮件联系 UCoC 项目团队:ucocproject(_AT_)wikimedia.org

此致,

运动策略与治理

Zuz (WMF) (讨论) 09:11, 2022年3月23日 (UTC)[回复]

掸邦维基行路志上线了

shn: 正在导入中:这对当地社区来说是一项了不起的成就,因为那里有 330 万讲 တွၼ်ႈ 语的人,分布在缅甸,而且那里的互联网普及率不高,还存在一些严重的内部民族问题,因此祝贺他们辛勤工作,并向为世界福祉传播免费知识和文化而努力的同志们致以ကြို+ဆို+ပါ၏(很抱歉,我那些新的掸族朋友:我太无知了,不知道如何使用感叹词“欢迎”,只知道动词……))。——Justin (koavf)TCM 15:58, 2022年3月23日 (UTC)[回复]

提取内容损坏

V1 REST API 上许多维基行路志文章的提取内容似乎突然丢失了。例如,法国("extract" 字段为空字符串)和纽约市(只有一个换行符)。最近这里有什么变化吗?谢谢。Brycehughes (讨论) 16:41, 2022年3月23日 (UTC)[回复]

@Brycehughes,你能再检查一下吗?Andyrom75 (讨论) 16:50, 2022年3月23日 (UTC)[回复]
Andyrom75,情况仍然是这样。我已经在mw上问过了Brycehughes (讨论) 16:56, 2022年3月23日 (UTC)[回复]
作为比较,伦敦仍然可以正常工作,但比较伦敦纽约市的文章,我没有看到任何明显的区别。Brycehughes (讨论) 17:04, 2022年3月23日 (UTC)[回复]
更新:是页面横幅模板。我在Fada上进行了测试。删除页面横幅模板后,REST API 的摘要调用恢复了提取内容。但是伦敦也有一个页面横幅模板,所以我不确定到底是怎么回事。Brycehughes (讨论) 17:13, 2022年3月23日 (UTC)[回复]
我看到以下输出
X
法国
X
伦敦
可以吗?--Andyrom75 (讨论) 17:27, 2022年3月23日 (UTC)[回复]
比较一下那两个的“extract”字段。注意法国的那个是空的 (""),而伦敦的那个有提取内容 (“嘈杂、充满活力且真正多元文化的…”)。extract 字段是网站(例如使用 en.wp 的 Google)在搜索结果中创建页面摘要时使用的。出于某种原因,这似乎在许多(也许是大多数)WV 页面上都丢失了。MediaWiki 的 extract 解析器卡住了。Brycehughes (讨论) 17:32, 2022年3月23日 (UTC)[回复]
好了,这个疯狂的想法怎么样?我想尽量缩小问题范围,目前我假设问题,至少是卡住解析器的代码,就在 Pagebanner 模板的某个地方。如果我创建一个新的、临时的模板(不确定我是否有权限这样做),然后复制 Pagebanner 模板的代码到那个新模板。然后我选择一个不常用的页面,比如说 Fada,用我自己的副本替换 Pagebanner 模板。然后我可以开始删除我自己的模板中的组件,直到找到破坏解析器的行。有了这个信息(假设我的计划可行),我就可以联系MediaWiki 解析团队说,“嘿,我认为这段代码正在破坏解析器”。幸运的是,他们也许能告诉我这是我们这边的问题还是他们那边的问题,甚至告诉我该怎么办。这听起来是不是很疯狂?如果不是,有没有人有更好的方法来沙盒化/开始处理这个问题?谢谢,Brycehughes (讨论) 15:40, 2022年3月24日 (UTC)[回复]
不是疯狂的想法。这种方法经常用于查找软件 bug:尝试找到触发它的最简单的代码。有些 bug 很难这样找到,特别是那些几乎随机出现的 bug,例如涉及竞态条件或耗尽某些奇怪资源的情况。如果这种情况是最近才开始发生的,而模板没有变化,那很容易是什么奇怪的原因。LPfi (讨论) 18:08, 2022年3月24日 (UTC)[回复]
哦……是的……我想我们遇到了一个海森 bug。将我的测试模板添加到Fada,提取内容正常返回。然后恢复到原始页面模板横幅,提取内容仍然在那里 :facepalm:Brycehughes (讨论) 18:53, 2022年3月24日 (UTC)[回复]
太奇怪了。要恢复提取内容,只需要删除 Pagebanner 模板,保存页面,然后恢复它。看来这绝对是 Mediawiki 人员该处理的问题了。谢谢大家。LPfi,你有没有空的时候帮我删除一下Template:Test1pagebannerBrycehughes (讨论) 19:24, 2022年3月24日 (UTC)[回复]
谢谢你的尝试。我暂时保留测试模板,我们可能仍然需要做一些实验。--LPfi (讨论) 19:40, 2022年3月24日 (UTC)[回复]
说得对,谢谢。Brycehughes (讨论) 19:43, 2022年3月24日 (UTC)[回复]
更新:似乎有一个 Bug 报告是关于这个(或者至少是类似的问题)……从十一月开始 :/ Brycehughes (讨论) 19:06, 2022年3月25日 (UTC)[回复]

WikiSP 的重要通知

21:28, 2022年3月23日 (UTC)

维基行路志十周年纪念日就要到了?!感觉第五周年才没多久。 WhatamIdoing (讨论) 18:41, 2022年3月24日 (UTC)[回复]
我那时(2018年)还不在,但从那时起时间真的过得真快。每周检查一次,发现那个博物馆(另一个网站)是一天比一天糟。--SHB2000 (讨论 | 贡献 | meta.wikimedia) 20:52, 2022年3月24日 (UTC)[回复]
这是我为即将到来的维基行路志十周年纪念所做的。一个放在YouTube 频道上的视频。视频 - https://drive.google.com/file/d/1b4EJKWyB9bZDibAEmDgGQ0wfPsYCsw-q/view 。花了大约 2 小时。请提出一些修改或更正,随时批评。祝好! :) 2006nishan178713t@lk 19:41, 2022年3月25日 (UTC)[回复]
@2006nishan178713 视频很好 - 我认为没有什么可批评的,即使你再吹毛求疵 ;-)。我唯一要说的是,31000 很快就会变成 32000(我们目前有 33,758 篇文章,如果我们再创建 700 多篇,很快就会达到 32000)。SHB2000 (讨论 | 贡献 | meta.wikimedia) 12:14, 2022年3月27日 (UTC)[回复]
是!2006nishan178713t@lk 12:44, 2022年3月27日 (UTC)[回复]
而且,它自 2003 年以来就一直存在,但后来才被采用。它是一个非常早期的 MediaWiki 维基。——Justin (koavf)TCM 22:08, 2022年3月24日 (UTC)[回复]
如果从第一个维基行路志迁移开始算,是 9 月 23 日。如果从第一个维基行路志被接受算起,是 1 月 7 日(eswikivoyage)。但我们的生日是 1 月 15 日!Galahad (sasageyo!)(esvoy) 23:50, 2022年3月24日 (UTC)[回复]
我记得 @GVarnum-WMF 曾经说过,他想做一个生日列表。我猜维基行路志也在 1 月 15 日的列表中。WhatamIdoing (讨论) 16:01, 2022年3月25日 (UTC)[回复]
嗨 @WhatamIdoing,你见过这个维基媒体生日列表吗?MPourzaki (WMF) (讨论) 20:16, 2022年3月30日 (UTC)[回复]
谢谢链接,@MPourzaki (WMF)。看起来所有的维基行路志都在“待验证”列表中,只有英语和德语被分开列出。@RolandUngerDerFussi,你们能检查一下页面上的德语“生日”吗?据我所知,英语是正确的。WhatamIdoing (讨论) 00:23, 2022年3月31日 (UTC)[回复]
@WhatamIdoing:有两个维基行路志生日:2006 年 12 月 10 日,维基行路志在德国上线,作为从维基旅行分叉的一个新项目(所以维基行路志现在有 15 年了)。2013 年 1 月 15 日,维基行路志正式成为维基媒体项目。这一天,维基百科满 12 岁。2012 年 11 月 9 日,维基行路志可从维基媒体服务器访问。在上面提到的列表中,我添加了意大利维基行路志,它是在第一个维基行路志生日时开始的。RolandUnger (讨论) 05:09, 2022年3月31日 (UTC)[回复]
英文维基行路志在 Wayback 机器上的存档。--RolandUnger (讨论) 05:34, 2022年3月31日 (UTC)[回复]
我理解这很不方便,因为原始名称已易手,但我们是否也应该记住项目最初在私人服务器上作为私人倡议启动的日期?我认为对于早期贡献者来说,中间发生的令人不快的事情只是一个括号,并不意味着其起源应该被遗忘。--LPfi (讨论) 06:46, 2022年3月31日 (UTC)[回复]
我认为这个特定的列表只适用于“官方生日”,这可能与首次编辑无关。每个维基行路志(或其他)社区选择将其周年纪念日定在哪一天,就应该被列入此列表。WhatamIdoing (讨论) 15:01, 2022年3月31日 (UTC)[回复]
我认为记录历史是个好主意,但这应该在另一个页面上。WhatamIdoing (讨论) 15:02, 2022年3月31日 (UTC)[回复]
(题外话)有人尝试过制作“旅行”视频内容吗?我指的是更像是 BBC 过去曾播过的旅游节目,而不是“自古以来,时代生活杂志就通过全球屏幕展示其宏伟的夸张宣传。眼睛很少会……”这种类型的旅行纪录片。88.97.96.89 14:35, 2022年3月27日 (UTC)[回复]
m:VideoWiki 允许你制作一种配音幻灯片。你可以包含视频和静态图像。机器生成的语音选项并不令人印象深刻,但录制真实的声音意味着你以后无法更改文本。WhatamIdoing (讨论) 15:46, 2022年3月27日 (UTC)[回复]

LintErrors

得益于早期的努力,我对英文维基行路志的“内容”部分已经基本完成了 Linter 清理,至少在我能力范围内是这样,无需额外的专业知识。

剩余未清理的是用户页面,以及基本上是讨论和对话命名空间,但已经形成共识,这些不应被修改(即使是善意的)。

恭喜。花了 4 年时间才清理完英文维基行路志的 Linter :)。

ShakespeareFan00 (讨论) 15:54, 2022年4月13日 (UTC)[回复]

关于清理用户页面的讨论在哪里?Ikan Kekek (讨论) 16:00, 2022年4月13日 (UTC)[回复]
我没有具体找到那次讨论,但这是我从一些(不一定是直接在维基行路志上的)贡献者那里获得的非官方建议。无论如何,我听说现在不让未登录用户修改用户空间页面了。ShakespeareFan00 (讨论) 16:29, 2022年4月13日 (UTC)[回复]
如果您拥有管理员/管理员权限并且想要解决用户和各种讨论命名空间中剩余的几个 LintErrors(很可能是由于旧版 Mediawiki/HTML/CSS 等接受的签名),我当然不能阻止您。ShakespeareFan00 (讨论) 16:31, 2022年4月13日 (UTC)[回复]
我不在乎这类事情,我只是问,因为我不记得见过关于这个话题的讨论。Ikan Kekek (讨论) 16:57, 2022年4月13日 (UTC)[回复]
另外,另一个维基的共识不适用于维基行路志。所以如果你真的想知道维基行路志上的人的想法,你得问问他们……Ikan Kekek (讨论) 17:03, 2022年4月13日 (UTC)[回复]
当然,但我们关心什么和我们应该关心什么不一定是一回事。——Justin (koavf)TCM 21:08, 2022年4月13日 (UTC)[回复]
我认为主空间的工作是好的,因为错误的语法可能会导致页面对某些读者显示错误。对于用户空间,还需要更多的讨论。对一些用户来说这没问题——很多人喜欢其他贡献者修复他们用户页面上的东西——但对另一些用户来说可能会有问题,特别是如果修复破坏了其他东西,而他们不在场来撤销或抱怨。--LPfi (讨论) 07:36, 2022年4月14日 (UTC)[回复]
fireflytools 上有一个 lint errors 表格。对于像过时的字体标签这样的东西,如果通过将它们更新为 span 标签来修复,我认为应该通过机器人账户进行。-- WOSlinker (讨论) 11:17, 2022年4月14日 (UTC)[回复]
另请参阅 Special:LintErrors。“高优先级”项目通常是那些有可能导致页面明显损坏的项目。理想情况下,任何命名空间都不应有这些问题,尽管显然许多人会认为修复低流量用户页面上的问题不值得自己花费时间和精力。我不打算阻止任何人修复任何地方的错误。WhatamIdoing (讨论) 16:01, 2022年4月14日 (UTC)[回复]
我注意到一个潜水点模板有“无效的文件参数”(NNNpx)。这似乎是示例中的解释性文本。我们通常如何处理?--LPfi (讨论) 17:16, 2022年4月21日 (UTC)[回复]

一篇关于中欧和东欧的流行文章写作比赛《CEE Spring》(现在有一个关于世界语的特别子类别)正在英文维基百科上进行,截止日期为2022年5月31日。我热烈邀请您参加,撰写文章并赢取丰厚奖品!如果您有任何疑问,我很乐意在比赛页面讨论区为您解答。

此外,为了更广泛地宣传,我刚刚请求了CentralNotice,它也应该会出现在本项目中。如果您对该请求有任何意见,欢迎在请求页面上写下。 --KuboF Hromoslav (讨论) 2022年5月3日 18:30 (UTC)[回复]

对本维基来说,更好的做法是撰写关于中欧和东欧的Wikivoyage文章Nurg (讨论) 2022年5月4日 05:06 (UTC)[回复]

运动战略与治理新闻 – 第6期

运动策略与治理新闻
2022年4月 第6期阅读完整新闻通讯


欢迎阅读第六期运动战略与治理新闻!这份改版的新闻通讯将分发关于运动章程、通用行为准则、运动战略实施补助金、董事会选举以及其他相关MSG主题的新闻和活动。

本新闻通讯将按季度发布,而更频繁的更新也将每周发布。如果您想收到本新闻通讯的未来各期,请在此订阅


  • 领导力发展 - 正在组建工作组!- 领导力发展工作组的申请已于2022年4月10日截止,最多12名社区成员将被选入工作组参与。(继续阅读
  • 通用行为准则批准结果公布! - 关于通过SecurePoll执行UCoC的全球决策流程于3月7日至21日举行。来自至少128个不同母项目的2300多名合格选民提交了他们的意见和评论。(继续阅读
  • 关于中心的运动讨论 - 关于区域和主题中心的全球对话活动于3月12日(星期六)举行,来自运动界的84位多元化的维基媒体人参加。(继续阅读
  • 运动战略补助金仍开放! - 自年初以来,已批准了六个项目提案,总价值约80,000美元。您有运动战略项目想法吗?联系我们!(继续阅读
  • 运动章程起草委员会已就位! - 该委员会由十五名成员组成,于2021年10月当选,已就其工作的基本价值观和方法达成一致,并已开始起草运动章程的提纲。(继续阅读
  • 推出运动战略周刊 - 贡献并订阅!- MSG团队刚刚启动了更新门户,该门户与Meta-wiki上的各种运动战略页面相连。订阅即可获取关于各种正在进行的项目的最新新闻。(继续阅读
  • Diff博客 - 查看关于维基媒体Diff运动战略的最新出版物。(继续阅读

Zuz (WMF) (讨论) 2022年4月13日 10:27 (UTC)[回复]

加入维基媒体基金会年度计划与Maryana Iskander的对话

你好,

运动通讯团队和运动战略与治理团队邀请您讨论2022-23维基媒体基金会年度计划,这是维基媒体基金会工作的记录计划。

这些对话是Maryana Iskander维基媒体基金会首席执行官倾听之旅的延续。

对话将围绕以下问题展开

  • 2030年维基媒体运动战略确立了“知识即服务”和“知识公平”的方向。维基媒体基金会希望根据这两个目标进行规划。您认为维基媒体基金会应如何将其应用于我们的工作中?
  • 维基媒体基金会正在继续探索在区域层面开展工作的更好方式。我们在补助金、新功能和社区对话等领域增加了区域重点。哪些方面做得好?我们如何改进?
  • 任何人都可以为运动战略进程做出贡献。让我们收集您的活动、想法、请求和经验教训。维基媒体基金会如何更好地支持从事运动战略活动的志愿者和附属机构?

您可以在Meta-wiki上找到会议日程

信息将提供多种语言版本。每次会议都将对任何人开放。部分会议将提供实时翻译。

此致,

Zuz (WMF) (讨论) 2022年4月15日 09:49 (UTC)[回复]

来聊聊桌面改进

大家好!

您是否注意到有些维基的桌面界面有所不同?您是否对下一步感到好奇?或许您对设计或技术问题有疑问或想法?

请参加与负责桌面改进的团队的在线会议!会议将于2022年4月29日 13:00 UTC18:00 UTC在Zoom上举行。点击此处加入。会议ID: 88045453898。按您的位置拨打

议程

  • 近期进展更新
  • 问答环节,讨论

形式

会议不会被录制或直播。会议记录将保存在一个Google Docs 文件中。Olga Vasileva(产品经理)将主持此次会议。演示部分将以英语进行。

我们可以回答以英语、法语、意大利语和波兰语提出的问题。如果您想提前提问,请在讨论页上添加,或发送至sgrabarczuk@wikimedia.org。

本次会议将同时适用友好空间政策和维基媒体技术空间的行为准则。Zoom不受WMF隐私政策的约束。

希望见到您! SGrabarczuk (WMF) (讨论) 2022年4月26日 00:35 (UTC)[回复]

这与Vector 2022有关吗?我不会参加会议,但我肯定不喜欢这个开发。幸运的是,Monobook仍然可用。我在他们的反馈页面上发表了评论,但上次检查时(在我发表评论很久之后)没有人回应。我的主要担忧是,除非您的浏览器窗口足够宽(我喜欢窄的),否则布局会很糟糕,而且许多重要链接都隐藏起来以获得“更清洁”的外观(大部分在下拉菜单中;我甚至无法直接键入文章名称,我必须先最大化窗口,或转到搜索页面,或直接编辑浏览器地址栏中的URL)。 –LPfi (讨论) 2022年4月26日 10:01 (UTC)[回复]
提醒@SGrabarczuk (WMF)。LP,听起来你的屏幕比标题栏窄,结果搜索框(AIUI比2010版Vector版本更大且居中)丢失/折叠/无法使用。是这样吗? WhatamIdoing (讨论) 2022年4月26日 15:11 (UTC)[回复]
如果有人想查看选项,请点击这些链接
这些链接不会改变您的偏好。它们只会为该页面/一次加载皮肤。 WhatamIdoing (讨论) 2022年4月26日 15:14 (UTC)[回复]
是的。我的浏览器窗口比标题栏窄。不是我的屏幕,但我在使用多个窗口,例如在编辑Wikivoyage指南时查看维基百科页面和地图。我还没弄懂为什么人们要坚持使用窗口系统引入之前的单应用程序模式。Alt-tab功能有点帮助,但我记得(如果是正确的)在1980年代的VT220文本终端上就已经使用它了(shift-control-^)。感谢您提供的皮肤链接。 –LPfi (讨论) 2022年4月26日 16:31 (UTC)[回复]
而且不只是标题栏。左侧边栏菜单会推下内容,导致我每次加载新页面时都必须向下滚动。非常令人沮丧。 –LPfi (讨论) 2022年4月26日 16:34 (UTC)[回复]
嘿 @LPfi,很抱歉没有及时回复!让我在这里回答您的问题。
  • 至于左侧边栏菜单,如果您将其折叠,它应该会保持折叠状态,而不会推下内容。
  • 关于您在项目讨论页上提出的问题(“左侧边栏右侧的空白空间是否真的提供了最佳体验”),我们仍在分步改进新界面。您提到的空白空间是暂时的。现在,我们正在处理页面工具,这将清楚地区分全局链接(如“最新更改”)和页面相关链接(如“相关更改”),并在内容区域两侧带来平衡。
  • 窄屏幕……我会和团队讨论这个问题。一般来说,我们的目标是使界面在窄屏幕或垂直屏幕(但非移动端)上可用。我们正努力使默认体验的最小阈值尽可能窄。
  • 在这种情况下,左侧边栏菜单和其他事情……我认为这属于该项目的最后阶段,届时我们将致力于整个界面的美学改进(而不是改进单个功能)。
SGrabarczuk (WMF) (讨论) 2022年4月26日 16:50 (UTC)[回复]
  • 感谢关于折叠菜单的提示。我之前没注意到这个可能性。不过,在我现在测试时,每次在新页面上跟随链接时都必须单独折叠它。
  • 很高兴您将消除空白区域。当我尝试使用该皮肤时,我没有找到关于未解决问题或哪些缺陷是尚未实现的功能而哪些是预期功能的讨论。也许我查得不够仔细。页面工具和其他链接之间的分离是一个好目标;我希望链接仍然易于像我这样的用户访问,他们知道这些链接并且可以忽略当前不需要的链接(这是您似乎承认的需求)。
  • 真的很好。到目前为止,我遇到了我默认窗口宽度的一些问题,而其他问题则在我偶尔使用的宽度下出现。然而,在某些情况下能够获得窄窗口是很重要的,而且能够摆脱左侧边栏是一个巨大的帮助。我希望目录的新建议位置不会与此冲突。
    (我认为在任何设计讨论中明确区分窗口和屏幕尺寸是很重要的,因为前者的常见或实际宽度不受后者的限制,而且我见过网页根据后者进行调整,或多或少地忽略前者,而前者应该是相关的。)
  • 好的,您比我更清楚何时以及如何处理这些事情,它们应该在全面推广之前得到修复。
LPfi (讨论) 2022年4月27日 09:02 (UTC)[回复]
啊!现在折叠起作用了。我之前为Mediawiki网站禁用了Javascript,启用后也没有立即生效。嗯。我为我经常访问的所有维基媒体项目启用了Javascript,但我是常客。像我这样的普通访问者禁用Javascript(对所有或部分域名)是您考虑的用例吗? –LPfi (讨论) 2022年4月27日 09:07 (UTC)[回复]

2022年董事会候选人征集

您可以在Meta-wiki上找到此消息的附加语言版本。

董事会正在征集2022年董事会选举的候选人。在Meta-wiki上阅读更多内容。

2022年董事会选举到来了!请考虑提交您的候选资格,以在董事会任职。

维基媒体基金会董事会负责监督维基媒体基金会的运营。社区和附属机构选出的董事和董事会任命的董事组成董事会。每位董事任期三年。维基媒体社区有机会投票选举社区和附属机构选出的董事。

2022年,维基媒体社区将投票选出董事会的两个席位。这是一个提高董事会作为团队的代表性、多样性和专业性的机会。

潜在候选人是谁?您是潜在候选人吗?请在申请候选人页面上了解更多信息。

感谢您的支持,

代表选举委员会和董事会,运动战略与治理团队

Zuz (WMF) (讨论) 2022年4月26日 12:53 (UTC)[回复]

后续步骤:通用行为准则(UCoC)和UCoC执行指南

维基媒体基金会董事会社区事务委员会感谢所有参与最近结束的通用行为准则(UCoC)执行指南社区投票的人。

虽然执行指南达到了董事会审议所需的最低支持门槛,但我们鼓励选民,无论其投票意向如何,都就他们认为需要修改或修复的执行指南的要素及其原因提供反馈,以防万一有必要启动新一轮编辑来解决社区的担忧。

基金会工作人员一直在审阅评论,并已向我们通报了部分新兴主题,因此我们社区事务委员会决定要求基金会重新召集起草委员会,并进行另一轮社区参与,以根据最近投票收到的社区反馈来完善执行指南。

此外,我们已知悉《通用行为准则政策》中第3.1条的担忧。我们指示基金会促进对该语言进行审查,以确保该政策符合其旨在支持安全和包容性社区的宗旨,而无需等到年底对整个政策进行计划审查。

请访问此处阅读完整公告。

此致, Zuz (WMF) (讨论) 2022年4月28日 11:53 (UTC)[回复]

使模板工作更轻松:又一项改进即将到来。

大家好,来自WMDE的“模板”关注领域的一项新变化即将登陆您的维基:在语法高亮CodeMirror扩展)中,您将可以通过用户设置激活一个色盲友好型配色方案。(项目页面

计划于5月10日部署。这是WMDE“模板”关注领域的最后一组改进。我们非常希望听到您的反馈

感谢您成为首批获得我们项目改进的维基之一,并提供宝贵的反馈! – Johanna Strodt (WMDE) (讨论) 2022年4月29日 09:55 (UTC)[回复]

供参考:相关的社交网络/应用程序

https://travelfacets.com/Justin (koavf)TCM 2022年5月1日 20:33 (UTC)[回复]

编辑新闻 2022 #1

以其他语言阅读此多语言新闻通讯订阅列表

新编辑者使用新工具的成功率更高。

新的话题工具帮助编辑者在讨论页创建新的==章节==。新编辑者使用此新工具的成功率更高。您可以阅读报告。很快,编辑团队将为参与测试的20个维基百科的所有编辑者提供此功能。您可以在Special:Preferences#mw-prefsection-editing-discussion处将其关闭。

Whatamidoing (WMF) 2022年5月2日 18:55 (UTC)[回复]

待批准模板:Template:ColonialEmpires

我没有创建这个模板,但还是提交社区批准(根据我们有争议的严格模板政策)。它有助于读者浏览我们的殖民主义文章,目前输出如下:Template:ColonialEmpires

我看不出有任何反对这个模板的理由。 --SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月4日 11:28 (UTC)[回复]

奥斯曼帝国和奥地利帝国在多大程度上是殖民帝国?它们不是更传统的跨国帝国吗? Ikan Kekek (讨论) 2022年5月4日 11:33 (UTC)[回复]
那么模板是否应该重命名为Template:Empires,并且“殖民帝国”一行替换为“帝国”?但那样的话,我们还必须包含藏帝国蒙古帝国等等。@The dog2:,有什么建议吗? SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月4日 11:38 (UTC)[回复]
我们真的需要这个模板吗? Ikan Kekek (讨论) 2022年5月4日 12:48 (UTC)[回复]
我们有Template:NordicCountries,这个和那个类似,为什么不呢? SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月4日 12:52 (UTC)[回复]
不,它不是,因为北欧国家非常明确。我的建议是,如果您认为创建一个简单地链接所有帝国文章的页面非常重要,请创建它,并列出简短的描述。我将反对使用此模板。 Ikan Kekek (讨论) 2022年5月4日 13:03 (UTC)[回复]
我们上面不是刚讨论过关于殖民主义的文章吗(见#"Article" on colonialism)?而且,这个模板正在被链接的所有文章使用,我不太确定是否值得删除它们。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月4日 13:22 (UTC)[回复]
我之所以创建这个模板,是为了替代创建一篇几乎没有旅游内容的文章。 Ikan Kekek 对奥匈帝国大部分情况是对的,但他们在华有一个租界,从各方面来看,这都是一个殖民地,尽管非常小。我认为我们可以将范畴限制在源自大发现时代的欧洲式殖民帝国。日本也包括在内,因为尽管它不是西方国家,但日本从西方 adopted 了它的殖民主义模式。我不认为奥斯曼帝国有殖民地,这也是我最初没有包括它的原因,但我也许错了。 The dog2 (讨论) 2022年5月4日 14:53 (UTC)[回复]
这是一个可能的解决方案。不过我想说的是,没有必要或没有理由创建关于帝国的文章,因为已经有一篇君主制文章了。 Ikan Kekek (讨论) 2022年5月4日 17:26 (UTC)[回复]

────────────────────────────────────────────────────────────────────────────────────────────────────美国自建国以来一直是共和国,但它曾有过(并且有些人认为仍然有)海外殖民地。所以从这个意义上说,它可以被宽泛地视为一个殖民帝国,即使它在技术上没有皇帝掌权。同样,法国和荷兰在某些时期也拥有殖民帝国,尽管它们是共和国。 The dog2 (讨论) 2022年5月4日 17:32 (UTC)[回复]

另外,从旅行者的角度来看,我认为问题在于是否有任何关于你可以去参观殖民统治遗迹的海外地点列表。就奥匈帝国而言,天津有一些至今仍可参观的殖民建筑。同样,哈尔滨和大连也有许多俄式殖民建筑可供参观。 The dog2 (讨论) 2022年5月4日 17:43 (UTC)[回复]
奥地利/奥匈帝国的典型旅行者视角是,它对中欧留下了深刻的印记。寻找他们在天津短暂存在的遗迹则更为不寻常。俄国殖民主义主要集中在向东扩张和定居,通过吞并占领所有领土,就像美国大部分殖民主义所做的那样向西扩张。正是这些情况的复杂性使得模板的过度简化变得有问题。 Ikan Kekek (讨论) 2022年5月4日 18:13 (UTC)[回复]
好的,我们看看其他人怎么说。我的观点是,我们可以宽泛地认为俄国和奥匈帝国是殖民帝国,因为它们确实拥有海外殖民地,无论数量多少或大小如何。我将移除奥斯曼帝国,因为它是一个经典的连续多民族帝国,没有海外殖民地(Yvwv是添加它的人,所以也许他可以评论我是否错了),很像中国和蒙古帝国。菲律宾是美国的殖民地,所以我认为美国曾是一个殖民强国,也许现在仍然是,如果你认为关岛、波多黎各和美属维尔京群岛是殖民地的话。 The dog2 (讨论) 2022年5月4日 20:41 (UTC)[回复]
我认为我们需要就我们是否想要任何导航框风格的模板进行更广泛的讨论。如果我们不希望文章包含一套“一刀切”的链接到其他文章,那么就没有必要讨论我们是否想要这一特定集合的“一刀切”链接。 WhatamIdoing (讨论) 2022年5月4日 20:47 (UTC)[回复]
我也不太喜欢维基百科上的导航框,而且我认为在正文中链接相关文章已经足够容易了。不过,我明白有些人喜欢它们,所以我并没有特别反对。这个特定的分组还有额外的问题:什么文章相关并没有明确定义,而且并非所有列出的文章都讲述了帝国的殖民主义方面(只列出一些目的地和景点真的足够吗?)。 –LPfi (讨论) 2022年5月5日 07:16 (UTC)[回复]
我也不能确定这个分组对旅行者是否有意义。如果一个人想去日本殖民帝国相关的地点旅行,那是否意味着他们也可能对瑞典殖民帝国感兴趣?我见过的其他导航模板为有特定兴趣的旅行者服务——Template:Asian cuisines和类似的为美食家,位于美国内战的为美国历史爱好者,位于Australasian wildlife的为野生动物爱好者。有没有帝国爱好者会觉得这个模板有用? —Granger (讨论 · 贡献) 2022年5月5日 09:44 (UTC)[回复]
老实说,不确定,但它肯定比有一个关于殖民主义的文章要好。我可以在百科全书中看到这种情况,但在旅游指南(甚至维基教科书)中很难想象(说实话)。 (另外,对于美食的那个,也许Template:Asian cuisines是一个有点误导性的模板,但Template:EuropeanCuisines有类似的目的,但没有误导性的东西,但也是一样…) --SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月5日 09:59 (UTC)[回复]
我仍然认为,一个关于殖民主义的旅游指南,如果写得好,是可能有意义的。我认为我们中的任何一个人都不会写这篇文章(缺乏时间、技能或兴趣)。对于维基教科书,我完全可以看到这样的书被写出来。为什么不呢?那也会很困难(我不知道哪个更难),但如果你是一名历史老师,你可能会为你的学生需要这本书。对旅行者来说,这是一个更小众的话题。 –LPfi (讨论) 2022年5月5日 11:27 (UTC)[回复]
@WhatamIdoing 就我所知,de.voy 也在目的地文章中使用这些导航框,例如在 de:Piton des Neiges#Weblinksde:Südamerikade:Southland#Weblinks 中看到的。我们可以效仿 de.voy,但我并不赞成 de.voy 将其插入几乎所有地区性文章的做法。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月5日 10:05 (UTC)[回复]

────────────────────────────────────────────────────────────────────────────────────────────────────我不知道关于殖民主义的旅行话题会如何运作。我不认为有任何关于殖民主义本身的纪念碑。但另一方面,在远离各自宗主国的遥远土地上有许多历史遗迹和建筑,它们提醒着殖民统治的遗留。例如,如果你去河内,有很多法国殖民时期的建筑,同样,如果你去仰光,也有很多英国殖民时期的建筑。 The dog2 (讨论) 2022年5月5日 15:09 (UTC)[回复]

我不确定人们是否会为了看殖民主义纪念碑而出游,所以我也不确定创建这样一个页面是否有意义。我不记得有任何纪念普遍概念的殖民主义的纪念碑,但有很多纪念地方殖民历史的纪念碑。例如,美洲各地有许多克里斯托弗·哥伦布的雕像,或者加州埃尔卡米诺雷亚尔沿线的铃铛。 El Camino Real 的长度表明,“殖民历史”与“自亚历山大大帝以来的世界历史”有很大重叠。 WhatamIdoing (讨论) 2022年5月5日 17:17 (UTC)[回复]
正是如此。我会说,为了保持模板的尺寸可管理,并且因为这通常是我们谈论“殖民地”时想到的,我们应该将包含范围限制在欧洲风格的殖民帝国,这些帝国始于 地理大发现时代。这意味着,如果他们的文章被创建,唯一剩下的帝国就是美国、比利时、德国和意大利帝国。我知道俄罗斯帝国和奥匈帝国主要是连续的多民族帝国,但它们确实有海外殖民地,所以它们可以保留。另一方面,我会剔除奥斯曼帝国,因为它没有海外殖民地。我认为这个模板有助于导航的便捷性,例如,对殖民时代遗产感兴趣的人可以通过我们的文章了解到俄罗斯也有海外殖民地,并计划一次旅行,看看俄罗斯殖民主义的遗迹。 The dog2 (讨论) 2022年5月5日 18:19 (UTC)[回复]
我们在这里开始变得复杂。我之前提到过,俄罗斯和美国的殖民主义主要针对东部和西部的连续陆地,那里居住着统治民族的成员并被吞并,而奥地利帝国则以其位于欧洲中心的跨民族帝国而闻名;其海外领土是一个非常次要的、几乎是附带的点,而且在其历史的大部分时间里并不存在。所以我不太喜欢一概而论地对待这些力量。 Ikan Kekek (讨论) 2022年5月5日 18:34 (UTC)[回复]
是的,我注意到了。美国曾拥有利比里亚和菲律宾,这些都是传统欧洲意义上的海外殖民地。俄罗斯在中国也曾有一些殖民地,也符合这个标准(我这里不包括符拉迪沃斯托克之类的地方,那是俄罗斯吞并的中国领土,今天属俄罗斯)。 The dog2 (讨论) 2022年5月5日 18:39 (UTC)[回复]
中国东北地区与俄罗斯接壤,所以符合西伯利亚殖民的模式,并且集中于美国历史上或甚至当前海外殖民地,这扭曲了美国殖民主义的压倒性历史,该历史主要由白人定居并被整合为州组成。 Ikan Kekek (讨论) 2022年5月5日 18:42 (UTC)[回复]
中国东北地区是这样,但俄罗斯在天津和汉口(今武汉的一部分)也有殖民地,尽管那些地方比东北的殖民地小得多。而且我认为俄罗斯在非洲也曾有一个短暂存在的殖民地,后来被法国人赶走了。 The dog2 (讨论) 2022年5月5日 18:52 (UTC)[回复]
关于俄罗斯殖民主义,w:Russian America呢?也有俄罗斯殖民地遗址可供游客参观,例如 w:Russian Fort ElizabethSHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月7日 04:05 (UTC)[回复]
这个模板可能有助于想阅读殖民帝国的人。但那些想阅读一般帝国的人呢?是否应该再创建一个模板?也许第三个关于欧洲帝国,第四个关于欧洲历史,等等。我不认为殖民主义是 瑞典帝国奥匈帝国俄罗斯帝国 的焦点。这些帝国可能是殖民主义的,但我们的文章主要关注其他方面。–LPfi (讨论) 2022年5月5日 19:33 (UTC)[回复]
它们不是焦点,但海外领土也被列出了。创建专门涵盖奥匈帝国和俄罗斯帝国海外殖民地的文章是没有意义的,因为殖民地不多,而且存在的殖民地也很小。然而,它们应该并且确实被列在关于这些帝国的各自文章中。同样,关于大英帝国的文章应该涵盖爱尔兰,即使爱尔兰从未被正式称为“殖民地”,而是被视为英国的一部分(尽管任何公正的人都不能否认,在大饥荒期间,爱尔兰人的待遇如同殖民地居民而非公民)。 The dog2 (讨论) 2022年5月5日 19:42 (UTC)[回复]
我们谈论得越多,我越觉得我们应该删除这个模板,只在文章中用正常句子替换相关链接。这意味着,与其(而不是“除了”)将 Template:ColonialEmpires 插入到那里链接的十一个文章中,不如我们在 Sweden#UnderstandWismar#Understand 等文章中写句子,链接到 Swedish Empire,甚至在 Spanish EmpirePortuguese Empire 等文章中写句子来解释它们曾是竞争对手。我们不会假设读旅行指南的人想比较所有关于帝国的文章,包括彼此没有联系的帝国。 WhatamIdoing (讨论) 2022年5月6日 03:17 (UTC)[回复]
想阅读帝国一般内容的人应该去维基百科。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月6日 06:30 (UTC)[回复]
反对,因为它与旅行的关系不大,而且主题过于复杂,模板难以很好地运作。
它没有包含德国或美国的殖民地。那各种伊斯兰哈里发呢?非洲撒哈拉以南地区曾经有过帝国吗?
它省略了 中国亚历山大大帝 的帝国、罗马帝国波斯帝国蒙古帝国,这些帝国都征服过其他国家。有人可能会争辩说,那些是连续的陆地帝国,不属于这一类,但俄罗斯、奥斯曼和奥匈帝国也大部分是这样的。
那俄罗斯在 冷战 期间对东欧的控制,中央情报局对各种政变的资助,美国在拉丁美洲的入侵,以及中国近期对 南沙群岛 的土地掠夺?在我看来,这些都像是相当恶劣的帝国主义,但似乎不属于旅行指南的主题。 Pashley (讨论) 2022年5月6日 08:04 (UTC)[回复]
你链接的帝国文章不是殖民帝国。此外,我们不处理这个模板中的单个殖民地,只处理关于殖民文章的各种旅行话题。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月6日 08:06 (UTC)[回复]
我同意 WhatamIdoing 的观点:“我们谈论得越多,我越觉得我们应该删除这个模板,只在文章中用正常句子替换相关链接。” Ikan Kekek (讨论) 2022年5月6日 10:14 (UTC)[回复]
这些不是关于帝国主义的文章。这些是列出了游客可以去看看那个帝国遗迹的文章。关于帝国主义本身的笼统文章不应出现在 Wikivoyage 上,除非有作为旅游景点的帝国主义纪念碑。 The dog2 (讨论) 2022年5月6日 15:09 (UTC)[回复]
而且,关于美国、德国、意大利和比利时的殖民地,我的计划是,一旦关于这些帝国的文章被创建,就把它们添加到模板中。 The dog2 (讨论) 2022年5月6日 19:16 (UTC)[回复]
我的想法与 The dog2 一致,但如果我们不能就应该包含什么达成一致,那么我们应该只包含在 w:Template:Empires 的“现代帝国”部分的“殖民地”中可以找到的内容。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月7日 03:27 (UTC)[回复]
我不认为有共识支持继续使用这个导航框。 Ikan Kekek (讨论) 2022年5月7日 14:24 (UTC)[回复]
致 The dog2:当然,可以写一篇关于俄罗斯在美国殖民遗产的优秀旅行文章。如果写了,我认为 Russian America 不是一个好的标题,因为曾有几波来自俄罗斯/苏联的移民潮与俄罗斯在美国的殖民主义无关。 Ikan Kekek (讨论) 2022年5月7日 21:37 (UTC)[回复]
鉴于此模板未获批准,我已将其 提请删除。请在此讨论串中参与讨论。谢谢大家! Ikan Kekek (讨论) 2022年5月7日 21:41 (UTC)[回复]
我绝不反对这个模板。撇开讨论中占一半篇幅的“又怎么样”式的诡辩不谈,我认为这个模板可以更好地重命名为(现代帝国主义,而不是殖民主义。正如其他人所说,并非所有这些都是严格意义上的殖民,但它们都具有 帝国主义的性质。文章大多相互链接,包括文章本身和“参见”部分,我认为一个模板会有用,因为这个原因。我强烈 支持 这个模板,作为 {{ModernImperialEmpires}} 或类似名称,并对现有模板表示一些温和的支持。
-- Wauteurz (讨论) 2022年5月7日 22:00 (UTC)[回复]
如果真是如此,你会如何处理 莫卧儿帝国Ikan Kekek (讨论) 2022年5月8日 00:44 (UTC)[回复]
这取决于模板的范围。如果只是现代帝国,我不会包含它。现代帝国主义通常是针对欧洲帝国的。奥斯曼帝国也因此有争议。理想情况下,我会将奥斯曼和莫卧儿帝国以及其他一些帝国归类为 w:火药帝国,要么放在姊妹模板中,要么放在这个模板的第二个分组中(那么范围就是现代帝国)。我自己的分组如下
现代帝国主义帝国1
奥匈帝国大英帝国丹麦帝国荷兰帝国法国殖民帝国日本(殖民)帝国葡萄牙帝国俄罗斯帝国西班牙帝国瑞典帝国
火药帝国
中国2莫卧儿奥斯曼日本(前现代)萨法维
(1) 可以称之为欧洲帝国,但加入日本就不太合适了。然而,它的殖民帝国很大程度上是对欧洲帝国主义的回应,所以这个名字并不错误,只是不直观。
(2) 我对中国历史不太了解,但我认为这主要包括明朝和清朝。
如果还有其他帝国可以包含,请告诉我,我会更新这个列表。 Wauteurz (讨论) 2022年5月8日 10:55 (UTC)[回复]
如果你谈论的是公元1200年至今存在的帝国,那么莫卧儿帝国就不能排除(而且我不知道你说的“现代帝国主义帝国”是什么意思:它无疑是一个征服了大量领土并施加影响力的庞大帝国),但它是一个 遭受 殖民主义的国家,而不是一个殖民帝国。此外,此后非洲也出现过帝国。而且我会注意到,我们目前的情况很荒谬,这个讨论串中绝大多数人反对使用这个模板,但在 Wikivoyage:Votes for deletion#Template:ColonialEmpires 中却有共识保留这个模板并使用它...做某事。所以任何不希望我们为或多或少任意划分的帝国分组使用导航框的人,请参与删除投票讨论。 Ikan Kekek (讨论) 2022年5月8日 14:46 (UTC)[回复]
如果有人总是让我烦恼,那就是那些断章取义地引用我的话来暗示我不认同的观点。虽然我很欣赏你的意见,但我也希望你下次不要再这样做。为了清晰起见,逐点说明:
  • 公元1200年只是我为举例而设定的一个任意时间点。它并非一成不变。如果你想要一个更好的界限,我建议从地理大发现时代到非殖民化时代(即公元±1450年 - ±1950年)。如果你有其他关于模板范围的建议,我很乐意考虑。
  • 现代帝国主义帝国是指奉行现代帝国主义的帝国;一般来说,它们是欧洲的(不包括1850年代后的日本和其他一些国家),其创建的目的是为了殖民和剥削这些殖民地以造福宗主国。
  • 莫卧儿帝国:我从未说过莫卧儿帝国不是殖民主义的受害者,也不是说它是一个殖民帝国。这次讨论的这一部分是我试图利用这个模板的有用之处,并提出改进方法。模板目前围绕殖民主义的范围已被证明是有争议的,所以我的提议省略了这一基础。因此,我在此次讨论中说的任何话都不能被视为我个人对殖民主义的看法。请在下次转述我时考虑到这一背景。
  • 非洲帝国:整个讨论充满了“又怎么样”(为什么包含 X 而不包含 Y?)的诡辩,我正试图摆脱这种局面。我并不是说非洲帝国或任何类型的帝国在我 建议改进范围 中没有位置。我不包含它们,因为它们还没有被提出,而且由于我想摆脱“列出什么”的讨论,转而进行关于这个模板是否真正有用的讨论。我不是在说非洲帝国或任何帝国在我的 建议改进范围 中没有位置。我之所以没有包含它们,是因为它们还没有被提出,而且我希望摆脱“列出什么”的讨论,转而进行关于这个模板是否真正有用的实际讨论。
  • 共识:这里,反对模板的论点主要是反对它对殖民主义的定义(包含什么,不包含什么),以及对其旅行相关性的担忧。后者本身并非旅行相关,但它支持了所有围绕 历史旅行 的文章,因此对网站有用。前者则不是反对这个模板有用的论点,而这才是模板审批讨论应该关注的。通过说明它可以是什么样子,我试图将对话转移到更细致的“它可能是什么”的讨论,而不是非黑即白的“用或丢弃”的讨论,因为我认为后者不太有成效。
我坚信这个模板的有用性,并且我正在寻求一种方法,使其能被更多人接受。在我看来,这次大部分讨论已经偏离了主题,错失了模板审批讨论的重点。
-- Wauteurz (讨论) 2022年5月8日 17:35 (UTC)[回复]
“现代帝国主义帝国是指奉行现代帝国主义的帝国”这是一个循环定义。请解释其含义,例如,它如何能包含俄罗斯而排除莫卧儿帝国或桑海帝国。 Ikan Kekek (讨论) 2022年5月8日 18:25 (UTC)[回复]
指出某事可能没有意义不是“诡辩”。首先,我同意 WhatamIdoing 关于这个模板本身对旅行者没有用处的看法,但我也看到,到目前为止,试图对帝国进行任何普遍意义上的分类,与旅行的关系都不大。 Ikan Kekek (讨论) 2022年5月8日 18:28 (UTC)[回复]
而且,我们不应该使用像“火药帝国”这样的欧洲中心主义词汇。在你链接的维基百科文章中,请阅读 w:火药帝国#关于该概念的近期观点。此外,这是一个晦涩的术语,我57年来一直不知道它,而且我了解甚至教授过很多历史。 Ikan Kekek (讨论) 2022年5月8日 18:33 (UTC)[回复]
首先,请参考后面的句子:“它们通常是欧洲的(不包括1850年代后的日本和其他一些国家),并且是为了殖民和剥削殖民地以造福祖国而建立的。”莫卧儿和桑海帝国之所以不被包含,是因为它们与现代帝国主义帝国在可用的技术方面存在差异。俄罗斯被包含在内,因为它在帝国主义方面与奥匈帝国的功能相似:向邻近土地扩张,使其成为核心领土,然后重复。我是在过度简化,但分类总需要某种程度的概括。
该模板并非对所有旅行者都有用,但它不需要如此。它反而对历史感兴趣的旅行者有用,因为许多独立的殖民地在其存在期间曾属于不止一个殖民者。
我怎么强调都不为过,上面示例中的任何内容都不是一成不变的。我使用“火药帝国”作为例子,而不是表明它应该被实施。如果你有更好的替代方案,请尽管提出来。
-- Wauteurz (讨论) 2022年5月8日 19:26 (UTC)[回复]
我认为武器技术差异对旅行者看到的帝国遗迹的 the impressiveness 没有影响。老实说,古埃及的狮身人面像和金字塔可能没有什么比这更令人印象深刻了,但我并没有亲眼见过。我见过泰姬陵、德里的红堡和阿格拉的红堡、中国长城以及普兰巴南和婆罗浮屠的寺庙建筑群,更不用说帕特农神庙、庞贝、赫库兰尼姆、罗马广场和尼姆的 Maison Carree。但说到这里,我离题了。你会看到,我正在逐渐接受在删除投票中创建一个经过精心界定且与旅行高度相关的殖民主义文章的想法。如果它以古代腓尼基人开始;并包含免责声明,说明该主题有争议,但由于这是一本旅行指南,我们只是在描述;并且规定我们专注于海外殖民,我都可以接受。 Ikan Kekek (讨论) 2022年5月8日 19:29 (UTC)[回复]
再次简化来说,但俱乐部和长矛对许多人来说比步枪和火枪的吸引力不同。前者可以被视为原始的,而后者则更先进。我认为你低估了其中的技术差异。对一些对历史感兴趣的人来说,它们具有非常不同的吸引力。正如我在删除投票中指出的那样,与君主制的联系过于牵强,难以奏效。
说实话,我可以接受不使用导航框,但一个合适的替代方案绝对可以使旅行者受益,原因我在删除投票中已列出。一个基础的关于殖民主义、帝国或帝国主义的通用文章肯定是有益的,尽管是面向一个相当小众的受众,但我们已经有很多小众文章了,所以这不应该是个问题,对吧? Wauteurz (讨论) 2022年5月8日 20:10 (UTC)[回复]
我认为技术差异对游客能看到的令人印象深刻的遗迹没有影响。老实说,古埃及的狮身人面像和金字塔可能没有什么比这更令人印象深刻了,但我并没有亲眼见过。我见过泰姬陵、德里和阿格拉的红堡、中国长城以及普兰巴南和婆罗浮屠的寺庙建筑群,更不用说帕特农神庙、庞贝、赫库兰尼姆、罗马广场和尼姆的 Maison Carree。但说到这里,我离题了。你会看到,我正在逐渐接受在删除投票中创建一个经过精心界定且与旅行高度相关的殖民主义文章的想法。如果它以古代腓尼基人开始;并包含免责声明,说明该主题有争议,但由于这是一本旅行指南,我们只是在描述;并且规定我们专注于海外殖民,我都可以接受。 Ikan Kekek (讨论) 2022年5月8日 20:30 (UTC)[回复]

[缩进]
我不认为关于帝国的文章是作为一个殖民主义系列写的。我不太满意一个模板让它看起来像是这样。如果我们想要一个模板,为什么它不是关于一般帝国,或者关于历史领域?我认为阅读历史帝国的人很可能对历史领域感兴趣(尽管也许不是全部)。假设他们对殖民主义感兴趣是仓促下结论。当然,有些人是。但他们中的许多人可能对他们正在阅读的帝国感兴趣的其他方面:它的语言、它的现代继承者、它的城市、它的艺术,等等。

我的印象是,这个模板之所以存在,是因为有人想要一篇关于殖民主义的文章,而他们认为这就是他们能得到的。我认为我更喜欢 Colonialism 这篇文章。似乎在可预见的将来,没有人会写一篇关于这个主题的真正深入的旅行文章,但一篇有几段关于殖民帝国、链接这些和相关文章(如欧洲历史和地理大发现时代)的文章怎么样?然后继续讲述那些容易看到(或研究)几个殖民帝国遗产的目的地——并检查这些方面是否在目的地文章中得到涵盖?

LPfi (讨论) 2022年5月11日 15:25 (UTC)[回复]

让大家知道,我已经将已删除的 American colonialism 文章草稿移至我的用户空间,我也很乐意让其他人编辑。我想我们可以扩大范围,也包括美国向西扩张,以及纪念美洲原住民灭绝等事件的地点。我正在尝试添加实际提醒人们美国殖民统治遗产的地点列表,以便它可以被恢复到文章空间。 The dog2 (讨论) 2022年5月12日 15:17 (UTC)[回复]
那篇文章的受众是谁?你想象中会有哪个旅行者使用那本指南? WhatamIdoing (讨论) 2022年5月12日 15:49 (UTC)[回复]
它面向的是那些想看美国殖民统治在世界各地不同地区留下印记的人。有点像其他殖民帝国的文章。但正如 Ikan Kekek 所提到的,美国殖民主义很大一部分是向西扩张,通过灭绝美洲原住民,用白人定居他们的土地,然后在白人人口足够多的时候授予殖民地州权。所以,虽然我们已经有了一篇关于美国殖民主义这一方面的 Old West 文章,但我认为美国殖民主义的文章至少应该提及这一点,但文章的重点应该是列出你可以去探索美国殖民统治遗产的海外地点。 The dog2 (讨论) 2022年5月12日 17:12 (UTC)[回复]
有多少这样的人?
我可以很容易地想象出有人想了解一个国家的历史。例如,如果你对菲律宾感兴趣,那么你会对西班牙殖民(16至19世纪)、美国殖民(20世纪上半叶)和日本殖民(二战前后几年)感兴趣。我很难想象一个人会说“我的目标是去世界上所有<这个国家>曾经殖民过的地方”。没有旅行者的心理图景,很难假设什么样的信息可能对文章有用或相关。 WhatamIdoing (讨论) 2022年5月13日 16:08 (UTC)[回复]

征集选举志愿者

运动战略与治理团队正在寻找社区成员担任 即将举行的理事会选举 的选举志愿者。

选举志愿者计划的想法是在 2021 年维基媒体基金会理事会选举期间提出的。该计划被证明是成功的。在选举志愿者的帮助下,我们能够将选举的宣传和参与度提高了 1753 名选民,超过 2017 年。总投票率为 10.13%,比 2017 年高 1.1 个百分点,有 214 个维基参与了选举。2017 年未参与的 74 个维基在 2021 年选举中产生了选民。您能帮助改变今年的参与度吗?

选举志愿者将在以下领域提供帮助

  • 翻译简短信息并在社区渠道宣布选举进程
  • 可选:监控社区渠道的社区评论和问题

志愿者应

  • 在对话和活动中遵守友好空间政策
  • 以中立的方式向社区展示指导方针和投票信息

您想成为一名选举志愿者,以确保您的社区在投票中得到代表吗?在此 注册 以接收更新。您可以使用 讨论页 提出关于翻译的问题。

Zuz (WMF) (讨论) 2022年5月4日 17:12 (UTC)[回复]

2022 年 Wikivoyage 夏令营,科索沃和阿尔巴尼亚

大家好!

2022 年 5 月 20 日至 22 日,阿尔巴尼亚语维基媒体用户组将举办 2022 年 Wikivoyage 夏令营编辑马拉松,以改进科索沃和阿尔巴尼亚的旅游目的地内容。今年,我们将重点关注阿尔巴尼亚东南部,但欢迎所有改进。如果您与我们一起编辑,请于 5 月 20 日至 21 日(格林威治标准时间+2)上午 9:30 至下午 17:00 在 Jitsi 上加入我们。这里是 阿尔巴尼亚科索沃 的探险页面。您也可以不加入通话而进行编辑。请在 Outreach Dashboard 上注册以跟踪编辑马拉松的贡献。谢谢! --Vyolltsa (讨论) 2022年5月13日 08:08 (UTC)[回复]

太棒了!我这次参加不了,但祝你们一切顺利,也感谢该团队使这个活动成功举办.--ThunderingTyphoons! (讨论) 2022年5月13日 11:43 (UTC)[回复]
感谢 @ThunderingTyphoons! Vyolltsa (讨论) 2022年5月17日 09:13 (UTC)[回复]
@Vyolltsa: 期待!虽然我对阿尔巴尼亚和科索沃知之甚少。你能检查一下“外展仪表板”链接吗?它似乎已损坏。 OhanaUnited讨论页 2022年5月15日 05:08 (UTC)[回复]
太好了!很高兴知道这还将持续一年。 --来自 Selfie City (讨论) (贡献) 2022年5月15日 10:54 (UTC)[回复]
@OhanaUnited 你好!我发送“外展仪表板”链接给你!谢谢! Vyolltsa (讨论) 2022年5月17日 09:14 (UTC)[回复]

能否有人帮助我们更新阿尔巴尼亚科索沃探险页面的最新统计数据?谢谢! Arianit (讨论) 2022年5月21日 09:32 (UTC)[回复]

我更新了5月13日——上周(但我忘了更新“update”参数)。我将在编辑马拉松结束后再次更新。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月21日 10:56 (UTC)[回复]
如果我没记错的话,目前的统计数据似乎已经过时了。我们将不胜感激你能更新,以便我们可以使用“遗漏部分”表格来处理它们。 Arianit (讨论) 2022年5月21日 13:13 (UTC)[回复]
你说的是表格底部吗?表格底部不知何故不再起作用了。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月21日 13:31 (UTC)[回复]
是的,好吧。
感谢大家的支持。希望已经完成了一些好的工作,并且清理工作不是很麻烦。我们有5-6位全新的参与者。 Arianit (讨论) 2022年5月23日 07:36 (UTC)[回复]
已经结束了?是的,我看到了很多优秀的全新内容。谢谢! Ikan Kekek (讨论) 2022年5月23日 07:38 (UTC)[回复]
@Arianit: 我刚刚又做了一次更新,但我不确定科索沃探险上的数字是怎么回事。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月23日 08:07 (UTC)[回复]

关于桌面改进的讨论

大家好!

你是否注意到一些维基有不同的桌面界面?你对下一步有好奇吗?也许你对设计或技术问题有疑问或想法?

加入一个在线会议,与负责桌面改进的团队见面!会议将于2022年5月17日 12:00 UTC19:00 UTC 在Zoom上举行。点击此处加入。会议ID:86217494304。按您的位置拨号

议程

  • 近期进展更新
  • 问答环节,讨论

形式

会议不会被录制或直播。笔记将保存在一个Google Docs文件中。Olga Vasileva(产品经理)将主持本次会议。演示部分将以英语进行。

我们可以回答以英语、意大利语、波兰语提出的问题;此外,仅在第一次会议中:波斯语、越南语;仅在第二次会议中:葡萄牙语、西班牙语、俄语。如果您想提前提问,请在讨论页上添加,或发送至sgrabarczuk@wikimedia.org。

本次会议将同时适用友好空间政策和Wikimedia技术空间的行为准则。Zoom不受WMF隐私政策的约束。

我们期待您的到来! SGrabarczuk (WMF) (讨论) 2022年5月14日 05:02 (UTC)[回复]

免责声明:Szymon(又名User:Tar Lócesilion)是我工作中的一名队友。我还没有和他谈过这件事,他也不知道我在这里发帖。
我一直在考虑将“新Vector”(Vector 2022)改为这个。我认为 Wikivoyage 应该进行这次更改。一些最近(以维基百科为中心)的市场调研表明,读者认为旧的设计(Vector 2010)已经过时。切换可能需要一点工作(显然,我们会想仔细检查页面横幅等关键功能),而且任何重大更改都需要个人(即阅读此页的我们)一两周的时间来适应。但当我想到这个社区的价值观时,看起来像一个现代化、最新且易于与竞争对手区分的网站,是我们在乎的事情之一,采用这项更改将是实现我们目标和支持团体价值观的直接途径。
如果您想看看它现在的样子,请点击https://wikivoyage.cn/wiki/Turin?useskin=vector-2022。如果您想看看它在没有新的浮动目录的情况下是什么样子,请点击https://wikivoyage.cn/wiki/Turin?useskin=vector-2022&tableofcontents=0
我不知道团队的部署流程是什么(如果你愿意,我可以问 Szymon),但既然它已经在许多维基上部署了,包括法语维基百科,我猜任何表示“我们已经看过了,我们想让你把我们列入下一批”的社区都会被接受。WhatamIdoing (讨论) 2022年5月15日 16:29 (UTC)[回复]
左侧边栏菜单在狭窄窗口中向下推内容是一个必须解决的问题,因为它会影响很多人。这个皮肤真的经过了充分测试,可以投入生产,使其“看起来像一个现代化、最新的”皮肤吗?Wikivoyage的用户可能从奇怪的硬件上通过不稳定的连接访问该网站,因此应该思考如何检查其功能。–LPfi (讨论) 2022年5月15日 17:37 (UTC)[回复]
我点击了“<<”来隐藏左侧边栏菜单(我认为这是默认设置?),所以我看不到那个。我认为最好的测试方法是让编辑者使用两周。如果需要,我们可以向phab:提交错误报告。 WhatamIdoing (讨论) 2022年5月15日 18:16 (UTC)[回复]
我认为它在实施之前需要更好的测试。如果我没记错的话,在主页地图上,尼泊尔或斯里兰卡以东的任何地方都会被裁剪掉。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月16日 06:26 (UTC)[回复]
是的,当我查看时,它确实被裁剪了。这可能是他们“固定宽度”设计的结果。不过,这应该是可以修复的。 WhatamIdoing (讨论) 2022年5月16日 16:11 (UTC)[回复]

“Infact”

我刚刚从这个网站上删除了所有“infact”的实例。请不要再添加了。 :-) 这个表达是“in fact”,两个词,但通常可以省略。 Ikan Kekek (讨论) 2022年5月22日 20:26 (UTC)[回复]

@Ikan Kekek 谢谢你的编辑 :-) 我必须承认我有一个坏习惯,就是把“in fact”写成一个词(我刚才差点又写了),但谢谢你的修正。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月23日 08:10 (UTC)[回复]
当然。并非所有相关编辑都是你做的。 :-) Ikan Kekek (讨论) 2022年5月23日 09:06 (UTC)[回复]

帮助存档一个讨论页

请问有人能帮我存档保加利亚讨论页吗?我已经将旧的评论复制到一个子页面并链接到主讨论页,你们只需要删除旧的讨论。我做不到,因为我太新了,尝试这样做会触发页面清空过滤器。我想开始一个新的关于地区的讨论,但旧的讨论页上的内容已经让它变得难以管理。 Daggerstab (讨论) 2022年6月17日 16:59 (UTC)[回复]

完成了。 Daggerstab (讨论) 2022年6月17日 17:12 (UTC)[回复]
如果你想讨论地区,我们应该重新开启之前的地区讨论。 Ikan Kekek (讨论) 2022年6月17日 17:54 (UTC)[回复]

关于桥梁的文章

我想知道这里是否有工程师能够撰写一篇关于著名桥梁的文章。当然,立即想到的有纽约的布鲁克林大桥、伦敦的塔桥、旧金山的金门大桥和悉尼海港大桥,但我相信还有无数其他桥梁可以被提及。 The dog2 (讨论) 2022年6月20日 20:12 (UTC)[回复]

桌面改进更新

将此设为新的默认项

你好。我想向你更新一下桌面改进项目,Wikimedia基金会网络团队已经为此工作了几年。我们的工作基本完成了!🎉

我们希望看到这些改进成为所有维基上读者和编辑者的默认设置。在接下来的几周里,我们将开始与更多维基(包括你们的维基)进行对话。🗓️ 我们很乐意听取您的建议!

该项目的目标是使界面对读者更具吸引力、更舒适,并对高级用户更有用。该项目包括一系列功能改进,使阅读和学习、页面内导航、搜索、语言切换、使用文章标签和用户菜单等更加容易。改进已经在30多个维基上对读者和编辑者默认可见,包括法语葡萄牙语波斯语的维基百科。

这些更改仅适用于Vector皮肤,尽管始终可以选择单独恢复到以前的版本。 MonobookTimeless 用户将不会注意到任何变化。

最新功能
  • 目录 - 我们的版本更容易访问,可以了解页面上下文,并且可以在不滚动的情况下浏览页面。它目前正在我们的试点维基上进行测试。对于已选择Vector 2022皮肤的编辑者来说,它也可用。
  • 页面工具 - 现在,侧边栏中有两种类型的链接。有针对单个页面的操作和工具(如相关更改)和适用于整个维基的链接(如最近更改)。我们将把它们分成两个直观的菜单。
如何启用/禁用这些改进
全局偏好设置
  • 可以通过在偏好设置中的外观选项卡中选择“Vector (2022)”来单独选择加入。此外,还可以使用全局偏好设置在所有维基上选择加入。
  • 在对所有人可见更改的维基上,已登录用户始终可以选择退出旧版Vector。新Vector的侧边栏中有一个易于访问的链接。
了解更多并参加我们的活动

如果您想跟踪我们项目的进展,可以订阅我们的新闻通讯。您可以阅读项目页面,查看我们的常见问题解答,在项目讨论页上留言,并加入我们的在线会议

谢谢! SGrabarczuk (WMF) (讨论) 2022年6月21日 16:59 (UTC)[回复]

谢谢。
我们的大多数页面都使用页面横幅模板来显示目录,而不是标准方法。这会受到你提议的更改的影响吗? AlasdairW (讨论) 2022年6月21日 18:58 (UTC)[回复]
在当前版本中,它们似乎相处得很好。页面横幅仍然有效,但侧边栏有一个额外的目录。你可以通过在你的偏好设置中启用Vector (2022)来自己尝试。 El Grafo (讨论) 2022年6月22日 14:22 (UTC)[回复]
尝试一下
WhatamIdoing (讨论) 2022年6月22日 17:31 (UTC)[回复]
谢谢。看起来不错。
查看一个示例页面,它确实显示文章所占的页面宽度略少,留给左侧列的宽度更多,但我没有深入研究,而且外观上的差异可能是一种改进。 AlasdairW (讨论) 2022年6月22日 20:49 (UTC)[回复]
周二加入我们

加入一个在线会议,与负责桌面改进的团队见面!会议将于2022年6月28日 12:00 UTC19:00 UTC 在Zoom上举行。点击此处加入。会议ID:5304280674。按您的位置拨号。以下活动将于7月12日和7月26日举行。

会议不会被录制或直播。笔记将保存在一个Google Docs文件中,并复制到EtherpadOlga Vasileva(产品经理)将主持本次会议。演示部分将以英语进行。本次会议将同时适用友好空间政策和Wikimedia技术空间的行为准则。Zoom不受WMF隐私政策的约束。

我们可以回答以英语提出的问题,以及多种其他语言。如果您想提前提问,请在讨论页上添加,或发送至sgrabarczuk@wikimedia.org。我们期待您的到来! SGrabarczuk (WMF) (讨论) 2022年6月23日 21:44 (UTC)[回复]

我刚刚在这里发布了一个新主题,并立即进行了编辑。请看
https://wikivoyage.cn/w/index.php?title=Wikivoyage%3ATravellers%27_pub&type=revision&diff=4472722&oldid=4472721 Ottawahitech (讨论) 2022年6月25日 15:22 (UTC)[回复]
@SGrabarczuk (WMF),@WhatamIdoing Ottawahitech (讨论) 2022年6月25日 15:22 (UTC)[回复]
这需要work-me提交一个Phab门票。谢谢告知。我很好奇:你在打字时是否能看到视觉编辑器中的<blockquote>标签?你是粘贴进来的,还是输入的,还是使用了键盘快捷键? WhatamIdoing (讨论) 2022年6月26日 05:25 (UTC)[回复]
感谢你的及时回复@WhatamIdoing,信不信由你,我对此事件的记忆已经模糊了。我知道我最初输入了< blockquote >标签,但我可能后来复制粘贴了(如果我不得不在发布半成品帖子之前去别处调查,我有时会这样做)。
我自从发现以来,还在wiki-voyage上实现的这个版本的软件(它与其他我参与的wmf维基不同)有两个可选的输入模式(未记录?)
  • 视觉
  • 来源
我认为我最初默认被设置为视觉模式,但现在我默认是源代码模式,而且我还看到一个以前不存在的预览窗格,我想?如果我能添加一个编辑摘要,那将是很好的,我可以使用 elsewhere 的“shall-we-call-it-reply”软件来做到这一点。
我希望我的这个混乱的回复有意义? Ottawahitech (讨论) 2022年6月26日 14:41 (UTC)[回复]
点击版权/许可声明上方的“高级”选项。大多数人不会在讨论中使用有意义的/自定义的编辑摘要,但如果你想的话,可以添加一个。 WhatamIdoing (讨论) 2022年6月26日 19:18 (UTC)[回复]
编辑摘要对于讨论也非常有用,尤其是在像“pub”这样繁忙的页面上。通常情况下,有些讨论串已经偏离了不那么有趣的路径,我只在有人提出新观点(在编辑摘要中提及)时才会阅读它们。当几个讨论串都有新帖子时,我可能会错过一些,除非编辑摘要引起了我在监视列表中的注意。而最令人恼火的是:在不告知摘要的情况下修改现有帖子——我向下滚动到讨论串的末尾,找不到新的内容,检查之前的缩进帖子,也没有找到,搜索今天的日期,不匹配,然后点击历史和差异,最后发现措辞的更改或其他什么,这通常没有给已经读过的内容增加任何价值。请写“ce”或别的什么。–LPfi (讨论) 2022年7月1日 12:38 (UTC)[回复]

运动战略与治理新闻 - 第7期

运动战略与治理新闻
第7期,2022年7月-9月阅读完整新闻通讯


欢迎阅读第七期运动战略与治理新闻!本新闻通讯分发有关实施Wikimedia的运动战略建议,其他有关运动治理的主题,以及Wikimedia基金会运动战略与治理(MSG)团队支持的不同项目和活动。

MSG新闻通讯每季度分发一次,而更频繁的每周运动战略更新将每周分发。请记住,如果您想收到本新闻通讯的未来各期,请在此订阅

  • 运动可持续性:Wikimedia基金会年度可持续性报告已发布。(继续阅读
  • 改善用户体验: Wikimedia项目桌面界面的近期改进。(继续阅读
  • 安全与包容:有关普遍行为准则执行指南修订过程的更新。(继续阅读
  • 决策公平性:关于Hubs试点对话的报告、运动章程起草委员会的最新进展,以及一份关于Wikimedia运动参与未来的新白皮书。(继续阅读
  • 利益相关者协调:启动了一个面向致力于内容合作伙伴关系的联盟和志愿者社区的帮助台。(继续阅读
  • 领导力发展:关于巴西和佛得角Wikimedia运动组织者的领导力项目的更新。(继续阅读
  • 内部知识管理:推出了一个新的技术文档和社区资源门户。(继续阅读
  • 创新免费知识:高质量的科学实验视听资源和一个用于记录口述实录的新工具包。(继续阅读
  • 评估、迭代和适应:公平性景观项目试点结果(继续阅读

其他新闻和更新:一个新的论坛讨论运动战略实施,即将举行的Wikimedia基金会理事会选举,一个新的播客讨论运动战略,以及基金会运动战略与治理团队的人员变动。(继续阅读

Zuz (WMF) (讨论) 2022年7月18日 22:58 (UTC)[回复]

宣布2022年度理事会选举六名候选人

大家好,

联盟代表已完成其投票期。选出的2022年度理事会候选人为

您可以在结果统计数据中看到有关本次理事会选举的更多信息。

联盟组织选出了代表来代表联盟组织进行投票。联盟代表们提出了问题,供候选人在六月中旬回答。候选人的这些回答以及分析委员会提供的信息,为代表们做出决定提供了支持。

请花些时间感谢参与此过程的联盟代表和分析委员会成员,他们帮助扩大了理事会的容量和多样性。这些志愿工作时数跨越了理解和视角。感谢您的参与。

感谢各位社区成员,他们将自己推举为理事会候选人。考虑加入理事会不是一个小决定。候选人迄今为止所表现出的时间和奉献精神,体现了他们对这个运动的承诺。祝贺那些被选中的候选人。对那些未被选中的候选人表示极大的赞赏和感谢。请继续与Wikimedia分享您的领导才能。

选民现在可以做什么?

查看联盟选择过程的结果.

在此处阅读更多关于2022年度理事会选举后续步骤的信息.

顺颂,

运动策略与治理

此消息由理事会选举工作组和选举委员会代表发送</translate>

Zuz (WMF) (讨论) 2022年7月20日 19:32 (UTC)[回复]

另类独立文化

有人知道任何 Wikivoyage 语言的另类独立文化指南吗? --Zblace (讨论) 2022年7月21日 19:59 (UTC)[回复]

正如我在跨语言休息室所说,我不知道有任何,这听起来是一个旅行话题,也许你想开始一个,但首先,你说的另类独立文化是什么意思?你想涵盖世界的哪个部分? Ikan Kekek (讨论) 2022年7月21日 20:16 (UTC)[回复]
@Ikan Kekek 谢谢:-) 我在那里回答了那里:“我的计划是涵盖克罗地亚的俱乐部(不同风格)和非商业(甚至反商业)的社会文化中心。我有一个朋友也对为斯洛文尼亚做这件事感兴趣。我们很乐意看到在其他地方也做类似的事情。”
@各位——我很有兴趣在不同的语言实例上完成这项工作,但我不知道它们之间的差异,所以可能会在孵化器中进行实验和“创新”。
-- Zblace (讨论) 2022年7月24日 06:50 (UTC)[回复]
这似乎是一个可能的旅行话题,但对我来说,完整的列表应该放在俱乐部所在的城市的文章中。 Ikan Kekek (讨论) 2022年7月24日 08:08 (UTC)[回复]

为选举指南针声明投票

您可以在Meta-wiki上找到此消息的多种语言翻译。

大家好,

2022年度理事会选举的志愿者们被邀请到Meta-wiki上为选举指南针中要使用的声明投票。您可以在Meta-wiki上为您想包含在选举指南针中的声明投票。

选举指南针是一个工具,旨在帮助选民选择与他们的信仰和观点最一致的候选人。社区成员将通过李克特量表(同意/中立/不同意)提出候选人需要回答的声明。候选人对声明的回答将被载入选举指南针工具。选民将通过回答声明(同意/不同意/中立)来使用该工具。结果将显示与选民信仰和观点最一致的候选人。

选举指南针的时间表如下:

  • 7月8日-20日:志愿者为选举指南针提出声明
  • 7月21日-22日:选举委员会审查声明的清晰度并删除离题声明
  • 7月23日-8月3日:志愿者对声明进行投票
  • 8月4日:选举委员会选择前15名声明
  • 8月5日-12日:候选人表明自己与声明的立场
  • 8月16日:选举指南针开放供选民使用,以帮助指导他们的投票决定

选举委员会将在八月初选择前15名声明


顺颂,

运动策略与治理

此消息由理事会选举工作组和选举委员会代表发送

Zuz (WMF)讨论2022年7月26日 17:26 (UTC)[回复]

推迟2022年维基媒体基金会董事会选举

大家好,

今天我来向大家通报董事会选举投票时间安排的最新情况。

正如大家可能已经知道的,今年我们提供了一个选举指南,以帮助选民了解候选人在一些关键议题上的立场。一些候选人要求延长其职位陈述的字符限制,选举委员会认为他们的理由符合公平和公正选举流程的目标。

为了确保更长的陈述能够及时翻译并用于选举,选举委员会和董事会遴选工作组决定将董事会选举的开始时间推迟一周——这是选举支持人员提出的理想时间。

尽管并非所有人都期望利用选举指南来指导投票,但选举委员会认为,在开放投票期时提供关键的翻译内容,以便社区成员跨语言使用,是更合适的做法。

投票将于UTC时间8月23日00:00开始,并于9月6日23:59结束。

此消息的其他语言翻译请在此查阅。

此致,

代表选举委员会

Zuz (WMF)讨论2022年8月16日 09:17 (UTC)[回复]

邀请加入运动战略论坛

大家好,

运动战略论坛】(MS论坛)是一个多语言协作空间,用于讨论运动战略实施的所有相关事宜。它为分享您的运动战略(MS)工作、寻找合作者、以及为您的MS项目获得更多支持和想法提供了绝佳机会。我们邀请所有运动参与者在MS论坛上进行协作。论坛的目的是利用包容性的多语言平台建立社区协作。

运动战略】是一项协作努力,旨在构想和构建维基媒体运动的未来。任何人都可以为运动战略做出贡献,从评论到全职项目。

请使用您的维基媒体账户加入此论坛,在此处打个招呼,然后加入或开始讨论您最感兴趣的建议!您可以随意讨论您的MS项目想法和计划,甚至是您已经完成的MS项目的报告。您可以观看此视频以开始。

运动战略与治理团队(MSG)于5月启动了此MS论坛的提案。经过2个月的评审期,我们刚刚发布了社区评审报告。其中包含讨论摘要、指标和后续步骤信息。

期待在MS论坛上见到您!

此致,

Zuz (WMF)讨论2022年8月19日 09:38 (UTC)[回复]

2022年董事会选举社区投票期现已开放

此消息的其他语言翻译可在Meta-wiki查阅。

大家好,

2022年董事会选举的社区投票期现已开放。以下是一些有用的链接,可帮助您获取投票所需的信息。

如果您已准备好投票,请前往SecurePoll投票页面进行投票。**您可以在UTC时间8月23日00:00至9月6日23:59之间投票。**要了解您的投票资格,请访问投票资格页面

顺颂,

运动策略与治理

此消息由理事会选举工作组和选举委员会代表发送

Zuz (WMF)讨论2022年8月23日 21:10 (UTC)[回复]

糟糕的旅行建议

Reddit评选出的15条最糟糕旅行建议 Pashley讨论2022年8月26日 03:20 (UTC)[回复]

他们将其宣传为最糟糕的旅行建议,足以毁掉你的行程,但他们给了什么:他们告诉我带件夹克,结果我一直很热;他们让我尝试当地食物,结果我拉肚子;有人说他们住的城镇很无聊,所以我就没去新西兰。看来作者有个好想法,但他们在半小时内没找到任何恐怖故事。
不过,我们可能需要检查一下旅行基本常识及相关文章中的一些内容,比如打包多少行李、是否应该尝试融入当地文化,以及是否应该参观主要城市还是“真实的”乡村地区。看来人们真的可能弄反了。
LPfi讨论2022年8月26日 06:00 (UTC)[回复]
新西兰的建议让我很费解,尤其是“无事可做,无处可去”,这让我觉得很荒谬(而且我敢说这是世界上最美丽的国家之一)。 SHB2000 (讨论 | 贡献 | Meta) 2022年8月26日 06:13 (UTC)[回复]
Reddit用户说,给出建议的人是他们可以预料到的那种类型(但他们当时没意识到)。没有提到她住在哪个城镇,也许是因为那里没有什么夜生活,而且她不喜欢自然风光。因为在新西兰你会找到一个无聊的地方,所以就避开新西兰?也许原始帖子更有意义,但这篇文章太荒谬了。从中可以学到的也许是,人们喜欢不同的东西,你不应该相信一个随机的人的建议,尤其是如果它含糊不清的话。这应该是显而易见的,但似乎并非如此。–LPfi讨论2022年8月26日 07:08 (UTC)[回复]
这篇文章就是当真正的记者被刷Reddit取代后会发生什么。——ThunderingTyphoons!讨论2022年8月26日 07:53 (UTC)[回复]
纯粹的点击诱饵,不值得关注。/Yvwv讨论2022年8月26日 09:31 (UTC)[回复]
作为一个在Reddit上花了很多时间的人,我可以确认,为了赚取karma而发布吸引眼球、点击诱饵式的内容非常普遍。 SHB2000 (讨论 | 贡献 | Meta) 2022年8月26日 09:49 (UTC)[回复]

2022年董事会选举社区投票即将结束

您好,

2022年董事会选举的社区投票期已于2022年8月23日开始,并将于2022年9月6日23:59 UTC结束。您仍然有机会参与本次选举。如果您尚未投票,请访问SecurePoll投票页面进行投票。要了解您的投票资格,请访问投票资格页面。如果您在做决定时需要帮助,以下是一些有用的链接:

顺颂,

运动策略与治理

Zuz (WMF)讨论2022年8月30日 12:22 (UTC)[回复]

《普遍行为准则》执行草案指南修订版

大家好,

《普遍行为准则》执行指南修订委员会】正在征求对【《普遍行为准则》(UCoC)修订执行草案指南】的意见。本次评审期为2022年9月8日至2022年10月8日。

委员会在社区于5月至7月进行的讨论以及于2022年3月结束的社区投票基础上,协作修订了这些草案指南。修订集中在以下四个领域:

  1. 确定UCoC培训的类型、目的和适用性;
  2. 简化语言,以便更容易翻译和非专家理解;
  3. 探讨确认的概念,包括其优缺点;
  4. 审查指控人与被指控人隐私的平衡。

委员会要求在2022年10月8日前提出意见和建议。之后,修订委员会预计将根据社区意见进一步修订指南。

在Meta上查找修订版指南,以及一些语言的比较页面

所有人可以在多个地方分享意见。协调员欢迎在修订指南讨论页上以任何语言发表意见。意见也可以在翻译版本的讨论页、本地讨论或交流时间分享。已计划就UCoC执行草案指南进行现场讨论;请参阅Meta上的时间与详情:交流时间

支持本次评审期的协调团队希望触及广泛的社区。如果您所在的社区没有进行讨论,请自行组织一次。协调员可以协助您安排讨论。讨论将每两周进行一次总结并提交给起草委员会。总结将在此处发布。

Zuz (WMF)讨论2022年9月8日 13:53 (UTC)[回复]

图片

大家好。我是Work-me,我有一个建议,希望一些Wikivoyage的志愿者能成为某个开发团队的“测试维基”。

背景:网页浏览器不“懂”维基文本。它们懂HTML。所以我们用维基文本书写,然后它会被转换(“解析”)成HTML。我们看到的东西,除了在维基文本编辑器内部,都是解析后的HTML。旧的解析器非常非常老旧(以软件术语来说),它正在被替换,用一个比较新的解析器来代替。旧的解析器没有正式名称,但传统上被称为“PHP解析器”(取自其编写的软件语言)。较新的解析器称为“Parsoid”。新的解析器基本上做了同样的事情,外加一些额外的功能,并去除了几个旧的bug(当然也可能增加了一些新的bug,但那些技术上不属于计划的一部分 ;-))。

项目:最终,旧的PHP解析器将被删除,Parsoid将取而代之。他们最近一直在研究它如何处理图片(主要Phab任务:T314318)。图片部分已经在mw:上运行,并且看起来效果不错。我在那里做了一些相当复杂的操作(例如,翻译页面的图库),没有任何问题。事实上,我甚至没有注意到他们切换了解析器。这应该是一个无缝的过渡,我在这方面也体验到了。他们希望在更多维基上进行尝试。

我的想法:我认为我们应该自愿参与。首先,这个东西最终会在这里出现,所以从一开始就让它为我们工作是更好的。我不希望Wikivoyage,它在图片方面有一些特殊用法(例如页面横幅),事后才被考虑。其次,如果现在出现问题,我们将在修复列表的最前面,并且有一支开发团队随时提供帮助(或者如果无法立即修复,则可以立即恢复到旧的解析器)。这种手把手的支持只有在我们是部署列表中的第三位时才能发生,而如果我们处于通常的部署流程中,当他们认为工作已完成后,则不太可能发生。从实际角度来说,如果你在同一天将软件部署到500个维基上,如果出现问题,它们不可能都是首要任务。但如果你是本周唯一的,那么你自然是首要任务。第三,这个团队在工作中非常谨慎。他们有一个系统可以识别整个页面中仅仅一个像素的改变!所以我认为我们会得到很好的照顾。

所以我在问大家:你们愿意让我们走在最前面吗?如果大家觉得没问题,我就可以正式向团队提出申请,让他们考虑我们。 Whatamidoing (WMF)讨论2022年8月24日 04:49 (UTC)[回复]

支持。根据WV:IP,我们通常不使用很多图片,所以一项重大更改不会影响很多页面。很高兴开发人员将此维基列为优先事项,鉴于您已经说服了我,我全支持此提案。 SHB2000 (讨论 | 贡献 | Meta) 2022年8月24日 08:15 (UTC)[回复]
尽管“图片使用量很少”,但我们几乎所有旅行指南页面都有图片,所以如果出现任何重大问题,它会影响很多页面。但如果真的有问题,最好能得到开发人员的全力关注,对吧?既然无论如何我们都会面对,那么支持成为试用者的提议是合理的。——ThunderingTyphoons!讨论2022年8月24日 08:36 (UTC)[回复]
@ThunderingTyphoons!: 尽管大多数文章是纲要,很少使用图片(而en.voy的大部分文章都是纲要),但我同意这会影响很多页面。也许我们都应该去给每篇文章添加大量的图片,让旅行指南更丰富多彩…… ;-) SHB2000 (讨论 | 贡献 | Meta) 2022年8月24日 09:16 (UTC)[回复]
我同意现在发现问题比以后发现要好。任何影响所有维基的重大问题,开发人员可能在推出更改之前就会注意到,而影响我们的问题可能只是小故障或与页面横幅相关的问题,这些问题要么不会造成灾难,要么在Wikivoyage启用之前不会被注意到。但我不支持在每篇文章中添加大量图片,我们已经足够注意到问题了,除非是关于图片的不寻常用法,我想维基百科或维基教科书会处理这个问题。–LPfi讨论2022年8月24日 09:32 (UTC)[回复]
每篇文章都有页面横幅(所以几乎所有文章,包括没有自定义横幅的文章),至少有一张图片,所以我坚持我的说法。但任何与图片相关的问题都不太可能影响文章主体,所以这是一个“值得冒的风险”——ThunderingTyphoons!讨论2022年8月24日 09:43 (UTC)[回复]
哦,是的,我怎么会忘了页面横幅。 SHB2000 (讨论 | 贡献 | Meta) 2022年8月24日 09:44 (UTC)[回复]
@LPfi:我说“也许我们都应该去给每篇文章添加大量的图片,让旅行指南更丰富多彩……”是开玩笑,为了缓和讨论——本来应该是反话。你真的认为我说的是认真的吗? SHB2000 (讨论 | 贡献 | Meta) 2022年8月24日 09:44 (UTC)[回复]
不,不完全是。抱歉。我只是对在短文章中堆积大量图片(有些在wp-sv上)产生了过敏反应,所以没能领会这个笑话。–LPfi讨论2022年8月24日 10:15 (UTC)[回复]
不用道歉。重读我之前的评论,它确实有些讽刺意味,但我也厌倦了某个用户认为用图片填满整个文章是件好事,或者毫无意义的画廊SHB2000 (讨论 | 贡献 | Meta) 2022年8月24日 10:19 (UTC)[回复]
支持。Whatamidoing的论点非常有说服力。 Vidimian讨论2022年8月24日 22:39 (UTC)[回复]

请求更改

感谢支持。如果我拥有编辑任何可能因更改而损坏的界面所需的权限,那将会很有帮助/高效。例如,我已准备好以下更改请求:Template_talk:Banner#Prepare_for_T314318。但我很乐意与任何能够协助更改的编辑者合作。 Arlolra讨论2022年9月13日 21:54 (UTC)[回复]

Arlolra是来自mw:Parsoid团队的Arlo Breault。我毫不夸张地说:这些人比世界上任何人都更了解维基文本如何被转换为读者在屏幕上看到的内容。我们确实应该接受他为我们修复东西的提议。我认为管理员权限就足够了,但可能在某个时候需要interface_admin权限。 WhatamIdoing讨论2022年9月14日 15:46 (UTC)[回复]
感谢WhatamIdoing的介绍,这非常必要。你想在WV:URN提名Arlo吗?——ThunderingTyphoons!讨论2022年9月14日 20:06 (UTC)[回复]
这会不会有利益冲突? WhatamIdoing讨论2022年9月15日 23:44 (UTC)[回复]
由于没有进一步的评论,我已发布Wikivoyage:用户权限提名#ArlolraWhatamIdoing讨论2022年9月21日 02:07 (UTC)[回复]

已部署

更改已部署,现已上线https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/830707。如果出现任何中断,请告知我们。谢谢。 Arlolra讨论2022年9月21日 13:24 (UTC)[回复]

InternetArchiveBot

InternetArchiveBot已经开始在这里编辑页面。我认为其中一些是有用的,但在许多情况下,死链可能比存档页面更有用。餐厅的死链警告该地方可能已关闭,我预计大多数读者在参观前会进行其他检查,但如果他们没有注意到存档横幅,他们会看到去年的菜单并假设该地方还营业。

在“了解”等背景信息中存档链接可能有用,但在“餐饮”或“住宿”中可能没用。在死链后面提供存档页面可能有用,并附带解释:例如,时刻表(死链,存档页面)。 AlasdairW讨论2022年9月11日 22:30 (UTC)[回复]

Alasdair,我同意你关于风险的看法,我暂时禁用了该机器人。 Ocaasi, Cyberpower678, Harej,你们为什么在这里运行User:InternetArchiveBot?你们在其他Wikivoyage上运行它吗?请看Wikivoyage:欢迎,维基百科人#风格差异:“Wikivoyage文章不使用参考文献。”因此,这个维基上没有可以供机器人救援的来源。我认为机器人不应该在任何Wikivoyage上添加archive.org链接。
如果,另一方面,你们愿意添加{{死链}}(这会将文章归类到Category:带有死链的条目),那么我想一些编辑者可能会觉得有用。 Whatamidoing讨论2022年9月12日 05:30 (UTC)[回复]
我查看了机器人前五次编辑。全部不理想。有些需要删除(例如,似乎已关闭的渡轮服务);有些需要正确的链接(例如,新的域名或重新组织的网站)。没有一次编辑是机器人能够正确完成的。 Whatamidoing讨论2022年9月12日 05:42 (UTC)[回复]
不需要封禁机器人。它有一个内置系统可以在任何维基上禁用它。你甚至不需要管理员就可以做到。 SHB2000 (讨论 | 贡献 | Meta) 2022年9月12日 08:12 (UTC)[回复]
已回滚所有。我还要补充一点,该机器人还移除了死链标签,并声称用archive.org网址替换它们,这比没有更好SHB2000 (讨论 | 贡献 | Meta) 2022年9月12日 08:29 (UTC)[回复]
没必要封禁机器人。它有一个内置系统可以在任何维基上禁用它。你甚至不需要管理员就可以做到。 Whatamidoing讨论2022年9月12日 17:46 (UTC)[回复]
@WhatamIdoing: 我们没有意识到添加存档URL实际上对Wikivoyage不利。由于该机器人已被批准为全球机器人,并且enwikivoyage被列在允许它们使用的维基中,我们只是将其部署到了这个维基。这当然与SHB2000 (讨论 · 贡献)所说的相反,因为他们将机器人封禁为未经授权。无论如何,标记链接为死链似乎比将它们存档更受青睐。我们可以修改机器人以适应这一点。——CYBERPOWER (聊天) 2022年9月12日 12:49 (UTC)[回复]
@WhatamIdoing: 我认为Wrh2的机器人已经做了同样的事情(虽然目前没有运行)。 SHB2000 (讨论 | 贡献 | Meta) 2022年9月12日 08:30 (UTC)[回复]
我同意这些编辑不合适。感谢您回滚它们,SHB2000。机器人标记死链供人工审核是有用的,但自动用存档副本替换它们会导致过时信息不被注意。这是旅行指南(包含需要经常更新的实用建议)和百科全书(包含通常具有历史性质的事实陈述)之间的巨大区别。——Granger 讨论 · 贡献2022年9月12日 09:34 (UTC)[回复]
如果Ryan的机器人目前没有运行,而IABot可以现在执行此操作,我认为我们应该解除对该机器人的封禁,让它们为我们标记死链。为了避免任何潜在的混淆,我现在提到,如果一个网站宕机一小时,那么任何人(机器人或人类)都可能错误地认为它是一个死链。我们应该期望在这种工作中有一小部分误报。
@Cyberpower678,我认为您需要在使用所有Wikivoyage时使用“仅标记”模式,并注意Wikisources的命名空间。另外,我不认为本地模板技术上支持 `|date=` 参数,但我认为包含日期还是个好主意。我相信机器人已经这样设置了。 WhatamIdoing讨论2022年9月12日 15:55 (UTC)[回复]
该机器人通常在行为方面非常灵活。我需要做的就是添加一个选项,允许重新配置机器人仅执行标记工作,因为该机器人是基于“存档比死链更好”的原则设计的。这应该不会花太长时间来实现。我已在 phab:T317553 处提交了一个 Phabricator 工单来跟踪此项工作。—CYBERPOWER (聊天) 2022年9月12日 17:00 (UTC)[回复]
谢谢。我认为那会很有帮助。 WhatamIdoing (讨论) 2022年9月12日 17:36 (UTC)[回复]
是的,谢谢。—LPfi (讨论) 2022年9月13日 11:12 (UTC)[回复]

我看到 InternetArchiveBot 的仅标记功能正在测试中 — 请看 User:Cyberpower678/sandboxSHB2000,我认为该机器人现在可以解除封禁了,但我建议在进一步讨论之前,机器人每天只标记几页。 AlasdairW (讨论) 2022年9月30日 23:13 (UTC)[回复]

@AlasdairW: Yes 已完成SHB2000 (讨论 | 贡献 | meta) 2022年9月30日 23:34 (UTC)[回复]

我们回来了(亚洲学生作业)

各位维基旅行家们好!沉寂几年后,我又回来了,将带领一群(主要是韩国和中国的)学生来处理一些话题(您可以在公告栏的存档中找到我以前的一些公告和相关的讨论)。有兴趣的编辑者也可以查看我们的教学大纲 (tinyurl.com/wikivoydata) 和/或仪表板 (tinyurl.com/dashwikivoydata2022)。仪表板上还有学生名单(账号名)。我预计大部分活动将集中在与韩国和中国相关的话题上;我将一如既往地尽力确保编辑工作富有建设性等等,并提前为任何额外的工作道歉。希望像过去一样,我们将为这些地区带来一些新的或改进的文章。过去项目的成果请参见我维护的列表:https://en.wikipedia.org/wiki/User:Piotrus/Educational_project_results (CTRL+F Wikivoyage)。感谢您的接待:) Piotrus (讨论) 2022年9月15日 10:44 (UTC)[回复]

哦,又一次远征——听起来不错。如果需要的话,我愿意做任何清理工作,但谢谢你组织这次远征 :-) SHB2000 (讨论 | 贡献 | meta) 2022年9月15日 11:53 (UTC)[回复]
欢迎回来,Piotrus,也欢迎你的学生!在你的学生工作期间,你希望我们暂时停止哪些类型的编辑吗? Ikan Kekek (讨论) 2022年9月16日 00:02 (UTC)[回复]
@Ikan Kekek @SHB2000 谢谢!不用,照常进行 :) 理想情况下,在回退学生编辑时,最好在他们的讨论页或编辑摘要中留下解释,并通知我,以便我能提供自己的问题解释,在课堂上或以其他方式。根据我过去的经验,大多数学生并不期待维基百科志愿者的建设性反馈,甚至任何反馈,所以有些学生甚至没有意识到他们的编辑被回退了,即使意识到了,他们也不知道原因(特别是,请注意,大多数学生不会注意到编辑摘要中的评论,除非我单独指出该功能,或在课堂上多次展示)。顺便说一句,请注意,我的大多数学生在英语方面都有困难(尽管他们参加的是我教授的英语大学课程),所以请注意,一些编辑可能需要常规的语法/词汇校订(比我在母语为英语的国家授课时需要得更多)。 Piotrus (讨论) 2022年9月16日 03:06 (UTC)[回复]
没问题。我通常会尽量避免回退远征期间的编辑,除非是严重的版权侵犯和/或超出范围。如果需要,我很乐意尝试让文本更符合习惯用法。——SHB2000 (讨论 | 贡献 | meta) 2022年9月16日 05:38 (UTC)[回复]
@Piotrus: 你说得对,不仅仅是对你的学生,对新用户普遍来说,通过编辑摘要与他们沟通往往是徒劳的。我在所有维基上都看到过经验丰富的编辑这样做,他们经常链接到带有行话和缩写的政策,新用户对此一无所知。这不会让他们了解这里的规则和政策,如果1. 他们不知道什么是编辑摘要以及在哪里找到它们,2. 政策没有更清晰、更简单地解释(例如,即使新用户阅读了编辑摘要,回退一次编辑并输入WV:MOS也不会让用户去阅读样式手册)。这是我在校对新手编辑时尽量避免的事情。祝你的学生好运! Gizza (漫游) 2022年9月16日 06:12 (UTC)[回复]
@DaGizza 的确如此。我们在编辑摘要中写下的任何内容都是给其他有经验的编辑的消息,但期望新手用户注意到它是徒劳的。如果想与新手沟通,在他们的讨论页上留言是唯一合理的方法。在其他新闻中,学生们开始选择他们的主题。预期的名单中有1/3(2/3尚未决定)是济州岛束草大邱嘉兴潭阳军浦(需要创建,请看:wikipedia:Gunpo)、西双版纳……如果有人愿意从现在到年底一直关注它们 :) 我会在一周左右后报告其他主题。 Piotrus (讨论) 2022年9月16日 08:49 (UTC)[回复]
很好。只是提醒一下,你的 tinyurl 链接 (tinyurl.com/wikivoydata) 是坏的。如果他们希望在课程结束后扩展韩语和中文维基旅行文章,那将很有趣。我知道这超出了你的课程范围,但那些维基的状况比英语的要差。 OhanaUnited讨论页 2022年9月17日 06:07 (UTC)[回复]
@OhanaUnited 我的错,应该是 tinyurl.com/wikivoydata2022(我无法链接 URL,因为 tinyurl 和 google docs 在 MediaWiki 级别被列为垃圾链接或类似链接,唉)。请注意,没有活跃的韩语维基旅行项目。在我的维基百科课程中,我让学生编辑韩语和中文维基百科,但由于没有韩语维基旅行,我们只专注于英语维基旅行的 WV 课程。我希望有一天韩语 WV 能开始,也许是由我的一名学生开始,但到目前为止还没有…… Piotrus (讨论) 2022年9月19日 08:57 (UTC)[回复]
顺便说一句,目前在维基百科孵化器有一个韩语维基旅行项目——请看 incubator:Wy/ko/위키여행:대문。不过,它仍然需要大量的扩展。 SHB2000 (讨论 | 贡献 | meta) 2022年9月19日 11:09 (UTC)[回复]
@SBH2000 好的,我之前找到了它,但孵化器不是“实时的”;我放弃了向我的学生解释如何使用它的尝试(我认为那里的页面无法连接到维基数据,例如)。坦率地说,我认为我们把东西藏在那里是在害人 — 它应该是实时的,然后它就可以成长(例如,在我学生的帮助下,我每年都可以让他们写或翻译十几个以上的条目)。 Piotrus (讨论) 2022年9月19日 12:32 (UTC)[回复]
@SHB2000 哎呀,ping 错了用户…… Piotrus (讨论) 2022年9月19日 12:32 (UTC)[回复]
URL 缩短器在所有地方都被屏蔽了,因为它们往往受到垃圾邮件发送者的青睐。不过,我认为你可以直接链接到 Google Docs 的完整 URL。你的链接是 https://docs.google.com/document/d/1tdHX3H7_fQZSthOXGAXYWbVlVBPbkIyorXvjIa1rgaQ/editWhatamIdoing (讨论) 2022年9月19日 16:06 (UTC)[回复]

哦,对了,我差点忘了——有些人可能会觉得看看我的维基旅行 Prezis 很有趣(见 https://en.wikipedia.org/wiki/User:Piotrus/Sociology_course_prezis#Wikivoyage_and_Wikidata)。我可能会开发更多(欢迎提出想法!)--Piotrus (讨论) 2022年9月19日 13:58 (UTC)[回复]

@User:SHB2000, User:OhanaUnited, User:Ikan Kekek。更新学生选择的改进文章列表,供大家关注:大邱潭阳东豆川军浦华城行宫济州岛嘉兴晋中智异山国家公园莱芜连云港浦项莱茵河地区束草铜仁(贵州)威海西双版纳灵德郡张家界舟山。 --Piotrus (讨论) 2022年10月1日 06:50 (UTC)[回复]

感谢您提供文章列表。我一定会将其中至少一些放到监视列表中。如果你的学生想创建新文章,只要它们符合 WV:WIAA,请随时让他们去做。小城镇如果也是足够好的旅游目的地,也是受欢迎的。 --来自 Selfie City (讨论) (贡献) 2022年10月3日 14:40 (UTC)[回复]
谢谢这份列表。另外,对于常客:编辑冲突对于新手来说非常难以处理。请尽量不要在学生停止编辑之前就冲进文章。我不知道会从这组学生那里期待什么,但根据一些 enwiki 的研究,经验法则是一个没有在过去半小时内保存过编辑的人很可能已经离线了。 WhatamIdoing (讨论) 2022年10月3日 16:21 (UTC)[回复]

致 Wikimedia 基金会的公开信,以改进 Wikimedia Commons

有一封致 Wikimedia 基金会的关于 Wikimedia Commons 的公开信。如果您有兴趣(或像我一样对 Commons 感到沮丧),请看:Think big - open letter about Wikimedia Commons -- DerFussi 2022年10月12日 11:25 (UTC)[回复]

这只是巧合吗?我刚读到那封信的一半,就偶然发现了你的信息?无论如何,我已经在文件上签名了,希望这个社区的更多人也能签名。 SHB2000 (讨论 | 贡献 | meta) 2022年10月12日 11:46 (UTC)[回复]
大家好,我只是想在这里发个消息。:-) 谢谢 @DerFussi,也谢谢大家的支持! Ziko (讨论) 2022年10月14日 19:51 (UTC)[回复]
@Ziko: 我有大量消息发送权限。我们应该起草一条消息并发送给所有维基旅行公告栏。太晚了——下次吧 :) -- DerFussi 2022年10月14日 20:00 (UTC)[回复]

UCoC EG 社区评审期已结束

各位维基媒体人:

感谢您参与《通用行为准则修订执行指南草案》的评审。UCoC 项目团队和修订委员会感谢大家花时间讨论指南、提出修改意见和提问。

本次社区评审期从 2022 年 9 月 8 日持续到 10 月 8 日。在过去四周里,UCoC 项目团队通过各种渠道收集了宝贵的社区意见,包括三次对话会议,维基媒体人可以在会上聚集讨论修订后的 UCoC 执行指南。修订委员会将在 2022 年 10 月的第二周重新召开会议时审阅社区意见。UCoC 项目团队将支持他们,并在他们继续工作时提供更新,并将继续告知社区所有重要进展和里程碑,因为委员会正在准备 UCoC 执行指南的最终版本,目前计划在 2023 年 1 月中旬进行社区全员投票。

代表 UCoC 项目团队:

Zuz (WMF) (讨论) 2022年10月20日 11:39 (UTC)[回复]

正式的封锁回退政策

鉴于近期关于一名管理员是否滥用回退功能的问题,我决定起草一项关于User:SHB2000/rollback 的正式政策。它主要总结自Wikivoyage:User rights nominations#Misused rollbacks 和其他维基的各种正式回退政策,但主要概述了何时应该和不应该使用 RB,滥用的后果,以及关于手指滑动的简要说明。欢迎随意校对,但在此之前,它需要什么才能成为政策? --SHB2000 (讨论 | 贡献 | meta) 2022年10月6日 12:49 (UTC)[回复]

我认为我们不应该有这样的政策。
我认为我们实际上应该考虑完全不担心大多数形式的“滥用”回退。
回退和撤销之间的主要区别是
  • 是否可以添加自定义编辑摘要,以及
  • 是否可以批量回退每一次编辑(对于大量破坏页面的用户来说非常方便)。
就是这样。第二个(工具被创建的原因)几乎从不引起争议。
拟议政策实际上是在试图将以下两种情况进行区分,并大做文章:点击产生此内容的按钮
以及点击产生此内容的按钮
我认为,认为“回退编辑”和“撤销版本”之间的区别,或者“标签:回退”和“标签:撤销”之间的区别实际上有很大区别,那是在猜测回退滥用的问题实际上是:有时人们在我们认为应该添加自定义编辑摘要时却没有添加。
与此相关的是,我建议我们考虑上面在一个非常不同的上下文中发表的评论:“特别是,请注意,大多数学生不会注意到编辑摘要中的评论,除非我单独指出该功能,或在课堂上多次展示”。
所以:措辞差别不大,而且新手根本看不到措辞。我认为我们应该从 Wikivoyage:Administrators' handbook#Rollbacks 中移除“可能侮辱人”的说法(至少在我看来,不比撤销按钮更侮辱人),也许调整我们的观点,将回退归类为与 w:en:Wikipedia:Don't template the regulars 相同 — — 尽管这可能会冒犯一些有经验的编辑,他们已经吸收了 enwiki 在这个工具周围的文化包袱,并且偶尔会错失直接沟通和加强社交联系的机会,但它本身并不是一个有问题行为 per seWhatamIdoing (讨论) 2022年10月6日 16:42 (UTC)[回复]
是的,唯一的问题是,当有必要时(?),是否会向用户讨论页发送消息。用回退工具常规性地对第一次违反广告规则的用户进行操作,而大多数新用户不知道这些规则,并且不告知他们他们做错了什么,这是不好的。 Ikan Kekek (讨论) 2022年10月6日 18:59 (UTC)[回复]
我同意。这就是为什么我认为我们应该有一些政策禁止这种回退(请注意,{{tout}} 没有被放在这个用户的讨论页上)。 SHB2000 (讨论 | 贡献 | meta) 2022年10月6日 21:33 (UTC)[回复]
那么我们有两个问题:何时必须(?)在用户页面上放置通知,以及何时必须(?)留下一个默认值以外的编辑评论。当广告出现在明显错误的上下文中时,我还没有对此进行过处理,就像这样(它可能是垃圾邮件,但我也不去检查,只关注同一用户/IP在 WV 上的其他编辑)。后者当编辑不是正式的回退或撤销(这会给你一个提醒)时,而是在文章之间的编辑战中,是一个更大的问题。当然,在这种情况下,回退是一种侮辱,而且没有建设性,但至少它是显而易见的。—LPfi (讨论) 2022年10月7日 05:17 (UTC)[回复]
@LPfi: 这个页面还不完整,所以请大胆前进并按你的想法扩展草稿。我认为只有在命名空间 0(即主空间)中使用回退功能来处理广告时,警告才是必须的。 SHB2000 (讨论 | 贡献 | meta) 2022年10月7日 05:48 (UTC)[回复]

我认为这是向管理员解释何时以及何时不应使用回退功能的一份有用的文件。它基本上是对 Wikivoyage:Administrators' handbook 中这段粗略建议的详细阐述。

"回退是一种强硬(且可能令人反感)的措施,主要应用于破坏和垃圾信息。出于好意的编辑应在编辑摘要中进行解释后撤销。"

管理员曾用回退功能回退过我在内容或风格上的争执。我认为这是滥用管理员编辑权限,但如果没有详细的建议,就只能依靠一种不明确的“合适”与否的感觉。

我理解不愿制定过多政策来指导我们如何行事的想法,但当我还是个新手时,我非常沮丧,因为我以为合乎情理的编辑被管理员在没有评论的情况下回退了。当我质疑回退时,我被告知(大意是)“我们这里不这样做;你必须在这里花时间观察我们这个小社区是如何运作的”。没有政策,只有一种不成文的共识。这让我觉得自己像是闯入了一个私人俱乐部,我被容忍了,但不受欢迎。

我认为 SHB 的这份文件,经过一些编辑,将是 Wikivoyage:Administrators' handbook 的一个有用补充或附录,这将有助于新管理员(特别是)不滥用他们被赋予的这个了不起的权力。 Ground Zero (讨论) 2022年10月7日 08:01 (UTC)[回复]

我倾向于一个单独的页面,因为巡查员也有滥用此工具的可能性;我认为我们都知道有一个用户在 2020 年因公然滥用此工具来回退合法的善意编辑(他/她经常针对 GZ 的编辑进行攻击)而被剥夺了巡查员权限,现在在 enwiki 上被永久封禁。这也将使英语维基旅行与大多数其他 WMF 维基保持一致,根据 Q5148465 (Wikipedia:Rollback)SHB2000 (讨论 | 贡献 | meta) 2022年10月7日 08:09 (UTC)[回复]
GZ,问题是“在争执中使用回退按钮,但没有详细的建议”吗?“在争执中使用撤销按钮,但没有详细的建议”会感觉好吗? WhatamIdoing (讨论) 2022年10月7日 17:02 (UTC)[回复]
使用回退按钮更严厉,因为它由管理员一键完成,说“这是错误的,不值得考虑”。但我们也应该提供关于如何礼貌使用撤销功能的建议。 Ground Zero (讨论) 2022年10月7日 18:47 (UTC)[回复]
我只需要点击一次撤销按钮,我甚至都不是管理员。点击一次回退按钮比点击一次撤销按钮要严厉,这是怎么回事? WhatamIdoing (讨论) 2022年10月7日 23:51 (UTC)[回复]
在读完评论之前,我本来会反对将此内容添加到政策中。我改变主意了:我认为我们应该正式规定,回退只能用于明显的破坏行为,但我们应该将其添加到手册中,而不是一个新的政策页面。我们已经有足够的政策页面,但其中许多都很短,所以对于具体政策,我认为最好将信息添加到现有的政策页面中。 --来自 Selfie City (讨论) (贡献) 2022年10月7日 18:15 (UTC)[回复]
为巡查员单独设置页面是有道理的,但我不太确定我们是否需要比现在更多的建议。我不认为在使用工具方面有什么大问题,除了少数几个人,并且在他们的讨论页上提醒一下可能就足够了。然而,似乎我们对于何时应该使用该工具存在一些分歧。是否应该在 Wikivoyage talk:Administrators' handbook 上讨论?—LPfi (讨论) 2022年10月7日 19:22 (UTC)[回复]
我也倾向于添加到管理员手册,但那样会排除巡查员。 SHB2000 (讨论 | 贡献 | meta) 2022年10月7日 23:12 (UTC)[回复]

我认为一个工具无关的变化就足够了,而且它确实解决了真正的问题

工具无关的变化
当前版本 建议版本
回退是一种强硬的(可能带有侮辱性)措施,主要应用于破坏和垃圾邮件。善意编辑应通过编辑摘要中的解释来撤销。 使用回退按钮时,您无法添加有用的编辑摘要,因此它主要在不需要解释时有用(例如,明显的破坏和垃圾邮件)。无论使用哪种工具,如果您正在移除善意编辑,通常应该在某处提供解释。如果您不在编辑摘要中解释您的回退,那么请在讨论页或另一位编辑的讨论页上解释。大多数新人永远不会看到编辑摘要或使用文章讨论页,所以即使您在编辑摘要中解释了,您可能也需要在新人讨论页上重复该解释。

你觉得呢? WhatamIdoing (讨论) 2022年10月8日 00:02 (UTC)[回复]

我喜欢它。 Ikan Kekek (讨论) 2022年10月8日 00:29 (UTC)[回复]
我乐意用建议版本替换当前版本,再加上我上面提出的回退政策。记住,巡查员也有滥用回退功能的可能性。
我知道我被告知过无数次我试图让这个网站变得更官僚化,但我真的认为这个网站应该更官僚化(但不像维基百科)。缺乏关于管理员滥用其工具的政策,造成了一个容易被滥用的系统。我不知道 Ground Zero 提到的是哪位用户,但在大多数维基上,该用户早就被撤销了管理员身份(如果他是巡查员,他早就失去巡查员权限了)。然而,如果我们有这个政策,那么就明确什么是可以接受的,什么是不可以接受的,以及滥用的后果。这最终将使维基旅行成为一个更友好的编辑之地。 SHB2000 (讨论 | 贡献 | meta) 2022年10月8日 01:31 (UTC)[回复]
我喜欢你草稿中的一部分,但也可能不是全部,但我认为 WhatamIdoing 说得对,主要问题不在于使用的是简单回退、强硬回退还是回退功能,而在于是否向非破坏者或非机器人用户提供信息,无论是通过用户讨论页消息和/或编辑摘要,解释任何一种回退方法的原因。我也认为,对于任何一种方法的回退模式,如果没有告知非严格破坏者或机器人用户的回退原因,就应该被视为取消管理员资格的理由,但无论是巡查员还是管理员,都不应被期望完美无缺,只需避免养成不沟通的习惯。换句话说,我认为你过于强调回退方法了。 Ikan Kekek (讨论) 2022年10月8日 04:02 (UTC)[回复]
> 缺乏关于管理员滥用其工具的政策,造成了一个容易被滥用的系统。
不。我们对人的依赖造成了一个容易被滥用的系统。无论你写多少规则,或者它们多么清晰明了。重要的是人类是否被允许运用他们的判断力。如果他们可以,就会出现判断错误,有时这些错误会达到我们可能称之为滥用的程度。写下规则并不能解决问题。
我也不同意“确切地告诉经验丰富的编辑他们将因对回退是否需要编辑摘要解释持有不同观点而受到何种惩罚”(我们避免使用“后果”这个委婉语)是让维基旅行更友好的方式。
> 在大多数维基上,该用户早就被撤销了管理员身份
不。在少数维基上,该用户可能被考虑撤销管理员身份,这取决于许多因素,包括该社区是否觉得他们有多余的管理员,以及该管理员树敌多少。大多数时候,在绝大多数维基上,唯一的回复(如果有所谓的回复的话)是提醒提供编辑摘要。例如,德语维基百科的官方页面上是这么说的:
  • "Sollten andere Benutzer dennoch unwissentlich oder häufig für normale Wiederherstellungen „rollback“ nutzen, so kannst du sie beispielsweise mit dieser Vorlage {{subst:Hinweis Zurücksetzen}} oder mit einem eigenen Text auf ihrer Diskussionsseite darauf hinweisen, dass die Rollback-Funktion nur für die Zurücksetzung nach Vandalismus genutzt werden sollte."
  • (“如果其他编辑者仍然无意中或频繁地将“回滚”用于正常回退,你可以例如使用此模板 {{subst:Hinweis Zurücksetzen}} 或在他们的讨论页上写上自己的评论来提醒他们,回滚功能只能用于回退破坏。”)
没有提到任何特定于使用回滚的惩罚,回滚功能对经验丰富的编辑者来说很方便,而且他们似乎对此并没有什么大问题。WhatamIdoing (讨论) 2022年10月9日 20:22 (UTC)[回复]
@Ikan Kekek:重写了滥用部分内容,现在更侧重于沟通而非移除。这是我的新措辞:

如果你发现用户滥用回滚功能,请与他们讨论他们回滚功能的使用情况,或者至少给他们一个正式的警告。如果用户改正了他们的行为和回滚功能的使用方式,那么你就取得了进展。但是,如果反复的讨论未能产生效果,请明确指出,撤销管理员权限或移除巡查员权限始终是一个选项。如果用户仍然继续滥用回滚功能,你可以启动撤销该用户管理员身份的请求(如果该用户是管理员),并告知一名无关的管理员关于巡查员的情况。

你可能已经知道,我倾向于像解释法律一样解释政策。我曾试图避免让这段话听起来像法律文件,但它可能仍然像。对于@WhatamIdoing:我已经调整了,使得撤销管理员/移除巡查员权限成为最后的手段。这样可以吗? SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 03:36 (UTC)[回复]
我认为主要问题是我们是否需要一个正式的文档。我们试图避免政策。没有正式的政策,用户可以自行判断,这应该足够了,有时比规则更好。如果判断不够,我们可以讨论任何问题,而且比使用规则文档更灵活。我们确实遇到过一些用户随意使用回滚工具的问题,但关于什么是随意使用,什么不是,是否存在无法解决的问题?记录最佳实践很有用,但这与政策不同。–LPfi (讨论) 2022年10月16日 05:48 (UTC)[回复]
这是“我们做事的方式”的另一个例子,新用户如果不写下来就不知道。我不知道“我们试图避免政策”,但我在这里已经有六年了,所以我想我还没有吸取这个教训。
提议制定这项政策或将其添加到《管理员手册》的原因是我们有用户判断不佳并引起问题的例子。将其写下来可以更容易地在用户讨论页上进行这些讨论。它允许某人说“这一点上已经形成了共识——这不仅仅是你我之间的判断分歧”,而不是说“这不是你在这里做事的方式,等你在这里待久了就会明白”。Ground Zero (讨论) 2022年10月16日 07:09 (UTC)[回复]
Ground Zero 完美地总结了为什么维基旅行的编辑基础(潜力)远小于其(潜在)规模。每个政策都要求编辑者运用自己的判断。从WV:TTCFWV:TONE再到WV:TOUT,许多政策和指南都是主观的。对旅行者有用的内容和无用的内容之间没有明确的界限,可接受的语气和不可接受的语气之间没有明确的界限,叫卖式宣传和非叫卖式宣传之间也没有明确的界限。制定一项正式的政策并不意味着编辑者不能运用自己的判断。一项政策可以明确回滚功能的某项使用是否不可接受,或者是否不可接受;老实说,英语维基旅行应该为允许或未对类似的回滚行为采取太多行动而感到羞耻。编辑者仍然可以运用他们的判断力来处理模糊的情况。SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 07:42 (UTC)[回复]
我仍然认为问题不在于回滚功能本身被滥用,而在于使用回滚功能后,没有尝试与善意或可能善意的被回滚用户沟通,告知他们回滚的原因。我承认回滚功能对某些用户来说比其他形式的回退更伤人,因为你们有些人说过对你们来说是这样,但我认为缺乏沟通才是更大的问题。Ikan Kekek (讨论) 2022年10月16日 09:09 (UTC)[回复]
根据你的评论调整。请参阅Special:Diff/4542376SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 09:22 (UTC)[回复]
我认为记录最佳实践是好的,我没有说清楚吗?因此,我支持在《管理员手册》中增加关于回退、回滚和沟通的建议,但不赞成建议中提到的将该页面作为正式政策。可以很容易地引用相关部分作为“已有共识”,而无需说“你正在违反政策”。SBH 提出的两个例子分别是滥用和随意使用回滚的明显例子,处理它们不需要引用政策。事实上,我认为在这些情况下引用政策是对社区的贬低:与其说“请不要这样做”(假设善意),不如说“警告!”(依赖惩罚)。–LPfi (讨论) 2022年10月16日 11:58 (UTC)[回复]
关于“新用户不知道的‘我们做事的方式’的另一个例子”:有多少新用户拥有回滚按钮?我假设数量是零,因此新用户不需要知道这一点。WhatamIdoing (讨论) 2022年10月17日 22:37 (UTC)[回复]
我确信 GZ 所指的“新用户不知道”是指有经验的用户应该如何使用回滚功能。请记住,绝大多数用户在编辑维基旅行之前,首先是在百科全书上开始的,我保证大多数有经验的维基百科用户(即编辑次数超过约 2000 次的用户)都知道回滚功能。SHB2000 (讨论 | 贡献 | meta) 2022年10月18日 10:20 (UTC)[回复]
@WhatamIdoing: 实际上我指的是 LPfi 的评论“我们试图避免政策”。我在这里待了六年多,竟然不知道。也许它写在什么地方但我没读过,但在我看来,这是一种在我之前就在此的共识。Ground Zero (讨论) 2022年10月19日 19:29 (UTC)[回复]
让我着迷的社区正式结构的一个方面是它希望“没有任何半官方半非官方的规则页面”。直到几年前,要么是强制性政策,要么是某些非官方的好建议。没有中间状态;我们没有指南、补充或其他规则层级。我认为它非常有效,并且对这个群体很好。
现在我们有了Template:Guideline(没有Template:Policy,并且Template:Essay 除了其创建者之外未被使用),似乎标记页面的诱惑不像应该的那样受到抵抗。一旦你可以在页面上随意添加标签并将它们分入越来越细的类别,就会有人发现这项工作非常令人满意。
例如,Wikivoyage:Goals and non-goals,一个比w:zh:Wikipedia:Five pillars更早存在,并且在目的和风格上相似的页面,不久前被大胆地声明为一个指南。它需要被标记吗?我会争辩说w:zh:WP:NOTAG,就像我长期以来(并且成功地)在 enwiki 上主张对 5P 不加标签一样。如果它需要一个标签,那会是正确的标签吗?我对此表示怀疑。但它已经被标记了。阻止人们这样做的唯一实际方法就是删除标签。
但该标签被讨论并接受了,因为有人想导入一个被标记为英语维基百科上的“essay”的页面,并让其他人遵守其建议。他们似乎觉得标签是最后一部分的必要组成部分,所以现在我们有了标签,因为有了标签,它就蔓延到了其他页面。WhatamIdoing (讨论) 2022年10月20日 03:20 (UTC)[回复]
新用户需要知道有经验的用户如何使用高级工具吗?
如果你想帮助新用户在这里进行第一次编辑,那么解释其他人如何使用这个新手无法访问的工具,是否应该排在新手的必知事项列表的前十名?它甚至能排进前一百名吗?Wikivoyage:Welcome, Wikipedians 包含 106 个句子,但一次也没有提到回滚。
我认为新手需要知道的是,我们有人会解释问题并鼓励贡献。由于编辑摘要不是解释事物的唯一方式,也不是解释新编辑最有效的方式,解释问题实际上与回滚的“不良”使用并不矛盾。WhatamIdoing (讨论) 2022年10月18日 15:35 (UTC)[回复]

政策撰写哲学

我喜欢写政策和指南;我甚至对此相当擅长(尽管不擅长写作的人常常不知道这一点,所以也许我只是不知道自己的局限性)。我个人对什么最有效有自己的看法,加上我自己的偏好和偏见,并且我比大多数人见过更多的基于维基的社区的政策方法。我提供这些背景是为了说明接下来的内容有点哲学化,如果你不感兴趣,那就不必读了。

不同的人喜欢不同的方法。几乎每个人都相信自己的观点是中间立场,并且每个人都相信自己的观点是最好的。所以我告诉你,这些是我的观点,而不是说它们是唯一的选择。

我在英语维基百科上推荐的一个经验法则,并且我认为它适用于所有地方,就是这个:

➤ 除非在至少两次独立的事件(不涉及任何相同的编辑者不涉及相同的页面/内容)中,并且这些事件无法通过任何正常的、现有的流程(例如,请其他编辑者加入讨论)解决,否则永远不要为任何情况制定书面规则。

我认为另一个普遍的原则是:

➤ 建立积极的“规范”而不是“违规”和“惩罚”,通常更好,也足够了。

这意味着我们说“我们这样做”,或者“这是一个受欢迎的选择”,但我们不说“如果你不遵守这条规则,那么我们将因违规而惩罚你”。有例外,通常涉及明显的事项(例如,我们通过封禁来惩罚垃圾邮件发送者和破坏者)和法律事务。然而,在日常编辑中,目标是进行没有威胁的互动。威胁旨在产生恐惧。威胁并不是说你应该这样做,因为它好、正确,并且让世界充满彩虹和蝴蝶;威胁说你应该这样做,因为如果你不这样做,我会惩罚你。恐惧会产生糟糕的经历、糟糕的人际关系、糟糕的行为和糟糕的社区。

相比之下,当你告诉人们某事是正常或受欢迎的时,他们通常会想去做。人们想通过像群体一样行事来证明他们是群体的一部分。人们认为经验丰富的编辑者已经解决了大部分问题,并且他们想利用这些知识,而不是通过痛苦、耗时的错误自己摸索一切。

这是一个不完全普遍的原则,但这是我的强烈偏好:

➤ 社区越小,你应该拥有的规则就越少。

这意味着,例如,最小的维基几乎不应该有任何规则。它们应该只提一下核心内容政策,并且可能在某个地方声明版权侵权是坏主意,或者至少删除侵权内容,即使它们没有在本地写下侵权内容是违规的。否则,贡献者应该模仿他们认为有效并且正在工作的行为和贡献,避免那些似乎无效的事情,并且主要是为了内容而“活者,放手让别人活”。整体的组织和规则的复杂程度不应超过一群邻居在一个下午去学校或公园捡垃圾的程度。

中等规模的维基应该有几条规则和一些流程。这些规则应该只处理常见问题,并且总体上旨在让新来者更容易。大多数规则应该围绕建立广泛的可接受的行为,以最大化用于创建内容的工作量,并阻止自封的规则执行者为诸如是否使用w:zh:serial comma(尽管每个人都应该这样做! ;-))或什么是做某事的“唯一真理™”方式等问题而争吵。这些常见问题之外的问题应该由考虑群体价值观(例如,Wikivoyage:The traveller comes first,保持欢迎态度)、其Wikivoyage:Goals and non-goals 以及他们当前的能力来决定,始终关注决定的影响,以及对人际关系的影响。

英语维基旅行在这最后一点上通常做得非常出色。这一点很难通过盲目遵循规则来处理。这一点在对情况做出反应时效果最好,你需要了解所有个体之间正在发生什么。例如:这真的是关于那个编辑的争吵,还是更大问题的症状?是否有人因为处理持续的破坏者而筋疲力尽,而这次爆发是否表明该团体需要提供更多实际支持,而不是表明我们需要惩罚那些表达自己不堪重负和应付不过来的事实的人?这些中等规模维基的总体组织和规则水平应该类似于为 100 人安排一次聚餐。你必须确定一些角色并组织一些事情(例如,谁来清理现场?垃圾桶应该放在哪里?),但你主要是让人们做他们想做的事,并努力让群体保持快乐,而不用试图控制任何个体参与者。

最大的维基应该有足够的规则来防止重复出现的问题,并且有足够的流程让感兴趣的人能够专精。总的来说,大型维基的目标仍然是拥有尽可能少的规则,但要认识到最少的规则仍然有很多。当你拥有大量贡献者,并且典型的“成熟编辑者”的生命周期是几年时,会反复出现很多问题。

我认为绝对没有维基应该有预先解决一切问题的规则。规则应该尽可能多地留出创造空间。这是因为大多数人之所以做出贡献,是因为他们想创造一些东西,而不是为了遵循一堆规则或被规则执行者指挥。你可能以前见过这些比较:

  • 人们喜欢烹饪,但没人喜欢洗碗。为什么?烹饪是有创造性的。洗碗不是。
  • 人们喜欢缝衣服,但没人喜欢洗衣服。为什么?缝纫有创造性。洗衣服不是。

虽然一定程度的组织是必要且有益的,但超出该点的额外规则往往适得其反。它不再有趣。它开始变得无聊。当这种情况发生时,人们会发现维基之外还有一个完整的互联网,然后他们就会离开。

我不认为我的观点在这里是普遍的。撇开“建造它,它们就会来”的那种人——他们天真地认为将英语维基百科广泛(且自相矛盾)的规则集、模板、机器人和通用官僚主义翻译成当地语言会导致一个庞大的社区出现来填补所有角色(至今从未成功过……)——有一些情况可以选择不同的方法,例如:

  • 对于敏感主题(例如,人力资源政策)的企业维基可能对控制有特别高的要求。诉讼曾取决于合同中的标点符号。
  • 自闭症患者社区可能看重我称之为“压抑式”的规则遵循。特别是如果你一生大部分时间都在思考你是否违反了某种模糊的社会惯例,那么知道你通过点击蓝色按钮而不是黄色按钮来做正确的事情会让你感到安慰,即使两个按钮的作用基本相同。这样的社区可能比创造力更看重可预测性、一致性和控制力。(顺便说一句,自闭症患者一旦找到适合其技能和兴趣的任务,往往会成为不知疲倦的贡献者。)
  • 年轻学童可能需要一种非常“按部就班”的贡献方式,因为他们缺乏做出良好贡献所需的成熟度。

但我不愿成为那样的社区的一员,我怀疑我们大多数人也是如此。我们在这里不是为了完美地遵守规则而感到快乐。我们在这里是为了与很棒的志愿者一起,在一个有趣的主题上创造新信息(并互相帮助),从中获得乐趣。

现在,请容我耐心听完我这冗长的陈述,并将其与上述争议联系起来

  1. 我认为我们不需要规则,因为这种情况基本上只涉及一个争议,而且它基本上已经通过现有的、正常的流程得到了解决。也许有些人对解决方案不满意,但我们确实达到了解决方案。
  2. 如果我们决定制定任何规则,我们不必威胁任何人。给出积极的陈述就可能足够了(“如果你回退任何非明显破坏的内容,请说明原因。这通常通过自定义编辑摘要或在讨论页上完成”)。
  3. 我们正在出色地处理围绕此事的讨论,因为人们不断回到核心价值观,例如通过解释为什么他们第一次尝试必须被回退来欢迎和鼓励新来者。

这一点让我很高兴来到这里。WhatamIdoing (讨论) 2022年10月18日 05:45 (UTC)[回复]

@WhatamIdoing: 你说的一些观点很好;我大体上同意你许多观点。另一方面,有一些观点我不同意,但很多观点并不特别与回滚政策相关。
关于“除非在至少两次独立的事件(不涉及任何相同的编辑者不涉及相同的页面/内容)中,并且这些事件无法通过任何正常的、现有的流程(例如,请其他编辑者加入讨论)解决,否则永远不要为任何情况制定书面规则。”:这是真的,但就本例而言,我们已经有不同用户滥用回滚的各种情况,而不仅仅是我提到的两次差异。
我意识到这严重跑题了,但回应“社区越小,你应该拥有的规则就越少。”,缺乏政策是导致小型维基不符合维基媒体规范的原因。在许多情况下,一个小维基上的管理员过去可能是垃圾邮件发送者,或者可能被大型维基(如 enwiki)封禁。顺便说一句,我相信 shn.voy 上有两个用户复制了 en.voy 的各种模板而没有注明任何出处。我曾考虑过警告这两位用户,但其中一位用户是 shn.voy 的管理员,我犹豫是否要警告这两位用户或修复此归因问题。我最终可能不得不自己做这件事,否则我可能会在 meta 上提出这个问题。不幸的是,他们俩的 Babel 量表都声称他们是 shn-3 和 my-3,完全没有提及英语。缅甸语当然可以通过谷歌翻译,但完全不懂缅甸语,这将是一个问题。关键是,在小型维基上沟通很困难,尤其是在大多数用户几乎不懂英语的维基上(回到 shn.voy 的问题,缅甸大多数人不懂英语)。
回到正题,我不太确定中等规模维基是否应该只有少数规则和流程。就我个人而言,我在 en.wb 上相当活跃,这是一个编辑者较少的维基,但有更多的流程(包括管理员公告板、编辑过滤器误报页面、管理员协助页面——我还可以继续说下去),但它们在处理破坏、垃圾邮件、有行为问题的用户等方面通常问题较少。简单来说,有政策,几乎所有用户都遵守,而且没有麻烦。在这里,发生的事情是用户认为他们可以随时使用回滚功能,制造麻烦,最终赶走用户或让其他人感到不受欢迎,认为这是一个“私人俱乐部”。如果大多数维基在回滚功能的使用上没有遇到障碍,而英语维基旅行上的几个用户遇到了,那么谁(即哪个维基)是罪魁祸首?
我同意我们不想走“规则执行”的道路,但我鼓励在座的各位看看 en.wb 是如何做事的。我很抱歉让你们中的许多人失望,但 en.wb 做事情比 en.voy 好得多,正因如此,它才不像“那个网站”那样容易在失去几个编辑者后就消亡。从处理破坏、垃圾邮件、有问题用户、政策等方面来看,en.wb 至少据我所知,从未发生过这样的闹剧。如果说自从我开始编辑以来,en.wb 上最具争议的讨论是是否允许视频游戏攻略。长篇大论结束。
最后以积极的口吻结束,我绝不暗示维基旅行在处理破坏、垃圾邮件或有问题用户方面很糟糕;我的意思是,如果我们遵循 en.wb 的模式,它可能不再只是 enwiki 大小的 1% 的维基。像制定一个概述可接受和不可接受内容的标准政策这样的小步骤并不一定会使网站变得更官僚化,也不具威胁性(我们应该废除WV:TOUT因为它具有威胁性吗?不,我们不应该)。回滚政策不应影响用户(建设性地)如何贡献。
抱歉让读了我的长篇大论和文本块的任何人。我是在深夜写的,而且今天在火车站爬楼梯时摔倒了。如果有什么不清楚的地方,我很乐意澄清。--SHB2000 (讨论 | 贡献 | meta) 2022年10月18日 12:23 (UTC)[回复]
你没有记录任何社区无法通过其正常的、日常的讨论过程来处理的回滚滥用事件。因此,写下规则实际上无济于事。它只会导致w:zh:WP:Instruction creep。(请注意,“处理”不同于“让人们服从你的命令”或“产生统一行为”。)
你对写下规则有如此强烈的信心。书面规则不是魔法咒语。即使在英语维基百科上,许多人会将其描述为规则繁琐,要让书面规则开始影响编辑的实际行为,通常需要两年的时间。
至于“我确实同意我们不想走规则执行的道路”,那么你为什么要做那么多呢?试图让该编辑被撤销管理员权限,因为你不同意回滚的使用,这就是规则执行。当它不起作用时,你提议修改规则,使行为更明显地应受惩罚,以便下次你可以严格执行它们。如果你不想“走规则执行的道路”,那么就停止试图对其他贡献者执行规则。
维基教科书的“麻烦”较少,因为它的编辑者比本站点少,并且这些用户之间的互动也少得多。他们这里的对应页面包含一个非机器人的评论。这并不奇怪,因为那里的想法是我在这里写我的书,你在那里写你的书,而在这里,想法是我们都在努力创作同一个目的地的一个好页面。仅基于这两个结构元素,就可以预期会大大减少麻烦。
其他维基在回滚使用上很少出现麻烦,因为没有人关心用哪个按钮来回退用户。例如,英语维基教科书上关于回滚的页面,并不说回滚只能用于破坏,也不说编辑者必须解释非破坏性回退,甚至不暗示撤销管理员权限是对“滥用”回滚的相称回应,这并不奇怪,因为根据他们的规则,几乎不可能滥用它。我在那里看到有编辑者使用回滚来回退可能是测试编辑,而不是破坏,而且我不认为有人会为此抱怨。我看到一个管理员移除一个外部链接。这是另一个编辑回滚了善意解释一个词的行为,这里还有一个编辑回滚了一个简单的语法错误一个单字符的拼写错误。该维基上回滚使用的一半左右的行为是你试图在此禁止的。如果你希望我们更像英语维基教科书,那么让我们从采纳他们对使用哪个按钮来移除不需要的编辑的自由放任态度开始。WhatamIdoing (讨论) 2022年10月18日 16:17 (UTC)[回复]
将这些政策放在心上是好的。我们许多政策页面是“另一个网站”的遗留产物,有时可能会涉及我们很少看到的问题。Wikivoyage:Listings 最近被提及了几次,并以寺庙和历史建筑为例。希望我们能使政策撰写更具鼓励性和普遍性。/Yvwv (讨论) 2022年10月18日 16:38 (UTC)[回复]
简短回复:你提到的有些链接,如b:Special:Diff/4195113b:Special:Diff/4195008,是长期破坏者的回退。我会在回家后回复你的其他信息。SHB2000 (讨论 | 贡献 | meta) 2022年10月18日 20:36 (UTC)[回复]
完整回复:
  • “你没有记录任何社区无法通过其正常的、日常的讨论过程来处理的回滚滥用事件。”嗯,Talk:Berlin?这只是一个例子。
  • “你对写下规则有如此强烈的信心。书面规则不是魔法咒语。”我已经表达了我的观点,不会再重复了。
  • “至于‘我确实同意我们不想走规则执行的道路’,那么你为什么要做那么多呢?”避免规则执行意味着不让机器人每次在主空间链接消歧义页面时都警告用户,或者类似的。它并不意味着不指出用户的行为。
  • “其他维基在回滚使用上很少出现麻烦,因为没有人关心用哪个按钮来回退用户。”如果真是这样,为什么其他维基上善意编辑的回滚基本上不存在?我并不是在主张使用撤销按钮来处理恶意的测试编辑,不像你声称的那样,例如b:Special:Diff/4194730b:Special:Diff/4194722
所以实际上,en.wb 上所有的回滚使用都不是滥用,而是完全可以接受的,如果User:SHB2000/rollback 成为政策的话。SHB2000 (讨论 | 贡献 | meta) 2022年10月19日 08:33 (UTC)[回复]
  • Talk:Berlin 发生于四年前,并通过正常、日常的讨论得到解决。这次讨论甚至包括了使用回滚按钮的人的礼貌道歉。你还能期望什么?
  • 指出用户的行为是一种规则执行。
  • 你说将“是菲律宾-西班牙人”改为“是一个菲律宾-西班牙人”是恶意的测试编辑吗?我认为这是来自一位不说母语的英语人士的善意编辑。语法不好,但并非恶意。你怎么知道这个人当时在积极地试图损害维基教科书?同样,将“level”改为“levl”。你怎么知道这是蓄意造成损害的尝试,而不是意外?请注意,我并不是说这违反了维基教科书的任何规则;我只说这并非公然的破坏。
WhatamIdoing (讨论) 2022年10月20日 02:51 (UTC)[回复]

维基旅行门户 (www.wikivoyage.org)

嗨,我一直在更新项目门户(例如 www.wiktionary.org)以适应新的编码基础设施,以避免将其存储在 meta 页面中(m:Www.wikivoyage.org_template)等等,包括更好的搜索体验、一致的设计、更好的外观等等。现在除了维基旅行,所有项目都已迁移,因为它的门户完全不同(日落图片)。

我想知道是否可以将其更改为标准门户设计(例如 wikipedia.org),因为

  • 它不可访问,文本的对比度(由于背景图像)对于有视觉障碍的人来说太低了。
  • 设计不遵循维基媒体标准(https://design.wikimedia.org/style-guide),例如蓝色不是 #36c
  • 总体外观不遵循所有其他项目遵循的标准,这是运动品牌的一部分。
  • 当前设计根本没有考虑到我们未来可能拥有更多维基旅行语言,没有为它们提供适当的空间(不像标准设计)。
  • 当前设计在手机上完全损坏。

我在 meta 上提到了这一点,但没有得到任何回应。所以我认为我在这里提出了。修复这个问题将解决我们许多遗留的基础设施问题。谢谢!Ladsgroup (讨论) 2022年10月15日 12:19 (UTC)[回复]

什么日落图片?只有手机版门户有吗?Ikan Kekek (讨论) 2022年10月15日 18:32 (UTC)[回复]
@Ikan Kekek这个页面,而不是维基的主页。Ladsgroup (讨论) 2022年10月15日 18:43 (UTC)[回复]
我明白了。我对日落的画面没有什么特别的依恋,所以如果维基媒体标准也具有在手机上更可见等优点,那么,是的,我们就采用它吧。Ikan Kekek (讨论) 2022年10月15日 22:41 (UTC)[回复]

酷工具

https://www.top-rated.online/ 这是另一种看待“孩子们在谈论什么”的方式。至少是在线上的。它似乎从各种来源拉取数据。似乎没有太多关于乡村地区的数据。我估计英语使用者喜欢去的地方覆盖率更好。你的体验可能不同。ButteBag (讨论) 2022年10月25日 13:17 (UTC)[回复]

列表非常糟糕。我尝试了蒙特利尔,前 5 名包括 3 家珠宝店、1 家电子烟店和 1 位牙医。这并不完全是游客旅行时需要的东西。OhanaUnited讨论页 2022年10月28日 04:27 (UTC)[回复]
你也可以过滤和排序,这对于蒙特利尔这样的大城市似乎更有用。YUL 顶级酒吧,例如。点击“隐藏的瑰宝”,等等。ButteBag (讨论) 2022年10月28日 13:43 (UTC)[回复]

正在寻找关于新冠的旧讨论

我(非常模糊地)记得在 wiki-voyage 上进行过一次讨论,关于一些来源认为新冠不再是一个问题,或者类似的意思,但我找不到它,事实证明这对我是好事……

我一开始就在这里寻找。找不到,所以决定去查阅档案。那么,档案在哪里?起初,我对档案不像英语维基百科(enwp)那样很容易在页面顶部找到感到有些恼火。不过,由于我并非像通常那样急着赶时间,我开始阅读顶部的框,然后很快跳到它下面的框,内容以“有经验的用户:请打扫酒吧”。”开头。

非常有趣,这是一种我在其他 WMF Wiki 上从未见过的不同方法。(想继续写下去,但我担心会丢失我已经写的内容,所以就不写了)Ottawahitech讨论2022年11月6日 13:32 (UTC)[回复]

这是一个有效的观点。此页面的顶部内容繁杂,对新访客不友好。我建议
  1. 在第一个框中添加一个指向档案的链接
  2. 将第二个框(针对有经验的编辑者)移到讨论页的顶部。它不适用于新访客,有经验的编辑者每次访问酒吧时都不需要阅读它。
Ground Zero讨论2022年11月6日 13:45 (UTC)[回复]
哇,我喜欢这个地方。回应非常迅速,而且我收到了通知,尽管我没有被提及(我使用了[订阅]按钮)!Ottawahitech讨论2022年11月6日 13:56 (UTC)[回复]
对于大部分被扫到其他讨论页而不是存档的内容,我们应该怎么做?Ikan Kekek讨论2022年11月6日 16:09 (UTC)[回复]
Template:Swept 可以配一个 Template:Sweptto(Swept 可以重定向为 Sweptfrom,或者移到 Sweptfrom),它将取代此处的内容,放在原标题下(标题将保留并存档),以帮助人们通过搜索或浏览档案找到类似的东西;如果标题本身无用,移动讨论段落的编辑者可以在标题后附加一些括号内的文字,以明确其内容(如果标题是“问题”,编辑者可以将其更改为“问题(COVID措施放松)”)。Twsabin讨论2022年11月6日 17:51 (UTC)[回复]
这对偶尔想查找旧对话而不必费力查看酒吧历史的人来说会很方便,但会给少数几个进行清扫工作的人增加很多工作量。增加清扫者的任务可能会导致清扫工作减少,这对酒吧不利。我反对这样做。我认为少数想查找旧对话的人可以查看历史记录。那里什么都会有。Ground Zero讨论2022年11月6日 18:11 (UTC)[回复]
我认为在许多情况下,段落标题将无济于事。不过,一般来说,解决方法是:查找讨论应在的位置。如果这是关于Wikivoyage:Where you can stick it 的问题,那么就查找Wikivoyage talk:Where you can stick it
搜索通常有一个明显的优点:如果——就像本例一样——你正在寻找被讨论过多次的内容,那么搜索将引导你找到多个讨论,例如Talk:Main Page#Is it time to drop the COVID-19 banner?Talk:Stay healthy#Is COVID over?WhatamIdoing讨论2022年11月7日 16:39 (UTC)[回复]

对页面顶部框的建议更改

我的提议没有得到多少回应,所以我将把它单独列为一个部分:由于此页面顶部的内容繁杂且对新访客不友好,我建议

  1. 在第一个框中添加一个指向档案的链接
  2. 将第二个框(面向有经验的编辑者)移至讨论页的顶部。

有什么意见吗?Ground Zero讨论2022年11月9日 12:33 (UTC)[回复]

我觉得这样挺合理的。Ikan Kekek讨论2022年11月11日 12:37 (UTC)[回复]
同感。–LPfi讨论2022年11月11日 12:59 (UTC)[回复]
同感。SHB2000 (讨论 | 贡献 | meta) 2022年11月11日 20:09 (UTC)[回复]

邀请参加“运动章程问答”活动

大家好,

在 2022 年维基媒体峰会上,运动章程起草委员会(MCDC)展示了运动章程的初稿,一窥其未来工作的方向以及章程本身。随后,MCDC 整合了峰会期间收集的初步反馈。在为整个运动撰写章程之前,MCDC 希望与社区成员互动,并就三个部分的草稿收集反馈:序言、价值观与原则,以及角色与职责(意向声明)。运动章程草稿将于 2022 年 11 月 14 日在 Meta 页面此处提供。关于 MC 的全社区咨询期将从 2022 年 11 月 20 日至 12 月 18 日举行。在此了解更多信息。

为了确保人们充分了解情况并能充分参与讨论,并赋予他们贡献自己对运动章程观点的能力,已安排了三个 “运动章程问答”活动,时间安排在不同的时区。运动中的每个人都受邀参加这些活动。目的是了解运动章程——它的目标、目的、重要性以及它如何影响你的社区。MCDC 成员将参加这些活动,回答你的问题并听取社区反馈。

“问答”活动迎合了不同时区的社区。只有活动的演示文稿会被录制并稍后分享,对话不录制。以下是计划的活动列表

  • 亚洲/太平洋:2022 年 11 月 4 日 09:00 UTC(当地时间)。提供中文和日文的翻译。
  • 欧洲/中东和北非/撒哈拉以南非洲:2022 年 11 月 12 日 15:00 UTC(当地时间)。提供阿拉伯语、法语和俄语的翻译。
  • 北美和南美/西欧:2022 年 11 月 12 日 15:00 UTC(当地时间)。提供西班牙语和葡萄牙语的翻译。

Meta页面上,你可以找到更多细节;Zoom链接将在会议开始前 48 小时分享。

招募运动章程大使

我们鼓励来自所有社区的个人或团体,他们希望在自己的社区中协助推广和开启关于运动章程的讨论,成为运动章程大使(MC大使)。MC大使将开展自己的活动,并获得资金支持,以促进他们自己语言的讨论。区域协调员来自运动策略和治理团队,他们可以支持申请人获得 MC 大使补助金。如果你有兴趣,请在此注册。如果你有具体问题,请通过电子邮件:strategy2030@wikimedia.org,或在 MS 论坛上联系 MSG 团队。

感谢您的时间和参与。

代表运动章程起草委员会,

Zuz (WMF)讨论2022年11月7日 10:17 (UTC)[回复]

加入运动章程区域对话时间

你可以在 Meta-wiki 上找到此消息的其他语言翻译。
更多语言请帮助翻译成你的语言

大家好,

正如你们大多数人所知,运动章程起草委员会(MCDC)目前正在收集社区对运动章程三个草稿部分的反馈:序言价值观与原则,以及角色与职责意向声明)。

你如何参与和分享你的反馈?

MCDC 期待收到来自运动和联盟中各社区成员以不同语言提供的各种反馈。你可以通过以下方式参与:

  • 参加与 MCDC 成员的社区对话时间。区域社区对话时间的详细信息在此公布
  • 填写一份调查问卷(可选且匿名)
  • Meta讨论页上分享你的想法和反馈
  • MS论坛上分享你的想法和反馈
  • 如果你有其他反馈给 MCDC,请发送电子邮件至:movementcharterwikimediaorg

本周五(11 月 25 日)将在 Zoom 上举行撒哈拉以南非洲地区的社区咨询时间。届时将提供法语翻译。对话不会被录制,除了参与者被邀请分享他们在分组讨论中讨论的内容的部分。之后我们会做笔记并制作总结报告。

如果你想了解更多关于运动章程、它的目标、它为何重要以及它如何影响你的社区,请观看 2022 年 11 月初举行的“运动章程问答”活动的录像

感谢你的参与。

代表运动章程起草委员会,

Zuz (WMF)讨论2022年11月22日 11:54 (UTC)[回复]

有兴趣的人注意:类似的(相同的?)消息也发布在 enWQ。我问了一个(承认有些偏执的)问题,OP(原发布者)在那里回答了。Ottawahitech讨论2022年12月3日 20:46 (UTC)[回复]

我在wikidata:Wikidata:Project_chat#Can_we_link_to_Wikivoyage_listings? 描述了这个问题——我建议有兴趣的编辑者在那里发表意见。Piotrus讨论2022年12月4日 06:53 (UTC)[回复]

🎄 祝大家圣诞快乐 🎄

或者用威尔士语说,是 Nadolig llawen pawb。好好吃饭,尽情畅饮,与你爱的人共度时光。感谢你们再次成为一群优秀的人。祝愿 2023 年成为一个伟大的年份,迎来我们的十周年和二十周年纪念!--ThunderingTyphoons!讨论2022年12月25日 14:39 (UTC)[回复]

祝大家圣诞快乐!Ypsilon讨论2022年12月25日 17:17 (UTC)[回复]
说得对,谢谢:也祝你和你的家人节日快乐。希望 2023 年快乐、和平、富有成效。—Justin (koavf)TCM 2022年12月25日 19:48 (UTC)[回复]
我知道我给所有我能想到的常驻用户都发了圣诞贺卡,即使我可能迟到了(在我写这篇文章时,我这里已经是 12 月 26 日上午 08:38 了),祝大家圣诞快乐!SHB2000 (讨论 | 贡献 | meta) 2022年12月25日 21:39 (UTC)[回复]
圣诞快乐,新年快乐,光明节快乐等等,所有正在庆祝的节日!Ikan Kekek讨论2022年12月25日 22:06 (UTC)[回复]
你们都一样!/Yvwv讨论2022年12月27日 11:46 (UTC)[回复]
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.