MOS:DEFLIST

維基百科常用**列表**組織信息。列表可在散文條目的正文找到，也可以在「出版物」或「作品」部分等附錄找到，或作為獨立條目。本指引解釋了何時以及如何適當地使用列表。

列表的主題應該十分明確，通常應該通過列表的標題反映，例如「國旗列表」，如果列表的標題不能準確反映列表的內容，則應該在列表的起始段給出明確的說明，不要讓其他編輯者和讀者猜測一個列表應該包含什麼內容。

### 標題

一個獨立列表的標題就是該頁面的名稱，一個嵌入列表（作為一個段落依附在條目中的列表）的標題應該是段落的標題。列表一般應該以「列表」或者「表」為結尾，比如「國旗列表」。

### 列表的概述

一個獨立的列表是一個條目，任何條目都應該有一個概述部分，列表也不例外。即使是內容非常明顯的列表，也應該有概述，在概述中應該有對列舉主題的簡要的介紹，須說明合理的列表收錄準則，即內容的選擇標準或收錄範圍。存在爭議時，須依照可供查證的要求提供來源。[方針]如果標準複雜，則應該詳細寫明，以便讓讀者和其他編輯者明確了解該列表應該包含怎樣的主題。同時，概述部分還應該表明一些含義不明顯的符號和格式，例如「『\*』表明有爭議」等。

嵌入列表沒有概述的嚴格要求，但如果列表標準不明確時推薦在概述中加以說明。

### 內容

列表的主題內容無例外的要求滿足 Wikipedia: 中立的觀點和 Wikipedia: 可供查證原則。如果沒有參考資料支持一個主題被列入某一個列表，則將其列入該列表就是「原創研究」；如果有參考資料支持一個主題列入，而不將其列入則是非中立觀點（POV）。在編輯列表的時候應該特別注意其內容與一般條目內容的區別，以及在這種情況下維基百科各個方針指引的適用度。如果列表涉及在世人物，Wikipedia: 生者傳記方針則應該受到重視。條目名存在類似「傑出 / 著名人物」等可能模稜兩可、有失中立及原創研究等措辭時，須提供來源。

#### 獨立列表之存廢標準

列表若有「同源條目」，可先考慮「篇幅容許」的情況下，置於同源條目中而不單獨成條。「同源條目」即「XX」和「XX 列表」之關係。「篇幅容許」情況有：列表內條目本身極少；列表本身絕大多數為下級列表的連結。

列表不應僅單純地列出各項名稱，而應提供各項名稱簡介或各項之間可比較的信息等其他資訊，即該列表不應該可簡單的由分類取代。而未改善的單純列出各項名稱的列表應經存廢討論刪除或改為分類。不應以列表包含紅鏈作為列表不可由分類取代的原因；是否提供各項名稱簡介或各項之間可比較的信息等其他資訊，應為區別列表與分類的唯一標準。

### 分類

每一個列表都應該被分類於包含列表的頁面分類中，其根目錄是 Category: 列表。

就以國家、政治實體、國籍、出生地或籍貫來劃分的人物列表來說，有以下規限：

* 中文維基百科容許建立 × 國人列表，但是僅限於索引形式，例如這樣。因此，必須要有至少 5 篇下級列表才可以以 × 國人列表作為索引，否則不予創建。
* 如果人物列表的收錄範圍可以預期將會或已經超過 100 人的話，應該再作細分至下下級列表，直至不超越 100 人為止。
* 國籍、出生地或籍貫無可靠來源證實的人物不予收錄。
* 每篇列表在創建時至少需要有 50 人，否則刪除。

對於條目內人物嵌入列表，其存廢標準可較獨立列表更為寬鬆一些，具體情況可自行考量，如遇爭議可到 Wikipedia: 互助客棧 / 方針尋求共識。以下羅列已達成共識的部分主題：

1. 姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:× 姓」或獨立列表體現。
2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表，此類信息應由「分類:×× 人」或獨立列表體現。
3. 疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:× 疾病患者」或獨立列表體現。

