Wikivoyage:旅人茶馆/2019

页面预览弹窗

我们几个月前就讨论过这个问题，但根据这次讨论，我正在尝试重启这次讨论。不过，这次我做了一些关于症状的研究。

首先，回顾一下，目前 Wikivoyage 上的页面预览存在一个问题，即它倾向于从列表（无论是否链接了 Wikidata ID）而不是文章本身获取预览图片，这远非理想状态，正如其中一些文章所证明的：

• 华盛顿特区 - 无法辨认且不具代表性的地标；
• 阿姆斯特丹/Zuidoost - 一张历史事件（Bijlmerramp）的照片。一架货机撞毁公寓楼的景象远非吸引人，更谈不上代表该地区；
• 哈勒姆和阿尔克马尔 - 火车站的照片，这些照片不能代表目的地；
• 希尔弗瑟姆 - 希尔弗瑟姆机场的照片，这对许多旅客来说没有用，因为那里是训练场和私人飞机场。

总而言之，你很难不遇到糟糕的图片。随便浏览一下，你就能轻易找到它们。

其次，这些图片是如何出现在预览中的？嗯，创建这些预览的页面预览本身没有错，而是PageImages。它对图片的评分偏向列表和标记，特别是那些有图片可以从链接在Said列表中的Wikidata ID获取的。源代码本身添加的图片，读者总是能看到，并且被选为代表性的图片，在评分列表中排名非常靠后。唯一评分更差的图片似乎是页面横幅，它们被完全列入了黑名单。我无法具体指出扩展程序的哪个部分是错误的，因为我的代码阅读能力有限，所以也许其他人可以指出。

第三，这个问题该如何解决？简单的选择当然是禁用页面预览，但我排除这个选项，因为总的来说，它并非一个坏功能，只是对我们的使用方式优化不佳。同样排除的是手动检查文章以确保它们显示有用的图片，原因很简单，我们编辑者有更多更好的事情要做。在我看来，更可行的方法是仅从导言部分获取图片（此处描述），或者联系 PageImages 的开发者探讨优化扩展程序使用的可能性。我还探索了在文章导言部分添加一个空的{{标记}} 来提高其优先级的可能性，但没有成功。因此，制作一个模板来强制使用特定图片并非一个非常可行的方案。

我在这里寻求的是关于哪些图片是理想的图片达成共识：只有文章中定义和显示的图片？列表的图片也包括在内，如果是的话，是哪些类型的列表？等等。之后我们可以讨论我们的行动。我们是改变 PageImages 在这里的工作方式，修改其设置，还是要求修改其代码和内部运作，或者我们只是在这里禁用该扩展程序？总而言之，关于这个话题的讨论非常必要。我会尽我所能回答您可能有的任何问题。提前感谢。
-- Wauteurz (讨论) 20:07, 2019年1月10日 (UTC)

为什么不选择文章 Wikidata 上的第一个图片？要么修改 PageImages 代码，要么我想到了在页面顶部放置一个小的折叠图标{{Wikidata Infobox}}。也许这能强制显示更好的图片。--Traveler100 (讨论) 20:46, 2019年1月10日 (UTC)

如果我手动选择图片，我首先会查看用于创建横幅图片的图片。我的第二个选择是横幅图片，或者如果需要一张更高的图片，可能是横幅图片的左半部分或三分之一。一张精心选择的横幅图片可以反映目的地的特色。它也是读者在访问文章页面时会看到的图片，因此如果读者不确定是否已经查看过该页面，可能会很有用。横幅图片至少有 1800 像素宽，所以我们可以确保它们有足够的分辨率，并且绝大多数质量都不错。之后，我倾向于使用文章中的图片，但要尽量避免使用“进入”和“出行”部分的图片，包括地图和机场照片。我会避免使用文章中未显示的图片。 AlasdairW (讨论) 21:34, 2019年1月10日 (UTC)

感谢 Wauteurz 花时间为我们做了研究和总结。回答你在最后一段提出的问题，就我而言，我认为只应该使用文章中显示的图片，因为至少这样一来，Wikivoyager 选择的图片才会显示在预览中，而不是似乎随机生成的东西。我也认为我们应该“请求更改其代码和内部运作”；禁用一个本应是有用的扩展程序应该是最后的手段，如果 PageImages 的开发者无法或不愿意帮助我们的话。--ThunderingTyphoons! (讨论) 21:46, 2019年1月10日 (UTC)

@Traveler100: 那当然可以，但我没有发现任何表明 PageImages 支持现成功能的迹象。我以为与我们已有的东西合作会更容易，如果现有的选项都不够，我们可以联系 PageImage 的开发者。我没有扩展程序方面的经验，所以我不知道每个项目是否都能修改整个扩展程序以适应其需求。如果有人能告诉我，我将非常感激。

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

@AlasdairW: 重用横幅图片不是一个好解决方案。由于横幅的比例是 7:1，将其裁剪成 4:3 或其他比例会丢失大量横幅内容。此外，有些横幅是向左、向右或居中的。我们需要为大约 15,800 个自定义横幅手动设置中心点（这是一个功能，但很少被使用）。在那种情况下，使用横幅的源材料将是我的首选行动方式。尽管如此，也有可能使预览高度变短，并强制其使用 7:1 的页面横幅。我犹豫是否要说地图是一个好替代方案。以Achterhoek为例。它没有列表，导言部分也没有图片，因此默认使用该地区的地图，这并不吸引人。地图除了显示一些基础设施和城镇外，几乎没有其他信息。至于机场，在我看来，它们不足以代表文章内容。以阿姆斯特丹为例，你在预览中看到的是史基浦机场，而不是被列入联合国教科文组织名录的运河和市中心，这会是更好的展示内容。

我完全同意我们应该使用 Wikivoyage 编辑者添加的图片，最好是读者在阅读文章时能看到的图片（因此不包括列表和地图框中隐藏的图片）。我认为这是我们可以达成一致的地方。

为了清晰起见，我的偏好首先是行内图片（缩略图），其次是编辑者定义或编辑者修改的列表图片（即填写了 `image` 参数的图片），然后是横幅源材料，最后是没有预览图片。实现这一点的最简单方法是调整 PageImages 的评分系统，使列表图片以及{{区域列表}}和类似模板中的图片（需要明确的是，我不知道单个项目是否能更改该评分系统），或者将 `wgPageImagesLeadSectionOnly` 设置为 true，这意味着只使用导言部分的缩略图（我知道这是我们的管理员可以更改的）。
-- Wauteurz (讨论) 22:00, 2019年1月10日 (UTC)

抱歉，如果我没说清楚。我想使用文章中显示的图片，除了“进入”和“出行”部分的图片。这通常会排除“进入”部分显示的机场和车站图片，以及通常在“出行”部分出现的地图。这意味着如果“查看”或“活动”部分没有图片，就使用“了解”部分的图片。我这里指的是城市文章，其他文章可能需要排除其他部分。 AlasdairW (讨论) 22:53, 2019年1月10日 (UTC)

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

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

附注：抱歉再次更改我的签名。我觉得橄榄绿色太刺眼了，所以我把它改回了蓝色。 --评论来自 Selfie City (讨论 | 贡献) 02:39, 2019年1月11日 (UTC)

@AlasdairW: 你说得很清楚，我只是没仔细看。从“查看”、“活动”等段落获取图片的难点在于，与 Wikidata 链接的列表并不总是在 Wikidata 中有有用的图片。之前的讨论甚至就是因为这样的列表而引起的。

@LPfi, SelfieCity: “了解”部分不总是有图片，导言部分之前也是如此。虽然这种获取图片的方法可以解决塞拉内华达山脉的问题，但对于太浩湖就没有改善，因为后者在这些部分没有图片。不过，我仍然支持这种方法，因为它相对容易，我们可以让机器人（或者可能是 Petscan）找到没有导言或“了解”部分图片的文章，并组织一次 CotM（如果有很多这样的文章，也可以作为 2019 年的目标）来在这些部分添加图片。

如果我们能够配置 PageImages 的评分系统，那么也许值得将{{列表}}、{{标记}}、{{区域列表}}等模板中使用的图片列入黑名单，转而根据图片在文章中的顺序进行评分，如果可能的话，还可以奖励那些曾在 Commons 上展出或带有质量标签的图片。查看一些例子，我得出结论，也许我们应该尽可能地黑名单所有模板，因为在提名文章中出现“复选标记”来“代表”文章（FTT、DotM 或 OtBP）是完全不可取的。总之，这种评分方法理想情况下应该根据文章中的出现顺序来评分图片，例如，荷兰铁路旅行中的图片，因此会抓取阿姆斯特丹中央车站的图片，这张图片因被 Commons 评为优质图片而获得奖励。也许一个用于修改评分的模板，让编辑者可以更精确地控制图片的选择，会很有用，但我们现在先不要想得太远。

如果我没记错的话，我发现一种普遍的趋势是想要导言部分和/或“了解”部分的图片。这，正如我之前所说，我们的管理员和/或管理者可以通过将参数 `$wgPageImagesLeadSectionOnly` 设置为 true 来配置。我暂时没有开始投票，因为还有很多其他选项，我希望听到更多 Wikivoyagers 的意见，以便我们最终能就一套方法进行投票。届时，或许也值得请 PageImages 扩展程序的 MediaWiki 负责人来指导我们做出好的选择。
-- Wauteurz (讨论) 10:55, 2019年1月11日 (UTC)

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

如果我们选择将图片添加到《了解》部分，或者在没有《进入》部分的情况下放在《进入》部分之前，我不确定如何轻松追踪这个项目的进展。初步看来，我找不到限制高级搜索或 Petscan 到文章某部分的方法。有人有什么想法或建议吗？我可以看到运行一个机器人扫描页面并进行标记的可能性，但那样不能保证会被移除。--Traveler100 (讨论) 07:45, 2019年1月13日 (UTC)

我也不知道。正如我在下面回答你的问题时提到的，API Sandbox 可能是一种找出方法，但这需要一个机器人来查找和标记这些页面，而不是 PetScan。只有当页面被标记了模板（例如，为了进一步参考，使用 `NoImageInLead`）时，我们才能更容易地使用 PetScan 找到这些文章。我认为没有机器人的参与，我们做不到。
-- Wauteurz (讨论) 12:06, 2019年1月13日 (UTC)

问题 - 图片在页面上显示的大小（而不是实际大小）是否会影响排名？可以在页面顶部放置一张不显眼的小图片（不易看到），通过对文章中已有的 `geo` 标签进行扩展。这将是文章中的第一张图片，默认可以是wikidata 标准图片，或者你可以在 geo 模板中添加图片文件名来定义另一张。--Traveler100 (讨论) 08:15, 2019年1月13日 (UTC)

不理解 PageImages 的计算。例如，文章 奥赫里德 中的第一张图片与机场列表中的图片实际大小相同，但仍不是选定的预览图片。--Traveler100 (讨论) 09:38, 2019年1月13日 (UTC)

@Traveler100: 简单来说，是的，图片大小很重要。我从来没有完全理解评分是如何工作的，但根据我的理解，我对评分系统有了一个不错的 ধারণা，尽管我不知道具体数字是多少。

• 小于 119px 或在 `$wgPageImagesScores['width']` 中定义的任何值都会受到高度不利的影响，而小于 100px 的图库中的任何图片都会被忽略。由于我们不使用图库，Wikivoyage 上的小图片（例如，宽度为 50px 的图片）仍然会被考虑。
• 400-600 像素是模板搜索的宽度，偏向于较低的边界——换句话说，400 像素是理想的，任何比这宽 50% 的都可以接受。我不确定 400×600 像素的缩略图如何被偏好于 4000×6000 像素的图片，但我认为缩略图是从文章中获取的，也就是说，获取的是缩略图，而不是原始的大图。
• 文章中的前四张图片会被考虑，除非通过 `$wgPageImagesScores['position']` 更改了该数字。我怀疑，无论是文章的渲染顺序、地图框架还是列表，列表中的图片（这是 Wikivoyage 上最主要的问题）由于先渲染而被视为具有更高的位置。这或许可以解释为什么奥赫里德有预览图片，但这是我的推测。我不能确定。
• 最后，图片的比例也会被考虑。任何宽于 2:1 的图片，例如我们的页面横幅，都会被自动丢弃或受到高度不利的影响。我不确定这是否也适用于长宽比为 1500×500 像素的肖像图片，因为文档没有明确说明，但我们假设它们是。在这种情况下，任何宽于 2:1 或高宽比大于 1:2 的图片都会被忽略。同样，这个比例（默认为 0.5）可以通过 `$wgPageImagesScores['ratio']` 进行自定义。这并不意味着任何更宽的图片，如页面横幅，会获得偏好，而只是调整了被考虑的范围。

我已经尽力使 PageImages 文档页面上的解释更易读，但如果不行，原始文档可以在此处找到。我不确定在 `geo` 模板中添加图片是否会有帮助，因为我不知道哪些模板被列入黑名单，哪些没有。你可以随时尝试。它可能无效，因为 `geo` 模板是代码中的最后一个模板之一，对于读者来说只是视觉上的第一个模板。机器可能会因为文章渲染方式的不同而读取它。唯一的方法就是尝试，我觉得。也许任何有 Wikimedia API 经验的人可以尝试一下，但看起来我们可以通过使用 API Sandbox 来找出哪些图片被考虑。如果有人愿意并且能够尝试一下，那么请看PageImages#API，看看是否可以对 Wikivoyage 上的文章进行这样的请求。
-- Wauteurz (讨论) 12:06, 2019年1月13日 (UTC)

@Wauteurz: 谢谢，这些评论帮助我弄清楚了这里发生了什么。正如你所说，列表是先解析的，但只有带坐标和图片的列表。所以前 4 个带坐标和图片的列表是候选。--Traveler100 (讨论) 12:27, 2019年1月13日 (UTC)

你说的对，geo 模板是行不通的，即使在模板中添加一个显示在顶部的列表，它仍然被视为列表的最后一张图片。所以，我能想到的唯一一种在不修改维基媒体代码的情况下进行控制的方法是，在每个页面顶部放置一个带有坐标的列表，例如显示城镇中心的位置。不确定这是否会被接受。我认为我们需要要求图片排名代码的开发者忽略列表图片。--Traveler100 (讨论) 12:50, 2019年1月13日 (UTC)

@Traveler100: 精确地说，如果带坐标和图片的列表少于 4 个，那么下一个候选者就是文章中的图片，或多或少按照它们出现的顺序。像 `featurenomination` 这样的模板似乎得分非常低，或者被列入了黑名单/完全忽略。我从未发现过特色文章在预览中显示过复选标记。另一方面，它是否需要被列入黑名单？特色提名文章有足够的图像来超过那个小复选标记。我知道这不太相关，但我认为有必要纠正我之前关于这是可能性的说法。
-- Wauteurz (讨论) 12:54, 2019年1月13日 (UTC)

T213652 要求将排名改为在列表图片之前优先显示可见图片。--Traveler100 (讨论) 13:19, 2019年1月13日 (UTC)

Phabricator 更新后

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

1. 将上述参数 `$wgPageImagesLeadSectionOnly` 设置为 `true`，这意味着所有预览图片都将从导言部分获取，并且仅限于导言部分。许多文章有图片，但不在导言部分，这将需要一个机器人和一个可能的“每月协作”来优化。然后，我们将手动处理机器人提供的列表，并在需要的地方添加图片，或者设置同一个机器人将文章中的第一张图片移动到导言部分。
2. 交换列表的顺序以获取更理想的图片。我们知道图片是通过它们在列表中的出现顺序来获取的。列表 #1 总是比列表 #3 优先被选中（如果两者都有图片）。如果列表 #3 的图片比 #1 更好，那么我们可以交换这两个列表以达到期望的效果。主要缺点是这将比上述选项需要更多的精力。我认为选项 1 可以通过 CotM 解决，而这个选项可能需要“年度协作”。
3. 什么都不做。一个对我们有利的解决方案已经在开发中了。但我还没有找到它的预计完成时间。显而易见的缺点是，我们可能需要数周甚至数年才能应对当前的情况。

