^_^ Complete Title backend rewrite!? A Image backend rewrite is being worked on, why not start one for the Title class as a separate project. We could compile a list of useful features in the Title system people want that we currently don't have. And come up with the most optimum way to deal with titles. However, I'm not a fan of storing both a normalized underscore version of the title, and a un-normalized space version of the title. I'm thinking display title for display, and normalized title for all the handling and other things. I think having the {{DISPLAYTITLE:}} function store the display title inside of the page table would be best. And if we made the normalized version depend on the display title then it wouldn't be possible for someone to remove the requirement that the displaytitle needs to normalize to the actual title. Some wiki would like to have that not there, and have a subtitle added when they don't match. So DISPLAYTITLE and PAGETITLE stored in the database I would think. Or we could actually to a tripple, we could decide what would be best after considering all the possible features people might want to be able to add into the title system, and consider various hooks to add which would allow people to create Title modifying extensions without hacking core. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

Well, if you've checked any number of active wiki, you're likely to run into the {{Title}} hack. Last I checked wiki like Wookiepedia and Uncyclopedia which are only second to the Wikimedia wiki in size have been using it for ages. And there are a few bugzilla entries asking for the functionality to. So it's not something void of examples, use, or demand: http://starwars.wikia.com/wiki/Star_Wars_Episode_III:_Revenge_of_the_Sith http://starwars.wikia.com/wiki/NR-N99_Persuader-class_droid_enforcer http://starwars.wikia.com/wiki/Acclamator_I-class_assault_ship http://uncyclopedia.org/wiki/Communism http://uncyclopedia.org/wiki/Game:Zork/knife http://uncyclopedia.org/wiki/Death https://bugzilla.wikimedia.org/show_bug.cgi?id=12998 I can go for allowing MediaWiki to handle case, space/underscore, and extra padding issues (Extra padding as in titles like _Summer, which have valid uses <http://en.wikipedia.org/wiki/Underbar_Summer>) natively in a title rewrite. And having an extension handle the extra cases like WikiMarkup in titles (Italics, Bolding, and class/styling of titles), stripping ()'s, allowing # for display, and other off uses which would require the use of a subtitle. However, to reduce the complaints and negative comments. Perhaps we should actually build that extension along-side a proper title rewrite as a Proof of Point, that it can be done without making it an absolute hack like it is. Also, it would let us compile a full list of all the possible and already desired features for Titles, and then dictate which ones MediaWiki should support natively, and which ones should be something only allowed with an installed extension. Keep the code clean, but give the public the features they want. Btw, DISPLAYTITLE did previously allow for off titles and did add the subtitle. Some wiki were actually making use of that as a feature awhile back and complained when it was /Fixed/ to never allow that whatsoever. Without even letting people allow it using a config variable. On a similar note, there's another feature which is used in some cases: http://www.mediawiki.org/wiki/Extension:Ascii_Translit That idea of allowing extensions to change the normalization process would void out the use of that extension, and allow for that kind of functionality without making it a hack, or needing to use redirects or double pages. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

The smaller set of improvements you propose will likely require a large amount of change to the MediaWiki code. Which is more sane? * Editing a large amount of code to make small changes. And then ending up finding out that further improvements can't be made without hacks and needing to edit a large amount of code again. * One group editing a large amount of code to make small changes, at the same time that another group decides to do something similar yet incompatible with the other than extends the functionality in another way. * Or one group editing a large amount of code to make small changes at the same time as opening up the ability to improve that further without the use of hacks. I noted the Title hack because as it is, both the css and js versions are complete hacks, the DISPLAYTITLE function was created to try and stop people from using those hacks by giving functionality for it inside of MediaWiki itself. However as you see, people are still using the Title hack and haven't stopped using it despite the fact that DISPLAYTITLE exists, that shows that there is something left to be desired in the current implementation before people are going to stop using ugly hacks on common wiki. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