維基百科區分了主要由列表組成的條目（一般稱為「列表」或「獨立列表」）和主要由散文組成的條目（稱為「條目」）。條目旨在主要由散文組成，儘管它們可能包含一些列表。

### 獨立的列表條目

_列表條目_是百科全書式的頁面，由一個序言部分和一個列表組成（可以用標題劃分，也可以不用）。這些列表上的項目包括與某一特定主題領域的條目的連結，並可能包括有關所列項目的額外信息。獨立列表的標題通常以條目的主題開始，然後是列表的類型（列表、索引等），例如，植物油列表。它們可以按主題分類或按主題以平面或分層結構進行組織。

標題和符號的格式，或垂直格式，是獨立列表的常見格式。這些維基百科條目遵循 Wikipedia: 獨立列表的格式指引。

### 嵌入式列表

_嵌入式列表_是在條目中使用的列表，補充條目的散文內容。它們包含或附加在正文中，並可能是表格格式。維基百科使用幾個標準的附錄，通常是以列表的形式，以及導航模板。

只有在適當的時候才可以使用嵌入式列表；有時，列表中的信息最好以散文形式呈現。以列表形式呈現過多的統計數據可能違反方針。

#### 「子項」（即縮進）

當列表中的項目是其前面段落的「子項」時，使用列表格式可能是合適的。這種「子項」在邏輯上有資格縮進到其父項的描述之下。在這種情況下，以列表形式縮進段落可能會使它們更容易閱讀，特別是在段落很短的情況下。下面的例子在有和沒有圓點的情況下都適用：

#### 作品列表和時間軸

個人或團體的作品列表，如書目、唱片、電影、專輯人員和曲目列表，通常以簡單的列表格式呈現，儘管預計這些信息將通過對要點的散文分析在條目的其它地方得到支持，如果列表變得難以處理，則按照 WP: 摘要格式將其拆分為獨立的列表。時間線和年表可以作為現實世界歷史的散文描述的有益補充。列表的內容受與散文相同的內容方針的約束，包括應有的比重和避免原創研究的原則。根據維基百科的方針和指引（包括 WP:TRIVIA 部分），確保列表項目對主題的重要性與該項目在條目正文中的要求相同。考慮一下散文是否更合適。關於時間線的具體建議在 Wikipedia: 年表標準中給出。

#### 相關條目（導航列表）

 **「參見」列表**和 **「相關條目」列表**是寶貴的導航工具，可以幫助用戶找到相關的維基百科條目。當決定在任何給定的條目中添加哪些條目和條目列表時，試著把自己放在讀者的頭腦中是很有用的。問問自己，讀者在讀完這篇條目後可能想去哪裡。一般來說，這將包括三種類型的連結：

* 相關主題的連結 - 與條目中討論的主題類似。
* 高階（即，更大體的）條目和列表 -- 這可能包括人的列表、主權國家列表，等等。例如，印度語詩人列表應該同時連結到印度人列表和詩人列表。
* 低階（即更具體）的條目和列表 -- 例如，企業頁面導航列表包含小企業的連結，會計主題列表等。

對於在任何條目中應該放多少個條目連結和列表連結，存在一些爭議。有些人把「條目連結」（放在「參見」部分）和「列表連結」（放在「相關主題」部分）分開，但這是沒有必要的，除非有太多的連結需要單獨放在一個部分。有些人認為，在任何一篇文章的結尾，應該包括的列表連結的最佳數量是 0、1 或 2。另一些人則認為，一套更全面的列表會很有用。一般來說，在決定包括什麼列表時，應該使用決定在「**參見**」部分包括什麼條目的相同標準。編輯應該試著把自己放在讀者的心態上，問「讀完這篇條目後我可能想去哪裡？」。一般來說，「參見」部分**不**應重複出現在條目正文中的連結。

#### 參考資料和外部連結

**參考資料列表**展示了維基百科之外的信息來源。兩種最常見的類型是：

* 「網絡超連結」 - 在「外部連結」標題下的維基百科以外的網址連結列表
* 「參考文獻」 - 在「參考資料」標題下的學術期刊文章或書籍列表

維基百科不是一個連結集，積極不鼓勵只有外部連結的條目，但從網際網路上引用更詳細的資料是合適的。當你把一個網站作為重要的信息來源時，情況更是如此。

