from_name: Brion Vibber

subject:
Encoding for non-Latin1 wikipedias (was Re: [Wikitech-l] New case
	conversion functions)

body:
(I'm cross-posting this to intlwiki-l; for those who have not been
reading wikitech-l, there's been some recent debate about how to encode
non-Latin1 characters using the new PHP-based wikipedia software. In
summary:
 * I had been preparing to convert the Esperanto wiki to the new
software, under the assumption of continuity with the old software in
which native character encodings were used: UTF-8 on eo.wikipedia.com,
ISO-8859-2 on pl.wikipedia.com, etc.
 * Lee Crocker claimed that the plan all along was actually to use
ISO-8859-1 with HTML character entities for all wikis, so that users
could easily cut and paste text between wikis with different languages.
 * I pointed out that this had never been implemented on the wikis that
are being actively used, and there were obvious problems with that plan
for people who were going to edit text in non-Latin languages; 100%
HTML-entity text is not very legible.
 * Jan Hidders recommended the possibility of checking what character
encoding the browser preferred, and based on that specially converting
those character entities in the current encoding to display as normal
characters in the edit box. )

On sab, 2002-02-23 at 08:24, Jan Hidders wrote:
>
> From: "Brion Vibber" <brion at pobox.com>
> > On ven, 2002-02-22 at 02:33, Jan Hidders wrote:
> > >
> > > No, no, of course not.  What I meant was that we check what the display
> > > character encoding (I said character set, but that is probably not the
> right
> > > word) is that is given with the request. [....]
> >
> > (Not necessarily, just lots of transliteration tables. Or perhaps
> > compile in iconv support... does iconv allow partial transliteration
> > between HTML entities and other character sets? ie, HTML entities that
> > are not in the destination charset are left intact?)
>
> Ah, I didn't know iconv. My guess would be that it doesn't know about
> entities because the default behaviour should be that it doesn't and I don't
> see any flags to indicate that it should.
>
> > > The nice thing about this would be that you can cut'n paste anything
> from
> > > any other Wikipedia by cutting it from the edit box.
> >
> > If I understand correctly, you're suggesting that the default character
> > encoding should *not* be based on the language used, but on some ability
> > of the browser to specify a preferred encoding (for instance, the HTTP
> > Accept-Charset header), such that the same user would see wikipedias in
> > different languages come up with the same character encoding?
>
> Yes, and the accept-charset header is indeed the meta-tag I was thinking of.

Does it vary appropriately with the default language of the browser? I
tried a few browsers on my system (US English or non-specific versions)
and got:

Mozilla 0.9.8: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Konqueror: unicode, utf-8, *
Netscape 4.78: iso-8859-1,*,utf-8
Opera 6: windows-1252;q=1.0, utf-8;q=1.0, utf-16;q=1.0,iso-8859-1;q=0.6, *;q=0.1
Internet Explorer 5.0: (nothing)
lynx: (nothing)

Could people using other languages check what they get? I set up a quick
little script to check the relavant headers and spit them out:
http://leuksman.com/misc/charset.php

In the case of multiple supported encodings, do we use the first one, or
the "best" one?

With regards to L. Crocker's earlier comment about UTF-8 being
potentially problematic with older browsers; after checking the
Accept-Charset field we *know* that a browser supports UTF-8, and can
provide an alternate, more limited, encoding if not.

That, I think, would be my personal preference.

While I'm at it -- if instead of HTML entities we were to use UTF-8
internally, we could get around the search problem by simply changing
high characters in the fulltext index to hex codes. If we're already
converting things right and left, there's little advantage to using the
entities internally -- particularly if most users have nice, modern
browsers with Unicode support and thus require no other conversion.

> > I'm not convinced that the default value of that would always (or even
> > often) be acceptable, and most users won't know how to change it.
>
> Can you give an example? What is at the moment the behaviour of the
> Esperanto Wikipedia?

The current behavior that you'll find on visiting eo.wikipedia.com
(running the old software):
- Article contents, titles, comments, user interface messages, etc. are
shown in UTF-8.
- The article edit box is in limited UTF-8, with the standard diacritics
transliterated (X-system)
- Any input (edit box, comment field, search box, username) is
internally normalised to X-system, so users can type any way they wish.
- On selecting a convenient link at the top of the screen, article
contents, user interface messages etc. are optionally shown in X-system.
The user does not have to log in to do this, just as he/she does not
have to create a named user account to set any other preferences in the
usemod wiki, however cookies are required.

As currently sitting in the CVS repository for the new software, the
only significant differences are:
- Full UTF-8 is used internally instead of X-system
- Since preferences can't be set without creating a user account,
cookies aren't saved for the encoding preference of not-logged-in users.

> > Simple, obvious at first sight manual switching between UTF-8 and a
> > standard transliteration format is a non-negotiable requirement for the
> > Esperanto 'pedia, so retaining the manual override is necessary.
>
> Of course, users will still be able to choose their encoding (provided they
> log in). Note that I was only talking about the editable boxes such as the
> edit box and the search box. It makes sense to me to ask people to log in if
>  they want special behavior there. The encoding for presentation of pages is
> another matter that can be decided separately.

Okay, but what's "special behavior" and what's "default behavior"? Say I
visit the Japanese wikipedia, the French wikipedia, and the Esperanto
wikipedia; is using a native encoding for native editing in each one
"special behavior"? Or is using a common encoding for all "special
behavior"?

I find the login process on the new software way too heavy and
intimidating, so I'm loathe to require people to do it just to change
one tiny option.

> > > > cf $wikiRecodeInput(), $wikiRecodeOutput() if you want a ready place
> to
> > > > do this.
> > >
> > > It doesn't have the right arguments. But these are implementation
> details.
> > > We first should agree on the architecture.
> >
> > There's no character set argument because that's a global variable. At
> > present $wikiCharset specifies the default encoding (that used in the
> > database),
>
> Ok, then it would be the right place. But note that for indexing reasons the
> meaning of the variable that you gave can no longer be correct. The encoding
> in the database *has*  to be different from the representation in the edit
> box and there may even be another encoding used for representing the page.

Right, it can change as necessary. Whatever happens, though, we still
need the custom transliteration functions available for the X-system
conversion. Those users without special keyboard drivers (or worse yet,
with Netscape 4's Unicode support) need to be able to type and sometimes
read that way. HTML entities are unacceptably difficult for typing, and
not helpful for reading -- a browser that doesn't show the UTF-8 won't
do any better with the entities.

-- brion vibber (brion @ pobox.com)


list: wikipedia-l

source: pipermail-mbox

from_name: Larry Sanger

subject: [Wikipedia-l] subpages

body:
Please--let's not get into this again.  We haven't even given a
subpageless Wikipedia the old college try yet.

Larry


subject: [Wikipedia-l] colons

body:
While I have to agree that it would be nicer to have the use of colons in
titles, I don't think it would be better to have "content:" preceding
every Wikipedia title.  Colonless page titles could be automatically
converted to content: titles (so that [[foo]] would be saved automatically
as [[content:foo]]), but it would make the system more complicated and
more importantly it would make the titles and the URLs uglier.

This is really more of a technical issue than a policy one.  I mean, from
a policy standpoint, it's great to have the use of colons in titles.  If
there aren't any technical objections, we should do it.  But, of course,
there might be technical objections.  (Cc'ing wikitech-l.)

Larry

> > > Thus instead of the ":" being a reserved character anywhere in a
> > > title, only "user:", "talk:", "wikipedia:" etc. need to be
> > > reserved. Any other uses of colons should be fine. This will let us
> > > have entries for books with standard formatting of the subtitle (e.g.,
> > > "The Muggles: A Tale of Woe") or other natural uses of the colon.
> >
> > There is a simpeler solution. The actual contents of Wikipedia get the
> > namespace "content:". If everything is prefixed with a namespace then the
> > first colon is always the end of the namespace.
> >
> That's perfect.


list: wikitech-l

subject: [Wikitech-l] Re: [Wikipedia-l] colons


subject: [Wikipedia-l] Uploads being abused

body:
On Mon, 25 Feb 2002, Robert Graham Merkel wrote:

> It seems to me from following the upload queue that it is
> being deliberately abused to store distinctly non-encyclopedia
> and copyright-infringing material on a disconcertingly large scale.

I agree 100% that this is a problem.  Last night I deleted several dozen
files that someone had overwritten as being (obviously) inappropriate for
Wikipedia articles.  I was a little concerned from the beginning that
having virtually no restrictions on the upload function would have this
effect, so it's not too surprising that this is happening.

> I would assume that this would be of direct financial concern
> to Bomis, both for the potential of large bandwidth costs and
> the potential for being sued, and to the rest of the project
> because of the risk of being shut down by a lawsuit.

Although not a huge financial concern, but I'd agree the risk is there...

> Are we just going to attempt to keep this under control by
> the vigilance of a few dedicated Wikipedians, or might, in this
> case, some technical measures to discourage abuse be appropriate?
>
> For instance, it might be feasible to restrict uploads to registered
> users, limiting the size and number of files that a user can upload in
> a day, perhaps even restricting the types of files that can be uploaded by
> checking with the "file" file type checking utility - that would at least
> prevent the uploading of executables).

I like all of these ideas.  Certainly in any case only registered users
should be able to upload files.  This seems a reasonable thing to ask,
given the potential for abuse that the file uploader represents.  Right
now, I can't even spot a miscreant's IP address by looking at the log.

> I would be prepared to help implement some of the above.  I'm a decent
> programmer, though I don't have any experience with PHP so it'd take me
> some time to get up to speed.
>
> Obviously, I think technical measures to slow things is
> justified in this case, otherwise I suspect too much time will
> be wasted weeding out rather noxious material.

I don't think that the technical measures you propose will slow very much
at all down.  The only person who might upload beyond a given size limit
would be Magnus.  :-)  I imagine that there is hardly anyone who (1)
refuses to sign in but who (2) wants to upload a useful file (e.g., a
public domain photo for a biography).

I don't know if the specific proposals you make are the best, but I agree
that something along these lines should be done.

Larry


from_name: kband at www.llamacom.com

subject: [Wikipedia-l] Re:colons

in_reply_to: <3C7AA032.14793.1C2D4D@localhost> from "Graham Chapman" at Feb 25, 2002 08:36:02 PM

body:
>
> Bad idea - you don't know what namespaces you want to use in
> future.
>
So? I rather suspect the number of desired namespaces is a
lot more limited than the number of entries that could use
colons, and I doubt that there would be any overlap, especially
since we're free to engineer nonsense-named namespaces.

It's an imperfect idea, but making colons reserved is just as
bad, if not worse, than making slashes reserved. There are
more times a colon would be used in a title than a slash.

I.e. making colons reserved is a bad idea too. We should
consider the thought of unreserving them.

For example, one thought is that only in the case of namespaces
would you find the match to
[a-z]+:\w    ("wikipedia:FAQ")

since normal English use of colons only matches

\w: \w or \d:\d ("Alan Turing: The Enigma" or "4:25")

