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

{{starnomination}}在手机上显示为“此页面存在一些问题”

特色文章候选图标

尝试在安卓设备上访问东京/六本木：第一行显示“此页面存在一些问题”。

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

被提名为星级文章并非问题，因此消息不应为“此页面存在一些问题”。

顺便说一下，特色文章候选图标看起来像一个破碎的星星。是否可以将其改为正在建造的星星？ Nicolas1981 (讨论) 2013年10月8日14:38 (UTC)

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

我能想到一些不错的概念，但它们都需要比一个小图标更多的细节。比如一些脚手架和一位正在进行半成品画作的画家，或者一台起重机正在将最后一块拼图放下。动画的…… • • • Peter (Southwood) ^(讨论)： 2013年10月8日15:03 (UTC)

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

一支正在画星星但尚未完成的铅笔如何？ Nicolas1981 (讨论) 2013年10月9日11:20 (UTC)

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

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

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

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

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

此错误是由ombbox模板的类名错误导致的。我已经修复了。 Kaldari (讨论) 2013年12月31日19:21 (UTC)

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

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

新年快乐

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

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

既然你懂芬兰语，那我就说Kiitoksia ja hyvää uutta vuotta sinullekin，Danapit！祝大家新年快乐，来自一个出奇温暖的赫尔辛基（新年时通常是零下几度并下雪，现在却是+5°C还下雨）。谢谢你的烟花，Saqib！附言：在维基百科的“你知道吗”栏目中，我看到了关于苏格兰新年传统和这个庆祝活动名称词源的文章…… ϒpsilon (讨论) 2013年12月31日16:53 (UTC)

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

Ypsi说得对。卡拉奇最近开始在新年夜吸引来自该国其他地区的人们，因为其在大港有盛大的新年庆祝活动，而迪拜也在新年夜吸引了许多海湾国家的人们参加盛大的新年庆祝。 --Saqib (讨论) 2013年12月31日20:32 (UTC)

祝大家新年快乐！2013年是新维基导游社区的第一年，我认为这预示着2014年将取得巨大成就。 Andrewssi2 (讨论) 2013年12月31日19:37 (UTC)

祝大家新年快乐！祝2014年一切顺利！ :) --Nick ^讨论 2014年1月1日02:50 (UTC)

祝1914年非常成功和健康。 --RolandUnger (讨论) 2014年1月1日08:38 (UTC)

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

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

MWException类型的致命异常

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

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

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

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

发现

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

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

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

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

事实上，我们的以色列文章提到耶路撒冷的地位未得到联合国承认。不过，我现在已经在“发现”部分和文章本身更改了这句话。 ϒpsilon (讨论) 2014年1月8日05:27 (UTC)

就记录而言，联合国既不承认塞浦路斯的分裂，也不承认土耳其对岛屿北部的占领，也不承认尼科西亚在两国之间的分裂。据我所知，土耳其塞浦路斯民族只得到世界上另一个国家——土耳其的承认。 Ikan Kekek (讨论) 2014年1月8日21:29 (UTC)

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

我们基本上意见一致，但以色列的文章需要一些编辑，因为西岸已从中移除。不过，一个问题是是否将巴勒斯坦领土文章重命名为巴勒斯坦。我欢迎任何人参与讨论：巴勒斯坦领土的讨论。 Ikan Kekek (讨论) 2014年1月8日23:23 (UTC)

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

我最初的帖子只是想说，除非绝对必要，我们最好完全避免提及这些事情——不用说，我认为“发现”功能上随机选取的文章中的随机摘录不构成“绝对必要”。当然，维基导游不希望在任何政治争论中冒犯任何人，如果我们可以避免的话，尽管有用，但免责声明框并不是避免争议的万无一失的方法。你紧接着回复的评论是针对Ypsilon的，即联合国否认耶路撒冷是以色列首都并不意味着这一点没有争议。相反，以色列“合法”首都的问题本身就是一个有争议的政治问题，也是尼科西亚的摘要选择不理想的另一个原因。同样，我的观点是，即使要提及这个问题，其参数也应尽可能限制。

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

我们基本上意见一致，尽管以色列的文章需要一些编辑，因为约旦河西岸已从中移除。不过，一个问题是将巴勒斯坦领土文章重命名为巴勒斯坦。我欢迎任何人参与讨论：巴勒斯坦领土中的讨论。 Ikan Kekek (讨论) 2014年1月9日00:26 (UTC)

话说，我们能把西北地区重命名为“鲍勃”吗？ K7L (讨论) 2014年1月9日16:02 (UTC)

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

“Wikivoyage 2014年十大国家” ？

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

我正在考虑制作一个显示最受欢迎文章的列表。这里有一个例子。为此目的有一些维基百科扩展，但这会给我们带来好处吗？ --Saqib (讨论) 2014年1月2日 13:52 (UTC)

后一个提议比前一个好无数倍，原因有很多。我支持在某个显眼位置显示“最受欢迎文章”（过去一小时或一天）的功能。PrinceGloria (讨论) 2014年1月2日 16:53 (UTC)

为了将此扩展安装到此维基上，我们需要一些本地支持。能得到一些支持吗？ --Saqib (讨论) 2014年1月18日 15:14 (UTC)

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

我同意PrinceGloria的看法。作为WMF网站，我们首先是准确、公正信息的可靠来源。我们的目标与《孤独星球》或《国家地理旅行者》之类的出版物有着微妙但重要的区别。此外，我们自己的政策禁止宣传和过度推广的措辞，因此在这种事情上我们必须非常谨慎。向读者提供关于我们最受欢迎文章的资源可能符合这些参数，只要我们这样做的方式避免出现“营销”这些目的地给读者的嫌疑（这可能排除主页上任何过于显眼的链接）；除此之外的任何内容似乎都有问题。 -- AndreCarrotflower (讨论) 2014年1月18日 15:52 (UTC)

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

Julia说得好，我想我现在很倾向于放弃这个想法了。 --Saqib (讨论) 2014年1月18日 16:33 (UTC)

在Wikivoyage:World cities/Large表格的“F”栏中，我们确实有关于最受欢迎目的地的内容。这是客观来源的，来自一篇基于万事达卡报告的《福布斯》文章。我们能否找到方法改进这一点（还有其他来源吗？），和/或让它更突出地显示出来，也许作为一个旅行主题？Pashley (讨论) 2014年1月18日 18:56 (UTC)

Wikivoyage——艰难的第二年

我真的认为这个项目很棒。它拥有丰富的精彩信息，并且由一群善良、积极的编辑组成。

话虽如此，我对Wikivoyage的喜爱确实意味着我有时觉得有必要强调该网站正在经历的困难。

目前，感觉网站有点停滞不前；我们似乎失去了Wikivoyage近一年前在WMF服务器上推出时所散发的一些活力和热情。我们似乎比以往任何时候都更热衷于就每个问题进行长时间的争论，而“共识”却一直未能达成。在过去几个月里，网站上的许多讨论已经堕落到人身攻击的地步，而我们似乎比以往任何时候都更不愿意大胆前行，许多这样做的人却因遵循项目的宗旨而受到指责。

由于这些原因（以及其他原因），我们似乎正在失去编辑——这绝不是Wikivoyage所需要的。事实上，我们真正需要做的是进行有计划的宣传，吸引来自其他WMF项目和更广泛的贡献者。无论他们只是想改进关于自己家乡的文章，还是投身于幕后蔓延的讨论，我们都应该张开双臂欢迎他们（如果是拖拽的话就合拢双臂）。

当我回顾去年八月这次讨论时，我很伤心地看到许多人出色的想法和重要的优先事项都与我们擦肩而过（我相信Ryan的政策优先事项清单尤其重要）。如果能重新找回一些乐观情绪，并将其投入到改进网站中，那就太好了。

那么我们能做什么呢？我个人建议两件事，我认为它们需要紧急处理：

1. 尽管这可能很困难和不愉快，但我真的觉得我们需要理清我们对共识的理解。目前，太多相对次要的问题演变成无休止的争斗，分散了我们对网站面临的更大问题的注意力。
2. 获取更多编辑。这比打字要难得多，但简单地说，我们需要更多的人以各种方式为网站工作。我们可以尝试通过许多不同的方法来做到这一点：更有效地利用我们的社交媒体存在；在其他WMF网站上做广告；针对网络上的旅游和旅行团体和论坛；与媒体接触；发起某种大规模的活动（也许在Reddit上？）。无论我们做什么，我们都需要尽快行动：目前我们的人手不足以同时处理两三个问题，所以新的想法（无论是受赞扬还是受谴责）都会被搁置，我们的大部分文章多年未被触及。

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

很抱歉这是一篇有点消极的帖子，但我坚信Wikivoyage及其社区会成长和繁荣。

如果幸运的话，也许有一天我就不会再谈论我的旅程了。 :) --Nick ^讨论 2014年1月7日 00:03 (UTC)

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

每当我感到对Wikivoyage未来悲观时，我就会想到我们的竞争对手Wikivoyage，这个网站对旅行者的用处越来越小。在短时间内，WT将变得一团糟，充斥着广告、未被撤销的破坏和分叉前早已过时的信息。与此同时，我们有一个小而活跃的社区，积极地改进我们的产品——诚然，可能人手不足以完成足够的工作，但我们的同行甚至没有维持现状。考虑到所有这些，WT目前在网站流量上可能拥有的任何优势，我认为都只是暂时的。

这并不是说Wikivoyage现在面临的问题应该被忽视或淡化，而是着眼大局确实有助于更好地看待问题。

-- AndreCarrotflower (讨论) 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

一边希望wt消失，一边拉屎，看看哪个先满。

谈论wt是“竞争对手”已经很累了。一年了。我们在这里，他们在那里，他们不会消失。不管你喜不喜欢，他们比我们有更多的编辑。他们有更多的访问者。这个网站由一群管理员维护，他们在人工筛选垃圾信息方面做得很好。

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

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

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

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

维基百科无限期封禁只进行破坏的账户。捣乱是一种破坏，或者说足够接近了。如果这不是Wikivoyage的政策，那它就应该成为政策。 -- AndreCarrotflower (讨论) 2014年1月9日 18:53 (UTC)

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

我们的主要目的是编写旅行指南。搜索引擎优化是一项重要任务，将我们的指南与市面上的其他指南区分开来也是，但它永远不会是我们的主要任务。我们需要填补现有地理覆盖范围的空白，并更新内容，以区别于网络上看似无限的过时数据。一旦页面达到“可用”状态，就可以开始考虑提议姐妹项目或外部网站链接到我们的内容了。K7L (讨论) 2014年1月8日 17:01 (UTC)

我已启动了一个讨论，旨在解决Nick关于共识的第一点，详见Wikivoyage talk:Consensus#Wikivoyage:Consensus/Draft。欢迎提供反馈。 -- Ryan • (讨论) • 2014年1月13日 02:28 (UTC)

牛津大学的Wikivoyage图表

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

@Nick：关于你提到的最后一点，我记得之前有一个提案，通过翻译其他语言版本中更全面的文章内容来改善英文维基导游对某些地理区域的覆盖。这对于评估我们可用的资源肯定会有很大帮助。 -- AndreCarrotflower (讨论) 2014年1月10日 23:08 (UTC)

在另一个完全不同的主题上，我惊讶于他们不认为法语是我们的“四大主要语言”之一。它肯定比西班牙语更大。 -- AndreCarrotflower (讨论) 2014年1月10日 23:11 (UTC)

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

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

这就是为什么英文维基导游也应该把兴趣点（POI）放到维基数据（WikiData）中，这会带来巨大的好处 :-)。我们将在意大利、希腊、德国、法国、土耳其、埃及等国获得巨大的收益，当然还有其他国家（在多种语言中维护列表细节意味着一些重复的工作）。Nicolas1981 (讨论) 2014年1月11日 15:43 (UTC)

有没有一份清单，列出存在于其他语言但不存在于英语中的文章？如果没有，这里会有人对这样一份清单感兴趣并从他们懂的语言进行翻译吗？Nicolas1981 (讨论) 2014年1月11日 15:43 (UTC)

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

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

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

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

机器人是否能转换德语维基导游的文章？

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

结果很小（不要对一个1031人的村庄期望过高），但我认为这是一个好的开始，肯定比什么都没有强。

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

这篇文章没有横幅也没有图片。横幅当然可以包含在内，图片也可以包含在内，无需标题。POI名称是个问题。通常POI名称需要翻译，例如“Museum im alten Pfarrhaus”。我认为机器人应该只翻译例如10篇文章，等待这10篇文章被人精修后，再生成另外10篇，以此类推。Nicolas1981 (讨论) 2014年1月11日 17:21 (UTC)

我假设“Hauptstrasse”是“rue Principale”是“Main Street”是“High Street”。如果“翻译”来自特定目的地的当地语言文本，并且它们使用西方欧洲字符集，我认为最初保持原样是可以的——但我们可能应该避免将一篇关于德国的法文文章（例如）原封不动地放入英文维基导游中，如“1, rue Hauptstrasse, Une ville allemande”，这太不英文，也不德文了。K7L (讨论) 2014年1月11日 17:56 (UTC)

这样的机器人可能会有用。但是，我们仍然需要有人来翻译任何实际上不是英语的内容（描述、兴趣点名称、整个“理解”和“保持安全”部分等等）。我们应该让机器人也把这些内容带过来，并在指南中留下大量非英语文本，还是让那些来润色文章的人去找到正确的德语列表，然后复制并翻译文本？

顺便问一下，他们真的会用法文写“rue Hauptstrasse”（大街）这样的东西吗？在一个本来就是拉丁字符地址之后或之前加上一个多余的“街”或“Rue”或任何类似的词有什么用？ϒpsilon (讨论) 2014年1月11日 20:09 (UTC)

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

翻译我们文章中的街道名称真的符合旅行者的最佳利益吗？我设想一个去巴黎大屠杀纪念馆的人，一边在街边标牌上茫然地经过“rue Geoffroy-L'Asnier”，一边焦急地寻找“Geoffroy L'Asnier Street”。我曾与足够多的英语单语者一起旅行，深知这并非一个牵强的假设。 -- AndreCarrotflower (讨论) 2014年1月11日 21:57 (UTC)

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

需要注意的一点是：如果从其他语言的维基导游导入现有文章，那篇文章可能已经包含了翻译的街道名称。fr:Ottawa 和 fr:Toronto 使用“rue”，而 fr:Londres（伦敦）使用“Street”。de:Paris 有时使用“rue”，但更多时候使用“Place Charles de Gaulle, sehenswerter Platz, auf dem der Arc de Triomphe steht.”。还有一个额外的问题是，目的地城市本身可能是多语言或至少是双语的。如果源维基导游是目的地的当地语言，这很容易管理。如果是第三国的语言，机器人不太可能避免三语混淆。K7L (讨论) 2014年1月11日 22:36 (UTC)

您似乎只对https://de.wikivoyage.org/wiki/Wiedensahl 进行了部分翻译。这确实很好，不过我猜您提议的机器人只会转换带有基本信息的列表？您应该在开头添加翻译模板，例如：{{translate|nl|Den Haag}}，以便后续进行人工翻译追踪。（希望您不要介意，但我刚刚已将此添加到您的文章中以作说明）Andrewssi2 (讨论) 2014年1月12日 15:09 (UTC)

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

也许有一个模板添加到文章的讨论页面（原始德语文章）会很有用，以感谢文章的创建者并告知他们，这样他们如果有能力和意愿就可以加入进来。AlasdairW (讨论) 2014年1月13日 00:04 (UTC)

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

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

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

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

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

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

我会对大规模创建机器人文章持谨慎态度：例如，“柏林是德国的一个城市。”这样一篇完整的文章并没有多大好处。--Rschen7754 2014年1月15日 05:31 (UTC)

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

生日庆祝

还是老一套的蛋糕

1月15日（只剩2天了！）是Wikivoyage在WMF服务器上成立一周年。由于我们去年没有庆祝该项目成立10周年，我们有什么想法来庆祝这个里程碑呢？ --Nick ^讨论 2014年1月13日 20:02 (UTC)

如果有人能准备一个合适的网站通知，那将是最低限度，如果有人能联系到WMF营销团队，在Twitter和Facebook页面上提及也会很棒。我相信其他人会有额外的建议——感谢您提出这个里程碑。 -- Ryan • (讨论) • 2014年1月13日 20:07 (UTC)

你好亲爱的Wikivoyage，祝你生日快乐，万事如意，但今年没有新鲜蛋糕。下次好吗？哈哈！ --Saqib (讨论) 2014年1月13日 20:49 (UTC)

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

我同意您的观点，我们明确这一点很重要，但对外部人士来说，“生日”的概念比“项目迁移到WMF服务器的周年纪念日”更容易理解；单独说“周年纪念日”会引出“什么周年纪念日？”的问题。也许我们只需说“这是我们的生日”，而不提及我们几岁（我们是10岁或1岁）。 --Nick ^讨论 2014年1月13日 21:41 (UTC)

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

由于世界某些地方现在已是15日，我将大胆前行并更改网站通知。如果有人有异议，我将乐意更改。 :) --Nick ^讨论 2014年1月14日 11:53 (UTC)

周年纪念日比生日更难传达，这种想法是荒谬的。但我猜我只会把它添加到我在这里无人理睬的意见清单中。 Powers ^(talk) 2014年1月14日 15:19 (UTC)

这似乎有点不公平，Powers。你的意见总是受到欢迎并被认真考虑；持续寻找适合美利坚合众国的横幅，正是由于你的反对和意见——你没有被忽视。我的意思仅仅是，“生日”比“我们搬到维基媒体基金会服务器的周年纪念日”听起来对局外人来说更像一个重大的场合——没有冗长的解释，后者可能看起来是一个简单的技术变更，不值得庆祝。当我们不得不在140个字符内宣布时，简洁和简单的概念是很有价值的。我并非否认WV的传统，也并非否认这里的许多贡献者已经在这个项目上工作了很多年，但对于不熟悉该网站运作的英语使用者来说，Wikivoyage在一年后的明天是全新的。既然我们去年七月没有与WT一起庆祝，那么不指定一天作为WV的生日似乎很可惜。未来几年我们如何命名这一天——周年纪念日、生日或独立日——取决于社区，但让我们利用这一天，无论它是什么，来反思我们已经走了多远，以及我们还能做些什么。--Nick ^talk 2014年1月14日 15:35 (UTC)

我强烈并激烈地不同意你的评估。称其为周年纪念日绝不会使情况变得过于复杂。我不明白你为什么要改变措辞，除了将“birthday”（生日）改为“anniversary”（周年纪念日）。所有关于“冗长解释”的内容，当你使用“anniversary”一词时，并不比使用“birthday”一词时更必要，而且还额外获得了一个并非公然虚假的好处。（Wikivoyage绝非在2013年1月“诞生”。） Powers ^(talk) 2014年1月14日 19:26 (UTC)

恕我直言，插手争论，但我确实觉得“生日”比含糊的“周年纪念日”更友好，更不冷淡和专业。而且肯定有人认为这个项目的这个特殊版本是在一年前“诞生”或“重生”的。对我来说，这似乎是正确的选择。确实生日快乐，非常感谢您让我有宾至如归的感觉。虽然我不太合群，但我会尽力尝试。 Alhens (talk) 2014年1月14日 23:27 (UTC)

其他庆祝活动

还有其他庆祝活动的好主意吗？ 这份Signpost报告承诺将举办一场“大型公共派对”！也许可以创建一个页面，总结过去一年的亮点？ --Nick ^talk 2014年1月14日 21:48 (UTC)

Wikivoyage 生日快乐！

1月15日标志着Wikivoyage在维基媒体基金会服务器上运行的第一年。让我们借此机会庆祝过去一年中我们取得的一些成就、您最喜欢网站的哪些部分以及您希望明年发生什么。 --Nick ^talk 2014年1月14日 11:53 (UTC)

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

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

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

