维基文库:写字间

←社區

写字间

存檔→

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

维基文库项目

维基文库是什么

维基文库与维基教科书

写字间

投票

版权信息

版权讨论

删除讨论

移动请求

请求管理员帮助

發言更新圖例

• 最近一小時內

• 最近一日內

• 一週內

• 一個月內

• 逾一個月

特殊狀態

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

手動設定

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

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

RESLOVED：

經社群決議，已在Phabricator開設任務頁面。—— Eric Liu_（留言） 2025年4月28日 (一) 18:27 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，包括本框格外部下方，并不要再次编辑本讨论。

---

See More

如题。免得有些网页来源失效了。 ——— 红渡厨（留言・贡献） 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)

---

今已在Phabricator開設任務頁面，本地社群無可作為，故關閉討論，請等待機器人操作者回覆。—— Eric Liu_（留言） 2025年4月28日 (一) 18:27 (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)

這是什麼字？

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

四

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

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

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

原圖：[1]

大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事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)

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

原圖：[4] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事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

原圖：[5] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事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

[6] 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事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)

八

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

原圖：[7] 70

[8] 68

[9] 69

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

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

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

我找到了新的文字來源[11] 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)

九

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

原圖：[12] 339

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

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

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

[14] 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)

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

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

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

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

十二

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

原圖：[17] 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)

十三

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

原圖：[18] 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)

十四

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

原圖：[19] pg 16

[20] pg 16

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

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

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

十五

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

原圖：[21] 83

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

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

原圖同上

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

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

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

「敷榮」者歛其液

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

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

十六

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

原圖：[23] 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)

十七

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

原圖：[24] 37

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

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

十八

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

原圖：[25] 66

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

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

十九

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

原圖：[26] 72

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

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

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

二十

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

原圖：[27]

[28]

[29] 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)

二十一

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

原圖：[30] pg 3

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

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

二十二

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

原圖：[31] pg 57

[32] pg 93

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

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

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

原圖：[33] pg 48

[34] pg 84

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

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

二十三

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

原圖：[35] pg 95

[36] pg 130

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

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

二十四

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

原圖：[37] 13

[38] 287

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

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

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

[39] 38

[40] 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)

二十五

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

原圖：[41] 53

[42] 47

[43] 52

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

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

二十六

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

原圖：[44] 78

[45] 73

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

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

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

原圖：[47] 86

[48] 84

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

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

二十七

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

這個字是不是「㤙」？

原圖：[50] 108

[51] 19

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

[53] 21

[54] 110

[55] 25

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

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

原文：「神明政▣琴」

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

[56] 21

[57] 105

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

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

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

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

二十八

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

是不是「拋」？

原圖：[59] 122

[60] 33

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

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

原圖：[62] 45

[63] 133

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

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

[65] 74

[66] 70

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

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

二十九

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

原圖：[68] 187

[69] 28

[70] 29

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

[71] 188

[72] 30

[73] 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)

三十

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

這個字是不是「其」？

原圖：[74] 191

[75] 31

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

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

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

[77] 31

[78] 33

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

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

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

三十一

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

原圖：[80] 64

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

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

三十二

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

原圖：[82] 43

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

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

三十三

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

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

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

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

三十四

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

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

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

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

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

三十五

見於此校對頁標題。「⿱艸酴」，疑與「荼」同義，但未查到。 另外，作品的子頁名有此字，如何妥當命名子頁面？Andayunxiao（留言） 2025年4月24日 (四) 16:58 (UTC)

𨢬。至于布局上的差异，见[86]，会被统合，您如果觉得需要反映出这一差异，我想可以选择一些有悬停显示的模板。 银色雪莉（留言） 2025年4月24日 (四) 17:12 (UTC)

感謝指點。如果命名為「空山霝雨 (1925)/𨢬蘼」，是否加頂注模板説明？中文維基百科有w:Template:CJK-New-Char模板，但未找到條目名有未編碼字的先例。 Andayunxiao（留言） 2025年4月27日 (日) 06:46 (UTC)

本地也有此模板Template:CJK-New-Char。我不太懂您指的顶注是指因为“𨢬”是扩展B区还是说因为用此字时与原貌有差异？不过我觉得都还好，不是一个非可非不可的问题——当然这只是我的个人看法；如果是后者，我也不大了解模板是否做得到（抱歉我对于技术类的知识实在是贫乏），或许可以在对应子页面讨论页作一简要说明即可？ 银色雪莉（留言） 2025年4月27日 (日) 08:32 (UTC)

後者，即出現在頁面名中的字和原字不同，是否需要標記，無關正文中的異體字。此例僅有些許佈局差異，同意特別標出并不必要，後續會在討論頁留説明。我不熟悉維基百科的方針，假設某人名字有未收錄僻字，又沒有別號，這個人的百科條目怎樣命名？百科社群希望特別標記「此人的正確名字是……」嗎？ Andayunxiao（留言） 2025年4月27日 (日) 08:55 (UTC)

这对应的应该是w:Template:未收錄漢字和w:Template:Correct title，一些具体例子如w:世界第一⿺麥方和w:黎維⿰礻密，具体的方针详见w:Wikipedia:命名常规/技术限制#缺字和僻字。从这些方针和实例看，百科采取条目标题作部件分割显示+顶注用Correct title模板的做法。 银色雪莉（留言） 2025年4月27日 (日) 09:30 (UTC)

甚至这两个模板本地也有Template:未收錄漢字和Template:Correct title，想来足以以任何方式解决我们讨论的事项了哈哈哈，不过像您说的，本例只是布局差异，与这些模板真正的对应使用场景还是有差异，无此必要。 银色雪莉（留言） 2025年4月27日 (日) 09:33 (UTC)

十分感謝查明。這些模板可為社群參考。 Andayunxiao（留言） 2025年4月29日 (二) 15:41 (UTC)

補一個操作：

對於{{FULLPAGENAME}}解析為𨢬蘼的頁面，內容添加{{DISPLAYTITLE:{{！|𨢬|⿱艹酴}}蘼}}後，可以使標題調用僻字模板顯示註解。(UnO模板的架構稍有不同，在此不適用)

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年4月28日 (一) 07:09 (UTC)

受教了。已在空山霝雨_(1925)/𨢬蘼實驗，未見效果，可能需額外支持？此例現樣式已經很滿意，各方案可作未來社群參考。 Andayunxiao（留言） 2025年5月1日 (四) 06:36 (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)

识典古籍相关的问题

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)

直排之技術問題

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

就技術而言，維基媒體基於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)

我嘗試了改直排後讓頁碼也跟隨直排文本。主要障礙是英文文庫原方案的頁碼是在正文内容（ws-region-container類）的姊妹容器中，其偏移位置是相對與全頁而非上述類。@Midleading，是否允許小工具將直排頁碼的實際位置（id=ct-pagenumbers）移到正文中？此法在樣式上最簡，惟會改變頁面結構，希望不會影響下載電子書等第三方用途及工具。 Andayunxiao（留言） 2025年4月22日 (二) 06:42 (UTC)

本人目前傾向於頁面布局保留英文文庫原方案，由該小工具根據使用者設置直接將ws-region-container設置為橫書或縱書。此方案可使大量未應用縱書排版的頁面直接獲得縱書排版，並可免除另加縱書排版模板。只是暫時未有時間改進該代碼，可能需要等待6個月。 Midleading（留言） 2025年4月22日 (二) 07:27 (UTC)

瞭解並贊同。直排頁碼為次要功能，本人也不希望影響此小工具本體開發。閣下是否已有更好的直排頁碼的實現方式？據我理解，問題在於CSS樣式和HTML結構，而非腳本。如閣下愿指點，本人也許可以先行實驗實現。 Andayunxiao（留言） 2025年4月22日 (二) 07:49 (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頁起「句號無形的消滅」的解釋，可能一窺當日的理解：[87]。

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浏览器显示成这样：[88]。为了避免自定样式的影像，使用的是匿名模式。 維基小霸王（留言） 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)

 中立诗歌的话，也可能牵涉这个美国法案使其美国版权发生微秒变化，这样一来能不能提供演唱版本就成了一些问题。--Liuxinyu970226（留言） 2025年5月18日 (日) 05:08 (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)

已创建{{PD-PRC-ineligible}}用于说明本文件依法不属于作品，属于公有领域 Midleading（留言） 2025年4月30日 (三) 12:02 (UTC)

已就该讨论建立存档路径。尽管已有判例，我个人建议社群对使用此模板而录入的文献仍应加强留意——即以“已有的例证”范畴来使用，而避免由社群或任意用户自由解释其定义及范围。--银色雪莉（留言） 2025年4月30日 (三) 21:52 (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)

美国之音、自由亚洲电台即将关闭，是否应该将历史内容导入维基文库？

美国之音、自由亚洲电台即将关闭，是否应该将历史内容导入维基文库？

版权：

美国之音：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)

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)

《瀛環志畧》校對頁化提議

据百科條目，此書初版於道光戊申（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#可不可能向二位固執用戶溝通，已向四次擅自回退解任案[89] [90] [91] [92]的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)

已經8票，我雖然不贊成他們這種動議，但是要搞，我們就要按現有規則好好整理一下。以下我參考這次U4C做了一個模板，歡迎社群討論修改。瓜皮仔＠Canton 2025年4月25日 (五) 13:25 (UTC)

