维基百科:互助客栈/其他

互助客棧： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

发表新议题

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

公告欄

• [公告] 请汇报由于新近上线的安全措施而工作异常的用户脚本。
• [公告] 取消人物生日分類、廢除醫學可靠來源指引有關醫學資訊的落日條款、啟用提醒使用archive.today的過濾器、廢除大量帳號創建者的方針地位及確立WP:模板命名空間為指引已經通過。
• [公告] 事实性修订快速刪除方針G14條的條文、事实性修订快速刪除方針A7條的條文、事实性修订快速刪除方針R8條的條文、事实性修订快速刪除方針R10條的條文及微調有關非管理員關閉存廢討論的規則的提案已因屬現實性對應調整或未實際更動方針指引的有效用詞而立即通過。
• [公告] 常見有爭議來源列表新格式、將分類名稱中的「撤消」更正為「撤銷」、修改同行評審存檔程序及调整“维基百科不是水晶球”的早期翻译正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論2027丁未年新年标志联合票选，歡迎踴躍參與。
• [討論] 社群正在討論有關非編號命名的城市軌道交通鐵路綫的條目命名、確立列表收錄標準為正式指引、检讨不限期封禁的用户页标记、有關國際學校導航模板的命名、仲裁委員會組織調整、活動組織者該由行政員還是管理員賦權、昆虫专题问题、修訂資訊框格式手冊有關表示國籍與公民權的規定、取消快速刪除方針G14條的14日等待期、停止人工解除隐退用户的多余权限、簡化命名常規與格式手冊的命名、「合理使用」改為「非自由內容」並提升為指引及尚在规划的城市轨道交通线路是否应独立成文，歡迎踴躍參與。

• [協作] 现有180个页面需维基化，671个条目需清理，16个移动请求正在讨论。
• [獎勵] 現有2名用户獲提名维基奖励，欢迎投票。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	维基百科25周年	1	1	Jimmy-bot	2026-03-24 16:14
2	西班牙月的请求	34	9	Zyx20101210	2026-02-28 01:26
3	Archive.today二三事	181	27	臺灣象象	2026-03-20 19:46
4	2027丁未年新年标志联合票选	63	8	魔琴	2026-03-19 15:14
5	关于之前按笔画分栏功能的设想	10	5	Kanashimi	2026-03-20 05:32
6	是否應對每日創建條目的數量、頻率予以限制？	23	9	糯米花	2026-03-19 15:56
7	用户白洲梓的編輯	10	4	YFdyh000	2026-03-23 03:44
8	维基登录	1	1	12З4567	2026-03-19 11:00
9	新聞動態用詞	7	3	YFdyh000	2026-03-24 02:03
10	求真百科	1	1	1F616EMO	2026-03-21 19:58
11	以後能用的參考來源會不會變得有限？	2	2	Ericliu1912	2026-03-23 14:37

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面 或完成討論之議題
手動設定
當列表出現異常時， 請先檢查設定是否有誤

正在廣泛徵求意見的議題

議題清單

以下討論需要社群廣泛關注：（重新整理） 維基專題與協作

Wikipedia:互助客栈/其他 § 西班牙月的请求

我希望可以召开第24届动员令，主题为：西班牙，用于完善西班牙相关条目缺失和有量无质的缺点，大家有什么意见吗？--Zyx快困死了 2026年1月29日 (四) 10:00 (UTC)

Wikipedia talk:可靠来源/常见有争议来源列表 § 新RSP格式

新RSP格式已完成，索引頁在此：Wikipedia:可靠來源/常見。預計索引頁中的列表和搜尋框將嵌入到Wikipedia:可靠来源/常见有争议来源列表以替換原表格。存檔方式等資訊，可以就直接放在各個頁面裡面（開個「存檔」章節）。已有的頁面也可以補充收錄電子遊戲專題、ACG專題的來源評語（例如Wikipedia:可靠來源/常見/17173.COM）。雖然RSP只是論述，但還是需要來個徵求意見，讓大家再討論看看。Ping「收錄存檔資訊」一事的討論參與者：@1F616EMO、Ericliu1912、Liu116、Olaf8940、Sksawf、YFdyh000、魔琴。--SuperGrey (留言) 2026年3月3日 (二) 14:44 (UTC)

Wikipedia:可靠来源/布告板 § 大紀元時報的來源是否可靠？

• 狀態：   讨论中
• 過往討論連結：2025年11月、2025年6月、2024年10月
• 來源1：https://www.epochtimes.com/ 、網址：epochtimes.com

  链接搜索	原文搜索
  Google	域名Whois

• 條目：大紀元時報
• 內容：有資深編者認為大紀元時報都列為不可靠是不妥的，因此想再次重新討論是否上調至 應替代，或是以不同年份區分可靠性、確認臺灣人文領域的報導品質與可靠性等。
• 提交的維基人與時間：英國皇家歐拉夫王子（留言） 2026年3月7日 (六) 12:56 (UTC)

Template talk:昆虫专题 § 昆虫专题问题

我前几个小时内，试图走页面存废讨论，删除模板:昆虫专题，理由是昆虫专题并未实际存在，然而有用户认为该模板在超过两千个页面被使用，不宜被提删。

然而，我认为昆虫专题完全可以被现有生物专题所涵盖，且昆虫专题就算建立也难以维护，因此彻底废除该模板才是适宜的。

以上。--Luoniya（留言） 2026年3月7日 (六) 15:18 (UTC)

Wikipedia:互助客栈/方针 § 再次提议“特色列表”改名

此案久無共識，是否考慮整理命名提議，然後定期表決？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月16日 (一) 11:30 (UTC)

西班牙月的请求

原标题：第24届动员令的请求

我希望可以召开第24届动员令，主题为：西班牙，用于完善西班牙相关条目缺失和有量无质的缺点，大家有什么意见吗？--Zyx快困死了 2026年1月29日 (四) 10:00 (UTC)

辦西班牙編輯松吧。動員令是7到9月辦的，而且不會限定主題。--象象🐘(留言|貢獻) 2026年1月29日 (四) 12:07 (UTC)

其實可以現在討論，畢竟動員令所訂主題需要長時間討論得出共識。（可發本站社群通告）--Sinsyuan✍️PJTW 2026年1月29日 (四) 13:41 (UTC)

也可以，毕竟现在要求是快速提升条目质量--Zyx快困死了 2026年1月29日 (四) 13:46 (UTC)

那就办西班牙编辑松了，我要找人来讨论吗--Zyx快困死了 2026年1月29日 (四) 13:46 (UTC)

@Ericliu1912@魔琴--Zyx快困死了 2026年1月29日 (四) 14:46 (UTC)

二位有什么见解吗？--Zyx快困死了 2026年1月29日 (四) 14:46 (UTC)

@Zyx20101210我的想法是用西班牙專題的名義辦西班牙編輯松，並由數位使用者擔任主持人。由參與者以某個方式提交條目，並要求提交的條目符合一定的標準。此處的標準或許可以使用新條目推薦標準。參與者提交的條目由主持人審核，並訂出一定的計分標準，結束後再由主持人授予頭銜或其他獎勵。--象象🐘(留言|貢獻) 2026年1月29日 (四) 15:08 (UTC)

主要问题是现在西班牙专题就我一个人--Zyx快困死了 2026年1月29日 (四) 15:10 (UTC)

社群会西班牙语的太少了，还很多都不活跃1--Zyx快困死了 2026年1月29日 (四) 15:11 (UTC)

@臺灣象象我可以自荐成为主持人吗--Zyx快困死了 2026年1月29日 (四) 15:12 (UTC)

當然可以啊--象象🐘(留言|貢獻) 2026年1月29日 (四) 15:12 (UTC)

另外還要決定的是編輯松的時間--象象🐘(留言|貢獻) 2026年1月29日 (四) 15:17 (UTC)

2月初至3月1日？--Zyx快困死了 2026年1月29日 (四) 15:29 (UTC)

應該可以--象象🐘(留言|貢獻) 2026年1月29日 (四) 15:31 (UTC)

建议从2月8日开始，刚好我的考试结束--Zyx快困死了 2026年1月29日 (四) 16:09 (UTC) 👌1

還有可以用維基百科廣告宣傳--象象🐘(留言|貢獻) 2026年1月29日 (四) 15:20 (UTC)

维基百科:西班牙月--Zyx快困死了 2026年1月29日 (四) 15:28 (UTC) 👍1

这个是我仿照照抄第十届动员令的主页做的主页--Zyx快困死了 2026年1月29日 (四) 16:11 (UTC)

@Zyx20101210：既然社群编写西班牙主题条目的人太少，那就先不要搞这种编辑松。更何况你现在能力也不够，那还不如去干别的有意义的事情，比如提升条目编写能力和阅读条目的能力。--Nishino⭐Asuka 2026年1月29日 (四) 20:24 (UTC)

那拉倒吧，我写的模版留到下次用。。。--Zyx快困死了 2026年1月29日 (四) 20:36 (UTC)

那就换成西班牙文主题，联合拉美专题的一起办--Zyx快困死了 2026年1月29日 (四) 20:39 (UTC)

这样人多一点，我也不用累死累活写模版了--Zyx快困死了 2026年1月29日 (四) 20:39 (UTC)

@Zyx20101210：首先据我所知，你维目前还没有勤于且善于编写西班牙主题条目的编者，倘若现在发起编辑松可能很难达到预期的理想效果；其次鉴于讨论发起人在编写拉斯罗萨斯德马德里条目过程中的表现，我怀疑其目前尚不具备主持编辑松所需的编辑水准和审核能力。--Nishino⭐Asuka 2026年1月29日 (四) 20:10 (UTC)

@Nishino Asuka有但是退休了。。。导致整个专题就我一个人。。。--Zyx快困死了 2026年1月29日 (四) 20:40 (UTC)

残念，勤於且善於編寫西班牙主題條目的編者=無，勤於且善於編寫墨西哥、阿根廷等中南美洲國家主題條目的編者=有。--鬼殺隊名誉隊員Allervous 2026年1月31日 (六) 04:33 (UTC)

对的😭😭😭--Zyx快困死了 2026年1月31日 (六) 11:37 (UTC)

我還是倾向多關注中南美洲。--鬼殺隊名誉隊員Allervous 2026年1月30日 (五) 01:51 (UTC)

無論如何，既然已經打算改辦編輯松的話，請先改一下標題吧。--AT⊿⁴⁶ 2026年2月1日 (日) 07:03 (UTC)

以國別辦編輯松並非沒有先例，但成效恐怕需要打個問號。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月3日 (二) 20:07 (UTC)

所以要找南美专题的，因为西班牙专题就2个活跃用户，总共3个人--Zyx快困死了 2026年2月3日 (二) 20:11 (UTC)

那我建议可以在今年拉美月的时候搞点特别活动，允许参赛选手写西班牙、葡萄牙主题这样的？你如果有精力的话，或许也可以考虑一下联系西班牙语维基社群，和他们合作？--FradonStar^{新春倒计时⏱️} 2026年2月8日 (日) 17:04 (UTC) 👍1

依稀記得其他語種的拉美月fountain單一條目計分可以超過1分（法維好像有單一條目破百分過），或許今年拉美月可以仿照動員令分大中小主題，然後分數依比例增加。但這在設定fountain時可能要多下點功夫--Kanshui0943（留言） 2026年2月21日 (六) 15:08 (UTC)

@Allervous，Ericliu1912，AT,FradonStar，Kanshui0943，Nishino Asuka，臺灣象象:我已经向西班牙语社群提交了联合举办的讨论，静待后文吧。--Zyx快困死了 2026年2月27日 (五) 17:26 (UTC)

Archive.today二三事

一般討論

Archive.today是和Wayback Machine齊名的網站存檔服務，儘管後者現在用的更多，但是前者有其無法替代的好處。特別的，Wayback Machine現在無法保存Twitter/X的推文，Archive.today可以。此外，Archive.today還可以生成網站的螢幕擷取，而Wayback Machine有時會因為各種原因出現不正確的網頁排版。

在技術上，Archive.today與Wayback Machine的主要區別在於，後者會運作自動化的網站爬蟲主動抓取網站，而前者完全依賴使用者指令而不運作機械人。前者由此得以不受robots.txt規範。

最近，Archive.today陷入爭議狀態。

當事人gyrovague的說法[1]