Are there any counter examples?


subject: [Wikipedia-l] colons

body:
>
> From: <kband at www.llamacom.com>
> >
> > Thus instead of the ":" being a reserved character anywhere in a
> > title, only "user:", "talk:", "wikipedia:" etc. need to be
> > reserved. Any other uses of colons should be fine. This will let us
> > have entries for books with standard formatting of the subtitle (e.g.,
> > "The Muggles: A Tale of Woe") or other natural uses of the colon.
>
> There is a simpeler solution. The actual contents of Wikipedia get the
> namespace "content:". If everything is prefixed with a namespace then the
> first colon is always the end of the namespace.
>
That's perfect.


from_name: Brion L. VIBBER

subject:
[Intlwiki-l] Re: Encoding for non-Latin1 wikipedias (was Re:
	[Wikitech-l] New caseconversion functions)

body:
On lun, 2002-02-25 at 07:55, Jan Hidders wrote:
>
> From: "Brion Vibber" <brion at pobox.com>
> > On sab, 2002-02-23 at 08:24, Jan Hidders wrote:
> > >
> > > Yes, and the accept-charset header is indeed the meta-tag I was thinking
> of.
> >
> > Does it vary appropriately with the default language of the browser? I
> > tried a few browsers on my system (US English or non-specific versions)
> > and got:
> >
> > Mozilla 0.9.8: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> > Konqueror: unicode, utf-8, *
> > Netscape 4.78: iso-8859-1,*,utf-8
> > Opera 6: windows-1252;q=1.0, utf-8;q=1.0, utf-16;q=1.0,iso-8859-1;q=0.6,
> *;q=0.1
> > Internet Explorer 5.0: (nothing)
> > lynx: (nothing)
>
> FWIW, I tried it with nl-be and as you would expect it is the same for
> Netscape and Explorer as above. I'll try what happens if I turn on
> multilanguage-support in Windows.
>
> > In the case of multiple supported encodings, do we use the first one, or
> > the "best" one?
>
> I would say the best one with. The only reason not do so is to show users
> how to write certain characters as entities, but if somebody decides to edit
> a page on the Russian Wikipedia we might expect that this person knows how
> to enter Cyrillic characters on his or her keyboard, or either knows how to
> enter them as entities. I'm not sure about when q!=1.0 for the best one.

Besides, if they would benefit from seeing the entities, they would
benefit just as well from cut-n-paste, wouldn't they? Who's really going
to memorise the numbers?

> > With regards to L. Crocker's earlier comment about UTF-8 being
> > potentially problematic with older browsers; after checking the
> > Accept-Charset field we *know* that a browser supports UTF-8, and can
> > provide an alternate, more limited, encoding if not.
> >
> > That, I think, would be my personal preference.
>
> Mine too.
>
> > While I'm at it -- if instead of HTML entities we were to use UTF-8
> > internally, we could get around the search problem by simply changing
> > high characters in the fulltext index to hex codes.
>
> Just to be clear on this. If we want indexing to work we need to encode it
> in a format that uses only the Latin 1 numbers, letters, "_" and "'". The
> alternative is to run different MySQL servers with appopriate character sets
> for different Wikipedias.

> > > Can you give an example? What is at the moment the behaviour of the
> > > Esperanto Wikipedia?
> >
> > The current behavior that you'll find on visiting eo.wikipedia.com
> > (running the old software):
> > - Article contents, titles, comments, user interface messages, etc. are
> > shown in UTF-8.
> > - The article edit box is in limited UTF-8, with the standard diacritics
> > transliterated (X-system)
> > - Any input (edit box, comment field, search box, username) is
> > internally normalised to X-system, so users can type any way they wish.
> > - On selecting a convenient link at the top of the screen, article
> > contents, user interface messages etc. are optionally shown in X-system.
>
> Ok. I see your point. Does this also work for Windows users?

Yes, it works for everybody.

> > Okay, but what's "special behavior" and what's "default behavior"? Say I
> > visit the Japanese wikipedia, the French wikipedia, and the Esperanto
> > wikipedia; is using a native encoding for native editing in each one
> > "special behavior"? Or is using a common encoding for all "special
> > behavior"?
>
> I would say that the default behaviour is that you see in the edit box the
> best character encoding your browser accepts. If the browser doesn't specify
> this then the site falls back to Latin1 or whatever is specified as
> $defaultEncoding on that site.

Sounds reasonable to me.

> > [...] Whatever happens, though, we still
> > need the custom transliteration functions available for the X-system
> > conversion. Those users without special keyboard drivers (or worse yet,
> > with Netscape 4's Unicode support) need to be able to type and sometimes
> > read that way.
>
> By the way, is this specified in the charset with the POST?

There's no real way to get that information, to my knowledge. This
particular conversion is clean enough that it can be run over any input
the user gives, though, so my preference would be to just keep filter
functions available over all editable text.

> > HTML entities are unacceptably difficult for typing, and
> > not helpful for reading -- a browser that doesn't show the UTF-8 won't
> > do any better with the entities.
>
> My main interest is that we maintain 1 software package that can be adapted
> by setting some variables and includes. If we really cannot get around
> having extra special encoding-links that can be turned off or on depending
> upon some variables, then so be it.

Agreed, which is why I added the little recoding functions in the first
place. They wouldn't be needed most of the time, but when they were, a
function or two could be dropped in with the localised messages.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] subpages

body:
>
> From: <kband at www.llamacom.com>
> >
>
> > I think we should have subpage functionality (or modify the namespace
> > functionality) to help with pages such as the September 11 pages.
> > The current situation is a step back from the earlier software.
>
> I disagree. It will lead to more self-contained articles about things like
> the hijackers, which is what we want in this encyclopedia.
>

What exactly do you mean? As the one who made pretty much all the
Sept.  11 pages, I can tell you that the subpage functionality made it
much easier--I certainly wouldn't have been able to deal with all of
the information in there if I didn't make some kind of subpagery. I'm
certainly not tied to the particular implementation of the UseModWiki,
but the ability to generate pages tied into another page without
having to type the entire title every time is extremely useful.

-TC


from_name: Jimmy Wales

subject: [Wikitech-l] Updating the database schema

body:
O.k., I'm going to install the latest software.  What do I need to do,
in order to update the database schema before I install the new version?

--Jimbo


subject: [Wikipedia-l] personal subpages / protected homepage

body:
On Mon, 25 Feb 2002, Chuck Smith wrote:

> >From what I remember from Wikipedia-L, I thought we
> were going to continue to allow subpages on personal
> pages and ditch them on the regular wikipedia.  Are
> there any plans to put them back in on personal pages?

Don't know.

> Also, when are you going to give back privileges to
> edit the Homepage to trusted users?  I made it my
> responsibility to update the new language wikipedias
> when they came in and now I can't.  I think an
> unprotected homepage is better than a protected
> homepage that only two people can edit... now that's a
> cabal!

Well, there was originally a "can-edit-the-homepage" cabal :-) consisting
of about a dozen people, but they all had sysop privileges as well, which
was, er, not to "diss" any of the people in question, maybe a little
dangerous.

Y'know, I think a sensible thing to do would be to make all registered
users members of a "can-edit-the-homepage" cabal, which makes it no longer
a cabal.  This would prevent almost all homepage vandalism.

Programmers, am I asking for too much here?  Or is there a better way?

Larry


subject: [Wikipedia-l] colons

body:
On Mon, 25 Feb 2002, Jan Hidders wrote:

> From: "Magnus Manske" <Magnus.Manske at epost.de>
>
> > The original software *did* stay within the current namespace if no other
> > was explicitly given. So, "[[test]]" on the page "[[user:Magnus Manske]]"
> > did link to "[[user:test]]" instead of "[[test]]". At that time, I still
> > planned a "stable:" namespace for approved articles, which would
> > automatically link only to other stable articles.
>
> It's already there? So all we would have to do is take care that the
> content: namespace doesn't show up in the title? (Plus change some
> code that assumes that any title that contains a ":" is not content.)
> Can I, can I, can I? Please? :-) As far as I can see this actually
> makes the code simpeler because titles will always have the same
> format.

Let's consider some arguments though on both sides.  Let's think it
through!

Larry


subject: [Wikipedia-l] Uploader requirements

body:
We just never gave the programmers a good set of requirements for the
uploader.

On Mon, 25 Feb 2002, Lars Aronsson wrote:

> Larry Sanger wrote:
> > I agree 100% that this is a problem.  Last night I deleted several dozen
> > files that someone had overwritten as being (obviously) inappropriate for
> > Wikipedia articles.  I was a little concerned from the beginning that
> > having virtually no restrictions on the upload function would have this
> > effect, so it's not too surprising that this is happening.
>
> >From a general, Wiki-philosophical-social aspect, it is interesting
> that the upload function gets abused, while general Wiki pages do not.

Actually, there's a good reason for it: the images aren't obviously linked
to anything in any article.  This is an ABSOLUTELY essential piece of
information to have: what articles *use* the image in question?  If no
article uses an image after 24 hours, perhaps we should delete the image
(or put it in a queue to be deleted by a human).  So, the point is,
without a context, unless some image is at face value obviously worthless
to any Wikipedia article (e.g., porn advertisements), it's difficult for
us to tell whether an image really is appropriate for the 'pedia.  It
would even make it easier for us to determine whether an image is
copyrighted.

One way around this would be to attach images to unique articles, so that
the uploading of an image would be logged in a particular article's
history.  I don't know if I like this suggestion, though, I'm just
throwing it out there for your consideration.

Here's another thing we need in that upload form.  We should ask people to
choose: (1) I have created this image and release it under the GNU FDL (or
contribute it to Wikipedia); (2) I personally certify that this image is
public domain (if checked, add a text box requiring that a source be
given--a URL or else a book title, say); (3) other?  If none are checked,
then the uploader wouldn't accept the article.

Under some schemes we might want (1) to require that the uploader identify
which article the image is going to be used in, and (2) to check that the
image title is linked to from that article.  But (1) might be done
automatically, I guess...

Doing these things would remove a fair bit of the abuse.  It would
certainly make it a lot easier for the community to act as a check on the
abuse.

> Perhaps the uploads should be visible in the RecentChanges list?

They already are, sort of--but each one individually should be, which
isn't the case now.

> Perhaps there should be a "view other versions" for each upload?

Maybe--would prevent people from uploading porn in place of legit images,
for instance.

> Perhaps a Wikipage in the upload: namespace for each uploaded object?

Maybe...?

Larry


subject: [Wikitech-l] Uploader requirements


from_name: Vicki Rosenzweig

subject: [Wikipedia-l] colons

body:
At 09:56 AM 2/25/02 -0600, kband wrote:
> >
> > From: <kband at www.llamacom.com>
> > >
> > > Thus instead of the ":" being a reserved character anywhere in a
> > > title, only "user:", "talk:", "wikipedia:" etc. need to be
> > > reserved. Any other uses of colons should be fine. This will let us
> > > have entries for books with standard formatting of the subtitle (e.g.,
> > > "The Muggles: A Tale of Woe") or other natural uses of the colon.
> >
> > There is a simpeler solution. The actual contents of Wikipedia get the
> > namespace "content:". If everything is prefixed with a namespace then the
> > first colon is always the end of the namespace.
> >
>That's perfect.

