from_name: Roger Luethi

subject: [WikiEN-l] Types of categories

body:
On Tue, 06 Jun 2006 17:36:07 -0400, Anthony DiPierro wrote:
> I'd say then that either the German [[Kategorie:Sicherheit]] should be
> disambiguated into two different categories, or that
> [[Kategorie:Sicherheit]] shouldn't be linked to [[Category:Security]],
> because they don't define the same set.  Maybe an English
> [[Category:Security and Safety]] could be made, with "Security" and
> "Safety" as subcats - then [[Kategorie:Sicherheit]] could link to
> [[Category:Security and Safety]].

These are all possible solutions. However, Sicherheit is not exactly
security+safety. It's just much closer than to security alone. I picked
that example because it's rather extreme. Here's another one: there are
two German words for technology: Technik and Technologie (each has
a separate category in the German WP).

More importantly, though, many translated words mean almost the same, but
not exactly, and some articles will be the corner cases that will make the
category in one language but not in the other.

You would need a mechanism to exclude categories that won't translate well
enough even though an interwiki link exists between them. Opt-in or
opt-out, I don't know.

> But maybe this is a common enough thing that that's not going to be
> reasonable.  At some point someone should look at how the en
> categories differ from the de ones.  I figure there will be 5 major
> points of difference:
>
> 1) Things being categorized at different levels ([[Category:Polish
> women]] vs. [[Kategorie:Frau]].
> 2) Interwiki links between articles on different things.
> 3) Interwiki links between categories defining different sets.
> 4) Articles categorized where they shouldn't be.
> 5) Articles missing from categories where they should be.
>
> 1) is the reason why I call this a "longer-term solution".  2 and/or 3
> are what you describe above.  4 and 5 are the reason why it would be
> useful to coordinate things.
>
> It'd be interesting to get a decent size sample and sort the
> differences into those 5 categories.  If 2 and/or 3 were significant,
> then I suppose this idea fails, at least initially.  If 1 is

2) is significant if only because the German WP tends to merge subjects
into one article, so you have several English articles pointing to the
same German one.
3) Extremes are rare, but subtle differences are pretty much inevitable.
6) Different understanding of what categories should exist.

Roger


list: wikitech-l

source: pipermail-mbox

from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-06-07

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


list: wikien-l

from_name: Steve Bennett

subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
On 6/6/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> Surely that is the standard which should already be applied, per
> [[WP:V]], [[WP:RS]], [[WP:NPOV]] (undue weight) and [[WP:NOR]]? That's
> how I would read it, anyway.

I think none of those help if the criterion is literally "has ever
been called a cult by anyone" which is one, almost reasonable
interpretation, of "referred to as a cult". It's just the "referred
to" bit - if it was "cults" then I would agree with you.

Steve


subject: [WikiEN-l] Category translation

body:
On 6/6/06, jkelly at fas.harvard.edu <jkelly at fas.harvard.edu> wrote:
>  Hi,
>
>  On a related note, some kind of translation system for Categories is
> desperately needed for Commons, as the Category system in place now is only of
> benefit to English speakers.  It is a source of some frustration.

Is it? I'm pretty sure I've used categories in either German or French
before? Do redirects work for categories? Would that suffice?

Steve


from_name: Karl A. Krueger

subject:
[WikiEN-l] Psychology of problem Wikipedians: excessive "need
	for cognition"

body:
On Mon, Jun 05, 2006 at 11:19:47AM +0100, David Gerard wrote:
> Karl A. Krueger wrote:
> >When people attempt to explain other people's actions in terms of
> >psychological disorders or oddities, it seems to me that it often
> >reflects a lack of respect or human sympathy for the people thus
> >diagnosed.
>
> [snip long post not addressing the point at all]
>
> Gosh, I guess that means we can't call obvious problem cases obvious
> problem cases, and certainly can't try to address the actual problem,
> because it might be rude to do so. Thanks for clearing that up.

What a mind-numbingly bad misreading of my post.


subject: [WikiEN-l] Types of categories

body:
On 6/6/06, Roger Luethi <collector at hellgate.ch> wrote:
> With the current software, that could be implemented as:
>
> [[Paris]]
>        [[Category:is a city]]
>                [[Category:is a (is there a name for "city or town or
>                        village or some other place"?)]]
>        [[Category:in France]] (or [[Category:located in France]])
>                [[Category:in Europe]]
>
> Okay.

Why do I get the feeling the current structure probably already looks
a lot like that, but with different names?

> What i see is (I added more information for illustration):
>
> [[Britney Spears]]
>        [[Category:is a singer]]
>                [[Category:is an entertainer]]
>                        [[Category:is a person]]
>        [[Category:is a child actor]]
>                [[Category:is an entertainer]]
>                        [[Category:is a person]]
>        [[Category:is alive]]
>        [[Category:is female]]
>        [[Category:born 1981]]
>        [[Category:born in McComb, Mississippi]] (that kind of category
>                        would be hard to maintain manually)

Good, good - why is that cat hard to maintain manually?

> Here are some other fun (existing!) categories from said article:
>
> Worst Actress Razzie: "won a Worst Actress Razzi"
> Soubrettes: "is a soubrette", I guess!?
> American child actors: ...? "is a child actor" or "was a child actor?"

Yes. The fact taht these are hard to express clearly is very telling.

> Hollywood Walk of Fame: Ugh.
> High school dropouts: Ahm?

Dropped out of high school?

> [[Pont du Gard]]
>        [[Category:is an aqueduct]]
>                [[Category:is a bridge]]
>                        [[Category:is a construction]]
>        [[Category:in France]]
>        [[Category:built by Romans]] (?)

Yep, why not. (Built by Ancient Romans if you prefer...)

> > Basically what I'm proposing now is keeping taxonomies quite strict,
> > and allowing greater flexibility in attributes. So we'll always know
> > whether an item is a soccer team or a city, but we may lose
> > information on the finer details if the attributes aren't managed
>
> Examples?

Erm, I mean, people will probably end up being "casual" with
attributes...but if we could make the taxonomic classificatins a bit
more firm...not sure what I'm getting at (it's late).

> > I don't quite understnd your second example. "Rattus rattus" "is a"
> > "Rattus" is ok isn't it?
>
> It is. But "species" is not a genus. Like city is not a country.

Yes, but I'm not sure what you're point is - are you talking about
"species" the article? Of course it shouldn't belong to "genus" the
category...probably missing something.

> I see two major problems with the status quo:
> * multi-concept categories (American child actors) force us to maintain a
>  complex system of subcategories (but they paper over shortcoming in the
>  software). The German WP shows it doesn't have to be this way, but
>  it might be difficult to convince people on WP:en until Mediawiki can
>  create intersections

Yay, how hard can it be?

> * categories with unclear relations that are used for everything

Like [[Category:Lasers]]? ;)

> We can fix both problems without changes to the software (but it still
> comes at a cost). However, we are dangerously close to inventing a poor
> man's version of a semantic wiki.

Would a fully fledged semantic wiki ever work on Wikipedia scale?

> My impression is that the German WP is pretty close to that. But categories
> are also an important navigation aid, and that's where WP:de falls short.

Trust the Germans to be organised! Obviously the shortcoming is the
lack of intersections though. You know, what would be really awesome
would be seeing at the bottom of each article:

Categories: Bridges, in France, built by Romans
See other: Bridges in France (200 articles), Bridges built by Romans
(137 articles), Bridges in France built by Romans (15 articles).

Is that feasible?

> > > Where's {{Category:Polish chemists}} coming from? Defined on a separate
> >
> > Defined on a separate page by someone who thought it was a meaningful
> > and useful category, and worth spending 2 minutes making.
>
> Number of countries: > 200
> Occupations: hundreds
>
> Not every country has people in every occupation, but these are just two
> attributes. That's many times 2 minutes. We should not have to do this
> manually.

Ok, I think we got sidetracked. I was saying you could put the
relevant attributes directly on a page, and manually search for the
appropriate intersection. However, people could also create templates,
or links to predefined groupings of attributes, if they find them
interesting and relevant.

(Note that this would allow people to create "Jewish mass murderers"
categories easily :))

> _Or_ editors could simply add all the attributes and forget about the
> template. Attributes on [[de:Marie Curie]] (I'm not making this up):

Ok, you did understand, I was just unclear.

>
> woman chemist physicist polish (+ some more)
>
> I guess splitting woman into person and female seemed too awkward to the
> Germans. Wimps.

Heh, what do they do for young girls?

Steve


from_name: Brion Vibber

subject: [WikiEN-l] [Wikitech-l] Template HTML fixups coming this week

body:
Minh Nguyen wrote:
> What about high-use templates like [[Template:Multi-listen start]] and
> [[Template:Multi-video start]]? These templates open <ul> tags but don't
> close them (or vice-versa).

That would likely break too, yes.

> Would it be possible to transclude
> {{int:Open list}}, where [[MediaWiki:Open list]] has code similar to
> [[MediaWiki:Cite references prefix]]?

{{int:Foo}} should behave the same as {{MediaWiki:Foo}} so far as I know. If it
doesn't, that's probably a bug, so please let me know.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/c0f08ae3/attachment.pgp


subject: [Wikitech-l] Template HTML fixups coming this week

body:
Minh Nguyen wrote:
> What about high-use templates like [[Template:Multi-listen start]] and
> [[Template:Multi-video start]]? These templates open <ul> tags but don't
> close them (or vice-versa).

That would likely break too, yes.

> Would it be possible to transclude
> {{int:Open list}}, where [[MediaWiki:Open list]] has code similar to
> [[MediaWiki:Cite references prefix]]?

{{int:Foo}} should behave the same as {{MediaWiki:Foo}} so far as I know. If it
doesn't, that's probably a bug, so please let me know.

-- brion vibber (brion @ pobox.com)

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


body:
brion at pobox.com wrote:
> An automated run of parserTests.php showed the following failures:

Looks like somebody failed to run any tests before their last checkin:

PHP Fatal error:  Cannot instantiate abstract class BagOStuff in
/home/brion/src/wiki/phase3/maintenance/parserTests.inc on line 362

-- brion vibber (brion @ pobox.com)

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


subject: [WikiEN-l] Category translation

body:
On 6/7/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> > They're not always 1:1. One topic might be given a whole article on
> > one Wikipedia and only a paragraph on another. I'm not aware of any
> > convention for handling that atm actually.
> >
> Looking a bit into this, I agree it'll be a hurdle.  How big of a
> hurdle I still don't know.

Just fwiw, one simple basic example I have dealt with.

[[fr:Carnac]] discusses both the township of Carnac and the famous
Carnac stones which are found within the town.

I split [[en:Carnac]] into that article which only discusses the town,
and [[en:Carnac stones]] which discusses the megalithic site.

[[en:carnac]] and [[en:Carnac stones]] both interwikilink to
[[fr:Carnac]]. However, nothing (anywhere) interwikilinks back to
[[en:Carnac stones]]. There is no clean mechanism for doing so. The
French article *could* link twice - once to each article - but then
you'd just have two interwiki links labelled "English" and only the
URL would tell you which was which.

In other words, many -> one correspondances are ok. One -> many are
unhandled atm. Occasionally you'll see "French Wikipedia article"
given as a "further reading" link but I don't think the MoS sanctions
that.

Steve


subject: [Wikitech-l] Lost session data

body:
Steve Bennett wrote:
> I'm getting this both at home and at work, almost every time I try to
> edit a page:
>
> Sorry! We could not process your edit due to a loss of session data.
> Please try again. If it still doesn't work, try logging out and
> logging back in.
>
> Normally, when I've had this message it's been after attempting to
> save a page after extended inactivity - you click Save again and the
> problem goes away. However, it's currently occurring as soon as I
> click "Edit", but doesn't cause any problems when clicking Save.

1) Where are you seeing this? (Which wiki, at what URL? Your own wiki or one of
ours?)

