维基导游:旅行者酒吧/2013（附加）

旅行者酒吧存档： 2007 • 2008 • 2009 • 2010 • 2011 • 2012 • 2013 • 2013（附加） • 2014 • 2015 • 2016 • 2017 • 2018 • 2019 • 2020 • 2021 • 2022 • 2023 • 2024 • 2025

2013年额外存档页面

将内容扫到2013年存档页面被证明是不可靠的。这是因为该页面太大，每次添加都需要保存整个页面。在所有2013年的对话都被扫除后，这可以与主存档页面合并回来。Andrewssi2 (讨论) 2014年1月18日04:29 (UTC)[回复]

区域模板和版块问题

这篇文章的结构是否符合版块和模板指南？特别是参观子版块

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

如果符合，我将用它来创建其他区域文章。

另外，为什么这篇文章中没有出现目录？
--TheMightyHercules (讨论) 2013年10月27日23:48 (UTC)[回复]

我猜如果目的地真的有很多值得看的东西，那么版块是没问题的。目录在顶部的横幅中显示为一行。Nicolas1981 (讨论) 2013年10月28日03:03 (UTC)[回复]

当有很多可看之处时，分段当然没问题。你想有多少和哪些分段取决于该区域景点的类型。查阅我们的一些明星区域文章，如旧金山/唐人街-北滩#参观、巴黎/第一区#参观或芝加哥/布朗斯维尔#参观。我实际上认为教育机构只有在其建筑具有建筑或其他“被动吸引”价值时才应列在“参观”项下。否则，它们可能应该放在“做”之后的一个单独的“学习”部分。JuliasTravels (讨论) 2013年10月28日17:21 (UTC)[回复]

只是一个小小的旁注，我认为“学习”更适合城市级别的文章，而不是区域级别的文章。人们通常选择在一个城市定居更长时间以进行学习，而不是在某个特定区域，因为从一个城市的某个区域到另一个区域学习并非不可能。PrinceGloria (讨论) 2013年10月28日19:54 (UTC)[回复]

我们通常不列出需要“定居”才能做的事情。大多数“学习”列表应针对一日烹饪课程或为期一周的语言课程等。没有理由将这些内容放在城市主页上。Texugo (讨论) 2013年10月28日19:57 (UTC)[回复]

嗯，目前这些版块里都是关于长期学习、大学等方面的建议，所以我以为它们就是这样使用的。短期学习的选择会少很多，我猜想，而且我认为这并不与城市内的某个特定地点相关联——你通常需要连续几个小时，如果不是一整天，或者连续几天或几周几个小时来学习任何东西。这意味着这些建议不应该与旅游景点归为一类，旅游景点通常围绕着“当你身在那里时，为什么不也看看这个/做这个/在那里吃饭”的原则运作。参与学习体验需要不同程度的计划，而且它反过来很少会与你将要发现的某个特定区域相关联，而是与你计划长期居住的城市相关联。PrinceGloria (讨论) 2013年10月28日22:01 (UTC)[回复]

这并不是一个更有力的论据，将它们放在主条目中，而不是酒店。主页上之所以突出/总结事物，是因为它们对城市整体体验的重要性，而不是因为城市整体体验对它们个体的重要性。Texugo (讨论) 2013年10月28日22:18 (UTC)[回复]

回到前面一点，我并不完全同意Texugo之前所说的话。虽然旅客可能不需要知道如何在一个只停留很短时间的城市报名参加长期课程，但我发现提供关于该地区学院和大学的简要信息是让读者更好地了解一个城市的整体特色或“感觉”的好方法。我认为这对于大型城市的区域文章尤其如此——当该区域包含一所大型大学，而这所大学是其独特身份的重要组成部分时，例如布法罗/埃尔姆伍德村，则更是如此。然而，这些信息可能不应该以列表的形式出现。-- AndreCarrotflower (讨论) 2013年10月28日22:50 (UTC)[回复]

我说的与其说是个人意见，不如说是对该主题传统建议的反映。虽然我同意你的观点，在某些情况下，简要提及当地大学可能具有文化相关性，但我认为这些是普遍规则的例外——描述典型的中小型城镇的社区学院在很大程度上是不相关和不需要的。无论如何，除非校园内有实际值得看的东西，否则不应将其列为“参观”列表；除非它们确实提供了一些短期且对旅行者可能感兴趣的东西，否则不应将其列为“学习”列表。在“了解”部分中进行简要的散文描述（或者更可能是在与大学夜生活区相关的提及）是可以的，如果它确实与城市的特色相关。对于“繁琐县社区学院”或“笨拙河技术学校”的随机信息应广受劝阻。Texugo (讨论) 2013年10月29日00:13 (UTC)[回复]

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

即使我们不把它放在“学习”部分，我仍然认为这些信息可以而且应该包含在某个地方。再次强调，旅客可能不需要知道如何在一个停留时间很短的城市报名参加学期制大学课程，但让旅客更好地了解他们选择访问的地方的特色确实能帮助他们。-- AndreCarrotflower (讨论) 2013年10月29日02:17 (UTC)[回复]

我同意安德烈特的观点，我还想说，在像克林顿（纽约）这样的大学城，不提供当地大学网站的链接是荒谬的，因为即使这所大学没有建筑意义，也不举办可能吸引非学生或非教职员工的文化活动，它也几乎是镇上唯一的看点。Ikan Kekek (讨论) 2013年10月29日04:30 (UTC)[回复]

[缩进重置] 我同意上面大部分观点。我坚信关于城镇作为大学城特征的信息应该放在“了解”而不是一个单独的版块中，而且“可看”/“可参观”的教育机构应该放在“看”或“做”中，这取决于机构的性质。
我发现，如果有什么“学习”的内容不只是“做”，并且值得单独分一个版块，那将是一个不寻常的情况。我仍然认为，对于大城市来说，大部分内容最好在城市层面处理，就像在城市层面列出大使馆、医院或机场，而不是将它们限制在区域层面并剥夺城市层面的信息。这并不意味着单个区域文章不应该在它们的“了解”或“方向”版块中提及这些内容，如果城市独有的服务/机构在这些区域内的位置影响了它们的特征或在其中的方向。PrinceGloria (讨论) 2013年10月29日05:45 (UTC)[回复]

在真正的大城市里，我认为虽然值得简要提及学习机构的例子，但它们的实际条目通常属于区域文章。例如，新社会大学有很多音乐会和讲座，这些应该列在曼哈顿/西村文章中，并附带新社会大学活动日历的链接（我不确定它们是否已经列出），而不是曼哈顿文章。Ikan Kekek (讨论) 2013年10月29日06:06 (UTC)[回复]

这对我来说看起来非常像一个“做”的类别。我们没有单独的“体育”类别，那为什么我们需要一个单独的“在教育机构中做事情”的类别呢？这些都是“做”。如果一个区域有很多事情可以“做”，我们用三级标题做得很好。PrinceGloria (讨论) 2013年10月29日09:47 (UTC)[回复]

你可能说得对。我猜我唯一的问题是，消除所有“学习”副标题并将大部分条目移到“做”中，以及一些移到“参观”中，是否值得付出额外的努力。Ikan Kekek (讨论) 2013年10月29日09:51 (UTC)[回复]

我们最好不要再在新创建和扩展的文章中添加“学习”部分，我们可以根据具体情况处理现有的问题。有很多清理工作要做，而且我们中的一些人实际上正在做这项工作，只要我们同意这样做（而不是通过创建新的“学习”部分来增加问题），问题就会在适当的时候得到解决。PrinceGloria (讨论) 2013年10月29日10:15 (UTC)[回复]

我没有检查过，但是如果达成共识，可能需要删除一些显示可选“学习”子标题的文章模板。此外，可能需要检查你可以把它放在哪里。Ikan Kekek (讨论) 2013年10月29日10:27 (UTC)[回复]

我非常乐意停止使用“学习”部分。我发现人们经常想列出大学，而这实际上与旅行者信息无关。(除非大学值得参观，比如海德堡，但那样的话它应该列在“参观”下) 我认为具体的课程（烹饪、语言学习等）仍然是很好的内容。Andrewssi2 (讨论) 2013年10月29日10:30 (UTC)[回复]

确实，学习部分的用途经常被误解，它不仅被用来列出大学、学院甚至公立学校，还被当作一个列出读者可能想了解的随机琐事甚至“学习更多”目的地资源的版块。我不太确定我对废弃它所需要的所有工作有什么看法。Texugo (讨论) 2013年10月29日11:58 (UTC)[回复]

即使是几周的课程（比如希库蒂米-容基耶尔的容基耶尔学院，它以其为渥太华文职人员提供的为期三周的强化法语作为第二语言课程而闻名，且没有当地学生），在“了解”部分中简要提及该学校，以及镇上的其他工业历史（纸浆/造纸、铝业）就足够了。“学习”部分不会增加太多内容。

是的，如果一所大型大学在一个本来很小的城镇中，这所学校可能会主导一篇文章。“宾夕法尼亚州立大学城”的文章如果不将帕特诺的雕像转180度，“以便他可以避开并对桑达斯基事件视而不见”，那么这篇文章将是不完整的，因为这所学校和球队是该镇最著名的地标。尽管如此，像“伊利诺伊州诺默尔以‘师范学校’或州立师范学院命名”这样的信息属于“了解”部分，而校园本身（如果具有建筑特色或拥有博物馆或音乐厅）可能属于“参观”部分（其中任何具体活动都属于“做”）。我们不需要“学习”作为另一个部分，因为学校是作为旅行者所看到的来描述的，而不是临时的四年制住宿学生。K7L (讨论) 2013年10月29日14:50 (UTC)[回复]

但这不仅仅是大学。一个问题是，我们是否想将开放大学讲座系列、烹饪学校、葡萄酒和奶酪搭配课程、当地手工艺作坊和5所西班牙语会话学校放在做的单一子版块中。Texugo (讨论) 2013年10月29日15:00 (UTC)[回复]

我个人认为“学习”和“做”之间没有多少实际区别。我正在考虑“学习”应该被弃用，因为它对于现有文章和存在大量学习机会的新文章（如你的列表）仍然有效。然而，对于新文章或人们希望在没有它的情况下刷新旧文章，它不应该被强制要求。这种方法对于WV来说是否过于模糊？Andrewssi2 (讨论) 2013年10月29日15:27 (UTC)[回复]

就我个人而言，如果文章模板要以这种方式更改，我宁愿不要只做一半。实际上，我认为做的部分已经经常被子部分（公园、剧院、音乐、体育、节日、活动、海滩、远足径、有组织的旅行、乘船游览、火车旅行等）所负担。我认为学习某种课程是一种足够不同的活动类型，我们可以单独保留它。仅仅因为它在技术上是做某事，并不意味着它必须放在做里面。毕竟，喝酒、泡吧、洗衣服和上网也是“活动”，但我们不需要把所有东西都放在做里面。Texugo (讨论) 2013年10月29日16:18 (UTC)[回复]

火车和船只是“出行”工具，如果用作交通工具的话，唯一的例外是观光环线旅游，除了原始出发点外无法下船。“餐饮、燃料、住宿”类别更像是基础设施而非娱乐（总得“吃”和“睡”在某个地方），而“洗衣”似乎更多地是其他类别中（特别是露营地）列表中的脚注，而不是独立的自助洗衣店。“Wi-Fi”也在朝着同样的方向发展，因为它在咖啡馆、酒店/汽车旅馆和公共图书馆中普遍出现；独立的“网吧”正在消亡。我犹豫是否要使用“连接”的持续存在来证明“学习”作为一个部分（而不是子部分）是合理的，因为现在Wi-Fi似乎在大多数人迹罕至的目的地随处可见，“连接”的日子可能屈指可数了。如果说“活动”更值得成为一个部分而不是子部分（因为每个小镇至少有一个年度旅游节），那么“学习”应该降级为“做”的一个子部分或完全删除。如果“骑马”是“做”，那么“学习骑马”也应该算作“做”，因为它们几乎是相同的活动。维基导游：你可以把它放在哪里#学习和文章模板需要更改，以便将此作为新文章的部分废弃，即使对现有混乱没有立即采取任何措施。太多的学习超出了我们的范围（即：多年制文凭和学位课程），剩下的仅仅是目的地众多活动中的一种。K7L (讨论) 2013年11月24日21:38 (UTC)[回复]

帮助页面清理

我一直在努力清理爱尔兰页面的格式。我遇到的最大问题是遵循样式手册页面。我发现它们难以记住，难以浏览，而且篇幅冗长。因此，我尝试制作了自己版本的日期和时间格式页面，我认为它更易于使用。

我尝试改进的一些地方

大型粗体示例。这使得快速浏览页面更容易。您应该能够仅从示例中了解大多数格式设置方法，而无需阅读文本。
仅限正确示例。我只使用过正确的示例。如果您在页面上看到一个示例，您就知道可以使用它。这也有助于缩短页面。
简短。我已努力使页面和注释尽可能简短。它不应该在顶部需要一个“本页摘要”框。我还去掉了顶部实际上什么也没说的介绍性段落。
一致的格式。我试图使页面尽可能保持一致。例如，所有示例总是显示在左侧，而不是句子中的随机位置。这应该有助于人们快速浏览示例以找到他们正在寻找的示例。

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

46.7.249.24 2013年11月2日20:47 (UTC)[回复]

我个人不喜欢大字体。我还没有考虑其他方面——字体大小太过于霸道了。如果您愿意尝试正常大小，我会再看一眼。否则我不会认为它可以取代现有页面——尽管您可以保留它供自己和喜欢它作为替代方案的人使用。不过，感谢您尝试改进。Nurg (讨论) 2013年11月3日00:01 (UTC)[回复]

我更喜欢这个页面，因为它简洁明了，特别是其一致的格式，左侧显示示例，右侧提供进一步解释。不良示例总是令人困惑。其他人怎么看？-- torty3 (讨论) 2013年11月3日00:09 (UTC)[回复]

我认为，如果大家觉得有用，有一些备忘单会很有帮助。在Wikivoyage:Cheatsheet/Time and date formats和Wikivoyage:Cheatsheet/Listings创建这样的页面可以吗？-- torty3 (讨论) 2013年11月3日23:39 (UTC)[回复]

这对我来说听起来是个合理的想法。我唯一的两个担忧是：1) 保持这些“备忘单”的数量较少，以免增加使其与政策页面保持同步的额外工作；2) 这些“备忘单”应该是从主要政策页面或其他简洁的政策页面信息版本中提取的示例列表，而不应被用来创建替代既定政策的方案。-- Ryan • (讨论) • 2013年11月3日23:51 (UTC)[回复]

Alice 的提案

Alice 已给我发邮件，表示她目前无法在不泄露密码的情况下发布此消息（例如，网吧的键盘记录器），但要求我代为发布

“我（和一些人）已经注意到您在我们的爱尔兰文章方面所做的出色工作，您添加了许多有用的信息，将它们整理成我们特殊的列表格式，并使格式保持一致和可读——为此，特别感谢！

我也同意您的基本前提，即我们应该尝试让我们的样式手册页面更容易理解和记忆。在这方面，除非影响理解，否则我认为最好是

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公里/小时的速度在坑坑洼洼的道路上行驶”。

感谢您对样式和格式问题提出建议，并极大地改进了我们的爱尔兰语文章！爱丽丝”。

--118.93.67.66 2013年11月3日 04:08 (UTC)[回复]

关于更改Wikivoyage:Measurements的提案最好在Wikivoyage_talk:Measurements提出。Nurg (讨论) 2013年11月15日 22:04 (UTC)[回复]

