Wikivoyage:Travellers' pub/2013 (additional)

2013年附加存档页面

将内容汇总到 2013 年存档页面的操作被证明是不可靠的。这是因为页面太大，每次添加都需要保存整个页面。所有 2013 年的对话都汇总后，可以将其合并回主存档页面。Andrewssi2 (讨论) 04:29, 2014年1月18日 (UTC)

区域模板和章节问题

这篇文章的结构是否符合 结构和模板指南？特别是 看点 (See) 子章节

• [编辑]
• 博物馆
• 教堂和天主教堂
• 教育机构
• 纪念碑

如果符合，我将将其用于其他一些区域的文章。

另外，为什么这篇文章没有显示目录 (TOC)？
--TheMightyHercules (讨论) 23:48, 2013年10月27日 (UTC)

如果目的地确实有很多可看之处，我认为章节设置是可以的。目录在顶部的横幅中以单行显示。Nicolas1981 (讨论) 03:03, 2013年10月28日 (UTC)

当有很多东西可看时，章节设置绝对是可以的。有多少章节以及选择哪些章节取决于该区域的景点类型。查看我们的一些明星区域文章，例如 San_Francisco/Chinatown-North_Beach#See、Paris/1st_arrondissement#See 或 Chicago/Bronzeville#See。我实际上认为，只有当教育机构的建筑具有建筑或“被动吸引力”价值时，才应将其列入“看点 (See)”部分。否则，它们可能应该放在“做 (Do)”之后的单独“学习 (Learn)”章节中。JuliasTravels (讨论) 17:21, 2013年10月28日 (UTC)

仅作为一点小说明，我认为“学习 (Learn)”更适合城市级别的文章，而不是区域级别的文章。人们通常选择在城市停留更长时间来学习，而不是在特定区域，因为在城市的一个区域到另一个区域学习并非不可能。 PrinceGloria (讨论) 19:54, 2013年10月28日 (UTC)

我们一般不列出需要“定居”才能做的事情。大多数“学习”条目应为一日烹饪课或一周语言课程之类的东西。没有理由将它们放在主城市页面上。Texugo (讨论) 19:57, 2013年10月28日 (UTC)

好吧，就目前而言，这些章节充满了关于长期学习、大学等的建议，所以我认为它们是这样使用的。短期学习的选择可能会非常有限，我推测，而且我认为这并不局限于城市中的特定地点——你通常需要连续几个小时，甚至一整天，或者连续几天或几周的几个小时才能学到东西。这意味着这些建议不应与旅游景点归为一类，旅游景点通常遵循“既然你在这里，为什么不也看看这个/做这个/在那里吃饭”的原则。参加学习体验需要不同级别的规划，而且很少会与你发现的特定区域挂钩，而是与你计划在某个城市花费更长时间相关。 PrinceGloria (讨论) 22:01, 2013年10月28日 (UTC)

这并不比将它们放在主文章上更强有力，就像将酒店放在主文章上一样。文章页面上的内容是因为它们对城市整体体验的重要性，而不是因为城市整体体验对它们个体的重视程度。 Texugo (讨论) 22:18, 2013年10月28日 (UTC)

回到前面一点，我不太同意 Texugo 之前说的。虽然旅行者可能不太需要知道如何在一个他们只短期访问的城市注册长期课程，但我发现提供关于地区学院和大学的简要通用信息是让读者更好地了解城市整体身份或“感觉”的好方法。我认为对于特大城市的区域文章来说尤其如此——特别是当该区域包含一所大型大学，而这所大学是其独特身份的重要组成部分时，例如 Buffalo/Elmwood Village。然而，这些信息可能不应以列表的形式出现。 -- AndreCarrotflower (讨论) 22:50, 2013年10月28日 (UTC)

我并非在表达个人意见，而是在反映关于该主题的传统建议。虽然我同意在某些情况下，简要提及当地大学可能具有文化相关性，但我认为这些是普遍规则的例外——描述典型中小城镇的社区大学在很大程度上是不相关的且不必要的。无论如何，除非校园内有真正值得一看的东西，否则它们不应成为“看点 (See)”条目；除非它们确实提供短期内可用且可能对旅行者感兴趣的东西，否则它们不应成为“学习 (Learn)”条目。在“了解 (Understand)”部分中进行简短的文字描述（或更可能是在大学夜生活区域的提及）是可以的，如果它确实与城市的身份相关。随意提及“Cumbersome County Community College”或“Bumpkin River Technical School”应被普遍禁止。Texugo (讨论) 00:13, 2013年10月29日 (UTC)

我完全同意 Texugo 的观点。不幸的是，我们让一些文章（甚至被评为星级文章）在“学习”部分包含过多的信息，这导致了错误的蔓延。我们应该在未来的提名讨论中强调这一点。LtPowers (讨论) 01:05, 2013年10月29日 (UTC)

即使我们不将其放入“学习”部分，我仍然认为这些信息可以也应该包含在某处。同样，旅行者可能不需要知道如何在一个他们几乎不会在那里待那么久的城市注册学期课程，但了解他们选择访问的地点对于旅行者来说确实是更好的。 -- AndreCarrotflower (讨论) 02:17, 2013年10月29日 (UTC)

我同意 Andre 的观点，而且我还会说，在像 Clinton (New York) 这样的大学城，不提供当地大学网站的链接是荒谬的，因为即使大学没有建筑上的意义，也没有吸引非学生或非雇员的文化活动，它几乎是那里唯一重要的东西。Ikan Kekek (讨论) 04:30, 2013年10月29日 (UTC)

[缩进重置] 我同意上面的大部分观点。我坚信关于城镇作为大学城特点的信息应该放入“了解 (Understand)”部分，而不是一个单独的章节，此外，教育机构中“可看/可参观”的场所应该放入“看点 (See)”或“做 (Do)”部分，具体取决于机构的性质。
我认为很少有什么“学习”内容不是简单的“做”，并且值得一个单独的章节。而且，我仍然认为大多数内容在较大的城市层面会处理得更好，就像大使馆、医院或机场应在城市层面列出，而不是局限于区域并剥夺城市级别的信息。这并不意味着特定区域的文章不应在其“了解”或“方位”部分提及这些内容，如果城市独有的服务/机构的设置影响了它们的特征或在其中的方位。 PrinceGloria (讨论) 05:45, 2013年10月29日 (UTC)

在非常大的城市中，我认为虽然教育机构的例子值得简要提及，但实际的条目通常属于区域文章。例如，新学院大学 (New School University) 有很多音乐会和讲座，这些应该在 Manhattan/West Village 文章中列出（我不确定是否已列出），而不是在 Manhattan 文章中。Ikan Kekek (讨论) 06:06, 2013年10月29日 (UTC)

这看起来很像“做 (Do)”的一部分。我们没有单独的“体育 (Sports)”类别，那为什么需要一个单独的“在教育机构做事 (doing)”类别呢？它们都是“做 (Do)”。如果一个区域有很多“做”的事情，我们用三级标题就可以很好地处理。 PrinceGloria (讨论) 09:47, 2013年10月29日 (UTC)

你说得很有道理。我只是在想，消除所有“学习”的子标题并将大部分条目移到“做 (Do)”以及一些到“看点 (See)”部分，是否值得付出额外的努力。 Ikan Kekek (讨论) 09:51, 2013年10月29日 (UTC)

让我们 just 避免在新建和扩充的文章中再添加“学习 (Learn)”章节，对于现有的，我们将在后续逐一处理。有很多清理工作要做，而且我们中的一些人实际上正在这样做，只要我们同意这样做（并且不通过创建新的“学习”章节来加剧问题），它最终会得到解决。 PrinceGloria (讨论) 10:15, 2013年10月29日 (UTC)

我没有检查过，但可能有一些文章模板显示可选的“学习 (Learn)”子标题，如果存在共识，就需要将其删除。另外，Where you can stick it 可能需要检查。Ikan Kekek (讨论) 10:27, 2013年10月29日 (UTC)

我很高兴停止使用“学习 (Learn)”章节。我发现人们经常想列出大学，但这实际上与旅行者信息无关。（除非大学值得参观，例如 Heidelberg，但那样应该列在“看点 (See)”下）不过，我认为具体的课程（烹饪、语言学习等）仍然是值得拥有的。Andrewssi2 (讨论) 10:30, 2013年10月29日 (UTC)

实际上，“学习 (Learn)”部分的目的常常被误解，不仅仅是列出大学、学院甚至公立学校，还被用作列出读者可能想知道的随机琐事，甚至“了解更多”关于目的地的资源。我不太确定我对于废除它的工作量有什么看法。Texugo (讨论) 11:58, 2013年10月29日 (UTC)

即使课程为期数周（例如 Chicoutimi-Jonquière，Collège du Jonquière 的三周强化法语课程以其闻名，但没有当地学生），简要提及学校在“了解 (Understand)”部分，与城镇的其他工业历史（纸浆/造纸、铝业）一起就足够了。一个“学习 (Learn)”章节只会增加很少的内容。

是的，当一个巨大的大学坐落在一个原本很小的城镇时，一所学校确实可以合法地主导一篇文章。一篇关于“State College PA”的文章，如果该学校和球队是城镇最著名的地标，那么在不将 Paterno 的雕像转动180度“让他可以视而不见桑达斯基事件”的情况下，就会是不完整的。尽管如此，诸如“Normal IL 是以‘师范学校’或州立师范学院命名的”之类的信息应放在“了解 (Understand)”中，而校园本身（如果建筑风格独特或有博物馆或音乐厅）很可能属于“看点 (See)”（如果有具体的活动则属于“做 (Do)”）。我们不需要“学习 (Learn)”作为一个单独的章节，因为学校是为旅行者描述的，而不是为期四年的临时居民。K7L (讨论) 14:50, 2013年10月29日 (UTC)

不仅仅是大学。一个问题是我们是否想把一个公开的大学讲座系列、一个烹饪学校、一个葡萄酒和奶酪品尝课程、一个当地手工艺品工作坊，以及 5 个西班牙语交流学校放在“做 (Do)”的一个子目录中。 Texugo (讨论) 15:00, 2013年10月29日 (UTC)

我个人的观点是，“学习 (learn)”和“做 (do)”之间没有多大实际区别。我考虑的是，“学习 (Learn)”章节应被废弃，即它对现有文章仍然有效，并且对于想要从中获得很多学习机会的新文章（如你的列表）。但是，它不应该实际要求新文章使用，或者对于那些想要更新而不需要它的旧文章。这种方法对 WV 来说会不会太模糊？ Andrewssi2 (讨论) 15:27, 2013年10月29日 (UTC)

个人而言，如果文章模板要这样更改，我宁愿不只做一半。实际上，我认为“做 (Do)”章节已经经常被子目录负担过重（公园、剧院、音乐、体育、节日、活动、海滩、徒步小径、组织好的旅游、乘船游览、火车旅行等等）。我认为参加课程是一种足够不同的活动类型，我们可以留着它。仅仅因为它在技术上是“做”某事，并不意味着它必须放在“做 (Do)”里。毕竟，喝酒、泡夜店、洗衣、上网也是“活动”，但我们不需要把*所有*东西都放进“做 (Do)”里。Texugo (讨论) 16:18, 2013年10月29日 (UTC)

火车和船只如果作为交通工具则属于“出行 (Get around)”，唯一的例外是观光环线游，除了出发点外，不能在其他地方下车。 “食物、燃料、住宿”类别更多的是基础设施而非娱乐（总得在某处“吃”和“睡”），而“洗衣”似乎更常作为其他类别（特别是露营地）中的一个脚注，而不是独立的自助洗衣店。“Wi-fi”也正走向同一方向，因为它在大多数热门目的地（如咖啡馆、酒店/汽车旅馆和公共图书馆）中都普遍存在；独立的“网吧”正在消亡。我犹豫是否要利用“连接 (Connect)”的存在来证明“学习 (Learn)”作为一个章节（而不是子章节）的合理性，因为随着 Wi-fi 在大多数热门目的地似乎无处不在，“Connect”的日子可能屈指可数。如果说有什么的话，“活动 (Events)”比子章节更有资格成为一个章节（因为每个小镇至少有一个年度旅游节），而“学习 (Learn)”应该被降级为“做 (Do)”的子章节，或者完全删除。如果“骑马”是“做 (Do)”，那么“学骑马”也应该是“做 (Do)”，因为它们几乎是相同的活动。Wikivoyage:Where you can stick it#Learn 和文章模板确实需要更改，以便废除它作为一个新文章的章节，即使现有的混乱局面没有立即得到处理。太多的学习超出了我们的范围（例如：多年的文凭和学位课程），而剩下的仅仅是目的地众多活动中的一项。K7L (讨论) 21:38, 2013年11月24日 (UTC)

帮助页面清理

我一直在尝试清理爱尔兰页面的格式。我遇到的最大问题是遵循样式手册页面。我觉得它们很难记住、扫描和冗长。因此，我尝试为时间日期格式页面提出了自己的版本，我认为它更容易使用。

我尝试改进的一些方面

• 大型粗体示例。 这是为了更容易快速扫描页面。你应该能够仅从示例中了解如何进行大多数格式设置，而无需阅读文字。
• 仅正确示例。 我只使用过正确的示例。如果你在页面上看到一个示例，你就知道你可以使用它。这也有助于使页面更短。
• 简短。 我尽量保持页面和笔记尽可能简短。它不需要顶部的“页面摘要”框。我还删除了顶部的介绍性段落，它实际上并没有说任何东西。
• 一致的格式。 我试图使页面尽可能一致。例如，所有示例始终显示在左侧，而不是在句子中的随机位置。这应该有助于人们快速扫描示例以找到他们正在寻找的示例。

新版本位于 Wikivoyage:Time and date formats/New version。

46.7.249.24 20:47, 2013年11月2日 (UTC)

个人而言，我不喜欢大字体。我没有考虑过其他方面——字体大小太刺眼了。如果你愿意尝试正常大小，我会再看一眼。否则，我认为它不会取代现有页面——尽管你可以保留它供你自己和喜欢它的人使用，作为一种替代。但你为改进所做的努力值得称赞。Nurg (讨论) 00:01, 2013年11月3日 (UTC)

我更喜欢这个页面，因为它简洁明了，特别是格式一致，示例在左边，解释在右边。错误的示例总是令人困惑。其他人怎么看？-- torty3 (讨论) 00:09, 2013年11月3日 (UTC)

我认为创建一个“速查表”对大家很有帮助。在 Wikivoyage:Cheatsheet/Time and date formats 和 Wikivoyage:Cheatsheet/Listings 创建这样的页面是否可以？-- torty3 (讨论) 23:39, 2013年11月3日 (UTC)

这听起来是个不错的想法。我只有两个担忧：1）保持这些“速查表”的数量少，这样就不会造成额外的维护工作来与政策页面同步，以及 2）这些“速查表”应该是从主政策页面或其他简洁版本的信息中提取的示例列表，并且不应被用来创建既定政策的替代品。 -- Ryan • (讨论) • 23:51, 2013年11月3日 (UTC)

Alice 的提议

Alice 发邮件给我说她目前没有技术手段可以发布此消息而不泄露密码（例如在网吧的键盘记录器等），但她要求我代表她发布。

"我（和其他人）注意到你一直在努力完善我们的爱尔兰文章，添加了大量有用的信息，将其纳入我们独特的 列表 格式，并使格式一致且易于阅读——所以特别感谢你！

我也同意你的基本前提，即我们应该努力使我们的 MoS 页面更容易理解和记住。在这方面，**除非影响理解**，我认为最好是：

1）尽可能少地设置例外情况

2）从最普遍的情况开始

3）在存在的情况下，尽量遵循全球标准

4）在列表中，除非影响理解，否则缩写为最短形式 ****

5）在时间格式上保持一致。大多数人的大脑会更容易理解，如果存在一致的规则。我认为我们应该先列出较大的时间段，然后是逐渐变小的时间段。例如：

• 组合日期或月份与时间时，将年份、季节和月份放在前面，然后是星期几，最后是时间，例如： 5月-9月 周一-周五 10:00-14:00 而不是 10:00-14:00 周一-周五 5月-9月。
• 列出替代日期范围时（例如，季节性营业时间），用分号分隔替代项，例如： 镜厅 5月3日-9月8日 周一-周六 08:30-18:00；9月9日-次年5月2日 周四-周六 10:30-16:00。恐怖迷宫 2013 夏天 周一-周六 08:30-18:00；10月-2月 周五-周六 10:30-13:00；2014 夏天 周一-周六 08:30-19:15；
• 所有七天都使用 每日。 不要使用“每天”或“周日-周六”。例如： 6月-9月 每日 08:30-11:00, 12:30-18:00

我喜欢你删除了数量和单位之间不必要的（并且对新手来说是混淆的）HTML 空格。

因此，我更希望我们将 Wikivoyage:Measurements#Avoid_orphaned_units 的短语“除温度和电压测量外，我们倾向于在数字与其关联单位之间留一个空格，但是：”改为：

我们倾向于不分隔数字与其关联单位，但是

我也认为，尤其是在列表条目中，我们可以将当前小时/小时的缩写 hr 缩短为 h，这样我们就会看到“N'Boli 机场距离 42 公里（1.5 小时）车程，因为在一些地方，你可能不得不在坑洼的道路上以低于 30 公里/小时的速度行驶”。

感谢您考虑风格和格式问题，并大大改进了我们的爱尔兰文章！Alice”。

--118.93.67.66 04:08, 2013年11月3日 (UTC)

更改 Wikivoyage:Measurements 的提议最好在 Wikivoyage_talk:Measurements 提出。Nurg (讨论) 22:04, 2013年11月15日 (UTC)