### 列表的特殊名稱

維基百科上的大多數列表是項目列表，但不是全部。專門的列表類型包括：

* **大綱** - 維基百科的大綱是一個分層排列的屬於某一特定主題的主題列表。大綱是維基百科上兩種類型的一般主題列表之一，另一種是索引。
* **索引** - 維基百科上的索引是一個按字母順序排列的關於某一特定主題的文章列表。
* **時間軸** - 時間軸是按時間順序排列的事件的圖形表示。
* **作戰序列** - 武裝力量組成部分的代表，顯示了層級組織和指揮結構。
* **作品列表**包括書目和唱片目錄。書目是一個主題領域的相關參考文獻列表，包括書籍、期刊文章和網絡文章；唱片目錄是一個音樂家或歌手的所有唱片的列表，也可以根據流派或唱片公司來編制。
* **詞彙表** - 詞彙表是一個特定主題領域的術語列表，其中包括定義。
* **同類索引條目** - 記錄一組共享相同（或相似）名稱的項目。它們與消除歧義的頁面不同，因為它們是完整的條目，旨在記錄多個主題，而消除歧義的頁面僅用於導航目的。並非所有的同類索引條目都是列表。
* **動態列表** - 動態列表是任何隨著其涵蓋的主題變化而變化的列表。因此，它可能永遠不會被完成。任何類型的列表都可能是動態的。

列表有以下幾個用途：

### 提供資訊

列表可能是一個有價值的資料來源。對於結構化的列表來說，情況更是如此。這方面的例子包括按時間順序排列的列表，按主題分組的列表，或有注釋的列。

### 導航

包含內部連結術語（即維基連結）的列表總的來說可以作為維基百科的自然內容表和索引。如果用戶對他們要找的東西有一些大致的概念，但不知道具體的術語，他們可以瀏覽基本主題的列表和更全面的主題列表，這些列表反過來會通向維基百科的大部分（如果不是全部）列表，進而通向相關條目。沒有具體研究目標的用戶可能也會發現條目中的「參見」部分所列出的條目很有用。入口站點中也提供了列表，以幫助瀏覽他們的主題，而且列表通常通過使用系列框和其它導航模板放在條目中。

有特定研究目標（用一兩個詞描述）的用戶可能會發現維基百科的搜索框很有用。

### 發展

一些列表對維基百科的發展是很有用的。**相關主題列表**可以說明維基百科的狀況、已寫的條目和尚未寫的條目。然而，由於維基百科是為讀者而非編輯而優化的，任何主要為開發或維護目的而存在的列表（例如，一個完全由紅色連結組成的列表，並不具有信息目的；特別是一個缺失主題的列表）應該放在項目（「Wikipedia:」）或用戶（「User:」）命名空間，而不是主命名空間中。

### 列表和分類

列表和分類的冗餘是有益的，因為這兩種格式可以一起工作；這一原則在準則 _Wikipedia: 分類、列表與導航模板_中有所涉及。像分類一樣，列表可以使用鏈出更改功能來跟蹤所列頁面中的更改。與分類不同的是，列表還允許保留其內容的歷史；列表還允許在一個頁面上出現大量的條目。

對於一個獨立的列表，列表的標題是頁面名稱。對於嵌入式列表，列表的標題通常是一個章節的標題（例如，超人前傳 (第一季)# 各集列表），但它可以更短。列表的標題不應具有誤導性，通常不應包括縮寫詞。此外，過於精確的列表標題可能不那麼有用，而且會使列表難以找到；列表的精確收錄標準應該在標題部分（見下文）闡明，而不是在標題中闡明。例如，像「完整」和「顯著」這樣的詞通常不會出現在列表標題中。相反，標題應明確說明該名單是否完整，或者是否僅限於廣為人知或著名的成員（即那些值得發表的條目）。請注意，「著名」一詞被認為是一種不必要的宣傳點綴，不應使用。

### 在易於理解的地方使用散文

