from_name: Fred Bauder

subject: [Wikipedia-l] concepts vs. words

body:
Sounds good, so I suppose the page [[lattice]] would be a disambiguation
page pointing to the other articles and explaining the different way the
concept is used.

Not sure how one would link to seperate wiktionary articles though. I think
wiktionary works best if we put it all on one page if we can, but your idea
might justify more separation so that a link from a specialized use of a
word in wikipedia could link back to the correct dictionary definition (in
fact every word in an article could, but we're not ready for that).

A lot of the hassles arise from ambiguity about what sense of a word is
being used, See the history of [[reality]].

Fred

>I noticed that the Lattice entry lumps together 3 different senses
>of the word "Lattice".  I believe these should be separate entries
>for each *sense*: [[Lattice algebraic structure]],
>[[Lattice in material science]] etc.
>
>Then there should be a disambiguation page that explains
>that in the context of algebra, the word "lattice" means
>[[Lattice algebraic structure]], in the context of material
>science it means [[Lattice in material science]] etc.  In
>general, I think that we should not get distracted by the
>fact that such entries are grouped together in traditional
>printed encyclopedias; this appears to be an artifact of the
>primitive lookup operation used in that case.
>
>I would even go as far as marking specially the pages whose
>primary purpose is to map words to senses.  The reason is
>the following potential useful enhancement of wikipedia.
>Image that *every* sense used in wikipedia article has an
>entry in wikipedia (or wiktionary).  Then one could build an
>interactive tool that would help replace every occurrence of
>a word in an article with a unique sense of that word.
>Therefore, all words would have unambiguous meaning.  This
>might not seem like a great advantage for human readers, but
>I believe that wikipedia has a large potential for automated
>processing.
>
>  Viktor
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikipedia-l


list: wikien-l

source: pipermail-mbox

subject: [WikiEN-l] Wikipedia:Shared resources

body:
>Eclectiology, I don't know if you know about this project, but archive.org
>keeps snapshots of websites, like a library for the internet. There was an
>interesting interview with the inventor in the New Scientist a little
>while back (It's probably available online if you look for it).
>

The stored records of web pages at archive.org can be accessed for research
purposes. One must make an application however and get approval. I think we
could do that though the auspices of wikipedia eventually. They more or
less want to know what institution you are with.

Fred

>ASB [[User:Smelialichu]]
>
>Eclctiology said:
>>>Along the same line, I've often found interesting web sites which I've
>bookmarked for later reference when I can focus my attention on the
>subject matter.  Several months later when I'm ready ... poof! it's
>gone.  Some of these have useful information, and it's a shame that it
>becomes lost because somebody didn't pay his ISP bill.
>
>These sites are covered by copyright, so for the most part we just can't
>copy the material onto Wikipedia and make it available to the public.
> Still it  could be in the public interest to copy material from
>threatened sites into a restricted access file where it could be revived
>if and when the original site could no longer be maintained.  It would
>be a lot easier to come to a conditional release agreement while the
>site is still functioning than after it has gone under.<<
>
>--
><signature>
>There are only 10 types of people in this world;
>Those that know binary...and those that don't
></signature>
>
>
>
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikien-l


list: wikitech-l

from_name: Sheldon Rampton

subject: [Wikitech-l] Sysop stuff on Wikipedia

body:
Hi all...I've done some more playing with the Wikipedia software for
my "Disinfopedia" project, and I noticed an apparent error in the
documentation. Specifically, the "user.doc" file contains the
following statement:

>   user_rights
>     Comma-separated list of rights. Right now, only "is_editor"
>     and "is_sysop".

I believe this should be changed to say,

>   user_rights
>     Comma-separated list of rights. Right now, only "developer"
>     and "sysop".

I was able to change my user rights to "sysop" using a direct SQL
command. Is there a better way to do this? Assuming the Disinfopedia
grows as hoped, I imagine I'll want to give sysop rights to other
users.

I'm assuming that I won't have any occasion to give anyone
"developer" rights. Is this a fair assumption?
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
--------------------------------


from_name: Brion Vibber

subject: [Wikitech-l] Sysop stuff on Wikipedia

body:
On lun, 2002-12-30 at 09:30, Sheldon Rampton wrote:
> >     Comma-separated list of rights. Right now, only "is_editor"
> >     and "is_sysop".
>
> I believe this should be changed to say,
>
> >     Comma-separated list of rights. Right now, only "developer"
> >     and "sysop".

That's right. Beware separate documentation files -- the up-to-date
documentation is the code itself. ;)

> I was able to change my user rights to "sysop" using a direct SQL
> command. Is there a better way to do this? Assuming the Disinfopedia
> grows as hoped, I imagine I'll want to give sysop rights to other
> users.

At present there is not a better way to sysopify users, but if anyone's
interested it would be easy enough to add a special page to grant/revoke
sysophood. (There used to be one, briefly, in phase II, it perhaps could
be dug up and adapted.)

> I'm assuming that I won't have any occasion to give anyone
> "developer" rights. Is this a fair assumption?

Unless you really trust them -- a 'developer' user has SQL write access
to the database, which means they can do anything from silently alter
the contents of an article to erasing the entire database. There's
nothing a developer could do that couldn't be done from a login shell on
the server with access to the physical installation, so you may not want
to use it at all.

-- brion vibber (brion @ pobox.com)


list: wikipedia-l

subject: [Wikipedia-l] Wikipedia page encoding

body:
On lun, 2002-12-30 at 11:06, Richard Grevers wrote:
> Hi again,
>
> I attempted to submit a sample Wkipedia page to the W3C validator and was
> amzaed to see that carried no character encoding whatsoever.

Eh?

GET /wiki/foobar HTTP/1.0
Host: www.wikipedia.org

HTTP/1.1 200 OK
Date: Mon, 30 Dec 2002 19:38:38 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Set-Cookie: PHPSESSID=19b987cd1b0790c6b079be08069f63f0; path=/
Expires: 0
Cache-Control: no-cache
Last-Modified: Mon, 30 Dec 2002 19:38:44 GMT
Pragma: no-cache
Content-language: en
Connection: close
Content-Type: text/html; charset=iso-8859-1

Right there, plain as day.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.wikipedia.org%2Fwiki%2Ffoobar
makes no complaints, either.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Wikipedia page encoding

references:
<oprh8fcuqik4g8ki@smtp.xtra.co.nz>
	<1041277650.17348.17.camel@rdaneel.vibber.org>
	<oprh8irxr9k4g8ki@smtp.xtra.co.nz>

body:
On lun, 2002-12-30 at 12:20, Richard Grevers wrote:
> Aha! One of the rare sites which uses the HTTP header and only the HTTP
> header to declare encoding. This tricked Opera's built-in validation
> submission, which actually uploads it's cached copy of the page, hence no
> header. Sorry for the false alarm.

Silly me for trying to follow standards. ;)

It would be safer to add in a meta tag too I suppose, I'll do that...

-- brion vibber (brion @ pobox.com)


from_name: tarquin

subject: [WikiEN-l] Re: Make summaries mandatory

body:
Brion Vibber wrote:

>(On the other hand, it's not hard to train oneself to hit tab-space
>after the summary.)
>
>
>
I've started doing this. Having to reach for the mouse to check the box
was a pain.
(yes, I know Orto will say "it's only 2 seconds". But I think we're
seeing evidence of differences in personality type. I'm very much a "do
six things at once, arg, why can't things go faster" sort of person. An
extra action bugs me, it might not bug Orto)

I still think that for registered users, comment boxes should be
recommended -- not compulsory.

(though if a dialog box popped up on submitting the form, it would save
me a press of the TAB key. I'd gain a whole 1.5 seconds of life over the
course of a week!!!! no, don't do that. I'm kidding :-)

>
>


from_name: Jonathan Walther

subject: [Wikipedia-l] Wikipedia pages DTD

body:
On Mon, Dec 30, 2002 at 10:12:00PM +0100, Erik Moeller wrote:
>> Since this does not include the URL to a full DTD, the curse of doctype
>> sniffing sees most browsers render the page in "Quirks" or "Bugwards
>> compatible" mode rather than "strict" mode. In the interests of making
>> wikipedia accessible, I think it would be better to force strict mode -
>> then editors would be more likely to notice markup errors which affect the
>> rendering on browsers which do not correct for bad markup.
>
>Why don't we just let the people using such browsers send us bug reports?
>If it ain't broke, don't fix it.

Because it's better if we just do The Right Thing from the beginning.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021230/ec743680/attachment.pgp


subject: [Wikipedia-l] Wikipedia page encoding

body:
On Tue, Dec 31, 2002 at 10:11:29AM +1300, Richard Grevers wrote:
>>It would be safer to add in a meta tag too I suppose, I'll do that...
>
>While you're about it, is there a concensus on the best encoding to use on general
>pages? 8859-15 ensures no problems should people use the likes of a Euro symbol in
>an article. Most definitions I've seen describe 8859-15 as "intended to replace
>8859-1".

I assumed that the encoding in the meta tag would be exactly the same as
the encoding in the http headers.  Any objection to that?  I think
switching from 8859-1 to 8859-15 is a separate issue, worth discussing.
For instance, how much software supports 8859-15?

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021230/b8011a40/attachment.pgp


subject: [Wikipedia-l] Wikipedia page encoding

body:
On lun, 2002-12-30 at 13:11, Richard Grevers wrote:
> While you're about it, is there a concensus on the best encoding to use on general
> pages? 8859-15 ensures no problems should people use the likes of a Euro symbol in
> an article. Most definitions I've seen describe 8859-15 as "intended to replace
> 8859-1".

ISO 8859-15 does not cover a number of characters that ISO 8859-1 does,
so I would heartily not recommend it.

Once conversion support for older, Unicode-broken browsers (wouldn't
trust them to do ISO 8859-15 either) is set up, the remaining Latin-1
sections of Wikipedia will move to UTF-8 (as Meta-Wikipedia, Wiktionary,
and many of the language sections of Wikipedia are already) so that
links and text are all in a compatible format.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Wikipedia pages DTD