最好让 Phabricator 的事情稍微发展一下，之后我们可以寻求共识，决定如何解决当前的问题。随意讨论以上选项或提出新建议，也可以在 Phabricator 上参与讨论。
-- Wauteurz (讨论) 20:26, 2019年1月14日 (UTC)

Wauteurz 用户出色地解释了其工作原理。当我提议启用页面预览功能时，我确实提到我们需要重新思考我们的描述和图片来支持它，但我认为这对项目有利，并且是一个我们可以解决的编辑问题。

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

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

令人沮丧的是，在像 华盛顿特区 这样的案例中，似乎是这样——林肯总统的照片非常有标志性和相关性，但出于某种原因，它没有被选为页面图片。我很想进一步研究一下，看看为什么会这样。在我看来，这似乎是一个 bug。希望这能消除我们看到的一些糟糕的页面图片。

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

@Jdlrobson: 我很清楚我不是唯一一个持此观点的人，但对我而言，$wgPageImagesLeadSectionOnly 似乎是最好的选择。我非常赞成一次影像探险或“每月/每季协作”，正如我之前所说。一次探险的目标是让每个导言部分都有一张图片，在此之后，我们应该会有绝大多数的文章在导言部分有图片。只有在实现这一点之后，我才会赞成将 $wgPageImagesLeadSectionOnly 设置为 true。我承认我之前没有说清楚这是我心目中的顺序。由于 phab:T91683 已经进行了好几年，而且没有一个目标被完成，我非常乐意在今年年底或 2020 年的某个时候实现这个目标。

我可以报告说，华盛顿特区的图片来源于文章中第一个带坐标的列表：阿富汗大使馆。这并不是说图片是从一个看似随机的地方抓取的。正如你所说，算法并不智能。我之前曾推测列表会获得优先权，因为它们或地图框架在页面内容加载之前就被加载了。我无法证实任何这一点，但也许值得研究一下。同样，如果算法如此愚蠢，那么为什么不重写它来区分那些显而易见的图片（缩略图等）和“不可见”的图片（列表等）呢？我可能极大地简化了整个过程，但请原谅我，我缺乏技术知识。我在学校学到的编码和技术知识早已淡忘。

无论如何，我非常支持一次影像探险，但我希望听到其他人的见解。
-- Wauteurz (讨论) 21:21, 2019年1月14日 (UTC)

在我看来，任何需要编辑每页或手动设置预览图片的解决方案都有问题。虽然我们可以为我们最受欢迎的文章这样做，但我们大部分页面的文本内容本身就很匮乏，而且许多文章没有自定义页面横幅，更不用说导言中的图片了。即使我们找到了图片，在很多情况下，它也会主导文章。

是否有可能，作为第四种解决方案，调整图片分数的权重，以极力倾向于 Wikidata 图片？我认为这是最好的解决方案：我们的大多数文章将立即获得一张图片，这张图片被认为是代表目的地的，作为预览图片，而那些 Wikidata 图片质量不佳的文章则很容易更改，这样做也会使其他项目受益。此外，Wikidata 中没有图片的地点，但有横幅的，可以将横幅源图添加到 Wikidata，而没有图片或横幅的地点仍然有其他种类的图片可以作为后备。如果这不可行，似乎对 Phabricator 的开发者来说，这是一个更简单的更改。

如果这不可行，似乎这对 Phabricator 的开发者来说是一个简单的改变。 ARR8 (讨论 | 贡献) 01:37, 2019年1月15日 (UTC)

建议更多人订阅 Phabricator 上记录的两个问题，我看不出为什么这在技术上不可能，可能只是因为它不够受重视，而且还有很多其他问题需要解决。或者，我认为可以在每个城市页面开头添加一个标记，指向 wikidata 图片（见下文）。但正如我所见，在页面开头添加位置图标需要讨论和一些共识，因为它有利有弊。--Traveler100 (讨论) 10:03, 2019年1月15日 (UTC)

我不喜欢任何需要大规模编辑每页的解决方案。这种事情应该透明地进行。如果我们想让它现在就起作用，那么我们确实需要做一些像那样笨拙的事情，但我宁愿让开发者先修复底层问题，然后再开始改变我们所有页面的外观。

但我确实很欣赏你找到了最不显眼的方法。不过，我认为在目的地名称后直接放置一个编辑按钮可能会让新编辑感到困惑，他们可能会点击那个而不是页面编辑按钮。 ARR8 (讨论 | 贡献) 13:50, 2019年1月15日 (UTC)

@ARR8: 我并不是说要手动编辑我们所有的 33,748 篇文章。Wikidata 拥有这些文章的大部分图片，而通过机器人不使用这些图片将是一个浪费的机会。然而，这也仍然需要一些手动输入，而一次协作或探险将有助于使其结构化。正如你自己所说，Wikidata 也有不太理想的图片，希望我们能在此过程中修复它们。目前并非所有文章在预览中都有图片，如果有的话，数量会增加。我们都不知道确切的数字，但也许值得研究一下，因为文章预览中带有图片的改变可能是一个重要的因素，可以帮助我们选择最终的方法。总而言之，与 Wikidata 的集成是我记得在过去几年里被提及过的愿望，因此链接列表到 Wikidata。这可能只是一个抓住那个愿望并进一步实践的机会。我个人完全不反对将页面横幅的源图设置为相应 ID 的 Wikidata 图片，更不用说使用链接到我们文章的 Wikidata ID 中的图片了。

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

无需手动编辑，可以在页面横幅模板中添加一个模板，提取维基数据并在页面右上角创建列表。 --Traveler100 (讨论) 2019年1月16日 11:58 (UTC)

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

也许这是杀鸡用牛刀，但这里有一个解决方案 华盛顿特区/沙盒。而且不需要一年时间来编辑页面，很可能可以通过机器人编辑完成。有什么评论吗？ --Traveler100 (讨论) 2019年1月14日 21:41 (UTC)

我并不是说我们应该这样做，但基本上唯一可见的变化是在城市文章开头添加一个坐标（以及市中心的位置），例如 奥赫里德/沙盒。这样是否可以接受以获得更好的预览图片？ --Traveler100 (讨论) 2019年1月15日 09:58 (UTC)

我宁愿不这样做。这个数字在文章开头只是一点点令人困惑，但在动态地图上显示时却相当令人困惑。—Granger (讨论 · 贡献) 2019年1月15日 14:13 (UTC)

可以将其移动到右上角（参见 华盛顿特区/沙盒），并省去编辑页面的需要（更新页面横幅），但无法将其从地图上移除。（注意当前的页面横幅沙盒是固定的图像和坐标，但可以更改为页面的维基数据值） --Traveler100 (讨论) 2019年1月15日 18:17 (UTC)

我不赞成这样做。一方面，它确实修复了预览图像，但另一方面，它也为每一个预览摘要添加了1，依我看，这不值得。我更赞成这个想法，但是用地图形状而不是地图标记。目前还没有这样的模板，而且我不确定这是否可行。这样在预览中就不会显示列表号（1），而是显示其标记的摘要——没有标签，没有链接——只有纯文本，就像它应该的那样。然后，这个模板可以分配一个图像和维基数据链接。两者都不会在地图上显示。
-- Wauteurz (讨论) 2019年1月15日 18:20 (UTC)

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

是的，这确实是一个可能性。然而，如果我们使用noexcerpt，我们将不得不为{{listing}}模板创建一个单独的实例。届时，不如上面描述的那样创建一个模板，该模板在行政区划周围添加一个地图框，而不是在地图上添加一个毫无信息的标记。
-- Wauteurz (讨论) 2019年1月16日 20:02 (UTC)

今日生效的更新解决方案

我在比托拉创建了一个测试。这不需要对页面进行任何手动更新，只需将代码添加到页面横幅中即可。将使用维基数据中的图像和坐标。请注意页面顶部的额外图标和文本。它仍然会在地图上创建一个图标，但它是浅灰色的。在预览中不会创建任何标记。我用户空间中的当前测试模板需要一些工作才能真正可用，因为它目前在维基数据不存在的情况下处理得不好。如果人们认为这是一个可行的解决方案，我可以进一步研究。提出这个的原因是，我认为媒体维基代码在短期内不太可能发生变化。 --Traveler100 (讨论) 2019年1月21日 09:03 (UTC)

FileExporter 贝塔功能

即将推出：贝塔功能 FileExporter

一项新的贝塔功能将很快在所有维基上发布：FileExporter。它允许将文件从本地维基导出到维基媒体共享，包括其文件历史和页面历史。哪些文件可以导出由每个维基的社区定义：如果您想使用此功能，请检查您的维基的配置文件。

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

一如既往，我们非常欢迎您的反馈。如果您想测试 FileExporter，请在您的用户偏好设置中激活它。反馈的最佳地点是中心讨论页。感谢来自 Wikimedia Deutschland 的技术愿望项目。

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

页面预览和导航弹出

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

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

我可以确认这个 bug。我不得不手动禁用页面预览，因为这个原因。 ARR8 (讨论 | 贡献) 2019年1月27日 16:57 (UTC)

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

移动版主页

基于 @Seddon (WMF) 的工作，我更改了维基旅行为移动入口页面。它曾非常沉闷。有进一步改进的潜力，但这是一个开始，给页面带来了一些色彩。 --Traveler100 (讨论) 2019年2月10日 14:23 (UTC)

出色的工作！非常感谢你这么做。--ThunderingTyphoons! (讨论) 2019年2月10日 14:38 (UTC)

我很高兴这一点已经实现。巨大的进步。—Granger (讨论 · 贡献) 2019年2月11日 11:39 (UTC)

我改进了一些页面，但现在开始遇到困难，特别是当页面使用了表格来格式化时。 --Traveler100 (讨论) 2019年2月12日 18:29 (UTC)

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

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

感谢 @ARR8：他让移动版主页变得更好。 --Traveler100 (讨论) 2019年2月23日 06:57 (UTC)

旅行者酒吧

此页面在移动设备上未显示欢迎块。我已将介绍和清理部分分开，以便第一部分在移动设备上显示，而第二部分不显示。有点好转，但还不完美。有什么改进建议吗？ --Traveler100 (讨论) 2019年2月12日 17:41 (UTC)

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

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

Wikivoyage:社群入口

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

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

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

原始页面中存在一些错误，直到我进行更改后才显示出来。 Wikivoyage:社群入口/沙盒是我想要的在智能手机上查看以及在 Firefox 和 Explorer 上使用桌面模式查看的效果，但在 Chrome 上效果不佳。 --Traveler100 (讨论) 2019年2月13日 20:03 (UTC)

帮助资源

我发现了 mw:Mobile Gateway/Mobile homepage formatting。还有更多有用的资源吗？也许可以稍微详细地说明类和样式代码的使用方法？看起来我们用于主页和项目页面的代码不适合移动端浏览。正在寻找能帮助编写更好的、适用于所有设备的页面的资源？ --Traveler100 (讨论) 2019年2月12日 18:29 (UTC)

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

你好。+1，可以看看w:fr:主页代码——我记得他们关注了可访问性，并且结果在桌面上和移动前端以细窗口查看时看起来都不错。关于 Enwiki，我不太了解谁在该领域活跃，但我知道 w:WT:WPACCESS 和 w:WT:ACCESS 的人们通常都很友好，并且乐于讨论这个话题！(是的，我希望我们能有一些更好的模板样式设计变体在社区之间共享。（同样还有模板等等等等！∞ 心愿单...）希望有所帮助。 Quiddity (讨论) 2019年2月14日 07:50 (UTC)

移动网络模板更新

你好，

几个月前，我们提到过一个即将到来的变化，关于某些模板如何在移动网络上显示。我想通知大家，这个变化现在已经在英语维基旅上生效了。如你所知，截至1月，移动流量占英语维基旅总流量的大约三分之一（使用移动站点的独立设备数量是桌面站点的近两倍），所以让模板在移动端显示很重要。

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

我们注意到这些模板在英语维基旅上存在一些样式不一致的问题，并希望寻求您的帮助。对于模板编辑者，我们有一些关于如何制作移动友好模板的建议和我们目前工作的更多文档。

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

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

对于 WV 来说，这些是相对较小的改动，但很高兴我们得到了通知。 ARR8 (讨论 | 贡献) 2019年2月21日 04:14 (UTC)

哦，好的。但还是，好消息。 --评论来自 Selfie City (讨论 | 贡献) 2019年2月21日 04:48 (UTC)

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

与我们谈论交流

维基媒体基金会正在计划一次全球沟通咨询。目标是汇集维基媒体人和对维基有想法的人，共同改进沟通工具。

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

我们正在寻求来自维基媒体社区尽可能多不同部分的输入。这些输入将来自多个项目，使用多种语言，并包含多种视角。

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

我们需要志愿者帮助与他们的社区或用户组沟通。

您可以这样做：

1. 首先，在此处注册您的团体。
2. 接下来，创建一个页面（或在村庄泵浦上创建一个部分，或一个电子邮件线程——无论对您的团体来说是自然的），以收集您团体中其他人的信息。这不是投票或决策讨论：我们只是收集反馈。
3. 然后问人们他们对沟通过程的看法。我们想听听关于人们在维基上和维基外如何相互交流的故事和其他信息。请考虑问以下五个问题：
   1. 当您想与社区讨论某个话题时，哪些工具对您有效，哪些问题阻碍了您？
   2. 对新用户来说，讨论页的哪些方面有效，哪些方面阻碍了他们？
   3. 您的社区在讨论页方面还有哪些其他困难？
   4. 您希望在讨论页上做什么，但由于技术限制而无法做到？
   5. 一个“维基讨论”的重要方面是什么？
4. 最后，请到Mediawiki.org上的2019年讨论页咨询并报告您从团队中学到的内容。如果讨论公开，请附上链接。

您还可以帮助我们收集人们交流的各种方式的列表。

并非所有活跃在维基或围绕维基的团体都使用相同的方式进行交流：这可能发生在维基上，在社交网络上，通过外部工具……告诉我们您的团体如何交流。

您可以阅读更多关于整体流程在mediawiki.org 上。如果您有任何问题或想法，您可以以您喜欢的语言留下关于咨询流程的反馈。

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

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

陈词滥调的景点及其背后的发现

从酒吧扫过

大家熟知的哈尔施塔特景观。

Johnny Harris 制作了一个关于旅游陈词滥调的精彩视频；知名景点、景观和活动可能会被过度开发，并以奥地利哈尔施塔特为例。他说了一些关于如何超越这些的经验。维基旅的作者可以从这个视频中学到什么？如果我们描述了一个拥挤、昂贵或被破坏的旅游景点，是否应该提供避开最糟糕的拥挤人群的时间建议？或者附近的替代景点？/Yvwv (讨论) 2019年3月4日 14:47 (UTC)

此外，也许当我们展示著名旅游目的地的图片时，我们可以展示一些不太知名的。例如，对于伦敦，如果我们尝试展示一些除了最著名景点以外的景点。 --评论来自 Selfie City (讨论 | 贡献) 2019年3月4日 15:09 (UTC)

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

我相信在WV:Banner expedition 中提到过，我们应该选择能展示该地点更独特景色的页面横幅。 --评论来自 Selfie City (讨论 | 贡献) 2019年3月4日 23:22 (UTC)

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

不过，据我所知，如果它是一个漂亮的地方，那么拍摄它并没有坏处。但如果认为这两个页面的横幅太相似，那么奥地利的横幅可以更改。 --评论来自 Selfie City (讨论 | 贡献) 2019年3月9日 01:02 (UTC)

Alexa 排名

从酒吧扫过

我喜欢关注 Alexa 排名。从 2018 年中期到 2018 年 10 月，维基旅的 Alexa 排名快速但稳步地攀升。然而，排名在这个时候突然停止了攀升，趋于平缓。在接下来的几个月里，它开始下降，虽然现在似乎相当平稳，但仍未处于大幅再次攀升的地位。我想知道为什么会发生这种情况。

在 2018 年初，曾经有一个编辑者被鼓励扩充文章的项目。最近，俄罗斯维基旅上也有一个项目。这些被认为是过去 Alexa 排名攀升的原因。近期或今年晚些时候是否有类似的活动？

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

根据传闻，我注意到最近这里（特别是白天（UTC））似乎比较安静。当然，我说的是编辑，而不是读者，但我认为读者中也有一定比例的人会进行编辑。（就此而言，有谁知道关于维基读者中平均有多少比例的人至少进行一次编辑的研究吗？以及其中有多少人成为常规贡献者？）我认为维基媒体应该有一笔小额的外部广告预算。因为像 Editathon 这样有效的倡议，它们只针对内部，即其他 WMF 维基。如果没有，也许我们（维基旅）应该在社交媒体上更活跃一些。我们有 Facebook、YouTube（Twitter？），但有人关注我们吗？--ThunderingTyphoons! (讨论) 2019年2月8日 14:10 (UTC)

通常给出的数字是10%。我们还有另一个问题，那就是我们的搜索排名通常很低，特别是与维基百科相比。大多数人不是来维基旅寻找旅行信息，而是通过搜索找到这里。我曾打算为此提议一个 COTM（月度特色文章）——有几篇高关注度的文章，搜索时，第一页会返回 Lonely Planet、TripAdvisor、Wikitravel 等结果，但没有我们。我找到的最糟糕的例子可能是克罗地亚。 ARR8 (讨论 | 贡献) 2019年2月8日 14:47 (UTC)

据我理解，在 SEO 方面，这可能是因为克罗地亚文章的内容与 Wikitravel 相似（甚至重复），或者文章内容没有使用很多会被搜索引擎捕捉到的短语。

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

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

往年，维基旅和另一个网站在 10 月到 2 月期间活动都比较少。这并不奇怪，因为英语使用者通常在北半球夏季进行主要的旅行。我们预计在未来几个月会有更多流量。 /Yvwv (讨论) 2019年2月8日 15:08 (UTC)

我目前是维基旅 Facebook 账户唯一活跃的管理员，并且在维基旅本身也比较活跃。目前，每一个新的 DotM（月度特色文章）、OtBP（每日特色文章）和 FTT（每周特色文章）都会发布在 Facebook 上。我绝对觉得我们的账户应该更活跃，但正如我之前所说，我觉得这对我来说是一个太大的任务，特别是对我这样已经过度劳累的人来说。但每次我在维基旅社区呼吁有人有兴趣帮助管理我们的 FB 存在时，接手的人似乎都会像时钟一样很快就不活跃了。我仍然很希望得到帮助，但我希望如果我在这里得到任何回应，说有人想被吸纳为我们 FB 页面的管理员，那个人是计划长期留下来的人。 -- AndreCarrotflower (讨论) 2019年2月8日 15:50 (UTC)

我于十月开始上大学。问题已解决。  ;-) Hobbitschuster (讨论) 2019年2月8日22:11 (UTC)

