![[Home]](http://meatballwiki.org/meatball.gif)
EditableTitle
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesOne of the tenets of the wiki model is that page names are link names (LinkIsLocation?). However, increasingly this has proven to be a problem. Plurals, conjugations, UgLy LinkPatterns, twisted WikiGrammar?, varying capitalization, SpacesInTitles, PageAliases, and translations for a MultilingualWiki all run amok when pages can only have the one title, and only the one title can refer to a page. Also, OpenCoding suggests that some readers may find or prefer new titles that are salient for a page that weren't thought of initially. AccidentalLinking can only work as well as the synchronicity of the imaginations of the TheIndividuals? making the links. Finally, TwinPages with variant spellings (e.g. CategoryHomePage vs. CategoryHomepage) cannot match without a technology like MetaWiki, but even MetaWiki cannot match variant names for the same concept.
Some solutions have been presented. PageRedirects, PageAliases, and PermanentAnchors all solve the problem in some way, but not all the ways. SpacesInTitles are particularly difficult to solve without FreeLinks, and yet FreeLinks are not appropriate for every corpus. Either way, the existing solutions are clumsy as they prioritize one title and force the second titles to exist either on separate pages (and thus remain invisible when reading the primary page) or floating in the body text proper, which lacks structural cues that identify the label as the page title. After all, a PermanentAnchor may only title a particular section, not the page. The solution is to use the explicit "PageAlias" keyword to hint the PermanentAnchor really is intended to be an alternate title, but using a keyword in the body text is a) programmatic, b) clumsy.
To RenamePages, one not only has an unnecessary step of copying & pasting the text from one page into a wholly new page, but it leaves the detritus of a deleted page around until PageDeletion can scavenge it, and it destroys the VersionHistory of the page in question which may be important for sites with FullHistory.
Furthermore, SearchEngines like Google like things like titles and headers. They do not like things like CamelCase, which they do not understand. Previous attempts to stuff hints into the MetaTag (KEYWORDS) have failed as Google ignores them. Plus, if our WikiEngine requires special hints that a particular text in the body is meant to ammend the page title, the search engines have no clue. They can only see headers and titles.
But why are titles static? Why can't titles be editable like anything else on a wiki? Titles are only addresses, and these addresses are only labels in a SemanticSpace. If a wiki is an OralCulture, the labels it uses for its ideas are up for negotiation and renegotiation like any other text on the site (LabelVocabulary?). Keeping titles constant while we can edit the body text is antithetical.
Titles in wikis should change as the content changes to more specific to what is on the page. There could be a short title that is set by a wiki mediator and the end of the title should be left editable as more content is added in. [Title Tags]
Therefore, make the titles editable. Supply a separate textfield on the EditPage? where editors can add, remove, and alter the title of a page. Allow multiple labels for a given page. You may want to make these titles comma separated if you don't want commas in your page titles. Otherwise, you might prefer to use hard returns. Let's assume comma separated for the sake of the examples here as it keeps them on one line.
So, previously, one would have a page that looked like
- This page describes what is a WikiName.
And on the EditPage?, one would see (where [] denotes an entry field)
- [
This page describes what ''is'' a WikiName.]
But in this proposal, we could provide a comma separated list of page titles on the EditPage?:
- [
Wiki Name, Wiki Names, Nom de Wiki, Page Name, Page Title, Link Pattern, WikiName]
- [
This page describes what ''is'' a WikiName.]
Which would be rendered as
- Wiki Name
- (aka Wiki Names, Nom de Wiki, Page Name, Page Title, Link Pattern)
- This page describes what is a WikiName.
Linking to this page is a matter of making a LinkPattern. Here we choose the CamelCase LinkPattern. Note the absence of the form "WikiName" (CamelCase) from the title list, but the presence of it in the body text. WikiNameCanonicalization can greatly ease the process of linking. When storing the various link titles in the LinkDatabase, store only their canonical representations. When searching the database for matching pages, we match the canonical form of the link against the canonical forms of the titles. Then, we do not need to overload page titles with their CamelCase cousins. Rather, we can store EditableTitles with SpacesInTitles, comfortable they will be accessible through existing CamelCase link practice.
Furthermore, TwinPages from SisterSites can be accommodated by adding them to your EditableTitle list. That easily promotes InterWiki linking without forcing unification of the two OralCultures trying to find a bridge. This can be doubly advantageous when WikiTunneling into separate languages, as the foreign language title can be added to the EditableTitle list and thus be found through TwinPages (e.g. "Nom de Wiki" above)--thus fostering a MultilingualWiki.
PageAlias, PermanentAnchor, and the horrid PageRedirect system are all made obsolete by EditableTitles whilst EditableTitles have the added advantage of clearly marking what actually does constitute the title of the page. To RenamePage, one will also preserve VersionHistory with an EditableTitle. A sufficiently plucky script might even do a global search and replace on referred titles.
A sufficiently plucky script might also replace the CamelCase links in the emitted body text with the proper SpacesInTitles representation as pulled from the LinkDatabase.
But, if you add a title to a page that has already been assigned to another page somewhere else in the PageDatabase, the script must give you an error, or fail safely by doing a magic edit as described on PermanentAnchor. After all, unlike previous practice, when you punch in a "new" title, you do not immediately see what is in the PageDatabase under that label. Possibly this is not a bad thing as pages with the same title may need to be unified. However, it is an extra complication.
Also, BackLink searches become more complex, as one has to search for all the various names for the text.
CommunityLore also gets damaged as the same concept may appear in the PageDatabase under many wildly differing names. Even an experienced reader may be taken by surprised by a hereto unknown page name only to discover a page they know quite well. This disrupts the construction of a LinkVocabulary? of the OralCulture. The CommunityExpectation for the StyleGuide should be for a most minimal set of titles for any page, to the pain of always reworking the title to the simplest text possible.
In the spirit of CoolUrisDontChange, one could distinguish between "active aliases", which appear on the page, and "deprecated aliases" which are just there to prevent BrokenLinks.
CategoryWikiTechnology CategoryUnimplementedWikiTechnology
I'm keen on trying this for MeatballWiki as part of my general feeling that we need to improve the organizational capabilities of wikis (other examples include DigestedChanges, DigestedSummary, AutomatedRoadMap?). As you might guess, my theory is more stuff should be editable in the wiki fashion. What do y'all think? -- SunirShah
It seems like a better UI following roughly the same principle as PageAlias, so I'm basically for it. It doesn't obsolete PermanentAnchor, though - there are still occasions when one would want to add a name to a specific section of a page. --MartinHarper
Another option is to use MetadataSyntax and DublinCore's alternative attribute, rendering the alternatives in the same way this page suggests. Doesn't let you rename a page, but everything else. (I prefer MetadataSyntax to edit-field-rot, which is my motivation for suggesting it.) -- ChrisPurcell
I'm working on this on [community-wiki: editables titles] and on a couple of other places in wikilandia.
What about the ugly square brackets in read mode? Is it of any use that they are shown? Is it of any use that they are shown?
Do you have a single line shift? <br> %%% [[<<]] -- [Mattis Manzel]
Smart Titles
[WikkaWiki] adopts a different strategy. The [SmartTitles] function retrieves the first, highest-level header available on the page and uses it as a page (HTML) title. If no header is present, then the pagename (generally, a CamelCase tag) is used instead. This solution allows easy title refactoring and increases title legibility both for humans and search engines. It also allows page titles with [special characters or unicode].
CategoryMeatballWikiSuggestion