最後溝通

當事人溝通

當事人（提起溝通和被溝通人）之間的溝通，社群可主要以提問方式參與

社群討論

當事人以外社群對雙方進行評議，當事人不得在此留言

2025年第15期技術新聞

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

近況更新 - 面向編輯者

• 從今以後，系統會要求介面管理員和中央公告管理員必須先啟用雙重認證，才能行使其權限。未來這項措施可能會擴大到更多具有高級權限的群組。 [93]
• 上週有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)

一點責任感都沒有全憑心情那還做什麼管理員，當個志願者都不及格。

管理員手握特權，自然就要制定相應機制加以限制，防止濫權，這跟他是否獲得實物報酬完全無關。管理員對於文章編輯也有超出普通用戶更高的權限。例如鎖定作品等。並非僅限於封禁用戶。收緊不活躍標準自然是為了讓其更為積極的為社區服務。

問題的關鍵在於減編，即本人在上面留言所說，管理人數和社區人數應該遵循合理比例，這個社區人非常少，無需那麼多管理員來維護所謂日常秩序， #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 07:35 (UTC)

希望你注意到，管理員的主要「責任」不是「維護日常秩序」，而是執行社群共識。本站社群活躍人數相對百科而言不多，但討論內容可不少；刪除討論、版權討論等站務工作積壓如山，雖然本質是由於參與人數不足，管理員沒有執行共識的基礎，但我想不到所謂「減編」對事態有何幫助。何況你也沒考慮到所有管理員都是志願者，不會一年到頭隨時在線，既然不像是公司有「排休」，那給予一定期間的編輯緩衝期，就是穩妥的折衷措施。遑論目前的解任限制純粹是基於安全考量，現行六個月其實很足夠了，甚至有點過頭（據我所知，本站沒有任何管理員被盜過號而發生破壞），所以方提議重新與元維基乃至於全域標準對齊。—— Eric Liu_（留言） 2025年4月20日 (日) 08:32 (UTC)

維護日常秩序是責任之一，否則不存在濫權封禁。社區共識由用戶自行討論完成，並非每個案件都需要管理員參與才能凝聚共識，執行結果更不需要花多少時間和精力。

從之前和目前現實運作來看，遠遠沒有達到你們所謂的管理員在超負荷運轉工作的程度，恰恰相反，幾乎所有管理者都在尸位素餐，從頭休息到尾。天天都在休假，就沒幾個稱職工作的。對這些人還沒辦法處理。

你說這麼多無非就是怕把你的位置搞掉了，你放心，如果有解任你的那場投票，我肯定行使權利投讚成。至於原因到時候自然會說，我考慮的非常周全，而且出發點單純良善，問心無愧。其他沒必要繼續多說了， #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 09:16 (UTC)

？—— Eric Liu_（留言） 2025年4月20日 (日) 16:17 (UTC)

所謂「尸位素餐」，基本上就是對管理員權限性質的最大誤解。當然倒是不怪你，畢竟維基百科那邊持這種思想的同人也很多。—— Eric Liu_（留言） 2025年4月20日 (日) 16:21 (UTC)

這裡是非營利組織，不需要老闆來壓榨工薪，和別處營利組織是完全不同的。減編增效是老闆裁員的籍口，減編一定會導致工作效率下降，而增效只不過是老闆可以少付工薪而已。要是有人出資請管理員有償編輯，但又想找籍口停止出資，才需要找減編增效的理由。有義工非營利為老闆工作，老闆才不會說要減編增效。 Midleading（留言） 2025年4月20日 (日) 16:34 (UTC)

限制管理人數，引入競爭機制通過優勝劣汰當然可以提高效率，選拔人才。你作為現任管理，可能由於重新洗牌遭到波及，從而官官相護，不會支持並不難理解。

這事和壓榨不壓榨沒任何關係，即便不支付報酬，社區管理層依然存在人浮於事，管理人數和普通用戶數比例嚴重失衡，導致的人員冗餘的問題。

而且如果整個機構都是非營利性的，就沒有所謂機構老闆通過壓榨員工從中獲利這種事，機構中沒有人獲得任何報酬的話，那連老闆這個角色本身都是不存在的。現在基金會官方的意思依然是此類管理事務推給社區自己處理。如果你指的老闆是他們，我的看法是他們對本社區的態度是切割和逃避，對管理員是否減員這件事無意參與。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 17:49 (UTC)

“你作为现任管理，可能由于重新洗牌遭到波及，从而官官相护，不会支持并不难理解。”这是Midleading执行的删除日志，这如果能叫做“不活跃”的话我不知道什么人才能够当本站的管理员。 dringsim 2025年4月21日 (一) 01:58 (UTC)

可以看出你似乎堅持著一種「企業管理式」的邏輯，要編定「員額上限」、「工作指標」，去「壓榨」管理員、鼓動他們互相「競爭」，乃至於開除所謂「不夠勤勞」者，以提高「單位業績」。這種過於激進的信念，根本忽視本站管理員（以及幾乎所有維基人）均出於志願且毫無限額的基本事實，看似能產生短期「拔高」的效益，實則是揠苗助長，更將激化編者對立，打擊本願意提供些許幫助的同志，對社群長期維續非常有害。至於其餘「濫權」云云的「滑坡」論述，既然明是為了掀起「黨爭」的陰謀論而來（整個討論在場到處指責他人「拉幫結派」、又給別人劃配什麼「盟友」的大概也就你一位吧？），那就自不必多談了。所謂「三個月活躍期」的幌子，不過是其中一種道理似是而非的表徵而已，背後所整體反映者，實是極為病態的鬥爭思維。顯然編輯維基文庫（或其他任何維基站點）可大不同於營運企業或官僚政黨，而這想必是你所無法理解的。所以社群諸位在鑑於實際考量而保留一定限度的解任期安全機制之餘，無論是否有意參與站務工作，甚至是否在個別治理政策上有所歧異，都應該團結起來，堅決駁斥以上這類殺雞取卵的路數。—— Eric Liu_（留言） 2025年4月21日 (一) 04:14 (UTC)

囍鵲說的好，建議社群選我當管理員，以便我每3個月“積極的”封禁囍鵲（笑） dringsim 2025年4月20日 (日) 08:45 (UTC)

你要真當上管理員卻胡作非為亂封禁用戶，我肯定投訴到底。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 09:18 (UTC)

你就说“积极”不“积极”吧。 dringsim 2025年4月20日 (日) 10:16 (UTC)

在你眼中，管理員的任務只有監督用戶而已，所以不積極才是對的。否則就是濫權。

而在你的盟友Eric Liu眼中，管理員的任務種類繁多，目前已經積極工作到需要定期療養三個月上一次線都多餘的地步，所以必須增加人手才是對的。否則就是喪心病狂不體諒管理。

而事實是，本站事情極少，完全不需要目前這麼多懶惰的管理員，需要的是減編增效。減編至接受適度工作強度、責任心強、自願犧牲個人時間，且人數不超過3名的適任管理員即可。一旦出現消極懈怠，例如三個月不活動，那就應該另選賢能取代之。

你要是還無法理解我說的，建議你和你的盟友先打一架，勝出的那位再來和我詭辯。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 10:47 (UTC)

没有什么限制的时候都没见多选出几个管理员，增加平均工作量就能“选贤能”了？你这么搞无非把人力变得更少而已。

“在你眼中，管理员的任务只有监督用户而已，所以不积极才是对的。否则就是滥权。”我可没这么说，我说的是你拦不住管理员“积极地”滥权。 dringsim 2025年4月20日 (日) 11:02 (UTC)

你爭取選上一次，濫權一次，就知道有沒有人能攔住。

其他說了很多你好像也完全不懂，無意再交流。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月20日 (日) 11:20 (UTC)

这种“拦住”和阁下的长期未活动（三个月以上）之管理员，如无法给予合适的理由及说明，默认为对待本职工作消极懒惰有任何关系吗？哪怕是收紧到3天，管理员照样能挂脚本滥权。 dringsim 2025年4月21日 (一) 04:13 (UTC)

我剛才都說那麼多了，你們兩位都表示完全聽不懂，還有必要繼續交流和提問嗎？

時機到了我自然會對能聽懂我說話的人進行說明。不要沒完沒了。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 09:25 (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)

補充一下，此處可能有所誤會，我說的是Zhxy 519跟Jusjih兩人，Gzdavidwong這邊目前完全沒看出來有需要提起解任。—— Eric Liu_（留言） 2025年4月20日 (日) 08:32 (UTC)

@Ericliu1912的确，上次讨论不活跃管理员标准修订的存档里，我也是没曾想过Zhxy那位竟然“自己警告自己”：“最后一次警告。我尊重阁下的贡献，但有贡献不代表可以口无遮拦。”这2句话紧跟着ta自己的“请注意文明。” Liuxinyu970226（留言） 2025年4月21日 (一) 06:18 (UTC)

另外我反对照搬元维基AAR的2年做法，2年间能改变的事情实在太多，除非本站真的小到极致，不然每2年才编辑几次甚至一次的用户就要当管理员简直搁谁身上都觉得害羞。如果真要问我怎么去修订这个不活跃标准，我的想法是结合元维基站点方针和中维方针的糅合改编版：

