putting '/' at the end works by just removing the ../ or / prefixes from the link text. so [[../../a/b/]] becomes a/b. isn't it more logical for it to become 'b'? the meaning of '/' at the end then behaves like 'basename' shell command.
to achieve this, in Parser::maybeDoSubpageLink, i changed the lines '$text=...' to '$text = array_pop(explode('/', ...))'.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ittay Dror wrote:
putting '/' at the end works by just removing the ../ or / prefixes from the link text. so [[../../a/b/]] becomes a/b. isn't it more logical for it to become 'b'? the meaning of '/' at the end then behaves like 'basename' shell command.
What?
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
if i use '[[../../a/b]]', the link's text is ../../a/b. if i use '[[../../a/b/]]', the text is a/b
i think it is more logical, that in the second case, the text will be 'b'. that is, the last path componont, not just the part without dotdot. i think it is better, since adding '/' at the end strips some path components anyway.
Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ittay Dror wrote:
putting '/' at the end works by just removing the ../ or / prefixes from the link text. so [[../../a/b/]] becomes a/b. isn't it more logical for it to become 'b'? the meaning of '/' at the end then behaves like 'basename' shell command.
What?
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtwUCwRnhpk1wk44RApJkAKCRueznIu6uCDGDgmZQn2Jc52BzfQCeNw2l pU/xi6fbUnj4S7bqfdgLzSo= =i+Mk -----END PGP SIGNATURE-----
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I was also wondering about the original decision to use the / to indicate a subpage, as you then get the problem that you cant have a subpage, 'team 2007/2008', would it be very complex to consider changing the wikitext from [[parentpage/subpage]] to [[parentpage//subpage]] to indicate a subpage as then [[teamx//2007/2008]] could be a valid parent / subpage combination.
Ta
John
Ittay Dror wrote:
if i use '[[../../a/b]]', the link's text is ../../a/b. if i use '[[../../a/b/]]', the text is a/b
i think it is more logical, that in the second case, the text will be 'b'. that is, the last path componont, not just the part without dotdot. i think it is better, since adding '/' at the end strips some path components anyway.
Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ittay Dror wrote:
putting '/' at the end works by just removing the ../ or / prefixes from the link text. so [[../../a/b/]] becomes a/b. isn't it more logical for it to become 'b'? the meaning of '/' at the end then behaves like 'basename' shell command.
What?
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtwUCwRnhpk1wk44RApJkAKCRueznIu6uCDGDgmZQn2Jc52BzfQCeNw2l pU/xi6fbUnj4S7bqfdgLzSo= =i+Mk -----END PGP SIGNATURE-----
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 24/01/07, Ittay Dror ittayd@qlusters.com wrote:
if i use '[[../../a/b/]]', the text is a/b
That sounds like a bug.
i think it is more logical, that in the second case, the text will be 'b'. that is, the last path componont, not just the part without dotdot. i think it is better, since adding '/' at the end strips some path components anyway.
No, because pages don't exist in "paths" - pages exist as a whole. Therefore, the default link text should consistently and reliably inform the user where they are going.
There might be some scope to sort out the pipe trick to work properly with subpages, though, but then one reaches the obvious problem of how much of the title to exclude.
Rob Church
Rob Church wrote:
On 24/01/07, Ittay Dror ittayd@qlusters.com wrote:
if i use '[[../../a/b/]]', the text is a/b
That sounds like a bug.
Yes but a bug my editors really like - don't take it away please, for example if you want to create a link to a first daughter page, the [[/daughter/]] creates a nice 'daughter' as 'pretty' link, other wise they would have to do '[[/daughter|daughter]] to get the same result with a pipe. it does save a lot of typing !
my 2p worth.
There might be some scope to sort out the pipe trick to work properly with subpages, though, but then one reaches the obvious problem of how much of the title to exclude.
I agree with this problem.
Rob Church
Ta
John
i thought the '/' at the end is the equivalent of the pipe trick for sub pages. it is quite useful, since in many cases, the context is known from the page and the '/' trick doesn't require me to give the link text. in my case, the wiki documents a product. so 3.1/Manual/Overview is the overview page in the 3.1 version's manual. in the overview page, i have links like [[../some feature]]. without the '/' trick, the text will be rendered as '3.1/Manual/some feature', which is too long, since 'some feature' is enough. when the user clicks the link, the title will be '3.1/Manual/some feature', which is ok i think.
Rob Church wrote:
On 24/01/07, Ittay Dror ittayd@qlusters.com wrote:
if i use '[[../../a/b/]]', the text is a/b
That sounds like a bug.
i think it is more logical, that in the second case, the text will be 'b'. that is, the last path componont, not just the part without dotdot. i think it is better, since adding '/' at the end strips some path components anyway.
No, because pages don't exist in "paths" - pages exist as a whole. Therefore, the default link text should consistently and reliably inform the user where they are going.
There might be some scope to sort out the pipe trick to work properly with subpages, though, but then one reaches the obvious problem of how much of the title to exclude.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org