跳转至内容

Wikivoyage:脚本提名/存档

来自维客旅行
 这是一个过去讨论的存档。请勿编辑本页内容。如果您希望发起新的讨论或重提旧的讨论，请在当前的讨论页进行。

以下脚本已通过Project:脚本提名。

Kunibotto

(WT-ja) Kunibotto 将用于自动上传所有国家的 CIA 旗帜、地图和条目存根到日文维基导游。Pywikipediabot 的 upload.py 将被使用。这是一次性运行，但我预计之后会使用此变体来输入日本的大量数据。(WT-en) Jpatokal 09:57, 2005年7月14日 (EDT)

我投赞成票。也就是说，也许我们应该设置图像可以在不同语言版本之间共享的功能…… -- (WT-en) Mark 10:47, 2005年7月14日 (EDT)
维基导游共享计划？我完全支持，现在就去找硬件、软件和维护者…… (WT-en) Jpatokal 13:27, 2005年7月15日 (EDT)
嗯？我们为什么不直接把它托管在 wikivoyage.org 服务器上，使用与维基导游相同的软件和技术呢？MediaWiki 1.4.x 对媒体共享有很多支持。--(WT-en) Evan 13:30, 2005年7月15日 (EDT)
你告诉我，老板，这又不是第一次有人提议了！(WT-en) Jpatokal 13:47, 2005年7月15日 (EDT)
那么答案是没有理由。我一直在查看 MediaWiki 共享系统代码，我认为构建它将是一件相当简单的事情，甚至无需关闭正在运行的服务器。--(WT-en) Evan 13:52, 2005年7月15日 (EDT)
是的，但请遵循政策。缓慢更新，使用标志打开/关闭机器人等。我认为这并不难，而且对维基导游服务器来说也更容易。停止有错误的机器人并清理它也更容易。谢谢。--(WT-en) Evan 13:34, 2005年7月15日 (EDT)
上传每分钟进行一次，这符合政策，不是吗？标志双重检查只会增加负载，尽管我承认我太懒惰而没有实现它的真正原因是，我对 Python 不太熟悉，需要花一两个小时仔细研究 pywikipediabot 未注释的内部结构，才能弄清楚如何做到这一点。但我会故意作恶，让标志上传器先运行完，数据集定义得足够好，以至于失控的风险相当小。(WT-en) Jpatokal 13:47, 2005年7月15日 (EDT)
请不要养成这种习惯。您、我或任何其他管理员都不能凌驾于维基导游的政策和准则之上。事实上，我们有责任树立一个好榜样。
如果您想更改政策，让我们在Project:脚本政策上解决。如果您懒得更改脚本以适应本地要求，或者您根本没有足够的代码经验来这样做，那么您可能根本不应该运行该脚本。我很乐意帮助更改 pywikipediabot 以使框架与双重检查配合使用。--(WT-en) Evan 15:32, 2005年7月17日 (EDT)
作为记录，Kunibotto 现在已经清理了它的行为，并像一个好机器人一样尽职地检查运行页面。(WT-en) Jpatokal 06:38, 2005年8月2日 (EDT)

所以为了记录在案，Kunibotto 现在正在进行最后一次运行（？），将所有 CIA 旗帜和地图上传到维基导游共享。每 60 多秒上传一次，所以它将花费一天的大部分时间…… (WT-en) Jpatokal 01:45, 2006年5月7日 (EDT)

SpellingScript

我想创建一个自动拼写更正脚本。它将使用拼写维护页面来查找常见拼写错误列表中列出拼写错误的页面，然后更改这些页面以使用正确的拼写。它不会更改 a) 任何大写内容（可能是专有名词）b) 短语手册中外语部分的内容，c) 任何斜体字（可能是外语词），和 d) 任何从特殊页面链接的页面（也许是User:(WT-en) SpellingScript/Ignore），以便人们可以覆盖它。这将提高网站的可读性和明显质量，并减少用户繁琐的任务之一。该脚本可能会从维基导游服务器上的 cron 作业运行——可能每天一次。注意：此脚本尚未编写。--(WT-en) Evan 19:24, 2004年1月10日 (EST)

我附议提名。-- (WT-en) Mark 09:50, 2004年2月6日 (EST)
我三次提名。值得一试。-(WT-en) phma 21:44, 2004年2月17日 (EST)

Wechselbot

这个脚本将读取页面列表和货币列表，然后编辑每个页面，寻找标记数字为汇率的注释，然后更新汇率。这将提高网站的实用性（访问任何国家页面并获取当前汇率），而不会给任何人带来更新的负担。该脚本可以在我的笔记本电脑上每天或每周运行一次。这个脚本还没有写好，但我确实有一个 shell 脚本可以获取任何其他货币兑美元的汇率。-(WT-en) phma 21:44, 2004年2月17日 (EST)

听起来是个有趣的主意。基础货币是什么？美元？既然我住在瑞士，我想我必须投票给瑞士法郎……当然，Evan 和 MAJ 在加拿大，所以他们可能有不同的看法…… ;) 真的，如果所有脚本只是在底部放置 Xcurrency = USD，那可能就没问题了，特别是如果它总是被标记为小编辑。-- (WT-en) Mark 01:35, 2004年2月23日 (EST)
评论看起来像<!--wb:chf/cad-->。基础是美元，因为 finance.yahoo.com 使用它作为基础；在收集所有汇率后，机器人根据需要计算比率。-(WT-en) phma 08:01, 2004年2月23日 (EST)
好的，为了确保我理解正确，这个脚本会寻找上述注释之后（或之前？）的数字。听起来你还想为每种货币设置一个汇率页面，我们可以从使用该货币的地方的页面链接到它。所以机器人不会到处寻找这些标签，对吧？如果是这样，我认为这是一个很棒的主意！-- (WT-en) Mark 09:58, 2004年2月23日 (EST)

Wechselbot 将

  1. 从页面读取货币代码列表。
  2. 从 finance.yahoo.com 获取当前汇率。这需要一次网络访问；这就是为什么我希望它首先读取列表。
  3. 读取要编辑的页面列表。
  4. 读取页面，查找数字后面的注释，并将数字更改为当前汇率。
  5. 重复直到完成所有页面。

注释还可以包含有效数字的数量和数字零的 Unicode 偏移量（以防在印地语、阿拉伯语或泰语维基导游中我们希望以本地文字书写数字）。-(WT-en) phma 15:45, 2004年2月23日 (EST)

迟到总比没有好，但你确实得到了答案——据我所知，这绝不是一个坏主意。我考虑得更深入一步：由于我使用的是欧元，美元金额让我对价值有一个概念，但如果我想知道准确金额，我仍然必须手动转换。如何设置我的用户偏好，以便我希望以欧元为基础？你可以将你的偏好设置为美元，其他人可能会将其设置为英镑等。当然，这将涉及对代码进行更改。(WT-en) DhDh 17:02, 2004年3月5日 (EST)
如果我理解正确，任意值（例如 Györ 到 Debrecen 的匈牙利福林票价）将前面带有一个标签，说明它是某种货币 (HUF)，然后 PHP 脚本将根据您的偏好以 EUR、GBP、USD、AUD、CAD、ZAR 或 NZD 显示它。（匿名用户和没有偏好的人将获得福林货币。）这将需要一个汇率表。该表可以通过之前描述的机器人维护；PHP 脚本必须知道它在哪里。对代码的任何更改都需要 Evan 参与。-(WT-en) phma 19:24, 2004年3月5日 (EST)
我的意思确实是这样。但在你的例子中，匈牙利福林金额不会消失。你所选货币的金额会加进去。像这样：
  • 无偏好/匿名：456 HUF
  • 偏好 = EUR：456 HUF (45 EUR)
  • 偏好 = USD：456 HUF (56 USD)
（我不知道匈牙利福林汇率...）(WT-en) DhDh 19:51, 2004年3月5日 (EST)
在我看来，最初的想法并不是在实际目的地页面上进行自动转换，而是创建特殊的转换表页面，旅行者可以打印出来随身携带。坦率地说，我根本不喜欢这种脚本篡改目的地页面价格的想法，原因有几个。
  • 一个 bug 会造成更大的损害，有人必须花时间清理。
  • 在实际目的地，价格将以当地货币列出，所以它们也应该以这种方式列在目的地页面上。
  • 一直用脚本更改所有页面，会让Special:RecentChanges变得一团糟。
  • 如上所述，为用户自己的当地货币设置用户偏好会使该功能更好地工作，但可能需要对 MediaWiki 软件进行一些深入的修改，而处理有限货币表页面的简单脚本会快得多。
另一方面，我完全支持用脚本创建一套货币转换页面的想法，尽管货币不是目的地。也许(WT-en) phma应该在他的工作区创建一个演示页面，向我们展示他的想法。-- (WT-en) Mark 14:22, 2004年3月6日 (EST)
我可以为 Wechselbot 创建一个用户页面并开始编写脚本吗？-(WT-en) phma 17:44, 2004年3月7日 (EST)
当然可以。当然，最安全的做法（恕我直言）是在你自己的命名空间中进行。例如，你可以创建一些页面，比如：User:(WT-en) PierreAbbat/Wechselbot 来玩玩。话虽如此，如果你认为脚本需要自己的登录，那么好吧，去做吧（恕我直言）-- (WT-en) Mark 18:20, 2004年3月7日 (EST)
脚本需要登录；这是脚本策略所要求的。-(WT-en) phma
我不会 PHP，但我不确定我的想法是否需要大量修改。该功能应该能够在二维查找表（文章中使用的货币和您的偏好中的货币）中搜索货币，并将相应的值显示到您的屏幕上。如果我错了，懂 PHP 的人应该纠正我。(WT-en) DhDh 03:14, 2004年3月7日 (EST)

脚本写好后，我可以把它上传到 arch 服务器，以便其他人可以以此为基础编写自己的脚本吗？-(WT-en) phma 22:57, 2004年3月7日 (EST)

W66InterwikiBot

根据对World66跨语言链接的请求，我希望运行一个机器人来启动这个过程。由于他们的文件名不规则并使用层次结构（即/texas/paris和/france/paris），它将进行一些模糊匹配/猜测，但我将首先从简单/精确的匹配开始（我已经完成了大约2k）。我将在一个(WT-en) 沙盒中设置示例。(WT-en) Majnoona 14:26, 2006年7月1日 (EDT)

机器人，她已经准备好运行了。我今晚会先做一些小批量处理。(WT-en) Majnoona 17:26, 2006年7月19日 (EDT)
抱歉我的机器人有点问题……我发誓它在我的User:(WT-en) Maj/Sandbox下运行完美！我将离线调试，直到解决这个 bug（它正在剥离所有回车符）……抱歉！(WT-en) Majnoona 22:23, 2006年7月19日 (EDT)
我们回来了！我将以小批量运行，以免淹没最近的更改…… (WT-en) Maj 13:20, 2006年7月27日 (EDT)


(WT-en) DorganBot

  • 维护者：(WT-en) Dorgan
  • 任务：跨语言链接
  • 程序：Pywikipedia

-- (WT-en) Dorgan 09:48, 2007年7月10日 (EDT)

支持。功能与已故且备受怀念的 InterLangBot 相同，而咳咳刚刚的测试运行表明它运行良好，所以我建议我们如果 Evan 愿意切换机器人开关（这是少数只有行政员才能执行的任务之一），我们可以免除7天的等待期。不过有一个问题：机器人能正确处理 UTF8 吗？它也能在日语、印地语、希伯来语等语言中运行吗？(WT-en) Jpatokal 10:00, 2007年7月10日 (EDT)
是的，它是 UTF-8，并且运行良好，当然，它也在其他语言中运行。源代码在(WT-hu) 这里！（wikivoyage_family.py）(WT-en) Dorgan 10:16, 2007年7月10日 (EDT)
你还需要修改 wikipedia.py 来检查机器人标志——见。(WT-en) Jpatokal 12:15, 2007年7月10日 (EDT)
我明白了。我的问题是：我破解了那个文件，把它复制到 wikipedia.py，但它不起作用。我认为这个破解已经过时了，不幸的是我无法解决检查这两个页面的问题。而且在跨语言链接方面还有一个问题：如果我的主要语言是匈牙利语，并且我在 hu wt 中设置了这两个页面（如果它有效 :)），如果您不知道主要语言，您怎么阻止我？或者如果您知道，如果匿名用户，我怎么知道阻止不是骚扰？您能审查一下脚本策略吗？我认为 STOP 是给管理员的（就像 wps 一样）！(WT-en) Dorgan 03:57, 2007年7月11日 (EDT)
机器人应该检查它当前正在编辑的语言版本上的标志。上面的代码非常简单，你所需要做的就是更改 URL 指向User:(WT-en) DorganBot/Run和Project:脚本政策/运行。(WT-en) Jpatokal 04:35, 2007年7月11日 (EDT)
是的，我知道，我改变了，但什么也没发生…… (WT-en) Dorgan 04:49, 2007年7月11日 (EDT)
好的，我的最后一个问题：是的，我知道，那不是维基百科，但我认为跨语言机器人并不危险。你看我自2006年11月以来就有一个机器人（在英文、意大利文、罗马尼亚文、俄文、荷兰文、芬兰文、法文、德文、匈牙利文维基百科中），仅在匈牙利文维基百科中就有超过13000次编辑（大部分是跨语言链接！）。所以我无法解决这两个检查页面的问题，但我能获得机器人标志吗？ :) (WT-en) Dorgan 04:09, 2007年7月11日 (EDT)
这不是危险不危险的问题。问题是，它是否符合维基导游政策？如果不符合，那么我们或者 1) 不让它在维基导游上运行，或者我们 2) 在这种情况下忽略政策，或者 3) 我们改变政策。我的观点：也许我们应该放弃当前脚本政策中繁重的文章检查要求，以便像 pywikipediabot 套件这样的有用工具能够符合要求。我认为我们有足够的管理员来阻止行为不端的机器人是可行的。--(WT-en) Evan 19:41, 2007年7月15日 (EDT)
尚未。我想知道它是否按照我们的Project:脚本政策运行。我将检查代码。--(WT-en) Evan 10:43, 2007年7月10日 (EDT)
由于机器人之前似乎运行正常，并且Evan 最近不怎么露面，并且上面的评论无论如何都相当模糊，并且这次讨论拖得太久了，我暂定认为机器人已批准—如果出现问题，我们再阻止它。(WT-en) Jpatokal 13:09, 2007年11月1日 (EDT)
有人知道这个机器人怎么了吗？它工作得很好，不幸的是自2008年3月以来再也没有编辑了。--(WT-en) Flip666 给我写信！ • 05:13, 2009年2月10日 (EST)


DiscoverBot

因此，我想编写一个小机器人，自动更新Project:发现和Template:发现）。它实现起来足够简单（并且可能会重用 StatScript 的相关部分）—只需删除即将到来的队列中的第一个项目，将其放置在模板的顶部，并自动存档最后一个。我将尝试添加一些逻辑，使其在无法找到正在寻找的机器人可读标签时停止并报错。—上述评论由(WT-en) Jpatokal (讨论 • 贡献) 添加

它会如何处理 BotH 和我分类的 DotM/CotW 琐事？- (WT-en) Andrew Haggard (Sapphire) 01:47, 2006年6月23日 (EDT)
它会愉快地忽略它们。然而，如果条目以每24小时1次的精确速度被消化，初等微分学将允许你同步DOTMage和相关的发现。我们可以将列表类型从 * 更改为 #，这样会更容易。(WT-en) Jpatokal 01:51, 2006年6月23日 (EDT)
我被说服了。再问一个问题，以确保我完全理解。机器人会忽略 CotW/DotM 的琐事，除非我们更改脚本以从“#DOTM trivia”获取列表？- (WT-en) Andrew Haggard (Sapphire) 01:57, 2006年6月23日 (EDT)
是的。基本上，我只会插入一个标签，上面写着<!-- 吃掉我 -->或类似内容，机器人就会吃掉下一行（除非它说“不要吃掉我”）。(WT-en) Jpatokal 02:34, 2006年6月23日 (EDT)
顶。我需要另一位管理员的支持…… (WT-en) Jpatokal 21:28, 2006年6月30日 (EDT)
支持。抱歉，我没有意识到是你在要求这个，所以我没有意识到你已经准备好了。-- (WT-en) Colin 21:41, 2006年6月30日 (EDT)
支持。我也没意识到你已经准备好了——我当时在等着看是否会有测试版本之类的。-- (WT-en) Ryan 21:47, 2006年6月30日 (EDT)
哦。还没准备好，但我以为第一步是获得批准——写一个机器人却被否决了有什么意义呢？明天我会尽量抽出几个小时来写，应该不难。(WT-en) Jpatokal 00:15, 2006年7月1日 (EDT)
支持。听起来对我来说是个好主意。--(WT-en) Evan 01:24, 2006年7月1日 (EDT)
(WT-en) DiscoverBot 已被释放到毫无戒心的维基导游公民身上，每晚 UTC+01 都会造成疯狂的机器人破坏。(WT-en) Jpatokal 04:03, 2006年7月11日 (EDT)

StatScript

每周运行一次，自动更新Project:多语言统计，一旦运行正常，可以扩展到所有语言版本。我计划分阶段部署

  1. 自动获取统计数据
  2. 自动格式化为表格行
  3. 自动将新行放入表格
  4. 将新行放入所有语言版本的表格

这个也不存在，但我正在努力。我还需要在每个语言版本中创建一个Project:NumberOfArticles页面，其中只包含{{NUMBEROFARTICLES}}作为内容，这样我就不需要处理自定义的 Special:Statistics 页面了。(WT-en) Jpatokal 11:10, 2004年10月27日 (EDT)

现在阶段 1 和 2 存在→ User:(WT-en) Jpatokal/StatScript。阶段 3 和 4 将等待管理员批准，因为它们实际上是编辑页面而不是只读取页面。(WT-en) Jpatokal 12:43, 2004年10月27日 (EDT)
我认为这听起来是个不错的脚本主意。你计划多久运行一次？--(WT-en) Evan 16:35, 2004年10月27日 (EDT)
每周一次，格林威治时间星期五早上。(WT-en) Jpatokal 22:41, 2004年10月27日 (EDT)
我认为这听起来是个好主意，所以我投赞成票。我还需要在其他地方表达吗？-- (WT-en) Mark 19:16, 2004年10月28日 (EDT)
我投赞成票。-(WT-en) phma 21:58, 2004年10月28日 (EDT)

