In T419152#11684577, @MBH wrote:

Rarely should a regular user need to go above 10 edits per minute

This is wrong for rollbacks. Rolling back mass inconsensus edits or bot errors requires making hundreds of edits with a rate more than a 1 edit / sec.

In T419152#11682583, @Bugreporter wrote:

Normal users are limited to 90 edits/minute. However, sysops, bots (except bots in Wikidata), account creators, global rollbackers, global sysops, stewards and staffs have no rate limit.

There were up to 35 edits per minute, which is usually the max I get using a bot account. Should the action rate be limited somehow, or an increased edit rate requested from the software before any mass edits, and granted for a limited time?

Two more examples

@Johannnes89 Thanks. Some old habits will be hard to change. That's why I'm suggesting that we at least enable the collapsing+collapsed option by default, in some nice way that will include a configurable title for the collapsed container box.

Seems to be working now, closing.

Per @cscott at Gerrit:

• This is still waiting for a test case added to test/parser/parserTests.txt -- search for "french spaces". The test case "French spaces in wikitext" is a good start, but note also the tests in definition lists, and with surrounding span tags.

Duplicate of T330386?

On mobile it gets even worse: it's animated, and after a few seconds it covers Media viewer's own exit button

Desktop "viewers" from countries where few people speak the language – the Philippines, India, Japan:
https://stats.wikimedia.org/#/hr.wikipedia.org/reading/page-views-by-country/normal|map|last-month|(access)~desktop*mobile-app*mobile-web|monthly
https://stats.wikimedia.org/#/hr.wikipedia.org/reading/unique-devices/normal|line|1-year|access-site~mobile-site*desktop-site|daily

Must be the same thing as T412655

I hope this can be fixed soon. It makes things look and feel so, let's say, unprofessional.

Yeah, it has to do with the font size choice. The cursor shift is most pronounced when a space is typed in.
In Chrome, when the first word is followed by a space, the word is shown in two sizes. That can be undone by typing in a backspace.

Thanks all for brainstorming your ideas. I didn't want to propose any radical changes to the current scheme, but keep it coming.

Much needed in some languages for symbols that are unavailable on most mobile device keyboards, such as » « „ ” – —

@Mvolz That's what I feared, though I could not imagine why it would change anything in the URL given to it.
I've created a translator for web2cit https://meta.wikimedia.org/wiki/Web2Cit/data/hr/enciklopedija/www/templates.json, which we have enabled for all users on hrwiki (though some still pick the first option, plain Citoid, it seems). Creating one for Zotero would be too much work for me (?), and I feel it would take ages to see it working on our wikis, unlike web2cit.

Another complaint at enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Aloysius_Jr-20250901113700-Search_function_malfunction_on_mobile

There are modules where some lengths need to be hardcoded and kept in sync with styles.css. Using css variables would help with this.
Yes, they could overwrite any system-wide variables, but you could enforce some naming scheme, the simplest of which migh be --ts-something-something. Disallow :root{} variables if you want, too.

This user registered at 12:26 UTC, which is 14:26 CEST (UTC+2) on hr.wikipedia (open both links in private windows).
My local time is 3:30 EDT (UTC-4). The pop-up says the user joined 3 hours ago (that would be ~12:30).
So it seems the browser is getting the UTC time as the registration time, and calculates the relative time by subtracting the browser's time from it. I can manipulate the value by changing the system's clock and refreshing the page.

I see this in Firefox Nightly for Android (SwiftKey keyboard, if it matters), but not in Chrome.

I disabled all my gadgets on enwiki and was unable to reproduce the issue following the steps described above.

Reminds me of T350270

Something has changed recently and the filter pages can be scrolled left-right, and zoomed out (as in the attached screenshot).
Still, ideally all these tables would be within a scrollable DIV so only the table parts of the page can be scrolled, not the whole page.

@Jdlrobson True, but interface administrators are only volunteers who could do things but never should. Are there global interface administrators or developers who could/should do this instead?

The link should be added to MediaWiki:Sidebar for all wikis that once had it and lost it with this change, especially because it was just recently moved from page tools to the left sidebar.
Special pages are important and I don't know of any other way of getting there, especially when every wiki has its own localized name.

This "button" is responsible for a lot of color contrast errors in https://github.com/wikimedia/color-contrast-checker for desktop – every desktop page has one.
@Jdlrobson-WMF

Pull request: https://github.com/CurbSafeCharmer/refill/pull/264

