跳转至内容

维基旅行:旅人茶馆/2022

来自维客旅行
 这是一个过去讨论的存档。请勿编辑本页内容。如果您希望发起新的讨论或重提旧的讨论，请在当前的讨论页进行。

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

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

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 顺便说一句，有没有办法让导航弹出窗口显示更有趣的图像，而不是文章中碰巧在第一个列表/标记中的图像？不幸的是，当我悬停在一个链接上时，弹出的图片通常是关于机场或其他不起眼的交通基础设施的，而不是目的地更有趣、更具代表性的图像。—Granger （讨论 · 贡献） 16:06, 2021年11月29日 (UTC)[回复]

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

关于《通用行为准则执行草案指南》的评论期结束

感谢您对《通用行为准则执行指南》的持续评论和想法。您的回复有助于构建一个更强的《通用行为准则》。

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

《通用行为准则》的下一步包括关于执行指南批准的对话。将有一个关于 11 月 29 日批准的对话。

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

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

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

大家好！

我们，《社区愿望清单调查》团队，邀请您与我们进行一次在线会议。会议将于11月30日 (星期二)，17:00 UTC 在 Zoom 上进行，持续一小时。点击此处加入。

议程

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

形式

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

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

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

邀请链接

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

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

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

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

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

虽然可能会增加其他问题，但运动策略和治理团队希望为社区成员和分支机构提供时间来考虑并准备上述已确认问题，然后在征集开始前做好准备。社区成员也可以在征集期间组织当地的对话。您可以在这里找到有关这次即将举行的反馈征集的更多信息。

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

年龄证明

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

我想这对于年轻人来说是真的，但保安人员难道不能相信一个 50 岁的人的话吗？这里大多数商店要求看起来低于 30 岁的人出示 ID，我认为这给了很好的余地（法定饮酒年龄是 18 岁），也许会让一些非青少年的外国人口渴。

我们应该明确说明，这些要求何时以及何时不适用于看起来不像青少年的人？你可能不想随身携带护照，而护照通常是你唯一可接受的 ID。其他 ID 在世界各地普遍被接受吗？

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

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

Wiki Loves Folklore 回来了！

请帮忙翻译成您的语言

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

您可以通过拍照、录音、录像并提交到共享资源比赛中，来帮助丰富您所在地区的民间传说记录。

您还可以组织一个当地的比赛，并帮助我们翻译项目页面，以帮助我们在您的母语中传播信息。

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

此致，

Wiki loves Folklore 国际团队

--MediaWiki message delivery (讨论) 13:14, 9 January 2022 (UTC)[回复]

社区愿望清单调查 2022

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

本次调查是社区决定社区技术团队在接下来一年中应致力于哪些工作的过程。我们鼓励所有人提交提案，截止日期为1月23日，或者评论其他提案以帮助其改进。社区将在1月28日至2月11日期间对提案进行投票。

社区技术团队专注于为有经验的维基媒体编辑者提供工具。您可以以任何语言撰写提案，我们将为您翻译。谢谢，我们期待看到您的提案！ SGrabarczuk (WMF) (讨论) 18:10, 10 January 2022 (UTC)[回复]

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

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

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

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

  1. 如何确保当选候选人具有更多样化的代表性？董事会注意到选择代表维基媒体运动全部多样性的候选人的重要性。目前的流程偏向于来自北美和欧洲的志愿者。
  2. 对候选人在选举期间的期望是什么？董事会候选人传统上需要完成申请并回答社区问题。选举如何提供对候选人的适当见解，同时也能 the 候选人作为志愿者的身份？

在意见征集中可能会有一个关于选择过程的额外问题。这个问题仍在讨论中，但董事会希望尽快提供已确认问题的见解。希望如果将提出一个额外的问题，它将在意见征集的第一周准备好。

加入对话。

顺颂,

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

XTools 编辑计数器选择加入

有一个很有用的工具叫做 XTools，它可以显示你或其他人的编辑数据，例如你编辑最多的页面、每月编辑次数，以及其他一些有趣的统计数据。它对于很多事情都很有用，比如了解一个编辑者是活跃还是不活跃，看看某人更关注主空间还是项目空间，以及跟踪你编辑最多的文章的质量。

对于许多项目（包括大多数最大的项目），所有 XTools 统计数据默认都已选择加入。然而，在 Wikivoyage 上，大多数统计数据需要手动创建 Special:MyPage/EditCounterOptIn.js，这使得它不太有用。是否有兴趣让 XTools 在 Wikivoyage 上默认选择加入？ Vaticidalprophet (讨论) 17:51, 8 January 2022 (UTC)[回复]

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

与社区技术交流

你好

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

议程

  • 请带上您的提案草稿，与社区技术团队成员讨论如何改进您的提案。

形式

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

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

Natalia Rodriguez（社区技术经理）将主持此次会议。

邀请链接

希望见到您！ SGrabarczuk (WMF) (讨论) 00:21, 18 January 2022 (UTC)[回复]

订阅“本月教育”通讯 - 向他人学习，分享您的故事

尊敬的社区成员：

来自 EWOC 通讯团队和维基媒体基金会教育团队的问候。我们非常高兴地分享，我们迎来了教育通讯（本月教育）的十周年，邀请您通过在您的讨论页上订阅该通讯或在即将发布的通讯中分享您的活动来加入我们。维基媒体教育通讯是每月一期的通讯，收集了世界各地社区成员在使用维基媒体项目进行教育的文章，并由 EWOC 通讯团队与教育团队合作发布。这些故事可以为您带来新的尝试想法，以及关于我们社区成员在各自环境中开展教育项目时取得的成功和面临的挑战的宝贵见解。

如果您的分支机构/语言项目正在开发自己的教育计划，请记住利用此通讯来发布您的故事，与同样热爱教育的更广泛的社区分享。您可以提交您自己语言的通讯文章，或为教育通讯提交双语文章。一月份的文章提交截止日期是1月20日。我们期待阅读您的故事。

此通讯的旧版本可在完整存档中找到。

有关通讯的更多信息可在教育/通讯/发布指南中找到。

更多信息，请联系spatnaik@wikimedia.org。

关于《本月教育》 · 订阅/退订 · 全球消息发送 · 团队：ZI Jony (讨论), 2025年11月13日星期四 3:38 (UTC)

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

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

欢迎阅读第五期运动策略与治理新闻（前身为通用行为准则新闻）！本改版通讯将分发与运动章程、通用行为准则、运动策略实施资助、董事会选举及其他相关MSG主题相关的时事和活动。


本通讯将按季度分发，而更频繁的更新也将每周或每两周发送给订阅者。请记住在此订阅以接收这些更新。

  • 关于董事会选举的反馈意见征集 - 我们邀请您对即将举行的 WMF 董事会选举提供反馈。本次反馈意见征集已于 2022 年 1 月 10 日上线，并将于 2022 年 2 月 7 日结束。（继续阅读）
  • 通用行为准则批准 - 2021 年，WMF 询问社区如何执行通用行为准则政策文本。修订后的执行指南草案应在 3 月份准备好供社区投票。（继续阅读）
  • 运动策略实施资助 - 在我们继续审查几项有趣的提案时，我们鼓励并欢迎更多旨在实现运动策略建议中特定举措的提案和想法。（继续阅读）
  • 通讯的新方向 - 随着 UCoC 通讯过渡到 MSG 通讯，请与协调团队一起构想和决定本通讯的新方向。（继续阅读）
  • Diff 博客 - 查看 Wikimedia Diff 上最新的 MSG 相关出版物。（继续阅读）

Zuz (WMF) (讨论) 08:21, 20 January 2022 (UTC)[回复]

Wikivoyage 的影响力

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

这真有趣。我曾认为英文 Wikivoyage 比英文 Wikipedia 在主页设计上做得更好，更现代、更好看。当前的英文 Wikipedia 主页是 2006 年 3 月设计的，在互联网时代已经过去太久了。 Gizza (roam) 03:48, 22 January 2022 (UTC)[回复]
英文Wikibooks的主页看起来设计得很早，比 Wikipedia 的还要老旧。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 03:51, 22 January 2022 (UTC)[回复]
题外话，但说到主页设计，w:nv: 有彩虹渐变，我一直很喜欢，即使可能并不吸引所有人。 —Justin (koavf)❤T☮C☺M☯ 10:19, 23 January 2022 (UTC)[回复]
w:se:（萨米语）进行了专业重新设计，并融入了文化相关元素。 WhatamIdoing (讨论) 21:31, 23 January 2022 (UTC)[回复]
这很有趣，因为它似乎具有响应式设计，我记得在任何维基上都没见过。 —Justin (koavf)❤T☮C☺M☯ 21:42, 23 January 2022 (UTC)[回复]

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

大家好。我想向您更新一下桌面改进项目的情况，该项目是维基媒体基金会 Web 团队在过去几年中一直致力于的项目。

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

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

这些更改仅适用于Vector皮肤。使用Monobook或Timeless用户不受影响。

上次更新以来部署的功能

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

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

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


如何启用改进功能

全局偏好设置
  • 可以通过在偏好设置的“外观”选项卡中取消勾选“使用旧版 Vector”框（必须为空）来在 偏好设置中单独选择加入。也可以使用全局偏好设置在所有维基上选择加入。
  • 如果您认为这对本维基的所有读者和编辑者来说都是一个不错的默认选项，请随时与社区发起讨论并联系我。
  • 在默认情况下，更改对所有读者和编辑者都可见的维基上，已登录用户始终可以选择退出到旧版 Vector。新版 Vector 的侧边栏中有一个易于访问的链接。

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

如果您想了解我们项目的进展，可以订阅我们的通讯。

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

如何加入我们的在线会议

谢谢！!

代表维基媒体基金会 Web 团队， SGrabarczuk (WMF) (讨论) 22:11, 24 January 2022 (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) (讨论) 09:36, 4 February 2022 (UTC)[回复]

机场文章的脚本错误

新年快乐。从布里斯班往下，信息被脚本错误取代，显示红色文字：“脚本运行时间已过。”有人知道是什么原因造成的以及如何修复吗？ --ThunderingTyphoons! (讨论) 11:51, 11 January 2022 (UTC)[回复]

谢谢 Justin。回答你的问题，按顺序：是的，没有（都确定）。我不知道。 —Justin (koavf)❤T☮C☺M☯ 11:57, 11 January 2022 (UTC)[回复]
谢谢 Justin。回答你的问题，按顺序：是的，没有（都确定）。我不知道。--ThunderingTyphoons! (讨论) 11:59, 11 January 2022 (UTC)[回复]
嗯。奇怪的是它才刚开始。作为不了解模块的人，我建议一个快速的解决方法是将文章按大陆分割，并在phab:上提交一个工单。可能有人比我更了解（但这总是对一切都适用：/）。 —Justin (koavf)❤T☮C☺M☯ 12:01, 11 January 2022 (UTC)[回复]
现在对我来说可以了。也许是临时的负载问题导致了处理器时间超出（或者更改了限制）？总之，最好不要逼近极限。Wikivoyage 的处理负担相当重；有没有办法优化列表模板，或者其他方法避免某些页面非常耗费资源？ –LPfi (讨论) 13:33, 11 January 2022 (UTC)[回复]
对我来说也工作了。如果问题再次出现，我们可以提交一个 Phabricator 工单。我想我们还需要 14 个机场才需要以某种方式进行分割，例如使用不同的颜色标记或单独的子文章。--ThunderingTyphoons! (讨论) 15:03, 11 January 2022 (UTC)[回复]
如果你好奇的话，这听起来像是PEIS限制。我之前问过，但找不到任何人能完全理解开发人员是如何决定限制的。解决方法很简单：分割大型页面，优化模板。 WhatamIdoing (讨论) 16:32, 11 January 2022 (UTC)[回复]
大部分时间都用于获取 Wikidata 数据集，正如你从 HTML 代码中可以了解到的。它包含一个 NewPP limit report。获取实体大约需要 6 秒，这是一个巨大的值，可能是由于复杂的机场数据集（并且随着软件的增加而增加）。Lua 的总计算时间接近 10 秒的限制，也就是说，有时可以工作，有时不行。我已将其复制到德语 Wikivoyage 的 de:Benutzer:RolandUnger/Flughäfen。它证实了获取实体需要巨大的计算时间。但它也表明，列表脚本可以优化，因为它总共只需要 8 秒的计算时间，比英语 Wikivoyage 少 2 秒。这更短的计算时间可以防止任何 Lua 时间错误。
在正常情况下，在文章中可以最多获取 250 个不同的 Wikidata 集，正如 de:Halle (Saale) 中所示。当然，Scribunto_LuaSandboxCallback::getEntity 和 Scribunto_LuaSandboxCallback::callParserFunction 的计算时间应该缩短。有时我在 Phabricator 上提交了 bug 报告，但只做了微小的改动来修复 bug。--RolandUnger (讨论) 16:46, 11 January 2022 (UTC)[回复]

由于获得内存的根本性改变很困难，并且依赖于开发者，我建议我们提前分割这篇文章。我们可以本地控制页面上的模板和脚本数量，所以我们应该留意我们认为可能会失败的页面。——Justin (koavf)❤T☮C☺M☯ 18:27, 11 January 2022 (UTC)[回复]

