维基百科讨论:字詞轉換處理/公共轉換組

關於公共轉換組

--1k1p3 (留言) 2009年6月11日 (四) 10:56 (UTC)

最近閱讀了一些七龍珠人物的條目，發現這些條目掛的NoteTA模板內容重複甚多，似乎可以公共轉換組代替。海賊王類條目也是一樣。可是我已經複製好要轉的字詞，卻不知道要如何建立新轉換組（Template:CGroup/doc沒有提到如何建立）。請問有什麼快捷的方式可以建立新轉換組嗎？我印象中先前有逛過某個有建立新轉換組的按鈕的頁面，可是名稱早就忘記了。請問是那個名稱？--RekishiEJ (留言) 2009年5月20日 (三) 04:07 (UTC)

我是在条目中先输入{{noteTA|G1=XXXX}}，然后再显示预览，这样就可以在noteTA中找到创建的链接了。--菲菇＠维基食用菌协会 2009年5月20日 (三) 08:01 (UTC)

Wikipedia:字詞轉換處理/公共轉換組頁面中間。剛用它來創建了麻將的快速轉換初稿。—Altt311 (留言) 2009年5月22日 (五) 04:52 (UTC)

公共轉換組似乎壞了

剛測試包括電影(Movie)和藝人(Show)兩個轉換組似乎都無法正常運作--Gonbom（留言） 2012年6月26日 (二) 07:36 (UTC)

IT转换组哪个地方也有问题，导致很多条目被归入Category:公共轉換組模板···--Fanglongzong^T‿T 2012年6月26日 (二) 10:02 (UTC)

IT转换组的分类已用<noinclude>处理了——路过围观人士 2012年7月3日 (二) 07:10 (UTC)

分类有问题，Category:體育公共轉換組模板

什么原因呀？--Berthe（留言） 2013年1月10日 (四) 21:41 (UTC)

公共轉換組是否不會轉換分類？

如注音文這一條目使用了模块:CGroup/IT，但台灣正體模式下的分類仍顯示「網絡文化」而非「網路文化」。--KRF（留言） 2016年12月26日 (一) 10:24 (UTC)

抗议把“台湾词汇-陆标正字法”和“大陆词汇-台标正字法”视作破坏的行为

这叫强行更改他人习惯，而且是无关于百科内容的，对得起“自由的百科全书”里的“自由”两字吗？

“自由”应当允许每位贡献者以自己喜欢的方式贡献。--七个点　（留言　Flow留言　个人的黑名单） 2017年5月26日 (五) 15:35 (UTC)

您是指用簡體字寫台灣用詞（「计程车」），用繁體字寫大陸用詞（「出租車」）？這樣只會給編輯及轉換帶來困擾。--Mosowai（留言） 2022年8月30日 (二) 14:51 (UTC)

做人做事已礼代人，在社会服务，为民以中心点，多个团队不如一个好的团队为中心点，用正解的思维去解决事情，肯定会有解决得了的问题，把所以主意力放在一个解决放向，很快就会解决问题的答案，佛祖要的是人类和平相助，每天烧香拜佛，不如帮助人类需要帮助的，宇宙有三界，天道，人道，地道。那么人类做好人道的和平就好了。 Lee chee keong（留言） 2022年1月16日 (日) 10:48 (UTC)

在模組頁面顯示description

我不確定在模块:CGroup/My_Little_Pony類似的模組網頁中顯示內容是否用的{{CItem}}或是其它的。在模組頁面中我經常使用description參數，但卻不會在模組頁面中直接顯示出來。例如：

{ type = 'item', original = 'Twilight Sparkle', rule = '暮光闪闪=>zh-cn:紫悦;暮光闪闪=>zh-tw:紫悦;暮光闪闪=>zh-hk:紫悦;', description = '根據「名從主人」命名原則，應統一使用「紫悦」這一官方譯名' },

這樣的代碼在模組頁面是否能顯示出：原文：Twilight Sparkle；暮光闪闪⇒大陆：紫悦；暮光闪闪⇒台灣：紫悦；暮光闪闪⇒香港：紫悦；當前顯示為：紫悦；註釋：根據「名從主人」命名原則，應統一使用「紫悦」這一官方譯名

就是模組頁面中是否能加入紅色部分？--eflyjason (留言) 2017年8月6日 (日) 14:48 (UTC)

有关于公共字词转换组的若干讨论

最近在编辑页面时，我发现许多字词在公共字词转换组中都没有出现。并且在阅读公共字词转换组时，我感觉许多公共字词转换组列表的分类有重叠。所以同样的字词有可能会出现在多个不同的公共字词转换组中，有些字词却又没有出现在任何字词转换组中。另外，当我想要转换一个特定词汇，要在长长的转换组列表中找到我要转换的字词的时候，我觉得非常不便。所以我提出如下一些建议：

1. 制作通过字词搜索转换组的功能，从而能够让编者方便知道某个字词出现在哪一个转换组中；
2. 制作字词与转换组对应关系的统计功能，从而能够方便得知哪些转换组之间的内容有重叠；
3. 撰写有关于字词转换组分类的共识或方针，并且加入字词转换组的帮助页面中，使得其他编者得以了解字词转换组的分类方式；
4. 设置专门的字词转换组分类的兴趣小组，从而可以更加统一地管里字词转换组的分类。

在Telegram群中，我与其他的维基百科编者对此问题进行过一些简单的交流。由此也获得了不同的看法与声音：

1. 这项工程规模浩大，人力资源不足，无法实施。
2. 分类大多数是以“图”的拓扑学结构出现的，而并不是“树”的结构出现的，所以某些字词很难将其分类到某一个字词转换组中。

对以上的两个问题，我的思考如下：

1. 某些人力资源不足的情况可以用插件，甚至是外部工具的方式来替代。例如“通过字词搜索转换组”的功能，就可以考虑做成TG以及IRC（举例仅供参考）的bot。有了这些工具的辅助，我相信即便对现状改善没有直接的帮助，我们也会对字词转换组这个问题有一个更加深入的了解。
2. 关于字词分类的拓扑学结构，我想一旦我们有了一个字词与转换组目前对应关系的列表，对照列表进行探讨，我们或许会得到更好的结论。所以我个人认为在对这个问题没有一个更加深入的了解之前，要得出一个完美的分类结论是不太现实的。一旦我们对现状有了了解，我们可以根据现状，得到对条目破坏程度最小的解决方案。届时我们可以通过达成共识与方针的方式加强这套解决方案，并且通过设置兴趣小组的方式来实施这套方案。