如果您将我们过去12个月的Alexa排名进行比较，会发现它要高得多。它从大约21,500跃升到16,500。而这是重要的衡量标准，因为全年中会有季节性变化，正如Yvwv前面提到的。当然，总有改进的空间。我有时会在网上旅行论坛上宣传维基导游的文章，我认为这与问题或对话相关。我收到的所有零散反馈都表明，读过维基导游的人，大多数人都喜欢我们。很少有人不喜欢。只是几乎没有人知道我们的存在。我们的目标受众非常庞大（任何对旅行感兴趣、有互联网连接且会说英语的人，包括非英语母语者），但在这个庞大的人群中有多少人听说过我们。主要竞争对手，无论是范围相似的（例如，另一个网站、Lonely Planet、Frommers、Rough Guides），还是目标有所不同但有重叠的，如TripAdvisor、BBC Travel和Nat Geo Travel，都在社交媒体上拥有数百万粉丝。我们只有几千。我们的目标应该是推广我们的名字，让旅行者了解这个网站。SEO是许多文章几乎处于“幽灵”状态的主要原因，但除了与其他网站区分开来之外，还必须有其他方法来提高知名度。Gizza ^(漫游) 2019年2月9日13:52 (UTC)

同意。知名度非常重要。--评论来自 Selfie City (讨论 | 贡献) 2019年2月9日17:23 (UTC)

想法

有没有考虑过让维基导游拥有某种形式的博客？维基旅行（WT）以前是不是有过？如果我们开始做，我们当然希望它是集体努力，如果是这样，我很乐意帮忙。--评论来自 Selfie City (讨论 | 贡献) 2019年2月8日23:48 (UTC)

也许可以尝试与一些现有的以维基百科为中心的活动合作。例如，写关于著名艺术家的作者可能也想更新这里关于可供参观的美术馆的条目。如果在纽约、伦敦或柏林，那里有很多潜在的活动。WhatamIdoing (讨论) 2019年2月9日04:54 (UTC)

总的来说，维基导游（Wikivoyage）不太受欢迎，毕竟大家只知道维基百科（Wikipedia），不知道我们……。要让更多人对我们的维基导游感兴趣，我认为我们需要与其他旅行网站合作（例如[https://www.backpackers.com.tw/guide/ Backpackers）。--Yuriy kosygin (讨论) 2019年4月2日18:45 (UTC)

DOTM 横幅

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

Alexa排名上升

突然之间，在三月中旬，维基导游（Wikivoyage）又回到了几个月前的最高水平，现在排名在15,000到16,000之间。这很有趣，也许有人能解释一下原因。--评论来自 Selfie City (讨论 | 贡献) 2019年3月19日02:14 (UTC)

维基旅行排名

以防万一之前没提到。因为我们一直将自己与维基旅行（Wikitravel）进行比较；维基旅行在过去几个月/几年里逐渐衰落：[https://www.alexa.com/siteinfo/wikitravel.org] 现在它几乎与维基导游（WV）平起平坐了。所以，我认为我们做得相当不错。干杯 Ceever (讨论) 2019年3月19日12:12 (UTC)

有人会在旧货市场购买旧的旅行指南，所以我猜人们仍然在阅读维基旅行并不奇怪。还有一点也很有趣，在维基导游的读者中，14%来自美国，35%来自接下来的四个国家（德国、意大利、中国、伊朗），这意味着我们的大部分读者不是英语母语者。（你需要订阅Alexa才能了解剩余51%的读者情况）。Ground Zero (讨论) 2019年3月19日12:26 (UTC)

请记住，他们可能不是在阅读我们的文章。他们可能去了[德语]、[意大利语]（原维基导游站点，内容优势远超维基旅行），[中文]，以及[波斯语]。我很惊讶[俄语]不在顶端之列，他们为纪念碑付出了很多努力。

基于此，我认为对于维基导游（WV）来说，WMF应该专注于创建更多的WV语言版本，特别是维基旅行（WT）已经存在的那些版本，因为版本创建得越晚，就越难克服内容差距，尤其是它对搜索引擎排名的影响。尽管如此，我们能做的很少。但是，值得注意的是，维基旅行（WT）的流量中有8.5%来自日本，而[日语]版本仍在孵化中。ARR8 (讨论 | 贡献) 2019年3月19日15:18 (UTC)

维基导游（WV）的Alexa排名刚刚超过了维基旅行（WT）（参见[Wikivoyage:Wikivoyage and Wikitravel]）。维基旅行在美国仍然更大（占英语世界的大部分）。/Yvwv (讨论) 2019年3月23日14:44 (UTC)

我曾在西班牙语维基导游（Wikivoyage）做过一些编辑，但总的来说，我对语言的掌握程度不足以让我能做出重大或自由的贡献。 --评论来自 Selfie City (讨论 | 贡献) 2019年4月1日00:35 (UTC)

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

抱歉，我来晚了……在我们的中文维基导游（Wikivoyage）中，我们拥有比中文维基旅行（Wikitravel）更多的文章和编辑者，但我们的中文维基导游在界面和功能方面仍有待改进。无论如何，我认为日本和韩国（维基导游）应该尽快孵化。毕竟，长期拖延将非常不利于维基导游在韩国和日本的发展。--Yuriy kosygin (讨论) 2019年4月2日18:31 (UTC)

我记得，分叉发生时，日本维基旅行社区是唯一投票决定坚持与Internet Brands合作，而不是迁移到WMF的社区。我上次查看时，他们仍然是一个活跃的社区，并且很高兴留在他们原来的地方。--AndreCarrotflower (讨论) 2019年4月2日23:47 (UTC)

@Yuriy kosygin：不用道歉，我只是指出了中文维基导游（Wikivoyage）文章的现状，并希望有读者看到此讨论并能轻松输入中文进行贡献。 OhanaUnited^讨论页 2019年4月3日03:42 (UTC)

• 在此向大家表示衷心的祝贺。我们在Alexa排名上终于超越了维基旅行（WT） :-) Travel Doc James (讨论 · 贡献 · 邮件) 2019年4月14日17:37 (UTC)

travellerspoint.com 的维基也……

Alexa排名固然不错，但大多数用户可能来自谷歌。最近，当我输入“destination wiki guide”（目的地维基指南）时，上面的页面似乎经常“胜出”。我们的指南通常更全面，所以找出原因会很好……维基导游的一些政策是否会导致相对平庸的SEO结果？--andree.sk(讨论) 2019年4月16日13:57 (UTC)

嗯，那个网站的受欢迎程度已经降到十万名开外了。Travel Doc James (讨论 · 贡献 · 邮件) 2019年4月16日21:11 (UTC)

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

……与我们的营利性竞争对手相比，维基导游（Wikivoyage）实际上做得相当不错。Alexa将我们排在维基旅行（Wikitravel）和Fodor's之上；远远领先于Rough Guides、Frommer's、Travellerspoint、Backpackers.com和Moon Travel Guides；仅次于Lonely Planet和TripAdvisor。我认为这使得与其他网站协同合作的讨论完全超出范围，因为我们唯一可以与之合作（后者两个）的网站都是以商业为基础运营的，因此任何此类合作都会违反WMF的非营利精神。

抄送：Yuriy kosygin 和 andree。

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

Alexa的[旅行指南和目录]类别网站列表将我们排在TripAdvisor、Timeout、Lonely Planet、Tripsavvy、Travelzoo和Ixigo之后，位列第七。我以前没听说过其中一些网站，但深入了解后，它们似乎在少数几个国家非常受欢迎。而且Travelzoo似乎不是旅行指南。还有一个[旅行出版物]网站列表，这些是旅行杂志，内容与我们类似，其中有几个网站目前的排名更高。此外，许多新闻和纪录片网站都有受欢迎的旅行指南部分，如CNN Travel、BBC Travel和National Geographic Travel，但不幸的是，Alexa无法抓取旅行部分的排名（尽管社交媒体粉丝等旁证表明它们比WV受欢迎得多）。

我认为维基导游在许多欧洲大陆国家（德国排名5774，意大利排名2458）和伊朗（排名5273）已接近其受欢迎程度的峰值，但在英语母语国家和亚洲仍有显著的增长机会。美国在WV的排名低于WT，例如在澳大利亚，维基导游不在排名前15位的旅行指南网站之列[]。澳大利亚在线旅行知识的主要来源是“Traveller”，其排名在600多位，但它在其他国家并不使用。它是《悉尼先驱晨报》的一个分支，但拥有独立的域名，所以你可以看出它的受欢迎程度。德国和意大利的维基导游（Wikivoyage）较早分叉，因此它们已经站稳了脚跟。但没有理由说维基导游不能像在意大利那样，在全世界范围内享有盛誉。Gizza ^(roam) 2019年4月16日22:35 (UTC)

我认为重要的是不要将苹果与橙子进行比较。你提到的网站都与旅行有关，但它们本身并非旅行指南，因此我们并非真正与它们竞争。维基导游不是像Timeout那样的“listicle”网站，我们也不是像Travelzoo或Ixigo那样的Expedia式预订引擎，我们不像《国家地理》（National Geographic）那样托管旅行散文或杂志风格的文章，我们也不像CNN或BBC的电视网络上的旅行版块。坦白说，尽管我知道是我提到了TripAdvisor，但我们甚至不能真正与它们相比；我更倾向于将它们视为类似于Yelp或Google Reviews，而不是我们这样的网站。--AndreCarrotflower (讨论) 2019年4月16日23:02 (UTC)

说起苹果和橙子，我认为Tripadvisor不是一个旅行指南，但由于许多人像使用旅行指南一样使用它，所以它值得进行比较。--评论来自 Selfie City (讨论 | 贡献) 2019年4月16日23:39 (UTC)

维基导游是A，其他旅行网站是B。它们与我们不完全相同，但仍然存在重叠。我们最终目标之一应该是成为互联网上大多数人用来了解交叉旅行知识的首选来源。

我们呈现信息的方式与许多上述网站不同，但信息本身在很大程度上是重叠的。从旅行者的角度来看，这是来自不同来源的相同信息。Nat Geo 关于徒步旅行的许多在线内容与我们的行程文章非常相似。就澳大利亚的Traveller而言，它不仅有listicles和旅行新闻文章，还有关于特定目的地的深度指南。BBC有一个旅行技巧部分，其中包含与我们某些旅行主题（如[预算旅行]）非常相似的文章。许多网站都有旅行论坛，其目的与我们这里的[游客中心]相同。我认为与我们相比，大多数网站都是苹果和梨（相似但不同），而不是苹果和橙子（根本不同）。这类似于维基百科，它的竞争对手（因此也受其崛起影响的网站）不仅仅是像Britannica这样的百科全书，还包括其他提供相似信息的通用参考网站。

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

布达佩斯/奥布达（Budapest/Óbuda）的错误

从公告栏扫入

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

我怀疑是模板数量的上限，而不是列表数量的上限。文章底部的某些非列表模板也出现了问题。那篇文章有大量的模板，因为它使用了[Template:rint]和[Template:station]来使所有公共交通信息变得多彩。—Granger (讨论 · 贡献) 2019年4月17日06:46 (UTC)

是的，问题解决了。我已经注释掉了“餐饮”列表中的站点信息。输出错误已消失。--Traveler100 (讨论) 2019年4月17日07:55 (UTC)

这解决了问题，但这意味着我们失去了这些部分中所有列表的方向信息。仔细想想，其他列表中的方向说明也不够清晰（“Remetehegyi út 165”是什么意思？“Remetehegyi út”是车站还是线路的名称？）。令人困惑的是，图标与[布达佩斯]文章中使用的图标不同。最好用更清晰、更具体的文字替换它们。“如何到达”（Get in）部分如果不熟悉布达佩斯的公共交通，也会显得很模糊——它们是地铁线？电车？巴士？—Granger (讨论 · 贡献) 2019年4月17日09:04 (UTC)

为什么对模板有限制？有没有可能为这篇特定文章更改限制？--评论来自 Selfie City (讨论 | 贡献) 2019年4月17日13:41 (UTC)

前几天在[德国]条目里也遇到了同样的问题，我们应该（如果可能的话）稍微增加内存限制（增加1/2？），比如wgLuaMaxTime等？--andree.sk(讨论) 2019年4月18日06:22 (UTC)

我们要联系谁来更改这些设置？--评论来自 Selfie City (讨论 | 贡献) 2019年4月18日13:32 (UTC)

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

从公告栏扫入

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

如果您想推广维基导游，请在[Commons]上提供关于维基导游的视频，或直接上传到YouTube。我将协助上传或在维基导游频道上进行推广，谢谢。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2019年4月17日17:44 (UTC)

关于WikiJournals成为新姐妹项目的提案

从公告栏扫入

在过去的几年里，[WikiJournal用户组]一直在使用Mediawiki平台构建和测试一套同行评审的学术期刊。主要文章类型有：

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

提案：[WikiJournals作为新的姐妹项目]

从维基百科的角度来看，这是一个特色文章评审（Featured article review）的补充系统，但它通过[外部专家]进行衔接，实施[既定的学术实践]，并生成[可引用的、带doi链接的出版物]。

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

对我来说看起来不错。您需要大家在哪里表达意见？另外，有没有涉及音乐的报道，或者打算涵盖音乐？目前涵盖哪些学科？Ikan Kekek (讨论) 2019年6月3日06:03 (UTC)

@Ikan Kekek：此帖旨在广泛发布以征集反馈，因此不仅是那些已经知道该项目的人会发表评论。目前，拟议的姐妹项目有3本英文期刊，采用钻石/铂金开放获取模式（读者或作者均无需付费）：医学、科学和人文学科。未来可以扩展到其他语言，如法语、西班牙语、中文等。作为一名科学人士，我对人文学科了解不多，但音乐可能属于该期刊的范畴。当然，如果将来有足够的投稿以支持一个独立的音乐期刊，那也是有可能的。（全披露，我是WikiJournal of Science的编委会成员之一）。OhanaUnited^讨论页 2019年6月3日23:37 (UTC)

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

OhanaUnited，我的问题性质是我不明白您需要大家在哪里对WikiJournals被维基媒体基金会接纳为姐妹项目一事表达支持或反对意见，我认为这才是公告的意图。在这里发表意见可能没有多大分量。Ikan Kekek (讨论) 2019年6月4日01:15 (UTC)

@Ikan Kekek：讨论的链接实际上是粗体显示的，并写着“提案：WikiJournals作为新的姐妹项目”，它将引导您到Meta页面。OhanaUnited^讨论页 2019年6月4日01:30 (UTC)

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

是的。该提案直到最近几乎获得一致支持，但现在随着宣传的增加，投票结果变得更加两极分化。--评论者： Selfie City（讨论 | 贡献） 14:19, 2019年6月5日 (UTC)

Wikivoyage的YouTube频道需要更多语言管理员

我想添加来自英语和其他语言的Wikivoyage的朋友来管理和上传YouTube教学视频，以便Wikivoyage能够以所有语言进行全面宣传。我们已经有很多中文的视频和直播了，希望频道能加入更多英语和其他语言！

如果您是Wikivoyage的任何语言管理员，我期待您将您的个人G-Mail提供给我，这样我就可以添加您成为YouTube管理员，您将可以上传视频到YouTube频道！每个人都可以点击订阅，谢谢！（见Wikivoyage频道）--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 16:23, 2019年9月30日 (UTC)

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

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

很抱歉，我没有能力或技能水平来帮助。 ShakespeareFan00（讨论） 15:42, 2019年10月1日 (UTC)

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

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

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

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

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

唯一的问题是我有多个G-Mail账户（一个专门用于Wiki）。我想我将使用那个账户；我只是不想混淆账户。--评论者： Selfie City（讨论 | 贡献） 17:53, 2019年10月6日 (UTC)

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

我想您希望将脚本保存在Wikivoyage上？在沙盒中创建一个，然后移到Wikivoyage，我可以看到如何在这里运行此工具。Travel Doc James（讨论 · 贡献 · 电子邮件） 23:41, 2019年10月6日 (UTC)

@Doc_James: 我不知道如何转移到Wikivoyage……就像这样？--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 14:39, 2019年10月7日 (UTC)

已经开始在Template:Videowiki构建一些背景工具。

基本上，您想创建类似这样的东西，关于一个旅行主题，对吗？ Travel Doc James（讨论 · 贡献 · 电子邮件） 19:10, 2019年10月7日 (UTC)

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

好的，您可以先在Wikipedia上创建一个。我会设法弄清楚如何在Wikivoyage上运行它。Travel Doc James（讨论 · 贡献 · 电子邮件） 02:28, 2019年10月10日 (UTC)

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

除非VideoWiki项目仅用于少数维基百科，否则其对任何模板的依赖，特别是英语维基百科复杂的Infobox模块系统，都必须被移除。在全局模板成为现实（这是一个耗时多年的技术项目）之前，像这样的项目必须在“处处可用”或“使用本地模板”之间进行选择。WhatamIdoing（讨论） 17:06, 2019年10月10日 (UTC)

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

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

@SelfieCity: 我已回复邮件给你，我使用Wondershare Filmora，谢谢。--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 13:41, 2019年10月14日 (UTC)

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

需要修复的损坏过滤器

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

我已经删除了您提到的文本。如果删除会以任何方式损害过滤器，则需要有更多知识的人进行修复。--评论者： Selfie City（讨论 | 贡献） 16:58, 2019年10月5日 (UTC)

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

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

@SelfieCity: 你好，我刚意识到过滤器34在第7行也有同样的问题。您能也请修复它吗？另外，供您参考，新的解析器现在在enwikivoyage上也启用了 :) 谢谢，--Daimona Eaytoy（讨论） 16:45, 2019年10月8日 (UTC)

