維基文庫:寫字間

←社區

寫字間

存檔→

請另頁請求管理員幫助，力求提高效率。機器人、導入者、管理員、更改用戶名請另頁申請。目前中文維基文庫共有292名活躍用戶，沒有行政員，暫不建議申請。
If you can't speak Chinese, we prefer you to comment at the embassy and our volunteers can help on translating your inputs.

維基文庫項目

維基文庫是什麼

維基文庫與維基教科書

寫字間

投票

版權信息

版權討論

刪除討論

移動請求

保護請求

請求管理員幫助

發言更新圖例

• 最近一小時內

• 最近一日內

• 一週內

• 一個月內

• 逾一個月

特殊狀態

已移動至其他頁面
或完成討論之議題

手動設定

當列表出現異常時，
請先檢查設定是否有誤

版權討論與刪除討論流程和模板問題

在提刪流程中加入「通知頁面創建者」、copyvio和afd模板直鏈到提刪件

讀Zy26閣下的論述中關於新人引導的部分有感，提兩個問題：

1. 能否參考w:Wikipedia:頁面存廢討論#提報過程，將提刪通知頁面創建者一項（本地本就有Template:AFDNote）列為提刪時的操作指引？
2. Template:copyvio和Template:Afd該兩模板是否有可能做到像w:Template:Vfd那樣，鏈接到具體的提報件？

以上出於便利用戶（尤其是新人）和規範流程的目的起見而提出，當中技術小白之處，請輕拍。 銀色雪莉（留言） 2025年6月26日 (四) 17:30 (UTC)

現在的兩個討論頁都是用戶自行去編輯分隔線，和其他社區每一件提報都開一個章節不同，如果換成每個提報都開一個新章節的形式，鏈接到具體提報就會更方便，自行編輯分隔線相較開新章節也對新人更有門檻。 Teetrition（留言） 2025年6月27日 (五) 03:36 (UTC)

提報方面甚至可以學習Commons使用自動化腳本提報+通知貢獻者。 Teetrition（留言） 2025年6月27日 (五) 03:37 (UTC)

由於是技術問題（再次利申小白），在此先向界面管理員@Midleading閣下諮詢上述內容包括Teetrition閣下意見是否有可能實現（題外話：話說本地是不是只剩下一位界面管理員了？），以便決定是否接續討論。 銀色雪莉（留言） 2025年6月28日 (六) 09:41 (UTC)

可以學習其他社區每一件提報都開一個章節，每個月份設置一個提報頁面。這樣對提報頁面版面變動較大，如果通過的話建議從下一年1月1日起實行，屆時可實現提報模板直接鏈接到案件。

至於小工具，我只能說對於目前較低的提報頻率，還不需要投入開發和維護成本去開發小工具。本人現在是唯一界面管理員，元維基全域方針規定至少要有兩個界面管理員，本人目前未辭職為非法界面管理員，建議儘快選舉另一個界面管理員，否則本人可能被迫辭職。 Midleading（留言） 2025年6月28日 (六) 10:34 (UTC)

本人依然認為可以選舉@Shizhao：為介面管理員。或是問問有誰適合擔任？我目前仍是有限期管理員，不適合兼理介面管理員。—— Eric Liu_（留言） 2025年6月28日 (六) 11:46 (UTC)

m:Interface administrators僅建議社群有至少2人懂JavaScript，並未要求必須有2名界面管理員。 dringsim 2025年6月30日 (一) 07:32 (UTC)

文庫現有討論篇幅已經很多，再拆分成章節，恐怕無助於事。其實MediaWiki目前已支援留言直接連結，屆時連結至提刪留言本身即可，不需要更改格式。本人認為，漸進改革試試水溫比較得體。—— Eric Liu_（留言） 2025年6月28日 (六) 11:46 (UTC)

@Ericliu1912：請問MediaWiki目前已支援留言直接連結，屆時連結至提刪留言本身是否能達致和百科vfd模板類似的效果，即點擊後可以連接至案件本身？其實正是因為「文庫現有討論篇幅已經很多」，着實讓人翻找不易，尤其是新手被提刪時可能困擾何處回應或查看案件詳情，故才有此議，若能不用大改而達致相同或接近效果，自然是好的。 銀色雪莉（留言） 2025年6月28日 (六) 13:29 (UTC)

比方說，你可以從這個連結直接通到我的留言。除了自動化可能困難（需要手動通知），其他問題應該不大。—— Eric Liu_（留言） 2025年6月28日 (六) 13:37 (UTC)

我的本意是希望當用戶打開Translation:百字明咒短釋或發到用戶討論頁的Template:AFDNote能夠使用戶一鍵直達提報討論處——自然，最好是自動化的。只能手動添加留言直鏈的話，憂慮沒有太多用戶會注意填寫。不過我最主要的，還是希望推行第一點，即明確要求提刪時應使用Template:AFDNote或留言告知頁面創建者。 銀色雪莉（留言） 2025年6月28日 (六) 14:31 (UTC)

本站似乎沒有Twinkle工具，所以任何通知本來就是手動。至於是否添加直接連結，我想大可以鼓勵。另外，現在刪除討論就一頁，所以祇要有通知，不管有無直接連結，受通知者應該都不難找。—— Eric Liu_（留言） 2025年6月29日 (日) 12:52 (UTC)

本身悉知「本來就是手動」，因此才請教各位是否有自動化可能性，我想即使「本來就是手動」，在此基礎上探討自動化可能性——即便只停留在探討——總是好的，求上得中，求中得下嘛。雖然就一頁，但客觀講確實篇幅並不短（其中在下又臭又長亦略有「貢獻」doge），新人未必好找。還是那句話，我拋磚。眼下第一點似乎還沒有什麼反對意見，期待各位更多意見。 銀色雪莉（留言） 2025年6月29日 (日) 13:17 (UTC)

理解改為章節模式後也方便存檔（雖然本站並沒有自動存檔機器人），最終刪除的作品姑且不論，至少對於那些標記保留的作品，對後人提刪更有參考作用（比搜索存檔來得直觀）。 Teetrition（留言） 2025年6月30日 (一) 09:03 (UTC)

我自己倒沒有太強烈的偏好——能自動化，怎麼都好；不能自動化，就無所謂了（笑）反正這項如果沒能共識，能把其他談下來也很好。您對提刪需通知頁面創建者一項意見如何？ 銀色雪莉（留言） 2025年7月1日 (二) 03:33 (UTC)

 支持 Teetrition（留言） 2025年7月1日 (二) 11:51 (UTC)

(！)意見 如果這項通過以後有的用戶像紅渡廚一樣長期大量提報，但是從來不通知頁面創建人，需要怎麼處理？ Midleading（留言） 2025年7月2日 (三) 12:44 (UTC)

你非要扯上我是幹什麼？維基百科都不要求強制通知，你不是很喜歡扯維基百科怎樣怎樣嗎？這會兒你又不說維基百科了？ ——— 紅渡廚（留言・貢獻） 2025年7月2日 (三) 12:54 (UTC)

現在還沒有通過要強制通知呢，通知不通知隨便，只是討論。 Midleading（留言） 2025年7月2日 (三) 12:57 (UTC)

你明知通知不通知隨便，非要把我扯上是幹什麼？還跟我寫上一句「像紅渡廚一樣長期大量提報，但是從來不通知頁面創建人」，你沒事找事吧你？ ——— 紅渡廚（留言・貢獻） 2025年7月2日 (三) 13:05 (UTC)

我說的是真話吧，2025年至今沒見過閣下提報時通知頁面創建人。如果閣下反對提報時通知頁面創建人，應該在這裡表示反對啊，通知閣下過來有必要。 Midleading（留言） 2025年7月2日 (三) 13:16 (UTC)

那麻煩你別像我做錯事了一樣的口氣在這裡講話。 ——— 紅渡廚（留言・貢獻） 2025年7月2日 (三) 13:29 (UTC)

既然閣下來了，如方便時能否請閣下談談您對關於本話題下兩件的看法？畢竟閣下是兩項討論的常客——其實我本意是準備在整理好2.0版本（即收集一下初步意見的基礎上提出的改善件）再請包含閣下在內的活躍於刪除討論和版權討論的用戶等提供意見的，不過既然閣下來了，相請不如偶遇。 銀色雪莉（留言） 2025年7月2日 (三) 13:04 (UTC)

1. 關於刪除討論，我的意見是推薦各位提刪人在提刪時通知，但不應強制。因為在刪除討論這方面更有經驗的維基百科同樣沒有強制要求；
2. 關於版權討論，我的意見是不推薦各位提刪人在提刪時通知，但也不反對。因為版權討論有其特殊性，很多上傳者就算參與討論了，其實自己也說不清楚什麼版權不版權的，實際能說清楚的就那麼幾個人，說白了還是由那麼幾個人的討論結果來決定。提醒不提醒的重要性不大。

——— 紅渡廚（留言・貢獻） 2025年7月2日 (三) 13:42 (UTC)

感謝。在下粗糙的兩項設定主要都是顧慮到照顧貢獻者的知情權——我個人認為這是維繫社群穩定（尤其是新人）的一個有效因素，畢竟如果自己的貢獻在未通知或溝通下被刪除——雖然刪除的結果意味着它不符合收錄方針或版權方針——不免會帶來一些情緒上的消極因素，這也可能影響他們的後續貢獻的意欲；而且趁此機會給予用戶（尤其是新人）在收錄方針和版權方針方面的指引，應該也絕非壞事；此外，雖然我並不認為「實際能說清楚的就那麼幾個人」，但如果真是那樣的話，那麼通過引導貢獻者參與討論來讓能說清楚的人變多一點，也是好事——那麼「那麼幾個人」的工作量也能減輕了2333。至於百科方面的經驗，一來像您之前說的，文庫不是百科的附庸——我個人傾向於結合實際情況下的蕭規曹隨；二來，事實上百科對刪除的方針性表述中含有「如可能，應通知頁面的創建者」——這或許表面看着不像強制性表述，但我認為這意味着「只要有可能，就要通知」——而我實在想不到有什麼主觀方面的「不可能」足以阻礙這種在我看來是客觀的「有可能」。當然，我認為這樣做最重要的作用還是在於完善整個流程，能夠照顧到的就照顧一下，減少不必要的質疑和扯皮。不過這當然是我的個人意見。 銀色雪莉（留言） 2025年7月2日 (三) 14:09 (UTC)

我同意照顧貢獻者知情權，對於此事我不持有反對意見，若日後規定強制提醒，我會照做。 ——— 紅渡廚（留言・貢獻） 2025年7月2日 (三) 14:26 (UTC)

這項沒通過以前的情況不必討論，現時不是硬性規定，不可能要求人遵守。鑑於我認為此項應列入Wikisource:刪除守則，而且我認為這條應該是必要性要求，因此我提議的表述是「應通知頁面創建者」，所以如果不遵守，就跟普通的不遵守其他方針指引一樣，循序漸進處理。我個人對紅渡廚閣下對指引的遵守性不持懷疑態度——就我的觀察，其在百科存廢那邊也是正常添加通知模板的。 銀色雪莉（留言） 2025年7月2日 (三) 13:01 (UTC)

其實百科方面規定「如可能，應通知頁面的建立者。」基本就是強制通知。我看過提報者沒通知，導致整個討論以程序無效結案的；甚至沒記錯的話，我自己也在這問題上栽過跟頭。就事論事，文庫方面自不必如此嚴格，但至少「推薦（甚至鼓勵）通知」，我覺得屬於比較穩妥的建議。—— Eric Liu_（留言） 2025年7月2日 (三) 14:08 (UTC)

我贊成百科方面的規定基本——在我看來可以說是「幾乎」——就是強制通知，理由上述不贅。作為不時參加兩項討論的人，慮及之前一些各方面的爭執，強制要求（除了部分規程性快刪，下已述不贅）在我看來並不影響提刪者任何自由或權益，但確是對被提刪者的知情權的保障，也能減免一些不必要的扯皮——推薦或鼓勵，還是會有扯皮的；像上面的「幾乎」，也會有扯皮。人多的地方，慣例的力量大，人少的地方就不一定了；鑑於此項無傷大雅，我認為不如劃成「除非客觀無法通知，否則應通知頁面建立者」，但求不扯皮——因為我實在想不到「通知」到底能影響提刪者什麼（PS：再次重申，部分規程性快刪應該豁免）；如果有，請各位告訴我。 銀色雪莉（留言） 2025年7月2日 (三) 14:18 (UTC)

在版權、刪除討論及快刪流程中釐清管理員權限使用指引

考慮到管理員兼具普通用戶和執行共識用戶的身份，為釐清相關身份定位，以便利各方面，在此建議部分參考w:WP:CLOSEAFD和w:WP:SD，在Wikisource:刪除守則中加入以下要求：

1、在「共識」一節末尾加入「在版權及刪除討論中得出的對被提刪頁面的處理方式（例如保留、刪除、合併、重定向）的共識須由一名未參與該案件提刪和討論的管理員執行。」

2、「快速刪除」一節改為：

如果頁面符合快速刪除的標準，請加上{{Sdelete}}模板，不用提交到Wikisource:刪除討論中。加了模板的頁面會自動收入Category:快速刪除候選分類，管理員就能看到了。加入模板時，請寫明刪除原因，用法：{{sdelete|删除原因}}。如果不符合快速刪除的標準，請提交到Wikisource:刪除討論。
維基文庫的方針允許管理員在頁面符合一個或以上的快速刪除標準時，直接快速刪除頁面；若遇有不確定的情況，則應轉交刪除討論或版權討論。管理員須避嫌，不得處理自己的快速刪除請求。

以上，在此徵詢諸位意見。--銀色雪莉（留言） 2025年6月28日 (六) 09:52 (UTC)

文庫社群基數較小，我認為不應該直接禁止管理員同時參與任何討論及結案，尤其是在某些共識明確的情況。是否可以增加一些但書，或是弱化指引語氣？—— Eric Liu_（留言） 2025年6月28日 (六) 11:48 (UTC)

我不排斥根據社群實際情況調整——我又不覺得人多2333但一定的限制是必須的。我看（1）至少要不允許管理員在作為提刪者的同時又可以結案，這是基本的程序需要；（2）如果管理員不是提刪者但是是參與討論者，那麼至少應使他們在作出處理動作前作必要的共識概括並通知所有參與討論者，采類似公示的形式（或者說，有點類似w:WP:RSN），如何？ 銀色雪莉（留言） 2025年6月28日 (六) 14:52 (UTC)

實際情況是少數幾個活躍用戶需要管理四十餘萬個頁面，經常審理刪除請求、執行刪除操作的管理員人數很少，但是可能需要刪除甚至完全應該快速刪除的頁面很多，並且有相當一部分現在還沒有任何人提報。有很多快速刪除的頁面都是我專門查出來，查出來就立刻快速刪除而不需要打擾社群的。 Midleading（留言） 2025年6月28日 (六) 12:49 (UTC)

也行，不少姊妹項目似乎都沒有這一條，我不反對刪去此條。但我想徵詢一點作為刪去此條的補充措施，即因應上節在下提出將提刪事宜通知頁面創建者作為刪除討論和版權討論流程的一部分，快刪似亦應將結果通知頁面創建者或主要貢獻者，以滿足基本的程序需要，如何？ 銀色雪莉（留言） 2025年6月28日 (六) 15:27 (UTC)

同意快刪時應當儘量通知頁面創建者或主要貢獻者。刪除純粹破壞內容，由頁面創建者或主要貢獻者通過添加Sdelete等模板或者直接清空頁面等方式自行要求的快刪，或者頁面創建者或主要貢獻者已經被封禁的除外。 Midleading（留言） 2025年6月28日 (六) 15:43 (UTC)

個人認為可以。看看其他用戶有無補充，我先把那句拉掉。等最後匯總的時候再合併公示。 銀色雪莉（留言） 2025年6月28日 (六) 15:47 (UTC)

還有一種情況只在維基文庫頻繁出現，就是申請移動頁面且不留重定向，或者是移動頁面後申請快速刪除重定向，原因多半是繁簡不當或者是消歧義樣式不當。對這樣的快速刪除閣下怎麼看，本人通常只給新手發送提醒，而老手不需要過度提醒。 Midleading（留言） 2025年6月28日 (六) 16:03 (UTC)

本地基本沒有太多原創命名的空間，都是照原件來，而且Wikisource:移動請求要經管理員覆核，也有其他用戶活動，只要所提供依據和資料經審視足以證明，只是更正名稱，應該不需要通知頁面貢獻者。自行移動頁面後申請快刪重定向，個人其實不贊成這麼做——除非是顯而易見的錯別字或是消歧義樣式不當——不然想要刪重定向還是應該提刪除討論，以免查證不足時實際上刪去了可作為有效重定向的一些別名頁面。我建議管理員這種情況下方便查資料就查資料，可以保留的就撤銷快刪，不能保留的直接刪掉，按Wikisource:刪除守則中「例程刪除」一類，應可不必通知（如果是新人，我贊成您說的提醒一下，這是善意，也是好事，有利於其明晰情況）；不便查資料或者吃不準時，可以移交刪除討論，那就自然要通知創建者。 銀色雪莉（留言） 2025年6月29日 (日) 05:01 (UTC)

如果只是「顯而易見的錯別字或是消歧義樣式不當」這種類別，這種快刪我看也可以按「例程刪除」一類，一般應可不必通知——若新人的話，提醒一下當是引導，也無不可。 銀色雪莉（留言） 2025年6月29日 (日) 05:03 (UTC)

@Midleading、银色雪莉：快速刪除候選通知應該比照普通刪除請求，由提報人而非管理員作出。其他規則也可以準用上述討論中之刪除請求通知程序，不必寫兩套指引。—— Eric Liu_（留言） 2025年6月29日 (日) 12:52 (UTC)

@Ericliu1912：前述在談的作通知者，本身即指提報人——讀上述討論時可把Midleading閣下看作此身份。我的看法是本地當前實況時，程序類快刪通知似可省去以合理地簡化部分流程——但能上刪除討論者必定是因為非程序類問題，因此應均通知以求程序完善。由此，此二類似仍應有所差別。 銀色雪莉（留言） 2025年6月29日 (日) 13:24 (UTC)

2.0（Wikisource:刪除守則修訂案）

個人淺見提出後，在上方與部分用戶作了些討論，蒙指正獲益良多，在此先行致謝。有鑒前述討論中似尚未見根本性的反對或否定意見，而原方案亦有不少未妥善處，因此在綜合前述各位的指正和意見碰撞下，謹擬出第二版修訂方案，以進一步在更大範圍內徵求意見，亦請各位不吝指教。PS：原兩話題因均牽涉各項提刪流程，是以在此擬合為一件不再分述，各項內容以對Wikisource:刪除守則的修訂案的形式綜合呈現。

現行條文 共識 如果你懷疑一篇條目侵犯版權，請在Wikisource:版權討論中提交，如果你認為一篇條目不應該在維基文庫上出現，但有不符合以下提到的任何快速刪除的標準，請在Wikisource:刪除討論中提交。 在Wikisource:刪除討論中會討論一周左右，而在Wikisource:版權討論中一般會討論兩周左右。儘管任何人都可以討論提名，但只有社群認可的編輯的投票才有分量。 快速刪除 維基文庫的方針允許管理員在頁面符合一個或以上的快速刪除標準時，直接快速刪除頁面。如果不符合快速刪除的標準，可以提交到Wikisource:刪除討論中。如果頁面符合快速刪除的標準，請配上{{Sdelete}}模板，但不用提交到Wikisource:刪除討論中。加了模板的頁面會自動收入Category:快速刪除候選分類，管理員就能看到了。加入模板時，請寫明刪除原因，用法：{{sdelete|删除原因}}。

提議條文 版權討論/刪除討論 如果你懷疑一個頁面侵犯版權，請加上Template:Copyvio並在Wikisource:版權討論中提交。如果你認為一個頁面因非版權原因不應該在維基文庫上出現，但又不符合以下提到的任何快速刪除的標準，請加上Template:Afd並在Wikisource:刪除討論中提交。在提交討論的同時，請到該頁面的創建者（創建者自行提刪除外；另外，如需要時，亦可包括該頁面的其他主要編者）的討論頁發出頁面已被列入版權/刪除討論的通知（可使用Template:CopyvioNotice和Template:AFDNote）。 一般情況下，在Wikisource:刪除討論中會討論一周左右，而在Wikisource:版權討論中會討論兩周左右。儘管任何人都可以提報及參與討論，但只有社群認可的言之有理的見解才有分量，管理員應基於由這樣的見解所形成的共識執行結案處理（例如保留、刪除、合併、重定向），並應迴避對自己在版權/刪除討論中提報的頁面執行結案處理。 快速刪除 如果頁面符合快速刪除的標準，請加上Template:Sdelete模板並附原因，不用提交到Wikisource:刪除討論中；加了模板的頁面會自動收入Category:快速刪除候選分類，管理員就能看到了。如有必要時，提報者可到該頁面的創建者（如需要時，亦可包括該頁面的其他主要編者）的討論頁發出頁面已被列入快刪的通知。如果不符合快速刪除的標準，請提交到Wikisource:刪除討論。 維基文庫的方針允許管理員在頁面符合一個或以上的快速刪除標準時，直接快速刪除頁面；若遇不符合或不確定是否符合快刪標準時，則應轉交刪除討論或版權討論。