body:
(Richard, you may be interested in the wikitech-l development list; see
http://www.wikipedia.org/mailman/listinfo/wikitech-l )

On lun, 2002-12-30 at 11:02, Richard Grevers wrote:
> My apologies if this has been discussed before, but I just noticed that
> Wikipedia pages carry a doctype declaration of
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>
> Since this does not include the URL to a full DTD, the curse of doctype
> sniffing sees most browsers render the page in "Quirks" or "Bugwards
> compatible" mode rather than "strict" mode.

Yes, this is intentional.

> In the interests of making
> wikipedia accessible, I think it would be better to force strict mode -
> then editors would be more likely to notice markup errors which affect the
> rendering on browsers which do not correct for bad markup.

We don't use the strict DTD (or, better yet, XHTML) because our
hacked-together wikicode->HTML parser currently can't guarantee that it
will generate well-formed output (particularly if there is raw HTML in
the page, which is munged a bit but not always correctly). If
well-behaved web browsers reject the page or massively break page
rendering due to a minor error, it's going to be mighty difficult for
editors using them to click 'edit' and try to work around the problem!

(On a similar note, nested HTML tables without closing </td> and </tr>
tags, while acceptable under HTML 4 standards, break Netscape 4.x, even
to the point of *crashing* it outright. This cropped up a while ago on
some of the Canadian provinces articles; the person who noticed the
problem couldn't edit the pages to look for the problem, since the
browser crashed before an edit link was made available. Really strict
DTD parsing isn't quite as bad -- it should at least tell you the
problem! -- but makes it hard to continue browsing.)

Volunteers for a new XHTML-safe parser are welcome...

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Re: [Wikitech-l] Tex update status

body:
On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> What's with the Tex feature update? Anything final yet?

It's sitting in CVS, and the fixed English language file looks right.
(** But we're still missing translations for the TeX options for most
languages! **)

Shall I install it wikipedia-wide? Is there any objection other than
Toby's? See: http://meta.wikipedia.org/wiki/Texvc

On a related note, I'd like some feedback on the suggestion to provide
support for inline musical notation via GNU Lilypond:
http://meta.wikipedia.org/wiki/Music_markup

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Tex update status


from_name: Tom Parmenter

subject: [WikiEN-l] Re: Make summaries mandatory

in_reply_to:
<3E103EB7.1040308@planetunreal.com> (message from tarquin on Mon,
	30 Dec 2002 12:40:23 +0000)

body:
|From: tarquin <tarquin at planetunreal.com>
|X-Accept-Language: en-us, en
|X-VSMLoop: planetunreal.com
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Mon, 30 Dec 2002 12:40:23 +0000
|
|
|
|Brion Vibber wrote:
|
|>(On the other hand, it's not hard to train oneself to hit tab-space
|>after the summary.)
|>
|>
|>
|I've started doing this. Having to reach for the mouse to check the box
|was a pain.
|(yes, I know Orto will say "it's only 2 seconds". But I think we're
|seeing evidence of differences in personality type. I'm very much a "do
|six things at once, arg, why can't things go faster" sort of person. An
|extra action bugs me, it might not bug Orto)

Orto doesn't believe it is an "extra" action, Orto believes it is
"documentation" and thus an essential part of what you are doing.

|
|I still think that for registered users, comment boxes should be
|recommended -- not compulsory.
|

Certainly recommended, not compulsory, but take "Votes for Deletion",
for example.  Isn't the value of another person's contribution there
either worth less or more trouble if it lacks a summary comment?
Doesn't the same go for any article that one is interested in?

That cranky guy, Orto

|(though if a dialog box popped up on submitting the form, it would save
|me a press of the TAB key. I'd gain a whole 1.5 seconds of life over the
|course of a week!!!! no, don't do that. I'm kidding :-)
|
|>
|>


from_name: Jason Richey

subject: [Wikitech-l] Tex update status

in_reply_to: <1041285697.17294.248.camel@rdaneel.vibber.org>; from brion@pobox.com on Mon, Dec 30, 2002 at 02:01:35PM -0800

body:
I am 100% for the comments you had about changing the backend to be
more generalizable.  I think that a plugin type architecture for this
type of thing would be ideal...

My thoughts:
We currently have the <math> tags and are considering <music> and
<tex>, right?  At what point are we going to realize that the stuff
that goes between these tags all share the same idea.  That is, they
are all text rendered into images and/or HTML for presentation.  I
think that it is crazy to add a tag every time we want to support a
new renderer.  We should use a single tag, and a modifier.  A few
possible examples:

<render type=tex>\sqrt[3]{x+y}</render>
<render type=math>\sqrt[3]{x+y}</render>
<render type=texvc>\sqrt[3]{x+y}</render>
<render type=lilypond>\notes{r4 <a c e> c e}</render>

That way, Toby could lobby (and create...) for a different math
rendering engine without stopping progress on texvc, and people who
like texvc could use it if they wanted.

Of course I realize that this adds a bit of complexity for the
wikipedian who is editing the code in the first place, but it could
remove a huge burden from the wikipedia developers.  We could just
publish a "render plugin API", and hope that someone from planetmath,
or lilypond or whatever group of developers would take interest and
write a plugin for that project.

Just my $0.02

Jason

Brion Vibber wrote:

> On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> > What's with the Tex feature update? Anything final yet?
>
> It's sitting in CVS, and the fixed English language file looks right.
> (** But we're still missing translations for the TeX options for most
> languages! **)
>
> Shall I install it wikipedia-wide? Is there any objection other than
> Toby's? See: http://meta.wikipedia.org/wiki/Texvc
>
> On a related note, I'd like some feedback on the suggestion to provide
> support for inline musical notation via GNU Lilypond:
> http://meta.wikipedia.org/wiki/Music_markup
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

--
"Jason C. Richey" <jasonr at bomis.com>


from_name: Erik Moeller

subject: [WikiEN-l] Re: Make summaries mandatory

body:
> Adding the preference setting "All edits minor by default" was a hasty
> decision.

The option is useful for copyeditors. Vera Cruz is Lir's new account name,
and he/she has been doing this before the option even existed.

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


from_name: Alexander Stephen Bradbury

subject: [WikiEN-l] Wikipedia:Shared resources

body:
Eclectiology, I don't know if you know about this project, but archive.org
keeps snapshots of websites, like a library for the internet. There was an
interesting interview with the inventor in the New Scientist a little
while back (It's probably available online if you look for it).

ASB [[User:Smelialichu]]

Eclctiology said:
>>Along the same line, I've often found interesting web sites which I've
bookmarked for later reference when I can focus my attention on the
subject matter.  Several months later when I'm ready ... poof! it's
gone.  Some of these have useful information, and it's a shame that it
becomes lost because somebody didn't pay his ISP bill.

These sites are covered by copyright, so for the most part we just can't
copy the material onto Wikipedia and make it available to the public.
 Still it  could be in the public interest to copy material from
threatened sites into a restricted access file where it could be revived
if and when the original site could no longer be maintained.  It would
be a lot easier to come to a conditional release agreement while the
site is still functioning than after it has gone under.<<

--
<signature>
There are only 10 types of people in this world;
Those that know binary...and those that don't
</signature>


subject: [Wikitech-l] Apache module

body:
On Tue, Dec 31, 2002 at 12:38:39AM +0100, Igor Gilitschenski wrote:
>Hi,
>
>On Tue, Dec 31, 2002 at 12:32:46AM +0100, Tomasz Wegrzanowski wrote:
>> There was such idea, but it isn't really popular here.
>> No code yet, not sure if ever.
>
>Why is it not popular?

It is news to me that it is not popular.

Code doesn't exist because it is currently in the design stage.

The permission scheme in particular, needs to be hammered out.  I am
trying to make it flexible enough to allow many different security
policies, and to allow Wikipedias current security policy without any
noticeable overhead.

Maybe the following URL will help; also, recent discussion in the
archives of this mailing list have a lot of detail that hasn't yet been
incorporated in the design document.  Please feel free to post with your
suggestions and ideas, to this list, and in the design document itself.

    http://www.wikipedia.org/wiki/User:Clutch/mod_wiki

Brion, what did you think of the idea of not making language be a
directory component, but an integral part of the title?

    http://foo.com/wiki/en:SaddleMaking

As opposed to

    http://foo.com/wiki/en/SaddleMaking

Then we can just have a table of "prefixes", and map them to namespaces,
or external wiki's, or whatever.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021230/dd6c8a9d/attachment.pgp>


from_name: Magnus Manske

subject: [WikiEN-l] Addition of just external link pages

body:
24.189.173.175
<http://www.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=24.189.173.175>(among
making contributions to many articles) keeps adding new "articles" that
consist of nothing but "External link" and a link to some website.

IMHO these are *not* articles, not even stubs. Therefore, I just deleted
3 or 4 of them.

Just letting you know.

Magnus


from_name: Jimmy Wales

subject: [Wikitech-l] need some numbers about wikipedia

in_reply_to: <auqq6j$r4c$1@main.gmane.org>; from giskart@wikipedia.be on Tue, Dec 31, 2002 at 01:00:04AM +0000

body:
Giskart wrote:
> The project in general; i know of course that Jimmy Weals is the person
> who   has give us Wikipedia and pays for everything. I know that he is
> the CEO of Bomis (TM). I do not understand how it is possible that he
> makes any money whit his website www.bomis.com

Bomis is very very popular, and we have advertising revenue.

> There is still no "formal wikipedia", no real organisation or legal
> structure. Is it still the intent that something like that will be done?

Yes.

> 3)
>
> www.wikipedia.org is still a "American/English" website and not a
> neutral portal. Is it still the idea to do something about that?

Uh, our official position is to deny that it is non-neutral?  And to
admit that it could use some tweaks.

I can't imagine that a reporter would ask about that, but if they did,
then obviously we'd want to diffuse the question by pointing out that
there's links right at the top of that page to all the other active
languages.

> The English Wikipedia; how many unique visitors a day does it get?
> How many different people on a typical day are working on the English
> wikipedia? 50 ? 100?  400?

Maybe someone else will answer this, otherwise I will look it up in
the morning.  :-)

> 5)
>
> For the Dutch Wikipedia, we have a Nedstat counter on the main page that
> gives us some limited information. It only counts page views, not unique
> visitors and mostly counts the traffic of the Wikipedians i think. Are
> there other, better logs that i can receive about the traffic to
> Wikipedia NL?

We could compress and make available an actual log for you, or whatever.

For privacy reasons, i.e. to respect our surfers, we shouldn't
distribute the actual access logs willy-nilly, but to a few trusted
people (like you) is not a problem.

> I suppose the English Wikipedia has give more interviews; any
> suggestions?

No matter what you say, you will be misquoted.  This is my experience.
:-) Sometimes this is good, sometimes not.

--Jimbo


subject: [Wikipedia-l] Open Publication License?

body:
Wikipedia is currently under GFDL. Would the Open Publication License
not be more suited?

I just found it at http://www.opencontent.org/openpub/

Just a thought.

Magnus


from_name: Ray Saintonge

subject: [WikiEN-l] Wikipedia:Shared resources

body:
Fred Bauder wrote:

>>Eclectiology, I don't know if you know about this project, but archive.org
>>keeps snapshots of websites, like a library for the internet. There was an
>>interesting interview with the inventor in the New Scientist a little
>>while back (It's probably available online if you look for it).
>>
>
>The stored records of web pages at archive.org can be accessed for research
>purposes. One must make an application however and get approval. I think we
>could do that though the auspices of wikipedia eventually. They more or
>less want to know what institution you are with.
>
Thanks.  My first impression is that it's a fascinating site.

Eclecticology

>


subject: [Wikitech-l] Apache module

body:
On Tue, Dec 31, 2002 at 01:10:28AM +0100, Tomasz Wegrzanowski wrote:
>> >On Tue, Dec 31, 2002 at 12:32:46AM +0100, Tomasz Wegrzanowski wrote:
>> >>There was such idea, but it isn't really popular here.
>> >>No code yet, not sure if ever.
>> >
>> >Why is it not popular?
>>
>> It is news to me that it is not popular.
>
>Well, you don't have any code yet, have quite radical ideas about desing,
>and you didn't tell us whether it will be possible to mirror wikipedia
>without having to use Apache.

Instead of implying that the apache module was unpopular, it might have
been better to have just said it wasn't in existence yet.

Apache runs on every platform one is likely to want to run a Wikipedia
on; I don't see being bound to Apache as an issue.  If you do have an
issue with that, I'd appreciate you spelling it out in detail so I can
address it.

As for "radical" ideas, I haven't put a single original idea in the
design.  It is all traditional, orthodox Unix and standard engineering
practice.  Maybe those things were radical 30 years ago.  Today those
things are considered tried and true by most people.

Which items in particular did you consider "radical"?

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021230/d233e5cd/attachment.pgp>


subject: [Wikitech-l] Tex update status

body:
What's with the Tex feature update? Anything final yet?

(I'm only asking because I'd like to use my new Recent Changes toy, but
I'm afraid to break something when installing the current CVS, because
of the Tex stuff).

Magnus


subject: [Wikipedia-l] Wikipedia pages DTD

body:
> Since this does not include the URL to a full DTD, the curse of doctype
> sniffing sees most browsers render the page in "Quirks" or "Bugwards
> compatible" mode rather than "strict" mode. In the interests of making
> wikipedia accessible, I think it would be better to force strict mode -
> then editors would be more likely to notice markup errors which affect the
> rendering on browsers which do not correct for bad markup.

Why don't we just let the people using such browsers send us bug reports?
If it ain't broke, don't fix it.

Regards,

Erik


from_name: Toby Bartels

body:
Brion Vibber wrote in part:

>Shall I install [texvc] wikipedia-wide? Is there any objection other than
>Toby's? See: http://meta.wikipedia.org/wiki/Texvc

Since Tomasz responded yes when everybody knew that he thought so,
then I won't feel bad about responding no when everybody knows
that I think that.  In any case, get Axel's answer first.

My essay on the above page left out an important point:
Why we shouldn't install texvc now and then fix it later
(assuming that the essay is persuasive on other points).
Basically, the reason is that supporting LaTeX directly
(as Axel and I want) won't be backwards compatible with current texvc;
fixing it later will break some things.

I realise that I now need to get to work on writing
an alternative to texvc that we can install soon.
(Saying that texvc isn't good enough
is unhelpful if there's nothing that is!)
I hope that Axel agrees with my opinions on TeX support and will help.
I don't expect that Tomasz will want to help,
but of course I'd welcome anybody.
(How such an alternative would work is already outlined in the essay.)

-- Toby


subject: [Wikitech-l] Tex update status


body:
> On a related note, I'd like some feedback on the suggestion to provide
> support for inline musical notation via GNU Lilypond:
> http://meta.wikipedia.org/wiki/Music_markup

In favor if we can get possible security issues sorted out (anyone e-
mailed the Lilypond folks yet?). Also, we should run some performance
tests on the MIDI generation etc. to make sure that it's not too taxing.

Since this is likely to come up again, should we think about a general
plugin framework or something like that? texvc might be extended in that
fashion.

Regards,

Erik


subject: [Wikitech-l] Tex update status


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Tex update status

body:
On Mon, Dec 30, 2002 at 02:01:35PM -0800, Brion Vibber wrote:
> On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> > What's with the Tex feature update? Anything final yet?
>
> It's sitting in CVS, and the fixed English language file looks right.
> (** But we're still missing translations for the TeX options for most
> languages! **)
>
> Shall I install it wikipedia-wide?

Yes.
Translations can be provided later.


from_name: Igor Gilitschenski

subject: [Wikitech-l] Apache module

body:
Hi,

At the 19. Chaos communication Congress in Berlin
(www.ccc.de/congress/2002/) I've heard, that wikipedia is considering
rewriting the Code as an Apache Module. My question is, wether you have
already started writing it and where can I find the code?

Cu,
Igor


subject: [Wikitech-l] Tex update status

body:
On Mon, Dec 30, 2002 at 02:29:31PM -0800, Jason Richey wrote:
> I am 100% for the comments you had about changing the backend to be
> more generalizable.  I think that a plugin type architecture for this
> type of thing would be ideal...

We can make such system after we have 3 or so renderers.

> My thoughts:
> We currently have the <math> tags and are considering <music> and
> <tex>, right?  At what point are we going to realize that the stuff
> that goes between these tags all share the same idea.  That is, they
> are all text rendered into images and/or HTML for presentation.  I
> think that it is crazy to add a tag every time we want to support a
> new renderer.  We should use a single tag, and a modifier.  A few
> possible examples:
>
> <render type=tex>\sqrt[3]{x+y}</render>
> <render type=math>\sqrt[3]{x+y}</render>
> <render type=texvc>\sqrt[3]{x+y}</render>
> <render type=lilypond>\notes{r4 <a c e> c e}</render>

I think that using different tags makes it more readable.
We'll probably have only a few renderers (math, music, chemistry, anything else ?)
plus maybe some multilingual pronunciation processor (so people can
see kana/kunrei/hepburn or pinyin_with_diactrics/pinyin_with_numbers/wadegiles
or real_arabic/latinization or whatever else, depending on what they set in
preferences, and maybe to connect it to some speech generator ...).

I don't think it's insane. XML guys do this all the time.

> Of course I realize that this adds a bit of complexity for the
> wikipedian who is editing the code in the first place, but it could
> remove a huge burden from the wikipedia developers.

I'm kinda Wikipedia developer and I don't think it's a big burden.
It's less than 10 lines per tag.

> We could just
> publish a "render plugin API", and hope that someone from planetmath,
> or lilypond or whatever group of developers would take interest and
> write a plugin for that project.

Connecting texvc to Wikipedia script wasn't all that hard.


subject: [Wikipedia-l] XHTML-safe parser (was: Wikipedia pages DTD)

body:
Brion Vibber wrote:

>Volunteers for a new XHTML-safe parser are welcome...
>
>
>
You might want to check out the markup parser we use on Unreal Wiki.
My co-host there Mychaeel wrote it as a replacement for UseModWiki's
built-in parser.
It's a separate perl script.

http://wiki.beyondunreal.com/wiki/Wookee -- general description & test area

It's OO and extendable.
I expect it can be taught to chomp up unclosed  as a piece of wiki
markup and spit out clean 	.
But maybe we should reopen the debate on implementing table markup?

-- tarquin


body:
Erik Moeller wrote:

>>On a related note, I'd like some feedback on the suggestion to provide
>>support for inline musical notation via GNU Lilypond:
>>http://meta.wikipedia.org/wiki/Music_markup
>>
>>
>
>In favor if we can get possible security issues sorted out (anyone e-
>mailed the Lilypond folks yet?). Also, we should run some performance
>tests on the MIDI generation etc. to make sure that it's not too taxing.
>
>Since this is likely to come up again, should we think about a general
>plugin framework or something like that? texvc might be extended in that
>fashion.
>
>
>
http://lilypond.org/stable/Documentation/user/out-www/lilypond/First-steps.html#First%20steps

It writes "C" for "\time 4/4"? Urg!
LaTex  "feels" like maths feels -- I think this stuff will feel very odd
to the average musician.

It should be fine for basics. Don't expect anyone to transcribe Mozart
with it though!
That said, I think the basics are all we'll need.
(otherwise, there's

  MusicXML

http://www.recordare.com/xml.html)

>
>


subject: [Wikitech-l] Apache module

body:
On Mon, Dec 30, 2002 at 11:57:24PM +0100, Igor Gilitschenski wrote:
> Hi,
>
> At the 19. Chaos communication Congress in Berlin
> (www.ccc.de/congress/2002/) I've heard, that wikipedia is considering
> rewriting the Code as an Apache Module. My question is, wether you have
> already started writing it and where can I find the code?

There was such idea, but it isn't really popular here.
No code yet, not sure if ever.


subject: [Wikitech-l] Apache module

body:
Hi,

On Tue, Dec 31, 2002 at 12:32:46AM +0100, Tomasz Wegrzanowski wrote:
> There was such idea, but it isn't really popular here.
> No code yet, not sure if ever.

Why is it not popular?

Igor
--
"In meinen 100 Jahren dienstzeit hab ich schon
 einiges erlebt."
 - meine Mathelehrerin.


from_name: Giskart

body:
There is a very good change that somebody of the Dutch wikipedia soon will
be able to give the first real interview soon for a important dutch
magazine (a real one, on paper) about Wikipedia and Wikipedia NL.

I would like to know some numbers and general information about
wikipedia if possible to give good information about wikipedia.

1)

The project in general; i know of course that Jimmy Weals is the person
who   has give us Wikipedia and pays for everything. I know that he is
the CEO of Bomis (TM). I do not understand how it is possible that he
makes any money whit his website www.bomis.com

If that is, non of youre business, be happy that hey pays for it, i
understand.

2)

There is still no "formal wikipedia", no real organisation or legal
structure. Is it still the intent that something like that will be done?

3)

www.wikipedia.org is still a "American/English" website and not a
neutral portal. Is it still the idea to do something about that?

4)

The English Wikipedia; how many unique visitors a day does it get?
How many different people on a typical day are working on the English
wikipedia? 50 ? 100?  400?

5)

For the Dutch Wikipedia, we have a Nedstat counter on the main page that
gives us some limited information. It only counts page views, not unique
visitors and mostly counts the traffic of the Wikipedians i think. Are
there other, better logs that i can receive about the traffic to
Wikipedia NL?

6)

I suppose the English Wikipedia has give more interviews; any
suggestions?

Giskart


subject: [Wikitech-l] Apache module

body:
On Mon, Dec 30, 2002 at 03:50:56PM -0800, Jonathan Walther wrote:
> On Tue, Dec 31, 2002 at 12:38:39AM +0100, Igor Gilitschenski wrote:
> >Hi,
> >
> >On Tue, Dec 31, 2002 at 12:32:46AM +0100, Tomasz Wegrzanowski wrote:
> >>There was such idea, but it isn't really popular here.
> >>No code yet, not sure if ever.
> >
> >Why is it not popular?
>
> It is news to me that it is not popular.

Well, you don't have any code yet, have quite radical ideas about desing,
and you didn't tell us whether it will be possible to mirror wikipedia
without having to use Apache.

But that will of course if we'll see nice and fast code.


