跳转至内容

Wikivoyage:删除投票/2014年2月

添加链接
来自维客旅行
← 2014年1月 删除投票存档 2014年2月 (当前) 2014年3月 →

托迪亚日历实验

这是一个自11月初以来就被放弃的实验。我认为现在我们已经充分证明，任何改善我们列出活动的方式的尝试，都不会通过为每个目的地文章创建暗示的额外13个页面来实现。

已完成。 Texugo (讨论) 17:02, 2014年1月31日 (UTC)[回复]
本可以有一个直接的讨论链接 Gnangarra (讨论) 00:12, 2014年2月1日 (UTC)[回复]
  • 删除，理由同Texugo的提名（或移动到Gnangarra的用户空间）。 --118.93nzp (讨论) 17:28, 2014年1月31日 (UTC)[回复]
  • 页面并未被放弃，只是没有更新内容而已。一月的条目对于2015年来说是正确的。这一切花费了我不少精力，最初对新用户的处理给一个更大的项目带来了阻碍。我已经投入了更多的时间和资源，但如果你们不想要新用户，请现在就告诉我，我不希望再次遭遇上次维基媒体研讨会那样的不友好的欢迎。正如在酒吧里讨论过的，我以为月度条目在12月就会被删除。我希望你们保留 Calendar of events and festivals in Toodyay。 Gnangarra (讨论) 00:12, 2014年2月1日 (UTC)[回复]
有5个主要活动，为什么不能将它们全部添加为“游玩”部分的子章节？我认为在那里会有更多人看到它们。其中一些“活动”，例如耶稣受难日，似乎根本不是活动。我只列出有活动可参与的假日和节日。例如，圣诞节期间镇上是否有令人兴奋的活动？如果没有，就不需要列在城镇条目中。 ChubbyWimbus (讨论) 12:30, 2014年2月2日 (UTC)[回复]
Gnangarra，毫无疑问，这些页面不符合条目的当前定义，并且通常会面临无争议的删除——这些页面得以保存的唯一方式是改变我们的整体政策以允许这种事情发生在所有条目中。这就是为什么它最初被标记为实验性——让你有机会发展它并试图达成共识，以适应你的提议。目前，鉴于有足够的时间进行实验和讨论，并且几个月来没有任何发展工作或讨论发生，唯一需要回答的问题是：“这个实验是否正在朝着允许为我们拥有的每个目的地文章创建一到多个独立活动页面的共识发展？”目前的答案非常明确地是“否”，老实说，我怀疑这个特定的方法将来是否有很大的希望获得共识。虽然我赞赏你尝试改进事物的积极性，但我认为现在是时候认识到这种方法可能永远不会获得它所需的足够支持来变得合法。也许你可以尝试一种不涉及大规模页面创建的方法，我不知道。但我确实希望你能理解，你的提议未能获得共识并不意味着我们不友好或不感激你的努力。我们很多人过去都提出过失败的提议。这只是维基社区过程的一部分。我确实希望你能继续留下来并继续贡献。 Texugo (讨论) 12:09, 2014年2月3日 (UTC)[回复]
  • 评论 - 这个日历实验对于一个足够大的城市，拥有更多更大的活动，可能会更成功（例如 巴黎、纽约、新加坡 或许还有 珀斯）。 ϒpsilon (讨论) 12:14, 2014年2月3日 (UTC)[回复]
  • 评论：一个日历对于一个国家或大区域是有意义的，也许 英格兰年度节日和活动 是可行的，而 南安普顿年度节日和活动 则可以合并到 南安普顿#游玩。另一种选择是为国际级别、覆盖整个世界但仅限于特定主题的活动（例如奥运会和世界杯）创建一个日历。在城市级别，(城市)->“游玩”-“活动”通常是一个子章节，而不是一个独立的条目。 K7L (讨论) 21:47, 2014年2月3日 (UTC)[回复]
  • 移动到用户空间。创建此活动日历的用户似乎想保留它，所以我们将其移动到他的用户空间。正如Texugo指出的，几个月后，这看起来并没有比将活动列表直接放在条目中有所改进，因此实验现在应该移出主空间。 -- Ryan • (讨论) • 22:20, 2014年2月3日 (UTC)[回复]
  • 移动到用户空间，并允许将其他少数几个活动（除了5个主要活动外）合并到城镇条目中。 Gnangarra，你非常受欢迎，我们对活动信息很满意。独立的文章是一个实验，在这种情况下，似乎没有必要将信息与托迪亚文章的其他部分分开。我甚至不认为这是不可能的（对我来说，只要有共识，一切皆有可能，即使它不是我们通常做事的方式 ;-）），但在这种情况下，没有明显的好处。作为经验法则，我们只在条目变得过于拥挤时才创建子页面。例如，我们只在城镇条目信息过多时才创建地区，而独立的日历只有在“游玩”部分有大量活动时才可能被讨论。但这不应该阻止你在 托迪亚 文章中维护活动日程。Chubbywimbus说得对：在那里它们会获得更多关注 :-) JuliasTravels (讨论) 22:37, 2014年2月3日 (UTC)[回复]


