And maybe having the filenames reflect both dimensions, not just X,

…/337px-…

would help. (But then cause a lot of pages that have previously embedded them to fail.)

That means it wouldn't be easy to fix this bug by just comparing filenames.

(https://phabricator.wikimedia.org/T144894#6751683 and
https://phabricator.wikimedia.org/T144894#6751684 are the same.)

One might say "Well, the program is just trying to give a easy to read full list of resolutions. Don't be so harsh on them for using the word "other."
Nope. as we see in https://commons.wikimedia.org/wiki/File:Historical_Power_Tower_Foundation_2.jpg the bug does not occur.

Yes, every time a time is mentioned, some mention of zone should be added. Just like this banner,

It seems there is a bug on zh.wikipedia.org that stops the UTC from
getting through, even for non-logged in users.

OK, let's say that the user indeed does even know that their preferences
cover this.

OK, if it turns out my bug has any merit, feel free to reopen it.

This one is too hard. OK I'll close it.

All I know is I am still getting notifications caused by https://zh.wikipedia.org/wiki/User:Jimmy-bot .

In fact, at the top of https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo there already is
"Email options" but the careful user will notice it only lasts until just before the following "Notify me about these events" section!

No, trying it again does not reproduce it. Apparently because my changes are saved. So you will you folks will have to figure out how to reproduce it yourselves.

Hmmm, Google would say,

• Are you sure you just want to see the English links? There are [click here] five times as many results for zh-tw.
• Found no English links. Removing language restriction and showing all results.
• Etc.

Well how about also sensing "the main language(s) for the coordinates."
Just like when you connect to Google from Japan, Google somehow guesses you might want their Japanese welcome screen.
So in this case, even though we are reading en.wikipedia.org, based on the coordinates, the system could say to itself, "Well I bet there are some zh-tw articles nearby too. Let's put some tally of them in the side panel the user could click on."

Indeed you can simply do:
$ GET https://... > /tmp/e
Then:

$ perl -nwle 'print for /href=............./g' /tmp/e|sort|uniq -c|sort -nr
     54 href="https://radi
     19 href="/wiki/%E7%89
     19 href="/wiki/%E4%BD
     11 href="javascript:v
     10 href="/w/index.php
      4 href="https://meta
      4 href="https://crea
      2 href="/wiki/%E9%A6
      1 href=\"https://cre
      1 href='https://radi
      1 href="https://www.
      1 href="/w/opensearc
      1 href="/w/load.php?
      1 href="/favicon.ico
      1 href="/apple-touch
      1 href="//login.mira
      1 href="#searchInput
      1 href="#mw-head"

So we observe 54 + 1 = 55 external links that should have been just local links.

Note
$ lynx -dump -listonly https://...
converts all links to absolute, so is useless for debugging this issue.

Well it only happens on those StructuredDiscussions pages.
But OK I will make a note of it on
https://bugs.chromium.org/p/chromium/issues/detail?id=1091439 .

(My guess is the authors of MediaWiki made the conscious decision to use relative links.
But some extension authors didn't know how to make them, so just used absolute links.

https://webmasters.stackexchange.com/questions/96955/speed-comparison-absolute-vs-relative-path-links etc.

https://stackoverflow.com/a/31629588/1118719

In T267483#6611714, @Aklapper wrote:

@Jidanni: Hi, if you as an admin...

(First, the average user would have no idea to report this bug to
https://phabricator.wikimedia.org/tag/structureddiscussions/

Anyway, my point is it is still possible to create categories with U+FFFC OBJECT REPLACEMENT CHARACTER in their names.
Try it.

Odd, on
https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette
it says

Thank you for hinting me to file proper bug reports.
Many of these are just emergency notes from the field.
Made on a tiny cell phone.
The idea is the public is reporting a fire on mountain A,
with the hope that people with better equipment will be able to better able to find the details,
much of which would not have been available to the bug reporter and would only be available to programmers.

So it turns out: there is no way users will remember that they have turned on "Advanced Mode" or made a .js file, so the the brown warning message should mention those two places. Thanks.

https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2020/08#How_to_keep_an_eye_on_my_uploads_after_kind_of_spam_notifications%3F

https://commons.wikimedia.org/wiki/Commons:Help_desk#Unsupported_gadget_or_script_all_of_a_sudden

https://commons.wikimedia.org/wiki/Commons:Help_desk#How_can_I_stop_receiving_bot_notification_by_email%3F%3F

" You are running a user gadget or script that is unsupported on mobile. Please review mw:ResourceLoader/Migration_guide "

I am sorry. I was reporting from the field on a tiny cellphone.

All I know is for the first time ever, a bot is munching through all of Commons,
causing the state of

I've added documentation of this feature to https://www.mediawiki.org/wiki/Extension:NearbyPages

https://www.mediawiki.org/wiki/Help:Notifications#Muting_users notes

Let's have a look at the highlights of one of these emails.

Ah, I found the problem: On Special:Preferences#mw-prefsection-personal

Nobody is monitoring https://github.com/toolforge/video2commons/ ,
and the problem is a wmflabs machine.

When saving preferences, a simple check for valid HTML or at least counting the number of opening and closing tags should be done.

Idea: Perhaps make a page, that combines phabricator's upload form, and
https://tools.wmflabs.org/url2commons/index.html ,
allowing ADSL users to upload in one step.

I guess I will have to upload indirectly via phabricator until this is fixed...

I ran the mtr tests earlier in this bug report.

OK, uploading the file to Twitter (takes about 20 seconds, but always a success), lots of healthy yellow seen in the icewm network monitor

Anyway, today I was given IP address 36.234.68.20,
so when you check the server errors logs above, you will see me.

pppd default-asyncmap defaultroute lcp-echo-failure 7 lcp-echo-interval
50 mtu 1492 noaccomp noauth noipdefault noproxyarp persist plugin
rp-pppoe.so usepeerdns user ---@hinet.net pty pppoe -I enp7s0 -T 80
-m 1452 enp7s0 debug

is how I connect.

I bet the form isn't even being sent.

https://commons.wikimedia.beta.wmflabs.org/ : OK, created account... Uploading .... and of course at the very end... "None of the uploads were successful."

OK finally succeeded via https://tools.wmflabs.org/url2commons/index.html
copying from phabricator to https://commons.wikimedia.org/wiki/File:Phony_water_tank_real_cell_tower.jpg .

Upload warning
Copy uploads are not available from this domain.

Nope, 92% is as far as one can get, before

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:18:51 GMT

OK, now got to 92%, and

Next attempt got to 80%, then

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:14:44 GMT

https://commons.wikimedia.org/w/index.php?title=Special:Upload&uploadformstyle=basic
just gets up to 68% and says

Today even with

Hmmm, well Special:Watchlist doesn't have an more links to Special:Preferences than any other page.
Perhaps it needs some.
Perhaps have a direct link to Special:Preferences#mw-prefsection-watchlist titled "control your watchlist preferneces".

So maybe Special:Watchlist needs to add an "advertisement" ("New") alerting users to the new preference available?