Sorry for missing this. I just created a project for the extension and moved this task to it.

@Samwilson Awesome, thanks! I just listed you as the maintainer at the extension's documentation page (diff). To get +2 rights, apparently you have to request them yourself, see https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Requesting_Gerrit_privileges If you file a request, I'll support it. Cheers!

Hi! I was able to reproduce the bug and verify the fix without apparent loss of functionality, so I just +2 the change and Jenkins merged it. Thanks everyone!

@Krinkle Hi! Same thing to T430406 seems to be happening here.

In T411834#12070018, @stjn wrote:

In T411834#11598784, @Amire80 wrote:

What it really needs to be expanded to is templates.

While I agree with some of your scepticism, I think overall we should encourage people not to write complex wikitext templates in favour of writing them with Lua (or other programming languages if we ever so choose and not wikitext soup), so this proposal technically satisfies that need. Global templates at that point could function just as wrappers around Produnto-based modules.

Translations for this project done via translatewiki.net carry the GPL-2.0 license that isn't currently accepted for translation tables in Commons, and even if it where, it requires attribution to the authors, which would be doable via the "source" parameter of translation tables but is kind of hacky. So instead of dealing with these complications, I just removed the source code from the Gerrit repo, leaving only the i18n files (change). This solves the issue of having the source code in two places, which was what actually bothered me the most.

Translations for this project done via translatewiki.net carry the GPL-3.0 license that isn't currently accepted for translation tables in Commons, and even if it where, it requires attribution to the authors, which would be doable via the "source" parameter of translation tables but is kind of hacky. So instead of dealing with these complications, I just removed the source code from the Gerrit repo, leaving only the i18n files (change). This solves the issue of having the source code in two places, which was what actually bothered me the most.

@TimWu007 Could you share the exact steps you follow to reproduce the issue? I tried a few random articles but nothing. Also, what browser are you using?

AFAIK, this issue happened in an old version of the gadget.

A simple UI for this feature would be adding an (optional) field next to "Master wiki" that reads "Target wiki". It would be nice to have it auto-suggest valid ids.

A good UI would be to have an "empty row" at the bottom of the table, with a field to enter the id of the new wiki (that auto-suggests valid ids), and a Create button in the Action column.

Two strategies would be contacting active module developers and preemptively syncing high-profile modules.

A system similar to Categorizator where a translation table is hosted at Commons is probably the best approach, per being simple and keeping everything on-wiki.

This should be easy to fix once Parsoid is fully deployed for all read views (T55784).

Supporting line-breaks is not trivial because the current regex relies on them to delimit paragraphs.

This feature would really only be useful together with a suggestion system. The algorithm could work along these lines:

The suggestion algorithm could work thus:

Perhaps the current Lookup field could be changed for a MultiselectLookup, and all the categories the page is currently in could be listed (and edited!) there. This would greatly generalize the functionality of Categorizator, but perhaps too much, to the point it would become more difficult to understand and use. It doesn't make much sense to edit all the categories of a page while visiting a specific category page. The concept behind Categorizator is we're "editing the category", not the page. If we wanted to edit all the categories of a page, we'd use HotCat and do it from the page itself.

Categorizator should probably notify the user of what happened. Else if they check their contributions, or the page history, they will be confused.

Ok, no worries. Just for reference though, the real world use case is when you want to show the entire world map, but color only a few countries. If you don't set latitiude=0 longitude=0 and zoom=0, the map will automatically center around the colored countries, not the full map. You can set zoom=1, but that will increase the zoom level and isn't always acceptable. I encountered this issue while developing Module:ChoroplethMap, and solved it by defining an invisible square the size of the world, to force the map to center around it.

If this feature is implemented, it may one day cease to work if T296847 is resolved in a way that blocks requests to external LLMs.

This feature was first proposed at https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_AI_Tools#AI_aid_for_citations