跳转至内容

Wikivoyage:目录

添加链接
来自维客旅行

让我们修复每页的目录 (TOC)。问题已在 Wikivoyage:Travellers' pub#Coding error 讨论过 – 现已移至 Wikivoyage talk:TOC#Coding error（在附加的讨论页上）。

项目列表

[]
  • 您好（一级）。所以，我把 ul,ol{list-style-position:inside;} 放进我的 user:Rogerhc/common.css 中，然后……它解决了 IE 9 中项目符号漂移的问题，但同时引入了一个问题——换行的列表项现在与其项目符号对齐，而不是与其第一行文本对齐。它也没有解决嵌套列表缺少缩进的问题。它也没有解决列表项流过目录底部时向左跳动的问题。
    • 那里（二级）
  • 哦（一级）
    • 嗨！（二级）
      • 再见！（三级）
  • 这个
  • 那个
  • 和
  • 更多

目录编号

[]

我们不需要也不想要目录项编号，因此在 Mediawiki:Common.css 中使用此代码抑制了编号

/* Suppress numbering of items in TOC */
.tocnumber { display: none; }

这带来了一个目录可读性问题：长目录项换行时没有任何图形指示。这使得目录中哪一行是新章节，哪一行只是换行变得不清楚；这是一个小问题，但如果可以的话值得修复。

由于未知原因，[+] 和 [-] 阻碍了第一字母和第一行样式的实现，修复可能很棘手。由 TocTree 实现，见下文。

TocTree

[]

[+] 展开和 [-] 折叠来自 m:Extension:TocTree，可在用户偏好设置 > 其他中设置。

目录左浮动来自 m:Extension:TocTree，也可在用户偏好设置 > 其他中设置。

目录旁的项目列表

[]

TocTree 指出这是一个已知问题。那么为什么还没有修复呢？让我们一起修复它...

项目列表无法优雅地流过目录的右侧。

  • 当列表流过目录底部时，列表会向左跳动。这是正常的内联显示行为，但对于期望垂直对齐的列表来说会显得突兀。我们能否通过块级显示来解决这个问题？下面的 Div hack 可以做到，但这是一个我们不希望在维基标记中看到的 HTML hack。
  • 列表缩进不正确（项目符号略微左浮）
  • 嵌套列表无法缩进
  • 当项目列表流到目录右侧时，IE 9.0 Windows 7 会在目录左边缘显示项目符号。
  • Div hack 可以强制此类列表符合用户期望，但这是一种 hack
<div style="overflow:hidden;">
* Some
* List
* Here
</div>

示例页面

[]
  • 福建南部海岸有嵌套列表流到目录右侧，缺少预期的缩进。尝试在“偏好设置 > 其他”中关闭“目录浮动”，看看它应该是什么样子。
  • 长岛是一个页面示例，其中 div style="overflow:hidden" 被 hack 到流到目录右侧的其中一个列表中。查看其维基标记以了解。

问题

[]
  1. 当列表围绕左浮动框流动时，是否总是存在这些问题？
  2. 其他网站也有这个问题吗？

一些模拟 HTML 页面可能有助于回答这个问题...

想法

[]

……让我们跳出框框，旧想法，新想法，简单想法，疯狂想法！

新目录

[]

我希望我们能有一个全新的目录。我们目前的目录已经用了大约 8 年了，它既过时又有问题。它会挤压文本，弄乱项目符号，压低模板等。我喜欢文章最顶部的水平目录的想法。--Peter Talk 2013年1月22日 22:23 (UTC)[回复]

听起来很有趣！可能只是个白日梦，但如果有人能做出一些，我很乐意品尝！ --Rogerhc (talk) 2013年1月22日 22:30 (UTC)[回复]
以前有人真的做过一个，但我怎么也找不到讨论了。也许它在某个时候不小心被删除了。 --Peter Talk 2013年1月22日 22:39 (UTC)[回复]

目的地指南目录和普通目录

[]

可以使用模板在目的地指南中插入统一的目的地指南专用目录，而可以在我们想要正常普通 Mediawiki 目录的任何其他地方插入 __TOC__，它就是简单地工作。网站默认可以是没有目录，直到手动添加其中一个。这样，目的地指南就可以拥有一个适合它们的目录，而其他页面可以使用普通目录，无需自定义。

  • 问题：当页面有超过 3 个章节时自动显示目录是一个用户覆盖偏好设置——用户可以在其偏好设置中覆盖网站默认设置。
    • 解决方案：在偏好设置中显示该偏好设置的地方，使用自定义系统消息警告不要这样做。 (未签名) 2013年1月23日 Rogerhc

