维基导游:旅人酒馆/2014

{{starnomination}} 在移动设备上显示为“本页面存在一些问题”

特色文章候选图标

尝试在Android上访问东京/六本木：第一行是“本页面存在一些问题”。

点击此消息会显示原因：“本文已被提名星级文章状态”。

被提名为星级并不是问题，所以消息不应该是“本页面存在一些问题”。

顺便说一下，特色文章候选的图标看起来像一个破碎的星星。能不能把它改成一个正在建造中的星星呢？ Nicolas1981 (talk) 2013年10月8日14:38 (UTC)

我喜欢这个想法，一个正在建造中的星星是什么样子的？ • • • Peter (Southwood) ^(talk): 2013年10月8日14:58 (UTC)

我能想到一些不错的概念，但它们都需要比一个小图标更多的细节。比如一些脚手架和一个正在完成油漆工作的画家，或者一台起重机正在将最后一块部件吊入到位。动画的... • • • Peter (Southwood) ^(talk): 2013年10月8日15:03 (UTC)

是的，这是我能找到的与我们星级模板上的完整星星最匹配的，但它并不理想。 Texugo (talk) 2013年10月8日15:31 (UTC)

用一支铅笔画一颗星星，但还没有完成怎么样？ Nicolas1981 (talk) 2013年10月9日11:20 (UTC)

你好，另一个尼克。根据我使用移动网站的经验，不只是{{Starnomination}}会产生“本页面存在一些问题”的功能。基本上所有使用{{Ombox}}中代码的模板都会这样。在维基百科上，该代码主要用于清理模板，因此会显示这些特定词语。这只能通过直接更改MediaWiki代码来解决。不过，我不确定如何在不改变维基百科上发生的情况的前提下提出这个请求。 Nick1372 (talk) 2013年10月8日19:32 (UTC)

相关的Mediawiki页面似乎是MediaWiki:Mobile-frontend-meta-data-issues。我们可以在那里更改文本而不影响其他维基，但我尝试了将其留空，虽然它不再显示文本消息，但仍然显示小的“i”图标。我们可以在那里放一个更合适的消息吗？ Texugo (talk) 2013年10月8日19:46 (UTC)

我们真的需要一开始就告诉读者吗？处于提名过程中并不会使文章变得特别，所以最简单的方法可能是从starnomination模板中删除ombox，只留下[[Category:Star article nominations]]部分。你觉得怎么样？ Nicolas1981 (talk) 2013年10月9日03:37 (UTC)

不，但是告诉读者确实会邀请他们通读文章，然后加入提名讨论。此外，删除这个 ombox 只会解决这一个模板的问题，而所有其他使用 ombox 的模板仍然存在同样的问题。我认为我们需要 1) 将该 mediawiki 页面更改为更有用/更准确的内容作为临时措施，也许像“某些内容可能未显示”，然后 2) 找出如何完全禁用该自动消息。 Texugo (talk) 2013年10月9日11:28 (UTC)

我已将消息更改为“某些内容可能未显示”。这不理想，但它比默认消息更准确。现在，如果我们能弄清楚如何完全关闭该消息... Texugo (talk) 2013年10月15日12:46 (UTC)

这个bug是由ombox模板类名错误引起的。我已修复。 Kaldari (talk) 2013年12月31日19:21 (UTC)

@Texugo: 既然已经修复，是否有人可以删除MediaWiki:Mobile-frontend-meta-data-issues页面，以便恢复默认消息？ Kaldari (talk) 2013年12月31日19:34 (UTC)

已完成。 Texugo (talk) 2014年1月3日10:41 (UTC)

新年快乐

各位维基导游同仁们，2014新年快乐！ --Danapit (talk) 2013年12月31日13:44 (UTC)

谢谢Dana。祝你新年快乐，万事如意，并向寒冷的卡拉奇的每一个人致以亲切的问候。 --Saqib (talk) 2013年12月31日14:16 (UTC)

如你所知，芬兰语我应该说Kiitoksia ja hyvää uutta vuotta sinullekin，Danapit！祝赫尔辛基所有朋友新年快乐，赫尔辛基出奇地温暖（新年通常是零下几度下雪，现在却是5°C下雨）。谢谢你的烟花，Saqib！附言：在维基百科的“你知道吗”栏目中，我遇到了关于苏格兰新年习俗的文章以及这个节日的名称词源…… ϒpsilon (talk) 2013年12月31日16:53 (UTC)

新年也是计划/梦想来年要做的事情的日子。世界各地的新年庆祝活动，以及点亮世界著名地标的烟花（想想悉尼令人惊叹的烟花）难道不会让你想去那些地方吗？ :) ϒpsilon (talk) 2013年12月31日19:41 (UTC)

Ypsi说得对。卡拉奇最近由于其在港口大楼举行的新年前夜庆祝活动而吸引了来自该国其他地区的人们，迪拜则吸引了许多海湾国家的人们来庆祝新年前夜。 --Saqib (talk) 2013年12月31日20:32 (UTC)

大家新年快乐！2013年真的是新维基导游社区的第一年，我认为这对2014年能取得的成就来说是个好兆头。 Andrewssi2 (talk) 2013年12月31日19:37 (UTC)

大家新年快乐！祝2014年精彩绝伦！ :) --Nick ^talk 2014年1月1日02:50 (UTC)

祝1914年取得巨大成功，身体健康。 --RolandUnger (talk) 2014年1月1日08:38 (UTC)

来自日本的新年快乐！在2014年，让我们都贡献大量内容，这才是最终让维基导游变得更好的原因 :-) Nicolas1981 (talk) 2014年1月1日14:58 (UTC)

大家新年快乐！ Kaldari (talk) 2014年1月2日08:03 (UTC)

MWException类型的致命异常

当我尝试保存文章、重新加载页面和点击编辑时，在过去几分钟内我一直收到这样的信息：[babeee3a] 2014-01-02 18:16:08: MWException类型的致命异常。是服务器在新年前夜狂欢后宿醉了吗？ :)（看看我能不能把这个发出去） ϒpsilon (talk) 2014年1月2日18:20 (UTC)

我已经提交了Bugzilla: 59221。另请参阅w:Wikipedia:Village pump (technical)#Commons down。 -- Ryan • (talk) • 2014年1月2日19:33 (UTC)

现在应该大部分都恢复了。 --Rschen7754 2014年1月2日19:45 (UTC)

由于本地化缓存更新问题，一些维基媒体项目中断了大约1小时45分钟，但现在已修复。 --Saqib (talk) 2014年1月2日19:47 (UTC)

探索

主页“探索”部分的最新条目写道：“尼科西亚是世界上最后一个分裂的首都。”鉴于耶路撒冷的地位以及我们政治中立的政策，我认为我们应该避免这种有争议的陈述。

-- AndreCarrotflower (talk) 2014年1月7日22:15 (UTC)

你说得对。 --118.93.244.91 2014年1月7日22:37 (UTC)

我也同意。 Pashley (talk) 2014年1月7日23:04 (UTC)

事实上，我们的以色列文章提到耶路撒冷的地位未获得联合国承认。尽管如此，我已更改了“探索”中的句子——以及文章本身中的句子。 ϒpsilon (talk) 2014年1月8日05:27 (UTC)

特此声明，联合国既不承认塞浦路斯的分裂、土耳其对岛屿北部的占领，也不承认尼科西亚在两国之间的分裂。据我所知，土族塞人国家只被世界上另一个国家承认——土耳其。 Ikan Kekek (talk) 2014年1月8日21:29 (UTC)

在我看来，耶路撒冷作为以色列首都的地位、巴勒斯坦和北塞浦路斯作为独立国家的地位都是有争议的政治问题，根据政策，我们应该避免在这些问题上站队。 -- AndreCarrotflower (talk) 2014年1月8日22:20 (UTC)

我们不站队事情应该如何，但我们承认现状。耶路撒冷是以色列的首都，尼科西亚被塞浦路斯和土耳其塞浦路斯分割。这些都是事实。如果事实发生变化，我们将相应地编辑我们的文章。我想听你多谈谈你对巴勒斯坦地位的看法。巴勒斯坦被世界上大多数国家承认为一个独立国家，但以色列不承认，而且它不控制其声称的大部分领土。你建议在本指南中如何描述巴勒斯坦，以利于旅行者？ Ikan Kekek (talk) 2014年1月8日23:23 (UTC)

@Ikan：当然，任何地缘政治场景中都存在一种事实，可能与一些人认为事情应该如何的看法不符。当然，有时为了旅客的利益，有必要提及敏感的政治争议，我们通常会使用免责声明框，其中包含强调文章中的任何内容都不应被解释为支持或反对任何一方的文字。我们在关于巴勒斯坦（以及北塞浦路斯）的文章中做得很好，所以，回答你的问题，我对我在这里的处理方式没有意见。

我最初的帖子只是想说，除非绝对必要，否则我们最好完全避免提及这些事情——不用说，我认为从“探索”功能中随机选择的一篇文章中随机选择的简介并不构成“绝对必要”。当然，如果可以避免，Wikivoyage 不希望冒犯任何政治争论的任何一方，虽然有用，但免责声明框并非避免争议的万无一失的方法。我紧接着你的评论是回应Ypsilon的，即联合国否认耶路撒冷是以色列首都并不意味着这一点毫无争议。相反，关于什么是以色列“合法”首都的问题本身就是一个有争议的政治问题，也是选择尼科西亚简介不理想的另一个原因。再次，我的意见是，甚至提及该主题的参数应尽可能受限。

-- AndreCarrotflower (talk) 2014年1月9日 00:15 (UTC)

我们基本同意，尽管以色列文章在约旦河西岸被移除后需要一些编辑。不过，一个问题是是否将巴勒斯坦领土文章重命名为巴勒斯坦。我欢迎任何人在Talk:Palestinian territories上参与该主题的讨论。 Ikan Kekek (talk) 2014年1月9日 00:26 (UTC)

为此，我们能否将西北地区重命名为“Bob”？ K7L (talk) 2014年1月9日 16:02 (UTC)

好吧，这太傻了。 :-) Ikan Kekek (talk) 2014年1月9日 21:52 (UTC)

“Wikivoyage 2014年度十大国家”？

一些指南正在网上推出此类页面，以期在新年的活动中吸引点击量。我们也应该这样做吗？如果应该，我们必须抓紧时间，否则就留到2015年。我不确定“热门”目的地的标准应该是什么。也许只是我们最好的10篇文章？干杯！ Nicolas1981 (talk) 2014年1月2日 12:38 (UTC)

我正在考虑制作一个显示最受欢迎文章的列表。这里有一个例子。有一些用于此目的的MW扩展，但这会对我们有益吗？ --Saqib (talk) 2014年1月2日 13:52 (UTC)

后一个提议因诸多原因无限优于前一个。我支持在显眼位置显示“最受欢迎文章”（过去一小时或一天）的功能。 PrinceGloria (talk) 2014年1月2日 16:53 (UTC)

要在此维基上安装此扩展，我们需要一些本地支持。能否提供一些支持？ --Saqib (talk) 2014年1月18日 15:14 (UTC)

听起来是个不错的主意。这个Wikinews扩展是只计算一次访问者，还是计算页面加载了多少次？如果有人正在编辑一篇文章并经常保存它，即使只有一个人在“查看”，这篇文章的浏览量也会很高，特别是如果列表是关于过去一小时最受欢迎的文章。 Ypsilon (talk) 2014年1月18日 15:33 (UTC)

我同意PrinceGloria的观点。作为维基媒体基金会网站，我们首先是可靠的、准确、公正信息的来源。我们的目标与《孤独星球》、《国家地理旅行家》或其他出版物之间存在微妙但重要的区别。此外，我们自己的政策禁止吹捧和过度宣传的语言，因此我们必须在处理此类事情时把握好分寸。向读者提供我们最受欢迎文章的资源可能符合这些参数，只要我们以避免“推销”这些目的地给读者的印象（这可能排除了主页上任何过于显眼的链接）的方式进行；除此之外的任何事情似乎都值得商榷。 -- AndreCarrotflower (talk) 2014年1月18日 15:52 (UTC)

如果真的要严格遵循这个原则，我们怎么会有“当日目的地”呢？这基本上是一回事，对吧？我们只是突出文章。当然，目前我们更多的是根据指南质量而不是目的地来突出，但这只是因为我们还没有大量的优秀指南。读者看不到这种区别。对我来说，作为一名旅行者，我恰恰觉得WV缺少激发灵感的内容。例如，我喜欢我们的泰国指南，以我最近的经验，它的目的地覆盖范围胜过LP。然而，我还是会再次购买LP，因为他们的“精选”和“亮点”以及建议的行程，我总是用这些来规划自己的旅行。（好吧，还有他们的英文地图而不是泰文地图，但那是另一回事 ;-)）。尽管我花了很多时间在这个网站上，我仍然会浏览其他网站，购买那些《国家地理》旅游杂志，被故事震撼，并列出愿望清单。如果我们使用“最受欢迎”，我们最终会不断地看到那些标准精选和我们中某人最近一直在编辑的文章，而不是新的发现或隐藏的宝藏。我认为我们可以在措辞上取胜。“热门目的地”是一个棘手的词，我明白。但我不认为突出某些内容一定会损害我们的非吹捧政策或对准确信息的追求，如果我们选择词语清晰巧妙的话。 JuliasTravels (talk) 2014年1月18日 16:28 (UTC)

茱莉亚说得好，我想我现在非常倾向于放弃这个想法。 --Saqib (talk) 2014年1月18日 16:33 (UTC)

我们在Wikivoyage:世界大城市表格的“F”列中确实有一些内容，指出了最受欢迎的目的地。它是客观来源的，取自一篇基于万事达卡报告的《福布斯》文章。我们能否找到改进（是否有其他来源？）和/或使其更突出可用（也许作为一个旅行主题？）的方法？ Pashley (talk) 2014年1月18日 18:56 (UTC)

维基导游——艰难的第二年

我认为这个项目非常棒，我真心这么认为。它拥有大量精彩的信息，并由一个友善、积极的编辑社区组成。

尽管如此，我对Wikivoyage的喜爱也意味着我有时觉得有必要强调网站正在经历的困难。

目前，感觉这个网站有点停滞不前；我们似乎失去了Wikivoyage在一年前在WMF服务器上推出时所展现的一些活力和热情。我们似乎比以往任何时候都更热衷于就每个问题进行长时间的争论，而“共识”仍然与我们无缘。过去几个月，网站上的许多讨论都演变成了人身攻击，而我们似乎比以往任何时候都更不愿大胆尝试，许多这样做的人却因遵循项目宗旨而受到训斥。

由于这些原因（以及其他），我们似乎反而正在失去编辑——这绝不是Wikivoyage所需要的。事实上，我们真正需要做的是进行有计划的宣传，从其他WMF项目以及其他地方吸引贡献者。无论他们是只想改进家乡的文章，还是投身于幕后众多的讨论，我们都应该张开双臂欢迎（并拉拢）他们（如果我们在拉拢的话，就关闭双臂）。

当我回顾去年八月的这次讨论时，我感到很伤心，看到许多人的优秀想法和重要优先事项都石沉大海（我相信Ryan的政策优先事项清单尤其重要）。如果能重新找回一些乐观情绪，并将其投入到改进网站中，那将是极好的。

那么我们能做什么呢？我个人建议两件我认为需要紧急完成的事情：

1. 尽管可能很困难和不愉快，但我真的觉得我们需要理清我们对共识的理解。目前，太多相对次要的问题变成了无休止的争论，使我们偏离了网站面临的更大问题。
2. 吸引更多编辑。这说起来容易做起来难，但简单地说，我们需要更多的人以各种方式为网站工作。我们可以尝试许多不同的方法来做到这一点：更有效地利用我们的社交媒体影响力；在其他WMF网站上做广告；针对网络上的旅游和旅行团体和论坛；与媒体接触；发起某种大规模的宣传活动（也许在Reddit上？）。无论我们做什么，都需要尽快完成：目前我们的人手不足以一次性处理多个问题，因此新想法（无论是受好评还是受谴责）都会被搁置，我们的许多文章多年无人触及。

这并非过去在酒馆里发布的那些末日预言——我仍然相信Wikivoyage拥有非常光明的未来；它只是需要朝着正确的方向稍微推动一下。我绝不是说这里一无所成，只是说需要更多的进步才能让网站正常运转。考虑到这一点，也许我们可以在某个时候举行一次大型的Wikivoyage“年度股东大会”（也许是在IRC或类似平台上）？

我很抱歉这篇帖子有些负面，但我相信Wikivoyage及其社区会成长和繁荣。

如果幸运的话，也许有一天我会停止谈论我的旅行。 :) --Nick ^talk 2014年1月7日 00:03 (UTC)

感谢你的深思熟虑（且发人深省）的评论，尼克，非常感谢！ --118.93.235.201 2014年1月7日 02:52 (UTC)

每当我重新燃起对维基导游未来的悲观情绪时，我都会想到我们的竞争对手维基旅行，一个对旅行者来说日益无用的网站。在不久的将来，维基旅行将只是一堆广告、未回滚的破坏和分叉前早已过时信息的混合体。与此同时，我们有一个小而活跃的社区，正在积极改进我们的产品——诚然，可能人手不足以完成足够的工作，但我们的同行甚至连自保都做不到。考虑到这一切，维基旅行目前可能拥有的任何网站流量优势，我都认为只是暂时的。

这并不是说维基导游现在面临的问题应该被忽视或淡化，而是从大局来看，确实有助于更好地看待问题。

-- AndreCarrotflower (talk) 2014年1月7日 22:28 (UTC)

维基旅行每天的点击量仍然是我们的十倍，这真是显而易见的问题，任何关于马甲或奇怪的澳大利亚IP编辑的干扰都不应使我们偏离当前的主要任务：搜索引擎优化和公关！ --118.93.244.91 2014年1月7日 22:41 (UTC)

https://wikivoyage.cn/wiki/Special:RecentChanges

http://wikitravel.org/en/Special:RecentChanges

一手希望维基旅行消失，一手拉屎，看看哪个先满。

把维基旅行说成“竞争”已经很过时了。一年过去了。我们在这里，他们在那里，他们哪儿也不去。不管你喜欢与否，他们的编辑量比我们多。他们的访问者也多得多。这个网站由一群管理员管理，他们在手动筛选垃圾邮件方面做得很好。

谁在乎呢？我不是来尝试从未被证明有效的SEO技巧的（坦率地说，听起来很90年代）。我来这里是为了写一本旅行指南。如果我们都专注于此，我们都会过得更好。 Nyadgy (talk) 2014年1月7日 22:56 (UTC)

考虑到你总共有三次用户贡献，其中两次是创建你的用户页面和用户讨论页面，我不知道你的评论应该被多么认真地对待。 -- AndreCarrotflower (talk) 2014年1月7日 23:02 (UTC)

你更喜欢省略哪些？那些统计页面链接？找出事实错误或者停止人身攻击。 Nyadgy (talk) 2014年1月7日 23:11 (UTC)

很遗憾我们无法无限期封禁这样为了捣乱而创建的账户。 --Rschen7754 2014年1月9日 18:27 (UTC)

维基百科无限期封禁仅用于破坏的账户。捣乱是破坏的一种形式，或者足够接近。如果这不是Wikivoyage的政策，那也应该成为政策。 -- AndreCarrotflower (talk) 2014年1月9日 18:53 (UTC)

捣乱不是破坏。只需忽略捣乱者。他们想让你回应。不要玩他们的游戏。 Nurg (talk) 2014年1月11日 00:25 (UTC)

我们的主要目的是编写旅行指南。SEO是一项重要任务，将我们的指南与现有其他指南区分开来也是如此，但这绝不会是我们的首要任务。我们需要填补现有地理覆盖的空白，并更新我们的内容，以将我们自己与网络上看似无限量的过时数据区分开来。一旦页面达到“可用”状态，就可以开始考虑提出一个姐妹项目或外部站点链接到我们的内容。 K7L (talk) 2014年1月8日 17:01 (UTC)

我已就Nick关于共识的第一点在Wikivoyage talk:Consensus#Wikivoyage:Consensus/Draft发起讨论。欢迎提供反馈。 -- Ryan • (talk) • 2014年1月13日 02:28 (UTC)

牛津大学的维基导游图表

牛津互联网研究所（该大学的一部分）制作了这个漂亮的图表，显示了文章按语言版本的分布情况。“此图表描绘了维基导游项目四个主要语言的地理重点；它是世界上最受欢迎的众包旅行指南之一。”如果您在上述链接中向下滚动，创作者还会展示他们关于项目如何代表不同区域的发现。 --Nick ^talk 2014年1月10日 21:50 (UTC)

@Nick：关于你提到的最后一件事，我似乎记得前段时间有一个提议，通过翻译其他语言版本中更全面的文章内容来改进英文版对某些地理区域的覆盖。这无疑对评估我们现有资源有很大帮助。 -- AndreCarrotflower (talk) 2014年1月10日 23:08 (UTC)

完全不同的话题，我惊讶他们不认为fr:是我们的“四种主要语言”之一。它肯定比es:大。 -- AndreCarrotflower (talk) 2014年1月10日 23:11 (UTC)

他们并没有选择四种最大的语言，而是选择了最大的两种，以及意大利语，因为它“地理上集中”，即大多数母语者生活在意大利，以及西班牙语，因为它“分散”，在西班牙和南美洲都有人使用。他们感兴趣的是人们是写自己的家乡还是写一个说外语的国家。 AlasdairW (talk) 2014年1月10日 23:31 (UTC)

尼克，感谢你提请我们注意这一点——非常具有启发性！我确实觉得德语版本对“中东和北非”的覆盖率相对和绝对都更好，这有点反直觉…… --118.93nzp (talk) 2014年1月11日 03:09 (UTC)

这就是为什么英文维基导游也将受益于将兴趣点放入维基数据 :-) 我们将极大地受益于意大利、希腊、德国、法国、土耳其、埃及，以及所有其他国家（以多种语言维护列表详情意味着一些重复的工作）。 Nicolas1981 (talk) 2014年1月11日 15:43 (UTC)

有没有一个列表，列出其他语言存在但英语不存在的文章？如果没有，这里会有很多人对这样的列表感兴趣并翻译他们理解的语言吗？ Nicolas1981 (talk) 2014年1月11日 15:43 (UTC)

我将对不存在英文版的法语和德语文章列表感兴趣，也对其他语言中篇幅更大的文章列表感兴趣。我之前已经使用一篇德语文章改进了一篇英文文章，如上所述。

我知道有一张地图显示了（几乎）所有英文文章——其他语言是否存在这样的地图？如果存在这样的地图，将其链接到主页会很有用。 AlasdairW (talk) 2014年1月11日 21:17 (UTC)

如果我没记错，那个OSM滑行地图是由WV.de创建的，并且存在于其他语言中；只需在URL中将“en”替换为“fr”或“de”或其他即可。 K7L (talk) 2014年1月11日 21:33 (UTC)

一份存在于X语言但不存在于Y语言的文章地图可能最有用。 Nicolas1981 (talk) 2014年1月12日 05:05 (UTC)

机器人是否能将文章从德语维基导游转换过来？

我刚刚从德语翻译了Wiedensahl，除了机器人可能执行的操作外，没有做任何其他事情。

结果很小（不要指望一个1031人的村庄能有多大的内容），但我认为这是一个好的开始，肯定比什么都没有好。

你觉得呢？这样转换值得吗，还是毫无价值？ Nicolas1981 (talk) 2014年1月11日 17:11 (UTC)

这篇特别的文章没有横幅和图片。横幅当然可以包括在内，图片也可以包括在内，不带说明文字。一个问题是兴趣点（POI）的名称。通常兴趣点名称需要翻译，例如“Museum im alten Pfarrhaus”。我认为机器人应该只翻译10篇文章，等待这10篇文章由人工润色后，再生成另外10篇，以此类推。 Nicolas1981 (talk) 2014年1月11日 17:21 (UTC)

我猜“Hauptstrasse”是“rue Principale”是“Main Street”是“High Street”。如果“翻译”来自特定目的地的当地语言文本，并且使用西方欧文字符集，我想最初将其保留原样是可以的——但我们可能应该避免将一篇关于德国的法语文章（例如）直接转储到en:中，因为“1, rue Hauptstrasse, Une ville allemande”有点太非英语、非德语了。 K7L (talk) 2014年1月11日 17:56 (UTC)

这样的机器人可能很有用。然而，我们仍然需要有人翻译所有非英语的内容（描述、兴趣点名称、整个理解和保持安全部分等等）。我们应该让机器人也把这些内容带过来，让指南中有很多非英语文本，还是让润色文章的人找到德语中正确的列表，然后复制并翻译文本？

顺便说一句，他们真的在法语中写“rue Hauptstrasse”（主要街道）吗？在拉丁字母开头的地址后面或前面写一个额外的“Street”或“Rue”或任何东西有什么用呢？ Ypsilon (talk) 2014年1月11日 20:09 (UTC)

他们更可能替换而不是重复，例如“810, rue Montréal”而不是“810 Montreal St.”。专有名词通常会保留不变，所以“rue Maisonneuve”变成“Maisonneuve St.”而不是“Newhouse Street”。还有一些其他的关键词会改变，比如电话交换机分机号码的“poste”而不是“ext”。使用像“123, rue Bank Street”这样难看的表达通常只出现在渥太华市的出版物中，他们喜欢重复两次。 K7L (talk) 2014年1月11日 21:00 (UTC)

在我们的文章中翻译街道名称真的符合旅行者的最大利益吗？我想象一个前往巴黎大屠杀纪念馆的人，在街头标示写着“rue Geoffroy-L'Asnier”时，却茫然地寻找“Geoffroy L'Asnier Street”。我曾与足够多的只说英语的人旅行过，意识到这并非一个牵强附会的假设。 -- AndreCarrotflower (talk) 2014年1月11日 21:57 (UTC)

同意，将街道名称翻译成英文确实很愚蠢（我甚至会说是白痴），因为你在目的地时根本用不上这些名称。此外，兴趣点的名称可能有助于告诉旅行者它是关于什么的，但英文名称通常不会出现在路标或地图上（但通常会出现在兴趣点的网站和小册子上）。对于非拉丁字母的名称——例如圣彼得堡的Sennaya Plochad广场及其同名地铁站——提供英文翻译或音译是有用的，因为许多人无法阅读西里尔字母，但更重要的是在文章中写出“Сенная Плошад”，因为一旦到了那里，你就会寻找这个名称。 Ypsilon (talk) 2014年1月11日 22:16 (UTC)

有一点需要注意：如果从另一种语言的WV导入现有文章，那篇文章可能已经包含翻译过的街道名称。fr:渥太华和fr:多伦多使用“rue”，而fr:伦敦使用“Street”。de:巴黎有时使用“rue”，但更常使用“Place Charles de Gaulle, sehenswerter Platz, auf dem der Arc de Triomphe steht.”。还有一个额外的复杂因素是目的地城市本身可能是多语言或至少是双语的。如果源WV是目的地的本地语言，这是可以管理的。如果它是第三国语言，机器人不太可能避免三语混乱。 K7L (talk) 2014年1月11日 22:36 (UTC)

你似乎只对https://de.wikivoyage.org/wiki/Wiedensahl进行了部分翻译。这真的没问题，尽管我猜测你提议的机器人只会转换带有基本信息的列表？你应该在开头添加翻译模板，例如：{{translate|nl|Den Haag}}，以便日后进行进一步的人工翻译。（希望你不介意，我只是将此添加到你的文章中以作说明） Andrewssi2 (talk) 2014年1月12日 15:09 (UTC)

我刚刚创建了大贝内拉岛，它以de:大贝内拉岛为起点。使用谷歌Chrome浏览器阅读德语文章时，一些文本直接来自德语文章的维基文本，一些来自文章的英文翻译（我无法让翻译在编辑框中工作）。这是我很久以前访问过的苏格兰的一个岛屿，所以我预计完成时不会有任何主要的翻译问题。我怀疑机器人无法很好地完成从一种语言到另一种语言的文章转换，但可能存在机器人擅长的特定元素——比如将德国使用的vcard格式的列表转换为我们的列表格式。

在被翻译的文章（最初的德语文章）的讨论页上添加一个模板可能会很有用，以感谢文章的创建者，并让他们知道，以便他们能够并且愿意参与进来。 AlasdairW (talk) 2014年1月13日 00:04 (UTC)

AlasdairW，我上周为已翻译的英文讨论页创建了这样一个模板：Template:Translated Andrewssi2 (讨论) 2014年1月13日 (UTC) 01:38

谢谢。几个月前我确实问过这样一个模板，这次我用了编辑摘要——但我会添加模板。我正在考虑的是一个所有语言都通用的模板——类似于 {{Translated_To|en|2014年1月12日}} ，它会显示类似于“感谢您创建这篇文章。此页面的部分（或全部）内容已翻译成英文。如果您愿意，可以在这里查看翻译后的文章。”的文本。我当时想a) 感谢原始文章的作者会很好。b) 其中一位可能会过来阅读并纠正翻译。c) 未来的一些更改也可能在这里进行。AlasdairW (讨论) 2014年1月13日 (UTC) 23:05

是的，实际上，拥有一个反向的模板会很好！（即：这篇英文文章于2013年12月3日翻译成罗马尼亚语）。

无论如何，我可以看看创建您建议的德语模板。（我从未真正活跃于德语网站，但这应该是一个简单的任务） Andrewssi2 (讨论) 2014年1月15日 (UTC) 00:58

供您参考：正在这里进行 Andrewssi2 (讨论) 2014年1月15日 (UTC) 01:59

午休时完成 :) 模板和示例 Andrewssi2 (讨论) 2014年1月15日 (UTC) 05:11

我会小心大量创建机器人文章：例如，像“柏林是德国的一个城市”这样只有一句话的文章作用不大。--Rschen7754 2014年1月15日 (UTC) 05:31

我完全同意。也许与其使用机器人，不如使用一个工具来创建骨架文章并吸取列表信息（如名称、地址、经度、纬度、电话号码、网站等），这将加速人工翻译工作。Andrewssi2 (讨论) 2014年1月15日 (UTC) 05:48

生日庆祝

还是老样子蛋糕

1月15日（只剩两天了！）是维基导游在维基媒体基金会服务器上第一个生日。由于去年我们没有庆祝该项目共同的第10个生日，我们有什么想法来庆祝这个里程碑吗？--尼克 ^讨论 2014年1月13日 (UTC) 20:02

如果有人能准备一份适当的网站公告，那将是最低限度，如果有人能联系到维基媒体基金会的营销团队，在Twitter和Facebook页面上提及也会很棒。我相信其他人会有更多的建议——感谢您提出这个里程碑。-- 瑞安 • (讨论) • 2014年1月13日 (UTC) 20:07

亲爱的维基导游，祝您生日快乐，万事如意，但今年没有新鲜蛋糕。也许下次？哈哈！--萨奇布 (讨论) 2014年1月13日 (UTC) 20:49

我更倾向于将其称为周年纪念日而非生日。我们不是去年一月诞生的；那只是我们在这个新伙伴关系下正式启动的标志。Powers ^(讨论) 2014年1月13日 (UTC) 20:53

我同意你，我们必须明确这一点，但对于局外人来说，“生日”的概念比“项目迁移到维基媒体基金会服务器的周年纪念日”更容易理解；单独说“周年纪念日”会引出“什么周年纪念日？”的问题。也许我们可以直接说“这是我们的生日”，而不提及我们多大了（我们要么10岁，要么1岁）。--尼克 ^讨论 2014年1月13日 (UTC) 21:41

我已相应更改了下面的横幅设计......--尼克 ^讨论 2014年1月14日 (UTC) 03:20

由于世界某些地区现在已是15号，我将勇往直前更改网站公告。如果有人反对，我乐意更改。 :) --尼克 ^讨论 2014年1月14日 (UTC) 11:53

认为周年纪念日比生日更难沟通的想法是荒谬的。但我猜我只会把它添加到我在这里没有获得任何关注的不断增长的意见列表中。Powers ^(讨论) 2014年1月14日 (UTC) 15:19

这似乎有点不公平，Powers。您的意见总是受到欢迎并认真考虑；为美国寻找合适横幅的持续努力就是您的异议和意见的结果——您没有被忽视。上面，我只是想说“生日”比“我们迁至维基媒体基金会服务器的周年纪念日”听起来对局外人来说更具意义——如果没有任何冗长的解释，后者可能听起来像是一个简单的技术更改，不值得庆祝。当我们不得不用140个字符来宣布这一点时，简洁和简单的概念是很有价值的。我并非否认维基导游的遗产，也并非否认这里的许多贡献者已经在这个项目上工作了很多年，但对于不熟悉该网站运作的英语使用者来说，维基导游确实在一年前的明天是新的。由于我们去年7月没有与WT一起庆祝，所以不将这一天指定为维基导游的生日似乎很可惜。我们未来如何标记这一天由社区决定——周年纪念日、生日或独立日——但让我们利用这一天，无论它是什么，来反思我们走了多远，以及我们还能做些什么。--尼克 ^讨论 2014年1月14日 (UTC) 15:35

我强烈并声嘶力竭地不同意你的评估。称其为周年纪念日绝不会使情况变得过于复杂。我不明白你为什么必须改变措辞，除了将“生日”一词替换为“周年纪念日”。当你使用“周年纪念日”时，所有关于“冗长解释”的东西与你使用“生日”时一样不必要，而且还有一个额外的好处，就是它不是公然虚假的。（维基导游绝不是在2013年1月诞生的。）Powers ^(讨论) 2014年1月14日 (UTC) 19:26

我绝不是要一上来就挑起争执，但我确实觉得“生日”比模棱两可的“周年纪念日”更友好，不那么冷淡专业。而且一定有人认为这个项目的这个特定版本是在一年前诞生——或者说是重生。对我来说，这似乎是正确的选择。确实是生日快乐，非常感谢让我有宾至如归的感觉。我不是那种喜欢加入群体的人，但我会尽力而为。Alhens (讨论) 2014年1月14日 (UTC) 23:27

其他庆祝活动

还有其他庆祝活动的想法吗？这份《维基新闻简报》报告承诺将举办一场“大型公共派对”！也许可以创建一个包含过去一年亮点的页面？--尼克 ^讨论 2014年1月14日 (UTC) 21:48

维基导游生日快乐！

1月15日是维基导游在维基媒体基金会服务器上运营的第一年。让我们借此机会庆祝过去一年中我们取得的一些成就、您最喜欢的网站部分以及您希望在来年发生的事情。--尼克 ^讨论 2014年1月14日 (UTC) 11:53

我计划今年在巴基斯坦各地旅行，为我们的指南收集大量信息，我相信我能够在下一个周年纪念日前将更多巴基斯坦目的地文章提升到指南级别。--萨奇布 (讨论) 2014年1月14日 (UTC) 12:14

生日快乐！说真的，我们可以感到自豪，维基导游比去年好多了！横幅和动态地图是一些最明显的例子。Nicolas1981 (讨论) 2014年1月14日 (UTC) 12:43

