In T274960#6835898, @Krinkle wrote:

@Jidanni OK, so to confirm, the only mismatching that you observe today is where talk pages use the unconverted version of the title?

Bingo.

The titles being differnt (for e.g., movie names in different markets) is totally resonable. The problem is the total decouple that happens before the user's eyes when hitting the Discuss button. At least a "Redirected from ..."-like little blub should appear. Welcome to expand my shell script to test for other &parameters.

Indeed, users pressing "Discuss" would be confronted by a totally different discussion pagename. "I am trying to discuss A, but I end up discussing totally unrelated B. Nowhere even before hitting Discuss is there the slightest hint that A is somehow related to B."

OK, made pristine bug report in T274960.

Well, that feature is being misused, perhaps by accident. It should just change three characters into a different set of three characters. Not a many times longer set of characters.
Users are confusing that feature, with Redirects.

Indeed, let's say one wants to discuss the page name. Well they would go to the Talk Page. But the talk page has a different name than the page we were on!

Okay I just tried it with a cell phone and now the page is working properly.

All I know is they were red until I picked up my cell phone. Aren't they still red on the Desktop version?

1.Visit https://en.m.wikipedia.org/wiki/List_of_phobias

2. Scroll down to Frigophobia.
3. Tap on it.
4. Now tap your phone's back button.

The closed T174995 is a duplicate of the open T236608 which corresponds to the picture I posted.

Yes it has, see T236608.

Well all I know is if on desktop, redlinks now looked the same as non-redlinks, there would be an uproar.

Couldn't even upload this to this bug report:

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 an 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.