将类似这样的内容放到目标页面以关闭目录并将其替换为虚假目录？

__NOTOC__ 了解 抵达 看 活动 购物 餐饮 饮品 住宿 下一站

所有章节都是标准化的，所以每个目的地使用相同的模板都可以工作。 K7L (talk) 2013年1月23日 00:43 (UTC)[回复]

我很乐意拥有一个目的地指南专用的目录。所有可展开的子章节总是显得有点多余，而像这样简单的水平目录栏（希望能更美观一些）将解决我们当前目录造成的所有各种格式问题。然而，我们现在目录的子章节链接功能更适合讨论页内容。--Peter Talk 2013年1月23日 00:46 (UTC)[回复]
没错，所以我们可以卸载[+][-]显示/隐藏（mw:Extension:TocTree）扩展，它也正在进行导致问题的左浮动，并且只使用一个标准的普通目录，无需偏好设置调整。很漂亮。我认为我们成功了！为成功者进行样式设置将是锦上添花。哦！在目的地指南上使用模板替换目录的纯粹优雅的简洁性！太棒了。只需在模板中放入 __NOTOC__，太棒了！也许可以听听其他人的意见？ --Rogerhc (talk) 2013年1月23日 04:22 (UTC)[回复]

很久以前，有人在捣鼓中美洲某个小镇的文章，虽然他们被恢复了，但这个想法似乎很不错，所以我把它保存在沙盒中——请参阅 User:Wrh2/Sandbox，它很粗糙，但提供了一个关于我们如何将更多信息放入页面顶部水平导航栏的想法。-- Ryan • (talk) • 2013年1月23日 04:57 (UTC)[回复]

Ryan，那个看起来真的很酷！不过，那是一个区域指南，而不是目的地指南，对吗？它比标准的普通目的地指南有更多的章节。而且该页面上的目录没有损坏，嗯，也许它现在运行得很好。好吧，我要睡觉了。但这一切都值得深思。当然，我们可以在这样的页面上放置一个明确的 __TOC__ 魔术词。我们能否在那里使用标准的普通 Mediawiki 目录，而不是 TocTree 目录？我希望卸载带来麻烦的 TocTree 扩展，除非它得到修复。--Rogerhc (talk) 2013年1月23日 05:36 (UTC)[回复]
我只是把它作为一个用户界面想法抛出来，可以应用于任何类型的文章。当然，可以用 __NOTOC__ 抑制目录，并用 __TOC__ 让它出现在特定位置。我实际上喜欢我们现有的目录（我发现它对于导航长页面很有用），尽管我希望有一种更好的方法将其融入文章。我还认为在页眉中包含一些元素可能很有用。-- Ryan • (talk) • 2013年1月23日 05:56 (UTC)[回复]

问题

[]
  • 当页面缺少某个章节时，指向该章节的蓝色链接会破坏预期的链接行为。这会破坏用户对网站的信任。也许可以使用现有的目录逻辑自动生成一级章节链接，这是一种优雅的以内容为中心的自下而上的结构，而不是试图将一组预定义的链接强加给所有页面。--Rogerhc (talk) 2013年1月23日 17:48 (UTC)[回复]

在实际中发现！

[]
  • 福建南部海岸 <------在此
    该页面更像是一个区域指南，而不是目的地指南。所以并不完全合适；{{Go}} 栏还没有“Stay safe”链接。也许可以将其包含在选项集中？也许 {{Go|x=region}} 可以触发包含标准区域链接？或者 {{Go|Stay safe}} 可以触发包含“Stay safe”链接？{{Go|Stay safe|Another}} 包含“Another”等等？ --Rogerhc (talk) 2013年1月23日 05:14 (UTC)[回复]
  • 很棒！不过，我注意到 Roger 在应用该模板之前做了一些其他编辑，大概是为了让模板能正常工作。我们每次应用到每篇文章都会这样吗？这大概会涉及多少工作量？
    这些调整是可选的。我所做的只是在“讨论”部分周围添加了更多的等号，使其成为 ==了解== 的子部分。这并非绝对必要，如果“讨论”最终被认为是独立的标准部分而不是“了解”的子部分，我们也可以这样做。K7L 模板（我已将其放在 {{Go}} 中进行测试）的妙处在于它不会破坏任何东西。如果有人将其放入缺少标准部分的旅游指南中，也不会有任何损坏。我想如果有人看到这种情况，他们就会将缺失的部分添加到页面中。让我们像碰碰车一样试驾一下这个东西吧！撞上区域指南让我意识到我们可能希望为模板制定选项，以便在区域指南的“前往”栏中添加“保持安全”等链接。--Rogerhc (talk) 2013年1月23日 05:24 (UTC)[回复]

