Wikitech-l December 2005

wikitech-l@lists.wikimedia.org

132 participants
156 discussions

my bugzilla email
by Ashar Voultoiz 14 Dec '05

14 Dec '05

Hello, Just to be consistent, I changed my bugzilla email address from thoane(a)altern.org to hashar(a)altern.org :o) cheers, -- Ashar Voultoiz - WP++++ http://en.wikipedia.org/wiki/User:Hashar http://www.livejournal.com/community/wikitech/ IM: hashar(a)jabber.org ICQ: 15325080

1 0

Some research questions
by Jakob 13 Dec '05

13 Dec '05

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

1 0

SVG To User Agent
by Aron Rubin 13 Dec '05

13 Dec '05

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

2 1

Re: [Wikitech-l] WikiMusic
by Any File 13 Dec '05

13 Dec '05

I have found this interesting web site about free music http://www.mutopiaproject.org/ AnyFile

1 0

Account creation spike on enwiki after anonymous page creation got disabled
by Ævar Arnfjörð Bjarmason 13 Dec '05

13 Dec '05

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…

5 4

Re: WikiMusic
by Edward Z. Yang 13 Dec '05

13 Dec '05

-----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-----

1 0

Caching old revisions
by Tim Starling 12 Dec '05

12 Dec '05

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

4 7

WikiMusic
by Effe iets anders 12 Dec '05

12 Dec '05

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)

1 0

proposals for discussion pages: enforce the use of headers and subheaders
by Uwe Brauer 12 Dec '05

12 Dec '05

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

2 1

RE: Wie gleichzeitig mehrere Wikis betreiben (Arena Andrea)
by Keller Florian 12 Dec '05

12 Dec '05

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 > ****************************************** >

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2005