Hi Danny,
I hope it's ok to forward this message to wikitech-l and
wiki-research-l because this are general research questions. You wrote:
> I think this is all an invaluable discussion, but it is being blurred
> by statements that have no basis in actual fact. "Most of our
> articles," "the vast majority of our articles," "only a very small
> percentage of our articles" all mean nothing.
>
> I would very much like to see a comprehensive report by the Research
> Committee about the current state of Wikipedia.
Probably it won't help a lot but at least I can tell you what measures
*can* be determined in which way from my point of view. That means if I
had the time I could do it (sorry, this is frustrating also for me).
> 1. How many articles are being created currently.
Can be measured from the recentchanges table. Up to now there is no
dump and you cannot use the XML dump only because it does not contain
deletions - I also think that this table is does not contain all edits
from the beginning.
> 2. What is the actual proportion of anon v. registered users.
Can be measured from the recentchanges table too. If you ignore the
deleted pages it can also measured from the full XML dump like I did
for the German Wikipedia or Erik Zachte for all Wikipedias:
http://en.wikipedia.org/wikistats/EN/TablesWikipediaEN.htm
There you can see it is 28% anonymous edits for the English Wikipedia
(but you may be interested in changes of this value so recentchanges is
needed)
> 3. How has the experiment on English impacted Wikipedia.
In the press or by content? ;-)
> 4. What percentage of our articles are classified as stubs?
There is a dump of categorylinks where you can easily count them. I'll
try do this tomorrow.
> 5. What percentage of our articles contain incorrect information?
I guess 100%. Please specify "incorrect".
> 6. What percentage of our articles contain pornographic images in
> their histories?
You need to track deletion log (again there is no dump) but I don't
know how to determine if a deleted image was pornographic or not.
> 7. What percentage of our articles are copied verbatim from other sources?
This is also difficult, I have to think about it.
> 8. What percentage of our images are copyrighted.
Tagged or non tagged? This also depends a lot on the law you consider.
> 9. What percentage of edits are vandalism?
This could be measured with the full dump or recent changes log. At
least you can count the number of probably reverts by looking at the
comments but you only get reverted vadalism (better than nothing).
> 10. What percentagge of our articles are of Featured Article quality?
http://en.wikipedia.org/wiki/Wikipedia:Featured_article_statistics
> Etc., etc., etc.
>
> I would also like to see practical suggestions that can be
> implemented in the immediate future to make the necessary changes.
> Ideally, this would include a timeline.
Research is beeing done but very slowly because there are so many
possibilities and most Wiki researchers do it in there own time (like
Wikipedians) so there are no deadlines (except your masters thesis
deadline and things like that) and no specific goals. It's freedom of
research. I play around a lot with Wikipedia statistics and ideas of
research but it's more for fun - writing it down and analysing it in
all details is work.
Greetings,
Jakob
P.S: By the way the best paper about quality of Wikipedia is already
published since Wikimania. Andreas Brändle has finished his thesis now
but it's in German and not published yet.
http://en.wikibooks.org/wiki/Wikimania05/Paper-AB1
Now that Firefox 1.5 has been deployed for my user base I would like to
start sending SVG content directly to the browser. I realize that
Firefox 1.5 is not deployed everywhere but it is to my user base. That
being now established (hopefully) I noticed that there are many
workarounds within mediawiki that prevent SVG content from getting to
the browser as an image source. Can someone give me a hand at switching
all the locks?
Thank you,
Aron
I made a plot[1] of account creations on the English Wikipedia based
on Newuserlog data, there has been quite a spike since anonymous page
creation got disabled, although the numbers are a bit inaccurate since
it has also been in the press lately.
[1]: http://upload.wikimedia.org/wikipedia/commons/5/5c/Account_creations_on_the…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This may seem a bit off-topic, but I've been noodling around with
Lilypond and I simply cannot get it to work, neither on my home Windows
system or my Unix server. Is this just a problem I have?
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDniqNqTO+fYacSNoRAntJAJ4rA3oaRULuJXqpco27iR5jUw+MkwCghN12
nkqv1TrSLUf6wA6Jyaw+ER4=
=BmLt
-----END PGP SIGNATURE-----
On wikipedia-l, Brion wrote:
> Please confirm that you have talked with Tim, who is already working on version
> tagging keeping our caching requirements in mind.
I thought I'd better describe here what I'm doing in that area, so that I
can get some comments on the design, and in case any of it affects what
other people are doing.
It started innocently enough, I ported Salvatore's "show verified" patch [1]
to HEAD, with the intention of putting it live within a day or so. But the
problem with that patch, like other features that encourage viewing of
revisions other than the latest one, is that such page views are currently
uncached. This is especially a problem for Salvatore's patch, which proposes
to switch particularly popular articles and frequently vandalised articles
to a moderated mode, where the old revision is displayed by default.
Our goals are:
* Consistency between the parser cache and the rerendered HTML at any time
* Fast cache hits
* Low-latency cache updates
At the moment, rerendered HTML changes in the following circumstances:
* Template change
* Link colour change
* Deletion of the revision
One simple way to reduce the rate at which the cache for old revisions is
invalidated would be to retrieve the old revisions of all included templates
when the revision is rerendered. In other words, to display all templates as
they were when the article was edited. Besides the cache implications, this
is also a highly desired UI feature. It turns out to be fairly easy to
implement, with the following caveats:
* If a template is moved, there is no way to reliably determine where it
moved to. We could follow the redirect in the first revision, but the
redirect might have been changed by deletion and recreation by an admin.
* Template deletion necessarily changes the rerendered HTML.
My original idea was to ignore these changes, and any link colour changes,
in the interests of simplicity and cache efficiency. However Brion expressed
a desire to see at least some part of MediaWiki work perfectly, and I admit
that's a good point.
For caches of old revisions to properly reflect these changes described
above, there are two design options that I can see:
1) Store a list of templates and links in the parser cache object, and check
them all to make sure they still exist, on every parser cache hit. This
would make parser cache hits slow, although they would be somewhat faster
than rerendering.
2) Store a list of templates and links in the database, indexed both ways,
in a similar way to what we do now with current revisions. Then analogously
to the behaviour for current revisions, all revisions which include a
template would have their rev_touched field updated when the template is
deleted or moved.
Option 2 is the one I'm running with, because it's likely to be faster if
carefully implemented. Note that template links from old revisions are only
required when there is a valid cache object stored which might need to be
invalidated. Thus we can reduce the size of the table by only registering
links to tagged or current revisions.
This is about as far as my planning goes, I'm not quite sure of the details
of this template tracking system. So in the following section I'm just
thinking aloud.
* Should the new templatelinks table be indexed by (page,tag) or revision?
If it's indexed by (page,tag), then we need to update all those rows when a
tag changes. If it's indexed by revision, then we need to (periodically?)
purge the table of all rows associated with untagged revisions.
* Just how bad would it be if we indexed by revision and let the
templatelinks table grow indefinitely? What would give out first?
* Parser cache objects have a finite lifetime in memcached. Perhaps we could
add a cache timestamp to templatelinks, and then periodically delete all
templatelinks rows for which the parser cache object has expired. This has
the advantage of allowing us to cache untagged old revisions, but I'm not
sure what the DB performance implications would be.
So far, I've ported Salvatore's patch to HEAD, and refactored the link
handling code, to track templates properly and to make it more flexible.
None of it is committed yet.
-- Tim Starling
[1] http://mail.wikimedia.org/pipermail/wikitech-l/2005-July/030898.html
hello everybody,
We now have a free encyclopedia. We now have a free library. We now have
free pictures. Now we have to *free the music* (
http://en.wikibooks.org/wiki/Wikimania05/Presentation-JW1) and make it
available for everyone. But with the preservation of the wiki-idea:
publishing music with a free license, or publishing music in the Public
Domain.
Let's make a WikiMusic. A Wiki with:
- *both score and text* of a free piece of music
- the *music itself* in a playable music file (in different versions,
for example one version with trumpet, one with a whole orchestra, not MIDI)
- the *sheet music* in a wiki-text format
- *information about* the piece of music.
The WikiMusic has to be *user-friendly* as well. So NO WikiMusic just for
expert musicians, but also for people who are just looking for a nice work
of Beethoven. There has to be a system to *search* in this Wiki in a
user-friendly way, too. Maybe the so-called Parsons
code<http://www.musipedia.org/pcnop.0.html>(
http://www.musipedia.org/pcnop.0.html) can be used?
The WikiMusic wiki has to *allow for growth*. Not just for experts, but
rather also for people with little knowledge of the software.
Lilypond<http://en.wikipedia.org/wiki/GNU_LilyPond>is at the moment
still too difficult, too technical, for this purpose. Maybe
there are possibilities to make it easier to enter scores into a Wiki. Maybe
it is possible to integrate some kind of keyboard (java applet) in the
software, and have the software rewrite it into Lilypond-like formats.
Perhaps a (java) applet to drag and drop the notes into the score can be
developed, so a full score can be reproduced in a Wiki. And that such will
be transcribed into the Lilypond format automatically is our dream.
The Wikimusic has to be *editable*. So not just the creation of new scores
has to be easy, but also their editing. Maybe some way can be found to
change the rather complex format of lilypond into a drag-and-drop idea, so
the sheet can be altered easily. Later the sheet can be transcribed into the
standard format again.
WikiMusic must, last but not least, be *able to survive*. Not only with its
envisioned community, but also with a protection from vandals. It may prove
to be be hard to maintain the usual wiki-way here. Some brainstorming about
this issue needs to be done. How can vandals be checked best, by a mere
possibility of *listening to the differences* perhaps?
You can help with this! Today a proposal is posted on meta (
http://meta.wikimedia.org/wiki/Proposals_for_new_projects#Wikimusic_II and
http://meta.wikimedia.org/wiki/Wikimusic_II), and there are still a lot of
technical issues to be solved. Plese add your comment, and get the project
on it's way. Every bit of help and comment is welcome. I hope to see you
there.
Effeietsanders (http://nl.wikipedia.org/wiki/gebruiker:Effeietsanders and
http://en.wikipedia.org/wiki/user:Effeietsanders)
Hello
Some weeks ago there was a discussion of how to improve threading
within the Wikipedia discussion pages. A possible solution would be
http://meta.wikimedia.org/wiki/LiquidThreads,
however that most likely will not come any time soon.
Would the following be easy to implement?
1 When adding a new contribution the user is forced to use a
header, that is the construct == == is automatically
inserted. Right now I have to press the button *+*. But
couldn't that functionality be on the button *edit*?
2 then when the user wants to reply to a contribution by using the
`local' *edit* button, automatically a subheader would be
inserted, in this case === ===, then the reply to that
would get a ==== ==== header and so on and so on.
More sophisticated implementation
- when doing 1, a yes-no questions pops up: do you want to
reply or to compose a entry?
- when doing 2 automatically and RE: is added behind the
===.
If such features would be implemented the tableofcontents would
server somehow as an overview of the threads.
Uwe Brauer
Hello andy,
This is not the right mailgroup if you write in german.
So anyways I try my best in german ;):
Wenn du dein Wiki auf mehereren Sprachen machen willst würde ich nicht für jede Sprache ein Wikipedia installieren sondern für jede Sprache ein namespace definieren. Diesbezüglich wirst du eine Menge Informationen auf meta Wiki finden.
Die Images sind soweit ich das sehe nicht in der Datenbank sondern unter <wikiroot>/images zu finden. Auf der Datenbank wirst du nur die links finden Bild -> Artikel
Aber mehrere Namespace sind meiner Meinung nach sicher die sauberste Lösung für sowas. Falls du dennoch nicht diesen Weg gehen willst, solltest du auf einer Datenbank sämtliche Daten speichern und prefix bei den tables verwenden bsp:
En_page
It_page
De_page
Etc. und den Code anpassen damit die image table überall gleich verlinkt ist. Dies ist jedoch nicht unriskant und mit viel mehrarbeit verbunden da dir niemand versichern kann das das Datenbank design so bleibt wie es jetzt ist.
Habe auch viel mit PHP für Wiki gecoded und beim Wechsel von 1.4 auf 1.5 wo sich sehr viel am Datenbankdesign geändert hatte grossen Aufwand hatte.
Gruss,
Flo
> -----Ursprüngliche Nachricht-----
> Von: wikitech-l-bounces(a)wikimedia.org
> [mailto:wikitech-l-bounces@wikimedia.org] Im Auftrag von
> wikitech-l-request(a)wikimedia.org
> Gesendet: Samstag, 10. Dezember 2005 13:15
> An: wikitech-l(a)wikimedia.org
> Betreff: Wikitech-l Digest, Vol 29, Issue 16
>
> Send Wikitech-l mailing list submissions to
> wikitech-l(a)wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-request(a)wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-owner(a)wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
> 1. Hooking (Aron Rubin)
> 2. Re: Hooking (Peter Danenberg)
> 3. Inactive wikis (Amgine)
> 4. Re: Inactive wikis (Mark Williamson)
> 5. Re: Re: Preformatted blank articles? (was Experiment on new
> pages and GFDL) (Tels)
> 6. Stupid Mediawiki Tricks: logical templates (David Gerard)
> 7. Re: Re: Preformatted blank articles? (was Experiment
> on new
> pages and GFDL) (Erik Moeller)
> 8. Re: Account creation spike on enwiki after anonymous page
> creation got disabled (Dori)
> 9. upgrade error messages (FxParlant)
> 10. Re: Re: Preformatted blank articles? (was Experiment on new
> pages and GFDL) (Tels)
> 11. Wie gleichzeitig mehrere Wikis betreiben (Arena Andrea)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 09 Dec 2005 16:52:39 -0500
> From: Aron Rubin <arubin(a)atl.lmco.com>
> Subject: [Wikitech-l] Hooking
> To: wikitech-l(a)wikimedia.org
> Message-ID: <4399FCA7.2070809(a)atl.lmco.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Why are there so few hooks in MediaWiki? Is this part of an
> effort to be
> lean or have you not gotten around to it?
>
> Aron
>
> --
>
> ssh aron(a)rubinium.org cat /dev/brain | grep ^work:
>
> Aron Rubin Member, Engineering Staff
> Lockheed Martin E-Mail: arubin(a)atl.lmco.com
> Advanced Technology Laboratories Phone: 856.792.9865
> 3 Executive Campus Fax: 856.792.9930
> Cherry Hill, NJ USA 08002 Web: http://www.atl.lmco.com
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 9 Dec 2005 15:37:44 -0600
> From: Peter Danenberg <pcd(a)wikitex.org>
> Subject: Re: [Wikitech-l] Hooking
> To: Wikimedia developers <wikitech-l(a)wikimedia.org>
> Message-ID: <20051209213744.GA23886(a)wikitex.org>
> Content-Type: text/plain; charset=us-ascii
>
> > Why are there so few hooks in MediaWiki?
>
>
> Imbalanced forward pack, I'm afraid; locks and flankers
> are in order, but the front row needs some work.
>
> In good sadness, though, did you have something like
> Apache's bucket brigades in mind?
>
> --
> Peter Danenberg .
> wikisophia.org ..:
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 09 Dec 2005 22:42:59 +0000
> From: Amgine <amgine(a)saewyc.net>
> Subject: [Wikitech-l] Inactive wikis
> To: wikitech-l(a)wikimedia.org
> Message-ID: <439A0873.2060302(a)saewyc.net>
> Content-Type: text/plain; charset=us-ascii
>
> There is a list of inactive wikis which should be locked at
> http://meta.wikimedia.org/wiki/Inactive_wikis which are currently spam
> traps, with many more to be added. I was wondering if this was still a
> Steward privilege, or if we need to ask developers to lock these?
>
> Amgine
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 9 Dec 2005 15:47:07 -0700
> From: Mark Williamson <node.ue(a)gmail.com>
> Subject: Re: [Wikitech-l] Inactive wikis
> To: Wikimedia developers <wikitech-l(a)wikimedia.org>
> Message-ID: <849f98ed0512091447g590d99e8x(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> These wikis are regularly monitored for vandalism.
>
> Mark
>
> On 09/12/05, Amgine <amgine(a)saewyc.net> wrote:
> > There is a list of inactive wikis which should be locked at
> > http://meta.wikimedia.org/wiki/Inactive_wikis which are
> currently spam
> > traps, with many more to be added. I was wondering if this
> was still a
> > Steward privilege, or if we need to ask developers to lock these?
> >
> > Amgine
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>
> --
> "Take away their language, destroy their souls." -- Joseph Stalin
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 9 Dec 2005 23:53:13 +0100
> From: Tels <nospam-abuse(a)bloodgate.com>
> Subject: Re: [Wikitech-l] Re: Preformatted blank articles? (was
> Experiment on new pages and GFDL)
> To: wikitech-l(a)wikimedia.org
> Cc: English Wikipedia <wikien-l(a)Wikipedia.org>
> Message-ID: <200512092353.37230(a)bloodgate.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Moin David,
>
> On Friday 09 December 2005 21:58, David Gerard wrote:
> > Tels wrote:
> [snipabit]
> > Yep!
> >
> > > The most FAQ was "How do I start a new article?" followed
> by "And why
> > > is this so complicated?", closely followed by "How do I add a
> > > headline again?"
> >
> > That's specifically why I put how to make a section in that in the
> > example ;-)
> >
> > I did a radio interview on Wikipedia yesterday. I actually tried to
> > lure casual editors to feel free to edit.
> >
> > It'd be nice if anon contributors could start articles again. If
> > regulars don't like getting a template, perhaps it could be
> on just for
> > anon editors.
>
> I think anon users rights have nothing to do with this issue
> of whether
> the edit box should be pre-filled or not, and whether it
> should be easier
> to create new articles :)
>
> (IMHO anon edits should be disallowed entirely, but this is just my
> private opinion which doesn't carry much weight and/or might be
> wrong/impractical/impolite etc :)
>
> > > Especially in-frequent contributors tend to forget these
> things very
> > > quick and since the computer should help the humans and not vice
> > > versa, I finally patched my local Mediawiki installation
> to fix this
> > > issue. Everyone's been happy since :)
> >
> > Please submit the patch! (Is there a bug for this yet?)
>
> Actually, I just added one new link to the toolbox on the
> left, which goes
> to a HTML page with a form entry on a webserver, which
> bounces the user
> back to the wiki. I am sure it is possible to create a specialpage
> (Specialpages:NewArticle?) that does the same, but the
> external form was
> easier for me.
>
> The disadvantage of my solution is that you need to be
> already logged in
> for the form to work, otherwise you get the "please login
> first" message,
> and since clicking "log me in" on that page loses the "where you came
> from" (which is a bug), the user will then be on the main page.
>
> Best wishes,
>
> Tels
>
> - --
> Signed on Fri Dec 9 23:46:06 2005 with key 0x93B84C15.
> Visit my photo gallery at http://bloodgate.com/photos/
> PGP key on http://bloodgate.com/tels.asc or per email.
>
> 'Wie Ludger Lügenboldt, Sprecher der Interessengemeinschaft
> Förderer der
> Prostitution International (I.F.P.I.) jetzt bekannt gab,
> entstehen der
> Zuhälterbrache jährlich Milliardenverluste durch kostenfreien Sex.
> "Bestimmt hätten unsere Mädels im Jahr 2003 alleine in
> Deutschland 2000
> Millionen Quickies mehr verkaufen können, wenn die Leute nicht immer
> mehr privat rumvögeln würden. Der uns entstandene Schaden
> beläuft sich
> auf mindestens 100000000000 Euro." Schuld sei nach Angaben
> Lügenboldts
> das Internet: "Flirtportale und Singlewebsites mit
> Kontaktbörsen machen
> unser Geschäft kaputt. Amateure rauben uns unserer
> Geschäftsgrundlagen." Zehntausende von Arbeitsplätzen in Deutschland
> seien gefährdet, die überdies gerade geringer qualifizieren jungen
> Frauen ein Einkommen sicherten. Die I.F.P.I. fordert den Gesetzgeber
> auf, diesem Treiben umgehend Schranken zu setzen.' MI-Boykotteur at
> 2004-05-07 at http://tinyurl.com/35qjo
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iQEVAwUBQ5oK4XcLPEOTuEwVAQG9EAf/Sra72bA66lpQ5j+45tyagutoZKFe+kOM
> J8I6hSlNvee/Zf/N6u0hqizrDD6ZCMPIGQKclDD+AnFVZcrTWV5KOMlNPNuJmMpc
> SPc2k3H0gB3ulLS1gYneOyTEeY/IQUl4peqBNY+QC6MVvClKxTn67N1vYiiW+C+A
> ucVEUnaCLbf/159KaN/XfSLTLmliE5/rn9PPth1x29mhkbLYOXPm1s1UfINFEIam
> +W5sT7WqptlbgmIW3PbuX9KTPejqgU/bgb8SUY1x17GUiSgWhoIjyjZb/hgAJWVt
> kQUswgKp6Abv2PmzTVp7rRZDCLnh16dZM2rMFndqvxgvAthsLvQ6MA==
> =Au5O
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 09 Dec 2005 23:33:04 +0000
> From: David Gerard <fun(a)thingy.apana.org.au>
> Subject: [Wikitech-l] Stupid Mediawiki Tricks: logical templates
> To: wikitech-l(a)wikipedia.org
> Message-ID: <439A1430.5050100(a)thingy.apana.org.au>
> Content-Type: text/plain; charset=ISO-8859-1
>
> [[:en:Category:If Templates]]
> [[:en:Category:Boolean Templates]]
>
> Check out some of the code in them, too, but make sure you
> haven't eaten
> first.
>
> The perpetrators of this l33tn3ss are trying to gut [[:en:WP:AUM]] by
> consensus, because everyone knows database performance and computer
> science in general can be determined by voting. Or maybe it can't.
>
> What would the Stupid Mediawiki Tricks in these things do to the
> database and the cache structure? If it's as bad as I suspect
> it would,
> could some of you please stop by [[:en:WT:AFD]] and describe
> reality to
> them?
>
>
> - d.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 10 Dec 2005 02:01:36 +0100
> From: Erik Moeller <erik_moeller(a)gmx.de>
> Subject: Re: [Wikitech-l] Re: Preformatted blank articles? (was
> Experiment on new pages and GFDL)
> To: Wikimedia developers <wikitech-l(a)wikimedia.org>
> Message-ID: <439A28F0.5010807(a)gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Tels:
>
> > Actually, I just added one new link to the toolbox on the
> left, which goes
> > to a HTML page with a form entry on a webserver, which
> bounces the user
> > back to the wiki. I am sure it is possible to create a specialpage
> > (Specialpages:NewArticle?) that does the same, but the
> external form was
> > easier for me.
> >
>
> http://meta.wikimedia.org/wiki/Help:Inputbox
>
> This has been active on the Wikimedia wikis for quite a while. I
> originally created it for Wikinews, but it's used in many different
> places now. It supports preloading text.
>
> Erik
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 9 Dec 2005 21:30:58 -0600
> From: Dori <slowpoke(a)gmail.com>
> Subject: Re: [Wikitech-l] Account creation spike on enwiki after
> anonymous page creation got disabled
> To: Wikimedia developers <wikitech-l(a)wikimedia.org>
> Message-ID:
> <d2f92e8b0512091930s76586019j7c51fa0c48700205(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 12/9/05, Ævar Arnfjörð Bjarmason <avarab(a)gmail.com> wrote:
> > I made a plot[1] of account creations on the English Wikipedia based
> > on Newuserlog data, there has been quite a spike since
> anonymous page
> > creation got disabled, although the numbers are a bit
> inaccurate since
> > it has also been in the press lately.
> >
> > [1]:
> http://upload.wikimedia.org/wikipedia/commons/5/5c/Account_cre
> ations_on_the_English_Wikipedia.png
>
> Time to start selling low UID accounts on eBay. Just in time for the
> fundraising too.
>
> Dori
>
> ------------------------------
>
> Message: 9
> Date: Sat, 10 Dec 2005 11:09:41 +0100
> From: FxParlant <f-x.p(a)laposte.net>
> Subject: [Wikitech-l] upgrade error messages
> To: wikitech-l(a)wikimedia.org
> Message-ID: <dne9ms$g95$1(a)sea.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello,
>
> just for information. Upgrading might fail for duplicate
> content on some
> fields who become a primary key.
>
> Unfortunately, the 1.5 install isn't as verbose as 1.4 install:
>
> ***1.5 error message***
> Making img_name the primary key... Query "ALTER TABLE image
> ADD PRIMARY
> KEY img_name (img_name)" failed with error code "".
>
>
> ***1.4 error message***
> Making img_name the primary key... Query "ALTER TABLE image
> ADD PRIMARY
> KEY img_name (img_name)" failed with error code "Duplicate entry
> 'README' for key 1".
>
>
> I suggest for users who have a duplicate content making a crash of 1.5
> install, to revert their database and try the install with a
> 1.4. Then,
> correct the database by suppressing one of the duplicate content, and
> redo the 1.5 install.
>
> I hope this is already in bugzilla (if not, maybe someone used to
> expressing the bug could make it) and the install process in
> 1.6 are as
> verbose as in 1.4.
>
>
> François
>
>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 10 Dec 2005 12:11:03 +0100
> From: Tels <nospam-abuse(a)bloodgate.com>
> Subject: Re: [Wikitech-l] Re: Preformatted blank articles? (was
> Experiment on new pages and GFDL)
> To: wikitech-l(a)wikimedia.org
> Cc: Erik Moeller <erik_moeller(a)gmx.de>
> Message-ID: <200512101211.14134(a)bloodgate.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Moin,
>
> On Saturday 10 December 2005 02:01, Erik Moeller wrote:
> > Tels:
> > > Actually, I just added one new link to the toolbox on the
> left, which
> > > goes to a HTML page with a form entry on a webserver,
> which bounces
> > > the user back to the wiki. I am sure it is possible to create a
> > > specialpage (Specialpages:NewArticle?) that does the same, but the
> > > external form was easier for me.
> >
> > http://meta.wikimedia.org/wiki/Help:Inputbox
> >
> > This has been active on the Wikimedia wikis for quite a while. I
> > originally created it for Wikinews, but it's used in many different
> > places now. It supports preloading text.
>
> Wow, saves me the work of creating it :) Thanx a lot,
>
> Tels
>
> - --
> Signed on Sat Dec 10 12:10:43 2005 with key 0x93B84C15.
> Visit my photo gallery at http://bloodgate.com/photos/
> PGP key on http://bloodgate.com/tels.asc or per email.
>
> "Man, I'm hot." - "Thirsty?" - "No, I mean good looking."
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iQEVAwUBQ5q30HcLPEOTuEwVAQHUzwf/SRq0Y0hkSmuu84TOyLyeet1xhy1LKGpD
> bURLDgIZrjz8uNwi3UsUwSVr7oLGbx6Kd7gLR3zZV2Cids/WdhAgTcD6MetANDzl
> BfC/fmqTbjONf2Zt90FztaBZhrCz5DwHH3vNPoaLKq0knNaViUA4ooSy7iHlAyr2
> 7gd+ADMOK6Z0RYEGwLriZe8cWhS4jNu00ccXXB43sCm3Vpxa7c4lxqipB65wEeyb
> MGbe1swk2PAINiCFaxBktqplhINE4SSetcEwj6lel9bTyraY9oVzcCPrs2FCMtXC
> aoR87FkAhSxATevR8lv5XQodilPChdeMsufl8Wd7MFr2jBV7KJKxKA==
> =kY70
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 4 Dec 2005 18:49:32 +0100
> From: Arena Andrea <andrea(a)arena.cd>
> Subject: [Wikitech-l] Wie gleichzeitig mehrere Wikis betreiben
> To: mediawiki-l(a)Wikimedia.org
> Message-ID: <43197370-FE31-412E-9EA4-67BB9853F876(a)arena.cd>
> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
>
> Hallo,
>
> Unser Projekt soll ein Wiki, dass in den Sprachen Deutsch,
> Italienisch, Französich und English erhältlich werden. Dazu
> kommt ein
> Wiki, dass nur für Administratoren da ist, sprich kein bearbeiten
> für den user.
>
> Bis jetzt habe ich nur die Mediawiki Software auf einer
> Deutschen und
> dieser geschützes Wiki installieren können.
> Ich habe zwei Ordner mit Mediawiki und zwei Datenbanken erstellt.
>
> Der Skin sollte bei allen Sprachen gleich aussehen.
>
> Wie ist es systematisch am besten, die weiteren wikis zu installieren?
>
>
> Möchte nochmals mein Ziel erklären:
>
> Der User sieht auf der Hauptseite links im Menu die verschiedenen
> Sprachen, wenn er z.b. auf Italienisch klickt, erscheint der Artikel
> auf Italienisch(inklusiv der Navigation). Und das mit allen Sprachen.
>
> Wie ist das im Hintergrund am besten zu installlieren? Die Skins,
> Extensions und ganz wichtig die Bilder sollten für alle verfügbar
> sein (keine doppelten dateien). Wie mache ich dann dass mit der
> Bilder Datenbank?
>
>
> Vielen Dank im voraus
>
> andy
>
>
> ------------------------------
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
> End of Wikitech-l Digest, Vol 29, Issue 16
> ******************************************
>