一般来说，区域不应该有“吃、喝、睡”章节。我们不鼓励在更高级别列出酒吧等；它们应该出现在城市或城镇。另一方面，国家确实需要美食概览。即使是“大城市”文章也可能没有这些章节；信息会出现在区域文章中。

这个基本想法显然很好，但我们需要多个版本吗？ Pashley (talk) 2013年1月23日 06:15 (UTC)[回复]

区域确实有吃、喝、睡的章节！它们不像有列表的文章那么重要，但它们确实有概览。
我们需要针对不同的文章类别（国家、地区、巨型城市文章、小城市、公园和区域）使用不同的模板目录，因为它们有稍微不同的子标题。当文章有一些更奇特的内容，比如“看和做”章节时，我想这必须通过某种参数手动处理。--Peter Talk 2013年1月23日 06:24 (UTC)[回复]
我同意根据文章类型提供一些不同版本会很棒。大多数文章都使用一个非常简单的版本。我们甚至可以考虑在某些类型的版本中放置图片，而不是这里看到的纯蓝色背景 Travel Doc James (talk · contribs · email) 2013年1月23日 09:56 (UTC)[回复]

有什么理由将其规划为模板而不是扩展，或者使用 CSS 吗？ LtPowers (talk) 2013年1月23日 15:22 (UTC)[回复]

根据 bugzilla:41983 和 bugzilla:43220（两者都在 2012 年提出了解决方案；修复程序可能会在 2013 年 2 月 11 日左右部署到服务器）的进度，获得扩展的测试、批准并实际部署到 WMF 服务器可能需要几个月的时间。当然，模板现在可以轻松完成，因为它不会更改服务器 PHP 代码。如果我们不喜欢它，也很容易恢复。如果您愿意，可以编写一个扩展，但如果代码审查需要一个月，然后又等待部署一个月左右，请不要感到惊讶。 K7L (talk) 2013年1月23日 15:32 (UTC)[回复]
嗯，我担心制作一个有点奇怪但可用的模板会抑制设计正确解决方案的热情。我想在某个时候我必须学习如何编写一个扩展，但这有点令人望而生畏。 LtPowers (talk) 2013年1月24日 01:41 (UTC)[回复]
是的，我们需要愿意从事编程的维基百科编辑。如果我们要进行更改，大部分将需要来自编辑组内部。 Travel Doc James (talk · contribs · email) 2013年1月24日 02:22 (UTC)[回复]

福建南部海岸曾至少应用过两个版本的这个模板。我更喜欢最初的版本而不是当前的，它让菜单更突出。 Pashley (talk) 2013年2月22日 12:58 (UTC)[回复]

这样做

[]

我们正在做这个吗？我很想。在切换之前还需要做什么？--Peter Talk 2013年2月22日 23:00 (UTC)[回复]

我认为我们需要确定一个设计，并找出如何使其与具有与标准列表不同章节标题的文章协同工作。 LtPowers (talk) 2013年2月23日 03:38 (UTC)[回复]

混淆视听

[]

我知道上面讨论的水平目录存在未解决的问题，但是...

所有这些关于目录和新主页漂亮横幅的讨论让我不禁想，这两者能否结合起来，为我们的目的地指南创建一个新的、更具吸引力的页眉。我的一个想法是将页面名称和水平目录叠加在横幅图像上。我粗略地勾勒了一些示例，如下所示：

  • User:Shaundd/Sandbox2 - 两个使用新主页横幅的原型——一个将页面标题和目录都放在图像上方，而另一个将目录放在单独的框中，以稍作区分。这些横幅的比例为 3:1（宽比高）。
  • User:Shaundd - 实际页面上的原型，目录根据页面进行了定制。此横幅的比例为 4:1。
  • 加里波第省立公园 - 带有独立目录框的原型 实际目的地文章中的原型。横幅比例为 4:1。该页面是一个流量较低的主空间页面，但如果您希望我暂时将其严格保留在沙盒中，请告诉我，我将移动它。