body:
On Tue, Dec 31, 2002 at 01:00:04AM +0000, Giskart wrote:
> There is a very good change that somebody of the Dutch wikipedia soon will
> be able to give the first real interview soon for a important dutch
> magazine (a real one, on paper) about Wikipedia and Wikipedia NL.
>
> I would like to know some numbers and general information about
> wikipedia if possible to give good information about wikipedia.

You can get full apache logs and analyze them if you have shell access
to Wikipedia servers. Ask Brion for shell access if you don't have it yet,
or to send you logs.


from_name: Derek Moore

subject: [Wikitech-l] Suggestion to promote readability of hyperlinked documents.

body:
Because of the nature of Wikipedia, articles tend to get rather congested
with links.  All these super-bright reds and blues and gaudy underlines can
sometimes get the better of an article.  I was working on [[w:LAMP]] just
now when my eyes just couldn't take anymore.

It might be nice to find some softer colors for links, visited links, and
non-existent links.  And to also, via CSS, get rid of the underlines on
links within the body of an article (the underlines are kinda helpful for
the menus to left, above, and below articles, though [but maybe for style
these underlines could be done away with, too, and instead go with bolding
the font faces]).  I do like red for non-existent articles, and blue for
existent articles; they're just way too bright as it is.

Anyways, I really think something ought to be done about this, as too many
link-filled articles just look terrible, and their readability is quite
degraded.  It's just too distracting on the eyes, especially when you're
tryin' to study the text.

What do others think?

_________________________________________________________________
The new MSN 8: smart spam protection and 3 months FREE*.
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf


body:
On lun, 2002-12-30 at 23:23, Toby Bartels wrote:
> Why we shouldn't install texvc now and then fix it later
> (assuming that the essay is persuasive on other points).
> Basically, the reason is that supporting LaTeX directly
> (as Axel and I want) won't be backwards compatible with current texvc;
> fixing it later will break some things.

Is there anything that couldn't be fixed by a script (such as texvc
itself modified to spit out the preferred LaTeX forms) which would hunt
down and fix articles with problem math?

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Tex update status


subject:
[Wikitech-l] Suggestion to promote readability of hyperlinked
	documents.

body:
On mar, 2002-12-31 at 00:27, Derek Moore wrote:
> Because of the nature of Wikipedia, articles tend to get rather congested
> with links.  All these super-bright reds and blues and gaudy underlines can
> sometimes get the better of an article.  I was working on [[w:LAMP]] just
> now when my eyes just couldn't take anymore.
>
> It might be nice to find some softer colors for links, visited links, and
> non-existent links.

What do you think of the colors in the Cologne Blue skin?

(I really think we need to finish cleaning up Cologne Blue and make it,
or a variant of it, the standard skin. It's a darn sight nicer looking!)

>  And to also, via CSS, get rid of the underlines on
> links within the body of an article

I'm *very* much against this. It's standard convention for links on the
web to be underlined; not doing so (on top of changing the standard
colors) makes them practically invisible. I've been on sites where I
literally couldn't tell what was a link and what wasn't short of putting
the cursor over every word, because some smartass webmaster decided that
links should be bold, not underlined, and the same color as regular
text, and would use the same bold for simple emphasis...

That said, I've no objection to removing the forced underline from our
style definitions and leaving it up to the browser settings.

-- brion vibber (brion @ pobox.com)


in_reply_to: <F7aJ6pkNzPZrIkyPzGN00009314@hotmail.com>; from jizzbug@hotmail.com on Tue, Dec 31, 2002 at 02:27:04AM -0600

body:
Derek Moore wrote:
> What do others think?

I'm so old-school, I wish everything were just left at the html
defaults.  :-)  But I defer to others on this.

--Jimbo


subject: [Wikitech-l] Suggestion to promote readability of hyperlinkeddocuments.

body:
>I'm *very* much against this. It's standard convention for links on the
>web to be underlined; not doing so (on top of changing the standard
>colors) makes them practically invisible. I've been on sites where I
>literally couldn't tell what was a link and what wasn't short of putting
>the cursor over every word, because some smartass webmaster decided that
>links should be bold, not underlined, and the same color as regular
>text, and would use the same bold for simple emphasis...

Yeah, I'm sure we've all had those problems when surfing.  *grin*  Now that
I think about it more (my last email was shot off rather quickly, typing as
I thought of the ideas), I agree that sticking with the underline
conventions for links is probably the best thing to do.

It's the underlines, though, that effect readability in link-ridden articles
the most, at least for me.  But, then again, I'm mildly colorblind, so the
contrast between bright colors (say, bright red or blue against a bright
white background) tends to stress and distract my eyes (especially when
bright red is butted up against bright green, it sometimes makes my eyes
almost water).  The extra brightness from the underlines doesn't help.  A
link here and there doesn't bug my eyes, it's when an article is
link-ridden, when there's two, three, or more links on each line for a few
lines, etc.

How about this:  Have link underlines be dashed, similar to the way
<acronym> is rendered in most browsers.  Then on hover, the dashed-underline
becomes the traditional underline.  Is that even possible with CSS1/2?  If
it's not, it should be, as it'd be a nice feature.

If the dashed underline thing isn't possible, I suppose I'm the colorblind
minority, so I can just put up with full underlines.  However, it would help
if the reds and blues were toned down a bit, if they weren't so terribly
bright.

Okay, I'm done now,

Derek

_________________________________________________________________
MSN 8 limited-time offer: Join now and get 3 months FREE*.
http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf


from_name: Richard Grevers

subject: [Wikipedia-l] Wikipedia pages DTD

body:
Hello everyone,

My apologies if this has been discussed before, but I just noticed that
Wikipedia pages carry a doctype declaration of
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Since this does not include the URL to a full DTD, the curse of doctype
sniffing sees most browsers render the page in "Quirks" or "Bugwards
compatible" mode rather than "strict" mode. In the interests of making
wikipedia accessible, I think it would be better to force strict mode -
then editors would be more likely to notice markup errors which affect the
rendering on browsers which do not correct for bad markup.
--
Richard Grevers
CHristchurch, NZ


subject: [Wikipedia-l] Wikipedia page encoding

body:
Hi again,

I attempted to submit a sample Wkipedia page to the W3C validator and was
amzaed to see that carried no character encoding whatsoever. Here is the
full report from the validator -

I was not able to extract a character encoding labeling from any of the
valid sources for such information. Without encoding information it is
impossible to validate the document. The sources I tried are: The HTTP
Content-Type field.
The XML Declaration.
The HTML "META" element.

And I even tried to autodetect it using the algorithm defined in Appendix F
of the XML 1.0 Recommendation. Since none of these sources yielded any
usable information, I will not be able to validate this document. Sorry.
Please make sure you specify the character encoding in use. IANA maintains
the list of official names for character sets. ----
<end quote>
Surely Wikipedia ought to use an encoding such as UTF-8?
--
Richard Grevers


subject: [Wikipedia-l] Wikipedia page encoding

body:
On 30 Dec 2002 11:47:28 -0800, Brion Vibber <brion at pobox.com> wrote:

> On lun, 2002-12-30 at 11:06, Richard Grevers wrote:
>> Hi again,
>>
>> I attempted to submit a sample Wkipedia page to the W3C validator and
>> was amzaed to see that carried no character encoding whatsoever.
>
> Eh?
>
> GET /wiki/foobar HTTP/1.0
> Host: www.wikipedia.org
>
> HTTP/1.1 200 OK
> Date: Mon, 30 Dec 2002 19:38:38 GMT
> Server: Apache/1.3.26 (Unix) PHP/4.2.3
> X-Powered-By: PHP/4.2.3
> Set-Cookie: PHPSESSID=19b987cd1b0790c6b079be08069f63f0; path=/
> Expires: 0
> Cache-Control: no-cache
> Last-Modified: Mon, 30 Dec 2002 19:38:44 GMT
> Pragma: no-cache
> Content-language: en
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> Right there, plain as day.
>
> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.wikipedia.org%2Fwiki%2Ffoobar
>
>
> makes no complaints, either.
>
Aha! One of the rare sites which uses the HTTP header and only the HTTP
header to declare encoding. This tricked Opera's built-in validation
submission, which actually uploads it's cached copy of the page, hence no
header. Sorry for the false alarm.
--
Richard Grevers


from_name: The Cunctator

subject:
[Wikipedia-l] Re: [Wikitech-l] Suggestion to promote readability of hyperlinked
 documents.

body:
On 12/31/02 3:27 AM, "Derek Moore" <jizzbug at hotmail.com> wrote:

> Because of the nature of Wikipedia, articles tend to get rather congested
> with links.  All these super-bright reds and blues and gaudy underlines can
> sometimes get the better of an article.  I was working on [[w:LAMP]] just
> now when my eyes just couldn't take anymore.
>
> It might be nice to find some softer colors for links, visited links, and
> non-existent links.  And to also, via CSS, get rid of the underlines on
> links within the body of an article (the underlines are kinda helpful for
> the menus to left, above, and below articles, though [but maybe for style
> these underlines could be done away with, too, and instead go with bolding
> the font faces]).  I do like red for non-existent articles, and blue for
> existent articles; they're just way too bright as it is.
>
> Anyways, I really think something ought to be done about this, as too many
> link-filled articles just look terrible, and their readability is quite
> degraded.  It's just too distracting on the eyes, especially when you're
> tryin' to study the text.
>
One, this isn't a matter for wikitech. Two, I think it's fine for there to
be a non-default skin that satisfies your desires. Three: in no way should
non-underlined links be the default. It's bad practice in terms of usability
to violate standards.


in_reply_to: <8ctGXa4CpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Dec 31, 2002 at 07:05:00PM +0100

body:
Erik Moeller wrote:
> Are you aware of the user preference "Underline links"? I think that
> making non-underlined links the default as well would be nicer; the
> argument that they are no longer recognizable as links doesn't count, as
> the colors are sufficiently distinct.

I disagree.  On the web, a standard blue underline that turns purple
after you visit it is simple and instantly recognizable.  For many web
users, it is the ONLY thing that they can count on to be a link.

It's very important to do what people expect.  The principle of least
astonishment is key.

--Jimbo


subject: [Wikipedia-l] Wikipedia page encoding

body:
On 30 Dec 2002 12:31:35 -0800, Brion Vibber wrote:

>On lun, 2002-12-30 at 12:20, Richard Grevers wrote:
>> Aha! One of the rare sites which uses the HTTP header and only the HTTP
>> header to declare encoding. This tricked Opera's built-in validation
>> submission, which actually uploads it's cached copy of the page, hence no
>> header. Sorry for the false alarm.
>
>Silly me for trying to follow standards. ;)
>
>It would be safer to add in a meta tag too I suppose, I'll do that...

While you're about it, is there a concensus on the best encoding to use on general
pages? 8859-15 ensures no problems should people use the likes of a Euro symbol in
an article. Most definitions I've seen describe 8859-15 as "intended to replace
8859-1".

--
A lottery is just a tax on people who are bad at math