另外，我现在在纽约市附近也遇到了问题。——Justin (koavf)❤T☮C☺M☯ 18:32, 11 January 2022 (UTC)[回复]
有人能再检查一下这篇文章吗？—— Matroc (讨论) 04:07, 12 January 2022 (UTC)[回复]
算了——我重新发布了文章，没有做任何更改，就能看到文章了。一旦我查看了别处又回来，它就显示错误。通过 ?action=purge（清除文章）可以使页面显示。这让我也倾向于考虑内存问题……—— Matroc (讨论) 04:15, 12 January 2022 (UTC)[回复]
  • 我们可以移除该文章中的 Wikidata 调用，而不会造成太大危害。列出的每个机场都有一个指向其 Wikivoyage 文章的维基链接，因此 Wikidata 和 Wikipedia 图标并非真正需要。我们不如鼓励读者点击内部链接阅读我们的文章，而不是去 Wikipedia 或 Wikidata。——Granger (讨论 · 贡献) 19:52, 12 January 2022 (UTC)[回复]
请查看 Airport articles/Sandbox。这篇文章是基于 Module:Marker （目前通过 Template:Listing/sandbox 和 Template:Marker/sandbox）而不是 Module:Map。
如果您比较 Airport articles 和 Airport articles/Sandbox 的 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 (讨论) 14:10, 18 January 2022 (UTC)[回复]
Justin, ThunderingTyphoons!, LPfi, WhatamIdoing, Matroc, Granger: 你们之间的反馈是？
  1. 使用当前模板（坐标 - 以及潜在的其他信息 - 总是从 Wikidata 下载，而不管维基代码中写了什么）
  2. 使用新的模块（不从 Wikidata 下载坐标）
  3. 使用新的修改模块（它只在列表模板中未提供坐标时才从 Wikidata 下载坐标）。
请告诉我，我将按此进行操作，--Andyrom75 (讨论) 08:41, 19 January 2022 (UTC)[回复]
我认为第三种方案应该就可以了，尤其是如果有一个机器人每 [x] 天从 Wikidata 检查并导入坐标的话。——Justin (koavf)❤T☮C☺M☯ 08:43, 19 January 2022 (UTC)[回复]
和 Justin 一样。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 08:49, 19 January 2022 (UTC)[回复]
我乐意接受任何可行的方案。——ThunderingTyphoons! (讨论) 10:09, 19 January 2022 (UTC)[回复]
如果第三种方案易于实现且负担不重，我认为这是理想的解决方案。我们应该将大部分坐标复制到列表中——最迟在模板超时时——但将来仍会不时出现新列表，并且并非所有列表都列出了坐标。导入坐标的机器人会很好，但我认为新机场文章的创建频率足够低，可以手动处理，如果我们养成习惯或在有太多列表缺少坐标时得到提醒。–LPfi (讨论) 10:37, 19 January 2022 (UTC)[回复]
我更喜欢第三种方案，不需要机器人。有时我不需要 Wikidata 的坐标（例如，我想要入口的坐标，但它们想要景点中心的坐标）。 WhatamIdoing (讨论) 16:22, 19 January 2022 (UTC)[回复]
我更喜欢带机器人的第三种方案，该机器人仅在坐标缺失时从文章中下载坐标。有时我们的坐标故意与 Wikidata 的大不相同，例如大型地貌（如河流）的列表是极端的例子。
在其他文章中，在文章中添加坐标的另一个好处是，它可以在全屏地图上显示标记（从目的地文章右上角的图标）。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)[回复]
在没有进一步反馈的情况下，我已经大胆地将新的修改模块投入生产。请及时向我突出显示（并 ping 我）您可能注意到的任何问题。正如预期的那样，User:Buzzy 的页面已自动修复，尽管它花费了将近 8 秒的时间来处理代码（非常接近 10 秒的限制）。另一个页面将如前所述继续随机失败。——Andyrom75 (讨论) 20:02, 20 January 2022 (UTC)[回复]
我认为第三种方案是可行的。
  • 考虑更改编辑器，使其在需要时自动从 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)[回复]

Image parameter does not work anymore

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

今天我在 Tasmanian national parks 上注意到了这一点。我只是忽略了它，因为我认为这是一个单一的文章问题，而且下面已经列出了图片，但似乎是全站范围都发生了。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 07:00, 21 January 2022 (UTC)[回复]
@Andyrom75: 需要再次/更好地测试 他的更改 {{Marker}}。更改前的版本工作正常。—— andree 07:13, 21 January 2022 (UTC)[回复]
FredTC, SHB2000，正如 andree 所说，我确认我需要处理这个问题。目前我专注于坐标。抱歉暂时造成不便。
只有一点。通过“name”参数显示图片相对容易，而且不会影响性能，但是从 Wikidata 下载图片可能会影响页面加载时间（请参阅上面关于坐标的讨论，社区决定选择解决方案 #3）。
我可以遵循同样的方法，但请记住附带的影响。——Andyrom75 (讨论) 09:37, 21 January 2022 (UTC)[回复]
好的，当然。对我来说，哪种都可以。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 09:39, 21 January 2022 (UTC)[回复]
FredTC, SHB2000，现在手动输入的图片已在地图上显示。要使用 Wikidata 图片，我想听听更多反馈。尽管我注意到 module:map 已经做到了，所以我认为不会有更差的性能。——Andyrom75 (讨论) 10:21, 21 January 2022 (UTC)[回复]
我们无法排除从 WD 获取图片，除非运行一个机器人，定期进行 WD->WV 文章同步。这需要非平凡的逻辑来避免覆盖手动输入的图片……IMO，如果一个页面出现超时错误，那就是时候分割它或优化软件/增加限制了。但这个特定的功能是我最喜欢的标记功能，我非常非常强烈反对移除它！ ;-) —— 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)[回复]
我在 Rome/South 上试了一下。左侧的 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)[回复]

Wikipedia icon on listings and markers

在 Southwest National Park 和 Tasmanian national parks 中，我注意到 Wikipedia 图标已更改。有什么原因吗？我更喜欢旧的。——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 creates coords at 0,0

根据 template:see，当 NA 添加到 see 列表时，它应该不创建标记，但如果您查看 Swedish Empire 的“Skattkammaren”，它具有 NA 坐标，标记却出现在 0,0，而应该没有标记。如何修复？ Tai123.123 (讨论) 01:58, 22 January 2022 (UTC)[回复]

@Andyrom75:，您是否不小心做了什么？Yosemite National Park 也是另一个坐标集中在 0,0 的例子。
我只想说省略所有坐标。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 02:00, 22 January 2022 (UTC)[回复]
Tai123.123, SHB2000，我可以修复它，但我很想知道为什么在经纬度参数留空时要插入“NA”？——Andyrom75 (讨论) 08:15, 22 January 2022 (UTC)[回复]
不确定。我通常只是把它留空，但很多文章出于某种原因使用“NA”。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 08:16, 22 January 2022 (UTC)[回复]
Andree，鉴于您过去曾处理过 Template:Marker 和 Module: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
我认为，如果 WD 坐标不正确，则应该删除或更新它们，至少我是这么做的。如果节日地点发生变化，这应该像价格、开放时间等一样定期更新。我仍然看不到那些“NA”坐标的必要性。您认为重新开启这个对话值得吗？——Andyrom75 (讨论) 19:19, 22 January 2022 (UTC)[回复]
在某些情况下可能需要讨论，但我认为不应该总是有标记。我遇到的典型例子是节日（或其他活动）位于一个已列出的场馆。我认为在 directions 参数中指向该场馆比在顶部堆叠两个标记要好。–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 set和Template_talk:Marker#Wikidata lat/longs。可能还有其他讨论，但关键在于WD和WV有不同的目标。所以WD中的坐标可能对WV没有意义，但对维基百科或其他数据挖掘可能很有用。我认为有时只选择我们需要的WD数据并没有什么“丢脸”的，所以NA（Not Applicable）对我来说是可以接受的（但最终，我从未用过它，也不特别在意……）。而且最重要的是，我真的不想再参与这个话题的讨论了——既然你打开了这个潘多拉魔盒，你就得承担论证的责任…… :-P -- andree 20:33, 2022年1月22日 (UTC)[回复]
Andree，听到你这么说我很难过，所以我想告诉你，我曾赤脚在海边散步……对于一月份来说，这确实有点不寻常，但为什么不呢 :-P
回到正题。
在你链接的对话中，我发现了以下几点：
  • 列表可能链接到了错误的Wikidata实体（例如，将组织活动的协会列为活动本身），因此我认为应该删除wikidata参数。
  • Wikidata上的信息是错误的（不仅是坐标），因此我认为应该更新/纠正Wikidata信息，以惠及所有使用Wikidata的WMF项目—然而，请记住，WD信息仅在本地信息缺失时的备用方案。
LPfi，如果我理解你的观点正确的话，你描述的是有两个或多个列表具有相同位置的情况。如果是这样，我认为没问题。想想看，亚洲的商店分布在同一栋建筑的不同楼层，或者西方商场里可以找到不同的餐厅。
尽管如此，如果重新恢复“NA”功能达成真正共识，我会去做的，尽管我认为这是一个好主意。--Andyrom75（讨论）09:29, 2022年1月23日 (UTC)[回复]
不同楼层的商店确实是一种可能的情况，但我想除了在同一个商场里，这种情况很少见，而商场本身可以被单独标示出来，而不是给单个商店标坐标；人们又不是通过GPS在室内导航。重叠的标记是有问题的，因为你无法在不放大查看的情况下看到单独的标记。这当然是一个权衡；我们会为列出的商店和旁边的餐馆设置标记（商场情况除外）。
另一种情况是当一个节日遍布全城。你可能想在一个售票处或类似地点设置标记，但有时这样做会显得牵强甚至误导。你也不会想在游客中心或体育场设置半打活动标记。
–LPfi（讨论）09:59, 2022年1月23日 (UTC)[回复]
LPfi，在亚洲大都市，商店、餐馆等分布在同一栋建筑的不同楼层是很常见的（不是商场，就是普通的N层商业建筑），而且由于它们通常都（一般用当地语言）宣传，要弄清楚该去哪里是非常复杂的 :-D
在我看来，节日就像一个巨大的机场。以JFK或CDG为例。我们有参考坐标来“定位”它，然后如果我们想指出具体的事物（例如，航站楼、租车服务、停车场、商店等），我们仍然可以使用通常与Wikidata无关的标记。
话虽如此，我仍然不赞成“NA”功能，但我会遵循社区的意愿。--Andyrom75（讨论）10:35, 2022年1月23日 (UTC)[回复]
如果坐标在特定情况下有用，当然应该包含它们，就像我之前说的关于相邻商店的情况。NA（Not Applicable）在有（足够多）的例子中，其标记弊大于利时很有用。我在许多情况下都见过它的用处，所以倾向于认为它应该可用。再举一个例子：对于每年都会迁移地点的节日，你说坐标应该更新。是的，应该更新。但明年的地点可能是我无法轻松找到坐标的地方（例如，网站上用我不知道的当地术语称呼的场地），而如果我删除去年的误导性坐标，我只会得到WD中的总部坐标，而总部在另一个城镇。–LPfi（讨论）10:54, 2022年1月23日 (UTC)[回复]
NA（Not Applicable）有用的一个例子是，WD上的坐标是一个关闭的办事处。节日可能会在游客中心售票，但“基于”一个工业区，因为那是他们存储设备的地方。WP仍然想要工业区的办事处地址。
另一个例子是英格兰#保护信托，英格兰遗产委员会拥有一个办事处的坐标，但旅行者感兴趣的是他们管理的城堡等，不应该尝试去拜访办事处。AlasdairW（讨论）10:59, 2022年1月23日 (UTC)[回复]
LPfi，AlasdairW，我认为，如果节日实体中的坐标是组织节日的协会的坐标，那么坐标就是错误的，应该从这里移到协会实体（如果存在的话）。
不过，在此期间，我将着手恢复此功能，但我仍然希望社区的决定能朝另一个方向发展 :-) --Andyrom75（讨论）14:53, 2022年1月23日 (UTC)[回复]
只是加入我的声音——我认为NA（Not Applicable）功能对于上面提到的情况很重要。谢谢你为此努力，Andyrom75。—Granger （讨论 · 贡献）15:16, 2022年1月23日 (UTC)[回复]
我也支持NA（Not Applicable），我过去在某些情况下使用过它，例如当多个兴趣点位于大致相同的坐标时。--评论来自 Selfie City（讨论）（贡献）18:47, 2022年1月23日 (UTC)[回复]
我应该恢复了NA（Not Applicable）功能。请检查并告知我。--Andyrom75（讨论）23:24, 2022年1月23日 (UTC)[回复]
现在好了，谢谢Tai123.123（讨论）23:30, 2022年1月23日 (UTC)[回复]
@Andyrom75：. 有些文章使用N/A。让这种变体也能工作是否很难，还是我们应该查找这样的文章？我没见过n/a，但根据Wiktionary，这是正确的拼写，所以也需要检查一下。–LPfi（讨论）12:07, 2022年2月25日 (UTC)[回复]
LPfi，我建议只使用一种方法来避免使用Wikidata。这种方法将进入模板手册，而已经使用“NA”的文章将清楚地展示它是如何工作的。因此，我建议查找并替换所有其他类似的出现。--Andyrom75（讨论）13:14, 2022年2月25日 (UTC)[回复]
搜索insource:"lat=N/A"只返回了一篇文章。我之前已经处理了几篇。这是查找它们的方法，还是我可能遗漏了？（我也尝试了n/a和等号周围的空格）。LPfi（讨论）13:53, 2022年2月25日 (UTC)[回复]
我想你已经把它们都改好了。--Andyrom75（讨论）14:43, 2022年2月25日 (UTC)[回复]
好的，谢谢。–LPfi（讨论）18:38, 2022年2月25日 (UTC)[回复]