我还没有进行大量测试，所以不知道这个设计有多健壮。它在我的 Firefox、IE 和 Safari 中都有效，但我还没有测试不同的字体大小。我也还没有弄清楚如何将图像缩放到屏幕宽度，所以现在它是硬编码为 800px。最终，我希望（实验性地）将其模板化，因为我希望它只需用户提供一个参数——图像名称——其他所有内容都会自动到位。第二个可选参数可以是页面名称，它将覆盖正常的页面名称，适用于区域（如“The Loop”而不是“Chicago/The Loop”）或同名地点（如“Georgia”而不是“Georgia (country)”）。我对模板知之甚少，所以我承认我可能在幸福的无知中做梦。

还有整个问题，即我们是否希望横向显示目录以及如何最好地做到这一点。我只是将 Go 模板修改为左对齐作为起点（我认为我在构建原型时它看起来更好），但我知道整个目录问题尚未解决。不过，目前，我只是想把这个提出来，看看大家的想法。祝好。-Shaundd (talk) 2013年3月17日 17:17 (UTC)[回复]

它们看起来相对华丽，但占用太多空间，而且总的来说，我认为使用全景图作为页眉不是一个好主意，原因有二：1）全景图必须全部是完全相同的尺寸和形状才能呈现一致和整洁（即使在您的模型中，其中一个只占据我屏幕的 2/3，看起来非常奇怪），2）我们永远不会有适合我们绝大多数目的地的良好、尺寸合适的全景图片，这会进一步破坏我们页面格式的相对一致性。我完全支持探索水平目录选项，但我认为包含巨大的图片横幅会使事情变得复杂得多。Texugo (talk) 2013年3月17日 17:59 (UTC)[回复]
让我想起了 mw:Athena。 LtPowers (talk) 2013年3月18日 00:41 (UTC)[回复]
这些真的太漂亮了！不过，我认为文字应该再大一点。我不太担心它们占用太多空间，因为失去了那个糟糕的浮动目录框，所以节省了很多空间！如果我们的主页上有类似的横幅，那么在可用性方面会有一个非常好的并行。对于 Texugo 对全景图的担忧——它们实际上不是必需的。你只需要任何符合我们最小宽度要求的照片，然后将其裁剪成正确的尺寸即可。更大的问题将仅仅是为我们数量庞大的页面完成这项工作所涉及的工作量。也许我们可以将其视为一个长期目标，就像我们将插图指南作为长期目标一样，并且暂时在缺少此类图片的目的地页面上使用无聊的水平目录？--Peter Talk 2013年3月18日 04:33 (UTC)[回复]
(ec) Texugo - 感谢您的评论。我同意添加图片会使事情复杂化，并且一致性更难实现，但我相信这些都可以最小化。关于第 2 点，我同意我们不会总是有好图片。为了解决这个问题，我的想法是，如果模板在没有图片名称参数的情况下使用，则显示一个默认的单色横幅，上面显示页面名称和目录（我已经将其添加到 User:Shaundd/Sandbox2 的底部）。如果有合适的图片，则在模板中包含图片名称参数，并显示全景横幅。这两个横幅（单色和全景）在外观和形状上不会完全一致，但我认为这将有很大帮助。
关于第 1 点，如果页眉中使用的所有图像都具有相同的宽高比，那将很有帮助。肯定需要有关它的文档。但如果有一个默认横幅，我不确定有多少用户会尝试更改它。我也不相信全景页眉占用太多空间。我认为如果宽高比为 4:1 或更大，那就可以了。我们现在拥有的引导图像会占用空间，如果引言太短，图像会溢出到下一部分，有时会干扰内容（如区域列表模板）。结合引导图像和目录的页眉为文章的其余部分创造了一个干净的开始，我认为这抵消了它可能使用的额外空间。
LtPowers - 它确实有点像雅典娜（但相比之下非常粗糙）。我喜欢它的外观和感觉。
Peter - 我喜欢你的想法！我同意这是一个长期的事情——它可以成为一个有趣的探险，随着时间的推移寻找并添加横幅图像。--Shaundd (talk) 2013年3月18日 04:47 (UTC)[回复]
那将是一次非常有趣的探险 ;) --[回复]
好的，我想有一个同样大小的空白可以缓解我在这方面的担忧，尽管我认为灰色或白色会比空洞的黑色好得多。但我仍然认为在支持这一点之前还有一些问题需要解决
  • 我们需要确定一个统一的标准尺寸，并让它始终覆盖整个屏幕——即使在我非常狭窄的工作电脑上，那个加里波第公园的例子也只覆盖了大约 80% 的区域
  • 我认为横幅仍然太高了——因为它需要扩展以适应屏幕尺寸，在宽屏上这些会非常高。
  • 您的示例只包含标题很少的文章。对于标题数量最多的文章，目录会是什么样子？
  • 我们不在乎二级标题/可展开性吗？
  • 对于很长的国家公园名称或 Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch，它会是什么样子？
  • “旅行指南内容”是必要的吗？我认为没有它也足够直观，而且会给目录带来更多对称性。
  • 我假设这应该用于所有主命名空间文章，所以我希望看到一些短语手册或旅行主题文章中可以使用的全景图示例（间隔年旅行、国家区号列表、发展中国家旅行提示 或 旅行者腹泻怎么样？）