On Sat, Mar 1, 2008 at 11:51 PM, DanTMan &lt;dan_the_man(a)telus.net&gt; wrote: The third, which is why I never said the mechanism shouldn't be perfectly extensible. It should be. On Sun, Mar 2, 2008 at 12:40 AM, DanTMan &lt;dan_the_man(a)telus.net&gt; wrote: I think you're assuming I'm actually going to do this. I doubt I am, for the foreseeable future. I don't have the time to do much serious hacking. I was just expressing a fond wish. The second and third titles you name may or may not be required to coincide. Permitting them not to (i.e., allowing the display title not to normalize to the title key, and/or permitting odd things like HTML in the display title) raises its own set of difficulties that will require a lot more thought than the initial proposal, and go a lot further. And I don't think they should be in core. But I think this discussion has gotten to the point where it may as well stop, unless someone says they're willing to write the code. Further argument over implementation details is probably not very productive without anyone seriously considering an implementation.

:/ oh, now you just poked the coding bone... http://uploads.screenshot-program.com/upl9489088627.png First note, NO there is no {{DISPLAYTITLE:}} inside that page. Though this is just a partial change. Only some parts are done, and others missing. Now onto the actual notes: - It may be a compatibility break for some extensions which are doing things they aren't supposed to do and using $title->mTextform instead of $title->getText() because when a title is initialized now with a DB Key the Textform is left as a null string and will be grabbed on the fly in getText when we need it. (Avoids excessive database queries) (Yes there is internal use of getText instead of mTextform to avoid using null titles where they shouldn't be used) - makeTitle now accepts a third optional parameter, the realtitle of a title. This way we can initialize both when we have them and it'll be there for when it's needed. - equals now accepts a second optional parameter similar to the $valid parameter we use in User:: stuff. It defaults to 'key' but if you pass 'real' to it, it'll compare real tittles instead. This is for use in page move interfaces so that we can move titles from say [[Main Page]] to [[Main_Page]]. - I do have the update and table sql and other stuff already in to add the needed page_real field (Hope no-one minds I used an AFTER page_title in the SQL patch to keep reading of the tables clean) - However, it's not yet added for use. The stuff you see in the demo is actually done by doing some mugging of mDbkey to initialize mTextform when getText is called. - I don't have the normalization stuff inside yet. A lot of str_replaces are going to be replaced with the extend able normalization and others removed because they're trying to backconvert where they shouldn't. - Also, as you can see the functions for subpage names and basepage names will need some tweaking to differentiate between the _ and _E forms which should actually use the realtitle and titlekey forms respectively rather than just the textform. A note on DISPLATITLE: Yes the DISPLAYTITLE is a hack, however it's widely used already. So I won't be dropping support in the rewrite, otherwise current uses will break. I'm going to come up with a maintenance script to populate the page_real fields, and another which will hunt down every page with a DISPLAYTITLE in it, and then move it to a proper title, and if possible try and remove the DISPLAYTITLE from it if the script tells it to. (Though, something like this can never be made to not leave cruft behind, so I'd suggest Wikimedia wiki should do moves by hand rather than trying this automatically. Especially since they use things like {{Lowercase}} rather than hardcoded displaytitles). Because DISPLAYTITLE already exists, rather than marking it as depreciated or to be removed I'll try and make it a little less hacky, and instead turn it into a function meant for extension of title displays into a third type of title only meant for display when viewing the page, not for other interface elements. Note that extension of title displays is means a few things: * Rather than DISPLAYTITLE doing everything, it's actually merely going to call another set of stuff meant for displaytitle stuff (Meaning that extensions can change the displaytitle in the background without needing DISPLAYTITLE everywhere). * The Displaytitle, unlike how it currently is done, will never show up inside of the Pagetitle, the realtitle is what will show up in the pagetitle (So wiki will want to move current titles using DISPLAYTITLE to actual realtitles to have the current stuff inside the title show up). * The purpose of a Displaytitle will not be for minor title things like iPod or _Summer, but will actually be meant for things like Foo #1, Lisp instead of Lisp (Programming language), Foo/Bar/, and Miniwiki or use of MediaWiki in an alternative use where they actually use a special title format and then modify how it looks by perhaps using a directory > like The current implementation does not allow for extensions to extend what a DISPLAYTITLE actually is. I'll make a proof of point extension or two for common use to test it out and satisfy a few people who are complaining about the new restrictions to DISPLAYTITLE. Oh, off topic but... No-one probably noticed it because it isn't used anywhere inside of the code. But on Line 321 of includes/Title.php the definition for the Title::nameOf function is missing the "public static" that should be there. It's not used, but someone's going to get a big shock when they try and use the function that says it's static but they need an arbitrary instance to use it. Well on topic... Could Brion or someone the like give me SVN Commit access and create a /branches/titlerewrite for this to be worked on in? ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) David Gerard wrote:

:/ And I think I found out something even worse than E_STRICT... I have no clue who came up with the dumb idea, but all of User.php is using getText(); instead of getDBkey(); Which is insanely stupid, because getText is supposed to output text for display, getDBkey is supposed to output the version of the text which should be used for unique identification. Unfortunately... Instead of relying on functional output, all of User.php is relying on the assumption that the display version of the text will always be as static as the actual unique identifying key. Practical point? If you move [[User:Username]] to [[User:username]], because getText now outputs "username" instead of "Username", Username now cannot login to the wiki. So, we have two options: A) Hack up User.php to use getDBkey and replaces _'s with spaces instead of getText. B) Make use of getDBkey for identification of the user and have the update script refactor the users table to use underscores like it should instead of spaces. I'm in strong favor of B. If there is a place which aims for display of a user's name we can also make use of getText, this will also have the impressive benefit that if you move User:Username to User:_username the software will go and display "_username" instead of "Username". So users who like a special form of their username will actually be able to make the interface display that instead of a normalized form with spaces. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

2008/3/6 &lt;T.W.A.Maaswinkel(a)rn.rabobank.nl&gt;nl>: Case-insensitivity of titles (in some form or other) is something that's been on the table for a long time now, and is currently under discussion. It's probably possible to do somehow, but I wouldn't bet on any way at present that's both efficient and non-buggy, without a lot of work.

On Thu, Mar 6, 2008 at 2:43 AM, DanTMan &lt;dan_the_man(a)telus.net&gt; wrote: In particular, of course, using some nice User method that hides the ugly conversion in one place. The idea of having separate normalized/display names makes as much sense for users as for titles, certainly. This seems like the more logical option. It's not like we aren't going to have be doing rebuilding and repopulating of the page table to do this anyway, so why not the user table too?

DanTMan wrote: Not always. Remember that the PHP code surrounding that functions is interpreted, while the regex call is run on compiled code. I think some of the sysadmins remarked that the use of regex *improved* the perfomance. I'm not saying you shouldn't change it to traditional means, just that time should be checked to be sure it's not slower.

On Sat, Mar 8, 2008 at 9:56 AM, Platonides &lt;Platonides(a)gmail.com&gt; wrote: Or you should just ignore the difference and use whichever you think is easier to read. There's no point in micro-optimization like this, unless you have reason to believe that the particular functions are important to performance.

