華夏公益教科書:層級命名方案
 | 此頁面記錄了已過時的 華夏公益教科書政策或指南。 此前政策或指南的文字已被 華夏公益教科書：命名策略 取代。 |
華夏公益教科書上的書籍應該被結構化為章節（類似於章節），由華夏公益教科書作者自行決定。但是，在華夏公益教科書文章名稱中沒有一種表示子結構的方法。此頁面用於討論當前使用的方法的優缺點，並決定要使用的方法，這將成為 華夏公益教科書：命名規範 中對未來書籍的明確建議。
命名規範涉及多個問題，最乾淨的方式是分開討論它們（例如，使用哪個分隔符（":", "/", "(..)", ..) 與是否允許多級層級或是否應使用數字來標記章節的問題或多或少是獨立的）。每個部分都說明了當前的示例。
請在下面新增優缺點，或提供討論替代方案。
分隔符
[編輯原始碼]子頁面 "/"
[編輯原始碼]一種方法是使用子頁面，也就是說，對於名為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）