修訂說明

1、修訂「共識」一節標題為「版權討論/刪除討論」，以明晰其含義，並與下文「快速刪除」小節的標題保持對應。

2、在提交版權/刪除討論的流程中明確要求提報人在提報時添加對應的頁面維護模板和用戶提醒模板。

3、有鑑於多年實踐中版權/刪除討論一向奉行「請以理服人，言之有理，不是一定少數服從多數的以力服人，所以IP用戶可發言，不是投票，不應用Wikisource:投票#各式投票資格」的底層邏輯，為釐清表述，調整「只有社群認可的編輯的投票才有分量」為「只有社群認可的言之有理的見解才有分量」，以保持邏輯上的一致，亦表明相關討論並非由「資深編輯」把控（原有的表述，「社群認可的編輯」容易被認為是看資歷）。

4、強調管理員應基於「社群認可的言之有理的見解」而形成的共識執行結案操作，並設置要求管理員迴避對由其自身提報的頁面進行結案操作。版權/刪除討論並非投票，同時亦非字面意義上的「共識決」——那就會淪為另一種投票，而應基於言之有理的說理為大前提；同時，也約束管理員注意執行結案操作的基礎與方式。

5、就快刪的用戶通知不比照版權/刪除討論的用戶通知要求一事，個人意見是：快刪本意是對明顯有問題的頁面作出快速應對處理，如果明顯的，則這種通知更多是出於一種社群對用戶的引導，與刪除/版權討論的可能強爭議性的屬性並不相同，應可采推薦制而非必要制，且現有刪除守則中實際上已列出較仔細的各類流程操作，也一定程度上對此類問題可能導致的處理不當作了約束；如不明顯或有爭議的頁面，應該轉交，屆時自然會通知用戶。因此，更需要的是規範刪除/版權討論和快刪之間分流流程、快刪的處理流程（包括轉交流程）和刪除的恢復流程。（PS：作為配套，認為如有需要，或可考慮導入w:Template:Db-notice並本地化。）

6、對部分用詞作了調整，如現行條文中的「條目」等表述，並不適合本地，而各提報流程牽涉的範圍又不僅僅是文獻，因此一律調整為「頁面」。

討論區

由於相關修訂為對方針的修訂，需要更顯著的共識基礎；同時，相關版面（1）確實涉及部分相關方針、指引或知識；（2）對在相關版面活動的用戶（含管理員）的權責約束有所調整。因此，在此邀請就在下所見活躍於相關版面的用戶@红渡厨、Zy26、Njzjz、Teetrition、Aerotinge、晞世道明、沈澄心、Kcx36、Fire-and-Ice、Andayunxiao、Liuxinyu970226（不免掛一漏萬，多請擔待）及所有管理員@Jusjih、Shizhao、Gzdavidwong、Zhxy_519、Hat600、Midleading、Ericliu1912參與討論；同時，上述邀請並非意在小圈子討論，在下謹請其他所有用戶若有見解時不吝就此件指正。希望藉此能凝聚共識，對可能是本地最重要的站務之一的版權/刪除討論等內容的相關規則作出必要修訂。--銀色雪莉（留言） 2025年7月7日 (一) 07:28 (UTC)

關鍵是本站如何定義「快速刪除」標準。 Liuxinyu970226（留言） 2025年7月7日 (一) 07:39 (UTC)

這裡根本就沒有提到「快速刪除」標準的修訂吧，看不出和本討論有何關聯性或者關鍵意義。 Midleading（留言） 2025年7月7日 (一) 07:41 (UTC)

您是說適用快刪的情況嗎？原守則的「快速刪除」一節下方就有列出，您是否認為當中也有需要調整或加添的部分？如果有的話不妨提出，也可以再作整合。不過快刪標準在廣義上講應該大差不差，細分項即使要修訂，應該也不至於根本性影響關於快刪操作流程等事宜的規定。 銀色雪莉（留言） 2025年7月7日 (一) 08:14 (UTC)

我加一條，在版權/刪除討論案件中表態過的管理員，亦不應對該案件執行結案處理。 ——— 紅渡廚（留言・貢獻） 2025年7月8日 (二) 07:29 (UTC)

「表態」是否包含詢問社群意見（即「留言」）？抑或限於明確表示立場者？—— Eric Liu_（留言） 2025年7月8日 (二) 14:28 (UTC)

我不清楚你是指何種「詢問社群意見」，但為穩妥起見，避免存在管理員不避嫌的疑慮，我認為只要是發言過的，均應不對該案件執行結案處理。管理員人數是夠的，沒必要一定由那個人來結案。 ——— 紅渡廚（留言・貢獻） 2025年7月8日 (二) 14:57 (UTC)

我想他指的是這種Special:diff/2504142，我也想確認一下，即閣下所說的是否包括這一類。 銀色雪莉（留言） 2025年7月8日 (二) 15:25 (UTC)

我認為這種回復可以視作作為管理員匯聚共識，可以不視為普通用戶的討論行為。 ——— 紅渡廚（留言・貢獻） 2025年7月9日 (三) 14:49 (UTC)

另外，我正好想到，你在維基百科的存廢中，存在既作為普通用戶對存廢發表意見，同時又作為管理員對同一案件進行結案的事情。 ——— 紅渡廚（留言・貢獻） 2025年7月8日 (二) 15:05 (UTC)

看看實際數據再說管理員夠不夠吧，從數據可以看出，只要經常參與刪除的前兩個管理員同時發言，就算這兩個管理員都支持刪除，該頁面被刪除的機會也會下降88%，因為根據這個規則一發言就不能刪除了。維基百科都支持的事情本地為什麼不支持呢？ Midleading（留言） 2025年7月8日 (二) 17:06 (UTC)

你的實際數據恰恰說明管理員人數足夠。但問題在哪？問題在當上管理員後不願意幹活。 ——— 紅渡廚（留言・貢獻） 2025年7月9日 (三) 14:50 (UTC)

管理員不願意幹活並沒有違反任何維基文庫方針，要賄賂他們履行職責嗎？明明有活躍的管理員可以履行職責，為什麼要等待不願意幹活的管理員呢，現在就有這樣的案例，刪除請求從2019年持續至今仍在等待一個特定管理員結案。 Midleading（留言） 2025年7月10日 (四) 02:52 (UTC)

我可沒說他們違反方針。反正隨便你吧，你不怕有人以後投訴你不避嫌，那你就去結案唄。 ——— 紅渡廚（留言・貢獻） 2025年7月10日 (四) 02:58 (UTC)

情況更新：慮及本地有指引級Wikisource:管理員（以下簡稱「指引」），其中「避嫌」一節有「管理員不得刪除自己提議刪除或者投票刪除的頁面」及其例外情況說明，這與上方修訂案及其他用戶修正修訂案的表述存在留有真空地帶的衝突。雖說刪除守則作為方針可能位階更高，或許不必顧慮指引，但一般而言，為了實用性和避免不必要的爭議，沒有道理不使它們保持邏輯上的一致。我並不打算修訂指引——那樣事情就沒完沒了了，而且這本是刪除守則自身的事。因此，在前述基礎上，我擬將修訂案第一節第二段的內容替換為：

一般情況下，在刪除討論中會討論一周左右，而在版權討論中會討論兩周左右。儘管任何人都可以提報及參與討論，但只有言之有理的見解才有分量，管理員應基於由這樣的見解所形成的共識執行結案處理（例如保留、刪除等）。管理員對於自己在版權討論或刪除討論中所提報，或曾對其去留表態的頁面，應迴避處理，而當共識形成時，亦應通知第三方管理員代為結案；惟若自通知起兩周後（對自己就其去留表態的頁面）或四周後（對自己提報的頁面）仍無第三方管理員處理時，該管理員則可依共識自行斟酌執行結案處理。

註：部分作了微調，如「社群認可的...見解」與「由這樣的見解所形成的共識」語義不免累贅，去其一；鑑於本地工作是錄入原始文獻，因此合併或重定向關鍵還是看原始文獻的情況，也並不必須由管理員執行，因此似不必在管理員事務流程中作太細的約束（這不是說刪除討論就不處理這些事，只是說它是一個只要共識了一般誰處理都問題不大的事）；加入對部分情況聯繫第三方管理員處理的要求，作為根據指引提出的但書的抵沖。 銀色雪莉（留言） 2025年7月10日 (四) 13:58 (UTC)

我對此修改案不持有反對意見。 ——— 紅渡廚（留言・貢獻） 2025年7月10日 (四) 14:43 (UTC)

微調表述，本意不變。--銀色雪莉（留言） 2025年7月10日 (四) 15:46 (UTC)

目前暫無明顯反對意見，徵詢在本件參加討論較多的@Midleading、Ericliu1912意見，看接下來是作公示7日還是需要走投票？--銀色雪莉（留言） 2025年7月19日 (六) 14:56 (UTC)

我再調整了一下行文。此案已可考慮交付公示。—— Eric Liu_（留言） 2025年7月19日 (六) 21:55 (UTC)

• 以2.0案及其後「情況更新」修正案，公示7日。--銀色雪莉（留言） 2025年7月20日 (日) 12:31 (UTC)

  恕我現在才發表一點懶人懶言，反對「通知第三方管理員」一點。一是比如說很長的討論本來確定「共識」就很難；二是即使管理員少，我個人也沒見過各種語言各項目還要這一步（即使真有也相信為極少數），這一步驟相當多餘；三是對可能對管理員造成通知地獄，反而會令人心生厭煩。 Zhxy 519（留言） 2025年7月20日 (日) 15:08 (UTC)

  @Zhxy 519：不否認共識的形成有時確實是困難的，但「共識並不強求一致」，關鍵還是能否有言之有理的意見，沒有什麼規章制度是能完全迴避需要下判斷的風險的，制度上謹慎一點總是對各方（包括管理員）都是一種保障，也避免了角色衝突，程序上至少通順些。要求由第三方管理員關閉頁面存廢類型的討論見諸於百科的w:WP:CLOSEAFD，而更進一步要求「請求未涉事的第三方管理員處理事件」的類似規定也見諸於w:WP:避嫌和本地的Wikisource:管理員#避嫌，我想百科作為中文維基項目中體量最大也確乎在頭面地位的項目，如果要算作是「極少數」，那應該是很有力的「極少數」——但我認為「通知第三方」是可以透過Wikisource:請求管理員幫助頁面提出而非一定要ping每個人或是在每個人的討論頁中留言（如果我們能就這一點達成共識，我不反對在行文中在「通知第三方管理員」處加入「（如Wikisource:請求管理員幫助）」的說明字樣，這種舉例在w:WP:避嫌也有出現——當然如果誰喜歡ping人那也是自由的），而且後續的一定條件下兩周四周允許涉及提報的管理員自行斟酌處理也已經充分鬆動——這種情況下，要求通知第三方，我認為是合理的安排。 銀色雪莉（留言） 2025年7月20日 (日) 15:43 (UTC)

  一和三綜合一下，我尊重參與討論的用戶在討論過長而其實已經有一定共識的情況下，在討論最下方以非ping的方式告知全體管理員（而非刻意強調第三方），也認可這是非常友善的做法，唯獨不贊成去Wikisource:請求管理員幫助，因為太繞遠了。第二點從規則來講，遵守沒有問題，我也同意今後管理員本人提刪等待四週，但是和專門「通知」還是不一樣的。 Zhxy 519（留言） 2025年7月20日 (日) 20:11 (UTC)

  想了想，修訂重點放在避嫌，應該可以將「通知第三方管理員代為結案」改為「等待第三方管理員代為結案（亦可主動通知）」？後面的「惟若自通知起兩周後（對自己就其去留表態的頁面）或四周後（對自己提報的頁面）仍無第三方管理員處理時」，則可以改為「幾日以後沒有表達新立場的留言」之類，再看怎麼措辭。—— Eric Liu_（留言） 2025年7月21日 (一) 00:34 (UTC)

  @Zhxy 519、Ericliu1912：外游剛結束，才能回復兩位。原「通知」並沒有明確指明要以何種方式通知，我並不反對在討論下方通知（或「告知」），我自己在Wikisource:版權討論#4月也這麼處理，後續處理者正是Zhxy 519，這同樣是我認為的「通知」的一種。同意「修訂重點放在避嫌」，因此相關約束並不是約束任意「參與討論的用戶」，而是約束「提報，或曾對其去留表態」的管理員，不允許他們自行在無共識的情況下概括共識或太早的情況下就結案，這會導致角色衝突；因此與其說是所謂「刻意強調第三方」，倒不如說「前述的情況下儘可能由其他管理員處理（除非已經歷一定前提下的一定時長），至於是在討論下方告知還是如何通知，這是個人選擇的事，沒有人可能禁止別人或要求別人去什麼地方通知」。我認為可以將「...而當共識形成時」以後的內容改為「亦應在討論下方公示並等待或通知第三方管理員代為結案；惟若自公示起兩周後（對自己就其去留表態的頁面）或四周後（對自己提報的頁面）仍無第三方管理員處理時，該管理員則可依共識自行斟酌執行結案處理。」 銀色雪莉（留言） 2025年7月24日 (四) 02:56 (UTC)

  通知為自願，文庫用戶做沒有問題，但是不必強制明文化，所以Eric Liu的寫法明顯更好，因為不是「應」。 Zhxy 519（留言） 2025年7月24日 (四) 17:12 (UTC)

  請仔細閱讀「等待或通知」——閣下總不會覺得連等待也是「自願」吧？至於「公示」，作一個宣示是應該的，有利於自此開始計算時間節點。還有，文庫普通用戶怎麼做並沒有在這裡被約束——這裡是約束諸位身兼管理員權限者在自己提報或參與討論時，以免出現角色衝突，這我此前講過多次了，所以「文庫用戶」當然不必「強制明文化」，但我們也並不是在約束廣義上的「文庫用戶」。

  事實上Eric Liu的寫法也沒有改動「亦應」，他是從「通知」兩字開始改動的，我與他的方案在意義上並無差別，「公示」的部分則是為了回應其後半部分的「再看怎麼措辭」，不作「應」公示的設定則時間節點計算無從談起。另外，我考慮了一下，既然提到了公示，那麼參考w:WP:7DAYS，補充如下：「亦應在討論下方公示並等待或通知第三方管理員代為結案；惟若自公示起兩周後（對自己就其去留表態的頁面）或四周後（對自己提報的頁面）仍無第三方管理員處理時，該管理員則可依共識自行斟酌執行結案處理，但公示期間若有言之有理的見解，公示期應中止，繼續討論相關見解直至共識形成，則可重行公示共識，此前公示時間不累計。」 銀色雪莉（留言） 2025年7月25日 (五) 02:46 (UTC)

  他是從「通知」兩字開始改動的不假，不過這樣就更好地規避了通知的強制性。要麼通知要麼等待，也還是比一個括號裡的可字強制性更強。所謂公示我認為這裡和通知是差不多的東西，更不必刻意去寫。 Zhxy 519（留言） 2025年7月25日 (五) 16:58 (UTC)

  第一，不管上述哪種表述，管理員都可以選等待，沒有人強制你選「通知」，選等待是合規的，我看不出閣下稱「強制性更強」的論理依據——除非閣下認為應該允許管理員對自己在版權討論或刪除討論中所提報，或曾對其去留表態的頁面採取其他做法，那麼請閣下把這種做法說出來大家參詳。第二，提報或表態的管理員完全可以不做公示，但這些管理員就不應該被允許——即便在相隔一定時間後——自行結案，因為那就是角色衝突的不避嫌。我再改一版吧：

  「...管理員對於自己在版權討論或刪除討論中所提報、或曾對其去留表態的頁面，均應迴避以管理員身份處理該頁面，須等待（亦可通知）第三方管理員進行處理。惟當頁面的處理共識已清晰時，提報或曾對其去留表態的管理員可在討論下方公示這一共識，若自公示起兩周後（對自己就其去留表態的頁面）或四周後（對自己提報的頁面）仍無第三方管理員處理時，該管理員才可依共識自行斟酌執行結案處理；但公示期間若有言之有理的見解，公示期應中止，繼續討論相關見解直至共識形成，則可重行公示共識，此前公示時間不累計。」 銀色雪莉（留言） 2025年7月25日 (五) 18:49 (UTC)

  另，公示與通知顯著不同，不寫，則時點無從計算，也留下了隨意計算時間的空子。我還是那句話：提報或表態的管理員完全可以不做公示，沒有任何規定相逼這些管理員要這麼做——那就在該件中不要由自己結案就好，踏踏實實做一個普通用戶，迴避對其以管理員身份操作，這不是什麼難以辦到的事。 銀色雪莉（留言） 2025年7月25日 (五) 18:54 (UTC)

  總歸都是等四週，那麼等待就不僅是合規，而是必須的，通知不過是為了加快速度的的可選項。我現在認為閣下前一版幾乎沒提公示，現在提出十分突兀，具體就公示一點我現在想看看其他人怎麼想。 Zhxy 519（留言） 2025年7月28日 (一) 13:38 (UTC)

  如果提案或表態的管理員有結案的意思，那麼等待四周（或兩周）是必須的，問題在於從什麼時候開始算這個等待，不能自由心證，否則只仍然是造成角色衝突，而公示就是一種時間節點的宣示。在討論中不斷精進案文、提出修正案並供討論是正常的，並無任何人稱就即刻要以此案生效或不經討論就推進修訂，因此難稱為「突兀」；我完全贊成徵求其他意見，在此除了有勞@Midleading、Ericliu1912、Teetrition、Liuxinyu970226、红渡厨等曾在本件中發言的用戶審視外，也繼續請其他用戶審視經討論和修改後的案文，並提議可在頂端布告此事的討論。 銀色雪莉（留言） 2025年7月28日 (一) 14:28 (UTC)

  @銀色雪莉我其實有條件支持「通知第三方管理員」，條件如下（任意一項）：

  1.當相關被提刪稿件至少有插入一張共享資源圖片時，因為顯而易見如果這種情況稿件侵權了，那麼66.666%概率圖片也侵權了（非得糾結剩下33.334%麼）

  2.當有關稿件系從維基百科等外站導入時（且需在源站自創建之日起有一些後續可信編輯）

  3.當有關稿件實質調用維基數據相關結構化數據時（而不只是被維基數據跨語言鏈接到，那種太普遍了） Liuxinyu970226（留言） 2025年8月9日 (六) 04:29 (UTC)

  @Liuxinyu970226：我的第三方管理員，指的是站內的管理員，目的是約束站內管理員在此類站務上避免角色衝突。所以我不太了解這和您提到的條件的關聯性，能否詳細說明一下？ 銀色雪莉（留言） 2025年8月9日 (六) 04:54 (UTC)

  @銀色雪莉涉及跨維基協作問題的確需要謹言慎行，甚需跨站溝通，我沒什麼更多需要解釋的了。 Liuxinyu970226（留言） 2025年11月19日 (三) 13:51 (UTC)

這個[[template:*]]能否改成{{tl|*}}？ Pawsdt（討論 | 貢獻） 2026年4月20日 (一) 10:35 (UTC)

制訂機器人方針

現時維基文庫:機器人除「機器人提議」和「機器人註冊」2個討論串外，僅規定「本wiki允許全局機器人和自動批准的機器人」，而沒有其它規定。經審視本站各機器人賬號，發現以下問題：

• 有的機器人未經批准就添加任務；
• 有的機器人長期不活躍，機器人賬號可以遠高於人類編輯的速率操作，編輯和日誌操作默認從最近更改中隱藏，此類賬號若被盜而用於破壞將造成更大危害，因此如同IP封禁豁免者和管理員等一樣，長期閒置的賬號應收回權限；
• 有的機器人獲批的任務已不能再執行（例如維護跨語言鏈接等），早應收回權限；
• 有的機器人沒有在用戶頁使用{{Bot}}正確標註信息。

不活躍超過1年的機器人

機器人賬號	所有者	最後編輯時間	用途	IP封禁豁免
350bot	Fish bowl	2024-05-03	經人工審批寫入生僻字

不活躍超過2年的機器人

機器人賬號	所有者	最後編輯時間	用途	IP封禁豁免
CrowleyBot	Crowley666	2021-10-11	Wikisource:寫字間/存檔/2021#關於刪除wikisource名字空間下所有跨名字空間重定向的提案（任務已完成？） 用Wikidata取代跨語言鏈接（任務已完成？） 未經批准運行錯字修正等任務	是
Njzjzbot	Njzjz	2023-01-06	導入國家法律法規數據庫
Yinyue200Bot	Yinyue200	（從未運行，2022-09-04取得權限）	導入國務院文件	是

不活躍超過5年的機器人

