華夏公益教科書:政策與指南/投票/命名策略

華夏公益教科書：命名策略

簡介

目前華夏公益教科書沒有正式的命名策略。我們無法對新書強制執行任何命名約定，也沒有明確的指南指導新使用者如何命名頁面。本提案試圖引入一套最少、簡單的規則。它不涵蓋所有情況 - 像模板、分類、書籍名稱快捷方式等的命名將在以後（如果有必要）討論，請勿將它們與本提案聯絡起來。

提案

• 新書 - 僅允許斜槓作為頁面名稱的定界符。頁面名稱必須採用格式<Bookname/Chaptername>。冒號作為定界符僅限於食譜。
• 現有書籍 - 可以使用任何約定，前提是每個章節標題中都包含書籍名稱。因此，我們不再允許使用像Contents這樣的通用名稱的章節，這些名稱不包含書籍名稱。不會在任何現有書籍上使用關於頁面命名的清理框。現有書籍必須在其所有頁面（除斜槓約定外，它會自動提供反向連結）上提供自己的反向連結。
• 執行 - 可以將禮貌的清理請求放置在不符合新書的討論頁面（而不是模組頁面）上。對於現有書籍沒有執行措施。

理由

優點

• 在現有書籍中廣泛傳播，並且主要用於新書
• 一致、清晰、易於讀者和編輯理解的命名策略
• 斜槓約定提供預先格式化的自動反向連結到更高級別的頁面（書籍名稱、章節名稱）
• 斜槓約定提供使用快速連結到子章節（[[/chapter/]]）和同級章節（[[../sibling/]]）的獨特可能性，節省了輸入更長形式（[[bookname/chapter]])
• 冒號約定：僅適用於名稱空間（食譜所用）
• 消除現狀，即
  • 兩本完全不同的書籍可能會在不知情的情況下連結到同一個章節（如 內容）
  • 自動任務（使用機器人修復錯誤）很困難
  • 它可能會讓讀者和貢獻者感到困惑（如果貢獻者看到兩本具有完全不同命名約定的書籍）
  • 允許在一本書中使用兩種不同的命名約定

缺點

• 不允許書籍作者決定哪種命名約定最適合他們
• 強制書籍章節名稱看起來像計算機檔名，例如：Windmills/Australian farms
• 如果作者想使用更好的書籍章節標題，例如“澳大利亞農場風車的歷史”，那麼頁面看起來會有兩個大字型的標題
• 斜槓約定在每個頁面上插入一個強制的（無法關閉）第二行文字，其中包含預先格式化的反向連結，如果頁面包含自己的反向連結或書籍內容模板，例如 植物學 示例，則該文字是多餘的。

投票

只有註冊使用者，且至少編輯了20次才可投票。投票於3月1日格林威治時間凌晨00:01結束，結果是該動議以14票贊成2票反對的優勢透過。

贊成

1. 贊成 Krischik ^T 2006年2月12日 (UTC) 17:42
2. 贊成 此外，應該鼓勵（儘管現在還不是強制性）現有書籍採用對新書強制執行的格式，Jguk 2006年2月13日 (UTC) 15:40
3. 贊成 雖然我希望看到冒號約定也被包含在新書的選項中。我們目前需要某種策略，關於允許冒號的辯論可以作為獨立的議題和投票進行。--Rob Horning 2006年2月13日 (UTC) 16:17
4. 贊成 - 對我來說可以。-Matt 2006年2月13日 (UTC) 18:00
5. 贊成 - 我們需要一致性，這是一個開始，但應該擴充套件到所有書籍。 Gerard Foley 2006年2月13日 (UTC) 22:09
6. 是 我也在討論部分添加了關於(現有書籍)的評論。 --JMRyan 2006年2月13日 (星期一) 22:57 (UTC)
7. 是 儘管我希望在未來某個時間點，這個政策能夠擴充套件到所有書籍。一致性非常重要。ManuelGR 2006年2月14日 (星期二) 22:48 (UTC)
8. 是 --Kernigh 2006年2月15日 (星期三) 00:27 (UTC)
9. 是 作為這個政策的主要支持者之一，我當然支援它 ;-） Derbeth ^討論 2006年2月15日 (星期三) 09:23 (UTC)
10. 一致性與準確性一樣重要。 --LV ^{(黑魔標記)} 2006年2月17日 (星期五) 02:45 (UTC)
11. 同意 但請參見下面的備註。 --kwhitefoot 2006年2月17日 (星期五) 11:22 (UTC)
12. 是 對於現有書籍，我們可能需要考慮更改它們，但保留重定向以用於連結。 --Gabe Sechan 2006年2月17日 (星期五) 22:27 (UTC)
13. 是 The Doc 正如我們在it:wb中所做的那樣，所有書頁都應該重新命名。 2006年2月19日 (星期日) 12:01 (UTC)
14. 是 雖然我想知道，例如，“程式設計”名稱空間的可能性...(?) - marsian 2006年2月21日 (星期二) 04:45 (UTC)
    