subject: [Wikipedia-l] Wikipedia page encoding

body:
On Mon, 30 Dec 2002 13:22:48 -0800, Jonathan Walther wrote:

>On Tue, Dec 31, 2002 at 10:11:29AM +1300, Richard Grevers wrote:
>>>It would be safer to add in a meta tag too I suppose, I'll do that...
>>
>>While you're about it, is there a concensus on the best encoding to use on
general
>>pages? 8859-15 ensures no problems should people use the likes of a Euro symbol
in
>>an article. Most definitions I've seen describe 8859-15 as "intended to replace
>>8859-1".
>
>I assumed that the encoding in the meta tag would be exactly the same as
>the encoding in the http headers.  Any objection to that?  I think
>switching from 8859-1 to 8859-15 is a separate issue, worth discussing.
>For instance, how much software supports 8859-15?
>
Or to rephrase, is there any that doesn't? I've sued it on all my pages for a year
now, and I can't recall any browser that fails to render because of the encoding.
I must try the shopping basket I've just written (option for Euros) in Lynx.

--
A lottery is just a tax on people who are bad at math


in_reply_to: <8ctGZ6XSpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Dec 31, 2002 at 07:59:00PM +0100

body:
Erik Moeller wrote:
> Blue underlined, yes; purple is almost used nowhere these days. CNN,
> Yahoo, Amazon, eBay etc. all don't use it.

Yahoo does. (blue/purple, the old default)

Amazon doesn't. (blue/orange)

Ebay does. (blue/purpose, the old default)

CNN doesn't.  (And their choice is particularly bad because visited
and unvisited look so similar. blue/weird bluish greyish purple)

But I agree: it isn't those exact colors that matter, it's that links
should instantly look like links, and visited links should instantly
look like visited links.


in_reply_to: <8ctG$R6hpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Dec 31, 2002 at 08:12:00PM +0100

body:
Erik Moeller wrote:
> No, they don't, that's just because you have set these colors in your
> browser and Yahoo! and eBay use the default (i.e. no color specified on
> the page). Which is probably the most reasonable thing to do.

But I didn't set them in my browser.  I didn't do anything.  They just
came that way.  I don't fiddle with my settings, I just run whatever
they give me.

Most people are like that.  So most people see the web the same way I
see it.

--Jimbo


in_reply_to: <1041363352.370.29.camel@rdaneel.vibber.org>; from brion@pobox.com on Tue, Dec 31, 2002 at 11:35:51AM -0800

body:
Brion Vibber wrote:
> On mar, 2002-12-31 at 06:11, Lars Aronsson wrote:
> > One easy solution is to allow a CSS URL as a personal setting.  If it
> > is not set, everything works like today.  Users who are unhappy with
> > the default design can design a CSS style sheet, put it on some
> > webserver (maybe upload to Wikipedia) and enter its URL in the
> > personal settings.  Everyone can have their own, or share URLs.
>
> Looked in your browser's settings lately? If it doesn't have an option
> for a user-defined style sheet override, you're using either a very old
> or a very rare one.

I don't consider this an easy solution at all.  My mother has never
heard of a CSS style sheet, nor does she have any interest in fiddling
with settings of any kind.

If there's any problem that can only be solved with users setting up
CSS style sheets, we're doing something very wrong.

--Jimbo


from_name: Brion Vibber

body:
On mar, 2002-12-31 at 11:02, Erik Moeller wrote:
> > It's almost impossible to agree on one skin for both Latin script
> > and CJK Wikipedias.
>
> The Chinese and Japanese Wikipedia use the standard skin, what's your
> point? It's Esperanto that doesn't.

The Chinese stylesheet is slightly tweaked to indent paragraphs. However
taw's not talking about the _present_ skin there, but the _ideal_ one.
It ought to be tweaked further to be typographically CJK-friendly.

-- brion vibber (brion @ pobox.com)


body:
On mar, 2002-12-31 at 06:11, Lars Aronsson wrote:
> One easy solution is to allow a CSS URL as a personal setting.  If it
> is not set, everything works like today.  Users who are unhappy with
> the default design can design a CSS style sheet, put it on some
> webserver (maybe upload to Wikipedia) and enter its URL in the
> personal settings.  Everyone can have their own, or share URLs.

Looked in your browser's settings lately? If it doesn't have an option
for a user-defined style sheet override, you're using either a very old
or a very rare one.

-- brion vibber (brion @ pobox.com)


in_reply_to: <8ctGawKCpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Dec 31, 2002 at 08:50:00PM +0100

body:
Erik Moeller wrote:
> That, again, depends on what browser they are using and what that
> browser's defaults are. Hopefully not every browser manufacturer is so
> sick to use purple as the default for visited links ;-)

To my knowledge, they are.  Netscape, IE, and Mozilla have always been
this way.  If I remember correctly, Opera is the same way.

The standard link is blue, the standard visited link is purple.

I'm not saying, by the way, that we should stick to this.  I've never
complained too loudly about the changes that we've made already.  But
I do fear, sometimes, that we forget that most people don't use the
web the way we do.

(Well, except for me.  I have the technical skills to change my
browser settings, I just don't.)

--Jimbo


in_reply_to: <3E11F922.2020004@epost.de>; from magnus.manske@epost.de on Tue, Dec 31, 2002 at 09:08:02PM +0100

body:
Magnus Manske wrote:
> Would it be sufficient to have links not underlined, *but* show the
> underline when passing over them with the mouse? IMHO the average user
> can be expected to fiddle with the mouse, especially if there are no
> obvious links ("what? no links? let's try this...")

Yuck.  I see no reason to do this.  What's the advantage?

I hate to waste even one second of the precious brain power of our
visitors going "what? no links?"  Why make people do that?

I'd say that fanciness should be an option.  In general, we should
appeal to the lowest common denominator.  _Everyone_ should
_immediately_ know what to do on our website.

Like Yahoo.  I once heard someone complaining about how ugly Yahoo's
web design is.  Yeah, but they're the most popular website in the
world.  Yahoo does a good job of not astonishing people.

I'm taking a very "conservative" position here, but don't get me
wrong.  I have no problem with "middle of the road" web design, i.e.
I don't have a problem with Amazon's different link colors, because
it's still underlines and it's still obvious to the user what to
do, and what the different colored links are.


subject: [Wikitech-l] Tex update status

body:
On Tue, Dec 31, 2002 at 02:45:44AM -0800, Brion Vibber wrote:
> On lun, 2002-12-30 at 23:23, Toby Bartels wrote:
> > Why we shouldn't install texvc now and then fix it later
> > (assuming that the essay is persuasive on other points).
> > Basically, the reason is that supporting LaTeX directly
> > (as Axel and I want) won't be backwards compatible with current texvc;
> > fixing it later will break some things.
>
> Is there anything that couldn't be fixed by a script (such as texvc
> itself modified to spit out the preferred LaTeX forms) which would hunt
> down and fix articles with problem math?

texvc is very automatic and also very fast.
By very little code it can easily find things that break
after upgrade - you can just check if old version accepts
something while new doesn't and what is it.

So far I have used it for finding which symbols look different
with AMS and without, and for lot of texvc testing.

Also texvc includes script that exports anything to pure TeX
(which is also available on CGI), so if you wanted to take math
from Wikipedia and do something with it you still can.
(texvc produces some redundant {}s now in its TeX output,
is it serious problem ?)

If someone really wants to try blacklist way,
texvc can be easily modified to support it.
Last line of texutil.ml says:
    | s                    -> raise (Illegal_tex_function s)

What means: everything else is illegal

It should be modified to:
    | "\\foo" as s	   -> raise (Illegal_tex_function s)
    | "\\bar" as s	   -> raise (Illegal_tex_function s)
    | s			   -> LITERAL (TEX_ONLY (s ^ " "))

What means: everything else is legal tex-only literal

where foo bar etc. are all banned functions.
Those on current whitelist may be left to support HTML rendering etc.

But I don't think blacklist is any better as:
* there may be dangerous undocumented functions
* new functions may appear in new versions of TeX modules
* adding more supported functions to texvc is very easy if they
    aren't too magical like \big. In particular adding support
    for tex-only symbols is trivial.


