维基导游:旅行者酒吧/2019

页面预览弹出窗口

我们几个月前讨论过这个问题，但根据这个讨论，我正在尝试重新启动这个讨论。不过，这次我对症状做了更多的研究

首先，回顾一下，目前维基导游的页面预览存在一个问题，即它倾向于从列表（无论是否链接 Wikidata ID）而不是文章本身获取预览图像，这远非理想，一些文章就证明了这一点

• 华盛顿特区 - 无法辨认且不具代表性的地标，
• 阿姆斯特丹/东南区 - 历史事件（Bijlmerramp）的图片。一架货机撞入公寓大楼的景象对任何人来说都远不具吸引力，更谈不上代表该地区，
• 哈勒姆和阿尔克马尔 - 火车站的图片，不代表目的地，
• 希尔弗瑟姆 - 希尔弗瑟姆机场的图片，对许多旅行者来说并无用处，因为它是一个训练场和私人机场。

我的意思是，你根本不用费劲就能碰到不好的图片。随便浏览一下就能轻松找到它们。

其次，这些图片是如何进入预览的？创建这些预览的页面预览本身并没有错，问题在于PageImages。它对图片的评分偏向于列表和标记，尤其是那些可以从 Wikidata ID 链接中获取图片的列表。源文件中添加的图片，也就是读者总能看到的那些被选为代表性的图片，在评分列表中排名很低。评分更低的似乎只有页面横幅，它们完全被列入黑名单。我无法准确指出扩展的某个部分是错误的，因为我缺乏阅读代码的能力，所以也许其他人可以指出。

第三，对此可以做些什么？最简单的选择当然是禁用页面预览，但我将其排除，因为总的来说，它不是一个糟糕的功能，只是在这里使用时优化不佳。手动浏览文章以确保它们显示有用的图片也被排除，原因很简单，我们编辑者有更多重要的事情要做。我认为更可行的选择是只从导言部分获取图片（此处描述）或联系 PageImages 的开发人员，探讨优化该扩展以供此处使用的可能性。我还探讨了在文章的导言部分添加一个空的{{marker}}以提升其优先级，但未成功。因此，创建某种模板来强制使用某个图片并不是一个非常可行的方法。

我在这里寻找的是关于哪些图片是可取的共识：只有文章中定义和可见的图片吗？列表中的图片也包括在内吗？如果是，是哪种类型的列表？等等。之后我们可以讨论我们的行动。我们是通过更改 PageImages 的设置来改变它的工作方式，还是要求更改它的代码和内部工作原理，或者我们只是在这里禁用这个扩展？总而言之，关于这个话题的讨论是很有必要的。我将尽力回答您可能遇到的任何问题。提前感谢您。
-- Wauteurz (talk) 20:07, 2019年1月10日 (UTC)

为什么不选择文章 Wikidata 中列出的第一张图片呢？要么修改 PageImages 代码，要么我也考虑在页面顶部放置一个小的折叠图标{{Wikidata Infobox}}。也许这会强制显示更好的图片。--Traveler100 (talk) 20:46, 2019年1月10日 (UTC)

如果我手动选择图片，我首先会寻找用于创建横幅图片的裁剪图片。我的第二个选择是横幅图片，或者，如果需要更高更窄的图片，可能是横幅图片的左半部分或三分之一。一张精心挑选的横幅图片能反映目的地的特色。它也是读者进入文章页面时会看到的图片，因此如果读者不确定是否已经查看过该页面，它会很有用。横幅图片至少有 1800 像素宽，因此我们可以确定它们有足够的清晰度，并且除少数例外，它们的质量也足够好。在此之后，我更喜欢使用文章中存在的图片，理想情况下避免使用“抵达”和“环游”部分中的图片，其中包括地图和机场照片。我会避免使用文章中未显示的图片。 AlasdairW (talk) 21:34, 2019年1月10日 (UTC)

感谢Wauteurz花时间为我们进行研究并写下这些。回答您在最后一段提出的问题，就我而言，我认为只应使用文章中可见的图像，原因至少是维基导游用户选择的图像会显示在预览中，而不是看起来几乎是随机生成的图像。我还认为我们应该“要求更改其代码和内部工作原理”；如果 PageImages 的开发人员无法或不愿帮助我们，禁用这个本应有用的扩展应该是最后的手段。--ThunderingTyphoons! (talk) 21:46, 2019年1月10日 (UTC)

@Traveler100: 是的，那将是一个选项，但我没有发现任何迹象表明 PageImages 原生支持这一点。我想，使用我们现有的功能会更容易，如果现有选项不足，我们可以联系 PageImage 的开发人员。我之前没有使用扩展的经验，所以我不确定每个项目是否都能更改整个扩展以适应其需求。如果有人能在这方面给我提供信息，我将不胜感激。

从理论上讲，获取文章关联 Wikidata ID 的图片可能可行，因为 Wikidata 上城市和城镇的图片通常是从维基百科获取的，而维基百科在大多数情况下都会有不错的图片。问题是信息框是否会被 PageImage 抓取。要找出预览结果是否符合预期，最简单的方法是将模板放入一些有“糟糕”预览图片的文章中，看看是否有任何变化。我支持你尝试一下。
-- Wauteurz (talk) 22:00, 2019年1月10日 (UTC)

@AlasdairW: 重用横幅图片不是一个好办法。因为横幅图片的比例是7:1，如果将其裁剪成4:3或预览使用的其他比例，会丢失横幅的很多部分。此外，有些横幅图片的焦点偏左、偏右或居中。我们需要手动为大约15,800个自定义横幅设置横幅中心（这是一个功能，尽管很少使用）。在这种情况下，使用横幅的原始素材将是我的首选。尽管如此，也可能可以缩短预览高度，并强制使用7:1的页面横幅。我不确定地图是否是一个好的替代方案。例如，看看Achterhoek。它没有列表，导言部分也没有图片，因此默认为区域地图，看起来不吸引人。地图除了基础设施和城镇之外，没有显示太多东西。至于机场，如果你问我，它们对文章来说并不公平。以阿姆斯特丹为例，你在预览中看到的是史基浦机场，而不是被联合国教科文组织列为遗产的运河和市中心，后者会好得多。

我完全同意我们应该使用维基导游编辑者添加的图片，最好是读者阅读文章时能看到的图片（因此不包括列表和地图框架中的隐藏图片）。我认为这是我们都能达成共识的事情。

简而言之，我的偏好是：首先是内联图片（缩略图），其次是编辑者定义或编辑者修改的列表图片（即填写了image参数的图片），其次是横幅原始素材，最后是完全没有预览图片。实现类似效果的最简单方法是调整 PageImages 的评分系统，将列表图片以及{{regionlist}}和类似模板中的图片或地图的评分全部撤销（需要明确的是，我不知道单个项目是否可以更改此评分系统），或者将$wgPageImagesLeadSectionOnly设置为 true，这意味着只使用导言部分中的缩略图（我知道我们的管理员之一可以更改此设置）。
-- Wauteurz (talk) 22:00, 2019年1月10日 (UTC)

抱歉，如果我没有完全清楚。我想使用文章中显示的图片，除了“交通”和“环游”中的图片。这通常会排除“交通”中出现的机场和车站图片，并排除通常在“环游”中的地图。这意味着如果没有“理解”部分中的图片，则使用“查看”或“做”部分中的图片。我在这里考虑的是城市文章，其他文章可能需要排除其他部分。 AlasdairW (talk) 22:53, 2019年1月10日 (UTC)

这听起来很合理。我认为图片应该在文章中可见，以免引起混淆。如果可以获取页面横幅的源图片，那么在大多数情况下这可能是一个不错的选择，但这可能需要一些编码，以及作为页面横幅模板参数的链接。如果没有这样的明确引用，可能会出现一些奇怪的结果（裁剪掉的部分可能是任何东西）。理想情况下，您应该能够手动指定预览图片。使用第一张图片（通常在“理解”部分）应该很简单，但我还没有阅读代码。避免某些部分需要一些解析，这可能还没有编码。--LPfi (talk) 23:03, 2019年1月10日 (UTC)

我认为，总的来说，正如LPfi所说，我们应该选择文章的第一张图片，这应该很容易编码。所以我支持更改，如果可能的话（看起来是可能的）。

附注：抱歉再次更改了我的签名。我发现橄榄色过于刺眼，所以我改回了蓝色。--评论来自 Selfie City (talk | contributions) 02:39, 2019年1月11日 (UTC)

@AlasdairW: 你说的很清楚，我只是读漏了。从“看”、“做”等段落中取图片的问题是，链接到 Wikidata 的列表并不总是具有 Wikidata 中链接的有用图片。之前的讨论甚至就是因为这样的列表而产生的。

@LPfi, SelfieCity:“理解”部分并不总是有图片，它之前的导言部分也没有。虽然这种获取图片的方法可以解决内华达山脉的问题，但它不会改善太浩湖，因为后者在这些部分中没有图片。但我比任何人都支持这种方法，因为我们可以相对轻松地使用机器人（或者可能是 Petscan）来查找导言或“理解”部分中没有图片的文章，并组织一个 CotM（如果此类文章数量庞大，则将其作为 2019 年的目标），以将图片放入这些部分。

如果我们能够配置 PageImages 的评分系统，那么也许值得将{{listing}}、{{marker}}、{{regionlist}}等模板中使用的图片列入黑名单，并根据图片在文章中的顺序进行评分，如果可能的话，对之前在维基共享资源上展示的图片或带有质量标签的图片给予奖励。查看一些示例后，我得出结论，也许我们应该尽可能地将所有模板列入黑名单，因为在FTT、DotM或OtBP提名文章中获得选中标记来“代表”文章远非理想。总之，这种评分方法理想情况下会根据图片在文章中的出现顺序对荷兰铁路旅行中的图片进行评分，从而获取阿姆斯特丹中央车站的图片，该图片作为维基共享资源中的高质量图片将获得奖励。也许一个用于修改分数以允许编辑者更好地控制显示哪些图片的模板可能有用，但我们暂时不要想得那么远。

如果我没弄错的话，我看到了一种普遍的趋势，希望从导言部分和/或“理解”部分获取图片。正如我之前所说，这应该可以通过将参数$wgPageImagesLeadSectionOnly设置为 true 来由我们的管理员和/或官僚进行配置。我暂时不打算为此发起投票，因为还有很多其他选项，我想听听更多维基导游用户的意见，这样我们最终可以对几组方法进行投票。届时，也许值得请 MediaWiki 负责 PageImages 扩展的一些人来指导我们做出一个好的选择。
-- Wauteurz (talk) 10:55, 2019年1月11日 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘我同意你关于可能的 COTM 等的看法。--评论来自 Selfie City (talk | contributions) 23:36, 2019年1月11日 (UTC)

如果我们采取在“理解”部分添加图片，或者在没有“交通”部分的情况下在其之前添加图片的方式，我不确定如何轻松追踪此类项目的进展。初步看来，我无法找到限制高级搜索或 Petscan 到文章某个部分的方法。有没有人有任何想法或建议？我可以看到一种可能性，即在页面上运行机器人并对其进行标记，但这样就无法保证会移除。--Traveler100 (talk) 07:45, 2019年1月13日 (UTC)

我也不确定。正如我在下面对你的问题的回复中提到的，API 沙盒可能是找出答案的一种方法，但这需要一个机器人来查找和标记这些页面，而不是 PetScan。只有当一个页面被模板标记（例如，为了进一步参考，我们称之为{{NoImageInLead}}）后，我们才能更容易地使用 PetScan 找到这些文章。我认为没有机器人的参与，我们无法完成相同的过程。
-- Wauteurz (talk) 12:06, 2019年1月13日 (UTC)

问题 - 页面上显示的图像大小（非实际大小）是否对排名有影响？可以在页面最顶部放置一个不显眼的小图像，并在所有文章中已有的{{geo}}标签上添加扩展。这将是文章中的第一张图像，默认可以是维基数据标准图像，或者您可以在 geo 模板中添加图像文件名来定义另一个图像。--Traveler100 (talk) 08:15, 2019年1月13日 (UTC)

不明白 PageImages 的计算方法。例如，文章奥赫里德中的第一张图片与机场列表中的图片实际大小相同，但仍未被选为预览图片。--Traveler100 (talk) 09:38, 2019年1月13日 (UTC)

@Traveler100: 简而言之，是的，图片的大小很重要。我从未完全理解评分是如何运作的，但我根据收集到的信息，对评分系统有了一个大致的了解，尽管我不知道评分会应用哪些数字

• 任何小于 119px 或$wgPageImagesScores['width']中定义的尺寸都会受到强烈反对，而<gallery中任何小于 100px 的图片都会被忽略。由于我们不使用画廊，维基导游上小尺寸图片（例如，一张 50px 宽的图片）仍然会被考虑。
• 模板搜索的宽度是 400-600 像素，偏好较低的范围——换句话说，400 像素是理想的，任何宽度增加 50% 以内仍然可以接受。我不确定 4.000×6.000 像素图片的一个 400×600 像素缩略图在这种情况下会如何被偏好，但我认为缩略图是直接从文章中获取的，这意味着获取的是缩略图，而不是原始的更大图片。
• 文章中的前四张图片会被考虑，除非这个数字通过$wgPageImagesScores['position']更改。我怀疑，通过某种方式，无论是文章的渲染顺序、地图框架还是列表，列表中那些在维基导游上造成最大问题的图片，因为它们先被渲染，所以被认为具有更高的位置。这可以解释为什么奥赫里德有它的预览图片，但这只是我的猜测。我无法确定这就是原因。
• 最后，图片的比例也会被考虑。任何宽度超过 2:1 的图片，例如我们的页面横幅，都会被自动丢弃或受到强烈反对。我不确定这是否也适用于纵向图片，例如 1,500×500 像素的图片，因为文档没有明确说明，但我们假设它们是。在这种情况下，任何宽度大于 2:1 或高度大于 1:2 的图片都会被忽略。同样，这个比例（默认为 0.5）可以用$wgPageImagesScores['ratio']自定义。这并不意味着任何更宽的图片，如页面横幅，会获得优先权，而只是调整了被考虑的范围。

我已经尽力使 PageImages 文档页面上的解释更易读，但如果仍不清楚，您可以在此处找到原始文档。我不确定在{{geo}}中添加图片是否有帮助，因为我不知道哪些模板被列入黑名单，哪些没有。您可以随时尝试一下。它可能不会有帮助，因为{{geo}}是代码中最后一个模板之一，并且对读者来说仅是视觉上的第一个模板。机器可能会因为文章的渲染方式而以不同的方式读取它。我认为唯一的办法就是尝试。也许有更多 Wikimedia API 经验的人可以尝试一下，但我们似乎可以通过使用 API 沙盒来找出哪些图片会被考虑。如果有人愿意并能够尝试，请查看PageImages#API，看看是否可以为维基导游上的文章进行此类请求。
-- Wauteurz (talk) 12:06, 2019年1月13日 (UTC)

@Wauteurz: 谢谢，这些评论帮助我弄清楚了这里发生的事情。正如你所说，列表会首先被解析，但只有那些带有坐标和明显图片的列表。因此，前四个带有坐标和图片参数的列表是候选对象。--Traveler100 (talk) 12:27, 2019年1月13日 (UTC)

你说得对，geo 模板不会起作用，即使在模板中添加一个显示在顶部的列表，仍然被视为列表的最后一张图片。因此，我看到在不改变维基媒体代码的情况下控制这一点的唯一方法是在每个页面顶部添加一个带有坐标的列表，比如显示市中心位置。不确定这是否需要。我认为我们需要要求图像排名代码的开发人员忽略列表图像。--Traveler100 (talk) 12:50, 2019年1月13日 (UTC)

@Traveler100: 没错。如果少于 4 个带有坐标和图像的列表，那么下一个候选者就是文章中的图像，或多或少按照它们的出现顺序。像{{featurenomination}}这样的模板似乎要么被非常负面地评分，要么完全被列入黑名单/忽略。我从未发现特色文章在其预览中显示勾号。另一方面，它是否需要被列入黑名单呢？特色提名文章有足够的图像来超越那个小勾号。我知道这不是很相关，但我觉得我需要纠正我之前关于这是一种可能性的说法。
-- Wauteurz (talk) 12:54, 2019年1月13日 (UTC)

T213652 请求更改排名，将可见图片置于列表图片之前。--Traveler100 (talk) 13:19, 2019年1月13日 (UTC)

Phabricator 更新后

这是来自Phabricator 任务单的更新：让贡献者手动设置预览图像的方法已经在开发中。根据Jdlrobson在 Phabricator 上的回复，我推断我们设想的（能够将模板列入黑名单）想法是不可行的。目前可行的替代解决方案如下：

1. 将上述参数$wgPageImagesLeadSectionOnly设置为true，这意味着所有预览图片都将仅从导言部分获取。许多文章都有图片，但不在导言部分，这需要机器人和可能的月度协作来优化。然后我们将手动处理机器人提供的列表，并在需要时添加图片，或者设置相同的机器人将文章中的第一张图片移动到导言部分。
2. 调整列表以获取更优的图像。我们知道图像是根据它们在列表中的出现顺序获取的。如果列表 #1 和列表 #3 都有图像，列表 #1 总是优先于列表 #3。如果列表 #3 的图像优于 #1，那么我们可以交换这两个列表以达到预期效果。主要缺点是这将是一个比上述选项更耗时的过程。我可以看到选项 1 可以通过一个月的协作来解决，而这个选项可能需要一年的协作。
3. 什么都不做。一个对我们来说很好的解决方案已经在开发中。不过我没有找到它的预计完成时间。明显的缺点是，我们将不得不处理目前的情况，这可能需要几周到几年的时间。

最好让 Phabricator 上的事情展开一段时间，之后我们就可以就如何解决目前的问题达成共识。欢迎讨论上述选项或提出任何新选项，或在Phabricator上加入讨论。
-- Wauteurz (talk) 20:26, 2019年1月14日 (UTC)

User:Wauteurz 在解释其工作原理方面做得非常出色。当我提议启用页面预览功能时，我确实指出我们需要重新考虑描述和图像来支持它，但我认为这对于项目有益，而且是一个我们可以解决的编辑问题。

我强烈建议不要将 $wgPageImagesLeadSectionOnly 设置为 true。这会导致我猜测至少 70% 的文章没有图片。这会对页面预览、移动网络搜索以及外部客户端产生负面影响。我们还有一些数据表明，当图片与链接同时呈现时，我们会获得更多的互动。我认为这比现状差得多。

选择图片的算法也很笨。 phab:T91683 已被提议作为处理这些情况的长期解决方案，目前只是缺乏动力来解决这个问题，这会帮助每个维基，但在此期间，我认为最好的做法是确保文章中的第一张图片能代表文章，并且是一张合适的页面图片！这似乎对页面预览用户和进入文章获取信息的用户都很有用！例如，暹粒除了页面横幅外，不包含任何吴哥窟（其最具标志性的景点）的图片，这很奇怪。从我的角度来看，过度使用横幅是有问题的——它不为移动用户提供标题（在移动设备上无法悬停在横幅上！）并且不会在不支持横幅的客户端上渲染。我们不能设置一个页面图片探险吗？我觉得那会很有趣。

令人沮丧的是，在像华盛顿特区这样的案例中，情况似乎就是如此——一张亚伯拉罕·林肯的图片看起来非常具有标志性和相关性，但由于某种原因，它并没有被选为页面图片。我很想再深入研究一下，看看这是为什么。这在我看来就像一个 bug。希望这能消除我们看到的一些糟糕的页面图片。

Jdlrobson (talk) 20:31, 2019年1月14日 (UTC)

@Jdlrobson: 我很清楚我不是唯一有意见的人，但在我看来，$wgPageImagesLeadSectionOnly 似乎是最佳选择。然而，我非常赞成之前提到的图像远征或月度/季度协作。这次远征的目标是在每个导言部分都放置一张图片，在此之后，我们理想情况下会有大部分文章的导言部分都包含图片。只有达到这个目标后，我才会赞成将 $wgPageImagesLeadSectionOnly 设置为 true。我承认我没有明确说明这是我设想的顺序。鉴于phab:T91683已经进行了几年，并且没有一个目标被勾选，我非常乐意在今年年底或 2020 年的某个时候实现这个目标。

我可以报告，华盛顿特区的图片来源于文章中第一个带有坐标的列表：阿富汗大使馆。并不是图片来自一个看似随机的地方。就像你说的，算法并不聪明。我之前已经推测，列表被优先考虑是因为它们或地图框在页面内容之前加载。我无法证实这些，但这可能值得研究。同样地，如果算法如此笨拙，为什么不重写它以区分清晰可见的图片（缩略图等）和“不可见”的图片（列表等）呢？我可能大大简化了整个问题，但请原谅我缺乏技术知识。我在学校学到的编码和技术见解早已在我脑海中褪色。

总之，我完全赞成图像远征，但我也想听听其他人的见解。
-- Wauteurz (talk) 21:21, 2019年1月14日 (UTC)

在我看来，任何需要编辑每个页面或手动设置预览图像的解决方案都存在问题。虽然我们可以为我们最受欢迎的文章这样做，但我们绝大多数页面本身文字稀少，许多页面缺乏自定义页面横幅，更不用说在导言中放置图像了。即使我们找到一张图像，在许多情况下它也会主宰整篇文章。

