> One thing I think is important -- double opt-in on the email
> addresses. We don't want anyone to use us as an annoying means
> of mailbombing someone.
I'm not sure double opt-in is critical in this context since we're
not talking about putting the address on a list. Nor would this be a
convenient way to mailbomb someone, because it would require dealing
with a webform for each message. But maybe it's better.
Here's what I envision: when someone views a "User" page, an "email
this user" link appears (perhaps only if that user has opted in, and
perhaps only if the person doing the browsing is logged in so we
don't allow anonymous mail). On clicking that link, the user is
presented with a form much like the one I'm typing into now on
Nupedia webmail, except that the e-mail address of the recipient is
not shown. When submitted, the software mails it off to the e-mail
address stored in the database.
The questions, then, are (1) when a new user signs up, giving an e-
mail address, should we further require that he check a box
saying "allow other wikipedians to mail me" or should we let him
check a box saying "don't allow other wikipedians to mail me". The e-
mail address is never published in any case, and the only mails
received are one-to-ones, not lists, but I suppose opt-in is still
the more responsible thing to do. (2) Perhaps the double opt-in
confirmation message could be sent whenever this option is selected.
(3) The mail messages themselves might have a section something
like "This mail was sent from Wikipedia's e-mail function. If you
don't want to receive mails like this, go to..."
0
> This might be a good idea anyway, since I don't see the need to
> having a stats page that recalculates the number of articles for
> each and every request (esp. since the main reason for reworking
> the php wikiware was to maximize efficiency).
The site stats are calculated each time a page is /saved/, and
just directly fetched when queried (except for page read counts,
which naturally have to be updated on each page read). This isn't a
performance issue at all.
The same with the "good" article count--it's only updated when
a page is saved, when either (1) a new page is saved that qualifies
as "countable", (2) a formerly uncountable page is edited to become
countable, or (3) a formerly countable page is edited to become
uncountable. So the {{NUMBEROFPAGES}} query on the front page is
not a calculation, just a lookup (and a faster one than each of
the links).
The criterion for "countable" is flexible; right now, a page is
countable if it (1) does not belong to any namespace, and (2)
contains a comma.
The details of how namespaces are handled is really more of a
techie issue, but since you brought it up here, I'll detail it here.
The full details, of course, can be found in the code.
"Namespace" is a separate field of the database from "Title"; in
fact it's an integer (the exact text of each one depends on the
language). Regular encyclopedia articles have a namespace of 0,
"Talk" (or "Diskussion") pages have a namespace of 1, etc. Things
like the search function simply add (namespace=0) to the query,
and never bother looking at the title (which may contain colons)..
The actual names of the namespaces come into play when interpreting
links. For example, when the software sees a link to [[User:X]],
is grabs whatever appears before the first colon and looks to see
if it is a known namespace or Interwiki. If it is, then the code
looks up the article with a query along the lines of (namespace=2
and title='X'), and so on. If it's not a recognized prefix, then
it uses a query like (namespace=0 and title='2001:_A_Space_Odyssey').
"Image:" is magic on other levels as well, but that's more detail
for later.
0
>> Only the specifically recognized namespace prefixes are treated
>> as namespaces; anything else is just a regular article with a
>> colon in the title.
> This sounds dangerous to me, as people might inadvertantly
> "pollute" the namespace name space?
But that's just my point: an article titled "E. Coli 0157:H7" or
"2001: A Space Odyssey" does NOT create a namespace, so they
aren't polluting anything. Only the previously existing
namespaces "User", "Talk", "Wikipedia", etc., are treated as
namespaces--everything else is just a plain old article, white
background, searchable, all that stuff.
There is a concern, I suppose, that it might limit our ability
to create real namespaces (and interwiki names) later, in that if
we decide to create, say, a "Fred" namespace, any previously
existing articles that happen to be named "Fred:..." may have to
be changed, but I think a simple convention not to use colons
for things other than titles that naturally contain them will
minimize that problem, and creating a new namespace is such a
major change anyway that having to fix a few article titles won't
be much of a problem.
0
Stephen Gilbert <canuck_in_korea2002(a)yahoo.com> writes:
> It depends on what program you're using to write your articles. MS Word
> inserts quite a few non-standard characters; I don't recommend it. Try using
> a pure text editor instead of a word processor.
Most (all?) of these can be eliminated in Word by turning off SmartQuotes(tm)
Its under Format -> Autoformat... -> Options... -> Replace
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)
wikipedia-l(a)nupedia.com 10 July 2002 3:53 pm, Jan Hidders wrote:
> Actually, I wonder if we should not do exactly the opposite: have one code
> base with one database that serves all wikipedias. I have the feeling that
> in terms of software maintenance the non-English wikipedia's are getting a
> very raw deal indeed; reported bugs are fixed earlier on the English
> wikipedia and the major software changes always happen there first. I
> assume this creates a feeling of being left out there in the cold. Having
> one common system would in my opinion also strengthen the sense of
> community.
Just want to say that I think this would be an excellent idea (if it's
feasible)! It really would lead to very tight integration of the projects
(e.g. being able to choose which language to perform searches in among other
things -- see below). This would also allow, as you said, for instant
updating of all wikis at once (assuming any new hard-coded wording is
translated). This is how most software is developed, why not here? (although
the install routine of most other software requires choosing ONE and only one
language; so I am not sure if multiple languages could run at the same time
in the same program).
In addition, it would also be neat if users could then be able to set their
preferences so that they could choose which languages pops up in their
version of RecentChanges. Then Brion could watch all changes made to both the
Esperanto wiki and the English wiki at the same time in the same Recent
Changes, Anthere could do that with the French and English wiki and I could
watch the English, Spanish and what the hell, Latin wikis in the same
RecentChanges.
If a user wanted to, they could have a tower of Babel going on in their
"Inter-wiki Recent Changes". For example: Clicking on de:atom in
RecentChanges (or Cambios Recientes, Ostatnie zmiany, Changements
Récents....) would take the user to the German article with all the sidebar
links, the logo and hard-coded wording in German (even though the underlying
php code would be exactly the same -- language meta tags could be affixed to
each page in the database to ID the language the article was written in). The
fr:, de:, eo:, en: or whatever would only be part of the display of the
page's name in such a Inter Wiki RecentChanges and wouldn't be actually part
of the article's name -- just like the current inter wiki links in the php
software running the English wikipedia.
Of course, this feature would by default be set to only display the language
of the wiki the user signed-in with for that session -- with no language
codes in front of page names.
I don't know if this would be easier or harder than having separate software
programs running the separate language wikis. But then, I could just as
easily split the display of my web browser Konqueror into two panes - one
with Recent Changes and the other with Cambios Recientes. But I'm lazy and
stubburn. :-)
--maveric149
They say a picture is worth a thousand words... I didn't have a lot to
add to the text of the brief banksia article, but I hope my photographs
speak for themselves :)
http://www.wikipedia.com/wiki/Banksia
Now to see what else I've got in my digital file cabinet :)
--
Karen AKA Kajikit
You can take the dragon out of Alfandra, but you can never take Alfandra
out of the dragon (or the Kitty)...
Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Love and huggles to all!
On Wednesday 10 July 2002 03:53 pm, Kurt Jansson wrote:
> I think for every new international Wikipedia someone like Larry would
> be very helpfull. You need someone who feels responsible for the
> project, especially in the first months. When we have enough money maybe
> we should hire some enthusiastic academic guy for each Wikipedia that
> hasn't already "taken off" for a few months. :-)
>
> Kurt
Sounds good to me - just need the money. ;-)
--maveric149
Here is a possible explanation (found at
http://enciclopedia.us.es/wiki.phtml?title=Wikipedia).
Esta enciclopedia surgi� como una escisi�n de la
versi�n en castellano de la wikipedia tras un anuncio
sobre la posibilidad de que hubiese publicidad en la
versi�n original.
Translation: This encyclopedia split off from the
Castilian version of wikipedia after an announcement
of the possibility that there would be advertising in
the original version.
Sigh�
We should consider doing some strategizing to make
sure another fork doesn�t happen (I hear members of
the French wikipedia threatened a fork in the past).
Specifically, we might want to revisit the idea of
wikipedia becoming a non-profit (preferably a European
one). That way, anti-Americanism and distrust of
Boomis (which is both an American company and, /gasp/,
for-profit) wouldn�t weigh on anybody�s mind.
I for one completely trust Jimbo and his company to
continue doing only good for Wikipedia � but others
are instinctively distrustful of both Americans and
for-profit companies and will over-react when certain
capitalistic ideas are put forward or American
influence is perceived to be expanding. I wouldn�t
mind at all contributing 10 Euros/dollars a month to
keep Wikipedia (all languages) afloat (esp. if my
donation were tax deductible). Oh and there would be
no reason why a non-profit Wikipedia.org couldn�t have
a corporate sponsor. ;-)
--maveric149
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
Jimbo wrote:
> We might earmark money to hire a fulltime editor again, although in the
> wikipedia system, this seems unnecessary.
In case anyone is wondering, I agree. The continuing success of Wikipedia
in my absence--which doesn't surprise me--makes it hard to justify my
return as a paid lead/organizer of Wikipedia, at least not anytime soon
and not as long as the project is plowing ahead more or less as it always
has. I'm under no illusions about that, and I'm happy for the project.
It's a great thing Jimbo has made it his hobby and is supporting it as he
always has.
Nupedia is a different matter, of course.
I'm still unemployed, by the way.
Larry