在2023年，個人博客gyrovague.com撰寫了一篇深度解析Archive.today運作的文章，結果導致Archive.today在2025年被盯上。FBI給網域名稱註冊商發傳票要求交出Archive.today運營者的資料；還有法國組織要求DNS服務提供者阻斷對網址的解析。Archive.today對此的回應是，首先請求gyrovague.com下架文章，被拒絕後，他們選擇了DDoS。

截至現在，任何訪問Archive.today網站的請求，若被要求完成CAPTCHA，都會自動向gyrovague.com發送請求，形同DDoS。新世代的網友們可能沒有相關的記憶，但是推薦大家去讀一讀大炮 (网络攻击工具)條目感受一下這是何等惡劣之行為。

某第三方的說法[2]

在2023年，gyrovague公開doxx了Archive.today站長的資料。

2025年FBI盯上了Archive.today，這件事被媒體報導，並且媒體的報導連結到了這篇涉嫌doxx的文章。

到了2026年1月8日，其中一個被doxx的人「獲得了歐盟的公民權」，引用GDPR向託管博客的Wordpress發出下架文章的請求，結果gyrovague説「在我自己管理的博客中下架我自己發表的文章這件事情是我做不到的」，然後用Gemini生了一篇大談特談doxx他如何對公眾有益的抗辯書，Wordpress接受了。

截至1月9日Archive.today已連續2到3個月發郵件請求gyrovague下架文章，但是依舊毫無回音，所以開始DDoS。直到1月15日gyrovague「在垃圾郵件中發現了請求」然後回文問「我該刪除什麼資料」

但是Archive.today沒有回覆。所以到1月25日gyrovague便自作主張認為「我不可能全文下架」然後對Archive.today説「你不停止你的DDoS的話我就要再發一篇文章，我現在就給你看看我準備發什麼」。

1月26日，Archive.today憤怒指責gyrovague唯一的回應就是那篇用Gemini生產的AI文，然後徹底與gyrovague撕破臉。Archive.today威脅用gyrovague真實姓氏做一個同性戀約會App，還要寫一篇深度調查gyrovague祖父的納粹背景的調查文。

gyrovague極度厭惡別人doxx他，同時也享受doxx對方的快感。

英維現正辯論是否應當據此將Archive.today拉入黑名單。目前的風向個人感覺是同意拉黑，有可能會全域拉黑，但是很明顯拉黑後的負面影響也是明顯的。我們或應討論對策。

• → 英維RFC
• → 德維討論
• → 西維討論

--MilkyDefer 2026年2月18日 (三) 17:11 (UTC)

个人倾向再等待一阵，观察事态变化。个人不反对无效化链接或弹出警告以降低可能的影响，但仍倾向为部分用户（如注册用户/脚本使用者/直接读取源码）留下使用的口子而非源码中直接移除。我目前可以重现该行为，且现在为setInterval(function(){fetch("https://gyrovague.com/tag/"+Math.random().toString(36).substring(2,3+Math.random()*8)+"/",{ referrerPolicy:"no-referrer",mode:"no-cors" });},400);，未见事态缓和趋向，令人遗憾。--YFdyh000（留言） 2026年2月18日 (三) 17:46 (UTC)

也許讀者點擊Archive.today相關連結時，會彈出一個視窗提示那個網站的安全性存在問題？或許可平衡安全問題以及存檔的便利性？--SCP-0000（留言） 2026年2月19日 (四) 03:00 (UTC)

我倾向于反对拉黑，毕竟我就大量使用过Archive.today来存档链接，Archive.today和Wayback Machine是互补的，Archive.today可以阻止可能导致混乱的JS脚本的运行，Wayback Machine在个别页面当中可能一开始能够正常显示内容，但过了一段时间受JS脚本的影响跳转到404，或者排版变得混乱。虽然Archive.today之外还有一个megalodon.jp，然而megalodon.jp限制每个IP在24小时内只能存档60个页面，相当麻烦。提醒Archive.today存在的风险是可以考虑的。--#MilanoCortina2026Day13 2026年2月19日 (四) 10:08 (UTC)

能不能先行統計本站（中文）有多少Archive.today連結？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月19日 (四) 13:05 (UTC)

其他維基踴躍參與但我們中維參與的意義是？Wayback Machine時不時被炸已經夠糟了要是封禁Archive.today還剩下什麼資源可以用？我們至少分析完中維使用Archive.today的程度再來探討是否封禁 --窝法乙烷 儿法梦碎 2026年2月19日 (四) 13:42 (UTC)

通過搜尋可知，目前約有五萬個頁面有提及archive.today。稍後將在XML匯出檔案中進行統計。--1F616EMO（喵留言～求助？） 2026年2月19日 (四) 14:23 (UTC)

根據c:Data:Wikipedia_statistics/exturls.tab，截至本月初，共有88963個連結。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:35 (UTC)

@MilkyDefer、YFdyh000、SCP-2000、Liu116、Ericliu1912、Milkypine：英維的共識及相關發現：

1. 英維編者確認此網站確實正在進行DDoS攻擊，違反Wikipedia:外部链接 § 正常情況下應避免的連結第二點（英維爲第三點）「含有……惡意腳本……的內容」。
2. 英維編者另確認此網站正修改其存檔，以致其可靠性蕩然無存，已不宜當作忠實的存檔網站。
3. 支持保留此網站的編者多從內容的（長遠）可供查證性着手論述，然而英維調查發現75%的內容都可以從其他存檔網站中重新獲取。
4. 綜上，英維決定儘快將archive.is加入垃圾連結黑名單或過濾器，並以完全取締archive.is爲最終目標。英維編者正在討論相關技術配套。

--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:42 (UTC)

個人論述：en:Wikipedia:Requests for comment/Archive.is RFC 5#c-1F616EMO-20260219155700-Survey break 5，大致和最終共識總結吻合，可供參考。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:43 (UTC)

關於中維，私以爲取締archive.is已無可避免，問題是應如何搶救含archive.is存檔的來源（注意我們絕不能信任archive.is現存的任何內容），儘量尋找互聯網檔案館的對應存檔取代現有archive.is的存檔。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:46 (UTC)

以提示彈窗（或者類似方式）提醒讀者網站的安全性，以及利用過濾器建議編者使用其他存檔服務，個人認為上述是現階段較為切實可行的做法。而同時間，可逐步更換存檔為 Wayback Machine或其他服務。謝謝。--SCP-0000（留言） 2026年2月20日 (五) 06:07 (UTC)

短期內同意如此，額外建議禁止加入新的archive.is來源而非僅建議，另可使用專用過濾器而非通用垃圾連結過濾器以提供專門的提示信息。長遠而言，仍建議取締archive.is，具體操作可等待英維技術方案出臺。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:17 (UTC)

已依照英維建立過濾器。如果社群達成共識可隨即啟用。--SCP-0000（留言） 2026年2月20日 (五) 07:09 (UTC)

考慮到需要測試，以及以便社群了解使用情況，故先行啟用，但不會採取任何動作。--SCP-0000（留言） 2026年2月20日 (五) 07:41 (UTC)

只要有https://www.rias.org.sg/rias-top-charts/、https://www.rias.org.sg/the-official-singapore-charts/內容，我不介意立刻啟用。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:39 (UTC)

提醒不要使用不代表禁止使用，如果有需要仍然可以使用的。不太理解您的疑慮是什麼。謝謝。--SCP-0000（留言） 2026年2月20日 (五) 12:17 (UTC)

1F616EMO大的回覆怎麼看都不是這個意思。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 15:08 (UTC)

我確實主張完全禁用，不過短期內可以先警告而暫不禁用。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 15:09 (UTC)

英維個人論述摘錄：

Don't be trapped in the mindset that we gotta have some sources for our texts. Sources come before texts, not the other way around. Even if we have some texts that we almost certainly believe are true, if verifiability cannot be fulfilled, we shall not move the goalposts; instead, we are left with no choices but to remove them. Therefore, "how come can we remove such a widely-used source" in itself is not a proper concern, and therefore would not be considered in consensus concluding.

---

切勿墮入「總要有些來源來支撐我們的條目內容」的思維陷阱。來源的考慮先於條目內容，而絕不可反其道而行之。即使我們確信目前的條目內容是真實的，若可供查證不再能被滿足，我們也不可以搬龍門、修改我們的原則，而只能移除相關內容。因此，「怎麼能封鎖這樣一個廣爲使用的存檔網站」本身並非正當合理意見，並因此難以在共識總結中被考慮。

--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:18 (UTC)

据我的编辑经验，在中国大陆，微信公众号、部分地方政府、百度百家号是无法被IA正确存档的，会被跳转到真人验证的界面。但today在这方面运行良好，可以正确存档大部分界面并保留网站的多媒体内容。早晨尝试使用ghost网站存档，多媒体内容无法被正确加载。目前这几个平台的存档没有替代品，尝试了套娃请求被IA拒绝。--YikyuenG~速速点击 2026年2月21日 (六) 05:53 (UTC)

知乎、小红书也无法用互联网档案馆存档，Archive.today时灵时不灵--Sksawf（留言） 2026年2月21日 (六) 12:05 (UTC)

仍旧建议现阶段仅提示用户相关风险而非一刀切禁止，最近正逢冬奥的举办，然而奥运官方网站Olympics.com大概在上个月月底的时候将Wayback Machine的IP禁了，导致这段时间一尝试使用Wayback Machine存档Olympics.com的内容便会提示403。megalodon还是那句老话，每个IP在24小时内只能存60个网页不方便。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:35 (UTC)

#c-1F616EMO-20260220061800-1F616EMO-20260220054600。確實不方便，但也沒辦法。另不反對短期內只警告而暫不完全禁制，惟應同時開始將archive.is存檔連結轉移爲使用其他存檔服務（參見英維操作指南），長遠（或後續討論）應以完全禁止並取締所有連結爲目標。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 07:42 (UTC)

(～)補充：我也反对现阶段禁止加入新的archive.today存档链接（警告为主足矣），除非能找到和archive.today一样能够阻止存档网页运行JS脚本（megalodon已经排除在外不再赘述），且比archive.today更为可靠的网页存档服务，或者建议Wayback Machine为用户提供禁止存档网页运行JS脚本的选项。我毕竟也是大量使用存档链接的，我很清楚过往archive.today和Wayback Machine之间所展现的互补作用，禁掉archive.today对我的影响很大，我就是因为发现Wayback Machine一些不可靠的地方（例如一个网页存完档之后过几天却提示该网页无存档）所以有时需要改用archive.today。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:51 (UTC)

还有需要考虑一种情况，就是部分网页几年前早已失效，翻archive.today有存档，但是Wayback Machine却没有存档。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:59 (UTC)

關於這一點，還是#c-1F616EMO-20260220061800-1F616EMO-20260220054600。這種情況下，由於archive.is已非忠實的存檔網站，其地位與自行出版來源無異，故唯有遺憾移除內容。同意不立刻取締archive.is，這樣可以爭取時間尋找是否有其他地方有存檔或相等來源。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 08:01 (UTC)

可以考虑针对能在Wayback Machine里存档且显示正常的网页，尽量用Wayback Machine取代，实在无法取代的，自行检查具体的存档内容，查实存档内容遭修改的，移除相关存档，未修改的暂时保留。PS：近些年来响应式布局的广泛使用已经是对网页存档越来越不友好，另外部分网页在Wayback Machine是不能绕过付费墙的，但在archive.today却可以，恕我无法认同你在上面所引用的话的那种近乎一刀切的思维，除非Wayback Machine本身能够改进以便有能力完全取代archive.today（75%对我来说还是不够，就我自己写条目加存档的经历，得至少90%-95%以上），现阶段即便archive.today已被查实存在不可靠的地方，在取代该类存档链接的问题上仍需谨慎！--#MilanoCortina2026Day14 2026年2月20日 (五) 08:07 (UTC)

問題是對archive.today的信任已基本降至零，原則上我們難以將archive.is上被存檔的可靠來源按原先的可靠度使用。若人工檢查過內容無誤，建議在別處對該存檔進行存檔（已知megalodon可以這樣做；archive.is的robots.txt並無阻止其他存檔服務反存檔其存檔，相信也存在其他存檔服務可以這樣做），以免後續存檔再被修改。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 08:18 (UTC)

虽然不认同对archive.today的信任已降至零那么夸张的说法，但不反对套娃（如果可行），不过对于archive.today的取代绝不能想着很快就能够完成。--#MilanoCortina2026Day14 2026年2月20日 (五) 08:27 (UTC)