Nurg，我完全同意。然而，过去也曾发生过这样的情况：在一个专门且适当的政策讨论页面达成共识后，有人突然出现并以他们未注意到之前的讨论为由撤销了更改。--118.93nzp (讨论) 2013年11月15日 22:13 (UTC)[回复]

我只想指出，我不仅是上面引文的传话筒，我对“爱丽丝的提案”也毫无异议。

我特别喜欢我们行为准则中关于“尽可能少地例外”的部分，以及它在tdf中的应用。她关于“先列出较长的时间段，然后是逐渐缩短的时间段”的提案将特别有帮助，因为我们出色的新列表编辑器经常将开放时间数字紧跟在电话号码数字之后，并且可以省去进行自定义编辑的麻烦，例如这个，其中

洛桑旅游局 (位于主火车站，以及乌希的导航广场9号，M2车站对面)， ☏ +41 21 613-7373。每日 09:00-19:00。旅游局办公室或电话上的工作人员几乎总能在最后一刻为您安排符合您价格范围的酒店。此外，他们还提供一份精美的免费城市地图和大量有用的印刷材料，包括英语、法语、德语和意大利语。

对于使用非彩色屏幕（如电子阅读器上的纸白屏幕）的读者来说，显然比我们当前的建议

洛桑旅游局 (位于主火车站，以及乌希的导航广场9号，M2车站对面)， ☏ +41 21 613-7373。每日 09:00-19:00。旅游局办公室或电话上的工作人员几乎总能在最后一刻为您安排符合您价格范围的酒店。此外，他们还提供一份精美的免费城市地图和大量有用的印刷材料，包括英语、法语、德语和意大利语。 --118.93nzp (讨论) 2013年11月15日 22:10 (UTC)[回复]

如果爱丽丝担心键盘记录器，她为什么不能直接使用IP呢？我有点不愿评估一个不愿出面讨论的提案。我认为我们应该暂停此项，直到爱丽丝可以讨论其优点，解释并（如有必要）捍卫她的提案。--Inas (讨论) 2013年11月19日 03:14 (UTC)[回复]

我正挠头想关于列表编辑器的事。列表模板基本与几年前一样，与任何新东西无关。-- torty3 (讨论) 2013年11月19日 03:34 (UTC)[回复]

引入测试功能

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

我们很高兴向您介绍测试功能，这是维基媒体基金会的一项新计划，让您可以在新功能向所有人发布之前进行试用。

将其视为一个数字实验室，社区成员可以在其中预览即将推出的软件并提供反馈以帮助改进它们。这个特殊的偏好设置页面让设计师和工程师可以在广泛的范围内试验新功能，但不会造成干扰。

测试功能现已可在MediaWiki.org进行测试。它还将于本周四（11月7日）在维基共享资源和MetaWiki发布。根据测试结果，计划于2013年11月21日在全球所有维基上发布。

以下是您本周可以测试的首批功能

媒体查看器——以大尺寸或全屏查看图像
VisualEditor 公式（适用于具有VisualEditor的维基）——在您的页面上编辑代数或方程式
排版刷新——使文本更具可读性（周四推出）

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

测试完测试功能后，请在此讨论页面上告诉开发者您的想法——或在此Bugzilla上报告任何错误。也欢迎您在11月8日星期五世界协调时18:30参加此IRC办公时间聊天。

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

祝您使用愉快，别忘了告诉开发者您的想法！Keegan (WMF) (讨论) 2013年11月5日 19:48 (UTC)[回复]

通过全球消息分发发布（页面有误？在此更正），2013年11月5日 19:48 (UTC)

我之前查看过，必须说，我喜欢媒体查看器功能。它与我们的静态地图配合得很好，因为在文章缩略图中经常太小而无法看到。一旦他们开始寻求全站测试，我建议我们举手支持。詹姆斯 A ▪ 讨论 2013年11月6日 01:06 (UTC)[回复]

Template:PrintDistricts

这个模板上个月似乎被单方面更改了（尽管我可能错过了一次讨论）。尽管我赞成削弱（或至少减少）打印在这个警告中的作用，但我还是希望将新措辞改为更简洁一些：也许是“XXX是一个大城市，有几个区域文章，其中包含特定景点、餐馆和住宿的信息。”

思考更改这个常用模板的SEO影响也可能值得——之前的措辞与其WT对应版本完全相同。--尼克 ^讨论 2013年11月5日 02:24 (UTC)[回复]

你的措辞很好，尼克，而且在WV沉没之前一直把SEO放在心上也是好事。--118.93.67.66 2013年11月5日 11:47 (UTC)[回复]

我希望你指的是“WT”：P，措辞看起来很好。詹姆斯 A ▪ 讨论 2013年11月5日 11:49 (UTC)[回复]

哎呀，我的弗洛伊德式口误暴露了我的邪恶计划。去卖掉我的IB股票…… 伊博比 2013年11月5日 04:15 (UTC)

获取打印件

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

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

大家好！

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

CirrusSearch相比当前的搜索引擎LuceneSearch具有许多优势，包括

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

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

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

此致，

--丹·加里，维基媒体基金会 (讨论) 2013年11月7日 22:21 (UTC)[回复]

我觉得这听起来很棒。我一直对我们当前的搜索功能不太满意。Texugo (讨论) 2013年11月8日 13:10 (UTC)[回复]

我想我们对模板的主要关注是{{listing}}——模板除了参数中提供的内容外不添加文本，但我们需要它的内容（替换前或替换后，无所谓……）出现在任何搜索结果中。K7L (讨论) 2013年11月11日 04:03 (UTC)[回复]

我总是乐于尝试新事物 :-) 请让我们知道何时在此处测试部署此功能，谢谢！Nicolas1981 (讨论) 2013年11月28日 07:05 (UTC)[回复]

我想丹·加里可能会有点失望，因为在他最初提出是否想成为早期采用者的问题之后，已经过去了3周多，我们仍然没有给他一个明确的答复。

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

请留下您的想法……

关于一个问题，涉及一个被提名为未来FTT的文章，自从它被提名以来一直困扰着我。

我在这里发布一个提示，因为我认为“讨价还价”可能不是一个流量很高的文章。

-- AndreCarrotflower (讨论) 2013年11月10日 01:35 (UTC)[回复]

另一个主页

只是一个快速的“提醒”，目前正在进行另一个关于网站主页未来的讨论，您可以在这里阅读。请在那里留下您的评论、想法或建议。--尼克 ^讨论 2013年11月12日 00:05 (UTC)[回复]

文章首次编辑无“感谢”按钮

大家好。我想感谢一位用户启动并在讨论文章中发表了第一篇文章，但我发现没有“感谢”按钮，所以我发布到了该用户的讨论页。这是已知问题吗？伊坎·科克 (讨论) 2013年11月15日 08:27 (UTC)[回复]

对我来说，这有效，米克，我刚刚给你发送了“感谢”你创建的一个页面。顺便说一下，请尝试这个。--萨奇布 (讨论) 2013年11月15日 13:03 (UTC)[回复]

那我不知道问题出在哪里了。伊坎·科克 (讨论) 2013年11月15日 22:12 (UTC)[回复]

User:Rschen7754/Wikivoyage的未来

虽然只完成了一半，但我认为它提供了足够的相关内容。--Rs chen 7754 2013年11月16日 23:31 (UTC)[回复]

我还没有通读全文，但作为一名最近从维基百科加入的贡献者，我觉得它很有趣。我发现自己想更多地了解这个社区，以及 Wikivoyage 未来几年的战略计划。感谢分享！Edge3 (讨论) 2013年11月17日 05:32 (UTC)[回复]

你是指维基导游的未来，还是指英语维基导游的未来？--亚历山大 (讨论) 2013年11月17日 06:13 (UTC)[回复]

我这是针对英语维基导游的。其他语言的维基导游在适应维基媒体方面做得比这个项目好得多。但我的文章中的观点可能也与它们相关。--Rs chen 7754 2013年11月17日 06:27 (UTC)[回复]

这不是真的。例如，俄罗斯维基导游从未试图“适应维基媒体”。我们没有义务这样做，而且维基百科人认为维基导游应该像维基百科一样，这纯粹是他们的观点。事实上，90%的维基百科人不知道旅游指南是什么（他们从未旅行过和/或从未使用过旅游指南）。因此，听从维基百科人的意见通常是一个非常糟糕的主意。

请不要介意，但你的文章，即使是草稿版，也已经表明，在你看来，旅游内容的开发远非这个项目的主要任务。这是一个非常根本的问题，我真诚地希望这种态度不会影响维基导游的其他语言版本。--亚历山大 (讨论) 2013年11月17日 11:15 (UTC)[回复]

我什么时候说过我想让维基导游看起来像维基百科了？你能否支持你的其他说法？最后，声明“因此，听从维基百科人的意见通常是一个非常糟糕的主意”只是一种刻板印象。--Rs chen 7754 2013年11月17日 11:22 (UTC)[回复]

嗯，我就是这么理解你的文字的。你链接到维基百科的共识政策，并且你反复提到维基媒体的政策/实践，这些政策/实践无论如何都源自英语维基百科。而且，还有一个非常奇怪的主张/指控，说 Wikitravel 正在对抗维基媒体（我不知道有人说过或做过这件事，除了IB，但他们在分家之前对WT没有做出任何认真的贡献）。

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

那我不认为你对维基媒体了解很多。英文维基百科往往是其中一个异类，因为许多其他维基媒体网站都特意选择了不同的发展方向。我们又把维基百科人当作二等公民对待，又刻板印象化了。“这就是我们将遵循的方向”这句话极其傲慢。--Rs chen 7754 2013年11月17日 19:32 (UTC)[回复]

当我说“我们”时，我指的是俄罗斯维基导游，因为我们在这方面有非常坚实的共识，并且对俄罗斯维基百科也有非常相似的看法，后者，嗯，甚至比我熟悉的任何其他维基媒体项目都更独特。如果你认为我的话傲慢或令人讨厌，那是你的选择，但我希望这里大多数人明白，大多数维基百科人不是经验丰富的旅行者。这并不意味着他们是坏人或“二等公民”，如你所说。这仅仅意味着维基导游应该从其他地方吸引编辑者。--亚历山大 (讨论) 2013年11月17日 19:55 (UTC)[回复]

页面横幅和动态地图只是表面文章；内容仍然相同，特别是对于像谷歌这样的文本搜索引擎。我的观点是，我最近看到了太多针对新来者的攻击，甚至包括管理员……而且通常都是维基百科人。我们在这里创建世界上最好的旅行指南，我们需要所有能找到的人来做这件事。地理、历史、夜生活专家、交通专家、摄影师、校对员、模板编码员、旅行专家、反破坏者等等，在这里都有其作用。我们不能挑剔谁能进来，谁不能进来。--Rs chen 7754 2013年11月17日 20:02 (UTC)[回复]

这说明了我的观点。如果你曾尝试使用维基导游文章，你就会明白，一篇带有坐标和最新地图的文章比一篇带有简单POI列表的旧WT风格文章要好上许多倍。这不是为了谷歌，而是为了实际的读者和旅行者。谷歌排名是完全不同的问题，但涌入的校对员和夜生活专家也无济于事。

另一个问题是，你不能吸引所有人，你必须做出选择。如果你最终只是一群“校对员”，这并不能使旅游维基变得更好。--亚历山大 (讨论) 2013年11月17日 20:18 (UTC)[回复]

我确实同意你关于尽可能多的人参与的观点，Rschen7754——我认为这对于我们的长期生存非常重要。我希望你不要介意（咳咳）这个！我也大体上同意你的其他观点——这篇文章为我们正在和将要面临的问题提供了一个很好的起点。我希望当我们在1月份迎来第一个WMF生日时，我们可以进行一次全面的“维基状态”审查。--尼克 ^讨论 2013年11月17日 20:34 (UTC)[回复]

禁用“Ref”标签？

我们网站不使用参考文献标签，而来自维基百科等需要参考文献的网站的新用户，理所当然地会使用维基语言功能插入它们，造成混乱，并在页面底部显示醒目的红色消息：“引用错误：存在标签，但未找到标签。”是否有任何重要原因不能禁用此网站创建参考文献标签的功能？如果这个问题以前被问过并回答过，我深感抱歉；我模糊地记得以前有过这个讨论，但随着越来越多的维基百科人来到这里，这将成为一个越来越严重的问题，因此找到一种更简单的处理方法将是件好事。伊坎·科克 (讨论) 2013年11月15日 22:14 (UTC)[回复]

我想这需要技术人员来完成。--Rs chen 7754 2013年11月15日 22:19 (UTC)[回复]

如何提议？伊坎·科克 (讨论) 2013年11月15日 22:22 (UTC)[回复]

我们首先需要达成共识，然后我们会去bugzilla。--Rs chen 7754 2013年11月15日 22:38 (UTC)[回复]

达成共识应该不难，因为我们从未使用过它们。我曾多次尝试从编辑窗口上方的编辑栏中移除参考文献（和画廊）按钮，但一直没能弄明白。如果能得到帮助，我将不胜感激。Texugo (讨论) 2013年11月15日 23:04 (UTC)[回复]

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

那不是共识，讨论才进行了4个小时。--Rs chen 7754 2013年11月16日 02:14 (UTC)[回复]

明确指出我们需要新的共识，不是关于是否使用参考文献——这已经明确建立并且没有人建议重新讨论——而是具体地关于技术上禁用它们，以便它们不再被识别并且不会产生鲜红色的错误消息，这可能有所帮助。Texugo (讨论) 2013年11月16日 02:35 (UTC)[回复]

哦，拜托，Rschen。共识是存在的；我们只是需要证据来证明它。尽管Texugo关于我们需要共识的具体内容可能是对的。LtPowers (讨论) 2013年11月16日 02:36 (UTC)[回复]

你怎么知道社区存在共识——你是在代表社区发言吗？你怎么知道所有其他活跃用户都会同意这一点？你不知道，除非你给每个人一个表达意见的机会。--Rs chen 7754 2013年11月16日 02:43 (UTC)[回复]

过去X年来的讨论已经非常清楚地表明，维基导游没有意愿也没有共识添加参考文献。我不需要很多人参与进来就知道他们会怎么回应。LtPowers (讨论) 2013年11月17日 01:10 (UTC)[回复]

支持这里是为了建立我们可以参考的共识。我继续支持禁止参考文献并支持禁用创建或识别它们的功能。ChubbyWimbus (讨论) 2013年11月16日 07:03 (UTC)[回复]
既然我们不用，那就删除它。Nurg (讨论) 2013年11月16日 09:53 (UTC)[回复]
郑重声明，我也支持这一点。--Rs chen 7754 2013年11月16日 09:56 (UTC)[回复]

我们什么时候开始在讨论中使用项目符号了？难道这一切争论不都源于我们不是维基百科这个事实吗？总之，伊坎的想法很棒，我完全同意。尼克1372 (讨论) 2013年11月16日 16:13 (UTC)[回复]

虽然我们通常不使用参考文献，但有时它们可能有用。例如这篇文章旅行者腹泻。因此，我不同意完全取消它们。旅行医生詹姆斯 (讨论 · 贡献 · 电子邮件) 2013年11月17日 10:27 (UTC)[回复]
- ……这就是我们进行这些讨论以确保达成共识的原因。--Rs chen 7754 2013年11月17日 10:38 (UTC)[回复]
詹姆斯，我有点困惑。我没有在旅行者腹泻中看到任何参考文献标签。我是不是错过了什么？尼克1372 (讨论) 2013年11月17日 14:33 (UTC)[回复]

