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?

In T247221#6187465, @Jdlrobson wrote:

Just share the URL in your address bar? It updates as you browse.

Also we can't tell what the real title of the page it is talking about,
as Topic... is mentioned four times, but the real title of the talk page, zero times.

The problem is in
https://radioscanningtw.miraheze.org/w/api.php?uselang=en&action=feedrecentchanges
when encountering Structured Discussion content,
the <description> is empty:

<item>
<title>Topic:Vmzesp0upz46b23i</title>
<link>
https://radioscanningtw.miraheze.org/wiki/Topic:Vmzesp0upz46b23i
</link>
<guid isPermaLink="false">
https://radioscanningtw.miraheze.org/wiki/Topic:Vmzesp0upz46b23i
</guid>
<description><p></p> </description>
<pubDate>Mon, 25 May 2020 13:56:50 GMT</pubDate>
<dc:creator>Sunham</dc:creator>
<comments>
https://radioscanningtw.miraheze.org/wiki/Topic_talk:Vmzesp0upz46b23i
</comments>
</item>

So changes to a non-Structured Discussions page,

Indeed the pleasant chit chat is turned into a list of Topic:zzzz .

In T205619#6168027, @Aklapper wrote:

That has always and ever existed at https://commons.wikimedia.org/wiki/Special:Upload ...

I'm sure alternate browsers were the first thing I tried.
Anyway, you would have to fix it for the world's biggest browser anyway.

Yes. I have to take my cellphone to the top of the mountain for a clear connection to upload, as your form requires high speeds or else it will fail.

Workaround:

#!/usr/bin/perl
# Automate Enable Structured Discussions...
# https://phabricator.miraheze.org/T5504#107946
# Copyright       : https://www.fsf.org/copyleft/gpl.html
# Author          : Dan Jacobson -- https://www.jidanni.org/
# Created On      : Mon May 11 21:00:19 2020
# Last Modified On: Mon May 11 21:52:32 2020
# Update Count    : 9
use strict;
use warnings FATAL => 'all';
use utf8;
use WWW::Mechanize;
my @pages = qw/
Talk:Barf
Talk:Bla
etc.
  /;

No know solution: https://phabricator.miraheze.org/T5504#108690 .
Wish there was an API way.
I tried using a curl script, but need to get a new token each time, etc.

OK I filed https://phabricator.miraheze.org/T5504 .

And OK. the category was saved into the Description, but as the content that contained that category is now gone, it doesn't make sense. But OK maybe it does on other occasions...

OK, there is indeed a somewhat of a link. One must click "Edit Description" to find it.

OK. I added my own brilliant idea at https://en.wikipedia.org/wiki/User_talk:SD0001#Idea:_Archive_names_from_the_start

Thanks! (but let's hope one day permalinks that survive archiving get invented.)

In T247221#6064729, @AntiCompositeNumber wrote:

I've got no idea what Special:Nearby does

Yeah, there is no "(?) Help" link explaining what it does.

Also consider using a numbered list, so one can better visually manage the results he is looking at. (<OL> vs <UL>.)

It is a common practice on all Wikimedia owned wikis, not any particular one.
It is not a common practice outside of Wikimedia owned wikis.
If phabricator.wikimedia.org is the wrong place to post this, where on *.wikimedia.org is?

And... if the radius and max results are actually computed with some secret recipe depending on nearby density, all that should be mentioned in the future "(?) Help" link, which this page certainly needs.

@AntiCompositeNumber while your are at it, you might as well throw in a radius[32 km] textbox, with the (currently secret) default sitting already inside the box.
Same with a maximum number of results box.

E.g., https://en.wikipedia.org/wiki/Special:Search has a "(?)" link for more info.
https://en.wikipedia.org/wiki/Special:CategoryTree too.

Or at least add a tiny (i) ("i" in a circle) that mentions "how to share a link to this page for a certain location" from which the user could see how he could compose the URL.

Put the entry box even way down at the bottom if you like,
and even make it two textboxes: Latitude:[_____], Longitude: [______].
(slower entry than one paste of LAT,LON) if you insist. But at least
"provide this manual override", as you never know when "the car's autopilot isn't working".
Thanks.

Well all I know is once there is an entry box on the page,
the user will notice the URL created in the browser's URL bar,
so you will no longer be the only person who knows the
currently secret way to workaround this bug!

I am saying (at least) just let me put in raw coordinates please.

@Aklapper
Sure, works fine in firefox, but not:

In T249480#6032169, @Demian wrote:

From the size of the scrollbar I've guessed 72. That shows how accurate that is :-D

Well then there is also "on this page" vs. "total".
And (at least for that text dump I did, it is not clear how many pages there might be.)

$ w3m ... | grep Load
Load more

Yes expect similar bug reports in the future to not be sure what project to assign it to as per
https://phabricator.wikimedia.org/T249396#6028851 .

@Demian's stuff looks great.

I found that there are

$ w3m -dump https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend | grep -c Permalink
46

items!

When we go to the library, we can see which books are thick vs. thin vs. endless.
When we download files, we (usually) can tell if it will finish before dinnertime.
Users want to know how many items there are.
Yes you might say well just look at the (ever growing) scrollbar.
But that might mean one big item, vs. 1000 small items... same scrollbar.
So why not simply give them a count up at top?

Or, if totals are bad, then remove the "10 comments" totals too.

1. I don't know what tool this is about. Because there is no way to determine that.
2. You don't have to number anything, just say once somewhere near the top how many there are.

Also why show the comment tallies, but not the [one level higher] tally?

Well on Facebook, we always know, before we click on something, how many items lie below.

(And on https://www.mediawiki.org/wiki/Extension_talk:DiscussionTools still say "2 total" even though yes, we can see that.)

I'm saying at the top of
https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend
there should be some "123 total" at top,
meaning that this very long page has a total of 123 topics.

The page keeps growing and growing while we wait (ADSL speeds).
We probably wouldn't think of looking way way way down there.

Fine. OK I'll just have to refer to all this stuff via what it looks like, etc.
https://phabricator.miraheze.org/T5372

By the way, both pages have the same top, "Discussion" tab selected. Perhaps make them different somehow.

All I know is some pages' Talk pages have the same format as the pages
themselves, e.g.,

https://github.com/gravitystorm/openstreetmap-carto/issues/4103 similar issues.

OK, made https://en.wikipedia.org/wiki/Template_talk:GeoTemplate#Users_have_very_few_methods_to_find_out_where_to_provide_feedback .

Thanks. Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1067571 .

Also you will note the numbers are too low in their boxes.
Also seen in T249282, where "投77", though unaffected by this space bug, still is placed too low.
See https://www.openstreetmap.org/#map=16/23.9611/120.9464 for examples of how to do it better.

Upon first arrival at e.g., Special:ManageWiki/settings... but that is Miraheze specific... but they say it is a MediaWiki bug. So I don't know what to say.

("Wikipedia cannot determine your location. Please try again with a better signal.")

Yep, one must resort to the API to dig out the information . https://m.mediawiki.org/wiki/API:Siteinfo

Anyway, currently, the timezone a (not logged into) wiki is showing is
such a secret, that without access to the $wg settings one cannot figure
out what the owner has set it to! Sure, analysis of the raw HTML reveals
"timestamp":"20200302194849" and HTTP HEAD shows Last-Modified: Sun, 01
Mar 2020 17:41:33 GMT but do we really need to start trying to go
further and analyze those?