跳转至内容

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

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

Let's Connect Program

各位好，

希望这个话题能让大家一切安好。我叫 Gorana Gomirac，是 Let’s Connect 工作组的一员。我们是一个由 8 人组成的团队，代表：拉丁美洲、中东北非、南亚、东亚、东南亚、太平洋、撒哈拉以南非洲、中东欧、北部和西部地区。如果您有兴趣参加 学习交流会，我欢迎您填写这份 注册表格。您将可以访问我们的月度通讯、月度学习交流会，甚至成为分享者，您和您的社区可以为我们的 Let’s Connect 同事举办讲习班/学习交流会。我们期待包含更多关于维基旅行的话题，请随时与我们联系！

如果您有任何疑问，请发送电子邮件至 letsconnect@wikimedia.org Gorana Gomirac (VMRS)（讨论） 2024年12月9日 12:59 (UTC)[回复]

关于维基旅行教育项目的疑问

首先，感谢大家这些年来的帮助。该课程将一如既往地在秋季回归。在此期间，我打算收集收到的反馈，并将其整理成更正式的指南（在 User:Hanyangprofessor2），以及类似我过去撰写的学术论文（GS）。欢迎您提供任何其他反馈、想法或评论（论文基本完成后，我会在此处发布草稿供您检查）。在此期间，有一个问题——您是否知道其他在维基旅行上开展活动的教育工作者？ Piotrus（讨论） 2025年1月6日 07:17 (UTC)[回复]

我记得几年前这里有印度学生。我想你现在是唯一一个。 Ikan Kekek（讨论） 2025年1月6日 08:23 (UTC)[回复]
如果我没记错的话，我们曾有过尼日利亚和更广泛非洲地区的考察活动，是通过 WM Nigeria（或某个等效组织）协调的，但我不太确定具体是如何操作的。几年前，我们还有一位法国英语老师将维基旅行用作教学工具。--SHB (讨论 | 贡献 | m) 2025年1月6日 10:47 (UTC)[回复]
我以前是老师，在 2017 年为学生组织过几次维基旅行编辑项目。—Granger （讨论 · 贡献） 2025年1月6日 14:44 (UTC)[回复]
@Mx. Granger 你停止使用维基旅行是因为工作变动还是因为它不起作用？ Piotrus（讨论） 2025年1月7日 01:12 (UTC)[回复]
是的，那些是法国高中生，我记得。我没记起你的教育项目，Granger。 Ikan Kekek（讨论） 2025年1月6日 16:07 (UTC)[回复]
可能吧——我记不太清了，也记不清是哪个用户了，所以无法核实 :( 。 SHB (讨论 | 贡献 | m) 2025年1月7日 01:50 (UTC)[回复]
@Piotrus：工作变动。我认为这个项目相当成功。除了让学生有机会在真实的语境中练习使用英语，它还促使乌拉圭一些目的地的内容得到了改进。我监督了学生的编辑，之后对文章进行了一些清理。 @Ikan Kekek：它在这里被简要讨论过：Talk:Uruguay#Workshop tomorrow。 —Granger （讨论 · 贡献） 2025年1月7日 04:29 (UTC)[回复]

启动！加入我们一起参与 2025 年 Wiki Loves Ramadan！

各位好，

我们很高兴地宣布 Wiki Loves Ramadan 2025 活动正式启动，这是一个旨在通过维基百科的力量庆祝和保存伊斯兰文化和历史的年度国际活动。作为本地维基百科的活跃贡献者，我们特别邀请您参与启动仪式。

今年的活动将围绕着邀请您加入我们，共同撰写、编辑和改进文章，以展示伊斯兰传统、历史和文化的丰富性与多样性。

如需开始，请访问 活动页面，了解详情、资源和指南：Wiki Loves Ramadan 2025。

请将 您的社区加入进来，并用您当地的语言组织 Wiki Loves Ramadan 2025。

无论您是第一次编辑还是经验丰富的维基百科人，您的贡献都很重要。齐心协力，我们可以确保伊斯兰文化和传统得到充分的体现，并让所有人都能获取。

欢迎邀请您的社区和朋友一同参加。如果您在准备参与过程中有任何疑问或需要支持，请随时与我们联系。

让我们一起让 Wiki Loves Ramadan 2025 取得圆满成功！→ 我。代表 国际团队 2025年1月16日 12:08 (UTC)

《通用行为准则》年度审查：就 UCoC 和执行指南提供您的意见

请协助翻译成您的语言.

我写信通知您，《通用行为准则》和执行指南的年度审查期现已开放。您可以在 2025 年 2 月 3 日之前提出修改建议。这是年度审查的几个步骤中的第一步。 在 Meta 上的 UCoC 页面上阅读更多信息并找到可以加入的讨论。

universal Code of Conduct Coordinating Committee（U4C）是一个全球性组织，致力于公平一致地执行 UCoC。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，您可以 查阅 U4C 章程。

请将此信息与您社区中的其他成员分享，并在其他合适的地方发布。

—— 经 U4C 合作，Keegan (WMF)（讨论） 2025年1月24日 01:12 (UTC)[回复]

提醒：年度 UCoC 审查的第一部分即将结束

请协助翻译成您的语言.

这是提醒，年度《通用行为准则》和执行指南审查的第一阶段即将结束。您可以通过 2025 年 2 月 3 日结束当日 之前提出修改建议。这是年度审查的几个步骤中的第一步。 在 Meta 上的 UCoC 页面上阅读更多信息并找到可以加入的讨论。在审查了反馈意见之后，将在三月份在 Meta 发布更新文本的提案，供下一轮社区审查。

请将此信息与您社区中的其他成员分享，并在其他合适的地方发布。

—— 经 U4C 合作，Keegan (WMF)（讨论） 2025年2月3日 00:49 (UTC)[回复]

即将举行的语言社区会议（2 月 28 日，UTC 14:00）和通讯

大家好！

An image symbolising multiple languages

我们很激动地宣布，下一场 语言社区会议 即将举行，时间是 2 月 28 日，UTC 14:00！如果您想参加，只需在 维基页面 上注册即可。

这是一个由参与者驱动的会议，我们将分享语言相关项目的最新进展，讨论语言维基中的技术挑战，并合作寻找解决方案。在我们上次的会议中，我们讨论了开发语言键盘、创建摩尔维基百科以及 Wiki Indaba 语言支持轨道上的更新等话题。

有话题要分享吗？ 无论是您项目中的技术更新、您需要帮助解决的挑战，还是对口译支持的请求，我们都非常乐意听您说！请随时 回复此消息 或在此 处 添加议程项目。

另外，我们想强调的是，第六期《语言与国际化》通讯（2025 年 1 月）已发布，可在此处查阅：Wikimedia Language and Product Localization/Newsletter/2025/January。本通讯提供了 2024 年 10 月至 12 月期间关于新功能开发、各种语言相关技术项目和支持工作的改进、社区会议详情以及为项目做出贡献的想法的更新。要保持了解最新信息，您可以订阅其维基页面上的通讯：Wikimedia Language and Product Localization/Newsletter。

我们期待您在语言社区会议上的想法和参与，到时见！

MediaWiki message delivery 2025年2月22日 08:30 (UTC)[回复]

《通用行为准则》年度审查：拟议变更现已开放评论

请协助翻译成您的语言.

我写信通知您，《通用行为准则》（UCoC）执行指南和《通用行为准则》协调委员会（U4C）章程的 拟议修改 现已在 Meta-wiki 上开放审查。您可以在 2025 年 3 月 18 日星期二结束当日 之前就建议的修改提出 反馈。这是年度审查流程的第二步，最后一步将是社区投票决定拟议的修改。 在 Meta 上的 UCoC 年度审查页面阅读更多信息并查找与该流程相关的链接。

universal Code of Conduct Coordinating Committee（U4C）是一个全球性组织，致力于公平一致地执行 UCoC。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，您可以 查阅 U4C 章程。

请将此信息与您社区中的其他成员分享，并在其他合适的地方发布。

—— 经 U4C 合作，Keegan (WMF) 2025年3月7日 18:52 (UTC)[回复]

Wiki Loves Bangla 2025 正在进行中——快来加入我们！

各位好，

来自 Wiki Loves Bangla 团队的问候！

我们很高兴地宣布 Wiki Loves Bangla 2025 即将到来！今年的比赛主题将聚焦于 孟加拉的鸟类，邀请参赛者捕捉并分享孟加拉地区多样鸟类的精彩照片。

比赛详情

📅 日期：2025 年 3 月 1 日 - 31 日
📍 主题：孟加拉的鸟类
🎯 主办方：Bangla WikiMoitree

Wiki Loves Bangla 是一个在 Wikimedia Commons 上举办的国际摄影比赛，旨在记录世界各地的孟加拉文化和遗产。作为孟加拉文化遗产整理项目的一部分，该比赛每年举办一次，并有特定主题，邀请参与者将他们的照片贡献到 Wikimedia Commons，以扩大知识共享。通过这项活动，您可以成为一个致力于保护和展示孟加拉鸟类之美、习性和生物多样性的社区的一员。这项倡议旨在向世界展示孟加拉丰富自然的遗产。

如何参与？

比赛将于 2025 年 3 月 1 日至 31 日 在 Wikimedia Commons 上进行。要参加，只需

📷 拍摄 孟加拉的鸟类 的照片。
📤 将您的照片上传到 Wikimedia Commons，并归类到 Wiki Loves Bangla 2025 类别。
📖 在 比赛页面 上了解更多关于比赛规则和指南。

为何参与？

通过贡献，您将帮助记录孟加拉丰富的鸟类生活，使知识能够为所有人所获取。此外，还有 激动人心的奖品 等您赢取！

奖品

一等奖：50,000 孟加拉塔卡、奖杯和证书。
二等奖：25,000 孟加拉塔卡、奖杯和证书。
三等奖：15,000 孟加拉塔卡、奖杯和证书。

如果您有兴趣参加摄影比赛，请开始拍摄，并为 Wikimedia Commons 上的摄影比赛做好准备。有关比赛规则和奖品的更多信息，请参阅 此处。如有任何疑问，请发送电子邮件至我们的邮箱或加入我们的 Telegram 群组 此处。

致以诚挚的问候，
Wiki Loves Bangla 团队.
~ Moheen (继续讨论) 2025年3月13日 13:44 (UTC) #WikiLovesBangla[回复]

您的维基即将进入只读模式

MediaWiki message delivery 2025年3月14日 23:14 (UTC)[回复]

只是提醒一下，这些事件是“最多一小时”，但在最近几年，通常是“不到五分钟”。大多数人根本不会注意到，但如果您注意到了，只需等待几分钟，然后重试您的编辑即可。 WhatamIdoing（讨论） 2025年3月15日 21:50 (UTC)[回复]

《通用行为准则》执行指南和 U4C 章程的最终拟议修改现已发布

《通用行为准则》执行指南（“UCoC EG”）和 U4C 章程的修订 现已在 Meta-wiki 上供社区参考，以备投票期。此最终草案是在前两轮社区审查的基础上制定的。 社区成员将能够从 2025 年 4 月 17 日开始对这些修改进行投票。投票将于 2025 年 5 月 1 日结束，结果不晚于 2025 年 5 月 12 日公布。U4C 选举期（从候选人征集开始）将在审查结果公布后立即开始。更多信息将很快发布在 选举的维基页面 上。

请注意，此过程将在接下来的两个月内需要发送更多消息。

universal Code of Conduct Coordinating Committee（U4C）是一个全球性组织，致力于公平一致地执行 UCoC。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，您可以 查阅 U4C 章程。

请将此消息分享给您社群的成员，以便他们也能参与。

—— 经 U4C 合作，Keegan (WMF)（讨论） 2025年4月4日 02:05 (UTC)[回复]

Wikidata 和姊妹项目：一场在线社区活动

（抱歉，用英文发布）

大家好，我很高兴地分享即将举行的一场在线活动的消息，名为 Wikidata 和姊妹项目，旨在庆祝 Wikidata 支持或增强其他维基媒体项目的不同方式。活动将持续 4 天，在 2025 年 5 月 29 日 - 6 月 1 日 之间举行。

我们诚邀各位演讲者参加本次社区活动，分享成功案例、挑战，展示您可能正在进行的、Wikidata 参与其中（在维基百科、Commons、WikiSource 以及所有其他 WM 项目）的工具或项目。

如果您有兴趣参加，请 在此注册。如果您想在活动中发表演讲，请填写 活动讨论页 上的会议提案模板，您也可以在此提出任何问题。

希望在活动中看到您，无论是在听众席还是作为演讲者，- MediaWiki message delivery（讨论） 2025年4月11日 09:18 (UTC)[回复]

立即投票，就修订的 UCoC 执行指南和 U4C 章程发表您的意见

《通用行为准则》执行指南（“UCoC EG”）和 UCoC 协调委员会章程的修订投票期现已开放，截止日期为 5 月 1 日（UTC）结束（请在您的时区查找）。 在 Meta-wiki 上的 UCoC 页面上阅读关于如何参与以及在投票前审阅提案的信息。

universal Code of Conduct Coordinating Committee（U4C）是一个全球性组织，致力于公平一致地执行 UCoC。EG 和章程的本次年度审查由 U4C 规划和实施。关于 UCoC 本身的审查，将在未来几个月内提供更多信息。有关 U4C 的更多信息和职责，您可以 查阅 U4C 章程。

请将此消息分享给您社群的成员，以便他们也能参与。

经 U4C 合作 -- Keegan (WMF)（讨论） 2025年4月17日 00:35 (UTC)[回复]

投票，就 UCoC 执行指南和 U4C 章程的拟议修改发表您的意见

《通用行为准则》执行指南和 U4C 章程的修订投票期将于 2025 年 5 月 1 日 UTC 23:59 结束（请在您的时区查找）。 在 Meta-wiki 上的 UCoC 页面上阅读关于如何参与以及在投票前审阅提案的信息。

universal Code of Conduct Coordinating Committee（U4C）是一个全球性组织，致力于公平一致地执行 UCoC。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，您可以 查阅 U4C 章程。

请将此消息分享给您社区中说您语言的成员，以便他们也能参与。

经 U4C 合作 --

Keegan (WMF)（讨论） 2025年4月29日 03:41 (UTC)[回复]

Commons 通知删除机器人已恢复

我很高兴地宣布，得益于 @Taavi这位大神，Commons 通知删除机器人终于又上线运行了！您应该很快就能看到新的讨论页通知了（针对在约 15 分钟前 之后开始的符合条件的删除讨论）。

在此 @Ikan Kekek @SHB2000 @WhatamIdoing 和 @LPfi，你们长期以来都在要求这个功能。长达两年的停机时间，我深表歉意。我正在努力确保机器人能持续运行，并且此类事件不再发生。

祝好，编辑愉快！ — MusikAnimal 讨论 2025年5月4日 09:07 (UTC)[回复]

太棒了——我期待这个功能很久了，很高兴您和 Taavi 实现了它！再次感谢。 :) // shb (讨论 | 贡献 | m) 2025年5月4日 09:09 (UTC)[回复]
听到这个消息我感到非常欣慰，也期待着减少我在 c:Commons:Deletion requests 上的参与。谢谢你，也非常感谢 Taavi！ Ikan Kekek（讨论） 2025年5月4日 16:06 (UTC)[回复]
这是个好消息。谢谢告知。Taavi，你太棒了。 WhatamIdoing（讨论） 2025年5月6日 17:43 (UTC)[回复]

新的 Charts 扩展即将启用！

（抱歉，用英文发布）

大家好！我们有好消息与大家分享，关于影响所有使用图表的维基的持续性问题。

正如您可能知道的，旧的 Graph 扩展 已于 2023 年因 安全原因 被禁用。在过去两年里，我们一直在努力寻找一个可以替代旧扩展的解决方案，并为希望在其文章中展示图表的用户提供更安全、更好的解决方案。因此，我们开发了 Charts 扩展，它将取代旧的 Graph 扩展，并可能取代 EasyTimeline 扩展。

在意大利语、瑞典语和希伯来语维基百科以及 MediaWiki.org 上成功部署该扩展作为试点阶段的一部分后，我们很高兴地宣布，我们将继续下一阶段的部署，其中也将包括您的维基。

部署将分批进行，并将于 5 月 6 日 开始。请查阅 MediaWiki.org 上的页面，了解新的 Charts 扩展何时将在您的维基上部署。您也可以在 MediaWiki.org 上 查阅有关该扩展的文档。

如果您有疑问、需要澄清，或者只是想表达您对此的看法，请参考 Mediawiki.org 上的项目讨论页，或者在此线程下直接 ping 我。如果您在 Charts 在您的维基上启用后遇到使用问题，请在 讨论页 或 Phabricator 上报告。

提前感谢！-- Sannita (WMF) (讨论) 2025年5月6日 15:07 (UTC)[回复]

有人记得我们有使用过这些东西吗？ WhatamIdoing (讨论) 2025年5月6日 17:44 (UTC)[回复]
我不太认为我们在本站用过图表——简直从没用过。//shb (讨论 | 贡献 | meta) 2025年5月6日 22:23 (UTC)[回复]
@WhatamIdoing，@SHB2000：我们确实有{{Climate}}，但它可能从未真正使用过Graph扩展。 Sbb1413 (他) (讨论 • 贡献) 2025年5月7日 03:35 (UTC)[回复]
谢谢。
@Sannita (WMF)，我注意到mw:Extension:Chart/Project#Deployment Timeline只列出了mw.org和维基百科。非维基百科项目的部署时间表是什么？ WhatamIdoing (讨论) 2025年5月7日 05:04 (UTC)[回复]
你好 @WhatamIdoing，谢谢你的问题。非维基百科项目的部署将在本周进行，同时也会部署大多数非未来两周安排的维基百科。是否对你的工作有用，取决于你们自己。 Sannita (WMF) (讨论) 2025年5月7日 11:19 (UTC)[回复]
我认为它对于制作现有{{Climate}}模板的重制版很有用。 Sbb1413 (他) (讨论 • 贡献) 2025年5月7日 11:38 (UTC)[回复]
嗨@WhatamIdoing以及其他各位：我的上一条消息需要更正。昨天由于扩展规模的原因，时间表有所变动，所以所有非维基百科项目将在所有维基百科部署完成后处理。这意味着所有非维基百科项目至少要等到月底才能处理。抱歉耽误了。 Sannita (WMF) (讨论) 2025年5月8日 11:06 (UTC)[回复]
是的，我认为那只是使用了一些非常复杂的CSS，但从未真正使用过正式的MW扩展。//shb (讨论 | 贡献 | meta) 2025年5月7日 09:39 (UTC)[回复]

通用行为准则协调委员会（U4C）候选人征集

通用行为准则执行指南和通用行为准则协调委员会（U4C）章程的投票结果已在Meta Wiki公布。

您现在可以提交您的候选人资格，为U4C服务，截止日期为2025年5月29日12:00 UTC。有关资格、流程和时间表的信息，请参见Meta Wiki。候选人投票将于2025年6月1日开始，为期两周，于2025年6月15日12:00 UTC结束。

如有任何疑问，请在本次选举的讨论页面提问。--与U4C合作，

Keegan (WMF) (讨论) 2025年5月15日 22:08 (UTC)[回复]

33,333篇文章

33333

在一些稍显乐观的消息中，我们终于达到了33,333篇文章，通过创建Nassarawa。感谢所有为此做出贡献的人！//shb (讨论 | 贡献 | meta) 2025年5月16日 08:35 (UTC)[回复]