赫尔辛基/中心区元素未显示

Helsinki/Central的地图有问题。页面加载时，地图最初会显示文章中所有元素的地理位置，但随后它们会立即消失，而且无法恢复。可以通过点击文章文本中的元素来查看单个元素，但无法在地图上一次性查看所有元素。赫尔辛基其他子页面的地图似乎工作正常，只有中心区是坏的。这是什么原因？JIP（讨论）19:33, 2022年1月23日 (UTC)[回复]

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

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

问题似乎已经解决了。赫尔辛基/中心区、Faversham和Sittingbourne的地图元素现在工作正常。JIP（讨论）23:38, 2022年1月23日 (UTC)[回复]
JIP，抱歉昨天（近两个小时）的服务中断，但我当时正在处理前一个主题。正如你所见，在你上次发帖前10分钟，我已经解决了。Andyrom75（讨论）09:20, 2022年1月24日 (UTC)[回复]

通过新的模块，我借机对所有具有至少一个标记/列表信息冲突的文章进行了分类，即带有外部链接（url参数）且名称参数为维基链接而非纯文本的。

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

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

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

去年页面浏览量

站点范围的页面浏览量显示去年有一个奇怪的模式。我们有两个大的高峰。第一个高峰，然而，与唯一设备的高峰不相关（第二个高峰则相关）。

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

二月和三月的第一个高峰与2018年二月的高峰相似。对我们很多人来说，那是在接近封锁的时候，所以很可能是由“ armchair travellers”（ armchair travellers）引起的，而八月的第二个高峰则是在旅行更容易的时候。从2020年5月开始，平均每月页面浏览量约为之前月份的三分之二。其他语言的趋势也有一些相似之处。
看看单个文章，《八十天环游世界》的受欢迎程度从九月份的第65位增长到上个月的第4位。一部非常松散地改编自这本书的BBC电视连续剧于12月下旬开始播出，这显然是造成这种情况的原因。AlasdairW（讨论）00:42, 2022年2月6日 (UTC)[回复]

页面底部的相关页面链接

大家好，请问有人能告诉我文章下方显示的相关页面链接的解释在哪里吗？谢谢，• • • Peter (Southwood) (讨论): 13:07, 2022年2月6日 (UTC)[回复]

Template:Confused应被包装在noexcerpt span内

回应我在Wikimedia支持台上的问题，TheDJ解释说问题是由Template:Confused没有被包装在<span class="noexcerpt"> ... </span>中引起的。我建议这样做，因为它对读者/编辑者来说成本很低，并且可以提高与Wikimedia API的兼容性。（其他模板，例如Template:Other uses，已经被包装了。）

我显然有权利自己做到这一点，而且它看起来足够简单，但我并不特别想这样做，因为我对编辑Wikimedia模板的经验为零，而且我不知道它们的陷阱。如果我们同意应该这样做，我希望有经验的人能做出改变。

这似乎是个明智之举，所以我做了更改。如果有人发现任何问题，请检查或撤销。在bug讨论中，也推荐了“role=note”，但我不知道它有什么作用，所以没有添加。LPfi（讨论）14:11, 2022年2月15日 (UTC)[回复]
谢谢。奇怪的是，API调用的“extract”值现在只是一个\n字符。我在想……你的改变会这么快地传播到API吗？该死，我应该在发帖前立即测试的。我想我会等几天再试试，如果它仍然很奇怪，我会在别处跟进。Brycehughes（讨论）14:26, 2022年2月15日 (UTC)[回复]
我把文章中的图片移开了，以防万一有什么奇怪的事情发生。我会看看会发生什么。Brycehughes（讨论）14:40, 2022年2月15日 (UTC)[回复]
我首先尝试将所有内容包含在中，但这导致了“:”不起作用。似乎它使用了第一段，而“:”行被解释为第一行。Extension:TextExtracts没有说明如何解决这个问题。添加一个空行？但span不应该跨段落。HTML的“:”？–LPfi（讨论）15:17, 2022年2月15日 (UTC)[回复]
你认为“:”是TheDJ在回应的后半部分提到的内容吗？我认为他可能是在说我们不应该使用“:”进行缩进，而应该使用他建议的CSS样式——这可能是一石二鸟，但也似乎与我们模板中使用“:”的更大问题有关。我想知道这个CSS样式是否有文档说明。我可以问他在我的MW支持帖子里（虽然我有点讨厌打扰他们）。Brycehughes（讨论）16:55, 2022年2月15日 (UTC)[回复]
是的，对所有这些都可能是。MediaWiki最初应该将“:”渲染为<span ...>，但我猜对于它来说已经太晚了。我不知道在所有模板中将“:”更改为其他内容会有什么副作用，但也许这里的一些技术人员可以评论一下。–LPfi（讨论）2022年2月15日20:22 (UTC)[回复]
好的，我跟进了我的MW帖子。我会报告的。Brycehughes（讨论）2022年2月15日22:35 (UTC)[回复]
嗨LPfi，TheDJ回复了并且好心在那里实现了一些修复。Sun River的提取现在可以工作了，但这只是一个非常简单的解决方案，并且在他的回复中TheDJ指出了一些行动点：1)他提供了一个使用CSS样式来实现缩进的例子，而不是使用“:”；2)注意到Template:Page banner与提取解析器交互时的奇怪之处，他建议我们“绝对在带有国家数据的隐藏span中添加'noexcerpt'”。我承认(1)对我来说有点难以理解，(2)我也不太明白，尽管它似乎是一个能做这件事的人可以快速修复的。所以，有几个问题……你明白(1)和(2)吗？你认为现在是否有任何紧迫性来追求这些修复？TheDJ提到的一项好处是改善了Google索引，这对整个网站来说可能是一个胜利。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！您在使用它时遇到什么问题？您希望看到哪些新功能？我们欢迎所有经验水平和使用各种工作流程的编辑者参与。

这是调查：https://wikimedia.sslsurvey.de/Kartographer-Workflows-EN/

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

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

背景：Wikimedia Germany的技术愿望团队目前正在致力于Kartographer扩展。在过去的几个月里，我们一直在努力解决如何让这个软件在尚未提供此功能的Wiki上使用。在项目的下一阶段，我们计划改进Kartographer本身。由于Kartographer在此Wiki上使用量很大，我们非常希望听到您的经验。有关我们使用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（讨论）2022年3月22日15:48 (UTC)[回复]
已完成。谢谢@WhatamIdoing的提醒。Andyrom75（讨论）2022年3月22日16:35 (UTC)[回复]
哎呀。我才刚看到这个调查。我记得这个扩展程序在穿越180度经线时有问题。如果跨越这条线，点不会并排显示，而是会绕过本初子午线。你可以在斐济的塔韦乌尼看到。 (其他地方，如基里巴斯、阿拉斯加的阿留申群岛、俄罗斯的楚科奇和南极洲也可能存在这个问题)。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上找到此消息的其他语言版本。

问候，

《通用行为准则》（UCoC）修订版执行指南的批准投票过程已于2022年3月21日结束。超过2300名维基媒体人参与了我们运动不同地区的投票。感谢所有参与此过程的人！审查小组目前正在核查投票的准确性，请允许他们最多两周时间完成工作。

投票过程的最终结果将尽快在此公布，以及相关的统计数据和评论摘要。请查阅选民信息页面以了解后续步骤。您可以用任何语言在Meta-wiki上的项目讨论页上发表评论。您也可以通过电子邮件联系UCoC项目团队：ucocproject(_AT_)wikimedia.org

此致，

运动策略与治理

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

掸语维基语行了

shn:正在导入中：这对于那个社区来说是一项令人难以置信的成就，因为这330万 百万说话者分布在缅甸，而且那里没有大的互联网存在，并且存在一些严重的内部困难，不同民族人口众多，所以恭喜他们辛勤的工作，并且တွၼ်ႈ（ကြို+ဆို+ပါ၏）给我们那些为了世界的利益传播自由知识和文化的战友们。(抱歉我所有的掸族新朋友：我太无知了，不知道如何使用感叹词“欢迎”，只知道动词……) —Justin (koavf)❤T☮C☺M☯ 2022年3月23日15:58 (UTC)[回复]

提取失败

V1 Rest API 上大量 Wikivoyage 文章的提取似乎突然丢失了。例如，法国（“extract”字段为空字符串）和纽约市（只有一个换行符）。最近这里有什么变化吗？谢谢。Brycehughes（讨论）2022年3月23日16:41 (UTC)[回复]

@Brycehughes，您能再检查一下吗？Andyrom75（讨论）2022年3月23日16:50 (UTC)[回复]
Andyrom75，仍然是这样。我已经在mw上也问了。Brycehughes（讨论）2022年3月23日16:56 (UTC)[回复]
作为比较，伦敦仍然可用，但比较伦敦和纽约市的文章，我没有看到任何明显区别。Brycehughes（讨论）2022年3月23日17:04 (UTC)[回复]
更新：是页面横幅模板。我在Fada上测试了一下。移除页面横幅模板恢复了REST API摘要调用中的提取。但伦敦也有一个页面横幅模板，所以我真的不确定发生了什么。Brycehughes（讨论）2022年3月23日17:13 (UTC)[回复]
我看到以下输出
X
法国
X
伦敦
可以吗？ --Andyrom75（讨论）2022年3月23日17:27 (UTC)[回复]
请比较这两个的“extract”字段。注意法国的那个是空的（“”，而伦敦的那个有提取（“Noisy, vibrant and truly multicultural…”）。extract字段是网站（如Google的en.wp）用来在搜索结果中创建页面摘要的内容。由于某些原因，现在在大量的（也许是绝大多数）wv页面上似乎都丢失了。mediawiki提取解析器似乎卡住了。Brycehughes（讨论）2022年3月23日17:32 (UTC)[回复]
好吧，这是个疯狂的想法怎么样？我想尽量减少问题，现在我假设问题，或者至少是让解析器卡住的代码，位于Pagebanner模板的某个地方。如果我创建一个新的、临时的模板（不完全确定我是否有权限这样做），然后将Pagebanner模板的代码复制到那个新模板中。然后我选择一个不起眼的页面，比如Fada，在那里我将Pagebanner模板替换成我自己的副本。然后我可以开始删除我自己的模板中的组件，直到我找到导致解析器出错的那一行。如果我的计划成功，我就可以带着这些信息去找MediaWiki解析团队，然后说，“嘿，我认为这段代码正在破坏解析器”。运气好的话，他们就能告诉我这是我们的问题还是他们的问题，甚至是如何解决。这听起来很疯狂吗？如果确实如此，有人有更好的方法来沙盒/开始解决这个问题吗？谢谢，Brycehughes（讨论）2022年3月24日15:40 (UTC)[回复]
不是疯狂的想法。这种方法经常用于查找软件错误：尝试找到触发它的最简单代码。有些错误很难通过这种方式找到，特别是那些以准随机方式出现的错误，例如经常在涉及竞争条件或耗尽某些奇怪资源的情况下。LPfi（讨论）2022年3月24日18:08 (UTC)[回复]
哦……是的……我想我们遇到了一个海森bug。将我的测试模板添加到Fada，提取已正确返回。然后将其恢复为原始页面模板横幅，提取仍然在那里 :facepalm: Brycehughes（讨论）2022年3月24日18:53 (UTC)[回复]
真是太离奇了。恢复提取所需的一切就是删除Pagebanner模板，保存页面，然后恢复它。看来这绝对是Mediawiki的人要处理的事情。大家谢谢。LPfi，也许您有机会删除Template:Test1pagebanner？Brycehughes（讨论）2022年3月24日19:24 (UTC)[回复]
谢谢你的尝试。我暂时保留测试模板，我们可能还需要做一些实验。–LPfi（讨论）2022年3月24日19:40 (UTC)[回复]
说得好，谢谢。Brycehughes（讨论）2022年3月24日19:43 (UTC)[回复]
更新：看起来有一个bug报告是关于这个（或者至少是非常类似的问题）……从11月开始 :/ Brycehughes（讨论）2022年3月25日19:06 (UTC)[回复]

来自WikiSP的重要消息

重要消息

帮帮我们！

我们，西班牙语维基媒体小项目，作为维基媒体基金会的官方分支机构，负责监督运动的所有小型项目，并开展有利于社区的倡议。今天，我们已经请求提供一般性支持，以资助我们的年度行动计划。

我们将做什么？

  • Commons的数据航行：关于如何与Wikidata、Wikivoyage和Commons（仅限eswikivoyage）合作的编辑研讨会，
  • Wikivoyage 10：一场庆祝Wikivoyage成为维基媒体家族一部分十周年的竞赛（所有社区），
  • Wikivoyage 亚洲月：一场您可以撰写与亚洲相关的指南的竞赛（所有社区），
  • Wikivoyage 移动应用程序：一个允许移动访问Wikivoyages的prototype
  • 小型项目大会：一个讨论维基媒体运动所有小型项目、以及未来要实施的协议和想法的大会。

您可以做什么？


我们在这里改变方向，这只有在您的支持下才有可能！


了解更多

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

