跳至內容

模板討論:Unblock

頁面內容不支援其他語言。
新增話題
維基百科,自由的百科全書
由Shwangtianyuan在話題編輯請求 2026-01-18上作出的最新留言:5 個月前

編輯請求

[編輯]

添加IPBE按鈕,一些小修改。--Stang c 2016年5月10日 (二) 02:17 (UTC)回覆

編輯請求

[編輯]
請求已處理

僅限管理員使用框不會自動隱藏,修改方案參見Draft:Template:Blocks_review。 --A2093064#Talk 2016年8月7日 (日) 09:05 (UTC)回覆

編輯請求

[編輯]
請求已處理

請求將開始的<span id="rfu" />修改為<span id="rfu"></span>。理由:清理Category:使用無效自封閉HTML標籤的頁面 --XYZ指示物(留言) 2016年8月8日 (一) 23:00 (UTC)回覆

 已修復,感謝提醒。--Stang 2016年8月10日 (三) 14:48 (UTC)回覆

建議管理員使用{{封禁申訴}}中的參數「無效」和「過期」

[編輯]

看見管理員如AT等對處理過期的封禁申訴均以拒絕回應。本人在此希望管理員使用其參數「無效」和「過期」,謝謝!--沉迷酒色的人(留言 | 簽到)發表於 2016年11月19日 (六) 01:27 (UTC)回覆

ep

[編輯]
請求已處理

對是否加入Category:已接受的封禁申訴的判斷不夠精確。註:可能{{Template:Editprotected/patch}}里哪裏出了問題,模版沒顯示好,我手打一遍:請檢查修改方案無誤。 --碸中嘌呤的白磷萃取 打譜 2017年2月28日 (二) 08:18 (UTC)回覆

完成 --Antigng(留言) 2017年2月28日 (二) 09:00 (UTC)回覆

{{封禁申訴}}模版的長時間存留的疑問

[編輯]

今天突然發現一個問題。

{{封禁申訴}}模版裏面寫着這樣的操作指示:

不過,可見數量龐大的用戶並不選擇在查封解除或者查封自然結束之後,移除這個模版。基本上,就這樣原樣留在用戶討論頁面上和存檔裏。模版當初規定要求解封後移除的理由我不清楚,可能是為了整潔、站務方便或者減少嵌入式引用HRT的考慮,用戶保留則可能有着存檔和記錄清晰的考慮。總之,這種規定和做法不一樣的情況很是奇怪,我認為可以討論一下究竟是應該推廣執行「解封後刪模版」,還是應該去掉這個誰也不遵從的要求。Bluedeck 2017年3月9日 (四) 18:38 (UTC)回覆

如果「解封後刪模版」,那Category:已接受的封禁申訴就沒什麼卵用了。 --碸中嘌呤的白磷萃取 打譜 2017年3月9日 (四) 19:04 (UTC)回覆

「移除本模板」似乎是從舊樣式的封禁申訴模板沿用下來的(9683710的當前版本),現在顯然已無用,且沒有任何方針指引依據,我認為可以去掉。--Wcam(留言) 2017年3月9日 (四) 23:27 (UTC)回覆

我認為那是用於標示已經處理的分類吧,分類應該保持為空,也就是已經處理好了。——路過圍觀的Sakamotosan 2017年3月10日 (五) 04:47 (UTC)回覆
本人認為應當去掉這項要求。-雨宮千夏❀(留言)直接ping我回復 2017年3月10日 (五) 13:06 (UTC)回覆
留住模版當然較好。--Temp3600(留言) 2017年3月10日 (五) 18:30 (UTC)回覆
我也覺得模版留在用戶頁面上起到很好的存檔作用,用戶願意留着,就沒有理由強制刪除。那麼,就正式提出刪除上述操作提示。Bluedeck 2017年3月10日 (五) 19:00 (UTC)回覆
有存檔作用,是應該留。——Artoria2e5編 保持討論完整,直接{{ping}}我回復。 2017年3月11日 (六) 05:10 (UTC)回覆