这是一个不错的成就，但也告诉我们对任意数字模式的痴迷，比如圆整数字（30,000）、重复数字（33,333）等等。这些对许多其他数字系统来说毫无意义，例如30,000和33,333在十六进制中分别是7,530和8,235。 Sbb1413 (他) (讨论 • 贡献) 2025年5月16日 09:36 (UTC)[回复]
哈哈，说得对——但我同时也认为，本项目文章数量里程碑往往要几年才能达到一个，这也与此有关。我预计到2034年会有4万篇文章，中间大约只有3.5万篇。//shb (讨论 | 贡献 | meta) 2025年5月16日 09:54 (UTC)[回复]
我们有36,00010 = 𒑚 * 𒐏^𒐏 (10*10060) – 这是一个非常圆整的数字（并且在重要的进制中）——或者2⁵·3²·5³，第一个素数（无论何种进制）的幂，指数为前一个数字（带有溢出轮转）。
:-)
--LPfi (讨论) 2025年5月16日 22:33 (UTC)[回复]
确实，对于一个项目来说，这也是一个值得庆祝的里程碑。//shb (讨论 | 贡献 | meta) 2025年5月19日 02:19 (UTC)[回复]
这个里程碑让我感到高兴。 WhatamIdoing (讨论) 2025年5月17日 19:17 (UTC)[回复]

关于抽象维基百科（以及您的项目）的RfC正在进行中

（如果英语不是您的母语，敬请谅解）

大家好！我们在Meta上就抽象维基百科开发的一个非常敏感的问题开启了讨论：存储通过Wikifunctions功能开发和Wikidata数据支持的抽象内容的位置。由于一些假设涉及到您的项目，我们也想听听您的想法。

我们希望决策过程清晰：我们还不知道要使用哪个选项，因此我们在此征求意见。我们将考虑维基媒体社区的论点，并希望与不同的社区进行协商，听取有助于我们做出决定的论点。基金会将咨询期结束后做出并传达决定。

您可以在Abstract Wikipedia/Location of Abstract Content页面阅读各种假设并发表您的意见。提前感谢！-- Sannita (WMF) (讨论) 2025年5月22日 15:27 (UTC)[回复]

@Sannita (WMF)：请问您说“有些假设涉及到您的项目”时，这对Wikivoyage有什么影响？提前感谢，//shb (讨论 | 贡献 | meta) 2025年5月26日 02:28 (UTC)[回复]
提出的解决方案在多个地方提到了Wikivoyages。主要问题是一个关于某个地方的抽象文章不应该在Wikipedia和Wikivoyage中以相同的方式呈现。这也会影响技术解决方案，例如存储陈述和函数的位置。--LPfi (讨论) 2025年5月26日 07:21 (UTC)[回复]
您能否进一步解释，Wikivoyage上的文章是如何区分抽象（与具体）文章的？ Ikan Kekek (讨论) 2025年5月26日 07:27 (UTC)[回复]
目前我们没有任何抽象文章，我猜想英文Wikivoyage可能永远不会有。但对于小语种来说，用合适的文章涵盖所有有趣的地方是不现实的。抽象维基百科的使命是提供一个框架，以一种能够进行自动翻译并至少达到半成品水平的方式来创建文章。这就像让列表从Wikidata获取关键信息，但规模扩大到完整的文章（或者不太完整——至少生动的个人印象语言在可预见的未来肯定会缺失）。--LPfi (讨论) 2025年5月26日 07:43 (UTC)[回复]
我明白了——我仍然不理解这（即使读了假设后）将如何完全实现，但我想这对于小语种项目来说是件好事。//shb (讨论 | 贡献 | meta) 2025年5月26日 09:47 (UTC)[回复]
嗨@SHB2000，看起来@LPfi已经涵盖了我大部分的论点，所以此时我只想重复它们。与你的项目相关的部分是指抽象内容*可能*（但目前还不确定）存储在你项目的专用命名空间中的假设。但同样，这*可能*会发生，你可以自由拒绝存储/使用抽象内容来进一步发展你的项目。这是你的权利，我们不希望在没有共识的情况下强迫任何采用。 Sannita (WMF) (讨论) 2025年5月26日 10:01 (UTC)[回复]
是的，抽象维基百科主要面向那些迄今为止文章数量很少的项目，旨在帮助它们加速增长，并希望为它们的社区提供更多知识并招募更多志愿者。 Sannita (WMF) (讨论) 2025年5月26日 10:03 (UTC)[回复]
听起来很棒。感谢你们两位解释！//shb (讨论 | 贡献 | meta) 2025年5月26日 10:10 (UTC)[回复]
表示赞同。我明白了。我们应该在另一个主题中讨论，是否最好鼓励、也许允许（不加评论）或禁止在本站使用抽象列表。我认为我们可能不想要抽象文章，但我们也应该对此进行讨论。 Ikan Kekek (讨论) 2025年5月26日 12:22 (UTC)[回复]
至少对于本站来说，我认为对于那些鲜为人知的世界地区，抽象列表可能很有用，但总的来说，这似乎是帮助小语种Wikivoyages而不是反之（这也很棒）。//shb (讨论 | 贡献 | meta) 2025年5月26日 13:30 (UTC)[回复]
我提到列表是因为我们已经（为坐标）使用Wikidata了，并且已经讨论过例如营业时间（太复杂而无法处理）。我认为“抽象列表”目前不是一个选项——必须有人决定是否需要一个列表，并在添加时包含一些手动语言。我们可能仍然能从中获得一些有价值的见解，了解如何——以及如何不——设计抽象的Wikivoyage文章使其有用。--LPfi (讨论) 2025年5月26日 14:04 (UTC)[回复]
我有两个想法：
  • 我们需要一种方法来区分适用于Wikipedia的文本块和适用于Wikivoyage（或其他姊妹项目）的文本块。这表明*不*应将英文维基百科作为一切的存储地点。维基百科可能都想要“木星是太阳系中最大的行星。它是离太阳第五远的行星”，但如果Wikivoyage要写一篇关于这颗行星的文章，它听起来可能更像是“木星不是一个可行的目的地，但对天文学和星际导航感兴趣的旅行者可能会对木星巨型博物馆和年度木星节感兴趣”。
  • 我认为英文Wikivoyage可以从抽象内容中受益。显然，我们可以将我们的明星文章“翻译”成抽象内容，从而使其他Wikivoyages受益。然而，想象一下，如果@Sannita (WMF)将it:Roma提升到明星文章水平，然后将其翻译给我们，让我们在Rome中随意复制我们想要的片段，那将给我们带来多大的好处。请记住，虽然抽象内容设置为进行动态自动翻译（例如，如果句子说“罗马的人口是___”，它会始终提供最新的人口估计），但您实际上可以将结果作为纯文本复制粘贴到文章中。
WhatamIdoing (讨论) 2025年5月26日 17:07 (UTC)[回复]
如果我的理解正确，抽象维基百科是用类似1980年代的编程方式运作的，大致上和Lsjbot的文章一样，虽然不局限于已有的数据集。“不可行的目的地”需要被插入和翻译。那篇关于木星的文章与维基百科上的文章几乎没有共同点。
对于罗马，人口统计等信息很容易以抽象形式编写，但抽象的明星文章需要大量特定文章的功能，这些功能需要翻译才能获得另一种语言的版本——而生动的语言很难自动翻译（想想“盲人所以疯了”）。复制列表内容是可以的，一篇好的抽象文章应该包含一个不错的列表选择。
我认为一篇抽象的Wikivoyage文章应该专注于合理地完整，提供*信息*：进入的道路和火车、带有坐标、联系方式和Wikidata链接的列表，以及“下一站”的建议，但很少有正文，大多数文章在数据值之外都相同（……是X村/镇/市……），同样，列表中的事实也只是干燥的列表，而不是像Wikivoyage:Listings中的生动写作。
--LPfi (讨论) 2025年5月26日 17:47 (UTC)[回复]
由于Wikivoyage的文章结构通常比Wikipedia更规范，我认为我们可以利用抽象Wikivoyage。两个领域看起来是可能的起点：列表和短语手册中的短语。
如果一个工具可以创建一个已存在于其他语言中的列表的抽象版本，那么在编辑此处同一部分的条目时就可以提供该列表——“您想添加一家割草机博物馆的列表吗？” 如果在一个列表中编辑了某些部分，那么所有语言中的这些部分都应该得到更新——无论在哪种语言中编辑，我们都会显示该博物馆最后更新的价格。困难的部分在于识别列表元素是否是语言特定的——我们可能会使用来自另一个WV的URL来指向一个英文页面，而我们并不在意该博物馆是否有西班牙语翻译的标签。
在英文WV中，我们有一套标准的短语手册短语，并且大多数短语手册都严格遵循这个列表。这个列表也是其他语言WV中短语手册的基础。创建抽象短语手册似乎相当直接，但需要审查不一致之处。英文中有大约300本短语手册，德文50本，波兰文20本。也许我们可以用它来提供200多本波兰语短语手册。 AlasdairW (讨论) 2025年5月26日 22:44 (UTC)[回复]
对于列表，是的，抽象版本很容易创建。对于名称，我们只需要确定本地名称、其罗马化以及翻译名称的语言。Wikidata中已经有了所有这些结构；“官方URL”也有一个语言属性。酒店的便利设施也可以很容易地描述。不会自动获取任何内容，所以不用担心对英语使用者无关紧要的信息。难做的是我上面链接的示例中的生动语言。
对于短语手册，我不确定是否那么容易，或者说创建一个抽象短语手册是否比仅仅翻译模板并使用字典（或您以其他方式使用的任何翻译方法）更有帮助。语法和发音部分需要根据听众的语言知识来编写，并且短语的翻译需要对上下文有一定的理解，因此大部分是手动的。对于一本好的短语手册，您还需要注意与目标语言相关的特殊性，例如已添加到法语和意大利语短语手册的liberty/liberté等，以及对特定假朋友的警告。
--LPfi (讨论) 2025年5月27日 04:57 (UTC)[回复]
我认为短语手册是那些（与旅行话题一起）几乎不可能创建抽象版本的东西之一。//shb (讨论 | 贡献 | meta) 2025年5月27日 05:23 (UTC)[回复]
你为什么这么认为？
我们已经可以写诸如“你好，一杯咖啡，谢谢”之类的，通过调用Wikidata。这需要扩展（例如，添加“a”和“an”），但原则上似乎并非不可能，至少对于更简单的句子来说是这样。 WhatamIdoing (讨论) 2025年5月27日 17:24 (UTC)[回复]
问题是这样做是否有意义。如果每句话都必须根据目的进行翻译，那么为什么不直接写非抽象短语手册呢？抽象文章的意义在于存在标准短语，可以跨文章使用，例如你在许多酒店都能找到的便利设施的词语。对于短语手册中的短语，问题是相同的萨米短语是否适用于英语和拉脱维亚语（或其他语言）的短语手册？
当英语短语根据上下文翻译时，需要添加一些注释（正式/非正式，阴性/阳性）。在做相同区分的语言中，这些注释是多余的或笨拙的，可能将这两种（或更多）形式视为完全无关（例如，人已故，牛已死）。
对于一杯茶，你可能需要根据你是一个男人还是女人，以及你是向服务员、咖啡馆老板、主人还是主人年幼的孩子要这杯茶来调整措辞。
--LPfi (讨论) 2025年5月27日 20:59 (UTC)[回复]
也许一个例子能说明我的想法
在法语短语手册中，我们有：
一张去 _____ 的票多少钱？
Combien coûte le billet pour _____ ? (kom-BYAN koot luh bee-YEH poor)
一张去 _____ 的票，请。
Un billet pour _____, s'il vous plaît. (ung bee-YEH poor ____ seel voo pleh)
在波兰语WV上，有pl:Rozmówki francuskie，他们的法语短语手册。
Ile kosztuje bilet do...?
Combien coûte le billet pour...?
Poproszę jeden bilet do...
Un billet pour..., je vous prie.
我们还有芬兰语短语手册，其中有：
一张去 _____ 的票多少钱？
Paljonko maksaa lippu _____in? (PAHL-yonk-aw MAHK-sah LEEP-poo _____?)
所以我想，波兰语WV上的芬兰语短语手册可以有：
Ile kosztuje bilet do...?
Paljonko maksaa lippu _____in? (PAHL-yonk-aw MAHK-sah LEEP-poo _____?)
“一张票到...”并不完全相同（翻译波兰语中的法语，意思是“我恳求您”，而不是“请”），所以这个短语在抽象化时需要一些手动调整。 AlasdairW (讨论) 2025年5月27日 22:24 (UTC)[回复]
我认为抽象的理念不是编程“请”，而是用该语言中表示礼貌和尊重的词语或短语来替换，同时提出请求。
我们已经有了性别切换的软件开关，所以这并非是什么神奇的未来技术；这是对多年来可能实现的功能的扩展。 WhatamIdoing (讨论) 2025年5月28日 01:39 (UTC)[回复]
对于芬兰语，没有表示礼貌的词语或短语，但人们经常使用条件句（？）。在某些情况下，人们会在短语中使用该词形式（在芬兰语短语手册和芬兰语的短语手册中）——但在这里问题在于没有礼貌的迹象，这在该语言中很常见。像“你能”这样的短语存在问题，因为大多数语言在“你”和“您”之间有区别。我认为常见情况可以很好地处理，但对于不太为人所知的语系——这些语系最能从抽象文章中受益——边缘情况会更常见。抽象短语手册可能需要针对特定语言进行调整，以避免出现非常具有问题的渲染的奇怪情况。--LPfi (讨论) 2025年5月28日 06:02 (UTC)[回复]
马来语中有两个“请”字，含义和用法都不同。有两个“我们”的词，含义也不同。等等。 Ikan Kekek (讨论) 2025年5月30日 09:34 (UTC)[回复]
我预计所有外语短语都将从现有的短语手册中完全复制。理想情况下，左侧的短语也将是精确的复制品，除非它们被用来创建一个短语手册，作为现有WV的一部分，而该WV目前没有短语手册；但如果左侧的阅读不完美，则问题不大。我假设一个抽象的Wikivoyage会有一种处理引文的机制，因为这对于复制著名演讲等中使用的确切文字至关重要，并且对于抽象的维基百科和维基语录等也是必需的。 AlasdairW (讨论) 2025年5月30日 14:06 (UTC)[回复]
@WhatamIdoing: LPfi基本上解释了我为什么认为抽象短语手册行不通。//shb (讨论 | 贡献 | meta) 2025年5月27日 23:25 (UTC)[回复]

维基媒体基金会董事会2025年选举与问题征集

更多语言 • 请帮助翻译成您的语言

各位，

今年，维基媒体基金会董事会中2名由社区和成员机构选出的董事的任期将届满[1]。董事会邀请整个社区参与今年的选举过程并投票选出继任者。

选举委员会将在基金会工作人员的支持下监督这一过程[2]。治理委员会由非2025年社区和成员机构选举的受托人候选人（Raju Narisetti、Shani Evenstein Sigalov、Lorenzo Losa、Kathy Collins、Victoria Doronina和Esra’a Al Shafei）组成[3]，负责为2025年受托人选举提供董事会监督，并向董事会汇报情况。有关选举委员会、董事会和工作人员角色的更多详细信息，请参见此处[4]。

以下是关键的计划日期：

  • 5月22日 – 6月5日：公告（本次通讯）和提问期[6]
  • 2025年6月17日 – 7月1日：候选人征集
  • 2025年7月：如有必要，成员机构投票筛选候选人（如果超过10人申请）[5]
  • 2025年8月：竞选期
  • 2025年8月 – 9月：两周社区投票期
  • 2025年10月 – 11月：对选定候选人的背景调查
  • 2025年12月董事会会议：新当选的董事就任

在Meta Wiki页面[链接]了解更多关于2025年选举过程的信息——包括详细时间表、候选人流程、竞选规则和选民资格标准。

问题征集

在每次选举过程中，社区都有机会提交问题，供董事会候选人回答。选举委员会从社区提出的问题列表中挑选问题供候选人回答。候选人必须回答申请中的所有必答问题才能获得资格；否则其申请将被取消。今年，选举委员会将挑选5个问题供候选人回答。选定的问题可能是社区提交的问题的组合，如果它们相似或相关。请在此[链接]提交问题。

选举志愿者

参与2025年选举过程的另一种方式是成为选举志愿者。选举志愿者是选举委员会与其各自社区之间的桥梁。他们帮助确保其社区得到代表，并动员他们投票。了解更多关于该计划以及如何加入的信息，请参见Meta Wiki页面[链接]。

谢谢！

[1] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Results

[2] https://foundation.wikimedia.org/wiki/Committee:Elections_Committee_Charter

[3] https://foundation.wikimedia.org/wiki/Resolution:Committee_Membership,_December_2024