生日快乐，新年快乐！:D。附注：两小时前横幅和页面横幅大小相同，现在却变得巨大了？是不是只有我注意到了？ ϒpsilon (talk) 2014年1月14日 17:47 (UTC)

对我来说，它仍然显示为正确的大小……你能在我的讨论页上发布一张截图吗？ :) --Nick ^talk 2014年1月14日 17:59 (UTC)

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

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

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

祝第七个生日快乐，也是作为WMF姊妹项目的第一个生日。感谢你们在这里所做的一切工作。 -- DerFussi 2014年1月15日 05:53 (UTC)

Wikivoyage 生日快乐。最近从 Wikitravel 转过来，了解了分歧及其原因。 --Larkly (talk) 2014年1月15日 08:14 (UTC)

@Larkly: 你在 Wikitravel 的用户名是什么？你可能希望在这里使用相同的用户名并将账户合并，以便你的贡献历史得到认可。Wikivoyage:User account migration 有进一步的解释... --118.93nzp (talk) 2014年1月16日 00:06 (UTC)

迟来的生日快乐，Wikivoyage。欢迎，Larkly。我们很高兴你加入。 -- AndreCarrotflower (talk) 2014年1月15日 21:27 (UTC)

Commons 上的意见征询：维基媒体是否应支持 MP4 视频？

我很抱歉此消息仅提供英文版本。如有需要，请翻译它以帮助您的社区。

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

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

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

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

请加入本次意见征询——并分享您的建议.

欢迎所有用户参与，无论您是否活跃于 Commons、Wikipedia、其他 Wikimedia 项目——或任何使用我们免费媒体存储库内容的网站。

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

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

WT归属

我们通常使用 Template:Wikipedia 进行归属，当我们从维基百科复制内容时，所以我正在想是否也可以为 Wikitravel 创建一个类似的模板，然后将该模板添加到文章的讨论页面，在这些文章中，WT 归属出现在页脚。这样，我们就可以取消页脚中的 WT 归属了。如果之前已经讨论过，请忽略此帖子。 --Saqib (talk) 2014年1月15日 11:56 (UTC)

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

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

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

根据WMF的使用条款，在编辑摘要中提供署名就足够了。然而，Wikitravel可能施加了额外的要求。有没有人知道在哪里可以找到内容复制到Wikivoyage当日的使用条款副本？ Edge3 (talk) 2014年1月18日 23:22 (UTC)

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

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

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

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

那么也许我们可以删除超链接，但保留URL？我们可以像下面这样做，但禁用超链接：“本文基于...来自Wikivoyage文章‘美国’（http://wikitravel.org/en/United_States）的文本....”知识共享指南指出我们至少应该包含一个URL。 Edge3 (talk) 2014年1月19日 03:51 (UTC)

酒吧清洁

这个页面变得相当庞大，所以我将一些旧的讨论（大约两个月或更早的）移动到它们的相关位置。有人能快速审阅并确认我做的是否正确吗？

我从顶部的指南中得到的印象是，“旅行者酒吧档案”应该是对话应该被移动的最后一个地方，尽管查看档案页面，似乎大多数对话都以这里结束？

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

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

大家好！

我编写了一个脚本，用于将英文 Wikivoyage 文章转换为法文 Wikivoyage 文章。这是结果：https://fr.wikivoyage.org/w/index.php?title=Aarhus&oldid=193198

生成的内容

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

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

有意思。一定有办法把它放在一个简单的网页界面后面，然后放在某个工具服务器上，就像https://toolserver.org/~dispenser/cgi-bin/webreflinks.py要求en.Wikipedia文章名称并将其所有<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 (talk) 2014年1月19日 16:24 (UTC)

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

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

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

保守教条

有人写道，我们的工作受到“旅行者视角下最好的”这一原则的指导，这甚至可以被称为我们的“首要指令”。

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

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

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

莱恩正在拉票的这些改变是否威胁到了这种基本的维基自由？ --118.93nzp (talk) 2014年1月19日 22:18 (UTC)

仅就背景而言，有没有关于不使用<abbr title="(解释性文本)">(本地化术语)</abbr> （或类似用法）的先前讨论？ Andrewssi2 (talk) 2014年1月19日 23:46 (UTC)

据我所知没有。

然而，我也未曾听说过禁止在西班牙语单词中使用外国字符的讨论，例如eñe在El Niño中的使用，或Bogotá中的重音符号，或Māori中的长音符号，或Eskişehir中的音调符号。

我真的不希望我们达到这样的境地：每一次“创新”都需要事先获得许可。如果有人引入了一个新词（对我们来说），然后经过深思熟虑达成共识来禁止这项创新，那倒是公平。然而，仅仅因为少数知名编辑“不喜欢它”，就不应该意味着全面禁止，除非有真实且有文件记录的共识支持这项禁令。

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

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

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

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

我认为在很多情况下，人们夸大了实际存在的差异，以便插入变音符号。我还没有遇到过一个西班牙语使用者，他们会笨到分不清Bogota是Bogotá。即使有西班牙语使用者无法理解，这也没关系，因为英文Wikivoyage并非为西班牙语使用者设计；它是为英文使用者设计的。指南无论如何都应该在页面顶部包含当地的拼写（或字符），所以即使存在很大的差异，例如英文与韩文，如果你出于某种原因需要向韩国人提及城市名称而他们听不懂，你也可以指向字符。西班牙语也可以这样做。出租车司机理应相当习惯外国人奇怪的发音。许多出租车司机本身就是外国人，他们发音不正确。

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

关于文章名称中变音符号的政策主要包含在Wikivoyage:文章命名约定#示例中。对于波哥大/波哥大，前者可能符合“常用英文名称”标准，因为后者在英文地图和文献中不常使用，但在变音符号和非变音符号版本同样常见的情况下，我们使用当地名称（例如圣保罗）。 -- Ryan • (talk) •

一个缺少重音符号的外国名字仍然是一个外国名字。我们需要从缺少变音符号的标题重定向，因为有人可能从缺少或更难输入的设备（如手机）访问WV，但本质上“café” “piñata” “maître d'hôtel”以及英语中的其他非英语单词，并不会仅仅因为有人忘记了一两个重音符号而神奇地变成英语。在蒙特利尔/西岛中省略重音符号是可以接受的（因为蒙特利尔的这一部分有一个著名的英语少数民族，他们通常会省略重音符号并相应发音），但波哥大无论拼写错误如何，它都是一个西班牙语名字。它与英语无关。

当一个地方有两种不同外语名称时，情况就会变得尴尬，例如切尔诺贝利/切尔诺贝尔（音译，乌克兰语/俄语）或格但斯克/但泽（波兰语/德语）。选择使用哪个名称就成了政治问题。 K7L (talk) 2014年1月20日 16:18 (UTC)

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

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

Powers，这确实是 HTML，我同意它取决于浏览器。[例如，这个元素在 IE7 之前的 Mickysoft's Internet Explorer 中不受支持，尽管 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 ，变音符号 voilà 就会出现。这并不能解决键盘和椅子之间的问题... 我不懂任何外语，而且在我自己的国家，我的文本已经够乱了。K7L (讨论) 2014年1月21日 16:28 (UTC)

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

大家好，

我发现所有语言的版块（吃、住等）都大同小异，我们都试图为每个版块找到相关的图片（“吃”版块放食物图片，等等）。通常每个版块有零张、一张或两张图片，放在版块的开头。

维基数据可以帮忙！让我们为每个目的地定义一个小的 Commons 图片文件名列表，每个版块都有一个本地化的图例，支持所有语言。这显然比我们为横幅所做的更复杂。

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

经常地，WV 会讨论文章中使用哪种横幅最好，而这些讨论在英语母语者之间可能会非常漫长和困难。

如果我们将这类内容集中到维基数据中，那么在不同社区之间进行这种讨论岂不是会有问题吗？实际上，这岂不是会将所有不流利英语的编辑者排除在有关其社区文章内容的讨论之外吗？Andrewssi2 (讨论) 2014年1月20日 03:15 (UTC)

Andrew，这是一个中肯的观点；维基数据在这方面看起来相当诱人……--118.93nzp (讨论) 2014年1月20日 03:19 (UTC)

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

所有语言的大多数部分都没有图片，如果有图片都会受益。99.9% 的部分图片都不会引起任何争议。对于剩下的 0.1%，你总是可以像我们现在这样，移除维基数据模板并放置硬编码图片。Nicolas1981 (讨论) 2014年1月20日 06:36 (UTC)

那会不会有风险，有人会偷偷地将“upright”这种不当（据一些超级用户说）的相对图像尺寸插入进去？毕竟，大多数其他 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)

我不确定这是否行得通，因为通常一篇文章的长度在不同语言之间会有很大差异——本地语言或拥有最多 Wikivoyage 用户的语言会有最详细的内容。罕见的例外是像 Lac-Mégantic (en/fr) 这样完全翻译的页面，其中完整的列表集经过某种翻译后完整地往返于不同语言之间。对于一篇冗长详细的文章来说，适当的图片数量对于一篇短小的草稿来说可能过多。K7L (讨论) 2014年1月20日 16:25 (UTC)

你说得对，在空荡荡的版块里可能会觉得空虚。而且我不确定 Lua 等语言是否能检测到版块的长度来调整要显示的图片数量。注意：当兴趣点在维基数据中时，看/做/买/吃/住版块的大小在不同语言之间不会有太大差异。Nicolas1981 (讨论) 2014年1月21日 03:19 (UTC)

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

很抱歉，我看不出这有什么好处。图片是文章中唯一可以轻松地从一种语言转移到另一种语言的特性，而无需理解文章中的任何内容——只需点击图片即可查看图片页面，然后从那里复制标题。AlasdairW (讨论) 2014年1月20日 22:30 (UTC)

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

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

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

我不太确定这个。一个问题是合理使用图片的管理；我意识到关于它们的使用一直存在一些争议，但它们有合法的使用方式，而且它们不能上传到 Commons，必须在本地处理……--Rschen7754 2014年1月21日 09:07 (UTC)

我现在进行翻译时，只是重复使用相同的图像，到目前为止还没有遇到麻烦......无论如何，任何潜在不可用的图像都会留在模板之后。当尝试在维基数据中插入图像时，维基数据甚至可以检查其许可证是否正确，因此相对于非维基数据图像复制来说是一个优势。Nicolas1981 (讨论) 2014年1月21日 13:22 (UTC)

图像的放置位置可能仍需手动决定，因为文章长度的差异以及 en: 上缺少{{Info Ville}} 会影响页面上（以及何处）有多少可用空间。K7L (讨论) 2014年1月21日 16:36 (UTC)

你好 Nicolas1981。我只是想说，你提供了许多增强 WV 并研究我们如何利用 WikiData 的想法，这真是太棒了。尽管这个图片想法在此线程中没有受到太多热烈欢迎，但我仍然希望看到你更多的想法。Andrewssi2 (讨论) 2014年1月22日 01:35 (UTC)

GAC 申请包含一项“维基导游竞赛”

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

感谢 Tony 提请我们注意此事——也祝你新年快乐！--118.93nzp (讨论) 2014年1月21日 08:25 (UTC)

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

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

听起来像一项艰巨的任务……关于旅行维基的好处是，我们中的一些人会在某个时候出于个人乐趣前往那里，通常带着相机。所以如果真的有比赛，它可能会与 WLM 比赛有所不同。Nicolas1981 (讨论) 2014年1月21日 13:16 (UTC)

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

我注意到 Talk:Croatia 页面上有一个免责声明框，要求人们不要在一个敏感的文章中过多地参与政治。我从中创建了一个模板，并原封不动地使用了相同的文本

这里不是政治论坛；请将所有的讨论限制在如何最好地改进 瑞士 文章上。无关紧要的辩论、政治咆哮、无稽之谈的诗歌等都将被移除。这是一本旅行指南，政治争议除非直接影响到旅行者的体验，否则完全无关。有关更多指南，请参阅 Wikivoyage:Be fair#政治争议。

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

如果有人想帮助改进文本，请随时加入。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 (讨论) 2014年1月22日 02:26 (UTC)

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

我认为这个模板的目的是/应该是试图让讨论与维基导游和维基导游文章相关，而不是添加一些与国家政治或文化无关的离题咆哮。--Rschen7754 2014年1月22日 18:54 (UTC)

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

讨论页模板以指示英语语言变体

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

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

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

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

一个小小的更正说明：如果文章与任何其他变体（如澳大利亚、加拿大、印度等）没有明显关联，则应默认使用美式英语。

[许多年前，美式中心派做出的两项妥协/让步，才使得目前的局面得以达成：

1) 罕见的美式英语拼写“traveller”和“travelling”应在所有地方优先使用，而不是“traveler”和“traveling”；

2) 日期默认为 dd Mmm yyyy（例如：2014年5月22日），类似于此处每个人签名的时间戳样式。] --118.93nzp (讨论) 2014年1月22日 04:41 (UTC)

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

如果连这个小点都有歧义，那我们可能应该将讨论转移到 WV 的其他部分。有什么建议去哪里吗？Andrewssi2 (讨论) 2014年1月22日 14:23 (UTC)

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

把“kilometer”这个词从 Wikivoyage 禁用真是太诱人了。它在美国不常用，因为他们仍然使用英里，而且在其他国家也不正确，因为“metre”是长度单位，“meter”是测量装置。K7L (讨论) 2014年1月22日 15:46 (UTC)

我完全同意。在大多数地方，我用其普遍已知的符号 km 来代替。同样，对于作为测量单位的 meter，m 也是普遍理解的。除了历史性妥协之外，Powers 的总结总体上是正确的。然而，那些声称对这些缩写和语法的琐碎问题深表不感兴趣和蔑视的人，却常常耗费大量热情和精力来阻挠那些花费大量时间校对这些琐碎问题的人，这总是令人惊讶；不是每个人都能成为狄更斯或麦尔维尔……--118.93nzp (讨论) 2014年1月22日 16:59 (UTC)

我认为大多数国家/地区的语言变体都已达成一致，不是吗？所以一个模板主要作用是指导人们使用哪个版本？我们不应该忘记，对于许多在这里做出贡献的人来说，英语是第二、第三甚至（对我来说是）第四语言。对于母语者来说，英语变体之间的区别是自然的，但对于许多其他人来说，则不那么自然。我喜欢一致性，并且完全接受关于哪些文章偏爱哪个版本的规则，但我确实认为当人们使用错误版本时，我们需要非常宽容，并深思熟虑我们在模板或其他地方指导特定版本时使用的措辞。我们想做的是阻止将一个版本“纠正”为另一个版本，我们不想阻止人们在不确定拼写时做出贡献。我知道我并不总是保持一致，而且老实说，我经常对 meter 和 metre，center 和 centre，travel(l)er，sizable 和 sizeables 以及所有其他内容感到困惑。我很高兴有校对人员比我更快地纠正我的错误。但我更乐于看到普遍的共识，即这些细节与我们创建良好旅行信息的总目标相比微不足道 ;-) JuliasTravels (讨论) 2014年1月22日 22:13 (UTC)

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

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

Powers 的观点很有趣。如果我用英式英语编辑，我的浏览器会给一些单词加上漂亮的红色下划线。虽然这对我来说不是问题，但我禁不住觉得这会不利于 ESL 贡献者。Andrewssi2 (讨论) 2014年1月23日 01:03 (UTC)

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

是的，我知道我应该说浏览器 ;) - Firefox 自 2.0 版本以来就具备拼写检查功能——我已经安装并选择了正确的词典，拼写检查也已选中，并且语言也选择了正确的。有独立的词典，如英语/美国、英语/英国等——很高兴“唤醒沉睡者”_沙丘 - 新年快乐！- Matroc (讨论) 2014年1月23日 06:39 (UTC)

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

模板可以指向任何东西，但我会说这种通用的外部链接（确实有几个，针对不同的浏览器）不应该出现在每个讨论页上。当广泛编辑特定文章时，一个人可能会改变它，但我们很难要求编辑者为他们所做的每一个微小修改都不断更换词典。我想我宁愿不在讨论页上大费周章，而是在人们过多使用“非偏好”版本时，将其引向相关的政策页面和讨论。但也许您应该说明您在这样的模板中设想什么样的文本，这样我们才能讨论相同的事情？JuliasTravels (讨论) 2014年1月23日 08:22 (UTC)

我想现在很明显，并没有大量的WV用户在呼吁这项功能，所以我想我暂时就此打住，不再提了。 :) Andrewssi2 (讨论) 2014年1月23日 09:32 (UTC)

许多列表使用了错误的模板（例如，“看”是“吃”）

大家好，

我注意到许多列表都使用了错误的模板，例如餐馆使用了{{See}}。有没有任何情况下这是有意的？有没有任何情况下，“吃”类中的列表故意不使用{{Eat}}，或者{{Eat}}不在“吃”类中？

谢谢！ Nicolas1981 (讨论) 2014年1月23日 04:15 (UTC)

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

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

并非所有列表都已采用模板形式，许多仍然使用星号 (*) 列表。 http://tools.wmflabs.org/catscan2/catscan2.php 可以帮助我们找到那些仍然没有“看”、“做”、“吃”和“睡”模板列表的文章（或至少缩小范围）。 Andrewssi2 (讨论) 2014年1月23日 07:00 (UTC)

谢谢！我猜所有尚未充分开发的文章都会是假阳性。 Nicolas1981 (讨论) 2014年1月24日 08:41 (UTC)

我认为咖啡馆被列在“看”列表中的可能性很小，但并非没有。我想到的是一个大型付费景点，比如主题公园或动物园，里面有吃饭的地方。因为要付费才能进入公园，所以它们可能不应该出现在主要的“吃”部分，但我们可能希望在地图上显示一个“吃”的符号，并在公园部分提及它们。 AlasdairW (讨论) 2014年1月24日 23:51 (UTC)

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

另一次远征？救援远征？

我不知道这以前是否讨论过，但万一讨论过，我怀疑它是否得到解决。有时我们重要的文章（特别是那些处于“指南”状态且以前在主页上 featured 的文章）变得过时且不如以前发达，但这是否足够且是一个好的决定，将它们从“指南”状态文章中降级？绝不是！如果一篇 featured 的“指南”状态文章过时，该文章必须得到改进和妥善处理，而不是简单地降级。事实上，featured 文章不应该被降级，毕竟，曾经为此付出了很多努力。

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

所以，我不知道我们是否需要另一次远征来解决这个非常重要的问题。毕竟，我们维基上已经有很多远征，而且大多数都相当不活跃。因此，如果我们对启动这样的远征有良好的支持，或者我们有其他解决方案，那将是极好的，我作为一名地图制作者，我准备尽我的职责。这是我唯一能做的。我没有去过那些文章被降级的地方，除了迪拜，所以我不知道该添加什么内容来挽救一篇文章，我也不擅长格式化和改进风格。最后，我想说 挽救一篇文章——挽救WV的标准。 --Saqib (讨论) 2014年1月25日 17:33 (UTC)

我支持这项努力。我不知道我在收集最新信息方面能有多大用处，但我肯定能在风格和格式问题上出一份力。 -- AndreCarrotflower (讨论) 2014年1月25日 18:08 (UTC)

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

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

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

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

它被我们的一位管理员User:ClausHansen降级了，尽管这篇文章及其区划文章都相当详细，但自2010年9月以来它们并没有太大变化，所以最好是让最了解这个地方的人审查这些文章，然后决定是保持可用状态还是重新升级为指南。 --Saqib (讨论) 2014年1月26日 00:02 (UTC)

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

我不敢肯定所有这些都被降级了，Saqib。早些年，对特色文章的要求和现在不一样。我想其中一些文章一开始就没有达到我们现在所说的指南状态 ;-) JuliasTravels (讨论) 2014年1月25日 22:21 (UTC)

