维基百科讨论:字词转换处理/公共转换组

关于公共转换组

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助。

--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)[回复]

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他/存档/2019年11月。

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

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

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

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

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

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

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

感谢！

西瓜玩偶（留言） 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:互助客栈/其他。执行者：Jimmy-bot（留言） 2019年12月14日 (六) 00: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" ？

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年4月5日 (一) 08:14 (UTC)。[回复]

目前定义转换项时，需要填写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( 内容 )是否要留空格。--YF dyh000（留言） 2021年3月11日 (四) 08:07 (UTC)[回复]

目前修改Module:CGroup/泰国人名和Module:CGroup/People后未见异常。鉴于只是格式调整且易于回退，如果3日内无反对，计划手动转换当前的公共转换组模块到此格式（不含模板和重定向）。--YF dyh000（留言） 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是等宽字体，好像不太容易看错。不太明白是省略哪个参数，请提一下例子。--YF dyh000（留言） 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)[回复]

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

那Item就好。（为什么我不习惯首字大写，不过无所谓了）--洛普利宁 2021年3月12日 (五) 06:08 (UTC)[回复]

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

在这试验了下，看{{CGroupViewer}}似乎是OK的。另外CSS能不能把目录搞成每个二级目录换一行？想用{{horizontal TOC}}压缩目录长度，结果又做的太超过了。--洛普利宁 2021年3月12日 (五) 18:19 (UTC)[回复]

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

模拟分号/冒号语法那样的样式吗？感觉没啥好办法

--洛普利宁 2021年3月12日 (五) 20:07 (UTC)[回复]

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

这样挺好了。标题文字本身也太长，我还需要缩短一下。--洛普利宁 2021年3月12日 (五) 20:40 (UTC)[回复]

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

不确定有多少转换组是一堆二级目录带一堆三级目录的。小转换组目录本来就没几个。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提取。用到的部分正则表达式见注释。--YF dyh000（留言） 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可以为规则追加自定义描述，但没能找到相关代码，可能早已失效。--YF dyh000（留言） 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：所以这个限制体现在哪里？--YF dyh000（留言） 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转换规则过多的页面）以维护和整合规则。--YF dyh000（留言） 2021年3月18日 (四) 12:47 (UTC)[回复]

能否将“新冠肺炎、新冠病毒、新冠疫苗”纳入繁简自动转换或转换组？

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2021年6月12日 (六) 08:14 (UTC)。[回复]

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行人：Eric Liu_{创造は生命（留言．留名．学生会）} 2021年6月2日 (三) 03:25 (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)[回复]

同上，有过度转换的问题。之前我留意到中国大陆用户很活跃地进行手动替换，那就证明用户逐个条目手动替换不是艰难的工作，因此好像也没有纳入繁简自动转换或转换组的必要。SAN MO SA _Σουέζ 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]“英国皇室及国会前年通过修改《王位继承法》”等。--YF dyh000（留言） 2022年8月29日 (一) 22:09 (UTC)[回复]

思路：条目预储公共转换组中匹配的规则，减少载入时间

诚邀加入回馈请求系统。

有编者正就本议题征求社群意见。本页已经新增至以下列表：

维基百科技术议题与模板

当讨论结束时，请移除本标签以将本页从征求意见列表中移除。若讨论已30日无人回应（按最后签名时间计算），机器人会自动将此标签移除。

近年有些公共转换组越来越大，导致所嵌入的各条目等页面_{（为便说明下称“条目”但不限于条目）}载入越来越慢，为人诟病。而若条目预先储存公共转换组中与条目中字词相匹配的转换规则，并适时更新：— 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来渲染和对比，同样增加服务器成本。对于观察生效组规则的变化可能是有益的，但冷门条目可能增加不少该机器人的编辑。--YF dyh000（留言） 2024年3月16日 (六) 18:55 (UTC)[回复]

或许试试“预览”直接调用相应公共转换组本体？不过，视觉化编辑没有“预览”选项，在一定程度上即为“预览”，却没有字词转换效果；如果“预览”不直接调用公共转换组，反而拉近与视觉化编辑的落差。--— Gohan 2024年4月26日 (五) 03:40 (UTC)[回复]

建议先写出提取条目/章节使用过的字词转换规则/组规则的脚本来，再评估其他技术可行性。--YF dyh000（留言） 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:連線;的简体有差异，是操作失误吗。--YF dyh000（留言） 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)[回复]

@GnolizX：

是否这样修改即可？

另，导航模板的改造那个没太理解，能否详细说明一下？--百无一用是书生 (☎) 2024年12月29日 (日) 10:22 (UTC)[回复]

如果只要减少 NoteTA 展开大小的话，改 Module:NoteTA 和 Template:NoteTA 就行了，CGroupViewer 不用改。因为关于导航模板我原来想的是借助 CGroupViewer 这样获取：API沙盒，去掉 "本文使用" "原文" "当前显示为"、把 -{D| 改成 -{H|。但是又一想其实这样就行了：API沙盒。

Module:沙盒/GnolizX/CGroupViewer 是我从上述修改联想到的拓展功能（点击“汉漢”图标也可以只显示匹配到的规则），只是提前写出来看一下效果。--GnolizX（留言） 2024年12月29日 (日) 11:40 (UTC)[回复]

只显示匹配到的规则我觉得挺好的，所有规则展示一是慢，二是太多与页面无关规则--百无一用是书生 (☎) 2024年12月30日 (一) 03:11 (UTC)[回复]

这个功能除了修改 Module:CGroupViewer，还需要把 MediaWiki:Gadget-noteTA.js#L-249 从

wikitext += '{{#invoke:CGroupViewer|dialog|' + $ele.attr('data-noteta-group') + '}}\n';

改成

wikitext += '{{#invoke:CGroupViewer|dialog|' + $ele.attr('data-noteta-group') + '|' + actualTitle + '}}\n';

--GnolizX（留言） 2024年12月30日 (一) 11:13 (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)[回复]