Eugene.Zelenko wrote:

Localized tab names (Recent changes, Editing, etc) should be supported too for site default language as well as English.

herd wrote:

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?

I experimented with a slight modification to prefs.js (see http://test.wikipedia.org/w/index.php?title=MediaWiki:Common.js/prefs.js&diff=61975&oldid=60839 ) to allow section linking, and this is live on test.wikipedia if you wish to examine it -> http://test.wikipedia.org/wiki/Special:Preferences#prefsection-8 ... It has the added bonus of changing the location.href to the tab you are on, so that you know where you are linking to. However, it wasn't satisfactory with javascript disabled. The various sections should have linkable IDs natively before the javascript is even applied, but I don't do PHP ^_^.

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

Eugene.Zelenko wrote:

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?

beesley wrote:

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.

beesley wrote:

*** Bug 16650 has been marked as a duplicate of this bug. ***

herd wrote:

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

Eugene.Zelenko wrote:

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 :)

(Batch change)

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!