是啊，我也是。那个页面上没有参考文献，你是不是在想别的东西？我相当确信，没有任何页面我们曾决定可以使用<ref>。--Texugo (讨论) 2013年11月17日 17:54 (UTC)[回复]

目前没有，但我认为可以/应该有。Travel Doc James (讨论 · 贡献 · 电邮) 2013年11月26日 09:40 (UTC)[回复]

为了什么目的？那个页面有什么特殊之处，需要引用来源？Texugo (讨论) 2013年11月26日 10:17 (UTC)[回复]

我也不明白为什么那篇文章需要引用来源。一份可靠的旅游医学书籍清单可能可以，但我认为文章中的陈述不需要来源。（另外，为项目符号道歉。我意识到我们这里不使用它们，也不使用“支持投票”进行共识讨论。我只是觉得，与其继续讨论我们是否需要支持记录，不如通过获得支持/共识来跳过这个讨论，这样我们就可以结束讨论，因为我也认为这并没有什么争议。显然，我可能是错的，所以像詹姆斯医生这样的担忧必须得到解决）ChubbyWimbus (讨论) 2013年11月26日 14:22 (UTC)[回复]

使用其他语言页面上的信息

我们能做些什么来帮助编辑者和旅行者使用其他语言的页面吗？我可以通过用Chrome浏览器打开页面来获得翻译（但我通常使用其他浏览器），不过，如果能直接链接到翻译后的页面会更好。我最近发现苏格兰的巴洛赫在德语页面比英语页面内容更丰富。了解其他语言页面的大小或评级也会很有用——如果一个目的地在其他语言中有星级指南，那么它可能值得一看。如果能看到一张地图，显示所有语言的文章，那就更棒了——也许可以在Meta上按国家显示。有没有从其他语言导入内容的指南？我意识到这些大多数可能都无法实现，它们只是一些激发思考的想法。AlasdairW (讨论) 2013年11月19日 23:27 (UTC)[回复]

如果你问的是我所理解的问题——链接到其他语言的页面——我们已经有了。它们位于侧边栏的“语言”下方，以及移动页面底部那个大大的蓝色按钮（我们从维基数据获取这些信息）。此外，如果你访问某个地点的维基数据页面，你会看到所有不同语言的维基导游页面以及所有不同语言的维基百科相关页面列表。至于添加星级文章的指示器，那是个很棒的主意，而且完全可行。维基百科对特色文章和优良文章都这样做，我们为什么不能？我不知道具体细节，但你可以在某个地方找到。一个显示所有语言文章的地图是不现实的。我相信你可以做到，但这会是太多工作，回报太少。我们没有“导入”其他语言信息的指南，因为这根本不是我们做的事情。维基媒体全站的惯例是人工翻译，而不是机器人。任何自动翻译都不可靠。如果你懂多种语言，并且在德语版本上看到一个有趣的片段（你知道是真的），并且会是英语版本的一个很好的补充，那么请务必并添加它。希望这能澄清问题。Nick1372 (讨论) 2013年11月20日 01:35 (UTC)[回复]

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

我想，信任自动翻译页面是否可靠是你的决定。我不会，但那是我的观点。我认为从其他维基导游翻译时不需要任何归属，非英语维基百科的归属方式应该与英语维基百科相同。我相信它们都使用CC-by-SA版权，所以应该没有任何问题。Nick1372 (讨论) 2013年11月21日 00:56 (UTC)[回复]

没问题，是的，但维基导游的政策是应该注明出处。所以，无论引用的是哪个版本的维基百科，至少在编辑摘要中提及你借用文本的来源。Ikan Kekek (讨论) 2013年11月21日 01:10 (UTC)[回复]

确实如此……CC-BY-SA 的核心是“by”……该许可要求注明原作者。K7L (讨论) 2013年11月21日 19:16 (UTC)[回复]

征求关于商标政策草案的意见

大家好，

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

当前的商标政策于2009年推出，旨在保护维基媒体商标。我们现在正在更新此政策，以更好地平衡对商标的许可使用与保留商标供社区使用的法律要求。新的商标政策草案已准备好供您在此审阅，我们鼓励您在此讨论。

如果您能将此消息翻译成您的语言，以便您社区的更多成员可以为对话做出贡献，我们将不胜感激。

谢谢，
Yana & Geoff

“Wikivoyage”商标的状态如何？它将注册为维基导游基金会还是维基媒体基金会的商标？我看到“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 talk:Administrators。--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可能只显示“打印版本”中出现的内容（因此任何class="noprint"的内容都会被隐藏），不确定。Wikivoyage talk:Listings#We have lost listings numbers in print version可能相关？K7L (讨论) 2013年11月27日 04:48 (UTC)[回复]

是的，也不是关于noprint。列表编号在PDF版本中显示得非常奇怪，并且不能包含CSS。Mapframe和列表编号确实显示在网络可打印版本中。用于PDF导出的扩展mw:Collection已经相当过时或不适合自定义，据User:AdamBMorgan说，像维基文库这样的其他项目也在寻找解决方案。WMF显然正在考虑替换mw:PDF rendering管道，以处理那些花哨的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。它们的标题非常相似，但似乎是关于不同主题的。是这样吗？还是应该合并？如果它们是独立的，那么可能应该有一些链接可以在它们之间导航。--WOSlinker (讨论) 2013年11月23日 21:47 (UTC)[回复]

链接到章节标题

我刚在Mediawiki上发现了一个有趣的小工具，它让我想起了User:Nicolas1981几个月前提到的一件事。请在偏好设置 > 小工具 > HeadAnchor 试用一下。我认为我们也需要为小工具和脚本设定一些指南，有些小工具（如可选的分享框功能到Facebook和Twitter）确实可以改进网站，当然也要有合理的限制。--torty3 (讨论) 2013年11月10日 00:24 (UTC)[回复]

谢谢你的提示！HeadAnchor 效果很好，我唯一的抱怨是图片看起来不如Github使用的可爱，但一旦这个问题解决了，我认为它应该默认开启。为了提高我们的谷歌排名，让读者更容易分享特定章节或子章节至关重要。我想每个人都知道如何分享URL... 有没有科学研究表明FB/Twitter/等分享按钮能提高分享率多少？Nicolas1981 (讨论) 2013年11月27日 10:02 (UTC)[回复]

维基导游的未来反映在其列表内容中

~~英文维基导游的未来看起来黯淡：无休止的共识讨论，无休止的W.Frank化身……~~但我这里有一个非常实际的问题，我最近在峰会上提出了。Fussi提出了一个想法，将所有列表内容移动到维基数据，以便不同语言版本可以共享这些信息。虽然在近期内不可行，但这个想法提出了另一个问题：如何找到不同语言中的相同列表内容？如何将我们的列表内容与维基百科的文章和维基共享资源的分类连接起来？在我看来，这些问题是“与维基媒体整合”的核心，这在上面的主题中得到了广泛讨论。任何想法和意见都非常感谢，但请先阅读我在Meta上的帖子。--Alexander (讨论) 2013年11月17日 17:37 (UTC)[回复]

很高兴听到与维基媒体其他部分的持续整合，但我们真的需要重新提起“英文维基导游的未来一片黯淡”的老调吗？最近我们对另一位用户对维基导游未来做出悲观预言非常不满，而我越来越难以（从你过去的评论到这次的评论）区分他的做法和你的做法。亚历山大，你完全有权选择不活跃，而不是投入进来帮助我们解决伴随我们迁移到WMF而出现的人格冲突和文化冲突。而且，如果你将来选择再次活跃在en:，那也是你的权利——我个人，而且我相信我不是唯一一个，会张开双臂欢迎你回来。我确信我们很乐意听到你对你提出的问题有任何建设性的解决方案。但是，如果没有这样的东西，在一旁挑剔是解决不了任何问题的，而且这确实是很差劲的表现。

我说这些话没有任何偏见，既不针对你过去在en:所做的出色贡献，也不针对我对你，亚历山大，仍然抱有的尊重，我希望这些话能以其 intended 的建设性精神被接受。

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

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

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

另外，我想再次重申我对你和你的工作，亚历山大，抱有极大的敬意。我希望你在我对你的评论中没有读到任何相反的意思。

我知道你最初的帖子中想要解决的主要问题是将列表迁移到维基数据，以便所有语言版本都能访问。接下来，在这个帖子中，我将把我的评论限制在这个主题上。我对维基数据的内部运作知之甚少，但总的来说，我无法想象我会反对任何有助于将en:voy整合到WMF社区的进程。

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

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

- - - 不同语言对国家的粒度覆盖程度不同。因此，一个小镇的城堡可能在一个语言版本的小镇文章中列出，而在另一个语言版本的大城市（15英里外）中列出。我怀疑任何大城市在多种语言中的划分方式都是相同的。
    - 有些景点只对说特定语言的人有兴趣。关于文学的博物馆，如果你不精通该语言且不熟悉相关作品，其兴趣就会有限。
    - 只有基本信息可以自动传输，任何实际的评论都必须翻译。
    - 追踪因维基数据更改而进行的更改的困难。列表被更改时需要显示在监视列表中（而不是所有数据属性更改的列表）。
    - 我们必须以一种不会给偶尔编辑者带来复杂障碍的方式来做这件事。
    - 要使数据库中的每个列表只出现一次，这将是一项艰巨的工作——要识别“爱丁堡城堡”、“Château d'Édimbourg”、“el Castillo”和“Castello di Edimburgo”是同一个地方。

一个可能有用的工具是，当编辑文章时，它会向编辑者提供添加列表的建议。AlasdairW (讨论) 2013年11月18日 00:19 (UTC)[回复]

正如我在Rfc帖子中提到的，除了上面提到的问题，我还看到了一些问题。

澄清 AlasdairW 上面的第二点，我认为只有电话/网站/电子邮件字段可以在不翻译的情况下通用使用。几乎所有其他字段都经常包含需要翻译的散文或其他元素。
如果我们让它们自动出现，我们就会失去在本地修剪/管理列表的能力。如果我们不这样做，我们如何知道什么时候可以添加内容？

Texugo (讨论) 2013年11月18日 02:21 (UTC)[回复]

从维基数据的角度来说，这绝对值得探索，但我认为软件还没完全准备好。--Rs chen 7754 2013年11月18日 02:38 (UTC)[回复]

我既喜欢这个想法，也和Texugo有同样的顾虑，但我们不应该在meta:Wikivoyage/Summit#ru讨论这个问题吗，这样来自其他语言网站的更多维基导游用户也能看到这些观点？Ikan Kekek (讨论) 2013年11月18日 02:57 (UTC)[回复]

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

伊坎，我一周前在Meta上写了同样的内容。唯一的回复是torty3。很明显，大多数人没有关注Meta页面和/或对这个话题不感兴趣。--Alexander (讨论) 2013年11月18日 05:29 (UTC)[回复]

我实际上问的是一个不同的问题。我们是否应该做些什么来连接不同语言的列表内容？假设我们可以将列表内容传输到维基数据，或者假设我们想通过将维基百科链接添加到列表内容中，并将维基导游链接添加到维基百科的相关页面来改进与维基百科的交叉链接。这必须手动完成，因为每个列表内容都是一个完全独立的实体。做一些能简化列表内容自动处理的事情肯定是有意义的。问题是要做什么。--Alexander (讨论) 2013年11月18日 05:10 (UTC)[回复]

我不知道谁会手动更新所有这些列表，考虑到我们有成千上万的目的地，每个目的地都有几十个{{列表}}标签/模板。我们已经有大量的列表没有正确转换为模板（例如目前珀斯（安大略）的混乱），多年来都没有检查场地是否仍然存在（点击网页链接——许多是404、被网络抢注、垃圾邮件或指向其他业务），或者存在其他问题，例如格式不正确或过时的电话号码。在大多数情况下，并没有采取任何措施来删除已关闭场地的列表。机器人曾被尝试用来将格式不正确的列表转换为模板，但这效果不佳。除非某种脚本能够最初连接列表（例如通过发现重复的电话号码并希望它们是同一个场地），否则将无法完成。列表太多，无法全部手动完成。K7L (讨论) 2013年11月18日 06:13 (UTC)[回复]

嗯，我们肯定应该做点什么，或者干脆看着混乱蔓延。我想你的回复给了我几个想法，谢谢！其他想法和意见仍然欢迎！ --Alexander (talk) 2013年11月18日 17:53 (UTC)[回复]

嗯，这些不能在不把整篇文章移到维基数据的情况下连接起来吗？我记得维基百科有一个模板或小部件，他们把它放在文章中代替跨维基链接，提供对跨维基链接的访问。我们不能也这样做吗？ Purple backpack89 2013年11月18日 18:32 (UTC)[回复]

维基导游也在这样做。从维基数据读取信息没有问题。问题是如何将其传输到那里。 --Alexander (talk) 2013年11月18日 19:07 (UTC)[回复]

问题是如何将其传输到那里，以及一旦在那里如何维护。后者似乎是我们的薄弱环节（已关闭的商家仍在指南中），一旦数据分散在多个维基上，这将变得异常复杂。一个新用户如何编辑一个部分在这里，部分在维基数据上，并且完全过时的列表？ K7L (talk) 2013年11月18日 19:18 (UTC)[回复]

如果列表编辑器可以从维基数据读取条目，那么编辑将与现有界面非常相似。但这又将对话引向了另一个话题。鉴于社区兴趣不大，我认为将列表传输到维基数据根本不可能。因此，我只是在思考我们可以做些什么来更好地组织列表并将其链接到其他维基媒体项目。这可能产生不同的影响，例如维基数据、维基百科链接（如果引入的话），或者一个纯粹的技术工具，通过读取相关类别来帮助在维基共享资源上查找新图像。 --Alexander (talk) 2013年11月18日 20:02 (UTC)[回复]

我们从简单的纯数据开始怎么样？例如，机场的航班和目的地。我们大多数机场都有直飞航班和航空公司信息。维基百科上也有很多相同的信息。如果这些信息集中保存，我们可以根据需要使用。我们可以从那里继续吗？ --Inas (talk) 2013年11月18日 21:38 (UTC)[回复]

嗯，这可能是一个选择，尽管它不太符合我对旅行指南的理解，旅行指南应该包含最新的时间表，或者只包含对旅行选项的简要描述。航空公司和目的地的列表是我从未理解的东西。此外，应该与英文维基百科（以及其他维基百科）达成协议，因为要启动这个。我将完全支持这项活动，但我当然不知道如何开始。 --Alexander (talk) 2013年11月18日 22:55 (UTC)[回复]

维基百科已经试图维护每个机场的目的地和航班列表，所以我们不是在创造不存在的东西。当然，我们并非每篇文章都会列出这些。如果一篇包含数百条信息的文章让人感到不知所措，那么我们就不需要它，简洁的散文会更好。然而，了解飞往麦夸里港的航班和航空公司是该市旅行指南的必要条件。 --Inas (talk) 2013年11月18日 23:30 (UTC)[回复]

我深信维基导游将从维基数据上的列表数据中受益匪浅。针对一些担忧，我的回答是：