作为第四个解决方案，是否有可能调整图像分数的权重，以强烈偏向维基数据图像？我认为这是最好的解决方案：我们大多数文章将立即拥有一张有人认为能代表目的地的照片作为预览图像，而那些维基数据图像质量较差的文章将很容易更改，这样做也将使其他项目受益。此外，没有维基数据图像但有横幅的目的地可以将横幅源图像添加到维基数据，而没有图像或横幅的目的地仍然可以依靠其他类型的图像。

如果这不可能，那么对于 Phabricator 的开发人员来说，这似乎是一个更简单的改变。ARR8 (talk | contribs) 01:37, 2019年1月15日 (UTC)

建议更多人订阅 Phabricator 上记录的两个问题，看不出这在技术上为何不可能，可能只是不被认为太重要，而且还有许多其他问题需要解决。另外，我认为可以在每个城市页面的开头添加一个指向维基数据图片的标记（见下文）。但要在文章开头添加位置图标需要讨论和一些共识，因为我看到了它的优缺点。--Traveler100 (talk) 10:03, 2019年1月15日 (UTC)

我不喜欢任何涉及对每个页面进行批量编辑的解决方案。这种事情应该透明地完成。如果我们现在就想让它工作，那么我们确实需要做一些笨拙的事情，但我宁愿开发人员在开始改变我们所有页面的外观之前，先修复根本问题。

不过，我很感谢你找到了最不引人注目的方式。但是，我认为在目的地名称后面直接放置编辑按钮可能会让新编辑者感到困惑，他们可能会点击它而不是页面编辑按钮。ARR8 (talk | contribs) 13:50, 2019年1月15日 (UTC)

@ARR8: 我并不是说我们33,748篇文章中的每一篇都需要手动编辑。维基数据为这些文章中的大部分提供了图片，不通过机器人的方式使用它们将是浪费机会。然而，这仍然需要一些手动输入，协作或远征将有助于为这带来一些结构。正如你所说，维基数据也有一些不太理想的图片，希望我们能在此过程中修复它们。现在并不是每篇文章在预览中都有图片，如果有什么不同，这个数字会有所增加。我们都没有确切的数字，但这可能值得研究，因为带有图片的文章预览的变化可能是选择最终方法的一个重要因素。总而言之，与维基数据集成是我记得往年所希望的，因此将列表链接到维基数据。这可能是一个追逐这个愿望并将其付诸实践的机会。就我个人而言，我一点也不反对将横幅源图片设置为维基数据中该 ID 的图片，更不用说使用链接到我们文章的维基数据 ID 中的图片了。

我们都更希望 PageImages 能够正常工作，但我并不指望它能够如愿以偿，让编辑者能够通过T91683获得承诺的控制权能够很快实现。到今年三月，这项任务将已经进行了四年，我不确定它能否在今年年底完成。另一个选择是T95026，它旨在允许 PageImages 直接从与正在预览的文章链接的 Wikidata ID 中获取图片。由于Jdlrobson参与了这两个项目，也许他们可以告诉我们这两个项目的进展情况。
-- Wauteurz (讨论) 2019年1月15日 (UTC) 18:32

不需要任何手动编辑，可以将模板添加到页面横幅模板中，以提取 Wikidata 并在页面右上角创建列表。--Traveler100 (讨论) 2019年1月16日 (UTC) 11:58

我今天看到的一个解决方案

也许这有点小题大做，但这是一个解决方案：Washington, D.C./sandbox。而且不需要一年时间来编辑页面，可能可以用机器人编辑完成。有什么意见吗？--Traveler100 (讨论) 2019年1月14日 (UTC) 21:41

不是说我们应该这样做，但基本上唯一可见的变化是在城市文章开头有一个坐标数字（带市中心位置），例如 Ohrid/sandbox。这是一个可以接受的变化，以获得更好的预览图像吗？--Traveler100 (讨论) 2019年1月15日 (UTC) 09:58

我不喜欢这样做。这个数字在文章开头有点令人困惑，但在动态地图上显示时则更令人困惑。—Granger (讨论 · 贡献) 2019年1月15日 (UTC) 14:13

可以将数字移动到右上角（参见Washington, D.C./sandbox），并消除编辑页面的需要（更新页面横幅），但无法将其从地图上删除。（注意，当前页面横幅沙盒是固定图像和坐标，但可以更改为页面的 Wikidata 值）--Traveler100 (讨论) 2019年1月15日 (UTC) 18:17

我不赞成这个。一方面，它确实修复了预览图像，但另一方面，它也为每个预览摘要都添加了1，我认为这不值得权衡。我更赞成的是这个想法，但使用地图形状而不是地图标记。目前没有模板可以实现这个功能，我也不确定是否可以做到。这样，预览中就不会显示列表编号（1），而只会显示带有标记的摘要——没有标签，没有链接——只有纯文本，这才是它应有的样子。然后这个模板可以被分配一个图像和 Wikidata 链接。这两个都不会显示在地图上。
-- Wauteurz (讨论) 2019年1月15日 (UTC) 18:20

可以通过添加 noexcerpt 类来从预览中删除数字！参见 MW:Extension:Popups#FAQ
2607:FB90:9D55:EEEC:AD28:E0EF:5ED3:DBD0 2019年1月16日 (UTC) 02:20

没错，这确实是一种可能性。然而，如果我们使用“noexcerpt”，我们将不得不创建一个单独的 {{listing}} 模板实例。到那时，更值得研究的是创建我上面描述的模板，该模板在管理机构周围添加一个地图框架，而不是在地图上添加一个没有任何信息的标记。
-- Wauteurz (讨论) 2019年1月16日 (UTC) 20:02

今天可用的更新解决方案

已在 Bitola 创建了一个测试。这不需要对页面进行任何手动更新，因为代码会添加到页面横幅中。将使用 Wikidata 中的图像和坐标。注意页面右上角的额外图标和文本。仍然会在地图上创建图标，但颜色是浅灰色。不会在预览中创建任何标记。我用户空间中的当前测试模板需要一些工作才能真正可用，因为它目前无法很好地处理 Wikidata 不存在的情况。如果大家认为这是一个可行的解决方案，我可以进一步研究。提出这个建议的原因是我认为 MediaWiki 代码很快就会改变。--Traveler100 (讨论) 2019年1月21日 (UTC) 09:03

FileExporter beta 功能

即将推出：beta 功能 FileExporter

一项新的测试功能“FileExporter”即将部署到所有维基上。它允许将文件从本地维基导出到维基共享资源，包括其文件历史和页面历史。哪些文件可以导出由每个维基社区定义：如果您想使用此功能，请检查您维基的配置文件。

FileExporter 已经在 mediawiki.org、meta.wikimedia、deWP、faWP、arWP、koWP 和 wikisource.org 上作为 Beta 功能推出。在添加了一些功能后，它现在正在成为所有维基上的 Beta 功能。部署计划于 1 月 16 日进行。更多信息可在项目页面上找到。

一如既往，我们非常感谢您的反馈。如果您想测试 FileExporter，请在您的用户偏好设置中激活它。反馈的最佳地点是中央讨论页。感谢维基媒体德国的技术愿望项目。

Johanna Strodt (WMDE) 2019年1月14日 (UTC) 09:41

页面预览和导航弹出窗口

在 Phabricator 中追踪 ^(?)
任务 T214878

@Jdlrobson:，此维基上的页面预览似乎不遵守 Navpops（对我而言）。当 Navpops 小工具启用时，页面预览应该被抑制。然而，当我将鼠标悬停在文章链接上时（在此页面上；我没有检查其他地方），我看到了两者。这是你的管辖范围吗？WhatamIdoing (讨论) 2019年1月27日 (UTC) 16:56

我能证实这个 bug。我不得不手动禁用页面预览。 ARR8 (讨论 | 贡献) 2019年1月27日 (UTC) 16:57

这现在已经修复了，感谢 User:X-Savitar :-) 2019年2月14日 (UTC) 19:58

移动主页

根据 @Seddon (WMF): 完成的工作，我已将 Wikivoyage 的移动端入口页面进行了更改。它以前非常枯燥。还有进一步改进的潜力，但这只是一个开始，给页面带来了一些色彩。--Traveler100 (讨论) 2019年2月10日 (UTC) 14:23

干得好！非常感谢您的付出。--ThunderingTyphoons! (讨论) 2019年2月10日 (UTC) 14:38

我很高兴这已经实施了。很大的改进。—Granger (讨论 · 贡献) 2019年2月11日 (UTC) 11:39

页面有所改进，但现在开始遇到困难，尤其是在使用表格格式化页面时。--Traveler100 (讨论) 2019年2月12日 (UTC) 18:29

已经解决了没有表格宽度的格式问题，但仍然不明白为什么在主页上 {{bottomboxesn}} 在移动视图中不显示，但在沙盒中可以工作？--Traveler100 (讨论) 2019年2月12日 (UTC) 21:53

哇！我们的中文维基导游也更新了移动版的主页。:D--Yuriy kosygin (讨论) 2019年2月15日 (UTC) 17:57

感谢 @ARR8: 制作了更好的移动版主页。--Traveler100 (讨论) 2019年2月23日 (UTC) 06:57

旅行者酒吧

此页面在移动设备上未显示“欢迎”区块。我将引言和清理部分分开，以便第一部分在移动设备上显示，而第二部分不显示。略有改善但并不完美。有改进建议吗？--Traveler100 (讨论) 2019年2月12日 (UTC) 17:41

绿底的问号真的有必要吗？--Traveler100 (讨论) 2019年2月12日 (UTC) 17:49

我不介意分开它们，但我认为现在的新盒子应该默认与另一个盒子对齐，更像 Pub/sandbox。但我不知道在移动设备上会是什么样子。--评论者 Selfie City (讨论 | 贡献) 2019年2月13日 (UTC) 01:35

Wikivoyage:社区门户

社区门户在典型尺寸的智能手机上看起来不太好。让各个区块在移动模式下垂直排列，在桌面模式下并排排列，这可能需要编写和编辑一些超出主题的代码（除非有人能看到一个简单的方法）。大家怎么看，是保留现有桌面视图设计和新的移动视图设计，还是提出一个适合两者的全新风格？欢迎任何建议。--Traveler100 (讨论) 2019年2月12日 (UTC) 17:37

我想我已经想出了一个解决方案 Wikivoyage:社区门户/沙盒。还没有完全完成，但已经看到成功的希望。--Traveler100 (讨论) 2019年2月12日 (UTC) 21:42

沙盒对我来说看起来不对劲。不过，也许那是因为你还在修改它。如果你只有一列盒子，而不是两列或三列，会怎么样？--评论者 Selfie City (讨论 | 贡献) 2019年2月13日 (UTC) 01:32

原页面有一些错误，直到我做修改才显示出来。Wikivoyage:社区门户/沙盒 是我希望在智能手机和使用 Firefox 和 Explorer 的桌面设备上查看的效果，但在 Chrome 上没有达到我想要的效果。--Traveler100 (讨论) 2019年2月13日 (UTC) 20:03

帮助资源

我找到了 mw:Mobile Gateway/Mobile homepage formatting。还有更多有用的资源吗？也许能提供更多关于类和样式代码的细节以及如何使用它们？看起来我们用于主页和项目页面的代码不建议用于移动端浏览。正在寻找有助于编写在所有设备上都能良好运行的页面的资源。--Traveler100 (讨论) 2019年2月12日 (UTC) 18:29

几年前法国维基百科重新设计了他们的主页，如果你能找出是谁做的，你可能就能找到一些例子。User:Quiddity 也许能告诉我们是否有任何活跃的英文维基编辑者对使主页易于访问感兴趣。（我想念User:Edokter。）WhatamIdoing (讨论) 2019年2月13日 (UTC) 21:43

你好。+1 查看 w:fr: 主页代码 - 如果我没记错，他们很注重可访问性，并且在窄窗口中，桌面和移动前端看起来都不错。关于英文维基，我不太了解这方面的活跃人士，但我知道 w:WT:WPACCESS 和 w:WT:ACCESS 的工作人员通常都非常友好，乐于讨论这个话题！（是的，我希望我们能有一些更好的模板风格设计变体，可以在社区之间共享。（同样是模板等等！无限愿望清单...））希望这有帮助。Quiddity (讨论) 2019年2月14日 (UTC) 07:50

关于移动网页模板的更新

您好，

几个月前我们曾提到一项变更，关于某些模板在移动网页上的显示方式。我只是想提一下，这项变更现在已在英文维基导游生效。您可能已经知道，截至1月份，移动流量约占英文维基导游总流量的三分之一（且使用移动网站的独立设备数量接近桌面网站的两倍），因此使模板在移动设备上显示非常重要。

我们已经将此更新部署到所有其他维基，并且我们已经在维基百科上进行了A/B测试来衡量其影响（总结：用户与新处理的交互频率高于旧处理。他们与高严重性问题的交互频率高于低严重性问题。新设计不会导致更频繁的编辑）。

我们注意到英文维基导游的这些模板存在一些样式不一致问题，希望大家提供帮助。对于模板编辑者，我们提供了一些使模板适应移动设备的建议，以及我们迄今为止工作的更多文档。

如果您有关于为移动设备格式化模板的问题，请在项目讨论页上留言或在Phabricator中提交任务，我们可以提供帮助。CKoerner (WMF) (讨论) 2019年2月20日 (UTC) 18:30

好消息！这应该会对 WV:UX Expedition 产生巨大影响。--评论者 Selfie City (讨论 | 贡献) 2019年2月21日 (UTC) 03:11

这些对维基导游来说是相对较小的变化，但我很高兴我们收到了通知。 ARR8 (讨论 | 贡献) 2019年2月21日 (UTC) 04:14

哦，好的。不过，仍然是好消息。--评论者 Selfie City (讨论 | 贡献) 2019年2月21日 (UTC) 04:48

这意味着，如果您在文章顶部放置了一个关于问题的模板，那么读者（至少在开始时，效果可能不会持续）会点击模板中的链接，了解这个新出现的模板是关于什么的。没有人额外编辑文章，所以我认为这基本上是一个失败。（公平地说，这个失败可能在于维护模板作为鼓励编辑的一种方式的整个想法，而不是团队所做工作的问题。但无论哪种方式，我们都不应该抱太大期望。）WhatamIdoing (讨论) 2019年2月22日 (UTC) 06:19

和我们谈谈交流吧

维基媒体基金会正在计划一项关于交流的全球咨询。目标是将维基媒体人和有维基思维的人聚集在一起，以改进交流工具。

我们希望所有贡献者都能在维基上互相交流，无论他们的经验、技能或设备如何。

我们正在寻求尽可能多的维基媒体社区不同部分的意见。它将来自多个项目，多种语言，并具有多种视角。

我们目前正在计划咨询。我们需要您的帮助。

我们需要志愿者来帮助与他们的社区或用户组进行交流。

您可以通过在您的维基上主持讨论来提供帮助。以下是操作步骤：

1. 首先，在此处注册您的群组。
2. 接下来，创建一个页面（或乡村茶馆的一个部分，或一个电子邮件线程——任何适合您群组的方式）来收集群组中其他人的信息。这并非投票或决策讨论：我们只是在收集反馈。
3. 然后询问人们对交流流程的看法。我们希望听到关于人们如何在维基内外互相交流的故事和其他信息。请考虑提出以下五个问题：
   1. 当您想与社区讨论一个话题时，哪些工具对您有效，哪些问题阻碍了您？
   2. 关于讨论页面，哪些对新手有效，哪些阻碍了他们？
   3. 在您的社区中，其他人对讨论页面有什么困难？
   4. 您希望在讨论页面上做些什么，但由于技术限制而无法实现？
   5. “维基讨论”的重要方面是什么？
4. 最后，请前往 Mediawiki.org 上的 2019 年讨论页咨询，并报告您从您的小组中学到的东西。如果讨论是公开的，请附上链接。

您还可以帮助建立人们互相交流的多种不同方式的列表。

并非所有活跃于维基或围绕维基的群体都以相同的方式讨论问题：它可能发生在维基上、社交网络上、通过外部工具……请告诉我们您的群体如何交流。

您可以在 mediawiki.org 上阅读更多关于整个过程的信息。如果您有疑问或想法，可以用您偏好的语言留下关于咨询过程的反馈。

谢谢！我们期待与您交谈。

Trizek (WMF) 2019年2月21日 (UTC) 15:01

陈词滥调的观点以及其背后所蕴含的

从 Travellers' pub 扫入。

人尽皆知的 哈尔施塔特 景观。

Johnny Harris 制作了一个关于旅游陈词滥调的精彩视频；那些可能被过度开发、价格过高或受到损害的知名地点、景观和活动，其中以奥地利的哈尔施塔特作为案例研究。他谈到了一些关于如何找到超越这些陈词滥调的体验。维基导游的作者可以从这个视频中学到什么？如果我们要描述一个过度拥挤、价格过高或受到损害的旅游景点，我们是否应该提供建议，说明哪些时间段可以避开最糟糕的拥挤？或者附近是否有替代景点？/Yvwv (讨论) 2019年3月4日 (UTC) 14:47

另外，也许当我们展示著名旅游目的地的图片时，我们可以选择一些不那么广为人知的。比如伦敦，如果我们尝试展示一些除了最著名景点之外的地点。--评论者 Selfie City (讨论 | 贡献) 2019年3月4日 (UTC) 15:09

同意上述所有建议。这些都是成功旅行指南的基本特征。--ThunderingTyphoons! (讨论) 2019年3月4日 (UTC) 19:05

我相信在 WV:Banner expedition 的某个地方谈到了选择能够展现更独特景色的页面横幅。--评论者 Selfie City (讨论 | 贡献) 2019年3月4日 (UTC) 23:22

奥地利和哈尔施塔特的横幅都是哈尔施塔特的照片，与上面提到的照片相似，但角度相反。/Yvwv (讨论) 2019年3月5日 (UTC) 03:18

不过，在我看来，如果一个地方很美，拍照也无妨。如果这两个页面的横幅被认为过于相似，那么奥地利的横幅或许可以更改。--评论者 Selfie City (讨论 | 贡献) 2019年3月9日 (UTC) 01:02

Alexa 排名

从 Travellers' pub 扫入。

我喜欢关注 Alexa 排名。从 2018 年年中到 2018 年 10 月，维基导游的 Alexa 排名攀升得相当快，而且稳定。然而，排名在大约这个时间突然停止攀升，并趋于平稳。在接下来的几个月里，它开始下降，虽然现在看起来相当平稳，但还没有真正开始大幅攀升。我想知道为什么会出现这种情况。

早在 2018 年初，曾有过一项鼓励编辑者扩展文章的项目。最近又有一个关于俄语维基导游的项目。这些都被认为是 Alexa 排名过去攀升的原因。在不久的将来，或者今年晚些时候，是否有类似的活动？

只是好奇。归根结底，我们仍然拥有优秀的读者数量，而且我们正在努力使旅行指南越来越好。但知道这些技术是否可以在未来用于吸引更多读者会很有趣。这只是一些想法。--评论者 Selfie City (讨论 | 贡献) 2019年2月8日 (UTC) 05:43

凭经验来说，我注意到最近这里似乎安静了许多，尤其是在白天（UTC）。当然，这里指的是编辑，而不是读者，但我猜一定比例的读者也会进行编辑。（关于这个主题，有没有人知道是否有研究关于维基百科读者中至少进行过一次编辑的平均百分比是多少？以及其中有多少人成为了定期贡献者？）我认为维基媒体应该有一个小的外部广告预算，因为像 Editathon 这样的举措虽然有效，但它们只针对内部，即其他 WMF 维基。如果不行，也许我们（指 Wikivoyage）应该尝试在社交媒体上更活跃。我们有 Facebook、YouTube（Twitter？），但有人关注我们吗？--ThunderingTyphoons! (讨论) 2019年2月8日 (UTC) 14:10

通常给出的数字是10%。我们还有另一个问题，那就是我们的搜索排名通常很低，尤其是与维基百科相比。大多数人不会来维基导游寻找旅行信息，而是查找后才来到这里。我打算为此提出一个 COTM——有几个引人注目的页面，当搜索时，会返回 Lonely Planet、TripAdvisor、Wikitravel 等的搜索结果，但没有我们。我发现最糟糕的例子可能是克罗地亚。ARR8 (讨论 | 贡献) 2019年2月8日 (UTC) 14:47

据我所知，在搜索引擎优化方面，这可能是因为克罗地亚条目包含许多与 Wikitravel 相似（甚至重复）的内容，或者条目的内容没有使用很多会被搜索引擎抓取的关键词。

我认为最近确实比较安静。我今天（UTC）5:00 查看了最近的更改，发现我可以轻松滚动浏览更改。一个例子是，除了一个帐户被创建外，3:00-4:00 之间没有进行任何编辑。想象一下，如果当时有一个破坏者在网站上，他会造成多大的破坏。

我同意社交媒体的看法。我们有一个社交媒体提名页面，但很少使用。如果可能的话，我们应该更多地使用它。我们可以提及最近得到显著改进的文章等等。据我所知，DOTM 会在社交媒体上发布。--评论者 Selfie City (讨论 | 贡献) 2019年2月8日 (UTC) 14:55

往年，维基导游和“另一个网站”在十月至二月期间的活跃度都较低。这并不奇怪，因为讲英语的人通常在北半球夏季进行大型度假旅行。我们可以预计未来几个月流量会增加。/Yvwv (讨论) 2019年2月8日 (UTC) 15:08