也祝我生日快乐。在庆祝了第十个和第七个生日之后，我们现在庆祝我们在维基媒体运动中的第一个生日。哇！社区做了大量工作。例如，我想到了将35,000张图片集成到维基共享资源以及将跨语言链接导入到维基数据。我们最初有七个语言分支，现在有15个，我们正在等待中文分支。我要感谢所有作者和读者为维基导游付出的努力和兴趣。再接再厉！--RolandUnger (讨论) 2014年1月14日 (UTC) 16:52

生日快乐，新年快乐！:D。附注：两小时前横幅的大小和页面横幅一样，但现在它变得巨大了？只有我注意到吗？Ypsilon (讨论) 2014年1月14日 (UTC) 17:47

对我来说，它仍然显示为正确的大小......你能在我讨论页上截个图吗？ :) --尼克 ^讨论 2014年1月14日 (UTC) 17:59

中文维基导游实际上今天开通了，尽管内容尚未导入：zh.wikivoyage.org。--Rschen7754 2014年1月15日 (UTC) 00:20

实际上，User:SPQRobin 正在导入。--Rschen7754 2014年1月15日 (UTC) 00:26

生日快乐 --Azoma (讨论) 2014年1月15日 (UTC) 00:38

祝我们第七个生日快乐，也是作为维基媒体基金会姐妹项目的第一个生日。感谢大家在这里所做的一切工作。-- DerFussi 2014年1月15日 (UTC) 05:53

维基导游生日快乐。最近在了解了分叉及其原因后，我从 Wikitravel 转了过来。--Larkly (讨论) 2014年1月15日 (UTC) 08:14

@Larkly: 您在 Wikitravel 上的用户名是什么？您可能想在这里使用相同的用户名，并将帐户合并，以便您的之前的贡献历史能够被认可。Wikivoyage:用户账户迁移 会进一步解释... --118.93nzp (讨论) 2014年1月16日 (UTC) 00:06

维基导游生日快乐。欢迎您，Larkly。我们很高兴您加入。-- AndreCarrotflower (讨论) 2014年1月15日 (UTC) 21:27

关于维基共享资源征求意见：维基媒体是否应支持MP4视频？

很抱歉此消息仅为英文。如果需要，请将其翻译以帮助您的社区。

维基媒体基金会多媒体团队正就支持MP4视频格式的提案征求社区指导。这种数字视频标准在全球范围内广泛用于在手机、台式电脑和家用视频设备上录制、编辑和观看视频。它也称为H.264/MPEG-4或AVC。

支持MP4格式将使我们的用户更容易在维基百科和维基媒体项目上查看和贡献视频——视频文件可以在我们的网站上以双重格式提供，因此我们可以继续支持当前的开放格式（WebM和Ogg Theora）。

然而，MP4是一种受专利限制的格式，使用专有格式将偏离我们目前仅支持我们网站上的开放格式的做法——即使许可证似乎具有可接受的法律条款，只需要支付少量费用。

我们非常感谢您就是否支持MP4提供指导。我们的征求意见稿根据我们在与社区和团队成员讨论中听到的意见，提出了支持和反对MP4支持的观点。

请加入此征求意见稿——并分享您的建议.

欢迎所有用户参与，无论您是否活跃于维基共享资源、维基百科、其他维基媒体项目——或任何使用我们免费媒体仓库内容的网站。

也欢迎您参加明天（本周四，1月16日，世界协调时19:00）的IRC办公时间聊天，如果您想与我们的团队和其他社区成员讨论这个项目。

我们期待与您进行建设性讨论，以便我们在这个重要问题上共同做出更明智的决定。基根 (WMF) (讨论) 2014年1月16日 (UTC) 06:46

WT归属

我们通常使用Template:Wikipedia进行归属，当我们从维基百科复制内容时，我当时在想是否可以为 Wikitravel 创建一个类似的模板，然后将该模板添加到页脚中显示 WT 归属的文章的讨论页面。这样，我们就可以在页脚中删除 WT 归属。如果之前讨论过相同的内容，请忽略此帖子。--萨奇布 (讨论) 2014年1月15日 (UTC) 11:56

如果共识是不可能或不建议在没有维基媒体基金会法律团队批准的情况下完全删除页脚，那么其他任何扰乱现状的方式，包括用模板替换页脚，可能也会如此。另一方面，如果我们要承担这种法律风险，我想说，我们不要半途而废，直接完全消除所有归属（除了标有WT-en的编辑摘要）。-- AndreCarrotflower (讨论) 2014年1月15日 (UTC) 20:59

另一方面，这样的模板可能有助于复制我们可能想要添加到 WV 的任何分叉后的 WT 内容，尽管考虑到 WT 目前的情况，我想这种情况不会经常发生。-- AndreCarrotflower (讨论) 2014年1月15日 (UTC) 21:08

老实说，我不认为为单个来源（尤其是非维基媒体的）开发特定模板是一个好主意。我认为我们应该或多或少地平等对待所有来源，并在可能的情况下在编辑历史中提供足够的归属。如果我们确实需要任何形式的模板，最好是它某种程度上是通用的，并且可以用于任何来源。至于模板替换免责声明，此类文章的搜索引擎效应无论如何都会受到限制，因为它仍然会有一个超链接。最好等到那个可怕的免责声明消失。JuliasTravels (讨论) 2014年1月15日 (UTC) 21:24

根据维基媒体基金会的使用条款，在编辑摘要中提供归属就足够了。然而，Wikitravel 可能施加了额外要求。有人知道在哪里可以找到内容复制到维基导游当天的使用条款副本吗？Edge3 (讨论) 2014年1月18日 (UTC) 23:22

WT 在迁移后更改了他们的要求，现在要求一个超链接（尽管他们条款的其他部分似乎对此不明确）。在迁移时，它明确指出“因此，我们要求您也链接回原始的 Wikitravel 文章，允许您的读者更新它。这只是一个请求；它不是许可要求的一部分”。 JuliasTravels (讨论) 2014年1月18日 (UTC) 23:40

WT内容受CC-SA许可保护，因此IB试图施加的任何额外要求都将违反CC-SA，并从本质上撤销他们对网站所有现有内容的权利（根据，“无额外限制”）。关于归属的最初问题，由于他们过去曾诉诸诉讼，我建议我们继续采取不鼓励从他们那里复制内容，并对从WT内容导入的现有文章的任何更改保持谨慎的态度。-- 瑞安 • (讨论) • 2014年1月19日 (UTC) 00:31

WT在迁移期间的使用条款非常模糊……这对我们来说是好事。我认为我们不需要在免责声明中提供超链接。Edge3 (讨论) 2014年1月19日 (UTC) 00:48

该项目的既定目标之一始终是能够打印目的地指南作为游客行李。因此，不需要超链接并非偶然。K7L (讨论) 2014年1月19日 (UTC) 03:24

那么，我们或许可以删除超链接，但保留URL？我们可以这样做，但超链接被禁用：“本文基于……来自 Wikitravel 上文章‘United States’（http://wikitravel.org/en/United_States）的文本……”知识共享指南规定我们至少应包含一个URL。Edge3 (讨论) 2014年1月19日 (UTC) 03:51

酒吧清理

此页面已变得相当笨重，因此我已将一些旧讨论（大约2个月或更早的）移动到其相关位置。有人能快速审阅并确认我做得对吗？

我从顶部的指南中得到的印象是，Travellers' Pub 存档应该是会话最后被移动到的地方，尽管查看存档页面，似乎大多数会话最终都到了这里？

此外，指南说可以清理一个月或更早的，但我认为现在将2个月或更早的规则应用于我的特定操作会很有帮助。Andrewssi2 (讨论) 2014年1月18日 (UTC) 03:51

从en.wv到fr.wv的自动文章生成

大家好！

我写了一个脚本，可以将英文维基导游文章转换为法文维基导游文章。结果如下：https://fr.wikivoyage.org/w/index.php?title=Aarhus&oldid=193198

生成的内容

• 横幅
• 小引言
• 信息框
• 动态地图
• 所有列表
• 面包屑导航
• 图片，在它们所属的部分。

我仍然需要自动链接 Wikidata。集成到文章创建页面会是一个杀手级功能，但这需要更多的开发工作。当然是开源的，欢迎将其移植以执行德语->英语和法语->英语的转换 :-) 欢迎提供反馈和想法！Nicolas1981 (讨论) 2014年1月19日 (UTC) 15:36

有意思。一定有办法把它放在一个简单的网页界面后面，并放在某个工具服务器上，就像https://toolserver.org/~dispenser/cgi-bin/webreflinks.py 请求一个英文维基百科文章名称，然后将所有<ref>标签转换为模板形式，并将结果输出到一个编辑框中。不确定我们如何处理fr:modèle:listing中缺少en:的{{listing}}中的字段，例如“téléphone mobile”、“wikipédia”、“facebook”——额外的电话号码可能需要移到en:中的描述部分。我想wget -O - "https://wikivoyage.cn/w/index.php?title=Aarhus&action=edit"也可以替换为action=raw或API https://fr.wikivoyage.org/w/api.php，以便只返回维基文本而不带任何无关的MediaWiki用户界面部分？K7L (讨论) 2014年1月19日 (UTC) 16:24

好的。我会在德国语有但英语没有的文章上使用它。如前所述，最好也在这些页面添加模板和类别，以便跟踪基本对话并确保及时进行翻译工作。Andrewssi2 (讨论) 2014年1月19日 (UTC) 23:51

感谢K7L的提示，已修复！它是开源的，所以请大家把它放到工具服务器或任何你想放的地方 :-) Andrewssi2：是的，fr上似乎也有这样的模板，我会尝试使用它。Nicolas1981 (讨论) 2014年1月20日 (UTC) 02:38

这项努力的目标也是更好地理解我们可以通过维基数据在语言之间共享什么。Nicolas1981 (讨论) 2014年1月20日 (UTC) 02:39

保守教条

有人写道，我们的工作以旅行者的最佳视角为指导，这甚至可以称为我们的首要指令。

MediaWiki 软件和 HTML 中有一些功能鲜为人知（更不用说有人费心去使用），但它们对旅行者仍然很有帮助。

一个例子是
<abbr title="(解释性文本)">(本地化术语)</abbr>
结构。
这种结构意味着散文流不会被括号中的解释不必要地打断。一个使用示例是：“纳尔逊的CBD紧凑且避雨。”其中对于澳大利亚人、新西兰人和南非人来说普遍易懂的散文，为英国人等提供了鼠标提示即时澄清。

以前，我们的共识政策一直是，既然这是一个维基，你可以使用任何对旅行者有用的英语语言特性或软件功能，除非它已被共识政策明确禁止。

瑞安正在游说进行的这些改变是否威胁到了维基的这种基本自由？——118.93nzp (对话) 2014年1月19日22:18 (UTC)

就一些背景信息而言，之前是否有过关于不使用<abbr title="(explanatory text)">(localised term)</abbr> 的讨论？（或类似的）Andrewssi2 (对话) 2014年1月19日23:46 (UTC)

据我所知没有。

然而，我也不知道有讨论试图禁止在西班牙语单词中使用外来字符，例如eñe中的西班牙语El Niño或Bogotá中的重音符号，或Māori中的长音符号，或Eskişehir中的软音符。

我真的不希望我们走到这样一个地步：每一项“创新”都需要事先获得许可。如果有人引入了一个（对我们来说）新词，然后经过深思熟虑的共识决定禁止这项创新，那是公平的。然而，仅仅因为少数知名编辑“不喜欢它”，不应该意味着在没有真正和有记录的共识的情况下就全面禁止。

共识不应意味着停滞。——118.93nzp (对话) 2014年1月19日23:58 (UTC)

我个人没有观察到外国字符被压制的情况。如果没有它们，我很难处理德国的文章。Andrewssi2 (对话) 2014年1月20日01:32 (UTC)

关于变音符号的规则是，我们尽量避免使用它们。也就是说，如果一个城市/城镇/地区/国家等有明确且相对常用的英文名称，则应优先使用英文名称，而非任何外文形式。原因很简单：英文 Wikivoyage 是用英文编写的。实际上，许多论点（主要来自欧洲人）都反对使用英文名称。例如，波哥大实际上使用了变音符号，尽管我认为不应该使用，因为英文地图和大多数参考文献都没有使用它。从对它的非辩论来看，我认为用户：Globe-trotter断言没有“明显的英文名称”是错误的。它应该是没有变音符号的 Bogota。它是一个世界首都，并且有一个公认的英文名称。ChubbyWimbus (对话) 2014年1月20日10:24 (UTC)

我不知道我们有关于变音符号的政策，但如果ChubbyWimbus引用的规则是准确的，我对此有异议。我可以举出许多可能的陷阱，其中许多情况下，变音符号会从根本上改变一个词的读音（例如，“n”与“ñ”），这可能导致混淆，比如游客误读地名给出租车司机听。此外，正如Andrewssi2暗示的那样，它们通常对于消歧义是不可或缺的。我觉得我们至少应该采取中立立场，甚至可能支持变音符号。我不确定我应该在哪一个政策讨论页开始讨论，但我很想这样做。——AndreCarrotflower (对话) 2014年1月20日10:58 (UTC)

我认为在很多情况下，人们为了插入变音符号，把差异夸大到实际上不存在的地步。我还没遇到过哪个西班牙语使用者迟钝到不能理解 Bogota 就是 Bogotá。即使有西班牙语使用者无法理解，也没关系，因为英文维基导游不是为西班牙语使用者准备的；它是为英语使用者准备的。导游页面顶部应该包含本地拼写（或字符），所以即使存在很大的差异，例如英语和韩语之间，如果你需要向韩国人提及城市名称而他们无法理解你，你可以指向这些字符。西班牙语也可以这样做。出租车司机应该非常习惯外国人奇怪的发音。许多出租车司机本身就是外国人，他们发音也不正确。

这项政策实际上只是为了确保我们尽可能使用英语。在不可能的情况下，允许使用变音符号。已经有关于各种城镇的讨论，结果是保留或插入变音符号。我自己无法支持“亲变音符号”的立场。我确实认为英文版需要坚持使用英文名称。变音符号只应该在确实没有英语可供使用或英语不合适的情况下使用。我很抱歉不擅长查找讨论，但它们随处可见。我无法一一追踪……ChubbyWimbus (对话) 2014年1月20日11:27 (UTC)

文章名称中有关变音符号的政策主要在Wikivoyage:文章命名惯例#示例中涵盖。在 Bogota / Bogotá 的情况下，前者可能符合“常用英文名称”的标准，因为后者在英文地图和文献中不常用，尽管在变音符号和非变音符号版本同样常见的情况下，我们使用当地名称（例如圣保罗）。—— Ryan • (对话) •

一个缺少重音符号的外文名称仍然是外文名称。我们确实需要一个从缺少变音符号的标题重定向，因为有人可能试图从没有或难以输入的设备（如手机）访问WV，但本质上“café”、“piñata”、“maître d'hôtel”和其他英文中的非英文单词并不会仅仅因为有人忘记了一个或两个重音符号就奇迹般地变成英文。将蒙特利尔/西岛上的重音符号省略是可以接受的（因为蒙特利尔的这部分地区有一个著名的讲英语的少数民族，他们通常会去掉重音符号并相应地发音），但Bogotà无论拼写错误与否都是西班牙语名称。它没有任何英文成分。

棘手的部分是当一个地方有两种不同外语的名称时，比如切尔诺贝利/切尔诺贝利（音译，乌克兰语/俄语）或格但斯克/但泽（波兰语/德语）。选择使用哪个名称就成了政治问题。K7L (对话) 2014年1月20日16:18 (UTC)

英语“Bogota”和西班牙语“Bogotà”的拼写除了一个变音符号外完全相同，但这绝不意味着该城市没有英文名称。当然，并非所有城市都有英文名称，但波哥大确实有。Powers ^(对话) 2014年1月20日19:01 (UTC)

据我所知，<abbr>不是Mediawiki功能，它的实现依赖于浏览器。我不确定它是否被广泛理解，所以我会不情愿地过多扩展它的使用。Powers ^(对话) 2014年1月20日19:01 (UTC)

Powers，这确实是HTML，我同意它依赖于浏览器。[例如，此元素在IE7之前的微软IE浏览器中不受支持，尽管Safari一直支持它，Chrome从2.0或更早版本开始支持，Firefox (Gecko) 从1.0 (1.7) 或更早版本开始支持，Opera从1.3或更早版本开始支持]。尽管在现代图形浏览器中，“工具提示”这种有用的行为很常见，但你不能完全依赖它，特别是从可访问性角度来看。一些基于语音的浏览器可能会为用户提供可选的访问标题属性值，但它们倾向于默认忽略它们。此外，没有鼠标或由于运动功能障碍而难以使用鼠标的图形浏览器用户可能无法调用“工具提示”。当然，缩写词的解释通常在打印版本中不可见。然而，我们不会仅仅因为一部分读者看不到图像而回避使用图像，我认为这又是一个可以由个别编辑和文章自行决定的例子。我的基本观点是，我不希望不宽容蔓延，不强制的东西都被禁止。——118.93nzp (对话) 2014年1月20日20:41 (UTC)

顺便说一下，该城市的西班牙语名称是 Bogotá。À 在意大利语和法语中使用（这次忍不住挑剔了 :D），ϒpsilon (对话) 2014年1月20日19:14 (UTC)

“Bogota”不是“Bogotà”的拼写错误。它就像 ボゴタ、ቦጎታ 等。它们是该城市的外语名称，在各自语言中都是“正确”的名称。ChubbyWimbus (对话) 2014年1月21日07:00 (UTC)

@ChubbyWimbus: ϒpsilon 指出的是 à 和 á 之间的区别 :-) Nicolas1981 (对话) 2014年1月21日12:27 (UTC)

我看到了，我上面复制粘贴错了。哈哈，我打不出变音符号。哎呀，真是个烦恼。ChubbyWimbus (对话) 2014年1月21日14:01 (UTC)