我完全同意 Nurg。但是，过去曾有几次，在专业且合适的政策讨论页面达成共识后，有人突然冒出来并撤销了更改，理由是他们没有注意到之前的讨论。--118.93nzp (讨论) 22:13, 2013年11月15日 (UTC)

我只想指出，我不仅是发布上述引文的信使——我对“Alice 的提议”没有任何异议。

我特别喜欢她关于“尽可能少地设置例外情况”的提议，以及其在 tdf 中的应用。她关于“先列出较大的时间段，然后是逐渐变小的时间段”的提议，现在尤为有益，因为我们出色的新列表编辑器经常将营业时间数字紧跟在电话号码数字之后，并且可以避免进行自定义编辑，例如 这一次，其中

• 洛桑旅游局 (主火车站，以及乌希（Ouchy）的 Place de la Navigation 9，就在 M2 车站对面)， ☏ +41 21 613-7373。 每日 09:00-19:00。 旅游局办公室的工作人员或电话可以几乎随时为你安排符合你价格范围的酒店。此外，他们还有一张精美的免费城市地图和大量有用的印刷资料，有英语、法语、德语和意大利语版本。 

显然比我们目前的建议 洛桑旅游局 (主火车站，以及乌希（Ouchy）的 Place de la Navigation 9，就在 M2 车站对面)， ☏ +41 21 613-7373。 09:00-19:00 每日。 旅游局办公室的工作人员或电话可以几乎随时为你安排符合你价格范围的酒店。此外，他们还有一张精美的免费城市地图和大量有用的印刷资料，有英语、法语、德语和意大利语版本。 

• 洛桑旅游局 (主火车站，以及乌希（Ouchy）的 Place de la Navigation 9，就在 M2 车站对面)， ☏ +41 21 613-7373。 09:00-19:00 每日. 旅游局办公室的工作人员或电话可以几乎随时为你安排符合你价格范围的酒店。此外，他们还有一张精美的免费城市地图和大量有用的印刷资料，有英语、法语、德语和意大利语版本。  --118.93nzp (讨论) 22:10, 2013年11月15日 (UTC)

为什么 Alice 不能使用 IP 地址，如果她担心键盘记录器？我有点不情愿评估一个由不愿意站出来讨论的人提出的建议。我认为我们应该将此搁置，直到 Alice 可以公开讨论她的提议的优点、解释并（如有必要）捍卫它。--Inas (讨论) 03:14, 2013年11月19日 (UTC)

我对关于列表编辑器的引用感到困惑。现有的列表模板和几年前的大致相同，与任何新东西都无关。--torty3（讨论）03:34, 2013年11月19日 (UTC)

介绍 Beta Features（测试功能）

（抱歉，用英文写。如有需要，请翻译）

我们想通知您关于Beta Features（测试功能），这是维基媒体基金会的一项新计划，允许您在新功能向所有人发布之前进行试用。

您可以将其视为一个数字实验室，社区成员可以在其中预览即将推出的软件，并提供反馈以帮助改进它们。这个特殊的偏好设置页面允许设计人员和工程师大规模地试验新功能，但以一种不具破坏性的方式。

Beta Features（测试功能）现已在MediaWiki.org上准备就绪，可供测试。它也将在本周四，11月7日，在Wikimedia Commons和MetaWiki上发布。根据测试结果，计划于2013年11月21日向全球所有维基百科发布。

以下是本周您可以测试的第一个功能

• Media Viewer（媒体查看器） — 以大尺寸或全屏查看图像
• VisualEditor Formulæ（可视化编辑器公式）（适用于拥有VisualEditor（可视化编辑器）的维基）— 编辑页面上的代数或方程
• Typography Refresh（排版更新） — 使文本更易读（周四推出）

您想立即尝试 Beta Features（测试功能）吗？在您登录 MediaWiki.org 后，您的“偏好设置”旁边会出现一个小的“Beta”（测试版）链接。点击它即可查看您可以测试的功能，勾选您想要的功能，然后点击“保存”。请访问Beta Features（测试功能）页面了解更多信息。

在测试完 Beta Features（测试功能）后，请在此讨论页面上告知开发者您的想法 — 或者在此Bugzilla上报告任何错误。您也欢迎参加本周五，11月8日，18:30 UTC在此 IRC 办公室时间聊天。

Beta Features（测试功能）由维基媒体基金会的设计、多媒体和可视化编辑器团队开发。他们将与其他开发人员一起，每隔几周向这个实验性计划添加新功能。他们非常感谢所有帮助创建这个项目的社区成员 — 并期待未来有更多富有成效的合作。

尽情享受，别忘了告诉开发者您的想法！Keegan (WMF)（讨论）19:48, 2013年11月5日 (UTC)

通过Global message delivery（全局消息传递）分发（页面错误？在此处修正），19:48, 2013年11月5日 (UTC)

我之前检查过这个，我必须说，我喜欢Media Viewer（媒体查看器）功能。它和我们的静态地图配合得很好，在文章缩略图里通常太小看不清楚。一旦他们开始进行全站测试，我建议我们积极参与。 James A ▪ 讨论 01:06, 2013年11月6日 (UTC)

Template:PrintDistricts

上个月，此模板似乎被单方面更改了（尽管我可能错过了讨论）。虽然我赞成减少甚至取消打印在此警告中的作用，但我会想把新的措辞改为更简洁的内容：也许是“XXX是一个大城市，有几个地区文章包含特定景点、餐厅和住宿的信息。”

改变这个常用模板的SEO影响也值得考虑——之前的措辞和WT（Wikitravel）的完全一样。--Nick^讨论02:24, 2013年11月5日 (UTC)

你的措辞很好，Nick，并且在WV（Wikivoyage）沉没之前，我们始终把SEO放在心上是件好事。--118.93.67.6611:47, 2013年11月5日 (UTC)

我希望你的意思是“WT”：P 措辞看起来不错。 James A ▪ 讨论 11:49, 2013年11月5日 (UTC)

哎呀，我的邪恶计划被我自己的口误暴露了。我得去卖我的IB股票了... Ibobi 04:15, 2013年11月5日 (UTC)

获取打印件

如果能有一种简单的方法，可以获取一个非常大的城市文章及其所有地区文章的PDF（或打印件），那就太好了。能否在左侧的“打印/导出”部分添加一个“将所有地区下载为PDF”的选项？AlasdairW（讨论）22:49, 2013年11月9日 (UTC)

想尝试 MediaWiki 的新搜索引擎 CirrusSearch 吗？

大家好！

我们想邀请您的维基成为我们新搜索功能 CirrusSearch 的早期使用者。

CirrusSearch 相对于目前的搜索引擎 LuceneSearch 有很多优势，包括：

• Cirrus 可以展开模板，因此搜索时可以找到文章中包含的模板文本。
• Cirrus 更新搜索索引的频率更高。这意味着文章的更改将更快地反映在搜索结果中。
• Cirrus 比 LuceneSearch 更好地支持不同语言。我们其他的早期使用者（例如孟加拉语维基百科）迄今为止对新搜索都感到满意。

如果您同意成为早期使用者，CirrusSearch 将与当前搜索并行运行，因此您可以使用新旧搜索来测试 CirrusSearch。最终，CirrusSearch 将部署到所有维基，并取代当前的搜索。通过提前试用，您可以帮助我们使其对所有人更好，并确保它满足您的需求。如果您宁愿等到我们开始在其他地方部署它，那也没关系。

如果您有任何问题，请在此mediawiki.org 上的我的讨论页上留言。

此致，

--Dan Garry, Wikimedia Foundation（讨论）22:21, 2013年11月7日 (UTC)

我觉得这听起来很棒。我一直不太满意我们目前的搜索功能。 Texugo（讨论）13:10, 2013年11月8日 (UTC)

我想我们关于模板的主要担忧是{{listing}} — 模板不添加参数中提供的内容之外的文本，但我们需要它（在替换之前或之后，我不在乎…）的内容出现在任何搜索结果中。 K7L（讨论）04:03, 2013年11月11日 (UTC)

我总是渴望尝试新事物 :-) 请在它在这里进行测试部署时告知我们，谢谢！Nicolas1981（讨论）07:05, 2013年11月28日 (UTC)

我想 Dan Garry 可能有点失望，他最初问我们是否想成为早期使用者，已经三个多星期了，我们还没有做出足够的决定给他一个明确的答案。

请问我们的共识是什么？--118.93nzp（讨论）07:17, 2013年11月28日 (UTC)

请给出您的想法……

关于一个将来 FTT（Focal Topic Tournament，焦点话题比赛）的议题，自从它被提名以来我一直感到困扰。

我在这里发布一个链接，因为我认为“Bargaining”（讨价还价）可能不是一个高流量的文章。

--AndreCarrotflower（讨论）01:35, 2013年11月10日 (UTC)

另一个首页

只是快速告知一下，目前关于网站首页的未来正在进行另一场讨论，您可以在这里阅读。请在此处留下您的评论、想法或建议。--Nick^讨论00:05, 2013年11月12日 (UTC)

文章的第一次编辑没有“感谢”按钮

大家好。我想感谢一位用户创建了一个讨论页面并发表了第一个帖子，但我发现没有“感谢”按钮，所以我就发到了用户的用户讨论页上。这是一个已知的问题吗？Ikan Kekek（讨论）08:27, 2013年11月15日 (UTC)

对我来说，它起作用了，Mick，我刚刚给你发送了一个“感谢”，感谢你创建了一个页面。顺便说一下，请试试这个。--Saqib（讨论）13:03, 2013年11月15日 (UTC)

那我不知道是什么原因造成了这个问题。 Ikan Kekek（讨论）22:12, 2013年11月15日 (UTC)

User:Rschen7754/The future of Wikivoyage

它只完成了一半，但我认为它提供了足够的相关内容。--Rschen775423:31, 2013年11月16日 (UTC)

我还没有读完，但作为最近从维基百科加入的贡献者，我觉得它很有趣。我想了解更多关于这个社区的信息，以及 Wikivoyage 未来几年的战略计划。谢谢分享！Edge3（讨论）05:32, 2013年11月17日 (UTC)

您是指 Wikivoyage 的未来，还是指英语 Wikivoyage 的未来？--Alexander（讨论）06:13, 2013年11月17日 (UTC)

我针对的是英语 Wikivoyage。其他语言的 Wikivoyage 在适应 Wikimedia 方面做得比这个项目好得多。但我的论文中的观点可能也与他们相关。--Rschen775406:27, 2013年11月17日 (UTC)

这是不正确的。例如，俄语 Wikivoyage 从未尝试过“适应 Wikimedia”。我们没有义务这样做，而且只有维基百科的用户才认为 Wikivoyage 应该看起来像维基百科。事实上，90% 的维基百科用户不知道什么是旅行指南（他们从未旅行过和/或从未用过旅行指南）。因此，听从维基百科用户的意见，总的来说，是一个非常糟糕的主意。

请不要个人化，但您的文章，即使是在草稿版本中，也已经表明旅行内容的发展远非这个项目的首要任务，至少在您的视角中是这样。这是一个非常根本的问题，我真诚地希望这种态度不会影响 Wikivoyage 的其他语言版本。--Alexander（讨论）11:15, 2013年11月17日 (UTC)

我在哪里说过我想让 Wikivoyage 看起来像维基百科？您能否请提供您的其他陈述的依据？最后，“因此，听从维基百科用户的意见，总的来说，是一个非常糟糕的主意”这句话只是一个刻板印象。--Rschen775411:22, 2013年11月17日 (UTC)

嗯，我这样读你的文本。你链接到了维基百科关于共识的政策，并且你反复提到 Wikimedia 的政策/惯例，而这些无论如何都起源于英语维基百科。而且有一个非常奇怪的说法/指控，说 Wikitravel 曾反对 Wikimedia（我不知道有谁说过或做过这种事，除了，也许，IB，但他们在分叉前对 WT 没有任何严肃贡献）。

此外，你声称现有政策会触发类似内容的创建，并且 WV（Wikivoyage）永远不会和 WT（Wikitravel）不同。然而，页面横幅和动态地图等完全兼容现有政策的事物反驳了这一论点。到目前为止，我只在你的文本中看到一个想法，那就是让 Wikivoyage 对维基百科用户更友好，这基本上是可以的，但相比于旅行者相关功能，如地图、PDF导出、与OSMand集成、在移动设备上下载单个文章等，其重要性相对较低……以及寻找具有真实旅行经验的人作为新编辑。他们不是维基百科的用户。他们来自 TA（Traveler's Association，旅行者协会）和 TT（Traveler's Tips，旅行贴士）论坛，以及个人旅行博客的作者。这才是我们将要遵循的方向。--Alexander（讨论）17:25, 2013年11月17日 (UTC)

你可能对 Wikimedia 了解不多。英语维基百科往往是其中的异类，因为许多其他 Wikimedia 站点都有意选择走不同的方向。又来了，把维基百科用户当成二等公民，还有这种刻板印象。“这是我们将要遵循的方向”极其傲慢。--Rschen775419:32, 2013年11月17日 (UTC)

当我说“我们”时，我指的是俄语 Wikivoyage，因为我们在这方面有非常稳固的共识，并且对俄语维基百科也有非常相似的看法，它比我熟悉的任何 Wikimedia 项目都要奇特。如果您认为我的话傲慢或冒犯，那是您的选择，但我希望这里的大多数人都明白，大多数维基百科用户不是经验丰富的旅行者。这并不意味着他们很糟糕或“二等公民”，如您所说。仅仅意味着 Wikivoyage 应该从其他地方吸引编辑。--Alexander（讨论）19:55, 2013年11月17日 (UTC)

页面横幅和动态地图只是表面文章；内容仍然是一样的，尤其是对于像 Google 这样的文本搜索引擎。我的观点是，我最近看到太多的人对待新手很苛刻，即使是管理员……而且他们往往是维基百科用户。我们在这里是为了创造世界上最好的旅行指南，我们需要任何可以得到的人来做这件事。地理、历史、夜生活专家、交通专家、摄影师、文案编辑、模板编码员、旅行专家、破坏者防治者等在这里都有其功能。我们不能挑剔谁可以进来，谁不可以。--Rschen775420:02, 2013年11月17日 (UTC)

这说明了我的观点。如果您曾经尝试过使用 Wikivoyage 的文章，您就会明白，一篇带有坐标和最新地图的文章，比一篇只有简单兴趣点列表的 WT（Wikitravel）风格的文章要好得多。不是为了 Google，而是为了实际的读者和旅行者。Google 排名是一个完全不同的问题，但文案编辑和夜生活专家的涌入在这里也帮助不大。

另一个问题是你不能什么都要，你必须做出选择。如果你最终得到一群“文案编辑”，这不会让旅行维基变得更好。--Alexander（讨论）20:18, 2013年11月17日 (UTC)

我确实同意你关于尽可能多地吸引人们参与的看法，Rschen7754 — 我认为这对我们的长期生存非常重要。希望你不要介意（咳咳）这个！我也大致同意你的其他观点 — 这篇文章是一个很好的起点，可以解决我们目前面临和将要面临的问题。我希望在 1 月份我们迎来 WMF（Wikimedia Foundation，维基媒体基金会）一周年生日时，我们可以进行一次全面的“维基状态”审查。--Nick^讨论20:34, 2013年11月17日 (UTC)

禁用“Ref”标签？

我们在这个网站上不使用 ref（参考）标签，而且来自维基百科等需要 ref 的网站的新用户，可以理解地使用 Wiki 语言功能来插入它们，这造成了一团糟，页面底部显示着这条大红字信息：“Cite error: <ref> tags exist, but no <references/> tag was found.（引用错误：存在<ref>标签，但未找到<references/>标签。）”是否有任何重要原因不能在这个网站上禁用创建 ref 标签的功能？抱歉，如果这个问题之前已经问过并回答过了；我隐约记得之前有过这个讨论，但随着越来越多的维基百科用户来到这里，这个问题将变得越来越严重，所以找到一种更容易处理的方法会很好。 Ikan Kekek（讨论）22:14, 2013年11月15日 (UTC)

我认为这必须由技术人员来完成。--Rschen775422:19, 2013年11月15日 (UTC)

如何提出建议？Ikan Kekek（讨论）22:22, 2013年11月15日 (UTC)

我们首先需要共识，然后我们将进入 bugzilla。--Rschen775422:38, 2013年11月15日 (UTC)

既然我们从不使用它们，那么达成共识应该不难。我曾多次尝试从编辑窗口上方的编辑栏中删除 ref（参考）和 gallery（图库）按钮，但一直未能弄清楚。如果有人能帮忙，我也将不胜感激。 Texugo（讨论）23:04, 2013年11月15日 (UTC)

我们从未使用过它们，并且明确删除了Template:Ref 和Template:Note。如果我们认为这足以说服技术专家，我现在就可以宣布达成共识。 LtPowers（讨论）02:08, 2013年11月16日 (UTC)

这不是共识，讨论才开放了 4 个小时。--Rschen775402:14, 2013年11月16日 (UTC)

明确这一点可能会有帮助，我们需要的不是关于是否使用 ref（参考）的新共识 — 这已经确立了，而且没有人建议重新讨论 — 而是需要一个关于技术上禁用它们，使它们不再被识别，也不会产生鲜红错误消息的具体共识。 Texugo（讨论）02:35, 2013年11月16日 (UTC)

拜托，Rschen。过去 X 年的讨论已经非常清楚地表明，Wikivoyage 没有意愿或共识添加参考文献。我不需要一堆人进来告诉我他们的回答会是什么。 LtPowers（讨论）02:36, 2013年11月16日 (UTC)

你怎么知道社区存在共识 — 你是声称代表社区发言吗？你怎么知道所有其他活跃用户都会同意这件事？你不知道，除非你给了每个人发言的机会。--Rschen775402:43, 2013年11月16日 (UTC)