结果：由于用户没有复制或要求移动到用户空间，因此已删除。 Texugo (讨论) 12:50, 2014年2月13日 (UTC)[回复]

相关模板

这些模板似乎依赖于上述创建“月 in 城市”格式的额外页面的提议，因此应该遭受同样的命运。 Texugo (讨论) 11:35, 2014年2月4日 (UTC)[回复]

结果：已删除。 Texugo (讨论) 12:50, 2014年2月13日 (UTC)[回复]

仅包含斋浦尔的堡垒和宫殿的信息，而斋浦尔的条目已经对这些地方有合理的介绍，并且/或者其中一些信息已被合并。这个主题过于宽泛，无法成为一个旅行主题——它似乎包括了字面上成千上万个地点，从凡尔赛宫、托普卡帕宫、日本皇宫到无数的殖民地防御工事、两次世界大战的炮台以及印度山地度假堡垒。没有一个特别好的地方可以重定向到这里，也没有明显的理由将这两个词连在一起搜索，因此它也不是一个特别可能的搜索词。还请参见 Talk:Forts and palaces 中的一些先前讨论。

  • 删除 或 移动然后合并和重定向 或完全重写。我能看出一个描述此类主要建筑的建筑技术、选址等文章的价值。可能排除那些在过去150年内建造的，有足够共同之处可以构成一个单一主题，但任何对具体建筑物的提及都应该只是为了说明观点（例如，“有些堡垒和宫殿位于湖中心…”），并且应在全球范围内选择例子。 AlasdairW (讨论) 15:34, 2014年1月31日 (UTC)[回复]