当前OtBPLetchworth State Park的破坏性编辑需要立即关注

尽量用最少的词语说明：我与Powers之间正在进行一场编辑战，Powers大家都知道，他对动态地图的反对和对静态地图的支持已经从强烈变为尖锐，现在似乎到了狂热和破坏性的地步。

几天前，我用一个动态地图替换了Letchworth的静态地图——正如您所见，它没有列出兴趣点，对旅行者来说基本上是无用的。我的编辑被撤销了，理由是公园入口没有在动态地图上标记。然后我撤销了撤销，说明解决这个问题最简单的办法是在动态地图上标记入口（我做了），而不是1）恢复一个对旅行者来说基本上无用的静态地图，以及2）通过缩小动态地图来破坏它，使其不再比静态地图更有用，这部分内容也包含在之前的编辑中。为了我的麻烦，我的撤销撤销又被撤销了。不用说，这种行为是不可接受的，特别是来自Powers这样地位的用户。

从更宏观的角度来看，我们的社区最近能够就使用动态地图和何时使用静态地图的问题达成一项长期的解决方案——分别是在Letchworth这样的底层目的地，以及在地图的细节（国界、城市位置等）很少或根本不改变的区域文章中（这很重要，因为知道如何编辑静态地图的活跃Wikivoyagers人数非常少）。坦率地说，我们之所以能够在之前无法达成共识的情况下成功达成这项共识，很大程度上是因为Powers的编辑历史越来越零散，因此在他不在的时候，我们可以享受他一个人反对动态地图运动的休息时间来推动政策。此外，我们最近还达成共识，除了少数特殊情况外，文章通常只应包含一张地图，并且绝不包含多张包含冗余信息的地图，Letchworth地图的两个情况就是如此。现在，我绝对不会为了一个几乎不活跃且无法接受与他意见相左的共识的用户而重新讨论这些问题，我也绝对不会让一个当前在主页上的特色文章（本月Wikivoyage浏览量最高的文章之一）成为这场冲突的发生地。

通常在这种情况下，最简单的解决方案是将文章暂时保护起来，直到它在主页上展示完毕。然而，由于Powers是管理员/总管，任何级别的文章锁定都不会影响他。考虑到这一点，我提出的解决方案是将文章恢复到它在主页展示时的状态——即，突出且可用的动态地图，无静态地图——并且Powers的进一步干扰将导致部分禁令，仅涵盖Letchworth State Park文章，立即生效（等待十四天的用户禁令讨论来解决会相当没意义），并持续到文章作为OtBP的文章展示期结束。但是，由于部分禁令是一项相对较新的软件功能，在此网站上从未被使用过，我宁愿不单独执行该解决方案。感谢您的反馈，越快越好。

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

我看不出如何在一个总管/管理员的同意下进行用户禁令，因为他们有能力撤销禁令。我的看法是：在所有条件相等的情况下，静态地图就是更好。但是，在这种情况下，显然更好的地图是显示兴趣点的地图，那就是动态地图。我的看法是，如果必须提出用户禁令，那么也有必要解除Powers的管理员身份，这需要一次投票，通常是在Wikivoyage:Administrator nominations，但在这种情况下，我猜是在Wikivoyage:User ban nominations，与主题禁令提案同时进行。Ikan Kekek（讨论） 00:30, 2019年10月15日 (UTC)

Ikan - 我确信对总管/管理员的用户禁令也会阻止他们使用管理员工具，使他们无法自我解除禁令。否则，我去年意外封禁Ibaman和Traveler100（再次抱歉，各位）就不会引起他们所遇到的问题。我不确定对总管是否不同，但我怀疑是这样。-- AndreCarrotflower（讨论） 00:52, 2019年10月15日 (UTC)

好的，如果那样的话，没问题。希望编辑战会停止，我们就不需要再做什么了。Ikan Kekek（讨论） 01:17, 2019年10月15日 (UTC)

在OTBP结束之前，恢复原状。然后我们可以决定是否要“解除Powers的总管身份”。--评论者： Selfie City（讨论 | 贡献） 01:19, 2019年10月15日 (UTC)

SelfieCity - 这不是关于解除Powers的总管身份，那需要单独讨论（也不是这个主题禁令，我刚才听上面有人提到了）。这是关于如何阻止一个编辑者对文章进行编辑，他的用户权限级别使他不受页面保护的影响，无论是半保护还是全保护。如果我们将其视为紧急情况，并在常规用户禁令渠道之外处理，那么我认为保持其范围尽可能窄是重要的；在部分禁令的情况下，Powers将仍然能够编辑和使用管理员工具编辑除Letchworth State Park以外的所有页面。AndreCarrotflower（讨论） 01:23, 2019年10月15日 (UTC)

好的。我当时很忙，没有仔细看你写的东西。我认为我们需要一条规则，规定除非是重要的更正、更新或纠正有问题的编辑，否则不允许对特色文章进行更改。如果有明确的规则和惩罚，我认为这种情况不会再次发生。--评论者： Selfie City（讨论 | 贡献） 01:37, 2019年10月15日 (UTC)

（另外，看了你的帖子：我确实曾经对一个用户使用过部分禁令。）--评论者： Selfie City（讨论 | 贡献） 02:15, 2019年10月15日 (UTC)

同意动态地图在此情况下更好，但谈论封禁一个长期用户，即使是暂时的，我认为对于我所看到的两次撤销编辑且没有在文章讨论页讨论分歧来说，有点过度。--Traveler100（讨论） 05:24, 2019年10月15日 (UTC)

同意以上观点。我没有看到André或Powers试图在任何讨论页上尊重地讨论分歧，这应该是最好、最简单的方式。在这种情况下，任何禁令都是荒谬的，并且会树立一个坏的先例。我鼓励你们两人都谈谈。--ThunderingTyphoons!（讨论） 06:04, 2019年10月15日 (UTC)

我认为没有必要禁令。如果我们确实封禁了任何人，我会说同时封禁两个编辑战用户并未能就此在讨论页上讨论。 Pashley（讨论） 08:26, 2019年10月15日 (UTC)

如果有人给出的编辑理由并非明显违反政策（或明显语法错误、事实不符等），并且您已经编辑了一次该页面，他们将其恢复并给出理由，您的工作就是开始一个讨论页的讨论。据我所知，编辑战的标准是撤销两次。我只会在有人宣传、破坏或恢复我因英语太差而无法真正理解的文本，或明显错误的拼写或语法时这样做——在后一种情况下，我也会在页面或他们的用户讨论页上开始一个讨论页的讨论，解释为什么在我看来他们的编辑显然是错误的，并且可能会推迟第二次撤销一两天。

在我看来，这意味着Powers在这里应该承担更多责任，特别是考虑到我们似乎普遍认为他在此实例中的论点不合逻辑。是的，Andre本可以开始一个讨论页的讨论，但我看不出他在这里开始讨论有什么不妥，因为该页面是特色文章，他想让更多人关注他的立场。这个讨论串可以随时被移到该页面的讨论页。

另一件事是，我认为现在没有人建议任何形式的禁令。这个提议是关于如果Powers继续进行编辑战该怎么做。而那些反对在Talk:Letchworth State Park上没有讨论的人，在我看来，应该把精力放在如果编辑战持续下去该怎么做上，而不是仅仅关注你们偏好的程序。那么你们怎么看？这些撤销编辑是否可以一直持续下去，或者不行？如果不行，你们打算怎么办？ Ikan Kekek（讨论） 09:49, 2019年10月15日 (UTC)

嗯，由于没有进行讨论，我们不知道Powers是否打算继续进行编辑战，或者除了一个编辑摘要之外，他的想法是什么。我认为，如果他继续进行编辑战，那么根据现有政策，封禁是合理的。但我们还没有到那个阶段，因为总共四次编辑并不构成严重的编辑战。

但我们不妨问问他：@LtPowers：您能否就Letchworth的地图参与讨论，或者停止编辑战？谢谢。

为了记录，虽然我同意“Powers在这里应该承担更多责任”，因为André的角色在于维护共识，但我也觉得这次讨论的开启方式（没有ping另一方，并将其描述为“狂热者”而在一整个社区面前讨论封禁他们，而他们却不在场为自己辩护，而且在尝试*直接沟通*之前），这是不恰当的。--ThunderingTyphoons!（讨论） 10:33, 2019年10月15日 (UTC)

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

ThunderingTyphoons! - 我已经清楚地表明，这不是一个孤立事件，而是我们与Powers在动态地图首次引入Wikivoyage时就遇到的一个问题，事实上，我们曾多次尝试与他讨论地图问题，但他的不合理方法总是让我们感到恼火。（尤其是在Wikivoyage talk:Dynamic maps Expedition/Archive 2014-2015上的评论，其中包含许多此类例子，而且看看有多少完全符合标准的星级提名仅仅因为他的反对而搁浅或悬而未决了很长时间，因为他反对动态地图。）如果我认为讨论页的讨论会解决问题，我绝不会提出上述建议，但我现在就可以告诉你，这样的讨论会如何进行：我会被指责竟敢建议删除他花费大量精力制作的地图，被告知动态地图是那些懒得学习如何编辑静态地图的人的“捷径”，不得不听说动态地图上的图标太近了，仿佛解决这个问题不简单地缩放一下即可，以及他一再使用的所有其他吹毛求疵来阻碍问题的解决，仿佛他的观点没有被反复提及和解决过一样。在某个时刻，够了就是够了，我们不再有责任去尝试第5000次地与他讲道理，而是他有责任放手。如果当前的一个特色文章（再次强调，是网站上最显眼的之一）受到威胁，那么这个问题该总决算的时候就是现在。

至于Powers“不在场为自己辩护”：如果他想这样做，没有人能阻止他。我们都不是在某个烟雾缭绕的房间里，没有人能看到发生了什么。这是旅行者酒吧。我几乎想不出比这更显眼、更容易访问的页面来开始这个讨论。如果Powers是管理员和总管，他应该已经将酒吧添加到了他的监视列表，而且如果他足够关心这个问题而反复撤销我的编辑，他就不需要被ping。

Pashley - 你关于“封禁两个编辑战用户并未能就此在讨论页上讨论”的评论没有帮助，而且背离了对编辑战性质及其相关政策的基本理解。事实是，“讨论”早已结束。我们已经就动态地图应在何时以及在何种情况下使用达成了一致。再次强调，这已经成了一个案例，即一个用户拒绝接受一个不符合他意愿的共识，从而越界变成了破坏性行为。（我其实会认为这个界限在几个事件前就已经越过了，但无论如何，任何人都不应再怀疑其行为的破坏性。）任何可能由此产生的编辑战的责任，当然不是平均分配给那些将文章恢复到基于共识状态的人。

ChubbyWimbus - 没有理由相信“编辑战已经停止”。它只是以不寻常的缓慢速度进行。Powers分别花了30和19个小时来回应我在Letchworth文章中的编辑，而距离最近一轮的编辑才过去了16个小时。“万一”仍然是一个很恰当的问题。-- AndreCarrotflower（讨论） 15:20, 2019年10月15日 (UTC)

Andre，我认为你的批评者在很大程度上是正确的。这次小小的编辑战本不必发生，即使发生了，我们也无需用600个字来告诉我们，要成事唯一的办法就是等待一个长期贡献者缺席。

