维基文库:写字间

←社區

写字间

存檔→

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

维基文库项目

维基文库是什么

维基文库与维基教科书

写字间

投票

版权信息

版权讨论

删除讨论

移动请求

请求管理员帮助

發言更新圖例

• 最近一小時內

• 最近一日內

• 一週內

• 一個月內

• 逾一個月

特殊狀態

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

手動設定

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

建议文库也导入网页存档机器人

如题。免得有些网页来源失效了。 ——— 红渡厨（留言・贡献） 2023年11月20日 (一) 03:07 (UTC)

要是技术上可行的话（不懂技术），个人觉得这个应该不错。 银色雪莉（留言） 2023年11月21日 (二) 09:50 (UTC)

支持。如果可行的话建议配置为仅存档talk页{{Textinfo}}模板中的链接。--Kcx36（留言） 2023年11月22日 (三) 08:18 (UTC)

网页存档机器人连英文维基文库都没有，不知道怎么才能在中文维基文库加入。在维基文库避免来源失效的最好办法是把原文扫描版文件上传到维基共享资源，并建立页面索引。 --Midleading（留言） 2023年11月22日 (三) 10:00 (UTC)

但事实是有很大一部分内容只是网页内容没有所谓原文扫描件。总不能将这部分内容放弃不管。而且我看中文维基百科有存档机器人才提出的本案。要是都没人知道怎么弄的话去那边问问？ ——— 红渡厨（留言・贡献） 2023年11月22日 (三) 12:30 (UTC)

有共识的话，管理员可以在这个页面申请启用，确实别的文库都没开启，不知道为何 及时雨 ^留言 2023年12月1日 (五) 21:50 (UTC)

可能是维基文库使用的模板和维基百科的不同，基本没有人用维基百科的{{cite web}}，维基文库的{{textinfo}}也没有存档网址参数？中文维基文库如果要做第一个使用网页存档机器人的维基文库，可能需要找个了解网页存档机器人工作机制的人测试。 Midleading（留言） 2023年12月2日 (六) 15:24 (UTC)

可以参考m:InternetArchiveBot/Documentation/Configuring_archive_templates，IABot url参数填我们模板用的参数source，然后我们需要加几个模板参数 及时雨 ^留言 2023年12月3日 (日) 00:35 (UTC)

@Kcx36：有关于阁下建议配置为仅存档talk页{{Textinfo}}模板中的链接，这点我有异议，因为事实上部分用户并没有在talk页{{Textinfo}}模板中加来源的习惯。譬如：关于进一步规范出版物文字使用的通知、

讨论:帝王略論、清丰县2016年国民经济和社会发展统计公报等。最好还是配置为有网页链接就加。 ——— 红渡厨（留言・贡献） 2023年12月22日 (五) 07:42 (UTC)

设置成处理{{textinfo}}和{{header}}中的链接呢？ 沈澄心✉ 2024年8月1日 (四) 15:34 (UTC)

讨论:帝王略論，您看这个页面就是，网址不在任何一个模板里，只有设置成全部网页都添加，才能匹配所有人的习惯。 ——— 红渡厨（留言・贡献） 2024年8月2日 (五) 01:53 (UTC)

應當鼓勵上傳者填寫網址之時先即時自行存檔，肯定比機器人快。—— Eric Liu_（留言） 2023年11月26日 (日) 10:38 (UTC)

不现实，大部分人没有这种习惯。否则维基百科那边也就不需要什么存档机器人了。（甚至更多的人连加来源这种习惯都没有。） ——— 红渡厨（留言・贡献） 2023年11月26日 (日) 10:50 (UTC)

這裡還是建議大家安裝網際網路檔案館瀏覽器擴充功能，並開啟自動存檔機制（ —— Eric Liu_（留言） 2023年11月26日 (日) 11:19 (UTC)

阁下这样的建议让我觉得非常奇怪，这就如同阁下想对世界70亿人口说你们不要违法犯罪，第一个问题是，阁下没有办法对70亿人一个不落；第二个问题是，即使对这70亿人全部说了，你仍旧无法保证这70亿人不会违法犯罪。甚至这70亿人中有人已经或者正在违法犯罪。 ——— 红渡厨（留言・贡献） 2023年11月26日 (日) 11:48 (UTC)

不理解您想表達的意思。我們自己先有意識地「以身作則」有什麼問題？又沒說不讓啟用這功能了，而且我事實上還挺歡迎的。—— Eric Liu_（留言） 2023年12月27日 (三) 01:37 (UTC)

您支持提案就好。 ——— 红渡厨（留言・贡献） 2023年12月27日 (三) 03:30 (UTC)

往页面添加存档链接还是跑Bot快一点。。。 沈澄心✉ 2024年7月1日 (一) 13:58 (UTC)

支持 及时雨 ^留言 2023年12月1日 (五) 22:09 (UTC)

基本上参与本条讨论的各位都很支持，要不就2024年1月1日正式启用吧。——— 红渡厨（留言・贡献） 2023年12月27日 (三) 03:32 (UTC)

主要还是技术问题。--Kcx36（留言） 2023年12月27日 (三) 04:21 (UTC)

我看@94rain：阁下好像知道怎么弄。不如请这位阁下来协助操作。 ——— 红渡厨（留言・贡献） 2023年12月27日 (三) 09:56 (UTC)

管理员参考m:InternetArchiveBot/Documentation/Configuring_archive_templates去那个界面修改配置，然后我们textinfo模板需要增加archive url, archive date 及时雨 ^留言 2023年12月29日 (五) 13:52 (UTC)

textinfo模板的source参数不总是填写URL，所以我不建议把archive url等参数直接加到textinfo模板上 沈澄心✉ 2024年8月1日 (四) 14:33 (UTC)

这条有懂代码的管理员出来说个话不。。——— 红渡厨（留言・贡献） 2024年1月10日 (三) 07:38 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年1月24日 (三) 02:48 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年3月5日 (二) 06:47 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年4月1日 (一) 16:01 (UTC)

支持该提案。存档出现的所有链接即可，事实上维基百科的机器人也会存档cite模板之外的链接的。--Yinyue200（留言） 2024年4月7日 (日) 05:56 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年5月5日 (日) 04:26 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年6月1日 (六) 09:39 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年7月1日 (一) 13:48 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年8月1日 (四) 14:38 (UTC)

把{{webarchive}}搬运到文库了。 沈澄心✉ 2024年8月1日 (四) 15:02 (UTC)

总之先仿照百科的phab:T163869开工单（phab:T371655）了。@94rain、@Ericliu1912、@Kcx36、@Midleading、@Yinyue200、@红渡厨、@银色雪莉：请问还有没有什么需要补充的？ 沈澄心✉ 2024年8月2日 (五) 02:38 (UTC)

我这边没什么补充，只要能把所有网页都存档就行。 ——— 红渡厨（留言・贡献） 2024年8月2日 (五) 02:50 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年9月8日 (日) 04:22 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年10月2日 (三) 02:45 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2024年11月1日 (五) 03:12 (UTC)

事已迟，静待未必如寻他人。--Zy26（留言） 2024年11月14日 (四) 10:44 (UTC)

@Cyberpower678：We humbly ask you, regarding task phab:T371655. If you have the leisure, might you kindly take a moment to review and assist in its processing? --Zy26（留言） 2024年11月14日 (四) 10:44 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2025年1月1日 (三) 12:09 (UTC)

本案仍需处理。——— 红渡厨（留言・贡献） 2025年2月4日 (二) 09:22 (UTC)

重写维基文库方针和说明文档

明年中文维基文库即将迎来20周年华诞。一些方针和说明文档已有近20年的历史，让人感觉晦涩难懂，内容过时。我计划明年对其进行大幅修改。对方针的修改尽量不会有争议，如果别人不满意也可以讨论。 維基小霸王（留言） 2024年12月4日 (三) 14:21 (UTC)

支持。我半年前就大致整理过一次帮助文档和模板说明，但很多还需要大幅完善。 Kcx36（留言） 2024年12月4日 (三) 16:20 (UTC)

支持，目前很多应当有的文档仅存在于英文维基文库，例如en:WS:V，en:Help:Index pages。 曾晋哲（留言） 2024年12月4日 (三) 18:42 (UTC)

 支持：修正案可即時陸續提出，俾便社群分批檢視。—— Eric Liu_（留言） 2024年12月9日 (一) 16:01 (UTC)

完全 支持。 银色雪莉（留言） 2024年12月26日 (四) 07:02 (UTC)

 支持。Teetrition（留言） 2025年1月7日 (二) 09:01 (UTC)

 支持。另外(＆)建議：希望能补上中文特有的东西：异体字如何处理、怎样查询，直排标点符号怎么录入、引号和句号连一起时顺序是否要转换成横排习惯，首行缩进、{{nop}}，穿越历史的文献怎么算版权…… David, but not Hilbert（留言） 2025年2月18日 (二) 14:16 (UTC)

• 從校對頁錄入時，目前共識是盡量使用原文用字。但是，古籍用字複雜，Unicode 編碼并不完美，很難制定一句話指引。
• 直排標點在w:標點符號有列出。如錄入原文標點，請與原文一致。如自行加標點，無用法限制。
• 引号和句号连一起：請與原文一致。
• 首行缩进：社群可能共識不足或沒有指定樣式。既往討論有Wikisource:写字间/存档/2023#要加gap吗？個人認爲只要整部作品一致即可，無需全站統一。如需要縮進，個人建議用{{gap}}或類似的不添加額外字符的模板，避免使用空格。
• {{nop}}用於校對頁錄入時頁面正文的結尾，讓下一頁另開新段。

Andayunxiao（留言） 2025年2月18日 (二) 16:21 (UTC)

感谢回复！（我不确定在这里讨论是否合适，不合适的话我新建个话题挪过去。）

• Unicode 编码并不完美

是啊，值 ≠ 値，可右边的的“直”似乎只有一个码？真是令人裂开……

• 缩进

请看Page:魯迅全集01_(1948).pdf/323。全文无段间距，每段首行缩进；但是『小栓——你坐着，不要到這裏來。』这句似乎是插在段中间，它自己这行缩进两字，下一行打头写。

我在此用了<br>和{{gap}}，不知是否合适？（我在段首加{{gap}}是沿用这部作品既有做法，并非有所偏好。）

• 标点与原文一致

请看Page:魯迅全集01_(1948).pdf/361的『七斤嫂，你「恨棒打人」。……』 。原文用直角引号，但并非「『』」，而是『「」』。在“不转换”和“繁体”模式，与原文一致，我没有疑问；可在“简体”模式时，引号会转换成‘“”’，既不合原文，又与今日习惯相反。

有无办法在特定页面关闭引号转换？

• 引号和句号连一起

也请看Page:魯迅全集01_(1948).pdf/361的『七斤嫂，你「恨棒打人」。……』。原文标点二维排布，引号、省略号作为行内标点依次放在“人”下方，句号作为行间标点放在“人”右方。

然而录入时只有一维，。」……、」。……、」……。选哪个？

• {{nop}}

我看也有给末段套<p>的（暂时未翻到是哪里），请问有区别吗？

David, but not Hilbert（留言） 2025年2月18日 (二) 17:16 (UTC)

• 値的右方部件可以是直(U+2F940)，在擴充區F區，目前主流閱讀環境應該都沒有字型原生支援，或乾脆直接映射到直(U+76F4)。
  其實我也給忘了有這個碼位，我都用直錄直。這下可好了...
• Page:魯迅全集01_(1948).pdf/323像這類有著原稿紙版型風格的作品，每段開頭都有空格，故可以直接交給Index:魯迅全集01_(1948).pdf/styles.css負責縮排即可
  

  ::::p {
  ::::    text-indent: 2em; /* 每段開頭縮排2字元 */
  ::::}
  

  
  之後即可直接一段一段錄入，無須手工縮排。每段(p元素)會自動縮排。
• Page:魯迅全集01_(1948).pdf/361是一個很好的早期標點風格舉例。在橫書顯示時，最終輸出應渲染為
  八一嫂也發怒，大聲說，『七斤嫂，你「恨棒打人。」……』
  。」……』，即引號與句點相連。
  在簡體模式，受限於自帶的轉換規則。需要用-{}-對符號進行行內跳脫處理，或是套用頁面轉換規則如-{H|}-、模板{{noteTA}}等。
  不過這些處置應做為推薦性或補充性即可。為維基的繁簡體轉換適配這件事，甚至不屬於貢獻者的本務範疇，而是編輯性質的低優先度事項。
• {{nop}}：來細說nop好了。維基的校對頁擴展會將跨頁內容接合避免中斷，又由於Wikitext用的雙換行以換段，這會導致雙換行被解析器視作空行並裁切掉，換段失敗。故需要插入一個塊元素(如<div>)之類的實體來確保解析器理解文本到這兒到底了，要對當前段落(如p元素)閉合，再來處理空的塊元素(nop)。
  故如果貢獻者欲確保段落(p)或行內元素(span)正常收尾，就可用{{nop}}，或是你有時會看到的</p>直接提示解析器對p元素作閉合。
  先前說到我的情況是因我多編輯古籍，常用<ul>等塊元素排版，通常能自帶正常閉合。所以{{nop}}對我來說更多是註釋用途。屬於個人寫作風格，不應做為方針。 Aerotinge（留言） 2025年2月19日 (三) 02:52 (UTC)
• 對縮排及Page:魯迅全集01_(1948).pdf/323再行補充：維基解析器通常會對頁面第一行另起新p元素，所以該CSS樣式很可能會縮在不該縮的跨頁後第一行(因為被當成新段落開頭了)。
  英語文庫那邊我看到比較多的作法是用{{ti/s}}(樣式起始)、{{ti/m}}(跨頁頁首)、{{ti/e}}(頁尾、樣式結束)來處理跨頁縮排。 Aerotinge（留言） 2025年2月19日 (三) 03:21 (UTC)

• 直排符號，原文無標點的可以先用{{ia}}加點錄入。原文為旁注標點或字距間插入標點的這兩種，我也還在苦思中。
• 同意Unicode 編碼并不完美。故先求有再求好，行有餘力再盡量保留足夠的元數據，如結構等。以待未來Unicode擴充可能性。不期不待，不受傷害
• 對於標點，比較會出問題的是引號的部分。這會隨著錄入者而有所不同，又無法依靠轉換表去達成轉換。(好吧是可以，非常之冗餘)
  • 另外就是對於日、朝的漢文作品該如何標點？如一件日人無読点（、）的漢文作品是該用標點符號，抑是依所在地按約物、w:諺文正寫法標點？
• 引号和句号连一起：同意，但最好參閱一下W3C草案對於連續標點的處理。我看中國好像存在相關的國標，或許會需要對習慣中國方案的編輯者做釐清說明。
• 首行缩进：個人建議使用{{dent}}、{{hi}}及子模板{{dent/s}}、{{dent/e}}等等來達成，或是從樣式表下手，配合<ul>, <li>等元素做縮排。我也用過{{gap}}排版面，現在只悔不當初，通篇贅模板。
  如果存在使用困難再來使用{{gap}}，這不失為一個新手友好的方式，也總強過用全形空白　做縮排、抬頭、挪抬等等。
• {{nop}}按需使用，我是僅加在序、卷、跋等結構的結尾作收。至於內文段落若收在頁面末端，需就語意跨頁另起新行時，我會用<p>手動開新段。
• 割注：結尾採日式規範，不加標點，避免出現雙句號或是雙重引号句号結構。

還有一些，想到再補充。 Aerotinge（留言） 2025年2月18日 (二) 17:16 (UTC)

我也用过{{gap}}排版面，现在只悔不当初，通篇赘模板。

同意。模板太多除了人难读，还可能干扰机器生成 diff。 David, but not Hilbert（留言） 2025年2月18日 (二) 17:32 (UTC)

• 我认为校对页面和主页面显示不同内容，完全通过软件层面的处理即可完成。每个标点添加{{ia}}太麻烦了。另外，建立忠实原文和现代标点的两种页面也不利于维护。如督戎疏紀/卷之一和督戎疏紀_(影印本)/卷之一。一方面我很尊重这样做的编辑很用心，一方面我觉得如果有一天更正错字，需要修改两个地方，很麻烦。最好的做法是能通过软件进行修改，可自动将嵌入包含的页面显示为督戎疏紀/卷之一的样式。现在chatgpt等llm可以帮助写代码，我觉得咱们可以试着写一个。--維基小霸王（留言） 2025年2月20日 (四) 02:02 (UTC)

  我在建立{{ia}}模板前也想過軟件方案，如js工具、lua模組，

  • js小工具需要審核後方能添加到維基站點。還需要進一步判對當前頁面命名空間是否為無標點文書，如果沒有參數支持，那就要讀者用戶自行手工打開。
  • lua模組則是方便用於作品頁嵌入時刪去符號，剛好與古文校對頁無標點的目的相反。

  思來想去讓編輯貢獻者自己來負擔成本還較省事，至少可調可控。花的時間也不過是完稿後敲幾個Ctrl+H作取代的工夫，或是直接丟進python處理。

  反正這模板只是工具，也還能修改。我就在想著要來把這些標點改成偽元素，使其真正的與實體原文分離。 Aerotinge（留言） 2025年2月20日 (四) 03:00 (UTC)

  我見到您提供的模組了，的確是可以照著軟件這個方向去做。 Aerotinge（留言） 2025年2月20日 (四) 03:11 (UTC)

关于Template:楷體

或者不应该整篇文章强制使用某种特定字体，而是用什么字体读文章交给用户自己决定比较好。 Huhu9001（留言） 2024年12月26日 (四) 07:20 (UTC)

如果是具有來源件的作品，在主命名空間，我認同你的看法。我傾向將字體、部分排版等元素僅用於在page空間，使其在貼齊原件風格，方便校對時，不至影響最終產出的文本。

但如果是無來源件的作品，這就不好說了。或許貢獻者想要保留一些來自原件的metadata，如用行、楷書表示手抄本，明體表示雕版印刷件，仿宋表示紅頭文件。

這點很見仁見智，目前社群好像還沒一個共識？或許是時候討論一下了。Aerotinge（留言） 2024年12月26日 (四) 07:56 (UTC)

支持，不建议对通篇文章设置字体或过多的格式，默认的字体就行。 Kcx36（留言） 2024年12月26日 (四) 09:28 (UTC)

支持，英文维基文库已有指引Help:Fonts。 Midleading（留言） 2025年1月1日 (三) 12:54 (UTC)

已翻译：Help:字体。英文维基文库有一个“显示选项”的功能，读者可以自己选版面布局和字体（en:Help:Layout），没看懂是怎么实现的。 Kcx36（留言） 2025年1月2日 (四) 11:56 (UTC)

那玩意是英文文庫的特異功能，他們用了個魔改過的小工具並預設打開。起初那只是個顯示頁碼的樣式開關，提供類似於今日行動版與桌面版的差異，經過十幾年的發展後長出更多功能。 Aerotinge（留言） 2025年2月25日 (二) 13:44 (UTC)

支持。-- Ewan0707（留言） 2025年1月1日 (三) 20:40 (UTC)

传统排版中的楷体是为了在宋体上下文中凸显强调，但又不如黑体那样强烈的强调。在中文非衬线体环境下反而显出“弱化”的含义。

理想情况下可以像英文维基文库那样匹配用户选择的上下文样式（我的开发精力暂时有限...），预定义几种模板让用户选择，比如在中文非衬线体环境下加粗、斜体比黑体、楷体的可读性更高；而当用户选择衬线体时，恢复原始文献的楷体、黑体样式。（加粗、斜体正是传统译文排版中尝试体现的原文强调感，但当年铅字排版，准备加粗、倾斜的字模成本过高。）

即使新功能成功落地，也不建议直接改现有模板（批量操作文献），因为我们不能保证所有文献录入者/原作者的目的都是“强调”。还是新建模板逐案修改更为稳妥。 XsLiDian（留言） 2025年2月25日 (二) 10:24 (UTC)

本地版权方针关于合理使用部分的修订

承移动前唯一参与讨论者提议，Teetrition（留言） 2025年1月9日 (四) 05:22 (UTC)自#重写维基文库方针和说明文档独立移动自此

本地版权方针中现有关于合理使用问题的表述繁杂、散乱各处且不符合本地操作实际，一些文字也被删除线划掉，对于新手而言非常不友好。承维基小霸王阁下上方关于重写方针的（随本提议独立成节补充于2025年1月9日 (四) 05:22 (UTC)）提议，同时注意到Wikisource:删除讨论正就Template:KR-political-speech模板涉合理使用问题开展讨论，借此机会，提出对合理使用部分的修订。

提议与对照

現行條文 定义 合理使用（Fair use）：（包括fair dealing和fair practice）这是指在复制版权所有的作品时，无需经过版权所有者同意的权利。这是一项非常有限的权利。 注意事项 3.合理使用一般不适用于大多数维基文库里的文件。合理使用要求按需引用原文，而我们的要求是将原文整体引用，因此，请勿宣称合理使用刊登他人有版权的整篇作品。在通常情况下，合理使用在这里不适用。 合理使用的资料及特殊要求 合理使用要求按需引用原文，而我们的要求是将原文整体引用，因此，請勿宣稱合理使用刊登他人有版權的作品。 所有维基文库的原创文字都是在GFDL下发布的。偶尔，维基文库的文章可能会根据美国版权法所规定的合理使用原则使用一些图像、录音、或转引的文字。这些资料应当尽可能地从那些许可证规定最宽松（比如GFDL或公有领域）的资源获得。但是如果无法找到这类图像/录音，那么合理使用的资料也是可以用的（直到有可以自由使用的资料时为止）。 在这种情况下，应当(在图像描述页或历史页面中)注明该资料是从外部资源获得。由于“合理使用”是否“合理”须根据具体情况判断，因此最好在文章的隐蔽文字中或是在图像描述页解释您是如何运用合理使用原则的。注意，尽管维基文库内所用的资料是在合理使用的原则下使用的，假如您打算将其用于其它情况下，您的使用不一定就符合合理使用的原则。 譬如，如果我们根据合理使用原则在文章中使用了一个图像，您必须确保您对该文的使用也符合合理使用原则（如果您打算把这篇文章用于商业目的，尽管GFDL允许这种情况，属于合理使用的资料却不允许被用于商业用途。因此，您的使用可能就不符合合理使用原则）。 维基文库有时使用一些与GFDL兼容的其它许可证下发布的文字，这些许可证可能有一些维基文库原创文本无须遵守的额外要求（比如要求包含不可变章节（Invariant Sections）, 封面文本（Front-Cover Texts）, 或封底文本（Back-Cover Texts)）。在引用这类资料时，您必须将不可变章节（Invariant Sections）一字不改地引用。 GFDL不禁止商業重製，所以當非商業許可與GFDL不兼容，而且這裡不適合宣稱合理使用時時，請勿刊登僅有非商業許可的他人有版權文章。 版权须知 ……在某些情况下，一个有版权的作品可以在合理使用的原则下使用。…… 合理使用与维基文库里的文字作品 维基文库的目标是在本网站尽可能地发表完整的作品。一般地说，合理使用原则不适用于整部作品的引用，因为就定义而言，整部作品即是作品的“相当大的部分”，而引用一个版权所有的作品的“相当大的部分”，在法庭审理时，是违反合理使用原则的一个主要证据。因此，请勿宣称合理使用刊登他人有版权的作品。 使用有版权的非文字类作品 偶尔，维基文库在合理使用原则下引用了版权所有作品的的一个部分，您应当记录这一事实（包括名字和日期）。我们的目标是使维基文库的内容能尽可能自由地重新发布，因此我们更欢迎那些如此授权的原创作品，而不是在合理使用原则下使用版权所有的作品。 如果您想向一个版权所有人申请将其版权所有的作品在GFDL下发布，请参考Wikipedia:Boilerplate request for permission里的申请信模式。 如果您不能确定您对一个作品的使用是否确实属于合理使用，那么就先不要使用该作品。您应该向版权所有人申请一个允许复制该作品的版权许可证。 请注意，版权法保护的是思想的创造性的表达方式，而不是思想或信息本身。

提議條文 定义 合理使用：在本方针中，指所有不需要著作权人同意，也不需要向著作权人支付报酬，即可使用相关作品的制度。 注意事项 3.在通常情况下，中文维基文库不接受以合理使用为由添加作品。 合理使用（重写“合理使用的资料及特殊要求”一节，建议关于GFDL的其他内容移至他处） 在通常情况下，中文维基文库不接受以合理使用为由添加整篇作品。 合理使用仅适用于引用、媒体报道、传播单篇政治演讲等特定情形。只有满足相关著作权法律规定的特定条件才可以在不需要著作权人同意也不需要向其支付报酬的情况下使用作品——这些特定条件可能包括对作品使用人的限制（例如部分法律规定国家机关可以以公务使用的目的使用作品，然而其他人不可以援引该规定），或是包括对目的的限制（例如部分法律规定可以为私人使用为目的使用作品），也可能包括对传播方式的限制（例如部分法律规定可以传播公开的政治演讲，但不允许汇编），还可能包括对作品使用篇幅的限制（例如法律通常仅允许引用他人作品中的一部分而非全文）。然而，中文维基文库要求贡献的作品与CC BY-SA 4.0相兼容，即允许任何人在任何情景下（但是可以附加署名、相同方式共享等限制）不受著作权限制地使用、复制、创建演绎作品和销售，前述相关合理使用规定显然无法满足这一要求。 以下是一些常见的中文维基文库不接受的合理使用依据： N引用——中文维基文库中贡献的作品原则上应当反映作品的全貌而不接受人为地选取作品的某一个部分进行录入。 N政治演讲、诉讼中发表的言论——伯尔尼保护文学和艺术作品公约第二条之二规定，作者享有将这类作品汇编的权利，然而中文维基文库提供按作者标准等对作品进行分类的功能，这可能被认为是汇编。同时CC BY-SA 4.0也要求被许可人可以创作、复制和分享演绎作品，“演绎作品”包括对授权作品的编排。（参见CC BY-SA 4.0第一条(a)及第二条(a)1.B.）（斜体字加入于2025年1月13日 (一) 16:38 (UTC)以润色连接语句） 惟如部分合理使用能够满足与CC BY-SA 4.0兼容的要求，则可援引。 另一方面，如果某篇作品本身符合“允许任何人在任何情况下不受著作权限制地使用、复制、修改和销售”的要求，只是该作品的作者本身适用了一些合理使用规定，此时便不存在问题，该作品可以贡献到中文维基文库。例如，某作品作者将其作品全文释出到公有领域，只是其作品中适用引用相关的合理使用规定引用了一小部分其他人受著作权法保护的文字。再如，某些国家的司法文书不受著作权法保护，惟法院适用国家机关可以以公务使用的目的使用他人作品的规定在法院判决书中附加了其他人受著作权法保护的作品作为附件。在这些情况下，可以使用模板【待创建，可参考维基共享资源最小限度/微不足道模板】来告知读者该作品中存在单独使用则可能构成侵权的元素。 版权须知 ……在某些情况下，一个有版权的作品可以在合理使用的原则下使用。……（提议删除本句） 合理使用与维基文库里的文字作品 维基文库的目标是在本网站尽可能地发表完整的作品。一般地说，合理使用原则不适用于整部作品的引用，因为就定义而言，整部作品即是作品的“相当大的部分”，而引用一个版权所有的作品的“相当大的部分”，在法庭审理时，是违反合理使用原则的一个主要证据。因此，请勿宣称合理使用刊登他人有版权的作品。（提议整合到新设的“合理使用”一节） 使用有版权的非文字类作品 偶尔，维基文库在合理使用原则下引用了版权所有作品的的一个部分，您应当记录这一事实（包括名字和日期）。我们的目标是使维基文库的内容能尽可能自由地重新发布，因此我们更欢迎那些如此授权的原创作品，而不是在合理使用原则下使用版权所有的作品。（提议整合到新设的“合理使用”一节） 如果您想向一个版权所有人申请将其版权所有的作品在GFDLCC BY-SA 4.0下发布，请参考Wikipedia:Boilerplate request for permission里的申请信模式。 如果您不能确定您对一个作品的使用是否确实属于合理使用，那么就先不要使用该作品。您应该向版权所有人申请一个允许复制该作品的版权许可证。 请注意，版权法保护的是思想的创造性的表达方式，而不是思想或信息本身。

修订理由简述

一、定义中为什么删去“合理使用”的英文？

答：在中文社群中，美国《版权法》第107条之“合理使用”（Fair Use，实际上是在第108-122条中规定的各权利限制情形之外由法官根据第107条所列举的4个要素自由地、开放地裁量对作品的使用是否不构成侵权的制度）与《中华人民共和国著作权法》第24条之“合理使用”、台澎金马地区著作权法“合理使用”（中国大陆和台澎金马实际上是指明文规定的所有不需要取得著作权人同意也不需要支付报酬的各种情形的权利限制制度），二者内涵并不对应。使用“Fair Use”一词可能会使人误解方针的“合理使用”特指美国法第107条之开放式合理使用。方针中的“合理使用”应包括所有不需要著作权人同意，也不需要向著作权人支付报酬，即可使用相关作品的制度。

另可考虑将“合理使用”改为“限制与例外”等称呼，如是，则对提议条文进行批量替换。

二、关于新整合的“合理使用”一节的一些考虑

在维基共享资源存在一些适用不需要取得著作权人同意也不需要支付报酬的权利限制例外（也就是方针中定义的“合理使用”）的情况（下面可能并不是完全列举）：

1. 适用全景自由规定的情况，也就是拍摄建筑、美术等作品并上传或是上传他人拍摄的建筑、美术等作品且该他人拍摄的照片在维基允许的许可证下授权。

2. 适用de minimis（最小限度、微不足道）的情况，也就是照片中受版权保护的部分占整个照片的比例是微不足道的。这在一些国家的著作权法的权利限制制度中有明文规定，通常以“附随性使用”或类似表述出现（例如日本《著作权法》第30条之2，2001年欧盟《信息社会版权指令》（Directive 2001/29/EC）第5条第3款第(i)项（防杠：指令需要转化为国内法适用。该指令的该规定只是说成员国可以而非应当规定附随性使用例外，放在这里只是想说欧盟部分成员国确实有这个规定））。