过去 X 年的讨论已经非常清楚地表明，Wikivoyage 没有意愿或共识添加参考文献。我不需要一堆人进来告诉我他们的回答会是什么。 LtPowers（讨论）01:10, 2013年11月17日 (UTC)

• 支持 让我们建立一个我们可以引用的共识。我继续支持禁止 ref（参考），并且我支持禁用创建它们或使它们被识别的功能。 ChubbyWimbus（讨论）07:03, 2013年11月16日 (UTC)
• 既然我们不使用它们，那就删除它。 Nurg（讨论）09:53, 2013年11月16日 (UTC)
• 供记录，我也支持。--Rschen775409:56, 2013年11月16日 (UTC)

我们什么时候开始在讨论中使用项目符号？这整个对话不是源于我们**不**是维基百科的事实吗？总之，Ikan 的想法很棒，我完全赞同。 Nick1372（讨论）16:13, 2013年11月16日 (UTC)

• 虽然我们通常不使用 ref（参考），但有时它们可能很有用。例如，这篇文章Traveller's_diarrhea。因此，我不支持完全摒弃它们。 Travel Doc James（讨论 · 贡献 · 邮件）10:27, 2013年11月17日 (UTC)
  • ……而这正是我们进行这些讨论的原因，以确保存在共识。--Rschen775410:38, 2013年11月17日 (UTC)

  James，我有点困惑。我看不出Traveller's diarrhea（旅行者腹泻）这篇文章中有任何 ref（参考）标签。我是否漏掉了什么？ Nick1372（讨论）14:33, 2013年11月17日 (UTC)

是的，我也是。那篇文章里没有 ref（参考）。你在想别的吗？我很有信心，没有任何页面上我们已经决定可以接受使用<ref>。 Texugo（讨论）17:54, 2013年11月17日 (UTC)

没有，但 IMO（In my opinion，在我看来）可以有/应该有。 Travel Doc James（讨论 · 贡献 · 邮件）09:40, 2013年11月26日 (UTC)

为了什么目的？那篇文章有什么特别之处需要引用来源？ Texugo（讨论）10:17, 2013年11月26日 (UTC)

我也看不出那篇文章需要引用来源。列出信誉良好的旅行医疗书籍也许还可以，但我看不出文章中的陈述为何需要引用来源。（另外，抱歉使用了项目符号。我意识到我们在这里不使用项目符号，也不在共识讨论中使用“支持投票”。我只是觉得，与其继续讨论是否需要支持记录，不如绕过那个讨论，获得支持/共识，以便我们可以结束讨论，因为我也认为这是相当没有争议的。显然，我可能错了，所以 Doc James 的担忧必须得到解决） ChubbyWimbus（讨论）14:22, 2013年11月26日 (UTC)

使用其他语言页面的信息

我们能做些什么来帮助编辑者和旅行者使用其他语言的页面吗？我可以打开页面用 Chrome 翻译（但我通常用其他浏览器），但链接到一个翻译过的页面会更好。我最近发现，苏格兰的Balloch有一个比英语页面更大的德语页面。如果一个目的地有其他语言的星级指南，那么它可能值得一看，这也会很有用。我也希望能看到一个地图，显示所有语言的文章 — 也许在 meta（元维基）上按国家显示。是否有关于从其他语言导入内容的指南？我意识到其中大多数可能不可行，它们只是为了激发思考的一些想法。 AlasdairW（讨论）23:27, 2013年11月19日 (UTC)

如果您问的是您所想的 — 其他语言页面的链接 — 我们已经有了。它们位于侧边栏的“语言”部分，以及移动页面底部的蓝色大按钮（我们从Wikidata获取）。此外，如果您访问某个地点的 Wikidata 页面，您会得到一个所有 Wikivoyage 不同语言页面以及所有维基百科不同语言页面的列表。至于添加星级文章的指示器，这是一个很棒的主意，并且完全可行。维基百科用特色文章和优秀文章做到这一点，为什么我们不能呢？我不知道具体细节，但您可以在某个地方找到信息。带有所有语言文章的地图是不可能实现的。我敢肯定您可以做到，但这会是太大的工作，回报太少。我们没有“导入”其他语言信息的指南，因为它根本就不是我们做的。维基百科的普遍习俗是人类进行翻译，而不是机器人。任何自动翻译都是不可靠的。如果您懂多种语言，并且看到德语版本中有趣的内容（您知道它是真实的），那么将其添加到英语版本会很好希望这能澄清一些事情。 Nick1372（讨论）01:35, 2013年11月20日 (UTC)

我使用了一个自动翻译的页面来帮助我将Balloch（巴洛赫）的住宿列表从德语复制到英语页面（我懂一些德语，但直接阅读德语文章会很慢）。自动翻译的文本不足以直接放在页面上，但可以给编辑者提供足够的列表信息，以及任何主要链接，以便他们用自己的语言添加到文章中。有一些关于从维基百科复制内容的指南，以及一个用于归属的模板 — 如果我翻译其他语言的内容，是否有特殊的归属考虑？ AlasdairW（讨论）08:26, 2013年11月20日 (UTC)

我猜您决定信任自动翻译的页面是否可靠。我不会，但这是我的意见。我认为您不需要从另一个 Wikivoyage 翻译时进行任何归属，并且非英语维基百科与英语维基百科的归属方式应该相同。我相信它们都使用 CC-by-SA 版权，因此不应该有问题。 Nick1372 (讨论) 2013年11月21日00:56 (UTC)

没问题，但 Wikivoyage 的政策是应该给出署名。所以，无论引用的是哪个版本的维基百科，至少要在编辑摘要中注明您是从哪里借用文本的。 Ikan Kekek (讨论) 2013年11月21日01:10 (UTC)

确实如此…… CC-BY-SA 的核心是“署名”……该许可证要求署名原作者。 K7L (讨论) 2013年11月21日19:16 (UTC)

关于商标政策草案的评论征集

大家好，

维基媒体法律团队邀请您参与制定新的维基媒体商标政策。

自 2009 年以来，现行的商标政策旨在保护维基媒体标记。我们现在正在更新这项政策，以更好地平衡标记的允许使用与法律要求，使其得以保留给社区。新的商标政策草案已准备就绪，供您在此审阅，并鼓励您在此讨论。

如果您能将此消息翻译成您的语言，以便社区更多成员参与讨论，我们将不胜感激。

谢谢，
Yana & Geoff

“Wikivoyage”标记的状态如何？它将注册为 Wikivoyage 基金会还是 Wikimedia 基金会的商标？我看到“Wiki Voyage Offline”已以 2 美元的价格打包销售，这是对我们（所谓的免费）数据库转储的重新包装。或许他们应该换个名字，以免显得与 WMF 或主题组织有关联？ K7L (讨论) 2013年11月20日21:42 (UTC)

管理员的不当行为

我意识到您目前是一个比英语维基百科小得多的项目，但请问英语维基百科的“管理员公告板”对应的页面是什么？ --118.93.239.53 2013年11月23日00:58 (UTC)

118.93nzp，Wikivoyage:管理员讨论页。 --Saqib (讨论) 2013年11月23日01:05 (UTC)

不，那不正确。我们没有完全等同的页面；这取决于您想做什么。对于关于管理员如何工作的普遍性问题，Saqib 的建议是好的。对于具体担忧，应该在管理员的讨论页提出。 LtPowers (讨论) 2013年11月24日20:51 (UTC)

LtPowers，但如果他对我有意见，我不会允许他填满我的用户讨论页。抱歉。 --Saqib (讨论) 2013年11月24日20:57 (UTC)

目前我们只有一个酒吧作为集中讨论空间，供管理员和其他人使用。我们正在讨论将其拆分，我提议设立四个页面：一个经过改进的评论请求，一个vip（紧急事务关注），一个用于新想法的建议/提案页面，并将酒吧留作其他网站讨论。 --Inas (讨论) 2013年11月24日21:35 (UTC)

“书籍”的问题

我使用“书籍”工具收集和整理了印度尼西亚：巴厘岛和龙目岛的所有内容，制作了一本书。然后将其下载为 epub 格式以供我的 Nook 阅读；我对此非常满意。

这似乎是与他人分享的明显方法。维基百科上关于书籍的页面描述了如何保存到我的用户页，或许也能保存到社区。不幸的是，我没有描述中的页面部分。

显然，我目前能制作的唯一方法是删除我已经制作的书籍。这似乎有点奇怪。 Cormac Bracken (讨论) 2013年11月26日14:13 (UTC)

看起来您可以通过将它们移到您用户页面的不同子页面来创建多个书籍，例如 User:Davidbstanley/Books/Croatia 和 User:Davidbstanley/Books/Montenegro 就是一组现有示例。我在您的贡献中找不到任何书籍，但据我所知，它们只是一个包含某些预定义格式的内容目录和模板的普通维基页面；当用户请求书籍时，“书籍”扩展会抓取所列文章的当前版本并进行打包。 K7L (讨论) 2013年11月26日18:34 (UTC)

嗯，就是这样，我没有办法保存到自己的用户空间或其他任何地方，所以至今我还没有正式贡献任何东西。但在重读了“书籍”主页面后，我发现我的账户必须注册 4 天并有 10 次编辑，才能保存到我自己的用户空间。这真是太傻了。 Cormac Bracken (讨论) 2013年11月27日11:12 (UTC)

也许您可以请一位管理员 User:LtPowers 或 User:Wrh2 更改您的权限？ --Danapit (讨论) 2013年11月27日11:34 (UTC)

感谢 User:Texugo 将我加入“自动确认用户”组。理想情况下，我认为任何新用户都应该有权将书籍保存到自己的用户空间，因为这是一个“用户”功能而不是贡献者功能，似乎不带任何破坏风险。我认为这应该是 MediaWiki 软件的更广泛问题。 Cormac Bracken (讨论) 2013年11月27日12:18 (UTC)

我在Mediawiki 支持中心提出了这个问题。希望那里是正确的地方！ Cormac Bracken (讨论) 2013年11月27日12:18 (UTC)

将您设置为自动巡查员是否解决了问题？也许过早了，但我想看看是否能解决问题。 Texugo (讨论) 2013年11月27日12:21 (UTC)

嗯，这又是一个 Bugzilla 的站点请求，尽管在 Mediawiki 提出可以从根源上解决。请参阅Bugzilla：46944 （英语维基百科的请求）。我支持同样的做法。 -- torty3 (讨论) 2013年11月27日12:29 (UTC)

PDF 渲染

相关问题：有人知道如何控制 PDF 导出的扩展功能吗？我不明白如何控制它。例如，PDF 版本中没有显示地图标记，这是一个巨大的缺点。 --Alexander (讨论) 2013年11月26日19:30 (UTC)

.pdf 可能会只显示“打印版本”（因此类名“noprint”的任何内容都将被隐藏），我不太确定。 Wikivoyage:列表讨论页#我们在打印版本中丢失了列表编号 可能相关？ K7L (讨论) 2013年11月27日04:48 (UTC)

是的，也不全是关于 noprint。列表编号在 PDF 版本中显示得很奇怪，而且它无法包含 CSS。Mapframe 和列表编号确实会出现在可打印的网页版本中。用于 PDF 导出的扩展功能，mw:Collection，相当过时或不适合定制，而且像 Wikisource 这样的其他项目也在寻找解决方案，根据 User:AdamBMorgan 的说法。据称，WMF 正在研究替换 mw:PDF 渲染管道，以便在花哨的 Parsoid 工具上工作。 -- torty3 (讨论) 2013年11月27日05:22 (UTC)

谢谢您的回复！所以您也说我们应该坐着等待？我也有同样的印象。这有点不幸，因为 PDF 导出是一个非常有用的功能，对于旅游指南很重要。但至少现在的网页打印版本工作得很好。 --Alexander (讨论) 2013年11月27日06:56 (UTC)

epub 渲染

基本上是同样的问题。epub 导出看起来很有前景，但它也缺少地图标记，并且有一些奇怪的功能。是否有任何微调工具？ --Alexander (讨论) 2013年11月27日12:47 (UTC)

如何抵达，从哪里，怎么去？

关于“如何抵达”部分。我在这里读到一篇关于一个非英语国家的较小城市的文章，只说“大多数人乘汽车抵达，使用 7 号公路”。大多数游客来自同一国家，但我假设我们的读者是英语使用者，并且会从另一个国家旅行并乘飞机抵达。是否应该始终提供有关乘飞机来此的信息，告知哪个机场合适，以及如何从机场乘火车或巴士等？“如何抵达”部分的政策是什么？ --BIL (讨论) 2013年11月24日01:02 (UTC)

小城市文章的政策在Wikivoyage:小城市文章模板#如何抵达。 Nurg (讨论) 2013年11月24日01:11 (UTC)

需要有人制作模板

在关于修改反复不当编辑的政策的提案的长期讨论中，我们谈到了制作一个用于警告用户的模板。我们需要一位经验丰富的模板制作者来帮助我们。有志愿者吗？谢谢。 Nurg (讨论) 2013年11月21日19:22 (UTC)

还需要大量工作，但大概是这样的： User:Traveler100/sandbox-warning。 --Traveler100 (讨论) 2013年11月21日21:56 (UTC)

毛里求斯蓝湾

只是想知道是否有人熟悉该地区，可以看一下这两篇文章，Blue Bay 和 Blue-Bay。它们的标题非常相似，但似乎是关于不同主题的。是这种情况吗，还是应该合并？如果是不同的事物，那么可能需要有一些链接来在它们之间导航。 -- WOSlinker (讨论) 2013年11月23日21:47 (UTC)

链接到章节标题

我偶然发现了一个有趣的 Mediawiki 小工具，它让我想起了 User:Nicolas1981 几个月前提到的一个东西。试试在“偏好设置”>“小工具”>“HeadAnchor”中。我认为我们也需要为小工具和脚本设定一些指导方针，有些真的会改进网站，例如可选的分享功能到 Facebook 和 Twitter，尽管限制当然是好的。 -- torty3 (讨论) 2013年11月10日00:24 (UTC)

感谢这个提示！HeadAnchor 的效果很好，我唯一抱怨的是图片不像 Github 使用的那样可爱，但一旦修复，我认为它应该默认开启。为了提高我们的 Google 排名，让读者更容易分享特定的章节或子章节至关重要。我说任何人都会分享 URL……有没有科学研究表明 FB/Twitter 等分享按钮能提高分享率？ Nicolas1981 (讨论) 2013年11月27日10:02 (UTC)

Wikivoyage 的未来体现在其列表

英语 Wikivoyage 的未来看起来黯淡：关于共识的无休止的讨论，W.Frank 的无休止的化身……但这里有一个我最近在峰会上提出的非常实际的问题。Fussi 提出一个想法，将所有列表移动到 Wikidata，以便不同语言版本可以共享这些信息。尽管在近期内不可行，但这个想法提出了另一个问题：如何在不同语言中找到相同的列表？如何将我们的列表与维基百科上的文章和 Commons 上的分类联系起来？在我看来，这些问题是广泛讨论的“与维基媒体集成”的核心。欢迎任何想法和意见，但请先阅读我在 Meta 上的帖子。 --Alexander (讨论) 2013年11月17日17:37 (UTC)

很高兴听到与维基媒体其他部分持续整合，但我们真的需要开始那句关于“英语 Wikivoyage 的未来看起来黯淡”的老调吗？我们最近对另一位用户发表关于 Wikivoyage 未来厄运的预言非常不满，而且我越来越难以（从您过去发表的评论 开始，一直到这条评论）区分您和他的做法。亚历山大，您完全有权选择退出，而不是积极参与并帮助我们解决伴随我们迁移到 WMF 的人际冲突和文化冲突。而且，如果您将来选择重新活跃在 en:，那也是您的权利——至少我，我相信我不是唯一一个，会张开双臂欢迎您回来。而且我相信我们很乐意听到您提出的任何关于您所说问题的建设性解决方案。但是，在没有这些的情况下，从场外进行嘲讽无济于事，而且非常不妥。

我说的这些并没有任何偏见，我仍然尊重您过去的伟大贡献，并且我仍然尊敬您，亚历山大，我希望这些话是以我打算的建设性精神来理解的。

-- AndreCarrotflower (讨论) 2013年11月17日19:24 (UTC)

好的，我不再试图表达我的感受了。这只是我过去一个半月来在 en: 上发生的讨论的看法。但忘了它吧。我问了一个实际问题，并期望得到答复。其余的都不重要。 --Alexander (讨论) 2013年11月17日19:59 (UTC)

亚历山大，我认为您对 en: 方向的担忧与我们其他人没有根本区别。然而，我认为“关于共识的无休止的讨论”是一件非常好的事情——这些问题触及了 en:voy 社区身份的核心，坦率地说，如果没有大量讨论，我将感到沮丧。让我以及 Peter、Jan 和您一起离开社区的是我对这些问题最终会得到解决的信心，并且我们能够再次将我们全部的注意力集中在成为最好的旅行指南上。在此之前，我认为最好多一点耐心。

另外，我想重申我多么尊重您和您的工作，亚历山大。我希望您没有从我在这条线路上对您发表的评论中读到任何相反的含义。

我知道您最初的帖子想要解决的主要问题是关于将列表移动到 Wikidata，以便它们可以从所有语言版本访问。接下来，在这条线上，我将把我的评论限制在该主题上。我对 Wikidata 的内部运作了解甚少，但总的来说，我无法想象我会反对任何有助于将 en:voy 整合到 WMF 社区的过程的事情。

-- AndreCarrotflower (讨论) 2013年11月17日20:28 (UTC)

我对使用 Wikidata 与其他语言共享列表的想法很感兴趣，但我看到一些潜在的困难