1. 在指定的审阅日期（每年4月1日和10月1日）当天，过去五个月（以150天计）未曾做过在用户贡献或日志中有记录的编辑者可直接提报元维基申请除权，恕不再通知。
2. 在同上指定的审阅日期当天之前五个月期限内，虽作出相关编辑，但未作出任何管理员限定操作（譬如封禁/解封用户、删除/恢复/保护/解除保护页面、编辑受全保护页面等）者给予一个月（以30天计）宽限期，咨询当事人是否仍愿意保留管理员权利，一个月内未回应要求保留权限（即便仍有编辑）的话可提报元维基申请除权，如回应保留或移除则依当事人回应。
3. 如有界面管理员等其他管理人员权限，符合不活跃标准时一并解除相关权限。

不知道每位阁下（不只是Erucliu1912）是否愿意接受这个版本。 Liuxinyu970226（留言） 2025年4月21日 (一) 06:40 (UTC)

对了，为了防止有人拿这个“审阅日期”做漏洞文章，审阅日期按UTC本时区00:00计。 Liuxinyu970226（留言） 2025年4月21日 (一) 06:43 (UTC)

现有方针、提议的方针和元维基方针相比不过是一个管理员每2年编辑4次还是1次的区别而已，有什么必要改得那么复杂么？ Midleading（留言） 2025年4月22日 (二) 07:50 (UTC)

不知道為什麼要改得那麼複雜，即使現行指引都要好一些。—— Eric Liu_（留言） 2025年4月22日 (二) 08:24 (UTC)

@Midleading关键是老有人在这个问题上钻漏洞让人很不爽。 Liuxinyu970226（留言） 2025年4月23日 (三) 23:47 (UTC)

所以到底是要支持管理员不可以放6个月假期，还是支持管理员可以每2年编辑不超过5次呢？ Midleading（留言） 2025年4月24日 (四) 04:59 (UTC)

@Midleading所以说阁下希望本站的不活跃方针允许以下两种情况咯？

1. 某管理员只照常编辑，从不封禁ta人、从不保护页面、也从不删除页面...
2. 某管理员一直封禁ta人、保护页面、删除页面，却从不编辑...

Liuxinyu970226（留言） 2025年4月24日 (四) 07:05 (UTC)

我倾向于不要搞假期制，也暂不寻求重新选举本地行政员（毕竟元维基对行政员选举有特殊强制要求，想想去年中文维基新闻那两个申请怎么失败的就知道了），后者的情况C区已经有人吐槽若干遍“潜水艇管理员”（具体是谁我就不细说了）。 Liuxinyu970226（留言） 2025年4月24日 (四) 07:10 (UTC)

无论是管理员只照常编辑还是只进行管理员操作起码都有一些价值（只进行管理员操作但从不回复管理操作复核请求可能会有争议）。但是如果每2年只编辑不超过5次的话，这些编辑几乎都是用于回复提醒的，令人怀疑这到底是在为维基项目作贡献还是只是在养号。维基文库起码还好点，看看维基语录吧，那里可是真正有永久管理员连续性每2年只编辑一次和进行一次管理员操作，就剩Jusjih一个永久管理员偶尔管理一下了。不过管理员休息一段时间是很正常的，要解决这问题就要禁止管理员休息了，维基百科和共享资源都没讨论清楚的问题，在维基文库这本来就基本不可能解决。所以现在还是建议大家多多申请管理员吧，等到养成了永久管理员账号，你们也可以每2年只编辑不超过5次。@Ericliu1912：下次可能会成为永久管理员了，而且在维基语录也是临时管理员，不知道你对这问题怎么想呢？ Midleading（留言） 2025年4月24日 (四) 09:08 (UTC)

首先我得說，本地反對者太多，我感覺自己很難續任啊（自己看上面的討論）⋯⋯而且我也毫無「申請成功就擺爛」的意思。無論如何，我對於離任機制，始終認為應保持最低限度。因為我一貫將管理員的貢獻視為「加法」而非「減法」，某人有時少來，並不代表他即應當喪失服務的資格。除非能夠證明，他有明確的濫權行為，或者對於社群政策理解有嚴重誤差，否則均不必輕易訴諸解任。—— Eric Liu_（留言） 2025年4月24日 (四) 09:18 (UTC)

1.只编辑（且编辑的都不是全保护页）从不封禁保护删除，可能刚开始获得权限时对具体操作详情还有所不熟自然值得理解，但长期有这种现象的话，意味着有关用户对管理员这一神圣的社群管制权利恒久缺乏基础知识，以为只是带个小皇冠很好玩，全然不知其背后的社群责任。那么ta们努力了半天当上又有何意义呢，没有这权限照样该好好编辑也能好好编辑。这还不是“昏君”么？

2.只封禁保护删除从不参与编辑，就算这做法有一点点合理性，我们已经拥有了AbuseFilter专用管理员账号了（任何装了这个扩展的wiki上都默认至少有这个“管理员”，是系统性账号，性质跟机器人一样），一个真人却在干AbuseFilter本体干的事，甚至全然无知其他用户对其意见，当自己能模拟AF，甚至不惜跟AF抢活，把自己整的很自动化一样，这居然还有人能接受？反正如果我看到这类情况，我会毫不犹豫的认为这种“暴君”就是一个Spambot。 Liuxinyu970226（留言） 2025年4月24日 (四) 09:30 (UTC)

不活跃方针明确指出那只是用于避免管理员因忘记密码造成安全隐患的。其他不适任管理员的因素请通过常规管理员解任流程操作。目前的方针是必须证实管理员有明显滥权或其他严重违反维基方针，而每6个月仅编辑一次显然不属于这种情况，除非从管理员的离任方针中取消这一条款，允许针对管理员只编辑或只封禁保护删除从不参与编辑这两种情况发起常规管理员解任流程。

另外，试问某用户一直在删除讨论、版权讨论和请求管理员帮助中不断申诉使得编辑次数达到了50次，而其他贡献已被删除或是不足50次，那这个用户是否有人事任免投票资格呢？ Midleading（留言） 2025年5月2日 (五) 11:30 (UTC)

看了Wikisource:投票#各式投票資格，版权讨论和请求管理员帮助中不断申诉使得编辑次数达到了50次，不像合乎“50次正文編輯”。--Jusjih（留言） 2025年5月2日 (五) 17:21 (UTC)

@Midleading“避免管理员因忘记密码造成安全隐患的”得了，以后但凡还记得密码的管理员都不应该被提请除权了，这个流程废废了。 Liuxinyu970226（留言） 2025年5月2日 (五) 22:03 (UTC)

“允许针对管理员只编辑或只封禁保护删除从不参与编辑这两种情况发起常规管理员解任流程。”我反而希望就这两种情况允许直接提报不活跃程序，毕竟这是为数不多可以不经共识就能做出除权决定的情形。 Liuxinyu970226（留言） 2025年5月2日 (五) 22:07 (UTC)

可以不经共识就能做出除权的前提是这个理由本身已经获得了广泛共识。把不同程序混合起来会在有人申诉的时候变得混乱。如果这两种情况允许直接提报不活跃程序的话，当事人还可以根据“但此举只是系统的例行事务，不应视作惩罚”通过申诉恢复管理员权限，这一程序是方针中唯一没有对申诉恢复管理员权限作出规定的程序。如此就变成了该管理员每6个月申诉一次，和当前的情况几乎一样，只是更搞笑了！ Midleading（留言） 2025年5月3日 (六) 02:52 (UTC)

对啊，我也不认为这种除权程序是什么“惩罚”，只是总有些用户故意妖魔化除权程序，搞得人心惶惶。 Liuxinyu970226（留言） 2025年5月4日 (日) 01:26 (UTC)

@Midleading综上，我继续冀希望阁下放弃有关避免管理员“因忘记密码”造成安全隐患的这一观点，因为这种情况非常罕见，极少有管理员会忘记密码。 Liuxinyu970226（留言） 2025年5月5日 (一) 22:27 (UTC)

“忘记密码”只是不活动状态的管理员具有安全隐患的一种情形，不排除还有其他情形。重点是目前方针明确规定管理员长期没有活动可以取消权限的原因是“处于不活动状态的用户拥有管理员权限，是系统的安全隐患，也给维基带来虚假的安全感。”这跟阁下所说的“昏君”或者“Spambot”完全不是同一件事，“昏君”同样可以保护好自己的账户。对这种情况，修改不活跃程序根本就是无效的。这种管理员并不是不活跃，而只是对编辑维基文库不活跃而已，只要一有跟管理员解任有关的消息，很快就会出来解除“危机”，如果一时找不到可以进行的管理员操作，在删除讨论里随便找个正在进行中的讨论强行删除结案也行，维基文库那么多积压的删除讨论，分不清管理员随便关闭一个到底是不是合理的。没事以后，又可以休息6个月。另外，你不认为这种除权程序是什么“惩罚”不代表当事人也这样。理论上除权程序或者是封禁都不是一种“惩罚”，但实际上，已经有管理员想尽各种办法阻止除权程序并且连续多次直接删除针对自己的除权讨论了。看看维基百科，除权程序一通过，当事人直接就再也不编辑维基百科了，像被永久封禁一样，这是一种“惩罚”吗？ Midleading（留言） 2025年5月6日 (二) 14:15 (UTC)