仅供参考，在长期死气沉沉（我只手动运行前半部分）之后，我终于使用 pywikipedia 框架编写了最后一块代码，并将其设置为自动驾驶。所以现在它应该每周五 UTC 00:00 自动运行。(WT-en) Jpatokal 21:47, 2005年8月18日 (EDT)

Hotelmakerbot

所以我有一个邪恶的(WT-en) 酒店制造商脚本，它会抓取各种酒店网站来生成条目。一些人已经使用这些数据源填充了各种美国文章。每次我运行脚本时，我的格式都会改进，一些酒店会消失，一些酒店会出现。我想编写一个脚本来帮助保持条目最新。它将

  1. 编辑所有在 hotelmaker 数据库中找到酒店的美国文章
  2. 如果“睡眠”部分包含过时的 hotelmaker 条目集，则“睡眠”部分将替换为这些条目的现代化版本。
  3. 新的条目将使用新的<sleep>标签

将来我可能会做得更花哨（注意：此提名不授予任何更花哨版本的权限），但目前我只想更新旧条目，别无其他，所以如果以下任何情况属实，我的脚本将不进行编辑

  • 手动添加了酒店到列表
  • 酒店已从列表中移除
  • 进行了任何可能需要保留的格式更改。

我这里的主要动机是领先于（WT-en）Jani，在他制作将睡眠条目转换为新列表标签样式的机器人之前完成此操作，因为这会让我将来难以编写更新机器人。-- (WT-en) Colin 03:00, 2006年11月6日 (EST)

DorganBot (曾用名: InterLangBot)

在德语网站上，大多数文章只包含指向英语版本的跨语言链接。另一方面，相应的英语文章并不知道它们的德语对应物。我想编写一个小型机器人来执行以下操作

  1. 它遍历德语文章列表并读取它们到英语网站的跨语言链接。
  2. 它会在找到的每篇英语文章上放置一个指向德语网站的适当跨语言链接。
  3. 同时，它在英语文章中查找其他跨语言链接，并将它们添加到德语文章中。
这样，英语和德语版本（以及其他语言版本）都将保持良好的联系并保持良好的链接。你可能会说，所有这些也可以手动完成。好吧，基本上你是对的。但是谁来做所有这些无聊的工作呢？-- (WT-en) Hansm 16:33, 2004年10月21日 (EDT)
    • 这听起来不错。它需要排除不是跨语言链接（WikiPedia，Dmoz）的孪生页面链接。我愿意制定一个非正式规则，即跨语言链接总是以小写字母开头（en:，sv:，fr:，de:，ro:），并且长度为三个字母或更长，而其他网站则以大写字母开头，并且长度为四个字母或更长。听起来公平吗？--(WT-en) Evan 17:02, 2004年10月21日 (EDT)
    • 对于第一次运行，我宁愿硬编码这 5 个国家代码。我希望机器人尽可能简单，以避免灾难性的故障。当机器人运行良好时，以后可以加入更高级的配置功能。在初步调查中，我发现一些现有的跨语言链接指向空页面。原因要么是链接损坏，要么是链接到已计划但仍为空的文章。问题是，如何处理这些链接。删除这些链接还是保留它们？-- (WT-en) Hansm 14:24, 2004年10月24日 (EDT)
      • 删除。损坏的链接是无用的，一旦有人注意到问题，链接将被重新创建。当然，你也可以记录损坏链接的列表，然后发布到某个地方进行手动更正…… (WT-en) Jpatokal 11:02, 2004年10月27日 (EDT)
    • 仅作程序说明——我不确定我们是否在这里达到了两位管理员的规定，所以我暂时将 InterLangBot 的运行设置为“否”。我有我的支持，Hansm 也支持，但他 a) 是这个想法的发起人，b) 是不同语言版本的管理员。这项政策是在我们有多个语言版本之前创建的，因此尚不清楚非 en: 管理员是否算数。对于Project:管理员提名，我想我们最终表示，如果提名人本身是管理员，则需要另外两位其他管理员的支持。无论如何，我只是在征求意见。如果另一位 en: 管理员能够进来表示赞同，那么这一点就无关紧要了。--(WT-en) Evan 17:01, 2004年10月28日 (EDT)
      • 埃文，我理解你的观点，但另一方面我又不理解。脚本被提名了一周。我已在 PUP 中请求其他管理员发表评论。如果管理员不关心，我该怎么办？要么这里的管理员太少，要么规则不应该太当真。无论如何，这个在主页上产生编辑的错误确实令人痛苦，我很抱歉。我希望在它再次发生之前我能修复它。-- (WT-en) Hansm 18:10, 2004年10月28日 (EDT)
        • 你应该做的就是等待。抱歉，但它不是那么紧急，不能再多等24小时的讨论和决策。--(WT-en) Evan 13:50, 2004年10月29日 (EDT)
    • 哎呀……抱歉。我一直没有关注这个页面。这是你的第二张管理员投票：赞成。听起来是个不错的脚本。同时，如果它是用 perl 编写的，就使用 perl 模块……并让我保持更新…… ;) -- (WT-en) Mark 19:19, 2004年10月28日 (EDT)
    • 同上……它获得了我的投票……它一开始只会用于德语还是所有语言？(WT-en) Majnoona 20:35, 2004年10月28日 (EDT)
    • 我认为这是个好主意。它需要比 StatScript 更多的测试，因为它修改了许多页面，而且不清楚如何在测试 wiki 上测试它，因为它需要两个语言版本才能做任何有用的事情。所以要仔细测试。-(WT-en) phma 21:58, 2004年10月28日 (EDT)
    • 感谢大家投赞成票。Marc，脚本已经写好了，我必须承认我没想起你的 wix 模块。下次我一定会参考。使用一些经过充分测试的标准比总是从头开始要好，就像我所做的那样。我知道，InterLangBot 是一项关键任务，因为测试只能在其真实环境中进行。Evan 阻止的不是运行机器人的尝试，而只是我的测试。在真正启动它之前，还会进行更多测试。-- (WT-en) Hansm 03:01, 2004年10月29日 (EDT)

InterLnagBot 正在运行。-- (WT-en) Hansm 04:11, 2004年10月29日 (EDT) (WT-en) InterLangBot 运行完成。大约 400 篇英文文章应该已经获得了指向其德语对应文章的新链接，当然，其中许多仍然是存根。一些损坏的法文和罗马尼亚文链接已被删除，并遇到了一些不一致的链接，但未做修改。如果您发现机器人有任何错误，请在InterLangBot 的讨论页上报告，让我知道。-- (WT-en) Hansm 03:48, 2004年10月30日 (EDT)

与其重复造轮子（然后迅速忘记它），不如使用Pywikipediabot，它有一个先进、使用广泛的机器人来完成这项工作。我会在某个时候尝试设置它自动运行。(WT-en) Jpatokal 09:57, 2005年7月14日 (EDT)

---

我的旧 InterLangBot 有一个严重问题：它无法处理无法映射到 iso-latin-1 编码的 UTF-8 字符。由于我们有 ja: 语言版本，它不再有太大用处了。

我曾尝试自定义Pywikipediabot框架中的 interwiki.py 机器人，以满足维基导游的需求。这样做的好处是可以使用一个维护良好、随着维基媒体软件版本更改而保持更新的程序。但也存在一些问题

  • 我看不出有什么办法可以在不大量修改源代码的情况下，将维基百科链接保留在列表底部。如果它们被移到顶部，这重要吗？
  • 处理我们非常特殊的脚本阻止政策，该政策规定当某些页面的内容与“是”不同时脚本必须停止，这并没有使事情变得容易，但可以通过对机器人代码进行微小更改来解决。Jpatokal 的方法可以推广到我们所有 6 种语言。我看到了一种无需更改 wikipedia.py（这是框架的核心文件之一）的方法。相反，需要对 interwiki.py 进行少量修改。
  • 另一个问题是，维基导游禁用了 mediawiki 消息，但 wikipedia.py（因此 interwiki.py 也是）依赖它们。似乎只有一种可能性来解决这个问题，那就是修改源代码中的一行。这样做的弊端是无法再处理编辑冲突和其他不规则问题。然而，这可能是一个小问题。

通常，对 Pywikipediabot 源代码的更改是有问题的，因为它们会随着更新而丢失。

现在对大家来说最成问题的问题是：维基百科链接在底部有多重要？-- (WT-en) Hansm 19:06, 2005年10月16日 (EDT)

你是说维基百科链接仍然保留，只是在列表中改变了位置？是因为大写 W 在按字母排序时排在小写 a-z 之前吗？(WT-en) Jpatokal 20:35, 2005年10月16日 (EDT)
是的，维基百科链接仍然保留在“其他语言”列表的顶部。但这不是因为大写 W。维基百科链接不能像语言版本一样被视为普通的跨语言链接。所以，维基百科链接是文章的最后一部分，它在所有跨语言链接都被删除并重新添加到页面末尾后仍然保留。-- (WT-en) Hansm 00:57, 2005年10月17日 (EDT)

也许，在wikipedia.py中进行一个非常脏的 hack 可以解决维基百科链接问题。更多信息请参阅User talk:(WT-en) InterLangBot。-- (WT-en) Hansm 15:31, 2005年10月17日 (EDT)


Tatatabot

我已开始在日语版上运行此机器人，我可以作为 DorganBot 的替代品为英语版做出贡献。

在英文版上，我将只使用维护跨语言链接的功能。至于替换文本的功能，如果有人需要帮助，将应要求使用。

顺便说一句，我也想在中文版上使用这个机器人。但是由于只有一个管理员，所以没有关于脚本或脚本提名流程的文档。 ;-) 我可以在这里为中文版申请一个机器人标志吗？-- (WT-en) Tatata 22:03, 2009年4月27日 (EDT)

  • 支持 -- 这早就该来了！是的，我很乐意在 fi 和 zh 上启用机器人标志。(WT-en) Jpatokal 01:09, 2009年4月28日 (EDT)
谢谢 Jani-san。我创建了一些账户（(WT-en) en, (WT-fi) fi, (WT-zh) zh）和 /Run 页面（zh:Project:脚本方针/Run）。在苏omi语中“Script policy”怎么拼？“Komentosarja käytännöt”，对吗？-- (WT-en) Tatata 21:16, 2009年4月29日 (EDT)
机器人标志已在 fi, zh 上启用。“脚本”这个词在芬兰语中没有很好的对应词（komentosarja指的是手动命令序列），所以政策页面现在位于fi:Project:Botit（“机器人”），标志位于fi:Project:Botit/Run。(WT-en) Jpatokal 02:48, 2009年4月30日 (EDT)
我已将中文页面从“zh:Wikivoyage:腳本方針/Run”移至“zh:Project:机器人方针/Run”，原因相同，尽管我不太懂中文 ;-)
机器人已在 fi, zh 上开始工作！-- (WT-en) Tatata 22:14, 2009年4月30日 (EDT)
  • 支持。我真受够了将跨语言链接标记为已巡查 :-) -- (WT-en) Colin 02:51, 2009年4月30日 (EDT)
谢谢你Colin-san。—— (WT-en) Tatata 22:14, 2009年4月30日 (EDT)

机器人获得了标记并开始在en:上工作。谢谢！

现在，我正在de:和fr:上请求机器人标记。不幸的是，这两个语言版本都没有人来脚本提名页面。;-) -- (WT-en) Tatata 22:08, 2009年5月6日 (EDT)

干得好，Tatata！ (WT-en) Gorilla Jones 22:36, 2009年5月6日 (EDT)

VolkovBot

这个跨wiki机器人使用标准pywikipedia框架，由wikipedia:ru:User:Volkov（ru.wiki管理员）在许多WikiMedia项目上操作。我认为它将有助于关注wikivoyage上的跨wiki链接并在需要时更新它们。机器人应该定期运行。--(WT-en) Volkov 03:13, 2009年8月19日 (EDT)

这与已经运行的Tatatabot有什么不同？- (WT-en) Dguillaime 03:26, 2009年8月19日 (EDT)
我看不出有什么太大不同，但我猜测有一个备用不是坏主意。最新的跨wiki链接对所有wikivoyagers都会有帮助 ;) --(WT-en) Volkov 03:32, 2009年8月19日 (EDT)
支持。它似乎已经做得很好，而且冗余是好事。Volkov，如果你想挑战一下，要不要也自动化维基百科<->维基导游的链接？我们使用[[WikiPedia:XXX]]（注意：大小写可能不同），而维基百科通常使用{{wikivoyage}}模板（参见Wikipedia:Template:Wikivoyage）。(WT-en) Jpatokal 04:46, 2009年8月19日 (EDT)
支持。Tatabot的备份不会有坏处，如果能（额外）自动化维基百科链接就更好了，尽管这并非支持此机器人的先决条件。-- (WT-en) Ryan • (talk) • 10:48, 2009年8月19日 (EDT)

YggdrasilBot

我想创建一个脚本来为尽可能多的文章添加“isIn”信息。我们已经手工做了很多，但我认为自动进行一次检查可能更有意义。我称之为“YggdrasilBot”，因为它旨在构建一个世界之树。我认为这会很棘手，但它将这样运作：

  1. 它将以七大洲作为输入，以及其他顶级区域，如中美洲和加勒比地区。
  2. 对于每个输入文章，它将阅读该文章，并查找具有特定名称的章节（“Sections”、“Regions”、“Countries”、“Other destinations”、“Districts”、“States”、“Provinces”、“Counties”等）。这将是可配置的，以便我们可以将相同的机器人用于不同的语言版本。
  3. 在这些文章的每个部分中，它将寻找“* [[Link]]”形式的链接——也就是说，只有链接是顶级列表中的第一个项目。这是列出区域、城市等的Project:Manual of style格式。它将忽略分层列表中的第二级或更高级别链接，以及嵌入在文本中的链接。
  4. 它会将链接引用的文章添加到其输入文章队列中。
  5. 它将记录输入文章是每个链接文章的父级——在正在阅读的文章和链接文章之间建立双向关系。
  6. 完成输入后，它将对其构建的图进行一些计算。对于每个节点（目的地），它将查看每个父节点。它将丢弃任何作为其其他父节点之一的祖先的父节点。然后，它将从剩余列表中选择第一个父节点。
  7. 计算完成后，对于每个节点，它将检查节点对应的文章是否存在，以及节点是否已经定义了父级（通过读取RDF数据）。如果存在且尚未定义父级，机器人将在文章底部添加一个{{isIn|Parent}}模板。

我将在接下来的几天内编写此脚本（使用Pywikipediabottish或Perl + WWW::Mediawiki::Client），并于下周运行（待批准）。代码将在此处和我的存档库中提供。

我正在尽可能保守地处理这个问题，但我将首先在测试仓库上进行尝试。——(WT-en) Evan 15:37, 2005年12月9日 (EST)

支持。一旦它能在最保守和最明显的案例中运行，请尽快让它运行。—— (WT-en) Colin 00:23, 2005年12月11日 (EST)
好主意 = 支持。但有一点。虽然区域可以是分支的一部分，但城市只能是末端的叶子。区域应该列出城市目的地，城市（除了有区域的大城市）不应该。此外，如果一个城市出现在多个区域文章中，那么应该选择最远或最深的区域作为IsIn链接。还应该有一些一致性，所有来自同一区域的城市文章，包括现有的，都应该获得相同的IsIn链接。因此，如果一个姊妹页面上已经存在IsIn链接，则应检查该IsIn的有效性，以确保与所有其他姊妹页面保持一致。这还可能意味着如果一个页面上的姊妹链接过多——可能是因为需要更多的区域——则不添加IsIn链接。最后，在区域未建成但城市已建成的情况下，IsIn链接可能在树中过早地被错误分配。这可以通过Bot在区域建成后更改IsIn链接来克服，或者报告错位的IsIn、过多的IsIn和缺失的区域页面。这里的假设是，人工添加的IsIn比Bot添加的更可靠。—— (WT-en) Huttite 00:59, 2005年12月11日 (EST)
首先：第六步的目的是确保只使用最深层的区域。其次，对于有奇怪情况的文章，在讨论页上添加一个lint注释怎么样？这样既能利用自动化工具，又能在遇到奇怪情况时不写入实际文章。——(WT-en) Evan 13:04, 2005年12月12日 (EST)
支持。这类似于User:(WT-en) Elgaard#Wikivoyage_as_book（我希望用一个使用isIn的脚本来代替）。——(WT-en) elgaard 16:35, 2005年12月11日 (EST)
我支持将其作为维护工具，但能否先创建一个仍然需要 isIn 信息的文章列表，然后等待一两周，看看有多少人可以手动设置？目前来看，isIn 似乎在促使人们创建父区域和更清楚地决定什么属于哪里方面取得了奇效，所以再等一段时间似乎也有一些价值。—— (WT-en) Ryan 16:43, 2005年12月11日 (EST)
支持。(WT-en) Ryan也提出了一个很好的观点.....我们为什么不等到新年后再运行这个机器人呢？(WT-en) Paul James Cowie 18:35, 2005年12月11日 (EST)
我也是。我不认为这特别紧急，所以我们先让人类完成困难的部分。(WT-en) Jpatokal 01:32, 2005年12月12日 (EST)
仅供参考：我刚刚进行了一次查询，在主命名空间中，6164个非重定向、非消歧义页面中，有1536个链接到“isin”模板。这样如何：我将脚本准备好，并在测试数据库上运行，然后等到1月份再运行。我希望它能每隔几天定期运行一次，以保持整个网站的良好连接。——(WT-en) Evan 12:55, 2005年12月12日 (EST)
我赞成这个脚本，特别是如果它使用Perl库，并且如果您能给我一些关于其设计和您发现的任何错误的反馈。—— (WT-en) Mark 04:58, 2005年12月12日 (EST)
您将如何处理一个地方属于两个区域的情况，例如太浩湖或尼亚加拉大瀑布？此外，这个机器人应该查看的一些链接前面有“The”或其他短词。-(WT-en) phma 09:35, 2005年12月21日 (EST)
我也支持这个脚本。手动处理近5000篇文章将需要很长时间，因此自动化是好事。每周运行听起来也不错。—— (WT-en) Ilkirk 10:30, 2005年12月30日 (EST)
机器人能否更新Special:Yggdrasil或Project:Yggdrasil页面，显示实际的世界树吗？我想到一个页面，世界各大洲、国家、地区、州和城市以分层树的形式显示，并且可以根据需要展开和折叠。如果也能显示文章状态就更好了，这样如果我想查找印度下的所有小作品，我就可以一次性完成。——(WT-en) Ravikiran 05:25, 2006年1月4日 (EST)

AutotranslateBot