同意棄用需時，且看英維怎麼處理吧。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 09:29 (UTC)

别的语言版本怎么处理只能做参考，这边具体如何处理根据实际情况来，我是认同能取代的尽量取代，先最小化archive.today的使用，至于后面新增的存档链接，应该视乎情况而定，如果该来源能够用Wayback Machine或Megalodon存档，且存档页面没有明显的问题（例如排版及JS脚本跳转之类的），可以禁止使用archive.today。--#MilanoCortina2026Day14 2026年2月20日 (五) 09:37 (UTC)

我說的參考英維，主要是參考他們如何半自動取代現有的archive.today連結，以及是否存在完全取締的可能性，而非無腦照抄他們的共識。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 09:38 (UTC)

基金会早应该自己建一个网页存档服务。在他们会这么做之前，反对将archive.today纳入黑名单，因为这些存档链接是对读者有价值的资讯。维基百科完全不应该介入这种事情，不要替读者做选择。--PexEric 2026年2月20日 (五) 10:12 (UTC)

这样有法律和版权风险吧…基金会一向对非自由内容很慎重。--GrandCeres（留言） 2026年2月20日 (五) 10:28 (UTC)

既然archive.today會修改以往存檔，該網站恐怕已無法滿足提供網站以往版本的忠實複製品的需求。注意我們的讀者只會在乎符合可供查證要求的來源。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 10:41 (UTC)

我看你一直提这事情，我倒是有几个疑问了：1、archive.today改了多少存档？2、archive.today改的存档，主题大致上涵盖哪些方面的？3、archive.today改这些存档各自动机能否推测出来是什么？我没那么多时间仔细翻查英文那边的讨论，而且有的人也不懂英文。如果说archive.today人为篡改存档所涉及的范围较小、涵盖的主题与动机都是涉及特定的利益冲突，那么现阶段顶多最低限度使用即可，能替换则替换（至少对于不涉及其利益冲突的算是如此），如果archive.today站长是心血来潮纯粹搞破坏，而且短时间内造成较大的影响，就算是我都会同意马上行动直接将archive.today给整个ban掉，并快速推进替换。搞这些东西毕竟工作量不小。--#MilanoCortina2026Day14 2026年2月20日 (五) 11:22 (UTC)

問題不是改了什麼，而是曾經改過，以至於其信任已經被破壞。關於具體（被發現）改了什麼，可參考英維討論，目前來說是幾個博客網站。存檔網站的使命是忠實地存檔網站以往的狀態；正如維基百科如果放棄了可供查證就不再是維基百科一樣，對以往存檔進行任何修改都代表該網站不再是一個存檔網站。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 11:42 (UTC)

是後來又在改過嗎？點進去沒看到sapphaline說的Jani Patokallio。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:53 (UTC)

抱歉挖坟，但是的：en:Special:GoToComment/c-Aaron_Liu-20260219182800-Evidence_of_altering_snapshots，之后就又恢复了正常 Aaron Liu（留言） 2026年3月10日 (二) 20:54 (UTC)

链接打不开--Sksawf（留言） 2026年3月11日 (三) 01:37 (UTC)

https://en.wikipedia.org/wiki/Special:GoToComment/c-Aaron_Liu-20260219182800-Evidence_of_altering_snapshots--Sksawf（留言） 2026年3月11日 (三) 01:37 (UTC)

抱歉，应该好了 Aaron Liu（留言） 2026年3月16日 (一) 01:16 (UTC)

具体改了什么，什么样的范围，以及出于什么目的去改的就应该是更需要关注的问题，这些还是会影响到我们如何处置此事。我看Milkypine君贴出了Archive.today的Tumblr页面了，上面有提到近期维基百科的事情。就连Wayback Machine也不能完全排除因为外部压力或黑客攻击的因素，而导致一些网页存档遭到删除或者调整的情况。--#MilanoCortina2026Day14 2026年2月20日 (五) 12:05 (UTC)

英維有提到主要的替換是將 Nora 替換為了 Jani Patokallio，有猜測這是賬戶匿名化的實現的副作用，即使使用該特定的使用者姓名有可能帶有個人恩怨（見前文）的成分存在

由於並未有出於破壞內容的初衷修改正文內容的證據，我並不認為這造成了可供查證/可信性質的失去。 另外希望 1F616EMO 能夠 Wikipedia:假定善意 並且避免情緒化的語言。--EdwardWW（留言） 2026年2月22日 (日) 04:10 (UTC)

關於基金會存檔：英維也有討論過，可供參考：:en:Wikipedia:Requests for comment/Archive.is RFC 5 § Migrating or cloning archives。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 10:43 (UTC)

先解决archive.today的替换存档（无论用Wayback Machine还是基金会应该自己也搞一套专用的参考页面时光机）并落实下来，再考虑完全替换archive.today的问题，实务而非立场先行。先观望en打算怎么替换掉archive.today的方案。——Sakamotosan路过围观 | 避免做作，免敬 2026年2月20日 (五) 11:55 (UTC)

故事主角Archive.today在Tumblr文章沒人轉，就連中共相關條目都有相應的中共意見，這邊是不是該提一下？ --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:39 (UTC)

講真，維基真的該有自己网页存档服务，而不是一邊認為有法律和版权风险還一邊用「任何」存檔服務。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:46 (UTC)

真要较真的话，Wayback Machine也有风险，还记得2024年10月遭到攻击导致关站多日的事情，如果Wayback Machine不能解决自己的安全问题，导致其在黑客面前显得脆弱，我们照样也可以觉得Wayback Machine不可信任。从这个角度上来说，我也认同基金会应该自己搞一个网页存档服务。--#MilanoCortina2026Day14 2026年2月20日 (五) 11:58 (UTC)

虽然也算是信息安全，然而网站被打到掉线与被挂马或数据泄露的严重性不能混为一谈[3]。2024年那次Internet Archive虽说后来也被拖库了，然而那起data breach对于仅浏览的用户来说没什么影响。--Srapoj（留言） 2026年2月21日 (六) 13:24 (UTC)

PS.gyrovague “开盒”了Archive.today（运营者的真人信息），Archive.today被政府“骚扰”，Archive.today有人申请“删盒”，gyrovague 以“不知道要删什么”来推脱拒绝，结果Archive.today上技术“反击”，不过Archive.today“Archive.today威胁用gyrovague真实姓氏做一个同性恋约会App，还要写一篇深度调查gyrovague祖父的纳粹背景的调查文。”还有改存档记录的这个事，可能会过火吧。不过“gyrovague极度厌恶别人doxx他，同时也享受doxx对方的快感。”嘛——"煽っていいのは　煽られる覚悟があるやつだけだ"。——Sakamotosan路过围观 | 避免做作，免敬 2026年2月20日 (五) 11:55 (UTC)

已向MediaWiki talk:Spam-blacklist、Wikipedia:防滥用过滤器/过滤器请求發送討論邀請。TalkInvite1F616EMO（喵留言～求助？） 2026年2月20日 (五) 13:42 (UTC)

我覺得即使1F616EMO提到的事情可能為真，但範圍不至於即時包含所有存檔頁面，過度擔心大可不必；故仍然希望先行確認「竄改」問題具體規模，以及是否僅針對特定人士或其網站，更不太希望即時禁止新存檔（警告則可行）。這方面我同意Liu116的意見（一、二）。副知@1F616EMO、SCP-2000。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月20日 (五) 15:55 (UTC)

無論最終是否以完全取締爲目標，同意先採取警告而不禁止的方式，是否取締容後再議。--1F616EMO（喵留言～求助？） 2026年2月21日 (六) 06:56 (UTC)

Nora 很可能是Archive.today站长的马甲之一

被篡改存档的那个博客，评论要求必须是“Only a member of this blog may post a comment”

那个被篡改的字样，本身是“还没发的评论的用户名”

因此Nora 应该是Archive.today抓取那个博客时使用的Cookie

另，中文互联网上2024-04-15有自媒体转载并补充了gyrovague（Jani）的分析， https://zhuanlan.zhihu.com/p/692514189

--Sksawf（留言） 2026年2月21日 (六) 07:22 (UTC)

这篇自媒体文章提到了“Wayback Machine允许用户自己上传网页存档”，我倒是有点好奇现在这个功能还有吗？--屠麟傲血（留言） 2026年2月21日 (六) 11:02 (UTC)

可以自行上传文件（应该包括html），但是和普通网页存档不同，iabot看到会替换掉。--YikyuenG~速速点击 2026年2月21日 (六) 11:05 (UTC)

(～)補充：即便是蓄意谋杀这样的严重罪行，就算是在中国这样的国家，其量刑都要视乎情节与严重程度来确定是否判死刑、终身监禁还是有期徒刑，这就是为什么强调要先搞清楚archive.today篡改存档的动机，篡改一个存档就说什么信任度降为0，在我看来就等同于是针对蓄意谋杀案不管三七二十一就一副建议判死刑的口吻。--#MilanoCortina2026Day15 2026年2月21日 (六) 08:54 (UTC)

动机应该是隐藏Nora 这个ID？并倒打一耙--Sksawf（留言） 2026年2月21日 (六) 12:05 (UTC)

近一年来编写条目时发现很多老的地方媒体新闻报道网页404，我不得不寻求微信公众号或百度百家号存档。这两个渠道现在Wayback Machine很难有存档，如果Archive.today存不了相当于条目质量无法保证（我不好评估搜狐新浪腾讯的报道留存率），这相当于中国大陆主题的条目来源受到限制。现在社群应该尽量对其他存档服务进行测试，确保条目存档能够平稳替换。另外在使用存档机器人时，我注意到有些网页Wayback Machine能存档但机器人不会存，不得不手动存档，请各位编辑注意。--屠麟傲血（留言） 2026年2月21日 (六) 09:03 (UTC)

搜狐新浪腾讯新闻可使用IA存档，阁下可以再行尝试。--YikyuenG~速速点击 2026年2月21日 (六) 09:05 (UTC)

我并没有说这几个网站机器人不能存档。如果非我举例的话，电击online的网页ブルアカ攻略：3周年記念募集で引いておきたいおすすめの生徒は？我好像跑了两次机器人也没存下来。--屠麟傲血（留言） 2026年2月21日 (六) 09:19 (UTC)

现在只能是优先使用Wayback Machine和megalodon（因每日使用限制的原因不太推荐），前两者实在存不了，或者存出来的网页有明显影响查阅体验的问题时，才用archive.today。总有些来源是那种只有archive.today才存的了，又无法找到其他替代来源的。--#MilanoCortina2026Day15 2026年2月21日 (六) 09:48 (UTC)

知乎、小红书也无法用互联网档案馆存档，至于Archive.today时灵时不灵--Sksawf（留言） 2026年2月21日 (六) 12:06 (UTC)

更新：英维讨论已经结案，结果为完全移除archive.today相关链接并且阻止后续添加。--碟之舞📀💿 2026年2月21日 (六) 09:50 (UTC)

鉴于中文互联网由于特殊情况，很多链接只能用archive.today存档，是否可以考虑先部署弹框，在用户打开相关链接时提示风险？--碟之舞📀💿 2026年2月21日 (六) 09:53 (UTC)

何止是中文互联网，别的语言也有一部分受JS脚本影响导致在Wayback Machine里显示不正常的网页，而且英文站那边不少官僚主义上身，沉迷规则的用户，觉得75%的网页可以用其他存档服务替代就能够消灭archive.today，这根本就不够！昨天我说90%-95%才够，今天我转念一想还嫌少了！--#MilanoCortina2026Day15 2026年2月21日 (六) 10:00 (UTC)

你是在說我們應該用WP:IAR來保留一個把用戶（當肉雞）的會修改存檔的網頁存檔服務嗎？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 10:06 (UTC)

请问Wayback Machine和megalodon都足够完美到可以完全替代archive.today了吗？还有这个东西也是要看具体情节的，情节没有严重到一定程度的，没必要短时间内花大量的精力进行替换，考虑到不同存档服务显示效果不同，及响应式布局的普及，最低限度使用+逐步替换已经是权衡利弊之下的最佳解。--#MilanoCortina2026Day15 2026年2月21日 (六) 10:23 (UTC)

是的，目前我使用过的任何存档工具都不足与archive.today媲美。看在其私人运营、资方不明的情况下，本人依然更常使用IA存档，忍受505的痛苦（M属性大爆发了属于是），今日竟能派上用场。--YikyuenG~速速点击 2026年2月21日 (六) 10:46 (UTC)

