I hardly write e-mails and even post to the mailing-list, so
if I did something wrong, just let me know. Also, I am well
known for terrible speeling and non-English grammer, please
excuse them too.
I have some proposal to the wikipedia system.
I don't have any worry about the encyclopedical side of
wikipedia. Both quality and coverage have been improving
constantly. It is just fine. But recently I started to worry
about technological side or hosting stuff.
While contents of wikipedia are open-conent and it is nice,
hosting server and database are not. As we all know the
current server is inadequate to support the huge traffic and
it seems going to be worse and worse.
Now then, here is my proposal. Can we distribute database
and related stuff? Each mimi-wikipedia contains certain
articles and provide both displaying and editing service.
Search querys are sent to all of mimi-wikipedian then put
the results together in the main server and return it.
The scale of mimi-wikipedia may vary, say 100 artcles to
possibly 10,000. I think there are many people who are
willing to provide diskspaces, including me.
The problem is set up. Surely the current dependency hell
makes hard to host mimi-wikipedia, particularly on windows-
based servers.
Another problem is what if some mimi-wikipedian is down? For
financially, lost of personal interest, whatever reason. My
solution is duplication.
Also this duplication scheme makes wikipedia more reliable
and easier to extend the capacity in terms of hosting.
I don't know if this kind of system is fesible. I don't see
such a site. But if we agree the idea is good, why don't we
try it?
I agree with the guy who suggested pure wikipedia software
written in C (I am sorry I can't remember his name).
Also, if there was some similar proposal before, excuse me.
Hello, Pieter.
>Agree, we should think (brainstorm) about distributed
>servers, but this is a very difficult topic (for me at
least).
Yeah, I think so too. But while the wikipedia grows as
encyclopedia, that its system remains same is a problem
surely.
>I've got more weird ideas: I'll make the source-code of my
pure-C-
>wikisoftware available via its' WikiWebInterface ITSELF!
This way,
>I'll never loose my sources! (the recursive trick).
I don't think this is weird, but nothing but wonderful! Such
a idea has already been proposed in wiki community. You may
want to check this out.
http://www.usemod.com/cgi-bin/mb.pl?
WikiAsSourceControlRepository
I believe it would work. At first, Wikipedia seems not to
work, but actually it does, we know that. I am always
dreaming of why don't we use wiki for everything?
Best wishes,
Takuya Murata
takusi(a)manjiro.net
On Saturday 11 January 2003 04:00 am, Tomasz Wegrzanowski wrote:
> No. Its rules must be obeyed only for words of that language.
> For words from other languages, like names of people, places etc.
> rules of source language must be obeyed.
And who are you to dictate what the naming conventions on the English
Wikipedia should be?
When words from other languages are used in any language that language tends
to modify those words so that they are pronounceable and usable by people who
speak that language. In English this is called Anglicisation and in Polish it
is called Polonisation (which has already been pointed out to you).
All languages pick up and modify words from other languages. When these
languages do this the words are no longer foreign, but they are now part of a
new language. Words are merely used to name things and different languages
have different words for things.
-- Daniel Mayer (aka mav)
I've just made some tweaks to allow client-side caching of article pages
and recentchanges.
They now provide a 'Last-modified' header which reflects the timestamp
of the page (or for recentchanges, the most recently modified page).
They're still set to expire instantly, so a caching client ought to ask
for the page again, with an 'If-modified-since' header. If the
last-modified timestamp has not changed, we tell it '304 Not modified'
and the client uses its cached version. Otherwise, the page continues
being generated and loaded.
Currently on test.wikipedia.org, please throw various browsers against
it.
-- brion vibber (brion @ pobox.com)
Hi,
support for subpages was not added to the new software because subpages
were considered detrimental to Wikipedia's structure. I agree with this:
For an encyclopedia, you want to avoid too many "hidden areas". However,
users are creating pseudo-subpages on their user pages and on talk pages
to archive them. In these instances, having subpage support may be
useful -- it makes link creation easier and provides automatic
backlinks.
DefaultSettings.php now has an array which defines namespaces that allow
subpages. Subpages are pages of the form [[/bar]], which, when created
on page [[foo]], lead to a page [[foo/bar]].
When creating links in a namespace that does not support subpages, the
link [[/bar]] simply points to "bar". When doing so in a namespace that
*does* support subpages, the link points to [[foo/bar]]. Thus, it is
possible to have talk page archives, subpages in userland etc., without
having subpages within Wikipedia.
On a page within a namespace that supports subpages, backlinks are shown
if the page title contains the "/" character. So "User
talk:Eloquence/Archive" shows a backlink to "User talk:Eloquence" at the
top (using the new subpage stylesheet). Backlinks are not shown to
non-existent parent pages.
Currently you have to do
[[/foo]]
[[/bar]]
[[/baz]]
to create multiple subpages. I plan to add support for a <subpages> tag
which should simplify the creation of multiple subpages (e.g. archive
links):
<subpages>
[[foo]]
[[bar]]
[[baz]]
</subpages>
I have committed a modified DefaultSettings.php which allows subpages
for Talk/User pages, which may be a reasonable default. I suggest that
this default be used for all Wikipedias, but this is a policy matter
which I will bring up on wikipedia-l. If subpages are not supposed to be
supported at all, the $wgNamespacesWithSubpages array fields can simply
be set to 0.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
----- Forwarded message from Michael Hardy <hardy(a)math.mit.edu> -----
From: Michael Hardy <hardy(a)math.mit.edu>
Date: Mon, 27 Jan 2003 22:16:19 -0500 (EST)
To: jwales(a)bomis.com
Subject: edit conflicts
We desparately need a better way to handle edit conflicts
than the current method of destroying 20 minutes work without
warning. -- Mike
--
Michael Hardy
hardy(a)math.mit.edu
----- End forwarded message -----
I've cleaned up the go button code a little and moved it to a separate
function. I've also changed the behavior to first try to find a close
title match before running a full text search. That is, the process is
now:
1) try various capitalization variants (we could make this
simpler by creating an UPPER index in CUR, but it may not
be worth it); if there's a match, display it
2) try title search in search index, if there's a match, display
it (e.g. typing "Chomsky" and clicking go will also display
"Noam Chomsky"); this searches across namespaces. In some
cases it produces weird hits because it just picks the first
match, so cunctator->go might put you on the talk page
or on some subpage instead of the user page, depending on the
order in the table.
3) run full text search
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
Brion Vibber wrote:
>For eons people have complained that "Put the text of the new page
>here." is extremely unhelpful and promotes confusion among newbies to
>wiki; that it discourages people from doing anything further with the
>site as they don't know what they've stumbled into; and that it
>encourages a lot of useless blank, "Put the text of the new page here",
>and "What does this do? FJSDIOJDFS" pages. Longer, more informative
>messages have been suggested.
I like the new message, but it seems a bit more could be done. Why
not modify the script so that it will respond with an error message
if anyone attempts to submit a new article that contains the exact
text of the "newarticletext" string? No matter what message you put
in the edit box, there will still be newbies who misunderstand or
ignore the message and create useless pages, but you can make it a
little harder for them to do so.
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------
Just saw this run by on the MySQL mailing list. Might help us?
(Also, I've enabled the 'slow query log' on the mysql server; I'll have
a look at the results come tomorrow...)
-- brion vibber (brion @ pobox.com)
-----Forwarded Message-----
From: Heikki Tuuri <Heikki.Tuuri--innodb.com>
To: mysql--lists.mysql.com, bugs--lists.mysql.com
Subject: Major bug fixed in InnoDB optimizer in ... WHERE col > x
Date: 28 Jan 2003 01:52:49 +0200
Hi!
Over the past 2 years several users have complained about optimization of
queries of type
... WHERE col < x;
... WHERE col <= x;
... WHERE col > x;
... WHERE col >= x;
and, indeed, there was a major bug in the InnoDB query estimator. The fix
appears in 4.0.10 and 3.23.56.
"
MySQL/InnoDB-3.23.56, February xx, 2003
Fixed a major bug in InnoDB query optimization: queries of type SELECT ...
WHERE indexcolumn < x and SELECT ... WHERE indexcolumn > x could cause a
table scan even if the selectivity would have been very good.
"
Best regards,
Heikki
Innobase Oy
For mail filters:
How-to-Repeat:
sql query
For eons people have complained that "Put the text of the new page
here." is extremely unhelpful and promotes confusion among newbies to
wiki; that it discourages people from doing anything further with the
site as they don't know what they've stumbled into; and that it
encourages a lot of useless blank, "Put the text of the new page here",
and "What does this do? FJSDIOJDFS" pages. Longer, more informative
messages have been suggested.
As an experiment, I've gone ahead and changed the (English) message to
the following:
You've followed a link to a page that doesn't exist yet. If you'd
like to create a new page under this title, delete this message and
get typing! Click the 'Help' link up top if you haven't used a
Wiki before and aren't sure how to go about it.
If you didn't mean to create a new page, just click the 'back'
button in your browser, or use the search box at the top of the
screen to find existing articles.
Suggestions for more consice, professional, friendly, and informative
wording are welcome.
-- brion vibber (brion @ pobox.com)