2) What version of MediaWiki is this wiki running?

3) What is the configuration of this wiki? Does it have raw HTML mode enabled?

4) What is your user configuration? Have you enabled the 'preview on edit'
option perhaps?

-- brion vibber (brion @ pobox.com)

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


from_name: Raphael Wegmann

subject: [WikiEN-l] [[WP:OURS]] - A proposal for admin-user relations

body:
Steve Bennett wrote:
> On 6/6/06, Stephen Bain <stephen.bain at gmail.com> wrote:
>>> Did user A complain about the lack of history?
>> There were 31 edits to the page, not all made by user A. I don't
>> really care why B deleted it, my issue was with C copy and pasting it,
>> which should never be done.
>
> Ok, I'm really not getting this at all. Lots of people contribute to
> proposal, presumably because they wanted that proposal to exist.
> Someone deletes it. Someone else recreates it but fails to properly
> acknowledge the original creators. You re-delete it, citing the
> interests of the unacknowledged? Surely common sense dictates that the
> original creators would prefer the proposal be recreated - acknowledge
> or not - than that it be deleted? It's a real stretch to assume that
> they would rather it be deleted than that it exist without their name
> on it. Also bear in mind that the recreator didn't have access to the
> history...but you did, and could have copied it to the new article's
> talk page, if it bothered you.
>
> Maybe there were good reasons for deleting it, but that's a pretty
> strange justification for re-deleting something.
>

I have even sent an email to User:Thebainer and asked him to restore
the history for me, but unfortunately I've got no reply.

--
Raphael


subject: [WikiEN-l] Template HTML fixups coming this week

body:
Tim Starling wrote:
> Infoboxes are a very important application of templates. There needs to
> be some way conditionally add table rows based on whether or not a given
> template parameter is defined. When people complained about the argument
> separators in {{#if:}} clashing with table syntax, I told them to use
> HTML table tags instead. That seemed like a much better, more stable
> solution than {{!}}. If that's not going to work anymore, what exactly
> are people meant to do?
>
> There are thousands of affected articles, and if there is no solution
> for this, then I don't think it is acceptable to put this change live.
>
> Why is the template required to close its own tags? It would make things
> a lot easier if this was not required.

That's how MediaWiki has worked for a long time; it was just broken with Tidy
mode enabled, thus guaranteeing that any Wikipedia page using such a template
would be broken when copied to another wiki.

Would you prefer to change the behavior? Note that this will require some
restructuring to the parser to both be more correct and and not break things,
and will leave us with inconsistent, unparseable code in the future. (That is,
it'll be impossible to tell what the code after a template inclusion will parse
as unless the template is available.)

But if we're really, really sure, we can put some time into working on that and
accept that our syntax will never be predictable. (This has consequences for
future wysiwyg or markup-sensitive assisted editing plugins.)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/347da3af/attachment.pgp


subject: [Wikitech-l] [WikiEN-l] Template HTML fixups coming this week

body:
Tim Starling wrote:
> Infoboxes are a very important application of templates. There needs to
> be some way conditionally add table rows based on whether or not a given
> template parameter is defined. When people complained about the argument
> separators in {{#if:}} clashing with table syntax, I told them to use
> HTML table tags instead. That seemed like a much better, more stable
> solution than {{!}}. If that's not going to work anymore, what exactly
> are people meant to do?
>
> There are thousands of affected articles, and if there is no solution
> for this, then I don't think it is acceptable to put this change live.
>
> Why is the template required to close its own tags? It would make things
> a lot easier if this was not required.

That's how MediaWiki has worked for a long time; it was just broken with Tidy
mode enabled, thus guaranteeing that any Wikipedia page using such a template
would be broken when copied to another wiki.

Would you prefer to change the behavior? Note that this will require some
restructuring to the parser to both be more correct and and not break things,
and will leave us with inconsistent, unparseable code in the future. (That is,
it'll be impossible to tell what the code after a template inclusion will parse
as unless the template is available.)

But if we're really, really sure, we can put some time into working on that and
accept that our syntax will never be predictable. (This has consequences for
future wysiwyg or markup-sensitive assisted editing plugins.)

-- brion vibber (brion @ pobox.com)

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


from_name: Minh Nguyen

body:
Brion Vibber wrote:
> Minh Nguyen wrote:
>> What about high-use templates like [[Template:Multi-listen start]] and
>> [[Template:Multi-video start]]? These templates open <ul> tags but don't
>> close them (or vice-versa).
>
> That would likely break too, yes.
>
>> Would it be possible to transclude
>> {{int:Open list}}, where [[MediaWiki:Open list]] has code similar to
>> [[MediaWiki:Cite references prefix]]?
>
> {{int:Foo}} should behave the same as {{MediaWiki:Foo}} so far as I know. If it
> doesn't, that's probably a bug, so please let me know.
>
> -- brion vibber (brion @ pobox.com)

Sorry, I should've been clearer: are interface messages also subject to
the HTML tidying when transcluded, even if they aren't tidied in the
interface?

--
Minh Nguyen <mxn at zoomtown.com>
AIM: trycom2000; Jabber: mxn at myjabber.net; Blog: http://mxn.f2o.org/


subject: [Wikitech-l] Lost session data

body:
Steve Bennett wrote:
> On 6/7/06, Brion Vibber <brion at pobox.com> wrote:
>> 1) Where are you seeing this? (Which wiki, at what URL? Your own wiki or one of
>> ours?)
>
> Silly me. English Wikipedia.

[snip]

> I do indeed have "preview on first edit",

Great, I've got this narrowed down and will have it fixed shortly. Thanks for
the report!

-- brion vibber (brion @ pobox.com)

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


list: wikipedia-l

subject: [Wikipedia-l] Monobook

body:
Berto wrote:
> Hi!
>
> Thanks, it worked. Only I can't seem to be able to edit common.css from the
> "system messages", so I temporarily put the changes into monobook. It works,
> but it would be better to have these classes where all the other editions
> have them. How do I transfer them to common.css?
>
> B?rto

You can edit common.css by going to
<http://pms.wikipedia.org/wiki/MediaWiki:Common.css>.

--
Minh Nguyen <mxn at zoomtown.com>
AIM: trycom2000; Jabber: mxn at myjabber.net; Blog: http://mxn.f2o.org/


body:
Minh Nguyen wrote:
> Sorry, I should've been clearer: are interface messages also subject to
> the HTML tidying when transcluded, even if they aren't tidied in the
> interface?

When transcluded into a wiki page? Yes, unless there's a bug.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/ac2670dc/attachment.pgp


subject: [WikiEN-l] To: Jimmy Wales - Admin-driven death of Wikipedia

body:
sean at epoptic.com wrote:
> On 6 Jun 2006 at 15:38, Raphael Wegmann <raphael at psi.co.at> wrote:
>
>> The discussion is not about thoughtcrimes. It is about hate *speech*
>> which is a different matter. The U.S. is actually violating an UN
>> resoltion by not passing hate speech laws.
>
> If we can't say "hate," how can we say "we fucking hate the UN"?
>

Daniel R. Tobias wrote:
 >
 > Fuck the UN.
 >
 > (Is that hate speech?)
 >

Maybe you should read the URL instead of cutting it out:

http://www.ohchr.org/english/law/ccpr.htm#art20

--
Raphael


from_name: Tim Starling

subject: [Wikitech-l] ch.wikimedia.org - close please

body:
Michael Bimmler wrote:
> we moved everything from ch.wikimedia.org to our own wikis/websites.
> Could somebody close/lock/delete/make inaccessible/whatever the
> ch.wikimedia.org wiki?
> Thanks

Wouldn't you rather make it a redirect to some external website?

-- Tim Starling


subject: [Wikipedia-l] Wikia's new CEO

body:
Andrew Lih wrote:
> FYI,
>
> Wikia taps eBay exec as CEO
> San Francisco Business Times - 2:41 PM PDT Monday
>
> Wikia Inc., a for-profit company founded 18 months ago by Wikipedia
> founder Jimmy Wales, hired Gil Penchina as its CEO on Monday.
>
> Penchina was vice president and general manager at eBay (NASDAQ: EBAY).

Penchina was *a* vice president of eBay. eBay is one of these companies with
lots of division presidents, senior vice presidents and vice presidents.

http://pages.ebay.com/aboutebay/thecompany/executiveteam.html

-- Tim Starling


body:
Brion Vibber wrote:
> Tim Starling wrote:
>> There are thousands of affected articles, and if there is no solution
>> for this, then I don't think it is acceptable to put this change live.
>>
>> Why is the template required to close its own tags? It would make things
>> a lot easier if this was not required.
>
> That's how MediaWiki has worked for a long time; it was just broken with Tidy
> mode enabled, thus guaranteeing that any Wikipedia page using such a template
> would be broken when copied to another wiki.
>
> Would you prefer to change the behavior? Note that this will require some
> restructuring to the parser to both be more correct and and not break things,
> and will leave us with inconsistent, unparseable code in the future. (That is,
> it'll be impossible to tell what the code after a template inclusion will parse
> as unless the template is available.)
>
> But if we're really, really sure, we can put some time into working on that and
> accept that our syntax will never be predictable. (This has consequences for
> future wysiwyg or markup-sensitive assisted editing plugins.)

What I can do is for now separate the HTML whitelisting and HTML nesting
correction into two separate parts, as it's (IMO incorrectly) done right now in
Tidy mode. This will let all 1.7 wikis display these templates the same as
Wikipedia currently does, by essentially copying the current (broken) Tidy
behavior to the default install.

Then we can fight about this again in a few months. :)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/b94c83d2/attachment.pgp


subject: [Wikipedia-l] [WikiEN-l] Template HTML fixups coming this week

body:
Brion Vibber wrote:
> Tim Starling wrote:
>> There are thousands of affected articles, and if there is no solution
>> for this, then I don't think it is acceptable to put this change live.
>>
>> Why is the template required to close its own tags? It would make things
>> a lot easier if this was not required.
>
> That's how MediaWiki has worked for a long time; it was just broken with Tidy
> mode enabled, thus guaranteeing that any Wikipedia page using such a template
> would be broken when copied to another wiki.
>
> Would you prefer to change the behavior? Note that this will require some
> restructuring to the parser to both be more correct and and not break things,
> and will leave us with inconsistent, unparseable code in the future. (That is,
> it'll be impossible to tell what the code after a template inclusion will parse
> as unless the template is available.)
>
> But if we're really, really sure, we can put some time into working on that and
> accept that our syntax will never be predictable. (This has consequences for
> future wysiwyg or markup-sensitive assisted editing plugins.)

What I can do is for now separate the HTML whitelisting and HTML nesting
correction into two separate parts, as it's (IMO incorrectly) done right now in
Tidy mode. This will let all 1.7 wikis display these templates the same as
Wikipedia currently does, by essentially copying the current (broken) Tidy
behavior to the default install.

Then we can fight about this again in a few months. :)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20060607/b94c83d2/attachment.pgp


body:
Brion Vibber wrote:
> Tim Starling wrote:
>> There are thousands of affected articles, and if there is no solution
>> for this, then I don't think it is acceptable to put this change live.
>>
>> Why is the template required to close its own tags? It would make things
>> a lot easier if this was not required.
>
> That's how MediaWiki has worked for a long time; it was just broken with Tidy
> mode enabled, thus guaranteeing that any Wikipedia page using such a template
> would be broken when copied to another wiki.
>
> Would you prefer to change the behavior? Note that this will require some
> restructuring to the parser to both be more correct and and not break things,
> and will leave us with inconsistent, unparseable code in the future. (That is,
> it'll be impossible to tell what the code after a template inclusion will parse
> as unless the template is available.)
>
> But if we're really, really sure, we can put some time into working on that and
> accept that our syntax will never be predictable. (This has consequences for
> future wysiwyg or markup-sensitive assisted editing plugins.)

What I can do is for now separate the HTML whitelisting and HTML nesting
correction into two separate parts, as it's (IMO incorrectly) done right now in
Tidy mode. This will let all 1.7 wikis display these templates the same as
Wikipedia currently does, by essentially copying the current (broken) Tidy
behavior to the default install.

Then we can fight about this again in a few months. :)