作为自动翻译功能的一部分，我将开始测试一个机器人，并向文章讨论页面的子页面添加自动翻译（例如，/Parigi:Discussione/Translation 用于英文文章的意大利语版本，或 /Talk:Cologne/Translation 用于德语文章的英文版本）。我将从大约六个左右开始，以获取反馈，然后处理有用的少量批次。(WT-en) Majnoona 14:26, 2006年7月1日 (EDT)

AntiVandalBot

维基百科目前运行着一个名为WikiPedia:User:AntiVandalBot的机器人，它使用模式匹配来回溯明显的破坏。它进行的破坏回溯似乎非常准确，包括从“Bob is gay”的编辑到页面清空的所有内容（参见WikiPedia:Special:Contributions/AntiVandalBot）。它还在被回溯更改的作者的用户页面上留下注释，并且在默认的“平静”模式下不会两次回溯同一更改——还有一个“愤怒”模式。他们有一个WikiPedia:User:AntiVandalBot/requests页面，用于让它在维基百科之外的Wiki上运行，我想尝试让它在英文Wikivoyage上运行。如果机器人出现任何问题，故障安全措施是管理员阻止机器人运行的用户，所以它看起来足够安全。-- (WT-en) Ryan 17:43, 2006年7月18日 (EDT)

  • 支持。Tawkerbot2在维基百科上表现出色。对于我监视列表上的少数页面，它通常比其他人更快地发现愚蠢的破坏。我查看过几次takwerbot2的贡献日志，对我来说看起来很完美。-- (WT-en) Colin 17:53, 2006年7月18日 (EDT)
  • 问题：WikiPedia:User:Tawkerbot2/requests提到了软件成本；这是一个问题吗？- (WT-en) Todd VerBeek 19:24, 2006年7月20日 (EDT)
    • 如果这是一个问题，我不明白为什么我们不能手动处理破坏。当然，不用担心巧妙隐藏的“我想吃你的孩子”、“鲍勃是同性恋”或wwww.crazyfarmsexffffffffffffff.com会很好。除了上述成本问题，Tawkerbot页面还提到了需要一个单独的服务器来运行，这会是个问题吗？-- (WT-en) Andrew Haggard (Sapphire) 19:32, 2006年7月20日 (EDT)
    • 关于费用的评论是最近添加的，它不是由脚本作者添加的，所以我不清楚这是否是会收取的费用，或者只是其他人建议开始收取费用。如果我请求让机器人在这里运行，他们说有费用，那么所有都作废了——这只是“锦上添花”，不是必需品。至于单独的服务器，我认为那是脚本作者说他想要一个单独的服务器来运行它，尽管我猜他也在考虑P2P解决方案。-- (WT-en) Ryan 19:35, 2006年7月20日 (EDT)
      • 我们可以在旧的wikivoyage.org服务器上运行它（现在它只运行邮件列表……还有我的博客，Maj的主页，以及其他一些杂项网站）；我不确定我对任何额外的使用费有什么看法，但我可以问问IB。——(WT-en) Evan 19:46, 2006年7月20日 (EDT)
  • 支持，只要一切顺利。—— (WT-en) Andrew Haggard (Sapphire) 19:43, 2006年7月20日 (EDT)
  • 关于费用问题有几点说明，主要是因为我们当时正处于服务器严重紧张时期，我们俩都负担不起每月大约150美元的费用来运行所有维基百科的服务器。简而言之，脚本现在可以从SVN中获取，你有一个IRC最近更改的feed吗，那是它需要的另一个主要的东西。-- 207.216.238.134 12:23, 2006年7月21日 (EDT)
    • 如果需要，可以设置一个 feed，请通过在我的讨论页或User talk:(WT-en) Evan#Tawkerbot上留言，让我们知道下一步。-- (WT-en) Ryan 16:02, 2006年7月21日 (EDT)
      • 不过，我不得不说：这些通知是在MediaWiki中生成的，然后发送到IRC服务器，再由机器人读取，然后通过Web界面发送回MediaWiki服务器……这肯定是一条漫长的弯路！——(WT-en) Evan 16:10, 2006年7月21日 (EDT)
        • 那我们是应该手动回溯还是点击回滚按钮呢？- (WT-en) Andrew
          • 不，我只是想知道我们是否可以通过将警告输出的管道扭曲一下，使其插入到回溯输入的孔中来缩短这个过程。——(WT-en) Evan 17:08, 2006年7月21日 (EDT)
            • 更新：机器人已更名，并于2006年10月24日在新机器上运行，希望很快能看到一些进展。—— (WT-en) Ryan 03:09, 2006年11月2日 (EST)

SpamFilterBot 2.0

Evan和我正在讨论维基导游的各种想法，我认为如果我们能建立一个机器人，可以在所有语言版本、共享和审查中更新垃圾邮件过滤器，并保持所有垃圾邮件过滤器的一致性，以防止英文垃圾邮件发送者向西班牙语、意大利语等语言版本发送垃圾邮件，那将是很棒的。无论谁编写脚本，都将获得一个星章。三、二、一，开始！-- (WT-en) Andrew Haggard (Sapphire) 23:25, 2006年8月6日 (EDT)

直接在共享中设置一个垃圾邮件过滤器会不会更简单？-- (WT-en) Ryan 22:11, 2006年8月15日 (EDT)
对于这个和上面的反破坏机器人，我们能使用WMF的多站点机器人吗？使用已经测试过且我们无需维护的代码对我来说是巨大的胜利。Pashley (talk) 2012年11月27日 18:24 (UTC)[回复]

Dotmodroid

由于手动更新 DotMs/OtBPs 很麻烦（更新首页、放入索引、从当前讨论中移除、放入档案），我想创建一个类似于(WT-en) DiscoverBot的机器人来自动化这个过程。（维基百科可能有一些可供借鉴的东西。）理想情况下，它能够维护所有拥有活跃 DoTM 流程的维基导游语言版本，并且它足够智能，当队列为空时不做任何事情。(WT-en) Jpatokal 02:14, 2006年11月1日 (EST)

  • 支持。Dotmodroid是个好名字，但JaniBot什么时候能出来？-- (WT-en) Ryan 02:44, 2006年11月1日 (EST)
JaniBot 会做什么？环游世界，为人们申请印度签证，流利地说八种语言并为更多机器人编写新脚本？-- (WT-en) Andrew H. (Sapphire) 03:05, 2006年11月6日 (EST)
“会”？哈！那个无用的臃肿的原生质体User:Jpatokal早就被干掉了，取而代之的是JaniBot。准备好被同化吧。—— (WT-en) JaniBot 03:08, 2006年11月6日 (EST)
:) -- (WT-en) Andrew H. (Sapphire) 03:14, 2006年11月6日 (EST)
读了这个之后想到的。—— (WT-en) Andrew H. (Sapphire) 04:19, 2006年11月25日 (EST)
  • 支持。听起来是处理繁琐任务的好方法。——(WT-en) Evan 10:43, 2006年11月2日 (EST)
  • 支持。我修改了本月目的地候选页面的格式，是让机器人生活更轻松还是更艰难了？我猜是更轻松了，因为它可以直接抓取 div 标签之间的内容，但对机器人来说，你永远不知道……— (WT-en) Ravikiran 21:23, 2006年11月13日 (EST)

CommaBot

我今天早上注意到有人创建了Newark, New Jersey，而我们已经有了Newark (New Jersey)。我想知道是否有一个机器人会很有用，它可以为美国和加拿大的城镇添加重定向，其中逗号分隔的城市和州是一种常见的命名约定。我可能会只使用UN/LOCODE列表中的美国和加拿大城市，这将排除地图上的点，但会涵盖大多数国家。它将以City, State和City, ST的形式重定向到City (State)或直接City（取决于文章是否存在）。——(WT-en) Evan 14:22, 2006年11月22日 (EST)

当文章已经存在为“城市”时，您打算如何确保它是正确的城市？遍历 isIn 树直到到达一个州？检查维基百科链接？（我这么说一半是为了澄清，一半是为了“我可能想做类似的事情”）您打算只为现有文章制作这些重定向吗？—— (WT-en) Colin 15:29, 2006年11月22日 (EST)

MapmakerBot

我离完全自动化将维基导游文章与OSM数据结合生成一个大部分可用的地图非常近了。我提议在共享上创建一个机器人帐户来上传这个过程的结果。完成后，MapmakerBot将执行以下操作：

  1. 监视给定类别中的页面，例如“有地图”
  2. 当其中一个页面发生任何更改时，根据页面上地图图像中的配置和OSM数据重新生成地图
  3. 将该地图生成的结果SVG上传到共享
  4. 等待有人调整上传的SVG文件
  5. 检索SVG
  6. 将其转换为适当大小的PNG
  7. 上传PNG

要查看地图生成所需的配置示例，请查看巴黎文章。在某个时候，我将编写一些关于如何使用该功能的文档。-- (WT-en) Mark 11:42, 2009年5月21日 (EDT)

支持。-- (WT-en) Colin 16:15, 2009年5月21日 (EDT)
支持 --(WT-en) Stefan (sertmann) Talk 16:19, 2009年5月21日 (EDT)
支持。(WT-en) Jpatokal 05:43, 2009年5月22日 (EDT)
以防万一您好奇，我已经将源代码推送至http://gitorious.org/osmatravel -- (WT-en) Mark 11:11, 2009年5月22日 (EDT)
我已经在共享上创建了帐户。我不记得了，有没有一个请求翻转机器人位的流程？-- (WT-en) Mark 11:22, 2009年5月22日 (EDT)

这个目前的状况如何？由于我们不再有共享，是否需要进行任何更改？Pashley (talk) 2012年11月27日 21:52 (UTC)[回复]

weTravelWrite.com

iTravelWrite 是一款 iPhone 应用（目前可在 App Store 免费下载），旨在让人们可以轻松地通过手机更新维基导游——尤其是添加 GPS 位置信息。这将增加维基导游上可用的经纬度数据，使地图制作更加容易，并有望通过允许人们在现场进行编辑来提高准确性。

该应用旨在通过一个中央服务（一个运行在 Google App Engine 上的 Python 脚本，网址为 www.wetravelwrite.com）传输更新。这大大降低了手机应用的带宽成本，提供了集中式日志记录和控制点，并让用户可以记下快速笔记，以便以后在真正的电脑上将其扩展为编辑。需要明确的是，这是一个脚本，但不是机器人：它只响应 iPhone 应用发出的特定用户请求。

我贸然开发了该应用和服务，事先未征得此处同意——对此表示歉意！我目前已禁用该应用的编辑功能，直到（如果）脚本获得批准，并且直到我修复它处理非 ASCII 字符的错误。（这反过来又是一个集中控制点有用的例子。）

(WT-en) Rezendi 15:18, 2009年8月25日 (EDT)

  • 顺便说一句，我注意到目前添加的一些坐标非常不准确——例如，对布里斯班的这次编辑实际上是俄亥俄州的坐标。我认为我们无法自动处理此类错误，而且很容易出现更多错误……该应用是否默认添加当前坐标？如果是这样，是否应该这样做？- (WT-en) Dguillaime 15:54, 2009年8月25日 (EDT)
    • 该应用有一个“我在那里！”按钮，可以插入当前坐标（或者至少是手机认为的当前坐标）；如果他们真是铁杆用户，也可以手动输入经纬度坐标。(WT-en) Rezendi 21:10, 2009年8月29日 (EDT)
  • 支持。有人能为Rezendi提供一个测试服务器来调试他的应用程序吗？如果没有测试服务器，我支持在这里进行测试。-- (WT-en) Colin 17:25, 2009年8月25日 (EDT)
  • 反对——暂时。必须有一种方法可以关闭它，并给用户发送来自WT的消息。如果它出现故障，阻止IP地址是不可接受的，如果它被广泛安装，甚至可能不切实际。如果wikivoyage API更改，或者我们更改部分或定义，必须有一种方法告诉用户他们需要更新，并阻止他们进行会损坏系统的更改，而无需完全阻止他们。我建议程序使用特定的用户帐户，或者通过页面的存在来拒绝更新，并发送用户消息。可能这个文件可以基于安装的版本。--(WT-en) inas 17:39, 2009年8月25日 (EDT)
实际上，我认为 iTravelWrite 根本不是一个脚本。实际上，它是一个非常专业的浏览器，与（比如说）Firefox 模块没有什么不同，由真实的人类操作，技术上它不需要我们的许可。
尽管如此，我确实看到了这里潜在的危害，我赞扬 User:Rezendi 让我们知道这一点。仔细测试是必要的，并且应该内置简单的保障措施，例如不更改任何现有坐标，并在启动时检查程序是否允许运行。(WT-en) Jpatokal 23:48, 2009年8月25日 (EDT)
别担心——虽然iPhone应用程序可以广泛分发，但它故意设计成不直接连接到维基导游；相反，它连接到wetravelwrite.com上的Web服务器，因此iTravelWrite应用程序的所有编辑都通过那里。这意味着有一个单一的控制点，可以关闭所有应用程序的编辑。（目前就是这种情况，直到我修复特殊字符错误，希望在我有偿工作不那么耗时后很快就能修复。）
我很乐意设置它，让所有编辑都使用“iTravelWrite”用户帐户，或者，交替地，通过轮询维基导游上的一个页面来查看编辑是否正常（尽管第一个解决方案看起来更优雅）。(WT-en) Rezendi 17:22, 2009年8月26日 (EDT)
同意—第一个选项更好。(WT-en) Gorilla Jones 18:45, 2009年8月26日 (EDT)
我想补充一点，我认为这个整体想法很棒。我们需要WT中旅行者更多的原创研究才能进步，让更多人能够在旅途中进行更新是非常棒的。然而，我也认为wiki的一个重要部分是能够尝试编辑者之间的沟通，并能够识别一组编辑是由同一个人完成的。这是协作方法的一部分。这就是讨论页存在的原因。这就是我们试图坚持每条消息都签名的原因。这就是每个编辑都记录IP或帐户的原因。如果所有内容都来自一个IP，并且用户是匿名的，那么我们就无法与用户沟通他们的编辑。我们无法将他们指向mos，纠正他们正在犯的错误。如果有人是破坏者，我们无法进行精细控制。这种事情有没有在其他wiki上做过，我们可以看看他们如何处理这些问题。有没有人写过iPhone WP编辑应用程序？对于应用程序来说，允许用户在WT上创建帐户是否太难？--(WT-en) inas 22:12, 2009年8月26日 (EDT)
我理解你的观点。将所有编辑归入同一用户会限制问责制和沟通。可以让用户在应用程序中输入他们的维基导游用户名和密码，并将其转发，尽管可能存在安全问题，因为密码将以明文形式传输。（不过，嗯，现在我仔细一看，维基导游主登录页面似乎使用http而不是https，所以它不会比现状更不安全。）这样你就可以通过a）编辑摘要评论（总是包含“weTravelWrite”）；b）用户代理（我想）；c）IP地址（尽管c）不太可靠，因为它取决于Google App Engine）来区分来自应用程序的编辑。
我也可以记录iPhone的唯一设备ID，并将其作为编辑摘要的一部分传递，这可能有助于识别特定用户的编辑。我甚至可以传递他们正在使用的IP地址……但实际上，这没有帮助——它们会频繁变化，既随着时间推移，也随着用户从一个网络移动到另一个网络或Wi-Fi站点。最终，随着人们越来越多地使用智能手机，IP地址将越来越不具有意义；这是许多网站将不得不处理的问题。
那样可以吗？如果该应用程序要求用户登录 Wikivoyage 账户，以便您可以单独识别他们，并且如果我无论如何都传递 iPhone 的唯一设备 ID？那么您应该能够区分 iTravelWrite 的编辑与其他编辑，即使他们不选择登录，也可以按唯一的电话 ID 对编辑进行分组。这不会像通过 IP 地址那样方便，但是，这就是移动网络的情况。(WT-en) Rezendi 13:22, 2009年8月29日 (EDT)
此外，我似乎已经修复了非ASCII字符错误（尽管我还需要用真实数据测试才能完全确定），所以一旦你们准备好，我就准备好了。(WT-en) Rezendi 21:07, 2009年8月29日 (EDT)
我喜欢每个用户使用自己的维基导游账户的想法。这样他们就可以成为完全合格的社区成员。我们能做些什么来让使用 OpenID 更容易吗？我的意思是，你能在你的网站上运行一个服务器吗，这样你就可以无缝地插入他们的ID，然后用它作为他们的维基导游ID？我不是想把事情复杂化，只是在思考。如果这一切听起来太难，我很高兴用户创建一个真正的维基导游账户。--(WT-en) inas 22:20, 2009年8月30日 (EDT)
嗯。这是一个有趣的想法。App Engine 使用 Google Accounts，所以一旦用户在我的服务器上授权，我认为我就可以使用 OpenID 将他们无缝登录到维基导游。问题在于他们的手机和我的服务器之间的授权——我不喜欢明文传输 Gmail/Google Account 密码，而且在 iPhone 上使用 https 很难（而且很慢）。这样吧：如果用户提供维基导游 ID，我将让他们使用现有的维基导游用户名和密码；如果未提供维基导游 ID，我将研究使用 Google Account / OpenID 登录（不过，在详细分析问题之前，不作任何保证……）。(WT-en) Rezendi 16:58, 2009年8月31日 (EDT)

更新：我已提交iTravelWrite应用的新版本，该版本修复了错误并允许用户输入其维基导游用户名和密码，并且除非他们这样做或提供电子邮件地址（该地址将添加到编辑评论中），否则不允许编辑。一旦接受，我将撤回旧版本应用并重新开启编辑。(WT-en) Rezendi 15:23, 2009年9月8日 (EDT)

User:K7Lbot

isInKat: (未完成，已使用现有机器人)

关于是否将分类与面包屑并行使用的问题，在Template talk:IsPartOf#Category of IsPartOf和Wikivoyage talk:Breadcrumb navigation#Navigating down a breadcrumb trail中仍然开放，但是，如果城市/城镇以上的所有区域都需要有相应的地理分类，那将需要一个“机器人脚本”来创建这些分类并将每个分类放置在其父区域中。目前使用的isPartOf标签列表有数千篇文章那么长，移除本地级别（城市/城镇）目的地文章后，仍然会留下几千个分类待创建。如果从具有本地数据库列表的程序中提供新页面，pywikipediabot脚本将能够完成此任务。

