Jun 12 2020
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
allowing ADSL users to upload in one step.
I guess I will have to upload indirectly via phabricator until this is fixed...
Jun 8 2020
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 188.8.131.52,
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.
Is the biggest thing to make a curl of.
And my network monitor doesn't show a lot of bytes transferred.
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 .
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
just gets up to 68% and says
Today even with
all I got was
Solution: Commons should simply use the same uploader as phabricator.
Jun 6 2020
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?
Jun 4 2020
May 29 2020
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
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>
May 28 2020
So changes to a non-Structured Discussions page,
Indeed the pleasant chit chat is turned into a list of Topic:zzzz .
May 27 2020
May 26 2020
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.
May 20 2020
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.
May 11 2020
#!/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.
May 4 2020
Apr 30 2020
OK I filed https://phabricator.miraheze.org/T5504 .
Apr 29 2020
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.
But users must cut/copy and paste it into their URL bar to visit it... and they very much might accidentally ruin
it via "Save description".
Apr 26 2020
OK. I added my own brilliant idea at https://en.wikipedia.org/wiki/User_talk:SD0001#Idea:_Archive_names_from_the_start
Apr 17 2020
Thanks! (but let's hope one day permalinks that survive archiving get invented.)
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.
Apr 16 2020
E.g., https://en.wikipedia.org/wiki/Special:Search has a "(?)" link for more info.
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".
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.
Apr 7 2020
Sure, works fine in firefox, but not:
Apr 6 2020
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
@Demian's stuff looks great.
I found that there are
$ w3m -dump https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend | grep -c Permalink 46
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.
- I don't know what tool this is about. Because there is no way to determine that.
- 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
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.
Apr 4 2020
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
Apr 3 2020
https://github.com/gravitystorm/openstreetmap-carto/issues/4103 similar issues.
Thanks. Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1067571 .
Apr 2 2020
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.
Mar 24 2020
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.
Mar 9 2020
("Wikipedia cannot determine your location. Please try again with a better signal.")
Mar 4 2020
Yep, one must resort to the API to dig out the information . https://m.mediawiki.org/wiki/API:Siteinfo
Mar 3 2020
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?