done

[編輯]

由於沒有反對意見,上述操作提示由bluedeck移除。Bluedeck 2017年3月17日 (五) 17:19 (UTC)回覆


編輯請求

[編輯]
請求已處理

擬於該模板中加入對接受解封請求的提醒,以提醒管理員落實封禁方針中對解封的相關要求。修改細節詳見草稿頁。——Aotfs2013 留於 2017年10月24日 (二) 13:21 (UTC)回覆

相關編輯禁制方針下的修正

[編輯]
請求已拒絕

把"當前封禁作出複檢"當前封禁/禁制作出複檢"。以上。--1233( T / C) 2018年5月7日 (一) 14:01 (UTC)回覆

@1233:建議是做新的模板,要不然封禁記錄之類的連結在禁制根本沒用處。--Xiplus#Talk 2018年5月7日 (一) 14:22 (UTC)回覆
@Xiplus:不關我事,我也不想做模板。我只是根據方針要求而要求進行事實性修改。--1233( T / C) 2018年5月7日 (一) 14:27 (UTC)回覆
未完成:{{Unban}}。--Xiplus#Talk 2018年5月11日 (五) 04:47 (UTC)回覆

編輯請求

[編輯]

我發現模板的指示為︰

請把{{封禁申訴|理由或提問}}中的「理由或提問」替換成您的請求理由或疑問。

但實際需要有「1=」,即︰

請把{{封禁申訴|1=理由或提問}}中的「理由或提問」替換成您的請求理由或疑問。

請幫忙修正。謝謝!——番薯 SweetPotato (留言給我 Talk to me) 2018年12月19日 (三) 16:49 (UTC)回覆

編輯請求 2019-04-03

[編輯]

參考此---Zest 2019年4月3日 (三) 08:28 (UTC)回覆

編輯請求 2023-06-15

[編輯]
請求已處理

第11行:

**由于技术原因,如果启用了“ 用户讨论页上的[[Wikipedia:結構式討論|结构式讨论]]”功能的话,请将该请求放到讨论页主页面的“关于此版块”中,否则该请求无法显示在请求分类中让管理员留意到。

「啟用了」後面的開引號後多了個空格。繁體的「後面多了空格就很明顯。--路西法人 2023年6月15日 (四) 13:20 (UTC)回覆

我收到MediaWiki軟件通知我在這裏發了三個通知,我完全沒看懂為何,如果您被ping來這裏了,先說聲抱歉,但我也不知道為啥。--路西法人 2023年6月15日 (四) 13:22 (UTC)回覆
Template:樂意處理EP的管理員。--Xiplus#Talk 2023年6月18日 (日) 06:15 (UTC)回覆
 已修復--百無一用是書生 (☎) 2023年7月26日 (三) 07:45 (UTC)回覆

編輯請求 2023-10-16

[編輯]
請求已處理

將工具條顯示的內容按申請者是否為匿名用戶做了差分顯示,新增了查看過濾器日誌連結,修正了以前增加授予 IPBE 連結時括號位置錯誤導致該連結不起作用(但沒法驗證)--廣雅 范★ 2023年10月16日 (一) 10:01 (UTC)回覆

完成--百無一用是書生 (☎) 2023年10月20日 (五) 11:53 (UTC)回覆

編輯請求 2023-11-03

[編輯]
請求已拒絕

建議將此模板所有「封禁」改為「封禁或禁制」,因為此模板可以用於禁制申訴。--桐生ここ★[討論] 2023年11月3日 (五) 04:37 (UTC)回覆

封禁和禁制有很大不同,不能實行上述修改--百無一用是書生 (☎) 2023年11月14日 (二) 11:59 (UTC)回覆

編輯請求 2024-04-01

[編輯]
請求已處理

請求管理員或模板編輯員修正內鏈與標點符號,更改後的效果為:

此用戶正請求管理員對當前封禁作出複檢或者回應相關提問:

謝謝。--Shwangtianyuan 不忘初心 牢記使命 2024年4月1日 (一) 15:52 (UTC)回覆

完成--百無一用是書生 (☎) 2024年4月9日 (二) 03:33 (UTC)回覆

編輯請求

[編輯]
請求已處理

刪除注意flow頁面申訴,已無flow頁面-- A0(討論·簽名) 2024年12月20日 (五) 12:45 (UTC)回覆

暫時保留一下也無大礙吧?備而不用。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年12月21日 (六) 04:29 (UTC)回覆
但沒有FLOW頁面,保存亦是沒有必要?-- A0(討論·簽名) 2024年12月21日 (六) 04:31 (UTC)回覆
@August0422 請問具體要修改哪裏?我找不到任何flow字眼。Пусть от победы☆к победе ведёт! 2025年1月6日 (一) 13:35 (UTC)回覆
@阿南之人,由於技術原因那邊--August0422討論 2025年1月6日 (一) 13:36 (UTC)回覆
我看到了,那麼(+)支持此修改。Пусть от победы☆к победе ведёт! 2025年1月6日 (一) 13:37 (UTC)回覆
我覺得整個擴充功能徹底刪除了再來刪這句話就好,這句話放着也不礙事。--SunAfterRain 2024年12月23日 (一) 13:39 (UTC)回覆
已確定於gerrit:1110814更改為read only,故完成--SunAfterRain 2025年1月19日 (日) 04:30 (UTC)回覆

編輯請求 2025-01-06

[編輯]
請求已處理

現時Flow已經停用,分類錯誤也隨之而消失了。現在請求移除模板最下面{{unblock/open}}。--Пусть от победы☆к победе ведёт! 2025年1月6日 (一) 13:29 (UTC)回覆

@阿南之人:為什麼你們都覺得flow已經被徹底解除安裝了啊... 跟上面那個一樣等移除後再刪。--SunAfterRain 2025年1月6日 (一) 16:33 (UTC)回覆
已確定於gerrit:1110814更改為read only,故完成--SunAfterRain 2025年1月19日 (日) 04:30 (UTC)回覆

封禁申訴流程適配DiscussionTools

[編輯]

目前的封禁申訴流程對DiscussionTools非常不友好,要求用戶前往原始碼界面按特定格式填入資訊,無法使用討論工具發起申訴,偶爾會出現{{unblock}}模板被置於冒號縮排內導致排版崩壞、或因其怪異格式而導致無法使用DT回覆留言。如果用新章節開啓封禁申訴(可用section=new&preload=...的按鈕指引新手操作),並將管理員最終決定的留言放置於最下方(一如其他留言),或可解決問題,例見個人討論頁沙盒。我還沒有確實想好怎麼改,就此問題邀請社羣討論,另邀請@SuperGrey、Diskdance。--1F616EMO(喵留言~回覆請ping~求助?) 2025年8月26日 (二) 00:25 (UTC)回覆