我只是在区域设置中将键盘设置为“美式国际”；输入 voil`a 然后 voila 变音符就出现了。这并不能解决键盘和椅子之间的问题……我不会任何外语，而且在我自己的国家，我的文本已经够乱了。K7L (对话) 2014年1月21日16:28 (UTC)

将章节图片移至维基数据？

大家好，

我意识到所有语言的章节（餐饮、住宿等）都大同小异，我们都试图为每个章节找到相关的图片（餐饮部分的食物图片等）。通常每个章节只有零、一或两张图片，放置在章节开头。

维基数据可以提供帮助！让我们为每个目的地定义一个小的维基共享资源图片文件名列表，每个章节一个，每个图片都配有针对不同语言的本地化说明。这显然比我们为横幅所做的更复杂。

在在维基数据上提出这个想法之前，最好在这里讨论一下，找出最好的方法。有什么想法吗？Nicolas1981 (对话) 2014年1月20日03:07 (UTC)

通常维基导游会讨论文章中使用的最佳横幅，而且这些讨论在母语为英语的人之间可能会相当漫长和困难。

如果我们真的将此类事物集中到维基数据中，那么不同社区之间进行此类讨论会不会有问题？实际上，您是否会将任何不流利的英语使用者排除在关于其社区文章内容显示的讨论之外？Andrewssi2 (对话) 2014年1月20日03:15 (UTC)

中肯的观点，安德鲁；维基数据在这方面看起来相当诱人……——118.93nzp (对话) 2014年1月20日03:19 (UTC)

在美国的讨论很有趣，也很必要，即使没有维基数据也会发生。

在所有语言中，大多数部分都没有图像，任何图像都会有所帮助。99.9% 的章节图像都不会引起任何争议。对于剩下的 0.1%，您将始终可以删除维基数据模板并像我们现在一样放置硬编码图像。Nicolas1981 (对话) 2014年1月20日06:36 (UTC)

这是否会冒着有人悄悄引入“直立”这种（在某些超级用户看来）不恰当的相对图像尺寸调整的风险？毕竟，大多数其他WMF项目都使用MediaWiki软件中有用的功能……——118.93nzp (对话) 2014年1月20日06:46 (UTC)

如果它是一个可以由每个WV语言站点使用或删除的“软”模板，那应该没问题。Andrewssi2 (对话) 2014年1月20日06:44 (UTC)

我想，问一些小型WV语言站点的编辑他们的感受可能更合理。我可以想象，规模较大的德语站点可能会有更多顾虑，因为他们能够独立完成任务和讨论，而较小的站点（如荷兰语和波兰语）可能暂时更愿意接受任何帮助？不过我不确定。JuliasTravels (对话) 2014年1月20日12:03 (UTC)

我相信Nicolas1981的意思是这些模板是可选的。例如，我过去翻译的德语文章实际上经常使用原始的德语图片。如果我想在英语版本中使用不同的图片，那么（我相信）我完全可以自由地这样做。

话虽如此，我确实想知道人们是否会把这视为WV各语言版本内容标准化的先兆？那肯定会引起担忧。Andrewssi2 (对话) 2014年1月20日12:13 (UTC)

我明白了，我的意思是，首先将这些内容放在维基数据中的主要原因是为了帮助较小的语言版本，还是我理解错了？JuliasTravels (对话) 2014年1月20日12:22 (UTC)

是的，主要目标是帮助较小的维基导游。但英语维基导游可能会从更多编辑中受益，类似于横幅的情况（本地人创建的横幅能真正表达他们熟悉的城镇的感觉）。Nicolas1981 (对话) 2014年1月21日03:19 (UTC)

我不确定这是否可行，因为文章的长度通常在不同语言之间差异很大——最详细的内容会出现在本地语言或拥有最多维基导游的语言中。极少数例外是像梅冈蒂克湖（英/法）这样完全翻译的页面，其中完整的列表内容经过某种翻译尝试后，未经删减地往返。对于一篇冗长详细的文章来说，可能合适的图片数量对于一篇简短的摘要来说可能过于冗余。K7L (对话) 2014年1月20日16:25 (UTC)

你说得对，在空荡荡的章节中可能会感觉空虚。我不确定 Lua 等是否可以检测章节的长度以调整要显示的图像数量。注意：当POI在维基数据中时，看/做/买/吃/睡章节的大小在不同语言之间不会有太大差异。Nicolas1981 (对话) 2014年1月21日03:19 (UTC)

（这是来自小型语言版本的一条评论）我不明白这个提案的意义。图片是用来辅助内容的。如果某个语言版本的内容很少，为什么要从高质量的英语或德语文章中获取所有图片呢？此外，图片需要说明文字，但英语说明文字在波兰语维基导游中毫无意义。可以考虑编写一个机器人来促进图片传输，就像最近讨论的列表传输一样，但这应该始终在人工控制下进行。而且这不需要涉及维基数据。——Alexander (对话) 2014年1月20日18:18 (UTC)

很抱歉，我没有看到这有什么好处。图片是文章中唯一一个无需理解文章内容就能轻松从一种语言传输到另一种语言的功能——只需点击图片即可查看图片页面，然后从中复制标题。AlasdairW (对话) 2014年1月20日22:30 (UTC)

点击和复制粘贴很容易，是的。几个月前，我们还在手动在语言之间复制粘贴横幅，那甚至更容易。但这对于15000篇文章来说是不可持续的。Nicolas1981 (对话) 2014年1月21日03:19 (UTC)

你打算如何将这个模板输入到这15,000篇文章中？会是机器人吗？你将使用什么标准来确定是否应该使用这个模板？谢谢！Andrewssi2 (对话) 2014年1月21日03:34 (UTC)

是的，一个机器人会添加模板（例如在See部分添加{{images_see}}）到所有尚未有图像的章节。最困难的是开发一个图例编辑器（有点像列表编辑器，但只有一个文本字段，并且可能显示其他语言的图例以供参考）。Nicolas1981 (对话) 2014年1月21日05:57 (UTC)

我对此不太确定。一个问题是合理使用图片的管理；我意识到关于它们的使用一直存在一些争议，但它们有合法的使用途径，不能上传到维基共享资源，必须在本地处理……——Rschen7754 2014年1月21日09:07 (UTC)

我现在翻译的时候，只是重复利用同样的图片，到目前为止还没有遇到麻烦……无论如何，任何可能无法使用的图片都会留在模板之后。当尝试在维基数据中插入图片时，维基数据甚至可以检查其许可证是否正确，因此这比非维基数据图片复制更有优势。Nicolas1981 (对话) 2014年1月21日13:22 (UTC)

放置图片的位置可能仍需手动决定，因为文章长度的差异以及英文维基导游中缺少{{Info Ville}}都会影响页面上的可用空间（以及位置）。K7L (对话) 2014年1月21日16:36 (UTC)

你好Nicolas1981。我只是想说，我认为你为增强WV并研究我们如何利用维基数据优势提供了很多想法，这真的很棒。尽管对于图片想法，这个帖子中的反响不那么热烈，但我仍然希望看到你更多的想法。Andrewssi2 (对话) 2014年1月22日01:35 (UTC)

GAC申请包括一个“维基导游竞赛”

委内瑞拉预备分会正在申请资金，其中一部分将用于所述竞赛（见“第一点”）。人们只能推测他们指的是西班牙语维基导游。这表明en.WV社区有机会识别可能对合作开发和/或实施此类竞赛感兴趣的WMF附属机构。Tony (对话) 2014年1月21日08:19 (UTC)

谢谢Tony，提请我们注意——并祝您新年快乐！——118.93nzp (对话) 2014年1月21日08:25 (UTC)

感谢Tony的提示！我认为推广专门为维基导游拍摄照片的想法是个好主意，因为这种照片（氛围、活动、人群，更生动，我不知道）在维基共享资源上很难找到。当我上传一张建筑物的照片到维基共享资源时，我会想“我要正交拍摄，让每个细节都清晰可见”，但对于维基导游来说，我会想“我要用主观视角拍摄，当卖冰淇淋的小贩经过，孩子们和小鸟玩耍时”。与维基百科不同，我们通常试图让人们想去那里旅行。Nicolas1981 (对话) 2014年1月21日12:14 (UTC)

WLM（和GLAM相关事务）是分会特别擅长的事情之一；这与参与可能的维基导游竞赛类比。也许通过选定的代表，这个社区可以通过GAC与一个涵盖您认为在en.WV（以及其他WV，特别是当选定区域的主要语言是另一个WV的语言时）有很多改进空间的分会共同申请会很有效。最初需要解决的问题包括范围（正如Nicolas指出的），以及WLM是否有现有记录（最近的WLM竞赛有50多个国家参与）。您需要资金用于访问摄影地点的交通和相关费用，可能还需要相机和三脚架（如果该地区有问题），以及奖品和当地仪式。您需要考虑视频是否可以成为其中一部分（我不知道，但一些文化展示，如舞蹈、游行，可能适合视频（您在WV上有视频吗？）WV可以提供关于需要什么以及哪种类型的图片适合本站的指导（与WPs不同，例如）。版权问题，如全景自由，需要在入围可能接触的分会时确定。Tony (对话) 2014年1月21日12:39 (UTC)

听起来像一项巨大的工程……旅行维基的好处在于我们中的一些人会在某个时候去那里旅行，为了个人乐趣，通常会带着相机。所以如果真有比赛，它可能会和WLM竞赛有所不同。Nicolas1981 (对话) 2014年1月21日13:16 (UTC)

模板要求避免在讨论页上过多谈论政治

我注意到在讨论:克罗地亚页面上有一个免责声明框，要求人们不要在一个敏感的文章中过多地涉及政治。我从中创建了一个模板并逐字使用了相同的文本

这里不是政治论坛；请将所有讨论限制在如何最好地改进瑞士文章的讨论上。离题的辩论、政治咆哮、无意义的诗歌等都将被移除。这是一本旅行指南，政治争议除了直接影响旅行者体验之外，完全无关。更多指导请参见Wikivoyage:公平#政治争议。

请注意，这仅适用于少数敏感的讨论页面，而非主文章。

如果有人想帮助改进文本，请随时加入。Andrewssi2 (对话) 2014年1月22日01:43 (UTC)

不幸的是，全球旅行并非在真空中进行……我们确实必须承认对旅行者有影响的当地政治局势。忽视朝鲜的政治局势，或者不提及叙利亚是一个战区，将是鲁莽的，即使有时它会变成WV:NCO。K7L (对话) 2014年1月22日02:15 (UTC)

我不是建议完全删除政治内容（“要求人们不要过多参与政治”）。这只是提醒贡献者WV的范围。

正如我所说，我只是使用了原文（不是我的），因此请将其修改为适合WV的措辞。Andrewssi2 (对话) 2014年1月22日02:23 (UTC)

当然，我们会继续从旅行者的角度讲述事情，但这个模板对某些讨论页面来说可能是一个有用的温和提醒……不过，我确实认为一个更实用的模板是指定文章是使用哪种语言变体撰写的（或应纠正为哪种），适用于那些不明显的目的地，如以色列、伯利兹或英属维尔京群岛……——118.93nzp（talk） 2014年1月22日02:26 (UTC)

谢谢118.93nzp。这确实是一个温和的提醒，而不是指令。Andrewssi2（talk） 2014年1月22日04:18 (UTC)

我认为这个模板的目的是/应该是尝试让讨论与Wikivoyage和Wikivoyage文章相关，而不是添加一些关于国家政治或文化的无关主题的抱怨。——Rschen7754 2014年1月22日18:54 (UTC)

我相信强调Wikivoyage所有最重要和最紧迫的问题都可以通过在讨论页面添加更多模板来解决，这是一件好事。PrinceGloria（talk） 2014年1月22日20:19 (UTC)

讨论页面模板，用于指示英语语言变体

据我所知，所有Wikivoyage文章都使用英联邦（英式）或美式英语。这种决定似乎主要基于该国与英国或美国的历史联系，如果没有明确的关联，则默认使用英联邦英语。

时不时会有新的贡献者来到Wikivoyage，当他们遇到美式拼写时会看到红色标记，然后我们不得不花一些时间解释和清理。

118.93nzp曾问（我推断他的评论）我们是否可以在某个国家的讨论页面放置一个模板，以指示应该使用哪种英语形式？

这样的模板有用吗？特别是对于“灰色地带”如中国和以色列？Andrewssi2（talk） 2014年1月22日04:35 (UTC)

只是一个小小的更正：如果文章与另一种变体（例如澳大利亚、加拿大、印度等）没有明显关联，目前应默认使用美式英语。

[许多年前，亲美阵营做出两项妥协/让步，才达到这种局面：

1) “traveller”和“travelling”这两个不常见的美式拼写应在所有地方优先于“traveler”和“traveling”使用，

2) 日期默认为dd Mmm yyyy格式（例如：2014年5月22日），类似于这里每个人签名中的时间戳格式。]——118.93nzp（talk） 2014年1月22日04:41 (UTC)

据我所知，“traveller”的偏好是一种矫揉造作，只适用于项目空间。Powers ^(talk) 2014年1月22日13:24 (UTC)

如果连这个小点都有歧义，那么我们可能应该把讨论转移到Wikivoyage的另一个部分。有什么建议吗？Andrewssi2（talk） 2014年1月22日14:23 (UTC)

并非所有内容都需要详细说明。我们社区的理念一直是，拼写、语法和其他琐碎细节次于，且远不如生成良好、可读且有用的旅行内容重要。这是一个“小点”意味着它的歧义不那么重要。Powers ^(talk) 2014年1月22日15:29 (UTC)

我非常想禁止在Wikivoyage上使用“kilometer”一词。它在美国不常用，因为他们仍然使用英里；在其他任何国家也都不正确，因为“metre”是长度单位，而“meter”是测量设备。K7L（talk） 2014年1月22日15:46 (UTC)

我完全同意。在大多数地方，我用其普遍已知的符号km代替。同样，对于作为测量单位的meter，m是普遍理解的。除了历史性妥协，Powers的总结大致正确。然而，令人惊奇的是，那些声称对这些缩写和语法小事漠不关心和蔑视的人，往往花费大量精力阻挠和挫败那些花费大量时间校对这些琐事的人；并不是每个人都能成为狄更斯或麦尔维尔……——118.93nzp（talk） 2014年1月22日16:59 (UTC)

我认为对于大多数国家来说，语言变体已经达成一致，不是吗？所以一个模板主要会起到指导人们使用哪个版本的作用？我们不应该忘记，对于许多在这里贡献的人来说，英语是第二、第三或（在我的情况下）第四语言。对于母语者来说，英语变体之间的区别是如此自然，但对于许多其他人来说则不然。我喜欢一致性，并且完全接受关于在哪些文章中优先使用哪个变体的规则，但我确实认为当人们使用错误版本时，我们需要非常宽容，并且在模板或其他地方指导特定版本时，措辞要深思熟虑。我们希望做的是阻止“纠正”一个版本到另一个版本，我们不希望阻止人们在不确定拼写时贡献。我知道我并不总是一致的，说实话，我对 meters 和 metres，centres 和 centers，travel(l)ers，sizable 和 sizeables 以及所有其他东西感到困惑。我很高兴有校对人员比我查阅的速度快得多地纠正我的错误。但我更高兴的是普遍的理解，即这些细节与我们创建良好旅行信息的目​​标相比并不重要 ;-) JuliasTravels（talk） 2014年1月22日22:13 (UTC)

萧伯纳曾说：“英格兰和美利坚是被一种共同语言分隔的两个国家”——这对全世界的英语使用者来说千真万确。我认为我们受过足够的教育，能够意识到拼写和语境的差异，但不要过于投入或紧张。我只对这些词稍加注意，因为我会说四种不同的语言。旅行文章才是更需要关注的。我们可以随时添加一个单独的页面，列出常见的变体，供那些无法弄清这些事情的人参考。维基编辑器也会通过给这些词加下划线来提醒人们注意变体……（偏向美式英语）……只是关于这个话题的一点想法。Matroc（talk） 2014年1月23日00:12 (UTC)

我相信那是你的浏览器在标记拼写错误的词，而不是维基软件。=)Powers ^(talk) 2014年1月23日00:47 (UTC)

Powers 的观点很有趣。如果我用英式英语编辑，我的浏览器会用漂亮的红线标记一些词。虽然这对我来说不是问题，但我情不自禁地觉得这会对非英语母语的贡献者不利。Andrewssi2（talk） 2014年1月23日01:03 (UTC)

啊，你会说英语是吗？老兄，试试这个……https://addons.mozilla.org/en-US/firefox/addon/british-english-dictionary/ :) K7L（talk） 2014年1月23日04:37 (UTC)

是的，我知道我应该说浏览器 ;)- Firefox从2.0版本开始就有了拼写检查功能——我安装并选择了正确的字典，勾选了拼写检查，并选择了正确的语言。有独立的字典，比如英语/美国，英语/英国等等。——很高兴“唤醒沉睡者”(们)_沙丘——新年快乐！——Matroc（talk） 2014年1月23日06:39 (UTC)

那么，模板实际上可以引导用户找到该字典吗？（针对Mozilla用户）Andrewssi2（talk） 2014年1月23日07:02 (UTC)

模板可以指向任何东西，但我想说这种一般的外部链接（确实有几个，针对不同的浏览器）不属于每个讨论页面。在某个特定文章上进行大量工作时，可能会更改它，但我们很难要求编辑者每次进行微小添加时都不断更改他们的字典。我想我宁愿不在讨论页面上对此大做文章，而是当人们过多地使用“非首选”版本时，引导他们去相关的政策页面和讨论。但也许你应该指出你设想的模板文本是什么样的，这样我们才能讨论同一件事？JuliasTravels（talk） 2014年1月23日08:22 (UTC)

现在看来很明显，并没有大量的Wikivoyage用户迫切需要这个功能，所以我想我现在就认为它已经被讨论过了，并且让它过去吧。 :) Andrewssi2（talk） 2014年1月23日09:32 (UTC)

许多列表使用了错误的模板（例如，“景点”是一个“美食”）

各位，

我注意到许多列表都使用了错误的模板，例如餐厅使用了{{See}}。有没有这种情况是故意的？有没有哪种情况是“美食”列表故意不使用{{Eat}}，或者{{Eat}}不在“美食”部分？

谢谢！Nicolas1981（talk） 2014年1月23日04:15 (UTC)

在“景点”、“活动”、“购物”、“餐饮”、“饮酒”、“住宿”这六个部分中的任何一个列表，都应始终具有相应的类型（景点、活动、购物、餐饮、饮酒、住宿）。那里的错误模板可能是错误或项目移动（例如，将“英式酒吧”从“餐饮”移至“饮酒”）的结果。在任何其他命名部分中的列表可以是任何类型——尤其是在行程中，其中部分标题按地理顺序而不是景点/活动/餐饮/住宿类别排列。K7L（talk） 2014年1月23日04:58 (UTC)

谢谢！有什么工具可以修复或至少检测这些问题吗？有人在开发这样的工具吗？Nicolas1981（talk） 2014年1月23日06:08 (UTC)

并非所有列表都已模板化，许多仍使用星号 (*) 项目符号。http://tools.wmflabs.org/catscan2/catscan2.php 可以帮助我们找到那些仍没有“景点”、“活动”、“餐饮”和“住宿”模板列表的文章（或至少缩小范围）。Andrewssi2（talk） 2014年1月23日07:00 (UTC)

谢谢！我想所有尚未开发的文章都会是假阳性。Nicolas1981（talk） 2014年1月24日08:41 (UTC)

我认为咖啡馆被列在景点列表中的可能性是有的，但不大。我指的是大型付费景点，如主题公园或动物园，里面有餐饮场所。由于需要付费才能进入公园，它们可能不应该出现在主餐饮部分，但我们可能希望在地图上显示餐饮符号，并在公园相关部分提及它们。AlasdairW（talk） 2014年1月24日23:51 (UTC)

说得好，但在这种情况下，兴趣点可能会以连续的散文形式出现，最好使用{{marker}}模板，这样侵入性的小灰色“编辑”文本就不会中断散文，但相应的符号仍然会出现在地图上。——61.29.8.41 2014年1月25日00:12 (UTC)

另一次远征？救援远征？

我不知道这以前是否讨论过，但如果讨论过，我怀疑是否已经解决。有时我们的重要文章（特别是那些处于指南状态且之前在主页上展示过的文章）会过时且不如以前发达，但这足以成为将其从指南状态文章降级的充分理由和良好决定吗？完全不是！如果一篇特色指南状态的文章过时，该文章必须得到改进和妥善处理，而不是简单地降级。事实上，特色文章不应被降级，毕竟，曾经为此付出了很多努力。

实际上，我自己最近降级了几篇存在风格、格式和过时问题的特色文章。我相信这不公平，但这似乎符合Wikivoyage的最佳利益。毕竟，我们的使命是“完整、最新、可靠的全球旅行指南”，而一篇过时或格式不佳的文章，顶部右上角有一个以前的特色符号，会给我们的用户和读者留下不好的印象。

所以，我不知道我们是否需要另一次远征来解决这个非常重要的问题。毕竟，我们维基上已经有很多远征，而且大多处于不活跃状态。因此，如果大家大力支持开展这样的远征，或者我们有其他解决方案，那将是极好的，我作为地图制作人也愿意尽我的那份力。我只能做这些。除了迪拜，我没有去过那些文章被降级的地方，所以我不知道该添加什么内容来挽救一篇文章，我也不擅长格式化和改进风格。最后，我想说挽救一篇文章——挽救Wikivoyage的标准。——Saqib（talk） 2014年1月25日17:33 (UTC)

我支持这项工作。我不知道我在收集最新信息方面能有多大用处，但我绝对可以在风格和格式问题上出一份力。——AndreCarrotflower（talk） 2014年1月25日18:08 (UTC)

迪拜一文在2008年初被评为本月目的地，但后来该文章变得非常过时，因此我去年不得不将其降级。迪拜是全球第七大访问量最大的城市，所以其文章处于指南状态肯定很重要。最近，该文章已经进行了分区（感谢我们已退休的编辑Jan发起的分区讨论），最近，Nurg访问了迪拜，并对迪拜及其分区做出了重大贡献。我在迪拜生活了很多年（事实上仍在生活），我认为该文章非常接近重新获得我去年剥夺的指南地位。关于迪拜地图，它缺少地图，但我最好现在不要制作地图，因为“迪拜区域边界的讨论正在进行中”。——Saqib（talk） 2014年1月25日21:02 (UTC)

这个问题确实值得关注。但我确实认为你对远征的看法是正确的。此外，正如安德烈所说，如果你不了解那个地方，修复内容并不总是那么容易，所以我不太确定远征是理想的方式（尽管我不知道是什么，也许是一个模板？）。即使你能找到愿意加入的人，他们中可能没有人了解那些特定的地方。你能举几个你曾经降级过且需要救援的特色文章的例子吗？JuliasTravels（talk） 2014年1月25日21:12 (UTC)

你说得对，所以我才在我的帖子中说，要么需要一次远征，要么需要一个解决方案。天哪！我发现了很多以前的本月目的地（撇开OtBP和FTT不谈），它们都被降级了：停泊岛、危地马拉城、新奥尔良、墨尔本、2005年世博会、爱丁堡、吉隆坡、布达佩斯、拉巴斯、台北、芭堤雅、长滩岛、死亡谷国家公园、塔什干、福克兰群岛（提纲）和埃尔西诺（提纲，尽管有疑问）。我只降级了2或3个，但我不知道是谁降级了其余的。——Saqib（talk） 2014年1月25日22:01 (UTC)

爱丁堡在2010年9月被降级，当时的评论是“抱歉，由于分区仍为提纲，无法作为指南”。我不确定这是否是一个有效的理由，而且今天只有一个分区爱丁堡/东区是提纲。也许其他人想看看，如果他们同意，就改回来。AlasdairW（talk） 2014年1月25日23:36 (UTC)

它是由我们的一位管理员User:ClausHansen降级的，尽管该文章及其分区文章非常详细，但自2010年9月以来它们没有太大变化，因此最好由最了解该地的人查看这些文章，然后决定是保持可用状态还是将其重新提升为指南。——Saqib（talk） 2014年1月26日00:02 (UTC)

还可以通过查看Wikivoyage:World cities/Large来查找需要关注的文章，该列表包含了世界上最大的100个城市，或者查看联合国教科文组织世界遗产名录。大型城市列表可以通过各种方式排序以发现更多信息；例如，按F列排序显示，访问量最大的20个城市中大约有一半的文章仍处于提纲状态。Pashley（talk） 2014年1月25日22:15 (UTC)

我不太确定所有这些都被降级了，Saqib。早些年，对特色文章的要求与现在不同。我想其中一些文章一开始就从未达到我们现在所说的指南状态 ;-) JuliasTravels（talk） 2014年1月25日22:21 (UTC)

茱莉亚。你说得对。同样的事情目前也发生在意大利Wikivoyage上。他们当前的本月目的地文章按英文Wikivoyage的标准仍处于提纲状态。而且，即使文章以前在主页上展示过但没有达到指南状态，我认为我们也应该努力将其提升到指南状态，否则，如果我们无法将以前的特色文章恢复到指南状态，就直接从该文章中移除特色图标。事实上，维基百科也在这样做。他们只是降级了（如果文章过时了，曾经是特色文章）并移除了文章右上角显示的特色文章图标。维基百科不妥协质量，我们为什么要妥协？——Saqib（talk） 2014年1月25日22:38 (UTC)

嗯，那并不是一个很好的比较：维基百科的特色文章是我们称之为星标文章的。我们也有星标文章的“降级”选项，在这种情况下，文章会失去星标图标。在这里删除以前的特色图标，我认为会很奇怪：它只是历史的一部分。尽管如此，你提出这个问题是好的，如果其中一些文章能够被完善以符合我们当前的标准，那就太好了 :-) JuliasTravels（talk） 2014年1月25日22:53 (UTC)

好吧，但我可以把我们的指南文章和维基百科的“优良文章”相提并论吗？他们也会降级他们的优良文章并移除图标。无论如何，我也不赞成移除我们以前的特色文章中的图标。我提出这个问题是为了挽救这些文章，而不是为了移除图标。我希望能有一个解决方案来解决这个问题。——Saqib（talk） 2014年1月25日23:02 (UTC)

致 JuliasTravels: Saqib纠正他的类比是正确的：Wikivoyage的星级文章类似于维基百科的“优良文章”，而不是“特色文章”。然而，我认为重要的是要注意，到目前为止，Saqib一直在谈论指南文章。正如你所提到的，任何发现星级文章不再符合标准的人都必须提名该文章进行降星，这必须像将文章提升到星级地位一样进行审议。通常，提名文章降星的行为就足以促使社区做出必要的修改。然而，指南文章也相当不错，而且与星级文章不同，它们可以单方面降级而无需协商。我认为探索如何防止它们被降级是完全值得的，我认为一次远征——前提是我们能长期保持对它的兴趣；我承认这很困难——是解决这个问题的任何好方法之一。——AndreCarrotflower（talk） 2014年1月26日01:00 (UTC)

当然，Andre，这个比较是准确的，而且文章的“可用”或“指南”状态确实可以轻易更改。然而，他给出的所有例子都已经不处于指南状态——有些是因为后来被降级，有些是因为它们从未成为指南。所以这并不是降级或不降级的问题。我们的“以前的特色图标”与指南或可用无关：它只说明该文章曾被刊登在主页上。即使我们现在认为这样的文章不合适，这一部分仍然是真实的。（澄清我的评论：图标问题当然不是主要问题）。

所以我们主要遇到的问题是，我们曾经在主页上刊登过的文章，但现在不符合指南标准。我认为Saqib说得很有道理，许多这些文章由于以前是特色文章而值得某种优先关注，但对于其他一些文章也是如此，例如“访问量最大的目的地”、“我们网站上最常请求的文章”等等。我并不反对一次远征，我只是认为我们都知道要保持一次远征活跃有多难，尤其是在内容方面。只是头脑风暴……制定一个更广泛的“高优先级”文章列表/远征，需要加以完善，这会是一个好主意吗？例如访问量最大的、以前的特色文章、使整个地区可用的关键文章等等？如果范围更广，人们可能会更容易加入。我们也可以从中选择一个月的合作项目。只是一个想法。JuliasTravels（talk） 2014年1月26日12:18 (UTC)

我担心一次远征可能会失败。也许复活CotM会是个好主意，并且与其提名，不如直接列出以前是特色文章但现在处于可用状态的文章，然后按照我们以前的方式进行处理。参见Wikivoyage_talk:Collaboration_of_the_month#Outdated.2C_again。——Saqib（talk） 2014年1月26日15:12 (UTC)

正如我所预料的，这次讨论以没有任何结果或结论而结束了。我认为一开始提出这个问题就是浪费时间。无论如何，Andrew，这个页面说“维基百科的特色文章是Wikivoyage的星级文章或本月目的地文章”，但没有提到维基百科的优良文章，而你上面说我们的星级文章与维基百科的优良文章相似。我认为最好先解决这个问题。维基百科的特色文章是他们最好的作品，而我们的星级文章是Wikivoyage最好的作品。如果我们的星级文章与维基百科的优良文章相似，那就意味着我们最好的作品与维基百科的（非最佳）作品相似。这令人困惑！——Saqib（talk） 2014年2月3日12:45 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘萨奇布，我认为你主动提出协助绘制静态地图真是太棒了。尽管我们的新动态地图为在线用户提供了许多优势（而且{{mapmask}}的开发可能会将其用处扩展到显示我们自己创建的区域和地区），但对于希望获取纸质副本（当然还有离线用户）的读者来说，它们可能永远不如静态地图。

我离开了一段时间，所以我想借此机会评论一下，看到你的管理员工具因与滥用管理员工具无关的“罪行”而被移除，我感到多么悲伤。最终，随着搜索引擎的普及，我们的公共知名度将提高（即使我们确实因为缺乏活跃的SEO而不断自食恶果），届时我们将“全员出动”来抵御垃圾邮件机器人的洪水。在我离开的这段时间里，当我查看“近期更改”时，我已经注意到垃圾邮件机器人账户的数量有所增加。

一个似乎在这里严重缺乏的东西是，人们没有意识到我们的大多数文章在某些常见的屏幕尺寸和分辨率下实际上看起来有多糟糕。我回家后，当我有更快的网络速度时，我会稍后发布一些截图，但有许多视觉异常需要纠正。我认为这种审美上的“盲区”主要是由于我们许多最常贡献的作者主要在大屏幕上处理维基文本差异，而不是检查最终结果。——61.29.8.41 2014年1月25日23:25 (UTC)

既然你支持动态地图，我希望这次讨论不会偏离主题。我只想在这里讨论这个话题，别无其他。——Saqib（talk） 2014年1月25日23:44 (UTC)

维基百科以前有“本周协作”或“本月协作”，但这两个项目现在都已停止。现在是Wikipedia:Today's articles for improvement。我认为我们应该考虑进行一次类似的远征，识别我们的最高优先级页面，并将其改进到我们当前的标准。Edge3 (talk) 2014年1月26日 14:05 (UTC)

这个讨论快要结束了，所以我想在这里更新一下。迪拜条目已得到拯救，现在可能已恢复到指南状态。--Saqib (talk) 2014年1月28日 13:11 (UTC)

特色条目标识

关于一个相关问题：是否有可能在跨语言链接列表中添加一个星号，表示某个条目以某种方式被推荐，例如星标、本月之最或指南状态，具体取决于各语言版本的传统？基本上，这是两个问题合二为一：i) 如何实现？ii) 我们是否需要这个机制？它可能有助于优质内容的翻译…… --亚历山大 (talk) 2014年1月26日 08:55 (UTC)

好主意。我不是图形设计专家，但一个简单的方法是使用一个由公认的两个字母的语言缩写组成的符号，例如“RU”代表之前在俄语 Wikivoyage 上的特色条目。Ikan Kekek (talk) 2014年1月26日 13:39 (UTC)

抱歉，我没明白。亚历山大，你是说我们应该在文章的右上角添加一个图标（星标、本月之最或指南状态），如果同一篇文章在其他维基导游语言版本中是星标、本月之最或指南状态？还是你建议我们，当同一篇文章在其他维基导游版本中是特色、星标或指南状态，但在本维基导游版本中是概述或可用状态时，就添加图标？--Saqib (talk) 2014年1月26日 14:49 (UTC)

我的意思是和维基百科一样的系统。我们的左侧面板有一个跨语言链接列表。如果一篇文章在波兰维基导游被推荐，那么在所有其他语言的“波兰语”链接旁就会显示一个星号。--亚历山大 (talk) 2014年1月26日 14:54 (UTC)

哦，好的，这是个好主意，但像维基百科那样用一个星号就足够了，而不是用缩写图标。--Saqib (talk) 2014年1月26日 15:05 (UTC)

我不记得在维基百科上见过这种指示。如果有人能发布相关文章的链接，那就太好了。Ikan Kekek (talk) 2014年1月26日 15:09 (UTC)

我没明白。抱歉！--Saqib (talk) 2014年1月26日 15:14 (UTC)

Ikan，这里是维基百科文章的一个例子；请看左侧的语言部分。ϒpsilon (talk) 2014年1月26日 15:23 (UTC)

维基百科英文版中关于特色文章和优秀文章的大多数指示都显示在创建者用户页的右上角，它们几乎每次都看起来非常杂乱，然而，如果它像Ypsilon所指示的那样是一个不显眼的标记，那么应该鼓励和使用它——不引人注目但信息丰富。sats (talk) 2014年1月26日 15:30 (UTC)

亚历山大，我认为我们必须创建一个像这个一样的模板，然后手动将模板添加到所需的文章中。--Saqib (talk) 2014年1月26日 15:33 (UTC)

这更关乎 Common.css 的更改。模板本身不是必需的，因为我们已经有星标和 DoTMs 反映在 {{pagebanner}} 中。问题是这个特殊的“id”是否能在 Wikivoyage 上用于特色文章。必须尝试一下... --Alexander (talk) 2014年1月26日 15:50 (UTC)

谢谢你的链接，Ypsilon。看起来只要像维基百科文章那样在侧边栏添加星号就显而易见了。但如果我们要显示该文章曾在其他语言版本首页被推荐，就必须使用另一个符号。Ikan Kekek (talk) 2014年1月26日 16:00 (UTC)

不如用一个月桂花环，表示该文章以某种方式在这门语言中受到特别认可。Nicolas1981 (talk) 2014年1月26日 16:25 (UTC)

我看到一个主要问题。维基百科特色条目机制要求在每个语言版本中添加相应的模板。当然，这从未发生过。需要通过维基数据实现…… --亚历山大 (talk) 2014年1月26日 16:32 (UTC)

这项工作正在进行中，希望能尽快完成。--Rschen7754 2014年1月26日 18:33 (UTC)

我们的横幅正在维基导游之外被重新使用 :-)

我们的横幅正在被其他项目充分利用 :-)

请看Reasonator：http://tools.wmflabs.org/reasonator/?q=Q350 横幅来自 Wikivoyage。

有了维基数据，您的贡献惠及的人将比以往任何时候都多，甚至是以您在贡献时从未想象过的方式。Nicolas1981 (talk) 2014年1月26日 16:13 (UTC)

每篇文章再加一张图片？

维基数据有一个城市的“图片”字段。例如，维基百科的信息框会使用这些图片，请看https://en.wikipedia.org/wiki/Cambridge 右上角的图片。这些图片总是展示城市的美丽景色或其最著名的地标，且天气晴朗。

那么在维基导游中重复使用这张图片如何？

也许我们1%的文章图片够多（甚至太多），但99%的文章都急需更多图片。

所以：缺点是我们必须为少数文章进行调整，但收益巨大，我认为非常值得。

你觉得呢？Nicolas1981 (talk) 2014年1月27日 02:50 (UTC)

我一直对此保持沉默，但现在我非常怀疑维基数据在越来越多的用户中催生的一刀切、流水线式的内容处理方式。我们已经用维基数据标准化了所有使用页面横幅的语言版本对同一目的地的页面横幅选择，似乎没有停下来考虑英文维基导游是否因此抢先讨论，而这些讨论如果发生，很可能会导致对使用哪张图片产生不同的共识。我们已经讨论过将列表移至维基数据，似乎也没有停下来考虑某些景点可能与某些语言社区相关，而与另一些社区无关。我们还在讨论标准化各语言版本的部分图片，似乎也没有考虑其他维基导游社区是否更喜欢不同的替代方案。

我说“似乎”是因为，虽然我没有听说有任何迹象表明 MediaWiki 中存在一种机制，允许各个社区在他们愿意的情况下偏离维基数据上的预设选择，但这并不意味着不存在这种机制。如果我错了，我为此道歉并撤回此声明。

我认为维基数据在某些情况下当然可以成为一个有价值的工具，但如果我们不认真限制我们使用它的情景范围，我担心维基导游会变成麦当劳，所有的原创性都被标准化和自动化地从产品中剔除，作者的角色被简化为仅仅是将信息转录到预设模板中。相反，我希望维基导游成为一家美食高级餐厅，才华横溢的作者创作出引人入胜的文章，以艺术的、有点不同寻常（并有望更好）的方式吸引读者，而不是在其他地方找到的内容。我想写作；我不想做数据录入。而且我当然不想自作主张地告诉德语、法语、意大利语等语言版本什么对他们最好。

-- AndreCarrotflower (talk) 2014年1月27日 03:22 (UTC)

AndreCarrotflower，写得非常精彩，分析透彻！ Bravo！--150.101.89.130 2014年1月27日 08:55 (UTC)

如果一篇文章没有引言图片，我倾向于插入维基数据中已有的图片，因为理论上自动包含图片比没有图片要好。我认为Andre对过度依赖维基数据的担忧值得警惕，但我们也应该努力整合不同语言版本之间不变的数据，以简化维护。我还认为使用维基数据来设置横幅等事物的“基础”数据集是一个积极的方面——例如，新的语言版本可以以所有文章都有横幅的形式启动，并根据需要进行覆盖。希望维基数据界面最终能发展到我们可以在英文维基导游上查看一篇文章，并有一个标签或其他UI元素，允许我们查看该文章所有来自（并可用于）维基数据的数据，以便我们轻松选择要包含的内容，但这可能还需要几年时间。-- Ryan • (talk) • 2014年1月27日 03:39 (UTC)

作为维基数据的管理员和监督员，我当然支持在任何有效的地方使用其数据。

然而，我并不相信这种特定的使用是有效的；首先，在实现层面上，我不确定这是否可行。--Rschen7754 2014年1月27日 03:57 (UTC)

我们不考虑图片，而考虑那些不主观且在语言和社区之间同样适用的数据如何？

关于气候数据怎么样？将一个地点的每月降雨量、温度和湿度水平集中在维基数据中是否是一个引人注目的用例？Andrewssi2 (talk) 2014年1月27日 04:32 (UTC)

那是个好主意！Ikan Kekek (talk) 2014年1月27日 05:03 (UTC)

我甚至不会说我反对维基数据被用于更主观的事物，除非在每个单独的实例中都有一个简单的方法来选择退出。我记得几个月前，维基数据的一个小故障导致锡拉丘兹（意大利）的页面横幅被用于锡拉丘兹（纽约）。虽然问题很容易解决，但挥之不去的问题是，如果有人偶然发现了完美的图片作为这些文章的新页面横幅，并能直接使用，而无需经历一个繁琐、缓慢的跨语言官僚机构，我仍然不知道如何实现。-- AndreCarrotflower (talk) 2014年1月27日 06:15 (UTC)

我们都努力为这里的所有文章制作美食佳肴。但这需要数年时间。与此同时，确保所有目的地至少可口如何？

质量：维基数据的图片字段比麦当劳级别更好 :-)

可实现性：今天在法语维基百科上实现了。

编辑战：与其从维基数据已有的精选图片开始，不如让英文维基导游成员之间因寻找20,000张新合适图片而产生更多争议。

迎合不同社区：这只是我的看法，但我认为我们的目标是普遍的。有些英语社区之间的文化差异比某些西班牙语社区之间的文化差异更大。例如，宗教可能比语言更能造成文化差异，但没有人会考虑将维基导游分成宗教团体。让我们面对现实吧，如果全世界只有一种语言，那么就只会有一个维基导游……这意味着拥有多个维基导游是技术上的必然，而不是更高的目标。为什么要把这种技术上的必然性输出到非语言领域呢？

“英文维基导游抢先了”：据我所见，其他语言很乐意协作，并在不适合时直接覆盖维基数据的值（是的，选择退出很容易）。

干杯！ :-) Nicolas1981 (talk) 2014年1月27日 08:33 (UTC)

维基百科上许多主要城市图片（只有一部分编码在维基数据中）是蒙太奇（例如：File:Boston Montage.jpg），这违反了我们的图片政策。Powers ^(talk) 2014年1月27日 14:54 (UTC)

这确实是一个有力的反驳！我不知道维基百科是否允许这种蒙太奇图片，我能找到的最接近的政策是https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Collages_and_montages，它说“如果画廊和拼贴画一样有效，应首选画廊”。实际上，我可以通过编写一个小算法来识别图片是否是蒙太奇，这会很有趣 :-) Nicolas1981 (talk) 2014年1月27日 16:14 (UTC)

没有主图的页面通常意味着内容也较少，所以在这类文章上放置图片并没有太大意义。通常，随着内容的增加，图片也会随之增加，要么是添加内容的人上传，要么是文章内容足够时，有人（仍然可能是添加内容的人）会寻找图片。文章没有或内容很少，如果缺少图片，我不会觉得困扰。我喜欢图片自然而然地添加。没有图片也可以鼓励贡献者上传他们自己的新图片。ChubbyWimbus (talk) 2014年1月27日 16:40 (UTC)

我与LtPowers、ChubbyWimbus和其他人一样担忧。我认为在这里，个人、有机的做法更好。我们的空文章不会真正受益于向读者展示他们一点击维基百科就会看到相同的主图来寻找实际信息。Texugo (talk) 2014年1月27日 17:59 (UTC)

国家文章中空置的“看”和“做”部分

你是否注意到，在相当多的国家或“与国家相当的地区”文章（如泽西岛）中，“看”或“做”部分，或两者都为空，尤其是在那些很少有游客的地方。在我看来，这些是最重要的部分，所以它们为空（尤其是“看”部分）是一种遗憾。召集一次远征可能有点太多了，但如果你发现这样的文章，请随意用几句话填充这些部分。如果该国有一些联合国教科文组织世界遗产地，这些遗址显然是合适的候选。你当然也可以点击城市和其他目的地，看看它们的“看”和“做”部分是否有任何有趣的内容可以在国家文章中提及。ϒpsilon (talk) 2014年1月27日 05:35 (UTC)

内容优先确实如此！有一些人（包括我）一直在积极地致力于国家看点部分的编辑，作为Wikivoyage:Country surgeon Expedition的一部分。不幸的是，尽管几乎所有人都认为这很重要，并且很多人报名参加，但只有少数人真正贡献了时间。然后又有很多关于迁移的事情。我很高兴你再次提起了这个问题 :-) JuliasTravels (talk) 2014年1月27日 10:20 (UTC)

动态地图问题

为什么现在动态地图都看不见了，除非点击它们？我希望其他人也有同样的问题。Ikan Kekek (talk) 2014年1月27日 06:02 (UTC)

内部页面框架出现了一些稳定性问题，并且“被拔掉了插头”。希望这个问题能在接下来的几周内解决。Andrewssi2 (talk) 2014年1月27日 06:15 (UTC)

我希望如此。这是个相当严重的问题。谢谢你的解释。Ikan Kekek (talk) 2014年1月27日 06:25 (UTC)

这是一个严重的问题。我首先想给这些开发人员一个机会，让他们在没有压力的情况下解决问题，但之后我们需要讨论动态地图的技术支持以及如何解决稳定性问题。Andrewssi2 (talk) 2014年1月27日 07:05 (UTC)

另请参见：Wikivoyage_talk:Dynamic_maps_Expedition#Sorry_to_bother_the_Dynamic_map_team_again... 和 Wikivoyage_talk:Dynamic_maps_Expedition#Problems_with_mapframe。ϒpsilon (talk) 2014年1月27日 07:33 (UTC)

在法语维基导游中似乎运行良好。我已向这里的地图人员提出这个问题。Andrewssi2 (talk) 2014年1月29日 05:26 (UTC)

生日和祝贺

昨天我们庆祝了7岁生日。2006年12月10日，我们从德语分站开始运营维基导游。一年后，意大利语分站也启动了。我们还收到了谷歌送出的一份不错的生日礼物：维基导游中央主页的PageRank现在是7，英语主页的PageRank是6。如果这还不足以保持积极思考，那我就不知道还有什么了。--RolandUnger (talk) 2013年12月11日 09:36 (UTC)

恭喜，做得好。--Saqib (talk) 2013年12月11日 09:51 (UTC)

好消息！祝贺，并非常感谢德国社区发起这个项目！--亚历山大 (talk) 2013年12月11日 09:55 (UTC)

生日快乐！非常感谢您为我们这些来自其他语言社区的人所做的一切！Ikan Kekek (talk) 2013年12月11日 10:10 (UTC)

亲爱的维基导游，祝你生日快乐❤ --Walta (talk) 2014年1月15日 00:22 (UTC)

维基导游7岁生日快乐！--Sonusmarty (talk) 2014年2月7日 23:23 (UTC)Sonusmarty

4x4缩写

看起来我们在“旅行”中对4WD和4X4（以及它们大小写不同的变体，如4wd、4x4等）的使用存在分歧——由于一致性使用可能会有所帮助，有没有任何迹象表明为什么一个可能优于另一个？或者就像发现的那样——大约各占一半……

• https://wikivoyage.cn/w/index.php?search=4x4&title=Special%3ASearch
• https://wikivoyage.cn/w/index.php?search=4wd&title=Special%3ASearch

只希望某种用法有充分的理由sats (talk) 2014年1月27日 06:12 (UTC)

雷诺B90 4x4

尽管这两种说法对大多数英语母语者来说都易于理解，但我更喜欢4x4，因为

1) 对于将英语作为第二语言的大多数用户来说，它更容易立即理解

2) 当你注意到大小写发生翻转时，它不那么引人注目

3) 它可以很容易地写出“2x4车辆在旱季也能成功通过这条路……”之类的话。--150.101.89.130 2014年1月27日 08:42 (UTC)

这不是一个私人问题，也不是在征求您的个人意见。如果是这样，我就会到您的讨论页去——我感兴趣的是维基导游的其他编辑者的实际想法，因为它涉及大量的文章——其他人可能也感兴趣（或者不感兴趣）。sats (talk) 2014年1月27日 09:44 (UTC)

首先：我对汽车知之甚少。我认为这两个词都足够容易理解，即使对于非母语人士也是如此。我一直以为它们只是同一个东西的两种说法，但维基百科在定义上有所不同

• 四驱车(4x4)是指车辆的总称。第一个数字通常是车轮总数（更确切地说是车轴末端，可能有多轮），第二个数字是驱动轮的数量。
• 四轮驱动(4WD)是指在前轴和后轴之间有一个分动箱而不是差速器的车辆，这意味着在前轮驱动和后轮驱动啮合时，前后驱动轴将被锁定在一起。

如果这是真的，那么4x4对我来说在写作时显然是更好的选择，因为我看到这种车时不会知道区别。优先使用这个通用术语似乎很明智。然而，告诉那些确实了解汽车的人用哪个词似乎有点愚蠢。JuliasTravels (talk) 2014年1月27日 10:31 (UTC)

我对汽车有一些了解。我认为维基百科引用的上述文本有严重错误。

对我来说，“四轮驱动”或“4wd”是向所有四个车轮提供动力的车辆的通用术语；该术语与“前轮驱动”或“后轮驱动”形成对比。这几乎是我们所有情况下都应该使用的术语。

与维基百科相反，称某物为“4wd”与是否使用分动箱、差速器或扭矩转换器来分配动力绝对无关。

对我来说，“四乘四”或“4x4”更多是对车辆类型的一种描述，尽管它相当不精确；它暗示着某种轻型卡车，具有四轮驱动和一定的越野能力。有许多车辆—特别是各种奥迪和斯巴鲁车型—是四轮驱动，但我不称它们为4x4，因为它们不够像卡车。Pashley (talk) 2014年1月27日 22:29 (UTC)

这一个月来没有任何进展，还有其他建议吗，因为维基导游仍然有两种用法，对这个问题没有约定或达成一致的解决方案——如果你看这个具体问题，这种不一致性很明显……sats (talk) 2014年3月1日 10:57 (UTC)

共识建立方式的变更

任何对我们共识建立过程潜在修改感兴趣的人，请考虑在Wikivoyage talk:Consensus#Wikivoyage:Consensus/Draft发表评论。-- Ryan • (talk) • 2014年1月30日 03:42 (UTC)

版权问题！

请查看我在关于尼维斯岛的文章讨论页上写的一篇文章。Invertzoo (talk) 2014年2月5日 00:14 (UTC) 复制自：Wikivoyage_talk:Community_portal#Copyright_problem.21 --Nick ^talk 2014年2月5日 00:34 (UTC)

谢谢Nick，不过我认为处理版权侵权问题的协议相当直接明了？你重新发布到酒吧的意图/问题是什么？Andrewssi2 (talk) 2014年2月5日 02:40 (UTC)

我只是在移动Invertzoo的原始帖子，因为它被放在了社区门户讨论页上，我认为这不是她想要放的地方。我已要求Invertzoo突出显示她认为侵犯版权的具体部分。--Nick ^talk 2014年2月5日 02:43 (UTC)

好的，谢谢，明白了。Andrewssi2 (talk) 2014年2月5日 03:08 (UTC)

首先，尽管（大部分是基本）信息具有可比性，但我不太容易找到大量逐字逐句的文本，但我应该进一步查找。这里奇怪的是，指出版权问题的用户大约在一年前大部分文章都是自己写的。我不确定他/她是否被猫途鹰告知不能同时在其他地方发布内容（这将是值得商榷的，因为他们的使用条款包括非独占许可），或者他/她忘记了是自己写的……我也会在她的讨论页上询问，但在我看来，这位用户声称并拥有（共同）所有权，并在我们的知识共享许可下上传？JuliasTravels (talk) 2014年2月5日 10:06 (UTC)

大家好，我认为这是我的错误。我发帖时很累，没有意识到文章的大部分内容是我自己写的，所以我误以为是从我朋友几年前在TripAdvisor上写过的文章复制的。我会再检查一遍，但可能一切都没问题。很抱歉不必要地引发了警报。Invertzoo (talk) 2014年2月5日 14:23 (UTC)

没问题，信息能保留下来很好，非常感谢你的贡献！既然我们已经引起了人们对尼维斯的关注，也许我们优秀的横幅设计者能制作一个更 colourful 的横幅？ :-) 适合的照片很难找到，我们拥有的照片大多来自圣基茨，但在维基共享资源上有一些，我添加了一张我从 Flickr 找到的，至少有一点尼维斯的照片。这样可行吗？ JuliasTravels (讨论) 2014年2月5日 16:24 (UTC)

圣基茨的版权标签也可以移除吗？ Texugo (讨论) 2014年2月5日 16:25 (UTC)

检查横幅，但这照片质量不高，所以效果不会很好。--Alexander (讨论) 2014年2月5日 19:44 (UTC)

非常感谢！我想也是，但无论如何，对于像这样的阳光明媚的目的地来说，它比灰色的默认横幅更具启发性 :-) JuliasTravels (讨论) 2014年2月7日 08:18 (UTC)

感谢Joachim

帮助我们再次启动动态地图！--118.93nzp (讨论) 2014年1月31日 00:25 (UTC)

当然！谢谢你，Joachim！ :) --Nick ^讨论 2014年2月1日 21:31 (UTC)

也向我迟到的感谢！没有人比我更想念它们了……但它们又回来了，就像一位久违的朋友，它们融化了泪水……

不过有趣的是，我现在在 Mac OS 上的 Firefox 中显示它们似乎有问题，但在 Windows 上（同样的 Firefox）却没问题。好奇怪。无论如何，能让它们回来真是太好了，Joachim，你和 Torty 让 Wikivoyage 变得真正有价值，值得进一步扩展！ PrinceGloria (讨论) 2014年2月3日 18:21 (UTC)

标记和数字

我在 Template_talk:Marker#Manipulating_the_numbers_on_the_markers 中提了一个问题，我们的 POI 地图专家 Joachim 今天一直在编辑，但可能太忙了 (?) 没回复，所以我就扮成新手，在酒吧里问一下，这样所有人都能看到。**

我想知道是否可以强制一个标记拥有一个特定的数字。我计划在动态地图上标记 西伯利亚铁路 上的重要站点（试图把它做成一个非常时尚的 特色旅行主题 :))。这条铁路在西伯利亚分叉成三条独立的线路，我希望这三条分叉上的数字是连续的。例如（点击这里“看图”），在标记 17 有一个交汇点，之后一条线路向东通往符拉迪沃斯托克，下一个站点是赤塔，另一条向南通往北京，下一个站点是瑙什基。我希望这两个站点都被标记为 18 号。

如果我放入一个二级标题，并从莫斯科开始添加前 17 个相同坐标的点，它们将在地图中隐藏——但在文本中不会。

如果我从符拉迪沃斯托克在同一部分继续，瑙什基将是 23 号…… ϒpsilon (讨论) 2014年2月3日 17:20 (UTC)

这里有一个有点奇怪的解决方案：将所有 1 到 17 号的站点添加到西伯利亚铁路部分。然后将它们注释掉。这样，编号应该从该部分的 18 号开始。我希望它能奏效-) --Alexander (讨论) 2014年2月3日 17:31 (UTC)

** 是的，我收到了来自所有语言版本的许多请求。但真正的原因是通知系统不可靠。既然你提到了我的名字，我应该收到通知。但在过去的几次中，有 3 或 4 次没有发生这种情况。甚至可能还有更多我从未注意到的情况。 - Joachim Mey2008 (讨论) 2014年2月3日 17:44 (UTC) (我的实际回答很快就会发布。)

谢谢你的主意，Alexander。不幸的是，它似乎不起作用。希望 Joachim 能找到解决方案，否则我将不得不重新开始编号，那在地图上看起来会有点尴尬。 ϒpsilon (讨论) 2014年2月3日 18:01 (UTC)

未提供标记号码的操作。我认为由于脚本的一些更改，Alexander 的提议不再有效。- 我建议为次要线路选择不同颜色的标记。你可以使用这些类型：。除了 type=listing (other.png) 之外，每个新部分的编号都将从 1 开始。-- Joachim Mey2008 (讨论) 2014年2月3日 18:28 (UTC)

真遗憾。 :( 好的，我想这是最好的解决方案。谢谢。 ϒpsilon (讨论) 2014年2月3日 18:37 (UTC)

趁此机会，也许有一个解决另一个困境的方法——有时在同一地点有两个或三个不同的兴趣点。例如，有一个历史宫殿或城堡（看），里面有一个不相关的博物馆（做，或另一个看），例如自然历史博物馆，这值得单独列为一个兴趣点，而且在同一栋建筑里还有一家不错的餐厅（吃），有时甚至有一个酒店（住）。火车站也是如此，它们既是购物中心，也有旅游信息点。将它们在文章中不同地方单独提及是值得的，但没必要在地图上创建几个重叠的标记，这只会使地图更难辨认。有没有可能在文章中再次引用已经放置的标记，以显示相同的数字和符号？ PrinceGloria (讨论) 2014年2月3日 18:57 (UTC)

不，不可能，也不清楚如何实现这个功能。列表是根据它们在文章中的顺序一个接一个地编号的，列表和它的编号之间没有一对一的对应关系。所以你基本上需要一个脚本，它遍历文章两次。第一次运行时，它会创建一个表格并为每个列表分配编号。第二次运行时，它会查找特定的列表，读取其编号，并根据需要复制。这很复杂…… --Alexander (讨论) 2014年2月3日 19:48 (UTC)

也许有点重复，但正如你所解释的，并不复杂。如果有一个表格存储着POI（使用什么作为索引？“名称”字段与“类型”字段结合？只有“名称”？其他？）与数字和形状的匹配，那么它就可以很容易地成为一个参考表，将一组模板引用与特定的POI对象匹配，然后将POI对象与屏幕上显示的图形匹配。这在这一点上似乎并不复杂，实现上可能会有一些我无法预见的问题，但复杂性本身似乎不是问题。 PrinceGloria (讨论) 2014年2月3日 19:55 (UTC)

此前，我提供了两种与重叠标记相关的方法：聚类 和 spiderfier 。这两种方法都被社区拒绝了。因此，我现在建议一个简单的手动过程。-- 缩放级别 16 (1:8000) 类似于印刷城市地图。不应有重叠标记，也考虑到日后的纸质打印。在此缩放级别下，可以轻松修改坐标，使标记并排显示。这无需额外软件即可实现。点击动态地图上的所需点。将出现一个弹出窗口：“您点击了地图，纬度 = 52.15382 | 经度 = 9.97044”。通过复制粘贴即可更正列表的坐标。- Joachim Mey2008 (讨论) 2014年2月6日 07:00 (UTC)

我个人认为，如果鼠标悬停在每个“蜘蛛脚”上时能出现工具提示，那么 Spiderfier 会很棒。 Nicolas1981 (讨论) 2014年2月7日 04:38 (UTC)

维基媒体国际大会 2013 演示视频

看起来 DerFussi 和 Travel Doc James 去年在维基媒体国际大会上关于 WV 的精彩演示现在已经发布到网上了。非常值得一看，也提醒我们还有一些事情需要做！--Nick ^讨论 2014年2月5日 02:12 (UTC)

巡查

我标记为已巡查的编辑仍然带有 ！，有人知道为什么吗？ --ClausHansen (讨论) 2014年2月5日 14:14 (UTC)

嗯。在这里看起来运行正常。当你标记它时，是否出现一个小的 JavaScript 弹窗，说它已被标记为已巡查？如果没有，我猜可能是你的浏览器存在 JavaScript 问题。 Texugo (讨论) 2014年2月5日 14:22 (UTC)

对单个编辑有效，但似乎无法一键将多个编辑标记为已巡查，这是应该的工作方式吗？--ClausHansen (讨论) 2014年2月5日 16:40 (UTC)

参见 Wikivoyage talk:Recent changes patrol#Patrolling problem。关于这个问题有一个 Bugzilla 报告，为该 Bug 投票可能有助于更快地解决。-- Ryan • (讨论) • 2014年2月5日 16:47 (UTC)

寻找有用的事情做？

1. 下载最新的 listings.csv 文件
2. 在 LibreOffice/Excel/电子表格程序中打开 CSV 文件
3. 按电话、纬度、经度、URL 或图片排序（文件很大，需要时间）
4. 检查开头和结尾的值。有很多格式不正确的值，带有各种错误的字符，例如电话号码以下划线开头等。
5. 使用第一列的文章名称，直接在 Wikivoyage 中修复任何错误的值。
6. 完成后，尝试按另一列排序并再次修复 :-)

非常感谢！ Nicolas1981 (讨论) 2014年2月7日 06:44 (UTC)

嗨，Nicholas，我知道我们无法直接访问 WV 数据库，但在商业世界中，这种方法被称为数据清洗活动。这种策略试图通过简单的算法自动修复 95% 的问题，其余的“漏网之鱼”可以手动处理。

我们可以使用对话框创建和编辑列表，我猜其背后有一个相应的 API。是否最好利用这个 API（可能结合机器人）并首先尝试自动修复？

我不熟悉这个 API，但如果你认为这可能是一个有价值的策略，我乐意学习。 Andrewssi2 (讨论) 2014年2月7日 06:58 (UTC)

我使用列表修复了一些项目。-- WOSlinker (讨论) 2014年2月8日 09:11 (UTC)

这太轻描淡写了——我注意到你做了大量出色的（非内容）编辑——以这种谦虚的程度，你一定是英国人！--118.93nzp (讨论) 2014年2月8日 09:49 (UTC)

确实，如果你注意到有什么最好用脚本修复（也许超过 200 个项目？），那么请写出模式和应该改为的内容。当对列进行排序并查看结尾或开头时，通常会发现“少于 200 个”的偶尔拼写错误等。需要脚本的一个例子是坐标以小时/分钟/秒而不是十进制数表示。 Nicolas1981 (讨论) 2014年2月8日 16:52 (UTC)

如何发展维基导游

大家好，我一直在关注各种旨在发展维基导游的倡议，例如 搜索探险 页面和各种项目，以及像 Nick 发起的上面那段讨论。我想发起一个开放的对话，讨论如何发展维基导游：吸引更多编辑者、提高文章质量、提升我们的搜索排名等。我既是社区成员/编辑者，也是维基媒体基金会理事会成员，关注我们所有项目的健康发展；我们都希望这个项目取得成功。请分享你的想法！谢谢，-- Phoebe (讨论) 2014年2月7日 22:19 (UTC)

谢谢你，Phoebe！最首要的答案很简单：抽出维基媒体基金会法律部门的几个小时时间，审查每个页面上那令人讨厌的页脚，其中包含指向 Wikitravel 的超链接。几乎所有人都认为这可能是我们搜索可见性差的主要因素，几乎所有人都认为我们可能在归属方面过于热心，因为完整的历史记录已经导入，而且 Wikitravel 的使用条款在分叉时明确不要求超链接。然而，由于页脚是在法律团队的帮助下创建的，社区觉得没有法律部门的绿灯，无法删除超链接。如果你能让这件事动起来，我们会非常高兴。 JuliasTravels (讨论) 2014年2月7日 22:27 (UTC)

啊哈，谢谢，我不知道那个问题。你能告诉我之前在哪里讨论过吗？那就太好了。更多具体的和一般的想法都会很棒！-- Phoebe (讨论) 2014年2月7日 22:36 (UTC)

嗨，Phoebe！谢谢你的提问！如果你觉得上面的讨论很有趣，几个月前还有一场类似但更长的讨论，你可能也会有兴趣看看（恐怕我又是一个略带末日色彩的开场白 :)）。我完全同意 JuliasTravels 的观点，即移除超链接引用将是该项目的一项重大成就，但我们还尝试了其他一些事情（除了搜索探险之外）。

旅游局探险旨在与世界各地的旅游局联络，并让他们参与本网站指南的创建和宣传。尽管我们取得了一些成功（我只能说我熟悉的情况，但曼彻斯特的旅游局似乎真的很有兴趣，给我发了几封邮件，而伦敦/伦敦市的旅游局积极地进行了编辑），但我们一直受到读者群低和不可靠（以及令人失望的？）统计数据的阻碍，这些统计数据对于吸引如此重要的合作伙伴是必需的。这有点像一个恶性循环。

我们还大大增加了在社交媒体上的存在，现在我们有活跃的Facebook和Twitter账户，希望能够吸引人们，尽管这种涌入很难量化（但感谢你最近的推文！）。

最后，我们还将内容的简单改进视为提高读者群的一种方式。这（我们希望）使我们与其他基于维基的旅行指南区别开来（这对于搜索引擎优化很重要），但也希望使我们成为一个对旅行者来说更好的网站——质量胜于一切！我们为此开发了许多探险活动，但不幸的是（恶性循环又来了），我们并没有足够的编辑者来同时保持几个项目的最高效率，所以它们往往是波浪式进行的。

我确信我忘记了这里尝试过的许多其他事情，但希望这能让你了解我们已经考虑过哪些方法来帮助改善网站的读者（和编辑者）群。我很快会再次发帖，一旦我想出一些新想法来帮助维基导游变得更大更好。如果这篇帖子有点语无伦次，我很抱歉——这里是凌晨 3 点！

谢谢你的联系！ :) --Nick ^讨论 2014年2月8日 02:51 (UTC)

@Phoebe: 我认为 Wikivoyage 面临着与许多其他小型维基媒体项目相同的问题，即我们受益于更多的知名度，从而拥有更多常规编辑者。提高我们的搜索引擎排名是实现这一目标的一种方式，但如果 WMF 董事会能想到其他方法来推广其小型项目，那将是巨大的——我们最大的流量周是维基百科上宣传新网站的横幅发布时，因此也许有一种方法可以使项目之间的链接更加突出。另一个选择是 WMF 可以扩大与课堂和当地团体的合作，鼓励他们参与，我相信还可以考虑其他外展工作。

WMF 可能有所帮助的另一个领域是寻找促进项目之间协作的方法——通常有一些倡议会帮助多个项目，但人们对此并不知情。此外，在某些情况下，我们有一些与 Wikivoyage 无关的问题，如果能与其他项目一起提出这些问题并希望有助于提高它们的优先级（例如：#巡查），那将是很好的。我不知道这是否可以通过由一名工作人员担任社区协调员来处理，或者让在元维基上协作更容易，或者采取什么形式，但我认为这将有助于 WMF 监督的每个项目。

与此同时，虽然我们有十年的文档和流程，但我们正在努力使维基导游更友好、更易于使用，尽管受到协作开发的限制，改变可能是一个缓慢的过程。我展望未来，感谢维基媒体基金会已经做的一切（过去一年比我们以前的情况好得多！），并且和 Nick 一样非常感谢你与我们联系！-- Ryan • (讨论) • 2014年2月8日 16:27 (UTC)

抱歉，@Phoebe: 没有包含链接。Wikitravel 超链接问题已在多个地方和时间讨论过，包括 元维基。Geoffbrigham 代表法律团队在那里回复，并指出他们只能向 WMF 本身提供法律建议。不幸的是，他将这个问题定性为“细节”，并建议我们专注于创建内容。我们都明白这一点，尤其是考虑到该团队可能有的工作量（而且我们也非常专注于内容！），但我担心他没有理解这个问题对社区和网站的巨大影响。有一个 bugzilla 请求；我想如果我们可以请 WMF 帮助我们删除链接，那么法律部门给出建议应该没问题吧？如果这能使审查更容易，我很乐意撰写一份问题的摘要作为开始，以及我们认为该链接可能不需要存在的理由。当然，其他人是对的：任何关于其他增加可见度的方法的帮助也都是最受欢迎的。只是那几个小时的法律时间相对来说是一件简单的事情，但却能带来很大的帮助 :-)

你可以建立的另一个联系（及时）是与分会。就联系旅游局而言，我认为如果任何分会感兴趣，他们将处于一个非常有利的位置来这样做。然而，正如 Nick 所说，只有当我们更受关注时，他们才会对与我们合作感兴趣。无论如何，你表现出兴趣真是太好了。 JuliasTravels (讨论) 2014年2月9日 20:27 (UTC)

通过维基百科和维基共享资源提高搜索引擎可见性

维基百科和维基共享资源充满了数百万个带有地理位置的条目，每个条目都与附近的维基导游地标或页面相关。我们如何才能最好地利用这一点来提高维基导游的可见性？目前是否有机器人和脚本可以在适当的地方插入维基导游的链接？ ` Sj (讨论) 2014年2月7日 22:46 (UTC)