投票現已結束

否

1. 否 - 投票否意味著作者可以選擇使用斜槓約定，也可以使用冒號約定或其他可接受的約定。 KHatcher 2006年2月21日 (星期二) 16:36 (UTC)
2. 否 - 我不同意強迫使用一個有明顯缺點的命名約定（參見下面的討論）。作者在開始編寫維基書籍時必須有選擇餘地。 BDB 2006年2月24日 (星期五) 18:37 (UTC)
   

投票現已結束

討論

在Wikibooks talk:命名策略中進行了非常長時間的討論。

冒號

我注意到Rob Horning的投票，以及他希望對新書籍使用冒號約定，但可以稍後討論。我認為這次投票對於新書籍的冒號約定立場相當明確，即不允許使用。就這樣。我個人希望這次投票能夠最終確保冒號約定永遠不被允許。其他人是否認為這個問題仍然開放，因為在我看來，經過所有討論，這個問題已經塵埃落定？ -Matt 2006年2月13日 (星期一) 18:05 (UTC)

任何人都可以在該政策通過後（假設它通過了）提出他們想要的任何修改建議。當然，這樣的修改是否會被接受是另一回事，這取決於是否有共識，Jguk 2006年2月13日 (星期一) 18:29 (UTC)

你說的完全正確，Jguk。我希望某種命名策略能夠成為一項強制執行的政策，無論它最終會如何發展。我和Matt可以就冒號的使用問題爭論不休，我猜我們在這方面有不同的意見。我們不應該讓多數人的暴政強加概念和問題給所有人，而且僅僅因為我覺得需要某種策略並不意味著我贊成整個策略。這個策略在將來某個時候一定會被修改，而且它應該被修改。新的使用者會來到維基書籍，而舊的使用者（也許是我自己）會離開。這類策略不應該“一成不變”，沒有可能被重新審查以確保它在將來仍然相關。目前的政策幾乎什麼都行，斜槓、冒號、脫字元、星號、金橘、括號、原力細胞，或者完全沒有命名約定，在我看來是不可接受的，需要改變。--Rob Horning 2006年2月19日 (星期日) 13:00 (UTC)

現有書籍

我已經投票“同意”。但是，我對現有書籍的措辭感到不舒服。我更希望斜槓策略應用於所有書籍，但對滿足既定最低要求的現有書籍不予執行。這樣，我們至少可以開始逐步淘汰或棄用非斜槓命名。我理解並樂於支援將現有書籍問題留待以後解決：我們需要從某個地方開始做決定。但即使這樣，我還是希望該策略聽起來更明確地表明我們正在將現有書籍問題留待以後解決，而不是像一項將現有書籍名稱列入祖父條款的決定。--JMRyan 2006年2月13日 (一) 23:15 (UTC)

討論頁面

我已經開始使用討論頁面來標記違規行為，就像這次投票中建議的那樣。我感覺它不起作用。NC 違規行為通常是由新使用者執行的，他們沒有養成檢查討論頁面的習慣。當然，我仍然支援“同意”，因為我相信這種極簡主義的方法是一個非常好的開始，如果某些事情的結果不如預期，我們可以在以後更容易地解決。--Krischik ^T 2006年2月15日 (三) 11:51 (UTC)

如果你想聯絡新使用者，使用者討論頁面也是一個好地方。那個橙色的橫幅（“您有新訊息”）通常足以讓新使用者注意到。--Rob Horning 2006年2月19日 (日) 13:24 (UTC)

