维基语游:旅行者酒吧/2025
 |
这是一个过去讨论的存档。请勿编辑本页内容。如果您希望发起新的讨论或重提旧的讨论，请在当前的讨论页进行。 |
 | 旅行者酒吧存档： 2007 • 2008 • 2009 • 2010 • 2011 • 2012 • 2013 • 2013 (额外) • 2014 • 2015 • 2016 • 2017 • 2018 • 2019 • 2020 • 2021 • 2022 • 2023 • 2024 • 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，将移至结构化子页面），以及一篇类似于我过去写过的学术论文（Google Scholar）。欢迎提出任何额外的反馈、想法或评论（论文大部分完成后，我将在此处发布草稿供您检查）。同时，一个问题——您是否知道有其他教育工作者在维基语游上开展活动？ Piotrus （讨论） 2025年1月6日 07:17 (UTC)
- 我记得几年前我们这里有印度学生。我想你现在是唯一一个。 Ikan Kekek （讨论） 2025年1月6日 08:23 (UTC)
- 如果我没记错的话，尼日利亚及更广泛的非洲的考察活动是通过 WM Nigeria（或某个类似组织）协调的，尽管我也不太确定具体是如何运作的。几年前，一位法国的英语老师也曾将维基语游用作教学工具。--SHB (t | c | m) 2025年1月6日 10:47 (UTC)
- 我以前是老师，在 2017 年为学生组织了几个维基语游编辑项目。—Granger （讨论 · 贡献） 2025年1月6日 14:44 (UTC)
- @Mx. Granger 您停止使用维基语游是因为工作变动还是因为不奏效？ Piotrus （讨论） 2025年1月7日 01:12 (UTC)
- 我记得那是法国的高中生，格林杰，我不记得您的教育项目了。 Ikan Kekek （讨论） 2025年1月6日 16:07 (UTC)
- 大概是吧——我不记得了，也不知道用户是谁，所以查不到 :( SHB (t | c | m) 2025年1月7日 01:50 (UTC)
- @Piotrus：工作变动。我认为这个项目相当成功。除了让学生有机会在真实的语境中使用英语外，它还改善了乌拉圭一些目的地的覆盖范围。我曾监督学生的编辑，之后又对文章进行了一些清理。 @Ikan Kekek：它在这里有简短的讨论：Talk:Uruguay#Workshop tomorrow。 —Granger （讨论 · 贡献） 2025年1月7日 04:29 (UTC)
- 大概是吧——我不记得了，也不知道用户是谁，所以查不到 :( SHB (t | c | m) 2025年1月7日 01:50 (UTC)
- 我以前是老师，在 2017 年为学生组织了几个维基语游编辑项目。—Granger （讨论 · 贡献） 2025年1月6日 14:44 (UTC)
- 如果我没记错的话，尼日利亚及更广泛的非洲的考察活动是通过 WM Nigeria（或某个类似组织）协调的，尽管我也不太确定具体是如何运作的。几年前，一位法国的英语老师也曾将维基语游用作教学工具。--SHB (t | c | m) 2025年1月6日 10:47 (UTC)
启动！加入我们参与 2025 年维基斋月！
各位好，
我们很高兴宣布启动 2025 年维基斋月，这是一个年度国际活动，旨在通过维基百科的力量庆祝和保存伊斯兰文化和历史。作为本地维基百科的活跃贡献者，您特别受邀参加本次启动活动。
今年的活动旨在邀请您加入我们，撰写、编辑和改进文章，以展示伊斯兰传统、历史和文化的丰富性与多样性。
- 主题：2025 年维基斋月活动启动
- 时间：2025 年 1 月 19 日
- 时间：16:00 UTC 时间，并贯穿整个斋月（始于 2025 年 2 月 25 日）。
- 加入 Zoom 会议：https://us02web.zoom.us/j/88420056597?pwd=NdrpqIhrwAVPeWB8FNb258n7qngqqo.1
- Zoom 会议由维基媒体孟加拉分会主持
要开始，请访问活动页面了解详情、资源和指南：2025 年维基斋月。
在此处添加您的社群，并用您当地的语言组织 2025 年维基斋月活动。
无论您是首次编辑者还是经验丰富的维基百科人，您的贡献都至关重要。齐心协力，我们可以确保伊斯兰文化和传统得到充分的代表，并为所有人所访问。
请随意邀请您的社群和朋友。在您准备参与时，如有任何疑问或需要支持，请随时联系我们。
让我们共同努力，使 2025 年维基斋月取得成功！→ 我。代表国际团队 2025年1月16日 12:08 (UTC)
《通用行为准则》年度审查：就 UCoC 和执行指南发表您的意见
请帮助翻译成您的语言.
我写信通知您，《通用行为准则》和执行指南的年度审查期现已开放。您可以通过 2025 年 2 月 3 日之前提出变更建议。这是年度审查的几个步骤中的第一步。阅读更多信息并在 Meta 的 UCoC 页面上找到要加入的讨论。
《通用行为准则协调委员会》（U4C）是一个致力于公平一致地实施 UCoC 的全球性团体。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，请查阅 U4C 章程。
请将此信息在您的社群中适当的地方分享给其他成员。
与 U4C 合作 -- Keegan (WMF) （讨论） 2025年1月24日 01:12 (UTC)
提醒：年度 UCoC 审查第一部分即将结束
请帮助翻译成您的语言.
这是一个提醒，关于《通用行为准则》和执行指南的年度审查第一阶段即将关闭。您可以在2025 年 2 月 3 日截止日期前提交变更建议。这是年度审查的几个步骤中的第一步。阅读更多信息并在 Meta 的 UCoC 页面上找到要加入的讨论。在审查反馈后，关于更新文本的提案将于 3 月发布在 Meta 上，供下一轮社群审查。
请将此信息在您的社群中适当的地方分享给其他成员。
与 U4C 合作 -- Keegan (WMF) （讨论） 2025年2月3日 00:49 (UTC)
即将举行的语言社群会议（2 月 28 日，14:00 UTC）及新闻通讯
大家好！
我们很高兴地宣布，下一次语言社群会议即将举行，时间是2 月 28 日 14:00 UTC！如果您想参加，只需在维基页面上注册即可。
这是一个由参与者驱动的会议，我们将分享关于语言相关项目的最新情况，讨论语言维基中的技术挑战，并合作解决问题。在我们上一次会议中，我们讨论了开发语言键盘、创建摩尔维基百科以及维基非洲大会语言支持的更新等话题。
有话题要分享吗？ 无论是您项目的技术更新、您需要帮助的挑战，还是对翻译支持的要求，我们都非常希望能听到您的声音！欢迎回复此消息或在此文档中添加议程项目。
另外，我们想强调的是，第六期语言与国际化新闻通讯（2025 年 1 月）已在此发布：Wikimedia Language and Product Localization/Newsletter/2025/January。该通讯提供了 2024 年 10 月至 12 月期间的更新，包括新功能开发、各种语言相关技术项目和支持工作的改进、社群会议的详情以及参与项目的想法。要获取最新信息，您可以订阅其维基页面上的通讯：Wikimedia Language and Product Localization/Newsletter。
我们期待您在语言社群会议上提出您的想法并参与其中，届时见！
《通用行为准则》年度审查：拟议修订可供评论
请帮助翻译成您的语言.
我写信通知您，《通用行为准则》（UCoC）执行指南和《通用行为准则协调委员会（U4C）章程》的拟议修改现已发布在 Meta-wiki 上供社群查阅。您可以在2025 年 3 月 18 日星期二结束前提交您对建议修改的反馈。这是年度审查流程的第二步，最后一步将是社群对拟议修改进行投票。阅读更多关于该流程的信息并在 Meta 的 UCoC 年度审查页面上查找相关链接。
《通用行为准则协调委员会》（U4C）是一个致力于公平一致地实施 UCoC 的全球性团体。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，请查阅 U4C 章程。
请将此信息在您的社群中适当的地方分享给其他成员。
与 U4C 合作 -- Keegan (WMF) （讨论） 2025年3月7日 18:52 (UTC)
2025 年维基孟加拉活动正在进行——快来加入我们！
各位好，
来自维基孟加拉团队的问候！
我们很高兴地宣布，2025 年维基孟加拉活动即将到来！今年的活动主题将聚焦于孟加拉的鸟类，邀请参与者捕捉并分享孟加拉丰富多样的鸟类令人惊叹的照片。
活动详情
- 📅 日期：2025 年 3 月 1 日 - 31 日
- 📍 主题：孟加拉的鸟类
- 🎯 主办方：Bangla WikiMoitree
维基孟加拉 是一个在维基共享资源上举办的国际摄影比赛，旨在记录世界各地的孟加拉文化和遗产。作为孟加拉文化和遗产汇集项目的一部分，该项目每年举办一次，主题特定，邀请参与者向维基共享资源贡献照片，以扩展自由知识。通过这项活动，您可以成为一个致力于保护和展示孟加拉鸟类之美、行为和生物多样性的社群的一员。这项倡议旨在向世界展示孟加拉自然遗产的丰富性。
如何参与？
比赛将于2025 年 3 月 1 日至 31 日在维基共享资源上进行。要参与，只需：
- 📷 拍摄孟加拉的鸟类的照片。
- 📤 将您的照片上传至维基共享资源，归类于 2025 年维基孟加拉类别。
- 📖 在活动页面了解更多关于比赛规则和指南。
为何参与？
通过您的贡献，您将帮助记录孟加拉丰富的鸟类生活，使知识更容易被所有人访问。此外，还有丰厚的奖品等待您赢取！
奖品
一等奖：50,000 孟加拉塔卡，奖杯和证书。
二等奖：25,000 孟加拉塔卡，奖杯和证书。
三等奖：15,000 孟加拉塔卡，奖杯和证书。
如果您有兴趣参加摄影活动，请开始拍摄，并为在维基共享资源上进行的摄影活动做好准备。有关比赛规则和奖品的更多信息，请在此处查阅。如有任何疑问，请给我们发送电子邮件或在此处加入我们的电报群组这里。
致以诚挚的问候，
维基孟加拉团队.
~ Moheen (持续讨论) 2025年3月13日 13:44 (UTC) #WikiLovesBangla
您的维基即将进入只读模式
维基媒体基金会将切换其数据中心之间的流量。这将确保即使在发生灾难后，维基百科和其他维基媒体维基也能保持在线。
所有流量将于3 月 19 日切换。切换将于14:00 UTC。
不幸的是，由于MediaWiki的一些限制，在切换期间必须停止所有编辑。我们对此中断表示歉意，并正在努力将其在未来最小化。
在操作开始前 30 分钟，所有维基上将显示一条横幅。此横幅将一直可见，直到操作结束。
您将可以在短时间内阅读所有维基，但无法编辑。
- 在2025 年 3 月 19 日星期三，您将无法编辑长达一小时。
- 如果您在此期间尝试编辑或保存，您将看到一条错误消息。我们希望在这几分钟内不会丢失任何编辑，但我们无法保证。如果您看到错误消息，请等到一切恢复正常。届时您应该可以保存您的编辑。但是，我们建议您先将更改复制一份，以防万一。
其他影响:
- 后台任务将变慢，有些可能会被丢弃。红链接可能更新不及时。如果您创建的文章已在其他地方链接，该链接将比平时更长时间地显示为红色。一些长时间运行的脚本将被停止。
- 我们预计代码部署将像往常一样进行。但是，如果操作需要，可能会有例外情况的代码冻结。
- GitLab 将在约 90 分钟内不可用。
此项目如有必要可能会推迟。您可以在wikitech.wikimedia.org上查看时间表。任何更改都将在时间表中公布。
请将此信息分享给您的社群。MediaWiki message delivery 2025年3月14日 23:14 (UTC)
- 只是提醒一下，这些事件是“最多一小时”，但在最近几年，通常是“不到五分钟”。大多数人根本不会注意到，但如果您注意到了，只需等待几分钟，然后重试您的编辑即可。 WhatamIdoing （讨论） 2025年3月15日 21:50 (UTC)
《通用行为准则》执行指南和 U4C 章程的最终拟议修改现已发布
《通用行为准则执行指南》和 U4C 章程的拟议修改现已发布在 Meta-wiki 上供社群查阅，以提前通知投票期。该最终草案是基于前两轮社群审查制定的。社群成员将可于 2025 年 4 月 17 日开始投票。投票将于 2025 年 5 月 1 日结束，结果将于 5 月 12 日之前公布。U4C 选举期（从候选人征集开始）将在审查结果公布后立即开始。更多信息将很快发布在选举的维基页面上。
请注意，此过程在接下来的两个月内需要发送更多消息。
《通用行为准则协调委员会（U4C）》是一个致力于公平一致地实施 UCoC 的全球性团体。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，请查阅 U4C 章程。
请将此消息分享给您社群的成员，以便他们也能参与。
与 U4C 合作 -- Keegan (WMF) （讨论） 2025年4月4日 02:05 (UTC)
维基数据和姐妹项目：一次在线社群活动
（抱歉用英语发布）
大家好，我很高兴地分享即将举行的在线活动的消息，名为《维基数据和姐妹项目》，旨在庆祝维基数据以不同方式支持或增强其他维基媒体项目的应用。该活动将于2025 年 5 月 29 日至 6 月 1 日的 4 天内举行。
我们诚邀演讲嘉宾参加此次社群活动，分享成功故事、挑战，展示您可能正在进行的、维基数据参与其中的工具或项目，无论是维基百科、共享资源、维基文库以及所有其他维基媒体项目。
如果您有兴趣参加，请在此注册。如果您希望在活动中发表演讲，请在活动讨论页填写此会议提案模板，您也可以在此提出任何疑问。
我希望能看到您参加此次活动，无论是在观众席还是作为演讲嘉宾，- MediaWiki message delivery （讨论） 2025年4月11日 09:18 (UTC)
立即就修订后的 UCoC 执行指南和 U4C 章程进行投票
关于《通用行为准则》执行指南（“UCoC EG”）和 UCoC 协调委员会章程修订的投票期现已开放，截止日期为 5 月 1 日 23:59 UTC（按您的时区查找）。请在 Meta-wiki 的 UCoC 页面上阅读有关如何参与以及在投票前审阅提案的信息。
《通用行为准则协调委员会（U4C）》是一个致力于公平一致地实施 UCoC 的全球性团体。EG 和章程的本次年度审查由 U4C 规划和实施。未来几个月将提供关于 UCoC 本身审查的更多信息。有关 U4C 的更多信息和职责，您可能需要查阅 U4C 章程。
请将此消息分享给您社群的成员，以便他们也能参与。
与 U4C 合作 -- Keegan (WMF) （讨论） 2025年4月17日 00:35 (UTC)
就 UCoC 执行指南和 U4C 章程的拟议修改进行投票
关于《通用行为准则》执行指南和 U4C 章程修订的投票期将于 2025 年 5 月 1 日 23:59 UTC 结束（按您的时区查找）。请在 Meta-wiki 的 UCoC 页面上阅读有关如何参与以及在投票前审阅提案的信息。
《通用行为准则协调委员会（U4C）》是一个致力于公平一致地实施 UCoC 的全球性团体。本次年度审查由 U4C 规划和实施。有关 U4C 的更多信息和职责，您可能需要查阅 U4C 章程。
请在您的社群中以适当的语言分享此消息，以便他们也能参与。
与 U4C 合作 --
共享资源通知删除机器人已恢复
我很高兴地宣布，感谢 @Taavi 这个技术大神，共享资源通知删除机器人终于又恢复运行了！您应该很快就会看到新的讨论页通知（适用于在约 15 分钟前之后开始的符合条件的删除讨论）。
在此通知 @Ikan Kekek @SHB2000 @WhatamIdoing 和 @LPfi，他们长期以来一直在询问这个问题。我为两年的停机时间表示歉意。我正努力确保机器人能够持续运行，并防止此类事件再次发生。
祝编辑愉快！ — MusikAnimal 讨论 2025年5月4日 09:07 (UTC)
- 太棒了——我期待这一天很久了，很高兴您和 Taavi 终于实现了！再次感谢。 :) //shb (t | c | 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)
我们即将为您维基启用新的图表扩展！
（抱歉用英语发布）
大家好！我们有好消息要分享，关于影响所有使用图表维基的图表问题。
如您可能知道，旧的 Graph 扩展于 2023 年因安全原因被禁用。我们在过去两年里努力寻找一个能替代旧扩展的解决方案，并为希望在文章中展示图表的用户提供更安全、更好的解决方案。因此，我们开发了Charts 扩展，它将取代旧的 Graph 扩展，并可能取代EasyTimeline 扩展。
在成功将该扩展程序部署到意大利语、瑞典语和希伯来语维基百科以及 MediaWiki.org 之后，作为试点阶段的一部分，我们很高兴地宣布，我们将继续进行下一阶段的部署，您的维基也将包含在内。
部署将分批进行，并将于 5月6日 开始。请参阅 我们在 MediaWiki.org 上的页面，了解新的图表扩展程序何时会在您的维基上部署。您还可以 查阅 MediaWiki.org 上关于该扩展程序的文档。
如果您有任何疑问、需要澄清，或者只是想表达您的意见，请参阅 MediaWiki.org 上的项目讨论页，或在此主题下直接提及我。一旦图表扩展程序在您的维基上启用，如果您在使用过程中遇到问题，请在 讨论页或 Phabricator 上报告。
提前感谢！ -- User:Sannita (WMF) (讨论) 2025年5月6日 15:07 (UTC)
- 有人记得我们是否在使用这些功能吗？ WhatamIdoing (讨论) 2025年5月6日 17:44 (UTC)
- 我不认为我们在这个网站上使用过图表——从来没有。//shb (t | c | m) 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)
- 我认为它对于制作现有 {{Climate}} 模板的重制版本很有用。 Sbb1413 (他) (讨论 • 贡献) 2025年5月7日 11:38 (UTC)
- 你好 @WhatamIdoing，谢谢你的提问。非维基百科网站的部署将在本周进行，与未来两周内未安排部署的大部分维基百科网站同步。是否对你的工作有用，完全取决于你自己。 Sannita (WMF) (讨论) 2025年5月7日 11:19 (UTC)
- 是的，我认为那只是使用了非常复杂的 CSS，但从未正式使用 MW 扩展。//shb (t | c | m) 2025年5月7日 09:39 (UTC)
关于“通用行为准则协调委员会”（U4C）候选人征集
关于“通用行为准则执行指南”和“通用行为准则协调委员会”（U4C）章程的投票结果已 在 Meta-wiki 上公布。
您现在可以通过 2025 年 5 月 29 日 12:00 UTC 前 提交您的 U4C 成员候选人资格。关于 资格、流程和时间表的信息可在 Meta-wiki 上找到。候选人投票将于 2025 年 6 月 1 日开始，持续两周，至 2025 年 6 月 15 日 12:00 UTC 结束。
如果您有任何疑问，可以 在选举讨论页上提问。-- 与 U4C 合作，
33,333 篇文章
带来一些稍显乐观的消息，我们终于以 Nassarawa 的创建达到了 33,333 篇文章。感谢所有为此做出贡献的人！//shb (t | c | m) 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 年会有 40,000 篇文章，中间的 35,000 篇文章也差不多是这个幅度。//shb (t | c | m) 2025年5月16日 09:54 (UTC)
- 我们有 36,00010 = splitposplit^split (10*10060)——这是一个相当圆的数字（并且在 一个重要的基数）——或 2⁵·3²·5³，即第一个质数（以任何基数）分别乘以前一个数字（带溢出旋转）。
- :-)
- –LPfi (讨论) 2025年5月16日 22:33 (UTC)
- 确实，这是本项目规模的另一个有价值的里程碑。//shb (t | c | m) 2025年5月19日 02:19 (UTC)
- 确实如此——但我也认为，这个项目的文章数量里程碑之间通常相隔数年，这也与此有关。我预计到 2034 年会有 40,000 篇文章，中间的 35,000 篇文章也差不多是这个幅度。//shb (t | c | m) 2025年5月16日 09:54 (UTC)
- 这个里程碑让我很高兴。 WhatamIdoing (讨论) 2025年5月17日 19:17 (UTC)
关于“抽象维基百科”（以及您的项目）的社群讨论正在进行中
（抱歉用英文发布，如果这不是您的母语）
大家好！我们在 Meta 上就“抽象维基百科”的开发启动了一个非常微妙的问题的讨论：存储通过 Wikifunctions 功能和 Wikidata 数据开发的抽象内容的位置。由于一些假设涉及到您的项目，我们也想听听您的想法。
我们希望使决策过程清晰：我们还不知道将使用哪种方案，因此我们在此进行咨询。我们将考虑来自维基媒体社区的论点，并希望与不同的社区进行协商，听取有助于我们做出决定的论点。基金会将在此咨询期结束后做出并传达决定。
您可以在 Abstract Wikipedia/Location of Abstract Content 阅读各种假设并发表您的意见。提前感谢！ -- Sannita (WMF) (讨论) 2025年5月22日 15:27 (UTC)
- @Sannita (WMF): 您能解释一下当您说“一些假设涉及到您的项目”时，这对 Wikivoyage 有何影响？谢谢，//shb (t | c | m) 2025年5月26日 02:28 (UTC)
- 提议的解决方案在多个地方提到了 Wikivoyages。主要问题是，关于某个地方的抽象文章在维基百科和 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 (t | c | m) 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 (t | c | m) 2025年5月26日 10:10 (UTC)
- 表示同意。我明白了。我们应该在单独的讨论串中讨论，看是鼓励、允许（或许不加评论）还是禁止在本网站上发布抽象列表。我认为我们可能不想要抽象文章，但我们也应该对此进行讨论。 Ikan Kekek (讨论) 2025年5月26日 12:22 (UTC)
- 至少对于这个网站来说，我认为抽象列表对于世界各地不太为人所知的地区来说是有用的，但总的来说，这似乎是帮助较小的语言 Wikivoyage 受益，而不是反之（这也很棒）。//shb (t | c | m) 2025年5月26日 13:30 (UTC)
- 我提到了列表，因为我们已经使用 Wikidata 来获取它们（坐标），并且已经讨论过例如营业时间（太复杂而无法实现）。我认为“抽象列表”目前不是一个选项——必须有人决定列表是想要的，并且在添加时会包含一些手动语言。我们仍然可能对如何——以及如何不——设计抽象 Wikivoyage 文章以使其有用方面获得一些有价值的见解。 --LPfi (讨论) 2025年5月26日 14:04 (UTC)
- 至少对于这个网站来说，我认为抽象列表对于世界各地不太为人所知的地区来说是有用的，但总的来说，这似乎是帮助较小的语言 Wikivoyage 受益，而不是反之（这也很棒）。//shb (t | c | m) 2025年5月26日 13:30 (UTC)
- 表示同意。我明白了。我们应该在单独的讨论串中讨论，看是鼓励、允许（或许不加评论）还是禁止在本网站上发布抽象列表。我认为我们可能不想要抽象文章，但我们也应该对此进行讨论。 Ikan Kekek (讨论) 2025年5月26日 12:22 (UTC)
- 听起来很完美。感谢你们两位解释！//shb (t | c | m) 2025年5月26日 10:10 (UTC)
- 我明白了——我仍然不明白这究竟会如何运作（即使阅读了假设之后），但我认为这对于较小的语言项目来说是有用的。//shb (t | c | m) 2025年5月26日 09:47 (UTC)
- 目前我们没有任何抽象文章，我猜想英语 Wikivoyage 可能永远不会有。但对于较小的语言来说，用适当的文章涵盖所有有趣的地方是不现实的。抽象维基百科的使命是提供一个创建文章的框架，允许自动翻译成至少半成品。这就像获取 Wikidata 的关键信息列表一样，但规模扩大到完整的文章（或者不那么完整——至少在可预见的未来，关于个人印象的生动语言肯定会缺失）。 --LPfi (讨论) 2025年5月26日 07:43 (UTC)
- 您能进一步解释一下 Wikivoyage 上是如何有抽象（与具体相对）文章的吗？ Ikan Kekek (讨论) 2025年5月26日 07:27 (UTC)
- 我有两个想法
- 我们需要一种方法来区分适用于维基百科的文本块和适用于 Wikivoyage（或其他姐妹项目）的文本块。这表明*不*应将英语维基百科作为所有内容的存储地。维基百科可能都想要“木星是太阳系中最大的行星。它是离太阳第五远的行星”，但如果 Wikivoyage 上有一篇关于这颗行星的文章，它听起来可能会更像是“木星并非一个宜居的目的地，但对 天文学 和 星际导航 感兴趣的旅行者可能会对木星大型博物馆和年度木星节感兴趣”。
- 我认为英语 Wikivoyage 可以从抽象内容中受益。很明显，我们可以将我们的 明星文章 “翻译”成抽象形式，这样其他 Wikivoyage 也会受益。但是，想象一下，如果 @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 的文章结构通常比维基百科更规范，我认为我们可以利用抽象 Wikivoyage。有两个领域看起来是可能的起点：列表和短语手册中的短语。
- 如果一个工具可以创建一个其他语言中存在的列表的抽象版本，那么在编辑此处同一部分的文章时就可以提供该列表——“您想添加一家割草机博物馆的列表吗？” 当在一个语言中编辑时，列表的某些部分可以在所有语言中更新——无论在哪个语言中编辑，我们都会显示博物馆的最后更新价格。一个困难的部分是识别列表元素何时是语言特定的——我们可以使用另一个 WV 的 URL 来指向一个英文页面，而我们并不关心博物馆是否有西班牙语翻译的标签。
- 在英语 WV 中，我们有一套标准的短语手册短语，大多数短语手册都严格遵循此列表。该列表也是一些其他语言 WV 中短语手册的基础。创建一个抽象的短语手册似乎相当简单，但需要审查不一致之处。英语中有大约 300 本短语手册，德语有 50 本，波兰语有 20 本。也许我们可以用它来为波兰语提供 200 多本短语手册。 AlasdairW (讨论) 2025年5月26日 22:44 (UTC)
- 对于列表，是的，抽象版本很容易创建。对于名称，我们只需要识别本地名称、其罗马化以及翻译名称的语言。Wikidata 中已经存在所有这些的结构；“官方网址”也有一个语言属性。酒店的设施也可以轻松描述。没有任何东西会被自动获取，所以不必担心对英语使用者不相关的信息。难以做到的是我上面链接的示例中的生动语言。
- 对于短语手册，我不确定是否如此简单，或者说创建一个抽象的短语手册与仅翻译模板并使用词典（或您以其他方式使用的任何翻译方法）相比是否有帮助。语法和发音部分需要根据听众的语言知识来编写，并且短语的翻译需要对上下文有一定的理解，因此大部分是手动的。对于一本好的短语手册，您还需要注意与目标语言相关的特殊性，例如现在添加到法语和意大利语短语手册中的 liberty/liberté 等，以及针对特定假朋友的警告。
- –LPfi (讨论) 2025年5月27日 04:57 (UTC)
- 我认为短语手册是（与旅行话题一起）不可能创建抽象版本的那些事物之一。//shb (t | c | m) 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 中尚无短语手册的一部分；但如果左侧不完全读起来，问题就更小了。我假设一个抽象的 Wikivoyage 会有一些处理引文的机制，因为这对于复制著名演讲等中使用的确切词语至关重要，并且对于抽象维基百科和维基语录等也是必需的。 AlasdairW (讨论) 2025年5月30日 14:06 (UTC)
- 马来语中有两个“请”字，意义和用法不同。还有两个“我们”字，含义也不同。等等。 Ikan Kekek (讨论) 2025年5月30日 09:34 (UTC)
- 对于芬兰语，没有表示礼貌的词语或短语，但人们经常使用条件式（？）动词形式。在某些情况下，人们会在短语中使用该词形（在芬兰语短语手册和芬兰语的短语手册中）——但这又回到了没有礼貌标记的问题，这在该语言中很常见。像“你是否可以”这样的短语很麻烦，因为大多数语言在“你”和“您”之间有区别。我认为常见情况可以很好地处理，但对于不太为人所知的语系——那些最受益于抽象文章的语系——边缘情况会更常见。抽象短语手册可能需要为特定语言进行调整，以避免出现非常麻烦的渲染的奇怪情况。 --LPfi (讨论) 2025年5月28日 06:02 (UTC)
- @WhatamIdoing：LPfi 基本上解释了我为什么认为抽象短语手册行不通。//shb (t | c | m) 2025年5月27日 23:25 (UTC)
- 我认为短语手册是（与旅行话题一起）不可能创建抽象版本的那些事物之一。//shb (t | c | m) 2025年5月27日 05:23 (UTC)
- 提议的解决方案在多个地方提到了 Wikivoyages。主要问题是，关于某个地方的抽象文章在维基百科和 Wikivoyage 上不应以相同的方式渲染。这也会影响技术方案，例如存储陈述和函数的地点。 --LPfi (讨论) 2025年5月26日 07:21 (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
董事会与选举委员会的联络员
治理委员会
FYI: 计划旅行？AI 会为您搞定
https://www.thrillist.com/travel/nation/ai-travel-apps —Justin (koavf)❤T☮C☺M☯ 2025年6月1日 07:04 (UTC)
- 我想知道我们是否可以设计一个 AI 工具，它可以从 Wikivoyage 获取信息并为您提供摘要。这可以取代 Wikivoyager 手动撰写摘要的负担。当然，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 (t | c | m) 03:13, 14 June 2025 (UTC)
Commons RFD 通知
虽然通知图片即将被删除的 Commons 机器人 已恢复运行，但仍有图片在未通知的情况下被删除，我猜测是那些（我猜）在 5 月 4 日之前提名的图片。问题在已链接的公告中说明了，但我没有意识到其影响。所以，预计有些图片将被删除而没有收到通知。如果它们可能很有价值，应该暂时恢复以便本地上传，就像机器人停止工作时那样。–LPfi （讨论） 11:51, 13 June 2025 (UTC)
2025 年维基媒体基金会理事会 - 候选人征集
大家好，
2025 年维基媒体基金会理事会选举的候选人征集现已开放，时间为 2025 年 6 月 17 日至 7 月 2 日，截止至 UTC 时间 11:59 [1]。理事会负责监督维基媒体基金会的工作，每位理事任期三年 [2]。这是一个志愿职位。
今年，维基媒体社区将在 2025 年 8 月下旬至 9 月期间投票，以填补基金会理事会中的两个（2）席位。您，或者您认识的人，是否适合加入维基媒体基金会理事会？[3]
请访问此 Meta-wiki 页面，了解担任这些领导职位所需的条件以及如何提交您的候选资格，或鼓励他人参加今年的选举。
此致，
Abhishek Suryawanshi
选举委员会主席
代表选举委员会和治理委员会
[2] https://foundation.wikimedia.org/wiki/Legal:Bylaws#(B)_Term。
姐妹项目特别工作组审查 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 代表姐妹项目特别工作组, 20:57, 27 June 2025 (UTC)
- 我实在不愿说，但 Wikinews 绝对是 WMF 最失败的项目之一。英语 Wikinews 勉强维持，我认为目前就这样挺好，但其他 Wikinews 项目的编辑基础 simplesmente 无法积极审查新闻文章。在 tawikinews 的关闭提案中就提到了这一点，其最新文章日期是 2018 年！//shb (t | c | m) 02:56, 28 June 2025 (UTC)
- 我认为我们应该把那种东西发布在 Meta-Wiki 的项目页面上：关于 Wikispore 的公开咨询和关于 Wikinews 的公开咨询。WhatamIdoing （讨论） 22:42, 28 June 2025 (UTC)
- 我知道；我只是想简短地表达一下我的观点——我有一份更长的建议列表，等我有更多空闲时间时会做的。//shb (t | c | m) 23:44, 28 June 2025 (UTC)
- 我认为我们应该把那种东西发布在 Meta-Wiki 的项目页面上：关于 Wikispore 的公开咨询和关于 Wikinews 的公开咨询。WhatamIdoing （讨论） 22:42, 28 June 2025 (UTC)
一般性担忧
我不喜欢 Wikinews，但关于姐妹项目特别工作组发布的报告有一点令人担忧。这份报告的措辞非常批评性，特别是，它没有提到数十甚至数百名志愿者花费了大量时间来开发 Wikinews。报告没有提及他们工作的任何一点好，这似乎不公平。报告表明 Wikinews 的当前活动水平和内容开发水平很低（这个陈述是公平的），但它没有设定任何门槛来衡量一个社区是否值得 WMF 的资源。此外，报告没有试图分析 Wikinews 编辑者为发展他们的项目采取了哪些步骤，以及为什么这些步骤不成功。它只是说：你们做得不好，所以我们要关闭你们，甚至剥夺你们将 Wikinews 迁移到其他地方的可能性，因为这个名字仍然属于维基媒体基金会。
Wikivoyage 也是一个较小的项目，如果出现一份类似批评我们工作的报告，那将是令人沮丧的。当一半的语言版本处于休眠状态，而许多其他版本的指标与最活跃的 Wikinews 版本相当时，这并非完全不现实。我认为只有英语 Wikivoyage 明确高于这个阈值，尽管实际阈值甚至没有定义，所以如果有人想这么说，几乎任何活动水平都可以被视为“低”。
你们怎么看？--Alexander （讨论） 09:53, 28 June 2025 (UTC)
- 我没有使用过 Wikinews，所以我的看法基于瑞典语 Wikinews 的关闭以及上面链接的当前讨论。讨论中提出的一点是，所选的指标没有考虑到项目的特殊性质。
- 我假设姐妹项目特别工作组在进行此类评估时是正确的，但我也认为评估应该侧重于是否存在前进的道路，而不是项目是否根据当前趋势可行。
- Wikinews 的问题在于需要一个规模可观的专门编辑团队——维基百科甚至 Wikivoyage 即使一年或两年没有编辑也能保持活力和有趣，而新闻媒体将失去几乎所有的读者。报道必须在至少某些领域（地理或主题）足够充分，以保持网站的吸引力。所需的临界质量要大得多——并且该临界质量还必须能够抵御有偏见（善意或恶意）或议程与项目目标不符的人——阻止捣乱者要容易得多。我认为只有在有希望快速建立起这种临界质量的情况下，才应该启动新的语言版本。
- –LPfi （讨论） 10:36, 28 June 2025 (UTC)
- 是的，我相信 LangCom 已经决定为此原因暂停创建所有新的 Wikinews 项目。//shb (t | c | m) 23:46, 28 June 2025 (UTC)
- Alexander，诚然“数十甚至数百名志愿者投入了大量时间来开发 Wikinews”，但因为过去的努力而维持一个失败的项目是沉没成本谬误的一个例子。
- 我怀疑，如果有人提出一个可信的提议将 Wikinews 迁移到另一个主机，WMF 会乐于就名称进行谈判。（但任何新的赞助商可能更愿意使用自己的名称。）WhatamIdoing （讨论） 03:31, 29 June 2025 (UTC)
- 我猜我的主要问题是缺乏任何明确定义的标准来区分一个可持续的项目和一个失败的项目。你们明白这些标准是什么吗？-- Alexander （讨论） 08:35, 29 June 2025 (UTC)
- 一个明确定义可持续项目的标准仍然很大程度上取决于项目的功能。对于 Wikinews 来说，它需要非常活跃，而适用于 Wikivoyage 或 Wikibooks 的指标，例如文章数量，并不那么重要，因为 20000 篇文章如果最后一篇是两个月前写的就没有意义了（数字是假设的，但我的观点成立）。//shb (t | c | m) 08:50, 29 June 2025 (UTC)
- 我同意不能将相同的指标应用于所有姐妹项目，但“非常活跃”留下了很大的解释空间。想象一下，有人认为 Wikivoyage 不可持续，因为它包含大量在过去 5 年未更新的过时旅行信息。这将是一个问题…… -- Alexander （讨论） 09:27, 29 June 2025 (UTC)
- 我们不需要明确的指标。需要对项目的实际前景进行判断。开放社区讨论是好的，因为这是查看指标是否提供准确图景的一种方式——尽管在开放此类讨论之前应该与项目进行讨论（我不知道在多大程度上进行了这些讨论）。–LPfi （讨论） 20:13, 29 June 2025 (UTC)
- 是的。问题应该首先与项目（不仅是大项目，而是所有受影响的项目）进行沟通；我不知道是否做到了，但显然做得不够，总之。似乎 SPTF（？）想要引入一种更普遍的项目重新评估做法，并选择了这两个作为例子。他们应该明白，如果不进行协商，这样做会激怒人们。//shb (t | c | m) 23:01, 29 June 2025 (UTC)
- 平心而论，之前有过几次关闭提案，包括一项针对所有主流语言 Wikinews 的提案。对于主流项目，那些提案失败了，但有人认为这是向社区发出信号，要求他们评估自己的表现，但他们显然没有得到。不过，我同意在首先通知 Wikinews 社区之前就开启此类讨论不是很好。–LPfi （讨论） 06:40, 30 June 2025 (UTC)
- 平心而论，之前有过几次关闭提案，包括一项针对所有主流语言 Wikinews 的提案。对于主流项目，那些提案失败了，但有人认为这是向社区发出信号，要求他们评估自己的表现，但他们显然没有得到。不过，我同意在首先通知 Wikinews 社区之前就开启此类讨论不是很好。 Ymblanter （讨论） 08:54, 30 June 2025 (UTC)
- 他们确实应该这样做；我希望他们能从中吸取教训，因为来自 enwikinews 社区的普遍情绪在这次讨论中非常不满。//shb (t | c | m) 09:01, 30 June 2025 (UTC)
- 好吧，这个评论肯定已经过时了。//shb (t | c | m) 13:59, 30 June 2025 (UTC)
- 哦，天哪。我希望 SPTF 中还有其他人更善于倾听。这可能会沦为又一次 WMF 不尊重社区的事件。–LPfi （讨论） 08:40, 1 July 2025 (UTC)
- SPTF（至少 Victoria）似乎如此预先决定要关闭 Wikinews，我从未听说过如此明目张胆的偏见，例如“然而，我预计 wikinewsians 会有利益冲突”——所以对他们来说，了解自己项目的内幕似乎是利益冲突？这对非维基百科项目来说是巨大的侮辱。//shb (t | c | m) 11:04, 1 July 2025 (UTC)
- 我能理解她的观点，但我认为这是错误的，她团队中的某个人应该让他们讨论他们的实际使命。如果一个项目确实需要终止，那么这个过程需要非常谨慎地进行——并且在这个阶段的磋商不应该是关于是否终止 Wikinews。它应该是“为了试验和演示审查过程”、“社区重新评估”和“潜在的重组工作”。
- 对过程的演示是一场灾难，而潜在的重组工作需要对项目有良好的理解，而没有与社区进行敏锐的讨论是无法获得的。
- “重新评估”应该基于这样的潜在重组路径，即重组不是关于将 Wikinews 内容放到哪里，而是关于如何拯救这个项目，如果可能的话。
- –LPfi （讨论） 13:13, 1 July 2025 (UTC)
- 我完全同意你关于“重新评估”的看法，但他们对社区反馈的响应方式让人觉得他们已经预设了结果，而这仅仅被用作一项勾选工作的理由——这就是为什么我认为我们作为一个姐妹项目，就这一处理不当的方式发表意见至关重要，因为谁知道当轮到我们进行公开磋商时，他们会怎么做。//shb (t | c | m) 14:04, 1 July 2025 (UTC)
- 我在meta:Talk:Public consultation about Wikinews#Process and analysis seem flawed 中写了一些担忧。–LPfi （讨论） 21:34, 1 July 2025 (UTC)
- 谢谢你，LPfi；希望我们的项目会没事的（我认为会，因为 Wikivoyage 或任何其他 WMF 项目不像 Wikinews 那样需要活跃的社区），但更多的反馈当然更好。//shb (t | c | m) 03:49, 2 July 2025 (UTC)
- 虽然我同意这个过程在某种程度上是有缺陷的（并且我同意 LPfi 在 Meta 上的回应中的观点），但看看用于分析的某些指标（无论多么有缺陷）是否可以改进 Wikivoyage，以便它们不再是讨论的焦点，这将是有益的。 Ymblanter （讨论） 08:18, 2 July 2025 (UTC)
- @Victoria：作为主要作者，以及对于我认为非常尖锐的反馈：鉴于该特别工作组正在评估姐妹项目，让各个社区了解用于评估其健康状况的评分标准将是有帮助的。 —Justin (koavf)❤T☮C☺M☯ 19:55, 2 July 2025 (UTC)
- 首先，特别工作组并不是在评估所有姐妹项目，Wikispore/Wikinews 是一个概念验证练习。
- 我们使用了此评分标准，该标准在一年前的公开磋商中已讨论过——但没有引起太多关注，因为 Meta 上充斥着从未实施的文件。
- 在Wikispore 磋商中，我们请求关于“活动”和其他标准的澄清建议。Victoria （讨论） 09:11, 3 July 2025 (UTC)
- 谢谢您，也谢谢您让我能在各个 WMF 项目中来回 ping 您。—Justin (koavf)❤T☮C☺M☯ 09:38, 3 July 2025 (UTC)
- 不客气。我很乐意用英语/俄语/白俄罗斯语回答，只要没有涉及人身攻击。Victoria （讨论） 10:15, 3 July 2025 (UTC)
- 谢谢您，也谢谢您让我能在各个 WMF 项目中来回 ping 您。—Justin (koavf)❤T☮C☺M☯ 09:38, 3 July 2025 (UTC)
- @Victoria：作为主要作者，以及对于我认为非常尖锐的反馈：鉴于该特别工作组正在评估姐妹项目，让各个社区了解用于评估其健康状况的评分标准将是有帮助的。 —Justin (koavf)❤T☮C☺M☯ 19:55, 2 July 2025 (UTC)
- 虽然我同意这个过程在某种程度上是有缺陷的（并且我同意 LPfi 在 Meta 上的回应中的观点），但看看用于分析的某些指标（无论多么有缺陷）是否可以改进 Wikivoyage，以便它们不再是讨论的焦点，这将是有益的。 Ymblanter （讨论） 08:18, 2 July 2025 (UTC)
- 谢谢你，LPfi；希望我们的项目会没事的（我认为会，因为 Wikivoyage 或任何其他 WMF 项目不像 Wikinews 那样需要活跃的社区），但更多的反馈当然更好。//shb (t | c | m) 03:49, 2 July 2025 (UTC)
- 我在meta:Talk:Public consultation about Wikinews#Process and analysis seem flawed 中写了一些担忧。–LPfi （讨论） 21:34, 1 July 2025 (UTC)
- 我完全同意你关于“重新评估”的看法，但他们对社区反馈的响应方式让人觉得他们已经预设了结果，而这仅仅被用作一项勾选工作的理由——这就是为什么我认为我们作为一个姐妹项目，就这一处理不当的方式发表意见至关重要，因为谁知道当轮到我们进行公开磋商时，他们会怎么做。//shb (t | c | m) 14:04, 1 July 2025 (UTC)
- SPTF（至少 Victoria）似乎如此预先决定要关闭 Wikinews，我从未听说过如此明目张胆的偏见，例如“然而，我预计 wikinewsians 会有利益冲突”——所以对他们来说，了解自己项目的内幕似乎是利益冲突？这对非维基百科项目来说是巨大的侮辱。//shb (t | c | m) 11:04, 1 July 2025 (UTC)
- 哦，天哪。我希望 SPTF 中还有其他人更善于倾听。这可能会沦为又一次 WMF 不尊重社区的事件。–LPfi （讨论） 08:40, 1 July 2025 (UTC)
- 好吧，这个评论肯定已经过时了。//shb (t | c | m) 13:59, 30 June 2025 (UTC)
- 平心而论，之前有过几次关闭提案，包括一项针对所有主流语言 Wikinews 的提案。对于主流项目，那些提案失败了，但有人认为这是向社区发出信号，要求他们评估自己的表现，但他们显然没有得到。不过，我同意在首先通知 Wikinews 社区之前就开启此类讨论不是很好。–LPfi （讨论） 06:40, 30 June 2025 (UTC)
- 是的。问题应该首先与项目（不仅是大项目，而是所有受影响的项目）进行沟通；我不知道是否做到了，但显然做得不够，总之。似乎 SPTF（？）想要引入一种更普遍的项目重新评估做法，并选择了这两个作为例子。他们应该明白，如果不进行协商，这样做会激怒人们。//shb (t | c | m) 23:01, 29 June 2025 (UTC)
- 我一直在查看一些统计数据，“非常活跃”是一个有趣的点。认为“非常活跃”的 Wikinews 语言版本支持者绝大多数都从事着从许可适当的外部网站复制/粘贴内容的工作。他们把 Wikinews 变成了其他网站的镜像，而不是撰写文章。
- 想象一下，如果我们 Wikivoyage 的人说“我是一名非常活跃的 Wikivoyage 编辑。我每天花至少一个小时从其他旅行网站复制粘贴页面！”我们会作何反应？WhatamIdoing （讨论） 21:34, 2 July 2025 (UTC)
- 我们确实从酒店网站和其他来源复制信息，但我们没有可靠的、用我们风格写的免费内容。作为一个可靠的新闻频道*可能*是 Wikinews 的使命（与一些“社交媒体”网站的运作方式大致相同）。如果是这样，问题在于它们能否做得足够好，以至于值得作为 WMF 的项目（以及它们所做的其他事情是否做得好）。但 SPTF 并没有发起这样的讨论，他们选择用统计数据来衡量。–LPfi （讨论） 22:12, 2 July 2025 (UTC)
- 曾有人提到统计数据可能被机器人歪曲——我仍然不明白你们如何能分辨统计数据是否被机器人歪曲。//shb (t | c | m) 23:11, 2 July 2025 (UTC)
- 大多数机器人，尤其是大型机器人，在其页面请求中都有适当的用户代理字段，因此服务器日志可以用来区分至少那些机器人。通过更高级的技术，您还可以区分典型的机器人行为和人类用户的行为。有一些灰色地带（例如，人类使用非典型网络浏览器的工具，或通过浏览器使用某些脚本，以及配置成看起来像人类的机器人），但我认为不可能获得一个非常准确可靠的机器人与人类流量的图景。–LPfi （讨论） 10:37, 3 July 2025 (UTC)
- 非常有趣——我猜你可以通过像页面浏览量突然增加这样的事情来判断，但是的，除非你告诉我，否则我无法特别分辨出来。//shb (t | c | m) 10:42, 3 July 2025 (UTC)
- 从汇总数据来看，可以识别出一些可疑的机器人活动模式，但要确定，你必须检查用户代理字段，并且当普通用户代理引起机器人般的模式时，你必须分析单个流量源的行为——如果有人真的试图将他们的机器人伪装成多个用户来隐藏，那并非易事。–LPfi （讨论） 10:54, 3 July 2025 (UTC)
- 非常有趣——我猜你可以通过像页面浏览量突然增加这样的事情来判断，但是的，除非你告诉我，否则我无法特别分辨出来。//shb (t | c | m) 10:42, 3 July 2025 (UTC)
- 大多数机器人，尤其是大型机器人，在其页面请求中都有适当的用户代理字段，因此服务器日志可以用来区分至少那些机器人。通过更高级的技术，您还可以区分典型的机器人行为和人类用户的行为。有一些灰色地带（例如，人类使用非典型网络浏览器的工具，或通过浏览器使用某些脚本，以及配置成看起来像人类的机器人），但我认为不可能获得一个非常准确可靠的机器人与人类流量的图景。–LPfi （讨论） 10:37, 3 July 2025 (UTC)
- LPfi，我不是在谈论复制“信息”；我是在谈论逐字复制整个页面。
- 我们*确实*有可复制的选项；有多个旅行网站拥有适当的版权许可。你知道如果有人决定通过从 Wikitravel 复制来“帮忙”会发生什么。看看https://travel.fandom.com/wiki/Travel_Wiki，其页面风格相似但标题不同。WhatamIdoing （讨论） 17:39, 3 July 2025 (UTC)
- 曾有人提到统计数据可能被机器人歪曲——我仍然不明白你们如何能分辨统计数据是否被机器人歪曲。//shb (t | c | m) 23:11, 2 July 2025 (UTC)
- 我们确实从酒店网站和其他来源复制信息，但我们没有可靠的、用我们风格写的免费内容。作为一个可靠的新闻频道*可能*是 Wikinews 的使命（与一些“社交媒体”网站的运作方式大致相同）。如果是这样，问题在于它们能否做得足够好，以至于值得作为 WMF 的项目（以及它们所做的其他事情是否做得好）。但 SPTF 并没有发起这样的讨论，他们选择用统计数据来衡量。–LPfi （讨论） 22:12, 2 July 2025 (UTC)
- 我们不需要明确的指标。需要对项目的实际前景进行判断。开放社区讨论是好的，因为这是查看指标是否提供准确图景的一种方式——尽管在开放此类讨论之前应该与项目进行讨论（我不知道在多大程度上进行了这些讨论）。–LPfi （讨论） 20:13, 29 June 2025 (UTC)
- 我同意不能将相同的指标应用于所有姐妹项目，但“非常活跃”留下了很大的解释空间。想象一下，有人认为 Wikivoyage 不可持续，因为它包含大量在过去 5 年未更新的过时旅行信息。这将是一个问题…… -- Alexander （讨论） 09:27, 29 June 2025 (UTC)
- 一个明确定义可持续项目的标准仍然很大程度上取决于项目的功能。对于 Wikinews 来说，它需要非常活跃，而适用于 Wikivoyage 或 Wikibooks 的指标，例如文章数量，并不那么重要，因为 20000 篇文章如果最后一篇是两个月前写的就没有意义了（数字是假设的，但我的观点成立）。//shb (t | c | m) 08:50, 29 June 2025 (UTC)
- 我猜我的主要问题是缺乏任何明确定义的标准来区分一个可持续的项目和一个失败的项目。你们明白这些标准是什么吗？-- Alexander （讨论） 08:35, 29 June 2025 (UTC)
评论请求通知
请注意，Meta 上有一项关于有偿编辑和高级权限的评论请求，网址为 m:Requests for comment/Should paid editing as a CU be allowed。您可以就该主题发表您的担忧。
此消息用于通知那些尚未在此 RFC 中发表评论的人。对于已经发表评论的人，您可以忽略此消息。
请勿回复此消息。 〈兴华街〉📅❓ 08:43, 4 July 2025 (UTC)
- @HingWahStreet: 我不认为这与本项目相关；任何语言的Wikivoyage项目都没有 CU（Checkuser，管理员）的权限，这 matters (不重要)。 //shb (t | c | m) 2025年7月4日09:11 (UTC)
- @SHB2000 抱歉，我不知道这件事。 〈兴华街〉📅❓ 2025年7月4日09:45 (UTC)
- @HingWahStreet: 我之所以问，是因为您只在此项目上留言（根据GUC检查）——我明白您是想发送给所有项目（我也不会这样做，但我谁又来阻止您呢），但您唯一发送到的项目甚至没有 CU。 //shb (t | c | m) 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)
- @SHB2000 您的意思是只有 CU（管理员）可以加入讨论吗？ 〈兴华街〉📅❓ 2025年7月4日13:36 (UTC)
- @HingWahStreet: 我之所以问，是因为您只在此项目上留言（根据GUC检查）——我明白您是想发送给所有项目（我也不会这样做，但我谁又来阻止您呢），但您唯一发送到的项目甚至没有 CU。 //shb (t | c | m) 2025年7月4日09:52 (UTC)
- @SHB2000 抱歉，我不知道这件事。 〈兴华街〉📅❓ 2025年7月4日09:45 (UTC)
- 事情是这样的：在一个小型维基百科上，一位 CU（管理员）最近成立了一家公司来撰写维基百科文章。这让一些人突然意识到 CU（管理员）并没有被正式禁止成为“付费编辑”。他们建议禁止 CU（管理员）从事某些付费编辑工作（例如为公司撰写文章），但不禁止从事其他工作（例如为艺术博物馆撰写文章）。
- 我怀疑这会对我们产生任何影响，我也怀疑这会对整体产生多大影响。 WhatamIdoing (讨论) 2025年7月4日16:48 (UTC)
- 我可能是错的，但我认为 HingwahStreet 也与 Bojan（涉及付费编辑的 srwiki CU（管理员））有过一些历史（这不影响此 RfC 的结果）。 //shb (t | c | m) 2025年7月4日23:01 (UTC)
- 为你节省一次点击：CU == Checkuser（检查用户） Brycehughes (讨论) 2025年7月7日18:29 (UTC)
- 但是等等，检查用户（checkuser）到底是什么？ Brycehughes (讨论) 2025年7月7日18:37 (UTC)
- Checkusers（检查用户）是某些维基上的一个小团队，他们拥有可以揭示用户IP地址信息的工具。我们还没有发现需要任命任何人的必要。 AlasdairW (讨论) 2025年7月7日21:12 (UTC)
- 有一种观点认为，这个维基可以有 CU（管理员），并且这样做有益处，但作为自 2022 年以来负责此维基所有 SRCU（Superuser Request for Checkuser，管理员请求检查用户）请求的人，我认为目前由管理员执行我们的 CU（管理员）检查就足够了。 //shb (t | c | m) 2025年7月8日08:58 (UTC)
- m:CheckUser。—Justin (koavf)❤T☮C☺M☯ 2025年7月7日22:03 (UTC)
- Checkusers（检查用户）是某些维基上的一个小团队，他们拥有可以揭示用户IP地址信息的工具。我们还没有发现需要任命任何人的必要。 AlasdairW (讨论) 2025年7月7日21:12 (UTC)
- 但是等等，检查用户（checkuser）到底是什么？ Brycehughes (讨论) 2025年7月7日18:37 (UTC)
英国法律与维基媒体基金会的挑战
EFF 关于挑战《在线安全法案》。这将对我们产生影响。 Pashley (讨论) 2025年7月18日03:51 (UTC)
U4C（通用行为准则协调委员会）征集非投票候选人
通用行为准则协调委员会（U4C）最近发布了一项公告，征集对成为非投票成员感兴趣的人。通过去年的年度审查，社区批准任命最多 4 名非投票成员，U4C 现在已经创建了一个地点和流程供志愿者表达兴趣。如果您知道任何可能感兴趣的人，请告诉他们。如果您有任何问题，请随时提问（或在此处问我）。祝好，Barkeep49 (讨论) 2025年8月2日21:15 (UTC)
- @Barkeep49，非投票成员的目的是填补投票成员的技能空白。是否有已知差距的列表？ WhatamIdoing (讨论) 2025年8月3日16:52 (UTC)
- 不是的。目前有 3 个地区席位空缺：拉丁美洲和加勒比地区、中东欧（CEE）和撒哈拉以南非洲。还有一些明显的模式，包括 7/8 的主要项目是维基百科（第 8 个是 Wikidata），这就是我在这里发帖以及所用语言的原因。祝好，Barkeep49 (讨论) 2025年8月3日20:34 (UTC)
Wikivoyage 和附近文章地图
您如何使用“附近”功能（主要是维基百科应用程序中的那个）？
它仍然显示各种与旅行者无关的文章，例如墓地、学校、火车站等，所以我想知道为什么似乎没有人对此有问题，为什么似乎很少有 Wikivoyage 用户参与该地图，尽管它对于假期/探索地点/ Wikivoyage 相关事务可能非常有用。也许这里的人使用其他东西，或者有一些技巧可以让“附近”地图在实际场景中有用，或者有相关的讨论。 Prototyperspective (讨论) 2025年7月27日21:10 (UTC)
- 我认为这只是我们很多人都忘记了的功能，因为它是一个不常被谈论的功能。 //shb (t | c | m) 2025年7月28日00:14 (UTC)
- 我刚试了一下，工作正常，没有问题，但如果它有缺陷，我也愿意改进。这是读者比编辑者使用更多的功能之一。 --评论来自 Selfie City (讨论) (贡献) 2025年7月28日01:07 (UTC)
- 我也忘了它的存在。 Ikan Kekek (讨论) 2025年7月28日01:19 (UTC)
- 您是在实际场景中试过，还是只是在家测试？
- 我问是因为 phab:T360197 没有参与，而这个功能似乎具有巨大的潜力——特别是对于 Wikivoyage 相关的事项，例如度假——在这种情况下，在大多数情况下似乎都需要进行一些更改才能使其在实际应用中真正有用。
- 请参见 meta:Community Wishlist/Wishes/Filters for types of items shown on the Wikipedia app Nearby places map。我无法使用此功能来探索地点，除非是在地图上几乎没有文章的偏远地区。
- 最后，我不知道为什么 Wikivoyage 会广泛遗忘这个功能——它似乎是 THE Wikivoyage 功能，例如维基百科应用程序中的该功能，大多数人可能会通过它第一次了解和使用 Wikivoyage。 Prototyperspective (讨论) 2025年7月28日11:19 (UTC)
- 我倒是认为，这是因为您无法在桌面端“真正”使用它，而桌面端是大部分编辑发生的地方。移动端的 Wikivoyage，这个功能最有用，但它很糟糕，所以我们很多人都忘记了它的存在。 //shb (t | c | m) 2025年7月28日23:37 (UTC)
- 它在移动应用程序中可用。由于那里的地图比桌面版本要先进得多，在桌面版本中甚至没有地图或输入框来输入位置，我指的是移动应用程序中的“附近”功能。（顺便说一句，我认为我在哪里读到过有关 Wikivoyage 移动应用程序的提议。） Prototyperspective (讨论) 2025年7月28日23:41 (UTC)
- 很遗憾，截至目前 Wikivoyage 还没有移动应用程序。 :(< //shb (t | c | m) 2025年7月29日00:51 (UTC)
- 是的，我指的是
我读到某个地方有关于 Wikivoyage 移动应用程序的提议
。通过它在移动应用程序中可用
，我指的是维基百科应用程序，我在之前的评论中已经提到了。 Prototyperspective (讨论) 2025年7月30日11:25 (UTC)
- 是的，我指的是
- 很遗憾，截至目前 Wikivoyage 还没有移动应用程序。 :(< //shb (t | c | m) 2025年7月29日00:51 (UTC)
- 它在移动应用程序中可用。由于那里的地图比桌面版本要先进得多，在桌面版本中甚至没有地图或输入框来输入位置，我指的是移动应用程序中的“附近”功能。（顺便说一句，我认为我在哪里读到过有关 Wikivoyage 移动应用程序的提议。） Prototyperspective (讨论) 2025年7月28日23:41 (UTC)
- 我倒是认为，这是因为您无法在桌面端“真正”使用它，而桌面端是大部分编辑发生的地方。移动端的 Wikivoyage，这个功能最有用，但它很糟糕，所以我们很多人都忘记了它的存在。 //shb (t | c | m) 2025年7月28日23:37 (UTC)
- 我刚试了一下，工作正常，没有问题，但如果它有缺陷，我也愿意改进。这是读者比编辑者使用更多的功能之一。 --评论来自 Selfie City (讨论) (贡献) 2025年7月28日01:07 (UTC)
- 我强烈反对“火车站……与旅行者无关”，而且我碰巧喜欢参观古老的墓地。也许我们需要过滤器，但要弄清楚包含或排除什么可能很困难。 WhatamIdoing (讨论) 2025年7月28日15:08 (UTC)
- 这是为了让用户能够配置它。火车站显然对许多旅行者来说都非常重要。 Prototyperspective (讨论) 2025年7月28日16:01 (UTC)
- 不错的功能，但有办法将其集成到 WV 中吗，还是必须使用 WP（维基百科）应用程序？我实际上正在考虑发明类似的东西——基本上是抓取附近的文章，获取它们的所有列表，并在地图上显示，理想情况下按 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）。它不显示地图，只显示文章列表，这实际上没什么用。此外，Wikivoyage 中的版本仅显示 WV 中的页面，而维基百科中的版本仅显示 WP 中的文章，但我认为它应该两者都显示（如果它们是关于同一个地方，那么点击时会出现一个点，让您选择打开哪一个）。理想情况下按 WP（维基百科）浏览量排序
我将编辑 phab:T360197 以添加页面视图作为另一个使用项为了能够排除低重要性文章，将使用相关 WikiProjects 的文章重要性评级
，我从这一点得到的想法是，不仅以这种方式过滤它们，而且根据评级和/或页面视图以不同的方式显示它们，例如，那些页面视图相对较多的显示为更大的点或不同颜色的点。 Prototyperspective (讨论) 2025年7月30日14:32 (UTC)- 我认为仅考虑文章不足以用于 WV（Wikivoyage），仅添加 WP（维基百科）内容也同样如此（许多文章要么仅是当地语言版本，而在 en（英文版）上未涵盖，要么在很大程度上符合Wikivoyage:Listings#Boring_places，战争事件地点等）；此外，尤其是偏远地区的有时有 10 个列表，例如只有一个在 WP（维基百科）上……因此，我认为需要某种混合操作，以便能够找到“附近最好的列表”。
- 至于地图，您可以通过动态地图底部相应的按钮显示——andree 2025年7月30日18:41 (UTC)
- 这取决于地区。在许多情况下，例如大城市，都有最著名景点和公园等文章。地图不会在那里显示用户可能感兴趣的所有地方，也不期望它这样做。（Wikivoyage 可以让地图更接近这一点。）它不一定是为了“找到附近最好的列表”，还包括例如“了解您现在所在地的维基百科更多信息”、“找到附近一个不错的地点”以及“找到附近一些有趣的地点供考虑”。
- -
- 我不太确定您的意思——我建议将用户语言的维基百科文章与 Wikivoyage 列表结合起来。是的，理想情况下，还可以添加该地区母语的文章。应用程序中可以提供的一种特殊功能是通过MinT进行机器翻译，这样就不会是胡言乱语，但对于不说该地区语言的应用程序用户来说，是可以理解的。
- 地图没有显示 Wikivoyage + 维基百科项目。首先，它仅在访问某个地点的 WV（Wikivoyage）页面然后打开其地图时才有效。例如，当您访问一个没有 WV（Wikivoyage）页面的地区时，这就不起作用。点击“显示附近文章”时，它只显示非常少的文章，而不是维基百科中的所有文章，我不知道为什么。 Prototyperspective (讨论) 2025年7月30日23:19 (UTC)
我在内罗毕参加 Wikimania 的时候测试了一下。附近页面只显示内罗毕和Wikimania 2025 Nairobi Guidebook。在我看来，这个功能应该扩大半径，因为它目前没什么用。 OhanaUnited讨论页 2025年8月6日13:27 (UTC)
WV（Wikivoyage）是否需要关于在世人物描述的政策？
Wikivoyage 是一个旅行指南，并非旨在收集传记。尽管如此，旅行主题和行程可能会提到重要人物，例如探险家、艺术家、君主和政治家。 Wikivoyage:What is an article? 阻止创建关于在世名人的文章，因为这些文章比关于克里斯托弗·哥伦布、弗兰克·劳埃德·赖特或阿斯特丽德·林德格伦的文章更难完成。诸如美国总统和英国君主制的文章描述了仍在职业生涯中的在世人物，并且肯定存在争议。在撰写犹太斯德哥尔摩之旅、斯德哥尔摩环保主义者之旅和北欧君主制时，我想到了几个著名的在世人物，但我发现最好尽量简短地提及他们。我们应该遵循哪些一般原则？ /Yvwv (讨论) 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 (讨论) 2025年6月9日20:36 (UTC)
- 我支持这项政策，原因与此相同。 //shb (t | c | m) 2025年6月11日11:40 (UTC)
- 我认为这在很大程度上与旅行指南关系不大，但“星空地图”或洛杉矶地区名人故居之旅是很常见的，在我看来这完全是疯狂的，是应被 the City Council 谴责的行为。考虑到 Whatamidoing 关于 WMF 鼓励这种文件的观点，我认为制定指导方针/政策是明智的。想得好。—Justin (koavf)❤T☮C☺M☯ 2025年6月9日21:00 (UTC)
- 是的，我绝对反对为带人们去他们宁愿保持隐私的名人住所旅游创建文章。如果纽约有这种旅游，纽约人会为此大发雷霆，并敦促市议会通过相关法律。 Ikan Kekek (讨论) 2025年6月9日21:35 (UTC)
- 页面和关于照片的部分说得很少，主要是不鼓励拍摄自己的照片，这与我们要讨论的无关。说得更多，并且可能也应该遵循本地上传的图片。这三者都没有关于人物文本的内容（除了说明题词不应诽谤）。
- 我认为我们可能不应该制定政策，除非出现实际问题。我们没有理由写关于大多数人的内容，而且似乎常识，就像 Yvwv 上面展示的那样，效果相当好。制定政策会留下漏洞和法律条文。 （法律术语）。
- –LPfi (讨论) 2025年6月9日21:50 (UTC)
- 我想我们的“BLP（在世人物）政策”可以是我们现有 Wikivoyage:Be fair 政策的一个部分。基本上，是一些关于避免提及个人，尤其是避免说任何有争议或不公平侵犯他们隐私的事情的原则。 WhatamIdoing (讨论) 2025年6月10日16:40 (UTC)
- 这听起来很合理。过去我曾反对一项创建基于在世个人旅行的行程的建议。
- 更常见的情况是，某个列表提到了在酒店或餐厅工作的人。“友好的主人”或“服务员服务差”是可以的，但提及工作人员的姓名需要更谨慎。 AlasdairW (讨论) 2025年6月10日23:04 (UTC)
- 当然，当主厨或糕点师的名字印在菜单上，或者他们是餐厅推广的著名厨师时，是可以的。 Ikan Kekek (讨论) 2025年6月10日23:40 (UTC)
- 艺术家的个人生活能否与其作品分开？至少，死亡有助于结束一个人的故事。乔治·里德尔（Georg Riedel）一年前去世了，他在犹太斯德哥尔摩之旅中值得被描述。亚历山大·沃洛达尔斯基（Aleksander Wolodarski）是另一个值得提及的人，但由于他还健在（并且在瑞典建筑界有一定争议），在同一篇文章中对他的描述非常简短。 哈利·波特旅游几乎没有提到作者，这可能也是好事。 /Yvwv (讨论) 2025年6月11日10:16 (UTC)
- 我认为提及一位著名厨师的名字（“Thomas Keller 的餐厅，The French Laundry”）或者一位相对公众的非名人（“餐厅老板 Mary Smith 也是这个小镇的长期镇长”或“Olly Owner 乐意应要求打包野餐”）是可以的。
- 然而，作为 Wikivoyage:Avoid negative reviews 的延伸，我们实际上不希望“Chris Celebrity（克里斯名流）很做作，他的餐厅价格过高”或“Wendy Waitress（温迪服务员）不友好且动作慢”。 WhatamIdoing (讨论) 2025年6月11日17:26 (UTC)
- 我认为“Wendy Waitress（温迪服务员）不友好”是可以避免的，但“一些员工不友好”是可以的。重要的是如果一个地方的负面方面与“精美的烹饪和绝佳的面包”相平衡，或者它是镇上唯一的这个地方，那么就应该报告。对于一人经营的企业，这会变得更加困难。 AlasdairW (讨论) 2025年6月11日20:24 (UTC)
- Wikivoyage 不应关注人：那是维基百科的领域。但是，Wikivoyage 关注与人相关的地点，并为此应谨慎处理他们的隐私。但是，如果相关个人邀请公众参观他们的住所或企业（例如，唐纳德·特朗普有一个关于Mar-a-Lago的网站），那么 Wikivoyage 就没有责任保护他的隐私：如果他公开自己的住所，那么他就有责任保护自己的隐私。相比之下，乔·拜登似乎并不公开他的住所，所以 Wikivoyage 也不应该这样做（即使在网上搜索会发现乔·拜登的房产）。Martinvl (讨论) 2025年6月12日15:18 (UTC)
- 我认为“Wendy Waitress（温迪服务员）不友好”是可以避免的，但“一些员工不友好”是可以的。重要的是如果一个地方的负面方面与“精美的烹饪和绝佳的面包”相平衡，或者它是镇上唯一的这个地方，那么就应该报告。对于一人经营的企业，这会变得更加困难。 AlasdairW (讨论) 2025年6月11日20:24 (UTC)
- 当然，当主厨或糕点师的名字印在菜单上，或者他们是餐厅推广的著名厨师时，是可以的。 Ikan Kekek (讨论) 2025年6月10日23:40 (UTC)
- 我想我们的“BLP（在世人物）政策”可以是我们现有 Wikivoyage:Be fair 政策的一个部分。基本上，是一些关于避免提及个人，尤其是避免说任何有争议或不公平侵犯他们隐私的事情的原则。 WhatamIdoing (讨论) 2025年6月10日16:40 (UTC)
- 像这样的内容感觉合适吗？
- ----
- 作为一般规则，Wikivoyage 关注地点，而非人物。偶尔，提供公平的描述会涉及提及特定人物。在这种情况下，以下原则适用于保护在世人物：
- 尽量避免关于在世人物的有争议内容，以表示对人类尊严和个人隐私的尊重。发布与文章需求无关、微不足道、短暂或构成负面评论的个人信息是不公平的。例如，如果一家餐厅的老板向顾客宣扬可疑的信仰，则完全删除该列表，而不是写关于老板信仰的文章。
- 避免以在世人物为中心的整篇文章，例如前往名人私人住宅的行程。行程专注于泰勒·斯威夫特（Taylor Swift）的演唱会巡演是公平的；但关于她住所的文章则不公平。
- 命名在世公众人物的个人列表是可接受的，只要内容没有争议。但是，当一般性描述足够时，您应避免命名在世人物。例如，写“老板乐于谈论当地历史”，而不是“老板 Harry Historian 乐于谈论当地历史”，即使您会命名名人厨师 Thomas Keller 为餐厅 The French Laundry 的老板。
- ----
- 应该更改、添加、删除什么？ WhatamIdoing (讨论) 2025年6月12日16:39 (UTC)
- 感谢您提供草稿！让我感到有问题的一点是关于“可疑的信仰”，这给不容忍的无神论者提供了一个抱怨餐厅里的“奉命”或十字架的理由。 Ikan Kekek (讨论) 2025年6月12日17:12 (UTC)
- 我想的是政治信仰，特别是关于我在疫情期间读到的一个反口罩餐厅，但你是对的：这需要重新措辞。 WhatamIdoing (讨论) 2025年6月12日23:30 (UTC)
- 我还是觉得是个不错的开始。 //shb (t | c | m) 2025年6月13日12:15 (UTC)
- 我不认为应该因为业主或员工的信仰而删除企业；业主宣传反疫苗或地平说理论可能很有趣，而不是理由去避免它们。有人可能会说他们可能会提出争议性话题。对于危险行为，例如在需要时未戴口罩，那将与其他地方使用受污染的水或类似情况一样处理。是的，有时这 warrants根据不差评的原则删除列表，但这与隐私关系不大。
- 对于一家芬兰企业，有人建议删除该列表，因为存在偏执，实际上是 Wikivoyage 的抵制。我不确定在多大程度上应该这样做，但我认为在这种情况下，我们可能会提及业主的一些情况，如果我们把选择是否使用他们的服务留给我们的读者。我将反对个别编辑者因其观点不符合自己的观点而删除列表，但他们当然可以选择不添加它们。
- –LPfi (讨论) 2025年6月13日12:28 (UTC)
- 我认为可能存在一系列问题，但某些类型的（例如）偏见与Wikivoyage:The traveller comes first不符。包容（至少在有其他选择时）就构成了一种推荐。如果我们列出一家餐厅，那应该是旅行者受到欢迎。如果餐厅的列表需要附带免责声明，例如“顺便说一下，这里只允许白人吃饭”或“店主认为看起来像犹太人/穆斯林/黑人/同性恋/跨性别者的人将被拒绝服务”，那么这家餐厅根本就不应该出现在Wikivoyage上。列出的餐厅通常应该向所有公众开放。
- 在另一方面，如果店主热情地接受所有顾客，但他私下属于一个种族主义组织，那么这实际上与旅行者的体验无关，所以我们不必提及。希望只光顾属于相同政治/宗教/种族/性取向的人所拥有企业的旅行者，应该另寻他处获取此类信息。
- 介于两者之间的是旅行者可能以不同方式解释的事实信息。例如，如果纽约市的某个熟食店是符合犹太教规的，那么在描述中提及这一点是值得的。大多数旅行者不会在意。有些旅行者会偏爱它（无论是出于宗教原因，还是因为符合犹太教规的肉被认为比普通肉更符合道德）。有些旅行者会拒绝它。但是，知道它可能吸引（或不吸引）不同的旅行者，与不同旅行者被禁止在熟食店用餐是不同的。WhatamIdoing（讨论）20:02, 2025年6月13日(UTC)
- 在我看来，以中立的方式描述一家餐厅的宗教信仰并没有什么问题——例如，“XYZ餐厅是一家符合犹太教规/清真/素食的餐厅”。读者可以自己决定是否光顾该场所——毕竟Wikivoyage有许多关于各种宗教场所的文章。Martinvl（讨论）21:05, 2025年6月13日(UTC)
- 我认为总体的要点是，我们想要的是“XYZ是一家符合犹太教规/清真/素食的餐厅”，而不是“XYZ的老板是犹太人/穆斯林/素食者”。WhatamIdoing（讨论）17:10, 2025年6月14日(UTC)
- 我同意这一点。//shb (t | c | m) 06:56, 2025年6月18日(UTC)
- 我认为总体的要点是，我们想要的是“XYZ是一家符合犹太教规/清真/素食的餐厅”，而不是“XYZ的老板是犹太人/穆斯林/素食者”。WhatamIdoing（讨论）17:10, 2025年6月14日(UTC)
- 在我看来，以中立的方式描述一家餐厅的宗教信仰并没有什么问题——例如，“XYZ餐厅是一家符合犹太教规/清真/素食的餐厅”。读者可以自己决定是否光顾该场所——毕竟Wikivoyage有许多关于各种宗教场所的文章。Martinvl（讨论）21:05, 2025年6月13日(UTC)
- 我想的是政治信仰，特别是关于我在疫情期间读到的一个反口罩餐厅，但你是对的：这需要重新措辞。 WhatamIdoing (讨论) 2025年6月12日23:30 (UTC)
- 感谢您提供草稿！让我感到有问题的一点是关于“可疑的信仰”，这给不容忍的无神论者提供了一个抱怨餐厅里的“奉命”或十字架的理由。 Ikan Kekek (讨论) 2025年6月12日17:12 (UTC)
- 建议重写第一点（更改以粗体显示）
- “尽可能避免涉及在世人员的争议性内容，以尊重人的尊严和个人隐私。发布与文章需求无关、琐碎、短暂或构成负面评价的个人信息是不公平的。例如，如果餐厅老板向顾客宣传特定信仰，则应完全省略列表，而不是撰写关于老板信仰的内容。但是，如果场所本身迎合某些信仰和/或道德规范，那么以中立的方式在描述中添加这些信仰/规范是合理的，甚至可能是可取的——例如，在场所描述中包含“符合犹太教规/清真/素食”等词语。”Martinvl（讨论）21:14, 2025年6月13日(UTC)
- 我建议扩展第二点（添加内容以粗体显示）
- 尽可能避免以在世人员为中心的文章，例如参观名人故居的行程。以泰勒·斯威夫特的演唱会巡演为中心的文章是合理的；但以她的故居为中心的文章则不合理。但是，如果相关名人向公众宣传他们的住所（例如唐纳德·特朗普的故居Mar-a-Lago或马尔伯勒公爵的故居Blenheim Palace），那么在文章中提及该住所是完全可以的，并且最好在描述或文章中包含网址。
- Martinvl（讨论）21:27, 2025年6月13日(UTC)
- 我认为所有关于信仰和政治的讨论都很糟糕，不应该制定相关政策。此外，负面评价绝非不公平，我无法理解任何人怎么会这么想；只是Wikivoyage选择不列出企业（除少数例外），而不是说它们很糟糕。我也不明白为什么我们需要制定一项政策，规定歧视基于种族、外貌或国籍的人的企业（例如，大流行初期拒绝东亚人入内的杜塞尔多夫一家历史悠久的餐厅）将被移除，因为我们已经根据现有政策这样做了。目前，我认为根据本帖中流传的草稿，我们可能会批准一项比没有政策还糟糕的新政策。Ikan Kekek（讨论）21:40, 2025年6月13日(UTC)
- 也许最好尝试最小的改动。毕竟，如果以后真的需要，通常比以后缩减更容易扩大政策。WhatamIdoing（讨论）17:08, 2025年6月14日(UTC)
- 这是一个更短的版本
- ----
- 作为一般规则，Wikivoyage 关注地点，而非人物。偶尔，提供公平的描述会涉及提及特定人物。在这种情况下，以下原则适用于保护在世人物：
- 尽可能避免涉及在世人员的争议性内容，以尊重人的尊严和个人隐私。涉及在世公众人物的个人列表是可以接受的，前提是内容不具争议性。
- 避免以在世人员为中心的整篇文章，例如参观名人故居的行程。
- ----
- 我们也可以缓和“尽可能”的说法。总是“可能”避免提及任何人的名字，但并非总是“合理”这样做。WhatamIdoing（讨论）17:14, 2025年6月14日(UTC)
- 关于美国总统的文章呢？我们不回避关于在世总统的争议性事实；我们只是根据现有的Wikivoyage:Be fair指南，就他们在介绍中的内容达成一致。我仍然不明白你的第一项提议指南将如何改善任何事情。另外，我们是在解决一个不存在的问题吗？你能举出一个我们无法通过现有指南处理的、关于在世人员的不必要争议性事实的文章的例子吗？Ikan Kekek（讨论）07:33, 2025年6月17日(UTC)
- 美国总统不是“以在世人员为中心的整篇文章”；它是一篇以已故人员为主的文章，只提到了五位在世的美国总统（而且大多是以“公共博物馆”的方式，而不是“当前私人住宅”的方式）。因此，这可以被接受为“涉及在世公众人物的个人列表”的案例，并且“尊重人的尊严和个人隐私”。
- 要解决的现有问题是：Wikimedia基金会董事会曾表示，每个项目都需要有一项官方的、书面的关于在世人物的政策。他们大约在16年前就这么说了，所以我们有点落后了，但我们应该有东西。他们的决议鼓励“特别关注中立性原则”，因此我认为将几句话写进我们版本的“NPOV”政策中是合适的。我们甚至可以创建一个指向它的WV:BLP快捷方式，以便维基百科的人更容易找到。WhatamIdoing（讨论）17:16, 2025年6月17日(UTC)
- 我的问题不在于你的第二个提议条款（它很好），而在于你的第一个，这也是我上次回复所讨论的。如果它说明，当需要提及在世人物时，我们必须公平，并就任何争议性内容达成共识，我会很高兴。Ikan Kekek（讨论）17:33, 2025年6月17日(UTC)
- 你能想到任何旅行指南——尤其是那些不引用外部来源的指南——需要包含的争议性或诽谤性信息吗？WhatamIdoing（讨论）17:37, 2025年6月18日(UTC)
- 我已经给了你一个例子！那么描述国家为独裁国家呢？我们有时会遇到用户反对并试图粉饰文章，在这种情况下，我们拥有的是Wikivoyage:Be fair，而不是什么“有争议性”是坏的并且必须避免的荒谬说法，这将使他们得逞。Wikivoyage是一个旅行指南，而不是一个试图保持中立的网站。我们明确没有NPOV政策，而是有一项要求公平的政策。Ikan Kekek（讨论）18:10, 2025年6月18日(UTC)
- 我同意我们可以公平地将一个国家描述为独裁国家。我们是否需要将一个在世的个人描述为独裁者，当这样做会引起争议（例如，导致维基上的纠纷和分歧）时？我刚刚查阅了所有包含“a dictator”和“the dictator”一词的文章；它们都没有提及在世人物。
- 如果你的先前例子是“美国总统的文章呢？”，我已经回答了这个问题。在《美国总统》中，我看不到任何侵犯隐私之处，也没有看到任何关于其中在世人物的争议性内容。内容并非得到竞选团队的普遍批准，但没有人真正对事实有争议或“争论”（例如，克林顿卷入性丑闻，或者特朗普在法律上是已定罪的重罪犯）。WhatamIdoing（讨论）01:07, 2025年6月20日(UTC)
- 如果你最近没有遇到特朗普支持者的不幸，那你就很幸运了。在美国有数千万铁杆特朗普支持者，他们不接受基本的科学事实，并将各种阴谋论作为真相提出。昨天我在新罗谢尔遇到一位出租车司机，他主动开始谈论政治。他声称拜登四年前就患有癌症，“他们”对此进行了掩盖，声称化石燃料导致全球变暖是“胡说八道”，如果民主党去年当选，我们现在都将驾驶电动汽车了，等等。因此，我非常反对你关于关于特朗普、拜登、奥巴马等的陈述不是“争议性”的自信断言。我们需要将这个词从Wikivoyage不能成为的东西的考虑范围中删除。你还记得几年前有人花了两周或更长时间试图粉饰关于古巴的描述，声称它实际上是民主的，他们的选举是真正自由和公平的，而且共产主义者从未在那里当过独裁者或压迫过任何人吗？或者那些声称中国是民主国家，而美国（特朗普之前）才是真正压迫性的国家（后者当然从未完全不真实，但对于旅行指南来说，这完全是跑题的，也是纯粹的“又如何”式的狡辩，什么都无法证明）。我们曾经历过各种政治动机的争议性事实。这就是为什么我们的标准是Wikivoyage:Be fair，而不是“Wikivoyage/避免说任何可能被争论的事情”，这就是“争议性”的意思，或者在任何想用旅行指南来宣泄私愤的人手中会意味着什么，而不是为旅行者改进资源。Ikan Kekek（讨论）02:14, 2025年6月20日(UTC)
- 我已经给了你一个例子！那么描述国家为独裁国家呢？我们有时会遇到用户反对并试图粉饰文章，在这种情况下，我们拥有的是Wikivoyage:Be fair，而不是什么“有争议性”是坏的并且必须避免的荒谬说法，这将使他们得逞。Wikivoyage是一个旅行指南，而不是一个试图保持中立的网站。我们明确没有NPOV政策，而是有一项要求公平的政策。Ikan Kekek（讨论）18:10, 2025年6月18日(UTC)
- 你能想到任何旅行指南——尤其是那些不引用外部来源的指南——需要包含的争议性或诽谤性信息吗？WhatamIdoing（讨论）17:37, 2025年6月18日(UTC)
- 我的问题不在于你的第二个提议条款（它很好），而在于你的第一个，这也是我上次回复所讨论的。如果它说明，当需要提及在世人物时，我们必须公平，并就任何争议性内容达成共识，我会很高兴。Ikan Kekek（讨论）17:33, 2025年6月17日(UTC)
- 关于美国总统的文章呢？我们不回避关于在世总统的争议性事实；我们只是根据现有的Wikivoyage:Be fair指南，就他们在介绍中的内容达成一致。我仍然不明白你的第一项提议指南将如何改善任何事情。另外，我们是在解决一个不存在的问题吗？你能举出一个我们无法通过现有指南处理的、关于在世人员的不必要争议性事实的文章的例子吗？Ikan Kekek（讨论）07:33, 2025年6月17日(UTC)
- 我同意Ikan的观点。我在种族隔离时期的南非长大。如果当时 Wikivoyage 存在，我们会因为几乎所有机构都被法律要求实行种族歧视而删除南非的所有内容吗？我认为这不合适。但是，我认为包括一节关于如何应对国家种族政策的内容是合适的。Martinvl（讨论）22:22, 2025年7月5日(UTC)
- 也许最好尝试最小的改动。毕竟，如果以后真的需要，通常比以后缩减更容易扩大政策。WhatamIdoing（讨论）17:08, 2025年6月14日(UTC)
- 相关：美国总统中的一些简短传记Purplebackpack89 15:03, 2025年8月8日(UTC)
- 你已经提出了编辑建议。继续酌情提出。Ikan Kekek（讨论）17:26, 2025年8月15日(UTC)
关于当前的主要问题，我建议关注地点，而不是人，更具体地说，关注官方列出或指定的地点。故居在房主去世后或在世时征得其同意后，会在历史遗址登记册上标明。官方图书馆和博物馆也是如此。而且，关于只留下特朗普及其四位在世前任（可能例外是克林顿、布什和奥巴马图书馆）的观点是有说服力的。Purplebackpack89 16:01, 2025年8月8日(UTC)
我关于用Wikivoyage进行教学的学术文章
草稿已完成（仍在进行细微的校对和修改）。我很乐意听取您的意见：https://docs.google.com/document/d/1mOR7w19Dd8CrElZcoeFkDxGCCOi12kff6qe1WQa8JCM/edit?tab=t.0 几天后，我打算将其提交给学术期刊（有几家期刊涉及教育+旅游和酒店业领域）进行同行评审。感谢多年来在我学生身上的帮助（另外，请注意：新学期即将开始，预计从9月下旬开始，会有新一批学生编辑关于韩国和中国的内容；我将一如既往地提供一份他们选择的文章列表供您关注）。Piotrus（讨论）11:19, 2025年8月15日(UTC)
- 哦，很有趣，我会读一下的。//shb (t | c | m) 11:21, 2025年8月15日(UTC)
- 刚读完——我没什么好说的，只是它研究得非常透彻，读起来很棒。干得好，Piotrus。//shb (t | c | m) 11:46, 2025年8月15日(UTC)
- 我快速浏览了文章。我是否可以建议一个小的补充——《Requested_articles》是建议主题的另一个来源——学生可能会在那里找到他们从未想过的主题。例如，我看到了一个关于Taizé Community的请求。这是一个位于法国乡村中心的修道院，吸引了许多年轻人，并以其所在地村庄的名字命名。讨论页的第一个部分很有趣，因为它显示了关于文章范围的辩论（应该包括村庄还是仅社区）。Martinvl（讨论）14:18, 2025年8月15日(UTC)
- @Martinvl 谢谢——我不知道那个页面，我会尽快把它添加到相关资源中！Piotrus（讨论）18:29, 2025年8月15日(UTC)
Piotrus，谢谢你发给我们这个链接！我正在愉快地阅读这篇论文。我想知道你是否需要一些校对建议，比如在下一句话中去掉分号：“The next section will review the academic consensus on pedagogical benefits of writing for Wikipedia, an assignment that was developed over a decade ago and has since been used by thousands of educators (Vetter, McDowell & Stewart, 2019; Konieczny 2021; Evenstein Sigalov & Konieczny, 2025); as a building block for the discussion on how such an activity can be adopted to the tourism and hospitality context, both on Wikipedia as well as on Wikivoyage website.”也许我应该停止阅读，直到你告诉我，因为我看到了一些其他地方我建议进行小的编辑，如果我读完文章，我会忘记所有这些实例，并且不想再次阅读只是为了校对。我补充说，到目前为止，它看起来写得相当好，没有大的建议需要更改，但我只看到第二部分。Ikan Kekek（讨论）17:25, 2025年8月15日(UTC)
- @Ikan Kekek 无论建议大小，都欢迎。Piotrus（讨论）18:28, 2025年8月15日(UTC)
- 通知@MarianaSenkiv，因为她也使用Wikivoyage（乌克兰语）来教学旅游专业的学生。Piotrus，你可能见过她，因为你们俩都参加了Wikimania Katowice。OhanaUnited讨论页 12:39, 2025年8月20日(UTC)
- 我曾担任期刊论文的编辑。在上述段落中，我将删除分号并将“adopted”改为“adapted”。Pashley（讨论）16:23, 2025年8月20日(UTC)
- 我发现了一个实质性问题，在我看来是一个错误，但也可以说是过于简化了。
- Wikivoyage 是……它于2006年作为商业 Wikitravel 网站的一个志愿者驱动的分支启动，……
- Wikitravel 于2003年启动并于2006年商业化。德语和意大利语的 Wikivoyage 大约在那时启动，但英文 Wikivoyage 的分支并在2012年左右成为 Wikimedia 站点；详情请参见Wikivoyage:Wikivoyage_and_Wikitravel。 Pashley（讨论）16:33, 2025年8月20日(UTC)
- 抓得好，Pashley。//shb (t | c | m) 21:14, 2025年8月20日(UTC)
- 嗯，我认为上面的日期是正确的。我很确定德语和意大利语的维基百科在2006年就已经分叉了，所以可以说，那时 Wikivoyage 才首次被志愿者分叉。--来自 Selfie City（讨论）（贡献）00:06, 2025年8月21日(UTC)
- 我认为这是无可争议的。那确实是 Wikivoyage 开始的时候。Ikan Kekek（讨论）00:58, 2025年8月21日(UTC)
- @Pashley @SHB2000 嗯，我的总结是一个简化，因为 Wikitravel/Wikivoyage 的详细历史实际上是琐事，对我们来说并不重要。关于 Wikivoyage 的维基百科文章说：“该项目始于德语，然后是意大利语版本的编辑者于2006年9月决定将其编辑活动和当前内容迁移到一个新网站……” 然后英语版本于2012/2013年左右跟进。信息框显示：“第一个版本（德语）2006年12月10日。英语版本2013年1月15日”。所以我不确定哪里错了？但我很乐意考虑修改建议。Piotrus（讨论）09:19, 2025年8月21日(UTC)
- 我认为这是无可争议的。那确实是 Wikivoyage 开始的时候。Ikan Kekek（讨论）00:58, 2025年8月21日(UTC)
- 嗯，我认为上面的日期是正确的。我很确定德语和意大利语的维基百科在2006年就已经分叉了，所以可以说，那时 Wikivoyage 才首次被志愿者分叉。--来自 Selfie City（讨论）（贡献）00:06, 2025年8月21日(UTC)
- 抓得好，Pashley。//shb (t | c | m) 21:14, 2025年8月20日(UTC)
我什么时候能翻译文章？
已经一个星期（也许2个星期）了，我仍然无法将英语文章翻译成世界语。我什么时候才能获得这项能力？HtialilwW（讨论）02:43, 2025年8月23日(UTC)
- 有人告诉你几周内你会获得这项能力吗？Ikan Kekek（讨论）02:49, 2025年8月23日(UTC)
- 没有。我只是猜测，但我什么时候才能获得它？HtialilwW（讨论）02:51, 2025年8月23日(UTC)
- 如果你想翻译文章，你必须自己翻译。Ikan Kekek（讨论）03:07, 2025年8月23日(UTC)
- 虽然我们希望有，但我们没有像维基百科那样官方的翻译工具。本站的Special:Translate对任何人都没有用。//shb (t | c | m) 03:53, 2025年8月23日(UTC)
- 但是当我点击右上角的“语言”时，它有几种语言。如何关联你的文章？HtialilwW（讨论）04:28, 2025年8月23日(UTC)
- 这是在Wikidata上完成的。//shb (t | c | m) 04:30, 2025年8月23日(UTC)
- 但是当我点击右上角的“语言”时，它有几种语言。如何关联你的文章？HtialilwW（讨论）04:28, 2025年8月23日(UTC)
- 虽然我们希望有，但我们没有像维基百科那样官方的翻译工具。本站的Special:Translate对任何人都没有用。//shb (t | c | m) 03:53, 2025年8月23日(UTC)
- 如果你想翻译文章，你必须自己翻译。Ikan Kekek（讨论）03:07, 2025年8月23日(UTC)
- 没有。我只是猜测，但我什么时候才能获得它？HtialilwW（讨论）02:51, 2025年8月23日(UTC)
- @Amire80，你的团队是否研究过为Wikivoyage启用内容翻译？WhatamIdoing（讨论）16:52, 2025年8月23日(UTC)
- 稍微看过一点，但从未优先处理。理论上是可能的，但需要工作。最好在mw:Talk:Content translation上提问。Amir E. Aharoni（讨论）15:10, 2025年9月6日(UTC)
- 各位，我们对此想法有何看法？我们是否希望在 Wikivoyages 之间启用翻译工具？（注意，启用机器翻译，如谷歌翻译，是另一个问题。我的问题是关于翻译 {{sleep}} 模板到不同语言的匹配模板的软件。）WhatamIdoing（讨论）19:51, 2025年9月6日(UTC)
- 明确地说，要点是让空白模板进行机器翻译吗？Ikan Kekek（讨论）20:01, 2025年9月6日(UTC)
- 各位，我们对此想法有何看法？我们是否希望在 Wikivoyages 之间启用翻译工具？（注意，启用机器翻译，如谷歌翻译，是另一个问题。我的问题是关于翻译 {{sleep}} 模板到不同语言的匹配模板的软件。）WhatamIdoing（讨论）19:51, 2025年9月6日(UTC)
- 稍微看过一点，但从未优先处理。理论上是可能的，但需要工作。最好在mw:Talk:Content translation上提问。Amir E. Aharoni（讨论）15:10, 2025年9月6日(UTC)
临时账户即将推出
您好，我们是 Wikimedia 基金会产品安全与诚信团队。我们想宣布，我们计划在9月1日当周为本维基启用临时账户。
临时账户已成功在30个维基（包括许多大型维基，如德语、日语和法语）上启用。它们带来的变化对未登录的编辑者尤其重要，因为该功能旨在保护他们。但它也与社区成员相关，如导师、巡查员和管理员——任何参与撤销编辑、封禁用户或以其他方式与未登录编辑者互动，以维护维基安全和准确性的人。
我们为何要构建临时账户
我们的维基对未登录的编辑者而言，默认应该更安全。临时账户允许人们在不创建账户的情况下继续编辑维基，同时避免他们的编辑公开与IP地址关联。我们相信这符合我们未登录编辑者的最佳利益，他们为维基做出了宝贵的贡献，并且以后可能会创建账户，壮大我们的编辑者、管理员和其他角色的社区。即使维基确实警告未登录编辑者他们的IP地址将与他们的编辑相关联，但许多人可能不理解IP地址是什么，或者它可能被用来将他们与有关他们的其他信息联系起来，以他们意想不到的方式。
此外，我们的审核软件和工具在识别用户和活动模式时过度依赖网络来源（IP地址），尤其是因为IP地址本身作为标识符越来越不稳定。临时账户允许与未登录编辑者进行更精确的互动，包括更精确的封禁，并且可以帮助减少我们意外封禁使用相同IP地址的善意用户的次数，而这些IP地址属于恶意用户。
临时账户如何工作
任何时候，当一个未登录用户在此维基上发布编辑时，都会在用户的浏览器中设置一个cookie，并且会自动创建一个与此cookie关联的临时账户。该账户的名称将遵循以下模式：~2025-12345-67（一个波浪号、当前年份、一个数字）。在“Recent Changes”或页面历史记录等页面上，将显示此名称。cookie将在创建后90天过期。只要它存在，从该设备所做的所有编辑都将归因于该临时账户。除非用户清除其cookie或使用不同的设备或网络浏览器，否则它将是同一个账户。在编辑发生后90天内，将存储每次编辑时使用的IP地址记录。但是，只有一些已登录用户才能查看它。
这对不同类型的用户意味着什么？
对未登录的编辑者
- 这增加了隐私：目前，如果您不使用注册账户进行编辑，那么任何人都可以看到您编辑的IP地址，即使在90天后也是如此。在本维基上，这种情况将不再发生。
- 如果您在过去90天内使用临时账户从不同地点编辑（例如在家和咖啡店），那么所有这些地点的编辑历史记录和IP地址现在将一起记录在同一个临时账户下。符合相关要求的用户将能够查看这些数据。如果您对此有任何个人安全顾虑，请联系talktohumanrights at wikimedia.org获取建议。
对与未登录编辑者互动的社区成员
- 临时账户唯一地与设备关联。相比之下，IP地址可以与其他设备和人员共享（例如，学校或工作场所的不同人员可能拥有相同的IP地址）。
- 与当前情况相比，可以更安全地假定临时用户的讨论页只属于一个人，并且留在上面的消息将被他们阅读。正如您在截图中所见，临时账户用户将收到通知。也可以感谢他们的编辑，在讨论中提及他们，并邀请他们更积极地参与社区。
对使用IP地址数据来审核和维护维基的用户
- 对于巡查员，他们负责跟踪持续的滥用者，调查政策违规等：符合要求的用户将能够显示临时用户的IP地址以及从特定IP地址或范围作出的所有临时账户的贡献（Special:IPContributions）。他们还可以通过IP Info功能获取有用的IP地址信息。许多其他软件已被构建或调整以适应临时账户，包括 AbuseFilter、全局封禁、Global User Contributions 等。（关于如何更新工具代码的志愿者开发者信息——请参见消息的最后部分。）
- 对于封禁未登录编辑者的管理员:
- 可以通过仅封禁滥用者的临时账户来封禁他们。如果管理员选择了自动封禁选项，被封禁者将无法快速创建新的临时账户。
- 仍然可以封禁IP地址或IP地址范围。
- 临时账户不会追溯应用于部署前的贡献。在 Special:Contributions 上，您将能够看到现有的IP用户贡献，但不能看到该IP地址上由临时账户产生的新贡献。相反，您应该使用 Special:IPContributions 来实现此目的。
我们的请求，以及下一步
- 如果您知道任何使用IP地址数据或可供未登录用户使用的工具、机器人、小工具等，您可能想测试它们是否在testwiki或test2wiki上正常工作。如果您是志愿者开发者，请阅读我们的开发者文档，特别是关于您的代码可能需要如何更新的部分。
- 如果您想测试临时账户体验，例如只是想感受一下，请访问testwiki或test2wiki并进行未登录编辑。
- 如果您知道任何需要解决的困难，请告诉我们。我们将尽力提供帮助，如果无法做到，我们将考虑可行的选择。
- 请查看我们关于未拥有扩展权限的用户可能需要访问 IP 地址的要求的上一条消息。
要了解更多关于该项目的信息，请查看我们的常见问题解答——您可以在那里找到许多有用的答案。您也可以查看更新（我们刚刚发布了一个）并订阅我们的新通讯。如果您想在站外与我（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（讨论） 15:39, 2025年9月2日 (UTC)
- 我在其他较小维基（如 srwiki）上处理临时账户的经验是，它们可以防止破坏者进行 IP 跳跃，因为这据称与设备关联，而不是 IP——但这使得处理此类滥用行为变得更加困难，尤其是在涉及范围封锁或对于不符合查看临时账户标准（6 个月和 500 次编辑；尽管据我所知，我现在应该可以绕过此限制，因为我获得了
全局临时账户 IP 查看器？）的情况下。shb (t | c | m) 23:24, 2025年9月2日 (UTC)
- 我在其他较小维基（如 srwiki）上处理临时账户的经验是，它们可以防止破坏者进行 IP 跳跃，因为这据称与设备关联，而不是 IP——但这使得处理此类滥用行为变得更加困难，尤其是在涉及范围封锁或对于不符合查看临时账户标准（6 个月和 500 次编辑；尽管据我所知，我现在应该可以绕过此限制，因为我获得了
- 这也是我担心的。但我看到了对维基社区的益处。
- “Cookie 将在创建后 90 天过期。只要它存在，从此设备进行的任何编辑都将归属于此临时账户。即使 IP 地址发生变化，它仍然是同一个账户，除非用户清除其 cookie 或使用不同的设备或 Web 浏览器。”
- “通过阻止其临时账户，就可以阻止许多滥用者。如果管理员选择了自动阻止选项，被阻止的人将无法快速创建新的临时账户。”
- 此外，“符合要求的用户将能够显示临时用户的 IP 地址以及从特定 IP 地址或范围（Special:IPContributions）进行的临时账户的所有贡献。”这意味着您（Gorgeous）将仍然拥有与现在相同的访问权限。Ground Zero（讨论） 15:59, 2025年9月2日 (UTC)
- 谢谢。我想我们很快就得习惯如何自动阻止了……Ikan Kekek（讨论） 16:04, 2025年9月2日 (UTC)
- 我尝试了第一次基于临时账户识别的封锁 Telstar 长期滥用者 IP。如果一切都做得正确，请看一下。OhanaUnited讨论页 21:33, 2025年9月8日 (UTC)
- 谢谢。我想我们很快就得习惯如何自动阻止了……Ikan Kekek（讨论） 16:04, 2025年9月2日 (UTC)
- 而且我在一个此类账户的讨论页上发布了我的第一次兜售警告。它们主要会保护兜售者和破坏者吗？Ikan Kekek（讨论） 15:39, 2025年9月2日 (UTC)
轻松找到城市中的“热门目的地”
foreword：我明白，每个旅行者的优先事项都不同。撇开这一点，肯定大多数城市都有主要的景点，然后是“支线任务”，适合普通旅行者。
例如，以埃斯泰尔戈姆为例。如果您在那里待一个星期，您可能可以全部游览。但对于 1-2 天来说，大多数人只会考虑例如大教堂、1-2 个博物馆、城堡和水上公园。我们能否为列表添加一些“首选”字段，并例如每篇文章和类型（游览/活动）限制 10 个？也许这样的列表可以有更生动的标记或其他东西。
我询问的原因和往常一样。又一次假期/公路旅行来了，我非常努力地尝试使用 WV 来计划它，但就是做不到。我不得不使用谷歌地图搜索景点，阅读评论，在其他地方（我常用的页面）组合行程，然后查阅 WV 以获得一些最终提示。我正在考虑为 WV 制作一个 JS 工具，可以收集这些行程的列表——但除非一个人至少能粗略评估给定区域的主要景点在哪里，否则开始都没有意义。
另一方面，如果我能在地图上看到匈牙利页面的所有文章的前 10 个景点组合，那至少可以让我对哪些地区最有趣有个大概的了解……
我一个人有这个问题吗？-- andree 18:42, 2025年9月2日 (UTC)
- 在有强烈共识认为哪些是热门景点的情况下，我们可以组织一个“游览”部分，例如锡耶纳#游览。否则，在游览部分开头进行总结即可。无需对列表模板进行任何花哨的颜色或格式更改。Ikan Kekek（讨论） 18:50, 2025年9月2日 (UTC)
- 很好，假设我们要花一两个星期游览托斯卡纳。您会如何使用 WV 来制定旅行计划？摘要文本很好，但它只在您被送到某个城市并需要一些介绍时才有帮助（例如通过某个有组织的旅游），对于主要的/自助规划则完全没有帮助。例如，蒙特普尔恰诺的景点看起来相当不起眼，在公路旅行中可能不值得一游（没有主要景点）。当然，如果您在该地区待几天，情况就不同了。但按照 WV 的当前结构，您如何弄清楚这一点？通过阅读所有文章？我可以打开 tripadvisor/google/wanderlog/... 并且效率提高 100 倍。-- andree 18:55, 2025年9月2日 (UTC)
- 托斯卡纳有很多很棒的度过一两周的方式，所以我们无法为读者提供一个“一刀切”的“托斯卡纳一周游”指南，我们只能合理地在托斯卡纳#游览和托斯卡纳#活动部分提及一些亮点，让读者自行选择首次访问的重点（然后是第二次、第三次、第四次，如果他们能去的话……）。当然，他们也可以选择参加预订好的旅游团，但我们在这里不是为了指导他们做这个。尽管如此，如果您认为《托斯卡纳》文章的任何部分缺少应予总结的重要信息，请随时添加！如果您认为其中任何内容可能存在争议，请在托斯卡纳讨论页提出建议。另外，我现在没时间查看 Tripadvisor 链接，但它比 Wikivoyage 优越在哪里，以及我们如何最好地解决这个问题？Ikan Kekek（讨论） 00:40, 2025年9月3日 (UTC)
- 这就是我的第一句话…… :) 另外，托斯卡纳只是一个例子。我可能是个美国士兵，有 5 天时间可以在拉姆斯泰因附近转转，一个从纽约到杰克逊维尔的推销员，想在中美洲待一个月的人，等等……你说你不想做“一刀切”的事情（我同意），但然后你建议做地区概览。这些只能涵盖特定区域，并且可能无法告知边界另一边的顶级景点。
- 在过去的 10-15 年里，我进行了各种几周/3000 公里的公路旅行，而 WV 大多数时候都无法帮助我制定一个大致的计划。城市指南本身通常很好（即使这里那里缺少一些内容，但这对我来说没关系，我总是在旅行后尝试填补空白），但我期望数字旅行指南也能帮助我把握大局……
- 或者想法仍然是只与传统的印刷旅行指南竞争？-- andree 06:05, 2025年9月3日 (UTC)
- “去哪里”（或有时是“附近”）是针对指南未涵盖的地区，并且总会有指南未涵盖的内容。 Ikan Kekek（讨论） 06:13, 2025年9月3日 (UTC)
- 托斯卡纳有很多很棒的度过一两周的方式，所以我们无法为读者提供一个“一刀切”的“托斯卡纳一周游”指南，我们只能合理地在托斯卡纳#游览和托斯卡纳#活动部分提及一些亮点，让读者自行选择首次访问的重点（然后是第二次、第三次、第四次，如果他们能去的话……）。当然，他们也可以选择参加预订好的旅游团，但我们在这里不是为了指导他们做这个。尽管如此，如果您认为《托斯卡纳》文章的任何部分缺少应予总结的重要信息，请随时添加！如果您认为其中任何内容可能存在争议，请在托斯卡纳讨论页提出建议。另外，我现在没时间查看 Tripadvisor 链接，但它比 Wikivoyage 优越在哪里，以及我们如何最好地解决这个问题？Ikan Kekek（讨论） 00:40, 2025年9月3日 (UTC)
- 很好，假设我们要花一两个星期游览托斯卡纳。您会如何使用 WV 来制定旅行计划？摘要文本很好，但它只在您被送到某个城市并需要一些介绍时才有帮助（例如通过某个有组织的旅游），对于主要的/自助规划则完全没有帮助。例如，蒙特普尔恰诺的景点看起来相当不起眼，在公路旅行中可能不值得一游（没有主要景点）。当然，如果您在该地区待几天，情况就不同了。但按照 WV 的当前结构，您如何弄清楚这一点？通过阅读所有文章？我可以打开 tripadvisor/google/wanderlog/... 并且效率提高 100 倍。-- andree 18:55, 2025年9月2日 (UTC)
- 我认为导言和==理解==部分对此也很有用。WhatamIdoing（讨论） 03:09, 2025年9月3日 (UTC)
- 我不会反对创建某种图标来表示“必看”景点，以及您在有额外时间时可以参观的附加地点——这是一个微妙的变化，但潜力巨大。虽然我知道摘要文本可以很好地发挥作用，但根据我的经验，仅仅拥有摘要文本并不能与其他旅行指南（我主要使用 Expedia 或 Google）相提并论。shb (t | c | m) 06:00, 2025年9月3日 (UTC)
- 摘要文本很好，一旦您进入相应的城市。我的问题在于别处。我无法阅读 200 篇这样的文章，即使它们都有顶级的概述……我宁愿使用谷歌地图在一个区域内搜索“景点”，然后挑选那些有 100 多条评论的，例如。但 IMO WV 可以轻易做到这一点，如果我们能在“必看”标签上做到的话。-- andree 06:10, 2025年9月3日 (UTC)
- 我在{{mustsee}} 制作了一个小示例，并在南堪培拉、基亚马和巴德鲁国家公园实施了它——您对此有什么看法？shb (t | c | m) 06:12, 2025年9月3日 (UTC)
- 原则上可以，但对我来说，只有当列表模板有 such parameter（例如 { {see|mustsee|name=xyz}}）时才有用。这样就可以创建一个动态地图，显示任意区域中带有 such stuff 的列表。
- 另一方面，添加这个工作量很大，并且可能是社区摩擦的来源……
- 我们可以做类似的事情，如果我们滥用维基百科搜索，例如按维基百科搜索结果的数量排序（穷人的谷歌鸽子排名替代品；因为如果我想使用它们的数字，我会很快被谷歌封禁——而且这可能违反了它们的 T&C :)）。例如，对于埃斯泰尔戈姆，它“埃斯泰尔戈姆大教堂”给出 51 条结果，“基督教博物馆” -> 13，“博蒂扬桥” -> 2，“耶稣会教区教堂” -> 1…… 我猜这可能有效，而且我们不需要任何外部东西，甚至不需要维基数据（但我们需要标记 :)）。-- andree 06:35, 2025年9月3日 (UTC)
- 这对于埃斯泰尔戈姆来说也许可行，但对于像纽约、柏林、巴黎、罗马或华盛顿特区这样的城市，结果会怎样呢？在这些城市，关于“最好”的景点和活动会有很大分歧，这取决于旅行者的偏好和兴趣。Ikan Kekek（讨论） 06:45, 2025年9月3日 (UTC)
- 嗯，据我所知，我们都在同一个问题上，即这种图钉适用于小城市、公园、较小的乡村地区——或者任何不是大城市的地方，因为在那里，最佳景点和活动更具主观性。shb (t | c | m) 06:49, 2025年9月3日 (UTC)
- 是的，总的来说，当一个城市有几个明显很棒的景点，而且活动不多时，会更容易。但为什么锡耶纳#游览模式对他们不起作用呢？Ikan Kekek（讨论） 06:56, 2025年9月3日 (UTC)
- 对于大城市？我怀疑。参考我在该主题中关于柏林、罗马、纽约等城市 lainnya 的评论。 shb (t | c | m) 07:00, 2025年9月3日 (UTC)
- 对于大城市？我怀疑。参考我在该主题中关于柏林、罗马、纽约等城市 lainnya 的评论。Ikan Kekek（讨论） 07:06, 2025年9月3日 (UTC)
- 是的，一旦您决定去锡耶纳，我认为这是一个完美的指南（第一眼看来），我可能只会用谷歌来搜索食物和可能缺少的新场所。但这不是这个话题的重点……-- andree 07:05, 2025年9月3日 (UTC)
- 在美国，我认为谷歌地图通常在寻找餐饮场所方面最有用。我怀念过去能够通过查看美食论坛网站（如 Chowhound）获得更可靠信息的那段日子。Ikan Kekek（讨论） 07:17, 2025年9月3日 (UTC)
- 对于大城市？我怀疑。参考我在该主题中关于柏林、罗马、纽约等城市 lainnya 的评论。 shb (t | c | m) 07:00, 2025年9月3日 (UTC)
- 是的，总的来说，当一个城市有几个明显很棒的景点，而且活动不多时，会更容易。但为什么锡耶纳#游览模式对他们不起作用呢？Ikan Kekek（讨论） 06:56, 2025年9月3日 (UTC)
- 是的，但这与埃斯泰尔戈姆本身无关。但如果您进行一次从埃斯泰尔戈姆到纳吉考尼察的旅行，并且对该国了解不多，IMO，如果您能汇总我们拥有的相关文章，选择列表并显示其排名最高的 10%，这将是很好的。然后您就会知道在塞克什白堡停留是值得的，但去瓦尔帕洛塔则不一定…… -- andree 06:56, 2025年9月3日 (UTC)
- 这听起来像是在地区指南或“去哪里”部分要解决的问题。Ikan Kekek（讨论） 06:57, 2025年9月3日 (UTC)
- 嗯，据我所知，我们都在同一个问题上，即这种图钉适用于小城市、公园、较小的乡村地区——或者任何不是大城市的地方，因为在那里，最佳景点和活动更具主观性。shb (t | c | m) 06:49, 2025年9月3日 (UTC)
- (ec) 我曾想过创建一个特殊的类别，将其列在动态地图上，但我知道这会遭到社区的强烈反对——因此，我提出了一个小图钉，它易于为大多数城市实现，并且争议性较小，同时又能获得大部分类似的好处。shb (t | c | m) 06:45, 2025年9月3日 (UTC)
- 这对于埃斯泰尔戈姆来说也许可行，但对于像纽约、柏林、巴黎、罗马或华盛顿特区这样的城市，结果会怎样呢？在这些城市，关于“最好”的景点和活动会有很大分歧，这取决于旅行者的偏好和兴趣。Ikan Kekek（讨论） 06:45, 2025年9月3日 (UTC)
- 我赞同。请看芝加哥#游览作为例子。我反对为所谓的“必看景点”使用特殊模板。这忽略了就景点达成一致的步骤，我不知道我们是否真的想在每个文章的讨论页上花费时间争论这些，但由个人单方面决定并强加答案也是不合理的。我们以前就这个话题进行过多次讨论，虽然在某些地方有明确的共识，但在很多其他地方则没有。举个例子，如果您考虑纽约市，许多没去过的人会认为时代广场是必看的，纽约人会勉强承认一次看一眼是说得通的，但这就能让它成为排名前五的景点吗？如果您优先考虑参观艺术博物馆（虽然它也有很棒的乐器和时装展厅），大都会博物馆是“必去之地”，但如果不是，那就不是。布鲁克林大桥可能是大多数人会同意的，但即使在这种情况下，有些人也会反对桥上的行人数量，或者仅仅是体力不支无法走完 1.1 英里。大多数纽约人以及许多游客会说乘坐史泰登岛渡轮是必做的，但一个拥有 YouTube 频道的导游声称它是个糟糕的交易，尽管它是免费的，而且您可以通过花很多钱喝香槟乘坐小型船只旅行，看到更多的自由女神像（我认为她大错特错了，但那些昂贵的旅行确实有顾客），但更严重的是，有些人宁愿不花时间往返纽约湾，而是宁愿多走走，去俱乐部和酒吧之类的。
......等等，等等。巴黎也是类似的情况：埃菲尔铁塔是标志性的，但不必进去参观才能看到；卢浮宫令人难以置信，但可能会让一个不太关心艺术的人感到厌倦；但巴黎有太多东西可看可做，对大多数人来说都是一个很棒的旅游目的地。Ikan Kekek（讨论） 06:25, 2025年9月3日 (UTC)
- 我的意思是，所有这些都是谷歌、Tripadvisor、Expedia、Lonely Planet 以及所有其他主要旅游指南都必须处理的问题，但它们都能很好地处理。我认识到这里的主要区别是那些网站不作为维基运行，但它们以某种方式设法做得很好，而且没有理由我们不能这样做（对于大城市来说可能需要一些讨论，但这确实就是这样）。拥有一个图钉或某种特殊列表并不一定意味着读者缺乏批判性思维——他们当然可以自己决定这是否符合他们的喜好。它应该更多地被视为一项新功能，读者可以按自己的意愿使用，但它并不能取代所有其他东西。
- 也许只是我，但 Wikivoyage 可能会失去相关性，如果我们没有某种区别性特征而只依赖文章摘要，因为我这个年龄的人都不愿意阅读冗长的文字和废话（这或许也解释了为什么我不如这里的大多数人关心生动的旅行写作），而如果我们想保持活跃的相关性，就需要一些视觉上的东西。shb (t | c | m) 06:42, 2025年9月3日 (UTC)
- 如果您想尝试为每个城市、地区、州/省，甚至地区列出前 5 或 10 个景点的争论，最好现在就开始，因为它将耗费很长时间。那些其他网站是商业性的，它们希望展示有助于它们销售最多的内容。这个维基的历史是它不关注最典型的旅行者，他们会满足于预订的旅游团，这些旅游团告诉他们去哪里。 Ikan Kekek（讨论） 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（讨论） 07:00, 2025年9月3日 (UTC)
- 我认为 Tripadvisor 上的排名可能很有帮助，尽管我并不总是同意它们的观点，但我认为这些是 Wikivoyage 的补充，并且不介意 Wikivoyage 与之不同。我承认，如果能帮助更多读者，我们可以尝试制作更多前十名之类的列表，我们可以这样做，但对于纽约这样的城市，这将归结为顶级的艺术博物馆、顶级的观景点、顶级的风景步道（通常是街区，而不是确切的行程）、顶级的公园（我们可以在那个方面做得更多）等等。Ikan Kekek（讨论） 07:03, 2025年9月3日 (UTC)
- 是的，我也不喜欢 Tripadvisor 是出于那个原因——我确实有车并且会开车，但我经常乘坐公共交通去区域地区出差以节省开支，有时还会考察城市。通常我不介意一个人走 12-15 公里（有时甚至靠近时速 110 公里的高速公路而没有任何防护），但 Tripadvisor 把事情推到了一个全新的层面。shb (t | c | m) 07:05, 2025年9月3日 (UTC)
- 我在寻找城市景点和活动时会查看 Tripadvisor 和 Wikivoyage。我对 Tripadvisor 最不满的是，他们显示了城市以外很远的地方的景点和活动，除非你有车，否则实际上无法游览或参与，而且你必须花时间查看他们的结果才能发现他们认为城市本身没有什么值得游览或参与的。我最担心 Wikivoyage 的地方在于，许多地方要么没有覆盖，要么覆盖不足，但这取决于具体地点。Ikan Kekek（讨论） 07:00, 2025年9月3日 (UTC)
- +1…… 我只是想让我们的（整个社区）努力得到展示，并被人们使用。正如 shb 在上面写的，大多数人不喜欢在决定去那里之前阅读大段的文字。-- andree 07:02, 2025年9月3日 (UTC)
- 您认为粗体字体没有帮助吗？您能做一个您想看到的示例吗？如果您想要比粗体更清晰的东西，那不应该是一个列表吗？Ikan Kekek（讨论） 07:05, 2025年9月3日 (UTC)
- 顺便说一下，我在这里的大部分评论都是基于轶事，既有我自己的经验，也有我 IRL 认识的许多其他（大部分是和我年龄相仿的）经常旅行的人的经验。您怎么看。shb (t | c | m) 06:56, 2025年9月3日 (UTC)
- 它们可能是商业性的，但即使像我这样的人，虽然在很多方面都为这个网站辩护，但最终经常求助于 Google/Lonely Planet，因为它们比我们更好地突出了关键兴趣点，这是它们比我们做得好，并且是我们应该努力改进的地方。我并不否认大城市实现这一点会有问题，但我想让这个网站被人们真正阅读，而且我们没有理由不能为小城市和公园做到这一点。shb (t | c | m) 06:55, 2025年9月3日 (UTC)
- 如果您想尝试为每个城市、地区、州/省，甚至地区列出前 5 或 10 个景点的争论，最好现在就开始，因为它将耗费很长时间。那些其他网站是商业性的，它们希望展示有助于它们销售最多的内容。这个维基的历史是它不关注最典型的旅行者，他们会满足于预订的旅游团，这些旅游团告诉他们去哪里。 Ikan Kekek（讨论） 06:47, 2025年9月3日 (UTC)
- 我同意您所有观点，但我的问题在于别处。我去了布达佩斯-克罗地亚，并想在途中花几天时间了解历史、自然景点等。我愿意绕道 50 公里，只要在申根区内，甚至去另一个国家。
- Globetrotter19（讨论 · 贡献）和City-busz（ 讨论 · 贡献）以及其他几位朋友在匈牙利的描述非常出色。但您知道，我不想在每个 5000 人城镇都看到（+- 相同）的巴洛克教堂…… :) 我想参观例如哈布斯堡王朝的某个夏宫，独特的我找不到其他地方的建筑，一些自然景点，也许还有些儿童游乐场。那种行程……最终我成功了，但不是因为 WV，我认为这很可惜，因为大部分元素（除了某种“优先级”和地图）都存在…… -- andree 06:48, 2025年9月3日 (UTC)
- 我不认为基于“必看”的任何行程都会推荐游乐场，尽管有些游乐场相当有趣（例如，我认为阿姆斯特丹 Vondelpark 中的一个游乐场很有趣，并且我认为我在阿姆斯特丹 Zuid的 Vondelpark 列表项中添加了描述，但我找不到它，所以也许我没有）。不过，独特的建筑和令人惊叹的自然景点应该在任何好的旅行指南中得到强调，这显然也包括 Wikivoyage。Ikan Kekek（讨论） 06:54, 2025年9月3日 (UTC)
- 我想到的是：您真正想要的是米其林（Michelin）过去在其纸质绿色指南中使用的那种地图，并且现在可以在线免费访问，这些地图显示了哪些城市是 3 星（值得一游）、2 星（值得绕道）和 1 星（有趣），或者不带星级，同样也包括城市内外景点的星级。那非常有用，部分原因是因为尽管米其林在他们认为有趣的事物上存在某些偏见，但我发现他们的判断相当可靠，因为他们认为有价值的东西通常确实有价值。所以是的，我非常看好那种地图的用途。然而，要创建我们自己的地图将是项艰巨的工作，并且需要大量的辩论（依赖于基于维基百科文章搜索或其他任何内容的计算不是我们想用来替代我们自己判断的东西，否则基于社区的指南还有什么意义？）。Ikan Kekek（讨论） 07:14, 2025年9月3日 (UTC)
- 如果这就是人们想要的，我愿意参与此类讨论。如果您想这样做，请在纽约讨论页开启一个讨论串，等等。我们以前尝试过，但我们可以再试一次……Ikan Kekek（讨论） 07:19, 2025年9月3日 (UTC)
- 这种排名听起来很有用，它可以帮助我们某种程度上对我们的文章进行分类/排序……基于维基百科搜索的排名只是一个比什么都不做更好的可能性（我认为） :) -- andree 07:28, 2025年9月3日 (UTC)
- 这很有意思。shb (t | c | m) 08:37, 2025年9月3日 (UTC)
- 我们需要决定的事情之一是，我们是尝试像米其林过去那样进行绝对的全球星级排名（并且可能在其纸质绿色指南中仍然如此），还是进行按区域排名，并且我们是否将决定哪些城市（等）值得 3 星、2 星、1 星或无星，或我们想使用什么其他区分。需要考虑的一件事是，据我记忆，从 20 世纪 90 年代起，当我仍然使用纸质指南时，米其林在罗马有许多 3 星和 2 星景点，但有几十个 1 星教堂，因为例如罗马相当小的教堂可能也有著名艺术家的好作品并且是漂亮的建筑，以至于它们在意大利更小的城市中轻易就能成为顶级景点。我非常怀疑纽约州哈德逊的新哥特式圣玛丽教堂会获得米其林的任何星级，因为虽然它是那个风景如画的小城市中遇到的一个非常漂亮的建筑，并且有很好的彩色玻璃窗，但它无法与罗马的教堂相提并论，例如 Sant'Andrea della Valle，一个我在住在附近 Via Arenula 的酒店时很喜欢参观的教区教堂。然而，我认为它是哈德逊的一个重要景点，尽管令人惊讶的是，除了 Wikivoyage（因为我列出了它）之外，我在任何指南中都没有看到它。Ikan Kekek（讨论） 08:56, 2025年9月3日 (UTC)
- 嗯，这就是全部。如果我在纽约，我可能不会花 2x2 小时去看那座教堂——但也许如果我从纽约去奥尔巴尼，并在那里停留一小会儿，那就有意义了。另一方面，现在的问题是，如果提出的排名在这里有帮助。我猜整个路线都会充斥着 1 星的城市，所以您还是会逐个点击并阅读……-- andree 09:39, 2025年9月3日 (UTC)
- 我认为，如果我们要复制全球性的星级排名标准，它最好是与地区相关的。一个位于拥有 500 万人口的大都市区的教堂可能对大多数旅行者来说并不那么有趣（可能得零星），但一个位于只有 500 人口的小镇的教堂可能是镇上最突出的景点（可能会得到两星）。现在我并不熟悉米其林的标准，所以请将我的星级评分仅作参考，但我的主要观点是避免一刀切的标准。//shb (t | c | m) 09:52, 3 September 2025 (UTC)
- 如果遵循米其林的足迹，最多只会有一两个一星级城市。大多数将是未评级的。我希望我能在线找到关于它们的信息供大家链接，除了在w:米其林指南#绿色指南中有一段简短的介绍外，但我在网上搜索“米其林星级景点列表”等信息时，没有找到其他有用的内容。不过，看看那一段还是值得的。
- 《米其林绿色指南》评论和评定餐厅以外的景点。有针对整个法国的《绿色指南》，以及针对法国境内十个地区的更详细的指南。其他《绿色指南》涵盖了法国以外的许多国家、地区和城市。《绿色指南》中有许多以多种语言出版。它们包含背景信息和按字母顺序排列的景点描述部分。与《红色指南》一样，它们使用三颗星的系统来推荐景点，从“值得一游”到“值得绕道”，再到“有趣”。
- 我相信我很久以前就扔掉了我 90 年代的绿色指南，但米其林的高标准体现在，尽管托斯卡纳地区的大多数村庄都没有获得星级，但其中的一些地方（很可能是大教堂或至少是教堂）本身就获得了一颗星，而且其中绝大多数都非常美丽。我相信我记得阿恰诺就是这样。当然，佛罗伦萨和锡耶纳获得了 3 星，但我认为阿雷佐最多只获得了 2 星，而科尔托纳只获得 1 星，因为尽管那里有几个很棒的景点（尤其是它的小大教堂，作为一个景点获得了至少 2 星），但除此之外就没什么了，只有一个很棒的景色，而且从很多山村都可以看到很棒的景色（我认为在此基础上这是一个公平的评价）。我很确定圣吉米尼亚诺获得了 3 星，因为除了地理位置优越之外，它作为一个小镇拥有令人难以置信的景点。
- 如果有人有美国地区的绿色指南那就太好了，但按照那个标准，如果我想到我曾去过的普基普西以北的哈德逊河谷地区，金斯顿会获得一星或两星，哈德逊也是如此（可能是一星，但奥拉纳作为一个景点至少会获得两星），特洛伊也是，萨拉托加可能会获得两星，科霍斯可能会获得一星，奥尔巴尼会获得一星，因为它是一个州府，有一个有趣的区域和一些可能不错的博物馆我没去，我想就这些了。莱茵贝克没有机会获得星级，尽管那里有一些教堂和相关的墓地有有趣的 D 历史，但我从未有过足够的动力去写，而且那些或多或少令人愉快和风景如画的村庄都没有星级。新帕尔茨会获得一星，但它更靠南。哈德逊沿岸的一些威彻斯特郡的郊区可能会获得一星，但除非除了景色之外还有其他东西，否则不会，所以扬克斯有哈德逊河博物馆和那个我记不起名字的花园，也许还有睡谷因传说（米其林的人喜欢这类东西）。不确定还有什么了。Ikan Kekek （讨论） 15:19, 3 September 2025 (UTC)
- 嗯，这就是全部。如果我在纽约，我可能不会花 2x2 小时去看那座教堂——但也许如果我从纽约去奥尔巴尼，并在那里停留一小会儿，那就有意义了。另一方面，现在的问题是，如果提出的排名在这里有帮助。我猜整个路线都会充斥着 1 星的城市，所以您还是会逐个点击并阅读……-- andree 09:39, 2025年9月3日 (UTC)
- 我们需要决定的事情之一是，我们是尝试像米其林过去那样进行绝对的全球星级排名（并且可能在其纸质绿色指南中仍然如此），还是进行按区域排名，并且我们是否将决定哪些城市（等）值得 3 星、2 星、1 星或无星，或我们想使用什么其他区分。需要考虑的一件事是，据我记忆，从 20 世纪 90 年代起，当我仍然使用纸质指南时，米其林在罗马有许多 3 星和 2 星景点，但有几十个 1 星教堂，因为例如罗马相当小的教堂可能也有著名艺术家的好作品并且是漂亮的建筑，以至于它们在意大利更小的城市中轻易就能成为顶级景点。我非常怀疑纽约州哈德逊的新哥特式圣玛丽教堂会获得米其林的任何星级，因为虽然它是那个风景如画的小城市中遇到的一个非常漂亮的建筑，并且有很好的彩色玻璃窗，但它无法与罗马的教堂相提并论，例如 Sant'Andrea della Valle，一个我在住在附近 Via Arenula 的酒店时很喜欢参观的教区教堂。然而，我认为它是哈德逊的一个重要景点，尽管令人惊讶的是，除了 Wikivoyage（因为我列出了它）之外，我在任何指南中都没有看到它。Ikan Kekek（讨论） 08:56, 2025年9月3日 (UTC)
- 这很有意思。shb (t | c | m) 08:37, 2025年9月3日 (UTC)
- 我想知道这其中有多少是关于在一个大型目的地中突出最佳景点，还是说在您已经驱车往返于 X 和 Y 之间时，要选择在哪个城市停留。我认为行程可能是更好的模式：去这里看这个，然后去那里看那个，如果您对某个东西感兴趣，就顺道去一下……WhatamIdoing （讨论） 19:50, 3 September 2025 (UTC)
- 2002 年在法国自驾游时，我使用了一本米其林绿色指南，以帮助我 spontanous 地决定是否要从高速公路绕道而行。我哥哥开车，我坐在他旁边，看着米其林地图，并给他读了些关于高速公路出口附近景点的内容。因此，除了我们计划在旅行前参观的其他地方外，我们还参观了塞米尔、索米尔和勒芒。米其林对城市和景点的星级评分有帮助，但他们的描述也有帮助。
- 我绝对认为可以使用 Wikivoyage 以同样的方式（我至今尚未尝试 - 自从我父亲病重以及父母随后去世以来，就没有家庭公路旅行了），但这个网站在内容覆盖方面的不一致性，以及成员们选择撰写哪些内容，造成了不可避免的标准化缺乏。考虑到维基百科固有的缺点，它们能做得这么好真是太棒了！Ikan Kekek （讨论） 21:03, 3 September 2025 (UTC)
- 我在{{mustsee}} 制作了一个小示例，并在南堪培拉、基亚马和巴德鲁国家公园实施了它——您对此有什么看法？shb (t | c | m) 06:12, 2025年9月3日 (UTC)
- 摘要文本很好，一旦您进入相应的城市。我的问题在于别处。我无法阅读 200 篇这样的文章，即使它们都有顶级的概述……我宁愿使用谷歌地图在一个区域内搜索“景点”，然后挑选那些有 100 多条评论的，例如。但 IMO WV 可以轻易做到这一点，如果我们能在“必看”标签上做到的话。-- andree 06:10, 2025年9月3日 (UTC)
- 对于一些城市，例如阿格拉，关键景点在文章的引言中就提到了。Pashley （讨论） 20:26, 3 September 2025 (UTC)
- 当您有一个大都会区的文章，下面有城市，或者一个有很多区域的大城市时，顶层文章可以提及最重要的景点，而将细节和较少的景点留给其他文章。例如，上海#景点和宿务都会区#景点。这对于旅游景点以外的事物也同样适用，例如，请看上海#服装。Pashley （讨论） 20:34, 3 September 2025 (UTC)
- 我发现，区域文章通常不如其内部的城市文章完整。这在一定程度上是由于志愿内容提供者的性质。为刚去过的地方添加内容要容易得多。要写一个区域，理想情况下您需要对该区域的大部分地区有所了解，这需要更长的访问时间来探索整个区域，而不是在一个城市进行一个周末的旅行——要将多个编辑者对城市的内容汇总成区域指南要困难得多。
- 商业指南在这方面有优势——一家传统的指南公司会付费让作者花几周时间游览该地区。评论网站有大量的数据可以处理——TripAdvisor 可以根据 4 星评论的数量进行过滤，Google 可能知道有多少 Android 手机访问过一个地点（用户设置允许等）。AlasdairW （讨论） 21:06, 3 September 2025 (UTC)
维基新闻时代终结
你们有些人可能还记得我们在这里进行的关于该网站的讨论——似乎他们已经在m:关闭维基新闻的提案上起草了报告，我认为值得一读。一方面，我认为令人遗憾的是，最终结果是锁定了所有维基新闻项目，而没有真正咨询维基新闻社区（SPTF 甚至声称这是明显的利益冲突），并且驳回了提出的真实建议，这给人一种印象，他们因为该提案最初引起了多少反对意见而更倾向于威权主义的方法（而且我也觉得他们是预设了结果）。
我认为 Wikivoyage 的我们不必过于担心，主要有两个原因——a) Wikivoyage 的信息在很大程度上仍然相关，即使在 20 或 25 年后（与 Wikinews 不同，其内容在 2-3 周后就会变得无关紧要）；b) 尽管存在许多空白，Wikivoyage 仍然是世界大部分地区可行的旅游网站。话虽如此，我认为现在是开始讨论我们如何才能真正与 Google、LonelyPlanet 或 Expedia 等主要旅游网站竞争的好时机，即使这不会带来改变，这样我们就能在大局中保持相关性，并且我们的内容能被旅行者阅读。无论如何，安息吧，维基新闻，令人难过的是，一个有缺陷的咨询过程竟然是它结束的方式。//shb (t | c | m) 11:51, 4 September 2025 (UTC)
- 几个想法。首先，我承认我不知道全部的背景，但这似乎只是一个提案。假设该提案可能被拒绝？
- 一个有价值的资源是关于每个项目编辑次数、页面浏览量等的数据，虽然提案中显示了该工具的图表，但我在这里找不到提到的实际网页。在我看来，我们应该审视哪些文章的阅读量最高，并从中吸取教训。从我看到的信息选项卡来看，旅游主题的表现比我们想象的要好得多，而且它们的维护比目的地文章少。也许我们应该增加我们的旅游主题和行程的提供，这肯定会增加我们网站与其他竞争对手如 LonelyPlanet 之间的区别。我还认为我们应该就车站文章达成共识，如果我们想永久性地创建一种新类型的文章，就应该扩大我们在该领域的提供。
- 听起来很奇怪，我们可能受困于拥有太多的目的地（尤其是城市）文章。人口稀少的地区，如北达科他州，甚至最小的城镇都有文章，而这些地方的编辑者不足以及时更新列表。我不确定解决这个问题的最佳方法是什么，但我认为过去有过一次创建然后删除空骨架文章的浪潮。
- 如果维基新闻确实下线，那么时机似乎不合适。在新闻机构（PBS、NPR）被削减资金的时候，不是关闭该项目 Thus 的最佳时机，肯定不是。我确实认为该提案提出了一个令人信服的论据，即维基新闻的现状不足，但我认为这应该导致改革而不是完全关闭。--评论者 Selfie City （讨论） （贡献） 12:45, 4 September 2025 (UTC)
- 根据 SPTF 在咨询页面上的行为方式，我们可以非常肯定他们预设了结果（尤其是因为他们事先也没有咨询维基新闻社区），并且报告中没有提到维基新闻的任何积极方面。这是我见过的 WMF 章程中最为严重的“打勾式”咨询之一。//shb (t | c | m) 12:59, 4 September 2025 (UTC)
- 我意识到这是一个完全题外话，但任何关于文章的真人编辑次数的计算都必须排除 Brendan 重复编辑赤道几内亚文章或破坏尼日利亚文章的情况。Ikan Kekek （讨论） 14:30, 4 September 2025 (UTC)
- 据我所知，我不认为计算 WN 的人数时排除了任何真人编辑——虽然我可能错了。//shb (t | c | m) 14:35, 4 September 2025 (UTC)
- 也许我们可以排除标记为“已撤销/回滚”的编辑。--评论者 Selfie City （讨论） （贡献） 19:35, 4 September 2025 (UTC)
- 据我所知，我不认为计算 WN 的人数时排除了任何真人编辑——虽然我可能错了。//shb (t | c | m) 14:35, 4 September 2025 (UTC)
- 我意识到这是一个完全题外话，但任何关于文章的真人编辑次数的计算都必须排除 Brendan 重复编辑赤道几内亚文章或破坏尼日利亚文章的情况。Ikan Kekek （讨论） 14:30, 4 September 2025 (UTC)
- “假设该提案可能被拒绝？”是的。您可以在m:Sister Projects next steps 的意见征询上发表您的声音，并查看其他评论（现已关闭）在m:Talk:Public consultation about Wikinews。这将在今年晚些时候进行审查以做出任何决定。——Justin (koavf)❤T☮C☺M☯ 16:46, 4 September 2025 (UTC)
- SPTF 已经很好地表现出了故意无知；理论上您可以这样做，但他们已经多次证明他们不感兴趣听取反对意见。//shb (t | c | m) 22:18, 4 September 2025 (UTC)
- 毫不夸张地说，这也是为什么m:Sister Project Task Force 成员的关闭意见征询似乎已经出现（我确实希望 WMF 能注意到 SPTF 在社区中不受欢迎——大多数反对意见只是人们说社区不能关闭 WMF 指定的章程）。//shb (t | c | m) 22:31, 4 September 2025 (UTC)
- SPTF 已经很好地表现出了故意无知；理论上您可以这样做，但他们已经多次证明他们不感兴趣听取反对意见。//shb (t | c | m) 22:18, 4 September 2025 (UTC)
- 根据 SPTF 在咨询页面上的行为方式，我们可以非常肯定他们预设了结果（尤其是因为他们事先也没有咨询维基新闻社区），并且报告中没有提到维基新闻的任何积极方面。这是我见过的 WMF 章程中最为严重的“打勾式”咨询之一。//shb (t | c | m) 12:59, 4 September 2025 (UTC)
- 关于我的推测/猜想/看法，我会说 WMF 的各个项目处于以下分层：
- 安全/成功:
- 维基百科
- Wiktionary
- Wikidata
- 共享资源
- Wikispecies
- MediaWiki
- 安全/合格的成功:
- 维基文库
- Wikiquote
- 维基旅游
- 不太安全/合格的失败:
- Wikibooks
- 维基学院
- 其他:
- 维基新闻（可能关闭，重大重组）
- 维基功能（太新无法评估，范围非常小且狭窄）
- 安全/成功:
- 我认为没人盯上英文 Wikivoyage，否则当时就会提到了。我在咨询过程中对维基新闻一直很直言不讳，虽然我认为可能关闭的提议是错误的，但我对那些只是在履行职责的人受到的一些诽谤感到失望。事实是，维基新闻一直挣扎和失败。我不认为这是固有的失败，我个人也继续在英文维基新闻上做贡献：我仍然相信它。但一些用户将批评和提议视为一种攻击，并以一种我认为不合理的方式进行反击。仅仅因为没有人愿意忍受这种戏剧性，我就不认为会有任何关闭其他项目的严肃提议，即使有，维基大学和可能还有维基图书也会排在维基旅行之前。
- 顺便说一句，如果管理员能处理一下Template_talk:WikivoyageSister#Wikifunctions，那就太好了。谢谢。——Justin (koavf)❤T☮C☺M☯ 16:54, 4 September 2025 (UTC)
- 谢谢你的帖子，但由于我不认识你帖子中使用的所有维基缩写，我敢肯定其他读者也不认识。所以如果你选择解释它们代表什么，你就是在做一件好事。我将开始说明 wp=Wikipedia, wikt=Wiktionary, d 可能是 Wikidata, c 是 Commons, species 是清楚的, voy=Wikivoyage, wn=Wikinews。我不认识其他的。Ikan Kekek （讨论） 17:10, 4 September 2025 (UTC)
- 抱歉，我写得太简略了。修改中。——Justin (koavf)❤T☮C☺M☯ 17:14, 4 September 2025 (UTC)
- 谢谢，很感激。Ikan Kekek （讨论） 22:49, 4 September 2025 (UTC)
- @Koavf：您认为什么区别了三个合格的成功项目与成功的项目，以及反过来什么区别了我们与维基图书和维基大学（合格的失败项目）？--评论者 Selfie City （讨论） （贡献） 00:25, 5 September 2025 (UTC)
- 我认为，“成功的”项目都非常活跃，并且总体上非常成功地满足了人们的需求。例如，如果您想知道一个词的意思（尤其是在英语中），并在 Wiktionary 上查找，您很可能会找到答案。对于那些合格的成功项目，您可能会得到您想要的东西，而且内容相当多，但也有一些大的空白。对于半失败的项目，需要做大量的工作才能使其有用。我通常是这样看待的。——Justin (koavf)❤T☮C☺M☯ 00:38, 5 September 2025 (UTC)
- 有道理。您认为 Wikivoyage 的漏洞在哪里？我认为近年来我们在大纲文章方面取得了很大进展，但许多小城镇和郊区的文章仍然过时。但我想，问题是，是否有人真的想去那些城镇旅行？在我看来，这是社区需要长期解决的问题。
- 话虽如此，自 2012 年以来，甚至自 Covid 以来，Wikivoyage 的有用文章与大纲文章的比例都得到了惊人的改善。我确实有很高的希望，如果我们继续保持这种进步，几年内我们就能达到 Commons、WikiSpecies 等的水平。--评论者 Selfie City （讨论） （贡献） 11:33, 5 September 2025 (UTC)
- 漏洞是一些缺失的地点/主题，但主要是过时的信息、臃肿和缺乏多媒体。我认为这个项目总体上是成功的，以至于您可能可以用它来规划去许多地方的旅行。我从未去过布法罗（纽约州）或波士顿，我认为，如果我只是阅读我们的指南并做一些对我来说有意义的事情，我可能会过得愉快，但我也认为我可能会错过一些我们没有涵盖的东西，而且我们没有理想中的那种交互功能（例如，规划路线并将其连接到地图应用程序）。至于主题，我偶尔会提供我关于我们可以谈论什么的想法，最近一次我在这里抛出一个有点像提案的想法是在这里，在那里我建议我们应该有更多自由形式和轶事性的材料，鼓励那种漫步和故意迷路的旅行方式，这在旅行中会很有趣。我还考虑过重新引入多年前这里曾存在的个人旅行博客。如果这是一个包含更多引人入胜和有趣的材料作为实际阅读材料的网站，那在我看来也将是理想旅行指南的一部分。
- 说到不寻常的事，想象一下 Wiktionary，它是一个词典，但我们也添加了同义词词典、音频发音和图片等多媒体来补充条目，还有附录提供更琐碎的信息等等。这是为了尽可能健壮地为关于词语和术语的参考书提供人们想要的一切。如果这个网站只是一堆“去地方，看东西”的列表，那是有价值的，但如果您想到旅行指南能做到的最好事情，那么我们可以在原则上（但不一定在实践中，因为资源是有限的）扩大我们的视野。
- 很有趣。我认为我们有反对多媒体的政策。
- 关于缺失的地点和主题，您能举些例子吗？我估计我们在旅游主题方面比地点有更多的漏洞。
- 我没有技术知识，但也许我们可以找到一种方法将行程路线图上的线路导出到 GPS 或 OSM 应用程序？如果我们能做到这一点，我们就可以解决您提到的关于行程的另一个问题。--评论者 Selfie City （讨论） （贡献） 14:52, 5 September 2025 (UTC)
- 是的，我们确实有一项政策，将媒体置于纸质打印件之后，这绝对不是 99% 的用户会使用此网站的方式。这是荒谬的，而且可能也不是用户在 2003 年使用此网站的方式。只需想象一下完美的旅行指南会是什么样子，而在那里没有交互式媒体和实际动态规划路线并连接到地图或导航功能的可能性，这是不可能的。至于主题，我偶尔会提供我关于我们可以讨论什么的想法，我上次抛出一个有点像提案的想法是在这里，在那里我建议我们应该有更多自由形式和轶事性的材料，鼓励那种漫步和故意迷路的旅行方式，这在旅行中会很有趣。我还考虑过重新引入多年前这里曾存在的个人旅行博客。在我看来，如果这是一个包含更多引人入胜和有趣的材料作为实际阅读材料的网站，那也将是理想旅行指南的一部分。
- 为了更详细地说，如果您想象 Wiktionary，它是一个词典，但我们也添加了同义词词典、音频发音和图片等多媒体来补充条目，还有附录提供更琐碎的信息等等。这是为了尽可能健壮地为关于词语和术语的参考书提供人们想要的一切。如果这个网站只是一堆“去地方，看东西”的列表，那是有价值的，但如果您想到旅行指南能做到的最好事情，那么我们可以在原则上（但不一定在实践中，因为资源是有限的）扩大我们的视野。
- 我认为，我们应该从能够打印我们的指南的优先事项中走出来，在如今手机信号无处不在的时代。如今，大多数人甚至不使用打印机了。
- 我们网站目前面临的挑战之一是，我们很少有人根据他们刚刚去过的地方来写作。您说得对，如果我们能有旅行者撰写的引人入胜的行程，就能提高网站质量。这样的文章，主观性更强，时效性信息更少，需要更少的维护来保持相关性。
- 所以，我同意我们不应优先考虑打印页面，但仍然存在一些地方几乎没有手机信号，而且它们并非都是非常偏远的。有人能告诉我，太平洋海岸公路长达 70 英里的地方是否仍然没有手机信号吗？我的感觉是，虽然打印指南不应成为本网站的主要重点，但我们仍应确保有足够的可打印内容，以供那些冒险进入没有手机信号区域的人们使用。Ikan Kekek （讨论） 20:04, 6 September 2025 (UTC)
- 原则上同意，并且也同意我们需要为最重要的问题提供最大的便利：例如，视觉障碍者的可访问性，或者为连接不稳定的用户提供页面服务的能力等。打印当然是一个考虑因素，对于少数用户来说可能很重要，但一个人通过互联网访问这些材料的情况要普遍得多，而且通常使用的是具有地图和导航功能的便携设备。对我们来说，完全没有与这些基本功能集成，至少可以说是一个缺陷。——Justin (koavf)❤T☮C☺M☯ 21:54, 6 September 2025 (UTC)
- 是的，太疯狂了！Ikan Kekek （讨论） 22:17, 6 September 2025 (UTC)
- 同意——尽管如此，从我推断来看，我们已经取得了很大的进步，尤其是考虑到我们有点被 WMF 忽视了。大多数文章不再偏爱静态地图，而缺少能够制作静态地图的贡献者在某种程度上是有益的。我们已经转向与 OSM 更好地集成，尤其是在地图形状方面。取得了许多进展，但仍有很长的路要走。//shb (t | c | m) 00:12, 7 September 2025 (UTC)
- 是的，太疯狂了！Ikan Kekek （讨论） 22:17, 6 September 2025 (UTC)
- @Ikan Kekek, SelfieCity： 我以前是那种会把东西打印出来带到信号不好或没有信号的地方（我经常这样做）的人，但现在我只会把 PDF 副本保存在手机上。如今大多数手机的存储空间都不是问题，所以我认为值得修改我们的政策，使其稍微宽松一些。//shb (t | c | m) 00:03, 7 September 2025 (UTC)
- 原则上同意，并且也同意我们需要为最重要的问题提供最大的便利：例如，视觉障碍者的可访问性，或者为连接不稳定的用户提供页面服务的能力等。打印当然是一个考虑因素，对于少数用户来说可能很重要，但一个人通过互联网访问这些材料的情况要普遍得多，而且通常使用的是具有地图和导航功能的便携设备。对我们来说，完全没有与这些基本功能集成，至少可以说是一个缺陷。——Justin (koavf)❤T☮C☺M☯ 21:54, 6 September 2025 (UTC)
- 所以，我同意我们不应优先考虑打印页面，但仍然存在一些地方几乎没有手机信号，而且它们并非都是非常偏远的。有人能告诉我，太平洋海岸公路长达 70 英里的地方是否仍然没有手机信号吗？我的感觉是，虽然打印指南不应成为本网站的主要重点，但我们仍应确保有足够的可打印内容，以供那些冒险进入没有手机信号区域的人们使用。Ikan Kekek （讨论） 20:04, 6 September 2025 (UTC)
- 漏洞是一些缺失的地点/主题，但主要是过时的信息、臃肿和缺乏多媒体。我认为这个项目总体上是成功的，以至于您可能可以用它来规划去许多地方的旅行。我从未去过布法罗（纽约州）或波士顿，我认为，如果我只是阅读我们的指南并做一些对我来说有意义的事情，我可能会过得愉快，但我也认为我可能会错过一些我们没有涵盖的东西，而且我们没有理想中的那种交互功能（例如，规划路线并将其连接到地图应用程序）。至于主题，我偶尔会提供我关于我们可以谈论什么的想法，最近一次我在这里抛出一个有点像提案的想法是在这里，在那里我建议我们应该有更多自由形式和轶事性的材料，鼓励那种漫步和故意迷路的旅行方式，这在旅行中会很有趣。我还考虑过重新引入多年前这里曾存在的个人旅行博客。如果这是一个包含更多引人入胜和有趣的材料作为实际阅读材料的网站，那在我看来也将是理想旅行指南的一部分。
- 作为 Wikibooks 的管理员，我可能是因为存在大量不完整或被放弃的书籍，再加上参与度低。与 Wikipedia、Wikivoyage 或 Wikisource 不同，您在 Wikibooks 上撰写书籍之前需要对主题有相当的了解（因此，关于同一篇文章的合作并不多）。清理许多旧书/被放弃的书籍需要一个漫长的过程，但这至少已经进行了一年多了。//shb (t | c | m) 00:39, 5 September 2025 (UTC)
- 同意。而且教科书的好处在于您可以回来完成它。新闻则不然：如果新闻没有完成或写出来，它就不再是新闻了。——Justin (koavf)❤T☮C☺M☯ 00:40, 5 September 2025 (UTC)
- 是的，这就是为什么我认为维基新闻的整个前提从一开始就有点问题（这也是为什么在 SPTF 咨询之前我就支持关闭许多小型维基新闻项目）。//shb (t | c | m) 00:50, 5 September 2025 (UTC)
- 同意。而且教科书的好处在于您可以回来完成它。新闻则不然：如果新闻没有完成或写出来，它就不再是新闻了。——Justin (koavf)❤T☮C☺M☯ 00:40, 5 September 2025 (UTC)
- 我认为，“成功的”项目都非常活跃，并且总体上非常成功地满足了人们的需求。例如，如果您想知道一个词的意思（尤其是在英语中），并在 Wiktionary 上查找，您很可能会找到答案。对于那些合格的成功项目，您可能会得到您想要的东西，而且内容相当多，但也有一些大的空白。对于半失败的项目，需要做大量的工作才能使其有用。我通常是这样看待的。——Justin (koavf)❤T☮C☺M☯ 00:38, 5 September 2025 (UTC)
- @Koavf：您认为什么区别了三个合格的成功项目与成功的项目，以及反过来什么区别了我们与维基图书和维基大学（合格的失败项目）？--评论者 Selfie City （讨论） （贡献） 00:25, 5 September 2025 (UTC)
- 谢谢，很感激。Ikan Kekek （讨论） 22:49, 4 September 2025 (UTC)
- 抱歉，我写得太简略了。修改中。——Justin (koavf)❤T☮C☺M☯ 17:14, 4 September 2025 (UTC)
- 抱歉，但我不同意对批评的回应是不合理的。一个委员会审查项目时最合适的做法是直接与项目联系，并与他们合作，共同改进项目。然而，SPTF 没有这样做——他们同时通知了 Wikinews 和所有其他项目（见我之前的消息中的链接）。您可以争辩说这可能是真正的错误，但当这个问题被反复提出时，SPTF 要么对所有关于缺乏沟通的批评几乎没有回应，要么 Victoria 通过声称参与涉及您母项目的咨询是所谓的利益冲突来进一步强调。当您如此糟糕地咨询社区，甚至不试图掩饰时，以这种方式做出反应是一种完全正常的人类反应。//shb (t | c | m) 00:33, 5 September 2025 (UTC)
- 在过去的十年里，英文 Wikivoyage 的页面浏览量大约是英文 Wikinews 的 2.5 倍。当然还有其他语言，但英语通常是所有维基媒体维基中最大的，所以比较起来最容易。另外，如果您仔细查看统计数据，近年来 Wikivoyage 和 Wikinews 之间的差距一直在扩大。所以我认为我们在短期内是相当安全的。至于我们如何发展，有很多东西需要拆解，但我仍然认为，除了那些保持不变的传统 W 旅游内容之外，许多编辑者没有充分地改写从 Wikipedia 引入的内容。有句子被逐字添加，这 1. 在我们的文章语气应该更随意有趣而不是平淡技术性的 Wikipedia 时是不合适的，2. 重复的内容继续在 SEO 排名中惩罚我们。例如，有许多文章介绍了柯本气候分类。一个城市的关于气候和天气的部分应该写得好像你在和一个想去你最近去过的地方旅行的朋友说话一样。我们的大部分文章都应该这样写。我注意到互联网用户点击搜索链接的次数不像以前那么多，因为他们通常只阅读顶部的 AI 摘要（有趣的是，AI 经常以维基百科作为其摘要的主要来源），但认真规划旅行的旅行者仍然会想要细节并进一步点击。
- 另一个大问题是缺乏在线应用程序。如果我们继续只依赖一个网站 URL，Wikivoyage 的读者将会继续偏向桌面和笔记本电脑用户，而不是平板电脑和手机用户（这是年轻一代花费更多时间的地方）。不幸的是，解决这个问题不在我们的掌控之中，因为为 Wikivoyage 开发应用程序不是 WMF 的优先事项。Gizza (roam) 01:10, 5 September 2025 (UTC)
- 我认为，这正是最有可能在未来几年内扼杀 Wikivoyage 的事情。Ikan Kekek （讨论） 01:14, 5 September 2025 (UTC)
- 哦，绝对是——这将是几乎所有非维基百科的维基媒体项目的毁灭（目前 Commons 只有一个 Android 应用）。//shb (t | c | m) 01:35, 5 September 2025 (UTC)
- IMO，即使是移动端优化的网站的网页包装也比什么都没有好，而且我经常喜欢下载各种移动端优化的网站作为渐进式 Web 应用程序，特别是当 Play 商店（或者如果您使用的是 iOS，就是 App Store）没有原生版本时。Sbb1413 (他) （讨论 • 贡献） 02:24, 5 September 2025 (UTC)
- 也许是题外话，我在 Wikimania 举办前不久提名内罗毕为 DotM，期望一些与会者会阅读和使用该文章，注意到提名横幅，并编辑/更新该文章，或者即使只是添加一点点内容。除了两次 Brendan 的编辑外，文章历史记录显示自那时以来零编辑。不幸的是，Wikivoyage 似乎对其他维基的编辑者不感兴趣或没有吸引力，即使是在他们旅行期间和之后 :( . --Ypsilon （讨论） 04:37, 5 September 2025 (UTC)
- 我认为有一个旅行指南应用程序使用了Wikivoyage的内容，但它是非官方的，而且更新不频繁。来自其他项目（尤其是Wikipedia）的更多用户会非常有帮助，即使我们的政策不尽相同。 --评论来自 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)
- @SHB2000 不想要离线应用程序（这确实是应用程序唯一合理的用途），而你想要的是一个浏览器包装器，这样用户就不需要将wikivoyage.org输入到浏览器里了……奇怪的时代 :-D -- andree 2025年9月5日 15:48 (UTC)
- “对于其他维基的编辑者来说，即使在旅行期间和旅行之后，似乎也并不有趣或吸引人”：我在想，如果有什么类似“OSM notes”的东西对这个有用。基本上，有一个“建议更改”的浮动图标用于条目？也许甚至有一个只是将建议发布到讨论页就足够了？并且理想情况下，我们应该有一个这样的建议列表，以便有效地处理/拒绝它们……这可能只对不太常去的地区有用，因为大城市通常覆盖得很好，甚至不需要更改。-- andree 2025年9月6日 08:05 (UTC)
- 我认为有一个旅行指南应用程序使用了Wikivoyage的内容，但它是非官方的，而且更新不频繁。来自其他项目（尤其是Wikipedia）的更多用户会非常有帮助，即使我们的政策不尽相同。 --评论来自 Selfie City (讨论) (贡献) 2025年9月5日 11:40 (UTC)
- 也许是题外话，我在 Wikimania 举办前不久提名内罗毕为 DotM，期望一些与会者会阅读和使用该文章，注意到提名横幅，并编辑/更新该文章，或者即使只是添加一点点内容。除了两次 Brendan 的编辑外，文章历史记录显示自那时以来零编辑。不幸的是，Wikivoyage 似乎对其他维基的编辑者不感兴趣或没有吸引力，即使是在他们旅行期间和之后 :( . --Ypsilon （讨论） 04:37, 5 September 2025 (UTC)
- IMO，即使是移动端优化的网站的网页包装也比什么都没有好，而且我经常喜欢下载各种移动端优化的网站作为渐进式 Web 应用程序，特别是当 Play 商店（或者如果您使用的是 iOS，就是 App Store）没有原生版本时。Sbb1413 (他) （讨论 • 贡献） 02:24, 5 September 2025 (UTC)
- 哦，绝对是——这将是几乎所有非维基百科的维基媒体项目的毁灭（目前 Commons 只有一个 Android 应用）。//shb (t | c | m) 01:35, 5 September 2025 (UTC)
- 我认为，这正是最有可能在未来几年内扼杀 Wikivoyage 的事情。Ikan Kekek （讨论） 01:14, 5 September 2025 (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 的社群活跃。
- 长篇内容
- Wikinews 的页面浏览量只有 20% 是来自人类用户。在三个月内，所有 Wikinews 的总共获得了 1000 万次人类读者的页面浏览量。仅英文 Wikivoyage 在过去三个月就获得了 30 倍于此的浏览量。Wikinews 的“访客”大部分显然不是在寻找新闻文章，因为最受欢迎的搜索词中有 90% 是俄语的，并且是关于婴儿名字的。（我没有开玩笑：“日本女性名字”、“韩国名字”、“穆斯林女孩的好名字”等等。）
- 人类读者不访问这些网站也就不足为奇了，因为 Wikinews 几乎不写任何文章。例如，当我大约在七月份检查时，德语 Wikinews 在前一个月总共只写了一（1）篇文章；那是一篇略带宣传性质的、由一个新手撰写的关于一位小政客的文章。俄语 Wikinews 上的几乎所有内容都是机器人从其他新闻网站复制粘贴的免费内容——正如 Wikivoyage 比大多数人都清楚的那样，这会杀死 SEO。搜索引擎会索引页面（爬虫机器人占 Wikinews 流量的 70%），但排名较低。例如，enwikinews 的特色文章是关于德国失业率的；搜索关于“德国失业率 2025”的信息会将其排在结果的第二页——这算是不错的结果了。如果你将文章的完整标题复制粘贴到其他搜索引擎中，Bing 会将 Wikinews 排在第一页的中部，而 Yahoo! 和 DuckDuckGo 都会将 Wikinews 排在第二页。我们不指望简单的搜索“伦敦”会使 Wikivoyage 排在前面，但如果你搜索我们一个较长或更独特的页面标题，例如 Itinerary of the Opera dei Pupi，Wikivoyage 通常会排在第一页（在此示例中，Google 将我们列为第一）。
- 英文 Wikinews 在讨论早期报告说他们改进了产出：他们之前官方每月发布 8 篇新闻文章，最近达到了 9 篇的里程碑。相比之下，在英文 Wikivoyage，我们上个月创建的文章数量大约是这个数字的十倍，考虑到一家报纸可以轻松地在一个月内写一百篇关于一个小城市的新闻文章，而我们几乎只能为同一个城市创建一篇条目，这尤其令人印象深刻。委员会对 Wikinews 的一个问题是，如果你每三四天写一篇新闻文章，你并没有真正实现向人们普及世界动态的目标。
- 内容创作不足的原因之一是核心社群非常小（例如，中文 Wikinews 主要由三位编辑撰写；德语 Wikinews 基本由一位编辑撰写）。在最活跃的英文 Wikinews 社群讨论页上，有几场关于他们未来的讨论。在这个讨论中，有更多的 Wikivoyage 用户在讨论 Wikinews 的未来，比整个页面上长期存在的英文 Wikinews 用户还要多。
- 许多社群似乎也没有跟上基本的维护工作。目前，英文 Wikinews 是注册编辑和管理员数量最多的项目，但在主命名空间中有18 篇条目等待“快速删除”，其中几篇被标记为纯粹的破坏，并且已经等待管理员删除几天了。他们有 17 名人类管理员。只需要其中一位每天或隔天检查一次并清空该分类即可。（这里的同一个分类当然是空的。我们的一些管理员显然会关注Special:RecentChanges，并立即清除破坏页面。）
- 如果你想阅读 Meta-Wiki 上的讨论，请记住，很多评论都是 Wikinews 编辑在处理他们的情绪。一位编辑说 Wikinews 被重视是因为它感觉像一份不会被解雇的工作。整个讨论感觉就像公司宣布了早已迟到的裁员后的工作场所对话。
- 我认为我们可以学到什么
- 优化长期成功。像 Wikinews 一样，并且不像 Wiktionary，我们的内容需要定期更新。这意味着一个可行的 Wikivoyage 需要比一个可行的 Wiktionary 更多的编辑者。整个运动应该普遍提高创建新语言版本的门槛，特别是对于需要最新信息的项目。我们可以通过防止过于乐观的开启来避免痛苦的关闭。
- 如果你不成长，你就在萎缩。我们应该考虑招募机会。学校社团更新他们当地的区域？要求 WMF 为新编辑资助广告宣传活动（“看看 Wikipedia 的姐妹旅行指南对你的城市有什么错误之处”？！）？在旅游会议上做演讲？举办一年一度的“Wiki Loves Tourism”活动？更早开始准备我们的生日竞赛？
- 考虑一些改变。Wikinews 讨论中的一个反复出现的主题是，长期以来的规则阻碍了条目的创建。也许我们应该重新考虑一些我们长期以来的规则。例如，如上所述，我们是否应该继续优先考虑纸质打印件？
- 如果我们不面对令人不愉快的事实，迟早会被别人替我们处理。我们可以为最小的 Wikivoyage 设立一个审查流程，并制定一个帮助他们的计划。我们知道一个运作良好的 Wikivoyage 社群是什么样的。如果来自不同语言的长期 Wikivoyage 用户能够访问，例如，印地语 Wikivoyage，并说：这是一种广泛使用的语言，具有巨大的潜力。而几乎没有条目，几乎没有编辑者，你们基本上是失败的。我们能做什么来帮忙？如果答案是任何东西都不起作用（这对于小语种来说可能是真实的，但对于印地语可能不是），那么我们应该提议关闭，而不是等待外部团体告诉我们该做什么。
- WhatamIdoing (讨论) 2025年9月6日 19:32 (UTC)
- 关于最后一点，我曾多次反对创建小型语言 Wikivoyage，但不断被驳回，很大程度上是因为 Wikivoyage 显然是少数几个在孵化后真正增长的项目之一（我对此持怀疑态度）。我不会反对创建一项政策，确保在启动前存在一定数量的条目——例如，可能包括所有 200 多个国家，一些重要的全球城市，以及重要的公园和奇观。//shb (t | c | m) 2025年9月6日 23:34 (UTC)
- @WhatamIdoing：感谢您的意见。这些都是很棒的观察。如果我们能创建一个吸引其他姐妹网站编辑者的活动，那将是极好的，正如这里的一些早期评论所述，他们中的许多人并不知道这里发生了什么。尽管我们与 Wikipedia 有所不同，但我相信许多 WP 编辑会喜欢这里的编辑过程。我最初在 Wikipedia 开始，但能够有文章的部分已经布局好（了解、查看、操作等），再加上用现实世界的知识替代引用来源，这最初吸引了我到 Wikivoyage。话虽如此，我仍然在 Wikipedia 编辑，所以我认为同样的事情也会从其他姐妹网站的作者那里带来积极的互动。 --评论来自 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)
- 哦，是的，我知道 Pi-zero——他确实在这两个项目上投入了令人难以置信的时间， enwikinews 和 enwikibooks（后者是我熟悉他的地方）。//shb (t | c | m) 2025年9月7日 19:46 (UTC)
- 这太不可思议了，因为几年前，我还记得 Wikinews 是一个及时了解重大新闻事件的优秀来源。 --评论来自 Selfie City (讨论) (贡献) 2025年9月7日 14:27 (UTC)
- 关于最后一点，我曾多次反对创建小型语言 Wikivoyage，但不断被驳回，很大程度上是因为 Wikivoyage 显然是少数几个在孵化后真正增长的项目之一（我对此持怀疑态度）。我不会反对创建一项政策，确保在启动前存在一定数量的条目——例如，可能包括所有 200 多个国家，一些重要的全球城市，以及重要的公园和奇观。//shb (t | c | m) 2025年9月6日 23:34 (UTC)
- 谢谢你的帖子，但由于我不认识你帖子中使用的所有维基缩写，我敢肯定其他读者也不认识。所以如果你选择解释它们代表什么，你就是在做一件好事。我将开始说明 wp=Wikipedia, wikt=Wiktionary, d 可能是 Wikidata, c 是 Commons, species 是清楚的, voy=Wikivoyage, wn=Wikinews。我不认识其他的。Ikan Kekek （讨论） 17:10, 4 September 2025 (UTC)
有趣
m:Wikipedia 25/Easter egg experiments 看起来像是我们可能想做的事情。 WhatamIdoing (讨论) 2025年9月14日 18:24 (UTC)
- 确实是个有趣的主意。//shb (t | c | m) 2025年9月16日 13:25 (UTC)
服务器切换 - 您的维基即将短暂变为只读模式
Wikimedia Foundation 将在其数据中心之间切换流量。这将确保 Wikipedia 和其他 Wikimedia 维基即使在灾难后也能保持在线。
所有流量将于 9月24日 切换。切换将于 15:00 UTC开始。
不幸的是，由于 MediaWiki 的一些限制，在切换过程中必须停止所有编辑。我们对此造成的干扰表示歉意，并正在努力在未来将其最小化。
将在操作开始前 30 分钟在所有维基上显示一个横幅。此横幅将一直可见，直到操作结束。您可以为该横幅文本的翻译或校对做出贡献。
您将可以在短时间内阅读所有维基，但无法编辑。
- 您将在 2025年9月24日星期三 无法编辑长达一小时。
- 如果您在此期间尝试编辑或保存，您将看到一条错误消息。我们希望在这几分钟内不会丢失任何编辑，但我们无法保证。如果您看到错误消息，请等到一切恢复正常。届时您应该可以保存您的编辑。但是，我们建议您先将更改复制一份，以防万一。
其他影响:
- 后台任务将变慢，有些可能会被丢弃。红链接可能更新不及时。如果您创建的文章已在其他地方链接，该链接将比平时更长时间地显示为红色。一些长时间运行的脚本将被停止。
- 我们预计代码部署将像往常一样进行。但是，如果操作需要，可能会有例外情况的代码冻结。
- GitLab 将不可用约 90 分钟。
此项目如有必要可能会推迟。您可以在 wikitech.wikimedia.org 阅读日程表。任何更改都将在日程表中公布。
请将此信息分享给您的社群。