然而，全景自由规定对于文字作品的适用性非常有限，根据维基共享资源的总结，明确可适用于文字的国家基本与中文关系不大，且其中部分国家要求不得对被适用作品进行破坏性修改、且复制方式限于拍照等适合维基共享资源而不适合中文维基文库的方式（如德国），因此，以上提议条文中未明确指出全景自由问题，而是概括提出“惟如部分合理使用能够满足与CC BY-SA 4.0兼容的要求，则可援引。”

对于“另一方面”一段，则是参照了维基共享资源最小限度和微不足道的原理。

三、关于GFDL的进一步疑问

私以为应当优先鼓励以CC BY-SA进行贡献（而非GFDL），因此对“使用有版权的非文字类作品”一节部分作了对应修改。本站目前是否允许仅GFDL授权的文章新上传到本地？可能需要对版权信息全文中的相关内容进行进一步考虑。

以上提案妥否，同时措辞定有不当之处，还请社群提出。Teetrition（留言） 2025年1月7日 (二) 09:01 (UTC)

抱歉对于GFDL部分忘记此前已参与讨论，但该讨论似乎没有反映到版权信息全文中，因此本次似宜一并修订。 Teetrition（留言） 2025年1月7日 (二) 09:07 (UTC)

讨论区

@Teetrition：在此先感谢阁下辛劳。在此有几点个人意见，也许有些琐碎，如有疏失处多包涵。

1、其实是个题外话，我在想是不是把这（与楼下）件移动到一个独立新话题会较好，可能会更容易引起注意与讨论，毕竟篇幅颇长，收在这话题下的话可能得不到足够的注意。

2、“合理使用”节的一、二段似可合并，大概作在通常情况下，中文维基文库不接受以合理使用为由添加整篇作品。这是因为在各地法律中合理使用仅适用于引用、媒体报道、传播单篇政治演讲等特定情形，...或在通常情况下，中文维基文库不接受以合理使用为由添加整篇作品。这是因为：1、在各地法律中合理使用仅适用...2、然而，中文维基文库要求贡献的...（注：后一种情况，两序号处各另起新缩进）。在下浅见以为，第二段其实是第一段的理由论述，如果按现况陈列，可能有（不仔细的）读者看了首句，以为第二段是在讲“什么情况下可以合理使用”，因此提议作这一更动。

3、“合理使用”节中“CC BY-SA 4.0第一条(a)及第二条(a)1.B.”提议链接到官网那边。

4、我不太确定“合理使用”节中“另一方面”段的说理是否足以覆盖再如，某些国家的司法文书不受著作权法保护，惟法院适用国家机关可以以公务使用的目的使用他人作品的规定在法院判决书中附加了其他人受著作权法保护的作品作为附件；或者说，我想向您了解，“另一方面”段中只是该作品的作者本身适用了一些合理使用规定，此时便不存在问题的描述是否使如关于转发首都儿科研究所附属儿童医院贯彻落实防控“新十条”主要做法的函（PS：原讨论见此）或中共中央关于印发毛泽东同志在扩大的中央工作会议上的讲话的通知的转发、印发对象被收录成为可能。之所以在下持有此疑问，是因为与其作品中适用引用相关的合理使用规定引用了一小部分其他人受著作权法保护的文字这种情况不同地，公务使用会出现全文使用的情况，这样一来，不知是否适宜以“最小限度/微不足道”逻辑来说理——而这种情况又恰是讨论得最多的（小部分节录、引用通常无人疑义，我甚至认为这种情况还不至于要新开模板——可能是因为文字作品的情况如此）。诚然，在下所引述的两例的印发、转发对象大概都不应该视为“附件”而应视为独立作品，但是由于实务中不少公文由于各种原因可能会出现“附件”标识（即使这些标识也许并不准确），以及只是该作品的作者本身适用了一些合理使用规定，此时便不存在问题也可能被用户引用为“只要作者合理使用合规，即使全文使用，这边也没问题”的立论依据，届时应如何对应，是个难题。因此，我想就此进一步了解您在此问题上的看法，即您所指的“附件”，其边界在何。

以上匆匆，多请指正。--银色雪莉（留言） 2025年1月8日 (三) 18:33 (UTC)

@银色雪莉：感谢意见。以下分点回复之：

1. 已移动。

2. 同意。

3. 由于这部分方针本身是从页面里摘出来的，提议时由于不能保证其他部分内容情况，因此对于链接问题似可在正式修改时适当加入。

4. 私认为不足以使阁下所列两件作品的转发、引发对象（被附作品）被收录成为可能，结合此二件受版权保护作品所占比例亦不符合“最小限度”的逻辑。如将提议文字中“附件”改为“判决书的一部分”是否会更好？ Teetrition（留言） 2025年1月9日 (四) 05:31 (UTC)

我想我应该是了解阁下的意思的，尽管如此，请容我再确认一下，“再如”一项，是否指如北京互联网法院（2019）京0491民初1957号民事判决书这种情况。至于表述的话，我倒是考虑，不如这样：

......只是该作品的作者本身适用了一些合理使用规定，且这种适用在作品中呈现的效果被认为是“最小限度/微不足道”时，则该作品可以贡献到中文维基文库。......再如，某些国家的司法文书不受著作权法保护，惟法院适用国家机关可以以公务使用的目的使用他人作品的规定，将其他受著作权法保护的作品以非独立主体形式附加在法院判决书中。在这些情况下，在录入这些作品时，应使用模板【待创建，可参考维基共享资源最小限度/微不足道模板】来告知读者该作品中存在单独使用则可能构成侵权的元素。

其中，“被认为”一词的加入是想保留共识决的空间，以免拿着这条硬顶牛的情况出现。PS：加黑体只是突出，并非最终想要这种效果，在下在非黑体处也有个别调整。其实我主要还是担忧哪的机关脑子一热附加了个不知道啥2333 银色雪莉（留言） 2025年1月9日 (四) 14:07 (UTC)

向阁下确认，阁下所举北京互联网法院（2019）京0491民初1957号民事判决书，是否属于将其他受著作权法保护的作品以非独立主体形式附加在法院判决书中？其实对于中国大陆的法院判决书而言，所附的内容（或者说所引用的内容）可能写在判决正文里，也可能在落款之后另附页从而显得与判决更为独立。就拿商标行政案件来说，北京知识产权法院在前几年可能偏向把争议商标的图案放到判决落款之后另附页，最近偏向直接放到正文的事实部分——实质上两种形式起到的都是相同的作用。但是“非独立主体形式”或许可能存在一些理解上的困难？例如部分人可能会认为落款之后另附页的就是“独立主体形式”？Teetrition（留言） 2025年1月10日 (五) 02:44 (UTC)

仅就“非独立主体形式”而言我觉得是属于的，但其实像您提到的“放到正文的事实部分”这种我好像也有看过，一下子记得不太清楚了，像是某个游戏公司相关的案例，展示了一些游戏页面之类的。理解上的困难这我同意，我自己也没有很好的写法思路（我还考虑过不少定语，但感觉愈显累赘，因此作罢），只是姑且一提，希望碰撞一下。 银色雪莉（留言） 2025年1月10日 (五) 04:34 (UTC)

「合理使用」稱呼不必改易，說明含義即可。—— Eric Liu_（留言） 2025年1月9日 (四) 08:06 (UTC)

感謝閣下的修訂提議，能否一并審定或更新其他有關合理使用和GFDL的頁面和模板？

合理使用：

• Wikisource:請求文本
• Help:如何提交文章
• Help:給維基百科人的入門

GFDL：

• Wikisource:版权信息/全文#使用者的权利与义务 的其餘段落
• Template:原文沒有標點
• Template:Copyvio
• Wikisource:专题/法律#大韓民國法律

Andayunxiao（留言） 2025年1月11日 (六) 17:39 (UTC)

谢谢阁下提议。关于GFDL部分，由于此前已经有过讨论，似乎可以直接执行？关于合理使用部分，由于我本次新提议了法院判决书引用受保护内容等的提案，似宜等待本次提案通过后一并修改。无论如何，对于阁下所给任一一个页面，我目前暂时先等待一段时间后再行行动。 Teetrition（留言） 2025年1月13日 (一) 02:30 (UTC)

閣下和社群可決定，非高優先級任務，可後續再審視。 Andayunxiao（留言） 2025年1月13日 (一) 16:18 (UTC)

公示

春节假期已过，考虑到本提案截至目前并未有明显反对意见，对提案文本公示如下：

現行條文 定义 合理使用（Fair use）：（包括fair dealing和fair practice）这是指在复制版权所有的作品时，无需经过版权所有者同意的权利。这是一项非常有限的权利。 注意事项 3.合理使用一般不适用于大多数维基文库里的文件。合理使用要求按需引用原文，而我们的要求是将原文整体引用，因此，请勿宣称合理使用刊登他人有版权的整篇作品。在通常情况下，合理使用在这里不适用。 合理使用的资料及特殊要求 合理使用要求按需引用原文，而我们的要求是将原文整体引用，因此，請勿宣稱合理使用刊登他人有版權的作品。 所有维基文库的原创文字都是在GFDL下发布的。偶尔，维基文库的文章可能会根据美国版权法所规定的合理使用原则使用一些图像、录音、或转引的文字。这些资料应当尽可能地从那些许可证规定最宽松（比如GFDL或公有领域）的资源获得。但是如果无法找到这类图像/录音，那么合理使用的资料也是可以用的（直到有可以自由使用的资料时为止）。 在这种情况下，应当(在图像描述页或历史页面中)注明该资料是从外部资源获得。由于“合理使用”是否“合理”须根据具体情况判断，因此最好在文章的隐蔽文字中或是在图像描述页解释您是如何运用合理使用原则的。注意，尽管维基文库内所用的资料是在合理使用的原则下使用的，假如您打算将其用于其它情况下，您的使用不一定就符合合理使用的原则。 譬如，如果我们根据合理使用原则在文章中使用了一个图像，您必须确保您对该文的使用也符合合理使用原则（如果您打算把这篇文章用于商业目的，尽管GFDL允许这种情况，属于合理使用的资料却不允许被用于商业用途。因此，您的使用可能就不符合合理使用原则）。 维基文库有时使用一些与GFDL兼容的其它许可证下发布的文字，这些许可证可能有一些维基文库原创文本无须遵守的额外要求（比如要求包含不可变章节（Invariant Sections）, 封面文本（Front-Cover Texts）, 或封底文本（Back-Cover Texts)）。在引用这类资料时，您必须将不可变章节（Invariant Sections）一字不改地引用。 GFDL不禁止商業重製，所以當非商業許可與GFDL不兼容，而且這裡不適合宣稱合理使用時時，請勿刊登僅有非商業許可的他人有版權文章。 版权须知 ……在某些情况下，一个有版权的作品可以在合理使用的原则下使用。…… 合理使用与维基文库里的文字作品 维基文库的目标是在本网站尽可能地发表完整的作品。一般地说，合理使用原则不适用于整部作品的引用，因为就定义而言，整部作品即是作品的“相当大的部分”，而引用一个版权所有的作品的“相当大的部分”，在法庭审理时，是违反合理使用原则的一个主要证据。因此，请勿宣称合理使用刊登他人有版权的作品。 使用有版权的非文字类作品 偶尔，维基文库在合理使用原则下引用了版权所有作品的的一个部分，您应当记录这一事实（包括名字和日期）。我们的目标是使维基文库的内容能尽可能自由地重新发布，因此我们更欢迎那些如此授权的原创作品，而不是在合理使用原则下使用版权所有的作品。 如果您想向一个版权所有人申请将其版权所有的作品在GFDL下发布，请参考Wikipedia:Boilerplate request for permission里的申请信模式。 如果您不能确定您对一个作品的使用是否确实属于合理使用，那么就先不要使用该作品。您应该向版权所有人申请一个允许复制该作品的版权许可证。 请注意，版权法保护的是思想的创造性的表达方式，而不是思想或信息本身。

提議條文 定义 合理使用：在本方针中，指所有不需要著作权人同意，也不需要向著作权人支付报酬，即可使用相关作品的制度。 注意事项 3.在通常情况下，中文维基文库不接受以合理使用为由添加作品。 合理使用（重写“合理使用的资料及特殊要求”一节，建议关于GFDL的其他内容移至他处） 在通常情况下，中文维基文库不接受以合理使用为由添加整篇作品。这是因为在各地法律中合理使用仅适用于引用、媒体报道、传播单篇政治演讲等特定情形。只有满足相关著作权法律规定的特定条件才可以在不需要著作权人同意也不需要向其支付报酬的情况下使用作品——这些特定条件可能包括对作品使用人的限制（例如部分法律规定国家机关可以以公务使用的目的使用作品，然而其他人不可以援引该规定），或是包括对目的的限制（例如部分法律规定可以为私人使用为目的使用作品），也可能包括对传播方式的限制（例如部分法律规定可以传播公开的政治演讲，但不允许汇编），还可能包括对作品使用篇幅的限制（例如法律通常仅允许引用他人作品中的一部分而非全文）。然而，中文维基文库要求贡献的作品与CC BY-SA 4.0相兼容，即允许任何人在任何情景下（但是可以附加署名、相同方式共享等限制）不受著作权限制地使用、复制、创建演绎作品和销售，前述相关合理使用规定显然无法满足这一要求。 以下是一些常见的中文维基文库不接受的合理使用依据： N引用——中文维基文库中贡献的作品原则上应当反映作品的全貌而不接受人为地选取作品的某一个部分进行录入。 N政治演讲、诉讼中发表的言论——伯尔尼保护文学和艺术作品公约第二条之二规定，作者享有将这类作品汇编的权利，然而中文维基文库提供按作者标准等对作品进行分类的功能，这可能被认为是汇编。同时CC BY-SA 4.0也要求被许可人可以创作、复制和分享演绎作品，“演绎作品”包括对授权作品的编排。（参见CC BY-SA 4.0第一条(a)及第二条(a)1.B.） 惟如部分合理使用能够满足与CC BY-SA 4.0兼容的要求，则可援引。 另一方面，如果某篇作品本身符合“允许任何人在任何情况下不受著作权限制地使用、复制、修改和销售”的要求，只是该作品的作者本身适用了一些合理使用规定，此时便不存在问题，该作品可以贡献到中文维基文库。例如，某作品作者将其作品全文释出到公有领域，只是其作品中适用引用相关的合理使用规定引用了一小部分其他人受著作权法保护的文字。再如，某些国家的司法文书不受著作权法保护，惟法院适用国家机关可以以公务使用的目的使用他人作品的规定在法院判决书中附加了少许其他人受著作权法保护的作品。在这些情况下，可以使用模板【模板见下】来告知读者该作品中存在单独使用则可能构成侵权的元素。 版权须知 ……在某些情况下，一个有版权的作品可以在合理使用的原则下使用。……（提议删除本句） 合理使用与维基文库里的文字作品 维基文库的目标是在本网站尽可能地发表完整的作品。一般地说，合理使用原则不适用于整部作品的引用，因为就定义而言，整部作品即是作品的“相当大的部分”，而引用一个版权所有的作品的“相当大的部分”，在法庭审理时，是违反合理使用原则的一个主要证据。因此，请勿宣称合理使用刊登他人有版权的作品。（提议整合到新设的“合理使用”一节） 使用有版权的非文字类作品 偶尔，维基文库在合理使用原则下引用了版权所有作品的的一个部分，您应当记录这一事实（包括名字和日期）。我们的目标是使维基文库的内容能尽可能自由地重新发布，因此我们更欢迎那些如此授权的原创作品，而不是在合理使用原则下使用版权所有的作品。（提议整合到新设的“合理使用”一节） 如果您想向一个版权所有人申请将其版权所有的作品在GFDLCC BY-SA 4.0下发布，请参考Wikipedia:Boilerplate request for permission里的申请信模式。 如果您不能确定您对一个作品的使用是否确实属于符合本方针要求的合理使用，那么就先不要使用该作品。您应该向版权所有人申请一个允许复制该作品的版权许可证。 请注意，版权法保护的是思想的创造性的表达方式，而不是思想或信息本身。

较此前版本修订之处：

1. 接受了银色雪莉阁下的意见第2点；
2. 惟法院适用国家机关可以以公务使用的目的使用他人作品的规定在法院判决书中附加了其他人受著作权法保护的作品作为附件改为惟法院适用国家机关可以以公务使用的目的使用他人作品的规定在法院判决书中附加了少许其他人受著作权法保护的作品；
3. 如果您不能确定您对一个作品的使用是否确实属于合理使用顺带改为如果您不能确定您对一个作品的使用是否确实属于符合本方针要求的合理使用。

最小限度模板参考c:Template:De minimis拟文案如下。考虑到本部分系首次草拟，如有不同意见可单独再行公示。

副知参与各讨论人员，如有打扰请见谅：@银色雪莉, Ericliu1912, Andayunxiao

同时，本次修订私以为并未对社群任何实践造成实质性影响。

Teetrition（留言） 2025年2月13日 (四) 09:31 (UTC)

看起來沒有問題。—— Eric Liu_（留言） 2025年2月13日 (四) 12:32 (UTC)

连同模板均 支持。 银色雪莉（留言） 2025年2月13日 (四) 14:44 (UTC)

 支持完善條文。版權細則因不瞭解，沒有更多意見。 Andayunxiao（留言） 2025年2月13日 (四) 16:33 (UTC)

提個問題，{{Indent_pars}}模板中的說明文件，其所用的範例是否會造成影響？ Aerotinge（留言） 2025年2月18日 (二) 15:10 (UTC)

窃以为采用版权作品的片段且只是为了展示排版效果，不属于多数国家引用之合理使用具有批评、介绍等目的的要求，属于侵权，需要修改并请管理员删除历史。 Teetrition（留言） 2025年2月19日 (三) 05:06 (UTC)

已提交版权讨论。 Teetrition（留言） 2025年2月19日 (三) 10:00 (UTC)

结果

完成：已对应修改。请检查修订与模板的创建。 Teetrition（留言） 2025年2月23日 (日) 10:21 (UTC)

這是什麼字？（2025年）

一

原文：「則吾等之死不⾜惜國家⼤事從此�矣」

原圖：[1] 冊一pg 41

這個字是「解」，「觧」，還是「鮮」？

可參考《朝鮮王朝實錄·成宗實錄·二十二年》：「彼人過行馬跡未久，彼人若還來見吾等馬跡，尋蹤扼其歸路，則吾等之死不足惜，國家大事不諧矣。」

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月11日 (六) 13:47 (UTC)

@Liouxiao@银色雪莉 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月12日 (日) 02:35 (UTC)

我觉得是“解”——瓦解。或者通“懈”。 Liouxiao（留言） 2025年1月12日 (日) 02:56 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月12日 (日) 03:04 (UTC)

二

原文：「非樂事也㦲�禱之辭䂓戒之義略」

原圖：[2] 25a

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月16日 (四) 03:05 (UTC)

這個字是不是「頌」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月16日 (四) 03:06 (UTC)

應該是的，字形合理，“頌禱”也是合理的。 银色雪莉（留言） 2025年1月16日 (四) 16:24 (UTC)

（按年度分拆討論，並重新編號）—— Eric Liu_（留言） 2025年1月17日 (五) 16:22 (UTC)

三

原文：「乎杖訊服義供柳順汀三⼨姪完川正�問順」

原圖：[3] page 46 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月23日 (四) 01:06 (UTC)

算了，我看了一下歷史文獻，得到結果是「禧」。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月23日 (四) 01:12 (UTC)

四

原文：「有⼀男四女男諱時英女長適田�」pg44

「年⼄巳墓與公袝⼀男時英四女⽥�」pg46

「⼦四女男曰時英女長適⽥�」pg49

原圖：[4]

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月30日 (四) 02:11 (UTC)

我懷疑是「渫」，但是歡迎大家討論。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月30日 (四) 02:12 (UTC)

@Liouxiao@银色雪莉 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月3日 (一) 13:24 (UTC)

像是「滦」的異體字 Liouxiao（留言） 2025年2月4日 (二) 08:26 (UTC)

似乎朝鮮文獻中也有數個與此字右半部類似的寫法，參見[5]和[6]，不知何故我打不開韓國歷史情報統合系統的網站，但從字統網抓下來的例句看，第一條中“古▼圍”的僻字解作“堞”和第二條中“有⊙闡者”的僻字解作“牒”似乎並無不通處，若照此推論，則同右半部的本件此字作“渫”似無不可；何況，右上部的結構視作“世”的異體似也無不可，若這樣看，則也是可以接受的。但話又說回來，本件是人名，無法以前後文檢測文意，因此在下未敢過多推測。 银色雪莉（留言） 2025年2月4日 (二) 10:14 (UTC)

看來是的，參考 https://zht.glyphwiki.org/wiki/u2ff0-u6c35-u2da60-var-001 ，應作「渫」的異體字。 Liouxiao（留言） 2025年2月4日 (二) 11:32 (UTC)

https://zht.glyphwiki.org/wiki/u2ff0-u6c35-u2ff3-u5341-u51f5-u6728 Liouxiao（留言） 2025年2月4日 (二) 11:46 (UTC)

五

原文：「闻夫豈塗�道說之比」pg 6

「余以老洫辤。不�」pg 9

原圖：[7] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月30日 (四) 22:56 (UTC)

其他的部分是根據《拓菴集》填寫的。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月30日 (四) 22:57 (UTC)

闻夫豈塗聼道說之比；

余以老洫辤不獲。

兩字俱為草書。 Liouxiao（留言） 2025年2月4日 (二) 11:55 (UTC)

前句見 拓菴先生文集/卷十三#林晩聞遺集序，後句見 拓菴先生文集/續卷之六#三友堂李公文集序。 Liouxiao（留言） 2025年2月4日 (二) 12:00 (UTC)

六

原文：「追事怪於▦▦。接」pg 65

原圖：[8] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月5日 (三) 02:20 (UTC)

各本子都很糊，似乎也不是熟语，恐无从推断。 银色雪莉（留言） 2025年2月5日 (三) 05:08 (UTC)

是孝武吧，太初不是刘彻年号吗，汉武帝太初改历。—— Zzhtju（留言） 2025年2月6日 (四) 11:39 (UTC)

感謝！！！！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月7日 (五) 00:20 (UTC)

七

原文：「龍蛇⽽鬪風霆卒⽌於正者？臺下之⽔當」pg 138

[9] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月14日 (五) 21:18 (UTC)

這個字是不是「是」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月14日 (五) 21:19 (UTC)

@Blahhmosh：不要这样删改原有发言，这是不合规的。要发新提问时，请照以前一样开新话题。本件而言，这是“是”字没错。--银色雪莉（留言） 2025年2月15日 (六) 04:45 (UTC)

我沒有刪改原有的發言。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月15日 (六) 04:46 (UTC)

等等，我確實是不小心刪改了！對不起。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月15日 (六) 04:47 (UTC)

@Blahhmosh：没事，不打紧，我猜也是这样，无心之失，请不必太在意，此后注意就好了，我主要是怕存档不准确和信息丢失引起误会，所以特地提醒。--银色雪莉（留言） 2025年2月15日 (六) 04:50 (UTC)

八

原文：「揖我謂我儇而狂。人生快▦何所好。」

原圖：[10] 70

[11] 68

[12] 69

[13] (靑泉集) 册一頁139

（靑泉集. 卷1, 2, 4, 6/ 申維翰(朝鮮) 著） 册二頁30

（靑泉集. [1]）pg136 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月16日 (日) 06:59 (UTC)

我找到了新的文字來源[14] 16 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月19日 (三) 23:57 (UTC)

@Aerotinge@Andayunxiao@Liouxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 01:47 (UTC)

還是不清楚，謹慎推測為“意”字。 Liouxiao（留言） 2025年4月4日 (五) 10:00 (UTC)

九

原文：「分。淸言殊未了。騎馬曉鍾聞。〈▦▦〉」

原圖：[15] 339

[16] 47a 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月16日 (日) 17:52 (UTC)

我認為第二個字是「暢」或者是「蜴」。你們呢？

@Aerotinge@Liouxiao@Andayunxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月5日 (三) 05:50 (UTC)

[17] 94 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月5日 (三) 05:51 (UTC)

第一個字是「鍊」或者「錊」？ Liouxiao（留言） 2025年3月5日 (三) 15:25 (UTC)

十

原文：「執筆具稿者如�偶扵廢謝閒」

原圖：Page:KYTU-BB04492447 督戎疏紀1.pdf/5

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

@银色雪莉 @DuckSoft @Liouxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月18日 (二) 15:41 (UTC)

@Blahhmosh：“干”。“如干”，义同“若干”。 银色雪莉（留言） 2025年2月18日 (二) 17:03 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月18日 (二) 17:21 (UTC)

十一

玉屏摹出之其巾爲筐圍若石鼓文者頗多如�
���之類而作�之字一方中至四五見又有
似鳥者作�有似馬者作�亦有竟作馬首者有
似眉眼者作�或作�或作�或作�或作�有
似爪者作�其竟類今篆者如�������
���其柱不知始何時埃及流傳古有賢后克

我從沒料想到會在古籍裡錄到埃及象形文字，今天算開了眼界了。這該怎麼處理？ Aerotinge（留言） 2025年2月19日 (三) 07:44 (UTC)

找到两个：𓃒𓆆。--維基小霸王（留言） 2025年2月20日 (四) 01:46 (UTC)

左邊第二行倒數第三字是否是「𓂯」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:05 (UTC)

或者是「𓏥」、「𓏦」、「𓏼」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:10 (UTC)

右邊第三行的第一個說是像鳥，所以這裡或許會有你的字：[18] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:12 (UTC)

同行第二個說是像馬，所以「𓃗」有可能是。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:13 (UTC)

中間那一行有諸多的像眼的字符，[19] 可能會有你想要的。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:15 (UTC)

還有一個說是像爪的字符，可能是「𓆆」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月20日 (四) 20:16 (UTC)

十二

原文：「情私矢百歲⽽不替微�悃愊祝遐壽之無疆不」

原圖：[20] pg 108 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月22日 (六) 15:49 (UTC)

我極為懷疑這個字是「微」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月22日 (六) 15:54 (UTC)

@Blahhmosh：“微”。“區區...微微...”，典型的駢文。 银色雪莉（留言） 2025年2月22日 (六) 16:59 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月22日 (六) 17:03 (UTC)

十三

原文：「之間㦲撫昔悼今尤不⾃勝敬以洞酌枯�少叙」

原圖：[21] pg 112 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月23日 (日) 04:49 (UTC)

查不到，不過「洞酌」應作「泂酌」，為《詩經．大雅》中的一篇。

故揣測「枯�原字未收錄於Unicode，結構：⿰月𬎾」應該也是某部作品，或許可往敬酒祝詞之類方向找起。 Aerotinge（留言） 2025年2月23日 (日) 05:24 (UTC)

「𬎾」同「肅」，所以根據字形結構可能是「䐹」。但是到底恰當麼？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月23日 (日) 05:46 (UTC)

@Aerotinge 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月24日 (一) 04:50 (UTC)

我不覺得可以這樣替換。

如果非不得已要這麼做，至少要留下編輯說明，並以模板加註。 Aerotinge（留言） 2025年2月24日 (一) 04:56 (UTC)

“枯䐹”--《元詩選•食新笋》：“黄虀瓮已竭，枯䐹筐亦空。” Liouxiao（留言） 2025年4月4日 (五) 10:09 (UTC)

十四

原文：「豈外貌爲焉趂㬻社之芳辰�炊釀扵餘⽣任農」

原圖：[22] pg 16

[23] pg 16

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月26日 (三) 22:02 (UTC)

我懷疑這個字是「足」，你們呢？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月26日 (三) 23:29 (UTC)

个人认为是的。 银色雪莉（留言） 2025年2月27日 (四) 02:36 (UTC)

十五

原文：「▦穆盤遊則雪死人。天」

原圖：[24] 83

是不是「周」？大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 15:03 (UTC)

原文：「惟玆▦雪。是誰之力。」

原圖同上

是不是「之」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 15:04 (UTC)

原文：「。品物閉塞。▦▦者斂其液。振奮者蟄」

原圖：[25] 87 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 16:16 (UTC)

「敷榮」者歛其液

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月2日 (日) 16:24 (UTC)

感謝！！！！！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 16:29 (UTC)

十六

原文：「書？釀春壽勺酙瓊液愛」

原圖：[26] 14 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 18:55 (UTC)

@Andayunxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 19:34 (UTC)

可能是「⿰韋巾」，未查到此字，可能是「幃」的異體。證據1：書幃=书斋，書房。證據2，見信菴遺稿/卷之一，此詩「和朴僉使成浩秀連回甲韻二⾸〇丙寅」。如果是「幃」，此詩1，2，4，6，8句末字為「歸幃衣肥希」，都在平水韻的上平聲部五微，押韻。 Andayunxiao（留言） 2025年3月2日 (日) 20:09 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月2日 (日) 20:28 (UTC)

十七

原文：「⽤蜃齒顧抽峯⼀？氣爽頭有整可由」

原圖：[27] 37

這個字是不是「衷」或「裒」？大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月4日 (二) 00:50 (UTC)

算了，是「裒」。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月4日 (二) 04:17 (UTC)

十八

原文：「嗚呼恭惟尊公㧞類卓絕性度慈惠氣宇？？」

原圖：[28] 66

這個字是不是「炯澈」？大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月7日 (五) 01:48 (UTC)

应该没错，字迹大体可辨。 银色雪莉（留言） 2025年3月7日 (五) 02:08 (UTC)

十九

原文：「常好靜坐如禪入定警咳不出閭⾥肅淸畏惡若？⾒賢必慕擇地」

原圖：[29] 72

這個字是「凂」還是「免」？大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月7日 (五) 12:58 (UTC)

“凂”，同“浼”，污染。“畏惡若凂，見賢必慕”，是为呼应。 银色雪莉（留言） 2025年3月7日 (五) 17:09 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月7日 (五) 17:22 (UTC)