数据迁移并非大挑战，我们已经积累了迁移坐标和横幅的经验，列表数据只是数据类型更多而已。
如果我们修改列表编辑器，修改数据将和现在一样简单。
当粒度不同时（例如，城堡在fr/大城市和en/小城市中存在），城堡数据会重复……这没什么大不了的，在维基数据之前就已经重复了，我们可以接受。
“有些景点只对说特定语言的人感兴趣”：我怀疑在整个维基导游中能找到超过10个这样的列表……请告诉我所有这样的列表，以便更好地了解。
“评论必须翻译”：是的。维基数据受益最大的是网址/电话/价格等数据。
“跟踪因维基数据更改而产生的更改的难度”：我们与维基百科处于相同的情况，所以我相信维基数据会解决这个问题。
“[有些列表]多年未检查”：维基数据将通过语言之间的协作来帮助解决这个问题。此外，维基数据可以轻松创建机器人来检测404错误等。
“这些不能在不把整篇文章移到维基数据的情况下连接起来吗？”是的，但作为一名跨维基老兵，我知道维基数据比临时跨维基连接更容易管理。

Nicolas1981 (talk) 2013年12月2日 03:07 (UTC)[回复]

虽然我总体上支持，但有没有可能看到一个实际操作的例子？谢谢。Andrewssi2 (talk) 2013年12月2日 03:19 (UTC)[回复]

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

由于只有电话、网址和电子邮件字段不需要翻译，那么谁来完成所有其他字段的填写工作，并确保这些条目连接到其他语言版本中的正确内容？
它将如何显示在我们的文章中？如果不将任何修剪/整理工作变成复杂的跨语言协作，就无法自动显示。如果不能自动显示，我们如何找到可能添加到文章中的内容？因此，列表项也不能与其父文章一一对应，否则将强制所有参与的语言版本就区域/区划划分达成一致才能使其正常工作。
你的第4点似乎假设会自动显示内容。除了上面给出的文学博物馆的例子，我还在其他地方给出的例子是：日本旅游指南往往会侧重于能说日语的酒店、专门迎合日本游客的度假村、日本餐馆等。其他版本可能会更侧重于清真或犹太洁食餐馆。其他语言可能还有其他偏向。英文版本上的列表选择不一定需要所有这些，并且需要保持其单独修剪/整理的能力。
我认为查看最近更改的解决方案必须在我们实际实施这些之前提出。否则我们现在只是蒙蔽自己，等待解决方案的到来。

Texugo (talk) 2013年12月2日 10:47 (UTC)[回复]

不，我想你没有理解。列表的选择根本不是问题。作为维基导游编辑者，你决定包含什么。理想情况下，一个人会写 {{listing|wdid=Q123456789|description=一个荒无人烟的好地方}}，并从维基数据Q123456789卡中获取所有必要信息（名称、地址、开放时间）。列表编辑器可以与我们现在拥有的非常相似，但它会直接将信息传输到维基数据，以便所有语言版本都能使用最新信息。这将是一个理想的情况，但由于多重挑战，我们很可能永远无法实现

维基数据界面尚未准备就绪
大多数列表（酒店、餐馆）可能不符合维基数据显著性标准
翻译问题需要大量思考。维基数据上地址、电话号码和价格的格式应该非常严格，以便每个语言版本都能自动翻译并转换为自定义格式。
列表应在不同语言版本之间以及与其他维基媒体项目之间同步。帝国大厦在维基数据中有自己的条目，但无法确保维基导游中的列表与维基百科中的文章/维基数据中的项目是同一事物。
巡查最近更改变得相当复杂；很可能需要新的技术解决方案

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

一个临时解决方案可以是以下内容。添加一个可选参数（我们称之为“wdid”），它将包含维基数据编号，并提供维基导游列表和现有数据项之间的显式连接。该参数将促进与维基百科和维基共享资源的链接，这将对机器人以及真实用户非常有帮助。

更普遍地说，有一个密切相关的提案，关于将文化遗产古迹信息转移到维基数据。它的时间表也未确定，但至少这将是改进技术方面和获取必要经验的自然第一步。 --Alexander (talk) 2013年12月2日 11:45 (UTC)[回复]

所以这主要用于“看”和“做”列表。我认为这在技术上解决后会很棒。有没有办法设置，以便在en.Wikivoyage中添加“看”和“做”列表时，列表会自动放入维基数据？或者，如果启动一个已经存在的列表，维基数据信息会默认自动填充？在我看来，这些都是软件人员应该着手解决的问题。Ikan Kekek (talk) 2013年12月2日 11:53 (UTC)[回复]

关于自动翻译，我不认为那些字段足够严格以允许自动翻译。电话号码、电子邮件和网址字段可能根本不需要翻译，但我认为不可能自动翻译地址字段到/从其他脚本，而且价格/小时字段的格式变化很大，经常带有散文片段来澄清所讨论的内容。没有严格的格式可以处理随机限定词短语，例如“两人主菜约40美元，半份按列出价格的70%计算”或“商店周一至周五上午10点至晚上9点，周六至周日上午2点至晚上8点；冬季（12月15日至3月1日）提前一小时关门”。即使我们只对“看”和“做”列表使用维基数据项目，我相信这些字段中也有许多这样的限定词短语。Texugo (talk) 2013年12月2日 12:12 (UTC)[回复]

如果这不是我们今天（即使是测试版）可以尝试的东西，那么我真的不清楚这里提出的要求是什么？ Andrewssi2 (talk) 2013年12月2日 12:51 (UTC)[回复]

我没有提出任何具体的建议。这个话题的目标是“试探一下”，看看人们是否感兴趣，以及他们是否有任何好的想法来推进。我没有看到太多超出重述语言特定信息和巡查最近更改的问题的活动，所以我们不会在明天将信息转移到维基数据，但这次对话的一些部分仍然有用。感谢大家！ --Alexander (talk) 2013年12月2日 13:48 (UTC)[回复]

Ikan，这是一个根本性的误解。信息应该一次性传输到维基数据，然后从那里检索。否则，你只是在维基数据上保留了一份列表副本，这并没有什么实际用处。我还试图明确指出，目前我们没有工具可以从维基数据检索这类信息。这些工具会（慢慢地）出现，但除非维基导游在整理事物、识别不同语言版本中的相同列表以及识别已经拥有其维基数据项目（维基百科文章）的列表方面付出巨大努力，否则它们不会有任何特殊用途。这最后一点是每个人都可以立即开始做的事情，但我不知道我是否能够正确解释这一点。 --Alexander (talk) 2013年12月2日 13:48 (UTC)[回复]

听起来这并不需要改变任何行为。查阅维基百科以获取景点基本信息并非新鲜事，但通常查阅景点自己的网页更可靠。我是不是又错过了什么？ Ikan Kekek (talk) 2013年12月2日 18:48 (UTC)[回复]

嗯，是的……这不是获取新信息的问题。而是关于跨项目链接。假设英文维基导游有一个莫斯科克里姆林宫的条目，俄文维基导游也有，但两者之间没有一一对应。如果你将维基数据编号添加到两种语言中，你立刻就知道它们是同一个列表。现在，维基百科不喜欢存储实用信息，例如开放时间和门票价格，因此为莫斯科克里姆林宫的维基百科文章提供维基导游的链接是很自然的。你可以手动完成所有这些，或者你可以让机器人帮你完成，但这个机器人必须知道哪个维基百科文章与莫斯科克里姆林宫的维基导游列表相关联。 --Alexander (talk) 2013年12月2日 19:32 (UTC)[回复]

我对在同一篇文章的英文和德文版本（以及其他语言）之间共享列表的维基数据条目感兴趣。我注意到克里姆林宫链接上有一个空白的WV部分。这是否意味着您已经开始使用集成工具了？ Andrewssi2 (talk) 2013年12月4日 13:42 (UTC)[回复]

每个维基数据项目都有一个维基导游文章的空白槽。这什么都不代表。

正如我所说，我们（俄语-乌克兰语团队）不打算自己启动任何项目，而是将精力集中在文化遗产方面，这更容易一些，组织得更好，并且更符合显著性标准。但即使是文化遗产也是一个长期项目。 --Alexander (talk) 2013年12月4日 13:51 (UTC)[回复]

.voyage

显然，新年会有顶级域名 .voyage 开放；这对我们有用吗？ K7L (talk) 2013年11月26日 19:56 (UTC)[回复]

嗯…有意思！我认为这应该尽快引起维基媒体基金会相关部门的注意，尽管我不知道具体是哪个部门。Texugo (talk) 2013年11月26日 19:59 (UTC)[回复]

wikivoyage.com 和 wikivoyage.net 已经重定向到 wikivoyage.org，所以添加“wikivoyage.voyage”也是常识。 -- AndreCarrotflower (talk) 2013年11月27日 17:08 (UTC)[回复]

还有wiki.voyage！ Jjtkk (talk) 2013年11月27日 17:32 (UTC)[回复]

感谢您的提示！Wiki.voyage确实是一个非常吸引人的URL :-) Nicolas1981 (talk) 2013年11月28日 08:42 (UTC)[回复]

稍微询问了一下，得到这个答案： --Rs chen 7754 2013年11月28日 10:00 (UTC)[回复]

@K7L: @Texugo: --Rs chen 7754 2013年11月30日 18:56 (UTC)[回复]

啊，是的，我早些时候看到了这个，但忘了回复。你有没有给YWelinder发邮件？ Texugo (talk) 2013年11月30日 19:45 (UTC)[回复]

我没有，因为我以为应该由更熟悉这类事情的人来做，但如果没人想做，我可以做…… --Rs chen 7754 2013年11月30日 19:52 (UTC)[回复]

不确定这里有没有人比我更熟悉这种事情。你介意吗？ Texugo (talk) 2013年11月30日 20:00 (UTC)[回复]

现在完成了。 --Rs chen 7754 2013年11月30日 20:03 (UTC)[回复]

.travel TLD 域名已经存在多年了。我们有没有，需要或想要那里的任何域名？我认为 guide.travel 会很有价值。Pashley (talk) 2013年11月30日 20:07 (UTC)[回复]

我很久以前就预注册了“wiki.voyage”，一旦该顶级域名开放注册，我就会把它交给维基媒体基金会，所以不用担心域名抢注问题。Pashley，“guide.travel”不可用。--Saqib (talk) 2013年11月30日 20:41 (UTC)[回复]

wiki.travel 可能不太好…… --Rs chen 7754 2013年11月30日 21:04 (UTC)[回复]

.travel 域名有一些非常随意的限制——基本上，必须证明自己是许可旅行社或二十个其他特定旅行领域之一（航空公司/铁路、酒店/民宿、租车公司……）的供应商才能在那里注册，价格是.com/.net/.org或当地国家代码的十倍——因此其采用范围相当有限。到2007年，特拉利联盟（Tralliance，经营.travel）被猜测有破产风险；2008年该公司私有化时，只有30000个名称注册。该域名仍然存在，但大多数供应商更倾向于保留其现有的.com注册，因为这些是已建立且受人尊重的地址。如果wiki.travel.com已经完成而wiki.travel被跳过，也许是有原因的？ :) K7L (talk) 2013年11月30日 22:29 (UTC)[回复]

新的知识共享许可协议

4.0版发布了。我认为这在短期内不会影响这里任何事情。我没有看到明显的修改需求，而且在维基媒体基金会法律部门审查之前我们也不能修改。我们还需要与其他维基媒体项目进行一些同步，而且……但这似乎值得指出。Pashley (talk) 2013年11月29日 01:45 (UTC)[回复]

感谢您的信息！快速阅读了这些更改后，我认为虽然切换会更好，但也不是优先事项。我们是不是应该等待维基媒体基金会采取主动？如果他们同时切换所有项目，成本可能会更低。Nicolas1981 (talk) 2013年11月29日 02:13 (UTC)[回复]

我不知道我们是否可以在没有上传者许可的情况下随意更改内容。很多媒体文件都在维基共享资源上，所以我会先等等看他们的反应。 --Rs chen 7754 2013年11月29日 02:24 (UTC)[回复]

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

Tipper

各位,

你对一个能让你轻松将列表添加到 Wikivoyage 的 Android 应用有多感兴趣？

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

可能会有趣的特点

如果需要，可通过 GPS 获取坐标的按钮
显示附近文章列表，用户选择相关文章
拍照（希望可以使用维基共享资源 Android 应用的意图）
如果没有网络连接，则存储数据并在有连接时发送

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

有没有比“Tipper”更好的名字？（指：提供地点提示的人） Nicolas1981 (talk) 2013年12月2日 07:21 (UTC)[回复]

当然。维基媒体网站现在支持 mw:OAuth，所以这可能可以解决IP地址问题（尽管它最近才部署，所以还没人使用）。我猜你会开发它？ --Rs chen 7754 2013年12月2日 07:50 (UTC)[回复]

我上一个与维基导游相关的 Android 应用（Wikivoyage 离线版）相当失败（只有 2000 次安装），所以我更喜欢先分享想法并获取一些反馈。像往常一样，它将是开源的，所以欢迎大家的帮助（顺便说一下，创建这样一个应用将是学习 Android 开发的好方法，有人感兴趣吗？）。感谢 OAuth 提示！我认为我们不应该要求用户拥有维基媒体账户，但未签名用户默认同意公开其 IP 地址。 Nicolas1981 (talk) 2013年12月2日 12:00 (UTC)[回复]

仅编辑导言部分

在我的维基百科偏好设置中，小工具 - 外观下，有一个“为页面导言部分添加[编辑]链接”。这在我的维基导游偏好设置中没有。除了点击其他部分的“编辑”，然后在生成的URL中将末尾的&section=n替换为&section=0，再重新加载页面之外，有没有更简单的方法来编辑导言部分？我们能为维基导游添加那个小工具吗？ Nurg (talk) 2013年12月2日 08:48 (UTC)[回复]

