MediaWiki to do
From WhyNotWiki
Aliases: Transitional wiki, Interim wiki, MediaWiki to-do list
This is for MediaWiki-configuration-related to-do items for this site. This is my plan for making MediaWiki as tolerable as possible, allowing me to continue to use it until I'm at the point where I can start moving away from it (or maybe make it tolerable enough that I don't want to move away from it).
Parent article: WhyNotWiki:To do is for any to-do items for this site that aren't specifically MediaWiki-configuration-related.
See also: WhyNotWiki:Conventions for conventions/policy; Information management system
cropastrco mondel acerre taboel noreleldr Workflow: When an item on MediaWiki to do becomes resolved/finished, move the item to How to configure MediaWiki or MediaWiki bugs and solutions (or another appropriate page) for future reference.
[edit] To do
[edit] Make it so quick and easy to drop/append stuff onto a page that I won't even be tempted to keep offline notes/lists
(not with MediaWiki?)
Even if I just have a "scratchpad"/"unsorted notes"/whatever section for each topic, that's still better than having that scratchpad offline. Currently it's too tempting to just add stuff to the bottom of a local offline scratchpad. That's what I often do. With the plans of coming back and adding to the online page "soon". But that never happens.
So my new theory is, even if I only add it the ballpark right topic (for instance, Ruby, rather than one of the more specific topics of Ruby), that's better than having it offline, not categorized at all, in the middle of a huge long list of uncategorized/unsorted notes.
How to implement?
"Quick add" box that appears on every page: Start typing the topic name; it will Ajax auto-complete. Enter your note. Click submit.
That will create a new record for your note, with the proper timestamp and everything, filed under the topic you selected.
Later, you can worry about moving it to a more specific topic (with drag and drop, conceivable), revising it (it's okay to add super-rough notes!), and integrating it.
[edit] 
New extension: Ability to embed ActiveScaffold into a page
Mainly to show records on the page. But I think it will be possible to expose the full features of ActiveScaffold, including creating new records (scoped to the current topic) and editing existing records. All actions are dispatched and processed in the background through Ajax anyway, so I don't need to worry about the user leaving the wiki page because the form posts to a different page/application.
Probably will display it in an iframe which sources a Rails app with the scaffolds? Or is it possible with just a simple div??
First planned usage: convert scattered records to-do list items into actual records, tied to that topic, and then query for those records, and dynamically find and display them on the topic page...
[edit] [conventions (category)] delimitable sections
By this I mean that both the start and the end of the section is delimited, not just the start of the section (as in by a heading) as is normally the case. Delimitable sections
How exactly? With templates, of course. See {{Include section}}.
{{section|1|Title of section}}
contents...
paragraphs...
{{section end}}
The first argument would be the heading level (h1, h2, etc.) and would be optional. Perhaps make 4 both the maximum and the default.
And since I don't care as much about font size (making a level 1 heading larger than a level 2 heading, for example) as I do about the end of the section being delimitable and each subsequent nesting being visually indicated via indentation/left border, I think the benefits outweigh the drawbacks.
[edit] Subtask: Convert all existing '===' headings to delimited sections
Depends on: Having ActiveRecord models.
The '===' obviously indicates the start of the section. And I'll try to use pretty much the same (identical?) logic as MediaWiki does when you do Edit Section, to determine the end of the section: probably just read up until the next section of the same level.
Will have to take into account '==' characters that are escaped -- embedded in
</code> tags, for instance. So I may need some kind of actual ''parser'' (as opposed to simple regexp / heuristic string manipulation)?
=={{3}} Ability to permanently delete a page==
If you have something sensitive that you accidentally put on a page (like a password), then you should be able to permanently delete it (so that it isn't recoverable?)... It should no longer be available from the revision history.
=={{2}} Drag and drop reordering of sections==
=={{2}} [Done?] Ability to have a redirect page redirect to any URL==
Not just to an internal wiki page.
This will become especially important/necessary if I start transitioning my wiki page by page to a different system. Then I'll want placeholders for all the pages that have already been moved over, and I'll want them to redirect to the new system, so that if someone lands on that page, it's as seamless and transparent as possible; in other words, they shouldn't have to click again just to go to the new URL!
[Might be possible using interwiki prefixes? But not ideal...]
=={{3}} Ability to know if a link is just for a redirect (alias) page==
Would be useful for spotting unwanted uses of {{section category|unpreferred synonyms}}, when the options are all listed together, as is the case on the [[Naming conventions]] page and with the [[Template:Aliases]] template.
So that one can better enforce a naming convention and prevent duplicate articles/titles/categories from cropping up.
Currently, we can tell at a glance if an unpreferred name is ''not used at all'', because it will be a red link (a link to a non-existent page) if it is.
But an even ''stronger'' way of enforcing a naming policy than simply having the unpreferred synonyms lead to '''non-existent pages''' is to have them lead to '''redirect pages''', which redirect to the page for the ''preferred synonym''.
Eventually, I'd like to have all the ''unpreferred'' synonyms that are listed as ''aliases'' for a name/title/article actually be redirects.
Once we make that switch, however, it becomes harder (impossible) to tell at a glance by looking at link color if a usage of an unpreferred synonym is ''wanted'' (it's a redirect page) or ''unwanted'' (it's a duplicate of another page, the page whose title is the preferred synonym)!
The only way to find out would be to follow the link, which is a waste of time, and I'd never do it because it wouldn't be worth the trouble. Therefore I think it should be possible to tell if a link leads to a redirect page ''without'' following/clicking on the link.
=={{1}} Every link has an edit link==
Hack source so that everywhere it outputs link, also outputs [e] link to edit the target page.
==Make sidebar more powerful, flexible, and hierarchical==
You should be able to browse the entire category tree (perhaps using the same technique that the CategoryTree extension uses).
It should show all (or at least the most major ones) top-level categories, and allow you to expanding nodes and dig as deep as you want to. You would be able to browse to any page in the entire wiki without leaving the comfort of your navigation bar!
You should also be able to jump directly to the edit page for any article ... but that feature request is categories elsewhere, because it applies to more than just the sidebar: it applies to all nodes displayed by CategoryTree, and even (perhaps) ''every'' internal link displayed in the entire wiki.
Problems with current:
*Currently it doesn't seem to let you use URL's with query params (? and & characters).
==↓ special character list==
get a clickable character list like Wikipedia has, allowing you to insert special symbols and foreign characters
=={{1}} [Done?] Make it so that the category trees are closed by default==
Because when we list some of the top of the page and the category has many members, it is very distracting and takes up too much space.
=={{3}} Show a category tree for each category automatically==
And each tree should let you browse ''up'' the tree, to get at any ancestor category node (and its article children--i.e., main page for that category).
==Create category page for you automatically==
When a blank category page is saved, it doesn't really save, and so the category doesn't really exist yet.
This creates the following problems:
*When you search for that category, it won't be listed in the search results!
*CategoryTree will complain that the category doesn't exist yet.
'''Solution''': hack the source so that it creates category pages for you automatically.
'''Problems with this solution''':
:'''Orphaned category pages''': An editor may quickly brainstorm about what categories to put an article in, and decide at that moment that category A, B, and C would be the best categories to throw it in. "Better too many categories than too few." But later he may decide that some of those categories is redundant or unnecessary, so he removes it from that article's category list. But the (nearly) empty category page will still exist and will show up in search results.
:Oh well. In this case, I'd much rather have orphaned categories show up than to ''not'' have a category show up simply because I forgot to actually create the category page for it.
=="purge" button in toolbar==
(see "special cite" extension)
==bookmarklet for citing/"bookmarking" current web page==
or other script to take the current page, extract title and URL, and build the citation wiki text for it (copy to clipboard?)
==export from/link to Wikipedia==
toolbar link for go to corresponding page with the same title in Wikipedia
Export corresponding page from Wikipedia and import into this page
==Category intersections==
I think DynamicPageList extension solves this partly: it lets you list pages that belong to 2 or more particular categories.
It would be nice if the search feature had this knowledge too: "Only list pages that belong to '''all''' of these categories:" (checkboxes).
===Use cases / Motivation===
Pages that are in both Rails and Questions. Don't have enough to necessitate making a new category "Rails Questions", so (at least for the meantime), I just want to have a "virtual category" that exists at the intersection of "Rails" and "Questions".
==Fix for: Unintuitive to make a new page under an existing category==
It's often most intuitive (from a user's standpoint) to go to a category page and expect to create a new page in that category ''from there''.
If it was a "normal page", I'd just tell that user to edit the page, create a link to the new page you want to create, save, click on the link, and start editing your new page.
But that doesn't work with categories... In fact, it's the complete opposite!
I have to tell that user to ''start'' by creating the new page and then create a link back to the ''category''! Completely backwards!
I can sort of understand why MediaWiki uses this method to assign a page to a category...after all, it lets you put a page in many categories, for example...
It ''works'', but... it's not intuitive.
It's sort of an ''abuse'' of the link syntax. You're not really linking to that other page... (at least not in the same way you would link to other pages using the exact same syntax.)
Anyway, although I realize the need to be able to add categories to page ''starting at the page'', I think it would be also good (from a usability standpoint) to allow the user to also be able to create a page under a category ''starting at the category page''!
It could be implemented as follows:
Add another text box under the page (near where the Summary text box would appear) with a button "Create new page".
You fill in that box with the name of your page and click the button. Presto! Easy. Intuitive.
==ActiveRecord models for doing maintenance/fixing/exporting/migrating of data==
Could be one step towards migrating to a new, Ruby-powered wiki. But could also be useful in the meantime, for batching changes on many changes. Just look through all the pages and make a substitution, etc.
==Append to bottom of page feature==
So you don't have to click edit and wait for whole giant page to load.
A little text box with "Append to top", "Append to bottom" buttons. Use to add to categories, etc.
Partially solved by http://en.wikipedia.org/wiki/Template:Talkheader
* '''Put new text under old text.''' <span class="plainlinks">[{{fullurl:{{PAGENAME}}&action=edit§ion=new}} Click here to start a new topic]</span>.
==Fix heading levels when transcluding==
Need to find the code that does the transcluding...
==Categorize sections of page==
MediaWiki only lets you put a whole article ''page'' into a category, not an individual ''section''.
(Although, if I move towards making smaller objects, I could probably categorize them as I'm wanting to...)
Use <code>{{section category}}</code> template.
<pre>
(this code is {{section category|Not yet released}})
produces:
(this code is [Not yet released (category)])
It would be nice if we could then get Category:Not yet released to link back to the right paragraph on the page even, not just the right section, and certainly not just the right page.
But currently all this will do is get the category to link back to the right page, where we'll have to scan the page to find the section/paragraph that actually belongs to the category.
The problem with this is that it marks the whole page as "not yet released", which isn't accurate. So again, the solution seems to be to break the section off into its own "article".
Of course, if this section/paragraph is its own independent object, we can just link back to that object... The big thing to consider here, though, is that it wouldn't be in any context. That might actually be good thing, though (?), as it forces you to make sections stand-alone-able, so that they make sense when viewed alone. See next section, "Standalone sections":
[edit] Relationships
Ideal solution: Information management system / Relationships
Relationships may be tricky to implement in MediaWiki, since it seems the only type of links that are biderectional are Categories. But that only lets you define one kind of relationship (belongs-to-category), and that relationship must be between an article and a category.
I want to be able to define a relationship between two article pages. For instance, between a problem article and a solution article.
[edit] [Workaround (category)] idea 1: simple link
Revision history '''Is a feature of''': [[MediaWiki]]
Problems: The link is only one-way. MediaWiki doesn't know that MediaWiki has-feature Revision history. Relationships need to be two-way!
[edit] [Workaround (category)] idea 2: templates, categories, category tree
A rather complicated, kludgy workaround, but I think it would work. It wake use of the bi-directionality of category links.
Revision history
{{is feature of|MediaWiki}}
Template:is feature of
<includeonly>
'''Is a feature of''': {{{1}}}
[[Category:{{{1}}}/features]<includeonly>
Mediawiki:
<categorytree>{{PAGENAME}}/features</categorytree>
Problems: Even though this effectively produces a bidirectional relationship, it only allows you to state the relationship from one end. It feels lopsided. No end of the relationship is more important from the other; you should be able to create/edit the relationship from either end. In this example, we stated a is-feature-of relationship from the feature end, but it should be possible to state a has-feature relationship from the software program end and have the same effect.
[edit] [Workaround (category)] idea 3: custom extension, parser hook
...
[edit] Standalone sectons
Even though we try to make a section so that it can be viewed/edited on its own -- independent of the context in which it would often be viewed --, it would probably be nice to be have a list of links back to all the places where this section is "included".
Requires a good implementation of: Bidirectional links.
[edit] Add ability to rename an existing category
Sort of like the RenameUser extensions lets you rename users.
[edit] Add ability to move a normal page into a category page.
Surely it's possible to change it to a different namespace. Templates can be moved to non Template-namespace page titles.
But categories are special...they have bidirectional links that probably have to be tracked... Still, it's probably possible.
[edit] Extract section and move to new page feature
This is a [workaround (category)] for this problem: Scattered records
Add a link beside the section edit link: "move to new page".
It does all this with one click: creates new page, moves existing section content there, removes that content/section from old page.
Begs the question: "Do we need page sections at all?" on Information management system / Sections of page
Why would we have sections at all?
Because, at least in the interim, the quickest and most natural way to flesh out a content page is by breaking it into headings/sections.
So, in order to not bog down the creative process, perhaps one should let the user again this way and then later, only once the content has been fleshed out and stabilized a little bit, then one can worry about extracting the headings into proper independent pages/objects.
Thoughts about revision history:
The revision history/ancestry should be copied to the new page for the "section". Yes, that means that when you look at the history for this newly created section, the revision right before the one in which the section was officially created will be an exact copy of the full page from which it was extracted -- including other sections on the page!
Yes, I know this results in rampant duplication, which is bad. Unfortunately, I don't know any other practical way of retaining revision history. I figure that it's better to keep too much information (at the expense of actually duplicating that information), then to not retain enough version history information with the newly created section.
Therefore this is only an interim solution, as the ideal solution would be to have all sections automatically be their own objects to begin with, and have the software smart enough to detect that the user is renaming or moving an existing category and to record that in the revision history accordingly. (See change logging.)
Implementation
Perhaps look at http://meta.wikimedia.org/wiki/Help:Inputbox extension to see how they did it.
[edit] Disable talk pages?
Since I never check them...
[edit] ↓↓ Disable Alt-d (delete)?
[edit] Quotes/citing sources
Until my grand solution is ready...this will have to do...
Short quotes:
(source name) :content :content
or
content ((source name))
Longer quotes:
(source name) <blockquote> content </blockquote>
":" after source name? Naw... not necessary...
Example:
http://beaver.net/slides/ruby/10-easy-pieces.html <blockquote> * Perform file i/o operations on a string * Lets you use same code path for manipulating strings and files </blockquote>
Assumed to be exact quote (with ... sometimes implied) unless otherwise noted.
Require ... for all inner ommisions??
[edit] Create (blank) category page as soon as you add an article to that category
I don't like how, after adding article A to category Cat:A, the link to Cat:A appears red, indicating that it doesn't exist.
I say, define "exist" in the context of categories to mean "contains at least one member". I suspect that it would be easier to trick MediaWiki into thinking the page exists (by automatically putting content in edit) than to actually change the "definition" (to "contains at least one member"), but... maybe that would be just as easy.
I seldom put anything on my category pages, so it seems silly to flag the category link specially until I put something on the page. Usually I end up just going to the category page, typing a single character ("."), and saving, to trick MediaWiki into showing the category as existing.
Not only do the links annoyingly show up as red, but category tree doesn't work either for categories that don't have content on their page.
[edit] Weight/importance/interestingness
It should be possible to mark certain links, sections, and categories as "more important" than the others.
Why?
- If you have a list of links, you should be able to easily indicate to your reader which ones are the best/most interesting, without resorting to unsemantic, possibly inconsistent solutions like putting text like "good" or "interesting", putting star icons, etc. Such display features should be inferred from the semantic data, not the other way around.
- I suspect that some category associations are stronger than others. But I need more evidence to support this.
[edit] [conventions (category)] A way to specify a license for the page/section
For lack of a better way, just use a template containing a category.
[edit] How to add metadata
http://meta.wikimedia.org/wiki/RDF_metadata RDF metadata - Meta
[edit] How to store metadata
- In a table that links to the ID of the article/revision? That would require a separate interface though other than the wiki text text box. Perhaps rails?
- Inside of special tags embedded in the wiki text? I have reservations about that. Although it does automatically give it versioning capabilities.... but it just seems so messy and inefficient.
[edit] [problems (category)] a Category/Template can't also be in the User namespace
For example: I can't have a category called User:Tyler/Favorite songs. I guess I could have a template in the user namespace (User:Tyler/Pretty box template), but that doesn't seem quite right.
To me, those concerns should be orthogonal, not mutually exclusive.
- Each "object" should have a (data? organizational?) type, which might be one of Category, Article, Template, ListItem, etc.
- Independent of that, an object should be able to have an associated domain/scope/namespace/primary visibility/primary ownership: Public/Shared, Personal (who?), Project-specific, Group-specific, ...
[edit] Copy and pasting from web pages often produces invalid wiki markup
This is especially true for lists.
This problem could be solved from a number of directions:
- Fix it at the source (don't let the markup be invalid): Figure out where the source code is that actually decides what plain-text version of the selection gets copied to the clipboard when you copy a selection of rendered HTML in Firefox. Then fix/patch the problem there so that it generates a plain-text version that is compatible with MediaWiki.
- Let the markup be invalid and automatically turn it into its valid equivalent: This would require a script (client-side with JavaScript? server-side with PHP/Ruby?) that does some searching and replacing to munge the text into a valid form.
- Works for things like lists, perhaps. But if formatting (bold, italics, preformatted, hyperlinks) has been stripped out completely, there's no way that any post-processing can magically get that formatting information back!
Examples
Copied from http://trac.edgewall.org/wiki/TracTicketTriage
duplicate
there's already another ticket about the same issue
* If marking as duplicate, include referring ticket #s in both duplicate and duplicated tickets.
o In duplicate ticket: This ticket is duplicate of #1234
o In original request: #2345 has been marked as duplicate of this ticket
* We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket.
should be:
duplicate :there's already another ticket about the same issue :* If marking as duplicate, include referring ticket #s in both duplicate and duplicated tickets. :** In duplicate ticket: This ticket is duplicate of #1234 :** In original request: #2345 has been marked as duplicate of this ticket :* We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket.
From http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html
Resolving bugs as DUPLICATE
See this guide for screening DUPLICATE bugs. In general newer bugs should be marked as DUPLICATEs of older bugs, except when the newer bug contains more information (bug description clearer, patch already attached, lots of people already CC'ed, etc.).
Resolving bugs as WORKSFORME
You can resolve a bug as WORKSFORME (WFM) if it can't be reproduced on the reported hardware/OS.
You should not resolve a bug as WFM if:
* the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows).
* the bug has been reproduced by some people but can't be reproduced by other people.
should be:
====Resolving bugs as <code>DUPLICATE</code>==== See this [http://www.mozilla.org/quality/help/screening-duplicates.html guide for screening <code>DUPLICATE</code> bugs]. In general newer bugs should be marked as DUPLICATEs of older bugs, except when the newer bug contains more information (bug description clearer, patch already attached, lots of people already CC'ed, etc.). ====Resolving bugs as <code>WORKSFORME</code>==== You can resolve a bug as <code>WORKSFORME</code> (WFM) if it can't be reproduced on the reported hardware/OS. You '''should not''' resolve a bug as WFM if: * the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows). * the bug has been reproduced by some people but can't be reproduced by other people.
[edit] Extensions
[edit] Get EasyTimeline to work
[edit] Music notation
Get http://wikitex.org/ to work. With music.
[edit] [Syntax highlighting (category)]
Find or create a parser-function extension that adds syntax highlighting.
<syntax_highlight language="ruby"> a = "hi" puts a </syntax_highlight>
More at Syntax highlighting.
[edit] random quote extension
For use on front page.
In addition to showing the quote and its author, also show some interesting metadata about the quote: categories that it's in.
↓↓ Filtering: Perhaps have a tiny link beside each category link labeled "don't show quotes from this category".
[edit] Modifications to CategoryTree (to-do)
- it shouldn't complain that the category doesn't exist as long as there are members of the category (look at the members, not at page content)
[edit] Bug: Links displayed by a category tree should not be links if pointing to self (current page)
Should be bold just like normal internal self-links.
[edit] Figure out why category tree doesn't take page name variable as contents -- ref does
[edit] Make it show pages (not just subcategories) in the CategoryTree even on category pages
Seems that the default behavior there is mode=categories, but I want it to be mode=all !
[edit] Show [one-line] description next to each page/subcategory
This is what I used to do back when I made my category tree manually (f.e., on Category:Software_development)...I don't want to lose that ability just because I switch to automatic creation of trees!
[edit] Allow it to be used in a template that gets included on many pages
Want to do that so I can have a consistent set of options/style that I use with it.
That would also let me put pages that use it in a category, like "Pages that have a CategoryTree at the top of the page".
See Sandbox
http://meta.wikimedia.org/wiki/Help:Template#When_parameters_do_not_expand
Parameters do not get expanded when they are inside tags (HTML, wiki, or extension), or between <html></html> tags
The following will not work within a template, because the parameter is not expanded
<myextension xparam={{{tparam}}}> ... </myextension> <html><span onmouseover="return escape('foobar')"> {{{1}}} </span></html>This continues to be true into version 1.8.2.
[edit] Make the categories-this-page-is-in links at the bottom of a page use CategoryTree
This solves the "Must be able to go from page A to main content page for category A with only one page load" problem:
(This isn't a problem if we allow Category pages to be Content pages, so for this discussion we'll assume that that is not the case.)
If I'm on some page A that is a part of Category:MediaWiki, I want to be able to jump to the main content page for that category. The way it is now in MediaWiki, I would first have to jump to Category:MediaWiki, the find the MediaWiki page listed there and click on it -- 2 page loads!
So if we add the concept of a "main content page" that is always associated with a category, then we can just have it (always) show a link to both the content page and the category page.
This begs the question, though: What good is a category page, then, if it has no content? (Since I'm planning on putting a CategoryTree at the top of the main content page, that basically gives the content page all the functionality of a category page.)
- I can't think of how it is helpful.
- Wikipedia makes a distinction between the main page for a topic and the category page, but are they a special case? Usually the category page has quite limited content, I think, perhaps a brief description of what types of articles are contained in this category. (example??)
We could just not have category pages. Use the categories but have nothing on the category page itself. But the link to the category page would still be there and would be red (non-existent page). So we could create and save it with nil content... but that just seems silly.
So I'm back to sort of wanting to just make the category page a content page.
Partial solution: Just get rid of 'class="new"' will probably make those links not red.
[edit] Possible [workaround (category)]
Use <code>{{category|Some category}}</code> instead of <code>[[Category:Some category]]</code>.
Then create the <code>{{category}}</code> template, which inserts a CategoryTree at that location in addition to having the page to the specified category.
Problems with this: If you wanted to have all categories displayed this way, then this wouldn't be a good solution: you'd have to migrate all existing category "links". And you couldn't enforce that all new category "links" would use this method.
[edit] Problems with this idea
- may increase page load/rendering time
- may make the page look cluttered, especially if it has many categories. (Possible solution: only show trees for the main categories, if such a thing can be defined.)
Solution: Don't preload the tree. Instead, load it via Ajax when they click on the category.
[edit] Complete / Resolved problems
[edit] Problem: Duplication between an article's categories and its associated category's categories
Solution: List the categories in one place only: the article's associated category. Then transclude Template:Has associated category from main article page. Template:Has associated category will in turn transclude the associated category, which will cause those categories to also be applied to the article itself.
[edit] Article metadata
[edit] 1
MediaWiki edit (Category edit)
[edit] 2
Web site to do edit (Category edit)