可見大多數管理員對社區不但提供不了多少實質幫助，偷懶耍滑乃其常態，還多貪戀權位，為了賴在職位上，手段無所不用其極。

另外wiki站群管理員是能夠核查普通用戶ip相關信息的，在網絡中這已經是賦予管理員非常大的權力了。若其道德敗壞，為了打擊跟自身政見不合或看不順眼的用戶，私下有意或無意將用戶情報洩露給第三方，造成現實中的危害。請問誰來負責？

我為什麼一直主張管理員這玩意宜少不宜多。總數最多不能超過3人，就是為了最大限度防止此類惡劣事件發生的可能。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年5月6日 (二) 14:39 (UTC)

保留页面决定，恕我直言中的恕我直言，不应该算管理员操作，因为至少理论上非管理员用户也可以做出保留。 Liuxinyu970226（留言） 2025年5月6日 (二) 22:35 (UTC)

“没事以后，又可以休息6个月。”这恰好中的恰好中的恰好解释了我为什么反对照搬AAR搞2年，因为这样一来用户甚至可以没事以后，休息2年。2年前的今天，我们还不相信中美会闹到脱钩呢，2年后的今天，中美关税战升级成脱钩战了；2年前的今天，我们以为美国会持续军援乌克兰帮助ta们光复克里米亚和乌东，2年后的今天，连基辅甚至波兰波兹南能不能保住都成了问题；2年前的今天，您可曾想过上海地铁徐泾东站和诸光路站会合并成一个站？2年后的今天，两者合并更名为国家会展中心站...等等，真的有很多世事只需要2年就会发生显著变化，每2年才编辑一两次的用户显然只会就此措手不及，让这类超级低调用户当管理员，简直更像是对社群的大开玩笑，只会让这个维基站点变成一整个笑料。 Liuxinyu970226（留言） 2025年5月6日 (二) 22:43 (UTC)

其他不談。兩年前本人倒是就算到川普會勝選，美中在經貿上會徹底脫鉤。China會因外貿環境惡化與出口密切相關的低端製造業領域大面積倒產導致經濟一路下行直到徹底崩壞。

相較於社群治理方面最為黑暗的文庫，中文維基百科至少還有最基本的規則底線，建立較為完善的退出機制，能夠保證管理員出現重大問題時，用戶能通過合法途徑將其趕下台。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年5月7日 (三) 00:46 (UTC)

从中美关税战聊到上海地铁车站，有哪一项是和本站直接相关的吗？可以谈谈本站2年间具体的变化吗？ dringsim 2025年5月8日 (四) 17:34 (UTC)

此外，我建议将上述“自己警告自己”的行为设法排除出有效编辑序列。 Liuxinyu970226（留言） 2025年5月6日 (二) 22:52 (UTC)

所谓“自己警告自己”很明显是缩进出错啊……看Wikisource:写字间/存档/2024#c-Zhxy_519-20240715160300-Zhxy_519-20240714211300的留言时间就知道实际上在回复哪一条留言了。 dringsim 2025年5月8日 (四) 17:31 (UTC)

“另外wiki站群管理员是能够核查普通用户ip相关信息的”，该项权限在本地只有用户查核员才能持有，本站没有用户查核员。 dringsim 2025年5月7日 (三) 13:08 (UTC)

顯然他為了「推動」議程開始亂扯一些不知道的東西了⋯⋯我很懷疑他是否明悉維基站點管理員的權限。—— Eric Liu_（留言） 2025年5月8日 (四) 15:22 (UTC)

他21年就在乱扯了。。。 dringsim 2025年5月8日 (四) 17:39 (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。這將改變所有維基頁面的顯示方式。部分社群多年來一直要求更改預設縮圖尺寸，但過去因技術限制而未能實現。 [94]
• 檔案縮圖現在以特定尺寸儲存。如果頁面指定的縮圖尺寸不在標準尺寸（20、40、60、120、250、330、500、960）之列，那麼MediaWiki將會選擇最接近的較大縮圖尺寸，但會請瀏覽器將其縮小到所要求的尺寸。這在視覺上不會有任何變化，但使用者可能會載入稍大一點的圖片。在頁面中使用縮圖時，如果縮圖尺寸不是很重要，請選擇其中一種標準尺寸，以避免額外的瀏覽器縮小步驟。 [95][96]

近況更新 - 面向編輯者

• 維基媒體基金會正在開發名為Edge Uniques的系統，該系統可用於實現A/B測試，幫助抵禦DDoS攻擊，並讓我們更容易了解維基媒體網站的訪客數量。有了Edge Uniques，基金會可以更有效率地打造能幫助讀者的工具，讓讀者更容易找到他們要找的東西。
• 為了提升使用者安全性，現在有一小部分的登入嘗試將需要輸入一次性密碼，該密碼將以電子郵件寄送。請檢查您的帳號是否設有有效的電子郵件地址，且該地址已被系統確認。 [97]
• 「您有沒有興趣參加一個簡短的調查，以改善您的維基上的巡查和回退工具？」這個問題將從下週開始在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)

古文的句讀版本建議另開新頁

如果原文沒有句讀，我認為古文的原文不應該添加句讀，而是應該照著原樣錄入，並且w:抬頭也應該儘量地原本保留。從某種角度來說，加標點版本並非原文，乃是基於原文的一種現代原創。因為雖然大差不差，但不同的人對其進行斷句時還是有可能斷句在不同位置，或使用不同的標點符號，不盡相同，所以我認為應該的另外建立頁面，並在原文頁面標識「此頁存在句讀版本」。

某些句子存在多種意思，自行添加句讀有可能曲解原作者的本意，例如w:下雨天留客天留我不留便是很著名的例子。而且越是艱澀難懂的古文，若是句讀有誤，容易對大家產生誤導，還是原文無標點，句讀版本另開一頁為妙。又如《琉球國舊記/卷之三》中有一句：「阿名呉之子奇怪之跑走以告其妻〻曰此壺必有神靈者乎」，顯然在叠字符號「〻」之前應斷句，但現代漢語沒有將標點符號後的第一個字寫為叠字符號的習慣（@Liouxiao：在這處沒有斷句，可能也是覺得遇上這個情況難以處理）。另外，抬頭在古代儒家文化圈中非常重要的文化，以示對長輩、神明之類的尊敬，在文字獄極其變態的滿清中期，甚至擡頭方式使用錯誤都有可能被問罪。而且經過句讀斷句後，挪擡、平擡都往往會被刪去，這丟失了原文的樣貌，不太合適。而且非常值得一提的是，標點符號是否擁有版權是存在爭議的。目前很難認定添加標點是否為貢獻者的原創行為，而且有可能不少貢獻者是直接將帶有標點的古文貼過來的，存在面臨訴訟的風險，在Wikisource:版權討論/存檔/2020年的討論中有關於標點符號的問題，@蟲蟲飛：說「此例一開，我擔心所有文庫中的古文都要下架」，這是文庫重大風險，我覺得有必要儘量規避。綜上，我覺得很有必要將古文的句讀版本另開新頁。

其實若是技術上可行的話，我覺得竪排本的古文都應該照搬原樣使用竪排，但是像目前四庫全書這樣的竪排（例：周髀算經 (四庫全書本)）實在太過難以閲讀。這方面技術很有必要加以改進。另外希望可校對版本的古籍可以支持竪排閲覽。el caballero de los Leones（留言） 2025年4月21日 (一) 15:39 (UTC)

句讀需要更改，錯字也可能會需要更改，維護加和不加句讀的兩個版本容易導致版本失去同步。現在這樣的加和不加句讀是兩個通常不需要同步的版本（如標點本+四庫全書無標點本）所以暫時沒有這方面問題，由四庫全書無標點本提供原文抬頭樣式、原文字型、竪排排版，標點本使用現代排版。

原文抬頭樣式可以在使用影印本校對頁錄入時同時錄入，但不能只有這個版本，如果一個作品只提供了一個版本的話，最好提供現代排版加標點的版本。竪排+原文抬頭樣式可能會嚴重影響在熒幕上的可讀性，一些清朝的史書每行沒寫幾個字就換行抬頭了，按原文抬頭樣式換行竪排排版會比現在的四庫全書本還難以閱讀。还有很多简体中文用户是完全不懂繁体中文、避讳以及句读的，例如中学生读者群体，也需要考虑这些读者的需求。現在有人工智能標點工具，如果將來法院判決某作品的標點符號受版權保護，可以使用這些工具重新標點該作品。 Midleading（留言） 2025年4月21日 (一) 16:46 (UTC)

先標定立場，我個人是完全支持古文不加標點的。但實務上如 Midleading所言有種種需求，是很難不加標點的。

我個人為此開發了輔助用標點{{ia}}、頂格書寫{{DG}}、挪抬{{NT}}，為的就是讓校正頁可以仿古文豎排Page:西藏紀遊_-_民國二十五年_(1936).pdf/33在嵌入後能成為現代閱讀習慣的西藏紀遊/卷一。