我很想知道更多。由于维基百科的搜索可见度更高，如果维基百科文章页面上有一个链接可以将感兴趣的旅行者带到相应的维基导游页面，那将是极好的。 Andrewssi2 (讨论) 2014年2月9日 12:50 (UTC)

Wikidata 可以让这变得非常容易，如果我们能找到要添加链接的模板。信息框在技术上是完美的，但也许它不是最好的位置。作为提醒，这里有一个似乎有效的方法

{{sister|project=voyage
|text=[[Wikivoyage]] has travel information related to: '''''[[voy:Paris|Paris]]'''''
}}

干杯！ Nicolas1981 (讨论) 2014年2月10日 07:41 (UTC)

报纸

一些非英语主导的国家，仍有本地出版（与《国际先驱论坛报》等外国出版物不同）的英语全国性报纸。在国家文章中提及它们是否无益，如果不是，应该在哪里提及——在“连接”部分？

一些例子

• 阿尔及利亚：Algeria Daily
• 阿根廷：布宜诺斯艾利斯先驱报
• 不丹：Kuensel
• 柬埔寨：金边邮报
• 喀麦隆：the Cameroon Daily Journal
• 中国：中国日报
• 古巴：格拉玛国际版
• 捷克共和国：Transitions Online, The Prague Post
• 丹麦：哥本哈根邮报
• 埃及：金字塔周报，每日新闻
• 埃塞俄比亚：财富，记者报
• 法国：外交世界报有英文版
• 格鲁吉亚：格鲁吉亚时报
• 希腊：Kathimerini
• 以色列：耶路撒冷邮报
• 日本：每日读卖新闻
• 约旦：约旦时报
• 韩国：韩国时报。韩国先驱报
• 拉脱维亚：波罗的海时报
• 黎巴嫩：黎巴嫩每日星报
• 利比亚：利比亚先驱报
• 马来西亚：星报、每日快报、婆罗洲公报
• 蒙古：乌兰巴托邮报
• 挪威：挪威邮报
• 巴基斯坦：民族报、黎明报、每日时报、每日邮报，
• 波兰：华沙之声
• 罗马尼亚：Nine O'Clock
• 俄罗斯：圣彼得堡时报，莫斯科新闻报，莫斯科时报，真理报英文版
• 斯洛伐克共和国：斯洛伐克观察家报
• 台湾：中国邮报，台北时报
• 泰国：曼谷邮报
• 乌克兰：基辅邮报
• 也门：也门时报 --118.93nzp (讨论) 2014年2月8日 03:31 (UTC)

我认为这是个好主意。顺便说一下，马来西亚主要的英文报纸是《新海峡时报》，它与自 1969 年以来一直是马来西亚联邦政府执政联盟主要成员的巫统有关联。 Ikan Kekek (讨论) 2014年2月8日 04:17 (UTC)

是的，这正是我没有提及这个政府喉舌的原因。你认为修改Wikivoyage:Country article template#连接是个好主意吗？--118.93nzp (讨论) 2014年2月8日 04:34 (UTC)

无论如何，我都会提及它。星报曾经（或至少过去）与马华公会，即主要的华人执政联盟伙伴有关。任何时候，如果你面对一个不自由的民主国家，更不用说专制政权，你都可以指望所有或至少大多数大众流通的报纸要么公开要么默认是政府喉舌。在马来西亚的案例中，伊斯兰反对党回教党有一份英文报纸，如果你喜欢，可以把它们也列进去，但我不会采取政治试金石来排除政府喉舌。 Ikan Kekek (讨论) 2014年2月8日 04:44 (UTC)

嗯，那只是一个说明性的列表，并非详尽或明确的。具体列出哪些内容将取决于编辑者之间的日常互动。我只是想知道是否普遍存在不提及报纸或广播电台的看法，而这些报纸或广播电台可能对前来旅行的游客来说是有趣或信息丰富的——或者在他们访问之前评估一般的犯罪水平/地点或最近的发展（如果它们也有在线存在的话）…… --118.93nzp (讨论) 2014年2月8日 05:20 (UTC)

我认为这是个好主意。既然你提到了广播电台，那么在相关城市、地区或国家文章中列出广播 BBC、美国武装部队广播，或者是非英语国家（例如，德语之声英语服务或 NHK）英语服务的调频或调幅频率是很好的，具体取决于信号覆盖范围。 Ikan Kekek (讨论) 2014年2月8日 05:56 (UTC)

我也认为这是个好主意。我旅行时经常寻找英文报纸，了解是否有英文报纸很有用—— Phoebe (讨论) 2014年2月8日 06:01 (UTC)

那么，是在“连接”部分——还是其他地方？ --118.93nzp (讨论) 2014年2月8日 06:27 (UTC)

在布法罗指南中，媒体在“应对”（Cope）部分。我猜想其理念是“连接”（Connect）专用于个人通信，而非大众媒体接收。Ikan Kekek (talk) 2014年2月8日 06:34 (UTC)

在我任职 Wikitravel/Wikivoyage 的早期，我几乎可以保证我是模仿Powers在罗切斯特（纽约）上的设置。-- AndreCarrotflower (talk) 2014年2月8日 07:31 (UTC)

那就该把功劳归于他，但你是否同意我关于把大众媒体信息放在“应对”（Cope）而非“连接”（Connect）中的理由的理解？ Ikan Kekek (talk) 2014年2月8日 07:43 (UTC)

我想是的，但我希望 Powers 会看到这里提到他，并果断地发表意见。-- AndreCarrotflower (talk) 2014年2月8日 07:55 (UTC)

@LtPowers:

我们不常使用国家模板来创建新文章，所以这可能被忽略了——或者，美国（与英国或法国相对）这种大国很少有全国性报纸的经验可能导致这被忽略了。

Wikivoyage:Where you can stick it#N 中的建议对于地方或城市媒体是明确的，但我的问题特别涉及国家或地区层面。Wikivoyage:国家文章模板目前没有“应对”（Cope）部分（且Wikivoyage:区域文章模板目前既没有“应对”（Cope）部分也没有“连接”（Connect）部分）——你是否建议我们创建一个，就为了这类内容？--118.93nzp (talk) 2014年2月8日 08:25 (UTC)

“连接”（Connect）最初是“联系”（Contact），指的是个人通信。后来改名，因为它往往会充斥着“联系当地旅游局获取旅游信息”这类内容，这并非其初衷。

对于那些非当地主要语言、不属于旅游餐饮/住宿/景点类别但可能对同语系旅行者有用的地方实体，有一个更广泛的问题需要解决。例如，一个文化中心或外籍社区；在fr:金斯顿（安大略）的“了解”（Understand）部分下，“Frontenac中心”被列出，因为它可以作为该语言的 Wikivoyage 旅行者获取法语信息的有效来源，尽管它主要服务于当地的法语少数民族。K7L (talk) 2014年2月8日 18:19 (UTC)

确实如此；我不知道为什么报纸被放在应对（Cope）部分，但它们确实被放在了那里。我可以推测，那是因为人们阅读报纸是为了了解新闻、查看天气预报，并普遍地进行日常生活，而不是作为与人交流的一种方式。你可以阅读Wikivoyage talk:Where you can stick it#bloated Understand-ing的原始讨论，其中似乎报纸一直都在理解（Understand）部分，直到 cacahuate 建议将它们移到应对（Cope）部分。国家级文章确实通常不需要应对（Cope）部分（尽管我对此有一些反驳理由）；对于全国性报纸，我建议要么创建一个应对（Cope）部分（根据Wikivoyage:文章模板/章节是允许的），要么使用理解（Understand）或联系（Contact）部分。Powers ^(talk) 2014年2月8日 18:36 (UTC)

那是个笔误吗 @LtPowers:？你的意思是说我建议要么创建一个应对（Cope）部分（根据Wikivoyage:文章模板/章节是允许的），要么使用理解（Understand）或连接（Connect）（我的下划线是为了清晰） ？--118.93.237.217 2014年2月9日 02:48 (UTC)

需要通用或“未分类目的地”文章模板吗？

从Talk:尼维斯复制，以获得更广泛的关注，作者为 --118.93nzp (talk) 2014年2月8日 06:24 (UTC)

我认为这篇文章可以有一个住宿部分。由于整个岛屿相当不发达，我们可能不需要单独的“城镇”文章，但理想情况下，我们应该在某个时候有酒店和餐馆的列表。我想说，这属于那种在地区文章中包含单独列表可能没问题的地方，是吗？ JuliasTravels (talk) 2014年2月5日 19:00 (UTC)

哦，我绝对同意你的看法。这应该被当作城市文章来处理。如果它真的是一个地区，而其中包含的单个城市文章包含了关于该岛的大部分内容，那就毫无意义了。因此，我将毫无意义的查尔斯顿文章重定向到这里。Texugo (talk) 2014年2月5日 19:07 (UTC)

我完全同意你们两位的观点。

有没有一个“小岛模板”可以用来代替“小城市”或“地区”来处理像Ukulhas等文章？--118.93nzp (talk) 2014年2月5日 22:57 (UTC)

我认为，如果创建任何额外的模板，它应该是一个更通用的模板。我一直在努力寻找处理这类情况的好方法，无论是对于广阔、不发达的地区，还是对于岛屿，以及对于每个定居点只有一两个列表的较小发达农村地区。问题其实非常相似。现在这类目的地之间的一致性并不高：有些放在城市文章中，有些放在地区文章中，有些只是在常规部分收集列表，还有一些则按“定居点”分设部分。哪种更有用取决于具体情况，所以也许我们不应该真正寻找一个模板，而应该寻找对如何处理这些地方更普遍的理解，以及我们可以在地区文章等地方对列表进行一些创新。JuliasTravels (talk) 2014年2月7日 09:22 (UTC)

新发现：格式错误的电子邮件

这是一份包含211个格式错误电子邮件地址的新列表。我筛选掉了最常见的错误，这些错误可能可以通过脚本修复，所以这211个必须手动修复，非常感谢！

我还更新了格式错误的经纬度列表，感谢大家修复了许多，但还有很多需要修复 :-)

Nicolas1981 (talk) 2014年2月8日 17:17 (UTC)

国家文章中的领事馆

我同意领事馆应该在包含它们的城市目的地指南中详细列出的建议。

但是，我们的国家文章不也应该在“应对”（Cope）部分包含一个指向那些包含城市的子部分吗？

我特别想到的是那些拥有相对较小或新首都的国家，而大多数领事馆仍留在较大或较老的城市中（例如，仰光仍然拥有缅甸的领事设施，而不是新的、小得多的首都内比都）...... --118.93nzp (talk) 2014年2月9日 01:30 (UTC)

是的，绝对如此。Ikan Kekek (talk) 2014年2月9日 07:33 (UTC)

我已开始着手整理我的祖国新西兰的相关信息，并开始充实惠灵顿的列表，接着我将处理奥克兰、基督城、达尼丁和皇后镇，然后才结束。--118.93nzp (talk) 2014年2月9日 08:26 (UTC)

这绝对是个好主意。还有很多其他情况需要在国家文章中提供一些信息。例如，在中国有三四个主要城市拥有许多领事馆，但一些国家，主要是东南亚国家，在厦门或昆明设有领事馆。这类信息对于进行多国旅行且需要签证的旅行者来说非常有用。Pashley (talk) 2014年2月9日 14:35 (UTC)

同一个列表有两个电子邮件地址？

在列表字段中包含多个电子邮件地址是否可以？如果可以，它们应该如何分隔？当前的模板输出似乎不支持多个地址，例如 1@e.com,2@e.com 会导致一个“1@e.com,”的 mailto 链接。

我们的文档中写着“email：一个电子邮件地址”，所以我猜不允许有多个地址？

Nicolas1981 (talk) 2014年2月8日 18:13 (UTC)

我不知道我们是否讨论过多个电子邮件的问题，但我们经常收到包含多个电话号码的列表——参见Wikivoyage talk:Listings#Multiple phone numbers，这是多个相关讨论串之一。我相信共识是每个模板字段只使用一个条目，这样点击链接时才能正常工作，并且通常没有必要使用多个值。如果确实需要第二个电子邮件，我的建议是在列表内容部分提及，但大多数情况下，我猜测第二个电子邮件是多余的。-- Ryan • (talk) • 2014年2月8日 18:26 (UTC)

我同意，在模板化列表的“email”字段中添加第二个电子邮件地址既是多余的又是错误的（因为它会破坏自动“mail-to”功能）。我同意，必要的实例应该放在“content”字段的散文中。任何第二个或不寻常的或不能机器拨号的电话号码（例如包含字母助记符的号码，如 1 800 MESSED-UP）都应该放在“phoneextra”字段中，不是吗？顺便说一句，该字段仍未在列表中显示... --118.93nzp (talk) 2014年2月9日 01:30 (UTC)

非常有趣 @118.93nzp 我不知道 phonextra！我同意应该使用它，这样我们的拨号链接才能正常工作。目前我们有 5000 个无效传真，25000 个无效电话，800 个无效免费电话（列于此处）Nicolas1981 (talk) 2014年2月9日 03:09 (UTC)

那是你的一份不错的清单，如果我不去履行我的承诺给User:Wrh2的话，它会让我忙上几个月... --118.93nzp (talk) 2014年2月9日 03:25 (UTC)

@118.93nzp 恰恰相反，我认为你应该抓住这个绝佳的机会，从政治中抽身，专注于 100% 的列表整理工作 :-) 怎么样，开始修复无效电子邮件和错误“*”字符的积压工作？这两项无法自动化，所以修复它们将是一项重大成就！Nicolas1981 (talk) 2014年2月10日 02:19 (UTC)

诱人的建议，尼古拉。

你是否能够首先修复列表机制，以便它向我们的读者显示phoneextra字段中的任何内容？

一个例子是这个部分：目前意大利名誉领事官 Sergio Gian Salis 博士的额外联系电话 +64 3 477-3123 未显示，而是“隐藏”在我们的代码中。--118.93nzp (talk) 2014年2月10日 04:56 (UTC)

我会尝试看看 phoneextra！但这不妨碍你从电子邮件和星号开始 :-) Nicolas1981 (talk) 2014年2月10日 07:31 (UTC)

不，我眼睛里已经看到太多浮动的星星了，电子邮件地址检查起来太麻烦了。电话号码是我感兴趣的领域，而且我作为 IP 很容易就能做到，无需太多争论。--118.93nzp (talk) 2014年2月10日 07:42 (UTC)

电话号码？如你所愿：User:Nicolas1981/Syntax_checks/Page2 期待你的精彩表现 :-) Nicolas1981 (talk) 2014年2月13日 08:10 (UTC)

我认为使用现有的模板参数，多个电话号码和电子邮件地址应该不会太难实现

• 可以使用现有的电话和/或电子邮件参数输入多个电话号码和多个电子邮件地址——需要一个确定的唯一分隔符。例如，电话 = +7 812 230-64-31,+7 812 230-64-32,+7 812 230-64-31，其中逗号作为分隔符。
• 修改列表模板以调用 Scribunto 模块来处理电话和电子邮件参数。部分功能仍将用于这两个参数。
• 创建一个 Lua 模块，该模块将从列表模板中调用（此模块将具有处理多个电话和电子邮件地址的功能）。Matroc (talk) 2014年2月11日 05:10 (UTC)
• 我的上述讨论的粗略编码示例... Matroc (talk) 2014年2月11日 12:12 (UTC)

实际上，没有必要有多个电子邮件地址，如果有，这意味着你真的只能点击一个电子邮件地址来发送电子邮件，因为你还需要向另一个地址发送电子邮件，这就意味着更多的复制粘贴电子邮件地址，而不是仅仅点击它们。可以制作一个 Lua 模块，它会计算“@”的数量，如果不是 1，则将页面添加到跟踪类别中。-- WOSlinker (talk) 2014年2月11日 07:31 (UTC)

德国的 vCard 模板使用多达三个电子邮件地址字段。过去我们没有像 Lua 这样的工具来从逗号分隔的列表中获取单独的地址，并将其与 mailto 链接结合起来。将来，逗号分隔的列表应该不再是问题。--RolandUnger (talk) 2014年2月11日 10:10 (UTC)

列出多个电子邮件地址的真正需求是什么？已经，列出多个电话号码在大多数情况下都是不必要的冗余。我不想在没有证明其真正需求的情况下助长这种冗余。Texugo (talk) 2014年2月13日 10:19 (UTC)

如果一个号码是酒店的，另一个是酒店餐厅的，那么多个电话号码就是有效的，例如（如果其他联系信息相同，我们尽量避免重复列出“吃”和“睡”）。我犹豫是否要列出多个电子邮件，因为我犹豫是否要发布电子邮件地址；通过包含它们，我们只是将它们添加到一堆垃圾邮件列表中，所以除非它们是该场所唯一的在线存在（没有网站），否则应该省略它们。K7L (talk) 2014年2月13日 17:05 (UTC)

2014年维基媒体国际会议上的 Wikivoyage

今年我打算参加在伦敦举行的维基媒体国际会议，并希望做一次关于 Wikivoyage 的演示。Stefan 说他今年不能参加维基媒体国际会议，但他会帮助我们准备演示。 Dr 也会参加会议，并已同意做一次演示，我想 Nick 可能也会加入我们。还有其他人计划今年参加维基媒体国际会议吗？任何想法和建议都将不胜感激！--Saqib (talk) 2014年2月11日 13:13 (UTC)

Nick最近给我们指出去年的视频很有趣。我认为观众提出的第一个问题基本上是“为什么选择 WikiVoyage”这一点很关键。

一次能够更好地向维基媒体组织推销我们目标的演示会很棒。理想情况下，我们希望维基百科人足够感兴趣，以至于他们会在会议结束后开始为 WV 做贡献。（我没有观察到香港会议后发生这种情况）Andrewssi2 (talk) 2014年2月12日 02:43 (UTC)

我乐意听取社区的建议，我们可以改变演示的主题。我最近写了Wikivoyage:关于#为什么选择 Wikivoyage。你注意到了吗？--Saqib (talk) 2014年2月12日 08:34 (UTC)

不，我确实没注意到。我可能会在那里发表一些评论，而不是在这里打断你的问题！

我们确实时不时会有维基百科的人，例如User:Sbmeirow，他显然有丰富的维基编辑经验，可以做出巨大贡献。我只希望能有一个关于 Wikivoyage 的一页“广告”，以鼓励更多像他这样的人来查看并可能做出贡献。Andrewssi2 (talk) 2014年2月12日 09:02 (UTC)

Saqib 说得对。很遗憾我不能参加。RolandUnger 会参加。但是，当然，我会帮助制作演示文稿。-- DerFussi 2014年2月12日 12:51 (UTC)

安德鲁，请随意在此处提出演示文稿的建议。我知道现在讨论演示文稿还为时过早，但为了使我们的演示文稿提案被接受，我们必须讨论演示文稿中要展示什么。目前，我心中想的是展示 Wikivoyage 在迁移后的进展、发展和改进，以及我们未来的计划，但正如你所说，我们需要进一步向维基媒体社区宣传该项目。我想我们最好将演示文稿的主题改为更侧重于“为什么选择 Wikivoyage”。--Saqib (talk) 2014年2月12日 14:34 (UTC)

很高兴你要去。我认为最好的办法是拟定一份你的演讲提案，让大家评论和补充。我还认为，在你想出主题和内容之前，你应该决定你的目标是什么，以及你想激励的受众是谁。如果你想吸引维基百科人，你需要一个与面向完全不知道 Wikivoyage 是什么的人的第三方不同的演示文稿。请记住，去年 Wikivoyage 还是全新的，但现在我们已经是项目之一了，许多维基百科人大致知道我们在做什么，并且可能浏览过一两次。我猜他们需要的是说服而不是演示。但再说一次，我不确定你想达到什么目的 :-) JuliasTravels (talk) 2014年2月15日 17:09 (UTC)

