from_name: Gerard Meijssen

body:
David Gerard schreef:
> On 22/01/07, Till Weber <peterpanini at gmx.net> wrote:
>
>
>> IMHO the spread of wikipedia in small languages would be better, if all these languages appear in the left menue-bar of the wikipedia for each article. Then users see, if an article is already existent in their or other language and they can translate one from another language,. so the bi-languists can help to get the number of articles bigger, and then other users in the original language can complete or expand the article.
>>
>
>
> This would become very large, annoying and unhelpful for almost all
> users of the wiki. Perhaps something that can be switched on by those
> who want to see whether their own wiki has a given article? That may
> be possible just in personal CSS.
>
>
> - d.
Hoi,
A personal CSS is not the panacea where you can put things under the
rug. For most people this is not an issue. Most people are simple, such
a "solution" is at best something for one percent of our editors if that.
Thanks,
      GerardM


list: wikimedia-l

source: pipermail-mbox

subject:
[Foundation-l] Promoting non-en Wikipedias (was In defence of
 Google)


list: wikien-l

from_name: Oskar Sigvardsson

subject: [WikiEN-l] In the news...

body:
On 1/22/07, Neil Harris <usenet at tonal.clara.co.uk> wrote:
> Given some of the other stories linked on this page, I think this is
> more likely to be satire than news.
>
> -- Neil

I thought that was pretty obvious from the story itself :)

--Oskar


subject: [WikiEN-l] We need to give Weird Al a recruitment award

body:
On 1/22/07, David Gerard <dgerard at gmail.com> wrote:
> http://en.wikipedia.org/wiki/User:Amyroxanne
>
> "I joined Wikipedia due to the lyrics of White and Nerdy by Weird Al
> Yankovic. I thought it would help me extend the general persona I have
> of being a nerd, and loving it."
>
>
> - d.

Awww, that's so nice! We do love our nerds here on wikipedia :D

--Oskar


from_name: David Gerard

subject: [WikiEN-l] Microsoft asks for NPOVing of OOXML articles

body:
http://www.oreillynet.com/xml/blog/2007/01/an_interesting_offer.html

Note that the person writing that appears entirely on the level, by
the way. Heck, he posted openly about Microsoft asking him about it.

Personally, I've found getting NPOV on [[OpenOffice.org]] a goddamn
nightmare, and I'm a fan. There's something about open-source and
free-software related articles that attracts REALLY OBNOXIOUS
partisans, who don't understand NPOV and don't care - they see
Wikipedia as another platform for advocacy. [[Internet Explorer]] is a
carefully written NPOV article, most free-software articles have
fallen entirely to the advocates. This is a bad thing.

If you want to check editing on the subjects, by the way, please
remember not to bite the newbies!

- d.


subject:
[WikiEN-l] Promoting non-en Wikipedias (was In defence of
	Google)

body:
On 1/22/07, Steve Bennett <stevagewp at gmail.com> wrote:
> On 1/22/07, David Gerard <dgerard at gmail.com> wrote:
> > What can we do for countries where people routinely use the English
> > wikipedia and ignore their own language Wikipedia? I try to push local
>
> Start by formalising this concept, and producing a special interface
> for people who are reading the non-local version of their Wikipedia.
> For example, a user in the .fr domain whose language settings are set
> to FR reads a page on EN.  The interface could simultaneously present
> him with the english and french versions of the article (assuming they
> exist) and perhaps suggest to him that he might like to contribute to
> the FR version.
>
> Steve

Speaking as a Swede who hardly ever visit the Swedish wikipedia (I
know, I'm part of the problem, blah, blah blah ;), that would annoy
the crap out of me.

--Oskar


list: wikitech-l

subject: [Wikitech-l] Development of a Metadata/Cross-Indexing System

body:
Rob Church schreef:
> On 22/01/07, Domas Mituzas <midom.lists at gmail.com> wrote:
>
>> The concept (and code) for parsing the template information was
>> written back at Frankfurt's Wikimania. The problem - how to
>> efficiently index and query that afterwards.
>>
>
> I think we can only really answer that question if we actually plan
> the thing properly, and to do that, we need to know
>
> a. what we mean by "metadata"
> b. how we would use it
>
> It's all well and good implementing huge catch-all solutions like
> Wikidata and Semantic MediaWiki, but they're pretty much sledgehammer
> to a nut if we haven't identified example use cases for this data.
> Obviously, what we use it for will lead in to how our users access it,
> and from there, the all important queries I know Domas loves to
> optimise to hell and back.
>
>
> Rob Church
Hoi,
The functionality of "Wikidata" is being expressed better and better in
OmegaWiki. Other example use cases have been identified as long ago as
May 2005. Obviously the functionality that is being created is what it
will be used for. It is currently feasible to develop the functionality
to use OmegaWiki for the tagging of the pictures that are in Commons.
And yes, Domas is always welcome to optimise queries.

Thanks,
     GerardM

http://omegawiki.org
http://meta.wikimedia.org/wiki/Using_Ultimate_Wiktionary_for_Commons


from_name: Rob Church

subject: [Wikitech-l] regular users and rolling back protected pages

body:
On 22/01/07, Travis Derouin <travis at wikihow.com> wrote:
> Was this functionality intentional? I would have assumed that if a
> user didn't have the rights to edit a page, they wouldn't be able to
> roll it back.

*Probably not*

It probably makes sense to add the per-page check in addition to the
standard permissions check.

Rob Church


from_name: Thomas Dalton

body:
> Personally, I've found getting NPOV on [[OpenOffice.org]] a goddamn
> nightmare, and I'm a fan. There's something about open-source and
> free-software related articles that attracts REALLY OBNOXIOUS
> partisans, who don't understand NPOV and don't care - they see
> Wikipedia as another platform for advocacy. [[Internet Explorer]] is a
> carefully written NPOV article, most free-software articles have
> fallen entirely to the advocates. This is a bad thing.

Yes, it's unfortunate the NPOV is so often taken to mean "don't just
say bad things about the subject". While we're less likely to get sued
for being to positive in an article, it is just as un-neutral.


from_name: Daniel R. Tobias

body:
On 22 Jan 2007 at 20:43, "Thomas Dalton" <thomas.dalton at gmail.com>
wrote:

> I like the way you're thinking, but I'm not sure I like your idea. How
> about (once single sign-on is set up), a global setting where you can
> put (in order) your preferred languages.

Browsers already have such a feature, which leads to the contents of
the HTTP "Accept-Language" header being set.  Lots of site developers
seem to be compelled to keep reinventing this wheel, however.

http://webtips.dan.info/language.html

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/


list: foundation-l

from_name: Mark Clements

subject: [Foundation-l] EBNF of Wikitext

body:
"Virgil Ierubino" <virgil.ierubino at gmail.com>
wrote in message
news:24dce9db0701211957k752c1b69oec2d75ffbb4e5a68 at mail.gmail.com...
> On 1/22/07, Gerard Meijssen
<gerard.meijssen at gmail.com> wrote:
> > Personally, I'm intrigued. Virgil, could you elaborate on the purpose
> > of this project? In what ways can it help us (and who exactly is the
> > 'us' in this case :))?
>
> As explained already, an EBNF of Wikitext will allow for expansion of
> Wikitext easily as it's conforming to a standard, and a more efficient
> parser, etc. I'm not the expert in WHY it's good though, I just know it
is.
> And I know how to write EBNFs, and I can't work out how to code Wikitext's
> bullet points in EBNF - if EBNF can't handle Wikitext, then the efficient
> parsing and expansion won't be possible (as easily).
>
> Would very much appreciate help from anyone clued up as to how to proceed
if
> Wikitext can't be EBNFed, or who can show me that it, in fact, can.
>
> http://meta.wikimedia.org/wiki/Wikitext_Metasyntax

I missed the beginning of this thread for some reason.

Please also see http://www.mediawiki.org/wiki/Markup_spec and its sub-pages
for some work that has already been done in this area.  It would be useful
if you could merge your new page on meta into this existing content.

- Mark Clements (HappyDog)


subject: [Foundation-l] EBNF of Wikitext


subject: [Wikitech-l] EBNF of Wikitext


from_name: Mathias Schindler

subject: [WikiEN-l] In the news...

references:
<kbr9r2hm3850qmeimu9f9ajrcqstcfl2r0@4ax.com>
	<45B4F999.3090106@tonal.clara.co.uk>
	<4ed666e60701221038q4c9fcceeg4f7b074d817eaeaa@mail.gmail.com>

body:
On 1/22/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:

> I thought that was pretty obvious from the story itself :)

Not in a country that has the "Only in America"-slogan trademarked. (does it?).

Mathias


body:
> Start by formalising this concept, and producing a special interface
> for people who are reading the non-local version of their Wikipedia.
> For example, a user in the .fr domain whose language settings are set
> to FR reads a page on EN.  The interface could simultaneously present
> him with the english and french versions of the article (assuming they
> exist) and perhaps suggest to him that he might like to contribute to
> the FR version.

I like the way you're thinking, but I'm not sure I like your idea. How
about (once single sign-on is set up), a global setting where you can
put (in order) your preferred languages. Then, whenever you click on a
link, you can have it set to either:

1) Take you to the article in the language which is highest on your
list of preferred languages out of the languages that have an article
on that subject (judged by the presence of interwiki links)
2) Take you to the article in the same language as the article you
were reading, but with a very noticeable message at the top saying
"This article also exists in LANGUAGE" if there is an article in a
language you prefer. It should also say if another of your preferred
languages has it as a featured article.
3) Do exactly what it does now, for those that don't like change.

If you are reading an article in one language, and another of your
preferred languages doesn't have an article on that topic, it would be
great if, next to "Edit this page" was a "Create this article in
LANGUAGE" link - although if you clicked it, it would need to suggest
you look for an article in that language that simply isn't linked and
link it, before starting from scratch.


from_name: Edward Z. Yang

subject: [Wikitech-l] MD5 Password Encryption

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I am not mistaken (and I may very well be), MediaWiki still uses MD5s
to encrypt (well, technically hash, but it's named wfEncryptPassword(),
heh heh) user passwords.

function wfEncryptPassword( $userid, $password ) {
	global $wgPasswordSalt;
	$p = md5( $password);

	if($wgPasswordSalt)
		return md5( "{$userid}-{$p}" );
	else
		return $p;
}

If this is indeed the case, we should be considering migrating away from
MD5 to a more secure algorithm like SHA256. The breadth of attacks
against this hashing scheme have grown incredibly sophisticated, and
over where I consult, we generally discourage new developers from using
MD5 for any security related purposes (still makes a fine good checksum
though).

Migrating the hashes would probably prove to be tricky, but if we
implement appropriate hooks, with the addition of only one new field we
could easily "magically" update the fields once a user logs in, and the
system is (for one short request) in possession of the plaintext
password. The old algorithm could be supported indefinitely, but only
for old user accounts that haven't upgraded yet, all new accounts would
use the new hashing scheme. We could even rename the function into
something more accurate!

