Wikimedia Bugzilla is closed!

the focus should be the 'what are the subpages of this page' function - a great feature to dive into directories

(In reply to comment #1)
> the focus should be the 'what are the subpages of this page' function - a 
> great feature to dive into directories
 
Yes... and a necessary feature to supplement "what links here", since links "up"
to a parent article are auto-generated at the top of subpages, but the subpages
don't show up in the "What links here" for the parent.  

This would be a most useful function.

This feature could be used as a basis for an automatic table of content
generation for wikibooks, provided that subpages are enabled on the main
namespace as I advocate on this article:
http://meta.wikimedia.org/wiki/Wikibooks_should_use_subpages

You can use Special:Allpages/User:Tim_Starling to see subpages. Slow, but it works.

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

I've created an extension that does this. It is at <a
href="http://meta.wikimedia.org/wiki/User:Joshurtree/SpecialListSubPages">http://meta.wikimedia.org/wiki/User:Joshurtree/SpecialListSubPages</a>.
There's another one at <a
href="User:Juxo/Extensions/ListSubPages">User:Juxo/Extensions/ListSubPages</a>.

Special:Prefixindex/{{NAMESPACE}}:{{PAGENAME}} might be a workaround for some
pages (also in the main namespace).

It helps at
http://en.wikipedia.org/wiki/Special:Prefixindex/:A-B_Helicopters_A
but *not* at
http://en.wikipedia.org/wiki/Special:Prefixindex/:M

offers limeted help at
http://en.wikipedia.org/wiki/Special:Prefixindex/User:Gangleri

this enhancement has a few ways that allow people to have the same result
(special:allpages and Special:Prefixindex), so I think the priority should be
below average.


Well personnaly, I don't like the idea of having links to subpages for the
following reasons :

*It will become ugly if the are many sub-pages
*Many portals, for examples uses subpages (see for fr:
http://fr.wikipedia.org/w/index.php?title=Special%3AAllpages&from=&namespace=100)
as "local" templates

(to have automated links to all the subpages, I meant)

This should be a feature that is explicitly added through a tag like the
_NO_TOC_ element or something like it, and done at the discression of the person
who is creating the page.  If it is ugly like you are suggesting, it does not
have to be added.  While it may be a low-priority for projects like Wikipedia,
it is an essential feature that would significantly enhance the Wikibooks
projects, where multi-page documents are normal, not the exception, as well as
Wikisource.

(In reply to comment #10)
> This should be a feature that is explicitly added through a tag like the
> _NO_TOC_ element or something like it, and done at the discression of the person
> who is creating the page.  If it is ugly like you are suggesting, it does not
> have to be added.  While it may be a low-priority for projects like Wikipedia,
> it is an essential feature that would significantly enhance the Wikibooks
> projects, where multi-page documents are normal, not the exception, as well as
> Wikisource.

In that case, we could just make [[Special:Prefixindex]] a little more
aesthetically-pleasing (perhaps getting rid of the layout table), so that the
page author can include {{Special:Prefixindex/{{FULLPAGENAMEE}}}} somewhere in
the page.

In reply to comment #7: you can exclude false positives by adding / at the end
of the query, like this: [[Special:Prefixindex/User:Lupin/]]

A couple of tangential remarks:

{{Special:Prefixindex/User:Lupin/}} is nice, but
{{subst:Special:Prefixindex/User:Lupin/}} doesn't work properly (it gives a
random uid).

I'd like [[Special:Recentchangeslinked/Special:Prefixindex/User:Lupin/]] to show
me recent changes to pages in my userspace.

Keep in mind, what I'm trying to suggest is the need for a dynamic list of pages
for projects like:

http://en.wikibooks.org/wiki/Japanese

where new users will sometimes contribute a new page without updating the main
table of contents, or worse will work on something on the main table of contents
page and accidently delete a link to a subpage.  This issue alone is the cause
for a substantial number of orphaned pages on Wikibooks, and has resulted in
often duplication of content simply because a second user (usually new to
Wikimedia projects or even Wikis in general) will go and recreate a very similar
page.

(In reply to comment #13)
> Keep in mind, what I'm trying to suggest is the need for a dynamic list of pages
> for projects like:
> 
> http://en.wikibooks.org/wiki/Japanese
> 
> where new users will sometimes contribute a new page without updating the main
> table of contents, or worse will work on something on the main table of contents
> page and accidently delete a link to a subpage.  This issue alone is the cause
> for a substantial number of orphaned pages on Wikibooks, and has resulted in
> often duplication of content simply because a second user (usually new to
> Wikimedia projects or even Wikis in general) will go and recreate a very similar
> page.

Perhaps an Index page at [[b:Japanese/Index]] would be helpful for that
textbook: it would contain {{Special:Prefixindex/Japanese/}}, as suggested above.

Made some tests at
http://test.wikipedia.org/w/index.php?title=User:Gangleri/tests/bugzilla/00233&oldid=725#advanced

Please do not hesitate to make / propose changes to
http://test.wikipedia.org/wiki/Template:Show_hide in order to use a minimal
width for the 'hide'  version; have it floating right (or left on RTL wikies).

There are two special pages which can do this, and an extension for insertion
into pages. I'd be inclined to resolve this as fixed...

I've resolved this as fixed. Special:Prefixindex works beautifully, it even
works with more than one subdirectory.

As for subst:ing not working that's only necessary to make fixed lists less
taxing to the server; for them it's not all that hard to copy the whole list
yourself and then search-'n'-replace the tabs with ]] [[, which is exactly how
it's had to be done up until now.

Joshurtree's more specialised solution looks pretty easy to both install and
use, and I'd certainly like to see it or an evolution of it added into the core
MediaWiki codebase someday.