二十

原文：「此以上即王？秋間事而此公之」

原圖：[30]

[31]

[32] pg 101 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月10日 (一) 13:58 (UTC)

@Andayunxiao@银色雪莉@Liouxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月10日 (一) 17:49 (UTC)

算了，是「成」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月10日 (一) 21:37 (UTC)

应该是“壬戌”，干支纪年——「此以上即壬戌秋間事而此公之」。

苏轼《前赤壁賦》开头：“壬戌之秋，……” Liouxiao（留言） 2025年3月11日 (二) 06:03 (UTC)

赞成Liouxiao君的观点，“戌”显然。 银色雪莉（留言） 2025年3月11日 (二) 08:47 (UTC)

感謝！！！！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月11日 (二) 13:59 (UTC)

二十一

原文：「環成丈？書⽣乆抱經綸志起舞龍泉壮懷發墨⾊」

原圖：[33] pg 3

這個字是不是「正」或者是「疋」？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月18日 (二) 03:26 (UTC)

“疋”，字形显然。“丈”和“疋”都是计算布匹长度的单位，此处用作布匹代指；“但覺廽環成丈疋”，回环，穿梭往复，可指织布的动作，则上下匹配。 银色雪莉（留言） 2025年3月18日 (二) 06:22 (UTC)

二十二

原文：「蘭玉盈▦佇餘慶」

原圖：[34] pg 57

[35] pg 93

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月19日 (三) 16:53 (UTC)

“庭”。“蘭玉盈庭”，語源該是《世說新語》謝玄說的“譬如芝蘭玉樹，欲使其生於階庭耳”，通常說的是子弟優秀。--银色雪莉（留言） 2025年3月19日 (三) 17:42 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月19日 (三) 17:50 (UTC)

原圖：[36] pg 48

[37] pg 84

原文：「傳家猶得托精▦。」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月19日 (三) 16:57 (UTC)

似乎是“禋”字 ---以禮祭祀：“禮者……，況國之大典，在于精禋……”。 Liouxiao（留言） 2025年4月4日 (五) 09:57 (UTC)

二十三

原文：「冥漠長辭▦得計」

原圖：[38] pg 95

[39] pg 130

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月19日 (三) 17:07 (UTC)

從殘留字形看似乎是“誠”字。 Liouxiao（留言） 2025年4月4日 (五) 09:44 (UTC)

二十四

原文：「前日。上敎曰。領相非但功勞甚重。且無入接家舍云。籍沒家舍中一坐。▦自願題」

原圖：[40] 13

[41] 287

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 01:48 (UTC)

上面的那個我認為是「從」

原文：「心▦不能自定。罔」

[42] 38

[43] 312 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 01:53 (UTC)

會不會是「神」阿？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 01:54 (UTC)

心神不能自㝎 Liouxiao（留言） 2025年4月4日 (五) 09:24 (UTC)

个人同意阁下所见，是“從”和“神”。 银色雪莉（留言） 2025年3月20日 (四) 12:54 (UTC)

二十五

原文：「閣閣殊音入耳喧。�有山河堪寓目。」

原圖：[44] 53

[45] 47

[46] 52

這個字是不是「只」？大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 02:56 (UTC)

是的。 Liouxiao（留言） 2025年4月4日 (五) 09:10 (UTC)

二十六

原文：「秖今縻吏役。訖▦▦餘生。」

原圖：[47] 78

[48] 73

[49] 76 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:00 (UTC)

「秖今縻吏役。訖可丐餘生。」 Liouxiao（留言） 2025年4月4日 (五) 09:21 (UTC)

原文：「長歌自作風格▦。句法還向東坡」

原圖：[50] 86

[51] 84

[52] 80 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:03 (UTC)

字形上看應該是“老”，“長歌自作風格老”，見杜甫蘇端薛復筵簡薛華醉歌：“歌辭自作風格老”。--银色雪莉（留言） 2025年3月20日 (四) 13:14 (UTC)

二十七

原文：「榮養雄州備。▦封晩歲新。」

這個字是不是「㤙」？

原圖：[53] 108

[54] 19

[55] 23 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:07 (UTC)

[56] 21

[57] 110

[58] 25

原文：「其如喜▦情。慇懃別時」

這個字是不是「悞」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:09 (UTC)

原文：「神明政▣琴」

這個字是不是「左」、或者說「右」？

[59] 21

[60] 105

[61] 17 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 17:06 (UTC)

第一条是“㤙”，字形明显。

第三条是“在”，“風化民如草，神明政在琴”，上句是《論語》“君子之德，風；小人之德，草；草上之風，必偃。”的化用，下句大抵与“鳴琴而治”一样，两句说的都是以德化民以礼乐教民的意思。 银色雪莉（留言） 2025年3月20日 (四) 19:20 (UTC)

🙏感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:30 (UTC)

二十八

原文：「徐劍掛來身更遠。郢斤▦却質今亡」

是不是「拋」？

原圖：[62] 122

[63] 33

[64] 37 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:27 (UTC)

原文：「 四州八島皆▦中諸州 」

原圖：[65] 45

[66] 133

[67] 49 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:38 (UTC)

原文：「吾黨諸君強起余。▦▦仍向漢皐如」

[68] 74

[69] 70

[70] 158 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 03:41 (UTC)

个人意见：“抛”、“海”、“夭魚” 银色雪莉（留言） 2025年3月20日 (四) 12:44 (UTC)

二十九

原文：「郊墅省愆甘▦跡。」

原圖：[71] 187

[72] 28

[73] 29

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 14:37 (UTC)

[74] 188

[75] 30

[76] 29

原文：「一中無賴酒熏▦。分憂列邑」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 14:39 (UTC)

腷？ Zzhtju（留言） 2025年4月4日 (五) 15:59 (UTC)

感謝，但是我查看了一下，應該是「肌」。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年4月4日 (五) 19:09 (UTC)

屏？ Zzhtju（留言） 2025年4月4日 (五) 15:22 (UTC)

感謝！！！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年4月4日 (五) 19:05 (UTC)

三十

原文：「易水長城。�終爲秦之有乎。」

這個字是不是「其」？

原圖：[77] 191

[78] 31

[79] 32 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:03 (UTC)

原文：「諸侯將相咸▦。動歡聲於大庭」

這個字是不是「在」，還是「推」？

[80] 31

[81] 33

[82] 192 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:07 (UTC)

第一條，“其”是合理的，字形也可接受；第二條，個人認為是“在”，字形合理，“諸侯將相咸在”和後文“動歡聲於大庭，溢和氣之藹藹”文理也接得上。另，此句中“侯”應更換為𫢑，“侯”的異體字，以符合原貌。--银色雪莉（留言） 2025年3月20日 (四) 19:33 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:44 (UTC)

三十一

原文：「笑謂座▦曰。彼妓之流涕。」

原圖：[83] 64

[84] 54 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:45 (UTC)

已解決。「客」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 23:08 (UTC)

三十二

原文：「塞馬寧嫌▦。仙鳬亦懶飛。」

原圖：[85] 43

[86] 119 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 19:53 (UTC)

已解決。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月20日 (四) 23:08 (UTC)

三十三

原文：「峕。崇禎乙丑�月初吉南溪朴世采和�曰題」

第一字我深度懷疑是「臈」，但是第二個字是什麼？「叔」？「井」？「壯」？

原圖：[87] pg 4 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月22日 (六) 22:26 (UTC)

算了，是「叔」。朴世采，字「和叔」。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月22日 (六) 22:51 (UTC)

三十四

原文：「東風拂征袖離思颯秋莖好去尋初服終知？汝成」

這是「王」，還是「玉」？

原圖：[88] pg 36 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月31日 (一) 13:35 (UTC)

是“玉”应该无误，毕竟“玉汝于成”。 银色雪莉（留言） 2025年3月31日 (一) 14:30 (UTC)

感謝！ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月31日 (一) 14:35 (UTC)

彩色影印庚辰本石頭記之錄入樣式和規則尋求共識

感謝社群關注和協作。同一作品的校對頁應遵循大致相同樣式（模板，標點），並有確定的錄字標準（異體字？旁改文字？）。 我已自行校對第19回和20回，並希望分享自己的格式手冊。現剛剛向文庫錄入第19回的一半，但想要先尋求共識討論，再繼續任何新頁面的錄入。 如複數編者希望貢獻，是否可以建立專題討論？

提請所有貢獻者參與討論：@Liouxiao：

相關索引：

• 索引:ISBN978-7-5013-6272-1 脂硯齋重評石頭記庚辰本 1.pdf
• 索引:ISBN978-7-5013-6272-1 脂硯齋重評石頭記庚辰本 2.pdf

Andayunxiao（留言） 2025年1月13日 (一) 16:33 (UTC)

以下是我采用的樣式或原則，供討論：

1. 關於紅色批注，因第一冊影印本（PDF）大部分為黑白，所以無從判斷哪些段落為紅色批注，只好參照脂硯齋重評石頭記判別，對於“紅批”部分的行使用Template:紅模板，見Page:ISBN978-7-5013-6272-1_脂硯齋重評石頭記庚辰本_1.pdf/30；

2. 關於雙行注解，個人認爲Template:DL要優於Template:Iac，可以縮小字體、並居中顯示，參見Page:ISBN978-7-5013-6272-1_脂硯齋重評石頭記庚辰本_2.pdf/188；（注：需要在styles.css中加上字體的高度修正）；

3. 關於標點符號，建議用onlyinclude,這樣在Page竪排頁面不顯示標點，在引用的頁面可以顯示標點，見脂硯齋重評石頭記_(庚辰本)/第02回。 Liouxiao（留言） 2025年1月14日 (二) 01:39 (UTC)

感謝閣下回復樣式：我已在下面討論説明對原文顔色的看法。回復2和3：

2. Template:Iac 亦可通過校對頁樣式修改字體，居中（閣下和社群可在索引頁樣式頁試驗）。惟此模板試圖兼顧直排和橫排，實現橫排下批語順序單行顯示，適應寬度換行。橫排下的草樣可參見我的沙盒頁User:Andayunxiao/sandbox，可更改瀏覽器寬度，或在小尺寸設備上查看其效果。和「竪排原文嵌入橫排顯示環境后每行單列」的目標不同。

3. 我尊重閣下不顯示標點的偏好。我也想指出，給每組標點都標記onlyinclude標簽或圍繞模板，無助於編者在page 頁面的文本編輯器編輯源碼，且易出錯。Page頁面是服務編者多於讀者，我理解有編者在Page頁面的生成頁面對照校對，希望行款整齊，但也有編者在文本編輯頁和源碼上比對。很遺憾，此二者不能兼顧是技術限制，我們使用的MediaWiki 軟件并非為中文古籍特制，非哪種偏好孰優孰劣。 Andayunxiao（留言） 2025年1月14日 (二) 16:13 (UTC)

閣下沙箱頁的橫排示例確實不錯，維如果能將竪排顯示也優化則更佳。 Liouxiao（留言） 2025年1月15日 (三) 01:56 (UTC)

感謝閣下美言。已經調整樣式，使雙行批語貼近閣下在188頁所示。{{Iac}}模板還需修改，如，第二行為空時也應顯示固定高度。更多細節還請指點。 Andayunxiao（留言） 2025年1月16日 (四) 16:25 (UTC)

請問是否有修改後的“雙行批語”直排|竪排示例？ Liouxiao（留言） 2025年1月20日 (一) 00:44 (UTC)

已在索引頁樣式頁修改。現169頁起即爲更改後樣式。 Andayunxiao（留言） 2025年1月20日 (一) 14:45 (UTC)

標點錄入是否可以推遲，即，以每一回為單位，待一回的有共識的頁面内容全部錄入，或編者執行首次校對時或之後，再按閣下的樣式補加標點？這樣兼顧最終的樣式，也方便各種偏好的編者參與編輯。閣下和社群更可開發機器人錄入標點。此外，頁面錄入也可拆分步驟，如，錄入未編碼字的資訊不易，其他編者可忽略此步，僅錄正字或留白（即錄入{{UnO|字|}}），本人隨後追加。各編者可僅錄字，僅校對批語樣式等。可在專題頁記錄各回各步的進度。 Andayunxiao（留言） 2025年1月16日 (四) 16:40 (UTC)

庚辰本还有更好的影印版吗？这套感觉不够清晰。 Kcx36（留言） 2025年1月14日 (二) 05:02 (UTC)

在書格論壇裏找到這個版本 - 脂砚斋重评石头记(庚辰本)-人民文學出版社1975.pdf，目錄裏還有其它版本。 Liouxiao（留言） 2025年1月14日 (二) 05:44 (UTC)

好的。另外再造善本也不错，可惜Wikimedia Commons上的文件图像有压缩，不知道有没有更清晰的版本。 Kcx36（留言） 2025年1月14日 (二) 06:34 (UTC)

我感觉人文社的这个pdf可能哪位爱好者给朱批上过色，虽然该影印版原书是彩色的，但是经我对比该pdf应该是来自读秀的ss10317852，而读秀扫描的是黑白的。 Kcx36（留言） 2025年1月14日 (二) 06:51 (UTC)

根据帖主“子康”在書格另外一個帖子，其發佈的“甲戌、庚辰”本都做過精修，如“使用商業字体製版”、“加底色”等，且有特別説明“所分享的所有圖書都禁止打印。一經發現，將取消原始分享。”、“此版字体爲未經商業授權之字体。故私用無礙，一經商用便侵權。”特提請注意。

” Liouxiao（留言） 2025年1月14日 (二) 14:38 (UTC)

抱歉，還是弄混了，上面所指的應是該帖主自行整理的四校自用本（v2.006a）、四校自用本（v2.006b）。 Liouxiao（留言） 2025年1月14日 (二) 14:46 (UTC)

本人拙見，再造善本影印本的文字顔色當是原本顔色，朱筆批語和改字當只存在于11回至28回。我當然未親目見過原本，僅列幾個其他旁證：一， 我上傳的影印本第一冊除末頁外全爲黑白（此頁應是13回的回前批），第二、三冊為彩色（21-30回），第四至八冊全爲黑白。二，馮其庸《論庚辰本》（一九七八上海文藝出版社初版）：

• 一（三）评语的情况（下錄原文）：庚辰本上的那许多朱笔评语，……（省略无关文字），而且它的朱笔抄手是一个人，全部朱笔批语是由一个人抄完的。（原文结束）
• 附錄表二：己卯、庚辰兩本回前、回後批語對照表，紀錄庚辰1-11回的回前、回後批語為墨色。庚辰本前11回沒有眉批、行間批、雙行小字，所以至少1-10回應無任何朱批。

三，鄧遂夫《脂硯齋重評石頭記庚辰校本》（二〇〇六作家出版社初版）有詳盡記錄庚辰本批語的顔色，前十回的回前批或混為正文的批語均標爲「【回前墨】」。我雖未閲讀鄧氏全書，且這是鄧一家之言，但在19，20回校對時，已經逐字對比鄧書的此二回，未見批語顔色有誤。

其他今人出版的庚辰本也有描述批語顔色，惟維基文庫脂硯齋重評石頭記的來源即未標明顔色，其在維基文庫展示的顔色并不和某個原始文獻相符。 Andayunxiao（留言） 2025年1月14日 (二) 15:53 (UTC)

我手上有四本裝2010年人民文學出版社出版的脂硯齋重評石頭記影印本，印刷很清晰。這是紅樓夢古抄本叢刊中的一種，豆瓣列出共有10種各版影印，這套應該是內地出版的最全面權威的紅樓抄本了，價格也還好，庚辰、甲戌本應該還可以買到。 Knowhan（留言） 2025年1月19日 (日) 21:36 (UTC)

我簡述我在第19回（第二冊169頁）起試錄入的樣式和錄字標準，請評論。

樣式：

1. 直排下模擬原書排版，橫排下合并按序展示正文和批語，試圖同時適應桌面瀏覽器和手機端。允許跨行、跨頁批語在橫排下合并。

2. 批語樣式和内容分離。生成的Wikitext 以CSS 類標記批語類別。紅色批語均以模板參數class=red標記（關鍵字可討論），在索引頁樣式頁指定顔色。墨色批語顔色，所有批語的對齊，間距，是否顯式標記批語類別，等待社群和讀者意見。

3. 正文有標點，批語無標點。但不加標點亦可。

錄字：

1. 錄抄手所寫原字，區分同一個字的不同寫法。未編碼非正字以{{Unencoded Original}}模板標記編碼或zh:w:表意文字序列(IDS)。少量的未編碼正字以{{?}}標記。

• 本書批語或者字小，或以連筆寫成，故對批語降低分類標準，在不能識別寫法時按正字錄。

2. 錄入範圍：所有可見的字，包括旁改文字和塗掉的原字。

3. 不加校，改，另，或注釋，在另頁（用戶頁或專題頁）提供編者需要的資訊。

4. 以模板標記少量避諱字（玄，祥等）但顯示正字。 Andayunxiao（留言） 2025年1月14日 (二) 17:07 (UTC)

第2點“旁改文字和塗掉的原字”是否需要依樣錄入？感覺按照改後的文字錄入原文中，會更方便閲讀。 Liouxiao（留言） 2025年1月15日 (三) 00:49 (UTC)

建議同時錄入旁改和塗掉的字，樣式，使用何種模板都可討論。一般而言，對原始文獻是手稿的情況，兩者都是組成部分，都應如實記錄。單對庚辰本而言，旁改有抄手隨手更正，但也有後人改動，和抄手不明來源的改字。版本學愛好者，可參考馮其庸《論庚辰本》三（五）章對庚辰本旁改文字的論述和舉例。因庚辰本的母本早已湮沒，此類考證很難避免主觀論斷，維基文庫只需兩者全錄。 Andayunxiao（留言） 2025年1月16日 (四) 16:56 (UTC)

再次感謝各位參與討論。已經過去了幾周，本人不確定現在是否有共識？我想補充，此討論限於我上傳的此系列影印本。共享資源有其他庚辰本影本，此系列文件未必需要作爲脂硯齋重評石頭記 (庚辰本)的惟一或首選來源。雖然一般情況文庫不需要單個版本多次錄入，但庚辰本石頭記有其内容和版本價值，各編者完全可以因排版和錄字標準之理由而在繼續消歧義的不同作品頁錄入（如脂硯齋重評石頭記 (庚辰本直排)，脂硯齋重評石頭記 (庚辰本正字本)）。本人的一廂情願也是此作品能經受時間檢驗，成爲文庫的特色，填補公有領域沒有精確的庚辰本石頭記原文的空白。我也支持基於庚辰本的精確校對本，社群維護一個維基文庫校本（en:wikisource:Annotation）。

其次，參考英語維基文庫常用的專案頁面的格式手冊（如en:Wikisource:WikiProject_1911_Encyclopædia_Britannica/Style_Manual，en:Wikisource:WikiProject DNB/Style Manual），且前番已經提請社群意見，如不反對，將近日建立專題頁面：Wikisource:專題/庚辰本石頭記2017影本，放置因需要長期更新而不適在討論頁維護的格式指引。Andayunxiao（留言） 2025年2月14日 (五) 17:02 (UTC)

已經建立專題頁面。自上次討論後，樣式上社群已在討論同一來源頁的直排和橫排同時實現，故具體實現可重新討論。無論模板方案{{Old text page}}或JS小工具，似乎都可以在校對頁的正文部分内按橫排樣式錄入（需考慮換行），然後在頁眉和頁脚加模板實現校對頁的直排。因此，可以先行錄入，日後可只修改頁眉頁脚的模板，或至多用機器人批量修改頁眉頁脚。

就錄入原則，即異體字，原書改字，是否使用校，另，改模板，及是否加編者注釋，雖社群長期沒有强制標準，但也難以在同一作品頁和其索引頁内混合多種體例。如對這些項有不同願望，最好分版本錄入。

本人在自己繼續錄入前，仍要更新現半個19回，並錄入19回餘下和20回作測試。社群可不必等待，現在就可錄入或編輯各頁面。也歡迎加入並完善專題頁面。 Andayunxiao（留言） 2025年3月15日 (六) 07:00 (UTC)

花錢給某大學複印古書

我現在要花錢給大學複印古書，但是需要花錢。維基文庫會不會幫我支付這一筆錢？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月28日 (二) 23:16 (UTC)

m:Grants:Project/Rapid/zh Midleading（留言） 2025年1月30日 (四) 09:57 (UTC)

也請閣下注意，如果從大學圖書館購買他們製作的影印圖像，然後分享到維基共享資源，可能有法律風險，請事先瞭解當地法律和大學的版權聲明。 Andayunxiao（留言） 2025年1月31日 (五) 16:21 (UTC)

明白了，但是如果複製的圖像都是早就進入公有領域的圖像呢？@Andayunxiao 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年1月31日 (五) 18:56 (UTC)

c:Template:PD-scan 維基小霸王（留言） 2025年2月5日 (三) 14:07 (UTC)

未收錄字以正字替代的模板（2）

提議更新Template:Unencoded_Original模板。先前討論在此。已經以模組實現顯示多種編碼及表意文字結構的功能：Module:Unencoded_Original。新版本和現版本的對比在此：Template:Unencoded_Original/testcases。僅文字有變化，樣式未更改。請社群評論新的提示文字，參數等是否得當。

更新後，第二個位置參數{{{2}}}將顯示異體字字典編碼，而不是現在的自訂文字。因社群已經有後一用法，故在模組的邏輯中製作了維護分類Category:Unencoded Original 模板使用錯誤參數的頁面來追蹤，我將協助社群逐一更正。如果社群想要保留一個通用的提示模板，可以另外創建。各種意見，請在此提出。 Andayunxiao（留言） 2025年1月31日 (五) 18:27 (UTC)

'原字未編碼' => '原字未收錄於Unicode'

又，{{{2}}}可以做成隱式變數，讓模組去做判斷。我不知道當前使用{{UnO}}且無宣告參數名稱的頁面數量多寡，但如果這麼做，會比逐一更正現有的、的使用中頁面還要省力的話，也不妨參考一下。

• 以⿰⿲⿱⿳⿸⿺⿹⿽⿵⿷⿶⿼⿴⿻⿾⿿㇯開頭為IDS
• 以ABCN開頭為MOE字號
• 以0~9開頭為CNS碼

GlyphWiki倒沒辦法判斷就是了。

話又說回來，指定參數名稱是個好慣習(convention)，向後相容性也不是必要的。Aerotinge（留言） 2025年2月4日 (二) 16:13 (UTC)

'原字未收錄於Unicode' : 更為準確，惟 Unicode 是否替以中文名更好理解？可等待社群更多意見。

分離各編碼的參數名可能更不易出錯，也和閣下先前的提議一致。{{{2}}} 取 MOE 編碼是我的私心和需要，也可討論改爲另一種編碼。

感謝閣下關於判斷編碼的提示。查連入頁面Special:链入页面/Template:Unencoded_Original，現不到300處使用，大多應無需修改，所以可能我自己還應付得過來。閣下也可改進相關邏輯（Module:Unencoded_Original 50-52行）。又此追蹤功能僅爲過渡而用，故判斷的邏輯很欠缺，更正後可能不再需要。 Andayunxiao（留言） 2025年2月4日 (二) 17:00 (UTC)

閣下另外是否仍希望開發外鏈功能？異體字字典的例子我已知道（ja:wikt:Template:R:twedu)，其他的我還不瞭解。可提供閣下希望的參數用法和實現方式或直接更新模塊。 Andayunxiao（留言） 2025年2月4日 (二) 17:06 (UTC)

我知道的外鏈如下

IDS

• https://www.cns11643.gov.tw/searchI.jsp?MD=1&IDS=⿰山窊
• https://hc.jsecs.org/irg/ws2024/app/index.php?ids=⿰山窊

CNS

• https://www.cns11643.gov.tw/search.jsp?ID=6&CPG=1&CNUM=6D30&CNUM2= CPG=字面;CNUM=碼位;CNUM2=碼位

MOE

• https://dict.variants.moe.edu.tw/search.jsp?ID=7&WORD=A02964-001&WORD= WORD=字號1;WORD=字號2(選填)

不過我對外鏈目前沒有需求(及期望)，可以按您的方便及需求來做就好。Aerotinge（留言） 2025年2月4日 (二) 17:22 (UTC)

如果說僅採用MOE碼是設計本意，也可以從我這著手，把我之前的嵌入使用給改了。該模板專注在MOE碼及其配套的索引字表上即可。

我會用{{UnO}}指定並錄入IDS結構也是看到某個用例在前，才以為可以這麼用，現在想想是疏忽了。Aerotinge（留言） 2025年2月5日 (三) 04:05 (UTC)

非常感謝閣下提供的外鏈實例，即便暫不用於本模板，也會幫助未來開發者。

提供IDS 參數雖然我起初未曾想到，但後來也發現了需求，因的確有些字的變體未在異體字字典收錄，或編者一時沒有找到。在本模板提供此參數可能優於拆分到不同模板。

閣下所提的索引字表和後續開發，我上面沒有説明。構想是，此次更新後，無論是否有Unicode以外的編碼，都允許顯示自訂的IDS。未來建立索引字表後，可以向表内添加社群維護的IDS 序列，對有指明其他編碼的字，將替換編者自訂的IDS。以「窗」的異體字「A02964-014」爲例，編者如要顯示IDS資訊，可輸入ids=⿱穴忽或ids=，會顯示社群維護的IDS。對沒有指明其他編碼的字，不會覆蓋自訂IDS，但也可允許社群自行編碼並在字表登記。 Andayunxiao（留言） 2025年2月9日 (日) 16:28 (UTC)

至於Unicode，中文可以稱為 統一字元編碼（Unicode）。或是去掉小字注文，反正tooltip字都夠小了。Aerotinge（留言） 2025年2月4日 (二) 17:25 (UTC)

或者作：原字未收錄於統一碼。据w:Unicode，統一碼是官方名稱，但文庫不必用官名，可考慮讀者接受的名稱。 Andayunxiao（留言） 2025年2月13日 (四) 17:00 (UTC)

目前對本模板的功能更新提議，社群是否還有更多意見？Tooltip 的用詞因只需修改模塊内一處，可繼續討論，修改不必經過沙盒。此更新未涉樣式，仍可延後修改。如無反對或新提議，將在7日后更新並人工修復連入頁面。Andayunxiao（留言） 2025年2月13日 (四) 17:11 (UTC)

已更新模板到沙盒。追蹤分類生效，但需要等待服務器更新分類頁面。 Andayunxiao（留言） 2025年2月22日 (六) 17:39 (UTC)

已經按嵌入頁面的分類找到大多數需要更新用法的頁面，並已經改動。此次修改的所有頁面見本人用戶貢獻以及分类:包含使用者定義的表意文字描述序列的頁面（同樣須等待服務器更新）。後續如發現遺漏應可再編輯。如有錯誤歡迎留言。 Andayunxiao（留言） 2025年2月22日 (六) 18:21 (UTC)

Reminder: first part of the annual UCoC review closes soon

My apologies for writing in English. 请帮助翻译至您的语言.

This is a reminder that the first phase of the annual review period for the Universal Code of Conduct and Enforcement Guidelines will be closing soon. You can make suggestions for changes through the end of day, 3 February 2025. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta. After review of the feedback, proposals for updated text will be published on Meta in March for another round of community review.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk) 2025年2月3日 (一) 00:49 (UTC)

2025年第6期技術新聞

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

近況更新 - 面向編輯者

• 「特殊字元」編輯工具列選單現在可以顯示您最近在該維基編輯時最常使用的32個特殊字元。這項變更讓您能更容易找到最常使用的字元。2010年版wikitext編輯器和可视化編輯器皆有此功能。 [89]
• 2010年版wikitext編輯器現在能以正確的縮排建立子清單。另外，您現在可以使用新的工具列按鈕插入<code>標籤。感謝stjn所做的改進。[90][91]
• 請提供協助以確保引用生成器Citoid能在所有維基上正常運作。
  • 一、請管理員更新本地版本的MediaWiki:Citoid-template-type-map.json頁面，收入preprint、standard、dataset等項目；參見preprint以及standard、dataset的更新範例。
  • 二之一、如果用於這類參考資料的引用模板中缺少citoid映射，請補上。
    二之二、如果已有citoid映射，請更新TemplateData，收入新的欄位名稱。參見preprint以及standard、dataset的更新範例。可能需要支援的新欄位包括archiveID、identifier、repository、organization、repositoryLocation、committee、versionNumber。 [92]
• 已新建一個維基： 中卡努里語维基百科 (w:knc:) [93]
• 上週有27個社群提交的工單得到解決。 例如，用於維基文庫的OCR（光學字元辨識）工具新增支援語言：教會斯拉夫語。 [94]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年2月4日 (二) 00:09 (UTC)

Gemini 2.0 Flash Thinking支持行外标点识别

大语言模型飞速发展。现在有很多模型支持OCR了，有人搞了一个榜单[95]。或许维基文库也可以根据对不同类型文献识别的准确程度自己做一个榜单。

经过测试，只有Gemini 2.0 Flash Thinking Experimental 01-21支持行外标点识别。网址：https://aistudio.google.com/prompts/new_chat 。

使用的命令：“这是一段文本，从右到左竖排版式，请注意标点在行外，转换为文本，不要给出解释，不要转换为简体。注意，页眉页脚、页码请忽略。换行请用双行换行。”

结果如下：[96]。

有一些错误。注意，“另外想法子”识别成了“另想些法子”。这不像一个识别错误，而是进行了文本修改。

aistudio的限制是每分钟10个请求，每天1500个请求。 維基小霸王（留言） 2025年2月6日 (四) 12:19 (UTC)

怎么说呢，本人是完全支持文库接入大模型对文本作业进行高效批处理的。

但目前市面上的agi大模型要想高效无限量使用都要支付一定算力成本，这方面资金由谁出？wiki基金维护目前的wiki公共服务器就已经捉襟见肘了。

