Last modified: 2014-08-18 09:50:44 UTC
The sandbox link on enwp always appears in the blue 'link exists' colour, even if the sandbox doesn't exist. This goes against the user interface standard of links to pages that don't exist appearing in red (as the user page / talk page links in the same section do). In order to match the convention, the link should be changed such that it appears in red if the sandbox doesn't yet exist.
The user interface, even on the English Wikipedia, doesn't have a "sandbox" link by default as far as I'm aware. There is a gadget called "mySandbox" which does, that, though: https://en.wikipedia.org/wiki/MediaWiki:Gadget-mySandbox.js , but given that (for the time being, anyway) gadgets are site-specific CSS and/or JS customizations, this isn't really a MediaWiki issue, but rather a site-specific issue.
Check again. I recently supervised two students, and I encouraged them to use the 'Sandbox' link that was present by default in the top-right of the logged-in user's view of enwp (between 'Talk' and 'Preferences'). It's not a gadget that has to be enabled - it's a standard link that everyone that has an account on enwp sees.
It really is a gadget that is enabled by default. Search for "Add a "Sandbox" link to the personal toolbar area." on [[w:Special:Preferences#mw-prefsection-gadgets]]. (I'm also afraid that this would be mostly impossible to implement well, given the limitations on JavaScript gadgets. Curiously, I can find no bug to implement this functionality in the MediaWiki software, which would allow us to fix this tirvially, too – perhaps one should be filed?)
I have now filed that bug: bug 69650, and explicitly noted taking into account page existence when generating the link as a requirement. I suggest following it and staying tuned :)
Hmm, OK. I'm not sure that this changes anything with this bug report, though. It's still a broken user interface issue with enwp (and any other wiki where this tool has been enabled), and as such it needs to be fixed. Apologies if I've filed this under the wrong criteria - please move it to the appropriate queue if that is the case.
I have marked the bug as "INVALID" for two reasons: * I believe that this bug literally can not be fixed by improving the current code without compromising site stability and user experience. However, writing and deploying an extension to do this should be rather easy. * Bugzilla is not the right place to report issues with site-managed scripts – a better one would be [[w:WP:VPT]] on the English Wikipedia. Perhaps the statement "INVALID" doesn't really provide that reasoning. :) Thank you for understanding.
Erm, no. This is an issue with the default settings of enwp. If this isn't the right queue for the problem, then please move it to the right queue rather than marking it as 'invalid' or 'resolved'!
Um, did you even read the comment? You need to go on [[WP:VPT]] and ask there. Bugzilla is the wrong place, period.
Thanks for reporting this, and thanks Bartosz and Kunal for explaining why this sounds like an issue to sort out in a more suitable place (that is [[WP:VPT]]) as this issue (due to its naturebeing about local code that is on or 'inside' a specific wiki) is not handled in Bugzilla. Hence "invalid" here means "this problem is out of scope for this Bugzilla". ("invalid" can be indeed a confusing bug resolution in such situations.)
OK, thanks for your patience and replies. I've now posted this at: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Bug_in_.27Sandbox.27_link_colouring Given that the general approach we're told is "find a bug -> report it on bugzilla", a "gadgets" queue might be a useful addition to bugzilla...
[offtopic] I'd support that once Gadgets were hosted in a centralized place - right now things that are on one wiki only should be handled in that wiki because I don't see how putting reports in Bugzilla for local code issues on-wiki would be ever found by their respective maintainers. :-/