機器人賬號	所有者	最後編輯時間	用途	IP封禁豁免
Alexbot	Alexsh	2009-11-15	雙重重定向修復 跨語言鏈接（不再適用） （機器人用戶頁列出了其它任務，但沒有經過批准）
AvicBot	Avicennasis	2020-02-20	雙重重定向修復 跨語言鏈接（不再適用）
AvocatoBot	Avocato	2012-09-16	跨語言鏈接（不再適用） （未能查詢到批准記錄及權限日誌，屬自動批准？）
Interwiki-Bot	DeirdreAnne	2011-03-05	跨語言鏈接（不再適用） （自動批准）
KtBot	KaiesTse	2009-01-24	「協助導入工作」，實際執行修正標點等任務
Liangent-bot	Liangent	2012-04-05	錄入文本等
P-bot	PhiLiP	2011-04-13	（未能查詢到批准記錄，由原行政員Vipuser授權）
Vizbot	Viztor	2019-08-15	替換過期的模板、進行格式性修正等
Wikisource-bot	多名用戶	2018-08-10	Wikisource:寫字間/存檔/2018#Bot_rights_for_User:Wikisource-bot（任務已完成？）
タチコマ robot	とある白い貓	2017-03-21	雙重重定向修復 （未能查詢到批准記錄及權限日誌，屬自動批准？）

因此，我認為有必要制訂一套正式的機器人方針，明確審批程序，並參考w:維基百科:機器人方針引入覆核申請、活躍度要求等機制。 dringsim 2025年7月3日 (四) 17:31 (UTC)

通知其餘幾位使用機器人的用戶：@Kcx36、Liouxiao、Midleading、維基小霸王：（請維基小霸王在Wmr-bot用戶頁添加{{Bot}}標註機器人操作者信息，謝謝！） dringsim 2025年7月3日 (四) 17:47 (UTC)

可參考以下站點的活躍度要求：

• 中文維基百科：機器人超過1年不活躍+一星期通知期
• 英文維基文庫：機器人或用戶超過2年不活躍+30天通知期，須回應並運行機器人方可保留權限
• 日文維基文庫：機器人超過1年不活躍
• 全域機器人：機器人超過1年未在允許使用全域機器人的wiki編輯

dringsim 2025年7月3日 (四) 17:55 (UTC)

結合本站活躍度，理解超過2年不活躍的標準比較妥當？ Teetrition（留言） 2025年7月4日 (五) 02:01 (UTC)

本站IP封禁豁免者目前是沒有活躍度方針的，允許長期閒置。建議要求通知不活躍機器人，本地缺乏行政員，重新授權會導致機器人重新啟用延遲。本站很多頁面分類通過header模板中theme參數錄入，而不是直接添加分類，因此必須使用機器人而不是小工具才能進行批量維護，至少本人和維基小霸王正在把機器人權限作為自動維基瀏覽器權限使用以維護大量頁面，標記含有{{PUA}}的頁面，錄入原文等等。而且有些機器人（至少包括本人和維基小霸王）正在維基共享資源執行耗時很長的大批量上傳和維護，可能會需要2年甚至更長時間。本地看不到這些貢獻，但不代表這些機器人在本地不再活躍或者賬號被盜。 Midleading（留言） 2025年7月4日 (五) 04:02 (UTC)

在其它wiki運行即表明仍然控制賬號，但如果是超過2年在各wiki都完全沒有活動，我認為仍然要認定為閒置賬號，此時雖有重新啟用延遲，但繼續保留權限的好處恐不足以抵消其風險。 dringsim 2025年7月4日 (五) 04:57 (UTC)

另外如果通知後仍長期未回應，則表明用戶近期無意繼續使用該權限，宜需要時再重新申請權限。 dringsim 2025年7月4日 (五) 05:02 (UTC)

本人雖然現在沒有運行，但是有未來運行的可能。建議保留。 維基小霸王（留言） 2025年10月26日 (日) 15:35 (UTC)

考慮本站實況，本人認為可以設定一段活躍門檻（比方說兩年？），但同時引進通知制度，即若機器人操作者於期限內明確表達希望保留權限（且未有不當行為），則一般從其意願。這樣可以確保操作者足夠活躍，或至少能夠掌握機器人。至於是否要計入全域活躍程度，本人沒有特別意見。—— Eric Liu_（留言） 2025年7月4日 (五) 05:01 (UTC)

個人支持Teetrition上面說的2年意見，不過建議有管理員權限的機器人應該有比此適度更短的活躍期要求。 Liuxinyu970226（留言） 2025年7月14日 (一) 04:12 (UTC)

另外，如果機器人出現任務已結束、運行未批准的任務等情況，也應當能被申請覆核。 dringsim 2025年7月4日 (五) 05:28 (UTC)

本人認為維基文庫本來就屬於相對不活躍的社群，出於減少行政任務的考量，對於已經批准過的任務應該無異議應當持續許可，機器人賬號本身也並不包含任何普通用戶所沒有的權限，僅僅是用於區分普通編輯和機器人編輯而已，處於行政維護的考量可以關掉一批，但目前看來也並沒有沒有什麼明顯的益處。 Viztor（留言） 2026年3月24日 (二) 00:09 (UTC)

「機器人賬號本身也並不包含任何普通用戶所沒有的權限」，機器人賬戶擁有多項權限，包括不受速率限制影響、自動巡查和繞過垃圾鏈接阻止列表等（見Special:ListGroupRights） dringsim 2026年3月24日 (二) 03:24 (UTC)

有注意到，但我的看法不變，增加行政成本不見得有什麼益處。 Viztor（留言） 2026年3月24日 (二) 16:37 (UTC)

關於收錄各類審判文書中當事人的姓名、出生日期、地址、身份證號，維基是否有相關的隱私政策規範應當做何種處理？

如：楊某訴肖某性騷擾損害責任糾紛一審民事判決書，是否算「侵犯個人隱私」，抑或「違反基金會隱私政策」？ Liouxiao（留言） 2025年7月30日 (三) 12:13 (UTC)

相關的意見可見《從判決書的私人公開看公共記錄中的隱私權保護》：「……除此以外可以公開的判決書，也需在公開時採取必要的匿名化措施，以保護當事人的個人信息。」 Liouxiao（留言） 2025年7月30日 (三) 12:19 (UTC)

理論上，根據最高人民法院關於人民法院在互聯網公布裁判文書的規定 (2016年)等，法院在互聯網上公布裁判文書時是會遮蔽相應信息的。本件所涉裁判文書現在還沒上裁判文書網（我自己暫時沒查到），如果說到時上網了是一個處理過的版本，可以考慮用那個版本作替換。但如果說像是「私人公開」或是其他一些情況，我不太確定一線判例對此的看法是否有一個較明確的方向，就算有，在本地層面就具體的件是否適合做什麼處理（舉個例子（不代表我支持或反對），也許會有「參照相關規定在本地做遮蔽」的提議：贊成的人會認為只要參照相關規定，不自由心證就好；反對的人會認為這與反映原貌的精神相衝突，也會質疑說這個遮蔽實際上無法不自由心證，甚至質疑本地可能不適宜或無法討論這種事而應該提到基金會——綜上，這種討論恐怕是無果的），基金會的隱私方針多大程度上能夠處理這些事以及處理到什麼程度，我想這可能真的要找基金會了解才能確定。 銀色雪莉（留言） 2025年7月30日 (三) 13:28 (UTC)

就我個人看法而言，現當前情況中「自然人的家庭住址、通訊方式、身份證號碼、銀行賬號、健康狀況、車牌號碼、動產或不動產權屬證書編號等個人信息」就連《規定》都說了要刪去，我覺得本地也其實可以如此——但是這只是我的個人看法，還不成為一種提議，因為就像上面說的，我不知道這能有多大程度的共識或方針支撐，也不確定實際操作的可行性。 銀色雪莉（留言） 2025年7月30日 (三) 13:51 (UTC)

僅僅就這個法律來說（先不考慮是否符合使用條款和通用行為準則），中華人民共和國法律管不到維基文庫。 GZWDer（留言） 2025年7月31日 (四) 02:49 (UTC)

我想我們的意思在這裡應該都不是「管到」，而是它在論理上有多高的參考性。 銀色雪莉（留言） 2025年7月31日 (四) 03:39 (UTC)

@GZWDer恐怕未必，2023年11月中國加入《取消外國公文書認證要求的公約》以後，大陸這邊只要有需要，給判決辦個海證（Apostille）就可以在美國有效，自然有可能也可以適用於WMF。 Liuxinyu970226（留言） 2025年9月4日 (四) 01:06 (UTC)

我理解《取消外國公文書認證要求的公約》僅僅是免除了一些公證認證的程序要求，用來證明該文件是「真實的」（也就是「不是假的」），而非證明這個文件在外國就「有效力了」。要不然中國怎麼不直接給《反分裂國家法》在該公約締約國都辦個海證？ Teetrition（留言） 2025年9月4日 (四) 02:07 (UTC)

也就是說，一個文件是否在國外「有效力」，本身還是需要看這個文件本身關於域外效力的規定以及對應域外國家是否承認。 Teetrition（留言） 2025年9月4日 (四) 02:09 (UTC)

@Liuxinyu970226這本來就是兩碼事，海牙認證只是替代原本的公證/領事公證要求，並不影響文件本身的法律性質，替代的只是原本領事館負責核對文件真實性的流程，與文件本身的法律效益是毫無關係的。 Viztor（留言） 2026年3月26日 (四) 17:11 (UTC)

使用條款和通用行為準則禁止侵犯他人隱私。非公開個人信息應當移除（見全域監督方針）。如果認為這樣做會與反映原貌的精神相衝突，可以選擇全文刪除。 dringsim 2025年7月30日 (三) 15:14 (UTC)

通用行為準則描述的是sharing other contributors' private information，在沒有證據證明當事人編輯過維基媒體計劃的情況下不適用。 GZWDer（留言） 2025年7月31日 (四) 02:56 (UTC)

如果參照w:WP:BLP精神，類似這種私人糾紛判決，出於隱私考慮很可能需要整個刪文。 --達師 - 370 - 608 2025年8月12日 (二) 17:20 (UTC)

大抵 支持達師意見，應寫明基於保護隱私需要移除此類內容不影響對收錄全文做法的襲承。--Liuxinyu970226（留言） 2025年9月16日 (二) 05:44 (UTC)

版權與隱私權無關，即便相關內容屬於公有領域/不受版權保護，隱私權仍然受到保護。 Viztor（留言） 2026年3月24日 (二) 00:13 (UTC)

我認為《最高人民法院關於人民法院在互聯網公布裁判文書的規定 (2016年)》第八條、第十條（一）~（四）款基本上與WMF所在地的美國法律重疊，可以遵照執行。至於第十條（五）、（六）款，就依照實際情況判斷吧。 SuperGrey（留言） 2026年4月17日 (五) 03:39 (UTC)

正文鏈接到求聞百科

@Baicarp： 在大英國志的正文中加入了多個求聞百科的外部連結。由於原文和求聞百科沒有什麼關係，維基百科也不會在正文中加入這樣的外部連結，因此這樣的外部連結似乎完全沒有必要。除非外部連結是原文的一部分，或者是為了標明原文的來源所必要的，否則就不應該加入外部連結，而只應該在維基文庫、維基百科、維基詞典等維基媒體計劃中內部連結。 Midleading（留言） 2025年9月26日 (五) 14:13 (UTC)

同意。—— Eric Liu_（留言） 2025年9月26日 (五) 16:03 (UTC)

是否要以方針訂明？ Teetrition（留言） 2025年9月28日 (日) 02:31 (UTC)

同意，應該聲明在正文中應該儘量避免加入外部連結，除非外部連結是正文的一部分，或者是為了標明正文的來源；可以添加在維基文庫、維基百科、維基詞典等維基媒體計劃的內部連結。需要首先建立Wikisource:外部連結。 Midleading（留言） 2025年10月9日 (四) 04:07 (UTC)

這也是注釋方針的一部分。到百科的連結也應適度，如南宋祈請使行程記現版本，觀感像百科條目而不是書本。是不是為了學生閲讀方便，可以每個字連到維基詞典？英文文庫的方針是文庫內連結（作者，作品）不算為注釋，可任意添加。到姊妹站的連結則算為注釋，僅可在注釋本添加，且需要獨立的非注釋版本存在。本地至少應該允許已核對的作品不添加任何注釋性質的連結，以反映原貌，想要詳注的編者可以在維基教科書錄入。 Andayunxiao（留言） 2025年11月1日 (六) 08:09 (UTC)

是否可通過技術手段將連接到其他項目的內鏈以不同顏色、title attribute等手段標註？ 內存溢出的貓（留言） 2026年4月18日 (六) 10:26 (UTC)

瀏覽器會顯示所有鏈接的目標地址，不需要特意標註。你的意思是這裡也要有綠鏈嗎？ Midleading（留言） 2026年5月2日 (六) 05:29 (UTC)

修訂幫助:公有領域頁的幫助文字

此頁和Help:版權標記， Help:作者頁面中版權標簽的原有敘述更多講述內部機理，服務於管理員有餘，而對普通編者不足傳達現有共識。請求討論幾點版權問題並繼續修改幫助文字：

{{PD-1923}}是否禁止直接使用

按模板{{PD-1923}}原有説明，標記發表超過95年但作者逝世不滿50年，因而不能收錄的作品，應使用{{Pd/1923|作者逝世年份}}，但幫助:公有領域#中文國家地區，非美國發表作品一節表格與之矛盾。Andayunxiao（留言） 2025年9月29日 (一) 05:57 (UTC)

事到如今，「1923」這個數字本身就會誤導新手（新手可能會疑問這個模板和1923年有什麼關係，明明模板寫的是XXXX年），建議學C區改名（但保留重定向）：c:Template:PD-1923。 Teetrition（留言） 2025年9月29日 (一) 09:24 (UTC)

前者是否也有可能直接重定向到後者？ Teetrition（留言） 2025年9月29日 (一) 09:41 (UTC)

另查前者鏈入頁面，本身作品+作者頁面不到百條，甚至可機器人替換後廢棄（刪除）。 Teetrition（留言） 2025年9月29日 (一) 09:46 (UTC)

不必清理或重定向。因{{Pd/1923}}實為殼模板，調用內層{{PD-1923}}。此設計合理。問題僅為編者使用哪個，是否有維護或歸一化的理由。 Andayunxiao（留言） 2025年10月4日 (六) 06:42 (UTC)

承前方我的提案，既然1923這個數字會造成新手疑惑（版權保護期延長導致的長時間1923年為公共領域的年份分界線，但目前已經正常逐年往後到現在的1930），何不在改名的同時清理/重定向呢？ Teetrition（留言） 2025年10月5日 (日) 09:21 (UTC)

模板改名（英文維基文庫的新名稱是Template:PD-US）已經足夠，但需要檢查是否有一個青年的夢這樣通過模板被錯誤分類至Category:大中華地區有版權爭議的頁面的頁面。 Midleading（留言） 2025年10月7日 (二) 05:03 (UTC)

社群可以跟隨英文文庫新名稱。此處問題在於維護，是在作品頁僅直接使用{{Pd/1923|作者逝世年份}}，還是也可以允許使用{{PD-1923}}，跳過外殼模板。 Andayunxiao（留言） 2025年10月12日 (日) 07:13 (UTC)

死後發表的版權

按美國版權法，死後發表仍然適用發表起95年版權。對非美國出版作品，特別是僅考慮逝世年的兩岸四地，如何確定版權？Andayunxiao（留言） 2025年9月29日 (一) 05:57 (UTC)

按本地消極容忍慣例，不知閣下問題所在。似乎雙邊各自用各自標準確定好即可？ Teetrition（留言） 2025年9月29日 (一) 09:49 (UTC)

問題是兩岸四地的死後發表作品是否版權考慮不同。如，作者去世50年後發表作品，是否第二年即進入公有領域？去世51年發表如何？ Andayunxiao（留言） 2025年10月4日 (六) 06:45 (UTC)

• 按中華人民共和國著作權法第23條、按香港第528章 《版權條例》第17條、澳門第43/99/M號法令第21條無論是多久發表，著作財產權存續至死後第50年。即使是死後第51年發表，亦同，也就是說死後第51年之後一發表就進入公共領域。
• 按著作權法_(民國111年5月立法6月公布)第30條，死後第39年及之前發表的，存續至死後第50年；死後第40年至50年間首次公開發表的，自該公開發表時存續十年。

因此僅著作權法_(民國111年5月立法6月公布)發生效力的台澎金馬地區，存在【死後第40年至50年間首次公開發表】的特例。對於台澎金馬地區死後第51年之後發表的作品，理解亦應理解為存續至死後50年，故亦為死後第51年之後一發表就進入公共領域。 Teetrition（留言） 2025年10月4日 (六) 11:40 (UTC)

美國的著作權是比較複雜的，對於作者死後出版的作品：

• 1977年及以前出版的作品，按出版+95判斷；
• 1978年-2002年出版，按死後+70或2047年12月31日較晚者計算，即未過期；
• 2003年以後出版，按死後+70計算。

但是對於非美國出版作品有URAA的例外：如果作品在來源國加入著作權條約的年份（如中國是1992年）前出版，URAA年份時（如中國是1996年）在來源國已過期（如中國是死後+50，即1945年前作者逝世），那麼在美國處於公有領域。

那麼總結一下，對於1945年前逝世的中國作者，其作品如果在1992年前或者2003年後出版，均屬於公有領域，唯獨在1993年-2002年出版需要消極容忍。例如《陷京三月記》於2006年出版，因此屬於公有領域。1945年-1954年逝世的作者，僅當作品於2003年後出版時，才在美國屬於公有領域。 曾晉哲（留言） 2025年10月5日 (日) 12:19 (UTC)

如果沒有表格，可以弄一個，方便理解。—— Eric Liu_（留言） 2025年10月22日 (三) 03:49 (UTC)

消極容忍是否能在幫助頁明文允許

參考m:美國對較短期間規則的不接受性#維基媒體基金會陳述，本地常有的是在中文地區已進入公有領域，但因發表晚於1946年，美國仍有版權。現表格中幫助文字對能否錄入未有態度，能否明確可以錄入，並使用{{Not-PD-US-old}}標記？同一問題還包含去世年不明作者（{{PD-old-assumed}}）。Andayunxiao（留言） 2025年9月29日 (一) 05:57 (UTC)

 支持 Teetrition（留言） 2025年9月29日 (一) 09:26 (UTC)

 中立。消極容忍是指不知情而刊登的，善意推定以及容忍到維基媒體基金會被正式要求下架止。因此不宜故意鼓勵刊登，只是本站不硬性禁止刊登，而社群更不能自行提刪。就是弛禁，不是英文維基文庫的嚴禁。--WEBridge（留言） 2025年10月21日 (二) 19:06 (UTC)

更多可能在於指明這種「消極的態度」而非鼓勵，否則消極容忍可能成了找不到依據的版權模板。本來WS:版權討論也指明了這種態度，讓新用戶更容易找到用什麼模板，不是壞事。 Teetrition（留言） 2025年10月22日 (三) 02:09 (UTC)

消極容忍情況如不指明使用何種版權標記，則應免除編者錄入此類作品時使用版權標記的要求。這差不多是將{{Not-PD-US-old}}當作維護模板使用。 Andayunxiao（留言） 2025年10月25日 (六) 05:04 (UTC)

我想這可以透過措辭問題來解決，比如可以仍按Wikisource:版權信息/全文措辭精神，改為「在兩岸四地屬公有領域。在美國認為發表起有版權到95年至年底。本站消極容忍，用{{Not-PD-US-old}}頁面底端標示」或者「在兩岸四地屬公有領域。在美國認為發表起有版權到95年至年底。遇此類作品時，用{{Not-PD-US-old}}頁面底端標示」？後者可能更「消極」一些，不容易像「鼓勵」。 銀色雪莉（留言） 2025年10月25日 (六) 05:41 (UTC)

修訂二版，將{{Not-PD-US-old}}模板要求移動到腳註。本人偏愛「不鼓勵錄入，但也不主動刪除」一類中性説法，也避免以管理者視點論述，而可顯示共識為社群達成。再請教各位意見。 Andayunxiao（留言） 2025年11月22日 (六) 17:51 (UTC)

{{PD|yyyy1|yyyy2}}還是{{Pd/1923|yyyy}}

查引用{{PD}}和{{Pd/1923}}，{{Pd/1996}}都有2000+連入([1], [2], [3])。兩個方案功能一致，前者調用後二者，因此未能知道作品頁的實際使用數量。看編輯歷史，兩者穩定版本都有十年多歷史，現狀如何？是否應更新幫助文字以反映共識？ Andayunxiao（留言） 2025年9月29日 (一) 05:57 (UTC)

修訂一版

按Teetrition與Njzjz閣下的解釋，已經更新中文地區作品的公有領域判斷表格。未盡討論請繼續。請檢查錯誤，可直接編輯。Andayunxiao（留言） 2025年10月25日 (六) 05:39 (UTC)

關於文言文（日韓越稱漢文）文獻錄入之提議

近期想要根據維基共享資源錄入《大日本野史》，原文為日式訓點斷句的文言文（漢文）。想到之前遇到的諸多問題，這裡一起探討一下。