我目前是维基导游Facebook账户唯一一个活跃的管理员，而且我本人在维基导游上也相当活跃。目前，每个新的DotM、OtBP和FTT都会发布到Facebook。我确实觉得我们的账户应该比这更活跃，但正如我之前所说，我觉得这对一个人来说是一项太大的工作，特别是像我这样分身乏术的人。但过去每次我向维基导游社区呼吁，希望有人能帮助管理我们的Facebook页面时，接下挑战的人似乎总是在不久后就变得不活跃了。我仍然非常希望能得到帮助，但我希望如果我在这里收到希望成为我们Facebook页面管理员的回复，那会是来自计划长期坚持下去的人。-- AndreCarrotflower (talk) 2019年2月8日 15:50 (UTC)

我10月份开始上大学。问题解决了。 ;-) Hobbitschuster (talk) 2019年2月8日 22:11 (UTC)

如果你比较我们与12个月前的Alexa排名，会发现它高得多。它从大约21,500跃升到16,500。这是一个重要的衡量标准，因为正如Yvwv上面提到的，全年都有季节性变化。但当然，总有改进的空间。我有时会在网上旅游论坛上推广维基导游文章，只要我觉得它与问题或对话相关。我收到的所有零星反馈都是，阅读维基导游的人大多喜欢我们。很少有人不喜欢。只是很少有人知道我们的存在。我们的目标受众相当广泛（任何对旅游感兴趣，有互联网连接，且说英语的人，包括非母语者），但在如此庞大的人口中，有多少人听说过我们呢？所有主要的WV替代品，无论是范围相似（例如，其他网站、孤独星球、Frommer's、Rough Guides），还是目标略有不同但重叠的TripAdvisor、BBC Travel和Nat Geo Travel，都在社交媒体上拥有数百万的关注者。我们只有数千人。我们的目标应该是让我们的名字广为人知，让旅行者了解这个网站。搜索引擎优化是我们许多文章几乎无人问津的主要原因，但除了将自己与其他网站区分开来之外，还必须有其他方法来提高知名度。Gizza ^(漫游) 2019年2月9日 13:52 (UTC)

同意。品牌知名度非常重要。--评论者 自拍城市 (讨论 | 贡献) 2019年2月9日 17:23 (UTC)

点子

维基导游是否曾考虑过建立某种博客？维基旅行以前不是也有过吗？如果我们开始了，当然希望这是集体努力，如果是这样，我很乐意提供帮助。--评论者 自拍城市 (讨论 | 贡献) 2019年2月8日 23:48 (UTC)

或许可以尝试与一些现有的维基百科专题活动合作。例如，也许有位正在撰写著名艺术家的作者，也想在这里更新关于展出其作品的博物馆条目。如果在纽约市、伦敦或柏林，那里有很多潜在的活动。WhatamIdoing (talk) 2019年2月9日 04:54 (UTC)

Wikivoyage毕竟不太受欢迎，大家都只知道维基百科，不知道我们……为了让更多人对我们的Wikivoyage感兴趣，我觉得我们需要和其他旅行网站合作（例如[https://www.backpackers.com.tw/guide/ 背包客]）。--Yuriy kosygin (talk) 2019年4月2日 18:45 (UTC)

DOTM横幅

我现在拥有了制作DOTM、OTBP和FTT横幅的工具（GIMP）和知识。希望这能减轻AndreCarrotflower制作横幅的一些负担，这可能是一项相当繁重的工作。Ypsilon最近也提供了帮助。--评论者 自拍城市 (讨论 | 贡献) 2019年2月10日 00:23 (UTC)

Alexa排名上升

突然之间，在三月中旬，维基导游的Alexa排名飙升至几个月前的历史高位，目前介于15,000到16,000之间。这很有趣，也许有人能解释一下为什么会发生这种情况。--评论者 自拍城市 (讨论 | 贡献) 2019年3月19日 02:14 (UTC)

维基旅行排名

以防万一之前没有提到过。因为我们总是将自己与Wikitravel进行比较；WT在过去几个月/几年中逐渐下降：https://www.alexa.com/siteinfo/wikitravel.org 它现在几乎与WV持平了。所以，我认为我们做得很好。干杯Ceever (talk) 2019年3月19日 12:12 (UTC)

有些人会在旧货店买旧的旅游指南，所以我想人们仍然在阅读Wikitravel也就不足为奇了。同样有趣的是，在Wikivoyage的读者中，14%来自美国，而接下来的四个国家（德国、意大利、中国、伊朗）合计占35%，这意味着我们的大部分读者都不是以英语为母语的人。（你需要订阅Alexa才能了解剩下的51%读者。）Ground Zero (talk) 2019年3月19日 12:26 (UTC)

请记住，他们可能没有阅读我们的文章。他们可能正在访问德语维基导游、意大利语维基导游（最初的WV网站以及内容优势远超WT的网站）、中文维基导游和波斯语维基导游。我很惊讶俄语维基导游没有名列前茅，考虑到他们在古迹方面所做的工作。

基于此，我认为对于维基导游来说，WMF应该专注于创建更多的WV语言版本，特别是WT已经拥有的那些，因为创建越晚，克服内容差距就越困难，尤其是在搜索引擎排名方面。对此我们大多数人无能为力。但是，值得注意的是，WT 8.5%的流量来自日本，而日语维基导游仍在孵化中。ARR8 (讨论 | 贡献) 2019年3月19日 15:18 (UTC)

WV的Alexa排名刚刚超过WT（参见Wikivoyage:Wikivoyage and Wikitravel）。WT在美国（占据英语世界大部分）仍然更大。/Yvwv (talk) 2019年3月23日 14:44 (UTC)

我在西班牙语维基导游做了一些工作，但通常我的语言知识还不足以在那里做出重大或自由的贡献。--评论者 自拍城市 (讨论 | 贡献) 2019年4月1日 00:35 (UTC)

我编辑过一点中文维基导游，但他们的覆盖面非常差。即使是赫尔辛基、里加和基辅这样的首都城市，也只是纯粹的骨架。（如果我能在电脑上轻松打字而不是使用安卓键盘上的听写软件，我会贡献更多。）OhanaUnited^讨论页 2019年4月1日 03:52 (UTC)

抱歉，我迟到了...在我们的中文维基导游中，我们比中文维基旅行有更多的文章和编辑者，但我们的中文维基导游在界面和功能上仍在不断改进。无论如何，我认为日语和韩语确实需要尽快孵化。毕竟，长时间的延迟将非常不利于维基导游在韩国和日本的发展。--Yuriy kosygin (talk) 2019年4月2日 18:31 (UTC)

我记得，分叉发生时，日本维基旅行社区是唯一投票选择留在Internet Brands而不是迁移到WMF的社区。上次检查时，他们仍然是一个活跃的社区，并且仍然乐意留在原地。-- AndreCarrotflower (talk) 2019年4月2日 23:47 (UTC)

@Yuriy kosygin: 无需抱歉，我只是指出中文WV文章的现状，希望能有更多能轻松打中文的人阅读此讨论并做出贡献。OhanaUnited^讨论页 2019年4月3日 03:42 (UTC)

• 向这里的所有人致以最热烈的祝贺。我们终于在Alexa排名上超越了WT :-) 旅行医生詹姆斯 (talk · contribs · email) 2019年4月14日 17:37 (UTC)

travellerspoint.com 维基也是...

Alexa排名固然好，但大多数用户可能来自谷歌。最近似乎如果我输入“目的地维基指南”，上面那个页面常常“胜出”。我们的指南通常更全面，所以最好找出这发生的原因……维基导游的一些政策实际上可能是相对平庸的搜索引擎优化结果的原因吗？-- andree.sk(talk) 2019年4月16日 13:57 (UTC)

嗯，那个网站的受欢迎程度已经低于10万名以下了。旅行医生詹姆斯 (talk · contribs · email) 2019年4月16日 21:11 (UTC)

与我们许多人（包括我自己）的假设相反……

...维基导游实际上比我们的营利性竞争对手做得相当好。Alexa将我们稍微领先于Wikitravel和Fodor's；远领先于Rough Guides、Frommer's、Travellerspoint、Backpackers.com和Moon Travel Guides；并且仅落后于Lonely Planet和TripAdvisor。我认为这使得任何关于与其他网站协同合作的讨论都变得不切实际，因为唯一我们有理由合作的网站（后两者）都是以商业模式运营的，因此任何此类合作都会违反WMF的非营利精神。

抄送：Yuriy kosygin和andree。

-- AndreCarrotflower (talk) 2019年4月16日 21:30 (UTC)

Alexa的旅行指南和目录网站列表将我们排在第7位，落后于TripAdvisor、Timeout、Lonely Planet、Tripsavvy、Travelzoo和Ixigo。我没有听说过其中一些网站，但深入了解后，它们似乎在少数几个国家非常受欢迎。Travelzoo似乎也不是旅行指南。还有一个旅行出版物网站列表，它们是旅行杂志，涵盖了类似的领域，目前有几个网站的排名更高。此外，许多新闻和纪录片网站都有受欢迎的旅行指南部分，如CNN Travel、BBC Travel和National Geographic Travel，但不幸的是Alexa无法捕捉这些旅行部分的排名（尽管社交媒体粉丝等间接证据表明它们比WV更受欢迎）。

我认为Wikivoyage在许多欧洲大陆国家（德国第5774位，意大利第2458位）和伊朗（第5273位）已接近人气顶峰，但在英语母语国家和亚洲仍有显著增长机会。WV在美国的排名低于WT，例如在澳大利亚，Wikivoyage不在前15名旅行指南网站之列。澳大利亚在线旅行知识的主要来源是“Traveller”，其排名在600位左右，但它不在其他任何国家使用。它是悉尼先驱晨报的一个分支，但拥有独立的域名，所以你可以看到它有多受欢迎。德语和意大利语的Wikivoyage更早分叉，这就是它们得以稳固发展的原因。但没有理由表明Wikivoyage不能在全世界范围内同样闻名。Gizza ^(漫游) 2019年4月16日 22:35 (UTC)

我认为重要的是不要混淆视听。你提到的网站与旅行相关，但它们本身并非旅行指南，因此我们实际上并未与它们竞争。维基导游不像Timeout那样是一个粗制滥造的列表网站，我们也不是像Travelzoo或Ixigo那样类似Expedia的预订引擎，我们不发布旅行随笔或杂志风格的文章，正如《国家地理》所做的那样，我们也不类似于CNN或BBC等电视网络上的旅行专题。（坦率地说，尽管我知道是我提到了TripAdvisor，但我们甚至无法与它们相提并论；我将它们更多地视为类似Yelp或Google Reviews的网站，而不是像我们这样的网站。）-- AndreCarrotflower (talk) 2019年4月16日 23:02 (UTC)

说到苹果和橘子，我想说Tripadvisor不是旅游指南，但由于许多人把它当成旅游指南来使用，所以值得用来比较。--评论者 自拍城市 (讨论 | 贡献) 2019年4月16日 23:39 (UTC)

维基导游是A，其他旅游网站是B。它们与我们不同，但仍有重叠之处。我们最终的目标之一是成为互联网上大多数人在获取交叉旅游知识时选择使用的首要来源。

我们以与上述许多网站不同的格式呈现信息，但信息本身在很大程度上重叠。从旅行者的角度来看，这是来自不同来源的相同信息。国家地理杂志上许多关于徒步旅行的在线内容与我们的行程文章非常相似。在澳大利亚的“旅行者”案例中，它不仅有列表和旅行新闻文章，还有关于特定目的地的深度指南。BBC有一个旅行小贴士栏目，其中包含的文章与我们的一些旅行主题（例如经济旅行）非常相似。许多网站都有一个旅行论坛，其目的与这里的旅游局相同。我想说，与我们相比的大多数网站都是苹果和梨，而不是橘子。这类似于维基百科，它的竞争对手（因此受其崛起影响的网站）不仅仅是像《大英百科全书》这样的百科全书，还有其他以不同方式呈现类似信息的综合参考网站。

无论如何，我的观点更多是关于从长远来看保持谨慎乐观。维基导游有能力在每个国家都变得像在意大利一样出名和被使用，在那里它是一个排名前2500的网站。无论上述其他网站是否是我们的真正替代品，这都是我们应该追求的目标。Gizza ^(漫游) 2019年4月17日 04:05 (UTC)

布达佩斯/奥布达的错误

已从旅客酒吧扫过

这里有语法错误吗，还是文章的列表数量有最大限制？--Traveler100 (talk) 2019年4月17日 06:25 (UTC)

我怀疑是模板数量的上限，而不是列表数量的上限。文章底部的一些非列表模板也出现了问题。那篇文章使用了大量的模板，因为它使用了Template:rint和Template:station来使所有的公共交通信息都带有颜色。—Granger (talk · contribs) 2019年4月17日 06:46 (UTC)

是的，就是这个。我已经注释掉了饮食列表中的车站。输出错误已经消失了。--Traveler100 (talk) 2019年4月17日 07:55 (UTC)

这样确实解决了问题，但这也意味着我们丢失了这些部分所有列表的指示。仔细想想，其他列表中的指示也不是很清楚（“Remetehegyi út 165”是什么意思？“Remetehegyi út”是一个车站名称还是一条线路？）。令人困惑的是，图标与布达佩斯文章中使用的不同。最好将其替换为更清晰、更具体的文本。“进入”部分对于不熟悉布达佩斯公共交通的人来说也相当不透明——那些是地铁线吗？电车？公交车？—Granger (talk · contribs) 2019年4月17日 09:04 (UTC)

为什么对模板有限制？有没有办法为这篇文章特别更改这个限制？--评论者 自拍城市 (讨论 | 贡献) 2019年4月17日 13:41 (UTC)

前几天在德国也看到了同样的问题，我们应该在可能的情况下稍微增加内存限制（增加一半？），比如wgLuaMaxTime之类的？-- andree.sk(talk) 2019年4月18日 06:22 (UTC)

我们应该联系谁来改变这些事情呢？--评论者 自拍城市 (讨论 | 贡献) 2019年4月18日 13:32 (UTC)

我想在YouTube上帮助推广维基导游。

已从旅客酒吧扫过

我上传了许多中文播放列表中的教学视频。但是，我希望许多维基导游的朋友能提供一些视频，这样我就可以在YouTube频道上帮助推广维基导游，我也欢迎希望参与的朋友成为管理员来管理YouTube频道。

如果您想推广Wikivoyage，请在Commons上提供关于Wikivoyage的视频，或直接上传到Youtube。我将协助在Wikivoyage频道上传或雇佣，谢谢！--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年4月17日 17:44 (UTC)

关于维基期刊成为新姊妹项目的提案

已从旅客酒吧扫过

在过去的几年里，WikiJournal用户组一直在MediaWiki平台上构建和测试一套经过同行评审的学术期刊。主要文章类型包括

• 现有维基百科文章提交外部评审和反馈（示例）
• 从头开始撰写的文章，经评审后导入维基百科（示例）
• 未导入维基百科的原创研究文章（示例）

提案：维基期刊作为新的姊妹项目

从维基百科的角度来看，这是一个与优良条目评审互补的系统，但它通过外部专家弥合了差距，实施了既定的学术实践，并生成了可引用的、带有DOI链接的出版物。

请大家看看并支持/反对/评论！Evolution and evolvability (talk) 2019年6月3日 04:25 (UTC)

对我来说看起来不错。你需要人们在哪里表达意见？另外，有音乐方面的报道吗，或者有没有考虑过报道？目前涵盖了哪些学科？Ikan Kekek (talk) 2019年6月3日 06:03 (UTC)

@Ikan Kekek: 这篇帖子是为了征求大家的反馈，作为一项大规模的公告，这样不仅是那些已经知道这个项目的人会评论。目前，提议的姊妹项目有3本英文期刊，采用钻石/白金开放获取模式（读者和作者均免费）：医学、科学和人文。未来可以扩展到其他语言，如法语、西班牙语、中文等。作为一个科学人，我对人文了解不多，但音乐可能属于该期刊的范畴。如果提交的数量足够多，未来当然有可能设立一本专门针对音乐的期刊。（完全披露，我是《维基科学期刊》的编委会成员之一）OhanaUnited^讨论页 2019年6月3日 23:37 (UTC)

• 听起来是个好主意。它会只对学者开放吗？万一没有人注意到，这意味着维基媒体网站上关于“维基导游是维基媒体项目中最新的一个”的提及将不得不进行调整。--评论者 自拍城市 (讨论 | 贡献) 2019年6月4日 00:27 (UTC)

OhanaUnited，我的问题本质上是我不明白你需要人们在哪里就维基期刊被维基媒体基金会接受为姊妹项目发表赞成或反对的意见，这我认为是公告的目的。在这里发表意见不会有太大分量。Ikan Kekek (talk) 2019年6月4日 01:15 (UTC)

@Ikan Kekek: 讨论的链接其实是粗体的，写着“提案：维基期刊作为新的姊妹项目”，它会直接把你带到元维基页面。OhanaUnited^讨论页 2019年6月4日 01:30 (UTC)

谢谢。 :-) Ikan Kekek (talk) 2019年6月4日 04:20 (UTC)

是的。该提案直到最近都获得了几乎一致的支持，但现在得到了更多的宣传，投票变得更加混合。--评论者 自拍城市 (讨论 | 贡献) 2019年6月5日 14:19 (UTC)

维基导游的YouTube频道需要更多的语言管理员

我想邀请来自英语及其他语言的维基导游朋友们，共同管理和上传YouTube教学视频，以便维基导游能全面以所有语言进行宣传。我们已经有很多中文视频和直播，希望有更多英语及其他语言的内容加入到频道中！

如果您是维基导游任何语言的管理员，我期待您向我提供您的个人Gmail，这样我就可以将您添加为YouTube管理员，您将可以在YouTube频道上上传视频！欢迎大家订阅，谢谢！(参见维基导游频道)--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年9月30日 16:23 (UTC)

你还打算在频道上做英文的“旅行”内容吗？例如，一位伦敦居民谈论汉普斯特德存在的鲜为人知的博物馆，或者一位墨尔本居民谈论有轨电车。（还有其他独立的YouTuber制作旅行相关内容。）ShakespeareFan00 (talk) 2019年9月30日 22:12 (UTC)

@ShakespeareFan00: 我们有英文列表，但我只使用中文。你的想法很好，我希望你能帮助我们管理YouTube频道。毕竟，我的英语很差，真的很糟糕。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月1日 14:44 (UTC)

很遗憾，我没有能力或技能水平提供帮助。ShakespeareFan00 (讨论) 2019年10月1日 15:42 (UTC)

如果你想为YouTube频道提供旅行内容，我想知道m:VideoWiki对你是否有用。User:Ian Furst可能比我能解释得更好。WhatamIdoing (讨论) 2019年10月1日 17:05 (UTC)

这里有一个视频脚本的例子 视频是根据脚本自动生成的。这是YouTube上的视频Travel Doc James (讨论 · 贡献 · 电子邮件) 2019年10月3日 03:56 (UTC)

@WhatamIdoing、Doc_James：好主意，但是m:VideoWiki没有关于旅行的视频...--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月6日 15:08 (UTC)

我会考虑这样做，因为我们越能使用YouTube账户，效果就越好。--评论者 Selfie City (讨论 | 贡献) 2019年10月6日 12:48 (UTC)

@SelfieCity：谢谢。✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月6日 15:11 (UTC)

唯一的问题是我有多个Gmail账户（其中一个专门用于维基）。我想我应该用那个，我只是不想混淆账户。--评论者 Selfie City (讨论 | 贡献) 2019年10月6日 17:53 (UTC)

@SelfieCity：好的。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月7日 14:39 (UTC)

我想你会想把脚本保存在维基导游上？在维基百科的沙盒中创建一个。然后转移到维基导游，我可以看看如何让这个工具在这里工作。Travel Doc James (讨论 · 贡献 · 电子邮件) 2019年10月6日 23:41 (UTC)

@Doc_James：毕竟，我不知道如何转移到维基导游...像这样吗？--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月7日 14:39 (UTC)

已开始在Template:Videowiki构建一些后台工具

基本上，你想在旅行主题上创建一个像这样的，对吗？Travel Doc James (讨论 · 贡献 · 电子邮件) 2019年10月7日 19:10 (UTC)

@Doc_James：是的！--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月9日 17:15 (UTC)

好的，你可以先在维基百科上创建一个。我将尝试找出如何让这个在维基导游上运行。Travel Doc James (讨论 · 贡献 · 电子邮件) 2019年10月10日 02:28 (UTC)

看来我们这里没有信息框的模板。这格式不太好 Template:VideowikiTravel Doc James (讨论 · 贡献 · 电子邮件) 2019年10月10日 12:31 (UTC)

除非VideoWiki项目只打算在少数维基上运行，否则其对任何模板（尤其是英语维基百科复杂的Infobox模块系统）的依赖需要被移除。在全球模板成为现实之前（这是一个大型的、多年期的技术项目），像这样的项目必须在“处处可用”或“使用本地模板”之间做出选择。WhatamIdoing (讨论) 2019年10月10日 17:06 (UTC)

嗯，看起来很复杂；我只是希望大家能通过提供YouTube视频来帮助推广维基导游。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月13日 15:24 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘你用什么应用程序？iMovie？--评论者 Selfie City (讨论 | 贡献) 2019年10月13日 17:05 (UTC)