茱莉亚。你说得对。同样的事情目前也发生在意大利WV上，例如。他们当前的DotM在英文WV标准下处于大纲状态。而且，即使文章以前在主页上被推荐过但没有达到指南状态，我认为我们也应该努力使它们达到指南状态，否则，如果我们无法将以前被推荐的文章恢复到指南状态，就简单地从该文章中删除被推荐图标。事实上，维基百科也这样做。如果文章过时，他们就简单地降级文章（曾经是被推荐文章），并删除文章右上角出现的被推荐文章图标。维基百科不妥协质量，我们为什么要妥协？ --Saqib (讨论) 2014年1月25日 22:38 (UTC)

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

好的，但我们的指南文章可以与维基百科的“优良文章”相比较吗？他们也会降级他们的优良文章并移除图标。无论如何，我也不赞成将我们以前推荐的文章的图标移除。我提出这个问题是为了挽救那些文章，而不是为了移除图标。我希望能提供一个解决方案，并解决这个问题。 --Saqib (讨论) 2014年1月25日 23:02 (UTC)

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

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

所以我们大部分拥有的，是曾经在主页上被推荐过但不是指南质量的文章。我认为萨基布说得非常对，其中许多文章由于以前被推荐过而应该得到某种优先关注，但其他一些文章也是如此，例如“访问量最大的目的地”、“我们网站上最常请求的文章”等等。我并不反对远征，我只是认为我们都知道要保持远征的活跃是多么困难，尤其是在内容方面。只是头脑风暴……制定一个更广泛的“高优先级”文章列表/远征，这些文章需要完善，这会是一个好主意吗？比如访问量最大的、以前的特色文章、使整个区域可用的一些关键文章等等？如果范围更广一些，人们可能会更容易加入。我们也可以从中挑选一个月的合作项目。只是一个想法。 JuliasTravels (讨论) 2014年1月26日 12:18 (UTC)

我也担心远征可能会消亡。也许复兴CotM会是个好主意，与其提名，不如简单地列出以前被推荐过但现在处于可用状态的文章，并像我们以前那样处理它们。请参阅Wikivoyage_talk:Collaboration_of_the_month#Outdated.2C_again。 --Saqib (讨论) 2014年1月26日 15:12 (UTC)

正如我所预期的，这次讨论无果而终。我想一开始提出这个问题就是浪费时间。无论如何。Andrew，这个页面说“维基百科上的特色文章是WV上的星级文章或当月目的地”，没有提到维基百科的优良文章，但你上面说我们的星级文章类似于维基百科的优良文章。我认为最好先解决这个问题。维基百科的特色文章是他们最好的作品，而我们的星级文章是WV最好的作品。如果我们的星级文章类似于维基百科的优良文章，那就意味着我们最好的作品类似于维基百科的（非最好）作品。混淆！ --Saqib (讨论) 2014年2月3日 12:45 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Saqib，我认为你主动提出帮助绘制静态地图真是太棒了。尽管我们的新动态地图为在线用户提供了许多优势（而且 {{mapmask}} 的开发可能会将其用处扩展到显示我们自己创建的区划和区域），但对于那些想要纸质副本（当然还有那些离线用户）的读者来说，它们可能总是逊色。

我离开了一段时间，所以我想借此机会评论一下，看到你的管理员工具因与滥用管理员工具无关的“违规”而被移除，我感到非常遗憾。最终，我们的公共可见性将随着搜索引擎的增加而提高（即使我们一直因为缺乏主动的搜索引擎优化而自作自受），届时将需要“全体动员”来阻止垃圾邮件机器人的泛滥。在我离开的这段时间里，我查看“最近更改”时，已经注意到垃圾邮件机器人账户的数量有所增加。

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

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

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

这场讨论即将结束，所以我想在这里提供一个更新。迪拜的文章已经得到挽救，现在可能已恢复到指南状态。 --Saqib (讨论) 2014年1月28日 13:11 (UTC)

特色文章的指示符

关于一个相关问题：当一篇文章以某种方式被推荐时，是否有可能在跨语言链接列表中添加一颗星——根据每个语言版本的传统，可以是星级、当月目的地或指南状态？基本上，是两个问题合二为一：i) 如何实现？ii) 我们需要这种机制吗？它可能会促进优质内容的翻译…… --Alexander (讨论) 2014年1月26日 08:55 (UTC)

非常好的主意。我不是图形设计专家，但一个简单的指示方法是使用一个由公认的两个字母语言缩写组成的符号，例如俄语维基导游的以前的特色文章使用“RU”。 Ikan Kekek (讨论) 2014年1月26日 13:39 (UTC)

请原谅我，我没明白。亚历山大，你是说如果一篇文章在其他WV语言版本中是星级、当月目的地或指南状态，我们就应该在该文章的右上角添加一个图标（星级、当月目的地或指南状态）吗？或者你是建议我们，如果同一篇文章在其他WV版本中是特色、星级或指南，但在本WV版本中是提纲或可用状态，我们就添加一个图标吗？ --Saqib (讨论) 2014年1月26日 14:49 (UTC)

我指的是维基百科中的相同系统。我们在左侧面板中有一个跨语言链接列表。如果一篇文章被收录，例如在波兰语维基导游中，那么在所有其他语言中，该“波兰语”链接旁边都会有一个星号。 --Alexander (讨论) 2014年1月26日 14:54 (UTC)

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

我不记得在维基百科上看到过这种指示。如果有人能发布相关文章的链接，那将很有帮助。 Ikan Kekek (讨论) 2014年1月26日 15:09 (UTC)

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

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

维基百科上关于特色和优良文章的大部分指示都出现在创建者用户页面的右上角，而且它们几乎每次都看起来一团糟，但是如果它像 Ypsilon 所指出的那样是一个不显眼的标记——应该鼓励和使用——不碍眼但信息丰富。 sats (讨论) 2014年1月26日 15:30 (UTC)

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

这更多是关于 Common.css 的更改。模板本身不是必需的，因为我们已经有星级和当月目的地反映在{{pagebanner}}中。问题是这种针对特色文章的特殊“id”是否能在维基导游中发挥作用。必须尝试一下…… --Alexander (讨论) 2014年1月26日 15:50 (UTC)

谢谢你的链接，Ypsilon。似乎只要像维基百科文章那样在侧边栏添加星号符号就行了。但如果我们要显示文章曾在其他语言版本的主页上被推荐，则需要使用不同的符号。 Ikan Kekek (讨论) 2014年1月26日 16:00 (UTC)

月桂花环怎么样，用来表示这篇文章在某种程度上被这种语言版本特别认可了。 Nicolas1981 (讨论) 2014年1月26日 16:25 (UTC)

我看到了一个主要问题。维基百科的特色文章机制要求在每个语言版本中都添加相应的模板。当然，这从未发生过。需要通过 Wikidata 实现…… --Alexander (讨论) 2014年1月26日 16:32 (UTC)

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

我们的横幅正在被维基导游以外的项目重复使用 :-)

我们的横幅正在被其他项目很好地利用 :-)

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

有了 Wikidata，您的贡献惠及更多人，甚至是以您在贡献时从未想象过的方式。 Nicolas1981 (讨论) 2014年1月26日 16:13 (UTC)

每篇文章再加一张图片？

Wikidata 为每个城市/地点都有一个“图片”字段。例如，维基百科信息框使用该图片，请参阅https://en.wikipedia.org/wiki/Cambridge右上角的图片。这些图片总是展示城市的美景或其最著名的地标之一，在晴朗的天气下。

在维基导游中重新使用这张图片怎么样？

也许我们1%的文章有足够多（甚至太多）的图片，但我们99%的文章迫切需要更多的图片。

所以：缺点是我们将不得不为少数几篇文章进行调整，但我认为收益如此巨大，非常值得。

你对此有什么看法？ Nicolas1981 (讨论) 2014年1月27日 02:50 (UTC)

我一直对此保持沉默，但对于 Wikidata 在越来越多的用户中催生的一刀切、流水线式的内容处理方法，我持非常怀疑的态度。我们已经使用 Wikidata 来标准化所有语言版本中用于同一目的地的页面横幅的选择，似乎没有停下来考虑 en: 因此抢先讨论了所有其他语言版本，如果这些讨论发生，很可能就会就使用哪张图片达成不同的共识。我们谈论将列表移动到 Wikidata，似乎没有停下来考虑某些景点可能与某些语言社区相关，而与另一些社区无关。我们还在谈论标准化跨语言版本的章节图片，似乎没有考虑其他 Wikivoyage 社区可能更喜欢不同的替代方案。

我说“似乎”是因为，尽管我没有听说有任何迹象表明 MediaWiki 中存在一种机制，允许个别社区如果愿意的话可以偏离 Wikidata 上的预设选择，但这并不意味着不存在。如果我错了，我为此道歉并收回此声明。

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

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

AndreCarrotflower，写得和分析得太棒了！好极了！ --150.101.89.130 2014年1月27日 08:55 (UTC)

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

作为 Wikidata 的管理员和监督员，我当然支持在有效的情况下使用其数据。

然而，我并不确信这种特定用途是有效的；一方面，我不确定它在实施层面是否可行。 --Rschen7754 2014年1月27日 03:57 (UTC)

与其使用图片，不如我们看看那些不具主观性，并且在不同语言和社区之间同样适用的数据？

气候数据怎么样？将一个地区的月降雨量、温度和湿度水平集中到维基数据（Wikidata）中，这是否是一个引人注目的用例？Andrewssi2 (讨论) 2014年1月27日 (一) 04:32 (UTC)

这真是一个好主意！Ikan Kekek (讨论) 2014年1月27日 (一) 05:03 (UTC)

我甚至不会说我反对将维基数据用于更主观的事物，前提是在每个单独的实例中都有一个简单的选择退出方式。我记得几个月前，维基数据的一个小故障导致锡拉丘兹（意大利）的页面横幅被用于锡拉丘兹（纽约）。这个问题很容易就修复了，但遗留的问题是，如果有人偶然发现了一张完美的图片可以用作这些文章的新页面横幅，并能在不经过繁琐、缓慢的跨维基官僚程序的情况下将其放置到位，我至今仍未弄明白如何做到这一点。--AndreCarrotflower (讨论) 2014年1月27日 (一) 06:15 (UTC)

我们都在努力为这里的所有文章制作美食。但这需要几年时间。在此期间，我们能否确保所有目的地至少都令人满意？

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

可实施性：今天已在法文维基百科上实施。

编辑战：en.wv成员之间可能会出现更多争议，他们试图找到20,000张新的合适图片，而不是从维基数据（Wikidata）已有的精选图片集中开始。

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

“en: 正在抢先”：据我所见，其他语言乐于合作，并且在不适用时简单地覆盖维基数据的值（是的，选择退出很容易）。

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

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

这确实是一个有力的反驳！我不知道这种蒙太奇在维基百科上是否可以，我能找到的最接近的政策是https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Collages_and_montages，它说“如果图库能和拼贴画或蒙太奇一样好用，应优先选择图库”。事实上，我可以写一个小算法来识别图像是否是蒙太奇 :-) Nicolas1981 (讨论) 2014年1月27日 (一) 16:14 (UTC)

没有主图的页面通常意味着内容也很少，因此在此类文章上添加图片并不那么重要。通常，内容丰富的文章会有人（很可能是添加内容的人）上传图片，或者在文章内容足够丰富时，会有人搜索图片。文章内容很少或没有内容，如果缺少图片，我并不会介意。我喜欢图片自然而然地添加。没有图片也能激励贡献者上传他们自己的新图片。ChubbyWimbus (讨论) 2014年1月27日 (一) 16:40 (UTC)

我同意LtPowers、ChubbyWimbus和其他人的担忧。我认为这里采用个人化、有机化的方法更好。我们空洞的文章并不会因为向读者展示他们点击维基百科时会看到的相同主图而真正受益，因为他们最终必然会去维基百科寻找实际信息。Texugo (讨论) 2014年1月27日 (一) 17:59 (UTC)

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

你有没有注意到，在相当多的国家或“可与国家相媲美”的文章（如泽西岛）中，“看”或“做”部分，或两者都为空白，尤其是在那些游客不多的地方。我认为这些是最重要的部分，所以它们为空白（特别是“看”）很可惜。召集一次远征可能有点过分，但如果你发现这样的文章，请随意用几句话填充这些部分。如果该国拥有联合国教科文组织世界遗产，那么这些地点是显而易见的选择。你当然也可以点击城市和其他目的地，看看它们的“看”和“做”部分是否有任何值得在国家文章中提及的有趣内容。ϒpsilon (讨论) 2014年1月27日 (一) 05:35 (UTC)

这确实是一个内容优先事项！一些人（包括我）一直在积极地致力于国家“看”部分，作为Wikivoyage:国家外科医生远征的一部分。不幸的是，尽管几乎所有人都认为这很重要，并且很多人都报名参加了，但只有少数人找到了时间真正贡献。然后又发生了太多与搬迁相关的事情。很高兴你重新引起了人们的注意 :-) JuliasTravels (讨论) 2014年1月27日 (一) 10:20 (UTC)

动态地图问题

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

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

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

这是一个严重的问题。我想先给他们一个机会，在没有任何压力的情况下解决问题，尽管之后我们需要讨论动态地图的技术支持以及如何解决稳定性问题。Andrewssi2 (讨论) 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 (讨论) 2014年1月27日 (一) 07:33 (UTC)

在法语维基导游中似乎工作正常。我已向这里的地图团队提出此问题。Andrewssi2 (讨论) 2014年1月29日 (三) 05:26 (UTC)

生日和祝贺

昨天我们庆祝了7岁生日。2006年12月10日，我们启动了德语分站的维基导游。一年后，意大利语分站也启动了。我们还收到了谷歌送出的一份不错的生日礼物：维基导游中心主页的PageRank现在是7，英语主页的PageRank是6。如果这还不足以让我们保持积极思考的话。--RolandUnger (讨论) 2013年12月11日 (三) 09:36 (UTC)

恭喜，干得好。--Saqib (讨论) 2013年12月11日 (三) 09:51 (UTC)

好消息！祝贺，并非常感谢德国社区发起这个项目！--Alexander (讨论) 2013年12月11日 (三) 09:55 (UTC)

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

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

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

4x4 缩写

看起来我们在“voyage”中对于4WD和4X4（以及它们大小写不同的变体，如4wd，4x4等）的使用存在分歧——为了保持一致性，是否有任何迹象表明为什么其中一个会胜过另一个？或者它就像现在这样——大约50/50？

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

只希望其中一种用法有充分的理由 sats (讨论) 2014年1月27日 (一) 06:12 (UTC)

雷诺B90 4x4

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

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

2) 当你注意到的情况下，大小写反转时，它不那么明显

3) 很容易就能写出“2x4车辆在旱季也能成功通过这条路……”这样的句子。--150.101.89.130 2014年1月27日 (一) 08:42 (UTC)

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

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

• 四驱车(4x4)指车辆的通用类别。第一个数字通常是总车轮数（更准确地说，是车轴末端，可能有多只车轮），第二个数字是提供动力的车轮数。
• 四轮驱动(4WD)指前桥和后桥之间有分动箱而非差速器的车辆，这意味着在接合时，前后传动轴将被锁定在一起。

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

我对汽车了解得中等。我认为上面引用的维基百科文本有严重错误。

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

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

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

这一个月来没有任何进展，有什么进一步的建议吗？因为“voyage”仍然存在这两种用法，没有达成共识或商定的解决方案，而且如果你看这个问题，这种不一致性很明显……sats (讨论) 2014年3月1日 (六) 10:57 (UTC)

共识建立过程的变更

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

版权问题！

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

谢谢Nick，不过我觉得处理版权侵权问题的协议应该相当简单明了？你在此论坛重新发帖的目的是什么？Andrewssi2 (讨论) 2014年2月5日 (三) 02:40 (UTC)

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

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

首先，尽管（大部分是基本）信息是可比的，但我并没有轻易找到很多逐字文本，但我应该进一步查找。这里奇怪的部分是，指出这个版权问题的用户大约一年前亲自编写了大部分文章。我不确定他/她是否被TA告知停止也在其他地方发布内容（这值得怀疑，因为他们的使用条款包含非排他性许可），或者他/她忘记了是他们自己写的……我也会在她的讨论页上询问，但在我看来，这个用户已经声明并拥有（共同）所有权，并在我们的cc许可下上传了内容？JuliasTravels (讨论) 2014年2月5日 (三) 10:06 (UTC)

大家好，我认为这是我的错误。我发帖时很累，没有意识到我才是最初编写几乎所有文本的人，所以我错误地认为它是从我和朋友几年前编写的TripAdvisor文章中复制过来的。我会再检查一遍，但可能一切都很好。很抱歉不必要地引起了警报。Invertzoo (讨论) 2014年2月5日 (三) 14:23 (UTC)

没问题，很高兴这些信息能保留下来，非常感谢您的贡献！现在尼维斯岛受到了关注，也许我们优秀的横幅设计者能制作一个色彩更丰富的横幅？ :-) 很难找到合适的图片，我们拥有的图片大多来自圣基茨，但Commons上有一些，我还在那里添加了一张我从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让维基导游变得真正有价值，值得进一步扩展！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) (我的实际回答将很快发出。)

谢谢你的主意，亚历山大。可惜似乎没起作用。希望乔阿希姆能有解决方案，否则我就得重新编号了，那样在地图上看起来可能会有点别扭。ϒpsilon (讨论) 2014年2月3日 (一) 18:01 (UTC)

无法操纵标记编号。我认为由于脚本的一些更改，亚历山大的提议不幸不再适用。- 我建议为次要线路选择不同颜色的标记。您可以使用以下类型：。除了type=listing (other.png)之外，每个新部分中的编号都将从1开始。-- Joachim Mey2008 (讨论) 2014年2月3日 (一) 18:28 (UTC)

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

与此同时，也许有一个解决另一个困境的方法——有时在同一地点有两个或三个不同的POI。例如，有一个历史宫殿或城堡（观光），其中有一个不相关的博物馆（活动，或另一个观光），例如自然历史博物馆，值得单独列为POI，同一建筑中还有一家好餐馆（用餐），有时甚至还有一家酒店（住宿）。铁路车站也是如此，它们兼作购物中心，还有游客信息点。在文章的不同地方分别提及它们是值得的，但在地图上创建多个重叠的标记只会让它更难以辨认。是否有可能在文章中再次调用已经放置的标记，以显示相同的数字和符号？PrinceGloria (讨论) 2014年2月3日 (一) 18:57 (UTC)

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

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

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

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

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

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

巡查

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

嗯。我这里看起来正常。你标记时，有没有收到一个小的 JavaScript 弹窗，说它已经被标记为已巡查？如果没有，我想可能是你的浏览器有 JavaScript 问题。Texugo (talk) 2014年2月5日 14:22 (UTC)

它对单个编辑有效，但似乎无法一键标记多个编辑为已巡查，是这样吗？--ClausHansen (talk) 2014年2月5日 16:40 (UTC)

请参阅Wikivoyage talk:Recent changes patrol#Patrolling problem。这个问题有一个 bugzilla 报告开放——为该 bug 投票可能有助于更快解决。-- Ryan • (talk) • 2014年2月5日 16:47 (UTC)

寻找有用的事做？

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

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

你好，Nicholas，我知道我们无法直接访问 WV 数据库，但在商业世界中，这种方法被称为数据清理活动。此类策略试图通过简单算法自动修复 95% 的问题，其余的“遗留问题”可以手动完成。

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

我不熟悉这个 API，但如果你觉得这是一个值得尝试的策略，我很乐意学习。Andrewssi2 (talk) 2014年2月7日 06:58 (UTC)

我用这个列表修复了一些条目。-- WOSlinker (talk) 2014年2月8日 09:11 (UTC)

这大大低估了——我注意到了你做出的许多出色的（非内容）编辑——如此谦虚的你一定是英国人！--118.93nzp (talk) 2014年2月8日 09:49 (UTC)

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

如何发展维基导游