-- brion vibber (brion @ pobox.com)

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


from_name: Phil Boswell

subject: [WikiEN-l] Category translation

body:
Elisabeth Bauer wrote:
>
> jkelly at fas.harvard.edu schrieb:
>>   On a related note, some kind of translation system for Categories is
>> desperately needed for Commons, as the Category system in place now is
>> only of
>> benefit to English speakers.  It is a source of some frustration.
> A patch is already submitted in bugzilla:
> http://bugzilla.wikimedia.org/show_bug.cgi?id=5638
>
And the system is available for test here (this is a demo link which will
not do you much good if you're already using "de"):
http://test.leuksman.com/view/Category:Geometry?uselang=de

HTH HAND
--
Phil
--
View this message in context: http://www.nabble.com/Category-translation-t1743148.html#a4750583
Sent from the English Wikipedia forum at Nabble.com.


from_name: Anthony DiPierro

subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
On 6/6/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/6/06, Peter Jacobi <peter_jacobi at gmx.net> wrote:
> > So, if you put together all these atoms of sourced statements,
> > is the entitity you created still in line with WP:NOR, WP:V
> > and friends? IMHO its (a) just this compiling step which is
> > problematic and (b), in this special case of [[List of groups
> > referred to as cults]], the one-drop-rule employed: Find one
> > author which says "is a cult" and the it's  on the list.
>
> The problem is basically that "referred to as cult" sounds like
> "everyone thinks it's a cult", but the actual criterion for inclusion
> is apparently "some nut once said it was". Solution: Up the stakes for
> inclusion to require labelling by some relatively authoritative
> authorities.
>

I'd say if the reference as a cult is NPOV and V (and NOR) enough to
be in the article about the group, then the group makes it into the
list.  Otherwise, it doesn't.

The only bad thing I can see about this is it automatically excludes
all groups which don't yet have an article.

Anthony


subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
On 6/7/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> Sure.  An article on "things which have been referred to as foo" has
> no place on Wikipedia.  For any thing which may potentially be
> described as foo, there will be at least one person somewhere who will
> have so described it.  So this should be the list of groups considered
> cults, with selection criteria set appropriately, or it should be
> deleted in favour of a category, so that every entry is rigorously
> tested by individual article authors (which will end up in the usual
> "pseudoscience" arguments, but that's a matter for consensus building
> on the articles).
>
Making it a category would be an absolutely horrible solution, as it
would remove any possibility of having any footnotes or annotations.


subject: [Wikitech-l] How often should exceptions be used?

body:
On 6/7/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> which is better? Should the backend dictate the error format by
> specifying an exception class with a fixed format? Of course, a caller
> wishing to override the formatting could catch the exception, but is
> that better than the old method of using a success/failure return value?
>
> Should error handling be completely exception-dominated? Is there any
> role for success/failure return values in a language with exception support?

Assuming this is a general question not specifically related to
MediaWiki, the general answer is that exceptions should only be used
for exceptional circumstances, and likely failures are better off
handled with return codes. It's better to use exceptions for weird
things like running out of memory, suddenly being unable to access the
disk, or an assertion failing, rather than something as banal as a bad
filename being supplied, for instance.

Also, it's not usually good practice to allow uncaught exceptions, as
in your "pretty error" case, is it?

HTH
Steve


from_name: Mark Gallagher

body:
Conrad,

> * Kelly Martin wrote:
>
>>On 6/5/06, Mark Gallagher <m.g.gallagher at student.canberra.edu.au> wrote:
>>
>>>In any case, the general thrust of Selina's comment was spot-on, so
>>>let's try not to jump on her for one clause.
>>
>>No, indeed, let us give the hypocrite a fair trial.  Then we can hang her.
>
> What was that I was saying about the need for admins to maintain civility
> even with 'bad' users? Oh well... probably wasn't important anyway, right?

[Note: I'm talking in generalities here, and mean no slight against
  either Selina or Kelly]

While I agree with the general idea of what you've been saying since
your RfA passed, I think you could do with being a little less smug
while you're saying it.

You haven't dealt with the same sorts of issues that other admins have.
  Now, it's not necessary to fight trolls, regularly clean up heavy
vandalism, mediate bloody disputes, etc., to be an admin, so that's no
slight on you.  You seem to be more focused on editing the
encyclopaedia, and that's an unvarnished Good Thing.  However, it also
means that you have no idea what the rest of us actually *do*.  It's
incredibly easy to stand, smugly, on the sidelines, and criticise your
fellows --- and it's very poor form to do it from a platform of "I'm an
admin, I know about these things," (as I've seen on ANI) when you know
nothing of the sort.

I think admins have a responsibility to be civil and polite *on
Wikipedia* at all times; I think the better admins out there go one
better and are actually *pleasant* to deal with.  This is what I aim
for; I often fall short of that goal, but it's there nevertheless.  It
can be very difficult to maintain one's temper when dealing with
problematic users.  That's a Bad Thing, true, but it would be nice if
those criticising had some understanding of the difficulty.

I, too, cringe when I see other admins behaving in a manner less than
ideal, particularly on Wikipedia, and have been known to take the issue
up with them on many occasions.  Often a polite, private message will
work wonders.  Standing by and pointing the finger and saying "you see
what bastards these people on Wikipedia are?" is *not* going to improve
anyone's behaviour, administrator or not.  It is an oft-repeated tragedy
that people who are absolutely correct can be ignored, simply because
the way that they make their points gets people off-side immediately.
Please consider this; if the point you're making is important to you, it
will be worth your while to change your mode of delivery.

Cheers,

--
Mark Gallagher
"What?  I can't hear you, I've got a banana on my head!"
- Danger Mouse


subject: [Wikitech-l] Lost session data

body:
I'm getting this both at home and at work, almost every time I try to
edit a page:

Sorry! We could not process your edit due to a loss of session data.
Please try again. If it still doesn't work, try logging out and
logging back in.

Normally, when I've had this message it's been after attempting to
save a page after extended inactivity - you click Save again and the
problem goes away. However, it's currently occurring as soon as I
click "Edit", but doesn't cause any problems when clicking Save.

Just wondering if it's the sort of thing that everyone is
experiencing, but no one thought of reporting? :)

Steve


references:
<e659l2$pds$1@sea.gmane.org>
	<f1c3529e0606062319g782ece48l9bf3cb961dcdfc38@mail.gmail.com>
	<e65t64$f4f$1@sea.gmane.org>

body:
On 6/7/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> > Assuming this is a general question not specifically related to
> > MediaWiki, the general answer is that exceptions should only be used
> > for exceptional circumstances, and likely failures are better off
> > handled with return codes. It's better to use exceptions for weird
> > things like running out of memory, suddenly being unable to access the
> > disk, or an assertion failing, rather than something as banal as a bad
> > filename being supplied, for instance.
>
> Do you have some sort of justification for this view?

Just what I've read.

Steve


subject: [Wikitech-l] Lost session data

body:
On 6/7/06, Brion Vibber <brion at pobox.com> wrote:
> 1) Where are you seeing this? (Which wiki, at what URL? Your own wiki or one of
> ours?)

