维基教科书:层级命名方案
 | 此页面记录了已过时的 维基教科书政策或指南。 此前政策或指南的文本已被 维基教科书：命名策略 取代。 |
维基教科书上的书籍应该被结构化为章节（类似于章节），由维基教科书作者自行决定。但是，在维基教科书文章名称中没有一种表示子结构的方法。此页面用于讨论当前使用的方法的优缺点，并决定要使用的方法，这将成为 维基教科书：命名规范 中对未来书籍的明确建议。
命名规范涉及多个问题，最干净的方式是分开讨论它们（例如，使用哪个分隔符（":", "/", "(..)", ..) 与是否允许多级层级或是否应使用数字来标记章节的问题或多或少是独立的）。每个部分都说明了当前的示例。
请在下面添加优缺点，或提供讨论替代方案。
分隔符
[编辑源代码]子页面 "/"
[编辑源代码]一种方法是使用子页面，也就是说，对于名为bookname的维基教科书，以及名为subpagename的子页面，文章名称是bookname/subpagename.
Wikijunior Solar System Wikijunior Solar System/Mars Wikijunior Solar System/Glossary
优点
- 这种方案的主要优点是它允许在层级内自动导航链接。
- 这允许层级，但也允许子子层级等等。
- 每个子(子..)页面都获得到所有父页面的静态链接。可以使用 [[/subpagename]] 来引用子页面（即不需要 bookname）。
- 正如 1 年半前指出的那样，它在 URL 中看起来类似于目录 [1]，从这个意义上说，它也遵循 最小惊讶原则。
缺点
- 主要缺点是该方案促进了子层级的使用，这可能会使书籍略微更难阅读或呈现。此外，作者可能会倾向于过度使用树状结构。因此，推荐的一部分可能只使用一级子页面，如果非常大的书籍需要，则可以使用二级子页面（见下面单独的讨论点）。
- 从一个子页面到另一个子页面的链接必须完整地输入。此外，管道技巧不适用于子页面；[[Bookname/Subpagename|]] 显示为 Bookname/Subpagename
- 对子页面所有链接区分大小写；Wikijunior Solar System/The Sun 与 Wikijunior Solar System/the Sun
- 当人们想要保存文件并通过脚本和简单的类 Unix 命令（如 grep）自动处理它们时，分隔符 "/" 会干扰文件系统。需要使用额外的命令，如 "mkdir"、"find" 和 "xargs"。
- 强制的树状结构不适合许多用途。例如：茴香是一种香料、草药和蔬菜。没有正确的方法可以设置它，以使所有茴香的使用都提供自动链接。人们将不得不选择更通用的树节点，例如 "glossary/anise" 或完全扁平的结构（"cookbook/anise"）。
真实自定义命名空间
[编辑源代码]一种方法是使用 自定义命名空间，也就是说，对于名为bookname的维基教科书，以及名为subpagename的子页面，文章名称是bookname:subpagename. 例子
优点
- 这种方案类似于其他命名空间，因此遵循 最小惊讶原则。
- 使用管道技巧，链接变得简单；[[Bookname:subpagename|]] 变成 subpagename。
- Special:Allpages 可以应用于选择的书籍。
- 用户贡献 可以显示所有贡献，或限制为选择的书籍。
- 从 MediaWiki 1.5 开始，最近更改 也是如此；对于此，Allpages 和 User contributions，还可以选择除了指定命名空间以外的所有命名空间；因此，可以通过选择例如图像命名空间并使用反转选项来获得包含所有书籍页面的组合列表。
- 搜索 可以限制为任何书籍子集。
- 变量 {{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:最近更改、Special:所有页面、Special:需要页面、Special:孤立页面、Special:死胡同页面 和 Special:分类 中没有无关的杂乱信息。（没错！我们需要它！）
- 正常的维基易用性得到完全恢复：[[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:旧金山式扇贝酸橘汁腌鱼 是一种酸橘汁腌鱼食谱、主菜、开胃菜、扇贝食谱和加利福尼亚料理食谱，可以结构化在其中任何一个之下。 Gentgeen 22:12, 2005年3月13日 (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 个标准命名空间外，帮助：命名空间 中列出的其他命名空间实际上都不是真正的命名空间（食谱不是，维基学院也不是……我知道这一点，因为我将我的 维基教科书：最活跃 SQL 搜索限制为命名空间“0”，而食谱和维基学院都在其中——顺便说一下，我的书籍列表包含 400 个标题）。我引用了 维基教科书讨论：命名空间#关于命名空间的政策
- “在当前的实现中，拥有太多自定义命名空间是一个坏主意——它们都必须手动输入到 MediaWiki 配置文件中。此外，删除和重命名命名空间非常麻烦。因此，我建议保持自定义命名空间的数量较少，至少在最初阶段，可能为 5 或 6 个。——雄辩” [2]
- 因此，我们实际上讨论的是“伪”命名空间，它们只是看起来像命名空间，但实际上并非如此（尽管如此，管道技巧对它们也有效：[[book:page|]] 将显示为 [[page]]）。鉴于这一点，使用哪种符号来分隔书名和子页面名只是个人喜好问题。唯一真正的层次结构支持是为子页面提供的，它提供了一个指向父页面的自动链接。在 帮助：命名空间 上讨论这些问题时，此选项还不可用（因为子页面最近才在维基教科书的主命名空间中启用），但现在已经可用，并可能通过免费提供基本的导航功能来帮助每周出现的大量新维基教科书。--Andreas 23:35, 13 Mar 2005 (UTC)
- 除了 15 个标准命名空间外，帮助：命名空间 中列出的其他命名空间实际上都不是真正的命名空间（食谱不是，维基学院也不是……我知道这一点，因为我将我的 维基教科书：最活跃 SQL 搜索限制为命名空间“0”，而食谱和维基学院都在其中——顺便说一下，我的书籍列表包含 400 个标题）。我引用了 维基教科书讨论：命名空间#关于命名空间的政策
- 子页面的缺点
我把下面这些关于子页面的缺点归类为个人喜好（“..非常令人讨厌..”），并把上面的观点改成了更中立的语气。--Andreas 08:55, 2 Apr 2005 (UTC)
- 层次结构通常是错误的。 茴香 是一种香料、草药和蔬菜。 搅拌器 既是一种烹饪技巧（动词），也是一种烹饪工具（名词）。子页面不允许这样做；它们只支持树形结构。
- 这一点应该放在“扁平 vs. 结构化”之下。正如上面所指出的，我可以使用所有分隔符（“/”，“：”）建立一个扁平的层次结构，也可以使用所有分隔符建立一个深层的树形结构（例如，食谱：香料：茴香 vs. 食谱/茴香）。--Andreas 08:55, 2 Apr 2005 (UTC)
- 不，因为“/”分隔符是特殊的。它有内置的维基支持，可以强制执行树形结构。这不好。
- 这一点应该放在“扁平 vs. 结构化”之下。正如上面所指出的，我可以使用所有分隔符（“/”，“：”）建立一个扁平的层次结构，也可以使用所有分隔符建立一个深层的树形结构（例如，食谱：香料：茴香 vs. 食谱/茴香）。--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)
- 实际上，我只想处理一本食谱。我不想看到食谱/蔬菜/茴香、食谱/香料/茴香和食谱/草药/茴香。它们将是什么，符号链接？重复副本？硬链接？无论哪种情况，这种人工强加的层次结构都会造成混乱。
- 术语表/茴香呢？我并不是想改变现有的维基教科书，而是想找到一种对大量只有几页的维基教科书最实用的形式，这些维基教科书没有明确的命名方案。由于许多初级的维基教科书甚至缺乏导航模板，因此对这些新书来说，最好的方法是拥有一个指向主页面 的自动链接，并强制所有页面都以相同的书名开头。这就是子页面所做的事情。
- 我看到，对于规模更大的项目，伪命名空间也有意义，这就是为什么我建议制定双重政策：对于具有线性结构的书籍（从头到尾阅读）使用子页面，对于像食谱这样的项目集合使用类似命名空间的方式。你对此折衷方案有什么看法？--Andreas 06:11, 3 Apr 2005 (UTC)
- 人们不断提出例外情况，说明为什么某项方案行不通。无论最终决定采用哪种方案（或哪些方案），都会有一些特殊情况无法适用（因此需要变通方案）。我同意子页面适用于线性书籍，命名空间适用于集合，因此我认为采用两者都是一个好主意。显然，混合使用两者不太理想，因此可能需要针对属于集合的线性书籍找到变通方案（例如，编程命名空间中的线性规划教科书）。--M.linger 6 July 2005 03:51 (UTC)
- 实际上，我只想处理一本食谱。我不想看到食谱/蔬菜/茴香、食谱/香料/茴香和食谱/草药/茴香。它们将是什么，符号链接？重复副本？硬链接？无论哪种情况，这种人工强加的层次结构都会造成混乱。
- 结构是否“令人讨厌”可能取决于你想要做什么，你想要处理多少维基教科书等等。我同意，如果你使用脚本处理你的食谱，并且在更改后它们不再工作，这是令人讨厌的，但想象一下，每本维基教科书都有自己的 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：贡献者说明”）。
- 永远不要使用方括号语法。
- 书籍应该适度结构化：书籍内部的层次结构应该尽可能结构化，但要足够扁平，以确保名称不会过长（即使这意味着我们会有一个非常长的页面）。层次结构的深度不应超过三到四层。
- 所有特定于单个书籍的模板和类别都应该以书籍名称开头（例如，“模板：Foo：目录”、“类别：Bar：关于 baz 的页面”）。
- 对于属于多本书籍一部分的页面，将其作为其中一本书的子页面，并将其他书籍的页面重定向到该页面，并创建自定义向上链接。该页面应该属于哪本书应该由讨论决定。
KelvSYC 05:51, 13 Apr 2005 (UTC)
我认为可以安全地说，我们将采用 Bookname:subpage 或 Bookname/subpage 层次结构。我倾向于前者，因为许多书籍使用自己的模板作为导航技术，因此 Bookname/subpage 层次结构看起来会很奇怪。此外，我认为，由于其他类型的命名空间（如 Wikibooks: 和 Talk: 和 User: 等）都是以这种方式完成的，因此对大多数用户来说会很直观。至于子结构，我认为应该由各个书籍作者决定——情况实在太过复杂。有些书籍最好只分成章节，有些书籍最好分成更多部分。--Naryathegreat|(讨论) 19:36, 17 Apr 2005 (UTC)
投票
[编辑源代码]理想情况下，维基教科书社区应该提出一种方法并对维基教科书范围内的命名层次结构方案进行投票。这将有利于维基教科书内部的一致性和易用性。
维基教科书应该积累一些命名层次结构方案，然后进行投票，投票应该在这里进行。
维基教科书的新 wikistats 报告
[编辑源代码]我很高兴地宣布一个由 Wikistats 作业定期生成的维基教科书新报告。您将在其中找到关于书籍、其内容和一些统计数据的概述。我发现至少有 6 种章节命名方案。这使得自动提取章节名称变得很困难，因此在某些情况下，章节分组可能看起来有点奇怪。我相信当关于文章标题标准化正在进行的讨论取得成果时，这种情况将会得到改善。请查看 按维基教科书统计 Erik Zachte 15:18, 2005 年 4 月 9 日（UTC）