但這隻有在使用者實際註冊的情況下才有效。這可以作為將頂層建立限制為僅註冊使用者的論據。--Krischik ^T 2006年2月25日 (六) 06:52 (UTC)

由於模糊而產生的剝奪權利

我認為整個問題正在以一種幾乎讓不精通計算機的人無法理解的術語進行討論，這意味著只有這些人會投票。而且，由於提議的結構符合大多數此類人群每天所處理的內容，因此異議意見似乎很少見，不是因為其他可能性沒有價值，而是因為認為自己有能力討論這個問題的人群是從可能投票支援某個特定方案的人群中選出的。事實上，很多術語對我來說也顯得模糊不清，而我擁有超過三十年的計算機經驗。是否有頁面能清晰地定義“名稱空間”、“標題”、“書架”、“書名”等術語？我貢獻最多的那本書的標題是“Visual Basic Classic”，但我懷疑“書名”指的是“Programming:Visual Basic Classic”。如果我把冒號換成斜槓，“書名”是什麼？也許我們需要採取更加嚴格的計算方式，並定義一個正式的語法。籠統地談論“計算機檔名”是不夠的，並非所有檔案系統都使用層次結構，而且很多使用此類系統的人即使使用層次結構也不理解它們。希望我的這些話有意義。--kwhitefoot 2006年2月17日 (五) 11:48 (UTC)

我理解提案的意思是“Book Name”這本書中的所有頁面都必須以“Book Name/”開頭。之後，各個書籍可以自由地使用最適合該書籍的任何合理的命名方式。我不同意你的看法，認為你的書名是“Programming:Visual Basic Classic”。它仍然是“Visual Basic Classic”——它會放在“Programming”或“Computer Programming”書架上，Jguk 2006年2月17日 (五) 12:17 (UTC)

如果我沒記錯的話，之前曾經討論過“Programming:Foobar”書籍的命名問題。當時我沒有太關注，因為我沒有參與這些書籍的編寫。我認為（其他人可能擁有更準確的資訊）這至少在一定程度上解決了，結果是將“Programming:Foobar”書籍改名為“Foobar”或“Foobar Programming”之類的名稱。書籍Programming:Ada和Programing:C#已移至Ada Programming和C# Programming，而Programming:Prolog和Programming:Visual Basic .NET已移至Prolog和Visual Basic .NET。此外，Programming本身已移至Computer programming。如果你要繼續關注，那麼你應該將Programming:Visual Basic Classic移至“Visual Basic Classic”或（不太可能）“Visual Basic Classic Programming”，甚至“Programming in Visual Basic Classic”。儘管Programming:Visual Basic Classic中的冒號最初是作為分隔符，但它不再能正確地作為分隔符，因為不再有“Programming”這本書。不幸的是，這使得你的標題狀態變得有些模糊。（1）你的書最有可能被視為一個子書，位於現在不存在的（除了作為重定向）的“Programming”書籍中——這是一種不幸的狀態。在這種情況下，你的書名為“Programming”。（2）如果你將冒號替換為斜槓，那麼你的書名將明確地是“Programming”，而你的書將明確地是“Programming”的子書——這再次是一種不幸的狀態。（3）也許你的書中的冒號應該解釋為只是一個冒號（就像 Harbison 和 Steele 的“C: A Reference Manual”中那樣）。在這種情況下，你的書名為“Programming:Visual Basic Classic”。在這種情況下，由於存在像Programming:Visual Basic Classic/Strings這樣的頁面，因此你的書至少部分地遵循了斜槓慣例。我猜想，冒號後面沒有空格使得（1）成為更可能的解釋。無論如何，你的書都位於Programming languages bookshelf上，因為該書架包含指向你的書的連結。我的建議——免費且物超所值——是最好將這本書的名稱改為“Visual Basic Classic”或“Programming in Visual Basic Classic”。如果有不止一位活躍的作者，則需要在他們之間達成共識。如果你願意，有一個機器人，tsca.bot，可以幫助你完成繁瑣的工作。必須請求它的幫助，我不知道如何進行這樣的請求。希望這能改善模糊不清，使一切都變得清晰。:-) --JMRyan 2006年2月17日 (五) 20:38 (UTC)

命名策略或命名指南