坦白说，Julias，起初我真的不想做这个演讲，所以我先问了 Stefan 他今年是否会再次演讲，但他表示没有计划参加会议，更别说演讲了。然后，我问了User:Andyrom75（去年的与会者）他今年是否会再次参加会议，他也说不会。然后我问了 Nick，Nick 说他今年不确定是否能参加维基媒体国际会议，然后我决定做这个演讲，因为我认为在如此重要的场合，我们绝对需要一个演讲，并且至少要持续到 WV 社区发展壮大。我很高兴 Dr. 同意做这个演讲，我仍然希望 Nick 或其他人能出现，而我成为听众。坦白说，我对这些事情有点害羞。现在回到话题，起初我心中想的是做一个关于项目进展的演讲，正如我在提案页面中所说，但在 Andrew 上述消息之后，我认为这不是一个好主意，只是浪费了这样一个好机会，所以我决定改变演讲的主题/方向，更侧重于在维基媒体社区中宣传 WV。维基媒体国际会议在八月举行，所以我们有很长时间可以开始准备演讲，但我只想与社区确认，社区是否同意我提议的演讲主题和方向，还是其他什么，以便我们相应地制定提案，因为提交提案的截止日期是3月31日。现在回答你的问题，我的目标是什么：显然我的受众是维基百科人，目标是鼓励和激励更多新编辑者加入 WV。你说“他们需要说服而不是演示”，你是在建议我们应该安排一次与他们的谈话和讨论吗？--Saqib (talk) 2014年2月15日 19:30 (UTC)

根据我去年经验，我可以告诉你，不需要制作花哨的东西，因为最基本的需求是让他们知道 voy 的存在；事实上，他们大多数人并不知道！我在香港看到的最愚蠢的事情是官方宣传册上写着：“基于 Wikitravel 文章” :-DDD 还要考虑到，在 voy 演讲厅里的人中，有三分之一是我带去的。我希望今年情况有所改变，但也可能没有。--Andyrom75 (talk) 2014年2月15日 20:03 (UTC)

我们为什么不为维基媒体国际会议制作一本旅行指南呢？可以是一张简单的传单，在门口分发，简要介绍会场和周边主要景点。没必要进行演讲，你可能也不应该强迫自己做不舒服的事情。有很多其他方式可以代表我们的项目——分发传单是一种方式，与小组交谈是另一种方式。专注于激励你成为 Wikivoyage 社区一员的因素。只要你表现出对项目的热情，其他人就会更倾向于加入我们。Edge3 (talk) 2014年2月15日 19:57 (UTC)

Edge3，我们已经有一个活动旅行指南了：Wikimania_2014_伦敦指南，据我所知，最初的想法是以某种形式分发给参与者。但我不确定是否有必要打印出来，因为那会消耗大量的纸张和墨水。ϒpsilon (talk) 2014年2月15日 20:04 (UTC)

以前，我确实在考虑你刚刚建议的那种方式，即打印2014年伦敦维基媒体国际会议指南并分发给与会者，但正如 YPSI 所说，事实是大多数与会者都会有平板电脑和智能手机，显然他们会更喜欢在他们的设备上以数字格式使用我们的指南文章，而不是携带纸张或传单。顺便说一句，WV 商品化是个好主意，Stefan 对此也有一些计划。另外，我正在考虑一个可以以有趣的方式讲述维基百科和 Wikivoyage 之间区别的演示文稿，并着重说明为什么人们应该为 Wikivoyage 而不是维基百科做贡献，但这可能会伤害一些维基百科人，如果演示文稿以有趣的图片呈现，那就不会。--Saqib (talk) 2014年2月15日 20:13 (UTC)

你可能还需要与其他语言的 Wikivoyage 讨论，看看他们有什么想法。--Rschen7754 2014年2月16日 00:37 (UTC)

Image: 对比 File:

我注意到 Auto Wiki Browser 正在将文章中有效的 Image: 用法更改为 File:，例如，并留下模糊的编辑摘要，如“清理”或“修复拼写错误”。

Image: 是有效的，并且是 MediaWiki 最初的默认设置。File: 是在 MediaWiki 1.6 左右引入的，当时假设少数文件可能是音频或多媒体，例如file:recorded-walking-tour.ogg之类的。由于 WV 文章必须能够以打印形式使用，我们目前不将 MP3/OGG 或其他非图像文件附加到我们的目的地，这是一项政策，所以我们所有的文件确实都是图像。

是否有可能关闭这种不必要的将 File: 替换为 Image: 的功能？K7L (talk) 2014年2月13日 17:36 (UTC)

“Image:”只是一个别名，仅为向后兼容而包含。我认为我们应该始终使用“File:”，尽管我不知道如果这是唯一的更改，我是否会费心编辑页面。Powers ^(talk) 2014年2月13日 18:12 (UTC)

正如 LtPowers 所指出的，“Image:”只是一个别名，没有特殊意义。我的理解是，现在建议改用“File:”——例如参见w:Wikipedia:图像：“图像被归类为文件，并使用 File: 前缀或已弃用的 Image: 前缀”。-- Ryan • (talk) • 2014年2月13日 18:30 (UTC)

基本上和LtPowers说的一样；我不认为为了单纯地把页面中的“Image”改为“File”而进行大规模编辑是件好事，这会使页面历史变得混乱。--Rschen7754 2014年2月14日 (UTC) 03:28

如果我没弄错的话，AWB将“Image:”→“File:”的转换视为次要修复，因此只有当需要进行更实质性的更改（例如修正错别字）时，使用AWB的用户才会被提示保存此更改。-- Ryan • (讨论) • 2014年2月14日 (UTC) 04:01

我还要说这对于新用户来说（略微）有些令人困惑。禁用“Image”将能略微提升整个网站的可用性。Andrewssi2 (讨论) 2014年2月14日 (UTC) 04:05

我很确定我们无法将其关闭……--Rschen7754 2014年2月14日 (UTC) 08:15

怎么会这样？这些链接都是指向图片的。K7L (讨论) 2014年2月14日 (UTC) 04:20

因为新用户不清楚他们应该使用哪个。Andrewssi2 (讨论) 2014年2月14日 (UTC) 04:35

现在所有维基百科编辑都习惯了“File:”。虽然这不是什么大问题，但坚持使用“File:”能使我们的维基代码更标准化，从而更对外人友好。它也使得编写机器人程序更容易，例如我的所有脚本都理解“File:”而不理解“Image:”。Nicolas1981 (讨论) 2014年2月14日 (UTC) 07:41

机器人或脚本需要同时识别两者，因为两者都内置在MediaWiki软件中，并且都不会消失。K7L (讨论) 2014年2月15日 (UTC) 15:02

如果这是一个完美的世界就好了！我的脚本远非完美 :-) Nicolas1981 (讨论) 2014年2月18日 (UTC) 12:05

UUTP

查看Special:WantedPages，排名第一的“最需要”页面是“UUTP”，有127个红链（是排名第二的两倍多）。这个页面最初由User:Alice创建，作为其用户子页面的重定向，后来我将其快速删除，因为我们不允许从主命名空间重定向到个人用户空间。显然，所有现有的红链都是Alice作为其个人欢迎消息模板的一部分首次插入的，然后由User:W. Frank复制Alice的消息并将其作为他自己的插入到用户和IP讨论页面，然后由User:118.93nzp复制Frank的消息并将其作为他自己的插入。由于它实际上不是“最需要页面”，并且它是来自一个有争议的三人组（？）的有争议的欢迎消息的一部分，如果我在这几个页面上运行AWB来取消链接“UUTP”，有人会反对吗？我知道这在技术上会涉及到更改别人的消息文本，但替代方案是我们将永远将“UUTP”作为我们有史以来最需要页面的第一名。大家怎么看？Texugo (讨论) 2014年2月18日 (UTC) 01:24

用户页面上的可见差异会是什么？只是删除了一个[[UUTP]]的实例吗？ ？Andrewssi2 (讨论) 2014年2月18日 (UTC) 01:41

根据随机抽样，它似乎总是与“您自己的讨论页面”这些词链接。唯一的区别是这些词将变为普通的黑色文本，而不是红色链接。Texugo (讨论) 2014年2月18日 (UTC) 01:49

作为参考，这些链接的预期目标是User:Alice/Kitchen/Using User Talk pages。也许那里有一些信息可以合并到Wikivoyage:用户页面帮助中，然后UUTP链接可以替换为指向该页面的链接。如果认为这不合适，因为更改了其他用户发布的与意图不同的内容，我们应该只替换所有UUTP链接以指向Alice的子页面。Powers ^(讨论) 2014年2月18日 (UTC) 02:29

我仍然认为最简单的做法是直接取消链接，但如果有人现在自愿将内容合并到Wikivoyage:用户页面帮助，我也会同意。我宁愿尽可能避免第二个选项，因为我认为将IP用户和新用户引导到某个用户空间中的非官方页面是不合适的，特别是如果这可能会鼓励IP用户或新手将这样的问题用户视为某种导师。Texugo (讨论) 2014年2月18日 (UTC) 12:13

完全同意Texugo的看法。取消链接是解决办法。如果这不是政策，就不应该将其呈现给容易受影响的新手，更不应该由像Alice/Frank/118这样有问题的用户来呈现。-- AndreCarrotflower (讨论) 2014年2月19日 (UTC) 00:16

可以改为Special:我的讨论，但由于大多数这些都在用户讨论页上，所以该链接用处不大，最好取消链接。-- WOSlinker (讨论) 2014年2月19日 (UTC) 13:54

相关讨论正在Wikivoyage talk:使用MediaWiki模板#取消红链模板的链接进行。Texugo (讨论) 2014年2月19日 (UTC) 15:06

通用语言选择器将再次在此维基上默认启用，截止日期为2014年2月21日

2014年1月21日，MediaWiki扩展程序通用语言选择器 (ULS) 在此维基上被禁用。为登录用户添加了一个新偏好设置以开启ULS。此举是为了防止由于ULS网络字体导致页面加载缓慢，这是维基媒体技术运营团队在某些维基上观察到的行为。

我们现在准备再次启用ULS。暂时启用ULS的偏好设置将被删除。语言面板中已添加一个新复选框，用于启用/禁用字体传输。此维基将默认取消选中此项，但用户可以随时选择启用网络字体。这是我们在改进网络字体传输功能期间的临时解决方案。

您可以阅读公告和开发计划以获取更多信息。抱歉，此消息仅以英文撰写。谢谢。Runa

使用条款修正案

大家好，

请加入关于对维基媒体使用条款中关于未公开的有偿编辑的拟议修正案的讨论，我们鼓励您在那里发表意见。如果您能，请翻译此声明，我们欢迎您翻译拟议的修正案和介绍。请参阅元维基上的讨论以获取更多信息。谢谢！Slaporte (WMF) 2014年2月21日 (UTC) 22:00

鉴于大型Wiki-PR丑闻及其后果，我想问维基导游社区对此变化的看法。维基导游社区是否接受维基媒体全站政策，该政策要求受薪雇员必须披露其资金来源或其所属组织？如果我没记错的话，维基导游的一些重要贡献者是旅行社，这可能会影响这里的一些政策页面，包括Wikivoyage:不要吹嘘和Wikivoyage:欢迎，企业主。如果它通过，而且看起来很可能通过，那么后者页面Wikivoyage:欢迎，企业主需要更新以包含新的要求。TeleComNasSprVen (讨论) 2014年2月23日 (UTC) 12:48

我在这里评论。我认为提案背后的想法是好的，但按目前的措辞，它可能弊大于利。-- Ryan • (讨论) • 2014年2月23日 (UTC) 16:55

我提出了meta:Talk:使用条款/有偿贡献修正案#这不仅仅是关于维基百科作为问题。维基百科禁止原创研究，我们不禁止。当地的会展旅游局可能会做出建设性的贡献，也可能弊大于利，但我们需要根据其优点来处理每个问题。K7L (讨论) 2014年2月23日 (UTC) 19:07

请求协助：各国电话号码格式

根据Wikivoyage talk:电话号码#建议替换，我用一个更简单、希望更直接的表格替换了关于国家特定电话格式的冗长不完整的讨论：Wikivoyage:电话号码#国家特定示例。该表格的“示例”列中许多国家不完整，因此请为您熟悉的任何国家/地区添加一个格式正确的电话号码示例。示例应按它们在维基导游中显示的方式格式化，因此它们应包含国家代码，并在可本地拨打的号码块之间使用连字符，例如（在美国）本地号码为“+1 YYY XXX-XXXX”，免费号码为“+1-8YY-XXX-XXXX”。谢谢！-- Ryan • (讨论) • 2014年2月24日 (UTC) 02:37

有没有简单的方法批量导入OpenStreetMap POI？

我注意到user:Mey2008手动将大量单独坐标导入到新文章奥斯威戈中，并注明“参见Mapnik图层”。想必这个“Mapnik图层”是OSM的一部分；该项目已经包含各种兴趣点（地标、酒店、餐馆），并附有它们在OSM城市地图上显示出的名称和坐标。

如果这堆巨大的地理数据已经以某种自由许可存在，是否有可能实现其自动化使用？例如，新文章不是以空白的{{小城市骨架}}开始，而是以OSM中已有的POI列表开始，供维基导游添加描述和详细信息。另一种可能性是通过自动化流程将现有的维基导游列表与OSM POI匹配，以获取坐标。

这实现起来有多困难？K7L (讨论) 2014年2月26日 (UTC) 18:00

我无法谈论技术难题，但如果有任何指向POI数据（URL等）的指针，那将非常有用——更新文章时查找这些数据需要很长时间，因此如果有更简单的方法获取它，我很乐意使用。-- Ryan • (讨论) • 2014年2月26日 (UTC) 18:14

OSM通常有太多针对某个目的地的POI。虽然从外部来源导入地址和坐标会很好，但维基导游文章有巨大的风险会变成没有描述的无尽POI列表。特别是，这适用于酒店和餐馆。--Alexander (讨论) 2014年2月26日 (UTC) 18:19

这取决于我们如何处理数据。一个在人工监督下运行的工具仍然会将决定包含哪些点的最终权力留给人为编辑者。一个将坐标添加到现有POI的机器人脚本也将避免创建“过多POI”，因为它只是扩展了现有的列表。这两者都不会涉及w:user:Rambot式的在地图上每个普查指定点大规模创建页面。无论是哪种方式，都将是避免“重复造轮子”的一步，因为这能让我们不必手动生成OSM中已有的坐标和地址数据。K7L (讨论) 2014年2月26日 (UTC) 18:51

我也注意到动态地图的一层标出了POI，并想知道它们是否可以导入。导入所有POI显然不是很明智，只会给我们带来类似黄页那样的长列表。理想的界面是将POI显示在地图上，编辑者只需点击即可将其添加到（或许“激活”是更好的词？）或从文章中移除。ϒpsilon (讨论) 2014年2月26日 (UTC) 19:52

我支持一种能让手动导入列表更容易的工具/方法。请注意，OSM中的列表可能不再是最新的，甚至可能已关闭，我们希望阻止不加区别地添加列表。--Andrewssi2 (讨论) 2014年2月27日 (UTC) 00:03

在地理地图 中，可以激活右上角的“OSM”按钮。然后，当您点击地图上的图标时，会显示OSM数据。很好的例子：餐馆“AKKU”或“Alte Münze”。该功能仍在测试模式中，需要优化。-- Joachim Mey2008 (讨论) 2014年2月27日 (UTC) 06:25

Joachim，你真是一位巫师！Danapit (讨论) 2014年2月27日 (UTC) 06:44

有趣。我点击“AKKU”后获得了坐标，但没有地址，也没有你添加的营业时间。如果我在nominatim.openstreetmap.org中查看POI，会发现那里有额外的信息。有没有办法将{{列表}}（无论是哪种语言）作为“复制模板”格式之一，并附带原始POI（节点或方式）标签附带的任何数据？原始XML数据（点击openstreetmap.org标准地图视图上的“导出”时导出的任何内容）看起来像

 <node id="" visible="true" version="" changeset="" timestamp="" user="..." uid="" lat="43.6461730" lon="-79.3797376">
  <tag k="addr:city" v="Toronto"/>
  <tag k="addr:country" v="CA"/>
  <tag k="addr:housenumber" v="200"/>
  <tag k="addr:state" v="ON"/>
  <tag k="addr:street" v="Bay Street"/>
  <tag k="amenity" v="fast_food"/>
  <tag k="name" v="Harvey's"/>
  <tag k="operator" v="Cara"/>
  <tag k="wheelchair" v="yes"/>
 </node>

应该变成{{eat|name=Harvey's |address=200 Bay Street |latitude=43.6461730 |longitude=-79.3797376 |description=快餐}}。通常OSM POI除了名称、类型（“设施”或“旅游”及其子类型）和坐标之外，几乎没有其他信息，但我们应该使用现有的信息。K7L (讨论) 2014年2月27日 (UTC) 14:08

请先点击右上角的“OSM”按钮！所有信息都会出现。-- Joachim Mey2008 (讨论)

看起来好多了，但我似乎每个POI都得到了“吃”的模板（而不是“喝”、“买”……），并且街道地址没有复制到模板中。K7L (讨论) 2014年2月27日 (UTC) 16:46

正如我上面所说：“OSM数据”功能仍在测试模式中，必须进行优化。我担心许可问题（ODbL）。在继续开发之前，这必须确定无疑。-- Joachim Mey2008 (讨论) 2014年2月27日 (UTC) 17:13

我对许可证兼容性也有同样的担忧。我知道无法将维基百科的数据导入OSM（我曾想批量导入火车站名称，但在OSM列表讨论后，这在某些国家可能不被允许，所以我没有这样做）。有人有关于这方面的信息/分析吗？目前维基导游提供了一个工具，可以从OSM/Mapnik选择坐标，我不知道这是否可以（许可证问题相当复杂！）。 - Fabimaru (讨论) 2014年3月2日 (UTC) 18:35

一对坐标可能受版权保护吗？通常需要一些创造性投入才能被视为可受版权保护的作品。K7L (讨论) 2014年3月2日 (UTC) 23:53

坐标是使用OSM图块（CC BY-SA许可证）计算的。我认为这里没有问题。我的问题是关于从OSM数据库（ODbL许可证）导入其他数据。-- Joachim Mey2008 (讨论) 2014年3月3日 (UTC) 05:18

根据欧盟法律，即使公共可访问数据库包含非创意作品（城市名称、坐标），也受到保护，未经同意不得采集数据。嗯，我猜OSM基金会不会因此起诉WP基金会（但如果有官方声明会很好）。在澳大利亚，我认为，一家电话簿公司输掉了针对另一家公司提取电话号码的诉讼，因为这些号码不属于创意作品。所以我没有答案，但我想说这不像人们想象的那么显而易见，也许其他国家还有其他限制。无论如何，感谢您提供关于图块的信息，我松了一口气！编辑：关于CC BY-SA许可证，提取的坐标难道不是图块的衍生作品吗？在这种情况下，它将要求授予相同的许可证。编辑2：我错了，维基百科也是CC BY-SA - Fabimaru (讨论) 2014年3月3日 (UTC) 07:00

看起来将OSM POI重用于维基导游是可以的：https://help.openstreetmap.org/questions/31250/can-i-export-osm-poi-metadata-to-wikivoyage-cc-by-sa-gfdl Nicolas1981 (讨论) 2014年3月4日 (UTC) 09:25

谢谢你的链接。我的理解是，这并不清楚。Fabimaru (讨论) 2014年3月5日 (UTC) 13:03

有趣。维基导游是CC-BY-SA，从未是GFDL（与维基百科不同，维基百科最初使用GNU许可证，后来才切换），但我没有预料到散文（维基导游）和数据库（维基数据）之间的区别。无论如何，看起来要将OSM POI可用地导入到WV中需要大量的手动编辑，因为它们缺乏完整的描述，通常只是（名称、类型、坐标），而缺少城市地址或电话。OSM的Nominatim可以获取这些的街道名称，但这只是近似值。决定导入哪些POI也需要手动进行。K7L (讨论) 2014年3月4日 (UTC) 17:16

创建新帐户界面中的错误

我是一个新用户，刚刚创建了一个账户。用于创建新账户的网页界面存在一些错误。它说电子邮件地址是可选的，但如果你不输入电子邮件地址，它就无法正常工作。结果的错误消息没有准确地解释问题（即缺少电子邮件地址）；它提到了cookie，并模糊地说无法验证来源。--Bcrowell (讨论) 2014年1月12日 (UTC) 18:34

Bcrowell，感谢您提请我们注意这一点。

我既不是管理员也不是程序员，但我相信很快就会有兼具这两种身份的人（比如@Wrh2:）会查看此问题...

感谢您创建阿皮萨科文章！--118.93nzp (讨论) 2014年1月12日 (UTC) 21:55

这可能应该在m:维基媒体论坛提出，因为它可能不仅仅影响英文维基导游。--Rschen7754 2014年1月12日 (UTC) 22:40

无法重现该问题——我刚刚创建了一个没有电子邮件地址的测试帐户，并且运行良好（Chrome 33）。这是关于哪个浏览器？这还是一个问题吗？--Malyacko (讨论) 2014年2月24日 (UTC) 18:04

我昨天创建账户时遇到了问题。我希望使用我在其他维基媒体网站上使用的相同用户名（The Photon），但我被告知该名称与现有账户（The photon）过于相似，而您可以看到该账户（来自红链）实际上并不存在。El Photon (讨论) 2014年3月13日 (UTC) 02:58

这是我猜测发生了什么事。当您现在创建一个帐户时，该帐户是一个单一用户登录——一个全球维基媒体帐户。您无法在此处只在维基导游创建一个帐户（请参阅此处，您的El Photon帐户是SUL帐户）。尝试创建全球“The photon”或“The Photon”帐户将无法成功，因为这两个帐户（非SUL帐户）在某些维基上都存在。您应该做的是前往en.wikipedia（或您拥有“The Photon”帐户的另一个维基），然后前往名为“Special:MergeAccount”的页面。这将把您的帐户设置为SUL，并允许您使用相同的登录名登录任何维基。Powers ^(对话) 2014年3月13日 (UTC) 16:04

维基媒体博客文章

供您参考，今天维基媒体博客上有一篇不错的文章，内容是关于Saqib的。 -- Ryan • (对话) • 2014年2月27日 (UTC) 08:22

+1。Saqib，我知道我有时会成为您的眼中钉（请参阅最近在dotm上的讨论），但我确实非常钦佩您不知疲倦的工作。-- AndreCarrotflower (对话) 2014年2月27日 (UTC) 08:25

Saqib，干得好！感谢您一直支持WV！Andrewssi2 (对话) 2014年2月27日 (UTC) 12:50

哦，你们找到了。谢谢！--Saqib (对话) 2014年2月27日 (UTC) 14:34

是的，非常好。很高兴看到网站得到推广，Saqib也得到了应有的赞誉。

不过，这提出了一个问题。讲英语的当地人是这个网站的一大资源—他们的知识和视角补充了游客可以提供的信息，而且他们还可以进行本地语言的翻译。我们在不同地方有一些优秀的人才，但是我们应该做些什么来吸引更多人呢？Pashley (对话) 2014年2月27日 (UTC) 15:53

太棒了，Saqib！Danapit (对话) 2014年2月27日 (UTC) 21:32

Saqib，文章写得太棒了！我经常和一位巴基斯坦的朋友下棋，希望有一天能去巴基斯坦看他……Matroc (对话) 2014年2月28日 (UTC) 04:04

真的很棒的文章！精彩的故事，精彩的照片。祝你旅途顺利！Ikan Kekek (对话) 2014年2月28日 (UTC) 10:30

谢谢大家。--Saqib (对话) 2014年2月28日 (UTC) 15:17

Saqib干得好！成功提升了巴基斯坦和WV的形象！--Nick ^对话 2014年2月28日 (UTC) 23:16

带有ref标签的文章

有一些页面包含<ref>标签，可以改成仅链接。例如俄亥俄州牛津。只是想知道是否有人可以编辑MediaWiki:Cite error refs without references并将其设置为以下内容，以便这些页面可以被跟踪到一个类别中以便于查找和编辑。

<code><ref></code> tags exist, but no <code><references/></code> tag was found[[Category:Articles with ref tags]]

谢谢。-- WOSlinker (对话) 2014年3月3日 (UTC) 22:25

用户也不应该使用引用标签；也许我们不应该将其包含在措辞中。Powers ^(对话) 2014年3月4日 (UTC) 01:18

谢谢您添加了类别。我忘了在类别周围加上 includeonly 标签。它们也应该被添加。抱歉。-- WOSlinker (对话) 2014年3月4日 (UTC) 07:11

<code><ref></code> tags exist, but no <code><references/></code> tag was found<includeonly>[[Category:Articles with ref tags]]</includeonly>

完成。-- Ryan • (对话) • 2014年3月4日 (UTC) 07:19

删除WT归属模板

大家好。我想从User talk:Ikan Kekek删除那个愚蠢的模板，因为所有与我在WT的时间有关的内容都已经存档了。我如何从我的用户对话页删除这个模板？Ikan Kekek (对话) 2014年2月27日 (UTC) 12:29

如果你还记得，User:Pashley为我们处理了Talk:Iran页面。我仍然不知道他是怎么做到的。Andrewssi2 (对话) 2014年2月27日 (UTC) 12:49

删除页面。然后只恢复迁移后的编辑。--亚历山大 (对话) 2014年2月27日 (UTC) 13:00

是的，删除页面并重新创建可以消除模板。一般来说，这应该在深思熟虑后才进行；我们有法律和道德义务给予适当的归属。Pashley (对话) 2014年2月27日 (UTC) 13:14

[编辑冲突]我必须删除页面？所有编辑都是在迁移之后完成的，每一个都是。旧的编辑（链接在我用户对话页的顶部）已存档。除了我将页面全部内容复制到空白文件，删除页面，然后重新创建页面并放回之前页面的内容之外，没有更简单的方法来完成这个操作吗？Ikan Kekek (对话) 2014年2月27日 (UTC) 13:16

不，谁说过复制粘贴？您可以在删除后选择性地恢复仅在迁移之后进行的编辑。Powers ^(对话) 2014年2月27日 (UTC) 14:07

为了做到这一点，我必须剪切内容，粘贴到其他地方，然后重复这个过程。应该有一个更简单的方法来从不再需要的文章中删除模板。Ikan Kekek (对话) 2014年2月27日 (UTC) 21:24

我不熟悉WikiMedia软件，但通常在IT解决方案中，如果需要完全删除模板才能移除，我不会感到惊讶。

流程应该是什么？用户可以在讨论页上请求此操作，然后由管理员确保没有WT内容，然后再执行此操作吗？

此外，如果WT内容已存档，我们如何处理新创建的存档页面上缺少归属的问题？Andrewssi2 (对话) 2014年2月28日 (UTC) 00:36

伊坎，听我说。作为管理员，您有能力在删除维基页面后选择性地恢复特定编辑。例如，请参阅w:Wikipedia:Selective deletion。无需复制粘贴。Powers ^(对话) 2014年2月28日 (UTC) 02:08

我试过了，结果太复杂了（我第一次尝试失败了），所以我删除了我的用户对话页面并重新创建了它。然而，不知为何，WT归属也从User talk:Ikan Kekek/archive中删除了，这不是我打算做的，因为它包含了迁移之前的内容。那么我们现在该怎么办？Ikan Kekek (对话) 2014年2月28日 (UTC) 07:47

恢复您对话页上的所有已删除编辑，然后将您的对话页移动到您的存档页，之后您可以编辑您的存档页，使其只包含您想要存档的内容。-- WOSlinker (对话) 2014年2月28日 (UTC) 08:05

我不明白。你是说如果我恢复已删除的编辑，WT归属就会重新出现吗？Ikan Kekek (对话) 2014年2月28日 (UTC) 09:11

不起作用——与撤销删除之前相同。Ikan Kekek (对话) 2014年2月28日 (UTC) 09:43

您的存档页面没有WT归属，因为您是在迁移后创建的。WT上没有要归属的User talk:Ikan Kekek/archive。另一方面，您的当前对话页确实有WT归属，因为其历史记录包含了迁移之前的编辑。

解决此问题的一种方法是通过移动将您当前的对话页面存档（例如，到用户对话：Ikan Kekek/archive 2）。这会保留编辑历史并用重定向替换您的对话页面。然后您可以编辑您的对话页面以删除重定向并重新开始（并在顶部包含指向存档页面的链接）。这应该将WT归属移动到Archive 2子页面，并使您的对话页面没有归属。

一个更复杂的解决方案是删除您的对话页面，然后只选择性地恢复迁移之后发生的编辑。不过，我不能亲身保证这会奏效。

为了彻底起见，我建议如下：

1. 删除您的存档页面。
2. 删除您的对话页。
3. 从您的对话页中选择性地恢复仅在迁移之前发生的那些编辑。
4. 将恢复的编辑移动到存档。不要创建（或在创建后删除）生成的重定向。
5. 从您的对话页中选择性地恢复其余编辑。

-- Powers ^(对话) 2014年2月28日 (UTC) 18:45

谢谢。我理解您的解释，但我真的很困惑，因为User talk:Ikan Kekek/archive似乎应该包含WT归属，因为它包含了迁移之前的编辑，而User talk:Ikan Kekek不应该包含，因为我已经存档了那些迁移之前的编辑。如果您说的是因为WT没有User talk:Ikan Kekek/archive，所以该页面不应该有WT归属，那么我的任何用户对话页面都不应该有WT归属吗？Ikan Kekek (对话) 2014年2月28日 (UTC) 22:15

你似乎忽略了WT归属是程序性添加的。我们无法事后添加，因此在迁移后创建的页面（包括您的存档页面）无法拥有它。系统无法知道您粘贴到存档页面中的帖子来自您的主对话页面，所以它无法显示WT归属。相反，如果您将您的对话页面移动到存档名称，WT归属应该随之移动。Powers ^(对话) 2014年3月1日 (UTC) 01:20

如果我们想在相关的存档页面上添加WT归属，我们能像使用{{swept}}一样，简单地使用一个模板来实现同样的目的吗？Andrewssi2 (对话) 2014年3月1日 (UTC) 06:55

我们可以这样做，但这几乎没有必要，因为帖子都已签名。我并不是建议伊坎有必要保留该归属通知，而是在解释为什么该通知在他的对话页上，而不是在他的存档页上。Powers ^(对话) 2014年3月1日 (UTC) 18:16

更多统计数据

此网站有一系列与维基导游相关的良好统计数据。很高兴看到我们似乎每月达到了1,000,000次点击量，并且Reddit对我们的社交媒体存在非常重要（一个WV账户可能有用吗？）。尽管如此，它也显示了我们可以在哪些方面改进以及我们仍然需要做的工作。--Nick ^对话 2014年3月4日 (UTC) 19:54

相关网站 / 外部链接

大家好，我来自西班牙语维基导游。我创建了一个模块和模板，用于直接从维基数据获取维基百科、维基共享资源和Dmoz的链接。我们将把这个模板包含在{{pagebanner}}中，并删除旧的链接。我留下链接以防有人感兴趣。Módulo:EnlacesExternos。Plantilla:Enlaces externos。致敬，--Kizar (对话) 2014年3月6日 (UTC) 20:46

我想补充一点，类似的模块已经很久以前在乌克兰语和俄语维基导游中实现。令人遗憾的是峰会页面现在处于休眠状态。--亚历山大 (对话) 2014年3月6日 (UTC) 22:55

这似乎是我们应该实施的。现在我非常忙，但如果没有人处理，我可以看看这个。--Rschen7754 2014年3月8日 (UTC) 02:11

移动网站证书问题？

当使用Android三星Galaxy Tab 2平板电脑浏览WV时，WV会更改网页的移动版本，即https://en.m.wikivoyage.org/wiki/Talk:United_States_of_America

最近它一直给我一个SSL连接错误（错误代码ERR_SSL_PROTOCOL_ERROR）

还有其他人遇到这种情况吗？这对许多潜在读者来说会很糟糕。Andrewssi2 (对话) 2014年3月7日 (UTC) 15:01

仅供参考，我使用了三星浏览器和谷歌浏览器。在Window Phone 8设备上似乎也有同样的问题。（将浏览器设置更改为“桌面模式”可以解决此问题）Andrewssi2 (对话) 2014年3月7日 (UTC) 15:12

Android 2.3上使用自带浏览器和Dolphin浏览器没有问题。-- Joachim Mey2008 (对话) 2014年3月7日 (UTC) 15:25

直接从您的桌面导航到移动页面，例如https://en.m.wikivoyage.org/wiki/United_States_of_America，怎么样？Andrewssi2 (对话) 2014年3月9日 (UTC) 05:18

使用Firefox、Internet Explorer或Chrome（Windows）均无问题。- Joachim Mey2008 (对话) 2014年3月9日 (UTC) 05:58

你是对的。我刚刚从我在美国的电脑上（远程）试了一下，一切正常。

看来我们的移动页面在中国大陆境内无法访问。这有点奇怪，因为桌面版是正常的。Andrewssi2 (对话) 2014年3月9日 (UTC) 06:08

Wts命名空间

Special:WantedPages显示许多指向Wts:命名空间中不存在页面的链接；那是Wikitravel Shared，他们用于跨语言版本共享图片和其他内容的共享空间。这个命名空间在这里从未存在过，我认为所有需要从旧网站移动的内容早已被移动。

有没有办法修改软件，使任何指向该命名空间，甚至任何指向不存在的命名空间的链接，在点击时会显示一些或多或少有用的错误消息，并且/或者这些链接不会出现在“所需”列表中？Pashley (对话) 2014年3月8日 (UTC) 01:26

我们现在使用维基共享资源，但我认为目前指向这些页面的链接应该取消链接，转而使用其他方式，例如双引号或加粗链接。-- TeleComNasSprVen (对话) 2014年3月8日 (UTC) 03:57

将wts设置为维基导游命名空间的别名可以解决很多问题。Powers ^(对话) 2014年3月9日 (UTC) 18:31

手动取消这些页面的链接，通过修复源页面上的链接工作量太大；有几十个，其中至少10个每个都有超过10个链接。机器人可以完成这项工作。

在这里创建Wts:页面作为重定向（主要指向共享资源）是可行的，但我不确定政策对创建新命名空间有什么规定。

将wts设为别名听起来不错，尽管我不确定具体如何操作以及实际效果如何。Pashley (对话) 2014年3月9日 (UTC) 18:57

恕我直言，创建命名空间别名的唯一重要反对意见通常是1) 可能与现有页面标题冲突，以及2) 可能与基于ISO系统的跨语言链接冲突。正如我们从Special:PrefixIndex/Wts中看到的，它只返回一个没有冒号的条目，因此与现有页面标题没有冲突，而且不太可能存在一个名为Wts:Foo的实际位置。SIL和Ethnologue报告也返回空值，因此除非ISO修改其代码以适应某种新语言，否则它不太可能被用作跨语言代码。技术上可行，但我到目前为止还没有看到任何反对意见。TeleComNasSprVen (对话) 2014年3月9日 (UTC) 20:24

我不认为命名空间别名会起作用——其中一些链接应该指向共享资源（Wts:Special:Upload），大多数现在并没有真正的链接位置（Wts:Main Page，Wts:Technical requests）——但如果我们能达成一致的解决方案，那么使用WV:AWB就可以很容易地实现。我建议只用“nowiki”将现有wts链接括起来（<nowiki>[[wts:Special:Upload]]</nowiki>），因为这些链接大部分已经过时了。有没有人更喜欢其他解决方案？-- Ryan • (对话) • 2014年3月9日 (UTC) 20:40