deepseek的免费web前端入口也已经被完全撸废，白天基本以每半小时为一周期成功响应一次。不知道是由站方暗中写入规则限制并发数，还是确实是使用人数过多导致的网络拥塞或服务器过载。

总而言之，大模型的性能和推理能力确实日新月异，但离走入普通用户生活中还存在巨大差距。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月7日 (五) 07:55 (UTC)

deepseek 的OCR估计是传统的技术应用于古书并不好用。gemini 2.0是多模态融合ai，直接用最新技术识别古文。 維基小霸王（留言） 2025年2月8日 (六) 01:31 (UTC)

说到底还是钱的问题，只要有钱活抢着做。

deepseek之前胜在web入口免费无限撸，现在这个渠道也在暗中被限制。

无论未来是大公司免费无限量提供高性能推理模型，还是个人pc性能提升到足以接入本地大模型进行推理。都得等算力供应过剩，大幅溢出，相关硬件成本普降后，才能吃到免费的午餐。这个过程至少还要再等10年左右。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月8日 (六) 08:31 (UTC)

Gemini 2.0 Pro Experimental 02-05 的表现更好。 Liouxiao（留言） 2025年2月14日 (五) 09:08 (UTC)

识典古籍相关的问题

Wikisource:古籍資源列了好些网站，其中识典古籍带页面扫描，并且它的古籍整理任務中心有“校对OCR结果”任务。尽管其用户服务协议 §4.3 不允许复制、整理等，但古籍的原本影像和OCR结果是不是没有版权，仍然可用于维基文库？OCR结果经人工整理校对勘误后呢？

特别地，“中国国家图书馆首页 → 数字资源 → 永乐大典”指向《永乐大典》高清影像数据库（第一辑），右上角的“阅读大典”就是识典古籍的《永乐大典》。这又怎么算呢？ David, but not Hilbert（留言） 2025年2月7日 (五) 09:12 (UTC)

补充：识典古籍上的文字似乎有以下三种程度。

1. “AI整理：文字为机器OCR结果，使用前注意核对原图”，例如《水經注釋》。
2. “粗校：标点与命名实体为机器自动标记，仅供参考”，例如《水經註》。
3. “精校：文字、标点、命名实体已经人工校对”，例如《論語集解》。

所谓“命名实体”大概是指□□百科链接。 David, but not Hilbert（留言） 2025年2月7日 (五) 09:26 (UTC)

對已進入公有領域之古籍書頁進行翻攝、掃描。只要不存在創作性的參與，該重製影像就不會形成著作權。

然，該重製影像經印刷或類似方式公開發行，並依法登記者。重製者就其影像，享有以相同或類似方式重製之專有權利，是為製版權。

又，對重製影像再翻拍、發行，不會再次形成製版權。(這部分有訴訟爭議，爭點在於縮圖、示意圖的公開算不算形成製版權，並耗盡權利)

OCR文本，作為忠實再現文字的方法，也不會產生任何著作權。

AI輔助生成的OCR文本，當前通說認為在沒有人為參與的情況下，即是不存在創作性與原創性的參與，亦不得主張著作權。

但即便如此，您仍應遵守EULA(用户服务协议)，不應該違反其任一項條文來使用該網站的服務，這是民法契約自由原則所保障的範疇。

以上都只是我的看法，畢竟我不知道共和国的相關條文是怎麼訂定及如何執行的。請務必遵守當地法規來行事。Aerotinge（留言） 2025年2月7日 (五) 10:00 (UTC)

看了一下这个网站，整理的所有书籍仅限于中国封建历史时期，近代出版的书籍貌似一本都没。

条款仔细看了下，大概意思也是自己有能力会爬数据，爬下来的数据自己看也行，网站基本上睁一只眼闭一只眼，但在未经站方许可绝对不能外传或者引用。

爬下来自己搭着自己看，对外提供服务要是被举报会被视为侵权。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月7日 (五) 10:24 (UTC)

感谢各位解答！看来还是谨慎参考为好。 David, but not Hilbert（留言） 2025年2月7日 (五) 10:51 (UTC)

说句题外话，识典古籍的整理平台可以自己上传古籍图像并免费使用文字识别、自动标点等功能，成果可以导出然后上传到维基文库，整个校对过程比起维基文库的Proofread Page顺畅太多了。 Kcx36（留言） 2025年2月13日 (四) 16:50 (UTC)

我试了一下，确实很好！不想注册的朋友可以参考他们网站上的教学视频（三分多钟），分为以下三步。

1. 区域调整：选图用的。这个维基文库似乎不涉及，就不说了。
2. 字框和列框：OCR如果没找出的字或行，可以人工框选补上；双行夹注似乎要单独选列。
3. 校对文字：一列原图一列结果；OCR不确定的字会标蓝，人工改过的会标橙，人工标记存疑的会标红；选中字还会推荐替换字（比如原文是“𤫊”，OCR结果是“靈”，会给我推荐“𤫊孁霊霛”等；还有助于发现“成成”这种细微区别），并根据输入继续推荐。但反而没法全文查找替换那种永远识别错的异体字。

不过，我没找到如何自己上传古籍图像。若是指整理平台，似乎要用手机号、姓名、大陆身份证号实名认证才能创建团队，恐怕维基文库不是所有人都能用。 David, but not Hilbert（留言） 2025年2月15日 (六) 14:17 (UTC)

我加上了韓國典籍的網站了。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月15日 (六) 15:13 (UTC)

上传影像确实要自己建一个团队。如果非大陆用户确实不能创建团队，或许可以委托大陆用户上传影像，再进行校对。 Kcx36（留言） 2025年2月16日 (日) 08:09 (UTC)

确实，识典古籍整理平台的功能确实很棒，可以减轻很多人工负担，极大加速了古籍的处理速度和质量。 Liouxiao（留言） 2025年2月19日 (三) 01:48 (UTC)

對上傳文本有審核要求，由於大陸目前的政治正確，絕大部分近代相關資料應該都無法通過審核，例如《國民政府公告》《滿洲國公告》之類的國家政府公文內容中會有數不勝數的觸犯禁忌的敏感詞。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月19日 (三) 20:22 (UTC)

这个网站的工具很好，如果能说服他们开源，以应用到维基文库就好了。开源是趋势，比如deepseek。或者不开源，但提供api也很好。维基文库的优势是多语言，国际化。而且成果完全开源，全站提供打包下载，可用于LLM。--維基小霸王（留言） 2025年2月20日 (四) 01:53 (UTC)

我发了邮件，回复说让用平台上的OCR功能。 維基小霸王（留言） 2025年2月20日 (四) 04:21 (UTC)

Template:中华人民共和国强制性国家标准及Template:中华人民共和国强制性行业标准

如题，留意到两模板内容引起讨论，在下简要看后，私以为目前两模板需要承载的内容杂糅（即“强制性国家标准”（此为专有名词）和“具强制约束力的国家标准”），因此有如下浅见，亦副知近期参与此模板相关事宜的@红渡厨, Patlabor Ingram，并请未尽ping到的社群各位多指正：

1. 当前模板标题因已有“强制性XX标准”这一名词存在，这就使得再在其中列举其他“具强制约束力的标准”的内容可能造成使用或理解上的不便，个人建议将模板更名为“中华人民共和国国家标准”和“中华人民共和国行业标准”（为免累赘，下面仅以国家标准为例），并修改模板首句为“本作品来自中华人民共和国国家标准，因符合下列规定而具备强制约束力，因而属于公有领域”，这样一来，下面的内容中则可照当前样式充分包含所有“具强制约束力的国家标准”。
2. 当前在下暂时作了一个缓冲修改，这里需要说明的是，《标准化法条文解释》是符合中国大陆司法管辖区内的法律解释权限划分规则的，这也是比较普遍的认知，因为《全国人民代表大会常务委员会关于加强法律解释工作的决议》与《宪法》、《立法法》并不相冲突，这一点如果有朋友有疑虑的话，可以参见一例，即2000年的国务院关于贯彻实施《中华人民共和国立法法》的通知——自然，这样的划分当然是存在学理法理上的讨论的，但我想那并不是我们在面对当前问题时能够考虑的。至于《标准化法释义》，尽管并不像《条文解释》那样因由技监局发出而具备三性质，但作为由人大法工委、国务院法制办、质检总局和国家标准委等参与修订《标准化法》的单位组织编写的释义书籍（PS：署名的二位，一位时任国务院法制办副主任，一位就是时任的国家标准委主任），无疑在厘清法律原意方面具备相当的权威性。据以上，两段都留在了当前的缓冲修改，因为愚见以为这两段被去除的可能性不大，同时也便于参与讨论的各位检视。
3. 至于其他引起讨论的细项，个人粗看似乎不必列得那么细（例如食安标准，食安都是GB无T打头，再细列似乎意义不大？），不过我还是想再细看一下；至于部分中涉及地方标准（强制性）的，是不是再建一个“中华人民共地方标准”为好，还要请诸位讨论。
4. 至于是该写一个注来提醒使用者国标行标不必然具有强制性（就像PD-PRC-exempt那种形式），还是直接在文本中说明，也在此请各位商议。

以上，一点浅见，多请指正。 银色雪莉（留言） 2025年2月8日 (六) 04:01 (UTC)

基本认同银色雪莉阁下的意见，同意将模板更名为“中华人民共和国国家标准”和“中华人民共和国行业标准”，避免理解上的困难。 ——— 红渡厨（留言・贡献） 2025年2月8日 (六) 09:16 (UTC)

亦认同地方标准单独设立模板的建议，不过本站目前似乎未录入公有领域的地方标准，似无现实需求。 ——— 红渡厨（留言・贡献） 2025年2月8日 (六) 09:22 (UTC)

这不难，录一个就是doge 银色雪莉（留言） 2025年2月8日 (六) 14:06 (UTC)

（1）对更名无异议。

（2）对于“按现有模式管理”，需要说明的是：

①《中华人民共和国标准化法》第十条规定，“法律、行政法规和国务院决定对强制性标准的制定另有规定的，从其规定”。《〈中华人民共和国标准化法〉释义》指出，“……‘国务院决定’是指《深化标准化工作改革方案》（国发〔2015〕13号）。”

②《国务院关于印发深化标准化工作改革方案的通知》（国发〔2015〕13号）规定，“法律法规对标准制定另有规定的，按现行法律法规执行。环境保护、工程建设、医药卫生强制性国家标准、强制性行业标准和强制性地方标准，按现有模式管理。安全生产、公安、税务标准暂按现有模式管理。核、航天等涉及国家安全和秘密的军工领域行业标准，由国务院国防科技工业主管部门负责管理。 ”因此，《〈标准化法〉释义》中对于“按现有模式管理”的释义段落，本质上是把国发〔2015〕13号文重述了一遍。

③因此，环境保护、工程建设、医药卫生、安全生产、公安、税务等领域在2018年1月1日以后，仍然可以公布强制性行业标准、强制性地方标准；仍然可以依据质技监局标发〔2000〕36号文公布以“GB/T”编号的条文强制形式强制性国家标准、以“XX/T”编号的条文强制形式强制性行业标准。此部分应当列入两个版权模板的说明内。 Patlabor Ingram（留言） 2025年2月8日 (六) 13:57 (UTC)

我认为这只需要在模板中的“此外”节中列出《标准化法》第十条即可，因为详列是列不尽的，而我们仍需要在出现疑难文献时检视相关标准制定时所依据的具体法律法规，这样一来在模板里详细列出就无必要了，不知阁下以为如何。 银色雪莉（留言） 2025年2月8日 (六) 14:05 (UTC)

同意您的看法。 Patlabor Ingram（留言） 2025年2月9日 (日) 12:31 (UTC)

更新：已制作Template:中华人民共和国地方标准，尚请各位协助审视行文是否有不足处。 银色雪莉（留言） 2025年2月9日 (日) 05:27 (UTC)

同意该模板的行文逻辑。并建议国家标准、行业标准模板行文可参照此模板现有文本撰写。 Patlabor Ingram（留言） 2025年2月9日 (日) 12:32 (UTC)

提议

根据各位见解，现提出两件的修正案：

一、Template:中华人民共和国强制性国家标准标题改为Template:中华人民共和国国家标准，内文：

本作品来自中华人民共和国国家标准（或部标准、专业标准），并因符合下列规定之一而具备强制约束力，根据《国家版权局版权管理司关于标准著作权纠纷给最高人民法院的答复》（权司〔1999〕50号），“强制性标准是具有法规性质的技术性规范”，所以依据《中华人民共和国著作权法》第五条，不适用著作权保护，因而属于公有领域：

• 根据1962年12月4日施行、1979年7月31日停止执行的《工农业产品和工程建設技术标准管理办法》第十八条，在此期间，技术标准中的国家标准和部标准均具备强制性。
• 根据1979年7月31日施行的《中华人民共和国标准化管理条例》第十一条、第十八条，自此日起至1989年4月1日间，标准中的国家标准、部标准一经批准发布，就是技术法规，具备强制性。
• 根据1988年和2017年《中华人民共和国标准化法》，自1989年4月1日起：
  • 国家标准分为强制性标准和推荐性标准。具体而言，根据1990年《国家标准管理办法》第四条、2020年《强制性国家标准管理办法》第三十五条，以汉语拼音字母“GB”加上国家标准发布的顺序号和年份号为标准代号格式的标准，是强制性国家标准。
  • 法律、行政法规和国务院决定对强制性标准的制定另有规定的，从其规定。因此，若有直观依据时，亦可佐证该国家标准具备强制性。
• 若无法符合上述任何一项时，则该国家标准是推荐性标准，《国家版权局版权管理司关于标准著作权纠纷给最高人民法院的答复》指出“推荐性标准不属于法规性质的技术性规范，属于著作权法保护的范围”，但：
  • 1990年7月23日颁布实施、2018年3月6日废止的《标准化法条文解释》（原国家技术监督局令第12号）第十四条规定：“……推荐性标准一旦纳入指令性文件，将具有相应的行政约束力。”据此，在1990年7月23日至2018年1月1日期间被纳入指令性文件的推荐性标准，具备强制约束力，属于公有领域文件。
  • 《〈中华人民共和国标准化法〉释义》指出，“但在有些情况下，推荐性标准的效力会发生转化，必须执行：（1）推荐性标准被相关法律、法规、规章引用，则该推荐性标准具有相应的强制约束力，应当按法律、法规、规章的相关规定予以实施。……”因此，2018年1月1日以后发布且被相关法律、法规、规章引用的推荐性标准，也具有与该相关法律、法规、规章相对应的强制约束力，属于公有领域文件。

二、Template:中华人民共和国强制性行业标准标题改为Template:中华人民共和国行业标准，内文：

本作品来自中华人民共和国行业标准（或企业标准），并因符合下列规定之一而具备强制约束力，根据《国家版权局版权管理司关于标准著作权纠纷给最高人民法院的答复》（权司〔1999〕50号），“强制性标准是具有法规性质的技术性规范”，所以依据《中华人民共和国著作权法》第五条，不适用著作权保护，因而属于公有领域：

• 根据1962年12月4日施行、1979年7月31日停止执行的《工农业产品和工程建設技术标准管理办法》第十九条，在此期间，下列领域的企业标准具备强制性：
  • 涉及生产原料、材料和协作件的验收、半成品的检查及成品的检验的；
  • 涉及工程建设的设计、施工和验收的；
  • 涉及农产品分级的。
• 根据1979年7月31日施行的《中华人民共和国标准化管理条例》第十一条、第十八条，自此日起至1989年4月1日间，标准中的企业标准一经批准发布，就是技术法规，具备强制性。
• 根据1989年4月1日施行的《中华人民共和国标准化法》第七条，自此日起至2018年1月1日期间，行业标准分为强制性标准和推荐性标准。具体而言，根据1990年《行业标准管理办法》第十六条，以强制性行业标准编号加上行业标准发布的顺序号和年份号为标准代号格式的标准，是强制性行业标准。
• 根据2018年1月1日施行的《中华人民共和国标准化法》第十条，法律、行政法规和国务院决定对强制性标准的制定另有规定的，从其规定；因此在2018年1月1日以后，仍存在制定新的强制性行业标准的可能，此时若有足以直观佐证该行业标准强制性的依据时，则可证明其为强制性行业标准。
• 若无法符合上述任何一项时，则该行业标准可能是推荐性标准，《国家版权局版权管理司关于标准著作权纠纷给最高人民法院的答复》指出“推荐性标准不属于法规性质的技术性规范，属于著作权法保护的范围”，但：
  • 1990年7月23日颁布实施、2018年3月6日废止的《标准化法条文解释》（原国家技术监督局令第12号）第十四条规定：“……推荐性标准一旦纳入指令性文件，将具有相应的行政约束力。”据此，在1990年7月23日至2018年1月1日期间被纳入指令性文件的推荐性标准，具备强制约束力，属于公有领域文件。
  • 《〈中华人民共和国标准化法〉释义》指出，“但在有些情况下，推荐性标准的效力会发生转化，必须执行：（1）推荐性标准被相关法律、法规、规章引用，则该推荐性标准具有相应的强制约束力，应当按法律、法规、规章的相关规定予以实施。……”因此，2018年1月1日以后发布且被相关法律、法规、规章引用的推荐性标准，也具有与该相关法律、法规、规章相对应的强制约束力，属于公有领域文件。

请各位协助审视行文是否有不足处。--银色雪莉（留言） 2025年2月10日 (一) 06:00 (UTC)

涉及的内容太多，无法一次性细致地看完，但粗略来看是没有什么明显问题的。 ——— 红渡厨（留言・贡献） 2025年2月17日 (一) 16:07 (UTC)

赞同。属于对标准著作权方面高质量的总结，感谢贡献。 Patlabor Ingram（留言） 2025年2月21日 (五) 04:53 (UTC)

更新：经十四日无明显反对意见，已调整模板文字。标题移动及链入已提批量协作。--银色雪莉（留言） 2025年2月24日 (一) 08:53 (UTC)

现阶段一简多繁问题解决方案。目前为止转换准确率最高的NLP模型HanLPC。

先使用HanLPC对文本进行分词，再利用繁简词对字典对包含语义和上下文关系的最小单位「词」进行字体转换，从根本上解决了过去仅仅通过单字匹配方式转化后产生的分歧词问题。

由于繁简词对的字典文件所收录多为白话文词汇，故该方案应用于现代中文体的文章时，其转换正确率最高，半百话其次。

HanLP下载后可搭建本地NLP处理平台。官方提供线上调用接口。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月8日 (六) 10:10 (UTC)

CSS 图像裁剪工具

{{CSS image crop}}是一个直接裁剪图像的实用工具。它允许你使用现有图像的特定部分，从而免去了为简单的裁剪任务上传新文件的需求。然而，这个模板的主要挑战是它需要用户手动识别并输入他们期望裁剪区域的精确像素坐标。 我已经开发了一个 JavaScript 工具，c:User:維基小霸王/CSSImageCrop.js，使用了 Google Gemini 2.0 Flash Thinking。 这个工具极大地简化了这个过程。 要安装它，只需将 importScript('User:維基小霸王/CSSImageCrop.js'); 添加到你的 c:Special:MyPage/common.js 中。 安装后，每个图片文件页面都会出现一个 "CSS Image Crop" 按钮。 点击此按钮即可激活该工具，允许你直接在图像中选择你期望的裁剪区域。 一旦你做出了选择，该工具会立即为你生成模板代码。 此外，你可以通过在提供的对话框中输入数值来轻松更改缩放级别。 该工具也与多页图书文件兼容。 維基小霸王（留言） 2025年2月8日 (六) 15:33 (UTC)

感谢提供该工具。 ——— 红渡厨（留言・贡献） 2025年2月10日 (一) 07:07 (UTC)

编辑协作请求

各位好，现有DB44/ 2155-2019 小东江流域水污染物排放标准一文需要录入含数学公式的内容，在此询请有能者据[97]（纸面页码p3）协助录入，感谢！ 银色雪莉（留言） 2025年2月8日 (六) 15:37 (UTC)

怎麼樣？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月8日 (六) 16:43 (UTC)

@Blahhmosh感谢您的帮助！也在此一并感谢@Aerotinge阁下的帮助。 银色雪莉（留言） 2025年2月8日 (六) 17:01 (UTC)

2025年第7期技術新聞

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

本週要聞

• 產品與技術諮詢委員會（PTAC）發表了一份對維基媒體基金會產品與技術部門的建議的草案。PTAC建議部門專注於行動裝置體驗，尤其是關於貢獻。PTAC請求社群在討論頁提出意見回饋，2月21日截止。

近況更新 - 面向編輯者

• 默认情況下，「特殊页面」portlet链接將從「工具」區塊移至主選單側邊欄的「导航」區塊（位於最頂部的區塊）。「工具」是用來放置與當前頁面相關的工具，而非與站點相關的工具，這項變更將使链接位置更符合一貫的邏輯。若要修改此行為並更新CSS樣式，管理員可遵循T385346的指示進行修改。 [98]
• 網頁團隊的一項工作是改善讀者在維基上探索內容的方式。作為該工作的一部分，網頁團隊將對少數讀者進行一項實驗，在搜尋欄中顯示一些相關或有趣條目的建議。參閱專案頁面了解更多。
• 使用TemplateStyles的模板編輯者現在可以用無障礙相關的媒體查詢（prefers-reduced-motion、prefers-reduced-transparency、prefers-contrast、forced-colors），來針對特定無障礙需求定制輸出。感謝Bawolff所做的改進。 [99]
• 上週有22個社群提交的工單得到解決。 例如，全域封鎖日誌現在會直接顯示在Special:中央认证頁面上，與全域鎖定類似，以簡化監管員的工作流程。 [100]

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

• 維基數據現在支援一種特殊語言「所有语言的默认值」，作為標籤和別名。這是為了避免相同的資訊過度地重複出現在多種語言中。如果您的維基數據查詢會用到標籤，您可能需要更新您的查詢方式，因為部分現有標籤會被移除。 [101]
• 先前，getDescription函數會在每次讀取維基頁面時被調用，約佔頁面總載入時間的2.5%。現在，計算出的值將被快取，以減輕維基媒體伺服器的負載。 [102]
• 作為RESTBase棄用作業的一部分，/page/related端點已於2025年2月6日封鎖，並將於近期移除。此時程選擇乃為配合舊版Android和iOS的棄用時程。MediaWiki的「morelike」action API提供了穩定的替代方案，請參考遷移範例。如有任何疑問，請聯絡MediaWiki介面團隊。 [103]

深入了解

• 季刊語言與國際化電子報新期數發布。 本期內容包括：有關「貢獻」功能表（Speciale:Contribute）的更新；維基百科一些最新語言版本的細節資訊；MediaWiki介面支援的新語言的細節資訊；社群定義清單功能的近況更新；等等。
• Chart專案電子報新期數發布。 本期內容包括：為Chart圖表的全域使用情況提高可見性的進度更新；在共享資源上的Data命名空間中支援頁面分類的進度更新。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年2月11日 (二) 00:12 (UTC)

直排之技術問題

社群近來有對文字排列方向和模板功能適配上的嘗試，但未就文字方向，特別是直排有重新討論，是否可能在此處瞭解社群的意見？

就技術而言，維基媒體基於HTML 標記語言，現支持直排等不同書寫方向，但并不完全支持同一模板或wikitext片段同時支持不同書寫方向。

適配最廣的是使用HTML 原生同時支持多書寫方向的樣式，如Template:書最近更新后使用的樣式text-decoration: underline, padding-inline-end。又例如Template:Zh-em2，傍點在直排環境下能正確地顯示在右側，這是好的設計。惟更多情況，同時支持不同書寫方向需要多個模板協作或全站樣式支持，會有技術限制（如Wikisource:写字间/存档/2024#校對頁面的樣式生效的範圍）。另，Mediawiki 軟體的原則之一是不允許模板依上下文不同而展開成不同的文字（試圖繞過可能會被後續補丁禁止）。

就樣式和讀者功能，有全局頁面直排，僅作品内容直排，僅嵌入包含直排等可能，也可能允許讀者自選方向。這些功能都顯有益，但恐互有衝突，且需要Mediawiki 提供更多支持。因Mediawiki 更新需時日，社群可以早早開始討論，有共識后即可向Phabricator提議案。 Andayunxiao（留言） 2025年2月13日 (四) 17:45 (UTC)

承君起言，

關於中文縱書，我以為問題在於「中文」文庫的性質上。中文，甚至諸東亞文字，在現代多改採用西方的行文書寫方式。

故在中文文庫也採用了由左至右的版面配置。但是傳統東亞文字排版並非如此，而文庫好一部分的作品便屬此排版。

由於各式因素，HTML原生的完整東亞文字排版支援仍是草案，處在有生之年、家祭毋忘的高閣。

長久以來對縱書作品的排版需求，多由模板去達成。

止直排一事，有古早時代的{{Vtext}}、約莫10年前writing-mode開始普及後的{{Vtext2Start}}、四庫系列的{{SKQS header}}、近來的{{Vlr-begin}}、君之{{vps}}。

但都不乏磨合難處，如Wikitext parser會自動生成<p>結構對文本閉合，但與模板互動後，結果難以預料。這也使得應用直排模板，配合雙換行符斷句的編輯貢獻者，常會需要在文本末尾用{{nop}}之類語法，去提示Parser作閉合。

以Wikimedia的架構而言，我認為一個可能的通解是在Page:命名空間中添加一個如校對頁面狀態的擴展，用以紀錄書寫方向。並據此以

<div class="mw-content-ltr mw-parser-output" lang="zh" dir="ltr">

或

<div class="mw-content-rtl mw-content-vertical mw-parser-output" lang="zh-hant" dir="rtl">

於Page:命名空間渲染頁面。

(註：mw-content-vertical是我胡謅的類別，僅權宜地代表直書屬性。依愚所聞，維基媒體基金會底下，至今仍不存在以東亞文字排版的媒體專案。在東亞文字排版向來是領跑者的日文，在此事上完全躺平；滿文已死；老蒙文還在孵蛋。真要說的話，zh-classical興許才該用在這兒)。

在最基本的框架確定下來後，再來才是對直排的樣式適配(維基預設的許多樣式如margin-*, padding-*是按西方行文習慣添加的，Common.css、Gadget-Site.css或需要相應修改。)

模板，即割注(夾注，即雙行註文)、挪抬、古文加點(添加新式標點符號)等如果要適配，此時也較方便著手。

以上是我對全局頁面的看法。

至於僅作品内容直排、僅嵌入包含直排，我認為這屬於個別貢獻者的編輯範疇，可以有方針，倒不一定需要有個規範。或可在該作品(如文集)的討論頁中約定即可。 Aerotinge（留言） 2025年2月14日 (五) 05:01 (UTC)

• 又，「模板依上下文不同而展開成不同的文字」一事，還請您指出有疑慮之模板。愚以為分項出來討論為宜。 Aerotinge（留言） 2025年2月14日 (五) 05:02 (UTC)

  此處并無對現有模板的疑慮，僅是闡述此類方案不可行，後面我可能會專項説明。本人無意推動違反這一原則的提案，此功能可能是MediaWiki的潘朵拉的盒子，啓用可能危害不小。可參考Extension:Variables這一未來將棄用的擴展的設計和討論。 Andayunxiao（留言） 2025年2月14日 (五) 15:50 (UTC)

認同閣下分享的經驗和觀點，我將後續分項細論。很遺憾日文維基文庫未能在此問題上先發聲。MediaWiki 和HTML 標準整體是為西文設計，背後是西文出版成熟的標準和習慣趨同的讀者群。對中文多編碼，多排版標準的複雜體系是先天不適應。希伯來文維基文庫he:עמוד_ראשי可能和中文社群有類似的處境，即歷史典籍多，需要注釋，校對不足，多排版標準。中文文庫社群如果能在提案上聯合以上語言社群，可以擴大聲音。 Andayunxiao（留言） 2025年2月14日 (五) 16:06 (UTC)

另，此討論不應影響現有直排作品的錄入，且成果也可能是有生之年，不可過高期望。用模板實現直排雖不完美（包括本人製作的模板）但卻是好的做法，方便編者，也便於未來可能的修改。本人也認爲文庫的老作品的樣式應不壞勿修（w:維基百科:沒壞就不要修），應避免（批量）以非校對原因編輯陳年作品頁。現在的錄入可以，但不必為未來的新技術讓位或留餘地。未來如果有直排的共識，也應限於更新模板，並免於追溯老作品的樣式。 Andayunxiao（留言） 2025年2月14日 (五) 16:23 (UTC)

大原則上我也是同意沒壞不修、不溯及既往，但排除我經手的過的作品。

因我自用的格式準則有顯著改變，手邊又沒有正在錄入的作品可供應用時，我可能會抓一件過去貢獻過的合適作品底稿進行再校對，順帶改寫。

至於預留新技術的空間，竊以為非必要，同時也未嘗不可。

舉個例子來說好了，詩文作品的斷句換行，目前常以手動方式添加換行符，或以雙回車達成。

查CSS實有break-after屬性，搭配nowrap即可供文句按標點、空格、<wbr>等元素排版斷句。惟其不能通過當前維基的CSS校驗工具檢查。

(屬CSS Fragmentation Module Level 3規範，當前處在CR階段。直排所用的writing-mode同處在CR階段就是了，但這屬性受到校驗工具認可)

故假使我要錄入一件七言詩作品時，我會傾向於不手動添加換行符。因在未來以HTML原生方法達成該效果是可預見的。或許在Phabricator爭取一下加速？ Aerotinge（留言） 2025年2月15日 (六) 03:06 (UTC)

是的，同意修改老作品頁的樣式非「不可」，而偏於「非必需」。如機器人或可靠的人工改法我也支持。閣下舉例已有遠見，當可以無慮按計劃錄入並修改。當前的CSS校驗工具顯較最新標準滯後。此處討論也有意爭取社群共識，推出Phabricator 提案，讓提案更容易通過。 Andayunxiao（留言） 2025年2月16日 (日) 16:30 (UTC)

弄了個腳本跟樣式把動態佈局功能給接上。並稍稍魔改了其功能，使得佈局可以無需依賴直排模板或Index樣式表，逕行在主空間進行動態切換。