世界各地不同文化和时代的堡垒的各种不同的建筑技术？再加上世界各地不同文化和时代的宫殿的各种不同的建筑技术和风格？这实在太多了，你不觉得吗？更不用说，堡垒和宫殿之间没有什么可以说普遍适用的内容—它们在目的、设计、风格或建筑技术方面没有太多共同之处。堡垒和宫殿最初被放在这个标题下，仅仅是因为这是斋浦尔恰好可以参观的两种事物。这实际上不是一个比“教堂和浴场”或“法院和书店”或“博物馆和码头”更合乎逻辑的组合。 Texugo (讨论) 16:27, 2014年1月31日 (UTC)[回复]
我确实看到堡垒和宫殿之间存在一些联系。欧洲许多较大的城堡在同一时间或不同时间都曾执行过这两种功能。例如，在 斯特灵城堡，你可以看到一个宫殿、防御工事和一个军事博物馆。“博物馆和图书馆”或“音乐商店和书店”是类似的组合——我不会用它们来开始一个条目，但我能理解其中的逻辑。 AlasdairW (讨论) 11:57, 2014年2月1日 (UTC)[回复]
根据下面的讨论，我喜欢“移动然后合并并重定向”的想法，并已将其添加到我先前的发言中。 AlasdairW (讨论) 21:18, 2014年2月3日 (UTC)[回复]
评论：这是一个极其宽泛的列表，其中主题之间似乎没有什么共同之处，有时甚至仅仅是勉强称得上是文化景点。也许它本身也应该接受一次Vfd。 Ikan Kekek (讨论) 19:12, 2014年1月31日 (UTC)[回复]
重定向不会带来巨大的改变，但我认为人们同时搜索“堡垒和宫殿”的可能性微乎其微，如果不是零的话；肯定不会比我上面建议的任何其他随机景点组合的可能性大。如果它只是 堡垒 或只是 宫殿，那么重定向可能有点意义，但我只是看不到保留这个特定组合的任何好处。这将意味着我们接受几十个类似的重定向，比如 宫殿和堡垒、宫殿和城堡、城堡和宫殿、城堡和教堂、教堂和堡垒，等等…… Texugo (讨论) 19:24, 2014年1月31日 (UTC)[回复]
我对此并没有强烈的意见，只是提出了重定向作为一种可能的快速解决方案。Ikan，关于你的担忧，文化景点是 旅行主题页面的顶层分组，除非我们更新旅行主题的组织方式，否则不应该删除。 -- Ryan • (讨论) • 19:58, 2014年1月31日 (UTC)[回复]
也许 1812年战争 或 欧洲第二次世界大战 的范围适合关于堡垒的条目？ 特兰西瓦尼亚#城堡和堡垒 与 导弹发射井国家历史遗址 是非常不同的主题，因为时间跨度。 K7L (讨论) 15:56, 2014年2月2日 (UTC)[回复]
K7l说得有道理，所以我划掉了我之前的“删除”发言。 Pashley (讨论) 14:27, 2014年2月2日 (UTC)[回复]
  • 合并到新条目以重定向到斋浦尔进行归属，然后删除。关于X国的城堡和堡垒的文章很有趣，但在同一个城市内，我认为城市条目就足够了。为了归属目的，将其合并到Jaipur/Forts and Palaces（如上所述）并重定向到斋浦尔是可行的。在此之后，这个“堡垒和宫殿”的文章应该被删除。没有一个合适的地方可以重定向这样的文章。 ChubbyWimbus (讨论) 06:07, 2014年2月3日 (UTC)[回复]
我认为 K7L 和 ChubbyWimbus 找到了最好的解决方案。移动到 Jaipur/Forts and palaces，然后重定向到 斋浦尔（我认为已经完成的合并足够了）。然后删除此条目。 Texugo (讨论) 19:03, 2014年2月4日 (UTC)[回复]

结果：已将 Jaipur/Forts and palaces 移动（不带重定向），然后从那里重定向到 斋浦尔，用于归属目的。 Texugo (讨论) 12:50, 2014年2月13日 (UTC)[回复]


中文维基旅程已启动。--GZWDer (讨论) 11:16, 2014年1月27日 (UTC)[回复]

重定向到维基。 --Rschen7754 18:37, 2014年1月27日 (UTC)[回复]
是的，显而易见的解决方案。 Ikan Kekek (讨论) 18:36, 2014年1月29日 (UTC)[回复]
可以重定向到另一个维基吗？ Powers (讨论) 01:51, 2014年1月30日 (UTC)[回复]
当然。为什么不能呢？ Ikan Kekek (讨论) 02:32, 2014年1月30日 (UTC)[回复]
嗯，那将是一个软重定向。 --Rschen7754 03:40, 2014年1月30日 (UTC)[回复]
重定向 Pashley (讨论) 14:23, 2014年2月1日 (UTC)[回复]

结果 - 已软重定向。 Texugo (讨论) 11:11, 2014年2月14日 (UTC)[回复]

删除。无需（参见 Template talk:Learn 中的讨论）。 Ikan Kekek (讨论) 18:34, 2014年1月28日 (UTC)[回复]