What say the developers?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtWicqTO+fYacSNoRAmQEAJ45Laiqabiclzix0wZ8cN2Y8CuVZACffFUB
DYyZ9MjWOhFalNSY73bpM0w=
=9sel
-----END PGP SIGNATURE-----


from_name: Łukasz Garczewski

subject:
[Foundation-l] [Announcement] Welcome to our new Communication
	Manager

body:
On 1/22/07, Kat Walsh <mindspillage at gmail.com> wrote:
> On 1/22/07, Florence Devouard <anthere at anthere.org> wrote:
> > The Foundation is pleased to announce the addition of Sandra Ordonez as
> > Communications Manager. Sandy is a public relations specialist living in
> > Tampa, Florida, with prior experience in for-profit and non-profit
> > organizations. Her role will include press relations, written and oral
> > communications, and various other assignments. We are fortunate to have
> > had Sandy approach us about a position, and we are excited to have her
> > start working in the office. Please say hello if you run into her online
> > (her wiki and irc name is "wiki blue") and welcome her to the community.

Hi Sandy!

> Welcome to the madhouse. :-)

Indeed. Has anybody stopped to ponder how will this new position fit
in with ComComm? :)

--
?ukasz 'TOR' Garczewski


body:
On 1/22/07, ?ukasz Garczewski <lgarczewski at gmail.com> wrote:

> Indeed. Has anybody stopped to ponder how will this new position fit
> in with ComComm? :)

Here's a german proverb: Was nicht passt, wird passend gemacht.

I hope the literal translation does not sound to harsh :)

Mathias


from_name: Tim Starling

subject: [Wikitech-l] Squid log collection infrastructure

body:
We now have squid logs again, after a long absence. We're using the UDP
logging patch I describe here:

http://www.squid-cache.org/mail-archive/squid-dev/200701/0042.html

The log collection program is running on henbane. The log format is our
own custom format described here:

https://wikitech.leuksman.com/view/Squid_log_format

Only a sampled log will be stored, the full log will only be available as
a real-time stream.

I'd like to invite submissions at this stage for log analysis programs,
which can process either the full stream or a sampled stream, aggregate
the data and present statistics on the web. There are lots of log analysis
packages already available, but I haven't found one yet that is designed
to work at such a high request rate.

Currently we only have a raw log, which contains duplicates due to
requests forwarded between squids. These should probably be filtered out
by the collection daemon before the log is handed out to the analysers.

-- Tim Starling


from_name: Myles Gray

subject: [WikiEN-l] New Test Templates

body: Will someone please explain to me why the new test templates have a number one in front of it? I was placing {{uw-vandalism3}} on the user's talk page, and I find a number one. See here<about:blank>. Thanks! --Bushcarrot<about:en.wikipedia.org/wiki/User:Bushcarrot>


from_name: Simetrical

subject: [Wikitech-l] MD5 Password Encryption

body:
On 1/22/07, Edward Z. Yang <edwardzyang at thewritingpot.com> wrote:
> If this is indeed the case, we should be considering migrating away from
> MD5 to a more secure algorithm like SHA256. The breadth of attacks
> against this hashing scheme have grown incredibly sophisticated, and
> over where I consult, we generally discourage new developers from using
> MD5 for any security related purposes (still makes a fine good checksum
> though).

Aren't the vulnerabilities limited to the attacker creating a
collision of two strings *that the attacker created* sharing a common
prefix?  Are they relevant to a password hash?  There's no preimage
attack against MD5, and that strikes me as the only thing relevant to
passwords.  Things like certificates can be a problem, of course,
depending on exact implementation.


body:
On 22/01/07, Evan Prodromou <evan at prodromou.name> wrote:
> I'll go ahead and plug the existing RDF extension:

Plug away! I never looked at it before...

Rob Church


from_name: Rory Stolzenberg

subject: [WikiEN-l] New Test Templates

body:
On 1/22/07, Myles Gray <MylesGray_33 at msn.com> wrote:
>
> Will someone please explain to me why the new test templates have a number
> one in front of it? I was placing {{uw-vandalism3}} on the user's talk page,
> and I find a number one. See here<about:blank>. Thanks! --Bushcarrot<about:
> en.wikipedia.org/wiki/User:Bushcarrot>

See
http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384


subject: [WikiEN-l] New Test Templates

body:
Thank you.
  ----- Original Message -----
  From: Rory Stolzenberg<mailto:rory096 at gmail.com>
  To: English Wikipedia<mailto:wikien-l at lists.wikimedia.org>
  Sent: Monday, January 22, 2007 9:35 PM
  Subject: Re: [WikiEN-l] New Test Templates

  On 1/22/07, Myles Gray <MylesGray_33 at msn.com<mailto:MylesGray_33 at msn.com>> wrote:
  >
  > Will someone please explain to me why the new test templates have a number
  > one in front of it? I was placing {{uw-vandalism3}} on the user's talk page,
  > and I find a number one. See here<about:blank>. Thanks! --Bushcarrot<about:
  > en.wikipedia.org/wiki/User:Bushcarrot>

  See
  http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384<http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384>
  _______________________________________________
  WikiEN-l mailing list
  WikiEN-l at lists.wikimedia.org<mailto:WikiEN-l at lists.wikimedia.org>
  To unsubscribe from this mailing list, visit:
  http://lists.wikimedia.org/mailman/listinfo/wikien-l<http://lists.wikimedia.org/mailman/listinfo/wikien-l>


from_name: Nick Jenkins

subject: [Wikitech-l] slowness today