顺便提一下，如果这个方案可行，还需要进行一些次要更改：从国家概况框中删除现在次要的引导图像，考虑先前的引导图像在横幅图像下挤压起来后的外观等等。还有我个人认为（稍后讨论）全景图需要仅限于此类目录，每篇文章一个——我一直不喜欢全景图打破文章流的方式，如果每篇文章都有一个突出位置的全景图，我认为这应该足以在文章的其余部分消除它们。
Texugo (talk) 2013年3月18日 11:45 (UTC)[回复]
您是否将地图也包含在全景禁令中？我在 华特迪士尼世界/市中心迪士尼 和 南部地区 中都有宽幅地图。 LtPowers (talk) 2013年3月18日 14:46 (UTC)[回复]
我认为这两者都非常合理。我不认为这需要应用于地图，因为地图很少是这种形状。我只是认为，一篇文章中出现海滩 A 的巨大全景、海滩 B 的巨大全景、从山顶 X 拍摄的海滩 A-D 的巨大全景等是不必要的。Texugo (talk) 2013年3月18日 14:56 (UTC)[回复]

我对 Shaund 的设计不太满意，因为它颜色太多，与 Wikivoyage 旅行指南的整体文本风格不符。一个大的标题图片应该伴随着许多大小和美观相似的图片。但这只是品味问题。请不要将我的意见视为对该提案的反对。

我还想提到，在俄罗斯 Wikivoyage 上，我们开发了一个非常简单且看似相当通用的目录问题解决方案。您可以在此处查看示例。当然，欢迎提出建议和评论。--Alexander (talk) 2013年3月18日 15:04 (UTC)[回复]

我进一步调整了横幅，试图解决 Texugo 在上面提出的一些问题。我使用 Mark 的横幅编码重新构建了它，并在 User:Shaundd/Sandbox3 上放置了几个示例。使用这个新设计
  • 横幅应该能够根据屏幕宽度进行缩放。它在我的电脑和手机上都有效，它们的屏幕分辨率不同，所以我抱有希望。如果您发现它有效/无效，请告诉我。我明天也会在我的工作电脑上进行检查，那台电脑的屏幕非常宽。
  • 我添加了一个示例来展示当目录有很多章节时会发生什么（它会换行，灰色框会扩展以包含它）。
  • “旅行指南内容”不是必需的，所以我删掉了。
  • 我还测试了使用非常长的名称时会发生什么（User:Shaundd/Sandbox3 上的第二个横幅）。它显示了大部分单词，但超出的部分没有显示。这是一个在 CSS 中设置的变量，所以我可以将其设置为换行，但这会非常难看。另一方面，我现在使用的是预先存在的样式表。我可以为这些页眉创建一个独特的样式表，字体略小，顶部和左侧间距更少，这样可以容纳更多的文本（如果图片更短，可能需要更小的字体，以免压倒图片）。另一个想法是，有多少这样的超长名称存在？如果不多，可能可以根据具体情况处理，或者我可以创建一个辅助样式表，用于名称非常长的情况。