我真的认为你发个像“嘿，Powers和我似乎在哪个地图更好这件事上无法达成一致。你们其他人能做个决定吗？我保证 whatever 你们决定，我都会接受。”这样的帖子就足够了。这件事太小了，不至于让任何人如此烦恼。

很久以前，我的一位同事，他住在一个有很多旅行警告的地方，半夜给我发了条聊天信息，问我是否有时间谈谈一些严肃的事情。我首先想到的是他某个孩子受伤了。但是，没有：他只是睡不着觉，因为他担心维基百科上会因为两个稍微不同的选项哪个更好而发生激烈的争论。这里不要这样。让我们不要因为使用哪个地图而失眠。如果两个编辑无法和气地解决，那就把这个争论推给其他人，把你从监视列表中移除该页面，暗中决定不再参与进一步的讨论，然后让我们来替你处理。没有人会因此丧命。别因为这个毁了我们友好的环境。WhatamIdoing（讨论） 16:03, 2019年10月15日 (UTC)

WhatamIdoing - 我们可能会过分强调“我们友好的环境”。我当维基旅人活跃了快八年了，在这期间的大部分时间里，维基旅人是一个辩论悬而未决、根本性问题多年得不到解决的地方，因为人们“过于友好”而不敢得罪彼此。这让我抓狂。谢天谢地，这种情况终于开始改变了，尽管我们还有很长的路要走，才能真正说我们学会了如何处理被少数声音洪亮的人缠住而无法进展的情况。我们不必变成像维基百科那样充斥着反社会行为的毒沼，但就我个人而言，我认为偶尔吃点亏、偶尔输掉一场辩论，是为了社区顺畅运行而付出的合理代价。-- AndreCarrotflower（讨论） 2019年10月15日 16:11 (UTC)

我不认为我们过分强调了友好的环境。我不介意辩论：那是我的本职工作，然后我去英文维基百科争论如何撰写方针。然而，我确实介意看到小的争执被这样个人化。哪个地图应该放在那个条目上，并不是一个困扰了多年的根本性问题。依我看，如果你决定退让而不是领导攻击，这个问题会解决得更快，头发掉得也更少。

我在英文维基百科上做的事情之一就是处理关于RFC的问题和投诉。多年来我学到的一点是，当有人带着对某些主观问题的抱怨出现时（“问题有误导性！”），这通常意味着“我输了！帮我以技术性获胜！”。从那个角度来看，如果你真的确信共识和方针在你这边，那么你可以立刻把这件事全部交给我们其他人处理，而不必费心贬低对方，也不必试图解释你为什么是对的。如果你真的对了，我们会得出相同的结论，而且当很多人说着同样的话时，比只有一位贡献者重复相同的说法更容易停止争执。你仍然可以采取那种方法。你仍然可以把这件事留给社区。我建议你这样做。 WhatamIdoing（讨论） 2019年10月15日 16:34 (UTC)

WhatamIdoing，我希望你不要再轻描淡写这个问题，假装这只是关于一个条目中的一张地图，并暗示我在小题大做。事实上，这只是Powers多年来不合理行为模式的最新篇章，也是社区对这种行为不合理容忍的最新篇章。我上面已经给出了许多例子，说明这种行为模式在过去 occasions 上给社区造成了问题，而且没有理由期望这种情况不会继续发生。因此，在我看来，通过在这里果断回应，我们有机会阻止这种行为模式在未来无数次重演，而我们可能不得不为此而劳累。最后一点值得重申：我不想像这里其他人一样浪费时间在这场争执上，但如果现在这样做可以避免我们将来无限期地继续纠缠下去，那么我是愿意的。

此外，考虑到这里发生或正在提议的几件事在维基旅人上从未发生过，这次讨论也有必要为这些领域确立先例：即，在一名拥有管理员权限的用户进行破坏性编辑，且文件保护无法阻止他们的情况下，该如何处理，以及何时适合使用部分封禁。这些是单个用户无法单方面回答的问题。如果我能避免“领导攻击”，而是通过既定程序静悄悄地解决它，我会这么做，但这是一种特殊情况。

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

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

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

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

然而，Powers的行为需要被处理，可能需要移除其总督权限（这与封禁或禁止不同）。如果Powers不愿意就此问题接受共识，希望能够以一种积极的方式来处理。如果他能道歉并明确表示他将不再在条目上这样做，那么如果他仍然希望保留总督权限，就绝对应该让他保留。

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

1. Powers在Letchworth State Park条目上的行为是不当的，而且由于该条目是特色条目，这使得情况变得紧急。Powers应该知道，在这样一个重要页面上采取此类行动是不合适的，特别是作为一个总督；此类行动在维基旅人社区内造成了不必要的对立和紧迫感。
2. 由于动态地图已经得到了共识的批准，并已确立为该条目的地图，它应该一直保留到其特色展示结束。然后，其潜在的替代品——静态地图——才可以被讨论。然而，如上所述，在特色条目上采取违反标准的操作是不当的。我们必须坚持共识，尤其是在我们的特色条目上。
3. Powers需要被告知他的行为是错误的，并且他需要明确表示他不会再这样做。

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

SelfieCity，这听起来是一个合理的行动方案，我同意所有这些观点。不过，我更希望暂时不要偏离主题去谈论Powers的取消管理员资格。如果他确实再次撤销我在 Letchworth 的编辑，那将是合乎逻辑的下一步，但这远非迫在眉睫，而且我宁愿不通过推测一个可能无关紧要的取消管理员资格来制造不必要的争端。-- AndreCarrotflower（讨论） 2019年10月15日 20:48 (UTC)

对我来说，这听起来很好，尤其是如果你是这么想的。 --评论来自 Selfie City（讨论 | 贡献） 2019年10月15日 20:59 (UTC)

就像 AlasdairW 一样，我倾向于支持在条目中同时拥有静态地图和动态地图，当两者都能为读者和潜在旅行者提供独特价值时。它们之间的冗余程度并不比两张著名地标的照片高，而在维基旅人的条目中，这种情况相当常见（通常是一张是横幅，另一张是非横幅，但有时两张照片都是非横幅，只是拍摄角度或方式不同）。 Gizza ^(roam) 2019年10月15日 21:10 (UTC)

需要立即关注的争议已经成功引起了社区的注意。也许下次可以少一些戏剧性。用户封禁或取消管理员权限的讨论可以在Ikan Kekek上面链接的页面进行。

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

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

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

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

1. 我同意Powers的行为不够理想，但我认为Powers并没有在维基旅人社区造成任何对立和紧迫感。我认为对立和紧迫感来自于Andre选择的回应方式，也就是说，通过侮辱Powers并继续喋喋不休，而不是中立地报告问题并相信其他人会处理好它。
2. 我不能同意在特色条目上不应编辑。Powers的修改是否构成改进，依我看是可疑的，但讨论应该随时可以进行，而且通常应该鼓励（但不互相编辑）向前推进，即使条目是主页上的特色条目。
3. 我同意Powers需要被告知存在包含动态地图的共识（因为我们普遍同意了这一点，对吗？），当然没有人应该进行编辑战。在另一半的陈述中，确定一个特定的动态地图是否比一个特定的静态地图更好，需要人们运用他们最好的判断。因此，我会认为任何承诺永远不将一种类型的地图替换成另一种类型是不恰当的，而且只勉强可信。我不希望我们强迫贡献者做出“纸面承诺”——就像烤派皮一样容易做出，而且在准备上桌时很可能被打破。 WhatamIdoing（讨论） 2019年10月16日 16:54 (UTC)

（缩进）我现在明白我一开始没有完全理解这个问题。对我来说，即使你试图解释说这是一个持续且常见的事件，这一切似乎是凭空出现的（其他人似乎也发生了类似情况）。我认为我同意SelfieCity的观点。关于 AndreCarrotflower 关于“奖励不良行为”的观点，我补充一点，用户应该避免“我接受两张地图”/“我都可以”/“这个条目不重要，谁在乎”之类的论点。这些不是合法的论点。这可能感觉上能缓和紧张气氛，但这些说法只会混淆视听，阻碍共识，并忽视了这里提出的具体担忧。那些无所谓的人应该支持现状。支持重新引入静态地图的论点需要明确说明这张地图除了动态地图之外还提供了什么好处，以及/或它的删除会失去什么好处。换句话说；包含/重新引入静态地图必须有一个与方针和共识一致的理由。因为对城市/条目/问题的冷漠而说都可以，这并没有帮助，对 Andre 来说也不公平，因为他正在按照共识行事。确实，如果我们基于如此薄弱的基础做出让步，那将是给任何想在未来无视方针的人一个机会，让他们可以引用这次讨论，而我们对此无从辩护。 ChubbyWimbus（讨论） 2019年10月16日 11:39 (UTC)

实际上，我认为所有这些都是合法的论点。如果存在同时拥有两张地图的理由，或者至少不会造成损害，那么我们应该这么说（“我接受两张地图”）。如果两张地图的优缺点势均力敌，那么点出这一点很重要（“我都可以”）。而且，如果社区为了看到一堆侮辱、处理人们的情绪反应以及花费大量时间调查此事而付出的代价，远远高于为了文章拥有一个不算完美但另一张也不算完美地图而付出的代价，那么我们也应该这么说（“不重要”）。我和其他人指出，通过 Andre 洗手，我们其余人只需在 RecentChanges 上安营扎寨几天，就可以轻易解决眼前的“紧急”问题，而不是一个积极参与编辑战的人在这里抱怨一个“不合理”、“狂热且具有破坏性”的贡献者在“为了争论哪个单张地图更好而进行的‘琐碎的吹毛求疵’”上“进行一场一对一的反动态地图的十字军东征”。这是完全合理的。 WhatamIdoing（讨论） 2019年10月16日 16:42 (UTC)

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

WhatamIdoing 和 Pashley - 不。 ChubbyWimbus 所说的关于支持重复地图的论点的非法性，正是如此。我们有一个共识，即动态地图在所有非区域性条目中都受到青睐，条目在大多数情况下应只包含一张地图，并且同一篇文章中不应多次使用地图来显示相同信息。达成这个共识花费了大量的时间和辛勤的工作。而且它是具有约束力的。它不会在你仅仅因为其存在不方便 vis-à-vis 解决一个不相关的争议，或为了不惹事、维持“友好环境”，或因为你个人不同意并/或没有参与建立该共识，或因为你个人不认为在这种特定情况下执行方针很重要，或因为你个人认为与你辩论的对方是个混蛋，或出于任何其他原因而神奇地消失。如果你要为 Letchworth 的重复地图争论，你最好仔细阅读我上面链接的帖子，而且你最好提出支持重复地图的论点，这些论点 1）以前没有被提出过，并且 2）足够令人信服，能够让所有反对过的一方改变主意，或者 3）你最好提出一个非常有说服力的理由，说明为什么 Letchworth 是一个例外，与本网站上其他那些使用一种或另一种地图就做得很好的文章不同。否则，抱歉，但现状偏见适用，本讨论中涉及的关于重复地图的论点应被视为不基于方针。-- AndreCarrotflower（讨论） 2019年10月16日 21:51 (UTC)

我同意 Andre 的观点，尽管我仍然认为，在其他条件相等的情况下，静态地图更好，并且我继续主张在静态地图完整、最新且比动态地图更清晰的任何条目中，对静态地图给予例外。 Ikan Kekek（讨论） 2019年10月16日 22:05 (UTC)

还有，WhatamIdoing，关于我最初帖子的语气：考虑到我们所有人中，只有我一个人还能轻易想起过去 Powers 发生的几次与地图相关的事件。我最初的帖子很大一部分是用来重述冲突的历史，以帮助那些需要被提醒或当时不在场的人，希望大家能将此视为一个正在升级的、持续多年的问题模式，而不仅仅是一个孤立的事件。结果人们仍然那样回应了，这让我更加沮丧。如果因此我显得对 Powers 过分报复和/或总的来说是个爱惹事的人，那很遗憾，并非有意为之，但总比未能将 Letchworth 事件置于其应有的背景下要好。而且，即使许多编辑不记得过去的事件，Powers 的总体行为模式仍然是一个重要的考虑因素。这正是我们存档旧讨论页的原因，而不是简单地删除它们。

另外，如果我在最初的帖子里使用了某些煽动性的语言，我很抱歉，但也要考虑到我是一个有感情的人，我刚刚经历了我基于共识的编辑被连续第二次撤销，而且自从我第一次在 Letchworth 即将成为 OtBP 的最后准备期间将静态地图改为动态地图以来，我一直有种预感，他可能会出现并制造麻烦。所以，是的，我有点恼火，就像任何人都会那样，而且可能在我写的东西的语气中显示得有点太过了。无论如何，任何回复这个帖子的人都应该超越我的用词选择，而是关注我实际传达的问题。而且，最重要的是，不要只见树木不见森林。

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

我认为是时候审视我们在Wikivoyage:Map上的草案方针了，这个草案已经两年了。“我应该用动态地图替换静态地图吗？”这一节似乎与此相关。不过，也许最好在下个月进行，这样我们就不至于过于关注某一个特定的条目。 AlasdairW（讨论） 2019年10月16日 23:04 (UTC)

如果地图不同，它们就不是重复的。我同意 WhatamIdoing 和 Pashley 的观点。说同时拥有两张地图能提高条目的质量，这是一个非常合法的论点。如果两者单独都不够用，被迫选择一个，那么这反而是一个对旅行者不利的论点。我也同意 AlasdairW 的观点，现在是时候审视地图草案方针了。 Gizza ^(roam) 2019年10月17日 00:28 (UTC)

我对这个回复感到困惑。地图为什么不是一样的？-- AndreCarrotflower（讨论） 2019年10月17日 00:32 (UTC)

我们可以很容易地拥有 5 种不同的地图，但这有什么意义能为旅行者服务呢？这不是一个专注于如何绘制某个城市不同方式的地图集。不同地图的真正用途在于显示不同的内容。 Ikan Kekek（讨论） 2019年10月17日 00:40 (UTC)

我倾向于同意 Ikan Kekek 的观点，即在“所有情况都相等”时，静态地图总体上更好，但这种情况很少见，而且在这个条目中，静态地图没有任何地点标记，所以我不认为它可以被说成更好。我绝对不认为静态地图应该总是被删除（我仍然想删除日文区域条目中那些糟糕的动态地图）。WhatamIdoing，拥有既定的共识或方针意味着你不需要处理用户对问题的感情反应。你只需要引用共识即可。我认为告诉用户共识“不重要”是因为他们的问题不是你的问题，这是不公平的。如果一个问题被提出来，而共识突然失效，是因为一群用户决定他们就是不想听你抱怨/他们不喜欢你/他们不喜欢共识/等等，那么它什么时候才有效呢？因为这听起来像是你的论点是“当我在乎这个问题，并且共识与我一致时，共识很重要，但当你们在乎时，无论如何都不重要。” 我不认为这样做会比引用方针或共识更好，或者让用户感觉更好。如我所述，那些真正不在乎的人应该可以维持现状。如果你对此不满意，那么肯定有什么是你非常在乎的。 ChubbyWimbus（讨论） 2019年10月17日 11:36 (UTC)

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

Chubby，我们是否因为某人对编辑感到不满而被迫进行w:en:情感劳动，这个问题完全独立于是否有关于哪张地图最适合该条目的共识。有些事情是我确实在乎的：我不想在这里读到侮辱性的言论。这对我来说很重要。我不想读到让我觉得“哦，他一定认为我们都记不起那场漫长的斗争”或者“他似乎失去了耐心”或者“这听起来他一点也不尊重社区处理哪怕是琐碎问题的能力”。我关心人们如何对待彼此。我们在这次谈话中的表现正在好转，但一开始确实很糟糕。