body:
> >> There's no "policy" here. Just *sense*.
> >
> > Fortunately, this has been written up as policy: [[m:Don't be dense]].
> > Phew! Writing it up as policy should fix the problem!
>
> *cries*

<rant>
Before anyone feels tempted to propose new policies, can they please try a simple test first: Take the negative/opposite, and ask
yourself if anyone normal would support it, or do that thing. If the answer is "no", then the policy or naming is probably daft,
because it's not telling you anything you don't already know.

Example: "Don't be dense"   --opposite-->    "Try to be completely stupid"  ---Would anyone normal support?-->  "No"  -->  policy is
a waste of space.

For what it's worth, the same idea also applies to the names of action groups too:

Example: "Women against rape"   --opposite-->    "Men in favour of rape"  ---Would anyone normal support?-->  "No"  -->  stupid
name.
Example: "International Physicians for the Prevention of Nuclear War"   --opposite-->    "International Physicians trying to
encourage Nuclear War"  ---Would anyone normal support?-->  "No"  -->  stupid name.

So, if you feel tempted to come up with policies or guidelines such as "Don't torture cute kittens and then bury them alive", then
please: Don't. Thanks!
</rant>

All the best,
Nick.


from_name: Gatto Nero

body:
2007/1/22, Cormac Lawler <cormaggio a gmail.com>:

> (This job
> description by Gatto Nero is quite a brief!)

I've been often accused of being too much talkative... that's why I
sintesized... too much :D
(Or, maybe, it could be, peut etre, forse, koennte sein, 'cause of my
total lack of conoscence of English :D )


body:
2007/1/22, Cormac Lawler <cormaggio at gmail.com>:

> (This job
> description by Gatto Nero is quite a brief!)

I've been often accused of being too much talkative... that's why I
sintesized... too much :D
(Or, maybe, it could be, peut etre, forse, koennte sein, 'cause of my
total lack of conoscence of English :D )


subject: [WikiEN-l] New Test Templates

body:
Okay, I was confused at first. So, thanks for clearing that up.
  ----- Original Message -----
  From: Eugene van der Pijll<mailto:eugene at vanderpijll.nl>
  To: English Wikipedia<mailto:wikien-l at lists.wikimedia.org>
  Sent: Monday, January 22, 2007 9:47 PM
  Subject: Re: [WikiEN-l] New Test Templates

  Rory Stolzenberg schreef:
  > On 1/22/07, Myles Gray <MylesGray_33 at msn.com<mailto:MylesGray_33 at msn.com>> wrote:
  > >
  > > Will someone please explain to me why the new test templates have a number
  > > one in front of it?
  >
  > See
  > http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384<http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384>

  Right. So it is to make these templates more useful for book-keeping, and
  to make them look less like personal communication.

  Eugene

  _______________________________________________
  WikiEN-l mailing list
  WikiEN-l at lists.wikimedia.org<mailto:WikiEN-l at lists.wikimedia.org>
  To unsubscribe from this mailing list, visit:
  http://lists.wikimedia.org/mailman/listinfo/wikien-l<http://lists.wikimedia.org/mailman/listinfo/wikien-l>


subject: [Wikitech-l] MD5 Password Encryption

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brion Vibber wrote:
> As a note; AFAIK versions of PHP prior to 5.1.2 include only MD5 and
> SHA-1 digest functions built-in, and the rumor is SHA-1 isn't safe
> enough either. [snip]

I would recommend rolling a pure-PHP implementation of SHA-256 and
siwtching to the hash implementation if it is present. The hash isn't
computed very often: only during login and password setting, so any
performance penalty incurred wouldn't be that bad. Plus, there are
already a number of quite fast SHA-256 implementations out there for
PHP. I personally recommend: <http://code.tatzu.net/sha256/>

> With appropriate hash functions present, we could indeed auto-upgrade
> hashes on login. (A new field is not necessarily required; the existing
> hash field can be upgraded to indicate the hash algo along with the hash
> value. And in a happy case of coincidence, the password hash fields are
> tinyblobs, so anything that fits in 255 bytes is cool...)

Works then, since raw binary SHA-256 output is only 256 bits (64 bytes,
I believe). We can easily spare another 7 bytes to prepend it with
something along the lines of "sha256:"

Simetrical wrote:
> Aren't the vulnerabilities limited to the attacker creating a
> collision of two strings *that the attacker created* sharing a common
> prefix?  Are they relevant to a password hash?  There's no preimage
> attack against MD5, and that strikes me as the only thing relevant to
> passwords.  Things like certificates can be a problem, of course,
> depending on exact implementation.

Well, in spite of these extremely devastating attacks in the collision
area, the keyspace of MD5 is extremely small: 128 bits is small enough
that a birthday attack is extremely feasible. MD5 also has many
comprehensive rainbow tables (including one that's 4.9 TB large!) I
think it's worth migrating, even if the security increase is
comparitatively small. It's not difficult to do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtXgoqTO+fYacSNoRAlD+AJ4rbqYappCdINOnd04L+2c/XxpDKACeJNWu
HxrsAq6hlrMjKKOk//inoUE=
=3wk3
-----END PGP SIGNATURE-----


from_name: Ivan Krstić

subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org> <45B572AF.1020203@pobox.com>
	<ep3t7a$upc$1@sea.gmane.org>

body:
Edward Z. Yang wrote:
> I would recommend rolling a pure-PHP implementation of SHA-256 and
> siwtching to the hash implementation if it is present.

New crypto implementations often have far more security issues than the
primitives they're implementing. Despite the known attacks on SHA-1,
it's perfectly fine for password hashing, and it doesn't require
external libraries. Use it, be merry.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org>
	<45B572AF.1020203@pobox.com>	<ep3t7a$upc$1@sea.gmane.org>
	<45B57998.6080605@solarsail.hcs.harvard.edu>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ivan Krsti? wrote:
> New crypto implementations often have far more security issues than the
> primitives they're implementing. Despite the known attacks on SHA-1,
> it's perfectly fine for password hashing, and it doesn't require
> external libraries. Use it, be merry.

Actual encryption (both design and implementation) is indeed rocket
science, but implementing cryptographic hashes is not difficult at all
as long as you understand the algorithm and a good battery of unit tests
to make sure your implementation is working properly.

Yes, actually *designing* a hash function is difficult. And yes, SHA-1
*probably* is still good enough. But if we're going to go the trouble of
migration (small trouble, but trouble that requires DB schema changes
nonetheless (be they formal or informal)), we might as well do it right.
I remember one security expert saying that there is no smoke yet, but
the alarm bells have gone off for SHA-1 and it's time to walk (not run)
for the exits.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtXvcqTO+fYacSNoRApoGAJ9Puqsb5SRQoJJtMf4JNzCMJ32B7QCdG7D0
Wj9X9jjaIV3WSiduM46XJXs=
=eN5t
-----END PGP SIGNATURE-----


from_name: Anthony

subject: [Wikitech-l] MD5 Password Encryption

body:
On 1/22/07, Edward Z. Yang <edwardzyang at thewritingpot.com> wrote:
> Well, in spite of these extremely devastating attacks in the collision
> area, the keyspace of MD5 is extremely small: 128 bits is small enough
> that a birthday attack is extremely feasible. MD5 also has many
> comprehensive rainbow tables (including one that's 4.9 TB large!) I
> think it's worth migrating, even if the security increase is
> comparitatively small. It's not difficult to do.

A birthday attack is not relevant to a password hashing scheme, and
rainbow tables are useless since Mediawiki uses salts.

The fact that the keyspace of MD5 is only 128 bits does limit the
password strength, but who's using a password more than 13 characters
for their Wikipedia password?  Does Mediawiki even allow more than 13
character passwords?

Anthony


subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org> <45B572AF.1020203@pobox.com>
	<ep3t7a$upc$1@sea.gmane.org>
	<71cd4dd90701221911w1cfcf3eeya2f08812c5903ff9@mail.gmail.com>

body:
On 1/22/07, Edward Z. Yang <edwardzyang at thewritingpot.com> wrote:
> Well, in spite of these extremely devastating attacks in the collision
> area, the keyspace of MD5 is extremely small: 128 bits is small enough
> that a birthday attack is extremely feasible.

Birthday attack, maybe, but that's useless for cracking a password.
It's still far too large to brute-force a preimage.  Maybe not for too
many years to come . . . I don't disagree with the idea of moving to a
new hash function just to be safe.  It seems like a good idea.

(While we're on the topic of hashes, by the way, vBulletin has
JS-enabled browsers hash and salt their passwords before they even
send them.  Thus man-in-the-middle attacks are impossible.  Seems like
a nifty idea to consider, anyway.)

On 1/22/07, Anthony <wikitech at inbox.org> wrote:
> The fact that the keyspace of MD5 is only 128 bits does limit the
> password strength, but who's using a password more than 13 characters
> for their Wikipedia password?  Does Mediawiki even allow more than 13
> character passwords?

I think the limiting factor in password length in MediaWiki is how
large a POST the server is willing to accept.  ;)  I once tried a
password on my local install thousands of pages long, just for the
heck of it, and it worked fine.


from_name: Brion Vibber

subject: [Wikitech-l] MD5 Password Encryption

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simetrical wrote:
> (While we're on the topic of hashes, by the way, vBulletin has
> JS-enabled browsers hash and salt their passwords before they even
> send them.  Thus man-in-the-middle attacks are impossible.  Seems like
> a nifty idea to consider, anyway.)

I did a demo implementation of that a couple years ago (might be in SVN
somewhere, or might be lost) on this model:

- - server sends a challenge string C with the login form
- - JavaScript takes over on form submission, asking server for the salt
(user id) for the given name
- - client calculates the salted hash H
- - client calculates a combined hash, something like MD5(c + H), and
submits that with the form instead of plaintext
- - server confirms that the submitted combined hash matches what it can
calculate with the challenge string and its copy of H

Is it more secure than sending plaintext passwords? A bit. But even if
the challenge can armor against replay attacks, anyone sniffing can just
hijack the session cookie and do all manner of nasty things right then
and there.

There was some muttering at the time that just using HTTPS is safer and
it's not worth the bother. Agreement? Disagreement?

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFta3XwRnhpk1wk44RAoS6AJ93zpLEoXoAMKQDwfBMTFw3AS1FnQCfXmBs
rotOXAaYzYzNC8ailwO6pMY=
=h4i6
-----END PGP SIGNATURE-----


subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org>	<45B572AF.1020203@pobox.com>	<ep3t7a$upc$1@sea.gmane.org>	<45B57998.6080605@solarsail.hcs.harvard.edu>
	<ep3u4t$16p$1@sea.gmane.org>

body:
Edward Z. Yang wrote:
> implementing cryptographic hashes is not difficult at all
> as long as you understand the algorithm and a good battery of unit tests
> to make sure your implementation is working properly.

Yes, and jet turbine maintenance is not difficult at all as long as you
understand their construction and have a good battery of pre-flight
tests to make sure they're working properly. Yet you wouldn't feel very
comfortable grabbing a random person off the street, handing them the
manual, and having them go to town on the engines of your 747.

It's trivial to introduce all sorts of subtle bugs when creating new
crypto implementations -- we've seen this happen time after time -- so
unless there's a particularly compelling reason to reimplement from
scratch, sticking with something that's already out and has had many
eyeballs looking at it is almost always the correct choice.

> But if we're going to go the trouble of
> migration (small trouble, but trouble that requires DB schema changes
> nonetheless (be they formal or informal)), we might as well do it right.
> I remember one security expert saying that there is no smoke yet, but
> the alarm bells have gone off for SHA-1 and it's time to walk (not run)
> for the exits.

FUD. Talk of "doing it right" and "alarm bells having gone off" is
meaningless without a threat model. New uses of SHA-1 are rightly
discouraged in protocol design, where collisions directly translate to
potential problems, but password hashing?

Generally, the only password hashing scenario in which the choice of
algorithm makes a difference at all is an offline attack once the
password table has been compromised, at which point, the difference
between one algorithm and the next is nothing more but how long you can
hold off a brute-forcing attacker. And for that, without preimage
attacks, the known MD5 and SHA-1 flaws make about zero difference for
any practical purpose.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] In the news...

body:
I actually bought that until I saw the other headlines.
I wouldn't want to place that guy in any situation requires face to face
contact. He might scare off other women. Community service on Wikipedia
makes perfect sense...

Mgm

On 1/22/07, Mathias Schindler <mathias.schindler at gmail.com> wrote:
>
> On 1/22/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
>
> > I thought that was pretty obvious from the story itself :)
>
> Not in a country that has the "Only in America"-slogan trademarked. (does
> it?).
>
> Mathias
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


from_name: Gregory Maxwell

subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org> <45B572AF.1020203@pobox.com>
	<ep3t7a$upc$1@sea.gmane.org>
	<45B57998.6080605@solarsail.hcs.harvard.edu>
	<ep3u4t$16p$1@sea.gmane.org>
	<45B58624.1070903@solarsail.hcs.harvard.edu>

body:
On 1/22/07, Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> wrote:
[snip]
> Generally, the only password hashing scenario in which the choice of
> algorithm makes a difference at all is an offline attack once the
> password table has been compromised, at which point, the difference
> between one algorithm and the next is nothing more but how long you can
> hold off a brute-forcing attacker. And for that, without preimage
> attacks, the known MD5 and SHA-1 flaws make about zero difference for
> any practical purpose.

Ivan is right on in his statements here.

There might be good reasons to move.. for example, as part of an
overall effort to stop using legacy hash functions throughout the
software... or better, to change to a system which supports client
side hashing.

None of the pre-existing MD5 rainbow tables will do a lick of good
against mediawiki because of the weird legacy inspired H(s+'-'+H(P))
that we use.

Frankly, we could probably be using classic unix crypt() for this
application. Hashing our server side passwords is useful to make it
less attractive for someone to steal the database, and perhaps keep a
curious developer from doing something actually useful like publishing
a list of accounts with the same password.

Once we've succeeded in making sure that attacking the database of
passwords is no longer the lowest hanging fruit, we're pretty much
done... Taking the extra effort to add lots of additional security
will only risk adding additional vulnerabilities.

(/me waits for someone to notice my above H(s +'-'+H(P)) above and cry
about the minor precomputation a smart attacker can do to reduce the
workload from 2*users*passwords MD5s to passwords + passwords*users
MD5s)

If someone wants to add something that will substantially improve
security which requires no substantial changes, ... build something
like Google's password strength indicator for the password change
page. :) (bonus points for pure js rather than ajax based)


from_name: Oldak Quill

subject: [WikiEN-l] Water chestnuts

body:
On 22/01/07, Gregory Kohs <thekohser at gmail.com> wrote:
> Doesn't the water chestnut deserve a little better than this confusing
> disambiguation page?  It's a pretty common food.  Does the Wikipedia
> community really expect users to find their way specifically to [[Eleocharis
> dulcis]] to get a half-decent write-up on the water chestnuts that many of
> their recipes call for?

Just some quick Google results:
+"Water chestnut" +"Eleocharis dulcis"
(http://www.google.co.uk/search?q=%2B%22Water+chestnut%22+%2B%22Eleocharis+dulcis%22)
produces  807 results)

+"Water chestnut" +"Trapa natans"
(http://www.google.co.uk/search?hl=en&safe=off&client=firefox&rls=org.mozilla%3Aen-GB%3Aunofficial&hs=EKn&q=%2B%22Water+chestnut%22+%2B%22Trapa+natans%22&btnG=Search&meta=)
gives 25,700 results

Without searching further, wouldn't the page (were it not a
disambiguation page) better point to T. natans, rather than E. dulcis
as you suggest?

--
Oldak Quill (oldakquill at gmail.com)


from_name: Thomas Dalton

subject: [WikiEN-l] Water chestnuts

body:
> Could somebody please explain why [[Water chestnut]] is a disambiguation
> page (with, in my opinion, neither splitting article really doing a good job
> of describing the tuber that most English-speaking people are familiar with
> from either a grocery store can or their local Chinese restaurant), while
> [[Corn]] (which redirects to [[Maize]]) is a really nice article that talks
> about the corn we all know and love, while having a convenient,
> unobtrusive "disambig" flag at the top?
>
> Doesn't the water chestnut deserve a little better than this confusing
> disambiguation page?  It's a pretty common food.  Does the Wikipedia
> community really expect users to find their way specifically to [[Eleocharis
> dulcis]] to get a half-decent write-up on the water chestnuts that many of
> their recipes call for?