大家好，我一直在关注各种举措，比如搜索远征页面和各种发展文章的项目，以及Nick 开始的上述讨论。我想发起一个开放的对话，讨论发展维基导游的想法：获得更多编辑者，提高文章质量，提升我们在搜索排名中的知名度等。我既作为社区成员/编辑者，也作为维基媒体基金会理事会成员提出，我对我们所有项目的健康状况都感兴趣；我们都希望这个项目取得成功。分享你的想法！谢谢，-- Phoebe (talk) 2014年2月7日 22:19 (UTC)

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

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

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

旅游局远征旨在与世界各地的旅游局联络，并让他们参与本网站指南的创建和宣传。虽然我们取得了一些成功（我只能谈我熟悉的案例，但曼彻斯特旅游局似乎真诚地感兴趣并给我发了几封电子邮件，而伦敦/伦敦金融城旅游局积极进行编辑），但我们一直受到低阅读量和不可靠（且令人失望？）的统计数据所阻碍，这些数据是吸引这些重要合作伙伴所必需的。这有点像一个恶性循环。

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

最后，我们还认为，简单地改进内容是提高读者群的一种方式。这（我们希望）将我们与其他基于维基的旅行指南区分开来（这对于 SEO 很重要），但也有望使我们成为一个对旅行者来说更好的网站——质量将胜出！我们为此目的开展了许多远征、横幅远征和机场远征，但不幸的是（恶性循环又来了），我们没有足够的编辑者来同时保持几个项目高效运行，所以它们往往是波浪式推进。

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

感谢联系！:) --Nick ^talk 2014年2月8日 02:51 (UTC)

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

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

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

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

你可能（及时地）能做的另一个联系是与分会建立联系。就联系旅游局而言，我认为如果有任何分会感兴趣，他们将处于有利地位。然而，正如 Nick 所说，只有当我们更具知名度时，他们才会有兴趣与我们合作。无论如何，你对此感兴趣，真是太好了。JuliasTravels (talk) 2014年2月9日 20:27 (UTC)

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

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

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

如果能找到要添加链接的模板，维基数据可以使这变得非常容易。信息框在技术上是完美的，但也许它不是最好的位置。提醒一下，这里有一些似乎有效的方法

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

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

报纸

一些非英语为主的国家，仍然有本地出版的（而非像《国际先驱论坛报》那样的外国出版物）英语全国性报纸。在国家文章中提及它们是否无益，如果不是，应该在哪里提及——在“联系”部分吗？

一些例子

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

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

是的，这正是我没有提及这个政府喉舌的原因。你认为修改Wikivoyage:国家文章模板#联系会是个好主意吗？--118.93nzp (talk) 2014年2月8日 04:34 (UTC)

我还是会提到它。《星报》是，或者至少曾经与马华公会（主要的华人执政联盟伙伴）有关。任何时候你处理一个非自由民主国家，更不用说一个专制政权，你都可以指望所有或至少大多数大众发行报纸公开或默许地成为政府的喉舌。在马来西亚的例子中，伊斯兰党反对党有一份英文报纸，所以如果你愿意，可以包括它们，但我不会采用政治试金石来排除政府喉舌。Ikan Kekek (talk) 2014年2月8日 04:44 (UTC)

嗯，那只是一个说明性的列表，并非详尽或确定的。哪些被列出或不被列出，将由编辑者之间的通常互动来决定。我只是想知道是否有一些普遍的情绪不提及报纸或广播电台，这些可能对来访的旅行者有趣或有益——或者在他们访问之前评估一般的犯罪水平/地点或最新进展（如果它们也有在线存在的话）…… --118.93nzp (talk) 2014年2月8日 05:20 (UTC)

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

我也认为这是个好主意。我旅行时经常寻找英文报纸，知道有没有很有用。-- Phoebe (talk) 2014年2月8日 06:01 (UTC)

那么，是在“连接”部分——还是在其他地方？--118.93nzp (talk) 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)

那么，功劳归他所有，但你是否同意我对将大众媒体信息放在“应对”而不是“连接”部分的理解？Ikan Kekek (talk) 2014年2月8日 07:43 (UTC)

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

@LtPowers:

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

Wikivoyage:可以放置的地方#N中的建议对于地方或城市媒体来说是明确的，但我的问题具体涉及国家或区域层面。Wikivoyage:国家文章模板目前没有“应对”部分（而且Wikivoyage:区域文章模板目前既没有“应对”部分也没有“连接”部分）——你是否建议我们创建一个，只为这类事情？--118.93nzp (talk) 2014年2月8日 08:25 (UTC)

“连接”最初是“联系”，它确实表示个人通讯。后来改名，因为它倾向于充满“联系当地旅游局获取旅行信息”，这并非其初衷。

这里有一个更广泛的问题，即如何处理不属于当地多数语言但可能对同语系旅行者有用的当地实体，这些实体不属于旅游食品/住宿/景点类别。例如，文化中心或外籍社区；“le Centre Frontenac”在fr:Kingston (安大略)的“理解”（Comprendre）下，因为它可能成为该语言维基导游用户的有效法语信息来源，尽管它主要服务于当地的法语少数群体。K7L (talk) 2014年2月8日 18:19 (UTC)

确实；我不知道为什么报纸被放在应对部分，但它们确实被放在了那里。我可以推测，这是因为人们转向报纸来获取新闻、查看天气预报，并通常进行日常生活，而不是作为一种与人交流的方式。你可以在Wikivoyage talk:可以放置的地方#臃肿的理解中阅读最初的讨论，其中报纸似乎在 cacahuate 建议将它们移到应对部分之前，一直都在理解部分。国家级文章确实通常不需要应对部分（尽管我可以看到一些反驳意见）；对于全国性报纸，我建议要么创建一个应对部分（根据Wikivoyage:文章模板/部分允许），要么使用理解或联系部分。Powers ^(talk) 2014年2月8日 18:36 (UTC)

那是个错别字吗 @LtPowers:？你的意思是说我建议要么创建一个应对部分（根据Wikivoyage:文章模板/部分允许），要么使用理解或连接（我添加了下划线以示清晰）吗？--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)

国家文章中的领事馆

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

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

我特别想到的是那些首都相对较小或新建的国家，而大多数领事馆仍留在较大的或旧的城市（例如，仰光仍然有缅甸的领事设施，而不是新的、小得多的首都内比都）...... --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链接。

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

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

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

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

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

你的这份清单很棒，如果我没有去兑现我对 User:Wrh2 的承诺，它会让我忙上好几个月…… --118.93nzp (讨论) 2014年2月9日 (世界标准时间) 03:25

@118.93nzp 我反而觉得你应该抓住这个绝佳的机会，从政治中抽身出来，专注于 100% 的列表编辑工作  :-) 解决 无效电子邮件 和 错误的“*”字符 的积压问题怎么样？这两个问题无法自动化解决，所以修复它们将是一项重大成就！ Nicolas1981 (讨论) 2014年2月10日 (世界标准时间) 02:19

尼古拉斯，这是一个诱人的建议。

你能不能首先修复列表机制，以便它向我们的读者显示 phoneextra 字段中的所有内容？

例如这一节：目前，意大利名誉领事代理塞尔吉奥·贾恩·萨利斯博士的额外联系电话 +64 3 477-3123 未显示，而是“隐藏”在我们的代码中。 --118.93nzp (讨论) 2014年2月10日 (世界标准时间) 04:56

我会尝试处理 phoneextra！但这不妨碍你从电子邮件和星标开始  :-) Nicolas1981 (讨论) 2014年2月10日 (世界标准时间) 07:31

不，我眼睛里已经看到太多浮动的星号了，电子邮件地址检查起来太麻烦了。我只对电话号码有点兴趣，而且作为 IP 用户，我可以轻松地完成，不需要太多争论。 --118.93nzp (讨论) 2014年2月10日 (世界标准时间) 07:42

电话号码？就像你想要的：User:Nicolas1981/Syntax_checks/Page2 期待你的精彩表现  :-) Nicolas1981 (讨论) 2014年2月13日 (世界标准时间) 08:10

我认为使用现有模板参数来处理多个电话号码和电子邮件地址不应该特别困难

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

其实不应该需要多个电子邮件地址，如果有，那意味着你只能点击一个电子邮件地址发送邮件，因为你还需要向另一个地址发送邮件，这样就变成了复制粘贴电子邮件地址，而不是简单地点击它们。可以创建一个 Lua 模块，它计算 @ 的数量，如果不是 1，则将页面添加到跟踪类别。-- WOSlinker (讨论) 2014年2月11日 (世界标准时间) 07:31

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

列出多个电子邮件地址的真正需求是什么？在大多数情况下，列出多个电话号码已经是不必要的冗余了。我不想在没有证明其真正需求的情况下促进更多这样的事情。Texugo (讨论) 2014年2月13日 (世界标准时间) 10:19

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

2014 年维基年会上的维基导游

今年我计划参加在伦敦举行的维基年会，并希望能做一个关于维基导游的演讲。Stefan 说他今年无法参加维基年会，但他会帮助我们准备演讲。Dr 也会参加会议并同意做演讲，我想 Nick 也可能会加入我们。还有其他人计划今年参加维基年会吗？欢迎提出任何想法和建议！ --Saqib (讨论) 2014年2月11日 (世界标准时间) 13:13

看到 Nick 最近给我们指出的 去年的视频 很有趣。我觉得观众提出的第一个问题基本上是“为什么是维基导游？”这一点很重要。

一份有助于在维基媒体组织内部更好地宣传我们目标的演讲会很棒。理想情况下，我们希望维基百科用户在会议结束后开始为 WV 做出贡献。（我没有观察到香港之后发生这种情况） Andrewssi2 (讨论) 2014年2月12日 (世界标准时间) 02:43

我乐于听取社区的建议，我们可以改变演讲的主题。我最近写了 Wikivoyage:About#Why Wikivoyage。你注意到了吗？ --Saqib (讨论) 2014年2月12日 (世界标准时间) 08:34

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

我们确实会不时遇到维基百科的人，例如 User:Sbmeirow，他显然在维基编辑方面经验丰富，可以提供很大的帮助。我只希望看到一张幻灯片形式的维基导游“广告”，以鼓励更多像他这样的人来查看并可能做出贡献。Andrewssi2 (讨论) 2014年2月12日 (世界标准时间) 09:02

萨奇布是对的。不幸的是，我无法参加。RolandUnger 将会参加。但是，当然，我将协助制作演示文稿。-- DerFussi 2014年2月12日 (世界标准时间) 12:51

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

你参加真是太好了。我认为最好的主意是起草一份你的演讲提案，让大家评论和补充。我还认为在你确定主题和内容之前，你应该决定你的目标是什么以及你想激励哪类受众。如果你想吸引维基百科用户，你需要另一个演讲，而不是针对那些对维基导游一无所知的第三方受众。请记住，去年维基导游是全新的，但现在我们是其中一个项目，许多维基百科用户大致知道我们是做什么的，并且可能已经看过一两次。我想他们需要的是说服而不是演讲。但再说一遍，我不确定你想达到什么目的 :-) JuliasTravels (讨论) 2014年2月15日 (世界标准时间) 17:09

坦白说，朱莉娅，起初我真的不想做这个演示，所以我第一次和斯特凡谈了谈，问他今年是否还会做演示，但他说他没有计划参加会议，更不用说演示了。然后，我与 User:Andyrom75（去年的与会者）谈了谈，问他今年是否还会参加会议，但他也说不会。然后我与尼克谈了谈，尼克说他不确定今年是否能参加维基年会，然后我决定做演示，因为我认为在如此重要的场合，演示是我们绝对需要的，而且至少要继续下去，直到 WV 社区发展起来。我很高兴 Dr. 同意做演示，我仍然希望尼克或其他人能出现，而我成为观众。坦白说，我对此类事情感到害羞。现在回到话题，起初我脑子里想的是做一次关于项目进展的演示，正如我在 提案页面 中所说的那样，但在安德鲁的留言之后，我认为这不是一个好主意，只是浪费了一个好机会，所以我决定将演示的主题/主题更改为更侧重于在维基媒体社区中宣传 WV 的内容。维基年会将在八月举行，所以我们有很长一段时间来开始准备演示，但我只是想确保社区是否同意我提出的演示主题和主题，或者其他什么，以便我们相应地制定我们的提案，因为提交提案的截止日期是 3 月 31 日。现在回答你的问题，我的目标是什么：显然我的受众是维基百科用户，目标是鼓励和激励更多新编辑加入 WV。你说“他们需要说服而不是演示”，你是在建议我们应该与他们安排一次谈话、一次讨论吗？--Saqib (讨论) 2014年2月15日 (世界标准时间) 19:30

根据我去年经验，我可以告诉你不需要创建花哨的东西，因为最基本的需求是让他们知道 voy 存在；事实上，他们大多数人不知道！我在香港注意到最愚蠢的事情是官方手册中免责声明写着：“基于 Wikitravel 文章”  :-DDD 也要考虑到，房间里三分之一的人是为了 voy 演示而来，是我带去的。我希望今年情况有所改变，但可能没有。--Andyrom75 (讨论) 2014年2月15日 (世界标准时间) 20:03

我们为什么不为维基年会创建一个旅行指南呢？它可以是一个简单的传单，在门口分发，简要描述会场和该地区的主要景点。演示文稿不是必需的，你也不应该强迫自己做不舒服的事情。有很多其他方式来代表我们的项目——分发传单是一种方式，与小组交谈是另一种方式。专注于激励你成为维基导游社区一部分的原因。只要你展现出对项目的热情，其他人就会更倾向于加入我们。 Edge3 (讨论) 2014年2月15日 (世界标准时间) 19:57

Edge3，我们已经有一个活动旅行指南了：Wikimania_2014_London_Guidebook，据我所知，原本的设想是以某种形式将其分发给参与者。但我不太确定是否有必要打印出来，因为这意味着大量的纸张和墨水。ϒpsilon (讨论) 2014年2月15日 (世界标准时间) 20:04

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

你可能也想和其他语言的维基导游谈谈，看看他们有什么想法。--Rschen7754 2014年2月16日 (世界标准时间) 00:37

Image: 与 File: 之争

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

Image: 是有效的，并且是 MediaWiki 的原始默认设置。File: 是在大约 MW 1.6 的软件中引入的，其假设是少数文件可能是音频或多媒体，也许是 file:recorded-walking-tour.ogg 或其他什么。由于 WV 文章必须以其打印形式可用，我们目前政策上不将 MP3/OGG 或其他非图像文件附加到我们的目的地，因此我们的所有文件确实都是图像。

是否可以关闭这种不必要的 File: 替换 Image: 的功能？ K7L (讨论) 2014年2月13日 (世界标准时间) 17:36

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

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

基本上和 LtPowers 意见一致；我不认为仅仅为了将 Image 更改为 File 而进行大规模编辑页面是件好事，这会使页面历史变得混乱。--Rschen7754 2014年2月14日 (世界标准时间) 03:28

如果我没记错的话，AWB 将 Image:→File: 的转换视为一个小改动，因此只有在需要进行更实质性的更改（例如修正错别字）时，使用 AWB 的用户才会被提示保存该更改。-- Ryan • (讨论) • 2014年2月14日 (世界标准时间) 04:01

我还要说，这对于新用户来说（轻微地）造成了困惑。关闭“Image”将对整个网站的可用性产生微小的改善。Andrewssi2 (讨论) 2014年2月14日 (世界标准时间) 04:05

我确定我们无法关闭它……--Rschen7754 2014年2月14日 (世界标准时间) 08:15

怎么了？这些链接都指向图片。K7L (讨论) 2014年2月14日 (世界标准时间) 04:20

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

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

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

如果世界是完美的！我的脚本远非完美  :-) Nicolas1981 (讨论) 2014年2月18日 (世界标准时间) 12:05

UUTP

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

在一个用户页面上，可见的区别会是什么？只是删除了 [[UUTP]] 的一个实例？ ？ Andrewssi2 (讨论) 2014年2月18日 (世界标准时间) 01:41

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

供参考，此类链接的预期目标是 User:Alice/Kitchen/Using User Talk pages。也许那里的信息可以合并到 Wikivoyage:User page help 中，并且 UUTP 链接可以替换为指向该页面的链接。如果由于更改了其他用户发布的与预期不符的内容而认为不合适，我们应该只将所有 UUTP 链接替换为指向 Alice 的子页面的链接。Powers ^(讨论) 2014年2月18日 (世界标准时间) 02:29

我仍然认为最简单的方法是直接取消链接，但如果有人自愿立即将内容合并到 Wikivoyage:User page help，那我也没意见。我更倾向于尽可能避免第二种选择，因为我认为将 IP 用户和新用户引导到某个用户空间中的非官方页面是不合适的，特别是如果这可能会鼓励 IP 用户或新手将这样一个问题用户视为某种导师。Texugo (讨论) 2014年2月18日 (世界标准时间) 12:13

完全同意 Texugo 的看法。取消链接是答案。如果它不是政策，就不应该以政策的形式呈现给易受影响的新手，更不应该由像 Alice/Frank/118 这样有问题的用户来呈现。 -- AndreCarrotflower (讨论) 2014年2月19日 (世界标准时间) 00:16

可以改为 Special:MyTalk，但由于其中大多数都在用户的讨论页上，这个链接用处不大，所以最好取消链接。-- WOSlinker (讨论) 2014年2月19日 (世界标准时间) 13:54

一项相关的讨论正在 Wikivoyage talk:Using MediaWiki templates#De-linking of redlinked templates 进行。Texugo (讨论) 2014年2月19日 (世界标准时间) 15:06

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

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

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

您可以阅读 公告 和 开发计划 以获取更多信息。对于仅用英语撰写此消息表示歉意。谢谢。Runa

使用条款修正案

大家好，

请就 拟议修正案 加入讨论，该修正案涉及 维基媒体使用条款 中关于未披露的有偿编辑，我们鼓励您在此发表您的看法。如果您能翻译此声明，我们将不胜感激，我们也欢迎您翻译拟议修正案和引言。请参阅 Meta Wiki 上的讨论 以获取更多信息。谢谢！ Slaporte (WMF) 2014年2月21日 (世界标准时间) 22:00

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

我在此发表了评论 这里。我认为提案背后的想法是好的，但以目前的措辞来看，它可能会弊大于利。-- Ryan • (讨论) • 2014年2月23日 (世界标准时间) 16:55

我已将 meta:Talk:Terms of use/Paid contributions amendment#这不只是关于维基百科 作为一个问题提出。维基百科禁止 原创研究，我们不禁止。当地的 CVB 可能会做出建设性的贡献，也可能弊大于利，但我们需要根据其各自的优缺点来处理。K7L (讨论) 2014年2月23日 (世界标准时间) 19:07

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

根据Wikivoyage talk:Phone numbers#Proposed replacement，我已用一个更简单、希望能更直接的表格替换了关于各国家电话号码格式的冗长且不完整的讨论：Wikivoyage:Phone numbers#Country-specific examples。该表格的“示例”列对许多国家来说都是不完整的，因此请为任何您熟悉的国家添加一个正确格式的电话号码示例。示例应以在维基导游中显示的格式呈现，因此它们应包含国家代码，并在可以本地拨打的号码块之间用连字符隔开，例如（在美国）本地号码为“+1 YYY XXX-XXXX”，免费电话号码为“+1-8YY-XXX-XXXX”。谢谢！-- Ryan • (讨论) • 2014年2月24日 (世界标准时间) 02:37

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

我注意到user:Mey2008手动导入了大量单独的坐标到新文章Oswego中，并附有“参见 Mapnik 层”。大概这个“Mapnik 层”是 OSM 的一部分；该项目已经包含了各种兴趣点（地标、酒店、餐厅）的名称和坐标，这些信息都显示在 OSM 的城市地图上。