对于那些记得以前关于地图的讨论的人，你们会记得我非常坚定地支持动态地图。我能够保持这个立场，同时承认它们有一些局限性（例如，不能供离线读者使用，这对于一个将印刷版作为官方目标的社区来说，是一个很大的局限性）。我在这里的关注点更多的是关于我们如何处理争议的“元”问题，而不是地图本身（我相信社区会处理好，而且我们已经处理了）。我希望将来，能够少一些侮辱，少一些纠缠，多一些信任，相信“有共识”意味着你不需要独自承担一切，因为形成共识的人能够而且将会为你处理任何争议。 WhatamIdoing（讨论） 2019年10月18日 16:30 (UTC)

我毫无保留地道歉。首先，为第二次撤销条目以包含静态地图而未先讨论，其次，为延迟回复。

我没有隐藏我有一段时间没在维基旅人上活跃了。但当我惊讶地发现我开始并工作过的条目成为特色条目时，我震惊并沮丧地发现，我花了差不多时间创建的地图在我被添加到特色条目仅一天之前就被随意删除了——而且还附带了一个轻蔑的编辑摘要。我认为未经讨论而全面删除我花费大量时间和精力添加的内容是不合适的。动态地图并非该条目中的一个长期特色（即使现在，它也存在不到两周），所以我觉得有必要恢复到原状，并附上一个编辑摘要，解释动态地图更能显示如何进入。 (Andre 将此解释为“动态地图未显示入口”，但它不仅仅是这样；静态地图还显示了高速公路和步道入口、附近的标志性建筑和社区、高速公路出口等)。作为一种妥协，你会注意到我没有*撤销*删除静态地图的编辑；我重新添加了静态地图，并缩小了动态地图以作补偿。

如果 Andre 不同意这个妥协，他可以讨论。相反，他只是单方面撤销了。我不应该撤销他的撤销，但我仍然认为这是不合适的。而且我当然拒绝“条目当前在主页上为特色，因此一周前进行的编辑是神圣不可侵犯的，不应被撤销”的说法。

当然，这个帖子让我感到震惊。我有点避免冲突（这就是我一直没有回应的原因），而这个帖子并不鼓励我考虑我的时间应该花在哪里。

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

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

回顾几天后，关于我在上述帖子中的表现，我不得不勉强同意一些批评者，我的解决争端和让大家回归共识的决心有时会变成对 Powers 的人身攻击。尽管我们两人在网站相关问题上经常意见不合，而且当我们想要坚持自己的观点时，我们都可能很固执，但我仍然认为 Powers 是我的同事和朋友。仅仅因为我们在 Letchworth 条目上的交流，我不应该忽视这一点。所以，Powers，请接受我对这些事情的道歉。

然而，另一个有分量的人会做的就是必要时让同事或朋友承担责任。在大部分情况下，我仍然支持我的实质性观点。至于你上面评论中的观点：Powers，自从我们推出动态地图功能以来，你就表达了你对动态地图的看法，而且这远不是你第一次与其他编辑就此问题发生冲突，所以也许我“轻蔑的编辑摘要”的原因是因为我忍不住通过那个视角来看待你撤销我在 Letchworth 条目编辑的行为。至于你创建 Letchworth 静态地图所花费的时间，这难道不是一个强有力的论据反对在底层目的地使用静态地图吗？你自己可能愿意捐出大量无偿时间来 1) 学习如何制作静态地图，和 2) 为你工作的每个条目制作单独的静态地图，但有多少其他编辑会这样做呢？我可以用一只手指数过来：你、Ypsilon、Saqib 和 Shaundd；而这四个人中只有 Ypsilon 在这个网站上是偶尔活跃的。让底层目的地条目没有地图，或者（更贴切地说）为它们配备很快就会过时的静态地图，因为没有人知道如何更新或/和有时间去更新，这真的比用一种不太美观但更容易维护的方式呈现相同的信息要好吗？答案是否定的，不仅据我所知，而且根据共识。 （而且如果你真的“一直打算添加第二张地图，显示公园南部仅有 POI 的区域，以更大的比例显示以便阅读”，为什么你在 Letchworth 被提名为 DotM 到它首次亮相主页的 15 个月期间，从未这样做过，特别是考虑到它的地图相关的缺陷已经被指出为问题？）

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

谢谢你，Andre。

为了记录，我提到的编辑摘要来自你最初删除静态地图的编辑，在我重新添加它之前。

确实，“某种地图比没有地图好”，而且过时确实是网站许多领域（不仅仅是地图）的问题。但我不知道 Letchworth 地图中有任何内容确实过时（至少没有显著过时），而且我坚持认为，在没有讨论或铺垫的情况下进行替换（尤其是在它将被放在主页的前一天）是不妥当的。

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

维基旅人的愿望清单提案

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

我有一些关于我们去年考虑过的两个想法的笔记

• 为维基旅人画册播放内嵌音频：想象一下，能够阅读画册，点击一个按钮，就能听到单词的发音，而无需离开页面。(phab:T20852) 这对维基词典也可能很有趣。
• 进一步的地图改进：争议性边界（phab:T113008）是其中之一，但我们或许可以考虑几项地图改进。

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

我认为最需要的增强功能是动态地图上标记当前位置。这对于现在大多数是移动用户进行网络访问的旅行者来说至关重要，因为了解你附近有什么是任何旅行/地点指南的关键功能。（phab:T208713） --Traveler100（讨论） 2019年10月21日 17:47 (UTC)

地图定位功能应该相对容易（我天真地认为），因为移动版已经能找到附近地点的条目了。

难道内嵌音频文件在同一页面上不是已经实现了吗？维基词典上肯定有内嵌音频文件，例如。难道这个功能就这么被我们错过了？ --ThunderingTyphoons!（讨论） 2019年10月21日 18:03 (UTC)

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

简单地使用维基词典上的系统有多难？ --ThunderingTyphoons!（讨论） 2019年10月21日 19:41 (UTC)

我猜它足够难，以至于我们没有弄清楚？ WhatamIdoing（讨论） 2019年10月22日 15:30 (UTC)

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

如何能够重新定位动态地图，而不仅仅是严格地向上是北，向下是南？在曼哈顿的地图上，向上应该是“uptown”，而不仅仅是罗盘上的正北。然而，我不同意我们应该显示“争议性边界”。这违反了维基旅人的方针，即承认所有合理稳定的既成事实，并且不介入争议，除非它们影响到旅行者。 Ikan Kekek（讨论） 2019年10月21日 19:59 (UTC)

看看像中国（地区）或日本这样的动态区域地图。每个县或地区的阴影区域包括领海，因为这代表了管理边界的 OSM 关系。不幸的是，这相当难看，与静态地图相比，静态地图只是显示属于每个县的陆地。据我所知，没有 OSM 实体代表这个；你需要以编程方式计算它。--Bigpeteb（讨论） 2019年10月21日 22:41 (UTC)

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

哎呀……我创建了一个关于通过地图添加景点地图，以帮助游客通过地图查找附近景点和信息的任务，但不是第一个在这里的旅行者论坛上讨论的，我真的很抱歉……--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 13:46, 2019年10月27日 (UTC)

• 能不能提供一种直接在地图形状上绘制多边形（形成区域和地区）的方法？--评论自 Selfie City (讨论 | 贡献) 01:51, 2019年10月22日 (UTC)

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

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

我非常赞同！而且我以前用安卓手机时，用户界面也很糟糕，对iPhone来说就更糟糕了。 Ikan Kekek (讨论) 23:44, 2019年10月24日 (UTC)

页面横幅的移动端显示怎么样？这是我们可以在内部修复的，还是需要MediaWiki软件的更改？--ThunderingTyphoons! (讨论) 12:43, 2019年11月9日 (UTC)

截止日期是周一

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

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

（“本地时间评论”脚本并非专门针对Wikivoyage（它可能对任何项目都有用），所以可能会被声明为范围外。其他建议都针对Wikivoyage，但任何建议都有可能被认为太大而无法由该团队完成。）

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

• 我已添加请求，使“Wanted Pages”仅显示来自主文章命名空间的红链接结果。--Traveler100 (讨论) 06:21, 2019年11月10日 (UTC)

第一本旅游指南

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

从图片上看，这更像是一本插画地图集，而不是一本旅游指南，但仍然是一份迷人的历史参考资料。 --评论自 Selfie City (讨论 | 贡献) 19:27, 2019年10月22日 (UTC)

确实很有趣。谢谢分享。

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

Beta 功能“参考文献预览”

一个新Beta功能很快将部署到您的维基：参考文献预览。从名字可以看出，这个功能可以预览文章中的参考文献。这意味着，您无需跳转到页面底部即可查看参考文献。

参考文献预览自4月以来一直是德语和阿拉伯语维基百科的Beta功能。现在它们将在更多维基上提供。部署计划于10月24日进行。更多信息可以在项目页面上找到。

一如既往，我们非常重视您的反馈。如果您想测试参考文献预览，请在您的用户偏好设置中激活Beta功能，并告诉我们您的想法。反馈的最佳地点是中央讨论页。我们希望该功能能帮助您更好地工作。来自Wikimedia Deutschland的技术愿望项目，感谢您。

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

你好，Johanna，欢迎来到Wikivoyage。我认为ref标签在Wikivoyage上几乎完全没有使用。可能没有必要为此项目发送更新。（我不知道是否值得为此更改整个邮件列表……） WhatamIdoing (讨论) 17:30, 2019年10月23日 (UTC)

更重要的是，它们违反了本站的外部链接指南。 Ikan Kekek (讨论) 17:35, 2019年10月23日 (UTC)

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

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

基于应用程序的送餐服务、小费以及《美国美食》文章（如果您是住在国外的Wikivoyager，这篇文章适合您）

我最近兼职做GrubHub司机，在《美国美食》文章中，我关于使用送餐App（比如我的，情况比给披萨送货员2-5美元现金要复杂一些）的小费习惯有几点看法。我想在《小费》文章中也加入同样的信息，但问题是，我不确定我说的适用于全世界，还是仅限于美国。我猜想在小费习惯与美国非常不同的国家，基于应用程序的送餐服务可能运作方式不同。是否有住在国外的Wikivoyager有使用这些App的经验，可以证实他们本国给司机小费的程序？如果没有，是否应该将此信息添加到《小费》文章中，即使带有免责声明，说明它仅适用于美国或北美？-- AndreCarrotflower (讨论) 14:26, 2019年10月26日 (UTC)

在中国，小费很少见。我从未见过有人给送餐员小费，而且我使用的两个送餐App都没有添加小费的选项，至少据我所知是这样。——Granger (讨论 · 贡献) 15:04, 2019年10月26日 (UTC)

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

Uber和Lyft的司机倾向于现金小费。Grubhub司机也一样吗？ Ikan Kekek (讨论) 18:11, 2019年10月26日 (UTC)

虽然在英国，基于应用程序的手机订餐很普遍，但我不是常客。Just Eat表示只有三分之一的顾客会定期给小费，并且给司机的提示是他们可能不会要求小费。 AlasdairW (讨论) 21:22, 2019年10月26日 (UTC)

这都很有趣。我无法声称有其他App的亲身体验，但在美国，GrubHub实际上让不给小费变得非常困难。该App的默认小费为20%；任何想取消小费的人不仅必须手动将其更改为零，还必须点击一个令人产生负罪感的“确定吗？”弹出窗口，解释“司机是GrubHub最不可或缺的资产”之类的。听起来，即使其他国家的送餐App可能提供给司机小费的方式，它们可能也不会如此坚持，所以我在《美国美食》中添加的建议可能不适用于非国家特定的《小费》文章。

Ikan Kekek - 我猜如果你去调查GrubHub司机，你可能会听到他们对现金小费的轻微偏好，但GrubHub App处理小费的方式与Uber/Lyft相比，这就像是在比较苹果和橘子。对于Uber和Lyft，小费是在行程结束后发生的（或不发生）；如果潜在乘客的星级评分很低，司机可能会将其解释为他/她可能是一个糟糕的小费者，但这并非万无一失，而且星级评分可以基于任何因素。对于GrubHub，小费是提前支付的；司机在收到送餐订单时就会知道客户给了多少小费，然后根据该信息决定接受还是拒绝。App中有一个“备注”部分，客户可以在其中说明是否打算给现金小费，但司机不一定会读，司机们普遍认为零小费就是零小费，而不是现金小费的意图。

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

我认为英国的App默认没有小费。一位常用者抱怨说，该App无法设置默认小费，每次都需要选择。我们可以提供针对不同国家司机小费的具体建议，并说明司机的收入来源。在英国，给司机小费可能比给服务员更有理由——服务员是雇员，必须按每工作小时支付最低工资，但App的司机通常是“自雇”的，按次计费。 AlasdairW (讨论) 13:41, 2019年10月27日 (UTC)

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

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

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

在本通讯中，编辑团队讨论了他们在移动端可视化编辑器、新讨论页项目以及2019年维基百科大会上的工作。

帮助

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

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

讨论页项目

“讨论页咨询”是一项全球性咨询，旨在为维基交流定义更好的工具。从2019年2月到6月，20个维基上的500多名志愿者，使用15种语言和多个项目，与基金会成员一起为一系列讨论工具制定了产品方向。讨论页咨询的第二阶段报告于8月发布。它总结了团队已开始着手的产品方向，您可以在此处了解更多信息：讨论页项目页面。

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

移动端可视化编辑器

编辑团队正致力于简化移动设备上的编辑过程。团队正在改进移动端可视化编辑器。如果您对在移动设备上编辑有任何意见，请在Talk:VisualEditor on mobile留言。

编辑卡片

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

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

工具栏

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

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

维基百科大会

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

展望未来

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

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

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

关于文字编辑探险队的提案

我认为我们在文字编辑方面还有很大的改进空间。一些修复（例如我正在进行的与不当逗号使用的斗争，这可能有些人已经注意到了）可能需要手动完成，但其他修复，如拼写错误纠正，可能可以借鉴维基百科拼写错误团队的自动化和半自动化工具，我认为最好有一个探险队来研究这个问题。我们还可以实现一些WV特有的修复，例如纠正格式不正确的电话号码。我无法承诺保持探险队的活跃（我没有那么多空闲时间），但我认为有一个专门的空间供我们寻找更系统的方法来清理所有可能因未解决的小错误而使WV显得不够专业的方面，这是一个好主意。 Sdkb (讨论) 07:15, 2019年10月30日 (UTC)

如何吸引女性独自旅行者，美国最大的市场

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

他们好像采访了七名女性，然后告诉你“FSTs”做了什么，报告了百分比之类的。我错过了什么吗？你不需要一个大的随机样本就能获得有趣的观点，但如果你想知道像这样的一群人是怎么想的，一个好的代表性样本会有很大帮助。--LPfi (讨论) 20:45, 2019年10月30日 (UTC)

黑客攻击尝试？

几分钟前我收到通知，有人试图从新设备登录我的账户失败了。我建议大家确保您拥有一个强密码，并且任何熟悉安全问题的人，请以您惯用的方式监控情况。 Ikan Kekek (讨论) 21:44, 2019年11月3日 (UTC)

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

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

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

Wikivoyage 是否支持双因素认证？我知道维基百科支持，但它仍仅限于管理员。 Sdkb (讨论) 18:26, 2019年11月4日 (UTC)

我相信“2FA”对WMF托管的任何项目上的管理员都可用。另外，对于非管理员来说，也有一些变通方法，如果有人真的想要的话。 WhatamIdoing (讨论) 03:03, 2019年11月5日 (UTC)

我不担心有人会破解我的密码，但我觉得有必要提醒大家有人在尝试。 Ikan Kekek (讨论) 20:51, 2019年11月8日 (UTC)

关于Wikivoyage维护项目的一个想法

正如所见，有时很难保持Wikivoyage信息的最新。Wikivoyages之间的互动应该有助于保持这些更新。这是我的想法，希望能有所帮助。而且它可以朝任何方向工作（请理解为Wikivoyage的语言版本）。应用程序将提供以下功能：