我还没有机会创建更短的横幅，但我希望明天晚上能有更多时间来做。我同意我们仍然需要解决二级标题和可扩展性问题，但这适用于任何横向目录。我的想法是，对于大多数目的地指南来说，二级标题在目录中并不是那么有用，所以我倾向于将其省略——但这只是我的直觉反应。-Shaundd (对话) 2013年3月19日 (UTC) 04:25[回复]
我的屏幕上没有文本换行，因为文本没有到达行尾。事实上，灰色条纹延伸到横幅的右侧。但这只是我的看法。=) 我觉得目录文本可以再大一点，尽管在小屏幕上可能会有问题。而且还有移动版本需要考虑。至于二级标题（实际上是三级标题；一级标题是页面标题），我同意大多数目的地指南不需要它们... 但在某些情况下它们会很有用。理想情况下，我想我们可以编写一些 CSS 代码，当鼠标悬停在目录条目上时，会下拉一个子章节菜单... LtPowers (对话) 2013年3月19日 (UTC) 13:01[回复]
我必须承认我有点喜欢这个想法。我不同意目录文本应该更大——它和当前目录的大小相同，我不明白为什么需要比这更大，而且字体越大，它就会越频繁地扩展到第二行。我确实喜欢使用 CSS 为子标题创建下拉菜单的想法。不过，我的一些其他担忧仍然存在，尤其是盒子太高——文章主体甚至直到页面中间才开始。我认为这有点太多了，尤其是绝大多数页面将在很长一段时间内都是空白模板。Texugo (对话) 2013年3月19日 (UTC) 15:31[回复]

好的，这是我今晚的更新

  • 我将它构建成一个模板（Template:Pagebanner），用户提供（1）图像名称或无，以触发使用哪种类型的横幅，以及（2）指南类型，以触发目录（例如，输入“park”将显示公园文章的一级标题）。我设置了三个示例：Garibaldi Provincial Park、Dewdney 和 User:Shaundd/Sandbox3。
  • 我将横幅尺寸从 4:1 更改为 5:1。上面三个例子都是 5:1，而我的用户页面仍然是旧的 4:1 尺寸，以供比较。这样看起来更好吗？
  • 我已调整了CSS，希望LtPowers上面提到的超出横幅的灰色条纹现在已经修复。我认为问题出在屏幕分辨率宽度超过1366左右。

还有更多工作要做，但那将是明天的项目。下拉菜单的想法听起来不错……不过，这可能超出了我的能力范围。-Shaundd (对话) 2013年3月20日 (UTC) 06:09[回复]

又有了改进，是的。这三个例子看起来比例不完全相同——空白的那个（Dewdney）更窄，而且我认为是完美的尺寸。我想如果它们都是那个尺寸，并且空白模板不那么黑，我就可以接受。也许我们可以设计一个带有某种微妙设计的默认横幅，在没有图片时使用？我还想知道是否有可能在目录需要分成两行时，尝试均匀分布项目数量，以避免第二行只有一个孤零零的项目。或者目录列表居中会更好看吗？
该模板提出了另外几个需要考虑的问题
  • 预设的目录内容是否真的足够好，或者我们是否需要一个能够自动提取每篇文章标题的工具？即使是相同类型的文章，所包含的标题也存在相当大的差异——某些部分在不需要时会被省略，或者在内容较少时合并（饮食、观光和活动等），而行程和旅行主题则有各种各样的标题。
  • 这是否在所有情况下都完全由模板实现，或者我们是否可以使用CSS等方法，以便在未指定图像模板时自动显示默认横幅？以及相关问题：默认页面名称的关闭是通过模板还是通过CSS完成？
