On 2/7/07, Jeff Raymond <jeff.raymond(a)internationalhouseofbacon.com> wrote: I sometimes feel like Jeff does, sometimes feel very different...which probably makes me pretty close standard policy, although I often find myself wondering...shouldn't [[He said, She said]] be the dab page? Then I realise it isn't worth a fight, and move on. I really like Steve's idea, but will it cause browser issues?

Ok, I did a proof of concept: http://en.wikipedia.org/wiki/User:Stevage/Disambig Obviously it has graphical issues, but technically it seems pretty simple. Steve On 2/8/07, Steve Bennett <stevagewp(a)gmail.com> wrote:

On 2/8/07, Rich Holton &lt;richholton(a)gmail.com&gt; wrote: Yep. Yep. Yep. Totally agree on all three points. The third is likely to be the hardest. I don't think it can currently be done without actually editing all the disambig pages and replacing {{dab}} with <noinclude>{{dab}}</noinclude>. It may be possible to do it with some CSS magic, like putting a class on the {{dab}} template, and somehow making that class invisible when it gets transcluded. I suggest that if there is consensus to actually start doing this, that we introduce it slowly, page by page, adjusting the corresponding disambig pages so they transclude nicely. If that proves to be popular, then presumably the MoS will be updated to make a requirement for disambig pages that they transclude nicely. Though I'm dubious whether a page like [[Victoria]] would ever come out well. Maybe we can get scrollbars in there? Steve

On 2/8/07, Steve Bennett &lt;stevagewp(a)gmail.com&gt; wrote: Hey, it turns out the Hidden template degrades the way we want: if JavaScript is off, you just get the disambig line, no transclusion. Brilliant! So this wikicode is basically perfect by itself: {{Hidden|1={{otheruses|He Said, She Said (disambiguation)}}|2={{:He Said, She Said (disambiguation)}}|ta1=left|fw1=normal}} The only problem left is the undesirable extra {{dab}} link showing up. But we can solve that on a page-by-page basis to begin with. Steve

On 2/8/07, Ruud Koot &lt;r.koot(a)students.uu.nl&gt; wrote: The whole scheme[1] is totally dependent on css anyway. If we get as far as having a box that can be expanded and that transcludes another page, CSS and javascript is a given. How would an Ajax implementation work? Would the MediaWiki code need to be modified? Incidentally, I've made an expanding version of the "otheruses-4" template: [[User:Stevage/Otheruses4-expand]] There's an example of its use here: http://en.wikipedia.org/wiki/User:Stevage/Disambig2 Steve [1] That is, using the 'hidden' template.

On 2/8/07, Rich Holton &lt;richholton(a)gmail.com&gt; wrote: That is a problem with using only wikicode. I'd suggest instead using an ajaxy (not really, but kinda) solution where a javascript loads the HTML from the target page and displays it in the box (I'm thinking of the popups addon, it does that, right?) That would ensure that the headings doesn't appear in the article, since it is added after the page has been rendered by mediawiki. Also, it would hide the code from non-javascript capable browsers. --Oskar

On 2/9/07, Steve Bennett &lt;stevagewp(a)gmail.com&gt; wrote: Yes My suggestion would be to load the page every time as soon as the user come to the article. The user would not notice this because it loads after the page is rendered in their browser. There would be a slight performance tax, but it is nothing the user would notice and nothing the servers couldn't handle. Well, I shouldn't put words in the developers mouths, but that's what I imagine. I think that would be the best solution. --Oskar

On 2/9/07, Rich Holton &lt;richholton(a)gmail.com&gt; wrote: I think it's fairly clear that we could not immediately take every disambig page and just declare it suitable for transclusion at the top of the relevant pages. Most will need minor reformatting, even if it's just sticking <noinclude> around certain bits of text like section headings and what-not. As a slightly separate issue, more advanced transclusion methods would certainly be beneficial, and I did raise a bugzilla bug over this once. The ability to transclude text without categories was a key issue, and references was another issue. To solve the disambig-template issue, perhaps we would need to be able to mark a template as only being transcludable for N levels (disambig page can transclude {{disambig}}, but another page that transcludes the disambig page doesn't transclude it), but that sounds really complicated and confusing. Steve

On 2/9/07, Bill Konrad &lt;bkonrad123(a)sbcglobal.net&gt; wrote: It's not geeky, it's good UI design, which MediaWiki kind of lacks. My internet connection is fairly slow, and it takes seconds to load a new page. Being able to avoid that would be great. Not true - I've made an otheruses4-expand template which is a drop-in replacement for otheruses4. Yeah, that's true. The major issues identified so far are: - not allowing section headings to be transcluded - not allowing the {{disambig}} (and related) templates to be transcluded There may be others. I notice that some disambig pages have wiktionary links, but they can probably safely stay. I think what we've got so far is "relatively idiot-proof". At worst, the drop-down box may be a bit ungainly. If an idiot did something really bad like putting <noinclude> around the whole page or something, then the worst possibly result is that the end user sees nothing drop down - and they're in the same situation as now. Advantages: - Saving a couple of seconds every time a user needs to pass through a disambiguation page. - Requiring one less page load in that scenario. The basic workflow would go from three page loads (searching for their term which loads the "wrong page", clicking the disambig page link which loads the disambig page, clicking a link which loads the "right page") to two (loading the wrong page, loading the right page). What are the disadvantages? Steve