傾向於散文，因為一段話很容易被理解為普通的文字。條目中首選散文，因為它可以介紹細節和澄清背景，而簡單的列表可能無法做到。它最適合於條目，因為其目的是解釋。

{{prose}} 可以用來表明一個可能更適合寫成散文的列表。許多小作品條目可以通過將不必要的列錶轉換為百科全書式的散文而得到改進。參見：WP: 格式手冊 / 瑣碎章節。

### 使用良好的標記

**使用適當的標記**：使用謹慎的 wiki 標記或基於模板的列表代碼（見 Help: 列表的許多建議）。特別是不要在列表中的項目之間留下空行，因為這將導致 MediaWiki 軟體誤認為每項項目是一個新列表的開始。(有些 HTML 技術可以在列表項中插入斷行或附加段落)。避免在條目中誤用列表標記來設置非列表材料的視覺樣式。

#### 圖片和列表

為了將圖片浮動到列表的右邊，在大多數情況下應該將圖片標記放在第一項之前，見例子「A」。再一次將圖片標記作為單獨的一行插入到列表中（如例子「B」），會將其分成兩個半列表。

如果列表項的長度或所述圖片的主題相關性使該圖片不適合顯示在頂角，可以考慮將其放在它所示的第一個列表項的星號之後（如例子「C」），以避免破壞無序列表（`<ul>`）元素的連續性。

**注意**：當把圖片浮動到列表左側時，請使用 {{flowlist}} 模板，以防止破壞圓點的縮進。

### 默認使用無序列表

**默認情況下，使用帶圓點（無序）的列表**，特別是對於長列表。只有在需要按編號引用項目、項目的順序很重要，或者在現實世界中存在編號的情況下（例如，專輯中的曲目），才使用編號（有序）的列表。

### 介紹性材料

列表中應該有介紹性材料；對於獨立列表，這應該是序言章節。這個介紹性材料應該清楚地說明該列表的範圍。它還應該為列表的非明顯特徵提供解釋，如列表的結構。獨立的列表可以將非顯而易見的特徵放在單獨的介紹部分。

列表和它們的輔助材料必須是中立的。對主題互補的獨立列表不應包含主題的內容。介紹性材料也應應該避免自我提及維基百科。

有些信息，如「著名人物」或「校友」，可能是為了了解背景或細察內容而閱讀的，可根據大小，採用章節序言和描述性的、帶圓點的列表，或散文格式。如果名單很長，無法總結，但又不適合拆分，那麼，用一個章節序言，加上描述性的、帶圓點的列表，可能比長的散文部分更合適。

### 組織結構

儘管列表可以用不同的方式組織，但它們必須始終是有組織的。最基本的組織形式包括按字母或數字排列，但如果項目有特定的日期，有時最好是按時間順序排列（例如，白俄羅斯總理）。當使用更複雜的組織形式時，（按來源、按用途、按類型等），分類的標準必須明確和一致。就像讀者或編輯可以很容易地假定標題 **A**、**B**、**C** 後面是 **D**（而不是 **1903**）一樣，更複雜的系統也應該同樣明確。如果一份國際監獄中的澳大利亞人列表包含**阿根廷**和**柬埔寨**的標題（按國家組織），那麼編輯加上**非法毒品貿易**的標題（按罪行組織）就不合適了。如果一個列表條目在邏輯上屬於兩個或更多的類別（例如，一個澳大利亞人因販毒而被關押在阿根廷監獄），這表明列表的分類可能存在缺陷，應該重新審查。

列表不應該包含「未分類」或「雜項」的標題，因為所有值得列入列表的項目都可按照某些標準分類，儘管完全有可能需要修改列表的格式以包括所有合適的項目。尚未分類的項目可以在確定其分類的時候列入列表的討論頁。

### 列表尺寸

就其目的和範圍而言，列表和表格應儘量簡短：列表中的資料應與條目的主題相關，而不涉及不必要的細節；統計數據應按方針保持在最低限度。

有些資料可能不適合用摘要式方法來縮減或總結。一個嵌入式列表可能需要完全拆分到一個列表條目中，留下一個 {{See}} 模板，產生：

在某些情況下，列表格式可能比一個句子中的長序列更可取，比較：