如果这庞大的地理数据堆已经以某种自由许可存在，是否有可能实现其自动化使用？例如，新文章不是以空白的{{smallcity skeleton}}开头，而是以 OSM 中已有的POI列表作为基础，供Wikivoyage编辑者为每个POI添加描述和详细信息。另一种可能性是，通过自动化过程，将现有的Wikivoyage列表与OSM的POI进行匹配，以获取坐标。

实现这个有多困难？ K7L (讨论) 2014年2月26日 (世界标准时间) 18:00

我无法谈论技术难题，但如果能有POI数据的任何线索（URL等），那将非常有帮助——在更新文章时查找这些数据需要很长时间，所以如果能有更简单的方法获取，我希望能利用它。-- Ryan • (讨论) • 2014年2月26日 (世界标准时间) 18:14

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

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

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

我支持一个能让手动导入列表更简单的工具/方法。也请注意，OSM中的列表可能不再是最新的，甚至可能已不再营业，我们希望阻止不加区分地添加列表。--Andrewssi2 (讨论) 2014年2月27日 (世界标准时间) 00:03

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

约阿希姆，你真是个奇才！ Danapit (讨论) 2014年2月27日 (世界标准时间) 06:44

有趣。我点击“AKKU”，得到了坐标，但没有得到你添加的地址和营业时间。如果我在 nominatim.openstreetmap.org 中查看该 POI，额外的S信息就在那里。有没有办法将{{listing}}（无论哪种语言）作为“复制模板”格式之一，并包含附加到原始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=Fast food}}。通常OSM POI只有名称、类型（“设施”或“旅游”及子类型）和坐标，但我们应该使用现有的。 K7L (讨论) 2014年2月27日 (世界标准时间) 14:08

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

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

正如我之前所说：“OSM数据”功能仍在测试模式中，必须进行优化。我担心的是许可问题（ODbL）。在继续开发之前，必须确保这一点。-- Joachim Mey2008 (讨论) 2014年2月27日 (世界标准时间) 17:13

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

坐标对有可能受版权保护吗？通常，要有一定的创作投入才能符合受版权保护作品的条件。 K7L (讨论) 2014年3月2日 (世界标准时间) 23:53

坐标是使用OSM切片（CC BY-SA 许可证）计算的。这里我看不出有什么问题。我的问题涉及从OSM数据库（ODbL许可证）导入其他数据。-- Joachim Mey2008 (讨论) 2014年3月3日 (世界标准时间) 05:18

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

看起来将OSM POI重用于Wikivoyage是没问题的：https://help.openstreetmap.org/questions/31250/can-i-export-osm-poi-metadata-to-wikivoyage-cc-by-sa-gfdl Nicolas1981 (讨论) 2014年3月4日 (世界标准时间) 09:25

谢谢你提供的链接。我的理解是这并不明确。 Fabimaru (讨论) 2014年3月5日 (世界标准时间) 13:03

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

创建新账户界面的Bug

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

谢谢你提请我们注意，Bcrowell。

我既不是管理员也不是程序员，但我相信很快就会有人（比如@Wrh2:）会来解决这个问题……

感谢您创建Apizaco‎文章！--118.93nzp (讨论) 2014年1月12日 (世界标准时间) 21:55

这可能应该在m:Wikimedia Forum上提出，因为它可能不仅仅影响英文维基导游。--Rschen7754 2014年1月12日 (世界标准时间) 22:40

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

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

这是我的猜测。你现在创建一个账户，这个账户是一个单一用户登录——一个全球维基媒体账户。你不能只在维基导游这里创建一个账户（请看这里，你的El Photon账户是一个SUL账户）。尝试创建一个全球性的“The photon”或“The Photon”账户行不通，因为这两个名字在某些维基上都以非SUL账户的形式存在。你应该去en.wikipedia（或你拥有“The Photon”账户的另一个维基），然后访问名为“Special:MergeAccount”的页面。这将把你的账户设置为SUL，并允许你使用相同的登录信息登录任何维基。 Powers ^(讨论) 2014年3月13日 (世界标准时间) 16:04

维基媒体博客文章

供参考，维基媒体博客今天有一篇关于Saqib的精彩文章。-- Ryan • (讨论) • 2014年2月27日 (世界标准时间) 08:22

+1。Saqib，我知道我有时会成为你的眼中钉（参见最近在dotm上的讨论），但我真心钦佩你不知疲倦的工作。-- AndreCarrotflower (讨论) 2014年2月27日 (世界标准时间) 08:25

太棒了Saqib！感谢你一直以来对WV的宣传！ Andrewssi2 (讨论) 2014年2月27日 (世界标准时间) 12:50

哦，你们找到了。谢谢！--Saqib (讨论) 2014年2月27日 (世界标准时间) 14:34

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

不过，这也引出了一个问题。说英语的当地人是网站的重要资源—他们的知识和视角补充了访问者可以提供的内容，而且他们还可以进行当地语言的翻译。我们有一些优秀的当地人提供了各种地方的信息，但是我们是否应该做些什么来吸引更多人呢？ Pashley (讨论) 2014年2月27日 (世界标准时间) 15:53

太棒了，Saqib！ Danapit (讨论) 2014年2月27日 (世界标准时间) 21:32

Saqib 的文章太棒了！我和一位来自巴基斯坦的朋友下棋，希望有一天能去那里拜访他…… Matroc (讨论) 2014年2月28日 (世界标准时间) 04:04

这篇真是太棒的文章了！很棒的故事，很棒的照片。祝您旅途顺利！ Ikan Kekek (讨论) 2014年2月28日 (世界标准时间) 10:30

谢谢大家。--Saqib (讨论) 2014年2月28日 (世界标准时间) 15:17

Saqib 干得好！在提高巴基斯坦和WV的知名度方面做得非常出色！--尼克 ^讨论 2014年2月28日 (世界标准时间) 23:16

带参考标签的文章

有一些页面包含<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日 (世界标准时间) 22:25

用户不应该使用引用标签；也许我们不应该在措辞中包含它。 Powers ^(讨论) 2014年3月4日 (世界标准时间) 01:18

谢谢您添加了类别。我忘了在类别周围加上includeonly标签。它们也应该被添加。抱歉。-- WOSlinker (讨论) 2014年3月4日 (世界标准时间) 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日 (世界标准时间) 07:19

删除WT归属模板

大家好。我想从User talk:Ikan Kekek删除那个愚蠢的模板，因为所有与我在WT的时间相关的内容都已被存档。我该如何从我的用户讨论页删除该模板？ Ikan Kekek (讨论) 2014年2月27日 (世界标准时间) 12:29

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

删除页面。然后只恢复迁移后完成的编辑。--亚历山大 (讨论) 2014年2月27日 (世界标准时间) 13:00

是的，删除页面并重新创建可以去掉模板。一般来说，这应该在深思熟虑后进行；我们确实有法律和道德义务给予适当的归属。 Pashley (讨论) 2014年2月27日 (世界标准时间) 13:14

[编辑冲突]我必须删除页面吗？所有编辑都是迁移后进行的，每一项都是。较旧的编辑（从我的用户讨论页顶部链接）已被存档。除了我将页面的全部内容复制到一个空白文件，删除页面，然后重新创建页面并将旧页面的内容放回去，就没有更简单的方法了吗？ Ikan Kekek (讨论) 2014年2月27日 (世界标准时间) 13:16

不，谁说过复制粘贴了？您可以选择性地恢复迁移后的编辑。 Powers ^(讨论) 2014年2月27日 (世界标准时间) 14:07

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

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

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

此外，如果WT内容被存档，我们如何处理新创建的存档页面上缺少归属的问题？ Andrewssi2 (讨论) 2014年2月28日 (世界标准时间) 00:36

Ikan，听我说。作为管理员，您有能力在从维基百科删除页面后选择性地恢复特定的编辑。例如，请参阅w:Wikipedia:Selective deletion。无需复制粘贴。 Powers ^(讨论) 2014年2月28日 (世界标准时间) 02:08

我试了一下，结果太复杂了（我第一次尝试没有成功），所以我删除了我的用户讨论页并重新创建了它。然而，WT的归属也因某种原因从User talk:Ikan Kekek/archive中删除了，这并非我的本意，因为它包含迁移前的内容。那么我们现在该怎么办？ Ikan Kekek (讨论) 2014年2月28日 (世界标准时间) 07:47

恢复你的讨论页上所有已删除的编辑，然后将你的讨论页移动到你的存档页，然后你可以编辑你的存档页，只保留你想要的存档内容。-- WOSlinker (讨论) 2014年2月28日 (世界标准时间) 08:05

我不明白。你是说如果我恢复已删除的编辑，WT 归属就会重新出现吗？ Ikan Kekek (讨论) 2014年2月28日 (世界标准时间) 09:11

没用——和撤销删除前一样。 Ikan Kekek (讨论) 2014年2月28日 (世界标准时间) 09:43

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

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

一个更复杂的解决方法是删除您的讨论页面，然后有选择地恢复仅在迁移后发生的那些编辑。不过，我并不能亲身证实这种方法是否有效。

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

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

-- Powers ^(讨论) 2014年2月28日 (世界标准时间) 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日 (世界标准时间) 22:15

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

如果想将WT归属添加到相关的存档页面，我们可以使用一个模板（类似于{{swept}}）来基本达到同样的效果吗？ Andrewssi2 (讨论) 2014年3月1日 (世界标准时间) 06:55

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

更多统计数据

这个网站有大量与维基导游相关的统计数据。很高兴看到我们似乎已达到每月1,000,000次点击量，并且Reddit对我们的社交媒体影响力如此重要（WV账户有用吗？）。尽管如此，它也显示了我们仍有待改进的领域以及需要完成的工作。--尼克 ^讨论 2014年3月4日 (世界标准时间) 19:54

相关站点 / 外部链接

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

我还要补充一点，类似的模块在乌克兰语和俄语维基导游中已经实施了一段时间。遗憾的是，峰会页面现在处于休眠状态。--亚历山大 (讨论) 2014年3月6日 (世界标准时间) 22:55

这似乎是我们应该实施的。最近我很忙，但如果没人管的话，我可以看看。——Rschen7754 2014年3月8日 (UTC) 02:11

移动网站证书问题？

当使用安卓三星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

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

安卓2.3系统，使用自带浏览器和海豚浏览器均无问题。-- 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设为Wikivoyage: 命名空间的别名可以解决很多问题。Powers ^(讨论) 2014年3月9日 (UTC) 18:31

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

在这里创建Wts:页面作为重定向（主要指向Commons）是可行的，但我不确定政策如何规定发明新的命名空间。

将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个月的实验。您可以获得资金，尝试您的在线社区组织、外展、工具构建或研究构想，以帮助让Wikivoyage变得更好。三月份，我们正在征集新的项目提案。

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

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

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

期待您的参与，

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

各位，这是否能为我们带来好处？比如开发并向旅游局寄送实际印刷的小册子，邀请他们更新自己的城镇信息？或者寻找一位愿意且能够解决一些紧迫技术问题的开发人员，例如无法翻译成英文的动态地图。或者开发我们可以使用的其他技术工具？2014年3月3日 (UTC) 08:19JuliasTravels (讨论) 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

Page rank

en:Wikivoyages的页面排名似乎有所提高，达到6/10（与WT相同）。不确定这是多久前的事。或者它是否解决了谷歌不显示的问题。

虽然德语读者量有所增加，但英语读者量并没有真正改变。 Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月8日 (UTC) 20:55

Nick在上面提供了一个有趣的链接，但数据与我们自己的数据大相径庭，德语和英语几乎同样受欢迎。而意大利语则较少。如果我们能达到WT流量的1/7，那还不错。Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月8日 (UTC) 21:04

在我看来，第一步是提高我们的谷歌页面排名。我认为让我们的页面排名高于WT并非不合理的目标，特别是他们的内容停滞不前且越来越多地被垃圾信息污染。想象一下那将对谷歌搜索结果产生什么影响。至于我们和WT之间的流量差异，我们必须耐心，不要气馁；这会随着时间而来。我们正朝着正确的方向前进。坦率地说，我宁愿流量逐渐增加；回想起WMF推出时流量的暂时飙升，一下子适应这么多有点困难（至少对我来说是这样）。-- AndreCarrotflower (讨论) 2014年3月8日 (UTC) 21:44

似乎还有很多中文维基百科的链接指向WT。我已经修复了一些。不过似乎有机器人会抓取该网站？我们有任何中文编辑可以帮忙吗？Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月8日 (UTC) 22:10

