Wikitech-l May 2005

wikitech-l@lists.wikimedia.org

136 participants
194 discussions

no more wikislow?
by Mathias Schindler 05 May '05

05 May '05

Has anyone tried how this monster http://webaccelerator.google.com/index.html does affect the ability to retrieve wikipedia pages? Mathias

3 2

committing to CVS
by Thomas Gries 04 May '05

04 May '05

If possible and and supported by you, I would like to ask, whether I can apply for developers rights for committing changes for a limited time. Then I can upload my http://bugzilla.wikipedia.org/show_bug.cgi?id=454 changes easily. Tom

5 7

A suggestion for a new IRC channel, #mediawiki-dev
by Ævar Arnfjörð Bjarmason 04 May '05

04 May '05

Currently we have two IRC channels that are development/administration related, #mediawiki and #wikimedia-tech, the latter recently forked out of the former because server-related discussions were taking up too much space at #mediawiki. I think we should have another IRC channel specific to development of the Mediawiki software, support requests and other non-development related stuff have begun to take up alot of space on #mediawiki and at times drown development discussion. I've already created it but it would be nice to have the CIA bot join it as well as to move wikibugs from #mediawiki to it, that is if others agree with the concept at all.

1 0

Re: [Wikitech-l] Redirect Pages: Text on them -> Text on article
by Edward Z. Yang 04 May '05

04 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brion Vibber wrote: > Edward Z. Yang wrote: >> Current behavior of Redirects totally masks any text that comes >> after the #REDIRECT [[]] declaration. > > The main reason this is done is that extra text containing links will > foul up the link database: the single outgoing link from a redirect > is used to keep track of where that redirect leads to. > > Redirect pages really oughtn't to be stored the way they are, it's a > nasty hack. This should be recorded properly as metadata listing the > exact target as a cleanly machine-readable field. Ah... I see. Didn't do my research: - From Wikipedia:Redirect > Everything after the redirect line will be blanked when you save the > page. Any text on the same line as the redirect will stay, but will > not be visible unless someone edits the page. Although I'm a bit confused with your last paragraph: did you mean that the redirect pages are a hack, or the way they are being stored is a hack? The technical specification was to serve as a suggestion, I think you get the general gist of the idea though... leave it to the developers to wrangle over the implementation. Lee Daniel Crocker wrote: >> (Suggested redirection feature) > > Why add a complicated feature for what is simply a misuse of a > current one? The article you cite should simply be a one-sentence > article with a link, not a redirect. > > There's absolutely nothing wrong with one-sentence articles. IMHO: - From Wikipedia:Redirect#What_do_we_use_redirects_for.3F > * Sub-topics or closely related topics that should be explained > within the text: Distributed denial of service redirects to Denial of > service and - From Template:R_with_possibilities > This is a redirect from a title for a topic more detailed than the > topic of the page this redirects to. Eventually if the target page > becomes too big, this redirect may be replaced with an article carved > out of the target page. > > For more info. follow the category link. Interestingly, this template doesn't work right now, but it is included in some articles under the syntax: - From Asia Minor > #REDIRECT [[Anatolia]]{{R with possibilities}} An aside for a moment, I think people are jumping the gun adding these sorts of templates, but I have found out there is sort of a demand for this sort of feature. I do not think that one sentence articles are acceptable, and the current user guide suggests that redirects with possibilities should stay redirects with possibilities, not one sentence articles. This idea would help these redirects greatly when it comes to disambiguity. Unfortunately, it's kind of difficult to tally exactly what links the template "R with possibilities" because the template is on redirects, and redirects automatically have their linkage expanded (so you get a lot of irrelevant stuff in there). Rowan Collins wrote: > I can't say I'm keen on having things that aren't links bracketted > like links - IIRC, the previous implementation had things like > #redirect [[Foo|is a kind of]], which was just confusing. My > suggestion would be > #REDIRECT [[Foo]] BECAUSE For info on Foo, see [[#Foo]] > or maybe > #REDIRECT [[Foo]] #BECAUSE For info on Foo, see [[#Foo]] > to make it more clear that "#because" is a magic word, not part of the > explanation. > > The text would then be displayed below (and formatted with) the > "redirected from" message (which should maybe be more obvious). Very cool suggestion. I like it. > I'd still like to see > http://bugzilla.wikimedia.org/show_bug.cgi?id=1521 implemented first > though, or some other way of creating more stable section anchors. At first I though this would be some controversial feature, but checking out the bug page, it seems quite reasonable. It would help greatly in all cases where anchors are used (although it would take a while to get it standardized and stuff, plus, old links would break as soon as the new ones were added even if the title itself didn't change). - -- 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) iD8DBQFCdtpVqTO+fYacSNoRAtn+AJ9AYyMRWGUFvFZvIP+MKdkzqBEfOgCePClJ VUmNnKUO5e4lBNJH7hzSFAw= =S+yV -----END PGP SIGNATURE-----