类别将使某些任务更容易——例如查找完全没有父区域的文章（这些文章应变为未分类页面）。数兆字节长的现有标签列表（User:K7L/isPartOf）是通过下载XML数据库转储并搜索“isIn”/“IsIn”/“isPartOf”获得的。每条记录都有从一个页面中提取的页面名和父名称。我建议将其导入本地数据库表，提取所有唯一的父位置列表，然后为这些地方生成类别描述（category:someregion - [Someregion]在[parentregion]中。[category:parentregion]）。然后将其提供给“pagefromfile.py”（包含在pywikipediabot包中）以发布生成的类别描述页面。

似乎这些（任务太重复）太多了，无法手动生成；这需要自动化。K7L (talk) 2013年1月11日 15:59 (UTC)[回复]

自动生成这将避免用户尝试手动创建时的任何误解。这种结构对于整理放置在错误ispartof中的文章非常有帮助。请使用{{IsPartOf/preload}}中使用的格式创建类别。--Traveler100 (talk) 2013年1月12日 10:37 (UTC)[回复]
    • 我认为这个是可疑的。
    • 首先，本节开头写道“关于是否将分类与面包屑并行使用的问题，在……仍然开放。”在我看来，这个问题是开放的，尚未解决，我们不应该添加数百个分类，除非我们达成共识认为我们需要它们。
    • 其次，我对User:K7L的了解还不足以信任他/她拥有机器人权限。这里提出的大多数机器人都是从其他WMF维基测试导入的。这将是一个针对WV的新机器人。
    • 话虽如此，我衷心同意如果我们添加此类类别，则必须由机器人完成。User:Atsirlin说“手动创建类别将是一场灾难”是完全正确的。Pashley (talk) 2013年1月12日 14:04 (UTC)[回复]
      • K7L，您能回应第二点中提出的担忧吗？我对现有讨论的理解是，支持创建这些（隐藏的）类别，但在翻转机器人标志之前，最好解决 Pashley 的担忧。—— Ryan • (talk) • 2013年1月17日 04:56 (UTC)[回复]
        • 规避对“新”机器人旗帜担忧的一种方法是支持#Creation of categories（相同的任务，但使用现有的Anomebot），这样就不需要重新发明轮子。最简单的解决方案。一般来说，en.WP通过允许新机器人运行一小段编辑作为测试（通常不超过50页）来处理这些问题。如果这些看起来不错，那么就批准在“机器人”旗帜下运行其余的批处理。K7L (talk) 2013年1月17日 16:48 (UTC)[回复]
  • 支持。据我理解，创建地理类别结构已达成共识，尽管对于是否应默认隐藏存在一些分歧。我自己尝试创建了一些类别，手动过程容易出错，因此让机器人完成此任务是正确的做法。—— Ryan • (talk) • 2013年1月12日 17:12 (UTC)[回复]

兴趣点文件

这目前更多的是试探性的，源于我在Travellers' Pub中提出的一个问题。鉴于许多文章开始在列表中添加经纬度标签，并且鉴于GPS的普及（不仅是卫星导航设备，许多手机也开始内置GPS），创建一个可以搜寻页面中包含经纬度标签的列表并为该页面创建PoI文件的脚本是否有用？

我建议使用GPX标准，因为它似乎是通用的最佳尝试格式（我知道Garmin MapSource将打开这些文件）。那么问题就是如何将其呈现给读者——我们是否为每篇文章设置一个/PoI页面，显示GPX文件的原始XML，然后读者必须复制并粘贴到文本文件中（这不是我喜欢的方式），或者是否有某种方法可以生成可以直接下载为GPX文件的文件。

无论如何，如果人们认为它有用并符合政策（我怀疑应该如此，因为它通常是一个只读脚本，涉及文章页面），并且能给我指出一些关于如何为MediaWiki创建脚本的有用文章或示例，我将有兴趣尝试一下。(WT-en) Nrms 03:07, 2010年3月8日 (EST)

如果我们使用一个模板来表示坐标，并发出地理微格式，如Template talk:Listing#Coordinates中所提议的（以及维基百科通过Template:Coord所做的），那么我们就可以使用像英文维基百科的Template:GeoGroup那样的一页一个模板，以KML文件的形式提供它们，例如Google地图（并通过转换，以GPX文件的形式）实时使用。我可以在大约10分钟内添加必要的代码，而且由于只涉及HTML类，所以不会有处理器开销。Andy Mabbett (Pigsonthewing); 与安迪对话; 安迪的编辑 2012年11月25日 22:57 (UTC)[回复]
目前只有一小部分列表被模板化，并且很少有坐标。如果我们要生成定位图或自动生成相同内容的链接，这需要改变。使用工具服务器脚本将需要该脚本更改为接受voy:链接而不是仅接受wikipedia:页面。如果一个列表具有标签或模板（以便可以自动提取地址、名称和其他部分），机器人可能可以从外部来源获取（纬度、经度）并将其插入文章。然而，在某些情况下，我们甚至没有这些……列表是纯文本的。定位图将是无价的，但在我们为所有页面做这些之前还有很多工作要做。K7L (talk) 2012年11月29日 16:26 (UTC)[回复]

Snowbot

我想在这里运行 Snowbot，以将旧的共享引用替换为适用的本地页面，将外部链接转换为内部链接等，自动帮助迁移过程并减少红链。我已经在英文维基百科和其他维基（包括管理员机器人）上运行过机器人很多次，没有太多问题。Snowolf 我能帮上什么忙？ 2012年11月12日 01:37 (UTC)[回复]

Thehelpfulbot

从用户页面来看，User:Thehelpfulbot似乎是一个机器人，因为它正在更新国家旗帜，我已经将其标记为机器人。根据政策在此处列出。-- Ryan • (talk) • 2012年11月12日 19:22 (UTC)[回复]

The Anomebot2

从酒吧扫来的： K7L (talk) 2012年11月25日 21:33 (UTC)[回复]

地理编码机器人 你好！我是英文维基百科地理坐标项目的一员。我操作w:en:User:The Anomebot2，一个在该项目上添加和维护地理编码的机器人。你可以在这里看到它最近的一些工作。

我提取了en: Wikivoyage上目前没有地理模板但enwiki上对应文章有坐标的文章列表。我做了大量的数据清洗，目前有2317 6687篇文章没有地理数据模板，但我从enwiki获取了它们的坐标。如果有人愿意授予User:The Anomebot2在此处的机器人权限，我将很乐意将这些坐标添加到这些文章中。-- The Anome (talk) 21:21, 25 November 2012 (UTC)[reply]

  • 奇怪的是没有人评论这个……目前的现状是，如果我们有城市/城镇的坐标就会显示（尽管单个列表中的lat=和long=字段目前不起作用）。因此，这看起来很有用。K7L (talk) 20:16, 27 November 2012 (UTC)[reply]

已授权 --Peter Talk 00:35, 29 November 2012 (UTC)[reply]

非常感谢。我将创建一个经过调整的机器人后端版本，以处理Wikivoyage的文章格式，然后在本周晚些时候开始进行编辑。-- The Anome (talk) 19:13, 2 December 2012 (UTC)[reply]
更新： 我已经为10995 11000多篇文章添加了坐标，这是目前我能自动完成的最大数量，再多就需要编写更多模式匹配代码，耗费不合理的编程工作。-- The Anome (talk) 22:40, 7 December 2012 (UTC) -- 更新于 2012-12-09[reply]

在我最近添加了11000多个坐标（来源于enwiki和/或GNIS上的等效文章）之后，我注意到这里仍然有很多文章可以链接到维基百科，但它们没有。我可以在以下基础上高精度地自动生成很多这类链接：

对于美国以外的地点：

  • Wikivoyage上包含isPartOf或isIn模板
  • Wikivoyage和enwiki上具有相同的基本名称
  • enwikivoyage上只有一个具有该基本名称的文章（即去除消歧后缀后，以及在Wikivoyage的情况下，也去除斜杠前缀后）
  • enwiki上只有一个具有相同基本名称的文章
  • 通过Wikivoyage面包屑图的树遍历识别的单一国家位置与通过维基百科类别图的树遍历识别的国家一致
  • NGA GNS数据表明在该国家只有一个该名称的地点

我还可以使用按州和县消歧（使用GNIS数据）为美国文章生成链接，格式为Wikivoyage“地名（州）”<->维基百科“地名，州”。（或者只使用维基百科“地名”，使用与非美国地点相同的规则，但使用GNIS数据而不是GNS。）

完成后，我可以在这里轻松地将生成的跨语言链接添加到文章中。我最好的估计是这将生成至少数千个新的跨语言链接。这些链接反过来将成为以后从enwiki到Wikivoyage的反向链接创建、将坐标（如果适用）从enwiki复制到Wikivoyage的数据源，并最终与Wikidata、OpenStreetMap等集成。

如果我的机器人被授权进行这些更改，我可以在接下来的一周左右将其添加到我的待办事项队列中。-- The Anome (talk) 14:00, 9 December 2012 (UTC)[reply]

听起来不错。 Pashley (talk) 14:48, 9 December 2012 (UTC)[reply]
我也支持。--Globe-trotter (talk) 14:53, 9 December 2012 (UTC)[reply]
  • 支持。像您这样的维基百科用户能够并且愿意帮助编写这类任务的脚本，这非常令人赞赏和极其有用——当我查看启用“显示机器人”标记的Special:RecentChanges时，幕后完成了如此多的工作，这让我印象深刻。-- Ryan • (talk) • 16:47, 9 December 2012 (UTC)[reply]
  • 评论：如果你将来使用这个功能从维基百科的“外部链接”生成反向链接到Wikivoyage，请确保任何标记为“stub”或“outline”的页面不获取反向链接？这些页面大多是“X在Y中”，后面跟着一个空模板，完全没有价值。（不知道我们为什么保留它们。） K7L (talk) 15:57, 11 December 2012 (UTC)[reply]
谢谢。我正在处理这项工作——像以前一样，这可能需要几天到一周的时间。-- The Anome (talk) 18:44, 9 December 2012 (UTC)[reply]
更新：我已经为非美国地区生成了4000多个潜在的跨语言链接。其中大约一半已经有跨语言标签，因此在这一轮完成后，预计将增加约2000个跨语言标签。然后我将处理美国地区。-- The Anome (talk) 15:03, 10 December 2012 (UTC)[reply]
好的，目前就到这里。迄今为止总共添加了11170个坐标和2150个跨语言标签。如果您能想到任何其他我可以提供帮助的方式，请在我的enwiki讨论页给我留言。-- The Anome (talk) 19:26, 10 December 2012 (UTC)[reply]

好的，我又有了几个想法

我一直在寻找一些小烦恼，看看是否可以用机器人轻松解决。这是另一个。

目前有547个页面包含指向已重命名页面的IsPartOf标签。例如，Córdoba_(city,_Argentina)目前被标记为IsPartOf Cordoba (province, Argentina)，但应该标记为IsPartOf Córdoba (province, Argentina)。同样，Polesie被标记为IsPartOf Lublin_Voivodship，而不是正确的Lubelskie。

因此，这些文章中的面包屑无法正常工作。如果你们批准，我可以使用脚本修复这些问题，将所有损坏的标签更新为指向正确的重定向目标。

我还可以做另一件事，就是找出最后剩余的IsIn标签，并修复它们。-- The Anome (talk) 02:18, 11 December 2012 (UTC)[reply]

修复损坏的面包屑链接在很多人的待办事项中，但从未完成，所以如果你能修复它就太棒了！-- Ryan • (talk) • 02:25, 11 December 2012 (UTC)[reply]
这怎么运作？它是否找到指向没有面包屑的重定向的“isIn”或“isPartOf”标签？我只是想知道Russia (Asia)（一个包含#REDIRECT [[Russia]] {{isPartOf|Asia}}的重定向）是否会被保留（这个重定向是为了让Siberia“isIn”Russia (Asia)，这样它就能获得Asia的面包屑而不是Europe的）。K7L (talk) 03:01, 11 December 2012 (UTC)[reply]
它只是查找指向重定向页面的IsPartOf标签，并使用该替换，而不查看重定向目标本身是否具有标签。它不一定会使事情变得正确，但通常会使它们变得更好，并且永远不会使它们变得更糟。我可以添加检查，但我看不到有什么意义：简单的启发式方法可以使事情95%正确，并且不会使任何事情变得更糟，这通常比更复杂的启发式方法更可取，因为后者更难调试。我目前不尝试遵循多个重定向链：尽管我很容易就能做到——它只有一行代码，我看不出它有什么害处。
我会保留Russia (Asia)的权宜之计，因为它指向的是页面片段，而不是页面：然而，它确实暴露了整个面包屑系统的一个边缘情况：即地域和地理边界的包含图形成一棵树，而不是一个更一般的图的假设，这很难修复，除非以编程方式作为面包屑支持代码重写的一部分。
修复IsIn更简单：我将简单地从转储中grep出所有它们，并在将IsIn更改为IsPartOf的同时对其目标字符串进行取消转义。同样，在此过程中，我不会进行任何过于复杂的检查，例如检查目标是否存在或是否具有标签，因为它实际上不会使任何事情变得更好：经验告诉我，最好将事情分解为一组简单、笨拙、无害的任务，而不是试图一次性解决所有问题。
顺便问一下，能给我这个父账户回退员权限吗？这将使机器人调试变得容易得多。-- The Anome (talk) 13:57, 11 December 2012 (UTC)[reply]
你也能把所有IsIn引用都改成IsPartOf吗？--Globe-trotter (talk) 21:40, 11 December 2012 (UTC)[reply]
是的：我上面提到了。-- The Anome (talk) 22:30, 11 December 2012 (UTC)[reply]
我认为我们在这个维基上没有启用回退员权限。–sumone10154(talk) 18:51, 12 December 2012 (UTC)[reply]

好的，我现在已经将主命名空间和File:命名空间中大约6300个IsIn实例替换为适当的IsPartOf标签。元页面中的使用保持不变。Yes 完成

并且也修复了几乎所有指向重定向页面的IsPartOf实例。可能还剩下一些边缘情况：我在做这些时一直很谨慎。Yes 完成 -- The Anome (talk) 14:25, 14 December 2012 (UTC)[reply]

DMOZ

我正在努力生成一组新的DMOZ链接，因为这里现有的链接似乎状况不佳：这里的人是否同意我这样做？-- The Anome (talk) 19:28, 14 December 2012 (UTC)[reply]

Sumone的机器人（下方）之前尝试通过删除不正确的“Region”前缀来修复其中一些。你的机器人正在做什么？假设它没有什么疯狂的，我完全同意——你迄今为止的工作非常出色。-- Ryan • (talk) • 19:43, 14 December 2012 (UTC)[reply]
扫描DMOZ、Wikivoyage、维基百科和GNS类别树，并为所有能找到的明确无误的内容生成链接。匹配逻辑非常简单（遍历所有三棵树中的所有根到叶弧，检查每条自上而下的路径是否名称相同，包括消歧，国家相同，并且所有三个来源中该国家只有一个该名称的地点），而且我已经拥有所有必要的数据集和工具。Sumone可能已经发现并/或修复了所有这些，在这种情况下，这将只是验证他们的工作并提供交叉检查。如果不是，我至少可以添加更多链接，或者生成我的链接和Sumone的链接之间的差异列表，或者两者兼而有之。-- The Anome (talk) 20:02, 14 December 2012 (UTC)[reply]
我觉得不错……放开机器人吧。-- Ryan • (talk) • 21:24, 14 December 2012 (UTC)[reply]
看来在某些情况下，机器人可能会添加重复的Dmoz标签：。-- Ryan • (talk) • 21:55, 14 December 2012 (UTC)[reply]
是的，我大约十分钟前发现了这个bug（并希望已正确修复）：我列出了在此之前处理的250篇文章，我将对这些文章进行另一次处理以删除重复项：我最好的猜测是大约有20篇文章需要跟踪和修复。-- The Anome (talk) 22:07, 14 December 2012 (UTC)[reply]

更新：看起来大约有4000个新的DMOZ标签正在路上：直到机器人完成编辑，我才能知道确切的数量，因为该过程的最后阶段会在编辑时查看实时副本，并执行最终检查。-- The Anome (talk) 01:21, 15 December 2012 (UTC)[reply]

机器人现在已经为5175篇文章添加了DMOZ链接。Yes 完成 -- The Anome (talk) 00:36, 16 December 2012 (UTC)[reply]
太棒了。--Globe-trotter (talk) 01:09, 16 December 2012 (UTC)[reply]
同意，太棒了。谢谢你！-- Ryan • (talk) • 01:58, 16 December 2012 (UTC)[reply]

Wikivoyage不同语言版本之间存在许多虚假的跨语言链接，例如从Rio Grande do Sul到fi:Rio Grande do Sul的链接。许多文章中也有大量被注释掉且通常完全无效的跨语言链接，大概曾作为模板流程的一部分添加，现在似乎除了制造混乱外没有任何作用。我很乐意处理这些文章，删除所有这些链接。-- The Anome (talk) 21:32, 17 December 2012 (UTC)[reply]

我支持，但有一个问题——如果芬兰语维基导游重新启动，有没有办法重建跨语言链接？其他WMF项目在新语言版本启动时如何管理？-- Ryan • (talk) • 21:37, 17 December 2012 (UTC)[reply]
我等等看，因为我们预计大多数语言版本会重新启动。不过，那些被注释掉的潜在跨语言链接是个坏主意，应该删除。--Peter Talk 22:07, 17 December 2012 (UTC)[reply]
好的。我可以轻松地只从包含注释掉的跨语言链接的约1500篇文章中删除它们，而保留其他跨语言链接，无论是否有效（除了那些链接到明显不可能的目标，如空字符串或FULLPAGENAME）。我将在未来一两天内完成这项工作。-- The Anome (talk) 11:52, 18 December 2012 (UTC)[reply]
Yes 完成 -- The Anome (talk) 23:30, 5 January 2013 (UTC)[reply]