我仍然不习惯修改对话页面上的旧评论。我们当初在将“Wikitravel”更改为“Wikivoyage”时不应该这样做，现在也不应该。如果我们设置一个别名，那些仍然是红色链接的页面可以被创建为（软或硬）重定向到正确的位置。如果我们不想设置别名，那么我们应该根据需要设置重定向。Powers ^(对话) 2014年3月10日 (UTC) 19:26

项目创意征集：社区实验资助现已开放申请

如果此消息并非您使用的语言，请谅解。请协助翻译。

您是否有能改善社区的项目想法？维基媒体基金会的个人参与资助金帮助个人和小型团队组织为期6个月的实验。您可以获得资金，尝试您在线社区组织、外展、工具构建或研究方面的想法，以帮助维基导游变得更好。三月份，我们正在寻找新的项目提案。

以往个人参与资助项目的例子

• 为中文维基百科组织社交媒体宣传（材料费350美元）
• 改进可视化编辑器的小工具（开发者费用4500美元）
• 协调维基百科人获取可靠来源（项目管理、顾问和材料费7500美元）
• 构建维基文库社区与战略愿景（组织和旅行费用10000欧元）

提案截止日期为2014年3月31日。有多种方式可以参与其中！

期待您的参与，

--Siko Bouterse，维基媒体基金会个人参与资助项目负责人 2014年2月28日 (UTC) 19:44

伙计们，我们能从中获利吗？考虑制作并向旅游局发送实际的纸质宣传册，邀请他们更新自己的城镇？或者找一位愿意并能够解决紧迫技术问题（例如无法翻译成英文的动态地图）的开发人员。或者开发我们可以使用的其他技术工具？2014年3月3日 (UTC) 08:19 JuliasTravels (对话) 2014年3月3日 (UTC) 08:20

您的宣传册主意听起来不错，但问题是谁愿意做这项工作，以及我们是否应该期望旅游局给予良好回应，因为Wikivoyage:Tourism Bureau Expedition已经停止了。--Saqib (对话) 2014年3月3日 (UTC) 11:09

我刚刚在想是否可以请Joachim考虑申请一笔资助，因为他有良好的业绩记录，而且仍有许多潜在目标可以实现，例如改进功能和静态地图打印。一些资金可能会在支持和激励方面有所帮助。可能与Wikivoyage EV协会、User:DerFussi和User:RolandUnger一起。

除此之外，为维基文库构建社区和战略愿景是另一个WMF项目的一个非常有趣的方法，尽管这需要付出一些努力才能实现。-- torty3 (对话) 2014年3月3日 (UTC) 11:50

页面排名

英文维基导游的页面排名似乎有所提高，达到6/10（与WT相同）。不确定这是否是最近的事情。或者它是否解决了在谷歌上不显示的问题。

虽然德语读者有所增加，但英语读者量并没有真正改变。 旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月8日 (UTC) 20:55

Nick在上面提供了这个有趣的链接，但数据与我们自己的数据差异很大。德语和英语几乎同样受欢迎。而意大利语则较少。如果我们获得WT七分之一的流量，那也不算太坏。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月8日 (UTC) 21:04

在我看来，第一步是提高我们的 Google PageRank。我认为让我们的 PageRank 高于 WT 并不是一个不合理的目标，尤其是在他们的内容停滞不前，并且受到越来越多的垃圾邮件污染的情况下。想象一下这会对 Google 搜索结果造成什么影响。至于我们与 WT 之间的流量差异，我们必须耐心，不要气馁；这会随着时间而来。我们正朝着正确的方向前进。坦率地说，我宁愿流量逐渐增加；回想起 WMF 推出时流量的暂时飙升，一下子适应那么多有点吃不消（至少对我而言）。-- AndreCarrotflower (talk) 2014年3月8日 (UTC) 21:44

似乎还有很多中文维基百科的链接指向WT。已经修复了一些。不过好像有机器人会抓取这个网站？我们有没有中文编辑可以帮忙？旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月8日 (UTC) 22:10

有没有理由将“en.wikivoyage.org”链接为外部URL，而不是使用跨语言链接（或模板化的跨语言链接）到[[wikivoyage: ？外部样式链接会得到那个丑陋的“nofollow”，我们不想要。 K7L (talk) 2014年3月9日 (UTC) 04:44

由于有一个新的http://zh.wikivoyage.org网站，中文维基百科应该链接到那里而不是英文维基导游。也许可以将其作为一个机器人项目，让中文维基导游的用户在他们的客栈中讨论。-- torty3 (talk) 2014年3月9日 (UTC) 09:44

已完成。有人能访问 [www.comScore.com] 数据吗？旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月10日 (UTC) 05:35

我没有。但也许我们可以放弃“WikiT 正在被垃圾邮件淹没，最终会毁掉它”的说法了？这在分叉时就被预测过。没有发生。已经快两年了。他们已经做到了。我所看到的垃圾邮件并不比这里多（至少在一天的清理工作之后）。垃圾邮件不会毁掉他们。一系列“Google 技巧”也不会给我们带来访客。我们从帽子里拿出了一只兔子——把维基百科的链接改为指向我们而不是他们——我们的流量几乎全部来自那里。我们是 Wikitravel 的一个克隆。随着时间的推移——一个漫长的时间——其中一些会发生变化。但没有灵丹妙药。我同意詹姆斯的话：我们很幸运能拥有 Wikitravel 七分之一的访客。Google 知道谁先来的，在我们的内容在全世界独一无二之前，我们永远无法摆脱 WT 的压制。SpendrupsForAll (对话) 2014年3月10日 (UTC) 19:12

是的，除非我们能说服谷歌调整。或者真的通过社交媒体推广这个网站。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 01:22

呃…说服 Google 调整？他们为什么要弯曲自己的规则，偏袒一个小型的免费网站，而不是一个大型、成熟、受欢迎且有广告支持的网站，而那个网站*能为 Google 赚钱*？呃…祝你好运。SpendrupsForAll (对话) 2014年3月11日 (UTC) 01:33

你说得很有道理，保罗。

我不认为你们的任何红利会面临太大危险，而这里的一些重要人物拒绝改进本网站的搜索引擎优化，因为他们宁愿在一个小池塘里当大鱼。--118.93nzp (对话) 2014年3月11日 (UTC) 05:46

呃，欢迎回来。这不是你恢复编辑的好方式。Ikan Kekek (对话) 2014年3月11日 (UTC) 05:52

谷歌有“不作恶”的座右铭。就搜索引擎优化而言，一旦我们能证明它对已有的文章有效，它就会得到我的全力支持。我的尝试失败了。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 05:55

暂时撇开118不谈，我认为SpendrupsForAll的上述言论令人质疑其在Wikivoyage的意图。Spendrups，如果你认为Wikitravel是更好的网站，你为什么不在那里编辑，却（明显带着得意）告诉我们我们比我们的竞争对手差得多？我会将你的评论描述为捣乱（如果不是类似于WMF启动后IBobi所做的恶作剧），并建议你将来要么建设性地贡献，要么干脆不要贡献。-- AndreCarrotflower (对话) 2014年3月11日 (UTC) 05:59

你说的很可能是对的，Spendrups打算在这个帖子中捣乱，但我没有把他的评论解读为捣乱，而是严厉直言。除了关于WT和这里垃圾邮件数量的评论，我无法评论，因为我已经很久没有访问那个网站了。Ikan Kekek (对话) 2014年3月11日 (UTC) 06:05

我感到困惑。SpendrupsForAll在哪里说WT更优，或者WV更差，又在哪里表现出幸灾乐祸？我认为TA提出了很好的观点，包括内容才是最大的区别。Andre，如果你受到上面关于SpendrupsForAll身份的建议的影响，那么我发现很难相信这个建议。Nurg (对话) 2014年3月11日 (UTC) 08:27

那些反对者说什么并不重要。我们还没有像我希望的那样迅速成功，但我们会成功的。我们有一个网站，我们有独立性，我们有一个真实的CC BY SA许可，我们是一个运动的一部分。我们有竞争。这只会让我们更加努力工作:-) 如果这些是来自WT的编辑来挑衅我们，最好的办法就是不理会他们……旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 06:08

再看看数据。如果看页面浏览量，WT有720万次访问 * 1.8页 = 1300万次页面浏览量。WV有100万次访问 # 3.1页 = 310万次页面浏览量，这意味着我们更接近25%:-) 恭喜大家。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 06:12

此外，2月份的读者量增长了60%以上，之前的数字是1月份的。3月份看起来会少一些。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 06:15

致Nurg: 我坚持我对SpendrupsForAll的说法，并且我拒绝你在编辑摘要中将其归类为“奇怪”。首先，Spendrups在他的评论中确实强烈暗示他认为Wikivoyage不如Wikitravel（“我们很幸运拥有WikiT的七分之一的访客”）和/或某种王位觊觎者（“谷歌知道谁先来的”；“我们是Wikitravel的克隆”）。再加上他关于Wikitravel优越性的更明确声明、他一般的捣乱和挑衅，以及他对Wikivoyage事务的惊人熟悉，而编辑历史却如此之短，包括没有任何主命名空间贡献（正如Ikan Kekek所阐明）——这在过去几次都是问题用户的危险信号——一个更大的图景浮现出来。在这种情况下，我认为质疑用户的善意是完全合理的。你会注意到我没有提议禁止Spendrups用户，也没有对他采取任何行政行动，而是平静地要求他避免敌对性贡献。我们的维基强调社区成员之间的文明交往，这是有充分理由的。我们过去已经处理过足够多似乎只对制造麻烦感兴趣的用户的​​问题，我认为我们不应该回避对从事这种行为的人进行问责。-- AndreCarrotflower (对话) 2014年3月11日 (UTC) 11:28

而且他表示他将于2014年1月31日离开 。所以Andre提出了合理的观点。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 18:13

WT 的现状

Spendrups建议“也许我们可以放弃‘维基旅行社正在充斥垃圾邮件并最终会被其扼杀’的观念了？这在分叉时就被预测过。没有发生。已经快两年了。他们已经做到了。我所看到的垃圾邮件并不比这里多（至少在一天清理之后）。”由于我时不时地查看WT，我想我可以评论一下。

查看新页面时，我经常看到那里有很多垃圾邮件，而这里几乎没有。目前，他们只有两个新的垃圾邮件页面，但5-10个是常态，我曾看到超过20个。

我之前故意留下了一个非常明显的垃圾邮件页面—没有旅行内容，标题奇怪，并有大量可疑的外部链接—想看看其他人需要多久才能注意到。我们已经等了九个月，还在继续。

我们目前有一个死胡同页面，而那里有几百个；没有双重重定向，而那里有九个；两个孤立页面，而那里有几百个；大约40个未使用的文件，而那里有一千多个。

我得出结论，WT没有得到妥善维护，因为几乎所有有能力的管理员都离开了。这可能不会杀死它，但肯定存在问题。Pashley (对话) 2014年3月11日 (UTC) 19:43

我本该预料到WT会不沉。K7L (对话) 2014年3月11日 (UTC) 20:38

WT 链接

一些链接已在英文维基百科上收集，我已将它们替换为维基导游链接。我们需要确保这在其他语言中也正在发生。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月11日 (UTC) 06:51

你能提供一些你做过的例子吗？

另外，尽管我们都属于维基媒体，但我们知道维基百科是否允许我们这样做吗？（维基百科文章已经有维基导游模板链接了）Andrewssi2 (对话) 2014年3月11日 (UTC) 10:29

这是一些更改列表 -- WOSlinker (对话) 2014年3月11日 (UTC) 10:51

维基百科的一些语言版本仍然存在一些WT模板；https://ms.wikipedia.org/w/index.php?title=Khas:Pautan_ke/Templat:Wikitravel&limit=200是最突出的（所有这些都需要替换为Wikivoyage模板，然后才能提名旧模板删除）。检查其他维基百科，确保已从文章中删除的模板被提名快速删除，并且不会作为垃圾邮件再次出现在页面中，这可能值得做。K7L (对话) 2014年3月11日 (UTC) 18:41

格式问题

这里似乎有一个格式问题旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月12日 (UTC) 18:54

能说得更具体些吗？Powers ^(对话) 2014年3月13日 (UTC) 16:13

抱歉，这里多了一个空格。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月15日 (UTC) 07:35

抱歉，我的电脑上没有看到。系统配置呢？TeleComNasSprVen (对话) 2014年3月15日 (UTC) 09:51

验证码问题

我刚才遇到了验证码问题。当我尝试使用“添加条目”界面提交餐厅列表时，我对验证码的回复（由于提交中包含外部链接）未被接受，并且我被反复要求回答新的验证码。当我按下“取消”而不是“提交”以尝试返回新的条目对话框时，页面冻结并显示“正在保存...”消息。El Photon (对话) 2014年3月13日 (UTC) 03:04

这听起来像是列表模块的一个错误，应该在Bugzilla上跟踪。Powers ^(对话) 2014年3月13日 (UTC) 16:14

日语维基导游

这种语言似乎是需要的。旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月13日 (UTC) 05:45

看来我们在这里的孵化器里有它了。有计划导入所有旧内容吗？旅行医生詹姆斯 (对话 · 贡献 · 电子邮件) 2014年3月13日 (UTC) 05:46

如果我没记错的话，当我们讨论分叉时，日本维基旅行社社区出于某种难以理解的原因选择留在了IB。真是奇怪。-- AndreCarrotflower (对话) 2014年3月13日 (UTC) 07:06

日本WT基本上只有一个主要贡献者（Shoestring）和其他少数人一起推动这个项目，他决定留下。我可能错了，但我相信所有以前的语言版本（日语、阿拉伯语等）都和英语版本一样被保存了下来。如果存在该语言版本，它不会被恢复吗？可能只是需要一些受信任的志愿管理员来监督这个项目。ChubbyWimbus (对话) 2014年3月13日 (UTC) 07:19

所有WT语言版本的XML和图片转储在最初分叉时都提供给Wikivoyage。如果需要，我仍然有副本，但其他人需要做导入工作并进行适当的归属。-- Ryan • (对话) • 2014年3月13日 (UTC) 07:44

如果您有转储文件，可能需要联系m:User:MF-Warburg，孵化器的人遇到了获取文件的困难。（不过他还有几周的假期）。--Rschen7754 2014年3月13日 (UTC) 16:40

电子邮件已发送。-- Ryan • (对话) • 2014年3月13日 (UTC) 16:49

User:Wrh2 - 另请参阅 incubator:Incubator:Wikivoyage import。--Rschen7754 2014年3月14日 (UTC) 04:51

如果我们必须从转储文件开始，为什么不从实时日语维基旅行社转储呢？我想它没那么大。我以前写过一个工具：https://github.com/nicolas-raoul/OxygenPumpNicolas1981 (对话) 2014年3月14日 (UTC) 10:00

提议对使用条款修正案进行可选更改

大家好，针对关于未披露有偿编辑的使用条款修正案讨论中的一些社区意见，我们准备了两项可选更改。请阅读元维基上的这些可选更改并分享您的评论。如果您可以（并且这是一个非英语项目），请翻译此公告。谢谢！Slaporte (WMF) 2014年3月13日 (UTC) 21:56

用户被强制登出

已从客栈移至客栈

维基媒体用户（包括Meta）因OpenSSL实现SSL和TLS协议中发现的漏洞而被强制登出并重新登录。

维基媒体基金会服务器已受到影响，并已于今天早些时候更新了其OpenSSL版本；作为预防措施，所有用户会话令牌将被重置——这将导致会话丢失并强制用户使用新的安全令牌重新登录。

维基媒体基金会还建议用户更改其登录维基百科所用的密码。阅读更多。Jalexander (对话) 2014年4月8日 (UTC) 23:47 (非常感谢Odder撰写了我在此处借用的文本)

维基教科书

您好！

昨天，我快速浏览了维基教科书，注意到他们有几本旅游指南和旅游主题，这些内容可能很适合整合到我们维基导游的指南中。他们没有很多内容，而且大部分有一段时间没有编辑了，所以我怀疑它们不会被特别怀念，尽管我已经在这里征求了社区的意见。当然，那里的指南不符合我们的模板，但我非常乐意筛选它们，将它们合并到对应的指南中，并在必要时创建新文章。

你觉得怎么样？这值得做吗？即使没有其他作用，这也应该能使维基导游成为维基媒体家族中旅游指南的明确存储库。

尼克 ^对话 2014年2月3日 (UTC) 20:07

很棒的发现！是的，可用信息应该合并到WV中，并在每个讨论页留下友好的消息，建议在哪里可以找到更最新的指南并建议加入。例如：https://wikibooks.cn/wiki/Talk:Enjoy_Tokyo/RoppongiNicolas1981 (对话) 2014年2月4日 (UTC) 08:51

维基教科书总体上不是很活跃，但我更希望在批量移动内容之前得到他们的同意，以免冒犯任何人。--Rschen7754 2014年2月4日 (UTC) 08:55

Nick 的留言很棒，我想。我假设如果一周内没有回复，就可以进行合并了。Nicolas1981 (对话) 2014年2月4日 (UTC) 09:25

我也会向管理员求助，确保它被注意到——QuiteUnusual 备受推荐。--Rschen7754 2014年2月4日 (UTC) 09:28

我已将 QuiteUnusual 指向我的帖子——感谢Rschen7754的推荐！如果我们获得“绿灯”，是否有更复杂的方法来移动页面，而不仅仅是简单的复制粘贴？--尼克 ^对话 2014年2月5日 (UTC) 00:16

可以导入整个页面历史，但这需要开发者和/或管理员的协助。--Rschen7754 2014年2月5日 (UTC) 00:38

那么，是直接复制内容，并在摘要中链接到WB上的剩余页面历史更可取吗？--尼克 ^对话 2014年2月5日 (UTC) 00:40

我认为导入可能仍然是更好的选择。最好看看en.wikibooks的结果，然后再做决定。--Rschen7754 2014年2月5日 (UTC) 02:59

管理员也可以使用Special:Import吗？- AdamBMorgan (对话) 2014年2月5日 (UTC) 19:33

从理论上讲，可以直接导入，但尚未定义上传源，因此该工具不起作用。--Rschen7754 2014年2月5日 (UTC) 19:59

向bugzilla提交请求应该能让它们被添加，如果这能在将来有所帮助的话；它只需要一个可接受的导入源列表。（如果这个提案通过，我建议将维基百科和维基教科书都包含在内，因为仅仅导入模板和模块可能很有用。）- AdamBMorgan (对话) 2014年2月6日 (UTC) 15:11

没错，不过我认为这可能需要当地的共识。--Rschen7754 2014年2月7日 (UTC) 07:11

我已提名这些页面被移动到此处。--尼克 ^对话 2014年2月5日 (UTC) 22:56

我完全单方面地认为这本书是维基教科书旅游分类中我们唯一不想要的——我说的对吗？它似乎不符合我们的职责范围；我认为它更适合现在的归属地。--尼克 ^对话 2014年2月6日 (UTC) 04:38

看来我们的请求可能很快就会获得共识，但是我们还没有决定每本书放在哪里。我建议b:Hiking_in_the_Canadian_Rockies和b:Teaching Assistant in France Survival Guide都可以作为独立的文章存在，而其余的则可能需要合并到现有文章中。尽管如此，所有提名的书籍都需要进行一些编辑，因为它们分成了几个页面。考虑到这一点，我很乐意将这些书籍首先移动到我的用户空间（这样可以方便任何移动页面的管理员），在那里它们可以被“旅行化”和/或将其内容分发到现有页面。为了归属目的，这些页面可以然后移动到Article name/Wikibooks。我很乐意自己承担大部分这项工作。这可以接受吗？--尼克 ^对话

导入请求已在此提交。 --Nick ^留言 2014年2月9日 (UTC) 22:51

导入提案

我提议将enwikipedia、meta和enwikibooks添加到Special:Import的导入源列表中。本节用于记录对此达成共识。

注意：这仅赋予我们进行导入的技术能力，即使我们很少使用此功能；它使我们能够在需要时再次使用此功能。 --Rschen7754 2014年2月9日 (UTC) 03:58

• 支持，作为提案人。 --Rschen7754 2014年2月9日 (UTC) 03:58
• 支持，因为我不知道为什么我们不应该最大限度地扩大我们未来的选择。 --118.93nzp (对话) 2014年2月9日 (UTC) 04:36

支持这个似乎是完美的直觉，但首先，我希望有人能解释这可能有什么不利之处，因为我没有看到不利之处。Ikan Kekek (对话) 2014年2月9日 (UTC) 07:33

支持 - 一个非常有用的工具，尤其是在处理上述问题时。 --Nick ^留言 2014年2月9日 (UTC) 14:33

我能想象到的唯一可能的缺点是过度热情的导入。不过，这很微不足道。Powers ^(对话) 2014年2月9日 (UTC) 16:29

顺便说一下，这是一个管理员工具——我本应该提到，这是我的错。 --Rschen7754 2014年2月9日 (UTC) 23:44

• 支持。如果没有危害，并且有明显的益处，那么就让我们实现它。 -- Ryan • (对话) • 2014年2月9日 (UTC) 18:31
• 请注意，导入已经完成，但这可能对未来有所帮助（尽管不是那么高的优先级）。 --Rschen7754 2014年2月9日 (UTC) 23:50

是的，我仍然很期待这件事发生！请随意编辑任何导入的文章

• User:Nicholasjf21/Guide_to_Electrical_Equipment_for_Travelers
• User:Nicholasjf21/Hiking_in_the_Canadian_Rockies
• User:Nicholasjf21/Colico
• User:Nicholasjf21/London
• User:Nicholasjf21/South_East_Queensland
• User:Nicholasjf21/Teaching_Assistant_in_France_Survival_Guide
• User:Nicholasjf21/Texas_State_Travel_Guide
• User:Nicholasjf21/Enjoy_Tokyo

--Nick ^留言 2014年2月10日 (UTC) 00:08

这现在是bugzilla:63095。 --Rschen7754 2014年3月26日 (UTC) 06:18

现在已在Special:Import上线。 --Rschen7754 2014年4月7日 (UTC) 23:19

调整 Special:附近

我们增加了维基导游“附近”功能的范围，使其更加有用。现在的范围是20公里。请务必查看Special:附近 ！欢迎提出反馈！Jdlrobson (对话) 2014年3月19日 (UTC) 00:45

我不知道有这项服务。旧的范围是多少？Ikan Kekek (对话) 2014年3月19日 (UTC) 01:05

我在special:preferences中启用了mw:Beta Features/Nearby Pages，它甚至没有机会在赫尔找到渥太华。同样的问题也出现在普雷斯科特-奥格登斯堡等双子定居点。讨论页上的一个注释表明它最近坏了，但它似乎从未正常工作。半径也会改变吗？K7L (对话) 2014年3月19日 (UTC) 01:38

是的，附近页面测试版功能目前已损坏，但将在周四修复，并应显示20公里范围内的位置。这是否足够（之前的范围是10公里）还有待观察。如果您认为范围需要进一步调整，请告诉我们。Jdlrobson (对话) 2014年3月19日 (UTC) 03:07

考虑到维基导游在这里计算的是城市/城镇文章，并且考虑到世界上大多数城市之间相距超过20公里，我不确定这个功能对我们是否会有很大的用处，除非将范围设置得更高，比如80或100公里。Texugo (对话) 2014年3月19日 (UTC) 11:11

也许“查找最近的五个点”比任意距离更有意义。纽约市半径100公里可能会返回威彻斯特、半个新泽西和部分康涅狄格州。沃特敦（纽约州）半径100公里会找到千岛湖，但会错过73英里外的锡拉丘兹（纽约州）。安蒂科斯蒂门尼尔港半径100公里可能除了静电什么也找不到，因为安蒂科斯蒂是175公里的省级公园。K7L (对话) 2014年3月19日 (UTC) 14:44

你说的对，在大多数情况下20公里太短了，但是被认为是“附近”的距离与你所在的地区非常相关。如果可行，将限制设定为最近的5-10篇文章而不是按距离设定是一个绝妙的主意！Texugo (对话) 2014年3月19日 (UTC) 14:52

User:Texugo，User:K7L，这似乎是个好主意。我已在我们的移动邮件列表上启动了此线程，看看我们能否进一步调整。 Jdlrobson (对话) 2014年3月20日 (UTC) 17:43

替代方案：动态地图

动态地图的“目的地”图层（按钮：目的地）根据语言版本显示所有文章150至1500公里范围内的文章。标记与文章链接（示例：en.WV 150km，ru.WV 1500km。 - Joachim Mey2008 (对话) 2014年3月21日 (UTC) 06:24

提议的相关站点外部链接和小的技术问题

添加OpenStreetMap 我想向社区提出三件事。第一件事最重要：我认为OpenStreetMap是一个足够好的资源，可以包含在侧边栏中。对于这个自由/开放内容社区来说，支持其他这样的社区也是值得的。wikivoyage-ev地图链接对我不起作用（目前在我父母家使用Firefox 28.x在Windows 8上），但我可以去OSM的网站查看。

作为小问题，我建议我们考虑将“开放目录项目”的引用重命名为“DMOZ”，参见en.wp上的此讨论。en.voy不一定总是要遵循en.wp的做法，但在姊妹项目之间保持一致是值得的。

最后，一个小小的技术说明：具有Wikitravel历史的页面在生成历史页面链接时存在一个小错误。请参阅https://wikivoyage.cn/wiki/Wikivoyage:Policies与https://wikivoyage.cn/wiki/Wikivoyage:Links_to_Open_Directory。后者有Wikitravel历史，页面底部有一个指向不存在的“https://wikivoyage.cn/wiki/Wikivoyage:Links_to_Open_Directory/w/index.php%3Ftitle%3DWikivoyage:Links_to_Open_Directory%26action%3Dhistory”的链接。实际存在的链接是“https://wikivoyage.cn/w/index.php?title=Wikivoyage:Links_to_Open_Directory&action=history”。我应该将其提交到bugzilla还是这里有人可以修复它？

感谢您的反馈。 —Justin (koavf)❤T☮C☺M☯ 2014年3月20日 (UTC) 23:18

看起来信用扩展已更改，现在使用MediaWiki:Creditssource-credits而不是MediaWiki:Creditssource-source-work，并且语法略有不同。我做了一些技术调整，使历史链接再次正确。在此声明，由于这是一个敏感的法律领域，我所做的更改仅限于恢复现有功能所必需的，并且完全没有触及内容。 -- Ryan • (对话) • 2014年3月20日 (UTC) 23:56

感谢Wrh2的小技术更新。

贾斯汀：你的将OpenStreetMap添加到侧边栏和更名为DMOZ的提议都明显有价值，贾斯汀和我都会支持它们。 --118.93nzp (对话) 2014年3月21日 (UTC) 03:42

我怀疑mw:Extension:RelatedSites将侧边栏链接硬编码到其中一个服务器配置文件中，因此需要打开一个bugzilla:项目来修复这些问题。K7L (对话) 2014年3月21日 (UTC) 04:02

Wikivoyage-ev 地图

引用User:Koavf：“wikivoyage-ev地图链接对我不起作用...” - Wikivoyage-ev地图直接链接到OpenStreetMap，但也显示Wikivoyage文章的所有标记。有什么问题吗？您是否使用了代理服务器，它伪装了您的网址（已知的阻止原因）？当您点击此链接时会发生什么？ -- Joachim Mey2008 (对话) 2014年3月21日 (UTC) 06:07

“连接超时。maps.wikivoyage-ev.org的服务器响应时间过长。”我收到所有wikivoyage-ev链接的消息已经几周了。如果我使用以tools.wmflabs.org/wikivoyage/w开头的URL，它就能正常工作。–Thatotherperson^对话贡献 2014年3月22日 (UTC) 06:27

我已将所有网络请求更改为“//tools.wmflabs.org/wikivoyage/w/”（示例）。希望问题已解决。 -- Joachim Mey2008 (对话) 2014年3月23日 (UTC) 04:34

@Mey2008: 顺便说一下，我正在使用另一台机器。 —Justin (koavf)❤T☮C☺M☯ 2014年3月23日 (UTC) 06:00

WV.ev 服务器存在问题，具体取决于浏览器设置。仅支持 http，不支持 https。工具服务器同时支持这两种协议。 -- Joachim Mey2008 (对话) 2014年3月23日 (UTC) 06:12

包含用户生成内容的旅游网站

目前在线上最受欢迎的3-5个专门提供用户生成信息和旅游目的地评论的旅游网站有哪些？（我特指像TripAdvisor.com这样的网站，它们包含有关景点和商家信息、评论和评分，可以帮助旅行者提前更好地评估某个区域/城镇/城市中最受欢迎和成功的当地景点、酒店、酒吧、餐厅等。）ויקיג'אנקי (对话) 2014年3月26日 (UTC) 17:53

我想到的是Yelp.com。还有Orbitz.com（仅限酒店）。ϒpsilon (对话) 2014年3月26日 (UTC) 18:10

据我所知，TripAdvisor和Wikitravel是前两名，尽管Yelp也可能位列其中；并非所有人都认为它是一个旅游网站，因为它的列表不限于旅行者设施，而且当地人似乎是主要用户。Powers ^(对话) 2014年3月26日 (UTC) 23:42

这是Alexa的列表 TripAdvisor遥遥领先于所有其他网站。Travel Doc James (对话 · 贡献 · 电邮) 2014年3月27日 (UTC) 15:11

旅行指南的子类别可能更有用：。Powers ^(对话) 2014年3月27日 (UTC) 23:14

IEG提案

大家好！首先，我为这么晚才提出这个方案道歉。我需要绝对确定我能投入时间。无论如何，我已经在m:Grants:IEG/Promoting Wikivoyage上提交了一个提案。这是为了向美国和州商会推广维基导游。希望这能在其他国家复制。如果您有任何问题或意见，请告诉我。谢谢！ --Tbennert (对话) 2014年3月26日 (UTC) 19:51

您可能需要查看旅游局探险和欢迎，旅游专业人士；当地CVB（会展旅游局）非常适合提供信息和纠正事实错误，因为它们代表每个目的地社区的“实地人员”，但同时，现有CVB材料的原始倾倒很容易将整个目的地页面变成宣传炒作的洪水。当然，维基导游已经确定需要鼓励CVB建设性地为项目做出贡献——从在场所关闭时删除列表到事实核查，再到在他们的相应目的地存在可用/指南文章时链接到我们——但我们的人员有限，无法推动这项倡议。*（在某些社区，CVB可能与商会是独立的实体。）K7L (对话) 2014年3月27日 (UTC) 02:41

我建议您用可衡量和可验证的目标来完善“成功衡量标准”这一段。不如添加：

• 与至少50个联系人建立对话，其中至少10个有非负面回复。通过抄送所有电子邮件或记录GoToMeeting会议来验证。
• 至少有5个联系人在维基导游上制作内容，其中至少2个有超过5次提交或超过1KB的添加文本。通过在上述电子邮件对话中建立用户名身份来验证。

祝你好运！即使资助不成功，这听起来也是一件非常有趣的事情 :-) 我会尝试联系我长大的目的地的CVB。Nicolas1981 (对话) 2014年3月27日 (UTC) 04:50

谢谢您的建议！这些都将很有用，并为我完善一些薄弱部分提供了一个起点。谢谢！ --Tbennert (对话) 2014年3月27日 (UTC) 21:26

也许更好的衡量标准是事实准确性，或者实际改进的目的地数量，从大纲到可用或指南？即使是所多玛与蛾摩拉也通过了一千字节的测试，尽管它包含足够的营销炒作和过时信息而毫无价值（除了作为不该做什么的假设示例）。相反，纠正文章中的错误信息和删除已关闭的场所不一定能延长像fr:Lac-Mégantic这样的文章的篇幅。梅甘蒂克湖的更新对旅行者来说很有用，可以确定去年夏天火车事故后什么仍然开放；一度，担心市中心被毁的游客取消了前往30-50公里外省立公园的旅行。质量，而不是数量...可以吗？

话虽如此，我们目前的覆盖范围在某些地方非常不均衡。纽约州对布法罗、罗切斯特和芬格湖（我们有当地用户投入了大量精力）有扎实的覆盖，对州中部（马塞纳红链，罗马已启动但未完成...）有可变的覆盖，然后在纽约市再次广泛。保持我们现有信息的最新也是一个巨大的问题。我们用户未曾访问过、没有当地人的地方的CVB可以通过建设性地贡献来填补一些空白，指出我们遗漏的关键目的地。K7L (对话) 2014年3月27日 (UTC) 13:00

感谢您的反馈。我希望这些鲜为人知的地方能从该计划中受益。我还没完全弄清楚具体的机制，但我希望能为那些红链或只有标题而没有内容的页面发送一封特别的电子邮件。

您对质量的担忧我理解。这些年来我清理了许多宣传页面。老实说，我认为大多数这些团体都会很乐意遵循给定的格式。谢谢！ --Tbennert (对话) 2014年3月27日 (UTC) 21:26

Category:包含黑名单链接的页面

我前几天创建了这个类别，因为我注意到某个东西，大概是mediawiki本身，正在填充它。然而，我没有完全理解发生了什么。例如

• 布拉格出现在列表中。我复制了文章的文本，并尝试将其放入我的用户空间中的新测试页面，显然触发过滤器的是文本“airport-shuttle(dot)com”。然而，a) 链接的完整文本是http://www.prague-airport-shuttle(dot)com，这显然是一个合法的链接，不应该仅凭其主要域名的一部分就触发垃圾邮件过滤器，而且 b) 文本“airport-shuttle(dot)com”甚至根本没有出现在Mediawiki:Spam-blacklist中，所以我不知道为什么它会触发过滤器
• 格伦峡谷国家休闲区确实包含一个列在Mediawiki:Spam-blacklist上的链接。根据我们的外部链接指南，它似乎是一个实际有效的列表，所以我将其从黑名单中删除，但该文章仍然出现在该类别中。

有没有人对它的工作原理有更多了解？Texugo (对话) 2014年3月28日 (UTC) 15:04

回答了上面第一点的一部分：“airport-shuttle(dot)com”列在元维基的黑名单中，但这仍然提出了一个问题，为什么它只通过部分匹配就触发了过滤器，以及我们能对此做些什么？Texugo (对话) 2014年3月28日 (UTC) 15:12

Wikivoyage:垃圾邮件过滤器的第一部分提供了有关所有黑名单和白名单如何协同工作的一些信息，但更新以使其更清晰可能很有用。至于机场穿梭链接，所有黑名单模式都是正则表达式，因此模式必须与文本中的某些内容匹配，即使它只是完整URL的一部分。如果我们需要覆盖Mediawiki黑名单条目，我们应该能够使用MediaWiki:垃圾邮件白名单来做到这一点。 -- Ryan • (对话) • 2014年3月28日 (UTC) 15:25

这个新功能是否只定期搜寻我们的文章？这就是为什么我无法将格伦峡谷国家休闲区从类别中移除，以及为什么该类别从我创建时的几个条目逐渐增加到现在的16个？Texugo (对话) 2014年3月28日 (UTC) 15:30