以下縮圖為議沙門不應拜俗狀_(劉仁叡)在不同佈局下的樣式。目前將佈局1當成橫排，佈局2當成直排，3、4佈局沒有用到(即無樣式)。

該作品錄入僅用了常見的{{DL}}模板寫夾注，跟使用{{ia}}模板加標點，幾乎是純Wikitext方案。如果您覺得這方向可以走，可以從這裡繼續討論。

我想段落縮進等等近日討論到的排版需求，也都可以用這個方案解決。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月5日 (三) 07:35 (UTC)

非常感謝閣下的貢獻。英文維基文庫的動態佈局使用很久了，其脚本應該可以拿過來修改而不太會有安全問題。樣式上還請社群討論。支持用Javascript脚本，和模板配合，允許讀者自訂直排與橫排，脚本和模板方案可并存。

在此之上，本人希望的是MediaWiki 增加類似{{DIRECTIONMARK}}的魔術字，或類似百科語言變體代碼的頁面變量，標記排版方向並允許讀者修改，這樣可以讓模板依文字方向不同而生成不同Wikitext，達到更多功能。惟是否技術上可行，還未考慮好。

請問單個使用者如何測試閣下的脚本？ Andayunxiao（留言） 2025年3月5日 (三) 16:01 (UTC)

要測試腳本，須將腳本抄寫一份到使用者頁下的/common.js，再編輯

1. 第62行改成硬連結mw.loader.load("//https://zh.wikisource.org/w/index.php?title=User:Aerotinge/Gadget-sandbox.js&action=raw&ctype=text/javascript");
2. 第63行改成硬連結mw.loader.load("//https://zh.wikisource.org/w/index.php?title=User:Aerotinge/Gadget-sandbox.css&action=raw&ctype=text/css", "text/css");
3. 刪除第65行，那個小工具與這事無關。

對/common.js保存後，到參數設定把本地的頁碼小工具(寫著在左側增加“顯示選項”並允許顯示頁碼。（預設）的那個)給關上。刷新任一作品頁面，動態佈局會出現在主選單下方。

要關閉測試只需要反著做一遍，然後刪除瀏覽器的本站Cookie跟暫存(會使用戶登出文庫)即可。

用魔術字或頁面變量以標記預設、或覆寫版面方向是個有趣的想法。

我也有過類似的思路，即是看能不能在Index:命名空間的資料結構中再增加一項「行文方向」值，並隨著嵌入時一併回傳到作品頁，讓動態佈局js接收處理。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月6日 (四) 02:25 (UTC)

是的，閣下之前提出的「行文方向」值得作爲提案提出。可類別字詞處理：百科站上同時存在編者，和讀者指定的用字。和排版方向類比如下：

字詞處理	排版方向	相通點
編者用字，地區詞	編者指定的排版方向 由校對擴展輸出的源碼中的「行文方向」值指定 模板，樣式中隱性指定的方向	保存在源碼中 解決編者間爭議和偏好 實施後可禁止繁簡破壞/排版破壞
讀者選擇用字變體 可預設偏好，也可每頁臨時指定	讀者選擇的排版方向 頁面變量 JavaScript 每頁指定	讀者選項覆蓋編者選項 不完美但可用 如果不使用JavaScript 則需重新加載頁面（parser 需要重新解析源碼）

頁面變量方案有一點困難是，Mediawiki未必允許提供這種用戶可按頁更改的變量給模板使用。即使允許也可能必須反映在位址上，類似zh.wikisource.org/zh-hant/v/桃花源記，如此則臃腫且波及過廣，幾乎不可期待。

Andayunxiao（留言） 2025年3月6日 (四) 07:11 (UTC)

另外，允許讀者選擇顯示的用字變體（方向），和允許不同編者使用不同偏好寫作（錄入），方針上和技術上說，都是同一件事；如頁面用字變體（方向）如果只能由本頁編者或社群共識決定，必然無法允許不同偏好，要麽分家，要麽出現「維基百科:維基百科:條目所有權」（本地是作品所有權），違背維基運動旨意。因此其不單有益讀者，也有助社群協作並減少爭議。 Andayunxiao（留言） 2025年3月6日 (四) 07:24 (UTC)

已在多個作品頁試用，直排（樣式2）下文字都可顯示，未察覺有錯誤。閣下是否已有後續開發想法，抑或希望討論？技術細節如果在寫字間討論過於繁瑣，也可移步專頁或使用者討論頁。我還沒有明白英文原小工具的個別功能。直排頁碼似乎可以用樣式上inset-block代替y來實現。

向後兼容可能只需要兼容{{Vtext2Start}} 與 {{SKQS header}} 兩大最多用的模板的正文源碼的換行方式，避免修改頁面正文。最好能提供「直排轉橫排去換行」的選擇。因歷史錄入方式的限制，除非批量修改頁面，否則無法判斷已有頁面正文代碼中的換行的語義是「橫排新段」，「直排新段」，「直排古書新行」中的哪一種。頁面變量，「行文方向」值方案，或者模板，都恐對此無助。提供「去換行」雖對不適合的頁面會有誤，但讀者可自行決定。 Andayunxiao（留言） 2025年3月8日 (六) 17:59 (UTC)

目前仍希望在此討論並收穫意見。之後若能得採用後，可以封存到MediaWiki_talk:Gadget-PageNumbers-core.js。

我想如果您對「將英文文庫Layout功能，移植到中文文庫時改作橫、縱書排版」這一行為可以接受。

那我想更動一些地方：

1. layout_1改作保留用排版，無樣式。
2. layout_2改作套用橫書排版(對於縱書原作轉橫，並做一些樣式變化支援，如雙行注文展開至單行、行間標點展開至行內、去挪抬/平抬等封建老一套不符現代閱讀習慣之處)
3. layout_3改作套用縱書排版(對於橫書原作轉直，並做一些樣式變化支援，例如章節底下首段縮排)
4. layout_4若是真想不出用處，提議直接拿掉(需要修改js本體)
5. 襯線體開關於中文環境也少用到。要挪改作中文字體開關如：黑體/楷體(明體、宋體)切換也有難行處。若是實務上無辦法提供字體以供渲染，或可拿掉(需要修改js本體)。
6. 小工具文字的改動。我是覺得直翻過來的指示文字在使用上很不直觀，不知您怎麼想？
   我會希望其直接顯示當前狀態，如下
   

   :::	var standard_layouts = [
   :::		{
   :::			id: 'layout_1',
   :::			name: '目前排版：無' // Old: name: '排版 1'
   :::		},
   :::		{
   :::			id: 'layout_2',
   :::			name: '目前排版：橫排' // Old: name: '排版 2'
   :::		},
   :::		{
   :::			id: 'layout_3',
   :::			name: '目前排版：直排' // Old: name: '排版 3'
   :::		}
   :::	];
   :::
   

至於一件作品的排版是橫是縱、是手書(楷體)/雕版(宋體;仿宋)/活字or刷印(明體;宋体)、甚至是一頁行寬(行高)幾em，我想可以參考Default layout讓貢獻者在作品裡自行作定義，再由本工具接手套用樣式。

畢竟要MediaWiki上游做出改動實在不太現實，還是先用手邊有的湊合湊合。

頁碼直排是一個我有看到，但沒能去弄懂的問題。這點有請您進一步指教了。

向後兼容這事，我倒沒想過要做到兼容，也同是出自考慮歷史因素。

而「去換行」，我記得有個小工具好像就是負責這事的，應是可以分工協力，無須統攬在動態佈局上。畢竟這小工具應當專注於佈局。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月9日 (日) 11:46 (UTC)

蒙古国从2025年起全面恢复使用直排的传统蒙文，都没能让MediaWiki支持直排，目前最好还是使用可以本地修改的小工具实现。在有页码的页面里使用直排排版会导致页码无法正常显示。这需要在小工具中考虑直排。 Midleading（留言） 2025年3月9日 (日) 15:53 (UTC)

 支持用此功能實現橫排，直排樣式。從安全和易用兩點都是目前最佳。即便未來有了上游支持，讀者端選擇也只能用 JavaScript 腳本，恐不能像字詞轉換一樣，以位址來切換。現在就實現此工具，大有益處。

「兼容」的提法我解釋的不清楚，而且我還不瞭解閣下希望直排轉橫排後有何種效果。包括閣下所述各點，我考慮分幾個子話題下面分別討論可能更清楚。字體，選單，樣式變化支援可能不難後續追加，社群可能已有一定的共識，閣下的傾向可能已是優選。 Andayunxiao（留言） 2025年3月9日 (日) 16:25 (UTC)

「動態佈局」小工具的設計討論

直排轉橫排應該怎麽設計？

目前的腳本只實現了直排樣式（樣式2）。還不知道原本以直排模板嵌入或錄入的作品頁，如轉爲橫排，預設怎樣樣式？

如以{{Vtext2Start}} 錄入的四部叢刊頁面，都是按原書單行展示的。以小工具轉爲橫排（樣式3）後，是仍維持原書每行為一行（窄模式），還是接合各行為一段（寬模式）呢？Andayunxiao（留言） 2025年3月9日 (日) 16:40 (UTC)

將本地歷史直排模板，如{{Vtext2Start}}等直接應用於正文的作品，不能也不會被轉為橫書。

因為小工具是在mw-content-text文本容器增加.dynlayout-layout_x類來套用樣式。而寫在文本內的書寫方向樣式，不能也不會被覆蓋。