archive.today也有不足（不考虑近期事件），例如无法展开被折叠的内容。不同的存档服务，很长一段时间都是互补关系。--#MilanoCortina2026Day15 2026年2月21日 (六) 11:13 (UTC)

倒不如说此类爬虫性质的服务都不是从天上掉下来的——服务器、存储显然要钱，而运维以及用各种方法（IP池？、付费账号等）绕过反爬措施和付费墙也需要持续的投入。--Srapoj（留言） 2026年2月21日 (六) 11:11 (UTC)

尤其是因AI浪潮导致硬件成本火箭式上涨的当下--Sksawf（留言） 2026年2月21日 (六) 12:08 (UTC)

技術上來說這種攻擊方式不算肉雞。 --窝法乙烷 儿法梦碎 2026年2月21日 (六) 11:29 (UTC)

为什么大炮式的做法不算肉鸡（--Srapoj（留言） 2026年2月21日 (六) 11:38 (UTC)

那是中间人攻击。 --窝法乙烷 儿法梦碎 2026年2月21日 (六) 12:16 (UTC)

对于攻击目标而言，效果都是一般用户的机器被攻击者用于DDoS。只不过做法方面这里是第一方直接加料，大炮是第三方作为中间人进行劫持。--Srapoj（留言） 2026年2月21日 (六) 12:28 (UTC)

点击Archive.today的链接时提醒用户去装一个uBlock Origin扩展就行了（（（，uBlock Origin Lite已经上架iOS端了--Sksawf（留言） 2026年2月21日 (六) 12:08 (UTC)

「先部署彈框，在用戶打開相關連結時提示風險」考慮到網站安全性存有疑慮及保障用戶安全，且社群仍有分歧，如果技術上可行，個人支持此做法以作為暫時應對方案。--SCP-0000（留言） 2026年2月21日 (六) 13:41 (UTC)

供參考的樣例User:SunAfterRain/js/externalPopup.js--SunAfterRain 2026年2月22日 (日) 04:32 (UTC)

我已经无法访问archive.today，网站能打开但是无限卡在一个加载动画上--Sksawf（留言） 2026年2月21日 (六) 12:12 (UTC)

以前有时候会出现这种情况，可以继续观望。--#MilanoCortina2026Day15 2026年2月21日 (六) 12:34 (UTC)

archive.today似乎炸了？ph显示Welcome to nginx，is和li无限reCAPTCHA循环，其他域名都打不开--Sksawf（留言） 2026年3月10日 (二) 13:44 (UTC)

現在Archive Today訪問不太穩定，曾經有效的存檔現在常常看都看不到。還是必須說很可惜沒辦法正常使用、現在英維真的不能加進了，但是很多網站包括臉書、政府網站都是不能用Wayback存檔的（Meta就是那麼爛，現在很多網路已經不是網路時光機能保存的了），要是中維還不能用，那麼基本等於這些來源無效，包括CC授權的留言、用在Commons檔案已獲授權的證明，誰都不知道哪天那些使用者會不會直接關帳號了。不知道怎麼辦。——George6VI（留言） 2026年2月26日 (四) 02:44 (UTC)

“曾经有效的存档现在常常看都看不到”有哪些例子，什么提示。--YFdyh000（留言） 2026年2月26日 (四) 03:29 (UTC)

Archive Today網址後綴有.today、.is、或者.ph，可能會自動跳轉，但是現在的結果是無法顯示。悲哀的是，那有可能是一些網路最後的存檔紀錄，這唯一的存檔掛了就再也找不到其他佐證。既然問舉例，最近我遇到的狀況有：

1. 영남타임즈 (Yeongnam Times)是韓國嶺南的傳媒，新聞一兩年前曾經可以閱覽，但是現在例如這則，Wayback、Archive Today兩個存檔都看不到了。不知道是伺服器故障還是會鎖IP，反正同則新聞都只各存檔一次。
2. 臉書上的圖片，只要原拍攝者同意留言我同意依「知識共享署名-相同方式共享4.0」（CC BY-SA 4.0）協議發布此圖片，就能放去Commons。可是臉書是沒辦法用Wayback存檔的，因此之前我傳的兩張照片File:孔垂長 (2025年釋奠典禮).png、File:孟令繼與趙慕倫專訪怪機絲.jpg都是用Archive Today當備胎，可是現在存檔已經看不到。儘管現在授權的原始留言還在，但是要是以後那些臉書帳號不在了呢？會不會影響授權有效性？
3. 台灣卡通頻道曾經在臉書有獨立的粉專，但是之後廢止了，所有舊貼文跟著消失。在那之前我曾用Archive Today存檔，例如「『探險活寶-遙遠的秘境』嗶莫💚」，現在也已經無法查看。

還是這樣，訂個方針說凡是Wayback不能正常存檔的網站，都不得用於維基百科？網路上很多東西沒過多久屍骨無存，很正常。——George6VI（留言） 2026年2月26日 (四) 05:58 (UTC)

会不会要删库跑路了……--Sksawf（留言） 2026年2月26日 (四) 06:09 (UTC)

archive.today有时访问是有些问题。诚然archive.today因为利益冲突的关系改存档算是开了个坏的先例，但英文版现在就将archive.today全部都ban掉显然不是明智之举，响应式布局的大量使用对于网页存档而言是相当不友好的，比如这个网页（2025年亚洲冬季运动会的网页）在Wayback Machine里，要么什么都不显示，要么不停刷新。我建议各位向Wayback Machine多提意见，多反馈问题（我以前就有反馈过巴黎奥运官网在Wayback Machine里显示异常的问题，结果人家还真的修好了），尽可能改善部分网页在Wayback Machine里的查阅体验，不然逐步取代archive.today的事情将会更加难以落实下去。--💊✖️2️⃣3️⃣（留言） 2026年2月26日 (四) 05:12 (UTC)

虽然用archive.today繞过付费墙是「不好」的甚至是「违法」的，但是如果付费网站倒了，要如何查證？书籍出版了肯定能留下痕跡，新闻网站倒臺了，付费墙（或者登錄墙）後的内容就直接消失了。而死链的内容就变成了不可查證的内容，需要移除。这種总有一天会不可查證的内容，我们真的该引用吗？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月26日 (四) 07:33 (UTC)

那维基百科干脆关了算了，任何网络参考资料都可能失效--Sksawf（留言） 2026年2月26日 (四) 07:37 (UTC)

部分实体书籍也会失传……个人认为有必要建立一个列表专门整理各网站在不同网页存档服务（Wayback Machine、archive.today、megalodon）的表现，包括但不限于能否成功存档，存档出来的页面显示效果，及会否受JS脚本的影响导致页面跳转等，只不过需要时常更新，比如Olympics.com域名下的网页昨天还能在Wayback Machine里手动存档的，今天就又不行了，另外同一网站不同版块情况也有不同，例如米兰-科尔蒂纳冬奥官网的新闻版块存档显示正常，但比赛结果版块存档的snapshot就显示一片空白。--💊✖️2️⃣3️⃣（留言） 2026年2月28日 (六) 09:13 (UTC)

(＋)支持--Sksawf（留言） 2026年2月28日 (六) 10:16 (UTC)

不反对制作操作手册，但该说明的准确性不好说。例如知乎可能遇到动态风控，有时多次存档能成功，有些问题/回答仅登录可见，等情况。--YFdyh000（留言） 2026年2月28日 (六) 12:52 (UTC)

所以我前面说过需要时常更新，很麻烦，而且有些网站也是那种有时能存有时又不能的。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 08:49 (UTC)

支持建立列表。目前WP:RSP是本站來源品質最常用的參考，會否考慮加入此功能，免得檢查來源時得搜尋多處？邀請近來關注RSN的編者信源簡報編輯團隊@SuperGrey、魔琴、Olaf8940、Royal Sailor。--1F616EMO（喵留言～求助？） 2026年2月28日 (六) 14:12 (UTC)

要不，直接引入enwiki在製的RSP新版格式？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月1日 (日) 02:50 (UTC)

確實，也是時候跟進新RSP格式了。 --SuperGrey (留言) 2026年3月2日 (一) 02:43 (UTC)

先開了個單獨的討論串。 --SuperGrey (留言) 2026年3月2日 (一) 02:53 (UTC)

(＋)支持將存檔友好列表整合進新版RSP。--英國皇家歐拉夫王子（留言） 2026年3月2日 (一) 04:44 (UTC)

(＋)支持--Sksawf（留言） 2026年3月2日 (一) 04:45 (UTC)

这列表最好跟RSP分开（但可以参考RSP的格式），RSP主要是聚焦内容方面，而且有的列入黑名单的来源本身不需要考虑是否存档友好。另外动手建之前先想好能不能确保持续更新吧，干脆先在用户页空间试试水。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 08:49 (UTC)

列表可以建立，至於更新頻率之後再擔心不遲吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月1日 (日) 17:18 (UTC)

為什麼要分開？我覺得如果是新版RSP格式，可以很方便地放在一起。 --SuperGrey (留言) 2026年3月2日 (一) 02:41 (UTC)

主要是因为页面对于存档服务的友好涉及多个方面，包括能否正常存档（有的网站尝试存档会返回403）、存档出来的页面显示效果（有的页面存档后，受排版影响，一些主要内容会被东西遮住）、会否受JS脚本的影响（有的页面存档会跳转到404页面），而且同一网站不同版块的表现也会有不同（例如某网站的一般新闻版块显示正常，但live blog之类页面的显示会有问题）。另外就是存档服务不止Wayback Machine一家，还有megalodon.jp等。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 09:22 (UTC)

舉個例子：Wikipedia:可靠來源/常見/17173.COM
如果在這個頁面裡面開一個章節介紹存檔服務，可以記錄得很細，還可以附帶擷圖。每個來源都可以單獨記述存檔方面的障礙。 --SuperGrey (留言) 2026年3月2日 (一) 09:31 (UTC)

如果有人愿意整理，不妨再记录些各平台的失效情况，包括一段时间后仅限订户，删文概率，访问网址变更，其他获取途径等。不过若涉及到影子图书馆等访问性质，不知道如何看待。--YFdyh000（留言） 2026年3月2日 (一) 18:05 (UTC)

还有https://ghostarchive.org/ Sksawf（留言） 2026年3月2日 (一) 04:46 (UTC)

还有 https://www.freezepage.com/ --Sksawf（留言） 2026年3月2日 (一) 04:47 (UTC)

Ghost Archive出现522 Connection timed out错误。--~2026-14674-84（留言） 2026年3月7日 (六) 23:48 (UTC)

《新聞業封鎖Internet Archive以防AI抓取》。--~2026-14674-84（留言） 2026年3月7日 (六) 23:21 (UTC)

本来一些新闻媒体就拉黑了Internet Archive，维基百科再拉黑archive.today，那我们就真没啥存档工具可用了。--~2026-14674-84（留言） 2026年3月7日 (六) 23:48 (UTC)

目前还有megalodon能用，但megalodon也不能保证能够与Internet Archive做到完美互补。--💊✖️2️⃣3️⃣（留言） 2026年3月8日 (日) 05:53 (UTC)

德国之声（这可是国际主流媒体）用Wayback Machine存档之后，存档页一直转圈圈[4]，用megalodon存档则正常[5]，英文版用户恐怕很多人都不知道megalodon的存在（毕竟这是个日本网站），再次证明一刀切的禁止弊大于利。--💊✖️2️⃣3️⃣（留言） 2026年3月9日 (一) 09:49 (UTC) 👍1

英维基上目前的探索不认为megalodon是个长期的解决方案，最大的原因好似是这个网站每天只允许存档60个连接的限制，防止机器人大规模存档。 Aaron Liu（留言） 2026年3月16日 (一) 01:29 (UTC)

所以他们当初就不应该全面禁止archive.today，并不是人人都有VPN可以绕过megalodon的每天存档限制。非要在乎archive.today修改存档的行为，应该是鼓励最低限度使用。PS：megalodon似乎可以允许申请批量存档，不过要交钱……--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 09:06 (UTC)

我同意英维基的做法，我觉得信赖与避免恶意代码比能不能访问更重要。 Aaron Liu（留言） 2026年3月16日 (一) 22:32 (UTC)

这取决于你如何理解Wikipedia:忽略所有规则。。。

如果你选择忽略掉恶意代码，那么接着奏乐接着舞