修正「個人用戶頁沙盒」連結。1F616EMO(喵留言~回覆請ping~求助?) 2025年8月27日 (三) 09:57 (UTC)回覆
也許可以用JavaScript小工具處理? ——魔琴[留言 貢獻 PJ:小學 PJ:兩岸] 2025年8月28日 (四) 07:59 (UTC)回覆
我同意應該避免讓用戶使用reply tool,因為要麼會造成<nowiki>{{unblock|xxx}}</nowiki>(可視化模式回復),要麼就是源碼模式生成:{{unblock|xxx,然後被parser搞亂排版。所以我先讓{{uw-block}}隱藏回復按鈕了[1]。
我其實覺得目前MediaWiki:blockedtext的「按此」就還算方便(至少preload了表單)。雖然不夠顯眼,但這種場合最好先讓用戶閱讀WP:封禁申訴再撰寫理由,所以可能不適合放一個特別顯眼的按鈕(<inputbox>),以避免亂寫一通然後浪費精力來回溝通?不過用戶需要到編輯界面才能見到這個提示,如果只是看到了討論頁的警告就想申訴,應該就不容易注意到它了吧。
如果想用上DiscussionTools,它的new topic tool倒是可以派上用場(其他討論)。然而我試了一下發現還是有些問題,主要是它仍然有可視化編輯器模式,需要提示用戶切換到源碼模式才便於輸入(否則就得用VisualEditor里編輯模板參數的界面了,unblock模板目前也沒有templatedata)。此外它不支持nosummary=1以消除標題框的功能,可以空標題提交到既有章節,但需再次確認;它還默認帶有簽名等等。
如果不大改模板的話,我覺得優化現有的文檔、引導用戶用MediaWiki:blockedtext里的preload連結申訴即可。--Srapoj(留言) 2025年9月5日 (五) 20:07 (UTC)回覆
關於源碼模式等問題,我傾向是創建獨立的header模板,然後允許用戶使用純wikitext在下方添加理由,參見上方個人討論頁沙盒的顯示方式。這樣一來,在VE上顯示的就只是一塊header加下方可以填入理由的地方,不會需要前往模板內填入wikitext。我稍後謝謝這個的草稿,以便理解。--1F616EMO(喵留言~回覆請ping~求助?) 2025年9月5日 (五) 23:51 (UTC)回覆
聽起來還行,雖然我覺得優化既有的文檔、繼續用wikitext編輯器即可(若有必要可以補一個editintro),不需要用new topic tool。--Srapoj(留言) 2025年9月5日 (五) 23:56 (UTC)回覆
( π )題外話:我這裏用帶preloadparams的連結就會讓<html>的lang變成ja,是不是又該提工單了🤦--Srapoj(留言) 2025年9月6日 (六) 00:04 (UTC)回覆
@Srapoj:User_talk:1F616EMO/沙盒這邊增加了一個封禁申訴按鈕,可以試用。至於按鈕位置,可以按舊有做法將申訴按鈕置於MediaWiki:blockedtext內。--1F616EMO(喵留言~回覆請ping~求助?) 2025年9月6日 (六) 00:09 (UTC)回覆
其實看起來還行。要做按鈕的話用mw:Extension:InputBox的type=comment/commenttitle類型、隱藏輸入框並指定它的usedt即可?
不過我覺得更重要的是讓Template:uw-block和MediaWiki:blockedtext的內容相對一致,以及也許整理一下WP:封禁申訴和WP:封禁申訴指導,不要散在兩個頁面。
或許應該徵求一下經常處理封禁申訴的管理員的意見?(感覺討論叫不到人😓)--Srapoj(留言) 2025年9月6日 (六) 00:21 (UTC)回覆
另外是否應該指示處理的人將new topic tool創建的申訴章節標題移除、使其與封禁通知處於同一二級標題下?(其實不特別有必要,但我更喜歡現在的布局)--Srapoj(留言) 2025年9月6日 (六) 00:30 (UTC)回覆
如果要「使其與封禁通知處於同一二級標題下」,可不填入preloadtitle並使用withCSS加載CSS隱藏標題輸入框。不過個人偏好分開另一章節處理,以免後面有人開啓新章節(如AFC拒絕通知、老用戶被封禁後收到的海量星章)導致奇怪的狀況發生(目前做法也有這個問題)。--1F616EMO(喵留言~回覆請ping~求助?) 2025年9月6日 (六) 00:55 (UTC)回覆
謝謝指出,我之前不知道有withCSS。不過上面提到,我測試時發現new topic tool對於未填標題的情況會彈框確認,這就沒那麼容易跳過了(除非withJS)。
如果是我,看到了會忍不住去挪討論串的順序,所以倒不覺得是很大的問題。這個修改主要目的是降低新用戶發起申訴流程的阻力吧,稍有經驗的用戶即使不熟悉wikitext應該也知道該把模板放哪兒,所以不用擔心他們?--Srapoj(留言) 2025年9月6日 (六) 01:16 (UTC)回覆
我給WP:25周年的留言按鈕用{{void}}構造了一個preloadtitle:{{subst:^|<!--请在下框留言,不要修改本框-->}}。這樣仍會在頁面內留下空的二級標題== ==,自動生成的摘要為/* {{subst:^|}} */ 新章节。我感覺若想避免彈discussiontools-newtopic-missing-title的窗頂多只能做到這樣了,留下的空標題可以事後清理。--Srapoj(留言) 2026年1月15日 (四) 06:54 (UTC)回覆

編輯請求 2025-11-21

[編輯]

有不少用戶會使用 reason 參數填寫理由。加上這個參數。--廣雅 范★ 2025年11月21日 (五) 16:09 (UTC)回覆

@范:例子?--SunAfterRain 2025年11月21日 (五) 16:59 (UTC)回覆
Special:Diff/90155952。--廣雅 范★ 2025年11月21日 (五) 17:12 (UTC)回覆
@范:嗯... 但有點頭疼欸,這個參數早就被用掉了
{{#if:{{{2| }}}|<!--
管理員複檢後填寫-->
此封禁決定的複檢已有以下結論:<br /><!--
顯示複檢結果-->
:{{#switch:{{{2}}}
|无效|無效|inv|invalid = [[File:Pictogram_voting_abstain.svg|20px|link=]]經核查封禁紀錄後,發現閣下未有被封禁。如確實或仍未能夠編輯維基百科,請連同封禁資料一併再次提交申請,以便核查及提供協助。謝謝。<br />&nbsp;&nbsp;{{#if:{{{3|{{{reason|}}}}}}|{{{3|{{{reason|您可於此列出理由}}}}}}}}<br />&nbsp;&nbsp;處理人:{{{sign|{{{4|請簽署}}}}}}
|过期|過期|expired|expire = [[File:Pictogram_voting_wait_green.svg|20px|link=]]封禁时间已到,或用户已被解除封禁。<br />&nbsp;&nbsp;{{#if:{{{3|{{{reason|}}}}}}|{{{3|{{{reason|您可於此列出理由}}}}}}}}<br />&nbsp;&nbsp;處理人︰{{{sign|{{{4|請簽署}}}}}}
|+|unblock|unblocked|accept|accepted|接受|解封|已解封 = [[File:Pictogram_voting_keep-light-green.svg|20px]]{{#if:{{{3|{{{reason|}}}}}}|基於下列理由,}}本人決定'''接受'''這位用戶的申诉並調整封禁。其他管理員可再'''[[Template:Unblock/review again|複檢]]'''此用戶的封禁,但在沒有更好的理由前,請勿輕易推翻之前的決定。<br />&nbsp;&nbsp;{{#if:{{{3|{{{reason|}}}}}}|{{{3|{{{reason|您可於此列出理由}}}}}}}}<br />&nbsp;&nbsp;處理人:{{{sign|{{{4|請簽署}}}}}}
|-|uphold blocking|decline|declined|reviewed|婉拒|拒絕|維持封禁決定|拒绝|维持封禁决定|已複检|已複檢 = [[File:Pictogram voting delete.svg|20px]]{{#if:{{{3|{{{reason|}}}}}}|基於下列理由,}}本人決定'''拒绝'''這位用戶的申诉。其他管理員可再'''[[Template:Unblock/review again|複檢]]'''此用戶的封禁,但在沒有更好的理由前,請勿輕易推翻之前的決定。<br />&nbsp;&nbsp;{{#if:{{{3|{{{reason|}}}}}}|{{{3|{{{reason|您可於此列出理由}}}}}}}}<br />&nbsp;&nbsp;處理人:{{{sign|{{{4|請簽署}}}}}}
}}
--SunAfterRain 2025年11月21日 (五) 17:18 (UTC)回覆
噢壞耶,那就拒掉吧。--廣雅 范★ 2025年11月21日 (五) 17:21 (UTC)回覆

編輯請求 2026-01-18

[編輯]
請求已處理

英文版已於2025年9月更新了此模板的圖標(相關討論)。本人提議中文維基亦追隨英文維基更新模板圖標,以此更容易理解圖標的定義,具體如下:

  • 提出申訴: →
  • 婉拒申訴: →
  • 拒絕申訴: →
  • 接受申訴: →

如有需要可移至互助客棧上作進一步的討論。本模板圖標更新後,Template:Unblock-un和Template:Unban的圖標亦需更新。

另外,請在模板中的出現的原始碼「帳戶創建者」的「帳戶」改為「帳戶」,因為在簡體字中「账」才是正確的寫法。--Shwangtianyuan 讓中國再次偉大 2026年1月18日 (日) 15:15 (UTC)回覆

@Shwangtianyuan:錯字已修正,然請不要挑戰違背站內編輯請求方針,請按照WP:RFC的流程進行,謝謝。--SunAfterRain 2026年1月19日 (一) 10:53 (UTC)回覆
我當時認為更新圖標可以不走RFC,但還是拒絕了。在這一問題上我還是尊重原則,後續我適時在客棧上作進一步的討論(因為我有一個待討論的提案所以近期不討論,另外我還有一個條目提示欠缺來源模板系列的圖標更新提案屆時會一併提交過去)。--Shwangtianyuan 讓中國再次偉大 2026年1月20日 (二) 07:17 (UTC)回覆
有意義的提案,放一下RFC與{{bulletin}}。Sanmosa 風林火山 2026年4月22日 (三) 13:57 (UTC)回覆
(?)疑問:目前模板似乎將婉拒和拒絕視為相同的結果?--象象🐘(留言|貢獻) 2026年4月22日 (三) 14:07 (UTC)回覆
婉拒 可能是代表差一點點就可以?但不是直接拒絕,我(+)支持此更改。--Jackyming(貢獻・簽名・這位編輯者是一位奶味藍🤩) 2026年4月22日 (三) 14:16 (UTC)回覆
支持所有圖標提議。另「unblock on hold」的意思是「暫緩」而不是「婉拒」,本地目前未有「暫緩」選項,如需設立新選項須另行討論,但若實現則支持上面的圖標。--1F616EMO(喵留言~求助?) 2026年4月22日 (三) 14:16 (UTC)回覆
暫停跟打勾打叉粗細有點差異啊,能否擇一統一?—— Eric Liu 創造は生命(留言・留名・學生會) 2026年4月22日 (三) 15:13 (UTC)回覆
我不清楚enwiki的討論為何沒有顧及這點,但我相信有可能是圖形構造的能見性的關係(兩條分開的直綫如果過幼容易被人忽略,但兩條相交的直綫不會。我不懂得繪製相關圖標,所以我應該沒辦法弄alternative的圖標出來了。不過如果社羣最終沒共識加入「婉拒」/「暫緩」的選項,這其實也不是甚麼問題。Sanmosa 風林火山 2026年4月23日 (四) 05:10 (UTC)回覆
(&)建議 原版本的視覺效果更加一致,但只有色彩區別,對色盲用戶不太友好;新版本整體看起來更……凌亂?如果能統一後者的風格就好了。——ZhaoFJx(論) 2026年4月22日 (三) 15:56 (UTC)回覆
你說的事情可能是「婉拒」/「暫緩」選項圖標的鍋,見上末句。Sanmosa 風林火山 2026年4月23日 (四) 05:11 (UTC)回覆
隨便看看沒想到又有新的進展了。--Shwangtianyuan 讓中國再次偉大 2026年4月25日 (六) 10:40 (UTC)回覆
@臺灣象象、Jackyming、1F616EMO、Ericliu1912、ZhaoFJx:我想先確定一下,假如本地不引入「婉拒」/「暫緩」的選項(File:OOjs UI icon pause-yellow.svg),各位是否支持更換圖標?Sanmosa 風林火山 2026年4月27日 (一) 13:39 (UTC)回覆
只要拒絕申訴的背景顏色跟着換成紅色的話就(+)支持--象象🐘(留言|貢獻) 2026年4月27日 (一) 13:59 (UTC)回覆
@臺灣象象:不反對對應底色由#FFEFD5調整為#FFDAD5。Sanmosa 風林火山 2026年4月28日 (二) 05:52 (UTC)回覆
可不引入,但亦不反對引入。--1F616EMO(喵留言~求助?) 2026年4月27日 (一) 14:01 (UTC)回覆
(+)支持更換圖標。--Jackyming(貢獻・簽名・這位編輯者是一位奶味藍🤩) 2026年4月27日 (一) 14:26 (UTC)回覆
@臺灣象象、Jackyming、1F616EMO、Ericliu1912、ZhaoFJx:補充:發現「無效」選項另有圖標(File:Appointment.svg),現提議以File:OOjs UI icon clock.svg取代。Sanmosa 風林火山 2026年4月28日 (二) 06:09 (UTC)回覆
我有想到之前為仲裁請求做的一系列圖標,即通過一個主體指出主要概念,並搭配不同的圖標以指示狀態。如果只希望使用單個元素的話,利用風格一致且選擇多樣的的Norro風格系列或許也可以?——ZhaoFJx(論) 2026年4月28日 (二) 23:27 (UTC)回覆
關於風格問題,請見Template:Unblock/testcases;您會注意到不同的狀態下,圖標有着不同的形狀和粗細,看起來就會很雜亂,且與背景並不搭配。——ZhaoFJx(論) 2026年4月28日 (二) 23:39 (UTC)回覆
但OOUI系圖標勝在簡單易明,而且不同狀態下的圖標本就不會同時顯示,在不會同時顯示的情況下,使用模板的用戶理論上不該感覺「雜亂」,我倒是認為所有狀態都放時鐘圖標意義不明。「與背景並不搭配」可能只是你的個人感覺,我自己倒是沒甚麼違和感。Sanmosa 風林火山 2026年4月29日 (三) 01:15 (UTC)回覆
我剛才有找到一組風格上可能更一致的圖標集,還請參考。——ZhaoFJx(論) 2026年4月28日 (二) 23:47 (UTC)回覆
我剛才又按照前文提到的主副組合做了一套()——ZhaoFJx(論) 2026年4月29日 (三) 00:07 (UTC)回覆
File:Hourglass icon (orange).svg與File:Unblock waiting.svg都是橙色的,與現時默認的藍色底色不一致。Sanmosa 風林火山 2026年4月29日 (三) 01:17 (UTC)回覆
我已將顏色替換為與File:Appointment_blue.svg邊框一致的淺藍色,請復檢。——ZhaoFJx(論) 2026年4月29日 (三) 01:50 (UTC)回覆
建議把「接受」的圖標改成打鈎(checkY),現在的版本很容易被理解為「回復」。--Ascchrvalstr(留言) 2026年4月29日 (三) 07:32 (UTC)回覆
已修改,還請檢查。——ZhaoFJx(論) 2026年4月29日 (三) 12:38 (UTC)回覆
我認為「默認」的沙漏應該完全豎直而不是歪一個小角度,除此以外(+)支持。--Ascchrvalstr(留言) 2026年4月29日 (三) 13:54 (UTC)回覆
我擔心豎着的話會不會太呆板了?——ZhaoFJx(論) 2026年4月29日 (三) 15:12 (UTC)回覆
應該不會。Sanmosa 風林火山 2026年4月30日 (四) 12:33 (UTC)回覆
@ZhaoFJx:剛才另外發現一個事情,就是File:Hourglass icon (orange).svg與File:Unblock waiting.svg的底色(白色)與其他圖標的底色(灰色)不一致。Sanmosa 風林火山 2026年4月30日 (四) 12:33 (UTC)回覆
我看ZhaoFJx的方案挺好--Luoniya(留言) 2026年5月24日 (日) 05:20 (UTC)回覆
(+)支持英文維基百科的無邊框圖標--Sksawf(留言) 2026年5月13日 (三) 07:50 (UTC)回覆
(+)支持改用英維圖標。原圖標僅採用顏色區分,對視障人士(如色盲與色弱)非常不友好。--Nebulatria 2026年5月17日 (日) 19:26 (UTC)回覆
@Ericliu1912、ZhaoFJx:有鑒於最近新增的意見支持我的方案,容我再確認兩位的意見。Sanmosa 風林火山 2026年5月23日 (六) 06:19 (UTC)回覆
補ping@Ascchrvalstr。Sanmosa 風林火山 2026年5月23日 (六) 06:19 (UTC)回覆
兩種修改方案對我來說都可以接受(但是「無效」的圖標可能還是ZhaoFJx的更好一些)。--Ascchrvalstr(留言) 2026年5月23日 (六) 07:05 (UTC)回覆
完成--百無一用是書生 (☎) 2026年5月24日 (日) 12:00 (UTC)回覆
已經在討論頁上看到了全新版本的圖標。--Shwangtianyuan 讓中國再次偉大 2026年5月25日 (一) 14:02 (UTC)回覆

編輯請求 2026-04-01

[編輯]
請求已處理

將尤其是在用戶受到永久封禁的情況下。改為尤其是在用戶受到不限期封禁的情況下。。--Ascchrvalstr(留言) 2026年4月1日 (三) 12:18 (UTC)回覆

@Ascchrvalstr:沒有討論過請不要提前開編輯請求。--SunAfterRain 2026年4月2日 (四) 02:48 (UTC)回覆
上述字眼修改應爲基於現有用詞共識的事實性修訂,應屬於「會輕微影響使用方式和外觀顯示的編輯」,私以爲可按Wikipedia:保護 § 需進行公示立刻交付公示處理。--1F616EMO(喵留言~求助?) 2026年4月2日 (四) 06:38 (UTC)回覆
@SunAfterRain、1F616EMO:你們倆對條文的理解都是錯誤的。社羣當時的共識認定的是「永久封禁」這種用法是錯誤的,這個修訂屬於WP:保護#可立即進行所稱的「修正明顯的標記錯誤」。Sanmosa 風林火山 2026年4月2日 (四) 15:49 (UTC)回覆
閱讀Wikipedia talk:封禁/存檔6 § 重修封鎖方針及Wikipedia talk:封禁/存檔6 § 還有必要稱呼「永久封鎖」嗎?後,同意社羣認爲「永久封禁」具有誤導性,並因此達成不應在方針、指引及程序性頁面、模板中使用此稱呼的共識。--1F616EMO(喵留言~求助?) 2026年4月3日 (五) 02:51 (UTC)回覆
回@Sanmosa,提交者沒有指出這點,並且我早時也不知道你所謂的共識是什麼,當下直接駁回我覺得非常合理。--SunAfterRain 2026年4月4日 (六) 15:26 (UTC)回覆
完成,基於Wikipedia:保護#可立即進行。 2026年4月3日 (五) 08:24 (UTC)回覆

編輯請求 2026-04-28

[編輯]
請求已處理

請將第一行中(--background-color-disabled, #D9D9D7)前,var後的空格刪掉,當前版本是錯誤的語法。 Stang998 2026年4月28日 (二) 07:03 (UTC)回覆

@Stang:完成。倒是您也可以直接申請個模板編輯員( —— Eric Liu 創造は生命(留言・留名・學生會) 2026年4月28日 (二) 11:28 (UTC)回覆