wts: 类别链接不再有任何作用，现在只是杂乱无章：它们甚至对查找潜在的维基共享资源链接（这可以通过算法更好地实现）也毫无用处，所以我看不出有什么理由保留wts链接。如果这里允许，我可以非常简单地删除所有这些链接：它们目前存在于约1400篇文章中。-- The Anome (talk) 23:33, 5 January 2013 (UTC)[reply]

  • 支持。-- Ryan • (talk) • 00:01, 6 January 2013 (UTC)[reply]
  • 在其他Wikivoyage项目中，我使用wts:链接来查找共享资源上的正确类别，并且在大多数情况下效果很好。所以，我不同意它只是垃圾的说法。而且只有1400个页面也不算多。我更希望有人先为文章添加共享资源链接，然后再通过算法添加共享资源链接，这样wts链接就不再需要了。我有添加共享资源链接的经验，基于此，我确实想先看看添加这些链接的方法。Romaine (talk) 02:10, 6 January 2013 (UTC)[reply]
  • 我想，通过遵循wikipedia:链接，找到潜在的commons:链接的机会会比尝试匹配wts:更大，对吗？ K7L (talk) 04:02, 6 January 2013 (UTC)[reply]
    • 没错。在早些时候的机器人运行之后，大多数文章现在都有到英文维基百科的链接。现在，我可以使用从转储中获取的数据，将这些链接与相应维基百科文章中到维基共享资源分类的链接进行交叉引用，从而创建要添加到这里的维基共享资源分类链接。-- The Anome (talk) 10:13, 6 January 2013 (UTC)[reply]
    • 好的，我现在已经完成了一半，正在清理和验证数据。目前我有6300多个维基共享资源分类链接候选，我希望这应该能弥补wts:链接的损失。更多信息稍后。-- The Anome (talk) 13:55, 8 January 2013 (UTC)[reply]
      • 我目前正在添加commons:链接：我将暂时保留wts:链接，直到这里就如何处理它们达成共识。-- The Anome (talk) 22:23, 8 January 2013 (UTC)[reply]
        • 我重申我支持删除“wts”链接——它们不是生成commons:链接的可靠方式，如果你的机器人已经生成了commons:链接，那么它们现在无疑只是杂乱无章。-- Ryan • (talk) • 22:27, 8 January 2013 (UTC)[reply]
          • 我现在已经将维基共享资源的链接添加到了5400多篇Wikivoyage文章中。Yes 完成

            我提议现在让机器人从所有现在包含维基共享资源链接的文章中删除多余的wts:链接。然后我可以对其他文章中剩余的wts:链接进行调查，看看它们是否包含任何有用的信息。-- The Anome (talk) 19:15, 9 January 2013 (UTC)[reply]

        • 把它们炸回真主或你选择的神灵那里去，它们现在没用了。 K7L (talk) 19:32, 9 January 2013 (UTC)[reply]

更新：我已从现在拥有commons:链接的页面中删除了wts:链接。在此之后，只剩下大约700个页面还有wts:链接—— The Anome (talk) 20:43, 10 January 2013 (UTC)[reply]

更新：我现在已经删除了完全匹配页面标题的wts:链接，因此它们没有文章标题中已有的额外信息内容。在此之后，只剩下大约170个wts:链接。-- The Anome (talk) 21:12, 10 January 2013 (UTC)[reply]

更新：我现在已经用{{wts}}模板替换了剩余的170多个wts:链接，除了将文章包含到一个隐藏类别Category:Pages with old wts links之外，它没有可见的效果。我认为这在目前已经解决了wts:链接的问题。Yes 完成

接下来：更彻底地匹配wv:文章到维基共享资源和维基百科条目。但可能要等到一周左右。-- The Anome (talk) 21:54, 10 January 2013 (UTC)[reply]

创建类别

我很乐意遍历整个面包屑导航树（我已经解析过），以生成所有需要的类别。我最初会将它们都命名为“<X>中的地点”。然后可以更改{{IsPartOf}}模板，使其自动将文章包含在其各自的类别中。这将大大减少需要编辑的页面数量，否则我将不得不编辑每个单独的指南内容页面。

我可以假设这是没问题的吗？关于政策，我们似乎在此页面上的其他地方（参见下面的K7Lbot讨论）已经达成共识并获得授权，认为这是一个好主意。如果得到批准，我可以很快完成这项工作。 -- The Anome (讨论) 2013年1月15日 21:01 (UTC)[回复]

请注意下面User:K7Lbot的讨论。已经有一个经过测试的类别格式、命名、内容以及ispartof模板的语法。经过测试，运行良好，只需要生成大量的类别。 --Traveler100 (讨论) 2013年1月15日 21:44 (UTC)[回复]
支持。使用现有的“机器人”可以避免创建新机器人。我有一个类别列表（来自数据库转储），在user:K7L/isPartOf，但这些需要删减，以删除任何叶节点（没有任何其他子节点的目的地不需要同名类别）。我建议输出的措辞不是“X在Y中”，而是{{某个模板|X|Y}}，这样每个页面都可以通过编辑某个模板来更改格式。 K7L (讨论) 2013年1月15日 21:49 (UTC)[回复]
我正在处理转储中包含的面包屑导航，检查其一致性和合理性，然后准备开始创建一些类别。看起来大约需要3000个。 -- The Anome (讨论) 2013年1月17日 11:28 (UTC)[回复]
好的，现在开始做。请参阅Category:Val di Chiana了解示例。 -- The Anome (讨论) 2013年1月19日 21:49 (UTC)[回复]
由于它没有自上而下地创建类别（我想这很难编程），我建议在完成后对{{RegionCat}}进行小幅编辑，以重新保存类别并更新内容。或者有更好的方法吗？ --Traveler100 (讨论) 2013年1月19日 21:56 (UTC)[回复]
我刚刚在{{IsPartOf}}和{{RegionCat}}中添加了空的HTML注释。这应该会导致所有文章被重新渲染，所有类别被填充，直到文章级别。缺点是完成这批重新渲染将需要网站几个小时才能完成，但我们有充足的时间——明天看到结果就足够了。 -- The Anome (讨论) 2013年1月19日 23:33 (UTC)[回复]
初步看起来不错。干得好。--Traveler100 (讨论) 2013年1月20日 06:07 (UTC)[回复]
这已经为许多单独目的地（被设置为省/州/国家“PartOf”而不是更精确的子区域）识别了许多大纲。大多数实际内容很少。仍然报告作业队列中有一千个作业，所以这应该会让服务器忙一段时间。 K7L (讨论) 2013年1月20日 08:18 (UTC)[回复]
没错。输出内容的好坏取决于输入内容。幸运的是，更改这些文章的{{IsPartOf}}条目也应该更改它们所属的类别，并且对于那些具有相关地理知识的人来说，类别树现在提供了一种快速查找存在此问题的文章的方法。 -- The Anome (讨论) 2013年1月21日 06:41 (UTC)[回复]

类别创建现已完成。 是 完成 -- The Anome (讨论) 2013年1月23日 12:11 (UTC)[回复]

太棒了，谢谢你。这看起来对保持文章层次结构的组织将非常有用。 -- Ryan • (讨论) • 2013年1月23日 15:56 (UTC)[回复]

地区

你的机器人一直在区县文章中添加许多IsPartOf标签，比如上海/外滩，一个例子是。这些应该是不需要的。请参阅Wikivoyage_talk:Breadcrumb_navigation#Districts和Wikivoyage_talk:Breadcrumb_navigation#Districts_2。

这是为了解决解析错误而故意采用的权宜之计吗？如果不是，那么添加在错误修复后不再需要的标签，并同时隐藏错误行为，这不是一个好主意。 Pashley (讨论) 2013年1月27日 17:05 (UTC)[回复]

按照代码更新的速度，看来十二月编写的补丁（比如在WT链接上添加rel="nofollow"或通过{{listing}}模板重定向标签输出）仍在等待部署，应该会在下一次实际站点更新（可能在2月11日左右）中上线。isPartOf/district错误已经报告，但尚未提出修复方案，因此在下次更新之前通过代码审查的补丁可能不太现实。从长远来看，当然需要一个适当的错误修复，但这目前帮不了我们。 K7L (讨论) 2013年1月27日 17:31 (UTC)[回复]

还有其他需要关注的事情吗？

大多数城市或地区文章的名称后面都应该有一个链接。例如

  • 厦门 (厦门; Xiàmén) 是中国福建省的一个沿海城市。

该链接应指向当地旅游局或当地政府。

我不认为机器人能够修复这些缺失或指向错误链接的问题。然而，生成一个没有此类链接的文章列表应该很简单。短语手册、旅行主题、行程、讨论页和用户页可以忽略。 Pashley (讨论) 2013年2月7日 02:08 (UTC)[回复]

过去一周我一直在添加维基百科文章的跨语言链接，以测试问题的范围。结果，我确信有数千篇文章可以链接但尚未链接。链接这些文章将有助于维基导游与其他项目之间的协作，并通过在维基百科中添加指向足够成熟的维基导游文章的链接，从而增加来自维基百科的流量。

尽管我已经链接了大量的文章，但对于一个人来说，在合理的时间内完成链接任务的文章太多了。然而，我相信这项任务可以通过众包的方式轻松处理。

因此，我为这些文章建立了一个实验性跟踪方案，旨在帮助这一过程。它使用了Template:No Wikipedia link，该模板生成指向隐藏类别Category:Articles without Wikipedia links的链接。该模板还接受一个可选参数，如果需要，最终可用于将文章添加到此维护类别的每个国家子类别中。作为实验，我已将此模板添加到Brouage和Tierra del Fuego National Park。

现在我想用我的机器人将这个模板添加到数千篇文章中，以启动这个过程。 -- The Anome (讨论) 2013年3月2日 21:11 (UTC)[回复]

更新1：请参阅Wikipedia:Template:Coord missing，这是另一个使用机器人生成模板和隐藏类别来众包手动处理类似任务的示例。 -- The Anome (讨论) 2013年3月2日 21:18 (UTC)[回复]
更新2：我已经扫描了最新的转储，似乎有超过6000篇文章是维基百科跨维基链接的候选，但尚未链接。这既是（a）一项相当艰巨的积压任务，也是（b）一个增加维基导游流量可见度的重要长期机会。 -- The Anome (讨论) 2013年3月2日 23:46 (UTC)[回复]

你好——这里有人能再给我一个认可吗，这样我就可以继续编辑了？谢谢， -- The Anome (讨论) 2013年3月4日 20:06 (UTC)[回复]

  • 支持。依你看来，我们是否已经用尽了所有自动化机会？我们是否已经对跨语言链接进行了彻底的尝试（链接到语言版本，然后链接到维基百科语言版本，再链接到en.wp）？我不太相信这种规模是我们可以实际操作的。 --Inas (讨论) 2013年3月4日 20:15 (UTC)[回复]
    • 还没有完全耗尽，不，但我已经通过自动化匹配处理了大部分最容易实现的目标。这样做将有两个好处：首先，它将有助于协调手动匹配过程（经验表明，手动匹配可能比你想象的更有效，因为有些人喜欢有可以逐一完成的任务列表——例如，我一个月内处理了大约500篇这样的文章，几乎是整个工作量的十分之一），其次，它希望能让我看到剩余部分的模式，以及人们进行匹配的模式，从而为更细粒度的自动化匹配过程提供灵感。维基百科的经验表明，这种多种人工和手动方法的结合非常有效：Wikipedia:WP:COORD项目迄今已通过这种方式处理了数十万篇文章。 -- The Anome (讨论) 2013年3月4日 20:26 (UTC)[回复]
      当然，我很高兴你是对的。让我们拭目以待。 --Inas (讨论) 2013年3月4日 20:28 (UTC)[回复]

这个模板还会用到吗，还是我们可以把它删除？ Texugo (讨论) 2013年10月10日 18:07 (UTC)[回复]

  • 支持，至少原则上是。机器人会将模板放在文章的哪个位置？它会放在维基百科链接应该放置的位置吗，这样任何添加维基百科链接的人都能看到模板？另外，模板旁边可以添加一个注释，写上“如果您为这个目的地添加了维基百科文章的链接，请删除此模板”吗？ Nurg (讨论) 2014年2月11日 07:35 (UTC)[回复]

User:Sumone's bot

我想使用w:wp:AWB运行一个机器人进行各种查找和替换清理（例如修复dmoz链接）。我一直在我的常规账户（半自动模式）上使用AWB，但我想在机器人账户上以自动模式运行它。 –sumone10154(讨论) 2012年12月12日 01:23 (UTC)[回复]

当然，我也会在其他语言版本上请求机器人批准。 –sumone10154(讨论) 2012年12月12日 20:21 (UTC)[回复]

我已经修复了大约2000个dmoz链接；如果还有任何损坏的链接，请告诉我，我会看看它们是如何被遗漏的。

我还可以将所有wts:category链接替换为Commons类别链接。但是，有些类别的命名不同，或者可能在Commons上根本不存在。我的机器人无法检查这种情况；我是否应该仍然进行这些替换，还是应该手动完成？ –sumone10154(讨论) 2012年12月13日 02:01 (UTC)[回复]

我认为如果wts:替换不能准确完成，那么最好跳过那篇文章，我们可以手动更新它，或者等到Sumone's bot 9000™创建出来，使用秘密技术更准确地确定Commons链接（也许通过跟踪维基百科跨语言链接并使用与链接文章相同的Commons跨语言链接？） -- Ryan • (讨论) • 2012年12月14日 01:49 (UTC)[回复]
最后一个听起来很有趣。我会研究一下。 -- The Anome (讨论) 2012年12月14日 20:03 (UTC)[回复]
更新：为了获得指向Commons类别的直接跨语言链接，例如[[Commons:Category:London]]，这似乎是这里所需要的，我认为最简单的路径是：Wikivoyage文章 -[跨语言]-> 维基百科文章 -[类别链接]-> 维基百科类别 -[跨语言]-> Commons类别。enwiki上也有Template:Commons_category，但在许多页面上都没有出现，例如enwp:London，那里通常会预期出现。加上所有必要的交叉检查，这似乎需要大量的工作才能获得相应的收益：所以，综合考虑，我暂时放弃这个任务，寻找一些短期内具有更高成本效益比的机器人任务。 -- The Anome (讨论) 2012年12月16日 17:53 (UTC)[回复]
我们也可以先删除所有wts链接，然后批量添加Commons链接。 --Globe-trotter (讨论) 2012年12月14日 20:55 (UTC)[回复]
我现在已经批量添加了Commons链接，并正在寻求从所有带有Commons链接的文章中删除wts:链接，然后调查其他文章中剩余的wts:链接——请参阅上面小节中的讨论。 -- The Anome (讨论) 2013年1月9日 19:19 (UTC)[回复]
全部是 完成。参见上文。 -- The Anome (讨论) 2013年1月15日 21:04 (UTC)[回复]

Crochet.david.bot

Crochet.david (讨论) 2013年1月4日 20:29 (UTC)[回复]


CarsracBot

  • 机器人管理员：User:Carsrac
  • 机器人名称：User:CarsracBot
  • 其他项目中的机器人标记列表：完整列表 (所有维基百科项目) 全局机器人权限。
  • 目的：跨语言链接
  • 技术细节：pywikipediabot，最新版本

Carsrac (讨论) 2013年1月18日 17:30 (UTC)[回复]

RileyBot

Riley Huntley (讨论) 2013年1月19日 09:40 (UTC)[回复]

我将大胆地勇往直前，对Template:涂鸦墙做同样的事情。 -- 敬礼， Riley 2013年1月20日 21:18 (UTC)[回复]

RileyBot 2

-- 敬礼， Riley 2013年1月26日 09:46 (UTC)[回复]

User:Hoo User Page Bot

此脚本因缺少提名而被阻止，所以我在此提名。根据描述：

此机器人同步所有维基的用户和用户讨论页面。同步可在此处请求。如果它做了不该做的事情，请随意投诉。每个请求都由Hoo man执行和审核。

这看起来是维基媒体项目上运行的标准机器人，所以我认为在此运行它没有害处。

感谢标记机器人。它会继续编辑这个维基。- Hoo man (talk) 2013年2月3日 (UTC) 14:29[回复]


User:inasbot

  • 机器人操作者：user:Inas
  • 机器人名称：User:Inasbot
  • 目的：在主命名空间旅行指南中将“联系方式”标题重命名为“连接”。
  • 技术细节：pywikipediabot，replace.py

既然需要完成这项工作，而且没有人自愿运行它……--Inas (talk) 2013年2月28日 (UTC) 10:22[回复]

是的。我在主命名空间中运行了许多文件，所以我相信这部分会没问题。至于我是否能在不让机器人编辑的最近更改信息堆积如山的情况下扫描整个主命名空间几个月，那是另一回事了，但我们会看看。我已经在User:Inasbot/testcases设置了测试用例。如果你觉得需要通过/失败任何其他测试，可以添加它们。--Inas (talk) 2013年2月28日 (UTC) 11:15[回复]
完成了。--Inas (talk) 2013年2月28日 (UTC) 11:17[回复]

User:Traveler100bot

删除未使用的模板似乎得到普遍支持。--Traveler100bot (talk) 2013年3月3日 (UTC) 14:02[回复]

我假设如果我扩展逻辑，我需要申请或者至少再次检查？我想做以下事情：

如果页面上存在“==Cities==”部分标题，则将包含{{outline}}的文章更改为{{outlineregion}}。

已经手动检查了几次半自动运行，似乎运行良好。--Traveler100 (talk) 2013年3月9日 (UTC) 15:39[回复]

根据以下逻辑，将包含{{outline}}的文章更改为{{outlinecity}}或{{outlineregion}}或{{outlinepark}}：

  • 如果包含==Cities==|==Towns and villages==|==Regions==|==Cities and towns==|is a region
    • 标记为outlineregion
  • 如果包含is a city|is a town|is a village|is the main city|is the capital city
    • 标记为outlinecity
  • 如果包含==Fees/Permits==
    • 标记为outlinepark

已手动测试了120个页面，编辑了60个，跳过了其他页面。--Traveler100 (talk) 2013年3月29日 (UTC) 13:48[回复]

这可能是对已弃用标签进行自动操作的最后一种可能性，而且存在少量出错的风险。

在手动检查每次编辑的不同变体运行几天后，我现在认为我有一个脚本可以更正电话号码。它不会更正所有号码，并且会跳过许多格式不规范的号码。因此，这不会完全移除，但希望能减少缺少国家代码的电话号码列表和电话格式有问题的列表页面数量。这不仅是为了保持一致性，也是为了允许在智能手机上通过Wikivoyage中的链接拨打电话。现在我想提议将其作为机器人运行。Traveler100 (talk) 2013年10月1日 (UTC) 20:00[回复]

当然，去吧。Ikan Kekek (talk) 2013年10月1日 (UTC) 23:12[回复]
  • 您能提供一些机器人将进行的样本编辑的链接吗？我完全支持清理网站上一些混乱的电话号码，但我想更好地了解具体将更改什么。-- Ryan • (talk) • 2013年10月2日 (UTC) 01:58[回复]