It would appear that two different plants are known as "Water
chestnut" and neither is significantly more important than the other,
so we have a disambig page. It's standard practice. What would you
have instead?


from_name: Andrew Gray

subject: [WikiEN-l] Water chestnuts

body:
On 22/01/07, Gregory Kohs <thekohser at gmail.com> wrote:
> Could somebody please explain why [[Water chestnut]] is a disambiguation
> page (with, in my opinion, neither splitting article really doing a good job
> of describing the tuber that most English-speaking people are familiar with
> from either a grocery store can or their local Chinese restaurant), while
> [[Corn]] (which redirects to [[Maize]]) is a really nice article that talks
> about the corn we all know and love, while having a convenient,
> unobtrusive "disambig" flag at the top?
>
> Doesn't the water chestnut deserve a little better than this confusing
> disambiguation page?  It's a pretty common food.  Does the Wikipedia
> community really expect users to find their way specifically to [[Eleocharis
> dulcis]] to get a half-decent write-up on the water chestnuts that many of
> their recipes call for?

I think we expect them to be intelligent enough to open [[water
chestnut]] and click on the appropriate link. (I would have no idea
which one it is, but then I don't eat them)

What I want to know is... why does [[corn]], in much of the
English-speaking world a generic term either for cereal crops in
general or the locally-dominant crop specifically, and a term with
several other distinct meanings, redirect to the specific footstuff
called "corn" in America?

I find it amusing we have entirely opposite reactions to these two!

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: The Cunctator

subject:
[WikiEN-l] Nofollow back on URL links on en.wikipedia.org
	articles for now

body:
On 1/22/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> On 1/23/07, The Cunctator <cunctator at gmail.com> wrote:
> > On 1/20/07, Brion Vibber <brion at pobox.com> wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Having been requested by Jimmy to do so, and having seen a fun rumor of
> > > a "search engine optimization world championship" contest targeting
> > > WP[1], I've gone ahead and switched rel="nofollow" back onto URLs in
> > > en.wikipedia.org's article namespace.
> >
> >
> > Does Jimmy have that authority? Should this have  gone through the board?
> > Did it?
>
> You know very well that the board lets Jimbo run wikipedia. If they
> have a problem with his actions, they can do something about it, but
> lets face it: for the first half-decade that Jimbo's been in control,
> he's done a pretty darn good job.
>
> This is just wikilawyering.
>
That's not what wikilawyering is. I wasn't questioning whether Jimbo
was doing a good or bad job, and I seriously doubt he needs people to
leap to his defense and resort to namecalling to attack questioners.

I asked three specific questions, which so far as I know Anthony and
Oskar can't directly answer except through (reasonable) surmisal.

Is it explicit policy that Jimbo continues to have a free hand to make
policy decisions for Wikipedia by fiat? I think that would be
perfectly fine, but I'm still trying to grasp what Jimbo's role is
becoming as the Foundation becomes more established and formal.


from_name: Platonides

subject: [Wikitech-l] Suggestion: "Maintenance mode" (JavaScript thingie)

body:
Dschwen wrote:
> I just whipped up a little Javascript for that purpose (PHP developers, start
> puking now!). Just insert the following lines into your monibook.js (or
> whichever skin you are using.
>
> // [[User:Dschwen/highlightredirects.js]] - please include this line
> document.write('<script type="text/javascript" src="'
> + 'http://en.wikipedia.org/w/index.php?title=User:Dschwen/highlightredirects.js'
> + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
>
> Have fun and please report bugs directly to me (less spammy to the list and
> less embarrasing to me :-) )

Problem with JavaScript solutions is that they need *another* http
query. If that was done on the server side there would be no overhead.

Some points about the code:
It uses 5 functions:
createXMLHTTP, updateStatus, addEvent, install and run

Being it new worl, i'd discourage coding new fucntions for addEvent and
createXMLHTTP, as the general Mediawiki javascript includes already
includes equivalent functions (theoretically with full browser compat.).

It's interesting your style of making eveything into a big variable.


subject: [Wikitech-l] MD5 Password Encryption

body:
On 1/22/07, Mark Clements <gmane at kennel17.co.uk> wrote:
> And could you remember it the next time you tried to log in? :-)

Well, I believe it consisted entirely of the letter 'A', so possibly I
could have if I wanted to.  :P


subject: [Wikitech-l] First upload of quantitative results (WikiXRay)

body:
Felipe Ortega escribi?:
> Hi all.
>
> Finally, the first upload of images created with WikiXRay is available:
>
> http://en.wikipedia.org/wiki/Wikipedia:WikiXRay
>
> For next updates I'll try to use Commonist for faster upload of lots of
> files.
>
> Any comments about the graphics are welcomed.
>
> Saludos.
>
> Felipe Ortega.

Wouldn't the page fit better on meta than on en.wiki?

Does Evolution in time section have images? It'd be interesting the
number of articles evolution on pt: as they use bot creation quite a lot.


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Water chestnuts

body:
On Mon, 22 Jan 2007 18:05:27 -0500, "Gregory Kohs"
<thekohser at gmail.com> wrote:

>Could somebody please explain why [[Water chestnut]] is a disambiguation
>page

Or why [[Raleigh]] is not.  An entire nation and half a Commonwealth
thinks Raleigh means first an explorer and second a bicycle
manufacturer.

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


subject: [Wikitech-l] Protection expiration

body:
Brion Vibber wrote:
> Another of Werdna's contributions: page protections can now have an
> expiration time added. The accepted input format is the same as for
> custom block times.

Hooray!
Thanks, Werdna.

Note that Special:Log correctly shows expiration time, but the
'automatic edit' doesn't, so when you see the history, there's a
protection entry (with no unprotection) on an unprotected page.


from_name: Sebastian Moleski

subject: [Wikitech-l] Protection expiration

body:
On 1/22/07, Platonides <Platonides at gmail.com> wrote:
>
> Brion Vibber wrote:
> > Another of Werdna's contributions: page protections can now have an
> > expiration time added. The accepted input format is the same as for
> > custom block times.
>
>
>
> Hooray!
> Thanks, Werdna.
>
> Note that Special:Log correctly shows expiration time, but the
> 'automatic edit' doesn't, so when you see the history, there's a
> protection entry (with no unprotection) on an unprotected page.

Also, what message needs to be edited to show the expiration time in the
protection log?

sebmol


subject: [WikiEN-l] Water chestnuts

body:
On 22/01/07, Gregory Kohs <thekohser at gmail.com> wrote:
> Oldak says:
> ++++++++++++++++
> Just some quick Google results:
> +"Water chestnut" +"Eleocharis dulcis"
> (
> http://www.google.co.uk/search?q=%2B%22Water+chestnut%22+%2B%22Eleocharis+dulcis%22
> )
> produces  807 results)
>
> +"Water chestnut" +"Trapa natans"
> (
> http://www.google.co.uk/search?hl=en&safe=off&client=firefox&rls=org.mozilla%3Aen-GB%3Aunofficial&hs=EKn&q=%2B%22Water+chestnut%22+%2B%22Trapa+natans%22&btnG=Search&meta=
> )
> gives 25,700 results
>
> Without searching further, wouldn't the page (were it not a
> disambiguation page) better point to T. natans, rather than E. dulcis
> as you suggest?
> +++++++++++++++++
> Which one do you think 98% of Wikipedia users are actually searching for?

I admit my search may skew the results in favour of botany (rather
than cuisine or popular culture), but since matching "Water chestnut"
with T. natans gives 30 times more results, I would say there is a
significance to my results.

I'm surprised that the association that seems obvious to you produces
less than 1000 Google hits.

--
Oldak Quill (oldakquill at gmail.com)


from_name: Cormac Lawler

body:
On 1/22/07, Gatto Nero <gattonero at gmail.com> wrote:
> 2007/1/22, Cormac Lawler <cormaggio at gmail.com>:
>
> > (This job
> > description by Gatto Nero is quite a brief!)
>
> I've been often accused of being too much talkative... that's why I
> sintesized... too much :D
> (Or, maybe, it could be, peut etre, forse, koennte sein, 'cause of my
> total lack of conoscence of English :D )
>

:-) However, this isn't what I meant. By "brief" here, I meant
"job"/"plan of action" (ie. brief - the noun), NOT "short" (ie. brief
- the adjective). (Though there are other meanings of "brief"..)

English can be pretty confusing alright - I even tried to teach it
once (I gave up). :-)

Cormac


subject: [Wikitech-l] Protection expiration

body:
Sebastian Moleski wrote:
  > Also, what message needs to be edited to show the expiration time in the
> protection log?
>
> sebmol

I just translated
*MediaWiki:Protect-expiring
*MediaWiki:Protectexpiry
*MediaWiki:Protect_expiry_invalid

I don't find more related messages. If there're, please tell.


subject: [Foundation-l] The Ideal Wiki Software

body:
Speaking from the technical side, there is a hurdle with the "vastly
improved searches" that are requested, at least on one aspect. The way
MediaWiki currently stores its data is in InnoDB tables, which allow for
simultaneous reads and writes with high efficiency and low lag. However,
these do not contain a full-text search index; MyISAM tables do. The search
index table is the only MyISAM table on the database, due to precisely that
limitation. Currently, every edit has to be copied to the search table,
usually by a script, and those take a while to run and consume precious
system resources. Ideas as to how to make that process better are greatly
recommended at Wikitech-l.

As for categories: date of page creation is not stored in the tables right
now; that would be ideally something for the page table. The time a page
included in a category is already stored (or at least, there is room for
it), so that may be easier to do in the future. Dynamic sort tables have
issues with older browsers, but maybe a sortby can be done by the server as
well. These things do require a considerable amount of coding and testing,
though.

Titoxd.

Titoxd.

-----Original Message-----
From: foundation-l-bounces at lists.wikimedia.org
[mailto:foundation-l-bounces at lists.wikimedia.org] On Behalf Of Brianna
Laugher
Sent: Monday, January 22, 2007 11:05 PM
To: Wikimedia Foundation Mailing List
Subject: Re: [Foundation-l] The Ideal Wiki Software

On 23/01/07, Virgil Ierubino <virgil.ierubino at gmail.com> wrote:
> In an ideal world, what features would the ideal Wiki Software have, and
> what would it be like?

I have outlined some of my hopes for the future of MediaWiki in
file/image management (ie. the Commons) in comments on this bug:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3712

I dream of a MediaWiki II that is actually designed to manage media -
like the name implies. :)

