Wikipedia:互助客栈/技术
）。
 |
發表前請先搜索存档，參考舊討論中的内容可節省您的時間。 |
| |||||||||||||||||||||||||||||||||||||
公告欄
- [討論]
用戶「折毛」主編條目偽造問題正進行集中討論，歡迎踴躍參與。 - [人事] 請踴躍參與此後管理員申請投票制度之修訂事宜。
- [公告] 用于讨论管理员事务的邮箱列表wikipedia-zh-admin
lists.wikimedia.org已被建立，欢迎各位管理员加入。 - [公告] 改善虚构格式手册并恢復其指引地位及調整優特內容評選規則已經通過。
- [公告] 臺灣行政區條目人口段落共識正在公示，如有意見請儘快提出。
- [討論] 互助客栈方针區正在討論修改巡查豁免权的简介及申请条件、修改防滥用过滤器可见性及新聞動態發表程序問題，敬請踴躍參與。
- [討論] 互助客栈技术區正在討論加入半自动提报内容评选工具及部署HanAssist小工具，敬請踴躍參與。
- [討論] 互助客栈条目探讨區正在討論“中国航空集团”條目合併争议及「校友列表」是否該用分類代替，敬請踴躍參與。
- [討論] 互助客栈其他區正在討論妥善利用巡查標記的方式及首頁「你知道嗎？」板塊的問題，敬請踴躍參與。
- [討論] 運動策略論壇正在討論通用行為準則執行規範如何才能對中文社群有最大效益，敬請踴躍參與。
- [廣告] 第二十次動員令主題投票暫定於6月26日（日）展開，歡迎踴躍參與！
- [投票] 提议增设“建筑特别贡献”的投票正在进行中，歡迎踴躍參與！
lists.wikimedia.org已被建立， 存檔 |
|---|
|
2005年 12 月 |
| 發言更新圖例 |
|---|
|
|
|
|
|
| 特殊狀態 |
| 已移動至其他頁面 或完成討論之議題 |
| 手動設定 |
| 當列表出現異常時， 請先檢查設定是否有誤 |
偽綠鏈二三事
- 追蹤偽綠鏈並將這類條目歸入Category:有蓝链却未移除内部链接助手模板的页面的程式碼有待完善。照分類紀錄Special:Diff/71332757這次編輯就已經把該模板從分類中移除，但逐筆比對後可發現仍有「{{link-en|索马里兰银行|Bank of Somaliland}}」（實際連結到索馬利蘭銀行，條目建立於2022年3月28日）、「{{link-en|斯里兰卡中央银行|Central Bank of Sri Lanka}}」（實際連結到斯里蘭卡中央銀行，條目建立於2022年4月9日）。由此可知追蹤程式碼可能無法處理繁簡、地區詞等問題，希望可以修復，也提醒User:Comrade John清理時留意。
- 目前User:Cewbot僅清理Category:有蓝链却未移除内部链接助手模板的页面中的條目命名空間、模板、Category 或 Wikipedia，但有部分偽綠鏈存在於Portal空間如Portal:東南亞]、User talk空間如User talk:221.9.13.45/存檔、WT空間如Wikipedia talk:並不是所有頁面都需要標籤難以人力處理窮盡，希望可建立「讓Cewbot請理所有空間」的共識，謝謝，也副知User:Kanashimi。--迴廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)
- 又希望建立共識加快Cewbot的清理速度。Category:有蓝链却未移除内部链接助手模板的页面近期的數字大致上在15500-14800之間浮動，但User:Cewbot/需要修正的跨語言連結近期的數字是14000以下，Cewbot每週了不起完全清理100多條，差距其實挺大。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)
- 我只在乎Category:有蓝链却未移除内部链接助手模板的页面消失與否。閣下所指的問題，我已知悉一段時間，但這並非我能夠獨自處理，而且逐筆比對費時失事，所以我對偽綠鏈，找到的就改，找不到的就算。
- 其實Cewbot要提升它的編輯頻率，很懷念上年Category:有蓝链却未移除内部链接助手模板的页面短短幾天，由30000多個頁面，清至10000多個頁面呢。-- 約翰同志－條目裱糊匠（留言） 2022年4月27日 (三) 12:07 (UTC)
- 其實能處理的大概都處理完了。您可以參照使用者:Cewbot/需要修正的跨語言連結，現在留下來的大概都是需要人工判別的。--Kanashimi（留言） 2022年4月27日 (三) 21:19 (UTC)
- 謝謝User:Comrade John、User:Kanashimi兩位辛苦，我會提出上述方案就是希望Cewbot清理簡單、但沒人注意到的偽綠鏈，讓有志者可以專心處理使用者:Cewbot/需要修正的跨語言連結，裡面問題真的太多。我目前找到的清法是把該頁面紀錄的原文人名、媒體名等專有名詞做重定向，像是Los Angeles Daily News、亚马逊MP3這類的讓機器人去跑，前陣子認真做的時候算蠻有成效，每週可以清一百多個。不過另一方面真的建議Cewbot加快速度，像凌晨一點到六點這種伺服器理應比較空閒的時段（如果我講錯請指正我），也常看到Cewbot除更新討論列表外只清了五、六筆偽綠鏈。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)
- 歸納一下討論狀況，目前我跟User:Comrade John都認為Cewbot應加快清理速度，請問一下Comrade John那邊有建議速率嗎？此外我昨天修了一筆將近兩年都沒被Cewbot修復的偽綠鏈（井上和香這個條目建立於2019年5月），這個效率真的是有點不妙。--迴廊彼端（留言） 2022年5月9日 (一) 17:40 (UTC)
- 速率吧.....它的速率其實沒有問題，而是頻率的問題，Cewbot每星期才清理偽藍鏈一次，可以說那一次所清理的數量，遠遠不及一星期所增加的偽藍鏈數量，最好是每日一次。確實，維基百科:不要搶機械人的工作，但前提是它們完全能夠獨自清理某些工作吧。-- 約翰同志－條目裱糊匠（留言） 2022年5月9日 (一) 18:26 (UTC)
- 我觀察了好一段時間，目前Cewbot幾乎每天都會清，只是清的份量多少而已，所以我傾向認為是速率問題。--迴廊彼端（留言） 2022年5月19日 (四) 16:28 (UTC)
- 速度的問題，主要是因為每一筆連結都要查詢各項資料以做確認，並且真正能改的不多。所以雖然一直在跑，卻大多改不了。依照當初的討論，能改的連結有限制，例如新文章必須過一禮拜才能當作穩定，您可參考原始碼。或許您可以提供一些應該能讓機器人自動更改，不必列在問題頁面的例子？--Kanashimi（留言） 2022年5月19日 (四) 22:38 (UTC
- 關於使用者:Cewbot/需要修正的跨語言連結目前我沒想法，謝謝辛苦。速度部分也謝謝您的解說，不過有些偽綠鏈毫無問題也被擱置了半年，您之前清完快取再運行機器人後我仍找到擱置兩年的偽綠鏈Special:Diff/55339541/71554938，這難免讓我好奇有沒有提升清理效能的方法，例如提升機器人整體運行速度、避免機器人總是在特定條目打轉之類的。--迴廊彼端（留言） 2022年6月4日 (六) 13:33 (UTC)
- @迴廊彼端 您在發現有些模板能改卻一直放著沒改時，或許能告知這邊一下，以利逐筆檢查。謝謝。--Kanashimi（留言） 2022年6月18日 (六) 21:31 (UTC)
- 速度的問題，主要是因為每一筆連結都要查詢各項資料以做確認，並且真正能改的不多。所以雖然一直在跑，卻大多改不了。依照當初的討論，能改的連結有限制，例如新文章必須過一禮拜才能當作穩定，您可參考原始碼。或許您可以提供一些應該能讓機器人自動更改，不必列在問題頁面的例子？--Kanashimi（留言） 2022年5月19日 (四) 22:38 (UTC
- 我觀察了好一段時間，目前Cewbot幾乎每天都會清，只是清的份量多少而已，所以我傾向認為是速率問題。--迴廊彼端（留言） 2022年5月19日 (四) 16:28 (UTC)
本章節暫時不存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。
模板:Infobox ship begin等子模板合併事宜
英維社群目前正在討論模板:Infobox ship begin等子模板合併為一個模板事宜，詳情請看此。
如英維社群決定合併，一定會影響有引進此模板的中維，如果我們不跟着它們合併，長遠會影響中維翻譯英維船舶條目的工作（需要轉換原始碼，費時失事）。
我想問：有沒有熟悉模板編輯（主要是熟悉模板合併）的用戶處理此等事宜 ? 有沒有能夠進行成千上萬的船舶條目的原始碼轉換的機器人 ?--約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:22 (UTC)
副知@Cwek、Vozhuo：可能需要進行模板合併的準備。-- 約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:45 (UTC)
- 首先Template:Infobox_ship是跟随en的更新？其次可以以并行切换的方式，逐步淘汰基于模块思路的Infobox ship XX模板组（告知不要使用，和转换方法），如同{{BS}}RDT系列逐步从模板型转为Lua型。思路可以跟随en，但做法可以有所调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月1日 (日) 01:32 (UTC)
- Infobox ship在英維現時是重定向至Infobox ship begin，想不到在中維還在。令人擔心引進英維模板框架的中維與英維的滯後。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 07:32 (UTC)
- 是英语太快，Infobox ship目前有35个外语版呢，Infobox ship begin有48个。是否等英语那边稳定和出现实际问题再研究。Infobox ship begin有1178个链入，似乎没有那么严重。相较而言，PRC admin系列的可维护性更值得中维关注，比如数据难以修订；比如暨南街道坏了，目前坏了53条。--YFdyh000（留言） 2022年5月1日 (日) 08:14 (UTC)
- 是否等英語那邊穩定和出現實際問題再研究，我也是這樣認為的。我出帖的目的，是提醒社群，英維社群對該模板可能有大動作，以免別人合併了，我們還慒然不知，影響中維翻譯英維船舶條目的工作。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 08:33 (UTC)
- 我觉得首先应该先把{{軍艦模板}}（1287引用）、{{軍艦艦型模板}}（111引用）、{{潜艇}}（121引用）、{{艦型模板}}（18引用）这四个以中文参数为主的模板合并成一个覆盖范围更广的模板，比如{{船舶信息框}}。然后再以这个新合并的模板为基础，去扩展兼容英文的参数（从英维提议合并的作者的想法来看，中维上面这几个模板在结构上会和英维合并后的单一模板相似，就有了扩展的可能）。中文维基一直以来就有中英文两套船舶模板，正好趁这个机会先把自己的问题解决了，要不然等英维模板变成新的，中维再引进，就变成三套了，以后就越来越乱了。其实{{軍艦模板}}是有英文参数的，它的英文参数应该是原来英维的{{Infobox_ship}}，你把中维引用Infobox_ship条目的模板名字换成"軍艦模板"显示出来的参数也少不了几个，这是一个很好的合并起点。--Vozhuowhisper 2022年5月1日 (日) 14:00 (UTC)
- @Vozhuo：雖然沒有解決中維的問題，但直接跟隨英維的做法，不是更容易嗎 ? 進行翻譯英維船舶條目的工作的用戶，哪有心機去將Template:Infobox ship轉換成自家的船舶模板。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 15:43 (UTC)
- 我说的都是进行模板合并的工作，和写条目的用户没有关系的。事实上我刚才就已经做了一个初步的版本{{Template:軍艦模板/sandbox}}，把上面我说的四个模板合并了起来（样例：Template:軍艦模板/testcases），比我想象中要简单的多。到时候把英文合并后的模板和这个模板做个整合，也未必是件困难的事情。--Vozhuowhisper 2022年5月1日 (日) 16:37 (UTC)
- @Vozhuo：模板:Infobox service record能兼容嗎 ? 有些潛艇條目帶有這個模板。字體能和Infobox ship begin等子模板一樣大小嗎 ? 最後，Infobox ship begin等子模板有不同國家服役和多次服役退役的功能，能放上去嗎 ? 謝謝。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 18:41 (UTC)
- 这得等到英文那边整合好了再说。--Vozhuowhisper 2022年5月2日 (一) 05:02 (UTC)
- 同意。-- 約翰同志－條目裱糊匠（留言） 2022年5月2日 (一) 07:33 (UTC)
- 这得等到英文那边整合好了再说。--Vozhuowhisper 2022年5月2日 (一) 05:02 (UTC)
- @Vozhuo：模板:Infobox service record能兼容嗎 ? 有些潛艇條目帶有這個模板。字體能和Infobox ship begin等子模板一樣大小嗎 ? 最後，Infobox ship begin等子模板有不同國家服役和多次服役退役的功能，能放上去嗎 ? 謝謝。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 18:41 (UTC)
- 我说的都是进行模板合并的工作，和写条目的用户没有关系的。事实上我刚才就已经做了一个初步的版本{{Template:軍艦模板/sandbox}}，把上面我说的四个模板合并了起来（样例：Template:軍艦模板/testcases），比我想象中要简单的多。到时候把英文合并后的模板和这个模板做个整合，也未必是件困难的事情。--Vozhuowhisper 2022年5月1日 (日) 16:37 (UTC)
- 目標應該是全部整合進Infobox ship，相容中文與英文參數。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月2日 (一) 01:02 (UTC)
- @Vozhuo：雖然沒有解決中維的問題，但直接跟隨英維的做法，不是更容易嗎 ? 進行翻譯英維船舶條目的工作的用戶，哪有心機去將Template:Infobox ship轉換成自家的船舶模板。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 15:43 (UTC)
- 我觉得首先应该先把{{軍艦模板}}（1287引用）、{{軍艦艦型模板}}（111引用）、{{潜艇}}（121引用）、{{艦型模板}}（18引用）这四个以中文参数为主的模板合并成一个覆盖范围更广的模板，比如{{船舶信息框}}。然后再以这个新合并的模板为基础，去扩展兼容英文的参数（从英维提议合并的作者的想法来看，中维上面这几个模板在结构上会和英维合并后的单一模板相似，就有了扩展的可能）。中文维基一直以来就有中英文两套船舶模板，正好趁这个机会先把自己的问题解决了，要不然等英维模板变成新的，中维再引进，就变成三套了，以后就越来越乱了。其实{{軍艦模板}}是有英文参数的，它的英文参数应该是原来英维的{{Infobox_ship}}，你把中维引用Infobox_ship条目的模板名字换成"軍艦模板"显示出来的参数也少不了几个，这是一个很好的合并起点。--Vozhuowhisper 2022年5月1日 (日) 14:00 (UTC)
- 是否等英語那邊穩定和出現實際問題再研究，我也是這樣認為的。我出帖的目的，是提醒社群，英維社群對該模板可能有大動作，以免別人合併了，我們還慒然不知，影響中維翻譯英維船舶條目的工作。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 08:33 (UTC)
- 是英语太快，Infobox ship目前有35个外语版呢，Infobox ship begin有48个。是否等英语那边稳定和出现实际问题再研究。Infobox ship begin有1178个链入，似乎没有那么严重。相较而言，PRC admin系列的可维护性更值得中维关注，比如数据难以修订；比如暨南街道坏了，目前坏了53条。--YFdyh000（留言） 2022年5月1日 (日) 08:14 (UTC)
- Infobox ship在英維現時是重定向至Infobox ship begin，想不到在中維還在。令人擔心引進英維模板框架的中維與英維的滯後。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 07:32 (UTC)
英維社群已同意將模板:Infobox ship begin等子模板合併為一個模板，現正整合中。-- 約翰同志－條目裱糊匠（留言） 2022年5月11日 (三) 09:27 (UTC)
本章節暫時不存檔，直到英文維基百科完成子模板合併，中文維基百科更新完成為止。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。
Google 错误地索引 .m 链接
目前只在搜索中文维基百科遇到过这种情况。比如搜索“机甲小宝 Wikipedia”，第一条是 https://zh.m.wikipedia.org/zh-hans/%E9%93%81%E7%94%B2%E5%B0%8F%E5%AE%9D
--Fireattack（留言） 2022年5月1日 (日) 12:43 (UTC)
現在google似乎將行動版wiki設為預設，使敝人必須每次手動切換成電腦版。不知其他維基人如何解決這問題？--es91213（留言） 2022年5月7日 (六) 05:43 (UTC)
- 奇怪，“机甲小宝+Wikipedia”我反而搜到wiki没语言缀的为第一条。不过偶然会搜到zh-tw语言缀的，可能与Google个人搜索算法有关。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月7日 (六) 07:38 (UTC)
- 希望Google編制搜尋索引時能只收集一種網址版本（無論是內容變體還是行動版／電腦版等等），避免混亂。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月7日 (六) 10:23 (UTC)
- 对于手机📱版网页可以让浏览器强制重定向，在用的工具Redirector，感觉可以移植到维基里。--Kethyga（留言） 2022年5月8日 (日) 09:12 (UTC)
这个问题在我这边已经改善，很少再遇到.m链接了。各位那边怎么样？--Fireattack（留言） 2022年5月29日 (日) 11:43 (UTC)
本章節暫時不存檔，直到問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。
特定页面的目录简繁转换异常
Wikipedia:編輯禁制方針页面，有Template:NoteTA/MediaWiki转换组。-{H|紀錄=>zh-cn:记录}-正常转换了正文内容，但简体中文下目录区仍显示“纪录”。预览结果中正常。刷新缓存不见效果。--YFdyh000（留言） 2022年5月8日 (日) 22:51 (UTC)
- 好像没有发现“纪录”。内容和界面的设置都是中国大陆简中。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月8日 (日) 23:45 (UTC)
- “5.3 纪录”没有吗。--YFdyh000（留言） 2022年5月9日 (一) 01:05 (UTC)
- 好像之前见过目录部分的繁简转换有问题，已经报过P区了。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:09 (UTC)
- Wikipedia:互助客栈/技术/存档/2022年3月，搜“目录问题”。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:11 (UTC)
赞！看来是新的已知bug，phab:T303855。--YFdyh000（留言） 2022年5月9日 (一) 03:40 (UTC)
- 因为我用脚本把原生目录直接隐藏掉了。
囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:12 (UTC)
- “5.3 纪录”没有吗。--YFdyh000（留言） 2022年5月9日 (一) 01:05 (UTC)
本章節暫時不存檔，直到問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。
模板 cite book 显示风格
1、模板{{cite book}}在使用时，如果同时存在作者和编辑时，编辑后面加的是 “ , 编”，而不是“(编)”。
举例 {{cite book|title=鲁迅全集|author=鲁迅|editor=鲁迅全集编委会}}，结果显示为 ：
- 鲁迅. 鲁迅全集编委会 , 编. 鲁迅全集.
如果只有编辑的话， {{cite book|title=鲁迅全集|editor=鲁迅全集编委会}}，结果显示为：
- 鲁迅全集编委会 (编). 鲁迅全集.
如果添加了章节（chapter）字段，{{cite book|title=某某全书|author=鲁迅|chapter=朝花夕拾|editor=某某全书编委会}}，结果显示为：
- 鲁迅. 朝花夕拾. 某某全书编委会 (编). 某某全书.
2、译者 （translator）字段
如果添加了译者 （translator）字段，{{cite book|title=某某图书|author=张某某|translator=鲁迅}}，结果显示为：
- 张某某. 某某图书. 由鲁迅翻译.
感觉改成 “张某某. 鲁迅 (译). 某某图书. ”，风格比较统一。
--Kethyga（留言） 2022年6月2日 (四) 12:43 (UTC)
- 說起來，既然這括號裡面總是中文而不像其他部分可能有外文，那或許應該改用全形，比方說「（編）」、「（譯）」等。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年6月3日 (五) 06:22 (UTC)
- (＋)支持：由于 CS1 模板以半形分号分隔人名，故使用 translator1、translator2、translator3 填写多个译者时，会生成：
- Nelson, J.S. 世界魚類. 由李思忠; 陳星玉; 陳小平翻译. 基隆: 水產出版社. 1994. ISBN 957-8596-03-0. OCLC 62611228. NLC 001533179.
- 这里的“由李思忠; 陈星玉; 陈小平翻译”看上去十分别扭，因此确实有必要修改译者字段的显示风格。不过根据《GB/T 7714》，译者属于“其他责任者”，仍应显示于书名之后，见《GB/T 7714–2005》和《GB/T 7714–2015》中“4.1.2 著录格式”一节的示例2：
- 昂温 G, 昂温 P S. 外国出版史 [M]. 陈生铮, 译. 北京: 中国书籍出版社, 1988.
- 哈里森, 沃尔德伦. 经济数学与金融数学 [M]. 谢远涛, 译. 北京: 中国人民大学出版社, 2012: 235–236.
--蕭漫（留言） 2022年6月3日 (五) 19:31 (UTC)
- “由某某某翻译”，可能是翻译自英维的 translated by，参见上古汉语条目，其中“由某某某翻译”，如果里面是英语的话，不会加空格。--Kethyga（留言） 2022年6月3日 (五) 23:01 (UTC)
- 看来译者字段也需要根据引文语种作出区分，中日韩引文改为《GB/T 7714》的格式，印欧语系的引文仍保持英维原格式。--
近日发现在 CS1 引文模板中填入“
display-authors=etal”或“display-editors=etal”后，所生成的字样由原先的“; 等”变成了“; et al”，参见“令狐姓”条目中的1、7、10号参考文献，暂时还没搞清楚是什么原因导致的。个人认为，该字样应与整条引文的语种相匹配，在中文引文内显示为“; 等”，在外文引文内显示为“; et al”，避免出现中外文混杂的情况。再如“editor”系列参数生成的“编”字，也应当基於引文语种作出区分，在中、外文引文内分别显示为“编”和“eds.”。目前在引用外文文献时使用“editor”系列参数，会导致一串外文内出现一个汉字“编”，使整条引文看上去不是很协调，参见“Template:MSW3 Wozencraft”。不知在技术上是否有办法改进这些细节，令维基编者根据情况需要来指定所显示的文字？--蕭漫（留言） 2022年6月3日 (五) 22:28 (UTC)
- 那个“等”变“et al”的，可以看Module:Citation/CS1/Configuration的最近编辑。后缀 (编)、(译)什么的，感觉中日韩的可以和印欧语系的区分开来。
- 上边的译者是其他责任者吗，感觉也挺重要的。--Kethyga（留言） 2022年6月3日 (五) 23:12 (UTC)
- @乌拉跨氪：，Special:Diff/71556201。--Antigng（留言） 2022年6月4日 (六) 08:19 (UTC)
- et al.和eds.都是拉丁式的文献格式用法，不应该翻译。现在的模板参数需要做调整，区分中外文文献，避免出现中外文杂糅。乌拉跨氪 2022年6月5日 (日) 16:46 (UTC)
- 是否可以參考日語維基百科的 cite_book 裏面添加的“和書”參數，裏面將日語和中文與主要的英語參考文獻格式區分開。--Kethyga（留言） 2022年6月5日 (日) 23:36 (UTC)
- 但这不解决参数缺省状态下的默认显示问题。--Antigng（留言） 2022年6月6日 (一) 03:40 (UTC)
- 那是否可以重新起用{{Cite book zh}}、{{Cite book en}}、{{Cite journal zh}}，发现之前是改成重定向了。--Kethyga（留言） 2022年6月9日 (四) 06:19 (UTC)
- 但这不解决参数缺省状态下的默认显示问题。--Antigng（留言） 2022年6月6日 (一) 03:40 (UTC)
- 是否可以參考日語維基百科的 cite_book 裏面添加的“和書”參數，裏面將日語和中文與主要的英語參考文獻格式區分開。--Kethyga（留言） 2022年6月5日 (日) 23:36 (UTC)
- et al.和eds.都是拉丁式的文献格式用法，不应该翻译。现在的模板参数需要做调整，区分中外文文献，避免出现中外文杂糅。乌拉跨氪 2022年6月5日 (日) 16:46 (UTC)
- 方案技术上可以实现，但本人目前对本案及近期相关提案（例如，要求periodical系列参数中文不斜体，英文加斜体等）合理性产生了一些怀疑。上方有用户主张eds.，et al.是西文文献用法，但实际的中文文献中，拉丁化的人名+中文“等”、“编”的用法并不罕见。更重要的是，本站针对引文格式的基本原则为：1. 没有官方格式，不同条目的编者可根据自己的偏好选用；2. 但同一条目内引文格式必须统一。对于同时引用中、西文文献的条目而言，让引文模板针对语种输出不同格式的引文的做法并不利于条目内引文格式的统一。原理就像是本站为了条目内格式上的统一，一律要求日期采用ISO标准格式，而不允许January 21, 2022之类的填法、显示方法一样——尽管在实际的英文文献中后者也非常常见。--Antigng（留言） 2022年6月15日 (三) 05:23 (UTC)
- 何况就算认为西文文献的引文中出现中文是一个问题（本人目前强烈怀疑是否真是一个问题），填写引文模板时如果有存档链接（目前机器人会定期、自动添加存档链接）的话，那总是会出现中文“原始链接存档于...”的，仅仅进行上述修改对解决这一问题的帮助也不大。--Antigng（留言） 2022年6月15日 (三) 05:34 (UTC)
- 机器人添加的存档链接和
|language=参数生成的语言标志，都显示在引文末尾，并且使用了引文中几乎从不会使用的全角括号。这样看来，存档链接和语言标志更像是特殊的附注信息，故其所用的语种及标点符号类型可以不与引文相匹配，而“等”“编”之类的文字是引文本身的一部分，在性质上似乎不同於前二者。如果本提案无法通过，那是否应将“et al.”改回来？毕竟“eds.”“via”之类的都已翻成了中文，唯独“et al.”保持拉丁原文并不妥当。--蕭漫（留言） 2022年6月15日 (三) 18:01 (UTC)- 个人认为，在解决这个问题之前，是不是先研究一下中英文文献常用的引文格式与wiki的格式的异同，以及上面讨论中关心的问题，在引文格式领域都是如何处理的，以及为何如此处理？我们的引文格式我认为至少要做到两点：1.在技术允许的前提下，满足我们的合理需求并尽量兼容已有的格式；2.尽可能表现出引文格式上的专业性--本章節暫時不存檔，直至问题解决。。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。
我看源代码是和英文维基完全一样的，但是完全没有切换的选项，只是两张图简单地上下排列而已。也看不到图片的caption。--Fireattack（留言） 2022年6月3日 (五) 21:38 (UTC)
- 需要运行英文维基默认启用的en:MediaWiki:Gadget-switcher.js--YFdyh000（留言） 2022年6月4日 (六) 00:17 (UTC)
- 副知@Antigng。--Txkk（留言） 2022年6月7日 (二) 04:19 (UTC)
- @Antigng：请问可否将其引入？--BlackShadowG Slava Ukraini! 2022年6月14日 (二) 10:42 (UTC)
- @
请问大家，在Template:中华人民共和国城市轨道交通中，对Template:中华人民共和国有轨电车和轻轨和Template:中华人民共和国的市郊铁路原来Navbox可以设置的child功能，在NavboxV2中无法实现，应该如何解决？谢谢！--Zzhtju（留言） 2022年6月7日 (二) 18:15 (UTC)
- NavboxV2在改写时，“没预料到”在list里面额外嵌套一个Navbox，所以没有实现类似Module:Navbox中353~369行的处理。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 07:59 (UTC)
- 感谢拨冗答复，请问有什么比较好的解决办法吗？--Zzhtju（留言） 2022年6月8日 (三) 09:25 (UTC)
- 暂时解决的话，如果像这种一个主Navbox的list嵌套一个可以独立使用的Navbox做子Navbox的，可以里面的子Navbox先用回{{Navbox}}。本来{{NavboxV2}}的考虑是希望将单纯嵌入非独立的{{Navbox|child}}等类似的Navbox模式合并一起，来避免WP:模板限制。如果还没有达到限制的话，可以先不改写。
- 至于NavboxV2这部分的话，可能补充调整和测试。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月10日 (五) 00:59 (UTC)
- 谢谢！希望行有余力能够解决，祝编安！——
- 原標題：什麼時候冒出了「字幕」命名空間，還顯示錯誤
如題，中文維基百科什麼時候引入了「字幕」命名空間了？，未見WP:命名空間有提及。且隨便點進去一個字幕命名空間頁面 TimedText:1 （ 建立頁面連結圖像TG討論）裡面顯示「維基百科目前還不存在名為「TimedText:1」的命名空間偵測錯誤。」顯然是有bug 的吧。有幾個問題：
- 字幕命名空間何時引入的？
- 字幕命名空間如何使用有沒有說明？何時會用到？
- 是否需要在WP:命名空間補充提及？
- 「命名空間偵測錯誤。」BUG是否需要修復？
以上-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 06:50 (UTC)
- (？)疑問（Special:Diff/72055421）：@Xiplus：所以這是本地能用的命名空間嗎？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 08:34 (UTC)
- 原本是需要opt-in才會開啟這個命名空間，但在該task中提到的patch移除掉這個配置了，所以才意外在所有wiki上開啟這個命名空間，先等等看他們是決定還原這個配置，還是就永久全面開啟，總之我認為本地先不需要做任何動作，以免徒勞。--Xiplus#Talk 2022年6月8日 (三) 08:36 (UTC)
- 既然是字幕，显然是给视频用的。--Txkk（留言） 2022年6月8日 (三) 08:33 (UTC)
- (？)疑問@Txkk：如何使用？在哪邊輸入？如何與视频綁定？有沒有規定格式？能直接編輯嗎？如何創建？？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 08:36 (UTC)
- 你可以去英文維基百科看看，他們開很久了，也有不少頁面。--Xiplus#Talk 2022年6月8日 (三) 08:36 (UTC)
- (？)疑問@Xiplus：所以現在是可以直接從enwiki翻譯頁面過來嗎？如果不能，甚麼時候可以？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 08:39 (UTC)
- 有需要再說啊，我還沒找到這個字幕會在哪邊顯示。--Xiplus#Talk 2022年6月8日 (三) 08:54 (UTC)
- @Xiplus：從這裡就可以進入字幕編輯介面了，估計會顯示在對應影片下方。如TimedText:CartmanAnalProbeSinga.ogg對應File:CartmanAnalProbeSinga.ogg-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 09:14 (UTC)
- 有需要再說啊，我還沒找到這個字幕會在哪邊顯示。--Xiplus#Talk 2022年6月8日 (三) 08:54 (UTC)
- (？)疑問@Xiplus：所以現在是可以直接從enwiki翻譯頁面過來嗎？如果不能，甚麼時候可以？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 08:39 (UTC)
- 你可以去英文維基百科看看，他們開很久了，也有不少頁面。--Xiplus#Talk 2022年6月8日 (三) 08:36 (UTC)
- (？)疑問@Txkk：如何使用？在哪邊輸入？如何與视频綁定？有沒有規定格式？能直接編輯嗎？如何創建？？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 08:36 (UTC)
- 要开启的话，至少要考虑本地是不是有很多视频文件和有需要配置字幕的需求？根据Special:媒体统计估算，ogg是视频的统计到6个文件。（至少有一个找到的是这个：File:Bad_apple!!_sample.ogg）——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 08:58 (UTC)
- 測試了一下有介面。但您給的例子File:Bad_apple!!_sample.ogg剛好還沒有到有歌詞的段落 囧rz……-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 09:05 (UTC)
- 翻了一下，確實有可以本地上字幕的文件，如File:CartmanAnalProbeSinga.ogg-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 09:09 (UTC)
- 如果是功能误开的话，到时还是会关掉。主要问题是：“本地是不是有很多视频文件和有需要配置字幕的需求”。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 09:26 (UTC)
- 若仅统计添加了正确的合理使用模板的视频文件，本地的合理使用视频文件很少，小于10件（Special:链入页面/Template:Non-free_video_sample）。私以为用途不大，但多一个功能总归是好事吧。--BlackShadowG Slava Ukraini! 2022年6月8日 (三) 12:32 (UTC)
- @BlackShadowG：因為是功能误开，所以到時候还是会关掉，所以如果本地要保留此功能，可能需要一個引入字幕功能的本地共識-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 12:43 (UTC)
- 多一个鸡肋功能不一定是好事。一来本地视频文件似乎很少，二来其中需要为配音标字幕的视频也似乎更少。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 13:00 (UTC)
- 若仅统计添加了正确的合理使用模板的视频文件，本地的合理使用视频文件很少，小于10件（Special:链入页面/Template:Non-free_video_sample）。私以为用途不大，但多一个功能总归是好事吧。--BlackShadowG Slava Ukraini! 2022年6月8日 (三) 12:32 (UTC)
- 如果是功能误开的话，到时还是会关掉。主要问题是：“本地是不是有很多视频文件和有需要配置字幕的需求”。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 09:26 (UTC)
- 翻了一下，確實有可以本地上字幕的文件，如File:CartmanAnalProbeSinga.ogg-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 09:09 (UTC)
- 測試了一下有介面。但您給的例子File:Bad_apple!!_sample.ogg剛好還沒有到有歌詞的段落
- 剛才給
留意到在cite web当中的title参数当中使用到{{!}}的话，{{!}}前面的内容都不会显示出来。例如：
{{cite web|title=Google {{!}} 关于|url=https://about.google/|work=Google|accessdate=2022-06-08}}返回：
关于. Google. [2022-06-08].
这到底是哪里的问题啊？--🔨（留言） 2022年6月8日 (三) 07:19 (UTC)
- (：)回應：@Liu116：可用
{{cite web|title=Google | 关于|url=https://about.google/|work=Google|accessdate=2022-06-08}}→「Google | 关于. Google. [2022-06-08].」。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月8日 (三) 07:43 (UTC)- 我当然知道这方法。但这问题出现之前已经有不少页面的来源标题用了这个模板了，另外{{!}}这个模板显然相比“
|”更方便，如果能够修复其在cite模板当中的显示问题显然更好。--🔨（留言） 2022年6月8日 (三) 08:19 (UTC)- {{!}}不是模板，是个魔术字：mw:Help:Magic_words#Other--百無一用是書生 (☎) 2022年6月8日 (三) 08:26 (UTC)
- 我当然知道这方法。但这问题出现之前已经有不少页面的来源标题用了这个模板了，另外{{!}}这个模板显然相比“
- 遇到这种情况，只能手工替换这些管道符为实体字符呗。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 08:53 (UTC)
- 现阶段要替换成“
|”不靠手工靠机器人也行，不过果然还是觉得能够修复更好，毕竟{{!}}还是更方便，而且英文版没这问题肯定相关代码已经和中文有不同。--🔨（留言） 2022年6月8日 (三) 09:19 (UTC)- 可以用{{pipe}}，效果一样，cite模板也能正常显示：Google | 关于. Google. [2022-06-08].--BlackShadowG Slava Ukraini! 2022年6月8日 (三) 13:02 (UTC)
- 现阶段要替换成“
- 這是Module:Citation/CS1/Language#L-143造成的，如果使用魔術字，會變成
-{Google | 关于}-進而觸發轉換規則。--Xiplus#Talk 2022年6月8日 (三) 13:35 (UTC)- 感谢找出问题所在，不过从代码看来，要么要用其他的方式来写这段代码，确保既可不转换来源标题又可让{{!}}正常显示，要么就只能暂时维持现状，使用其他的方式来呈现管道符号了。--🔨（留言） 2022年6月9日 (四) 02:13 (UTC)
已修复 @ Special:Diff/72102371，问题来自Special:Diff/62087761，讨论在Module talk:Citation/CS1#script-title=zh:。但是这里说到“試行一個月”而我并没有找到一个月后的评估讨论，@AT。Liangent（留言） 2022年6月11日 (六) 07:28 (UTC)
- @Liangent，不說我也忘了。不過，也實施差不多兩年多了，也不見什麼異議，或許大家也同意這個改動？--AT 2022年6月11日 (六) 11:11 (UTC)
- 我幾次見到為此強迫編者使用特定中文變體的例子。我知道此舉有其背景，但個人不太認同這種行為就是。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年6月11日 (六) 14:01 (UTC)
- 我不能同意這個改動，有什麼論文有或者書籍會繁體來源使用繁體字，簡體來水源使用簡體字？就像劉勰一文就炸了。很多內地書籍用繁體字，你告訴我要按原文輸入多多少少有些強人所難。本身假如來源有什麼繁簡轉換問題編者就應該做好吧。你們喜歡的話可以保留標題以原本的變體顯示，但是也應該有法子讓不希望轉換的編者自行選擇就是。--Ghren🐦🕛 2022年6月12日 (日) 04:58 (UTC)
- 「有什麼論文有或者書籍會繁體來源使用繁體字，簡體來水源使用簡體字？就像劉勰一文就炸了。」完全不懂您在說什麼，也看不懂您在劉勰的操作。「很多內地書籍用繁體字，你告訴我要按原文輸入多多少少有些強人所難。」顯然地大陸書籍的話必然簡體更多，繁體只佔很少的部分，相反亦然，而且繁簡轉換本來就非常簡單，在維基上預覽一下都能轉換了，我不認為這有什麼強人所難的。「你們喜歡的話可以保留標題以原本的變體顯示，但是也應該有法子讓不希望轉換的編者自行選擇就是。」現在就是不轉換標題，直接顯示代碼裡的字體，而且您前句和後句說的意思是相同的，您的意思會否是可以選擇保留原文標題用字或按地區自動轉換繁簡？如果技術上能做到的話，無任歡迎。--AT 2022年6月12日 (日) 10:14 (UTC)
- 上邊那句話看來我打錯了很多字 囧rz……。「你們喜歡的話可以保留標題以原本的變體顯示，但是也應該有法子讓不希望轉換的編者自行選擇就是。」，中間的「不」多打出來了。我在劉勰一文對於來源的處理也就是將引文格式手動變回兩年前還沒修定的樣子，繁簡可以如常轉換。既然繁簡轉換非常簡單，我既然手動將繁簡轉換成本來的原文的樣子，這樣我為什麼不直接將其轉換成繁體簡體都是對的樣子？來源和正文、繁體來源都混雜在一起，來源不多的時候還好，來源多的時候根本記不過來。有些是轉引的來源，有些可能是PDF版和HTML版，有些可能是預印版，數個版本之間繁簡不一定一致，我也不一定能看到最原始的版本，根本不可能按這套制度來。再者，這種引用保留原文繁簡標題的做法，我也看不出有實際的機構支持，也看不出有文章實例。我的意思要是大家都認為保留繁簡是比較好的話，也應該讓編者自行選擇保留原文標題或者轉換。本來是可以的，這樣一修之下，現在不行了。--Ghren🐦🕗 2022年6月12日 (日) 12:33 (UTC)
- 看不太懂您的意思，您是指這個Special:Diff/72102371改動導致劉勰的來源崩了？那看看怎樣修改吧，目前這個代碼露出是肯定不行啊。--AT 2022年6月12日 (日) 13:57 (UTC)
- Special:Diff/72130103先把它修成之前的状态，但我个人的意见是模板用户只应该按约定在title填title，而不应该写入其他语法，尤其是不应该填入一个不完整的语法片段使其“恰好”和模板的其他部分配合产生需要的效果。我能想到的另一个abuse方法是写
|title={{)}}-希望被繁简和地区词转换的文字-{{(}}|（在现在的模板实现里这样确实是能工作的），暂且不说应不应该这样做为了来使标题会被转换，但这个肯定不保证改模板后不被弄坏。Liangent（留言） 2022年6月13日 (一) 03:55 (UTC)
- Special:Diff/72130103先把它修成之前的状态，但我个人的意见是模板用户只应该按约定在title填title，而不应该写入其他语法，尤其是不应该填入一个不完整的语法片段使其“恰好”和模板的其他部分配合产生需要的效果。我能想到的另一个abuse方法是写
- 看不太懂您的意思，您是指這個Special:Diff/72102371改動導致劉勰的來源崩了？那看看怎樣修改吧，目前這個代碼露出是肯定不行啊。--AT 2022年6月12日 (日) 13:57 (UTC)
- 上邊那句話看來我打錯了很多字
- 「有什麼論文有或者書籍會繁體來源使用繁體字，簡體來水源使用簡體字？就像劉勰一文就炸了。」完全不懂您在說什麼，也看不懂您在劉勰的操作。「很多內地書籍用繁體字，你告訴我要按原文輸入多多少少有些強人所難。」顯然地大陸書籍的話必然簡體更多，繁體只佔很少的部分，相反亦然，而且繁簡轉換本來就非常簡單，在維基上預覽一下都能轉換了，我不認為這有什麼強人所難的。「你們喜歡的話可以保留標題以原本的變體顯示，但是也應該有法子讓不希望轉換的編者自行選擇就是。」現在就是不轉換標題，直接顯示代碼裡的字體，而且您前句和後句說的意思是相同的，您的意思會否是可以選擇保留原文標題用字或按地區自動轉換繁簡？如果技術上能做到的話，無任歡迎。--AT 2022年6月12日 (日) 10:14 (UTC)
- @Liangent，不說我也忘了。不過，也實施差不多兩年多了，也不見什麼異議，或許大家也同意這個改動？--AT 2022年6月11日 (六) 11:11 (UTC)
- 感谢找出问题所在，不过从代码看来，要么要用其他的方式来写这段代码，确保既可不转换来源标题又可让{{!}}正常显示，要么就只能暂时维持现状，使用其他的方式来呈现管道符号了。--🔨（留言） 2022年6月9日 (四) 02:13 (UTC)
要是可能独立出来一个参数去完成这个工作，这样我依约定来在填也是没有问题的。按你给的方法的话，这样地域词就会转换，多多少少可能有过度转换的问题。当然，我强行将其修成
|title={{)}}--{{(}}zh;zh-hans;zh-hant{{!}}希望被繁简转换的文字-{{)}}-{{(}}|也不是不能用。有时候实在是繁简来源搞不清，又或者是觉得调整繁简实在是比较麻烦，要是有个正规点的方法处理就好。--Ghren🐦🕓 2022年6月13日 (一) 09:54 (UTC)- 參考文獻應保持文字原貌以便於查證（Wikipedia:地区词处理#参考文献应避免情况），目前本地只是禁止了標題部分的轉換，其實個人傾向於更加激進的做法，即對整個引文都不作轉換，避免繁簡雜糅。另外，刘勰條目中的引文標題使用了方括號式內鏈，個人認為
|title=參數最好只填入純粹的標題，如需添加內鏈應使用|title-link=參數。--蕭漫（留言） 2022年6月13日 (一) 18:36 (UTC)- 后面这句我是同意的，也就是我上面说的“模板用户只应该按约定在title填title，而不应该写入其他语法”。上面那个修改只是把刘勰最小变动地解决一下，把“尤其是不应该”的改成了“我觉得不应该”的方法。但是更大的问题，包括条目编者不按约定填写来实现特殊（和模板默认不同的）效果，以及刘勰中选用的效果（绕过模板设计使用转换）是否可以接受，我觉得应该拿到技术客栈之外更广泛地讨论一下。Liangent（留言） 2022年6月13日 (一) 21:48 (UTC)
- 关于编者为实现特殊效果而不按默认约定填写模板一事，有个现象值得引起广泛注意——某些编者会在中日韩以外的引文中加入斜体代码，将 periodical 系列字段（journal/magazine/newspaper/work/website）以及书籍引文模板中的 title 字段等显示为斜体，来达到和英维相同的效果。窃以为此举有其合理性和必要性，可帮助读者辨别引文中的不同字段，并且符合外文文献普遍的引用格式。然而问题在于，编者通过手动添加代码来强行改变模板的默认效果显然不是个好做法，造成了本地条目中的外文引文风格混乱不一（既有显示成斜体的，也有未显示成斜体的）。要彻底解决该问题，恐怕还得将中外文文献的显示风格区分开来（见本页上节讨论），中日韩引文维持现有格式，印欧语系的引文则效仿英维，将特定字段预设为斜体，如此方能正本清源，避免因编者的编辑习惯不同而导致引文风格不统一。待模组修改完毕后，可使用机器人清理编者手动加入的斜体代码。@User:Liangent @User:AT @User:Antigng @User:乌拉跨氪 --蕭漫（留言） 2022年6月14日 (二) 06:09 (UTC)
- @Ghrenghren的作法，可能不利于COins自动获取条目内的参考文献，利用维基百科内置的COins可以，部分文献管理软件可以抓取所有采用{{cite ****}}系列模板的参考文献。如果使用Ghren的作法显示结果是imgur截图。
- 倾向支持Ghren的另一个说法，允许读者选择是否进行繁体转换。
- 看知乎上一个讨论，应该是没有强制规定要求保持原文的繁简体[3]。看了台大中文学报的一篇论文，将简体的参考文献转换成了繁体，〈出山与入山：李白庐山诗的精神底蕴〉。--Kethyga（留言） 2022年6月14日 (二) 04:31 (UTC)
- 后面这句我是同意的，也就是我上面说的“模板用户只应该按约定在title填title，而不应该写入其他语法”。上面那个修改只是把刘勰最小变动地解决一下，把“尤其是不应该”的改成了“我觉得不应该”的方法。但是更大的问题，包括条目编者不按约定填写来实现特殊（和模板默认不同的）效果，以及刘勰中选用的效果（绕过模板设计使用转换）是否可以接受，我觉得应该拿到技术客栈之外更广泛地讨论一下。Liangent（留言） 2022年6月13日 (一) 21:48 (UTC)
- 果然正常了，太感谢了！虽然来源标题不转换确有合理之处吧，不过视乎具体改法考虑bug的存在也是必要的啊……话说其实我两年前就发现这bug了，不过我一直没提出来……--🔨（留言） 2022年6月12日 (日) 03:02 (UTC)
- 能否在citoid里，把标题里面的"|"转换掉，一般在自动引用时会引入这个问题。--Kethyga（留言） 2022年6月12日 (日) 06:28 (UTC)
- 一个魔术字在来源标题内呈现的问题居然引出关于来源标题繁简转换的进一步讨论也是神奇……虽然不是完全无关，不过还请各位不要跑偏太多吧。--
RT，建议在工具里面加入提报内容评选DYK、GA、FA、FP功能。设计提报条目评选功能的时候，建议加入初步核查条目提报资格的功能，把存在维护模板的、新条目近期没有重大或字节不够等问题的条目挡下来。如果这个能实施，一来可以简化提报流程，二来可以直接阻挡明显不符合标准的内容提名，有效节省资源。--百战天虫（留言） 2022年6月10日 (五) 14:59 (UTC)
ITN也可以搞起来。顺便@Xiplus--百战天虫（留言） 2022年6月10日 (五) 15:00 (UTC)
- 可以是獨立工具，不是非得加到Twinkle內。--Xiplus#Talk 2022年6月10日 (五) 15:11 (UTC)
- 建议作为独立工具，Special:参数设置#mw-prefsection-gadgets也有“在条目的左侧工具栏下添加新条目推荐提报工具”。--BlackShadowG Slava Ukraini! 2022年6月13日 (一) 15:31 (UTC)
小(！)意見，獨立工具，希望移動版可以用-- Evesiesta Deutschland(因為簽名太長而決定手動簽名的維基人)（簽|論） 2022年6月17日 (五) 10:27 (UTC)
本章節暫時不存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。绿链的颜色不符合WCAG AAA标准
打印时把上下滚动箭头也一起打印出来了
是否依然有必要保留“Template:(语言代码)-link”系列重定向（比如
经过本站多年对ILH系列模板的使用指导，我发现几乎没人能把
{{link-(语言代码)}}写反，顶多遇到个别几例后续参数写反的人（估计是{{tsl}}控的后遗症），-link系列存在感至少本人未曾感受到，所以我希望未来某一天彻底弃用并使之走向提删，但因为牵涉早期创建者人数众多，故冀希望于在VPT先达成弃用共识再行行动。--Liuxinyu970226（留言） 2022年6月15日 (三) 06:07 (UTC)- 删除了是不是可以减轻服务器负担
？可以保留下来，或者不排除会突然习惯用link-X。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月15日 (三) 06:21 (UTC) - 未见删除必要。T:En-link有5652个链入。--YFdyh000（留言） 2022年6月16日 (四) 22:15 (UTC)
- 倾向于希望清理。--Liuxinyu970226（留言） 2022年6月17日 (五) 05:18 (UTC)
- (？)異議WP:沒壞別修。如果問題沒有真正的發生，試圖解決這個虛構的「問題」對維基百科沒有效益。我們不該浪費時間和精力假想一個虛構的問題，再想辦法解決它。 請問使用
{{link-XX}}造成了甚麼問題？Wikipedia:不要担心性能。所有東西都不是問題。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月17日 (五) 06:45 (UTC)- @A2569875：同下面看法，我所咨询的是{{XX-link}}（语言代码后面-link后缀），跟link-XX系列（link-前缀加语言代码）毫无关系，您应该重新审题。如果一个重定向的建立不是为了方便ta人使用，那么创建ta干什么呢？只是觉得重定向好玩么？--Liuxinyu970226（留言） 2022年6月21日 (二) 07:30 (UTC)
- 除非坏了，否则必要性不大。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月17日 (五) 06:35 (UTC)
- 的确坏了，不过例子不在维基百科上，而是维基词典上。--Liuxinyu970226（留言） 2022年6月21日 (二) 05:48 (UTC)
- (？)異議WP:沒壞別修。如果問題沒有真正的發生，試圖解決這個虛構的「問題」對維基百科沒有效益。我們不該浪費時間和精力假想一個虛構的問題，再想辦法解決它。 請問使用
- 倾向于希望清理。--Liuxinyu970226（留言） 2022年6月17日 (五) 05:18 (UTC)
- (－)反对：
{{link-XX}}可讀性更佳，從「link」字可以直接看出在幹嘛。{{Internal link helper}}太長，累贅！(！)抗议x1；{{ilh|en}}是啥I?L?H?? Information Looking Header？Insert List Header？Infobox Looting Host？Insect Losing Hat？Interscholastic League of Honolulu？明明「link」字一看就懂，為啥要硬要換成「艱澀難懂的」ILH？(！)抗议x2。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月17日 (五) 06:41 (UTC)- 其实{{link-en}}和{{tsl}}都是以module:ilh为骨干，两者目前的差别只是内链和处链的位置对调。——白布飘扬（留言） 2022年6月18日 (六) 17:06 (UTC)
- 您是不是搞錯了什麼？很明顯上述討論提議要廢除的是「某-link」，不是「link-某」。要抗議也得先好好看過題目是什麼再來抗議吧。Ericliu1912（留言） 2022年6月19日 (日) 19:35 (UTC)
- (！)意見，我记得{{link-en}}系列以前是为了替换当时泛滥的“[[某某某]]（[[:en:something else|something else]]）”等外标式跨语言链接，而{{tsl}}则刚好用来替换“[[:en:something else|某某某]]”之类的隐藏式的跨语言链接，两种模板结构刚好分工互补，Cewbot（讨论 | 貢獻）好像也还在使用？——白布飘扬（留言） 2022年6月18日 (六) 16:38 (UTC)
- 不知module:ilh能不能自动判读内链与外链，这样就不必纠结其位置了。——🤔白布飘扬（留言） 2022年6月18日 (六) 17:06 (UTC)
- 假如真的廢止這些模板，對於cewbot來說只不過少處理這種類型的模板，實際上並無影響。--Kanashimi（留言） 2022年6月18日 (六) 21:33 (UTC)
- (－)反对：沒壞別修。廢除為了甚麼 ? 且影響維護。不要強制別人使用哪種綠鏈的習慣。--約翰同志－條目裱糊匠（留言） 2022年6月19日 (日) 21:07 (UTC)
- 坏了不少页面了，谢谢。Cewbot在维基词典合并wikt:Template:TL至wikt:Template:Tl以后，他加禄语在维基词典就已经“几近消亡”。--Liuxinyu970226（留言） 2022年6月21日 (二) 05:46 (UTC)
- 甚麼因素令閣下將維基詞典的問題，放到維基百科談 ?--約翰同志－條目裱糊匠（留言） 2022年6月21日 (二) 11:47 (UTC)
- 我猜可能是因为那边没多少人活跃吧？--Txkk（留言） 2022年6月22日 (三) 06:41 (UTC)
- @
查詢模板:Expand Ukrainian自動分類於Category:依語言分類的擴充模板，但在當頁未見顯示，計數也沒有收入，是否現時維基站域存在技術問題？在使用跨站（en站）時有顯示「Invalid CSRF token」參數，可能需要聯繫技術同好協助檢測有關數據。--約克客（留言） 2022年6月15日 (三) 10:05 (UTC)
- 應該修好了。——
点入即可见，NoteTA设置标题也无济于事，经测试与条目内的Automatic Taxobox模板有关，试了一下删除该模板就没事了，求解决。--Bigbullfrog1996（𓆏） 2022年6月16日 (四) 19:15 (UTC)
- @白布飘扬 --蕭漫（留言） 2022年6月17日 (五) 04:51 (UTC)
- 目前版本我這里試了幾個不同瀏覽器，都可以正確顯示。不過，我之前已經發覺，使用用{{全局僻字}}模板的頁面容易出現標題、或分類連接載入不全的情況，但刷新後又能正常顯示，目前在模板源代碼沒看出問題。{{Automatic Taxobox}}與{{全局僻字}}都會改寫標題，兩者的前後次序會對有所影響，另外，因為“𰡉”（U+30849 𰡉 ）和“𰡓”（U+30853 𰡓 ）都是CJK-G區最新的漢字，在沒採用圖片或者使用最新字集的話，目前大部份手機和電腦的字符集可能不支持。——白布飘扬（留言） 2022年6月18日 (六) 12:28 (UTC)
- 目前能免費使用的G區漢字完整字符集暫時找到有“sim-ch_n5100”。——白布飘扬（留言） 2022年6月18日 (六) 12:41 (UTC)
- 先前标题露出转换语法，目前看上去正常（尽管僻字显示为方块），未看出是哪里做了调整。--YFdyh000（留言） 2022年6月18日 (六) 22:09 (UTC)
各位维基人好，
中文维基百科站内的
wgULS和wgUVS函数自部署已有十余年的时间。在这十余年间，MediaWiki、JavaScript及其开发环境都发生了翻天覆地的变化，而这两个函数的若干问题也逐渐显露出来：- 仍然使用旧式的
wgXXX类名称，污染全局空间。现今MediaWiki中的此类变量全部通过mw.config.get()获取，但这两个函数并未也无法跟进。 - 函数名称使用意义不明的缩写，影响代码可读性。
- 参数列表过长，影响阅读。设计良好的JavaScript函数最多仅应包含两个参数。设想一下，如果像这样调用
wgULS()（此代码确实存在）：难道不会使代码非常难以阅读及维护？wgULS( undefined, undefined, '显示%s的用户日志', '顯示%s的使用者日誌', '顯示%s的用戶日誌' );
- 并非类型安全。
wgULS和wgUVS允许任何类型的参数传入，且返回值类型亦不确定，这可能会导致非预期的行为发生，并且使得代码难以维护。 - 没有代码文档。这使得不了解这些函数的人必须通过直接阅读代码来确定它们的用法。
为了解决这些问题，我开发了
HanAssist小工具，作为wgU*S的现代API替代。小工具页面位于Diskdance/public/HanAssist，GitHub仓库位于此处。我认为的几个亮点：
- 代码使用TypeScript编写；
- 支持新的命名参数语法，显著提升代码可读性；
- 完善的代码文档及类型定义；
- 新增一个批量转译消息的API，在代码大量依赖中文变体消息时可以使得代码更紧凑、更模块化。
用法示例( function( HanAssist ) { // 等同于 wgULS( '一天一苹果，医生远离我。', '一天一蘋果，醫生遠離我。' ); HanAssist.localize( { hans: '一天一苹果，医生远离我。', hant: '一天一蘋果，醫生遠離我。' } ); // 等同于 wgULS( undefined, undefined, 'IP用户', 'IP使用者', 'IP用戶' ); HanAssist.localize( { cn: 'IP用户', tw: 'IP使用者', hk: 'IP用戶' } ); // 等同于 wgUVS( '一天一苹果，医生远离我。', '一天一蘋果，醫生遠離我。' ); HanAssist.vary( { hans: '一天一苹果，医生远离我。', hant: '一天一蘋果，醫生遠離我。' } ); // 批量转译消息 // 推荐配合 mw.messages 使用 mw.messages.set( HanAssist.parse( { 'article': { hans: '条目', hant: '條目' }, 'category': { hans: '分类', hant: '分類' }, 'categories': { hans: '分类', hant: '分類' }, 'image': { hans: '文件', hant: '檔案' }, 'images': { hans: '文件', hant: '檔案' }, 'minute': '分', 'minutes': '分', 'second': '秒', 'seconds': '秒', 'week': '周', 'weeks': '周', 'search': { hans: '搜索', hant: '搜尋' }, 'SearchHint': { hans: '搜索包含$1的页面', hant: '搜尋包含$1的頁面' }, 'web': { hans: '站点', hant: '站點' }, } ) ); mw.msg( 'categories' ); // => 界面语言为简中：“分类”；繁中：“分類” mw.msg( 'SearchHint', 'Apple' ); // => 界面语言为简中：“搜索包含Apple的页面”；繁中：“搜尋包含Apple的頁面” } ( mw.libs.HanAssist ) );
另有一点需要澄清：如果将来本小工具成功部署，旧API在短期内不会移除，仍然保留（但是会标记为deprecated）。
欢迎各位技术向维基人测试和反馈本小工具，并提出宝贵的意见和建议，谢谢！--Diskdance 2022年6月19日 (日) 07:58 (UTC)
- 考虑把这个HanAssist挂到mw.libs下或者mw对象吗？我觉得wgU*S也可以这么弄，就是引用得太多了。--安忆Talk 2022年6月19日 (日) 12:23 (UTC)
- (～)補充：这是部分小工具使用HanAssist重写的效果——Diskdance/public/popups-hanassist-ify.js、Diskdance/public/edittools-delh-hanassist-ify.js，供各位参考。--Diskdance 2022年6月22日 (三) 10:40 (UTC)
问了不少维基人，反响还可以。接下来考虑在本站部署本小工具，替换掉wgU*S
并默认启用（EDIT: 不需要默认启用）。小工具定义如下：
HanAssist[ResourceLoader|hidden|targets=desktop,mobile]|HanAssist.js
其他脚本调用小工具的代码示例：
mw.loader.using( 'ext.gadget.HanAssist', function() { // Use HanAssist here } );
敬请各位发表自己的看法，谢谢。--Diskdance 2022年6月24日 (五) 10:47 (UTC)
- 讓其他工具依賴的lib，為何要默認啟用？--Xiplus#Talk 2022年6月24日 (五) 11:29 (UTC)
- 考虑到HanAssist会shim掉wgU*S，而本站现有大量小工具使用wgU*S，为了避免部署后出现大量deprecate warning，所以拟定部署方案如下：
- 先部署不含wgU*S垫片（shim）的HanAssist，让新API和旧API共存60天，以评估新API可能带来的问题；
- 若评估无问题，60天后，将site-lib中的wgU*S移除，改为依赖含有wgU*S垫片（shim）的HanAssist，deprecate wgU*S；
- 在相当长的一段时间后（>=1年），彻底移除wgU*S。
- 现征求社群意见。--Diskdance 2022年6月25日 (六) 04:24 (UTC)
- 建议“deprecate warning”延后，如180天，以观察主动迁移后是否会暴露出新问题。即共存30天是alpha阶段，beta阶段不显示警告。--YFdyh000（留言） 2022年6月25日 (六) 04:46 (UTC)
- shim是否也要延后？--Diskdance 2022年6月25日 (六) 04:55 (UTC)
- 我不确定shim影响如何，所以暂无意见。--YFdyh000（留言） 2022年6月25日 (六) 05:18 (UTC)
- 延后至60天。[email protected]SunAfterRain、Alexander Misel、Lt2818：。--Diskdance 2022年6月25日 (六) 05:26 (UTC)
- 我建議是2022/12/31和2023/12/31（或2024/06/30），墊片直接換了，只是先不警告--
維基媒體技術社群現在發佈最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻譯版本。
最近更改
- 目前在维基百科Android客户端中，您可以通过溢出菜单（点击形如三个点的图标
）中的一个选项来一次编辑一整个页面。 [4] 
近期的一些对数据库的变更可能会影响通过Quarry工具做出的查询。在英文维基百科、维基共享资源和维基数据中针对site_stats的查询需要更新。了解更多信息。- 您目前可以在防滥用过滤器中使用
user_global_editcount变量来避免影响到在全域范围内活跃（但在本地编辑较少）的用户。 [5]
本週後期變更
MediaWiki的新版本將於6月21日部署至測試維基及MediaWiki.org，於6月22日部署至非維基百科站點及部分维基百科，并於6月23日部署至所有站點，參見日曆。- 使用非响应式皮肤的用户（如MonoBook或Vector）可能注意到了在移动设备上默认缩放级别的一些微小变化。此举旨在优化缩放功能，确保所有的界面元素都可以呈现在页面上（如Vector 2022的“目录”）。罕见情况下，这可能会对您访问页面造成一些麻烦；如果您就此遇到了问题，请@Jon (WMF)以进行站内沟通。 [6]
未來更新
2022年6月20日 (一) 20:18 (UTC)
脚本问题
如何限制脚本只在特定的命名空间运行？--Txkk（留言） 2022年6月22日 (三) 06:37 (UTC)
if(mw.config.get("wgNamespaceNumber")==命名空间id ){ //要在特定的命名空间运行的脚本 }
- 例如，Wikipdeia命名空间id=4（可至Wikipedia:命名空间查詢）
if(mw.config.get("wgNamespaceNumber")===4 ){ //要在Wikipdeia命名空间运行的脚本 }
- 又例如，僅在特殊頁面運行的腳本，特殊頁面的命名空间Special命名空间id=-1（可至Wikipedia:命名空间查詢）
if(mw.config.get("wgNamespaceNumber")===-1 ){ //要在特殊頁面运行的脚本 }
- 如果要多個，以下[0,4]可自行添加例如[0,1,2,4,10,100]：
if([0,4].includes(mw.config.get("wgNamespaceNumber"))){ //要在id=0命名空间(條目)和id=4命名空间(Wikipdeia命名空间)运行的脚本 }
- 反之如果，不要在特定多個命名空间运行：
if(![0,4].includes(mw.config.get("wgNamespaceNumber"))){ //不要在id=0命名空间(條目)和id=4命名空间(Wikipdeia命名空间)运行的脚本 }
- 同理，不要在單一特定多個命名空间运行：
if(mw.config.get("wgNamespaceNumber")!==4){ //不要在id=4命名空间(Wikipdeia命名空间)运行的脚本 }
- -- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年6月22日 (三) 06:43 (UTC)
- 具体id可以用
console.table(mw.config.get('wgNamespaceIds'))查看。--安忆Talk 2022年6月22日 (三) 06:46 (UTC) - 如果针对css的话，可以看body标签里面的class，里面有标识页面命名空间的class名，例如项目空间（Subject）对应有ns-4和ns-subject。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月22日 (三) 08:32 (UTC)
怎么固定脚本的界面语言不变呢？--Txkk（留言） 2022年6月23日 (四) 12:25 (UTC)
- 举Wikiplus的例子来说，浏览器是什么语言，它就显示什么语言。我用的浏览器是中文界面，在英维出现中文的Wikiplus未免太突兀了。--Txkk（留言） 2022年6月23日 (四) 12:30 (UTC)
- 在enwiki引入前，加一句
localStorage.Wikiplus_Settings = '{"language":"en-us"}';。--安忆Talk 2022年6月23日 (四) 13:35 (UTC)- 别的脚本呢？有没有通用的设置语言的方法？--Txkk（留言） 2022年6月24日 (五) 02:41 (UTC)
- 没有。--
Category:尚未清空的已重定向分類有十幾個中華人民共和國地級市重新導向分類長期無法清空，問題應該出在{{PRC admin/navcat}}，如何修復？--紺野夢人 2022年6月22日 (三) 09:33 (UTC)
tabs模板不能正常显示
u:Evesiesta/沙盒13中最后两个框点击后为空，但引用了同一页面的另一tabs模板：u:Evesiesta/沙盒19却显示正常，还请各位查看，谢谢！（早前已问过DinoWP君但其尚未回复） --Evesiesta 2022年6月25日 (六) 06:23 (UTC)
- 没有。--
- 别的脚本呢？有没有通用的设置语言的方法？--Txkk（留言） 2022年6月24日 (五) 02:41 (UTC)
- 在enwiki引入前，加一句
- 目前在维基百科Android客户端中，您可以通过溢出菜单（点击形如三个点的图标
- 我建議是2022/12/31和2023/12/31（或2024/06/30），墊片直接換了，只是先不警告--
- 延后至60天。[email protected]SunAfterRain、Alexander Misel、Lt2818：。--Diskdance 2022年6月25日 (六) 05:26 (UTC)
- 我不确定shim影响如何，所以暂无意见。--YFdyh000（留言） 2022年6月25日 (六) 05:18 (UTC)
- shim是否也要延后？--Diskdance 2022年6月25日 (六) 04:55 (UTC)
- 建议“deprecate warning”延后，如180天，以观察主动迁移后是否会暴露出新问题。即共存30天是alpha阶段，beta阶段不显示警告。--YFdyh000（留言） 2022年6月25日 (六) 04:46 (UTC)
- 仍然使用旧式的
- 應該修好了。——
- @
- 我猜可能是因为那边没多少人活跃吧？--Txkk（留言） 2022年6月22日 (三) 06:41 (UTC)
- 甚麼因素令閣下將維基詞典的問題，放到維基百科談 ?--約翰同志－條目裱糊匠（留言） 2022年6月21日 (二) 11:47 (UTC)
- (：)回應：@Liu116：可用
- 谢谢！希望行有余力能够解决，祝编安！——
- 感谢拨冗答复，请问有什么比较好的解决办法吗？--Zzhtju（留言） 2022年6月8日 (三) 09:25 (UTC)
- NavboxV2在改写时，“没预料到”在list里面额外嵌套一个Navbox，所以没有实现类似Module:Navbox中353~369行的处理。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月8日 (三) 07:59 (UTC)
- @
- 需要运行英文维基默认启用的en:MediaWiki:Gadget-switcher.js--YFdyh000（留言） 2022年6月4日 (六) 00:17 (UTC)
- 个人认为，在解决这个问题之前，是不是先研究一下中英文文献常用的引文格式与wiki的格式的异同，以及上面讨论中关心的问题，在引文格式领域都是如何处理的，以及为何如此处理？我们的引文格式我认为至少要做到两点：1.在技术允许的前提下，满足我们的合理需求并尽量兼容已有的格式；2.尽可能表现出引文格式上的专业性--
- 机器人添加的存档链接和
- 看来译者字段也需要根据引文语种作出区分，中日韩引文改为《GB/T 7714》的格式，印欧语系的引文仍保持英维原格式。--