另外，本頁面尚有Wikisource:写字间#新建模板：允許在page頁面以傳統版式顯示、在主頁面以現代方式顯示、Wikisource:写字间#直排之技術問題討論類似內容，君或可參考。

ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年4月21日 (一) 17:07 (UTC)

閣下所指錄入時應保留古文原稿格式的問題，社區已有成員User:維基小霸王編寫old text page模版予以較好解決。通過此模版可以在底本校對頁面隱藏句讀標點，達到保留原稿原汁原味效果的同時，在新建立的橫排頁面中展示出添加標點後的作品樣貌。

不過即便使用此模版依然無法解決原文抬頭處嵌入新頁面後產生的自動換行問題：即當把底本校對頁的原稿格式頁面通過transclude pages或wikitext標籤<pages>嵌入橫排新作品頁時，底本原稿抬頭處依然會在新作品頁中自動換行。影響閱讀。

如也是錄第五頁，通過使用模版後，在底本校對頁中完美再現了原稿行文格式，但在使用transclude pages嵌入到相對應的新頁面中，原文抬頭處出現了自動斷行。

此模版另外還存在雙行注釋在嵌入頁面的格式錯誤問題，這兩個問題都需要User:維基小霸王針對transclude pages進行修復處理。（針對底本頁面中的普通換行和抬頭換行進行標記區分，再根據標記之不同特征，在新建立的橫排頁面中進行格式重排。雙注部分解決方案亦同。） #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月21日 (一) 18:25 (UTC)

竊以爲：古文原版排版，如果能找到影印原本，可以參考Index:Gujin_Tushu_Jicheng,_Volume_405_(1700-1725).djvu實現忠於原版的非標點錄入（自然是另外的新頁）——這方便上面提到的諸君已經有了不錯的示例和貢獻。而對於大多數讀者來説，有標點的版本可能更便於閲讀（至於斷句/標點的謬誤，自有細心的讀者會幫助修正的）。 Liouxiao（留言） 2025年4月22日 (二) 01:51 (UTC)

在底本校對頁錄入無標點原文格式文本，在被嵌入頁也就是對應的橫排新頁面錄入帶標點文本。

絕大多數的古文閱讀者，在無標點和有標點兩者中選擇，都會傾向閱讀帶標點文本。無他，標點斷句使得句子之間結構更清晰，能極大提升閱讀效率。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 06:09 (UTC)

好的，这叫w:挪抬，我试试。 維基小霸王（留言） 2025年4月22日 (二) 02:03 (UTC)

改好了。NTstart：挪抬开始的词，空格可分开定义多个，在page页面会解读为新段的开始，见示例。如果有多个级别的挪抬，则需要使用{{Page-only-text-indent}}，见示例。 維基小霸王（留言） 2025年4月22日 (二) 03:24 (UTC)

新增一個參數可以，不過可否根據行數來指定抬頭行。即，將參數NTstart定義為數值變量，傳入參數值為數值類型。

因為漢字是會有重複情況的。如果有些重複的字不需要抬頭，有些需要，依然會產生錯誤格式。雖然這種情況相當罕見。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 06:04 (UTC)

您好，其实已经考虑了空行，只会匹配单一（而非两个）空行的情况。而且只匹配行首，行内是不会匹配的。您可以举个例子，说明什么情况下现在的方式会出错。 維基小霸王（留言） 2025年4月22日 (二) 06:31 (UTC)

我剛才將也是錄第五頁的第四行第一個字改為“清”字，被模版錯誤的自動識別為抬頭行進行抬頭。

您可以察看。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 06:35 (UTC)

如果清在行首，按照规则应该都进行抬头。如果存在个别的古人出错忘记抬头的情况可以在行首添加<!---->避免抬头。 維基小霸王（留言） 2025年4月22日 (二) 07:00 (UTC)

不能通過指定行來達到效果麼？如果做不到，你可否按照你說的這個解決方法，修復現在的格式錯誤。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 07:10 (UTC)

那個字是隨便改的，我的意思是需要抬頭的漢字不見得都是尊稱之意，也有普通意思，如果僅代表普通意思，那就不需要抬頭，跟出不出錯無關。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 07:14 (UTC)

<!---->确实不行，但nowiki可以，已修改。您说的“指定行來達到效果”能否详述？我倾向于现在的解决方法，因为只需要修改page页面的模板，否则主页面使用的模板也需要改。 維基小霸王（留言） 2025年4月22日 (二) 07:23 (UTC)

指定行數的意思就是哪一行需要抬頭就指定哪一行的行數啊。例如第五頁里抬頭的是第七行和第八行，那就在參數里傳入7和8兩個數字。

transclude pages的業務邏輯里，輸出循環中加一個if條件判斷是否等於NTstart參數值，等於7、8時不換行就行了。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 07:29 (UTC)

你這修改的是啥？後面兩個應該抬頭的清字沒有抬頭！ #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 07:37 (UTC)

是的。各種討論過的方案都需要編者主動錄入額外資訊，至少要有（1）每個校對頁標記一次書寫方向，（2）橫排下分段（換行）。社群能否接受這些額外工序？ Andayunxiao（留言） 2025年4月22日 (二) 06:20 (UTC)

閣下提到文庫的一些竪排作品頁閲讀有困難，可否賜教是具體哪些排版因素可以改進？本人也一直覺得竪排的連續長頁面的體驗和紙書不儘相同，但還不瞭解原因是何種差異所致。如果您對上面提及的同時支持縱排橫排的討論有興趣，也歡迎閣下分享見解和經驗。 Andayunxiao（留言） 2025年4月22日 (二) 06:29 (UTC)

欽定古今圖書集成原文的排版方式我看很適合現代熒幕閱讀，也有許多現代出版物采用，可以參考。 Midleading（留言） 2025年4月22日 (二) 07:35 (UTC)

也是錄不要再修改，我恢復到初始狀態。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 09:27 (UTC)

目前自行句讀有模板可以標註，所以我覺得寫清楚就好了。不句讀對於讀者來講比欠佳的句讀更痛苦。—— Eric Liu_（留言） 2025年4月24日 (四) 09:31 (UTC)

建議為缺筆避諱字建立專用模板

建議為古籍中的缺筆避諱字建立一個專用的模板，外觀與Template:僻字相似。正常展示的是未缺筆時的原字，滑鼠移動到上面時顯示「原字缺哪一個筆畫，為缺筆避諱字」。Unicode無法完全被收錄這類缺筆避諱字，即便收錄了也在許多早期的作業系統無法顯示，不如這樣處理。el caballero de los Leones（留言） 2025年4月21日 (一) 15:39 (UTC)

整本書會充斥着這樣的避諱字，其實在作品里直接備注一下都使用了哪些避諱字更簡便易行，特別是Unicode未編碼的字，用模板替換以後到處都是背景色塊高亮的避諱字（類似楚辭 (四部叢刊本)/卷第二那样），影響閱讀。 Midleading（留言） 2025年4月21日 (一) 16:25 (UTC)

{{UnO}}就可以用來處理這種問題。我是覺得舊的{{缺字}}、{{漏字}}模板會套用高亮背景是很奇怪的事情，但我也不清楚當時的背景就是。

e.g 李朝綿原字未收錄於Unicode，結構：⿰糸⿱⿱丿口巾宗原字未收錄於Unicode，結構：⿱㝉小諱二字，絃原字未收錄於Unicode，結構：⿰糸𤣥諱𤣥。

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

維基百科導入{{僻字}}後很快就改為了無背景的{{僻字}}，維基文庫是否跟隨更新？ Midleading（留言） 2025年4月22日 (二) 02:50 (UTC)

 支持：跟隨更新，改用border-bottom: 1px dotted;樣式。ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年4月22日 (二) 03:27 (UTC)

 支持。此外，{{另}}，{{另2}}，{{參}}等模板也可統一樣式，減少背景色。作爲過渡，至少可以給這些模板加類名，讓已登入編者編輯自己的用戶樣式自訂。 Andayunxiao（留言） 2025年4月22日 (二) 06:13 (UTC)

 支持，视觉上不那么突兀。 银色雪莉（留言） 2025年4月27日 (日) 05:40 (UTC)

@Midleading, Aerotinge, Andayunxiao, 银色雪莉：是否考慮同時將模板正名為「僻字」？以「!」為主標題，就中文而言較不易懂。—— Eric Liu_（留言） 2025年4月27日 (日) 13:51 (UTC)

本地的{{!}}可以說是歷史包袱了，當年MediaWiki正式將{{!}}納入魔術字時都沒能改變本地習慣，今天就一個「正名」名義便要犁掃積痾，想來不太實際。

話雖如此，我還是同意應推廣使用{{僻字}}、{{！}}等重定向模板代替{{!}}。真有那麼一天要廢棄{{!}}時，也能少點痛。

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

在页面转换为简体的时候，会出现{{僻字}}模板使一个简体字高亮的情况，非常奇怪。可以增加一个参数让模板在繁简转换后不增加任何标记。 Midleading（留言） 2025年4月28日 (一) 07:44 (UTC)

@Aerotinge：什麼意思？如果祇是在標題間移動，不會有問題吧？—— Eric Liu_（留言） 2025年4月28日 (一) 17:35 (UTC)

確定一下，您要實施的操作是：