当前逻辑的编辑 --Traveler100bot (talk) 2013年10月2日 (UTC) 05:33[回复]
在这里，机器人删除了连字符；这是基于机器人知道518区号允许7位拨号吗？还是删除区号和本地号码之间的连字符的一般政策？ LtPowers (talk) 2013年10月2日 (UTC) 16:18[回复]
它会移除区号和本地号码之间的连字符。这是我目前对建议的理解。--Traveler100 (talk) 2013年10月2日 (UTC) 18:54[回复]
根据编辑历史，机器人只处理美国电话号码吗？我在进行列表的文本到模板转换时，发现非美国列表使用了各种格式。假设这仅适用于美国，并且LtPowers的担忧可以得到解决，那么我支持。-- Ryan • (talk) • 2013年10月3日 (UTC) 00:09[回复]
不，我打算为每个国家/地区进行操作，只是确保国家/地区代码正确的最简单方法是一次处理一个国家/地区（德国已经手动完成）。我是否从评论中理解，格式“<国家代码>空格<地区代码>空格<带破折号的本地号码>”只应应用于美国？--Traveler100 (talk) 2013年10月3日 (UTC) 05:30[回复]
其他国家要小心——我遇到了各种奇怪的格式，尤其是一些印度文章，我的解析器甚至无法识别这些数字是电话号码。至于格式细节，希望其他人能回答——我从来没有足够关心日期格式、电话号码格式等的细微差别，并把这些细节留给其他人去争论。-- Ryan • (talk) • 2013年10月3日 (UTC) 05:39[回复]
传统上，我们使用连字符来表示电话号码中哪些部分可以本地拨打。因此，在美国，对于免费电话号码，我们会使用“+1-800-555-5555”；对于强制10位拨号的区域，我们会使用“+1 212-555-5555”；对于7位拨号的区域，我们会使用“+1 518 555-5555”。 LtPowers (talk) 2013年10月3日 (UTC) 14:29[回复]
实际上应该是“+1-212-555-5555”，本地呼叫需要所有11位数字。K7L (talk) 2013年10月4日 (UTC) 02:28[回复]
那他们为什么称之为十位拨号呢？ =) LtPowers (talk) 2013年10月4日 (UTC) 12:17[回复]
他们不这么称呼。根据，十位拨号是波士顿式号码“617 MA 10D”，但纽约市/洛杉矶/芝加哥是“1+10D”。实际上，这三个城市或其周边地区没有固定费率本地通话，一切都是按表计费的。从麦迪逊广场花园打到街对面的“PEnnsylvania 6-5000”是+1-212-736-5000，11位数字，就像从檀香山打过来一样。“212 NY 1+10D” K7L (talk) 2013年10月4日 (UTC) 18:14[回复]
啊，抱歉；我没有意识到你特指212区号。在这种情况下，我的例子选错了。我只是想随便想一个重叠的区号，但不小心选择了一个附带特殊规则的。请随意替换成其他重叠的区号，比如416。 LtPowers (talk) 2013年10月4日 (UTC) 21:04[回复]

User:SteveRBot

  • 机器人主：user:SteveR
  • 机器人名称：User:SteveRBot
  • 目的：乌克兰语维基导游最近启动。机器人会根据需要添加来自uk.wikivoyage和其他维基导游的跨语言链接。
  • 技术细节：机器人使用pywikipediabot库。在en.wikivoyage上，机器人将只使用interwiki.py。您可以在此处阅读有关它的信息。--SteveR (talk) 2013年4月1日 (UTC) 17:25[回复]

User:Traveler100bot 页眉

如User:Traveler100bot和Wikivoyage_talk:TOC/Banner讨论中所述，将页面横幅模板添加到奥地利的位置页面。--Traveler100 (talk) 2013年4月14日 (UTC) 05:12[回复]

User:Kolega2357-Bot

--Kolega2357 (talk) 2013年5月12日 (UTC) 23:08[回复]

Rschen7754，你有什么问题？你对我如此复杂。机器人有自己的文件夹，而不是其他Wiki项目在同一个文件夹。不要制造战争更改。这样运行 python interwiki.py -autonomous -start:A -lang:en。--Kolega2357 (讨论) 2013年5月13日 07:45 (UTC)[回复]

@Pashley：我已向所有本地行政员提出请求。--Kolega2357 (讨论) 2013年5月16日 09:20 (UTC)[回复]

有没有管理员能解除我机器人的封禁，它已经 inactive 超过一个月了。--Kolega2357 (讨论) 2013年7月1日 21:47 (UTC)[回复]

为什么？没有理由需要解除封禁。--Rschen7754 2013年7月1日 22:05 (UTC)[回复]

有一个原因，我看到了这个，并且维基导游正在将跨语言链接迁移到维基数据。我在这里签署了。--Kolega2357 (讨论) 2013年7月1日 22:13 (UTC)[回复]

那不意味着我们必须授予你机器人权限；还有很多其他机器人操作员。--Rschen7754 2013年7月1日 23:12 (UTC)[回复]
反对 暂时。我甚至无法弄清楚这个机器人提议的任务是什么。我们还没有开始使用 Wikidata，如果提议只是更新跨语言链接，我们已经有正在运行和测试的机器人处理这些链接；我认为我们不需要也不希望多个机器人同时执行相同的任务。如果提议是其他内容，则需要进行解释，涵盖页面顶部列出的三个关键点。-- D. Guillaume (讨论) 2013年7月1日 23:16 (UTC)[回复]

为什么用户Rschen7754如此偏执？我想要在这里获得机器人标记。如果所有感兴趣的机器人操作员在不久的将来都能做到，为什么我不能呢？为什么其他人都能做到，而我不能？请假定善意。--Kolega2357 (讨论) 2013年7月1日 23:27 (UTC)[回复]

此处机器人旗帜的批准要求对请求没有未解决的异议，鉴于当前的异议与commons:Commons:Administrators' noticeboard/Archive 41#Kolega2357中提出的担忧相关，你需要提供一个讨论链接或其他证据，证明这些问题已经成功解决。在此之前，继续在此请求权限可能毫无意义。-- Ryan • (讨论) • 2013年7月1日 23:53 (UTC)[回复]

不再有这样的问题了，我在维基共享资源上不再拥有 FileMover 权限。我在几个维基导游项目上拥有机器人标记。--Kolega2357 (讨论) 2013年7月2日 00:21 (UTC)[回复]

是的，因为它们大多处于非活动状态和/或不知道你的跨wiki记录。--Rschen7754 2013年7月2日 02:11 (UTC)[回复]

User:Wrh2Bot

XML 列表转换为模板

旨在将旧版 XML 列表转换为模板化列表，参见Wikivoyage talk:Listings#Tags to templates。有关主命名空间中前100篇文章（按字母顺序）的示例运行，请参阅Special:Contributions/Wrh2Bot，有关日志输出，请参阅User:Wrh2Bot/ListingsToTemplate。该机器人将格式良好的 XML 转换为模板。如果机器人无法可靠地转换列表（由于标签不匹配或其他错误），则机器人会跳过该列表并向日志写入一条消息（我必须手动将日志上传到此处）。如果获得批准，我可能会在周末回家并有时间监控时启动它。-- Ryan • (讨论) • 2013年5月16日 00:19 (UTC)[回复]

我已经准备好代码，可以将 '''粗体文本''' [http://www.example.com] 形式的链接转换为 '''[http://www.example.com 粗体文本]'''，遵循 Wikivoyage:External links 的最新更改。此代码目前只适用于上述特定模式——如果链接前的文本不是粗体，则不匹配，但这只是一个开始，应该能更新网站的很大一部分。请参见以下测试

我会在未来的更新中研究转换更多链接的选项，但这确实是一项棘手的工作。-- Ryan • (讨论) • 2013年7月2日 04:35 (UTC)[回复]

  • 支持。这些测试很成功，我想不出有任何情况是不希望这样做的。像这样一点一点地完成这项工作似乎是个好主意。这大概不用说，但这只是针对主命名空间，对吗？--Peter Talk 2013年7月2日 05:00 (UTC)[回复]
    是的，仅限主命名空间。如果得到批准，我将分几小批运行，以便我可以留意情况，但我预计这种简单的模式不会出现问题。虽然这个机器人不会转换所有脚注链接，但它至少应该能处理文章开头处的官方城市链接，这是一个足够重要的链接，值得运行。-- Ryan • (讨论) • 2013年7月2日 05:06 (UTC)[回复]
  • 支持。这绝对是机器人的工作，而且这种谨慎的模式应该能很好地避免误报。同意目前需要保持在主命名空间内，因为你的用户空间沙盒测试页面显然仍然被排除在新的 CSS 之外。-- D. Guillaume (讨论) 2013年7月2日 05:07 (UTC)[回复]

已完成。更新了7000多篇文章。-- Ryan • (讨论) • 2013年7月3日 02:30 (UTC)[回复]

不错。是否有 ''斜体文本'' [http://www.example.com] 这样的模式？如果有的话，那对你的代码来说应该是一个简单的修改，所以下一步很容易做到。Pashley (讨论) 2013年7月3日 04:45 (UTC)[回复]
彼得在Wikivoyage talk:External links#Bot suggestions列出了潜在的模式，不过我们需要小心，因为很容易出现误报。斜体模式是一个很好的补充，而且肯定不会引发任何误报。-- Ryan • (讨论) • 2013年7月3日 04:56 (UTC)[回复]

文本到模板转换

几周以来，我一直在测试一个机器人，它将纯文本列表转换为使用Template:Listing的适当版本。更多细节可以在Wikivoyage talk:Listings#Text-to-template conversion找到，但总体概览是机器人非常保守，只有在极高概率正确转换的情况下才会转换字段。如果它不确定，列表要么不转换，要么如果特定字段有问题，则简单地将其作为列表“内容”字段的一部分，以便有人可以稍后手动将其移动到正确的字段。仍然存在罕见的误报——例如，在此编辑中，开头的句子“这3座小教堂围绕着圣母玛利亚”被解释为包含一个街道地址（“3座小教堂围绕着圣”）——但这些情况非常罕见且易于清理。

我们永远不会有一个可以100%准确转换的机器人（或者一个不会偶尔犯错的人），在经过数百次编辑的测试和审查之后，我认为这个机器人值得运行，但会等待几天，以防有任何反对意见（和所需的赞成票）再运行。请参阅Special:Contributions/Wrh2Bot以获取机器人测试的历史记录——到目前为止，我已手动审查了所做的每一个编辑并进行了调整以提高准确性，但现在希望让机器人自行运行。-- Ryan • (讨论) • 2013年7月19日 04:59 (UTC)[回复]

  • 支持。虽然它可能会在某些项目上造成一点混乱，但它正在转换的所有项目基本上都已经是混乱的了。这是一项太大而无法手动完成的工作；从长远来看，这将为我们节省大量时间。--Peter Talk 2013年7月19日 05:16 (UTC)[回复]

请参见meta:User:Addbot。Wikivoyage 将于下周在 Wikidata 启用。我的机器人从页面获取跨语言链接，将其放置在 Wikidata 上，然后从文章中删除不再需要的跨语言链接。这项任务目前正在所有语言维基百科项目上运行，已完成超过1400万次编辑，如果能在这里获得批准就太好了！Addshore (讨论) 2013年7月19日 12:22 (UTC)[回复]

  • 疑问 - 这项任务是否会自动获得全球机器人的批准？如果是，那么全球机器人可以在这里运行而无需额外批准。如果这不是全球机器人任务，那么我支持你的特定机器人。-- Ryan • (讨论) • 2013年7月19日 14:52 (UTC)[回复]
  • 支持 可信用户和可信机器人，尽管这可能与全球机器人问题无关（我自己也不完全确定）。--Rschen7754 2013年7月19日 23:44 (UTC)[回复]

用户:Andyrom bot 移除未知的 Print= 参数

我发现有几张图片有这个从WT导入的参数。在 voy 和 WT 中，解析器都不管理这个参数，所以必须将其移除。虽然这是一项简单的任务，但我现在正在进行50次测试修改，以便任何人都可以验证它们。--Andyrom75 (讨论) 2013年9月5日 18:44 (UTC)[回复]

它是由Wikitravel Press的解析器处理的。可能没有理由保留它们，不像其他WTP遗留语法，但也没有任何紧迫性来移除它们。LtPowers (讨论) 2013年9月6日 13:43 (UTC)[回复]
彼得，感谢你提供背景信息，我对此一无所知。我也不知道你在卖书！ :-D 如果你知道其他语法（除了 print=），请告诉我，我也会一并删除。显然不紧急，但我倾向于删除无用的内容，以避免给编辑者造成混乱，或者像那些图片没有描述，标题却是“print=...”的情况那样，避免版面混乱。--Andyrom75 (讨论) 2013年9月6日 18:56 (UTC)[回复]
哪位彼得？=) LtPowers (讨论) 2013年9月7日 18:32 (UTC)[回复]


此机器人批准仅适用于从图像标签中删除打印参数。它无权删除其他项目。LtPowers (讨论) 2013年9月9日 19:01 (UTC)[回复]

我已经清理了您链接的页面中解释的所有 WTP 遗留语法。具体来说
  • 删除所有 print= 出现
  • 删除所有 angle= 出现
  • 删除 PRINT "标签注释" 之间冗余的文本（冗余是因为所有这些出现都有相同/相似的文本在文章中）
  • 删除 WEB-START & WEB-END "标签注释"，保留它们之间的文本
如果您认为我犯了错误，请告诉我，我会毫无问题地撤销我的工作。--Andyrom75 (讨论) 2013年9月9日 21:44 (UTC)[回复]
为了做到完美，我还建议将Template:Pagebreak和Template:Index这两个模板孤立起来，它们都由 WTP 使用，并应用于少数文章。欢迎内部讨论。我不认为我在这项操作中是绝对必要的，但如果我在其他方面能提供帮助，请告诉我。--Andyrom75 (讨论) 2013年9月9日 21:50 (UTC)[回复]
如果我没有说清楚，我为此道歉。您的机器人仅被授权删除文件标签中的“print=”属性。您提到的其他内容都没有在此讨论中提及，并且您的机器人无权删除它们。“angle=”属性的删除无害，但删除 PRINT 和 WEB-START/END 标签则可能有害。这些情况都需要单独处理，机器人不应一概删除它们。请尽快恢复这些更改。LtPowers (讨论) 2013年9月9日 23:05 (UTC)[回复]
如果你认为这很紧急和关键，那么最快的方法就是管理员一键撤销机器人的所有更改。否则会耗费时间，虽然WTS在这里和WT都不起作用，但我不想拖延你的请求。--Andyrom75 (讨论) 2013年9月9日 23:14 (UTC)[回复]
我没有回滚所有的编辑，因为我不想丢失好的编辑。这可能不紧急；只是我们越晚撤销它们，就越难撤销。明白吗？LtPowers (讨论) 2013年9月10日 01:49 (UTC)[回复]
如果不是很紧急，也许值得花几分钟时间来理解是否所有都可以被视为“好的”，以及我们是否真的希望恢复那些维基媒体解析器不使用的其他标签。例如，“angle=”与“print=”一起使用，那么为什么在删除第二个标签时保留第一个标签呢？
在 PRINT 标签注释中，可以找到两种注释的维基文本。
  • 文章中已经显示的相同图片（通常在上面几行）
  • 文章中已经写好的相同文本（我记得有一个信息框使用了不同的模板，以及没有使用区域列表模板的区域列表描述）
所以，既然是冗余的，并且没有在任何媒体中显示（因为它被注释掉了，并且没有以不同的方式管理），为什么要保留它呢？
WEB-START/END 标签用于划定仅通过网络显示的文本，但目前这个标签不起作用，文本在任何媒体中都会显示，而且我认为是正确的，就像那些包含几乎整篇文章的短语集一样。如上所述，为什么要保留无用的注释？
附：抱歉回复晚了，但这里是睡眠时间 :-) --Andyrom75 (讨论) 2013年9月10日 07:12 (UTC)[回复]
正如我上面所说，“这些情况都需要单独处理，机器人不应一概删除它们。”你确定每种情况都一样吗？LtPowers (讨论) 2013年9月10日 17:06 (UTC)[回复]
如果你觉得我们有足够的时间，我们可以逐一讨论它们（我认为不会花费太多时间）。我不太明白你所说的“每个案例都一样”是什么意思；你能换个说法吗？--Andyrom75 (讨论) 2013年9月10日 19:28 (UTC)[回复]
你似乎坚信在所有这些标签被使用的情况下，它们都可以毫无顾虑地被删除。我是在问你是否对此确定。无论如何，我有点希望其他贡献者也能在这里发表意见。LtPowers (讨论) 2013年9月11日 02:06 (UTC)[回复]
所有的标签不都只是 WT Press 的残余吗？用于确定哪些内容制作了印刷版指南，哪些仅用于网络？我看不出它们有什么用处，尽管我同意在未经讨论的情况下不应该删除它们，但我认为我们有一个短暂的窗口来讨论是否应该在恢复之前保留它们。--Inas (讨论) 2013年9月11日 04:03 (UTC)[回复]
感谢 LT 的澄清。我很确定这个标签可以被移除（否则我也不会这样做）。我并没有以自动化的方式处理所有这些。我已经进行了测试，以确保布局不会有任何改变，并且我已经验证了，特别是对于 PRINT 标签，在这些标签之外是否存在等效的被移除文本（在标签内部）。WEB 标签应该用于隐藏这些标签内部的文本，使其在屏幕上没有影响，如果没有专门的解析器（如 WTS）以这种方式处理它们，这些标签就毫无用处。此外，在日语短语手册中，WEB 标签的使用方式很奇怪，因为它几乎包含了整个文章，而避免将其打印在纸上是没有意义的。--Andyrom75 (讨论) 2013年9月11日 10:19 (UTC)[回复]
不幸的是，是的，标签目前不起作用，无法阻止仅限网络的内容被打印。（Jani 在一段时间前删除了Template:Web及其所有用途，即使我们本可以通过将其包含在Category:Exclude in print中来保持其功能。WTP 专用 HTML 注释方法没有这个优势。）我只是不想失去这些语义信息——即使它们目前实际上没有任何作用——就像我们失去Template:Web一样。LtPowers (讨论) 2013年9月11日 13:22 (UTC)[回复]
这个功能可以通过不同的方式轻松恢复：通过 CSS，您可以为特定设备（如手机和打印机）分类内容，或者避免这些设备接收特定内容。这项任务不需要解析器。如果对此话题感兴趣，也许我们可以在另一个页面继续讨论。--Andyrom75 (讨论) 2013年9月11日 15:56 (UTC)[回复]
是的，有方法可以复制功能，但如果当前的打印方法比 WTP 的方法更好，其中一些可能不再需要。这就是为什么我说我们必须逐个案例地处理，而不是简单地全部删除。LtPowers (讨论) 2013年9月11日 16:51 (UTC)[回复]
事实是 CSS 的工作逻辑不同，因此它们的实现也不同，不能（例如）一对一替换。通常，CSS 应该包含在模板中，这样你就可以控制整个站点而不是单个文章片段。举个例子，我删除了一堆文本，这些文本是地区列表的“可打印副本”。正确的做法是修改Template:Regionlist，而不是修改特定的文章。--Andyrom75 (讨论) 2013年9月11日 17:27 (UTC)[回复]
诚然，但这似乎更说明了应该逐一处理而不是简单地全部删除。 LtPowers (讨论) 2013年9月12日 00:17 (UTC)[回复]