我前述所說的套用橫書排版(對於縱書原作轉橫係指「原文為縱書的作品，使其於橫書顯示時也能按橫書習慣排版。即是說，應該分項的分項(模擬Wikitext * )、列點的列點(Wikitext # )、該作標題的作標題(還原大字<h3>, <h4>...樣式)等等」。

並不是說在主命名空間或校對頁頁身已套用直排模板的作品，還能硬轉成橫書。

如果一件作品本身就已經由貢獻者使用直排模板排版過，應視為已有指定預設排版。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:21 (UTC)

是的。同意目前小工具的原理還不足以讓直排模板轉橫書。現在的小工具樣式已經很好了。我希望也能開發功能，實現如尚書_(四部叢刊本)/卷第五的頁面在「目前排版：橫排」下也能橫排，當然牽扯較多，還需試驗和再議。也同意「寫在文本內的書寫方向樣式」，或者説，行内CSS樣式，是會覆蓋小工具的樣式的。如果小工具未來能變成全站預設，那麽到時可以推動共識，不要在行内指定書寫方向，類似百科有了字詞轉換後，就不該再允許全條目不轉換。 Andayunxiao（留言） 2025年3月13日 (四) 05:46 (UTC)

行高

直排樣式（樣式2）必須要預設一個默認行高才能顯示得好看。古籍的行高并無統一數值，如超出預設值則會折斷各行。能否允許模板或索引頁樣式表覆蓋小工具的預設行高？Andayunxiao（留言） 2025年3月9日 (日) 16:49 (UTC)

行高，如前述可以參考Default layout讓貢獻者在作品裡自行作定義，本就有保留用模板覆蓋預設行高的空間。我是打算用模板{{Default layout|Layout 3|line_h=40}}這樣的方式，然後讓模板跑一串#ifexpr決定要載入<templatestyles src="..." />哪一個行高CSS，例如：

:.dynlayout-layout_3 .ws-region-container { /* Default_layout_參數_40字行高 */
:	--CJK_chars_per_line: calc(40em / 0.83);
:}

但MediaWiki的"sanitized-css"不允許變數，我有想了幾個方法解套，但要先請示管理員許可，甚至是要由管理員操作。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:29 (UTC)

算了，CSS小把戲不管用。我直接改了js本體來承擔傳值工作，但這有違代碼與樣式分離原則，請您審閱一下代碼變更並給予意見。

目前是可用模板{{Default layout|V|cpr=40}}來指定直排(V)，每行行高40em。由於瀏覽器渲染等種種因素，40em不總是等於40字行高。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 08:11 (UTC)

純CSS方案可以用:has()選擇器，已測此選擇器在文庫可用，惟近年舊版本瀏覽器可能不支持，可能JS方案更好。此方案一如，外層使用

:::.outerdiv {
:::    height:30em;
:::}
:::.outerdiv:has(.innerdiv.dynlayout-custom-height) {
:::    height:unset;
:::}
:::

内層使用

:::.innerdiv{
:::    height:40em;
:::}
:::<div class="innerdiv dynlayout-custom-height"></div>
:::

也許可以用JS實現類似功能，即，如有以dynlayout-custom-height標記的内部div，則取消外部預設行高？ Andayunxiao（留言） 2025年3月13日 (四) 06:12 (UTC)

我怎麼印象中:has父選擇器不被"Sanitized CSS"許可。

晚點來試寫看看，如果可以使用，那事情會好些。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月13日 (四) 09:01 (UTC)

選單

小工具文字的改動。我是覺得直翻過來的指示文字在使用上很不直觀，
— User:Aerotinge

現皮膚 Vector 2022 的外觀選單，即無線電鈕，可能比原地切換「樣式1234」要好。英文文庫原工具選單設計就不佳，和百科的界面不很協調，也很少見主流網站有這樣切換的。之外的各開/關按鈕，最好有圖像支持，但我不知道界面是否允許。如果不可，那麽閣下所説的「標識目前狀態」更佳。或者以字體或樣式區分，如：襯線體 | 無襯線體 （按一下變成） 襯線體 | 無襯線體。Andayunxiao（留言） 2025年3月9日 (日) 17:07 (UTC)

考慮到要同時支援Vector、Vector 2022、Minerva、Timeless、Monobook五大外觀，純文字連結以外的選單介面嘛...至少我是做不來，需要介面管理員等熟悉MediaWiki UI的高手介入。

開關用ON|OFF這個方案不錯。

至於圖像支持，我也不確定可行性。如果不可行，也可以看看有那些Emoji適用(Emoji也會有缺字體渲染可能，故有MediaWiki或jQ提供支援者佳)。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:31 (UTC)

配合模板

英文文庫原工具的原理是在包含頁面内容的元素id="mw-content-text"加入dynlayout-layout_1類名，允許配合Mediawiki 空間内的樣式表文件，但不允許模板樣式自訂配合，只有en:Template:Sidenote一個模板有配合，然而是在上述樣式表内寫入的。本站是否有配合需求？一種改法是給mw-parser-output ws-page-container類的<div>也加上動態類名，則能允許模板樣式自訂。Andayunxiao（留言） 2025年3月9日 (日) 17:23 (UTC)

有配合需求。我已在樣式內寫了兩個模板的配套。我想您的側批、眉批等模板應該也需要寫配套樣式。

在Mediawiki命名空間外允許模板樣式自訂，我擔憂的的地方在於引用的自訂樣式是否合法。

固然一個模板或Index樣式安分的定義自己的div.dynlayout-layout_2 .wst-self {}是理想狀態，但也開了干涉其他模板、乃至本體樣式.dynlayout-layout_x的可能性。

(不過用戶真硬要自個兒套個樣式按上，我們也沒法子管就是)

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:36 (UTC)

防止模板樣式外溢只靠自覺和社群共識，但關鍵和高可見模板本來就已鎖定編輯，因此可能并無安全之虞。我的{{Side annotation}}等模板需要魔術字配合（因希望輸出不同Wikitext），和此處關係不大。此處是想討論，是允許編者在模板樣式内自訂，還是只能在Mediawiki 空間内的樣式表内集中追加？後者只能請求管理員操作。 Andayunxiao（留言） 2025年3月13日 (四) 06:19 (UTC)

我個人意見是只在Mediawiki添加對模板樣式支援，所以要在這個討論階段把該寫的都給寫上，一次性提交。往後就不方便修改了。

當然實務上我也覺得放開在Index:等空間自訂要方便得多，也是很難拿捏。

要不把那個「已啟用預設排版」的功能也來點改寫擴充？改成「僅啟用小工具預設樣式」/「已啟用作品自訂樣式」云云，來做開關。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月13日 (四) 09:11 (UTC)

例外

和字詞轉換相同，可以允許編者指定某些段落不轉換。如前赤壁賦的竪排版和真跡圖像對照，如轉換為橫排，則失去原意。現工具已經將頁首標題模板和頁脚排除在動態佈局外，方法是以dynlayout-exempt 等類標記。似乎可以據此製作模板，或直接修改作品頁源碼。Andayunxiao（留言） 2025年3月9日 (日) 17:40 (UTC)

是的，可製作標記模板以用於部分排除轉換。

我個人目前則是偏向導入{{Default layout|Layout 1}}模板用以指定"目前排版：無"，並添加模板到該類作品作全局排除就好。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:40 (UTC)

頁碼

原工具的頁碼不能在直排下正確顯示，可能是因爲原方法是渲染後計算.offset()值來確定頁碼位置的。腳本不同於模板，可能無法預覽效果，請問本人如果想要改進腳本，如何協作？是在使用者頁各立新版本，還是在同一處編輯？Andayunxiao（留言） 2025年3月9日 (日) 17:40 (UTC)

請直接於您的使用者頁fork一份改寫即可，有需要測試時也請{{ping}}我抄寫回一份以回饋意見。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月11日 (二) 03:41 (UTC)

我將另立一個版本，試試只修復此處，不涉其他。須判斷當前樣式的書寫方向，或在Cookie保存此資訊。和其他功能的對接會需要微調。 Andayunxiao（留言） 2025年3月13日 (四) 06:24 (UTC)

《国（境）外学历学位认证办法》是否具有行政性质？

该文件。已知事实：

1. 该文件作者“教育部留学服务中心”是教育部直属事业单位，不是政府部门。

2. “国（境）外学历学位认证”位于教育部官网的“服务”栏目中，里面标注“系留服中心依据国务院教育行政部门为其核定的机构职能，面向社会开展的一项服务。”

3. 学历学位认证工作经教育部2000年文件《关于同意“教育部留学服务中心”和“全国学位与研究生教育发展中心”开展外国学位证书认证咨询工作的通知》（学位【2000】2号）授权。

因此想讨论“学历学位认证”是否属于教育部授权由事业单位承担的行政职能。 曾晋哲（留言） 2025年2月14日 (五) 14:22 (UTC)

个人意见，不是，见[104]。有一个案例在裁判文书网上还有，刘远东与教育部，因为案涉裁定书太多我就不一一列了，但就在下所见那里的中心思想之一是：教育部没有国外学历学位认证这一法定职责——北京中院这么说，教育部自己也这么说（而且是在基于有《通知》的基础上这么说）。个人所见，教育部固然有“负责国际间学位对等、学位互认等工作”的职权（见国务院办公厅关于印发教育部主要职责内设机构和人员编制规定的通知），但它跟学历认证这一专业认证是两码事，学历认证本身不是行政职权，教育部的文件是同意（或授权）相关单位“可以”做这个，而不是授权相关单位“代它”干这个——作一个不恰当的类比，就是教育部授权其“专营”。 银色雪莉（留言） 2025年2月14日 (五) 16:44 (UTC)

认证看似专业服务，实则由教育部授权，服务于教育管理和人才流动。其结果具有官方权威性，在行政管理中被广泛采纳。由此观之，认证可被视为教育部将其部分与学历学位管理相关的职责，委托或授权给其下属事业单位执行。故“学历学位认证”是教育部授权其直属事业单位承担的公共服务职能。虽非典型审批，但在行政机关（教育部）的明确授权和规范下进行，其结果直接服务于公共管理与行政目的。故认证具有一定的行政性质，可被视为源于行政授权的特定管理服务职能，带有行政管理的色彩。--Zy26（留言） 2025年4月1日 (二) 09:05 (UTC)

模板分類參數

依據這個修改，似乎有些模板的「cat=no」參數不作用，是否能夠修復？—— Eric Liu_（留言） 2025年2月14日 (五) 15:03 (UTC)

完成。顺便请帮我删除Module:Suppress categories，我建重复了。 Kcx36（留言） 2025年2月14日 (五) 19:10 (UTC)

k —— Eric Liu_（留言） 2025年2月19日 (三) 06:43 (UTC)

把台灣教育部《異體字在線字典》的字體樣式表下載搬運至本站。能一勞永逸解決絕大部分異體字缺失問題。

根據《異體字在線字典》說明介紹，收錄大約10w個異體字。針對收錄的每個異體字，並非通過加載位圖圖像或svg矢量圖的方式來顯示。也非類似本站通過字形結構膠水式拼接的模版給出標註，從而曲線達到目的，而是自製一套異體字font-face字體文件，用戶通過瀏覽器訪問時下載、加載該字體文件，進行前端異體字渲染。

以上是原理，好處是font-face由於是基於css的規則，對於瀏覽器來說更加原生，加載渲染效率好，同時收錄全面。

例如 Page:KYTU-BB04492447 督戎疏紀1.pdf/36 中「廷」對應的異體字。在其他線上字典如漢典中只能找到𢌜，但在《異體字在線字典》中就有收錄。

現在的問題是本站未安裝該網站的font-face文件，導致即便從其網站頁面中複製該文字，粘貼到本站時亦無法渲染。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月17日 (一) 15:52 (UTC)

教育部該網站的內容不符合{{PD-ROC-exempt}}中的任何一項，存在版權疑慮。 Midleading（留言） 2025年2月17日 (一) 16:16 (UTC)

這條路子早已有類似討論，我也試過。首先維基媒體基金會不允許CSS去外連外部資源這關就過不去，

而維基共享資源也不收字體檔案，所以沒得內連。

就算能上傳字體至維基共享資源，教育部異體字字型亦不提供SIL授權以相容維基共享資源所需的CC-BY-SA 3.0授權，故不得再分發。

就算教育部提供授權，其異體字用的也是Unicode PUA B區碼位，皆為外字。不利文獻保存流通，應當避免使用。目前已有機器人巡查PUA字並標記待清除，故不應再增加外字使用。

現在的模板曲線方案已經是碰壁試錯後，得到的相對可行方案了。 Aerotinge（留言） 2025年2月17日 (一) 16:17 (UTC)

不是引用外鏈獲取，而是下載字體庫文件，在本地服務器安裝。

字體拼接模版後的異體字，也無法保存流通，下載後也無法直接複製使用（顯示爲模版原生標記語言，非php語言環境無法渲染）。

而Unicode的非官方字，只要維護好一套使用標準，數量夠多，至少線上渲染時足夠簡潔美觀。也省去了很多異體字逐個都拼接的麻煩。

《異體字在線字典》下方外鏈的辭典公眾授權網，裡面有關於字典內容的引用方式和授權標準。使用的是「創用CC-姓名標示- 禁止改作 3.0 臺灣授權條款」。允許使用者重製、散布、傳輸著作（包括商業性利用）。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月17日 (一) 16:58 (UTC)

禁止改作不符合維基版權方針，維基要求授權允許使用者改編、匯編以及商業性利用。同時，網站下方有©版權聲明。 Midleading（留言） 2025年2月17日 (一) 17:24 (UTC)

2025年第8期技術新聞

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

本週要聞

• 現在，使用Growth工具的社群可以在Special:首页給新手展示一則活動。這項功能將幫助新手了解可以參與的編輯活動。管理員可以在Special:CommunityConfiguration新建活動展示。參見Diff文章、文档，或聯絡Growth團隊了解更多。

近況更新 - 面向編輯者

討論頁改進，圖中以粉紅色方框強調

• 從下週開始，四個維基的討論頁將採用新設計。這些維基包括：西班牙语维基百科、​法语维基百科、​意大利语维基百科、​日文维基百科。這項變更已作為測試功能進行了廣泛測試，是討論頁改進的最後一步。 [105]
• 现在，在操作页面（例如查看历史记录的页面）点击重定向页面的链接可以直接前往重定向页面。先前则必须先跳转到重定向目标再前往。此项更改会为处理重定向的编辑者带来很大的帮助。感謝stjn所做的改進。 [106]
• 目前，當Cite參考資料被多次重複使用時，參考資料清單中會顯示如「1.23」的數字標記或如「a b c」的本地化字母標記。先前，如果重用次數太多，以致於字母標記用盡，系統會顯示一則錯誤消息。作為Cite自訂現代化工程的一部分，將不再顯示這些錯誤消息；一旦字母標記用盡，反向链接將恢復顯示如「1.23」的數字標記。
• 现在，每条用户组更改日誌的显示都更加清晰，目前会分别列出授予、撤销、更改的群组，而不再是简单列出更改前后是哪些群组。译者可以帮忙更新相关消息的本地化版本。感謝Msz2001所做的改進。
• Special:大量删除工具新增篩選項，現在可用頁面大小（位元組）範圍來篩選頁面。管理員可以用這項功能刪除小於特定大小的頁面。 [107]
• 此外，非管理員——即使無法直接刪除頁面——現在可以使用Special:大量删除工具檢查哪些頁面可能需要刪除。感謝MolecularPilot所做的這兩項改進。 [108]
• 上週有25個社群提交的工單得到解決。 例如，AV1視訊檔案格式配置中的一個錯誤得到修復，使這些檔案再度能夠正常播放。 [109]

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

• 繼去年維基導遊成功轉換成Parsoid閱讀視圖之後，未來幾週內，Parsoid閱讀視圖將在大多數維基詞典推出。參閱Parsoid/解析器統一了解更多。 [110][111]
• 站内工具的开发者请注意，mw.Uri已弃用。仍依赖mw.Uri的工具必须显式声明mediawiki.Uri作为ResourceLoader依赖，且应尽快迁移到浏览器原生的URL这一API。 [112]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年2月17日 (一) 21:16 (UTC)

我有一個想法

古代時候，葡萄牙、荷蘭、英國、俄羅斯等國家曾經不是跟中國、朝鮮、日本等地區做生意嗎？或許這些國家的圖書館/大學圖書館裡面會有一些逸存書。有沒有人能夠幫我們檢查一下？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月19日 (三) 04:07 (UTC)

因為你們想想，這些交易、貿易裡或許存在一些圖書等物品。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月19日 (三) 04:13 (UTC)

實際上歐美（包括日本）確實有很多散佚的中文古籍（通過不僅限於貿易、盜買、劫掠等手段），而且有不少孤本，比如敦煌殘卷，還有“漢籍合璧項目”從俄羅斯聖彼得堡大學圖書館獲得的《鐵冶志》。只是尋訪逸書的工作需要經費人力，即便如有官方支持的“漢籍合璧”項目，也未見其網站公佈更多的成果，可想是不太容易。 Liouxiao（留言） 2025年2月19日 (三) 05:47 (UTC)

光有想法沒有資金是無法實現的。尋求他人幫助時即便是為公義而非私利，也應該支付代價。

如果需要調用大量人手做事，應該要先籌措資金，通過商業化活動支付佣金方能達到目的。動用私財來支付總非長久之計。

本人的想法是成立基金會，聘請專業的投資經紀人，開展金融投資交易，獲利增值後，拿盈利來實現目的。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月19日 (三) 20:14 (UTC)

魯迅全集01 (1948).pdf錄入的異體字和格式問題

@David, but not Hilbert，@Aerotinge，感謝各位在#重写维基文库方针和说明文档話題下補充問題和貢獻討論。上面的討論可能已經偏離原話題，我的初始回答也未解決David閣下的問題。提請後續討論在此話題下繼續。Andayunxiao（留言） 2025年2月19日 (三) 07:18 (UTC)

錄入異體字的原則

承上討論，此問題包括「識讀原字」和「確定編碼」。前者需要編者熟悉傳承字寫法，有時還需要熟悉書法，但求助社群通常可以得到解決。後者則是技術問題。Unicode 非爲古籍錄入設計，其「認同原則」和「原字集分離原則」矛盾，後續的變體序列也僅考慮了字體渲染，文庫未曾使用且未必能適應本地架構。簡要的編者規則很難制定。Andayunxiao（留言） 2025年2月19日 (三) 07:57 (UTC)

異體字查詢

幾個外部查詢來源並請補充：

• 教育部異體字字典 收字多且有來源，用例和影印（拓本）圖像。
• https://glyphwiki.org 字形為使用者生成，通常可以查到同一個編碼對應的各地不同字形。
  • 例如「直」 的不同變體。個人認爲，現階段按Unicode 認同原則有同一編碼的異體字不需要以模板額外標注，除非字形於原文特別重要。
• en:wikt:Main page，英文維基詞典。
• 中國哲學書電子化計劃的字典功能。其優點是對古籍用字有典籍用例，適合不確定原字是否是筆誤的情況。

—以上未簽名的留言由Andayunxiao（對話｜貢獻）於2025年2月19日 (三) 08:19加入。

• 漢典网（例：为）在宽屏界面会显示简繁和异体字，来源不明。
• Unihan 数据库会列出 variants（例：值），由Unicode维护，可靠但缺漏严重。该网站搜索较慢，可先用 UniView 搜索（例：值），再选字，view data in Unihan database。UniView 的开发者隶属于W3C，应该也比较可靠。

David, but not Hilbert（留言） 2025年2月19日 (三) 08:51 (UTC)

我慣用IDS結構去查字，提供幾個外部工具

• CNS全字庫：CNS標準，可以由此反查教育部異體字典等台灣工具網站。
• IRG工作組：就是搞Unicode規範的小組，會收不少提交上來的異體字
• 字統网：作者好像也是IRG的小組成員。支援結構模糊查找，功能強大。附帶一個類似GlyphWiki的組字引擎，習慣筆畫輸入的用戶可以組合出各種可能性。

Aerotinge（留言） 2025年2月19日 (三) 09:04 (UTC)

值 ≠ 値

值 ≠ 値，可右边的的“直”似乎只有一个码？
— User:David, but not Hilbert

Andayunxiao（留言） 2025年2月19日 (三) 07:43 (UTC)

段落縮進

请看Page:魯迅全集01_(1948).pdf/323。全文无段间距，每段首行缩进；但是『小栓——你坐着，不要到這裏來。』这句似乎是插在段中间，它自己这行缩进两字，下一行打头写。
我在此用了<br>和{{gap}}，不知是否合适？（我在段首加{{gap}}是沿用这部作品既有做法，并非有所偏好。）
— User:David, but not Hilbert

Andayunxiao（留言） 2025年2月19日 (三) 07:43 (UTC)

我覺得這是印工失誤產生的的瑕疵。因不涉文字内容，閣下可自由決定。如要求完美，可比較Page:Sandbox.djvu/30所示的，<br>單個，兩個，與兩個\n（效果是<p>標簽)，三種換行的間距在本站各不相同。 Andayunxiao（留言） 2025年2月22日 (六) 15:55 (UTC)

依愚見，這或許是編輯刻意為之的排版，造就一種像是台本的風格，強化對白感。當然更可能是我想多了。

如果要我來1:1復刻這樣的效果的話，我會

• 於文本用<br class="shifted-dial">換行，接<span>『</span>喫下去...錄入該行剩下內容。
• 於樣式上個.shifted-dial + span { margin-inline-start: 2em; } 。讓這種特殊的br後跟著的span(夾起來的『符號)縮進兩個字元，達到排版效果。

但就是麻煩，說真的。好險我少錄現代作品。 Aerotinge（留言） 2025年2月22日 (六) 16:23 (UTC)

找到相關說明了，在W3C日文排版需求中 §3.5.1一節有提到。魯迅全集這裡用的是一種變體風格，見 §3.1.5一節裡「圖72」的示例。

不過轉成橫排後還要不要、能不能保留這樣的風格，這我就不清楚了，因我印象也只在直排書中看過這樣的排版。 Aerotinge（留言） 2025年2月24日 (一) 13:06 (UTC)

这是印工失误产生的的瑕疵

这或许是编辑刻意为之的排版

我找了人民文学出版社的横排简化字版（ISBN 7-02-005834-5，2006年12月第1次印刷），31页对应此处，保留了这种特殊缩进。看来人民文学出版社的编辑认为是刻意为之，而非印工失误。 David, but not Hilbert（留言） 2025年2月28日 (五) 11:57 (UTC)

感謝兩位的指點。 Andayunxiao（留言） 2025年2月28日 (五) 17:19 (UTC)

直角引號用法

请看Page:魯迅全集01_(1948).pdf/361的『七斤嫂，你「恨棒打人」。……』 。原文用直角引号，但并非「『』」，而是『「」』。在“不转换”和“繁体”模式，与原文一致，我没有疑问；可在“简体”模式时，引号会转换成‘“”’，既不合原文，又与今日习惯相反。
有无办法在特定页面关闭引号转换？
— User:David, but not Hilbert

Andayunxiao（留言） 2025年2月19日 (三) 07:43 (UTC)

同樣還是請見沙盒示例，頁首的

-{H|「=>zh-hans:「;」=>zh-hans:」;『=>zh-hans:『;』=>zh-hans:』}-

可用於強制指定“简体”模式的轉換規則。 Aerotinge（留言） 2025年2月20日 (四) 03:40 (UTC)

行間排版的標點和引號的順序

也请看Page:魯迅全集01_(1948).pdf/361的『七斤嫂，你「恨棒打人」。……』。原文标点二维排布，引号、省略号作为行内标点依次放在“人”下方，句号作为行间标点放在“人”右方。
然而录入时只有一维，。」……、」。……、」……。选哪个？
— User:David, but not Hilbert

Andayunxiao（留言） 2025年2月19日 (三) 07:43 (UTC)

感謝User:David, but not Hilbert閣下舉例，此問題可能并不簡單。行内樣式的早期新式標點，標準可能已經和今日相同，即直接引文的句號在引號内，但强調語匯的引號内無末尾句號。還請熟悉標點歷史的編者賜教。幾個可能相關的文獻：

• File:CADAL3008526_紅樓夢（一）.djvu。1927年亞東圖書館，汪原放標點本《紅樓夢》。
• File:SSID-13427406_標點符號使用法.pdf。見其59頁起「句號無形的消滅」的解釋，可能一窺當日的理解：[113]。

Andayunxiao（留言） 2025年2月19日 (三) 08:34 (UTC)

我还听说过一种说法（没有确切来源了），与胡怀琛“句号无形的消灭”的解释不同：句号表示停顿，而引号读不出来，所以二者没有严格先后；但句号点在汉字旁边更美观，便如此布置。

无论当时标准与今日相同，还是当时只考虑美观性而无标准，在模棱两可的地方，我认为可以按今日标准录入。 David, but not Hilbert（留言） 2025年2月19日 (三) 13:21 (UTC)

以本作品的排版，我試著弄了個高仿P.361，並錄到沙盒呈現嵌入後效果。

從模板展開嵌入後的狀態，標點順序您看來，有何不妥適處？

這種有影像供校對的，只要忠實還原行文方式，將其邏輯理清後，最後展開便是該作品的原標點順序。

或許會稍與今日的标准/標準有所出入，竊以為還是忠實於原文較佳，也較為方便。

至於沒有原件來源供校對的作品，或是用戶自行加點的文字。理當可以按标准/標準編輯並錄入。 Aerotinge（留言） 2025年2月19日 (三) 16:30 (UTC)

原来还能这样，感谢您演示这种方法！

不过我可能没表达清楚，我也支持忠于原文——我之所以建议按今日标准录入，是因为认为三种方法都不忠于原文。打个比方，人类（原文）有左右两只手，外星人（录入版）发明了三种克隆方法，但都是把双手放到同一胳膊上，区别仅在左右手串联方式。在这种情况下，选择外星人的天然生长方式比较好。

关于{{ip}}，我认为」{{ip|。}}与{{ip|。}}」在直排时应渲染成相同样子，现在不同属于 bug。 David, but not Hilbert（留言） 2025年2月19日 (三) 18:19 (UTC)

高仿不錯，如果可以支持文本複製帶標點就更好了。 Liouxiao（留言） 2025年2月20日 (四) 01:33 (UTC)

@Aerotinge, Liouxiao：我用AI写了{{Interlinear punctuation auto}}，无需每个标点添加模板，只需要在页眉添加{{Interlinear punctuation auto|，在页脚添加}}即可实现相同效果：Page:Sandbox.djvu/5。--維基小霸王（留言） 2025年2月20日 (四) 02:44 (UTC)

感謝Aerotinge，維基小霸王的貢獻！對從校對頁嵌入時替換所有中文標點的方案，我和之前文庫討論一樣，有維護和穩健性的擔憂，更希望獲得 MediaWiki 原生的支持。但此處如只替換幾個只用於行外的標點，Module:Interlinear punctuation auto的方案更利於維護，也可兼顧讓原始 WikiText 更易讀。如社群有共識和需求，可協助整合到其他校對頁使用的頁眉頁脚模板以作爲參數選項。 Andayunxiao（留言） 2025年2月20日 (四) 06:52 (UTC)

您好，我恰好剛剛創建了兩個模板，見下面的討論。 維基小霸王（留言） 2025年2月20日 (四) 04:20 (UTC)

如果内容長了，圖片就無法顯示，如Page:Sandbox.djvu/4。請問如何修改？我嘗試了chatgpt很多次都不行。 維基小霸王（留言） 2025年2月20日 (四) 06:53 (UTC)

您是說校對頁右邊的書影圖片嗎？我看還是有的。會不會是所用的Skin、用戶自訂樣式，或是裝置畫面大小導致？ Aerotinge（留言） 2025年2月20日 (四) 08:05 (UTC)

我的chrome浏览器显示成这样：[114]。为了避免自定样式的影像，使用的是匿名模式。 維基小霸王（留言） 2025年2月20日 (四) 08:25 (UTC)

是了，Chrome開起來的確是這樣。我原先用的火狐還能看到，到了Chrome圖片便被擠出畫面了。不知是哪條樣式跟Chrome犯沖。 Aerotinge（留言） 2025年2月20日 (四) 09:00 (UTC)

同意Andayunxiao君所言。Interlinear punctuation auto模組在其本分工作上實在相當出色。往後若有編輯手冊，可將其作為錄入該時代圖書標點版型的推薦方式。 Aerotinge（留言） 2025年2月20日 (四) 08:03 (UTC)

也感謝閣下創作並分享模板。即使是英文文庫，据我有限的體驗，校對頁面的模板也是五花八門，少有强制標準。當然，西文編者更容易接受模板，而本地尚有語言障礙，非中文字符太多，或模板選擇太多，難免勸退新手，這也是我不希望原始代碼過複雜的一點點擔憂。 Andayunxiao（留言） 2025年2月20日 (四) 08:55 (UTC)

模板樣式如允許user-select:all;可允許選擇文本時包括行間標點，可幫助需要直接複製文本的讀者。 Andayunxiao（留言） 2025年2月22日 (六) 15:43 (UTC)

我找了人民文学出版社的横排简化字版（ISBN 7-02-005834-5，2006年12月第1次印刷，下文简称《人》），查了几处。这当然对录入原文意义有限，但参考一下还是可以的吧。

以下每个例子中，标红的字符在魯迅全集01_(1948).pdf中对齐。

• Page:魯迅全集01_(1948).pdf/315，《人》23页：

什么“君子固穷”，什么“者乎”之类

• Page:魯迅全集01_(1948).pdf/320，《人》29页：

“倒高兴……。”

• Page:魯迅全集01_(1948).pdf/331，《人》37页：

“这是怎么一回事呢？……”

• Page:魯迅全集01_(1948).pdf/336，《人》41页：

“怎样……？”

• Page:魯迅全集01_(1948).pdf/354，《人》56页：

“这老不死的！”

• Page:魯迅全集01_(1948).pdf/361，《人》61页：（删除了行间的“。”）

“七斤嫂，你‘恨棒打人’……”

David, but not Hilbert（留言） 2025年2月28日 (五) 12:31 (UTC)

感謝閣下的示例。我還沒有新的看法，但本人無意參與錄入此作品，因此可不必等待本人的意見。

之前列出胡懷琛的解釋，我也非要論證哪種解釋更正確，而是以爲，可以按原書出版同時代的行内標點規則錄入。以閣下的比喻，更接近是外星人按人類自己的方式克隆人類。 Andayunxiao（留言） 2025年3月1日 (六) 16:55 (UTC)

{{nop}} 模板的使用場景

我看也有给末段套<p>的（暂时未翻到是哪里），请问有区别吗？
— User:David, but not Hilbert

Andayunxiao（留言） 2025年2月19日 (三) 07:43 (UTC)

補充User:Aerotinge閣下的説明：維基文庫使用Extension:Proofread Page 擴展處理校對（page）頁嵌入，其原理很不巧是單獨解析（parse）每個頁面，故每個page 頁面内模板必須成對或閉合，禁止模板跨頁。見英文維基文庫的指南：en:Help:Page_breaks。很遺憾尚未翻譯為中文。 Andayunxiao（留言） 2025年2月19日 (三) 08:47 (UTC)

Andayunxiao（留言） 2025年2月19日 (三) 07:18 (UTC)

章太炎文字學作品裡的異體字過於罕見。不少都是金文文字。錄入十分困難。

字形難以辨認不說，很多古體字按照現有方式根本無法錄入。目前只能通過glyphwiki.org開發新字再上傳文字圖片的方式插入到該文字位置。

是時候請字體設計的程序員開發一套維基文庫自有的字體庫了。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月20日 (四) 02:55 (UTC)

最好的办法是直接用glyphwiki.org的字体。将glyphwiki的字体导入commons，定期更新，直接使用该站编号即可。未来有字体编入更新版本的unicode，替换也会很方便。 維基小霸王（留言） 2025年2月20日 (四) 04:23 (UTC)

現在解決方式過於雜亂多樣。而且隨著錄入文本體量增加，之後即便制定出較為完美的標準，也不得不花巨額成本，從頭修正因標準多樣造成的海量既定待修文本。

這也是工程學相關的行標比其他行業要嚴謹苛刻的多，沒有良好的設計規劃，寫出一大堆屎山那還不如一開始就不要開發。

畢竟程序內核的開發都是一次性的，未考慮周全寫到擴展功能時才發現出問題，推倒重來的成本太高。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月20日 (四) 10:39 (UTC)

新建模板：允許在page頁面以傳統版式顯示、在主頁面以現代方式顯示

古文需要以兩種方式顯示：現代版式和傳統版式。前者便於閲讀，後者便於校對。一種方法是同時創建兩者，比如督戎疏紀_(影印本)/卷之一和督戎疏紀/卷之一。但是這樣太費力，而且難以維護。我創建了兩個模板，以允許在page頁面以傳統版式顯示、在主頁面以現代方式顯示。

{{Transclude pages}}：替代<pages/>嵌入包含。請看夜航船/卷01和欽定古今圖書集成/博物彙編/藝術典/第001卷。該模板可以刪除每行閒的“\n”，這樣嵌入后換行閒就不會有空格了。另外，還支持mediawiki的標題目錄。（目前欽定古今圖書集成/博物彙編/藝術典/第002卷還是用傳統方式嵌入，就無法顯示目錄。）

{{Old text page}}：用於在page頁面以還原古書的方式顯示：竪排顯示，刪除標題（==標題==）兩旁的等號，刪除表點，將換行顯示。見Page:Ye Hang Chuan part 1.djvu/15。但是還有個問題沒有解決，那就是對於太長的文本，原圖就無法顯示了，見Page:Gujin Tushu Jicheng, Volume 423 (1700-1725).djvu/4。還請其他維基人幫忙調整。

建好了這兩個模板，只需在校對頁面輸入完整的包含標點和標題符號的文章，即可同時實現在page頁面以傳統版式顯示（按原版式顯示換行）、在主頁面以現代方式顯示（只顯示段閒換行），既便於核對原文，又便於維護。

這兩個模板還需要進一步完善，以適應更複雜的版式。比如，有的古書會將一些名字靠前顯示，如南京條約，又比如Page:KYTU-BB04492447 督戎疏紀1.pdf/16有不同的段前空格。如何在page頁面保持這種顯示方式，在主頁面卻不這麽顯示？ 維基小霸王（留言） 2025年2月20日 (四) 07:20 (UTC)

那個是w:擡頭相關的板式，你可以參考一下我昨天錄的使西紀程及配套的樣式表。

基本上版型都要因地制宜去微調樣式，至少要用到一些標籤語法才會讓文字工作比較簡單。

此外還有挪抬，即：奉(空兩格)天承運這類的。我手上有兩篇用到這樣的樣式，但還沒發出來，沒辦法做例子。 Aerotinge（留言） 2025年2月20日 (四) 07:50 (UTC)

我将模板用在了使西紀程、Page:NLC892-GBZX0301010751-250698 使西紀程 二卷.pdf/3，请问是否满意。除了作者难以兼顾，而且换行空格已经消失，其他均显示如以前。 維基小霸王（留言） 2025年2月20日 (四) 09:18 (UTC)

我想這樣的錄入方式會失去其條列性質。本件作品為日記形式，有著一貫的體例，故我當初以<ul>等html元素標籤錄入，這也是為了兼顧其語意結構。這是對一部作品粗讀過，拆解出大致結構後的成果。

古文作品不僅僅只是一篇純文字。古人縱然沒有發展出西方的排版、標點、縮排、項目等格式工具，他們仍然用僅有的換行與空格來嘗試形成各種體例，常見的日記、博物志、方志、詩集或多或少都可以受益並應用現代的W3C標準。

也是這種隨意性，讓我認為錄入古文會存在因地制宜的必要性。

模組是可以提供一個通用的公版，這點仍是具有相當價值的。 Aerotinge（留言） 2025年2月20日 (四) 09:42 (UTC)

稍等我修改一下 維基小霸王（留言） 2025年2月20日 (四) 09:46 (UTC)

已修改。加入<includeonly>*</includeonly>即可。 維基小霸王（留言） 2025年2月20日 (四) 11:59 (UTC)

您对新模板是否满意？如果满意，可考虑将Index:NLC892-GBZX0301010751-250698_使西紀程_二卷.pdf替换为新式，这样可以大幅让源码看上去简单。 維基小霸王（留言） 2025年2月20日 (四) 12:22 (UTC)

首先感謝您的心血，辛苦了。

對於校對頁的理解，我認為歧異依舊存在。我對校對的理解是，校對頁與被嵌入頁的目標結構應該是對應一致的，或大致相似的。

兩方的差異僅僅是樣式不同，即文本的表現態樣不同。

在校對頁有著h3+p+span+p+ul+li+p結構的一頁，在嵌入頁的結構理當一樣。

而您提供的模板則是在校對頁會推平成p+p+span+p+p+p+p，這是我說的純文字的意思。這些資訊雖然會在嵌入時回來，但兩邊結構實是不同的。

對於當前絕大部分做OCR的貢獻者來說，這個模板方案確實比一行行敲再兩換行符錄入來得更優秀（無須擔心Wikimedia的p閉合抽風、自動除換行空格、夠用的縮排與樣式彈性、擴展過的語法但大致維持熟悉的Wikitext風格...etc）

就像視覺化編輯器一樣，相當夠用了。但我是個用慣了直接敲原代碼的人，請容我當前維持能緊抓狠抓、落實掌控的錄書方式。

至於滿意那可是太滿意了，今天您已經帶給我太多驚喜了，實在是社群之福，還請務必適度休息。 Aerotinge（留言） 2025年2月20日 (四) 12:59 (UTC)

感谢！此方案效果甚佳，值得推广。另请问Page:NLC892-GBZX0301010751-250698_使西紀程_二卷.pdf/16有DL（双行注解）模板，不知嵌入页会怎么处理？ Liouxiao（留言） 2025年2月23日 (日) 14:25 (UTC)

感謝閣下示例。我非常認同閣下對校對頁的見解，支持改進現有校對頁嵌入方式，讓直排顯示的page頁面文本能在嵌入后直排或橫排顯示並有適當的格式，並保持page頁的原始代碼的簡潔和易用。

技術上，除了{{Transclude pages}}所示的刪除換行符“\n”外，另一個可能普遍存在的需求是橫排的分段。以我是新手時錄入的紅樓夢（程甲本）/二十爲例，現代標準無論直排或橫排都會分開段落，有些地方（如此作品頁來源的5，6頁之間）還可以加大段落距離以起到子章節的效果。但原刻本并無分段，此資訊是缺失的。因此無論何種嵌入技術，包括未來可能的MediaWiki 原生官方支持，都很難避免「污染」原始代碼，加入如{{brop}}但功能相反的模板，或使用<noinclude></noinclude>。我在之前的話題#直排之技術問題之中希望提請討論的也正是這個問題。

其他的需求如挪抬，縮進，竪排行高和頁面寬，如Aerotinge閣下所言，大多可以用樣式表微調。對齊可參見{{Center or page}}。因未見社群有共識，故尚未向社群推薦。詩歌的直排轉橫排可能更加困難，因古籍樣式和今天標準相差太大，也許可以先擱置。（未完） Andayunxiao（留言） 2025年2月20日 (四) 08:14 (UTC)

湊合著弄了篇康熙皇帝遺詔改版，及配套的樣式，在擡頭、三抬的樣式部分，請兩位參考、惠賜意見。 Aerotinge（留言） 2025年2月20日 (四) 08:30 (UTC)

已經很好了。請教一個離題的問題：印章裏滿文和中文混排，間距可有規範？如果是正文内排版又有何不同？遺詔原件的印章我看不大清。 Andayunxiao（留言） 2025年2月22日 (六) 16:48 (UTC)

不知規範，我那時是湊合著能看就弄上了。

斯以為印章不必加入正文，若要加入僅需要確保邊線壓印在年月日上做騎縫章作用。這有個名堂，但我忘記叫啥來著了。 Aerotinge（留言） 2025年2月22日 (六) 17:08 (UTC)

另一方面，就直排原文錄入和閲讀而言，社群已經有直排轉橫排，直排轉直排兩種偏好。即使不是古籍，也已經有不同編者對同一主命名空間的作品文字排列方向的爭論。

私以爲，文字排列方向及其附加產生的排版樣式問題，是維基文庫版本的「維基百科字詞轉換」問題。兩者的相似之處甚多：都是源於并存的多種中文標準；都是編者期望以自己熟悉的樣式錄入，或希望展示特定樣式，而不能兼顧其他編者和讀者的需求；都是MediaWiki 原生不支持的。更顯見的是，無論是百科還是文庫，社群都無力長期維護兩個内容同源但編輯分立的頁面。中文維基百科成功避免了可能的分家，而是允許了繁簡并存和讀者自由選擇，還讓其他有類似文字轉換需求的語言社群也因此受益。本地社群也應能努力達成共識，推動技術更新，避免校對頁和作品頁「分家」。 Andayunxiao（留言） 2025年2月20日 (四) 08:44 (UTC)

那麼那些有《 (四庫全書本)》的那些頁面是怎麼搞的？

比如說《史糾 (四庫全書本)》、《史通 (四庫全書本)》

難道我們需要刪除這些頁面嗎？ 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年2月22日 (六) 19:32 (UTC)

成熟可靠的版本什麼時候能開發製作好？現在每天都在微調改動，無法批量使用你的模版。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年2月23日 (日) 18:53 (UTC)

已经写好了两个模板的文档：{{transclude pages}}、{{old text page}}。我还提议了一个新的关键字：=。通常来说一页的第一段是上一段的延续，但是有时是新段。此时，嵌入包含仍然视为上一段的继续。如果在第一段前加上“=”，就代表这一页最开始就是新的一段。如Page:NLC892-GBZX0301010751-250698 使西紀程 二卷.pdf/4。我在两个模板中都加入了对此的处理方式。请检查。--維基小霸王（留言） 2025年2月20日 (四) 12:18 (UTC)

再次感謝閣下的貢獻。個人純技術的淺見，標記並判斷首段是否是新段可考慮使用空白元素，如<span></span>，<p></p>。如覺得過長，也可自訂空白標簽，如<newparagraph>，並可專設一個模板{{模板快捷名}}以方便錄入。這樣可與Wikitext 語言最大相容，避免第三方誤讀頁面的可見文字内容。 Andayunxiao（留言） 2025年2月22日 (六) 16:09 (UTC)

我感觉“=”就类似于mediawiki的“==标题==”语法。使用“=”判断，可同时兼容标题，因为标题也是以“=”开始的。wiki的一大用途是chatgpt这样大语言模型的训练语料，只要在文档中写清楚这个语法，他们应该是可以自动判断的。 維基小霸王（留言） 2025年3月2日 (日) 05:47 (UTC)

直接在页面开头多加两个换行就可以标记page中的首段是新段落了，不需要任何新模板或语法。 Midleading（留言） 2025年3月2日 (日) 09:27 (UTC)

可能并不簡單。原則上MediaWiki手冊#Trimming on save說頁首的空格和新行會在保存頁面時保存，在校對頁實測并非如此，而是：

• 頁眉空白：則正文首的空格和新行不能保存，之後也不能嵌入（用 pages 標簽）。
• 頁眉或正文起首有<noinclude />：之後的空格和新行能保存，嵌入后無論多少都變成一個空格。
• 如果頁眉有閉合模板（即正文在模板閉合后開始），則正文首的空格和新行能保存，嵌入后同樣只有一個空格。
• 如果頁眉有開放模板，將正文作參數，例如{{old text page}}的用法，依同一手冊#Trimming on expansion，命名參數起首空格不保存，位置參數相反。未測試。
• 頁眉空白，正文首有{{nop}}\n（英文文庫用法是前一頁末尾）, 則{{nop}}前的空格和新行不保存，之後的保存，嵌入后可正常分段。

因涉及MediaWiki parser 和 ProofreadPage 擴展兩處，找到問題所在可能不容易，總之很不符合中文文本編輯的習慣，更勿論直排轉橫排。 Andayunxiao（留言） 2025年3月2日 (日) 19:24 (UTC)

理解閣下的想法。考慮{{old text page}}模板將校對頁正文視爲模板參數，那麽確實沒有對參數内語法和MediaWiki 已有語法一致的限制。閣下的方案并無技術上不當之處，而且值得使用。可能多餘的考慮是，技術上，標記語言應該是將單行内成對並在首尾（不計首尾空白字符）的等號群解釋為標題，但= 第一章 = a\n不會渲染為標題<h1>第一章</h1>a而是普通文本。因此，以“=”开始的校對頁可能必須使用專門模板，如{{transclude pages}}才能正確嵌入。如果{{old text page}}也能和預設的嵌入語法協同使用或提供選擇，受益的編者可能更多。 Andayunxiao（留言） 2025年3月6日 (四) 07:45 (UTC)

即將舉行的語言社群會議（2 月 28 日，14:00 UTC世界協調時間）和新聞通訊

大家好，

我們很高興地宣佈，下一次語言社群會議即將舉行，時間為2 月 28 日 14:00 UTC 世界協調時間！如果您希望加入，只需在此維基頁面上註冊即可。

這是一個以參與者為導向的會議，我們在此分享語言相關專案的最新消息、討論語言維基專案中的技術挑戰，並協力尋求解決方案。在上次會議中，我們討論的主題包括開發語言鍵盤、建立莫西語維基百科，以及維基媒體非洲區域會議語言支援軌道的最新消息。

您有話題希望跟大家分享嗎？無論是有關您專案的技術更新、需要協助的挑戰，或是口譯支援的請求，我們都很樂意聽到您的意見！請隨時回覆此訊息或新增議程項目至此文件。

此外，我們希望與您分享語言與國際化通訊第六版（2025 年 1 月）可在此處閱讀：Wikimedia Language and Product Localization/Newsletter/2025/January。本通訊提供 2024 年 10 月至 12 月季度新功能開發的最新動態、各種語言相關技術專案和支援工作的改進、社群會議的詳細資訊，以及為專案做出貢獻的想法。如希望獲取最新信息，您可以在其維基頁面上訂閱新聞通訊：Wikimedia Language and Product Localization/Newsletter。

我們期待您參與語言社群會議並分享您的想法，到時見！

MediaWiki message delivery 2025年2月22日 (六) 08:29 (UTC)

台灣分會2025年2月對話時間

台灣維基媒體協會2025年2月的對話時間，訂於台灣時間2/26 (三) 19:00舉行，
參與連結為 https://meet.google.com/qiv-ctih-sse 。
想跟更多台灣維基人互動嗎？不知道台灣有個維基協會，或知道協會但不知道他們平常都在幹嘛嗎？
本次對話時間將聚焦於2025 A+F藝術與女性編輯松的討論，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！

--MediaWiki message delivery（留言） 2025年2月24日 (一) 14:08 (UTC)

Template:雙行註文請求更新

請求將Template:雙行註文更新到沙盒版本。沙盒版本存在以下修改：

1. 模板不再使用行內樣式，將樣式移出模板本體，交由獨立的樣式表負責，有助於樣式編寫的彈性。
   至於phab:T200704提到的相關問題我無法復現。應是已經由上游解決，故應該可以放心使用樣式表。
2. 模板外層兩括弧賦予wst-dl-bracket類別名稱，方便選擇。
3. 樣式表對註文內文做首行縮排的初始化，避免常用的縮排模板去影響到註文內文。
4. 註文顏色改由用戶當前的維基外觀方案提供，與{{*}}相同，大多數外觀下仍是接近赭色，並保留了原色號作為後備選項。

還請@Midleading君撥冗審閱修改案，查照惠允。 Aerotinge（留言） 2025年2月24日 (一) 16:13 (UTC)

完成。T200704会发生在模板的第一次使用恰好位于一个内部链接中时，并导致TemplateStyles无法使用。不过本模板不会置于内部链接中。 Midleading（留言） 2025年2月25日 (二) 02:33 (UTC)

2025年第9期技術新聞

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

近況更新 - 面向編輯者

• 管理員現在可以透過Special:CommunityConfiguration/Babel自訂Babel功能建立分類的方式。管理員可以重新命名語言分類，選擇是否自動建立分類，以及調整其他設定。 [115]
• wikimedia.org门户網站更新，並持續進行一些改進，使維基媒體的门户網站頁面更現代化、更易於使用。該頁面現在有更好的手機版版面，措辭链接得到更新，並支持更多語言。此外，所有維基媒體项目的门户網站（例如wikibooks.org）現在皆支持深色模式，會根據讀者的系統設定顯示對應模式。 [116][117][118]
• 已新建一個維基： 桑塔利語维基词典 (wikt:sat:) [119]
• 上週有30個社群提交的工單得到解決。 例如，在某些Android手機配置中，出現一錯誤導致無法在Firefox網頁介面中點擊搜尋結果，現已修正此問題。 [120]

會議與活動

• 下一次語言社群會議即將於2月28日 14:00 UTC舉行。本次會議涵蓋：薩米語輸入法和工具的亮點及技術更新；印尼楠榜語社群對Translatewiki.net的貢獻；以及技術問答環節。有意參加者只需在wiki頁面登記報名即可。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年2月25日 (二) 00:41 (UTC)

現有編者申請成爲管理員

提請社群注意，現有編者User:一个大大大大大聪明申請成爲管理員。依本人對本站指引Wikisource:管理员#成為管理員的理解，似未有因提名有效與否的理由而限制頂欄公示的方針。請熟悉流程的編者和管理員查看。另外此提名的討論位置有誤，應移動到「管理员提名」章節下。 Andayunxiao（留言） 2025年2月28日 (五) 20:05 (UTC)

已代為調整格式。—— Eric Liu_（留言） 2025年2月28日 (五) 22:12 (UTC)

(！)意見：關於Wikisource:申请成为管理员的版本2532621修訂，本人存在一些問題，請@Ericliu1912及管理員協助說明釐清。

按Wikisource:管理员#成為管理員"通过标准"之第一節：提名流程期间或结束后，有下列情况之一者，无视下文规则，视为提名无效：其中第2款：提名流程不合法的

該修訂是否使得該件原本存在瑕疵的提名流程發生實質上的變動，並阻卻無效事由(第2款)發生效力？

又，該修訂是否做出了提名流程，即任何用戶若想在維基文庫成為管理員或想提名其他用戶，則可把申請之連結放在下面的「現時的管理員提名」？

管理員的選任事關文庫前程，宜多加謹慎，請容愚在程序上提起覆覈。若程序即有未合，應不予受理。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月1日 (六) 12:41 (UTC)

本人發起話題在先，並已指出瑕疵並提請移動，而後User:Ericliu1912君的編輯只是回應我的提請，在同頁内移動討論位置。Liu君的此筆編輯并未讓流程變得更合法，或更不合法。之前提名時的瑕疵并未從編輯歷史中消失。我覺得全流程中只有申請人提名的一筆編輯，和本人發起此話題並指出瑕疵的編輯，有「合法」與否的可討論處。 Andayunxiao（留言） 2025年3月1日 (六) 15:55 (UTC)

其实如果援引“提名流程期间或结束后，有下列情况之一者，无视下文规则，视为提名无效：...被提名人自始至终不符合管理员提名条件的”，类似这件的情况（满足不了硬性条件）应该是可以快速关闭的吧？之前也不是没有前例，见Wikisource:管理员/Chihonglee。 银色雪莉（留言） 2025年3月1日 (六) 15:14 (UTC)

同意此提名可能不滿足硬性條件。惟幾日後仍無頂欄公示及提名討論位置有誤，不易發覺，恐影響公平，故提請社群注意。 Andayunxiao（留言） 2025年3月1日 (六) 15:37 (UTC)

竊以為，若一件申請行為欠缺生效要件，自始確定無效，自然不存在伴隨該行為而來的公示權益。想來也不會存在權利救濟以及影響公平可能性。

對於新手因不熟悉指示及需求，而做成之出於善意的擾亂性編輯，或許撤銷該筆編輯，並在用戶討論頁給予說明是另一種在快速關閉之外的處置方向。

至於該用戶是否成立"通过标准"之第一節第三款被提名人自始至终不符合管理员提名条件的的情況，即此處所言之（满足不了硬性条件）同為爭點所在。惟我當前著眼處在於第二款的程序合法性，還未就第三款各條件標準對其查核驗證，恕我現不便對此作出意見。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月2日 (日) 01:40 (UTC)

我其實不覺得格式排版是大問題，畢竟文庫本是小社群，講求太多規矩反而不好。當然申請者確實不甚符合資格，而且不熟悉申請格式亦屬此一事實之體現。宣告投票無效之餘，或許不必額外打擊其自信吧。—— Eric Liu_（留言） 2025年3月2日 (日) 06:07 (UTC)

無效的提名投票（如被提名人自始至終不符合管理員提名條件的）不需要全站公示，因為其他使用者無法也不需要參與一個無效的提名投票，公告無效后若無異議就可以存檔了（若是純粹破壞則回退）。 Midleading（留言） 2025年3月2日 (日) 09:37 (UTC)

2025年第10期技術新聞

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

近況更新 - 面向編輯者

• 所有已登入編輯者現在皆可在手機版網站編輯整個頁面。在工具列上的「更多」選單中點擊「编辑整页」即可。先前編輯者須啟用高级模式才能使用這項功能。 [121]
• 請介面管理員協助移除本地MediaWiki:Common.css中帶有「mw-ref」的已棄用Cite CSS碼。此全域搜尋列出了需清理的維基站點以及需移除的代碼，另可參考此範例。參閱CSS遷移项目頁面進一步了解如何提供協助。Cite腳註標記（「[1]」）現在由Parsoid渲染，不再需要上述的已棄用CSS。反向链接的CSS（「mw:referencedBy」）目前應維持不變。這項清理作業應不會給讀者帶來明顯變化。請在3月20日前協助移除這些代碼，若未及時處理，之後將由開發團隊代為移除。
• 現在，若在受連鎖保護的頁面加入文件（例如[[File:MediaWiki.png]]），系統將不再限制對文件描述頁面的編輯，而僅限制文件新版本的上傳。反之，若嵌入文件描述頁面（例如{{:File:MediaWiki.png}}），對描述頁面的編輯將受連鎖保護限制。 [122][123]
• 編輯者若想要將文件還原至較早版本，現在需要與上傳文件新版本相同的權限。系統現在會檢查「覆盖现存文件 (reupload)」或「覆盖自己上传的文件 (reupload-own)」權限，並遵守連鎖保護。 [124][125]
• 現在，管理員在使用Special:大量删除工具列出待刪除頁面時，可以選擇同時列出相關的討論頁和重定向頁面，而無需事後再手動處理。 [126]
• 前幾期提到單一用户登录（SUL）系統為配合瀏覽器對跨網域Cookie的限制，登入和帳號建立頁面將移至中央網域——這項更新將於3、4月向所有用户推出。團隊計劃於本週為Group0站點上的所有新帳號建立流程應用這項更新。參閱SUL3项目頁面了解最新時間表和更多細節。
• 自上週以來，部分介面圖示在頁面尚未加载完全時，錯誤顯示為黑色方塊（深色模式中則為白色）。本週將修正此問題。 [127]
• 已新建一個維基： 錫爾赫特語维基百科 (w:syl:) [128]
• 上週有23件社群提交的工單得到解決。 例如，之前老舊版本的手機版Firefox瀏覽器無法正常加载圖片，現已修正此問題。 [129]

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

• 本週稍晚代码更新細節： MediaWiki

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年3月4日 (二) 02:30 (UTC)

中国保护知识产权网对公众留言的回复著作权问题

各位好，注意到中华人民共和国商务部主办的2025年2月14日中国保护知识产权网对公众留言的回复，“《著作权法》保护的是文学、艺术和科学领域内具有独创性并能以一定形式表现的智力成果，目的是鼓励文学、艺术和科学领域的创作，而保险公司章程属于企业内部的规范性文件，不属于《著作权法》的保护范围。”，请问该回复是否说明企业内部的规范性文件不属于《著作权法》的保护范围。 MarkZhou08（留言） 2025年3月4日 (二) 08:31 (UTC)

单看该回复，确实是认为一切企业内部的规范性文件都不属于《著作权法》的保护范围。不过这个回复是基于《著作权法》第三条而并非第五条的规定，且仍然可能认为企业内部的规范性文件属于管理科学，因此该回复的有效性有疑问（它并非法院判决）。 Midleading（留言） 2025年3月4日 (二) 08:40 (UTC)

同Midleading阁下意见。此外，单凭一句“属于企业内部的规范性文件”便将其排除到著作权法的保护范围之外，理由尚不充分：

1. 企业：企业创作、代表企业意志的内容当然可以构成作品（法人作品）；
2. 内部：著作权法也保护未发表的作品——更何况公司章程需要登记、股东有权复制，对于上市公司而言内部性更弱了；
3. 规范性文件：如果规范性文件不属于作品，那么是否可以认为（至少是PRC的）法律法规不受保护的原因都在“规范性”上？学说上对于法律法规不受保护的依据也不仅仅在于它规范了全体公民。

即使以上三个因素结合，也似乎难以想象出什么新的化学反应使得其本身不构成作品。 Teetrition（留言） 2025年3月4日 (二) 13:51 (UTC)

关于商务部之回复恐非单纯依据《著作权法》第三条之规定，实乃第三条与第五条之合力。第五条所述“具有立法、行政、司法性质的文件”，实与回复中“规范性文件”之含义相近。正如Midleading所言，并无相关判例可证“规范性文件”受（或者不受）著作权法保护，可见商务部之回复权威有效，难以轻易推翻。如是，凡具有立法、行政或司法性质之“规范性文件”，自然不受《著作权法》保护。--Zy26（留言） 2025年3月31日 (一) 07:24 (UTC)

“企业内部的规范性文件”和“立法、行政或司法性质”看不出有什么可以联系起来的关系，有立法、行政或司法职能的部门应该是党政机关而不是企业，同时该回复内容直接引用的是《著作权法》第三条的内容而没有提及第五条。不过无论如何，该回复的结论（《中国人民保险公司章程》属于公有领域）可以采用，目前只需要讨论是否根据该回复，将所有“企业内部的规范性文件”视为根据《著作权法》第五条具有立法、行政或司法性质的文件。 Midleading（留言） 2025年4月1日 (二) 12:47 (UTC)

可以参考这个案例，该案例入选最高法发布的知识产权典型案例。广州市中级人民法院判决，某合同“不是著作权法意义上的文字作品，也不属于著作权法所保护的其他类型的作品范畴，故不受著作权法保护。”原因是“这些条款本身是根据合同法、其他法律、相关部门规章以及工程承包施工的实际情况而制作，但合同条款约定的是当事人之间的权利义务，法律表达方式较为有限，且准确而简洁的表达方式尤为有限。”公司章程应当类似，《公司法》第五条规定“设立公司应当依法制定公司章程。公司章程对公司、股东、董事、监事、高级管理人员具有约束力。” 曾晋哲（留言） 2025年4月1日 (二) 14:50 (UTC)

对这个案例涉及的文件，需要建立一个版权模板说明本作品不属于《著作权法》第三条规定的文字作品，因此不受《著作权法》保护，属于公有领域。 Midleading（留言） 2025年4月1日 (二) 16:01 (UTC)

剩最後兩個生僻字或異體字，實在無法識別。

第一個：

比對很久，認為是「卯」的變體：k5-0633 (卯) - GlyphWiki

第二個：

「勹」里的兩個橫折「巜」完全無法處理。即便使用IDS方式也無法架構出來。或者有想到架構方法的可以提供出來。或者這樣表示是否正確：⿱山⿰單⿹巜勹

另外最後分享一個最近看到的漢字檢索工具：【Mastameta】部件檢索（改裝）25.2.22 - 汉汉 - FreeMdict Forum

內嵌相關字體無版權使用限制，可免費使用。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月6日 (四) 22:28 (UTC)

第一個是「𠑹」 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月6日 (四) 23:19 (UTC)

厲害！

第二個怎麼解決？ #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月6日 (四) 23:38 (UTC)

不知道 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月7日 (五) 00:00 (UTC)

此應是章氏自書隸定，原字見[130]（“字形”節“金文”項第四行第六列）。這種情況，組字、用模板列結構或者插圖片（不管是自書隸定還是原文）都是選擇——如果金文有朝一日進了Unicode則另作別論，目下只能先將就。 银色雪莉（留言） 2025年3月7日 (五) 00:03 (UTC)

我沒查原始手稿的手寫體，印刷體就是這個。你這麼大學問，從何得知這是他自造的隸書？

目前我用的這個結構：⿱山⿰單⿹巜勹

你說的那個字看到了，應該是這個金文。但這個字里的那兩個橫折「巜」，隸變演化成「斤」字，是該字的聲符。才是對的。

日語中「斤」就讀作「キン」，而「旂」讀作「キ」。前者僅僅多了個齒齦鼻音假名「ン」，兩者發音相近。中文裡兩字發音差別很大。

「單」解的是對的，是盾牌的意思，現在的看法是舉旗的人同時持盾，但上面的「山」又錯了，字頭應隸變成「𠂉」。把「勹」里象征旗杆的豎鉤去掉了。

章氏的小學學問還是落伍了。畢竟一百年前的知識。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月7日 (五) 00:53 (UTC)

我也只查到浙圖《章氏叢書》（即《全集·太炎文錄初編》所據底本）爲止，與今本同。 银色雪莉（留言） 2025年3月7日 (五) 02:03 (UTC)

順便提示一下，韓語里「斤」就讀作「근」，而「旂」讀作「기」。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年3月7日 (五) 03:48 (UTC)

微調一下IDS結構順序，旂原字未收錄於Unicode，結構：⿱山⿰單⿹勹巜。⿹組件前者在外(右上)，後者在內(左下)

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月7日 (五) 01:21 (UTC)

Universal Code of Conduct annual review: proposed changes are available for comment

My apologies for writing in English. 请帮助翻译至您的语言.

I am writing to you to let you know that proposed changes to the Universal Code of Conduct (UCoC) Enforcement Guidelines and Universal Code of Conduct Coordinating Committee (U4C) Charter are open for review. You can provide feedback on suggested changes through the end of day on Tuesday, 18 March 2025. This is the second step in the annual review process, the final step will be community voting on the proposed changes. Read more information and find relevant links about the process on the UCoC annual review page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) 2025年3月7日 (五) 18:51 (UTC)