[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_committee/Roles

[5] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2025/FAQ

[6] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2025/Questions_for_candidates

此致，

Victoria Doronina

董事会与选举委员会的联络人

治理委员会

MediaWiki 消息推送 (讨论) 2025年5月28日 03:08 (UTC)[回复]

附注：正在计划一次旅行？人工智能可以为您代劳

https://www.thrillist.com/travel/nation/ai-travel-apps —Justin (koavf)❤T☮C☺M☯ 2025年6月1日 07:04 (UTC)[回复]

我想知道我们是否可以设计一个人工智能工具，它能从Wikivoyage获取信息并为您生成摘要。这可以替代Wikivoyagers手动撰写摘要的负担。当然，Wikivoyage的文章应由人类编辑，然后由AI进行总结。我也想把这个建议提给维基百科人，但我自2021年以来一直被封禁，而且我主要在孟加拉维基百科上工作。Sbb1413 (他) (讨论 • 贡献) 2025年6月1日 07:11 (UTC)[回复]

立即投票参加2025年U4C选举

请协助翻译成您的语言

符合资格的选民被邀请参加2025年通用行为准则协调委员会的选举。更多信息——包括资格检查、投票流程信息、候选人信息以及投票链接——可在Meta网站的2025年选举信息页面上找到。投票将于2025年6月17日12:00 UTC结束。

如果您符合资格，请投票。结果将在2025年7月1日前公布。-- 与U4C合作，Keegan (WMF) (讨论) 2025年6月13日 23:01 (UTC)[回复]
很惊讶这么晚才发送。我在Meta上制作了一个关于所有候选人的指南，链接是m:User:SHB2000/U4C guide 2025，供感兴趣者参考。//shb (讨论 | 贡献 | Meta) 2025年6月14日 03:13 (UTC)[回复]

Commons 待删除文件通知

虽然负责提醒我们文件即将被删除的Commons机器人已恢复运行，但仍有文件在未通知的情况下被删除，我猜测可能是那些在5月4日之前提请删除的文件。这个问题在链接的公告中已提及，但我没有意识到其影响。因此，请注意，某些文件可能会被移除，而其讨论页不会收到通知。如果这些文件可能很有价值，它们应该像机器人未运行时那样，暂时恢复并允许本地上传。LPfi (讨论) 2025年6月13日 11:51 (UTC)[回复]

2025年维基媒体基金会董事会 - 候选人征集

大家好，

2025年维基媒体基金会董事会选举的候选人征集现已开放，时间为2025年6月17日至7月2日11:59 UTC [1]。董事会负责监督维基媒体基金会的工作，每位董事任期三年[2]。这是一个志愿职位。

今年，维基媒体社区将在2025年8月下旬至9月投票，以填补基金会董事会的两个（2）席位。您——或者您认识的人——是否适合加入维基媒体基金会董事会？[3]

了解更多关于担任这些领导职位需要什么以及如何提交您的候选资格，请访问Meta-wiki上的此页面，或鼓励他人参加今年的选举。

此致，

Abhishek Suryawanshi
选举委员会主席

代表选举委员会和治理委员会

[1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_elections/2025/Call_for_candidates

[2] https://foundation.wikimedia.org/wiki/Legal:Bylaws#(B)_Term。

[3] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_elections/2025/Resources_for_candidates

MediaWiki 消息推送 (讨论) 2025年6月17日 17:44 (UTC)[回复]

姊妹项目特别工作组审查 Wikispore 和 Wikinews

亲爱的维基媒体社群：

维基媒体基金会董事会下属的社群事务委员会（CAC）已指派姊妹项目特别工作组（SPTF）来更新和实施一项程序，以评估姊妹项目——即由维基媒体基金会（WMF）支持的维基项目——的生命周期。

相关的、可访问的、有影响力的自由知识愿景一直指导着维基媒体运动。随着维基媒体项目生态系统的不断发展，我们必须定期审查现有项目，以确保它们仍然符合我们的目标和社群能力。

尽管初衷崇高，但有些项目可能已不再有效地服务于其最初目的。审查这些项目并非意味着放弃——而是负责任地管理共享资源。志愿者的时间和精力、员工的支持、基础设施和社群的关注都是有限的，而且随着我们的生态系统进入了一个不同于我们成立之初的互联网时代，非技术成本往往会显著增加。支持不活跃项目或未能实现我们目标的项目，可能会无意中将这些资源从更具潜力的领域转移开。

此外，维护不再反映维基媒体名称所代表的质量和可靠性的项目，会带来声誉风险。被放弃或不太可靠的项目会影响对维基媒体运动的信任。

最后，未能结束或重新设想不再奏效的项目，会使启动新项目变得更加困难。当社群感到必须遵循每一个过去的决定——无论多么过时——我们就会面临停滞的风险。一个健康的生态系统必须允许进化、适应，并在必要时放手。如果我们创造出每个项目都必须无限期存在的期望，我们就限制了我们实验和创新的能力。

因此，SPTF审查了两个关于姊妹项目生命周期的请求，以进行演示和展示审查过程。我们选择了Wikispore作为可能新开姊妹项目的案例研究，并以Wikinews作为现有项目审查的案例研究。初步调查结果已与CAC进行了讨论，并建议对这两个提案进行社群咨询。

Wikispore

考虑Wikispore的申请是在2019年提交的。SPTF决定更深入地审查此请求，因为与其他大多数新姊妹项目提案不同，Wikispore没有集中于特定主题，而是有潜力培育多个初创姊妹项目。

经过仔细考虑，SPTF决定不推荐Wikispore作为维基媒体姊妹项目。考虑到目前的活跃程度，目前的安排更具灵活性并有利于实验，同时WMF提供核心基础设施支持。

我们承认该计划的潜力，并寻求社群的投入，以确定未来是否需要重新考虑其地位，需要何种程度的活动和参与。

作为流程的一部分，我们已将此决定告知Wikispore社群，并邀请其领导者之一Pharos参加了一次SPTF会议。

目前，我们特别邀请就指示项目准备情况的可衡量标准（如贡献者数量、内容量和持续的社群支持）提供反馈。这将阐明开放新姊妹项目（包括未来Wikispore可能的重新申请）的充分标准。然而，数字永远只是一个指导，因为任何数字都可能被操纵。

Wikinews

我们选择审查现有的姊妹项目Wikinews，因为它是在多个方面引起最高程度关注的项目。

自2023年SPTF成立以来，其成员在会议和社群电话会议中询问了关于未能在维基媒体运动中实现承诺的姊妹项目的社群意见。[1][2][3] Wikinews之所以成为评估的领先候选者，是因为来自多个语言社群的人提出了它。此外，根据大多数指标，它是最不活跃的姊妹项目，其活跃度多年来下降幅度最大。

虽然语言委员会定期为小语种的姊妹项目开设和关闭语言版本，但从未有过关闭主要语言维基百科或任何英语项目的有效提案。Wikinews并非如此，曾有提议关闭英语Wikinews，该提议获得了一定的支持但未采取任何行动[4][5], 参见第5节，以及一项关闭所有语言Wikinews的草案提案[6]。

WMF员工汇编的初步指标也支持社群对Wikinews的担忧。

基于这份报告，SPTF建议社群重新评估Wikinews。我们认为其当前的结构和活跃度是现有姊妹项目中最低的。SPTF还建议在咨询期间暂停开设新的语言版本。

SPTF将此分析提交讨论，并欢迎讨论替代方案，包括潜在的重组工作或与其他维基媒体倡议的整合。

迄今为止提到的选项（可能适用于仅低活跃度语言或所有语言）包括但不限于：

  • 重组Wikinews的运作方式及其与其他当前事件倡议的关联，
  • 将Wikinews的内容合并到相关的语言维基百科中，可能在一个新的命名空间下，
  • 将内容合并到兼容许可的外部项目中，
  • 归档Wikinews项目。

您的见解和观点对塑造这些项目的未来至关重要。我们鼓励所有感兴趣的社群成员在相关的讨论页面或通过其他指定的反馈渠道分享您的想法。

反馈和下一步

如果您愿意参与关于这些项目未来和审查过程的对话，我们将不胜感激。我们正在设置两个不同的项目页面：关于Wikispore的公开咨询和关于Wikinews的公开咨询。请在2025年6月27日至2025年7月27日期间参与，之后我们将总结讨论并继续前进。您可以使用您自己的语言撰写。

我将于7月16日星期三11:00 UTC和7月17日星期四17:00 UTC（稍后提供通话链接）主持社群对话，并在Wikimania期间进行更多讨论。

-- Victoria 代表姊妹项目特别工作组， 2025年6月27日 20:57 (UTC)[回复]

我不得不说，Wikinews是WMF最失败的项目之一。英语Wikinews勉强维持，我认为目前还可以，但是其他Wikinews项目缺乏编辑基础来积极审查新新闻文章。在tawikinews的关闭提案中，他们最新的文章日期是2018年！//shb (讨论 | 贡献 | Meta) 2025年6月28日 02:56 (UTC)[回复]
我认为这类事情应该发布在Meta项目页面上：关于Wikispore的公开咨询和关于Wikinews的公开咨询。WhatamIdoing (讨论) 2025年6月28日 22:42 (UTC)[回复]
我知道；我只是想简短地发表我的看法——我计划了一个更长的建议列表，等我有更多空闲时间再写。//shb (讨论 | 贡献 | Meta) 2025年6月28日 23:44 (UTC)[回复]

普遍关切

我不喜欢Wikinews，但姊妹项目特别工作组发布的报告中有令人担忧的一点。这份报告的语气非常批判性，特别是它没有提到数十甚至数百名志愿者投入了大量时间来发展Wikinews。报告没有提到他们工作的任何一个亮点，这似乎不公平。报告表明Wikinews目前的活跃度和内容发展水平很低（这一点是公平的），但它没有设定一个社区值得WMF提供资源的最低标准。此外，报告也没有尝试分析Wikinews编辑者为了发展他们的项目采取了哪些步骤，以及为什么这些步骤不成功。它只是说：你们做得不好，所以我们要关闭你们，甚至剥夺你们将Wikinews转移到别处的任何可能性，因为这个名字属于维基媒体基金会。

Wikivoyage也是一个较小的项目，如果出现类似严厉的报告，那将是令人沮丧的。这并非完全不现实，因为一半的语言版本都是休眠的，而许多其他版本的指标与最活跃的Wikinews版本相当。我认为只有英语Wikivoyage明确高于这一门槛，尽管实际门槛甚至没有定义，所以几乎任何活动水平都可以被认为是“低”的，如果你想这么说的话。

您对此有何看法？--Alexander (讨论) 2025年6月28日 09:53 (UTC)[回复]

我没有使用过Wikinews，所以我的反思基于瑞典语Wikinews的关闭和当前的讨论（如上链接）。讨论中提出的一点是，所选的指标并未考虑到该项目的特殊性质。
我假设姊妹项目特别工作组的评估是必要的，但我也认为评估应该侧重于是否有前进的道路，而不是项目是否根据当前趋势可行。
Wikinews的问题在于需要一个相当活跃的编辑群体——维基百科甚至Wikivoyage即使一年或两年没有编辑也能维持和保持有趣，而一个新闻机构会失去几乎所有的读者。覆盖范围至少要在某些区域（地理或主题）上足够，才能保持其趣味性。所需的临界质量要大得多——而且这个临界质量还需要能够对抗那些有偏见（善意或恶意）或有与项目目标不符议程的人——阻止垃圾信息要容易得多。我猜测只有在有希望快速建立临界质量的情况下，才应该开始新的语言版本。
–LPfi (讨论) 2025年6月28日 10:36 (UTC)[回复]
是的，我认为语言委员会已决定暂停创建所有新的Wikinews项目，原因正是如此。//shb (讨论 | 贡献 | Meta) 2025年6月28日 23:46 (UTC)[回复]
Alexander，确实“数十甚至数百名志愿者投入了大量时间来发展Wikinews”，但同样，因为过去的努力而维持一个失败的项目是沉没成本谬误的一个例子。
我猜测，如果有人提出一个可信的提议将Wikinews转移到另一个主机，WMF会愿意就名称进行谈判。（但任何新的赞助商可能都倾向于使用自己的名称。）WhatamIdoing (讨论) 2025年6月29日 03:31 (UTC)[回复]
我猜我的主要问题是，没有任何明确的标准来区分一个可持续的项目和一个失败的项目。您明白这些标准是什么吗？-- Alexander (讨论) 2025年6月29日 08:35 (UTC)[回复]
一个明确定义什么是可持续项目的标准，仍然很大程度上依赖于项目的功能。对于Wikinews来说，它需要非常活跃，而对Wikivoyage或Wikibooks适用的指标，例如文章数量，并不那么相关，因为20000篇文章如果最后一篇是两个月前写的，就没什么意义了（这些数字是假设的，但我的观点是成立的）。//shb (讨论 | 贡献 | Meta) 2025年6月29日 08:50 (UTC)[回复]
我同意，不能将同样的指标应用于所有姊妹项目，但“非常活跃”留下了很大的解释空间。想象一下，有人决定Wikivoyage不可持续，因为它包含大量在过去五年未更新的过时旅行信息。那将是个问题……-- Alexander (讨论) 2025年6月29日 09:27 (UTC)[回复]
我们不想要明确的标准。需要对项目的实际前景进行判断。开放社群讨论是好的，因为这是了解指标是否给出正确图景的一种方式——尽管在开放此类讨论之前应该与项目进行沟通（我不知道在多大程度上进行了此类沟通）。–LPfi (讨论) 2025年6月29日 20:13 (UTC)[回复]
我仍然不喜欢SPTF决定大规模地将这些消息发送给每个维基百科，而没有咨询Wikinews社群；这真的应该由他们（我指的是更活跃的Wikinews项目，如en或ruwikinews）来决定他们的项目未来，而不是我们其他人或绝大多数不参与Wikinews的人。//shb (讨论 | 贡献 | Meta) 2025年6月29日 23:01 (UTC)[回复]
是的。问题本应首先与项目（不仅是大项目，而是所有受影响的项目）提出。我不知道这是否被做到，但显然做得不够，总之。似乎SPTF (?) 想引入一种更普遍的项目再评估的做法，并选择了这两个作为例子。他们本应明白，这样做，在未经咨询的情况下，会激怒人们。–LPfi (讨论) 2025年6月30日 06:40 (UTC)[回复]
恕我直言，之前有过几次关闭提案，包括关闭所有语言的Wikinews。主要项目的提案失败了，但可以认为这是一个给社群评估自身表现的信号，而他们显然没有收到。但我同意，在先通知Wikinews社群之前就开启这样的讨论实在不好。Ymblanter (讨论) 2025年6月30日 08:54 (UTC)[回复]
他们确实应该这样做；我希望他们能吸取教训，因为英语Wikinews社群的情绪在这种讨论中显然非常不满意。//shb (讨论 | 贡献 | Meta) 2025年6月30日 09:01 (UTC)[回复]
好吧，这个评论无疑像牛奶一样变质了。//shb (讨论 | 贡献 | Meta) 2025年6月30日 13:59 (UTC)[回复]
哦，天哪。我希望SPTF中还有其他更敏锐的人。这有可能会演变成又一起“WMF不尊重社群”的事件。–LPfi (讨论) 2025年7月1日 08:40 (UTC)[回复]
SPTF（或者至少是Victoria）似乎如此预先决定要关闭Wikinews，以至于我从未听过如此明显带有偏见的话，例如“然而，我预计Wikinews的人员会处于利益冲突状态”——所以对他们来说，了解自己项目的细节居然是利益冲突？这是对非维基百科项目的巨大侮辱。//shb (讨论 | 贡献 | Meta) 2025年7月1日 11:04 (UTC)[回复]
我可以理解她的观点，但我认为这是错误的，她团队中的某个人应该让他们讨论他们的实际任务。如果一个项目确实需要被停止，那么这个过程需要非常谨慎地进行——而在这一阶段的咨询不应该是关于是否要停止Wikinews。它是“为了演示和展示审查过程”、“一次社群再评估”和“潜在的重组工作”。
过程的演示是一场灾难，潜在的重组工作需要对项目有深刻的理解，而没有与社群进行敏锐的讨论是不可能获得的。
“再评估”应该基于这些潜在的重组路径，重组不是关于把Wikinews的内容 dump 到哪里，而是关于如何拯救这个项目，如果可能的话。
–LPfi (讨论) 2025年7月1日 13:13 (UTC)[回复]
我完全同意您关于“再评估”的看法，但他们回应社群反馈的方式让人感觉结果是预先确定的，这仅仅是一个走过场——这就是为什么我认为我们作为一个姊妹项目，就这个问题被如何糟糕地处理发言是很重要的，因为谁知道当轮到我们进行公开咨询时，他们会怎么做。//shb (讨论 | 贡献 | Meta) 2025年7月1日 14:04 (UTC)[回复]
我在meta:Talk:Public consultation about Wikinews#Process and analysis seem flawed中写了一些担忧。–LPfi (讨论) 2025年7月1日 21:34 (UTC)[回复]
谢谢，LPfi；希望我们的项目会没事的（我认为它会没事的，因为Wikivoyage或任何其他WMF项目没有像Wikinews那样需要一个活跃社群的问题），但更多的反馈肯定更好。//shb (讨论 | 贡献 | Meta) 2025年7月2日 03:49 (UTC)[回复]
虽然我同意这个流程在某种程度上是错误的（我也同意LPfi在Meta上的回复中的观点），但看看用于分析的某些指标（无论多么错误）是否可以为Wikivoyage进行改进，从而使其不再是争论的焦点，将会很有用。Ymblanter (讨论) 2025年7月2日 08:18 (UTC)[回复]
@Victoria：作为主要作者，并为您提供深刻的反馈：在一定程度上，如果这个特别工作组正在评估姊妹项目，那么单个社群知道评估其健康状况的评分标准将会很有帮助。—Justin (koavf)❤T☮C☺M☯ 2025年7月2日 19:55 (UTC)[回复]
首先，特别工作组并不是在评估所有姊妹项目，Wikispore/Wikinews是一个概念验证练习。
我们使用了这个评分标准，它在一年前的公开咨询中进行了讨论——但没有得到太多关注，因为Meta上充斥着从未实施过的文件。
在Wikispore咨询中，我们征求关于“活跃度”和其他标准的明确提案。Victoria (讨论) 2025年7月3日 09:11 (UTC)[回复]
谢谢你，也谢谢你让我通过ping在各种WMF项目里转来转去。—Justin (koavf)❤T☮C☺M☯ 2025年7月3日 09:38 (UTC)[回复]
不客气。我很高兴在没有个人攻击的情况下，用英语/俄语/白俄罗斯语回答任何问题。Victoria (讨论) 2025年7月3日 10:15 (UTC)[回复]
LPfi，我不是在说复制“信息”；我说的是复制整个页面，逐字逐句。
我们确实有可复制的选项；有多个旅游网站拥有合适的版权许可。你知道如果我们这里的某个人决定通过从Wikitravel复制来“帮忙”，会发生什么。看看https://travel.fandom.com/wiki/Travel_Wiki，它的页面风格相似，但章节标题不同。WhatamIdoing (讨论) 2025年7月2日 21:34 (UTC)[回复]
我们确实从酒店网站和其他来源复制信息，但我们没有可靠的、以我们风格书写的免费内容。成为可靠新闻的渠道可以是Wikinews的使命（或多或少就像一些“社交媒体”网站那样）。如果是这样，问题在于它们能否做得足够好，使其成为WMF项目有价值的（以及它们所做的其他事情是否做得好）。但这不是SPTF发起的讨论，他们选择用统计数据来衡量。–LPfi (讨论) 2025年7月2日 22:12 (UTC)[回复]
有人提到统计数据可能被机器人夸大——我仍然不确定如何区分统计数据是否被机器人夸大。//shb (讨论 | 贡献 | Meta) 2025年7月2日 23:11 (UTC)[回复]
大多数机器人，尤其是大多数大型机器人，在页面请求中都有一个适当的用户代理字段，因此服务器日志可以用来区分至少那些。通过更高级的技术，您还可以区分典型的机器人行为和人类用户的行为。存在一些灰色区域（例如，一个人使用了一个非典型的Web浏览器工具，或者通过浏览器使用某些脚本，以及配置成看起来像人类的机器人），但我认为要获得机器人与人类流量的相当准确和可靠的图像并非不可能。–LPfi (讨论) 2025年7月3日 10:37 (UTC)[回复]
很高兴知道——我想你可以通过例如页面浏览量的突然激增来识别，但是的，除非你告诉我，否则我无法具体分辨。//shb (讨论 | 贡献 | Meta) 2025年7月3日 10:42 (UTC)[回复]
从汇总数据来看，可以识别出一些可能由机器人引起的模式，但要确定，您必须查看用户代理字段，并且当普通用户代理产生机器人般的模式时，您必须分析单个流量来源的行为——如果有人试图将他们的机器人伪装成多个普通用户，那将不是一件容易的事。–LPfi (讨论) 2025年7月3日 10:54 (UTC)[回复]
LPfi，我不是在谈论复制“信息”；我是在谈论复制整个页面，逐字逐句。
我们确实有可复制的选项；有多个旅游网站拥有适当的版权许可。你知道如果有人决定通过复制Wikitravel来“帮忙”，会发生什么。看看https://travel.fandom.com/wiki/Travel_Wiki，它的页面风格相似，但有不同的章节标题。WhatamIdoing (讨论) 2025年7月3日 17:39 (UTC)[回复]

意见征询通知

请注意，Meta上有一个关于付费编辑和高级权限的意见征询，链接为m:Requests for comment/Should paid editing as a CU be allowed。您可以就该主题表达您的担忧。

此消息旨在通知尚未在此RFC中发表评论的人。对于已发表评论的人，您可以忽略此消息。

请勿回复此消息。 〈兴华街〉📅❓ 2025年7月4日 08:43 (UTC)[回复]

@HingWahStreet：我认为这与本项目无关；任何语言的Wikivoyage项目都没有CU，这对本项目无关。//shb (讨论 | 贡献 | Meta) 2025年7月4日 09:11 (UTC)[回复]
@SHB2000 抱歉，我不知道这个。〈兴华街〉📅❓ 2025年7月4日 09:45 (UTC)[回复]
@HingWahStreet：是的，我问是因为您只在这个项目上留下了信息（根据GUC检查）——我明白您想发送给所有项目（我也不赞成这样做，但谁又能阻止你呢），但您发送的唯一项目甚至没有CU。//shb (讨论 | 贡献 | Meta) 2025年7月4日 09:52 (UTC)[回复]
@SHB2000 您的意思是我们只能由CU（而不是其他人）加入讨论？ 〈兴华街〉📅❓ 2025年7月4日 13:36 (UTC)[回复]
@HingWahStreet：不，我从未说过那样的话——我试图表达的是，仅仅通知enwikivoyage一个与本项目完全无关的RfC，这才让我感到好奇。//shb (t | c | m) 2025年7月4日 13:40 (UTC)[回复]
事情是这样的：一个小型维基百科的CU最近创建了一家撰写维基百科文章的公司。这让一些人突然意识到，CU（检查员）并没有被官方禁止成为“有偿编辑”。他们提议，CU不能从事某些有偿编辑工作（例如为公司撰写文章），但可以从事其他工作（例如为艺术博物馆撰写文章）。
我怀疑这会给我们带来任何影响，也怀疑这会带来多大的整体影响。 WhatamIdoing (talk) 2025年7月4日 16:48 (UTC)[回复]
我可能弄错了，但我认为HingwahStreet也与Bojan（涉足有偿编辑的srwiki CU）有过一些过往（但这与此次RfC的最终结果无关）。//shb (t | c | m) 2025年7月4日 23:01 (UTC)[回复]
为你节省点击：CU == Checkuser（检查员） Brycehughes (talk) 2025年7月7日 18:29 (UTC)[回复]
但是，检查员（checkuser）到底是什么？ Brycehughes (talk) 2025年7月7日 18:37 (UTC)[回复]
检查员是某些维基上的一小部分用户，他们可以使用工具来揭示用户名的IP地址信息。我们还没有发现需要任命任何检查员。 AlasdairW (talk) 2025年7月7日 21:12 (UTC)[回复]
可以论证说，本维基可以任命CU，这样做也有好处，但作为自2022年以来处理本维基所有SRCU请求的人，我认为目前由管理员进行CU检查已经足够了。//shb (t | c | m) 2025年7月8日 08:58 (UTC)[回复]
m:CheckUser。 —Justin (koavf)❤T☮C☺M☯ 2025年7月7日 22:03 (UTC)[回复]

英国法律与维基媒体基金会挑战

EFF 关于对《在线安全法案》的挑战。这也会影响我们。 Pashley (talk) 2025年7月18日 03:51 (UTC)[回复]

参见 https://wikimediafoundation.org/news/2025/07/17/wikimedia-foundation-challenges-uk-online-safety-act-regulations/ WhatamIdoing (talk) 2025年7月18日 07:03 (UTC)[回复]

U4C（通用行为准则协调委员会）招募非投票候选人

从讨论区（pub）移来

通用行为准则协调委员会（U4C）最近发布了招募公告，旨在招募有兴趣成为非投票成员的人员。通过去年的年度审查，社区批准任命最多4名非投票成员，U4C现已创建了招募地点和流程供志愿者表达兴趣。如果您知道任何可能感兴趣的人，请介绍给他们。如果您有任何疑问，请随时提问（或在此处提问）。此致， Barkeep49 (talk) 2025年8月2日 21:15 (UTC)[回复]

@Barkeep49，非投票成员的目的是填补投票成员技能上的空白。是否有任何列表说明了已知的空白？ WhatamIdoing (talk) 2025年8月3日 16:52 (UTC)[回复]
不完全是。目前有3个区域席位空缺：拉丁美洲和加勒比地区、中欧和东欧（CEE）以及撒哈拉以南非洲。还有一些明显的模式，包括7位（8位中）主要项目是维基百科（第8位是Wikidata），这就是为什么我在这里发帖以及他们说的语言。此致， Barkeep49 (talk) 2025年8月3日 20:34 (UTC)[回复]

维基旅行和“附近文章”地图

你们是如何使用“附近”功能的（主要是维基百科应用程序里的）？

它仍然显示着各种各样的文章，例如墓地、学校、火车站等，这些对旅行者来说都不太相关，所以我想知道为什么似乎没有人对此有意见，以及为什么维基旅行的用户对这张地图的参与度如此之低，尽管它对度假/探索地点/维基旅行事物如此有用。也许这里的人们使用别的东西，或者有什么技巧可以让“附近”地图在现实场景中有用，或者有相关的讨论。 Prototyperspective (talk) 2025年7月27日 21:10 (UTC)[回复]

我认为这只是我们很多人都忘记了它，因为它是一个不常被提及的功能。//shb (t | c | m) 2025年7月28日 00:14 (UTC)[回复]
我刚试了一下，它工作正常，但如果它有问题，我也愿意做出改变。这可能是一个读者比编辑者使用更多的功能。 --由 Selfie City (talk) (contributions) 2025年7月28日 01:07 (UTC)[回复]
我也忘了它的存在。 Ikan Kekek (talk) 2025年7月28日 01:19 (UTC)[回复]
您是在真实场景中试用过，还是仅仅在家中测试？
我问这个问题是因为 phab:T360197 没有得到任何回应，而这个功能潜力巨大——尤其对于维基旅行相关的事务，比如度假——在大多数情况下似乎需要进行一些修改才能使其真正适用于现实应用。
参见 meta:Community Wishlist/Wishes/Filters for types of items shown on the Wikipedia app Nearby places map。我无法在探索地点时使用此功能，除非是地图上几乎没有任何文章的偏远地区。
最后，我不知道为什么维基旅行会广泛忽略这个功能——它似乎是维基旅行的“招牌”功能，例如，是维基百科应用程序中大多数人第一次了解和使用维基旅行的途径。 Prototyperspective (talk) 2025年7月28日 11:19 (UTC)[回复]
我倒觉得是因为你在桌面上（desktop）不能真正地使用它，而大部分编辑工作发生在桌面上。维基旅行的手机版（mobile），这个功能最派上用场的地方，很烂，所以我们很多人都忘记了它的存在。//shb (t | c | m) 2025年7月28日 23:37 (UTC)[回复]
它在移动应用程序中可用。由于那里的地图比桌面版本先进得多且有用，桌面版本甚至没有地图或用于输入位置的输入框，我指的是移动应用程序中的“附近”功能。（顺便说一句，我好像在哪里读到过关于维基旅行移动应用程序的提案。） Prototyperspective (talk) 2025年7月28日 23:41 (UTC)[回复]
很遗憾，截至目前维基旅行还没有自己的移动应用程序。 :(// shb (t | c | m) 2025年7月29日 00:51 (UTC)[回复]
是的，我说的正是“我好像在哪里读到过关于维基旅行移动应用程序的提案。”。而说“它在移动应用程序中可用。”时，我指的是我之前评论中提到的维基百科应用程序。 Prototyperspective (talk) 2025年7月30日 11:25 (UTC)[回复]我好像在哪里读到过关于维基旅行移动应用程序的提案。它在移动应用程序中可用 我指的是我之前评论中提到的维基百科应用程序。
我强烈反对“火车站……与旅行者无关”的说法，我个人也喜欢参观老墓地。也许我们需要过滤器，但要弄清楚包含什么或排除什么可能很困难。 WhatamIdoing (talk) 2025年7月28日 15:08 (UTC)[回复]
这是为了让用户可以配置它。火车站显然对许多旅行者都非常重要。 Prototyperspective (talk) 2025年7月28日 16:01 (UTC)[回复]
好功能，但有没有办法将其集成到WV中，还是必须使用WP应用程序？我 Actually 曾想发明类似的东西——基本上是抓取附近文章，获取它们的所有列表，然后将其显示在地图上，最好按WP的浏览量排序。我认为WV不能仅仅显示WP文章，否则维护这些列表就没有意义了。-- andree 2025年7月30日 11:53 (UTC)[回复]
但有没有办法将其集成到WV中 这也是这个帖子在讨论的内容：有 Special:Nearby，但它远不如移动应用程序中的地图先进，而且重要的是，你甚至无法输入位置（参见Wish:Enable entering a specific location on Wikipedia's & Wikivoyage's Nearby page）。它不显示地图，只显示文章列表，这不太有用。此外，维基旅行中的版本只显示WV中的页面，维基百科中的版本只显示WP中的文章，但我认为它应该同时显示两者（如果它们是关于同一个地方，那么点击的点就可以让你选择打开哪个）。最好按WP浏览量排序 我会编辑phab:T360197，添加页面浏览量作为另一个要使用的内容为了能够排除低重要性的文章，将使用相关Wiki项目的重要程度评分，我从这里得到的一个想法是，不仅通过这种方式过滤，而且根据评分和/或页面浏览量以不同的方式显示它们，例如，浏览量相对较多的条目显示为更大或不同颜色的点。 Prototyperspective (talk) 2025年7月30日 14:32 (UTC)[回复]
我认为仅仅考虑文章是不够的，对于WV来说也是如此，仅仅添加WP的东西也是不够的（很多文章往往只是本地语言版本，在en:上没有覆盖，或者在很大程度上匹配Wikivoyage:Listings#Boring_places、战争事件地点等）；另外，特别是偏远地区有时有10个列表，例如只有一个在WP上……因此，我认为需要某种混合操作，以便能够找到“附近最好的列表”。
至于地图，你可以通过动态地图底部的相应按钮显示它 -- andree 2025年7月30日 18:41 (UTC)[回复]
这取决于地区。在许多情况下，例如大城市，大多数最著名的景点和公园等都有文章。地图的目的是展示用户可能感兴趣的所有地点，这不是期望它能做到的。 （维基旅行也可以朝着那个方向改进地图。）它不一定是关于“寻找附近最好的列表”，也可以是例如“从维基百科了解你目前所在地的有趣地点”，以及“寻找附近某个好地方考虑去看看”和“寻找附近有趣的地点考虑访问”。
-
我也不太确定你的意思——我建议将维基百科文章和维基旅行列表结合起来。是的，理想情况下，还可以添加该地区的本地语言文章。应用程序中可以提供的一个特殊功能是机器翻译，通过MinT，这样就不会是乱码，而是对不讲当地语言的应用程序用户来说多少可以理解。
地图不显示维基旅行+维基百科的项目。首先，它只在你访问某个地方的WV页面并打开其地图时才有效。例如，当您访问一个没有WV页面的地区时，这就不行了。点击“显示附近文章”时，它只显示非常少的文章，而不是维基百科中的所有文章，我不知道为什么。 Prototyperspective (talk) 2025年7月30日 23:19 (UTC)[回复]

我在内罗毕参加维基媒体会议时测试了这一点。附近页面只显示内罗毕和2025年内罗毕维基媒体会议指南。我认为，这个功能应该划定更大的半径，因为它目前没什么用。 OhanaUnitedTalk page 2025年8月6日 13:27 (UTC)[回复]

维基旅行是否需要关于在世人物描述的政策？

维基旅行是一个旅游指南，并非旨在收集传记。尽管如此，旅游主题和行程可能会提及重要人物，例如探险家、艺术家、君主和政治家。 Wikivoyage:What is an article? 劝阻创建关于在世名人的文章，因为这些文章比关于克里斯托弗·哥伦布、弗兰克·劳埃德·赖特或阿斯特丽德·林德格伦的文章更难完成。像《美国总统》和《英国君主制》这样的文章描述了仍在世且未结束职业生涯的人物，并且肯定会有争议。在撰写《犹太斯德哥尔摩之旅》、《斯德哥尔摩环保主义者之旅》和《北欧君主制》时，我想到了几个著名的在世人物，但我发现最好尽量简要提及他们。我们应该遵循哪些通用原则？ /Yvwv (talk) 2025年6月9日 12:58 (UTC)[回复]

看起来 foundation:BLP 鼓励我们制定正式政策，即使没有太多要说的。也许可以参考Project:Don't be evil？
我们已经有了 Wikivoyage:Photographs of identifiable people 和 Wikivoyage:Image policy#People in photos，这些都劝阻拍摄人物照片。 WhatamIdoing (talk) 2025年6月9日 20:36 (UTC)[回复]
我也支持同样的政策。//shb (t | c | m) 2025年6月11日 11:40 (UTC)[回复]
我认为这在很大程度上与旅游指南不相关，但实际上有“明星地图”或洛杉矶地区名人故居游览是很常见的，在我看来这完全是疯狂的，并且不应该被鼓励。考虑到Whatamidoing关于WMF鼓励这种文档的观点，我认为制定指南/政策是明智的。想法不错。—Justin (koavf)❤T☮C☺M☯ 2025年6月9日 21:00 (UTC)[回复]
是的，我绝对反对任何关于带人们去他们宁愿保持隐私的名人故居的行程。如果这种游览在纽约存在，纽约人会对此大发雷霆，并敦促市议会出台相关法律。 Ikan Kekek (talk) 2025年6月9日 21:35 (UTC)[回复]
关于照片的页面和部分内容很少，主要是劝阻拍摄自己的照片，但这与我们要讨论的内容无关。内容更多，并且也应该遵守本地上传的图片。这三个都没有说明关于人物的文字（除了标题不应诽谤）。
我认为我们可能不应该制定政策，除非出现实际问题。我们没有理由写大多数人的信息，并且似乎常识，就像Yvwv上面展示的那样，效果相当好。制定政策会留下漏洞和曲解。
–LPfi (talk) 2025年6月9日 21:50 (UTC)[回复]
我是否可以将在我们现有的 Wikivoyage:Be fair 政策中加入一个关于“在世人物生平（BLP）”的部分？基本上，关于避免提及个人，特别是避免说任何有争议或不公平侵犯隐私的事情的几条原则。 WhatamIdoing (talk) 2025年6月10日 16:40 (UTC)[回复]
这听起来很合理。过去我曾反对过创建基于在世个人行程的建议。
更常见的情况是，某个列表提到了在酒店或餐厅工作的人员。“友好的老板”或“服务员服务不周”是可以的，但提及工作人员的名字需要更谨慎。 AlasdairW (talk) 2025年6月10日 23:04 (UTC)[回复]
当主厨或糕点师的名字印在菜单上，或者餐厅宣传的都是知名厨师时，肯定是可以的。 Ikan Kekek (talk) 2025年6月10日 23:40 (UTC)[回复]
艺术家的个人生活能否与其作品分开？至少，死亡有助于结束人生故事。乔治·里德尔（Georg Riedel）在一年前去世，他值得在《犹太斯德哥尔摩之旅》中被描述。亚历山大·沃洛达尔斯基（Aleksander Wolodarski）是另一个值得提及的人，但他还健在（并且在某种程度上是瑞典建筑界一个有争议的人物），因此在同一篇文章中对他的描述非常简短。《哈利·波特旅游》几乎没有提及作者，这也许是好的。//Yvwv (talk) 2025年6月11日 10:16 (UTC)[回复]
我认为可以提及名人厨师的名字（“Thomas Keller的餐厅，The French Laundry”），甚至一个相对公开的非名人（“餐厅老板Mary Smith也是这个小镇的长期镇长”或“Olly Owner乐意应要求打包野餐”）。
然而，作为 Wikivoyage:Avoid negative reviews 的延伸，我们实际上不希望看到“Chris Celebrity很做作，餐厅价格过高”或“Wendy Waitress不友好且动作慢”。 WhatamIdoing (talk) 2025年6月11日 17:26 (UTC)[回复]
我认为“服务员不友好”是可以避免的，但“一些工作人员不友好”是可以接受的。如果负面情况被“出色的烹饪和美味的面包”所平衡，或者它是镇上唯一的餐馆，那么报告负面方面很重要。对于一人经营的生意来说，这会变得更加困难。 AlasdairW (talk) 2025年6月11日 20:24 (UTC)[回复]
维基旅行不应关注人物：这是维基百科的领域。然而，维基旅行关注与人物相关的地点，为此应谨慎对待其隐私。但如果相关个人邀请公众进入其住宅或企业（例如，唐纳德·特朗普有一个关于海湖庄园的网站），那么保护其隐私就不再是维基旅行的职责：如果他公开自己的住所，那么他就有责任保护自己的隐私。相比之下，乔·拜登似乎并不宣传他的住所，因此维基旅行也不应该（即使在互联网搜索会显示乔·拜登的房产）。Martinvl (talk) 2025年6月12日 15:18 (UTC)[回复]
这样的草案感觉如何？
----
作为一般规则，维基旅行关注的是地点，而不是人物。偶尔，提供公平的描述会涉及提及特定人物。在这种情况下，这些原则适用于保护在世人物。
  • 尽可能避免关于在世人物的有争议内容，以示对人类尊严和个人隐私的尊重。发布与文章需求无关、琐碎、短暂或构成负面评价的个人信息是不公平的。例如，如果一家餐厅的老板向顾客宣传可疑的信念，那么就完全省略该列表，而不是写关于老板的信念。
  • 避免整篇文章都专注于在世人物，例如名人故居参观行程。以泰勒·斯威夫特的演唱会巡演为主题的行程是公平的；以她的故居为主题的文章则不公平。
  • 列出在世公众人物的单个条目是可以接受的，只要内容不具争议性。然而，当一般性描述足够时，您应该避免提及在世人物的名字。例如，写“老板很乐意谈论当地历史”，而不是“老板Harry Historian乐意谈论当地历史”，即使你会提及名人厨师Thomas Keller作为餐厅The French Laundry的老板。
----
应该修改、添加、省略什么？ WhatamIdoing (talk) 2025年6月12日 16:39 (UTC)[回复]
感谢您提供草稿！其中“可疑的信念”部分在我看来有点问题，这给了不宽容的无神论者一个抱怨“ بسم差”（bismillah）或十字架在餐厅的口实。 Ikan Kekek (talk) 2025年6月12日 17:12 (UTC)[回复]
我想到的是政治信念，特别是疫情期间我读到的一家反对戴口罩的餐厅，但你说得对：这需要修改措辞。 WhatamIdoing (talk) 2025年6月12日 23:30 (UTC)[回复]
我认为这仍然是一个好的开始。//shb (t | c | m) 2025年6月13日 12:15 (UTC)[回复]
我不认为应该因为业主或员工的信念而删除企业；业主宣扬反疫苗或地平说理论可能很有趣，而不是拒绝他们的理由。有人可能会说他们可能会提出有争议的话题。对于危险行为，例如在需要时未戴口罩，这将被视为与使用受污染的水或其他类似情况一样。是的，有时这 warrants根据《无差评》删除列表，但这与隐私关系不大。
对于一家芬兰企业，有人建议删除列表，因为存在偏见，实际上是维基旅行的抵制。我不确定在多大程度上应该这样做，但我认为，如果我们让读者自行选择是否使用他们的服务，那么在这种情况下，我们也许可以说明一些关于业主的信息。我反对个人编辑者因其观点与自己不符而删除列表，但他们当然可以选择不添加它们。
–LPfi (talk) 2025年6月13日 12:28 (UTC)[回复]
我认为可能存在一系列问题，但某些类型的（例如）偏见与Wikivoyage:The traveller comes first不符。包含构成推荐，至少在有其他选择的情况下是如此。如果我们列出一个餐厅，那应该是游客受欢迎的。如果该餐厅的列表需要附带免责声明，例如“顺便说一句，只允许白人在这里用餐”或“业主认为看起来是犹太/穆斯林/黑人/同性恋/跨性别的人将被拒绝服务”，那么该餐厅根本不应包含在维基旅行中。列出的餐厅通常应向公众开放。
在另一方面，如果老板欣然接受所有顾客，但他私下属于一个种族主义组织，那么这实际上与旅行者的经历无关，所以我们不必提及。想要只光顾与自己政治/宗教/种族/性取向相同的人拥有的企业的旅行者应该去别处寻找这些信息。
介于两者之间的是事实信息，旅行者可能会以相反的方式解读。例如，如果纽约市的某个熟食店是犹太洁食，那么在描述中提及这一点是值得的。大多数旅行者不会在意。一些旅行者会喜欢它（无论是出于宗教原因，还是因为犹太洁食肉被认为比传统肉更符合道德）。一些旅行者会拒绝它。但知道它可能会吸引（或不吸引）不同的旅行者，与不同旅行者被禁止在该熟食店用餐是不同的。 WhatamIdoing (talk) 2025年6月13日 20:02 (UTC)[回复]
我看不出在描述一家餐厅的宗教信仰方面有何问题，只要它是以中立的方式进行的——例如，“XYZ餐厅是一家犹太洁食/清真/素食餐厅”。读者可以自己决定是否光顾该餐厅——毕竟维基旅行有许多关于各种礼拜场所的文章。 Martinvl (talk) 2025年6月13日 21:05 (UTC)[回复]
我认为总的来说，我们的意思是“XYZ是一家犹太洁食/清真/素食餐厅”，而不是“XYZ餐厅的老板是犹太人/穆斯林/素食者”。 WhatamIdoing (talk) 2025年6月14日 17:10 (UTC)[回复]
我同意。//shb (t | c | m) 2025年6月18日 06:56 (UTC)[回复]
  • 建议重写第一点（更改以粗体显示）
"尽可能避免关于在世人物的有争议内容，以示对人类尊严和个人隐私的尊重。发布与文章需求无关、琐碎、短暂或构成负面评价的个人信息是不公平的。例如，如果一家餐厅的老板宣传特定信念给顾客，那么就完全省略该列表，而不是写关于老板的信念。但如果该场所本身迎合某些信念和/或道德规范，那么在描述中以中立的方式添加这些信念/规范是合理的，或者甚至是被期望的——例如在描述中包含“犹太洁食/清真/素食”等词语。" Martinvl (talk) 2025年6月13日 21:14 (UTC)[回复]
  • 我建议扩展第二点（新增内容以粗体显示）
避免整篇文章都专注于在世人物，例如名人故居参观行程。以泰勒·斯威夫特的演唱会巡演为主题的行程是公平的；以她的故居为主题的文章则不公平。 然而，如果名人宣传其住所（例如唐纳德·特朗普的海湖庄园，或布伦海姆宫，即马尔伯勒公爵的住所），那么在文章中提及该住所是完全可以的，并且最好包含该住所的网址或文章。
Martinvl (讨论) 2025年6月13日 21:27 (UTC)[回复]
我认为所有关于信仰和政治的讨论都是有害的，而且不应成为我们的政策内容。此外，差评绝非不公平，我很难理解为什么有人会这么认为；这只是因为维基导游（除少数例外）选择不列出此类商家，而不是说明它们很差。我也看不到为什么我们需要添加一项政策，规定那些因种族、外貌或国籍等原因歧视他人的场所（例如在大流行初期拒绝东亚人进入的杜塞尔多夫一家历史悠久的餐厅）应该被删除，因为我们已经根据现有的政策这样做了。目前，我认为基于此线程中流传的草案，我们可能会批准一项比没有更好的新政策。 Ikan Kekek (讨论) 2025年6月13日 21:40 (UTC)[回复]
也许最好是尝试最小的增量。毕竟，如果政策真的需要扩大，以后要扩大它通常比以后缩短它要容易。 WhatamIdoing (讨论) 2025年6月14日 17:08 (UTC)[回复]
这是更短的版本
----
作为一般规则，维基旅行关注的是地点，而不是人物。偶尔，提供公平的描述会涉及提及特定人物。在这种情况下，这些原则适用于保护在世人物。
  • 尽可能避免关于在世人物的有争议内容，以示尊重人权和个人隐私。涉及在世公众人物的个别条目只要内容无争议即可接受。
  • 避免以在世人物为中心的整篇文章，例如关于观看名人私人住宅的行程。
----
我们也可以软化“尽可能”。总是“可能”避免提及任何人的名字，但这并非总是“合理”的。 WhatamIdoing (讨论) 2025年6月14日 17:14 (UTC)[回复]
关于美国的总统条目呢？我们不会避免描述在世总统的有争议事实，我们只是根据现有的维基导游：公正指南，就如何撰写他们的简介达成一致。我仍然不明白，至少增加你的第一个指导方针会有什么好处。而且，我们是在为不存在的问题创造解决方案吗？你能举出一个我们无法通过现有指南处理的、关于在世人物的、不必要地有争议事实的条目例子吗？ Ikan Kekek (讨论) 2025年6月17日 07:33 (UTC)[回复]
美国总统不是“以在世人物为中心的整篇文章”；它是一篇主要关于已故人物的文章，只提及了五位在世的美国总统（而且主要是以“公共博物馆”的方式，而不是“当前私人住宅”的方式）。因此，这可以被接受为“涉及在世公众人物的个别条目”，并且“尊重人权和个人隐私”。
现有需要解决的问题是：维基媒体基金会董事会曾表示，每个项目都需要有一份官方的书面BLP（关于在世人物）政策。他们大约在16年前就这么说了，所以我们有点落后了，但我们应该有东西。他们的决议鼓励“特别关注中立性原则”，所以我认为将几句话放在我们版本的“NPOV”政策中是合适的。我们甚至可以为此创建一个WV:BLP快捷方式，以便维基百科上的用户更容易找到。 WhatamIdoing (讨论) 2025年6月17日 17:16 (UTC)[回复]
我的问题不在于你第二个提议的条款，那个条款很好，而在于第一个。这正是我上次回复所讨论的。如果它规定，当必须提及在世人物时，我们必须公正，并就任何有争议的事项达成共识，我就会很高兴。 Ikan Kekek (讨论) 2025年6月17日 17:33 (UTC)[回复]
你认为一个旅行指南——尤其是那些不引用外部来源的指南——需要包含任何有争议或诽谤性的信息吗？ WhatamIdoing (讨论) 2025年6月18日 17:37 (UTC)[回复]
我已经给你一个例子了！那么，当我们公正地将国家描述为独裁政体时呢？我们有时会遇到用户反对并试图粉饰文章，在这种情况下，我们有维基导游：公正，而不是任何“有争议”的内容都是坏的并且必须避免的荒谬说法，而这会让他们得逞。维基导游是一个旅行指南，而不是一个力求中立的网站。我们明确没有NPOV政策，而是有一项要求公正的政策。 Ikan Kekek (讨论) 2025年6月18日 18:10 (UTC)[回复]
我同意我们可以公正地将一个国家描述为独裁政体。当我们描述一个在世的个人是独裁者，而这会引起争议（例如，在维基上产生争论和分歧）时，我们是否需要这样做？我刚刚检查了所有包含“a dictator”和“the dictator”字样的文章，它们都没有提及在世人物。
如果你之前的例子是“那么，关于美国的总统条目呢？”，我已经回答了这个问题。我看不出《美国总统》中有任何侵犯隐私的内容，也看不出其中任何在世人物有什么争议。内容并未获得竞选团队的普遍批准，但没有人真正争论或“争议”事实（例如，克林顿涉及性丑闻，或者特朗普在技术上是定罪的重罪犯）。 WhatamIdoing (讨论) 2025年6月20日 01:07 (UTC)[回复]
如果你最近没有幸遇到过特朗普的支持者，那你就很幸运了。美国有数千万铁杆特朗普支持者，他们不接受基本的科学事实，并将各种阴谋论当成真相。昨天，我在新罗谢尔遇到了一位出租车司机，他毫无缘由地开始谈论政治。他声称拜登四年前就已经患了癌症，“他们”掩盖了这件事，说化石燃料导致全球变暖的说法是“胡说八道”，如果去年民主党赢了，我们现在早就开电动车了，等等。因此，我非常反对你自信的断言，即关于特朗普、拜登、奥巴马等的陈述不是“有争议的”。我们需要从考虑中排除这个词，因为维基导游不能这样做。你还记得几年前有人花了两个星期或更长时间来粉饰关于古巴的描述，声称它实际上是一个民主国家，他们的选举真正自由公平，以及共产主义者从未在那里压迫过任何人吗？或者那些声称中国是民主国家，而美国（特朗普上台前）才是真正压迫性的（后者当然从来不是完全错误的，但对于旅行指南来说，这完全是题外话，也是纯粹的“以彼之道还施彼身”，什么都证明不了）。我们经历过各种政治动机的争议。这就是为什么我们的标准是维基导游：公正，而不是“维基导游/避免说任何可能引起争论的话”，因为“有争议”的意思是，或者在那些想利用旅行指南来宣泄私愤的人手中意味着什么，而不是改进旅行者的资源。 Ikan Kekek (讨论) 2025年6月20日 02:14 (UTC)[回复]
我同意Ikan的观点。我在种族隔离时期的南非长大。如果当时维基导游已经存在，我们会因为几乎所有场所都被法律要求实行种族歧视而删除南非的所有内容吗？我认为这样做不合适。但是，我认为包含一个关于如何应对国家种族政策的部分是合适的。 Martinvl (讨论) 2025年7月5日 22:22 (UTC)[回复]
相关：美国总统的几篇简短传记中的编辑器大量地使用了评论性语言 Purplebackpack89 2025年8月8日 15:03 (UTC)[回复]
你已经提出了编辑建议。请继续这样做。 Ikan Kekek (讨论) 2025年8月15日 17:26 (UTC)[回复]

至于当前的问题，我建议关注地点，而不是人物，更具体地说，是官方列出或指定的地点。住宅在人们去世后会被列入历史建筑登记，或者在在世者同意的情况下也被列入。官方图书馆和博物馆也属于这两种方式之一。并且有合理的论据认为，只需留下特朗普和他之前的四位总统，可能除了克林顿、布什和奥巴马图书馆。 Purplebackpack89 2025年8月8日 16:01 (UTC)[回复]

我的关于用维基导游教学的学术文章

草稿已完成（仍在进行小幅的校对和修改）。我将非常感谢您提出意见：https://docs.google.com/document/d/1mOR7w19Dd8CrElZcoeFkDxGCCOi12kff6qe1WQa8JCM/edit?tab=t.0 几天之内，我打算将其提交给学术期刊（有几家期刊涉及教育+旅游和酒店业领域）进行同行评审。感谢多年来在我学生身上的帮助（另外，请注意：新学期即将开始，预计从9月下旬开始，将有一批新学生编辑关于韩国和中国的条目；我将像往常一样提供一份他们选择的需要监视的条目列表）。 Piotrus (讨论) 2025年8月15日 11:19 (UTC)[回复]

哦，有意思，我会读一读。//shb (t | c | m) 2025年8月15日 11:21 (UTC)[回复]
刚读完——我没什么别的要说的，只是它研究得很充分，读起来很棒。干得好，Piotrus。//shb (t | c | m) 2025年8月15日 11:46 (UTC)[回复]
我同意。 Pashley (讨论) 2025年8月20日 17:20 (UTC)[回复]
我快速通读了文章。是否可以建议一个小小的补充——请求的文章页面是建议主题的另一个来源——学生可能会在那里找到他们从未想过的主题。例如，我看到那里有一个关于泰泽社区的请求。这是一个位于法国农村中心的修道院，吸引了许多年轻人，并以其所在地村庄命名。该讨论页的第一部分很有趣，因为它显示了关于文章范围的辩论（是否应包括村庄或仅社区？）。Martinvl (讨论) 2025年8月15日 14:18 (UTC)[回复]
@Martinvl 谢谢——我不知道有那个页面，我很快就会把它添加到相关的资源中！ Piotrus (讨论) 2025年8月15日 18:29 (UTC)[回复]

Piotrus，感谢你把这个链接发给我们！我正在阅读这篇论文，目前为止还不错。我想知道你是否需要校对建议，比如消除以下句子中的分号：“下一节将回顾学术界关于维基百科写作教学益处的共识，这项作业是在十多年前开发的，此后已被数千名教育工作者使用（Vetter, McDowell & Stewart, 2019; Konieczny 2021; Evenstein Sigalov & Konieczny, 2025）；作为讨论如何在维基百科和维基导游网站上将此类活动应用于旅游和酒店业背景的讨论的基础。”也许我应该停止阅读，直到你告诉我，因为我看到了其他几个地方我建议进行小幅编辑，如果我通读整篇文章，我就会忘记所有这些地方，而且我不想再读一遍来校对。到目前为止，它写得相当好，没有大的建议修改，但我只看到第二部分。 Ikan Kekek (讨论) 2025年8月15日 17:25 (UTC)[回复]

@Ikan Kekek 无论如何，所有建议，无论是小的还是大的，都欢迎。 Piotrus (讨论) 2025年8月15日 18:28 (UTC)[回复]
通知 @MarianaSenkiv，因为她也使用维基导游（乌克兰语）来教旅游专业的学生。Piotrus，你可能见过她，因为你们都参加了维基百科会议卡托维兹。 OhanaUnited讨论页 2025年8月20日 12:39 (UTC)[回复]
我曾为期刊论文担任过编辑。在上述段落中，我会删除分号并将“adopted”改为“adapted”。 Pashley (讨论) 2025年8月20日 16:23 (UTC)[回复]
我发现了一个实质性问题，在我看来是一个错误，但也可以说只是过于简化了。
维基导游是……它于2006年作为商业Wikitravel网站的一个志愿者驱动的分叉启动，……
Wikitravel始于2003年，并于2006年商业化。德语和意大利语的Wikivoyage也大约在那时开始，但英语WV的分叉并成为维基媒体网站大约发生在2012年；详情请参阅Wikivoyage:Wikivoyage_and_Wikitravel。 Pashley (讨论) 2025年8月20日 16:33 (UTC)[回复]
干得好，Pashley。//shb (t | c | m) 2025年8月20日 21:14 (UTC)[回复]
嗯，我认为上面的日期是正确的。我很确定德语和意大利语的维基在2006年就分叉了，所以可以说，那就是维基导游首次由志愿者分叉的时候。 --来自 Selfie City (讨论) (贡献) 2025年8月21日 00:06 (UTC)[回复]
我认为这没有争议。那绝对是维基导游开始的时候。 Ikan Kekek (讨论) 2025年8月21日 00:58 (UTC)[回复]
@Pashley @SHB2000 嗯，我的总结是过于简化了，因为维基旅行/维基导游的详细历史实际上是琐碎的，对我们来说并不太相关。关于维基导游的维基百科文章说：“该项目始于2006年9月，当时德语版和意大利语版的编辑者决定将他们的编辑活动和当前内容转移到一个新网站……”然后英语版大约在2012/2013年跟进。信息框显示：“第一个版本（德语）2006年12月10日。英语版本2013年1月15日”。所以我不确定这里有什么问题？但我乐于接受改写建议。 Piotrus (讨论) 2025年8月21日 09:19 (UTC)[回复]

我什么时候能翻译文章？

已经一周（可能两周）了，我还没有将英语文章翻译成世界语的能力。我什么时候能得到？ HtialilwW (讨论) 2025年8月23日 02:43 (UTC)[回复]

有人告诉你会在几周内获得这项能力吗？ Ikan Kekek (讨论) 2025年8月23日 02:49 (UTC)[回复]
不。我只是假设，但我什么时候才能得到它？ HtialilwW (讨论) 2025年8月23日 02:51 (UTC)[回复]
如果你想翻译文章，你必须自己做。 Ikan Kekek (讨论) 2025年8月23日 03:07 (UTC)[回复]
虽然希望我们有，但我们没有像维基百科那样官方的翻译工具。这个网站上的Special:Translate对任何人都不起作用。//shb (t | c | m) 2025年8月23日 03:53 (UTC)[回复]
但是当我点击右上角的‘语言’时，上面有一些语言。你如何连接你的文章？ HtialilwW (讨论) 2025年8月23日 04:28 (UTC)[回复]
这是在Wikidata上完成的。//shb (t | c | m) 2025年8月23日 04:30 (UTC)[回复]
如何？ HtialilwW (讨论) 2025年8月23日 04:31 (UTC)[回复]
  1. 在一个X项目上创建一个文章（例如，最近在这里创建了鞋类）。
  2. 前往相关的Wikidata项目（如果存在）（在本例中为d:Q161928）
  3. 编辑相关的网站链接，通常在页面右侧（在本例中为维基导游）
  4. 选择合适的语言代码（在本例中为en，以及对于用世界语书写的任何内容，为eo）
  5. 一旦您添加了新撰写文章的名称，它就会保存在Wikidata上，并显示在所有相关的维基媒体基金会项目上。
—Justin (koavf)❤T☮C☺M☯ 2025年8月23日 04:51 (UTC)[回复]
谢谢。 HtialilwW (讨论) 2025年8月23日 05:30 (UTC)[回复]
@Amire80，你的团队是否考虑过启用维基导游的内容翻译功能？ WhatamIdoing (讨论) 2025年8月23日 16:52 (UTC)[回复]
稍微看了一下，但从未优先处理。理论上是可能的，但需要工作。最好在mw:Talk:Content translation上询问。 Amir E. Aharoni (讨论) 2025年9月6日 15:10 (UTC)[回复]
大家，我们对此想法有什么看法？我们是否希望在维基导游之间启用翻译工具？（注意：启用机器翻译，如谷歌翻译，是另一个问题。我的问题是关于翻译一个{{Sleep}}模板到另一个语言的匹配模板的软件。） WhatamIdoing (讨论) 2025年9月6日 19:51 (UTC)[回复]
明确地说，重点是翻译空白模板的机器翻译？ Ikan Kekek (讨论) 2025年9月6日 20:01 (UTC)[回复]

临时账户即将推出

您好，我们是维基媒体基金会产品安全与完整性团队。我们想宣布，我们计划在9月1日当周为本维基启用临时账户。

临时账户已成功在30个维基上启用，包括德语、日语和法语等许多大型维基。它们带来的改变对未登录的编辑者尤其重要，因为该功能旨在保护他们。但它也与社群成员相关，例如导师、巡查员和管理员——任何参与恢复编辑、封禁用户或以其他方式与未登录编辑者互动，以维护维基安全和准确性的人。

我们为什么要构建临时账户

我们的维基默认应该对未登录的编辑者更安全。临时账户允许人们在不创建账户的情况下继续编辑维基，同时避免公开地将他们的编辑与其IP地址关联起来。我们认为这符合我们未登录编辑者的最大利益，他们为维基做出了宝贵的贡献，并且以后可能会创建账户并发展我们的编辑者、管理员和其他角色的社群。尽管维基确实会警告未登录的编辑者，他们的IP地址将与其编辑相关联，但许多人可能不理解IP地址是什么，或者它可能以他们意想不到的方式被用来将他们与其他关于他们的信息联系起来。

此外，我们的审核软件和工具在识别用户和活动模式时过于依赖网络来源（IP地址），尤其是在IP地址作为标识符变得越来越不稳定的时候。临时账户允许与未登录编辑者进行更精确的互动，包括更精确的封禁，并且可以帮助限制我们无意中封禁使用相同IP地址的善意用户，而实际上是由于他们与恶意用户共享IP地址。

临时账户如何运作

任何时候，当一个未登录用户在本维基上发布编辑时，都会在用户的浏览器中设置一个cookie，并自动创建一个与此cookie绑定的临时账户。该账户的名称遵循模式：~2025-12345-67（一个波浪号、当前年份、一个数字）。在“最近更改”或页面历史等页面上，将显示此名称。cookie将在创建后90天过期。只要cookie存在，从此设备进行的所有编辑都将归属于此临时账户。除非用户清除cookie或使用不同的设备或Web浏览器，否则它将是同一个账户。在每次编辑发生后90天内，将存储当时使用的IP地址的记录。但是，只有一些已登录用户才能看到它。

这对不同用户群体意味着什么？

对于未登录的编辑者

  • 这增加了隐私：目前，如果您不使用注册账户进行编辑，那么每个人都可以看到您编辑的IP地址，即使在90天后也是如此。在本维基上，这种情况将不再发生。
  • 如果您在过去90天内使用临时账户从不同地点进行编辑（例如在家和咖啡店），那么所有这些地点的编辑历史和IP地址现在将记录在一起，归属于同一个临时账户。符合相关要求的用户将能够查看此数据。如果这对您造成任何个人安全问题，请联系talktohumanrights at wikimedia.org获取建议。

对于与未登录编辑者互动的社群成员

  • 临时账户与设备唯一关联。相比之下，IP地址可以与不同的设备和人员共享（例如，学校或工作场所的不同人员可能拥有相同的IP地址）。
  • 与目前情况相比，可以更安全地假设临时用户的讨论页只属于一个人，并且留在上面的消息将由他们阅读。正如您在截图中所见，临时账户用户将收到通知。您也可以感谢他们的编辑，在讨论中提及他们，并邀请他们更积极地参与社群。

对于使用IP地址数据来审核和维护维基的用户

  • 对于巡查员来说，他们追踪持续骚扰者，调查违反政策的行为等：符合要求的用户将能够显示临时用户的IP地址，以及从特定IP地址或IP范围进行的所有临时账户贡献（Special:IPContributions）。他们还将能够通过IP Info功能获取有关IP地址的有用信息。许多其他软件已被构建或调整以适应临时账户，包括AbuseFilter、全局封禁、全球用户贡献等。（有关志愿者开发人员更新工具代码的信息，请参阅消息的最后部分。）
  • 对于封禁未登录编辑者的管理员:
    • 可以通过简单地封禁其临时账户来封禁许多骚扰者。如果管理员选择了自动封禁选项，被封禁的人将无法快速创建新的临时账户。
    • 仍然可以封禁IP地址或IP范围。
  • 临时账户不会追溯应用于部署之前的贡献。在Special:Contributions上，您将能够看到现有的IP用户贡献，但不能看到同一IP地址上由临时账户进行的新贡献。相反，您应该使用Special:IPContributions来完成此操作。

我们对您的要求，以及后续步骤

若想了解更多关于该项目的信息，请参阅我们的常见问题解答——你可以在那里找到许多有用的答案。你也可以查看更新（我们刚刚发布了一篇）并订阅我们的新通讯。如果你想在站外与我（Szymon）交流，可以在Discord和Telegram上找到我。谢谢！

NKohli (WMF), SGrabarczuk (WMF) 21:37, 2025年8月26日 (UTC)[回复]

……并且已经部署。//shb (t | c | m) 13:56, 2025年9月2日 (UTC)[回复]
我已在该类账户的讨论页上发布了我的第一个拉客警告。它们主要是为了保护拉客者和破坏者吗？Ikan Kekek (talk) 15:39, 2025年9月2日 (UTC)[回复]
我在其他小型维基（例如srwiki）上的经验是，临时账户可以阻止IP地址的跳变，因为这据称与设备相关而不是与IP地址相关——但这使得处理此类滥用变得更加困难，尤其是在涉及范围屏蔽时，或者对于那些不符合查看临时账户条件（6个月和500次编辑；尽管我猜我现在可以绕过这个限制，因为我被授予了全局临时账户IP查看器权限？）。//shb (t | c | m) 23:24, 2025年9月2日 (UTC)[回复]
我当时也担心这一点。但我看到了对维基社区的好处。
"Cookie将在创建后的90天内过期。只要它存在，从该设备进行的所有编辑都将归因于该临时账户。即使IP地址发生变化，它也会是同一个账户，除非用户清除其cookies或使用不同的设备或Web浏览器。"
"通过屏蔽许多临时账户，就可以屏蔽许多滥用者。如果管理员选择了自动屏蔽选项，被屏蔽者将无法快速创建新的临时账户。"
此外，“符合要求的用户将能够显示临时用户的IP地址，以及临时账户从特定IP地址或范围（Special:IPContributions）所做的所有贡献。”这意味着，你将仍然拥有与现在一样的访问权限。Ground Zero (talk) 15:59, 2025年9月2日 (UTC)[回复]
谢谢。我想我们很快就要习惯如何自动屏蔽了……Ikan Kekek (talk) 16:04, 2025年9月2日 (UTC)[回复]
我已尝试屏蔽一名通过临时账户识别出的长期滥用者IP。请查看是否一切都已正确完成。OhanaUnitedTalk page 21:33, 2025年9月8日 (UTC)[回复]

在城市中轻松找到“顶级目的地”

序言：我明白，每个旅行者都有不同的优先事项。除此之外，大多数城市肯定都有主要的景点，然后是“支线任务”，供普通旅行者选择。

例如，以埃斯泰尔戈姆为例。如果你在那里待一周，你大概可以全部游览完。但对于1-2天来说，大多数人只会考虑例如大教堂、1-2个博物馆、城堡和水上乐园。我们能否在列表添加一个“顶级精选”字段，并设置例如每个条目和类型（游览/活动）限制10个？也许这样的列表可以有更生动的标记或其他什么。

我问的原因和往常一样。又一次假期/公路旅行来了，我非常非常努力地尝试使用WV来规划行程，但就是无法做到。我不得不使用谷歌地图搜索景点，阅读评论，在其他地方（我常用的网站）整理行程路线，然后查阅WV获取一些最后的提示。我正在考虑为WV构建一个JS工具，可以收集这些行程的列表——但除非一个人至少能大致评估某个区域的主要景点在哪里，否则甚至开始都是徒劳的。

另一方面，如果我能打开匈牙利页面，并在地图上看到所有条目的前10个景点组合，那至少能让我对哪些地区最有趣有一个大致的了解……

我是否是唯一遇到这个问题的人？-- andree 18:42, 2025年9月2日 (UTC)[回复]

在有强烈共识认为哪些是顶级景点的情况下，我们可以组织“游览”部分，例如锡耶纳#游览。否则，在游览部分开头进行总结即可。无需对列表模板进行任何花哨的颜色或格式更改。Ikan Kekek (talk) 18:50, 2025年9月2日 (UTC)[回复]
好的，假设我们要花一周或两周时间游览托斯卡纳。你会如何用WV来规划行程？摘要文字不错，但它只在你被送到某个特定城市并需要一些介绍时（例如通过某个有组织的旅游团）才有帮助——对于大型/自助规划则完全没有帮助。例如，蒙特普尔恰诺的景点看起来非常普通，在公路旅行中可能不值得一去（没有主要景点）。当然，如果你在该地区待几天，那又是另一回事了。但以WV目前的结构，你如何找出这一点？通过阅读所有文章？我可以打开tripadvisor/google/wanderlog/...，效率要高100倍。-- andree 18:55, 2025年9月2日 (UTC)[回复]
托斯卡纳有很多很棒的方式可以花一周或两周时间，所以没有一个放之四海而皆准的“托斯卡纳一周游”指南是合理的，我们能做的最合理的事情就是在托斯卡纳#游览和托斯卡纳#活动部分提及一些亮点，然后让读者自行选择首次访问的优先事项（然后是第二次、第三次、第四次，如果他们能去的话……）。当然，他们也可以选择参加预定的旅游团，但我们不在此指导他们。说了这么多，如果你认为《托斯卡纳》文章中的任何部分缺少应该被总结的重要信息，那就请加上吧！如果你认为其中任何部分可能存在争议，请在托斯卡纳讨论页上提出建议。另外，我现在没有时间查看Tripadvisor链接，但它比Wikivoyage好在哪里？我们该如何最好地解决这个问题？Ikan Kekek (talk) 00:40, 2025年9月3日 (UTC)[回复]
因此，第一句话…… :) 另外，托斯卡纳只是个例子。我可能是一个只有5天时间待在拉姆施泰因附近的美国士兵，一个从纽约到杰克逊维尔出差的推销员，一个想在中美洲待一个月的人，等等……你说你不想做“一刀切”的事情（我同意），但然后你建议在区域概览中这样做。这些只能覆盖特定区域，并且很可能不会告知边界另一边最好的东西。
在过去的10-15年里，我进行了各种为期几周/3000公里的公路旅行，而WV在大多数时候都无法帮助我制定一个大致的计划。城市指南本身通常不错（即使遗漏了一些地方，但这对我来说没关系，我总是在旅行后努力填补这些空白），但我期望一个数字旅行指南也能帮助我把握大局……
或者，我们仍然只打算与传统的印刷旅行指南竞争吗？-- andree 06:05, 2025年9月3日 (UTC)[回复]
“下一个”目的地（有时是“附近”）是指指南未涵盖的地区，而指南永远不会涵盖所有内容。Ikan Kekek (talk) 06:13, 2025年9月3日 (UTC)[回复]
我认为导言和“了解”部分对此也有用。WhatamIdoing (talk) 03:09, 2025年9月3日 (UTC)[回复]
同意。Ikan Kekek (talk) 03:16, 2025年9月3日 (UTC)[回复]
我不会反对创建某种图标来表示第一次访问者应该“必看”的地方，以及有哪些额外的可以去游览的地方——这是一个微妙的变化，但潜力巨大。虽然我知道摘要文字可以运作良好，但根据我的经验，仅有摘要文字并不能与其他旅行指南相媲美（我主要使用expedia或Google）。//shb (t | c | m) 06:00, 2025年9月3日 (UTC)[回复]
摘要文字不错，一旦你身处相应的城市。我的问题在于，我无法阅读200篇这样的文章，即使它们都有顶级的概述……我宁愿使用Google地图查看某个区域，搜索“景点”，然后选择那些有100多条评论的，例如。但我认为WV可以通过添加这样的“必看”标签轻松做到这一点。-- andree 06:10, 2025年9月3日 (UTC)[回复]
我在{{mustsee}}做了一些模型，并在堪培拉/南堪培拉，基亚玛和巴德鲁国家公园实施了它——你觉得怎么样？//shb (t | c | m) 06:12, 2025年9月3日 (UTC)[回复]
原则上可以，但就我的用例而言，除非列表模板有这样一个参数（例如 {{see|mustsee|name=xyz}}），否则它才有用。这样就可以创建一个动态地图，显示某个任意区域内带有此类内容的列表。
另一方面，添加这个需要很多工作，而且可能会引起社区的摩擦……
我们可以做类似的事情，如果我们滥用维基百科搜索，例如按照维基百科搜索结果的数量排序（廉价版的谷歌鸽子排名替代方案；因为如果我想使用它们的数字，我会很快被谷歌封禁——而且这很可能违反了它们的T&C :)）。例如，对于埃斯泰尔戈姆，“埃斯泰尔戈姆大教堂”得到51个结果，“基督教博物馆”——13个，“博蒂安桥”——2个，“耶稣会教区教堂”——1个……我想这可以奏效，而且我们不需要任何外部的东西，甚至不需要维基数据（但我们需要标记 :)）。-- andree 06:35, 2025年9月3日 (UTC)[回复]
这对于埃斯泰尔戈姆来说也许可行，但对于纽约、纽约、柏林、巴黎、罗马或华盛顿特区这样的城市，结果会怎样呢？这些城市人们对“最佳”景点和活动的看法存在相当大的分歧，这取决于旅行者的偏好和兴趣。Ikan Kekek (talk) 06:45, 2025年9月3日 (UTC)[回复]
据我所知，我们都对这种标记对小城市、公园、较小的乡村地区——或者任何不是大城市的地方——有帮助，那里的最佳景点/活动更加主观。//shb (t | c | m) 06:49, 2025年9月3日 (UTC)[回复]
是的，一般来说，当一个城市有几个明显很棒的景点，而且活动不多时，会更容易些。但为什么锡耶纳#游览模式对它们不起作用呢？Ikan Kekek (talk) 06:56, 2025年9月3日 (UTC)[回复]
嗯，对于大城市来说呢？我怀疑。请参阅我在这条讨论串其他地方关于像柏林、罗马、纽约等城市的评论。//shb (t | c | m) 07:00, 2025年9月3日 (UTC)[回复]
对于大城市？我不这么认为。请参考我在本讨论串其他地方关于柏林、罗马、纽约等城市的评论。Ikan Kekek (talk) 07:06, 2025年9月3日 (UTC)[回复]
确实如此，一旦你决定去锡耶纳，我认为它是一个完美的指南（第一眼来看），我可能只会用谷歌来搜索食物和可能遗漏的新场所。但这并不是本主题的重点…… -- andree 07:05, 2025年9月3日 (UTC)[回复]
我同意，至少在美国，谷歌地图在寻找吃饭的地方方面通常最有用。我怀念过去可以在Chowhound等美食论坛上获得更可靠信息的那段日子。Ikan Kekek (talk) 07:17, 2025年9月3日 (UTC)[回复]
是的，但这与埃斯泰尔戈姆本身无关。但如果你进行一次旅行，从埃斯泰尔戈姆到瑙吉考尼日，对这个国家了解不多，我认为如果你能收集我们拥有的相关文章，选择那些排名靠前的10%的列表，那会很好。然后你就会知道在塞克什白堡停留是有意义的，但可能不一定需要去瓦尔帕洛塔…… -- andree 06:56, 2025年9月3日 (UTC)[回复]
这听起来像是在区域指南或“前往下一站”部分中要解决的问题。Ikan Kekek (talk) 06:57, 2025年9月3日 (UTC)[回复]
（编辑冲突）我曾想过创建一个特殊的类别，在一个动态地图上列出它们，但我知道这会遭到社区的强烈反对——这就是为什么我提出了一个小标记，它对大多数城市来说都易于实现，而且争议要小得多，同时又能获得大部分类似的好处。//shb (t | c | m) 06:45, 2025年9月3日 (UTC)[回复]
在摘要中，景点应该适当加粗。请参考芝加哥#游览的例子。我反对使用特殊模板来表示所谓的“必看景点”。这忽略了就其达成一致的步骤，我不知道我们是否真的想在每个文章的讨论页上花时间争论这一点，但让人们单方面决定他们将 dictation 答案也是不合理的。我们以前就这个话题进行过多次讨论，虽然在某些地方有明确的共识，但在许多其他地方则没有。举一个例子，如果你考虑纽约市，许多未曾到过的人认为时代广场是必看的，而纽约人会勉强承认看一次是合理的，但这是否使其成为前五的景点？大都会博物馆是艺术博物馆爱好者的“必去之地”（尽管它也有很棒的乐器和服装展区），但如果你不是，那就不是。布鲁克林大桥可能是大多数人都会同意的，但即使在这种情况下，有些人也会反对桥上行人的数量，或者仅仅是体力不足以走1.1英里。大多数纽约人以及许多游客会说乘坐斯塔滕岛渡轮是必做的，但一个拥有YouTube频道的导游声称这是一笔糟糕的交易，尽管它是免费的，而且你可以通过花很多钱喝香槟，然后乘坐一艘小船进行游览，看到更多自由女神像（我认为她大错特错了，但那些昂贵的旅游确实有顾客），但更严重的是，有些人宁愿不花时间往返纽约湾，而更愿意多走走，去俱乐部、酒吧或其他地方。等等，等等。巴黎也是类似的情况：埃菲尔铁塔是标志性的，但不必参观就能看到；卢浮宫令人难以置信，但如果一个人对艺术不太感兴趣，可能会感到厌倦；但巴黎有太多东西可看可做，对大多数人来说都是一个很棒的游览地点。Ikan Kekek (talk) 06:25, 2025年9月3日 (UTC)[回复]
我的意思是，这些都是Google、Tripadvisor、Expedia、Lonely Planet以及所有其他主要旅行指南都必须处理的问题，但他们处理得很好。我认识到这里的主要区别在于那些网站不是维基百科，但它们确实设法做得很好，而且我们没有理由不能这样做（可能需要就大城市进行一些讨论，但仅此而已）。有一个标记或某种特殊列表并不一定意味着读者缺乏批判性思维——他们当然可以自己决定那是否适合他们。这应该更多地被视为一个新功能，读者可以自行使用，但它并不取代其他一切。
也许是我，但我有点担心Wikivoyage会失去相关性，如果我们没有某种独特的特征，而只是坚持使用文章摘要，因为我这个年龄的人没有人愿意在决定去那里之前阅读长篇的文字和废话（这也可能解释了为什么我不太关心生动的旅行写作，不像这里的大多数人），而我们需要一些视觉的东西来保持相关性。//shb (t | c | m) 06:42, 2025年9月3日 (UTC)[回复]
如果你想尝试为每个城市、地区、州/省，甚至是区争论前5或10个景点，最好现在就开始，因为这需要很长时间。那些其他网站是商业化的，它们想推广任何能帮助它们卖得最多的东西。本维基的历史是，它不专注于那些满足于预订行程并告诉你去哪里的典型旅行者。Ikan Kekek (talk) 06:47, 2025年9月3日 (UTC)[回复]
它们可能是商业化的，但即使像我这样的人，虽然在很多方面都在为本网站辩护，但经常诉诸Google/Lonely Planet，因为它们比我们更好地突出了关键景点，这是它们做得比我们好的地方，也是我们应该努力改进的地方。我并不否认在大城市实施这一点会有问题，但我想让这个网站真正被人们阅读，而且我们没有理由不能为小城市和公园这样做。//shb (t | c | m) 06:55, 2025年9月3日 (UTC)[回复]
顺便说一句，我在这里的大部分评论都是基于轶事，既有我自己的经验，也有我 IRL（很多人和我年龄差不多）经常旅行的朋友的经验。你可以自行判断。shb (t | c | m) 06:56, 2025年9月3日 (UTC)[回复]
我查看Tripadvisor和Wikivoyage来寻找城市中的景点和活动。我对Tripadvisor最大的抱怨是，它们显示了城市以外很远的地方的景点和活动，除非你开车，否则不太可能去看或做，而且你必须花时间查看它们的结果，才能发现它们认为城市本身没有任何东西可以看或做。我最大的问题是Wikivoyage，很多地方没有覆盖，或者覆盖不足，但这取决于具体的地方。Ikan Kekek (talk) 07:00, 2025年9月3日 (UTC)[回复]
我认为Tripadvisor上的排名会有帮助，尽管我并不总是同意，但我认为这些是Wikivoyage的补充，而且我并不介意Wikivoyage与众不同。我承认，如果这能帮助更多读者，我们可以尝试做更多类似“前10名”的列表，我们可以做，但对于纽约这样的城市，这可能相当于前5名艺术博物馆，前5名观景点，前5名风景优美的步道（这些通常是社区，而不是确切的行程），前5名公园（我们可以在那个方面做得更多），等等。Ikan Kekek (talk) 07:03, 2025年9月3日 (UTC)[回复]
是的，我也不喜欢Tripadvisor的原因是这样——我确实有车，也能开车，但我经常乘坐公共交通工具去偏远地区进行现场考察，以节省金钱，有时还会看看城市。通常我也不介意独自步行12-15公里（有时甚至在110公里/小时的高速公路旁边，没有保护），但Tripadvisor把事情推向了另一个层面。//shb (t | c | m) 07:05, 2025年9月3日 (UTC)[回复]
+1……我只是想让社区付出的努力得以体现，并被人们使用。正如shb在上面写的，大多数人都不喜欢在决定去那里之前阅读大段的文字 :) -- andree 07:02, 2025年9月3日 (UTC)[回复]
你认为加粗无济于事吗？你能做一个你想要的样子的模型吗？如果你想要比加粗更清晰的东西，难道不是列表吗？Ikan Kekek (talk) 07:05, 2025年9月3日 (UTC)[回复]
我同意你的所有观点，但我的问题在于别处。我去了布达佩斯->克罗地亚，想在路上花几天时间了解历史、自然景点等。如果需要，我可以绕行50公里，在申根区内，甚至去另一个国家。
Globetrotter19 (talk · contribs), City-busz (talk · contribs) 以及其他几位朋友们在描述匈牙利的一切方面都做得非常出色。但你知道，我不想在每个5000人口的小镇上看到(+/- 相同)的巴洛克式教堂…… :) 我想参观例如哈布斯堡王朝的某个夏宫、独特的建筑、一些自然景点、也许还有一些儿童游乐场。那种行程……最终我成功了，但不是因为WV，我认为这很可惜，因为大部分内容（除了某种“优先事项”和地图）都在那里…… -- andree 06:48, 2025年9月3日 (UTC)[回复]
我不认为任何基于“必看景点”的行程会推荐游乐场，尽管有些游乐场很有趣（例如，我认为阿姆斯特丹Vondelpark的一个游乐场很有趣，并且我曾以为我在阿姆斯特丹/南区的Vondelpark列表里添加了描述，但我没找到，所以也许我没添加）。然而，独特的建筑和令人惊叹的自然景观应该在任何好的指南中得到强调，这显然也包括Wikivoyage。Ikan Kekek (talk) 06:54, 2025年9月3日 (UTC)[回复]
我正在思考更多：你真正需要的是米其林以前在其纸质绿色指南中拥有的那种地图，并且允许在线免费访问，这些地图显示了哪些城市是3星（值得一去）、2星（值得绕道）和1星（有趣），或者无星，同样也包括城市内外景点。那非常有用，部分原因是，尽管米其林在寻找有趣的事物方面存在某种偏见，但我发现他们的判断非常可靠，他们认为有价值的东西通常确实如此。所以，是的，我非常理解这种地图的用处。但对我们来说，要创建自己的地图将是极其耗费工作的，而且需要进行大量辩论（依赖于基于维基百科文章搜索的某种计算或其他任何东西，我们都不想用它来替代我们自己的判断，否则基于社区的指南还有什么意义呢？）。Ikan Kekek (talk) 07:14, 2025年9月3日 (UTC)[回复]
如果人们想这样做，我愿意参与讨论。如果你想的话，可以在纽约讨论页上开始一个话题。我们以前尝试过，但我们可以再试一次……Ikan Kekek (talk) 07:19, 2025年9月3日 (UTC)[回复]
那种排名听起来很有用，它可以帮助我们以某种方式对我们的文章进行分类/排序……基于维基百科搜索的排名只是一个比什么都不做要好的可能性（我认为） :) -- andree 07:28, 2025年9月3日 (UTC)[回复]
那会很有趣。//shb (t | c | m) 08:37, 2025年9月3日 (UTC)[回复]
我们必须决定的是，是否要像米其林曾经（并且可能仍然在其纸质绿色指南中）那样，尝试制定一个绝对的全球星级评级标准，还是按地区进行评级，并且还要决定哪些城市（等）值得三星、二星、一星或无星评级，或者我们想使用哪些其他区分方式。一个需要考虑的点是，据我回忆，在 20 世纪 90 年代，我仍然使用纸质指南时，米其林指南在罗马有许多三星和二星景点，但有一打的教堂被评为一星，因为例如，即使是罗马一些相当不起眼的教堂，也可能拥有知名艺术家创作的精美艺术品，并且是漂亮的建筑，因此它们在意大利的小城市中很容易成为顶级景点。我严重怀疑纽约州哈德逊市的新哥特式圣玛丽教堂会获得米其林的任何星级，因为虽然它是一座非常漂亮的建筑，在你游览那个风景如画的小城市时可能会偶然发现，并且有精美的彩色玻璃窗，但它根本无法与罗马的教堂相比，例如圣安德烈亚德拉瓦莱教堂，那是一座我以前住在附近 Via Arenula 的酒店时很喜欢参观的教区教堂。然而，我认为这是哈德逊市的一个重要景点，尽管除了维基旅游之外，我看到的任何指南都没有提及它——因为是我列出的。 Ikan Kekek （讨论） 2025年9月3日 08:56 (UTC)[回复]
嗯，这正是问题的关键。如果我在纽约市，我可能不会花 2x2 小时去看那一座教堂——但也许如果我从纽约市去奥尔巴尼，并且可以在那里短暂停留，那倒是说得通。另一方面，现在的问题是，拟议的排名是否能在此处有所帮助。我猜整个道路上都会充斥着一星城市，所以你又会回到点击每个城市并逐一阅读…… -- andree 2025年9月3日 09:39 (UTC)[回复]
我认为，如果我们想复制全球星级评级衡量标准，它最好应该是相对区域而言的。一个拥有 500 万人口的都市区的教堂可能对大多数旅行者来说不是那么有趣（并且可能得零星），但一个拥有 500 人口的小镇的教堂可能就是该镇最显著的景点了（并且可能得二星）。现在我不熟悉米其林曾经的标准，所以请把我的星级评级当作一个例子，但我的主要观点是避免一刀切的标准。//shb (t | c | m) 2025年9月3日 09:52 (UTC)[回复]
如果我们效仿米其林，最多只会有一两个一星城市。大多数将不会有星级。我希望我能在网上找到有关它们的信息供大家链接，除了在w:米其林指南#绿色指南中的简短段落外，但在网上搜索“米其林星级景点列表”等内容，没有找到其他有用的信息。但值得看看那段话。
《米其林绿色指南》会评论和评级餐厅以外的景点。有一本针对整个法国的《绿色指南》，以及一本针对法国内部十个地区的更详细的指南。其他《绿色指南》则涵盖了法国以外的许多国家、地区和城市。《绿色指南》的许多版本都有多种语言。它们包含背景信息和一个描述景点的按字母顺序排列的部分。与《红色指南》一样，它们使用三星系统推荐景点，从“值得一游”到“值得绕道”和“有趣”。
我相信我很久以前就处理掉了我 90 年代的老《绿色指南》，但米其林的严苛标准体现在，即使托斯卡纳的大多数村庄没有获得任何星级，尽管它们中的某个地方（很可能是大教堂或其他教堂）本身就获得了一颗星，而且其中绝大多数都非常漂亮。我相信我记得阿斯恰诺的情况就是如此。当然，佛罗伦萨和锡耶纳获得了三星，但我认为阿雷佐最多只获得了二星，而科尔托纳只获得了一星，因为尽管那里有几处很棒的景点（尤其是它的小大教堂，作为一个景点获得了至少二星），但除此之外就只剩下了美景，而许多山村都有美景（我认为基于这一点，这是公平的评级）。我很确定圣吉米尼亚诺获得了三星，因为除了它优越的地理位置之外，作为一个如此小的城镇，它还有令人难以置信的景点。
如果有人拥有美国地区的《绿色指南》那就太好了，但按照那个标准，如果我想起我在普渡溪以北的哈德逊河谷游览过的地方，金斯顿可能会获得一星或两星，哈德逊也是如此（可能是一星，尽管奥拉纳作为一个景点至少会获得二星），特洛伊也是。萨拉托加可能会获得二星，科霍斯可能会获得一星，奥尔巴尼会获得一星，因为它是一个州府，有一个有趣的区域，可能还有一些我没去过的不错的博物馆，我想就这些了。莱茵贝克没有可能获得星级，尽管那里有一些教堂和墓地有有趣的往事，而我从未有足够的动力去写下来，而且那些多多少少令人愉快和风景如画的村庄都没有星级。新帕尔茨会获得一星，但它更靠南。哈德逊沿岸威彻斯特的一些郊区可能会获得一星，但前提是那里不仅仅有景色，所以扬克斯为了哈德逊河博物馆和那个我忘记名字的花园，也许还有特里尔镇为了那个传说（米其林的人喜欢这种东西）。不太确定还有什么。 Ikan Kekek （讨论） 2025年9月3日 15:19 (UTC)[回复]
我想知道这有多少是关于突出一个大型目的地内的最佳景点，有多少是关于在你已经在 X 和 Y 之间开车时，说明哪些城市值得停留。我认为行程可能是一个更好的模型：去这里看这个，然后去那里看那个，如果你对这个感兴趣，就停留在这里…… WhatamIdoing （讨论） 2025年9月3日 19:50 (UTC)[回复]
我在 2002 年法国公路旅行时使用过米其林绿色指南，以帮助我自发地决定是否走高速公路旁的支线。我哥哥开车，我坐在他旁边，看着米其林地图，并给他读了关于那些离出口不远的地方的指南。结果，除了我们在旅行前计划的其他地方之外，我们还参观了 Semur、Saumur 和 Le Mans。米其林对城市和景点的星级评级很有帮助，但它们的描述也很有用。
我绝对认为可以使用维基旅游以同样的方式（我还没有尝试过——自从我父亲生病和父母去世后，就没有家庭公路旅行了），但这个网站覆盖范围的不一致性，由于这个群体的成员选择写哪些地方，造成了一种不可避免的标准化缺乏。考虑到维基百科固有的缺点，它们能做到如此之好真是令人惊叹！ Ikan Kekek （讨论） 2025年9月3日 21:03 (UTC)[回复]
对于一些城市，例如阿格拉，关键景点在文章的引言中已经提到。 Pashley （讨论） 2025年9月3日 20:26 (UTC)[回复]
当你有包含城市的区域文章，或者一个有许多区域的大城市时，顶层文章可以提及最重要的景点，而将细节和次要景点留给其他文章。例如，上海#景点和宿务都市区#景点。这对于旅游景点以外的事物也同样适用，例如，查看上海#服装。 Pashley （讨论） 2025年9月3日 20:34 (UTC)[回复]
我发现区域文章通常不如城市内的文章完整。这在一定程度上是由于志愿提供的内容的性质。为某个刚去过的地方添加内容要容易得多。要撰写关于一个区域的文章，理想情况下你需要对该区域的大部分地区有所了解，这需要更长的访问时间来探索整个区域，而不是在一个城市里度过一个周末——将多个编辑者对城市的贡献整合到区域指南中要困难得多。
商业指南在这方面有优势——传统的旅游指南公司会支付作者几周的时间来游览该地区。评论网站拥有大量数据供分析——TripAdvisor 可以根据 4 星评论的数量进行过滤，Google 可能会知道有多少 Android 手机访问过一个地点（取决于用户设置等）。AlasdairW （讨论） 2025年9月3日 21:06 (UTC)[回复]