• • • • 不同语言对国家的覆盖粒度不同。所以一个小乡村的城堡可能在一门语言的这个小乡村条目中列出，而在另一门语言的那个大乡村（15 英里外）中列出。我怀疑任何大城市在不同语言中的划分方式都是一样的。
      • 有些景点只对说某种语言的人真正感兴趣。如果不懂该语言又不熟悉相关作品，那么关于文学的博物馆通常兴趣不大。
      • 只有基本信息可以自动传输，任何实际的评论都必须翻译。
      • 跟踪因 Wikidata 更改而产生的更改的困难。需要更改的列表应显示在监视列表中（而不是所有数据属性更改的列表）。
      • 我们必须以一种不会给偶尔的编辑者带来复杂性的方式来做这件事。
      • 将每个列表只出现一次在数据库中将是一项巨大的工作——认识到“爱丁堡城堡”、“Édimbourg 城堡”、“ el Castillo”和“Castello di Edimburgo”是同一个地方。

也许有用的是一个工具，在编辑文章时向编辑者提供要添加的列表的建议。 AlasdairW (讨论) 2013年11月18日00:19 (UTC)

正如我在 Rfc 线程上提到的，除了上述情况外，我也看到了这个问题的某些问题。

• 澄清 AlasdairW 的第二个观点，我认为只有电话/网站/电子邮件字段可以在所有语言中通用使用，而无需翻译。几乎所有其他字段经常包含需要翻译的文本段或其他元素。
• 如果我们让它们自动显示，我们将失去本地修剪/策划列表的能力。如果我们不这样做，我们怎么知道什么时候有可以添加的内容？

Texugo (讨论) 2013年11月18日02:21 (UTC)

从 Wikidata 的角度来看，这绝对值得探索，但我认为软件还不够成熟。 --Rschen7754 2013年11月18日02:38 (UTC)

我既喜欢这个想法，也有 Texugo 的担忧，但我们是不是应该在这里讨论，而不是在这里，这样来自其他语言网站的更多 Wikivoyagers 就能看到正在提出的观点？ Ikan Kekek (讨论) 2013年11月18日02:57 (UTC)

我认为几乎每个人都支持这个总体的概念，但对实施细节存在担忧（如上所述）。请参阅 wikidata:Wikidata:Requests for comment/VCards for Wikivoyage。 -- Ryan • (讨论) • 2013年11月18日03:38 (UTC)

Ikan，我一周前在 Meta 上写了同样的内容。唯一的回应来自 torty3。很明显，大多数人都不关注 Meta 页面和/或不对此话题感兴趣。 --Alexander (讨论) 2013年11月18日05:29 (UTC)

我实际上在问一个不同的问题。我们是否应该做些什么来连接不同语言的列表？假设我们可以将列表传输到 Wikidata，或者假设我们想通过向列表添加维基百科链接和向维基百科相关页面添加 Wikivoyage 链接来改善与维基百科的交叉链接。这必须手动完成，因为每个列表都是一个完全独立的实体。做一些事情来简化列表的自动处理当然是有意义的。问题是我们该做什么。 --Alexander (讨论) 2013年11月18日05:10 (UTC)

我不知道谁会手动更新所有这些列表，因为我们有数千个目的地，每个目的地都有几十个listing 标签/模板。我们已经有大量的列表没有正确转换为模板（例如，目前的Perth (Ontario) 的混乱），这些列表多年来都未被检查以确定该地点是否仍然存在（点击网页链接 - 许多是 404、网络钓鱼、垃圾信息或指向其他企业），或者存在其他问题，例如格式不正确或过时的电话号码。在大多数情况下，没有人处理删除已停业地点的列表。已经尝试使用机器人来将格式错误的列表转换为模板，但这效果好坏参半。除非某种脚本可以初步连接列表（例如，通过查找重复的电话号码并希望它们是同一地点），否则将无法完成。手动完成的列表太多了。 K7L (讨论) 2013年11月18日06:13 (UTC)

嗯，我们肯定应该做些什么，否则只会看着混乱加剧。我认为您的回复给了我几个关于如何做的想法，谢谢！其他想法和意见仍然欢迎！ --Alexander (讨论) 2013年11月18日17:53 (UTC)

• 嗯，这些是否可以在不将整个文章移动到 Wikidata 的情况下连接起来？我好像记得维基百科有一种模板或小部件之类的东西，它们放在文章中以代替内部链接，提供对内部链接的访问。我们不能这样做吗？ Purplebackpack89 2013年11月18日18:32 (UTC)

Wikivoyage 也在做同样的事情。从 Wikidata 读取信息不是问题。问题是如何将其传输到那里。 --Alexander (讨论) 2013年11月18日19:07 (UTC)

问题是如何将其传输到那里 *以及* 如何在其存在后进行维护。后者似乎是我们现在的弱点（企业关闭后仍在指南中），而且一旦数据分散到多个维基，将会更加复杂。新用户将如何编辑部分在此处、部分在 Wikidata 且完全过时的列表？ K7L (讨论) 2013年11月18日19:18 (UTC)

如果列表编辑器能够从 Wikidata 读取条目，那么编辑将与现有界面非常相似。但这又将对话转移到了另一个话题。鉴于社区的兴趣不大，我认为将列表迁移到 Wikidata 根本不可能。因此，我只是在考虑我们可以做什么来更好地组织列表并将它们与维基媒体的其他项目链接起来。这可能会有不同的影响，例如 Wikidata，链接到维基百科（如果将来引入），或者一个纯粹的技术工具，通过读取相关类别来帮助查找 Commons 上的新图片。 --Alexander (讨论) 2013年11月18日20:02 (UTC)

我们是否可以先从一些类似于纯数据的东西开始考虑？例如，从机场出发的航班和目的地。我们大多数机场都有直飞航班和运营的航空公司。维基百科上也有类似的信息。如果这些信息集中维护，我们可以根据需要使用。我们可以从那里开始吗？ --Inas (讨论) 2013年11月18日21:38 (UTC)

嗯，这可能是一个选项，尽管它并不完全符合我对旅游指南的理解，它应该要么包含最新的时刻表，要么只提供旅行选项的简要描述。航空公司和目的地的列表是我一直不理解的。此外，从一开始就应该与英语维基百科（或许还有其他维基百科）达成一致。我当然支持这项活动，但我肯定不知道如何开始。 --Alexander (讨论) 2013年11月18日22:55 (UTC)

维基百科已经尝试维护了每个机场的目的地和航班列表，所以我们并不是在创建不存在的东西。当然，我们所有的文章都不会列出这些。如果它让一篇文章充斥着数百个条目，那我们就不会想要它，而且简短的文字更好。然而，知道飞往Port Macquarie 的航班和航空公司是这座城市旅行指南的要求。 --Inas (讨论) 2013年11月18日23:30 (UTC)

我坚信 Wikivoyage 会从在 Wikidata 上拥有列表中获益良多。为了回答一些担忧

1. 迁移数据不是一个大挑战，我们已经通过迁移坐标和横幅获得了经验，列表将与之前一样，只是数据类型更多。
2. 修改数据将和现在一样容易，如果我们修改列表编辑器。
3. 在粒度不同的地方（例如，城堡同时存在于 fr/bigville 和 en/smallville），关于城堡的数据是重复的……没关系，它在 Wikidata 之前就已经重复了，我们可以接受。
4. “有些景点只对说某种语言的人真正感兴趣”：我怀疑 Wikivoyage 整个范围内能找到超过 10 个这样的列表……请告诉我所有这样的列表，以便更好地了解情况。
5. “评论需要翻译”：是的。从 Wikidata 中受益最多的数据是 URL/电话/价格/等等。
6. “跟踪因 Wikidata 更改而产生的更改的困难”：我们与维基百科处于相同的情况，所以我相信 Wikidata 会解决这个问题。
7. “[一些列表] 多年未被检查”：Wikidata 将有助于此，这得益于多语言的协作。此外，Wikidata 可以轻松创建检测 404 错误等错误的机器人。
8. “是否可以在不将整个文章移动到 Wikidata 的情况下连接起来？”：是的，但作为一个内部链接的资深人士，我知道 Wikidata 比临时的内部链接连接更易于管理。

Nicolas1981 (讨论) 2013年12月2日03:07 (UTC)

虽然我总体上支持，但能否举一个实际的例子说明一下？谢谢。 Andrewssi2 (讨论) 2013年12月2日03:19 (UTC)

我也不是反对这个想法，但我仍然不明白它将如何运作。

• 由于只有电话、网址和电子邮件字段不需要翻译就可以通用，谁将承担填写其他字段并确保条目与其它语言版本中的正确事物相关联的所有工作？
• 它将在我们的文章中如何显示？没有了任何修剪/策划的努力，它就不能自动显示，这变成了一个复杂的跨语言协作。如果不自动显示，我们如何找到可以添加到文章中的内容？作为推论，列表项也不能与它们的父文章一对一对应，除非迫使所有参与的语言版本就区域/地区细分达成一致才能实现。
• 您的第 4 点似乎是假设信息会自动显示。除了上面给出的文学博物馆的例子外，我之前给出的例子是：日本旅游指南倾向于侧重于提供日语服务的酒店、专门接待日本游客的度假村、日式餐厅等。其他版本可能更侧重于清真或犹太洁食餐厅。其他语言可能有其他侧重点。英文版的列表选择不一定需要所有这些，并且需要保留其单独修剪/策划的能力。
• 我认为在实际实施任何这些之前，必须先找到查看最近更改的解决方案。否则，我们现在只会让自己陷入盲目，然后等待解决方案出现。

Texugo (讨论) 10:47, 2013年12月2日 (UTC)

不，我认为您没有理解。列表的选择根本不是问题。您作为 Wikivoyage 的编辑，决定包含什么。理想情况下，人们会编写 {{listing|wdid=Q123456789|description=A nice place in the middle of nowhere}}，并从 Wikidata 的 Q123456789 卡片中获取所有必要信息（名称、地址、开放时间）。列表编辑器可能与我们现在拥有的非常相似，但它会将信息直接传输到 Wikidata，这样所有语言版本都可以享受使用最新信息。那将是一个我们很可能永远无法达到的理想情况，原因有很多挑战。

• Wikidata 的界面尚未准备好
• 大多数列表（酒店、餐厅）可能无法通过 Wikidata 的可显著性标准
• 翻译问题需要仔细考虑。Wikidata 上的地址、电话号码和价格的格式应该非常严格，以便每个语言版本都可以自动翻译并将其转换为自定义格式。
• 列表应在不同语言版本和其他 Wikimedia 项目之间同步。帝国大厦在 Wikidata 中有自己的条目，但无法确保 Wikivoyage 中的列表与 Wikipedia 上的文章/Wikidata 中的条目是同一个事物。
• 巡查最近的更改变得相当复杂；很可能需要新的技术解决方案

到目前为止，我还没有看到所有语言版本中有超过 5-10 人对这样做真正感兴趣。因此，很明显，该提案应无限期搁置。

一个临时解决方案可能是这样的。添加一个可选参数（我们称之为“wdid”），它将包含 Wikidata 编号，并提供 Wikivoyage 列表与现有数据项之间的明确连接。此参数将方便链接到 Wikipedia 和 Commons，这对机器人用户以及真正的用户都非常有帮助。

更广泛地说，有一个密切相关的提议是关于 将文化遗产古迹信息移至 Wikidata。其时间表也不确定，但至少这将是改进技术方面和获得必要经验的自然第一步。--Alexander (讨论) 11:45, 2013年12月2日 (UTC)

所以这主要是针对“景点”和“活动”列表。我认为当技术上实现时，这将非常棒。是否会有办法设置，使得当在 en.Wikivoyage 中添加“景点”和“活动”列表时，列表会自动放入 Wikidata？或者，如果一个已存在的列表被开始创建，Wikidata 的信息是否会自动默认填充？在我看来，这些是软件开发者应该着手解决的事情。 Ikan Kekek (讨论) 11:53, 2013年12月2日 (UTC)

关于自动翻译，我不认为让这些字段严格到可以自动翻译是可行的。电话号码、电子邮件和 URL 字段可能根本不需要翻译，但我认为无法自动将地址字段翻译成/来自其他脚本，并且价格/小时数字段的格式差异很大，经常包含散文片段来澄清所讨论的内容。没有严格的格式能够处理随机的限定短语，例如“两人份主菜约 40 美元，半份价格为标价的 70%”或“商店 周一至周五 10AM-9PM，周六至周日 2PM-8PM；美食广场 周一至周日 11AM-8PM；冬季营业时间提前一小时，12 月 15 日至 3 月 1 日”。即使我们只将 WD 项目用于“景点”和“活动”列表，我相信这些字段中也有许多这样的限定短语。 Texugo (讨论) 12:12, 2013年12月2日 (UTC)

如果不是今天就可以尝试（即使是测试版）的东西，那么我真的不清楚要求是什么？ Andrewssi2 (讨论) 12:51, 2013年12月2日 (UTC)

我没有做出任何特别的提议。这个话题的目标是“试探一下”，看看人们是否感兴趣，以及他们是否有任何好的想法如何进行。我没有看到多少活动，除了重申语言特定信息的问 题和巡查最近的更改，所以我们不会明天就将信息迁移到 Wikidata，但这个对话的某些部分还是很有用的。感谢大家！--Alexander (讨论) 13:48, 2013年12月2日 (UTC)

Ikan，这是一个根本性的误解。信息应该一次性传输到 Wikidata，然后从中检索。否则，您只是在 Wikidata 上保留列表的副本，这并没有真正用处。我还试图清楚地说明，目前我们没有工具从 Wikidata 检索这类信息。这些工具将（慢慢地）出现，但除非 Wikivoyage 在整理事物、识别不同语言版本中的相同列表以及识别已经拥有 Wikidata 条目（Wikipedia 文章）的列表方面付出巨大努力，否则它们将毫无用处。最后这一点是每个人都可以立即开始做的，但我不敢肯定我是否能好好解释。--Alexander (讨论) 13:48, 2013年12月2日 (UTC)

这听起来并不需要行为上的任何改变。咨询 Wikipedia 获取景点基本信息并不是什么新鲜事，但咨询景点的官方网页通常更可靠。我又漏掉了什么吗？ Ikan Kekek (讨论) 18:48, 2013年12月2日 (UTC)

嗯，是的……这不是关于获取新信息。这是关于跨项目链接。假设英文 Wikivoyage 有一个关于莫斯科克里姆林宫的条目，俄文 Wikivoyage 也有，但没有一对一的对应关系。如果您将 Wikidata 编号添加到两种语言中，您就能立即知道这是同一个列表。现在，Wikipedia 不喜欢存储实际信息，例如开放时间和门票价格，因此将 Wikipedia 上关于莫斯科克里姆林宫的文章链接到 Wikivoyage 是很自然的。您可以手动完成所有操作，也可以让机器人为您完成，但机器人必须知道哪个 Wikipedia 文章与莫斯科克里姆林宫的 Wikivoyage 列表相关联。--Alexander (讨论) 19:32, 2013年12月2日 (UTC)

我对共享英语和德语版本相同文章列表的 Wikidata 条目（进而推广到其他语言）感兴趣。我注意到克里姆林宫链接有一个空的 WV 部分。这是否意味着您已经开始了集成工具？ Andrewssi2 (讨论) 13:42, 2013年12月4日 (UTC)

每个 Wikidata 条目都有一个空的 Wikivoyage 文章插槽。这没有任何意义。

正如我所说，我们（俄罗斯-乌克兰团队）不打算自己开始任何事情，而是将精力集中在文化遗产方面，这稍微容易些，组织得更好，并且更能满足可显著性标准。但即使是文化遗产也是一个长期项目。--Alexander (讨论) 13:51, 2013年12月4日 (UTC)

.voyage

Apparently there's a top-level domain .voyage opening in the new year; is this of any use to us? K7L (讨论) 19:56, 2013年11月26日 (UTC)

嗯……有意思！我认为应该尽快提交给 WMF 相关部门的负责人，尽管我不知道是谁。 Texugo (讨论) 19:59, 2013年11月26日 (UTC)

wikivoyage.com 和 wikivoyage.net 已经重定向到 wikivoyage.org，所以添加“wikivoyage.voyage”也是顺理成章的事。-- AndreCarrotflower (讨论) 17:08, 2013年11月27日 (UTC)

还有 wiki.voyage！ Jjtkk (讨论) 17:32, 2013年11月27日 (UTC)

谢谢提示！Wiki.voyage 将是一个非常吸引人的 URL :-)   Nicolas1981 (讨论) 08:42, 2013年11月28日 (UTC)

进行了一些询问，得到了这个答复： --Rschen7754 10:00, 2013年11月28日 (UTC)

@K7L: @Texugo: --Rschen7754 18:56, 2013年11月30日 (UTC)

啊，是的，我早就看到了，但忘了回复。你有没有给 YWelinder 发过邮件？ Texugo (讨论) 19:45, 2013年11月30日 (UTC)

我还没有，因为我以为应该由更熟悉这类事情的人去做，但如果没人愿意，我可以去做…… --Rschen7754 19:52, 2013年11月30日 (UTC)

我不确定这里是否有人更熟悉这类事情。你介意吗？ Texugo (讨论) 20:00, 2013年11月30日 (UTC)

现在完成了。 --Rschen7754 20:03, 2013年11月30日 (UTC)

几年前就有 .travel TLD 了。我们是否拥有、需要或想要那里的任何域名？我认为 guide.travel 是有价值的。 Pashley (讨论) 20:07, 2013年11月30日 (UTC)

我很久以前就预注册了“wiki.voyage”，一旦该顶级域名可用注册，我就会将其交给 WMF，所以不用担心域名抢注。Pashley，“guide.travel”不可用。--Saqib (讨论) 20:41, 2013年11月30日 (UTC)