我不确定维护类别是如何生成的——我知道其中一些是间歇运行的批处理作业，但也许其他人可以提供一些见解。你尝试过重新编辑格伦峡谷国家休闲区文章，使其重新解析吗？另外，该文章中提及的URL来自一家大量发送垃圾信息的公司——请参阅MediaWiki talk:Spam-blacklist#invertsports dot com。—— Ryan • (讨论) • 2014年3月28日 16:09 (UTC)

我们还可以请求将该条目从全局黑名单中删除（可能性不大，因为它可能是由于特定垃圾信息事件而被添加的），或者将“好”链接添加到全局白名单中（可能性更大，但不确定，因为他们可能会质疑任何机场接驳车URL的适当性）。 Powers ^(讨论) 2014年3月28日 17:47 (UTC)

英语维基导游的维基统计数据

我正在发布二月份的维基统计报告。我注意到英语维基导游的一些数字明显低于以前。少量减少是正常的，因为维基统计数据总是从最新的转储文件从头开始重新生成所有数据，并且一些不好的文章可能已经从转储文件中删除。这次的差异相当大。请比较新报告和旧报告中第一个表格的A列和C列。两者在新版本中都显著下降。是否进行了重大清理？ Erik Zachte (讨论) 2014年3月30日 15:48 (UTC)

那些只有{{小城骨架}}和指向WT的署名链接（没有实际内容）的空文章已被删除，这并不影响将来为这些地方创建实际文章，目的是为了SEO目的而去除WT署名。这实际上是一次性操作，因为将来没有计划从其他旅行维基导入空骨架。请参阅Wikivoyage talk:Deletion policy#Summary K7L (讨论) 2014年3月30日 16:05 (UTC)

啊，谢谢 Erik Zachte (讨论) 2014年3月30日 16:10 (UTC)

默认站点排版即将更改

本周，维基媒体网站的排版将对所有使用默认“Vector”皮肤的读者和编辑进行更新。此更改将涉及一些标题使用新的衬线字体，正文内容字体、文本大小、文本颜色和元素间距的细微调整。具体时间安排如下：

• 4月1日：非维基百科项目将上线此更改
• 4月3日：维基百科项目将上线此更改

此更改与自2013年11月以来在维基媒体项目上提供的“排版更新”Beta功能非常相似。经过多轮测试和社区反馈，此Beta功能将被禁用，其成功之处将在默认站点外观中启用。已登录的用户仍可选择使用其他皮肤，或修改其个人CSS，如果他们喜欢不同的外观。本地公共CSS样式也将正常应用，以解决影响所有用户的本地样式和脚本问题。

更多信息

• 更改摘要和常见问题解答
• 讨论页，用于反馈或提问
• 博客文章，网址为blog.wikimedia.org

-- 维基媒体基金会用户体验设计团队的产品经理Steven Walling

纽约公共图书馆地图

纽约公共图书馆刚刚发布了其知识共享许可下的地图收藏。由于我们的中大西洋州文章有很多编辑，看看其中一些图片是否可以用于历史背景可能会很有趣。 Andrewssi2 (讨论) 2014年4月1日 03:16 (UTC)

标题字体更改？

标题字体更改？

标题字体更改？

是不是只有我这样，还是我们标题的字体变成了更像Times New Roman的东西？ Texugo (讨论) 2014年4月1日 18:57 (UTC)

请参阅#默认站点排版即将更改。—— Ryan • (讨论) • 2014年4月1日 19:15 (UTC)

哦，我错过了。我不得不说，到目前为止我并不喜欢。 Texugo (讨论) 2014年4月1日 19:23 (UTC)

我想这只是需要适应，正文也略有不同（每行大约减少10-14个字符，因此换行次数更多）。 Matroc (讨论) 2014年4月2日 05:48 (UTC)

如果你愿意，可以通过在Mediawiki:Common.css中添加一些css代码来改回来。—— WOSlinker (讨论) 2014年4月2日 09:01 (UTC)

我已在Mediawiki上提出了关于个人CSS更改的问题。希望在字体更改在维基百科上推出之前能得到答复。 Nurg (讨论) 2014年4月2日 09:22 (UTC)

字体大小的差异我或许能习惯（尽管我更希望它被恢复），但我认为将正文用典型的无衬线字体，而标题用明显更正式的衬线字体，看起来荒谬地业余。这是一种非常糟糕的审美选择，完全与标准排版常识相悖，使我们的内容看起来像博客。当我看到上面帖子中，“纽约公共图书馆”出现在标题中，后面紧跟着正文第一行使用不同字体的相同文本时，这只会凸显两种字体之间存在多么刺耳的对比。我完全不认为这种改变能带来任何必要的提高可读性，我绝对支持将标题字体改回与正文匹配。这太丑了，以至于有人在meta上甚至建议这可能是一个愚人节玩笑。 Texugo (讨论) 2014年4月2日 11:19 (UTC)

天哪，不仅如此，现在我注意到页面标题 (H1) 和 H2 标题以新的衬线字体显示，而所有的 H3 和 H4 标题（我们有很多）仍然以普通的无衬线字体显示，就像正文一样，所以现在我们还有混合的标题字体（请参阅我上面添加的示例副标题）。这整个事情太糟糕了，考虑得非常不周。 Texugo (讨论) 2014年4月2日 11:57 (UTC)

我已对MediaWiki:Vector.css做了一个小改动。告诉我它是否修复了标题。—— WOSlinker (讨论) 2014年4月2日 12:18 (UTC)

它确实修复了标题。我希望没有人反对。现在我们需要讨论是否要接受这种字体大小的更改强加给我们。 Texugo (讨论) 2014年4月2日 12:37 (UTC)

标题的新字体对我来说并没有造成太大的困扰。但老实说，超大字体看起来很碍眼。一开始我还以为我的浏览器出了问题…… ϒpsilon (讨论) 2014年4月2日 13:50 (UTC)

字体更改似乎也影响了列表标记的显示方式1 , 2 , 3 , 4 ,5 。现在数字显示在框的底部边缘附近，而以前则更居中。 Texugo (讨论) 2014年4月2日 18:22 (UTC)

哎呀。我们的希腊同事会怎么看Y字（Ypsilon）看起来像一个手摇水泵？ :/ ϒpsilon (讨论) 2014年4月2日 19:37 (UTC)

仅供记录，我同意上述观点——我不是这些改动的粉丝。——Nick ^讨论 2014年4月5日 19:24 (UTC)

我建议通过将此补丁添加到Mediawiki:Vector.css来恢复所有更改。新样式简直糟糕透顶。我不知道是谁提议的，但我很想把这个人从维基媒体社区中清除出去。——Alexander (讨论) 2014年4月2日 22:41 (UTC)

我们可能要等一周左右，看看核心软件是否会应用任何修复程序，然后再添加太多本地变通方案，否则这些方案之后需要回滚——关于此更改似乎有足够的担忧，我预计会大力解决所有项目的这些问题。—— Ryan • (讨论) • 2014年4月2日 23:00 (UTC)

我鼓励大家在mw:Talk:Typography_refresh#serif_vs_sans_serif或其他页面上的相关讨论中加入你们的声音。 Texugo (讨论) 2014年4月3日 11:49 (UTC)

我已恢复Vector.css的更改。在新功能稳定下来之前，我们必须给它一些时间，而不是立刻动手修改。 Powers ^(讨论) 2014年4月3日 14:49 (UTC)

对于那些对选择衬线字体感兴趣的人，这里有一些原因。基本上，衬线字体在屏幕上小字体大小下效果不佳，因此正文文本使用无衬线字体……从而导致标题文本使用衬线字体以形成对比。通常用于正文文本的衬线字体的排版标准不适用，因为电脑屏幕与印刷文本不同。 Powers ^(讨论) 2014年4月3日 14:56 (UTC)

这并不能解释我的疑问。谁决定仅仅是标题不同大小、加粗和下方有分隔线还不够，还需要这种强烈的对比，以至于不惜牺牲我们的审美和谐来获得它？我认为这是在修复一个从未坏掉的东西，结果是标题现在过于突出，以一种不理想的方式，就像眼中钉。 Texugo (讨论) 2014年4月3日 15:00 (UTC)

我同意 Powers 的看法，我们现在不应该全面恢复这些更改。如果有人不喜欢这些更改的某些方面，并且不想尝试适应它们，你可以前往个人偏好设置并更改你的自定义 Vector CSS。例如，要恢复正文文本大小：

#bodyContent {
	font-size: 0.8em !important;
}

Nurg (讨论) 2014年4月3日 23:18 (UTC)

我没看到有人在这个网站上呼吁这些改变。不如在这个网站上恢复原状，不管其他Mediawiki网站看起来怎么样？ Ikan Kekek (讨论) 2014年4月3日 23:44 (UTC)

抱歉回复晚了，我有很多村庄酒吧需要查看。首先，感谢所有可能试用过Beta功能和/或在过去五个月中给我们反馈的维基导游用户。关于本地覆盖：我同意Nurg和Powers的观点。设计更改总是需要时间来适应。由于我们花费了大量时间进行测试，收集了维基媒体社区所有编辑的反馈，并进行了迭代，我唯一的请求是，在进行任何全站范围的更改之前，让维基导游作为一个整体尝试一下默认设置。如果个人不喜欢这些更改，当然可以选择退出。如果您有任何其他问题，例如我们为什么选择衬线标题等，请告诉我。 Steven (WMF) (讨论) 2014年4月4日 00:15 (UTC)

谢谢光临，史蒂文。我不记得在这次更改发生之前看到过关于这项拟议更改的公告。我请求未来，当考虑对本网站产生影响的维基媒体范围内的重大更改时，请有人在讨论进行期间来旅行者酒吧通知我们。这种情况曾发生过几次，但这次我认为没有。另一个选择是更改其他维基而不是这个，如果可行的话。 Ikan Kekek (讨论) 2014年4月4日 00:23 (UTC)

或者，人们可以积极主动地关注这类事情……通过注册m:Global message delivery/Targets/Tech ambassadors。简单来说，维基媒体有超过750个维基，WMF员工不可能访问每一个维基。——Rschen7754 2014年4月4日 04:02 (UTC)

我完全同意User:Texugo的观点，"正文使用典型的无衬线字体，而标题使用明显更正式的衬线字体，看起来荒谬地业余。这是一种非常糟糕的审美选择，完全与标准排版常识相悖"。这种改变在我看来显然是荒谬的。 Pashley (讨论) 2014年4月4日 00:31 (UTC)

新设计应该是一个可选功能，旧设计应该作为默认使用，直到所有格式问题都解决。你建议的“选择退出”选项并没有将行间距恢复正常。请提供一个CSS文件，它能移除与3月31日相比的所有更改。然后我们可以讨论新风格的哪些功能有意义，但到目前为止，这种新风格只是对社区的纯粹无知。——Alexander (讨论) 2014年4月4日 07:24 (UTC)

标题字体，至少，我甚至不愿意尝试“适应”，用我的个人CSS来隐藏它也不是办法——我很尴尬，因为我们现在就是这样向世界展示我们的指南的，我希望它恢复原状。整个这项举措正在搞砸一些原本没有问题的东西，而且事先没有社区共识认为有这个必要。我完全支持将一切恢复到3月31日的样子，直到/除非有任何本地共识进行更改。 Texugo (讨论) 2014年4月4日 11:14 (UTC)

虽然我同意排版更新存在一些问题，但我认为一些评论说这是在没有通知的情况下实施的说法是不妥的。在每个页面上，每个人账户偏好旁边的“beta”链接已经提供了排版更新数月，并且已经有一些自动的酒吧通知提醒大家这项更改即将到来。正如User:Rschen7754所指出的，不可能与数百个维基单独互动，因此至少部分取决于我们来跟踪全球更改并在其宣布之前进行权衡。

至于现在恢复更改，我强烈建议我们至少等待一段时间，待主要问题得到解决后再尝试“修复”感知到的不足之处，因为每次我们创建维基导游特有的自定义都会增加一个可能与未来升级发生不良互动的问题，需要我们额外的工作或导致我们错过新功能。—— Ryan • (讨论) • 2014年4月4日 15:30 (UTC)

我感觉就像亚瑟·丹特被告知他的房子将被拆除，因为拆除命令已经在他家地下室一个被遗忘的角落里公开存档了几个月。这种重大改变没有明确地引起我们的注意，这简直是荒谬的。 Texugo (讨论) 2014年4月4日 15:46 (UTC)

2013年11月首次请求对排版功能提供反馈：Wikivoyage:Travellers' pub/2013 (additional)#Introducting Beta Features，并在邮件列表和meta上进一步讨论。我同意在3月底之前再次通知排版更改会更好，但要求本地参与将使全球更改变得不可能，因为这样做将需要在700个不同的维基上进行单独讨论。

展望未来，如果人们启用“beta”功能以在这些类型的更改正在测试时获得提前通知，那么一旦提议将其纳入，您将自动看到它们，从而有机会提供即时反馈，这可能会很好。如果需要，我们可能还会设置一个页面，其中包含指向人们应监控的位置的指针，以跟踪全球更改——这会有用吗？—— Ryan • (讨论) • 2014年4月4日 16:24 (UTC)

跟踪所有维基媒体项目的所有技术发展不是我们的工作。开发人员（顺便说一句，其中一些人是有偿的）的工作是确保他们的开发是合理的，并且不会破坏现有内容。排版如果是一个选项，那将是一个完美的附加功能，但未经请求更改所有维基的默认外观非常令人恼火。——Alexander (讨论) 2014年4月4日 20:57 (UTC)

另请参阅w:Wikipedia:Village pump (technical)#Font size and style，了解维基百科上的排版更改讨论。—— Ryan • (讨论) • 2014年4月4日 16:54 (UTC)

我确实在11月酒吧发布时开启了beta功能（当我看到排版对标题做了什么之后，我立刻又关掉了），但当时并没有迹象表明它们不是作为选项提供的开发中的功能，而这实际上是一套影响我们所有页面的全局默认设置的根本性更改。维基百科的许多人似乎也有同感。 Texugo (讨论) 2014年4月4日 17:27 (UTC)

我不知道有任何Beta功能只作为未来的选项考虑；如果它们是可选的，它们就不需要通过Beta测试系统。（Beta测试系统的全部意义在于人们可以轻松地打开和关闭它；如果一个功能将是偏好设置中的一个选项，那么它已经可以轻松地打开和关闭了。）

我确实对新设计的一些细节有些意见，但它肯定还没有糟糕到需要采取完全将我们的设计与其他维基脱钩的极端措施。我有点担心（如果Steven还在阅读的话），排版是考虑到维基百科的政策和风格（中立性、正式性、可靠性）而选择的，而不是考虑到其他项目有不同的需求。Powers ^(讨论) 2014年4月4日 18:17 (UTC)

我不知道为什么保持我们的设计与其他维基保持一致会成为一个问题。我们已经偏离了这条道路，例如使用了横幅和水平目录等，因此我们的主空间文章标题的字体已经不受这些更改的影响。（而且请务必不要建议用衬线字体破坏我们的文章标题！）无论如何，我们也不会是唯一的，因为维基百科的各个版本已经恢复了。 Texugo (讨论) 2014年4月4日 18:41 (UTC)

共识是本维基的核心政策之一。对字体和其他样式问题没有共识。因此，所有这些更改都必须恢复并进行讨论。——Alexander (讨论) 2014年4月4日 20:57 (UTC)

这是WMF所为，是一个技术决定，超出了本维基共识的范围。——Rschen7754 2014年4月4日 21:16 (UTC)

他们正在违反自己的政策，这是他们的问题，但我看不出维基导游为什么要支持这一点。——Alexander (讨论) 2014年4月4日 21:31 (UTC)

他们没有。这种夸张的说法对你的情况毫无帮助。如果我们想偏离默认排版，那才需要共识。 Powers ^(讨论) 2014年4月4日 23:14 (UTC)

什么样的政策能为这种既未充分宣布也未妥善讨论（例如通过RFC）的单方面全站更改辩护？——Alexander (讨论) 2014年4月5日 21:14 (UTC)

“维基媒体基金会管理服务器，他们可以做任何他们想做的事情”的政策。——Rschen7754 2014年4月5日 23:14 (UTC)

更不用说它已经得到了充分的通知和妥善的讨论。 Powers ^(讨论) 2014年4月6日 01:00 (UTC)

这证实了我的声明，即这项更改违反了现有政策，且未获得社区支持。 --Alexander (讨论) 2014年4月6日 (UTC) 06:25

是这样吗？怎么会？ Powers ^(讨论) 2014年4月7日 (UTC) 00:14

如果“维基媒体基金会运营服务器，可以随心所欲”是官方政策，那就太搞笑了。我很想去元维基问问这项政策是何时以及如何批准的。 --Alexander (讨论) 2014年4月7日 (UTC) 06:03

据我所知，任何维基上都没有关于Mediawiki软件默认外观的社区政策。这根本不是政策变更。 Powers ^(讨论) 2014年4月7日 (UTC) 19:51

您是如何从所有文章中隐藏页面标题的？

我们希伯来语维基导游之前已经将横幅添加到所有文章中，但尚未从文章顶部隐藏所有页面标题。从技术上讲，这具体是如何实现的？（我尝试通过更改vector.css和common.css来做到这一点，但似乎应该用不同的方法。） 维基垃圾 (讨论) 2014年4月2日 (UTC) 14:01

我们不得不使用Javascript来完成，虽然不优雅，但由于技术限制，似乎是唯一的选择。请参阅MediaWiki:Common.js，特别是

$(".topbanner").closest(".mw-body").children(".firstHeading").hide();

-- Ryan • (讨论) • 2014年4月2日 (UTC) 15:06

我将这段代码添加到了希伯来语维基导游，现在它确实隐藏了所有文章的页面标题，但对我来说，这个过程在希伯来语维基导游中似乎稍长一些——也就是说，在每个文章的顶部，您可以看到页面标题大约1.5秒，然后它才完全隐藏——而在英语维基导游的文章中，对我来说，页面标题似乎会立即隐藏。（您可以在希伯来语维基导游中巴黎的文章中亲自查看这种延迟的例子）有什么建议可以减少这种延迟吗？ 维基垃圾 (讨论) 2014年4月2日 (UTC) 16:33

尝试将新代码移动到MediaWiki:Common.js的顶部——如果运行速度更快，则意味着您的Javascript中存在其他代码运行缓慢，导致其后的所有代码在页面加载过程中运行较晚。如果您能找出哪些代码运行缓慢，可以通过将其包围在以下代码中来延迟慢速代码的执行：

$(document).ready(function(e) {
    // put slow code here
});

如果问题不是由于其他代码运行缓慢造成的，则需要进一步调试。 -- Ryan • (讨论) • 2014年4月2日 (UTC) 16:43

再想一想，现在看来，这个问题实际上在希伯来语维基导游和英语维基导游都存在（隐藏英语维基导游的巴黎文章的页面标题所花费的时间与希伯来语维基导游的巴黎文章所花费的时间大致相同）。现在看来，这个问题是由服务器在隐藏页面标题之前实际上首先加载横幅的全景图像造成的——因此，在加载尺寸和细节较大的图像时，服务器需要额外花费一秒或1.5秒来加载图像，然后才开始隐藏文章顶部的页面标题。理想情况下，为了解决这个问题，我们需要让服务器首先隐藏文章顶部的页面标题，然后再加载横幅的全景图像。有什么办法可以实现这一点吗？（我尝试将新代码移动到MediaWiki:Common.js的顶部，但没有任何改变，可能是因为全景图像加载的顺序是在其他地方定义的。） 维基垃圾 (讨论) 2014年4月2日 (UTC) 18:00

仅是来自很久以前的一些旧维基零碎信息（可能适用，也可能不适用）： Matroc (讨论) 2014年4月3日 (UTC) 00:07

1. 要隐藏单个页面上的文章标题，可以使用模板：

{{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}}

1. 要隐藏所有文章标题，我编辑了Common.css（很多年前在一个个人维基上）：

body.page-No_page_title h1.firstHeading { display:none; }

当然，MediaWiki代码已经发生了很多变化，上述方法可能无法正常工作。 —以上评论由Matroc（讨论 · 贡献）添加

不幸的是，DISPLAYTITLE不能再用于隐藏页面标题——请参阅Wikivoyage talk:Banner Expedition/archive#Not inhibiting title。 -- Ryan • (讨论) • 2014年4月3日 (UTC) 01:14

移民数据

该网站面向所有旅行者，因此应该包括移民，当然，游客是最重要的服务群体，商务旅行者可能位居第二。

这里有一张有趣的图表，世界各地人口迁移图。 Pashley (讨论) 2014年4月3日 (UTC) 14:05

Stack Exchange有一个新的外籍人士问答网站（与他们的旅行问答网站不同） Andrewssi2 (讨论) 2014年4月4日 (UTC) 04:34

工具菜单中的格式错误项

从酒馆扫来

看起来左侧栏的“工具”菜单出了问题。&lt;wikibase-dataitem&gt; Nurg (讨论) 2014年4月10日 (UTC) 10:39

在其他语言链接的底部也有。 Nurg (讨论) 2014年4月10日 (UTC) 10:40

维基数据似乎出了大问题—所有编辑/添加/保存/取消按钮都坏了。例如，查看wikidata:Q16503。 Texugo (讨论) 2014年4月10日 (UTC) 11:18

好的，他们现在已经修复了。Wikidata:Project chat#所有标签都坏了。 Nurg (讨论) 2014年4月10日 (UTC) 20:05

管理员编辑请求

从酒馆扫来

侧边栏更改根据bugzilla:64027。谢谢。 —Justin (koavf)❤T☮C☺M☯ 2014年4月22日 (UTC) 03:52

我看了那个bug，我不确定我们要改什么。 Powers ^(讨论) 2014年4月22日 (UTC) 13:47

这个bug似乎是请求更改服务器上的配置文件。那需要维基媒体基金会的系统管理员来做。 K7L (讨论) 2014年4月22日 (UTC) 14:15

Bug 将侧边栏中的“开放目录”更改为“DMOZ”。 —Justin (koavf)❤T☮C☺M☯ 2014年4月27日 (UTC) 18:20

是的，那是bug的标题。问题是，作为管理员，我们应该更改什么？正如K7L所指出的，这看起来像是一个配置文件更改，据我所知，管理员无权访问。 Powers ^(讨论) 2014年4月28日 (UTC) 18:47

抱歉 我误读了Bugzilla。真尴尬。我道歉。请随意将其从酒馆中清除。 —Justin (koavf)❤T☮C☺M☯ 2014年5月1日 (UTC) 04:10

世界上最危险的城市？

这个列表准确或有用吗？你觉得呢？ Ikan Kekek (讨论) 2014年4月10日 (UTC) 09:41

它似乎没有任何事实依据。在墨西哥、巴基斯坦和也门等地采取预防措施总是好的，但我怀疑这是否是针对具体城市的。 Andrewssi2 (讨论) 2014年4月10日 (UTC) 12:32

值得检查w:List of cities by murder rate中排名前列的城市是否在此处有警告。

我们在国外养老#信息来源的“统计数据和指数”部分提供了几个危险级别指数的链接。 Pashley (讨论) 2014年4月10日 (UTC) 12:51

还值得注意的是，采取预防措施的游客和必须住在城市的居民所经历的危险可能会显著不同。 Andrewssi2 (讨论) 2014年4月10日 (UTC) 12:59

同意Andrewssi2的观点。我不太相信那篇文章，因为我很确定：将“巴西人口最稠密的地区不是你想去的地方”这种概括性说法，是公然的危言耸听和极度夸大。 Texugo (讨论) 2014年4月10日 (UTC) 13:22

令人惊讶的是，喀布尔、巴格达、格罗兹尼和大马士革不在名单上。然而，名单上的城市及其所在的地区也并非以安全著称。 ϒpsilon (讨论) 2014年4月10日 (UTC) 20:03

我住在世界上最危险的特大城市，但幸运的是从未觉得这里不安全，所以是的，居民和游客的安全顾虑确实不同。 --Saqib (讨论) 2014年4月10日 (UTC) 20:21

一个更具说服力的排名或许不会计算那些受害者是袭击者熟人的案件。 Texugo (讨论) 2014年4月10日 (UTC) 20:55

刚刚，联合国发布了官方数据：https://www.unodc.org/gsh/en/data.html

《经济学人》的一些分析：http://www.economist.com/news/international/21600713-un-offers-some-hints-how-avoid-being-bumped-dicing-death

Andrewssi2 (讨论) 2014年4月11日 (UTC) 07:29

正式请求：将侧边栏中的“开放目录”重命名为“DMOZ”

请发起意见征集 我正在为我在之前的一篇帖子中简要提及的一个问题发起一个正式的意见征集。开放目录项目已正式将其自身品牌化为“DMOZ”（这是一个它一直使用的名称，并且更受欢迎）。我已在英语维基百科、维基数据和维基共享资源上提出了类似的更改请求。无论好坏，英语是维基媒体基金会项目的主导语言，维基百科是主导项目，所以我从那里开始，以期在各个项目和语言之间实现该网站品牌的一致性。这对我来说似乎没有什么争议，其他人也表示支持。社区怎么看？ —Justin (koavf)❤T☮C☺M☯ 2014年4月11日 (UTC) 00:22

我们应该链接到开放目录项目吗？在那里添加或更新列表似乎几乎不可能。 K7L (讨论) 2014年4月11日 (UTC) 01:27

@K7L: 为什么不呢？即使在那里获取列表不容易，DMOZ对读者来说也是一个很好的资源。在某些时候，人们可能想要比旅行指南提供更多的信息，那么我们应该把他们引导到哪里（如果有的话）？ —Justin (koavf)❤T☮C☺M☯ 2014年4月12日 (UTC) 05:51

很久以前和DMOZ的一位创始人谈过。他表示这个项目基本已经死了，维基百科不应该链接到它。我不太喜欢文章中长长的外部链接列表，而且它比其他任何东西都好。我想问题是维基媒体基金会是否应该启动一个？对于DMOZ这个词没有强烈的感觉。 旅行医生詹姆斯 (讨论 · 贡献 · 电子邮件) 2014年4月12日 (UTC) 17:27

如果保留链接，按照建议重命名似乎是明智之举。 Nurg (讨论) 2014年4月19日 (UTC) 05:06

我支持删除DMOZ的链接。它的管理很差，而且正在消亡。 —Tom Morris (讨论) 2014年6月2日 (UTC) 14:10

如果我们保留它，我更倾向于使用“开放目录”或其他有意义的短语，而不是“DMOZ”，无论他们自己怎么称呼。我希望一个不熟悉的用户（比如我）一眼就能明白它是什么。

从上面的评论来看，我们似乎应该直接删除它。有没有人有更清晰或更近期的信息来支持或反驳这一点？ Pashley (讨论) 2014年6月2日 (UTC) 16:48

本周媒体查看器

大家好，

在此提醒，本周四（4月17日）将默认对所有已登录用户在英语维基导游启用媒体查看器。您的偏好设置中将提供禁用媒体查看器的选项。如果您想现在尝试媒体查看器，可以在您的Beta功能中启用，或在mediawiki.org上的演示页面上使用。如有任何疑问，请联系我。 Keegan (WMF) (讨论) 2014年4月14日 (UTC) 16:27

维基导游对此应该做些什么，如果有的话？虽然我无法想到任何地方它们是必不可少的，但想到各种媒体文件能作为我们指南的有趣或有用的补充并不困难。同样，也不难看出可能存在各种问题，尽管我看不到任何看似无法克服的问题。

之前的讨论拒绝了链接到媒体文件的想法。我赞成允许一些链接。规则一应该是只链接到维基共享资源上的文件；不允许本地上传，也不允许外部链接到媒体文件。除此之外，我不太确定。还有其他意见吗？ Pashley (讨论) 2014年4月14日 (UTC) 20:19

你似乎将其解释为专门指非图像媒体文件，但它也改变了点击图像时的显示方式。我认为这不一定对我们关于非图像媒体文件的政策有任何影响。它只是一个可视化功能。 Texugo (讨论) 2014年4月14日 (UTC) 20:26

维基数据中的姊妹项目链接？

根据mw:Extension:Wikibase Client#其他项目侧边栏，维基媒体正在开发维基数据扩展，以使其能够生成姊妹项目链接，其方式与维基数据当前在项目内生成跨语言链接的方式大致相同。这些链接将出现在MediaWiki:侧边栏的MediaWiki:wikibase-otherprojects部分。

