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