Wikivoyage的10周年纪念日就要到了？！感觉第五个周年纪念日才刚过去不久。WhatamIdoing（讨论）2022年3月24日18:41 (UTC)[回复]
我2018年不在那儿，但时间过得真快。根据我每周的检查，那个博物馆（也就是“另一个网站”）看起来一天比一天糟。–SHB2000 (讨论 | 贡献 | meta.wikimedia)2022年3月24日20:52 (UTC)[回复]
这是我为即将到来的Wikivoyage 10周年所能做的。一个要发布到YouTube频道的视频。视频-https://drive.google.com/file/d/1b4EJKWyB9bZDibAEmDgGQ0wfPsYCsw-q/view。花了大约2小时。请提出一些更改或更正，并随意批评。Cheers！ :) 2006nishan178713t@lk 2022年3月25日19:41 (UTC)[回复]
@2006nishan178713 视频很棒——我认为没什么可批评的，即使您进行额外的吹毛求疵 ;-) 我唯一要说的是，31000可能很快会变成32000（我们目前有33,757，如果我们设法创建超过700个，那么很快就会变成32000）。SHB2000 (讨论 | 贡献 | meta.wikimedia)2022年3月27日12:14 (UTC)[回复]
是的！2006nishan178713t@lk 2022年3月27日12:44 (UTC)[回复]
而且，当然，它自2003年就存在了，但后来才被采用。它是一个非常早期的MediaWiki wiki。 —Justin (koavf)❤T☮C☺M☯ 2022年3月24日22:08 (UTC)[回复]
如果我们从第一个wikivoyage迁移开始算，是9月23日。如果我们从第一个wikivoyage被接受算起，是1月7日（eswikivoyage）。但我们的生日是1月15日！Galahad（sasageyo!)(esvoy)2022年3月24日23:50 (UTC)[回复]
我记得@GVarnum-WMF之前说过，他曾试图整理一份庆祝生日的列表。我猜Wikivoyages都在1月15日的列表中。 WhatamIdoing（讨论）2022年3月25日16:01 (UTC)[回复]
嗨@WhatamIdoing，你看到这个维基媒体生日列表了吗？MPourzaki (WMF)（讨论）2022年3月30日20:16 (UTC)[回复]
谢谢这个链接，@MPourzaki (WMF)。看起来所有的Wikivoyages都在“需要验证”列表中，并且只有英语和德语分开列出。@RolandUnger和DerFussi，你们能检查一下页面上的德语“生日”吗？据我所知，英语是正确的。WhatamIdoing（讨论）2022年3月31日00:23 (UTC)[回复]
@WhatamIdoing: There are two Wikivoyage birthdays: On Dec. 10, 2006, Wikivoyage went online in Germany as a new project forked from Wikitravel (so Wikivoyage is now 15 years old). On Jan. 15, 2013, Wikivoyage officially became a Wikimedia project. On this day, the Wikipedia turned 12. On Nov. 9, 2012 Wikivoyage was available from Wikimedia servers. On Sep. 23, 2012 the English Wikivoyage was started, in October, 2012 the Netherlandish, French, Swedish and Russian ones followed. In the list mentioned above I added the Italian Wikivoyage which was started on the 1st Wikivoyage birthday. --RolandUnger (talk) 05:09, 31 March 2022 (UTC)[reply]
English Wikivoyage at the Wayback Machine. --RolandUnger (talk) 05:34, 31 March 2022 (UTC)[reply]
I understand it's inconvenient, as the original name has changed hands, but shouldn't we also keep in mind the date when the project was started as a private initiative on a private server? I think that for the early contributors the unfortunate things that happened in-between is a parenthesis that doesn't mean the origins are to be forgotten. –LPfi (talk) 06:46, 31 March 2022 (UTC)[reply]
I think this particular list is only for "official birthdays", which may or may not have much relationship to first edits. Whatever date each Wikivoyage (or other) community prefers to count as their anniversary is the one that belongs in this list. WhatamIdoing (talk) 15:01, 31 March 2022 (UTC)[reply]
I think it's a good idea to write down the history, but that would belong on another page. WhatamIdoing (talk) 15:02, 31 March 2022 (UTC)[reply]
(Aside) Has anyone tried to make 'travel' video content? I am thinking more in the viewn of the Holiday shows the BBC used to have as opposed to "Since the dawn, Time-Life has been presenting it's majestic hyperbole across screens globally. Seldom have the eyes..." type travelouge. 88.97.96.89 14:35, 27 March 2022 (UTC)[reply]
m:VideoWiki lets you make a sort of narrated slideshow. You can include both video and still images. The machine-generated voice option is not impressive, but recording a real voice means that you can't change the text later. WhatamIdoing (talk) 15:46, 27 March 2022 (UTC)[reply]

LintErrors

Thanks to some efforts earlier, I am reasonably satisfied that the 'content' side of English Wikivoyage has been de-linted as far as I am able to without additional expertise.

What remains unlinted is User pages, and what are essentially Talk and discussion namespaces, but a consensus has emerged that these should not be adjusted (even in good faith.)

Congratulations. It only took 4 years to de-lint English Wikivoyage :).

ShakespeareFan00 (talk) 15:54, 13 April 2022 (UTC)[reply]

Where's the discussion about delinting user pages? Ikan Kekek (talk) 16:00, 13 April 2022 (UTC)[reply]
I don't have the specfic discussion to hand, but it was what I had been advised off wiki by a number of contributors (not necessarily directly on Wikivoyage though). In any event non account-holder changes to userspace pages are now generally considered bad practice I've been told. ShakespeareFan00 (talk) 16:29, 13 April 2022 (UTC)[reply]
If you have admin/custodian status and want to resolve the few remaining LintErrors in User and various talk namespaces (most likely signatures that were accepted under previous versions of Mediawiki/HTML/CSS etc.) , I can't stop you obviously. ShakespeareFan00 (talk) 16:31, 13 April 2022 (UTC)[reply]
I don't care about this kind of stuff, but I was asking because I didn't remember seeing a discussion on this topic. Ikan Kekek (talk) 16:57, 13 April 2022 (UTC)[reply]
Also, some consensus on another Wiki does not apply to Wikivoyage. So if you really want to know what people on Wikivoyage think, you have to actually ask them... Ikan Kekek (talk) 17:03, 13 April 2022 (UTC)[reply]
Sure, but what we care about and what we should care about are not necessarily the same thing. —Justin (koavf)❤T☮C☺M☯ 21:08, 13 April 2022 (UTC)[reply]
I think the work in mainspace was good, as broken syntax may result in broken pages for some readers. For user space, more discussion would be needed. For some users it is no problem – many like other contributors fixing things on their user pages – for others it may be problematic, especially if the fix breaks something else and they aren't here to revert or complain. –LPfi (talk) 07:36, 14 April 2022 (UTC)[reply]
There is a table of the lint errors at fireflytools. For things such as the obsolete font tags, if those were to be fixed by updating them to span tags, then I think that should be done by via a bot account. -- WOSlinker (talk) 11:17, 14 April 2022 (UTC)[reply]
See also Special:LintErrors. The "high priority" items are generally things that have the potential to make a page look visibly broken. Ideally there would be none of those in any namespace, though obviously many people will decide that it is not worth their own time and efforts to fix problems in low-traffic user pages. I wouldn't be inclined to stop anyone from fixing errors anywhere. WhatamIdoing (talk) 16:01, 14 April 2022 (UTC)[reply]
I notice that a dive site template has "bogus file parameters" of (NNNpx). This seems to be explanatory text in examples. How do we normally handle that? –LPfi (talk) 17:16, 21 April 2022 (UTC)[reply]

A popular article writing competition CEE Spring (about Central and Eastern Europe; now with special subcategory about Esperanto) is happening on the English Wikipedia until the 31st May 2022. I warmly invite you to participate, write some article and win a valuable prize! If you have question, I will happily answer it on the competition page talk.

Also, for more wide outreach, I have just asked for a CentralNotice, which should appear also in this project. If you have a comment on the request, you are welcome to write it on the request page. --KuboF Hromoslav (talk) 18:30, 3 May 2022 (UTC)[reply]

Better still for this wiki, write Wikivoyage articles about Central and Eastern Europe. Nurg (talk) 05:06, 4 May 2022 (UTC)[reply]

Movement Strategy and Governance News – Issue 6

运动策略与治理新闻
Issue 6, April 2022Read the full newsletter

Welcome to the sixth issue of Movement Strategy and Governance News! This revamped newsletter distributes relevant news and events about the Movement Charter, Universal Code of Conduct, Movement Strategy Implementation grants, Board of trustees elections and other relevant MSG topics.

This Newsletter will be distributed quarterly, while the more frequent Updates will also be delivered weekly. Please remember to subscribe here if you would like to receive future issues of this newsletter.


  • Leadership Development - A Working Group is Forming! - The application to join the Leadership Development Working Group closed on April 10th, 2022, and up to 12 community members will be selected to participate in the working group. (continue reading)
  • Universal Code of Conduct Ratification Results are out! - The global decision process on the enforcement of the UCoC via SecurePoll was held from 7 to 21 March. Over 2,300 eligible voters from at least 128 different home projects submitted their opinions and comments. (continue reading)
  • Movement Discussions on Hubs - The Global Conversation event on Regional and Thematic Hubs was held on Saturday, March 12, and was attended by 84 diverse Wikimedians from across the movement. (continue reading)
  • Movement Strategy Grants Remain Open! - Since the start of the year, six proposals with a total value of about $80,000 USD have been approved. Do you have a movement strategy project idea? Reach out to us! (continue reading)
  • The Movement Charter Drafting Committee is All Set! - The Committee of fifteen members which was elected in October 2021, has agreed on the essential values and methods for its work, and has started to create the outline of the Movement Charter draft. (continue reading)
  • Introducing Movement Strategy Weekly - Contribute and Subscribe! - The MSG team have just launched the updates portal, which is connected to the various Movement Strategy pages on Meta-wiki. Subscriber to get up-to-date news about the various ongoing projects. (continue reading)
  • Diff Blogs - Check out the most recent publications about Movement Strategy on Wikimedia Diff. (continue reading)

Zuz (WMF) (talk) 10:27, 13 April 2022 (UTC)[reply]

Join the Wikimedia Foundation Annual Plan conversations with Maryana Iskander

你好，

The Movement Communications and Movement Strategy and Governance teams invite you to discuss the 2022-23 Wikimedia Foundation Annual Plan, a plan of record for the Wikimedia Foundation's work.

These conversations continue Maryana Iskander's Wikimedia Foundation Chief Executive Officer listening tour.

The conversations are about these questions

  • The 2030 Wikimedia Movement Strategy sets a direction toward "knowledge as a service" and "knowledge equity". The Wikimedia Foundation wants to plan according to these two goals. How do you think the Wikimedia Foundation should apply them to our work?
  • The Wikimedia Foundation continues to explore better ways of working at a regional level. We have increased our regional focus in areas like grants, new features, and community conversations. What is working well? How can we improve?
  • Anyone can contribute to the Movement Strategy process. Let's collect your activities, ideas, requests, and lessons learned. How can the Wikimedia Foundation better support the volunteers and affiliates working in Movement Strategy activities?

You can find the schedule of calls on Meta-wiki.

The information will be available in multiple languages. Each call will be open to anyone to attend. Live interpretation will be available in some calls.

此致，

Zuz (WMF) (talk) 09:49, 15 April 2022 (UTC)[reply]

Let's talk about the Desktop Improvements

大家好！

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 April 2022 at 13:00 UTC and 18:00 UTC on Zoom. Click here to join. Meeting ID: 88045453898. Dial by your location.

议程

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

形式

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English, French, Italian, and Polish. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 00:35, 26 April 2022 (UTC)[reply]

