-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brion Vibber wrote:
Edward Z. Yang wrote:
Current behavior of Redirects totally masks any
text that comes
after the #REDIRECT [[]] declaration.
The main reason this is done is that extra text containing links will
foul up the link database: the single outgoing link from a redirect
is used to keep track of where that redirect leads to.
Redirect pages really oughtn't to be stored the way they are, it's a
nasty hack. This should be recorded properly as metadata listing the
exact target as a cleanly machine-readable field.
Ah... I see. Didn't do my research:
- From Wikipedia:Redirect
Everything after the redirect line will be blanked
when you save the
page. Any text on the same line as the redirect will stay, but will
not be visible unless someone edits the page.
Although I'm a bit confused with your last paragraph: did you mean that
the redirect pages are a hack, or the way they are being stored is a
hack? The technical specification was to serve as a suggestion, I think
you get the general gist of the idea though... leave it to the
developers to wrangle over the implementation.
Lee Daniel Crocker wrote:
(Suggested
redirection feature)
Why add a complicated feature for what is simply a misuse of a
current one? The article you cite should simply be a one-sentence
article with a link, not a redirect.
There's absolutely nothing wrong with one-sentence articles.
IMHO:
- From Wikipedia:Redirect#What_do_we_use_redirects_for.3F
* Sub-topics or closely related topics that should be
explained
within the text: Distributed denial of service redirects to Denial of
service
and
- From Template:R_with_possibilities
This is a redirect from a title for a topic more
detailed than the
topic of the page this redirects to. Eventually if the target page
becomes too big, this redirect may be replaced with an article carved
out of the target page.
For more info. follow the category link.
Interestingly, this template doesn't work right now, but it is included
in some articles under the syntax:
- From Asia Minor
#REDIRECT [[Anatolia]]{{R with possibilities}}
An aside for a moment, I think people are jumping the gun adding these
sorts of templates, but I have found out there is sort of a demand for
this sort of feature.
I do not think that one sentence articles are acceptable, and the
current user guide suggests that redirects with possibilities should
stay redirects with possibilities, not one sentence articles. This idea
would help these redirects greatly when it comes to disambiguity.
Unfortunately, it's kind of difficult to tally exactly what links the
template "R with possibilities" because the template is on redirects,
and redirects automatically have their linkage expanded (so you get a
lot of irrelevant stuff in there).
Rowan Collins wrote:
I can't say I'm keen on having things that
aren't links bracketted
like links - IIRC, the previous implementation had things like
#redirect [[Foo|is a kind of]], which was just confusing. My
suggestion would be
#REDIRECT [[Foo]] BECAUSE For info on Foo, see [[#Foo]]
or maybe
#REDIRECT [[Foo]] #BECAUSE For info on Foo, see [[#Foo]]
to make it more clear that "#because" is a magic word, not part of the
explanation.
The text would then be displayed below (and formatted with) the
"redirected from" message (which should maybe be more obvious).
Very cool suggestion. I like it.
I'd still like to see
http://bugzilla.wikimedia.org/show_bug.cgi?id=1521 implemented first
though, or some other way of creating more stable section anchors.
At first I though this would be some controversial feature, but checking
out the bug page, it seems quite reasonable. It would help greatly in
all cases where anchors are used (although it would take a while to get
it standardized and stuff, plus, old links would break as soon as the
new ones were added even if the title itself didn't change).
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website:
http://www.thewritingpot.com/
GPGKey:0x869C48DA
http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFCdtpVqTO+fYacSNoRAtn+AJ9AYyMRWGUFvFZvIP+MKdkzqBEfOgCePClJ
VUmNnKUO5e4lBNJH7hzSFAw=
=S+yV
-----END PGP SIGNATURE-----