@SelfieCity：我已回复您的邮件，我使用万兴喵影，谢谢。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月14日 13:41 (UTC)

谢谢！有时间我会看看那个应用的。--评论者 Selfie City (讨论 | 贡献) 2019年10月14日 13:42 (UTC)

需要修复的损坏过滤器

大家好！最近，我们一直在将所有维基切换到使用新的、更快的解析器来处理AbuseFilter。不幸的是，这个维基无法切换，因为其中一个过滤器包含不支持的语法。具体来说，它是过滤器36。为了修复它，你应该删除第5行末尾的&!。有人能看一眼吗？如果您有任何问题，请随时回复我！谢谢，--Daimona Eaytoy (讨论) 2019年10月5日 16:56 (UTC)

我只是删除了您提到的文本。如果这个删除对过滤器有任何损害，就需要更有知识的人来修复这些问题。--评论者 Selfie City (讨论 | 贡献) 2019年10月5日 16:58 (UTC)

@SelfieCity：谢谢！从技术上讲，那部分等同于 & !null，也就是& true，所以删除它没有任何影响。再次感谢，--Daimona Eaytoy (讨论) 2019年10月5日 17:07 (UTC)

好—感谢您的解释。--评论者 Selfie City (讨论 | 贡献) 2019年10月5日 19:30 (UTC)

@SelfieCity：你好，我刚刚意识到过滤器34在第7行也有同样的问题。你能修复一下吗？另外，顺便说一下，新的解析器现在也在enwikivoyage启用了 :) 谢谢，--Daimona Eaytoy (讨论) 2019年10月8日 16:45 (UTC)

当前OTBP莱奇沃思州立公园的破坏性编辑，需要立即关注

简单来说：上述页面正在发生编辑战，涉及我和Powers，你们许多人都知道他是一个用户，他反对动态地图，支持静态地图的立场已经从强烈发展到强硬，现在看来已经达到了狂热和破坏性。

几天前，我将莱奇沃思的静态地图替换为动态地图，其中所有POI都已标记。正如你所看到的，静态地图没有列出的兴趣点，对旅行者来说基本上毫无用处。我的编辑被回退，理由是公园入口未在动态地图上标记。然后我回退了回退，声明解决这个问题的最简单方法是在动态地图上标记入口（我已经这样做了），而不是1）恢复一个对旅行者基本上毫无用处的静态地图，以及2）通过缩小动态地图使其不再比静态地图有用，这也是早期编辑的一部分。为了我的麻烦，我的回退的回退随后又被回退。不用说，这种行为是不可接受的，尤其是来自Powers这样身份的用户。

从更宏观的角度来看，我们的社区最近就何时使用动态地图以及何时使用静态地图这一长期争议达成了解决方案——分别是在像莱奇沃思这样的底层目的地和区域文章中，这些文章的具体内容（国家边界、城市位置等）很少或根本没有变化（当知道如何编辑静态地图的活跃维基导游人数非常少时，这一点很重要）。坦率地说，我们之所以能够在以前未能达成共识的情况下取得成功，很大程度上是因为Powers的编辑历史变得越来越零星，因此我们得以在他离开期间享受到他一人反动态地图运动的足够长的休息时间，从而推行政策。此外，我们最近还达成共识，除了少数特殊情况外，文章通常只应包含一张地图，并且绝不应包含多张带有冗余信息的地图，莱奇沃思的两张地图就是这种情况。如果为了一个几乎不活跃的用户，他无法接受共识与他意见不符的想法，我们就要重新讨论这些问题，那我真是活该。如果一个当前的主页特色文章，本月维基导游浏览量最高的文章之一，将成为这场冲突的发生地，那我真是罪孽深重。

通常在这种情况下，最简单的解决方案是在文章在主页上显示期间进行半保护。然而，由于Powers是管理员/行政员，没有任何级别的文章锁定会影响他。鉴于此，我建议的解决方案是将文章恢复到其在主页上发布时的状态——即突出且可用的动态地图，没有静态地图——并且Powers的进一步破坏将导致一项仅涵盖莱奇沃思州立公园文章的部分禁令，立即生效（等待十四天以解决用户禁令讨论将毫无意义），并持续到文章作为OtBP的任期结束。然而，由于部分禁令是一个相对较新的软件功能，从未在本网站上使用过，我宁愿不单方面实施该解决方案。您的反馈意见值得赞赏，越快越好。

-- AndreCarrotflower (讨论) 2019年10月14日 23:56 (UTC)

我看不出在未经行政员同意的情况下，对行政员/管理员的禁令如何能生效，因为他们有权撤销禁令。我的感觉是：在所有条件都相同的情况下，静态地图就是更好。然而，在这种情况下，很明显显示兴趣点的动态地图更好。我的感觉是，如果必须提出用户禁令，那么也需要取消Powers的管理员权限，这需要投票，通常在Wikivoyage:Administrator nominations进行，但在这种情况下，我想会在Wikivoyage:User ban nominations进行，同时提出主题禁令提案。Ikan Kekek (讨论) 2019年10月15日 00:30 (UTC)

Ikan - 我很确定对系统操作员执行的用户禁令也会阻止他们使用系统操作员工具，使他们无法解封自己。否则，我去年意外封禁Ibaman和Traveler100（再次抱歉，各位）就不会导致那些问题了。我不确定对行政员是否有所不同，但我对此表示怀疑。-- AndreCarrotflower (讨论) 2019年10月15日 00:52 (UTC)

好的，如果这样的话，那就没问题了。希望编辑战能停止，我们不用再做任何事情了。Ikan Kekek (讨论) 2019年10月15日 01:17 (UTC)

恢复现状，直到它离开OTBP。然后我们可以决定是否要“取消Powers的行政员权限”。--评论者 Selfie City (讨论 | 贡献) 2019年10月15日 01:19 (UTC)

SelfieCity - 这不是关于取消Powers的管理员权限，那将是一个单独的讨论（也不是一个主题禁令，我上面听到有人提到）。这是关于如何阻止编辑者对文章进行编辑的问题，因为他们的用户权限级别使他们不受页面保护（无论是半保护还是完全保护）的影响。如果我们将此视为一个在通常的用户禁令渠道之外处理的紧急情况，那么我认为将范围保持在尽可能窄的范围内是很重要的；在对Powers实施部分禁令的情况下，他仍将完全能够在除莱奇沃思州立公园以外的所有页面上编辑和使用管理员工具。-- AndreCarrotflower (讨论) 2019年10月15日 01:23 (UTC)

好的。我当时很忙，没有仔细阅读你写的东西。我认为我们可以制定一条规则，规定对特色文章的更改，除非是重要的更正、更新或撤销有问题的编辑，否则不允许。如果有一条明确的规则和惩罚，我想这不会再发生。--评论者 Selfie City (讨论 | 贡献) 2019年10月15日 01:37 (UTC)

（另外，阅读你的帖子：我确实对一个用户进行过一次部分封禁。）--评论者 Selfie City (讨论 | 贡献) 2019年10月15日 02:15 (UTC)

同意在这种情况下动态地图更好，但谈论封禁一个长期用户，即使是暂时性的，我认为对于我所看到的两次回退和编辑之间没有讨论分歧的情况来说，有点过分了。--Traveler100 (讨论) 2019年10月15日 05:24 (UTC)

同意上述观点。我没有看到André或Powers在任何讨论页面上试图以尊重的方式讨论这个分歧，而这本来是最好、最简单的选择。在这些情况下，任何禁令都是荒谬的，并开创了一个不好的先例。我鼓励你们双方都谈谈这个问题。--ThunderingTyphoons! (讨论) 2019年10月15日 06:04 (UTC)

我认为不应该封禁。如果我们要封禁任何人，我会说因编辑战和未在讨论页讨论而封禁两个用户。Pashley (讨论) 2019年10月15日 08:26 (UTC)

如果有人给出的编辑理由没有明显违反政策（或者明显语法不佳、事实不正确等等），并且你已经编辑过一次页面，他们又以一个理由恢复了，你的职责是主动开始一个讨论页线程。据我理解，编辑战的标准是回退两次。我只会在有人进行宣传、破坏或恢复我无法真正理解的文本（因为英语太差，或者明显拼写或语法不正确）时才这样做——在后一种情况下，我也会在该页面或他们的用户讨论页上开始一个讨论线程，解释为什么他们的编辑在我看来明显不正确，并且可能会在一两天内不进行第二次回退。

对我来说，这意味着Powers在这里的责任更大，特别是我们到目前为止似乎都同意他的论点在这种情况下不合逻辑。是的，Andre本可以在那个讨论页上开一个帖子，但我认为他在这里开帖子并没有错，因为那个页面正在被特色展示，他想确保更多的人关注他的立场。我们可以随时将这个帖子移动到那个页面的讨论页。

另一件事是，我认为现在没有人建议任何形式的禁令。提案是关于如果Powers继续编辑战该怎么办。而那些反对Talk:Letchworth State Park缺少讨论线程的人，在我看来，最好关注如果编辑战持续下去我们应该怎么办，而不是只关注你们偏好的程序。那么你们怎么看？这些回退是否可以一直持续下去？如果不行，你们建议怎么做？Ikan Kekek (讨论) 2019年10月15日 09:49 (UTC)

嗯，既然还没有进行讨论，我们也不知道Powers是否打算继续就此进行编辑战，也不知道除了一个编辑摘要之外，他还有什么想法。我想说，很明显，如果他继续编辑战，根据现有政策，封禁是合理的。但我们还没有到那个阶段，因为总共四次编辑并不等同于一场严重的编辑战。

但我们还是问他吧：@LtPowers：您能否加入关于莱奇沃思地图的讨论，或者停止编辑战？谢谢。

就记录而言，虽然我同意“Powers在这方面更有过错”，因为André在“编辑战”中的角色是捍卫共识，但我仍然觉得这次讨论的开启方式（没有提及另一位涉事者，并将其描述为“狂热分子”，在当事人不在场的情况下在整个社区面前讨论封禁他们，所有这些都在任何直接“对话”尝试之前进行）是过分的。--ThunderingTyphoons! (讨论) 2019年10月15日 10:33 (UTC)

我同意。编辑战已经停止，所以我认为继续讨论一个特定用户的“如果他……”是不公平的。将其变成八卦/抨击帖子，我想说比编辑战更糟糕。如果他有什么想说或讨论的，我们应该等待并允许他这样做。编辑战已经停止，所以没有什么可谈的了。ChubbyWimbus (讨论) 2019年10月15日 12:06 (UTC)

ThunderingTyphoons! - 我认为我在最初的评论中已经清楚地表明，这并非孤立事件，而是我们自动态地图首次引入维基导游以来就与Powers存在的问题的一部分，而且我们实际上过去曾多次尝试与他讨论地图问题，并一直因其不合理的做法而感到困惑。（特别是他在Wikivoyage talk:Dynamic maps Expedition/Archive 2014-2015的评论中包含了许多这样的例子，只需看看有多少完全有价值的星级提名仅仅因为他反对动态地图而被搁置或长时间处于悬而未决的状态。）如果我有理由相信讨论页能够解决问题，我绝不会提出我上面建议的方案，但我现在就可以告诉你这样的讨论会如何进行：我会被严厉批评，因为我竟然敢建议移除他辛苦制作的地图，会被告知动态地图是“懒惰者的敷衍了事，他们懒得学习如何编辑静态地图”，不得不听他说动态地图上的图标靠得太近，就好像解决这个问题不像放大一样简单，以及他过去无数次用来阻碍解决这个问题的其他琐碎挑剔，就好像他的观点以前没有被多次解决过一样。在某个时候，忍无可忍，不再是我们的责任去第5000次地试图与他讲道理，而是他的责任放弃这个问题。如果一个当前的特色文章，再次是网站上最显眼的文章之一，正处于危险之中，那么现在就是这个问题爆发并果断解决的时候了。

至于Powers“不在场为自己辩护”：如果他想这样做，没有什么能阻止他。我们并非都挤在某个烟雾弥漫的房间里，没有人能看到发生了什么。这里是旅客酒吧。我几乎想不到有比这更显眼、更容易访问的页面来进行这场讨论了。如果Powers是管理员和行政员，他应该已经把酒吧添加到他的监视列表了，如果他足够关心这个问题以至于反复回退我的编辑，他就不应该需要被提及。

Pashley - 你关于“因编辑战和未能在讨论页讨论而封禁双方用户”的评论是无益的，并暴露了对编辑战性质及其相关政策的根本误解。事实是，“讨论”已经结束很久了。我们已经就动态地图是否以及在何种情况下使用达成了共识。再说一次，这已经成为一个案例，一个用户拒绝接受未遂的共识，已跨越界限，演变为破坏性行为。（我实际上会争辩说，这条界限在几次事件前就被越过了，但无论如何，这种行为的破坏性不应该再被任何人质疑。）因这种情况可能导致的任何编辑战的责任，绝不是由将文章恢复到基于共识的现状的人平等分担的。

ChubbyWimbus - 没有理由相信“编辑战已经停止”。它只是以异常缓慢的速度进行着。Powers分别用了30小时和19小时来回应我在莱奇沃思文章中的编辑，而距离最近一次交锋也才过去16小时。“万一”仍然是非常恰当的问题。-- AndreCarrotflower (讨论) 2019年10月15日 15:20 (UTC)

Andre，我想你的批评者关于这个话题的整体大致观点是正确的。这场小小的编辑战本不需要发生，即使发生了，我们也不需要600个词来告诉我们，要办成任何事，唯一的办法就是等待一位长期贡献者不在的时候。

我真的认为你只需发帖说“嘿，Powers和我在哪个地图更好方面似乎无法达成一致。你们中的一些人能做出决定吗？我保证接受你们的任何决定。”这真的太小了，不值得任何人如此烦恼。

前段时间，我的一位同事，他住在一个有很多旅行警告的地方，在半夜给我发了一条聊天信息，问我是否有时间谈谈一些严肃的事情。我的第一个想法是他的一个孩子受伤了。但是，不：他只是因为担心维基上会就两个略有不同的选项哪个更好而发生巨大争议而失眠。我们这里不要这样。我们不要真的为了用哪个地图而失眠。如果两个编辑者无法友好解决，那么就把争议抛给我们其他人，把页面从你的监视列表中移除，秘密决定不再参与进一步的讨论，让我们为你处理。没有人会死。不要为了这个而破坏我们友好的环境。WhatamIdoing (讨论) 2019年10月15日 16:03 (UTC)

WhatamIdoing - 我们可能会过度美化“我们友好的环境”。我作为维基导游的活跃用户已经八年了，其中大部分时间，维基导游都是一个争议未决、根本问题长期存在的地方，因为人们过于“友好”，不愿互相冒犯。这让我恨不得把所剩无几的头发都扯掉。幸运的是，这种情况终于开始改变了，尽管我们距离真正学会如何处理因少数但声音很大的群体而导致问题停滞不前的局面还有很长的路要走。我们不必像维基百科那样变成一个充满反社会行为的毒瘤，但就我个人而言，我认为偶尔忍受一下并输掉偶尔的争论，是换取一个运行顺畅的社区的合理代价。-- AndreCarrotflower (讨论) 2019年10月15日 16:11 (UTC)

我不认为我们对友善的环境太过重视。我不介意辩论：那是我的日常工作，然后我还会去英文维基百科争论如何制定政策。但是，我确实介意看到像这样把小的争议个人化。哪个地图属于那篇文章并不是一个多年来持续存在的根本问题。在我看来，如果你决定退出而不是主动攻击，它会更快、更少烦恼地解决。

我在英文维基导游做的一件事就是处理关于RFC的问题和投诉。多年来我学到的一点是，当有人提出关于某些主观事项的投诉（“这个问题具有误导性！”）时，通常意味着“我输了！帮我找个技术借口赢！”从这个角度来看，如果你真的确信共识和政策站在你这边，那么你可以立即把整件事交给我们其他人处理，而无需费心去追究对方，也无需试图解释你为什么是对的。如果你真的是对的，我们也会得出相同的结论，而且当很多人都说同样的话，而不是只有一个贡献者重复相同的说法时，更容易停止争论。你仍然可以采取这种方法。你仍然可以把这件事留给社区处理。我建议你这样做。 WhatamIdoing (讨论) 2019年10月15日 (UTC) 16:34

WhatamIdoing，我希望你不要再轻描淡写这个问题，假装这只是关于一篇文章中的一张地图，并且推断我在夸大其词。事实上，这仅仅是Powers多年来不合理行为模式的最新篇章，也是社区对这种行为的不合理迁就。我在上面已经给出了许多这种行为模式在过去造成社区问题的例子，没有理由期望它将来不会继续发生。因此，在我看来，通过在这里果断回应，我们有机会防止这种行为模式在未来多次重现，否则我们可能不得不一遍又一遍地应对。最后一部分值得重复：我不想比这里任何人都更浪费时间在这场争论中，但如果现在这样做能阻止我们在未来无限期地继续这样做，那么我愿意。

此外，鉴于这里正在发生或提议的几件事在Wikivoyage上从未发生过，这次讨论对于在这些领域建立先例也是必要的：即，当拥有管理员工具的人进行破坏性编辑，并且文件保护无法阻止他们时该怎么做，以及何时适合使用部分禁令。这些问题不能由一个用户单方面回答。如果我能够避免“带头攻击”并使用既定程序悄悄解决这个问题，我早就这么做了，但这是一个特殊情况。

-- AndreCarrotflower (讨论) 2019年10月15日 (UTC) 16:50

我更喜欢动态地图，但我不认为这是一个如此重要的问题。我不反对有两张地图，特别是当它们相互补充时，并且在页面上同时拥有两张地图并在讨论页上进行讨论可能是一种更好的方法（仅仅将两张地图放在讨论页上不起作用，因为没有标记）。我最近一直在使用Kwix离线阅读器，并注意到它（以及其他离线阅读器）不显示动态地图——如果公园有大片区域没有信号，那么这是包含静态地图的一个论据（也许除了动态地图之外）。在第一次编辑摘要中称静态地图“相当无用”并不是一个外交性的开始。 AlasdairW (讨论) 2019年10月15日 (UTC) 20:31

Andre，我不是在轻描淡写当前的问题或历史。我告诉你，你（你个人）无法解决这个问题。我还告诉你，你在这场讨论中参与得越多，特别是你越是告诉任何可能不同意你的人他们是错的、是坏的或者不理解，这个问题本周解决的可能性就越小。如果你真的想解决这个问题，那么你必须退后一步，让所有不是Andre的人来处理剩下的事情。 WhatamIdoing (讨论) 2019年10月16日 (UTC) 16:31

• （编辑冲突）首先，Ikan Kekek和WhatamIdoing在这里说的都很有道理，很好地权衡了全局。我不认为他们是在为Powers辩护或攻击Andre。我通过访问Powers的修订版本查看了静态地图，它并没有像暗示的那么糟糕。虽然我相信Powers的行为是错误的，而且这在某种程度上是一场编辑战，但这并非紧急情况。

然而，Powers的行为需要处理，可能通过移除管理员权限（这与封禁或禁言不同）。如果Powers不愿意就此事服从共识，希望能够以积极的方式完成。如果他能道歉并明确表示他将不再对文章做同样的事情，那么他绝对应该保留他的管理员权限，如果他愿意的话。

我准备了一系列声明，希望我们能就此达成共识。我们是否同意以下几点？

1. Powers在莱奇沃思州立公园文章上的行为是不恰当的，并且因为该文章是特色文章而变得紧急。Powers应该知道不应该在一个重要页面上采取这种行动，尤其是作为管理员；这种行动在Wikivoyage社区内部造成了不必要的分裂感和紧迫感。
2. 由于动态地图遵循共识批准，并已确立为该文章的地图，它应该保持到特色结束。然后，可以讨论其潜在的替代品，即静态地图。然而，如上所述，在特色文章上违反标准是不恰当的。我们必须维护共识，特别是在我们的特色文章上。
3. 需要告知Powers他的行为是错误的，他需要明确表示他不会再犯。

我们同意这些观点吗？如果不同意，我们需要认真重新考虑我们是否能就如何处理这个问题达成共识。--评论者： Selfie City (讨论 | 贡献) 2019年10月15日 (UTC) 20:41

SelfieCity，这听起来是一个合理的行动方案，我同意所有这些观点。不过，我更希望我们暂时不要偏离讨论Powers的管理员权限问题。如果他确实再次回滚我在Letchworth的编辑，那将是合乎逻辑的下一步，但目前尚不清楚这种情况是否迫在眉睫，我宁愿不通过猜测可能无关紧要的管理员权限移除来制造不必要的纷争。-- AndreCarrotflower (讨论) 2019年10月15日 (UTC) 20:48

我没问题，尤其是如果你是这么想的话。--评论者： Selfie City (讨论 | 贡献) 2019年10月15日 (UTC) 20:59

和AlasdairW一样，我喜欢在文章中同时拥有静态地图和动态地图，前提是这两种地图都能为读者和潜在旅行者提供独特的信息。它们之间的冗余程度并不比两张著名地标照片的冗余程度更高，这在Wikivoyage文章中很常见（通常其中一张是横幅，另一张是非横幅，但有时两张照片都是非横幅，以不同角度或方式拍摄）。 Gizza ^(漫游) 2019年10月15日 (UTC) 21:10

需要立即关注的争议已成功引起社区的关注。也许下次可以用少一些戏剧性的方式完成。关于用户禁令或移除管理员权限的讨论可以在Ikan Kekek上面链接的页面进行。