Is this about Vector 2022? I won't be at the meeting, but I certainly don't like the development. Luckily, Monobook is still there for me. I made a comment at their feedback page, but last I checked (long after I made the comment) nobody had answered. My primary concern is that the layout is miserable unless you have a wide enough browser window (I like narrow ones), and that many important links are hidden to have a "cleaner" look (mostly in a drop-down menu; I even cannot just type in an article name, I have to either maximise the window first, or go to the search page, or just edit the URL in the browser's address field). –LPfi (talk) 10:01, 26 April 2022 (UTC)[reply]
Pinging @SGrabarczuk (WMF). LP, it sounds like your screen is narrower than the header, with the result that the search box (which AIUI is meant to be both bigger and centered than in the 2010 version of Vector) is missing/collapsed/unusable. Is that right? WhatamIdoing (talk) 15:11, 26 April 2022 (UTC)[reply]
If anyone wants to see the options, click these links
These links won't change your preferences. They'll only load the skin for this one page/one time. WhatamIdoing (talk) 15:14, 26 April 2022 (UTC)[reply]
Yes. My browser window is narrower than the header. Not my screen though, but I use several windows, e.g. to see a Wikipedia page and a map while I am editing a Wikivoyage guide. I have yet to understand why people keep to the one-application-at-the-time style from before windowing systems were introduced. The alt-tab function helps a bit, but that I used (shift-control-^, if memory serves) already with the VT220 text terminals of the 1980s. Thanks for the skin links. –LPfi (talk) 16:31, 26 April 2022 (UTC)[reply]
And it's not only the header. The left-margin menu pushes down the content, so that I have to scroll down every time I load a new page. Very frustrating. –LPfi (talk) 16:34, 26 April 2022 (UTC)[reply]
Hey @LPfi, I'm sorry for not answering! Let me answer your questions here.
  • As for the left-margin menu, if you collapse it, it should stay collapsed and not push down the content.
  • Regarding the question you asked on the project talk page ("does the empty space to the right of the margin menu really give the best possible experience") we are still building the new interface, one feature improvement at a time. The empty space you have referred to is temporary. Now, we're working on page tools which will make a clear distinction between wiki-wide links (like Recent changes) and page-related links (like Related changes) and bring balance to the space on both sides of the content area.
  • The narrow screen... I'll talk about that with the team. Generally, we are aiming to make the interface usable on narrow screens or vertical screens (although not mobile). We're trying to keep the minimal threshold of the default experience as narrow as possible.
  • In this context, that thing with the left-margin menu and other things... I think it'd fit to the last phase of the project when we'll be working on aesthetic refinements to the entire interface (as opposed to improving individual features).
SGrabarczuk (WMF) (talk) 16:50, 26 April 2022 (UTC)[reply]
  • Thanks for the tips on collapsing the menu. I didn't notice that possibility. However, when I tested it now, I had to collapse it separately on any new page when following links.
  • Nice that you'll get rid of the empty space. When I tried the skin, I did not find any discussion on unsolved problems or on which deficiencies were about yet unimplemented aspects and which were intended features. I might not have looked deep enough. Separation between page tools and other links seems a good goal; I hope the links will still be easily available to users like me, who know the links and can disregard those not needed at the moment (a need you seem to acknowledge).
  • Really nice. As of now I got some of the problems with my default window width, while others surfaced with width I use only occasionally. It is important though, to be able to get a narrow window in certain situations, and being able to get rid of the left margin is then an immense help. I hope the suggested new placement of the table of contents won't infer with this.
    (I think it is important to make the distinction between window and screen size explicit in any design discussion, as common or realistic widths of the former aren't restricted to those of the latter, and I have seen web pages that adjust to the latter, more or less ignoring the former, which should be the relevant one.)
  • OK, you know better when and how to do those things, they just should be fixed before general roll-out.
–LPfi (talk) 09:02, 27 April 2022 (UTC)[reply]
Ah! Now the collapsing worked. I hadn't enabled Javascript for the Mediawiki site, and enabling it did not have immediate effect. Hm. I have enabled Javascript for all Wikimedia projects I visit regularly, but I am a regular contributor. Is the casual visitor with Javascript disabled (for all or some of the domains) a use case you take into consideration? –LPfi (talk) 09:07, 27 April 2022 (UTC)[reply]

2022 Board of Trustees Call for Candidates

You can find this message translated into additional languages on Meta-wiki.

The Board of Trustees seeks candidates for the 2022 Board of Trustees election. Read more on Meta-wiki.

The 2022 Board of Trustees election is here! Please consider submitting your candidacy to serve on the Board of Trustees.

The Wikimedia Foundation Board of Trustees oversees the Wikimedia Foundation's operations. Community-and-affiliate selected trustees and Board-appointed trustees make up the Board of Trustees. Each trustee serves a three year term. The Wikimedia community has the opportunity to vote for community-and-affiliate selected trustees.

The Wikimedia community will vote to fill two seats on the Board in 2022. This is an opportunity to improve the representation, diversity, and expertise of the Board as a team.

Who are potential candidates? Are you a potential candidate? Find out more on the Apply to be a Candidate page.

Thank you for your support,

Movement Strategy and Governance on behalf of the Elections Committee and the Board of Trustees

Zuz (WMF) (talk) 12:53, 26 April 2022 (UTC)[reply]

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

The Community Affairs Committee of the Wikimedia Foundation Board of Trustees would like to thank everyone who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC).

While the Enforcement Guidelines did reach a threshold of support necessary for the Board to review, we encouraged voters, regardless of which way they were voting, to provide feedback on the elements of the enforcement guidelines that they felt needed to be changed or fixed, as well as why, in case it seemed advisable to launch a further round of edits that would address community concerns.

Foundation staff who have been reviewing comments have advised us of some of the emerging themes, and as a result we have decided as Community Affairs Committee to ask the Foundation to reconvene the drafting committee and to undertake another community engagement to refine the enforcement guidelines based on the community feedback received from the recently concluded vote.

Further, we are aware of the concerns with the note 3.1 in the Universal Code of Conduct Policy. We are directing the Foundation to facilitate a review of this language to ensure that the Policy meets its intended purposes of supporting a safe and inclusive community, without waiting for the planned review of the entire Policy at the end of year.

Please visit here to read the full announcement.

Best, Zuz (WMF) (talk) 11:53, 28 April 2022 (UTC)[reply]

Make working with templates easier: One more improvement coming soon.

Hello, one more change from WMDE’s focus area “Templates” is coming to your wiki soon: In syntax highlighting (CodeMirror extension), you’ll be able to activate a colorblind-friendly color scheme with a user setting. (project page)

Deployment is planned for May 10. This is the last set of improvements from WMDE’s focus area “Templates”. We would love to hear your feedback.

Thanks for being one of the first wikis to get the improvements from our project, and for giving valuable feedback! – Johanna Strodt (WMDE) (talk) 09:55, 29 April 2022 (UTC)[reply]

FYI: Relevant social network/app

https://travelfacets.com/ —Justin (koavf)❤T☮C☺M☯ 20:33, 1 May 2022 (UTC)[reply]

Editing news 2022 #1

Read this in another language • Subscription list for this multilingual newsletter

New editors were more successful with this new tool.

新建主题工具可以帮助编辑者在讨论页上创建新的==章节==。新编辑者使用这个新工具会更成功。你可以阅读报告。很快，编辑团队将为所有参与测试的 20 个维基百科的编辑者提供此功能。你可以在特殊:偏好设置#讨论编辑中将其关闭。

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 关于奥地利-匈牙利帝国大部分是正确的，但他们在中国有一个租界，这实际上就是一个殖民地，尽管规模很小。我认为我们可以仅限于那些源自发现时代的欧洲式殖民帝国。日本也包含在内，因为尽管它不是西方国家，但日本是借鉴了西方的殖民主义模式。我认为奥斯曼帝国没有殖民地，这也是我最初没有包括它的原因，但我可能错了。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 和类似的食物爱好者模板，美国内战的模板是给美国历史爱好者，澳大利亚野生动物模板是给野生动物爱好者。有没有帝国爱好者会觉得这个模板有用？——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#Weblinks、de:Südamerika 或 de:Southland#Weblinks 中可以看到。我们可以效仿 de.voy，但我不是 fan de.voy 把它们塞进几乎所有地区性文章。SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月5日 10:05 (UTC)[回复]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘我不知道关于殖民主义的旅游话题会如何运作。我不认为有任何关于殖民主义本身的纪念碑。但另一方面，在异国他乡有许多纪念碑和建筑，它们是各自宗主国殖民统治遗产的象征。例如，如果你去河内，有很多法国殖民建筑，同样，如果你去仰光，也有很多英国殖民建筑。The dog2 (讨论) 2022年5月5日 15:09 (UTC)[回复]

我不确定人们是否会为了看殖民主义的纪念碑而去旅行，所以我不太确定创建这样一个页面是否有意义。我不知道有什么纪念碑是纪念殖民主义这个普遍概念的，但有很多纪念碑是纪念殖民主义的当地历史的。例如，看看美洲的克里斯托弗·哥伦布雕像，或者加州的皇家大道沿线的钟。维基百科w:en:Colonial empire#List of colonial empires的长度让我觉得“殖民历史”与“亚历山大大帝以来的世界历史”有很大重叠。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 Elizabeth。SHB2000 (讨论 | 贡献 | 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插入到那里的十一个链接的文章中，而是在瑞典#了解和Wismar#了解等地方写句子，链接到瑞典帝国，甚至在西班牙帝国和葡萄牙帝国等文章中写句子来解释它们是竞争对手。我们不会假设读者在看旅游指南时想比较所有帝国的文章列表，包括那些彼此毫无关联的帝国。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)[回复]
这些不是关于帝国主义总体的文章。这些文章包含可以去看某个帝国统治遗迹的列表。关于帝国主义总体的文章不属于维基旅，除非有帝国主义的纪念碑是旅游景点。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：当然，可以写一篇关于俄罗斯在美殖民遗产的优秀旅游文章。如果写了，我认为俄属美洲不是一个好的标题，因为有几波来自俄罗斯/苏联的移民与俄罗斯在美洲的殖民主义无关。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)[回复]
这将取决于模板的范围。如果只包含现代帝国，那么我就不会将其包含在内。现代帝国主义通常是仅限于欧洲帝国。奥斯曼帝国也因此而有争议。理想情况下，我会将奥斯曼帝国和莫卧儿帝国以及其他一些帝国归类为火药帝国，放在姊妹模板中，或者在这个模板中作为第二组（其范围将是现代帝国）。我自己的分类会是这样的：
现代帝国主义帝国1
奥匈帝国 • 大英帝国 • 丹麦帝国 • 荷兰帝国 • 法兰西殖民帝国 • 日本（殖民）帝国 • 葡萄牙帝国 • 俄罗斯帝国 • 西班牙帝国 • 瑞典帝国。
火药帝国
中国（帝国）2 • 莫卧儿 • 奥斯曼 • 日本（前现代） • 萨法维
(1) 这可以称为欧洲帝国，但包含日本就不太合适了。然而，它的殖民帝国很大程度上是作为对欧洲帝国主义的回应而形成的，所以这个名称并无不妥，只是不够直观。
(2) 我对中国历史不太熟悉，但我认为这主要包括明朝和清朝。
如果有其他帝国可以包含，请告诉我，我会更新这个列表。Wauteurz (讨论) 2022年5月8日 10:55 (UTC)[回复]
如果你说的是公元1200年至今存在的帝国，那么莫卧儿帝国就不能被排除（我也不知道你所谓的“现代帝国”是什么意思：它无疑是一个庞大的帝国，征服了大量领土并四处施压），但它是一个遭受殖民主义侵害的帝国，而不是殖民帝国。此外，非洲也有类似的帝国。我会注意到，我们现在的情况是荒谬的，在这个帖子中，大家普遍（或近乎普遍）反对使用此模板，但在Wikivoyage:删除投票#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)[回复]
我认为军备技术上的差异对于旅行者来说并不太相关。我建议的替代方案是，在君主制条目中包含一个关于帝国的链接部分，并为每个帝国提供一个单行列表。这样，就不需要导航栏，也不需要就任何分类达成一致。 Ikan Kekek (讨论) 2022年5月8日 19:29 (UTC)[回复]
再次简化地说，俱乐部和长矛与步枪和火枪的吸引力不同。前者可以被视为原始的，而后者可能更先进。我认为你低估了技术差异。对于一些有历史兴趣的人来说，它们有非常不同的吸引力。我之前在删除投票讨论中指出的，与君主制的联系太牵强，无法很好地发挥作用。
老实说，我赞成不设导航栏，但一个合适的替代品肯定能为旅行者带来好处，原因我在删除投票讨论中已经说明了。一个关于殖民主义、帝国或帝国主义的总体性文章可以带来好处，尽管受众可能有些小众，但我们已经有很多小众条目了，所以这不应该是个问题，对吧？ Wauteurz (讨论) 2022年5月8日 20:10 (UTC)[回复]
我认为技术差异对旅行者可以从帝国那里看到的景点的壮观程度没有影响。老实说，没有什么比古埃及的金字塔和狮身人面像更令人印象深刻了，但我没有亲眼见过。我见过泰姬陵、德里和阿格拉的红堡、中国长城以及婆罗浮屠和普兰巴南的寺庙群，更不用说帕特农神庙、庞贝、赫库兰尼姆、古罗马广场和尼姆的方形宫了。不过，我跑题了。你将看到，我倾向于在删除投票讨论中创建一个经过仔细界定且与旅行高度相关的关于殖民主义的条目。如果这个条目从古代腓尼基人开始；有免责声明说明该主题具有争议性，但由于这是一个旅行指南，我们只是在描述；并规定我们专注于海外殖民，那么我将没有意见。 Ikan Kekek (讨论) 2022年5月8日 20:30 (UTC)[回复]

[悬挂]
我不认为关于帝国的条目是作为一系列关于殖民主义的条目而写的。我不太乐意看到一个模板让人们觉得它们是这样的。如果我们想要一个模板，为什么不围绕帝国本身，或者历史疆域呢？我认为阅读历史帝国的人很可能对历史疆域感兴趣（尽管可能不是全部）。假设他们对殖民主义感兴趣是草率的。当然，有些人是。但很多人可能对他们正在阅读的帝国其他方面感兴趣：它的语言、它的现代继承者、它的城市、它的艺术，等等。

我的印象是，这个模板的出现是因为有人想要一个关于殖民主义的条目，而这是他们认为可以获得的。我认为我更倾向于殖民主义条目。看起来在可预见的未来，没有人会写一个关于这个主题的好的、全面的旅行条目，但一个包含一两段关于殖民帝国的内容，链接这些以及相关条目（如欧洲历史和发现时代），然后讲述容易看到（或研究）几个殖民帝国遗产的目的地——并检查目的地条目是否涵盖了这些方面，怎么样？

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