例如，wikidata:Q2078515链接到s:fr:Appel du 18 juin以及同一主题的法语维基百科文章。维基数据扩展会自动将“Autres projets - Wikipedia”放入维基文库页面的侧边栏，而无需向该页面的维基文本添加任何代码。与我们当前的扩展mw:extension:RelatedSites的“笨办法”形成对比，该扩展会将每个零散的[[wikipedia: 或 [[commons: 链接移动到侧边栏（通常是无意中），就像它是一种语言一样，而其余的姊妹项目则没有侧边栏链接。

问题在于？这仍然局限于每个项目从任何页面链接一个，并且确实需要在服务器配置文件中添加一行：

$wgWBSettings['otherProjectsLinks'] => array( 'enwiki', 'enwikinews', 'enwikiquote', 'commonswiki' );

在m:Requests for comment/Interproject links interface上有一些讨论，但我认为，如果我们想使用它，我们应该确定要显示哪些维基，以便可以打开一个bugzilla:工单。我建议：

• 所有维基导游语言版本（已存在）
• 所有英文维基媒体姊妹项目版本（维基百科、维基新闻等）
• 维基共享资源、元维基、mw
• 英文DMOZ（如果可用）。

评论？ K7L (讨论) 2014年4月16日 (UTC) 16:24

维基数据上似乎有一个相关的对话：Wikidata:Wikidata:Project chat#由Wikidata驱动的项目之间侧边栏链接现在可能 - AdamBMorgan (讨论) 2014年4月16日 (UTC) 16:56

嗯，一些语言版本已经从维基数据获取维基百科和维基共享资源的链接，尽管这些链接的显示仍然通过扩展:相关站点进行界面交互。当然，摆脱这个扩展会很棒。然而，重要的是维基共享资源的链接要设置为分类而不是页面。否则，许多有用的链接将会丢失。 --Alexander (讨论) 2014年4月16日 (UTC) 17:10

我认为我们应该慷慨地包含许多链接。例如，拥有维基共享资源链接和维基百科的各种链接是很棒的。此外，这样做可能会增加这些网站未来链接到我们的可能性。 Nicolas1981 (讨论) 2014年4月17日 (UTC) 10:18

说到DMOZ，我整理了一份大多数维基导游页面与其对应的DMOZ网址的映射，这可能会有所帮助。 Unknown (讨论) 2014年4月26日 (UTC) 07:07

@未知用户：有意思！在线提供吗？我猜是从维基导游转储中提取的？ Nicolas1981 (讨论) 2014年4月28日 (UTC) 06:17

是的，我已在此处提供。它映射了转储中27187/47623个维基导游页面，精确度各不相同。当然，通过一些手动检查可以改进，因为这是用一个相当简单的算法完成的。 Unknown (讨论) 2014年4月28日 (UTC) 17:34

是只有我这样，还是...

...最近非经常贡献者的活动有所增加？我一如既往地希望维基导游能获得发展势头。 -- AndreCarrotflower (讨论) 2014年4月23日 (UTC) 04:14

可能是吧，我不能否认。 Powers ^(讨论) 2014年4月23日 (UTC) 13:25

我也注意到了——维基导游的情况开始好转了吗？有人有可靠的网站浏览量统计数据吗？ --尼克 ^讨论 2014年4月23日 (UTC) 18:07

前几天，我很高兴地欢迎了一位2003年首次编辑并曾担任管理员的用户来到WV。很酷，对吧？ :) ϒpsilon (讨论) 2014年4月23日 (UTC) 18:18

那真是太棒了！我们需要更多这样的人！也许也值得考虑如何留住一些编辑者，让他们更深入地参与进来。 --尼克 ^讨论 2014年4月23日 (UTC) 18:28

如果你想知道如何让他们更投入，在他们的讨论页上留下一条简单的信息会是一个很好的开始。给他们一些额外的维基爱心，并感谢他们的贡献！新用户喜欢看到经验丰富的用户的热情和鼓励。 Edge3 (讨论) 2014年4月25日 (UTC) 02:18

致Edge3: 参阅 User talk:007contributor。 -- AndreCarrotflower (讨论) 2014年4月25日 (UTC) 03:18

太棒了！为了避免误解，我并不是说维基导游的用户不善于欢迎新用户。我只是提出了一个简单的建议，以防有人需要。  :) Edge3 (讨论) 2014年4月25日 (UTC) 03:44

维基导游离线

大家好，

我刚刚将维基导游转换成几种格式：

• OxygenGuide，离线维基导游，只是一个HTML文件集合，经过优化以便在移动设备上轻松查看。
• OBF格式的列表，可直接导入Android离线GPS/导航应用OsmAnd。
• OSM格式的列表，可导入您的OpenStreetMap服务器。
• CSV格式的列表，用于混搭、数据重用、错误发现，或只是为了探索数据而获得乐趣。

如果大家足够感兴趣，我会在Labs上设置我的脚本，这样这些4个文件每两周会自动刷新。祝好！ Nicolas1981 (讨论) 2014年4月24日 (UTC) 02:23

我认为这是绝对必要的事情，但下一步将是与OsmAnd开发人员进行某种形式的沟通。我尝试将你早期的OBF文件之一导入我的OsmAnd安装，并意识到兴趣点（POI）只是与Osm中已有的数千个POI合并。然后就无法使用或至少突出显示维基导游特有的POI。对此有什么想法吗？

您可能也有兴趣将 Wikivoyage 与 MapsWithMe 进行接口，后者是 OsmAnd 的替代品。--Alexander (talk) 2014年4月24日 (UTC) 05:22

大约有80个左右的条目带有嵌入式制表符，在大多数情况下，用户可能尝试做了一些格式化（在将文件转换为制表符分隔文件时发现）...例如：曼彻斯特/市中心 - 三一啤酒厂...我正在测试一些想法，并将分享我发现的其他任何东西 - Matroc (talk) 2014年4月24日 (UTC) 05:54

我已从文章中删除了制表符，所以下次生成列表文件时，它将正常。-- WOSlinker (talk) 2014年4月24日 (UTC) 07:19

谢谢 - 我还修复了一些包含 \\ 或 , 作为数据的文章。Matroc (talk) 2014年4月24日 (UTC) 07:30

我相信我可能发现了一个小的转换问题 -- 文章中发现的 不间断空格 的正确 HTML 代码在 .csv 文件中被转换为 & 符号 后跟 nbsp; 的 HTML 代码 -- (1070 次) - 例如，参见阿劳（Aarau），在阿劳西（Aarau-West）的睡眠条目下。（希望我没有错，也没有产生幻觉！）Matroc (talk) 2014年4月25日 (UTC) 04:25 ... 对于 ndash 也是如此。

你好 Matroc！不确定是否理解这个问题，你能不能把维基中、CSV 中以及 CSV 中应该出现的内容复制粘贴到这里？非常感谢！顺便说一句，生成 CSV 的代码 对 & 符号等没有做任何特殊处理。Nicolas1981 (talk) 2014年4月27日 (UTC) 13:58

嗨 Nicolas - 为了避免在旅行者酒吧中填满我的废话 - 我在我的讨论页上创建了一个部分，用于进一步的讨论。Matroc (talk) 2014年4月28日 (UTC) 03:57

死链接

大家好，维基人。我浏览了一下你们的页面，发现有很多死链接。社区对此的普遍看法是什么？我是从 DMOZ 编辑的角度来看待这个问题的，在那里非常强调删除不functioning的链接，但也许在这里这不是一个大问题——我能理解某个餐厅或民宿可能不再有网站，但仍然是一个正常的业务，也许你们更倾向于提供最大量的信息，然后用户应该验证。如果不是这样，有没有兴趣创建一个机器人来维护这些链接？Unknown (talk) 2014年4月26日 (UTC) 07:01

通常，死链接只意味着网页结构发生了变化，或者它已经移动到另一个域（例如，他们有了自己的适当网页，而不是许多 ISP 免费提供的有时带广告的小空间）。如果我遇到死链接，我通常会通过谷歌搜索该机构，看看它是否仍然存在。ϒpsilon (talk) 2014年4月26日 (UTC) 08:31

拥有更好的链接将提高网站的搜索引擎排名。但我认为这应该手动纠正。是否有可能创建一个包含损坏的外部链接的页面类别，类似于损坏的图片链接类别？--Traveler100 (talk) 2014年4月26日 (UTC) 11:08

DuckDuckGo 使用 Wikitravel 链接

搜索地点会显示一个 Wikitravel 链接以获取更多信息，例如：https://duckduckgo.com/?q=london — 这将是一个很好的方式来吸引一些流量，说服他们链接到 Wikivoyage。JimKillock (talk) 2014年4月26日 (UTC) 17:30

我认为让 DuckDuckGo 意识到这是一个许多人关心的问题会很好。您可以在此处向 DuckDuckGo 提出建议。我相信我们应该确保他们在短时间内收到许多建议更改的消息。PrinceGloria (talk) 2014年4月26日 (UTC) 20:05

我已就此在 https://duck.co/forum/thread/5688/use-wikivoyage 发帖，欢迎大家在那里添加评论。谢谢！Nicolas1981 (talk) 2014年4月28日 (UTC) 02:24

维基数据列表详情

我从 Openstreetmap 找到这里，尝试将 OSM 对象链接到维基数据，然后最终开始贡献维基百科。我正在 WV 和 WP 的多个语言版本上进行贡献。这让我思考。我将一家餐馆添加到一个行程中，下一步是将其添加到这个 WV 中关于该地区的本地指南中，然后对大约 6 个语言版本做同样的事情。当然，我们在 Openstreetmap 中也重复了所有这些细节。复制/粘贴很容易，没有问题。问题在于当某些细节（例如营业时间）发生变化时。谁会去查找所有提及该细节的实例？对我来说，显而易见的解决方案是将所有这些存储在维基数据中，然后引用属性，尽管我不太确定如何做到这一点，以及技术上是否可能，因为 Q-项不是文章本身的 Q-项。第一个问题当然是，我们想这样做吗？--Polyglot (talk) 2014年4月27日 (UTC) 08:28

你好 Polyglot，欢迎来到 Wikivoyage！Wikidata Q 项无需与任何特定文章匹配，所以这没问题。实际上，我们需要人们努力实施使整个集中化成为可能的模型和工具。请参阅 https://www.wikidata.org/wiki/Wikidata:Property_proposal/Sister_projects#Wikivoyage https://wikivoyage.cn/wiki/Wikivoyage:Wikidata_Expedition 我们还需要修改列表编辑器，以便在列表由 Wikidata Q 项定义时从 Wikidata 获取数据。没有不可能实现的事情，但工作量很大，所以非常欢迎您加入我们的努力 :-) 干杯！Nicolas1981 (talk) 2014年4月27日 (UTC) 14:19

嗨 @Nicolas1981:，我试了，但无法使其正常工作。请查看我在 安道尔 的最新更改--Polyglot (talk) 2014年4月30日 (UTC) 17:54

嗨 Polygot！不幸的是，目前看来安道尔的文章只能访问维基数据项 Q228（安道尔）的属性。需要有人研究维基页面如何通过链接找到 Q228 中链接的所有酒店（并首先找到如何从 Q228 链接酒店）。确实还有很多工作要做...Nicolas1981 (talk) 2014年5月1日 (UTC) 05:29

DuckDuckGo 即时答案？

在 DuckDuckGo 自然搜索结果中偏爱 Wikivoyage 似乎很困难。相反，一位社区成员建议创建一个“即时答案”。这里有一些例子。我还没有计划/开发任何东西，但是如果我们走这条路，我们将不得不回答以下问题，因此欢迎您的回答/想法！请在每个问题下评论，谢谢！Nicolas1981 (talk) 2014年5月8日 (UTC) 03:03

你的即时答案是做什么的？

• 品川王子大饭店 -> 酒店的营业时间、价格及其他信息。其他兴趣点同理。
• 伦敦 -> 伦敦文章的第一句话，如果它没有维基百科文章（不太可能……维基导游上有哪些目的地文章，但维基百科上没有？）。
• 在中国驾车 -> 在中国驾车 文章的第一句话。
• ...（添加您的想法）...

你的即时答案解决了什么问题（为什么它比有机链接更好）？

你的即时答案的数据来源是什么？（如果可能，请提供链接）

• 维基旅游

你为什么选择这个数据源？

• 最新旅行信息

有没有其他替代（更好）的数据源？

• 替代方案：WT、Yelp、TripAdvisor。

有哪些示例查询会触发此即时答案？

此即时答案对哪些社区特别有用？ (游戏玩家、图书爱好者等)

• 旅行者
• 准备旅行的人

这个即时答案是否与 DuckDuckHack 即时答案的想法相关？

• （当我们确定这个想法后，将创建创意条目）

现有的哪些即时答案将被此答案取代/重叠？

• Yelp
• 维基百科

你遇到什么问题了吗？你需要我们帮忙吗？

正式请求：在侧边栏中包含 OpenStreetMap

请评论请求 我将针对我在之前的帖子中简要提及的问题，启动一个正式的评论请求。我认为 OpenStreetMap 是一个很好的资源，可以包含在侧边栏中，原因有几个。首先，它是一个开放项目，就像维基媒体和 ODP/DMOZ（侧边栏中链接的另一个项目）一样。从抽象层面讲，我们相互支持是件好事。从更实际的层面讲，OSM 提供了深入的数据，这些数据对于旅行指南来说可能不合适，但对于深入了解城市的人来说非常有用。此外，它通常具有高质量的内容，尽管它不均衡——就像我们的 WMF 项目一样。还有其他人认为 OSM 是一个足够好且足够有用的项目，值得我们在旅行者阅读完我们的旅行指南后，将他们引导到它那里吗？—Justin (koavf)❤T☮C☺M☯ 2014年4月11日 (UTC) 00:25

我们已经相当突出地整合了 OSM 信息，{{geo}}、{{mapframe}}、{{listing}}、{{marker}}、special:mapsources。你的提案有何不同？K7L (talk) 2014年4月11日 (UTC) 01:22

@K7L: 这些其他模板只是将 OSM 包含在其他地图服务中。我提议做两件事，让 OSM 从（例如）谷歌地图中脱颖而出：OSM 拥有其他地图服务所缺乏的许多高质量选项，而且它是一个开放项目。作为我们自己的开放项目，我们应该鼓励支持其他类似的开放项目。这正是 Wikitravel 最初链接到 DMOZ 和维基百科的原因。—Justin (koavf)❤T☮C☺M☯ 2014年4月12日 (UTC) 05:56

并非如此。看看奥斯威戈#出行；德国“Wikivoyage eV”用户已努力将 OSM 地图直接集成到 Wikivoyage 中，并标记了我们的兴趣点。OSM 并没有被视为像（专有的）谷歌地图那样仅仅是另一种地图服务。K7L (talk) 2014年4月12日 (UTC) 13:24

大多数目的地文章都有一个指向全屏 OpenStreetMap 地图的链接——横幅上方右侧有一个图标。但我预计许多读者不会注意到这一点，或者注意到它是 OpenStreetMap。将此作为“相关网站”组中的链接复制到左侧可能是一个好主意。AlasdairW (talk) 2014年4月12日 (UTC) 14:35

我希望每篇文章都有一张地图。机器人能做到吗？也支持在侧边栏中添加 OpenStreet Map 链接。旅行医生詹姆斯 (talk · contribs · email) 2014年4月12日 (UTC) 17:19

我建议用地图替换图标；用户可能不会注意到图标或意识到它的重要性。Pashley (talk) 2014年6月2日 (UTC) 16:53

DMOZ 工具用于挖掘和检查 Wikivoyage 链接

链接抓取工具 DMOZ 论坛（需要会员资格）上有一个帖子，其中一个用户使用他们的区域链接本体和我们的 RDF 面包屑，并使用一些计算魔法来查找我们页面上已失效或与 DMOZ 重复的链接。该论坛仅供内部使用，但我认为引用是可以的，因为他们对跨领域协作感兴趣。

好吧，我一直在玩弄数据，我得到了一些值得一看的东西，尽管它不是我认为最终产品可能最终会变成的样子。它是一个 DMOZ 主题浏览器，可以映射到相关的 Wikivoyage 链接，并按其页面和类别进行细分。例如温哥华（Wikivoyage 也有几个社区页面，也已清晰识别）

http://dmoztools.net/wikivoyage.cgi?browse_wikivoyage=1&cat=Regional/North_America/Canada/British_Columbia/Localities/V/Vancouver

或者是我在新不伦瑞克省能自动识别的所有地点

http://dmoztools.net/wikivoyage.cgi?browse_wikivoyage=1&cat=Regional/North_America/Canada/New_Brunswick/Localities

很多东西都可以轻松挖掘。我还可以使用 Wikivoyage 的分类来建议地点内的专题类别——我不知道这是否那么重要。

从另一个方向思考，我看到这个类别

http://dmoztools.net/wikivoyage.cgi?browse_wikivoyage=1&cat=Regional/North_America/Canada/New_Brunswick/Localities/Plaster_Rock

包含 13 个未在 DMOZ 中列出的站点，但其中 6 个已失效。我认为 Wikivoyage 项目可以从中获得一定的价值。它们不是专门的链接目录，但 DMOZ 是——这就是为什么我们有一个完善的质量控制系统来清理目录。目前从我所看到的，仅使用我自己的质量控制工具，Wikivoyage 拥有数量惊人的死链接。如果有一个在两个站点都列出的链接数据库，也许我们可以找到一种方法，在我们的站点上删除链接时通知他们的编辑。

从链接挖掘的角度来看，一个显而易见的事情就是过滤死链接，但我认为现在展示它们以作说明之用是有用的。

有趣的是，这是 DMOZ 生态系统的一个部分，它可能对 Wikivoyage 项目有利，而他们可能由于其开源许可系统而不愿在内部开发，因为开源启发式算法将使垃圾邮件发送者在购买过期域名时轻易规避它们。也许对他们来说这不是一个大问题，因为它们都是 nofollow 链接。

这当然可以扩展到所有其他语言的维基导游。我只是首先做了英文版，看看是否有兴趣，因为我更精通英文。

另外，我看到 DMOZ 中 Wikivoyage 列表的数量已增至 20 个 http://www.dmoz.org/search?q=wikivoyage.org 。

有用吗？有没有人愿意在这些页面上的链接以及指向这些页面的链接方面与 DMOZian 们进行来回合作？—Justin (koavf)❤T☮C☺M☯ 2014年4月28日 (UTC) 03:39

有意思！首先，我们真的可以从获取所有死链接列表中受益。动态信息共享（通过维基数据？）会更好。Nicolas1981 (talk) 2014年4月28日 (UTC) 05:04

上面发布的链接有一个身份验证层，阻止了除 DMOZ 编辑器之外的任何人查看它们——我已经制作了一个公共版本的浏览器并更新了链接。这只是本体的映射，但我确实有一个死链接数据库（来自您的 XML 转储，而非实时），我将在稍后将其发布到网上。Unknown (talk) 2014年4月28日 (UTC) 15:10

这是一个 [Wikivoyage 上的死链接列表]，占总链接数的 29305/171536 = ~17%。其中一些当然是暂时性错误，而且它是基于可能略有过时的 XML 转储。还有大约 10,000 个可能的错误或需要纠正但未在此处列出的问题，因为它们更模糊（极小的页面、奇怪的重定向等）。我不确定如何最好地处理这些数据。显然，这是一个相当大的列表——如果持续进行维护，那么单个列出错误的页面可能就足够了，但也许这对于一个页面来说太多了？也许将其分解成更易于管理的部分会更好，或者在单独的讨论页上提及它们？如果对此有兴趣，我还可以将其制作成更可搜索的系统。欢迎提出任何想法！Unknown (talk) 2014年5月1日 (UTC) 00:51

非常感谢这份清单！我修复了一些问题，并意识到修复链接太耗时了，最好是直接删除 29305 个损坏的 URL……有人能编写一个脚本来做这件事吗？Nicolas1981 (talk) 2014年5月1日 (UTC) 05:24

我修复了 卡尔弗城 和 黄石国家公园 中的一些损坏链接，但也遇到了一些误报，这让我对使用自动化脚本删除所有链接感到犹豫。此外，手动删除可能允许我们识别（并删除）一些已关闭的列表。我们能否推广这个列表一段时间（也许通过 Wikivoyage:清理 和其他方式），看看接下来几周完成了多少手动清理，然后再考虑自动化选项？-- Ryan • (talk) • 2014年5月1日 (UTC) 06:12

我当然不打算自动删除此列表上的所有内容 :) 这绝对是为了手动检查。如果我们要采用自动化解决方案，我们会希望将死链接放入队列中，并查看它们是否在一两周内恢复，以确保它们不是暂时性错误，我们还需要针对不同情况进行特殊处理。在 DMOZ 中，一旦我们确定一个链接确实已失效，我们也不会立即删除它们，而是将它们放入一个辅助队列中，编辑人员会在那里寻找替代品，因为通常有一个很好的理由，比如企业更名、获得新域名等等。这就是为什么我在想，在两个项目之间直接协作是一个好主意，因为我用来扫描 Wikivoyage 链接的链接扫描器远不如 DMOZ 中运行的那些完善，而且我们还在不断修复我们的链接，将这些工作的价值传播给其他开放项目（例如这个项目）也很有意义。理想情况下，当 Wikivoyage 发现替代品时，这些替代品也会被发送到另一个方向以改进 DMOZ。使用 Wikidata 动态地做这件事听起来是一个有趣的想法。无论如何，如果这些报告在这里有帮助，我很乐意继续定期从 WV XML 转储中生成这些报告。Unknown (talk) 2014年5月1日 (UTC) 15:03

我以为这个列表来自与 DMOZ 相同的多步骤检查引擎。如果只是一次性检查，那么删除 URL 确实为时过早。但是，如果一个链接持续失效，我将赞成只删除该链接（并保留列表）。与 DMOZ 不同，我们并不绝对需要 URL。与 DMOZ 不同，我们有相对较多的实际前往该目的地的人，这些人最适合在以后添加正确的 URL，或者如果它在现实生活中消失了，则完全删除该列表。无论如何，期待与 DMOZ 在这方面进行合作！干杯！Nicolas1981 (talk) 2014年5月2日 (UTC) 06:15

有计划重新运行此列表吗？进行一次集中的清理活动，然后重新运行，看看还剩下什么要做，这可能是一个好主意。我一直在修补零散的链接，听起来其他人也在做，所以列表可能已经发生了变化。同意其他人关于在检查列表是否已关闭之前，不宜草率删除链接的观点。--Phoebe (talk) 2014年6月16日 (UTC) 05:36

我不会指望有“相对较多的实际前往该目的地的人”作为健全性检查，因为这取决于目的地的受欢迎程度以及我们常规用户的数量。一个偏远小村庄里的小餐馆常常悄无声息地消失，只有村里的当地人才知道。损坏的 URL 往往是企业关闭的第一个外部迹象，因为域名如果每年不续费，就会过期并被垃圾邮件发送者劫持。过时的黄页或白页列表仍会在网上存在十年或更长时间，因为某些网站不更新其信息。除了使用廉价的网络电话服务实际致电这些场所（在大多数工业化国家，拨打座机一分钟只需一两便士），我们无法知道它们是死是活。损坏的 URL 往往意味着场所已关闭。

另一种选择可能是收集一份已损坏的列表，并联系这些目的地的当地 CVB，以争取他们协助发现企业倒闭。K7L (talk) 2014年6月16日 (UTC) 14:58

维基媒体国际会议的 Wikivoyage 宣传单

请看 m:Wikivoyage/Lounge#Wikimania Leaflets。我认为这是一个很好的想法，可以帮助向 WMF 社区推广我们的项目。Powers ^(talk) 2014年5月29日 (UTC) 12:42

太棒了。谁来申请WV的宣传单？--Saqib (talk) 2014年5月29日 (UTC) 12:46

我希望我们能在元维基讨论细节。Powers ^(talk) 2014年5月30日 (UTC) 00:07

当然，但我认为最好先在这里讨论，因为我们更有可能吸引潜在的感兴趣人士，否则到目前为止还没有人在元维基回应。--Saqib (talk) 2014年5月30日 (UTC) 00:19

我在元维基留言说，我认为通过宣传单推广 Wikivoyage 是个好主意 - Matroc (talk) 2014年5月30日 (UTC) 02:44

一张印在卡片上的页面横幅可以作为书签的基础。背面有足够的空间写几行文字。我预计这与一个小传单的成本差不多，并且更容易被捡到的人保留下来。AlasdairW (talk) 2014年5月31日 (UTC) 22:40

推广维基导游

你好！m:Grants:IEG/Promoting Wikivoyage 的个人参与资助已获选。我很高兴能分享维基导游这一极好的资源！基本计划是直接向美国各地的商会介绍维基导游。我将在此过程中征求社区意见，并在酒吧发布更新。主要项目页面在元维基。目前，只是让您知道这个好消息。我们很快会再见的！--Tbennert (talk) 2014年5月31日 (UTC) 03:51

太棒了。做得好！-- Alice^✉ 2014年5月31日 (UTC) 03:57

Tbennert，恭喜！这真是个好消息。--Danapit (talk) 2014年6月1日 (UTC) 16:46

我们指望你 :-) Nicolas1981 (talk) 2014年6月2日 (UTC) 08:37

干得好！恭喜！如果您需要任何帮助，请告诉我们！ :) --Nick ^talk 2014年7月4日 (UTC) 21:00

特拉沃明德

各位，

今天起，第一个跨维基协作项目在 .de 和 .en 上线了！我要感谢 User:Ikan Kekek、User:Pashley 和 User:Texugo 对我的拙劣文笔进行校对和不懈控制，感谢 User:Saqib 提供的静态地图，以及感谢 User:Mey2008 在早期实现了动态地图。特别感谢 User:DerFussi 和 User:Tine，他们是德国管理员，使德语部分成为可能。

我认为我们需要继续进行跨维基导游的合作，以维持维基导游作为一个多语言社区的精神。Mr. Nugget 目前做得很好，所以也许我们应该每年进行一次跨维基合作，以实现 Dotm/OtBP？此致，jan (talk) 2014年6月11日 (UTC) 11:35

Nugget先生！谢谢！我在这里一直在学习，这比金子还珍贵。Llywelyn2000 (讨论) 2014年6月11日19:52 (UTC)

祝贺你和所有参与者！我认为拥有其他跨WV功能会很棒。如果我们能获得任何其他维基的合作，跨维基功能也会很棒。Ikan Kekek (讨论) 2014年6月11日20:43 (UTC)

我与德国WV社区进行了交流https://de.wikivoyage.org/wiki/Wikivoyage:Lounge#Travem.C3.BCnde，他们对每年合作进行“本月目的地/OTBP/FTT”表现出积极的兴趣。André是该领域的宗师，所以我希望我们能找到一种方法来继续下去。也许我们甚至可以设定更大的目标，与意大利和德国社区一起做些什么。jan (讨论) 2014年6月12日07:09 (UTC)

抱歉，迟回复此话题。关于jan的建议，我完全支持年度跨语言专题。当/如果我们与法语和西班牙语社群合作时，我可以担任联络人，但在其他情况下，最好有其他愿意的多语言编辑者表明身份。 --AndreCarrotflower (讨论) 2014年6月16日12:16 (UTC)

不用担心André，我知道你很忙。我想User:Andyrom75可以作为意大利语的中间人，User:Texugo可以作为葡萄牙语的中间人。我会在跨语言讨论页上发帖。jan (讨论) 2014年6月16日12:35 (UTC)

嗯，我会尽力而为。老实说，在葡萄牙语维基导游上，我通常更喜欢保持秩序并在幕后工作，把实际的散文写作留给母语使用者，但目前除了我之外，没有其他常驻贡献者。Texugo (讨论) 2014年6月16日13:37 (UTC)

也许如果我们把里斯本作为一个多语言合作项目，这可能会激起一些兴趣——也许我们可以问问葡萄牙维基百科社区是否愿意参与？PrinceGloria (讨论) 2014年6月16日14:53 (UTC)

我认为这听起来是个好主意。最好先从这里的经验丰富者开始，以确保基本结构到位，但与w:en:里斯本的编辑者或w:pt:旅游的编辑者交谈，可能会找到能帮助解决语言或当地信息问题的人。WhatamIdoing (讨论) 2014年6月17日15:38 (UTC)

jan，非常乐意在需要时提供帮助。只需给我发个it:voy上的消息，以确保能迅速引起我的注意 ;-） --Andyrom75 (讨论) 2014年6月17日21:23 (UTC)

André、WhatamIdoing、PrinceGloria、Texugo，我已经在跨语言酒吧发起了协调讨论。https://meta.wikimedia.org/wiki/Wikivoyage/Lounge#multi_lingual_display_for_Destination_of_the_month 祝好，jan (讨论) 2014年6月18日12:33 (UTC)

Twitter

大家好，尽管标题如此，本节并非仅关于Twitter。这也是对我过去几个月活动极度减少的道歉。正如你们可能猜到的，我最近被工作压得喘不过气来，未能给予维基导游我所希望的关注；我希望你们都一切安好！

在此期间，尽管我尽可能频繁地从维基导游账户发推，但我未能给予它应有的全部关注。因此，我希望呼吁另一位用户帮助运营WV Twitter账户。我并不打算完全停止发推，但在我忙碌时，能有其他人填补空缺会很好——我们目前有超过500名关注者，他们期待内容！在要求方面，任何以前的Twitter经验自然都是加分项，但您还需要成为一位值得信赖的维基导游用户（无论这意味着什么），并且您还需要准备好向我提供您的电子邮件地址/在您的个人资料中启用该功能，以便我能够秘密地向您发送登录凭据。如果有人能想到任何其他必要的要求，请告诉我。

再次，我为我长时间的缺席道歉，但我希望能在夏季变得更活跃一些。很高兴看到项目持续发展（即使是从远处），我仍然绝对致力于WV的成功。谢谢！ --Nick ^讨论 2014年6月12日22:44 (UTC)

你好，尼克。很高兴看到你的消息。如果社区信任我，我可以管理WV Twitter。目前，我正在管理@WikimediaPK。 --Saqib (讨论) 2014年6月12日22:53 (UTC)

垃圾信息增多

最近我看到来自IP地址的垃圾信息显著增加。我在想，如果我们将文章创建仅限于注册用户，这会是个好主意吗？--Saqib (讨论) 2014年6月17日11:29 (UTC)

我看到了一些新页面，但你能给出一些垃圾邮件的例子吗？--Traveler100 (讨论) 2014年6月17日12:46 (UTC)

垃圾邮件已删除。--Saqib (讨论) 2014年6月17日12:48 (UTC)

我不确定垃圾邮件是否已经达到了需要占用过多管理员时间或失控的程度。我希望尽可能保持对新用户的开放，除非/直到情况开始变得非常严重。Texugo (讨论) 2014年6月17日12:54 (UTC)

维基媒体基金会对此的立场会是什么？

另外，似乎很多账户都是为了发送垃圾邮件而自动创建的，所以我不确定限制匿名用户创建页面会有多大帮助……--Andrewssi2 (讨论) 2014年6月17日13:07 (UTC)

我同意Texugo的观点——目前看起来我们每天处理的IP创建垃圾文章平均约为2-4篇，这只是一个小麻烦，而不是一个大问题，而且我不认为这值得改变我们尽可能开放的原则。 --Ryan • (讨论) • 2014年6月17日14:41 (UTC)

是的，这可能会被维基媒体基金会拒绝。--Rschen7754 2014年6月18日14:20 (UTC)

我的猜测是，如果我们决定保持现状，维基媒体基金会会支持维基导游用户，如果我们决定限制新用户或IP创建文章，他们也会支持我们。我认为，维基导游必须在不合理（无论哪个方向）的道路上走很远，维基媒体基金会才会介入——在我看来。关于自动生成的账户：我可以看到维基媒体基金会通过技术措施对此采取行动，甚至无需咨询我们。请记住，用户账户现在是所有维基媒体维基上的账户。我相信已经存在一项限制，即在短时间内从同一IP地址创建大量新账户——我在帮助管理一次编辑马拉松时曾收到过此警告。Filceolaire (讨论) 2014年6月22日19:51 (UTC)

Twitter: WeAreWikipedia

Twitter上的@WeAreWikipedia账户每周由不同的维基百科人运营。这周是我，我正尝试在其中包含一些关于每个姊妹项目的内容。欢迎大家来看看，如果感兴趣可以关注。Andy Mabbett (Pigsonthewing); 与Andy交谈; Andy的编辑 2014年6月17日15:01 (UTC)

嗨，安迪，这是个好主意！如果你想提及维基导游，也许可以提一下我们关于柏林的文章正在进行重大翻新，但我们缺乏来自真正居住在柏林的人的声音。由于德国维基百科/维基媒体社区实际上是最强大的社区之一，这可能是因为他们之前对维基导游不感兴趣——如果柏林对他们很重要，也许是时候大胆行动了！PrinceGloria (讨论) 2014年6月17日15:27 (UTC)

PS。同样，我不确定维基百科人是否知道我们实际上正在使用OpenStreetMap来动态地绘制人们添加的POI（兴趣点——例如景点、餐馆、酒店/旅馆等），以便我们始终拥有最新的地图。这个世界级的应用程序是维基导游独有的（例如，Wikitravel没有），并且基本上由一位非常投入的用户创建和维护——碰巧，是一位德国用户！

柏林已完成——谢谢你的提示。我稍后会介绍OpenStreetMap。Andy Mabbett (Pigsonthewing); 与Andy交谈; Andy的编辑 2014年6月21日13:15 (UTC)

马航MH17航班遭遇不幸

从酒馆转入

就在马航MH370航班失踪三个月后，另一架载有280名乘客和15名机组人员的马航客机在俄罗斯-乌克兰边境被击落。我深感悲痛，这真是一个毁灭性的消息。--Saqib (讨论) 2014年7月17日17:00 (UTC)

是的，确实如此。我希望这是一场误认身份的事件，但无论原因如何，对于马来西亚航空公司来说，这都是极其悲惨的一年，我向所有受这场灾难和暴行影响的人们致以最深切的哀悼。Ikan Kekek (讨论) 2014年7月18日02:11 (UTC)

在顿涅茨克，MH17（从史基浦机场，阿姆斯特丹飞往吉隆坡国际机场，吉隆坡）也在与俄罗斯接壤的Grabovo坠毁（见BBC）。--Liuxinyu970226 (讨论) 2014年7月18日12:32 (UTC)

听到这个消息真是令人悲伤。ϒpsilon (讨论) 2014年7月18日12:56 (UTC)

真是令人悲痛，今年对于马来西亚航空公司来说，简直是一场悲剧。Jianhui67 (讨论) 2014年7月19日11:13 (UTC)

感谢维基导游！

从酒馆转入

你好，

抱歉在这里写了这样一篇随意的笔记（我不知道该把它放在哪里），但我真的很喜欢维基导游作为旅行指南。所以我想感谢所有为它付出的人。

它正在成为（对我来说）第三个最有用的维基媒体项目，仅次于维基百科（当然）和维基词典。

（还有一些其他的项目，比如维基学院，我完全不理解，但那是另一个辩论。）

谢谢大家。我来自布拉格，正考虑增强其文章。 --Running (讨论) 2014年8月6日08:01 (UTC)

不客气，Running。很高兴看到旅行者使用我个人认为是巨大资源的资料。至于我们关于布拉格的文章，非常欢迎你作为贡献者。我鼓励你大胆地进行改进！--AndreCarrotflower (讨论) 2014年8月6日13:56 (UTC)

太棒了！我相信您会喜欢为布拉格以及我们其他目的地和旅行主题文章做出贡献。ϒpsilon (讨论) 2014年8月6日14:10 (UTC)

统计数据已重新计算

您可能想知道，所有维基导游添加的统计数据 (Special:Statistics) 刚刚重新计算。对于不了解的人，由于一个（仍然存在的）bug 导致从其他站点导入页面时重复计数，许多计数过高。This, that and the other (讨论) 2014年7月14日11:50 (UTC)

仅供参考，目前影响统计数据的已知错误有两个：页面导入（bugzilla:40009）和页面移动（bugzilla:64333）。第一个问题已经提出近2年，而最后一个问题是最近才出现的，但似乎还没有人测试/确认。请随时访问bugzilla并投票支持解决这些问题。--Andyrom75 (讨论) 2014年7月14日17:17 (UTC)

我认为投票在Bugzilla上大多被忽略，即使它在某些项目中开启。 WhatamIdoing (讨论) 2014年7月14日22:04 (UTC)

WhatamIdoing，你说的可能没错，但考虑到不作为的替代方案是再等两年一无所获，所以值得一试 ;-) --Andyrom75 (讨论) 2014年7月15日07:07 (UTC)

也许是好消息

大家好。读者人数方面可能有一些好消息。根据的数据，我们的读者人数持续（14天）增长了三倍。Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年7月23日09:50 (UTC)

我完全无法弄清楚如何查看超过1天的网站统计数据。即使我选择不同的语言或项目，这些数字也不会改变。Powers ^(讨论) 2014年7月23日20:07 (UTC)

你需要选择项目总数，然后选择wikivoyage下的统计数据，然后将天数设置为180。不过，这些数字可能不准确。Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年7月23日20:36 (UTC)

夏季？这个数字似乎比去年七月略高。Nicolas1981 (讨论) 2014年7月24日07:03 (UTC)

几周前发生了一些事情，导致观众人数增加。不过，可能只是机器人或爬虫。Powers ^(讨论) 2014年7月24日17:34 (UTC)

是的，是爬虫；很可能来自Guidesebooks.com（只是没有数据的猜测）。超过100万次点击访问了以下页面：Special:CentralAutoLogin/setCookies Special:CentralAutoLogin/deleteCookies。没有哪个有脑子的人会给这些技术页面带来100万次点击 :-P --Andyrom75 (讨论) 2014年7月25日07:23 (UTC)

Wikivoyage的维基数据文档更新

大家好！

我是一名当前维基媒体妇女自由开源外展项目实习生，专门从事维基数据外展工作，只是想告诉大家，维基导游的维基数据文档已更新，希望能对维基导游社区有用，并鼓励进一步合作。如果您感兴趣，请查看Wikidata:Wikivoyage。您也可以在讨论页留下任何反馈意见。

致敬，-Thepwnco (讨论) 2014年7月31日16:45 (UTC)

自动警示框

你好！

作为（至少未来）旅行信息的主要来源，我们有责任确保我们的指南提供准确和最新的安全信息。目前，这是一个手动过程，任何用户都可以将警示框模板添加到文章中。这可能会非常繁琐，因为一个警示可能会影响数十篇文章。例如，西非当前的埃博拉疫情应该添加到几内亚、利比里亚和塞拉利昂所有相关文章中。众所周知，这需要大量时间，而且通常文章缺乏重要的安全信息。

所以，我认为我们应该引入一个脚本，当一个警示框添加到国家/地区时，其下所有页面也会自动获得警示框。由于文章已经按其所属地区进行了分类，因此似乎可以使用相同的机制。

然而，当然也有一些例外。例如，我们会在伊拉克页面以及所有北部地区添加有关当前ISIL攻势的警示框。但将其添加到其南部地区就没有意义了，在那里我们更多地是发出一般性警告。这些类型的问题将需要解决。

总的来说，我确实认为这是一个非常重要的问题，需要深入研究。特别是当维基导游有望成为主要的旅行信息来源时。Jonte-- (讨论) 2014年6月27日12:04 (UTC)

这听起来有点过度。想想一个直接与旅行相关的安全事件，比如9/11：你会不会对美国每一个城镇都添加同样的警告？我可能会对美国、华盛顿特区和纽约添加，甚至可能会对美国每个州，或者可能对每个拥有商业机场的城市（因为机场关闭了）添加。但是每一个小城镇？我想不是这样的。WhatamIdoing (讨论) 2014年6月27日15:41 (UTC)

我们必须小心，不要将自己定位为旅行安全的权威指南，原因很简单，我们是一个志愿者团体，我们中很少有人（如果有的话）真正能够权威地发言或及时更新相关文章。显然，我们有时会针对重大新闻事件这样做，但自动化这个过程并在各地都有警示框似乎不是正确的方向。Andrewssi2 (讨论) 2014年6月28日03:53 (UTC)

根据路透社的报道，南非也禁止来自几内亚、利比里亚和塞拉利昂的旅客入境。--Liuxinyu970226 (讨论) 2014年8月22日07:09 (UTC)

Echo和监视列表

Special:通知 和 Special:监视列表在功能上基本重叠，除了前者还包含额外的（一些非公开的）事件，并且不提供被动使用选项（意味着关闭网页通知或电子邮件通知，并只在我有空时访问页面），而后者不提供主动网页通知选项（但已经提供电子邮件界面）。部分原因，在我个人看来，Echo/通知项目是由监视列表可用性低所驱动的； 想到了这一点。值得注意的是，Echo用户除非禁用JavaScript，否则不会接触Special:通知——在这种情况下，这是他们阅读通知的唯一方式。

我想完成这个

1. 将这两页合并成一页。
2. 为了解决大量信息涌入的问题，引入了多个级别的网页通知重要性（提及为红色，感谢为橙色，新监视列表项目为蓝色等，可在设置中配置）。

对这两点有什么想法吗？--Gryllida (讨论) 2014年9月9日02:39 (UTC)

我并不认为它们是重叠的。我真的不想把别人给我留言或提及我的用户名，与我监视的众多文章混为一谈。--Traveler100 (讨论) 2014年9月9日04:44 (UTC)

Gryllida，你把这个想法发到多少个地方了？WhatamIdoing (讨论) 2014年9月9日19:18 (UTC)