This still happens. I've uploaded a new version of https://commons.wikimedia.org/wiki/File:EPSON_PX-8_-_1.jpg with cropped image on 2023-03-29 03:32 GMT.

Not caching negative responses may extend surface for DDoS attacks.

Isn't it possible to suppress requesting static thumbnail URL from preview mode (static thumbnail isn't used there anyway, AFAIK, live map iframe is displayed instead), so that first request will be made later, from an already saved page (when context data for proper rendering are definitely available)?

As far as I know, most common (and "expected", from the user point of view) approch when implementing FTI solutions in Slovak-centered projects, is to normalize all latin variants of each char into it's plain ASCII equivalent. The resulting side-effect of (search) equivalence of words like mäso/maso is a minor one in Slovak (and users can solve this by iterating through search results, where term matches are presented in their original, non-normalized form).

As for latin chars with diacritics, maybe even a simple iconv/recode-based ASCII translit term normalization (both on indexing and lookup side) would be sufficient for Slovak and other latin-based alphabets:

Even in case thers's no format value in TemplateData (or no TemplateData / no doc for given tamplate at all), VE should not change block template markup into inline (and vice-versa). It should not be that hard to infer inline/block format from actual markup during parsing (witespace containing newline before/after argument separators, maybe some simple RE based heuristics).

In T162849#3449142, @Jdforrester-WMF wrote:

This is intentional prioritisation for the billion users of Vector (as the default skin on Wikimedia wikis) against the thousands of users of Monobook (which isn't).

@Whatamidoing-WMF I don't expect them to look the same. What I do expect, is that the accessibility aspects (sizes and contrasts of relevant widgets, in this case) would get improved in the same way, regardless of a skin. Otherwise, there is no real benefit of change like this for non-vector users.

Under Monobook still no progress...

• no OOjs UI "accessible" styling of inputs (standard tiny checkboxes)
• strange bathroom-green gradient publish button, inconsistent with blue-gray skin visual
• large vertical indent between summary and checkboxes

@Niedzielski wrote:

I think your request is to make #2 more robust to affect _all_ UI elements. Is this correct or were you thinking of a fourth language option?

@Dbrant There are cases, where non-english users tend to (or have to) keep default english system-wide locale:

• corporate policy / locked settings
• wrong quality system localization (for their native language)
• wrong quality UI localization or a malfunction of some key app (which, too, does not provide independent UI lang switching...)

BUT at the same time would prefer some other Wikipedia-Android app locale, if available.

OK, that makes sense (and is kind of symmetrical, in its own way), but to be true, somehow I've hoped, that Flow is implemented in a way, backward compatible with wikitext content format, so that common things, like diffs over multiple revisions, diffs from watchlist/RC, markup operations over single or multiple comments (copying, moving, merging, quoting/reusing on wikimarkup level) and particularly, the ability of posting comments using both approaches will be preserved. Sadly, that seems not to be the case.

Thanks for the explanation, Matthias. But then - is there any sane way for Flow-enabled and non Flow-enabled users to discuss/collaborate on the same talk page? If there's no such way, I don't really understand the purpose of proposed Flow opt-in/opt-out games. NonFlow-ers won't be able to discuss on talk pages, created by Flow-ers (while Flow-ers will still be able to discuss on classic wiki talk pages), which is quite asymmetric outcome and it will, de facto, force all to use Flow...

Would it be possible to set $wgFlowContentFormat to "wikitext", to be able to test Flow in the way, that is compatible with non-Flow discussants?

Hello Arial, thanks for explaining.

I've filled this one at the end of May, related to skwiki:
https://phabricator.wikimedia.org/T100877, with I believe was related to
this issue. Not that it has gained any attention at all... :)

Seems to be solved, all skwiki dumps up to date, as of June 05.

Hi Kolossos, nice to hear from someone familiar with the thing... :)

No change after restart this time, permanent 502 Bad Gateway response for
all requests...

Really no way to fix?

@yuvipanda: who actually is a maintainer of the tool?

24+ hour outage, can anyone have a look and resume normal op, if possible?

Any thoughts? Pages/articles/histories at /skwiki/latest/ still of April
9...

Well, I was doing the same in parallel... :)

Nice, but it would be more relevant to monitor actual availability of each
particular service (tool) alone. The availability of kmlexport was < 90%
during last 24h, I guess. And even worse during week 17 (April 20 - 26).

Plenty of dropouts last two days: http://tools.freeside.sk/monitor/http-
kmlexport.html

8+ hr downtime right now...

And 4+ hour outage right now: http://tools.freeside.sk/monitor/http-
kmlexport.html

After 4 days of continuous operation since the limit update advertised,
some outages today, the longest one being ~90 min:

Right now it seems to be down again.

Yes, the tool was returning a 500 resposne for several hours today as well.