I feel like the Journal icon has taken a step for the worse:

@MusikAnimal I see v6 modules have been renamed. Does this affect user scripts and gadgets? If it does, then when will the change be deployed? There are quite a few scripts that would need updating.

@Bhsd Thanks. Since I'm using quite a lot of scripts, I suppose I'll have to ask their maintainers one by one.

In T6055#11706530, @mszwarc wrote:

I have an idea of how to implement that in the backfill script.

That's a log entry for permissions on metawiki. Log entries for interwiki rights changes don't move when a user is renamed [...]

@MGChecker That's not true. At the time of this log entry, the user now known as Veritas Sapientiae was named Hide on Rosé, and yet the log shows the current name rather than the old one.

@mszwarc What happens if the old target user was renamed? For example, A09 granted adminship at zghwiki to Lhoussine AIT TAYFST, who was then renamed to Lhoussine Bentayfaste. As I understand the script, it would create a log entry for the non-existent Lhoussine AIT TAYFST rather than Lhoussine Bentayfaste.

In T419187#11685507, @Tgr wrote:

why would a compromised or malicious interfaceadmin account mess with user scripts, rather than site scripts?

@Bhsd Allowing configuring the behaviour of mw.addWikiEditor sounds good. Please do.

By the way, I have another question regarding this note in the change message:

@Bhsd I have a script that makes use of the CodeMirror extension's API. it might add more than one editor to the same document. That's beside the point, however. The problem is that there must not be any two elements with the same ID. That is, IDs must be unique.

The new jquery.wikiEditor.resizingdragbar module added in this change has a small problem: It assigns an ID for the resize bar, but it isn't necessarily true that there can only be one such bar in the entire document. Pinging @Bhsd as the owner of the change.

I read that task and it seems to me that only one of the concerns applies to this new group: it won't be possible to override the automatic assignment. I don't really understand why that would be desirable, can you explain?

What permissions, exactly, will this group contain? I assume "higher rate limits" means apihighlimits and not noratelimit. If it's just the former, then wouldn't apihighlimits-requestor suffice? Several bots have been granted that group already.

The "history" links now look a little bit out of touch with "diff", "cur", "prev", "contribs", as Krinkle has noted above. I think it would have been better to change enhancedrc-history to "hist" and not hist to "history".

The repository is probably this one on Wikimedia's GitLab instance.

Monkeypatchable with:

@matmarex @MusikAnimal The bug doesn't appear to be fixed. I can still reproduce it. I'm using Chrome 143, if that makes a difference.

I went ahead and created a user script. There are a few rough edges, but it is generally usable.

For the record, this change affects several user scripts, in addition to the aforementioned gadgets.

@Nirmos I don't see how T91169 has anything to do with this. Templates and links don't work at all on JSON pages, yet people can still request for their deletion, via either their talk pages or the (interface) administrators' noticeboard.

Appears to have been caused by ad4d59c, which fixes T330941. In particular, the logic here is wrong:

@Ladsgroup Now it's running at just 18 pages per minute. Did something happen?

@Ladsgroup Thanks a lot for your help on this. Might I ask that the bot be sped up? The consensus is that we want the task to be done as soon as possible.

@Tacsipacsi Good point. That's one new thing I learn today.

@Nikerabbit I'm aware of {{#tag}}. The problem is not that I don't know how to include <translate> tags in a syntax-highlighted block, but that the <nowiki>-like-ness of <syntaxhighlight> is not recognized correctly.

See also m:User:NguoiDungKhongDinhDanh/IPAutoReveal.js.

(Please ignore 1193529, which was superseded by 1193530.)

Are you looking for action=paraminfo?

So if I were to write the following some time ago I would also get a broken result?

Table syntax has higher precedence than the file link, in the legacy parser.

This seems to be half-resolved as wikitext was recently added to Pygments in T29828. As for regex, it has many flavors and syntaxhighlighting depends heavily on that. For example, \z means the end of the string in PCRE (a special token), but a literal z in ECMAScript (plain text).

Yep, done that. Thanks for the suggestion.

To whoever monitoring this: I guess that an userscript of mine (and I, who wrote and installed it) caused this error by calling mw.loader.using(['ext.codeEditor']) on pages without an editor, such as Special:Contribs. I must say, however, that it acts as a script instead of a module, unlike most others that can be loaded via mw.loader, is not really a good thing.

If I understand correctly, you are trying to remove leading and trailing whitespaces by using a Lua pattern (not a RegExp, mind you) and the string.match/mw.ustring.match functions:

line = '    foo bar    '
print(line:match('^%s*(.+)%s*$')) -- 'foo bar    '

The + quantifier is greedy; it captures everything it can. Since . matches all characters, including whitespaces, nothing is given back to %s*$. The only non-greedy quantifier in Lua is -, and in this case it works well:

greedy = '^%s*(.+)%s*$'
lazy   = '^%s*(.-)%s*$'