如何使用 common.js 添加快捷键？

我想用我的 common.js（参数设置 → 外观 → 所有皮肤共用的CSS/JavaScript → 自定义JavaScript）实现如下功能：在校对页任选一段文字，按 Ctrl+Alt+U，自动套上专名号。

目前我已经写好了代码，把代码粘贴到浏览器控制台运行，功能完全正常。然而存到 User:David,_but_not_Hilbert/common.js 的代码（请参考提问时的版本）似乎并未生效，console.log(…) 都没有结果。请问怎样调试呢？加载 common.js 是否有什么条件？

（我已经用强制刷新、换浏览器隐私窗口等手段初步排除了浏览器缓存的问题。） David, but not Hilbert（留言） 2025年3月9日 (日) 08:53 (UTC)

使用以下代码：

function user(){
// ......
}
mw.loader.using('user', user, user);

Midleading（留言） 2025年3月9日 (日) 10:06 (UTC)

感谢帮助！我刚刚尝试了您的方案，仍然无效；不过我发现以下报错中“line 11”这个行号会随之变化。

Parse error: Unexpected: ) on line 11 index.php:1:8
    <anonymous> index.php:1
    globalEval startup.js:1141
    runScript startup.js:1292
    enqueue startup.js:1179
    execute startup.js:1399
    doPropagation startup.js:748
    (异步：requestIdleCallback handler)
    setAndPropagate startup.js:821
    impl startup.js:2010
    <anonymous> jQuery

经过试验，我发现是下面这段代码中的逗号,干扰了index.php解析。如果删除这个逗号，就正常了。

range.insertNode(document.createTextNode(
  `{{專|${selected}}}`,
));

按理说，即使加上逗号，也是合法的 JavaScript。这是否是 wiki 软件的 bug？ David, but not Hilbert（留言） 2025年3月9日 (日) 11:47 (UTC)

根据gerrit:962739记载，由[131]判断是否是合法的JavaScript。 Midleading（留言） 2025年3月9日 (日) 16:36 (UTC)

2025年第11期技術新聞

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

近況更新 - 面向編輯者

• 在多個維基上使用密碼管理工具的編輯者可能會注意到將來的變化。我們的維基提供密碼管理工具跨網域重複使用密碼資訊的方式最近已經更新，因此有些密碼管理工具現在可能會為您提供您為不同維基媒體網站儲存的登入憑證。有些密碼管理工具已經這麼做了，現在正在為更多的維基媒體網域進行此操作。這是SUL3專案的一部分，旨在改善我們的單一登入系統的運作方式，並使其與不斷變更的網路瀏覽器相容。 [132][133]
• 維基百科App團隊邀請有興趣的用户協助改善維基百科的離線和受限網路使用情況。經過Afrika Baraza和上次ESEAP通話會議的討論後，我們正在探討搜尋、編輯、離線访问等關鍵挑戰，即將召開的焦點團體將深入探討這些主題。歡迎以任何語言參與，活動將提供口譯服務。如有任何想法，歡迎參與討論或寄信至aramadan@wikimedia.org！
• 3月19日，所有維基媒體網站將進入唯讀狀態數分鐘，預定於14:00 UTC開始。詳情將在技術新聞發布，並在未來幾週內發送至各維基。
• 上週有27件社群提交的工單得到解決。

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

• 本週稍晚代码更新細節： MediaWiki

深入了解

• 季刊Growth電子報新期數發布。 本期內容包括：推出「社群新訊」模組；「社群配置」的最新變更；即將對初次編輯者測試條目內建議。
• Android維基百科App之前使用的舊API將於3月底移除。目前並沒有軟體使用該API，但到移除當日（2025年3月31日），年齡超過6個月的App版本的使用者，將無法再使用「建議編輯」功能，直到他們更新App為止。了解更多。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年3月10日 (一) 23:09 (UTC)

俄罗斯联邦宪法录入

请问2021年11月14日archive.org存档的俄罗斯联邦外交部译《俄罗斯联邦宪法》能否收录，译文是否适用PD-EdictGov。 MarkZhou08（留言） 2025年3月12日 (三) 12:36 (UTC)

根据“网站使用信息”所述，只允许非商业用途，且不得修改。但是维基文库需要允许商业使用及二次创作，并且需要同时遵守美国以及两岸四地的版权法规（PD-EdictGov只适用于美国，所以不能只有PD-EdictGov授权）。所以不要收录。 Midleading（留言） 2025年3月12日 (三) 14:04 (UTC)

适用{{PD-RU-exempt}}。 dringsim 2025年3月13日 (四) 08:39 (UTC)

根据模板文字，需要证明这是“正式译文”。 Teetrition（留言） 2025年3月13日 (四) 09:55 (UTC)

“网站使用信息”页同时也

“然而对网站资料的转载或者任何在大众媒体上的引用，仅当提及俄罗斯外交部官方网站作为信息来源时是被允许的。” MarkZhou08（留言） 2025年3月14日 (五) 01:28 (UTC)

俄罗斯联邦外交部中文网站不能证明是“正式译文”吗 MarkZhou08（留言） 2025年3月14日 (五) 01:29 (UTC)

比如，中国人大网（人大官方网站）的英文版页面的法律英文翻译专栏明确写明了“Home> Resources>Laws（Translation for Reference Only）”（强调后加），那这个专栏的法律翻译当然不能因为是人大官网就被当作是正式译文。俄罗斯外交部的中文网站可能是同一性质，而且重要的一点是，如果是“正式译文”，大概率信源就不止这一个（而且这一个还是archive存档的版本）。 Teetrition（留言） 2025年3月14日 (五) 01:54 (UTC)

了解，感谢讲解。 MarkZhou08（留言） 2025年3月17日 (一) 10:05 (UTC)

中文维基文库不支持援引“引用”之规定，“对网站资料的转载”表意不明，也可以理解为对作品中间涉及的“资料”的转载或对数据的转载。 Teetrition（留言） 2025年3月14日 (五) 01:51 (UTC)

本wiki即將切換至只讀模式

閱讀本消息的其他語言版本 • 请帮助翻译至您的语言

維基媒體基金會即將切换数据中心之间的路由。 这项举措能够确保维基百科以及其他的维基媒体项目可以在经受灾害冲击时依然维持线上运作。

所有流量将在2025年3月19日进行切换。 本次測試將會在14:00 UTC開始。

因MediaWiki系统限制，切换期间将短期无法进行编辑。 我們在此對您的不便致以歉意，並努力將其影響減至最低。

每一個維基將會在此行動發生的30分鐘之前顯示一個通告。 該通告將持續顯示，直到行動結束。

期间您可以阅读但暂时无法编辑所有的维基。

• 2025年3月19日，您大約有一个小时的时间不能进行编辑。
• 届时编辑条目或保存更改时将出现错误信息。 我们希望过程中没有编辑丢失，但无法确保。 如果您看到错误消息，请耐心等待一切恢复正常， 然后保存您的编辑。 保存前请先另行复制一份您的修改，以防万一。

其他影響：

• 后台作业变慢，有些可能被丢弃。 紅鏈可能無法像平時一樣即時更新。 如果您建立了一个新条目，而该条目的名称此前已经在其他页面显示为红色的内部链接，则该链接需要更长的时间才会被更新为蓝色。 一些长时间运行的脚本将停止。
• 我們預期代碼部署將如同往常一般進行。 不過，部分個案代碼可能因操作需要而暫時凍結。
• GitLab會暫停服務，為時約90分鐘。

如有必要，此项目有可能推迟。 您可以在wikitech.wikimedia.org阅读计划。 任何變化都將會在這份计划书中更新。

请把这个通知分享给您的社区。

MediaWiki message delivery 2025年3月14日 (五) 23:15 (UTC)

美国之音、自由亚洲电台即将关闭，是否应该将历史内容导入维基文库？

美国之音、自由亚洲电台即将关闭，是否应该将历史内容导入维基文库？

版权：

美国之音：w:Template:VOA，但“美联社授权美国之音使用其照片和图像。美联社所有资料均受版权保护，并为美联社所属财产，未经美联社书面允许任何人不得复制、发表或传播。”https://www.voachinese.com/p/3874.html

RFA禁止商业使用：https://www.rfa.org/english/about/terms-of-use/

内容：代表美国政府观点，不符合维基百科的中立原则。然而维基文库不需要内容中立，只要求忠实原文即可。

建议：导入美国之音内容，导入后删除提到“美联社”的内容。其他语言一并下载，联系相关语言的维基文库导入。不导入RFA内容。

--103.127.219.59 2025年3月16日 (日) 09:07 (UTC)

維基新聞已經收錄美國之音文章，本地不應重複收錄。 Midleading（留言） 2025年3月16日 (日) 09:15 (UTC)

刚看到新闻，所以这里适用的美国之音作品看来要加紧存档了。不过由于需要处理的文章目前只有34项，所以应该还能赶上？廣九直通車（留言） 2025年3月17日 (一) 09:29 (UTC)

為什麼通知維基文庫卻不通知維基新聞呢，有沒有在維基新聞編輯的維基人可以把最新消息導入維基新聞？ Midleading（留言） 2025年3月17日 (一) 10:30 (UTC)

通知維基新聞管理員@Ericliu1912： Midleading（留言） 2025年3月17日 (一) 10:43 (UTC)

我不確定著作權行不行得通就是了？另外改寫內容也有很大問題。—— Eric Liu_（留言） 2025年3月17日 (一) 15:35 (UTC)

@Midleading：导入美国之音历史内容很明显是属于维基文库/维基共享资源的scope，而非维基新闻啊……这些文章若导入维基新闻则可以被修改，并不起存档的作用，且历史内容已失去新闻价值，没有导入的意义了。 dringsim 2025年3月17日 (一) 15:42 (UTC)

历史内容不属于维基新闻收录范围的可以收录到维基文库。维基新闻上已经被编辑了的新闻，维基文库也可以收录原文。但是维基新闻有很多文章是机器人自动导入的，未经修改就永久全保护了，维基文库没必要重收一次。而且既然维基新闻的机器人可以自动导入，改为自动导入到维基文库应该也很容易。但这需要通知维基新闻的机器人操作者@Kanashimi：进行导入。 Midleading（留言） 2025年3月17日 (一) 16:55 (UTC)

不曉得需要機器人如何配合呢? Kanashimi（留言） 2025年3月17日 (一) 21:38 (UTC)

维基新闻只有1,178篇美国之音文章。美国之音仅3月1日一天就有31篇文章。按此计算，只导入了一个多月的文章。获取链接的网址：

https://www.voachinese.com/z/1739/2001/7/16

到

https://www.voachinese.com/z/1739/2025/3/15

如果没有列全，需要从?p=2 获取

建议的维基文库标题：美国之音/2001年/7月/16日/日本月底参议院选举考验小泉内阁 - 2001-07-16 103.127.219.59 2025年3月18日 (二) 04:29 (UTC)

维基新闻仅称“这篇新闻报道的全部或部分内容，来自美国政府的国营国际广播机构美国之音的新闻”，即便是原样转载，也并非是以“忠实于原文”为目的。维基新闻转载新闻稿和维基文库收录历史文献，其含义是完全不同的，并不能够称为“重复”。 dringsim 2025年3月18日 (二) 09:49 (UTC)

维基新闻不接受逾七日前的消息。--Jusjih（留言） 2025年4月2日 (三) 04:14 (UTC)

2025年第12期技術新聞

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

本週要聞

• 每年春秋分前後，維基媒體基金會的網站可靠性工程團隊例行執行資料中心伺服器切換，將所有流量從主要伺服器導向備用伺服器。這個半年一次的程序確保了我們在面臨危機時，可以隨時使用備援資料中心。多虧了Listen to Wikipedia工具，您可以實際聽到切換的過程：開始之前，您會聽到源源不絕的編輯聲音；然後，當系統進入短暫的唯讀階段時，聲音會停止數分鐘，切換完成後才會恢復。更多關於此次切換的背景和細節，請參閱Diff文章。如果您想聆聽即將到來的伺服器切換，請於3月19日 14:00 UTC收聽各維基的聲音。

近況更新 - 面向編輯者

• 經改良的內容翻譯工具面板現已供10個維基百科使用，並即將在所有維基百科推出。有了統一的面板，桌面裝置使用者現在可以翻譯條目章節；探索並存取以主題為基礎的條目建議篩選器（起初僅限行動裝置）；從維基專題和編輯活動中探索並存取社群定義的清單篩選器，也稱為「收藏集」（Collections）。
• 維基共享資源引入新的檔案分類選擇系統：如果某分類含有一個或多個子分類，點擊箭頭即可在表單中展開子分類清單，以便選取正確分類。父分類名稱會持續顯示在頂部，可隨時返回父分類。這應該可以減少志願者修復/建立新分類的工作量。這項變更同樣適用於行動裝置。這些變更是上传向导改進計畫的一部分。
• 社群技術團隊正在徵求維基社群參與試用多重封鎖功能以及更新後的Special:封禁頁面，預定3月底進行。多重封鎖可讓管理員同時對同一使用者施加多種不同類型的封鎖。如果您是管理員或監管員，並希望我們與您的社群討論參與試行的事宜，請在專案討論頁留言。
• 3月25日開始，編輯團隊將在12個維基百科站點測試編輯檢查的新功能：多重檢查。在這些維基中，一半的新手在編輯時會看到所有參考檢查，而另一半則如同往常只看到一個。此測試旨在觀察編輯者在單一編輯階段中看到多個（且相關的）參考檢查時，是否會感到困惑或氣餒。在這些維基中，有顯示參考檢查的編輯所使用的標籤將被簡化，因為一筆編輯中可能會顯示多個標籤。Phabricator工單記錄了變更的標籤。 [134]
• 全域提醒機器人是一項通知使用者其臨時權限即將到期的服務，現已支援在訊息標題中使用權限群組的本地化名稱。請翻譯人員參閱說明文件和現有譯文清單，檢查其語言是否需要更新或新增譯文。
• Special:全域设置中的性別設定——用來設定軟體在介面訊息中應該如何稱呼您——現在可以如預期般覆寫本地預設值。 [135]
• 上週有26件社群提交的工單得到解決。 例如，Android版維基百科App修正了使用者以多種語言瀏覽和搜尋時發生的錯誤。 [136]

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

• 本週稍晚，Codex樣式的載入方式將改變。儘管風險較低，這有可能導致某些頁面上的介面訊息框樣式失效。模板等使用者生成內容不受影響；小工具可能會受影響。如果您發現任何問題，請回報至工單。關於如何修復受影響小工具的細節、截圖、說明文件，請參閱上述工單。
• 本週稍晚代码更新細節： MediaWiki

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年3月17日 (一) 23:48 (UTC)

glyphwiki無法導入新字。

前段時間導入glyphwiki的幾個新字至今沒有在相關頁面顯示。應該都未被錄入後台數據庫。所以下面「用」的兩個異體字怎麼處理，特別是第二個。

#Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月20日 (四) 07:36 (UTC)

Glyphwiki製作新字 u7528-var-006 和 u7528-var-007，並將SVG導入commons.wikipedia.org，即可引用： [[File:用的異體字.svg|18px|用的異體字]] 和 [[File:用的罕見異體字.svg|18px|用的罕見異體字]]

， Liouxiao（留言） 2025年4月4日 (五) 15:38 (UTC)

本人已在glyphwiki上製作過一些新字，但可能因為是剛註冊賬號不久，製作的新字好像都沒被該網站錄入。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月5日 (六) 11:52 (UTC)

《十國春秋》篆書十二字。

如何解？如何錄入？

#Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月22日 (六) 06:12 (UTC)

用Glyphwiki？ 比如第一個字： [[File:𢏭的異體字.svg|20px|𢏭]] Liouxiao（留言） 2025年4月4日 (五) 13:01 (UTC)

一篇文章被兩個文件分割為兩部分，如何將兩部分連接？

十國春秋/卷115的文本分屬於1和2兩個文件。然而<pages />中的index屬性只能傳入一個參數，即只能連接同一文件中的不同頁面。

目前想要在同一頁面展示全文，只能通過引入兩個<pages />的方式將全文嵌入頁面中，但在兩個標籤之間處的文本會被打斷並自動換行。如十國春秋/卷115中前一文件的末頁第60頁和後一文件的起始頁第2頁無法無縫結合。

如何解決這個問題？ #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月22日 (六) 08:02 (UTC)

Proofread擴展的設計本意是一個作品僅一個Index:嵌入，所以這種情況需要一點hack，

可以參考沙盒的版本2541062來接合，你可以先試著在十国春秋23的樣式中導入這段樣式。

只是這種方法可能產生其他排版問題，如果往後有問題須自行除錯、調整。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年3月22日 (六) 17:15 (UTC)

多謝回復。

看了一下修復原理，是通過外聯樣式表將標籤結合處文檔流中的塊級元素強制轉換為行內元素。下一行文字自動接續到上一行行內元素的後面。解決方案本身倒是沒多大問題，只是跳出了wikitext原生的渲染框架。

最為理想的還是利用wikitext解決問題。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年3月22日 (六) 18:08 (UTC)

2025年第13期技術新聞

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

本週要聞

• 維基媒體基金會正在徵求您對下年度目標與關鍵結果（OKR）草案的反饋意見，這些OKR將影響基金會的下一個財政年度（從7月開始）的產品與技術優先事項。「目標」是廣泛的高層次領域，而「關鍵成果」則是追蹤目標成功與否的可衡量方式。請在討論頁分享您的意見，語言不限，最好在4月底之前提出。

近況更新 - 面向編輯者