我仍然倾向于认为它们的基础是 WTP 的编辑决定。就我个人而言，如果我得到一份打印件，我希望拥有所有网络上存在的信息，并根据需要应用自动格式。我不想任何人手动决定我的打印件中应该排除哪些信息。它们甚至目前不起作用，这是决定性的因素。--Inas (讨论) 2013年9月12日 01:43 (UTC)[回复]

Inas，我同意你的看法，也因为，特别是对于打印，我能想到的任何网站都没有正确使用（斟酌考量 ;-)) 定制打印版本。一篇优秀而完整的文章应该原样传递给所有媒体。然而，我不排除通过深入研究，可以修改少量模板以不同地显示相同内容（不是不同内容！只是布局）。--Andyrom75 (讨论) 2013年9月12日 09:49 (UTC)[回复]

好吧，如果我们想用这种艰难的方式。 这里有一个例子，Template:Web 被用于排除仅在链接环境中才有意义的注释。这里是另一个例子，它被用于排除一个消歧义通知，这在打印中完全无用。这里（参见最后一次更改）是一个例子，它被用于避免打印一个冗长的 URL，该 URL 与段落中较早的链接非常相似（并且可从该链接访问）。这里它被用于避免打印指向 PDF 的链接。这还只是 Template:Web；我甚至还没有讲到 WEB-START/END 的情况。LtPowers (讨论) 2013年9月12日 14:08 (UTC)[回复]

我认为该模板的使用方式与 WTS 的工作方式没有太大区别。原理是相同的，只是技术上更易于管理，所以我不会复活它。如果你对区分输出感兴趣，你应该有不同的思考方式。让我们谈谈你提到的一个例子：消歧义注释。如果我没记错的话，我们应该有一个模板，也许在 en:voy 中也有。所以，想法是随时随地使用该模板来显示消歧义注释，然后将 CSS 补丁应用于该模板。否则，你将用那个过于通用的模板淹没所有文章，这只会让编辑们的生活更加复杂。恕我直言，这种补丁要有效，应该是透明的，否则人们自然会因为不应用它们而破坏这类倡议。--Andyrom75 (讨论) 2013年9月12日 16:40 (UTC)[回复]
你说的“WTS”是什么意思？另外，我不确定我们是否意见不合；我完全支持把这些内容放到模板里。我的担忧是，我们正在通过删除标记而没有提供替代方案来失去这些语义信息，即使替代方案目前尚未完全发挥作用。LtPowers (讨论) 2013年9月12日 17:21 (UTC)[回复]
抱歉，我打错了，我指的是 WTP :-) 在我看来，我们并没有失去任何有价值的东西，因为已清理的标签对于其目的而言并没有用。我猜测（并希望）WTP 的设计早于 CSS 能够管理不同媒体布局的时候，因为现在，没有人会以那种方式设计它，从编程和使用角度来看都太复杂了。--Andyrom75 (讨论) 2013年9月12日 20:12 (UTC)[回复]
关键是，我不想仅仅因为打印内容就错过芝加哥天际线指南的链接。当 WTP 出版内容时，他们这样做了。他们想要一本没有这些钩子的出版书籍。我们不再希望将这些信息排除在打印版本之外。--Inas (讨论) 2013年9月12日 20:51 (UTC)[回复]
为什么不呢？打印输出中的消歧义通知有什么用？ LtPowers (讨论) 2013年9月12日 23:15 (UTC)[回复]
我们没有解决这个问题。这些东西是为了 WTP 出版的书籍而放入文章中的。如果我们不希望其他用途在某些视图中呈现，那么我们应该更改模板/CSS。通过在文章中保留这些 WTP 的格式指南，我们没有保留任何东西。保留这些并不能阻止其他用途出现在 WTP 从未参与的 99.9% 的打印文章中。--Inas (讨论) 2013年9月12日 23:48 (UTC)[回复]
我明白这一点；我没能传达的是，保留这些遗留信息能让我们轻松找到并修复我们可能希望或需要保持该功能的案例。如果它们被移除，要追查和替换它们将变得更加困难。LtPowers (讨论) 2013年9月13日 01:13 (UTC)[回复]
我只是觉得我们实际手动标记文章以进行打印视图的机会非常渺茫，所以我认为将这些信息保留在历史记录中已经足够了。这并不是说有人会添加更多这样的内容，或者我们会使用相同的标签。目标文章总是可以识别的。然而，如果我们沿着这条路走下去，我能看到的唯一方法就是像其他用途这样的模板可以从打印视图中排除，而这些标签在这方面帮不了我们。我理解放弃 WTP 想法可能很困难，但我认为它永远不会以那种形式重生。任何未来的视图都将是对现有模板和 CSS 应用某种形式的自动化，而不是手动分类。--Inas (讨论) 2013年9月13日 01:29 (UTC)[回复]
我不明白为什么；我们没有理由不能为印刷和网络使用编写指南。LtPowers (讨论) 2013年9月13日 02:04 (UTC)[回复]
Lt，恕我直言，您应该将这两个讨论分开。
  1. WTP 的实现完全错误，现在不能作为任何正确事物的示例。这个讨论应该结束这个话题。
  2. 为其他媒体（包括打印机）提供不同的布局是可能的，但必须从头开始重新考虑。这个讨论应该在一个专门的帖子中进行。如果您认为这是一个战略性话题，您可以发起一次远征（如果它尚未存在……我还没有检查）。
恕我直言，Template:web 也是一个错误的方法，但这个话题与第二点有关，而不是第一点。--Andyrom75 (讨论) 2013年9月13日 06:53 (UTC)[回复]
我不是混淆这两个讨论的人。关键是你的机器人超出了其批准的权限。我们应该恢复多余的更改，并以正确的方式进行，即在必要时用功能性代码替换它们，而不是简单地删除它，迫使我们将来通过历史记录来查找它们。LtPowers (讨论) 2013年9月13日 13:18 (UTC)[回复]
如您所愿，事实上我最初的回复是您可以全部撤销，但在我看来，这会在 en:voy 中重新引入无用的代码。请相信我，我没有说服您的个人兴趣（一个有趣的引言说“观点就像睾丸，每个人都有自己的”：-D），我只是试图向您解释解决不同媒体问题的正确方法。--Andyrom75 (讨论) 2013年9月13日 13:49 (UTC)[回复]

归档机器人

既然看起来至少有些人觉得它有用，我想运行User:ArchiverBot来定期归档讨论页面上的非活跃章节。我的机器人是 Pywikibot 的archivebot.py 的未经修改的副本，它将在明确标记有标记模板的页面上工作，并带有可能的页面级自定义。它将需要一个机器人标志，以免打扰关注目标页面的人。建议的目标页面包括Wikivoyage:Tourist Office、提名页面（可能在脚本或归档实践中进行一些修改）以及用户讨论页面（由用户自己决定）；这些仅仅是建议，不会在遭到反对的情况下实施。Whym (讨论) 2014年11月8日 02:42 (UTC)[回复]

  • 支持，基于已经成功的实验。仅仅澄清一下，是否有人只需要用Template:Auto archiving标记一个页面，机器人就会根据模板中指定的参数自动归档它（即mw:Manual:Pywikibot/archivebot.py/setup#Template_parameters）？-- Ryan • (讨论) • 2014年11月8日 03:37 (UTC)[回复]
    • 是的，就是这样。进一步澄清，经过一周左右的实验，我暂停了每日运行，因为没有标志的频繁归档可能会很烦人。一旦获得批准并标记，我将保持它每日运行。Whym (讨论) 2014年11月10日 09:20 (UTC)[回复]
  • 我们将使用什么程序来规范哪些页面被归档？假设有人出于好意，将模板添加到了酒吧页面；那么撤销机器人后续操作的难度如何？ Powers (讨论) 2014年11月8日 14:30 (UTC)[回复]
    • 撤销和恢复已归档的讨论与撤销其他编辑没有什么不同；由于这些编辑通常不会与其他人的编辑发生冲突，因此简单的撤销或回滚（无需手动复制粘贴）就可以奏效。机器人没有特殊的机制来帮助撤销。至于规定，当涉及重大更改（例如不同的子页面方案）时，建议建立明确的共识。话虽如此，这完全取决于社区。看起来其他使用此功能的维基百科在w:Wikipedia:大胆、回退、讨论周期的精神下运行良好。Whym (讨论) 2014年11月10日 09:20 (UTC)[回复]
      • *提醒* 还有其他人可以评论吗？所有提出的担忧都已解决，但在我添加机器人标志之前，必须有两位管理员表示“支持”。-- Ryan • (讨论) • 2014年11月29日 03:50 (UTC)[回复]
        • 恐怕我仍然担心好心的用户尝试归档不应自动归档的页面。如果它是一个高流量页面，或者归档没有被迅速发现的页面，撤销损害可能会非常耗时。Powers (讨论) 2014年11月29日 16:14 (UTC)[回复]
          • 这与好心用户手动执行相同操作有何不同？除非我遗漏了什么，否则归档机器人不会在标签添加的那一刻立即归档页面，因此除非有人不撤销添加到高流量页面的归档标签，否则有足够的时间撤销任何标记。这个机器人似乎是一种节省时间，并保持经常被忽视的页面（如用户封禁提名）整洁的简单方法。另外，请考虑大多数其他 WMF 维基百科都使用这个机器人，据我所知，它们并没有你描述的问题。-- Ryan • (讨论) • 2014年11月29日 16:29 (UTC)[回复]
            • 我相信，如果放置在一个以前没有归档的页面上，机器人会在下次运行时归档大部分页面。其他维基百科都以相同的方式归档所有讨论页面，所以无论是机器人还是人类操作都没有关系。Powers (讨论) 2014年12月2日 02:22 (UTC)[回复]
              • 我要发牢骚，然后停止关注这个帖子。我们否决一个在所有其他维基媒体维基上成功运行的机器人，仅仅因为一个用户可能错误地标记了一个页面，机器人可能在其他人移除标签之前运行，并且可能需要30秒才能点击“撤销”并撤销这些更改，这让我对这个项目的未来感到绝望！我们不是在讨论是否应该改变页面归档方式，我们只是在维基导游中添加一个机器人支持，它可以帮助我们已经归档现有页面的方式。你在这个小问题上不让步，意味着一个想要以维基百科规范之内的方式提供帮助的贡献者，被告知他的贡献在这里是不受欢迎的。更糟糕的是，我们引用了一种看似不合理的担忧，即最糟糕的情况是我们如果机器人出错，将不得不花费30秒点击“撤销”作为理由。如果我们连一个显而易见的归档机器人都不能批准，那么其他有用的机器人贡献者为什么还要和我们打交道呢？这个脚本提名的失败，毫无疑问是错误的结果——我们需要新的贡献者和新的想法，但这种疯狂的保守主义和官僚主义将扼杀这个项目，如果它还没有致命地伤害到它的话。-- Ryan • (讨论) • 2014年12月2日 02:52 (UTC)[回复]
                • 瑞安，我认为每次我对你支持的善意更改表示怀疑时都勃然大怒是没有帮助的。请注意，我从未反对批准这个机器人；我只是拒绝成为第二个管理员，承担批准它的责任。考虑到我们有几十位其他管理员可以（现在也已经）轻松提供你想要的第二个支持，这真的是一个如此严重的冒犯吗？至少我费心评论了。Powers (讨论) 2014年12月2日 19:35 (UTC)[回复]
  • Powers，如果我将机器人设置为每周检查页面一次，而不是每天，会有帮助吗？这会减少不欢迎的模板添加在任何人注意到之前触发归档的可能性。在有非常繁忙的页面需要归档之前，这可能已经足够频繁了。（如果我没记错的话，一些英文维基百科页面需要每天两次归档，但这可能只是那个维基百科的特例。）Whym (讨论) 2014年12月2日 13:52 (UTC)[回复]

User:CommonsDelinker

从技术上讲，我不是这个机器人的维护者（它是 Magnus Manske 的机器人），但我想代表 Commons 管理员请求机器人标志——他们删除图像，偶尔命令在维基上替换文件。这个机器人的存在是为了协助 Commons 管理员的删除工作，通过移除已删除文件的使用，并替换文件。（例如，如果 Commons 管理员发出命令，机器人将在维基媒体维基上将 A.jpg 替换为 AB.jpg。）默认情况下，为了防止误报，它在删除后等待 10 分钟（或更短时间） CommonsDelinker 才开始解除链接。之后，机器人将查询GlobalUsage以查看其使用位置，然后转到该页面并移除文件。

— Revi 2015年1月25日 15:01 (UTC)[回复]

User:Revibot

这是我自己的机器人。在浏览 RC 时，我发现了这个编辑，惊讶于没有机器人修复它们。我想用我的机器人来修复这个问题。我的机器人已在多个维基（kowiki、kowikisource、kowikicersity、Commons、meta 等）上被批准运行此任务，此任务属于“自动批准”的范围。机器人的编辑频率取决于Special:DoubleRedirects的缓存更新。（目前没有进行任何编辑，因为积压已清理完毕）

— Revi 2015年1月28日 17:08 (UTC)[回复]

复制粘贴检测机器人

从酒吧搬运过来

你们许多人可能已经知道，人们经常通过简单地复制粘贴段落到我们的指南中来公然剽窃。这种复制粘贴一方面侵犯了版权，另一方面由于重复内容而降低了指南的搜索引擎排名。最近，我在维基百科上发现了一个机器人User:EranBot，它能自动检测复制粘贴的内容。我认为在这里运行这样一个机器人会有帮助，这样它就能帮助我们解决版权侵犯和重复内容的问题。机器人创建者 Eran 同意在这里设置机器人，如果社区感兴趣的话。--Saqib (讨论) 2015年4月8日 19:36 (UTC)[回复]

对我来说，这听起来是个好主意。Ikan Kekek (讨论) 2015年4月8日 19:53 (UTC)[回复]
如果我理解机器人描述没错的话，它只是生成一份潜在版权侵犯编辑的报告。听起来很有用，所以我会全力支持——让我们把它放到WV:Script nominations上。-- Ryan • (讨论) • 2015年4月8日 20:03 (UTC)[回复]
该机器人于过去一天运行，在User:EranBot/Copyright中发现1处可能的版权侵犯。我将配置它每天自动运行并更新此页面。ערן (讨论) 2015年4月10日 20:48 (UTC)[回复]
谢谢 Eran。现在可以标记为 BOT 了吗？--Saqib (讨论) 2015年4月10日 20:55 (UTC)[回复]
有没有办法让机器人忽略某些网站？被标记的编辑是我做的，我在编辑摘要中指出部分内容来自 nps.gov，这是一个公共领域网站。-- Ryan • (讨论) • 2015年4月10日 21:10 (UTC)[回复]
我认为我们不应该忽略任何网站，包括那些属于公共领域的网站。我们一直反对重复内容，即使是那些从维基百科等自由许可网站复制粘贴的内容。当然，否则如果我们把一些网站加入忽略列表，人们仍然能够抄袭。我不认为BOT 계속 通知我们关于从维基百科和公共领域网站复制粘贴的材料有什么害处。--Saqib (talk) 2015年4月10日 21:29 (UTC)[回复]
  • 从公共领域网站复制 - 有一个User:EranBot/Copyright/Blacklist，你可以扩展它来避免某些网站，但它旨在用于复制维基百科/维基导游的网站（镜像）。机器人可以指示那些声明自己是知识共享许可的网站（如果网站上有知识共享许可的链接）。它目前没有类似的公共领域材料指示，因为我没有很好的启发式方法来从网站推断它（.gov可能不够，因为即使是美国政府网站也可能在某些页面中使用受版权保护的材料）。
总的来说，我同意Saqib的观点，即即使是自由许可的内容，通常也最好避免重复材料（并非总是如此），但这里没有法律问题（如果你正确引用来源，也没有道德问题） - 所以在这种情况下你可以将其设置为FP。顺便说一句：如果你决定从其他来源复制一些内容，重要的是在文本本身添加对来源的引用 - 机器人会将此类编辑标记为“引用”，读者将能够将此处的内容与来源进行验证。
  • 机器人权限 - 机器人只会编辑User:EranBot/Copyright，每天只编辑1次或几次，所以我认为给它机器人权限是安全的。
Eran (talk) 2015年4月10日 21:51 (UTC)[回复]
不忽略网站的论点是合理的，特别是因为这个机器人主要是一个通知工具。我对标记这个帐户有两个小担忧：1) 既然机器人帐户是刚刚创建的，等待更长一点的时间给其他人评论的机会似乎是公平的；2) 如果这个机器人只是更新一个通知页面，将该帐户标记为机器人将从最近更改和大多数用户的监视列表中隐藏该页面的更新，那么在这种情况下破例不标记它是否有意义？我不认为在没有机器人标记的情况下运行会有任何缺点，但我可能遗漏了什么？
感谢Eran设置了这一切！-- Ryan • (talk) • 2015年4月10日 22:09 (UTC)[回复]
Ryan，你可以出于你提到的良好理由让机器人不加标记。我只能想到一个（理论上）的缺点——机器人和普通用户的查询和编辑限制不同（详情见：Special:ListGroupRights），但机器人主要使用labs数据库进行查询，而不是API，所以这无关紧要。 Eran (talk) 2015年4月10日 22:46 (UTC)[回复]
机器人由于验证码（新用户添加新链接）而无法保存结果。你能否给机器人用户分配Special:ListGroupRights中与skipcaptcha相关的权限之一（例如 bots/confirmed）。谢谢，Eran (talk) 2015年4月11日 22:08 (UTC)[回复]
收到Eran。希望Ryan能处理好并分配机器人所需的权限。顺便问一下：在清除版权侵犯后，从User:EranBot/Copyright中移除通知是否安全？--Saqib (talk) 2015年4月11日 22:39 (UTC)[回复]
是的，清除通知是安全的，但最好是设置TP或FP状态，然后才移除条目，这样我们才能收集有关该工具有效性的统计数据。Eran (talk) 2015年4月12日 04:43 (UTC)[回复]
机器人和（自动）确认用户是唯一可以免除验证码要求的群组，恐怕我不能手动分配确认状态（参见Wikivoyage talk:Confirmed users；你可能只需要等待四天。我想我可以添加机器人标记，然后在自动确认后将其删除。让我知道哪个更可取。Powers (talk) 2015年4月11日 23:12 (UTC)[回复]
我希望这个机器人在几天内拥有机器人权限。谢谢，Eran (talk) 2015年4月12日 04:43 (UTC)[回复]
Yes 已完成 -- Ryan • (talk) • 2015年4月12日 05:05 (UTC)[回复]
@ערן: 机器人账户现在应该已经足够老了，可以自动确认。如果我移除机器人标记，以便编辑出现在未过滤的最近更改中，根据上面的讨论，这是否可以？-- Ryan • (talk) • 2015年4月21日 15:39 (UTC)[回复]
Ryan，是的，你可以移除机器人标记。Eran (talk) 2015年4月21日 21:14 (UTC)[回复]
Yes 已完成 -- Ryan • (talk) • 2015年4月21日 21:26 (UTC)[回复]

