Last modified: 2011-02-09 12:57:26 UTC
I think will be good idea to allow [[Special:Preferences]] to use # for referring to particular section like:
Special:Preferences contains many options now and it's not easy to find particular ones for user who new to MediaWiki. Will be useful for help pages and talks.
Localized tab names (Recent changes, Editing, etc) should be supported too for site default language as well as English.
It would probably be better to use the (semi) existing numeric representations rather than localized names, in my opinion. This would work in any content or user language. And even if not, they should only be localized to the content language like the localized namespaces (not changing with user language changes). Or perhaps both? The prefsection-# and then the anchorencoded title?
If someone were to add the ID to each <fieldset> for each section (incrementally) starting at id="prefsection-0" it would pave the way to snazzy JS that would work good with people lacking the JS (a JS user could link a non-JS user, that is).
Thank you for your experiments!
It's looks like what I thought about. However name like "prefsection-8" is not intuitive. May be parser could translate sections names (including localized ones) into such form?
Although you can now link to a tab via http://en.wikipedia.org/wiki/Special:Preferences#prefsection-4 you can not link to sections within a tab.
http://en.wikipedia.org/wiki/Special:Preferences#wpDate2 ought to link to the
"Time zone" section of the "time and date" tab. It briefly goes to the right
place but then the page flicks back to the first tab. If you're trying to
explain to someone how to change something in their preferences, it's very
useful to be able to link them directly to the right place.
*** Bug 16650 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> Although you can now link to a tab via
> http://en.wikipedia.org/wiki/Special:Preferences#prefsection-4 you can not link
> to sections within a tab.
> For example,
> http://en.wikipedia.org/wiki/Special:Preferences#wpDate2 ought to link to the
> "Time zone" section of the "time and date" tab. It briefly goes to the right
> place but then the page flicks back to the first tab. If you're trying to
> explain to someone how to change something in their preferences, it's very
> useful to be able to link them directly to the right place.
Okay, I've refactored the code, which is live at http://test.wikipedia.org/wiki/MediaWiki:Common.js/prefs.js (in demo mode, be sure to clear cache). It now allows four kinds of anchor linking:
http://test.wikipedia.org/wiki/Special:Preferences#top <- anchor outside the fieldsets, no action
http://test.wikipedia.org/wiki/Special:Preferences#editing <- anchor matching a field name (case insensitive), goes there.
http://test.wikipedia.org/wiki/Special:Preferences#prefsection-2 <- anchor matching field ID, goes there
http://test.wikipedia.org/wiki/Special:Preferences#wpSkinchick <- anchor matching an ID inside a field, goes to that field and that ID
After load the name-type gets normalized to the numeric section, as it is language-specific. Sort of like [[User:Foo]] works in all content languages but gets localized on load.
Note that the last case isn't perfect, as page anchors are approached pre-JS collapse in most browsers (can't be helped, there was a bug on a Wikia where they tried to set the anchor post-transform but that sent firefox into an infinite reload loop).
Note also this sets the form action to the section you are in, so after save, you are returned to that section (it did that before, too, but still does).
There are two easy ways to get the link: click a section and get the URI, or right click a tab and copy link location.
It would have been easier to use URI parameters like ?section=foo or /foo but these are notoriously unreliable (see bug 16462 ) and I couldn't have the current URI location bar change to reflect your current tab (a snazzy feature). With straight anchors, you can even Wikilink to a section, like [[Special:Preferences#editing]]
Testing needed in as many browsers as possible:
- Does it work when changing the document.location.hash when clicking tabs? Do any browsers reload the page? This is my largest concern, and that feature may have to be disabled -> "if(!nohash) document.location.hash = '#' + trigger.secid;"
- Does it jump down when linking to an ID inside a section in any browsers?
- Does it do any other unpredictable shit?
It still optionally would have much non-JS fallback benefit from: every <fieldset> inside includes/specials/SpecialPreferences.php having id="prefsection-0" ++ (but looking at the mixture of XML::fieldset() and raw html output it is a horrid mess).
Brion showed interest in this becoming core, but it needs testing.
Thank you! Almost works for me in Firefox 3.1b2/WinXP except last example (skin selection).
*** Bug 14150 has been marked as a duplicate of this bug. ***
Dumping this one on Andrew :)
These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.
Fixed in r81573.
woohoo, thx Brion!