Nickolay Ponomarev wrote:
However, having article names like "JavaScript:References:Core JavaScript 1.5 Reference:Objects:Array" strikes me as not really a good idea. It defeats one of main concepts of wiki, accidental linking (when one doesn't have to use the pipe syntax), makes it hard to move a page in docs hierarchy (so it's crucial to get the hierarchy right *now*) and makes mediawiki categories <http://meta.wikimedia.org/wiki/Help:Category> close to useless (though it looks like you're not going to use them anyways).
We'll be using Categories. As far as I know, categories are a totally independent system from any form of page naming. I could be mistaken on this, but I was under the impression that any page could be put into any number of categories, simply by adding the category tags to the page. Categories could then be nested and linked by adding them to each other, and so forth.
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.
Accidental linking is great, I agree, but if someone links [[function]], things get hairy, fast -- do they mean the function statement, or the function object? Do they even mean to link to something within the JavaScript side of things, or to something else entirely? 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.
What's even more important, the wiki source of some pages becomes unreadable, see <http://developer-test.mozilla.org/docs/index.php?title=JavaScript:References:Core_JavaScript_1.5_Reference&action=edit> or <http://developer-test.mozilla.org/docs/index.php?title=JavaScript:References:Core_JavaScript_1.5_Reference:Objects:Array&action=edit§ion=14> 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. 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.
Again, if there's a better solution available, I'd love to know about it.
I understand that this project is huge and using short article titles may not work in your case. I'm just saying, I don't see much point in making it *that* hard to create any links.
It's a tradeoff. Accidental linking is very difficult when there is room for ambiguity (such as between the function object and statement). Technical documentation simply doesn't afford us the luxury of that ambiguity.
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.
, and (2) makes the displayed title of article be the "leaf name".
Yah, we're already looking into something like this -- displaying the full pagename at the top of the page is problematic. I think we'll be able to make an extension to do something like what you're suggesting.
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.
Also from our experience at MZ wiki, dividing information into FAQs and Tips (as you suggest on your user page) makes the information harder to find by navigating wiki. FAQs should not be a branch in the hierarchy, but a special manually maintained page. All articles that are put in FAQs should have a real place in the hierarchy. Just sharing experience.
That makes sense. Thanks :)
btw, pardon my ignorance, who are the devmo drivers? fantasai and Deb?
There are currently 20 people on the devmo-drivers@ mailing list, including several staff and foundation people. Fantasai and I are two of the more active members, but discussion there was quite brisk while hammering out some of the arguments for and against wikis and so forth.
~ deb _______________________________________________ mozilla-documentation mailing list mozilla-documentation@mozilla.org http://mail.mozilla.org/listinfo/mozilla-documentation
