維基百科討論:字詞轉換處理/公共轉換組

關於公共轉換組

--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)

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

不少轉換規同時存在於兩個或多個公共轉換組，浪費資源，對此更新修正疲於奔波、亦浪費人力。不如設置可容多個公共轉換組嵌入的「交叉板塊」——相當於次級的公共轉換組。例如，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)

一個想法

我們是否可以通過鏈入條目的轉換來增加當前條目的轉換規則，比如泰亞利·亨利zh-tw:蒂埃里·亨利（Thierry Henry）鏈入阿仙奴zh-sg:阿申納（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)