User Details
- User Since
- Jan 1 2023, 11:48 AM (98 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Bugreporter [ Global Accounts ]
Wed, Nov 20
Getting the optimal wording for error messages can be tricky: https://uxwritinghub.com/error-message-examples/
Tue, Nov 19
Would it be possible with this to specify, in the error message, the target of the redirect you're attempting to link to? The chances are that's what the redirect target should be as well.
25 years wasn't such a bad guess.
This would be fixed by having different user groups, which can be easily set in localsettings.php.
A magic word output of the user's browser would allow this. Would it impact caching?
Mon, Nov 18
Thu, Nov 14
Tue, Nov 12
Mon, Nov 11
Most likely.
Sun, Nov 10
I believe the SOP is actually to retire this task and start a new task for 1.44, rather than renaming this one, @Reedy -- at least that's what people did before.
Thu, Oct 31
Oct 22 2024
Or is there any reason why escaped-HTML can't be just displayed as plain text?
Non-wikitext messages would seem to fall under
Oct 18 2024
Thanks to all who have worked on fixing this.
Oct 16 2024
Sep 11 2024
Sep 10 2024
Aug 31 2024
But that assumes that the welcome patch would fix everything, which I doubt it would.
Aug 2 2024
I've added that suggestion as T371657
Better than having it preserve the skin, which can be set via [[special:preferences]], might be to include a drop-down in [[special:expandtemplates]] that allows the skin to be specified, which then adds &useskin=foo as required?
Jul 30 2024
Is this still happening now with the new implementation of dark mode?
Why is this needed? The homepage looks OK to me in dark mode:
Jul 27 2024
Another thing it could do is mark if the edit is minor or not.
As a note, Wikipedia uses a lot of IPA. Fonts should be IPA-compatible, and because of open source ideology, open source.
Jul 23 2024
Apr 28 2024
Mar 8 2024
Feb 22 2024
Feb 20 2024
Dec 29 2023
Dec 1 2023
Nov 30 2023
Having checked this out, I can see that $wgRestrictDisplayTitle does allow some but not all of this functionality. That is, it allows changes to both the displayed name and <title> but you have to use one string to change both values. So, if you set {{DISPLAYTITLE:USS ''Nimitz''}}, it changes the page title to USS Nimitz (italics with <i> tags), but then the html title is displayed as USS Nimitz (without the formatting), and it's not ideal to set the <title> tag to something different such as USS 𝘕𝘪𝘮𝘪𝘵𝘻 (which uses italic lettering from https://lingojam.com/ItalicTextGenerator rather than formatting the text itself). Note, if you use {{DISPLAYTITLE:USS 𝘕𝘪𝘮𝘪𝘵𝘻}} (i.e. with the italic lettering), the page title looks pretty messy.
@taavi I do not think this is an extension request; I think it better integrated into MediaWiki core.
Thanks for the review @Samwilson - you are correct; I had misspecified the element that this would customise.
Nov 29 2023
Nov 22 2023
I don't think we should really be using italics to show redirects.
Nov 16 2023
Might it be better to fix this with a magic word like` {{ISSUBPAGE}} which would return 1` if true and 0 if false? They could then be used together to avoid throwing errors.
Is this really a massive 😱 OMG drop everything and panic security issue?
The solution to this, which I'm going to suggest, is by moving disambiguation pages to their own namespace. This is something that some 3rd party wikis do already, and it seems to work.
Nov 15 2023
I think this is good idea 👍💡