有什么理由将“en.wikivoyage.org”链接为外部URL，而不是使用跨维基链接（或模板化的跨维基链接）到[[wikivoyage: ? 外部链接会带上那个难看的“nofollow”，我们不希望这样。K7L (讨论) 2014年3月9日 (UTC) 04:44

由于有一个新的http://zh.wikivoyage.org网站，zh.wp应该链接到那里而不是en.voy。也许可以作为一个机器人项目，让zh.voy的人在他们的酒馆里讨论。-- torty3 (讨论) 2014年3月9日 (UTC) 09:44

完成了。有人能访问[www.comScore.com]数据吗？Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月10日 (UTC) 05:35

我没有。但也许我们可以放弃“WikiT正在被垃圾信息淹没并最终会消亡”的说法？这在分叉时就被预测过。但并没有发生。已经快两年了。他们已经应对过来了。我看不出那里有比这里更多的垃圾信息（至少在经过一天的整理之后）。垃圾信息不会杀死他们。一系列“谷歌技巧”也不会给我们带来访客。我们从帽子里拿出了我们的绝招——将维基百科的链接指向我们而不是他们——我们的流量就来自那里。几乎全部如此。我们是Wikitrav的克隆。随着时间的推推移——很长一段时间——一些情况会改变。但没有灵丹妙药。我同意詹姆斯：我们很幸运能拥有WikiT七分之一的访客。谷歌知道谁是第一个存在的，我们永远无法摆脱WT的压制，直到我们的内容在全世界都是独一无二的。SpendrupsForAll (讨论) 2014年3月10日 (UTC) 19:12

是的，除非我们能说服谷歌进行调整。或者通过社交媒体大力推广该网站。Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 01:22

呃……说服谷歌进行调整？他们凭什么会为了一个小型免费网站，而不是一个大型、成熟、受欢迎且能为谷歌带来收入的广告支持网站，而弯曲自己的规则呢？呃……祝你好运。SpendrupsForAll (讨论) 2014年3月11日 (UTC) 01:33

那是一个非常好的观点，保罗。

我认为只要这里的一些有影响力的人拒绝改进这个网站的搜索引擎优化，因为他们宁愿在一个小池塘里做大鱼，那么你的任何红利都不会有太大危险。--118.93nzp (讨论) 2014年3月11日 (UTC) 05:46

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

谷歌有“不作恶”的座右铭。关于搜索引擎优化，一旦我们能证明它对已有的文章有效，我将全力支持。我的尝试失败了。Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 05:55

暂时撇开118不说，恕我直言，SpendrupsForAll在上面的言论让人质疑他在Wikivoyage上的意图。如果你认为Wikitravel是一个更优秀的网站，Spendrups，你为什么不在那里编辑，却（显然带着幸灾乐祸）告诉我们我们比我们的竞争对手差多少？我会将你的评论描述为捣乱（即使不像WMF发布后IBobi所做的那样恶劣），并建议你将来要么建设性地贡献，要么干脆不要贡献。-- AndreCarrotflower (讨论) 2014年3月11日 (UTC) 05:59

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

我感到困惑。SpendrupsForAll在哪里说WT更优秀，或者WV更差，以及哪里有幸灾乐祸的成分？我认为他/她提出了很好的观点，包括内容才是最大的区别。Andre，如果你受到上面关于SpendrupsForAll身份的建议的影响，那么，我认为这个建议完全不可信。Nurg (讨论) 2014年3月11日 (UTC) 08:27

那些反对者说什么都无关紧要。我们没有像我希望的那么快成功，但我们会成功的。我们有一个网站，我们有独立性，我们有一个实际的CC BY SA许可证，我们是这个运动的一部分。我们有竞争。这只会让我们更加努力工作:-) 如果这些编辑是从WT过来挑衅我们的，最好的办法就是不搭理他们… Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 06:08

再看一遍数据。如果看页面浏览量，WT是720万访问量 * 1.8页 = 1300万页面浏览量。WV是100万访问量 # 3.1页 = 310万页面浏览量，这意味着我们更接近25%:-) 恭喜大家。Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 06:12

此外，2月份的阅读量增加了60%以上，而之前的数字是1月份的。不过3月份看起来会少一些。 Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 06:15

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

而且他说他将在2014年1月31日离开。所以Andre提出的观点是合理的。Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月11日 (UTC) 18:13

WT状态——页面排名

Spendrups建议“也许我们可以放弃‘WikiT正在被垃圾信息淹没并最终会消亡’的说法？这在分叉时就被预测过。但并没有发生。已经快两年了。他们已经应对过来了。我看不出那里有比这里更多的垃圾信息（至少在经过一天的整理之后）。”因为我时不时会查看WT，所以我想我可以评论一下。

查看新页面时，我经常看到那里有大量垃圾信息，而这里几乎没有。目前，他们只有两个新的垃圾信息页面，但通常有5-10个，我甚至见过超过20个的情况。

我曾故意留下一个非常明显的垃圾信息页面——没有旅行内容，标题古怪，并有大量可疑的外部链接——看别人需要多长时间才能发现。我们已经九个月了，还在继续观察。

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

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

我本该预料到WT是不沉的。K7L (讨论) 2014年3月11日 (UTC) 20:38

WT链接

一些链接已在英文维基百科上收集，我已将它们替换为 Wikivoyage 链接。我们需要确保这在其他语言中也正在发生。Travel Doc James (讨论 · 贡献 · 电邮) 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是最恶劣的（所有这些都需要替换为维基导游模板，然后才能提名删除旧模板）。可能值得检查其他维基百科，确保已从文章中移除的（现在未使用的）模板被提名为快速删除，并且不会作为垃圾信息重新出现在页面中。K7L (讨论) 2014年3月11日 (UTC) 18:41

格式问题

这里似乎有一个格式问题 Travel Doc James (讨论 · 贡献 · 电邮) 2014年3月12日 (UTC) 18:54

能更具体一点吗？Powers ^(讨论) 2014年3月13日 (UTC) 16:13

抱歉，这里多了一个空格 Travel Doc James (讨论 · 贡献 · 电子邮件) 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

日语维基导游

这种语言似乎是需要的。 Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年3月13日 (UTC) 05:45

看起来我们这里有孵化器 。有计划导入所有旧内容吗？ Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年3月13日 (UTC) 05:46

如果我没记错的话，当我们讨论分叉时，日语维基旅行社区出于某种莫名其妙的原因选择留在IB。谁知道呢。 -- AndreCarrotflower (讨论) 2014年3月13日 (UTC) 07:06

日语维基旅行基本上只有一个主要贡献者（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 - 另请参阅 孵化器:维基导游导入。 --Rschen7754 2014年3月14日 (UTC) 04:51

如果必须从转储文件开始，为什么不从活动的日语 WT 转储呢？我想它不是很大。我以前写过一个工具：https://github.com/nicolas-raoul/OxygenPump Nicolas1981 (讨论) 2014年3月14日 (UTC) 10:00

使用条款修正案拟议的可选更改

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

用户被强制注销

从酒馆扫来

由于 OpenSSL 实现中的漏洞，维基媒体用户（包括元维基）被强制注销并重新登录。该漏洞是在 SSL 和 TLS 协议中发现的。

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

维基媒体基金会还建议用户更改用于登录维基的密码。阅读更多。Jalexander (讨论) 2014年4月8日 (UTC) 23:47 (非常感谢Odder编写了我这里盗用的文本)

维基教科书

你好！

昨天，我快速浏览了维基教科书，注意到他们有几本旅行指南和旅游主题，这些可能很适合整合到我们的维基导游中。他们没有很多，而且大部分已经很久没有编辑了，所以我怀疑它们不会被特别怀念，尽管我已经在这里询问了社区的想法。当然，那里的指南不符合我们的模板，但我很乐意筛选它们，将它们合并到相应的指南中，并根据需要创建新文章。

你对此有什么看法？这值得吗？如果什么都没有，它至少应该能将维基导游明确标记为WMF家族中的旅行指南储存库。

Nick ^讨论 2014年2月3日 (UTC) 20:07

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

维基教科书整体上不太活跃，但我宁愿在大量移动内容之前征得他们的同意，以免冒犯任何人。 --Rschen7754 2014年2月4日 (UTC) 08:55

我认为尼克的留言很棒。我假设如果一周内没有回复，就可以进行合并。 Nicolas1981 (讨论) 2014年2月4日 (UTC) 09:25

我也会去找一位管理员，确保它得到关注——QuiteUnusual 强烈推荐。 --Rschen7754 2014年2月4日 (UTC) 09:28

我已将QuiteUnusual 指向我的帖子 - 谢谢你的推荐 Rschen7754！如果/当我们获得“批准”后，是否有比简单复制粘贴更精妙的方法来移动页面？ --Nick ^讨论 2014年2月5日 (UTC) 00:16

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

那么，是否最好只复制内容，并在摘要中链接到 WB 上剩余的页面历史？ --Nick ^讨论 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

我已在此处提名要移动的页面。 --Nick ^讨论 2014年2月5日 (UTC) 22:56

我完全单方面决定这本书是维基教科书旅游类别中我们唯一不想要的——我说的对吗？它似乎不太符合我们的任务；我认为它更适合它现在的位置。 --Nick ^讨论 2014年2月6日 (UTC) 04:38

我们的请求看起来很快就会获得共识，但是，我们尚未决定每本书的存放位置。我建议b:Hiking_in_the_Canadian_Rockies和b:Teaching Assistant in France Survival Guide都可以作为独立文章保留，而其余的则应与现有文章合并。尽管如此，所有被提名的书籍都需要进行一些编辑，因为它们分布在几个页面上。考虑到这一点，我很乐意将这些书籍首先移动到我的用户空间（使移动页面的管理员工作更轻松），在那里它们可以被“维基导游化”和/或将其内容分发到现有页面。为了归属目的，这些页面可以随后移动到Article name/Wikibooks。我很乐意自己承担大部分这项工作。这是否可以接受？ --Nick ^讨论

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

导入提案

我提议将英文维基百科、元维基和英文维基教科书添加到 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/旅行者电器设备指南
• User:Nicholasjf21/加拿大落基山徒步旅行
• User:Nicholasjf21/科利科
• User:Nicholasjf21/伦敦
• User:Nicholasjf21/昆士兰东南部
• User:Nicholasjf21/法国助教生存指南
• User:Nicholasjf21/德克萨斯州旅行指南
• User:Nicholasjf21/乐享东京

--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:附近 的调整

我们增加了 Wikivoyage 上“附近”的范围，使其更有用。现在的范围是20公里。请务必查看 Special:Nearby ！欢迎反馈！ 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

考虑到 WV 上重要的是城市/城镇文章，并且考虑到世界上大多数地方的城市之间相距超过 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 150公里，ru.WV 1500公里。 - 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 的小技术更新。

Justin：你关于将 OpenStreetMap 添加到侧边栏和重命名为 DMOZ 的提议都明显有价值，Justin，我将支持这两个提议。 --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。这是为了向美国和各州商会推广 Wikivoyage。希望这也能在其他国家复制。如果您有任何问题或意见，请告诉我。谢谢！ --Tbennert (对话) 2014年3月26日 (UTC) 19:51

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

我建议你完善“成功衡量标准”段落，加入可衡量和可验证的目标。例如，可以添加：

• 与至少 50 个联系人建立对话，其中至少 10 个给出积极答复。通过抄送所有电子邮件或记录 GoToMeeting 会议来验证。
• 至少有 5 个联系人在 Wikivoyage 上生成内容，其中至少 2 个有超过 5 次提交或超过 1 千字节的添加文本。通过在上述电子邮件对话中建立用户名身份来验证。

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

谢谢你的建议！这两个都非常棒，给我提供了一个起点来完善一些薄弱的章节。谢谢！--Tbennert (对话) 2014年3月27日 (UTC) 21:26

也许更好的衡量标准是事实准确性，或者从大纲到可用或指南实际改进的文章数量？即使是索多玛和蛾摩拉也通过了 1 千字节测试，尽管它包含了足够的营销炒作和过时信息，以至于毫无价值（除了作为反面教材的假设例子）。相反，修复文章中的不正确信息并删除已关闭的场所不一定会增加fr:Lac-Mégantic这样的文章的长度。Lac-Mégantic 的更新对于旅行者来说很有用，可以确定去年夏天火车事故后哪些地方仍然开放；曾经，担心市中心被毁的游客在新闻广播中看到后，取消了前往 20 或 30 英里（30-50 公里）以外的省立公园的旅行。质量，而不是数量……可以吗？

话虽如此，我们目前的覆盖范围在某些地方非常不均衡。纽约州对布法罗、罗切斯特和芬格湖（我们在那里有当地用户付出了巨大的努力）有坚实的覆盖，对该州中部地区的覆盖不一（马塞纳是红色链接，罗马已启动但从未完成……），然后又在纽约市进行了广泛覆盖。保持我们现有信息的最新也是一个巨大的问题。在我们的用户未曾访问过、没有当地人的地方，会展旅游局可以通过建设性地贡献来填补一些空白，指出我们遗漏的关键目的地。 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:垃圾邮件黑名单#invertsports dot com。 -- Ryan • (对话) • 2014年3月28日 (UTC) 16:09

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

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

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

只包含{{小城市骨架}}和指向 WT 的归属链接（没有实际内容）的空文章已被删除，不影响将来为这些地方创建实际文章，以消除 WT 归属链接以用于 SEO 目的。这实际上是一次性操作，因为未来没有计划从其他旅游维基导入空骨架。请参阅Wikivoyage talk:删除政策#摘要 K7L (对话) 2014年3月30日 (UTC) 16:05

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

默认站点排版即将更改

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

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

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

更多信息

• 更改摘要和常见问题解答
• 讨论页用于反馈或提问
• 博文位于 blog.wikimedia.org

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

纽约公共图书馆地图

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

标题字体改变了吗？

标题字体改变了吗？

标题字体改变了吗？

是我错觉，还是我们的标题字体变成了更像 Times New Roman 的字体？ Texugo (对话) 2014年4月1日 (UTC) 18:57

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

哦，漏看了。我不得不说，到目前为止我并不喜欢。 Texugo (对话) 2014年4月1日 (UTC) 19:23

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

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

我在Mediawiki上提出了一个关于个人CSS更改的问题。希望在更改在维基百科上推出之前能得到答复，以免引起轩然大波。 Nurg (对话) 2014年4月2日 (UTC) 09:22

文本大小的差异我或许能习惯（尽管我更希望它能恢复原样），但我认为正文文本采用典型的无衬线字体而标题采用截然更正式的衬线字体显得荒谬地不专业。这是一种非常糟糕的美学选择，完全与标准排版常识相悖，使我们的内容看起来像博客。当我在上面的帖子中看到“纽约公共图书馆”出现在标题中，后面紧跟着同一文本以不同字体出现在正文第一行时，这只会突出两种字体之间令人不快的对比。我断然否认这种改变提供了任何必要的阅读性改进，我绝对支持将标题字体改回与正文文本一致。这太丑了，以至于有人在元维基上甚至建议这可能是一个愚人节玩笑。 Texugo (对话) 2014年4月2日 (UTC) 11:19

天哪，不仅如此，我现在还注意到，虽然页面标题 (H1) 和 H2 标题以新的衬线字体显示，但所有 H3 和 H4 标题（我们有很多）仍然以普通的无衬线字体显示，就像正文文本一样，所以现在我们也有了混合标题字体（请参阅我上面添加的示例子标题）。整件事都很糟糕，考虑得非常不周。 Texugo (对话) 2014年4月2日 (UTC) 11:57

我已对MediaWiki:Vector.css做了一点小改动。请告诉我它是否修复了标题。 -- WOSlinker (对话) 2014年4月2日 (UTC) 12:18

它确实修复了标题。我希望没有人反对。现在我们需要讨论是否要接受这种字体大小的改变。 Texugo (对话) 2014年4月2日 (UTC) 12:37

新的标题字体对我影响不大。但老实说，超大号字体看起来很碍眼。一开始我还以为我的浏览器出问题了…… ϒpsilon (对话) 2014年4月2日 (UTC) 13:50

字体更改似乎也影响了列表标记的显示方式1 , 2 , 3 , 4 ,5 。它们现在将数字显示在框的底部边缘附近，而以前则更居中。 Texugo (对话) 2014年4月2日 (UTC) 18:22

哎呀。我们的希腊同事会怎么看 Y 字母（Ypsilon）看起来像一个手动抽水泵呢？ :/ ϒpsilon (对话) 2014年4月2日 (UTC) 19:37

记录在案，我同意以上观点——我不喜欢这些更改。 --Nick ^对话 2014年4月5日 (UTC) 19:24

我建议通过将此补丁添加到Mediawiki:Vector.css来恢复所有更改。新样式简直太糟糕了。我不知道是谁提议的，但我渴望将这个人从维基媒体社区中清除出去。 --Alexander (对话) 2014年4月2日 (UTC) 22:41

我们可能需要等待大约一周，看看核心软件是否会进行任何修复，然后再添加过多的本地临时解决方案，因为这些方案之后可能需要回滚——似乎有足够多的担忧表明，我会期望为所有项目解决这些问题会付出巨大的努力。 -- Ryan • (对话) • 2014年4月2日 (UTC) 23:00

我鼓励大家在mw:Talk:Typography_refresh#serif_vs_sans_serif或该页面的其他主题中加入您的声音。 Texugo (对话) 2014年4月3日 (UTC) 11:49

我已恢复 Vector.css 的更改。我们需要给它一些时间稳定下来，然后再开始修改新功能。 Powers ^(对话) 2014年4月3日 (UTC) 14:49

对于那些对选择衬线字体的原因感兴趣的人，这里有一些解释。本质上，衬线字体在屏幕上较小的字号下效果不佳，因此正文文本使用无衬线字体……从而导致标题文本使用衬线字体以形成对比。衬线字体通常用于正文文本的排版标准不适用于计算机屏幕，因为计算机屏幕与印刷文本不同。 Powers ^(对话) 2014年4月3日 (UTC) 14:56

这对我来说无法解释。是谁决定标题已经有不同的字号、粗体和下划线还不够，非得有这种对更多对比的强烈需求，这种需求是如此之大，以至于值得牺牲我们的美学和谐来获得它？我认为这是在试图修复从未损坏的东西，结果是标题现在太突出了，以一种不理想的方式，就像眼中钉一样。 Texugo (对话) 2014年4月3日 (UTC) 15:00

我同意 Powers 的观点，我们现在不应该对这些更改进行全站范围的恢复。如果有人不喜欢这些更改的某些方面，并且不想尝试适应它们，您可以转到个人偏好设置并更改您的自定义 Vector CSS。例如，要恢复正文文本大小：

#bodyContent {
	font-size: 0.8em !important;
}

Nurg (对话) 2014年4月3日 (UTC) 23:18

我没看到有人在这个网站上吵着要这些改变。不如在这个网站上恢复原状，不管其他 Mediawiki 网站是什么样子？ Ikan Kekek (对话) 2014年4月3日 (UTC) 23:44

很抱歉这么晚才加入讨论，我需要查看很多Village Pumps。首先，感谢所有可能试用过Beta功能和/或在过去五个月中向我们提供反馈的Wikivoyagers。关于本地覆盖：我同意Nurg和Powers的看法。设计更改总是需要时间来适应。由于我们花了很多时间进行测试，从所有维基媒体社区的编辑者那里收集反馈并进行迭代，我唯一的请求是让Wikivoyage作为一个整体尝试默认设置一段时间，然后再进行任何全站更改。如果个人不喜欢这些更改，您当然可以选择退出。如果您有任何其他问题，例如我们为什么选择衬线标题等，请告诉我。Steven (WMF) (讨论) 2014年4月4日 00:15 (UTC)

谢谢Steven前来。我不记得在更改发生之前看到过关于此提议更改的公告。我请求将来，当影响本网站的重大维基媒体范围的更改正在考虑时，请有人在讨论进行时来到Travellers' Pub并告知我们。这种情况曾多次发生，但这次我认为没有发生。另一种选择是更改其他维基，而不是这个，如果可行的话。Ikan Kekek (talk) 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 (talk) 2014年4月4日 00:31 (UTC)

新设计应该是一个可选功能，旧设计应该默认使用，直到所有格式问题都解决。您建议的“选择退出”选项不能使行间距恢复正常。请提供一个CSS文件，删除与3月31日相比的所有更改。然后我们可以讨论新风格的哪些功能有意义，但目前这种新风格完全是对社区的无知。——Alexander (talk) 2014年4月4日 07:24 (UTC)

至少标题字体，我甚至不愿意尝试“适应”，而且用我的个人CSS隐藏它也不是办法——我很尴尬，因为我们现在这样向世界展示我们的指南，我希望它能被恢复。这项倡议正在搞砸一些没有坏掉的东西，而且之前也没有社区共识表明有必要这样做。我完全支持将所有内容恢复到3月31日的状态的建议，除非/直到有任何本地共识进行更改。Texugo (talk) 2014年4月4日 11:14 (UTC)

虽然我同意排版刷新存在一些问题，但我认为一些关于这在没有通知的情况下实施的评论是过分的。每个页面上每个人账户偏好旁边出现的“beta”链接已经提供了排版刷新几个月了，并且有几个自动的pub通知提醒所有人这个更改即将到来。正如User:Rschen7754指出的，不可能与数百个维基进行单独交互，所以至少部分取决于我们来跟踪全球变化并在它们宣布之前发表意见。

至于现在恢复更改，我强烈建议我们至少等待一小段时间，解决主要问题，然后再尝试“修复”感知到的缺点，因为每次我们创建Wikivoyage特定的定制，这都是一个可能与未来升级产生不良互动的事情，需要我们额外的工作，或者导致我们错过新功能。——Ryan • (talk) • 2014年4月4日 15:30 (UTC)

我感觉有点像亚瑟·邓特被告知他应该知道他的房子会被拆除，因为他的拆除令已经在市政厅地窖一个被遗忘的角落里公开存档了好几个月了。如此大的改动没有明确提请我们注意，这似乎很荒谬。Texugo (talk) 2014年4月4日 15:46 (UTC)

11月，排版功能首次征求反馈意见：Wikivoyage:Travellers' pub/2013 (additional)#Introducting Beta Features，此后在邮件列表和元维基上进行了进一步讨论。我同意在3月底的通知之前再发布一次关于排版更改的通知会更好，但要求本地参与将使全球更改变得不可能，因为这将需要在700个不同的维基上进行单独讨论。

展望未来，如果人们启用“测试版”功能以在这些类型的更改正在测试时获得提前通知，这将很有用，在这种情况下，一旦提议将其纳入，您将自动看到它们，从而有机会立即提供反馈。如果需要，我们还可以设置一个页面，其中包含指向人们应监控的地点以跟踪全球更改的指针——这会有用吗？——Ryan • (talk) • 2014年4月4日 16:24 (UTC)

关注所有维基媒体项目的所有技术发展并非我们的职责。开发人员（顺便说一句，其中一些人是带薪的）的职责是确保他们的发展有意义并且不会破坏现有内容。如果排版是一个选项，那将是一个完美的附加功能，但是未经请求地更改所有维基的默认外观非常令人恼火。——Alexander (talk) 2014年4月4日 20:57 (UTC)

另请参阅w:Wikipedia:Village pump (technical)#Font size and style，了解维基百科上的排版更改讨论。——Ryan • (talk) • 2014年4月4日 16:54 (UTC)

我确实在11月发布在酒吧时开启了测试版功能（当我看到排版对标题做了什么时，我立即又关闭了它），但没有迹象表明它们不是仅仅作为可选功能提供的开发中功能，而这一功能实际上是对影响我们所有页面的全局默认设置进行的一系列根本性更改。维基百科的许多人似乎也有同感。Texugo (talk) 2014年4月4日 17:27 (UTC)

我不知道有什么测试功能只被视为未来的可选功能；如果它们将是可选的，它们就不需要通过测试系统。（测试系统的全部目的是让人们可以轻松地打开和关闭它；如果一个功能将是偏好中的一个选项，那么它已经可以轻松地打开和关闭了。）

我对新设计的一些细节确实有一些异议，但它肯定还没有糟糕到采取彻底将我们的设计与其他维基分离的极端步骤。我有点担心（如果Steven还在阅读的话）排版是考虑到维基百科的政策和风格（中立性、正式性、可靠性）而选择的，而不是考虑到其他项目有不同的需求。Powers ^(talk) 2014年4月4日 18:17 (UTC)

我不知道为什么我们的设计要与其他维基保持一致。我们已经通过横幅和水平目录等方式偏离了这条道路，因此我们主空间文章标题的字体已经不受这些变化的影响了。（请务必不要建议用衬线字体破坏我们的文章标题！）无论如何，我们也不会是唯一的，因为维基百科的各种版本已经恢复了原样。Texugo (talk) 2014年4月4日 18:41 (UTC)

共识是本维基的核心政策之一。没有共识来更改字体和其他样式问题。因此，所有这些更改都必须恢复并进行讨论。——Alexander (talk) 2014年4月4日 20:57 (UTC)

这是WMF所为，是一个超出本维基共识范围的技术决定。——Rschen7754 2014年4月4日 21:16 (UTC)

他们正在违反自己的政策，这是他们的问题，但我不明白维基导游为什么要支持这一点。——Alexander (talk) 2014年4月4日 21:31 (UTC)

他们没有。这种夸张的说法对您的论点没有帮助。如果我们想要偏离默认排版，那才是需要共识的地方。Powers ^(talk) 2014年4月4日 23:14 (UTC)

什么样的政策可以证明未经充分宣布或适当讨论（例如通过RfC）的单方面全站更改是合理的？——Alexander (talk) 2014年4月5日 21:14 (UTC)

“WMF管理服务器，他们可以做任何他们想做的事情”的政策。——Rschen7754 2014年4月5日 23:14 (UTC)

更何况它已经得到了充分的通知和适当的讨论。Powers ^(talk) 2014年4月6日 01:00 (UTC)

这证实了我的说法，即这项更改是违反现有政策进行的，并未得到社区的支持。——Alexander (talk) 2014年4月6日 06:25 (UTC)

是吗？怎么说？Powers ^(talk) 2014年4月7日 00:14 (UTC)

如果“WMF管理服务器，他们可以做任何他们想做的事情”是官方政策，那会非常有趣。我倾向于去Meta询问这项政策是何时以及如何获得批准的。——Alexander (talk) 2014年4月7日 06:03 (UTC)

据我所知，任何维基上都没有社区政策规定Mediawiki软件的默认外观和感觉。这根本不是政策变更。Powers ^(talk) 2014年4月7日 19:51 (UTC)

您是如何从所有文章中隐藏页面标题的？

我们希伯来语维基导游很早就将横幅添加到所有文章中，但我们还没有从文章顶部隐藏所有页面标题。从技术上讲，这具体是如何实现的？（我尝试通过更改vector.css和common.css来做到这一点，但似乎应该以不同的方式完成）。ויקיג'אנקי (talk) 2014年4月2日 14:01 (UTC)

我们不得不使用Javascript，这并不优雅，但由于技术限制，这似乎是唯一的选择。请参阅MediaWiki:Common.js，特别是

$(".topbanner").closest(".mw-body").children(".firstHeading").hide();

——Ryan • (talk) • 2014年4月2日 15:06 (UTC)