我们可以得到它。@PiRSquared17: 如果你在，文件名又是什么？我总是忘记 :( --Rs chen 7754 2013年12月2日 08:53 (UTC)[回复]

实际上，我已经处理好了。 --Rs chen 7754 2013年12月2日 10:03 (UTC)[回复]

谢谢。如果页面有横幅，它似乎不起作用。或者如果起作用，如何操作？如果不起作用，能否使其起作用？这是否需要更改横幅的实现，也许？ Nurg (talk) 2013年12月2日 20:16 (UTC)[回复]

我猜横幅完全遮住了它。我们可以在横幅中添加一个链接，但那样就会对所有人可见…… --Rs chen 7754 2013年12月3日 06:15 (UTC)[回复]

w:en:User:Equazcion/OneClickArchiver

如果有兴趣的话，鉴于我们没有归档机器人，这里有一个让归档更简单的脚本。我进行了这些编辑，现在我只需点击一下就能归档我讨论页上的部分。

问题是，以这种方式存档的每个页面都必须添加少量代码。它也不会处理将酒馆内容自动转移到其他页面的功能（尽管理论上有人可以编写该功能）。--Rs chen 7754 2013年12月2日 (世界标准时间) 09:52[回复]

清理列表的小型远征队

我正在发起一项小型远征活动，目标是修复损坏的兴趣点列表。

有没有人知道类似的努力，或者任何现有的工具，以便工作不重复？

以下是我目前发现的问题类型，你还知道其他问题吗？

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

微妙的情况

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

灵活性固然好，但对于混搭/协作（例如OpenStreetMap图层）来说，如果机器仍能理解数据的基本部分，那就更好了。

欢迎提出您的意见/想法！ Nicolas1981 (讨论) 2013年12月3日 (世界标准时间) 06:29[回复]

两轮Wikivoyage:脚本提名#Wrh2Bot应该已经大部分删除了无法识别的参数，尽管最好有一个维护机器人来清理任何悄悄溜回来的参数。你计划这是一个手动远征还是自动化远征，如果是后者，你打算编写一个机器人还是寻找其他人来做？ -- Ryan • (讨论) • 2013年12月3日 (世界标准时间) 06:47[回复]

我当时考虑的是一次人工考察，但如果错误数量过高，可以重新考虑。我不知道你的机器人清理了不必要的属性，太棒了！顺便说一句，我的脚本正在User:Nicolas1981/Syntax_checks#Invalid_URLs中吐出无效属性。Nicolas1981 (讨论) 2013年12月3日 (世界标准时间) 08:41[回复]

这是我目前的脚本：https://github.com/nicolas-raoul/wikivoyage2osm/blob/master/wikivoyage2osm.sh 欢迎大家贡献更多验证功能 :-) Nicolas1981 (讨论) 2013年12月3日 (世界标准时间) 14:36[回复]

其中一些所谓的“未知参数”可能是其他WV语言中有效的字段，例如第二个电话号码（或手机号码）、维基百科的链接或（如果实施了）维基数据，或者指向Facebook/Twitter等网站的链接。即使en.WV目前不使用这些信息，我们也可能希望保留它，因为混搭或第三方应用程序可能会找到其用途（例如，WikiSherpa是地图+WP+WV，所以WP链接对他们可能有用）。如果字段名是这里确实存在且名称只是不同的（例如adresse和téléphone），那么这才是应该修复的问题。我们确实有相当多的列表将信息放在描述中而不是更具体的字段中——最初是纯文本并由机器人转换的列表中的时间和价格不可避免地容易出现这种情况。我们还有许多格式不正确的电话号码列表——像宿务（市）这样的地方有时有多达四个号码来呼叫同一个地点。我不得不怀疑当地的宿务电话公司是否没有“寻线”或“等效”功能来处理有多条线路的固定电话？免费电话号码有时被包含在“电话”中而不是“免费电话”中，即使该字段中已经有一个本地号码。缺少国家代码相当常见，而且我们大概希望是+44 20而不是+44 (0) 20，如果国际电话没有本地中继前缀。存在大量的错误，但我怀疑除了极少数情况外，它们是否能自动修复。K7L (讨论) 2013年12月3日 (世界标准时间) 18:27[回复]

在所有平台上将电话号码渲染为“tel:”URL

我经常与Kiwix开发者交流，他告诉我他看不出我们为什么不将电话号码渲染为“tel:”链接的理由。

我认为他说的有道理，这类链接对于支持此协议的人（安卓、Skype等）来说会很有用，尽管并非所有人。

您对此有何看法？谢谢！

顺便说一下，一份全新的Wikivoyage ZIM昨天已经发布。Nicolas1981 (讨论) 2013年12月3日 (世界标准时间) 14:31[回复]

支持这个想法。电话号码超链接对用户友好，可以极大地改善我们移动网站访问者的体验。--Saqib (讨论) 2013年12月3日 (世界标准时间) 14:41[回复]

只要号码以+开头，任何使用列表模板的电话号码都已经实现了这一点。-- WOSlinker (讨论) 2013年12月3日 (世界标准时间) 17:08[回复]

哦对，刚意识到它正在运行。--Saqib (讨论) 2013年12月3日 (世界标准时间) 18:17[回复]

我们有3234个列表格式不正确——它们将两个（或更多）号码塞进一个字段，号码有一个主交换机，然后是一个分机（tel: 处理不好，如果能处理的话），它们包含字母数字电话号码，例如+1-800-HOLIDAY或+1-800-RENT-A-CAR，或者（在2914个实例中）缺少国家/区号。在某些情况下，这些列表最初是未经标签或模板提交，然后由机器人脚本随意转换的。现在，格式正确的有效号码将获得一个tel:链接，但对于一些号码格式糟糕的页面，存在完整的维护类别。K7L (讨论) 2013年12月3日 (世界标准时间) 18:10[回复]

谢谢！我之前没有意识到这一点，抱歉打扰了！我会试着想办法让修复有问题数字变得更容易，而无需检查文章中的所有数字。Nicolas1981 (讨论) 2013年12月4日 (世界标准时间) 05:07[回复]

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

下载OxygenGuide并将其解压到您的笔记本电脑或手机上，即使没有互联网，您也可以拥有整个Wikivoyage！

使用最新数据转储（星期六）生成。现在包括一个菜单，可以轻松跳转到任何部分。Nicolas1981 (讨论) 2013年12月2日 (世界标准时间) 13:41[回复]

那么Mac用户呢？--Saqib (讨论) 2013年12月2日 (世界标准时间) 13:43[回复]

Saqib：在Mac上，您也可以下载OxygenGuide，解压缩后离线浏览 :-) 如果有任何问题，请告诉我，感谢您的反馈！Nicolas1981 (讨论) 2013年12月3日 (世界标准时间) 04:07[回复]

现在有搜索功能了吗？Travel Doc James (讨论 · 贡献 · 电子邮件) 2013年12月5日 (世界标准时间) 04:26[回复]

需要帮助修复双重重定向

从酒馆扫过

我发现了几十个双重重定向，有人有20分钟来修复它们吗？谢谢！它们在https://wikivoyage.cn/wiki/User:Nicolas1981/Syntax_checks#Double_redirectsNicolas1981 (讨论) 2013年11月29日 (世界标准时间) 02:40[回复]

以前有一个机器人做这个，但操作员从维基媒体退休了。:/ --Rs chen 7754 2013年11月29日 (世界标准时间) 02:44[回复]

我编辑了你的列表——已修复——我只相信有一个Bigi Pan指向自身，所以我让它重定向到苏里南，因为它是一个岛屿在那里……Matroc (讨论) 2013年11月29日 (世界标准时间) 05:35[回复]

再次感谢Matroc :-) 每月需要20分钟，所以优先级不是很高，但如果有人知道维基百科上执行此操作的机器人，能告诉我吗？我可以尝试在Wikivoyage上运行相同的机器人。Nicolas1981 (讨论) 2013年11月29日 (世界标准时间) 07:50[回复]

我在维基百科上看到修复双重重定向的机器人是w:User:AmphBot，尽管可能还有更多。Nick1372 (讨论) 2013年11月30日 (世界标准时间) 16:24[回复]

显然Amphbot的开发者在2012年离开了维基百科，并且找不到源代码。Nicolas1981 (讨论) 2013年12月2日 (世界标准时间) 03:35[回复]

User:RileyBot在这里获得了批准，但在所有者从维基媒体退休后停止运行。--Rs chen 7754 2013年12月2日 (世界标准时间) 04:18[回复]

RileyBot的源代码也没找到……Nicolas1981 (讨论) 2013年12月2日 (世界标准时间) 07:53[回复]

显然这是mw:Pywikipedia的一个函数（redirect.py）。--Rs chen 7754 2013年12月3日 (世界标准时间) 07:19[回复]

在Special:DoubleRedirects页面确实有一个。Special:BrokenRedirects也没有被清理。-- torty3 (讨论) 2013年12月6日 (世界标准时间) 11:30[回复]

从WT复制

出现了一个问题，波洛茨克的内容是从WT复制过来的。大部分但并非全部作者是同一个导入者。（见Talk:Polatsk）在这种情况下我们该怎么办？我们想保留它吗？如果想，最好的归属方式是什么？显然，我们不想让这种复制变得太容易，并鼓励更多的复制，鉴于我们最近努力减少对那里的归属链接而不是增加它。或者，这位用户是否有可能只将他最初在那里做的未更改的贡献插入到我们这里的新文章中，而不必担心归属于其他网站？Texugo (讨论) 2013年12月6日 (世界标准时间) 13:51[回复]

如果用户先将文本放入WV，然后再复制到WT，问题是否会解决？Andrewssi2 (讨论) 2013年12月6日 (世界标准时间) 14:26[回复]

嗯，理想情况是他们先在这里贡献，句号，但你的建议不太可行，也没有解决信息已经首先在那里添加的不可避免的情况。Texugo (讨论) 2013年12月6日 (世界标准时间) 14:36[回复]

它可以通过我们的讨论页面向这些贡献者提供指导，因此是可行的。

对于 WT 首先发布的不可避免的情况，没有建议。Andrewssi2 (讨论) 2013年12月6日 (世界标准时间) 14:44[回复]

鉴于过去的法律历史（Wikivoyage:Wikivoyage and Wikitravel#我可以在Wikivoyage和Wikitravel之间复制内容吗？），我们不鼓励需要归属的复制，所以我建议我们需要删除任何不是作者原创作品的内容。-- Ryan • (讨论) • 2013年12月6日 (世界标准时间) 15:56[回复]

是的，每个人都应该避免直接复制Travel的内容。如果一个人在Travel中添加了一些第一手信息，那么用不同的措辞在这里写下相同的信息应该不难。另外，当然，支持其他网站与否取决于个人，但我个人自一年半以前就不再在那里贡献了，我想大多数Voyagers也是如此。Ypsilon (讨论) 2013年12月6日 (世界标准时间) 16:38[回复]

从法律上讲，文本的作者拥有版权，并且可以随心所欲——但重新措辞文本是个好主意，因为重复内容会受到搜索引擎的惩罚。在对页面进行大量更改后，使用http://www.copyscape.com/compare.php查找文章中仍然存在的WT文本，这些文本可以重新措辞或删除，有助于避免重复内容惩罚。K7L (讨论) 2013年12月6日 (世界标准时间) 16:47[回复]

为了澄清我上面的评论，如果有人复制他们自己的原创作品，则无需进一步归属——他们是原创作者，无论他们是专门为Wikivoyage写作，专门为WT写作，还是将自己的作品复制到两个网站，归属都是一样的。但是，如果复制的内容并非完全是作者自己的作品，虽然在提供归属的情况下复制文本在法律上是允许的，但根据Wikivoyage:Wikivoyage and Wikitravel#我可以在Wikivoyage和Wikitravel之间复制内容吗？，我认为不鼓励这样做，除非事先已经讨论过。至于SEO问题，虽然所有内容都与他处发现的内容不同会很棒，但如果有人想同时贡献到两个网站，我不能确定要求他们为每个网站编写不同版本是否完全合理。-- Ryan • (讨论) • 2013年12月6日 (世界标准时间) 17:15[回复]

归属信息可以放在历史记录中。我们移动维基百科文本时就是这样做的。底部不需要归属信息。Travel Doc James (讨论 · 贡献 · 电子邮件) 2013年12月6日 (世界标准时间) 18:35[回复]

越南的编辑战

我看到了上面关于如何吸引实际旅行者在WV上编辑的对话。就此而言，我想请您查看会安讨论页，其中一位常客不断撤销我添加的一段信息。请告诉我为什么我还要在这里进行另一次编辑。--Neotarf (讨论) 2013年11月19日 (世界标准时间) 13:31[回复]

我并非想赶走你，我的部分想法是，既然你不是一个全新的用户，你更有可能愿意讨论事情而不是直接离开。关键点在于，美山应该被列在文章的“下一步去哪”部分还是“景点”部分。它不能同时列在两个部分。这才是真正的症结所在，尽管我也提出了文章是否应该合并的问题。Ikan Kekek (讨论) 2013年11月19日 (世界标准时间) 19:45[回复]

请耐心一点。你在这里遇到的政策立场是，每个景点只列出一次。这通常运作良好，但像所有事情一样，它在边缘地带是模糊的。--Inas (讨论) 2013年11月19日 (世界标准时间) 22:28[回复]

“下一步去哪”的目的是什么？它似乎是一个随机的城市列表。难道没有一个“离开”部分吗？
旅行者的时间极其有限。如果他们来到这里，发现突然陷入一场大争吵，或者被告知要耐心等待，或者被告知一些内部行话，他们就会止损并悄悄地去别处。他们可能不会告诉你为什么。我会告诉你。你已经知道我实际上不使用这个网站，有其他更好的纸质和在线资源。但这个网站是新的，潜力巨大。
在我的讨论页上，我被指向了旅行者优先，但现在我发现有一长串隐藏的神秘理由导致这无法实现。--Neotarf (讨论) 2013年11月20日 (世界标准时间) 03:13[回复]

你在Talk:Hoi An中询问时，我已解释了“下一步去哪”部分的用途，但既然这里会有更多人阅读，我将引用Wikivoyage:超大城市文章模板中的内容。

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

没有其他的“离开”部分。我认为你可能是把这个网站和另一个仍然使用“出去”部分的网站混淆了。

听着，也许我不应该两次撤销你的编辑，我很抱歉惹恼了你，但我们不喜欢在文章的不同部分重复信息，我不太确定你关于服务旅行者的观点。我可以看到，在“景点”部分用散文写上“除了城内的这些景点，许多人还以会安为基地参观美山和其他几个地方（参见‘下一步去哪’）”可能对旅行者有用，但是在那里创建一个完整的“景点”条目，然后在“下一步去哪”中也提供一个指向更详细指南的链接——这真的能最好地服务于旅行者吗？我真的不明白为什么在不止一个地方覆盖相同的景点会帮助旅行者。Ikan Kekek (讨论) 2013年11月20日 (世界标准时间) 03:23[回复]

避免重复列表的政策是为了帮助旅行者。我真的认为你在这里小题大做了。如果人们因为我们有明确的行事方式而离开，那么他们可以去写自己的博客或旅行日记，完全按照他们希望的方式。在维基上工作意味着合作。这意味着有时，一个旅行者的博客，或TripAdvisor或Thorntree论坛可能会提供更好的信息。这很好。如果你认为在WT会得到更友好、更开放的接待，我对此表示怀疑。我经历过，已经做过了。--Inas (讨论) 2013年11月20日 (世界标准时间) 03:34[回复]

哦，我确实在维基旅游。我在这里的时间比在那里更长。而且我从未在那里遇到过在这里遇到的问题。但公平地说，相关讨论页上的情况似乎正在解决。致敬，--Neotarf (讨论) 2013年12月14日 (世界标准时间) 13:21[回复]

时光旅行者指南

（在此处发帖，因为这是主要的讨论中心。）

有没有人对维基导游的编写方式足够熟悉，可以为我设想的一个相关项目提供建议？

据指出，在四月份会编写愚人节文章。然而，我有一个比那稍微更严肃的想法。

这个想法是（可能在维基学院上）开发一套针对不同历史时期地点的“时光旅行者”指南，以支持历史教育。

考虑到您比某些人更了解您各自的领域和历史，维基导游的人是否有兴趣为此做出贡献？：）Sfan00 IMG (讨论) 2013年12月4日 (世界标准时间) 12:24[回复]

这听起来非常有意思。你能具体说明一下你需要什么样的帮助吗？Texugo (讨论) 2013年12月4日 (世界标准时间) 12:43[回复]

我有一本1975年出版的韩国旅行指南。如今，韩国已是一个截然不同的国家，在许多方面，30年前的访问就像是访问一个新地方。我很想看看你有什么想法。Andrewssi2 (讨论) 2013年12月4日 (世界标准时间) 13:38[回复]

嗯，本质上我需要一些作者，因为我更擅长构思而非实际写作。基本上，我请求的是有人根据维基导游的风格指南为历史地点和时间编写指南（尽管是从现代角度编写）。如果有人想尝试编写同时代（与时期）的风格，我不会介意，但我的想法是“时光旅行”指南，而不是布拉德肖的模仿品 ;) Sfan00 IMG (讨论) 2013年12月4日 (世界标准时间) 17:16[回复]

好的，首先要确定（和笑话文章一样）一个可能的位置……对我来说，一些容易的位置是

纽约 1965
伦敦 1967
伦敦 1890
牛津 1955（但牛津变化不大……）