维基新闻时代的终结

你们中的一些人可能还记得我们在这里关于该网站的讨论——似乎他们已经起草了报告，我认为值得一读。首先，我认为最终结果是锁定所有维基新闻项目，而没有真正与维基新闻社区进行任何协商（SPTF 甚至声称这是一种明显的利益冲突），并且驳回了提出的真诚建议，这给人一种他们更倾向于专制方式的印象，因为该提案最初引起了如此大的反对（我也觉得他们似乎预先决定了结果）。

我认为我们在维基旅游方面不必过于担心，主要有两个原因——a) 维基旅游上的信息在很大程度上仍然是相关的，即使在 20 或 25 年后（不像维基新闻，内容在 2-3 周后就会变得无关紧要）；b) 尽管存在许多空白，维基旅游仍然是世界大部分地区的实用旅行网站。话虽如此，我认为现在是时候开始讨论如何真正与 Google、LonelyPlanet 或 Expedia 等主要旅行网站竞争了，即使这不会带来改变，这样我们才能在大局中保持相关性，并使我们的内容被旅行者阅读。无论如何，维基新闻安息吧，很遗憾它不得不以一个有缺陷的咨询过程结束。 //shb (t | c | m) 2025年9月4日 11:51 (UTC)[回复]

几点想法。第一，承认我不了解全部背景，这似乎只是一个提案。可以推测该提案可能会被否决？
一个有价值的资源将是关于每个项目编辑次数、页面浏览量等数据，虽然提案中展示了该工具的图表，但我在这里找不到提到的实际网页。在我看来，我们应该仔细研究哪些文章获得的读者最多，并从这些文章中吸取教训。从页面信息标签中我所看到的情况来看，旅行主题的表现远超我们的想象，而且它们的维护比目的地文章少。也许我们应该增加我们的旅行主题和行程的提供，这肯定会增加我们网站和其他替代品（如 LonelyPlanet）之间的区别。我还认为我们应该就车站文章达成共识，如果我们想让它成为一种新的文章类型，那么我们就应该扩展我们在这方面的产品。
听起来很奇怪，我们可能面临的问题是我们有太多的目的地（尤其是城市）文章。人口稀少的地区，如北达科他州，甚至最小的城镇都有文章，而这些地方的编辑者不足以保持列表的最新。我不确定解决这个问题的最佳方法，但我认为过去曾经有过一股创建然后删除空骨架文章的浪潮。
如果维基新闻确实被下线，那么时机似乎不恰当。新闻机构（PBS、NPR）被削减资金的时候，不是关闭项目的时候，肯定不是。我确实认为该提案提出了一个令人信服的论点，即维基新闻的现状不足，但我认为这应该导致变革而不是完全关闭。 --评论来自 Selfie City （讨论） （贡献） 2025年9月4日 12:45 (UTC)[回复]
根据 SPTF 在协商页面上的行为方式，我们可以非常确定他们已经预先决定了结果（尤其是因为他们事先也没有与维基新闻协商），而且报告中也没有提及维基新闻的任何优点。这是我见过的 WMF 章程中最过分的走形式协商之一。 //shb (t | c | m) 2025年9月4日 12:59 (UTC)[回复]
我意识到这是一个完全偏题的话题，但任何计算文章获得的实际编辑次数都必须排除 Brendan 重复尝试编辑赤道几内亚文章或破坏尼日利亚文章的情况。 Ikan Kekek （讨论） 2025年9月4日 14:30 (UTC)[回复]
据我所知，我不认为任何人类编辑都被排除在 WN 的计算之外——尽管我可能错了。 //shb (t | c | m) 2025年9月4日 14:35 (UTC)[回复]
也许我们可以排除标记为“已撤销/回滚”的编辑。 --评论来自 Selfie City （讨论） （贡献） 2025年9月4日 19:35 (UTC)[回复]
“可以推测该提案可能会被否决？” 是的。你可以在m:Requests for comment/Sister Projects next steps 发表你的意见，并查看（现已关闭的）其他评论，请参阅m:Talk:Public consultation about Wikinews。这将在今年晚些时候进行审查以做出任何决定。——Justin（koavf）❤T☮C☺M☯ 2025年9月4日 16:46 (UTC)[回复]
SPTF 表现出了极大的故意无视；理论上你可以这样做，但他们已经多次证明他们对听取反对意见不感兴趣。 //shb (t | c | m) 2025年9月4日 22:18 (UTC)[回复]
事实上，这也是为什么m:Requests for comment/Closure of Sister Project Task Force似乎出现的原因（我希望 WMF 能注意到 SPTF 在社区中并不受欢迎——大多数反对意见只是人们说社区不能关闭 WMF 指定的章程）。 //shb (t | c | m) 2025年9月4日 22:31 (UTC)[回复]
在我看来/猜测/看法中，各种 WMF 项目分为以下几个级别：
  • 安全/成功:
    • 维基百科
    • Wiktionary
    • Wikidata
    • 共享资源
    • Wikispecies
    • MediaWiki
  • 安全/有条件的成功:
    • 维基文库
    • Wikiquote
    • 维基旅游
  • 不安全/有条件的失败:
    • Wikibooks
    • 维基学院
  • 其他:
    • 维基新闻（可能关闭，重大重组）
    • 维基功能（太新无法评估，范围非常小而狭窄）