在我看來，命名策略很快就會成為一項強制執行的政策。維基百科和華夏公益教科書，除了是資訊來源外，也是關於自由的 - 自由地以你想要的方式撰寫文章或書籍。這種自由突出了我們生活中多樣性的美。我相信大多數華夏公益教科書的使用者都忘記了維基百科的第五個也是最重要的支柱是什麼 (請參見 維基百科的五個支柱)。制定更多規則並強制執行它們將使華夏公益教科書更加統一，但會對新手和現有作者施加更多限制。這是我對強制執行命名策略的基本反對意見。其次，使用斜槓作為頁面名稱分隔符的提議策略存在一些支持者忽視的缺點。在像醫學這樣的學科中，主題可能會出現在多個章節下，因為疾病或人體不像人造軟體或任何其他事物那樣相互重疊，並且可能無法清晰地彼此區分。從技術上講，醫學通常涉及連續變數，而不是工程或計算機科學專業的學生所處理的離散變數。例如，反射性交感神經病變 這樣的主題可能會出現在 手部和顯微外科、小兒外科 和 運動醫學 等章節下。冒號約定使得在各個章節下輕鬆列出主題，而無需重複！冒號有助於識別並連結到它所屬的書籍。這樣，書籍之間就不會有內部連結。我寧願將書籍視為主題文章的集合，而不是符合強制執行的策略的嚴格命名的章節的教條式集合。第三，自動連結回不是遵循斜槓約定的理由。作者建立了更清晰、更吸引人的導航模板 (參見 植物學)，沒有理由透過提供自動連結來抑制這種創造力。第四，最不重要的原因是，斜槓約定會使每個頁面的標題變長，如果層次結構很深，恕我直言，很醜。冒號將使每個頁面的標題簡短、簡潔和整潔。我承認有些書籍斜槓可能是一個更好的選擇，因此我支援允許作者自己決定什麼更適合他們的書籍目的的想法。--BDB 2006年2月24日 (星期五) 19:47 (UTC)

提議的政策實際上只要求所有書籍中的頁面以 書名/ 開頭。此後，頁面組織完全取決於個人作者。關於你與維基百科的比較，我注意到這是一個獨立的專案，我們應該自由地，也應該自由地，在適當的情況下制定獨立的規則。 Jguk 2006年2月25日 (星期六) 07:38 (UTC)

我不確定目前的提議政策是否真的符合這個想法。 食譜 是這個專案中從偽名稱空間到完整名稱空間的例子，冒號是其中的關鍵部分。我不知道完整名稱空間對於食譜作為一個維基專案來說是否很重要，但這確實給了這本書一種獨特的風格。如果食譜被豁免，其他書籍專案遲早也會要求同樣的“平等待遇”，我不明白為什麼食譜有什麼獨特之處，除了它是一個管理員的寵兒專案 (這在華夏公益教科書中並不一定是問題)，他們聯絡了一些開發者讓它成為一個名稱空間。

我強烈建議作者保持個性，冒號自然是一個邏輯分隔符，這使它看起來是一個合理的替代方案。我的觀點是，只有當有人嚴重濫用情況，並且你想確保你可以在將來有效地懲罰那些試圖做同樣的事情來傷害他人的人時，才能制定政策、規則或法律。關於某種命名策略的規則是有效的，因為命名模組為任何事物命名 (例如假裝這是維基百科，你可以有像 目錄、索引 或 附錄 這樣的章節) 是沒有道理的，而且嘗試重新連結這種命名的孤立內容也很麻煩。孤立模組在華夏公益教科書這裡是一個非常嚴重的問題，而且將來會更糟糕。至於除了在模組標題中包含書籍名稱以外的特定樣式 (最好放在開頭以便搜尋)，我準備為之奮鬥，並允許其他標準。--Rob Horning 2006年2月25日 (星期日) 08:03 (UTC)