我建议选择一个并着手处理…Sfan00 IMG (讨论) 2013年12月4日 (世界标准时间) 17:16[回复]

我们的一些行程文章，如丝绸之路或刘易斯和克拉克之路，已经部分具有历史性。我主要写了两篇：《追随吉卜林的《金》》和《追随马可·波罗》；那里有什么你可以用的吗？

我基于从古腾堡计划下载的书籍。他们有数千本更多的书，包括许多历史小说和19世纪探险家或传教士在各种奇怪地方的日记。我认为你的项目可能会大量引用其中最好的部分，或者有时只提供一个链接。

我对更具异国情调的时光旅行更感兴趣，中世纪牛津、凯撒治下的罗马、唐朝中国或阿育王的印度。Pashley (讨论) 2013年12月4日 (世界标准时间) 17:48[回复]

我也有同样的想法。大火前夕的伦敦，18世纪70年代的费城，穆斯林统治下的塞维利亚，平安京都……这需要更困难的研究，但那会多棒啊！Texugo (讨论) 2013年12月4日 (世界标准时间) 19:34[回复]

好的……我会开一个页面，如果有人想建议一个合适的主机项目……Sfan00 IMG (讨论) 2013年12月5日 (世界标准时间) 11:47[回复]

您有一个登陆页面 - []，从那里开始 :) Sfan00 IMG (讨论) 2013年12月5日 (世界标准时间) 21:43[回复]

我开始在Wikicronos上撰写关于https://en.wikiversity.org/wiki/User:ShakespeareFan00/Wikicronos/London_%281951%29的文章。我需要一些帮助来扩展它。:) Sfan00 IMG (讨论) 2013年12月5日 (世界标准时间) 22:25[回复]

这看起来是一个非常激动人心且有趣的项目！绝对值得一试！我可以谦虚地建议我们称之为Wikichronos（带'h'），如果我们要这样称呼它的话，因为那是古希腊时间的人格化。我们是将其留在维基学院还是作为这里的子项目？--尼克 ^讨论 2013年12月5日 (世界标准时间) 22:38[回复]

好的——它目前在维基学院，因为范围规则。如果维基导游社区不反对在这里以Wikichronos的名义托管它（并且有明确的免责声明它不是真实内容），我没有异议，但这必须是社区讨论，而不是我个人的决定。ShakespeareFan00 (讨论) 2013年12月5日 (世界标准时间) 23:37[回复]

我认为在英语中用“chronos”或“kronos”都可以，但不能只用“c”。英语在“chronology”和其他词中都有“ch”。如果它将是一个多语言项目，我们应该咨询其他语言的一些人。如果可能的话，包括一位现代希腊语学者或古希腊语学者。Pashley (讨论) 2013年12月6日 (世界标准时间) 01:51[回复]

嗯，显然我们需要一些学者。你期望一个2013年的人能理解口语拉丁语吗（这当然与纯粹的“古典”拉丁语不同<哈哈>）。我没有直接使用Kronos是因为商标问题吗？Sfan00 IMG (讨论) 2013年12月6日 (世界标准时间) 11:01[回复]

我正在等待社区对此的批准Sfan00 IMG (讨论) 2013年12月8日 (世界标准时间) 17:23[回复]

恕我直言，这超出了此处的讨论范围。LtPowers (讨论) 2013年12月9日 (星期一) 01:47 (UTC)[回复]

谢谢。不过，我建议任何感兴趣的人直接联系我，以便在一个更合适的项目上进行开发。Sfan00 IMG (讨论) 2013年12月9日 (星期一) 10:07 (UTC)[回复]

我想我同意LtPowers的看法。这是一个有趣的想法（我添加了一些关于食物配给的词语），但我看到几个潜在的问题。对于严肃的教育用途，我认为事实需要参考文献（像维基百科一样，但与这里不同），因为与普通旅游目的地不同，没有一手资料，文章也不会被实际去过那里的人完善。还有一个难题是避免有人将文章误认为是普通的旅行指南，而且我认为这违反了政策，因为它不是一个对游客开放的目的地。你是否知道学校对这种指南的需求很大？

然而，我认为我们可以有一个旅游主题（或行程），引导人们参观今天仍然可见的与特定时期相关的景点，这可能有助于家长们将学校历史带入生活。我正在考虑罗马不列颠或1950年代英国建筑之旅等。AlasdairW (讨论) 2013年12月9日 (星期一) 23:54 (UTC)[回复]

你指出的这些担忧正是我在维基学院试行这个项目的原因。

一）我不反对将参考文献纳入以支持历史事实或推测。（《可怕的历史》我想是包含了确认历史来源的注释），我也不反对设立一个“基础”页面，在那里可以讨论指南的可信度或准确性（这是《架空历史维基》所做的）。

二）我不知道学校有任何具体的需求，但“时间旅行者”指南的方法已被一些英国博物馆和遗产机构用于展示社会历史材料。WikiChronos主要是我自己的想法，但我希望在讨论中获得支持。

三）是否可以设置一个合适的免责声明，以免被误认为是真实内容？（目前它在我的维基学院用户空间中是有原因的？）（而且这个讨论应该及时转移到那里）。

四）创建以教育为重点的旅行主题/行程也是Wikivoyage可以做的事情。我支持这一点。（我当然也不反对WikiChronos页面链接到实际的Wikivoyage页面）。

你提到的这些话题可能会很令人兴奋。Ikan Kekek (讨论) 2013年12月9日 (星期一) 23:58 (UTC)[回复]

导出到epub的问题

大家好，
首先——感谢各位为维护这个网站所做的出色工作。我已经和工作中的一些朋友分享了它。我不确定是应该在末尾添加新问题，还是应该挂接到这里已有的相关主题。
现在回到问题本身——我试图将我的书导出为epub，以便在旅行时方便地在Kindle上使用（我喜欢这个功能），但无论我选择哪种格式，它总是将我的书保存为PDF。这个功能目前是坏的，还是我操作不当？此致 Iwwwwwwi (讨论) 2013年12月6日 (星期五) 23:03 (UTC)iwwwwwwi[回复]

我猜这是因为我们缺少一个扩展。--Saqib (讨论) 2013年12月7日 (星期六) 07:50 (UTC)[回复]

有什么办法可以解决这个问题吗？我记得一个月前它还运行良好。Iwwwwwwi (讨论) 2013年12月7日 (星期六) 10:29 (UTC)[回复]

不是缺少扩展，可能一个月前还能用。这个bug似乎是在11月15日引入的 - Bugzilla: 57975 和 Bugzilla: 57920，WMF技术人员已将其列为高优先级。-- torty3 (讨论) 2013年12月9日 (星期一) 01:17 (UTC)[回复]

Google搜索数据

查看WV的Google趋势页面，似乎在今年年初“繁荣”启动期后的下降后，关注度已经稳定下来。美国当地数据显示略有下降，但仍然表明有持续的访问者流量，这无疑可以加以利用。--Half past (formerly SUFCboy) 2013年12月8日 (星期日) 13:16 (UTC)[回复]

对比一下，我们仍然远远落后。--Saqib (讨论) 2013年12月8日 (星期日) 13:53 (UTC)[回复]

Sapphire在这个帖子（时间戳为2013年12月7日17:31）中的评论带来了巨大的希望。-- AndreCarrotflower (讨论) 2013年12月8日 (星期日) 18:52 (UTC)[回复]

营业时间：OpenStreetMap有一个清晰且周密的标准，我们是否应该切换到它？

OpenStreetMap表达营业时间的方式如下：http://wiki.openstreetmap.org/wiki/Key:opening_hours#Examples http://wiki.openstreetmap.org/wiki/Key:opening_hours:specification

我们也有这样的标准：https://wikivoyage.cn/wiki/Wikivoyage:Time_and_date_formats

如果我们对自己的标准满意，那就没问题。但我正在运行一个验证脚本，大部分数据不符合我们的标准，所以我在想我们不妨借鉴OpenStreetMap。标准化对每个人都有好处，它使我们更容易与其他工具集成。我并不是说我们现在就应该切换，我只是想听听大家对这个想法的反馈。Nicolas1981 (讨论) 2013年12月10日 (星期二) 09:23 (UTC)[回复]

你将遇到的问题是，在美国，除了军事时间外，很少使用24小时制，许多美国人难以理解例如“20:00”是什么意思。我知道我在欧洲的时候也会将下午的时间减去12小时，以弄清楚它们是什么。我认为在美国的文章中强制使用24小时制甚至会比强制使用英式拼写更不合时宜，我不得不说，与其他工具集成的便利性论点并不能说服我，因为这种改变会给编辑美国目的地文章的美国用户带来真正的麻烦，并且无助于前往美国的旅行者理解他们将看到的实际营业时间标志。Ikan Kekek (讨论) 2013年12月10日 (星期二) 09:37 (UTC)[回复]

我没考虑到这一点，谢谢！那样确实会不方便用户。Nicolas1981 (讨论) 2013年12月10日 (星期二) 13:34 (UTC)[回复]

是的，我们应该切换到OSM标准。Pashley (讨论) 2013年12月10日 (星期二) 13:52 (UTC)[回复]

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

我不想过分强调“美国人很奇怪”这个方面，因为真正的问题在于OSM标准旨在机器可读。而我们的标准旨在人类可读。这是一种根本上的不兼容。我们不能也不应该尝试将我们的营业时间严格地纳入一种固定格式。坦率地说，我不确定Nicolas的脚本想要验证什么。LtPowers (讨论) 2013年12月10日 (星期二) 14:45 (UTC)[回复]

OSM标准如何处理季节性变化的营业时间？根据目的地不同，旅行和航海列表往往有一半的景点在劳动节或感恩节关闭。K7L (讨论) 2013年12月10日 (星期二) 15:57 (UTC)[回复]

同意，这是反对采用OSM格式的最大论点。WV列表相当简单，只有少数几个字段用于传达“营业时间”和“价格”等一般信息类别。我经常输入诸如“周一至周六上午9点至下午5点，每小时有导览，隔周二关闭”（是的，这是我刚刚编造的）或其他易于人类理解的词语组合的营业时间，但如果将其放入机器可读格式，则会非常冗长。（OSM通过标记诸如opening_hours:tours=Mo-Sa 09:00,10:00,11:00之类的方式来解决这个问题，而我们不能只是在列表中添加额外的字段。）如果它采用一致、简洁的格式，那又有什么优势呢？你有没有想到可以用我们的列表做些什么，是现在不能做，但如果改变格式就可以做的？--Bigpeteb (讨论) 2013年12月10日 (星期二) 22:08 (UTC)[回复]

当然，总会有一些POI需要非机器可读的时间。回答LtPowers的问题：我的脚本会找到诸如hours="Closed"或hours="jonron49@bigpond.com"（是的，这些现在就在Wikivoyage中）的情况，以及语法可以改进的情况，例如hours="8 am to 10 pm"。Nicolas1981 (讨论) 2013年12月11日 (星期三) 06:42 (UTC)[回复]

CSV中的所有列表

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

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

一个建议，货币转换器

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

这不是一个购物网站，价格只需以当地货币或美元表示就足够了。--Saqib (讨论) 2013年12月10日 (星期二) 22:23 (UTC)[回复]

以当地货币表示价格听起来不错，但以美元表示不是一个好主意，原因有二：1）汇率持续变化，价格可能很快就不再有效。2）不是所有人都使用美元，我认为英国人应该重新考虑。--Kizar (讨论) 2013年12月10日 (星期二) 23:02 (UTC)[回复]

除了图片、天气和动态地图外，价格是旅行者最常关注的事项之一。有一些网站使用动态转换器，例如http://dynamicconverter.com/，允许读者选择以他们选择的货币（几乎实时更新）显示每一个价格。

您可能也有兴趣阅读几年前的一次非常简单的讨论：Wikivoyage_talk:Currency#Exchange_Rate_Bot。此外，还有一位4WD维基网站的网站管理员在很久以前发起了一次更有趣的讨论，但我没能记住在哪里看到的...

感谢Kizar为我们一些与西班牙语相关的文章添加的所有精彩材料！--118.93nzp (讨论) 2013年12月10日 (星期二) 23:56 (UTC)[回复]

你好，Kizar，谢谢你提出了一个可以帮助读者的想法。然而，我认为任何想要查找外汇换算的人都可以通过在任何网络浏览器中输入“外汇汇率”，然后在该网站上输入数字来非常容易地完成。并非所有能帮助读者的东西都真正属于本指南的范围，而且我认为我们不想在网站上的每篇文章中都包含货币换算表。Ikan Kekek (讨论) 2013年12月11日 (星期三) 01:17 (UTC)[回复]

不，当然不是转换表格，但是，就像我们不一定希望人们去使用谷歌地图（或者目前是维基百科）一样，我们可能希望开发技术能力，让用户设置他们的偏好，以显示 (a) 次要的当代货币转换 (b) 选择次要转换货币的显示方式（类似于我们可以为注册并登录的读者提供的缩略图显示大小选择...） --118.93nzp (讨论) 2013年12月11日 (星期三) 01:34 (UTC)[回复]

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

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

我建议我们应该小心与我们无法控制的外部服务集成，因为突然失去其中一个服务将极大地影响本网站的质量。Andrewssi2 (讨论) 2013年12月11日 (星期三) 02:57 (UTC)[回复]

相对不错的货币转换可能可以通过模板（可能还需要一些额外的JavaScript）来完成，但就实施达成一致意见，然后将其在整个网站上实施将是一项繁重的工作。我建议这可能是某人可以开始起草提案并将其添加到路线图中，作为“未来考虑”的事情，但考虑到需要解决的其他网站问题，现在可能还不可行。-- Ryan • (讨论) • 2013年12月11日 (星期三) 03:29 (UTC)[回复]

如果有一个用户偏好设置和一个客户端JavaScript小工具，可以加载汇率数据并为每个列表价格添加您偏好的货币后缀，例如：JPY1500 (10.6€) 怎么样？当然，无法机器读取的价格将被排除在外。猜测用户想要哪种货币是很棘手的，所以我们可以选择在用户设置偏好之前不显示任何内容。Nicolas1981 (讨论) 2013年12月11日 (星期三) 06:17 (UTC)[回复]

使用维基数据可能是一个选项，这样可以跨语言维基导游共享。--Rs chen 7754 2013年12月11日 (星期三) 10:01 (UTC)[回复]

也许没必要使用模板。只需要一个用JavaScript编写的可选小工具来执行文本替换。例如，列表编辑器会更改页面内容，将“编辑”链接放在列表中。该程序将获取汇率，搜索文本中像“5.23€”或“$2.33”这样的表达式，并用转换后的值替换旧文本。

汇率可以从这个页面免费获得，只需创建一个免费账户即可得到类似这样的东西，而且很容易将格式更改为Javascript数组这样的。Javascript代码可以存储在Wikivoyage、Metawiki、Toolserver...当然，它也可以每天由一个机器人更新。

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

示例：用户之前在某处定义了他想以欧元（EUR，€）查看价格。在某篇文章中，有文本“1000 JPY”（JPY = 日元）。JavaScript代码获取此文本并将其转换为9.74518美元，然后再转换为7.06396欧元。操作很简单（1000 / currency_ex['JPY']）* currency_ex['EUR']，即可得到欧元。现在将“1000 JPY”替换为“7.06 EUR”。其他货币的其他价格也将转换为欧元，用户只需以欧元查看所有内容，而无需更改文章源文件中的任何内容。--Kizar (讨论) 2013年12月11日 (星期三) 15:03 (UTC)[回复]