「將Template:!移動到Template:僻字，保留重定向。」對嗎？這應當不會有問題。

有問題的是在本地使用{{!}}錄入的作品，在複雜的頁面上，對{{!}}模板的調用可能會被Parsoid誤解析成魔術字{{!}}，然後返回單個pipeline字符。如下所示(上：現行解析器；下：Parsoid)

(Parsoid是WMF將採用的解析器，且已部署到數個維基項目上。本地可由工具選項開啟，或在偏好設定中選用)

要治標，一是上報phab開工單讓他們查bug、改解析器的行為。一是本地徹底棄用{{!}}，將現存的{{!}}模板調用全數改成{{僻字}}模板，主動避讓問題。

我是覺得如果是WMF去改行為，那本地模板正不正名倒無所謂。若是本地主動退讓，這樣一個影響龐大的操作，以「正名」名義發起似不夠充分。

以上望能解釋我之前回覆不足處。最後，如果對{{!}}的問題還有要繼續詢問、討論，還請另開一串討論獨立出，因該問題與本串主題直接關聯性較弱。

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

我个人无所谓，看各位的谈话中似乎此处还有些技术问题，我不太懂，只好辛苦各位思量了。 银色雪莉（留言） 2025年4月28日 (一) 08:32 (UTC)

支持移動到{{僻字}}。如果社群對使用及棄用哪些別名有共識，可在模板説明頁寫明，及使用{{template shortcut}} 模板標記。 Andayunxiao（留言） 2025年4月29日 (二) 15:36 (UTC)

 支持感叹号模板更名为僻字，感叹号意义实在过多，僻字功能占用这个领域实在让人违和感十足。 Liuxinyu970226（留言） 2025年5月6日 (二) 22:50 (UTC)

已導入維基百科樣式及移動本模板至{{僻字}} Midleading（留言） 2025年5月15日 (四) 15:38 (UTC)

2025年第17期技術新聞

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

近況更新 - 面向編輯者

• 自4月15日起，維基函數已與達戈姆巴語維基百科整合。這是第一個能夠從維基函數呼叫函數並在條目中使用的專案。函數能接受一個或多個輸入，並將其轉換成預期的輸出，例如：相加兩數、換算單位、計算時間跨度或轉換大小寫。有了維基函數，使用者只需呼叫一個穩定的全域函數即可達成目的，無需使用本地模板。 [98]
• 新增了一種lint錯誤：空标题（說明文件）。Linter擴充功能旨在找出頁面中需要或可以修正的wikitext語句，並提供指引，說明這些語句的問題以及如何修正。 [99]
• 上週有37件社群提交的工單得到解決。

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

• 繼在HuggingFace上發布之後，由維基媒體企業服務（Wikimedia Enterprise）開發的「Structured Contents」資料集現在也可在Kaggle上取用。這項Beta計畫著重於讓維基媒體資料更易於機器讀取，以供大量重複使用。這次，他們在開放資料集社群已在使用的平台上發布這個測試版，以尋求回饋，幫助改善產品，利於將來的廣泛發布。參閱更多關於整個Structured Contents專案，以及第一個可自由使用的版本。
• 本週沒有MediaWiki版本更新。

會議與活動

• 編輯團隊與機器學習團隊邀請有興趣的志願者參加視訊會議，討論最新的編輯檢查：華辭檢查。華辭檢查可在編輯者鍵入文字時偵測「華而不實」、「過度宣傳」或「非中立」的語句。我們鼓勵經常接觸新手的編輯者、協助修正此類文字的編輯者，或對我們在專案中使用AI的方式感興趣的編輯者參加。會議將於2025年4月28日 18:00-19:00 UTC在Zoom上舉行（查看您的當地時間）。

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

MediaWiki message delivery 2025年4月21日 (一) 21:00 (UTC)

使用AI进行OCR并批量导入

我写了Wikisource:光學字元辨識#OCR提示词和导入方法，可通过此方法进行OCR并批量导入。已经使用Index:CADAL01035836_明季稗史彙編·也是錄明季稗史彙編·江南聞見錄.djvu测试，对于已有页面也导入并手动撤销了，供校对时参考。注意，我只是测试，如果有更好的AI或提示词，可以直接覆盖本人导入的内容。@囍鵲, Liouxiao：。維基小霸王（留言） 2025年4月22日 (二) 05:36 (UTC)

關於AI識字的優劣之處，本人曾經和閣下有過一次討論，目前gemini的效果只能說尚可，跟大陸不少OCR相比甚至都有不小的差距。例如之前閣下非常推崇的識典古籍AI，對識別結果中的每個漢字會進行準確度評價，對於那些識別較差、拿不準的漢字，在結果頁面會被高亮標識，便於錄入者更高效的進行定位更改。

另外gemini有使用額度限制，在免費情況下，對於大批量作業的支持度亦相當有限。

當然閣下運用尖端技術來解決棘手的問題，值得進一步嘗試。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 06:49 (UTC)

对于您创建的也是錄，通过与gemini的结果对比，就可以找出与底本的一些区别。 維基小霸王（留言） 2025年4月22日 (二) 06:56 (UTC)

《也是錄》並非由我所創建，早已有之。原始文本應該是中國哲學書電子化計劃網站上複製出來的，而那個中國哲學書電子化計劃網站的很多內容又是通過簡轉繁產生的，本身就有很多問題。

我只是根據底本分頁切割該文本，並將切割後的結果在校對頁和底本進行關聯。AI識別糾正了原文中的少部分錯誤，但也產生了少部分錯誤。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年4月22日 (二) 07:06 (UTC)

@維基小霸王：是否應該設個模板，統在使用人工智慧輔助錄入的文章添加，以便編者追蹤並手動校對？—— Eric Liu_（留言） 2025年4月22日 (二) 09:06 (UTC)

我觉得没必要，因为这和传统OCR没有本质区别。 維基小霸王（留言） 2025年4月22日 (二) 13:44 (UTC)

傳統光學辨識沒有模板嗎？我覺得對於這些非人工案例，起碼要有些標記吧。—— Eric Liu_（留言） 2025年4月25日 (五) 08:10 (UTC)

有标记，就是25%或者未校对 Midleading（留言） 2025年4月25日 (五) 09:17 (UTC)

Portal 名字空間的本地名

本人之前實驗，有時可以在頁面路徑中以「主題，導覽」替代Portal，但後來不能復現。本地是否已有中文名？

如Portal:联合国大会决议頁面，改爲導覽:聯合國大會決議，导览:联合国大会决议，主題:聯合國大會決議，主题:联合国大会决议，是否為紅鏈？

此外 Portal 頁面的分類亟待建立，需要社群選擇一個合適名稱。 Andayunxiao（留言） 2025年4月22日 (二) 09:02 (UTC)

這方面應該可以比照百科，建立一些命名空間別稱。—— Eric Liu_（留言） 2025年4月22日 (二) 09:21 (UTC)

• Portal:MediaWiki:Conversion-ns100/zh-hant、MediaWiki:Conversion-ns100/zh-hans、MediaWiki:Conversion-ns100/zh
• Portal_talk:MediaWiki:Conversion-ns101/zh-hant、MediaWiki:Conversion-ns101/zh-hans、MediaWiki:Conversion-ns101/zh

皆未建立。會不會是看到百科去了？

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

對Portal有可能。其他幾個名字空間怎麽解釋？

• 模塊:Yesno，模块:Yesno，模組:Yesno，模组:Yesno。（828）
• 樣板:PD-old，模板:PD-old。（10）
• 幫助:入门指南。（12）

Andayunxiao（留言） 2025年4月24日 (四) 16:48 (UTC)

那可能是以上幾個NS在本地有設定映射mw:Manual:$wgNamespaceAliases，但檢視該設定內容須具權限。所以我不能確定。

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

现有别名在 https://noc.wikimedia.org/wiki.php?wiki=zhwikisource#wgNamespaceAliases 可见。 dringsim 2025年4月25日 (五) 11:09 (UTC)

若社群有需要，可以建立phab任務。—— Eric Liu_（留言） 2025年4月25日 (五) 08:09 (UTC)

台灣分會2025年4月對話時間

台灣維基媒體協會2025年4月的對話時間，訂於台灣時間4/29 (二) 19:00舉行，
參與連結為 https://meet.google.com/qiv-ctih-sse 。
想跟更多台灣維基人互動嗎？不知道台灣有個維基協會，或知道協會但不知道他們平常都在幹嘛嗎？
本次對話時間將聚焦於2025 COSCUP議程徵件的討論，這是將是讓你深入了解協會運作並參與交流的絕佳機會！快來一起參加！

--MediaWiki message delivery（留言） 2025年4月26日 (六) 01:16 (UTC)

2025年第18期技術新聞

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

近況更新 - 面向編輯者

• 本週，孟加拉語、日語、韓語維基百科等多個維基的協作活動籌辦人員將可以使用CampaignEvents擴充功能。此外，已啟用CampaignEvents的維基百科中的管理員將不久後自動獲得活動籌辦人員權限，無需再根據社群要求手動授予自身。
• 上週有19件社群提交的工單得到解決。

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