wiki.travel 可能不会那么受欢迎…… --Rschen7754 21:04, 2013年11月30日 (UTC)

.travel 域名有一些非常武断的限制——基本上，您必须证明自己是注册的旅行社或二十种其他特定旅行领域的供应商（航空公司/铁路、酒店/住宿、租车公司……）才能注册，价格是 .com/.net/.org 或本地国家代码的十倍——因此其采用相当有限。到 2007 年，Tralliance（运营 .travel 的公司）被推测濒临破产；该公司在 2008 年被私有化时，仅注册了 30000 个名称。 该域名仍然存在，但大多数供应商强烈倾向于保留其现有的 .com 注册，因为它们是成熟、受尊重的地址。如果 wiki.travel.com 已完成而 wiki.travel 被跳过，也许有原因？ :) K7L (讨论) 22:29, 2013年11月30日 (UTC)

新的 Creative Commons 许可证

4.0 版本已发布。 我认为这在短期内不会影响任何事情。我看不出有明显的需要更改，而且在 WMF 法律部门审阅之前我们也无法更改。而且我们还需要与其他 WMF 项目以及……进行同步。但似乎值得一提。 Pashley (讨论) 01:45, 2013年11月29日 (UTC)

谢谢信息！快速阅读了这些更改后，我认为虽然切换会是好事，但也不是优先事项。我们不如等待 WMF 主动发起？他们切换所有项目时成本可能会更低。 Nicolas1981 (讨论) 02:13, 2013年11月29日 (UTC)

我不知道我们是否可以在没有上传者许可的情况下随意更改，因为许多媒体文件都在 Commons 上。所以我会先看看他们如何反应。--Rschen7754 02:24, 2013年11月29日 (UTC)

我们 可以 在没有上传者许可的情况下更改，因为当前许可证的第 4b 条允许在同一许可证的任何后续版本下重新分发。当然，我们不应该这样做。一个重大变化是新版本以不同的方式处理国际许可。确定这是否适合 WMF 项目将需要跨项目和跨语言的协调，以及法律部门的意见。 Pashley (讨论) 07:22, 2013年11月29日 (UTC)

Tipper

各位好，

您对一款允许您轻松向 Wikivoyage 添加列表的 Android 应用有多大兴趣？

它将看起来像当前的列表编辑器。

可能有趣的特性

1. 如果需要，可通过 GPS 获取坐标的按钮
2. 显示附近文章列表，用户选择相关文章
3. 拍照（希望可以使用 Wikimedia Commons Android 应用的意图）
4. 如果没有互联网连接，则存储数据并在有连接时发送

在实验阶段，数据将添加到用户页面，然后我/任何人都可以将其复制/粘贴到正确的位置。可以使用 Google App Engine 或 Heroku 或类似服务来避免泄露 IP 地址。如果该工具变得流行，可以考虑添加到文章的讨论页（甚至在一些非常严格的条件下添加到文章本身，稍后定义）。

有什么比“Tipper”更好的名字吗？（意思是：发送关于地方的小费的人） Nicolas1981 (讨论) 07:21, 2013年12月2日 (UTC)

当然。Wikimedia 网站现在支持 mw:OAuth，这可能会消除 IP 地址问题（尽管它最近才部署，所以还没有人使用）。我猜你会开发它？--Rschen7754 07:50, 2013年12月2日 (UTC)

我之前的 Wikivoyage 相关 Android 应用（Wikivoyage offline）相当失败（只有 2000 次安装），所以我宁愿先分享这个想法并获得一些反馈。一如既往，它将是开源的，因此欢迎大家的帮助（顺便说一句，创建这样的应用程序将是学习 Android 开发的好方法，有谁感兴趣吗？）。感谢 OAuth 的提示！我认为我们不应该要求用户拥有 Wikimedia 账户，但未签名的用户隐含同意透露其 IP 地址。 Nicolas1981 (讨论) 12:00, 2013年12月2日 (UTC)

只编辑导言部分

在我的 WP 偏好设置中，在 Gadgets - Appearance 下，有一个“为页面导言部分添加 [编辑] 链接”。我的 WV 偏好设置中没有这个。除了点击“编辑”其他部分，然后在生成的 URL 中，将末尾的 &section=n 替换为 &section=0 然后重新加载页面之外，还有一种只编辑导言的更简单方法吗？我们能否为 WV 获取那个小工具？ Nurg (讨论) 08:48, 2013年12月2日 (UTC)

我们可以得到它。 @PiRSquared17: 如果你在，文件名又是什么？我老是记不住 :( --Rschen7754 08:53, 2013年12月2日 (UTC)

实际上，我已经处理好了。--Rschen7754 10:03, 2013年12月2日 (UTC)

谢谢。如果页面有横幅，它似乎不起作用。或者如果它起作用，如何起作用？如果它不起作用，可以使其起作用吗？这是否需要对横幅实现进行更改，也许？ Nurg (讨论) 20:16, 2013年12月2日 (UTC)

我的猜测是，横幅完全遮盖了它。我们可以将链接添加到横幅中，但那样的话对每个人都可见……--Rschen7754 06:15, 2013年12月3日 (UTC)

w:en:User:Equazcion/OneClickArchiver

如果有人感兴趣，由于我们没有归档机器人，这是一个让归档更容易的脚本。我做了这些编辑 ，现在我可以在我的讨论页上点击一次来归档部分内容。

缺点是必须在每个设置为如此归档的页面上添加少量代码。它也不会处理将 pub 迁移到其他页面（尽管理论上有人可以编写该功能）。--Rschen7754 09:52, 2013年12月2日 (UTC)

迷你远征以清理列表

我正在发起一次迷你远征，目标是修复损坏的 POI 列表。

是否有人知道任何类似的努力，或任何现有的工具，以免重复工作？

到目前为止，我发现以下是问题类型，您知道还有其他问题吗？

• 纬度（经度）格式为 34°31'33.95N，而不是例如 31.46937
• 无效的 URL
• 无法访问的 URL
• 无效的电子邮件地址
• 无效的电话/免费电话/传真号码
• 未知参数，例如“vkontakte”

细微情况

• 营业时间/入住/退房：我们是否希望以下内容完全符合 时间/日期格式？
• 价格：我们想要单一价格（数字+货币），还是完全自由格式，或者介于两者之间（句子，其中至少第一个数字+货币是机器可读的）？

灵活性是好的，但对于数据聚合/协作（例如 OpenStreetMap 图层）来说，如果机器仍然能够理解数据的核心部分，那就更好了。

非常欢迎您的意见/想法！ Nicolas1981 (讨论) 06:29, 2013年12月3日 (UTC)

两轮 Wikivoyage:Script nominations#Wrh2Bot 应该已经基本清除了不受识别的参数，尽管最好有一个维护机器人来清除任何重新出现的参数。您是计划手动进行远征还是自动化进行，如果是后者，您是计划编写机器人还是寻找其他人来做？-- Ryan • (讨论) • 06:47, 2013年12月3日 (UTC)

我考虑的是手动远征，但如果错误数量太高，可以重新考虑。我不知道您的机器人已经清理了不需要的属性，太棒了！顺便说一句，我的脚本开始在 User:Nicolas1981/Syntax_checks#Invalid_URLs 报告无效属性。 Nicolas1981 (讨论) 08:41, 2013年12月3日 (UTC)

这是我当前的脚本： https://github.com/nicolas-raoul/wikivoyage2osm/blob/master/wikivoyage2osm.sh 欢迎任何人贡献更多验证 :-) Nicolas1981 (讨论) 14:36, 2013年12月3日 (UTC)

其中一些所谓的“未知参数”可能是其他 WV 语言中有效的字段，例如第二个电话号码（或手机号码）、指向 Wikipedia 或（如果将来实现）Wikidata 的链接，或者指向 Facebook/Twitter 等站点的链接。即使 en.WV 目前不使用这些信息，我们也可能想保留它，因为数据聚合或第三方应用程序可能会找到用途（例如，WikiSherpa 是一个结合地图+WP+WV 的项目，所以 WP 链接对他们可能有用）。如果字段名称与我们这里存在的字段名称不同（例如 adresse 和 téléphone），那么修复它就是有意义的。我们确实有相当多的列表信息在描述中而不是在更具体的字段中——来自最初是纯文本并由“机器人”转换的列表的营业时间和价格不可避免地会导致这种情况。我们还有许多列表的电话号码格式不正确——像 Cebu (city) 这样的地方有时有多达四个用于联系同一地方的号码。我不得不怀疑，当地的宿务电话公司是否没有“寻线”或“同等功能”来处理一个有多个线路的固定电话？免费电话号码有时被包含在“电话”而不是“免费电话”中，即使该字段中已经有一个本地号码。缺少国家/地区代码相当普遍，而且我们可以假设我们想要 +44 20 而不是 +44 (0) 20，如果拨打国际长途电话时没有包含本地长途前缀。有大量错误，但我怀疑除了极少数情况外，它们是否能被自动修复。 K7L (讨论) 18:27, 2013年12月3日 (UTC)

将电话号码呈现为所有平台的“tel:”URL

我经常和 Kiwix 的开发者交流，他告诉我，我们没有理由不将电话号码呈现为“tel:”链接。

我认为他说得对，这种链接对支持该协议的人（Android、Skype 等）很有用，尽管不是每个人都如此。

您对此有何看法？谢谢！

顺便说一下，昨天发布了一个新的 Wikivoyage ZIM Nicolas1981 (讨论) 14:31, 2013年12月3日 (UTC)

支持这个想法。超链接电话号码对用户来说很友好，并且可以极大地改善我们移动网站访问者的体验。--Saqib (讨论) 14:41, 2013年12月3日 (UTC)

只要号码以 + 开头，任何使用列表模板的，这已经发生了 -- WOSlinker (讨论) 17:08, 2013年12月3日 (UTC)

哦，对了，刚意识到它正在工作。--Saqib (讨论) 18:17, 2013年12月3日 (UTC)

我们有 3234 个列表 存在电话格式问题——它们将两个（或更多）号码挤在一个字段中，号码有总机和分机（tel: 对此处理不佳，甚至无法处理），它们包含 w:phonewords，如 +1-800-HOLIDAY 或 +1-800-RENT-A-CAR，或者（在 2914 个实例中）缺少国家/地区代码。在某些情况下，这些是最初在没有标签或模板的情况下提交的列表，并通过机器人脚本随意转换的。一个有效格式的号码现在将获得 tel: 链接，但对于数字格式不正确的页面，有整个维护类别。 K7L (讨论) 18:10, 2013年12月3日 (UTC)

谢谢！我还没意识到这一点，抱歉打扰了！我会想办法让修复有问题的数字更容易，而无需检查文章中的所有数字。Nicolas1981（讨论） 2013年12月4日 05:07 (UTC)

OxygenGuide（离线 Wikivoyage）：已更新，现已包含章节菜单

下载OxygenGuide并将其解压到您的笔记本电脑或手机上，即可离线访问整个Wikivoyage！

使用最新的数据转储（星期六）生成。现已包含一个方便跳转到任何章节的菜单。Nicolas1981（讨论） 2013年12月2日 13:41 (UTC)

那 Mac 用户呢？ --Saqib（讨论） 2013年12月2日 13:43 (UTC)

Saqib：在 Mac 上，您也可以下载 OxygenGuide，解压后离线浏览 :-) 如果有任何问题，请告诉我，感谢您的反馈！ Nicolas1981（讨论） 2013年12月3日 04:07 (UTC)

现在能搜索了吗？ Travel Doc James（讨论 · 贡献 · 邮件） 2013年12月5日 04:26 (UTC)

需要帮助修复双重重定向

我已从旅馆扫过

我检测到有几十个双重重定向，有谁能花20分钟修复它们吗？谢谢！它们位于https://wikivoyage.cn/wiki/User:Nicolas1981/Syntax_checks#Double_redirects Nicolas1981（讨论） 2013年11月29日 02:40 (UTC)

过去曾有一个机器人会做这件事，但操作员已从 Wikimedia 退休了。 :/ --Rschen7754 2013年11月29日 02:44 (UTC)

我修改了你的列表 - 已修复 -- 我认为只有一个 Bigi Pan 指向自身，所以我让它重定向到苏里南，因为它在那里有一个岛屿…… Matroc（讨论） 2013年11月29日 05:35 (UTC)

再次感谢Matroc :-) 每月需要20分钟，所以不是高度优先事项，但如果有人知道在维基百科上执行此操作的机器人，能否告诉我？我可以尝试在Wikivoyage上运行相同的机器人。Nicolas1981（讨论） 2013年11月29日 07:50 (UTC)

我曾见过的在 WP 上修复双重重定向的机器人是 w:User:AmphBot，但可能还有其他的。Nick1372（讨论） 2013年11月30日 16:24 (UTC)

Apparently Amphbot's operator has left Wikipedia in 2012, and no source code can be found。Nicolas1981（讨论） 2013年12月2日 03:35 (UTC)

User:RileyBot was approved here, but stopped running after the owner retired from Wikimedia.--Rschen7754 2013年12月2日 04:18 (UTC)

也找不到RileyBot的源代码……Nicolas1981（讨论） 2013年12月2日 07:53 (UTC)

Apparently this is a function in mw:Pywikipedia (redirect.py)。 --Rschen7754 2013年12月3日 07:19 (UTC)

There's actually a page at Special:DoubleRedirects. Special:BrokenRedirects isn't being cleaned as well.-- torty3（讨论） 2013年12月6日 11:30 (UTC)

从 WT 复制

出现了一个问题，Polatsk是用 WT 复制的文本创建的。大多数（但不是全部）作者信息都来自导入到这里来的同一个用户。（见Talk:Polatsk）在这种情况下我们该怎么做？我们想保留它吗？如果是，最好的归属方式是什么？显然，我们不想让它变得太容易而鼓励更多的复制，考虑到我们最近为减少指向那里的归属链接数量而付出的努力，而不是增加它。或者，这个用户是否有可能只将他在那里做的原始未更改的贡献插入到我们这里的新文章中，而不必担心归属其他网站？ Texugo（讨论） 2013年12月6日 13:51 (UTC)

是否可以通过让用户先将文本放入 WV，然后再复制到 WT 来解决这个问题？Andrewssi2（讨论） 2013年12月6日 14:26 (UTC)

理想情况是他们首先在这里贡献，但是你的建议不太可行，也不能解决信息已经先在那里添加的不可避免的情况。Texugo（讨论） 2013年12月6日 14:36 (UTC)

通过他们的讨论页面可以指导这样的贡献者。

对于不可避免的 WT 首先发布的情况没有建议。Andrewssi2（讨论） 2013年12月6日 14:44 (UTC)

鉴于过去的法律历史（Wikivoyage:Wikivoyage and Wikitravel#Can I copy content between Wikivoyage and Wikitravel?），我们不鼓励需要归属的复制，因此我建议我们需要删除任何不属于作者自己原创的作品。 -- Ryan •（讨论） • 2013年12月6日 15:56 (UTC)

是的，每个人都应该避免直接复制粘贴。如果有人将一些第一手信息添加到 Travel，那么用不同的措辞在这里写相同的信息应该不难。顺便说一句，这当然取决于每个人自己是否支持其他网站，但我个人已经一年半没在那里贡献了，我猜大多数其他 Voyagers 也是如此。ϒpsilon（讨论） 2013年12月6日 16:38 (UTC)

Legally, the author of the text owns the copyright and can do as they darned well please — but rewording text is a good idea as duplicate content is being penalised by search engines. After substantial changes to a page, using http://www.copyscape.com/compare.php to find leftover WT text still in the article that can be reworded or removed helps avoid the duplicate content penalty。K7L（讨论） 2013年12月6日 16:47 (UTC)

Just to clarify my above comment, if someone is copying their own, original work then no further attribution is required - they are the original author and attribution would be the same whether they write something just for Wikivoyage, write something just for WT, or copy their own work to both sites. However, if the content being copied is not solely the author's own work, while it is legally permissible to copy text if attribution is provided, per Wikivoyage:Wikivoyage and Wikitravel#Can I copy content between Wikivoyage and Wikitravel? I think that is something to discourage unless it has first been discussed. As to SEO issues, while it would be great if all content was distinct from what is found elsewhere, if someone wants to contribute to both sites I'm not sure it's entirely reasonable to require them to write different versions for each site. -- Ryan •（讨论） • 2013年12月6日 17:15 (UTC)

可以将归属放在历史记录中。当我们移动 WP 上的文本时，我们就是这样做的。底部不需要归属。Travel Doc James（讨论 · 贡献 · 邮件） 2013年12月6日 18:35 (UTC)

越南编辑战

我看到了上面关于如何吸引实际旅行者在 WV 上编辑的对话。顺便说一句，我想引导您关注会安的讨论页，在那里您的一位常客一直在撤销我添加的信息。请有人告诉我为什么我要在此处进行另一次编辑。 --Neotarf（讨论） 2013年11月19日 13:31 (UTC)

I'm not trying to chase you away, and part of my thinking is that since you aren't an absolutely new user, you are therefore more likely to be willing to discuss things than just up and leave. And the key point is, should My Son be listed in the "Go next" section or the "See" section of the article. It can't be listed in both. That's the only real sticking point, though I also brought up the issue of whether the articles should be merged。Ikan Kekek（讨论） 2013年11月19日 19:45 (UTC)

Please be patient. The policy position you are running up against here, is that each attraction is only listed once. That generally works well, but like all things, it's grey around the edges.--Inas（讨论） 2013年11月19日 22:28 (UTC)