body:
On Tue, Dec 31, 2002 at 02:55:37AM -0800, Brion Vibber wrote:
> (I really think we need to finish cleaning up Cologne Blue and make it,
> or a variant of it, the standard skin. It's a darn sight nicer looking!)

I'm for too.

> >  And to also, via CSS, get rid of the underlines on
> > links within the body of an article
>
> I'm *very* much against this. It's standard convention for links on the
> web to be underlined; not doing so (on top of changing the standard
> colors) makes them practically invisible. I've been on sites where I
> literally couldn't tell what was a link and what wasn't short of putting
> the cursor over every word, because some smartass webmaster decided that
> links should be bold, not underlined, and the same color as regular
> text, and would use the same bold for simple emphasis...

While I don't think that underline is any problem in Latin script,
it will be bad for CJK.


subject: [Wikipedia-l] Copyright question

body:
On mar, 2002-12-31 at 13:33, Richard Grevers wrote:
> What is the situation when you want to include information which is
> essentially in the public domain (e.g. a historical list of the Governors-
> General of NZ) but where all the convenient sources have their own
> copyright notices? Are they in effect copyrighting the information (which I
> would consider to be in the public domain) or just their presentation of
> it?

At least under US copyright law, _knowledge_ is not copyrightable, just
creative work and presentation. A simple list of governors-general, like
a list of names and telephone numbers in a phone book, is not a
substantial creative work. (There is a particular court case on the
matter; I don't recall but you can probably find it somewhere from
http://www.wikipedia.org/wiki/Wikipedia:Copyrights )

I can't speak for New Zealand, but I'd be very surprised if knowledge of
historical facts were subject to copyright. Otherwise, you wouldn't be
allowed to mention anything that you heard about on the radio or TV news
or read about in a newspaper without getting written permission and
paying a relicensing fee... ;)

(IANAL)

-- brion vibber (brion @ pobox.com)


subject:
[Wikitech-l] Suggestion to promote readability of hyperlinked
 documents.

body:
Tomasz Wegrzanowski wrote:

>On Tue, Dec 31, 2002 at 02:55:37AM -0800, Brion Vibber wrote:
>
>
>>(I really think we need to finish cleaning up Cologne Blue and make it,
>>or a variant of it, the standard skin. It's a darn sight nicer looking!)
>>
>>
>
>I'm for too.
>
BTW, should we have a JavaScript-improved skin? It could hold more
functions with less cluttering of the page.
If so, should it be a new one, or a variation of an existing one?

>>> And to also, via CSS, get rid of the underlines on
>>>links within the body of an article
>>>
>>>
>>I'm *very* much against this. It's standard convention for links on the
>>web to be underlined; not doing so (on top of changing the standard
>>colors) makes them practically invisible. I've been on sites where I
>>literally couldn't tell what was a link and what wasn't short of putting
>>the cursor over every word, because some smartass webmaster decided that
>>links should be bold, not underlined, and the same color as regular
>>text, and would use the same bold for simple emphasis...
>>
>>
>
>While I don't think that underline is any problem in Latin script,
>it will be bad for CJK.
>
While underlined links are useful on most web pages, IMHO they look
really ugly on wikipedia, and break the "flow of the text". I can't
really explain why; maybe because we're link-heavy on many pages (which
in itself is a Good Thing). Maybe because I feel our pages are more like
a book (in a positive way) than most web pages. Also, most of our links
are internally, which IMHO *should* be indicated somehow, so the user
will know that he won't leave the encyclopedia by following the link.

Magnus


subject: [Wikipedia-l] Wikipedia pages DTD

body:
On 30 Dec 2002 13:55:35 -0800, Brion Vibber wrote:

>(Richard, you may be interested in the wikitech-l development list; see
>http://www.wikipedia.org/mailman/listinfo/wikitech-l )
>
>On lun, 2002-12-30 at 11:02, Richard Grevers wrote:
>> My apologies if this has been discussed before, but I just noticed that
>> Wikipedia pages carry a doctype declaration of
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>>
>> Since this does not include the URL to a full DTD, the curse of doctype
>> sniffing sees most browsers render the page in "Quirks" or "Bugwards
>> compatible" mode rather than "strict" mode.
>
>Yes, this is intentional.
>
>We don't use the strict DTD (or, better yet, XHTML) because our
>hacked-together wikicode->HTML parser currently can't guarantee that it
>will generate well-formed output (particularly if there is raw HTML in
>the page, which is munged a bit but not always correctly). If
>well-behaved web browsers reject the page or massively break page
>rendering due to a minor error, it's going to be mighty difficult for
>editors using them to click 'edit' and try to work around the problem!

Sorry, a sloppy use of "Strict". I agree that using a strict DTD where the code is
1) machine generated
2) able to be input directly by editors
is asking for trouble.
But allowing browsers with two rendering modes to render the more standards
compliant one by using the transitional DTD with URL ( <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html40/loose.dtd"> ) would be preferable to quirks mode.
At worst, it would cause markup such as <SMALL><Table> to not render as small.

Perhaps it would be a good idea for the preview page to contain a link (targeted
to a new window) to submit the page to the validator. (Or to generate the page as
it would be if saved and submit that to the validator).

--
Why is it that most nudists are people you don't want to
see naked?


subject: [Wikipedia-l] Copyright question

body:
Richard Grevers wrote:

> What is the situation when you want to include information which is
> essentially in the public domain (e.g. a historical list of the
> Governors- General of NZ) but where all the convenient sources have
> their own copyright notices? Are they in effect copyrighting the
> information (which I would consider to be in the public domain) or
> just their presentation of it?

I basically agree with what Erik and Brion have said.  An original
presentation would be copyrightable, but the usual chronological or
alphabetical lists can hardly be considered original, nor could
something like putting a GG's dates to the left of the name instead of
to the right.  It is customary and much easier to make a blanket
copyright statement about a site, which means that it's copyright to
whatever extent it's copyrightable.  The user might as well be the one
to try figuring out what is and isn't copyright.  Sometimes the only
thing that is copyrightable is the general appearance of the site, which
you probably don't want to use anyway.

Eclecticology


body:
On Tue, Dec 31, 2002 at 03:11:18PM +0100, Lars Aronsson wrote:
> Derek Moore wrote:
> > Because of the nature of Wikipedia, articles tend to get rather congested
> > with links.  All these super-bright reds and blues and gaudy underlines can
>
> One easy solution is to allow a CSS URL as a personal setting.  If it
> is not set, everything works like today.  Users who are unhappy with
> the default design can design a CSS style sheet, put it on some
> webserver (maybe upload to Wikipedia) and enter its URL in the
> personal settings.  Everyone can have their own, or share URLs.

Part of the skin is in CSS, other part is in .php file.
Not everything can be modified that way.


subject: [Wikitech-l] A browser-specific problem

body:
The inline stylesheet served in the head of each wikipedia page has a
media=screen attribute in its declaration. This is problematic in Opera
when you hit F11 to take the browser to full-screen mode, which uses
media=projection (a handy replacement for powerpoint, as it happens). The
styles within that sheet are ignored, and since it contains the margin for
the main div, the main and left divs overlap rather messily.
Print preview shows the same overlapped rendering.

Unfortunately media="screen,projection" results in the stylesheet being
ignored in Netscape4 and IE4 (an oft-used hack for hiding style from these
browsers). Is the intention of the media=screen to disable the style for
print, or merely to be standards compliant?

The best solution might be to declare the stylesheet with no media
attribute.
In fact, inclusion of a media="print" stylesheet to follow it with the rule
#quickbar {display:none;} would allow printing without having to laod the
"printable version" - which has fonts that are too large IMO (I can cope
with smaller fonts printed than I can on screen). Most of the features of
the current printable page can be achieved via css2, including the citation
at the bottom.

--
Richard Grevers


from_name: Sheldon Rampton

subject: [WikiEN-l] May I be a sysop, please?

body:
Hi there...Sheldon Rampton here. I'm a relative newbie to Wikipedia,
but I'd like permission to be a sysop anyway.

I am making this request because I am in the process of creating my
own separate project, a "Disinfopedia" that will be modeled after
Wikipedia. In addition to the Wikipedia software, I would also like
to use or adapt a number of protected pages (e.g., guidelines on how
to create an article). I am not planning to make any changes to those
pages as they exist in Wikipedia, but in order to cut-and-paste the
information into my own project, I will need sysop status.

If you need any further information about my bona fides, I am the
editor and webmaster for PR Watch (www.prwatch.org).

Thanks!
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
--------------------------------


body:
> Because of the nature of Wikipedia, articles tend to get rather congested
> with links.  All these super-bright reds and blues and gaudy underlines can
> sometimes get the better of an article.  I was working on [[w:LAMP]] just
> now when my eyes just couldn't take anymore.

Are you aware of the user preference "Underline links"? I think that
making non-underlined links the default as well would be nicer; the
argument that they are no longer recognizable as links doesn't count, as
the colors are sufficiently distinct. Underlining is generally recognized
as the most distracting of all styles in typesetting, which is why it is
almost never used in print.

There is one advantage to underlining on Wikipedia: If you have two links
right next to each other:

[[December 7]] [[1981]]

These get underlined separately, whereas with no underlining you cannot
tell whether this is one link or two links without hovering.

> It might be nice to find some softer colors for links, visited links, and
> non-existent links.

It's not as bad if you turn underlining off, but I agree the colors could
be nicer. On the infoAnarchy wiki I use red on a slightly gray background
for non-existent pages:

http://www.infoanarchy.org/wiki/

(I also use underlining there, but mostly out of laziness.)

Regards,

Erik


body:
> What do you think of the colors in the Cologne Blue skin?
> (I really think we need to finish cleaning up Cologne Blue and make it,
> or a variant of it, the standard skin. It's a darn sight nicer looking!)

I like the current menu structure of the standard skin better, especially
with regard to special pages. (Also, having a heading like "Page options"
if there are only three items seems like overkill.) Neither "New pages"
nor "Image list" nor "Statistics" seem particularly important, and for the
other special pages there no longer is the quick access drop down from the
standard skin. I also think it's a bad idea to have the search box in the
menu bar as it's too small.

Furthermore, I can see why you want underlined links - with that skin it
really is necessary because of the dark link color. That is a bad default
choice because it makes the "Underline links" user preference almost
useless.

I do think we need to agree on a standard skin for the different language
Wikipedias. Consistency is important.

Regards,

Erik


body:
On Tue, Dec 31, 2002 at 07:30:00PM +0100, Erik Moeller wrote:
> I do think we need to agree on a standard skin for the different language
> Wikipedias. Consistency is important.

It's almost impossible to agree on one skin for both Latin script
and CJK Wikipedias.

And consistency isn't all that important.
Often we have different typografical traditions in different countries.


body:
> I disagree.  On the web, a standard blue underline that turns purple
> after you visit it is simple and instantly recognizable.

Blue underlined, yes; purple is almost used nowhere these days. CNN,
Yahoo, Amazon, eBay etc. all don't use it. So the expecation isn't there.
Blue underlined vs. blue is not such a big difference as to be confusing,
and we *are* a very link-heavy site.

That being said, I'm not pushing the no-underline thing. As long as I can
have my user preference, I'm happy.

Regards,

Erik


body:
> It's almost impossible to agree on one skin for both Latin script
> and CJK Wikipedias.

The Chinese and Japanese Wikipedia use the standard skin, what's your
point? It's Esperanto that doesn't.

Regards,

Erik


body:
> Erik Moeller wrote:
>> Blue underlined, yes; purple is almost used nowhere these days. CNN,
>> Yahoo, Amazon, eBay etc. all don't use it.

> Yahoo does. (blue/purple, the old default)
> Ebay does. (blue/purpose, the old default)

No, they don't, that's just because you have set these colors in your
browser and Yahoo! and eBay use the default (i.e. no color specified on
the page). Which is probably the most reasonable thing to do.

Regards,

Erik


body:
> But I didn't set them in my browser.  I didn't do anything.  They just
> came that way.  I don't fiddle with my settings, I just run whatever
> they give me.

> Most people are like that.  So most people see the web the same way I
> see it.

That, again, depends on what browser they are using and what that
browser's defaults are. Hopefully not every browser manufacturer is so
sick to use purple as the default for visited links ;-)

Regards,

Erik


body:
> The Chinese stylesheet is slightly tweaked to indent paragraphs. However
> taw's not talking about the _present_ skin there, but the _ideal_ one.
> It ought to be tweaked further to be typographically CJK-friendly.

Fair enough, but even if we need a new skin to do that, it should be as
close to the one used elsewhere as possible. There's no reason to have a
different set of links everywhere. The simple truth is
- many Wikipedia users are at least bilingual
- most Wikipedia users probably do not change their skin.

So from a usability perspective it's a good idea to have the Wikipedias
look and act the same. When I first visited eo.wikipedia I wasn't even
sure if this is the same software, because I hadn't seen the Cologne skin
yet.

Regards,

Erik


body:
Would it be sufficient to have links not underlined, *but* show the
underline when passing over them with the mouse? IMHO the average user
can be expected to fiddle with the mouse, especially if there are no
obvious links ("what? no links? let's try this...")

Magnus

Jimmy Wales wrote:

>Erik Moeller wrote:
>
>
>>That, again, depends on what browser they are using and what that
>>browser's defaults are. Hopefully not every browser manufacturer is so
>>sick to use purple as the default for visited links ;-)
>>
>>
>
>To my knowledge, they are.  Netscape, IE, and Mozilla have always been
>this way.  If I remember correctly, Opera is the same way.
>
>The standard link is blue, the standard visited link is purple.
>
>I'm not saying, by the way, that we should stick to this.  I've never
>complained too loudly about the changes that we've made already.  But
>I do fear, sometimes, that we forget that most people don't use the
>web the way we do.
>
>(Well, except for me.  I have the technical skills to change my
>browser settings, I just don't.)
>
>--Jimbo
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>


subject: [Wikipedia-l] Copyright question

body:
> What is the situation when you want to include information which is
> essentially in the public domain (e.g. a historical list of the Governors-
> General of NZ) but where all the convenient sources have their own
> copyright notices? Are they in effect copyrighting the information (which I
> would consider to be in the public domain) or just their presentation of
> it?

Facts cannot be copyrighted, only particular presentations can. Even if
someone claims copyright on a very basic factual list, you can safely
ignore it.

Regards,

Erik


subject: [WikiEN-l] May I be a sysop, please?

body:
Sheldon Rampton wrote:

>In addition to the Wikipedia software, I would also like
>to use or adapt a number of protected pages (e.g., guidelines on how
>to create an article). I am not planning to make any changes to those
>pages as they exist in Wikipedia, but in order to cut-and-paste the
>information into my own project, I will need sysop status.

I suspect that Sheldon can be trusted, but there is a more general solution.

In order for Wikipedia to be as open source as possible,
we should change the "Protected page" non-link
that non-administrators see instead of "Edit this page"
to "View this page's source", which will give them
an edit page with no submit button.
Then Sheldon -- or anybody else -- can copy the wiki code.

-- Toby


subject: [Wikipedia-l] Copyright question

in_reply_to: <opriagtfsdk4g8ki@smtp.xtra.co.nz>; from dramatic@xtra.co.nz on Wed, Jan 01, 2003 at 10:33:05AM +1300

body:
I agree with all the other comments.  We don't have to worry about
this very much.  If there is a sentence of introduction, like "Here is
a stupendous and fancy list of the Governors-General of New Zealand,
which we present to you with our most artistic flair" then that
*sentence* could be copyrightable, so we shouldn't use those exact
words.

But the list itself is just facts, and we're on solid ground using
those.

For some types of information, a cite is a courtesy and the
professional thing to do.  But for simple lists of historical facts,
even that is completely unnecessary.  We can get the data from multiple
sources and, ultimately, we should check the data against multiple
sources.  No one owns such.

Richard Grevers wrote:

> What is the situation when you want to include information which is
> essentially in the public domain (e.g. a historical list of the Governors-
> General of NZ) but where all the convenient sources have their own
> copyright notices? Are they in effect copyrighting the information (which I
> would consider to be in the public domain) or just their presentation of
> it?
>
> Happy New Year!
>
> --
> Richard Grevers
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [WikiEN-l] May I be a sysop, please?

body:
On mer, 2003-01-01 at 04:41, Toby Bartels wrote:
> In order for Wikipedia to be as open source as possible,
> we should change the "Protected page" non-link
> that non-administrators see instead of "Edit this page"
> to "View this page's source", which will give them
> an edit page with no submit button.
> Then Sheldon -- or anybody else -- can copy the wiki code.

Seconded...

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Copyright question

body:
What is the situation when you want to include information which is
essentially in the public domain (e.g. a historical list of the Governors-
General of NZ) but where all the convenient sources have their own
copyright notices? Are they in effect copyrighting the information (which I
would consider to be in the public domain) or just their presentation of
it?

Happy New Year!

--
Richard Grevers


subject: [Wikipedia-l] Re: Suggestion to promote readability of hyperlinked documents.

body:
On 31 Dec 2002 19:59:00 +0100, Erik Moeller
<erik_moeller=Mmb7MZpHnFY at public.gmane.org> wrote:

>> I disagree.  On the web, a standard blue underline that turns purple
>> after you visit it is simple and instantly recognizable.
>
> Blue underlined, yes; purple is almost used nowhere these days. CNN,
> Yahoo, Amazon, eBay etc. all don't use it. So the expecation isn't there.
> Blue underlined vs. blue is not such a big difference as to be confusing,
>
> and we *are* a very link-heavy site.
>
To add to the dilemma, Wikipedia has to distinguish between three different
classes of link:
*Wikipedia article
*Non existant Wikipedia Article
*External link
and only for the second of these is Visited status not important. Thus
there need to be five distinct link designations.

Most useability guidelines suggest that visited links should have a less
distinctive marking than unvisited. I tend to use "closer to grey/black" as
less distinctive, e.g. the two link colours for external links ought to
have the same hue (green) but different saturation or lightness/darkness.
I currently find the red to be a little strong (giving missing articles too
much visual weight) and the green a little weak. (using the cologne blue
stylesheet).

With respect to underlining, thought might be given to the following
markup, which will result in a less intrusive underline in good browsers
(IE, unfortunately, still renders dotted as solid):
a.whatever {text-decoration:none; border-bottom: 1px dotted #ddeeff;} (I've
used an arbitrary colour and class here). This also avoids problems where
some browser/font combinations result in underlines striking out the bottom
pixel-row of descenders, which impairs redability.

--
Richard Grevers


subject: [Wikitech-l] On security

body:
Last night someone hacked the password of one of the French Wikipedia
sysops, Youssefsan. (Using IP 217.144.0.5, possibly a proxy?) They don't
appear to have done anything terribly devastating; blanked a few pages
and banned a couple IPs (since restored).

However, under the system that has been in place, it would be trivial
for any sysop to retrieve another user's password hash and use it to log
in by hand-setting the stored password cookie. (Indeed, there is some
concern that one of the other fr users who is a sysop there may be the
troublemaker.)

** Anyone with an account on the French Wikipedia, I recommend you
change your password just in case this guy snagged more. **

I've changed the sysop's SQL query to use a separate mysql user account
which has read-only access and isn't allowed to read the email and
password fields of the user table, which should close the 'malicious
sysop' hole. (However, developers still have full access.)

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Copyright and web cams

body:
I was looking for supplementary material regarding the [[Quetzal]]
article, and ended up with a copyright question.

An organization maintains a web-cam in front of a hummingbird feeder in
Costa Rica.  Most of the time there are no visitors to the feeder.  On
one occasion I find a great specimen has come to feed, and I save the
picture.  Although the owner of the web-cam maintains an archive, I have
made a point not to use an archived picture.

The question:  Does the owner of the web cam have any copyright claim on
the picture that I have downloaded?  I suspect not, because he made no
creative effort to shoot that particular picture.  I would be interested
in other opinions.

Eclecticology


from_name: Zoe

subject: [Wikipedia-l] Copyright question

body:
There have been attempts in the recent past to change US copyright law so that things like sports scores and statistics are copyrighted.  I know the National Basketball Association tried to claim that nobody could report their results without their permission, but that failed.
Zoe
 Brion Vibber <brion at pobox.com> wrote:On mar, 2002-12-31 at 13:33, Richard Grevers wrote:
> What is the situation when you want to include information which is
> essentially in the public domain (e.g. a historical list of the Governors-
> General of NZ) but where all the convenient sources have their own
> copyright notices? Are they in effect copyrighting the information (which I
> would consider to be in the public domain) or just their presentation of
> it?

At least under US copyright law, _knowledge_ is not copyrightable, just
creative work and presentation. A simple list of governors-general, like
a list of names and telephone numbers in a phone book, is not a
substantial creative work. (There is a particular court case on the
matter; I don't recall but you can probably find it somewhere from
http://www.wikipedia.org/wiki/Wikipedia:Copyrights )

I can't speak for New Zealand, but I'd be very surprised if knowledge of
historical facts were subject to copyright. Otherwise, you wouldn't be
allowed to mention anything that you heard about on the radio or TV news
or read about in a newspaper without getting written permission and
paying a relicensing fee... ;)

(IANAL)

-- brion vibber (brion @ pobox.com)

_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030101/3a3eb178/attachment.htm


subject: [Wikipedia-l] Copyright and web cams

body:
How about just including a link to the webcam page from the article?
Zoe
 Erik Moeller <erik_moeller at gmx.de> wrote:> The question: Does the owner of the web cam have any copyright claim on
> the picture that I have downloaded? I suspect not, because he made no
> creative effort to shoot that particular picture. I would be interested
> in other opinions.

Before we look at this interesting question -- is the picture actually of
sufficient quality for Wikipedia? Webcams I've seen so far tended to be
blurry and low-res, but maybe that has changed.

Regards,

Erik
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030101/a1f1b0a1/attachment.htm


subject: [Wikipedia-l] Copyright and web cams

body:
Erik Moeller wrote:

>>The question:  Does the owner of the web cam have any copyright claim on
>>the picture that I have downloaded?  I suspect not, because he made no
>>creative effort to shoot that particular picture.  I would be interested
>>in other opinions.
>>
>
>Before we look at this interesting question -- is the picture actually of
>sufficient quality for Wikipedia? Webcams I've seen so far tended to be
>blurry and low-res, but maybe that has changed.
>
For the purposes of this question we have to assume that the quality is
acceptable.  If it's not worth putting up, then the copyright question
doesn't matter anyway.  Generally I find the quality of the pictures to
be mixed.  Some are adequate to illustrate articles about nature or
volcanoes.

Eclecticology


subject: [Wikipedia-l] Copyright and web cams

body:
Zoe wrote:

> How about just including a link to the webcam page from the article?
>
Birds don't stay at the feeder very long.

Ec


subject: [Wikitech-l] Minor changes to texvc

body:
Already applied to test.wikipedia.org
-------------- next part --------------
diff -ruN orig/lexer.mll neo3/lexer.mll
--- orig/lexer.mll	2002-12-19 15:32:35.000000000 +0100
+++ neo3/lexer.mll	2003-01-01 16:32:19.000000000 +0100
@@ -7,7 +7,8 @@
 let alpha = ['a'-'z' 'A'-'Z']
 let literal_it = ['a'-'z' 'A'-'Z']
 let literal_rm = ['0'-'9']
-let literal_uf = ['+' '-' '*' ',' '=' '(' ')' ':' '/' ';' '?' '.' '!'  '|' '\'' ]
+let literal_uf_lt = [',' '(' ')' ':'  ';' '?' '.' '!' '\'']
+let literal_uf_op = ['+' '-' '*' '=' '/' '|']
 let boxchars  = ['0'-'9' 'a'-'z' 'A'-'Z' '+' '-' '*' ',' '=' '(' ')' ':' '/' ';' '?' '.' '!' ' ' '\128'-'\255']
 let aboxchars = ['0'-'9' 'a'-'z' 'A'-'Z' '+' '-' '*' ',' '=' '(' ')' ':' '/' ';' '?' '.' '!' ' ']

@@ -42,7 +43,8 @@
 				  BOX ("\\vbox", String.sub str n (String.length str - n - 1)) }
   | literal_it			{ let str = Lexing.lexeme lexbuf in LITERAL (HTMLABLEC (FONT_IT, str,str)) }
   | literal_rm			{ let str = Lexing.lexeme lexbuf in LITERAL (HTMLABLEC (FONT_RM, str,str)) }