Vastly improved and more flexible search would also benefit all wikis.
There is a hella lotta potential for improving options when working
with categories, too (for example, I envisage a drop-down list with
options for the sort key - date page created, date added to category,
page name (alphabetical - current default), date page was last edited.
etc.

cheers,
Brianna
user:pfctdayelise

_______________________________________________
foundation-l mailing list
foundation-l at lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/foundation-l


subject: [Foundation-l] The Ideal Wiki Software


from_name: Ray Saintonge

body:
David Gerard wrote:

>On 22/01/07, teun spaans <teun.spaans at gmail.com> wrote:
>
>
>>The low representation of Indian citizens surprises me. I met one or two at
>>the english wikipedia / commons, perhaps they tend to prefer the english
>>wiki above their local languages?
>>
>>
>This appears to be the case. The educated classes tend to learn in
>English and to talk to each other in English. There are many native
>languages in India, but the one that all educated people are likely to
>speak is English, so that's the one that gets spoken. English is
>regarded as higher status than the local languages.
>
That and by being foreign English is not seen as giving an advantage to
a ny particular part of the country as would be the case with a native
language.

Ec


from_name: Keitei

body:
On Jan 22, 2007, at 23:20, The Cunctator wrote:
> Is it explicit policy that Jimbo continues to have a free hand to make
> policy decisions for Wikipedia by fiat? I think that would be
> perfectly fine, but I'm still trying to grasp what Jimbo's role is
> becoming as the Foundation becomes more established and formal.

http://meta.wikimedia.org/wiki/Foundation_issues
See number 5?

--keitei


from_name: David Gerard

subject: [WikiEN-l] Fwd: [Wikitech-l] Protection expiration

body:
---------- Forwarded message ----------
From: Brion Vibber <brion at pobox.com>
Date: 22-Jan-2007 21:44
Subject: [Wikitech-l] Protection expiration
To: wikitech-l at lists.wikimedia.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another of Werdna's contributions: page protections can now have an
expiration time added. The accepted input format is the same as for
custom block times.

While we've put it through its courses, it's possible there's still some
minor issues or corner cases, so give a shout if you notice anything awry!

There's also a Special:Protectedpages list, but it's not fully
functional yet. (As well as a few minor issues, as it's marked
'expensive' it won't show any results yet on the live site as the cache
is empty.)

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtTBQwRnhpk1wk44RAgHmAJ9hToS3ahUyAmQDJQVi82OcQclyzQCfXglS
giSBn1AqMDj6wa74Wo0kLgU=
=2yE/
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l at lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2007-01-23

body:
An automated run of parserTests.php showed the following failures:

This is MediaWiki version 1.10alpha (r19600).

Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...

  18 still FAILING test(s) :(
      * URL-encoding in URL functions (single parameter)
      * URL-encoding in URL functions (multiple parameters)
      * TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
      * TODO: Link containing double-single-quotes '' (bug 4598)
      * TODO: message transform: <noinclude> in transcluded template (bug 4926)
      * TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
      * BUG 1887, part 2: A <math> with a thumbnail- math enabled
      * TODO: HTML bullet list, unclosed tags (bug 5497)
      * TODO: HTML ordered list, unclosed tags (bug 5497)
      * TODO: HTML nested bullet list, open tags (bug 5497)
      * TODO: HTML nested ordered list, open tags (bug 5497)
      * TODO: Inline HTML vs wiki block nesting
      * TODO: Mixing markup for italics and bold
      * TODO: 5 quotes, code coverage +1 line
      * TODO: dt/dd/dl test
      * TODO: Images with the "|" character in the comment
      * TODO: Parents of subpages, two levels up, without trailing slash or name.
      * TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.

Passed 489 of 507 tests (96.45%)... 18 tests failed!


from_name: JePe

subject: [Wikitech-l] Protection expiration

body:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Another of Werdna's contributions: page protections can now have an
> expiration time added. The accepted input format is the same as for
> custom block times.
>
> While we've put it through its courses, it's possible there's still some
> minor issues or corner cases, so give a shout if you notice anything awry!

One issue, the expire time in the log is in UTC instead of the local time of the
wiki.

Something else, is it possible to use the same interface for the duration as
used in the duration of an user block. A selection menu with the options from
MediaWiki:Ipboptions.

Hans (JePe)


list: commons-l

from_name: Brianna Laugher

subject: [Commons-l] Flickr group for Commons

body:
Hi all,

I just started a group on Flickr called "Wikimedia Commons". I
encourage anyone who has a Flickr account to join it.

http://www.flickr.com/groups/wikimedia_commons/

It can be used as a way to increase our presence on Flickr and explain
the utility of CC-BY and CC-BY-SA licenses to Flickr users, on their
own turf where they are much more likely to be receptive to helping us
out. Flickr users who are unexperienced with wikis/Commons can post
photos to the group where I am sure one of us will gladly transfer
them, if they are useful. Flickr users can have the satisfaction of
seeing their work in prime  web real estate, especially if they
photograph famous people for example. :) People who photograph plants
can also post photos there to get them IDed before transfer to
Commons.

I think some people also post comments on photos when they transfer
them to Commons. It might be useful in such a comment to also post a
link to this group now, to encourage them to learn more about how they
can contribute to Wikimedia, the world's largest and most accessible
of open content.

So anyway, all members and discussion now welcome :)

cheers,
Brianna
user:pfctdayelise


from_name: Eugene van der Pijll

subject: [WikiEN-l] Water chestnuts

body:
Gregory Kohs schreef:
> Oldak, I don't mean to be snippy, but, I don't really care what Google
> results on that search say, if (according to Wikipedia)...
>
> Water caltrop is:
> "sold as an occasional streetside snack in the south of" China.
>
> Eleocharis dulcis is:
> "The small, rounded corms <http://en.wikipedia.org/wiki/Corm> have a crispy
> white flesh and can be eaten raw, slightly boiled, grilled, pickled, or
> tinned <http://en.wikipedia.org/wiki/Canning>. They are a popular ingredient
> in Western-style Chinese dishes. In China, they are most often eaten raw,
> sometimes sweetened. They can also be ground into a
> flour<http://en.wikipedia.org/wiki/Flour>which is used especially to
> make fried cakes called
> *matigao* (??????; m??t? g??o). They are unusual among vegetables for remaining
> crisp even after being cooked or canned."
>
> Which one do you think 98% of Wikipedia users are actually searching for?
> How many of them might be confused by their "eenie meenie mynie moe" on the
> disambiguation page.

I'm not an expert on these plants; never having met them before; but the
number of interwiki links on both pages seem to confirm that the most
well known, and therefore the most common of these two, even in Western
Europe, would be Trapa natans.

But a disambiguation page is probably best.

Eugene


from_name: Steve Bennett

subject: [Wikitech-l] Suggestion: "Maintenance mode"

body:
On 1/22/07, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> It's the very first comment, by the person who WONTFIXed it (i.e.,
> Brion, who as you may recall is the lead developer):  "Redirects are
> meant to be a transparent part of the user interface. Behaving just
> like other links is desired behavior, not a bug."

"Transparent" is ambiguous here. Normally in these contexts,
transparent means "the user can see exactly what is going on". Whereas
Brion apparently meant "invisible", in the sense that "transparent"
glass is kind of "invisible".

Semantics aside, being able to distinguish redirects from links to
real articles strikes me as useful, and not "undesirable" at all.
Example: I have a page in my user space that links to all the stubs
I've started. Clicking "related changes" shows any changes to any page
I started - useful for me. If anyone renames any of those stubs, it
becomes a redirect. "Related changes" then quietly[1] breaks, because
future changes to the stub no longer show up. It would be very handy
for me to see which of my links are actually pointing to redirects.

Remember we're still talking about "maintenance mode" here - you
wouldn't want redirects to show up specially for users in normal mode
(especially non-logged-in users).

Steve
[1] The actual change to a redirect will show up, once.


subject: [Commons-l] Flickr group for Commons

body:
On 23/01/07, David Monniaux <David.Monniaux at free.fr> wrote:
> Brianna Laugher a ?crit :
> > Hi all,
> >
> > I just started a group on Flickr called "Wikimedia Commons". I
> > encourage anyone who has a Flickr account to join it.
> >
> > http://www.flickr.com/groups/wikimedia_commons/
> I have a big issue with Flickr and free licenses.
>
> Flickr typically show "this photo is public" in a proeminent place,
> while their sign about copyleft is less clear.
>
> Many people incorrectly conclude that "public" photos on Flickr are
> "public domain". In fact, what Flickr means by "public" is that these
> photos are publicly viewable by any Internet user, as opposed to
> restricted to friends or contacts of the user who posted them.
>
> Consequences:
> 1) Many people assume they can download anything from Flickr and use
> them without any kind of restriction as long as there's "this photo is
> public".
> 2) Flickr users are not really aware of free licenses.
>
> Maybe we should talk to Flickr about that issue. Their interface should
> be redesigned so as to minimize confusion.

Yes, you are right - the design is bad. I think it could be improved
just by changing "public" to "publicly viewable". or "This photo can
be viewed by anyone".

I guess that Commons regulars know this difference. :)

We can use this group as a visible presence on Flickr try to correct
such mistakes as aggressively as possible, and possibly push for such
interface changes. But I guess Flickr will still leave the default as
"all rights reserved" -- most people are happy not to think about
copyright of course.