"維基百科和華夏公益教科書，除了是資訊來源外，也是關於自由的 - 自由地以你想要的方式撰寫文章或書籍" – 不，這不是自由，而是無政府狀態。在維基百科，你不能隨心所欲地寫文章 - 生物文章、關於國家的文章等都有標準。我不認為對書籍作者來說，頁面命名有自由選擇很重要。正如我之前寫過的那樣，書籍作者應該寫書，而不是試圖發明新的命名方案。命名方案是完全無關緊要的，大多數讀者不會看頁面的實際名稱，他們會閱讀內容。 "制定更多規則並強制執行它們將使華夏公益教科書更加統一，但會對新手和現有作者施加更多限制。" 如果我是一個想要貢獻的新手，當我發現許多書籍使用完全不同的頁面命名方式時，我會感到非常困惑。如果一本書使用兩種不同的風格怎麼辦？ "第四，最不重要的原因是，斜槓約定會使每個頁面的標題變長，如果層次結構很深，恕我直言，很醜。" 這表明你不理解這個提議。你可以建立任意深度的書籍層次結構，並使頁面名稱僅包含兩部分：書籍名稱和章節名稱。斜槓約定不是關於在頁面名稱中顯示書籍內部結構，而是關於在頁面名稱中顯示書籍名稱，僅此而已。 "我寧願將書籍視為主題文章的集合，而不是符合強制執行的策略的嚴格命名的章節的教條式集合。" 書籍不是鬆散的文章集合。嘗試列印然後閱讀這樣的“書籍”。 意識研究 是一個構建良好的華夏公益教科書的例子。--Derbeth ^討論 2006年2月25日 (星期日) 11:55 (UTC)

Jguk，雖然你提到它只要求更改標題/子頁面名稱，但是你在 骨科手術 中所做的更改擴充套件到了標題/子頁面名稱1/子頁面名稱1，例如 骨科手術/基礎科學/骨骼損傷與修復。我們實施這項政策是因為我們想要或需要與維基百科不同嗎？華夏公益教科書是一個不同的專案，它不會也不一定會有一套不同的規則。我想提出的觀點是，我們是否需要命名 指南 而不是僵化的 政策。

Derbeth，我很快就會回來回答你提出的問題。 BDB 2006年2月25日 (星期日) 17:07 (UTC)

只要書籍中的每個頁面都以“骨科手術/”開頭，我非常樂意看到你在骨科手術頁面上實施任何其他結構。我試圖保留這本書的現有結構，同時對其進行重新命名。不幸的是，我很快意識到我不確定現有結構是什麼 (似乎存在兩種相互競爭的結構，如果我錯了，我道歉)。這就是我停止進行大量其他更改的原因。如果你能告訴我你認為這本書應該採用什麼結構，我很樂意幫助你實施它。關於維基百科，我們與維基百科不同 - 這意味著我們不一定與維基百科擁有相同的規則和結構，而不是說我們故意制定不同的規則和結構 - 我們應該做任何適合華夏公益教科書的事情。 Jguk 2006年2月25日 (星期日) 18:01 (UTC)

我仍然不明白這一點。我更喜歡“骨科手術：”而不是“骨科手術/”。為什麼這個規則在仍然是提案的情況下就被強制執行了？命名策略仍然列在“提案”下，而不是“強制”列下，我們不應該在投票中討論嗎？但可能是因為我們中有些人不想看到像食譜這樣的名稱空間，我們更喜歡“標題/結構”而不是“標題：”。我還沒有決定哪種方式更好，這就是我來到這裡的原因。也許“標題/章節名稱：”可以滿足需求。我還發現，使用斜槓結構進行管道操作很困難，而使用冒號則簡單得多。我認為，在華夏公益教科書中使用斜槓約定來搜尋主題會很不方便。我很樂意聽取你對這些問題的看法。回到維基百科，我想補充你說的：“我們應該做任何對華夏公益教科書合適的事情”——無論它是否來自維基百科。 -BDB 2006年2月25日 (星期六) 18:24 (UTC)

老實說，我看到並修改的第一個格式是頁面標題 (骨科手術)，如果我看到所有頁面都一致地使用骨科手術：頁面標題，我就會保持原樣。無論發生什麼，我相信我們都同意應該保持一致性，而且最好讓書名放在前面。 -Jguk 2006年2月25日 (星期六) 21:03 (UTC)

是的，我當時對這本書的結構很不確定，並且有一些頁面被命名為“子頁面名稱1(標題)”。我完全同意你的觀點，書名應該放在前面，然後是章節名或子頁面名。 -BDB 2006年2月26日 (星期日) 06:55 (UTC)