如果你觉得禁用archive.today之后，以前用archive.today作为参考资料的内容仍然可信，那么实际上是忽略了Wikipedia:可供查證

如果你要死板教条的按照规则的字面意思行动，那么所有以“通过archive.today存档且原始链接失效”作为参考资料的内容都应该以Wikipedia:非原创研究而删除

考虑到互联网上的内容都有可能失效，即使是互联网档案馆也不可能永远在线

迟早有一天整个维基百科的所有内容都会缺乏参考资料而被删除

--Sksawf（留言） 2026年3月17日 (二) 04:25 (UTC)

第三自然段和第四自然段之间是有极大的空间的。NOR只是说得删除被争议的内容。档案馆都下线这个担忧，也是比区区archive.today大太多。 Aaron Liu（留言） 2026年3月18日 (三) 22:45 (UTC)

wayback machine以前真的有长达20来天无法使用并存档的情况……--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 03:21 (UTC)

如果说光一个Wayback Machine就能确保全站90%-95%的来源能够正常存档，剩下5%大多数也有可以替代的存档友好来源，我对于全面禁用archive.today也不会有太大的意见。如果archive.today对于存档snapshot的篡改是远超其利益冲突之外的范围，可以合理认定纯粹搞破坏，我也会毫不犹豫的同意在本站范围内清除掉所有的archive.today链接。现实情况是没有证据证明archive.today站长也有篡改过不涉及其自身利益冲突的snapshot，而越来越多的网站已经不适合使用各类存档服务来存档了（德国之音网站还没改版的时候用Wayback Machine存档，显示效果还是没问题的；有的网站近几年开始还引入了cloudflare人机验证，相当恶心），而megalodon每天60次的限制也不见得能够满足部分人的需求（除非手上有很多节点）。--💊✖️2️⃣3️⃣（留言） 2026年3月17日 (二) 08:53 (UTC)

如果说光一个Wayback Machine就能确保全站90%-95%的来源能够正常存档，剩下5%大多数也有可以替代的存档友好来源，我对于全面禁用archive.today也不会有太大的意见。

其实这样也不行，不能光看占比，如果剩下那5%非常重要怎么办--Sksawf（留言） 2026年3月18日 (三) 08:25 (UTC)

那就是还要考虑各来源权重，更加复杂……--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 09:56 (UTC)

我不觉得N……涉及到站长个人利益。站长看起来纯粹把与N……的个人冲突升级到了篡改信息与身份盗窃。严格意义上来说，N……一事纯属推测，但从WP:监督与WP:基金会行动来看，是WMF与英维基监督员们判定有一定可信度的推测。因此，我不太信任站长万一与大人物有冲突时不会干出大事。 Aaron Liu（留言） 2026年3月18日 (三) 22:52 (UTC)

如果真发生，降级到 通常不可靠就行了，没有必要 列入黑名單并删除以前的引用--Sksawf（留言） 2026年3月19日 (四) 01:34 (UTC)

基本(▲)同上，一来人手上没英文那么充足，二来替代品的表现，包括Wayback Machine在内，还是不够令人满意，昨天我写条目试着用Wayback Machine存档几个网页，表现并不稳定，有时候提示Job Failed、Save Page Now Browser crashed……什么的，像我这种写条目写的相对多一些的，肯定是要追求无痛过渡，不然只会严重影响我写条目的效率！--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 03:43 (UTC)

现在没法用Wayback Machine存档的网页太多了--Sksawf（留言） 2026年3月19日 (四) 03:47 (UTC)

刚发现Bloomberg（也是国际主流媒体）在megalodon下的表现也是有问题的（整个网页纵向压缩，例如这个[6]），Wayback Machine目前503暂时无法测试（但估计无法绕过付费墙），archive.is倒是正常（[7]）。既然国际主流媒体的存档体验都越来越不行了，就更不能单纯只考量信任及代码问题，同样也要充分考虑替代品的使用体验，找来源本就不容易了。--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 10:47 (UTC)

总的来说，我个人希望中文维基百科不要全面禁用Archive.today。

一、通过Chrome的开发者界面功能，我在archive.md和archive.is验证码界面的网页源代码中，找到了提及gyrovague.com的代码：

setInterval(function(){fetch("https://gyrovague.com/tag/"+Math.random().toString(36).substring(2,3+Math.random()*8)+"/",{ referrerPolicy:"no-referrer",mode:"no-cors" });},3000000);

这些代码的作用是每隔50分钟向gyrovague.com发送一次请求。考虑到用户极少会让网页在验证码界面停留50分钟，以及Archive.today属于比较小众的网站，我想我们可以假定Archive.today当前事实上没有使gyrovague.com遭受DDoS攻击。

二、如果Archive.today修改了某个直接关涉自身利益的存档，那么我们有理由禁止使用它提供的关涉其利益的存档。但是，如果我们要禁止使用Archive.today提供的所有存档（比如中国大百科全书“印欧语系”条目的存档），就应当考虑这一禁制的负面影响是否值得我们这样做。

三、让我们看看Archive.today的替代品有何缺点：互联网档案馆的诸多缺点其他人已经有讲到，Megalodon.jp和它一样无法存档拒绝机器人访问的网页。我研究了一些其他存档服务，结果发现Ghost Archive无法正确存档上述中国大百科全书条目，Smry.ai存档得更不成功，Perma.cc需要付费，FreezePage则竟会删除不活跃的用户提供的存档。查阅或尝试了这些网站以后，我想我们可以假定，足够好的单一替代品即使存在也难以找到。

四、此外，考虑到我们的人手与英语维基百科的差距，禁用Archive.today会给我们带来更大的相对负担。--CuSO₄ · 蛇年大吉 2026年3月15日 (日) 18:24 (UTC)👍1

我也可以确认此站目前确实把期限调成了50分钟，可是二月初英维基也有人认为此站把相关的代码完全移除了。一天后，他们又看到了网站上每0.3秒发动fetch的代码。我同意现在去访问没有什么可观测的危害（对于存档的篡改也被滚回了），但是论点在于信赖。不过，我也同意替代品的不佳令人头疼。 Aaron Liu（留言） 2026年3月16日 (一) 01:32 (UTC)

看来事态是有一些好转的，可以继续观望下，我感觉megalodon大多数时候没archive.today好用，最头疼的就是每个IP每天60个链接的限制。--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 09:23 (UTC)

我的话的意思是好转不太能说明多少。至少，这是英维基讨论的看法。 Aaron Liu（留言） 2026年3月16日 (一) 22:34 (UTC)

补充一个 https://www.archiveforever.xyz/ 我这里不知为何用不了，你们试试--Sksawf（留言） 2026年3月16日 (一) 05:28 (UTC)

我试了一下，点击“ARCHIVE”按钮后网站没有反应。--CuSO₄ · 马年大吉 2026年3月16日 (一) 11:46 (UTC)

总结的非常好！在这件事之前，我一直都觉得archive.today相当便利。现在用Wayback Machine存不了的我只能转去megalodon去存，有时候如果工作量大，要存的链接很多，一天60个的份额都不够用！除非你开了VPN，手上有很多节点。--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 08:53 (UTC)

archive.today打不开了？--Sksawf（留言） 2026年3月18日 (三) 08:26 (UTC)

我试了下能打开啊。--💊✖️2️⃣3️⃣（留言） 2026年3月18日 (三) 13:46 (UTC)

错误代码：503 Service Unavailable--Sksawf（留言） 2026年3月18日 (三) 13:50 (UTC)

應該只是暫時性的伺服器過載而已。--象象🐘(留言|貢獻) 2026年3月18日 (三) 13:58 (UTC)

過濾器

正如前述所言，已參照英維建立了本地的過濾器，提醒文本亦翻譯至英維，並依照本站討論修改。該過濾器目前測試運作中，且以便社群了解archive.today使用情況。依據上述討論，個人認為現階段可利用過濾器提醒編者，而非一刀切禁止。由於涉及到用戶安全，如果社群中有多人支持此方案，可考慮先行啟用，並同時進行公示流程。謝謝。--SCP-0000（留言） 2026年2月21日 (六) 13:53 (UTC)

“透過”应当地区词转换为“通过”，“广告阻挡插件”应改为“内容拦截器”。

另外，提供uBlock Origin及uBlock Origin Lite的GitHub链接可好？--Sksawf（留言） 2026年2月21日 (六) 15:02 (UTC)

已調整，謝謝建議。--SCP-0000（留言） 2026年2月21日 (六) 15:13 (UTC)

这东西是作为系统消息展示的，字词转换标记不会起效。若要提供简体版本，需在部署前用{{lan}}手动转换一份。--Srapoj（留言） 2026年2月21日 (六) 15:49 (UTC)

已調整，謝謝。--SCP-0000（留言） 2026年2月22日 (日) 00:40 (UTC)

留意到有一个新的全域过滤器m:Special:AbuseFilter/449 (Archive.today tracking)。--Srapoj（留言） 2026年2月21日 (六) 17:58 (UTC)

@1F616EMO、Cwek、Diskdance、Ericliu1912、GrandCeres、Liu116、MilkyDefer、Milkypine、PexEric、SCP-2000、Sksawf、Srapoj、YFdyh000、YikyuenG、屠麟傲血：cc 參與上方討論的編者。--SCP-0000（留言） 2026年2月22日 (日) 04:30 (UTC)

(＋)支持啟用過濾器--象象🐘(留言|貢獻) 2026年2月26日 (四) 15:01 (UTC)

@SCP-2000：「酲」應作「醒」。Sanmosa _风林火山 2026年3月1日 (日) 05:31 (UTC)

@Sanmosa 我這邊看正常的，不太理解問題在哪？--SCP-0000（留言） 2026年3月2日 (一) 03:00 (UTC)

他是說你過濾器日誌裡寫了錯字。 --SuperGrey (留言) 2026年3月2日 (一) 03:09 (UTC)

那我之後更新時一併修正吧。--SCP-0000（留言） 2026年3月2日 (一) 03:11 (UTC)

考慮到討論多天未有人反對此提案，且涉及用戶安全性問題，故先行啟用此過濾器，並 公示7日，2026年3月18日 (三) 20:06 (UTC)結束。--SCP-0000（留言） 2026年3月11日 (三) 20:06 (UTC)

啊，现在才启用？--Sksawf（留言） 2026年3月12日 (四) 03:55 (UTC)

@SCP-2000：容我確認一下，公示通過了沒有？Sanmosa _风林火山 2026年3月20日 (五) 10:42 (UTC)

根據WP:共識，應該早就通過了？--象象🐘(留言|貢獻) 2026年3月20日 (五) 11:32 (UTC)

有鑑於公示期間無反對意見，現根據共識方針代告公示通過。--象象🐘(留言|貢獻) 2026年3月20日 (五) 11:46 (UTC)

沒問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月12日 (四) 03:51 (UTC)

MMS

是否需要發送MMS提醒編者相關變更？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 16:24 (UTC)

過濾器 + 彈窗理應足夠，但不反對發送MMS。--SCP-0000（留言） 2026年2月22日 (日) 01:40 (UTC)

弹窗

用弹窗提醒读者，是否有共识？如果没问题的话麻烦哪位技术大设计一下（） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 19:28 (UTC)

@1F616EMO、Cwek、Diskdance、Ericliu1912、GrandCeres、Liu116、MilkyDefer、Milkypine、PexEric、SCP-2000、Sksawf、Srapoj、YFdyh000、YikyuenG、屠麟傲血。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 19:28 (UTC)

可。--YikyuenG~速速点击 2026年2月21日 (六) 23:53 (UTC)

同意彈窗。不建議用瀏覽器原生彈窗，在不同平台上視覺表現參差，建議使用OOUI或Codex。邀請@Diskdance。--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 00:57 (UTC)

(＋)支持--SCP-0000（留言） 2026年2月22日 (日) 00:58 (UTC)

已经做了临时脚本并且在Beta站上线了。请各位检查是否有问题。此事事关安全，是否应该走常规公示流程？--碟之舞📀💿 2026年2月22日 (日) 04:59 (UTC)

Error

Requests from your IP have been blocked, please see https://wikitech.wikimedia.org/wiki/Beta/Blocked for more information.--Sksawf（留言） 2026年2月22日 (日) 06:00 (UTC)

这是Beta Cluster的防爬虫措施，如果使用代理的话请尝试切换节点。--碟之舞📀💿 2026年2月22日 (日) 06:13 (UTC)