### 向列表中添加單個項目

列表，無論是獨立列表（也稱為列表條目）還是嵌入式列表，都是百科全書式的內容，就像僅有段落的條目或章節那樣。因此，列表上的所有單項必須遵循維基百科的內容方針：核心內容方針是可供查證（通過項目的一個或多個參考資料中的良好來源）、非原創研究和中立的觀點，另外還有其它內容方針。如果內容包含四種絕對需要引用的材料中的任何一種，則應在其出現的地方用內文引用註明來源。雖然列表的格式可能對每個主題的細節要求較低，但維基百科的方針和程序同樣適用於類似事物的列表，以及列表中的單個事物可能被連結到的任何相關條目。

 

在添加或編輯列表中的項目時要大膽，但也要在大膽與周到之間取得平衡，所有的內容方針都是為了幫助編輯者實現這一平衡。對於質量不確定的編輯，可以先在討論頁上討論，以獲得其它編輯的反饋。

除了對這種反饋有用之外，討論頁討論也是一個很好的審查過程，可以在添加一個困難或有爭議的項目之前達成共識，特別是那些對主題本身的定義有爭議的項目。請注意，與本節提到的其它方針和程序一樣，這個過程可以用於維基百科上任何類型的困難或有爭議的百科全書式內容。

在編輯列表本身之前在討論頁上達成共識，不僅從長遠來看可以節省時間，而且有助於確保列表上的每一項內容都有很好的參考價值，而且列表整體上代表了中立的觀點。內容出現的地方要有來源，如果包含四種絕對需要有引證的材料，要提供內文引用。

當一個項目符合可供查證方針的要求時，列表中的讀者可以檢查一個項目的參考資料，以了解該信息是否來自可靠的來源。對於信息的可供查證，也意味著維基百科不發布原創研究：它的內容是由以前在一個好的來源中發布的信息決定的，而不是其編輯的信念或經驗，甚至是編輯的解釋超出了來源的實際內容。即使你確定一個項目與列表的主題有關，你也必須在添加到列表之前找到一個良好的來源來驗證這一知識（儘管你可以在討論頁上建議），並在項目旁邊的參考資料中添加該來源。

在涉及生者的列表中，適用生者傳記的方針。

當可靠的消息來源出現分歧時，保持中立觀點的方針要求描述相互競爭的觀點，而不支持任何特定的觀點。編輯應該簡單地介紹各種消息來源的內容，根據所發表的可靠消息來源中每種觀點的突出程度來平衡報導，給予每一方應有的重視。

當添加到一個有其它條目連結的獨立列表時，在添加你的項目時要遵循既定的格式，然後看看你是否能將該項目連結到關注該項目主題的條目。如果是這樣的話，就考慮列表的格式是否允許在列表項目中容納所有競爭性觀點的細節，或者這些細節是否只應該在連結的、關於該主題的主要條目中涉及。無論哪種方式，如果主條目中沒有這些內容，請確保將其添加到主條目中。

### 分類

你可以在包含一個可能具有獨立百科全書意義的列表的頁面底部，添加一個或多個合適的 Category: 列表子分類。如果有一個列表的重定向（例如，從「List of Presidents of Elbonia」到「President of Elbonia#List of Elbonian Presidents」），則將列表分類放在以「列表」命名的重定向上。

在維基百科上有幾種呈現列表的方式。

### 帶圓點的列表

這是維基百科上最常見的列表類型。列表中的每項內容通常是一個簡單的單詞、短語或單行文字，不適合用數字排序，或者是極其簡短的列表，在這種情況下，一眼就能看出這些內容不是問題。它們不適合於大段的文字。簡單的帶圓點的列表是通過在一行中以 `*` 開頭，然後添加列表項目的文本，每行 `*` 有一個項目來創建的。

列表項目的格式應一致。摘要：

* 傾向於句子的情況。
* 傾向於使用完整的句子，並避免將句子和片段混合作為同一列表中的項目。
* 句子片段不使用結尾標點符號。
* 列表項目之間不要放空行。

HTML 格式化可以用來創建豐富的列表，包括有內部段落分隔的項目。在列表中使用圖像需要注意一些問題。