这是第三次讨论。正如我在 Wikivoyage talk:使用 MediaWiki 模板#Learn 模板 中所说，该模板可以重定向到 Template:Listing，这a) 避免了替换现有使用，b) 允许不熟悉该模板的编辑者使用“learn”作为模板名称，而无需实际实现（并保持更新）该模板，以及c) 阻止了未来创建该模板的任何尝试。 Powers (讨论) 20:11, 2014年1月28日 (UTC)[回复]
这对我来说没问题，而且有道理。抱歉我没有在头两个地方看到你的相关评论。 Ikan Kekek (讨论) 20:38, 2014年1月28日 (UTC)[回复]
我的错。我已经在通用模板讨论页面提出了这个问题。同意重定向到 Template:Listing。Andrewssi2 (讨论) 2014年1月28日 23:43 (UTC)[回复]
重定向 Pashley (讨论) 2014年2月1日 14:24 (UTC)[回复]

结果：重定向至 Template:Listing。Texugo (讨论) 2014年2月14日 11:11 (UTC)[回复]

两个有些关联的模板，但目的不明，由 IP 用户 62.2.80.246 在一年多前引入，并且完全没有使用。

结果：已删除 - Texugo (讨论) 2014年2月17日 11:45 (UTC)[回复]

由 User:Globe-trotter 于去年七月引入，目前未在任何地方使用。过去使用时，通常会被遗忘，在编辑频繁期过后很久仍然存在 - 我自己似乎不止一次遇到过这种情况。鉴于其存在并不一定意味着正在进行编辑，我认为这个模板的用处不大。此外，这个文本对我们所有的文章来说技术上都是成立的，因为一切都处于持续编辑和改进的状态。

结果：已删除 - Texugo (讨论) 2014年2月17日 11:45 (UTC)[回复]

由 IP 用户 150.101.89.130 于一周前创建，目的不明，可能与提供 WP 风格的来源有关，而我们无论如何都不需要这些。它只被使用过一次，在 2006 年的评论 中被插入到 Evan 的一段评论中，并产生了一个相当大的错误消息。

结果：已删除 - Texugo (讨论) 2014年2月17日 11:45 (UTC)[回复]

Tab 模板

创建于 5 个月前，仅在一个用户页面 User:Jmh649/M1 上使用。目的不明。

结果：已删除 - Texugo (讨论) 2014年2月17日 11:45 (UTC)[回复]

自 2013 年 1 月起进行实验性使用，该模板仅在 4 篇文章中重复相同的 3 句话。信息本身是全年和国家范围的，因此其完整细节应放在国家文章中。我认为这种情况与 Template:Schengen 的情况无法充分相比，这是我们唯一使用样板文本的先例 - 在那种情况下，信息在其应有的位置篇幅更长、更复杂，并且恰好对所有使用它的国家都相同，而在本例中，信息简短且不复杂，而且城市文章本身就不适合包含国家现象的完整细节。虽然在某些城市文章中快速链接到国家文章的详细信息是可以的，但我并不认为在每篇文章中重复所有细节都值得，即使重复了，在 4 篇文章之间保持 逐字 相同也可能是有利的。保留它将意味着我们同意将样板化的方法用于将其他国家信息插入到次国家文章中，这违背了我们关于信息应归属何处的常规指南，并且相当违反了保持写作生动且避免不必要重复的原则。

  • 保留 并将其插入到荷兰各地城市的“见”部分；将信息放在感兴趣的读者最有可能看到的地方。将其制成信息框，以免干扰生动的写作，并且更容易被不关心的读者忽略。Pashley (讨论) 2014年2月5日 00:58 (UTC)[回复]
所以你对我们不厌其烦地在多个次级文章中重复国家信息的一般性指导原则说“去他的”吗？Texugo (讨论) 2014年2月5日 10:08 (UTC)[回复]
  • 评论：我多次对这个模板表示怀疑。我没有添加它，因为它还在实验阶段（所以不应该把仅有的 4 篇文章作为论据，我认为我们故意不把实验性内容添加到太多文章中）。正反两方面都有道理。原则上我同意“把一般信息放在国家文章里”。但在实践中，成千上万的城市游客不会去阅读整个荷兰国家文章——尤其是文化部分等。所以，在“独立目的地”中重复这些信息是有意义的，就像我们对大城市与地区的气候信息所做的那样。如果需要，另一种解决方案是将信息外部链接，或者链接到国家文章的某个部分，但这样的话，用户只需少点击一次。我都可以 :-)JuliasTravels (讨论) 2014年2月5日 10:24 (UTC)[回复]