无论我们能找到什么解决方案，我认为它都应该增加（括号内）而不是替换。但无论如何，我认为这需要更多考虑。例如，我认为它需要合理地进行四舍五入。当我们有一个酒店的价格范围是“双人间R$60-80”时，我们不希望它变成“双人间USD $23.17-31.48”。那会不合理地具体。Texugo (讨论) 2013年12月11日 (星期三) 14:50 (UTC)[回复]

如果用户货币的价格小于10，则保留两位小数，否则不保留小数。无论如何，我提议的是一个不改变文章现有代码的外部小工具。如果用户在偏好设置中选择了禁用此小工具，他将看到页面现在的样子。即便如此，也可能只在价格附近显示一个符号，点击后会出现一个小弹出窗口。--Kizar (讨论) 2013年12月11日 (星期三) 15:03 (UTC)[回复]

所以如果一件东西是100美元，你希望它显示“JPY 10238”？这不是四舍五入和有效数字的工作方式。LtPowers (讨论) 2013年12月11日 (星期三) 20:30 (UTC)[回复]

我认为它不应该显示超过两位有效数字。所以这个例子就变成了日元10000。任何显示出来的数字都会在几天内发生2-5%的变化，而且旅行者还要支付佣金等等。总的来说，我不确定这样做的好处，因为我旅行时通常希望看到当地货币的价格，这样我才能习惯我将要支付的价格。AlasdairW (讨论) 2013年12月12日 (星期四) 22:02 (UTC)[回复]

动态地图的语言

我刚从亚洲，包括泰国，旅行了几周回来，我第一次发现WV指南如此完整，以至于我真的可以使用它们，甚至觉得它们比我的LP书更好。实际上，这相当令人兴奋！然而，这也让我对我们设置中缺少、不足或不太实际的地方有了一些见解。我发现的主要问题之一是，泰语动态地图对我来说几乎无法使用，导致我不得不转向其他在线应用程序和我的书来找路。在泰国主要目的地，比如清迈的道路标志实际上是双语的，包括英语。这不仅更容易阅读，而且还能大致了解名字听起来像什么，这对于向出租车或嘟嘟车司机解释去哪里很有用。这是怎么回事？我们有选择地图使用哪种语言的选项吗？是否曾有过关于此的讨论？JuliasTravels (讨论) 2013年12月11日 (星期三) 15:19 (UTC)[回复]

在Wikivoyage talk:Dynamic maps Expedition#Shanghai map有一些讨论。Pashley (讨论) 2013年12月11日 (星期三) 16:17 (UTC)[回复]

...讨论可以概括为，“我们对此无能为力”。在我看来，除了OSM未来的任何发展，唯一可行的解决方案是为使用非拉丁字母的本地语言目的地创建和维护静态地图。-- AndreCarrotflower (讨论) 2013年12月11日 (星期三) 16:38 (UTC)[回复]

那是一个误解，我没有澄清或更新。它本质上是WMF总体计划的一部分，即为所有维基百科提供本地化的OSM地图，并让所有维基导游跟随，最初的目标至少在六个月前就已到期，但由于技术问题，一直被推迟。现在有可能拥有本地化地图，但开发服务器（容易超时）和现成的生产服务器之间存在非常大的差异，这就是为什么快速加载时间和稳定的运行时间被优先考虑的原因。

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

谢谢你澄清，torty3。我急切地等待这方面的进一步信息。-- AndreCarrotflower (讨论) 2013年12月11日 (星期三) 21:22 (UTC)[回复]

电话语法检查

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

我不期望任何人去修复所有这些。人类的时间最好花在经纬度上，那是一个需要人工判断的较小列表。

但无论如何，这里是电话号码，希望它能给一些人提供处理它们的方法：第2页第3页第4页

干杯！Nicolas1981 (讨论) 2013年12月11日 (星期三) 08:18 (UTC)[回复]

在这两个列表中，似乎有一些常见的错误可能适合机器人脚本处理。电话号码中的(0)可以安全地删除，错误的经纬度值通常要么是DMS（适合转换），要么是多余的文本（可以删除）。也许一些正在运行机器人的用户可以评论一下？理想情况下，手动编辑应针对无法自动修复的问题，因为我们只有有限数量的人工编辑来完成这些更改。K7L (讨论) 2013年12月11日 (星期三) 18:11 (UTC)[回复]

skobbler

"

柏林，2013年12月10日 /美通社/

全球在线/离线地图和导航 - 口袋大小的价格，卓越性能

应用程序全新设计，提供更流畅、直观的操作
所有功能均支持真正的离线功能（通过应用内购买），包括国家、大陆和全球下载，以及城市和州
来自OpenStreetMap的更新和新鲜地图数据，数字地图的未来
全新流线型和改进的地图在最需要时提供水晶般清晰的细节和流畅的浏览体验
基于全球最强大的数字地图引擎 NGx 构建，提供无缝地图操作和定制
集成 'Wikitravel' 和 TripAdvisor 数据，提供当地的快速、最新信息

移动定位服务创新者 skobbler 宣布对其极其成功的 GPS Navigation 进行重大更新——这是 iOS 上最流行的导航解决方案。它提供了一系列强大的新功能，旨在将 iPhone 或 iPad 变成高端卫星导航系统，提供卓越性能且价格实惠。无论是在国内还是国外，GPS Navigation 都具有极致的灵活性，允许消费者在可用时使用互联网连接进行在线使用，或者下载地图（通过应用内购买）存储在设备上——从单个城市到全球——以便在连接不良或数据漫游区域使用。

"

我强调的。难道不应该有人告诉他们 Wikitravel 已经过时了吗？（我自己会做，但我匿名且地位低下，最好由一个既不匿名也不地位低下的人来做……）——118.93nzp (talk) 2013年12月12日02:10 (UTC)[回复]

查看 WT 的“近期更改”会发现该网站处于停滞状态，尽管没有任何迹象表明它已过时。（有一些活跃用户勇敢地在垃圾信息轰炸下尝试添加内容）

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

小工具请求

不确定在哪里提出此请求，但有人可以导入 w:en:Special:Gadgets/export/righteditlinks 和 w:en:Special:Gadgets/export/addsection-plus 吗？谢谢 Smokestack Basilisk (talk) 2013年12月13日15:41 (UTC)[回复]

如果您能提供一些关于这些小工具的背景信息，可能会有所帮助。LtPowers (talk) 2013年12月13日21:32 (UTC)[回复]

当然，w:en:Special:Gadgets/export/righteditlinks 将编辑链接放回屏幕右侧，而 ~~w:en:Special:Gadgets/export/addsection-plus~~ 已经安装。我发现另一个有用的是 w:en:Special:Gadgets/export/OldDiff，它将差异颜色恢复为原始的媒体维基红/绿格式，并更改了差异的空格格式。我发现传统的差异格式比新格式更容易阅读。由于这些只是用户小工具，不会更改任何默认设置，它只会允许用户更改其偏好。Smokestack Basilisk (talk) 2013年12月13日22:02 (UTC)[回复]

实际上，这个维基百科的小工具导入功能已被禁用，所以你必须从英文维基百科复制粘贴源代码。——Rs chen 7754 2013年12月14日10:03 (UTC)[回复]

重复文本

你好。

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

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

TaBaZzz (talk) 2013年12月15日07:05 (UTC)[回复]

当然。这正是模板擅长的工作，这样信息就可以在一个中心位置更新，而不必在多个文章中更新……感谢您帮助改进我们的旅行指南！——118.93nzp (talk) 2013年12月15日07:17 (UTC)[回复]

更好的方法是，直接引用一个包含详细信息且易于更新的机场页面。我们设立机场页面就是为了这个目的。如果您认为信息太少，不足以创建单独的机场文章，可以将其包含在例如特拉维夫文章中，并从其他城市文章链接到特拉维夫#乘飞机。PrinceGloria (talk) 2013年12月15日09:33 (UTC)[回复]

还有以色列#乘飞机。我猜本-古里安机场足够大，可以有自己的文章，如果有人想写的话。我们可以在 Wikivoyage talk:Airport Expedition 进一步讨论，那里通常会就机场文章是否成立达成共识，但我怀疑没有人会反对。它是以色列主要的国际机场，关于安检程序和地面交通有很多可说的。Ikan Kekek (talk) 2013年12月15日09:44 (UTC)[回复]

Snowolf

此备注旨在告知大家 User:Snowolf 已辞职，因为权限移除是在 Meta 上进行的： --Rs chen 7754 2013年12月17日02:46 (UTC)[回复]

感谢大家在最初选择我作为临时管理员，然后确认我作为永久管理员时给予我的善意和信任。我从未能像我希望的那样投入大量工作到这个项目中，在过去的几个月里，我的可用时间大大减少，因此我预计我在这里活跃的能力不会改变。我还想为我在这里糟糕的活跃记录向大家道歉，这是我在请求大家信任时没有预料到的。我仍然积极履行作为管理员、元维基管理员以及在我们的 IRC 频道中的职责，如果需要，可以一如既往地在 Meta 上联系我。Snowolf ^{我能帮什么忙？} 2013年12月17日03:03 (UTC)[回复]

感谢您在这里的贡献。可惜您的建议没有得到进展…… ——118.93nzp (talk) 2013年12月17日03:10 (UTC)[回复]

很高兴见到你，Snowolf，即使是为了这个。不必道歉。如果你确实有更多时间，我知道每个人都会欢迎你回来编辑更多内容或参与更多政策讨论。Ikan Kekek (talk) 2013年12月17日03:34 (UTC)[回复]

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

有些文章在酒店名称中使用星号 * 来表示其评级。例如参见 https://wikivoyage.cn/wiki/Beruwela#Sleep

这是一种推荐的风格吗，还是应该删除它们，或者现状可以接受？我整理了一份包含此类星号的146篇文章列表，请随意进行适当的修改：https://wikivoyage.cn/wiki/User:Nicolas1981/Syntax_checks#Stars

干杯！Nicolas1981 (talk) 2013年12月16日03:19 (UTC)[回复]

星级系统不是有点可疑吗？在许多地方，非连锁酒店可以自我评估，将其宣传为“四星级酒店”，而不是官方认证。Andrewssi2 (talk) 2013年12月16日03:37 (UTC)[回复]

酒店评级中加入星号没有达成共识，一些用户会随时删除它们。我认为在酒店列表的“内容”标签中以散文形式标明星级是可以的。我认为酒店列表中不应该正式允许星号。然而，虽然我不会在酒店列表中放置星号，但与删除酒店列表中包含的所有星号相比，有更紧迫的事情要做，这些星号通常用于意大利等国家/地区的酒店，这些国家的酒店列表中通常会强调星级。Ikan Kekek (talk) 2013年12月16日05:44 (UTC)[回复]

在没有监管的国家，评级是可疑的，但在有监管的国家可能有用。等级也取决于国家。无论如何，我认为这个信息不应该放在“名称”字段中……也许放在“内容”中，正如 Ikan 所建议的？多年以后（当我们完成了所有伟大的项目并且没有更好的事情可做时），我们甚至可以为此创建一个特殊的字段。Nicolas1981 (talk) 2013年12月16日09:03 (UTC)[回复]

那么，它就会因为国家之间不一致而变得可疑。 :) 无论如何，我很高兴这些评级能在“内容”中提及。Andrewssi2 (talk) 2013年12月16日09:38 (UTC)[回复]

这个问题之前已经提过很多次了，最近一次是在 Wikivoyage:Words to avoid#星级评级。我认为共识是，除非有非常特殊的原因，否则我们不应该使用星级评级。评级系统太多样化，机构很容易编造自己的评级，如果我们鼓励添加星级并命名评级系统，那将意味着我们的评估可能基于该评级系统，而不是旅行者的个人经验。我们最重要的指南之一 WV:旅行者至上规定：

地区、价格分类等均基于旅行者的便利和期望，而非官僚规定（行政区划、正式星级评定等）。（我的强调）

我实际上认为我们对星级评级的反感被写入了政策，因为多年来我们一直采取非常一致的方法。显然它没有，但我当然不介意我们将其写入某个地方。无论如何，未经限定的星号字符串绝不是机构“名称”的一部分，因此没有人应该在名称字段中放置星号。我是那些总是删除它们的人之一，我确实觉得这样做总是值得的。Texugo (talk) 2013年12月16日11:00 (UTC)[回复]

有评级系统、wikivoyage:不要吹嘘和 wikivoyage:避免使用的词语。我怀疑像“五星服务”这样含糊不清的说法是需要避免的词语，因为它过于宣传，除非指定了特定的评级系统，并且该评级机构实际上派检查员根据既定标准进行评估。“2001年米其林道路指南授予四颗爆胎星”是有效的，如果米其林确实派了检查员；“我们的五星服务将令商务和休闲旅客满意”则毫无意义。从列出所有酒店/汽车旅馆/青年旅舍/废弃洞穴的本地目录中获得一颗星（因此1*是镇上最差的地方）与在专门的高端指南中获得一颗星（其中差或甚至一般的酒店根本不会被列出）之间存在巨大差异。名称中的星号暗示“* 不含电池”或某些其他免责声明，而不是奖项，除非以某种方式进行解释。K7L (talk) 2013年12月16日18:41 (UTC)[回复]

我认为使用这些评级不是一个好主意。请参阅评级系统的开头部分。Pashley (talk) 2013年12月16日21:49 (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 (talk) 2013年12月16日03:34 (UTC)[回复]

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

顺便提一下，我正在维基百科提议一个通过 Wikidata 利用 Wikivoyage 横幅的小工具。——Yair rand (talk) 2013年12月16日05:28 (UTC)[回复]

你认为 Wikivoyage 目前最好的横幅是什么？

我尝试在此处编制一份列表 here。如果您知道任何其他特别成功且您认为质量相当的横幅（未包含在此页面中），请告诉我。我很清楚这样的列表最终将基于每个用户的个人品味，尽管如此，如果大家能在这里提及他们目前认为最好的具体横幅，我仍将不胜感激。ויקיג'אנקי (talk) 2013年12月16日23:43 (UTC)[回复]

我们有星级横幅页面，但它从未真正启动。我认为 Inkey 的、Armigo 的和 Danapit 的上传都非常棒。Jjtkk (talk) 2013年12月17日07:13 (UTC)[回复]

我明白了。这让我想起来，有没有可能有一个链接可以自动在维基共享资源上生成一份为 Wikivoyage 创建的最新横幅列表？ויקיג'אנקי (talk) 2013年12月17日15:49 (UTC)[回复]

commons:Category:Wikivoyage banners. --Saqib (talk) 2013年12月17日15:52 (UTC)[回复]

那里的文件被分成了许多子类别——子类别太多，用户无法快速了解最新添加的内容。这就是为什么我希望能有一种快速自动在维基共享资源上生成 Wikivoyage 最新创建横幅列表的方法。ויקיג'אנקי (talk) 2013年12月17日18:14 (UTC)[回复]

那个链接上的几乎都是陆地/城市风光，但我认为我们一些最好的横幅不那么显眼。京都有一个不错的。我最喜欢的一个是广岛。图像质量很好，但除此之外，仙鹤很好地代表了这座城市，但它不一定是城市最明显的标志（像原爆圆顶馆或其他一些纪念碑那样）。列表中的横幅都很好看，但它们基本上都是相同的风格。ChubbyWimbus (talk) 2013年12月18日05:45 (UTC)[回复]

有安卓设备吗？导入所有 Wikivoyage 列表！

亲爱的安卓用户，

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

场景：你被空投到一个随机的国家，没有任何准备和互联网。

只需打开 OsmAnd，Wikivoyage 的酒店等就会显示在地图上！
选择酒店后，让 GPS 为您导航。

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

不要犹豫：你的手机需要这个 :-) Nicolas1981 (talk) 2013年12月17日06:19 (UTC)[回复]