Would this require us to explicitly put "content:" in front of every link?

If so, I doubt it would work--people would forget, because it's not intuitive.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


from_name: Jan Hidders

subject: [Wikipedia-l] subpages

body:
From: <kband at www.llamacom.com>
>

> I think we should have subpage functionality (or modify the namespace
> functionality) to help with pages such as the September 11 pages.
> The current situation is a step back from the earlier software.

I disagree. It will lead to more self-contained articles about things like
the hijackers, which is what we want in this encyclopedia.

-- Jan Hidders


subject: [Wikipedia-l] colons

body:
From: <kband at www.llamacom.com>
>
> Thus instead of the ":" being a reserved character anywhere in a
> title, only "user:", "talk:", "wikipedia:" etc. need to be
> reserved. Any other uses of colons should be fine. This will let us
> have entries for books with standard formatting of the subtitle (e.g.,
> "The Muggles: A Tale of Woe") or other natural uses of the colon.

There is a simpeler solution. The actual contents of Wikipedia get the
namespace "content:". If everything is prefixed with a namespace then the
first colon is always the end of the namespace.

-- Jan Hidders


subject: [Wikipedia-l] Re: [Wikitech-l] Uploader requirements

body:
On lun, 2002-02-25 at 11:16, Larry Sanger wrote:
> On Mon, 25 Feb 2002, Lars Aronsson wrote:
> > >From a general, Wiki-philosophical-social aspect, it is interesting
> > that the upload function gets abused, while general Wiki pages do not.
>
> Actually, there's a good reason for it: the images aren't obviously linked
> to anything in any article.  This is an ABSOLUTELY essential piece of
> information to have: what articles *use* the image in question?  If no
> article uses an image after 24 hours, perhaps we should delete the image
> (or put it in a queue to be deleted by a human).

At the moment, though, the non-English wikipedias don't have their own
upload capabilities. Images that are used on the other wikis thus tend
to end up uploaded to www.wikipedia.com or meta.wikipedia.com without
necessarily being used where they were uploaded (especially diagrams and
maps with language-specific names, descriptions, etc).

So please, don't delete my Esperantized maps. :)

>  So, the point is,
> without a context, unless some image is at face value obviously worthless
> to any Wikipedia article (e.g., porn advertisements), it's difficult for
> us to tell whether an image really is appropriate for the 'pedia.  It
> would even make it easier for us to determine whether an image is
> copyrighted.
>
> One way around this would be to attach images to unique articles, so that
> the uploading of an image would be logged in a particular article's
> history.  I don't know if I like this suggestion, though, I'm just
> throwing it out there for your consideration.

I'm not quite sure how to go about doing that.

What could be done though that may be useful, is to add a link to a
"pages that link to this file" function next to each name in the
uploaded file list. A start, at least, though it doesn't cover the
multi-wiki problem.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Uploader requirements


from_name: Chuck Smith


body:
>
> On Mon, 25 Feb 2002, Chuck Smith wrote:
>
> > >From what I remember from Wikipedia-L, I thought we
> > were going to continue to allow subpages on personal
> > pages and ditch them on the regular wikipedia.  Are
> > there any plans to put them back in on personal pages?
>
> Don't know.

That would be nice.
>
> > Also, when are you going to give back privileges to
> > edit the Homepage to trusted users?  I made it my
> > responsibility to update the new language wikipedias
> > when they came in and now I can't.  I think an
> > unprotected homepage is better than a protected
> > homepage that only two people can edit... now that's a
> > cabal!
>
> Well, there was originally a "can-edit-the-homepage" cabal :-) consisting
> of about a dozen people, but they all had sysop privileges as well, which
> was, er, not to "diss" any of the people in question, maybe a little
> dangerous.

Were there ever any actual incidents where this was a problem? If there
were, it should be made public.
>
> Y'know, I think a sensible thing to do would be to make all registered
> users members of a "can-edit-the-homepage" cabal, which makes it no longer
> a cabal.  This would prevent almost all homepage vandalism.

That's a good idea.


subject: [Wikipedia-l] colons

body:
>
> At 09:56 AM 2/25/02 -0600, kband wrote:
> > >
> > > From: <kband at www.llamacom.com>
> > > >
> > > > Thus instead of the ":" being a reserved character anywhere in a
> > > > title, only "user:", "talk:", "wikipedia:" etc. need to be
> > > > reserved. Any other uses of colons should be fine. This will let us
> > > > have entries for books with standard formatting of the subtitle (e.g.,
> > > > "The Muggles: A Tale of Woe") or other natural uses of the colon.
> > >
> > > There is a simpeler solution. The actual contents of Wikipedia get the
> > > namespace "content:". If everything is prefixed with a namespace then the
> > > first colon is always the end of the namespace.
> > >
> >That's perfect.
>
> Would this require us to explicitly put "content:" in front of every link?
>
> If so, I doubt it would work--people would forget, because it's not intuitive.

It's not just not intuitive, it makes the user's life harder, and technology
should work the other way around--put the burden on the programmers,
not the users (editors).

Yeah, I realized this too a little later. It's immaterial from a user
perspective what happens behind the stage; the problem is to match
user practices with parsability.

Which gets us back to setting up standards for parsable colon usage,
which is probably a mostly Wikitech-L issue, if we agree that it's
worth it to try to find a way to make colons a (by and large) non-reserved
character in titles (and I think we do).

-TC


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] subpages

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020225/0d30376d/attachment.diff


subject: [Wikipedia-l] colons

body:
>
> From: "Larry Sanger" <lsanger at nupedia.com>
> >
> > Let's consider some arguments though on both sides.  Let's think it
> > through!
>
> Don't worry. I won't change any code unless I have a feeling there is a
> consensus about this. But by now I have programmed most of the SQL that
> deals with this and I think I have a reasonable insight in what the
> consequences are from a technical point of view. From the users point of
> view not much changes (unless we want to) except that the namespace-feature
> that keeps links by default within the namespace is turned back on.
>
> And there should at least be one good counter-argument, shouldn't there? :-)
>
Yup, there are good counterarguments. The central one is that because
the main wikipedia holds the vast majority of information on the site,
most links are into the main site, no matter what section the page is
in.

Note also that if the change were turned on, all current links would
need to be automagically changed.

That said, I'd think it not unreasonable to make the switch, inasmuch
as we have the test case of meta.wikipedia.com, where to link to
the main site you have to put wp: before the link, which is essentially
what we're talking about.

But this should be lower priority than fixing the many, many bugs the
current software has.

-tc


in_reply_to: <ILENJBCFHGHELEBFPPBGOEKJCFAA.Magnus.Manske@epost.de> from "Magnus Manske" at Feb 25, 2002 08:21:53 PM

body:
> AFAIK, as we can still use the "/" character in page titles, there never was
> a plan to reintroduce subpage *functionality*. But it is easy enough to to
> by hand: Create the subpage by clicking on a link you create on your
> homepage ("[[user:Magnus Manske/foobar]]"); on the "subpage", write "Back to
> ~~~", which will become the backlink to your homepage.

Automatic functionality that can be done by hand is no longer automatic
functionality. And the creation of the back-link is only part of the
functionality; the other part is being able to write [[/foobar]] instead
of [[user:Magnus Manske/foobar]] on any user:Magnus Manske subpage.

> It seems we're back at my "trusted" status idea, which was meant to *reduce*
> the "cabal" by making certain fucntions accessible to many people instead of
> two. Well, I guess I was ahead of my time again ;)

Increasing the number of people in a cabal doesn't make it less of
a cabal unless the vast majority of people are in a cabal. Then you've
instead got a situation of unfortunate hierarchies. I'd rather have
one or two absolute dictators (so to speak) than an oligarchy.

--tc


subject: [Wikipedia-l] image namespace

body:
> An additional advantage could be tha ability to cope
> with new data types. I
> think of SVG, as an example. The code for including
> such a file is quite
> different, but for the user, it would be the same as
> a jpg
> ("{{IMG:foobar.svg}}").

Why not just [[Image:foobar.svg]] in the Image
namespace?  I was wondering how this would apply for
the non-English wikipedias, but then I realized they
could still just use the old way... (linking by URL)

Chuck

=====
Come to my homepage!  Venu al mia hejmpagxo!
http://amuzulo.babil.komputilo.org/
====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


subject: [Wikipedia-l] colons

body:
>
>
> From: <kband at www.llamacom.com>
> >
> > Yup, there are good counterarguments. The central one is that because
> > the main wikipedia holds the vast majority of information on the site,
> > most links are into the main site, no matter what section the page is
> > in.
>
> Yes, so?
>
> > Note also that if the change were turned on, all current links would
> > need to be automagically changed.
>
> No, it wouldn't. I've explained this a couple of postings ago. Because we
> would turn the switch that redirects links in a namespace that have no
> specified namespace to the same namspace. We only need to change the page
> titles and that can be done with a single SQL statement.

This is pretty wikitech, but e.g. on a user page, say there's a
link to [[mind control]]. I don't want that to default to
[[user:mind control]].

>
> > But this should be lower priority than fixing the many, many bugs the
> > current software has.
>
> We are working on that. Any bug you would like to go first?
>

Here's a short list.

#1 would be restoring the old wikipedia edit history, but I suspect
that won't ever happen, so:

#2 www.wikipedia.com homepage doesn't recognize a user as logged in if
you link to it from another site or type in the url; only once you go
to a www.wikipedia.com/wiki/* page does it recognize you.

#3 Can't edit a redirected entry

#4 Edit conflict on re-direct to nonexistent page

#5 Edit conflict on using back button to edit some more

I recommend setting up a bugzilla.wikipedia.com to make life easier.

--tc


subject: [Wikipedia-l] colons

body:
On lun, 2002-02-25 at 13:19, Magnus Manske wrote:
> > #2 www.wikipedia.com homepage doesn't recognize a user as logged in if
> > you link to it from another site or type in the url; only once you go
> > to a www.wikipedia.com/wiki/* page does it recognize you.
>
> That's an apache setting, also for Jimbo;)

This works fine for me. Is the problem specific to certain user
accounts?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] subpages

in_reply_to: <20020225233457.16097.qmail@www.llamacom.com>; from kband@www.llamacom.com on Mon, Feb 25, 2002 at 05:34:57PM -0600

body:
kband at www.llamacom.com wrote:
> Actually, to my knowledge LMS is just about the only one who's
> strongly anti-subpages in any form (look for the previous discussion
> on this issue).

I don't agree with this at all.

> If he's still the final arbiter of all Wikipedia
> functionality, then this is a moot point. If, however, we're back to
> policy by consensus, then it won't be too hard. But Mr. Wales needs to
> tell us what the story is there.

Don't think of it as "Larry as final arbiter" on the one hand and
"policy by consensus" on the other hand.  The right way to look at it
is that Larry is the final arbiter of what the consensus is.  Since
agitators on all sides are likely to never concede that the consensus
is against them, we need to have a final stopping point.

That's Larry, or maybe me if the issue is something technically beyond the
scope of his knowledge, but so far, achieving technical consensus has been
pretty easy.

--Jimbo


body:
On Mon, 25 Feb 2002 kband at www.llamacom.com wrote:

> > It seems we're back at my "trusted" status idea, which was meant to *reduce*
> > the "cabal" by making certain fucntions accessible to many people instead of
> > two. Well, I guess I was ahead of my time again ;)
>
> Increasing the number of people in a cabal doesn't make it less of
> a cabal unless the vast majority of people are in a cabal. Then you've
> instead got a situation of unfortunate hierarchies. I'd rather have
> one or two absolute dictators (so to speak) than an oligarchy.

Well, basically, we should keep the option *open* of having a "trusted"
status, as we did before.  It's basically silly, unjustified, to call this
sort of thing a cabal.  I think it's also silly to be very concerned that
it might turn into a "cabal," too.

All this being said, I really don't see why we shouldn't just let all
registered users edit the homepage.  Seems like the most elegant solution
all-round.

Larry


subject: [Wikipedia-l] colons

body:
On Mon, 25 Feb 2002, Jan Hidders wrote:

>
> From: <kband at www.llamacom.com>
> >
> > Yup, there are good counterarguments. The central one is that because
> > the main wikipedia holds the vast majority of information on the site,
> > most links are into the main site, no matter what section the page is
> > in.
>
> Yes, so?

Well, it's not true for the wikipedia: namespace, though it's probably
true for the user: namespace and the talk: namespace.

Larry


subject: [Wikipedia-l] subpages

body:
On Mon, 25 Feb 2002 kband at www.llamacom.com wrote:

> > >What exactly do you mean? As the one who made pretty much all the
> > >Sept.  11 pages, I can tell you that the subpage functionality made
> > it
> > >much easier--I certainly wouldn't have been able to deal with all of
> > >the information in there if I didn't make some kind of subpagery. I'm
> > >certainly not tied to the particular implementation of the
> > UseModWiki,
> > >but the ability to generate pages tied into another page without
> > >having to type the entire title every time is extremely useful.
> > >
> > >-TC
> >
> > that strikes me as ridiculous.  Ctrl+c, ctrl+v.
>
> Why should I have to do that if it can be automated?

Why should we revert to an inferior technology just to save you a little
convenience?  That's ridiculous.  EVERYONE is having to do extra work in
order to make the switch to the (better) new software.

Larry


subject: [Wikipedia-l] subpages

body:
On Tue, 26 Feb 2002, Jan Hidders wrote:

> From: <kband at www.llamacom.com>
> >
> > Why should I have to do that if it can be automated?
> >
> > Putting in many days of work into making the most popular entries on
> > the site (pat pat) is ridiculous. Having automatic functionality
> > making that work easier isn't.
>
> You are right, and ridiculous is certainly not a word that I would have
> used. But the thing is that by making such things easier we also stimulate
> the creation of subpages which, as Larry will explain to you if his wife
> lets him, :-), is something that we'd rather not have in Wikipedia. Maybe
> you don't agree with that, but then you should try to convince Larry and the
> rest of the Wikipedia-gang that subpages are a good thing. That won't be
> easy.

You'd actually have a hard time convincing me that it's worth spending any
more bandwidth discussing it at all.

(Wife is calling me to dinner right now. :-) )

Larry


subject: [Wikipedia-l] Another upload-management suggestion

body:
On lun, 2002-02-25 at 14:13, Robert Graham Merkel wrote:
> One thing that would speed up the management of uploads would
> be to have a link from each entry on the log:uploads page to the
> upload itself

Sounds good, that's been bothering me for a while too. ... Checked into
CVS and ready to go. (Will only affect new uploads from when the update
is installed, the old log entries stay as they are.)

> (or a page containing the upload and the meta-information
> that would be collected as described in other proposals).

Yes, that would be nice too once such a thing is implemented.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] colons

in_reply_to: <ILENJBCFHGHELEBFPPBGGEKMCFAA.Magnus.Manske@epost.de> from "Magnus Manske" at Feb 25, 2002 10:19:28 PM

body:
> > #5 Edit conflict on using back button to edit some more
>
> I thought about that one since the first versions, but I can't figure out
> how to avoid that. Maybe someone else???
>
The answer is to implement edit conflict testing like it did in UseModWiki.
The timestamp shouldn't come from the userside HTML, but from the server.
In addition, the software should know that the same user can't conflict
with himself.

--tc


subject: [Wikipedia-l] subpages

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020225/089612bf/attachment.diff


subject: Encoding for non-Latin1 wikipedias (was Re: [Wikitech-l] New caseconversion functions)

body:
From: "Brion Vibber" <brion at pobox.com>
> On sab, 2002-02-23 at 08:24, Jan Hidders wrote:
> >
> > Yes, and the accept-charset header is indeed the meta-tag I was thinking
of.
>
> Does it vary appropriately with the default language of the browser? I
> tried a few browsers on my system (US English or non-specific versions)
> and got:
>
> Mozilla 0.9.8: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Konqueror: unicode, utf-8, *
> Netscape 4.78: iso-8859-1,*,utf-8
> Opera 6: windows-1252;q=1.0, utf-8;q=1.0, utf-16;q=1.0,iso-8859-1;q=0.6,
*;q=0.1
> Internet Explorer 5.0: (nothing)
> lynx: (nothing)

FWIW, I tried it with nl-be and as you would expect it is the same for
Netscape and Explorer as above. I'll try what happens if I turn on
multilanguage-support in Windows.

> In the case of multiple supported encodings, do we use the first one, or
> the "best" one?

I would say the best one with. The only reason not do so is to show users
how to write certain characters as entities, but if somebody decides to edit
a page on the Russian Wikipedia we might expect that this person knows how
to enter Cyrillic characters on his or her keyboard, or either knows how to
enter them as entities. I'm not sure about when q!=1.0 for the best one.

> With regards to L. Crocker's earlier comment about UTF-8 being
> potentially problematic with older browsers; after checking the
> Accept-Charset field we *know* that a browser supports UTF-8, and can
> provide an alternate, more limited, encoding if not.
>
> That, I think, would be my personal preference.

Mine too.

> While I'm at it -- if instead of HTML entities we were to use UTF-8
> internally, we could get around the search problem by simply changing
> high characters in the fulltext index to hex codes.

Just to be clear on this. If we want indexing to work we need to encode it
in a format that uses only the Latin 1 numbers, letters, "_" and "'". The
alternative is to run different MySQL servers with appopriate character sets
for different Wikipedias.

> > Can you give an example? What is at the moment the behaviour of the
> > Esperanto Wikipedia?
>
> The current behavior that you'll find on visiting eo.wikipedia.com
> (running the old software):
> - Article contents, titles, comments, user interface messages, etc. are
> shown in UTF-8.
> - The article edit box is in limited UTF-8, with the standard diacritics
> transliterated (X-system)
> - Any input (edit box, comment field, search box, username) is
> internally normalised to X-system, so users can type any way they wish.
> - On selecting a convenient link at the top of the screen, article
> contents, user interface messages etc. are optionally shown in X-system.

Ok. I see your point. Does this also work for Windows users?

> Okay, but what's "special behavior" and what's "default behavior"? Say I
> visit the Japanese wikipedia, the French wikipedia, and the Esperanto
> wikipedia; is using a native encoding for native editing in each one
> "special behavior"? Or is using a common encoding for all "special
> behavior"?

I would say that the default behaviour is that you see in the edit box the
best character encoding your browser accepts. If the browser doesn't specify
this then the site falls back to Latin1 or whatever is specified as
$defaultEncoding on that site.

> [...] Whatever happens, though, we still
> need the custom transliteration functions available for the X-system
> conversion. Those users without special keyboard drivers (or worse yet,
> with Netscape 4's Unicode support) need to be able to type and sometimes
> read that way.

By the way, is this specified in the charset with the POST?

> HTML entities are unacceptably difficult for typing, and
> not helpful for reading -- a browser that doesn't show the UTF-8 won't
> do any better with the entities.

My main interest is that we maintain 1 software package that can be adapted
by setting some variables and includes. If we really cannot get around
having extra special encoding-links that can be turned off or on depending
upon some variables, then so be it.

-- Jan Hidders


subject: [Wikipedia-l] subpages

in_reply_to: <200202252240.g1PMeCB26844@ross.bomis.com> from "koyaanisqatsi@nupedia.com" at Feb 25, 2002 02:40:12 PM

body:
> >What exactly do you mean? As the one who made pretty much all the
> >Sept.  11 pages, I can tell you that the subpage functionality made
> it
> >much easier--I certainly wouldn't have been able to deal with all of
> >the information in there if I didn't make some kind of subpagery. I'm
> >certainly not tied to the particular implementation of the
> UseModWiki,
> >but the ability to generate pages tied into another page without
> >having to type the entire title every time is extremely useful.
> >
> >-TC
>
> that strikes me as ridiculous.  Ctrl+c, ctrl+v.

Why should I have to do that if it can be automated?

Putting in many days of work into making the most popular entries on
the site (pat pat) is ridiculous. Having automatic functionality
making that work easier isn't.

-TC


subject: [Wikipedia-l] subpages

body:
>
> From: <kband at www.llamacom.com>
> >
> > Why should I have to do that if it can be automated?
> >
> > Putting in many days of work into making the most popular entries on
> > the site (pat pat) is ridiculous. Having automatic functionality
> > making that work easier isn't.
>
> You are right, and ridiculous is certainly not a word that I would have
> used. But the thing is that by making such things easier we also stimulate
> the creation of subpages which, as Larry will explain to you if his wife
> lets him, :-), is something that we'd rather not have in Wikipedia. Maybe
> you don't agree with that, but then you should try to convince Larry and the
> rest of the Wikipedia-gang that subpages are a good thing. That won't be
> easy.
>

Actually, to my knowledge LMS is just about the only one who's
strongly anti-subpages in any form (look for the previous discussion
on this issue). If he's still the final arbiter of all Wikipedia
functionality, then this is a moot point. If, however, we're back to
policy by consensus, then it won't be too hard. But Mr. Wales needs to
tell us what the story is there.

-tc


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] subpages

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020225/5630986d/attachment.diff


subject: [Wikipedia-l] colons

body:
>
>
> From: <kband at www.llamacom.com>
> >
> > This is pretty wikitech, but e.g. on a user page, say there's a
> > link to [[mind control]]. I don't want that to default to
> > [[user:mind control]].
>
> Ah, ok. That might be a good point, although I myself wouldn't mind it. The
> other side of the coin is that I now have to type [[user:Jan
> Hidders/Sandbox]] instead of [[Jan Hidders/Sandbox]].

But you wouldn't have to do that if subpage functionality were turned
on for the user pages. Then all you'd have to type is [[/Sandbox]].

>
> > #5 Edit conflict on using back button to edit some more
>
> I'm not so sure that's a bug. You can always click on the edit link again if
> you want to edit some more. I know we could simply arrange things so that a
> user can never conflict with him or her-self, but that might lead to
> mistakes like starting to re-edit the penultimate version.

Oh, it's definitely a bug. It was a very useful feature in the
UseModWiki software, since it takes much longer to load the edit page
from the server than from the local browser cache (and on a smaller
but still cumulatively significant point, it's a little bit faster to
find the back button or hit the back-page command than to scroll/find
the "edit page link").

There's no need to keep users from conflicting with themselves; it's
just a matter of fixing the way timestamping is handled. It shouldn't
be browserside.

--tc


subject: [Wikipedia-l] subpages

body:
>
> On Mon, 25 Feb 2002 kband at www.llamacom.com wrote:
>
> > > >What exactly do you mean? As the one who made pretty much all the
> > > >Sept.  11 pages, I can tell you that the subpage functionality made
> > > it
> > > >much easier--I certainly wouldn't have been able to deal with all of
> > > >the information in there if I didn't make some kind of subpagery. I'm
> > > >certainly not tied to the particular implementation of the
> > > UseModWiki,
> > > >but the ability to generate pages tied into another page without
> > > >having to type the entire title every time is extremely useful.
> > > >
> > > >-TC
> > >
> > > that strikes me as ridiculous.  Ctrl+c, ctrl+v.
> >
> > Why should I have to do that if it can be automated?
>
> Why should we revert to an inferior technology just to save you a little
> convenience?  That's ridiculous.  EVERYONE is having to do extra work in
> order to make the switch to the (better) new software.
>
There's that good Yankee-Puritan ethic: if it tastes bad and is more
difficult, it's better.

Better == more convenient, not more work, in the world of software.

If EVERYONE is having to do extra work, then we're wasting a lot
of human-hours which could be better spent just making good articles.

And I'm not arguing for any "reversion" to "inferior" technology.
That would be ridiculous. I'm talking about better information
management techniques--how exactly to implement those is a secondary
issue.

--tc


subject: [Wikipedia-l] colons

body:
From: "Vicki Rosenzweig" <vr at redbird.org>
> > >
> > > There is a simpeler solution. The actual contents of Wikipedia get the
> > > namespace "content:". If everything is prefixed with a namespace then
the
> > > first colon is always the end of the namespace.
> > >
> >That's perfect.
>
> Would this require us to explicitly put "content:" in front of every link?

Not necessarily. I would propose that a link without a namespace should
default to the namespace that it is in. That's how namespaces usually work
anyway. It means for example that if you create a link on your home page
without a namespace it becomes a page in the user: namespace. (Actually I
still believe that every user should have his or her own namespace, but that
is another issue.)

-- Jan Hidders


from_name: Magnus Manske

subject: [Wikipedia-l] Uploads being abused

body:
I already changed the software so it only accepts uploads from users who are
logged in. I did this two days or so ago. It might help if Jimbo would
actually install the latest version ;)

Magnus


subject: [Wikipedia-l] colons

body:
The original software *did* stay within the current namespace if no other
was explicitly given. So, "[[test]]" on the page "[[user:Magnus Manske]]"
did link to "[[user:test]]" instead of "[[test]]". At that time, I still
planned a "stable:" namespace for approved articles, which would
automatically link only to other stable articles.

The "blank" namespace was (and still should be) accessible through "[[:Main
Page]]" (note the leading colon).

The main switch for that should still be somewhere in wikiTextEn.php.

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jan Hidders
> Sent: Monday, February 25, 2002 6:26 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] colons
>
>
> From: "Vicki Rosenzweig" <vr at redbird.org>
> > > >
> > > > There is a simpeler solution. The actual contents of
> Wikipedia get the
> > > > namespace "content:". If everything is prefixed with a
> namespace then
> the
> > > > first colon is always the end of the namespace.
> > > >
> > >That's perfect.
> >
> > Would this require us to explicitly put "content:" in front of
> every link?
>
> Not necessarily. I would propose that a link without a namespace should
> default to the namespace that it is in. That's how namespaces usually work
> anyway. It means for example that if you create a link on your home page
> without a namespace it becomes a page in the user: namespace. (Actually I
> still believe that every user should have his or her own
> namespace, but that
> is another issue.)
>
> -- Jan Hidders
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Julie Hofmann Kemp

subject: [Wikipedia-l] RE: Wikipedia-l digest, Vol 1 #310 - 17 msgs

body:
Please make the colors go away!!!  And (same old song, different tune)
WHY make such a huge change without explaining it where people will see
this???  It isn't intuitive for people to go to FAQ when there has been
a change -- why not just let them know ahead of time -- and as a blurb
on Recent Changes, since that's where most of the addicted start????

Julie

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


subject: [Wikipedia-l] colons

body:
From: "Magnus Manske" <Magnus.Manske at epost.de>

> The original software *did* stay within the current namespace if no other
> was explicitly given. So, "[[test]]" on the page "[[user:Magnus Manske]]"
> did link to "[[user:test]]" instead of "[[test]]". At that time, I still
> planned a "stable:" namespace for approved articles, which would
> automatically link only to other stable articles.

It's already there? So all we would have to do is take care that the
content: namespace doesn't show up in the title? (Plus change some code that
assumes that any title that contains a ":" is not content.) Can I, can I,
can I? Please? :-) As far as I can see this actually makes the code simpeler
because titles will always have the same format.

> The "blank" namespace was (and still should be) accessible through
"[[:Main
> Page]]" (note the leading colon).

Yup, works on my site.

-- Jan Hidders


subject: [Wikipedia-l] Colors

body:
On lun, 2002-02-25 at 19:16, Vicki Rosenzweig wrote:
> At 07:11 PM 2/25/02 -0800, Julie wrote:
> >Please make the colors go away!!!
>
> Or at least make them lighter--the green on feature requests is fine on my
> monitor
> (Hitachi CM715; Netscape 6), but the gray on "recent changes" is dark enough to
> make reading harder.

Agreed, they're icky. Magnus, would you be terribly upset if we
redecorate your colors with something a bit lighter? Say:

$wikiNamespaceBackground[$wikiTalk] = "#eeFFFF" ;
$wikiNamespaceBackground[$wikiWikipedia] = "#eeFFee" ;
$wikiNamespaceBackground[$wikiUser] = "#FFeeee" ;
$wikiNamespaceBackground["log"] = "#FFFFcc" ;
$wikiNamespaceBackground["special"] = "#eeeeee" ;

These are much less eye-searing to me.

(Also, I'd prefer to see these set in wikiSettings, not wikiTextEn. In
particular, they should be overrideable in wikiLocalSettings, which
currently is not possible for anything set up in wikiTextEn.
Objections?)

-- brion vibber (brion @ pobox.com)


from_name: Lars Aronsson

subject: [Wikipedia-l] Uploads being abused

body:
Larry Sanger wrote:
> I agree 100% that this is a problem.  Last night I deleted several dozen
> files that someone had overwritten as being (obviously) inappropriate for
> Wikipedia articles.  I was a little concerned from the beginning that
> having virtually no restrictions on the upload function would have this
> effect, so it's not too surprising that this is happening.


subject: [Wikipedia-l] colons

body:
From: "Larry Sanger" <lsanger at nupedia.com>
>
> Let's consider some arguments though on both sides.  Let's think it
> through!

Don't worry. I won't change any code unless I have a feeling there is a
consensus about this. But by now I have programmed most of the SQL that
deals with this and I think I have a reasonable insight in what the
consequences are from a technical point of view. From the users point of
view not much changes (unless we want to) except that the namespace-feature
that keeps links by default within the namespace is turned back on.

And there should at least be one good counter-argument, shouldn't there? :-)

-- Jan Hidders


body:
> > > >From what I remember from Wikipedia-L, I thought we
> > > were going to continue to allow subpages on personal
> > > pages and ditch them on the regular wikipedia.  Are
> > > there any plans to put them back in on personal pages?
> >
> > Don't know.
>
> That would be nice.

AFAIK, as we can still use the "/" character in page titles, there never was
a plan to reintroduce subpage *functionality*. But it is easy enough to to
by hand: Create the subpage by clicking on a link you create on your
homepage ("[[user:Magnus Manske/foobar]]"); on the "subpage", write "Back to
~~~", which will become the backlink to your homepage.

> > > Also, when are you going to give back privileges to
> > > edit the Homepage to trusted users?  I made it my
> > > responsibility to update the new language wikipedias
> > > when they came in and now I can't.  I think an
> > > unprotected homepage is better than a protected
> > > homepage that only two people can edit... now that's a
> > > cabal!
> >
> > Well, there was originally a "can-edit-the-homepage" cabal :-)
> consisting
> > of about a dozen people, but they all had sysop privileges as
> well, which
> > was, er, not to "diss" any of the people in question, maybe a little
> > dangerous.
>
> Were there ever any actual incidents where this was a problem? If there
> were, it should be made public.

It seems we're back at my "trusted" status idea, which was meant to *reduce*
the "cabal" by making certain fucntions accessible to many people instead of
two. Well, I guess I was ahead of my time again ;)

> > Y'know, I think a sensible thing to do would be to make all registered
> > users members of a "can-edit-the-homepage" cabal, which makes
> it no longer
> > a cabal.  This would prevent almost all homepage vandalism.
>
> That's a good idea.

Best idea, second to "trusted"...

Magnus


from_name: Graham Chapman

subject: [Wikipedia-l] Re:colons

body:
Bad idea - you don't know what namespaces you want to use in
future.

Graham

> I just realized we don't need to forbid the use of colons in
> titles;
> unlike the subpage "/", the only time colons are used as a
> special
> character are with the limited number of namespaces.

> Thus instead of the ":" being a reserved character anywhere in > a
> title, only "user:", "talk:", "wikipedia:" etc. need to be
> reserved. Any other uses of colons should be fine. This will
> let us
> have entries for books with standard formatting of the
> subtitle (e.g.,
> "The Muggles: A Tale of Woe") or other natural uses of the
> colon.

> -TC

Email: grahamc at patia.com
Web  : http://patia.com/grahamc


subject: [Wikipedia-l] Upload issue

body:
This might be the time for a new idea (beware!;)

As you can see on the upload page, it gets quite crowded and loads very
slow. And we only have a few images up there.

So, there are some mechanisms we could try to clean this up and fix the
unwanted uploads issue:
1. Create subdirectories for categories ("biology" etc.)
2. Create SourceForge-style subdirectories, by the first and the first two
letters. "foobar.jpg" would go to "f/fo/foobar.jpg".
3. Create a binary namespace.

Personally, I'd vote for #2. We won't have to create a category scheme (as
in #1), and the tech would be easy (in contrast to #2). It would also group
images quite efficiently.

Now, what I had in mind was this: The current way of linking to images is
fine (just type in the URL!), but *additionally*, we could have another
scheme for linking wikipedia-internal images. Example: "{{IMG:foobar.jpg}}".
Now, the software could automatically determine the correct URL, based on
the storage scheme. It would also enable us to find unlinked images quite
easily.

An additional advantage could be tha ability to cope with new data types. I
think of SVG, as an example. The code for including such a file is quite
different, but for the user, it would be the same as a jpg
("{{IMG:foobar.svg}}").

Just dumping my random thoughts on you,
Magnus


subject: [Wikipedia-l] subpages

body:
On Mon, 25 Feb 2002 koyaanisqatsi at nupedia.com wrote:

> LMS is not strongly against subpages in any form, as you will see if
> you upgrade your monitor from monochrome to 16 colors.  Read
> carefully.  People do deserve that respect.  Larry is against
> subpages in the main, encyclopedia-article namespace; he is not
> against them in "meta-" namespaces.  Furthermore, I am equally
> against them, for the reasons he has elaborated, and have expressed
> as much.  LMS is not the final arbiter of all Wikipedia
> functionality, in spite of your assertions to the contrary, though he
> does have considerable influence over Wikipedia's course.  Most
> people realize that.  A few insist on oversimplification, with
> increasingly frustrating results.

Thanks.  I couldn't agree more.

There hasn't ever been a real consensus about subpages.  There's been a
controversy and a need to arrive at a decision that reflected, to the
best of my ability, a fair assessment of the range of opinions on the
issue.

Larry


subject: [Wikipedia-l] Colors

body:
Or, make them the colors of the headers and footers...

Larry

On Mon, 25 Feb 2002, Vicki Rosenzweig wrote:

> At 07:11 PM 2/25/02 -0800, Julie wrote:
> >Please make the colors go away!!!
>
> Or at least make them lighter--the green on feature requests is fine on my
> monitor
> (Hitachi CM715; Netscape 6), but the gray on "recent changes" is dark enough to
> make reading harder.
>
> But, as implied by my specifying monitor hardware and browser, this is
> going to be
> hard to tinker with: what works for me may not work for someone else.
>
>


subject: [Wikipedia-l] colons

body:
From: <kband at www.llamacom.com>
>
> Yup, there are good counterarguments. The central one is that because
> the main wikipedia holds the vast majority of information on the site,
> most links are into the main site, no matter what section the page is
> in.

Yes, so?

> Note also that if the change were turned on, all current links would
> need to be automagically changed.

No, it wouldn't. I've explained this a couple of postings ago. Because we
would turn the switch that redirects links in a namespace that have no
specified namespace to the same namspace. We only need to change the page
titles and that can be done with a single SQL statement.

> But this should be lower priority than fixing the many, many bugs the
> current software has.

We are working on that. Any bug you would like to go first?

-- Jan Hidders


subject: [Wikipedia-l] colons

body:
From: "Jan Hidders" <hidders at uia.ua.ac.be>
> From: <kband at www.llamacom.com>
> >
> >
> > Note also that if the change were turned on, all current links would
> > need to be automagically changed.
>
> No, it wouldn't. I've explained this a couple of postings ago. Because we
> would turn the switch that redirects links in a namespace that have no
> specified namespace to the same namspace. We only need to change the page
> titles and that can be done with a single SQL statement.

Hold it, that's not completely true. The links from non-content namspaces to
the content namspace would indeed be broken. But that can be remedied with a
PHP script that replaces these links.

-- Jan Hidders


subject: [Wikipedia-l] Colors

body:
At 07:11 PM 2/25/02 -0800, Julie wrote:
>Please make the colors go away!!!

Or at least make them lighter--the green on feature requests is fine on my
monitor
(Hitachi CM715; Netscape 6), but the gray on "recent changes" is dark enough to
make reading harder.

But, as implied by my specifying monitor hardware and browser, this is
going to be
hard to tinker with: what works for me may not work for someone else.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [Wikipedia-l] colons

body:
> #1 would be restoring the old wikipedia edit history, but I suspect
> that won't ever happen, so:

That's up to Jimbo (who is pretty busy right now updating the "real" site;)

> #2 www.wikipedia.com homepage doesn't recognize a user as logged in if
> you link to it from another site or type in the url; only once you go
> to a www.wikipedia.com/wiki/* page does it recognize you.

That's an apache setting, also for Jimbo;)

> #3 Can't edit a redirected entry

That's long fixed, the software will be installed today

> #4 Edit conflict on re-direct to nonexistent page

Yes, that seems to be still in...

> #5 Edit conflict on using back button to edit some more

I thought about that one since the first versions, but I can't figure out
how to avoid that. Maybe someone else???

Magnus


subject: [Wikitech-l] IP blocking (fwd)

body:
Re the e-mail below: I just noticed that the following line appears in
the Recent Changes log:

(diff) Wikipedia:Blocked IPs; 22:24 (1 change) . . . Larry_Sanger M [IP
was blocked by Larry_Sanger]

I'd rather not have the log entry there.  This represents a significant
change in the functionality of the software; frankly, this doesn't need to
be made so public.  I don't think it should be shouted from the rooftops
that I've blocked an IP.  If someone wants to know what IPs I've blocked,
that's fair enough--I don't want it *hidden* from anyone--they could visit
a page to find that out.  I just don't want the eedjits constantly getting
into a dither about who I'm blocking and why.  And they will be, if we log
this.  This hasn't been a problem so far; there's no reason for it to be
made one.

Also, please notice that I haven't got a clue as to how the above
happened.  I simply went to [[special:blockIP]] (WITHOUT any
"&target=..."), it seems, and the above log entry was created.

Now, when I go to [[Wikipedia:Blocked IPs]], I see the following entry:

(1014704640) : IP  was blocked by Larry_Sanger

Did I just block someone's IP address unwittingly???  I hope not.  Can you
please check?  (I don't know how.)

--Larry

---------- Forwarded message ----------
Date: Mon, 25 Feb 2002 22:25:50 -0800 (PST)
From: Larry Sanger <lsanger at nupedia.com>
To: Magnus Manske <Magnus.Manske at epost.de>
Subject: IP blocking

Hi Magnus,

I found a link to "block this IP" on
http://www.wikipedia.com/wiki/What_is_a_wiki&action=history after
4.35.29.174 but not after any other IP numbers.  Is that how it's supposed
to work?  How IS it supposed to work?  What will happen if I press the
"Block this IP" button?

Larry


from_name: Robert Graham Merkel

subject: [Wikipedia-l] Uploads being abused

body:
Hi all, it is perhaps unfortunate that my first post to the list is
a bit of a rant, but I'm very concerned about the abuse of the file
upload feature and so far I haven't seen any responses to the discussion
on meta from people with the power to do something about it.

It seems to me from following the upload queue that it is
being deliberately abused to store distinctly non-encyclopedia
and copyright-infringing material on a disconcertingly large scale.

I would assume that this would be of direct financial concern
to Bomis, both for the potential of large bandwidth costs and
the potential for being sued, and to the rest of the project
because of the risk of being shut down by a lawsuit.

Are we just going to attempt to keep this under control by
the vigilance of a few dedicated Wikipedians, or might, in this
case, some technical measures to discourage abuse be appropriate?

For instance, it might be feasible to restrict uploads to registered
users, limiting the size and number of files that a user can upload in
a day, perhaps even restricting the types of files that can be uploaded by
checking with the "file" file type checking utility - that would at least
prevent the uploading of executables).

I would be prepared to help implement some of the above.  I'm a decent
programmer, though I don't have any experience with PHP so it'd take me
some time to get up to speed.

Obviously, I think technical measures to slow things is
justified in this case, otherwise I suspect too much time will
be wasted weeding out rather noxious material.

--
------------------------------------------------------------
Robert Merkel	                           rgmerk at mira.net

Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------


subject: [Wikipedia-l] colons

body:
From: <kband at www.llamacom.com>
>
> This is pretty wikitech, but e.g. on a user page, say there's a
> link to [[mind control]]. I don't want that to default to
> [[user:mind control]].

Ah, ok. That might be a good point, although I myself wouldn't mind it. The
other side of the coin is that I now have to type [[user:Jan
Hidders/Sandbox]] instead of [[Jan Hidders/Sandbox]].

> #5 Edit conflict on using back button to edit some more

I'm not so sure that's a bug. You can always click on the edit link again if
you want to edit some more. I know we could simply arrange things so that a
user can never conflict with him or her-self, but that might lead to
mistakes like starting to re-edit the penultimate version.

-- Jan Hidders


subject: [Wikipedia-l] subpages

body:
From: <kband at www.llamacom.com>
>
> Why should I have to do that if it can be automated?
>
> Putting in many days of work into making the most popular entries on
> the site (pat pat) is ridiculous. Having automatic functionality
> making that work easier isn't.

You are right, and ridiculous is certainly not a word that I would have
used. But the thing is that by making such things easier we also stimulate
the creation of subpages which, as Larry will explain to you if his wife
lets him, :-), is something that we'd rather not have in Wikipedia. Maybe
you don't agree with that, but then you should try to convince Larry and the
rest of the Wikipedia-gang that subpages are a good thing. That won't be
easy.

-- Jan Hidders


body:
One thing that would speed up the management of uploads would
be to have a link from each entry on the log:uploads page to the
upload itself (or a page containing the upload and the meta-information
that would be collected as described in other proposals).

That way, inspecting the new uploads would be considerably quicker.

--
------------------------------------------------------------
Robert Merkel	                           rgmerk at mira.net

Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------


subject: [Wikitech-l] Quick note on updating the cur table

body:
One of the wonders of having a TIMESTAMP field in your table is that it
gets updated automatically every time a row is changed.

One of the gotchas of having a TIMESTAMP field in your table is that it
gets updated automatically every time a row is changed.

When the latest update got installed, *every article* got its modified
date reset to February 25, circa 15:51 (and thus flooded Recent
Changes). D'oh!

Either we all need to make sure that we throw a
cur_timestamp=cur_timestamp into data-changing SQL code that's not
supposed to change the dates, or we should just change the field so it's
updated manually in the places where it's supposed to be...

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] colons

body:
From: <kband at www.llamacom.com>
> > From: <kband at www.llamacom.com>
> > >
> > > This is pretty wikitech, but e.g. on a user page, say there's a
> > > link to [[mind control]]. I don't want that to default to
> > > [[user:mind control]].
> >
> > Ah, ok. That might be a good point, although I myself wouldn't mind it.
The
> > other side of the coin is that I now have to type [[user:Jan
> > Hidders/Sandbox]] instead of [[Jan Hidders/Sandbox]].
>
> But you wouldn't have to do that if subpage functionality were turned
> on for the user pages. Then all you'd have to type is [[/Sandbox]].

True. But if I'm thinking of future namespaces such as "stable" I'd prefer a
consistent behaviour over all namespaces. It is in my experience important
that the behaviour of the system is governed by a few clear and simple rules
with as little exceptions as possible. It not only makes it easier to build
a correct implementation, but also makes it easier to explain to the user.

> There's no need to keep users from conflicting with themselves; it's
> just a matter of fixing the way timestamping is handled. It shouldn't
> be browserside.

Both the begin-time and the commit-time of the edit are determined
server-side at the moment. As I said, changing the behaviour would probably
mean that a user never conflicts with him or herself.

-- Jan Hidders


subject: [Wikitech-l] orphans page takes too long

body:
Jan Hidders wrote:
> SELECT COUNT(*) FROM linked;
>
> and
>
> SELECT COUNT(*) FROM linkes GROUP BY linked_from, linked_to ;

mysql> SELECT COUNT(*) FROM linked;
+----------+
| COUNT(*) |
+----------+
|    15380 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM linked GROUP BY linked_from, linked_to ;
ERROR 1169: Can't write, because of unique constraint, to table '#sql1112_aaaca_1'

(I assumed you meaned 'linked' instead of 'linkes', which doesn't work either.


subject: [Wikipedia-l] Colors - skin

body:
Colors:

Simple solution, make it a skin.  That's what skins
are for, aren't they?

Chuck

=====
Come to my homepage!  Venu al mia hejmpagxo!
http://amuzulo.babil.komputilo.org/
====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


subject: [Wikipedia-l] Allowing HTML for ruby text?

body:
Someone wrote in [[wikipedia:Bug reports]] today about the ruby tags
(<ruby>, <rb>, <rt>, <rp>) being disabled, and requesting to have them
reinstated.

For those who don't know, ruby text is a feature of East Asian
typography in which a pronunciation guide in alphabetic or syllablic
characters is put above or below the equivalent Chinese characters.
These are used extensively in books for children and foreigners, as well
as in regular publications for rare characters -- for instance,
now-obsolete characters used in historical names that you'd expect to
see in an encyclopedia.

Basically, it's the equivalent of things like "Lumi?re (loo-me-AIR)",
but because it goes outside the line of regular text, requires a special
HTML tag to do it.

It's a simple matter to include ruby, rb, rt, and rp in the list of
allowed tags, but I promised to ask the group before adding more tags.

The primary argument in favor of including them is that they might be
useful on the (currently rather empty) Japanese and Chinese wikipedias,
and as a demonstration in the English wikipedia article [[Ruby]].

Arguments against are double:
* Using the tags is kind of complicated, roughly like making an HTML
table. This may discourage users from using them regularly anyway.

* As far as I know, the ruby tags are currently only supported by recent
versions of Internet Explorer, and aren't actually in the HTML 4.01
standard. They are, however, officially available as an extension to
XHTML - see http://www.w3.org/TR/2001/REC-ruby-20010531/

However, properly formed ruby text will come out looking okay on
browsers that don't support the tags (ie, like "Lumi?re (loo-me-AIR)"),
so there's no harm to using the tags where appropriate.

-- brion vibber (brion @ pobox.com)


body:
On mar, 2002-02-26 at 11:28, Jimmy Wales wrote:
> mysql> SELECT COUNT(*) FROM linked;
> +----------+
> | COUNT(*) |
> +----------+
> |    15380 |
> +----------+
> 1 row in set (0.00 sec)

That looks wayyy too small. Jim, did you run updLinks.php? You'll
probably have to edit it to up $size to make it managable, given the
size of the database...

-- brion vibber (brion @ pobox.com)


in_reply_to: <1014760753.24573.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Tue, Feb 26, 2002 at 01:59:08PM -0800

body:
> > mysql> SELECT COUNT(*) FROM linked;
> > +----------+
> > | COUNT(*) |
> > +----------+
> > |    15380 |
> > +----------+
> > 1 row in set (0.00 sec)
>
> That looks wayyy too small. Jim, did you run updLinks.php? You'll
> probably have to edit it to up $size to make it managable, given the
> size of the database...

I did run it, with $size=1000.

It printed a lot of stuff on the screen, I guess because I didn't
comment out some debugging prints.  I can not report now with 100%
certainty that it ran without any errors.  But it ran, and then after
that I did some more mysql stuff to create the indexes on it.

I'll look at the contents of the 'linked' table now, and report back on whether it looks
sensible to me.

--Jimbo


body:
Well, the (boolean) search seems to fly and the most-wanted page seems to
run smoothly, but the orphans-page get a time-out because it takes more than
30 seconds to compute. I'm baffled by this because on my little PC the
most-wanted pages takes about 5 times as long as the orphans page. Is there
a way for me to get access to the database to see what's going on? Perhaps
someone could check if all the indexes for linked are actually defined? I
also would like to know if there are perhaps a big amount of duplicates
there. I would like to know what the results of

SELECT COUNT(*) FROM linked;

and

SELECT COUNT(*) FROM linkes GROUP BY linked_from, linked_to ;

to see if they are very different. Perhaps a new log of the slow queries
would also be helpful.

-- Jan Hidders


subject: [Wikitech-l] minimum search size

body:
Jimbo,

Could you please also install the new wikiSettings.php? There is a variable
defined in there that needs to be set for the search box to function
properly.

Thanks,

-- Jan Hidders


from_name: Gareth Owen

subject: [Wikipedia-l] subpages

in_reply_to: Larry Sanger's message of "Mon, 25 Feb 2002 15:43:36 -0800 (PST)"

body:
Larry Sanger <lsanger at nupedia.com> writes:

> Why should we revert to an inferior technology just to save you a little
> convenience?

Can someone please explain, from the perspective of a user and contributor
rather than a software engineer, why the old wiki technology is considered
(by some) to have been inferior?

On an unrelated *cough* note:
-----------------------------------------------------------------------------
Fatal error: Call to undefined function: array_key_exists() in
/home/wiki-newest/work-http/special_recentchanges.php on line 152
-----------------------------------------------------------------------------
--
Gareth Owen
"Wikipedia does rock.  By the count on the "brilliant prose" page, there
 are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)


subject: [Wikipedia-l] subpages

body:
From: "Gareth Owen" <wiki at gwowen.freeserve.co.uk>
> Larry Sanger <lsanger at nupedia.com> writes:
>
> > Why should we revert to an inferior technology just to save you a little
> > convenience?
>
> Can someone please explain, from the perspective of a user and contributor
> rather than a software engineer, why the old wiki technology is considered
> (by some) to have been inferior?

I don't think Larry meant it from a software-engineering point of view,
because from that point of view it doesn't make much difference. He probably
meant it from a management point-of-view where inferior technology means
that it promotes unwanted types of articles.

> On an unrelated *cough* note:
> --------------------------------------------------------------------------
---
> Fatal error: Call to undefined function: array_key_exists() in
> /home/wiki-newest/work-http/special_recentchanges.php on line 152
> --------------------------------------------------------------------------
---

That's because Jimbo was running an older version of PHP. Inferior
technology, if you will. :-) I don't see the error now so I assume he has
updated it.

-- Jan Hidders


subject: [Wikitech-l] IP blocking / color schmemes

body:
I just commited
* IP blocking does not show on Recent Changes anymore
* In all namespaces, the "article" body has a white background (fix for
now;)


subject: [Wikitech-l] New colors, Nostalgy skin

body:
I updated the background colors to Brion's suggestion (now in
wikiSettings.php).

Also, I added a "Nostalgy" skin that makes the 'pedia look almost (!) like
UseModWiki. The HTML output is far from perfect, but it renders well in
Konqueror.

Magnus


subject: [Wikipedia-l] Colors - skin

body:
> Simple solution, make it a skin.  That's what skins
> are for, aren't they?

The background of the *text* in all namespaces is now white again.

Also, for those of you who still miss the UseModWiki, there's now a
"Nostalgy" skin (sorry for the typo, will be corrected in the next update;)

Magnus

PS: Thanks, Jimbo, for the fast update :)


subject: [Wikitech-l] orphans page takes too long (PS)

body:
On mer, 2002-02-27 at 02:42, Jan Hidders wrote:
> Because you already did a batch you need to empty the tables first. The
> fastest way to do this is simply to drop the tables altogether. After that
> you can recreate them without the indexes (as in updSchema.sql) and fill
> them with the script. Considering the speed of your system you might simply
> try setting $size to 40000 or so, and attempt to do everything in one go. If
> that times-out, clear the tables 'linked' and 'unlinked'  with DELETE and
> try again with half the value. Et cetera. After this you can add the indexes
> as in updSchema.sql.

You can also set set_time_limit(9999) or some such. No nasty timeouts!

-- brion vibber (brion @ pobox.com)


body:
On mer, 2002-02-27 at 02:51, Jan Hidders wrote:
> From: "Brion L. VIBBER" <brion at pobox.com>
> > Someone wrote in [[wikipedia:Bug reports]] today about the ruby tags
> > (<ruby>, <rb>, <rt>, <rp>) being disabled, and requesting to have them
> > reinstated.
>
> Well you probably know that my position is that allowing HTML tags was one
> of the biggest mistakes ever made in the history of Wikipedia software. But
> they are here now and we can't make them go away, so we have to deal with
> them anyway.

Heh. :) Well, the alternative is to provide our own special wiki markup
for *every* feature that people need, including complicated things like
tables. At some point the simplicity of the wiki markup and the
complexity of the features collide, and you may as well make use of
peoples' existing experience with the HTML codes.

> These tags look very useful to me, so I agree with allowing
> them.

(see also a few messages to this effect in intlwiki-l)

Great, I'll go ahead and add them then.

> As a technical remark I would like to see a central array or something that
> records what tags are allowed (and perhaps even how they might be nested and
> what attributes they may have).

Hmm, that could be done. Guess it's time to rewrite removeHTMLtags()
again. (yay)

> For instance, in presenting the search
> results I have to deal with HTML tags that might be present, and it would be
> pleasant if this would automatically adapt if new tags are allowed.

Can you just run removeHTMLtags() separately over each chunk of
extracted text? That should automatically close off tags, etc. I haven't
taken a look at the search code in a while though so I'm not sure how it
works at the moment...

-- brion vibber (brion @ pobox.com)


body:
Right, I did drop cur_linked_links and cur_unlinked_links.

> No panic, the linking information is still there except we now need a
> different script because we need to get it out of the cur_text field. This
> is a bit of a problem because I really have to prepare some lessons for
> tomorrow. Any of the other programmers feel able to do this?

Well, there's no special hurry is there?

The site looks fine, this is just a problem for the orphan pages script?  And that's
not super-duper important.


body:
On mer, 2002-02-27 at 09:34, Jan Hidders wrote:
> From: "Jimmy Wales" <jwales at bomis.com>
> >
> > Well, there's no special hurry is there?
> >
> > The site looks fine, this is just a problem for the orphan pages script?
> And that's
> > not super-duper important.
>
> .. and the mostWanted page, but that is also not really fatal.

And "pages that link to this page".

> Ok. I'll try
> to have the new script ready by tomorrow.

I just committed a rebuildLinks.php, does it look like it's doing the
right things?

-- brion vibber (brion @ pobox.com)


body:
From: "Jan Hidders" <hidders at uia.ua.ac.be>
>
> Oh dear. Sorry that my instructions were not clear. You are supposed to
run
> the script, wait for a link to appear and then click this link for the
next
> batch. It seems you did only one batch. You need to repeat this until all
> the records in table cur have been processed. This means you have to click
> about 37 or 38 times, or you have to increase $size to do bigger batches.
> (But avoid the 30 s. time-out. If you get a time-out you have the clear
the
> table "DELETE FROM linked WHERE 1=1;" and start from the beginning again.)

Because you already did a batch you need to empty the tables first. The
fastest way to do this is simply to drop the tables altogether. After that
you can recreate them without the indexes (as in updSchema.sql) and fill
them with the script. Considering the speed of your system you might simply
try setting $size to 40000 or so, and attempt to do everything in one go. If
that times-out, clear the tables 'linked' and 'unlinked'  with DELETE and
try again with half the value. Et cetera. After this you can add the indexes
as in updSchema.sql.

-- Jan Hidders


body:
From: "Brion L. VIBBER" <brion at pobox.com>

> Someone wrote in [[wikipedia:Bug reports]] today about the ruby tags
> (<ruby>, <rb>, <rt>, <rp>) being disabled, and requesting to have them
> reinstated.

Well you probably know that my position is that allowing HTML tags was one
of the biggest mistakes ever made in the history of Wikipedia software. But
they are here now and we can't make them go away, so we have to deal with
them anyway. These tags look very useful to me, so I agree with allowing
them.

As a technical remark I would like to see a central array or something that
records what tags are allowed (and perhaps even how they might be nested and
what attributes they may have). For instance, in presenting the search
results I have to deal with HTML tags that might be present, and it would be
pleasant if this would automatically adapt if new tags are allowed.

-- Jan Hidders


subject: [Wikipedia-l] Wikification function proposal

in_reply_to: <1014847080.26359.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Wed, Feb 27, 2002 at 01:57:58PM -0800

body:
Brion L. VIBBER wrote:
> Question: why do we have the separate forms [X] for external links and
> [[X]] for internal links? Unless we're going to add http:, ftp:, news:
> or mailto: namespaces, I don't see much possibility of conflict.
>
> There may be good historical reasons I am not aware of.

"Good" I don't know, but the historical reasons are these:

In the original UseMod, CamelCase was internal, and [] was external.
We wanted spaces, so someone came up wtih the idea of [[]].

--Jimbo


body:
On mer, 2002-02-27 at 13:30, Magnus Manske wrote:
> The functions that could be performed (and that I can think of) are:
>
> 1. Replacement of HTML tags by wiki tags (namely, "<b>" and "<i>", maybe
> "<h1>" as well)
> 2. Eliminating links to redirect pages by changing the link in question to
> the target of the redirect

Hmm, maybe. Sometimes redirects are wrong, though!

> 3. Marking [broken links]] and [[more broken links]
> 4. Optimizing external links with too many [] (like
> [[http://www.google.com]])

Question: why do we have the separate forms [X] for external links and
[[X]] for internal links? Unless we're going to add http:, ftp:, news:
or mailto: namespaces, I don't see much possibility of conflict.

There may be good historical reasons I am not aware of.

> 5. Optimizing [[link|links]] to [[link]]s

Please don't! Not only is the result very ugly, but it would lead to
inconsistent link appearance for irregular and regular plurals
([[foot|feet]] vs [[hand]]s), never mind the issue of other languages.

> 6. Removing [[Talk:thispage|Talk]] links (at the end of the page)
>
> I am sure you can think of some more details that have always bugged you,
> but that were (be themselves) not important enough to call for a function;)
>
> We could use this for rather fancy things as well:
>
> 7. In the preview, mark words (or word combinations) that are currently
> plain text, but that do exist as a topic in the database (to find pages one
> could link to).
> 8. In the preview, mark all numbers that could be dates (more link
> candidates).
> 9. Automatically put the title phrase in bold if it appears in the first
> paragraph.

This would be even more fun if we had a WYSIWIG editor. Just think of
all the myriad colors and wavy underlines and mysterious icons we could
bedazzle the poor confused users with! Or, wait, were we supposed to be
*nice* to the users? :)

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] European Communities Copyright

in_reply_to: <200202272221.g1RMLFm27385@ross.bomis.com>; from koyaanisqatsi@nupedia.com on Wed, Feb 27, 2002 at 02:21:15PM -0800

body:
koyaanisqatsi at nupedia.com wrote:

> >Reproduction is authorised, provided the source is acknowledged,
> save
> >where otherwise stated.
>
> <snip>
>
> >Is this compatible with the GNU FDL? Can we copy the content to
> >wikipedia?
> >
>
> not really.  we can't guarantee that it will have acknowledgement--
> anyone could come along and delete it.  other thoughts?

That's right.

But additionally, this license only authorized reproduction, not
modification.

--Jimbo


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020227/b5a33312/attachment.diff


references:
<ILENJBCFHGHELEBFPPBGEELKCFAA.Magnus.Manske@epost.de>
	<1014847080.26359.0.camel@rdaneel.moisty.org>
	<20020227135557.D19445@joey.bomis.com>

body:
On mer, 2002-02-27 at 13:55, Jimmy Wales wrote:
> Brion L. VIBBER wrote:
> > Question: why do we have the separate forms [X] for external links and
> > [[X]] for internal links? Unless we're going to add http:, ftp:, news:
> > or mailto: namespaces, I don't see much possibility of conflict.
> >
> > There may be good historical reasons I am not aware of.
>
> "Good" I don't know, but the historical reasons are these:
>
> In the original UseMod, CamelCase was internal, and [] was external.
> We wanted spaces, so someone came up wtih the idea of [[]].

(thunks head) Ah, right. [http://some.url Better title] vs
[Some Topic|Better title]

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Recent Changes

in_reply_to: <ILENJBCFHGHELEBFPPBGGELDCFAA.Magnus.Manske@epost.de> from "Magnus Manske" at Feb 26, 2002 10:13:36 PM

body:
Can someone fix the Recent Changes, or am I the only one seeing
dates like

Wednesday, December 31, 1969

etc. on the page whenever anyone edits a userpage?


body:
On mer, 2002-02-27 at 15:40, kband at www.llamacom.com wrote:
> >From a user perspective, I'd rather have more redirects than
> links like [[Winter Olympic Games|Winter Olympics]], since the
> redirects are "invisible", while the pipe-linking is an ugliness
> on the edit side (especially when they accumulate).
>
> Another reason that redirecting is better is because it reduces
> duplication of work--instead of everyone having to write
> [[democracy|democratic]] every time they want to link "democratic",
> a single redirect allows everyone to just write [[democratic]].
>
> But I'd also like the REDIRECT functionality improved.

What kind of improvements?

> The new software renders [[hand|hands]] and [[hand]]s the same
> as a single link (try it!), so it would be a nice optimization on the
> edit side to use the latter. Again, I like the reduction of pipes
> as much as possible.

Hey, never noticed that before, that's kinda nice! Objection withdrawn.
(Though I would note two things about this feature: first, it's
currently restricted to word extensions using the lowercase Latin
letters a-z. Second, some languages are not normally written with spaces
between words; a lowercase English word thrown in right after a linked
word could extend a link where it's not really warranted. This might be
something we want to be able to enable/disable on a per-wiki basis.)

Note to Magnus: would it kill you to put a few comments in your code? :)
I understand what that part's doing now that the effect has been
explained to me, but...

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: [Wikipedia-l] Allowing HTML for ruby text?

body:
From: "Jan Hidders" <hidders at uia.ua.ac.be>
>
> As a technical remark I would like to see a central array or something
that
> records what tags are allowed (and perhaps even how they might be nested
and
> what attributes they may have). For instance, in presenting the search
> results I have to deal with HTML tags that might be present, and it would
be
> pleasant if this would automatically adapt if new tags are allowed.

On second thought, I don't really need it because in this case, i.e., the
presentation of search results, it is probably better to simply remove all
HTML tags anyway.

-- Jan Hidders


in_reply_to: <1014847080.26359.0.camel@rdaneel.moisty.org> from "Brion L. VIBBER" at Feb 27, 2002 01:57:58 PM

body:
>
> On mer, 2002-02-27 at 13:30, Magnus Manske wrote:
> > The functions that could be performed (and that I can think of) are:
> >
> > 1. Replacement of HTML tags by wiki tags (namely, "<b>" and "<i>", maybe
> > "<h1>" as well)
> > 2. Eliminating links to redirect pages by changing the link in question to
> > the target of the redirect
>
> Hmm, maybe. Sometimes redirects are wrong, though!


body:
From: "Brion L. VIBBER" <brion at pobox.com>
>
> You can also set set_time_limit(9999) or some such. No nasty timeouts!

Ah, great!! That really supersedes the Apache setting? You learn something
new every day. :-) Or rather, :-/. I should have known this earlier on. I
read that this only works if PHP does not run in safe mode, but I suppose
that since the default is off, Jimbo probably has it not running in safe
mode anyway.

-- Jan Hidders


body:
From: "Jimmy Wales" <jwales at bomis.com>
>
> This answered my question.
>
> When I ran this by hand, it took a long time, so I better just stick with
1000 and
> click it a bunch of times.  That's no bother to me.
>
> If I drop the tables will the site break until I create them again?

WAIT!! It just occurred to me that there is a problem because you probably
by now have dropped the cur_linked_links and cur_unlinked_links columns,
right? The script updLinks.php assumes they are still there and gets its
information for the new tables from them. So just running it again won't
work.

No panic, the linking information is still there except we now need a
different script because we need to get it out of the cur_text field. This
is a bit of a problem because I really have to prepare some lessons for
tomorrow. Any of the other programmers feel able to do this?

-- Jan Hidders


from_name: Kurt Jansson

subject: [Wikipedia-l] AT&T

body:
Hello everybody!

After some searching and many errors I figured out that the AT&T article
is under [[ATT]]. There seems to be a problem with the "&". I don't know
if it can be fixed, but maybe we can find a way around this. The errors
I got:

First I searched for "AT&T":
---------
 Sorry, your boolean search query contains the following errors:

[!! SYNTAX ERROR: the word 'AT' is too short, the index requires at
least 4 characters]
[!! SYNTAX ERROR: illegal symbol '&'; ignored]
[!! SYNTAX ERROR: the word 'T' is too short, the index requires at least
4 characters]
------------

By searching with google I got:
http://www.wikipedia.com/search.fcgi?request=AT%26T
----------
Error 500
Jimbo says: Due to traffic increases to levels that the original UseMod
wiki was not designed to handle, we are experiencing intermittant
problems. Please email me with the time and nature of the problem you
experienced, as I am working to eliminate the bugs as quickly as I can.
jwales at bomis.com.
----------

And: press on "[AT&T Unix]?" in the [[BSD]] article and see what happens
:-(

Bye,
Kurt