維基百科常用列表組織信息。列表可在散文條目的正文找到，也可以在「出版物」或「作品」部分等附錄找到，或作為獨立條目。本指引解釋了何時以及如何適當地使用列表。
 |
 | 本頁簡而言之：
|
 | 此頁面中包含的一個或多個部分是中文維基百科方針。這些部分分別標有{{Policy section}}。本頁面沒有標記為這樣的部分並不是方針。 |
 | 此頁面中包含的一個或多個部份是中文維基百科指引，這些部份分別標有{{Guideline section}}。本頁面中沒有這樣標記的部份就不是指引，僅為論述。 |
格式和內容
列表的主題應該十分明確，通常應該通過列表的標題反映，例如「國旗列表」，如果列表的標題不能準確反映列表的內容，則應該在列表的起始段給出明確的說明，不要讓其他編輯者和讀者猜測一個列表應該包含什麼內容。
一個獨立列表的標題就是該頁面的名稱，一個嵌入列表（作為一個段落依附在條目中的列表）的標題應該是段落的標題。列表一般應該以「列表」或者「表」為結尾，比如「國旗列表」。
|
一個獨立的列表是一個條目，任何條目都應該有一個概述部分，列表也不例外。即使是內容非常明顯的列表，也應該有概述，在概述中應該有對列舉主題的簡要的介紹，須說明合理的列表收錄準則，即內容的選擇標準或收錄範圍。存在爭議時，須依照可供查證的要求提供來源。[方針]如果標準複雜，則應該詳細寫明，以便讓讀者和其他編輯者明確了解該列表應該包含怎樣的主題。同時，概述部分還應該表明一些含義不明顯的符號和格式，例如「『*』表明有爭議」等。
嵌入列表沒有概述的嚴格要求，但如果列表標準不明確時推薦在概述中加以說明。
列表的主題內容無例外的要求滿足Wikipedia:中立的觀點和Wikipedia:可供查證原則。如果沒有參考資料支持一個主題被列入某一個列表，則將其列入該列表就是「原創研究」；如果有參考資料支持一個主題列入，而不將其列入則是非中立觀點（POV）。在編輯列表的時候應該特別注意其內容與一般條目內容的區別，以及在這種情況下維基百科各個方針指引的適用度。如果列表涉及在世人物，Wikipedia:生者傳記方針則應該受到重視。條目名存在類似「傑出/著名人物」等可能模稜兩可、有失中立及原創研究等措辭時，須提供來源。
|
列表若有「同源條目」，可先考慮「篇幅容許」的情況下，置於同源條目中而不單獨成條。「同源條目」即「XX」和「XX列表」之關係。「篇幅容許」情況有：列表內條目本身極少；列表本身絕大多數為下級列表的連結。
列表不應僅單純地列出各項名稱，而應提供各項名稱簡介或各項之間可比較的信息等其他資訊，即該列表不應該可簡單的由分類取代。而未改善的單純列出各項名稱的列表應經存廢討論刪除或改為分類。不應以列表包含紅鏈作為列表不可由分類取代的原因；是否提供各項名稱簡介或各項之間可比較的信息等其他資訊，應為區別列表與分類的唯一標準。
每一個列表都應該被分類於包含列表的頁面分類中，其根目錄是Category:列表。
以地方劃分的人物列表的收錄標準
|
就以國家、政治實體、國籍、出生地或籍貫來劃分的人物列表來說，有以下規限：
- 中文維基百科容許建立×國人列表，但是僅限於索引形式，例如這樣。因此，必須要有至少5篇下級列表才可以以×國人列表作為索引，否則不予創建。
- 如果人物列表的收錄範圍可以預期將會或已經超過100人的話，應該再作細分至下下級列表，直至不超越100人為止。
- 國籍、出生地或籍貫無可靠來源證實的人物不予收錄。
- 每篇列表在創建時至少需要有50人，否則刪除。
條目內嵌入人物列表的收錄標準
|
對於條目內人物嵌入列表，其存廢標準可較獨立列表更為寬鬆一些，具體情況可自行考量，如遇爭議可到Wikipedia:互助客棧/方針尋求共識。以下羅列已達成共識的部分主題：
- 姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:×姓」或獨立列表體現。
- 疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:×疾病患者」或獨立列表體現。
- 一般而言，行政區劃條目中禁止嵌入僅單純列點之人物列表，此類信息應由「分類:××人」或獨立列表體現。
列表形式
維基百科區分了主要由列表組成的條目（一般稱為「列表」或「獨立列表」）和主要由散文組成的條目（稱為「條目」）。條目旨在主要由散文組成，儘管它們可能包含一些列表。
列表條目是百科全書式的頁面，由一個序言部分和一個列表組成（可以用標題劃分，也可以不用）。這些列表上的項目包括與某一特定主題領域的條目的鏈接，並可能包括有關所列項目的額外信息。獨立列表的標題通常以條目的主題開始，然後是列表的類型（列表、索引等），例如，植物油列表。它們可以按主題分類或按主題以平面或分層結構進行組織。
標題和符號的格式，或垂直格式，是獨立列表的常見格式。這些維基百科條目遵循Wikipedia:獨立列表的格式指引。
嵌入式列表是在條目中使用的列表，補充條目的散文內容。它們包含或附加在正文中，並可能是表格格式。維基百科使用幾個標準的附錄，通常是以列表的形式，以及導航模板。
只有在適當的時候才可以使用嵌入式列表；有時，列表中的信息最好以散文形式呈現。以列表形式呈現過多的統計數據可能違反方針。
當列表中的項目是其前面段落的「子項」時，使用列表格式可能是合適的。這種「子項」在邏輯上有資格縮進到其父項的描述之下。在這種情況下，以列表形式縮進段落可能會使它們更容易閱讀，特別是在段落很短的情況下。下面的例子在有和沒有圓點的情況下都適用：
| 散文 | 列表 |
|---|---|
| 在二十世紀初，紐約市是美學建築運動的中心，吸引了包括斯坦福·懷特、卡雷爾和黑斯廷斯等偉大建築師的人才。隨着本世紀的發展，更好的建築和工程技術的出現，紐約成為世界上最高建築競爭的焦點。
這個城市的天際線由無數不同的摩天大樓組成，其中許多是二十世紀建築的標誌。熨斗大廈高285英尺（87米），在1902年竣工時是該市最高的建築之一，它的鋼製骨架使之成為可能。它是第一批用鋼架設計的建築之一，用當時的其它建築方法要達到這個高度是非常困難的。伍爾沃斯大樓是一座新哥特式的 "商業大教堂"，俯瞰市政廳，由卡斯·吉爾伯特設計。它的高度為792英尺（241米），在1913年建成後成為世界上最高的建築，這一榮譽一直保持到1930年，當時它被華爾街40號所超越。同年，克萊斯勒大廈率先成為世界上最高的建築，在1046英尺（319米）的高空划過。比它的高度更令人印象深刻的是該建築的設計，由威廉·凡·阿倫設計。克萊斯勒大廈是一個裝飾風藝術的傑作，其外觀由磚塊製成，至今仍是紐約人的最愛。 |
在二十世紀初，紐約市是美學建築運動的中心，吸引了包括斯坦福·懷特、卡雷爾和黑斯廷斯等偉大建築師的人才。隨着本世紀的發展，更好的建築和工程技術的出現，紐約成為世界上最高建築競爭的焦點。這個城市的天際線由無數不同的摩天大樓組成，其中許多是二十世紀建築的標誌：
|
個人或團體的作品列表，如書目、唱片、電影、專輯人員和曲目列表，通常以簡單的列表格式呈現，儘管預計這些信息將通過對要點的散文分析在條目的其它地方得到支持，如果列表變得難以處理，則按照WP:摘要格式將其拆分為獨立的列表。時間線和年表可以作為現實世界歷史的散文描述的有益補充。列表的內容受與散文相同的內容方針的約束，包括應有的比重和避免原創研究的原則。根據維基百科的方針和指引（包括WP:TRIVIA部分），確保列表項目對主題的重要性與該項目在條目正文中的要求相同。考慮一下散文是否更合適。關於時間線的具體建議在Wikipedia:年表標準中給出。
「參見」列表和「相關條目」列表是寶貴的導航工具，可以幫助用戶找到相關的維基百科條目。當決定在任何給定的條目中添加哪些條目和條目列表時，試着把自己放在讀者的頭腦中是很有用的。問問自己，讀者在讀完這篇條目後可能想去哪裡。一般來說，這將包括三種類型的鏈接：
- 相關主題的鏈接 - 與條目中討論的主題類似。
- 高階（即，更大體的）條目和列表--這可能包括人的列表、主權國家列表，等等。例如，印度語詩人列表應該同時鏈接到印度人列表和詩人列表。
- 低階（即更具體）的條目和列表--例如，企業頁面導航列表包含小企業的鏈接，會計主題列表等。
對於在任何條目中應該放多少個條目鏈接和列表鏈接，存在一些爭議。有些人把「條目鏈接」（放在「參見」部分）和「列表鏈接」（放在「相關主題」部分）分開，但這是沒有必要的，除非有太多的鏈接需要單獨放在一個部分。有些人認為，在任何一篇文章的結尾，應該包括的列表鏈接的最佳數量是0、1或2。另一些人則認為，一套更全面的列表會很有用。一般來說，在決定包括什麼列表時，應該使用決定在「參見」部分包括什麼條目的相同標準。編輯應該試着把自己放在讀者的心態上，問「讀完這篇條目後我可能想去哪裡？」。一般來說，「參見」部分不應重複出現在條目正文中的鏈接。
參考資料列表展示了維基百科之外的信息來源。兩種最常見的類型是：
- 「網絡超鏈接」 - 在「外部連結」標題下的維基百科以外的網址鏈接列表
- 「參考文獻」 - 在「參考資料」標題下的學術期刊文章或書籍列表
維基百科不是一個鏈接集，積極不鼓勵只有外部連結的條目，但從互聯網上引用更詳細的資料是合適的。當你把一個網站作為重要的信息來源時，情況更是如此。
維基百科上的大多數列表是項目列表，但不是全部。專門的列表類型包括：
- 大綱 - 維基百科的大綱是一個分層排列的屬於某一特定主題的主題列表。大綱是維基百科上兩種類型的一般主題列表之一，另一種是索引。
- 索引 - 維基百科上的索引是一個按字母順序排列的關於某一特定主題的文章列表。
- 時間軸 - 時間軸是按時間順序排列的事件的圖形表示。
- 作戰序列 - 武裝力量組成部分的代表，顯示了層級組織和指揮結構。
- 作品列表包括書目和唱片目錄。書目是一個主題領域的相關參考文獻列表，包括書籍、期刊文章和網絡文章；唱片目錄是一個音樂家或歌手的所有唱片的列表，也可以根據流派或唱片公司來編制。
- 詞彙表 - 詞彙表是一個特定主題領域的術語列表，其中包括定義。
- 同類索引條目 - 記錄一組共享相同（或相似）名稱的項目。它們與消除歧義的頁面不同，因為它們是完整的條目，旨在記錄多個主題，而消除歧義的頁面僅用於導航目的。並非所有的同類索引條目都是列表。
- 動態列表 - 動態列表是任何隨着其涵蓋的主題變化而變化的列表。因此，它可能永遠不會被完成。任何類型的列表都可能是動態的。
列表用途
| 本頁是維基百科的方針、指引或流程的草案。 該草案可能仍在草議中、討論中或正在達成共識以便通過。 |
列表主要有三類用途：
列表可以提供有價值的資訊，尤其是結構化列表——例如按時間組織的列表、按主題分組的列表，或項目附帶說明描述的列表。
項目包含內部連結時，列表可以自然成為維基百科的內容索引。如果讀者對搜索目標有大致概念，但不知道具體術語，則可以瀏覽內容大綱，它自上而下通向維基百科大部分（即使不是全部）列表，進而通向相關條目。首頁可進入的主題空間中（部分主題）也列出了一些列表；此外，在列表條目（或其他條目）底部也通常有導航模板鏈往其他列表。
一些列表有助於維基百科發展。一系列主題列表可以表明維基百科當前狀態，尤其是標示已寫條目和未寫條目。然而，維基百科主要為讀者而非編者優化，故主要為開發維護而存在的列表（如只含有紅鏈且未提供有價值資訊的列表，特別是項目均為紅鏈的主題列表）應該放在維基百科（「Wikipedia:」）或用戶（「User:」）命名空間，而非主命名空間。
列表和分類同時存在是有益的，因為這兩種項目組織方式協同運作（《WP:分類、列表與導航模板》提及了相關原則）。與分類相同的是，列表可以使用鏈出更改功能來監視所列頁面的更改；與分類不同的是，列表還能在編輯歷史中顯示其所含項目的變化，還允許在同一頁面上顯示大量項目。
列表命名
對於一個獨立的列表，列表的標題是頁面名稱。對於嵌入式列表，列表的標題通常是一個章節的標題（例如，超人前傳 (第一季)#各集列表），但它可以更短。列表的標題不應具有誤導性，通常不應包括縮寫詞。此外，過於精確的列表標題可能不那麼有用，而且會使列表難以找到；列表的精確收錄標準應該在標題部分（見下文）闡明，而不是在標題中闡明。例如，像「完整」和「顯著」這樣的詞通常不會出現在列表標題中。相反，標題應明確說明該名單是否完整，或者是否僅限於廣為人知或著名的成員（即那些值得發表的條目）。請注意，「著名」一詞被認為是一種不必要的宣傳點綴，不應使用。
列表布局
傾向於散文，因為一段話很容易被理解為普通的文字。條目中首選散文，因為它可以介紹細節和澄清背景，而簡單的列表可能無法做到。它最適合於條目，因為其目的是解釋。
{{prose}}可以用來表明一個可能更適合寫成散文的列表。許多小作品條目可以通過將不必要的列錶轉換為百科全書式的散文而得到改進。
| 散文 | 沒有內容的列表 |
|---|---|
| 紐約市二十世紀的建築包括眾多的標誌性建築，最引人注目的是摩天大樓。在本世紀的頭幾十年裡，該市成為以建築師斯坦福·懷特、卡雷爾和黑斯廷斯為代表的美學運動的中心。紐約的新摩天大樓包括熨斗大廈（1902年），第五大道在麥迪遜廣場與百老匯交叉的地方；卡斯·吉爾伯特的伍爾沃斯大樓（1913年），一個俯瞰市政廳的新哥特式「商業大教堂」；克萊斯勒大廈（1929年），純粹的裝飾風藝術；以及帝國大廈（1931）。第二次世界大戰後，現代主義建築師雷蒙德·胡德和利華大樓開始建造一系列「玻璃盒子」，改變了20世紀30年代的經典天際線，最終在世界貿易中心大廈（1973年）達到頂峰。 | 紐約市二十世紀的建築 |
使用適當的標記：使用謹慎的wiki標記或基於模板的列表代碼。特別是不要在列表中的項目之間留下空行，因為這將導致MediaWiki軟件誤認為每項項目是一個新列表的開始。(有些HTML技術可以在列表項中插入斷行或附加段落)。避免在條目中誤用列表標記來設置非列表材料的視覺樣式。
| A（良好的） | [[File:Example.jpg|thumb|Caption text]]
* Example 1
* Example 2
* Example 3
* Example 4
|
|---|---|
| B（不好的） | * Example 1
* Example 2
[[File:Example.jpg|thumb|Caption text]]
* Example 3
* Example 4
|
| C（良好的） | * Example 1
* Example 2
* [[File:Example.jpg|thumb|Caption text]] Example 3
* Example 4
|
為了將圖片浮動到列表的右邊，在大多數情況下應該將圖片標記放在第一項之前，見例子「A」。再一次將圖片標記作為單獨的一行插入到列表中（如例子「B」），會將其分成兩個半列表。
如果列表項的長度或所述圖片的主題相關性使該圖片不適合顯示在頂角，可以考慮將其放在它所示的第一個列表項的星號之後（如例子「C」），以避免破壞無序列表（<ul>）元素的連續性。
注意：當把圖片浮動到列表左側時，請使用{{flowlist}}模板，以防止破壞圓點的縮進。
默認情況下，使用帶圓點（無序）的列表，特別是對於長列表。只有在需要按編號引用項目、項目的順序很重要，或者在現實世界中存在編號的情況下（例如，專輯中的曲目），才使用編號（有序）的列表。
列表中應該有介紹性材料；對於獨立列表，這應該是序言章節。這個介紹性材料應該清楚地說明該列表的範圍。它還應該為列表的非明顯特徵提供解釋，如列表的結構。獨立的列表可以將非顯而易見的特徵放在單獨的介紹部分。
列表和它們的輔助材料必須是中立的。對主題互補的獨立列表不應包含主題的內容。介紹性材料也應應該避免自我提及維基百科。
有些信息，如「著名人物」或「校友」，可能是為了了解背景或細察內容而閱讀的，可根據大小，採用章節序言和描述性的、帶圓點的列表，或散文格式。如果名單很長，無法總結，但又不適合拆分，那麼，用一個章節序言，加上描述性的、帶圓點的列表，可能比長的散文部分更合適。
儘管列表可以用不同的方式組織，但它們必須始終是有組織的。最基本的組織形式包括按字母或數字排列，但如果項目有特定的日期，有時最好是按時間順序排列（例如，白俄羅斯總理）。當使用更複雜的組織形式時，（按來源、按用途、按類型等），分類的標準必須明確和一致。就像讀者或編輯可以很容易地假定標題A、B、C後面是D（而不是1903）一樣，更複雜的系統也應該同樣明確。如果一份國際監獄中的澳大利亞人列表包含阿根廷和柬埔寨的標題（按國家組織），那麼編輯加上非法毒品貿易的標題（按罪行組織）就不合適了。如果一個列表條目在邏輯上屬於兩個或更多的類別（例如，一個澳大利亞人因販毒而被關押在阿根廷監獄），這表明列表的分類可能存在缺陷，應該重新審查。
列表不應該包含「未分類」或「雜項」的標題，因為所有值得列入列表的項目都可按照某些標準分類，儘管完全有可能需要修改列表的格式以包括所有合適的項目。尚未分類的項目可以在確定其分類的時候列入列表的討論頁。
就其目的和範圍而言，列表和表格應儘量簡短：列表中的資料應與條目的主題相關，而不涉及不必要的細節；統計數據應按方針保持在最低限度。
有些資料可能不適合用摘要式方法來縮減或總結。一個嵌入式列表可能需要完全拆分到一個列表條目中，留下一個{{See}}模板，產生：
在某些情況下，列表格式可能比一個句子中的長序列更可取，比較：
列表，無論是獨立列表（也稱為列表條目）還是嵌入式列表，都是百科全書式的內容，就像僅有段落的條目或章節那樣。因此，列表上的所有單項必須遵循維基百科的內容方針：核心內容方針是可供查證（通過項目的一個或多個參考資料中的良好來源）、非原創研究和中立的觀點，另外還有其它內容方針。如果內容包含四種絕對需要引用的材料中的任何一種，則應在其出現的地方用內文引用註明來源。雖然列表的格式可能對每個主題的細節要求較低，但維基百科的方針和程序同樣適用於類似事物的列表，以及列表中的單個事物可能被鏈接到的任何相關條目。
在添加或編輯列表中的項目時要大膽，但也要在大膽與周到之間取得平衡，所有的內容方針都是為了幫助編輯者實現這一平衡。對於質量不確定的編輯，可以先在討論頁上討論，以獲得其它編輯的反饋。
除了對這種反饋有用之外，討論頁討論也是一個很好的審查過程，可以在添加一個困難或有爭議的項目之前達成共識，特別是那些對主題本身的定義有爭議的項目。請注意，與本節提到的其它方針和程序一樣，這個過程可以用於維基百科上任何類型的困難或有爭議的百科全書式內容。
在編輯列表本身之前在討論頁上達成共識，不僅從長遠來看可以節省時間，而且有助於確保列表上的每一項內容都有很好的參考價值，而且列表整體上代表了中立的觀點。內容出現的地方要有來源，如果包含四種絕對需要有引證的材料，要提供內文引用。
當一個項目符合可供查證方針的要求時，列表中的讀者可以檢查一個項目的參考資料，以了解該信息是否來自可靠的來源。對於信息的可供查證，也意味着維基百科不發布原創研究：它的內容是由以前在一個好的來源中發布的信息決定的，而不是其編輯的信念或經驗，甚至是編輯的解釋超出了來源的實際內容。即使你確定一個項目與列表的主題有關，你也必須在添加到列表之前找到一個良好的來源來驗證這一知識（儘管你可以在討論頁上建議），並在項目旁邊的參考資料中添加該來源。
在涉及生者的列表中，適用生者傳記的方針。
當可靠的消息來源出現分歧時，保持中立觀點的方針要求描述相互競爭的觀點，而不支持任何特定的觀點。編輯應該簡單地介紹各種消息來源的內容，根據所發表的可靠消息來源中每種觀點的突出程度來平衡報道，給予每一方應有的重視。
當添加到一個有其它條目鏈接的獨立列表時，在添加你的項目時要遵循既定的格式，然後看看你是否能將該項目鏈接到關注該項目主題的條目。如果是這樣的話，就考慮列表的格式是否允許在列表項目中容納所有競爭性觀點的細節，或者這些細節是否只應該在鏈接的、關於該主題的主要條目中涉及。無論哪種方式，如果主條目中沒有這些內容，請確保將其添加到主條目中。
你可以在包含一個可能具有獨立百科全書意義的列表的頁面底部，添加一個或多個合適的Category:列表子分類。如果有一個列表的重定向（例如，從「List of Presidents of Elbonia」到「President of Elbonia#List of Elbonian Presidents」），則將列表分類放在以「列表」命名的重定向上。
列表樣式
在維基百科上有幾種呈現列表的方式。
這是維基百科上最常見的列表類型。列表中的每項內容通常是一個簡單的單詞、短語或單行文字，不適合用數字排序，或者是極其簡短的列表，在這種情況下，一眼就能看出這些內容不是問題。它們不適合於大段的文字。簡單的帶圓點的列表是通過在一行中以*開頭，然後添加列表項目的文本，每行*有一個項目來創建的。
列表項目的格式應一致。摘要：
- 傾向於句子的情況。
- 傾向於使用完整的句子，並避免將句子和片段混合作為同一列表中的項目。
- 句子片段不使用結尾標點符號。
- 列表項目之間不要放空行。
| Wikitext | HTML | 顯示 |
|---|---|---|
== 列表名稱 ==
* 例子 1
* 例子 2
* 例子 3
|
<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
|
列表名稱
|
HTML格式化可以用來創建豐富的列表，包括有內部段落分隔的項目。在列表中使用圖像需要注意一些問題。
對於信息框來說，可以用簡單的模板將帶圓點的列錶轉換為無圓點或水平樣式，以抑制大圓點和縮進。
不要在列表後面留出空行，使列表的行數有雙重空間。這樣做會把列表分成多個列表，違背了使用列表標記的目的。這對可訪問性有不利影響（屏幕閱讀器會告訴視力受損的用戶有多個列表）[1]，並干擾機器對內容的可解析性，以便重複使用。此外，在某些網絡瀏覽器中，一個列表輸出塊和下一個列表輸出塊之間的額外空白可能會產生視覺上的干擾效果。
| Wikitext | HTML | 顯示 |
|---|---|---|
== 列表名稱 ==
* 例子 1
* 例子 2
* 例子 3
|
<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ul>
<li>例子 1</li>
</ul>
<ul>
<li>例子 2</li>
</ul>
<ul>
<li>例子 3</li>
</ul>
|
列表名稱
|
這樣做實際上會產生三個列表，每個列表包含一個項目！請注意呈現的HTML，其中的<ul>標記與<li>標記一樣多。
對於不帶圓點的多達30個項目（以後可能會增加）的列表，請使用{{Plainlist}}或{{Unbulleted list}}模板。典型的用途是在信息框字段中，以及替換用<br />分隔的偽列表。模板會發出正確的HTML標記，並使用CSS隱藏圓點。
| Wikitext | HTML | 顯示 |
|---|---|---|
== 列表名稱 ==
{{Plainlist|
* 例子 1
* Example 2
* Example 3
}}
|
<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<div class="plainlist">
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
</div>
|
列表名稱
|
== 列表名稱 ==
{{Unbulleted list
| 例子 1
| 例子 2
| 例子 3
}}
|
<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<div class="plainlist">
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
</div>
|
列表名稱
|
{{Plainlist}}的一個好處是，它可以被包裹在已經存在的帶圓點的列表中。{{Unbulleted list}}的一個特點是，對於一個短的列表，它可以放在一個單行上：{{Unbulleted list|例子 1|例子 2|例子 3}}.
只有在以下情況下才使用編號（有序）的列表：
- 有必要用編號來指代這些元素。
- 項目的順序是關鍵。
- 編號有一些獨立的意義，例如在一張專輯的音樂曲目列表中。
在一行的開頭使用#符號來生成一個編號的列表項（除了本節中詳細說明的以外，這與上面的*號列表的作用相同）。
列表項目的格式應一致。摘要：
- 傾向於句子的情況。
- 傾向於使用完整的句子，並避免將句子和片段混合作為同一列表中的項目。
- 句子片段不使用結尾標點符號。
- 列表項目之間不要放空行。
示例：
| Wikitext | HTML | 顯示 |
|---|---|---|
== 列表名稱 ==
# 例子 1
# 例子 2
# 例子 3
|
<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ol>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ol>
|
列表名稱
|
編號列表中的項目之間的空行不僅會導致與項目列表中相同的斷列問題，而且還會在「1」處重新開始編號。如果沒有複雜的標記，這一點是無法解決的（違背了編輯便利性的期望），所以在編號列表中應該始終避免使用雙行距。
HTML格式化可以用來創建豐富的列表，包括有內部段落分隔的項目。在列表中使用圖像需要注意一些問題。
有經驗的編輯可以使用原始HTML來實現更複雜的結果，如使用數字以外的索引的有序列表，以及不從1開始的有序列表。
| Wikitext | 顯示 |
|---|---|
<ol type="a">
<li>this</li>
<li>list</li>
<li>uses</li>
<li>letters</li>
<li>as</li>
<li>indexes</li>
</ol>
|
|
<ol start="10">
<li>this</li>
<li>list</li>
<li>starts</li>
<li>from</li>
<li>10</li>
</ol>
|
|
<ol type="I" start="50">
<li>this</li>
<li>list</li>
<li>uses</li>
<li>roman</li>
<li>numerals</li>
<li>and</li>
<li>starts</li>
<li>from</li>
<li>50</li>
</ol>
|
|
列表類型（type）的有效值為：
起始值可以是負數，但只有在列表使用數字作為索引的情況下。否則，會產生奇怪的結果。
| Wikitext | 顯示 |
|---|---|
<ol type="a" start="-2">
<li>definitely</li>
<li><b>not</b></li>
<li>a</li>
<li>good</li>
<li>idea!</li>
</ol>
|
|
一個描述列表包含「......術語和定義、元數據主題和值、問題和答案或任何其它的名-值數據組」。[2][3]在維基百科上，描述列表最常見的用途是用於詞彙表，在那裡它比其它樣式更受歡迎。維基百科對描述列表有專門的標記：
| 原始碼 | 效果 |
|---|---|
; 名称 1 : 值 1 ; 名称 2 : 值 2 ; 名称 3 : 值 3 |
|
來源也可以在術語後的下一行布置描述值，像這樣：
| 原始碼 | 效果 |
|---|---|
; 名称 1 : 这是与第一个名称相关的值，可能相当长，但必须是来源中一行不间断的行。 ; 名称 2 : 这是与第二个名称相关的值，也可能是长的。 |
|
這仍然使名稱和值保持在一個單一的描述列表中，而且典型的短名稱和長值的交替使獨立的組件在編輯時容易被發現。由此產生的布局和HTML與單行語法所產生的布局和HTML是相同的。
無論哪種wikitext標記都是功能有限的，而且容易被破壞。這兩種wikitext標記的一個主要弱點是，它們很容易被試圖創建多行值的後期編輯破壞。這些問題在冗長的描述列表中最為突出。因此，有一些模板用於製作描述列表，如詞彙表，其方式是提供更豐富、更複雜的內容，包括多段、塊狀引文、子列表等。
模板式結構的描述列表的基本格式是：
| 標記 | 渲染為 |
|---|---|
|
|
|
在描述列表中使用wikitext或上述模板，而不是其它捏造的格式，因為其它格式可能會讓讀者和編輯都感到意外，妨礙維基百科內容的重用性，使自動處理更加困難，並帶來可用性和可訪問性問題。(其它格式可能會占用較少的垂直空間，但會使讀者更難掃描）。也就是說，一個描述包含超過一段的項目列表可能作為獨立的列表條目中的章節呈現得更好，而表格比描述列表更適合於關聯內容，特別是當每個項目有多個值的時候。
與無序（帶圓點）和有序（編號）列表一樣，描述列表中的項目之間不應該有空行，因為這會導致每個條目在輸出中成為自己的假「列表」，從而使將項目放在列表標記中的意義消失。
當維基標記的冒號僅僅用於視覺縮進時，它們也會在HTML中被呈現為描述列表，但沒有「;」--限定的術語，而這些術語適用於「:」--縮進的材料，也沒有列表的開始和結束標記，這將產生破碎的標記（詳見WP:格式手冊/親和力#縮進）。可以使用更方便的縮進模板，例如，{{in5}}或其變體用於一行，{{block indent}}用於多行（即使討論頁上的描述列表標記的濫用已經根深蒂固，目前無法改變）。
即使描述列表術語不是標題，它們在某些方面也像標題。然而，至少在一個方面，它們不是：描述列表術語wikitext（;）不應該被用來劃分大的章節。應使用副標題（例如，===副標題===）。
表格是一種以行和列形式呈現鏈接、數據或信息的方式。它們是一種複雜的列表形式，特別是當每個列表項感興趣的信息超過2條時，它們非常有用。表格需要一個更複雜的符號，應該仔細檢查其可及性。可以考慮合併散文中所涉及的信息的摺疊表。
表格可用於呈現數學數據，如乘法表、比較數字或體育成績。它們也可用於呈現兩種或更多語言的等價詞，用於按類型和年份劃分的獎項，以及複雜的唱片譜系。
在諸如信息框的情況下，水平列表可能是有用的。示例：
{{Flatlist}}的一個好處是，它可以被包裹在一個已經存在的帶圓點的列表中。{{Hlist}}的一個特點是，對於一個簡短的列表，它可以被放在一個單行上。
對於日期事件的列表，或時間軸，每個事件使用一個{{Timeline-event}}實例，因此：
* {{Timeline-event|date={{Start date|1904|11|18|df=y}}|event=发生了一件事}}
* {{Timeline-event|date={{Start date|1905}}|event=没有发生什么事}}
* {{Timeline-event|date={{Start date|1906|01|21}}|event=发生了其它事情}}
渲染為：
- 1904年11月18日：發生了一件事
- 1905年：沒有發生什麼事
- 1906年1月21日：發生了其它事情
（注意可選的df=y（日期優先）參數--日期格式在個別條目中應該是一致的）。
按時間順序排列的列表，如時間軸，應按從早到晚的時間順序排列。
| 原始碼 | 效果 |
|---|---|
cake<br /> cheese<br /> chocolate<br /> |
cake |
這種「偽列表」方法已被廢棄，因為它不符合Web標準，並可能導致可訪問性問題。取而代之的是，使用上面定義的更多格式化的列表樣式之一。
模板文本
在一個不完整的列表前，插入{{incomplete list}}，這將把以下內容嵌入該頁：
 |
參見
- 參考目錄列表
- Wikipedia:嵌入列表
- Wikipedia:作品列表
- Wikipedia:模板消息/列表
- Help:列表
- Wikipedia:分類、列表與導航模板
- Help:Line-break handling – 除其他事項外，還包括如何正確處理水平鏈接列表中的換行問題
- Help:可排序表格 – 維基百科的表格可以用
class="sortable"排序，本頁面解釋了如何排序 - Wikipedia:List dos and don'ts – 總結本指引要點的信息頁
- Wikipedia:格式手冊/消歧義頁 – 消除歧義的頁面是同源詞的列表--一個詞或一組詞有相同的書面形式，但有不同的含義，有自己的頁面規則和布局。
- Wikipedia:獨立列表 – 關於內容和格式指引以及命名慣例的指引頁
- Wikipedia:Template index/Cleanup#Lists – 列表的清理標籤
- WikiProject:列表 – 此項目的目標是合作開發維基百科的列表條目和嵌入式列表
注釋
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
