> Why? This would keep the software and the interface simple and more
> consistent. Look at the links to namespaces at the bottom of pages.
> Sometimes there is none, sometimes one, sometimes two. Why is that?
> And why on earth is the link to a discussion page called
> a namespace? And why is there no Talk page for SpecialPages?
I think constancy is not the solution, it's the problem.
The special namespaces contain pages which are functionally different from
standard wikipedia pages. Talk namespaces are for discussion of articles,
and user namespaces are for interaction with other wikipedians. These are
NOT encyclopedia articles, and I think it behooves us to help anybody who
comes to wikipedia to gain a clear and distinct understanding of this point
as quickly as possible.
I would actually suggest that we try somehow to change the "look and feel"
of the special namespaces, so that people will just SEE the distinction as
they browse through our site. The fundamental problem I have with using ()
both to disambiguate terms within the wikipedia, and to denote special pages
which are not encyclopedia articles, is that we don't want people to
accidentally miss this distinction and start using the standard encyclopedia
article namespace for user pages, or for talking about articles, etc.
Making the distinction as clear as possible is and important goal -- in my
opinion more important than simplifying the way namespaces are handled in
the code.
That said, I think we can and should look at ways to make the current
interface more self explanatory, so that the links help users make the
necessary distinction between wikipedia and the necessary wikipedia related
pages.
Yours
Mark
From: "Larry Sanger" <lsanger(a)nupedia.com>
>
> The notion of "section headers" sounds like one that should be discussed
> on wikipedia-l before considering implementing it in software, I think.
It certainly is. It's a feature that is also seen at some other Wiki's,
e.g., MoinMoin, and usually in the form of of a macro such as
{{{table_of_contents}}} such that it adapts itself automatically when new
headers are inserted. I agree with Lars that it could help in promoting
bigger articles with subsections that replace subpages.
-- Jan Hidders
Hello,
Suggestion #2:
WikiWord:
page with buttons labeled "BLOCKQUOTE" "LIST" "CARRIER RETURN"...
you press "LIST"
you get *
you press "LINK"
you get [[insert here you link]]
stupid?
not because you NOT need to remind all UserMod trick, you only need press the
button laveled what you need.
This can bee improved to a small icons, not buttons.
notes:
1) optional
2) improve with small eyecandy lovable icons :D
1 saludo
Tei
note:
at least this will help me, because I dont remember the minimal sintax needed
por wikipedia :P
---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/
It would be very cute and maybe harmless to be able to mark up some articles
as being about people or events or whatever. I'm not sure how this would best
be implemented, and maybe it shouldn't be implemented, but hear me out. (I think
maybe namespaces aren't right for this idea, but then again, maybe so.)
Look at this text -- I'm not suggesting this as actual markup we should adopt, but
this is just something to get ideas flowing:
<person>George Washington</person> was the first <concept>President</concept> of
the <place>United States of America</place> after the adoption of the <concept>United
States Constitution</concept>.
The magic we could do if lots and lots of articles were marked up with this kind
of metadata would be really neat.
If we used namespaces, this would be:
[[George Washington]]
[[person:George Washington]]
But I think we should think really hard about the dangers of
proliferating namespaces too quickly. One of the things we have to
think really hard about is making sure that any transition to more
comprensive semantic markup doesn't frighten and confuse people.
--Jimbo
Hello I am Tei,
and i have join Wikipedia project recently.
I am a active web and desktop developper for 3D Engines, GFX, Perl things, etc..
I can make amazing suggestions that can turn people crazy as never have you
see.. that mi expecial ability :D
Suggestion #1:
Upload a complete substitution gfx icons for greek symbols. And builtin a easy
to use feature...
<Grek>OMEGA</grek> <Grek>A</grek>
to
<img src="/upload/greek/omega.png"> <img src="/upload/greek/alfa.png">
May this help oneline math expresions writing?
1 saludo
Tei
==POD RULEZ!!
---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/
I noticed some things on wikipedia that IMHO should be avoided:
* Creating half a dozen redirects to a single topic. A recent example of
this might be the "ArXiv.org e-print archive", for which "Xxx.lanl.gov",
"Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created. There's no
need to do this if the redirected titles aren't very common and mentioned in
the article text anyway. The search function will find them without the
redirect, and noone will go through the "All Pages" list if there's a search
function.
* Links to the talk page of an article appended to the article. Having
"Talk" links in the article text is obsolete, as at least one link to the
talk page will show anyway (or two, if you use the sidebar). When editing
articles, if you see these links, please delete them.
* Ebooks and other long texts. With the coming software update, the sidebar
will contain a link to "Long Pages" (like an inverse stub list). Please have
a look at this once it is available, and remove yet another copy of "The
Origin Of Species" (that's not what wikipedia is for, right?), and try to
break apart long "real" articles into pieces that are more easy to swallow;)
Magnus
I thought about having an easy way of expressing "this page is obsolete and
should be deleted". Currently, we have "page titles to be deleted", but it
takes time and effort to go there and edit.
The obvious solution:
* For logged-in users (troll prevention!), have a link in the sidebar "Mark
this page for deletion" (a shorter title might fit better, but I can't think
of any; maybe a shredder logo?;)
* This adds the current page to "log:Pages to be deleted" (or
"wikipedia:Pages to be deleted")
** Alternatively, we mark the article in the database, so the page is "PTBD"
page is generated on-the-fly, ensuring it doesn't list pages that already
*have* been deleted
* Additionally, these pages are sorted by votes (descending, the "most
hated" on top;)
* Optionally, list the users that voted for deletion of that page
Then, a sysop (=Larry) comes along, checks out the list and cleans up behind
us thoughtless page-creators by permanently deleting the pages he deems
obsolete.
Before I implement any of that, any ideas, comments, flames? ;)
Magnus
It takes such a long time to load! And I can't instruct my preferences
page to make 500 (or more!) changes the default, which is what I want.
Please, please, dear, dear programmers, make the updates to this page's
code correct and functional. :-) Thank you. :-)
Larry
I just noticed that some of you might *not* be aware of the "Hide minor
edits on Recent Changes" checkbox on your user preferences page. Someone
made a comment in his minor edit that implied everyone would be forced to
see it. Well, you're not!
Julie Kemp might want to include this factoid on the PHP Script FAQ page :)
I would also like to thank everybody who has been working on the software,
improving functionality, reliability, and performance over the last few
weeks. We're really getting somewhere here ;)
Magnus
> How do you know that the current parser is bad? Do you have numbers
> (measurements from the live website) that indicate that the regexp
> parsing is the bottleneck in the performance of today's Wikipedia
> website? Or do you just want to write a parser? (I know writing
> parsers can be great fun, seriously, but I think this discussion
> should focus on fixing the performance problems.)
Well, I've got that impression from what Jan Hidders said.
Judging from the recent traffic on the list, the bigger problem
is with the database connection management, though, so
you've got a point here.
I still believe, however, that the current Wiki parser is far
from perfection, so that it will have to be re-written some
day. What I'd personally like to see as the first step is the
simplification and systematization of Wiki markup (e.g.
making all links use square brackets).
> Sometimes, a simple access to http://www.wikipedia.com/wiki/Biology
> takes 11 seconds, sometimes it takes 2 seconds. When it takes longer,
> is it because too much CPU time is spent in regexp parsing? How can
> we know this? From profiling the running server? Or is my HTTP
> request put on hold for some other reason (database locks, swapping,
> I/O waits, network congestion, ..., or too much CPU time spent on some
> other task)? If regexp parsing really is the bottleneck, how much
> more efficient can a new parser be? Twice as fast? Is it possible to
> add more hardware (multiprocessor) instead?
Again, I set out from the position that the Wiki parser is
so inefficient that adding any additional markup (the
original subject of the discussion) would be devastating
to its performance. Even though the current slowdown
seems to originate in the database connectivity, I suspect
that parser speed will become the bottleneck some time
in the future.
Sincerely yours,
Uri Yanover