Ok, new issue... I've changed usage inside of User.php from getText and getPrefixedText to getDBkey and getPrefixedDBkey. However I notice an issue with the User functions themselves: We have a getName function, and additionally for awhile we've had a getTitleKey, but other than a single occurrence inside of Article.php, it's widely unused. That means that getName is used for both uniqueness testing, and display. Obviously, because usernames are now stored in key form rather than text form we are going to need to separate the functional use of functions inside the User class for backend and display use. We've got a few options here: A) Create a new function getTitle which returns the title object which the User matches, and make use of it's functions for the standard displays and other things. Of course this is bascialy the same as getUserPage. B) Change getName's definition to be the display form of a user's name, and getTitleKey to be the key form of the user's name. And change the large number of comparison functions inside of MediaWiki to use getTitleKey instead of getName. C) Create a new function getDisplayName, and have getName's definition changed to the key form of the user's name, and getDisplayName as the display form of the user's name. Depreciate the use of getTitleKey because of it's lack of use or need anymore (changing a single reference to it). And change the uses of getName as a display value inside of MediaWiki to use getDisplayName instead. D) Create two new functions for the key and display forms of the user's name. And depreciate the old functions, slowly changing use of them to the new functions in MW to keep compatibility. I'm probably in favor of C, as if it's definition is changed to key form, all the backend testing and stuff will still work fine, and we then will only need to worry about changing the areas that the username is used for display. Which won't really be a problem if we miss anything, because if we end up missing one conversion, the system will simply be displaying a semi-ugly form with underscores inside of it and none of the case stuff picked by the user. And it'll still be likable and won't break anything in the backend. Oh, ^_^ an interesting new ability due to switching to key form: SELECT user_editcount FROM `user`, `page` WHERE user_name=page_title AND page_namespace=2 AND page_id=3 In this example, page_id 3 is the userpage of my user's userpage. What does it do? Well, if you were on the userpage of a user and just had the page ID, you could now easily grab any information from the database on that user himself because page_name and user_name are stored in the same format instead of different formats. ^_^ Of course, this example isn't to useful, but I'm sure someone will find some use for the two being a match now. Though it looks like I'm also going to have to add some more database stuff. * archives is going to need a ar_real field so that deleting a page doesn't break it's titling. * rev_user_text is going to need the same conversion that user_name underwent, and I'll also need to do some stuff inside the backend to change how the name of the user is displayed. * same goes for image_user_text, ipb_by_text, oi_user_text, rc_user_text, and ar_user_text Oh, minor off topic. But what about putting a log_user_text in at some point. Honnestly I know of a few extensions which intended to allow certain things to be done by anons in addition to normal users, but which broke when anons were allowed use of them because anon users were not properly logged. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) DanTMan wrote:

Mkay, D it is... getName will be depreciated... To go with the whole key/real namescheme I've been going with in Title.php a new getRealName function will get the name to use for interface display. And to match that, getKeyName will get the name for use in uniqueness checking and comparison, and getName will be aliased to it. ^_^ Actually about your note on User and Title normalization not being the same. There is no real reason for them not to be (With the exception of the stuff that we stick in functions like isValidName)... Why's that? A little bonus I already theorized but never mentioned (I'm good at grasping a lot of theory and wrapping my mind around how things work and are supposed to, so I get a lot of them) Because of the new extensible normalization, and how all the username stuff relies on getDBkey and directly uses getText for displaying the username, there is a little bonus. If you go and extend the normalization of Titles specifically for the User: namespace (remember that because of the way it's setup, you can now create per-namespace normalization), the normalization of Usernames will be directly affected by it (Which is kinda why I needed to alter User.php because of that login bug). So, if you go and make the User: namespace completely case-insensitive and leave other namespaces the way they are, the Usernames will suddenly all become completely case-insensitive to match that, without altering any normalization code for usernames. Btw: I have a function inside of the normalizer. TitleNormalizer::backconvert( $title ); basically it does the normal replacing of underscores with spaces. The point of it is for when we don't have a page_real stored in the database (ie: nonexistant page), then backconvert will be used to create a temporary title for displaying while the page doesn't exist. Of course, there is a hook inside of it which lets extensions override it in case they do something like changing the ' ' to '_' normalization to ' ' to '-' for some reason. Heh, I guess I'll take a look at that log stuff sometime later to see how easy it will be. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