由于我对维基百科的管理、流程、历史以及各项细节不甚了解，如有不切实际之处，或是错误之处，还望不吝指正。

感谢！

西瓜玩偶（留言） 2019年11月12日 (二) 13:20 (UTC)

• 如果想轉換個別特定詞彙，用全文轉換似乎已經足夠？--【和平至上】^{別人罷工是不上班，香港暴徒「三罷」是不讓人上班、要别人閉嘴}💬📝 2019年11月12日 (二) 15:30 (UTC)
  • 您好，感谢您的意见。由于我个人近期编辑摩托车/电单车/机车的条目较频繁，有一些转换词汇需要在二至三篇条目中拷贝。我个人认为这样做效率有些低下、容易出错，并且需要新添加转换字词时，就需要在二至三篇条目中逐一添加。故我个人认为有一套方便的可供大家使用的全局转换组是一件方便的事情。然而我对目前的公共转换组的现状并不是非常满意，故提出以上建议。西瓜玩偶（留言） 2019年11月12日 (二) 15:51 (UTC)

我曾经有过类似想法，在wmflabs上建一个项目，对所有的字词转换可以进行搜索查询。技术上应该不难实现--百無一用是書生 (☎) 2019年11月13日 (三) 08:38 (UTC)

• 如果分类不是树状而是图状，一般来说是分类本身有问题，可以拿来讨论修正。分类是很重要的。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年11月13日 (三) 09:14 (UTC)

公共轉換組/重複字詞報告

先前討論：Wikipedia:互助客栈/其他/存档/2019年11月#有关于公共字词转换组的若干讨论

@西瓜玩偶、和平至上、Shizhao、UjuiUjuMandan：做了個Wikipedia:字詞轉換處理/公共轉換組/重複字詞報告、Wikipedia:字詞轉換處理/公共轉換組/各頁面包含字詞，歡迎提供建議。 --Kanashimi（留言） 2019年12月2日 (一) 09:19 (UTC)

(＋)支持非常感谢您的努力！我前些时间比较忙，一直没有在这方面继续跟进，没想到有人看到并且已经完成了我的想法！唯一想要提的一点是想问下这些重复的字词是从何而来呢？当时发现字词转换除了在公共转换组模块以及公共转换组模版中存在之外，还在Wikipedia的php代码中，以及全局转换组中存在。如果能再将其加入列表中的话就再好不过了！不过即便是不加入全局转换组以及php代码中的静态转换，目前的列表已经可以用来参考制定字词转换组的规则。不知@Kanashimi：阁下是否对此有初步的建议。——西瓜玩偶（留言） 2019年12月2日 (一) 15:55 (UTC)

 已修复 --Kanashimi（留言） 2019年12月3日 (二) 08:30 (UTC)

非常感谢！我快速地浏览了一下您的Wikipedia:字詞轉換處理/公共轉換組/重複字詞報告这个页面。我目前正在陆续零散地把我和其他一些人的意见记录在我的用户页面中，欢迎深入讨论。——西瓜玩偶（留言） 2019年12月3日 (二) 16:35 (UTC)