Silly me. English Wikipedia. Quickly testing, I don't seem to be
getting this at French wikipedia on at Commons.

> 2) What version of MediaWiki is this wiki running?

See above.

> 3) What is the configuration of this wiki? Does it have raw HTML mode enabled?
>
> 4) What is your user configuration? Have you enabled the 'preview on edit'
> option perhaps?

The only user config setting I've modified in the last week has been
my signature. I do indeed have "preview on first edit", but I've been
using that for months. Just played with preferences and the problem
appears to occur only when using "preview on first edit" mode.

It's not a huge problem (it doesn't stop the page saving correctly
first try, for instance), but it's a bit odd?

User name, fwiw: stevage

Steve


subject: [WikiEN-l] Types of categories

body:
Incidentally, I realised one great thing that could be done with a
hierarchical taxonomy: The very top branch can be "Fictional" vs
"Real". Easy way to prune out huge sections of fancruft :)

Steve


from_name: Ray Saintonge

subject: [WikiEN-l] Types of categories

body:
Anthony DiPierro wrote:

>On 6/3/06, Roger Luethi <collector at hellgate.ch> wrote:
>
>
>>On Sat, 03 Jun 2006 19:54:27 +0200, Steve Bennett wrote:
>>
>>
>>>I'm probably not the only one who envisages all the wonderful things
>>>that could be done with this massive collection of information that is
>>>Wikipedia, *if only* we could do something clever with the categories.
>>>And then you realise that you can't really do anything clever because
>>>"category" has all sorts of different meanings to different people.
>>>
>>>
>>Agreed. Still: can you give some specific examples of wonderful things that
>>could be done but are not possible now? That would tell us what problem you
>>are trying to solve.
>>
>>
>I've personally run into this when trying to automatically create, for
>example, a list of all Wikipedia articles on people.  You can't just
>start at [[category:people]] and work your way down, because you wind
>up going to [[Category:Women]] (fine, all women are people) then
>[[Category:Feminine hygene]] (bad).
>
A high level category like people does not need to have direct
elements.  To be simplistic about it, it would do fine with only two
sub-categories, men and women.  An element of a sub-category is an
element of the superset category.

>>Categories based on such intersections of attributes are conceptually bad.
>>Look at the categories for an article like [[Marie Curie]]: She's French
>>three times, female four times, Polish four times (not counting "Natives of
>>Warsaw"), etc. Why not create [[Category:Polish women who were born in
>>1867 and died in 1934 and won a Nobel Prize in Chemistry and in Physics]]?
>>
>>
>Because there would only be one person in that category.
>
Such a category would be theoretically acceptable but totally
impractical. There is an element of art to the design of category
hierarchies.  A category that's too narrow (like your example) is
unfindable; you simply never know which ones exist.  At the other
extreme, if the category is too broad it becomes more difficult to find
things within it.  In Wiktionary people have established
[[Category:English nouns]] which now has numerous elements, but what
user would ever look there to find something?  The purpose of categories
is to help the passive user to find things.  It requires some idea of
which Googling strategies work and which don't, and how to modify a
strategy which initially doesn't work.  Just think of what works when
you are searching for something.

In my mind a category should not have more than 200 direct elements,
this being the number of items that will appear on a single page by
default when we ask for a category to be listed.  Anything longer should
be subdivided.  Even so, a person should have the option to have an
"include sub-categories" to a determinable level when listing the
contents of a higher level category.

>>If we don't have a term for (or an article about) it, there probably
>>shouldn't be a category for it, either (I'm sure a determined mind could
>>come up with an exception).
>>
>>
>If the category system could effectively build these intersection
>categories on the fly, I'd agree.  But the category system can't
>currently do that.  (And it's been around a reasonably long time, with
>that as an obvious flaw, and no one has fixed it.)
>
I suggested something of the sort before categories were implemented,
but more from the searching end.  The real problem is with the search
function, which is remarkably unsophisticated for a project the size of
Wikipedia.

>>>Attributes: The category exists to denote some very specific small
>>>detail of a subject, such that it would be conceivable to have dozens
>>>or more such categories on an article. Examples: 1943 deaths, Living
>>>persons, Winners of Nobel Peace Prize, etc. These tend to hierarchies
>>>that start strict then end up fuzzy. Eg, 1943 deaths is only in 1943
>>>and "1940s deaths", and these have parent categories of
>>>"1940s","Years" and so forth, eventually ending up in "History",
>>>whereupon things become chaos.
>>>
>>>
>>There is no way to make hierarchies not suck, especially if you have to
>>maintain them manually (as we do now). Don't try to impose hierarchies
>>unless they emerge quite naturally from the subject.
>>
>>
>I made a proposal.  All subcategories of attributes must be a subset
>of the parent attribute.  Seems like a perfectly reasonable way to
>make hierarchies not suck.
>
It's an idea that I have tried to implement for some time at
Wiktionary.  The difficulty with such hierarchies is that they require
people to think logically, and to be able to trace a path back to a
single top level hierarchy.

Ec


subject: [WikiEN-l] Types of categories

body:
Matt Brown wrote:

>On 6/3/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
>
>>What you're saying makes sense, but does not currently have consensus.
>>Implementing it therefore sounds like a bad idea bound to cause upset.
>>
>>
>I suspect that simply no real discussion of this has taken place yet.
>
There's not much to discuss.  Either you like recursive inclusions or
you don't.  I tend to favour them, but am not too dilligent about
remembering to add them.

Ec


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
On Wed, 7 Jun 2006 00:23:36 +0200, you wrote:

>On 6/6/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>> Surely that is the standard which should already be applied, per
>> [[WP:V]], [[WP:RS]], [[WP:NPOV]] (undue weight) and [[WP:NOR]]? That's
>> how I would read it, anyway.

>I think none of those help if the criterion is literally "has ever
>been called a cult by anyone" which is one, almost reasonable
>interpretation, of "referred to as a cult". It's just the "referred
>to" bit - if it was "cults" then I would agree with you.

Sure.  An article on "things which have been referred to as foo" has
no place on Wikipedia.  For any thing which may potentially be
described as foo, there will be at least one person somewhere who will
have so described it.  So this should be the list of groups considered
cults, with selection criteria set appropriately, or it should be
deleted in favour of a category, so that every entry is rigorously
tested by individual article authors (which will end up in the usual
"pseudoscience" arguments, but that's a matter for consensus building
on the articles).

I'd say that lists of arbitrary constructs meeting arbitrary and broad
criteria with no rigorous definition are indiscriminate.  But I am one
of those who dislikes lists-for-the-sake-of-lists.

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


body:
I'm currently implementing PHP 5 exceptions in MediaWiki and I've come
across a design question. How often should exceptions be used?

I've set up an exception handler which is quite capable of formatting
and displaying pretty error messages for the user. The HTML to be
displayed is defined by the exception class. But the question is, how
often should I use them? Say if I have the choice between:

function deleteUserInterface( $file ) {
     if ( deleteFile( $file ) ) {
         displaySuccess();
     } else {
         displayError();
     }
}

function deleteFile( $file ) {
     return (bool) unlink( $file );
}

function displayError() {
     // pretty error
}

and...

function deleteUserInterface( $file ) {
     deleteFile( $file );
     displaySuccess();
}

function deleteFile( $file ) {
     if ( !unlink( $file ) ) {
         throw new DeleteError();
     }
}

class DeleteError extends MWException{
     function getHTML() {
         // pretty error
     }
}

which is better? Should the backend dictate the error format by
specifying an exception class with a fixed format? Of course, a caller
wishing to override the formatting could catch the exception, but is
that better than the old method of using a success/failure return value?

Should error handling be completely exception-dominated? Is there any
role for success/failure return values in a language with exception support?

-- Tim Starling


list: foundation-l

from_name: Lord Voldemort

subject: [Foundation-l] Fundraising ideas - using what we've already got

body:
On 6/7/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> I'm not taking it so much from the angle of "let's sell these" as
> "let's encourage them to donate a tiny bit more with a feelgood
> 'freebie' and simultaneously display the breadth and quality of our
> coverage which they probably didn't realise existed".

Plus the way these are delivered may make a difference.  Yes, our
stuff is free, and they could go do it themselves, but if they want to
kick in a few extra pounds, dollars, etc., we could send them what
they wanted and save them the trouble of having to find it all.  Like
if I was going to donate 25 pounds, I wouldn't mind kicking in an
extra 5 if someone wanted to send me say, 12 good landscape pictures
(or baseball, or trains, or whatever) so I could make myself a
calandar.  The time saved not having to find quality images is
probably worth 5 pounds.  Maybe it's just me.
--LV


list: wikimedia-l


subject: [WikiEN-l] Types of categories

body:
Anthony DiPierro wrote:

>On 6/4/06, Roger Luethi <collector at hellgate.ch> wrote:
>
>
>>On Sat, 03 Jun 2006 17:27:59 -0400, Anthony DiPierro wrote:
>>
>>
>>>>Categories based on such intersections of attributes are conceptually bad.
>>>>Look at the categories for an article like [[Marie Curie]]: She's French
>>>>three times, female four times, Polish four times (not counting "Natives of
>>>>Warsaw"), etc. Why not create [[Category:Polish women who were born in
>>>>1867 and died in 1934 and won a Nobel Prize in Chemistry and in Physics]]?
>>>>
>>>>
>>>Because there would only be one person in that category.
>>>
>>>
>>That's why nobody made it, but not why it shouldn't be done.
>>
>>
>I'd say it's both.  There shouldn't be categories with only one
>article in them.  IMO that's just common sense.
>
They should be avoided, but I would not proscribe them.  If you are
sub-categorizing mammals you still need to deal with the ones that are
so different (like the platypus) that they will end up in a one article
category.

>In the current system categories should have a fair number of articles
>in them.  If there are too many, they should be broken up.  If there
>are too few, they should be combined.  There isn't a crystal clear
>line what constitutes too many and what constitutes too few, but a
>category with only one article in it clearly has too few.
>
>The problem of categories having too many articles in them wouldn't
>really be a problem if the software allowed you to automatically
>compute category intersections.  But the software doesn't do this, so
>people make do with what they've got.
>
Exactly