Texugo (对话) 2013年3月20日 (UTC) 11:19[回复]
带有微妙设计的默认横幅是个好主意。它将使两个横幅保持相同大小变得更容易。不过，我不确定我们是否可以在 CSS 中实现默认横幅。
我将尝试居中目录，看看效果如何。对于标题较多的模板（如国家/地区），我还有另一个想法，就是在中间插入一个换行符，强制它分成两行，大致均匀。
总的来说，我越是深入研究这个问题，就越觉得复制现有目录结构（即捕捉所有标题和可扩展性）存在问题。正如你所提到的，使用的标题种类繁多，目前我确信，我们捕捉这些细节的唯一方法是某种程度上提取每篇文章的标题，然后找到一种方法将其横向复制。我不确定详细的目录与涵盖最重要和常用标题的通用目录相比有多重要。考虑到当前目录造成的布局问题，我倾向于采用更通用的横向目录（用于初始实现），同时继续探索是否可以开发出更好的目录。很高兴能听到更多关于这方面的意见。-Shaundd (对话) 2013年3月20日 (UTC) 14:37[回复]
一个损坏的目录客观上比一个导致布局问题的目录更糟糕。在像华特迪士尼世界这样的文章中，目录会损坏。目录条目指向空白是一个非常糟糕的事情，会降低读者对我们网站的信任。不幸的是——因为我真的很喜欢这个想法——我看不出有什么办法可以避免实际调整真实的目录数据，而不是假设一个标准模板。LtPowers (对话) 2013年3月20日 (UTC) 17:03[回复]
此外，如果我们使用模板选项创建目录，我们就无法通过机器人将其插入到所有文章中——我们必须手动操作，因为即使机器人可以查找文章类型类别，它也无法区分小城市、中等城市和特大城市，而这之间存在相当多的标题差异。我们必须手动将模板插入到每篇文章中，以确保它显示正确的标题集，即便如此，许多标题也会出错。我同意我们不希望链接指向空处。Texugo (对话) 2013年3月20日 (UTC) 17:35[回复]
好的，目录确实是一个问题（至少目前是）。经过大量谷歌搜索，我认为没有办法只使用 HTML 和维基标记动态地重新创建目录。有点好消息是有一个横向目录模板可以横向重新创建标准的维基媒体目录。不太好的消息是，我无法让它在维基导游上完全运行。我复制了 CSS 和代码，一切都正常，只是目录无法像在维基百科那样横向伸展。当它遇到我们的子标题时，它也不是最引人注目的。无论如何，一个实际操作的示例在我的用户页面上，另一个我正在将其整合到模板代码中的示例在User:Shaundd/Sandbox2。你认为这个选项值得追求吗？我还找到了一些模板，我们可能可以修改它们，以便为像华特迪士尼世界这样的文章自定义目录，但自定义必须手动完成。-Shaundd (对话) 2013年3月21日 (UTC) 05:24[回复]

我刚发现这个讨论，并阅读了全部内容。我真的很喜欢 Shaundd 的想法，认为它将有助于我们网站的品牌重塑。我认为上面提到的一些问题是有解决方案的。

对于像华特迪士尼世界这样有“观光与活动”等非标准标题的文章，在机器人将标准模板部署到所有页面后，是否可以再通过另一个机器人搜索类似== 观光与活动 ==的标题？当它找到这样的标题时，机器人可以添加一个类别，我们可以手动筛选（我想这样的实例不会太多），或者让机器人自动配置目录模板本身。

我也不觉得包含子标题（第三级）那么重要。我们文章的大多数读者都会点击主要标题。在大多数情况下，到达子标题也不需要太多滚动。顺便说一句，我真的不喜欢维基百科的横向目录。它完全不清楚 [+] 会展开哪个标题；是左边的还是右边的？展开后，用括号显示子标题既混乱又复杂。

默认的、设计精美的横幅是个好主意。我想它可以是某种白灰渐变，上面覆盖着维基导游水印。另一个有趣的替代方案可以是为每个大洲设置空中地图横幅，部署在各自大洲的文章中。例如，Dewdney的横幅可以是北美洲上空的鸟瞰图，右侧逐渐褪色为左侧的不同颜色。

我认为如果我们能够系统地解决每个问题，这是一个绝妙的主意，将真正为我们的项目注入新的活力。JamesA >对话 2013年4月1日 (UTC) 05:59[回复]