关于内容问题，我认为在这种情况下动态地图更好，尽管同时包含两张地图也可以。—Granger (讨论 · 贡献) 2019年10月16日 (UTC) 00:09

我不明白同时包含两张地图除了奖励Powers的糟糕行为，并可能因此鼓励未来发生类似事件之外还能达成什么目的。静态地图不包含动态地图中不包含的任何信息。-- AndreCarrotflower (讨论) 2019年10月16日 (UTC) 00:12

包含两张地图有助于那些看不到动态地图的人。这包括任何离线阅读或在不支持Javascript的设备上阅读的人。这种好处的存在完全独立于任何人的行为。 WhatamIdoing (讨论) 2019年10月16日 (UTC) 17:03

Selfie，我很抱歉，但我不能完全同意。

1. 我同意Powers的行为不尽理想，但我不认为Powers在Wikivoyage社区内部造成了任何分裂感和紧迫感。我认为这种分裂感和紧迫感来自于Andre选择回应的方式，即通过侮辱Powers并持续拍桌子，而不是中立地报告问题并相信其他人会处理。
2. 我不能同意页面在被推荐期间不应编辑。Powers的修改是否构成改进，在我看来是值得怀疑的，但讨论应该随时都是一个选项，并且即使文章在主页上被推荐，通常也应鼓励积极推进（但不进行编辑战）。
3. 我同意需要告知Powers存在一个包含动态地图的共识（因为我们普遍同意这一点，对吧？），当然没有人应该进行编辑战。关于声明的另一半，判断特定动态地图是否优于特定静态地图需要人们运用他们的最佳判断。因此，我将任何永不替换一种地图的承诺视为不恰当且几乎不可信。我不希望我们强迫贡献者做出“馅饼皮承诺”——像馅饼皮一样容易制作，并且在端上馅饼时很可能会被打破。 WhatamIdoing (讨论) 2019年10月16日 (UTC) 16:54

（缩进）我现在明白了，一开始我没有完全理解这个问题。对我来说，即使你确实试图解释这是一个持续且常见的事件，这一切都凭空出现（而且似乎其他人也发生了类似的事情）。我想我同意SelfieCity的观点。关于AndreCarrotflower关于“奖励不良行为”的观点，我想补充一点，用户应该避免“我两种地图都行”/“我无所谓”/“这篇文章不重要所以谁在乎”/等等类型的论点。这些都不是正当论点。它可能让人觉得能缓和紧张气氛，但这些言论只会混淆视听，与共识背道而驰，并忽略了这里提出的具体问题。那些态度模糊的人应该支持现状。支持恢复静态地图的论点需要明确说明这张地图除了动态地图之外还提供了哪些好处，以及/或者删除它会失去哪些好处。换句话说；包含/恢复静态地图必须有一个符合政策和共识的理由。出于对城市/文章/问题的冷漠而说两种地图都行，这是无益的，对按照共识行事的Andre也不公平。事实上，如果我们以如此薄弱的基础做出让步，那将是对任何未来想要无视政策的人的邀请，他们会引用这次讨论作为理由，而我们没有任何辩护。 ChubbyWimbus (讨论) 2019年10月16日 (UTC) 11:39

实际上，我认为所有这些都是合理的论点。如果两种地图都有理由存在，或者至少无害，那么我们应该这样说（“我两种地图都行”）。如果两种地图的优缺点平衡，那么指出这一点很重要（“我无所谓”）。如果社区为了看到一堆侮辱，处理人们的情绪反应，以及人们花费数小时调查此事而付出的代价，远高于文章中有一张不那么完美的地图或另一张不那么完美的地图所付出的代价，那么我们也应该这样说（“不重要”）。我和其他人指出，眼前的“紧急”问题可以通过Andre置身事外，我们其他人密切关注“近期更改”几天来轻松解决，这是完全合理的，而不是编辑战中积极参与的一方来到这里，大篇幅抱怨一位“不合理”、“狂热且具有破坏性”的贡献者，就“一个人反动态地图的运动”就“微不足道的细节”争论哪张地图更好，他“无法接受共识与他意见相左”。 WhatamIdoing (讨论) 2019年10月16日 (UTC) 16:42

我同意WhatamIdoing的所有编号观点，以及上面这篇帖子。 Pashley (讨论) 2019年10月16日 (UTC) 18:11

WhatamIdoing和Pashley——不。 ChubbyWimbus关于重复地图论点的非法性，说得完全正确。我们有一个共识，即动态地图在所有非区域文章中都是首选，文章在大多数情况下应只包含一张地图，并且在同一篇文章中绝不能使用多张地图来显示相同的信息。这个共识花费了大量时间和努力才达成。而且它是具有约束力的。它不会仅仅因为其存在对于解决一个不相关的问题不方便，或者为了不制造波澜和维护“友好环境”，或者因为你个人不同意和/或没有参与建立该共识，或者因为你个人不认为在这种特定情况下执行政策很重要，或者因为你个人认为辩论的另一方是一个混蛋，或者任何其他原因而神奇地消失。如果你要为Letchworth上的重复地图辩护，你最好彻底阅读我上面链接的帖子，并且你最好提出支持重复地图的论点，这些论点既1）以前没有提出过，又2）足够令人信服，足以让所有持相反观点的人改变主意，或者3）你最好提出一个相当有说服力的理由，说明为什么Letchworth是一个例外，并与其他所有使用一种或另一种地图的文章不同。否则，很抱歉，现状偏见适用，本讨论中涉及的亲重复地图论点应被驳回为非基于政策的。-- AndreCarrotflower (讨论) 2019年10月16日 (UTC) 21:51

我同意Andre，尽管我仍然坚持认为，在所有条件相同的情况下，静态地图更好，并且我继续主张对静态地图存在例外，即在任何文章中，如果静态地图完整、最新且比动态地图更清晰，则应允许使用。 Ikan Kekek (讨论) 2019年10月16日 (UTC) 22:05

此外，WhatamIdoing，关于我最初帖子的语气：请考虑一下，在我们所有参与这次讨论的人中，我是唯一一个清楚记得Powers之前所有与地图相关事件的人。我最初帖子的很大一部分致力于为那些需要提醒或当时不在场的人重述冲突的历史，希望人们不要将此视为一个孤立事件，而是多年来问题行为模式的进一步升级。结果人们还是这么做了，这让我更加沮丧。如果因为这个原因我显得对Powers过于报复心重和/或总体上显得像个戏剧女王，那是不幸的，也不是故意的，但这总比未能将Letchworth事件置于其 proper context 中要好。是的，Powers的整体行为模式仍然是一个重要的考虑因素，即使许多编辑者个人不记得过去的事件。这正是我们存档旧讨论页面而不是简单删除它们的原因。

此外，如果我在最初的帖子中使用了一些煽动性语言，我为此道歉，但也请考虑我是一个有情感的人，我刚刚经历了我的共识编辑连续第二次被回滚，而且自从我第一次在Letchworth作为OtBP之前的最后准备期间将静态地图更改为动态地图以来，我心里就一直隐约觉得他可能会出现并制造麻烦。所以是的，我有点恼火，任何人都会这样，也许我在所写内容的语气中表现得有点太多了。无论如何，任何回复此帖子的人都有责任忽略我选择的词汇，转而关注我传达的实际问题。而且，最重要的是，不要只见树木不见森林。

- AndreCarrotflower (讨论) 2019年10月16日 (UTC) 22:31

我想现在是时候审阅我们在Wikivoyage:Map的政策草案了，它已经作为草案两年了。“我应该用动态地图替换静态地图吗？”这一节在这里似乎相关。然而，下个月再做可能更好，这样我们就不会过于专注于一篇特定的文章。 AlasdairW (讨论) 2019年10月16日 (UTC) 23:04

如果地图不同，它们就不是重复的。我同意WhatamIdoing和Pashley。说两种地图都有助于改进文章是非常合理的论点。如果两者单独都不够用，却被迫选择其一，那反而会损害旅行者的利益。我也同意AlasdairW的观点，现在是时候审阅地图政策草案了。 Gizza ^(漫游) 2019年10月17日 (UTC) 00:28

我对这个回复感到困惑。地图怎么会不一样呢？-- AndreCarrotflower (讨论) 2019年10月17日 (UTC) 00:32

我们很容易就能有5种不同的地图，但这又如何服务旅行者呢？这不是一个专注于以不同方式绘制给定城市地图的地图集。真正使用不同地图的唯一情况是，当它们需要显示不同的事物时。 Ikan Kekek (讨论) 2019年10月17日 (UTC) 00:40

我倾向于同意Ikan Kekek的观点，即静态地图总体上更好，当所有条件确实相等时，但情况往往并非如此，而且在这篇文章中，静态地图没有任何列表，所以我不认为可以认为它更好。我当然不认为静态地图应该总是被删除（我仍然想删除日本区域文章中那些丑陋的动态地图）。WhatamIdoing，拥有既定的共识或政策意味着你无需处理用户对问题的情绪反应。你只需要参考共识即可。我认为告诉用户共识“不重要”因为他们的问题不是你的问题是不公平的。如果一个问题被提出，而共识突然失效，因为一群用户决定他们只是不想听到你抱怨/他们不喜欢你/他们不喜欢共识/等等，那么它何时才有效？因为这听起来你的论点是“当我关心这个问题并且共识支持我时，共识才重要，但当你关心时，无论如何它都不重要。”我预见到这不会优于或让用户感觉比参考政策或共识更好。正如我所说，那些真正不在乎的用户应该乐于维护现状。如果你不接受这一点，那么你一定有什么是你在乎的。 ChubbyWimbus (讨论) 2019年10月17日 (UTC) 11:36

我完全同意这篇帖子。 Ikan Kekek (讨论) 2019年10月17日 (UTC) 13:25

Chubby，我们是否被要求承担w:en:情感劳动的问题，仅仅因为有人对一次编辑感到不满，这与关于哪张地图最适合文章的共识问题是完全分开的。我确实关心一些事情：我不希望在这里读到侮辱性的言论。这对我来说很重要。我不希望读到让人觉得“天哪，他一定以为我们都不记得那漫长的苦差事了”或者“他正在发脾气”或者“听起来他似乎不尊重社区处理哪怕是这样微不足道问题的能力”的留言。我关心人们如何对待彼此。我们这次对话的记录正在改善，但开始时相当糟糕。

对于那些记得之前关于地图讨论的人，你们会记得我坚定地支持动态地图。我能够保持这个立场，同时承认它们有一些局限性（例如，离线阅读器无法使用，这在一个将印刷副本列为官方目标的社区中是一个相当大的局限）。我在这里的担忧更多的是关于我们如何处理争议的“元”问题，而不是关于地图（我相信社区会处理好，我们也做到了）。我希望将来，争议处理会减少侮辱、减少纠缠，并更加信任“存在共识”意味着你不需要独自完成所有事情，因为形成共识的人能够并且会为你处理任何争议。 WhatamIdoing (讨论) 2019年10月18日 (UTC) 16:30

我毫无保留地道歉。首先，为第二次回滚文章以包含静态地图而未经事先讨论，其次，为延迟回复。

我有一段时间没有在Wikivoyage上活跃，这不是秘密。但当我惊讶地发现一篇我开始并参与制作的文章成为特色文章时，我震惊而沮丧地发现，我花费了同样多时间制作的地图竟然在特色文章发布前仅仅一天就被无情地删除了——而且还附带了一条刻薄的编辑评论。我认为在没有讨论的情况下，完全删除我花费了相当多时间和精力添加到文章中的内容是不恰当的。动态地图并非这篇文章的长期特色（即使现在，它也只存在了不到两周），所以我很放心地回滚到原状，并附上编辑评论解释动态地图更好地展示了如何进入。（Andre将其解释为“动态地图没有显示入口”，但它远不止于此；静态地图还显示了高速公路和步道入口、附近的地标和社区、高速公路出口等。）作为妥协，你会注意到我并没有*回滚*删除静态地图的编辑；我重新添加了静态地图，并缩小了动态地图以进行补偿。

如果Andre不同意这个妥协，他本可以讨论的。相反，他只是单方面回滚了。我不应该撤销回滚，但我仍然认为它是不恰当的。而且我当然拒绝文章当前作为首页特色文章的状态意味着前一天所做的编辑是神圣不可侵犯且不应撤销的论点。

当然，这个帖子让我感到震惊。我有点不愿冲突（这就是我直到现在才回复的原因），当我考虑我应该在哪里花费时间时，这个帖子并没有起到鼓励作用。

-- Powers ^(讨论) 2019年10月23日 (UTC) 13:15

我还应该指出，静态地图上没有兴趣点，是因为我一直打算添加第二张地图，只显示公园南部的大部分兴趣点，以更大的比例，以便清晰阅读。兴趣点的密集程度在动态地图中非常明显，这就是我认为它不适合的原因。 Powers ^(讨论) 2019年10月23日 (UTC) 13:17

几天后回过头看我在上面帖子中的言行举止，我不得不不情愿地同意我的一些批评者的观点，即我解决这场争论并使所有人与共识保持一致的热情，有几次演变成了对Powers的人身攻击。尽管我们俩在网站相关问题上经常意见不合，而且我们在各自的观点上都可能相当固执，但我仍然认为Powers是一位同事和朋友。我不应该仅仅因为我们在Letchworth文章上的交流就忘记这一点。所以，Powers，请接受我为此道歉。

然而，一个有价值的同事或朋友也会在必要时对他/她进行问责。而且，在很大程度上，我坚持我所说实质性部分。至于您上面评论中的观点：Powers，自从我们推出动态地图功能以来，您就表达了对它的看法，这也不是您第一次就此问题与其他编辑发生冲突，所以我的“刻薄编辑摘要”可能是因为我情不自禁地将您回滚我对Letchworth文章的编辑的行为，通过那个棱镜来审视。至于您为Letchworth创建静态地图所花费的时间，这难道不是一个非常有力地反对为底层目的地使用静态地图的论据吗？您可能愿意投入大量无偿时间来1)学习如何制作静态地图，以及2)为您所编辑的每篇文章制作单独的静态地图，但其他编辑中有多少人也是如此呢？我可以用一只手指数出来：您、Ypsilon、Saqib和Shaundd；而Ypsilon是这四人中唯一一个不只是偶尔活跃在网站上的人。让底层目的地的文章没有地图，或者（更适合本案例）让它们使用因没有人知道如何和/或有时间更新而迅速过时的静态地图，真的比以一种美观上不那么完美但更容易维护的方式呈现相同信息更好的解决方案吗？答案是否定的，这不仅根据我的观点，也根据共识。（而且如果您真的“一直打算添加第二张地图，只显示公园南部的大部分兴趣点”，为什么在Letchworth被提名为月度目的地到它首次出现在主页之间的15个月期间，您没有这样做呢？尤其是考虑到其地图相关缺陷已被单独指出是一个问题？）

-- AndreCarrotflower (讨论) 2019年10月24日 (UTC) 16:19

谢谢你，Andre。

就记录而言，我所指的编辑摘要来自您最初删除静态地图的编辑，在我重新添加它之前。

当然，有地图总比没有地图好，而且过时确实是网站许多领域（不仅仅是地图）的问题。但我不知道Letchworth地图上的任何内容实际上已经过时（至少没有明显过时），我仍然认为在没有讨论或前言的情况下进行替换是不好的做法（尤其是在它即将登上主页的前一天）。

-- Powers ^(讨论) 2019年10月25日 (UTC) 01:24

Wikivoyage愿望清单提案

今年的愿望清单今天开放。只会接受五个愿望，并且仅限于非维基百科姐妹项目。m:Community Wishlist Survey 2020/Wikivoyage目前是空的。

我有去年我们考虑过的两个想法的笔记

• Wikivoyage短语手册中内联音频播放：想象一下能够阅读短语手册，点击一个按钮，无需离开页面即可听到单词的发音。（phab:T20852）这可能对维基词典也很有趣。
• 进一步的地图改进：争议边界（phab:T113008）是其中之一，但我们可能还能想到其他的地图改进。

大家还有其他想法吗？ WhatamIdoing (讨论) 2019年10月21日 (UTC) 17:05

我认为最需要的重要增强是动态地图上标记当前位置。这对于旅行/位置指南来说是一个关键功能，尤其是在大多数网络用户现在都是移动用户的情况下，了解周围有什么非常重要。（phab:T208713）--Traveler100 (讨论) 2019年10月21日 (UTC) 17:47

位置地图功能应该相对容易实现（我天真地认为），因为移动版已经可以找到附近地方的文章了。

页面上的音频文件功能不是已经可能了吗？维基词典上肯定有内联音频文件在使用，例如。难道我们错过了什么吗？--ThunderingTyphoons! (讨论) 2019年10月21日 (UTC) 18:03

我们花了一段时间研究内联音频，我认为我们没有解决。当我点击德语短语手册#数字上的音频图标时，它会为我打开一个新标签页。 WhatamIdoing (讨论) 2019年10月21日 (UTC) 18:05

像维基词典那样，使用他们的系统到底有多难呢？--ThunderingTyphoons! (讨论) 2019年10月21日 (UTC) 19:41

我想我们还没弄清楚是不是很难呢？ WhatamIdoing (讨论) 2019年10月22日 (UTC) 15:30

User:TheDJ写了phab:T208713。 WhatamIdoing (讨论) 2019年10月21日 (UTC) 18:07

动态地图能否调整方向，而不仅仅是严格的“上北下南”？在曼哈顿的地图中，“上”应该是上城区，而不是严格意义上的罗盘北。然而，我不同意显示“争议边界”。这违反了Wikivoyage的政策，即承认所有合理稳定的既成事实，不参与争议，除非它们影响旅行者。 Ikan Kekek (讨论) 2019年10月21日 (UTC) 19:59

看看像中国或日本这样的动态区域地图。每个县或区域的阴影区域都包含领海，因为这就是OSM行政边界关系所代表的。不幸的是，这与静态地图相比非常难看，静态地图只显示每个县陆地部分。据我所知，没有一个OSM实体可以表示这一点；你必须通过编程来计算它。--Bigpeteb (讨论) 2019年10月21日 (UTC) 22:41

我同意User:Traveler100的观点——最需要的重要功能是在动态地图上显示用户位置。我也同意我们应该能够像维基词典那样包含音频。User:Bigpeteb关于不显示领海的建议也不错。—Granger (讨论 · 贡献) 2019年10月21日 (UTC) 23:33

糟糕……我创建了关于添加景点地图以帮助游客通过地图找到附近景点和信息的任务，但没有先在这里的Travellers pub讨论，我非常抱歉……--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年10月27日 13:46 (UTC)

• 能否直接在地图形状上绘制多边形（形成区域和地区）？ --评论者： Selfie City (讨论 | 贡献) 2019年10月22日 01:51 (UTC)

  @SelfieCity: 这现在可以做到。我不记得具体怎么做，但我记得这很麻烦。你必须在维基上别的地方创建一个独立的文件，其中包含多边形的坐标，然后以某种方式将其链接到地图中。我以前见过例子，但现在没时间找，如果我有（也许你可以给我一个你认识的链接），我可以解剖它来解释如何完成。--Bigpeteb (讨论) 2019年10月31日 19:19 (UTC)

• 愿望清单应考虑读者目前认为最不足的地方。因此，它应包括完整的移动功能，无论是阅读还是编辑。i-phone以其现在的形式已经存在了近十年，在创新的洪流中保持稳定，想象一下如果我们用了那么长时间才适应黑莓。虽然这个愿望适用于所有WF项目，但对于WV来说尤其紧迫，因为WV最有可能在旅途中被访问。我猜测工作正在进行中，但其可见性如何，例如是否有项目页面、目标和时间表等所有管理上的好东西，以及一个讨论项目组件的论坛？这不仅仅是一个锦上添花的事情。除此之外，我们还需要思考技术的前沿，并考虑最大的语音激活功能。Alexa及其后续产品可能会在未来几年成为主要的搜索方法，WV需要被定位为回答此类旅行相关查询的首选。Grahamsands (讨论) 2019年10月24日 14:37 (UTC)

我完全同意你的观点！当我使用Android时，它的用户界面也很糟糕，但iPhone更糟糕。Ikan Kekek (talk) 2019年10月24日 23:44 (UTC)

关于页面横幅的移动端显示呢？这是我们内部可以解决的，还是需要修改MediaWiki软件？--ThunderingTyphoons! (talk) 2019年11月9日 12:43 (UTC)

截止日期是星期一

我们还有大约60小时来完成这项工作。到目前为止，提出的建议有：

• 添加景点地图，帮助游客通过地图找到附近的景点和信息
• 在地图上显示用户的当前位置
• Wikivoyage的内容翻译工作
• 评论显示本地时间
• 当地理定位被禁用时，“附近”特殊页面应显示输入表格和坐标选择器

（“评论显示本地时间”脚本并非Wikivoyage特有（任何项目都可能有用），因此可能被宣布超出范围。其他建议都是Wikivoyage特有的，但任何建议都有可能被认为对于这个团队来说太庞大而无法实现。）

我们还想在列表中添加什么？请记住，理论上Wikivoyage可以赢得所有五个愿望。提案正在按项目分类，但没有规定结果必须在姊妹项目之间均匀分配。WhatamIdoing (讨论) 2019年11月9日 19:26 (UTC)

