魔鬼藏在细节中——周一 wiki 老手会发生什么变化？
2010年7月8日 | Henne Vogelsang | 无许可
几天前，我向大家介绍了周一 en.opensuse.org 将会发生什么变化，当我们切换到新的 Wiki 时。现在让我深入探讨一下新 Wiki 的细节。我特别想关注对熟悉旧 Wiki 的人来说重要的变化。我们开始吧。
| ## 目录 * 1 页面位置 * 1.1 命名空间示例 每周新闻 * 2 导航 * 2.1 子页面是魔鬼的作品！ * 2.2 真正的导航：分类、导航栏和门户 * 3 搜索 * 4 结论 |
页面位置
这是你首先要学习的东西。你不能简单地将你的页面扔到 en.opensuse.org/My_great_page 上。你必须稍微动动脑筋，将你的页面放到正确的命名空间中。
规则其实很简单
-
主命名空间，即没有前缀的命名空间，仅用于最新版本发行版的展示
-
所有项目相关的都属于 openSUSE:
-
关于发行版中软件/硬件的解决方案/帮助/概述，仅属于 SDB:
-
与发行版兼容的硬件声明，仅属于** HCL: **
-
你想保留的旧东西属于 Archive:
命名空间示例 每周新闻
让我举个例子。每周新闻团队有几个页面。他们有
-
一个包含最新一期的页面
-
一个包含下一期的页面
-
几个包含旧期的页面
-
几个关于他们如何准备这些期的文档页面
-
一个用于该期的页面模板
-
一个描述他们团队的页面
现在它们属于哪个命名空间？主命名空间，因为每周新闻对消费者很重要，还是 openSUSE: 命名空间，因为他们是一个团队并共同处理新闻通讯？答案很简单：两者，甚至更多。它们有属于主命名空间、openSUSE: 和 Archive: 的页面。以下是新 Wiki 中实际的布局
- 最新一期在主命名空间中，以便访问者可以找到并阅读它。
- 不再太重要但我们想保留的旧期在 Archive: 命名空间中
wiki.opensuse.org/Archive:Weekly_news_130
团队协作处理的下一期、如何操作的文档以及关于团队是谁/什么/在哪里的页面都在项目的命名空间 openSUSE 中
wiki.opensuse.org/openSUSE:Weekly_news wiki.opensuse.org/openSUSE:Weekly_news_guidelines wiki.opensuse.org/openSUSE:Weekly_news_translations wiki.opensuse.org/openSUSE:Weekly_news_team
页面模板用于这些期，在 Template: 命名空间中。
wiki.opensuse.org/Template:Weekly_news_full
现在这有 7 个页面在 4 个命名空间中。是不是有点混乱？我们如何将它们全部连接在一起？我们只需添加另一个页面，概述整个_每周新闻_项目。一个门户。门户介绍主题并链接到属于该项目的所有页面。
wiki.opensuse.org/Portal:Weekly_news
现在，正如你所看到的，消费者始终可以在主命名空间中找到最新一期。不会有人被旧内容或正在进行中的内容所困扰。如果你想了解更多或参与每周新闻，我只需将你指向 Portal:Weekly news。
导航
网页上的导航是关于链接东西的。人们往往忘记了网络，因此 Wiki，就是关于什么的。导航必须几乎完美，否则你的用户会迷路，更糟糕的是，找不到他们想要的东西。
子页面是魔鬼的作品！
在旧的 Wiki 中，我们使用子页面来“分组”页面。你知道吗？斜杠游戏。
en.opensuse.org/KDE en.opensuse.org/KDE/Repositories en.opensuse.org/KDE/Repositories/Factory en.opensuse.org/KDE/Repositories/11.3
这提供了“返回”导航。所以 KDE/Repositories/Factory 有一个自动链接添加到页面顶部，指向 KDE/Repositories，而后者指向 KDE。这是我们真正一致使用的唯一导航。人们倾向于认为斜杠有帮助，因为每个黑客都习惯于目录树，这看起来像一个不错的 KDE“目录”对吧？它缺少目录的一个基本“功能”：目录列表工具。Wiki 页面 en.opensuse.org/KDE 不以任何方式列出子页面 en.opensuse.org/KDE/Repositories。除非你知道 KDE/Repositories 存在，否则你必须从 KDE 链接它。你没有目录列表，也看不到子页面的关系（目录内容）。斜杠有什么用？没有，它只会混淆页面名称。导航不在浏览器的 URL 输入字段中，所以不要使用子页面！
真正的导航：分类、导航栏和门户
所以这是我们在新 Wiki 中所做的。我们给页面起一个真正描述性的名称，然后停止自欺欺人，使用简单的链接、导航栏、分类或门户将它们链接起来。所以以上面的例子为例，我们会…
-
…以可读的方式命名页面。就像这样：KDE、KDE_repositories、KDE_repositories_factory、KDE_repositories_11.3
-
…只需将 [[Category:KDE]] 添加到它们，将所有页面放入 KDE 分类中，以便我们自动获得 KDE 页面的概述。
-
…创建 Template:KDE_repo_navbar，它在各种存储库页面的顶部提供一个漂亮的导航栏。
-
…并且在我们添加了更多页面，例如 KDE 文档和 KDE 团队页面之后，我们创建 Portal:KDE 来介绍整个主题。
这是真正的导航，而不是一些伪后退按钮。它具有可扩展性、易于维护，并且适用于我们 Wiki 中的所有内容。
搜索
我们希望尽可能地让访问我们页面的简单消费者更容易，因此我们也更改了 MediaWiki 搜索的默认设置。在新 Wiki 中，它仅搜索主命名空间和门户。因此，搜索 GNOME 会找到有关 GNOME 的产品宣传页面以及在 Portal:GNOME 上有关 Wiki 中所有 GNOME 内容的概述。它不会找到会议记录（它们在 openSUSE: 中），删除 beagle 的说明（它在 SDB: 中）或 11.0 上关于 GNOME 的旧垃圾（这些页面在 Archive: 中）。但不用担心，你可以在你的帐户首选项中设置要搜索的命名空间。
结论
这些是周一技术上会发生的三件主要事情。起初你可能需要习惯一下，并且感觉很陌生，但一旦你摆脱了旧的方法，这个新的 Wiki 实际上会使事情变得更容易。从技术上讲，对于 Wiki 贡献者来说，这并不是什么大问题，但它对 Wiki 的消费者有巨大的影响。让我们诚实地说，我们需要尽快更好地向他们提供信息 ASAP。