>>For instance, how do you connect the districts of Paris to the category
>>Paris? What is a subset of the parent attribute "Paris": "Districts of
>>Paris", or "Quartier Latin", or neither? Does it bother you if the article
>>on a French district is now in a subcategory of "Capitals in Europe"?
>>
>>
>[[Category:Paris]] is a theme, not an attribute, so [[Category:Paris]]
>should not be a subcategory of [[Category:Capitals in Europe]].
>
Is it practical to have people debating whether something is a theme or
an attribute?

>>Or going back to [[Category:Women]]: You could declare that only articles
>>on instances of women (i.e.  biographies) can ever be under that category,
>>and that only sets of such articles can ever be subcategories of the
>>category women. -- You could even create a separate [[Category:Woman]],
>>subcategories like "female reproductive organs" containing articles like
>>uterus. -- But how would you express the undisputed relationship between
>>female human beings and your example [[Category:Feminine hygiene]]? How
>>about [[Category:Women's rights]]? Add an umbrella cat "Somehow related to
>>women" maybe?
>>
>>Roger
>>
>>
>[[Category:Women]] could be a subcategory of [[Category:Woman]].
>Making an attribute a subcategory of a theme is allowed, it is the
>reverse that is not allowed.
>
Avoid distinctions that will have to be re-explained every time another
newbie joins.

>In any event, things wouldn't be perfect.  Ultimately the best
>solution would involve fixing the category system itself, a process
>which should be approached carefully so as to avoid making the same
>mistakes all over again.  The advantage of my proposal to not allow
>themes as subcategories of attributes is that it can be implemented
>today, without much disruption, and without modifying any code.  Plus,
>it allows for a relatively straightforward upgrade path when the
>category system is fixed.  The proposal itself is not the fix, it's a
>temporary workaround.
>
>As an alternative, it would probably be possible to do all of this
>even without enforcing the subcategory rule.  But all purely attribute
>categories would have to be identified as such.  I'll have to think
>about that.
>
One can work towards this, but any enforcement is a bit like passing a
law that requires everybody to think logically.

Ec


body:
Kirill Lokshin wrote:
> On 6/6/06, Brion Vibber <brion at pobox.com> wrote:
>
>
>>I've done some automated checks on templates on en.wikipedia.org to make a list
>>of likely problem candidates:
>>
>>http://leuksman.com/misc/templates/html-table-start.txt
>>http://leuksman.com/misc/templates/html-table-end.txt
>>http://leuksman.com/misc/templates/html-table-row.txt
>
>
> Looks like the third list is largely composed of templates that use
> raw HTML table markup inside {{#if}} (which, coincidentally, includes
> a great many of the most widely-used infoboxes).  This is going to be
> fun! ;-)

Infoboxes are a very important application of templates. There needs to
be some way conditionally add table rows based on whether or not a given
template parameter is defined. When people complained about the argument
separators in {{#if:}} clashing with table syntax, I told them to use
HTML table tags instead. That seemed like a much better, more stable
solution than {{!}}. If that's not going to work anymore, what exactly
are people meant to do?

There are thousands of affected articles, and if there is no solution
for this, then I don't think it is acceptable to put this change live.

Why is the template required to close its own tags? It would make things
a lot easier if this was not required.

-- Tim Starling


subject: [WikiEN-l] Types of categories

body:
Steve Bennett wrote:

>On 6/4/06, Roger Luethi <collector at hellgate.ch> wrote:
>
>
>>>I've personally run into this when trying to automatically create, for
>>>example, a list of all Wikipedia articles on people.  You can't just
>>>start at [[category:people]] and work your way down, because you wind
>>>up going to [[Category:Women]] (fine, all women are people) then
>>>[[Category:Feminine hygene]] (bad).
>>>
>>>
>>Okay, that's equivalent to Steve's Amelie-Paris relation. I agree that's a
>>problem.
>>
>>
>The problem there, now that I think about it, is that Paris should not
>be in the category "Paris" (as was pointed out by someone else).
>
>Amelie should be in the category "Paris"
>The article Paris should be in the category "European capitals" (say)
>The article Paris should not be in the category "Paris"
>The category "Paris" should not be in the category "European capitals".
>
>Actually, even simply obeying this last rule would solve it: Paris
>*the article* belongs in the taxonomic category (Paris *is a* European
>capital) , but "Paris" the category is thematic, so should only belong
>to thematic categories: maybe "Europe" in this case.
>
>That actually seems to fix the problem. I saw this with The Beatles
>for example. John Lennon was in category "The Beatles" (thematic), and
>that category was in "British rock bands" (taxonomic), leading to the
>conclusion that Lennon was a British rock band.
>
You can't avoid multiple categorizations.  The category "European
capitals" would not exclude Paris from the category "Cities of France".
The Beatles would still be in "1960s rock bands".  Do you need to
priorize time over place?  Eponymous recursions are really a very minor
problem since they never involve more than a single article in a category.

Ec


subject: [WikiEN-l] Types of categories

body:
On Wed, 07 Jun 2006 00:39:52 +0200, Steve Bennett wrote:
> On 6/6/06, Roger Luethi <collector at hellgate.ch> wrote:
> > With the current software, that could be implemented as:
> >
> > [[Paris]]
> >        [[Category:is a city]]
> >                [[Category:is a (is there a name for "city or town or
> >                        village or some other place"?)]]
> >        [[Category:in France]] (or [[Category:located in France]])
> >                [[Category:in Europe]]
> >
> > Okay.
>
> Why do I get the feeling the current structure probably already looks
> a lot like that, but with different names?

Because it does. Where it's different is that the category names make it
much clearer what does and what does not belong into the category, the
catch-all "thematic" categories are eliminated (or made explicit by saying
"is related to").

> > What i see is (I added more information for illustration):
> >
> > [[Britney Spears]]
> >        [[Category:is a singer]]
> >                [[Category:is an entertainer]]
> >                        [[Category:is a person]]
> >        [[Category:is a child actor]]
> >                [[Category:is an entertainer]]
> >                        [[Category:is a person]]
> >        [[Category:is alive]]
> >        [[Category:is female]]
> >        [[Category:born 1981]]
> >        [[Category:born in McComb, Mississippi]] (that kind of category
> >                        would be hard to maintain manually)
>
> Good, good - why is that cat hard to maintain manually?

Because for every place someone was born in, you have to recreate the
hierarchy of geography, which is large. An automatic system could infer
from existing information that [[Category:born in McComb, Mississippi]]
also means, say, [[Category:born in Mississippi]], or if you want to be
really fancy, that being born in Prague implies a different country
depending on the year of birth.

> > Here are some other fun (existing!) categories from said article:
> >
> > Worst Actress Razzie: "won a Worst Actress Razzi"
> > Soubrettes: "is a soubrette", I guess!?
> > American child actors: ...? "is a child actor" or "was a child actor?"
>
> Yes. The fact taht these are hard to express clearly is very telling.

What does it tell you?

> > Hollywood Walk of Fame: Ugh.
> > High school dropouts: Ahm?
>
> Dropped out of high school?

I guess <shrug>.

> Erm, I mean, people will probably end up being "casual" with
> attributes...but if we could make the taxonomic classificatins a bit
> more firm...not sure what I'm getting at (it's late).

The easiest way to make them more firm is by making them self-explanatory.
Otherwise it's not unreasonable for people to assume that a category is
thematic.

> > It is. But "species" is not a genus. Like city is not a country.
>
> Yes, but I'm not sure what you're point is - are you talking about
> "species" the article? Of course it shouldn't belong to "genus" the
> category...probably missing something.

Nevermind. It wasn't a great example, Europe-France-Paris was better.

> > I see two major problems with the status quo:
> > * multi-concept categories (American child actors) force us to maintain a
> >  complex system of subcategories (but they paper over shortcoming in the
> >  software). The German WP shows it doesn't have to be this way, but
> >  it might be difficult to convince people on WP:en until Mediawiki can
> >  create intersections
>
> Yay, how hard can it be?

Convincing or intersections? Hard enough, either way.

> > * categories with unclear relations that are used for everything
>
> Like [[Category:Lasers]]? ;)

Exactly. If it was called [[Category:is a Laser]], there would be less
confusion.

> > comes at a cost). However, we are dangerously close to inventing a poor
> > man's version of a semantic wiki.
>
> Would a fully fledged semantic wiki ever work on Wikipedia scale?

Of course. The question is not if, but when. Evaluating all relations and
attributes on-the-fly may be way out there, but you could use it for
offline-processing today, and that's what _you_ and many other people seem
to be interested in.

Semantic Wiki does have challenges:

* The use needs to extend beyond nice statistics. Editors must see an
immediate benefit. There are major concerns about hidden metadata that is
invisible in the Wikipedia proper (unless you check the source, that is).

* It must try to prevent an ontology mess that we have with categories.
It can't ever be the same mess by virtue of its very own nature, but you
can for instance create confusion with "Relation:Is located in",
"Relation:Located in", and "Relation:Has location".

Check out, for example:
http://wiki.ontoworld.org/index.php/Help:Relation
You will find it eerily familiar :-).

> lack of intersections though. You know, what would be really awesome
> would be seeing at the bottom of each article:
>
> Categories: Bridges, in France, built by Romans
> See other: Bridges in France (200 articles), Bridges built by Romans
> (137 articles), Bridges in France built by Romans (15 articles).

It does sound cool, but if you have a dozen categories on an article rather
than three, you have more intersection categories than you want to put at
the end of the article.

> Is that feasible?

Not with the current mess, but other than that, I can't see why not.

> > woman chemist physicist polish (+ some more)
> >
> > I guess splitting woman into person and female seemed too awkward to the
> > Germans. Wimps.
>
> Heh, what do they do for young girls?

Female child actors are tagged "Frau", "Kinderstar" ("woman", "child
star"). So they use "woman" to mean "female human being" (even though
Frau implies "adult", as "woman" does in English).

(who would have guessed that the German WP has an article about an American
girl (born 1996) who played in a bunch of TV shows, including Startrek,
while the English WP has no article? I am shocked, shocked I tell you!)

Roger


body:
Anders Wegge Jakobsen wrote:
> Brion Vibber <brion at pobox.com> writes:
>
>> Just a heads-up, folks:
>>
>> Later this week I'm going to be installing a fix for some
>> longstanding bugs with HTML in wiki pages. One of the issues is a
>> difference in rendering of templates that improperly nest HTML tags,
>> which caused certain badly-written templates to render in one way on
>> Wikipedia but wildly broken on most other wikis.
>
>  Will the fixes also affect templates that spread wikitext table
> markup across more than one template, or is this a fix for misnested
> HTML only?

As mentioned in the following paragraphs, no. :)

-- brion vibber (brion @ pobox.com)

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


subject: [WikiEN-l] Types of categories

body:
Roger Luethi wrote:

>On Sun, 04 Jun 2006 11:31:02 -0400, Anthony DiPierro wrote:
>
>
>>Once the software is written to compute intersections of categories
>>within the Mediawiki software, it would be relatively simple to
>>recategorize the articles into their parent categories, such that no
>>information was lost.  The way this would be done is that all articles
>>in a subcategory which had multiple parent attribute categories would
>>be automatically moved into the parent categories.  This would be
>>repeated until no such situations continued to exist.  The ad-hoc
>>structure could still be kept, but it could be calculated on the fly
>>(along with new types of intersections which could be easily added).
>>
>>
>So instead of in the category "Bridges in France", the "Pont du Gard" would
>now be in the categories "Bridges" and "France"!?
>
There's no benefit from this unless we have a good search system.

>>(Now that I do this on an example, I see that this algorithm would
>>probably have to be tweaked to deal with subcatgories of
>>[[Category:Categories by topic]], but that's not too bad.)
>>
>>
>I suspect there are more corner cases than we imagine.
>
Absolutely. See
http://en.wiktionary.org/wiki/Wiktionary:Semantic_relations , and this
could be taken even further.

>>>For instance, how do you connect the districts of Paris to the category
>>>Paris? What is a subset of the parent attribute "Paris": "Districts of
>>>Paris", or "Quartier Latin", or neither? Does it bother you if the article
>>>on a French district is now in a subcategory of "Capitals in Europe"?
>>>
>>>
>>[[Category:Paris]] is a theme, not an attribute, so [[Category:Paris]]
>>should not be a subcategory of [[Category:Capitals in Europe]].
>>
>>
>One problem I'm seeing here is that your proposal focuses on one single
>type of hierarchies. Paris, France, Europe are now all themes. So if I
>ask for an intersection of categories "Bridges" and "France", the results
>include bridges that for any reason are related to the "France" theme.
>There is no way to ask for Bridges in France, or Paris.
>
>One solution would be to create "is part of" or "is in" categories in
>addition to the "is a" categories. Then you can have a hierarchy with "Pont
>du Gard" -> "France" -> "Europe", or "cylinder" -> "engine" -> "car".
>
>We'd have two indepent types of categories, plus a third, the catch-all
>"theme".
>
That still doesn't disambiguate "cylinder" -> "geometric solid", or
"engine" -> "aircraft", or "engine" -> "railway"

Ec


subject: [WikiEN-l] Types of categories

body:
Anthony DiPierro wrote:

> The latter should probably be [[Category:Humanity]] :).
>
>Here's another fun fact.  [[Category:Humans]] is a subcat of
>[[Category:People]].  Ick.
>
[[Category:Klingons]] could be another sub-category. :-)

>And now that I look at it, [[Category:Humans]] is also a subcat of
>[[Category:Apes]] (presumably a theme).  'Course that wouldn't have
>interested me if I was acquainted with the terminology that "humans"
>are "apes" :).
>
It's taxonomic among zo?logists.