• 我已添加请求，要求“被请求页面”只显示主文章命名空间中的红链结果。--Traveler100 (讨论) 2019年11月10日 06:21 (UTC)

第一本旅行指南

https://hyperallergic.com/523009/peregrinatio-in-terram-sanctam-british-museum/ —贾斯汀 (koavf)❤T☮C☺M☯ 2019年10月22日 15:45 (UTC)

从图片来看，它更像是一本插图地图集，而不是旅行指南，但仍然是一部引人入胜的历史参考资料。--评论者： Selfie City (讨论 | 贡献) 2019年10月22日 19:27 (UTC)

确实很有趣。谢谢分享。

但可以说它并非第一本；古希腊早在几个世纪前就有列出世界七大奇迹的书籍，而且据我所知，中国人、印度人或波斯人可能更早就有类似的东西。Pashley (讨论) 2019年10月23日 02:02 (UTC)

测试功能“引用预览”

一个新的测试功能即将部署到您的维基：引用预览。顾名思义，此功能可让您预览文章文本中的引用。这意味着，您无需跳到页面底部即可查找引用。

引用预览自4月以来已在德语和阿拉伯语维基百科上作为测试功能推出。现在，它们将在更多维基上可用。部署计划于10月24日进行。更多信息可以在项目页面上找到。

一如既往，我们非常感谢您的反馈。如果您想测试引用预览，请在您的用户偏好设置中激活测试功能，并告诉我们您的想法。反馈的最佳地点是中央讨论页。我们希望此功能能为您的工作提供良好的帮助。感谢维基媒体德国的技术愿望项目。

-- Johanna Strodt (WMDE) 2019年10月23日 09:47 (UTC)

你好，Johanna，欢迎来到维基导游。我相信在维基导游上，ref标签几乎完全没有使用。可能不需要在这里发送更新给这个项目。(不过，我不知道是否值得改变整个邮件列表...)WhatamIdoing (讨论) 2019年10月23日 17:30 (UTC)

不止如此，它们还违反了本网站的外部链接准则。Ikan Kekek (讨论) 2019年10月23日 17:35 (UTC)

并非所有ref标签的使用都一定涉及外部链接。

目前，我们似乎有47个带有ref标签的页面，但只有少数（例如，另一个）实际显示给读者。这些可能习惯了维基百科链接规则的人，只需要重新格式化。这47个ref标签中的大部分都与气候框有关，并且不会显示给任何人。WhatamIdoing (讨论) 2019年10月24日 17:01 (UTC)

基于应用程序的送货服务、小费以及美国菜文章（如果您是居住在美国境外的维基导游用户，请阅读此内容）

我最近做了第二份工作，担任GrubHub的送货司机，在美国菜文章中，我有一些关于使用像我这样的基于应用程序的送餐服务时的小费惯例的话要说（情况比通常给披萨小哥2-5美元现金要复杂一些）。我还想在小费文章中包含相同的信息，但问题是，我不确定我所说的内容是否适用于全球，或者是否只与美国相关。我猜想在小费习惯与美国非常不同的国家，基于应用程序的送货服务可能会以不同的方式运作。是否有居住在美国境外的维基导游用户有使用这些应用程序的经验，并能确认在他们的祖国给司机小费的程序是什么？如果没有，这些信息是否应该放在小费文章中，即使附带声明它只适用于美国或北美？-- AndreCarrotflower (讨论) 2019年10月26日 14:26 (UTC)

在中国，给小费很少见。我从未见过有人给送货员小费，而且我用的两个送货应用程序似乎都没有添加小费的选项。—Granger (讨论 · 贡献) 2019年10月26日 15:04 (UTC)

据我所知，这些服务在德国还没有真正“流行”起来，很可能是由于监管问题。Lieferando之类的服务确实存在，但它们的运作方式与Uber Eats等不同，因为（据我所知）它们也对餐馆施加价格压力... Hobbitschuster (讨论) 2019年10月26日 17:18 (UTC)

我知道Uber和Lyft的司机更喜欢现金小费。Grubhub的司机也是如此吗？Ikan Kekek (讨论) 2019年10月26日 18:11 (UTC)

虽然在英国基于应用和手机的外卖订购很常见，但我并不是一个经常使用它的人。Just Eat表示只有三分之一的顾客会定期给小费，其给送货员的注意事项也表示他们不能要求小费。AlasdairW (讨论) 2019年10月26日 21:22 (UTC)

这都非常有趣。我不能声称有其他应用程序的第一手经验，但在美国，GrubHub实际上让不给小费变得极其困难。应用程序界面默认小费为20%；任何想拒绝给小费的人不仅必须手动将其更改为零，还要点击一个令人内疚的“您确定吗？”弹出窗口，其中解释了“司机是GrubHub最不可或缺的资产”之类的话。听起来，即使在其他一些国家，送餐应用程序可能提供给司机小费的方式，它们也不太可能如此坚持，所以我添加到美国菜的建议可能不适用于非国家特定的小费文章。

Ikan Kekek - 我想如果你对GrubHub司机进行调查，你可能会听到他们稍微偏爱现金小费，但GrubHub应用程序处理小费的方式与Uber/Lyft不同，这使得它无法进行苹果和橘子的比较。使用Uber和Lyft，小费是在行程结束后才发生（或不发生）；如果潜在乘客的星级评分较低，司机可能会将其解释为可能不是好小费者的信号，但这并非万无一失，而且星级评分可以基于多种因素。使用GrubHub，小费是预先支付的；司机在收到送货订单时会被告知顾客给了多少小费，然后根据该信息决定接受或拒绝订单。应用程序中有一个“备注”部分，顾客可以在其中注明是否打算支付现金小费，但无法保证司机是否会费心阅读，而且司机普遍认为零小费就是零小费，而不是打算支付现金小费的意图。

-- AndreCarrotflower (讨论) 2019年10月27日 05:23 (UTC)

我认为英国的应用程序默认不给小费。一名应用程序的常客抱怨说，该应用程序没有设置首选默认小费的方式，每次都必须手动选择。我们可以针对司机小费提供各国具体建议，并说明司机的薪资情况。在英国，给司机小费可能比给服务员小费更有说服力——服务员是雇员，必须按工作时间支付最低工资，但应用程序的司机通常是“自雇人士”，按每次送货支付薪水。AlasdairW (讨论) 2019年10月27日 13:41 (UTC)

在芬兰，我想司机通常是不会收到小费的（除非在特殊情况下）：他们的薪水很低，没有任何基于雇佣的社会保障，但我认为这不是给小费的理由，而是应该抵制送货服务，除非你找到提供体面雇佣的服务。--LPfi (讨论) 2019年10月28日 20:29 (UTC)

编辑新闻 #2 – 移动编辑和讨论页面

阅读其他语言版本 • 本多语言通讯的订阅列表

在此通讯中，编辑团队讨论了他们在移动可视化编辑器、新讨论页面项目以及维基媒体国际会议2019上的工作。

帮助

您还记得哪些讨论页面互动？是一个关于有人如何帮助您学习新知识的故事吗？是一个关于有人如何帮助您参与某个群体的故事吗？还是其他什么？无论您的故事是什么，我们都想听！

请告诉我们一个您使用讨论页面的故事。请分享一个令人难忘的讨论链接，或在此项目的讨论页面上描述它。团队需要您的例子。这些例子将帮助大家对该项目应支持和鼓励什么形成共同的理解。

讨论页面项目

讨论页咨询是一项全球性咨询，旨在定义更好的维基交流工具。从2019年2月到6月，来自20个维基、15种语言和多个项目的500多名志愿者与基金会成员共同为一套讨论工具创建了产品方向。讨论页咨询第二阶段报告于8月发布。它总结了团队已开始着手的产品方向，您可以在此处阅读更多相关信息：讨论页项目页面。

团队在这个早期阶段需要并希望您的帮助。他们正在开始开发第一个想法。如果您想了解参与机会，请将您的姓名添加到项目页面上的“参与”部分。

移动可视化编辑器

编辑团队正在努力简化移动设备上的编辑操作。团队正在修改移动设备上的可视化编辑器。如果您对移动设备上的编辑有任何看法，请在讨论:移动设备上的可视化编辑器留言。

编辑卡片

点击链接时会发生什么。新的编辑卡片更大，并有更多编辑链接的选项。

• 9月3日，编辑团队发布了版本3的编辑卡片。任何人都可以在移动可视化编辑器中使用新版本。
• 添加和修改链接的编辑卡片有一个更新的设计。还有一个新的、组合的工作流，用于编辑链接的显示文本和目标。
• 反馈：您可以通过在智能手机上打开移动可视化编辑器来尝试新的编辑卡片。请在编辑卡片讨论页上发布您的反馈。

工具栏

移动可视化编辑器中的编辑工具栏正在改变。旧系统有两个不同的工具栏。现在，所有按钮都集中在一起了。告诉团队您对新工具栏的看法。

• 9月，编辑团队更新了移动可视化编辑器的编辑工具栏。任何人都能在移动可视化编辑器中看到这些变化。
  • 一个工具栏：所有编辑工具都位于一个工具栏中。以前，工具栏会随着您点击不同的内容而改变。
  • 新导航：在编辑流程中前进和后退的按钮已更改。
  • 无缝切换：改进的工作流程，用于在可视化和维基文本模式之间切换。
• 反馈：您可以通过在智能手机上打开移动可视化编辑器来尝试更新后的工具栏。请在工具栏反馈讨论页上发布您的反馈。

维基媒体国际大会

编辑团队参加了在瑞典举办的2019年维基媒体国际大会。他们主持了一个关于移动可视化编辑器的会议和一个关于新讨论页项目的会议。他们与贡献者一起测试了移动可视化编辑器中的两个新功能。您可以在团队关于2019年维基媒体国际大会的报告中阅读更多关于团队所做和所学的内容。

展望未来

• 讨论页项目：团队正在考虑第一组提议的更改。团队将与一些社区合作，试行这些更改。了解最新情况的最佳方式是将您的用户名添加到项目页面的列表中：参与其中。
• 测试移动可视化编辑器作为默认设置：编辑团队计划在日历年结束前发布结果。了解最新情况的最佳方式是将项目页面添加到您的监视列表：移动默认可视化编辑器项目页面。
• 衡量编辑卡片的影响：这项研究旨在探讨该项目是否帮助编辑添加了链接和引用。编辑团队希望在11月分享结果。了解最新情况的最佳方式是将项目页面添加到您的监视列表：编辑卡片项目页面。

– PPelberg (WMF) (讨论) & Whatamidoing (WMF) (讨论)

2019年10月29日 11:13 (UTC)

校对远征提议

我认为我们有很多改进空间的一个领域是校对。有些修正（比如我持续与一些人可能已经注意到的不当逗号使用作斗争）可能需要手动完成，但其他的，比如打字错误修正，可能可以借鉴维基百科打字错误团队的自动化和半自动化工具，我认为组织一次远征来研究这方面可能会很好。我们还可以实施WV特有的修正，比如纠正格式不正确的电话号码。我无法承诺让这样的远征保持活跃（我只是没有那么多的空闲时间），但我确实认为设立一个专门的空间，让我们寻找更系统的方法来清理所有可能让WV看起来不专业的微小错误，将是一个好主意。Sdkb (讨论) 2019年10月30日 07:15 (UTC)

如何触达美国最大的市场——女性独自旅行者

https://ux.nearsoft.com/blog/travel/how-to-reach-female-solo-travelers-the-biggest-market-in-the-us/ —贾斯汀 (koavf)❤T☮C☺M☯ 2019年10月30日 18:53 (UTC)

他们似乎采访了七位女性，然后讲述了“FSTs”（女性独自旅行者）的行为，并报告了百分比等等。我是否错过了什么？你不需要大量的随机样本就能获得有趣的观点，但如果你想讲述一个群体整体的想法，一个有代表性的样本会有很大帮助。--LPfi (讨论) 2019年10月30日 20:45 (UTC)

黑客攻击？

我几分钟前收到通知，有人多次尝试从新设备登录我的账户，但均告失败。我建议大家确保密码安全，并且熟悉安全事务的人请以您的方式监控情况。Ikan Kekek (讨论) 2019年11月3日 21:44 (UTC)

我想通过手动猜测密码来破解账户是相当徒劳的尝试，除非他们有一些线索，比如从其他网站获取了密码并尝试其变体（或者使用你的猫和女朋友的名字，并进行变体，如果你使用这种密码的话）。如果你认为存在这种风险，你可能需要更改密码。

真正的风险，也是促使人们设置好密码的原因，是有人可能找到一种方法，在自己的机器上尝试密码，或者绕过服务器的每分钟尝试次数限制。然后他们可能会尝试数十亿种变体，在前一种情况下，你直到他们用正确的密码登录时才知道。

--LPfi (讨论) 2019年11月4日 14:57 (UTC)

维基导游有两步验证吗？我知道维基百科有，但目前只对管理员开放。Sdkb (讨论) 2019年11月4日 18:26 (UTC)

我相信“两步验证”对任何WMF托管项目上的管理员都可用。此外，如果有人确实需要，非管理员也有几种解决方法。WhatamIdoing (讨论) 2019年11月5日 03:03 (UTC)

我不太担心有人破解我的密码，但我认为提醒大家有人正在尝试是件好事。Ikan Kekek (讨论) 2019年11月8日 20:51 (UTC)

维基导游维护项目的想法

如大家所见，维基导游的信息有时难以保持最新。维基导游之间的互动必须有助于维持这些更新。这是我的一个帮助想法。这可以适用于任何方向（理解为维基导游的语言版本）。以下是应用程序将提供的内容：

1. 应用程序在英语维基导游中搜索包含某个更新日期早于特定日期或从未更新的列表的页面。
2. 应用程序将name、alt和lastedit参数“保存”为“备注”。
3. 应用程序在其他语言版本（通过维基数据进行跨维基链接）中搜索一个“列表”，其名称或替代文本与之前的一个元素最接近，并且其最后编辑时间最好晚于我们的。最糟糕的情况下，它会在包含该元素的某个部分中搜索文本。
4. 应用程序显示该版本列表的发布者以及其他所有语言版本的元素（列表或章节）的源代码。
5. 我们根据比较后的阅读更新元素并保存。

以上就是我们可以用应用程序完成的工作总结。您觉得呢？是的，我们有想法，但要实现它们，却缺少人手。但这个想法是有一个结构良好的项目，并提交给“程序员”进行推进。Crochet.david (讨论) 2019年11月11日 11:18 (UTC)

能够在另一种语言中比较类似的列表听起来很有趣。必须是交互式比较，并且用户能够选择要传输的内容。也许类似于列表编辑器中的“同步到维基数据”选项。另外，与其在页面上交互式运行（这很可能经常不会给出任何有用的结果），不如批量运行整个站点，并用一个标签（和类别）标记任何候选列表，该标签只有在“错误高亮”小工具激活时才可见（类似于我们处理死链接{{死链接}}）。--Traveler100 (讨论) 2019年11月11日 18:21 (UTC)

我们确实需要一些东西，这必须涉及自动翻译，因为这项任务比更新列表要大得多。有些主要目的地在某些常用语言中几乎只是一系列标题。看看活跃贡献者的数量：在过去一小时内，英语WV有52次更新，德语有15次，俄语有12次，法语有12次。西班牙语一整天只有11次，希伯来语19次，普通话31次。人工编辑根本无法跟上。然而，我们需要停下来思考WV乃至整个WMF能否保持当前的多种语言版本模式。更好的翻译和5G传输的结合预示着未来单一版本模型，可以实时翻译成任何已知语言；并且反过来用于贡献。我们认为这很快就会发生，还是遥遥无期？Grahamsands (讨论) 2019年11月11日 23:42 (UTC)

例如，德语维基导游已经领先于这场讨论。他们将一些信息移至维基数据，因此基本信息可以轻松地在语言版本之间自动共享。描述显然需要翻译（或保留为每个WV语言版本私有），但与电子邮件、电话号码等相比，这部分通常变化不大。例如 - 哈雷（萨勒）的Bergschänke酒店 / Q42298625 -- andree.sk(讨论) 2019年11月12日 07:28 (UTC)

届时我们仍然需要人工翻译，因为电脑翻译仍然很生硬。有些习语和其他表达方式极难翻译，甚至在其他语言中可能没有等效词。我的日语远未达到流利程度，但即使在我的水平上，我仍然能够发现并纠正Google翻译的一些错误，因此，在WV不同语言版本之间实现自动化翻译还有很长的路要走。The dog2 (讨论) 2019年11月13日 05:29 (UTC)

同意。作为一个多语言者和翻译者，在我看来机器翻译是不可行的。这项技术还有很长很长的路要走，才能使机器翻译程序在一致的基础上正确处理基本的语法规则，更不用说捕捉人类语言中包含的所有微妙细微差别、丰富多彩的习语和比喻了。-- AndreCarrotflower (讨论) 2019年11月13日 14:59 (UTC)

我认为我们可以同意，列表的定性信息（即“内容”字段中的书面描述，以及适用的“方向”字段）在可预见的未来仍需要人工翻译。我认为值得探讨的是，正如Andree (SK)所建议的德国人正在做的，我们能否使“定量”信息（即地址、电话号码、网站、价格等）在维基导游的不同语言版本之间更容易自动共享。我们已经使用维基数据快速共享POI的经纬度（尽管由于我们与维基数据或我们与百科全书之间的优先级差异，结果参差不齐），因此值得考虑我们还可以自动化哪些内容，以提高我们有限的人力效率。

另外，仅仅是受到Andre (NY)第一句话的启发，我想庆祝一下，与英语维基百科这个拥有更大编辑群体的项目相比，我们拥有的社区绝大多数是多语言的。--ThunderingTyphoons! (讨论) 2019年11月13日 15:53 (UTC)

TedX：如何应对过度旅游

一个简短的讲座，关于布拉格与游客相关的问题和解决方案。与负责任的旅行和常见骗局有关。/Yvwv (讨论) 2019年10月24日 17:40 (UTC)

我应该早点看这个的！多么精彩的短讲，他有一些有趣的想法！

它提出的问题是，WV对于他的#honestlamp这类事情应该采取什么政策。他所做的类似于我们写“欣赏可爱的锻铁雕像，一定要摸摸它右边的灯，以求好运和财富。”现在我们这样写可以吗，即使这是一种现代“传统”，人们才做了不到一年？既然WV不是WP，我们的语调也不同，那么我们肯定可以不说“以前有在艺术品上挂锁的传统，但现在取而代之的是……”。WV甚至可以像他那样，通过自己创造一个全新的传统，例如#honestlamp，作为积极变革的力量吗？--Bigpeteb (讨论) 2019年11月6日 17:34 (UTC)

我理解想要高瞻远瞩并产生积极变化，我真的理解。但是，过度旅游问题的本质，甚至是它是否是个问题，都是一个有争议的话题，双方都有确凿的论据。在这种情况下，当正确答案不明显，并且采取立场可能会在我们的读者甚至编辑中引起某些派系的不满时，我们应该保持中立，就像我们在有争议的政治纠纷中那样。我们的工作是向人们提供信息，而不是告诉他们如何使用这些信息。-- AndreCarrotflower (讨论) 2019年11月6日 17:39 (UTC)

过度旅游的两面性是什么？我好像从未听到过任何支持它的论点（无论是否有说服力）。WhatamIdoing (讨论) 2019年11月7日 19:01 (UTC)

到底多少旅游才算“太多”？最近在德国基督教民主联盟（CDU，德国中右翼“天然执政党”）党代会上，可以听到“过度旅游的支持论调”，有人说“我们是那些飞往马略卡岛的人的党”，结果与会者“自发地”唱起了关于在马略卡岛喝醉的歌Hobbitschuster (讨论) 2019年11月7日 22:13 (UTC)

过度旅游意味着有太多人到访，导致交通堵塞，难以参观你感兴趣的景点，当地人无力承担生活费用，景点意外损坏（例如，太多人攀爬历史石阶=没有更多石阶）等等。我怀疑“飞往马略卡岛的人的党”不希望马略卡岛出现这些问题，如果大多数人停止前往马略卡岛，他们可能会对结果感到满意。

“多少才算太多？”部分是主观感受的问题（任何提高*我*租金的旅游量都是问题；提高*你*租金的旅游量则没问题），但有些情况无人真正争议（例如，麦加朝圣期间的安全和一些脆弱的生态系统）。WhatamIdoing (讨论) 2019年11月7日 23:33 (UTC)

在一些旅游主题和目的地文章中我们讨论了这个问题，在其他文章中我们也有所暗示。例如，在欧洲，我们反对从一个标志性景点匆匆赶到下一个，我们有可持续旅行和无痕露营。我们应该告诉人们不要触摸雕像。将一个至今不存在的仪式描述为真实的仪式就太过分了，但我们可以将替代方案描述为“不如……”（无论是对于雕像还是排队看蒙娜丽莎）。我认为这大部分都是没有争议的。

然后我们有两个真正的问题：我们确实强调“热门景点”，无论一个较少人参观的景点是否同样好——而且我们参与营销“最后一个未受破坏的天堂”。我们在这方面做了一些好事，还可以做更多，但没有完美的解决方案。

--LPfi (讨论) 2019年11月8日 09:15 (UTC)

Wikivoyage 可以推广最热门景点附近被低估和未充分开发的旅游目的地。像威尼斯都会区这样的文章可以大大扩展，超越威尼斯本身。/Yvwv (讨论) 2019年11月8日 10:50 (UTC)