• CampaignEvents擴充功能將於2025年4月部署至多個維基（詳情請見部署計畫），團隊已開始與確定部署的維基社群接觸。該擴充功能提供了在維基上籌辦、管理和推廣協作活動（如Event活動、編輯松、維基專題）的工具。該擴充功能有三個工具：活動報名、協作清單和邀請清單。該擴充功能目前已部署至13個維基百科（包括中文、英語、法語、西班牙語等），以及維基數據。若有任何問題或請求，請至擴充功能討論頁或Phabricator（加上#campaigns-product-team標籤）。
• 3月31日當週開始，維基站點將能夠自行設定哪些使用者群組可以在活動報名功能中檢視非公開報名者，這是CampaignEvents擴充功能的一部分。預設情況下，活動籌辦人員和本地管理員將能夠檢視非公開報名者。這改變了目前的行為，即只有活動籌辦人員才能檢視非公開報名者。維基社群在Phabricator請求變更配置（加上#campaigns-product-team標籤）來變更預設配置。過往活動的參與者可隨時取消報名。
• 有自訂MediaWiki:Sidebar的維基的管理員應檢查其之中是否列有特殊页面項目。若沒有，管理員應使用* specialpages-url|specialpages來加入該項目。帶有預設側邊欄的維基將在4月看到該链接從工具欄移至側邊欄。 [137]
• Minerva外觀（手機版網站）將重要通知和常规通知整合進一個鈴鐺圖示 中。Minerva長期存在一個錯誤，僅在有未讀「重要通知」時才會顯示新通知標示。現已修正此問題。未來在Minerva中，無論您有未讀的重要通知或常规通知，鈴鐺圖示上方皆會顯示未讀通知數量。 [138]
• 上週有23件社群提交的工單得到解決。

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

• 視覺化編輯器引入了新的用戶端勾點，供開發者在整合視覺化編輯器目標生命週期時使用。該勾點應該會取代現有的生命週期相關勾點，並且在不同平台之間更加一致。此外，新的勾點也將適用於全文編輯以外的視覺化編輯，讓小工具也能與討論工具（DiscussionTools）中的編輯器互動。編輯團隊打算棄用並最終移除舊的生命週期勾點，因此團隊很關注任何新勾點未涵蓋的用例，如有相關資訊，歡迎在工單中與團隊分享。
• 使用mw.Api這一JavaScript函式庫的開發者，現在可以使用userAgent參數來識別使用該函式庫的工具：var api = new mw.Api( { userAgent: 'GadgetNameHere/1.0.1' } );。如果您有在維護小工具或使用者腳本，請務必設置使用者代理（user agent），這將有助於函式庫和伺服器的維護，以及區分合法與非法的流量。 [139][140]
• 本週稍晚代码更新細節： MediaWiki

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年3月24日 (一) 22:42 (UTC)

台灣分會2025年3月對話時間

台灣維基媒體協會2025年3月的對話時間，訂於台灣時間3/29 (六) 14:00舉行，
參與連結為 https://meet.google.com/qiv-ctih-sse 。
想跟更多台灣維基人互動嗎？不知道台灣有個維基協會，或知道協會但不知道他們平常都在幹嘛嗎？
本次對話時間將聚焦於ESEAP Hub進度的更新與分享，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！

--MediaWiki message delivery（留言） 2025年3月24日 (一) 22:55 (UTC)

《瀛環志畧》校對頁化提議

据百科條目，此書初版於道光戊申（1848），文庫已有瀛寰志略，未完成，現有配圖不是原書影像而是今人重制。

共享資源上已有多個不錯的影本。如c:Category:瀛環志略分類下所列：

• File:NLC403-312001064879-162125 瀛環志略 清道光28-29年(1848—1849) 卷一.pdf
• File:NCL-04148 瀛環志略.pdf
• File:CADAL02087082_瀛環志略（一）.djvu

似乎都是道光初版這同一版本。包括最近貢獻者在内的各位編者可有意協作，挑選來源，將此書校對頁化，並錄入到依初版命名的瀛環志畧，放棄修補瀛寰志略作品頁？

上述初刻本字跡清楚，文庫内置的 google OCR 識別尚可，如用外部工具可能會非常準確。初版行款除幾處誇張的抬頭外較工整，社群現使用的竪排技術和雙行批語模板應已能勝任。且初版已有句讀（小字除外），可免去自行加標點一環。善製圖的編者更可重製無水印的左右頁拼合的原貌地圖。

共享資源另有稿本：c:Category:瀛寰志略，未敢推斷版本。還有c:Category:瀛環志畧。Ctext.org 有此作品但僅為OCR輸出。 Andayunxiao（留言） 2025年3月27日 (四) 16:59 (UTC)

2025年第14期技術新聞

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

近況更新 - 面向編輯者

• 編輯團隊正在開發新的編輯檢查：華辭檢查（Peacock check）。這項檢查的目的是在使用者編輯維基頁面時找出非中立詞句，以便在他們發布編輯前通知並建議其修改。華辭檢查仍在早期階段，團隊正在尋求社群的意見：在此Phabricator工單中，團隊正在收集他們目前所研究的語言版本的維基內方針、用來標記非中立條目的模板，以及編輯摘要的用語（術語與關鍵字）。要參與其中，您可以編輯工單中的表格、在工單留言，或是直接傳訊息給Trizek (WMF)。
• 所有維基站點的單一使用者登入系統皆已更新，登入與帳號建立頁面已移至中央網域。這可讓使用者登入流程兼容瀏覽器對跨網域Cookie的限制，這些限制會讓某些瀏覽器的使用者無法維持登入狀態。
• 上週有35件社群提交的工單得到解決。

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

• 3月31日開始，MediaWiki介面團隊將開始限量發布已生成的OpenAPI規格，以及以SwaggerUI為基礎的MediaWiki REST API沙盒體驗。團隊邀請來自特定非英語維基百科社群（中文、阿拉伯語、德語、法語、希伯來語、國際語、荷蘭語）的開發者，以他們的偏好語言審閱說明文件並試用沙盒。除此之外，沙盒與OpenAPI規格也將在測試維基的REST沙盒特殊頁面上提供給偏好使用英語的開發者。在預覽期間，MediaWiki介面團隊也邀請開發者分享您的體驗。預覽期約為兩週，之後沙盒和OpenAPI規格將提供給所有維基站點使用。
• 本週稍晚代码更新細節： MediaWiki

深入了解

• 有時，一行小小的程式碼變更，卻有著重大的意義：這項變更意味著多年來，我們第一次能夠從單一座核心資料中心執行所有提供給maps.wikimedia.org（專門為維基媒體站點提供多語言地圖的主機）的堆疊，我們每次執行資料中心切換時都會進行這項測試。這項進展非常重要，因為它確保即使其中一座資料中心發生意外，我們仍能持續提供網站服務。這項變更歸功於兩位開發人員的大量工作，他們將地圖堆疊的最後一個組件移植到Kubernetes，我們在那裡能更有效率地分配資源，從而使單一資料中心能承受更多流量。這項工作涉及許多複雜步驟，因為這個軟體及其所使用的軟體函式庫需要許多逾期已久的升級。這類工作讓維基媒體的基礎架構更具永續性。

會議與活動

• 2025年5月14日至16日，2025年春季MediaWiki使用者與開發者研討會將於美國桑達斯基舉行，並同時線上舉行。研討會將圍繞不同產業公司使用MediaWiki軟體的情況進行討論，並鼓勵及吸引新使用者。活動報名及演講報名現已開始，可前往研討會網站報名。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年4月1日 (二) 00:05 (UTC)

Final proposed modifications to the Universal Code of Conduct Enforcement Guidelines and U4C Charter now posted

The proposed modifications to the Universal Code of Conduct Enforcement Guidelines and the U4C Charter are now on Meta-wiki for community notice in advance of the voting period. This final draft was developed from the previous two rounds of community review. Community members will be able to vote on these modifications starting on 17 April 2025. The vote will close on 1 May 2025, and results will be announced no later than 12 May 2025. The U4C election period, starting with a call for candidates, will open immediately following the announcement of the review results. More information will be posted on the wiki page for the election soon.

Please be advised that this process will require more messages to be sent here over the next two months.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this message with members of your community so they can participate as well.

-- In cooperation with the U4C, Keegan (WMF) (talk) 2025年4月4日 (五) 02:05 (UTC)

再向固執用戶溝通

上接Wikisource:写字间/存档/2024#修改認定長期不活動管理員之時限標準（縮短目前標準改為3個月）包括@Midleading：所述“解決Zhxy 519濫用封禁權限的正確程序是申請管理員解任投票以及完善有關方針”，以及Wikisource:写字间/存档/2022#可不可能向二位固執用戶溝通，已向四次擅自回退解任案[141] [142] [143] [144]的User talk:Zhxy 519以及因而包庇的w:User talk:Gzdavidwong試行社群能否同此二位溝通。--Jusjih（留言） 2025年4月5日 (六) 04:47 (UTC)

也請看维基文库:不合理的封禁/2025年。Zhxy 5192024年2月5日曾破壞投票。再溝通不成就要解任。--Jusjih（留言） 2025年4月5日 (六) 14:43 (UTC)

中華民國台灣現在正在進行一場針對不適任立法委員的罷免活動，私以為本wiki站點存在更為嚴重的瀆職濫權之管理員，應該比照台灣目前的選罷活動，永久撤銷閣下所提及的這類不適任管理者的相關管理權限及職位。

當然本人深知做這類事會得罪人，但不能因為怕得罪人就不敢做正確的事。

另外應該建立一套較為完善便於操作的管理員罷免機制，類似台灣選罷法，以便於日後出現類似情形，可以比照辦理。

以上。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月5日 (六) 15:35 (UTC)

諸位，就在我在old.ws進行正常提刪申請時，原本無關甚至可以說在該站瀆職的Jusjih跳出來以荒謬的理由中止我的請求，並在當地批判我一番。幸虧當站的其他管理員足夠理性，知道我在提出正常請求，不然Jusjih能幹出甚麼來，可想而知。Jusjih這裡延續著他那文法不通的中文，我根本不知道他要「溝通」甚麼。而在其它站點的表現，足以證實其人純屬惡意擾亂。我沒時間陪他說話，如果各位不出面導致事態繼續發展，我將直接對這種惡意擾亂處以累進封禁。--Zhxy 519（留言） 2025年4月5日 (六) 22:35 (UTC)

要不要解決Wikisource:不合理的封禁/2025年？--Jusjih（留言） 2025年4月6日 (日) 00:21 (UTC)

你敢不敢公佈你討論頁上被刪除的討論記錄讓大家看看我跟你的溝通？不說我了，瓜皮仔即Gzdavidwong早就洗刷了你的誣告，居然還在提。頁面已送提刪。 Zhxy 519（留言） 2025年4月6日 (日) 01:09 (UTC)

@hat600：仍有重要聲明。Zhxy 519多次濫用“你”字太不禮貌。--Jusjih（留言） 2025年4月7日 (一) 02:07 (UTC)

本人再插一句，目前基金會的仲裁機制已經完全失效，不拿出乾綱獨斷的氣魄和責任，說再多也沒用。

wiki中文系列站點所發生的所有事情，發展到今天這一步，不論什麼問題最後都歸結到必須站隊的地步，從本質上說都是意識形態的鬥爭。前幾年wikipedia維基中文對自身大量編輯者的清洗行動，是最後一次撥亂反正。而由於本站參與者過少，被滲透嚴重，相應的正本清源的清洗活動未得到基金會官方重視。

哪些人是帶著任務混進來的，基本都能判斷清楚，現在的問題是如何剝離和抽身。這也是本人非常讚同閣下曾提出的開闢傳統漢文分站，空心化本站的根本原因。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月7日 (一) 13:16 (UTC)

我把相关争议丢给了通用行為準則協調委員會，可以到m:Universal Code of Conduct/Coordinating Committee/Cases/Zhxy 519, Jusjih and Chinese Wikisource#Other feedback参与讨论。 GZWDer（留言） 2025年4月7日 (一) 15:03 (UTC)

User:Zhxy 519使得中文維基文庫管理員離任程序事實癱瘓，同意由通用行為準則協調委員會調查中文維基文庫的系統性問題 Midleading（留言） 2025年4月8日 (二) 03:03 (UTC)

@Midleading：在这里讨论是没用的，应该把相关证据提交到元维基讨论页面。 GZWDer（留言） 2025年4月8日 (二) 13:11 (UTC)

沒什麼提交的必要，之前又不是沒有提交過，我去年提交的申訴至今連一個回應都沒有，基金會這些玩意都在和稀泥。去年的申訴還不算近期。睜眼說瞎話。

什麼forgive and forget，說穿了就是嫌中文社區事多，壓根就是不想管。扯個理由避嫌。

早對官方基金會沒任何指望，這事就看User:Jusjih 最後的抉擇了。就是直接把User:Zhxy 519 賬號註銷，基金會也不會怎麼樣。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月9日 (三) 16:57 (UTC)

@GZWDer：立案有功，包括引述囍鵲在元維基的申訴。此事請各位去元維基向通用行為準則協調委員會留言，稍安勿躁。暫不在囍鵲在元維基的申訴回答，是避免一案多審。請先等通用行為準則協調委員會看法。--Jusjih（留言） 2025年4月10日 (四) 02:34 (UTC)

通用行為準則協調委員會目前似乎認為根据一案不再審，不需要采取任何行動，因為所有事件發生在通用行為準則協調委員會成立前且既往沒有採取任何行動。 Midleading（留言） 2025年4月10日 (四) 03:47 (UTC)

通用行為準則協調委員會的0xDeadbeef在4月11日表示“上次向Zhxy 519提出的解任投票却由Zhxy 519擅自回退，虽然我没有非常仔细去阅读相关讨论，但这样的行为不合理，可以说是在无视其他社群成员。我在想是否能够提议允许Jusjih或其他用户在中文维基文库上提出对Zhxy 519的解任投票，而禁止Zhxy 519直接将此投票删除，让社群合理走一次本地的流程。”--Jusjih（留言） 2025年4月11日 (五) 18:18 (UTC)

其實我也希望這件事能一了百了，不再成為困擾社群的問題。以前監管員說過請本地社群處理Jusjih跟Zhxy 519的解任案，但顯然至今難有定論。或許交由外部機構仲裁是一個可行的辦法。—— Eric Liu_（留言） 2025年4月13日 (日) 14:53 (UTC)

继续举行Zhxy 519解任案的动议已取得6票（共8席）。这件事大概率要回到本地继续处理。 dringsim 2025年4月19日 (六) 17:23 (UTC)

2025年第15期技術新聞

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

近況更新 - 面向編輯者

• 從今以後，系統會要求介面管理員和中央公告管理員必須先啟用雙重認證，才能行使其權限。未來這項措施可能會擴大到更多具有高級權限的群組。 [145]
• 上週有20件社群提交的工單得到解決。

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

• 設計系統團隊正準備於4月29日發布Codex的下一個主要版本（v2.0.0）。使用Codex提供的CSS的編輯者和開發者應查看2.0概要文檔，其中包括與一些重大變更相關的指南，例如font-size、line-height和size-icon。
• 2025年開發者滿意度調查的結果現已公布。感謝所有參與者。這些結果有助於基金會決定下一步的工作方向，並檢討最近的工作。
• 本週稍晚代码更新細節： MediaWiki

會議與活動

• 5月2日至4日，2025年維基媒體黑客松將在土耳其伊斯坦堡舉行。現場活動報名將於4月13日截止。報名前請留意，入境土耳其可能需要簽證或電子簽證。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年4月7日 (一) 18:52 (UTC)

【紧急呼吁】抢救濒危的美国之音中文及粤语内容，导入维基文库

各位维基文库的编辑同仁：

我们正面临一个文化与信息保存的紧急关口。由于美国政府已决定停止对美国之音 (VOA) 的拨款，其网站，特别是对华语世界有着特殊意义的中文网和粤语网，随时面临着永久消失的风险。这不仅意味着一个信息来源的终结，更可能是一段独特历史记录的湮灭。

美国之音作为美国联邦政府的产物，其内容属于公有领域，没有版权限制。这为我们提供了一个宝贵的机会——在它彻底消失之前，将其完整地迁移、保存在人类知识的殿堂：维基文库。这不仅是对信息的保存，更是对历史、对不同声音、对一个时代片段的尊重与守护。

为了抢救这份可能稍纵即逝的数字遗产，我已经下载了美国之音中文网和粤语网的近期网页内容。它们被保存在以下三个压缩包中，请务必在30天内下载，以免链接失效：

https://ufile.io/f/uut2x

数据格式说明：

• 每个压缩包内，每天的新闻被整理成一个单独的文件。
• 在每个文件中，每行代表一个网页。
• 每行的内容分为两部分：第一部分是原始网页的网址 (URL)，第二部分是该网页的HTML内容。

导入请求与协作：

这项工作需要将大量的HTML内容进行处理、格式化，并按照维基文库的标准导入。这是一项浩大的工程，单靠一人之力难以完成。因此，我在此恳请各位，特别是经验丰富的 @沈澄心, Kanashimi, 囍鵲, GZWDer： 等同仁，能够伸出援手，参与到这项抢救工作中来。

我们可以仿照英文维基文库处理《纽约时报》旧档的方式来组织标题，例如： en:The New York Times/1851/9/24/Earthquake in Naples。

我已经创建了一个示范页面，供大家参考导入格式：

美国之音中文网/2025/03/05/美国为什么会认为中国传统芯片对国家安全构成威胁？

对于页面中包含的图片、视频、音频等多媒体文件，请使用 {{VOA file link}} 模板进行链接。

时间紧迫，每一份导入的文档，都是对历史碎片的一次成功抢救。让我们共同努力，为后人保留不同的声音。

期待您的回应与参与！--103.127.219.59 2025年4月6日 (日) 09:30 (UTC)

您好，爲了您提供的數據不丟失，請先嘗試上傳您的數據包到永久存檔平臺如 archive.org 等以保證數據始終留存且對大眾可及。抱歉此數據包過大我無力直接操作。另外建議有能力者嘗試使用 Wayback Machine 或其關聯工具嘗試批量整體保存相關網站。

Xsgzjmxs（留言） 2025年4月10日 (四) 03:15 (UTC)

管理員的離任指引

這裡不牽涉上面Jusjih與Zhxy 519爭吵的問題，祇是想吐槽一下指引後面部分劃底線的部分也太多了，而且劃線基準頗為不明。眾所周知「重點劃太多等於沒劃」（而且漢字沒劃線也看得懂吧），能不能去掉一些，僅保留最重要的部分劃線？—— Eric Liu_（留言） 2025年4月13日 (日) 12:50 (UTC)

我個人覺得比較重要的部分，主要是解任投票的性質及要件，例如「管理員解任投票是一個最終手段」這句可以劃線；「至少5張有效票支持解任，也多於反對解任票」也可以；還有「蓄意濫提解任案者，可能遭反坐」這段。其他的應該都不需要特地強調。不知社群意見如何？—— Eric Liu_（留言） 2025年4月13日 (日) 12:54 (UTC)

谨赞 Eric 君之见。观此指引，下划线之用繁复，不仅淡化了强调之效（诚如所言，“重點劃太多等於沒劃”），且恐与网页中下划线惯用于标示超链接相混淆。建议削除全部下划线，仅于最为紧要之规则或条件，施以加粗以彰显其重，如此方更简明，且符网页通行之规范。其余关键之时间限制（譬如六月、七日、四十八或七十二小时、三名用户、超出五票以上等），亦可一并以加粗标示，以求清晰统一。--Zy26（留言） 2025年4月14日 (一) 01:07 (UTC)

我同意，已调整加粗样式 Midleading（留言） 2025年4月16日 (三) 03:59 (UTC)

我觉得重要的问题是投票过程中出现站外拉票、威胁等情况导致投票不公怎么办。维基百科的安全投票都差点被站外拉票搅黄，维基文库完全有必要对此设立维基百科一样的投票延期措施：“在投票过程中发现存在站外拉票、威胁、使用傀儡等操纵投票情形的，涉嫌操纵投票的用户及傀儡账户作出的投票无效。管理员、当事人和联署人可以延长投票期限至发现操纵投票情形起14日。投票结束后发现存在操纵投票情形的，当事人可以申诉要求宣告被操纵的投票无效并重新举行投票。” Midleading（留言） 2025年4月16日 (三) 03:43 (UTC)

本站屬「小維基」，迄今為止似未有類似情事。但若社群確認有必要，可先行增訂相關條款以為防範。當然，所謂「拉票」亦需要明確定義，或援用百科方面情況為宜。—— Eric Liu_（留言） 2025年4月16日 (三) 05:49 (UTC)

@Ericliu1912、Midleading要不趁现在抓紧时间重新研究一下这个指引的各个方面问题吧？比如说可否讨论对“不活跃的管理员”的定义进行修改？ Liuxinyu970226（留言） 2025年4月18日 (五) 07:10 (UTC)

我覺得對於中文維基文庫而言，六個月未有編輯或操作太過嚴格，且毫無必要，應該重新放寬為一年，甚至符合元維基標準之二年為宜。—— Eric Liu_（留言） 2025年4月18日 (五) 08:37 (UTC)

現在討論什麼是“不活躍的管理員”可能不是最重要的事，我也沒有意見，現有的要求下，管理員每六個月等到收到提醒的時候編輯一次就可以满足活躍度要求了，最近沒有不活躍的管理員。

現在有必要討論的是如何使管理員解任投票更為正當。如果U4C同意在本地舉行对Zhxy 519管理員的解任投票，這也不是代表Zhxy 519管理員聲稱的Jusjih濫用溝通無效提出無效解任提案的問題就完全不可能存在。這需要在管理員解任投票前的討論及投票中由社群判別。如果提出管理員解任提案起7日內聯署人數不足方針規定的2人，或是提案人或聯署人認為溝通有效，撤回聯署導致聯署人數不足方針規定的2人的，不進入投票階段而宣告無效。如果進入投票階段，我建議和維基百科一樣要求投票時必須說明投票理由，未給出理由的投票計為無效。 Midleading（留言） 2025年4月18日 (五) 14:36 (UTC)

管理員是否瀆職是否有在做事，應成為衡量管理員是否適任的重要標準之一。例如長期未活動（三個月以上）之管理員，如無法給予合適的理由及說明，默認為對待本職工作消極懶惰，依此社區成員可對其提出解任投票。

針對管理員自身的知識水平及編輯能力也納入評價範圍，如出現編輯錄入錯誤等，代表其不具備工作能力，也應考慮解任。

另外由於維基文庫的基礎用戶遠遠少於中文維基百科，管理員數量應該和社群人數匹配才合理，按照目前的人數，管理員人數設置最多不應超過3人。能否減編至3人以下，就看這次改革的成效了。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月18日 (五) 15:22 (UTC)

「管理員數量應該和社群人數匹配才合理，所以要減編」是很奇怪的論述，本來任何人都應該可以是管理員，不過是受系統安全的考慮而有所限制，所以在社群維持信任的基礎上，管理員自然是越多越好。過去聽過各種舒緩管理員壓力的方案，但從沒聽過要主動給管理員增加平均工作量的。—— Eric Liu_（留言） 2025年4月19日 (六) 01:15 (UTC)

若给管理员增加平均工作量，管理员完全可以主动辞职，这样管理员就更少了：） dringsim 2025年4月19日 (六) 05:38 (UTC)

社群人少可不等于社群（从project scope来考虑）事情会少。 dringsim 2025年4月19日 (六) 05:51 (UTC)

敢問這個社區目前有多麼繁重的任務需要接近10個管理員處理？

社區人數跟管理難度當然強相關成正比。脫離現實情況按照詭辯話術，管理難度也可以只和管理員個人責任感相關，沒責任感的管理員可以只掛名卻幾個月無所事事，耍無賴找藉口推卸所有任務和責任，反正也沒辦法把他拉下去。

目前就是這個現狀，所以我才會出來要求建立退出機制，向良善方面改變。如果無法建立相應規則，那就必須考慮其他不那麼文明的方式解決問題。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月19日 (六) 13:22 (UTC)

Wikimedia这个自愿参与的社区隔几个月编辑几次不是全凭心情么，难道还有人给管理员开工资不成。

假使用“收紧不活跃标准”处理滥权问题，当事管理员大可以加倍地滥权，滥权问题解决了吗？ dringsim 2025年4月19日 (六) 17:19 (UTC)

你我意見多有不同，但“這也不是代表Zhxy 519管理員聲稱的Jusjih濫用溝通無效提出無效解任提案的問題就完全不可能存在。這需要在管理員解任投票前的討論及投票中由社群判別”我深表贊成。 瓜皮仔＠Canton 2025年4月19日 (六) 00:16 (UTC)

@Midleading：我懷疑這是否有實際意義，因為就解任投票而言，「贊成（或反對）解任理據」本身就已足夠。—— Eric Liu_（留言） 2025年4月19日 (六) 01:15 (UTC)

中文維基文庫很可能存在一些使用者投票的理由並非是方針規定的合理理由，例如某使用者支持對Gzdavidwong解任並說此管理員過去三個月內編輯不足1次，這就很奇怪，因為方針要求的長期未活動是指連續六個月編輯不足1次，所以如果某使用者給出的理由是這樣的理由，當事人可以追問，該使用者也可以在追問後改票，只是當事人不能單方宣穪此投票無效而已。Jusjih是否濫用溝通無效也存在類似的情形，需要確保双方提出的理由都已經得到投票參與者的充分審視。 Midleading（留言） 2025年4月19日 (六) 01:31 (UTC)

目前委員會方面似乎傾向先辦理Zhxy 519的解任投票（至少是要保護這類投票），但這又牽涉到社群和諧問題，我個人比較希望雙方同時舉行，一次把帳算清⋯⋯ —— Eric Liu_（留言） 2025年4月19日 (六) 09:30 (UTC)

支持同时开启两人的罢免投票。 ——— 红渡厨（留言・贡献） 2025年4月19日 (六) 13:59 (UTC)

Zhxy 519四次强行回退掉的解任投票早就包括Gzdavidwong。--Jusjih（留言） 2025年4月19日 (六) 16:29 (UTC)

深色模式

许多模板未做相应调整。editor下面的方块尤其必要。 RoyZuo（留言） 2025年4月13日 (日) 14:45 (UTC)

@Shizhao：有關深色模式的問題，應該可以請教他。—— Eric Liu_（留言） 2025年4月13日 (日) 14:47 (UTC)

没有界面管理员权限，修改不了MediaWiki:Common.css#L-1328 Shizhao（留言） 2025年4月14日 (一) 03:25 (UTC)

MediaWiki:Editpage-head-copy-warn已修改 Shizhao（留言） 2025年4月14日 (一) 03:29 (UTC)

完成 Midleading（留言） 2025年4月14日 (一) 03:46 (UTC)

@Shizhao, Midleading：我在想是否可提名Shizhao為本站介面管理員？他在百科也有權限，經驗足夠，可以協助文庫時不時的介面維護。—— Eric Liu_（留言） 2025年4月14日 (一) 07:06 (UTC)

editor下方區塊問題，可於本樣式表處抄寫一份回去套用。

除了WS命名空間及受保護模板以外的樣式，用戶亦可自行動手更新。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年4月13日 (日) 15:16 (UTC)

2025年第16期技術新聞

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

本週要聞

• 本週稍晚，預設的縮圖尺寸將從220px增至250px。這將改變所有維基頁面的顯示方式。部分社群多年來一直要求更改預設縮圖尺寸，但過去因技術限制而未能實現。 [146]
• 檔案縮圖現在以特定尺寸儲存。如果頁面指定的縮圖尺寸不在標準尺寸（20、40、60、120、250、330、500、960）之列，那麼MediaWiki將會選擇最接近的較大縮圖尺寸，但會請瀏覽器將其縮小到所要求的尺寸。這在視覺上不會有任何變化，但使用者可能會載入稍大一點的圖片。在頁面中使用縮圖時，如果縮圖尺寸不是很重要，請選擇其中一種標準尺寸，以避免額外的瀏覽器縮小步驟。 [147][148]

近況更新 - 面向編輯者

• 維基媒體基金會正在開發名為Edge Uniques的系統，該系統可用於實現A/B測試，幫助抵禦DDoS攻擊，並讓我們更容易了解維基媒體網站的訪客數量。有了Edge Uniques，基金會可以更有效率地打造能幫助讀者的工具，讓讀者更容易找到他們要找的東西。
• 為了提升使用者安全性，現在有一小部分的登入嘗試將需要輸入一次性密碼，該密碼將以電子郵件寄送。請檢查您的帳號是否設有有效的電子郵件地址，且該地址已被系統確認。 [149]
• 「您有沒有興趣參加一個簡短的調查，以改善您的維基上的巡查和回退工具？」這個問題將從下週開始在7個維基的近期變更和監視清單頁面上向使用者提出。內容維護工具團隊想更了解那些：檢視維基媒體專案的新編輯，並判斷這些編輯是否遵守專案方針的工作。
• 4月15日，query.wikidata.org將不再支援完整的維基數據圖表。該日之後，學術文章將可透過query-scholarly.wikidata.org取得，而維基數據上託管的其他資料則可透過query.wikidata.org端點取得。這是預定的維基數據圖表拆分計畫的一部分，該計畫於2024年9月公布。詳情請見維基數據頁面。
• 季刊維基媒體App電子報新期數發布。內容涵蓋了維基百科行動應用程式的更新、實驗與改進。
• 上週有30件社群提交的工單得到解決。

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

• 季刊技術社群電子報新期數發布。 本期內容包括：邀請工具維護者參加4月15日的Toolforge UI社群回饋會議；近期社群指標；近期技術方面的Diff文章。
• 本週稍晚代码更新細節： MediaWiki

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2025年4月15日 (二) 00:24 (UTC)

Vote now on the revised UCoC Enforcement Guidelines and U4C Charter

The voting period for the revisions to the Universal Code of Conduct Enforcement Guidelines ("UCoC EG") and the UCoC's Coordinating Committee Charter is open now through the end of 1 May (UTC) (find in your time zone). Read the information on how to participate and read over the proposal before voting on the UCoC page on Meta-wiki.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review of the EG and Charter was planned and implemented by the U4C. Further information will be provided in the coming months about the review of the UCoC itself. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C -- Keegan (WMF) (talk) 2025年4月17日 (四) 00:35 (UTC)

竖排表格

请教 竖排表格如Page:NLC416-03jh004219-15285 香港—「東方的馬爾太」.pdf/34如何处理？有现成转录可参考吗？ RoyZuo（留言） 2025年4月18日 (五) 07:45 (UTC)

我隨手弄了一個，您看著合不合用，先湊合著。

不過我倒覺得此處不用豎排就是了，按本書其餘部分錄入時好像也沒見到豎排相關的樣式？

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年4月18日 (五) 08:24 (UTC)