Sun, Aug 25
Aug 21 2019
Aug 20 2019
Aug 17 2019
Jul 30 2019
(example links moved to description)
Jul 28 2019
reopening, but perhaps it's the wrong phabricator task. T90475 seems to be relevant too. Judging by the title of this task here, however, it isn't yet fixed.
Same for the dewiki page; the search terms "Benutzer ToBeFree de wikipedia" and "User ToBeFree Wikimedia Commons" are very specific, but to my knowledge, a properly working "NOINDEX" should prevent, or even remove, these results.
Jul 9 2019
Jul 6 2019
@Krinkle: My global userpage on Wikimedia Commons still appears in Google results, even with the text "… you see on this page was copied from". Is this an intentional exception by the Commons community?
Jul 3 2019
(Only the fifth example has a "Visual edit: Switched" tag)
Jun 23 2019
Jun 21 2019
Jun 19 2019
May 16 2019
The link is known to have worked at 2019-05-01T18:45:33 UTC.
May 15 2019
May 13 2019
Before the patch, I wasn't aware that this is a Wikimedia-only extension providing the text. I genuinely believed this to be a global error that the enwiki community was insisting on keeping. Neither is the case.
@Risker, I am very disappointed by this bureaucratic objection to a typo fix that is backed by a local policy and can easily be overridden by creating the page with any content that the enwiki community decides on in an RFC.
May 12 2019
May 5 2019
May 2 2019
May 1 2019
Apr 27 2019
Feel free to close any of both tasks, perhaps as a duplicate, if they are considered to be essentially attempting to solve the same problem using two different solutions
Apr 26 2019
Thank you very much, this relieves me! :)
Apr 23 2019
"Optimizing" a website for search engines appears to be the wrong approach to website building to me. If a search engine's algorithm fails to correctly balance the relevance of a website to its users, then the problem is in the algorithm, not the website.
Apr 22 2019
Apr 11 2019
Wonderful and seems to be done
Still testing? Breaking issues?
Mar 26 2019
Mar 7 2019
Mar 2 2019
Feb 25 2019
I think we should consider updating the min-version setting on Wikipedia if/when this issue is fixed.
Interesting, possibly related, HG 3.4.4. Clearly a technical issue, proven by the edit summary: https://en.wikipedia.org/w/index.php?title=Jason_Kenney&diff=884940008&oldid=884939997
Feb 23 2019
I think I have an example use case that I'd need right now: I'm creating a global userpage on meta.wikimedia.org and would like to add a globally working "Add new message to my talk page" link. This does not seem to work without having a local page that can be accessed using an internal wikilink to execute the action. Any magic words are parsed on Meta before being displayed on the other wikis, external links are unflexible, but wikilinks are being interpreted locally.
Feb 11 2019
Feb 9 2019
Jan 31 2019
Jan 25 2019
(I agree, we can remove this)
The timeout is nothing new, my preferences show 1000 entries by default, and that's too much for 60 seconds. Wondering if PHP7 accelerates this process enough to finish within 60 seconds, I opened the page, and received plaintext instead of the "usual" warning design. I guess this is relatively intentional and can be ignored.
Jan 15 2019
Jan 14 2019
Thinking about it again, I agree, and the point about technical skill is good. Thanks!
Jan 5 2019
Dec 28 2018
Dec 9 2018
@Billinghurst , one comment above yours: "Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage and the situation will mostly be at a standstill until stewards come and clean things up."
Dec 3 2018
Dec 2 2018
- if this happens, the null revisions are not the main problem – the overall high edit count is. It would be wrong to blame the final straw for breaking the camel's back.
- Ignore null revisions for non-admin overwriting redirect checks.
- Force a null revision to be made, do not provide a checkbox.
- Do not show a rollback link if all the affected edits are null revisions.
- Thanking for a null revision should cause the same message as thanking for the log entry.
Dec 1 2018
Most of that IRC log seems to contain arguments that are invalid when implementing this as a null edit rather than doing extra database queries whenever viewing the revison history. The first real point appears at 16:57:22. In my personal opinion, it should not matter how a ticket is written; the existence of a feature request implies that there is use for the feature, and the feature has no downsides, so it should be implemented. This is open since 2014, and people are now wondering (see Village Pump link above) why this is still not a thing.
@geraki Hi, thank you very much for the comment.
Nov 28 2018
Regarding auto-removal, note that the current way for generating new backup
codes is disabling 2FA and enabling it again ^^
Nov 27 2018
Oh, thank you very much. That's a nice solution I didn't think of. ☺️
Nov 26 2018
If you assume an adversary who is not subject to rate limits and uses automated tools, unblocking themselves whenever needed for further carnage will likely lead to the same result. The unblockself privilege only makes a difference against humans who act harmfully and are limited by their own action speed.
Nov 25 2018
Nov 22 2018
This is very kind, thank you very much! :)