現今中文維基文庫所錄入的文言文（日韓越稱漢文）文獻均使用現代漢語標點，事實上不少文獻原文並無讀，添加句讀可以認為是二次創作，但無句讀會造成不少人的閲讀障礙。

然而若使用現代的格式來錄入，原本竪排版本的特定格式擡頭，避諱等可以反應古文原貌的特定格式統統丟失了。

另外大家可能忽略了一個事實，即日本也存在一種獨特的句讀來對文言文進行斷句（請參見w:漢文訓讀，案例參見這部日本的論語刻本），有些日本的漢文文獻刻本原本使用「㆑」「㆒」「㆓」「㆔」這種日本式斷句，在中文維基文庫錄入往往會被改成了中文式的句讀，這明顯篡改了文章原貌。不過作為「中文」維基文庫，使用日本式句讀應該不太合適。

基於上述的事實，我提議：

若原文無句讀，則自行添加現代漢語句讀並均應加上{{原文沒有標點}}模板，以示尊重原文。無句讀的版本放在文言文維基文庫。若有句讀且是中式的句讀，直接按原文句讀錄入。

若原文是日本式的句讀（漢文訓讀的訓點），則改用中式句讀來斷句，並標識出已將日式訓點改成了中式句讀（新創建一個模板來標識？）。原文的日式句讀版本去日文維基文庫錄入，他們應該會接納。

另外提議可將文言文維基文庫作為漢字文化圈共通書面語的文庫保留。某種角度來說作為漢字文化圈共用的書面語言，所有文言文均是可以用漢語、日語、韓語、越南語來讀的，並非中文專有。該文言文維基文庫與中文維基文庫功能不同，為保留古文原貌所設，必須保留竪排刻本的原貌（技術上也用豎排），包括擡頭、避諱等格式均不作任何更改，原文無句讀則無句讀，原文有句讀則原樣保留句讀（包括中式句讀、日式句讀）。目前該處所錄入的所有文獻大部分都不符合這一標準（事實上文言文維基文庫如果還是自行添加句讀，就根本沒有存在的必要），宜將其全部改為遵循古文格式，同時將現代句讀版轉入到中文維基文庫這裡。 el caballero de los Leones（留言） 2025年10月1日 (三) 05:20 (UTC)

豎排本身本地是能夠錄入的（有大量用例），擡頭、避諱也不是不能解決的問題。因此，橫豎排的錄入方式（包括有無句讀）本質上是錄入者所依據的文本以及錄入者錄入時決定採取的形式來決定的。因此，有無句讀的版本本身都可以放在本地。您所稱的日式句讀版本去日文維基文庫錄入不是問題（或者說，不是本地來處理的問題）；但嚴謹而言，本地過往也有變體文言文收錄的一些例子。總括而言，恐怕看不到設置有句讀（或自行添加句讀）的才能留在本地而無句讀的得去文言文維基文庫的規則的必要性，文庫恐怕也無法設置這樣的規則來規管錄入者。 銀色雪莉（留言） 2025年10月1日 (三) 05:49 (UTC)

補充：對於若原文是日本式的句讀（漢文訓讀的訓點），則改用中式句讀來斷句，並標識出已將日式訓點改成了中式句讀這種情況，其實是一個很玄乎的情況，鑑於在下過往處理過的一些變體文言的經驗，我個人認為這個視情況可能存在某種程度的討論空間，但是它似乎還牽涉蠻多問題的，不是一個可以劃一而論而是需要根據文獻實際情況確定的問題。 銀色雪莉（留言） 2025年10月1日 (三) 07:08 (UTC)

日本的漢文訓點是日語中專用的一種輔助句讀，此處是中文維基文庫，使用日文句讀顯然是不太合適，更何況有的文獻通篇就是自帶日文句讀。因此，如果這樣通篇用日式漢文訓點，我認為當然應該將其轉換為中式句讀，日式漢文訓點版本應錄入在日文維基文庫。

有一點令我困惑，從某種角度來說，文言文與現代中文的關係，同拉丁文與義大利文的關係是類似的。日文、韓文、越南文與文言文的關係，同歐洲語言與拉丁文之間的關係類似。拉丁文為義大利文的母語和祖先，後成為歐洲國家的共用的書面語，這與文言文和中文的關係很相似。不太明白為何拉丁文被認定為獨立的語言，而文言文卻被認為中文的一種？ el caballero de los Leones（留言） 2025年10月1日 (三) 17:50 (UTC)

也許此前在下的發言有些模糊，我所指的「討論空間」不是說想要保留日式句讀在本地，而是說對於變體文言或者採取特殊句讀的情況（不同文獻的變體程度與原始句讀形式都有差異）的收錄存在空間，但是要具體情況具體討論。像您舉的大日本野史，調整掉日式句讀後與通常文言基本無異，那麼一般是沒什麼問題的（自然，這與日式句讀版本錄到日文文庫完全不衝突）。像是天正三年柴田勝家安堵狀這種候文則比較適合日文維基文庫。 銀色雪莉（留言） 2025年10月2日 (四) 10:16 (UTC)

支持把候文文獻轉移去日文維基文庫。同理，吏讀文獻應轉至韓文維基文庫、喃字的文獻應轉至越南文維基文庫。如果僅只有少數句子段落屬於上述情況可以例外。 el caballero de los Leones（留言） 2025年10月3日 (五) 07:05 (UTC)

我認為這不容易劃一處理。候文處理起來可能是容易的，作為和漢混淆體而言它更接近日語。但其他的一些變體漢文，包括但不限於朝鮮文獻，問題就複雜得多。喃字已經是另一個維度的問題了，它用不着在本話題下擔心。 銀色雪莉（留言） 2025年10月9日 (四) 23:58 (UTC)

@唐吉訶德的侍從、銀色雪莉我有必要提醒兩位閣下，韓語維基文庫多年前已明確謝絕收錄朝鮮/韓文漢字：ko:위키문헌:사랑방/보존 6#한문 문헌의 수록 문제，目前暫未看到韓語方面對此有任何形式的讓步。 Liuxinyu970226（留言） 2025年11月6日 (四) 06:54 (UTC)

上面已提到過「不同文獻的變體程度與原始句讀形式都有差異」。朝鮮這邊的情況雖說複雜但比較容易解決而不是一個非常需要困擾的問題。朝鮮文獻，在本地是有過探討的（參見Talk:內閣故事節目#最後吏讀斷句不了、Talk:全羅兵營關牒謄錄#《全羅兵營關牒謄錄》錄入），也有一個小範圍（客觀說法，因為本地處理或參與處理過朝鮮文獻的就那麼幾位）的初步共識，不過因為文本數量很多、處理人數很少而沒有嚴格執行。總體而言，除部分變體程度很高的以外，朝鮮使用漢字書寫的文獻本地收錄的可行性甚至都不太需要討論。至於韓語文庫收什麼，不收什麼，與本地收什麼，不收什麼，沒有因果關係。 銀色雪莉（留言） 2025年11月6日 (四) 07:15 (UTC)

我不想要吹噓自己，但是我是公認的參與收錄韓國/朝鮮漢文文獻最多的人。如果你想要問我什麼問題直接在這裡@我。謝謝。@Liuxinyu970226 @唐吉訶德的侍從。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年11月6日 (四) 20:28 (UTC)

話說吾妻鏡的性質是什麼？是否需要從本站刪除？ dringsim 2025年10月6日 (一) 17:02 (UTC)

如果有合適的方法將其轉移到日文維基文庫的話，可以考慮從本站刪除，畢竟這份文獻在本站並未錄入太多內容。不過一個目前可前比較疑惑的問題是：『吾妻鏡』的正文為變體漢文，但其序文為標準漢文。對於這類文體混合的文獻，是否將其移入外文維基文庫，個人認為可以進一步商討。 Chain114514（留言） 2025年10月9日 (四) 15:12 (UTC)

東鑒體的和漢混淆中偏和的程度（或者說變體漢文的變體程度）比候文低而比另外一些和化漢文高。就我的個人觀點的話，這個我還算能咽（不是說我看不看得懂，而是「收錄」）得下去，候文幾乎不行。如果你問我上面那個安堵狀，我可能會大喝一聲「管它日文文庫怎麼想！」doge，但吾妻鏡...我五十五十。 銀色雪莉（留言） 2025年10月10日 (五) 00:03 (UTC)

韓國古代文獻有些時候使用一個叫「吏讀」的東西。就是加標點符號在文獻的邊上幫助朝鮮人閱讀古書。跟日本的這種「㆑」「㆒」「㆓」「㆔」很相似。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年10月3日 (五) 15:45 (UTC)

支持在本地錄入原貌。擡頭、避諱，原文句讀樣式等都可用CSS或模板達成。直排和包括避諱的其他樣式並無強關聯，至多模板樣式兼顧直排。閣下作為惟一貢獻者可自行決定。 Andayunxiao（留言） 2025年10月4日 (六) 06:50 (UTC)

閣下之前提議過避諱字模板，現有諸模板是否滿足閣下願望？ Andayunxiao（留言） 2025年10月4日 (六) 06:53 (UTC)

中文維基文庫和日文，韓文，多語言，文言文（還未有獨立運行）是姐妹專案，不是從屬和分站關係。我們可以討論本地的收錄原則但此處討論不能為其他社群做決定。

獨立的文言文文庫以前在元維基有不成功提案，閣下可檢視歷史討論。僅補充一點，本地幾乎不可能被收回收錄文言文作品的權力。各中文語言一旦使用漢字書寫，則沒有形態上的區分，分界綫極難劃。英文文庫有Template:Lang等語言標簽，不僅可以標記成段文字，還可以標記單個詞是哪個語言的，後者在中文諸語言是困難而沒有客觀標準的。 Andayunxiao（留言） 2025年10月4日 (六) 07:35 (UTC)

其實文言文維基文庫根本就沒有必要存在，文言文維基文庫也有這樣類似的問題（判斷文獻是文言文、中文、還是日文），文言文全部收中文維基文庫至少避免了一大半問題。日文維基文庫中十分了解漢文的貢獻者遠沒有這里多，這也是一大障礙。 Midleading（留言） 2025年10月9日 (四) 16:16 (UTC)

(！)意見：我認為「判斷文獻是文言文、中文、還是日文」這個在語言學上不是問題。至少在本人作為語言學本科畢業生的角度來說，斟酌的餘地其實不大。譬如：《訓民正音》是文言文，而日本二戰投降的《終戰詔書》則是日文（即使本來以漢文（即文言文）書寫，亦很容易還原成文言文，但原文是用日文語法書寫，所以歸為日文）。⸺ googoo0202（he／佢／他） （留言 · 貢獻） 2025年11月27日 (四) 09:23 (UTC)

我同意歷來的一些說法，就是以漢文邏輯行文者，基本可以納入，而單純借用漢字（但語法完全不是漢語）者不算。—— Eric Liu_（留言） 2025年11月6日 (四) 16:05 (UTC)

有理由認為作者寫作的時候就是認為自己是以文言文寫作，即便使用和式生造字，仍然符合錄入標準。漢字作為表意符號，本身就是靈活多變的。如同英語在現代日語中的地位一樣，只要仍然是寫的英語，就可以作為英語收錄，無需考慮其他語言文庫如何考量，也無須考慮是否重複。即便借用了漢字，實際上文言文對日語韓語語言來說本身就是外文，如同英語借用法語詞彙一樣。 Viztor（留言） 2026年3月24日 (二) 00:25 (UTC)

ChineseTypography小工具

突然想起來，不知道你們是否會對ChineseTypography小工具加入「偏好設定」的「小工具列表」感興趣（預設不啟用）。

mw.loader.load('//zh.wikipedia.org/w/index.php?title=User:SuperGrey/gadgets/ChineseTypography/main.js&action=raw&ctype=text/javascript');  // Backlink: [[w:User:SuperGrey/gadgets/ChineseTypography|ChineseTypography]]

請Midleading管關注。程式碼目前完全部署在中文維基百科。

小工具描述：改善中文和其他字元混排時的字距（盤古空白），改善標點符號與文字的字距（標點擠壓）。SuperGrey（留言） 2025年10月12日 (日) 21:44 (UTC)

邀請參與生僻字webfont討論

w:Wikipedia:互助客棧/技術#生僻字webfont。歡迎參與。

簡要說明：欲通過Toolforge+小工具加載webfont解決生僻字顯示問題。 PexEric（留言） 2025年10月20日 (一) 08:57 (UTC)

如果Toolforge或共享資源能託管字體是最好。中文文庫對大字庫有強需求：如果如實錄入，則現有Unicode區塊尚不足涵蓋全部作品用字。新字如能自動分包，緩存，更新，則優於人工維護。

對未登入讀者和手機端怎樣支持？ Andayunxiao（留言） 2025年10月25日 (六) 06:16 (UTC)

「現有Unicode區塊尚不足涵蓋全部作品用字」這個就是漢字沒有被unicode收錄的情況，我的方案是KAGE引擎組字+MediaWiki擴展（如果以後有機會，可能會着手開發）。「對未登入讀者和手機端怎樣支持？」則是藉由JavaScript小工具，默認對所有使用者啟用。 PexEric（留言） 2025年10月25日 (六) 06:23 (UTC)

原來如此。也請留意維基文庫導出電子書的工具Wikisource:WS Export。導出和網頁版對作品閲讀，傳播同樣重要。如可能，可考慮兼容為epub，pdf等格式的導出書嵌入字體。 Andayunxiao（留言） 2025年10月25日 (六) 06:38 (UTC)

@PexEric：想順便問一下這類小工具能否部署到其他站點？本站應該是特別需要。—— Eric Liu_（留言） 2025年11月22日 (六) 14:56 (UTC)

可能需要針對本站單獨開發？我不太清楚本站對生僻字的處理。 PexEric（留言） 2025年11月23日 (日) 06:20 (UTC)

似乎本站與中維的生僻字處理相同。可以直接沿用小工具。 PexEric（留言） 2025年11月23日 (日) 06:22 (UTC)

unihan-helper 已通過驗證，在文庫中有效，如此設置即可。 PacmanD（留言） 2026年7月11日 (六) 00:48 (UTC)