目前彈窗僅指出網站存在安全問題，是否應至少指出DDoS問題？--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 06:22 (UTC)

社羣或可參考英維創建相關說明頁，並在彈窗中提供target=_blank連結。--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 06:23 (UTC)

不能假定所有读者都知道DDoS这样的专业词汇是什么意思，因此指出安全风险足矣。--碟之舞📀💿 2026年2月22日 (日) 07:20 (UTC)

“已知安全问题”对有经验读者来说参考性过低？可能应该将此链到相关议题或说明页（未建立）。“如非必要，请勿访问”对用户来说，似乎感觉不出危害（风险）程度。非代理用户碰到该站验证码页面的概率有多大。--YFdyh000（留言） 2026年2月22日 (日) 11:08 (UTC)

如果有说明页的话可以添加。--碟之舞📀💿 2026年2月22日 (日) 12:49 (UTC)

那就把DDoS改成“对其他网站进行攻击”--Sksawf（留言） 2026年2月22日 (日) 11:27 (UTC)

至少应该把 https://zh.wikipedia.org/wiki/MediaWiki:Abusefilter-warning-archivetoday 的内容全放进弹窗里--Sksawf（留言） 2026年2月24日 (二) 07:34 (UTC)

這樣的話太臃腫了，不過同意可摘錄要點。--1F616EMO（喵留言～求助？） 2026年2月24日 (二) 13:47 (UTC)

我认为可以紧急上线。谢谢。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月23日 (一) 17:26 (UTC)

@魔琴、@1F616EMO、@Cwek、@Ericliu1912、@GrandCeres、@Liu116、@MilkyDefer、@Milkypine、@PexEric、@SCP-2000、@Sksawf、@Srapoj、@YFdyh000、@YikyuenG、@屠麟傲血：考虑到属于安全问题，现已部署，如发现问题请回报。--碟之舞📀💿 2026年2月24日 (二) 12:00 (UTC)

收到。--YikyuenG~速速点击 2026年2月24日 (二) 12:06 (UTC)

@Diskdance 鼠标中键（滚轮）点击没有提示 Sksawf（留言） 2026年3月10日 (二) 13:43 (UTC)

應爲預期行爲。鼠標中鍵會繞過瀏覽器的點擊事件，直接請求瀏覽器開啓新分頁，故不會觸發依賴瀏覽器事件觸發的彈窗警告。--1F616EMO（喵留言～求助？） 2026年3月10日 (二) 13:45 (UTC)

为了安全，只支持css弹窗，反对js弹窗。--脳補｡◕‿◕｡讨论 2026年3月20日 (五) 11:40 (UTC)

参考資料

2027丁未年新年标志联合票选

先祝大家丙午年新年快乐。虽然26年元宵都没过完，讨论27年春节标志的事可能为时过早，现在看来还有三百多来天。但是考虑到我维和越南语的正常票选流程，其实差不多在今年年底或在明年年初开始，也就是还有九个月的时间，再加上联合票选一事若确定，可按方案往后一直办下去，故此提前九个月讨论只能算是留下一个充裕的时间，所以不如提早讨论。

首先先回顾一下背景，见Wikipedia:互助客栈/其他#春節標誌聯合票選，其大致思路就是，多个语言社区中，创作者将作品放到票选中，各语言社群各自选出自己社群的标志。本质上是个共享设计的方案。社群应该有：中维、日维、越维、韩维、闽南语、粤语、吴语、闽东语、文言、客家话、赣语、藏语、壮语（可能因为我眼瞎漏了其他也可以参与的语言社群）。其中日维在上方讨论中基本确定不会换标，但毕竟也可以邀请创作者创作。同时也有人提出，可以不局限在维基百科这一单一维基项目，还可扩充到例如维基词典等项目之中。

上述主要有两个问题：

• 文化问题。各个社群的春节文化可能完全不同，甚至越南有猫年这一说法，这导致设计上可能会导致些许不合。
• 维基项目问题。不同维基项目之间，可能也因不同项目的属性，难以推出一个能让大家都用的标志。

当然上述两个问题都是小问题，对文化上来说，可能可以放些有关春节的元素就行，相信春节习俗上还是有很多共同点的。维基项目问题，亦可以用同样思路解决。

我个人对此对的想法是，27年先邀请上述社群的维基百科来看看，毕竟如果维基百科都没人，其他维基项目很难真的有人来。具体细则上，我相信只要一些基本上的，如不涉及版权问题等即可。

我本人对此能力有限，尤其是对元维基的了解上的，所以也希望有人能对我在元维基上有些帮助（如建立项目页？）。本人主要是有些时间，可以和其他社群的讨论页上与其他社群人员进行交流。

希望大家可以对该想法提出意见和帮助。

以上。谢谢。Luoniya（留言） 2026年2月28日 (六) 18:25 (UTC)

我觉得春节标志以后都别提日文的事情了，这次维基百科25周年他们没换特别标志（上次20周年换了），至于邀请创作者，我认为他们的积极性也没那么大到专门为别的语言版本提供方案，更何况日本那边的新年习俗细节上本就与中文圈有很大的差异，由此带来的文化差异问题其实不比想象中小。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 09:22 (UTC)

都注明“日维在上方讨论中基本确定不会换标”了，这话有什么问题，而且也不重要，别老是盯着这个日维不放了...--Sheminghui.WU（留言） 2026年3月1日 (日) 09:36 (UTC)

如果没说“邀请创作者创作”，我也不需要说什么。如果一定要邀请只过公历新年的国家/地区的编者来参与创作，干脆直接邀请全球的创作者都来参与啊！什么“老盯着日维不放”！？--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 09:41 (UTC)

日本新年以及春节对应的旧正月其实还是有很多相似之处的，毕竟也是属于中华文化圈的一部分，你要说有区别倒也没错，但是我认为既然是联合票选，各个社群也可以根据他们自己的文化喜好，选择要不要投日本创作者所表现出的新年习俗嘛。

至于你说的邀请全球创作者，这自然也是合理的，但是我个人对此程序不太了解，如果你有兴趣，可以在元维基上提一提。至于我为什么要提日维，也主要是日本确实有这样的习俗，没必要单独不列。--Luoniya（留言） 2026年3月1日 (日) 09:47 (UTC)

日本只是放弃了农历，不是放弃了新年好吗... 日本人也过节气和新年，只是按照公历日期而已，只是不能同一个时间来换图标而已。要是搞这种大联合邀请，那就应该一视同仁，这有什么负面影响吗？。日本是东亚文化圈的成员，有传统新年习俗是事实。~ Sheminghui.WU（留言） 2026年3月1日 (日) 10:03 (UTC)

我觉得是不是在农历庆祝新年，还是有着不小的区别的，毕竟公历新年全球无论是哪里都会庆祝，还有十二生肖更多是跟农历挂钩的，特别是日本的新年经过多年的发展，所形成的习俗差异已经越来越明显，这就是我为什么认为明治维新后的日本新年不能跟汉字文化圈其他地区的春节可以相提并论。当然韩国的春节习俗和大中华的也有很多不同，但好歹还是在农历庆祝，而且中国也有朝鲜族。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 10:05 (UTC)

我觉得就算有区别，也不影响现阶段邀请创作者创作，否则联合票选一事就没必要考虑了。使用中文的人，也因为各地区有不一样的习俗，但也不影响中维能推出来一个大家都觉得合适的标志，其他语言，如日语在此事上也无本质区别。以上--Luoniya（留言） 2026年3月1日 (日) 10:09 (UTC)

中国其实也有未识别和族来着...而且这没什么关系的吧。不过我们都可以保留自己意见，先把大概的东西确定了再来讨论这些细枝末节比较好。--Sheminghui.WU（留言） 2026年3月1日 (日) 10:09 (UTC)

如果要邀请日文的社群，干脆也邀请其他所有语种的社群。放眼站外，英国自2014年开始每年都推出中国农历生肖纪念币，因此邀请全球所有编者共同参与理论上可行。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 10:15 (UTC)

我本人对邀请全球创作者并无意见，但由于本人对现有计划已经不知所措，你若有闲暇时间可以帮忙完善计划。--Luoniya（留言） 2026年3月1日 (日) 10:18 (UTC)

我也没意见，但还是觉得让几乎全民庆祝此节日的东亚文化圈诸社群来搞比较好。 ~ Sheminghui.WU（留言） 2026年3月1日 (日) 10:26 (UTC)

对于越南语、韩语等在采用特殊标志庆祝方面较为积极的社群，可前往各自语言版本的互助客栈单独发出邀请。至于文言文、粤文等汉语方言，及藏语、壮语等少数民族语言，需要视乎各自社群的活跃情况。对于其他不可能在春节（注意是春节，像俄文就有在每年的公历新年启用特殊标志）期间换标的语种社群，则不需要单独发出邀请，仅在元维基页面上说明欢迎全球所有编者参与创作即可。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 08:48 (UTC)

一些少数族群似乎也受农历新年影响，也有了一定习俗，毕竟是全国性假日--Luoniya（留言） 2026年3月2日 (一) 09:04 (UTC)

我没说少数族群不需要邀请，只是要看他们社群活跃程度是否足够，有的社群活跃的可能也就那几个人而且都不能确保天天都去逛维基百科，单独去他们那边邀请，有可能很久都不会获得任何回应那就尴尬了……--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 09:10 (UTC)

这没有什么尴尬的吧...应该都去类似的讨论区发条邀请的。没回应有什么的，小Wiki的讨论区经常有无回应的各种邀请。应该都发邀请。 ~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:05 (UTC)

根本不是一个概念，那一些非华人主体地区还放假呢。日本新年，“正月本来是农历的一月，明治维新后改用格里历，则用于称新历的1月”，历法变了，节日毕竟同根同源且有全民庆祝的传统。~ Sheminghui.WU（留言） 2026年3月1日 (日) 10:24 (UTC)

无论如何，我不知道现在花篇幅讨论这个的意义是什么，毕竟日本社群可能相当大概率不参与。先把最基础的东西确定了再来继续讨论这些东西吧。~ Sheminghui.WU（留言） 2026年3月1日 (日) 10:28 (UTC)

(＋)支持基本赞同。如果本地社群依然有兴趣，可以联络其他社群看看。主要先确定在哪讨论 ~ Sheminghui.WU（留言） 2026年3月1日 (日) 09:38 (UTC)

我个人主要的思路还是，先在元维基上搭一个基本框架的项目页，然后再邀请各社群进行讨论。但正如上面，我对元维基的事物基本不太了解，还是需要他人协助，或等我有更多空闲的时候研究下。--Luoniya（留言） 2026年3月1日 (日) 09:49 (UTC)

我也觉得这个方案合理，如果要搞的话 ~ Sheminghui.WU（留言） 2026年3月1日 (日) 10:04 (UTC)

其实说到这个，归根究底就是我不太了解元维基到底是怎么运作的。此类事宜是否直接在元维基新建页面即可？以及似乎在本地无共识的情况下，也不好去写。--Luoniya（留言） 2026年3月1日 (日) 10:29 (UTC)

Sanmosa同志在上面提过这个，“参考meta:Meta:About的说明，在meta那边开的个专门的讨论页面应该是一个不错的选择。”。如果确认了社群仍有一定兴趣，应该就可以去开。具体怎么开我也不太了解。~ 2026年3月1日 (日) 10:34 (UTC)--Sheminghui.WU（留言） 2026年3月1日 (日) 10:34 (UTC)

我研究了一会，或许应该可以在元维基的Wikimedia Forum上开，如果我没理解错的话？）。不过还是得先在这取得一定共识。--Luoniya（留言） 2026年3月1日 (日) 10:47 (UTC)

我是覺得太早了哈，不過反正討論可以開著慢來，所以沒特別意見（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月1日 (日) 17:16 (UTC)

考虑到今年的春节特别标志评选中出现了用AI辅助创作的作品，今后的特别标志有必要针对AI辅助创作方面作明确规范，考虑到本站懂美工的不多，个人对于使用AI创作标志并不抵触，仅认为如果用了AI就必须加以说明，但不清楚其他用户在这方面的看法如何。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 08:55 (UTC)

考虑到社群的实际情况，使用ai的话加声明，确实是合适的--Luoniya（留言） 2026年3月2日 (一) 09:03 (UTC)

这方面有必要到时统一一下意见，不同人对于AI创作的接受程度不同，有的人就特别讨厌使用AI创作的作品。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 09:14 (UTC)