• “下一个去哪里”的目的是什么？它似乎是一系列随机的城市。难道已经有一个“离开”部分了吗？
• 旅行者的时间非常有限。如果他们来到这里，发现自己突然卷入了一些大的争执，或者被告知要有耐心，或者被告知一些内部行话，他们就会损失惨重，悄悄地去别处。他们可能不会告诉你原因。我会说的。您已经知道我实际上不使用这个网站，还有其他更好的纸质和在线来源。但是这个网站是新的，具有巨大的潜力。
• On my talk page I was pointed to teh traveller comes first, but now I find there is a whole laundry list of hidden arcane reasons that that cannot happen。 --Neotarf（讨论） 2013年11月20日 03:13 (UTC)

I addressed the uses of the "Go next" section when you asked about it in Talk:Hoi An, but since more people will probably be reading here, from Wikivoyage:Huge city article template

有关附近可能作为“下一站”的游览目的地信息。简要描述其他附近的游览建议、邻近城市和城镇或一日游的点子。不要重复“如何抵达”部分的信息。

There is no other "getting away" section. I think you're probably confusing this site with another site that still uses a "Get out" section.

Listen, maybe I shouldn't have reverted your edit twice, and I'm sorry I annoyed you, but we don't like to duplicate information in two different sections of an article, and I'm not sure I see your point about serving the traveler. I could see where it might serve the traveler to put in the "See" section in prose "Aside from these sights in town, many people also use Hoi An as a base to visit My Son and several other places (see "Go next"), but making a full "See" entry there and then also having a link in "Go next" to a more detailed guide - is that really something that best serves the traveler? I really am not getting why it helps travelers to cover the same attractions in more than one place。Ikan Kekek（讨论） 2013年11月20日 03:23 (UTC)

The policy of avoiding multiple listings is to help the traveller. I really think you're making a mountain out of molehill here. If people are going to walk because we have a defined way of doings things, then they can go and write their own blog or travel journal exactly the way they wish. To work on a wiki, means working cooperatively. This does mean that sometimes a blog of someone who has done the trip, or a tripadvisor or thorntree forum is going to provide better info. That's great. If you think you're going to receive a friendly and more open reception at WT, I doubt it. Been there, done that.--Inas（讨论） 2013年11月20日 03:34 (UTC)

Oh I AM on Wikitravel . I've been there longer than I've been here. And I've never had the problems there that I've had here. But in all fairness, the situation on the talk page in question seems to be resolving now. Regards, --Neotarf（讨论） 2013年12月14日 13:21 (UTC)

时空旅行者指南

（在此发布，因为这是中心讨论枢纽。）

是否有熟悉 Wikivoyage 写作方式的人可以帮助我为我脑海中一个有间接关系的项目提供建议？

据注意到，在四月份会写一些恶搞文章。然而，我的想法比那更严肃一些。

这个想法是开发一套“时空旅行者”指南，用于不同时期的地方，以支持历史教育（可能在 Wikiversity 上）。

鉴于你们对自己所在领域和历史的了解比某些人更深入，Wikivoyage 的人们是否有兴趣为此做出贡献？ :) Sfan00 IMG（讨论） 2013年12月4日 12:24 (UTC)

This sounds extremely interesting to me. Could you be a little more specific as to what kind of help you need？Texugo（讨论） 2013年12月4日 12:43 (UTC)

I have a great guide book for South Korea written in 1975. It is a completely different country today, and in many ways visiting 30 years ago would be akin to visiting a new place. I'd be interested to see what you have in mind。Andrewssi2（讨论） 2013年12月4日 13:38 (UTC)

Well in essence I was needing some writers, as I'm better at ideas then actual writing. Essentailly what I am aksing for is for someone to write a guide according to the Wikivoyage style guide for an historical place and time (albiet writing from a modern perspective). If someone wants to attempt writing a contemporaneous (to the period) style I won't mind, but the idea was "Time-Travel" guides, not a Bradshaw pastiche ;) Sfan00 IMG（讨论） 2013年12月4日 17:16 (UTC)

The first thing to determine (as with the Joke articles) would be a possible location... And to me some easy locations would be

• New York 1965
• London 1967
• London 1890
• Oxford 1955 (But then Oxford hasn't changed that much...)

I suggest picking one and working on it... Sfan00 IMG（讨论） 2013年12月4日 17:16 (UTC)

Some of our itinerary articles like Silk Road or Lewis and Clark Trail are already partly historical. Two that I mostly wrote are On the trail of Kipling's Kim and On the trail of Marco Polo; is there anything you can use there?

I based those on books downloaded from Project Gutenberg. They have thousands more including many historical novels and things like the journals of 19th century explorers or missionaries in various odd places. I think your project might use a lot of quotes from the best of those, or sometimes just give a link.

I'd be much more interested in more exotic time travel, medieval Oxford, Rome under the Caesars, Tang China or Ashoka's India。Pashley（讨论） 2013年12月4日 17:48 (UTC)

I was thinking along the same lines. London on the eve of the Great Fire, Philadelphia in the 1770s, Seville under the Muslims, Heian Kyoto... More difficult research involved, but wouldn't it be awesome！Texugo（讨论） 2013年12月4日 19:34 (UTC)

OK.. I'll open up a page , if someone wants to suggest a suitable host project...Sfan00 IMG（讨论） 2013年12月5日 11:47 (UTC)

You have a landing page - [] , Start from there :) Sfan00 IMG（讨论） 2013年12月5日 21:43 (UTC)

I made a start on Wikicronos's article on https://en.wikiversity.org/wiki/User:ShakespeareFan00/Wikicronos/London_%281951%29 I could do with some help in expanding it。 :) Sfan00 IMG（讨论） 2013年12月5日 22:25 (UTC)

This looks like a really exciting and interesting project! Definitely worth a go! May I humbly suggest that we call it Wikichronos (with an 'h'), if that's what we're to call it, as that was the Ancient Greek personification of time. Would we leave it on Wikiversity or have it as a sub-project on here? --Nick ^talk 2013年12月5日 22:38 (UTC)

OK - It's currently at Wikiversity, because of scoping rules.If the Wikivoyage community has no objections to hosting it here under a Wikichronos banner (And obvious disclaimers it's not real content) I have no objections, but that would have to be a Community disscussion not mine。ShakespeareFan00（讨论） 2013年12月5日 23:37 (UTC)

I think it is OK in English as "chronos" or maybe "kronos", but it's not with just the 'c'. English has the 'ch' in "chronology". and other words. If it is going to be a multilingual project, we should ask some people from other languages. Include a modern Greek or a scholar of ancient Greek if possible。Pashley（讨论） 2013年12月6日 01:51 (UTC)

Well obviously we need some scholars. You expect someone from 2013 to understand colloquial Latin (which of course differs from purely 'classical' <grin>. I hadn't used Kronos directly because of trademark concerns？Sfan00 IMG（讨论） 2013年12月6日 11:01 (UTC)

I am awaiting an OK from the community on thisSfan00 IMG（讨论） 2013年12月8日 17:23 (UTC)

I am afraid it would be out of scope here, in my opinion。LtPowers（讨论） 2013年12月9日 01:47 (UTC)

Thank you. I would suggest however that anyone interested , contact me directly so it can be developed on a more suitable project。Sfan00 IMG（讨论） 2013年12月9日 10:07 (UTC)

I think that I agree with LtPowers. It is an interesting idea (and I added a few words on food rationing), but I see several potential problems. For serous educational use, I think that facts would need references (like WP, but unlike here), as unlike normal travel destinations there are no primary sources and the article is not going to be refined by people actually going there. There is also the difficulty of avoiding somebody mistaking the article for a regular travel guide, and I think it is against policy as it is not a destination open to visitors. Are you aware of much demand from schools for this sort of guide?

However I think that we could have a travel topic (or itinerary) to guide people to sights visible today that relate to a particular period, which might help parents looking to bring school history to life. I am thinking of Roman Britain or A tour of 1950s British Architecture etc。AlasdairW（讨论） 2013年12月9日 23:54 (UTC)

The concerns you note were why I was prototyping this over on Wikiversity.

i) I have no objections to references being included to support historical fact or conjecture. (Horrible Histories I think includes notes confirming historical sources), I also have no objections to there being a 'Basis' page where the credibility or accuracy of the guides can be discussed (This is something the Alternate History Wikia's done.)

ii) I'm not aware of any specfic demand from schools, but the approach of a 'time-traveller' guide has been used by some UK museums and heritage bodies to present social history material. Wuikichronos was largely my own idea, but I hope to gain support in disscussion.

iii) Would a suitable disclaimer work, so that it's not mistaken for real content.. (At the moment it's in my userspace at Wikiversity for a reason? (And this disscussion should probably transfer there in time).

iv) Creating travel topic/itenaries with an Education focus is something WikiVoyage could do as well. This is something I would support. (I also have no objection of course of WikiChronos pages linking to the Actual Wikivyoage page).

The topics you mention could be exciting。Ikan Kekek（讨论） 2013年12月9日 23:58 (UTC)

导出到epub的问题

Hi there,
First of all - thank you guys for doing such a great job keeping this site up and running. I've already shared it wit some of my friends at work. Wasn't sure if I should add new question at the end or should I hook to a relevant topic that's already here.
Now to the issue - I'm trying to export my book to an epub to have it handy on my kindle when traveling (I love this feature) however no matter which format I choose it is always saving my book to a pdf. Is the functionality currently broken or is it something i'm doing wrong? Regards Iwwwwwwi（讨论） 2013年12月6日 23:03 (UTC)iwwwwwwi

I guess this is because we're missing an extension。 --Saqib（讨论） 2013年12月7日 07:50 (UTC)

Any ideas when that functionality might be fixed ? I remember it was working perfectly more than a month ago。Iwwwwwwi（讨论） 2013年12月7日 10:29 (UTC)

Not a missing extension, and it probably did work a month ago. Looks like the bug was introduced on Nov 15 - Bugzilla: 57975 and Bugzilla: 57920, placed on high priority for WMF techs.-- torty3（讨论） 2013年12月9日 01:17 (UTC)

Google 搜索数据

Looking at WV's Google Trends page, it seems that interest has stabilised since the drop-off after the 'boom' launch period early this year. Local data for the United States shows a bit of a slight decline, but still suggests that there is a consistent stream of visitors that can surely be built upon.--Half past (formerly SUFCboy) 2013年12月8日 13:16 (UTC)

And comparison shows we're still very down。 --Saqib（讨论） 2013年12月8日 13:53 (UTC)

Sapphire's comments on this thread (timestamped 17:31, 7 December 2013) provide a huge glimmer of hope。 -- AndreCarrotflower（讨论） 2013年12月8日 18:52 (UTC)

开放时间：OpenStreetMap 有一个清晰且经过深思熟虑的标准，我们应该切换到它吗？

Here is how OpenStreetMap expresses opening hours: http://wiki.openstreetmap.org/wiki/Key:opening_hours#Examples http://wiki.openstreetmap.org/wiki/Key:opening_hours:specification

We also have such a standard: https://wikivoyage.cn/wiki/Wikivoyage:Time_and_date_formats

If we are happy with our standard then no problem. But I am running a validation script and a large part of the data is not respecting our standard, so I was thinking we might as well piggyback on OpenStreetMap. Standardization is good for everyone, it makes it easier for us to integrate with other tools. I am not saying we should switch now, I am just asking for your feedback on this idea。Nicolas1981（讨论） 2013年12月10日 09:23 (UTC)

您会遇到的问题是，在美国，24小时制很少使用，军事时间除外，很多美国人都不太理解“20:00”这样的时间表示。我知道我在欧洲的时候，也会用减12来计算下午的时间。我认为，强制要求美国文章使用24小时制，会比强制使用英式拼写更加不符合习惯，而且我必须说，为了与其他工具的便利性而进行的更改，对我来说并不充分，因为这种更改会给编辑美国目的地文章的美国用户带来麻烦，也不会帮助前往美国的旅行者理解他们实际看到的营业时间标识。Ikan Kekek (讨论) 09:37, 2013年12月10日 (UTC)

我之前没想过这个问题，谢谢！这确实不用户友好。Nicolas1981 (讨论) 13:34, 2013年12月10日 (UTC)

是的，我们应该切换到OSM标准。Pashley (讨论) 13:52, 2013年12月10日 (UTC)

我不确定我是否能完全理解那个技术描述的含义，但我同意Ikan Kekek的观点，强制要求美国目的地使用24小时制会非常不自然且可能带来问题。Texugo (讨论) 14:00, 2013年12月10日 (UTC)

我不想过于关注“美国很奇怪”这一点，因为真正的问题在于那些OSM标准是为了机器可读而设计的。我们的标准是为了人类可读而设计的。这是一个根本性的不兼容。我们不能，也不应该试图将我们的营业时间生硬地套入一个严格的格式。坦率地说，我不确定Nicolas的脚本是在验证什么。LtPowers (讨论) 14:45, 2013年12月10日 (UTC)

OSM标准如何处理季节性变化的营业时间？根据目的地不同，旅行和航海列表中的景点，很多会在劳动节或感恩节关闭。 K7L (讨论) 15:57, 2013年12月10日 (UTC)

同意，这是反对采用类似OSM格式的最大论据。WV列表相当简单，只有少数几个字段用于传达一般类别的信息，如“营业时间”和“价格”。我经常输入“周一至周六上午9点至下午5点，整点导览，每隔一个周二休息”（是的，这是我刚才编的）或其他容易理解的自然语言组合，但用机器可读格式表示会非常冗长。这种改变将消除使用自然语言的可能性；为了不丢失任何信息，您需要一个复杂得多的格式。（OSM通过可以为事物添加标签，例如opening_hours:tours=Mo-Sa 09:00,10:00,11:00来规避这一点，而我们不能仅仅在列表中添加额外的字段。）而且，如果格式一致且简洁，有什么好处呢？您有什么想法可以利用我们的列表来实现现在无法实现的功能，但如果改变格式就可以实现吗？ --Bigpeteb (讨论) 22:08, 2013年12月10日 (UTC)

当然，总会有需要非机器可读营业时间的兴趣点。为了回答LtPowers的问题：我的脚本发现了诸如：hours="Closed"或hours="jonron49@bigpond.com"（是的，这些现在就在Wikivoyage上），以及语法可以改进的情况，例如hours="8 am to 10 pm"（早上8点到晚上10点）。Nicolas1981 (讨论) 06:42, 2013年12月11日 (UTC)

所有列表的CSV格式

这是一个包含英语Wikivoyage所有列表的CSV文件：https://docs.google.com/file/d/0B-SI__O0UX9ob2JLRmNkeE41UEU 尽情享用！

我正在将其转换为OpenStreetMap格式，以便能在OsmAnd等应用程序中使用。源代码位于https://github.com/nicolas-raoul/wikivoyage2osm Nicolas1981 (讨论) 12:55, 2013年12月10日 (UTC)

一项建议，货币转换器

我认为使用模板（{{currency|5.36|USD}}）指定价格是个好主意，用户可以通过某种方式（在偏好设置中或在顶部，随你选择）选择以特定货币查看价格，例如欧元。模板“currency”将包含一个（由机器人定期更新的）表格，用于将原始当地货币转换为用户指定的货币。一种简单的方法是进行美元与所有其他货币之间的转换，然后进行当地货币 => 美元 => 用户货币的转换。这只是一个想法。祝好。 --Kizar (讨论) 22:18, 2013年12月10日 (UTC)

这不是一个购物网站，价格用当地货币或美元就足够了，我认为。 --Saqib (讨论) 22:23, 2013年12月10日 (UTC)

用当地货币表示价格听起来不错，但用美元不是个好主意，原因有二。1)汇率不断变化，价格很快就会失效。2)并非所有人都使用美元，我认为英国人应该审视一下。 --Kizar (讨论) 23:02, 2013年12月10日 (UTC)

与图片、天气和动态地图一样，价格也是旅行者最常关注的事物之一。那里有一些网站使用动态转换器，例如http://dynamicconverter.com/，允许读者选择以自己选择的货币显示所有价格（几乎实时更新）。

您可能还对阅读几年前的一次非常简单的讨论感兴趣：Wikivoyage_talk:Currency#Exchange_Rate_Bot。前段时间，一位4WD维基网站的站长发起了一个更有趣的讨论，但我记不起在哪里看到了……

感谢您为我们的一些西班牙语相关文章添加了如此精彩的内容，Kizar！ --118.93nzp (讨论) 23:56, 2013年12月10日 (UTC)

你好，Kizar，感谢你提出一个可能帮助读者的想法。但是，我认为任何想查找外汇兑换的人都可以很容易地通过在任何网页浏览器中输入“外汇汇率”然后在那里输入数字来找到。并非所有能帮助读者的东西都在本指南的范围内，而且我认为我们不希望在本网站的每篇文章中都包含货币兑换表格。Ikan Kekek (讨论) 01:17, 2013年12月11日 (UTC)

不，当然不是转换表，但就像我们不一定想把人们推到谷歌地图（或者目前，推到维基百科）一样，我们可能希望开发技术能力来设置他们的用户偏好，以显示（a）一个辅助的实时货币转换（b）选择该辅助转换货币显示什么（类似于缩略图显示尺寸选择，我们应该能够为已注册和登录的读者提供……） --118.93nzp (讨论) 01:34, 2013年12月11日 (UTC)

我同意你——如果有人想开发一个能做到这一点的程序。Ikan Kekek (讨论) 02:50, 2013年12月11日 (UTC)

开发这样的程序很容易，但要找到一个能提供免费、可靠且无限次调用当前外汇汇率的网络服务将非常困难。当然，汇率不必是最新的。

我建议我们应该小心地与不受我们控制的外部服务集成，因为突然失去一个服务会大大影响本网站的质量。Andrewssi2 (讨论) 02:57, 2013年12月11日 (UTC)

