Template talk:Reflist
添加话题S8321414在话题“編輯請求 2026-10-28”中的最新留言：12天前
我從英文維基將他們的 {{reflist}} 翻譯過來成為 {{reflist2}}，加入了以 CSS3 為基礎的多欄位注釋功能，並已經測試成功。希望管理員將該模板搬移至此，感謝。--GIANTtalk 2007年7月22日 (日) 17:37 (UTC)
“组合注释”里不能使用name属性添加多条注释的
[编辑]我在编辑阿兰·李 (插画家)词条的时候发现，Reflist添加了group属性以后，是不能再使用name属性添加多条注释的，否则会有语法错误；但像Footnotes: groups一样添加多个不指定name属性的注释条目则是正常的。BnW.h（留言） 2013年8月11日 (日) 15:23 (UTC)
參考資料的列數
[编辑]參考資料使用{{Reflist}}已經是常規做法。最近看到不少條目使用了三列（例如[1]），甚至有四列的Reflist，我認為太擠，不易查閱。兩列的最舒服，比一列更省空間，且不擠。我建議規定只用一或兩列的Reflist，禁用更多列數。大家怎麼看？鋼琴小子 打個招呼 查看貢獻 2014年4月6日 (日) 06:43 (UTC)
- 我不认为有需要硬性规定。——路过围观的Sakamotosan 2014年4月6日 (日) 07:31 (UTC)
- 如果ref比较多，我傾向
{{Reflist|colwidth=30em}}的方式，屏幕有1920*1080的，也有1366*768的。--铁铁的火大了 2014年4月6日 (日) 10:59 (UTC)- @Wangxuan8331800：我在世界地理分区列表 (联合国)用了您的方法，貌似没什么变化呢？——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★贡献 2014年4月6日 (日) 12:42 (UTC)
- 測試後發現應該是因為30em太寬了！對於一般寬度設定低於1000px的視窗而言跟不分列根本沒差。做了幾次測試後我覺得對於自己的視窗設定習慣而言20～25em似乎是個比較中庸的寬度（參考文獻的敘述不會被切斷到太多段而影響閱讀，但又具有利用換行縮短佔用版面的效果），但不知道大家的習慣如何？我使用的是1920x1080的螢幕解析度設定，但平常開啟Chrome視窗時只會拉2/3螢幕的寬度，所以版面寬度應該是介於900～1200px之間。--泅水大象™ 訐譙☎ 2014年4月7日 (一) 07:13 (UTC)
- 實際上是有效果的，要把視窗拉得非常寬才有作用（超過1000px左右），所以才說30em應該是太寬了。--泅水大象™ 訐譙☎ 2014年4月7日 (一) 15:58 (UTC)
- @Wangxuan8331800：我在世界地理分区列表 (联合国)用了您的方法，貌似没什么变化呢？——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★贡献 2014年4月6日 (日) 12:42 (UTC)
- 在我而言無必要分欄，通通都用一欄便好，省去空白反而不舒服，很有壓迫感；再者，分欄對於排版造成了更多顧慮，例如要避免右側圖片或右側模板掉進註腳顯示區。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月8日 (二) 10:49 (UTC)
- 不過適當的分欄可以縮減參考文獻區的篇幅面積，這對於註記數量非常多的大型條目是有幫助的。右邊的圖片或模板掉進註釋區段內會產生啥問題嗎？就我看到的畫面上來說分欄的功能與圖片顯示等都很正常呀。--泅水大象™ 訐譙☎ 2014年4月8日 (二) 18:30 (UTC)
- 有兩個關鍵點得指出：
- 1. 好像很少見到文章只有一段但這麼多註釋/參考文獻的條目吧？如果真的存在，表示那些參考條目裡面一定有很多是魚目混珠或是濫竽充數，可以進一步的篩選掉一些必要性低的註釋以確保圖文比正常。
- 2. 如果用上面提及、固定換行寬度的設法（例如寬度設成20em）就不會有這困擾了。版面寬度不足時就會變成單欄配置，可以確保不會換行換太頻繁。--泅水大象™ 訐譙☎ 2014年4月9日 (三) 06:52 (UTC)
- 第一點正正就是我所說的「顧慮」，而且也請另外假設這是很長的條目，萬一那圖片正正就是要放在正文最後一段才有意義、放到其他地方或者不放又會可惜的時候（比如：解說圖），這還得另外想辦法。而且還有要放到附錄最後一章的右側姊妹模板（如{{commonscat}}），碰巧最底相關條目、外部連結等等通通都沒有，獨獨祇有參考資料的時候，那祇得放到參考資料，到時也是出問題。
- 第二點根本沒有真正解決問題，即使以colwidth自動設定單欄，稍長的項目還是會未用完空白就換行，反而甚麼都不設定的單欄不會產生如斯問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 07:19 (UTC)
- 所以只要在遇到你說的那些特例狀況時再取消分欄設定就好，但一般情況來說分欄還是可以大幅度的減少參考文獻/註釋區段佔用的版面長度。為了偶爾才出現的特例而放棄平常大部分的狀況下都有幫助的配置方式，感覺有點因噎廢食，不是嗎？--泅水大象™ 訐譙☎ 2014年4月9日 (三) 09:17 (UTC)
- 根本看不出「縮減版面長度」和這種所謂的「省位」有何幫助，本來就很沒實質作用，何來因噎廢食？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 09:28 (UTC)
- 所以只要在遇到你說的那些特例狀況時再取消分欄設定就好，但一般情況來說分欄還是可以大幅度的減少參考文獻/註釋區段佔用的版面長度。為了偶爾才出現的特例而放棄平常大部分的狀況下都有幫助的配置方式，感覺有點因噎廢食，不是嗎？--泅水大象™ 訐譙☎ 2014年4月9日 (三) 09:17 (UTC)
- 怎會沒實質作用？下面的兩種版面雖然只是個範例與實際的參考文獻模版換行方式不同，但跟參考文獻版面採單欄與雙欄配置的狀況有點像，很顯然，Case.2的頁面長度只有Case.1的一半。或許對於一般註釋數量有限的條目來說差異不大，但這對註釋數量極多的條目中會有關鍵性的幫助。--泅水大象™ 訐譙☎ 2014年4月9日 (三) 10:51 (UTC)
Case.1 單欄排版
- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
- BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
- CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
- DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
- EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
- FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
- GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
- HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
- IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
- JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
- KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
- LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
- MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
- NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
- OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
- PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
- QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ
- RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
- SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
- TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
- UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
- VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
- WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Case.2 雙欄排版
- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
- BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
- CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
- DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
- EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
- FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
- GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
- HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
- IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
- JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
- KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
- LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
- MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
- NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
- OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
- PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
- QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ
- RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
- SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
- TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
- UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
- VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
- WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
- 短一半也不覺得特別有幫助，一樣也是由A看到Z，我不覺得這樣的兩欄比起一欄更容易看這個列表，而且一眼看去還會產生第一欄和第二欄是兩種不同類的錯覺。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 11:17 (UTC)
- 很少人會直接去一條一條閱讀註釋欄的，大部分的讀者主要都還是利用游標靠近主文中的標示數字時，浮動視窗內顯示的文字。但是，註釋區域的篇幅太長時更下方的外部連結、模板與分類標籤就很不容易查閱，所以才會說適度的縮短篇幅是有幫助的。
- 其實我們在這兒也沒必要爭執這麼多，街燈電箱君覺得分欄無用，我覺得有時有幫助，這是我們各自的審美與閱讀習慣不同而已並無對錯問題，主要還是要看到底大部分的用戶習慣哪種排版方式才對。但可以確定的是，強制設定成三、四欄那種排法是絕對不恰當的。--泅水大象™ 訐譙☎ 2014年4月9日 (三) 13:12 (UTC)
- 沒別的，也都祇是個人對分欄的感覺，心裏總是覺得不但祇很壓迫，分開兩欄還常常在第一下以為兩邊的注項有不同性質。回到正題，參考資料裏單一個項目本身就已經不少字，故單欄本身已經沒許多空白留下來，所以就算有很多注項其實用了兩欄也省不了許多空間，加上還會有技術問題的顧慮，所以我完全不建議兩欄。講到三欄，既然我連兩欄都不建議，當然三、四欄也更不。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 13:30 (UTC)
- 你忘記比較常見的狀況其實是內容的文字正好超過一行的上限而換行，但字數又不夠多到填滿兩行的情形啦！這種情況往往才是分兩欄時可以大幅度減少空白的情況。很巧的是一般如果用cite web模板時，在約1000px視窗寬度（也就是1920px的Full HD螢幕上正好一個畫面可以並排兩個視窗的狀態，是很常見的閱讀版面）狀態下，註釋長度經常會正好落在單欄狀態下的1.2至1.5行之間，所以分兩欄之後註釋版面大都會縮減不少但又不致於造成換行太頻繁影響閱讀的情況，所以才會說是比較推薦的折衷點。--泅水大象™ 訐譙☎ 2014年4月9日 (三) 14:05 (UTC)
- 其實關鍵在於「減少空白」究竟對於翻查參考資料後面的東西是否真的很有幫助？在我而言「不是」，因為無論縮短和不縮短，翻查的時候我一樣都是直接捲到底部，縮短也根本沒方便過我瀏覽。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 14:29 (UTC)
- 對於上面靠右圖片侵入參考範圍，許多條目的做法都是使用{{Clear}}模板重置排版。個人審美觀感上的差異是很難一字一句得到妥協的。對於這種問題，可能投票是最可行的方案。參見en:H:REFCOLS，參考列表寬度是沒有硬性規定的，一般要看參考格式：數量屈指可數的，應用1列；數量較多的，應用2列；使用短參考格式的（例如[2]），應用多列，直到空間基本填滿而不換行。個人來說，如果我見到使用3、4列，而每一項需多次換行的情況，就會改為2列。在參考多的情況下，不使用1列是因為眼睛在看一行橫跨螢幕的細行資訊的時候，很容易看偏。鋼琴小子 打個招呼 查看貢獻 2014年4月9日 (三) 19:43 (UTC)
- 其實關鍵在於「減少空白」究竟對於翻查參考資料後面的東西是否真的很有幫助？在我而言「不是」，因為無論縮短和不縮短，翻查的時候我一樣都是直接捲到底部，縮短也根本沒方便過我瀏覽。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 14:29 (UTC)
- 你忘記比較常見的狀況其實是內容的文字正好超過一行的上限而換行，但字數又不夠多到填滿兩行的情形啦！這種情況往往才是分兩欄時可以大幅度減少空白的情況。很巧的是一般如果用cite web模板時，在約1000px視窗寬度（也就是1920px的Full HD螢幕上正好一個畫面可以並排兩個視窗的狀態，是很常見的閱讀版面）狀態下，註釋長度經常會正好落在單欄狀態下的1.2至1.5行之間，所以分兩欄之後註釋版面大都會縮減不少但又不致於造成換行太頻繁影響閱讀的情況，所以才會說是比較推薦的折衷點。--泅水大象™ 訐譙☎ 2014年4月9日 (三) 14:05 (UTC)
- 沒別的，也都祇是個人對分欄的感覺，心裏總是覺得不但祇很壓迫，分開兩欄還常常在第一下以為兩邊的注項有不同性質。回到正題，參考資料裏單一個項目本身就已經不少字，故單欄本身已經沒許多空白留下來，所以就算有很多注項其實用了兩欄也省不了許多空間，加上還會有技術問題的顧慮，所以我完全不建議兩欄。講到三欄，既然我連兩欄都不建議，當然三、四欄也更不。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年4月9日 (三) 13:30 (UTC)
编辑请求：加入「autocol」参数
[编辑]
请求已拒绝修改最后对于 #tag:references 的调用，加入最新「响应式分栏」模式的开关，供编者试用：
{{#tag:references|{{{refs|}}}|group={{{group|}}}|responsive={{#ifeq:{{{autocol|}}}|1||0}}}}
上述例子使用的默认值为「禁用」。TemplateData的数据类型为「Boolean」（0/1/空，不是yes/no我也很无奈），标签为「自动调整分栏」。
--Artoria2e5编 保持讨论完整，直接{{ping}}我回复。 2017年3月14日 (二) 05:16 (UTC)
- 我在现在沙盒弄了用参数1等于auto时的写法，不过现在加responsive的话，会提示“请使用带group的{{reflist}}”，估计属性识别有问题，添加多余属性会出警告。——路过围观的Sakamotosan 2017年3月14日 (二) 05:58 (UTC)
- @Cwek：干脆等软件真部署下来了再看吧。没事干去看看Special:Version什么的？——Artoria2e5编 保持讨论完整，直接{{ping}}我回复。 2017年3月14日 (二) 20:18 (UTC)
编辑请求：修改允许接受的liststyle列表
[编辑]目前reflist在liststyle做了一定“防呆”处理，只允许接纳少数几种list-style-type，完全杜绝了使用汉字编号（cjk-ideographic）、天干（cjk-heavenly-stem）地支（cjk-earthly-branch）（参见前一个链接）等有趣玩法的可能性。希望管理员根据我给出的MDN链接，给那个#switch多增加点选项。或者直接摘掉防呆选项，改成不认识的时候加个跟踪分类我也没意见。 --Artoria2e5编 保持讨论完整，直接{{ping}}我回复。 2017年3月15日 (三) 03:26 (UTC)
- ref都沒有[一][二][三]、[甲][乙][丙]、[子][丑][寅]的註釋效果，那{{reflist}}加這些選項有什麼用？--113.52.80.16（留言） 2017年3月15日 (三) 14:07 (UTC)
编辑请求，在自动分栏部署后的修订
[编辑] 请求已拒绝使用参数1控制分栏行为，增加值“auto”来使用系统提供的自动分栏。
- 如果启用设定为默认不自动分栏的话，使用oldid=43630361替换
- 如果启用设定为默认自动分栏的话，使用oldid=43630359替换（由于现在功能未部署，会有提示错误，部署后会正常）
--路过围观的Sakamotosan 2017年3月15日 (三) 12:08 (UTC)
- 两个ifeq语法都有误，且未考虑手动启用colwidth的情况。请基于mw:Special:PermanentLink/2420815修改。（提供的版本默认为不启用，需要启用的话把最后一个ifeq里面的{{{1|}}}改成{{{1|auto}}}。）——Artoria2e5编 保持讨论完整，直接{{ping}}我回复。 2017年3月15日 (三) 17:23 (UTC)
- 已fixup，并且已考虑colwidth的情况。——路过围观的Sakamotosan 2017年3月16日 (四) 01:40 (UTC)
编辑请求：为固定列数设计增加追踪模板
[编辑] 请求已拒绝固定列数设计适应各种宽度视窗的能力较差，一般不应是优先选择。提议在模板末尾增加{{#iferror: {{#ifexpr: {{{1|}}} > 1 }}||[[Category:固定reflist列数的页面]]}}的跟踪分类设定，当{{{1}}}为手动定义的数字时增加分类。（不考虑默认一列的情况。）
--Artoria2e5编 保持讨论完整，直接{{ping}}我回复。 2017年3月15日 (三) 17:32 (UTC)
- @Artoria2e5：那這個分類有什麼用處？--A2093064#Talk 2017年8月4日 (五) 06:27 (UTC)
- @A2093064：追踪模板的目的就是列出来一个个杀掉。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月4日 (五) 21:30 (UTC)
- @Artoria2e5：這樣可以嗎？--A2093064#Talk 2017年8月5日 (六) 00:15 (UTC)
- @A2093064：追踪模板的目的就是列出来一个个杀掉。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月4日 (五) 21:30 (UTC)
- 不建议，没必要去追踪。只是申请者自己的一厢情愿而已。——路过围观的Sakamotosan 2017年8月5日 (六) 04:49 (UTC)
- 不用 fixed-col 是上面传下来的原则。n=1 只是特例而已。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月5日 (六) 05:10 (UTC)
- 上面？而且对于使用数栏分裂的话比按照宽度分列的判断更加直观清晰。——路过围观的Sakamotosan 2017年8月5日 (六) 08:36 (UTC)
- 你现在还扯“直观清晰”，我就不知道是你在装什么傻了。你是没用过现代浏览器呢，还是没想过分栏的目的呢，还是读了当时默认分栏的东西就忘了呢？——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月5日 (六) 14:31 (UTC)
- 你才傻了吧。一个清晰知道需要分多少栏，另一个还需要自己掂量需要多大的栏宽。既然这么想完美自动分栏，自己弄个完美按固定栏宽的reflist，不用输入参数的，你认为多大栏宽最好的就固定栏宽值，然后你自己编辑的条目就用那个就是了，何必自找麻烦去逐个清理固定栏数的？——路过围观的Sakamotosan 2017年8月6日 (日) 00:58 (UTC)
- 你现在还扯“直观清晰”，我就不知道是你在装什么傻了。你是没用过现代浏览器呢，还是没想过分栏的目的呢，还是读了当时默认分栏的东西就忘了呢？——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月5日 (六) 14:31 (UTC)
- 上面？而且对于使用数栏分裂的话比按照宽度分列的判断更加直观清晰。——路过围观的Sakamotosan 2017年8月5日 (六) 08:36 (UTC)
- 不用 fixed-col 是上面传下来的原则。n=1 只是特例而已。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月5日 (六) 05:10 (UTC)
- 上列讨论以无共识告终。--Antigng（留言） 2018年1月11日 (四) 13:41 (UTC)
已创建快捷模板重定向
[编辑]使用{{rl}}即可有相同效果。维基百科巡查员Richard923888執行編輯~\(≧▽≦)/~和我聊天 2017年4月28日 (五) 16:00 (UTC)
- {{rl}}它原本是體育聯賽專用的地區旗幟模板啊，有條目還在用啊，已經回退。--122.100.177.149（留言） 2017年4月30日 (日) 03:12 (UTC)
已重新创建另一个模板重定向{{RL}}，请注意rl和RL不是同一个模板。维基百科巡查员Richard923888執行編輯~\(≧▽≦)/~和我聊天 2017年4月30日 (日) 04:36 (UTC)
- WP:重定向：不應創建引起混亂的重定向，已把Template:RL改為重定向至Template:rl，免得有人產生混亂。--122.100.177.149（留言） 2017年4月30日 (日) 08:00 (UTC)
@Richard923888：请考虑{{refs}}之类的名字。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年5月16日 (二) 16:41 (UTC)
編輯請求
[编辑] 请求已拒绝--Schellingok（留言） 2017年12月2日 (六) 11:23 (UTC)
- 沒有給予理由。--Xiplus←A2093064 2017年12月24日 (日) 02:59 (UTC)
語法問題
[编辑]近期常看見有人將{{Reflist|2}}改為{{Reflist|30em}}，同樣是兩欄，請問有何差別？此現象亦發生在語法前後有無「空一格」。謝謝。--Tp0910（留言） 2018年1月28日 (日) 12:24 (UTC)
- {{Reflist|30em}}是一個ref寬度為30、{{Reflist|2}}是一行分成兩個ref。--Zest 2018年1月28日 (日) 12:43 (UTC)
- [3]←這個頁面你用鍵盤的Ctrl-來看，縮小或放大後會有所差異。--Zest 2018年1月28日 (日) 12:49 (UTC)
- 學到了，感謝解惑。--Tp0910（留言） 2018年1月28日 (日) 18:32 (UTC)
- {{Reflist|30em}} 这种写法是否应该避免？感觉对移动版可能不友好。--小烈 (找我?) 2018年1月29日 (一) 05:10 (UTC)
- 不对呀，不是有人30em热衷的说固定分栏不好吗？还说固定分栏对移动版不友好，非要清掉固定分栏啊？
囧rz...——路过围观的Sakamotosan 2018年1月29日 (一) 07:12 (UTC) - 应该比|2更友好吧，空间大就多列（不知道是否会数列），少就单列。只是30em可能尚缺共识。--YFdyh000（留言） 2018年1月29日 (一) 15:17 (UTC)
- 仔细看才发现是em不是px，那应该没问题。-小烈 (找我?) 2018年1月30日 (二) 19:57 (UTC)
- 不对呀，不是有人30em热衷的说固定分栏不好吗？还说固定分栏对移动版不友好，非要清掉固定分栏啊？
- 分欄對小螢幕的使用者不友善，尤其一些參考資料很多的條目，編者把它分三欄，在小螢幕更是擠成一團。--Liaon98 我是廢物 2018年2月6日 (二) 03:58 (UTC)
refTag显示错误
[编辑]用法>>分栏中的refTag显示错误，请求更正-- ★WPTO★ 2022年4月19日 (二) 02:05 (UTC)
reflist 与 authority control
[编辑]- 下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
模板{{reflist }}与模板{{authority control}}之间如果没有空一行，authority control就不会显示，不知道是否是被reflist覆盖了。见Special:diff/71276375--Kethyga（留言） 2022年4月23日 (六) 05:37 (UTC)
- 我似乎能在上面的diff看到authority control？--Hamish with w. 2022年4月23日 (六) 09:37 (UTC)
- 同上，此版本未见显示问题。--YFdyh000（留言） 2022年4月23日 (六) 09:45 (UTC)
- 目前显示正常了……Kethyga（留言） 2022年4月23日 (六) 09:54 (UTC)
- 本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
編輯請求 2025-03-30
[编辑] 请求已拒绝引入Template:Reflist/styles.css樣式。外觀上會產生輕微變化：預設模式（即不指定欄位數或欄位寬度的情況）下自動以30em分行，而非現時的不分行。此請求適用WP:保護#需进行公示條。Sanmosa 新朝雅政 2025年3月30日 (日) 14:31 (UTC)
- 見phab:T160830及phab:T347109，當時也欲更改reflist預設的自動分欄模式，但有一個很大的問題就是原本已使用無參數{{reflist}}所產生的單欄的頁面有可能在改變後出現浮動元素佔位時產生空白的問題（見這個測試），而且有可能影響歷史版本的顯示。之前跟MW那邊的交流就是預設模式不應改變。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2025年3月30日 (日) 15:53 (UTC)
是不是条目过长就不显示了？
[编辑]条目中共十八大后落马官员列表里，参考文献处使用了{{Reflist|30em}}，但模板并没有详细列出参考文献，而是直接显示了Template:Reflist这条蓝链。删除掉部分内容后显示正常，推测可能是条目参考文献过多或是条目本身过长导致的bug。尝试替换成<references/>后，尽管显示出来了，但第891条之后的参考文献依旧显示不正常。
我使用的Chrome版本号是 135.0.7049.41 可谓不低（留言） 2025年4月8日 (二) 08:53 (UTC)
- 是條目使用模板過多，碰到系統限制了--1F616EMO（喵留言～回覆請ping） 2025年4月8日 (二) 08:54 (UTC)
- 看来确实是，我尝试去拆分一下条目--可谓不低（留言） 2025年4月8日 (二) 09:06 (UTC)
Reflist自動分欄
[编辑] 请求已拒绝如同Template:Reflist/sandbox所示，英語維基百科實現了參考資料列表自動分欄，請協助測試並添加。感謝。臺灣杉在此發言 (會客室) 2025年4月29日 (二) 05:07 (UTC)
- @Taiwania Justo：所以之後不再需要設定「2」或「30em」之類參數了？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月29日 (二) 08:15 (UTC)
- 不需要，但如果要手動也沒問題。臺灣杉在此發言 (會客室) 2025年4月29日 (二) 09:04 (UTC)
- 麻煩爬文#編輯請求 2025-03-30：見phab:T160830及phab:T347109，當時也欲更改reflist預設的自動分欄模式，但有一個很大的問題就是原本已使用無參數{{reflist}}所產生的單欄的頁面有可能在改變後出現浮動元素佔位時產生空白的問題（見這個測試），而且有可能影響歷史版本的顯示。之前跟MW那邊的交流就是預設模式不應改變。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2025年4月29日 (二) 14:08 (UTC)
- 那英語維基百科怎麽還在用？臺灣杉在此發言 (會客室) 2025年4月30日 (三) 02:53 (UTC)
- 大概就是中維社群在浮動元素（尤其圖片）的放置習慣與英維不同所致。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2025年4月30日 (三) 04:03 (UTC)
- 那英語維基百科怎麽還在用？臺灣杉在此發言 (會客室) 2025年4月30日 (三) 02:53 (UTC)
使用列表出現的問題
[编辑]在<ref>...</ref>或{{reflist|refs=}}中，使用* 建立列表，第一行/個并不會正常顯示。參見新疆种族灭绝指控。麻煩協助解決或給出指引，謝謝！--LeoSaltedFish（留言） 2025年6月8日 (日) 15:51 (UTC)
指定欄數的樣式
[编辑]如題，建議全面廢止指定欄數的樣式（如{{reflist|3}}），以使欄數可基於頁寬與欄寬而調整。進行此調整前，須先加入追蹤參數確認使用指定欄數的樣式的頁面的數量。Sanmosa 风林火山 2026年4月22日 (三) 04:52 (UTC)
- 不可，早年在幕後討論是曾經有考慮過，但很難完全排除有些情況可能反而是指定固定欄數較佳，記得以前見過有些條目好像是途中的某些列表或右側文字就要提前列註，確實是要指定固定欄數而不是欄寬，是故仍有保留必要，也不應有理無理機械式全部替換。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月22日 (三) 16:50 (UTC)
- 需要具體的現行例子證明，「以前的情況」現時不一定適用。此外，指定固定欄數不利使用流動裝置介面的讀者閱讀。Sanmosa 风林火山 2026年4月24日 (五) 05:01 (UTC)
- 「固定欄數不利使用流動裝置介面的讀者閱讀」其實也不是一定的。應該要證明的是「完全沒有可能出現固定欄數是適合的」，但一百萬個條目確實可以合理預期當中不排除有的情況即使用了固定欄數也不構成影響。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 05:16 (UTC)
- en:Template_talk:Reflist/Archive_14#General_recommendation_to_use_"colwidth"_parameter，「其實也不是一定的」不成立，這事情已經說了很多年了，而基於這點，「應該要證明的是『完全沒有可能出現固定欄數是適合的』」也不成立。我堅持必須要先看到具體的現行例子證明必須指定欄數而非欄寬的情況存在才能考慮保留指定欄數的機制的合理性。Sanmosa 风林火山 2026年4月24日 (五) 06:31 (UTC)
- 我希望閣下搞清楚「General recommendation」的意思是甚麼才好說——「一般建議」，若「其實也不是一定的」不成立，那不應該僅僅是建議，而是強制。坦白說，我也不喜歡{{reflist|3}}，但連我也不敢寫包單說全部狀況下都一定不行。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 07:09 (UTC)
- 文本上的事情不能只按字面意思來看，也需要看實際執行情況，而那邊的實際執行情況是到了後來en:Template talk:Reflist/Archive 25#Deprecating fixed number of columns廢止了指定欄數的樣式，其中提及的原因一模一樣。我仍然堅持必須要先看到具體的現行例子證明必須指定欄數而非欄寬的情況存在才能考慮保留指定欄數的機制的合理性。Sanmosa 风林火山 2026年4月24日 (五) 08:09 (UTC)
- 看討論麻煩看到最後，那邊的討論最後是要重來，他們最後的方案是把固定欄數封頂，不是完全廢除。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 08:32 (UTC)
- 所以你要不要看我下方的執行思路？再者我的原始提議本就不是一步到位，加入追蹤參數本也無不可吧？Sanmosa 风林火山 2026年4月24日 (五) 09:04 (UTC)
- 然後證明必須指定欄數而非欄寬的具體的現行例子又在哪裏？Sanmosa 风林火山 2026年4月24日 (五) 23:05 (UTC)
- 重來討論已表明像閣下如此的推定並不正確（there were some incorrect assumptions in the initial proposal）而未廢止，連那邊都不敢完全確定，怎麼可能這裏敢確定？您試圖將「一般建議」超譯為「必然」本身就已經不合理了，本來就沒有必要一定要看到例子才能證明。（我是有見過需要固定欄的情況，奈何當年沒記下）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月27日 (一) 20:29 (UTC)
- 這不是推卸舉證責任的理由。Sanmosa 风林火山 2026年4月28日 (二) 05:50 (UTC)
- 舉證責任本來就應該是提案者，而且這裏也涉及到要汲取別人教訓和經驗的問題，那邊都出過問題而要留着，這裏更加不能如此武斷。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月28日 (二) 06:03 (UTC)
- 你既然提出了“不可全面廢止指定欄數的樣式”的主張，那你就有義務為你自己的主張作有效舉證。說來說去，你能有效舉證的話，這面前的問題不就能解決了？Sanmosa 风林火山 2026年4月28日 (二) 13:28 (UTC)
- 問題是您的提案本身正在主張「固定欄數不利使用流動裝置介面的讀者閱讀」是「一定的」，然而連英文那邊的討論都沒有肯定這個主張（甚至那邊反過來說incorrect assumptions），故此是您有舉證責任在先。也請注意現在未舉出例子從來就不代表沒有例子存在（閣下如上論調其實犯了訴諸無知的邏輯謬誤：Simply because you do not have evidence that something exists does not mean that you have evidence that it doesn't exist），更何況以前真的見過有關案例。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月28日 (二) 17:23 (UTC)
- Template:Reflist/doc的既成事實我相信你也是有看到的。不尋常的主張本就需要足夠有效的舉證以滿足較高的相信門檻，社羣並不是你說甚麼就是甚麼的地方，如果你無法就你不尋常的主張作足夠有效的舉證，社羣本就無法（全然）相信你不尋常的主張。說白些，你在這裏幾度聲稱自己「以前見過」不能不用指定欄數的樣式的情況，但沒有人知道你是否真的見過，沒有人知道你「見過」的情況現在是否仍然如此，也沒有人知道你「見過」的情況現在是否真的沒有替代解決方案，你在這種情況下要求社羣必須全然相信你不尋常的主張無異於空手套白狼。Sanmosa 风林火山 2026年4月29日 (三) 01:31 (UTC)
- Template:Reflist/doc？？本地的doc根本沒有既成事實。不過就算是英文版doc，也衹不過是停在不推薦使用（deprecate）而非廢止（discontinue），不然那邊理應如您所說的思路那般設為當指定固定欄數時直接報錯不用封頂，然而那邊並沒有，顯然地您所謂的既成事實是基於將deprecate超譯為discontinue，這本身就已經不尋常。您的主張本來就已經存在多次超譯，指控別人的理據不尋常時，請先想一下自己又是否尋常；尤其是您的主張在那邊已被證過偽，您作為提案人當然是先有責任舉證一個被視為incorrect的主張在這裏為何又可以用，連這個都不先確定，您反而要求對方先反證本來就不合理了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年5月5日 (二) 20:32 (UTC)
- deprecate在zhwiki被翻譯為「停用」，其強烈程度與你所聲稱的「不推薦使用」有很大的差別。從其他社羣成員在這裏的反應來看，我的理據簡直尋常得不能再尋常了。還請你就你不尋常的主張提出有效舉證，enwiki的情況不一定意味zhwiki的情況，enwiki解決不了的問題zhwiki不一定同樣解決不了，你不能完全不給予社羣理解並解決具體問題的機會。Sanmosa 风林火山 2026年5月7日 (四) 22:34 (UTC)
- Template:Reflist/doc？？本地的doc根本沒有既成事實。不過就算是英文版doc，也衹不過是停在不推薦使用（deprecate）而非廢止（discontinue），不然那邊理應如您所說的思路那般設為當指定固定欄數時直接報錯不用封頂，然而那邊並沒有，顯然地您所謂的既成事實是基於將deprecate超譯為discontinue，這本身就已經不尋常。您的主張本來就已經存在多次超譯，指控別人的理據不尋常時，請先想一下自己又是否尋常；尤其是您的主張在那邊已被證過偽，您作為提案人當然是先有責任舉證一個被視為incorrect的主張在這裏為何又可以用，連這個都不先確定，您反而要求對方先反證本來就不合理了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年5月5日 (二) 20:32 (UTC)
- Template:Reflist/doc的既成事實我相信你也是有看到的。不尋常的主張本就需要足夠有效的舉證以滿足較高的相信門檻，社羣並不是你說甚麼就是甚麼的地方，如果你無法就你不尋常的主張作足夠有效的舉證，社羣本就無法（全然）相信你不尋常的主張。說白些，你在這裏幾度聲稱自己「以前見過」不能不用指定欄數的樣式的情況，但沒有人知道你是否真的見過，沒有人知道你「見過」的情況現在是否仍然如此，也沒有人知道你「見過」的情況現在是否真的沒有替代解決方案，你在這種情況下要求社羣必須全然相信你不尋常的主張無異於空手套白狼。Sanmosa 风林火山 2026年4月29日 (三) 01:31 (UTC)
- 問題是您的提案本身正在主張「固定欄數不利使用流動裝置介面的讀者閱讀」是「一定的」，然而連英文那邊的討論都沒有肯定這個主張（甚至那邊反過來說incorrect assumptions），故此是您有舉證責任在先。也請注意現在未舉出例子從來就不代表沒有例子存在（閣下如上論調其實犯了訴諸無知的邏輯謬誤：Simply because you do not have evidence that something exists does not mean that you have evidence that it doesn't exist），更何況以前真的見過有關案例。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月28日 (二) 17:23 (UTC)
- 你既然提出了“不可全面廢止指定欄數的樣式”的主張，那你就有義務為你自己的主張作有效舉證。說來說去，你能有效舉證的話，這面前的問題不就能解決了？Sanmosa 风林火山 2026年4月28日 (二) 13:28 (UTC)
- 舉證責任本來就應該是提案者，而且這裏也涉及到要汲取別人教訓和經驗的問題，那邊都出過問題而要留着，這裏更加不能如此武斷。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月28日 (二) 06:03 (UTC)
- 這不是推卸舉證責任的理由。Sanmosa 风林火山 2026年4月28日 (二) 05:50 (UTC)
- 重來討論已表明像閣下如此的推定並不正確（there were some incorrect assumptions in the initial proposal）而未廢止，連那邊都不敢完全確定，怎麼可能這裏敢確定？您試圖將「一般建議」超譯為「必然」本身就已經不合理了，本來就沒有必要一定要看到例子才能證明。（我是有見過需要固定欄的情況，奈何當年沒記下）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月27日 (一) 20:29 (UTC)
- 看討論麻煩看到最後，那邊的討論最後是要重來，他們最後的方案是把固定欄數封頂，不是完全廢除。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 08:32 (UTC)
- 文本上的事情不能只按字面意思來看，也需要看實際執行情況，而那邊的實際執行情況是到了後來en:Template talk:Reflist/Archive 25#Deprecating fixed number of columns廢止了指定欄數的樣式，其中提及的原因一模一樣。我仍然堅持必須要先看到具體的現行例子證明必須指定欄數而非欄寬的情況存在才能考慮保留指定欄數的機制的合理性。Sanmosa 风林火山 2026年4月24日 (五) 08:09 (UTC)
- 我希望閣下搞清楚「General recommendation」的意思是甚麼才好說——「一般建議」，若「其實也不是一定的」不成立，那不應該僅僅是建議，而是強制。坦白說，我也不喜歡{{reflist|3}}，但連我也不敢寫包單說全部狀況下都一定不行。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 07:09 (UTC)
- en:Template_talk:Reflist/Archive_14#General_recommendation_to_use_"colwidth"_parameter，「其實也不是一定的」不成立，這事情已經說了很多年了，而基於這點，「應該要證明的是『完全沒有可能出現固定欄數是適合的』」也不成立。我堅持必須要先看到具體的現行例子證明必須指定欄數而非欄寬的情況存在才能考慮保留指定欄數的機制的合理性。Sanmosa 风林火山 2026年4月24日 (五) 06:31 (UTC)
- 「固定欄數不利使用流動裝置介面的讀者閱讀」其實也不是一定的。應該要證明的是「完全沒有可能出現固定欄數是適合的」，但一百萬個條目確實可以合理預期當中不排除有的情況即使用了固定欄數也不構成影響。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 05:16 (UTC)
- 需要具體的現行例子證明，「以前的情況」現時不一定適用。此外，指定固定欄數不利使用流動裝置介面的讀者閱讀。Sanmosa 风林火山 2026年4月24日 (五) 05:01 (UTC)
- 支持开展追踪和清理工作。但不认为最终有必要废除固定栏数的参数。--PexEric 2026年4月22日 (三) 16:55 (UTC)
- 參數本身是會保留的，因為預設情況（不分欄）的實現方式是預設固定欄數為1，而且匿名參數1也能填其他東西。我的思路是如果匿名參數1填入了不是「1」的純數字，那就會報錯。Sanmosa 风林火山 2026年4月24日 (五) 05:04 (UTC)
- 可能要使用
responsive=0和responsive=1来切换是自动分栏还是手工分栏？--百無一用是書生 (☎) 2026年4月23日 (四) 03:03 (UTC)- 見phab:T160830，存在缺陷無解故不宜使用。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月23日 (四) 20:54 (UTC)
- 我看英文版有在用啊--百無一用是書生 (☎) 2026年4月24日 (五) 02:55 (UTC)
- 英文版不一定要追從，明知有缺陷不應妄動。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 03:10 (UTC)
- 英文版用了自动分栏有加追踪吗？--百無一用是書生 (☎) 2026年4月29日 (三) 08:30 (UTC)
- 我是說「追從」不是「追蹤」，我的意思是不要仿效那邊把有缺陷未解的功能偷步引入。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年5月5日 (二) 20:32 (UTC)
- 英文版用了自动分栏有加追踪吗？--百無一用是書生 (☎) 2026年4月29日 (三) 08:30 (UTC)
- 英文版不一定要追從，明知有缺陷不應妄動。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月24日 (五) 03:10 (UTC)
- 我看英文版有在用啊--百無一用是書生 (☎) 2026年4月24日 (五) 02:55 (UTC)
- 見phab:T160830，存在缺陷無解故不宜使用。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2026年4月23日 (四) 20:54 (UTC)
- 完全技术上废除的话短期比较麻烦，不过可以加一个跟踪分类作为后续操作的跟踪依据。——Sakamotosan路过围观 | 避免做作，免敬 2026年4月24日 (五) 03:18 (UTC)
- #编辑请求：为固定列数设计增加追踪模板，过往讨论过，还说方便“处理掉”，但真的要这样搞？ 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2026年4月24日 (五) 03:21 (UTC)
- 一切可能要在加入追蹤參數後才能定論了。Sanmosa 风林火山 2026年4月24日 (五) 05:06 (UTC)
- #编辑请求：为固定列数设计增加追踪模板，过往讨论过，还说方便“处理掉”，但真的要这样搞？
- 就着加入追蹤參數確認使用指定欄數的樣式的頁面的數量的提議，現建議於{{reflist}}加入下述代碼：「{{#if:{{{1|}}}|{{#ifeq:{{{1|}}}|{{digits|{{{1|}}}}}|{{#switch:{{{1|}}}|1=|#default=[[Category:指定固定欄數的Reflist]]}}}}}}」。Sanmosa 风林火山 2026年5月7日 (四) 22:42 (UTC)
- 考虑到该模板有百万个使用，是否有其他评估方式以避免大量刷新的成本及用时，例如脚本扫描数据库副本以估测？--YFdyh000（留言） 2026年5月7日 (四) 23:58 (UTC)
- 這我並不熟悉。Sanmosa 风林火山 2026年5月8日 (五) 02:50 (UTC)
- 再确认一下，“作为后续操作的跟踪依据”是怎样的依据，根据数量了解使用量和需求，还是要求持续减少、体现成果。如果只需要估算级别的依据，是否随机取样检查参数也可接受。如果单纯想了解一个精确数量且要求实时跟踪，我觉得没太大意义，尤其是为此刷新所有链入（注：我知道“不要担心性能”）。很难预测这种刷新需要多久，并且已知系统有时出现缓存不刷新的现象，导致分类成员不精准。另外，也可过滤器标签来追踪和提醒新增。--YFdyh000（留言） 2026年5月9日 (六) 01:44 (UTC)
- 同YFdyh000，应该有其他方式查找有关用到的页面，例如源代码搜索，toolforge开发了一些这样的工具，如[4]。而且这段追踪语法还叫了几个条件式，还嵌了模板，开销肯定多了，有的页面可能已经用了非常多的模板而接近模板开销限制的边缘，这样改会有推爆限制的风险，可能很难短时间修复，所以不支持直接修改模板。--Peck2442 2026年5月15日 (五) 01:27 (UTC)
- 考虑到该模板有百万个使用，是否有其他评估方式以避免大量刷新的成本及用时，例如脚本扫描数据库副本以估测？--YFdyh000（留言） 2026年5月7日 (四) 23:58 (UTC)
新方案
[编辑]不好意思，最近因為各方面的事務都比較繁忙而無暇顧及這邊的討論串。我在較早前已經收到了YFdyh000有關Reflist指定欄數的統計的留言，因此我相信現在已經沒必要加入追蹤參數確認使用指定欄數的樣式的頁面的數量了。然而，考慮到使用指定欄數的樣式的頁面的數量比較多，即使用bot來處理，耗時可能還是比較長，因此這裏提出一個新方案：
{{reflist}}填寫值大於1的固定欄數（如{{reflist|2}}）時，固定欄數按公式自動換算成欄寬。
公式：y=60/x（x為固定欄數，y為欄寬）
這樣做的一個可預期的影響是頁寬較窄的電子設備因為固定欄數被自動換算成欄寬而全部顯示成只有一欄，但考慮到在頁寬較窄的電子設備顯示多個分欄可能會導致字體過小的問題，這個影響對頁寬較窄的電子設備而言應該是正面的。以上。Sanmosa 风林火山 2026年5月15日 (五) 11:29 (UTC)
- @Cdip150、PexEric、Shizhao、Cwek、YFdyh000、Peck2442。Sanmosa 风林火山 2026年5月15日 (五) 11:30 (UTC)
- 虽然倾向支持优化显示，但这样改变参数行为我怀疑复杂度较不可控。如果该显示的长度能被权衡，建议机器人批量修改参数，或者整体设定某种min/max，少数特例改回与讨论或者新设一个‘忽略限制’参数。--YFdyh000（留言） 2026年5月15日 (五) 11:37 (UTC)
- @YFdyh000：“複雜度較不可控”具體的意思是甚麽？我剛調整了沙盒的內容，你可以看一下這種實現方式會否導致你所說的“複雜度較不可控”的問題。如果確實有需要的話，我不反對留個後門，這點在原始碼上很容易實現，但是需要看其他討論參與者的意思。Sanmosa 风林火山 2026年5月15日 (五) 13:07 (UTC)
- 大致指，明确的参数开始被忽略，而新行为可能存在bug，到时不太好收拾，新行为可能该先经历更长久测试。如果要解决“多个分栏可能会导致字体过小的问题”，可能该不限于已指定固定栏数的情况，以及是否该自动适当分栏。对如何分栏，我还没有清晰想法。--YFdyh000（留言） 2026年5月15日 (五) 13:15 (UTC)
- 看看其他人有沒有意見，沒意見的話我就開個後門。Sanmosa 风林火山 2026年5月15日 (五) 13:28 (UTC)
- 同YFdyh000的疑虑，这样改很难保证不会出现很多bug，而且是会即时出现的bug，即便有后门忽略参数也可能很难在短时间修复，要冒的风险实在难说，同时这语法还是有开销限制的疑虑。所以现在不支持直接做任何更改。--Peck2442 2026年5月22日 (五) 08:02 (UTC)
- @Peck2442：然而現在的一個問題是沒人知道“很難保證不會出現很多bug”的“（很多）bug”具體到底是甚麽，而這恰好也只有先落實一次修訂才能知道。Sanmosa 风林火山 2026年5月23日 (六) 05:30 (UTC)
- “落实一次修订”为什么不是批量修改条目源码呢，这样容易观察也更彻底。--YFdyh000（留言） 2026年5月23日 (六) 12:26 (UTC)
- @YFdyh000：工作量過於浩大，我不肯定bot是否有能力處理，我也不肯定“容易觀察也更徹底”是否真的成立。此外，有用戶聲稱存在必須指定欄數而非欄寬的情況，如果批量修改條目原始碼，（假設出了問題）那可能也需要同樣規模的批量回退（即回退全數批量操作），而在這種情況下我們也不太好拒絕這樣的要求。Sanmosa 风林火山 2026年5月25日 (一) 11:33 (UTC)
- 机器人去掉参数没有难度。能通过历史版本轻松对比单个条目的效果，对比模板变更要麻烦很多。那些是少数特例，改模板的代价大非常多。机器人去掉可以逐批次，不需要一次性完成。必须固定栏数的，应该找出，列明或统一标注，并考虑是否合理（例如用指引禁止）、能否改变。--YFdyh000（留言） 2026年5月25日 (一) 11:42 (UTC)
- @YFdyh000：工作量過於浩大，我不肯定bot是否有能力處理，我也不肯定“容易觀察也更徹底”是否真的成立。此外，有用戶聲稱存在必須指定欄數而非欄寬的情況，如果批量修改條目原始碼，（假設出了問題）那可能也需要同樣規模的批量回退（即回退全數批量操作），而在這種情況下我們也不太好拒絕這樣的要求。Sanmosa 风林火山 2026年5月25日 (一) 11:33 (UTC)
- “落实一次修订”为什么不是批量修改条目源码呢，这样容易观察也更彻底。--YFdyh000（留言） 2026年5月23日 (六) 12:26 (UTC)
- @Peck2442：然而現在的一個問題是沒人知道“很難保證不會出現很多bug”的“（很多）bug”具體到底是甚麽，而這恰好也只有先落實一次修訂才能知道。Sanmosa 风林火山 2026年5月23日 (六) 05:30 (UTC)
- 大致指，明确的参数开始被忽略，而新行为可能存在bug，到时不太好收拾，新行为可能该先经历更长久测试。如果要解决“多个分栏可能会导致字体过小的问题”，可能该不限于已指定固定栏数的情况，以及是否该自动适当分栏。对如何分栏，我还没有清晰想法。--YFdyh000（留言） 2026年5月15日 (五) 13:15 (UTC)
- @YFdyh000：“複雜度較不可控”具體的意思是甚麽？我剛調整了沙盒的內容，你可以看一下這種實現方式會否導致你所說的“複雜度較不可控”的問題。如果確實有需要的話，我不反對留個後門，這點在原始碼上很容易實現，但是需要看其他討論參與者的意思。Sanmosa 风林火山 2026年5月15日 (五) 13:07 (UTC)
- 虽然倾向支持优化显示，但这样改变参数行为我怀疑复杂度较不可控。如果该显示的长度能被权衡，建议机器人批量修改参数，或者整体设定某种min/max，少数特例改回与讨论或者新设一个‘忽略限制’参数。--YFdyh000（留言） 2026年5月15日 (五) 11:37 (UTC)
直接批量替換的方案
[编辑]根據上方討論的情況，現改為建議直接批量替換填入的參數。替換規則為如匿名參數1填入的內容為大於1的純整數（下稱「x」），以y=60/x的公式計算對應欄寬後，將x替換為yem（如2替換為30em）。@Cdip150、PexEric、Shizhao、Cwek、YFdyh000、Peck2442。Sanmosa 风林火山 2026年6月1日 (一) 07:20 (UTC)
- 总体上我不反对。菲律賓公民簽證要求的{{reflist|6}}变成10em，会变得更窄。臺中市公共自行車租賃系統从{{reflist|5}}改成12em，效果看上去变凌乱了，1080p分辨率下5排变为7排，但小屏幕下的显示效果大幅改善。--YFdyh000（留言） 2026年6月1日 (一) 20:26 (UTC)
- 明朝七卿年表，参数3改成20em不如30em，增加留白。--YFdyh000（留言） 2026年6月1日 (一) 21:25 (UTC)
- 6月扫描结果，附有条目内ref数量，但不支持发现{{sfn}}等用法。--YFdyh000（留言） 2026年6月1日 (一) 21:27 (UTC)
- @YFdyh000：
- 這兩個條目的欄數設置本來就不當，直接按不當的欄數設置換算欄寬自然會出問題。我分別換成20em與30em了。
- 來源數過多，30em可能會過長，20em應該是適當的（參考西園寺家#參考資料）。
- 悉。
- Sanmosa 风林火山 2026年6月2日 (二) 01:14 (UTC)
- 手动设了4栏及以上，或者计算出来小于20em的，应手动修改为20em/30em，对于参考文献数少于10个的直接移除？之前遇到过很多只加了一两个参考文献就要设4/5栏的条目了。--Tim（留言） 2026年6月2日 (二) 01:22 (UTC)
- @TimWu007：前者不反對（其實也不一定需要手動，調整公式即可），看其他人有沒有意見。後者有保留，我自己有時候即使只有五六個參考資料也還是會設為30em。Sanmosa 风林火山 2026年6月2日 (二) 01:36 (UTC)
- 10的数字是来源于英维自动分栏的门槛。--Tim（留言） 2026年6月2日 (二) 01:38 (UTC)
- @TimWu007：這方面還是容許彈性吧，排版的美感還是需要顧慮一下的。Sanmosa 风林火山 2026年6月2日 (二) 01:42 (UTC)
- 我的本意是遇到设了4+以上分栏的话，人工检视下当前设置是否合理的。--Tim（留言） 2026年6月2日 (二) 01:48 (UTC)
- 或許可以以批量替換為20em並加入追蹤分類的方式處理？Sanmosa 风林火山 2026年6月2日 (二) 05:24 (UTC)
- 我的本意是遇到设了4+以上分栏的话，人工检视下当前设置是否合理的。--Tim（留言） 2026年6月2日 (二) 01:48 (UTC)
- @TimWu007：這方面還是容許彈性吧，排版的美感還是需要顧慮一下的。Sanmosa 风林火山 2026年6月2日 (二) 01:42 (UTC)
- 10的数字是来源于英维自动分栏的门槛。--Tim（留言） 2026年6月2日 (二) 01:38 (UTC)
- @TimWu007：前者不反對（其實也不一定需要手動，調整公式即可），看其他人有沒有意見。後者有保留，我自己有時候即使只有五六個參考資料也還是會設為30em。Sanmosa 风林火山 2026年6月2日 (二) 01:36 (UTC)
- 手动设了4栏及以上，或者计算出来小于20em的，应手动修改为20em/30em，对于参考文献数少于10个的直接移除？之前遇到过很多只加了一两个参考文献就要设4/5栏的条目了。--Tim（留言） 2026年6月2日 (二) 01:22 (UTC)
- @YFdyh000：
- 我认为完全不适合用机器人，除了4+，2和3都应该是全人工检查，假设明朝七卿年表本身用的是2，你又认为20em才对，那就是2对不上30em了，另外象是中文书面语如果把3改成20em我会觉得太紧了，这下就说明2不能全部都对应30em、3不能全部都对应20em，这种对不上的情况可能不会少，如果用了机械人结果还是要反过来大量追踪检查，还不如全部人工编辑预览一次才保存。所以反对任何机械人批量更改方案。--Peck2442 2026年6月8日 (一) 22:45 (UTC)
- @Peck2442：工作量太大，無法全人工檢查。Sanmosa 风林火山 2026年6月9日 (二) 14:25 (UTC)
- 这不是理由，数量多少与能不能省略人工检查并没有关系，不可能说量多就可以先不检查直接改。--Peck2442 2026年7月9日 (四) 14:24 (UTC)
- @Peck2442：工作量太大，無法全人工檢查。Sanmosa 风林火山 2026年6月9日 (二) 14:25 (UTC)
編輯請求 2026-10-28
[编辑]
迁移至使用模板样式的{{Reflist}}，用了比较保守的改法，暂时保留了固定栏数的用法，而不是将两栏和三栏分别转换为30em和25em并将四栏以上舍弃（强制显示为三栏），同时中维特有的{{list}}参数也保留了下来。--Dabao qian℡ 2026年10月28日 (三) 08:34 (UTC)