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 (
On Thu, Mar 13, 2008 at 12:11 AM, DanTMan
<dan_the_man(a)telus.net> 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.
Okay, reasonable.
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
Hmm. Nothing leaps out at me as being the best.
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.
I meant generically, that user pages should correspond exactly to
usable usernames. This needs to be in a loose sense, I guess:
anything that can show up in a user_text field should be valid. That
may include cross-wiki usernames, for instance, which could contain @.
Hmmm... well, there are two things to actually
consider with the format
of the name.
. . .
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 that's an interesting idea. It would solve the problem neatly.
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.
Well, if it's a new action=create, then you can just use the title
parameter, since it will be unused.
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.
Of course. I don't know if such a thing would be desirable.
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.
I'm not sure I get what you're saying. I'll have to look this over in
more detail later to offer suggestions.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l