相对不错的货币转换可能可以通过模板（可能还需要一些额外的JavaScript）完成，但要获得对实现方案的同意，然后在整个网站上实现它将是大量的工作。我建议这是一个可以开始起草提案的事情，并将其添加到路线图中，作为“未来考虑”之类的项目，但考虑到需要解决的其他网站问题数量，这可能不是目前可行的实现。Ryan • (讨论) • 03:29, 2013年12月11日 (UTC)

如何设置一个用户偏好和一个客户端JavaScript小工具，加载汇率数据并将其后缀到每个列表的价格上？例如：日元1500（10.6欧元）。不可机器读取的价格将不被显示，当然。猜测用户想要的货币很棘手，所以我们可以选择在用户设置偏好之前不显示任何内容。Nicolas1981 (讨论) 06:17, 2013年12月11日 (UTC)

使用Wikidata可能是一个选择，这样就可以在不同语言的Wikivoyage之间共享。 --Rschen7754 10:01, 2013年12月11日 (UTC)

也许不必使用模板。只需一个可选的JavaScript小工具即可进行文本替换。例如，列表编辑器会修改页面内容，将“编辑”链接放在屏幕右侧。该程序将获取汇率，在文本中搜索类似“€5.23”或“$2.33”的表达式，然后用转换后的值替换旧文本。

汇率可以免费从这个页面获取，只需创建一个免费帐户即可获得类似这样的内容，并且很容易将其格式转换为Javascript数组。JavaScript代码可以存储在Wikivoyage、Metawiki、Toolserver等地方，当然，一个机器人每天都可以更新它。

该小工具只需导入.js文件并使用数组。

示例：用户之前在某个地方定义了他想看到的欧元价格（欧元，€）。在一篇文章中，有文本“1000日元”（日元=日元）。JavaScript代码获取此文本，并将1000日元转换为9.74518美元，然后转换为7.06396欧元。操作很简单(1000 / currency_ex['JPY']) * currency_ex['EUR']，您就可以得到欧元。现在将“1000日元”替换为“7.06欧元”。其他货币的价格也将转换为欧元，用户将看到一切都是欧元，而无需更改文章源。Kizar (讨论) 15:03, 2013年12月11日 (UTC)

无论我们找到什么解决方案，我认为它都应该以括号的形式进行补充（而不是替换）。但无论如何，我认为这需要进一步的思考。例如，我认为它需要合理地进行四舍五入。当一个酒店的价格范围是“双人间R$60-80”时，我们不希望它变成“双人间美元$23.17-31.48”。那将过于精确。Texugo (讨论) 14:50, 2013年12月11日 (UTC)

如果用户货币价格<10，则保留2位小数，否则，则不保留小数。无论如何，我的提议是使用一个外部小工具，它不会修改文章的当前代码。如果用户在其偏好设置中选择禁用此小工具，他将看到页面和现在一样。即使这样，也可能只显示一个符号在价格旁边，当你点击它时，会出现一个小的弹出窗口。 --Kizar (讨论) 15:03, 2013年12月11日 (UTC)

那么，如果某件东西花费100美元，你想让它显示“日元10238”？四舍五入和有效数字不是这么用的。LtPowers (讨论) 20:30, 2013年12月11日 (UTC)

我认为不应显示超过2位有效数字。所以例子变成日元10000。任何显示出来的数字都将会在几天内有2-5%的变化，而且旅行者还需要支付佣金等。总的来说，我不确定这有什么好处，因为我旅行时，通常想看到当地货币的价格，这样我才能习惯我要支付的价格。AlasdairW (讨论) 22:02, 2013年12月12日 (UTC)

动态地图的语言

我刚从亚洲几周旅行回来，包括泰国，这是我第一次发现WV指南如此完整，以至于我真的可以好好利用它们，甚至发现它们比我的LP指南还好。事实上，这非常令人兴奋！然而，这也让我对我们目前的设置有什么（我认为）缺失、不足或不太实用之处有了一些见解。我发现的一个主要问题是，泰语的动态地图对我来说几乎是无法使用的，这迫使我转向其他在线应用程序和我的书来寻找路线。在泰国的主要目的地，如清迈，路标实际上是双语的，包括英语。这不仅更容易阅读，而且还能大致了解名称听起来是什么样的，这对于向出租车或嘟嘟车司机解释去哪里很有用。它是如何工作的？我们有选择地图使用哪种语言的选项吗？这方面有过讨论吗？JuliasTravels (讨论) 15:19, 2013年12月11日 (UTC)

在Wikivoyage talk:Dynamic maps Expedition#Shanghai map有一些讨论。Pashley (讨论) 16:17, 2013年12月11日 (UTC)

...讨论，其总结基本上是“我们无能为力”。在我看来，唯一的可行解决方案，在OSM方面没有任何未来发展的前提下，就是为那些本地语言使用非拉丁字母书写的目的地创建和维护静态地图。--AndreCarrotflower (讨论) 16:38, 2013年12月11日 (UTC)

那么，这是一种我还没有弄清楚或更新的误解。它基本上是WMF的一个整体计划，旨在为所有维基百科以及后续的维基旅游项目提供本地化的OSM地图，最初的目标应该在六个月前完成，但由于他们方面的问题一直被推迟。现在也有可能实现本地化地图，尽管开发服务器（可能超时）和准备好的生产服务器之间存在巨大差异，这就是为什么优先考虑加载速度和稳定的正常运行时间。

更有希望的发展是，ShareMap已经申请并很有可能获得拨款，这将极大地改进将维基旅游列表的坐标与OSM SVG文件一起导出，以便在Inkscape中定制（即创建和维护静态地图）。请理解，每添加一个纬度/经度都将使所有文章的静态地图更接近现实，如果动态地图有助于人们可视化和添加它们，那很好！这就是为什么它不像说静态地图好，动态地图坏或反之那么简单。 --torty3 (讨论) 17:22, 2013年12月11日 (UTC)

谢谢你为我澄清，torty3。我热切期待关于这个的进一步信息。--AndreCarrotflower (讨论) 21:22, 2013年12月11日 (UTC)

电话号码语法检查

我发现有大量电话号码不符合我们的电话号码语法。

我不指望任何人能全部修复。人类的最佳时间应该花在纬度/经度上，这是一个需要人类判断的小列表。

但无论如何，这里是电话号码，希望它能给人们一些关于如何处理它们的想法：第二页 第三页 第四页

祝好！Nicolas1981 (讨论) 08:18, 2013年12月11日 (UTC)

在这两个列表中，似乎有一些常见的错误可以通过“机器人脚本”来解决。电话号码中的（0）可以安全删除，错误的经纬度值通常是DMS格式（因此适合转换）或杂乱的文本（可以删除）。也许一些运行“机器人”的人可以发表评论？理想情况下，手动编辑应该集中在无法自动修复的问题上，因为我们的人工编辑资源有限。K7L (讨论) 18:11, 2013年12月11日 (UTC)

skobbler

"

柏林，2013年12月10日 /prnewswire/ --

全球在线/离线地图和导航 - 以袖珍价格提供卓越性能

• 完整的应用程序重新设计，提供更流畅、更直观的操作
• 真正的离线功能（通过应用内购买），包括所有功能，如国家、大陆和世界地图下载，以及城市和地区地图
• 来自OpenStreetMap的最新、最优质的地图数据，这是数字地图的未来
• 新优化的地图提供清晰的细节和流畅的浏览，在最需要的时候
• 基于NGx，世界上最强大的数字地图引擎，提供无缝的地图操作和定制
• 集成的“Wikitravel”和TripAdvisor数据，提供快速、最新的当地区域信息

skobbler，移动定位服务领域的创新者，宣布对其极其成功的GPS导航进行重大更新——这是iOS上最受欢迎的导航解决方案。凭借一系列强大的新功能，旨在将iPhone或iPad变成高端导航仪，它以非高昂的价格提供了卓越的性能。无论在家还是在国外，GPS导航都提供了最终的灵活性，允许消费者在有互联网连接时使用在线功能，或者通过应用内购买下载地图（从单个城市到整个世界），以便在连接不良或漫游数据区域使用。

"

我已加重。是否应该有人告诉他们Wikitravel已经过时了？（我自己会做的，除了我是匿名且地位低下，由非匿名且地位较高的人去做会更好……） --118.93nzp (讨论) 02:10, 2013年12月12日 (UTC)

查看WT的“最近更改”表明该网站处于休眠状态，尽管没有任何迹象表明它已经过时。（有一些活跃用户在勇敢地添加内容，同时受到垃圾邮件的干扰）

顺便说一下，称自己为“低地位”可能不是个好主意，因为这是大多数人（包括管理员）试图避免的概念。任何有建设性贡献的人（无论频率或数量如何）都应享有平等待遇。Andrewssi2 (讨论) 02:22, 2013年12月12日 (UTC)

小工具请求

不确定在哪里提出这个请求，但能否有人导入w:en:Special:Gadgets/export/righteditlinks 和 w:en:Special:Gadgets/export/addsection-plus？谢谢。Smokestack Basilisk (讨论) 15:41, 2013年12月13日 (UTC)

如果您能为每个小工具提供一些背景信息，可能会有帮助。LtPowers (讨论) 21:32, 2013年12月13日 (UTC)

当然，w:en:Special:Gadgets/export/righteditlinks 将编辑链接放回屏幕右侧，而w:en:Special:Gadgets/export/addsection-plus已安装。另一个我认为有用的工具是w:en:Special:Gadgets/export/OldDiff，它将差异颜色恢复为原始Mediawiki的红/绿色格式，并改变差异的空间格式。我认为传统的差异格式比新格式更容易阅读。因为这些只是用户小工具，不会改变任何默认设置，它只是允许用户为自己的偏好进行设置。Smokestack Basilisk (讨论) 22:02, 2013年12月13日 (UTC)

实际上，此维基上禁用了小工具导入功能，所以您必须复制粘贴enwiki的源代码。 --Rschen7754 10:03, 2013年12月14日 (UTC)

重复文本

您好。

以色列有一个主要机场。大多数以色列城市的页面都有“抵达/飞机”部分。想法是相同的，但措辞和细节程度不同。例如

• 耶路撒冷 #飞机抵达
• 特拉维夫 #飞机抵达
• 海法 #飞机抵达
• 埃夫拉特 #飞机抵达

有没有办法通过模板或其他方式标准化一些重复的文本？

TaBaZzz (讨论) 07:05, 2013年12月15日 (UTC)

当然。这正是模板擅长的工作，以便信息可以在一个中心位置更新，而不是必须在多个文章中更新……感谢您为改进我们的旅行指南做出贡献！--118.93nzp (讨论) 07:17, 2013年12月15日 (UTC)

更确切地说，应该引用一个包含详细信息且易于更新的单一机场页面。这就是我们拥有机场页面的原因。如果您认为信息量不足以创建单独的机场文章，请将其包含在例如特拉维夫的文章中，并从其他城市文章链接到特拉维夫#飞机抵达。PrinceGloria (讨论) 09:33, 2013年12月15日 (UTC)

还有以色列#飞机抵达。我猜本·古里安机场是一个足够大的机场，可以拥有自己的文章，如果有人想写的话。我们可以在Wikivoyage talk:Airport Expedition进一步讨论这个问题，在那里通常会就机场文章的创建或不创建达成共识，但我怀疑会有人反对。这是以色列主要的国际机场，关于安检程序和地面交通有很多内容可说。Ikan Kekek (讨论) 09:44, 2013年12月15日 (UTC)

Snowolf

这是一条通知，让大家知道User:Snowolf已辞职，因为权限移除是在Meta上完成的： --Rschen7754 02:46, 2013年12月17日 (UTC)

我感谢大家的善意和对我信任，首先选择我为临时管理员，然后确认我为永久管理员。我从未能够像我希望的那样为这个项目付出努力，而且在过去几个月里，我的可用时间大大减少，因此我无法预见到我的活跃度会发生变化。我还想向大家为我在这里不活跃的记录道歉，这是我当初请求大家信任时未能预见的。我仍然活跃于我作为监督员、元维基管理员以及我们在IRC频道上的职责，如果需要，我随时可以在Meta上找到我。Snowolf ^{我能帮忙吗？} 03:03, 2013年12月17日 (UTC)

感谢您在此的贡献。很遗憾 您在此的建议 未能推进…… --118.93nzp (讨论) 03:10, 17 December 2013 (UTC)

很高兴见到您，Snowolf，即使是因为这件事。不用道歉。如果您发现您有更多时间，我知道大家都会欢迎您回来多做编辑，或参与更多政策讨论。 Ikan Kekek (讨论) 03:34, 17 December 2013 (UTC)

酒店名称中的星级以显示其评级

有些条目在酒店名称中包含星号*以表示其评级。例如，请参阅 https://wikivoyage.cn/wiki/Beruwela#Sleep

这是推荐的风格，还是应该删除它们，或者现状就可以？我整理了包含此类星号的146个条目列表，请随意按需修改： https://wikivoyage.cn/wiki/User:Nicolas1981/Syntax_checks#Stars

祝好！ Nicolas1981 (讨论) 03:19, 16 December 2013 (UTC)

星级系统不是有些可疑吗？在许多地方，非连锁酒店可以像“四星级酒店”一样自评，而不是官方认证。 Andrewssi2 (讨论) 03:37, 16 December 2013 (UTC)

没有达成共识将星号符号包含在酒店评级中，有些用户看到它们就会删除。我认为在酒店列表的“内容”选项卡中用散文方式注明星级数量是可以的。我不认为星号应该被正式允许在酒店列表中使用。但是，虽然我不会在酒店列表中使用星号符号，但删除所有包含在酒店列表中的星号比其他更紧迫的事情要好，这些星号通常是针对像意大利这样的国家，在当地酒店列表中通常会强调星级。 Ikan Kekek (讨论) 05:44, 16 December 2013 (UTC)

在不受监管的国家，评级是可疑的，但在受监管的国家则有用。级别也取决于国家。无论如何，我认为此信息不属于“名称”字段……也许像Ikan建议的那样放在“内容”字段？多年以后（当我们完成了所有伟大的项目，并且无事可做的时候），我们甚至可以为此创建一个特殊的字段。 Nicolas1981 (讨论) 09:03, 16 December 2013 (UTC)

那么，由于国家之间不一致，它就会变得可疑。:) 无论如何，我很乐意在“内容”中提及此类评级。 Andrewssi2 (讨论) 09:38, 16 December 2013 (UTC)

这个问题以前已经出现过几次，最近一次是在 Wikivoyage:Words to avoid#Stars Ratings。我认为共识是我们根本不应该使用星级评级，除非有非常特殊的原因。有太多的评级系统，而且机构很容易自创评级，如果我们鼓励添加星号并命名评级系统，那会暗示我们的评估可能是基于该评级系统，而不是基于旅行者的个人经验。我们最重要的指导方针之一 WV:The traveller comes first 规定

区域、价格分类等基于旅行者的便利和期望，而不是官僚命令（行政区划、正式星级评级等）。（我的重点）

实际上，我曾以为我们对星级评级的厌恶已经写进了政策的某个地方，因为我们多年来一直采取相当一致的做法。显然还没有，但我当然不介意如果我们把它写在某个地方。无论如何，在任何情况下，未经修饰的星号字符串都不是机构的名称的一部分，所以没有人应该在名称字段中放置星号。我是那些看到它们就删除的人之一，而且我实际上确实觉得这样做总是值得的。 Texugo (讨论) 11:00, 16 December 2013 (UTC)

有 评级系统、wikivoyage:don't tout 和 wikivoyage:words to avoid。我怀疑含糊的说法，如“五星级服务”是应避免的词，因为它们是宣传性的，除非明确了特定的评级系统，并且该评级机构确实派出检查员根据既定标准进行评估。“米其林指南2001年授予四只爆胎”是有效的，如果米其林确实派出检查员，“我们的五星级服务将使商务和休闲旅客满意”是无意义的。本地目录给的一星和专业高端指南给的一星之间有很大的区别，后者往往根本不收录差的或一般的酒店。名称中的星号暗示“不含电池”或其他免责声明，而不是奖励，除非经过解释。 K7L (讨论) 18:41, 16 December 2013 (UTC)

我不认为使用这些评级是个好主意。参见 Rating systems 的开篇部分。 Pashley (讨论) 21:49, 16 December 2013 (UTC)

列表为CSV格式

我改进了所有 Wikivoyage 列表的 CSV 格式，我认为现在看起来很好，并且应该允许进行许多混搭。

https://sourceforge.net/projects/wikivoyage/files/Listings-as-CSV/enwikivoyage-20131130-listings.csv

请告诉任何使用 WT 数据的人，他们没有借口不切换到 WV：使用 CSV 文件比进行网络抓取容易得多。

您还需要其他 CSV 或数据吗？

Google Code 将关闭下载，所以我复活了老牌 SourceForge。是的，我大胆创建了一个“Wikivoyage”项目。如果 Wikimedia 有账户，我很乐意将项目转移给他们。同时，我将把所有 Wikivoyage 提取的数据分发在那里。 Nicolas1981 (讨论) 03:34, 16 December 2013 (UTC)

w:WP:GP#User:Yair_rand/PanoramicBanners.js

顺便说一句，我正在维基百科上提议一个利用维基数据中的 Wikivoyage 横幅的小工具。 --Yair rand (讨论) 05:28, 16 December 2013 (UTC)

您认为 Wikivoyage 目前拥有哪些最好的横幅？

我在这里尝试整理了这样一个列表 here。请告诉我您是否知道任何其他（未包含在此页面的）特别成功的横幅，并且您认为它们质量相当。我清楚这样的列表最终会基于每个用户的个人品味，但我仍然会很感激如果大家能在此提及您认为目前哪些特定的横幅看起来最好。 ויקיג'אנקי (讨论) 23:43, 16 December 2013 (UTC)

