華夏公益教科書:層次命名方案
 | 此頁面記錄了已過時的 華夏公益教科書政策或指南。 此前政策或指南的文字已被 華夏公益教科書：命名策略 取代。 |
華夏公益教科書上的書籍應按照華夏公益教科書作者的決定，結構化為部分（類似於章節）。但是，在華夏公益教科書文章名稱中，沒有一種統一的方法來表示子結構。本頁旨在討論當前使用的方法的優缺點，並確定一種使用的方法，然後將其作為對華夏公益教科書上未來書籍的明確建議 華夏公益教科書：命名約定。
命名約定中涉及幾個問題，最乾淨的做法是分別討論它們（例如，使用哪個分隔符（“：”、“/”、“(..)” 等）與是否允許多級層次結構或是否應該使用數字來標記章節等問題是相對獨立的）。每節都列出了當前的示例。
請在下面新增優勢或劣勢，或提供討論備選方案。
分隔符
[編輯原始碼]子頁面 "/"
[編輯原始碼]一種方法是使用子頁面，即對於名為 *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)