User:Wrh2Bot - 标记失效外部链接

我想用 {{失效链接}} 标记失效的外部链接。默认情况下，未启用“偏好设置”中ErrorHighlighter小工具的用户将看不到此标签，但已启用该小工具的用户将在无效链接旁边看到“失效链接”注释，从而非常容易地查找和修复文章中的错误链接。带有失效链接的页面也将添加到Category:Articles with dead external links‎‎。请参阅纽约市的此编辑和芝加哥的此编辑，以了解机器人将执行的操作示例。假设有两个人支持此机器人，我的计划是最初缓慢运行机器人，并手动审查它所做的所有编辑，以确保没有误报。另请注意，我设置机器人的方式是，如果链接没有明显失效——例如，如果网站返回“服务器错误”或其他指示可能暂时性问题——机器人将不会标记该链接，以避免误报。-- Ryan • (talk) • 2016年4月7日 03:44 (UTC)[回复]

更新：我已经对所有星级文章运行了机器人，所以Category:Articles with dead external links‎‎现在包含了一些可以查看的文章，以了解机器人将如何工作。它在此过程中破坏了一个链接，所以我需要找到一个修复方法，但这个链接一开始就是一团糟——在以下差异中搜索“Golders Hill Park”：Special:Diff/2909329/2968987。-- Ryan • (talk) • 2016年4月8日 00:11 (UTC)[回复]

支持 - 这是一个很棒的工具，手动检查是一项非常漫长的工作。失效链接可以突出显示已关闭的企业或仅是网址已更改。这将帮助我们提高文章质量，使其对读者更有用并提高我们的搜索引擎排名。--Traveler100 (talk) 2016年4月7日 07:43 (UTC)[回复]
支持。希望它在更新前能间隔几天检查两次链接。OSM 中的类似工具产生了大量误报。--Inas (talk) 2016年4月7日 08:50 (UTC)[回复]
当前版本的机器人旨在仅标记服务器明确返回 404（文件未找到）或 DNS 查找返回“未知主机”（表示该域名已不再有网站）的链接。我认为这应该可以消除因检查两次而解决的问题导致的误报，尽管它也可能会遗漏一些无效链接——例如，在圣莫尼卡文章中，一个链接被设置为“https”但该网站只支持“http”，机器人目前不会标记这种情况（我在此编辑中手动修复了它，因为我在笔记本电脑上注意到了机器人输出中的错误）。此外，如果机器人重新运行一篇文章，它将删除所有现有的{{失效链接}} 标签，并且只重新标记失败的文章，因此如果一个链接由于外部网站的临时问题而被标记为失效，它应该在机器人下次运行时被取消标记。对于第一次迭代，希望这样可以，然后我可以考虑做一些事情，比如为边缘情况存储失败历史记录，并在未来增强功能中标记多次失败后更困难的链接。这看起来合理吗？-- Ryan • (talk) • 2016年4月7日 14:51 (UTC)[回复]
是的。--Inas (talk) 2016年4月8日 02:18 (UTC)[回复]
好主意。支持。Pashley (talk) 2016年4月8日 09:17 (UTC)[回复]
它能否指示是找不到网站还是收到了 404 错误？这对任何试图修复它的人都会有帮助，尽管这不是必需的，因为修复者当然会测试链接。Pashley (talk) 2018年2月22日 08:42 (UTC)[回复]

User:AndreeBot - 改进列表/区域列表

目前，许多地区都非常基础——比如布里亚特，我想做的是尝试从引用的文章中自动收集地理位置，并创建 listing|type=city，这样我们以后就可以轻松地在地图上显示这些（并可视化地浏览文章）。同样，我想将区域列表转换为使用模板（例如中部丘陵）。我为此已经有了一些基本的脚本，所以我想避免“最近更改”墙被淹没。

另一个任务是为已经有维基百科链接的列表添加维基数据链接。在许多情况下，这些列表没有图片、位置或URL——这些也可以相对容易地添加。Andree.sk (talk) 2018年2月21日 18:55 (UTC)[回复]

支持 - 我之前考虑手动在地区文章中添加城市的经纬度，但使用机器人显然是一个更好的主意。Gizza (漫游) 2018年2月22日 02:19 (UTC)[回复]
支持 - 我想可能会有一些问题，但没什么大不了的，这基本上是个好主意。Pashley (talk) 2018年2月22日 08:28 (UTC)[回复]
支持 - 只要是添加而不是覆盖信息。也许先运行大约20个随机样本，这样就可以看到创建了什么。--Traveler100 (talk) 2018年2月22日 09:07 (UTC)[回复]
支持维基数据提案（参见Category:Listing with Wikipedia link but not Wikidata link中的目标文章列表）。对其他提案没有意见。Andy Mabbett (Pigsonthewing); 与Andy对话; Andy的编辑 2018年2月22日 16:37 (UTC)[回复]
我认为这些想法都非常好。我喜欢Traveler100的建议，运行一个几页的样本，这样我们就能准确地看到结果是什么样子。——Granger (talk · 贡献) 2018年2月23日 00:46 (UTC)[回复]
支持 - 我认为这是个好主意。我只有一个问题，为什么你使用listings而不是markers？我认为listings在某些情况下可能看起来有点奇怪，例如你在用户页面Evenkia上发布的例子，我们只有城市名称后面跟着一个句点，这看起来有点奇怪。例如，请参见法兰西岛，那里使用了markers。 Drat70 (talk) 2018年2月23日 04:52 (UTC)[回复]
我认为语义上，列表是正确的选择——因为理想情况下，所有这些内容都应该（在我看来）包含一些简短描述、维基百科链接等等——并且应该可以由维基导游编辑……也许我们应该改进列表模板，使其在列表中没有数据（除了位置+维基链接）时，不生成句点？Andree.sk (talk) 2018年2月23日 07:38 (UTC)[回复]
我同意Drat70的观点——带有单行描述的城市应该使用标记模板而不是列表模板。我从未见过地区文章使用列表模板来表示其城市，而且我认为没有理由为它们包含维基百科和维基数据链接——如果读者想了解该城市，他们可以点击维基链接跳转到我们关于该城市的文章。——Granger (talk · contribs) 2018年2月23日 14:29 (UTC)[回复]
我的想法是最终能有漂亮的、可点击的地图内容，就像北匈牙利（参见前3个城市）一样，并混合可点击的区域，如马德里。当然有很多方法可以做到，但我会说将维基数据引用与列表保持一致是未来最好的方式。最终，志愿者可以将其进一步转换为伯尔尼地区类似的区域列表，如果城市没什么可说的……无论如何，我认为这不是讨论此问题的正确场所。listing|type=city 稍后可以转换为其他任何内容，取决于该讨论的结果？Andree.sk (talk) 2018年2月23日 15:53 (UTC)[回复]
我同意这不是讨论此问题的正确场所。现有的做法是使用带有一句话描述的标记模板；如果你认为我们应该改变这种做法，也许酒吧会是提出这个想法的合适场所。——Granger (talk · contribs) 2018年2月23日 19:23 (UTC)[回复]
好的，样本量足以进行第一轮评论。--Traveler100 (talk) 2018年3月3日 12:09 (UTC)[回复]
  • 你能把用户 ID 设置为机器人用户，这样更容易从监视列表中筛选出编辑吗？
我想这必须由一些管理员（将机器人权限分配给机器人）来完成。我尝试在pywikibot框架中设置机器人标记，但它没有任何改变……不过我可能遗漏了什么。
  • 能否将维基数据参数添加到维基百科参数旁边，而不是列表末尾？
已完成，mwparserfromhell只允许在 [wikipedia] 参数之前添加，所以就这么办了……
  • 当有留言页条目时，机器人也应该停止。
已完成，忘记了（但最终机器人目前无论如何都需要一些手动干预……）Andree.sk (talk) 2018年3月3日 15:25 (UTC)[回复]
我想“一些管理员”是指一位行政员。K7L (talk) 2018年3月3日 22:00 (UTC)[回复]
  • 各位，我不确定我能否很快完成第一部分（列表/标记 + 区域列表）（可能需要几周时间），所以我建议给机器人赋予机器人标志，然后我将让它执行第二项任务（维基百科 -> 维基数据）……一旦我完成了第一项任务，我就会回到这里征求反馈？我猜最终，这个机器人的一切都是基于“信任”的，对吧？Andree.sk (talk) 2018年4月24日 19:14 (UTC)[回复]
关于列表与标记的问题解决了吗？Ikan Kekek (talk) 2018年4月24日 19:18 (UTC)[回复]
据我所知——也许提供一些样本后，我们可以继续讨论……同时，我接受了两种可能的结果（我真的只是想让区域页面变得更好，如果可能的话），目前不太关心标记/列表，所以…… :) Andree.sk (talk) 2018年4月24日 19:47 (UTC)[回复]
嗯，看起来这个机器人有很多支持。机器人还需要行政员的批准吗？它似乎已经被管理员设为自动巡查员。这对你的目的来说足够了吗？Ikan Kekek (talk) 2018年4月24日 23:31 (UTC)[回复]
如果没有机器人标志/组，即使它是自动巡查员，它的更改也会在运行的几个小时内淹没“最近更改”日志……Andree.sk (talk) 2018年4月25日 05:23 (UTC)[回复]
好的，我已批准它为机器人。如果我还能提供任何帮助，请告诉我。Ikan Kekek (talk) 2018年4月25日 05:54 (UTC)[回复]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘大家好，很抱歉这么晚才加入讨论，但我现在才偶然发现。我对提案有几点评论

  • 关于 WV 区域页面上的地理坐标：这是一个很棒的主意。在放开机器人之前，我能否提议进一步思考一下：一个 WV 城市单行信息所需的所有信息（几乎）都在其页面上给出（例如在“地理”模板中——这就是机器人会工作的原因）。如果这些信息是动态地（而不是像现在这样静态地）从这些页面中提取的，那就好得多了，这样如果有人更改了那里的信息（例如地理坐标，或链接，或母语中的名称/转写），它就会在其他所有地方自动更改。如果这可能，那么像“{{oneliner|Kilkenny}}”这样的东西，它会动态提取所有相关信息，就足以放在这些页面上。
    如果这可能，那么我将在此基础上建议一些东西：在每个 WV 城市页面上，可以定义该 WV 城市的“单行”摘要（例如，对于“基尔肯尼”，使用“{{onelinersummary|迷人的中世纪城镇，被称为大理石城，也是每年六月初举办的猫笑喜剧节的举办地。}}”）。该信息也可以动态提取，并且不仅有利于 WV 区域文章（在“城市”、“其他目的地”下），还可以重复用于“下一步”部分。“单行”模板也应该提供覆盖或添加到自动提取值的可能性。
  • 关于测试机器人：我认为这应该在沙盒中完成，例如通过复制当前使用不同样式的一些页面。在我看来，这些测试不应该在 WV 的实时页面上进行。但是，如果您有足够的直接在 WV 实时页面上测试的良好经验，那么就去做吧。
  • 关于自动覆盖内容：我想强调，不应这样做（未经讨论后果）。我遇到过正确地理坐标被维基数据中的值覆盖的情况，这些值要么完全错误，要么放置在对旅行者没有太大用处的位置。这是由一个似乎机械地浏览许多列表的用户完成的，这几乎就像一个机器人。

感谢您考虑上述几点。Xsobev (talk) 2018年4月25日 12:04 (UTC)[回复]

我没有复制内容，而是使用了新的{{标记}}功能，自动从维基数据获取缺失数据……所以上面的问题现在基本上不是问题了。我决定暂时不处理短描述，因为它似乎是一个敏感话题……Andree.sk (talk) 2018年6月24日 17:50 (UTC)[回复]

各位，这个脚本似乎在区域准备方面做得 +- 和我设想的一样。查看更改。最终，我将不得不监督这个脚本，因为每个区域页面都有特殊之处，会导致它失败 :) 但是，如果您不喜欢输出，您可以提出异议（但我没有做任何有争议的事情，我甚至使用了标记而不是列表 ;))。否则，我将批量运行它……Andree.sk (talk) 2018年6月24日 17:50 (UTC)[回复]


我提议我的机器人每小时重置Wikivoyage:涂鸦墙，根据Wikivoyage talk:涂鸦墙的讨论。它将通过替换User:DannyS712 bot/reset的内容来重置，这样管理员就可以调整基本文本，而无需我修改机器人代码（User:DannyS712 bot/reset页面是完全保护的）。我很乐意回答任何问题，代码还没写，但应该很容易。谢谢，--DannyS712 (talk) 2020年11月6日 19:09 (UTC)[回复]

DannyS712 机器人 - 自动“巡查”被回退的编辑

如果编辑通过回退功能被回退，则原始编辑会自动巡查，但如果通过手动撤销或手动回退，则旧编辑仍未被巡查，因此在Special:RecentChanges中搜索未巡查的编辑时仍会显示。由于这些编辑不需要人工巡查员检查，因为它们已被回退，我建议由机器人自动巡查它们。

我还没有编写此代码，但大致上是：

  • 查询 API 获取最近的未巡查编辑，并标记为已回退 ("rctag": "mw-reverted", "rcshow": "!patrolled")
  • 对于每个结果编辑，通过 API 将其标记为已巡查

有什么想法吗？如果获得批准，我将编写代码并授予机器人账户巡查员权限进行测试。 --DannyS712 (讨论) 2020年12月7日 (UTC) 21:40[回复]

当然。请继续。The dog2 (讨论) 2020年12月18日 (UTC) 21:56[回复]
这听起来是个好主意。—Granger (讨论 · 贡献) 2020年12月18日 (UTC) 22:03[回复]
我一点都不喜欢这个主意。这个网站上最活跃的破坏者回退了很多编辑。Ikan Kekek (讨论) 2020年12月18日 (UTC) 22:50[回复]
为了确保不是误解，我认为这是自动标记已被回退的编辑为已巡查。如果回退者不是自动巡查用户，则回退本身仍将被标记为待巡查，巡查员仍可以查看。The dog2 (讨论) 2020年12月19日 (UTC) 00:19[回复]
@The dog2 是的，没错。考虑以下情况：
  • 没有自动巡查权限的用户（或IP）进行编辑，编辑A
  • 其他人回退，编辑B
除非使用回退功能（会自动巡查被回退的编辑），否则编辑A仍然需要手动巡查。机器人会将编辑A标记为已巡查，因为它已被回退，所以不需要人工巡查员的关注。机器人不关心编辑B。DannyS712 (讨论) 2020年12月19日 (UTC) 00:22[回复]
那样的话，当然，这是个好主意。Ikan Kekek (讨论) 2020年12月19日 (UTC) 00:25[回复]
听起来是个好主意。EpicPupper (讨论) 2021年6月10日 (UTC) 21:07[回复]
不。那个人几乎从不回退任何东西。那指的是我发布回复时最活跃的破坏者。Ikan Kekek (讨论) 2021年6月10日 (UTC) 22:10[回复]
哦，我明白了。SHB2000 (讨论 | 贡献 | en.wikipedia) 2021年6月11日 (UTC) 02:19[回复]
回想起来，布伦丹并不是真正的破坏者，更多的是版权侵犯者。SHB2000 (讨论 | 贡献 | en.wikipedia) 2021年6月11日 (UTC) 02:22[回复]

meta:全局提醒机器人

如上所述，针对这个维基。请记住，我预计机器人不会在这个维基上运行太多次（可能一年一次？）；但是，规则要求在运行机器人之前明确授权，无论运行频率多低。Leaderboard (讨论) 2024年8月24日 (UTC) 05:41[回复]

如果我理解正确，这会自动提醒那些不活跃的人，他们作为管理员等的用户权限将很快被撤销？Ikan Kekek (讨论) 2024年8月24日 (UTC) 06:23[回复]
@Ikan Kekek: 正确。这是一个粗略的例子（默认情况下，消息将是此维基的通用消息）。Leaderboard (讨论) 2024年8月24日 (UTC) 06:24[回复]
谢谢。支持。Ikan Kekek (讨论) 2024年8月24日 (UTC) 07:34[回复]
还有一件事：我猜这会对管理员、界面管理员和行政员生效吗？--SHB2000 (t | c | m) 2024年8月24日 (UTC) 07:37[回复]
@SHB2000: 除了 meta:全局提醒机器人/全局 上的排除列表之外，所有权限（即目前为 flood 和 confirmed）。所以它确实会影响巡查员等权限（如果您将来给某人临时访问权限）。Leaderboard (讨论) 2024年8月24日 (UTC) 07:51[回复]
啊，对—— 这就能解释了。--SHB2000 (t | c | m) 2024年8月24日 (UTC) 08:00[回复]
你好 @SHB2000，根据规则，我想我可以把这个维基添加到我的机器人允许列表里——如果不行请告诉我。Leaderboard (讨论) 2024年8月31日 (UTC) 05:30[回复]
@Leaderboard: 是 完成，用户页已创建（如顶部第三段所述）。--SHB2000 (t | c | m) 2024年8月31日 (UTC) 05:54[回复]
取自“https://wikivoyage.cn/w/index.php?title=Wikivoyage:Script_nominations/Archive&oldid=5144170”
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.