>OK, this plural/singular thing probably isn't going to work.
>
Not in the general case, but there are still places where it can be
useful.  "Science" could be about science generally; "sciences" would
list the various branches."

>I suppose the plural/singular thing is still useful as a rough
>guideline.  If things are kept separated it doesn't have to be
>followed strictly.
>
>Anyway, I'm starting to think things are too far gone by now.  Might
>as well just wait for the features first and then start reorganizing
>things.  But I've got a little bit of hope, and my import script of
>the downloaded data is still running.
>
Reorganization can keep happening, but not on any massive scale.

Ec


subject: [WikiEN-l] Types of categories

body:
Anthony DiPierro wrote:

>That brings up another, longer term, to-do for categories: they should
>be language independent.  For instance [[Marie Curie]] is in de: and
>en: (they happen to have the same title, but even if they don't they
>are linked via interwiki links).  [[Kategorie:Pole]] is linked to
>[[Category:Polish people]].  So there should be no need to categorize
>Marie Curie twice (multiply by the actual number of languages which
>have a Polish people category and an article on Marie Curie).
>
>This is pretty simple theoretically.  The only real problem is getting
>the multiple category schemes in sync.  Considering your point about
>how the German categorization scheme differs from the English one,
>this might be a lot harder in practice than it is in theory.
>
I think that this would be very difficult across projects, if only
because the terminology is different, and there is a cultural element to
determining distinctions.

To some extent I have dealt with som of this on the English Wiktionary
as a byproduct of being all words in all languages, but with English
definitions.  Category names there would also all be in English.  Thus
[[Category:Mammals]] could have its usual hierarchical subcategories
[[Category:Dogs]], [[Category:Rabbits]], etc.  It would also hve
[[Category:de:Mammals]], [[Category:ja:Mammals]], etc. which could be
developed in a parallel manner for  those other languages.  To
facilitate sorting the language codes would always be lower cased, and
the categories themselves would be upper cased.

>>>>Your definitions of taxonomies and attributes need work :-).
>>>>
>>>>
>>>Heh :) Input welcome! I think the distinction between "taxonomy" and
>>>"attribute" is probably a sliding scale. It comes down to what is
>>>natural. Do we really think in terms of "nobel laureates"? I doubt it
>>>
>>>
>>Combining rigid rules with common sense is hard. I am tempted to quote your
>>line about inevitable disaster.
>>
>>
>Personally I don't see the difference between taxonomies and
>attributes, as described.  But I suppose one (taxonomies?) could be
>described as partitioning (an article can only be in one taxonomy
>category) whereas attributes can be mixed.  Under that definition
>though, all taxonomies are attributes (but not vice-versa).  I'm not
>sure how close that definition is to reality though.
>
It's best not top get hung up on pedantic distinctions.

Ec


from_name: Magnus Manske

body:
Steve Bennett schrieb:
> On 6/7/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
>
>>> Assuming this is a general question not specifically related to
>>> MediaWiki, the general answer is that exceptions should only be used
>>> for exceptional circumstances, and likely failures are better off
>>> handled with return codes. It's better to use exceptions for weird
>>> things like running out of memory, suddenly being unable to access the
>>> disk, or an assertion failing, rather than something as banal as a bad
>>> filename being supplied, for instance.
>>>
>> Do you have some sort of justification for this view?
>>
>
> Just what I've read.
>
For C++, I totally ageee with this. It's just the way it's done, and
proved to be a viable solution.

I see no reason to stray from this well-established path in PHP.
Exceptions are to be used for, well, exceptional events. Bad user input
is normal. Hard drive going down is exceptional.

Magnus


body:
On 6/7/06, Magnus Manske <magnus.manske at web.de> wrote:
> For C++, I totally ageee with this. It's just the way it's done, and
> proved to be a viable solution.
>
> I see no reason to stray from this well-established path in PHP.
> Exceptions are to be used for, well, exceptional events. Bad user input
> is normal. Hard drive going down is exceptional.

Fwiw, I was speaking from a Delphi/Java experience, no idea how it
relates to PHP, which I've never used.

Steve


from_name: jkelly at fas.harvard.edu

subject: [WikiEN-l] Psychology of problem Wikipedians

body:
  Karl,

> What a mind-numbingly bad misreading of my post.

  Incidentally, I also misread your post.  After reading the first few
paragraphs, it seemed to me that you were trying to describe what is called
"pathologizing".  But then, as an example, you gave... a pathology.  So
whatever point you were trying to make was completely opaque to me as well.

                 Jkelly


from_name: Drini drini

subject: [WikiEN-l] Another KIND of categories: (Was: Types of categories)

body:
Well, the discussion about the "kind of categories" missed a very important
one:

Categories used to group wikipedians by poitical/religious beliefs
like
[[Category:Muslim Wikipedians]]
[[Category:Born-again Christian Wikipedians]]
[[Category:Flying Spaghetti Monsterist Wikipedians]]
[[Category:Roman Catholic Wikipedians]]

etc which are sometimes used to raise voting blocks.

The emphasis on "this user is/believes foo" is quite different from "this
user is interested in foo".

if I recall correctly, categories as the ones I mentiones above are not
welcome on wikipedia, but I may be wrong.

Can someone else please give me mroe feedback? Maybe previous discussions,
statements by jimbo or arbcom, etc...

Otherwise, I'm depopulating such categories (which over 95% of them are done
via userboxes) and removing them afterwards.


subject: [WikiEN-l] Types of categories

body:
On 6/7/06, Roger Luethi <collector at hellgate.ch> wrote:
> Because it does. Where it's different is that the category names make it
> much clearer what does and what does not belong into the category, the
> catch-all "thematic" categories are eliminated (or made explicit by saying
> "is related to").

Maybe the way to go is have only attributes, but then make certain
attributes themselves belong to thematic categories. Something like:

The Outsider
+Novel
+By Albert Camus
+Existentialist

Then make a thematic category "Existentialism" into which the
constructed (that is, automatically built by an intersection) category
"Existentialist novels" is grouped.

Not a good example come to think of it.

Should we try and work out, what is the basic point of thematic
categories? The problem is that the articles in them are related in
such different ways, that it would seem much better to have a page
that actually explains the links, and fits them in in a way that makes
sense: existentialist authors, existentialist works, history of
existentialism etc. Even a structured way of displaying items in
subcategorys on the page itself would be handy.

Just to continue this example, look at [[Category:Existentialism]].
There are subcategorical conceptual articles ("Existential desire"),
related conceptual articles (Absurdism), works (Exile and the
kingdom), and miscellaneous (Kierkegaard and Nietzsche comparisons).
Then there's the subcategory "Existenialists" where we find Sartre and
Camus. And even better, a perfect example of a thematic subcategory to
a taxonomic category to a thematic category: "S?ren Kierkegaard",
which mostly contains his works, but also mentions a research centre
and the man himself.

>From a navigational point of view it would be so much more helpful
having a single page that quickly defined the topic, linked to the key
articles about the topic, then presented sections "Existentialist
authors" that transcluded the relevant category, "Existentialist
works" that did the same, and finally ended with "related categories".
If we had that, then Wikipedia would be really starting to get
somewhere as a structured encyclopaedia, as opposed to simply a
massive number of articles on various topics.