附近还有一些城市，比如帕多瓦，许多人为了省钱而选择住在那里，然后白天到威尼斯游览。它们也有值得一去的景点。我对威尼斯指南的观察是，还有很多景点可以列出来，我只是看了维基共享资源用户Moroder等人的大量照片才知道的。最好能在这个网站上对威尼斯进行区域划分，这将有助于推广圣马可等核心旅游景点以外的区域。我本人从未去过威尼斯，所以我不会牵头这项工作，但我认为这将是理想的方案。现在，至于在一个给定城市不说明什么是热门景点，如果游客时间有限，不知道锡耶纳的热门景点是什么，那会很不方便；许多热门景点之所以热门是有原因的。如果你喜欢艺术博物馆并去巴黎，如果你的旅行中不去卢浮宫至少一两次，那你就错了；你不会想错过在佛罗伦萨看大教堂，或者从奥尔特拉诺一侧的观景点欣赏景色；等等。其他主要的旅游景点是旅游陷阱，但你可能还是想去看看一次。我会把时代广场和好莱坞星光大道归为这一类。旅游指南的存在不是为了劝阻旅行，所以虽然我们应该以公平和有益的角度来介绍一切，但如果我们不记住人们为什么旅行以及他们旅行的目的，我们就可以考虑放弃，告诉人们旅行对环境有害，他们应该在家寻找美好的事情去做，而不是去旅行。Ikan Kekek (讨论) 2019年11月8日 21:01 (UTC)

没错。但是，仅仅为了能在清单上划掉蒙娜丽莎而排队参观卢浮宫，这不是我所推荐的。我所想的是尝试降低所有“勾选清单”的心态，但我真的不知道如何明智地做到这一点，除了通过寻找并突出那些替代景点/目的地（这通常需要一些当地知识或大量的努力）——LPfi (讨论) 2019年11月8日 21:33 (UTC)

但是，有许多旅行者非常乐意在他们的世界最著名和最受欢迎的景点清单上打勾；他们喜欢时代广场、迪士尼乐园等俗气旅游陷阱。我们不必理解或同意这种方式——我当然不理解——但Wikivoyage也为这些人服务。-- AndreCarrotflower (讨论) 2019年11月8日 22:25 (UTC)

我认为我们有责任提及一个目的地的主要景点，无论我们是否真的推荐它们。但根据anr，我们可以列出著名的景点，同时仍然温和地建议人们不要去看它们——例如，我们对卢浮宫的介绍可以这样说：“为了一瞥远处的蒙娜丽莎而排长队是不值得的——参观博物馆里其他不那么拥挤但同样美丽的区域会更有收获。” —Granger (讨论 · 贡献) 2019年11月8日 23:33 (UTC)

我们可以做的另一个例子：丹霞山最受欢迎的景点是一块巨大的阴茎形岩石，我发现它不如公园其他地方有趣的岩石地貌和全景。在撰写文章时，我列出了这块著名的岩石并指出了它的重要性，但我淡化了它的重要性，并建议花时间探索公园的其他部分。—Granger (讨论 · 贡献) 2019年11月8日 23:47 (UTC)

[编辑冲突：]我不会支持这种措辞。我会这样措辞：“《蒙娜丽莎》是一幅著名而伟大的画作。不幸的是，如今这幅作品周围排队很长，人潮拥挤。因此，请考虑一下，与其排队等待一段时间才能在人群中瞥见这幅画，不如利用你的时间去欣赏这个极其丰富的博物馆中许多其他同样伟大的艺术品，这会不会是更好的选择？” 顺便说一句，我认为《蒙娜丽莎》是一幅伟大的画作是毋庸置疑的。我觉得它被高估了，与我在卢浮宫看到的其他一些真正伟大的画作相比，但我的父亲，他本身也是一位画家，不同意我的看法。有些景点之所以被炒作是有原因的。Ikan Kekek (讨论) 2019年11月8日 23:51 (UTC)

当然，这可行。我的重点不是具体的措辞（我只是用蒙娜丽莎作为例子，因为它前面提到过），而是我们能够而且应该说些什么，如果一个著名景点过度拥挤、被高估或不值得麻烦的话。—Granger (讨论 · 贡献) 2019年11月9日 00:07 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 在马德里的普拉多博物馆展出了一幅由达芬奇工作室的某人（或几人）绘制的同一位女性的肖像画。这幅画在那里大部分被忽视。Hobbitschuster (讨论) 2019年11月9日 00:22 (UTC)

我认为对我们来说，最好的办法就是诚实。如果这是一个俗气的旅游陷阱，我们就应该这样说明，但人们是否决定去那个目的地，这不是由我们决定的。但我们也可以为那些想避开人群的人提供建议。例如，如果你想避开西班牙阿尔罕布拉宫的人群，一个好的建议是在冬天去，那是西班牙旅游淡季。我实际上很喜欢在冬天参观西班牙的旅游景点，那时人不多。缺点是餐馆里会说英语的服务员较少，所以如果你不会说西班牙语，你需要发挥创造力。The dog2 (讨论) 2019年11月9日 00:35 (UTC)

或者就自学一些应急西班牙语。它与英语有足够的重叠，对很多人来说学习基础并不难。Ikan Kekek (讨论) 2019年11月9日 00:42 (UTC)

我们的美国Alexa排名暴跌

出于某种对我来说尚不清楚的原因（不可能是单纯的季节性变化），我们在美国的Alexa排名比一架加装了MCAS的737 max坠落得还要厉害。这似乎还没有造成实际后果，但我们应该在为时已晚之前找出原因。Hobbitschuster (讨论) 2019年11月19日 23:38 (UTC)

不幸的是，这一观察属实。其原因就像大约两年前的跃升一样无法解释。暴跌始于大约三个月前（参见此处），至今尚未停止，并伴随着美国访客数量从约15%下降到10%。印度和德国的数值更稳定。一年内常见的临时变化也无法解释这种行为。也许维基旅行可以提高其在美国的排名。不幸的是，维基导游的知名度仍然很低。大部分流量来自搜索引擎和维基百科，而不是直接访问或其他网站。社交媒体也帮不上忙，因为使用率低。提高维基导游的可见度肯定会有帮助，但我不知道该怎么做。--RolandUnger (讨论) 2019年11月20日 06:28 (UTC)

最好能将其与其他网站排名网站（如 SimilarWeb）进行比较，看看这是一种普遍趋势，还是只发生在 Alexa 上（如果是后者，则 Alexa 衡量美国网站受欢迎程度的方式可能已发生变化）。德国维基导游显示了 Seitwert 排名，尽管我不太明白。正如您所说，维基导游的整体知名度仍然很低。许多从搜索或维基百科来到这里的人，并没有留下足够深刻的印象，以至于他们能记住这个网站并从那时起直接访问或在社交媒体上关注我们。除了分支之外，我们也很少获得主流媒体报道。我能想到的唯一一件事就是在文章底部放置“分享”按钮，这样当读者读完一篇文章并认为值得分享时，他们可以通过电子邮件或社交媒体平台分享。Gizza ^(漫游) 2019年11月20日 08:57 (UTC)

是的，理论上我们应该启用分享功能，但这有一个问题，那就是将我们与像Twitter和Facebook这样的网站联系起来可能会引起争议，这些网站在世界政治中扮演了非常可疑的角色，可以说。Ikan Kekek (讨论) 2019年11月20日 09:22 (UTC)

旅游网站的流量通常在北半球秋季下降。维基导游全球 Alexa 排名的下降并不比往年更糟。此外，另一个网站不再是相关的竞争对手。/Yvwv (讨论) 2019年11月20日 09:52 (UTC)

我支持探索分享按钮的想法，但认为政治问题是误导。无论好坏，数十亿人使用 Twitter 和 Facebook，我们的内容在这些平台上分享以触达更多人应该被视为一件好事。

关于 Wikitravel 的数据怎么说？我们能否就这样把它排除为“不再是相关的竞争对手”？--ThunderingTyphoons! (讨论) 2019年11月20日 10:38 (UTC)

我说的不是我们的全球排名。我们的美国排名出现了剧烈的短期波动，这在其他网站（事实上，我们在美国已经落后于它）或两个网站的全球排名中都没有反映出来……这是否与谷歌尝试涉足旅行指南有关？Hobbitschuster (讨论) 2019年11月20日 10:53 (UTC)

根据 Roland 链接的数据，最近美国排名不止一次下跌；8月初到9月中旬，从8,886跌至18,911（序数词翻了一倍多），然后排名略有回升，10月升至13,799，然后跌至28,458（序数词再次翻了一倍多）。这真的正常吗？--Ypsilon (讨论) 2019年11月20日 11:53 (UTC)

大家好，我作为一名曾与搜索团队合作并关心维基导游的工作人员来插一句话。:) wikivoyage.org（门户）的流量可能减少了，但实际的语言版本没有。在我看来，这没那么令人担忧。这里是英文维基导游的统计数据，显示自2019年初以来，页面浏览量有所增加！而且来自美国的英文维基导游流量占据了绝大多数流量。这一点也一直保持一致。这并不是说我们不应该关注和担忧，而是为了提供一点情境上的缓解（我希望！）。

也可能是 Google 正在做一些不同的事情，它占据了95%以上的流量（因此极大地影响了 Alexa 排名）。CKoerner (WMF) (讨论) 2019年11月20日 17:35 (UTC)

这里提出另一个想法：维基媒体基金会是否应该购买Google 搜索广告？它们甚至可以针对“wikitravel”的搜索，以便人们可以被教育并重定向到我们。WT 在质量方面可能不是一个相关的竞争对手，但它们在流量方面仍然是一个非常大的竞争对手：对于许多搜索词，他们的文章排名都高于我们，导致许多普通读者在那里进行编辑。通过将自己呈现给普通读者为旅行维基百科，他们也劫持并持续损害我们的声誉。Sdkb (讨论) 2019年11月26日 20:11 (UTC)

这是一个非盈利网站。Ikan Kekek (讨论) 2019年11月27日 05:12 (UTC)

我们确实不打广告。维基导游可以也已经宣传和提高自身知名度的地方是其他维基媒体网站。编辑马拉松（庆祝我们成立5周年）取得了适度的成功。许多人首次访问该网站，一些新编辑者在不同程度上留了下来。就任意统计里程碑而言，我们很快就要达到30,000篇文章了。也许我们应该要求维基媒体基金会在页面顶部放置一个框，突出显示这一点，并包含一个链接，将人们引导到主页。虽然让人们编辑很好，但能让人们阅读我们最好的内容会更棒。Gizza ^(漫游) 2019年11月27日 10:02 (UTC)

广告和盈利/非盈利组织有很大的区别。我很想看看维基媒体关于网站推广的指导方针，有人能指点我们正确的方向吗？--Traveler100 (讨论) 2019年11月27日 17:28 (UTC)

我相当同意Traveler100的观点。我们不应该，也不允许在Wikivoyage上投放广告，但这与Wikivoyage的广告不同吗？我认为这是一个从未被提出的问题，因此没有答案：维基百科显然拥有足够的知名度，不需要任何广告，这个问题也从未在任何较小的WMF维基中出现过，但这并不意味着我们知道WMF会如何回应这样的想法。-- AndreCarrotflower (讨论) 2019年11月27日 17:53 (UTC)

谷歌过去会向非营利组织捐赠少量免费广告，但我不确定（a）他们是否仍然这样做，或者（b）我们是否符合条件。（我猜他们可能仍有这个项目，但我们不符合条件。）WhatamIdoing (讨论) 2019年11月27日 18:11 (UTC)

我，也许是错误的，将Ikan的评论解读为更少关注我们作为非营利组织应该做什么，更多关注我们现实中能做什么。维基媒体基金会是一个慈善机构，显然慈善机构会做广告。但是，在 YouTube 上投放针对旅游视频的广告，例如，需要多少钱？像Sdkb上面建议的那样，购买 Google 搜索广告需要多少钱？我原则上喜欢在维基媒体之外投放广告的想法，但我担心这是否实际。如果我们向维基媒体基金会提出这个想法，他们会问的第一个问题是“这要花多少钱？” --ThunderingTyphoons! (讨论) 2019年11月27日 18:21 (UTC)

只要我们与维基媒体基金会达成一致，并且广告活动显示出一些潜力，我就会支持这个想法。--评论者 Selfie City (讨论 | 贡献) 2019年11月27日 18:46 (UTC)

• 另外，虽然我知道一个人不太可能显著改变网站排名，但我曾有一段时间在这里非常活跃，有时几天内就进行了数千次编辑。自从我在维基导游上不那么活跃，尤其是在过去几个月里，排名明显下降了。这之间是否存在联系？或者说，一个用户不足以影响美国排名哪怕一千左右吗？--评论者 Selfie City (讨论 | 贡献) 2019年11月27日 18:53 (UTC)

回到谷歌广告的建议：既然维基媒体基金会不能从该网站的 Alexa 排名提升中获利，那么花钱为它做广告有什么好理由呢？慈善机构之所以做广告，是因为他们需要钱来帮助穷人、灾区、政治事业、艺术组织等。我想维基媒体基金会需要钱来维护服务器、支付员工工资等，所以如果他们认为广告划算，他们可能已经这样做了。但我认为在谷歌上做广告以提高维基媒体网站的知名度不太可能划算。Ikan Kekek (讨论) 2019年11月27日 19:21 (UTC)

它的目的不是为了赚钱，即财务贡献，而是为了鼓励新读者访问网站，并希望有更多贡献者。--Traveler100 (讨论) 2019年11月27日 19:35 (UTC)

至于费用，您决定每日预算，每次点击收费在 1 到 2 美元之间。所以基本上，每位新读者大约需要 2 美元，但显然无法保证他们会留下来。--Traveler100 (讨论) 2019年11月27日 19:43 (UTC)

当然，如果维基媒体基金会愿意花钱，却没有任何回报的话。你觉得他们会吗，考虑到他们一直在为维基百科寻求捐款？我认为不会。我甚至不会考虑向他们提出这个建议。Ikan Kekek (讨论) 2019年11月27日 19:53 (UTC)

他们的目标不是赚钱，因此这项事业不会产生利润这一点并不重要。重要的是这项事业的潜在回报（吸引更多读者，其中一部分人将成为贡献者——这应该是基金会共同的目标）是否足以抵消成本。如果他们不为各种方式改善维基百科而筹款，例如雇佣全职员工、开发软件改进，或者在这种情况下增加流量，那么他们筹款的目的是什么？我仍然认为这可能相当昂贵，当然也不认为获得批准的可能性很高，但值得探索，可能与其他较小的姊妹维基一起。我也感谢Traveler100的简要解释。ThunderingTyphoons! (讨论) 2019年11月27日 21:48 (UTC)

在过去的半年左右，Alexa 提供了更多信息。例如，根据受众重叠和链接网站相似的网站。很明显，维基导游在链接网站方面远远落后，除了其中一个网站是维基百科（92%的流量来自字典和百科全书，其中维基百科当然是首位）。Elgaard (讨论) 2019年12月4日 16:55 (UTC)

如果你查看维基导游与WT的谷歌趋势比较（），你会发现除了委内瑞拉，WT在所有地方都是一个更受欢迎的搜索词。有些国家被灰化了，但似乎WT在超过100个国家都胜过维基导游。我们受益于维基百科对我们的链接，但除此之外，我仍然觉得维基导游在许多方面落后于旧网站。Gizza ^(漫游) 2019年12月11日 23:27 (UTC)

事实上，从5年趋势来看，我们对他们取得了进展。在2014年，WT的搜索量是我们的20倍，现在只有我们的8倍。这部分可以归因于WT的下降，而不是我们变得更出名了。当你将Wikivoyage与Lonely Planet进行比较时，2014年LP的搜索量是WV的30倍，而现在是20倍。所以可以说取得了适度但并非实质性的进展。Gizza ^(漫游) 2019年12月11日 23:33 (UTC)

关于维基旅行与维基导游：可能与 Alexa 排名没有完全相关，但今年早些时候我旅行秘鲁、玻利维亚和智利时，我开始使用维基导游，但后来切换到维基旅行，因为他们的覆盖范围更及时、更广（即他们包含了维基导游没有提及的城镇）。我相信这有其原因，但我目前正在东南亚旅行，不准备深入讨论（无论如何，这将是一个单独的主题/帖子/部分）。我将在几个月（或更久，或任何时候）回家后开始一个新的讨论。可能与谷歌搜索结果相关（我不知道这些如何影响 Alexa）。现实是维基导游应该远远超过其他网站，例如 TripAdvisor 在谷歌搜索中不断出现，但我每次查看它都发现它没什么用，他们宣传的“旅行团”完全是个笑话。PsamatheM (讨论) 2020年1月2日 15:50 (UTC)

感谢你的更新，@PsamatheM:。你还记得维基导游覆盖薄弱或缺失的城镇名称吗？我们应该把弥补这些空白作为优先事项。Gizza ^(漫游) 2020年1月8日 05:05 (UTC)

@DaGizza: 我目前正在旅行，网络“不稳定”，而且只有一台平板电脑。所以目前只能简要（且未经证实地）回复。据我回忆，例如，我在特鲁希略（秘鲁）走了很多路，流了很多汗（非常热），因为那里的公交信息灾难性地错误（相关公交公司有自己的售票处，不在中央车站，所以只能不停地走）。当我访问豪哈（秘鲁）时，维基导游当时没有任何页面（豪哈是一个非常棒的地方，有巨大的图南马卡遗址，皮奇利利峡谷等）。但即使现在，与维基旅行提供的信息相比，维基导游的页面也相当糟糕。不准确的信息会给旅行者带来麻烦，这肯定会迅速将人们赶出网站。我一到秘鲁就放弃了更新维基导游，当时我发布了一个很棒的旅游（我自己去过，免费）的列表，结果“政策警察”蜂拥而至将其删除，随后进行了无休止的讨论以试图达成共识，我相信该列表后来恢复了，但“人生苦短”，对于一个列表来说，这简直是闹剧。我其实非常坚信维基百科、维基导游等项目，但我认为维基导游需要显著重新考虑其态度的一些方面。我正在准备我的想法，但我不会在回家之前发表它们，因为那时我才能充分参与它们可能引发的任何讨论（当然，它们也可能什么都引发不了）。PsamatheM (讨论) 2020年1月9日 07:44 (UTC)

@PsamatheM: 我同意对新手甚至一些资深编辑存在过度挑剔，以及对许多政策的盲目遵守，这些政策从长远来看并不一定能改善维基导游。我们确实需要从维基百科借鉴的一项政策是：“如果一个规则阻碍你改进或维护维基百科（或者我们这里是维基导游），请忽略它。”参见wikipedia:Wikipedia:忽略所有规则。很多时候，编辑被直接回退，甚至没有编辑摘要中的解释，更没有给善意编辑者的个人消息，这会让他们感觉被跟踪，不受欢迎。 Gizza ^(漫游) 2020年1月10日 01:03 (UTC)

我有很多想法可以改进 Wikivoyage，这些想法会与 Wikivoyage 的风格手册大相径庭，但这只是我的个人意见，而不是网站的集体意见。我的问题是：维基百科是如何通过其“忽略规则”的政策来阻止人们肆意破坏其指导方针的？Ikan Kekek (讨论) 2020年1月10日 03:26 (UTC)

除了（a）明显的破坏，或（b）重复推销，不加解释地回退编辑是完全无知的。同时，允许人们无视规则将导致编辑战，一方想按一种方式做，另一方认为另一种方式更好。规则解决了这些争议，避免了浪费时间的编辑战。最终，任何加入协作项目的人都必须明白他们的工作将被其他用户编辑和修改。让新手认为他们的贡献是完美的，不会被其他人修改，对他们没有帮助。同时，不对新手吹毛求疵是一项非常重要的做法，我确信我过去也曾有过这种行为。当有经验的编辑对新手过于严厉时，其他老编辑指出这一点很重要。Ground Zero (讨论) 2020年1月10日 04:03 (UTC)

@PsamatheM: 我已经大幅扩充了豪哈的文章，内容改编自维基百科文章。您能否根据您在那里的经验，对我的贡献进行查看并进行添加/删除/改进？在您的帮助下，并有选择地借鉴维基百科，我们可能会得到一篇不错的文章，谢谢。Ground Zero (讨论) 2020年1月10日 04:39 (UTC)

@Ground Zero: 两个方面。

1. 我不是在批评那篇文章，而是将其作为维基旅行有很好的覆盖范围，但（当时）维基导游根本没有页面提及的例子。（这也是当时我放弃使用维基导游作为旅行秘鲁、玻利维亚和智利信息来源的原因之一。

2. 我只有平板电脑、手机和可变互联网，在我回来之前（可能要几个月），我无法撰写文章。可能违反了规定，但请特别参阅我网站上的帖子：https://psamathe.net/tag/jauja/。图纳马卡是一个非常重要的地点。皮奇卢利峡谷令人惊叹。没有旅行团，因此关于例如WV的信息变得更加有用。两者都离城镇很近，可以作为城镇文章的一部分。旧村本身不足以游览，但在你步行到皮奇卢利峡谷的路上经过它还是值得的（但你需要GPS坐标，因为没有“行进路线”，只有一个好的起点和当地农民和牧羊人使用的路径网络）。