4 4

wiki syntax
by Lars Aronsson 04 May '05

04 May '05

Is the wiki syntax going anywhere? Did somebody start work to standardize it? Is anybody rethinking the difference between [[x]], [[x:y]], [[:x:y]], [[x|y]], [x:y], [x y], {{x|y}}, {{x|y=z}}, {{x|y=[[z]]}}, and [[x|{{y}}]]? If we started over today, with today's experience but without today's legacy, would we make it similar or different? Would [[image:x]] be implemented as {{image|x}} instead? Would [http://url/ text] be replaced by [[http://url/ | text]]? Would that make "http:" and "isbn:" parallels to "image:" and "category:"? What about making a scripting language for template definitions, so you can have conditions, loops and database fetches, almost like PHP? {{x|y=x}} ::= if ($y) then "see also: $y"; And what about <math></math>? If I got this part of history right, the [[x]] syntax was introduced into the UseMod wiki software by Clifford Adams on request from the Wikipedia community early in 2001. Before that all wikis used CamelCase to make links, and that option was still available in Wikipedia for most of 2001. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

10 11

Redirect Pages: Text on them -> Text on article
by Edward Z. Yang 04 May '05

04 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A while ago, there was a topic on Wikitech-l that discussed "Redirect to Anchor". Noting that this is technically impossible, but also concerned without redirects such as: Blood Agar --> Agar Plate where the relevant information is tucked away very far down in the article, the following feature is requested: Current behavior of Redirects totally masks any text that comes after the #REDIRECT [[]] declaration. Feature would modify behavior, where now this extra text (provided there is text at all), is placed at the top of the article people are redirected to, perhaps, in some way, reformatted to be prominent. The earlier example cited could be rectified in this manner: - ---- #REDIRECT [[Agar plate]] '''Blood agar''' is a special type of agar plate. See [[Agar plate#Types_of_agar_plates]] - ---- The following text would be inserted at the top of the article, so: - ---- :<i>'''Blood agar''' is a special type of agar plate. See [[Agar plate#Types_of_agar_plates]]</i> An '''agar plate''' is a sterile [[Petri dish]] that... (continue main content) - ---- IMHO, I think this is an elegant way of solving the "Irrelevant Redirect" problem. I also do not think that it would be very difficult to implement (although I'm no programmer for Mediawiki, so I can't really make any statements on this). - -- 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) iD8DBQFCdUDRqTO+fYacSNoRAsNzAJ9nobid8CawGv1WPfNDo5UUi+wxbACfa+rt VP/jtoWO7nAO3k3KkslrmVk= =j2Zw -----END PGP SIGNATURE-----

5 6

MediaWiki 1.4.4 released
by Brion Vibber 04 May '05

04 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MediaWiki 1.4.4 is a bugfix release for the 1.4 stable release series. Some bugs in the installer/updater and refreshLinks maintenance script were introduced in the last release and have been corrected. == Changes from 1.4.3 == * (bug 725) Let dir="ltr" attribute work again in MonoBook on RTL languages * (bug 2024) Skip JavaScript error for custom skins where .js message not set * (bug 2025) Updated Indonesian localization * (bug 2039) Updated Lithuanian localization * Don't die on PHP <4.3.0 when calling mysql_ping() * Fix refreshLinks cleanup step on MySQL 3.x * Fix breakage on rerunning the site_stats update * Localized namespaces for csb Release notes: http://sourceforge.net/project/shownotes.php?release_id=325088 Download: http://prdownloads.sf.net/wikipedia/mediawiki-1.4.4.tar.gz?download MD5 checksum: 85553d464041e36b85939810d79f5bf4 Before asking for help, try the FAQ: http://meta.wikimedia.org/wiki/MediaWiki_FAQ Low-traffic release announcements mailing list: http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce Wiki admin help mailing list: http://mail.wikipedia.org/mailman/listinfo/mediawiki-l Bug report system: http://bugzilla.wikimedia.org/ Play "stump the developers" live on IRC: #mediawiki on irc.freenode.net - -- brion vibber (brion @ pobox.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeMEcwRnhpk1wk44RAuXHAJ4w2k4pZ9nopOQU2M4IB8t7oDI3XwCfbC22 FjsQPU8hCVlGwRxrONsfCQs= =jkua -----END PGP SIGNATURE-----

1 0

VfD needs to be internally wired
by Edward Z. Yang 03 May '05

03 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was surfing Wikipedia the other day, and at one point, I had to use VfD. My experience makes me shudder. But that's not my point. In my opinion, the VfD is now beyond elegant implementation without hardwired software help. As of now, Wikipedia:Vfd is simply a page with lots of policy and lots of problems. HERE ARE SOME INSTANCES OF THE DEBATE ON THE TALK PAGE: Lotsofissues wrote: > 1/4 MB load - This no longer make sense. This page should only > contain links to individual day pages. Please voice your agreement Litefantastic wrote: > The VfD is so bogged down with junk articles that it's no longer > possible to edit without extreme patience. When I started (Nov 2003) > there was only about one-third the VfDing that there is today. I > think the VfD page has simply become outmodled: it wasn't designed > for this level of traffic. > > Since the WP is broken up in topics itself (Science, History, > Culture, etc.) why ddoesn't someone break up the VfD so that it > simply links to a bunch of VfD subpages, one for each major topic. > Someone with regular access to broadband. > > The overall speed rate would go back up to something approaching > usefulness, and the ease of use would suffer only slightly. We'd have > to fix all the VfD templates, too, but let's look at the positive > aspects just now. For the sake of sanity. True... but: Rossami wrote: > his gets suggested about once a quarter - and rejected every time. I > will again voice my unambiguous opposition. DO NOT STOP LISTING THE > ENTIRE WEEK. Users who don't like it now have lots of options. But > some of us (many?) view it as a responsibility to follow the VfD > discussions in order to see if new evidence has been presented which > should cause us to change a vote. The most efficient way I have to > fulfill that obligation is to load the entire page (which admittedly > takes some time) and then use the find function to skim through the > list looking for my own username. Yes, other people have proposed > other techniques. None of them work for me. Further, I think that it > is essential that at least some people do review the entire list in > order to identify common trends and patterns. Those observations are > used to propose policy changes, improve the instructions and > generally benefit Wikipedia in all sorts of subtle ways. And there are some proposed solutions: - From Wikipedia:Categorized Deletion > Otherwise, these category pages behave exactly like VfD currently > does, with the same time limits, the same criteria for deletion or > keeping, etc. However, they serve the purpose of bringing together > similar (in terms of field of knowledge) entries on VfD. Essentially, > these category pages are WikiProject pages, but used for > standardization of deletion instead of standardization of page > layouts. > > The majority of pages listed for deletion on VfD will still continue > to go on the VfD page; only those pages fitting specific, narrow > categories will be listed on the category VfD pages instead. - From Wikipedia:Countdown Deletion > Countdown deletion (CD) is intended to be an additional tool for > deletion. It would not supplant or modify Wikipedia:Votes for > deletion or Wikipedia:Criteria for speedy deletion in any way, except > for prohibiting VfD on an article already undergoing CD. Yet none of these ideas address the fundamental problem. The first tries to solve the problem by diverting entries from the page, while the second tries to stop entries from getting to VfD in the first place. But as volume increases, this will all but prove to be futile. In my humble opinion, the fundamental problem is that Wiki pages were never meant to support *this* sort of process. Talk pages are already a stretch: they aren't exactly ideal. Workable, but not ideal. VfD is simply a magnification of this problem. All we have is a wiki, a bunch of templates, and a lot of policy. It is time for software, the wiki, to lend a helping hand. HOWEVER... This path will not be without resistance and major road blocks. Many things one must consider: * These policies are not set in stone. How do we create a software solution that helps the process while not fixating the process on one implementation. This leads to: * How do we implement this? What exactly will the software *do* in order to help solve the problem? Because any changes that would suggest some sort of rules are going to be deeply frowned upon, here's what I'd propose. VfD becomes divided into several sections that all tap into the same "database" of VfD articles. This allows users to draw several versions of the page, including: * All with all comments * All active debates with all comments on them * All with only links * Only links for all active debates * Only links for today The process of adding VfDs to the database is ported to another completely different page, with a detailed procedures for adding VfD, and integrated checks to make sure the procedures are followed? (This may not be a good idea, but it should be clear that you should be able to Add without having to Read, and if you want to Casually browse, you don't have to read everything). This way, we: * Give something for everyone * Trim down the page for those who want it, and keep it that way for those who don't (after all, there are some people who like have a megabyte of information to browse) The negative is: * This puts a greater strain on Wikipedia servers with the parsing and output of these pages (which may require an entirely different sort of caching system). It probably will come down to only a few possible ways of viewing VfD to keep caching manageable. Soooo... *WHAT DO YOU THINK?* - -- 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) iD8DBQFCeCDBqTO+fYacSNoRAipUAJ99hkHKJc53NGG8gi0+fi4cHM1uCQCeNxdR BFMUtc0SnZeroWQGeweLlPU= =s0Ju -----END PGP SIGNATURE-----

2 1

Re: Redirect Pages: Text on them -> Text on article
by Edward Z. Yang 03 May '05

03 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timwi wrote: >> Although I'm a bit confused with your last paragraph: did you mean >> that the redirect pages are a hack, or the way they are being stored >> is a hack? > > The latter. Urp. Maybe we should fix that first before we do anything about redirect messages... - -- 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) iD8DBQFCeCi0qTO+fYacSNoRApgfAJ429zdP/1gfL9BWRf26up0xgfS7aACdFKx1 vAadqbe+CDKVKHR648P2Pl0= =YUPe -----END PGP SIGNATURE-----

1 0

Wikipedia Zeitgeist
by Georg Jaehnig 03 May '05

03 May '05

Hello, on German Wikipedia we've got the idea to have a Wikipedia Zeitgeist. Like Google Zeitgeist [1] it would show the most popular articles - not the most viewed, but the most edited of a week. This feature would reveal, which are the current "hot" topics among the authors and where there might be edit wars. The easiest way to realize this would be a log of the IRC-channel #derc.wikipedia. Even better would be a direct log of the "stupidbot's" output. The counting would be done by a simple Perl skript. A RecentChanges log might be also useful for other purposes, therefore it could be saved weekly (or daily) in a zip file and made available for download at http://download.wikimedia.org/. So is there a way to get the Recent Changes of a week? [1] http://www.google.com/press/zeitgeist.html -- | Jorge | Nur lernen, was man will: http://www.sudbury.de

6 7

Jump to page:

2026

2025

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