>I'm not sure why you think the pagename heirarchy would render this
>useless, but I might have missed something when researching the
>category features.
Apologies for not being clear. It will not render the idea of
categories useless. Just that the category pages (with automatically
generated list of articles) will look ugly, because you can't change
display name of an article for that list. I had this problem in MZKB
when I first tried to make use of categories. Things have been improved
since then, but some left-overs are still there, for example on
<http://kb.mozillazine.org/Category:Example_code> page (scroll to the
very end of that page). It isn't now as scary, as when all those
articles were listed under "D". My point was that unfortunately
mediawiki software wasn't designed with such usage in mind, so the
categories will not be as pretty as they could be.
>Page names
>have to be unique enough so this doesn't happen, which means they have
>to include enough information that people know exactly what they're
>linking to...thus JavaScript:Reference:Core
Reference:Objects:Function.
>Even removing the Reference:Core Reference part would be problematic,
>in that someone may create a Pocket Reference, and someone else might
>write about the Function object in one of the Guides or somesuch.
>
>It is definitely something to try to minimize, but I think the only
>place that the page names will get really problematic is in the
>book-length manuals. An article about JavaScript, for example, would
be
>something like [[JavaScript:Articles:This is an Article about
>JavaScript]].
>
>If anyone has a better solution for ensuring no namespace collisions
>between pages while also allowing for a bit of heirarchy (the
>breadcrumbs system currently works of the pagenames, but could be
>rigged to read off something else, I suppose), please let me know.
>
You have a point here. I said it myself that short article titles a la
wikipedia may not work here.
I'm not sure though if putting the *whole* "path" to the article in its
name is a wise idea. After giving it some thought (while discussing
rules for MZKB), my current position is that categories and
subcategories should be used to define the "path", while the article
title should be as short as possible, while being unique.
In support part of MZKB this meant a switch to short article titles,
with application name in parentheses when necessary, e.g. "Safe Mode
(Firefox)". For DevMo it may mean
[[Core_JavaScript_1.5_Reference:Objects:Array]] instead of
[[JavaScript:References:Core_JavaScript_1.5_Reference:Objects:Array]].
You see, the point is that "Core_JavaScript_1.5_Reference" already
contains enough information to be an unique prefix.
"JavaScript:References:" is redundant in this sense. (Same for
":Articles:" document type.) Well, that's just my opinion.
>> What's even more important, the wiki source of some pages becomes
>> unreadable, see [link 1] or [link 2] for example.
>
>I don't find that particularly unreadable. It's not ideal by any
>means, but once you get the hang of eyeing the wikimedia markup,
>it's relatively straightforward, I think.
It's not the wiki markup that makes it hard for me to read (I'm used to
wiki). It's the fact that in internal links ("[[A | B]]"), "A" is too
long, makes it hard to follow the text itself. Well, maybe it's just
me.
>One of the tricks I use is to do
>my markup in a separate text editor, then just copy/paste it in. For
>minor changes, it can take a min to orient yourself within the linking
>code, true.
I don't see how that helps. Do you have an editor that understands wiki
markup?
>Again, if there's a better solution available, I'd love to know about
it.
Nope, sorry. I'll try to write a greasemonkey script to work around
that.
>> filesystem/url-like shortcuts, like [[.:blah]] for links to a
>>"sibling" article and [[..]] for a "parent" article
>
>Possibly, and definitely something to look into. Good suggestion for
>a MediaWiki extension, I think.
>
While I'm dreaming, support for shortcuts would be cool too. E.g.
[[%jsref:Array]] becomes [[JavaScript:References:Core JavaScript 1.5
Reference:Objects:Array]].
>> I'm not a PHP person, but from
>> what I've seen in mediawiki, they don't have support for these kinds
>> of extensions, so it will cause problems when you need to upgrade
>> wiki software.
>
>MediaWiki does support extensions. The breadcrumb stuff we have has
>been written as an extension, which lives in the "extensions/"
directory
>of the MediaWiki installation, and is simply included via the
>LocalSettings.php file. They should not impede the software upgrade
>path at all, so long as any addons we write are done similarly.
>
As far as I understand (I tried to look what kind of hooks mediawiki
has - some time ago), this is the only kind of extensions it supports -
you can define special processing for custom tags. IIRC, the output of
such extensions must be HTML, and cannot include wiki formatting. I
would like to be proven wrong here, though.
Thanks for your reply and clarifications, I appreciate it.
-Nick
_______________________________________________
mozilla-documentation mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-documentation