• 維基媒體設計系統——Codex預定於2025年4月29日發布下一個主要版本。技術編輯者將能於2025年5月5日當週使用該版本。本次更新將包含一些不向下相容的重大變更和輕微的視覺變更。該頁面記載了處理重大變更和視覺變更的說明。發布前的測試在T386298中回報，發布後的問題則在T392379和T392390中追蹤。
• Wiki Replicas的使用者將會注意到ipblocks、ipblocks_ipindex和ipblocks_compat這幾個資料庫檢視表現已棄用。使用者可以查詢block和block_target這二個新的檢視表，這些新檢視表會反映生產資料庫中的新表格。棄用的檢視表將於2025年6月從Wiki Replicas中完全移除。
• 本週稍晚代码更新細節： MediaWiki

深入了解

• 季刊語言與國際化電子報新期數發布。 本期內容包括：內容翻譯面板工具的改進概要；新增支援語言；「維基愛齋月」活動的亮點；新語言啟動實驗的結果；條目主題多樣性的分析；以及即將舉行的社群會議和活動的資訊。

會議與活動

• Let's Connect學習診所將於4月29日 14:30 UTC舉行。本期主題是「維基媒體專案中的衝突理解與應對」。現在可以報名參加。
• 2025年5月2日至4日，2025年維基媒體黑客松將在土耳其伊斯坦堡舉行，屆時全球技術社群將齊聚一堂，相互交流、集思廣益，並對既有專案進行駭客活動。

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

MediaWiki message delivery 2025年4月28日 (一) 19:31 (UTC)

對《通用行為準則執行規範及其協調委員會章程》的修訂投票

《通用行為準則執行規範及其協調委員會章程》修订案的投票期将于世界协调时 (UTC) 2025年5月1日23:59结束（在您的时区查找对应时间）。请在 Meta-wiki 上的UCoC页面投票前，阅读关于如何参与的说明并仔细审阅提案。

通用行為準則執行規範協調委員會(U4C)是一個全域性的組織，致力於公平、一致地實施UCoC。本年度審查由U4C規劃和實施。如需更多資訊和 U4C 的責任，您可以檢閱U4C的章程。

請酌情以您的語言與您的社群成員分享此訊息，以便他們也能參與。

與U4C共同合作 --

Keegan (WMF) (talk) 2025年4月29日 (二) 03:41 (UTC)

朝代標註

雖然Header模板現在可以設定分類重新導向，但還是想問一下錄入時有無必要統一朝代標註（如統用「秦朝」而不用「秦代」之類）？這涉及本站不少文章體例，故提出討論。—— Eric Liu_（留言） 2025年5月2日 (五) 07:33 (UTC)

除此之外，地名（如「2017年香港」此種分類）或許也值得討論。—— Eric Liu_（留言） 2025年5月2日 (五) 07:50 (UTC)

此例「秦代」，模板似乎沒有使用分類重定向，而是經過轉換文字，直接添加了Category:秦朝。轉換表在Module:Header内。如不在此表内，則編者選擇可能不同。閣下是希望規範使用者錄入的朝代名？ Andayunxiao（留言） 2025年5月3日 (六) 06:34 (UTC)

對。當然我知道這可能有爭議，所以先在此請社群多討論下。—— Eric Liu_（留言） 2025年5月8日 (四) 15:25 (UTC)

建議對有刪除性質的數個維護模板添加NOINDEX魔術字，阻止頁面問題解決前被快取到外部

想建議對{{sdelete}}、{{afd}}、{{Copyvio}}模板的<include>段內添加__NOINDEX__魔術字。使具爭議內容不被網路爬蟲快取。

雖說掛前兩者模板的頁面在本站的活躍巡查下，排查時間通常也不長。於此兩模板添加__NOINDEX__僅是起到一個後援作用。 而{{Copyvio}}雖已隱蔽內文，使爬蟲無法快取內文，但還是建議添加，能起到整頁完全避免的作用。

愚一時之見，如有未盡周詳之處，如違反原則、濫用魔術字等可能，也請提出指教。 ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年5月3日 (六) 03:18 (UTC)

根据mw:Manual:$wgExemptFromUserRobotsControl/zh，__NOINDEX__對主命名空間的頁面無效，所以在這些模板中添加__NOINDEX__是無效的 Midleading（留言） 2025年5月3日 (六) 04:32 (UTC)

了解，相當合理呢。多謝說明。ᡥᠣᡵᠣᠩᡤᠣ ᠶᠠᠩᠰᠠᠩᡤᠠ ᡩᡝᠶᡝᠨ ᡳ ᠪᡳᡨᡥᡝ ᠸᡝᡳᠯᡝᡵᡝ ᠪᠠ ᠠᡳᠰᡳᠯᠠᡵᠠ ᠪᡳᡨᡥᡝᠰᡳ ᡝᡵᡤᡝᠨ（ᠯᡝᠣᠯᡝᠪᡠᠮᠪᡳ） 2025年5月3日 (六) 06:25 (UTC)

要不跟Phabricator说一下，请求允许部分主空间页面NOINDEX有效？然后另行规定方针指引规定什么情况下可以在主空间插入NOINDEX？ Liuxinyu970226（留言） 2025年5月6日 (二) 22:48 (UTC)

申请对未来会被删除的主空间页面NOINDEX有效不就是刻舟求剑吗，跟Phabricator申请没有用，得跟如来佛申请 Midleading（留言） 2025年5月7日 (三) 01:13 (UTC)

@Midleading https://archive.is/ 了解一下，那玩意有概率主抓程序漏洞强行存档已删除网页。 Liuxinyu970226（留言） 2025年5月13日 (二) 16:54 (UTC)

外部网站复制含有copyvio的页面是外部网站的法律责任，和维基文库无关。而且一旦页面添加NOINDEX并且被爬虫获知，以后就算页面决定保留了，爬虫也不会再过来索引了。所以NOINDEX真的只适合于中国大陆式的“永久封禁、彻底凉凉”的东西，包括{{blocked user}}和{{locked global account}}。 Midleading（留言） 2025年5月14日 (三) 08:19 (UTC)

2025年第19期技術新聞

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

本週要聞

• 維基媒體基金會分享了明年度（2025年7月—2026年6月）年度計畫的最新更新草案，其中包括執行摘要（也發布在Diff）、三大目標（基礎設施、志願者支援、有效性）的詳細資訊、全球趨勢以及預算與財務模式。歡迎在五月底前，在討論頁提供反饋意見和提出疑問。

近況更新 - 面向編輯者

• 已啟用CampaignEvents的維基，該擴充功能發布了兩項新的功能改進：
  • 管理員現在可以透過社群配置（說明文件）選擇哪些命名空間允許活動報名。預設配置允許在「Event」命名空間中進行活動報名，但現在可以新增其他命名空間（例如專案或「維基專題」命名空間）。有了這項變更，維基專題等社群現在可以更輕鬆地使用活動報名功能來舉辦協作活動。
  • 編輯者現在可以在維基頁面中嵌入協作清單（說明文件）。協作清單自動列出維基上的活動和維基專題，可透過Special:AllEvents查看（範例）。現在，協作清單可以被加進各種維基頁面中，例如：維基首頁、維基專題頁面、自治體頁面、活動頁面，甚至是使用者頁面。
• 上週有27件社群提交的工單得到解決。

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

• 小工具和使用者腳本的開發者，應將其使用moment函式庫的程式碼改為使用其他函式庫，例如Intl或新的mediawiki.DateFormatter函式庫。moment函式庫現已棄用，並將開始在瀏覽器的開發人員主控台中記錄警告訊息。需修改的程式碼頁面，請在Phab工單中提供的全域搜尋結果查看，如有疑問也可在工單中提出。
• 維護用於查詢維基數據詞彙（term）儲存表（wbt_*）的工具的開發者需要更新其程式碼，以連接到單獨的資料庫叢集。這些表格將被分割到一個獨立的資料庫叢集中。透過Wiki Replicas來查詢這些表格的工具，必須改為連接到新的資料庫叢集。參閱說明文件和相關連結。 [100]
• 本週軟體更新細節： MediaWiki

深入了解

• Chart專案電子報新期數發布。 本期包括以下新訊：最快在本週（5月6日開始），Chart將進一步部署至更多wiki，並在接下來的幾週內擴大部署規模，此外Chart將探索篩選和轉換來源資料。

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

MediaWiki message delivery 2025年5月6日 (二) 00:14 (UTC)

We will be enabling the new Charts extension on your wiki soon!

(Apologies for posting in English)

Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.

As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.

After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.

The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.

If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.

Thank you in advance! -- User:Sannita (WMF) (talk) 2025年5月6日 (二) 15:07 (UTC)

提議首頁展示最近完成的作品

對比百科和英文文庫的首頁設計，提議在首頁展示文庫最近錄入完成的且質量較好的作品。 其目標，大約相當於百科首頁的新條目，與英文文庫首頁的 New Texts（新作品) 。本地活躍編者數尚不足支持協作核對，最多只好要求整個作品已由一個編者校對，即已校對（或 75%）。與英文文庫首頁標準相同。對長作品也可考慮只要求内容已經完成，沒有維護模板，且編者已確信内容足夠準確，不需近期持續編輯，即可符合標準。