也刚看到这个讨论，之前自己也尝试过横向目录（发现了上面讨论的同样问题）。如果能解决这个问题，我认为这将是对页面风格的改进，并赋予维基导游独特的身份。--Traveler100 (对话) 2013年4月1日 (UTC) 06:25[回复]
我同意詹姆斯的观点，可展开的标题确实没有必要。只在目录中使用一级标题会给我们带来更简洁、更适合新手的外观。--Peter 对话 2013年4月1日 (UTC) 21:05[回复]
詹姆斯——我们之后可以让机器人更新“观光和活动”的目录，但我不认为它能达到使用现有 Mediawiki 目录的可靠性，原因有二。首先，我们的指南内容差异很大——有时“饮食”合并，有时“城市”和“其他目的地”合并，“城市”可能被称为“城镇”、“乡村”或“城镇和乡村”（以及其他名称），“应对”、“学习”和“保持健康”在城市文章中是临时包含或排除的，等等——因此很难让所有页面都正确。其次，标题可能会改变，随着时间的推移，机器人更新的目录可能会与页面上的标题脱节（编辑者可能会决定合并“观光和活动”，或将其分开；可能会添加或删除“应对”部分）。有了内置目录，它至少总是最新的。-Shaundd (对话) 2013年4月8日 (UTC) 04:46[回复]

第二版

[]

大家好，感谢所有反馈。我已经尝试解决了一些问题，所以现在的模板

  • 使用较短的图片——提供两种尺寸，宽高比为 6:1 或 7:1
  • 使用维基媒体目录，因此它会自动拾取我们所有的标题，并且如果标题更改，它会自动更新（目录不再是预先编程的，因此手动工作量减少，链接应该始终有效）
  • 使用默认横幅图像而非通用黑框
  • 允许第二个变量显示不同于官方页面名称的名称（例如，佐治亚州可以在横幅中显示为“佐治亚”）

当前模板未解决的一些问题/疑问是

  • 如果没有模板，横幅不会自动加载。我想如果我们想走这条路，就必须构建一个扩展。
  • 目录只显示一级标题，但如果存在子标题，仍然会生成[+]或[-]（尽管它们没有显示）。我找不到可以操作的 HTML 或 CSS 代码来关闭此功能。我怀疑它与我们使用的 TocTree 扩展有关。如果我们将这些横幅移动到，也许我们可以卸载 TocTree，这样[+]就会消失。这将产生连锁反应，即在不使用横幅的页面（例如，讨论页、项目页）上，每个标题级别都会显示在目录中。不确定人们是否认为这是一个问题，显示的标题级别数量可以通过另一个维基百科使用的模板逐页手动设置。
  • 我只有一个默认图片。詹姆斯关于基于大洲的默认横幅的想法很有趣，但这使得自动化设置变得更加困难。不过，我想如果默认横幅最初是由机器人设置的，那么机器人运行可以分成多个块，也许可以有一个北美机器人、一个南美机器人、一个非洲机器人等等（不过我不知道这是否可行）。另一个问题是，每个默认横幅都必须有单独的模板，除非模板可以读取面包屑导航（有人知道吗？）。

我在Wikivoyage:TOC/Banner上放了一个新横幅，并在Wikivoyage talk:TOC/Banner上留下了一些注释。我尝试捕获这里讨论的要点，但如果我遗漏了什么，请随时在那里提出（我认为将这种特定样式的目录讨论移到显示横幅的讨论页会更好）。谢谢 -Shaundd (对话) 2013年4月8日 (UTC) 04:09[回复]

我认为这是一个好主意。它赋予维基导游独特的外观，与其他维基网站相比，更像一本旅行指南。将内容列表移到页面顶部将消除下方内容与地图和图片冲突的拥挤区域。

内容列表中如果能减少空白并去掉加号就好了，但我也一直在尝试这个，却找不到更好的格式。如果不能去掉加号，那么我建议保留展开子部分的选项。可以通过让机器人遍历Category:Region categories来设置特定大陆的机器人。--Traveler100 (对话) 2013年4月8日 (UTC) 14:05[回复]

我们尝试将此讨论整合到Wikivoyage talk:TOC/Banner。Texugo (对话) 2013年4月8日 (UTC) 14:15[回复]

损坏的目录

[]

在 Ubuntu 的 Chromium 和 Firefox 中，Cobblers Reef 的目录被分成两个独立的目录，一个在简介中（理解），其余的在设施部分，这是怎么回事？Sertmann (对话) 2013年1月23日 (UTC) 05:50[回复]

那是缺少了一个</listing>标签。--Peter 对话 2013年1月23日 (UTC) 06:26[回复]
取自“https://wikivoyage.cn/w/index.php?title=Wikivoyage:TOC&oldid=4924792”
© 2026 wikivoyage.cn. Text is available under the CC BY-SA 4.0 License.