-  | literal_uf			{ let str = Lexing.lexeme lexbuf in LITERAL (HTMLABLEC (FONT_UFH, str,str)) }
+  | literal_uf_lt		{ let str = Lexing.lexeme lexbuf in LITERAL (HTMLABLEC (FONT_UFH, str,str)) }
+  | literal_uf_op		{ let str = Lexing.lexeme lexbuf in LITERAL (HTMLABLEC (FONT_UFH, str," "^str^" ")) }
   | "\\" alpha + 		{ Texutil.find (Lexing.lexeme lexbuf) }
   | "\\sqrt" space * "["	{ FUN_AR1opt "\\sqrt" }
   | "\\," 			{ LITERAL (HTMLABLE (FONT_UF, "\\,"," ")) }
@@ -57,6 +59,8 @@
   | "\\%"			{ LITERAL (HTMLABLE (FONT_UFH,"\\%","%")) }
   | "&"				{ NEXT_CELL }
   | "\\\\"			{ NEXT_ROW }
+  | "\\begin{matrix}"		{ Texutil.tex_use_ams(); BEGIN__MATRIX }
+  | "\\end{matrix}"		{ END__MATRIX }
   | "\\begin{pmatrix}"		{ Texutil.tex_use_ams(); BEGIN_PMATRIX }
   | "\\end{pmatrix}"		{ END_PMATRIX }
   | "\\begin{bmatrix}"		{ Texutil.tex_use_ams(); BEGIN_BMATRIX }