I'm not a fan of "Display". While it is used in normal interface it's not necessarily the actual title that will be displayed inside the title header. Remember that there is a third form if the wiki is supporting the upgraded DISPLAYTITLE, which by default will be enabled ^_^ in a semi-neutered state (lol) where it functions like the standard DISPLAYTITLE for backwards compatibility. But over top of that, there are many wiki which are likely to enable an option or an extension which allows less strict display titles, as well as some purely extension driven ones. So, I think Display should be reserved for what goes inside of the header, rather than the un-normalized name of the title. So potential words: (Normalized form for inside the database) Key, DB Key, Unique, Normalized (Non-Normalized form for interface use) Real, Text, Interface, Display, UI, UnNormalized (Format generated by extensions or other things for use in the title bar) Display, Generated No, @ should never be banned from the namespace. It's ok to make it invalid for creation and use, however it's not ok to kill any User namespace title using it. Remember that some things like the idea of Transwiki imports appending the wiki they came from after an @. Those still link to names inside the user namespace. It would be best to keep @ valid so that those can be created with information or such on that user from the other wiki. Hmmm... well, there are two things to actually consider with the format of the name. Firstly, is that most of the stuff inside of MediaWiki dealing with titles, and many of them the ones which deal with broken links as well, are likely to create Title objects using factory functions which make use of the key format, NOT the real format. And most of them do that for good reasons which should not be altered. So, a high percentage of the time you have a Title object generated by MediaWiki itself, which will have no concept or input of what a real title is. Secondly, there are many broken links which are created in special pages. Ones such as Wantedpages, Broken redirects, etc... None of these will ever have a real format inside the database, and there is no title attribute to attempt use of. Thirdly has to do with the editing (Honestly I haven't been thinking much about that, more focused on [[Special:Movepage]]). There are a few issues with directly using the title made by the url. * External sites may actually be using the format which search engines typically have used, but may be in use in other systems as well. In this way, we may actually have titles such as [[Main+Page]], which will insert a literal + inside the title, which we don't actually want. * While we can alter the way that links are generated for the current site, we cannot guarantee anything to do with another wiki. While we do have the user case stuff for interwiki which allows for keeping the case of the first letter. There's no guarantee that another wiki won't use a link like [[Wikipedia:Some Page]], and as a result will link to http://en.wikipedia.org/wiki/Some_Page and that view page would then have the _ inside of it, and a user who hits edit would then end up creating a page with an _ inside the title. * Don't forget us users who don't use the search box, or preview link methods, but instead use the address bar altering method. It's highly likely there are editors who will edit the address bar and use a _ to get where they want to go for page editing. And it's not good for this to be reflected inside of the title. And there's no guarantee on what the browser will do when we type actual characters inside the address bar, and we shouldn't need to memorize percent encodings for characters. Actually, I'm thinking the best method may actually be the addition of a new input to the edit page for that edit issue. Basically a Title input would appear above the textbox (Where the section title is currently located) when editing a new page. This would by default contain the back converted title (To avoid any possible issue, including a user using a title with no first case capital when they should be using it), and the user could edit it to reformat the title. While we could make it so that the the title there is required to normalize back to the normal title. Why not kill two birds with one stone? Instead of that, use that input as the actual title. This will even kill the normal confusion that a new editor encounters when they don't know how to create a new page. All you'll need to do is go to any new page with an &action=edit, even using something like http://en.wikipedia.org/w/?action=edit or use http://en.wikipedia.org/w/?action=create to clear it up, type in the title of the page into the input, and save it. Instead of mucking with other stuff, and extensions like the Inputbox. Of course, if that page already exists, then you'll simply get an error telling you it already exists, and you should either edit that page or find a new title. Now as for the redlinks and getting a real form through the url. I'd propose a secondary parameter, something like &titlesuggest= or something. Which a redlink would append to keep the formatting of the current title. As well as extensions like Inputbox could do. As for the current existing pages. We would probably leave that out and use Special:Movepage to do actual movement. It's possible that in the future someone could rewrite the edit system and move system to allow for a setup where you can both move, and edit the page text at the same time. However, that is a rewrite in an area which we probably should not attempt inside the scope of the current title rewrite. That can actually be done on it's own later without requiring any work here. ---- I should also make a note on caching, and what effect that has on the title. I'm actually using the LinkCache to generate the Real name from the database. Why? Title.php never, ever uses a database query inside of a get function to get information on a title. The only database queries inside of there are part of things like the factory constructors dealing with page ids. The only other getter which needs database info, is getArticleId. And that makes a query to the LinkCache, which does the database query there on it's own, and returns that, as well as putting the link into the cache to avoid any new queries. Because of that, I went for making use of the LinkCache for the getting of the real title. Of course there are a few issues. Firstly, because this is being stored in the cache, we should NEVER store a user inputed real title. For this reason, before the LinkCache stores the title in it's cache, it actually resets the real title using that database query, and if it doesn't find it, then it backconverts it. So it's not a good idea to use user supplied titles here. So that has two side effects. Firstly, if we were to make it so that the LinkCache just didn't set the real title when it doesn't find one... We are likely to end up with a Wiki error resulting from getText not normalizing to getDBkey at some point. Or even worse, there could be a small possibility of an infinite loop where something which needs that real title may query again until it gets it, which would never happen. Another affect could be the fact that since it does not have a real title stored, the LinkCache would be queried for a new real title every time you call getText or something else which depends on it. This would be a heavy database burden resulting from LinkCache not setting a fallback title. Secondly, just as another result, but if anyone uses getArticleId on your title object, there is the possibility that the real title will be reset. (I've made a warning of this inside the setter, that setter is meant strictly for temporary use where you know what is happening to the title. Primarily it is only used by the LinkCache firstly to actually set the title (Since it isn't from the same object and it's bad practice to externally edit a member variable, that could change names, and also because it would generate PHP errors if we later re-factored things to use actual private variables.), and also will be used when moving a page to set what new real title to move to) From my detailed look at Title.php there is little other way to do this, which does not have a serious effect on the database, or bad coding which will result in a lot of bugs. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

Hmmmm, now that I think about it... While the term "Real" is good for titles, it doesn't work for usernames. Because we already have a "Real Name" for the user, which is something completely different. (I don't believe we've even used it in any features yet O_o... One of these days I've gotta alter the system to display the real name field instead of the user's username inside of the personal links). Hmmm... though, redlinks actually use editredlink rather than edit. Ok then, &action=create will be a overriding action. Rather than being like a simple alias of edit which is meant for creation, it'll use an edit form, but it'll never throw an error if the suggested title already exists when you go to the page (Of course it will if you try to save over top of a page, and we'll probably give the user notification that a title they are using is already in use... Probably on each submit to the form (ie: Preview, etc...) and through some AJAX for those who have it) I think Tim Starling was the one who did the editredlink change. Could we get some input from him on if he minds changing the dedicated editredlink to something like a &muffleerrors=1 which would be used in the form &action=edit&muffleerrors=1 to allow &action=create&muffleerrors=1 to be used. Or something... Cause "editredlink" doesn't fit right when &action=create may come from many other sources. And that includes redlinks, inputboxes, and it's likely also going to be used when the user hits the "edit" tab (Actually if no-one minds, it would be a beautiful opportunity to change the "edit" tab on non-existent pages into a "create" tab for a more intuitive interface) ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