所以目前（由于我目前的“旅途中”状态），我只能把文章的工作交还给您（或其他人）。您可以随意从我的个人网站获取任何信息/文本，您有我的许可可以获取任何照片（可以直接上传到WV或上传到共享资源（但请注明来源为psamathe.net - 尽管这些照片我迟早也会上传，而且我会从原始文件中导出，所以质量/分辨率会更好（但更多是关于信息而不是照片的完美度）。如果您需要任何详细信息或信息，请告诉我（但我没有原始文件在身边）。很抱歉如果我看起来懒惰，没有自己完成工作，但如果您/某人能完成大部分工作，我怀疑我没有太多需要调整的。PsamatheM (talk) 2020年1月10日05:13（UTC）

@Ground Zero: 除上述内容外，乘巴士抵达的信息在页面底部 https://psamathe.net/jauja-southern-sierra/ PsamatheM (talk) 2020年1月10日05:29（UTC）

别担心，在讨论帖中链接你的博客没问题！祝你旅途愉快！ Ikan Kekek (talk) 2020年1月10日05:50（UTC）

我从你的精彩博客中添加了很多内容，还有另一家酒店，但我应该停止拖延，开始计划即将到来的旅行。Ground Zero (talk) 2020年1月10日13:49（UTC）

Ikan Kekek，如今英文维基百科主要通过敷衍了事然后严格执行“规则”来解决“忽略所有规则”的问题，这与政策相悖。当它出现时，通常会有一段对话。在其最佳形式下，这与我们如何决定不受监管的事情没有区别，比如一家特定的餐厅/酒吧组合业务应该列在==餐饮==还是==饮品==下。WhatamIdoing (talk) 2020年1月11日22:13（UTC）

谢谢你的解释，WhatamIdoing。所以我不太确定制定一个类似的政策是否会在这里产生任何改变，除了引起混淆。你同意吗，或者你认为它会以某种方式有用吗？Ikan Kekek (talk) 2020年1月11日23:19（UTC）

我猜它有可能将“我们真的可以阻止这个人吗，即使技术上在阻止政策中没有明显的类别？”的讨论从每年两次减少到一次，这可能是一个小小的胜利。WhatamIdoing (talk) 2020年1月12日04:07（UTC）

我不太明白。Ikan Kekek (talk) 2020年1月12日05:08（UTC）

通过将关于是否可以屏蔽用户的冗长讨论替换为“我决定‘忽略所有规则’并屏蔽那个人”的声明。它不会全部阻止，但可能会阻止一部分。WhatamIdoing (talk) 2020年1月13日16:55（UTC）

这更像是一种价值观或原则，而不是政策。再多想一下，WV:旅行者至上涵盖了类似的内容，所以这里可能不需要它。Gizza ^(漫游) 2020年1月14日08:36（UTC）

@PsamatheM: - 我感同身受。我在柏林列出了一次旅行时也发生了同样的事情。我们很乐意列出酒店和其他商家，没有任何顾虑，但不知何故，旅行团是禁止的。我们的政策不一致，这非常令人沮丧。随便拿起一本人们花钱买的旅行指南。你会发现，如果酒店、旅行团和其他商家对旅行者有帮助，它们就会被列出。我们似乎做出了某种不一致的纯洁承诺，这损害了本项目基本目标。Marvin The Paranoid (talk) 2020年1月26日15:44（UTC）

PsamatheM提到的秘鲁徒步旅行引发了一场讨论，导致了全站范围内的徒步旅行例外。因此，尽管PsamatheM的经历可能令人沮丧，但实际上促成了一项假定为永久性的政策变化（指南在一年前进行了更改，并未造成任何干扰，因此尽管并非所有人都同意，但它们似乎不太可能被撤销）。

但当你声称旅游政策“损害了本项目的基本目标”时，这是其中一个目标

旅游团可以在Wikivoyage上列出，只要它们构成增值活动。 如果旅行者可以自行完成旅游的实质内容，则不应列出该旅游团。

如果还不清楚本网站是面向独立旅行者的，那么链接部分的结尾是

实际上，这项政策不允许列出大多数语音导览和导游，因为此类导览的实质内容通常可以由独立旅行者完成，而且此类导览提供的信息理想情况下应该包含在相应的Wikivoyage文章中。

这方面的另一个部分是您不会记得的事情，因为它发生在很久以前，但当我们允许旅游链接时，像佛罗伦萨这样的文章绝对充满了垃圾旅游链接和列表。本网站的共识迄今为止都认为，我们指南的目的是让独立旅行者能够访问我们所涵盖的目的地。任何宁愿参加旅行团的人可能都不需要本网站，也不会难以找到此类旅行团。此外，我们根本缺乏阅读量和专业知识，无法尝试我们以前对这些列表所做的事情，即判断哪些旅行团是好的，哪些是纯粹的吸金陷阱。

也就是说，准则和政策的例外总是可能的（当然，法律要求除外），但必须在相关文章的讨论页面上进行论证。如果您想更改整个网站的旅行列表政策，您随时可以在Wikivoyage talk:Listings上发起一个讨论，看看您是否能说服达成共识以同意您的提议。无论结果如何，总会有人不高兴，这就是现实，也是为什么有这么多不同网站的原因——这是一个全球性的网络。Ikan Kekek (talk) 2020年1月26日16:12（UTC）

谢谢您的解释和历史。很高兴知道这方面取得了进展。我的编辑是在我刚接触WV时完成的，当时我没有意识到可以通过讨论来支持我的论点。--Marvin The Paranoid (talk) 2020年1月26日16:39（UTC）

我们应该把这一点说得更清楚。我正在考虑在哪里以及如何更清楚地说明所有非法律要求的政策和准则都可能根据具体情况，如果一个令人信服的论点导致特定文章讨论页面上的共识，则可以例外。我们一直都是这样运作的，但也可能会有人反对这种具体情况的例外。Ikan Kekek (talk) 2020年1月26日16:44（UTC）

我想说的是，在Wikivoyage:旅行者至上上再加一个要点，内容大概是：“如果执行某项政策会损害旅行者的利益，社区可以达成共识，在特定情况下不适用该政策。”Powers ^(talk) 2020年1月26日18:49（UTC）

措辞很好，不过讨论机制应该阐明，也许吧。我们将在Wikivoyage talk:The traveller comes first讨论此事。我马上就开贴。Ikan Kekek (talk) 2020年1月26日18:55（UTC）

Ikan Kekek 有组织旅游的一个大问题是它们的使用方式。去年在秘鲁完全独立旅行时，我在北部沿海地区多次参加有组织旅游，因为没有公共交通，出租车比旅游团贵得多（独立旅行者可以乘巴士到一个城镇，也许再乘出租车，可能需要过夜，但当有组织旅游可以提供更便宜、更方便的交通时，这一切都显得荒谬）。旅游小巴会到达景点，我会问司机或导游他们什么时候返回，然后说“到时见”，然后我就自己走了——用他们作为交通工具，但这确实是有组织旅游。在上面提到的“徒步旅行”的烦恼之后，我已经放弃了向WV添加任何内容，但如果我列出一个有组织旅游，理由是它作为交通工具比其他选择便宜得多，我能摆脱麻烦吗？或者这会引起另一次冗长的讨论……PsamatheM (talk) 2020年1月26日16:52（UTC）

当然，在此基础上。在各种文章中都有将旅游巴士列为交通工具的例子。很抱歉，在您发布的一项列表导致政策变更后，您放弃了向Wikivoyage添加内容；您还能要求多少响应呢？Ikan Kekek (talk) 2020年1月26日17:54（UTC）

这是关于制定规则例外的讨论帖：Wikivoyage talk:The traveller comes first#Exceptions to rules。请查看并评论措辞，以便我们能就措辞形式达成一致。Ikan Kekek (talk) 2020年1月26日19:13（UTC）

Ikan Kekek我停止打扰的原因是，我发布了一个有用且有效的列表，对许多独立旅行者都很有用——它立即被删除，随后是一场“共识讨论”……人生苦短，考虑到网站上如此多文章（无论是遵守政策还是信息严重过时）的巨大缺陷，我的列表所引发的问题很好地说明了网站如何忽视了更宏大的图景。花了很长时间专注于一个小小的列表，却忽略了其他地方所需的大量工作。这就是为什么我相信需要改变一些态度，以避免赶走许多需要的旅行者，因为他们才是能发现错误并修复错误的人（但他们会犯“风格”或政策错误，然后……）。但那是另一个话题，目前我没有时间或资源参与讨论。PsamatheM (talk) 2020年1月28日13:52（UTC）

@PsamatheM: 无休止地批评这个社区的方法，然后当被挑战时说“我没时间参与”，这很容易，但如果你对你旧的“烦恼”如何能比通过讨论导致政策改变，从而更容易列出你所倡导的旅游类型，有更好的处理方法，请分享。你得到了你想要的结果，但仍然不够好。你谈论改变态度，但没有提出你清楚设想的这个网站更好的替代方案，而是继续抱怨几个月前那些你觉得没有按照你的方式进行的事情。我认为如果你以积极的方式提出建议（“我有一个想法，这就是为什么我认为它会让Wikivoyage变得更好，你觉得呢？”），我们会更容易接受。但目前——如果我理解错了，我道歉——我觉得你很高兴告诉我们所有我们做错了什么，但对提出建设性的如何做得更好的建议不感兴趣。我希望被证明是错的。--ThunderingTyphoons! (talk) 2020年1月28日15:26（UTC）

@ ThunderingTyphoons!: 正如我在此次讨论中稍早前所说，我目前没有时间参与（我说过“但我目前正在东南亚旅行，还没准备好参与讨论（这无论如何都将是另一个主题/帖子/部分）。我将在几个月后（或更久，或任何时候）回家时开始新的讨论。”）。由于互联网速度慢且不可靠，我甚至很难将照片备份到云端，所以现在开始讨论可能会让我消失一周，而且会变得非常支离破碎——因此我后来才说，而不是像你评论中暗示的那样拒绝参与。

我并不是在抱怨过去，而是用它来说明问题。为了一个列表而经历的痛苦是荒谬的。更好的处理方式是，例如，保留列表并要求我将其作为例外进行辩护，或者相信一个独立旅行者“现场”做出明智的判断等。

我并没有“得到我想要的结果”——我只是想提供信息来帮助其他独立旅行者。为了一个列表而付出的努力让我觉得我的时间最好花在旅行上，所以所有关于巴士路线等过时、错误、误导性的信息可能仍然会误导其他旅行者。

正如我所说，我回家后有网络、笔记本电脑和时间讨论时会提出建议——现在我不太确定我是否还想这么做了。我之前说过，我对提出建设性意见很感兴趣。PsamatheM (talk) 2020年1月29日01:55（UTC）

毕竟，维基导游不像维基百科那么有名。此外，主要的活跃人群大多是社区中的人，甚至遇到了很多像我们这样的竞争者，因此外部推广是必要的。基本上，我在YouTube上创建的维基导游频道是为了帮助任何人了解我们的维基导游。我也希望有朋友想要发布宣传或教学视频。您可以向我提供您的G-Mail。我将允许愿意的人成为管理员，这样您就可以将视频发布到维基导游的YouTube频道。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2020年2月5日16:21（UTC）

请在2020年社区愿望清单上投票支持维基导游的提案

自11月20日起，愿望清单提案的投票已开放。请支持Wikivoyage提案。

不幸的是，与地图相关的提案被删除了。维基媒体基金会的用户 IFried 解释道：“……谢谢您提交此提案！我们团队对此进行了审查，不幸的是我们无法采纳此愿望。原因如下：我们的基础设施团队目前正在讨论将地图前端和后端切换到不同的技术栈的选项，这将更强大且更易于维护。如果能实现这一点，那么它就可以解决此提案中表达的许多担忧。至少需要几个月才能确定最终决定，因此今年的愿望清单，我们不会就现有地图栈的任何可能承诺展开工作。再次感谢！” --RolandUnger (talk) 2019年11月22日07:48（UTC）

“所需文章”愿望也从m:社区愿望清单调查2020/维基导游中删除了。由于读者在地图上的当前位置可能是旅行网站最重要的功能之一，这并不能真正给人留下委员会对帮助维基导游感兴趣的印象。--Traveler100 (talk) 2019年11月22日14:46（UTC）

总有明年。各位，这是清单

• Wikivoyage的内容翻译工作
• 维基导游附近文章数据文件需要永久更新
• 创建坐标选择器
• 当地理定位被禁用时，“附近”特殊页面应显示输入表格和坐标选择器

我有点惊讶最后两个没有因为不特定于维基导游而被删除（它们是“全球性”请求，可以惠及任何维基，而不仅仅是维基导游）。

我们还应该查看其他项目的列表，看看是否有任何项目也能偶然地惠及我们。

投票规则是：是的，您已经有资格投票，所以请投。基本上，如果您有任何编辑，并且您看起来不像一个专门为投票而创建的账户，那么您就有资格在愿望清单中投票。WhatamIdoing (talk) 2019年11月22日21:13（UTC）

我查阅了一些其他项目的愿望，发现m:Community Wishlist Survey 2020/Wikibooks/EPUB generation可能也对维基导游感兴趣。WhatamIdoing (talk) 2019年11月28日03:51（UTC）

我同意改进文章的离线使用功能会很好。由于我不是EPUB格式的常规用户，所以我稍微偏好m:Community Wishlist Survey 2020/Wikiversity/将已发表的WikiJournal文章导出为DOCX或PDF。如果能提供一种简便的方法，让酒店在客房文件夹中放置一份整洁的城市文章（部分内容）纸质副本，那就太好了。AlasdairW (talk) 2019年11月28日22:35（UTC）

@AlasdairW: 很高兴您喜欢我的提案，并能够看到它在维基大学/维基期刊之外的用途。OhanaUnited^讨论页 2019年11月29日04:30（UTC）

这也会很有用。投票将于周一结束。目前，维基导游有一个（已标记的）愿望进入前5名（只有前5名“获胜”）。另一个目前距离获胜还差6票。请记住，您可以投票支持您认为好的任何愿望，而不仅仅是那些带有维基导游标签的愿望。有些人活跃于其他项目，我们希望支持他们。此外，一些“非维基导游”的愿望也可能在这里有用。我想到了m:Community Wishlist Survey 2020/维基语录/在视觉编辑器工具栏中添加“添加引用”按钮这一类。我不认为这个今年会赢，但是我的工作团队一直在与编辑团队讨论如何实现它，这也可以让我们在这里的工具栏中放置Do/Buy/See/Eat/Sleep模板列表。重要的是只需投票支持您想要的。WhatamIdoing (talk) 2019年11月29日20:51（UTC）

更多黑客攻击尝试

我又收到了一次警告，说有多个新设备试图以我的用户名登录维基导游失败。我是唯一收到这些警告的人吗？Ikan Kekek (talk) 2019年12月6日01:13（UTC）

我不记得我收到过这些。你会去哪里查找这些信息？ --评论者 Selfie City (讨论 | 贡献) 2019年12月6日02:54（UTC）

你不需要找它。你会在那里收到通知，可能还会收到一封电子邮件。Ikan Kekek (talk) 2019年12月6日04:15（UTC）

我一个也没见过。设备地址是否与任何可能对您不满的人匹配，例如Telstra的破坏者？Pashley (talk) 2019年12月6日05:59（UTC）

我怎么会知道设备地址呢？Ikan Kekek (talk) 2019年12月6日10:01（UTC）

为维基导游提供内容翻译工具

我不知道你们有没有用过维基百科的内容翻译工具，但我只想说这是一个非常强大的工具，它帮助维基百科社区在各种维基百科版本之间翻译了大量文章（主要是将英文维基百科的文章翻译成较小的维基百科版本）。

到目前为止，这个工具只在维基百科中使用。

作为当前社区愿望清单调查的一部分，有人提出建议，将此工具也提供给所有维基导游版本。

meta:社区愿望清单调查_2020/维基导游/内容翻译_维基导游工作

如果您支持将此工具提供给维基导游，请在该页面中添加您的投票。ויקיג'אנקי (talk) 2019年11月30日14:21（UTC）

这一个离获胜只差几票了。投票非常简单：前往该页面，然后点击蓝色按钮“支持”。如果您愿意，可以添加可选评论，但大多数人不会。投票即将结束。WhatamIdoing (talk) 2019年12月1日18:13（UTC）

@WhatamIdoing: 什么时候？

各位，这个可能真的很有价值；主要是对我们较小的姐妹项目，但也适用于目标文章在其他语言版本上比这里更完善的情况。我鼓励大家投票。—此评论由ThunderingTyphoons!（讨论 • 贡献）添加

产生的翻译质量如何？比Google翻译好吗？Ikan Kekek (talk) 2019年12月1日18:29（UTC）

谷歌翻译不足以作为最终文档呈现，但足以完成大量初步的意义翻译工作。然后，一个不错的（人类）翻译者可以专注于改进流畅度，掌握地道语言，并清理机器造成的理解错误或遗漏的细微差别。这就是专业翻译人员的工作方式（不一定用谷歌，但肯定会用翻译软件），因为它更快，因此翻译人员可以投入更多时间做真正需要他们专业知识的工作。--ThunderingTyphoons! (talk) 2019年12月1日20:01（UTC）

好的，但我的问题是这个翻译工具到底有什么价值，它比谷歌翻译好吗？Ikan Kekek (talk) 2019年12月1日20:10（UTC）

我没用过，所以无法回答你的问题。在我看来，这些问题可以稍后再提；投票是首要任务。仅仅因为投票通过，并不意味着我们必须使用它。--ThunderingTyphoons! (talk) 2019年12月1日22:04（UTC）

ויקיג'אנקי 和 WhatamIdoing，对我的问题有什么反馈吗？Ikan Kekek (talk) 2019年12月1日22:26（UTC）

你知道它在实践中是如何运作的吗？我看到的最严重的问题是，很多人会跳过“清理机器造成的任何理解错误或遗漏的细微差别”这一部分，尤其是在使用机器时，你并不一定需要理解源语言。我很久没看过了，但谷歌曾经有时会生成看似不错但包含严重错误信息的文本，因为它擅长查找地道语言，但在理解方面却毫无用处。我见过最糟糕的是它在不更改数字的情况下翻译货币（美元到芬兰马克）。我认为我们只有在觉得它有用且不太危险的情况下才应该投票支持该工具。我们可以修正糟糕的语言，但很难修正不明显的错误信息--LPfi (talk) 2019年12月2日13:47（UTC）

ThunderingTyphoons!，投票今天结束。

Ikan Kekek，这是一款旨在让双语编辑轻松翻译文章的软件。它不是自动翻译。有一个设置可以确保纯机器翻译不会被倾倒到文章中。如果你不先清理它，它就不会让你点击“发布”按钮。最小清理工作量可以根据语言进行配置。此外，还有一个系统，如果个人编辑（IP完全不能使用它）翻译的文章被删除太多次，它基本上会阻止他们使用它。总的来说，这是一个设计得相当不错的系统。WhatamIdoing (talk) 2019年12月2日16:52（UTC）

好的。根据您的建议，我将投赞成票。您使用过该工具吗？Ikan Kekek (talk) 2019年12月2日20:03（UTC）

我收到一条错误信息，“抱歉！调查已关闭。”下次，如果能提前一点发布公告，给我们时间讨论提案，那会更好。您不能因为我们不愿意纯粹基于信任或仅仅因为被要求而投票就责怪我们。Ikan Kekek (talk) 2019年12月2日20:07（UTC）

愿望清单投票已于11月4日在酒吧宣布，并于11月22日再次提醒。如果您想投票支持任何提案，留到最后一天不是最好的主意。当然，这个特定的提案仅在几天前在这里提出，但所有提案都已存在了将近一个月。指出这里每个人都有机会投票并不是责备。

结果将于12月6日公布；希望我们能有值得庆祝的事情。--ThunderingTyphoons! (talk) 2019年12月2日21:41（UTC）

关键是，我不知道这个工具是否有用，也不知道投票支持它很重要。我很久以前就投票支持其他事情了。Ikan Kekek (talk) 2019年12月2日23:38（UTC）

看来我们不会得到这个功能了。它以令人称赞的第八名结束（这在排名前五位中有四个是维基文库提案的情况下，还算不错）OhanaUnited^讨论页 2020年1月10日 (UTC) 05:52

第五个是关于维基词典如何能更轻松地链接到维基文库。WhatamIdoing (讨论) 2020年1月11日 (UTC) 22:09

管理员，请阅读

各位朋友，那些对过滤器运作方式有很好了解的人，请注意过滤器 #37。似乎有一个问题或错误。我将非常感谢提供一些专业知识。--ThunderingTyphoons! (讨论) 2019年12月16日 (UTC) 07:42

我们有没有一个关于修改过滤器最佳实践的页面？你不会因为正则表达式、错误跟踪等方面的经验而成为管理员，所以我们不能期望我们的管理员具备这种专业知识（我们确实有一些专家，但他们并不总是可用）。我花了不少时间研究语法和一些过滤器工具的工作原理，了解更多会使这类工作容易得多。我能够阅读并理解技术文档，但仍然会从教程中受益。--LPfi (讨论) 2019年12月17日 (UTC) 14:12

这仍然是个问题吗（一个月后）？如果是，我可以看看。Andrewssi2 (讨论) 2020年1月10日 (UTC) 05:32

有一个微不足道的错误藏得很深。仍然欢迎提供指导页面。--LPfi (讨论) 2020年1月10日 (UTC) 17:01