维基文库:写字间 - 维基文库，自由的图书馆

维基文库:写字间 - 维基文库，自由的图书馆
跳转到内容
維基文庫，自由的圖書館
（重定向自
Wikisource:寫字間
TunnelESON在话题“
裁判文书的命名
”中的最新留言：
3天前
社區
写字间
存檔
姊妹计划
百科
大典
吴典
粤典
图册
语录
新闻
词义
教科书
课程
物种
导游
数据项
捷径
WS:S
WS:VP
請另頁
請求管理員幫助
，力求提高效率。
机器人
導入者
管理员
更改用戶名
請另頁申請。目前中文維基文库共有277名
活跃用户
，沒有行政員，暫不建議申請。
If you can't speak Chinese, we prefer you to comment at
the embassy
and our volunteers can help on translating your inputs.
維基文庫項目
维基文库是什么
维基文库与维基教科书
写字间
投票
版权信息
版權討論
删除讨论
移動請求
保護請求
請求管理員幫助
💭 話題
🙋 最新發言
(UTC+8)
版权讨论与删除讨论流程和模板问题
77
Pawsdt
2026-04-20
18:35
制订机器人方针
14
Viztor
2026-03-25
00:37
关于收录各类审判文书中当事人的姓名、出生日期、地址、身份证号，维基是否有相关的隐私政策规范应当做何种处理？
16
SuperGrey
2026-04-17
11:39
正文链接到求闻百科
内存溢出的猫
2026-04-18
18:26
修訂幫助:公有領域頁的幫助文字
23
Andayunxiao
2025-11-23
01:51
關於文言文（日韓越稱漢文）文獻錄入之提議
21
11
Viztor
2026-03-24
08:25
魯迅作品錄入
银色雪莉
2025-12-21
11:53
是否可收錄錢海岳《南明史》/《南明史稿》
Midleading
2025-10-14
13:03
ChineseTypography小工具
SuperGrey
2025-10-13
05:44
10
邀请参与生僻字webfont讨论
PexEric
2025-11-23
14:22
11
對於中國人民銀行的文件的收錄？（以及一些新手的問題）
18
银色雪莉
2025-12-04
00:26
12
就中国大陆司法文书收录信源问题的进一步讨论
银色雪莉
2025-11-25
14:22
13
更新社群首頁
10
Andayunxiao
2025-12-24
17:10
14
毛詩的異文情況
银色雪莉
2026-04-21
04:15
15
跨页的专名号是否需要特殊处理？
银色雪莉
2026-04-21
04:20
16
徵求意見：申請註冊機械人
SuperGrey
2025-12-05
10:40
17
法院文書
Andayunxiao
2025-12-22
00:44
18
中华人民共和国国家标准标题是否应该有标准编号
HCCB3947
2026-01-09
17:23
19
中華人民共和國的司法文件的版權、定義和範圍？
Teetrition
2025-12-09
00:57
20
如何处理表示分节的“空一行”？
Midleading
2026-03-20
21:54
21
義勇軍進行曲的著作權？
Midleading
2026-03-20
21:52
22
請求搬運模板
Andayunxiao
2026-01-08
19:00
23
关于药典的一个问题
银色雪莉
2026-01-07
22:14
24
合集問題
银色雪莉
2026-04-03
02:34
25
关于推荐性国标的版权
10
Jimmy0611
2026-01-11
15:57
26
Not-PD-US-old問題
银色雪莉
2026-04-03
02:36
27
关于国标为ISO/IEC采信标准的版权
31
银色雪莉
2026-04-05
02:13
28
這是什麼字
24
银色雪莉
2026-04-07
02:24
29
2026年第3期技術新聞
MediaWiki message delivery
2026-01-13
03:33
30
Thank You for Last Year – Join Wiki Loves Ramadan 2026
31
作者頁的樣式規範
Andayunxiao
2026-01-19
18:03
32
2026年第4期技術新聞
MediaWiki message delivery
2026-01-20
04:29
33
通用行為準則執行規範的年度審查
34
台灣分會2026年1月對話時間
MediaWiki message delivery
2026-01-25
08:28
35
2026年第5期技術新聞
MediaWiki message delivery
2026-01-27
05:17
36
作品页可选楷体及竖排显示
17
SuperGrey
2026-03-12
17:37
37
2026年第6期技術新聞
MediaWiki message delivery
2026-02-03
01:43
38
2026年第7期技術新聞
MediaWiki message delivery
2026-02-10
07:30
39
2026年第8期技術新聞
MediaWiki message delivery
2026-02-17
03:17
40
2026年第9期技術新聞
MediaWiki message delivery
2026-02-24
03:03
41
关于跨语言链接及Wikidata的疑问
Ericliu1912
2026-03-13
01:34
42
台灣分會2026年2月對話時間
MediaWiki message delivery
2026-02-26
06:25
43
2026年第10期技術新聞
MediaWiki message delivery
2026-03-03
01:51
44
《反共抗俄歌》、《中華民國陸軍軍歌》、《中華民國空軍軍歌》、《中華民國海軍軍歌》等是否進入了公有領域？
TunnelESON
2026-04-19
10:44
45
2026年第11期技術新聞
MediaWiki message delivery
2026-03-10
02:53
46
徵求意見：新命名空間「法律文書:」=「Case:」
35
11
SuperGrey
2026-04-19
18:25
47
异体字是否属于{{校}}的“讹字”范畴？
David, but not Hilbert
2026-03-31
00:12
48
是否對繁體模式同樣啟用異體字轉換為規範字？
Midleading
2026-04-17
18:48
49
鲁迅全集PDF页码显示异常
David, but not Hilbert
2026-03-21
18:36
50
2026年第12期技術新聞
MediaWiki message delivery
2026-03-17
20:09
51
异体字
银色雪莉
2026-03-22
19:04
52
2026年第13期技術新聞
MediaWiki message delivery
2026-03-24
00:51
53
关于 header, header2, header3 的问题
Midleading
2026-04-05
18:22
54
台灣分會2026年3月對話時間
MediaWiki message delivery
2026-03-28
14:28
55
2026年第14期技術新聞
MediaWiki message delivery
2026-03-31
03:25
56
裁判文书的命名
TunnelESON
2026-04-21
11:17
57
徵求意見：監管員、志工回覆團隊
SuperGrey
2026-04-03
07:20
58
Action Required: Update templates/modules for electoral maps (Migrating from P1846 to P14226)
MediaWiki message delivery
2026-04-04
01:11
59
新手的几个问题
MarkZhou08
2026-04-05
21:55
60
2026年第15期技術新聞
MediaWiki message delivery
2026-04-07
00:19
61
如何錄入這本書？
Liouxiao
2026-04-08
10:27
62
2026年第16期技術新聞
MediaWiki message delivery
2026-04-13
23:19
63
"貼是"是什麼意思？
Blahhmosh
2026-04-16
22:00
64
GB/T 47229-2026能录入吗
Zzhtju
2026-04-17
01:02
65
标明页码、保留原文献布局的Page版本和纯文字录入的版本，以何为主？
银色雪莉
2026-04-19
20:10
66
本Wiki的讨论页方针在哪里？
Pawsdt
2026-04-20
19:30
67
2026年第17期技術新聞
MediaWiki message delivery
2026-04-20
23:00
發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查
設定
是否有誤
版权讨论与删除讨论流程和模板问题
编辑
最新留言：
4天前
77条留言
9人参与讨论
本主題或以下段落文字，在討論結束後應存檔至
Wikisource talk:删除守则
在提删流程中加入“通知页面创建者”、copyvio和afd模板直链到提删件
编辑
读Zy26阁下的论述中关于新人引导的部分有感，提两个问题：
能否参考
w:Wikipedia:頁面存廢討論#提報過程
，将提删通知页面创建者一项（本地本就有
Template:AFDNote
）列为提删时的操作指引？
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名界面管理員。
dring
sim
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)
回复
关于删除讨论，我的意见是推荐各位提删人在提删时通知，但不应强制。因为在删除讨论这方面更有经验的维基百科同样没有强制要求；
关于版权讨论，我的意见是不推荐各位提删人在提删时通知，但也不反对。因为版权讨论有其特殊性，很多上传者就算参与讨论了，其实自己也说不清楚什么版权不版权的，实际能说清楚的就那么几个人，说白了还是由那么几个人的讨论结果来决定。提醒不提醒的重要性不大。
———
红渡厨
留言
贡献
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:版权讨论
中一般会讨论两周左右。尽管任何人都可以讨论提名，但只有社群认可的编辑的投票才有分量。
快速删除
捷径
WS:速删
维基文库的方针允许管理员在页面符合一个或以上的快速删除标准时，直接快速删除页面。如果不符合快速删除的标准，可以提交到
Wikisource:删除讨论
中。如果页面符合快速删除的标准，请配上{{
Sdelete
}}模板，但
不用
提交到
Wikisource:删除讨论
中。加了模板的页面会自动收入
Category:快速删除候选
分类，管理员就能看到了。加入模板时，请写明删除原因，用法：{{sdelete|删除原因}}。
提議條文
版权讨论/删除讨论
如果你怀疑一个页面
侵犯版权
，请加上
Template:Copyvio
并在
Wikisource:版权讨论
中提交。如果你认为一个页面因非版权原因不应该在维基文库上出现，但又不符合以下提到的任何快速删除的标准，请加上
Template:Afd
并在
Wikisource:删除讨论
中提交。在提交讨论的同时，请到该页面的创建者（创建者自行提删除外；另外，如需要时，亦可包括该页面的其他主要编者）的讨论页发出页面已被列入版权/删除讨论的通知（可使用
Template:CopyvioNotice
Template:AFDNote
）。
一般情况下，在
Wikisource:删除讨论
中会讨论一周左右，而在
Wikisource:版权讨论
中会讨论两周左右。尽管任何人都可以提报及参与讨论，但只有社群认可的言之有理的见解才有分量，管理员应基于由这样的见解所形成的共识执行结案处理（例如保留、删除、合并、重定向），并应回避对自己在版权/删除讨论中提报的页面执行结案处理。
快速删除
捷径
WS:速删
如果页面符合快速删除的标准，请加上
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)
回复
制订机器人方针
编辑
最新留言：
30天前
14条留言
7人参与讨论
现时
维基文库:机器人
除“机器人提议”和“机器人注册”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:维基百科:机器人方针
引入复核申请、活跃度要求等机制。
dring
sim
2025年7月3日 (四) 17:31 (UTC)
回复
通知其余几位使用机器人的用户：
Kcx36
Liouxiao
Midleading
維基小霸王
（请
維基小霸王
Wmr-bot
用户页添加{{
Bot
}}标注机器人操作者信息，谢谢！）
dring
sim
2025年7月3日 (四) 17:47 (UTC)
回复
可参考以下站点的活跃度要求：
中文维基百科
：机器人超过1年不活跃+一星期通知期
英文维基文库
：机器人或用户超过2年不活跃+30天通知期，须回应并运行机器人方可保留权限
日文维基文库
：机器人超过1年不活跃
全域机器人
：机器人超过1年未在允许使用全域机器人的wiki编辑
dring
sim
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都完全没有活动，我认为仍然要认定为闲置账号，此时虽有重新启用延迟，但继续保留权限的好处恐不足以抵消其风险。
dring
sim
2025年7月4日 (五) 04:57 (UTC)
回复
另外如果通知后仍长期未回应，则表明用户近期无意继续使用该权限，宜需要时再重新申请权限。
dring
sim
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)
回复
另外，如果机器人出现任务已结束、运行未批准的任务等情况，也应当能被申请复核。
dring
sim
2025年7月4日 (五) 05:28 (UTC)
回复
本人认为维基文库本来就属于相对不活跃的社群，出于减少行政任务的考量，对于已经批准过的任务应该无异议应当持续许可，机器人账号本身也并不包含任何普通用户所没有的权限，仅仅是用于区分普通编辑和机器人编辑而已，处于行政维护的考量可以关掉一批，但目前看来也并没有没有什么明显的益处。
Viztor
留言
2026年3月24日 (二) 00:09 (UTC)
回复
机器人账号本身也并不包含任何普通用户所没有的权限
”，机器人账户拥有多项权限，包括不受速率限制影响、自动巡查和绕过垃圾链接阻止列表等（见
Special:ListGroupRights
dring
sim
2026年3月24日 (二) 03:24 (UTC)
回复
有注意到，但我的看法不变，增加行政成本不见得有什么益处。
Viztor
留言
2026年3月24日 (二) 16:37 (UTC)
回复
关于收录各类审判文书中当事人的姓名、出生日期、地址、身份证号，维基是否有相关的隐私政策规范应当做何种处理？
编辑
最新留言：
7天前
16条留言
9人参与讨论
如：
杨某诉肖某性骚扰损害责任纠纷一审民事判决书
，是否算“侵犯個人隱私”，抑或“違反基金會隱私政策”？
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)
回复
使用条款
通用行为准则
禁止侵犯他人隐私。非公开个人信息应当移除（见
全域监督方针
）。如果认为这样做会与反映原貌的精神相冲突，可以选择全文删除。
dring
sim
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)
回复
正文链接到
求闻百科
编辑
最新留言：
6天前
6条留言
5人参与讨论
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)
回复
修訂
幫助:公有領域
頁的幫助文字
编辑
最新留言：
5个月前
23条留言
7人参与讨论
此頁和
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)
回复
關於文言文（日韓越稱漢文）文獻錄入之提議
编辑
最新留言：
1个月前
21条留言
11人参与讨论
近期想要根據
維基共享資源
錄入《
大日本野史
》，原文為日式訓點斷句的文言文（漢文）。想到之前遇到的諸多問題，這裡一起探討一下。
現今中文維基文庫所錄入的文言文（日韓越稱漢文）文獻均使用現代漢語標點，事實上不少文獻原文並無讀，添加句讀可以認為是二次創作，但無句讀會造成不少人的閲讀障礙。
然而若使用現代的格式來錄入，原本竪排版本的特定格式擡頭，避諱等可以反應古文原貌的特定格式統統丟失了。
另外大家可能忽略了一個事實，即日本也存在一種獨特的句讀來對文言文進行斷句（請參見
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)
回复
话说
吾妻鏡
的性质是什么？是否需要从本站删除？
dring
sim
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)
回复
魯迅作品錄入
编辑
最新留言：
4个月前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Talk:魯迅全集 (1938年)
Wikisource talk:繁简处理
。执行人：
银色雪莉
留言
2025年12月21日 (日) 03:53 (UTC)
回复
是否可收錄錢海岳《南明史》/《南明史稿》
编辑
最新留言：
6个月前
3条留言
3人参与讨论
錢海岳
（1901—1968）所著《
南明史
》，又名《南明史稿》，其一百卷本初本完成於1944年，原稿本不存，有
柳亞子
抄本存世。後
錢海岳
對初本進行修訂，約在1950年前擴充為一百二十卷本，此後十餘年進行修訂，有草稿與謄清稿共兩份。然1968年1月
錢海岳
逝世。其前九十六卷謄清稿與後二十四卷草稿尚存於世，2006年
中華書局
以一百二十卷本為底本出版了這套南明史稿的標點本，並名為《
南明史
》。目前所能見到的紙質本與電子掃描本均為該版。
以上是錢氏《
南明史
》的大體情況。本人計劃參照06年本，將本書錄入至文庫，另外該版存在一些標點、用字等編輯錯誤，亦可在維基文庫改之。
然在錄入之前，我個人不是很清楚此書的版權情況是否滿足錄入至文庫的要求，故先請教大家，咨詢一下諸位的看法。
Chain114514
留言
2025年10月12日 (日) 17:52 (UTC)
回复
題外話，如果允許錄入，本人可先行把本紀部分即時處理--
Tombus20032000
留言
2025年10月12日 (日) 19:05 (UTC)
回复
只允許錄入初稿（請標記
{{Not-PD-US-old|1968|2006}}
），因為經過後人編輯的部分仍然可能受整理版權保護（加標點不受版權保護，见{{
原文沒有標點
}}）。
Midleading
留言
2025年10月14日 (二) 05:03 (UTC)
回复
ChineseTypography小工具
编辑
最新留言：
6个月前
1条留言
1人参与讨论
突然想起來，不知道你們是否會對
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讨论
编辑
最新留言：
5个月前
7条留言
3人参与讨论
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)
回复
對於中國人民銀行的文件的收錄？（以及一些新手的問題）
编辑
最新留言：
4个月前
18条留言
7人参与讨论
本人最近看到
中國人民銀行
的一些歷史文件（主要是對於貨幣流通和廢止的官方公告）可能對維基百科上有許貢獻和作用，因此想要將其加入。由於不太熟悉維基文庫的方針的社群，因此希望諸位大佬可以指名一些意見，尤其是關於版權上、收錄方針和格式上提供協助——當然，最重要的是，我想要知道中國人民銀行的公告是否符合版權標準（跟官方文件一樣是公有領域作品）？（人行是作為
國務院組成部門
存在。）
此外，本人還想要了解下列問題：
有沒有PD的《
靜靜的頓河
》中文譯本？（該書按照蘇聯的版權要求已經進入公有領域）
如果不考慮延伸的影響和關注度的話，對於歌曲（尤其是國歌或官方頌歌等）的歌詞是否真的有必要在維基文庫刊登（尤其是如果有錄音存在的話）？
是否可以自己本人對版權狀態可行的情況下對非中文作品進行翻譯？
對於在法國戰役/蘇德戰爭中犧牲的法國/俄國人的版權延伸獎勵時長具體為何？
正式的外交通牒/非正式但是被公開的外交照會是否算做公務性質的文件（並適用於公有領域）？
FK8438
留言
2025年11月9日 (日) 14:12 (UTC)
回复
人行在历史上的功能是有变迁和调整的。一般而言，央行功能这个部分的文件大致上没有什么问题（但是人民币样式的图可能有问题，我不太熟图像的问题，抱歉），其他的可能要看看脉络。
也许我有所误会，但《静静的顿河》原文似乎未进入公有？
歌词也是文本。
Wikisource:收錄方針#翻譯
Wikisource:收錄方針#由翻译软件和生成式人工智能生成的译文
。注：“譯文以「已出版的」、位於公有領域的譯文優先”在本地的实践中等价于“只要有这样的译文，用户的自行翻译就不收了”。
c:Commons:Copyright_rules_by_territory
的国家和地区子页面对此可能有比较详细的说明。
w:伟大的卫国战争
的参战者就我所知应该是多给四年。
正式和普通照会都是算的。
一点浅见，供参考。
银色雪莉
留言
2025年11月11日 (二) 11:04 (UTC)
回复
银色雪莉
斗胆请问阁下所指“人行”究竟是指向中国人民银行还是指向人行道、人行交通等日常生活行为相关领域？
Liuxinyu970226
留言
2025年11月19日 (三) 13:47 (UTC)
回复
Liuxinyu970226
：经检视上下文，我有充分的信心相信我的所指应该是中国人民银行。
银色雪莉
留言
2025年11月19日 (三) 15:19 (UTC)
回复
这不是擾乱是什麼？--
魔琴
留言
2025年11月21日 (五) 04:18 (UTC)
回复
供参考：
c:User_talk:Teetrition#请阁下不要再将“中国人民银行”简称为“人行”了
Teetrition
留言
2025年11月21日 (五) 05:55 (UTC)
回复
另参考：
w:Special:diff/79502030
w:Special:diff/83979025
w:Special:diff/83979025
c:Special:diff/1001728896
我一直的观点就是，“人行”作为官方也曾使用过的通称，在上下文不会造成误解的情况下，当然可以使用，哪位用户如有误解也可以进一步解释说明、消除歧义。但Liuxinyu阁下确实给我一种“找茬”的感觉。官方规定的简称是什么，不影响维基百科收录使用广泛的通称。维基百科的命名规范又不是只有名从主人。
Teetrition
留言
2025年11月21日 (五) 06:10 (UTC)
回复
不要懷疑，他就是在找碴。以後直接忽略即可。——
Eric Liu
留言
2025年11月22日 (六) 14:55 (UTC)
回复
Ericliu1912
：若再有扰乱宜考虑封禁。
dring
sim
2025年11月22日 (六) 16:05 (UTC)
回复
L某把
国务院办公厅秘书局关于印发国务院机构简称的通知 (2023年)
搬出来就是在乱来。那里面写的很清楚是“供内部使用”。中国科学院
2018年
简称“科学院”，2023年简称“中国科学院”。但是你什么时候见过
中科院之声
改过名了？
dring
sim
2025年11月22日 (六) 16:05 (UTC)
回复
沈澄心
我愿就我曾经的某些粗鲁言论表示道歉，但我也有必要提醒阁下，美国的版权期限计算原则（甭管什么情况）是优先考虑出版日期而非作者逝世日期的，只有未出版的作品才会优先考虑逝世日期。
Liuxinyu970226
留言
2025年11月24日 (一) 01:08 (UTC)
回复
至于中科院一词，我只愿声明：台湾
中山科学研究院
也可以这样简称。
Liuxinyu970226
留言
2025年11月24日 (一) 01:13 (UTC)
回复
至少按照維基百科所說，中國人民銀行確實有通稱（俗稱）為「人行」的。9至於@
Liuxinyu970226
的誤解是不是找碴就還是不要爭論了。所以最後中國人民銀行的文件算不算
國務院組成部門
然後他們所有的作品可以因此視為不受版權保護（公有領域）？如果可以的話，我應該會把一些影響重要的歷史性文件加進來維基文庫。
FK8438
留言
2025年12月3日 (三) 01:40 (UTC)
回复
PS：肖洛霍夫1984年逝世，当时苏联身后+25，2010年到期，但俄罗斯1993年已经把这延伸到50年，这就到2034年了，再加上2004、2008两个时间节点，现在肖洛霍夫应该是2055年到期。（忘了，还得再+4）
银色雪莉
留言
2025年11月11日 (二) 13:04 (UTC)
回复
银色雪莉
这人是否
参与过二战
为俄国争光
，如果是确实得加4年，更复杂的情况（什么镇压平反，某三个通讯社老作品等各种云云）我也不愿细谈。
Liuxinyu970226
留言
2025年11月19日 (三) 14:23 (UTC)
回复
Liuxinyu970226
：肖洛霍夫在此期间是军事记者，发表了不少报道。按照俄罗斯联邦民法典（在这段期间创作——以人为准，不是作品——或参战），这就够了。肖洛霍夫没有被镇压也谈不上死后平反，静静的顿河不是通讯社员工在特定期间的个人公务作品，这些路子与此事无关。
银色雪莉
留言
2025年11月19日 (三) 15:18 (UTC)
回复
本人想知道有沒有具體的一些文件或者頁面可以介紹一下在
衛國戰爭
法國戰役
參與者的作品版權延伸情況。目前看到wikimedia有提及，但是不確定具體的時長是多久，還是說只有陣亡者才可以享有版權延伸？
FK8438
留言
2025年12月3日 (三) 01:43 (UTC)
回复
FK8438
c:Commons:Copyright_rules_by_territory/Russia
c:Commons:Copyright_rules_by_territory/France
应该已经有你需要的内容？你也可以去
WIPO
查各国法律。俄国不是只有阵亡者才能享有，是在那段期间创作或参战即可延长4年（1281条第5款），除非你在1993年1月1日以前就五十年到期（源于1993年俄最高苏维埃对1993年著作权法的溯及力规定）。法国的话，两次世界大战的部分是直接延期，没有什么战争参与者的先决条件（具体延长多少要看在哪个时段身故，两次大战的延期是可以叠加的
[4]
，L123-8、9），但如果是“为法国而死”（这是有
定义
的）的，那么就在承认前面的叠加的基础上，再延长三十年（L123-10）——这是往简单了说，对于版权延伸的争议详见上方法区著作权链接的介绍，不过总体而言，在维基应该都是往长了算——毕竟你又不会去打官司，但人家确实可以诉讼你。
银色雪莉
留言
2025年12月3日 (三) 16:26 (UTC)
回复
就中国大陆司法文书收录信源问题的进一步讨论
编辑
最新留言：
4个月前
8条留言
5人参与讨论
当前有
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)
回复
裁判文书网似乎有登录墙，能存档吗？
dring
sim
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)
回复
更新社群首頁
编辑
最新留言：
4个月前
10条留言
4人参与讨论
新的草稿在
此頁
（討論發起前
版本
）。
社群首頁服務編者，本地較中文維基百科相比，專案相關頁少而集中，因此社群首頁值得善用以成爲便捷入口。從前的設計因襲英文文庫，編者自行張貼任務和動態條目的設計，已經不合現實。提議是模仿維基百科的主題頁設計。未來擴充此頁時，内容穩定的可以在此頁直接加入；動態内容及複雜語法寫入到社群首頁的子頁，再嵌入社群首頁。
歡迎各樣提議及直接修改草稿。
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)
回复
新的協作頁
编辑
提議社群建立一個編者協作的專案頁。之前編者協作或對單個作品提議，只能在作品討論頁發生。其固然是設計本意，但亦有不足：
討論分散：缺少上下文和協作氛圍，不易找到，否則討論容易停滯。
不便維護錄入數據：中文作品錄入常需要整體考慮，維護跨校對頁的元數據，如異體字，樣式，内部連結等。這些數據可以在討論頁錄入，但限於
討論頁指引
，發言不適合協作更改；在編者頁錄入則不能體現協作之精神。例如，
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)
回复
毛詩
的異文情況
编辑
最新留言：
3天前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Talk:詩經
。执行人：
银色雪莉
留言
2026年4月20日 (一) 20:15 (UTC)
回复
跨页的专名号是否需要特殊处理？
编辑
最新留言：
3天前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Template_talk:專
Help talk:換頁
。执行人：
银色雪莉
留言
2026年4月20日 (一) 20:20 (UTC)
回复
徵求意見：申請註冊機械人
编辑
最新留言：
4个月前
1条留言
1人参与讨论
SuperGrey 正在申請註冊機械人，用於全自動匯入中國裁判文書網文書：
Wikisource:机器人 § User:SuperGrey-bot
，邀請您參與討論。副知先前中國裁判文書話題的參與者 @
银色雪莉
Chu Tse-tien
Teetrition
Midleading
Ericliu1912
沈澄心
Andayunxiao
SuperGrey
留言
2025年12月5日 (五) 02:40 (UTC)
回复
法院文書
编辑
最新留言：
4个月前
3条留言
3人参与讨论
目前有關分類極為混亂，如
此例
。——
Eric Liu
留言
2025年12月5日 (五) 11:21 (UTC)
回复
而且民國也有行政一審，有待兩岸用戶共同商榷。--
TunnelESON
留言
2025年12月6日 (六) 18:14 (UTC)
回复
是否將相關版權模板的自動分類功能先移除好些？以便使用 HotCat 和 Cat-a-lot 等小工具。
Andayunxiao
留言
2025年12月21日 (日) 16:44 (UTC)
回复
中华人民共和国国家标准标题是否应该有标准编号
编辑
最新留言：
3个月前
3条留言
3人参与讨论
Category:中华人民共和国国家标准
，大部分是有的，少数例如
信封 (1978年)
标点符号用法
没有。
GZWDer
留言
2025年12月6日 (六) 09:28 (UTC)
回复
应该有标准编号，除非原文真的缺少编号。--
TunnelESON
留言
2025年12月6日 (六) 18:12 (UTC)
回复
国家标准、部标准、行业标准编号一般在{{header}}模板中有所添加，目前是否有明文规定必须放在标题中？如果必须放，连字符是按照21世纪以来中国标准出版社的实体出版物中统一使用的“—”（U+2014），还是
Wikisource:标题格式
中草草书就的“-”（U+002D）？
HCCB3947
留言
2026年1月9日 (五) 09:23 (UTC)
回复
中華人民共和國的司法文件的版權、定義和範圍？
编辑
最新留言：
4个月前
2条留言
2人参与讨论
眾所週知，中華人民共和國的司法文件並不受版權保護；然而本人並不清楚司法文件的定義與範圍為何（什麼算是「司法文件」）。目前，判決書及公布的法案和法規是明確算是「司法文件」的，但是其他的作品則似乎沒有明確定義。
本人希望了解下列文件或作品是否應該被認為是「司法文件」（或是其他符合版權的文件）：
懲教機構（看守所、監獄）的文件（例如出獄證明）
人法釋法
（及其所衍生的公務演講）
庭審的材料（起訴書、證詞/證物）
控辯雙方於法庭上的任何文字或口頭發言/錄製的影音（無論是官方的庭審錄像、閉路電視或是違法錄製的）（通常不被公開，此處討論是洩漏的作品）
由最高人民法院所發表任何的「意見」或「指導意見」
逮捕令、傳票、調解書、扣押/充公物品的文件
一般情況下符合收錄標準，但是沒有公開（而被私人洩漏）的法庭文件
由治安機關（民警/警察）所發布的文件
上述但是由軍事法庭完成的文件或作品
調查性質的文件（屍檢報告/事故調查，大部分不公開）
由地方人大、街道、居民委員會所發布的公務文件或通知
關於上述款項的物品是否應該被收錄，懇請各位提供意見和討論，祝編安。
FK8438
留言
2025年12月8日 (一) 15:38 (UTC)
回复
首先提请阁下注意，立法、行政、司法性质的文件都不属于著作权保护范围，法案、法规属于立法性质的文件。以下仅针对阁下所举部分例子陈述我
个人的意见，不保证准确性和可靠性，不应被视为给出法律意见
，且如属于立法、行政性质，也不再特别指明了。“受保护”结论仅针对是否符合立法、行政、司法性质而谈，对于其他可能不受保护的理由，不在此特别考虑。
需要特别注意的是阁下很多举例范围都太大了，需要个案考察或细化概念。
惩教机构（看守所、监狱）的文件（例如出狱证明）：就“例如”而言，不受保护；
不知道阁下所指“人法释法”是什么，如果是指“人大释法”下全国人大及其常委会的法律解释，则不受保护。相关“公务演讲”需个案讨论；
庭审材料：检察院的起诉
（刑事）不受保护。起诉
（民事、行政）、刑事自诉状是原告方自己撰写的，受保护。证词/证物，是案件当事人、证人等出具的，受保护。
法庭发言及录音录像，受保护。但其中法院的当庭口头决定、裁定、宣判时的判决，不受保护（部分国家对法庭发言规定了合理使用规定，但中国无）；
由最高人民法院所发表任何的“意见”或“指导意见”，通常不受保护；
逮捕令、传票、调解书，不受保护。扣押/充公物品的文件，如指决定扣押文件的决定书，不受保护，如指被扣押的文件，受保护。
没有公开的法庭文件：“法庭文件”范围过大，无法一概而论；
由治安机关（民警/警察）所发布的文件：需要考察是否依职权作出；
军事法庭之军事性质不影响司法性质；
调查性质的文件：需要考察作出的主体（谁作出的文件？）和是否依职权及该职权性质；
由地方人大、街道、居民委员会所发布的公务文件或通知：地方人大可能不受保护，街道和居委会无法一概而论。
Teetrition
留言
2025年12月8日 (一) 16:57 (UTC)
回复
如何处理表示分节的“空一行”？
编辑
最新留言：
1个月前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Index talk:魯迅全集01_(1948).pdf
。执行人：
Midleading
留言
2026年3月20日 (五) 13:54 (UTC)
回复
義勇軍進行曲
的著作權？
编辑
最新留言：
1个月前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Talk:義勇軍進行曲
。执行人：
Midleading
留言
2026年3月20日 (五) 13:52 (UTC)
回复
請求搬運模板
编辑
最新留言：
3个月前
7条留言
4人参与讨论
這個模板我們能不能搬運到中文維基文庫？我有一些在韓國進入公有領域的作品想要搬運進來。
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月5日 (一) 18:55 (UTC)
回复
本站收录的作品都需要在美国进入公有领域，请直接添加
帮助:版权标记
中的标签，若作品只在韩国进入公有领域而未在美国进入公有领域，请不要收录。谢谢。
MarkZhou08
留言
2026年1月6日 (二) 13:49 (UTC)
回复
这不尽然，请留意
Template:Not-PD-US-old
等和
Wikisource:版权信息/全文
的相关消极容忍规定。详见
m:United_States_non-acceptance_of_the_rule_of_the_shorter_term/zh#来自维基媒体基金会的陈述
，本地现应处于不活跃执法状态。
银色雪莉
留言
2026年1月7日 (三) 08:06 (UTC)
回复
感谢提醒，我注意到了
Template:Not-PD-US-old
，能否将该类模板的诸如“在两岸四地、马来西亚以及新加坡”的字眼更改为适用于所有相同版权保护年限的表达。
MarkZhou08
留言
2026年1月7日 (三) 11:47 (UTC)
回复
我想这些叙述当时应该是基于本地用户以一般意义上的使用中文者居多而这些人而又多来自于（或可能受法律影响于）相关地区，所以做了这样的叙述（这仅是我个人的看法，不过与
Wikisource:版权信息/全文
注意事项第一条的思路在我看来可能是类似的）。至于此处私以为改不改都可，韩国2013年前+50，现在是+70，在当地过期了的话那么在前述这些司法区域也是过期的（一般而言），如果没有很大规模的例外情况，似可不改（这讲法可能有点笼统，若有不明确处则责任当在我）——因此前面Blahhmosh君提议引入模板其实是OK的，就如您所引用的
Help:版权标记
里头也有部分国别的版权标记一样，都是配合使用。（不过我不太懂模板引入这种技术活，就不班门弄斧了）。
银色雪莉
留言
2026年1月7日 (三) 14:21 (UTC)
回复
感谢指出，我已根据
c:Template:PD-South Korea
c:Template:PD-North Korea
及其他相关信息，引入模板
Template:PD-KR
Template:PD-DPRK
MarkZhou08
留言
2026年1月7日 (三) 15:13 (UTC)
回复
也可以將美國版權狀態合并到{{
Template:PD-KR
}}，就像共享資源上源模板做法。判斷美國版權是否過期需要知道來源地，邏輯也有些複雜。不如按國家各設模板，也符合字面意思。本地最多需要日、韓、越等幾個就夠了，因其他情形僅一種：原文非中文，來源地已過期但美國未過期，同時中文譯文已過期，這實在罕見。
Andayunxiao
留言
2026年1月8日 (四) 11:00 (UTC)
回复
关于药典的一个问题
编辑
最新留言：
3个月前
2条留言
2人参与讨论
药典普遍是一个国家界定药品的法律依据，所以各国药典都是公有领域的文件，这样理解对吗？
Jimmy0611
留言
2026年1月7日 (三) 12:43 (UTC)
回复
我建议还是就各司法区域具体的法律条文和实践去分析，这样会比较准确。中国大陆依据《
中华人民共和国药品管理法
》称
药品应当符合国家药品标准...国务院药品监督管理部门颁布的《中华人民共和国药典》和药品标准为国家药品标准。
药品必须符合国家药品标准...国务院卫生行政部门颁布的《中华人民共和国药典》和药品标准为国家药品标准。
（1984年等版）和各次药典颁布时相关部门颁发的指令性文件，大体上是如此的（说“大体”是因为药品管理法始发于1984年，在此以前的几版药典需要确认相关指令文件或条例——但从一些侧面表述看，应该问题不大，此处不展开，反正还没人录2333）。但另一方面，美国药典则并不自动在公有领域，见
[5]
。仅举两例，不展开。
银色雪莉
留言
2026年1月7日 (三) 14:14 (UTC)
回复
合集問題
编辑
最新留言：
21天前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Talk:勿山遺稿
。执行人：
银色雪莉
留言
2026年4月2日 (四) 18:34 (UTC)
回复
关于推荐性国标的版权
编辑
最新留言：
3个月前
10条留言
3人参与讨论
您好，我是新手，不太了解版权规则。我注意到PRC国标的版权申明中有：2018年1月1日以后发布且被相关法律、法规、规章引用的推荐性标准，也具有与该相关法律、法规、规章相对应的强制约束力，属于公有领域文件……这句话。我想问一下，被强制性国家标准引用的推荐性标准和行业标准也属于这一类吗。谢谢
Jimmy0611
留言
2026年1月9日 (五) 15:14 (UTC)
回复
欢迎您。请问是否能举些具体例子？
银色雪莉
留言
2026年1月9日 (五) 17:07 (UTC)
回复
比如GB 1350-2025 稻谷中规定检验方法按照GB/T 5490~5497，21719，35865执行。
Jimmy0611
留言
2026年1月10日 (六) 02:00 (UTC)
回复
另外GB 1350-2025 稻谷中还引用了GB/T 1354 大米，因为GB 1350中对精米的定义依赖GB/T 1354。还有想问一下维基文库对行标的版权有界定吗
Jimmy0611
留言
2026年1月10日 (六) 02:07 (UTC)
回复
引用推荐性国标的部分一般不作为强制性国标中的强制性条款，具体条款是否有强制力应该需要根据具体情况确定，不是所有的引用推荐性国标的部分都会让推荐性国标具有强制性。行标的版权情况与推荐性国标相同（通常是版权所有，不排除有可能部分文件有强制性）。
Midleading
留言
2026年1月10日 (六) 09:56 (UTC)
回复
谢谢，那我默认这种不算强制性了。不过我还是有些好奇这里的具体情况有无例子
Jimmy0611
留言
2026年1月10日 (六) 17:42 (UTC)
回复
GB 9706.1-2020 医用电气设备 第1部分：基本安全和基本性能的通用要求
在前言明确表示了本部分的全部技术内容为强制性，所以该文件引用的推荐性标准的技术内容可能也有强制性。
Midleading
留言
2026年1月11日 (日) 04:39 (UTC)
回复
谢谢，不过想提醒一下GB 9706.1-2020是ISO/IEC采标标准，ISO/IEC具有版权，这个适合在维基媒体上放吗……
Jimmy0611
留言
2026年1月11日 (日) 07:50 (UTC)
回复
那么我想单开一个楼讨论这个问题
Jimmy0611
留言
2026年1月11日 (日) 07:57 (UTC)
回复
Template:中华人民共和国行业标准
作了大方向上的说明，当然可能会有遗漏。
银色雪莉
留言
2026年1月11日 (日) 07:01 (UTC)
回复
Not-PD-US-old問題
编辑
最新留言：
21天前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Template talk:Not-PD-US-old
。执行人：
银色雪莉
留言
2026年4月2日 (四) 18:36 (UTC)
回复
关于国标为ISO/IEC采信标准的版权
编辑
最新留言：
19天前
31条留言
5人参与讨论
才发现
模板:中华人民共和国国家标准
中似乎没有讲国标中内含ISO/IEC标准的情况……
《采用国际标准管理办法》（2025年3月25日国家市场监督管理总局令第102号）：
ISO、IEC、ITU统称国际标准组织。采标国家标准的公开应当……遵守国际标准组织的版权政策。
ISO POCOSA 2017中说：
ISO的出版物及
国家采标标准
是具有独特性和原创性的作品，受瑞士版权保护。
又说：
监管者和立法者引用ISO的出版物及国家采标标准，
不意味着
ISO或ISO成员
丧失了版权
因此，即使强制性标准具有强制性和行政约束力，ISO依然对所有采信国标具有版权。
IEC和ITU的我没有查到……建议在
模板:中华人民共和国国家标准
补充针对ISO/IEC/ITU采信国标的版权。
Jimmy0611
留言
2026年1月11日 (日) 08:30 (UTC)
回复
我理解的是引用ISO/IEC标准和基于ISO/IEC标准制订国标，在著作权方面不等于把ISO/IEC标准翻译成中文。ISO/IEC标准英文版仍然版权所有，但是国标不是ISO/IEC标准，也不是其中文译文。国标只不过可以引用ISO/IEC标准，但在著作权方面不是衍生作品。
Midleading
留言
2026年1月11日 (日) 08:44 (UTC)
回复
ISO POCOSA 2017对国家采标标准的定义是：根据ISO指南21-1:2005或21-2:2005起草的，以ISO标准为基础而含有ISO知识产权或认可ISO标准的国家出版物，被采用的ISO标准视为国家规范性文件，与ISO的每处差异均已标注。
但源自ISO标准但与21-1:2005之定义不完全符合的国家出版物除外。
这个国家采标标准的定义是否对所有含有ISO内容的强制性国标都适用似乎是个问题……
Jimmy0611
留言
2026年1月11日 (日) 09:58 (UTC)
回复
我确实也不太懂版权规定，就是注意到这一点就提一下。因为ISO/IEC对版权的保护和处罚还是比较严的。另外，国标委国合处副处长种栗和法规处处长郭济环处长有一篇论文《2017版ISO版权政策对我国的影响与应对》或可参考
Jimmy0611
留言
2026年1月11日 (日) 10:17 (UTC)
回复
这种理解并不正确，以ISO/IEC标准化文件为基础的标准化文件是ISO/IEC标准化文件的衍生作品。见GB/T 1.2—2020《标准化工作导则 第2部分：以ISO/IEC标准化文件为基础的标准化文件起草规则》第6章“起草步骤”。
dring
sim
2026年1月13日 (二) 02:58 (UTC)
回复
其实前次相关更订早于
采用国际标准管理办法 (2025年)
的公布，虽然在讨论时，对于
国家标准管理办法 (2022年)
等提出
以国际标准为基础起草国家标准的，应当符合有关国际组织的版权政策。
等表述是有所留意的；但之所以没有涉及这一部分，并不单单是因为采标国家标准的问题，这包括几个原因：市场监管总局在标准版权的问题上的看法似乎与版权行政管理部门和司法机关方面有所区别，例如《国家标准管理办法》
国家标准及外文版依法受到版权保护，标准的批准发布主体享有标准的版权
，实际上会指向（不论何种）国家标准的版权均归于其批准发布主体——这就会牵涉到强制性国家标准的著作权问题，而那两份知名的版权局和最高法文件（自然不乏有人对其形式和效力有所争议，但这已经不是我们能控制的问题，何况人家判决长期引用呢）确定了一条，即“...强制性标准，是具有
法规
性质的技术性规范”——其实我们不是因强制性而说它在公有，而是强标基于其强制性被两份文件赋予“法规”的定性而不适用著作权法——这就挂上了著作权法第五条的班车，也就不好办了。司法实践就我所见的，都是就推荐性国家标准的性质的再确认（这一点上各方基本没有冲突）；强制性这边则甚少提及，除了延伸到本件的采标国家标准问题，标准全文公开系统现在对于IDT和MOD都称“由于涉及版权保护问题”只提供预览（PS：如果是推标则好像连预览都没有）。从本地实务来讲，鉴于目前也只涉及这一部分，如果基于此写一条但书，将这一部分采标国家标准中的强标移除应该是可行的；从法律观点看，在《答复》至今仍被援引于司法实践中的情况下，冲突可能是客观存在的。在此邀请@
Teetrition
和@
Patlabor Ingram
两位看看此件。
银色雪莉
留言
2026年1月13日 (二) 10:15 (UTC)
回复
根据POCOSA 2017，
监管者和立法者引用ISO的出版物及国家采标标准，
不意味着
ISO或ISO成员
丧失了版权
。在一国领土范围内之立法行政及司法机关有必要明确这一点，不要
错误的
将ISO出版物、国家采标标准及其草案和其他作品
等同于不受版权保护的官方文件
我的理解是，法规也属于这里所说的官方文件，也就是说，无论立法机关如何阐释采标标准的强制性，ISO对国家采标标准的版权仍不影响。所以我认为，这里的冲突并不存在，因为已经被ISO的版权规范消灭了。
Jimmy0611
留言
2026年1月13日 (二) 10:25 (UTC)
回复
我想这里很难用“消灭”去描述这种关系，因为ISO的版权规范——或者任何被签署的国际协议或公约之于各国并没有那种必然的“上位法”关系，都需要经过国内法化——正如您所引文指出的“在一国领土范围内之立法行政及司法机关有必要明确这一点”，这就是一个要求对此国内法化的表现——且在国内法化后的位阶、效力还需要根据具体情况乃至于实践情况来看待，也不是说国内法化完了就万事大吉了的。在下在上面提议“基于此写一条但书，将这一部分采标国家标准中的强标移除”就是基于实践情况：有没有冲突？那个条文就是冲突的，但它目前缺少直接的对碰，大家都在一个“不活跃的冲突”状态下，所以基于这种状态，把特定部分的强标移除是可行的，因为这没有破开圈子；至于国际组织能不能“消灭”这个冲突？它也没有这个权限——它可以在签加入协议时要求你如何如何，然后在你没有遵守的时候批评你、威胁你甚至驱逐你，但是它就是没有“消灭”（这体现一种直接的、排他的领导性——这东西只有有明确上下位关系的机关才有）这个冲突的权力。
银色雪莉
留言
2026年1月13日 (二) 10:46 (UTC)
回复
PS：而且，如在下前述，这个“矛盾”不仅仅发生在被国内法化的ISO规范和仍有效的对国标的版权的判定，而是一个更大的范围，即对于所有标准版权状态的判断问题——我想对于此，ISO的规范就显然更无能为力了。
银色雪莉
留言
2026年1月13日 (二) 10:53 (UTC)
回复
学习了。还是PRC的版权法规范太……模糊了。
Jimmy0611
留言
2026年1月13日 (二) 10:58 (UTC)
回复
NEQ也不提供下载。
dring
sim
2026年1月13日 (二) 11:47 (UTC)
回复
您是否能提供例子？我知道的一个NEQ恰好可以
[6]
，所以想进一步确认一下。
银色雪莉
留言
2026年1月13日 (二) 12:18 (UTC)
回复
GB 15213-2016 医用电子加速器 性能和试验方法
（IEC 60976:2007，NEQ）
GB/T 1.2-2020 标准化工作导则 第2部分：以ISO/IEC标准化文件为基础的标准化文件起草规则
（ISO/IEC Guide 21:2005，NEQ）
dring
sim
2026年1月13日 (二) 12:26 (UTC)
回复
不过根据《采用国际标准管理办法》和《标准化工作导则 第2部分》，NEQ不属于采标标准的……难道说国标委的人也不清楚版权规定，干脆一刀切？
Jimmy0611
留言
2026年1月13日 (二) 15:11 (UTC)
回复
但仍然可能属于“以国际标准为基础”的标准……
dring
sim
2026年1月14日 (三) 01:28 (UTC)
回复
那看来这大概就是要沿着衍生作品的路子捋下去了。ISO POCOSA 2017称保护“ISO出版物、国家采标标准及其草案和其他出版物”的版权，其中在“ISO出版物”的定义里提到了“包括ISO标准及其官方译文、衍生品”。大概而言，这是有个路子——算是吧。
银色雪莉
留言
2026年1月13日 (二) 18:56 (UTC)
回复
本话题已经沉潜了相当时间，从各位所提及和引用的各种实际情况来看，私以为作出一定的但书恐怕是有必要的，因此谨提案如下：
一、在
Template:中华人民共和国国家标准
中“...因而属于公有领域”后加注，内容为：
惟根据2022年《
国家标准管理办法
》第六条、2025年《
采用国际标准管理办法
》第十八条及第二十三条，采用国际标准或以国际标准为基础起草的国家标准，应当符合有关国际组织的版权政策。通常而言，可参考全国标准信息公共服务平台的相关版权状况说明。
二、在
Template:中华人民共和国行业标准
中“...因而属于公有领域”后加注，内容为：
惟根据2023年《
行业标准管理办法
》第十六条，采用国际标准或以国际标准为基础起草的行业标准，应当符合有关国际组织的版权政策。
以下做一点说明：
1、之所以加注，是因为下面分点的都是“可以录”的情况，那么这个不可以的情况就不宜混进去；而注在“公有领域”后面，也是一个提醒，注的显示形式，参见
Template:PD-PRC-CPC
——当然，如果各位觉得注不显眼，也可以另起一段，只要不与那些分点混淆，我想问题不大。
2、没有地方标准模板的修订案是因为《
地方标准管理办法
》没有这个条文，而像《
中华人民共和国标准化法
》等上位条文里又没有相关问题的内容，因此就先不加了。——其实我也还没有找到行业标准属于这种情况的具体例子，不过既然有条文，就且一写。
3、没有很具体地讲哪些国际组织以及其政策，是因为各条文也都往往有兜底（也就是不仅仅某些组织）的表达，且这种事情也都需要根据实际情况定夺——这也是我在后面加入“可参考相关标识”的原因，务求从实务出发；但行标我没有这样做，原因跟上面一样，我还没有找到行标的这种情况的例子，因而我也就暂时不写，在此请诸位如果了解相关事宜，还请指引，适合的话我们可以添补进去。
4、关于国标管理办法中对于国标版权的表述（此处主要指强制性），我留意到在其两年前的强制国标管理办法公布时曾有来自市监总局就此的
具备相关性（可能冲突）的说明
，我想相关问题，还不到定数的时候，因此就先不涉及了。
以上，也请该两话题下参加讨论的
Midleading
Jimmy0611
沈澄心
诸位并文库其他各位就此草案是否妥当给予意见及指正，在此表示感谢。
银色雪莉
留言
2026年1月28日 (三) 11:57 (UTC)
回复
Template:中华人民共和国国家标准
应该还可以加上2020年《
强制性国家标准管理办法
》第五十一条？
dring
sim
2026年2月1日 (日) 04:38 (UTC)
回复
以上引用的诸标准管理办法的法律层级，没有高于最高法有关解释。使强制性标准失去著作权的是其强制性，而非作者（或者说，{{
PD-EdictGov
}}。认为强制性采标（采标=采用国际标准的标准）受著作权保护，是将强制性归属于作者，违背强制性标准PD的逻辑。上述诸办法实施之后，是否已经有新发布的强制性采标？如果已经有的话，参照标准化管理机构对它们的著作权的处理方式，个人认为可接受；但如果目前还没有，个人认为不宜添加这句话。 --
达师
370
608
2026年1月31日 (六) 00:48 (UTC)
回复
Hat600
[7]
这个应该属于阁下问的诸办法实施之后新发布的强制性采标。从我自己的角度出发，我的观点其实跟之前没有差异，不过我也觉得很难忽视现今的这种情况——就像我说的，我们很难有机会等到关于“强制性国标著作权”的案子，所以这就是尴尴尬尬的。不知阁下以为如何为好？
银色雪莉
留言
2026年1月31日 (六) 09:33 (UTC)
回复
国家标准全文公开系统一直是不提供采标标准（含强制性）的下载的。
dring
sim
2026年2月1日 (日) 04:47 (UTC)
回复
银色雪莉
：个人认为这样描述比较妥当：强制性采标
可能
仍然具有著作权；本站的著作权问题从严考虑，按照不收录处理。至于为什么
可能
，这个具体理由有点多，从国际法到国内法，应该单写一页了，模板里链接到这里就行了。至于目前局面，围绕强制性采标的矛盾应该不小，除非国际组织对中国境内的事不闻不问，否则应该预期会有诉讼。 --
达师
370
608
2026年2月12日 (四) 14:34 (UTC)
回复
Hat600
：我倒是觉得当前这个情况不会有诉讼——在指定页面公开免费阅览和各版权政策不相冲突，所有的强标都可以在指定页面免费公开阅览。
银色雪莉
留言
2026年2月22日 (日) 06:46 (UTC)
回复
但是阅览界面是禁止下载的吧，维基文库能提供仅阅览不下载的服务吗
Jimmy0611
留言
2026年2月22日 (日) 09:33 (UTC)
回复
我谈论的只是达师君提及的“目前局面”那一句，貌似跟您关注的议题没有关联。
银色雪莉
留言
2026年2月22日 (日) 13:50 (UTC)
回复
话说ISO POCOSA 2017 4.2节中的“
监管者或立法者可能引用ISO出版物、国家采标标准及其草案和其他作品，但这并不意味着ISO或ISO成员丧失了其享有的版权
”应当如何理解？--
dring
sim
2026年2月1日 (日) 04:42 (UTC)
回复
另外《〈中华人民共和国标准化法〉释义》提到的“
推荐性标准被相关法律、法规、规章引用，则该推荐性标准具有相应的强制约束力，应当按法律、法规、规章的相关规定予以实施
”有什么具体的例子吗？
dring
sim
2026年2月1日 (日) 04:46 (UTC)
回复
例如《
中医药团体标准管理办法
》、《
个人信息保护认证实施规则
》和《
国家级公益林管理办法
》，“应当按照”、“应当符合”或“应当执行”。
银色雪莉
留言
2026年2月2日 (一) 02:20 (UTC)
回复
留意到上述讨论，虑及可能存在仍值得探讨的法理问题的同时实务问题又需要明确做法（且已有可参考的对象（即标准化管理机构的表述）），因此综合后提出修订的注释案，即在
Template:中华人民共和国国家标准
Template:中华人民共和国行业标准
中“...因而属于公有领域”后加注，内容为：
采用国际标准或以国际标准为基础起草的具有强制性的标准，可能仍然具有著作权；中文维基文库当前对此类情况按照不收录处理。
其中“可能仍然具有著作权”将链接至存档后的本话题。副知
Midleading
Jimmy0611
沈澄心
hat600
。--
银色雪莉
留言
2026年3月4日 (三) 09:45 (UTC)
回复
不宜直接链接至讨论，建议建一个专页。 --
达师
370
608
2026年4月4日 (六) 13:00 (UTC)
回复
Hat600
：我是打算把这个不存档在写字间而是直接存档至两个模板的对应讨论页，这样应该跟专页效果差不多？
银色雪莉
留言
2026年4月4日 (六) 18:13 (UTC)
回复
這是什麼字
编辑
最新留言：
17天前
24条留言
3人参与讨论
编辑
本主題或以下段落文字，在討論結束後應存檔至
Talk:勿山遺稿/跋
原文：「止此吾甚憾焉今將付剞劂西岡柳公遠重
之子」
原圖：
85頁
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月12日 (一) 03:50 (UTC)
回复
這個字是不是「序」？
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月12日 (一) 04:11 (UTC)
回复
我看也是「序」字——「止此吾甚憾焉？今將付剞劂，西岡
柳公遠重
序之。子其...」
Liouxiao
留言
2026年1月13日 (二) 02:54 (UTC)
回复
看來對的上了，這個文獻的序也是柳遠重冩的。
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月13日 (二) 03:55 (UTC)
回复
编辑
本主題或以下段落文字，在討論結束後應存檔至
Talk:七峯咸先生遺稿/卷之一
原文：「則三網八目
然扵心目明體適用之方皆知所止」
原圖：
[8]
page 12
[9]
page 14
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月16日 (五) 02:50 (UTC)
回复
Liouxiao
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月27日 (二) 22:27 (UTC)
回复
竊以爲是“尞”的異體字“㶫”或“𤈹”，通“瞭”，作“瞭然”解。此處寫作“上木下灬”(也可能是“上大下火”)懷疑有誤。
Liouxiao
留言
2026年1月28日 (三) 07:09 (UTC)
回复
感謝！
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年1月28日 (三) 16:21 (UTC)
回复
编辑
本主題或以下段落文字，在討論結束後應存檔至
Talk:玄谷集 (趙緯韓)/卷四
原文：「推。▒墨功名壯。弓刀事業恢。旌旗翻朔雪。鼓」
原圖：
[10]
[11]
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年2月16日 (一) 00:51 (UTC)
回复
Liouxiao
银色雪莉
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年2月16日 (一) 00:52 (UTC)
回复
“楮墨功名壯”——“楮墨”，表示“紙與墨”，如魯迅先生的《
漢文學史綱要
》提到太史公：“恨為弄臣，寄心楮墨”；猶如明代董越的《
朝鮮賦
》：“有楮墨以供唱酬”。
Liouxiao
留言
2026年2月18日 (三) 13:16 (UTC)
回复
另：卷十一“而不圖爲宿嫌之中傷。拈▒僞書中不近之說。枉加臣子無窮之惡。”——這裏看起來像“拈出”。
Liouxiao
留言
2026年2月18日 (三) 13:48 (UTC)
回复
感謝！！！
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年2月18日 (三) 14:31 (UTC)
回复
编辑
本主題或以下段落文字，在討論結束後應存檔至
Talk:泰齋先生文集/卷之二
我病久不出。或時能騎馬。騎馬將何歸。東隣有酒舎。
茅齋淨如掃。宴坐聊自樂。盡日人不來。知余愛寂寞。
結髮慕丘軻。㓛名視么麼。即令成謬悠。無計乃吾何。
茅屋依山址。彂門向水涯。愁多唯飲酒。年老懶看詩。
原文：
[12]
pg 67
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月2日 (四) 16:39 (UTC)
回复
没看懂...我打开对应的文件页码，有这首诗，所以阁下想问的具体是什么？--
银色雪莉
留言
2026年4月2日 (四) 18:31 (UTC)
回复
我的意思是，我雖然看得懂這首詩，我就是深怕我打錯了字，想讓你們幫我看看我有沒有打錯字。@
银色雪莉
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月2日 (四) 19:18 (UTC)
回复
Blahhmosh
：校了一下：
我病夂不出。或時能
馬。
馬將何
。東隣有酒舎。
茅齋淨如掃。宴坐聊自樂。盡日人不來。知余愛寂寞。
慕丘軻。㓛名視么麼。即令成謬悠。無計乃吾何。
茅屋依山址。彂門向水涯。愁多唯飲酒。年老懶看詩。
只有“彂”我不能确定，可能是。一点浅见，供参考。
银色雪莉
留言
2026年4月3日 (五) 05:50 (UTC)
回复
感謝！
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月3日 (五) 13:21 (UTC)
回复
“柴門向水涯”——没有“彂門”这种说法吧。前句“茅屋”正对“柴门”。
Liouxiao
留言
2026年4月6日 (一) 14:08 (UTC)
回复
完全赞成，之前我看不出来所以没有作改动，这确实是“柴”，经您提醒后我在
[13]
也看到类似的写法（“此”字中的“匕”拉长，做出类似半包围结构）。副知@
Blahhmosh
阁下。
银色雪莉
留言
2026年4月6日 (一) 18:20 (UTC)
回复
编辑
本主題或以下段落文字，在討論結束後應存檔至
Talk:伊溪先生續集/䟦
原文：「 編。擬續刊未果。▦公沒幾年乙」 (右邊第四行)
原圖：
[14]
pg 303
[15]
pg 103
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月5日 (日) 18:28 (UTC)
回复
银色雪莉
Liouxiao
這個字是不是「後」？
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月6日 (一) 13:06 (UTC)
回复
应该是。
Liouxiao
留言
2026年4月6日 (一) 14:02 (UTC)
回复
草书我不是很拿得准，抱歉。
银色雪莉
留言
2026年4月6日 (一) 18:24 (UTC)
回复
2026年第3期技術新聞
编辑
最新留言：
3个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
本週要聞
維基媒體基金會在
元維基
Diff
平台發布了有關明年度（2026年7月—2027年6月）年度計畫的若干指導性問題。這些問題聚焦於全球趨勢、更快更健康的實驗模式、強化新手支援、提升編輯者與高階權限者的能力、促進跨專案協作，以及擴展與留存讀者群。歡迎在
討論頁
提供意見與想法。
近況更新 - 面向編輯者
作為社群技術團隊目前在「
多重監視清單
」專案的工作之一，團隊將更新
EditWatchlist
特殊頁面的介面，向多重監視清單的實現邁出第一步。此外，為回應社群願望「
改進分頁/頁面導航
」，
特殊頁面的分頁顯示機制也將更新。
[16]
全域監視清單
是MediaWiki
擴充功能
，可查看不同維基的監視清單。現已更新，使其外觀更接近常規
監視清單
，例如檢視IP位址中臨時帳號的介面已最佳化（包含用戶連結重定向到貢獻頁面），將頁面標題加粗，及以新分頁開啟編輯摘要和標籤中的連結。
[17]
[18]
[19]
[20]
上週有
28件由社群提交的工單
得到解決。 例如，先前全域封鎖介面中沒有停用發送電子郵件的選項，現已修復此問題，將於1月13日當週啟用。
[21]
近況更新 - 面向技術貢獻者
VisualEditor引用工具
參考文獻預覽
現已支援「地圖」方式的文獻類型。
[22]
本週軟體更新細節：
MediaWiki
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年1月12日 (一) 19:33 (UTC)
回复
Thank You for Last Year – Join Wiki Loves Ramadan 2026
编辑
Dear Wikimedia communities,
We hope you are doing well, and we wish you a happy New Year.
Last year, we captured light. This year, we’ll capture legacy.
In 2025, communities around the world shared the glow of Ramadan nights and the warmth of collective iftars. In 2026,
Wiki Loves Ramadan
is expanding, bringing more stories, more cultures, and deeper global connections across Wikimedia projects.
We invite you to explore the
Wiki Loves Ramadan 2026
Meta page
to learn how you can participate and
your community.
Photo campaign on
Wikimedia Commons
If you have questions about the project, please refer to the FAQs:
Meta-Wiki
Wikimedia Commons
Early registration for updates is now open via the
Event page
Stay connected and receive updates:
Telegram channel
Mailing list
We look forward to collaborating with you and your community.
The Wiki Loves Ramadan 2026 Organizing Team
2026年1月16日 (五) 19:45 (UTC)
作者頁的樣式規範
编辑
最新留言：
3个月前
1条留言
1人参与讨论
提議文庫作者頁標題模板展示本作者的分類，如
分類:李白
。因作者分類由{{
Header
}}模板自動添加，讀者可即時獲取最新作品列表，而不是等到編者更新。這也可解決手機版視圖不展示分類的問題。
作者頁的樣式和細節，現在并不一致。提議討論規範樣式。幾點可能爭議不大的：
作者介紹文字置於標題模板的
|notes=
内，而不是正文。
介紹文字適用維基百科的版權要求，不應侵權。從維基百科複製的文字應指明來源。
所有作品應該以列表展示，一個作品一行；分組用章節或下級列表。
列出作品如果在文庫收錄了不同版本，應該至少列出版本頁，而不是只列出某個版本，也可在版本頁下面的二級列表列出所有版本。這點也適用導覽頁。
幾點本地樣式出入較多的：
作品名加不加書名號或引號？文庫多數作者頁不加書名號，但有沒有需要加的情況？
作品名後面的介紹文字（如有）使用何種標點和樣式？英文文庫的樣式一般不符合中文習慣，比如
就大總統職宣告
（1921年5月5日）——是否需要空格，逗號？中文還是英文括號？
志摩的詩
（1925），新月書店 ——出版商等更多資訊放在首個括號內，還是外面？
雜感 (魯迅)
，還是隱去消歧義後綴：
雜感
如果作者的作品收在非本人文集中，不獨立成子頁，應該怎樣標注？如
全唐詩
全唐文
作者。
合著作品，是否應列出其他作者？如
吴廷燮
清史稿
作者之一。
Andayunxiao
留言
2026年1月19日 (一) 10:03 (UTC)
回复
2026年第4期技術新聞
编辑
最新留言：
3个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
近況更新 - 面向編輯者
行動版
Special:Diff
頁面中的Tray已重新設計。Tray現預設為折疊狀態，並新增可復原當前檢視編輯的按鈕，讓行動版編輯者與審閱者能更容易執行操作，同時保持介面簡潔。
[23]
全域監視清單
讓使用者能夠在一個頁面檢視多個維基站點的監視清單。此
擴充功能
目前正持續改進，現在能自動判斷文字書寫方向（而非依賴硬編碼語言列表），並顯示更詳細的日誌操作描述。本週稍晚，將為頁面建立操作附上固定連結，並為每個項目元素加上專屬CSS類別。
[24]
[25]
[26]
[27]
上週有
32件由社群提交的工單
得到解決。 例如，先前在Vector 2022中，錨點連結的目標遭固定式頁首遮擋，現已修正此問題。
[28]
近況更新 - 面向技術貢獻者
2025年10月的棄用公告
所述，MediaWiki介面團隊將於1月26日當週起，逐步廢棄MediaWiki REST API中所有帶有結尾斜線的轉換端點。預計所有維基站點將於1月30日或之前完成變更部署。目前仍呼叫這些端點的API使用者，請盡快轉用不帶結尾斜線的版本。兩種端點變體皆可透過
REST沙盒
進行查找、比對與測試。如有疑問或遇到問題，請至Phabricator的
#MW-Interfaces-Team面板
提交工單。
Wikimedia REST API
的互動式參考文件已移動。先前透過
RESTBase
託管的API文件請求（如
）現已重新導向至
REST沙盒
維基媒體基金會維基數據平台團隊
（WDP）發布了
2026年1月電子報
。本期內容包括：舊版完整圖譜端點（full-graph endpoint）的退役；使用者代理（User-Agent）方針的修訂；關於Blazegraph遷移的每月諮詢時段；因應舊版端點關閉所引發迴歸問題的改善措施。歡迎
訂閱WDP電子報
本週軟體更新細節：
MediaWiki
會議與活動
2026年西北歐維基媒體黑客松
將於2026年3月13日至14日在荷蘭阿納姆舉行。報名自12月中旬開始，將於近期截止或額滿為止。這是一場為期兩天、以技術為導向的黑客松，將吸引當地維基人一同參與。期待與您相會！
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年1月19日 (一) 20:29 (UTC)
回复
通用行為準則執行規範的年度審查
编辑
這一則訊息是為了通知您對通用行為準則執行規範的年度審查已經開始了。您可以在2026年2月9日前提供更改的建議。這是年度審查的幾個行動中的第一步。
閱讀更多資訊並在元維基的頁面上找到某個通用行為準則並加入討論
通用行為準則協調委員會
（U4C）是一個以確保通用行為準則被公平且一致地實施的全域zh-cn:组;zh-tw:群組;。此次年度審查是由U4C計畫和實施的。對於更多有關U4C及其職責的資訊，
您可以回顧一下U4C的章節
請在任何合適的地方和您的社群中的其他成員分享這則訊息。
-- 和U4C一起合作，
Keegan (WMF)
讨论
2026年1月19日 (一) 21:02 (UTC)
台灣分會2026年1月對話時間
编辑
最新留言：
2个月前
1条留言
1人参与讨论
社群疑難雜症找協會！
台灣維基媒體協會
2026年1月的
對話時間
，訂於台灣時間
1/25 (日) 14:00
舉行，
參與連結為
協會到底在做什麼？如果你覺得協會存在感超低，有事都找不到人，把握這次的對話機會！這是一個定期舉辦的服務時段，由協會秘書長親自主持，有問題馬上解決。協會會分享目前進行中的專案與計劃，也邀請社群朋友分享想法、反映需求，彼此開講、一起討論。
本月討論主題將討論2026國際資訊最新動態，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！
--
MediaWiki message delivery
留言
2026年1月25日 (日) 00:28 (UTC)
回复
2026年第5期技術新聞
编辑
最新留言：
2个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
近況更新 - 面向編輯者
Wikimedia Foundation invites comments on
proposed future
of the
Product and Technology Advisory Council
until 28 February.
All users with registered accounts can now use passkeys for
two-factor authentication
(2FA). Passkeys are a simple way to log in without using a second device. They verify the user's identity using a fingerprint, face scan, or a PIN code. To set up a passkey, first set up a regular 2FA method. Currently, to log in with a passkey, users must also use a password. Later this quarter, passwordless login will allow users to log in with a single click and a passkey. Users with advanced rights will also be required to have 2FA enabled. This is part of the
Account Security
project.
Unregistered contributors on blocked IPs or blocked IP ranges can now interact on-wiki to appeal a block by creating a temporary account to appeal a block on the user talk page, unless the "prevent this user from editing their own talk page" is enabled. This solves the problem of logged-out users unable to use the default unblock process via user talk page.
[29]
上週有
20件由社群提交的工單
得到解決。 例如，雙重驗證（2FA）管理頁面上的雙重驗證方法說明已更新。現在說明文字更清晰易懂，使用者能更容易理解並運用相關功能。
[30]
近況更新 - 面向技術貢獻者
A new AbuseFilter variable,
account_type
, has been added to provide a reliable way to determine the account type being created in the
createaccount
and
autocreateaccount
actions. As part of this change, the variable
accountname
has been renamed to
account_name
, and
accountname
is now deprecated. Edit filter managers should update any filters that use hardcoded account type checks or the deprecated variable.
[31]
Image thumbnails that are requested in non-standard sizes, and using non-standard methods such as direct requests to
upload.wikimedia.org/…
will stop working in the near future. This change is to prevent ongoing external abuse by web-scrapers and bots. Some users with custom CSS/JS, Interface Admins who can fix gadgets and local skins, and Tool-authors, will need to update their code to use standard thumbnail sizes.
Details, search-links, and examples of how to fix them, are available in the task
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年1月26日 (一) 21:17 (UTC)
回复
作品页可选楷体及竖排显示
编辑
最新留言：
1个月前
17条留言
7人参与讨论
页码显示功能已从英文维基文库重新导入，更新了其功能。通过该小工具，从索引页面嵌入正文的作品页，现在还将获得楷体及竖排显示功能，用户可在左侧的显示选项中自行设置页面布局、页码显示方式、字体。请确保使用支持竖排显示的浏览器，在
四明人鑑
真誥
植物名實圖考 (道光刻本)
等任意嵌入索引页面的作品查看设置效果。建议更多作品采用从索引页面嵌入的方式录入，以自动获得该新功能。
Midleading
留言
2026年1月27日 (二) 10:02 (UTC)
回复
这个功能真棒！希望所有古文页面都能启用此功能。--
維基小霸王
留言
2026年1月28日 (三) 04:04 (UTC)
回复
常用排版模板現在是否可以使用
|class="ws-vertical"
跟進支持直排？本人新制了{{
直排標題
}}模板，可允許橫排下居中，單行直排下顯示預設幾種縮排或挪抬，可保留古籍原有樣式。見
沙盒
Andayunxiao
留言
2026年2月1日 (日) 12:56 (UTC)
回复
ws-vertical只在嵌入索引页面的页面中存在，一般作品和页面因为没有加载页码排版小工具，所以没有这个CSS类，不支持此功能。另外，把现有许多排版模板升级到横排、竖排通用CSS逻辑属性（*-inline-start之类的）时，也同时需要加-webkit、-moz等前缀版本，否则一些2020年之前的浏览器不支持。
Midleading
留言
2026年2月1日 (日) 16:16 (UTC)
回复
即將從
四部叢刊
頁面中
刪除直排模板
，改用此功能。
Midleading
留言
2026年2月3日 (二) 13:11 (UTC)
回复
也可暫時取消{{
Vtext2Start
}}的直排樣式留作以後再改，免得逐作品頁修改（看上去此模板的非四部叢刊頁用途不多，不過還請檢查）。
Andayunxiao
留言
2026年2月7日 (六) 08:10 (UTC)
回复
{{
Vtext2Start
}}使用超過40萬次，不可以直接刪除該模板功能。
Midleading
留言
2026年2月15日 (日) 03:22 (UTC)
回复
直排模板已全部刪除
Midleading
留言
2026年2月27日 (五) 15:29 (UTC)
回复
也提議增加動態樣式下小功能：選擇雙行注文（
Template:*
等）是否合并單行顯示，直排與橫排均適用。需要改動
Template:*
的樣式。
Andayunxiao
留言
2026年2月7日 (六) 08:18 (UTC)
回复
這個功能做的還行，不知是哪位用戶的開發成果。未來如能添加諸如調整字號、增加字體等文字相關樣式功能，使其進一步完善那就更佳。
字幕首發
留言
2026年2月16日 (一) 08:58 (UTC)
回复
調整字號在外观-文本裡。字體目前只有楷體。
英語維基文庫的四種佈局
已经导入中文維基文庫，不过看起来并不适合中文圖書，需要更換更適合中文圖書的佈局。請問各位希望中文維基文庫具有哪些佈局？
Midleading
留言
2026年2月19日 (四) 05:41 (UTC)
回复
我非新人，今次歸來乃因丙午歲至，予世界氣象不久將為之鉅變，故值此新春之際閒暇之餘摘錄文稿，以備引用。
至於佈局調整，僅就古文頁面而言，對正文部分尚無異議。但對抬頭標題，建議重設，初步設想可按經史子集四類分別設計四種不同樣式，以示直觀區別。
另Andayunxiao設計之新首頁於本年內能儘快導入。
字幕首發
留言
2026年2月21日 (六) 16:54 (UTC)
回复
在Vector-2022皮肤中，感觉那些选项更适合插入到皮肤自带的「外观」侧边栏。
魔琴
留言
2026年2月27日 (五) 16:17 (UTC)
回复
MediaWiki目前只能支持小工具把选项加入到所有皮肤都有的Sidebar里面
Midleading
留言
2026年2月27日 (五) 16:28 (UTC)
回复
可以用
mw.config.get('skin')
控制？
魔琴
留言
2026年2月27日 (五) 17:23 (UTC)
回复
可以參考
此處寫法
SuperGrey
留言
2026年3月12日 (四) 09:37 (UTC)
回复
還不錯呀！——
Eric Liu
留言
2026年2月28日 (六) 01:54 (UTC)
回复
2026年第6期技術新聞
编辑
最新留言：
2个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
近況更新 - 面向編輯者
「页面信息」功能（
範例
）現在自動包含目次。若您的維基站點有在本地建立
MediaWiki:Pageinfo-header
頁面，現可將它刪除。
[32]
上週有
21件由社群提交的工單
得到解決。 例如，之前視覺化編輯器會在連結顯示文字內添加粗體或斜體格式，導致wikitext複雜化，現已修正此問題。
[33]
近況更新 - 面向技術貢獻者
1月20日沒有生成XML轉儲。即日起，轉儲將改為每月生成一次。
[34]
MediaWiki介面團隊已停止支援
MediaWiki REST API
中所有帶有結尾斜線的轉換端點。目前仍呼叫這些端點的API使用者，請盡快轉用不帶結尾斜線的版本。如有疑問或遇到問題，請至Phabricator的
#MW-Interfaces-Team面板
提交工單。
本週軟體更新細節：
MediaWiki
本週要聞
提醒所有使用者，維基媒體基金會在
元維基
Diff
平台發布了有關明年度（2026年7月—2027年6月）年度計畫的若干指導性問題。這些問題聚焦於全球趨勢、更快更健康的實驗模式、強化新手支援、提升編輯者與高階權限者的能力、促進跨專案協作，以及擴展與留存讀者群。歡迎在
討論頁
提供意見與想法。
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年2月2日 (一) 17:43 (UTC)
回复
2026年第7期技術新聞
编辑
最新留言：
2个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
近況更新 - 面向編輯者
監視清單中存有大量頁面的編輯者現可用新功能「
監視清單標籤
來整理與篩選監視清單，幫助優化工作流程。透過新增自訂標籤（如：自己建立的頁面、需監控破壞行為的頁面、討論頁），使用者能更快速辨識需關注的編輯，降低認知負荷，並更有效率地應對。此功能讓監視清單更容易使用，對活躍編輯者尤為助益。（※＝Watchlist labels，勿與編輯標籤「tag」混淆）
Special:Contributions
推出新功能，可顯示很可能由同一人操作的
臨時帳號
，從而減少巡查耗時。當查核臨時帳號的貢獻時，具有臨時帳號IP位址存取權限的使用者，現在能查看其他相關臨時帳號的貢獻。此功能會在資料保留期間內，查詢與特定臨時帳號關聯的所有IP位址，並顯示曾使用這些IP位址的所有臨時帳號的貢獻紀錄。
了解更多
[35]
預覽wikitext編輯時，頂部顯示的提醒框（「這只是預覽……」）背景色已由警告黃底改為中性灰底。此變更有助於區分預覽提示與實際警告訊息（如編輯衝突或重定向目標錯誤），後者現改以獨立的警告框或錯誤框呈現。
[36]
全域監視清單
讓使用者能夠在一個頁面檢視多個維基站點的監視清單。此
擴充功能
目前正持續改進，現已完整支援多個Wikibase站點，例如同時涵蓋
維基數據
測試版維基數據
。此外，已修正右至左（RTL）文字顯示問題。
[37]
[38]
因缺乏彈性且難以本地化，wikitext中為ISBN、RFC、PMID編號自動生成連結的「魔術連結」功能
已於2021年棄用
。RFC與PMID魔術連結能以等效外部連結取代（部分維基站點已完成替換），但ISBN魔術連結通常需要模板才能完成替換。現已推出
內建解析器函數
{{#isbn}}
，可取代ISBN魔術連結的基本功能，方便完成替換作業。
[39]
已新建兩個維基：
卡捷語
维基百科 (
w:kaj:
[40]
Nawat語
维基百科 (
w:ppl:
[41]
上週有
23件由社群提交的工單
得到解決。
近況更新 - 面向技術貢獻者
新增了一個全域使用者群組：
局域机器人
。此群組將由軟體內部使用，允許社群機器人繞過針對惡意
網頁抓取
工具所施加的速率限制。凡在至少一個維基媒體站點獲准為機器人的帳號，將自動加入此群組。此舉不會改變機器人原有的使用者權限。
[42]
本週軟體更新細節：
MediaWiki
會議與活動
2026年春季MediaWiki使用者與開發者大會
將於3月25日至27日在美國鹽湖城舉行。本活動由第三方MediaWiki社群主辦，並面向該社群。您可以提出議程並報名參加。
[43]
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年2月9日 (一) 23:30 (UTC)
回复
2026年第8期技術新聞
编辑
最新留言：
2个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
本週要聞
SRE
團隊
將對維基媒體托管的
Etherpad
實例進行清理作業。Etherpad是一款網頁式即時協作文件編輯器。所有Pad文件將於2026年4月30日後永久刪除，若屆時仍有進行中的遷移專案，團隊可視個別情況重新評估日期。資料刪除後無法復原，請務必為希望保留的內容建立本地備份。本次清理旨在縮減資料庫規模並降低基礎設施佔用資源。Etherpad將持續支援即時協作功能，但請勿將其視為長期儲存服務。未來可能再次進行清理作業，屆時恕不另行通知。
[44]
近況更新 - 面向編輯者
資訊檢索團隊將
在Android版維基百科APP展開實驗
，測試能夠同時處理語義查詢與關鍵字查詢的混合搜尋功能。這項改進將使讀者更容易直接在維基百科上找到所需內容。實驗將於2月下旬首先在希臘語維基百科上線，隨後於3月在英語、法語、葡萄牙語推出。更多詳情請參閱
Diff文章
[45]
The Reader Growth team will run
an experiment
for mobile web users, that adds a table of contents and automatically expands all article sections, to learn more about navigation issues they face. The test will be available on Arabic, Chinese, English, French, Indonesian, and Vietnamese Wikipedias.
先前，網站公告（
MediaWiki:Sitenotice
MediaWiki:Anonnotice
）只會在桌面版顯示。現在，這些公告將顯示在所有平台。行動版網頁使用者將能看見這些公告並獲取相關資訊。管理員應準備測試並修正網站公告在行動裝置上的顯示情況，以避免影響條目閱讀體驗。若需停用此變更，介面管理員可在
MediaWiki:Minerva.css
中加入樣式規則：
#siteNotice { display: none; }
[46]
[47]
上週有
19件由社群提交的工單
得到解決。 例如，先前在
Special:RecentChanges
中，點擊篩選器的「隐藏」會導致「查看……之后的新更改」按鈕消失，但該按鈕理應保持可見狀態。現已修正此問題，按鈕功能恢復正常運作。
[48]
近況更新 - 面向技術貢獻者
New documentation is now available to help editors debug on-site search features. It supports troubleshooting when pages do not appear in results, when ranking seems unexpected, and when you need to inspect what content is being indexed, helping make search behavior easier to understand and analyze.
[49]
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年2月16日 (一) 19:17 (UTC)
回复
2026年第9期技術新聞
编辑
最新留言：
2个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
本週要聞
参考文献检查
功能已在英语维基百科部署完成，标志着该功能已在所有维基百科语言版本推广完成。该功能会在新用户发布内容前提示他们添加引用，有助于减少因缺乏引用而被撤销的情况，并提高条目的可验证性。在A/B测试中，该功能效果显著：A/B测试显示效果显著：使用该功能的新用户在桌面端添加引用的比例增加约2.2倍，在移动端则增加约17.5倍。
[50]
近況更新 - 面向編輯者
维基百科已撤销部署
跨wiki排序扩展
，该扩展曾提供
跨wiki链接排序
功能。因此，之前在“非紧凑模式（完整列表）”下进行跨维基链接排序的编辑者，他们的链接顺序将发生变化。今后链接将按语言代码的字母顺序显示。
[51]
本週稍晚，使用移动版可视化编辑器按段编辑页面的用户将看到新增的“编辑整页”按钮。点击后可切换到整页编辑，便于在修改内容跨段时一次性编辑整篇条目。当需要修改的内容超出当前段落时，该功能可省去反复打开其他段落的步骤，使用更方便。
[52]
[53]
读者体验团队
正在邀请编辑者并根据他们在桌面端和移动端的使用情况，评估深色模式是否仍需在各自站点维持“测试版”状态。如果认为该功能已经成熟，编辑者可以更新
MediaWiki:skin-theme-description
MediaWiki:Vector-night-mode-beta-tag
中的介面提示，说明深色模式已可正式使用，不再处于测试阶段。
改进后的
活动标签页
现已向维基百科iOS应用程序（7.9.0及以上版本）的所有用户开放。A/B测试显示，启用该功能的用户注册率显著提高；因此我们已向所有用户全面推送该功能，并同时推出若干更新。活动标签页现在会在时间轴中显示用户编辑过的条目，提供编辑影响洞察（例如贡献次数与条目浏览趋势），并支持自定义选项以优化应用内体验。
上週有
21件由社群提交的工單
得到解決。 例如，先前
讨论工具（DiscussionTools）
在移动设备上无法正常使用，功能现已全面恢复。
[54]
近況更新 - 面向技術貢獻者
全域监视列表
可在同一页面显示来自多个维基站点的监视列表。此
扩展
目前正持續改進，最新增加了
新钩子
ext.globalwatchlist.rebuild
，该钩子会在每次重建监视列表后触发。这使您能在该页面运行小工具和用户脚本。
[55]
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年2月23日 (一) 19:03 (UTC)
回复
关于跨语言链接及Wikidata的疑问
编辑
最新留言：
1个月前
6条留言
4人参与讨论
我观察到《
端午節
》页面右上角显示除了zh版，还有ja、en两个语言的版本；可是该页源代码最后只标注了[[ja:端午節]]，并无en。那么跨语言链接是否只取决于
Wikidata
，而与文库源代码无关？源代码最后的[[ja:端午節]]是否应当删除？
此外，
《端午節》Wikidata 页面
上的en版有个proofread小徽章，而其它版本没有。逐一访问，会发现目前只有en版带PDF逐页对照。然而我们zh版《
阿Q正传
》也带PDF逐页对照，
相应 Wikidata 页面
却并无任何徽章。如果我尝试添加，会提示无权限（详见以下报错）。请问这种徽章会在维基文库某个地方显示吗？中文维基文库是否会定期添加徽章？若会显示但尚不会定期添加，是否有可能建立某种机制，比如每年集中更新一次？
Could not save due to an error.
The save has failed.
Warning:
You are trying to add/remove badges to this item. At local Wikipedias adding or removing badges are done by consensus. Saving this edit was blocked and should be done only by administrators or trusted users. If you think you are correct, please
contact an administrator
David, but not Hilbert
留言
2026年2月24日 (二) 16:25 (UTC)
回复
David, but not Hilbert
看了一下，維基數據項目三個語言版本都有了，故已去除手動連結。至於徽章，我也很好奇，社群可以討論看看。——
Eric Liu
留言
2026年2月24日 (二) 17:18 (UTC)
回复
關於新增徽章的部份，閣下在Wikidata上必須至少有自動確認使用者權限才能新增，不過我看閣下編輯數離自動確認使用者的門檻不遠了，因此這應該不是太大的問題；至於要將文庫上的徽章狀態同步到Wikidata上，我想在Wikidata上做個機器人來掃描中文維基文庫可能會比較簡單？--
S8321414
留言
2026年2月25日 (三) 03:50 (UTC)
回复
感谢二位！关于新增徽章权限，原来各子站会各自判断
自动确认用户
，并不在全域共享，那我知道是怎么回事了。至于同步徽章状态，如果基本没显示，那我觉得并不是优先事项。
David, but not Hilbert
留言
2026年2月26日 (四) 09:26 (UTC)
回复
现在包括中文在内的各维基文库都没有机器人同步徽章状态，直接手动更新徽章吧（需要在维基数据编辑50次晋升自动确认用户）。
Midleading
留言
2026年2月26日 (四) 09:33 (UTC)
回复
隨手更新吧（ ——
Eric Liu
留言
2026年3月12日 (四) 17:34 (UTC)
回复
台灣分會2026年2月對話時間
编辑
最新留言：
1个月前
1条留言
1人参与讨论
社群疑難雜症找協會！
台灣維基媒體協會
2026年2月的
對話時間
，訂於台灣時間
2/26 (四) 19:00
舉行，
參與連結為
協會到底在做什麼？如果你覺得協會存在感超低，有事都找不到人，把握這次的對話機會！這是一個定期舉辦的服務時段，由協會秘書長親自主持，有問題馬上解決。協會會分享目前進行中的專案與計劃，也邀請社群朋友分享想法、反映需求，彼此開講、一起討論。
本月討論主題將討論2026年未來規劃與展望，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！
--
MediaWiki message delivery
留言
2026年2月25日 (三) 22:25 (UTC)
回复
2026年第10期技術新聞
编辑
最新留言：
1个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻译版本
本週要聞
維基百科25週年
生日模式
現已在中文、布列塔尼語、印尼語、西西里語、西班牙語、貝塔維語、法語、科隆達羅語、英語、泰語、馬都拉語、捷克語、荷蘭語、越南語、義大利語及盧森堡語維基百科上線！此限時活動為慶祝維基百科成立25週年，特別推出生日吉祥物「拼圖球寶寶」（Baby Globe）。啟用生日模式後，拼圖球寶寶將出現在
約2500篇條目
中，靜待讀者發現。要在本地維基啟用生日模式，管理員可在社群取得共識後啟用此功能，亦可在
社群配置
功能中進行自訂。
近況更新 - 面向編輯者
子引用
功能已在瑞典語、波蘭語維基百科及
其他數個維基站點
推出，此新功能可在重複使用參考資料時能修改部分細節。您可在上述站點、測試維基或
Beta維基
試用此功能
。首個試行站點——德語維基百科的實施經驗已彙整成
報告
發布。若您的社群
有意參與試行
，請聯繫德國維基媒體協會團隊。
本週，
貼上檢查
（Paste check）功能將在所有維基百科站點上線。此功能針對使用視覺化編輯器的新編者，當他們將由他人撰寫的內容貼入條目時，此功能會提示其思考此舉是否可能侵犯著作權。凡觸發此功能的編輯內容，系統皆會標上
標籤
供其他編者審核。本地管理員可透過
Special:EditChecks
頁面設定此功能的各項參數。橫跨22個維基站點的
研究
顯示，相較於對照組，貼上檢查功能使編輯回退率減少了18%。誠摯邀請翻譯者
協助本地化
此功能及相關功能。
閱讀體驗團隊
將為所有行動版使用者統一右上角的使用者選單，使其更貼近桌面版的使用體驗。目前此選單僅對啟用行動版進階模式（AMC）的使用者顯示。本次變更後，未啟用AMC的使用者將有若干按鈕從左側選單移至右上角。此變更旨在改善UI，預計於3月9日推出。
[56]
自3月2日當週起，當帳號新增、移除或變更電子郵件地址時，系統發送的通知郵件將由原先的純文字格式，更改為更美觀清晰的HTML格式電子郵件。
[57]
目前，每位使用者的通知匣最多可儲存2000筆紀錄，可追溯至2013年該功能推出之初。這將調整為僅儲存近五年內的通知記錄，但數量上限提升至1萬筆。此變更有助於基礎設施的長期穩定運行，並避免近期通知過早消失。
[58]
全域監視清單
可在同一頁面顯示來自多個維基站點的監視清單。此
擴充功能
目前正持續改進，最新改進了維基數據項目標籤的使用體驗。現在，全域監視清單為維基數據等站點啟用了
語言備援系統
，若維基數據項目缺少使用者檢視語言的標籤，將以備援語言或使用者偏好的維基數據語言顯示這些標籤（若提供
uselang=
URL參數則以該語言為檢視語言）。
[59]
[60]
維基百科Android團隊已在希臘語維基百科啟動
混合搜尋
功能的Beta測試。混合搜尋功能可同時處理語義查詢與關鍵字查詢，讓讀者能更容易直接在維基百科上找到所需內容。
出於安全考量，位於特定使用者群組的使用者將
必須啟用雙重認証
（2FA）。當前，只有在使用相關權限時才會檢查並要求啟用2FA，而單純位於相關使用者群組內則不需要。考量到即便如此依然可能存在安全漏洞，基金會
自三月起將逐步改變現狀
。處於這些使用者群組的使用者只要還擁有相關使用者群組身分便不能從自己的帳號中移除全部的2FA方式，同時有權者亦無法將沒有啟用2FA的使用者加入到這些群組中。只要帳號中至少還留有一個2FA方式，這些使用者依然可以自由添加和移除額外的2FA方式。目前決定以下使用者群組將受到新規則的限制：CentralNotice administrators、使用者查核員、介面管理員、監督員、Wikidata staff、Wikifunctions staff、WMF Office IT和WMF Trust & Safety。其他使用者不受影響。關於新規定生效的時程詳見連結的工單。
[61]
上週有
27件由社群提交的工單
得到解決。 例如，先前有個問題導致使用者無法在
Wikibase.cloud
建立實例，現已修正此問題。
[62]
近況更新 - 面向技術貢獻者
為確保
基礎設施的合理使用
，維基媒體基金會將於未來一個月內對所有API全面實施速率限制。3月初，針對並非來自Toolforge/
WMCS且未經身份驗證的請求，以及透過網頁瀏覽器發出的API請求，將實施更嚴格的流量限制。4月起，已驗證流量將適用較高限額。此限額刻意設定得盡可能高，以盡量減少對社群的影響。目前在Toolforge/
WMCS運行的機器人和擁有站內機器人權限的機器人應不受影響。不過，我們建議所有開發者遵循最新的最佳實踐。詳情請參閱
維基媒體API/速率限制
。（WMCS＝Wikimedia Cloud Services）
維基數據查詢服務的鏈結資料片段（LDF）端點將於2月停止運作。此端點原本服務流量有限，現已成功遷移至其他更適合支援現有用例的資料存取方式。原本用於支援LDF端點的硬體設備將重新分配，以支援進行中的後端遷移工作。
[63]
新版解析器Parsoid
正持續部署至更多維基站點
，這不僅能提升平台永續性，亦有助於導入新的閱讀與編輯功能。目前Parsoid已成為488個維基媒體站點（含268個維基百科站點）的預設解析器，涵蓋超過10%的維基百科頁面瀏覽量。
維基媒體企業服務API高流量資料源的
特殊存取權限申請
流程與標準
現已正式發布
（符合維基媒體使命的用例可免費取得）。此舉旨在為使用者提供更詳盡清晰的說明文件。
Tech Blog
，這個專為維基媒體技術社群設立的部落格，
預計將遷移
至社群新聞與活動部落格——
Diff
。遷移作業預計於2026年4月完成，之後將開放刊登新文章。讀者可在
入口頁面
瀏覽所有新舊文章。
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年3月2日 (一) 17:51 (UTC)
回复
《反共抗俄歌》、《中華民國陸軍軍歌》、《中華民國空軍軍歌》、《中華民國海軍軍歌》等是否進入了公有領域？
编辑
最新留言：
5天前
2条留言
2人参与讨论
如標題。
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年3月9日 (一) 02:49 (UTC)
回复
《反共抗俄歌》蕭而化作曲，其1985年卒，就推定歌曲版權缺許可，至於中華民國總統蔣中正親自作詞，其1975年卒，
可能算
因公作品而不受
m:美國對較短期間規則的不接受性
影響，但非完全確定。《陸軍軍歌》何志浩作词2007年卒，休想。《海軍軍歌》是約為桂永清擔任海軍總司令1946年至1949年間創作，1954年卒，不知作品因公因私。《空軍軍歌》簡樸（2004年卒）詞 劉雪庵（1985年卒）曲，也不知作品因公因私。非完全確定就請寧缺毋濫。--
TunnelESON
留言
2026年4月19日 (日) 02:44 (UTC)
回复
2026年第11期技術新聞
编辑
最新留言：
1个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
本週要聞
3月25日，
所有維基媒體站點將進入唯讀狀態
幾分鐘，預定於
15:00 UTC
開始。這是資料中心伺服器切換備份測試的必要程序，
每年執行兩次
。切換作業期間，所有維基媒體網站流量將從主要資料中心轉移至備援資料中心，以測試系統可用性，並確保即使面臨突發狀況，服務依然能維持不中斷。
上週，所有維基媒體站點進入了為期2小時的唯讀狀態，且使用者腳本與小工具功能在當日間暫時停用。此情況源於一件安全事故，目前已獲解決。相關團隊正在研擬防範措施，以避免類似問題再度發生。最新資訊請參閱
監管員布告板的公告
翻譯版本
）。
近況更新 - 面向編輯者
在行動裝置上遭遇多重封鎖的使用者，現在將能分別查看每項封鎖的具體原因，而非籠統的提示訊息。這將有助於使用者理解封鎖原因及可採取的解決措施。例如，因使用常見VPN（如
iCloud私密轉送
）而受影響的使用者，將獲得更清晰的指引，說明如何恢復編輯功能。
[64]
本週稍晚，
建議模式
將作為測試功能在所有維基百科的視覺化編輯器中上線。此功能會主動建議使用者可執行的各種編輯操作，以改善維基百科條目，同時協助使用者了解相關指引。此功能支援本地配置，亦可自訂「建議」項目來擴充此功能。現行設定可在
Special:EditChecks
頁面查看，該頁亦提供
管理員操作指引
，來設定「建議」中的連結應該指向哪個本地指引。此功能與
編輯檢查
功能連動，能在使用者撰寫新內容時提供改進建議。編輯團隊未來將透過控制實驗評估此功能對新使用者的影響。
[65]
上週有
23件由社群提交的工單
得到解決。 例如，之前使用CodeMirror的語法高亮功能（此功能可讓wikitext與代碼更易於閱讀）時，游標位置可能會出現錯位，現已修正此問題。這個問題特別影響到在個人CSS中自訂字型，並使用討論工具（DiscussionTools）建立新話題的使用者。
[66]
近況更新 - 面向技術貢獻者
【API速率限制更新】為確保
基礎設施的合理使用
，本週起將對以下請求實施全面API速率限制：並非來自Toolforge/
WMCS且未使用合規使用者代理的請求；來自網頁瀏覽器且未經身份驗證的請求。4月起，已驗證流量將適用較高限額。目前在Toolforge/
WMCS運行的機器人和擁有站內機器人權限的機器人應不受影響。不過，我們建議所有開發者遵循最新的最佳實踐。詳情請參閱
維基媒體API/速率限制
。（WMCS＝Wikimedia Cloud Services）
新的GraphQL API現已發布。此API旨在成為維基數據查詢服務（WDQS）特定功能的彈性替代方案，以期提升開發者體驗、促進適應性，並實現高效數據存取。歡迎試用並
提供意見回饋
，您亦可
報名參與可用性測試
遺棄工具支援工作組
（PTAC Unsupported Tools Working Group）於2月持續改進
Video2Commons
，解決了驗證錯誤、大型檔案處理等問題，同時提升了任務佇列可見度，並使上傳行為更明確。部分工作仍在進行中，包括與已棄用伺服器端上傳相關的變更。
了解更多
本週軟體更新細節：
MediaWiki
深入了解
條目導引團隊誠邀選定
試行維基
的資深維基百科編輯者，以及其他維基百科的熱心貢獻者填寫這份問卷。問卷提供
英語
阿拉伯語
孟加拉語
日語
葡萄牙語
波斯語
土耳其語
版本。您的回覆將協助團隊為經驗較少的編輯者量身打造導引，使其在撰寫條目時能同步學習社群方針與慣例。更多詳情請參閱
專案頁面
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年3月9日 (一) 18:53 (UTC)
回复
徵求意見：新命名空間「法律文書:」=「Case:」
编辑
最新留言：
5天前
35条留言
11人参与讨论
提議來自Midleading管
我再次建議為這些裁判文書新建一個命名空間。原因有三點：一，便於檢索時選定或者排除裁判文書，如果裁判文書過多，可以單獨調整裁判文書在檢索結果中的排序，二，錄入大量裁判文書時不會讓Special:Random全部重定向到裁判文書，三，有必要考慮要對裁判文書實行命名空間級別的永久半保護，因為沒有原件和掃描件，難以由匿名用戶進行校對，同時有大量個人信息，容易變成破壞的目標，而機器人統一導入的文本更可靠。這個命名空間將被視為主命名空間、Translation命名空間一樣，是中文維基文庫的正式收錄內容。
此命名空間目前將主要用於由機械人
User:SuperGrey-bot
匯入的中國裁判文書。根據
「请求wiki配置更改」規則
，我需要大家積極討論，並取得此提案的共識。感謝！
SuperGrey
留言
2026年3月12日 (四) 01:39 (UTC)
回复
倾向支持。但需要解决的问题是：
已有的裁判文书是否全部移动到新命名空间？是否保留重定向移动？需要考虑到百科及其他项目部分条目已经引用了本地的相关文书，这部分文书不留重定向移动似乎显然不妥，但这部分是否可以因为其被相关项目条目提及的显著性而保留在主命名空间？
范围只是中国大陆的裁判文书，还是可以包括其他所有地区的裁判文书？
“法律文书”是“裁判文书”的上位概念，需要明确只包括裁判文书，还是所有和法律相关的、公权力机关出具的文书？例如检察院的刑事起诉书、公安机关的相关文书等。
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照片占比大，是否也要拆分命名空间以彰显“公平”？
dring
sim
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的高级搜索语法
满足。
dring
sim
2026年3月13日 (五) 07:21 (UTC)
回复
高级搜索语法在中文维基文库懂的人可能都不到10个，如果未来每个用户包括匿名用户都必须懂高级语法才能在中文维基文库检索，那这是非常失败的，完全无法与直接在检索页面选择命名空间相提并论。Special:Random的问题更不可能通过什么高级语法解决了，WMF能提供空间存放这些文件已经是最大的帮助了，没有人会专为中文维基文库修改Special:Random。这里的情况和Commons区别很大，Commons的匿名用户很可能需要查找照片，但中文维基文库的用户中，需要查找法律文书的只是一小部分，如果没有新的命名空间，所有用户，特别是只阅读的匿名用户，会受到很大的影响。
Midleading
留言
2026年3月13日 (五) 16:55 (UTC)
回复
如果未来每个用户包括匿名用户都必须懂高级语法才能在中文维基文库检索，那这是非常失败的
”呃……诸如
北大法宝
全国报刊索引
都有很多不同的搜索选项，本站什么类型的文献都收怎么可能简简单单就搞定了……
dring
sim
2026年3月20日 (五) 12:07 (UTC)
回复
至于Special:Random，不同类别（该划分为什么类别又是一大问题）的作品被抽取到的可能性本来就已十分不均等，我认为实在没有讨论的必要。
dring
sim
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”的，不是拿来当
分类
用的……
dring
sim
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)
回复
异体字是否属于{{
}}的“讹字”范畴？
编辑
最新留言：
24天前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Template_talk:校
。执行人：
David, but not Hilbert
留言
2026年3月30日 (一) 16:12 (UTC)
回复
是否對繁體模式同樣啟用異體字轉換為規範字？
编辑
最新留言：
7天前
7条留言
3人参与讨论
由於一些歷史原因，維基文庫的
繁簡轉換
功能只在將原文轉簡體中文時，同時把異體字轉換為規範字。繁體中文使用者仍然會看到原文的異體字。考慮到有部分繁體中文使用者可能希望以規範字閱讀和檢索文獻，特此建議對繁體模式同樣啟用異體字轉換為規範字。此建議的目的是當使用者選取「繁體」轉換模式時，原文中的異體字會轉換為繁體中文的規範字。假設某文獻含有「爲」字，目前繁體模式仍顯示「爲」字，簡體模式顯示「为」字；啟用異體字轉換為規範字後，「爲」字在繁體模式會顯示「為」字，以便閱讀檢索，原文的「爲」字只能在「不轉換」模式顯示。
Midleading
留言
2026年3月15日 (日) 15:51 (UTC)
回复
「繁體中文的規範字」指的是臺標？有沒有可能兼顧港標、大陸《古籍印刷通用字規範字形表》等用字？
魔琴
留言
2026年3月17日 (二) 02:03 (UTC)
回复
沒錯，是臺標（電腦字）。如果使用其它標準，首先要把「繁體」拆分為「香港繁體」、「臺灣正體」等才有可能，而現在只有一種「繁體」。
Midleading
留言
2026年3月17日 (二) 02:50 (UTC)
回复
需要修改MediaWiki内置转换表将各语言变体的用字转换和地区词转换拆分开，否则无法在本站应用。另外大陆繁体（zh-Hant-CN）目前不受支持。
dring
sim
2026年3月20日 (五) 11:55 (UTC)
回复
悉。並不反對，但是對於以臺標繁體爲正的做法仍然保留疑慮。我認爲，修改MediaWiki轉換表以支持更多的繁體字標準，還是需要做的。--
魔琴
留言
2026年4月2日 (四) 14:20 (UTC)
回复
已經超過14天無人反對，可認為通過。
Midleading
留言
2026年4月17日 (五) 10:22 (UTC)
回复
图片表示的异体字也需要通过繁简转换功能转换为规范用字，只在“不转换”模式显示图片字。
Midleading
留言
2026年4月17日 (五) 10:48 (UTC)
回复
鲁迅全集PDF页码显示异常
编辑
最新留言：
1个月前
1条留言
1人参与讨论
本主題全部或部分段落文字，已
移動至
Index_talk:魯迅全集01_(1948).pdf
。执行人：
David, but not Hilbert
留言
2026年3月21日 (六) 10:36 (UTC)
回复
2026年第12期技術新聞
编辑
最新留言：
1个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
近況更新 - 面向編輯者
2024年11月，
增强版语法高亮
（亦稱為
CodeMirror 6
）以測試功能推出，用於wikitext的語法高亮顯示。此功能預計將於2026年5月正式推出，向所有使用該功能的編輯者提供改進與新
功能
。若您對此功能的正式推出有任何疑問或顧慮，
敬請提出
[67]
部分對本地使用者群組的變更由監管員在元維基執行，且僅記錄於元維基的日誌。現在，跨維基權限變更將同時記錄於元維基及目標使用者的維基站點中，以便查閱使用者在本地維基的完整權限變更紀錄。過去的此類變更日誌項目將於未來數週內補錄。
[68]
On wikis using
Flagged Revisions
, the number of pending changes shown on
Special:待定更改
previously counted pages which were no longer pending review, because they have been removed from the system without being reviewed, e.g. due to being deleted, moved to a different namespace, or due to wiki configuration changes. The count will be correct now. On some wikis the number shown will be much smaller than before. There should be no change to the list of pages itself.
[69]
維基函數的複合語言（composition language）已重新編寫。此次重寫旨在透過降低協調器的記憶體消耗，來提升服務的穩定性。此次重寫還帶來了顯著的延遲降低、代碼簡化以及更好的抽象化，為日後的功能擴展奠定基礎。
了解更多
使用者現在可以按頁面標題的字母順序對搜尋結果進行排序。此更新為使用者提供另一種更簡便、快速查找頁面的選項。先前，搜尋結果可依「編輯日期」、「建立日期」或「相關性」進行排序。若要使用此新功能，請在搜尋結果頁面上點開「進階搜尋」，並在「排序方式」下選取「字母順序」。
[70]
上週有
28件由社群提交的工單
得到解決。 例如，之前維基共享資源的上傳嚮導出現異常，無法從Flickr匯入檔案，現已修正此問題。
[71]
近況更新 - 面向技術貢獻者
新增了一個特殊頁面
Special:LintTemplateErrors
，用以列出被標記為含有Lint錯誤的被嵌入頁面，讓使用者更容易發現這些頁面。該清單是根據含有錯誤的嵌入次數進行排序。例如：
Special:LintTemplateErrors/night-mode-unaware-background-color
[72]
一段時間以來，對於啟用「
增强版语法高亮
」測試功能的使用者，在編輯JavaScript、CSS、JSON、Vue、Lua內容頁面時，編輯器已改用
CodeMirror
取代
CodeEditor
進行語法高亮。隨著CodeMirror 6的正式推出，我們預計於2026年5月以CodeMirror取代CodeEditor，作為這些內容模型的標準編輯器。
歡迎提出意見或疑慮
[73]
CodeMirror
的JavaScript模組即將升級至CodeMirror 6。在此次升級之前，在小工具和使用者腳本中載入
ext.CodeMirror
ext.CodeMirror.lib
模組的方法已於2025年7月標為棄用。此外，
ext.CodeMirror.switch
鉤子的使用亦已於2025年3月標為棄用。貢獻者現在可以修改腳本或小工具，使其與CodeMirror 6相容。詳情請參閱
遷移指南
[74]
MediaWiki介面團隊正在擴大REST API模組的定義範圍，將「
擴充功能API
」納入其中。REST API模組是由一系列相關端點組成的群組，可獨立進行管理與版本控制。目前已為
GrowthExperiments
維基函數
API建立模組。隨著我們將「擴充功能API」遷移至此架構中，相關文件將從MediaWiki OpenAPI主要規格及REST沙盒檢視中移出，改為透過
REST沙盒
（即
Special:RestSandbox
，所有維基專案皆可使用）下拉選單中的模組專屬選項存取。
Scribunto
擴充功能透過
mw.site
函式庫，為模組提供維基站點的各項資訊。自上週起，該函式庫亦提供了一種存取
維基站點ID
方式
，可用於簡化跨維基模組的維護工作。
[75]
本週軟體更新細節：
MediaWiki
深入了解
The
2026 Coolest Tool Award
celebrating outstanding community tools, is now open for nominations! Nominate your favorite tool using the
nomination survey
form by 23 March 2026. For more information on privacy and data handling, please see the
survey privacy statement
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年3月17日 (二) 12:09 (UTC)
回复
异体字
编辑
最新留言：
1个月前
2条留言
2人参与讨论
經典常談/說文解字第一
中有一些异体字，是以“【旗去掉右下角的“其”】”之类显示的，我根据
另一个版本
的书做的图片,比如
File:旗去掉右下角的“其”.svg
，可否加入？比如像这样：“
【旗去掉右下角的“其”】”。
Xzkdeng
留言
2026年3月22日 (日) 10:09 (UTC)
回复
您所举的该例子下各字均有编码，已据底本录入，所以可以不必以图代字。一般而言，若有未编码等情况时，以图代字是可选项之一。
银色雪莉
留言
2026年3月22日 (日) 11:04 (UTC)
回复
2026年第13期技術新聞
编辑
最新留言：
1个月前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
本週要聞
現在，維基媒體網站使用者可以使用通行密鑰（passkeys）無需密碼即可登入。這是一種支援指紋、臉部辨識和PIN碼的安全登入方式。隨著這項變更，所有選擇無密碼登入的使用者，將能更加便捷、快速、安全地使用任何裝置登入帳號。目前，新的通行密鑰登入選項會以「自動填入建議」的形式出現在使用者名稱欄位中。不久後，將為已註冊通行密鑰的使用者提供額外的
「使用通行密鑰登入」按鈕
。此更新將提升安全性與使用者體驗。參看
螢幕錄影影片
逐步演示無密碼登入的流程。
3月25日，
所有維基媒體站點將進入唯讀狀態
幾分鐘，預定於
15:00 UTC
開始。這是資料中心伺服器切換備份測試的必要程序，
每年執行兩次
。切換作業期間，所有維基媒體網站流量將從主要資料中心轉移至備援資料中心，以測試系統可用性，並確保即使面臨突發狀況，服務依然能維持不中斷。
近況更新 - 面向編輯者
維基媒體網站的使用者現在可以透過
新的Toolforge工具
，匯出超過5年的通知。這將確保使用者能保留重要通知，並避免因先前公告的變更計畫——刪除超過5年的通知——而導致通知遺失。
[76]
土耳其語、印尼語、泰語、簡單英語維基百科的編輯者，現已可使用Special:PersonalDashboard。這是該功能的
早期版本
，旨在引導新編輯者熟悉巡查工作流程，協助他們更容易從編輯工作，過渡到參與專案中的進階維護管理工作。
[77]
Special:Block
頁面有兩項小幅介面調整。管理員現可透過「期限」區塊中的專用單選鈕，輕鬆執行無限期封鎖。此外，選擇「無限期」時，系統會提供另一組常見理由供選擇，可在以下頁面修改：
MediaWiki:Ipbreason-indef-dropdown
[78]
得益於Growth團隊最近的更新，
多個維基站點
的行動版編輯者現在可以看到經過改進的「未登入編輯」警告。這些於上週發布的變更，是我們持續努力和測試的一部分，旨在提升
行動端的帳號建立體驗
，進而增加參與度。
[79]
上週有
36件由社群提交的工單
得到解決。 例如，之前行動版網頁使用者在受到多重封鎖影響時無法查看封鎖資訊，現已修正此問題。現在，當他們瀏覽維基百科時，可查看所有目前影響他們的封鎖的相關訊息。
近況更新 - 面向技術貢獻者
使用Toolforge建立的映像檔即將升級至新版建構包，此版本將支援較新的語言版本，並包含其他上游的改進與修正。如果您使用Toolforge建構服務，請查閱最近的
cloud-announce電子郵件
，並視需要更新您的建構配置，以確保您的工具相容。
[80]
[81]
API Portal
這一說明文件維基將於2026年6月關閉。在API Portal上建立的API金鑰將繼續正常運作。api.wikimedia.org端點將自2026年7月起逐步停用。API Portal上的文件將移動至
MediaWiki.org
了解更多
本週軟體更新細節：
MediaWiki
深入了解
WMDE技術願望
專案正在考慮改進
視覺化編輯器中自動生成的參考名稱（
name=
。請查看
解決方案提案
，並參與
意見徵詢
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年3月23日 (一) 16:51 (UTC)
回复
关于 header, header2, header3 的问题
编辑
最新留言：
19天前
4条留言
2人参与讨论
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)
回复
台灣分會2026年3月對話時間
编辑
最新留言：
27天前
1条留言
1人参与讨论
社群疑難雜症找協會！
台灣維基媒體協會
2026年3月的
對話時間
，訂於台灣時間
3/29 (日) 14:00
舉行，
參與連結為
協會到底在做什麼？如果你覺得協會存在感超低，有事都找不到人，把握這次的對話機會！這是一個定期舉辦的服務時段，由協會秘書長親自主持，有問題馬上解決。協會會分享目前進行中的專案與計劃，也邀請社群朋友分享想法、反映需求，彼此開講、一起討論。
本月討論主題將討論本年度社群交流與規畫，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！
--
MediaWiki message delivery
留言
2026年3月28日 (六) 06:28 (UTC)
回复
2026年第14期技術新聞
编辑
最新留言：
24天前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
本週要聞
在上週，
Abstract Wikipedia
（抽象維基百科、摘要維基百科）的Beta版本正式推出。Abstract Wikipedia是全新的基金會專案，旨在成為不依賴特定單一語言的維基百科，讓社群可以用自己的語言構築文章，讀者也能用自己的語言讀取文章。該wiki由Wikifunctions提供文字搭建支援，內容來源於維基數據中的結構化資料。
瞭解詳情
近況更新 - 面向編輯者
Growth團隊正在針對一項改進創建帳號提示詞的變更進行A/B測試。當前，手機使用者在未登入的狀態下開始編輯的時候，他們會看到一則警告提示，突兀、勸退、暗示使用臨時帳號就好、也不鼓勵創建帳號。提議的變更將更加友善，並且鼓勵創建帳號。該測試目前在十個維基百科中實裝，包括中文、阿拉伯語、法語、西班牙語和德語。
瞭解詳情
行動應用程式團隊現正針對
編輯功能應如何在應用程式中展現
一事徵求意見。討論將聚焦於如何改善使用者按下編輯按鈕後接觸編輯工具的方式。放眼全局，這關切到如何友善地將對編輯有興趣的讀者，轉變為確實的編者。
上週有
45件由社群提交的工單
得到解決。 例如，之前無法從報紙檔案庫
Newspapers.com
擷取引用，這是由於
Citoid
請求遭到封鎖，現已修正此問題。
[82]
近況更新 - 面向技術貢獻者
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年3月30日 (一) 19:25 (UTC)
回复
裁判文书的命名
编辑
最新留言：
3天前
7条留言
3人参与讨论
张某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)
回复
徵求意見：監管員、志工回覆團隊
编辑
最新留言：
21天前
1条留言
1人参与讨论
邀請大家共同研議：
Wikisource:請求管理員幫助#請求管理員研議：監督員、志工回覆團隊
SuperGrey
留言
2026年4月2日 (四) 23:20 (UTC)
回复
Action Required: Update templates/modules for electoral maps (Migrating from P1846 to P14226)
编辑
最新留言：
20天前
1条留言
1人参与讨论
Hello everyone,
This is a notice regarding an ongoing data migration on Wikidata that may affect your election-related templates and Lua modules (such as
Module:Itemgroup/list
).
The Change:
Currently, many templates pull electoral maps from Wikidata using the property
P1846
, combined with the qualifier
P180
Q19571328
We are migrating this data (across roughly 4,000 items) to a newly created, dedicated property:
P14226
What You Need To Do:
To ensure your templates and infoboxes do not break or lose their maps, please update your local code to fetch data from
P14226
instead of the old
P1846
P180
structure. A
list of pages
was generated using Wikimedia Global Search.
Deadline:
We are temporarily retaining the old data on
P1846
to allow for a smooth transition. However, to complete the data cleanup on Wikidata, the old
P1846
statements will be removed after
May 1, 2026
. Please update your modules and templates before this date to prevent any disruption to your wiki's election articles.
Let us know if you have any questions or need assistance with the query logic. Thank you for your help!
ZI Jony
using
MediaWiki message delivery
留言
2026年4月3日 (五) 17:11 (UTC)
回复
新手的几个问题
编辑
最新留言：
18天前
5条留言
3人参与讨论
我最近部分录入了
關於列寧主義底機礎
这篇文章，毕竟是新手，想请大家看看有没有什么问题，特别是格式，版权标记之类的。
Template:Not-PD-US-anon
上说“本站作消極容忍處理，不鼓勵但也不反對增加與刪改有關内容”，也就是说可以录入
数量较多
的此类内容？(虽然我知道这种行为可能不怎么受欢迎)
Module:Sandbox
是沙盒吗，上面没有标记。
Xzkdeng
留言
2026年4月4日 (六) 14:00 (UTC)
回复
首先，翻译作品属于衍生作品，因此需要在原创作品的基础上确定它们的版权形式，原作者于1953年逝世，依据俄罗斯联邦著作权法规（可见
c:Commons:Copyright rules by territory/Russia
，著作于作者逝世后70年进入公有领域），该原作的著作权已于2023年（1953+70）在俄罗斯失效并进入公有领域。其次，由于维基数据库位于美国佛罗里达州境内，数据库里的内容是否合法显然应当首先依据美国的版权法来确定，即由于
美国对较短期限法则的不接受性
（若1996年1月1日在原作地仍有著作权，则美国著作权自出版起95年有效，即使现在在原作地著作权已经失效），该作著作权将在2048年失效并进入公有领域。最后，您提及的
Template:Not-PD-US-anon
仅适用于以匿名或别名发表且确实作者身份不明的情况。综上，本作因版权仍未于美国失效而不宜录入。
Wikisource:沙盒
是沙盒。
MarkZhou08
留言
2026年4月4日 (六) 15:45 (UTC)
回复
原作是1924年发表的，“若1996年1月1日在原作地仍有著作权，则美国著作权自出版起95年有效”，所以它不是应该于1924+95=2019年就于美国进入公有领域吗？另外，如果所说的Template:Not-PD-US-anon是针对于录入的译文，译文1949年于中国匿名出版，应该适用吧？
Xzkdeng
留言
2026年4月4日 (六) 17:29 (UTC)
回复
更正一下我之前的说法，根据
2006年12月18日俄罗斯联邦第230-FZ号《民法典》第四编
第1281条“如果作者在伟大卫国战争期间创作或参加过战争，则本条规定的专有权有效期延长四年。”，本作著作权应于2028年1月1日失效。其他有关细节可以看一下
User:银色雪莉
的讲解（感谢！）。另外，翻译作品属于衍生作品，因此需要在原创作品的基础上确定它们的版权形式，若原创作品未进入公有领域，译文也是不能录入本地的。
MarkZhou08
留言
2026年4月5日 (日) 13:55 (UTC)
回复
稍为说明一下情况：
（1）原作的版权：根据现有的
c:Commons:Copyright rules by territory/Russia
，这篇发表于1924年的斯大林作品在起源国不是+70，而是+74（“伟大的卫国战争”条款影响），所以是到2028年1月1日起到期。当原作在起源国到期后，考虑年份，该作品在本地可以直接上
Template:Pd/1923
而不会受美国较短期限法则的影响。——简而言之，现在卡着斯大林作品的录入的主要是起源国法律而不是美国。与之可以作为对照的是他在1917年以前发表的作品如
編輯部的話
则无碍，因为根据
c:Template:PD-RusEmpire
所指，其已在公有领域（注：之前忘了引进模板到本地，请忽略《编辑部的话》里的模板问题）
（2）译作的版权：姑且按该本的出版日期即1949年计算，在起源国已经进入公有，但是由于美国较短期限法则，要挂
Template:Not-PD-US-anon
模板，“不鼓勵但也不反對增加與刪改有關内容”。——但就算如此，还有原作的版权问题卡着呢，译作的版权是要结合原作的版权状况来考虑的，简而言之就是原作译作都要到期，译作才真的能被录入。
综上：还没行，等2028再说。
银色雪莉
留言
2026年4月4日 (六) 17:59 (UTC)
回复
2026年第15期技術新聞
编辑
最新留言：
17天前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
近況更新 - 面向編輯者
The
CampaignEvents extension
now includes a new group goal-setting feature, enabling organizers to set and track event goals such as the number of articles created and participating contributors in real time. Similarly, participants can work toward shared targets and see their collective impact as the event unfolds. The feature is now available on all Wikimedia wikis. Learn more in
the documentation
The new
watchlist labels
feature (announced in
Tech News 2026-07
) is now available via VisualEditor, the source editor, and the 'watchstar' (or watch link, for skins that don't have a star icon). Previously it was only possible to assign labels via
EditWatchlist
. In all three places it is a new field following the expiry field.
上週有
23件由社群提交的工單
得到解決。 例如，之前在行動版網頁上，用Parsoid解析的討論頁若有空白話題標題，會導致該處以下的討論頁無法正常使用，現已修正此問題。
[83]
近況更新 - 面向技術貢獻者
The
sub-referencing feature
, which lets editors add details to an existing reference without duplicating it, will be gradually rolled out to
more wikis
later this year. Wikis using the
Reference Tooltips
gadget are encouraged to update their version (typically at
MediaWiki:Gadget-ReferenceTooltips.js
as shown
here
) to ensure compatibility. Other reference-related gadgets may also be affected.
[84]
All Wikinews editions will be closed and switched to read-only mode on 4 May 2026. Content will remain accessible, but no new edits or articles can be added. This closure was approved by the Board of Trustees of the Wikimedia Foundation following extended discussions.
The
Action API
has had several formats for requested output. One of them,
format=php
, is being removed soon. Please ensure your scripts or bots use the
JSON format
. This removal should affect very few scripts and bots.
[85]
The
Special:NamespaceInfo
page now includes namespace aliases. For example "WP" for the "Project" ("Wikipedia") namespace on the German Wikipedia.
[86]
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年4月6日 (一) 16:19 (UTC)
回复
如何錄入這本書？
编辑
最新留言：
16天前
2条留言
2人参与讨论
原文：
[87]
如題，這本書的名字叫《
菴集》。但是
unicode不存在。怎麼辦？就在維基文庫輸入
"⿱秋木菴集"
如何？
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月7日 (二) 03:21 (UTC)
回复
Liouxiao
留言
2026年4月8日 (三) 02:27 (UTC)
回复
2026年第16期技術新聞
编辑
最新留言：
10天前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
本週要聞
誠摯邀請資深編輯者參與
測試
條目建立指南
」功能，此功能旨在協助經驗較少的編輯者創建結構完善且符合方針指引的維基百科條目。請參閱
測試說明
。此外，請在審閱完
大綱
後，於
專案討論頁
提供意見回饋。我們將根據您的回饋來優化該功能，並移交至參與試行的維基百科站點以進行翻譯與調整。請觀看此功能的
介紹影片
近況更新 - 面向編輯者
在大多數維基，所有自動確認使用者現在可使用
Special:ChangeContentModel
頁面來
自訂新頁面的內容模型
（如大量信息递送列表）並建立，讓更多人能利用wikitext以外的內容格式。查看
Special:ListGroupRights
來確認您的維基是否有這項變更。
[88]
成长团队已启动一项
账户创建实验
，旨在评估在移动网页页眉中添加账户创建按钮，是否能增加新账户注册量，并鼓励更多移动用户参与维基百科的贡献。该实验目前已在印地语、印度尼西亚语、孟加拉语、泰语和希伯来语维基百科上线，面向10%的未登录移动网页用户。
上週有
30件由社群提交的工單
得到解決。 例如，之前在微軟Windows裝置上，若「動畫效果」設為關閉，維基視覺化編輯器可能會在載入時卡住，現已修正此問題。
[89]
近況更新 - 面向技術貢獻者
本週稍晚起，對於啟用「
增强版语法高亮
」測試功能的滥用过滤器编辑者，
Special:AbuseFilter
中的編輯器將從
CodeEditor
改為
CodeMirror
。我們計畫讓所有編輯器的UX更加一致。
[90]
[91]
访问
通知API
action=query&meta=notifications
)的工具和机器人，需要更新其OAuth或BotPassword授权，以包含对私有通知的访问权限。
[92]
由于库升级，自4月20日（星期一）起，分类页面上的列表显示顺序可能会出现错乱。我们将运行迁移脚本来修复此问题；根据维基规模的大小，修复过程可能耗时数小时至数天（对于英语维基百科，最长可能需要一周）。
[93]
本週軟體更新細節：
MediaWiki
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年4月13日 (一) 15:19 (UTC)
回复
"貼是"是什麼意思？
编辑
最新留言：
7天前
3条留言
2人参与讨论
海東諸國記
》有說過：「
砂貼是。〈쉬릐〉
木貼是。〈파지〉
砂貼是 和 木貼是 看似都是名詞，但是我不知道“貼是”到底是什麼。各位的中文比我的更好。
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月15日 (三) 18:52 (UTC)
回复
「碟子」。砂貼是：「皿」；木貼是：「鉢」。可能是琉球語的漢文讀音，比如從漢語「磁楪子/砂陶碟子」、「木楪子/木碟子」（音近）傳讀後錯訛而來。
參考
Liouxiao
留言
2026年4月16日 (四) 01:31 (UTC)
回复
感謝！！
大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh
留言
2026年4月16日 (四) 14:00 (UTC)
回复
GB/T 47229-2026能录入吗
编辑
最新留言：
7天前
3条留言
2人参与讨论
GB/T 47229-2026
法律法规电子文件
将于2026年9月1日实施，是不是需要哪个法律文件提到要求执行这个标准，文库才能录入？——
Zzhtju
留言
2026年4月16日 (四) 13:41 (UTC)
回复
大体如此。
银色雪莉
留言
2026年4月16日 (四) 16:11 (UTC)
回复
谢谢！
Zzhtju
留言
2026年4月16日 (四) 17:02 (UTC)
回复
标明页码、保留原文献布局的Page版本和纯文字录入的版本，以何为主？
编辑
最新留言：
5天前
2条留言
2人参与讨论
中华人民共和国全国人民代表大会常务委员会公报/2020年/第二号
为例，最初版本是纯文字录入版本，但被人修改成了Page版本。个人认为应该以纯文字录入版为主，Page版本添加消歧义括号，作为特定版本处理。--
大化國史館從九品筆帖式
留言
2026年4月19日 (日) 02:57 (UTC)
回复
照指引走是推荐page版本，
Wikisource:样式指南#校对页样式
。偏好哪种方式可能因人而异，不过私以为“以何为主”是与“偏好哪种”不同的问题，且恐怕不是一个能够成立的问题——纯文字和page是录入方式的差异，不是版本的差异，同一个版本的原始出版物，如果要做成一个纯文字录入和一个page分离，这样的必要性的逻辑在下暂时还看不清楚。
银色雪莉
留言
2026年4月19日 (日) 12:10 (UTC)
回复
本Wiki的讨论页方针在哪里？
编辑
最新留言：
4天前
1条留言
1人参与讨论
我找不到
Pawsdt
讨论
贡献
2026年4月20日 (一) 11:30 (UTC)
回复
2026年第17期技術新聞
编辑
最新留言：
3天前
1条留言
1人参与讨论
維基媒體技術社群現在發布最新的
技術新聞
。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的
翻譯版本
本週要聞
經過兩年的開發，
增强版语法高亮
（亦稱為
CodeMirror 6
）將於4月21日（二）正式推出。此功能將為所有使用標準語法高亮的編輯者帶來更佳的代碼與wikitext可讀性、減少輸入錯誤，以及其他諸多
好處
。特別感謝志願者
Bhsd
，他開發了許多新功能，包括
代碼摺疊
自動完成
Lint檢查
[94]
維基百科iOS版應用程式推出重大更新，重新設計了介面，以符合Apple最新的「Liquid Glass」視覺設計。請
下載最新版本
來體驗此次更新。
近況更新 - 面向編輯者
閱讀清單
」功能可讓讀者將條目儲存至清單中，以便日後閱讀。此功能目前已在中文、印尼語、法語、阿拉伯語及越南語維基百科上開放測試，並為所有維基百科新帳號預設啟用。
4月20日當週將啟動將
「頁面預覽」功能擴展至行動版網頁
的實驗，在法語、波蘭語、阿拉伯語、英語、越南語、義大利語維基百科上推出。「頁面預覽」是一種彈窗，會顯示條目的縮圖、序言，以及一個可點擊開啟完整條目的藍色链接，藉此提升內容的探索體驗。此功能已在桌面版網頁及手機APP中提供。
了解詳情
在多個維基站點上，已登入但尚未驗證電子郵件地址的編輯者，現在會看到一則橫幅，鼓勵他們進行驗證。驗證電子郵件地址後，若使用者遺失帳號，即可藉此取回對該帳號的存取權限。
了解詳情
[95]
上週有
15件由社群提交的工單
得到解決。 例如，之前在2017年版wikitext編輯器中編輯內容龐大的維基頁面時，會出現載入緩慢、預覽與捲動延遲，以及在選取、剪下或貼上內容時出現效能問題，現已修正此問題。
[96]
近況更新 - 面向技術貢獻者
隨著
CodeMirror
正式推出，所有使用者在編輯JavaScript、CSS、JSON、Vue、Lua內容頁面時，將改用
CodeMirror
進行語法高亮，取代
CodeEditor
[97]
專為Debian和Ubuntu使用者提供的
mirrors.wikimedia.org
服務將於5月15日停止運作。該服務的軟硬體資源將更換為更先進的設備。部分使用者可能需要切換至其他伺服器，此過程約需一分鐘。
了解詳情
[98]
image
oldimage
資料表將從
Wiki Replicas
中移除。若您的工具或查詢會直接存取
image
oldimage
資料表，請務必於5月28日之前更新相關程式，改用
file
filerevision
資料表。
[99]
繼近期針對未經身份驗證流量實施全面API速率限制後，維基媒體基金會將持續致力於確保
基礎設施的合理使用
，並將自4月最後一週起，對已驗證的API流量實施全面限制。此限額刻意設定得盡可能高，以盡量減少對社群的影響。目前在Toolforge/
WMCS運行的機器人和擁有站內機器人權限的機器人應不受影響。不過，我們建議所有開發者遵循最新的最佳實踐。詳情請參閱
維基媒體API/速率限制
常見問題解答
。（WMCS＝Wikimedia Cloud Services）
姓名標示API
現已開放
Beta測試
。此API可在任何使用維基媒體條目及媒體檔案之處，擷取用於標示來源的資訊。相關參考文件可透過所有維基媒體站點上的REST沙盒特殊頁面查閱（例如
中文維基百科上的REST沙盒
）。請在
專案討論頁
分享您的意見回饋。
本週沒有MediaWiki版本更新。
技術新聞
技術新聞編者
準備，並由
機器人
送達 •
貢獻
翻譯
获取帮助
提供反馈
訂閱或退訂
MediaWiki message delivery
2026年4月20日 (一) 15:00 (UTC)
回复
检索自“
分类
：​
维基文库
隐藏分类：​
使用已弃用enclose属性的页面
维基文库
写字间
添加话题