Heh... I thought he said something about it being editredlink, not &action=edit&redlink=1, ok, that's fine... It'll just end up as &action=create&redlink=1 instead, and the title will be a suggest not hard. Hmmm... actually, perhaps we should add a bit more restriction to &redlink=1. It's quite possible for someone to click a redlink after a page has already been created. And when someone clicks a redlink to create a page, they are expecting to create that page, not another. So perhaps when coming from a redlink we should add in an extra message if the page already exists saying something like "A page with this title has recently been created. It's likely that you want to edit that page rather than create a new one. Do you wish to switch to editing that page instead of creating a new one under a different title?" And give them a link to switch to that page's edit mode instead. Never said that the user would never be notified: "and we'll probably give the user notification that a title they are using is already in use... Probably on each submit to the form (ie: Preview, etc...) and through some AJAX for those who have it"; But when a user goes to a &action=create page, we should probably assume they are expecting to create something new rather than expecting to edit something that already exists. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Simetrical wrote:

On Fri, Mar 14, 2008 at 9:05 PM, DanTMan &lt;dan_the_man(a)telus.net&gt; wrote: Someone clicking a red link wants to either 1) read the page (not knowing it doesn't exist), or 2) create the page (thinking it doesn't exist). In case 1 the best behavior would be to redirect the user to the page as though it were a blue link. In case 2 the best behavior is unclear, since the user's expectations are wrong, and so actually if we do any special-casing, it may as well be a 301 redirect to the existing page as though it were a blue link. But I wouldn't waste too many brain cells on this, since it's a fairly uncommon scenario.