提議的目的是給錄入作品的編者中期目標和獎勵。首頁現有編輯動態已反映近期編輯熱門，惟短作品如一次完成則無登榜可能。以此提議，新錄入的已校對的短作品可獲關注。對長作品，編輯最多的時段常常仍未完成，完成時反容易跌出榜單。如以完成狀態呈示，可避免讀者提早看到「施工現場」，也和百科評選要求條目已寫好的做法一致。

相關提議是建立en:Wikisource:Works/2025對應的頁面並從首頁連入，記錄本年内新校對的作品。無論作品頁還是校對頁錄入，維基文庫都只有單個頁面的狀態及其分類（Category:文本完善度，Category:页面校对状态），沒有對多子頁的整部作品的狀態標記（索引頁記錄全局狀態但不等於作品）。此項標準簡單，可能由脚本或機器人自動完成。 Andayunxiao（留言） 2025年5月8日 (四) 17:19 (UTC)

現時文庫活跃程度尚不足以全面實行作品完成度的評審，仍有很多作品完成編輯時未添加任何來源或品質模板，所以目前只能以全自動方式快速更新首頁以避免過多增加社群和管理員負擔，更新方式见此使用者腳本。如有更好方式自動更新首頁，還請賜教。 Midleading（留言） 2025年5月9日 (五) 03:36 (UTC)

感謝閣下一直維護首頁的最近編輯動態。此提議希望在首頁另處顯示新錄入作品，不涉及更改或重組其他首頁内容。

如果社群對首頁此欄展示的標準有共識，則可全憑社群自覺，無需評審，更無需對作品内容有審查或要求。

作爲參考，英文文庫的實現辦法是編者自行提交。使用模板en:Template:new texts, 編者將要發佈的作品加到此模板頁的頂端，同時將第一組的末位移到第二組。第一組，即最新發佈作品嵌入到首頁。每月由編者手動存檔到子頁（如en:Template:New_texts/2025/04）。見其編輯歷史 (外部頁面）。模板為半保護，即限自動確認用戶提交。以英文文庫月均約200人的活躍編者數，每月新作品尚不足百，本地符合條件的可能不到20/月，社群完全可以承擔。

另外，本人覺得英文文庫方案的更迭也過頻繁，對於文庫這樣的「慢維基計劃」，大可每兩三個月更新一次，讓榜單停留時間稍久些，並在數量超過首頁容量（5-10位為適）時用模板自動輪換顯示，如此則至多榜單更新不及時，無需管理員有任何必需操作。

至於自動更新方案，對校對頁可篩選帶「已校對」及「已核對」標簽的最近編輯，如站内搜索：[101]，然後獲得對應作品名，再篩選確實完成者。對作品頁則需追蹤最近編輯頁中有分類:75%及分類:100%的頁面。如上所述，因數量不多，實可編者手動提交。 Andayunxiao（留言） 2025年5月9日 (五) 08:13 (UTC)

本人曾在前年寫字間發過thread幾點想法，其中系統性談到過本站頁面的前端設計問題。但因為本站缺乏頁面管理員。故而不了了之。

本站的主頁至少接近20年沒有大規模調整過。整個設計問題堆積如山。即便是當年的頁面管理員也沒用心好好針對文庫類網站進行設計。而此人之後完全失聯。已經十幾年。

至少應該針對編輯者和閱讀者兩種身份，分別設計頁面，予以不同展示。 #Kill the zombies in zh.wikisource.org, it's very important.（留言） 2025年5月9日 (五) 04:56 (UTC)

好像確實可以有一個地方展示已校新文。—— Eric Liu_（留言） 2025年5月9日 (五) 18:03 (UTC)

中国大陆政府采购的招标公告、竞争性谈判公告等是否属于公有领域

例如 [102]，页面下方的描述为“本页面提供的内容是按照政府采购有关法律法规要求由采购人或采购代理机构发布的，重庆市政府采购网对其内容概不负责，亦不承担任何法律责任。” 内存溢出的猫（留言） 2025年5月10日 (六) 00:47 (UTC)

商事行为很难认为符合“立法、行政、司法”的范畴。 --达师 - 370 - 608 2025年5月10日 (六) 11:26 (UTC)

同达师，民商事行为不属于“立法、行政、司法”。不过有可能会属于“单纯事实消息”，这需要个别判断。 ——— 红渡厨（留言・贡献） 2025年5月10日 (六) 12:12 (UTC)

2025年第20期技術新聞

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

本週要聞

• 側邊欄的「获取短链接」連結（功能說明）現在會同時顯示QR碼，供使用者掃描或下載。維基媒體網站使用者現在多了一個便利的方式來快速分享維基媒體網站和存取分享內容。

近況更新 - 面向編輯者

• 維基媒體基金會正在開發名為Edge Uniques的系統，該系統可用於實現A/B測試，幫助抵禦DDoS攻擊，並讓我們更容易了解維基媒體網站的訪客數量。有了Edge Uniques，基金會可以更有效率地打造能幫助讀者的工具，讓讀者更容易找到他們要找的東西。技術新聞先前曾撰文介紹過該系統。該系統將逐步進行部署。有些人可能會在5月19日當週見到Edge Uniques的Cookie。相關討論在此討論頁進行。
• 2025年5月19日開始，已啟用CampaignEvents擴充功能的維基中的活動籌辦人員可以在專案命名空間（例如「Wikipedia:」、「Wikidata:」等）中使用活動報名功能。有了這項變更，社群不需要管理員也能進行活動報名。不想要這項變更的維基可以在Special:CommunityConfiguration/CampaignEvents中移除／新增允許使用的命名空間。
• 已新建努佩語维基百科（w:nup:）。這是一種主要在奈及利亞中北部地區使用的語言。邀請使用該語言的人士來為新的維基百科做出貢獻。
• 上週有27件社群提交的工單得到解決。

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

• 開發者現在可以透過結構化內容快照（Beta）存取7個維基百科（英語、德語、法語、西班牙語、葡萄牙語、義大利語、荷蘭語）的預解析內容。這些內容包括已解析的維基百科摘要、描述、主要圖片、資訊框、條目章節和參考資料。
• REST API的/page/data-parsoid端點已不再使用，並將被棄用。預定2025年6月7日關閉。
• 本週軟體更新細節： MediaWiki

深入了解

• 雲端服務現已支援IPv6，這將大幅提升維基媒體平台的可擴縮性與安全性，為未來做好準備。欲知詳情的技術貢獻者可參閱這篇博文，深入了解我們邁向IPv6的歷程。

會議與活動

• Afrika Baraza是非洲維基人交流聯繫的線上平台，2025年第二屆Afrika Baraza將於5月15日 17:00 UTC舉行。本屆將集中討論維基媒體年度計畫與進展。
• MENA Connect社群通話會議是MENA（中東北非）維基人交流聯繫的線上會議，將於5月17日 17:00 UTC舉行。現在可報名參加。

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

MediaWiki message delivery 2025年5月12日 (一) 22:37 (UTC)

暂时告辞了各位

这么多年来，我一直都是为维基文库做贡献的。但是我暂时要去忙于我的生活了，而且我又有其他的私人项目了，实在是腾不出来时间继续大规模地编辑了。我还是会关注维基文库的，甚至可能有时会做出一小点贡献，但是我就暂时先告辞了。我祝你们平安、幸福、健康、快乐。

我的私人页面上有很多还未录入的文件和资料，并且我加入了这些文献的原文链接。你们搜查（未录入）就可以找到了。除此之外，我还有（未填写）这个页面，专门记录有磨破的文字的文献，或许有朝一日我们可以得到另外的版本填补这些磨破的字。

除此之外我还有大量的朝鲜文献链接，你们可以通过这些链接得到原文。

谢谢各位的关照。或许我还能够再回来！🙏 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年5月15日 (四) 16:59 (UTC)

这消息使人有些感慨，感谢您为文库做的贡献，祝您在现实生活中一切如意，幸福快乐。我会怀念与阁下互动协作的时光，也欢迎您常回来看看。 银色雪莉（留言） 2025年5月15日 (四) 17:22 (UTC)

感謝！我有時間回來看看。 大東國奎章閣大提學兼弘文館大提學藝文館大提學知成均館事Blahhmosh（留言） 2025年5月15日 (四) 19:02 (UTC)

祝顺利！—— Zzhtju（留言） 2025年5月16日 (五) 13:36 (UTC)

感谢您长期以来对维基文库的贡献，祝您生活顺利。 ——— 红渡厨（留言・贡献） 2025年5月16日 (五) 14:12 (UTC)

辛苦了！我想閣下可說是近年對本站貢獻最大者，若無其他。—— Eric Liu_（留言） 2025年5月17日 (六) 13:18 (UTC)

徵求《通用行為準則》協調委員會（U4C）候選人

《通用行為準則》執行指南和《通用行為準則》協調委員會(U4C)憲章的投票結果可在Meta-wiki上獲得。

您現在可以提交您在U4C服務的候選人資格，截至2025年5月29日12:00 UTC止。有關資格、程序、和時間表的資訊請參閱 Meta-wiki。候選人投票將於2025年6月1日開始，為期兩週，於2025年6月15日12:00 UTC結束。

如果您有任何問題，可以在選舉討論頁面上提出。-- 感謝您與U4C合作

Keegan (WMF) (留言) 2025年5月15日 (四) 22:08 (UTC)