我们有一个 Star banners 页面，但它从未真正开始。我认为 Inkey's、Armigo's 和 Danapit's 的上传都非常棒。 Jjtkk (讨论) 07:13, 17 December 2013 (UTC)

我明白了。这让我想起，有没有可能有一个链接可以自动生成维基共享资源上 Wikivoyage 最新横幅的列表？ ויקיג'אנקי (讨论) 15:49, 17 December 2013 (UTC)

commons:Category:Wikivoyage banners。 --Saqib (讨论) 15:52, 17 December 2013 (UTC)

那里的文件分为很多子类别——实际上子类别太多了，用户无法快速了解最新添加的内容。这就是为什么我希望有一个方法可以快速自动生成维基共享资源上 Wikivoyage 最新横幅的列表。 ויקיג'אנקי (讨论) 18:14, 17 December 2013 (UTC)

链接上的几乎都是陆地/城市景观，但我认为我们最好的有些不那么明显。 Kyoto 有一个不错的。我最喜欢的是 Hiroshima。图像质量很高，但更重要的是，鹤象征着这座城市，但并非总是最明显的象征（例如，原爆圆顶或某些纪念碑）。列表上的所有都看起来不错，但它们基本上都是同一种风格。 ChubbyWimbus (讨论) 05:45, 18 December 2013 (UTC)

有 Android？导入所有 Wikivoyage 列表！

亲爱的 Android 用户，

这是一份简单的 操作指南，描述了如何将所有 Wikivoyage 列表导入到 OsmAnd 地图应用程序（免费、开源、GPS 导航/地图即使离线也能工作）。

场景：您空降到一个随机国家，毫无准备，没有互联网。

• 只需打开 OsmAnd，Wikivoyage 的酒店等信息就会显示在地y图上！
• 一旦您选择了一家酒店，让 GPS 指导您。

OsmAnd + 离线世界基础地图：150 MB
Wikivoyage 列表：3 MB
OxygenGuide，不仅有列表，还有完整的指南：475 MB
独立性：无价

不要犹豫：您需要在手机上安装这个 :-) Nicolas1981 (讨论) 06:19, 17 December 2013 (UTC)

还没有试过，但看起来很棒！您能分享一下列表导出的秘密吗？我们也想为其他语言这样做。 --Alexander (讨论) 07:27, 17 December 2013 (UTC)

我的秘密是 Github 上的开源代码 :-) 请 fork，或者更好的是直接在脚本中实现国际化，我很乐意拉取您的贡献！在我的笔记本上进行验证/生成需要一天以上的时间，所以我现在正尝试让脚本在每次有新 dump 可用时自动在 Wikimedia Labs 上运行，一旦您的代码准备好，我当然也会为俄语设置它。 Nicolas1981 (讨论) 08:44, 17 December 2013 (UTC)

好的，让我试试。我不擅长写代码，只懂一些基本的 Unix 命令，但我应该能够用 ru: dump 运行你的代码，然后看看该改变什么。希望只需要很少的改动。

您能考虑保留/生成 POI 编号，以便它们与 Wikivoyage 文章一致吗？ --Alexander (讨论) 09:27, 17 December 2013 (UTC)

这些 ID 是 OSM 格式必需的，但它们实际上并没有出现在 OsmAnd 的任何地方……不过是个好主意！我们可以计算 POI 编号并将它们连接到 POI 名称，这样 POI 名称就会变成例如“3: Bar Chez Roger”。您对此怎么看？ Nicolas1981 (讨论) 06:03, 18 December 2013 (UTC)

嗯，这已经是不同的了。我曾想让 OsmAnd 地图类似于我们的动态地图，其中每个 POI 都会在其符号中显示其编号。但我不知道这在 OsmAnd 上是否可能。 --Alexander (讨论) 07:16, 18 December 2013 (UTC)

Wiki Loves Monuments 照片比赛

九月份举办的照片比赛的获奖者已在 宣布。这些是国家注册的（标准因国家而异）历史建筑的精彩照片。我认为我们应该利用其中一些——我们可能会从任何关于结果的宣传中受益。 AlasdairW (讨论) 23:33, 18 December 2013 (UTC)

最全面的指南

我认为，与传统指南相比，我们的一些指南非常全面。你们认为我们应该创建一个类似于星级条目的列表，列出我们最全面的指南吗？ --Saqib (讨论) 11:36, 18 December 2013 (UTC)

不用。星级条目需要全面，这部分已涵盖。如果我们有一些全面但质量不高的条目，请提名它们参加 Wikivoyage:Collaboration of the month；也许我们可以让它们达到星级。 Pashley (讨论)

好的，但遗憾的是，CotM 现在似乎已经失效了。 --Saqib (讨论) 09:13, 19 December 2013 (UTC)

列表编辑器中的缺陷

请原谅我的抱怨，但列表编辑器是我们可能比 Wikitravel 强大得多的一个方面。

您知道我的意思——就是点击列表末尾那个灰色小“编辑”文字时弹出的东西？

1) 住宿类型列表不显示（也不破坏）“入住”和“退房”字段

2) 24 小时格式的示例是错误的（这对于美国以外世界上大多数国家都应该是要使用的格式）。

我的建议是改变示例，从
9AM-5PM 或 9:00-17:00 到
08:30-16:30 或 8:30AM-4:30PM，这样编辑器就能明白我们使用冒号分隔小时和分钟，并且在使用（在印刷品中更常用）的 24 小时格式时，始终使用两位数字表示小时……

3) 货币符号

₹ ₪ ₱ Kč

丢失了。

(这些符号分别在 Wikivoyage:$#Universally_known_currency_notation_exceptions 中被推荐用于印度卢比、以色列新谢克尔、菲律宾比索和捷克克朗。添加 RM、Rp 和 Rs 符号也可能值得，但这不那么紧迫)。

如果有什么方法可以自己修复最后两点，请告诉我…… --118.93nzp (讨论) 23:51, 18 December 2013 (UTC)

指向可下载的开源全面免费 GPS 地图文件（国家或大陆）的外部链接，这些文件是使用 OpenStreetMap 创建的

在希伯来语 Wikivoyage 中，我们最近在许多文章的底部添加了指向此类免费合法文件的外部链接，这可能会极大地帮助旅行者。我本人去年就使用了这样的地图，它帮助我在欧洲一个以前从未开过车的地方开车导航，而无需购买该国的新 GPS 设备（GPS 制造商显然希望旅行者这样做，尽管如今人们可以合法地下载世界上大多数国家的免费开源 GPS 地图并加载到自己的 GPS 设备上）。这样做的方式非常简单——如今许多 GPS 设备都有记忆卡插槽，您可以在其中放入包含任何免费开源 GPS 地图的记忆卡。由于每个国家的地图会占用记忆卡上可用空间的大部分，而且这些记忆卡现在价格很便宜，所以很多情况下，旅行者更容易将每个旅行目的地的国家 GPS 地图复制到单独的记忆卡中，并将它们全部放在相机包里）。

您可以在这里看到一个此类链接的示例 here（链接出现在 GPS 图标旁边，并写着“免费下载的 Garmin GPS 设备 GPS 地图 - 基于来自免费地图网站 OpenStreetMap 的地图生成的免费 GPS 地图。应注意的是，此地图由私人方开发、更新和分发，而不是由 Garmin 分发。英文安装说明”）。

您是否支持在英文 Wikivoyage 上也这样做？ ויקיג'אנקי (讨论) 07:01, 19 December 2013 (UTC)

您可以在 OpenStreetMap wiki 的 此页面 上找到许多指向免费可下载开源 Garmin GPS 地图的链接。 ויקיג'אנקי (讨论) 07:05, 19 December 2013 (UTC)

我赞成添加此类信息，但也许格式可以更紧凑一些？一个完整的版块有点太大了，也许左侧栏的链接会更好？顺便说一句，很遗憾链接的页面只有德语。它主要是针对国家条目，对吧？数据文件通常是针对一个国家或大区域，而不是单个目的地。我没有 Garmin，但我认为这个提示对 Garmin 用户非常有用了！顺便说一下，OsmAnd 也有类似的下载地图（所有文件可在此 处下载）。 Nicolas1981 (讨论) 07:18, 19 December 2013 (UTC)

缺失的跨语言链接

似乎有些页面上的语言链接出了问题：最近更改、特殊页面等。有人知道发生了什么吗？它们的维基数据项被撤销了吗？ Texugo (讨论) 10:35, 19 December 2013 (UTC)

“最近更改”项目现在应该已恢复。相关讨论请参见 d:Wikidata:Requests for comment/Interwiki links for special pages。 --Rschen7754 18:54, 24 December 2013 (UTC)

活动和节庆日历

“活动和节庆日历”页面已经有一段时间被忽略了。我想提议改变格式，但在花费大量时间（除非有其他人愿意帮助）进行修改之前，需要一些反馈。考虑 使用此格式，但将所有月份和主题页面合并到一个页面。这种表格方法允许读者按月份、地点或主题排序。赞成还是反对？有什么改进建议吗？ --Traveler100 (讨论) 13:13, 21 December 2013 (UTC)

维基的本质是，无法保证您的工作不会在某个时候被删除（至少从公众视野中）。但是，我注意到了您在做什么，我很感激。我认为活动日历在有足够多的人来维护它时会很有用（这是任何条目的潜在问题，但当有日期每年都会变化的节日和庆典时，问题会更严重）。我现在没有具体的建议，但我希望鼓励您继续前进并进行实验。 Ikan Kekek (讨论) 13:33, 21 December 2013 (UTC)

{edit conflict}

初步想法

• 这将是一个非常巨大的表格，尤其是如果我们像需要的那样详尽地填充它来使其全面。即使按大洲细分，表格也会相当笨重。
• 它浪费了很多空白，而且描述越长，其他字段浪费的空间就越多。
• 图像字段，使用时，会大大增加其他字段的浪费空间。
• 需要定义一组分类，我们将一切归入其中，这是有问题的。慕尼黑啤酒节在多大程度上是文化活动，又在多大程度上是饮食活动？圣保罗的日本节既是贸易展览会，也是文化博览会和美食节。德克萨斯州博览会是一个有嘉年华游乐设施和文化景点的牲畜展，也以其不寻常的油炸食品而闻名。许多其他活动也同样难以明确分类。

我欣赏实验，但尚未确信表格就是答案。 Texugo (讨论) 13:43, 21 December 2013 (UTC)

Texugo (讨论) 13:43, 21 December 2013 (UTC)

另一个想法是使用活动列表模板。粗略示例 here。这可以用于活动页面和地点文章内部。与目前使用的自由格式相比，其优点是可以轻松识别过期的活动（通过类别或机器人）以便更新。 --Traveler100 (讨论) 15:34, 21 December 2013 (UTC)

由于活动日历页面很少得到关注，并且总是难以维护，为什么不让它们自动从地点文章页面上的活动列表中编译呢？方法是在文章页面上使用活动列表模板，它有一个月份和类型参数，可以将该地点页面放入活动类型和月份类别。然后将这些类别的内容列在活动日历页面上。因此，贡献者只需将活动添加到地点文章，活动日历就会自动构建。 --Traveler100 (讨论) 10:21, 22 December 2013 (UTC)

我认为这是一个好主意。我建议某种重要性评级，例如 1 = 如果在步行范围内就值得去…… 5 = 值得乘坐长途航班去。这应该可以防止世界杯在几十场村级足球比赛中被淹没。 AlasdairW (讨论) 11:22, 22 December 2013 (UTC)

我曾想过如何处理活动的不同重要性（本地或全球），这是个好主意。 --Traveler100 (讨论) 11:37, 22 December 2013 (UTC)

所以，活动组织方法是按类型、月份和国家，但列出的是条目，即地点、名称。例如，Dinagyang Festival 列在 一月份活动 和 文化活动 下，但其地点是 Iloilo (city) 而不是活动名称。除非为活动创建一个页面，例如 Sochi 2014，否则我看不出更好的方法，而不使用户输入过于复杂。 --Traveler100 (讨论) 16:27, 22 December 2013 (UTC)

我讨厌听起来过于挑剔，因为我没有在这方面提出任何更好的建议，但创建 72 个新类别，分为相当主观的 5 个类别，听起来比以前需要更多的维护工作，而不是更少，而且这些类别页面只能是目的地名称的简单无中断列表，需要点击每个目的地才能找到是哪些活动，这似乎并不是用户友好性的改进。 Texugo (讨论) 02:30, 23 December 2013 (UTC)

我完全理解您的观点。我只是通过实验和建议来寻找解决方案。目前我唯一的其他想法（除了完全删除日历页面之外）是在地点文章页面上使用活动列表模板，不直接使用类别，而是使用机器人来编译活动日历页面。但我不确定如何编写这样的机器人。 --Traveler100 (讨论) 06:46, 23 December 2013 (UTC)

• 为什么不链接到维基百科，或者利用维基数据获取大部分信息，而不是在这里重新创建所有内容，特别是对于索契、世界杯等重大活动，它们会提供完整的日程安排，对于整个 WV 的方法，活动应仅限于可以放在首页的主要国际活动。然后为国家、地区、城市活动设置日历选项，通过将日期包含为类别并让机器人运行以删除已过期的活动（例如，事件发生 7 天后），机器人维护将是可行的。 Gnangarra (讨论) 01:35, 25 December 2013 (UTC)

创建了 {{Event}}，可用于日历页面和地点文章。提供标准格式，有利于维护（创建包含过期事件的类别）。还创建了按类型、日期和地点分类的隐藏类别，可用于查看页面上可供更新的内容。这类似于列表模板，如果此实验有效，可以考虑合并功能。 --Traveler100 (讨论) 12:35, 26 December 2013 (UTC)

我想停止创建更多类别，直到它经过更彻底的评估和讨论。我看到的是“Events in XXX”类别的快速创建。到目前为止，正如 一月、二月 等页面的处理方式，最终将属于数百个此类类别（它们已经堆积了很多类别），这并没有什么意义。此外，这种方法基本上是从地理层级开始重新创建“events in”类别，这正是我们最近才从为主题文章做的这件事中撤回的。 Texugo (讨论) 16:31, 26 December 2013 (UTC)

这些类别不是给读者看的，想法是作为基础来使 活动和节庆日历 页面达到可用水平。但说实话，浏览这些页面时，我甚至认为它们应该被删除。很明显没有人长期更新，而且它们已变得无用。维护这些页面需要大量工作，而似乎没有人感兴趣。建议将所有内容移至相应的地点页面，并使用活动模板（如果愿意，可以关闭类别），这样至少可以轻松保持最新（模板有一个检查类别）。 --Traveler100 (讨论) 18:39, 28 December 2013 (UTC)

将 Mapframe 复制到其他语言的 Wikivoyage

我将 Mapframe 和 PoiMap2 复制到了荷兰语 Wikivoyage。但是，我认为还需要做更多的事情才能使其工作。我没有得到地图，只有地图下方的链接可以打开全屏版本的地图。我没有收到任何错误消息，所以我不知道缺少什么。有谁能帮我吗？ --FredTC (讨论) 10:17, 22 December 2013 (UTC)

可能是网站范围的 Javascript 或 CSS（在 MediaWiki: 命名空间中）有所更改？ K7L (讨论) 05:10, 23 December 2013 (UTC)

谢谢您的回复。您能告诉我如何访问 Javascript 和 CSS 吗？然后我就可以比较两个语言的版本了。 --FredTC (讨论) 09:35, 23 December 2013 (UTC)

MediaWiki:Gadget-MapFrame.js --Adehertogh (讨论) 11:47, 23 December 2013 (UTC)

也许是另一个问题，但在英文 Wikivoyage 上，地图也常常不显示。刷新（F5）通常可以解决问题。 Nicolas1981 (讨论) 04:28, 2013年12月24日 (UTC)

我在英文 Wikivoyage 上从来没有遇到过这个问题。不过，我在荷兰文 Wikivoyage 上用 IE 和 Mozilla 都试过 F5，但地图都没有出现。所以我想我必须在 JS 和 CSS 文件中找到问题的解决方案。--FredTC (讨论) 05:38, 2013年12月24日 (UTC)

请考虑一下 Template:Mapframe 的文档（段落代码：与小工具一起使用：Mediawiki:Gadget-MapFrame.js。如果禁用了该小工具，用户只会看到一个链接到全屏动态地图的标题。使用 HTML5 数据参数向 iframe 传递变量，需要高级 POST 查询才能进一步影响 iframe。）。也许这就是解决方案？-- Joachim Mey2008 (讨论) 06:56, 2013年12月24日 (UTC)

圣诞快乐

愿这一天带给你健康和成功。愿你和你的家人体验到上帝的爱之拥抱，愿你们的节日季充满爱、喜悦与和平。祝大家圣诞快乐！--Saqib (讨论) 14:06, 2013年12月25日 (UTC)

也祝你圣诞快乐，Saqib。-- AndreCarrotflower (讨论) 18:56, 2013年12月25日 (UTC)

谢谢！也祝你和这里的各位新年快乐，成功，没有仇恨/喷子！(我的天...) ϒpsilon (讨论) 09:32, 2013年12月26日 (UTC)

谢谢 Saqib！也祝这里所有人圣诞快乐！ :) --Nick ^讨论 12:13, 2013年12月26日 (UTC)

1984 还是 2014？

我们也有一些管理员不必要地干涉其他用户的用户空间的问题，但常常更容易看到自己邻居眼中的木屑：在移除 Evan 的管理员权限后不久，Wikitravel 的 IBobi 再次改写了历史。--118.93nzp (讨论) 21:57, 2013年12月30日 (UTC)