我将此代码添加到了希伯来语维基导游中，现在它确实隐藏了所有文章的页面标题，但是，在我看来，这个过程在希伯来语维基导游中稍微长一些——也就是说，您可以看到每篇文章顶部的页面标题大约1.5秒，然后它才完全隐藏——而在英语维基导游的文章中，在我看来，页面标题似乎立即隐藏了。（您可以亲自在希伯来语维基导游中巴黎的文章中看到这种延迟的示例）有什么建议可以减少这种延迟吗？ויקיג'אנקי (talk) 2014年4月2日 16:33 (UTC)

尝试将新代码移动到MediaWiki:Common.js的顶部——如果它运行得更快，这意味着您的Javascript中的其他东西运行缓慢，导致其后的所有内容都在页面加载过程中运行得更晚。如果您能找出什么运行缓慢，可以通过用以下内容将其包围来推迟缓慢的代码：

$(document).ready(function(e) {
    // put slow code here
});

如果问题不是由于其他代码运行缓慢造成的，那么就需要进一步调试。——Ryan • (talk) • 2014年4月2日 16:43 (UTC)

重新思考后，现在看来希伯来语维基导游和英语维基导游都存在同样的问题（从英语维基导游的巴黎文章中隐藏页面标题所需的时间与从希伯来语维基导游的巴黎文章中隐藏页面标题所需的时间大致相同）。现在看来，这个问题是由这样一个事实引起的：在服务器隐藏页面标题之前，它实际上首先加载横幅的全景图像——因此，在加载较大尺寸和细节的图像时，服务器需要额外的一到1.5秒来加载图像，然后才开始隐藏文章顶部的页面标题。理想情况下，为了解决这个问题，我们需要让服务器先隐藏文章顶部的页面标题，然后再开始加载横幅的全景图像。有什么办法可以实现这一点吗？（我尝试将新代码移动到MediaWiki:Common.js的顶部，但没有任何改变，可能是因为全景图像会预先加载的设置是在其他地方定义的。）ויקיג'אנקי (talk) 2014年4月2日 18:00 (UTC)

只是一个关于一些古老的维基零碎信息（可能适用也可能不适用）的注释：Matroc (talk) 2014年4月3日 00:07 (UTC)

1. 要隐藏单个页面上的文章标题，可以使用模板：

{{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}}

1. 要隐藏所有文章标题，我已编辑 Common.css（多年前在个人维基上）

body.page-No_page_title h1.firstHeading { display:none; }

当然，Mediawiki代码自那时以来已经发生了很大变化，上述内容可能无法正常工作。—此评论由Matroc (talk • contribs) 添加

不幸的是，DISPLAYTITLE不能再用来隐藏页面标题了——请参阅Wikivoyage talk:Banner Expedition/archive#Not inhibiting title。——Ryan • (talk) • 2014年4月3日 01:14 (UTC)

移民数据

该网站面向所有旅行者，因此应该包括移民，当然游客是服务的最重要群体，商务旅客可能位居第二。

这里有一张有趣的图表，世界各地的人们正在向何处移民——一张华丽的图表。Pashley (talk) 2014年4月3日 14:05 (UTC)

Stack Exchange有一个新的外籍人士问答网站（与他们的旅行问答网站不同）。Andrewssi2 (talk) 2014年4月4日 04:34 (UTC)

工具菜单中的格式错误项

从pub中扫来

工具菜单左侧栏中的某些内容似乎出了问题。&lt;wikibase-dataitem&gt;Nurg (talk) 2014年4月10日 10:39 (UTC)

其他语言链接的底部也有。Nurg (talk) 2014年4月10日 10:40 (UTC)

Wikidata似乎出了大问题——所有编辑/添加/保存/取消按钮都坏了。例如，查看wikidata:Q16503。Texugo (talk) 2014年4月10日 11:18 (UTC)

好的，他们现在已经修复了。Wikidata:Project chat#所有标签都坏了。Nurg (talk) 2014年4月10日 20:05 (UTC)

管理员编辑请求

从pub中扫来

侧边栏更改根据bugzilla:64027。谢谢。——Justin (koavf)❤T☮C☺M☯ 2014年4月22日 03:52 (UTC)

我看了那个bug，我不确定我们要改变什么。Powers ^(talk) 2014年4月22日 13:47 (UTC)

这个bug似乎是请求更改服务器上的配置文件。这是WMF的系统管理员需要做的事情。K7L (talk) 2014年4月22日 14:15 (UTC)

Bug 将侧边栏中的“开放目录”更改为“DMOZ”。——Justin (koavf)❤T☮C☺M☯ 2014年4月27日 18:20 (UTC)

是的，那是bug的标题。问题是，作为管理员，我们应该改变什么？正如K7L所指出的，这看起来像是一个配置文件更改，据我所知，管理员无权访问。Powers ^(talk) 2014年4月28日 18:47 (UTC)

抱歉 我看错了Bugzilla。这很尴尬。我道歉。请随意将此从Pub中删除。——Justin (koavf)❤T☮C☺M☯ 2014年5月1日 04:10 (UTC)

世界上最危险的城市？

这个列表准确或有用吗？您怎么看？Ikan Kekek (talk) 2014年4月10日 09:41 (UTC)

它似乎没有任何事实依据。在墨西哥、巴基斯坦和也门等地方采取预防措施总是好的，但我怀疑这是否特定于所提到的城市。Andrewssi2 (talk) 2014年4月10日 12:32 (UTC)

值得检查一下w:按谋杀率划分的城市列表中排名靠前的城市是否有警告。

我们在Retiring_abroad#信息来源中，“统计数据和指数”下有几个危险等级指数的链接。Pashley (talk) 2014年4月10日 12:51 (UTC)

还值得注意的是，游客采取预防措施所面临的危险与必须生活在城市中的居民所面临的危险可能显著不同。Andrewssi2 (talk) 2014年4月10日 12:59 (UTC)

同意Andrewssi2的看法。我不太相信那篇文章，因为我很确定一点：断言“（巴西的）人口最稠密地区不是你想去的地方”过于危言耸听，而且是极端的夸大其词。Texugo (talk) 2014年4月10日 13:22 (UTC)

令人惊讶的是，喀布尔、巴格达、格罗兹尼和大马士革不在名单上。然而，名单上的城市以及它们所在的地区也并非以安全著称。ϒpsilon (talk) 2014年4月10日 20:03 (UTC)

我住在世界上最危险的大城市，但幸运的是，我从未感到在这里不安全，所以是的，居民和游客的安全顾虑确实不同。——Saqib (talk) 2014年4月10日 20:21 (UTC)

一个更有说服力的排名可能不会计算那些受害者是袭击者熟人的案例。Texugo (talk) 2014年4月10日 20:55 (UTC)

刚刚，联合国关于此事的官方数据：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 (talk) 2014年4月11日 07:29 (UTC)

正式请求：将侧边栏中的“开放目录”重命名为“DMOZ”

请求评论 我正在就我之前在一篇文章中简要提及的一个问题，启动一个正式的请求评论。开放目录项目已正式将其品牌命名为“DMOZ”（这是一个它一直使用的名称，并且更受欢迎）。我已在英文维基百科以及维基数据和维基共享资源请求了类似的更改。无论好坏，英语是WMF项目的主要语言，维基百科是主要项目，所以我从那里开始，以此作为在项目和语言之间获得对该站点一致品牌推广的途径。这对我和其他人来说似乎都没有争议，并且得到了支持。社区认为如何？——Justin (koavf)❤T☮C☺M☯ 2014年4月11日 00:22 (UTC)

我们应该链接到ODP吗？在那里添加或更新列表似乎几乎不可能。K7L (talk) 2014年4月11日 01:27 (UTC)

@K7L: 为什么不呢？即使在那里添加列表不容易，DMOZ也可以成为读者的一个好资源。在某个时候，一个人可能需要比旅游指南提供更多的信息，那么我们应该将他们引导到哪里（如果有的话）？——Justin (koavf)❤T☮C☺M☯ 2014年4月12日 05:51 (UTC)

前一阵子和DMOZ的其中一位创始人聊了聊。他表示这个项目基本已经死了，我们维基百科不应该链接到它。我不太喜欢文章里长串的外部链接，但它比其他任何东西都要好。我想问题是维基媒体基金会应该启动一个吗？对于DMOZ这个词没有什么强烈的感觉。Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年4月12日 (UTC) 17:27

如果链接保留，按建议重命名似乎是明智的。Nurg (讨论) 2014年4月19日 (UTC) 05:06

我支持删除DMOZ的链接。它管理不善且正在消亡。—Tom Morris (讨论) 2014年6月2日 (UTC) 14:10

如果我们保留它，我强烈倾向于使用“Open Directory”或其他有意义的短语来代替“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#Other projects sidebar，维基媒体正在开发维基数据扩展，以允许其用于生成指向姊妹项目的链接，其方式与维基数据目前在一个项目内生成跨语言链接的方式大致相同。这些链接将显示在MediaWiki:Sidebar的一个部分中，标题为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#Sidebar links between projects powered by Wikidata now possible - AdamBMorgan (讨论) 2014年4月16日 (UTC) 16:56

嗯，一些语言版本已经从维基数据获取维基百科和维基共享资源的链接，尽管这些链接的显示仍然通过Extension:RelatedSites进行接口。当然，摆脱这个扩展会很好。然而，重要的是维基共享资源链接要设置为类别而不是页面。否则，许多有用的链接将会丢失。--Alexander (讨论) 2014年4月16日 (UTC) 17:10

我认为我们应该慷慨一些，包含许多链接。例如，拥有维基共享资源链接和指向各种维基百科的链接非常好。此外，这样做可能会增加这些网站未来链接到我们的可能性。Nicolas1981 (讨论) 2014年4月17日 (UTC) 10:18

说到DMOZ，我整理了一份大多数维基导游页面与其对应的DMOZ网址的映射，这可能会有所帮助。Unknown (讨论) 2014年4月26日 (UTC) 07:07

@Unknown：有趣！可以在线获取吗？我猜它是从维基导游的数据转储中提取的？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

我也注意到了这一点——维基导游的情况开始好转了吗？有人有关于网站访问量的可靠统计数据吗？--Nick ^讨论 2014年4月23日 (UTC) 18:07

前几天我很高兴地欢迎了一位在2003年首次编辑Wikivoyage并曾是其管理员的人来到WV。很酷，对吧？ :) ϒpsilon (讨论) 2014年4月23日 (UTC) 18:18

这太棒了！我们需要更多这样的人！也许也值得考虑如何留住一些正在编辑的人，让他们更多地参与进来。--Nick ^讨论 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只是与OsmAnd中已有的数千个POI合并。这样就无法使用或至少突出显示维基导游特有的POI。对此有什么想法吗？

您可能也有兴趣将维基导游与MapsWithMe对接，它是OsmAnd的替代方案。--Alexander (讨论) 2014年4月24日 (UTC) 05:22

大约有80个条目带有嵌入式制表符，在大多数情况下，用户可能尝试进行一些格式化（在将文件转换为制表符分隔文件时发现）……例如，曼彻斯特/市中心 – 三一酿酒厂……我正在测试一些想法，并将分享我发现的任何其他信息 – Matroc (讨论) 2014年4月24日 (UTC) 05:54

我已从文章中删除了制表符，所以下次生成列表文件时，它将是正常的。-- WOSlinker (讨论) 2014年4月24日 (UTC) 07:19

谢谢——我还修复了一些包含反斜杠或逗号作为数据的文章。Matroc (讨论) 2014年4月24日 (UTC) 07:30

我相信我可能发现了一个小转换问题——文章中发现的不间断空格的正确html代码被转换为csv文件中&后跟nbsp;的html代码——（1070次）——例如，参见Aarau，Aarau-West的住宿条目。（希望我没有错，也没有出现幻觉！）Matroc (讨论) 2014年4月25日 (UTC) 04:25……短破折号也一样。

嗨，Matroc！不太明白问题，你能不能把维基里出现的、CSV里出现的以及CSV里应该出现的复制粘贴到这里？非常感谢！顺便说一句，生成CSV的代码对&号等没有做任何特殊处理。Nicolas1981 (讨论) 2014年4月27日 (UTC) 13:58

嘿，Nicolas——我没有用我的冗余信息塞满旅行者酒馆——我在我的讨论页上创建了一个部分，用于进一步讨论。Matroc (讨论) 2014年4月28日 (UTC) 03:57

失效链接

嗨，维基人。我浏览了一下你们的页面，发现有很多失效链接。社区对此有什么普遍看法？我从DMOZ编辑的角度来看这个问题，那里非常强调删除失效链接，但也许在这里这并不是一个大问题——我明白一家特定的餐厅或住宿可能不再有网站，但仍然是一个正常的企业，也许你们更倾向于提供最大量的信息，然后用户应该验证这些信息。如果不是这样，有没有兴趣组织一个机器人来维护这些链接？Unknown (讨论) 2014年4月26日 (UTC) 07:01

失效链接通常只意味着网页结构已更改或已移动到其他域名（例如，他们有了自己的正式网页，而不是许多ISP免费提供的，有时带有广告的小空间）。如果我遇到失效链接，我通常会用Google搜索该机构，看看它是否仍然存在。ϒpsilon (讨论) 2014年4月26日 (UTC) 08:31

拥有更好的链接将提高网站的搜索引擎排名。但我认为这应该通过手动纠正。是否有可能创建一个页面类别，其中包含损坏的外部链接，类似于损坏的图像链接类别？--Traveler100 (讨论) 2014年4月26日 (UTC) 11:08

DuckDuckGo使用Wikitravel链接

搜索地点时会显示Wikitravel上更多信息的链接，例如：https://duckduckgo.com/?q=london ——这将是一个很好的方法，可以引导一些流量，说服他们改为链接到维基导游。JimKillock (讨论) 2014年4月26日 (UTC) 17:30

我认为让DuckDuckGo意识到这是许多人感兴趣的问题会很好。您可以在此处向DuckDuckGo提出建议。我相信我们应该确保他们能在短时间内收到许多建议更改的消息。PrinceGloria (讨论) 2014年4月26日 (UTC) 20:05

我为此创建了一个帖子，网址是https://duck.co/forum/thread/5688/use-wikivoyage，也欢迎大家在那里发表评论。干杯！Nicolas1981 (讨论) 2014年4月28日 (UTC) 02:24

用于列表详情的维基数据

我从Openstreetmap找到了这里，尝试将OSM对象链接到维基数据，最终开始为维基百科做出贡献。我正在为维基导游和维基百科的几个语言版本做出贡献。这让我思考。我将一家餐厅添加到行程中，下一步是将其添加到这个维基导游中关于该地区的本地指南中，然后以同样的方式在例如6个语言版本中进行操作。当然，我们在Openstreetmap中又重复了所有这些细节。复制/粘贴很容易，没有问题。问题在于当其中一些细节，例如营业时间发生变化时。谁会去查找所有提到该细节的实例？对我来说，显而易见的解决方案是将所有这些存储在维基数据中，然后引用其属性，尽管我不太确定如何做到这一点，以及技术上是否可能，因为Q项不是文章本身的Q项。第一个问题当然是，我们想这样做吗？--Polyglot (讨论) 2014年4月27日 (UTC) 08:28

嗨，Polyglot，欢迎来到维基导游！维基数据Q项不需要与任何地方的特定文章匹配，所以这没问题。实际上，我们需要人们努力实现这些模型和工具，才能实现整个集中化。请参阅https://www.wikidata.org/wiki/Wikidata:Property_proposal/Sister_projects#Wikivoyage https://wikivoyage.cn/wiki/Wikivoyage:Wikidata_Expedition 我们还需要修改列表编辑器，以便在列表由维基数据Q项定义时从维基数据获取数据。没有什么不可能实现的，但需要大量工作，所以非常欢迎你加入这个努力 :-) 祝好！Nicolas1981 (讨论) 2014年4月27日 (UTC) 14:19

嗨，@Nicolas1981:，我试过了，但不行。请看看我在安道尔上的最后一次修改——Polyglot (讨论) 2014年4月30日 (UTC) 17:54

嗨，Polygot！不幸的是，目前看来安道尔的文章只能访问维基数据项Q228（安道尔）的属性。需要有人研究维基页面如何通过链接找到Q228链接的所有酒店（并首先找到如何从Q228链接酒店）。确实还有很多工作要做……Nicolas1981 (讨论) 2014年5月1日 (UTC) 05:29

DuckDuckGo即时答案？

似乎在DuckDuckGo自然搜索引擎结果中偏爱维基导游很困难。相反，一位社区成员建议创建“即时答案”。这里有一些例子。我还没有计划/开发任何东西，但如果走这条路，我们将不得不回答以下问题，因此欢迎您的回答/想法！请在每个问题下发表评论，谢谢！Nicolas1981 (讨论) 2014年5月8日 (UTC) 03:03

您的即时答案有什么作用？

• 品川王子大饭店 -> 酒店的营业时间、价格及其他信息。其他景点也是如此。
• 伦敦 -> 伦敦文章的第一句话，如果没有相应的维基百科文章（可能性不大……维基导游上有哪些目的地文章维基百科上没有呢？）。
• 中国驾驶 -> 中国驾驶文章的第一句话。
• ... (添加你的想法) ...

您的即时答案解决了什么问题（为什么它比自然链接更好）？

您的即时答案的数据来源是什么？（如果可能，提供链接）

• 维基旅游

您为什么选择此数据源？

• 最新旅游信息

是否有其他（更好）的数据来源？

• 替代方案：WT、Yelp、TripAdvisor。

有哪些示例查询会触发此即时答案？

此即时答案对哪些社区特别有用？(游戏玩家、图书爱好者等)

• 旅行的人们
• 准备旅行的人

此即时答案是否与 DuckDuckHack 即时答案创意相关联？

• （待我们确定想法后创建想法条目）

此即时答案将取代/与哪些现有即时答案重叠？

• Yelp
• 维基百科

您有什么问题吗？您需要我们提供任何帮助吗？

正式请求：在侧边栏中加入OpenStreetMap

请发起讨论 我正在就我之前在一篇帖子中简要提及的问题发起正式的讨论请求。我认为OpenStreetMap是一个很好的资源，可以将其包含在侧边栏中，原因如下。首先，它是一个开放项目，就像维基媒体和ODP/DMOZ（侧边栏中链接的另一个项目）一样。从抽象层面讲，我们互相支持是好事。从更实际的层面讲，OSM提供了深入的数据，这些数据对于旅行指南可能不合适，但对于深入了解城市的人来说非常有用。此外，它通常拥有高质量的内容，尽管分布不均——就像我们的维基媒体项目一样。还有人认为OSM是一个足够好、足够有用的项目，值得我们向旅行者推荐，让他们在我们提供旅行指南后继续使用吗？—Justin (koavf)❤T☮C☺M☯ 2014年4月11日 (UTC) 00:25

我们已经相当突出地整合了OSM信息，{{geo}}、{{mapframe}}、{{listing}}、{{marker}}、special:mapsources。您的提案有何不同？K7L (讨论) 2014年4月11日 (UTC) 01:22

@K7L:这些其他模板只是将OSM纳入其他地图服务。我提议做两件事，让OSM从（例如）谷歌地图中脱颖而出：OSM拥有其他地图服务所缺乏的许多高质量选项，而且它是一个开放项目。作为我们自己的开放项目，我们应该鼓励支持其他此类开放项目。这正是Wikivoyage最初链接到DMOZ和维基百科的原因。—Justin (koavf)❤T☮C☺M☯ 2014年4月12日 (UTC) 05:56

并非如此。看看Oswego#Get around；德国的“Wikivoyage eV”用户们投入了大量精力，将OSM地图整合到维基导游中，并标记了我们的兴趣点。OSM并未被视为像（专有的）谷歌地图那样仅仅是另一种地图服务。K7L (讨论) 2014年4月12日 (UTC) 13:24