供大家知悉，我已将已删除的美国殖民主义草稿移至我的用户空间，我也乐于接受他人的编辑。我认为我们可以将范围扩大到包括美国的西进扩张，以及纪念美洲原住民灭绝等事件的地点。我正在尝试添加实际提醒人们美国殖民统治遗迹的地点列表，以便能够将其重新发布到条目空间。The dog2 (讨论) 2022年5月12日 15:17 (UTC)[回复]
这个页面的受众是谁？你想象中会使用这个指南的旅行者是怎样的？ WhatamIdoing (讨论) 2022年5月12日 15:49 (UTC)[回复]
面向那些希望看到美国殖民统治在世界不同地区遗迹的人。类似其他殖民帝国条目的内容。但正如Ikan Kekek所提到的，美国殖民主义很大一部分是通过种族灭绝美洲原住民、用白人定居其土地，后来在白人人口足够多的时候授予殖民地州权来实现的。所以，虽然我们已经有了一个老西部条目涵盖了美国殖民主义的这一方面，但我认为至少应该在美国殖民主义的条目中提到这一点，但条目的重点是列出你可以去探索美国殖民统治遗迹的海外地点。The dog2 (讨论) 2022年5月12日 17:12 (UTC)[回复]
这样的人多吗？
我可以轻易想象出有人想了解一个国家的历史。例如，如果你对菲律宾感兴趣，那么你就会对西班牙殖民（16至19世纪）、美国殖民（20世纪前半叶）和日本殖民（二战前后几年）感兴趣。我很难想象一个人会说“我的目标是看遍<某个国家>殖民过的所有地方”。没有旅行者的心理图景，很难就哪种信息可能对条目有用或相关形成假设。 WhatamIdoing (讨论) 2022年5月13日 16:08 (UTC)[回复]

招募选举志愿者

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

选举志愿者计划的想法出现在2021年维基媒体基金会理事会选举期间。该计划被证明是成功的。在选举志愿者的帮助下，我们能够将2017年的选民数量增加了1753人，从而提高了选举的宣传和参与度。总体投票率为10.13%，比2017年高出1.1个百分点，214个维基参与了此次选举。2017年未参与的74个维基在2021年的选举中产生了选民。你能帮助改变今年的参与度吗？

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

  • 在社区频道翻译简短信息并宣布正在进行的选举进程
  • 可选：监控社区频道中的社区评论和问题

志愿者应

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

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

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

2022年夏季维基旅行，科索沃和阿尔巴尼亚

大家好！

2022年5月20日至22日，阿尔巴尼亚语维基媒体用户组将举办2022年夏季维基旅行编辑马拉松，以改进科索沃和阿尔巴尼亚的旅游和旅行目的地内容。今年，我们将重点关注阿尔巴尼亚东南部，但欢迎所有改进。如果您与我们一起编辑，请随时加入我们在5月20日至21日（周六和周日）的Jitsi会议，时间为9:30 - 17:00（GMT+2）时区。这是阿尔巴尼亚和科索沃探险页面。您也可以在不参加通话的情况下进行编辑。请在外展仪表板上注册，以追踪编辑马拉松的贡献。谢谢！--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：我刚才又进行了一次更新，但我不确定Wikivoyage:Kosovo Expedition上的数字是怎么回事。 SHB2000 (讨论 | 贡献 | meta.wikimedia) 2022年5月23日 08:07 (UTC)[回复]

我们来谈谈桌面改进

大家好！

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

加入与负责桌面改进的团队的在线会议！会议将于2022年5月17日 12:00 UTC 和 19:00 UTC 在Zoom上举行。点击这里加入。会议ID：86217494304。根据你的地点拨打。

议程

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

形式

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

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

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

我们期待见到你！SGrabarczuk (WMF) (讨论) 2022年5月14日 05:02 (UTC)[回复]

免责声明：Szymon（又名User:Tar Lócesilion）是我的同事。我没有和他谈过这件事，他也不知道我在这里发帖。
我一直在思考“新Vector”（Vector 2022）这个变化。我认为维基旅行应该做出这个改变。最近（以维基百科为中心）的市场研究表明，读者认为旧设计（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)[回复]
左侧边栏菜单在窄窗口上将内容向下推是一个无法容忍的问题，如果它影响很多人。该皮肤真的经过充分测试以投入生产，使其“看起来像一个现代、最新的”皮肤吗？维基旅行者可能通过奇怪的硬件和不稳定的连接访问网站，因此需要认真考虑如何进行功能测试。 –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)[回复]

帮助归档讨论页

能否有人帮我归档Talk:Bulgaria？我已经将旧评论复制到一个子页面，并将子页面链接到了主讨论页，你们只需要删除旧的讨论。我不能这样做，因为我太新了，这样做会触发页面清空过滤器。我想开始一个新的关于地区的讨论，而讨论页上旧的东西让它变得难以处理。 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)[回复]

桌面改进更新

将其设为新的默认设置

大家好。我想向大家汇报一下桌面改进项目的情况，维基媒体基金会网络团队已经为此工作了几年。我们的工作几乎完成了！🎉

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

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

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

最新功能
  • 目录 - 我们的版本更容易访问，可以了解页面上下文，并在不滚动的情况下导航页面。它目前正在我们的试点维基上进行测试。它也可供选择使用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日 UTC时间12:00 和 19:00 在Zoom上举行。 点击此处加入。会议ID：5304280674。 通过您的位置拨打。以下活动将于7月12日和7月26日举行。

会议不会被录制或直播。会议记录将保存在一个Google Docs文件中，并复制到Etherpad。 Olga 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>标签，但我后来可能复制粘贴了它（如果我必须在发布一个半成品帖子之前去其他地方调查的话，有时会这样做）。
我后来还发现，这个在wikivoyage上实现的软件版本（它与其他我参与的wmf-wiki不同）有两种可选的输入模式（未公开？）。
  • 可视化
和
  • 来源
我认为我最初默认使用的是可视化模式，但现在默认使用的是源代码模式，而且我还看到了一个预览窗格，以前没有，我猜？如果我能添加一个编辑摘要，那就更好了，我在其他地方使用（我们称之为）回复软件时就可以做到。
希望我的这个混乱的回复还能说得通？ Ottawahitech (讨论) 2022年6月26日 14:41 (UTC)[回复]
点击版权/许可声明上方的“高级”选项。大多数人在讨论中不使用有意义的/自定义的编辑摘要，但如果你愿意，可以添加一个。 WhatamIdoing (讨论) 2022年6月26日 19:18 (UTC)[回复]
编辑摘要对于讨论也很有用，尤其是在像茶馆这样繁忙的页面上。经常有这样的情况，一些讨论串走向了一些不太有趣的道路，我只有在有人提出新观点（在编辑摘要中提及）时才会阅读它们。当几个讨论串都有新帖子时，我可能会错过一些，除非编辑摘要在监视列表上引起了我的注意。而最令人恼火的是：在不告知摘要的情况下修改现有帖子——我滚动到讨论串的末尾，找不到新的内容，检查之前的缩进帖子，也找不到，搜索今天的日期，没有匹配，然后点击历史记录和差异，最终才发现措辞或其他方面的改变，而这些改变常常没有增加任何我已阅读过的内容的价值。请写上“ce”或别的什么。–LPfi (讨论) 2022年7月1日 12:38 (UTC)[回复]

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

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

欢迎来到第7期运动战略与治理新闻！本新闻通讯将分发关于维基媒体运动战略建议实施、运动治理相关主题以及维基媒体基金会运动战略与治理（MSG）团队支持的各种项目和活动的最新消息和活动。

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

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

其他新闻和更新：一个讨论运动战略实施的新论坛、即将举行的维基媒体基金会理事会选举、一个讨论运动战略的新播客，以及基金会运动战略与治理团队的人员变动。（继续阅读）

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

公布2022年理事会选举的六名候选人

大家好，

成员组织代表已完成投票期。选出的2022年理事会候选人是

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

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

请花点时间感谢参与此过程并帮助扩大理事会能力和多样性的成员组织代表和分析委员会成员。这些志愿工作 hours 让我们跨越了理解和视角的鸿沟。感谢您的参与。

感谢那些挺身而出成为理事会候选人的社区成员。考虑加入理事会并非易事。候选人迄今为止所付出的时间和奉献精神，证明了他们对这个运动的承诺。祝贺那些被选中的候选人。对那些未被选中的候选人表示极大的赞赏和感谢。请继续与维基媒体分享您的领导才能。

选民现在可以做什么？

查看成员组织选择流程的结果.

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

顺颂,

运动策略与治理

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

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

另类独立文化

有人知道任何维基旅行语言中的另类独立文化方面的优秀指南吗？--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上为您想包含在选举指南中的陈述投票。

选举指南是一个工具，旨在帮助选民选择最符合其信仰和观点的候选人。社区成员将通过李克特量表（同意/中立/不同意）提出候选人回答的陈述。候选人对陈述的回答将被载入选举指南工具。选民将通过输入他们对陈述的回答（同意/不同意/中立）来使用该工具。结果将显示最符合选民信仰和观点的候选人。

以下是选举指南的时间表

  • 7月8日 - 20日：志愿者为选举指南提出陈述
  • 7月21日 - 22日：选举委员会审查陈述的清晰度并删除无关陈述
  • 7月23日 - 8月3日：志愿者对陈述进行投票
  • 8月4日：选举委员会选出排名前15的陈述
  • 8月5日 - 12日：候选人与陈述对齐
  • 8月16日：选举指南开放供选民使用，以帮助指导其投票决定

选举委员会将于8月初选出排名前15的陈述


顺颂,

运动策略与治理

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

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

2022年维基媒体基金会理事会选举延迟

大家好，

我今天来是想通知大家关于理事会选举投票时间安排的最新情况。

正如大家所知，今年我们提供了一个选举指南，以帮助选民在一些关键议题上了解候选人的立场。几位候选人请求延长其回答的字符限制，以更详细地阐述他们的立场，选举委员会认为他们的理由符合公平公正选举的目标。

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

尽管预计并非所有人都会使用选举指南来指导他们的投票决定，但选举委员会认为，在投票期开始时提供必要的翻译，以便社区成员在不同语言中使用，从而做出这个重要决定，是更合适的。

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

您可以在此处找到此消息的更多语言翻译。

此致，

代表选举委员会

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

邀请加入运动战略论坛

大家好，

运动战略论坛（MS Forum）是一个多语言的协作空间，用于所有关于运动战略实施的对话。它提供了一个分享您的运动战略（MS）工作、寻找合作者以及获得更多支持和想法的绝佳机会。我们邀请所有运动参与者在MS论坛上进行协作。论坛的目标是通过一个包容的多语言平台来建立社区协作。

运动战略是为构想和构建维基媒体运动的未来而进行的合作努力。任何人都可以为运动战略做出贡献，从评论到全职项目。

使用您的维基媒体账户加入此论坛，在此处打个招呼，然后随意加入或发起您最关心的建议的对话！您可以讨论您的MS项目想法和计划，甚至您曾参与过的MS项目的报告。为了开始，您还可以观看此视频。

运动战略与治理团队（MSG）于5月提出了MS论坛的提案。经过为期2个月的评审期，我们刚刚发布了社区评审报告。它包括了讨论摘要、指标以及关于后续步骤的信息。

我们期待在MS论坛上见到您！

此致，

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

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

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

大家好，

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

如果您已准备好投票，请前往SecurePoll投票页面投票。 您可以在8月23日00:00 UTC至9月6日23:59 UTC之间投票。 要查看您的投票资格，请访问投票资格页面。

顺颂,

运动策略与治理

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

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)[回复]

《通用行为准则》修订执行草案指南

大家好，

《通用行为准则》执行指南修订委员会（Universal Code of Conduct Enforcement Guidelines Revisions committee）正在征求关于《通用行为准则》（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，在此提出一个建议，即让一些维基旅行社区自愿成为一个开发团队的“测试维基”。

背景：网页浏览器不“理解”维基文本。它们理解HTML。所以我们用维基文本写作，但它会被转换（“解析”）成HTML。我们看到的，除了维基文本编辑器本身内部，就是解析后的HTML。旧的解析器非常非常老旧（以软件术语来说），并且正在被替换，取而代之的是一个新解析器。旧解析器没有正式名称，但传统上被称为“PHP解析器”（以其编写所用的软件语言命名）。较新的解析器称为“Parsoid”。新解析器基本上做了同样的事情，外加一些额外的功能，并删除了几个旧的bug（并且可能增加了几个新bug，但那些技术上不属于计划的一部分;-)）。

项目：最终，旧的PHP解析器将被删除，Parsoid将取而代之。他们最近一直在研究它如何处理图像（主要的Phab任务：T314318）。图像部分已经在mw:上运行，并且似乎运行良好。我在那里做了一些相当复杂的事情（例如，翻译页面上的图库），没有任何问题。事实上，我从未注意到他们切换了解析器。这应该是一个无缝的过渡，而我的体验也是如此。他们想在更多维基上进行测试。

我的想法：我认为我们应该自愿。首先，这最终会在这里实现，所以如果从一开始它对我们来说是好的，那就更好了。我不希望Wikivoyage（它在图像处理方面有一些不寻常的做法，例如页面横幅）成为事后诸葛亮。其次，如果现在出了什么问题，我们将在修复列表的最前面，并有一支开发团队随时提供帮助（或者如果不能立即修复，则立即恢复到旧解析器）。这种亲密的 Hands-on 支持可能发生在例如我们是部署列表的第3位时，而在常规部署过程中，当他们认为工作已完成时，就不太可能发生。仅仅从实际角度来看，如果您同一天向500个维基部署软件，那么如果出现问题，它们不可能都是首要的。但如果您本周是唯一的，那么您自动就是首要的。第三，这个团队非常仔细地进行工作。他们有一个系统，可以识别出整个页面上单个像素的变化！所以我认为我们会得到很好的照顾。