> > Good, good - why is that cat hard to maintain manually?
>
> Because for every place someone was born in, you have to recreate the
> hierarchy of geography, which is large. An automatic system could infer
> from existing information that [[Category:born in McComb, Mississippi]]
> also means, say, [[Category:born in Mississippi]], or if you want to be
> really fancy, that being born in Prague implies a different country
> depending on the year of birth.

Hmm, well apart from the Prague bit, it would certainly be cool to be
able to hijack a geographical structure that had been built once to
create other attributes/categories. You would need something fancy
like categorical operators though, which is definitely getting more
advanced and complicated.

Category:Bridges in France would become: Category: (is a bridge) (in)
(place:France). Since (place:Lyon) would be defined once and for all
as being a subcategory (subplace?), any bridge in Lyon would
automatically be a bridge in France.

To solve your example, a different "operator" (born in) would be used,
combined with a place. The end result is to replace a number of
parallel hierarchies with a single one combined with several different
operators:

in (place)
born in (place)
died in (place)
famous in (place) ?
buried in (place) ?
banned in (place) ?

One obvious advantage is that people could immediately start assigning
articles to categories like "Born in New York" or even "Born in
Queens", without losing them from the broader categories "American
musicians" etc.

> > > American child actors: ...? "is a child actor" or "was a child actor?"
> >
> > Yes. The fact taht these are hard to express clearly is very telling.
>
> What does it tell you?

That the categories are badly designed and ambiguous.

> > Erm, I mean, people will probably end up being "casual" with
> > attributes...but if we could make the taxonomic classificatins a bit
> > more firm...not sure what I'm getting at (it's late).
>
> The easiest way to make them more firm is by making them self-explanatory.
> Otherwise it's not unreasonable for people to assume that a category is
> thematic.

Yep. If the category doesn't tell you exactly what it's about, it must
be "random stuff with some tangential connection to X" :)

> > Like [[Category:Lasers]]? ;)
>
> Exactly. If it was called [[Category:is a Laser]], there would be less
> confusion.

Actually [[Category:Types of lasers]] would be better - "blue laser"
is not really "a laser". Very few individual lasers would deserve
entries.

Hard to see how "laser" would be a good name for a thematic category
though. But where else would laser eye surgery or light sabers go?

> Of course. The question is not if, but when. Evaluating all relations and
> attributes on-the-fly may be way out there, but you could use it for
> offline-processing today, and that's what _you_ and many other people seem
> to be interested in.

Depends what "on the fly" means. "Each time an attribute is updated"
would be one thing. "Each time a user requests" it would be another.
The former would fit the mediawiki model a lot better.

> Semantic Wiki does have challenges:
>
> * The use needs to extend beyond nice statistics. Editors must see an
> immediate benefit. There are major concerns about hidden metadata that is
> invisible in the Wikipedia proper (unless you check the source, that is).

Clearer groupings, better portals, automatic navigational boxes, more
powerful categories (like "German-born Polish scientists buried in
France (2 articles)")

> * It must try to prevent an ontology mess that we have with categories.
> It can't ever be the same mess by virtue of its very own nature, but you
> can for instance create confusion with "Relation:Is located in",
> "Relation:Located in", and "Relation:Has location".

Redirects solve so many of these problems.

> > Categories: Bridges, in France, built by Romans
> > See other: Bridges in France (200 articles), Bridges built by Romans
> > (137 articles), Bridges in France built by Romans (15 articles).
>
> It does sound cool, but if you have a dozen categories on an article rather
> than three, you have more intersection categories than you want to put at
> the end of the article.

Some way where editors can guide the system would be valuable. Some
way where power users can ignore the editors' recommendations and see
all the possible intersections (ok, within reason) would be nice.

> > Is that feasible?
>
> Not with the current mess, but other than that, I can't see why not.

We seem to have a couple of different proposals bubbling away, each
requiring different amounts of work to implement. I'll see if I can
summarise somewhere and synthesise something palatable, to really work
out feasibility.

> (who would have guessed that the German WP has an article about an American
> girl (born 1996) who played in a bunch of TV shows, including Startrek,
> while the English WP has no article? I am shocked, shocked I tell you!)

And the English Paris article is better than the French one, and the
German New York article is better than the English one.

Steve


subject: [WikiEN-l] AFC needs your help!

body:
Anthony DiPierro schrieb:
> On 5/22/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
>> Dear RC patrollers and vandal hunters,
>>
>> This is a desperate plea for help!
>>
>> The few people who work at "Articles For Creation" are getting overworked.
>> They almost can't keep up with the new requests and a lot of dubious
>> submission are left
>> with no idea how to handle them. Even worse, occasionally
>> "Wikipedia:Articles for creation"
>> and "Wikipedia:Articles for creation/Today" get blanked by a newbie who
>> isn't reading the
>> instructions. Unfortunately, those blankings aren't always discovered in
>> time, and this way
>> a lot of good submissions are missed. Once they get archived, they're almost
>> never touched.
>>
>>
> Why not set up a system where each article proposed for creation
> exists as a separate page.  And there could be a special page set up
> which points to each of them.  This special page could list the date
> and time created, the name of the proposed page, the number of bytes
> of the page, and the username or  IP address of the proposer.
>
My Tasks extension handles requests for creation, with the date the task
was submitted, and the IP of the submitter. Tasks can be sorted by
creation date, and assigned to people. Each task can have its own
discussion page.

Besides, it could handle requests for deletion, stub notes
(automatically categorized), etc.

Currently, however, it is sitting unmaintained in the extensions module,
since noone gives a s**t. Business as usual.

Magnus


subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
On 6/7/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> Making it a category would be an absolutely horrible solution, as it
> would remove any possibility of having any footnotes or annotations.

You could put a <!-- comment --> next to the [[Category:Cults]] wikitext.

Steve


from_name: Delirium

subject: [WikiEN-l] Category translation

body:
Jimmy Wales wrote:
> For the record, and as I have said many times in the past, I do NOT
> think that cultural distinctions between difference language Wikipedias
> are accidental or to be regarded as accidental, and even if it were
> possible to translate every article using machine translation, I cannot
> imagine that we would want to do so.
>

This seems like a strange position to me.

My view of a good encyclopedia article is that *any* reasonable person
in the world would find it: 1) informative; and 2) neutral.  This should
include non-native speakers of the language, people from outside the
typical "culture" of the language, and even people who can't speak the
language at all who have the article translated for them.  On en:, we
make an explicit effort to have it *not* be biased towards Anglosphere
culture, but instead to pull in people who speak English as a second
language (whether well or not) and are generally outside of
"English-speaking culture".  This isn't of course 100% successful, but
the *goal* is definitely to make it a global encyclopedia, not an
encyclopedia only for people who are culturally in the English-speaking
world.

-Mark


subject: [WikiEN-l] Are lists subject to WP:NOR?

body:
Peter Jacobi wrote:

>Hi JzG, All,
>
>
>>Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>>
>>
>>>And if so, in which sense?
>>>
>>>
>>Yes, and in the usual sense: if you cannot provide a reliable source
>>for each individual case (and here that would mean referencing each
>>one explicitly as it is likely to be contentious) then the entry must
>>be removed.  If none of them are sourced the list is empty - delete.
>>If none of them *can* be sourced, the list is unverifiable - delete.
>>
>>
>Mmmh. That's (IMHO) the entire problem: The single entries
>are -- in a sense -- all sourced. Minus some drive-by-additions
>to the list, it is usually indeed verifiable, that
>* X said 19YY the group Z is a cult [of]
>
>But the question is, does it matter?
>
>Is X an expert on Z? Is his opinion isolated? Which of
>the several meanings of "cult" is implied?
>
>So, if you put together all these atoms of sourced statements,
>is the entitity you created still in line with WP:NOR, WP:V
>and friends? IMHO its (a) just this compiling step which is
>problematic and (b), in this special case of [[List of groups
>referred to as cults]], the one-drop-rule employed: Find one
>author which says "is a cult" and the it's  on the list.
>
A distinction needs to be made with lists in general and the particular
list you have in mind.  In general lists are to be encouraged.  The red
links that they contain serve as a valuable launching point for further
development.  There should be little need to generally provide sources
for list items in the absence of a specific challenge to an item.  When
actual articles are written there will be ample opportunity for adding
sources.

Your specific example about cults seems more like someone trying to
exercise POV about just what groups are cults.  I would act more
strictly with that.

Ec


body:
Platonides wrote:
> How about a new Magic Word like __TAGS_COMPLETED_ON_PARENT__

No, absolutely not. A magic word that breaks parsing is absolutely insane. It
needs to work consistently in one way or the other.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/5a483b13/attachment.pgp


body:
Platonides wrote:
> How about a new Magic Word like __TAGS_COMPLETED_ON_PARENT__

No, absolutely not. A magic word that breaks parsing is absolutely insane. It
needs to work consistently in one way or the other.

-- brion vibber (brion @ pobox.com)

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


from_name: George Herbert

body:
On 6/7/06, Mark Gallagher <m.g.gallagher at student.canberra.edu.au> wrote:
>
> [...] and it all just leading to an attempt to recapture USENET's heyday.
>

We had a heyday?

--
-george william herbert
gherbert at retro.com / george.herbert at gmail.com


from_name: maru dubshinki

subject: [WikiEN-l] Types of categories

body:
On 6/7/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Incidentally, I realised one great thing that could be done with a
> hierarchical taxonomy: The very top branch can be "Fictional" vs
> "Real". Easy way to prune out huge sections of fancruft :)
>
> Steve

Not really. I don't see what such a division gains. You still have a
demarcation problem. Is [[Darth Vader]] fictional or real? He's
obviously fictional, since such a fellow never was born, lived, fell
to the dark side, and was redeemed; but on the other, you can't say he
is completely unreal and unmoored from reality, because there are
countless real things of him, various physical real objects like
comics, books, movies, costumes with actors in them etc.

~maru
'Shuzan held out his short staff and said, "If you call this a short
staff, you oppose its reality. If you do not call it a short staff,
you ignore the fact. Now what do you wish to call this?"'


subject: [WikiEN-l] Are phone books reliable sources?

body:
maru dubshinki wrote:

>On 6/4/06, Ray Saintonge <saintonge at telus.net> wrote:
>
>
>>This all depends on how rigidly you look at the term "source".
>>Scientific American does not typically have a lot of footnotes, but it
>>does give opportunities such as this for further exploration. Are you
>>saying that this makes the magazine less credible?
>>
>>
>Scientific American generally gives far more references than most
>other science magazines I can think of (Discover is generally on or
>below SA's par, and Science News is definitely way below)
>
I only occasionally pick up Discover, but I noticed that about the last
one that I got.  Of course, no one's mentioning  Popular Science. :-)
It has progressed a long way downhill since its early days in the 19th
century when it had some very interesting feature articles.  In that
same period Scientific American was a weekly which put great emphasis on
the material that was going through the US Patent Office.

Ec


body:
Delirium wrote:
> Brion Vibber wrote:
>> But if we're really, really sure, we can put some time into working on that and
>> accept that our syntax will never be predictable. (This has consequences for
>> future wysiwyg or markup-sensitive assisted editing plugins.)
>>
>
> Isn't it general practice with a macro-like facility like templates not
> to parse until you've substituted in the preprocessing phase?

That depends on the macro-like facility.

> If they're to have some sort of different semantics, that's a different
> paradigm of sorts---it would require no longer using templates as
> macros, but as functions that return complete well-formed sub-parts of
> the page.

In what way is that not like a macro?

Note that the C preprocessor is not the only macro language in existence; it's
just a particularly ugly and poorly-integrated example. In fact it's a perfect
example of how *not* to design a macro language, since it's impossible to
reliably work with C source code programatically due to it. Simple cases mostly
work, while mildly complex cases explode dramatically for no apparent reason.

Dumb source-code replacement (like the C preprocessor) is extremely difficult to
work with; however parse-tree replacement is clean and easy to work with for
analysis, conversion, and editing tools.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/fc36a5e9/attachment.pgp


body:
Delirium wrote:
> Delirium wrote:
>> it should then be made obvious and well-understood that
>> templates aren't macros.
>>
>
> I was going to add that we might want to do something about subst: then,
> too.  IMO it's *very* counterintuitive that {{subst:foo}} and {{foo}}
> would render differently, especially since most of the documentation
> treats them as semantically equivalent.

Most of the time they will render the same.

The issue is when some smart-ass comes along and abuses the system; how badly
will it break?

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060607/d80339db/attachment.pgp


from_name: Elliott F. Cable

subject: [Wikitech-l] New diff feature for MediaWiki

body:
I'm forwarding this to MediaWiki-l also. I think it's more relevant
there anyway.

I like that a lot, and think it should be implemented in MediaWiki
ASAP. I'm e-mailing him to ask why he only wants to contribute if
it's used in 'teh wikipedia'<!-- wikicrapia more like it -->, there
are lots of other wiki sites out there that need this and could
definitely use it. I'm aallll for this, and willing to help in any
way I can.

On Jun 6, 2006, at 2:13 PM, Roman Nosov wrote:
> Hi all,
>
> I've been directed here by Brion, Robchurch and others on
> #wikimedia-tech.
> So I propose a new feature for Wikipedia which people on
> #wikimedia-tech mostly refer as blame page or blame map. I would
> prefer to call it something like "Track contributions mode" (because
> of similarity with MS Word track changes mode) or "Hall of fame" but
> whatever. I have live prototype written in PHP&MySQL at
> http://217.147.83.36:9000/ Example of "blame map" can be seen at
> http://217.147.83.36:9000/history::171 two blame maps compared
> http://217.147.83.36:9000/history::171=169
>
> For some reason folks at #wikimedia-tech. were mainly concerned with
> speed and almost nothing else so I'll try explaining performance
> issues as best as I can.
>
> First of all, I DO NOT propose to recalculate diffs for all zillions
> of edits Wikipedia already has. Diffs would only be calculated for a
> new edits.
> Next, I want to explain in detail how I see this working. So first I
> propose to modify revision table and add a flag with following
> possible values: "Revision is too old to be diffed", "Revision is
> awaiting to be diffed", "Revision has been diffed". Also another table
> should be added that will store blame maps for each revision. Blame
> map for each subsequent revision will be calculated incrementally. So
> it doesn't really matter whether article has 10 or 1000 revisions. We
> would only need last blame map.
>
> I also propose to have separate dedicated diff server(s) with sole job
> to calculate diffs in background. I.e. diff server grabs revision with
> "Revision is awaiting to be diffed" flag and last blame map from
> database, calculates diff and finally stores new blame map in the
> database and also changes revision flag to "Revision has been diffed".
> Repeat.
>
> In addition, article display logic should be altered. The module that
> displays article should check diff flag. If diff flag is set to
> "Revision is too old to be diffed" no further changes needed. If diff
> flag is set to "Revision is awaiting to be diffed" then Credits
> section should be created that only contains message "Calculation in
> progress". If diff flag is set to "Revision has been diffed" then
> Credits section should be created that contains list of contributors
> ordered by contribution size. The list of contributors in correct
> order can be generated with a single select to blame map table. In
> addition this select can be cached. Direct link to blame map should be
> displayed too. If user clicks on this blame map link corresponding
> blame map should be presented. Every blame map can be generated with a
> single select and can be placed in cache. Yawn
>
> If you are still awake by now more thoughts on fault tolerance here.
> Should diff server die, crash, fail or whatever the only side effect
> end user will see is "Calculation in progress" message right after
> article body. That's it. No slowdown or anything. If user still wants
> see some kind of diff he/she can still use old diff engine. Because
> blame maps aren't calculated in real time this feature is impractical
> target for DoS attacks. However I should point out that any real time
> diff algorithm is one big fat target for DoS attacks on other wikis
> which are run on single server without some sort of acceleration.
>
> There is also small Unicode issue. Due to crappy utf-8 support in PHP
> all non-latin characters are currently ignored. I believe this could
> be solved either by enabling proper Unicode support in PHP or writing
> custom code to separate words. But before that I propose to test on
> English Wikipedia first because if it will works for English it should
> work for other languages.
>
> So I offer following practical steps. Dedicate one of servers to be
> diff playground. I will need a shell account on this server. Install
> mediawiki on it alongside with diff logic running in background.
> Create read only mysql account on live database server. So as a result
> this diff server can grab new revisions from live database, diff them
> and store results locally. This way we can find out how many edits
> single server can process and see how many servers this feature will
> require in total (I don't think it will be more than 2-3 though).
>
> In conclusion, I'd like to say that in my opinion this feature will be
> useful and practical if implemented. It also can be crucial building
> block for other interesting features. However, I want to stress that
> I'm not interested in doing this *unless* it is used in English
> Wikipedia and I'm given appropriate credit. I can give a reason why I
> want that in private e-mail.
>
> Thank you for reading this long and boring e-mail.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject:
[WikiEN-l] Aww, so cute,
 a banned user is trying to take us down with a
 DMCA	notice	(Forwarded email)

body:
Philip Welch wrote:

>On Jun 4, 2006, at 8:00 PM, Ray Saintonge wrote:
>
>
>>>>>Wait untill you see some try to claim you can't deleted stuff
>>>>>claimed
>>>>>as fair use becuase that consitutes giving legal advice.
>>>>>
>>>>>
>>>>[[WP:BEANS]] ;-)
>>>>
>>>>
>>>Doesn't apply becuase it has already been tried:
>>>
>>>http://en.wikipedia.org/wiki/
>>>Wikipedia_talk:Copyright_problems#A_proposal
>>>
>>>
>>Simply giving legal advice is not the practice of law.  Practice would
>>require doing it as some kind of business.
>>
>>
>It's still against the rules to give legal advice for free, because
>the rules are made by lawyers, and lawyers' business is giving legal
>advice.
>
There's such a thing as taking this to extremes.  The way you put it if
two beer buddies sit down and discuss their latest parking tickets they
could be illegally driving lawyers into starvation.  In practical terms,
even though lawyers write the rules they are not turned on unless they
can smell money.

Ec


list: textbook-l

subject: [Textbook-l]  Game Guides

body:
Okay, Jimbo.  In an effort to discuss the game guides issue, I would
appreciate a couple of questions being answered.  I will try to
address various points people have brought up on the subject of game
guides as well as Wikibooks (WB) as a whole.  I will try to ask them
in a broad sense, including questions that may seem obvious to some.
Bear with me.

1. What was the original purpose of Wikibooks?

2. Is the current purpose the same?

3. Who has control over the overall content of Wikibooks? The
Wikimedia Foundation, the WMF Board, the community of Wikibookians?

4a. Some time ago now, you declared that game guides did not fit with
the intent of WB.  Were you speaking on behalf of the Wikimedia
Foundation?  Were you speaking just as Jimbo?

4b. Who decided all of a sudden to rid Wikibooks of game guides?  Was
there recent discussion on Meta?  Between the Board?  If so, is there
a record of this discussion?

5. Why specifically do game guides not fit in Wikibooks?  Are there
possible tax-exemption implications with having these here?  If so,
where is the information regarding this?

6. If the community of Wikibookians disagrees with the decision, and
consensus is formed against it, can the community disregard the
pronouncement?

7. If the community rejects the pronouncement and decides they want
game guides included, what steps would need to be taken to ensure
there place at WB?  Would the WMF bylaws need to be changed? If so,
how would they go about doing that?

8. Can video games be an acceptable textbook subject?  If so, what are
the requirements?  Is a simple walkthrough constitute a textbook?

9. If video game guides are to be gotten rid of, what about board game guides?

10. There is talk of a "Accredited Institution" metric.  If one small
institution somewhere develops a class on a topic, does that warrant
that topic's textbook on WB?  What about  if three institutions have
the class?  Should links to some number of courses be provided to show
the suitability for WB? If so, how many?

11. Do classes that you do not earn credit for (either
extra-curricular or within school, but not for credit) count as
classes under the Accredited Institution metric?  For example, clubs
used to educate someone on a topic not otherwise found in class.

12. If the removal of video game guides also results in the leaving of
many prolific and trusted WB editors, does the WMF consider this okay?

13. Any other comments on these issues?

I guess this is a start.  Forgive me if my biases show through. I
tried to ask questions brought up on both sides of the issue.  If I
have forgotten any glaring questions, please forgive me.  I understand
some of these are not easy to answer, but I, and others, would
appreciate whatever answers you can provide. Thanks.
--LV


from_name: thomas Armstrong

subject: [Wikitech-l] 'searchindex' table corrupted

body:
Hi

Working with v1.4, I found that 'searchindex' table was corrupted. I repaired
it, but does anybody have any similar experience to know the reason?

Thank you very much.