Well, as an unrelated aside, I find it very interesting that Creative
Commons ( http://creativecommons.org/ ) loves to push Flickr, counts
Jimbo on its board of directors, and yet has never even mentioned
Wikimedia Commons in even remotely the same way (see
http://creativecommons.org/image ). Or, for that matter, Wikinews.

(No, I'm not bitter that Flickr is such a media darling...!)

cheers,
Brianna


subject:
[WikiEN-l] Fwd: [Wikitech-l] First upload of quantitative
	results (WikiXRay)

body:
David is speechless. I concur - awesome work. Will this be regularly updated?

On the graphics, slightly clearer (layman-friendly) legends would be
nice. I sort of get what a 1 on a "log" axis means...but seeing "10
bytes" would be simpler :)

Also, what is "density"?

Steve

On 1/23/07, David Gerard <dgerard at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Felipe Ortega <glimmer_phoenix at yahoo.es>
> Date: 22-Jan-2007 12:35
> Subject: [Wikitech-l] First upload of quantitative results (WikiXRay)
> To: wikitech-l at lists.wikimedia.org, wiki-research-l at lists.wikimedia.org
>
>
> Hi all.
>
> Finally, the first upload of images created with WikiXRay is available:
>
> http://en.wikipedia.org/wiki/Wikipedia:WikiXRay
>
> For next updates I'll try to use Commonist for faster upload of lots of files.
>
> Any comments about the graphics are welcomed.
>
> Saludos.
>
> Felipe Ortega.
>
>
> ---------------------------------
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y m?viles desde 1 c?ntimo por minuto.
> http://es.voice.yahoo.com
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


body:
On 1/22/07, David Gerard <dgerard at gmail.com> wrote:
> What can we do for countries where people routinely use the English
> wikipedia and ignore their own language Wikipedia? I try to push local

Start by formalising this concept, and producing a special interface
for people who are reading the non-local version of their Wikipedia.
For example, a user in the .fr domain whose language settings are set
to FR reads a page on EN.  The interface could simultaneously present
him with the english and french versions of the article (assuming they
exist) and perhaps suggest to him that he might like to contribute to
the FR version.

Steve


body:
On 1/23/07, Rob Church <robchur at gmail.com> wrote:
> It's already been agreed that we can probably add a class for users
> who would like one, as it incurs no additional performance penalty in
> Linker::makeLinkObj(); I wouldn't introduce a whole new "mode" for
> this, though...users who *want* their redirect links distinguised can
> just add the relevant line to their custom CSS.

Ok cool. Should I file a bug?

Then maybe later we can come up with an elegant way for people to get
certain pre-defined CSS styles to appear in certain pre-defined ways
without having to hack their monobook.css. There are other styles in
this category (notably, spoilers).

Steve


from_name: Andre Engels

subject:
[Foundation-l] Promoting non-en Wikipedias (was In defence of
	Google)

body:
2007/1/22, teun spaans <teun.spaans at gmail.com>:

> Funny: The english, german and french wikis do not seem to have an article
> on the omoro language. Yet from this stat I gather they have 32million
> native speakers.
>

That's my fault, I made an error - the language is not called Omoro, but
Oromo, and as such has an article in these language as well as (according to
the English page) 10 others.

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


from_name: Luna

body:
On 1/22/07, David Gerard <dgerard at gmail.com> wrote:
>
> http://en.wikipedia.org/wiki/User:Amyroxanne
>
> "I joined Wikipedia due to the lyrics of White and Nerdy by Weird Al
> Yankovic. I thought it would help me extend the general persona I have
> of being a nerd, and loving it."
>

Awesome. =3 Something to balance out all the "->Replaced page with
<big><big>YOU SUCK</big></big>" fun I get to have.

Every cloud has its silver lining, no? We never know where people will come
from -- I got drawn in because I was trying to use a Wikipedia page as a
source, in some political forum, and a page I needed was up at AfD.

-Luna


body:
On 1/22/07, David Gerard <dgerard at gmail.com> wrote:
>
> ---------- Forwarded message ----------
> From: Brion Vibber <brion at pobox.com>
>
> Another of Werdna's contributions: page protections can now have an
> expiration time added. The accepted input format is the same as for
> custom block times.
>
> While we've put it through its courses, it's possible there's still some
> minor issues or corner cases, so give a shout if you notice anything awry!
>
> There's also a Special:Protectedpages list, but it's not fully
> functional yet. (As well as a few minor issues, as it's marked
> 'expensive' it won't show any results yet on the live site as the cache
> is empty.)
>
> - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
>

Alright, score one more for our wonderful devs. :) They've been keeping as
busy and productive as ever.

-Luna


body:
2007/1/22, Till Weber <peterpanini at gmx.net>:

see here, for example "Madonna"
>
> can we have this automatically for each keyword added in each language?

The short answer is no.

The longer answer is: How are you going to decide automatically what the
title of the page in some language will be? That you use "Madonna
(entertainer)" in English but "Madonna (cantante)" in Italian, "Madonna
(artist)" in Norwegian and "Madonna Ciccone" in simple English? That it's
"??????" in Serbian, but "???????" (with the "(????????)" added) in Russian?

There's no automatic way to make those decisions. It might be possible to do
it by hand, but even then there is a danger of someone not realizing that
something is a homonym in their language, and create a link which, when
filled in, becomes incorrect.

Also, I doubt whether the use of this would be so great. It might get people
to the other languages, it might also make those interwiki links even less
used than they are now - after you have found 5 times "there is no article
on this subject in <insert language here>, you can write it" when clicking
on the link to your own language, you might well turn away from clicking it
at all.

ok, the cryptic languages need manual advice, but we can do a link already..
> then the index will grow... That?s all we need for promotion !!!
>
> http://en.wikipedia.org/wiki/Madonna_(entertainer)
>
> [[ar:??????]]
> [[bg:?????? (??????)]]
> [[bs:Madonna]]
> [[ca:Madonna]]
> [[cbk-zam:Madonna]]
> [[cs:Madonna]]
> [[da:Madonna]]
> [[el:???????]]
> [[en:Madonna (entertainer)]]
> [[eo:Madonna]]
> [[es:Madonna]]
> [[fa:????? (???????)]]
> [[fi:Madonna]]
> [[fr:Madonna]]
> [[gl:Madonna]]
> [[he:?????]]
> [[hr:Madonna]]
> [[hu:Madonna (?nekesn?)]]
> [[id:Madonna]]
> [[it:Madonna (cantante)]]
> [[ja:???? (??)]]
> [[ka:?????? (?????????)]]
> [[la:Madonna (cantrix)]]
> [[lt:Madonna]]
> [[mk:?????? (???????)]]
> [[nds-nl:Madonna (zangeres)]]
> [[nl:Madonna (zangeres)]]
> [[no:Madonna (artist)]]
> [[pl:Madonna]]
> [[pt:Madonna]]
> [[ro:Madonna]]
> [[ru:??????? (????????)]]
> [[simple:Madonna Ciccone]]
> [[sk:Madonna]]
> [[sl:Madonna]]
> [[sq:Madonna]]
> [[sr:??????]]
> [[sv:Madonna]]
> [[th:????????]]
> [[tr:Madonna]]
> [[vi:Madonna (ca s?)]]
> [[vls:Madonna (zangeresse)]]
> [[yi:??????]]
> [[zh:???]]
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


from_name: Oskar Sigvardsson

body:
On 1/23/07, The Cunctator <cunctator at gmail.com> wrote:
> On 1/20/07, Brion Vibber <brion at pobox.com> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Having been requested by Jimmy to do so, and having seen a fun rumor of
> > a "search engine optimization world championship" contest targeting
> > WP[1], I've gone ahead and switched rel="nofollow" back onto URLs in
> > en.wikipedia.org's article namespace.
>
>
> Does Jimmy have that authority? Should this have  gone through the board?
> Did it?

You know very well that the board lets Jimbo run wikipedia. If they
have a problem with his actions, they can do something about it, but
lets face it: for the first half-decade that Jimbo's been in control,
he's done a pretty darn good job.

This is just wikilawyering.

--Oskar


subject:
[WikiEN-l] Citizendium trying out not being a fork of Wikipedia
	for a while

body:
On 1/22/07, Guettarda <guettarda at gmail.com> wrote:

> Looking through the Citizendium forum is interesting
> http://forum.citizendium.org/
>
> I took a good look at them this weekend and tried to figure out what they
> were about, and how they saw themselves from being different to us.  There
> appear to be two key elements of CZ that distinguishes it from WP -
> approved
> versions (your edits don't show up until they are approved) and expert
> approval (that you need to be a subject-matter expert, a so-called
> "Editor"
> in order to approve a version).

The other one that interests me is their hierarchical project setup -- the
workgroups are far more rigidly defined, and each is given specific charge
of a group of articles (as opposed to Wikipedia's more fluid and loose
system).

CZ's strategy seems more regimented, as I understand users are even "ranked"
based on their level of expertise on given subjects; on the upside, I
anticipate that working things out that way will cut down on some of the
nasty content disputes we've seen on en.wikipedia, and will encourage users
to be cooperatively productive, once they get into things.

I imagine it'll be more difficult to integrate new or casual users into such
an environment -- although I believe typo fixes and general cleanup are
still encouraged in a "drive-by" style. Getting new people into using a
wiki, especially when they're not the most tech-savvy people around, is
difficult under the best of circumstances. It'll be interesting to see how
workgroups change the newcomer's experience.

But I'm just rambling.

-Luna
**


from_name: Delirium

subject:
[WikiEN-l] Nofollow back on URL links on
 en.wikipedia.org	articles for now

body:
Keitei wrote:
> On Jan 22, 2007, at 23:20, The Cunctator wrote:
>
>> Is it explicit policy that Jimbo continues to have a free hand to make
>> policy decisions for Wikipedia by fiat? I think that would be
>> perfectly fine, but I'm still trying to grasp what Jimbo's role is
>> becoming as the Foundation becomes more established and formal.
>>
>
> http://meta.wikimedia.org/wiki/Foundation_issues
> See number 5?
>
That was written before the first Board of Trustees election even took
place, though, so is somewhat out of date these days.

-Mark


subject: [WikiEN-l] Microsoft offering to pay people to edit WP articles

body:
Yeah, David posted that article a couple of threads ago:

http://lists.wikimedia.org/pipermail/wikien-l/2007-January/061314.html

On 1/23/07, George Herbert <george.herbert at gmail.com> wrote:
> Found on Slashdot:
> http://www.oreillynet.com/xml/blog/2007/01/an_interesting_offer.html
>
> Targeted articles was apparently:
>   http://en.wikipedia.org/wiki/OOXML
>
> --
> -george william herbert
> george.herbert at gmail.com
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] New Test Templates

body:
Rory Stolzenberg schreef:
> On 1/22/07, Myles Gray <MylesGray_33 at msn.com> wrote:
> >
> > Will someone please explain to me why the new test templates have a number
> > one in front of it?
>
> See
> http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384

Right. So it is to make these templates more useful for book-keeping, and
to make them look less like personal communication.

Eugene


from_name: Mark Clements

body:
"Magnus Manske" <magnusmanske at googlemail.com> wrote
in message
news:fab0ecb70701220032p2a20b5fcw86d18c916da7c5eb at mail.gmail.com...
> I once posted the idea (which, of course, was ignored;-) to store the
> names and values of variables passed to templates from articles in a
> SQL table. If you write {{xyz|a=1|b=2}} in article BLA and save, it
> would store
> BLA | xyz | a | 1
> BLA | xyz | b | 2
> in said table. Applied to {{Persondata}} [1], you could search for a
> specific birth date, or for "%January%1980%" to find people born in
> January 1980, which you can not do with the current category system,
> even with intersections, AFAIK.
>
> Given the amount of data we put in navboxes via templates, this is a
> vast repository of unharvested metadata, IMHO.

I have been working on a WikiDB extension that would work as a direct
substitution for infoboxes (i.e. it would require the page to be edited, but
it is the kind of edit that could be done by a bot).

The result would be visually identical, but it additionally adds the data to
a named table that can then be queried.

See http://www.kennel17.co.uk/testwiki/WikiDB for details.  I would
appreciate some feedback!

- Mark Clements (HappyDog)


from_name: Ivan Krstić

subject: [Wikitech-l] MD5 Password Encryption

body:
Brion Vibber wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?

Absolutely agreed. Not being able to deal with the computational cost of
SSL is the only convincing reason to try and use JavaScript hackery to
do a more secure login, and I don't think that's a valid concern at
Wikipedia these days. If you find a designated SSL login machine becomes
CPU-bound, I can recommend PCI SSL accelerator cards that'll be happy to
take over the work.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


subject: [Wikitech-l] MD5 Password Encryption

body:
"Simetrical" <Simetrical+wikitech at gmail.com>
wrote in message
news:7c2a12e20701221939h45f35021u6e37e067ba078df2 at mail.gmail.com...
> On 1/22/07, Anthony <wikitech at inbox.org>
wrote:
> > The fact that the keyspace of MD5 is only 128 bits does limit the
> > password strength, but who's using a password more than 13 characters
> > for their Wikipedia password?  Does Mediawiki even allow more than 13
> > character passwords?
>
> I think the limiting factor in password length in MediaWiki is how
> large a POST the server is willing to accept.  ;)  I once tried a
> password on my local install thousands of pages long, just for the
> heck of it, and it worked fine.

And could you remember it the next time you tried to log in? :-)