I checked the references in [[London]] on a few major wikis. Some wikis use the ISO 8601 date format exclusively, some use their local date format or both.
On all wikis the ISO date is transformed into the local date format by the citation module.
Babel format=long is identical to what the wikis will accept as the input date.
No wiki uses the format output when the format=medium (default) is used.

@Curb_Safe_Charmer
I checked https://en.wikipedia.org/api/rest_v1/#/Citation/getCitation. Citoid returns the ISO format, like 2007-11-19.

In T393124#10784709, @Curb_Safe_Charmer wrote:

This would need to be implemented in Citoid (https://phabricator.wikimedia.org/project/profile/62/) rather than reFill.

The current layout could be improved with some better visual separation within the lines, but the low information-density tables are not the way to go. In these mockups I don't even see revisions with 3,4 or 5 edit tags (they can get long in some languages) or edits with long edit summaries, I don't see Twinkle buttons (love Twinkle), I don't see the possibility of expanding the diff right below each line (inline diffs), coupled with patrol buttons for wikis that use PatrolChanges. Any idea how many user scripts will be broken? Any work done on making the layouts of Recent Changes, Watchlist, Page History, User Contributions the same (for easier scripting at least)?

This "worked" fine some 3-4 weeks ago, i. e. it was either possible to scroll left and right, or there was no (hidden) overflow.

@Tchanders Yes, my filters are back and I was able to edit one. Thanks!

I don't know what's happening here, but it's not good.
We were encouraged to switch to the new ip_in_range(user_unnamed_ip, ...), and some of us did.
That protected our filters for good.
But now we cannot see nor edit the protected filters. They disappeared from our lists. I don't even know if they're working.
On hrwiki, they're the only protection from our IP-jumping LTA.

After a quick test, I think we could live with \w (with re.U) too, which still covers a great number of accented characters if this is a problem for you guys in Pywikibot.

I think you'll have better python - php compatibility if you simply switch from re.search to regex.search.

Ideally, yes. Though we benefit from the automatic   armoring of our percentage sign that comes with that function, as in 42▁%.
That's why I'm hoping for a quick and minimal solution.

This is one of the few things that cannot be undone, so my question remains: why is this present in all filters?
It will be confusing for people to see two ways to hide a filter, one of which is permanent.

@Dreamy_Jazz
From what I can tell, Special:AbuseFilter/test will not work with user_unnamed_ip, and Special:AbuseFilter/examine will only work with actions that triggered a user_unnamed_ip–containing filter.
Is that right?
Can that be added to https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format?

@Dreamy_Jazz OK, I see. Not sure if I'll need to test against (all) past actions or just the ones that triggered the filter, so I won't file a separate feature request.

Can we have a different name for this nondescript pretty?
If that's day+month call it daymonth or dm.
If people want month+year, introduce monthyear or my.
With pretty, you'll have one thing in a template for one language, and another thing in the template for another language (on Commons, for example), depending on what people decide is pretty in their language.

I was reminded that this is still an issue.
I've tested the patch, found no issues.

Looks good to me, Samwilson. I mean the dialog.
Yes, the show changes (diff) button should be where it is now, in the Save/summary dialog.
It doesn't hurt to have these two warnings, though the "may have changed" seems more important to me (if you can compare the time of the last live on-wiki revision and the time of the locally saved edit)
Thanks!

While you're at it, would it be possible to do the same on User contributions pages?

Adding a note here, as I am discussing the patches at Discord. We're removing mdy and ymd because they are not valid date formats in Croatian. For example: Studeni 28. 2024. and 2024. studeni 28. make no sense in Croatian.

The two patches should fix all the problems. How soon can we have this? It only affects hrwiki, and I hope it can be treated with some urgency (some of our automatic templates are failing).
Thanks all!

@Umherirrender : oh, what a mess. I have no idea why they did that. The local Month-gen messages were in the nominative case. I've deleted them.

DiscussionTools is different. You're not editing someone else's work but your unfinished/unsent message.

@MusikAnimal: I've spoken to @JWheeler-WMF and I'm hoping his team will care of this behavior.
Yes, it's by design, but the design decision is, arguably, flawed. Most, if not all software asks whether to restore.

I have a question here: from these screenshots, you seem to be satisfied with the blue/purple background in light mode, even though most, if not all complaints are about it. The color probably looks okay on some big, fancy designer monitor for casual testing, but it feels too dark and grayish for any meaningful work, especially on smaller screens (think 14" laptop screen). We'd get the same information if the background was a little lighter (that there was a change somewhere in the text), but the change itself would be easier to read.