那票选可以自己根据自己对ai的喜好投。作者只要声明有没有ai元素就行--Luoniya（留言） 2026年3月2日 (一) 09:23 (UTC)

这没你想得那么简单，有的人恨不得取消AI作品参与评选的资格，也有的人会认为参与评选的作品不能全是AI创作……所以我才说要统一意见。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 09:32 (UTC)

我觉得既然是联合活动，也需要先等待其他社群的意见。等初步成型了在MediaWiki讨论这些事务比较好。~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:08 (UTC)

( π )题外话，下年羊年有小麻煩：日韓指的是「綿羊」而非「山羊」，跟越南人不同。我自己認同文中白領的看法：「我看到的生肖形象更多是山羊，但我會更願意買綿羊造型的吉祥物，因為它們更可愛。」-- MCY  對話  2026年3月2日 (一) 09:20 (UTC)

确实注意到这一情况，文化标志上主要体现在羊角上的区别，我个人觉得这个问题不是特别大，应该基本不影响观感，，毕竟还没到猫年那种情况。--Luoniya（留言） 2026年3月2日 (一) 09:26 (UTC)

如果是一起用一个或类似的标识，我觉得兼顾两者也不是没有希望（或者干脆用一个）。如果是各自落地那应该更没有问题了:)--Sheminghui.WU（留言） 2026年3月2日 (一) 10:03 (UTC)

我其实有想过两轮票制，第一轮选出每个维基最受欢迎和全域最受欢迎的标志，然后社群可以自行决定是直接用该维基最受欢迎的还是全域最受欢迎的，还是这两个中再选一次，但是我觉得实际操作下来估计就是该维基最受欢迎的标志当选，所以没提。--Luoniya（留言） 2026年3月2日 (一) 10:11 (UTC)

这种应该不行，全域标志一定得是多少兼顾了多元素（至少这几个国家）才能入选（所以可以在这项投票中增加这个限制），否则就只是人数堆叠了，也没有什么实际意义。~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:29 (UTC)

确实。不过这个其实属于延展方面的，可以等基本框架搭起来以后，再讨论这个。--Luoniya（留言） 2026年3月2日 (一) 10:47 (UTC)

（突然有想法，搞个山羊和绵羊各自拿着自己的过年物品互相分享的图标怎么样，例如粽子、福袋之类。总之跨文化点子还是会很多的） ~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:37 (UTC)

考虑到大家的意见，以及毕竟不是中维一家在办，我计划将下列信息与下列信息的翻译版本，发送到上述涉及的社群，以便更好的了解各社群对此计划的意见：

各位2026年农历新年好。中文、越南语维基百科，历年有在春节期间更换春节特别标志的习惯，考虑到春节这一习俗广泛传播，且希望有更多设计的出现。源于中维的讨论，我在此提议以下事项：

1本社群或可考虑也在2027春节期间更换标识，更换具体时间可由社群自由商讨，这里推荐自UTC+14时区2027年2月5日0点（即除夕）开始，UTC-12时区2027年2月22日23:59结束（即元宵翌日）

2本社群的春节特别标识，可由各社群人员各自提交设计到联合票选项目页，各社群可以自行根据这些设计，组织票选，以来选出最适合自己社群的设计。

我计划联合票选的具体规则如下：

1在今年相关项目页建立后，投票前可自由提交标志

2标志必须是svg格式的文件，只需替代File:Wikipedia-logo-v2.svg

3如果可以，亦可为移动版设计图标，即替代File:Wikipedia-wordmark-en.svg或具有相同性质的文件，考虑到多语言的特殊性，文字必须采用“wikipedia”，而非本地社群语言

4标志必须透明背景

5必须采用开放版权许可，并符合维基资源的相关规定，意味着其标志的所有元素也必须是自由资源

6如果有使用的元素由ai生成，作者需要在提交的时候声明

7设计时应考虑所有人士，包含残障人士等，因此请避免使用动画。而会引起癫痫的闪烁动画则全面禁止。若要使用动画则应为循环动画。

如果你对上述规则和想法有更多意见，欢迎提出。

考虑到本社群可能并无换标想法，但这也没关系！你们也可以来参与创作。此外值得注意的是，由于现在此案基本由我操办，由于本人不太熟悉元维基事宜，请问关于类似想法，是否直接在元维基建立项目页较为适当，谢谢。

可能在2026年春节都没过完的情况下，提这些有点早，但是毕竟涉及到多社群，并计划长期举行，还是希望早点能够讨论。具体我会直接邀请的社群有：中维、日维、越维、韩维、闽南语、粤语、吴语、闽东语、文言、客家话、赣语、藏语、壮语（可能我遗漏了其他也可能有积极想法参与的语言社群，欢迎提出）。

以上，谢谢。

此外中维也可对我上述规则进行讨论，我看一下修改后再发出去--Luoniya（留言） 2026年3月2日 (一) 10:08 (UTC)

我建议说“去年春节前夕有中维用户提出联合设计乃至票选纪念标致的想法，在本地社群受到了认可，越文及朝文维基百科也有一些用户表示了兴趣。”之类。然后时间方面，不用推荐日WP使用农历时间吧？如果个各社群没有意见，日WP应该可以在自己过年的时候挂（假如真的参与了）？（所以也许日文版本不写推荐使用农历部分）。另外现在发是不是太早了点？而且很容易被淹没，后面按理来讲还应该第二次发送吧，毕竟很多人不看MediaWiki。不少具体的东西也可以等待本地（中文）社群再讨论讨论再说？说实在的，各社群都应该讨论，所以先建个维基媒体页面吧，也许这份通知的后半段具体怎样应该让各社群去那里讨论出来，可以考虑先发前半段之类。~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:50 (UTC)

时间问题很有意思，我会和下面那条回复稍后一起回复。

时间问题的话，主要是我觉得，现在主要讨论要不要办和怎么办，我估计也能讨论个几十来天，到时候真办起来了，再二次邀请创作者参与。

至于维基媒体页面，其实说实话，我对此类问题确实一窍不通，我会稍后研究具体怎样的。--Luoniya（留言） 2026年3月2日 (一) 10:58 (UTC)

我觉得应该先行建立Meta页面，然后您可以把通知后半段这些具体要求作为草案发到MetaWiki页面上，征求所有人各社群编者的修改意见。直接在通知里确定下来应该不太行。~ Sheminghui.WU（留言） 2026年3月2日 (一) 11:01 (UTC)

其实我也还一直犹豫一个身份问题，就是我可以直接以用户身份发起此类项目吗--Luoniya（留言） 2026年3月2日 (一) 11:09 (UTC)

我也不太了解meta的规则，如果要搞先建立meta页面再邀请会理想一些。你以个人身份到各处留言肯定是没什么问题。所以先不着急吧，再等等看看有经验的人出来解答一下（ ~ Sheminghui.WU（留言） 2026年3月2日 (一) 11:12 (UTC)

話說壯族、藏族新年和農曆春節似乎不一定重合🤔，如果不重合也可以算的話，維吾爾，蒙古，排灣語的好像也可以算？甚至是其他地區，如泰文[8]、印尼等等--User:What7what8🏠 2026年3月2日 (一) 10:51 (UTC)

其实吧，我感觉藏历新年（虽然日子接近）本身不应该计入农历新年内的。确实，如果把标准扩大到“放假庆祝”之类，一些非东亚人主体国家也可以计入。不过泰国是有自己的新年泼水节的，而且我查到的资料有显示并不全国放假，2021年是特例？[9]。说到底还是泰国华人和其他源于东亚的族群的节日吧。放假事情我现在问问泰国朋友也可以（，不过官方应该会给资料的。~ Sheminghui.WU（留言） 2026年3月2日 (一) 10:59 (UTC)

泰国我有看到资料好像是地方性假期（？）--Luoniya（留言） 2026年3月2日 (一) 11:01 (UTC)

其实这样考虑的话马来西亚等把春节列为法定假日的国家是不是也该算，所以是否应该邀请马来语社区等等？）

我会进一步重新研究一下春节的流传情况。给出一个改进方案。--Luoniya（留言） 2026年3月2日 (一) 11:00 (UTC)

其实中国新年即使在马来西亚也是华人社群庆祝为主和有传统的节日吧，政府放假基本是考虑到占一半的这个华人社群。。（其他非东亚的放假地区大多也是这个原因）。我觉得联合评选应该先聚焦有庆祝传统的各社群，况且维基百科不是以国界而是以语言区分的，应该没有必要专门去邀请（举例子）马来文吧，反正不论哪里的人想要参与/做贡献我们也欢迎啊，到时候Meta页面上会写。~ Sheminghui.WU（留言） 2026年3月2日 (一) 11:03 (UTC)

我之前也是有这样的考量，所以没有把马来语之类的列进去。我的排法其实主要就是，两岸四地境内的所有主流语言（英语这些的除外），以及其他国家主体民族还有春节习俗的，把该主体民族语言列进去。然后我上面其实是把维吾尔，蒙古，排湾语遗漏了，按照我的排法就是该列的--Luoniya（留言） 2026年3月2日 (一) 11:06 (UTC)

我其实觉得合理。反正是征求各社群本地意见嘛。例如藏语社群假如不想参与就可以选择不参与，这没什么问题。~ Sheminghui.WU（留言） 2026年3月2日 (一) 11:11 (UTC)

至于更加具体的东西，还是等到Meta页面上大家讨论。--Sheminghui.WU（留言） 2026年3月2日 (一) 11:13 (UTC)

我又仔细研究了一下。个人认为马来语、等就没必要直接去该语言邀请了。马来语那一类的原因是因为虽然有公共假日，但是考虑还是没有春节习俗。

至于维吾尔语、壮语、蒙古语考虑只是时间上相近，而是不直接邀请了。排湾语亦是同理。

所以应该中维、日维、越维、韩维、闽南语、粤语、吴语、闽东语、文言、客家话、赣语。

所以本质上是将有春节习俗的语言社区拉进来，当然到时候其实可以去上述那些马来语等社群直接邀请他们设计标志的。--Luoniya（留言） 2026年3月2日 (一) 12:08 (UTC)

不会换标志的wiki还是别单独发邀请了，还是那句话，优先拉在换标志方面可预见较为积极的wiki社群。硬是要拉，那就先单独邀请这一次，反应明显不积极的那以后就别再去单独邀请了，不然年年都去问他们肯定觉得烦。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 12:12 (UTC)

各位，我已在别的维基百科邀请，以下为详细讨论链接：日维、越维、韩维、闽南语、粤语、吴语、闽东语、文言、客家话、赣语。--Luoniya（留言） 2026年3月6日 (五) 13:03 (UTC)

目前，在维基大典，以及在一定程度上（两名用户）表达了对该方案的理解与些许支持。越南语维基上，有用户询问具体方案，并提出若是中维没标志可以选，或可考虑筹钱请人画标志，尽管我本人对此方案觉得没有推进的可能性，但是我觉得还是有一定价值，反馈到这。以上。--Luoniya（留言） 2026年3月7日 (六) 08:48 (UTC)

筹钱请人画个人不是很赞同。毕竟这里是志愿性质。接下来还是继续观察各语种的反馈。--💊✖️2️⃣3️⃣（留言） 2026年3月8日 (日) 06:22 (UTC)

目前，维基大典那边现在是准备用全域最受欢迎标志，然后本地二次确认。日维那边是有用户认为，或可在1月份悬挂，而非农历春节。--Luoniya（留言） 2026年3月8日 (日) 06:28 (UTC)

只有日文是只能在格里历新年挂。受此影响导致的悬挂时间的错开，多多少少还是会影响到日文那边社群的参与积极性的，本来他们就没上过什么特别标志，所以我不鼓励拉他们一起参与，如果那边反应没韩文和越南文那样足够积极的话，下年别再去他们那里问了。--💊✖️2️⃣3️⃣（留言） 2026年3月8日 (日) 06:34 (UTC)

個人认为，按照格里曆新年定流程也挺好的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月19日 (四) 07:14 (UTC)

各位，有关本事的元维基页面已经建立，详见此，正在将此粗略翻译成英语，并到时发送消息到对应社区--Luoniya（留言） 2026年3月13日 (五) 13:03 (UTC)

这么早就开始讨论了吗……

本人意见同基本同刘酱。--浅村しき（留言・签名） 2026年3月15日 (日) 13:23 (UTC)

具体赞同哪些，是指赞同日本社群问题，还是规则上的问题，还是都赞同。以便调整。--Luoniya（留言） 2026年3月15日 (日) 14:06 (UTC)