假如放在Wikipedia:字詞轉換處理/公共轉換組的討論頁或許會更好？公共轉換組應該個包含嵌入其他公共轉換組的功能。另外 MediaWiki:Conversiontable/* 包含的詞彙有些也太偏頗了。 --Kanashimi（留言） 2019年12月3日 (二) 22:16 (UTC)

Module转换组定义转换项时，能否不用填写 type = "item" ？

目前定义转换项时，需要填写type = "item"，比如：

{ type = "text", text = "=== 硬體用語 ===" },
{ type = "item", original = "computer", rule = "计算机=>zh-tw:電腦; 计算机=>zh-hk:電腦; 计算机=>zh-mo:電腦;" }, -- 大陆亦常用“电脑”，故用单向
{ type = "item", original = "memory", rule = "zh-cn:内存; zh-tw:記憶體;" },
{ type = "item", original = "port", rule = "zh-cn:端口; zh-tw:埠;" },

这样会让定义项比较长，如果后面有注释容易导致显示上换行。而且Module大部分内容都是在定义转换，所以能否考虑将type = "item"作为缺省设置，可以省略不填？就像：

{ type = "text", text = "=== 硬體用語 ===" },
{ original = "computer", rule = "计算机=>zh-tw:電腦; 计算机=>zh-hk:電腦; 计算机=>zh-mo:電腦;" }, -- 大陆亦常用“电脑”，故用单向
{ original = "memory", rule = "zh-cn:内存; zh-tw:記憶體;" },
{ original = "port", rule = "zh-cn:端口; zh-tw:埠;" },

--洛普利宁 2021年3月11日 (四) 06:14 (UTC)

建议公共转换组这样写语法糖，排版整洁而不减功能。各位对格式是否有意见，比如函数名、I( 内容 )是否要留空格。--YFdyh000（留言） 2021年3月11日 (四) 08:07 (UTC)

目前修改Module:CGroup/泰國人名和Module:CGroup/People后未见异常。鉴于只是格式调整且易于回退，如果3日内无反对，计划手动转换当前的公共转换组模块到此格式（不含模板和重定向）。--YFdyh000（留言） 2021年3月11日 (四) 12:43 (UTC)

@YFdyh000：这个太好了！PS：I会不会容易被看成小写的l？PPS：只输入一个参数时，能否视作输入参数乙？--洛普利宁 2021年3月11日 (四) 16:02 (UTC)

那就用Item，沒必要短到難以理解。另外original似乎沒有用處，應該可以改成註解以減少回傳的資料量。--Xiplus#Talk 2021年3月12日 (五) 01:49 (UTC)

original用在CGroupViewer。--Xiplus#Talk 2021年3月12日 (五) 01:58 (UTC)

用I出于local的函数必定在开头，理解不难。用Item也好。@Lopullinen：代码编辑器模式下的模块编辑器，I是等宽字体，好像不太容易看错。不太明白是省略哪个参数，请提一下例子。--YFdyh000（留言） 2021年3月12日 (五) 04:44 (UTC)

@YFdyh000：original可以不填，比如{ type = "item" rule="zh-hans:大宇资讯; zh-hant:大宇資訊;" }, -- 修正過度轉换。當然這個需求不大重要，寫個公司英文名填充參數也没問題。I用Apple設備在編輯介面比較慘，但是一個字母的確有助于進一步壓縮長度。反正編輯者都是模仿抄寫的，I具體有什麽内涵也不緊要，當隨意起的名字就行；所以在想能不能换一個區分度比較大的字母（比如H）。--洛普利宁 2021年3月12日 (五) 05:28 (UTC)

Lopullinen啊对，想过这个情况（但后来忘了），值得考虑一下。T的区分度较高，但因字形就改用语义更模糊的T可能不合适，以及应不需要极力压减长度。H感觉更晦涩难懂了。1. 单加一个R或者Rule函数？2. 用if判断如传入""。3. Item(nil, "zh-...."), 就可以了，例子见Module:CGroup/Les_Misérables。--YFdyh000（留言） 2021年3月12日 (五) 05:54 (UTC)

YFdyh000那Item就好。（爲什麽我不習慣首字大寫，不過無所謂了）--洛普利宁 2021年3月12日 (五) 06:08 (UTC)

您一提醒也感觉不符常见的命名法。但小写有点像变量，大写开头也整齐，所以还是首字母大写吧。--YFdyh000（留言） 2021年3月12日 (五) 06:28 (UTC)

在這試驗了下，看{{CGroupViewer}}似乎是OK的。另外CSS能不能把目錄搞成每個二級目錄换一行？想用{{horizontal TOC}}壓縮目錄長度，結果又做的太超過了。--洛普利宁 2021年3月12日 (五) 18:19 (UTC)

感觉不容易调出令人满意的效果。模块:CGroup/Games/sandbox/doc当前这样吗，感觉还是挺乱的。如果二级标题有合适前缀，次级标题有缩进，可能更好一些。--YFdyh000（留言） 2021年3月12日 (五) 20:02 (UTC)

YFdyh000模拟分号/冒号语法那样的样式吗？ 感觉没啥好办法--洛普利宁 2021年3月12日 (五) 20:07 (UTC)

安排了冒号。标点旁有奇怪的空格没解决。如果用顿号，四五六...级标题的显示效果会变奇怪，得另修。规则暂未预防影响其他目录。--YFdyh000（留言） 2021年3月12日 (五) 20:35 (UTC)

這樣挺好了。標題文字本身也太長，我還需要縮短一下。--洛普利宁 2021年3月12日 (五) 20:40 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Lopullinen：如果您希望改目录版式，建议新开一个话题，方便继续讨论。--YFdyh000（留言） 2021年3月16日 (二) 01:50 (UTC)

YFdyh000不确定有多少转换组是一堆二级目录带一堆三级目录的。小转换组目录本来就没几个。IT、Music等的大转换组是按ABCDEFG分的，普通的{{horizontal TOC}}也够用。怀疑这种目录格式都没有什么泛用性……--洛普利宁 2021年3月16日 (二) 04:31 (UTC)

做個記錄：有些機器人可能會用到，例如咱家的（e.g., Wikipedia:字詞轉換處理/公共轉換組/*）。如果真要處理，麻煩最後請統一所有相關頁面，這邊才好重寫程式。 --Kanashimi（留言） 2021年3月13日 (六) 00:36 (UTC)

@Kanashimi：应该是都搞定了，模板保护的Unit和IT组提交了编辑请求。Unit和Medicine组多加了一个ItemD函数。WP:CGROUP我加了一些说明。过程中遇到没想过的desc属性，不过用的不多。以及original后置等写法，总之现在改成一样了，考虑过是否{o:''}之类的简写，但这样简写就不好读、意义不大了，也很容易语法出错。快弄完才想起AWB，不过我估计AWB不能提示语法出错。如果大规模，也可以JSLT提取。用到的部分正则表达式见注释。--YFdyh000（留言） 2021年3月16日 (二) 01:42 (UTC)

@YFdyh000：直接統一成這樣好了，會更簡潔且不用特殊處置：

local function Item(o, r, d) 
    return { type = 'item', original = o, rule = r, desc = d };
end

這個語法糖應該要寫入說明文件中（已完成），要不然有人又創造了其他用法，cewbot就讀不懂了...(cewbot採用JavaScript來解析lua。這邊基本上必須以JavaScript重寫所有函數，包括 Item()。) --Kanashimi（留言） 2021年3月16日 (二) 08:59 (UTC)

翻Module:CGroupViewer和Module:NoteTA都沒有看到使用desc的地方，究竟在哪？--Xiplus#Talk 2021年3月16日 (二) 10:29 (UTC)

原先就有的……memo用？ --Kanashimi（留言） 2021年3月16日 (二) 11:08 (UTC)

看起來可以用註解代替就好。--Xiplus#Talk 2021年3月16日 (二) 12:20 (UTC)

@YFdyh000：若無其他考量，例如必須在某個地方呈現描述，或許就改成註解即可？　 --Kanashimi（留言） 2021年3月16日 (二) 21:23 (UTC)

我没意见。印象中很久以前MediaWiki:Gadget-noteTA.js可以为规则追加自定义描述，但没能找到相关代码，可能早已失效。--YFdyh000（留言） 2021年3月16日 (二) 22:03 (UTC)

看起來似乎沒有其他意見。那就改了。 --Kanashimi（留言） 2021年3月19日 (五) 06:48 (UTC)

目前可以使用這份AWB設定檔進行批量替換。--Xiplus#Talk 2021年3月19日 (五) 09:14 (UTC)

@Kanashimi：格式以Module:CGroup/Medicine作為範本行嗎？--Xiplus#Talk 2021年3月23日 (二) 10:25 (UTC)

OK --Kanashimi（留言） 2021年3月23日 (二) 10:36 (UTC)

已全數按此範本轉換完成。--Xiplus#Talk 2021年3月26日 (五) 08:10 (UTC)

说起来，电子游戏专题先前有人在问为什么NoteTA早就变成模块实现了，仍然还有转换组不超过10个、单独项目不超过30个的限制。我看这个限制能否有办法去除？ --Milky·Defer 2021年3月17日 (三) 16:30 (UTC)

@MilkyDefer：所以这个限制体现在哪里？--YFdyh000（留言） 2021年3月18日 (四) 12:32 (UTC)

@YFdyh000：Module:NoteTA#L-59和Module:NoteTA#L-90--Milky·Defer 2021年3月18日 (四) 12:36 (UTC)

目前模块:NoteTA应该是转换组和规则是各`for` 30个。赞成作软限制，例如应用100个规则、20个组，对超过50个规则和10个组的条目各列一个维护分类（如NoteTA转换组过多的页面、NoteTA转换规则过多的页面）以维护和整合规则。--YFdyh000（留言） 2021年3月18日 (四) 12:47 (UTC)

能否將「新冠肺炎、新冠病毒、新冠疫苗」納入繁簡自動轉換或轉換組？

根據WP:CC19，已經明文規定條目內文是不能使用「新冠肺炎、新冠病毒、新冠疫苗」的，不過目前看到還有許多條目大量使用（如：2019冠狀病毒病中國大陸疫情、2020年3月中國），手動轉換也耗時，能不能將「新冠肺炎、新冠病毒、新冠疫苗」列入繁簡轉換的行列？--Nrya（留言） 2021年5月22日 (六) 17:49 (UTC)

繁簡轉換並非用作修正，而且極有可能導致過度轉換，故不支持。--【和平至上】💬 2021年5月22日 (六) 19:42 (UTC)

那寫入轉換組呢？--Nrya（留言） 2021年5月23日 (日) 03:28 (UTC)

附議。不知為何現在有不少編者希望使用轉換來修復錯誤/瑕疵/格式問題。--Yangwenbo99^{論 文} 2021年5月23日 (日) 08:58 (UTC)

• 会过度转换，特别是中国大陆很多专有名词里面是有“新冠”二字的 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月23日 (日) 06:46 (UTC)

同上，有過度轉換的問題。之前我留意到中國大陸用戶很活躍地進行手動替換，那就證明用戶逐個條目手動替換不是艱難的工作，因此好像也沒有納入繁簡自動轉換或轉換組的必要。SANMOSA _Σουέζ 2021年5月24日 (一) 00:52 (UTC)

• 這不就走回頭路了嗎。--Temp3600（留言） 2021年5月24日 (一) 03:55 (UTC)
• 用AWB轉換即可---Koala0090（留言） 2021年5月25日 (二) 09:15 (UTC)

F1公共转换组中，全名和姓的转换

本人最近在编辑关于F1的部分内容。目前F1公共转换组中，只有全名的转换，而无姓氏的转换。而我们在写相关内容时，一般只会在部分关键内容写每个车手的全名，而在具体描述比赛细节时（例如某圈两名车手之间的超车），显然不宜每一处都写全名。例如在2016年西班牙大奖赛中有如下内容：“雷克南追近前方的维斯塔潘，费尔南多·阿隆索的车辆在第47圈停到了3号弯边上，这场主场赛事在此画下句点。雷克南尝试追近至1秒差内，以启动减少空气阻力系统（DRS），此时，维特尔与他仍有8秒之差，里卡多暂居第4名。到了第57圈，里卡多够近足以开启DRS，但却未能顺利超车。三圈后，里卡多试图在进入1号弯时超车，但是，他因为太晚刹车而跑开，使得维特尔保住名次。当前方车手已经套圈慢车，科维亚特跑出他职业生涯及红牛二队的首个最快圈速，并且超越第10名的古铁雷斯。”这段话在地区词处理时就会出现凡是全名的就能转换、只写姓的就不转换这个问题。我注意到用户“Games1129”采用的方法是在每一处都人工加入转换。这样未必工作量太大，太过劳累，而且降低了代码的可读性。我希望能解决这个问题，让不论是全名还是姓氏都能“智能”地转化为各地用词。——超级核潜艇（留言） 2021年9月28日 (二) 13:15 (UTC)

模块只是半保护，可以尝试自行编辑Module:CGroup/F1（依葫芦画瓢）。如理解语法有困难请讲。--菲菇＠维基食用菌协会 2021年9月28日 (二) 16:35 (UTC)

音頻、音訊、錄音

煩請更改，香港繁體應為音訊非音頻！Hk2022（留言） 2022年5月7日 (六) 15:17 (UTC)

「王位繼承法令」和「皇位繼承法令」的轉換

我與用戶Joker Twins在「英國政治人物、英國政府與政治」中就《1701年王位繼承法令》、《2013年王位繼承法令》及《1937年王位繼承法令》的轉換產生分歧。我根據香港《官方法律程序條例》中「皇位的繼承」使用「皇位」，提出「王位」在香港繁體中應轉換為「皇位」。他堅持要刪去該轉換，認為法律只能使用「王位」，聲稱這個事關「法律的嚴謹性」。本人實在無法贊同。

既然香港社會及法律普遍使用「皇位」，按照常理理應加入轉換。沒有理由在其他場合可以使用「皇位」，法律中就只能使用「王位」。中文「王」、「皇」及英文「King」、「Emperor」原本皆屬不同概念，「王」與「King」的原本含義並不完全一致，翻譯時只是將相似的概念對應，不同地區的對應方式可能不同。香港自割讓予英國一直是在所有領域皆使用「英皇」、「英女皇」。香港總督接收新界公告中即使用「大英國大皇帝」。清廷與英國於1908年簽訂的《中英修訂藏印通商章程》中使用「大英國兼五印度大皇帝」。1928年《中英關稅條約》中有「大英國大皇帝」、「大英國全境兼印度大皇帝」。可見「王」、「皇」只是King的不同譯法，無所謂哪個更好，哪個更嚴謹。只是現今大陸及台灣通行「國王」、「女王」，香港通行「英皇」、「女皇」。認為該譯法「不嚴謹」難免有地域中心之嫌。

希望能夠在此達成共識，加入香港繁體「皇位繼承法令」的轉換。--Mosowai（留言） 2022年8月29日 (一) 20:03 (UTC)

这边人少，也许应移入互助客栈/条目探讨来讨论。关于争议的转换，我看到该转换组中已将女王、王后等在香港地区转换为“皇”，安妮 (英国女王)、英国王位继承等条目也被转换。如果这守认可，法律内容禁止转换会否不成立、反而导致用词不一致。对于专有名称、法条是否不能转换改字，我不确定。对方要求可靠来源，也合情理，"皇位繼承法" site:hk我看到8条结果，确实较少。其中香港情、中國心（高中）我不确定是哪本书、是否可靠。[1]“擔心當局推動修改《皇位繼承法》的進度”。"王位繼承法" site:hk则多一些。[2]“英國皇室及國會前年通過修改《王位繼承法》”等。--YFdyh000（留言） 2022年8月29日 (一) 22:09 (UTC)

思路：條目預儲公共轉換組中匹配的規則，減少載入時間

近年有些公共轉換組越來越大，導致所嵌入的各條目等頁面_{（爲便説明下稱「條目」但不限於條目）}載入越來越慢，爲人詬病。而若條目預先儲存公共轉換組中與條目中字詞相匹配的轉換規則，並適時更新：— Gohan 2024年3月12日 (二) 05:00 (UTC)

（以下劃有底綫的「匹配」為動詞）

• 【定時更新】條目若在最近7天無變更，恆常每隔7天探測1次所嵌入的公共轉換組有無變更，若公共轉換組有變更，則重新匹配轉換規則；若公共轉換組無變更，則不重新匹配轉換規則。
• 【觸發更新】條目一有變更，且距上次重新匹配超過24小時，則立即自動重新匹配所嵌入的公共轉換組歌轉換規則；若距上次重新匹配不足24小時，則不然，除非手按更新。
• 【手按更新】條目彈出界面可設「重新匹配」按鈕，可供每1小時按下1次。用戶若認爲條目中有字詞需要立即重新匹配以作轉換，可按此按鈕。可限制任一條目的任一公共轉換組的「重新匹配」按鈕在被按後1小時內凍結，不容再按，以防濫用。（本點若有技術困難，可暫緩部署）

如上，便可大幅減少載入時間，亦無須擔憂或限制公共轉換組過大。可先在最大的幾個公共轉換組試行，是否擴大應用可容商討。此外，現在彈出界面不能顯示公共轉換組中適用於所在條目的轉換規則，如上施行或可方便顯示，間接減少重複手工轉換規則。以上數字（7天、24小時、1小時、1次）純屬建議，可作變動。--— Gohan 2024年3月12日 (二) 05:00 (UTC)

技術上可行的話不反對。--冥王歐西里斯（留言） 2024年3月12日 (二) 05:27 (UTC)

理论上似乎可行。若如此的话，建议到时转换规则不知能否放到页面最下方？否则编辑时开头前面一大片转换规则实在不友好--百無一用是書生 (☎) 2024年3月12日 (二) 06:57 (UTC)

另外，个人感觉似乎不用这么复杂，写个bot，7天全部更新一次即可，即只需要【定時更新】，【手按更新】有的话更好，【觸發更新】没有太大必要。设想的流程是：建立一个模板，假设叫做noteTAcheck，如果一个页面需要人名和地名公共转换组，模板参数就是{{noteTAcheck|人名|地名}}，机器人通过这个模板和参数获取页面需要用到的公共转换组，并与全文匹配挑出实际用到的转换规则，直接放入文内（或通过模板参数的方式放入）。或者直接在NoteTA模板上修改（这样可能兼容性更好一些），增加一个参数pick，这个参数放入转换组中实际用到的转换规则，当使用pick参数时，G开头的参数无效。--百無一用是書生 (☎) 2024年3月12日 (二) 07:24 (UTC)

如果只有7天更新，沒有【觸發更新】、【手按更新】，有些編者會不會迫不及待，加入多餘而又不全的手工轉換規則？--— Gohan 2024年3月12日 (二) 10:53 (UTC)

如果设计的够健壮，不用担心这种问题--百無一用是書生 (☎) 2024年3月13日 (三) 03:30 (UTC)

各位技術高手可以隨時開始設計。在這方面在下無能爲力。--— Gohan 2024年3月13日 (三) 09:49 (UTC)

現行noteTA是從插入位置開始轉換，放在最下方就無法轉換；若改爲真正全文轉換，就會過度轉換消歧義頂注模板中的字詞。不過無論如何，預儲的公共轉換組規則不應放置在可供編輯的一般界面，以免編者可以修改而更加麻煩。或許可放在附帶文檔／子頁面？--— Gohan 2024年3月12日 (二) 10:53 (UTC)

如果是另外建立页面，可能需要改mw才行？--百無一用是書生 (☎) 2024年3月12日 (二) 11:44 (UTC)

例如类似于WP:编辑提示那样？--百無一用是書生 (☎) 2024年3月12日 (二) 11:44 (UTC)

您的意思是像WP:编辑提示一樣顯示還是像WP:编辑提示一樣另建頁面？--— Gohan 2024年3月12日 (二) 11:56 (UTC)

像WP:编辑提示一樣另建頁面--百無一用是書生 (☎) 2024年3月13日 (三) 03:29 (UTC)

看上去是不直接嵌入noteTA的公共转换组，是单独一个模板用来定义需要拉取的公共转换组名称，然后检测G组和被“嵌入”页面的更新触发，有一个触发的话，从设置的公共转换组中抽出和页面用词相符和项目，然后更新到一个对应专用页面来被“嵌入”页面去嵌入转换规则，并加上定时更新机制。检测被“嵌入”页面的更改（包括公共转换组的变化）相对容易，但反之可能存在问题，因为需要了解到哪些页面选择“嵌入”哪些公共转换组，可能需要借助“检测被‘嵌入’页面的更改”这个顺带获得并且有一个数据库记录谁“嵌入”过以便更新。从技术上来看似乎有一定复杂度。对于一些“大炮”公共转换组被为了“蚊子”而嵌入的情况比较实用意义。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月14日 (四) 12:44 (UTC)

设想太复杂了，只要在页面上通过一个指定的模板手工设定好要使用的公共转换组，然后写个bot定期轮询一遍这个指定模板的嵌入页面，找出匹配的转换规则就好了（每次覆写原有的规则就行，不需要记录）。至于是把检出的规则写入需要转换的页面，还是对应的专用页面可以再考虑。我这种设想可能不够更新及时，但是比较简单一些。另外，对应专用页面有个缺点就是要一直跟踪页面移动，否则页面一旦移动，可能就失效了（这里很难保证完全不跟丢页面的移动），或者不用页面名称，用pageid来处理对应页面问题可能更保险一点（正常情况下，页面移动不会改变pageid），但是根据mediawiki的说明，也不能100%保证不出问题。而直接把规则写入转换页面的话，最大问题是可能会造成头部内容大片的转换规则，非常不利于编辑。--百無一用是書生 (☎) 2024年3月14日 (四) 13:37 (UTC)

例如可以改造NoteTA模板为{{NoteTA|G1=IT|G2=Games|pageid=12345}}，当出现pageid参数时不调用G系列参数，然后人工或bot把从G1和G2转换组中与该页面匹配的规则挑出来，放入一个专门的模板（例如叫做{{NoteTA/pageid/12345}}）,页面只嵌入该模板中的转换规则。突然想到转换有时候有先后顺序问题，自动提取规则的做法看起来还要照顾到先后顺序...--百無一用是書生 (☎) 2024年3月14日 (四) 13:49 (UTC)

像這樣把規則放到另一個頁面可能會導致歷史版本轉換新出現問題。比如新版本條目去掉了某個需要轉換的詞彙，然後這個專門的頁面就會由機器人更新刪除相應規則，再看條目的舊版本這個詞彙就不轉換了。不過這應該不算大問題。——枰（留言） 2024年4月4日 (四) 02:31 (UTC)

我觉得有一定的技术成本。预览时最好能看到转换组效果，这或许可通过预览时自动填回转换组解决，但模板超限会更难避免，以及转换组生效位置，编辑章节等情形。用外部脚本实现转换组生效规则的检测，可能会比想象中的困难，包括规则生效顺序、章节编辑、模板嵌入等，如果要调用API来渲染和对比，同样增加服务器成本。对于观察生效组规则的变化可能是有益的，但冷门条目可能增加不少该机器人的编辑。--YFdyh000（留言） 2024年3月16日 (六) 18:55 (UTC)

或許試試「預覽」直接調用相應公共轉換組本體？不過，視覺化編輯沒有「預覽」選項，在一定程度上即為「預覽」，卻沒有字詞轉換效果；如果「預覽」不直接調用公共轉換組，反而拉近與視覺化編輯的落差。--— Gohan 2024年4月26日 (五) 03:40 (UTC)

建议先写出提取条目/章节使用过的字词转换规则/组规则的脚本来，再评估其他技术可行性。--YFdyh000（留言） 2024年3月16日 (六) 20:56 (UTC)

@YFdyh000 我用python写了一个原型，从公共转换组提取某个页面文本中会用到的转换规则，然后生成一个该页面专用的转换组模块，见[3]。--百無一用是書生 (☎) 2024年3月28日 (四) 12:26 (UTC)

按照我的思路做了一下测试[4],，似乎看起来可行。只是转换组的相关模块没有全搞明白，比如[5]这个红字重定向我就没找到是哪个地方控制的...--百無一用是書生 (☎) 2024年3月30日 (六) 12:22 (UTC)

找到了，原来是MediaWiki:Scribunto-doc-page-does-not-exist控制的--百無一用是書生 (☎) 2024年3月30日 (六) 12:32 (UTC)

做了一个简单的对比：同一篇内容，三个转换组，未精简过的转换[6],精简过的转换[7]，展开后大小变化非常明显（从280,741减小到了14,423），解析性能提高显著--百無一用是書生 (☎) 2024年3月30日 (六) 12:59 (UTC)

听上去不错，虽然还没完全懂。转换表中zh-tw:連線;的简体有差异，是操作失误吗。--YFdyh000（留言） 2024年3月30日 (六) 23:10 (UTC)

“連線”的那个问题，因为是用脚本处理的，脚本匹配规则有问题没有完全匹配对（lua的注释“--”被删掉了），是操作失误。

实现方式就是：读取页面上NoteTA模板中列出的转换组，从转换组中挑出实际在该页面中使用的转换词，然后放到一个新的转换组模块里，例如Module:CGroup/pageid/7629，这个模块只用于该页面的转换，并且屏蔽掉其他转换组对该页面的转换。7629是该页面的pageid，若非特殊原因，pageid不会因移动页面或删除恢复页面而变。如果没有Module:CGroup/pageid/7629存在，则使用NoteTA模板中列出的转换组进行转换（即与现在一样）。

目前在测试wiki上测试的结果看，转换相关的lua脚本和模板这一块，可以在目前的基础上稍微修改即可实现（而且尽量不使用高开销的语法），新的针对单个页面的转换组（例如Module:CGroup/pageid/7629）可以手工建立也可以通过bot脚本自动创建和更新（也可以用js小工具的方式半自动实现，如果有人愿意写js脚本的话）。NoteTA小工具目前来看似乎不需要做修改（不是很确定）--百無一用是書生 (☎) 2024年3月31日 (日) 11:59 (UTC)

直接使用lua脚本似乎也能做到，但是不清楚性能上会不会有什么问题。毕竟这个提议的初衷就是解决转换组太庞大所带来的性能问题--百無一用是書生 (☎) 2024年3月31日 (日) 12:07 (UTC)

如果某个条目内只用到了一个词语转换，为此建立一个pageid页面是否有些浪费，本来较少的转换就可以放在Noteta表格中，且便于修订。--Kethyga（留言） 2024年4月15日 (一) 01:23 (UTC)

不是太理解你的意思。目前我的想法是pageid页面只用于处理转换组的部分，其他单独转换不处理。如果某个条目只用到了转换组中的一个转换规则，那么把这条转换规则捡出到pageid页面肯定能够大大降低性能开销（因为不用载入整个转换组的数百条规则）--百無一用是書生 (☎) 2024年4月15日 (一) 02:49 (UTC)

如果加入了公共转换组，但是未匹配到任何规则，感觉不建立pageid比较好，如果按照你的方法似乎未匹配到也要建？；如果匹配到较少的规则（1至2条），如果可以修改Noteta的话，可以增加1个参数，表示不加载该转换组的内容，或许你的方法不用修改Noteta。--Kethyga（留言） 2024年4月15日 (一) 03:15 (UTC)

未匹配到规则不建立pageid是个好建议！但需要Noteta加一个参数来表示，或者未匹配到规则就直接删掉Noteta参数中的相应转换组更简单一些（还能起到防止滥用转换组的作用）；匹配较少的话，可以再加一个参数，把匹配到的规则写在这个参数里，但是增加了bot脚本和维护的复杂度，不确定是否值当，而且随着条目的完善，可能较少的匹配会慢慢增多到较多的匹配，最后还是要有个pageid。。。

总之，我之前的想法是尽量不让bot编辑使用了Noteta的页面，尽量减少bot编辑的影响...--百無一用是書生 (☎) 2024年4月15日 (一) 04:12 (UTC)

能否實現對導航模板中的字詞的轉換？測試頁面TEX、Wii遙控器都無真正的導航模板，看不出成效。當然，不在條目相應子頁面預儲導航模板的規則，而在導航模板相應子頁面預儲亦無不可。--— Gohan 2024年4月6日 (六) 09:27 (UTC)

我想最终是应该把整个页面的wikitext解析成html后，再匹配并捡出转换规则，测试页面只是测试了一下整体思路是否可行，许多细节都没处理--百無一用是書生 (☎) 2024年4月15日 (一) 02:52 (UTC)

书生的实现很棒。对于【触发更新】，可以让bot检测公共转换组的更新后更新页面转换组。另外需要商讨，页面转换组页面是否应允许编者自填一部分规则（也允许编者纯手工维护一个条目的规则），这样可进一步减少条目内的代码。还有一些小作品页面（如物种等），可能只用得上少量规则，建立子页面恐没有必要。社群需要确认建立子页面的门槛（是按规则数？还是对页面大小的影响？）。--PexEric 💬|📝 2024年4月5日 (五) 06:00 (UTC)

其实，如果采用检测公共转换组更新的触发更新，除了第一次建立子页面（初始化），也不需要定时更新。--PexEric 💬|📝 2024年4月5日 (五) 06:04 (UTC)

如果頁面、公共轉換組兩端都有【觸發更新】，那麽的確不需要【定時更新】。如果暫時沒有任何【觸發更新】，那麽【定時更新】或許縮短至3天一次。--— Gohan 2024年4月6日 (六) 09:29 (UTC)

手工这个的话，似乎如何让程序自动判断哪些是人工特意添加的比较困难？除非是有能够对自动和手工进行区分的标记--百無一用是書生 (☎) 2024年4月5日 (五) 11:07 (UTC)

像第83届奥斯卡金像奖这样的条目，里面塞了4个NoteTA，如果不放到子页面对编辑确实挺不便的。--PexEric 💬|📝 2024年4月6日 (六) 05:21 (UTC)

如此情況甚少。而且第83届奥斯卡金像奖NoteTA許多規則與公共轉換組重複，只因有缺漏或cn／hans之別而未被機械人清除。掃視格式整齊NoteTA規則並迅速下拉至下方，未至於令人生厭。--— Gohan 2024年4月6日 (六) 09:30 (UTC)

「頁面轉換組頁面」是指子頁面嗎？編者可以照舊自填條目內手工轉換規則（以及公共轉換組），如再開放編輯儲存公共轉換組的子頁面，恐怕造成更多迷惑——一般編者會懷疑子頁面與前二者（條目內手工轉換規則、公共轉換組）的關係如何。如果不建子頁面，少有更新的條目的編輯歷史大概會充斥此項機械人的更新記錄（假定可匹配的轉換規則頻繁變更），不利於追蹤人類或其他機械人的編輯活動。全部建立子頁面無害，成本也不高。--— Gohan 2024年4月6日 (六) 09:28 (UTC)

@Shizhao：請問近期進展如何？--— Gohan 2024年7月7日 (日) 08:54 (UTC)

為了泛用性，是否也需考慮採用分割公共轉換組這種方式? 採用子頁面的技術成本、伺服器似乎負擔不小(考量頁面更新與可能會有大量的子頁面)...--Kanashimi（留言） 2024年7月7日 (日) 09:53 (UTC)

我只是试了一下可行性，没再做什么。@Kanashimi，其实这就是相当于分割公共轉換組，只是分割成了针对单个页面的公共轉換組，原来加载的转换组规则可能几百条，这样处理后就能大大简化，不少情况下估计能简化到十几条到几十条，甚至就几条。弊端就是不依赖于机器人，人力很难维护，以及可能做不到所见即所得。伺服器负担方面，我倒觉得除了多了很多页面，计算量应该是大为减小了（还可能减少一部分模板超限的问题）--百無一用是書生 (☎) 2024年7月7日 (日) 11:57 (UTC)

假如太大的公共轉換組分割成10個20個，是否就不必創建太多子頁面，增加泛用性，並且達到減輕伺服器負擔的目的?如此亦可不依賴於機器人--Kanashimi（留言） 2024年7月7日 (日) 12:56 (UTC)

不懂就問，如果一個公共轉換組拆分成10個，那麽原有所對應的該轉換組子頁面也會變成多個，會減輕負擔嗎？--— Gohan 2024年7月7日 (日) 23:38 (UTC)

所以現在最大的問題是載入的次數或載入的大小呢？--Kanashimi（留言） 2024年7月8日 (一) 01:00 (UTC)

我其实对载入模板的后台处理机制不是很熟悉，但我依据目前我所了解的，似乎需要渲染的内容数量影响最大？我的处理方案，相当于减少了原来页面加载公共转换组数量-1个模板，因为只要加载一个单页面的转换组模板就可以了，同时转换数量也大为降低，不用像现在这样，200条规则的转换组可能在某个页面只有2条转换规则有用。拆分成多个转换组的方案，可能会遇到原来一个转换组模板能解决的，可能变成了几个转换组模板才能解决（比如三个转换规则被分别拆到了三个转换组里）。另外，依赖机器人方面，或许可以做成js小工具作为辅助，用户点击几下就能生成/更新一个单页面转换组，这样就不必完全依赖机器人（前提是有人愿意写一个这样的脚本）--百無一用是書生 (☎) 2024年7月8日 (一) 03:35 (UTC)

PS：我这个方案，如果担心修改转换组后无法在页面中看到转换效果的话，可以各转换组模板设计一个开关，off的时候仍然使用原来的转换组模式，on的时候则转为单页面转换--百無一用是書生 (☎) 2024年7月10日 (三) 08:40 (UTC)

理解轉換組拆分之後全組重滾（重新匹配）所耗費資源將會減少。但如今若無機械人協助檢測頁面有何字詞匹配拆分後的各轉換組並替換轉換組代碼，具備拆分條件的大型公共轉換組所剩不多（或許只有綱目分明、甚少提及其他綱目的鳥類條目及其轉換組）；若由人力判斷並替換轉換組代碼，難免遺漏導致原有轉換效果大打折扣。而且，「預儲轉換規則」施行之後，亦能減輕伺服器負擔，對讀者而言載入時間也減少，與拆不拆分大型轉換組並不衝突。此外，與拆分相似、但更可行的想法請見下節「#交集板塊：減少重複、節省資源」。--— Gohan 2024年7月10日 (三) 07:10 (UTC)

资源充足的条目可以考虑把压力转移给Lua模组，也就是让Module:NoteTA更智慧，只加载条目中用到的转换规则，代码见Module:沙盒/GnolizX/NoteTA。看效果，User:GnolizX/肖申克的救赎/新：

Post‐expand include size: 647267/2097152 bytes

Lua time usage: 1.732/10.000 seconds

Lua memory usage: 30646218/52428800 bytes

可以对比User:GnolizX/肖申克的救赎/旧，两个页面转换后的内容是一致的：

Post‐expand include size: 1764141/2097152 bytes

Lua time usage: 0.859/10.000 seconds

Lua memory usage: 20785293/52428800 bytes

于是用充足的Lua记忆体与紧张的模板展开大小进行了交换。

这个功能还可以迁移到Module:沙盒/GnolizX/CGroupViewer，汉漢图标打开的速度也能变快很多，不用再一股脑地把所有的规则全部加载出来。看效果：User:GnolizX/CGroupViewer。

至于条目下方的导航模板可以考虑用机器人更新，把CGroupViewer稍微改造一下（-{D|改成-{H|等等）就可以自动获取匹配到的规则了。--GnolizX（留言） 2024年8月26日 (一) 16:12 (UTC)

这个想法不错！--百無一用是書生 (☎) 2024年8月27日 (二) 02:00 (UTC)

極好！期待早日付諸現實！--— Gohan 2024年10月6日 (日) 09:00 (UTC)

话说这个话题还有讨论么？我觉得可以在Category:引用模板后大小超过限制的页面先小范围试用一下。导航模板可以先不管，反正这个分类里的本来就显示不了几个。--GnolizX（留言） 2024年11月13日 (三) 12:19 (UTC)

可以尝试--百無一用是書生 (☎) 2024年11月15日 (五) 04:05 (UTC)

敬請試行，迫不及待。--— Gohan 2024年11月15日 (五) 09:58 (UTC)

我从分类里面挑了五十个左右把NoteTA改成Template:NoteTA-lite，比较了前后的差异（结果），只有嵌入的内容是不一致的（比如漫威电影宇宙#電影_2用的#section、2022年至2023年西班牙足球甲級聯賽的{2022年至2023年西班牙足球甲級聯賽積分榜}和加泰罗尼亚），目前看来感觉效果还不错（比如2023年欧洲歌唱大赛的参考资料已经能全部显示了）。--GnolizX（留言） 2024年11月16日 (六) 06:14 (UTC)

甚佳，距離試行還需哪些步驟？--— Gohan 2024年11月18日 (一) 02:36 (UTC)

---

已提交RFC，希望获得更多共识后采取行动--百無一用是書生 (☎) 2024年12月15日 (日) 08:57 (UTC)

抽查幾條目，除導航模板外，轉換成效不亞於原狀。支持進一步推廣。--— Gohan 2024年12月15日 (日) 09:24 (UTC)

交集板塊：減少重複、節省資源

不少轉換規同時存在於兩個或多個公共轉換組，浪費資源，對此更新修正疲於奔波、亦浪費人力。不如設置可容多個公共轉換組嵌入的「交叉板塊」——相當於次級的公共轉換組。例如，Movie組、迪士尼組、Pixar組之間設置「交集板塊」「迪士尼-Pixar長片」，Movie組、迪士尼組之間設置「交集板塊」「迪士尼非Pixar長片」，Movie組、Pixar組之間設置「交集板塊」「Pixar非迪士尼長片」；如此，任何一個迪士尼或Pixar出品的電影長片的轉換規則都應收錄在以上三個「交集板塊」之一，而移出Movie組、迪士尼組、Pixar組頁面本身，最終轉換效果不變。另外，在提交公共轉換組編輯時，亦可警告不應增加已收錄在屬於本公共轉換組的「交集板塊」的字詞或要求復查。希望儘早提出此想法，以免導致上節「預儲」設計細節日後大改。--— Gohan 2024年7月10日 (三) 07:05 (UTC)

@神秘悟饭：应该允许转换组无限再分（套娃）。如“电影”下可以按照各国电影、各题材或者各年代细分组合，子转换组应成为子页面。让各个专题自己决定分类标准和最小单位。--PexEric💬|📝 2024年7月22日 (一) 15:14 (UTC)

其实，像是电影这种似乎可以交给机器人更新，只要子转换组有对应的分类，如Cat:迪士尼動畫，机器人可以跑一遍每个条目的标题转换然后生成一份转换组。--PexEric💬|📝 2024年7月22日 (一) 15:17 (UTC)

機械人整理是好主意，但仍需人力對照，以免過度轉換。例如，有些標題（轉換規則）的地區詞需要括注，實際沒有括注。--— Gohan 2024年7月23日 (二) 08:35 (UTC)

各年代分类应该是最科学的。电影奖项之类的条目（基本上也是这些条目需要转换组）直接拿一份其年代知名电影的名称、相关知名人物的地区译名就完事了。--PexEric💬|📝 2024年7月22日 (一) 15:21 (UTC)

如果一個轉換組拆成多個板塊，嵌入原轉換組代碼的頁面的顯示（字詞轉換）效果，倒是有利無弊。@PexEric：--— Gohan 2024年7月23日 (二) 08:34 (UTC)

這技術上可行？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月21日 (三) 08:25 (UTC)

技術上只需在調用一轉換組的同時調用另一轉換組（或稱交集版塊）即可，存儲上轉換組與交集版塊分離。説是交集，技術上完全不必是交集。--— Gohan 2024年8月21日 (三) 10:29 (UTC)

这似乎和上面 @GnolizX提到的方案差不多？--百無一用是書生 (☎) 2024年9月12日 (四) 03:28 (UTC)

不同之處在於，此提議能減少並方便統一編輯多個公共轉換組重複的部分？--— Gohan 2024年10月6日 (日) 08:59 (UTC)

为何Module:CGroup/Disney和Module:CGroup/Pixar里面的电影名字没有移动到Module:CGroup/Movie，是出于什么考虑呢？--GnolizX（留言） 2024年10月19日 (六) 19:03 (UTC)

此情此景早已存在，難以參透原由。轉移或許可取，閣下可付行。不過，類似重複情況並不罕有。--— Gohan 2024年10月23日 (三) 09:21 (UTC)

一个想法

我们是否可以通过链入条目的转换来增加当前条目的转换规则，比如蒂埃里·亨利（Thierry Henry）链入阿森纳（Arsenal），是否可以把Arsenal的转换（-{zh-cn:阿森纳;zh-sg:阿申纳;zh-tw:兵工廠;zh-hk:阿仙奴;}-）加入到亨利条目，本意同GnolizX提出的只加载条目中用到的转换规则--Kethyga（留言） 2024年9月12日 (四) 03:26 (UTC)

好像目前lua做不到这点？--百無一用是書生 (☎) 2024年10月20日 (日) 11:36 (UTC)