所以我在问你们：你们是否愿意让我们排在最前面？如果你们都认为没问题，那么我可以正式向团队提出请求，让他们考虑我们。 Whatamidoing (WMF) (讨论) 2022年8月24日 04:49 (UTC)[回复]

支持。根据WV:IP，我们通常不使用很多图片，所以显著的改变不会影响很多页面。很高兴开发人员将此维基列为优先事项，并且鉴于您已经说服了我，我全力支持。
尽管“图像使用极少”，但旅行指南的几乎每一页都有图像，所以如果有什么大问题，会影响很多页面。但如果发生了，最好能让开发者全力关注，对吧？既然无论如何都会发生，那么支持这个成为小白鼠的提议是有意义的。——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:User rights nominations#Arlolra。 WhatamIdoing (讨论) 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？你们在其他 Wikivoyages 上运行它吗？请参阅Wikivoyage:Welcome, Wikipedians#Style differences：“Wikivoyage 文章不引用参考资料。”因此，此维基上没有机器人可以挽救的来源。我认为该机器人不应该在任何 Wikivoyages 上添加 archive.org 链接。
反之，如果你愿意添加{{dead link}}（它会将文章放入Category:Articles with dead external links），那么我想一些编辑者可能会认为那很有用。 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: 我们没有意识到添加存档网址实际上是在损害 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，我认为你希望在所有 Wikivoyages 上使用仅标记模式，并注意 Wikisources 的命名空间。另外，我认为本地模板技术上不支持 `|date=` 参数，但我认为包含日期会是个好主意。我相信机器人已经这样设置了。 WhatamIdoing (讨论) 2022年9月12日 15:55 (UTC)[回复]
机器人通常在行为方面非常灵活。我需要做的就是添加一个选项来重新配置机器人以仅进行标记工作，因为机器人设计的基本原则是存档比死链接更好。这应该很快就能实现。我在 phabricator 上开了一个 ticket 来跟踪这项工作：phab:T317553。——CYBERPOWER (聊天) 2022年9月12日 17:00 (UTC)[回复]
谢谢。我认为这会很有帮助。 WhatamIdoing (讨论) 2022年9月12日 17:36 (UTC)[回复]
是的：谢谢。——LPfi (讨论) 2022年9月13日 11:12 (UTC)[回复]

我看到 InternetArchiveBot 的仅标记功能现在正在测试中——请参阅 User:Cyberpower678/sandbox。SHB2000，我认为现在可以解除对该机器人的封禁，但我请求该机器人每天只标记少量页面，直到进一步讨论。 AlasdairW (讨论) 2022年9月30日 23:13 (UTC)[回复]

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

我们回来了（亚洲学生作业）

各位维客！经过几年的休整，我回来啦，将释放一批学生（主要是韩国和中国的）来处理一些话题（你可以在pub的存档中找到我以前的一些公告和相关的讨论）。感兴趣的编辑者也可以查看我们的教学大纲（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 谢谢！不用，照常进行 :)。理想情况下，在回滚学生编辑时，最好在他们的讨论页或编辑摘要中留下解释，并且 ping我，以便我能注意到并提供我自己的问题解释，在课堂上或其他地方。我过去的经验是，大多数学生并不期望来自维基志愿者的建设性反馈，或者任何反馈，所以有些学生甚至没有意识到他们的编辑被回滚了，即使他们意识到了，也不知道原因（特别是，请注意，大多数学生不会注意到编辑摘要中的评论，除非我单独指出该功能，或在课堂上多次展示）。顺便说一句，请注意，我的大多数学生在英语熟练程度上会遇到问题（尽管他们参加的是英语授课的大学课程，而我正在教授这门课程），所以请期待一些编辑需要例行的语法/词汇校对（比我在以英语为母语的国家授课时需要更多）。 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）坏了。如果他们希望在课程结束后扩展韩语和中文的 Wikivoyage 文章，那会很有趣。我知道这超出了你课程的范围，但那些维基的状况比英语维基差。 OhanaUnited讨论页 2022年9月17日 06:07 (UTC)[回复]
@OhanaUnited 我的错，应该是 tinyurl.com/wikivoydata2022（我无法链接网址，因为 tinyurl 和 google docs 在 MediaWiki 级别被列为垃圾链接或类似的东西，唉）。请注意，目前没有活跃的韩语 Wikivoyage 项目。在我的维基百科课程中，我让学生编辑韩语和中文维基百科，但由于没有韩语 Wikivoyage，我们只专注于英语 Wikivoyage 进行 WV 课程。我希望能有一天看到韩语 WV 被创建，也许是由我的一个学生创建，但到目前为止还没有发生…… Piotrus (讨论) 2022年9月19日 08:57 (UTC)[回复]
@Piotrus: 顺便说一句，目前在 Wikimedia Incubator 上有一个韩语 Wikivoyage——参见incubator:Wy/ko/위키여행:대문。不过，它仍然需要大量的扩展。 SHB2000 (讨论 | 贡献 | meta) 2022年9月19日 11:09 (UTC)[回复]
@SBH2000 好的，我之前找到了它，但 incubator 不是“活跃的”；我放弃了向我的学生解释如何在上面进行操作（例如，我认为那里的页面无法连接到 wikidata）。坦率地说，我认为将东西隐藏在那里是在我们所有人的头上，应该让它活跃起来，然后它才能成长（例如，在我学生的帮助下，他们每年可以写或翻译十几个以上的文章）。 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/edit。 WhatamIdoing (讨论) 2022年9月19日 16:06 (UTC)[回复]

哦，对了，我差点忘了——你们中的一些人可能会觉得看看我的关于 Wikivoyage 的 Prezi 很有趣（参见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。更新已选定的文章列表，供大家关注：大邱、潭阳、东豆川、军浦、华城 Fortress、济州、嘉兴、晋中、智异山国家公园、莱芜、连云港、浦项、Rivierenland、束草、铜仁（贵州）、威海、西双版纳、英德县、张家界、舟山。——Piotrus (讨论) 2022年10月1日 06:50 (UTC)[回复]

感谢您提供文章列表。我一定会至少将其中一些添加到监视列表。请随意让您的学生创建新文章，如果它们符合WV:WIAA。如果小城镇也是足够好的旅游目的地，也欢迎。 ——评论者 Selfie City (讨论) (贡献) 2022年10月3日 14:40 (UTC)[回复]
感谢这份列表。另外，对于常驻用户：编辑冲突对于新手来说真的很难处理。请尽量等到学生们停止编辑后再介入文章。我不知道对这群学生会有什么期望，但根据维基百科的一些研究经验法则，如果一个人在过去半小时内没有保存过编辑，他们可能已经离线了。WhatamIdoing（讨论） 2022年10月3日 16:21 (UTC)[回复]

致Wikimedia Commons的公开信

有一封致WMF关于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）修订执行指南的审查。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以及其他维基上的正式撤销回退策略，但主要概述了何时应该使用和不应该使用撤销回退，滥用它的后果，以及一些关于手指失误的内容。欢迎自由编辑，但它还需要什么才能成为策略？--SHB2000 (讨论 | 贡献 | meta) 2022年10月6日 12:49 (UTC)[回复]

我认为我们不应该有这样的策略。
事实上，我认为我们应该考虑完全不必担心大多数形式的“滥用”撤销回退。
撤销回退和撤销之间的主要区别是
  • 是否可以添加自定义编辑摘要，以及
  • 是否可以批量撤销所有编辑（对于大量破坏页面的人来说非常方便）。
仅此而已。第二个（这也是该工具被创建的原因）几乎从不引起争议。
拟议的策略实际上是试图将点击生成此内容的按钮
和点击生成此内容的按钮
我认为，认为“Reverted edits”和“Undo revision”之间的区别，或者“Tag: Rollback”和“Tag: Undo”之间的区别真的有很大不同，那就太傻了。我猜滥用撤销回退的真正问题是：有时人们没有添加自定义编辑摘要，而我们认为应该添加。
与此相关的是，我建议我们考虑一下在一个非常不同的语境下发布的评论：“特别是，请注意，大多数学生不会注意到编辑摘要中的评论，除非我单独指出这一功能，或在课堂上多次展示。”
所以：措辞差别不大，而且新手根本看不到措辞。我认为我们应该删除Wikivoyage:Administrators' handbook#Rollbacks中“使用回退可能会冒犯人”的说法（在我看来，这并不比“撤销”按钮更冒犯人），并且或许调整我们的看法，将回退工具归类为类似w:en:Wikipedia:Don't template the regulars的东西——可能会惹恼一些经验丰富的编辑，他们已经习惯了英文维基百科关于这个工具的文化包袱，并且偶尔会错过直接沟通和加强社会联系的机会，但本身并不是一个有问题的行为。WhatamIdoing（讨论） 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：页面尚未完成，所以请勇往直前，随意扩展草稿。我认为警告只是在主名字空间（namespace 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的编辑）而被剥夺了巡查员权限，并且现在在英文维基百科上被永久封禁。这也将使英文维基旅人与大多数其他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)[回复]
已根据您的评论进行调整。请参阅Special:Diff/4542195。这是我的新措辞

如果您发现用户滥用回退工具，请开始与他们讨论他们的回退工具使用情况，或者至少给予正式警告。如果用户能改正其行为和回退工具的使用，那么您就取得了进展。然而，如果反复的讨论未能带来改变，那么明确表示撤职或撤销巡查员权限始终是一个选项。如果用户仍然继续滥用回退工具，您可以发起撤职请求（如果该用户是管理员），并告知巡查员。

您可能已经知道，我有将政策解读得像法律一样的倾向。我已尽力避免将其写成法律文件，但它可能仍然听起来像。给@WhatamIdoing：我已经调整了，以便撤职/撤销巡查员权限是最后的手段。这样可以吗？ SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 03:36 (UTC)[回复]
我认为记录最佳实践是很有用的，我没有说清楚吗？因此，我支持添加到管理员手册中关于撤销、回退和沟通的建议，而不是像建议的那样添加页面作为正式策略。人们可以很容易地指出相关章节作为“对此已有共识”，而不是说“你正在违反策略”。SHB给出的两个例子是滥用和粗心使用回退的明显例子，处理它们不需要指出策略。事实上，我认为在这些情况下指出策略是对社区的贬低：与其说“请不要这样做”（假设有善意），不如说“警告你！”（依赖惩罚）。 –LPfi（讨论） 2022年10月16日 05:48 (UTC)[回复]
这是“我们做事方式”的另一个例子，新用户在没有写下来之前是不知道的。我不知道“我们试图避免政策”，但我在这里已经六年多了，我想我还没有吃过这个苦头。
提出这项政策或将其添加到管理员手册的原因是，我们有用户判断力不佳并造成问题的例子。写下来可以更容易地在用户讨论页上进行讨论。它允许人们说“关于这一点已经有共识——不仅仅是你的最佳判断对我的最佳判断”，而不是“这不是你在这里做事的方式，你在这里待久了就会学到”。 Ground Zero（讨论） 2022年10月16日 07:09 (UTC)[回复]
Ground Zero完美地概括了为什么维基旅人的编辑群体（显著地）小于其潜力。每个策略都要求编辑者运用他们的判断力。从WV:TTCF到WV:TONE再到WV:TOUT，许多策略和指南都是主观的。对于对旅行者有用和无用的内容之间没有明确界限，对于可接受的语气和不可接受的语气之间没有明确界限，对于兜售和非兜售之间没有明确界限。拥有正式的策略并不一定意味着编辑者不能运用他们的判断力。策略明确了某种回退工具的使用是否不可接受。说实话，英文维基旅人在允许或未对此或此等回退采取太多行动方面应该感到羞耻。编辑者仍然可以在模糊的情况下运用他们的判断力。 SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 07:42 (UTC)[回复]
我仍然认为问题不在于回退工具本身的使用，而在于使用它们然后习惯性地不尝试与善意或潜在善意的用户沟通，告诉他们为什么进行回退。我承认回退工具对某些用户来说比其他形式的回退更具侮辱性，因为你们中的一些人说它们对你们来说是如此，但我认为缺乏沟通是一个更大的问题。 Ikan Kekek（讨论） 2022年10月16日 09:09 (UTC)[回复]
根据您的评论进行了调整。请参阅Special:Diff/4542376。 SHB2000 (讨论 | 贡献 | meta) 2022年10月16日 09:22 (UTC)[回复]
我认为记录最佳实践是很有用的，我没有说清楚吗？因此，我支持添加到管理员手册中关于撤销、回退和沟通的建议，但不是像建议的那样将页面作为正式策略。人们可以很容易地指出相关章节作为“对此已有共识”，而不是说“你正在违反策略”。SHB给出的两个例子是滥用和粗心使用回退的明显例子，处理它们不需要指向策略。事实上，我认为在这些情况下指出策略是对社区的贬低：与其说“请不要这样做”（假设有善意），不如说“警告你！”（依赖惩罚）。 –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:en:Wikipedia:Five pillars并且目的和风格相似的页面，很久以前就被大胆地宣布为一项指南。需要打标签吗？我主张w:en:WP:NOTAG，就像我长期以来（并成功地）在英文维基百科上为5P不打标签而辩护一样。如果需要标签，那它是正确的标签吗？我对此表示怀疑。但它已经被打上标签了。唯一能阻止人们这样做的实际方法就是删除标签。
但标签经过了讨论和接受，因为有人想导入一个在英文维基百科上被标记为论文的页面，并让其他人遵循其建议。他们似乎觉得标签是后者的必要组成部分，所以现在我们有了标签，因为我们有了标签，它就蔓延到了其他页面。 WhatamIdoing（讨论） 2022年10月20日 03:20 (UTC)[回复]
新用户需要知道经验丰富的用户应该如何使用高级工具吗？
如果你想帮助某人在这里做出他们的第一个编辑，那么解释其他人如何使用这位新手没有权限使用的工具，是否会使一个需要新手知道的事项列表排名前十？它会排进前一百名吗？Wikivoyage:Welcome,Wikipedians包含106句话，但一次也没有提到撤销回退。
在我看来，新手需要知道的是，我们有会解释问题并鼓励贡献的人。由于编辑摘要不是解释事情的唯一方法，也不是向新编辑解释任何事情最有效的方法，解释问题实际上与“糟糕”的回退使用不兼容。 WhatamIdoing（讨论） 2022年10月18日 15:35 (UTC)[回复]

