维基教科书:层次命名方案
 | 此页面记录了已过时的 维基教科书政策或指南。 此前政策或指南的文本已被 维基教科书：命名策略 取代。 |
维基教科书上的书籍应按照维基教科书作者的决定，结构化为部分（类似于章节）。但是，在维基教科书文章名称中，没有一种统一的方法来表示子结构。本页旨在讨论当前使用的方法的优缺点，并确定一种使用的方法，然后将其作为对维基教科书上未来书籍的明确建议 维基教科书：命名约定。
命名约定中涉及几个问题，最干净的做法是分别讨论它们（例如，使用哪个分隔符（“：”、“/”、“(..)” 等）与是否允许多级层次结构或是否应该使用数字来标记章节等问题是相对独立的）。每节都列出了当前的示例。
请在下面添加优势或劣势，或提供讨论备选方案。
分隔符
[编辑源代码]子页面 "/"
[编辑源代码]一种方法是使用子页面，即对于名为 *bookname* 的维基教科书，以及名为 *subpagename* 的子页面，文章名称为bookname/subpagename.
Wikijunior Solar System Wikijunior Solar System/Mars Wikijunior Solar System/Glossary
优点
- 这种方案的主要优点是可以实现层次结构内的自动导航链接。
- 这允许层次结构，但也允许子子层次结构等等。
- 每个子（子）页面都将获得指向其所有父页面的静态链接。可以使用 [[/subpagename]] 引用子页面（即，不需要 *bookname*）。
- 正如 1.5 年前指出的那样 [1]，它将在 URL 中类似于目录，从某种意义上说，它也遵循了 最小意外原则。
缺点
- 主要缺点是该方案促进了子层次结构的使用，这可能会使书籍稍微难以阅读或展示。此外，作者可能会倾向于过度使用树形结构。因此，建议可能包括只使用一级子页面，如果非常大的书籍需要，则可以使用第二级（参见下面单独的讨论点）。
- 从一个子页面到另一个子页面的链接必须完全输入。此外，管道技巧不适用于子页面；[[Bookname/Subpagename|]] 显示为 Bookname/Subpagename
- 所有指向子页面的链接都区分大小写；Wikijunior Solar System/The Sun 与 Wikijunior Solar System/the Sun
- 当想要保存文件并通过脚本和像 grep 这样的简单 UNIX 命令自动处理它们时，分隔符 "/" 将与文件系统冲突。将需要使用额外的命令，如 "mkdir"、"find" 和 "xargs"。
- 强制的树形结构不适合许多用途。例如：茴香是一种香料、草药和蔬菜。没有正确的方法来设置它，以便为茴香的所有用法提供自动链接。必须选择更通用的树节点，例如 "glossary/anise" 或完全扁平的结构 ("cookbook/anise")。
真正的自定义命名空间
[编辑源代码]一种方法是使用 自定义命名空间，即对于名为 *bookname* 的维基教科书，以及名为 *subpagename* 的子页面，文章名称为bookname:subpagename. 例子
优点
- 这种方案类似于其他命名空间，因此遵循了 最小意外原则。
- 使用管道技巧，链接变得很简单；[[Bookname:subpagename|]] 变为 subpagename。
- 特殊：所有页面 可以应用于所选书籍。
- 用户贡献 可以显示所有贡献，也可以限制在所选书籍内。
- 从 MediaWiki 1.5 开始，最近更改 也是如此；对于此，所有页面和用户贡献，还可以选择除指定命名空间外的所有命名空间；因此，可以通过选择例如图像命名空间并使用反转选项来获得包含所有书籍页面的组合列表。
- 搜索 可以限制在任何书籍子集内。
- 变量 {{NAMESPACE}} 和 {{PAGENAME}} 分别给出书名和不含书名的页面名称。
缺点
- 自定义命名空间的创建、删除和重命名只能由开发者完成（当启动新书时，可以暂时使用伪命名空间，参见下一节）。
- 软件限制 "真正" 命名空间的最大数量为 256（在 SQL 数据库中为 TINYINT(2)），即 0-255。自定义命名空间编号从 100 开始，因此可以有 156 个，包括讨论页面，即 78 个自定义命名空间及其讨论命名空间。但是，从 MediaWiki 1.5 开始，最大值为 65,536，即 32,718 个自定义命名空间及其讨论命名空间，参见 Bugzilla:719。
伪命名空间
[编辑源代码]另一种方法是模仿命名空间，即对于名为 *bookname* 的维基教科书，以及名为 *subpagename* 的子页面，文章名称为bookname:subpagename, 与上面相同。
优点
- 这种方案的主要优点是它模仿了命名空间，因此遵循了 最小意外原则。
缺点
- 这种方案的主要缺点是它没有像命名空间那样运作，而只是看起来像命名空间。
- 对于伪命名空间，管道技巧仍然有效，但子页面名称的第一个字母区分大小写，这使得它们不太适合内联链接。
括号 "(..)"
[编辑源代码]一种方法是使用括号，即对于名为 *bookname* 的维基教科书，以及名为 *subpagename* 的子页面，文章名称为subpagename (bookname).
General Biology Energy and Metabolism (General Biology) Authors (General Biology)
优点
- 类似维基百科的消歧义，从维基百科来的用户会熟悉这个。
- 这允许更方便的链接，使用管道技巧；[[subpagename (bookname)|]] 显示为 subpagename.
缺点
- 将来更难自动提取书籍列表（参见 Wikibooks:Top active/All books）。在自动提取中，很难区分书名和字符串中的中间部分，因为它可能是另一个子页面标题的一部分。如果书名始终出现在最前面，则提取过程是唯一的。
没有分隔符，子页面上没有书名，都在 wikibooks.org 域中
[编辑源代码]一种方法是不使用任何分隔符，即对于名为bookname的维基教科书和名为subpagename的子页面，文章名为subpagename（即书名不会出现）。
World History Civilization and Empires in the Indian Subcontinent (<- this is a subpage of World History!) The Industrial Revolution (<- this is a subpage of World History!)
（世界历史页面已更改为命名空间分隔符。这些行保留为示例）
Vector Math (<- this single modules is referred to in the middle of the Geometry, Calculus, and Electronics books) ASCII character set (<- this single module is referred to in the appendix of just about every programming language)
优点
- 子页面的标题不会因过长的书名而变得杂乱无章。
- 恢复了正常的维基易用性：[[foo]] 而不是 [[Bookname:Foo|foo]]。
- 属于多个不同维基教科书的简短模块可以一次性编写。在编辑一本书的过程中改进该模块后，所有其他书籍立即使用改进版本。
- 这不需要单独的数据库或软件更改——它已经在 http://wikibooks.org/ 上运行。
缺点
- 如果没有单独的域名或软件更改（这些更改不太可能很快发生），章节页面很可能很快就会在书籍之间发生命名冲突。
请注意，对于某些注释文本，两个缺点可能不适用。也就是说，对于具有唯一标题的特定文本，这些文本只会被注释一次，因此不会发生命名冲突。因此，不需要子域名，也不需要任何软件更改，并且完全保持了正常的维基易用性。
- 我认为你把“没有分隔符，子页面上没有书名”和下一部分“任意分隔符”混淆了，即空格“ ”，或者仍然需要添加的部分。“没有分隔符，子页面上没有书名”在这里的意思是书名不会出现在每个子页面上，这使得两本书很可能发生命名冲突，即使是注释文本也是如此。
没有分隔符，子页面上没有书名，并且有单独的域名
[编辑源代码]一种方法是不使用任何分隔符，即对于名为bookname的维基教科书和名为subpagename的子页面，文章名为subpagename（即书名不会出现）。此外，每本书都放置在单独的域名中。
World History Civilization and Empires in the Indian Subcontinent (<- this is a subpage of World History!) The Industrial Revolution (<- this is a subpage of World History!)
（世界历史页面已更改为命名空间分隔符。这些行保留为示例）
Vector Math (<- this single modules is referred to in the middle of the Geometry, Calculus, and Electronics books) ASCII character set (<- this single module is referred to in the appendix of just about every programming language)
优点
- 子页面的标题不会因过长的书名而变得杂乱无章（但书名会放在域名中）。
- 可扩展性，使维基教科书更容易在更多服务器上拆分。
- 在 Special:Recentchanges、Special:Allpages、Special:Wantedpages、Special:Lonelypages、Special:Deadendpages 和 Special:Categories 中没有无关的杂乱无章。（没错！我们需要这个！）
- 恢复了正常的维基易用性：[[foo]] 而不是 [[Bookname:Foo|foo]]。
- 这不需要单独的数据库或软件更改——它已经在 http://wikicities.com/ 上运行。
缺点
- 这需要单独的域名：cookbook.wikibooks.org
- 模块不能在书籍之间共享——向量数学 模块是为它出现的每本书定制的。如果十个人对该模块进行了十种不同的改进，那么这些改进就会分散在该模块的所有副本中，很难将它们整合在一起。
任意分隔符
[编辑源代码]任何字符都可以用作分隔符，只受作者的品味和想象力的限制：“ ”（空格）、“-”、“--”、“,”（逗号）、“;”，……。所有这些与另一个空格“ ”（空格）结合使用，可以放在分隔符之前、之后或两者兼有。
As You Like It ⇒ As You Like It - Act III Bicycle Repair ⇒ Bicycle Repair Cleaning parts Using GNOME ⇒ Using GNOME : File manager
优点
- 每个作者都可以轻松地满足自己的品味。
缺点
- 如果没有明确的约定，很难有效地处理不同的书籍。
- 它在不同的书籍中并不一致。
- 因此，它成为了一个可用性问题。
组合
[编辑源代码]使用上述组合：例如，将书籍放到指定的命名空间中，但将页面放到子页面中。
Musictionary Musictionary:Guitar Musictionary:Guitar/Bass
优点
- 可以结合命名空间的优点（如果它们真的被激活了）和子页面的优点（链接到父级）。
缺点
- 为子页面创建了非常长的标题。
- 对于新用户来说，这种方法并不直观和简单。由于使用了两种不同的分隔符，可能会导致混淆或错误使用。
其他
[编辑源代码]请在此处放置其他方法
子层次结构
[编辑源代码]尽可能扁平
[编辑源代码]子页面的命名应以使每个子页面名称反映层次结构，但不引入子子页面级别的层次结构的方式进行。这应该以使subpagename与articlename一起尽可能自然的方式进行。
US History US History:Pre-Columbian US History:Civil War
优点
- 章节可以在将来轻松地重新排列。重点是子页面的内容，而不是它在书中的结构位置。
缺点
- 书籍的结构从标题中不可见。需要参考目录或其他导航帮助。
尽可能结构化
[编辑源代码]一本书可以分成几个章节、部分、子部分等等。子页面允许轻松构建这种层次结构，但并不限于使用子页面：使用任何分隔符都可以进行结构化。对于类似命名空间的分隔符，可以通过添加额外的 :subpagename 部分来实现，但这种方法没有在命名空间中反映出来。
Geometry US History US History:Pre-Columbian US History:Pre-Columbian:Aztec Empire US History:Pre-Columbian:Mayan Empire
优点
- 书籍结构很容易看到：人们“知道”自己处于书籍的哪个部分。
缺点
- 主要缺点是子层次结构可能会使书籍稍微难以阅读或呈现。
- 另一个缺点是它不允许一个页面在非线性维基教科书的层次结构中占据多个位置。例如，Cookbook:San Francisco style Scallop Ceviche 是扇贝酸橘汁腌鱼食谱、主菜、开胃菜、扇贝食谱和加州美食食谱，可以归类于其中的任何一种。 Gentgeen 22:12, 13 Mar 2005 (UTC)
子页面上的标题
[编辑源代码]在子页面上使用完整的书名
[编辑源代码]一种bookname方案是在内容和书籍页面本身使用相同的articlename，即bookname是内容页面，bookname:subpagename是在子页面上。
SA NC Doing Investigations ⇐ bookname SA NC Doing Investigations:Chapter 1 SA NC Doing Investigations:Chapter 2 ⇐ same bookname
优点
- 人们（读者和自动软件）可以很容易地看到哪个子页面属于哪本书。
- 知道任何子页面的名称，我就知道这本书的名称。
缺点
- 子页面标题可能会很长。
在子页面上使用简短的书名
[编辑源代码]另一种可能性是，为书名使用一个长而复杂的标题，但为子页面使用一个较短的标题，即在内容中使用长的bookname，在子页面中使用较短的shortbookname。较短的标题不应缩短到影响可读性的程度——例如，“IP:…”不应被用作“哲学导论”的简短标题；这样做不好的一個原因是，它可能會與“Inside Perl”之类的标题混淆。
Learning the vi editor ⇐ bookname Learning vi:Basic tasks Learning vi:Advanced tasks ⇐ shorter bookname
优点
- 长标题可以更具描述性，而不会使书的所有部分都杂乱无章。
缺点
- 使自动提取书本信息变得更加困难。
- 子页面只有在每个子页面上都使用相同的标题时才起作用。
数字作为章节
[编辑源代码]使用章节描述
[编辑源代码]Business English/Getting more practice Business English/Phrasal verbs Business English/Phrasal verbs/Get
优点
- 人们知道章节的内容。
- 很容易在现有章节之间插入新章节或改变它们的顺序（这对维基流程很重要！）。
- 章节可以在将来轻松地重新排列。重点是子页面的内容，而不是它在书中的结构位置。
缺点
- 人们不知道当前在书中的位置 => 需要额外的导航结构。
使用章节编号
[编辑源代码]Computer Science:Algorithms:Chapter 1 Computer Science:Algorithms:Chapter 2 Computer Science:Algorithms:Chapter 3
优点
- 强调了书的结构。
缺点
- 这个数字没有说明章节的内容。
- 很难重新排列章节或在现有章节之间插入新章节（移动所有更高层的书籍，或复制所有内容？）。这一点相当严重，因为维基书籍预计在未来会不断增长。
- 它在非线性维基书籍中完全不可用。
使用章节编号和描述
[编辑源代码]Macbeth - Act 5, Scene 1 - Dunsinane. Ante-room in the castle Macbeth - Act 5, Scene 2 - The country near Dunsinane Macbeth - Act 5, Scene 3 - Dunsinane. A room in the castle
优点
- 人们知道自己身处书中的哪个部分。
缺点
- 难以插入新章节。
- 标题太长。
个人喜好和讨论
[编辑源代码]请将这些方法的优缺点放在上面的相应部分，并将个人喜好放在这里。
我认为，鉴于目前存在的混乱，未来明确的方向是为未来的书籍（希望在未来的某个时刻，未来的书籍数量会超过现有的书籍）提供一个明确的建议，无论这个建议是什么。由于子页面提供到父页面的自动链接，并且（或多或少）强制在书籍的所有子页面上使用完全相同的书名，所以我的个人喜好是推广子页面作为前进的方向，明确建议只使用一层子结构（没有子子页面），以及使用章节描述而不是编号。--Andreas 09:37, 13 Mar 2005 (UTC)
- 以下投票的结果不应仅仅是一个建议——它应该是政策。我对子页面没有真正的问题，除了我之前提到的关于层次结构和“：”带来的“最小意外原则”的评论。 Dysprosia 10:36, 13 Mar 2005 (UTC)
- 除了 15 个标准命名空间之外，帮助:命名空间 中列出的其他命名空间实际上都不是真正的命名空间（食谱不是，维基versity 也不是……我知道这一点，因为我把我的 Wikibooks:Top active SQL 搜索限制在命名空间“0”中，而食谱和维基versity 都在其中——顺便说一下，我的书籍列表统计了 400 个标题）。我引用自 Wikibooks talk:Namespaces#命名空间政策
- “在当前的实现中，拥有太多自定义命名空间是一个不好的主意——所有命名空间都必须在 MediaWiki 配置文件中手动输入。此外，删除和重命名命名空间非常麻烦。因此，我建议保持自定义命名空间的数量较少，至少在最初阶段，可能 5 或 6 个。--Eloquence” [2]
- 所以我们实际上是在讨论“伪”命名空间，它们看起来像命名空间，但实际上并非如此（尽管如此，管道技巧对它们也适用：[[book:page|]] 将显示为 [[page]]）。鉴于此，使用什么符号来分隔书名和子页面名只是一个喜好问题。唯一真正支持层次结构的是子页面，它们提供到父页面的自动链接。这个选项在 帮助:命名空间 中讨论问题时并不存在（因为子页面最近才在维基书籍的主命名空间中启用），但现在可以使用了，并可能通过免费提供基本的导航功能来帮助每周出现的众多新维基书籍。--Andreas 23:35, 13 Mar 2005 (UTC)
- 除了 15 个标准命名空间之外，帮助:命名空间 中列出的其他命名空间实际上都不是真正的命名空间（食谱不是，维基versity 也不是……我知道这一点，因为我把我的 Wikibooks:Top active SQL 搜索限制在命名空间“0”中，而食谱和维基versity 都在其中——顺便说一下，我的书籍列表统计了 400 个标题）。我引用自 Wikibooks talk:Namespaces#命名空间政策
- 子页面缺点
我把以下关于子页面的缺点（似乎带有个人偏好：“……很烦人……”）放在了讨论部分，并将上面的观点改写为更中性的语气。--Andreas 08:55, 2 Apr 2005 (UTC)
- 层次结构通常是错误的。 茴香 是一种香料、草药和蔬菜。 搅拌器 既是一种烹饪技巧（动词），也是一种烹饪工具（名词）。子页面不允许这种情况；它们只支持树形结构。
- 这一点可能应该放在“扁平化与结构化”下面。如上所述，我可以使用所有分隔符（“/”，“：”）建立一个扁平的层次结构，也可以使用所有分隔符建立一个深层的树形结构（例如，Cookbook:Spices:Anise vs. Cookbook/Anise）。--Andreas 08:55, 2 Apr 2005 (UTC)
- 不，因为“/”分隔符是特殊的。它具有内置的维基支持，强制执行树形结构。这不好。
- 这一点可能应该放在“扁平化与结构化”下面。如上所述，我可以使用所有分隔符（“/”，“：”）建立一个扁平的层次结构，也可以使用所有分隔符建立一个深层的树形结构（例如，Cookbook:Spices:Anise vs. Cookbook/Anise）。--Andreas 08:55, 2 Apr 2005 (UTC)
- 如果你想将维基文本作为文件进行处理，子页面就会非常烦人。例如，你可能会将维基文本保存到 Linux 系统上的文件，以便可以使用 grep 命令（或稍微复杂一些的脚本）。使用“/”会使这变得很麻烦。Shell 通配符扩展失败，因此需要使用“find”命令。文件不再可以简单地保存；需要使用“mkdir”命令。
- 结构是否“烦人”可能取决于你想要做什么，你想处理多少维基书籍等等。我同意，如果你有使用食谱的脚本，并且在更改后它们不再工作，这很烦人，但想象一下，每个维基书籍都有自己的 URL（cookbook.wikibooks.org，kochbuch.wikibooks.org，howtobuildacomputer.wikibooks.org，……），并且你想处理它们——难道你不会在处理之前将每本书的页面放在一个单独的目录中吗？（有些页面可能有相同的名称！）所以，“/”分隔符会为你自动完成这些操作！--Andreas 08:55, 2 Apr 2005 (UTC)
- 实际上我只想处理一本，就是食谱。我不希望看到 Cookbook/Vegetable/Anise、Cookbook/Spice/Anise 和 Cookbook/Herb/Anise。它们将是什么？符号链接？重复副本？硬链接？无论如何，这种人为强制的层次结构会造成混乱。
- Glossary/Anise 怎么办？我并不是想改变现有的维基书籍，而是想为许多只有几页的维基书籍找到最实用的形式，这些维基书籍会突然出现，而且没有明确的命名方案。由于许多新出现的维基书籍甚至缺少导航模板，所以对这些新书籍来说，最好的方法是提供一个自动链接回它们的首页，并强制所有页面都以相同的书名开头。这就是子页面的作用。
- 我看到对于规模更大的项目，伪命名空间也有意义，这就是为什么我建议一个双重政策：对于具有线性结构的书籍（从头到尾阅读）使用子页面，而对于像食谱这样的项目集合，使用命名空间式的结构。你认为这种妥协怎么样？--Andreas 06:11, 3 Apr 2005 (UTC)
- 人们不断提出例外情况，说明为什么某个方案行不通。无论最终确定哪种方案（或方案），都会有一些特殊情况无法解决（因此需要解决方法）。我同意，子页面适用于线性书籍，命名空间适用于集合，因此我认为同时采用两者是一个好主意。将两者混合显然不太理想，因此可能需要为属于集合的线性书籍（例如，编程命名空间中的线性规划教科书）找到解决方法。--M.linger 6 July 2005 03:51 (UTC)
- 实际上我只想处理一本，就是食谱。我不希望看到 Cookbook/Vegetable/Anise、Cookbook/Spice/Anise 和 Cookbook/Herb/Anise。它们将是什么？符号链接？重复副本？硬链接？无论如何，这种人为强制的层次结构会造成混乱。
- 结构是否“烦人”可能取决于你想要做什么，你想处理多少维基书籍等等。我同意，如果你有使用食谱的脚本，并且在更改后它们不再工作，这很烦人，但想象一下，每个维基书籍都有自己的 URL（cookbook.wikibooks.org，kochbuch.wikibooks.org，howtobuildacomputer.wikibooks.org，……），并且你想处理它们——难道你不会在处理之前将每本书的页面放在一个单独的目录中吗？（有些页面可能有相同的名称！）所以，“/”分隔符会为你自动完成这些操作！--Andreas 08:55, 2 Apr 2005 (UTC)
kelvSYC 对这个问题的想法：我认为良好的、一致的组织是必不可少的。因此，命名方案应该与用于模板/类别等的方案相关。所以我的想法是
- 无论约定是什么，每本现有的维基书籍都应该转换为标准约定。
- 我认为没有分隔符的标题意味着一个单独的维基教科书。类别应该组织书籍的各个部分（例如，教科书答案键），以及相关的书籍（例如，抽象代数 和 线性代数 应该归类为“数学教科书”）。由于书籍很有可能成为其他书籍的一部分，因此类别系统应该反映这一点。
- 类别也可以用于，例如，自动索引功能（参见 维基教科书神奇宝贝图鉴），但应避免使用。
- 只有大型过于通用的书籍才值得拥有独立的命名空间。好的例子包括 食谱，编程，以及 游戏指南和策略。
- 如果书籍的标题页不包含目录、索引等，则应使用冒号分隔（例如，“Foo:目录”，“Bar:字母索引” vs. “Baz/第1章”）。
- 实际的书籍内容应尽可能放在子页面中。
- 对于具有这种结构的书籍，应提供具有自定义上链接的顶级子页面（如果我们可以隐藏默认的上链接）。
- 关于页面（贡献者说明等）应使用冒号分隔（例如，“Foo:关于”，“Bar:贡献者说明”）。
- 永远不要使用方括号语法。
- 书籍应该适度结构化：书籍内部的层次结构应该尽可能结构化，但要足够扁平，以至于名称不会太长。（即使这意味着我们有一个很长的页面）层次结构不应该超过三到四层。
- 所有特定于单个书籍的模板和类别都应该以书籍的名称开头。（例如，“Template:Foo:TOC”，“Category:Bar:Pages on baz”）。
- 对于属于多本书籍的页面，将其作为一本书的子页面，并将所有其他页面重定向到它，并创建自定义上链接。它应该属于哪本书应该由讨论决定。
KelvSYC 05:51, 2005年4月13日 (UTC)
我认为我们可以说，我们将采用 Bookname:subpage 或 Bookname/subpage 层次结构。我倾向于使用前者，因为很多书籍使用自己的模板作为导航技术，因此 Bookname/subpage 层次结构看起来会很奇怪。此外，我认为，由于其他类型的命名空间，例如 Wikibooks: 和 Talk: 和 User: 等，都是以这种方式完成的，因此对于大多数用户来说会很直观。至于子结构，我相信这应该是各个书籍作者的决定——情况实在太多了。有些书籍最好只分成章节，有些书籍最好再进一步细分。--Naryathegreat|(讨论) 19:36, 2005年4月17日 (UTC)
投票
[编辑源代码]理想情况下，维基教科书社区应该提出一种方法，并为维基教科书的命名层次结构投票。这将有利于在维基教科书中保持一致性和易用性。
维基教科书应该积累一些命名层次结构方案，然后进行投票，投票应该在这里进行。
维基教科书的新 wikistats 报告
[编辑源代码]我很高兴宣布维基教科书的一份新报告，该报告定期由 Wikistats 作业生成。您将在其中找到书籍、其内容和一些统计数据的概述。我发现至少有 6 种命名章节的方案。这使得自动提取章节名称变得困难，因此在某些情况下，章节分组可能看起来有点奇怪。我相信当关于文章标题标准化的持续讨论取得成果时，这种情况会得到改善。请查看 按维基教科书统计 Erik Zachte 15:18, 2005年4月9日 (UTC)