1. 应用程序搜索英文Wikivoyage中包含一个列表的页面，该列表的更新日期晚于某个日期或从未更新过。
2. 应用程序“保存”为“笔记” 名称、alt 和 lastedit 参数。
3. 应用程序搜索其他语言版本（通过Wikidata进行互维基搜索），其中 name 或 alt 与上述元素最接近，并且 lastedit 晚于我们的。最差情况下，它会在包含该元素的节中搜索文本。
4. 应用程序会显示各语言版本列表的发布者以及其他语言元素（列表或节）的源代码。
5. 我们根据这样比较阅读的内容更新元素并保存。

这是我们可以完成的工作的总结。您怎么看？ ？是的，我们有想法，但要实现它们，人就少了。但想法是拥有一个结构良好的项目，并推进提交给“程序员”。 Crochet.david (讨论) 11:18, 2019年11月11日 (UTC)

能够比较其他语言上的类似列表的想法听起来很有趣。必须是交互式比较，并且用户可以选择要传输的内容。也许与列表编辑器中的同步到Wikidata的选项类似。另外，而不是在页面上进行交互式运行，这可能非常不经常给出任何有用的结果，为什么不进行全站的批量运行，并用一个标签（和类别）标记任何候选列表，该标签只有在启用ErrorHighlighter工具时才可见（类似于我们对待死链的方式{{死链}}）。--Traveler100 (讨论) 18:21, 2019年11月11日 (UTC)

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

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

此时我们仍然需要人工翻译，因为计算机翻译仍然很生硬。一些习语和其他表达方式非常难以翻译，甚至可能在其他语言中没有等价物。我的日语远非流利，即使在我这个水平上，我仍然能够发现并纠正一些谷歌翻译造成的错误，所以自动化翻译在不同语言版本的WV之间成为现实还有很长的路要走。 The dog2 (讨论) 05:29, 2019年11月13日 (UTC)

同意。作为一名多语者和翻译者，在我看来，机器翻译是不可行的。直到机器翻译程序能够一贯地纠正基本的语法规则，更不用说捕捉到人类语言中包含的所有细微差别、生动的习语和隐喻，还有很长的路要走。-- AndreCarrotflower (讨论) 14:59, 2019年11月13日 (UTC)

我认为，列表的定性信息（即“内容”字段中的文字描述，以及在适用情况下“方向”字段）在可预见的未来都需要由人工翻译。我确实认为值得探索的是，正如Andree (SK)所建议的，德国人已经在做的，我们是否能让“定量”信息（即地址、电话号码、网站、价格等）在Wikivoyage的不同语言版本之间更容易共享。我们已经使用Wikidata来快速共享POI的经纬度（虽然结果好坏参半，取决于我们与Wikidata的优先级差异，或者我们与百科全书的差异），所以值得考虑我们还能自动化什么来提高我们有限的人力效率。

作为与Andre (NY)的第一句话无关的题外话，我很高兴地庆祝我们拥有一个极其多语言的社区，即使与英语维基百科相比，其编辑者人数也多得多。--ThunderingTyphoons! (讨论) 15:53, 2019年11月13日 (UTC)

TedX：如何对抗过度旅游

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

我真该早点看这个的！讲得真棒，而且他有一些很有趣的想法！

它引发的问题是，Wikivoyage 在像他提出的 #honestlamp 这样的事情上应该持什么政策？他所做的类似于我们写“欣赏可爱的铸铁雕塑，记得摸摸它右边的灯笼以获得好运和财富。” 我们现在可以这样写吗？即使它是一个只有不到一年历史的现代“传统”？鉴于 WV 不是 WP 并且我们的 语气 不同，我们肯定可以 不 说“过去有一种在艺术品上挂锁的传统，但现在……” 这样做，使用我们自己作为一股积极变革的力量，就像他用 #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)

附近也有城市，如 帕多瓦，许多人住在那里以节省一些钱并前往威尼斯进行一日游。它们也有值得一看的景点。我观察到 威尼斯 指南中，还有许多可以列出的景点，这仅仅是我看了像 Commons 用户 Moroder 这样的人拍摄的大量照片得知的，并且最好在这个网站上按区域划分威尼斯，这将有助于推广圣马可广场等核心旅游景点之外的区域。我自己从未去过威尼斯，所以我不会在这方面起带头作用，但这就是我认为理想的情况。现在，至于不说明某个城市的主要景点是什么，如果游客不知道，尤其是如果他们时间有限，这将是对 锡耶纳 游客的一种错误。很多主要景点之所以成为主要景点是有原因的。如果你喜欢艺术博物馆，去巴黎，你至少应该去一次卢浮宫，如果不是 2-3 次的话；如果你去佛罗伦萨，你不想错过看大教堂，或者在奥特拉诺一侧的一个观景点看风景；等等。其他主要旅游景点是旅游陷阱，但你仍然可能想看一次。我会把时代广场和好莱坞星光大道归入这一类。旅行指南的存在不是为了阻止旅行，所以虽然我们应该以公平和有益的视角来呈现一切，但如果我们不考虑人们为什么旅行以及他们为之旅行什么，我们就可以考虑放弃，转而告诉人们旅行对环境有害，他们应该在家中寻找有趣的事情。 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 %。印度和德国的数值更稳定。正常的年度临时变化也无法解释这种行为。也许 Wikitravel 可以改善其美国排名。不幸的是， Wikivoyage 的知名度仍然很低。大部分流量来自搜索引擎和维基百科，而不是直接访问或其他网站。社交媒体也无济于事，因为使用率很低。 Wikivoyage 的可见性提高肯定会有帮助，但我不知道如何做到这一点。 --RolandUnger (讨论) 2019年11月20日06:28 (UTC)

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

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

旅游网站的流量通常在北秋季下降。Wikivoyage 的全球 Alexa 排名下降幅度并不比往年更糟。此外，另一个网站（Wikivel）已不再是相关的竞争对手。 /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 的员工来插话。 :) 有可能 wikivoyage.org（门户网站）的流量有所减少，但实际的语言版本没有。 IMHO，这稍微不那么令人担忧。 这是英语 Wikivoyage 的统计数据，显示自 2019 年初以来，页面浏览量有所增加！而 来自美国的英语 Wikivoyage 流量 占了绝大部分。这在一段时间内也相当稳定。这并不是说我们不应该关注和担心，而是为了提供一些情境上的缓解（希望如此！）。

也有可能，贡献了 超过 95% 流量（因此极大地影响了 Alexa 排名）的谷歌，正在做一些不同的事情。 CKoerner (WMF) (讨论) 2019年11月20日17:35 (UTC)

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

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

确实，我们不打广告。Wikivoyage 可以并且确实自我推广和提高知名度的唯一地方是其他维基媒体网站。编辑马拉松（以庆祝我们的五周年纪念）取得了适度的成功。许多人是第一次来到该网站，一些新编辑在不同程度上留了下来。就任意统计里程碑而言，我们即将突破 30,000 篇文章。也许我们应该请 WMF 在页面顶部发布一个方框，突出这一点，并包含一个指向主页的链接。虽然让人们编辑很好，但让人们阅读我们最好的内容会很棒。 Gizza ^(roam) 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 所建议的，购买谷歌搜索广告的成本是多少？原则上我喜欢在维基媒体泡沫之外进行广告宣传的想法，但我的担忧是它的实用性如何。WMF 如果我们将这个想法作为一项提议，会问的第一个问题是“这需要多少钱？” --ThunderingTyphoons! (讨论) 2019年11月27日18:21 (UTC)

只要我们与 WMF 达成一致，并且广告宣传有潜在效果，我会支持这个想法。 --来自 Selfie City (讨论 | 贡献) 2019年11月27日18:46 (UTC)

• 另外，虽然我知道一个人不太可能显著改变网站排名，但有一段时间我非常活跃于此，有时几天就能做出数千次编辑。自从我不再像以前那样活跃于 Wikivoyage，尤其是在最近几个月，排名就明显下降了。有没有可能存在联系？或者即使一个用户的影响力不够大，也不能使美国排名仅提升一千多名？ --来自 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 提供了更多信息。例如，按受众重叠划分的相似网站以及链接到的网站。很明显，WV 在链接网站方面远远落后，除了其中一个链接是维基百科（92% 来自字典和百科全书，其中维基百科当然是首位的）。 Elgaard (讨论) 2019年12月4日16:55 (UTC)

如果你查看谷歌趋势 Wikivoyage 与 WT 的对比（），你会注意到 WT 在除委内瑞拉之外的所有地方的搜索量都比我们高。有些国家是灰色的，但似乎 WT 在 100 多个国家都胜过 Wikivoyage。我们受益于维基百科的链接，但除此之外，我仍然觉得 WV 在许多方面落后于旧网站。 Gizza ^(roam) 2019年12月11日23:27 (UTC)

实际上，在五年的趋势中，我们取得了对他们的进展。2014 年，WT 的搜索量是我们的 20 倍，而现在仅是我们的 8 倍。这部分可以归因于 WT 的衰落而不是我们变得更受欢迎 。当你比较 Wikivoyage 和 Lonely Planet 时，2014 年 LP 的搜索量是 WV 的 30 倍，而现在是 20 倍。所以可以说取得了适度但非实质性的进展 。 Gizza ^(roam) 2019年12月11日23:33 (UTC)

关于 WikiTravel vs WikiVoyage：可能与 Alexa 排名完全无关，但今年早些时候，我去秘鲁、玻利维亚和智利旅行时，开始使用 WikiVoyage，但后来切换到了 WikiTravel，因为他们的覆盖范围更更新、更广泛（即，他们包括了 WikiVoyage 没有内容的城镇）。我相信这其中有原因，但我目前正在东南亚旅行，还没有准备好进行讨论（这本身也是一个单独的主题/帖子/章节）。我回家后的几个月（或更长时间）再开始一个新讨论。也许与谷歌搜索结果有关（我不知道那些如何影响 Alexa。现实是 WikiVoyage 应该远远领先于其他网站，例如 TripAdvisor 经常出现在谷歌搜索结果中，但每次我查看时，它都相当无用，而且他们宣传的“旅游”完全是个笑话。 PsamatheM (讨论) 2020年1月2日15:50 (UTC)

感谢你的更新 @PsamatheM:。你还记得 Wikivoyage 覆盖范围薄弱或不存在的城镇的名称吗？我们应该优先填补这些空白。 Gizza ^(roam) 2020年1月8日05:05 (UTC)

@DaGizza: 我正在旅行，使用“不稳定的”网络，并且只有一台平板电脑。所以现在回复简短（且未经核实）。记忆中，例如，我在特鲁希略（秘鲁）走了很多路，出了很多汗（很热），因为巴士信息糟糕透顶（相关巴士公司在中央巴士站没有售票处，所以需要走很多路，走很多路）。当我访问哈乌哈（秘鲁）时，WV 没有相关页面（而哈乌哈是一个相当惊人的地方，有巨大的 Tunanmarca 遗址、Canoncitos de Pichiluli 等）。但即使现在，与 WT 相比，WV 的页面也非常差。不准确的信息会导致旅行者遇到麻烦，这是迅速让人们远离该网站的保证方式。我刚到秘鲁不久就放弃了更新 WV，当时我发布了一个很棒的旅游信息（我做过的，免费的），但“政策警察”却删除了它，然后是无休止的讨论试图达成共识，我相信这个列表被恢复了，但“生活太短了”，而且只为一条列表就这么做简直是闹剧。我实际上对 Wikipedia、WV 等项目有很强的信念，但我认为 WV 需要大大重新考虑其态度。我正在准备我的想法，但要等到我回家才能开始发布，并且能够恰当地参与任何可能引发的讨论（当然，它们可能什么都不会引发）。PsamatheM (讨论) 2020年1月9日07:44 (UTC)

我同意，对新编辑甚至半经验丰富的编辑来说，存在过度的指责，以及对许多政策的盲目遵守，这些政策不一定能从长远来看改善 Wikivoyage。我们*确实*需要从维基百科采用的一项政策是：“如果一条规则阻碍了你改进或维护维基百科（或在我们的情况下是 Wikivoyage），**忽略它**。” 请参阅 wikipedia:Wikipedia:Ignore_all_rules。很多时候，编辑只是被撤销，甚至没有在编辑摘要中解释，更不用说给善意的编辑者一条个人消息了，他们会觉得自己被跟踪了，不受欢迎。 Gizza ^(roam) 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)

我已大幅扩展了 哈乌哈 文章，改编自维基百科文章。你能看看吗？根据你的经验，随意添加/删除/改进我的贡献。有你的帮助，以及从维基百科有选择地借鉴，我们可能会得到一篇不错的文章。谢谢。 Ground Zero (讨论) 2020年1月10日04:39 (UTC)

两个方面。

1. 我并非在批评这篇文章，而是将其作为一个例子，说明在 WT (Wikitravel) 上有很好的报道，但在 WV (Wikivoyage) 上（当时）完全没有相关页面。（这也是为什么我当时放弃将 WV 作为旅行秘鲁、玻利维亚和智利的旅行信息来源的几个原因之一。）

2. 我只有平板电脑、手机和不稳定的网络，在返回（可能很多个月后）之前无法撰写文章。这可能违反规则，但请特别查看我的个人网站上的帖子：https://psamathe.net/tag/jauja/。Tunamarca 是一个非常重要的景点。Cañoncitos de Pichiluli 令人惊叹。那里没有旅游团，因此 WV 上的信息就变得更加有用。这两个景点都靠近城镇，可以包含在城镇的文章中。Pueblo Viejo 本身不足以专门游览，但在你步行前往 Cañoncitos de Pichiluli 的途中经过它也值得（但你需要 GPS 坐标，因为没有明确的“路线”，只有一个好的起点和当地农民和牧羊人使用的路径网络）。

因此，目前（由于我目前“旅行途中”的状态）我不得不将文章的任何工作转交给您（或其他人）。您可以随意从我的个人网站获取任何信息/文本，我允许您获取任何照片（可以直接上传到 WV 或 Commons（尽管请注明来源为 psamathe.net - 尽管它们只是我打算稍后上传的几张照片，并且我会从原始文件中导出，所以质量/分辨率会更好（但更侧重于信息而非摄影完美）。如果您需要任何详细信息或信息，请告诉我（但我手头没有原件）。如果我看起来懒惰没有自己完成工作，我很抱歉，但如果您/有人能完成大部分工作，我想我只需要做一些微调的工作。PsamatheM（讨论） 2020年1月10日 05:13 (UTC)

此外，@Ground Zero:，乘巴士抵达方式的详细信息在页面底部：https://psamathe.net/jauja-southern-sierra/ PsamatheM（讨论） 2020年1月10日 05:29 (UTC)

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

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

Ikan Kekek，英文维基百科目前处理“忽略所有规则”的问题，主要是口头上承认，然后严格执行规定，与政策相悖。当这种情况出现时，通常会有相关的讨论。在最佳情况下，这与我们如何决定不受管制的事务没什么区别，例如一个特定的餐厅/酒吧组合企业是否应列在 ==用餐== 或 ==饮品== 下。 WhatamIdoing（讨论） 2020年1月11日 22:13 (UTC)

谢谢你的解释，WhatamIdoing。所以我不确定在这里拥有类似的政策是否会带来任何改变，除了造成混乱。你同意吗，还是你认为这在某种程度上会很有用？ Ikan Kekek（讨论） 2020年1月11日 23:19 (UTC)

我猜它有可能将“我们是否真的可以封禁这个人，尽管技术上没有明确的封禁政策类别？”的讨论次数从每年两次减少到一次，这可能是一个小小的胜利。 WhatamIdoing（讨论） 2020年1月12日 04:07 (UTC)

我不确定这是如何实现的。 Ikan Kekek（讨论） 2020年1月12日 05:08 (UTC)

通过用“我决定‘忽略所有规则’并封禁该用户”这句话取代关于是否可以封禁用户的冗长讨论。这并不能阻止所有人，但可能会阻止其中一些人。 WhatamIdoing（讨论） 2020年1月13日 16:55 (UTC)