策略写作哲学

我喜欢写政策和指南；我甚至似乎相当擅长（尽管不擅长写作的人通常意识不到这一点，所以也许我只是意识不到自己的局限）。我对自己认为有效的方法有自己的看法，加上我自己的偏好和偏见，而且我在基于维基的社区中见过比大多数人更多的策略方法。我给出这些背景是为了说明接下来的内容有点哲学化，如果你不感兴趣，不必阅读。

不同的人喜欢不同的方法。几乎每个人都认为自己的观点是中间立场，每个人都认为自己的观点是最好的。所以我想告诉你，这些是我的观点，而不是唯一的选择。

我在英文维基百科上推荐的一个经验法则，并且我认为它适用于任何地方，是这样的：

➤ 除非出现了至少两个无法通过任何正常、现有流程（例如，请求其他编辑加入讨论）解决的独立事件（即不涉及任何相同编辑者且不涉及相同页面/内容），否则绝不为任何情况制定书面规则。

我认为普遍适用的另一个原则是：

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

这意味着，我们会说“我们这样做是因为它有效”或“这是个受欢迎的选择”，但我们不会说“如果你不遵守这条规则，我们将因违规而惩罚你”。当然，这有一些例外，通常涉及显而易见的情况（例如，我们通过封锁来惩罚垃圾邮件发送者和破坏者）以及法律事务。然而，在日常编辑中，目标是进行没有威胁的互动。威胁的目的是 引起 恐惧。威胁不是说“你应该这样做，因为它很好、很正确，而且会给世界带来美好”，而是说“你应该这样做，否则我会惩罚你”。恐惧会带来糟糕的体验、糟糕的关系、糟糕的行为和糟糕的社区。

相反，当你告诉人们某件事是正常或受欢迎的，他们通常会想去做。人们希望通过像群体一样行事来证明他们是群体的一员。人们认为有经验的编辑者已经通过过去的经验摸索出了大部分内容，他们希望利用这些知识，而不是通过痛苦、耗时的错误自己摸索一切。

这里有一个并非普遍适用，但却是我的强烈偏好的原则：

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

这意味着，例如，最小的维基基本上应该没有任何规则。它们应该只是随意地提到核心内容政策，并且可能 somewhere 有一条关于版权侵权是坏主意的声明，或者至少移除 copyvios，即使它们没有费心在本地写下 copyvios 是违反规则的。否则，贡献者应该模仿他们认为有效 Thus 的行为和贡献，并避免那些似乎无效的事情，而且大多数情况下是为了内容而“存在并让别人存在”。整体的组织水平和规则不应比一群邻居在一个下午去学校或公园捡垃圾的组织更复杂。

中等规模的维基应该有一些规则和 一些 程序。这些规则应该只针对常见问题，并且总体上旨在让新用户更容易上手。大部分规则应该关于确立广泛可接受的行为，以最大化用于创建内容的时间，并阻止自封为规则执行者的人为一些事情争论，比如是否使用 w:serial comma（尽管每个人都应该这么做！ ;-)）或者某个事情的“唯一正确™”的方式。常见问题之外的问题应根据情况由考虑了群体价值观（例如，Wikivoyage:The traveller comes first，要热情好客）、其 Wikivoyage:Goals and non-goals 以及当前能力的人来决定，并始终关注决策对人际关系的影响。

英文维客旅行（English Wikivoyage）在这最后一点上做得非常出色。这一点不是简单地遵循规则就能解决的。它在你可以通过了解所有个人正在发生的事情来应对情况时效果最好。例如：这真的是关于那一个编辑的争吵，还是更大问题的症状？有人已经厌倦了处理一个顽固的破坏者，而且这次爆发是否意味着我们需要为表达自己不堪重负的感受而惩罚人们，而不是我们需要提供更多实际支持？对于这些中等规模的维基，整体组织水平和规则应该大致相当于为100人组织一次聚餐。你需要确定一些角色并组织一些事情（例如，谁来清理？垃圾桶放哪里？），但你主要让人们做他们想做的事情，并努力让团队保持愉快，而不是试图控制任何个体参与者。

最大的维基应该有足够的规则来防止重复出现的问题，以及足够的程序来让感兴趣的人进行专业化。总的来说，对于大型维基来说，目标仍然是拥有最少的规则，但要认识到最少的规则仍然有很多。当你拥有大量的贡献者时，他们通常的“成熟编辑”生命周期只有几年，会有很多问题一遍又一遍地出现。

IMO 任何维基都不应该有预先规定一切的规则。规则应该尽可能为创造力留出空间。这是因为大多数人之所以贡献，是因为他们想构建一些东西，而不是因为他们想遵守一堆规则或被规则执行者命令。你可能以前见过这些比较：

  • 人们喜欢做饭，但没人喜欢洗碗。为什么？做饭是有创造性的。洗碗不是。
  • 人们喜欢缝制衣服，但没人喜欢洗衣服。为什么？缝制是有创造性的。洗衣服不是。

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

我不认为我在这里的观点是普遍的。抛开那些天真地认为将英文维基百科（Wikipedia）广泛的（且自相矛盾的）规则集、模板、机器人和官僚体系翻译成当地语言就能吸引大量社区填补所有角色的“建造者”（他们从未这样做过！）的人们不谈，在某些情况下，你可以选择不同的方法，例如：

  • 一个关于敏感主题（例如，人力资源政策）的公司维基可能对控制有特别高的要求。诉讼曾经因为一份合同的标点符号而存在。
  • 自闭症患者社区可能看重我称之为“压抑的”规则遵守程度。尤其是当你一生的大部分时间都在想自己是否违反了某种不明确的社会习俗时，知道点击蓝色按钮而不是黄色按钮就一定做对了，这会让你感到安心，即使两个按钮的功能基本相同。这样的社区可能比创造力更看重可预测性、一致性和控制力。（顺便说一句，自闭症患者在找到适合他们技能和兴趣的任务时，往往会成为不知疲倦的贡献者。）
  • 年幼的小学生可能需要一种非常“循规蹈矩”的贡献方式，因为他们缺乏做出良好贡献所需的成熟度。

但我不愿意成为这样一个社区的一员，我猜我们大多数人都不是。我们来这里不是为了完美地遵守规则而感到快乐。我们来这里是为了和很棒的志愿者一起（互相帮助）创造关于有趣主题的新信息，并享受乐趣。

现在，如果你愿意听我啰嗦，我将把这个冗长的陈述与上面的争执联系起来。

  1. IMO 我们不需要规则，因为这种情况基本上涉及一个争论，并且基本上已经通过现有的正常流程解决了。也许有些人对这个解决方案不满意，但我们确实达到了一个解决方案。
  2. 如果我们决定制定任何规则，我们不需要威胁任何人。提供积极的陈述很可能就足够了（“除非是明显的破坏行为，否则任何回复都要解释原因。通常的做法是使用自定义的编辑摘要或在讨论页上说明”）。
  3. 我们处理有关此事的讨论做得非常出色，因为人们一直在回归核心价值观，例如通过解释为什么他们的第一次尝试被撤销来热情好客并鼓励新来者。

最后一点让我很高兴能在这里。 WhatamIdoing（讨论） 2022年10月18日05:45 (UTC)[回复]

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

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

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

我想知道是否可以将其更改为标准的门户设计（如 wikipedia.org），因为：

  • 它不可访问，文字与背景图像的对比度太低，对于视力障碍者来说。
  • 设计不符合维基媒体标准（https://design.wikimedia.org/style-guide），例如蓝色不是 #36c。
  • 整体外观不符合所有其他项目遵循的标准，这是运动品牌的一部分。
  • 当前设计并未真正考虑到我们未来可能拥有更多维客旅行（Wikivoyage）语言，没有为它们留出适当的空间（不像标准设计）。
  • 当前设计在手机上完全损坏。

我在 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家电子烟店和一家牙医。这不太可能是游客旅行时需要的东西。 OhanaUnited讨论页 2022年10月28日04:27 (UTC)[回复]
你也可以过滤和排序，这对于像蒙特利尔（Montréal）这样的大城市似乎更有帮助。例如 YUL顶级的酒吧。点击“隐藏的瑰宝”等。 ButteBag（讨论） 2022年10月28日13:43 (UTC)[回复]

寻找关于新冠的旧讨论

我记得（非常模糊地）在维客旅行（wiki-voyage）上有一个关于某些来源认为新冠不再是个问题，或者类似这样的讨论，但我找不到它，而事实证明这对我是件好事……

我最先在这里寻找。找不到，于是决定去翻阅存档。那么存档在哪里呢？起初，我有点恼火，因为存档不像英文维基百科（enwp）上那样，容易在页面顶部找到。然而，由于我并不像往常一样急需，我开始阅读顶部的框，然后很快地看了下面的框，从这句话开始：“有经验的用户： 请清理 the pub”。

非常有趣，而且与其他我见过的任何 WMF 维基都不同。（想继续写，但我怕会丢失我已写的内容，所以就不写了） Ottawahitech（讨论） 2022年11月6日13:32 (UTC)[回复]

这是个合理的问题。页面顶部拥挤且不欢迎新访客来到 pub。我建议
  1. 在第一个框中添加一个存档链接
  2. 将第二个框（用于有经验的编辑者）移到讨论页的顶部。它不适用于新访客，有经验的编辑者也不需要在每次访问 pub 时都看到它。
Ground Zero（讨论） 2022年11月6日13:45 (UTC)[回复]
哇，我喜欢这个地方。这是非常快速的回应，而且我收到了通知，尽管我没有被 ping（我使用了 [Subscribe] 按钮）！ Ottawahitech（讨论） 2022年11月6日13:56 (UTC)[回复]
关于大部分内容被转移到其他讨论页而不是存档，我们应该怎么做？ Ikan Kekek（讨论） 2022年11月6日16:09 (UTC)[回复]
Template:Swept 可以匹配一个 Template:Sweptto（Swept 可以重定向到 Sweptfrom，或者移动到 Sweptfrom），它将替换这里的节内容，放在原始标题下（然后会保留并存档），以帮助人们通过搜索或浏览存档找到它；如果标题本身没有帮助，移动讨论节的编辑者可以给标题加上括号中的几个词，以使其清晰（如果标题是“Question”，编辑者可以将其更改为类似“Question (COVID measures relaxation)”）。 Twsabin（讨论） 2022年11月6日17:51 (UTC)[回复]
这对于偶尔想查看旧对话而不想费力查看 Pub 历史记录的人来说会很方便，但会增加我们少数几个进行清理的人的工作量。增加清理工的任务量可能会导致清理工作减少，这对 Pub 不利。我反对这样做。我认为少数想查找旧对话的人可以查看历史记录。一切都会在那里。 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)[回复]

对页面顶部框的拟议更改

我没有收到太多关于我提议的回应，所以我将把它分成一个单独的部分：因为这个页面的顶部拥挤且不欢迎新访客来到 pub，我提议

  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 Ambassadors）。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。我问了一个（不可否认很偏执的）问题，得到了原作者的回复。Ottawahitech (讨论) 2022 年 12 月 3 日 20:46 (UTC)[回复]

Wikivoyage 列表链接到 Wikidata - 但没有反向链接

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

🎄 祝大家圣诞快乐 🎄

或者用威尔士语说，Nadolig llawen pawb。好好吃，好好喝，和您爱的人一起庆祝。再次感谢大家成为一群出色的人。祝愿 2023 年，也就是我们的第 10 届和第 20 届周年纪念，一切顺利！--ThunderingTyphoons! (讨论) 2022 年 12 月 25 日 14:39 (UTC)[回复]

大家圣诞快乐！Ypsilon (讨论) 2022 年 12 月 25 日 17:17 (UTC)[回复]
是的，谢谢：也祝您和您的家人圣诞快乐。希望 2023 年快乐、和平、富有成效。—Justin (koavf)❤T☮C☺M☯ 2022 年 12 月 25 日 19:48 (UTC)[回复]
我知道我给所有我想到的常驻用户发送了圣诞贺卡，即使我可能迟到了（写下这段话时，我这里是 12 月 26 日上午 8:38），但大家圣诞快乐！SHB2000 (讨论 | 贡献 | meta) 2022 年 12 月 25 日 21:39 (UTC)[回复]
祝您和所有庆祝节日的人们圣诞快乐、光明节快乐、光明节快乐等等！Ikan Kekek (讨论) 2022 年 12 月 25 日 22:06 (UTC)[回复]
也祝你们一切顺利！/Yvwv (讨论) 2022 年 12 月 27 日 11:46 (UTC)[回复]
检索自“https://wikivoyage.cn/w/index.php?title=Wikivoyage:Travellers%27_pub/2022&oldid=5108047”
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.