對於信息框來說，可以用簡單的模板將帶圓點的列錶轉換為無圓點或水平樣式，以抑制大圓點和縮進。

**不要在列表後面留出空行**，使列表的行數有雙重空間。這樣做會把列表分成多個列表，違背了使用列表標記的目的。這對可訪問性有不利影響（屏幕閱讀器會告訴視力受損的用戶有多個列表），並干擾機器對內容的可解析性，以便重複使用。此外，在某些網絡瀏覽器中，一個列表輸出塊和下一個列表輸出塊之間的額外空白可能會產生視覺上的干擾效果。

這樣做實際上會產生三個列表，每個列表包含一個項目！請注意呈現的 HTML，其中的 `<ul>` 標記與 `<li>` 標記一樣多。

### 無圓點的列表

對於不帶圓點的多達 30 個項目（以後可能會增加）的列表，請使用 {{Plainlist}} 或 {{Unbulleted list}} 模板。典型的用途是在信息框欄位中，以及替換用 `<br />` 分隔的偽列表。模板會發出正確的 HTML 標記，並使用 CSS（見 Template:Plainlist § Notes）隱藏圓點。

{{Plainlist}} 的一個好處是，它可以被包裹在已經存在的帶圓點的列表中。{{Unbulleted list}} 的一個特點是，對於一個短的列表，它可以放在一個單行上：`{{Unbulleted list|例子 1|例子 2|例子 3}}`.

### 編號列表

只有在以下情況下才使用編號（有序）的列表：

* 有必要用編號來指代這些元素。
* 項目的順序是關鍵。
* 編號有一些獨立的意義，例如在一張專輯的音樂曲目列表中。

在一行的開頭使用 `#` 符號來生成一個編號的列表項（除了本節中詳細說明的以外，這與上面的 `*` 號列表的作用相同）。

列表項目的格式應一致。摘要：

* 傾向於句子的情況。
* 傾向於使用完整的句子，並避免將句子和片段混合作為同一列表中的項目。
* 句子片段不使用結尾標點符號。
* 列表項目之間不要放空行。

**示例：**

編號列表中的項目之間的空行不僅會導致與項目列表中相同的斷列問題，而且還會在「1」處重新開始編號。如果沒有複雜的標記，這一點是無法解決的（違背了編輯便利性的期望），所以在編號列表中應該始終避免使用雙行距。

HTML 格式化可以用來創建豐富的列表，包括有內部段落分隔的項目。在列表中使用圖像需要注意一些問題。

#### 其它案例

有經驗的編輯可以使用原始 HTML 來實現更複雜的結果，如使用數字以外的索引的有序列表，以及不從 1 開始的有序列表。

列表類型（type）的有效值為：

* 1（默認，數字）
* a（小寫拉丁字母）
* A（大寫拉丁字母）
* i（小寫羅馬數字）
* I（大寫羅馬數字）

起始值可以是負數，但只有在列表使用數字作為索引的情況下。否則，會產生奇怪的結果。

### 描述（定義、關聯）列表

一個描述列表包含「...... 術語和定義、元數據主題和值、問題和答案或任何其它的名 - 值數據組」。在維基百科上，描述列表最常見的用途是用於詞彙表，在那裡它比其它樣式更受歡迎。維基百科對描述列表有專門的標記：

來源也可以在術語後的下一行布置描述值，像這樣：

這仍然使名稱和值保持在一個單一的描述列表中，而且典型的短名稱和長值的交替使獨立的組件在編輯時容易被發現。由此產生的布局和 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 日 (1904-11-18)：發生了一件事
* 1905 年 (1905)：沒有發生什麼事
* 1906 年 1 月 21 日 (1906-01-21)：發生了其它事情

（注意可選的 `df=y`（日期優先）參數 -- 日期格式在個別條目中應該是一致的）。

按時間順序排列的列表，如時間軸，應按從早到晚的時間順序排列。

### 換行

這種「偽列表」方法已被廢棄，因為它不符合 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: 列表 – 此項目的目標是合作開發維基百科的列表條目和嵌入式列表