这更像是一种价值观或原则，而不是一项政策。再考虑一下，WV:旅客优先涵盖了类似的内容，所以这里可能不需要。 Gizza^（roam） 2020年1月14日 08:36 (UTC)

我同情。我曾经历过同样的事情，当时我在柏林列出了一个旅游项目。我们很乐意列出酒店和其他商家，但不知何故，旅游项目却被禁止了。我们的政策不一致，这非常令人沮丧。随便拿起一本人们花大价钱购买的旅行指南。你会看到酒店、旅游项目和其他商家被列出，只要它们对旅行者有用。我们似乎做出了某种不一致的纯洁誓言，这损害了本项目的基本目标。 @PsamatheM: Marvin The Paranoid（讨论） 2020年1月26日 15:44 (UTC)

PsamatheM提到的秘鲁徒步旅行就是导致需要进行讨论并最终对徒步旅行项目进行全站例外处理的原因，所以尽管 PsamatheM 的经历可能令人不快，但它确实促成了一项可能永久性的改变（指南的修改已在一年多前完成，并未引起任何混乱，所以尽管并非所有人同意，但不太可能被撤销）。

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

只要旅游项目构成增值活动，就可以在 Wikivoyage 上列出。如果旅行者可以在不参加该旅游项目的情况下完成旅行的核心内容，则该旅游项目不应被列出。

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

实际上，这项政策禁止列出大多数音频导览和有导游的旅游项目，因为此类旅游项目的核心内容通常可以通过独立旅行者完成，而且此类旅游项目提供的信息最好应包含在相应的 Wikivoyage 文章中。

这项政策的另一部分是你可能不记得了，因为它发生在很久以前，但当时我们允许列出旅游链接时，像佛罗伦萨这样的文章里充斥着垃圾般的旅游链接和列表。本网站的共识至今仍认为，我们指南的目的是使独立旅行者能够游览我们所涵盖的目的地。任何更喜欢参加打包旅游的人可能不需要这个网站，并且不会在寻找这类旅游项目时遇到困难。此外，我们根本没有读者群和专业知识来尝试我们以前为这类列表所做的尝试，那就是判断哪些旅游项目好，哪些纯粹是骗钱的。

话虽如此，但对指南和政策的例外情况总是可能的（当然，除非涉及法律要求），但必须在相关的文章讨论页上进行论证。如果你想改变整个网站的旅游列表政策，你可以随时在Wikivoyage 讨论:列表上开一个帖子，看看是否能说服共识同意你的提议。无论结果如何，都会有人不满意，这就是事实，也是为什么有这么多不同网站的原因——这是一个广阔的互联网世界。 Ikan Kekek（讨论） 2020年1月26日 16:12 (UTC)

感谢你的解释和历史。很高兴知道这方面已经取得了进展。我很久以前就编辑了，那时我还是 WV 的新手，我不知道讨论可以用来为我保留它提供论据。 --Marvin The Paranoid（讨论） 2020年1月26日 16:39 (UTC)

我们应该把这一点说清楚。我想知道在哪里开始讨论，以及如何更清楚地说明，除了法律要求之外，所有政策和指南都可能在有令人信服的论据导致共识时，根据具体情况进行例外处理。我们一直都是这样运作的，但也许也有人会反对“逐案例外”的想法。 Ikan Kekek（讨论） 2020年1月26日 16:44 (UTC)

我倒觉得可以在Wikivoyage:旅客优先页面上加一条： “社区可能在特定情况下达成共识不适用某项政策，如果适用该政策会损害旅客的利益。” Powers ^(讨论) 2020年1月26日 18:49 (UTC)

措辞很好，尽管讨论机制可能需要详细说明。我们将在Wikivoyage 讨论:旅客优先上讨论此事。我现在就开启讨论串。 Ikan Kekek（讨论） 2020年1月26日 18:55 (UTC)

Ikan Kekek，去年我在秘鲁独自旅行时，在北部沿海地区，我参加了组织的旅游团，因为没有公共交通，而且出租车的费用远远高于旅游团（独立旅行者可以乘巴士到镇上，也许再打车，可能需要过夜，但所有这些都显得很荒谬，因为一个有组织的旅游团可以以更便宜、更便捷的方式提供交通）。旅游巴士会到达景点，我会问司机或导游他们什么时候回去，然后说“回头见”，然后我就会自己逛——利用他们作为交通工具，但这是一个有组织的旅游项目。在上述“徒步旅行”的麻烦之后，我放弃了为 WV 添加任何内容的想法，但我是否可以通过列出有组织的旅游项目来逃脱，因为其交通成本比替代方案便宜得多？还是会引发另一场复杂的讨论…… PsamatheM（讨论） 2020年1月26日 16:52 (UTC)

当然，在此基础上可以。在各种文章中都有以交通工具为基础的旅游巴士列表。我很抱歉你放弃了为 Wikivoyage 添加内容，因为你发布的一个列表引起了政策的改变；你还能要求什么更快的响应？ Ikan Kekek（讨论） 2020年1月26日 17:54 (UTC)

这是关于对规则做出例外的讨论串：Wikivoyage 讨论:旅客优先#对规则的例外。请查看并评论措辞，以便我们能就措辞达成一致。 Ikan Kekek（讨论） 2020年1月26日 19:13 (UTC)

我停止 bothering 的原因是，我发布了一个有用、有效的列表，对许多独立旅行者都有帮助——它被立即删除，并进行了“共识讨论”……。生活太短暂了，鉴于网站上许多文章存在巨大的不足（无论是在遵守政策方面，还是信息过时严重），我当时遇到的问题清楚地表明了网站忽略了更大的图景。花费大量时间关注一个次要列表，而忽略了其他地方需要的大量工作。这就是为什么我认为需要改变态度，以阻止那些迫切需要的东西被驱赶走，因为他们是能够发现错误并修复错误的人（但然后他们会犯“风格”或政策错误，然后……）。但这又是另一个话题了，我现在没有时间或资源来参与讨论。 PsamatheM（讨论） 2020年1月28日 13:52 (UTC)

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

@ ThunderingTyphoons!: 如我在本次讨论稍早所说，我目前没有时间参与（我说：“但我现在正在东南亚旅行，还没准备好进行一次（这本身就是一个单独的主题/讨论串/章节）。等我回家后（或更长时间，或何时）再开始新的讨论。”由于网络缓慢且不可靠，我甚至在努力将照片备份到云端，所以现在开始讨论，我可能会消失一周，讨论会变得非常零散——因此我后来才说，而不是像你的评论那样暗示拒绝参与。

我不是在抱怨过去，而是用它来说明问题。为了得到一个列表而付出的努力是荒谬的。更好的处理方式是，例如，让列表保留下来，然后要求我证明它是例外，信任一个在当地旅行的独立旅行者做出明智的判断，等等。

我并没有“得到我想要的结果”——我希望提供信息来帮助其他独立旅行者。为了得到一个列表所付出的努力让我觉得我的时间更好地花在了旅行上，所以所有关于例如公交路线的极其过时、错误、误导性的信息可能仍然在误导其他旅行者。

正如我之前所说，等我回家有了互联网、笔记本电脑和时间来讨论时，我会提出建议——现在我不确定我是否还有兴趣。我之前说过，我本来想提出建设性的想法。 PsamatheM（讨论） 2020年1月29日 01:55 (UTC)

毕竟，Wikivoyage 的知名度不如 Wikipedia。此外，主要活跃人员大多是社区中的人，甚至遇到了许多像我们一样的竞争对手，因此有外部推广的必要。基本上，我创建的 Wikivoyage YouTube 频道是为了帮助任何人了解我们的 Wikivoyage。我也希望有一些朋友愿意发布宣传或教学视频。您可以将您的 G-Mail 提供给我。我将提供愿意的人成为管理员，这样您就可以将视频发布到Wikivoyage 的 YouTube 频道。 --✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 2020年2月5日 16:21 (UTC)

请为 Wikivoyage 提案在社区愿望清单 2020 上投票

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

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

“Wanted Articles”的愿望也被移除了，m:Community Wishlist Survey 2020/Wikivoyage。鉴于读者当前在地图上的位置是旅行网站最重要的内容之一，这并没有给人留下委员会对帮助 Wikivoyage 感兴趣的印象。 --Traveler100（讨论） 2019年11月22日 14:46 (UTC)

明年总有机会。各位，这是列表：

• 为Wikivoyage的内容翻译工作
• 永久更新 Wikivoyage 附近文章数据文件
• 创建坐标选择器
• 特殊页面“附近”在地理定位停用时应显示输入表单和坐标选择器

我有点惊讶最后两项没有被移除，因为它们不特定于 Wikivoyage（它们是“全局”请求，可以惠及任何维基，而不仅仅是 Wikivoyage）。

我们也应该查看其他项目的列表，看看其中是否有任何项目也可能间接使我们受益。

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

我浏览了其他项目的一些愿望，发现m:Community Wishlist Survey 2020/Wikibooks/EPUB generation也可能对 Wikivoyage 有益。 WhatamIdoing（讨论） 2019年11月28日 03:51 (UTC)

我同意改进离线使用文章的设施会很好。由于我不是 EPUB 格式的常规用户，我稍微偏好m:Community Wishlist Survey 2020/Wikiversity/Export published WikiJournal articles to DOCX or PDF。为酒店提供一个简单的途径，可以将（部分）城市文章的整洁纸质副本留在卧室的文件夹中，这将很有帮助。 AlasdairW（讨论） 2019年11月28日 22:35 (UTC)

很高兴你喜欢我的提案，并且能看到它在 Wikiversity/WikiJournal 之外的用法。 OhanaUnited^讨论页 2019年11月29日 04:30 (UTC)

这个也很有用。投票截止日期是周一。目前，排名前 5 的愿望中有一个（已标记）Wikivoyage 愿望（只有前 5 名“获胜”）。还有一个愿望（目前）差 6 票就能获胜。请记住，您可以投票给任何您认为是个好主意的愿望，不只是那些带有 Wikivoyage 标记的。一些人活跃在其他项目上，我们希望支持他们。此外，一些“非 Wikivoyage”的愿望也可能对我们有用。 m:Community Wishlist Survey 2020/Wikiquote/"Add quote" button in the Visual Editor toolbar 让我联想到这个类别。我认为今年那个不太可能获胜，但工作成员一直在与编辑团队讨论一种实现方法，该方法也可以让我们在这里将 Do/Buy/See/Eat/Sleep 模板列表放在工具栏中。重要的是，只需去投票给你想要的。 WhatamIdoing（讨论） 2019年11月29日 20:51 (UTC)

更多黑客尝试

我又收到了一条关于从新设备多次尝试登录 Wikivoyage 的警告。只有我收到这些警告吗？ Ikan Kekek（讨论） 2019年12月6日 01:13 (UTC)

我没见过这些。你从哪里能看到这些信息？ --评论来自 Selfie City（讨论 | 贡献） 2019年12月6日 02:54 (UTC)

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

我从未见过。你是在哪里看到这些信息的？设备地址是否与可能对你有怨恨的人匹配，例如 Telstra 破坏者？ Pashley（讨论） 2019年12月6日 05:59 (UTC)

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

使内容翻译工具可用于 Wikivoyage

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

到目前为止，此工具仅在维基百科中使用。

作为当前社区愿望清单调查的一部分，已提出一项建议，使此工具也可用于所有 Wikivoyage 版本。

meta:Community_Wishlist_Survey_2020/Wikivoyage/ContentTranslation_work_for_Wikivoyage

如果您支持将此工具也提供给 Wikivoyage，请在该页面上投票。 ויקיג'אנקי（讨论） 2019年11月30日 14:21 (UTC)

这个差几票就赢了。投票很简单：去页面，然后点击蓝色按钮“支持”。你可以选择添加评论，但大多数人不会。投票很快就结束了。 WhatamIdoing（讨论） 2019年12月1日 18:13 (UTC)

什么时候结束？

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

翻译结果的质量如何？比谷歌翻译好吗？ Ikan Kekek（讨论） 2019年12月1日 18:29 (UTC)

谷歌翻译的质量不足以作为最终文档呈现，但它足以完成大量的初步翻译工作。然后，一个不错的（人工）翻译者可以专注于改进流畅性，掌握惯用语，并纠正机器翻译可能导致的理解错误或遗漏的细微差别。专业翻译人员（不一定是使用谷歌，但肯定会使用翻译软件）就是这样工作的，因为这更快，所以翻译人员可以花更多的时间去做真正需要他们专业知识的事情。 --ThunderingTyphoons!（讨论） 2019年12月1日 20:01 (UTC)

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

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

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

而且，实际使用情况如何？我看到的最大问题是，很多人会跳过“清理机器翻译的错误和遗漏的细微差别”这一步，尤其是因为使用机器翻译，你不一定需要理解源语言。我很久没看了，但谷歌有时会产生看起来不错的文本，但包含严重错误信息，因为它善于找到惯用语，但对理解能力却毫无用处。我见过最糟糕的是它在不改变数字的情况下翻译货币（美元到芬兰马克）。我认为只有在我们发现该工具很有用且不太危险的情况下，才应该投票支持它。我们可以纠正语言错误，但很难修复不显眼的错误信息 --LPfi（讨论） 2019年12月2日 13:47 (UTC)

ThunderingTyphoons!，投票今天截止。

Ikan Kekek，这是一个方便双语编辑者翻译文章的软件。它不是自动翻译。有一个设置可以确保纯机器翻译不会被直接导入文章。如果你不先清理它，它就不会让你点击“发布”按钮。每种语言的最低清理工作量都是可配置的。此外，还有一个系统基本上可以阻止单独的编辑者（IP 用户根本无法使用它）使用它，如果他们翻译的文章被删除太多次。总的来说，它是一个设计得相当好的系统。 WhatamIdoing（讨论） 2019年12月2日 16:52 (UTC)

好的。根据你的推荐，我会投票支持它。你用过这个工具吗？ Ikan Kekek（讨论） 2019年12月2日 20:03 (UTC)

我收到一条错误消息：“抱歉！调查已结束。”下次，如果能提前一点发布公告，给我们时间来讨论提案，那会更好。你不能怪我们不愿意凭空投票，或者只是因为有人要求我们就投票。 Ikan Kekek（讨论） 2019年12月2日 20:07 (UTC)

愿望清单投票是在 11 月 4 日在 Pub 公布的，11 月 22 日再次提醒。如果你想投票支持任何提案，留到最后一天不是最好的主意。当然，这个特定的提案是几天前才在这里提出的，但所有提案都至少有一个月的时间供大家查看。指出这里每个人都有机会投票，并不是在指责。

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

关键是，我不知道这个工具很有用，或者投票给它很重要。我很久以前就投了其他的东西。 Ikan Kekek（讨论） 2019年12月2日 23:38 (UTC)

看起来我们不会实现这个功能了。它以令人钦佩的第八名结束（考虑到前四名中有五项是维基文库的提案，这其实也不算差）OhanaUnited^讨论页 2020年1月10日05:52 (UTC)

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

管理员，请阅读

各位朋友大家好。请熟悉过滤器工作方式的各位将注意力转向过滤器#37？似乎存在一个问题或bug。我将非常感激专家的帮助。--ThunderingTyphoons! (讨论) 2019年12月16日07:42 (UTC)

我们是否有关于修改过滤器最佳实践的页面？您并不是因为熟悉正则表达式、bug跟踪等而成为管理员，所以我们不能期望我们的管理员具备专业知识（我们确实有一些专家，但他们并不总是可用）。我花了很多时间才弄清楚语法以及一些过滤器工具的工作原理，学习更多将使这项工作更容易。我能够阅读和理解技术文档，但我仍然会从教程中受益。--LPfi (讨论) 2019年12月17日14:12 (UTC)

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

有一个隐藏在深处的微小错误。一个包含指导的页面仍然受欢迎。--LPfi (讨论) 2020年1月10日17:01 (UTC)