Derbeth，自由伴隨著責任，當我們不再負責任時，就會出現混亂。我認為華夏公益教科書的作者一直以來都沒有不負責任。不要把華夏公益教科書中看似混亂的活動誤認為是混亂。混亂中總是存在模式，只是需要一段時間才能變得清晰。我過去和現在都認為，我們強加給作者的規則越少，華夏公益教科書就會變得越美麗。讓我們制定指南，而不是強制執行的策略。維基百科的標準是隨著時間推移而演變的。它們不是一夜之間實施的。作者應該像對內容一樣擁有對書籍結構的權利。是否每個人都感興趣並不重要。一本書應該採用什麼命名約定，應該是由它的作者決定的，而不是由你、我或任何管理員決定的。我確實沒有理解這部分內容：“你可以擁有你想要的任何深度的書籍層次結構，並且頁面名稱只包含兩個部分：書名和章節名。斜槓約定不是為了在頁面名稱中顯示內部書籍結構，而是為了在頁面名稱中顯示書名，僅此而已。”。你能更清楚地向我解釋一下嗎？最後，雖然華夏公益教科書的目標是像一本印刷書籍一樣，但我認為它與印刷品有很大的不同。 -BDB 2006年2月25日 (星期六) 18:47 (UTC)

好的。讓我們假設有一本虛構的醫學書籍。你想寫一章“胸腺”。你不會將頁面命名為：“醫學/免疫學/免疫系統的器官/胸腺”，儘管這是你書中本章在層次結構中的位置。你只會把它命名為“醫學/胸腺”。如果它很長？你寫道：“作者應該像對內容一樣擁有對書籍結構的權利。”但是華夏公益教科書已經存在了近三年，作者有足夠的時間玩耍並觀察不同的命名約定如何運作。現在斜槓約定是最流行的，我認為沒有理由允許更多的命名約定，而這些約定並沒有比斜槓約定更有優勢。自由很重要，但是為什麼你需要在選擇書籍中使用的分隔符方面擁有自由？對你來說，冒號和斜槓之間的選擇重要嗎？我不接受僅僅為了自由而自由，我們不是為了給任何人自由去做任何他想做的事情而來到這裡的，我們是來寫好書的。維基百科不是一個民主的網站，華夏公益教科書也不是。在維基百科中，你不能將頁面命名為“眼鏡蛇 - 蛇”或“眼鏡蛇，蛇”，這樣的頁面會立即被重新命名，甚至不會問你，沒有人說維基百科不自由。 -Derbeth ^talk 2006年2月26日 (星期一) 15:36 (UTC)

Derbeth，我不得不遵循你提出的頁面名結構。贊成“醫學/胸腺”！但是我完全不同意你的自由概念。雖然你提到“維基百科不是一個民主的網站”，這是一個官方政策（參見維基百科不是一個民主的網站），但我希望你繼續閱讀並瞭解維基百科不是一個官僚機構，我引用如下：“應該透過協商一致的討論來解決分歧，而不是透過嚴格遵循規則和程式。應該避免指令蠕變。遵循任何規則、策略和指南的精神，而不是字面意思”。我的觀點就是這樣！ -BDB 2006年2月26日 (星期一) 18:42 (UTC)

但是我們正在在這裡討論。你舉了一個非常錯誤的例子。是的，我們不應該制定大量的指南和政策，但總有一些必須遵守的規則來維護專案的秩序。考慮維基百科中消歧義頁面命名約定——你是否可以忽略它？不，因為它是基礎性的。我認為命名策略也是這樣一條基礎性規則；它是基礎性的，因為事實上這裡沒有多少策略，我們也沒有要求太多。只需按照我們的要求命名頁面，一切就都好了——這就是我們想說的。提議的命名約定非常簡單，簡而言之就是：“在你建立的每一頁的名稱中新增書名-斜槓”。想想看——我們給予書籍作者極大的自由，命名策略並沒有阻止他們按自己的意願組織書籍。在我看來，頁面名稱不是創意作品的一部分，就像電腦上的檔名一樣——它們如何命名並不重要，重要的是裡面的內容。想象一個只允許你用大寫字母開標頭檔案名的作業系統。這是一種限制，但檔名首字母是什麼對你有實際意義嗎？如果我編輯或列印它，它就完全無關緊要。 -Derbeth ^talk 2006年2月26日 (星期一) 22:06 (UTC)