- Mark Clements (HappyDog)


subject: [Wikitech-l] License status of MW screenshots.

body:
Hi,

I didn't receive any replies to this question (below).  Is there perhaps a
better place to ask it?

- Mark Clements (HappyDog)

"Mark Clements" wrote:
> This pops up every so often at www.mediawiki.org, particularly in relation
> to the public domain help pages that we are trying to compile.
>
> What is the correct license for screenshots of MediaWiki?  Are we able to
> distribute them along with the PD help pages (when we get to that stage)?
> Currently they are variously tagged as GFDL, PD, (c) WMF and possibly
> others.
>
> Are there any considerations that may cause some screenshots to be under
> one license and some under another?  E.g. if the screenshot includes
> the MW logo or certain interface text does it affect how it can be
> licensed?  What about the different skins?
>
> It would be good to have this question answered officially, once and for
> all.
>
> - Mark Clements (HappyDog)


from_name: Virgil Ierubino

subject: [Foundation-l] The Ideal Wiki Software

body:
In an ideal world, what features would the ideal Wiki Software have, and
what would it be like?

If we can answer this question, developmental direction is made clear. It is
easy to develop MediaWiki with view to improving it, streamlining it,
ironing out bugs - but much more difficult to look beyond it; for the future
of Wikimedia projects and general wiki success, new software must emerge
that caters for the new functions required by modern wiki users.

What functions would set MediaWiki well above all other wiki engines for
years to come?
What features would make it the most efficient wiki engine?
**What would the software be like if it generated maximal wiki success?**

To discuss this (what I find an interesting) question, I've set up a page at
http://meta.wikimedia.org/wiki/MediaWiki_Ideal

Obviously the answers to these questions won't necessarily be possible to
implement; but it would be interesting to know the answers nonetheless.

Look forward to some bright ideas :)


subject: [Foundation-l] The Ideal Wiki Software


subject: [Wikitech-l] The Ideal Wiki Software


from_name: Mohamed Magdy

subject: [Foundation-l] The Ideal Wiki Software

body:
Virgil Ierubino wrote:
> In an ideal world, what features would the ideal Wiki Software have, and
> what would it be like?
>
> If we can answer this question, developmental direction is made clear. It is
> easy to develop MediaWiki with view to improving it, streamlining it,
> ironing out bugs - but much more difficult to look beyond it; for the future
> of Wikimedia projects and general wiki success, new software must emerge
> that caters for the new functions required by modern wiki users.
>
> What functions would set MediaWiki well above all other wiki engines for
> years to come?
> What features would make it the most efficient wiki engine?
> **What would the software be like if it generated maximal wiki success?**
>
> To discuss this (what I find an interesting) question, I've set up a page at
> http://meta.wikimedia.org/wiki/MediaWiki_Ideal
>
> Obviously the answers to these questions won't necessarily be possible to
> implement; but it would be interesting to know the answers nonetheless.
>
> Look forward to some bright ideas :)
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

Faster loading time

M.M.


subject: [Foundation-l] The Ideal Wiki Software


from_name: Anthony

subject: [Wikitech-l] MD5 Password Encryption

body:
On 1/23/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> Hoi,
> Actually I will not lay off on Single User Login. The reason is quite
> simple. Some things that are important to me will not happen until AFTER
> Single User Login. It is all well and good that everyone comes up with
> the most nifty things and all kinds of functionality that HAS to be
> implemented because you are volunteers too. In the mean time some rather
> basic stuff does not get done. If this drives you mad, fine. Fix the
> issue - help Brion implement SUL !
>
> The promised date for SUL was end of January 2005. It is now a year late.
>
> Thanks,
>     GerardM
>
I couldn't agree with this more.  Single User Login is a pretty
useless feature.  It was a neat dream back in 2001 or whenever
passport.com came out, but it really is rather useless.  But...there
are so many other useful features that are being ignored because they
aren't scheduled to be implemented until *after* SUL.

I really wish the board would fix the issue and tell Brion to just
drop the whole idea of Single User Login.  You know, Firefox (like
probably all the other browsers) has this nifty feature that stores
your username and password for each site, so you only have to type in
your password once.

By the way, January 2005 was *two* years ago, not one.

Anthony


subject: [Wikitech-l] MD5 Password Encryption

body:
Anthony wrote:
> Single User Login is a pretty useless feature.  It was a neat dream
> back in 2001 or whenever passport.com came out, but it really is
> rather useless. [...] You know, Firefox (like probably all the other
> browsers) has this nifty feature that stores your username and
> password for each site, so you only have to type in your password
> once.

SUL isn't generic SSO. Clearly, you have little or no understanding of
the kind of problems that SUL is trying to fix or the benefits it would
bring, so I'm not sure why you thought it was a good idea to embarrass
yourself on a public list by backing ignorance with invective.

You aren't entitled to getting your desired MediaWiki features
implemented by other people. If the current development model or pace
bother you, either focus on your power animal and find the patience to
wait some more, or start posting patches.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


from_name: Raimond Spekking

subject: [Wikitech-l] Protection expiration

body:
Sebastian Moleski schrieb:
> Also, what message needs to be edited to show the expiration time in the
> protection log?

The expiration time is shown in the log. With
[[MediaWiki:Protect-expiring]] you can change the text around time/date.

Raymond.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20070123/bb868377/attachment.pgp>


from_name: Andrew Gray

subject: [WikiEN-l] New Test Templates

body:
On 23/01/07, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> Layout standardization is a nice goal, but why do the templates have to be
> given a longer name?
> Why can't the change be discussed and the resulting layout applied to the
> existing templates as was done with FAC templates and the like?

The idea appears to be to phase them in; if you don't like them you
can continue using the traditional warnings. At some indefinite point,
if the community is happy with them, {{test2-n}} and all its friends
will presumably become redirects to these,,,

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: Rob Church

subject: [Wikitech-l] MD5 Password Encryption

body:
On 23/01/07, Brion Vibber <brion at pobox.com> wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?

What infrastructure changes would it require for us to start migrating
to HTTPS, at least during the login process?

Rob Church


from_name: Gerard Meijssen

subject: [Foundation-l] The Ideal Wiki Software

body:
Hoi,
What is great about MediaWiki is its capability for localisation. This
is what sets it apart from other wiki-engines. There is however room for
improvement. It would help the smaller projects if much of the
maintenance where drastically improved. The long awaited integration of
the "BetaWiki" functionality in MediaWiki proper and its integration in
the Incubator is part of it. Some responsiveness for localisation issues
like with the Marathi projects is another.

When a new recognised language is to be considered for MediaWiki, the
first thing to do is to make the appropriate language file and be able
to distribute it.

Thanks,
    GerardM

Virgil Ierubino schreef:
> In an ideal world, what features would the ideal Wiki Software have, and
> what would it be like?
>
> If we can answer this question, developmental direction is made clear. It is
> easy to develop MediaWiki with view to improving it, streamlining it,
> ironing out bugs - but much more difficult to look beyond it; for the future
> of Wikimedia projects and general wiki success, new software must emerge
> that caters for the new functions required by modern wiki users.
>
> What functions would set MediaWiki well above all other wiki engines for
> years to come?
> What features would make it the most efficient wiki engine?
> **What would the software be like if it generated maximal wiki success?**
>
> To discuss this (what I find an interesting) question, I've set up a page at
> http://meta.wikimedia.org/wiki/MediaWiki_Ideal
>
> Obviously the answers to these questions won't necessarily be possible to
> implement; but it would be interesting to know the answers nonetheless.
>
> Look forward to some bright ideas :)
>


subject: [Foundation-l] The Ideal Wiki Software


subject: [Wikitech-l] [Foundation-l] The Ideal Wiki Software


subject: [Wikitech-l] The Ideal Wiki Software

body:
On 23/01/07, Virgil Ierubino <virgil.ierubino at gmail.com> wrote:
> What functions would set MediaWiki well above all other wiki engines for
> years to come?

I believe one of the features that *does* set it above the others, at
least in large wiki use cases, is the incredible support it has to
scale to millions of simultaneous users all reading, editing, arguing
etc. We have support for database replication, a nifty load balancer,
support for a number of object caches including memcached, and the
smaller, one-machine caches that things like APC and eAccelerator
provide. We have extensive support for Squid caches and for
appropriate purging of these caches.

> To discuss this (what I find an interesting) question, I've set up a page at
> http://meta.wikimedia.org/wiki/MediaWiki_Ideal

Why, oh why are people still creating *software* pages on Meta? We've
got the http://www.mediawiki.org domain; we're trying to move anything
MediaWiki related *away* from Meta, to leave more room for all that
Foundation bickering, and so we know where we stand.

I also think this page is a little redundant. We don't want wiki pages
cataloguing feature requests; we have a bug/enhancement tracker for
that purpose.

> Obviously the answers to these questions won't necessarily be possible to
> implement; but it would be interesting to know the answers nonetheless.

Are you offering to implement some, or at least one of them? When I
randomly ask users for feature requests, sometimes they're small and
easy, and sometimes I get a flood of ideas which I can't implement
right that minute, but it always sets me thinking about possible
future enhancement.

Rob Church


from_name: Lane, Ryan

subject:
[Wikitech-l] HTTPS virtual hosting (was Re: MD5 Password
	Encryption)

body:
> HTTPS does support virtual hosting. You can have certificates
> with wildcards, e.g. *.wikipedia.org, and you can even have
> certificates that list multiple second-level domains. In
> theory we could even support https://en.wikipedia.org/, by
> having LVS pass the traffic off to an SSL proxy cluster,
> which forwards to the Florida squids via a secure tunnel.
>

>From what I've read HTTPS does not support name-based virtual hosting,
only IP based virtual hosting, as the SSL connection happens before the
request is made. So, if you have two virtual hosts such as:

<Virtualhost en.wikipedia.org>
...
</Virtualhost>

<Virtualhost de.wikipedia.org>
...
</Virtualhost>

The first virtual host will always be used as the server has absolutely
no clue, when the connection is made, which virtual host it needs to
use.