关于之前按笔画分栏功能的设想

用tabber就可以实现这功能，但是貌似这里没有这种功能，能申请开通么？--辱包专家（V • T • C） 2026年3月6日 (五) 11:20 (UTC)

@Hzt0208042508415531 tw：请明確完整地描述你的想法，不要让人玩猜谜遊戏。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月6日 (五) 14:17 (UTC)

TabberNeue扩展，制作选项卡模板，就可以按笔画顺序索引。

这个技术帖子我现在找不到了，不过确实有前人有这样的想法。--辱包专家（V • T • C） 2026年3月7日 (六) 08:33 (UTC)

@Hzt0208042508415531 tw：什麼按笔画顺序索引？tabber有多個选项卡，一個选项卡放“笔画”，其他放什麼？还是说五個选项卡分別放横竖撇捺折？还是一二三四五画？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月9日 (一) 07:25 (UTC)

对啊，就是笔画一二三四，部首这些。看到别人很久之前探讨过这个话题，我有回复。--辱包专家（V • T • C） 2026年3月9日 (一) 17:51 (UTC)

原来的讨论见模板讨论:Navbox#有可能编写出有分页的模板吗？

是本人记错了。这是个技术问题，我认为很好解决。--辱包专家（V • T • C） 2026年3月10日 (二) 15:42 (UTC)

Template:Isotope nav（Template:Tabs）這種？--User:What7what8🏠 2026年3月11日 (三) 14:52 (UTC)

差不多吧--辱包专家（V • T • C） 2026年3月16日 (一) 00:20 (UTC)

話說@Kanashimi：為何topic list沒辦法正確顯示Hzt0208042508415531 tw的用戶名？會顯示為「User:Hzt0208042508415531 tw」（多了一個User:），然後連結至「User:User:Hzt0208042508415531 tw」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月19日 (四) 16:47 (UTC)

 已修复 因為Special:Contributions/User:Hzt0208042508415531 tw。--Kanashimi（留言） 2026年3月19日 (四) 21:32 (UTC)

是否應對每日創建條目的數量、頻率予以限制？

此問題是因為「是否應對懸掛收錄標準、提刪的每日數量、頻率予以限制？」所引發的想法。若短時間提刪大量條目，或短時間對大量條目掛收錄標準模板是不太合理的。那麼，短時間、密集的創建條目是否合理呢？

此情形下產生的條目多半是小小作品、小作品或初級條目，有基本篇幅，但內容不多。（若可以短時間頻繁密集的產生大量內容的條目，那就有可能是LLM產生的了，不過那是另一個議題，我目前不太想碰）。我之前聽到有維基人創建這類條目，期望「有緣人」繼續擴充，不過，屮文維基百科的「有緣人」沒有這麼多。

我還沒針對此議題想好具體規範的標準（例如「每人每天不得創建超過100個條目」之類的），只是提出想法，拋磚引玉，歡迎大家提供意見。若大家認為我多慮了，也可以提出。謝謝大家。--Wolfch (留言) 2026年3月7日 (六) 08:20 (UTC)

不过现在真的有人一天创建一百个小作品、或小小作品以上吗--Luoniya（留言） 2026年3月7日 (六) 08:31 (UTC)

「一天創建100個條目」只是舉例說明而已，不是我實際觀察到的現象。--Wolfch (留言) 2026年3月7日 (六) 08:34 (UTC)

我其实主要是觉得，现在本站，连有闲心大量建立小小作品的人都已经很少见了。--Luoniya（留言） 2026年3月7日 (六) 08:38 (UTC)

但剛好超過小小作品標準的新條目倒是不少... 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:03 (UTC)

批量一天建立100個小小作品沒有，但批量一天建立100個小作品多年前就已經開始有了。隨便看一下巡查都會知道--某人✉ 2026年3月13日 (五) 14:57 (UTC)

「每人每天不得創建超過100個條目」，那我要@Dawson783：了。--日期20220626（留言） 2026年3月7日 (六) 10:04 (UTC)

還有個問題，那看提刪和創建條目到底算不算是貢獻，如果大量提刪和大量創建條目都無害，那可以放著不管，如果大量提刪有害而大量創建條目無害或者大量提刪無害而大量建條目有害，那就不能一視同仁了。--日期20220626（留言） 2026年3月7日 (六) 10:06 (UTC)

我是覺得大量提刪和大量創建條目都是有害的。--Wolfch (留言) 2026年3月7日 (六) 10:14 (UTC)

🤔理想狀況是能做到大量提刪精確符合刪除條件的條目或大量建立找不到提刪理由的條目，不過應該是後者更容易做到。--日期20220626（留言） 2026年3月7日 (六) 10:19 (UTC)

我认为两者都不应以单纯数量评定，如果说创建过多小作品就被认为有害，那不如禁止创建小作品，而非限制创建数量。对提删则是，判断其是否在游戏规则，也并非着重在数量--Luoniya（留言） 2026年3月7日 (六) 10:19 (UTC)

禁止創建小作品反而無益，這不就是人為抑制中維增加新的知識了。--日期20220626（留言） 2026年3月7日 (六) 10:22 (UTC)

所以我认为以现在限制其创建数量的理由来看，不如禁止创建小条目，两者并无本质区别，而这明显是无益的，故此反对限制创建数量。

当然上面说的小条目显然是不会被删的前提下--Luoniya（留言） 2026年3月7日 (六) 10:24 (UTC)

我覺得應當提高小小作品->小作品的門檻而非禁止小作品 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:25 (UTC)

這個以前討論過幾回，沒成功。--日期20220626（留言） 2026年3月7日 (六) 10:28 (UTC)

現在有了草稿化應該更不會成功 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:29 (UTC)

還是請大家回到「短期內大量創建小小作品/小作品/剛好超過小作品規模的作品好不好？是否有需要限制」來討論吧，謝謝大家。--Wolfch (留言) 2026年3月7日 (六) 10:11 (UTC)

理解提案人憂慮，但合格內容不應限制。至屢次濫建問題內容且不聽勸告者，本站另有規定處置。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月7日 (六) 10:46 (UTC)

一个老问题：“100（或者随便多少）这个数字是如何来的？一拍脑袋想出来的吗？”再者，本站人手是否已经少到无法由人类判断最近更改是否出现异常用户了呢？如果只是出于对大规模编辑超出控制的顾虑，我觉得不必如此。——暁月凛奈 (留言) 2026年3月7日 (六) 11:57 (UTC)

过往应该有过类似讨论。我认为批量创建（和修改）应该是批准制度，按修改规模和讨论进展决定讨论和公示期限。是否要一致同意则不确定。热血创建大量条目而无维护改进在过往有多次，劝解没什么用。单纯限制频次对每日创建到上限没有阻拦作用，限制字数篇幅也拦不住凑字而低质。--YFdyh000（留言） 2026年3月7日 (六) 15:50 (UTC)

我個人是支持「寧濫毋缺」，只要條目內文沒有太明顯問題/錯誤我都覺得能過，不奢求每個條目都滿足DYK嘛。--糯米花🌾🌼 2026年3月19日 (四) 07:56 (UTC)

短時間大批量建立頁面會觸發過濾器，我就觸發過幾次。現有的機制已經足夠限制批量建立條目的情形。--糯米花🌾🌼 2026年3月19日 (四) 07:51 (UTC)

舉例：NT:AREA規定「法律上認定的有人居住地區可被認為典型地符合收錄標準」，若是有人建立bot批量建立中華人民共和國村、社區級的條目，顯而易見這些都會是小作品（甚至是小小作品），但這樣的行動顯然是符合維基百科規則的。--糯米花🌾🌼 2026年3月19日 (四) 07:54 (UTC)

用户白洲梓的編輯

原标题：白洲梓的編輯

各位編者好，白洲梓（讨论 | 貢獻）近期的一些編輯希望能引起注意，

1. 其中在福建省建瓯第一中学的編輯，修改了一些數值，但沒有説明原因。
2. 其中在建瓯市第二中学的編輯，修改了學校的稱呼和簡稱，沒有引用或説明原因
3. 其中在叙利亚内战对黎巴嫩的影响，修改「阿拉伯民主黨」成「阿拉伯民族黨」，説明原因是修正筆誤，但我看到兩種黨派在條目中都有。

我無法判斷此類的編輯是否正常，請各位給予關注或幫忙溝通一下，謝謝。 -Lemonaka 2026年3月10日 (二) 16:50 (UTC)

@Lemonaka，所有的编辑似乎都是没有任何来源，并且也不符合常用名称--Zyx快困死了 2026年3月10日 (二) 16:58 (UTC)

我懷疑這種編輯可能是有害的，也希望更多編者給予檢閲。 -Lemonaka 2026年3月10日 (二) 17:17 (UTC)

@shizhao 請決斷吧。 -Lemonaka 2026年3月12日 (四) 09:39 (UTC)

缺乏来源或理由令人难以接受，但目前看不出该用户虚构或意图破坏条目，似乎应该警告沟通。--YFdyh000（留言） 2026年3月12日 (四) 16:40 (UTC)

已經嘗試溝通，但該使用者不回應。 -Lemonaka 2026年3月12日 (四) 16:43 (UTC)

@Lemonaka Hi, would you consider changing the thread title to clarify that this is related to the behaviour of a user named "白洲梓", not on the article 白洲梓? MilkyDefer 2026年3月14日 (六) 15:45 (UTC)

Sure, already done by others. Thanks a lot. -Lemonaka 2026年3月15日 (日) 13:05 (UTC)

@YFdyh000@Zyx20101210
該用戶再次于米揚魯德將「庫爾德斯坦省」 改爲「胡齊斯坦省」，經查實該編輯合理。伊朗戰爭 (2026年)中將「法斯通訊社」改爲「瓦爾斯通訊社」，這一改動不具有意義。其餘編輯未見明顯問題。需提醒該用戶編輯時正確使用編輯摘要 -Lemonaka 2026年3月22日 (日) 19:26 (UTC)

通讯社似乎是手动修改地区词为大陆用法。客栈讨论中被不当转换了。--YFdyh000（留言） 2026年3月22日 (日) 19:44 (UTC)

新聞動態用詞

不是很大問題，純粹好奇記載傷亡，用「導致」還是「造成」比較符合漢語用法？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月19日 (四) 08:14 (UTC)

感觉是造成。两者都可能包含间接？虽然通常仅统计直接。导致是否更常见于立即。--YFdyh000（留言） 2026年3月19日 (四) 08:45 (UTC)

具體用法很可能需要看上下文。「造成」一般有主動的意思，而「導致」則一般有被動的意思。Sanmosa _风林火山 2026年3月22日 (日) 09:38 (UTC)

@Sanmosa：新聞動態的用法頗為固定，通常是某地發生某案，「造成／導致」幾人傷亡。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月23日 (一) 06:38 (UTC)

還是有些差別的。天災「導致」比較合適，人禍「造成」比較合適。Sanmosa _风林火山 2026年3月23日 (一) 07:49 (UTC)

🤔 —— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月23日 (一) 17:43 (UTC)

不赞成。如电力故障导致病患死亡（直接原因）、造成求助者死亡（叠加因素）。也看不出“造成”更主动，感觉相反。--YFdyh000（留言） 2026年3月23日 (一) 18:03 (UTC)

以後能用的參考來源會不會變得有限？

最近嘗試將條目裡的參考來源換成書籍或報章雜誌，但是我想到一個問題。書本內容都多少會滯後，可是出版業、報社都已經不如以前風光了，這樣以後要找新的參考資料、而且維基百科可以用的，會不會越來越難？紙本資料可能還是有，但是變得很少（而且可能因為相對小眾而有所偏差），畢竟現在資訊流通好像變得更封閉，網站本身都轉型，關站或者變成APP、訂閱制，不能公開查閱、不再是一個網址就能引用的，其他工具例如網路時光機往往無法完整或根本不能擷取，不然就是內容農場、自媒體流傳的各種垃圾。至少這是我編輯要找資料時，感覺如此。--George6VI（留言） 2026年3月23日 (一) 02:54 (UTC)

維基百科反映的是知識沈澱。如果人類儲存知識的型態轉變，本站對參考資料的規範遲早也會。況且對於絕大多數記載過去的條目而言，既有紙本文獻運用依然遠遠不足，甭提「找新的參考資料」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月23日 (一) 06:37 (UTC)