还没试过，但看起来很棒！你能分享一下列表导出的秘密吗？我们也想为其他语言做这件事。——亚历山大 (talk) 2013年12月17日07:27 (UTC)[回复]

我的秘密是 GitHub 上的开源代码 :-) 请进行 git-fork，或者更好的是直接在脚本中实现国际化，我将乐意合并您的贡献！验证/生成在我的笔记本电脑上需要一天多的时间，所以我现在正尝试让脚本在每次有新转储可用时在 Wikimedia Labs 上自动运行，一旦您的代码准备好，我也会将其设置为在俄语上运行，当然。Nicolas1981 (talk) 2013年12月17日08:44 (UTC)[回复]

好的，让我试试。我不擅长编写代码，只懂基本的 Unix 命令，但我应该能够对俄语转储运行您的代码，然后看看需要更改什么。希望只需要做很少的更改。

您能否考虑保留/生成 POI 编号，使其与 Wikivoyage 文章保持一致？——亚历山大 (talk) 2013年12月17日09:27 (UTC)[回复]

这些 ID 对于 OSM 格式来说是必需的，但它们实际上并没有出现在 OsmAnd 的任何地方……不过是个好主意！我们可以计算 POI 编号并将其连接到 POI 名称，这样 POI 名称就变成了例如“3: Roger 酒吧”。你觉得怎么样？Nicolas1981 (talk) 2013年12月18日06:03 (UTC)[回复]

嗯，那又不一样了。我当时想让 OsmAnd 地图类似于我们的动态地图，每个 POI 的编号都作为符号的一部分显示。但我不确定 OsmAnd 是否能做到这一点。——亚历山大 (talk) 2013年12月18日07:16 (UTC)[回复]

维基爱古迹摄影大赛

9月举办的摄影大赛获奖名单已经公布。这些都是国家登记在册的历史建筑（标准因国家而异）的精美照片。我认为我们应该利用其中一些照片——我们可能会从结果的宣传中受益。AlasdairW (talk) 2013年12月18日23:33 (UTC)[回复]

最全面的指南

我认为我们有一些非常全面的指南，如果与传统指南书相比。你们认为我们应该创建一个类似于星级文章的列表，列出我们最全面的指南吗？——萨奇布 (talk) 2013年12月18日11:36 (UTC)[回复]

不。星级文章需要全面，所以这部分已经涵盖了。如果我们有一些全面但质量不高的文章，请提名它们参加 Wikivoyage:月度协作；也许我们可以让它们达到星级。Pashley (talk)

好吧，但不幸的是，CotM 现在似乎已停止运作。——萨奇布 (talk) 2013年12月19日09:13 (UTC)[回复]

列表编辑器中的缺陷

请原谅我的抱怨，但列表编辑器是我们有可能远远优于 Wikitravel 的一个方面。

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

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

2) 24小时时间格式的示例错误（这种格式在美国以外的大多数国家/地区都应该使用）。

我的建议是将示例从
上午 9 点至下午 5 点或 9:00-17:00 改为
08:30-16:30 或 8:30AM-4:30PM，这样编辑者就能知道我们使用冒号分隔小时和分钟，并且在使用（在印刷品中更普遍使用的）24小时格式时，小时始终使用两位数……

3) 货币符号

₹ ₪ ₱ Kč

缺失。

（这些符号分别在 Wikivoyage:$#普遍已知货币符号例外中推荐用于印度卢比、以色列新谢克尔、菲律宾比索和捷克克朗。添加 RM、Rp 和 Rs 符号也可能值得，但这并非如此紧迫）。

如果我能自己修复最后两点，请告诉我……——118.93nzp (talk) 2013年12月18日23:51 (UTC)[回复]

指向使用 OpenStreetMap 创建的可下载开源综合免费 GPS 地图文件（国家或大陆）的外部链接

在希伯来语 Wikivoyage 中，我们最近在许多文章底部添加了此类免费合法文件的外部链接，这可能会极大地帮助旅行者。我去年曾使用过这样的地图，它帮助我在一个从未驾驶过的欧洲国家驾驶车辆时进行导航，而无需为该国购买新的 GPS 设备（GPS 制造商显然希望旅行者这样做，尽管现在人们可以合法下载大多数国家/地区的免费开源 GPS 地图并将其加载到自己的 GPS 设备上）。这样做很简单——现在许多 GPS 设备都有存储卡插槽，您可以在其中插入包含任何免费开源 GPS 地图的存储卡。由于每个国家/地区的地图都占用存储卡上可用空间的大部分，并且这些存储卡现在相当便宜，因此在许多情况下，旅行者将每个要前往的国家/地区的 GPS 地图复制到单独的存储卡中，并将它们全部放在相机包中会更容易）.

您可以在这里查看此类链接的示例（该链接出现在 GPS 图标旁边，写着“适用于 Garmin GPS 设备的免费可下载 GPS 地图 - 基于免费地图网站 OpenStreetMap 的免费 GPS 地图。值得注意的是，该地图由私人开发、更新和分发，而非 Garmin。提供英文安装说明”）。

你会支持在英文 Wikivoyage 上也这样做吗？ויקיג'אנקי (talk) 2013年12月19日07:01 (UTC)[回复]

您可以在 OpenStreetMap wiki 的此页面上看到包含许多免费可下载开源 Garmin GPS 地图链接的列表。ויקיג'אנקי (talk) 2013年12月19日07:05 (UTC)[回复]

我赞成添加此类信息，但可能以更紧凑的格式？一个完整的章节有点大，也许在左侧栏中添加一个链接会更好？顺便说一句，链接页面只有德语版本有点可惜。它主要是针对国家文章的，对吗？数据文件通常是针对一个国家或大区域，而不是针对单个目的地。我没有 Garmin 设备，但我认为这个提示对于 Garmin 用户来说会非常有用！顺便说一句，OsmAnd 也提供可下载的地图（所有文件都可以在此处下载）。Nicolas1981 (talk) 2013年12月19日07:18 (UTC)[回复]

缺失的跨语言链接

显然，有些页面的语言链接出了问题：近期更改、特殊页面等。有人知道发生了什么吗？它们是 Wikidata 项目被撤销了还是怎么回事？Texugo (talk) 2013年12月19日10:35 (UTC)[回复]

“近期更改”项目现在应该恢复了。相关讨论请参见 d:Wikidata:Requests for comment/Interwiki links for special pages。——Rs chen 7754 2013年12月24日18:54 (UTC)[回复]

活动和节日日历

活动和节日日历页面已被忽略了一段时间。我想提议更改格式，但在我花大量时间（除非其他人愿意帮忙）之前，一些反馈会很有用。正在考虑使用这种格式，但将所有月份和主题页面合并到一个页面中。这种表格方法允许读者按月份、地点或主题进行排序。赞成还是反对？有什么改进建议吗？ --Traveler100 (talk) 2013年12月21日 13:13 (UTC)[回复]

维基的本质是无法保证你的作品在某个时候不会被删除（至少从公众视野中）。但是，我注意到了你在做的事情，我很欣赏。我认为，如果有足够的人员来维护（这是任何文章都可能出现的问题，但当节假日和节日日期每年都变化时，这个问题会更加严重），活动日历会很有用。我目前没有任何具体的建议，但我鼓励你继续大胆尝试。 Ikan Kekek (talk) 2013年12月21日 13:33 (UTC)[回复]

{编辑冲突}

初步想法

那将是一个巨大的表格，尤其是如果我们像需要的那样彻底填充它以使其全面。即使按大陆划分，表格也会非常笨拙。
它浪费了相当多的空白，描述越长，其他字段浪费的空间就越多。
图像字段，在使用时，极大地增加了其他字段中浪费的空间。
必须定义一组我们可以将所有内容分类的主题是成问题的。慕尼黑啤酒节在多大程度上是一个文化活动，在多大程度上是食物/饮料？圣保罗的日本节既是贸易展，也是文化博览会和美食节。德克萨斯州博览会是一个牲畜展，有嘉年华游乐设施和文化景点，也以其不寻常的油炸食品而闻名。许多其他事件也同样难以明确分类。

我很欣赏这次实验，但我尚未确信表格是解决方案。 Texugo (talk) 2013年12月21日 13:43 (UTC)[回复]

Texugo (talk) 2013年12月21日 13:43 (UTC)[回复]

另一个想法是使用活动列表模板。粗略示例如此处。这可以在活动页面和位置文章中使用。与当前使用的自由格式相比，其优点是过期活动可以很容易地识别（类别或机器人），以便更新。 --Traveler100 (talk) 2013年12月21日 15:34 (UTC)[回复]

由于活动日历页面很少受到关注，并且维护始终是一个问题，那么如何让它们自动从位置文章页面上的活动列表中编译呢？方法是在文章页面上有一个活动列表模板，它将有一个月份和类型参数，然后将该位置页面放置在活动类型和月份类别中。然后将这些类别的内容列在活动日历页面上。因此，贡献者只需将活动添加到位置文章中，活动日历将自动生成。--Traveler100 (talk) 2013年12月22日 10:21 (UTC)[回复]

我认为这是一个好主意。我建议某种重要性评级，例如：1 = 如果步行距离可达，则值得一去... 5 = 值得乘坐长途航班前往。这应该可以阻止世界杯在几十场乡村足球比赛中迷失。 AlasdairW (talk) 2013年12月22日 11:22 (UTC)[回复]

我一直在思考如何处理事件的不同重要性（本地或全球），这是一个好主意。 --Traveler100 (talk) 2013年12月22日 11:37 (UTC)[回复]

因此，有一种方法可以按类型、月份和国家组织事件，但列出的是文章，即地点、名称。例如，Dinagyang 节列在一月活动和文化活动下，但其位置是伊洛伊洛市，而不是事件名称。除非为该事件创建页面，例如索契2014，否则我看不到更好的方法来做到这一点，而不会使用户的输入过于复杂。 --Traveler100 (talk) 2013年12月22日 16:27 (UTC)[回复]

我很抱歉听起来过于苛刻，因为我在这方面没有提供任何更好的建议，但是创建 72 个新类别并将其划分为相当主观的 5 个类别听起来会需要更多的维护工作，而不是更少，而且这些类别页面永远不可能只是简单的目的地名称列表，需要点击每个目的地才能找出涉及哪些事件，这在我看来并不是用户友好性的改进。 Texugo (talk) 2013年12月23日 02:30 (UTC)[回复]

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

为什么不使用维基百科的链接，或者利用维基数据来获取大部分信息，而不是在这里重新创建所有信息，特别是对于像索契、世界杯等大型活动，它们包含了完整的日程表，对于整个维基导游来说，活动应该仅限于可以被主要页面收录的主要国际活动。然后，日历选项可以用于国家、地区、城市活动，通过包含日期作为类别，并通过机器人运行以删除过期活动（例如在活动发生7天后），维护将是可行的。 Gnangarra (talk) 2013年12月25日 01:35 (UTC)[回复]

创建了{{Event}}，可以在日历页面和位置文章中使用。它提供了一个标准格式，这对于维护很有用（创建包含过期事件的类别）。它还创建了按类型、日期和位置分类的隐藏类别，可以用于查看哪些内容可以更新页面。这类似于列表模板，如果这个实验成功，可以考虑合并这些功能。 --Traveler100 (talk) 2013年12月26日 12:35 (UTC)[回复]

我希望在对这个问题进行更彻底的评估和讨论之前，停止创建更多类别。我看到的是大量创建“XXX 中的事件”类别。目前为止，一月、二月等页面最终将属于数百个此类类别（它们已经有了相当多的类别），这并没有多大意义。此外，这种方法基本上开始在“事件”类别中重新创建整个地理层次结构，而这正是我们最近在主题文章中放弃的做法。 Texugo (talk) 2013年12月26日 16:31 (UTC)[回复]

这些类别并非面向读者，其目的是作为将活动和节日日历的月份页面提升到可用水平的基础。但坦率地说，在浏览这些页面后，我正在考虑也许它们应该直接被删除。很明显，没有人长时间更新它们，阅读起来毫无用处。维护这些页面是一项大量的工作，但似乎没有人感兴趣。建议将所有内容移动到适当的位置页面并使用事件模板（如果需要，可以关闭类别），这样我们至少可以轻松地保持它们最新（模板有一个检查类别）。 --Traveler100 (talk) 2013年12月28日 18:39 (UTC)[回复]

将 Mapframe 复制到其他语言的 Wikivoyage

我将Mapframe和PoiMap2复制到了荷兰语 Wikivoyage。但是，我认为要使其正常工作，需要做更多的事情。我没有得到地图，只有地图下方打开全屏版地图的链接。我没有收到任何错误消息，所以我不知道缺少什么。有人能帮我吗？ --FredTC (talk) 2013年12月22日 10:17 (UTC)[回复]

可能MediaWiki:命名空间下的站点范围的Javascript或CSS有变化？ K7L (talk) 2013年12月23日 05:10 (UTC)[回复]

感谢您的回复。您能告诉我如何访问 Javascript 和 CSS 吗？这样我就可以比较两种语言的版本了。 --FredTC (talk) 2013年12月23日 09:35 (UTC)[回复]

MediaWiki:Gadget-MapFrame.js --Adehertogh (talk) 2013年12月23日 11:47 (UTC)[回复]

可能是一个不同的问题，但在英文维基导游上，地图也经常不显示。刷新（F5）通常可以解决问题。 Nicolas1981 (talk) 2013年12月24日 04:28 (UTC)[回复]

我从未遇到过英文维基导游的这种问题。但是，我在IE和Mozilla上都在荷兰语维基导游尝试了F5，但都没有出现地图。所以我认为我必须在JS和CSS文件中找到问题的解决方案。 --FredTC (talk) 2013年12月24日 05:38 (UTC)[回复]

请参考模板:Mapframe的文档（代码段落：与小工具配合使用：Mediawiki:Gadget-MapFrame.js。如果小工具被禁用，用户将只看到一个链接到全屏动态地图的标题。使用HTML5数据参数将变量传递给iframe，需要高级POST查询以进一步影响iframe。）。也许这就是解决方案？ -- Joachim Mey2008 (talk) 2013年12月24日 06:56 (UTC)[回复]

圣诞快乐

愿这一天带给你健康和成功。愿你和你的家人体验上帝的慈爱拥抱，愿你的假期充满爱、喜悦与和平。祝大家圣诞快乐！ --Saqib (talk) 2013年12月25日 14:06 (UTC)[回复]

也祝你圣诞快乐，Saqib。 -- AndreCarrotflower (talk) 2013年12月25日 18:56 (UTC)[回复]

谢谢！我也祝你和这里的所有人圣诞快乐！也祝新年快乐，成功，没有仇恨者/喷子！ (哦，天哪...) ϒpsilon (talk) 2013年12月26日 09:32 (UTC)[回复]

谢谢 Saqib！也祝这里的每个人圣诞快乐！ :) --Nick ^talk 2013年12月26日 12:13 (UTC)[回复]

1984 还是 2014？

我们自己也有一些管理员不必要地干预其他用户的用户空间的问题，但通常更容易发现邻居眼中的梁木：在移除 Evan 的管理员权限后不久，Wikitravel 的 IBobi 再次改写历史。 --118.93nzp (talk) 2013年12月30日 21:57 (UTC)[回复]