I believe this is the point Neil was trying to make.

V/r,

Ryan Lane


subject: [Wikitech-l] MD5 Password Encryption

body:
On 23/01/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> I would say first finish the Single User Login. It makes little sense to
> consider it before this implementation as it is part of the login process.

*shrug*

All I did was ask what kind of changes we would need to plan for. You
know, if we require a few hundred new servers, we might as well whinge
about that at the next budget allocation now, so we can plan ahead.

I don't see you rushing to help with single-user login. Nor do I see
any of those people who're whinging about it taking ages, and how they
could do better, coming up with any better implementations.

This next bit isn't aimed at you Gerard...CAN PEOPLE PLEASE LAY OFF ON
SINGLE USER LOGIN? It's driving us all mad everytime someone asks
"when and how", and if I were Brion, I'd be getting absolutely bloody
*sick* of it. Furthermore, "SUL" is *not* some magical sword which
will fix all our problems in one fell swoop, so please remember that.

Rob Church


from_name: Nick Jenkins

subject:
[Wikitech-l] Allowing Type Hinting in MediaWiki
	internalfunctions: Yes or No?

body:
> On 1/22/07, Rob Church <robchur at gmail.com> wrote:
> > On 22/01/07, Nick Jenkins <nickpj at gmail.com> wrote:
> > > public function parse( $text, Title $title, array $options, $linestart = true, $clearState = true, $revid = null ) {
> >
> > When did Parser::parse() take an array of options? ParserOptions is a
> > class...or have I missed some significant restructuring?

I was only applying a mechanical transformation to a randomly selected function, based on that function's own documentation:

       /**
         * Convert wikitext to HTML
         * Do not call this function recursively.
         *
         * @param string $text Text we want to parse
         * @param Title &$title A title object
         * @param array $options
        ^^^^^^^^^^^^^^^^^^^^^^^^^
         * @param boolean $linestart
         * @param boolean $clearState
         * @param int $revid number to pass in {{REVISIONID}}
         * @return ParserOutput a ParserOutput
         */
        public function parse( $text, &$title, $options, $linestart = true, $clearState = true, $revid = null ) {

> See, this is why we could use type hinting.  :P

Touche! :-)

All the best,
Nick.


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] New Test Templates

body:
Layout standardization is a nice goal, but why do the templates have to be
given a longer name?
Why can't the change be discussed and the resulting layout applied to the
existing templates as was done with FAC templates and the like?

Mgm

On 1/23/07, Myles Gray <MylesGray_33 at msn.com> wrote:
>
> Okay, I was confused at first. So, thanks for clearing that up.
> ----- Original Message -----
> From: Eugene van der Pijll<mailto:eugene at vanderpijll.nl>
> To: English Wikipedia<mailto:wikien-l at lists.wikimedia.org>
> Sent: Monday, January 22, 2007 9:47 PM
> Subject: Re: [WikiEN-l] New Test Templates
>
>
> Rory Stolzenberg schreef:
> > On 1/22/07, Myles Gray <MylesGray_33 at msn.com<mailto:MylesGray_33 at msn.com>>
> wrote:
> > >
> > > Will someone please explain to me why the new test templates have a
> number
> > > one in front of it?
> >
> > See
> >
> http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384
> <
> http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_on_user_warning_layout_standardisation&oldid=92676384
> >
>
> Right. So it is to make these templates more useful for book-keeping, and
> to make them look less like personal communication.
>
> Eugene
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org<mailto:WikiEN-l at lists.wikimedia.org>
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l<
> http://lists.wikimedia.org/mailman/listinfo/wikien-l>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


from_name: habj

subject:
[WikiEN-l] Promoting non-en Wikipedias (was In defence of
	Google)

body:
2007/1/21, David Gerard <dgerard at gmail.com>:

> What can we do for countries where people routinely use the English
> wikipedia and ignore their own language Wikipedia? I try to push local
> Wikipedias when talking to the press (and far too many  seem to be
> unaware of their own language Wikipedia) and mention the international
> character talking to the English-language press. That hopefully does a
> little, but not enough.

Besides enwiki actually being the longer and "better story",
journalists learn about their subject from other journalists.
Journalists will read the articles on English Wikipedia that they can
find on the net. In them, English Wikipedia is routinely referred to
as Wikipedia. Of course the journalists will focus on Wikipedia =
English Wikipedia, not on the "we also have Wikipedias in n number of
languages". If Jimmy Wales, people on the board and others giving
interviews would make sure to say English Wikipedia a bit more often
when they are talking about English Wikipedia, that would probably
make some kind of difference.

Of course, the major part of that effort would be wasted since the
journalist will shorten English Wikipedia to Wikipedia. They are short
of space, and as we all know Wikipedia most of the time _is_ used as
an abbreviation for English Wikipedia.

/habj


subject: [Wikitech-l] MD5 Password Encryption

body:
Rob Church schreef:
> On 23/01/07, Brion Vibber <brion at pobox.com> wrote:
>
>> There was some muttering at the time that just using HTTPS is safer and
>> it's not worth the bother. Agreement? Disagreement?
>>
>
> What infrastructure changes would it require for us to start migrating
> to HTTPS, at least during the login process?
>
>
> Rob Church
Hoi,
I would say first finish the Single User Login. It makes little sense to
consider it before this implementation as it is part of the login process.
Thanks,
     GerardM


from_name: bbatsell

subject: [WikiEN-l] Mircosoft paying people to edit

body:
On Jan 23, 2007, at 3:34 AM, Mathias Schindler wrote:

>> I think we should protect it.
>
> I think we should help Rick to fix the article. Since when are we
> opposed to people who try to improve articles?

Although I absolutely agree with the sentiment (and think we should
clean up any POV problems in the article), my answer to your question
would be, "when people are being paid by the subject to do so", which
in my opinion is a clear [[WP:COI|conflict of interest]].

[[User:bbatsell]]


from_name: Jimmy Wales

subject: [WikiEN-l] something to look out for

body:
http://www.opinioneditorials.com/guestcontributors/rcurry_20070123.html

"The research behind the new discoveries by the cryptologist Dr. Rex
Curry (author of "Swastika Secrets") is referenced on Wikipedia and in
the vexillological group Flags Of The World (FOTW)."

http://rexcurry.net/wikipedia-the-free-encyclopedia.html


from_name: Brion Vibber

subject:
[Wikitech-l] Session cookie theft. Was: identity management
 (was: MD5 Password Encryption)

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregory Maxwell wrote:
> On this subject...  Wrapping the login site via SSL sounds like a
> dandy idea, and it sidesteps the whole mess of cert issues if with SUL
> we were to use a single login portal domain.
>
> However, then we've just pushed the problem back to session cookie
> theft.  Sure, it would still be an improvement since a passive
> attacker (at say Wikimania...) couldn't sit back and gather passwords,
> but better still might be possible.
>
> What the current industry best-practices with respect to binding
> session data to a client's IP? Do web browsers switch IPs too often
> for this to be acceptable (AOL?)?

My impression is that the most likely actual scenario for network
sniffing is an open wireless network behind a NAT -- so everyone will
have the same IP on the outside anyway.

Binding to IP probably protects more against cookies grabbed via XSS
(but then you can probably do your nasty things in JS).

AOL is a problem, with the switching of the IPs...

> At some point it might make sense to talk about all logged in user
> sessions being SSLed... the overwhelming majority of the computational
> load of SSL is the RSA stuff for signatures which would need to happen
> once per login if we went the SUL login page behind SSL route.. After
> that it's just symmetric crypto which isn't astoundingly expensive.
>
> Were we to move logged in users into SSL all sorts of threats just go
> away.

That gives me warm fuzzy feelings, if we can in fact swing it cleanly. :)

> Of course there is the little matter of plain squid not
> supporting SSL offloading like some of the commercial reverse proxy /
> acceleration solutions which would have to be resolved...

Details, but details to think about.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtkxywRnhpk1wk44RAtyRAJ94QdUMcr728GGOsVVgWJ7dQys5lgCgwLvs
EK7q4F5XLq5MScLm8wkRUI8=
=94ZI
-----END PGP SIGNATURE-----


subject: [Wikitech-l] MD5 Password Encryption

body:
Rob Church schreef:
> On 23/01/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
>
>> I would say first finish the Single User Login. It makes little sense to
>> consider it before this implementation as it is part of the login process.
>>
>
> *shrug*
>
> All I did was ask what kind of changes we would need to plan for. You
> know, if we require a few hundred new servers, we might as well whinge
> about that at the next budget allocation now, so we can plan ahead.
>
> I don't see you rushing to help with single-user login. Nor do I see
> any of those people who're whinging about it taking ages, and how they
> could do better, coming up with any better implementations.
>
> This next bit isn't aimed at you Gerard...CAN PEOPLE PLEASE LAY OFF ON
> SINGLE USER LOGIN? It's driving us all mad everytime someone asks
> "when and how", and if I were Brion, I'd be getting absolutely bloody
> *sick* of it. Furthermore, "SUL" is *not* some magical sword which
> will fix all our problems in one fell swoop, so please remember that.
>
>
> Rob Church
Hoi,
Actually I will not lay off on Single User Login. The reason is quite
simple. Some things that are important to me will not happen until AFTER
Single User Login. It is all well and good that everyone comes up with
the most nifty things and all kinds of functionality that HAS to be
implemented because you are volunteers too. In the mean time some rather
basic stuff does not get done. If this drives you mad, fine. Fix the
issue - help Brion implement SUL !

The promised date for SUL was end of January 2005. It is now a year late.

Thanks,
    GerardM


subject:
[WikiEN-l] Nofollow back on URL links on en.wikipedia.org
 articles for now

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Gray wrote:
> On 20/01/07, Brion Vibber <brion at pobox.com> wrote:
>> Having been requested by Jimmy to do so, and having seen a fun rumor of
>> a "search engine optimization world championship" contest targeting
>> WP[1], I've gone ahead and switched rel="nofollow" back onto URLs in
>> en.wikipedia.org's article namespace.
>>
>> (Better heuristic and manual flagging tools for URLs would of course be
>> super; anyone interested in working on integrating such support into
>> MediaWiki should swing on by the tech channels and give a shout.)
>
> Quick question (since I haven't seen it addressed below) - is this
> temporary for the duration of the current optimisation contest, or
> indefinite?

Indefinite. I'd prefer to see actual improvements (whitelisting, fading,
flagging and approval system, etc) rather than just turn it off one day,
though.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtlQtwRnhpk1wk44RAiYMAJ9HTPO1X/BdXKQp1+wCPafqmvEXOQCbBmeG
uCCmGzR9Pq8CnDP6Gh9PVOQ=
=jSu6
-----END PGP SIGNATURE-----


from_name: Mathias Schindler

body:
>
> I think we should protect it.

I think we should help Rick to fix the article. Since when are we
opposed to people who try to improve articles?

Mathias