@PexEric：這樣看來，應該可以直接引進本站。副知@Midleading：準備部署。—— Eric Liu_（留言） 2026年7月11日 (六) 01:42 (UTC)

 支持。 魔琴（留言） 2026年7月11日 (六) 01:51 (UTC

已導入，請在偏好設定中自行開啟僻字小工具測試，然後討論是否預設啟用。 Midleading（留言） 2026年8月25日 (二) 14:01 (UTC)

發現一些小問題，正在聯繫作者改進。另外，鑑於文庫中僻字較多，採 Unicode 編碼後，可以考慮在現有的 Plangothic、WenJinMincho 基礎上繼續增加字符集更全的字型，如 Jigmo TC： https://tools-static.wmflabs.org/webfont-zh-static/ （此目錄由本人於昨天創建）。 PacmanD（留言） 2026年8月28日 (五) 15:14 (UTC)

測試正常，測試期間無人提出意見，現已預設開啟僻字小工具。 Midleading（留言） 2026年9月21日 (一) 04:03 (UTC)

就中國大陸司法文書收錄信源問題的進一步討論

當前有Wikisource:刪除討論#8月中涉及湖北省武漢市中級人民法院（2022）鄂01刑終818號刑事裁定書一件的討論，相關討論引出中國大陸司法文書收錄信源的討論，此類討論可能在寫字間進一步展開較為有益，因此在此新開話題，並將參與討論者觀點（無論是共識或有爭議者）概括點列，請各位維基人就此進一步討論，希望得出此類文件的較明晰的收錄標準（或收錄標準共識）：

• 裁判文書網：視作可靠（註：存在下架情況，若可能時需要考慮存檔以便保留信息）；
• 北大法寶、威科先行、法信、知產寶、律商聯訊等付費/免費第三方數據庫：視作可靠；
• 官方或學術匯編類書籍（數據庫）：視作可靠（可能存在刪節，但仍可基於版本學收錄）；
• 個人出版物：基於在文檔討論頁提供存檔鏈接且該存檔有可視文書原貌（帶章掃描件/電子件）的前提下可以容忍，對電子重排件不接受；
• 第三方轉載：有觀點認為只要有可靠第三方刊載/轉載即可接受；也有意見認為這種轉載可能源於SPS且可能在轉載中存在刪節，應以其原始來源情況考慮是否符合要求。

副知原討論參與者@Chu Tse-tien、Teetrition、Midleading。 銀色雪莉（留言） 2025年11月11日 (二) 10:01 (UTC)

前面三種沒有問題。後面暫時沒有特別意見，再想想。—— Eric Liu_（留言） 2025年11月13日 (四) 00:24 (UTC)

裁判文書網似乎有登錄牆，能存檔嗎？ dringsim 2025年11月14日 (五) 15:47 (UTC)

網頁應該是不能，這裡只是說如果有需要，可以考慮archive一個圖像（才發現我上面打錯了字，我的意思是「若需要時可以考慮存檔」），當然這不會強制，只是對這個來源的這種情況做一個提醒。 銀色雪莉（留言） 2025年11月14日 (五) 18:05 (UTC)

法律文本如在公有領域，則不應該只有轉載或僅數字文本的證據。因此這可能不是收錄標準問題，而是「文庫有無義務判斷原始來源已不存的作品真僞」，和「無原始來源的作品是否允許以二手文本在同名下錄入」的兩個問題。對前者，本地完全可以將責任推給維基共享資源和網路存檔，至少影印件如共享資源不能收錄，本地也不能上傳或使用。 Andayunxiao（留言） 2025年11月15日 (六) 08:05 (UTC)

如果原始來源是到了「不存」或者「無」，我是傾向不錄；然而，何種來源是（或可等價於）原始來源，是值得討論的，因為可能有不同意見。 銀色雪莉（留言） 2025年11月15日 (六) 15:41 (UTC)

按理說，法院判決書的「原始來源」，應該只有法院出具的原始紙質件（或是蓋有電子簽章的電子PDF）才算得上「原始來源」，然而能找到公開的原始來源的判決又有多少呢。誠如銀色雪莉君所言，本話題下似乎就是在討論哪些來源算得上可靠的原始來源這一問題。 Teetrition（留言） 2025年11月16日 (日) 08:20 (UTC)

PS：雖說我曾在刪除討論那邊對「個人出版物」的容忍表示接受，但再三思考下，請允許我對此類的態度改為中立偏反對——現時點的信息技術的日新月異的程度已使我對於個人提供的東西是否為原件（或原件的忠實複製）一事能否被確證的問題感到擔憂。如果是與發布者自身相關的文書（即w:WP:ABOUTSELF），我也許會容忍吧。 銀色雪莉（留言） 2025年11月25日 (二) 06:22 (UTC)

更新社群首頁

新的草稿在此頁（討論發起前版本）。

社群首頁服務編者，本地較中文維基百科相比，專案相關頁少而集中，因此社群首頁值得善用以成為便捷入口。從前的設計因襲英文文庫，編者自行張貼任務和動態條目的設計，已經不合現實。提議是模仿維基百科的主題頁設計。未來擴充此頁時，內容穩定的可以在此頁直接加入；動態內容及複雜語法寫入到社群首頁的子頁，再嵌入社群首頁。

歡迎各樣提議及直接修改草稿。Andayunxiao（留言） 2025年11月29日 (六) 11:41 (UTC)

 支持。「專題」一欄似可多列幾款（題外話：這樣也可讓右邊欄看起來長一點，現在拉到底右邊空了一塊——不過這只是隨口一說，並不是作為一個重要原因提出），其他無異議。 銀色雪莉（留言） 2025年12月1日 (一) 08:22 (UTC)

左右末端可以對齊，如此，僅取消樣式中|style=flex:none;參數即可。編者可以擴充、更改各模塊的順序，添加新的模塊，不再限於原有的表格樣式。各專題的宣傳請熟悉的編者來擴充。 Andayunxiao（留言） 2025年12月2日 (二) 16:24 (UTC)

編者可繼續添加需要的捷徑。更可在此頁貼出公告、新聞。 Andayunxiao（留言） 2025年12月2日 (二) 16:33 (UTC)

 支持。晞世道明（留言） 2025年12月3日 (三) 15:49 (UTC)

感謝各位支持，建議新年起更新社群首頁。因只涉兩個頁面，未來還可持續修改。 Andayunxiao（留言） 2025年12月24日 (三) 09:10 (UTC)

新的協作頁

提議社群建立一個編者協作的專案頁。之前編者協作或對單個作品提議，只能在作品討論頁發生。其固然是設計本意，但亦有不足：

1. 討論分散：缺少上下文和協作氛圍，不易找到，否則討論容易停滯。
2. 不便維護錄入數據：中文作品錄入常需要整體考慮，維護跨校對頁的元數據，如異體字，樣式，內部連結等。這些數據可以在討論頁錄入，但限於討論頁指引，發言不適合協作更改；在編者頁錄入則不能體現協作之精神。例如，
   • Index talk:魯迅全集01 (1948).pdf 頁中 David, but not Hilbert，TianSalt 閣下列出的轉換代碼和規則。
   • Talk:大南寔錄#錄入字形頁中各位編者對錄入字形的討論。

提議是在Wikisource 名字空間新設協作專案頁。此頁主體以作品為章節，每個作品章節包括「錄入概覽」和「討論板」和兩部分。「錄入概覽」以模板實現，允許協作更改，可以連到子頁上的元數據。完成的討論再存檔到作品或索引頁的討論頁，本頁也可在子頁平行存檔。

本地已有專題，因此設想此協作頁從小任務開始試驗，如100頁以下的單本書。

中文文庫二十周年快過去了，因此這也算一個周年提案。Andayunxiao（留言） 2025年11月29日 (六) 11:41 (UTC)

其實寫字間就是協作頁面；本站社群規模真的不大，若確有必要，是可以增設專題，但不宜過細，分散討論量能。另亦可結合上方拆分寫字間的提案，先考慮將一般消息與內容討論分開。—— Eric Liu_（留言） 2025年12月4日 (四) 11:00 (UTC)

同意閣下所言另設新頁可能不如集中在寫字間，我也擔心可能設立新頁後不活躍，因此提出了最近的幾個活躍協作作品，希望得到意見。

即使在寫字間，也可以在討論頂端以模板或文本展示作品資訊，連到可協作編輯的元數據，如

大南寔錄 （討論 • 異體字 • 避諱 • 模板樣式 • 字詞轉換表 • 進度）

這些元數據頁面是否可以錄入到作品討論頁的子頁，或索引頁的子頁？ Andayunxiao（留言） 2025年12月5日 (五) 09:52 (UTC)

其實我是怕多數頁面根本不需要這些東西，最後變成無效連結大量增加。基本上全部聚集於寫字間，比較可行。—— Eric Liu_（留言） 2025年12月5日 (五) 11:07 (UTC)

徵求意見：新命名空間「法律文書:」=「Case:」

提議來自Midleading管：

我再次建議為這些裁判文書新建一個命名空間。原因有三點：一，便於檢索時選定或者排除裁判文書，如果裁判文書過多，可以單獨調整裁判文書在檢索結果中的排序，二，錄入大量裁判文書時不會讓Special:Random全部重定向到裁判文書，三，有必要考慮要對裁判文書實行命名空間級別的永久半保護，因為沒有原件和掃描件，難以由匿名用戶進行校對，同時有大量個人信息，容易變成破壞的目標，而機器人統一導入的文本更可靠。這個命名空間將被視為主命名空間、Translation命名空間一樣，是中文維基文庫的正式收錄內容。

此命名空間目前將主要用於由機械人User:SuperGrey-bot匯入的中國裁判文書。根據「請求wiki配置更改」規則，我需要大家積極討論，並取得此提案的共識。感謝！ SuperGrey（留言） 2026年3月12日 (四) 01:39 (UTC)

傾向支持。但需要解決的問題是：

1. 已有的裁判文書是否全部移動到新命名空間？是否保留重定向移動？需要考慮到百科及其他項目部分條目已經引用了本地的相關文書，這部分文書不留重定向移動似乎顯然不妥，但這部分是否可以因為其被相關項目條目提及的顯著性而保留在主命名空間？
2. 範圍只是中國大陸的裁判文書，還是可以包括其他所有地區的裁判文書？
3. 「法律文書」是「裁判文書」的上位概念，需要明確只包括裁判文書，還是所有和法律相關的、公權力機關出具的文書？例如檢察院的刑事起訴書、公安機關的相關文書等。

Teetrition（留言） 2026年3月12日 (四) 07:04 (UTC)

假如今後很多法律文書都録入了，把各地區所有法律文書收録在同一命名空間更符合檢索的需求。我建議所有法律文書都收録到法律文書命名空間，現有的法律文書也要移動到新命名空間，但在該命名空間創建之前録入的法律文書都可以在主命名空間保留重定向(除本機器人測試匯入的文章不需要重定向外)。 Midleading（留言） 2026年3月12日 (四) 10:43 (UTC)

雖立意良好，惟恕不能同意，因為不過是有關文章數量多，不代表與本站允許收錄之其他文本發生根本性質差異，更不應有獨立命名空間予以區別對待。—— Eric Liu_（留言） 2026年3月12日 (四) 17:32 (UTC)

私以為本案的通過本身就需要以機器人被通過並導入巨量的裁判文書文本為前提，而設立新命名空間的意圖，不是「區別對待」設立命名空間對裁判文書予以了「優待」，而是如果不設立新的命名空間，會導致裁判文書在事實上被優待。設立新的命名空間反而是事實上對裁判文書相較其他作品的「矮化」。

事實上被優待的點可以體現在，Special:Random基本都重定向到裁判文書，導致該功能事實上變成「隨機一篇判決」，導致其他作品難以通過該入口得到被查看的機會等。 Teetrition（留言） 2026年3月13日 (五) 03:16 (UTC)

建議改進隨機頁面功能，而不是為了遷就該功能就將主命名空間單純按數量占比切割成幾塊。Commons照片占比大，是否也要拆分命名空間以彰顯「公平」？ dringsim 2026年3月13日 (五) 07:34 (UTC)

意見與Eric差不多。創建一個新命名空間如果是僅用於機器人導入任務，叫「CJOOP」更合適；不認同「把各地區所有法律文書收録在同一命名空間」這一操作。Stang 2026年3月13日 (五) 00:05 (UTC)

新命名空間似乎不會算作是內容頁面？ Shizhao（留言） 2026年3月13日 (五) 03:21 (UTC)

這個命名空間的建立是機器人即將導入大量裁判文書文本的技術需要，在收錄、檢索和防止破壞上都有優點。這個命名空間如果僅收錄機器人導入內容會導致用戶檢索裁判文書和相關的法律文書時，仍然要連同主命名空間一起檢索，也不利於日後其他人繼續錄入更多法律文書。在新建命名空間的時候，要考慮到以後還會有更多的法律文書需要錄入到這個命名空間，以便被一起檢索到。完全可以把這個命名空間計為內容頁面，和新建Portal命名空間一樣。 Midleading（留言） 2026年3月13日 (五) 04:17 (UTC)

這種東西可以調的。Stang 2026年3月13日 (五) 07:30 (UTC)

很難想象以您的閱歷會關心條目數。你不會真是Shizhao的孩子吧？--維基小霸王（留言） 2026年3月14日 (六) 02:28 (UTC)

意見同Eric Liu。（在當下）數量占比大不代表與其它文本有根本性質差異。搜索需求可以用CirrusSearch的高級搜索語法滿足。 dringsim 2026年3月13日 (五) 07:21 (UTC)

高級搜索語法在中文維基文庫懂的人可能都不到10個，如果未來每個用戶包括匿名用戶都必須懂高級語法才能在中文維基文庫檢索，那這是非常失敗的，完全無法與直接在檢索頁面選擇命名空間相提並論。Special:Random的問題更不可能通過什麼高級語法解決了，WMF能提供空間存放這些文件已經是最大的幫助了，沒有人會專為中文維基文庫修改Special:Random。這裡的情況和Commons區別很大，Commons的匿名用戶很可能需要查找照片，但中文維基文庫的用戶中，需要查找法律文書的只是一小部分，如果沒有新的命名空間，所有用戶，特別是只閱讀的匿名用戶，會受到很大的影響。 Midleading（留言） 2026年3月13日 (五) 16:55 (UTC)

「如果未來每個用戶包括匿名用戶都必須懂高級語法才能在中文維基文庫檢索，那這是非常失敗的」呃……諸如北大法寶和全國報刊索引都有很多不同的搜索選項，本站什麼類型的文獻都收怎麼可能簡簡單單就搞定了…… dringsim 2026年3月20日 (五) 12:07 (UTC)

至於Special:Random，不同類別（該劃分為什麼類別又是一大問題）的作品被抽取到的可能性本來就已十分不均等，我認為實在沒有討論的必要。 dringsim 2026年3月20日 (五) 12:12 (UTC)

諸如北大法寶和全國報刊索引都有很多不同的搜索選項，本站什麼類型的文獻都收怎麼可能簡簡單單就搞定了……搜索選項是要擺在界面上的，沒哪個數據庫會把每個人都要用的搜索選項設置成只有懂高級搜索語法的人才能用。對於本站而言，在此命名空間中搜尋：這一欄就是出現在界面上的最常用的搜索選項之一。我認為實在沒有討論的必要。看起來像是被一個無法解決的問題徹底困住了，因為無法解決所以乾脆就不要再改善。可是明明增加一個命名空間就可以，也不需要修改MediaWiki軟件，沒必要採取如此消極的態度。 Midleading（留言） 2026年3月24日 (二) 04:53 (UTC)

「可是明明增加一個命名空間就可以」，這麼偷懶就是在給將來欠債……以後再有大宗導入，也要切割出一個個命名空間嗎？這根本不是命名空間存在的目的，命名空間是用來「differentiate between the purpose of the pages at a high level」的，不是拿來當分類用的…… dringsim 2026年3月24日 (二) 08:04 (UTC)

我建議命名空間命名為法律文書，不是CJOOP，已經避免了以後再有大宗導入需要再次新建命名空間。大宗導入之前已經有過，四庫全書、四部叢刊、古今圖書集成都是，以後也會有，但沒有所謂「也要切割出一個個命名空間」的問題。假如以後有人導入了識典古籍全文、中國國家圖書館的所有書籍、或者是人民日報和其他報紙所有的文章，也不會有人要提出新建命名空間的問題，直接收錄主命名空間即可。由此看來，裁判文書確實和書籍類原文存在根本性差異，這一差異是每個讀者都關注的。有可能和裁判文書一樣還需要新建命名空間的是學術期刊文章。學術期刊文章方面，維基數據已經有前車之鑑。維基數據因為收錄了太多學術期刊文章到主命名空間，導致效率低下，被迫進行拆分，還一直有把學術期刊文章進一步分離到新命名空間或者新項目的提議。維基數據是面向機器的，站內檢索不太重要，本站中站內檢索是一個最重要的功能。總之，新建一個命名空間是完全解決收錄大量裁判文書這一技術問題的技術需要，不是所謂的給將來欠債。不這麼做，只是添加一個分類，放任真正導入以後出現可用性問題，才是偷懶和給將來欠債。 Midleading（留言） 2026年3月25日 (三) 04:27 (UTC)

照這樣說，每類文章都存在「本質」差異，是否都需要獨立命名空間？這其實正是分類的用途，而非命名空間。—— Eric Liu_（留言） 2026年3月31日 (二) 21:03 (UTC)

我可沒說過什麼「每類文章都存在「本質」差異」，我只說過法律文書和學術期刊文章需要獨立命名空間，不要用稻草人論證。 Midleading（留言） 2026年4月1日 (三) 05:57 (UTC)

有一就有二，為何某類文章可以，某類文章不行？—— Eric Liu_（留言） 2026年4月3日 (五) 15:38 (UTC)

新建命名空間需要申請、投票，不是隨便新建的。只有同時滿足有機器人大量導入，並且這類文章和主命名空間已經存在的大部分文章的類型都不同，才會有人去發起這樣的投票。「為何某類文章可以，某類文章不行」是因為對每個申請都有這樣一個投票過程，確保新建命名空間的必要性。這個申請的目的不是指以後每個機器人導入都需要新建命名空間。 Midleading（留言） 2026年4月5日 (日) 02:45 (UTC)

題外話：目前Category:期刊論文里只有本人創建的兩篇文章。—— 內存溢出的貓（留言） 2026年4月19日 (日) 09:15 (UTC)

•  支持新建名字空間。實在太多，應該建一個。同時，也可以：自動將主條目重定向：XX案件若Case:XX案件存在就自動重定向。已有的中華人民共和國裁判文書全部移動到新命名空間。不過這一步無需馬上，以後誰有精力慢慢搞就行。--維基小霸王（留言） 2026年3月14日 (六) 02:25 (UTC)

倒是建議匯入文章可用編號命名（而不是糾紛內容），好處是方便設計篩選搜尋，不管有沒有獨立命名空間。—— Eric Liu_（留言） 2026年4月3日 (五) 15:38 (UTC)

CJOPP的大量匯入或許有其特殊之處（沒有原件因此需要半保護等），可能也是一種「purpose」的區分。 魔琴（留言） 2026年4月8日 (三) 15:55 (UTC)

@Ericliu1912、Midleading、Shizhao、Stang、Teetrition、沈澄心、維基小霸王、魔琴：煩請再次確認討論結論⸺支持還是反對？雖然雙方都言之有理，但我只能採納一個答案，不能無共識結案。 SuperGrey（留言） 2026年4月15日 (三) 20:05 (UTC)

我傾向支持。 Teetrition（留言） 2026年4月16日 (四) 02:12 (UTC)

反對，沒有必要 Shizhao（留言） 2026年4月16日 (四) 02:53 (UTC)

反對，理同前述。—— Eric Liu_（留言） 2026年4月16日 (四) 21:09 (UTC)

反對，同前。Stang 2026年4月16日 (四) 23:42 (UTC)

如果不想建一個新名字空間至少應該建個過濾器禁止非自動確認用戶編輯裁判文書。--GZWDer（留言） 2026年4月17日 (五) 00:47 (UTC)

@GZWDer 反對「禁止非自動確認用戶編輯裁判文書」，文書中有大量提及同/另案文書的不規範命名，需要加入內鏈。—— 內存溢出的貓（留言） 2026年4月19日 (日) 09:17 (UTC)

支持 維基小霸王（留言） 2026年4月18日 (六) 01:22 (UTC)

目前顯然是無法達成共識了。結論：無共識，維持現狀，即不使用新命名空間。
此討論串暫不關閉，歡迎大家繼續討論此議題。 SuperGrey（留言） 2026年4月19日 (日) 10:25 (UTC)

•  支持，不過建議命名空間使用「CaseLaw:」，因為 case 一詞單用含義不明確。 --PacmanD（留言） 2026年10月6日 (二) 20:38 (UTC)

關於 header, header2, header3 的問題

@Midleading，既然 header 已經用 Lua 重寫，可否考慮合併 header2，header3。 Viztor（留言） 2026年3月26日 (四) 17:59 (UTC)

你的意思是把 header2，header3 重定向到 header 嗎，還是調用 Module:header ，還是把 header2，header3 也重寫到 Module:header2，Module:header3 ？ Midleading（留言） 2026年3月27日 (五) 11:39 (UTC)

通過增加參數的形式統一調整到 Template:header 控制目前看來是最佳的且最簡單的，重定向當然更好，目前看來需要機器人手動修改大量頁面。重寫到 Module:* 無意義啊，這幾個模塊差異很小，減少不了後續維護的工作量，統一之後對於機器人或者其他自動處理程序來說全維基只需要處理識別 header 模版獲取元信息會更便捷一些，且也便於 header 模塊後續的修改，而非需要手動對比調整。理論上這都是技術債，一開始就不應該通過新建模版的形式創建 header2，header3，增加參數控制就好了。 Viztor（留言） 2026年3月29日 (日) 09:18 (UTC)

需要使用 Template:header 重寫 header2，header3 模板，再通過在 header2，header3 前面加上 subst: 的方式把 header2，header3 模板自動升級成 Template:header。 Midleading（留言） 2026年4月5日 (日) 10:22 (UTC)

裁判文書的命名

• 張某1、張某2等民事一審民事判決書，caseopen能找到124篇同名文書，需要考慮如何消歧義。
• 中國裁判文書網的文書名稱不一定是好名稱。例如宋俊盜竊罪、盜竊罪刑事一審刑事判決書裡面「盜竊罪」出現兩次是沒有理由的。

GZWDer（留言） 2026年4月2日 (四) 16:28 (UTC)

目前bot會自動建立{{Versions}}頁消歧義。
名稱雖然不好，但是尊重原文也是一種消極的選擇。雖然這個議題先前已經討論過了。 SuperGrey（留言） 2026年4月2日 (四) 22:56 (UTC)

@SuperGrey：對於張某1、張某2等民事一審民事判決書來說，建消歧義頁可能更合適一些，因為這不是同一作品的不同版本。 GZWDer（留言） 2026年4月10日 (五) 13:19 (UTC)

👌等出現第2個同名判決書之後，就會建立消歧義頁。 SuperGrey（留言） 2026年4月19日 (日) 10:30 (UTC)

請問「安徽省阜南縣人民法院（2021）皖1225民初1222號民事判決書」是否可行？民國很多裁判文書就是命名。另中共早就下架「安徽省池州市中級人民法院（2020）皖17行終31號行政判決書」。--TunnelESON（留言） 2026年4月20日 (一) 02:51 (UTC)

> 請問「安徽省阜南縣人民法院（2021）皖1225民初1222號民事判決書」是否可行？
當然可行；如果改成消歧義頁，此文書就會移動到此名。
> 安徽省池州市中級人民法院（2020）皖17行終31號行政判決書
站內沒搜尋到您說的這個？ SuperGrey（留言） 2026年4月20日 (一) 02:55 (UTC)

也請看User_talk:廣九直通車#中共裁判書。--TunnelESON（留言） 2026年4月21日 (二) 03:17 (UTC)

感覺文庫快被民事判決書淹沒了，點擊隨機作品十次有六、七次是判決文書。 Liouxiao（留言） 2026年5月30日 (六) 14:31 (UTC)

只要不將其排除出「有內容的頁面」的定義（mw:Manual:$wgContentNamespaces），就會被隨機到。感覺有點難辦。 SuperGrey（留言） 2026年5月30日 (六) 17:37 (UTC)

@Liouxiao、SuperGrey：瑞典語維基百科有一個可以排除機器人的隨機頁面工具。 GZWDer（留言） 2026年6月3日 (三) 16:06 (UTC)

本來就應該用編號。堅持用什麼「中國裁判文書網」俗名，唯有自討苦吃。老早勸過當事人了，沒用，那也無可奈何。—— Eric Liu_（留言） 2026年6月2日 (二) 20:47 (UTC)

現在亡羊補牢辦法，就是遇有消歧義需要或GZWDer君提及糟糕名稱時，即正名為編號標題。—— Eric Liu_（留言） 2026年6月2日 (二) 20:51 (UTC)

勸我幹什麼？這不是社群很反對嗎？還是說希望我自作主張？我本人當然是更喜歡怎麼簡單怎麼做，編號確實比俗名簡單，但是我首先要尊重社群的意見。 SuperGrey（留言） 2026年6月2日 (二) 21:32 (UTC)

如何錄入這本書？

原文：[4]

如題，這本書的名字叫《�菴集》。但是�unicode不存在。怎麼辦？就在維基文庫輸入

"⿱秋木菴集"

如何？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年4月7日 (二) 03:21 (UTC)

Liouxiao（留言） 2026年4月8日 (三) 02:27 (UTC)

"貼是"是什麼意思？

《海東諸國記》有說過：「

砂貼是。〈쉬릐〉 木貼是。〈파지〉

」

砂貼是 和 木貼是 看似都是名詞，但是我不知道「貼是」到底是什麼。各位的中文比我的更好。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年4月15日 (三) 18:52 (UTC)

「碟子」。砂貼是：「皿」；木貼是：「鉢」。可能是琉球語的漢文讀音，比如從漢語「磁楪子/砂陶碟子」、「木楪子/木碟子」（音近）傳讀後錯訛而來。

參考 https://kodaimoji.chowder.jp/pdf/pdf/takekoshi35.pdf Liouxiao（留言） 2026年4月16日 (四) 01:31 (UTC)

感謝！！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年4月16日 (四) 14:00 (UTC)

提議引入間距優化小工具

中文維基百科現在使用w:MediaWiki:Gadget-text-spacing.css來改善中文與其他字符混排時的字距，建議本站也啟用。 dringsim 2026年5月2日 (六) 07:36 (UTC)

中文維基百科並非一致同意引入間距優化小工具，先請問本地用戶是否支持引入？ Midleading（留言） 2026年5月2日 (六) 10:06 (UTC)

我先  支持。我自己已經長期試用過各種字體新特性，除了w:MediaWiki:Gadget-text-spacing.css#L-17--L-39這些已知例外，開著都是有益排版美觀的：

font-feature-settings: "chws";
text-rendering: optimizeLegibility;
text-autospace: normal;
text-spacing-trim: trim-start;

如果部分古籍有特殊排版需求，可以通過CSS再個別調整。

• font-feature-settings
• text-rendering
• text-autospace
• text-spacing-trim

備註：請大家忽略我的以上推銷，只討論w:MediaWiki:Gadget-text-spacing.css涉及的text-autospace: normal;就好。 SuperGrey（留言） 2026年5月2日 (六) 11:51 (UTC)

已匯入間距優化小工具，當前暫不預設開啟，請各使用者自行測試小工具。 Midleading（留言） 2026年5月13日 (三) 12:15 (UTC)

@Midleading：既然是自行測試，要不要另外做一個開啟我提到的所有選項的CSS小工具，也供大家自行測試？

相比之下，14行改成上面的原始碼，40行改成下面內容即可：

font-feature-settings: normal;
text-autospace: no-autospace;
text-spacing-trim: space-all;

SuperGrey（留言） 2026年5月13日 (三) 15:52 (UTC)

小工具標題可以叫：開啟所有「CSS字體模塊第4級」特性（部分瀏覽器未完全支援）。 SuperGrey（留言） 2026年5月13日 (三) 15:58 (UTC)

小工具名稱可以叫：MediaWiki:Gadget-font-features.css。 SuperGrey（留言） 2026年5月13日 (三) 15:59 (UTC)

只有一個用戶使用的工具似乎更適合作為用戶頁保留，請問有沒有其他人需要使用？ Midleading（留言） 2026年7月9日 (四) 02:08 (UTC)

支持。—— Eric Liu_（留言） 2026年6月6日 (六) 12:59 (UTC)

小工具已經啟用一段時間，現在請問是否支持將小工具預設開啟？ Midleading（留言） 2026年7月9日 (四) 02:09 (UTC)

支持。並希望 zh-wikisource 小工具今後以單獨 repo 維護，這樣在上游停止維護後，未來本社群仍可修復發現的問題。 PacmanD（留言） 2026年8月28日 (五) 15:07 (UTC)

完成 間距優化小工具現在預設開啟。 Midleading（留言） 2026年9月19日 (六) 15:14 (UTC)

非國家機關與國家機關聯合發文是公有領域嗎

人民/群眾團體和行政機關聯合發文，從發文字號來看主辦機關是群團組織的。如《全國婦聯 教育部等九部門關於印發〈全國家庭教育指導大綱（修訂）〉的通知》（婦字〔2019〕27號）、《中華全國總工會 文化和旅遊部 國家電影局 國家體育總局關於深入推進新時代職工文體工作高質量發展 擴大職工文體消費的意見》（總工發〔2025〕18號）和《共青團中央、中央網信辦、國家發展改革委、教育部、國家民委、民政部、財政部、人力資源社會保障部、自然資源部、住房城鄉建設部、文化和旅遊部、國家衛生健康委、體育總局、國家統計局、中國社科院關於深化青年發展型城市建設助力建設現代化人民城市的意見》（中青聯發〔2026〕5號）。 Ky476（留言） 2026年5月3日 (日) 14:20 (UTC)

您設定的特徵對應不上著作權法的金標準，所以不會有正確答案。從實務上來說，通常都會是，除非相關文獻並沒有著作權法第五條所規定需要的性質，但我想這種情況幾乎不太可能發生。 銀色雪莉（留言） 2026年5月7日 (四) 10:00 (UTC)

多個維基數據項能否鏈入同一頁面

我在維基數據問過詩經同名詩的拆分，暫無回復。我想詢問如題。（即使不能，我也不覺得為此就要在維基文庫也拆分。感覺現在詩歌拆得太細了。（相比之下，司法解釋當然全文只有一句話也只能拆分。））

順便，維基數據不少數據項名為「序」「Preface」，應是維基文庫導入所致。這也蠻有意思，比如原名就叫「序」而不是「某書序」，除非後人有引作「某書序」否則這些數據項真就只能叫「序」。 物靈（留言） 2026年5月27日 (三) 05:21 (UTC)

同名詩應該在維基文庫拆分成多個頁面，因為根本不是同一作品。 GZWDer（留言） 2026年5月27日 (三) 13:17 (UTC)

確應拆分。不同版本的重複頁面才會遇到你所說的問題。 內存溢出的貓（留言） 2026年7月10日 (五) 18:07 (UTC)

拆分已完成。 PacmanD（留言） 2026年8月29日 (六) 04:07 (UTC)

是否應當保留文末的注釋？

留意到部分文章中，文末保留有一些注釋，見關於赫魯曉夫的假共產主義及其在世界歷史上的教訓#注釋，內容大部分是引句來源文字。我認為注釋部分不應視作原文的一部分，應當刪去。上傳者Fire-and-Ice認為注釋是人民日報刊載中有的，不應刪去。故現請求社區成員討論。ping一下@銀色雪莉閣下，謝謝！ 1969社論（留言） 2026年6月12日 (五) 01:33 (UTC)

私以為閣下所列文章的這種引注是原文的必要組成部分（類比到論文，一篇論文如果實際引用了但沒有引注甚至都不合規範），如果原版本中有，基於忠實呈現該版本樣態的考慮，無理由刪去。本地需要討論的更多是編輯者自己加的注釋。 Teetrition（留言） 2026年6月12日 (五) 02:48 (UTC)

參考文獻當然是文章的一部分，我不知道這為什麼還要討論？ Fire Ice 2026年6月12日 (五) 05:37 (UTC)

謝ping。除了上方的討論，我也讀了閣下和Fire-and-Ice閣下在別處的討論。查了一下電子掃描件，本件和人民戰爭勝利萬歲的注釋是在原來刊發在人民日報時就有的，一般而言如果沒有例外證明（例如說「編者注」），一般還是應視為屬於原文的一部分（就像上面兩位說的，類似當今寫論文時的參考文獻），是應該被視為一個整體一起收錄的。這和一些古籍出版帶有注釋的本子的情況不同，因為那種情況下古籍的作者和注釋的作者明顯地並非同一人，古籍是一個作品，加注釋的古籍按照版權法的表述是一個新作品，後者有它需要另外考慮的版權情況，這種版權情況是因為其明示而得到考慮的。而且退一萬步講，即使這是編者注，就兩件的情況而言，也已經超過五十年了，應當可以收錄的（當然，如果是這種情況，那麼還可以分為有編者注和無編者注的版本，因為那也是兩個作品——當然這是題外話了）。 銀色雪莉（留言） 2026年6月12日 (五) 06:27 (UTC)

補充：這種例外證明並不一定要明示「編者按」，就像姚文元那篇評海瑞罷官，它在被解放軍報還是哪裡的文章轉載時加上了編者按這件事是被歷史材料或記述所證實的，那麼即使它在刊載時沒有註明「編者按」「編者注」，應該也足以為前述的例外證明了。 銀色雪莉（留言） 2026年6月12日 (五) 06:48 (UTC)

謝謝各位參與討論，先前提出討論確實是擔心注釋為後人所加而非原文如此。本人現已補回先前移除的注釋內容。 1969社論（留言） 2026年6月13日 (六) 12:49 (UTC)

借地說一下，本站所收《粉碎林陳反黨集團反革命政變的鬥爭（材料之二）》（中共中央通知 (1972年1月13日中發〔1972〕4號)）附有「編注」，不知是誰人所注。文件來源也不明。Fire Ice 2026年6月20日 (六) 15:02 (UTC)

@Fire-and-Ice：附件一圖片來源可疑，和孔網照片和附件二文字對比明顯缺頁；附件二「編注」可能來自《華夏文摘》（[5]）？ dringsim 2026年6月20日 (六) 18:06 (UTC)

民國政府的公報出處

請問各位前往國家圖書館政府公報資訊網正常否？或403禁入？--TunnelESON（留言） 2026年7月9日 (四) 02:17 (UTC)

@TunnelESON：正常。 銀色雪莉（留言） 2026年7月9日 (四) 03:56 (UTC)

謝謝。在下遇到403禁入。解決前，就更有請能正常去那網站用戶收集文本。--TunnelESON（留言） 2026年7月10日 (五) 01:25 (UTC)

分類:政府公報 (民國)是{{中華民國政府公報}}造成的，要改成像是{{中華民國政府公報|民國年=3年}}。--TunnelESON（留言） 2026年9月2日 (三) 04:46 (UTC)

立法院國會圖書館立法院智庫早就停止總統府公報影像系統，但國家圖書館有更多公報，只是有的卷期尚未編目。政府公報 (北洋政府)以及政府公報 (中華帝國)用的PDF是分月合訂本。--TunnelESON（留言） 2026年9月13日 (日) 00:36 (UTC)

臺北政治大學也有整理民國人事任免令，有利本站以及共享資源分類。--TunnelESON（留言） 2026年9月16日 (三) 01:28 (UTC)

翻譯:朝鮮民主主義人民共和國反對反動思想文化法的注釋問題

翻譯:朝鮮民主主義人民共和國反對反動思想文化法頁面中的注釋已經超出翻譯的範疇（參考en:Wikisource:Translations），而參考en:Wikisource:Annotations的內容，本頁面中的注釋的中立性和解釋性有待探討，歡迎參與討論。 MarkZhou08（留言） 2026年7月21日 (二) 06:43 (UTC)

同樣認為該注釋超過翻譯範疇，可以移交其他項目。 Teetrition（留言） 2026年7月22日 (三) 03:50 (UTC)

這事實上已經形成了原創內容，據Wikisource:收錄方針#註解和Wikisource:收錄方針#原創作品，眼下只有兩條路可走，要麼清理這些注釋，要麼送維基教科書看看收不收（當然也可以兩者同時進行，這應該也沒什麼衝突）。副知貢獻者@CreeperDigital1903閣下看就處理方案有何意見。 銀色雪莉（留言） 2026年7月25日 (六) 15:45 (UTC)

已收到。可予以清理。 CreeperDigital1903（留言） 2026年7月26日 (日) 00:39 (UTC)

頁面Translation:朝鮮民主主義人民共和國反對反動思想文化法的「譯者注釋」似乎不當

頁面Translation:朝鮮民主主義人民共和國反對反動思想文化法的翻譯者加入了大量具有鮮明毛派特徵的「注釋」，其中多半是評論性的。這也許算Wikisource:收錄方針禁止的「原創作品」吧？是否可以全部刪除？ Yu Nuomin（留言） 2026年7月24日 (五) 05:06 (UTC)

抱歉，剛才發現已經有人在討論這個問題了，所以 撤回請求 Yu Nuomin（留言） 2026年7月25日 (六) 01:08 (UTC)

如何上傳《東方ê故事》

原文：

• https://tcmb.culture.tw/zh-tw/detail?indexCode=MOCCOLLECTIONS&id=26000254280
• https://db.nmtl.gov.tw/site3/dindex?search=1&serchkey=&page=18

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月2日 (日) 18:33 (UTC)

這本質上跟錄北拉差不多，我認為是可以的。具體的方法是錄原貌。如果你只是問這本，那就是錄羅馬字「Tang-hng ê kò͘-sū」的那一半而不是「東方ê故事」的那一半，因為從你提供的第一個印刷品上反映出原貌是那樣的，而不能僅因為第二個網站就決定是錄全羅還是漢羅合用，所以我建議你參考北拉的例子，見新文字半月刊/第1期/Sin Wenz sh Womn Zgidi Wenz，在能夠查對原件影印件的情況下根據原貌錄入相應內容——這與朝鮮文獻的邏輯也是類似的，我們也需要檢查原件而不是光看當代人轉錄數字化的結果來判斷它是否適合收錄。另參考上述北拉的例子，可能應考慮建立一個類似模板:Latinxua Sin Wenz那樣的模板放在文首順便添分類；還有也可考慮增加像Translation:新文字是我們自己的文字作為有益讀者的丰容，當然我不會說那是必須的，只是一個提議。應該說有北方話拉丁化文字和粵語白話文的例子珠玉在前，閩南語白話文也沒有道理成為收錄的障礙，只是請閣下注意在可查對原貌的情況下才錄入。 銀色雪莉（留言） 2026年8月3日 (一) 00:26 (UTC)

多語言維基文庫上似乎有粵語內容。 內存溢出的貓（留言） 2026年8月30日 (日) 15:24 (UTC)

這是台語，不是粵語。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月30日 (日) 16:10 (UTC)

是的，多語言可以收錄的東西很多，多語言能收什麼和本地能收什麼並非互補而是可以重疊的。 銀色雪莉（留言） 2026年9月1日 (二) 05:36 (UTC)

1961年發布、疑似1982年整理出版的政府公文，現在是否屬於公有領域？

我為查閱某些資料從二手書市場購得（大陸這邊的）文化部出版事業管理局辦公室編印《出版工作文件選編（1958年–1961年）》，意外發現其中有些篇目很有意思†，但互聯網上似乎尚無開放數字版本，所以希望上傳到Commons並在維基文庫抄錄。

不過我擔心存在版權爭議，操作前想先問問大家。這本書的情況如下。

• 公文本身已發布超過50年，無論是否屬於著作權法政府文件豁免範圍，都進入公有領域了。
• 這本書沒有版權頁，封面、封底也沒寫年份（書雖二手但很新，大概率原本就如此）；不過國家圖書館 opac.nlc.cn 系統能查到同名、同作者書籍，標註「出版年：1982」，即44年前。
• 中華人民共和國文化部這個部門只存在於1954–1970年和1975–2018年，而1970年距今超過50年。

†：比如1961年8月10日文出齊字第1162號《關於適當解決年畫用紙，爭取增加年畫印數的通知》講當時紙張緊缺，但「年畫在我國農村中有廣大的需要」，於是文化部計算出印量缺口，聯繫外貿部、各省出版局、文化局和幾家出版社想辦法。聯繫外貿部是因為外貿部本來要出口幾百噸新聞紙。這些新聞紙本來沒法印年畫，但「努力克服困難」也能湊活印。 David, but not Hilbert（留言） 2026年8月24日 (一) 15:50 (UTC)

我又翻了翻Wikisource:版權信息及其子頁面，看來這本書屬於政府文件，和中華人民共和國全國人民代表大會常務委員會公報2021年第一號.pdf差不多，那上傳文件、抄錄文本應該沒問題。 David, but not Hilbert（留言） 2026年8月24日 (一) 16:28 (UTC)

如果互聯網上沒有其他公開文檔，恐怕很難查證。建議將原件掃描後先上傳 Wikimedia Commons，再在 zh-wikisource 進行 OCR 後逐頁面轉錄。 PacmanD（留言） 2026年8月25日 (二) 19:16 (UTC)

我買的這本暫時還沒掃描。Anna's Archive上有《出版工作文件初編（1949–1957）》的電子版，我先上傳了它試試，見出版工作文件初編-1949-1957.pdf。 David, but not Hilbert（留言） 2026年8月26日 (三) 17:51 (UTC)

這份文件很有意思！從中可以看到出版、印刷、發行准入制度是怎麼一步步確立的，查禁書刊制度的演變，不同級別的幹部能夠看什麼書，甚至還能看出「雙百」期間似乎略微放寬了管治。堪稱一部微縮的中國大陸的出版體制史。感謝您的上傳與數字化。 PacmanD（留言） 2026年8月27日 (四) 05:12 (UTC)

提議添加繁簡轉換

諕 Pawsdt（討論 | 貢獻） 2026年8月26日 (三) 01:48 (UTC)

諕轉換為簡體一般寫成唬，請檢查。純粹繁簡轉換建議在維基百科申請，因為那裡可以申請到全域繁簡轉換，維基文庫這裡申請只對維基文庫生效。 Midleading（留言） 2026年8月26日 (三) 04:13 (UTC)

請問 MediaWiki 系對於「類推簡化字」有什麼處理原則嗎？𬤀（U+2C900）位於 Unicode E 區（2025, 8.0）一般系統字體也是不能渲染的吧。 PacmanD（留言） 2026年8月26日 (三) 06:41 (UTC)

MediaWiki 沒有什麼特殊要求，只要是 Unicode 已收錄的字都可以錄入。 Midleading（留言） 2026年8月27日 (四) 03:45 (UTC)

關於繁簡轉換的建議

現在每次點開新頁面都要重新點一次簡體特別不方便。建議讓他保存一下繁簡信息 Pawsdt（討論 | 貢獻） 2026年8月26日 (三) 03:19 (UTC)

在偏好設定中的內容語言變體：保存。 Midleading（留言） 2026年8月26日 (三) 04:08 (UTC)

這是什麼字？

一

原文：「慈愛清平共莫違。黃扉異寵已當期。行看五▦歌騰處。」

原圖：

[6] pg 18

[7] pg 36 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月29日 (六) 18:05 (UTC)

桍? PacmanD（留言） 2026年8月30日 (日) 00:50 (UTC)

「行看五桍歌騰處」——出《後漢書》廉範傳：「廉叔度，來何墓？不禁火，民安作。平生無襦今五絝。」(五絝，又作五桍，歌頌官吏廉明能幹。） Liouxiao（留言） 2026年8月31日 (一) 05:52 (UTC)

宋慕容彥逢《上知府張朝請》：「五袴於今預蜀歌，三語何時同晉掾。公不見黃金百鎰未為優，季布一諾百不愁；又不見李白不願萬戶侯，惟願一識韓荊州。」(參見《永樂大典/卷10999》) Liouxiao（留言） 2026年8月31日 (一) 06:18 (UTC)

原文：「時先君謬▦庸夫怨謗」

這個字是不是「被」？

原圖：

[8] pg 28

[9] pg 14 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月29日 (六) 18:08 (UTC)

是「被」，但後面可能是「怨謗」，也可能是「惡謗」？ Liouxiao（留言） 2026年8月31日 (一) 05:54 (UTC)

原文：「梁衣服改制之牒數▦故反之」

原圖：

[10] pg 115

[11] pg 52 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月29日 (六) 18:12 (UTC)

「課衣服改制之牒數段故及之」，看著像是「段」字；另第一個字像「課」，倒數第二字像「及」。 Liouxiao（留言） 2026年8月31日 (一) 06:01 (UTC)

剛才想了一下，這裏用「段」好像不太通，可能用「殷」（表示次數多）更好：「課衣服改制之牒數殷，故及之」—— 有感於督促改換衣服樣式的牒文頻繁地頒下，所以在這首七言詩裏提及這件事。 Liouxiao（留言） 2026年8月31日 (一) 09:00 (UTC)

原文：「存亡▦俱。成仁取義。」

原圖：[12] pg 126

[13] pg 220 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月29日 (六) 18:15 (UTC)

「存亡與俱」——文徵明詩「可憐功業惟詩在，自決存亡與國俱。」 Liouxiao（留言） 2026年8月31日 (一) 06:14 (UTC)

@Liouxiao @銀色雪莉 @DuckSoft 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年8月30日 (日) 22:43 (UTC)

二

原文：「不為外物▦汩。而常令意思激昂。」

原圖：[14] pg 5

[15] pg 6

[16] pg 5 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年9月1日 (二) 19:05 (UTC)

@Liouxiao @銀色雪莉 @DuckSoft @PacmanD 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年9月1日 (二) 19:07 (UTC)

是不是「扼」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年9月1日 (二) 19:07 (UTC)

看字形是「扼」，意思也通。——吳與弼：「正襟端坐，讀聖賢書，收斂此心，不為外物所汩，夜倦則寢，此外非所當計。」 Liouxiao（留言） 2026年9月2日 (三) 02:33 (UTC)

三

原文：「次黃叔貢。_{時▒得凍秀魚。勸付行槖供慈廚。}」

這個字是不是「網」

原圖：[17] 冊一 頁45

[18] pg 16

[19] pg 45

[20] pg 87

[21] 冊二 頁14b 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年9月2日 (三) 01:36 (UTC)

原文：「次可柔韻_{可柔詩。有▒玉待價之句。故戲之。}」

這個字是不是「蔵」

原圖：[22] 冊一 頁62

[23] pg 34

[24] 62

[25] 122

[26] 冊二 頁32a 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2026年9月2日 (三) 01:51 (UTC)

是「蔵」，通「藏」。——蔵玉待価。 Liouxiao（留言） 2026年9月2日 (三) 02:38 (UTC)

是「網」，捕魚。 Liouxiao（留言） 2026年9月2日 (三) 02:35 (UTC)

zh-wikisource《四庫全書》的來源問題，以及後續計劃

目前中文網際網路上流傳的《四庫全書》電子文本，其主要源頭應可追溯至收藏於台北故宮的《文淵閣四庫全書》。其影印版，《景印版文淵閣四庫全書》共 1500 冊，1980 年代由台灣商務印書館出版，後由中國大陸的出版社翻印。中國大陸所藏的《文溯閣》《文津閣》《文瀾閣》本，相關整理、出版則較晚。

本站所收錄的《四庫全書》文本來源不清晰。但根據其中的一些典型錯誤（例如錯用了日文漢字）分析，其實際來源應為 Kanripo Project。

其實想想即知《四庫全書》共計約 8 億字，將其重新 OCR 並校對，絕非個人或小團體能夠承擔的小型工程。而 Kanripo 也並非獨立承擔了這一 OCR 工作。其文本來源很可能源自更早期的迪志/書同文等機構合作的《文淵閣四庫全書》電子文本。這一判斷並非僅憑 Kanripo 中的「WYG」名稱或傳聞，而是根據其中若干有辨識度的錯誤進行了交叉比對。

我想，既然有前輩做了最基礎的工作，將《四庫全書》完整地整理為文本，我們也無需再做一遍 OCR，只需在目前的基礎上修改完善、據影印圖片內容互校即可。事實上，目前的工作框架已經搭好：

• 景印文淵閣四庫全書書名目錄 包括全部 1500 冊的目錄，已連結到新創立的 1500 冊 index 頁面。
• 每本書的第 5 頁為該冊的目錄頁，已由機器人在 Index: 頁面整理出每本書的 pagelist 來。
• 電子版文本可以逐頁存入 Page: 頁面。這部分預計會產生約 135 萬個新頁面。此步驟可由機器人完成。例子：Index:文淵閣四庫全書_0862冊.djvu#夢溪筆談（補筆談）
• 等完成一本書的錄入之後，在 ____ (四庫全書本) 頁面連結 Page: 書葉內容即可重建完整的電子版《四庫全書》。如發現 OCR 或者排版錯誤，可到 Page: 頁面查詢原始影印書葉，並直接修改。例子：欽定儀象考成_(四庫全書本)

關於版權問題

本人不是法律專家，但根據本人對美國版權法律及相關判例的理解，直接將既有電子文本匯入本站的版權風險應當很低。

首先，Kanripo Project 本身已經公開使用這套電子文本多年，相關文本也已經在網路上流傳多年。其次，本項工作所處理的主要是《四庫全書》原文及其影印本所呈現的客觀資訊，例如文字本身、字序、頁碼以及文字在書葉上的位置關係；這些內容是對原始文獻的忠實記錄，而非新的文學或學術表達。

就美國版權法而言，版權保護的是具有原創性的表達，而非「事實」本身。對不受版權保護的原始材料進行忠實、準確的複製，也不會僅因為錄入工作本身具有大量勞動而產生新的版權。因此，如果所匯入的內容僅限於《四庫全書》原文及其忠實版面資訊，而不包含現代編者具有原創性的改寫、評註或其他創作性整理，本人認為其版權風險很低。

當然，這並不意味著任何名為《四庫全書》的現代電子資料庫都可以不加區分地完整複製；具體仍應區分古籍原文、影印本的版式、OCR 文本以及現代編者新增的整理成果（例如標點等）。本項工作的目的，正是以可追溯的影印本電子文本為依據，使其得以與實際影印頁面進行校核。 PacmanD（留言） 2026年8月31日 (一) 21:39 (UTC)

據我了解，無論根據中美法律還是伯尼爾公約，對於古籍的忠實複製，包括影印、文字整理，即使付出辛勤勞動，也不屬於原創性工作，不受版權保護。在現代工具加持下，我也希望看到更多古籍被準確數字化。四庫全書雖然有着諸多問題，但總是繞不開的一套大型叢書，文獻歷史價值巨大。

希望看到作者在這項工作的更多進展。 古籍小助手（留言） 2026年9月11日 (五) 05:01 (UTC)

竪排和楷體顯示選項已在全站啟用

顯示選項小工具現已更新。現在，在全站範圍都可以切換竪排和楷體顯示選項，包括主命名空間、Page命名空間、Translation命名空間、以及用戶頁，即使頁面沒有嵌入Page頁面也可以使用竪排和楷體顯示選項。竪排顯示時，頁碼範圍的高亮顯示問題已修復。已刪除未使用的4種佈局。顯示選項小工具可能會造成小部分頁面的模板顯示異常，如有發現請反饋。 Midleading（留言） 2026年9月17日 (四) 03:48 (UTC)

感謝修改！反饋一個小問題，見下圖。麻煩把豎排時的頁碼逆時針旋轉 90 度，這樣頁碼會更直觀。目前，左端位置似乎恰好能使與右端的頁邊界對齊。

--PacmanD（留言） 2026年9月17日 (四) 04:52 (UTC)

其實是頁碼也豎排的結果，如果加「rotate: 270deg;」樣式雖然可把數字旋轉回來，但頁碼為中文時會過度旋轉。 Midleading（留言） 2026年9月17日 (四) 08:59 (UTC)

已解決 Midleading（留言） 2026年9月19日 (六) 15:19 (UTC)

哇，這個功能挺實用！我有以下兩個問題/建議。

• 豎排時，目前{{專}}與{{書}}看起來在兩行間距的正中央，難以直接判斷是標註前一行還是後一行，需結合文本實際內容猜測。建議增大行間距，或者減小{{專}}與{{書}}的text-underline-offset。

  在維基文庫中，有的書把這種行間線標在文字左側，而有的書標在右側，所以明確維基文庫標在左側還是有必要的。

  至於是否要支持切換標左標右，我認為支持的意義不大。從方便當代閱讀的角度，CLReq介紹「直排時，行間線標註於文字左側」，所以現在這樣標左就夠了。從接近原文原貌的角度，行間線只是標點符號的一小方面，除非有功夫通盤考慮全部標點符號，否則單純支持調整行間線並沒有太大效果。（比如1922年《婦女雜誌》將專名號、逗號都標在文字右側，其Page/106第二欄第三行「是在想他舊游之地的爪哇，……」專名號緊跟逗號，於是縮短專名號以避讓逗號；即使CSS能實現這種效果，那麼也不排除其它書籍用其它方式處理，比如專名號保持不變，逗號外移以避讓專名號；即使能提供選項切換處理方式，那麼編輯者設置選項時也很難從全書找出所有專名號與逗號衝突的例子……）

• 是否有人比較過默認字體與楷體的字形？會不會存在某字有A、B兩種寫法，默認字體的x、y碼位分別是A、B，而楷體的x、y碼位分別是B、A，二者相反，導致校對時無所適從？

  建議在楷體模式編輯時，自動添加某種標籤，類似維基百科Special:Tags的「可視化編輯」「可視化編輯：已切換」那種。

David, but not Hilbert（留言） 2026年9月18日 (五) 04:20 (UTC)

「默認」與「楷體」都可能會顯示成不同的 glyphs 的。目前的「楷體」定義如下；取決於使用者系統裡裝了什麼，fallback 到這些字型中的任何一個。如希望徹底解決此問題，可引入統一的 webfonts；之前提過幾次類似的建議，看起來實作有一定難度（主要是 Wikimedia 基金會隱私權政策層面的問題）。

Times, "Kaiti TC", 標楷體, DFKai-SB, "AR PL UKai HK", "AR PL UKai TW", BiauKai, Kai, 全字庫正楷體, TW-Kai, TW-Kai-Ext-B, "Kaiti SC", TH-Khaai-PP0, TH-Khaai-PP2, TH-Khaai-TP0, TH-Khaai-TP2, TH-Feon-A, 楷體, KaiTi, 楷體_GB2312, KaiTi_GB2312, FandolKai, 華文楷體, STKaiti, "AR PL UKai CN", EUDCKAI, cursive PacmanD（留言） 2026年9月19日 (六) 06:26 (UTC)

請問「之前提過幾次類似的建議」是指使用webfont，還是標記編輯者所用字體呢？後者涉及隱私我可以理解；若指前者，我不太理解，難道是第三方webfont服務所致？可否再解釋解釋？ David, but not Hilbert（留言） 2026年9月19日 (六) 15:29 (UTC)

是指用 webfonts。目前全站僻字小工具已經預設開啟，未來可以更進一步。如果文庫全站統一使用專屬的 webfonts，就能確保所有人看到的字型至少是一樣的，Unicode 的僻字也能夠正常顯示。 PacmanD（留言） 2026年9月21日 (一) 23:27 (UTC)

又發現一個問題：編輯校對頁時的「顯示預覽」尚不支持，始終使用橫排默認字體。 David, but not Hilbert（留言） 2026年9月19日 (六) 15:42 (UTC)

我編輯了Page頁面，顯示預覽時可以以楷體豎排顯示，請再指出具體的頁面位置和編輯操作。 Midleading（留言） 2026年9月19日 (六) 16:51 (UTC)

訪問任意校對頁（如Page:魯迅全集01_(1948).pdf/483），單擊右上角「編輯源代碼」。待頁面完成加載後，向下滾動，單擊「發布更改」與「顯示更改」之間的「顯示預覽」。再次等待加載完成，發現預覽結果是橫排默認字體（無論之前設置了什麼），並且左上角菜單沒有書寫方向和字體設置（到「幫助」就完了）。 David, but not Hilbert（留言） 2026年9月20日 (日) 00:49 (UTC)

我嘗試了在這個頁面顯示預覽，結果可以自動應用之前記憶的豎排和楷體設置，可以看到書寫方向和字體設置。有許多頁面通過添加豎排模板強制頁面為豎排，所以沒有排版設置。 Midleading（留言） 2026年9月28日 (一) 15:13 (UTC)

MediaWiki:Gadget-PageNumbers-core.js#L-304處代碼在104命名空間（校對頁）會出現問題：

由於原始DOM結構如下，會將.pagetext里的內容抽出來，導致載入的樣式表無法匹配。

目前測試，將.pagetext排除即可。應當對其他功能無影響。

<div id="mw-content-text" class="mw-body-content">
 <div class="prp-page-container">
  <div class="prp-page-content">
   <div class="mw-content-ltr mw-parser-output" lang="zh-Hant" dir="ltr">
    <div class="prp-page-qualityheader quality3">本页已校对</div>
    <div class="pagetext">
     <div class="mw-content-ltr mw-parser-output" lang="zh-Hant" dir="ltr">
      <style>.mw-parser-output .pagetext ..rules..</style>
      ...content
    </div><!-- 无其他子节点 -->
   </div><!-- 下省略 -->

--小老虎3018（留言） 2026年9月21日 (一) 18:10 (UTC)

已改為只將.pagetext下級的內容進行排版調整。 Midleading（留言） 2026年9月28日 (一) 15:16 (UTC)

提議剝奪全域管理員在這裡的權限

根據元維基的政策，中文維基文庫默認允許全域管理員執行管理性操作，因為只有八名本地管理員。但是，本站有四名活躍管理員，且Special:Log/block、Special:Log/delete和Special:Log/protect顯示，本站上的絕大多數管理性操作都由本地管理員執行，這些足以說明本站的自治能力已經足夠。此外，本站上的破壞行為並不頻繁。因此，我在此提議剝奪全域管理員在這裡的權限。 Pristome（留言） 2026年9月25日 (五) 15:37 (UTC)

不明白取消權限有何益處？全域管理員並不干涉本站決策。—— Eric Liu_（留言） 2026年9月27日 (日) 05:30 (UTC)

不同意本站活躍管理員足夠多以及破壞行為並不頻繁，實際上活躍管理員非常少。 Midleading（留言） 2026年9月27日 (日) 15:55 (UTC)

2026年第39期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其他語言的翻譯版本。

本週要聞

• 2026年9月23日14:00 UTC，所有維基站點將進入只讀模式，持續數分鐘。此舉是為了進行數據中心服務器切換備份測試，該測試每年進行兩次。在切換過程中，所有維基媒體網站的流量將從主數據中心轉移至備用數據中心，以測試可用性並確保即使在緊急情況下服務也不會中斷。 [27]

近況更新 - 面向編輯者

• 成長團隊測試了一項新的編輯後提示，以鼓勵臨時賬戶持有者註冊永久賬戶。這項新提示取代了原有的多個對話框及同步顯示的歡迎通知，改為僅展示一條強調創建賬戶益處的信息。該實驗使永久賬戶的創建率從1.94%提升至3.66%，相對增幅達87%。該變更現將推廣至所有維基站點。 [28]
• 對於使用「建議模式」測試版功能的維基百科編輯者，現有一項新的可選用戶偏好設置，用於顯示「實驗性」編輯檢查與建議。這些類型列於Special:EditChecks，旨在供開發者進行早期測試並收集資深用戶的反饋。管理員可照常更改各項建議的配置詳情。管理員還可以利用此功能，協助測試社群針對本地創建的檢查與建議提出的構想。本周晚些時候，這些實驗性類型將採用更具辨識度的視覺樣式。歡迎提供反饋。
• CEE Technical Village Pump已正式設立，為中東歐地區的維基媒體社群提供一個進行技術討論與協作的平台。
• 面向新興及小型語言維基百科社群的一項新工具——入門套件，現已推出。該工具整合了引導式任務、各類工具及資源，以幫助社群起步、追蹤進展，並與更廣泛的維基媒體社群開展協作。入門套件託管於Wikimedia Toolforge平台，專為條目數少於50,000篇的維基百科項目設計。歡迎閱讀這篇Diff博客文章，了解入門套件的運作方式及社群的實際應用情況。
• 讀者成長團隊即將重新開展圖像輪播實驗。此次重測將評估基於社群反饋改進後的三個新設計版本。團隊將評估實驗結果，並與社群共同決定是否繼續推進該功能。實驗將於9月28日所在的一周啟動，覆蓋阿拉伯語、孟加拉語、中文、捷克語、英語、波斯語、法語、德語、印尼語、日語、波蘭語、葡萄牙語、西班牙語、瑞典語和越南語維基百科。
• 繼在阿拉伯語、孟加拉語、中文、捷克語、英語、法語、印尼語和越南語維基百科成功推出後，由讀者體驗團隊開發的閱讀列表功能將於9月28日起向所有維基百科站點的已登錄用戶開放。
• 上週有28件由社群提交的工單得到解決。 例如，此前存在一個問題：即使導師狀態未發生任何變化，導師狀態腳本也會反覆更新其狀態，從而產生不必要的最近更改項；該問題現已修復。 [29]

近況更新 - 面向技術貢獻者

• 用於獲取維基上已配置的活躍或歷史濫用過濾器詳細信息的abusefilters列表查詢API現已更新，支持formatversion=2配置參數，這將導致API響應發生破壞性變更。所有維護用戶腳本或其他代碼的用戶，均需檢查自己是否使用了abusefilters列表查詢API，並針對任何破壞性變更採取相應措施。 [30]
• 本週軟體更新細節： MediaWiki

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2026年9月27日 (日) 11:56 (UTC)

魯迅《吶喊》已全本採用校對頁，歡迎閱讀或進一步核對！

中秋好！向各位報告，經過眾人幾年間歇性努力，魯迅《吶喊》已全本採用校對頁錄入方式，可靠程度大為提高。歡迎大家閱讀或進一步核對！

我在其中參與了不少，有些想法，來分享一下。某些點說不定以後會形成幫助頁面或方針政策，但主要還是隨便說說。

兩種錄入方式

「直接錄入」與「校對頁錄入」是維基文庫錄入文檔的兩種方式。

• 直接錄入即直接編輯普通wikitext頁面，編輯者創建頁面、校對文字時最多在編輯摘要或討論頁面介紹來源，而他人無法在維基文庫內查證。直接錄入的正文品質按整篇文章標註，有25%、50%、75%、100%等。聯合國大會一些決議當前採用直接錄入。
• 校對頁錄入是指編輯者先上傳PDF等格式的影印原文，再逐頁編輯Page頁面，最後將相應Page嵌入作品頁面的錄入方式。採用這種方式，他人在作品頁面閱讀時，如果懷疑某段文字有錯，可隨時轉到相應Page核對。校對頁錄入的頁面狀態分Page標註，有未校對、已校對、已核對等。《吶喊》各篇當前採用校對頁錄入。

與直接錄入相比，校對頁錄入的結果方便查證，而且參與者（無論人還是機器人）不必持有原本就能做出貢獻，是更理想的錄入方式。

不過，校對頁錄入的前提是存在影印原文。一方面，從原本製作影印本，比參考原本校對更加困難；另一方面，影印本有時比文檔文本蘊含更多的獨創性勞動，著作權問題相對複雜。種種因素所致，校對頁錄入儘管理想，但並非絕對主流。根據中文維基文庫社區主頁的統計，當前直接錄入的文章有70,077篇已經完成（正文品質標註為50%或更高），而校對頁錄入的頁面有12,257頁已經校對（頁面狀態為已校對或已核對）。假設每篇文章有十頁，那麼直接錄入完成的文章數量是校對頁錄入的五六十倍。

影印本自身價值

校對頁錄入不僅從錄入結果的角度看更理想，它搭配的影印本自身也有很大價值，特別是它展示了文檔的原文原貌。

像《吶喊》這樣的近代書籍，它們的影印本其實是現代中文版面形成過程中的一張快照。平常一談中華文化就論上下五千年，一提漢字就要追到甲骨文、金文，但現在我們用的這種中文，其實是相當晚近的事：白話語言及用字、漢字繁簡正異、標點符號的用法與寫法、書寫方向橫排豎排……無一不在那個風雲激盪的年代發生了劇變。特別是當時字體排印方面的一些細節工藝，現在用CSS都沒辦法完全復現，只能參考影印圖像。

以下舉一些《吶喊》裡的例子。

• 漢字字形：想必上學讀簡體課本的人都或多或少思考過為何魯迅以「罢」代「吧」。現在一看根據Index:魯迅全集01_(1948).pdf校對過的作品，立馬知道原文其實既非「吧」又非「罢」，而是「罷」；稍微讀幾段，便又直觀感受到當時字形正異並不絕對，甚至還有Page/389這樣同頁同段、同字同義卻有「脚」「腳」兩種字形的情況。

• 標點符號：《一件小事》1919年晨報本的逗號全都像日文那樣寫作「、」，而後來《魯迅全集》收錄本和今日一樣採用「，」。《鴨的喜劇》1922年《婦女雜誌》本與《魯迅全集》收錄本都使用專名號，但前者把專名號標在字的右邊，而後者標在左邊。

• 中西混排：《阿Q正傳》出現了Q和Quei，例如Page/383。其中單個字母Q的方向和漢字相同，占一個漢字位置；而Quei要旋轉一個直角，讓閱讀方向與漢字相同，同時Quei前方、後方或兩端會加空隙，整體占約三個漢字的位置。Q後趕上逗號時，處理方式與漢字類似，逗號下端與Q的下端對齊；而Quei則不然，逗號上端與i的下端對齊，即逗號位於Quei後空隙的位置。

• 兩端對齊：《魯迅全集》中，大部分標點符號都寫在兩行之間，剩下的破折號、成對引號的總長度又是漢字的整倍數，所以只要漢字順着密排，每行兩端基本就能對齊。不過仍有地方需專門兩端對齊：Page/480第一段最後「又向那松柏林前進了。」幾字如果密排，「了。」會形成孤字，於是增大「向那松柏林前」幾字間字距，把「進」擠到下一行，避免孤字。

• 配圖：《鴨的喜劇》最初1922年發表於《婦女雜誌》時，帶有配圖。

錄入價值所在

既然影印本自身有很大價值，那為何要費勁錄入文本呢？

最基礎的答案當然是方便檢索閱讀。即便是《吶喊》這種知名書籍，網上雖有很多公開文本，但維基文庫當前採用校對頁錄入的版本仍有優勢。下面簡單比較幾例。

• 北京魯迅博物館（北京新文化運動紀念館）資料查詢在線檢索系統比較權威，但內容質量遠不如維基文庫這版。魯博採用簡體字而非原文用字，而且很多地方按簡體習慣也算錯別字（我每次在維基文庫校對後，會把維基文庫轉換出的簡體與魯博版本比較，結果二者差異十有八九是魯博有誤）；《明天》等文章丟失分段；《社戲》等文章有「，，」這樣的明顯編輯錯誤。
• 魯迅圖書館（luxunlib.com）、中文馬克思主義文庫（marxists.org/chinese）等網站本身不權威，還無從查證，同時也存在不記原文用字的問題。
• 中國哲學書電子化計劃（ctext.org）可以對照影印圖像查證，不過網站設計比較質樸，瀏覽編輯體驗不如維基文庫，經常點幾個鏈接就會轉到某個超長頁面上不存在的anchor。

不過文本與圖像在檢索閱讀方面的難度差異在逐漸縮小。我簡單測試過，現在27B的小型視覺LLM/AI/agent輔以工具調用自己工作一周，就可以把一本影印PDF錄入成markdown文本，在注釋中標註頁碼，並設置標題級別。儘管存在大量混淆異體字等問題，但對檢索閱讀來說也差不多夠用了。何況現在還有若干專業框架，不少還開源。

所以錄入的價值恐怕到頭來還得追到人身上。就我個人而言，我最早來維基文庫的動機是想提高自己認讀繁體字的能力，不久發現自己閱讀豎排的能力也需練習（這也是我當時選擇校對近代書籍的原因，因為校對古代書籍更難）。現在我認為書籍發表的意義就在於被人閱讀，而校對錄入是讀者與書更深入交互的過程，此即價值所在。 David, but not Hilbert（留言） 2026年9月27日 (日) 16:42 (UTC)

贊。辛苦了。另想請教目前吶喊的首頁中《鴨的喜劇》是初版本，這似乎與其他篇目採用1938年全集本的做法有異，不知是出於何種考慮還是說後續會調整？ 銀色雪莉（留言） 2026年9月27日 (日) 23:19 (UTC)

我的處理策略大致如下。《鴨的喜劇》並非有意與其它篇目不同，只是自然出現了區別；我並無強烈理由反對調整，但我估計不會主動調整。

1. 前期先檢查既有頁面，根據wikitext注釋、編輯摘要等信息判斷是否有明確來源（查證不太困難的參考底本）。如有，在討論頁記錄{{Textinfo}}，並在主頁面標註edition=yes。
2. 校對前搜羅比較可用底本，主要校對質量更好且更接近最初發表的。《鴨的喜劇》最初發表於《婦女雜誌》，這份影印本的圖像比較清晰，甚至還有《魯迅全集》上沒有的配圖，於是選了《婦女雜誌》本；《風波》最初發表於《新青年》第八卷第一號Page/65起，但這份影印本的圖像壓縮處理得太厲害了，很多筆畫粘在一起，OCR效果一般，而且人讀起來很難受，就沒選《新青年》本。魯迅全集01_(1948).pdf整體質量還不錯，但偶有錯別字，某些頁數還會連錯一串標點符號，所以我並不是一上來就選它。
3. 校對完再看要替換既有頁面還是另建頁面。如果既有頁面有明確來源，且正是校對選用版本，那麼直接替換；如果既有頁面有其它明確來源，則另建頁面，並與既有頁面相互鏈接；如果既有頁面無明確來源，那麼也直接替換。《社戲》屬於第一種情況，《一件小事》屬於第二種情況，《吶喊》大部分篇目屬於第三種情況。（註：《一件小事》我當時是按第二種情況處理的，不過半年後Midleading把既有頁面替換成了魯迅全集01_(1948).pdf版本，這我就沒再管。）

David, but not Hilbert（留言） 2026年9月28日 (一) 03:52 (UTC)

我覺得此類情況，應考慮在文庫中保留兩個版本，一個單獨命名為《一件小事 (魯迅全集1948版)》，另一個（通行本）命名為《一件小事》。前者應為魯迅全集1948的忠實轉錄，後者可以編輯至符合現代出版規範，例如錯字改對、適當添加不同版本的校註記等。 -- PacmanD（留言） 2026年9月28日 (一) 04:43 (UTC)

使用校對頁錄入更符合可供查證的原則，並且還可以起到防止破壞的作用，推薦使用校對頁錄入。底本的選擇其實不必求古，最初發表的版本固然有其價值，後來再版的版本也有反映作者於再版時修改和修復錯字的價值。我同意當多個版本並存時，每個作品可以建立通行本頁面，但這不代表通行本頁面就需要放棄校對頁錄入可供查證的優點。很多匿名用戶編輯通行本頁面去掉{{另}}模板和調換此模板顯示的文字是因為那是教科書採用的版本。更合適的做法是通行本頁面也使用校對頁錄入一個年代較晚、有校注的版本，使{{另}}模板無論是內容還是此模板應該顯示的文字都可供查證，避免目前通行本頁面出現同一頁面不同{{另}}模板分別顯示兩個不同版本的矛盾和匿名用戶在{{另}}模板上編輯戰。 Midleading（留言） 2026年9月28日 (一) 11:52 (UTC)

2026年第40期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其他語言的翻譯版本。

近況更新 - 面向編輯者

• 對於使用桌面版和移動版網頁默認皮膚（分別為Vector 2022和Minerva）的用戶，當他們在搜索框輸入內容並看到搜索建議時，系統現在會提示這些建議是否源自頁面重定向。此前，如果搜索建議列表首位的條目與用戶的實際輸入不完全匹配，用戶可能會感到困惑。新增的重定向提示明確了這些建議並非隨機生成，而是與搜索內容相關的；這些建議頁面可能是指向用戶實際想要查找的最相關目標條目的重定向頁面。 [31]
• 使用移動版網頁瀏覽維基百科的未登錄用戶，將看到一個用於將條目保存至閱讀列表的書籤按鈕，以取代現有的監視星標按鈕。點擊該書籤按鈕時，系統會提示用戶登錄或創建賬戶，以便保存條目供日後閱讀。此前的一項實驗發現，與監視星標按鈕相比，書籤圖標促使未登錄用戶創建賬戶的可能性高出四倍。此次調整旨在鼓勵更多讀者註冊賬戶，並使用有助於保存及回訪內容的相關功能。 [32]
• 一項簡化用戶創建賬戶後即時體驗的實驗將於9月29日在西班牙語、阿拉伯語、英語和法語維基百科上啟動。該測試將探討移除現有歡迎問卷中的操作阻礙，是否有助於新用戶更輕鬆地了解後續步驟。實驗將持續至10月底。 [33]

• 產品與技術諮詢委員會現向社群徵集議題，以便與維基媒體基金會進行考量與探討。歡迎編輯和技術貢獻者在委員會的討論頁上添加議題。
• 本周晚些時候，社群將能夠配置編輯檢查與建議，使其在更多命名空間中顯示（例如Draft:命名空間）。歡迎提供反饋。
• 全域監視列表中的一個程序錯誤導致在維基共享資源上有未讀更改的用戶無法加載該頁面。開發人員正在修復此問題。在此期間，受影響的用戶可以按照相關幫助章節中描述的變通方法進行操作。
• 現已新增{{CATEGORYSORT:TIMESTAMP}}和{{CATEGORYSORT:RTIMESTAMP}}這兩個魔術字，可將分類的默認排序方式更改為基於歸類時間戳進行排序。 [34]
• 上週有20件由社群提交的工單得到解決。 例如，此前無法訪問維基百科的Wikistats問題現已修復。 [35]

近況更新 - 面向技術貢獻者

• 原定於9月23日進行的數據中心切換已推遲。在晝夜平分點演練期間發現的容量問題，導致無法將所有服務切換至另一數據中心。目前該流程已暫停，我們將優先排查並解決該問題，以確保能繼續為用戶提供可靠的服務。我們將另行安排新的演練。在此期間，所有流量和編輯操作均照常進行。
• 9月23日，一次電力中斷短暫影響了所有維基站點，導致閱讀和編輯模式出現間歇性問題。Gerrit也受到了影響。此事與數據中心切換工作的推遲無關。 [36]
• Produnto現已部署至mediawiki.org及部分印度語言維基站點。我們希望能聽到您對這款實驗性產品的反饋。Produnto允許用戶使用託管於維基媒體GitLab上的Lua模塊，從而簡化了各維基站點間Lua代碼的共享流程。用戶無需再將單個Lua模塊從一個維基站點逐一複製到另一個站點，而是可以輕鬆地在所有維基站點間共享代碼包。
• 本週軟體更新細節： MediaWiki

會議與活動

• 一場跨維基代碼協作研討會將於10月2日12:30 UTC在線舉行，旨在匯集南亞地區的技術貢獻者，讓他們了解Produnto並着手在印地語、旁遮普語、奧里亞語、泰盧固語和馬拉雅拉姆語維基百科上試用該工具。Produnto是一款用於將託管於GitLab上的Lua模塊部署到維基媒體各維基站點的軟件包管理器，近期已在部分試點維基站點上完成部署。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2026年9月28日 (一) 10:49 (UTC)

Wikidata Sitelink changes in Recent Changes and Watchlist

(Apologies for cross-posting in English, translating it will help spread the message)

Editors on group 1 wikis, including Wikiquote, Wikibooks, Wikiversity, Wikivoyage, and Wikisource, will no longer see notifications on Recent Changes and Watchlist when a link to another language version of a page is added, removed, or changed in its Wikidata item. This change will begin on October 5 at 07:00 UTC as a two-week trial to reduce high-volume, low-value notifications and make higher-value changes easier to identify. Editors who rely on these notifications should be aware of the change and can share feedback or concerns on the project or talk page.
Please reach out if you have any questions, thank you! -- Danny Benjafield (WMDE) (talk) sent via MediaWiki message delivery（留言） 2026年10月1日 (四) 12:43 (UTC)

以下內容以AI翻譯：

「最近更改」和「監視列表」中的維基數據站點鏈接更改

（很抱歉使用英文進行了跨版塊發布，將其翻譯為中文將有助於消息的傳播）

第1組維基項目（包括維基語錄、維基教科書、維基學院、維基導遊和維基文庫）的編者，當某個頁面的其他語言版本鏈接在其維基數據（Wikidata）項中被添加、移除或更改時，將不再在「最近更改」和「監視列表」中看到相關通知。此項更改將於10月5日 07:00 (UTC) / 15:00 (北京時間)開始，進行為期兩周的測試，旨在減少大量且低價值的通知，從而使高價值的更改更易於被發現。依賴這些通知的編者應留意此項更改，並可在項目頁面或討論頁上分享反饋或疑慮。

如有任何疑問，請與我們聯繫，謝謝！ Oscar Wai（留言） 2026年10月3日 (六) 06:10 (UTC)

庶吉士、庶起士

庶起士不存在。應該是「吉士」「起士」這樣的機械轉換導致的。文庫有很多「庶起士」，我一個人很難盡改，只能把翻過原文獻查證的手動改了幾筆。 - I am Davidzdh. 2026年10月2日 (五) 07:46 (UTC)

我已經確認至少四庫全書總目提要中所有的「庶起士」都應該是「庶吉士」，可批量替換。全庫中共有289處「庶起士」，以康熙朝實錄為最多，應皆可批量替換。不過，真正麻煩的是「吉士」也被部分替換成「起士」了，這些很難換回來。 PacmanD（留言） 2026年10月3日 (六) 05:56 (UTC)

「庶起士」已經全部改過來了。 PacmanD（留言） 2026年10月4日 (日) 16:29 (UTC)

《蜀山劍俠傳》是否可以收錄？

《蜀山劍俠傳》的作者w:還珠樓主於1961年逝世，此作品從1932年至1949年以連載形式發表，且無已知在美國發過表過的記錄。 據此我認為應可據中國大陸版權規則（+50年）予以收錄，收錄時使用 {{Not-PD-US-old}} 模板（參數 1961，1949）。這樣理解對嗎？ PacmanD（留言） 2026年10月2日 (五) 23:17 (UTC)

此書先在天津連載，跟着出單行本，按集出（可以理解比「回」高一級的章節標識），沒出完就轉到上海去出剩下的，出完了剩下的又把整個正傳在那兒再版了一次，發完了正傳還有後傳，後來別的地方出的還有別人偽托的後傳...總的來說，因為作者過世超過五十年，總體而言可以放心收錄，至於選用何種模板和參數要看版本具體情況，不是說就一定填1949。 銀色雪莉（留言） 2026年10月3日 (六) 07:52 (UTC)

申請在本 wiki 使用 AutoWikiBrowser 及JWB 以進行批量編輯

請將 PacmanD 添加進 Wikisource:AutoWikiBrowser/CheckPageJSON。 PacmanD（留言） 2026年10月5日 (一) 17:35 (UTC)

特提醒各用戶，授權申請將需要14天投票階段，請其他用戶發表意見。 Midleading（留言） 2026年10月9日 (五) 17:26 (UTC)

2026年第41期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其他語言的翻譯版本。

本週要聞

• 今年的社群願望清單流程已公布。這是在聽取社群反饋後制定的。計劃組建一個工作組，成員包括熟悉願望徵集流程及MediaWiki代碼庫的社群成員以及維基媒體基金會的工作人員。計劃於10月下旬或11月上旬開放新願望的提交，並預計在11月下旬完成初步篩選工作。欲了解更多信息，請參閱已公布的流程詳情。

近況更新 - 面向編輯者

• 使用可視化編輯器的編者在將文本粘貼到維基百科時，如果該文本很可能是最初從五種外部生成式AI聊天機器人之一複製而來的，將會看到一條警告。此功能被稱為LLM粘貼檢查，屬於一種可由社群配置的編輯檢查機制。該檢查通過識別複製內容中的HTML標記來運作，並不使用內容水印檢測技術。相關編輯還會被標記，以便巡查員進行更仔細的審查。該功能既能幫助新手添加符合維基百科方針的內容，也能讓經驗豐富的編輯更容易識別出存在問題的編輯。對於制定了關於LLM使用之本地方針的社群，可以調整提示文案及所鏈接的方針頁面。開發團隊致歉，因為該功能在推出時未預留時間進行多語言翻譯。
• 編者現在可以輕鬆地直接從iOS和Android應用訪問網頁版可視化編輯器。打開編輯器時，用戶可以選擇可視化編輯或源代碼編輯。若選擇可視化編輯，系統會將用戶引導至手機瀏覽器中的移動網頁界面；完成編輯後，頁面頂部的橫幅會提供返回應用的選項。這使得讀者能夠在隨手閱讀的同時，快速進行編輯貢獻。
• 使用維基百科Android和iOS應用的用戶，在連續使用兩周後，將會看到一次創建賬戶的提示。該提示意在說明擁有賬戶的益處，並幫助更多普通讀者轉變為會定期回訪應用的登錄用戶。 [37]
• 在group1 wiki（包括維基語錄、維基教科書、維基學院、維基導遊和維基文庫）上，當頁面對應的維基數據項中有關其他語言版本的鏈接被添加、移除或修改時，編者將不再在最近更改和監視列表中收到相關通知。此項變更將於協調世界時（UTC）10月5日07:00開始進行為期兩周的試運行，以減少高頻次但低價值的通知，從而更易於識別重要變更。依賴此類通知的編者可查閱項目頁面了解詳情，或在討論頁發表意見或提出疑慮。 [38]
• 上週有36件由社群提交的工單得到解決。 例如，此前已退出導師計劃的導師仍會被分配學員並收到提問，這一問題現已修復。現在，當導師退出計劃時，其學員會被重新分配。 [39]

近況更新 - 面向技術貢獻者

• 巴西維基媒體分會發布了其開發最佳實踐框架（ABPD）。這是一份面向開發技術工具與項目的員工、承包商及志願者的指南，涵蓋了項目生命周期、安全性、無障礙性、個人數據保護及負責任的人工智能使用等內容，並闡述了如何將維基媒體運動的通用準則調整以適應本地實際情況。他們鼓勵其他分會復用並根據自身需求調整該框架。欲了解更多信息，請閱讀Diff上的相關文章。
• Wikimedia API即將啟用一個新的標準基礎URL。該新標準路徑遵循{projectName}/api/模式，將作為現有REST API（例如：{projectName}/w/rest.php/）的替代訪問路徑。所有現有API均支持通過這兩種路徑進行調用，但新創建的API模塊將優先採用這一新結構。對於大多數用戶而言，此次變更不會導致現有功能中斷；針對現有端點的所有請求，原有的訪問路徑將繼續有效。不過，部分端點可能會在響應正文中返回符合新模式的URL。相關變更將首先在測試維基上部署，預計到10月底將覆蓋所有維基站點。 [40]
• 本週軟體更新細節： MediaWiki.

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

2026年10月5日 (一) 18:52 (UTC)

引入transclusion-check插件

目前英文文庫上有一個名為transclusion-check的插件，對編輯Index空間下的頁面大有用處。它包含下列模塊：

• en:MediaWiki:Gadget-transclusion-check.js
• en:MediaWiki:Gadget-transclusion-check.css
• en:Help:Gadget-transclusion-check（文檔）

提議在中文文庫上引入此插件，默認對所有用戶開啟（見User:PacmanD/common.js）。@Midleading： 🐠 _{formerly U.T.} 2026年10月8日 (四) 05:28 (UTC)

這個插件針對於英文維基文庫方針開發，而中文維基文庫允許嵌入「沒有文字」、「未校對」、「有問題」的頁面，目前沒有引入的必要。 Midleading（留言） 2026年10月8日 (四) 08:14 (UTC)

不過我提議引入有一個理由就是想用它檢查哪些page空間的頁面已經存在但是並沒有嵌入任何主空間頁面：這樣排查哪些頁面可以用基於掃描版的內容替換會更方便很多。 🐠 _{formerly U.T.} 2026年10月8日 (四) 08:43 (UTC)

中文維基文庫這樣的page頁面沒有多到需要每個用戶都檢查的程度。很多頁面要麼貢獻者不採用page頁面錄入，要麼在錄入page頁面的同時建立了主命名空間頁面，要麼因為種種原因故意不建立主命名空間頁面（Wikisource:寫字間/存檔/2014#長期破壞者「User:維基小霸王」回來了）。 Midleading（留言） 2026年10月8日 (四) 10:06 (UTC)

我個人還是非常主張採用page錄入：一套書有很多卷，很多時候光是一卷的篇幅也很長了；這樣一來頁面很容易大到難以編輯。 🐠 _{formerly U.T.} 2026年10月8日 (四) 12:35 (UTC)

「Page頁面沒有多到需要每個用戶都檢查的程度」，我覺得這或許不一定適合作為是否提供 Gadget 的主要判斷標準。像校對小工具、僻字小工具等也並非所有編輯與閱讀者都會主動使用；是否值得作為一個選項提供，或許可以更多考慮「是否存在明確的使用場景」，「引入後的維護、效能和介面成本是否合理」等因素。 PacmanD（留言） 2026年10月8日 (四) 12:51 (UTC)

提案人建議的是默認對所有用戶開啟，標準理應更加嚴格，要考慮是否真的是所有用戶都需要。如果僅僅是引入但不默認對所有用戶開啟，那麼也要修改插件，僅顯示嵌入狀態，不暗示頁面是否應該被嵌入，如已嵌入的頁面不加邊框，未嵌入的頁面邊框加粗而不是紅色邊框。 Midleading（留言） 2026年10月9日 (五) 08:49 (UTC)

也可以選擇不默認開啟，不過引入大抵沒什麼大問題？ 🐠 _{formerly U.T.} 2026年10月10日 (六) 05:21 (UTC)

我把這個英文版小工具修改了一下，現在僅檢查「未被嵌入」「被單個頁面嵌入」「被多個頁面嵌入」三種情況，並列出圖示。請@Midleading： 看一下，是否值得推廣並啟用給全站使用者。

--PacmanD（留言） 2026年10月11日 (日) 21:26 (UTC)

這不是把英文版小工具修改了一下，而是用AI重新生成了一個新的小工具，裡面有匪夷所思的行為，如t.title.indexOf( 'Main Page' ) !== 0 && t.title.indexOf( 'Wikisource:首页' ) !== 0檢查了嵌入頁面是不是以Main Page和Wikisource:首頁開頭，可是這兩個頁面根本沒有子頁面，怎麼會寫這個檢查呢。請在使用AI生成時主動聲明。用AI生成的代碼會需要更長時間的審查。 Midleading（留言） 2026年10月12日 (一) 13:38 (UTC)

英文版小工具不區分單個頁面和多個頁面嵌入，這裡進行了區分的用意是什麼，能不能不要過度添加邊框，在正常作品裡不要給所有頁面標籤統統加上邊框。 Midleading（留言） 2026年10月12日 (一) 13:45 (UTC)

Translation命名空間不使用頁面嵌入，這是因為Translation命名空間只收錄自行翻譯作品，如果此譯文已出版並有掃描件，應該收錄到主命名空間；自行翻譯作品不應該轉換成掃描件。 Midleading（留言） 2026年10月12日 (一) 13:57 (UTC)

感謝審查，意見很有幫助。

首先澄清一下：此工具不會自動改變頁碼表的外觀，只有使用者主動點擊「檢查」按鈕或右側連結後，才會加上標記；重新載入頁面亦恢復原狀。因此即使預設開啟，未點擊的讀者看到的仍是原來的頁碼表，僅「嵌入進度」後多加了一個按鈕，亦不會對文庫後端造成額外負擔。

回復區分單個頁面與多個頁面的問題：此功能目的是檢查同一個頁面是否被多個頁面重複 transclude。我認為大部分情況下一個 Page: 頁面只應被一個頁面 transclude，當被多於一個頁面 transclude 時，通常應該是跨越章節的「接縫」處，需要提起額外關注。至於邊框的渲染樣式，這屬於美學與風格上的細節，我沒有強烈立場，只要能區分兩種嵌入程度即可。邊框會按閣下的建議調整：已被單個頁面嵌入的不加標記，未被嵌入的用黑色邊框，已被多個頁面嵌入的上下綠色邊框標示。

關於 Main Page 的判斷：這是從英文版搬來的。英文文庫排除的是 Main Page 及其沙盒（避開每月校對模板產生的連結），中文站首頁不在主空間，故不必排除；已刪去「Wikisource:首頁」。統計範圍也按閣下的意見改為只看主空間，並且不再計入 Translation。（另外排除掉標題帶「全覽」等的頁面，這些頁面會造成「多次嵌入」的誤報。）

這個版本確實是以英文版的邏輯為基礎、藉助 AI 改寫的，特在此說明。JS 程式約 140 行，僅以 GET 方式讀取 API，不做任何寫入；已在至少 10 本不同書的 Index（含 0001 冊的紅鏈頁）上手動核對過結果，未發現問題。歡迎繼續指出其他問題或意見。 PacmanD（留言） 2026年10月12日 (一) 20:19 (UTC)

Page Proofread 首次開啟頁面不顯示圖像的問題已修復

向大家報告一個好消息：困擾維基文庫編輯校對工作的一個老問題，終於在最近的 MediaWiki 更新中得到修復了。

此前，使用 Page Proofread 開啟頁面時，經常會遇到「首次載入不顯示掃描圖像」的情況，必須手動 refresh 一次頁面才能正常顯示。這個問題已經存在很長時間，給日常校對帶來了相當的不便，如果你是該功能的重度使用者一定知道我在說什麼。

八月底，我向 Phabricator 提交了 T436575 這個問題，並提供了參考修復程式碼。有志願者在九月底完成了修復，相關程式碼已於 10 月 6 日隨 MediaWiki 1.47 版本合入，目前也已經在維基文庫生效。感謝參與修復的志願者！

今後首次開啟 Page: 頁面時，就不必再為了顯示圖像而額外加載一次了。 PacmanD（留言） 2026年10月9日 (五) 15:51 (UTC)

⚡️ —— Eric Liu_（留言） 2026年10月9日 (五) 16:15 (UTC)