我不认为有人会瞄准英文维基旅游，否则，当时就会被提出来了。我在维基新闻的协商过程中一直很直言不讳，虽然我认为关闭的可能性提案是错误的，但我对那些只是在做自己工作的人遭受的一些辱骂感到失望。事实是，维基新闻一直很挣扎和失败。我不认为这是固有缺陷，我个人继续为英文维基新闻做贡献：我相信它。但有些用户认为批评和提案是一种攻击，并以一种我认为不当的方式进行回击。即使不是因为没有人想忍受这种戏剧性，我也认为不太可能出现任何关闭其他项目的严肃提案，即使有，维基教育和可能还有维基书籍也会排在维基旅游之前。
顺便说一句，如果管理员能处理一下Template_talk:WikivoyageSister#Wikifunctions，那就太好了。谢谢。——Justin（koavf）❤T☮C☺M☯ 2025年9月4日 16:54 (UTC)[回复]
感谢你的发帖，但由于我不认识你使用的所有维基缩写，我非常确定其他读者也不知道。所以如果你选择解释它们的意思，你将做一件好事。我将开始这项工作，即 wp=Wikipedia，wikt=Wiktionary，d 可能是 Wikidata，c 应该是 Commons，species 是清楚的，voy=Wikivoyage，wn=Wikinews。我不认识其他的。 Ikan Kekek （讨论） 2025年9月4日 17:10 (UTC)[回复]
抱歉，我的表达过于简略。正在修改。——Justin（koavf）❤T☮C☺M☯ 2025年9月4日 17:14 (UTC)[回复]
谢谢，很感激。 Ikan Kekek （讨论） 2025年9月4日 22:49 (UTC)[回复]
@Koavf: 你认为是什么区分了三个有条件的成功项目与成功的项目，进而又是什么区分了我们与维基书籍和维基教育（有条件的失败者）？ --评论来自 Selfie City （讨论） （贡献） 2025年9月5日 00:25 (UTC)[回复]
我認為“成功”的項目都非常活躍，並且普遍在其能滿足人們需求的方面做得很好。例如，如果你想知道一个词的含义（尤其是在英语中），并在 Wiktionary 上查找，你很可能会找到答案。对于那些有条件的成功项目，你可能会得到你想要的东西，并且有相当多的内容，但也有一些很大的空白。对于那些半失败的项目，需要做很多工作才能使其有用。这只是我通常的看法。——Justin（koavf）❤T☮C☺M☯ 2025年9月5日 00:38 (UTC)[回复]
很有道理。你认为维基旅游的漏洞在哪里？我认为近年来我们在轮廓文章方面取得了很大进展，但仍有许多小型城镇和郊区的文章过时。我犹豫的是，有没有人真的想去那些城镇旅游？在我看来，这是社区将来需要解决的问题。
话虽如此，自 2012 年以来，甚至自新冠疫情以来，维基旅游的有用文章与轮廓文章的比例已大大提高。如果我们的进步继续下去，我确实对我们能在几年内达到 Commons、WikiSpecies 等水平抱有很高的希望。 --评论来自 Selfie City （讨论） （贡献） 2025年9月5日 11:33 (UTC)[回复]
漏洞在于一些缺失的地点/话题，但主要是过时的信息、冗余和缺乏多媒体。我认为这个项目总体上是成功的，在某种程度上你可以用它来规划许多地点的旅行。我从未去过布法罗（纽约）或波士顿，我认为如果我只看我们的指南并做我认为有意义的事情，我可能会玩得很开心，但我也认为我会错过一些我们没有涵盖的东西，而且我们没有人们理想中想要的那种互动功能（例如，规划路线并将其连接到地图应用程序）。——Justin（koavf）❤T☮C☺M☯ 2025年9月5日 14:08 (UTC)[回复]
有趣。我认为我们目前的政策是反对多媒体。
至于缺失的地点和话题，你能举些例子吗？我想我们缺少旅行话题方面的漏洞比地点方面的要多。
我没有技术知识，但也许我们可以找到一种方法将行程路线图上的路线导出到 GPS 或 OSM 应用程序？如果能做到这一点，我们就可以解决你提到的关于行程的另一个问题。 --评论来自 Selfie City （讨论） （贡献） 2025年9月5日 14:52 (UTC)[回复]
是的，我们确实有一项政策，即在以打印为目的方面，我们不优先考虑多媒体，但这种情况对绝大多数（99%）用户来说是荒谬的，而且用户在 2003 年可能也不是这样使用的。试想一下，一个完美的旅行指南是什么样的，而且在那个世界里，没有一种是没有交互式媒体和动态规划路线并与地图或导航功能连接的功能的。至于话题，我偶尔会提供一些关于我们可以讨论什么的想法，最近一次我在这里提出了一个大致是提案的想法，在这里，我建议我们增加更多自由格式和轶事性质的材料，鼓励那种在旅行中可以令人愉快的漫步和故意迷路。我还曾设想过恢复多年前这里曾经有过的个人旅行博客，以达到这个目的。如果这个网站包含更多引人入胜和有趣的材料作为实际阅读材料，那在我看来也将是理想旅行指南的一部分。
更深入地说，如果你想象一下 Wiktionary，它是一个词典，但我们也添加了同义词词典、媒体（如音频发音和图片）来补充条目，还有附录提供更多琐碎的信息等等。这是为了让一个关于词语和术语的参考作品尽可能全面。如果这个网站只是一个列出“去地点，看事物”的列表，那是有价值的，但如果你想到一个旅行指南所能达到的最佳状态，那么我们可以扩展我们的视野，从原则上（但不一定从实践上，因为资源是有限的）去思考我们在这里想要做什么。——Justin（koavf）❤T☮C☺M☯ 2025年9月6日 00:20 (UTC)[回复]
我同意，我们需要摆脱将打印作为首要考虑的时代，因为现在手机信号无处不在。如今大多数人甚至都不使用打印机了。
我们网站目前面临的挑战之一是我们很少有人根据他们刚刚去过的地方来撰写内容。你说得对，如果我们能有旅行者撰写的引人入胜的行程，就能提高网站质量。这类文章更主观，且时效性信息较少，所需的维护也更少，以便保持相关性。
我希望看到的一篇文章是内陆航道，但必须由真正驾驶自己的船只走过大部分航程的人来撰写。我认为这可以成为一个绝佳的行程，即使它只涵盖一个州内的路线。 --评论来自 Selfie City （讨论） （贡献） 2025年9月6日 12:57 (UTC)[回复]
所以，我同意大家的观点，我们不应优先考虑打印页面，但仍然有一个因素是，有些地方的手机信号非常弱，甚至没有，而它们并非都是极其偏远的。能否有人告诉我们，太平洋海岸公路约 70 英里路段是否仍然没有手机信号？我的感觉是，虽然打印指南不应该是本网站的主要优先事项，但我们仍然应该确保有足够的打印内容，以对那些冒险进入手机信号盲区的人有用。 Ikan Kekek （讨论） 2025年9月6日 20:04 (UTC)[回复]
原则上同意，并且也同意我们需要为最重要的问题做出最多的考虑：例如，为视障人士提供无障碍服务，或者为连接不稳定的用户提供页面服务等等。打印当然是一个考虑因素，并且可能对少数用户来说是一个重要的因素，但远比不上人们实时访问网络的使用方式，许多时候使用的是具有地图和导航功能的便携设备。我们完全不与这些基本功能集成，至少可以说是一种疏漏。——Justin（koavf）❤T☮C☺M☯ 2025年9月6日 21:54 (UTC)[回复]
是的，这太疯狂了！ Ikan Kekek （讨论） 2025年9月6日 22:17 (UTC)[回复]
同意——尽管如此，根据我的推断，我们已经取得了相当大的进步，尤其是考虑到我们受到 WMF 的一点忽视。静态地图在大多数文章中不再受到青睐，而能够制作静态地图的贡献者不足在某种程度上起到了作用。我们已经转向更好地与 OSM 集成，尤其是在地图形状方面。取得了很大进展，但仍有许多工作要做。 //shb (t | c | m) 2025年9月7日 00:12 (UTC)[回复]
@Ikan Kekek, SelfieCity: 我以前是那种去偏远地区或没有信号的地方（我经常这样做）会打印东西的人，但现在我会在手机上保存一个离线 PDF 副本。现在大多数手机的存储空间都足够了，所以我认为值得重新审视我们的政策，使其更宽松一些。 //shb (t | c | m) 2025年9月7日 00:03 (UTC)[回复]
作为维基书籍的管理员，这可能是由于未完成或被放弃的书籍数量庞大，加上参与度低。与维基百科、维基旅游或维基文库不同，在维基书籍上写书之前，你需要对主题有相当的了解（因此，在同一篇文章上没有大量的合作）。有很长的过程来清理许多旧的/被放弃的书籍，但这项工作已经进行了至少两年了。 //shb (t | c | m) 2025年9月7日 00:39 (UTC)[回复]
同意。而且教科书的好处是你可以回来完成它。新闻则不然：如果新闻没有完成或没有写出来，它就根本不再是新闻了。——Justin（koavf）❤T☮C☺M☯ 2025年9月5日 00:40 (UTC)[回复]
是的，这就是为什么我认为维基新闻的整个前提从一开始就有问题（也是为什么我在 SPTF 协商出现之前就支持关闭许多小型维基新闻项目）。 //shb (t | c | m) 2025年9月5日 00:50 (UTC)[回复]
抱歉，我不同意对批评的回应是不合理的。当一个委员会审查一个项目时，最恰当的做法是直接联系该项目，并与他们一起探讨如何改进项目。然而，SPTF 并未这样做——他们和其他项目一样，在同一时间通知了维基新闻（参见我之前的消息以获取链接）。你可能会争辩说这可能是一个真正的错误，但当多次提出这个问题时，SPTF 要么几乎不回应关于沟通不足的批评，要么 Victoria 坚持认为参与涉及自己项目的协商是一种所谓的利益冲突。当你与社区的沟通如此糟糕，甚至试图掩饰都不去做时，做出如此反应是完全正常的。 //shb (t | c | m) 2025年9月5日 00:33 (UTC)[回复]
在过去十年，英文维基旅游的页面浏览量约为英文维基新闻的 2.5 倍。当然还有其他语言，但英语通常是所有维基媒体维基中最大的，所以比较起来最容易。此外，如果你仔细查看统计数据，近年来维基旅游和维基新闻之间的差距一直在扩大。所以我认为短期内我们是相当安全的。至于我们如何发展，有很多问题需要解决，但我仍然相信，除了那些多年来未曾改变的传统维基旅行内容之外，许多编辑没有充分改写从维基百科迁移过来的内容。有一些句子是逐字添加的，这 1. 在我们的文章语气应该比平淡、技术性的维基百科更随意、更有趣时是不合适的，而且 2. 重复的内容继续在 SEO 排名中惩罚我们。例如，有许多文章涉及柯本气候分类。一个城市的关于气候和天气的部分应该写得就像你在和一个想去你最近去过的地方旅行的朋友交谈一样。我们的大部分文章都应该这样写。我注意到互联网用户点击搜索链接的频率不如以前，因为他们经常只阅读顶部的 AI 摘要（有趣的是，AI 经常使用维基作为其摘要的主要来源），但正在规划行程的认真旅行者仍然会想要细节并点击更多内容。
另一个大问题是缺少一个在线应用程序。如果我们继续只依赖网站URL，Wikivoyage的读者将继续以桌面和笔记本电脑用户为主，而不是平板电脑和手机用户（年轻人在这上面花费的时间更多）。不幸的是，这超出了我们的能力范围，因为为Wikivoyage开发应用程序并非WMF的优先事项。Gizza（roam） 2025年9月5日 01:10 (UTC)[回复]
我认为，这在未来几年最有可能杀死Wikivoyage。 Ikan Kekek（讨论） 2025年9月5日 01:14 (UTC)[回复]
绝对如此——我认为这将会是维基媒体项目（除维基百科外）走向衰落的最大原因（目前 Commons 只有一个 Android 应用）。//shb （t | c | m） 2025年9月5日 01:35 (UTC)[回复]
IMO，即使是移动端优化网站的网络包装也比什么都没有好，而且我经常喜欢下载各种移动端优化网站作为渐进式Web应用，尤其是在Play商店（或iOS的App Store）没有原生版本的时候。 Sbb1413 (他)（讨论 • 贡献） 2025年9月5日 02:24 (UTC)[回复]
也许是相关的，我在 Wikimania 举行前不久提名了内罗毕为 DotM，期望一些与会者会阅读和使用这篇文章，注意到提名横幅，然后编辑/更新这篇文章，或者只是添加一点东西。除了两次 Brendan 的编辑外，文章历史显示在那之后没有任何编辑。不幸的是，Wikivoyage 似乎对其他维基的编辑者来说并不有趣或有吸引力，即使在他们旅行期间和之后 :-(。 --Ypsilon（讨论） 2025年9月5日 04:37 (UTC)[回复]
我认为有一个旅游指南应用程序使用了Wikivoyage的内容，但它是非官方的，并且只是偶尔更新。来自其他项目（尤其是维基百科）的更多用户将大有帮助，尽管我们的政策并不相同。--来自 Selfie City（讨论）（贡献） 2025年9月5日 11:40 (UTC)[回复]
（但我现在找不到了，所以也许它已经不存在了。无论如何，为Wikivoyage和其他项目创建一个应用程序应该是WMF的优先事项—这就是未来，而且肯定不会很难创建。）--来自 Selfie City（讨论）（贡献） 2025年9月5日 11:41 (UTC)[回复]
你说的是 Wikivoyage:Kiwix 吗？是的，它很好，但可惜所有内容都是离线的。//shb （t | c | m） 2025年9月5日 12:08 (UTC)[回复]
也许吧，我想还有另一个，专门针对Wikivoyage的。我不确定，因为我上次查看是几年前了。
我们确实需要一个官方应用程序。--来自 Selfie City（讨论）（贡献） 2025年9月5日 12:11 (UTC)[回复]
@SHB2000 不想要离线应用（这正是应用唯一合理的用途），而你想要一个浏览器包装器，这样用户就不需要输入wikivoyage.org到浏览器里……真是奇怪的时代 :-D -- andree 2025年9月5日 15:48 (UTC)[回复]
我应该说明一下，我说的离线应用并不是指每隔几年就要在手机上下载整个维基（像Kiwix那样），而是指一个可以离线保存页面的在线应用（这对公园文章来说是巨大的好处）。//shb （t | c | m） 2025年9月5日 22:38 (UTC)[回复]
“似乎对其他维基的编辑者来说并不有趣或有吸引力，即使在他们旅行期间和之后”：我在想，如果有什么类似于“OSM notes”的东西对这个有用的话。基本上是文章上的一个“建议修改”浮动图标？也许只是将建议发布到讨论页就足够了？而且理想情况下，我们应该有一个这样的建议列表，以有效地处理/拒绝它们……这可能只对访问频率较低的地区有用，因为大城市通常已经覆盖得足够好，而且不需要进行更改。 -- andree 2025年9月6日 08:05 (UTC)[回复]
我也关注了对m:Proposal for Closing Wikinews及其相关m:Public consultation about Wikinews的反应。我认为 Wikivoyage 不需要担心我们会成为下一个被砍掉的项目。
我认为m:Proposal for Closing Wikinews中的数字很有启发性，如果你对事实以及董事会用来评估成功或失败的标准（例如，“与使命的一致性”）感兴趣，我建议你阅读它。我学到了一些东西
摘要
  • Wikivoyage 的读者比 Wikinews 多得多.
  • Wikivoyage 创建的文章比 Wikinews 多。
  • Wikivoyage 的社区比 Wikinews 的社区大。
  • Wikivoyage 的社区比 Wikinews 的社区更活跃。
长篇
Wikimédia 项目的页面浏览量中只有 20% 是来自人类读者。在三个月内，所有 Wikinews 的总和获得了 1000 万次人类读者的页面浏览量。仅英文 Wikivoyage 在过去三个月就获得了其 30 倍的浏览量。大多数“访问者”显然不是在寻找新闻文章，因为最受欢迎的搜索词中有 90% 是俄语的，而且是关于婴儿名字的。（我没开玩笑：“日本女性名字”，“韩国名字”，“穆斯林女孩的好名字”等等。）
人类读者不访问这些网站并不奇怪，因为 Wikinews 几乎不写文章。例如，我大约在七月检查时，德语 Wikinews 上个月只写了一篇（1）文章；那是一篇关于一位小人物政客的、有些宣传意味的文章。俄罗斯 Wikinews 上的几乎所有内容都是机器人从其他新闻网站复制/粘贴的免费内容——正如 Wikivoyage 比大多数人都清楚的那样，这会杀死 SEO。搜索引擎会索引这些页面（爬虫机器人占 Wikinews 流量的 70%），但它们排名很低。例如，enwikinews 上的特色文章是关于德国失业率的；搜索关于“德国失业率 2025”的信息会将其排在结果的第二页——这已经算不错了。如果你将文章的完整标题复制/粘贴到其他搜索引擎，Bing 会将 Wikinews 排在第一页的中间位置，而 Yahoo! 和 DuckDuckGo 都会将 Wikinews 排在第二页。我们不指望简单的搜索“伦敦”能让 Wikivoyage 排在前列，但如果你搜索我们一个更长或更独特的页面标题，比如歌剧院木偶行程，Wikivoyage 经常会出现在第一页（在这个例子中，Google 将我们列为第一）。
英文 Wikinews 在讨论早期报告称他们提高了产量：他们过去每月正式发布 8 篇新闻文章，最近达到了 9 篇的里程碑。相比之下，在英文 Wikivoyage，我们上个月创建的文章数量是其十倍，考虑到一家报纸很容易在一个月内写出关于一个小城市的一百篇新闻文章，而我们几乎只能为同一个城市创建一篇，这尤其令人印象深刻。委员会对 Wikinews 的一个问题是，如果你每三四天写一篇新闻文章，你就没有真正实现教育人们了解世界正在发生什么的初衷。
内容创作不足的原因之一是核心社区非常小（例如，中文 Wikinews 主要由三名编辑撰写；德语 Wikinews 基本上只有一个编辑）。在最活跃的英文 Wikinews 社区讨论页面上，有几个关于其未来的讨论。比长期活跃的英文 Wikinews 用户加起来还多的人，在这一个讨论串里谈论 Wikinews 的未来。
许多社区似乎连基本的维护都跟不上。目前，英文 Wikinews 是注册编辑和管理员数量最大的，但在主命名空间中有18 篇条目等待“快速删除”，其中几篇被标记为纯粹的破坏，已经等待了几天管理员来删除。他们有 17 名人类管理员。只需要其中一个每天或每两天检查并清空该类别。（这里的同类类别当然是空的。我们的一些管理员显然会关注Special:RecentChanges，并立即处理破坏页面。）
如果你想去 Meta-Wiki 阅读讨论，请记住，很多评论都是 Wikinews 编辑在处理他们的情绪。一位编辑说，Wikinews 有价值是因为它感觉像一份你无法被解雇的工作。总的讨论感觉就像公司宣布了迟到的裁员后，在工作场所进行的对话。
我们可以学到什么
  • 优化长期成功。就像 Wikinews 一样，与 Wiktionary 不同，我们的内容需要定期更新。这意味着一个可行的 Wikivoyage 需要比一个可行的 Wiktionary 更多的编辑者。整个维基媒体运动应该提高创建新语言版本的门槛，特别是对于需要最新信息的项目。我们可以通过防止过于乐观的启动来避免痛苦的关闭。
  • 如果你不增长，你就在萎缩。我们应该考虑招聘机会。通过学校社团更新他们当地的地区？请求 WMF 为新编辑资助广告活动（“看看维基百科的姊妹旅游指南关于你的城市有什么错误”？！）？在旅游会议上做演讲？举办一个年度“维基旅游”活动？尽早开始为我们的生日竞赛工作？
  • 考虑一些改变。Wikinews 讨论中反复出现的主题之一是长期规则阻碍了文章的创建。也许我们应该重新考虑一些长期规则。例如，如上所述，我们是否应该继续优先考虑印刷版本？
  • 如果我们不面对令人不快的现实，它最终会被别人替我们完成。我们可以为最小的 Wikivoyage 建立一个审查流程，并制定一个帮助它们的计划。我们知道一个功能正常的 Wikivoyage 社区是什么样的。如果来自不同语言的长期 Wikivoyager 可以去，例如，印地语 Wikivoyage 说：这是一种广泛使用的语言，具有巨大的潜力。但文章几乎没有，编辑者也几乎没有，你基本上是在失败。我们能做些什么来提供帮助？如果答案是这种语言什么都不行（这对于小语种来说可能是真的，但对于印地语可能不会），那么我们应该提议关闭，而不是等待外部团体告诉我们该做什么。
WhatamIdoing（讨论） 2025年9月6日 19:32 (UTC)[回复]
关于最后一点，我曾一再反对创建小型语言 Wikivoyage，但总是被否决，很大程度上是因为 Wikivoyage 似乎是为数不多在孵化后确实能增长的项目之一（这有多真实我仍持怀疑态度）。我不会反对创建一个政策，确保在启动前存在一定数量的文章——比如所有大约 200 个国家，一些重要的全球城市，以及重要的公园和奇迹。//shb （t | c | m） 2025年9月6日 23:34 (UTC)[回复]
@WhatamIdoing：感谢你的输入。这些都是很棒的见解。如果我们能创建一个吸引我们姐妹网站编辑者的活动，那将是极好的，正如前面的一些评论所说，很多人并不知道这里发生的事情。尽管我们与维基百科存在差异，但我相信许多 WP 编辑会喜欢在这里的编辑过程。我最初是在维基百科开始的，但能够有文章结构（了解、查看、操作等）已经准备好，并且用真实世界的知识替代引用来源，这些是我最初被 Wikivoyage 吸引的原因。话虽如此，我仍然在维基百科编辑，所以我认为同样的情况也能从姐妹网站的其他作者那里获得积极的参与。--来自 Selfie City（讨论）（贡献） 2025年9月7日 02:24 (UTC)[回复]
此外，我还清理了 Wikinews 上的 CSD 类别（本地政策允许这样做），令人惊讶的是，一个英文项目上长期存在未处理的破坏——这不是一个有17 名管理员的维基上会出现的情况。//shb （t | c | m） 2025年9月7日 04:19 (UTC)[回复]
这太不可思议了，几年前我记得 Wikinews 还是一个重要新闻事件的及时信息来源。--来自 Selfie City（讨论）（贡献） 2025年9月7日 14:27 (UTC)[回复]
英文 Wikinews 多年来主要由一个人运营，他几年前已经去世了。这并没有真正解释为什么其他人处于不良状态，但他们在 enwikinews 上努力组织自己。
企业有时会谈论“公交车测试”：如果这个关键员工被公交车撞倒/突然离开办公室且无法联系，公司会怎么样？（我甚至听说过一些公司通过在没有任何预警的情况下让经理度假来模拟这种情况。）
对我们来说，一个可能的“经验教训”是永远不要过度依赖一个人。这可能意味着我们每个人都决定做得更多（例如，我每年几次查看Special:RecentChanges：我能做得更多吗？）或者做得更少（例如，如果一个管理员认为他们是唯一一个处理积压类别的人，也许他们可以在这里发个帖子说：“嘿，还有其他人关注这个类别吗？我希望有人每天都能检查一下。”） WhatamIdoing（讨论） 2025年9月7日 16:31 (UTC)[回复]
哦，是的，我知道 Pi-zero——他确实花了很多时间在 enwikinews 和 enwikibooks 上（后者是我认识他的地方），那肯定是的。//shb （t | c | m） 2025年9月7日 19:46 (UTC)[回复]
哦，好吧，这解释了很多。我认为我们的多样性更大，尽管近年来我们失去了一些可靠的管理员。但我认为我们拥有多样化的专业知识，有几位管理员擅长处理广告商和内容问题，而另一些则擅长代码和模板（我指的是你，shb）。--来自 Selfie City（讨论）（贡献） 2025年9月7日 20:20 (UTC)[回复]

有趣

m:Wikipedia 25/Easter egg experiments 看起来像我们可以做的事情。WhatamIdoing（讨论） 2025年9月14日 18:24 (UTC)[回复]

这确实是个有趣的想法。//shb （t | c | m） 2025年9月16日 13:25 (UTC)[回复]

服务器切换 - 您的维基将在短时间内变为只读模式

Trizek (WMF)（讨论） 2025年9月18日 15:41 (UTC)[回复]

取自“https://wikivoyage.cn/w/index.php?title=Wikivoyage:Travellers%27_pub/2025&oldid=5157499”
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.