大多数目的地文章都有一个指向全屏OpenStreetMap地图的链接——横幅上方右侧有一个图标。但我预计许多读者不会注意到或意识到它是OpenStreetMap。将此作为相关网站组中的链接复制到左侧可能会很好。AlasdairW (讨论) 2014年4月12日 (UTC) 14:35

我希望每篇文章都有一张地图。机器人能做到吗？也支持在侧边栏中添加OpenStreet Map链接。Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年4月12日 (UTC) 17:19

我建议将图标替换为地图；用户可能没有注意到该图标或意识到其重要性。Pashley (讨论) 2014年6月2日 (UTC) 16:53

DMOZ工具，用于挖掘和检查维基导游链接

链接抓取工具DMOZ论坛（需要会员资格）上有一个帖子DMOZ论坛，用户在那里利用他们的区域链接本体和我们的RDF面包屑，并通过一些计算魔法找到了我们页面上失效或与DMOZ重复的链接。该论坛原本只供内部使用，但我认为引用是没问题的，因为他们对交叉协作感兴趣

嗯，我玩弄了一点数据，发现了一些值得一看的东西，尽管这并不是我认为最终产品能达到的水平。它是一个DMOZ主题浏览器，映射到相关的维基导游链接，按页面和类别细分。例如温哥华（维基导游也有几个社区页面，也清晰地识别出来了）

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

很多东西都很容易挖掘。我还可以使用维基导游的分类来建议地区内的专题类别——我不知道这是否很重要。

从另一个角度思考，我看到这个类别

http://dmoztools.net/wikivoyage.cgi?browse_wikivoyage=1&cat=Regional/North_America/Canada/New_Brunswick/Localities/Plaster_Rock

包含 13 个未在 DMOZ 中列出的网站，但其中 6 个已失效。我认为维基导游项目可能从中获得一定的价值。他们不是专门的链接目录，但 DMOZ 是——这就是为什么我们有一个完善的质量控制系统来清理目录。从我目前所见，仅使用我自己的质量控制工具，维基导游有数量惊人的失效链接。如果有一个列出两个网站中链接的数据库，也许我们可以找到一种方法，在我们的网站删除链接时通知他们的编辑者。

从链接挖掘的角度来看，一个显而易见的事情是过滤掉死链接，但我认为现在展示它们有助于说明问题。

有趣的是，这是DMOZ生态系统的一个部分，它可以使维基导游项目受益，但DMOZ可能不希望内部开发它，因为他们的开源许可系统会让垃圾邮件发送者在购买过期域名时轻易规避它们。对于他们来说，这可能不是一个大问题，因为它们都是nofollow链接。

这当然可以扩展到所有其他语言的维基导游。我只是先做了英语版本，看看是否有任何兴趣，因为我对英语更流利。

另外，我看到DMOZ中维基导游的列表数量已增加到20个http://www.dmoz.org/search?q=wikivoyage.org。

有用吗？有没有人想与DMOZ编辑就这些页面上的链接以及指向这些页面的链接进行双向合作？—Justin (koavf)❤T☮C☺M☯ 2014年4月28日 (UTC) 03:39

有趣！首先，我们可以从获取所有失效链接的列表中受益匪浅。动态信息共享（通过维基数据？）会更好。Nicolas1981 (讨论) 2014年4月28日 (UTC) 05:04

上面发布的链接有一个身份验证层，阻止除了DMOZ编辑以外的任何人查看——我已经制作了一个公共版本的浏览器并更新了链接。这只是本体的映射，但我有一个失效链接数据库（来自您的XML转储，非实时），我将很快上线。 Unknown (讨论) 2014年4月28日 (UTC) 15:10

这是一个[维基导游上的失效链接列表]，其中29305/171536 ≈ 17%的链接失效。当然，其中一些将是暂时性错误，并且它基于XML转储，可能略有过期。还有大约10,000个可能的错误或需要纠正的东西未在此处列出，因为它们更模糊（极小的页面、奇怪的重定向等）。我不确定如何最好地处理这些数据。显然，这是一个相当大的列表——如果持续维护，那么一个列出错误的页面可能就足够了，但也许这对一个页面来说太多了？最好将其分解成更易于管理的块，或者在单独的讨论页上提及它们？如果有人对此感兴趣，我也可以将其制作成一个更易于搜索的系统。欢迎提出任何想法！Unknown (讨论) 2014年5月1日 (UTC) 00:51

非常感谢这份清单！我修复了一些，但意识到修复链接太耗时了，最好直接删除29305个失效的URL……有没有人能写一个脚本来做这件事？ Nicolas1981 (讨论) 2014年5月1日 05:24 (UTC)

我修复了卡尔弗城和黄石国家公园中的一些失效链接，但也遇到了一些误报，这让我对使用自动化脚本删除所有链接犹豫不决。此外，手动删除可能有助于我们识别（并删除）一些已关闭的商家信息。我们能否先推广这份清单一段时间（也许通过Wikivoyage:清理和其他方式），看看未来几周内完成了多少手动清理，然后再考虑自动化选项？ -- Ryan • (讨论) • 2014年5月1日 06:12 (UTC)

我当然不打算自动删除这份清单上的所有内容 :) 这绝对是为了人工检查。如果我们想采用自动化解决方案，我们会将失效链接放入队列中，并在未来一到两周内查看它们是否恢复，以确保它们不是暂时性错误，并且我们需要针对不同情况进行特殊处理。在DMOZ中，一旦我们确定一个链接确实已失效，我们甚至不会删除它们，而是将它们放入辅助队列中，编辑者会去寻找替代链接，因为通常有很好的理由，比如企业更名、获得新的域名等等。这就是为什么我一直在考虑在两个项目之间直接协作是个好主意，因为我用来扫描Wikivoyage链接的链接扫描器远不如DMOZ运行的那么完善，而且我们也在不断修复我们的链接，因此将这项工作的价值传播到其他开放项目（如这个）是有意义的。理想情况下，当Wikivoyage旅行者找到替代链接时，这些替代链接也会被发送到另一个方向以改进DMOZ。使用Wikidata动态地实现这一点听起来是个有趣的想法。无论如何，如果这些报告在这里有用，我很乐意继续根据WV XML转储不断生成这些报告。 Unknown (讨论) 2014年5月1日 15:03 (UTC)

我以为这份清单来自与DMOZ相同的多步骤检查引擎。如果只是一次性检查，那么删除URL确实为时过早。但如果一个链接一直失效，我赞成直接删除这个链接（并保留该条目）。与DMOZ不同，我们不绝对需要URL。与DMOZ不同，我们有相对较多的实际前往该目的地的人，这些人最适合在以后添加正确的URL，或者如果该条目在现实生活中消失了，则将其完全删除。无论如何，期待与DMOZ在这方面合作！祝好！ Nicolas1981 (讨论) 2014年5月2日 06:15 (UTC)

有没有计划重新运行这份清单？进行一次集中的清理活动，然后重新运行，看看还剩下什么需要做，这可能不错。我一直在零星地修复链接，听起来其他人也在做，所以这份清单可能已经改变了。同意其他人的观点，在检查条目是否已关闭之前，贸然删除链接不是一个好主意。 -- Phoebe (讨论) 2014年6月16日 05:36 (UTC)

我不敢指望“有相对较多的实际前往该目的地的人”作为健全性检查，因为这取决于目的地的受欢迎程度以及我们常驻用户的人数。一个偏远小村庄里的小餐馆常常悄无声息地消失，只有村里的当地人知道。失效的URL往往是企业关闭的第一个外部迹象，因为域名如果每年不续订，就会过期并被垃圾邮件发送者劫持。过时的白页或黄页列表仍然可以在网上存在十年或更长时间，因为有些网站不会更新其信息。除了使用廉价的网络电话服务实际致电这些场所（在大多数工业化国家，一分钟的座机通话可能只需一两美分），我们无法知道它们是死是活。一个失效的URL常常意味着一个已关闭的场所。

另一个选择是整理一份失效列表，然后联系这些目的地的当地旅游局，寻求他们协助识别企业关闭。 K7L (讨论) 2014年6月16日 14:58 (UTC)

维基导游宣传单张 (Wikimania)

请看m:Wikivoyage/Lounge#Wikimania Leaflets。我认为这是一个很好的主意，有助于向WMF社区推广我们的项目。 Powers ^(讨论) 2014年5月29日 12:42 (UTC)

太棒了。谁来提出WV宣传单张的请求？ --Saqib (讨论) 2014年5月29日 12:46 (UTC)

我希望我们能在元维基讨论细节。 Powers ^(讨论) 2014年5月30日 00:07 (UTC)

当然，但我认为最好先在这里讨论，因为我们更有可能找到潜在的感兴趣的人，否则到目前为止元维基上还没有人回应。 --Saqib (讨论) 2014年5月30日 00:19 (UTC)

在元维基上留言说，我认为制作一份宣传单来推广维基导游是个好主意 - Matroc (讨论) 2014年5月30日 02:44 (UTC)

一张印在卡片上的页面横幅可以作为很好的书签。背面会有足够的空间写几行字。我预计这会与一张小传单成本相仿，而且更可能被捡到的人保留。 AlasdairW (讨论) 2014年5月31日 22:40 (UTC)

推广维基导游

大家好！m:Grants:IEG/Promoting Wikivoyage的个人参与拨款已获选。我很高兴能分享维基导游这个优秀的资源！基本计划是直接向美国各地的商会介绍维基导游。我将在此过程中征求社区意见，并发布最新进展。主要项目页面在元维基。目前，只是让大家知道这个好消息。我们很快就会再见的！ --Tbennert (讨论) 2014年5月31日 03:51 (UTC)

太棒了。干得好！ -- Alice^✉ 2014年5月31日 03:57 (UTC)

Tbennert，恭喜你！这真是个好消息。 --Danapit (讨论) 2014年6月1日 16:46 (UTC)

我们指望你 :-) Nicolas1981 (讨论) 2014年6月2日 08:37 (UTC)

干得好！恭喜！如果您需要任何帮助，请告诉我们！ :) --Nick ^讨论 2014年7月4日 21:00 (UTC)

特拉沃明德

伙计们，

今天起，第一个跨维基协作项目在.de和.en上线了！我要感谢User:Ikan Kekek、User:Pashley和User:Texugo对我的蹩脚写作技巧的校对和不懈检查，User:Saqib提供的静态地图，以及User:Mey2008在很早阶段就实现了动态地图。特别感谢User:DerFussi和User:Tine，他们是德国管理员，使得德国方面的工作得以实现。

我认为我们需要继续在跨WV项目上努力，以保持WV作为多语言社区的精神。Mr. Nugget目前做得很好，所以我们也许应该以每年一次的跨维基合作为目标，推出月度目的地/特色目的地？此致， jan (讨论) 2014年6月11日 11:35 (UTC)

Nugget先生！谢谢！我在这里一直在学习，这比黄金更有价值。 Llywelyn2000 (讨论) 2014年6月11日 19:52 (UTC)

恭喜你和所有参与者！我认为有其他跨WV特色会很棒。如果能得到其他任何维基的合作，跨维基特色也会很棒。 Ikan Kekek (讨论) 2014年6月11日 20:43 (UTC)

我与德国WV社区的成员进行了交谈，他们积极表示有兴趣每年合作推出一个月度目的地/特色目的地/FTT。https://de.wikivoyage.org/wiki/Wikivoyage:Lounge#Travem.C3.BCnde André是该领域的负责人，所以我希望我们能找到一种方法来继续下去。也许我们甚至可以更进一步，与意大利和德国社区一起做一些事情。 jan (讨论) 2014年6月12日 07:09 (UTC)

抱歉回复此帖迟了。关于jan的建议，我完全支持每年举办一次跨语言特色活动。如果将来我们与fr:和es:合作，我可以担任联络人，但在其他情况下，最好能有其他愿意的多语种编辑者自荐。 -- 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，非常乐意在需要时提供帮助。只需在意大利语维基导游上给我吹个口哨，以确保我及时关注 ;-) --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，但本节不仅仅是关于Twitter。它也是对我过去几个月活动极度减少的道歉。正如您可能已经猜到的那样，我最近工作非常繁忙，无法像我希望的那样关注维基导游；我希望大家一切都好！

作为其中一部分，尽管我尽力通过维基导游账户发布推文，但我未能给予它应有的全部关注。因此，我希望呼吁另一位用户帮助运营维基导游的Twitter账户。我并不打算完全停止发布推文，但当我有其他事情时，有其他人来填补空缺会很好——我们目前有超过500名关注者，他们期待内容！在要求方面，任何以前的Twitter经验自然都是加分项，但您还需要成为维基导游的受信任用户（无论这意味着什么），并且您还需要准备好提供您的电子邮件地址/在您的个人资料中启用该功能，以便我可以放心地将登录凭据发送给您。如果有人能想到任何其他必要的要求，请告诉我。

再次为我长时间的缺席道歉，但我希望能在夏天变得更加活跃。很高兴看到这个项目持续发展（即使是从远处），我仍然绝对致力于WV的成功。谢谢！ --Nick ^讨论 2014年6月12日 22:44 (UTC)

嗨，Nick。很高兴看到你的留言。如果社区信任我，我可以管理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的观点——目前看来，我们每天处理大约2-4篇由IP创建的垃圾文章，这只是一个小麻烦，而不是一个问题，我不认为这值得改变我们尽可能开放的原则。 -- 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)

嘿，Andy，这真是个好主意！如果你想提及维基导游，你也许可以提到我们关于柏林的文章正在进行重大翻新，但我们缺少来自实际居住在柏林的人的声音。由于德语维基百科/维基媒体社区实际上是最强大的之一，这可能是因为他们之前对维基导游不感兴趣——如果柏林对他们来说很重要，也许是时候大胆行动了！ PrinceGloria (讨论) 2014年6月17日 15:27 (UTC)

附言。同样，我不确定维基百科人是否知道我们实际上正在使用OpenStreetMap来动态地绘制兴趣点（如景点、餐馆、酒店/旅馆等），这些兴趣点是由人们添加的，这样我们总是能得到最新的地图。这个世界级的应用程序是维基导游独有的（例如，维基旅行就没有），并且基本上是由一位非常投入的用户（恰好是德国人！）创建和维护的！

柏林已完成 - 感谢提示。稍后我会介绍OSM。 Andy Mabbett (Pigsonthewing); 和Andy聊聊; Andy的编辑 2014年6月21日 13:15 (UTC)

马航17号航班空难

从酒馆“扫除”

在马航MH370航班失踪三个月后，另一架载有280名乘客和15名机组人员的马航客机在俄乌边境被击落。我深感悲痛，这真是一个令人震惊的消息。 --Saqib (讨论) 2014年7月17日 17:00 (UTC)

是的。我希望是误伤，但无论原因如何，对于马来西亚航空公司来说，这是极其悲惨的一年，我向所有受此灾难和暴行影响的人表示哀悼。 Ikan Kekek (讨论) 2014年7月18日 02:11 (UTC)

同样在顿涅茨克，MH17航班（从史基浦机场，阿姆斯特丹飞往吉隆坡国际机场，吉隆坡）在格拉博沃（与俄罗斯接壤）坠毁（见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)

你需要选择项目总数，然后在维基导游下选择统计数据，然后将天数设置为180。不过这些数字可能不准确。Travel Doc James (讨论 · 贡献 · 电子邮件) 2014年7月23日 20:36 (UTC)

夏季吗？这个数字似乎比去年七月略高。 Nicolas1981 (讨论) 2014年7月24日 07:03 (UTC)

几周前发生了一些事情，增加了浏览量。不过，可能只是一个机器人或爬虫。Powers ^(讨论) 2014年7月24日 (UTC) 17:34

是的，是一个爬虫；很可能来自Guidesebooks.com（这只是一个没有数据的猜测）。超过100万次点击访问了以下页面：Special:CentralAutoLogin/setCookies Special:CentralAutoLogin/deleteCookies。没有一个有大脑的人会对这些技术页面点击100万次 :-P --Andyrom75 (讨论) 2014年7月25日 (UTC) 07:23

Wikivoyage的维基数据文档更新

大家好！

我是一名当前的维基媒体OPW实习生，专门负责维基数据推广，我只是想让大家知道，维基数据关于Wikivoyage的文档已经更新，希望能对Wikivoyage社区有所帮助，并鼓励进一步的协作。如果感兴趣，请查看Wikidata:Wikivoyage。您也可以在讨论页留下任何反馈。

祝好，-Thepwnco (讨论) 2014年7月31日 (UTC) 16:45

自动化警告框

您好！

作为（至少是未来的）主要的旅行信息来源，我们有很大的责任确保我们的指南提供准确和最新的安全信息。目前，这是一个手动过程，任何用户都可以将警告框模板添加到文章中。这可能非常繁琐，因为一个警告可能会影响几十篇文章。例如，西非当前的埃博拉疫情应该添加到所有关于几内亚、利比里亚和塞拉利昂地区文章中。正如大家所理解的，这需要大量时间，而且通常文章缺乏重要的安全信息。

所以，我认为我们应该引入一个脚本，当一个警告框添加到国家/地区时，其下的所有页面也会自动获得警告框。由于文章已经按其所属区域进行分类，因此似乎可以使用相同的机制。

然而，当然也有一些例外。例如，我们会在伊拉克页面以及所有北部地区添加关于当前ISIL攻势的警告框。但将其添加到南部地区则没有意义，因为那里我们有更一般的警告。这些类型的问题将不得不解决。

总的来说，我确实认为这是一个非常重要的问题，需要深入研究。特别是Wikivoyage有望成为主要的旅行信息来源。Jonte-- (讨论) 2014年6月27日 (UTC) 12:04

这听起来像是小题大做。考虑一个直接与旅行相关的安全事件，比如9/11：你会对美国每一个城镇都添加相同的警告吗？我可以看到把它添加到美国、华盛顿特区和纽约；我甚至可能看到把它添加到每个美国州，或者可能添加到每个有商业机场的城市（因为机场关闭了）。但是每一个小城镇呢？我认为不是这样的。WhatamIdoing (讨论) 2014年6月27日 (UTC) 15:41

我们必须小心，不要将自己定位为旅行安全的权威指南，原因很简单，我们是一个志愿者团体，我们中很少有人（如果有的话）真正有资格权威地发言或及时更新相关文章。显然，我们有时会为重大新闻事件这样做，但自动化这一过程并在各地设置警告框似乎不是正确的方向。Andrewssi2 (讨论) 2014年6月28日 (UTC) 03:53

另据路透社报道，南非已禁止来自几内亚、利比里亚和塞拉利昂的旅客。--Liuxinyu970226 (讨论) 2014年8月22日 (UTC) 07:09

Echo和监视列表

Special:Notifications和Special:Watchlist在功能上基本重叠，除了前者还包含额外的（一些非公开的）事件，并且不提供被动使用选项（意味着关闭网页提醒或电子邮件提醒，只在我有空时访问页面），而后者不提供主动网页提醒通知的选项（但已提供电子邮件界面）。部分原因，在我个人看来，Echo/通知项目的推动是由于监视列表的可用性较低；浮现在脑海中。值得注意的是，Echo用户除非禁用JavaScript，否则无法看到Special:Notifications——在这种情况下，这是他们阅读通知的唯一方式。

我想完成这个

1. 将这两个页面合并为一个。
2. 为了解决信息流过大的问题，引入多级别的网页提醒通知重要性（红色表示提及，橙色表示感谢，蓝色表示新的监视列表项目等，可在您的设置中配置）。

请对这两点发表意见？--Gryllida (讨论) 2014年9月9日 (UTC) 02:39

我并不认为它们有重叠。我真的不想把我收到的消息或我的用户名被提及的信息，和我在监视列表中的许多文章混淆在一起。--Traveler100 (讨论) 2014年9月9日 (UTC) 04:44

Gryllida，你把这个想法发到多少个地方了？WhatamIdoing (讨论) 2014年9月9日 (UTC) 19:18