我的担忧是它会成为一个先例。难道不能用同样的理由，“人们可能不会读 x”，把样板化的欧洲铁路信息放到几十个城市文章里吗？在每个美国城市文章中都加上“紧急电话：911”？我想说的是，为什么不把详细信息（价格、工作原理等）放在国家文章中，然后从主要的博物馆城市，只放一个链接“另见 xxx”。这是标准的做法。为什么这个案例会不同到我们需要把它逐字地放在每篇相关的城市文章里呢？Texugo (讨论) 2014年2月5日 10:47 (UTC)[回复]
是的，我认为我同意。但这真的是标准做法吗？气候和交通信息不是这样的。无数的城市文章或多或少地重复了其（低级别）地区也有的机场信息。我只是想说，这更多是一个普遍的困境，而不是仅限于这个模板。 JuliasTravels (讨论) 2014年2月5日 12:22 (UTC)[回复]
地区文章不应也不通常不包含位于城市中的机场的全部详细信息。其他依赖于其他城市机场的地区城市也是如此。它们应该（也通常会）提供简要概述，并指向详细信息的所在地，无论是机场所在的城市文章，还是独立的机场文章。Texugo (讨论) 2014年2月5日 12:32 (UTC)[回复]
我强烈认为，凡是适用该卡的博物馆（至少在“见”部分）都应该提及它。模板似乎是显而易见的方法。模板文字应该详细描述卡片，还是仅仅链接到国家文章中的某个地方，或者介于两者之间？留给工作的人决定。Pashley (讨论) 2014年2月17日 17:09 (UTC)[回复]
什么使得这种情况成为一个特殊的例外，可以违反标准常识，而是逐字重复文本而不是将读者指向适当的地方获取详细信息？如果这是样板文本的情况，那么肯定有数百万类似情况也符合条件。将详细信息放在国家文章中，然后我们只需要为每个相关的博物馆写 接受 [[Netherlands#Museumkaart|Museumkaart]]。我们不需要一个专门的模板来做这样的维基链接。Texugo (讨论) 2014年2月17日 17:16 (UTC)[回复]
维基链接似乎是个更好的主意，并且足够了。可惜 Globetrotter 不在（因为是他创建的模板），但在没有任何令人信服的反对 Texugo 解决方案的论据的情况下，我也支持删除。JuliasTravels (讨论) 2014年2月17日 17:58 (UTC)[回复]

结果：已删除 --AndreCarrotflower (讨论) 2014年2月21日 04:07 (UTC)[回复]

结果：已删除 - Texugo (讨论) 2014年2月27日 11:23 (UTC)[回复]

标记为“全景自由”下的使用权，但这显然不是全景的附带物。这是一张精心裁剪的、据推测有版权的二维地图照片，应该像过去许多其他照片一样被删除。来自书籍、宣传册和标牌的地图照片和从其他网站复制的一样不可接受 - 仅仅因为你拍了照片并不意味着我们就能神奇地获得使用它的权利。

问题：我们知道这张地图是公开张贴的，是受版权保护的图像吗？Ikan Kekek (讨论) 2014年2月14日 12:32 (UTC)[回复]
我认为更相关的问题是，我们是否确定它不是？上传者的声明表明它是受版权保护的，但在全景自由下使用。Texugo (讨论) 2014年2月14日 13:39 (UTC)[回复]

我对此有些困惑，但我想我不是唯一一个。让我提出几点。

  1. “全景自由”不是最好的术语；它是德语法律术语的翻译，但它是我们能找到的最好的，也是 Commons 使用的，但只是因为没有更好的术语。因此，我们不应该过多地解读“全景”这个词。Commons 理解的全景自由适用于许多不是全景或城市景观的图像。它适用于在公共场所（通常是户外）拍摄的任何受版权保护的作品的照片。
  2. 不同国家对全景自由的规定不同。例如，印度法律允许拍摄受版权保护的建筑和雕塑，但不允许拍摄受版权保护的二维作品，如地图。
  3. 全景自由不是对合理使用的辩护。它与合理使用无关。利用全景自由法律的照片可能只是忽略主体作品的版权，以确定照片的版权。
  4. 这里可能存在与九牛一毛原则的混淆，该原则也与合理使用无关。就我们而言，九牛一毛原则是说，如果受版权保护的作品是照片的附带物，那么照片不侵犯版权。一个例子是男孩穿着米老鼠 T 恤的照片；除非照片放大米老鼠或以其他方式使米老鼠成为图像的焦点，否则照片不会侵犯迪士尼（或其被许可方）的版权。

根据以上几点，我可以得出关于这张图片的以下结论：

  1. 上传者在将“全景自由”应用于此图像时是错误的，因为二维地图在印度不受全景自由例外条款的约束。
  2. 上传者应该为该图像应用非自由图像模板，因为该图像是衍生作品。MGA73bot 晚些时候处理了这个问题，但仅因为所有本地上传的图像都被假定为非自由文件（因为自由文件应上传到 Commons）。即便如此，模板也没有指定图像要使用的文章，这违反了政策。
  3. 该图像在两个方面违反了我们的Wikivoyage:Non-free content政策：
    • 该图像未在任何文章中使用。
    • 该图像可以被另一张免费图像替换，该图像显示的信息基本相同。

因此，该图像应被删除，因为我看不到在我们的政策下保留它的任何方法。顺便说一句，我认为允许机器人添加非自由模板可能是一个错误，因为它掩盖了这种图像从未在非自由使用下合理的情况。-- Powers ((讨论)) 2014年2月14日 19:04 (UTC)[回复]

附注：此图像先前在Wikivoyage talk:Image policy#Images under the Exemption Policy 中讨论过，但似乎没有人跟进具体案例。然而，那次讨论促使我向我们的 EDP 提出了一项更改建议，但从未有人评论过，并且尚未进行更改。我相信这项更改对于使我们的 EDP 符合基金会的决议是必要的。Powers ((讨论)) 2014年2月14日 19:12 (UTC)[回复]
很有趣。我当时长时间在休假，错过了很多事情。我已添加了对你提议的支持。Texugo (讨论) 2014年2月14日 19:16 (UTC)[回复]

结果 ：已删除。Texugo (讨论) 2014年2月28日 12:54 (UTC)[回复]

只使用过一次，在一个 WT 用户页面上，该用户于 2008 年停止编辑，并且从未在 WV 上编辑过。如果我们确实想拥有一个国家来源的用户框，应该创建一个单一的模板并使用开关，而不是为每个国家创建一个单独的模板。

既然我们通常不允许用户随意创建用户模板，最多这应该是一个应该被考虑为实验性的模板，并且早就应该被删除，就像过去所有同类模板一样。“是否造成任何伤害？”不是模板的有效标准，因为为了可用性，我们一直致力于将它们保持在最低限度。模板应该通过一个实验过程并获得共识，然后才能发布。 Texugo (讨论) 2014年2月17日 11:52 (UTC)[回复]
评论：这个“实验”过程似乎由以下步骤组成：模板化带有“不要使用此模板，因为它处于实验阶段”的模板，然后，当没有人使用它们时，提名它们删除。我们已经容忍了对内容页面模板采取这种限制性方法，以便文章都遵循相同的通用格式（吃，喝，睡，开心...），但没有必要让每个用户页都看起来一样。模板的命运应该根据其自身的优点来单独决定。K7L (讨论) 2014年2月17日 15:39 (UTC)[回复]
这是一个应该在别处讨论的政策问题。Texugo (讨论) 2014年2月17日 17:08 (UTC)[回复]
我们可以简单地将其替换到该用户页面上，作为一种礼貌。Texugo (讨论) 2014年2月18日 16:02 (UTC)[回复]

结果 ：已替换到该用户页面，然后删除。Texugo (讨论) 2014年2月28日 12:54 (UTC)[回复]

取自“https://wikivoyage.cn/w/index.php?title=Wikivoyage:Votes_for_deletion/February_2014&oldid=4924704”
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.