@@ -67,8 +71,8 @@
   | "\\end{vmatrix}"		{ END_VMATRIX }
   | "\\begin{Vmatrix}"		{ Texutil.tex_use_ams(); BEGIN_VVMATRIX }
   | "\\end{Vmatrix}"		{ END_VVMATRIX }
-  | '>'				{ LITERAL (HTMLABLEC(FONT_UFH,">",">")) }
-  | '<'				{ LITERAL (HTMLABLEC(FONT_UFH,"<","<")) }
+  | '>'				{ LITERAL (HTMLABLEC(FONT_UFH,">"," > ")) }
+  | '<'				{ LITERAL (HTMLABLEC(FONT_UFH,"<"," < ")) }
   | '%'				{ LITERAL (HTMLABLEC(FONT_UFH,"\\%","%")) }
   | '~'				{ LITERAL (HTMLABLE (FONT_UF, "~"," ")) }
   | '['				{ LITERAL (HTMLABLEC(FONT_UFH,"[","[")) }
diff -ruN orig/parser.mly neo3/parser.mly
--- orig/parser.mly	2002-12-21 13:55:52.000000000 +0100
+++ neo3/parser.mly	2003-01-01 15:57:42.000000000 +0100
@@ -10,8 +10,8 @@
 %token <string*(Tex.t->Tex.t->string*string*string)> FUN_AR2h
 %token <string*(Tex.t list->Tex.t list->string*string*string)> FUN_INFIXh
 %token EOF CURLY_OPEN CURLY_CLOSE SUB SUP SQ_CLOSE NEXT_CELL NEXT_ROW
-%token BEGIN_PMATRIX BEGIN_BMATRIX BEGIN_BBMATRIX BEGIN_VMATRIX BEGIN_VVMATRIX
-%token END_PMATRIX END_BMATRIX END_BBMATRIX END_VMATRIX END_VVMATRIX
+%token BEGIN__MATRIX BEGIN_PMATRIX BEGIN_BMATRIX BEGIN_BBMATRIX BEGIN_VMATRIX BEGIN_VVMATRIX
+%token END__MATRIX END_PMATRIX END_BMATRIX END_BBMATRIX END_VMATRIX END_VVMATRIX

 %type <Tex.t list> tex_expr
 %start tex_expr
@@ -74,6 +74,7 @@
 				{ TEX_INFIX($3,$2,$4) }
   | CURLY_OPEN ne_expr FUN_INFIXh ne_expr CURLY_CLOSE
 				{ let t,h=$3 in TEX_INFIXh(t,h,$2,$4) }
+  | BEGIN__MATRIX  matrix END__MATRIX	{ TEX_MATRIX ("matrix", $2) }
   | BEGIN_PMATRIX  matrix END_PMATRIX	{ TEX_MATRIX ("pmatrix", $2) }
   | BEGIN_BMATRIX  matrix END_BMATRIX	{ TEX_MATRIX ("bmatrix", $2) }
   | BEGIN_BBMATRIX matrix END_BBMATRIX	{ TEX_MATRIX ("Bmatrix", $2) }
diff -ruN orig/texutil.ml neo3/texutil.ml
--- orig/texutil.ml	2002-12-21 14:39:10.000000000 +0100
+++ neo3/texutil.ml	2003-01-01 16:28:23.000000000 +0100
@@ -58,10 +58,12 @@
   | TEX_FUN1hf (_,ff,a)::r -> (html_render_flat (new_ctx ff) [a])^html_render_flat ctx r
   | TEX_DECLh (_,ff,a)::r -> (html_render_flat (new_ctx ff) a)^html_render_flat ctx r
   | TEX_CURLY ls::r -> html_render_flat ctx (ls @ r)
-  | TEX_DQ (a,b)::r  -> (let bs = html_render_flat ctx [b] in match html_render_size ctx a with
+  | TEX_DQ (a,b)::r  -> (html_conservative := false;
+			 let bs = html_render_flat ctx [b] in match html_render_size ctx a with
 		         true, s -> raise Too_difficult_for_html
 		       | false, s -> s^""^bs^"")^html_render_flat ctx r
-  | TEX_UQ (a,b)::r  -> (let bs = html_render_flat ctx [b] in match html_render_size ctx a with
+  | TEX_UQ (a,b)::r  -> (html_conservative := false;
+		         let bs = html_render_flat ctx [b] in match html_render_size ctx a with
 		         true, s ->  raise Too_difficult_for_html
 		       | false, s -> s^""^bs^"")^html_render_flat ctx r
   | TEX_FQ (a,b,c)::r -> (html_conservative := false;
@@ -307,6 +309,9 @@
     | "\\hookleftarrow"    -> LITERAL (TEX_ONLY "\\hookleftarrow ")
     | "\\mp"               -> LITERAL (TEX_ONLY "\\mp ")
     | "\\approx"           -> LITERAL (TEX_ONLY "\\approx ")
+    | "\\flat"             -> LITERAL (TEX_ONLY "\\flat ")
+    | "\\sharp"            -> LITERAL (TEX_ONLY "\\sharp ")
+    | "\\natural"          -> LITERAL (TEX_ONLY "\\natural ")
     | "\\int"	           -> LITERAL (HTMLABLE_BIG ("\\int ", "∫"))
     | "\\sum"	           -> LITERAL (HTMLABLE_BIG ("\\sum ", "∑"))
     | "\\prod"	           -> LITERAL (HTMLABLE_BIG ("\\prod ", "∏"))


subject: [Wikipedia-l] Re: Copyright question

body:
Richard Grevers wrote:

> It certainly shouldn't be a problem in New Zealand. A year or two ago
> we were heading towards such a relaxed copyright law (academic
> institutions were to be allowed to copy quite freely) that
> International textbook publishers were threatening to make their books
> unavailable in New Zealand. I've never actually heard whether that law
> change was defeated.

> Inceidentally (and heading OT), many books published in Britain in the
> middle of last century carried the rider "for Copyright reasons this
> edition may not be sold in the US and Canada". Does anyone know
> thether this was because there were separate territorial publishing
> deals, or because of lower legal protection in US/Canada?

A lot of that did have to do with publishing deals.  At that time United
States copyright law was linked to a requirement that if any more than
10,000 copies of a book were to be distributed in the United States they
had to be printed there.  To deal with this Penguin set up a printing
plant in Baltimore.  In North America publishers have often thought of
the continent as one big playground, which explains why Canada is often
included in these.  Canada has tended to give special protection to
distribution arrangements that give companies who can't make a living by
publishing their own books a chance to prosper from middlemen's
commissions.  This gets involved in some sensitive issues in Canada.
 Cultural domination is a consideration for many Canadians.  New
Zealanders at least have the protection of a significant expanse of sea
between themselves and Australia.

Eclecticology


subject: [Wikitech-l] Something just broke with character references.

body:
Inside ampersands that are part of character references inside <pre> ...
</pre> are now being translated to & as though they're not a part of an
explicit character reference.  I'm experiencing this at [[m:Wikitax]].

For example, try doing:

    <pre>
    <pre> ... </pre>
    </pre>

Okay, I'm done now,

Derek

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus


subject: [Wikitech-l] Re: Suggestion to promote readability of hyperlinked documents.

body:
>Cologne Blue is much nicer.
>I think it should be default on other Wikipedias too.

I'm runnin' XFree86 4.2 using Mozilla 1.2.1 at a resolution of 1024x768 on a
21-inch Sony Trinitron monitor.  I think the font sizes in Cologne Blue
could stand to be a bit bigger, especially with regard to the menu on the
left.  I have a huge freakin' monitor, and I'm only runnin' at 1024x768 (to
get DRI), so one would think the fonts shouldn't be as small as they're
seeming to be.  I've attached a screenshot if anyone is interested.

The Nostalgia theme is just god awful.  *grin*

I /really/ like the default theme.

Okay, I'm done now,

Derek

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CologneBlueScreenshot.png
Type: image/png
Size: 45276 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030101/5081836e/attachment.png>


subject:
[Wikitech-l] Re: Suggestion to promote readability of
	hyperlinked documents.

body:
On ?a?, 2003-01-02 at 17:54, Daniel Mayer wrote:
> Why is the default skin on eo set to Cologne blue?

I like it better, and our folks seemed favorable to the change. The
question is, why are the rest of you guys behind the times? ;)

-- brion vibber (brion @ pobox.com)


body:
On mer, 2003-01-01 at 19:08, Derek Moore wrote:
> Inside ampersands that are part of character references inside <pre> ...
> </pre> are now being translated to & as though they're not a part of an
> explicit character reference.  I'm experiencing this at [[m:Wikitax]].

Should be back.

While fixing other things, I accidentally overwrote OutputPage.php with
the (partially) tex-enabled version, which apparently handles <pre> tags
in a broken way. I'll go fix that.

-- brion


body:
On mer, 2003-01-01 at 19:30, Derek Moore wrote:
> I think the font sizes in Cologne Blue
> could stand to be a bit bigger, especially with regard to the menu on the
> left.

What do you think of the version I've just put on test.wikipedia.org
which doesn't change your browser's font selection and uses only
relative font sizes?

(Aside from "the sidebar's way too frelling long", which is true. It
needs refactoring.)

-- brion vibber (brion @ pobox.com)