body:
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. Ok. I'll try
to have the new script ready by tomorrow.

-- Jan Hidders


list: wikitech-l

source: pipermail-mbox

from_name: Brion L. VIBBER

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

body:
All right, I've reworked removeHTMLtags() a little bit and put the ruby
tags into the allowed list.

Please everybody, give it a try. Throw some good HTML at it and make
sure it doesn't break, and some bad HTML at it to make sure it breaks
politely. (I don't want a repeat of the recent cut-in-half
talk:Beryllium incident!)

I've also changed most of the &s in URLs into &s so that the HTML
validator likes us better, and moved the </BODY></HTML> tags to *after*
the page content instead of before it. *cough cough*

-- brion vibber (brion @ pobox.com)


list: wikipedia-l

from_name: João Mário Miranda

subject: [Wikipedia-l] European Communities Copyright

body:
This is the Copyright Notice of European Communities Web Site:

-------------------------
Copyright Notice
? European Communities, 1995-2002

Reproduction is authorised, provided the source is acknowledged, save
where otherwise stated.

Where prior permission must be obtained for the reproduction or use of
textual and multimedia  information (sound, images, software, etc.),
such permission shall cancel the abovementioned general permission and
indicate clearly any restrictions on use.
-------------------------------

Is this compatible with the GNU FDL? Can we copy the content to
wikipedia?

--
jo?o
http://www.nonio.com


from_name: Magnus Manske

subject: [Wikipedia-l] Recent Changes

body:
An accident with the coordination of the database improvement. We're working
on it;)

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of
> kband at www.llamacom.com
> Sent: Wednesday, February 27, 2002 9:55 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] Recent Changes
>
>
> 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?
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Lars Aronsson

subject: [Wikitech-l] Re: [Wikipedia-l] AT&T

body:
On wikipedia-l, Kurt Jansson wrote:

> 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 once fixed this in UseModWiki for another site, so it can be fixed.
Just replace & with %26 in any externally visible URL.  The page URL
should then be:

    http://www.wikipedia.com/wiki/AT%26T

(The + in C++ is a lot harder, and CPlusPlus is really ugly.  But this
too can be fixed.)

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Wikification function proposal

body:
A topic that was briefly discussed several times on this list in the past is
the automated "wikification" of pages. I think it is time to work on that,
is there is a need.

Some wish to ban all HTML code from the wiki articles, though I find this
rather extreme. Others prefer to use HTML as much as possible, especially if
copying from other (free) web sources.

IMHO, the best was is to use wiki tags where they are available, and leave
the complicated stuff (like tables) to HTML. A function that could help with
that could be invoked as follows:

1. After or prior to editing, as standard setting. This would enforce
wikification, but reduce the "editing freedom", thus probably not a good
idea.
2. After or prior to editing, as a user option. If you check that option on
your user page (default:off), wikification would take place when you edit an
article.
3. As a button on the edit page. Like "Preview", maybe "Wikify & Preview".

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
3. Marking [broken links]] and [[more broken links]
4. Optimizing external links with too many [] (like
[[http://www.google.com]])
5. Optimizing [[link|links]] to [[link]]s
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.

Thoughts? Comments? Threats? ;)


from_name: Michel Clasquin

body:
On Wednesday 27 February 2002 23:30, Magnus Manske wrote:

> A topic that was briefly discussed several times on this list in the
> past is the automated "wikification" of pages. I think it is time to
> work on that, is there is a need.

<snip>

> Thoughts? Comments? Threats? ;)

Yeah. If you don't implement this by tomorrow I'm coming to get you!

Apart from tables, the only html code I have consistently found
indispensable is <br>. We certainly don't need things like <p> </p> pairs.
My vote is for a "Wikfy and preview" button.

I thought #5 was being done already? #7 through 9 would need to be thought
about carefully. For instance, "Joe Bloggs died in [[1978]] at the ripe
old age of 92"  should not become "Joe Bloggs died in [[1978]] at the ripe
old age of [[92]]".  A newbie might just OK the change.

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

... Linux users and the women who chase them - next Oprah!


body:
On ?a?, 2002-02-28 at 08:06, Jan Hidders wrote:
> From: <kband at www.llamacom.com>
> >
> > The new software renders [[hand|hands]] and [[hand]]s the same
> > as a single link (try it!), [...]
>
> Hmm, isn't that a bit language specific? I'd prefer it if we didn't have
> language specific things in our central code base.

What the actual code does isn't quite so specific. If a [[link]] is
immediately followed by some chunk of the lowercase letters [a-z], the
link gets expanded over that area. So the entire word will appear as a
link in:
  [[link]]s = [[link|links]]
  [[link]]ing = [[link|linking]]
  [[ligilo]]n = [[ligilo|ligilon]]
  [[I forgot the]]space = [[I forgot the|I forgot thespace]]
etc.

-- brion vibber (brion @ pobox.com)


from_name: Tei

subject: [Wikipedia-l] AT&T

body:
 need to be urlencode before to use as data in wikipedia mod
 and un-urlencode to use as key.

 no?

 problem here is that data as been "fixed" without urlcodding from day 1 of
wiki (maybe)

 -- Tei

At 18:27 27/02/02 +0100, you wrote:
>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
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>


from_name: Jan Hidders

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

body:
First my apologies for replying this late, but my students go first.

From: "Brion L. VIBBER" <brion at pobox.com>
>
> I just committed a rebuildLinks.php, does it look like it's doing the
> right things?

I think it doesn't work correctly for links between <pre> tags. Anyway, I've
committed a new version that uses the same code as that which is run when a
page is updated. This script is more robust than my previous one (you can
run it as many times as you like for the same records) and tells you a bit
more about what is going on. It also tells you when all records have been
processed and doesn't present you another link then.

So Jimbo, can I ask you to try the new script rebuildLinks.php?

-- Jan Hidders


body:
From: <kband at www.llamacom.com>
>
> The new software renders [[hand|hands]] and [[hand]]s the same
> as a single link (try it!), [...]

Hmm, isn't that a bit language specific? I'd prefer it if we didn't have
language specific things in our central code base.

-- Jan Hidders


body:
From: "Magnus Manske" <Magnus.Manske at epost.de>
>
> 1. Replacement of HTML tags by wiki tags (namely, "<b>" and "<i>", maybe
> "<h1>" as well)

To be honest, I'm uncomfortable with the idea of fiddling with the input of
the user, even if it is only an option. In general software that tries to
guess what I *actually* meant usually irritates me endlessly. Adding more
and more options also doesn't make the software more usable and maybe even a
bit scary for novice users.

If we really don't want these tags [don't worry, I know I'm the only one who
feels that way :-)] then we have to be unequivocal about it; we replace them
everywhere with a script and from that moment on the tags we don't want
don't work anymore. But some halfhearted approach that is optional is not
going to work and only makes things more complicated then they have to be.

> 2. Eliminating links to redirect pages by changing the link in question to
> the target of the redirect

I don't see what problem is solved by that. Do you also want the change all
the links on existing pages if a page with real contents becomes redirected?

> 3. Marking [broken links]] and [[more broken links]

I never had problems with finding those now.

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

Who says it has too many brackets? I would say that this is "[<link to
google>]".

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

Language specific.

> 6. Removing [[Talk:thispage|Talk]] links (at the end of the page)

It's better to do this everywhere in one big fell swoop with a script
instead of waiting until somebody comes along to edit the page and has the
option turned on.

> 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;)

Well what does bug me is that the replacement of ~~~ doesn't show up in the
preview. And wouldn't it be nice if we always added the time with a
signature? Sorry for this shameless plug, but you asked. :-)

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

Ah, now that is something that I would find very useful, especially when
wikifying imported stuff. Doesn't sound very cheap though so it should
definitly be an option or a special link you can click to do this.

> 8. In the preview, mark all numbers that could be dates (more link
> candidates).

That's overdoing it IMO. If the user wanted to link it he or she only needed
to place brackets around it.

> 9. Automatically put the title phrase in bold if it appears in the first
> paragraph.

Could be useful, but in my opinion not useful enough for adding yet another
option that can be turned on and off.

> Thoughts? Comments? Threats? ;)

What I am a bit missing is a priority list of bugs that is maintained by our
great leader (yes, that's you :-}) and that we should be working on. That
would not only be useful for us, but also give the users an idea of what we
are doing about their problems. Or would that make you feel too much like a
manager? :-P

-- Jan Hidders


from_name: Axel Boldt

subject: [Wikitech-l] Showing full IP addresses on History pages

body:
Currently, we are showing full IP addresses on history pages. Is that
a bug or a feature?

Axel


subject: [Wikipedia-l] Editing using the Opera Web Browser

body:
On ven, 2002-03-01 at 06:07, David Jones wrote:
> It looks like the close tags for HEAD and BODY and HTML are in the wrong
> place, and that META is closed.
>
> I guess that upsets opera enough to stop it rendering properly.
>
> Any chance of a fix / some documentation so that I can do it myself?

I fixed all these yesterday. Jimbo, the fixes are in wiki.phtml, could
you update it when you get a chance?

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] IP numbers on History pages?

body:
On ven, 2002-03-01 at 06:20, Axel Boldt wrote:
> Currently, we display full IP numbers on history pages. Is that a bug
> or a feature? Looking at the code in special_recentchangeslayout.php, l.
> 91-100, it appears that the full IP (including last 3 digits) was put
> in deliberately (or else I can't see the point of that code).

I'm not the one wot did it, but the impression I seem to have from
earlier discussions is that this was done so that the full IP would be
available for Larry et al to ban vandals with.

Perhaps we should check that the current user has is_sysop and only then
show a full IP?

-- brion vibber (brion @ pobox.com)


from_name: Larry Sanger

body:
On 1 Mar 2002, Brion L. VIBBER wrote:

> On ven, 2002-03-01 at 06:20, Axel Boldt wrote:
> > Currently, we display full IP numbers on history pages. Is that a bug
> > or a feature? Looking at the code in special_recentchangeslayout.php, l.
> > 91-100, it appears that the full IP (including last 3 digits) was put
> > in deliberately (or else I can't see the point of that code).
>
> I'm not the one wot did it, but the impression I seem to have from
> earlier discussions is that this was done so that the full IP would be
> available for Larry et al to ban vandals with.

I didn't know that!  Maybe there's a way to do it without making the full
IP public?  (Like this cryptic "ban this IP" link I sometimes see, but
which I still don't quite understand...and dare not use...)


body:
From: "Brion L. VIBBER" <brion at pobox.com>
> On ?a?, 2002-02-28 at 08:06, Jan Hidders wrote:
> > From: <kband at www.llamacom.com>
> > >
> > > The new software renders [[hand|hands]] and [[hand]]s the same
> > > as a single link (try it!), [...]
> >
> > Hmm, isn't that a bit language specific? I'd prefer it if we didn't have
> > language specific things in our central code base.
>
> What the actual code does isn't quite so specific. If a [[link]] is
> immediately followed by some chunk of the lowercase letters [a-z], the
> link gets expanded over that area. So the entire word will appear as a
> link in:
>   [[link]]s = [[link|links]]
>   [[link]]ing = [[link|linking]]
>   [[ligilo]]n = [[ligilo|ligilon]]
>   [[I forgot the]]space = [[I forgot the|I forgot thespace]]

Ok. Then I have no problem with it.

-- Jan Hidders


body:
From: "Jan Hidders" <hidders at uia.ua.ac.be>
>
> So Jimbo, can I ask you to try the new script rebuildLinks.php?

Hm, I forgot to explain the procedure. Here it is:

Step 1: run the script in your browser and keep on clicking the presented
link until it says it's ready.

That's it. So you don't have to empty the tables, recreate the indexes, or
anything. It also clears up any wrong links that might have been inserted
before.

-- Jan Hidders


from_name: 421621 at ingta.unizar.es

subject: [Wikipedia-l] Suggestion #3

body:
How wiki work:

Edit this page --> generate a text plain

<user edit this page>

this text plain --> generate a html page

 - - -

Suggestions #3-A

 #Bookmarks for Articles

 Every page has a key called "add this item to your route" You can collect
favorites pages with this.

/*

Suggestions #3-B

 #WikiExplorer

Delphi app (writen by me) that hidden the fact you hare navigating a web page,
and shows you a book view, with bookmarks tab, preloading, etc...  GPL. I will
release the source code soon in my berlios ftp space... (maybe)

*/

Suggestions #3-C

 #Globals

 A way to attach a style CCS file to the page. Ex:
 "<#CSS MathPage>"

Suggestions #3-D

 #Templates

 A way to aply and code a template por wiki pages:
 "<#TEMPLATE DuneBookCharecters>"

1 saludo
Tei (RatBert)

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/


subject: [Wikipedia-l] My resignation

body:
Dear friends:

I hereby resign as editor-in-chief of Nupedia and I also hereby give up
any position of authority I had with Wikipedia; assuming particularly that
funding will not be able to be found for the position of Nupedia
editor-in-chief (see below), I don't intend to work on either project any
significant amount within the next few months, and very possibly ever.

Obviously, I owe you an explanation.

First, let me stress that this has *nothing* to do with my lack of faith
in the projects or in the nobility of the mission.  It also has absolutely
nothing to do with my relationship with Jimbo or Bomis, which remains
friendly.  I really *do* hope the projects go on to great successes, even
without me.  It is even still possible even that Bomis, or a future
Nupedia Foundation, will find the money to pay for my job, and I might be
in a position to come back to the old job.  But I'm frankly not expecting
this.

As you know, since the beginning of February, I've been working on
Wikipedia and Nupedia as a part-time volunteer.  I haven't been able to do
nearly as much as I wish I could do, but job-hunting and money-making
activities necessarily occupy a great deal of my time.  Unfortunately, I
do not expect to see, within the foreseeable future, any sort of
compensation for the time and responsibility I've continued to hold in the
projects.  Now that I'm unemployed, I can ill afford to spend my free time
this way.  This is, I'm afraid, *by far* the most important reason for my
resignation.

Second, a little bit of history will help to explain this as well.  I was
more or less offered the job of editing Nupedia when I was, as an ABD
philosophy graduate student, soliciting Jimbo's (and other friends')
advice on a website I was thinking of starting.  It was the first I had
heard of Jimbo's idea of an open content encyclopedia, and I was delighted
to take the job.  So I want this to be clear: I did not *set out* to be a
leader and crusader and organizer.  As a job, this has been the best I've
ever had.  But this project is not something I would have chosen as a
hobby, frankly; *with* *my* *spare* *time*, even after having started it
and having grown to care a lot about it, I must admit I'd rather be
spending time with my wife, reading and writing philosophy, and playing
fiddle.  (I'm making a little money now teaching fiddle in Columbus and
enjoying that immensely.)

A third important reason is that I feel I simply cannot do a good job
working only part-time.  It seems like every time I sit down to do a
little work on Wikipedia or Nupedia, I am now asking myself, "What's the
use?  I don't have any time to do anything of importance."  If I can't do
the job right, what's the point of doing it at all?

So--I wish Wikipedia all the best and hope that it can find its way
forward without my involvement.  Wikipedians, don't take my departure as
an excuse to leave yourself.  My departure should not be taken as a
reflection on Wikipedia, or you.  It still might succeed brilliantly.
It's very important that you continue to edit each others' work, that you
encourage in each other good habits, that you welcome new contributors,
and that you praise good work when you see it.  As for Nupedia, obviously,
the only way it can be revived is if it either finds money to pay an
editor-in-chief or perhaps an emeritus professor who is willing to
volunteer.  I am no longer going to pretend*to be able to be
editor-in-chief as a part-time volunteer--even if I had the desire and the
spare time. I'd be interested in helping to organize it--again--as an
employee, but I'm not holding my breath.

I will try to assist in any transitioning, if any needs to be done (e.g.,
listservs I now moderate will probably have to be made unmoderated).  I
should continue to be reachable at lsanger at nupedia.com, but not via
mailing lists (I'll be unsubscribing).  Otherwise, I feel a clean break is
necessary.  I have no hard feelings at all for Jimbo or the others at
Bomis, and I wish to thank and say "best wishes" to--well, a long list of
people in both Wikipedia and Nupedia. You know who you are.  If you don't
mind, I'd rather not name names, for fear of leaving anyone out.

By the way, if you've got a serious job lead for me, please let me know.
:-)

All the best,
Larry Sanger, Ph.D.
Ex-editor-in-chief, Nupedia
Ex-chief organizer, Wikipedia


subject: [Wikitech-l] "watch this article" for special: pages

body:
Should there really be a link "watch this article for me" for pages in the
special: namespace? This causes an error for the watch-page-links page, and
I think the concept of putting a generated page in a watch-list is strange
anyhow.

-- Jan Hidders

PS. I also saw a redirect to a special page from a conventional page. If
that happens you see the special page with the coloring of a normal page.

PPS. I think that the namespaces mentioned should always be just one: the
talk: article, and it should not be called namespace but something like
"discuss this article here".


from_name: Jimmy Wales

subject: [Wikipedia-l] Advertisements

body:
With the resignation of Larry, there is a much less pressing need for
funds.  Therefore, all plans to put advertising of any kind on the
wikipedia is called off for now.

We will move forward with plans for a nonprofit foundation to own
wikipedia, and possibly to solicit donations and grants to help us
carry out our mission.  (Ironically, I think that grant money would
come with many annoying strings attached, which we could not accept,
comparted to advertising money, which is virtually 100% string-free.)

Just as the National Geographic Society is supported in large part by
advertisments in the National Geographic Magazine, I expect this to be
a potentially necessary thing at some point in the future, if we wish
to have an impact beyond our own little corner of the Internet.  (And,
I think we all do.)

But for now, there's no pressing need unless and until we find chaos
descending on us from the lack of constant oversight.

The hosting of Wikipedia I can continue to do for no charge for the
foreseeable future.  Even if Wikipedia traffic were to grow by a
factor of 10, I would be willing to absorb all the bandwidth and
hardware costs.  If it grows beyond a factor of 100 or 1000,
obviously, alternative solutions would have to be found.


subject: [Wikipedia-l] My resignation

body:
Oh, how nice and gracious this was.  Oh, thank you SO much, Cunctator.

I'm sure glad I won't have to deal with you anymore, Cunctator.  You're a
friggin' piece of work.

On Fri, 1 Mar 2002 kband at www.llamacom.com wrote:

> >
> > Dear friends:
> >
> > I hereby resign as editor-in-chief of Nupedia and I also hereby give up
> > any position of authority I had with Wikipedia; assuming particularly that
> > funding will not be able to be found for the position of Nupedia
> > editor-in-chief (see below), I don't intend to work on either project any
> > significant amount within the next few months, and very possibly ever.
>
> I know that we've hardly been on the best of terms, but I want you to know
> that I'll always consider you one of the the most important Wikipedians,
> and I hope that you'll always think of yourself as a Wikipedian, even
> if you don't have much time to contribute.
>
> Herding cats ain't easy; you did a good job, all things considered.
>
> --the cunctator
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Advertisements

body:
On Fri, 1 Mar 2002 kband at www.llamacom.com wrote:

> >> But for now, there's no pressing need unless and until we find chaos
> > descending on us from the lack of constant oversight.
>
> Which really means that its important for all of us, every contributor,
> to feel vested with responsibility. We are all responsible for oversight.

I agree.  I think that the Cunctator is one person you have to watch like
a hawk, however, and he of all people has no moral right to say what he is
saying here.

> > The hosting of Wikipedia I can continue to do for no charge for the
> > foreseeable future.  Even if Wikipedia traffic were to grow by a
> > factor of 10, I would be willing to absorb all the bandwidth and
> > hardware costs.  If it grows beyond a factor of 100 or 1000,
> > obviously, alternative solutions would have to be found.
>
> Speaking of which, I think it would be great if we started thinking
> about mechanisms for distributing the hosting of Wikipedia. Does
> anyone have any thoughts on how a (to some degre) distributed solution
> could work?

Frankly, this is hardly the time to bring this up.  You have a lot more
pressing issues before you.

Larry


subject: [Wikipedia-l] Advertisements

in_reply_to: <20020301211617.28032.qmail@www.llamacom.com>; from kband@www.llamacom.com on Fri, Mar 01, 2002 at 03:16:17PM -0600

body:
> Speaking of which, I think it would be great if we started thinking
> about mechanisms for distributing the hosting of Wikipedia. Does
> anyone have any thoughts on how a (to some degre) distributed solution
> could work?

It strikes me, from a technical point of view, as very unlikely that
distributed hosting will ever be the right solution.  Distributed
funding, maybe, but distributed hosting just really doesn't make
sense.

--Jimbo


from_name: David Jones

body:
I am just trying out Opera on Windows (www.opera.com) (Version 6.01
Build 1041 Platform Win32).

I can't edit a page.

For example,

http://www.wikipedia.com/wiki/SPARC&action=edit

because the HTML seems to be bad.  When I click the "Edit this page"
link I see a page which has an editable text box with no text in, and all
the text that is obviously supposed to be in the box has been rendered
outside of the box.

I validated the edit page (
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.wikipedia.com%2Fwiki%2FSPARC%26action%3Dedit&charset=%28detect+automatically%29&doctype=Inline
)

And got the following:

::  Line 22, column 6:
::
::
::          ^
::
::  Error: end tag for element "HEAD" which is not open; try removing the
::  end tag or check for improper nesting of elements
::
::  Line 22, column 31:
::
::
::                                   ^
::
::  Error: element "BODY" not allowed here; check which elements this
::  element may be contained within

And much more.  Indeed, looking at the HTML produced (just lines 18 - 24):

  18: a.newlink { color: black; text-decoration: none; }
  19: .newlinkedge { display: inline; }
  20: //--></style>
  21: <link rel="shortcut icon" href="/favicon.ico" />
  22:
  23:

  24:
SPARC

It looks like the close tags for HEAD and BODY and HTML are in the wrong
place, and that META is closed.

I guess that upsets opera enough to stop it rendering properly.

Any chance of a fix / some documentation so that I can do it myself?

Cheers,
 drj


subject: [Wikipedia-l] OK, I've unsubscribed

body:
OK, I've unsubscribed from wikipedia-l and bunches of other lists.  I'll
still be on advisory-l and nupedia-l in case anything interesting happens
there.

Larry


from_name: kband at www.llamacom.com

subject: [Wikipedia-l] My resignation

body:
>
> Dear friends:
>
> I hereby resign as editor-in-chief of Nupedia and I also hereby give up
> any position of authority I had with Wikipedia; assuming particularly that
> funding will not be able to be found for the position of Nupedia
> editor-in-chief (see below), I don't intend to work on either project any
> significant amount within the next few months, and very possibly ever.

I know that we've hardly been on the best of terms, but I want you to know
that I'll always consider you one of the the most important Wikipedians,
and I hope that you'll always think of yourself as a Wikipedian, even
if you don't have much time to contribute.

Herding cats ain't easy; you did a good job, all things considered.

--the cunctator


subject: [Wikipedia-l] Advertisements

body:
>> But for now, there's no pressing need unless and until we find chaos
> descending on us from the lack of constant oversight.

Which really means that its important for all of us, every contributor,
to feel vested with responsibility. We are all responsible for oversight.

Chaos will come if a) we are unable to work together to provide that
oversight or b) if too many of us don't feel that responsibility (the
equivalent of a representative democracy where only 40% vote and only
2% ever run for office).

> The hosting of Wikipedia I can continue to do for no charge for the
> foreseeable future.  Even if Wikipedia traffic were to grow by a
> factor of 10, I would be willing to absorb all the bandwidth and
> hardware costs.  If it grows beyond a factor of 100 or 1000,
> obviously, alternative solutions would have to be found.

Speaking of which, I think it would be great if we started thinking
about mechanisms for distributing the hosting of Wikipedia. Does
anyone have any thoughts on how a (to some degre) distributed solution
could work?

--tc


body:
Currently, we display full IP numbers on history pages. Is that a bug
or a feature? Looking at the code in special_recentchangeslayout.php, l.
91-100, it appears that the full IP (including last 3 digits) was put
in deliberately (or else I can't see the point of that code).

Axel


subject: [Wikipedia-l] Suggestion #3

body:
On Friday 01 March 2002 13:02, 421621 at ingta.unizar.es wrote:

>  #Bookmarks for Articles
>
>  Every page has a key called "add this item to your route" You can
> collect favorites pages with this.

It exists already, called "Watch this article" IIRC

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

... Linux users and the women who chase them - next Oprah!


subject: [Wikipedia-l] Distributed hosting

body:
>
>
> > Speaking of which, I think it would be great if we started thinking
> > about mechanisms for distributing the hosting of Wikipedia. Does
> > anyone have any thoughts on how a (to some degre) distributed solution
> > could work?
>
> It strikes me, from a technical point of view, as very unlikely that
> distributed hosting will ever be the right solution.  Distributed
> funding, maybe, but distributed hosting just really doesn't make
> sense.
>
I know it's rather complicated, but vast amounts of comp sci research
are going into the development of all kinds of distributed networks
(under the buzzword p2p), and it makes perfect sense for a project like
this, *if* the tech actually existed. I know it's pretty blue sky
now, but it does make sense if you ignore the fact that it would be
freaking difficult to implement.

'Swhy I prefer theoretical physics to engineering. Let someone else
work out the fussy details.

:)

-tc


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] Advertisements

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


subject:
[Wikipedia-l] Offline editing and conflicts (was Re:  [Wikipedia-l]
 Advertisements)

body:
On ven, 2002-03-01 at 20:50, koyaanisqatsi at nupedia.com wrote:
> Lars Aronsson wrote:
> >I think the hosting of the server should be left to Jimbo to decide.
> >But what I'd really like to see is something like groove.net, where I
> >can keep an offline copy on my own computer, edit articles locally,
> >and sync the changes with the server the next time I'm online.  I'm
> >not on a modem connection, but I'm moving with my laptop and wireless
> >LAN between home, workplaces and cafes.  This of course would be a
> >major software change.  Some two-way synchronization protocol (like
> >unison) would be needed.
>
> what if someone else edits your article after you last see it?  how
> would the software reconcile different edits from the same point?  i
> rather prefer the current system, where you can go in and choose the
> best bits of each to save.  I don't foresee software being that
> sophisticated within our lifetimes.  maybe you have some ideas about
> it.

Changes that don't conflict with one another could be integrated fairly
easily, as long as the upload indicates which revision of the article
you were working from. (CVS does this with source code, for instance.)

Actual conflicts -- changes that affect the same part of the text in
both revisions -- are more difficult. Probably we would want to handle
this the same way that we do it now within the web interface: throw up
an edit conflict and ask the user to manually reconcile the two
versions.

The edit conflict process needs to be improved in any case; including a
diff with the edit conflict screen has been recommended, which I
heartily endorse, but the diff function is currently quite limited:
removes and adds are not shown in sequence, and small changes in large
paragraphs are very difficult to see.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Pages that link here...

body:
I just noticed that the "pages that link here"
on http://www.wikipedia.com/wiki/Belarus/History
does not list http://www.wikipedia.com/wiki/Belarus
which I think it should.  Shouldn't it?
I think this is how it used to work a few weeks ago.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikitech-l] whitespace in search

body:
If I search for "van eyck" (with the whitespace, but sans the quotes),
I get an ugly error message.  Searching for "eyck" actually solves my
particular problem for the moment, but the error message is still
ugly.  Is it really such a crime to want to search for a string that
includes the whitespace?  Perhaps this could be explained somewhat
more politely?

Also, if I search for "van\ eyck", the error message comes up and the
input box contains "van\\ eyck".  Maybe there is a potential risk for
a buffer overrun or something more exotic here?  I think the input
string should be quoted before being used in a regexp search.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikitech-l] Hide minor edits in recent changes

body:
If I set my preferences to hide minor edits in the recent changes
listing, then I want to see the most recent major edit for that page.
That is how UseModWiki worked.  It seems the new software doesn't list
the page at all if the most recent change was a minor edit.

Example:
 1) I set my prefs to hide minor edits.
 2) I make a major edit on a page.
 3) I view recent changes.  The page is listed.
 4) I make a minor edit on the same page.
 5) I view recent changes. Now the page isn't listed at all!

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Advertisements

body:
tc wrote:
> Speaking of which, I think it would be great if we started thinking
> about mechanisms for distributing the hosting of Wikipedia. Does
> anyone have any thoughts on how a (to some degre) distributed solution
> could work?

I think the hosting of the server should be left to Jimbo to decide.
But what I'd really like to see is something like groove.net, where I
can keep an offline copy on my own computer, edit articles locally,
and sync the changes with the server the next time I'm online.  I'm
not on a modem connection, but I'm moving with my laptop and wireless
LAN between home, workplaces and cafes.  This of course would be a
major software change.  Some two-way synchronization protocol (like
unison) would be needed.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] kuro5hin article

body:
An article about wikipedia was posted at kuro5hin:

http://www.kuro5hin.org/story/2002/3/1/163730/6996

Joao


subject: [Wikitech-l] Signature with date

body:
You can now sign with automatic (server) date using ~~~~ (4x "~").

Magnus


subject: [Wikipedia-l] Advertisements

body:
> >major software change.  Some two-way synchronization protocol (like
> >unison) would be needed.
>
> what if someone else edits your article after you last see it?

This is something that existing systems like CVS and unison already
deal with.  When I decide to sync, the software would inform me about
any editing conflicts, and I would have to either resolve them or
discard my own changes.  The edit conflict could be moved to my local
copy, so I could resolve it offline and commit it the next time I'm
online (provided the same page hasn't changed again, in which case
there would be a new editing conflict).  My offline software would
need a "recent conflicts" listing.  :-)  As I said, this would be a
major software change.  But it is still a sweet dream, isn't it?

> i rather prefer the current system,

Which is fine.  The current system would still work as it does today.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikitech-l] SQL dump

body:
I just commited a "special_sqldump.php" file with a function that creates a
SQL dump as a zipped file in the upload directory each time it is called.
Runs about 21 sec on my system. I didn't link it from anywhere else yet, so
you'll have to access the page through "...../wiki/special:sqldump". After
it finished, you'll get a direct link to the file and a file size in KB.

Please have a look.

Magnus


from_name: Julie Hofmann Kemp

subject: [Wikipedia-l] Everything in the last digest

body:
Larry --

It's a damned shame and I'll miss you.  That said, I know what it's like
to have feet in both the academic and money making worlds, and know
exactly the kind of calls you're having to make.  Ugh.

Cunctator et al --

Why would we want to distribute hosting?  And for that matter, what's
wrong with advertising, provided it's done as subtly as possible, and
not from various merchants of death ;-) (which I still think is for
Bomis to decide -- I may feel very proprietary about a lot of stuff
here, but I  still remember I'm on somebody else's playground.  Jimbo et
al. have  been very cool about trying to  get input, but business
decisions should belong to them)

Just a few questions and comments...

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


in_reply_to: <001d01c1c2e8$f3939060$ad37a8c0@laptop> from "Julie Hofmann Kemp" at Mar 03, 2002 11:23:51 AM

body:
> Why would we want to distribute hosting?  And for that matter, what's
> wrong with advertising, provided it's done as subtly as possible, and
> not from various merchants of death ;-) (which I still think is for
> Bomis to decide -- I may feel very proprietary about a lot of stuff
> here, but I  still remember I'm on somebody else's playground.  Jimbo et
> al. have  been very cool about trying to  get input, but business
> decisions should belong to them)

It's a matter of scaling. Hosting is currently the only bottleneck
in the wikipedia process, other than possible problems in organization
of material. If the popularity of Wikipedia doubles, the hosting needs
to double--with distributed hosting, that would happen automatically.

-tc


subject: [Wikipedia-l] Distributed hosting

in_reply_to: <20020302020013.25229.qmail@www.llamacom.com> from "kband@www.llamacom.com" at Mar 01, 2002 08:00:13 PM

body:
See http://www.sciam.com/2002/0302issue/0302anderson.html
(The Worldwide Computer)


subject: [Wikipedia-l] Suggestions #4

body:
// Suggestion #4:  Avatar Evil Suggestion

 I like the actual look & feel of Wikipedia. But.. Can be improved with
icons views of data. You can visually pack more info with icons, helping
people sorting and finding information.

 Icons view of older versions of files.
 Icon for Talk
 Icon for users edit this page ( with avatars? )

I suggest this looks and feel:
  - windows 95 big icons view
  - winjabber buddylist view
  - etc..

1 saludo
Tei RatBert

At 20:50 1/03/02 -0800, you wrote:
>
>>I think the hosting of the server should be left to Jimbo to decide.
>>But what I'd really like to see is something like groove.net, where I
>>can keep an offline copy on my own computer, edit articles locally,
>>and sync the changes with the server the next time I'm online.  I'm
>>not on a modem connection, but I'm moving with my laptop and wireless
>>LAN between home, workplaces and cafes.  This of course would be a
>>major software change.  Some two-way synchronization protocol (like
>>unison) would be needed.
>
>what if someone else edits your article after you last see it?  how would
the software reconcile different edits from the same point?  i rather
prefer the current system, where you can go in and choose the best bits of
each to save.  I don't foresee software being that sophisticated within our
lifetimes.  maybe you have some ideas about it.
>
>kq
>
>0


from_name: wojtek pobratyn

subject: [Wikipedia-l] Suggestions #4

body:
----- Original Message -----
From: "Tei" <421621 at ingta.unizar.es>
To: <wikipedia-l at nupedia.com>
Sent: Monday, March 04, 2002 12:28 PM
Subject: [Wikipedia-l] Suggestions #4

|
| // Suggestion #4:  Avatar Evil Suggestion
|
|  I like the actual look & feel of Wikipedia. But.. Can be improved with
| icons views of data. You can visually pack more info with icons, helping
| people sorting and finding information.
|
|  Icons view of older versions of files.
|  Icon for Talk
|  Icon for users edit this page ( with avatars? )
|
| I suggest this looks and feel:
|   - windows 95 big icons view
|   - winjabber buddylist view
|   - etc..

IMHO this would only increase the weight of the pages to be loaded and consume
valuable bandwith.
regards,
WojPob

<wojtek at seti23.org.>
what burns twice as bright, burns half
as long, and you have burnt so very,
very brightly roy.


subject: [Wikipedia-l] Suggestions #4

body:
At 12:34 4/03/02 +0100, you wrote:
>----- Original Message -----
>From: "Tei" <421621 at ingta.unizar.es>
>To: <wikipedia-l at nupedia.com>
>Sent: Monday, March 04, 2002 12:28 PM
>Subject: [Wikipedia-l] Suggestions #4
>
>
>|
>| // Suggestion #4:  Avatar Evil Suggestion
>|
>|  I like the actual look & feel of Wikipedia. But.. Can be improved with
>| icons views of data. You can visually pack more info with icons, helping
>| people sorting and finding information.
>|
>|  Icons view of older versions of files.
>|  Icon for Talk
>|  Icon for users edit this page ( with avatars? )
>|
>| I suggest this looks and feel:
>|   - windows 95 big icons view
>|   - winjabber buddylist view
>|   - etc..
>
>IMHO this would only increase the weight of the pages to be loaded and
consume
>valuable bandwith.
>regards,
>WojPob
>

Woj, thats true, but i suggest icows of less than 1 k size, ante then will
be cached anyway in the client machine.

1 saludo
Tei

note:
type error: icons, not icows,...  :DDD


subject: [Wikipedia-l] hosting, etc

body:
Julie Kemp wrote:
> I understand that, Cunc, but wouldn't Bomis having
> larger, perhaps more redundant (and mirrored) servers
> work as well?

Yes, and it's worth noting that we are a long long way from this
really mattering.  Traffic would have to increase by a factor of 10
before I would really start to care at all.  I'm happy to throw
another couple of servers at the system, if it is justified by traffic
levels.

> It's very expensive, but
> isn't that where the advertising comes in?

Well, we're running free software on commodity hardware.  I'm happy to
supply whatever we need for the visible future.  So no money will be
necessary from any sources other than me for a long time.  It's not
_that_ expensive.

>  I know
> remote networking is viable, but is it practical?  It
> just doesn't seem to be a sensible solution long-term.
>  Can you imagine having to deal with migrations, etc.,
> every time someone decides to back out?  Ugh.

I think it's very impractical and "pie in the sky" from a technical
point of view.  There's a lot of neat ideas out there -- freenet,
etc., but we aren't really a *technical* project, we're an
_encyclopedia_ project.  So I agree with you completely.

Our great virtue, to date, is that we stick to what we know.
Inventing astounding new distributed hosting solutions seems too far
off our central mission.  We should, of course, utilize the best
available stable technology at any given point in time.


from_name: Julie Kemp

subject: [Wikipedia-l] hosting, etc

body:
>
> Message: 1
> From: kband at www.llamacom.com
> Subject: Re: [Wikipedia-l] Everything in the last
> digest
> To: wikipedia-l at nupedia.com
> Date: Sun, 3 Mar 2002 21:54:40 -0600 (CST)
> Reply-To: wikipedia-l at nupedia.com
>
> > Why would we want to distribute hosting?  And for
> that matter, what's
> > wrong with advertising, provided it's done as
> subtly as possible, and
> > not from various merchants of death ;-) (which I
> still think is for
> > Bomis to decide -- I may feel very proprietary
> about a lot of stuff
> > here, but I  still remember I'm on somebody else's
> playground.  Jimbo et
> > al. have  been very cool about trying to  get
> input, but business
> > decisions should belong to them)
>
> It's a matter of scaling. Hosting is currently the
> only bottleneck
> in the wikipedia process, other than possible
> problems in organization
> of material. If the popularity of Wikipedia doubles,
> the hosting needs
> to double--with distributed hosting, that would
> happen automatically.
>
> -tc
>
> --__--__--
>
I understand that, Cunc, but wouldn't Bomis having
larger, perhaps more redundant (and mirrored) servers
work as well?  I've  never dealt with wiki technology,
but my last tech job was with a firm that did online
transaction management.  We had three active servers
up at all times (web, SQL, and mail), and were always
running checks so that we could add more servers as
soon as it was necessary.  It's very expensive, but
isn't that where the advertising comes in?  I know
remote networking is viable, but is it practical?  It
just doesn't seem to be a sensible solution long-term.
 Can you imagine having to deal with migrations, etc.,
every time someone decides to back out?  Ugh.

---JHK

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com


subject: [Wikitech-l] User's contributions minor edits bug

body:
Contributions aren't listed if the most recent edit (not the only
edit) made by the user is a minor edit.

It would be great if this bug could be solved by having a configurable
Contributions page, choosing to list minor edits, pages
created, and/or pages edited. But that's a feature request, not bugfix.

So why does

SELECT old_title FROM old WHERE old_user_text=\"$theuser\" AND old_minor_edit<>\
1

exclude *all* entries which have a minor edit?

Maybe it needs to be

SELECT DISTINCT old_title FROM old WHERE ....

or perhaps

SELECT old_title FROM old WHERE old_user_text="$theuser" GROUP BY old_title HAVING old_minor_edit<>1


subject: [Wikipedia-l] Distributed hosting

body:
<rant>
yea.. this can be done with a freenet wikipedia fork.
I think for now is not needed.... USA freedom is good
</rant>

At 23:07 3/03/02 -0600, you wrote:
>See http://www.sciam.com/2002/0302issue/0302anderson.html
>(The Worldwide Computer)
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>


from_name: Ian

body:
Much more pratical would be a mirroring system. Bomis could continue to do
the main wikipedia.com where updates would take place and the
authoritative version would reside, and mirrors could automatically
download new versions of pages. There could be more then one tier of
mirrors to lift even more bandwidth and CPU time (which appears to be a
bigger problem) off of Bomis.

The mirrors could wouldn't have to use php-wikipedia, they could just have
static pages (though they could have edit this links, which would take
you to wikipedia.com).

Granted, I don't have the time to put the code where my moulth is.

Ian Monroe
http://mlug.missouri.edu/~eean/

On Sun, 3 Mar 2002, kband at www.llamacom.com XXXXXXXXXXXXXXXXXXXXX wrote:

> > Why would we want to distribute hosting?  And for that matter, what's
> > wrong with advertising, provided it's done as subtly as possible, and
> > not from various merchants of death ;-) (which I still think is for
> > Bomis to decide -- I may feel very proprietary about a lot of stuff
> > here, but I  still remember I'm on somebody else's playground.  Jimbo et
> > al. have  been very cool about trying to  get input, but business
> > decisions should belong to them)
>
> It's a matter of scaling. Hosting is currently the only bottleneck
> in the wikipedia process, other than possible problems in organization
> of material. If the popularity of Wikipedia doubles, the hosting needs
> to double--with distributed hosting, that would happen automatically.
>
> -tc
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


from_name: David Merrill

body:
On Mon, Mar 04, 2002 at 06:38:03PM -0600, Ian wrote:
> Much more pratical would be a mirroring system. Bomis could continue to do
> the main wikipedia.com where updates would take place and the
> authoritative version would reside, and mirrors could automatically
> download new versions of pages. There could be more then one tier of
> mirrors to lift even more bandwidth and CPU time (which appears to be a
> bigger problem) off of Bomis.
>
> The mirrors could wouldn't have to use php-wikipedia, they could just have
> static pages (though they could have edit this links, which would take
> you to wikipedia.com).
>
> Granted, I don't have the time to put the code where my moulth is.

The existing PHP code will be useless in generating a static site
suitable for mirroring.

Well, I do have the wt2txt utility, which will convert articles into
DocBook XML, which is easily publishable in many formats including
PDF, PostScript, text, and good old html.

Sime I'm already working on very much the same problem, there's no
need for you to duplicate work. My code is all under the GPL. So if
any programmers want to help with this, talk to me.

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

I wonder if in part why so many people are angry at Microsoft is not just
because their products frustrate them so much, but also because this
frustration is ignored. The computer makes people feel like they are
dummies, when in fact it is the computer that is stupid.
	--MIT Associate Professor Rosalind Picard


subject: [Wikitech-l] International upgrades

body:
So, where do we stand on the issue of international upgrades?

I'd like to get back to these quickly, if possible.  Starting with esperanto, and then
polish.  And then probably spanish, although of course we'll now need to co-ordinate with
the forpas forked group, so that we minimize the extent of the forkage in the hopes of
bringing things back together soon.

--Jimbo


from_name: Brion Vibber

subject: [Wikitech-l] International upgrades

body:
On Tue, 5 Mar 2002, Jimmy Wales wrote:
> So, where do we stand on the issue of international upgrades?
>
> I'd like to get back to these quickly, if possible.  Starting with esperanto, and then
> polish.  And then probably spanish, although of course we'll now need to co-ordinate with
> the forpas forked group, so that we minimize the extent of the forkage in the hopes of
> bringing things back together soon.

There was a discussion some days ago on how to best implement a more or
less character set independent underlying system, but it sort of died out
without any clear consensus. In particular, no response from lcrocker, who
made the initial claim that the present system of using language-tied
encodings was Wrong.

As it left off, Jan and I had more or less agreed on something like:
* Check the browser's Accept-charset header; if available, use UTF-8. If
not, use the most likely encoding used for that wiki's language.
* Where necessary, convert characters into/out of HTML entities so that
non-Unicode browsers can safely handle all characters.
* Internally, non-ascii characters will need to be escaped somehow in the
search index field to allow correct indexing.

Somewhat less solid was how to store the actual text internally: Lee
suggested Latin-1 (or ASCII?) with HTML entities, I suggested UTF-8.

* UTF-8 is more space- and bandwidth-efficient and doesn't require
outgoing transliteration for the many users with relatively current,
UTF8-savvy browsers, but needs to be translated into native code / HTML
entities for non-UTF-8-savvy browsers (old old old ones, and Netscape 4
which has very buggy Unicode support).

* ASCII+HTML entities won't require outgoing translation for
non-UTF8-savvy browsers that nonetheless understand unicode-numbered
character entities, but may not be much of an improvement for older
browsers that don't know the character entities are always numbers in
Unicode, not the current character set. Thus outgoing translation to the
browser's character set is recommended to be safe.

Incoming translation is always required, as edited text will come to us in
the character encoding used by the browser and may or may not have HTML
entities typed by the user mixed in.

The character set translation can probably be done mostly via PHP's iconv
support -- however this is an optional component and must be enabled
during compile time (same as the annoying 4-letter minimum for search
index terms). Also, some slight customisation of the process is necessary
for for instance the Esperanto transliteration schema (basically in place
in $RecodeInput/$RecodeOutput).

If there's some consensus on this, we can get crackin' and get this
implemented so the upgrades can proceed.

-- brion vibber (brion @ pobox.com)


from_name: Graham Chapman

subject: [Wikipedia-l] Advertising? Mirroring? Distributed hosting? What about an EDITOR?!!

body:
Why all the discussion about advertising, distributed hosting and mirroring? It all
seems a bit Alice in Wonderland.

You already have a good site easily able to handle the load, which is only moderate,
from what I can see.

You have a well-disposed site manager in the form of Jimmy Wales who has
generously declared himself happy to continue running and paying for it. The marginal
cost of running an extra host to support something the size of Wikipedia is not great,
so you don't need advertising anytime soon. I mean the whole thing will sit on  $100 or
less worth of disk, for heavens sake!

But you've just lost your EDITOR-IN-CHIEF! You need an EDITOR first and foremost.
If you can't get an editor, you need to work out how to set up a group to keep the
vision and the standards going, or the lights will start going out. Which would be a
shame.

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


subject: [Wikitech-l] Bugzilla?

body:
Jimbo:
  Would you consider installing bugzilla (http://www.mozilla.org/projects/bugzilla/) on wikipedia to help us manage bugs/feature requests? The Wiki
interface is pretty wretched for bug management.

I'd certainly be happiest if everything was integrated (so that you
wouldn't have to separately log into bugzilla...hm, maybe that could
be done...that would be neat, if when you first create an account at
Wikipedia, you could choose to join the wikipedia-l and/or wikitech-l
lists...) but that certainly doesn't need to be a high priority.

The installation looks pretty simple, especially since you already
have perl and mysql all running. It would be of great help. If you
do so, I promise to file the bugs on the current bug reports page.

-tc


subject: [Wikitech-l] Bugzilla?

in_reply_to: <20020306060819.11698.qmail@www.llamacom.com>; from kband@www.llamacom.com on Wed, Mar 06, 2002 at 12:08:19AM -0600

body:
Sure, I'd consider it.  But let's get a consensus of developers that we all actually
want to use this.  It sure seems like a reasonable idea to me.

kband at www.llamacom.com wrote:

> Jimbo:
>   Would you consider installing bugzilla (http://www.mozilla.org/projects/bugzilla/) on wikipedia to help us manage bugs/feature requests? The Wiki
> interface is pretty wretched for bug management.
>
> I'd certainly be happiest if everything was integrated (so that you
> wouldn't have to separately log into bugzilla...hm, maybe that could
> be done...that would be neat, if when you first create an account at
> Wikipedia, you could choose to join the wikipedia-l and/or wikitech-l
> lists...) but that certainly doesn't need to be a high priority.
>
> The installation looks pretty simple, especially since you already
> have perl and mysql all running. It would be of great help. If you
> do so, I promise to file the bugs on the current bug reports page.
>
> -tc
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


from_name: Mark Christensen

subject: [Wikitech-l] Bugzilla?

body:
One issue to consider how easy it will be for end users to report a bug.

Bugzilla is far better than the wiki interface for tracking bugs, but
wikipedians will already know how to use the wiki, and form that perspective
Bugzilla will be more complex to use.

Clearly bugzilla is not --that-- complex, so this is not a serious problem,
but I think it is still worth mentioning.

> -----Original Message-----
> From: Jimmy Wales [mailto:jwales at bomis.com]
> Sent: Wednesday, March 06, 2002 11:12 AM
> To: wikitech-l at nupedia.com
> Subject: Re: [Wikitech-l] Bugzilla?
>
>
> Sure, I'd consider it.  But let's get a consensus of
> developers that we all actually
> want to use this.  It sure seems like a reasonable idea to me.


from_name: Leonardo Boshell

subject: [Wikitech-l] Wiki newbie

body:
Hello everyone,

Please allow me to introduce myself, my name is Leonardo and I'm a
contributor to the Spanish Wikipedia.

I've joined this list some days ago since I want to contribute to wiki
software, specially to the Spanish encyclopedia implementation of it.

So, without any further formalities, here's a list of things I wanted to
ask you guys.

* How are u doing? :)

* Ok, I understand the English Wikipedia made a transition to a new
software written in PHP. Do I have to wait too long before I see the
transition to the new software on the international wikipedias?

* Can I get the new software sources? Where?

* About the handling of bugs and feature requests, I think Bugzilla is a
great idea. I, for one, would rely on it heavily to make contributions
to the project.

So, I guess what I'm trying to tell you is, is it a good idea if I work
on the old (perl) wiki software? or should I wait for the PHP wiki?..
bear in mind that I'm mostly interested in the improvement of the
Spanish Wikipedia (although, if I can contribute to other projects in
the process, and eventually make the world a better place, I won't get
mad :)

Personally, I have a couple of ideas I'd like to implement on the wiki
software:

(a) A new, easier(?) way to create tables inside wiki pages. I
understand that some time ago, somebody wanted to do something like this
with vertical bars (`|'):

http://www.wikipedia.com/wiki/How_does_one_edit_a_page/Old+version
(near the bottom of the page)

I wouldn't implement this feature in the same way (I don't even
understand it completely!), but basically I want to create an
alternative method to include tables in the encyclopedia without HTML.

(b) Ok, I know this may sound like pure evil, but I think that Wikipedia
could use some javascript on the editing pages (action=edit).

And before you start throwing sharpened things in my direction, please
let me expand my argument.

Wikipedia is a great tool, and it's certainly very easy to edit pages
and contribute to the project, but a plain <textarea> box is an arguably
limited widget. Now, I'm not saying this is a critical issue. It works,
and it works pretty darn good, but maybe we could take advantage of some
tools that would improve the editing experience (wow, I sound like a
marketroid :-).

Granted, this may be about just pure eye-candy stuff, and it may piss
off many javascript haters. But please remember that (1) it could be
implemented carefully, so it doesn't break anything on any browser, and
remain standards-compliant, and (2) it could be an optional feature, so
in case your head aches every time you see a <script> tag, you could
just turn it off.

Well, so what can Javascript do for us on the editing pages? I can think
of the following uses right now:

- A collection of buttons that allow you to insert special symbols
easily (like a character map, right there beside your editing box)

- A collection of buttons that insert special tags quickly. For example,
if I press a button labeled "strike out", I get the "<strike></strike>"
tags inserted in my text right away.

- A "Preview" area, updated immediately every time I type a character.

I know these are just lame examples, but I guess you get the idea.

----

So, in conclusion, I'm just another guy that wants to contribute with
the Wikipedia Project. Hopefully I'll manage to start coding a lot more
than talking real soon... :)

Thanks,

Leonardo Boshell


subject: [Wikitech-l] Re: Wiki nubie

body:
Hi Leonardo,

I believe the plan is to eventually migrate all wikipedias over to the
PHP script. So your perspective and help from your side is very much
welcome.

You can read about the features of the new script at
   http://wikipedia.com/wiki/wikipedia:PHP_script
and you can browse the current code at
   http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wikipedia/phpwiki/fpw/

To download the code, it's best to use anonymous CVS, explained on the
PHP_script page mentioned above.

Have fun,
  Axel


subject: [Wikitech-l] Re: Bugzilla?

body:
I don't know Bugzilla, so I have no opinion about adopting it, but I
just wanted to point out that our sourceforge account
at http://sourceforge.net/projects/wikipedia
appears to come with a fairly sophisticated bug tracking system; maybe we
should start importing bugs from the wiki page. (I also think
that we shouldn't force Wikipedians to use a different interface to
report bugs, quickly editing a Bug_Reports page seems to be the most
natural for them).

Axel


subject: [Wikitech-l] Feature request: Kana entities

in_reply_to: <20020307192658.GA2607@tavaiah>; from taw@users.sourceforge.net on Thu, Mar 07, 2002 at 08:26:58PM +0100

body:
This is a neat idea, but...

> So one can write &hiragana_wa; or &katakana_chi;
> This isn't likely to conflict with anything.
>
> Kana Unicode table (in "English") is on http://pl.wikipedia.com/wiki.cgi?Kana

In general, why would it ever be common that one would wish to put
Kana into non-Japanese wikipedias?

At least at first thought (and I'm totally open to have my mind
changed!) the only place in an English or Polish wikipedia where
showing Kana would make sense would be an article _about_ Kana.

--Jimbo


from_name: Jan Hidders

body:
From: "Ian" <rsvr4cqdon001 at sneakemail.com>

> Much more pratical would be a mirroring system. Bomis could continue to do
> the main wikipedia.com where updates would take place and the
> authoritative version would reside, and mirrors could automatically
> download new versions of pages. There could be more then one tier of
> mirrors to lift even more bandwidth and CPU time (which appears to be a
> bigger problem) off of Bomis.

CPU time is not really the problem. The problem is that that the current
script still contains a lot of code that is not really programmed in a
scalable way. Distribution is not a solution to that problem, it will make
it worse.

-- Jan Hidders


subject: [Wikitech-l] whitespace in search

body:
From: "Lars Aronsson" <lars at aronsson.se>
>
> If I search for "van eyck" (with the whitespace, but sans the quotes),
> I get an ugly error message.

You may not realize it but there is a little parser that parses your querie
(you can now use and/or/not and brackets in your search query) and it took
quite some of my time to let this parser give you a more detailed error
message than just "syntax error". :-)

>  Is it really such a crime to want to search for a string that
> includes the whitespace?

No. The problem is that because of how the MySQL indexing works you cannot
do that anymore. For the same reason you also cannot search for anything
that is not a letter or words with less than 4 letters. I have plans on how
this might be solved, but that is not going to be easy.

> Also, if I search for "van\ eyck", the error message comes up and the
> input box contains "van\\ eyck".

That's a little bug. A forgot to unescape the letters that are escaped for
the URL. That will be fixed in the near future.

-- Jan Hidders


subject: [Wikitech-l] Signature with date

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

> You can now sign with automatic (server) date using ~~~~ (4x "~").

Great! Thanks.

-- Jan Hidders


body:
From: "Lars Aronsson" <lars at aronsson.se>
>
> If I set my preferences to hide minor edits in the recent changes
> listing, then I want to see the most recent major edit for that page.

Yup, that's what I intended to happen when I programmed, but there seems to
be more that is going wrong at the moment. I haven't been succesful at
replicating the error at home, but I'm looking into it.

-- Jan Hidders


subject: [Wikitech-l] Re: Bugzilla?

body:
From: "Axel Boldt" <axel at uni-paderborn.de>
>
> I don't know Bugzilla, so I have no opinion about adopting it, but I
> just wanted to point out that our sourceforge account
> at http://sourceforge.net/projects/wikipedia
> appears to come with a fairly sophisticated bug tracking system; maybe we
> should start importing bugs from the wiki page. (I also think
> that we shouldn't force Wikipedians to use a different interface to
> report bugs, quickly editing a Bug_Reports page seems to be the most
> natural for them).

I agree with Axel (but also do not know Bugzilla). The problem is more that
somebody should be responsible for doing the bug-bookkeeping.

-- Jan Hidders


subject: [Wikitech-l] Wiki newbie

body:
From: "Leonardo Boshell" <p at kapcoweb.com>
>
> So, I guess what I'm trying to tell you is, is it a good idea if I work
> on the old (perl) wiki software? or should I wait for the PHP wiki?..

Since the PHP wiki will very probably replace the Perl software everywhere
your work on the Perl script will be lost then.

> bear in mind that I'm mostly interested in the improvement of the
> Spanish Wikipedia (although, if I can contribute to other projects in
> the process, and eventually make the world a better place, I won't get
> mad :)

At the moment the idea is to have eventually the same script for all
languages. So if you want to add something that is language dependent you
have to do it in a way that makes either appopriate for all languages or
easily adaptable (by, say, changing a certain include).

> Personally, I have a couple of ideas I'd like to implement on the wiki
> software:
>
> (a) A new, easier(?) way to create tables inside wiki pages. I
> understand that some time ago, somebody wanted to do something like this
> with vertical bars (`|'):
>
> http://www.wikipedia.com/wiki/How_does_one_edit_a_page/Old+version
> (near the bottom of the page)
>
> I wouldn't implement this feature in the same way (I don't even
> understand it completely!), but basically I want to create an
> alternative method to include tables in the encyclopedia without HTML.

Frankly, I'm not a big fan of adding any more mark-up at the moment. The
parser is still a mess, needs optimization and we don't have an exact formal
description of how the syntax looks and what it does. Once we have those
things, we can start thinking about changing the mark-up.

> Granted, this may be about just pure eye-candy stuff, and it may piss
> off many javascript haters. But please remember that (1) it could be
> implemented carefully, so it doesn't break anything on any browser, and
> remain standards-compliant, and (2) it could be an optional feature, so
> in case your head aches every time you see a <script> tag, you could
> just turn it off.

We have not been very succesful at "careful implementing" sofar. :-/ And (2)
is really not a very good argument. You have seen how many options we have
already. Also in this respect we have to keep things as simple as possible.

> - A collection of buttons that allow you to insert special symbols
> easily (like a character map, right there beside your editing box)

Could be useful, but how many people who want to type Spanish don't have a
Spanish key board or have some short-cuts for Spanish letters?

> - A "Preview" area, updated immediately every time I type a character.

So you are going to write another version of the parser in Javascript? Two
versions of the parser in different languages doesn't seem very maintainable
to me.

Perhaps I sound a bit grumpy, but there is still an awfull lot of work that
needs to be done. We need a formal description of the mark-up. We need a
better parser. We need a better organization of the code and a
well-understood architecture for the internationalization. We need to get
rid of the current long list of bugs. Et cetera. What we do not need is more
and more and more features that make the script harder to maintain and bring
it closer to  feature-death.

-- Jan Hidders


subject: [Wikitech-l] International upgrades

body:
From: "Brion Vibber" <brion at pobox.com>
>
> Somewhat less solid was how to store the actual text internally: Lee
> suggested Latin-1 (or ASCII?) with HTML entities, I suggested UTF-8.

We cannot index UTF-8. But if we introduce a redundant indexable field where
all characters (even the ASII ones) are represented with their unicode
number, then we would have a way around the 4-letter indexing boundary and
the problem that you cannot index anything but letters. So in that case I
would vote for UTF-8 since that would probably be the most efficient anyway.

> If there's some consensus on this, we can get crackin' and get this
> implemented so the upgrades can proceed.

Er, I would suggest that before coding we set up a document that describes
what the consenus is. It should say what codings are used for what, when and
where. It should also say which functions take care of this coding. This
would also include the coding used in URLs.

-- Jan Hidders


from_name: Tomasz Wegrzanowski

body:
This feature should be easy to do.
Unfortunately my PHP knowledge is limited, so I think
it will be better if I just ask for it instead of trying to do it myself :)

Using japanese characters in non-japanese wikipedias is currently hard.
One have to write them as &#xHEXCODE; or &#DECIMALCODE;

I think that it would be much better if parser were able to parse
fake kana (at least basic kana, full kanji would be much more work) &entities;
and convert them to numeric codes.

So one can write &hiragana_wa; or &katakana_chi;
This isn't likely to conflict with anything.

Kana Unicode table (in "English") is on http://pl.wikipedia.com/wiki.cgi?Kana

Entities that would be needed:
* Full hiragana ぁ to ゔ
* Full katakana ァ to ヺ
* Prolongation mark ー

Proposed names:
* &hiragana_x; &hiragana_smallx;
* &katakana_x; &katakana_smallx;
* &kana_long;

I also think that it might be good idea to extend it to other writing sytems
in the future.

Is it possible ?


from_name: Brion L. VIBBER

body:
On ?a?, 2002-03-07 at 22:07, Tomasz Wegrzanowski wrote:
> On Thu, Mar 07, 2002 at 03:59:34PM -0800, Jimmy Wales wrote:
> > This is a neat idea, but...
> >
> > > So one can write &hiragana_wa; or &katakana_chi;
> > > This isn't likely to conflict with anything.
> > >
> > > Kana Unicode table (in "English") is on http://pl.wikipedia.com/wiki.cgi?Kana
> >
> > In general, why would it ever be common that one would wish to put
> > Kana into non-Japanese wikipedias?
> >
> > At least at first thought (and I'm totally open to have my mind
> > changed!) the only place in an English or Polish wikipedia where
> > showing Kana would make sense would be an article _about_ Kana.
>
> Just see articles about anything Japanese on English Wikipedia.
> They contain Japanese names of everything.

Sure, but more often kanji than kana, so special kana markup wouldn't be
that big a win. See the thread "International Upgrades"; the vague plan
is to standardise the internal character set and present the wikipedias
in Unicode to capable browsers. (Please comment!)

As a result, we should be able to use the customary input methods or
cut-n-paste to put any characters into any of the wikis, which is
certainly a lot easier than looking up entities or running text through
a UTF-8-to-entities convertor (which is what I currently do).

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] International upgrades

body:
On ?a?, 2002-03-07 at 10:50, Jan Hidders wrote:
> From: "Brion Vibber" <brion at pobox.com>
> >
> > Somewhat less solid was how to store the actual text internally: Lee
> > suggested Latin-1 (or ASCII?) with HTML entities, I suggested UTF-8.
>
> We cannot index UTF-8.

Nor HTML entities, naturally.

> But if we introduce a redundant indexable field where
> all characters (even the ASII ones) are represented with their unicode
> number, then we would have a way around the 4-letter indexing boundary and
> the problem that you cannot index anything but letters. So in that case I
> would vote for UTF-8 since that would probably be the most efficient anyway.

Hmm, that's an idea.

[Incidentally; if we are to switch to UTF-8, we'll obviously want to do
something about the fact that the current English wikipedia uses
ISO-8859-1 high characters extensively. These pages can be converted
fairly easily, either as a one time search & replace or as a
normalise-an-old-page-when-we-first-load-it thing.]

> > If there's some consensus on this, we can get crackin' and get this
> > implemented so the upgrades can proceed.
>
> Er, I would suggest that before coding we set up a document that describes
> what the consenus is. It should say what codings are used for what, when and
> where. It should also say which functions take care of this coding. This
> would also include the coding used in URLs.

Well, I was hoping there would be some evidence of some kind of
consensus before anyone goes writing documents or code! :)

We can probably add this stuff to
http://meta.wikipedia.com/wiki.phtml?title=Proposed_Wikipedia_policy_on_foreign_characters

The only sane format for URLs would be url-encoded UTF-8. This is the
recommended norm (http://www.w3.org/International/O-URL-and-ident.html),
it is the most future-proof (can you imagine if we kept all our URLs in
EBCDIC instead of ASCII because everybody still had links & bookmarks
from their old IBM mainframe days?), and it allows links across
languages to be consistently represented.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Japanese wikipedia now works!

body:
After some tweaking with character set headers, title character
limitations and mysterious high-byte problems, the Japanese wikipedia
should now be useable:
  http://ja.wikipedia.com/

(At some point it and the other non-English wikipedias will be converted
to the new software, but there is still work to be done before that's
ready - see the thread "International upgrades" on wikitech-l.)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] International upgrades

body:
On ven, 2002-03-08 at 01:10, Jan Hidders wrote:
> From: "Brion L. VIBBER" <brion at pobox.com>
> > On ?a?, 2002-03-07 at 10:50, Jan Hidders wrote:
> > > From: "Brion Vibber" <brion at pobox.com>
> > > >
> > > > Somewhat less solid was how to store the actual text internally: Lee
> > > > suggested Latin-1 (or ASCII?) with HTML entities, I suggested UTF-8.
> > >
> > > We cannot index UTF-8.
> >
> > Nor HTML entities, naturally.
>
> That's not so obvious. If you replace the &, # and ; with something that is
> indexed like ' and _ then indexing would work.

Exactly what I'm saying; in both cases we can't index words including
non-ASCII characters unless we munge the text somehow.

Which reminds me, this will not work well for Japanese and Chinese,
which don't separate words by spaces... ugh!

> But like I said, I favour
> UTF-8 anyway and we can solve the indexing problem with an extra column
> where everything is more or less represented as entities anyway.

Don't we already have a separate index column?

> (We could
> even replace uppercase with lowercase there and have case insensitive
> indexing.)

Hmm, can be done.

> > [Incidentally; if we are to switch to UTF-8, we'll obviously want to do
> > something about the fact that the current English wikipedia uses
> > ISO-8859-1 high characters extensively. These pages can be converted
> > fairly easily, either as a one time search & replace or as a
> > normalise-an-old-page-when-we-first-load-it thing.]
>
> I like the one-time-search-and-replace approach. No need to complicate
> and/or slow down the run-time code with checks and translation code.

Okay. We'll need another update script for poor Jimbo, then!

> > Well, I was hoping there would be some evidence of some kind of
> > consensus before anyone goes writing documents or code! :)
>
> Of course. :-) I am still wondering what our great leader thinks of all
> this.

The ways of the Great Leader are mysterious indeed, we must await
revelation... :)

> > We can probably add this stuff to
> >
> http://meta.wikipedia.com/wiki.phtml?title=Proposed_Wikipedia_policy_on_fore
> ign_characters
>
> This page is more about the local policy on the English Wikipedia. I would
> like to see a page with a title like "A common architecture for Wikipedias
> in all languages". I'd start writing it, but work is really busy at the
> moment.

Okay, but they are clearly related topics since we'd be affecting the
English wikipedia as well! I might throw up a quick page in the morning
to start with.

> > The only sane format for URLs would be url-encoded UTF-8. This is the
> > recommended norm (http://www.w3.org/International/O-URL-and-ident.html),
> > it is the most future-proof (can you imagine if we kept all our URLs in
> > EBCDIC instead of ASCII because everybody still had links & bookmarks
> > from their old IBM mainframe days?), and it allows links across
> > languages to be consistently represented.
>
> Completely agreed.

That's you, me, and Carey Evans then...

-- brion vibber (brion @ pobox.com)


body:
On Thu, Mar 07, 2002 at 03:59:34PM -0800, Jimmy Wales wrote:
> This is a neat idea, but...
>
> > So one can write &hiragana_wa; or &katakana_chi;
> > This isn't likely to conflict with anything.
> >
> > Kana Unicode table (in "English") is on http://pl.wikipedia.com/wiki.cgi?Kana
>
> In general, why would it ever be common that one would wish to put
> Kana into non-Japanese wikipedias?
>
> At least at first thought (and I'm totally open to have my mind
> changed!) the only place in an English or Polish wikipedia where
> showing Kana would make sense would be an article _about_ Kana.
>
> --Jimbo

Just see articles about anything Japanese on English Wikipedia.
They contain Japanese names of everything.


in_reply_to: <20020308060727.GA7954@tavaiah>; from taw@users.sourceforge.net on Fri, Mar 08, 2002 at 07:07:27AM +0100

body:
I wrote:
> > In general, why would it ever be common that one would wish to put
> > Kana into non-Japanese wikipedias?
> >
> > At least at first thought (and I'm totally open to have my mind
> > changed!) the only place in an English or Polish wikipedia where
> > showing Kana would make sense would be an article _about_ Kana.

Tomasz Wegrzanowski wrote:
> Just see articles about anything Japanese on English Wikipedia.
> They contain Japanese names of everything.

But shouldn't these Japanese names generally be written in the Roman
alphabet (Romaji), not in Kana?  If I open up an Encyclopedia
Britannica article about 'anime' or 'sushi' or 'Hirohito' or 'Konoe
Fumimaro' I don't expect to see kana, but Romaji.

I'm not a real stickler on this point; as I say, I could be convinced.
I'm just saying that it strikes me as fairly odd to put Kana or Kanji
character sets into other languages, except in some very special
cases.

--Jimbo


in_reply_to: <1015572895.3403.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Thu, Mar 07, 2002 at 11:34:53PM -0800

body:
Brion L. VIBBER wrote:
> Sure, but more often kanji than kana, so special kana markup wouldn't be
> that big a win. See the thread "International Upgrades"; the vague plan
> is to standardise the internal character set and present the wikipedias
> in Unicode to capable browsers. (Please comment!)

Really?  There are kanji in articles about Japan?  I mean, articles
other than articles about the language or other special cases?

That seems odd to me.  I'm not opposed to it, necessarily, but it
seems very odd.  I mean, there's no reason to expect that kanji will
be useful to the vast majority of readers.

Can you send some examples?

--Jimbo


in_reply_to: <1015609654.4259.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Fri, Mar 08, 2002 at 09:47:32AM -0800

body:
O.k., I'm starting to see the light on this.

Brion L. VIBBER wrote:
> > I'm not a real stickler on this point; as I say, I could be convinced.
> > I'm just saying that it strikes me as fairly odd to put Kana or Kanji
> > character sets into other languages, except in some very special
> > cases.
>
> What other special case could there be than "something originating in
> culture X, here's its real name in the language of X in case you can
> read X and want to look up more information or, heck, are just curious".

Oh, the special cases I had in mind were articles _about_ kana or kanji, or in
cases where the kana or kanji are likely to be well-known in a certain context.

I don't know much about 'anime', for example, but I imagine that fans
of anime are familiar with the kana for 'a ni me'.  New people
interested in that area may have seen those kana around but not yet
grasped what they mean.  So they'd be excited to find out by readin
our 'a ni me' article.

That's different from just sticking a kanji in after someone's name.

But, now I'm starting to see the light.  So long as this is just
presented as parenthetical information, there's no harm and it could
be very useful.  Take the Sushi article as an example.  Someone could
use it to become familiar with the kanji for different things like
nigirisushi, and then have more fun the next time at a Japanese
restaurant.

Boku wa nihongo no gakusei.  De mo watashi no nihongo joozu de wa
arimasen.  "I am a Japanese language student.  But, my Japanese
language is not proficient."

So consier me totally converted on this point.

(However, my Konquerer browser does not render these characters at all.)

--Jimbo


body:
On ven, 2002-03-08 at 09:18, Jimmy Wales wrote:
> Tomasz Wegrzanowski wrote:
> > Just see articles about anything Japanese on English Wikipedia.
> > They contain Japanese names of everything.
>
> But shouldn't these Japanese names generally be written in the Roman
> alphabet (Romaji), not in Kana?  If I open up an Encyclopedia
> Britannica article about 'anime' or 'sushi' or 'Hirohito' or 'Konoe
> Fumimaro' I don't expect to see kana, but Romaji.

Bring up the wikipedia article on [[Miyazaki Hayao]] (or, for that
matter, [[Sushi]]) for an example of what we're talking about.
Kanji/kana are provided as supplementary parenthetical information,
while the main text uses the English name and, if different, the Romaji
form.

> I'm not a real stickler on this point; as I say, I could be convinced.
> I'm just saying that it strikes me as fairly odd to put Kana or Kanji
> character sets into other languages, except in some very special
> cases.

What other special case could there be than "something originating in
culture X, here's its real name in the language of X in case you can
read X and want to look up more information or, heck, are just curious".

-- brion vibber (brion @ pobox.com)


body:
On ven, 2002-03-08 at 09:20, Jimmy Wales wrote:
> Brion L. VIBBER wrote:
> > Sure, but more often kanji than kana, so special kana markup wouldn't be
> > that big a win. See the thread "International Upgrades"; the vague plan
> > is to standardise the internal character set and present the wikipedias
> > in Unicode to capable browsers. (Please comment!)
>
> Really?  There are kanji in articles about Japan?

Yeeessss.... You have such a difficult time accepting this. :)

>  I mean, articles
> other than articles about the language or other special cases?

Define "special cases".

> That seems odd to me.  I'm not opposed to it, necessarily, but it
> seems very odd.  I mean, there's no reason to expect that kanji will
> be useful to the vast majority of readers.

No, but there's no reason to expect that any particular *article* will
be useful to the vast majority of readers for that matter.

A few question marks or boxes in parentheses aren't going to drive
non-Japanese readers mad with one look, but for those who *do* know it,
they *do* get more information because they now can recognize the term
in Japanese text, or usefully look it up in Japanese informational
resources.

The English wikipedia isn't just for English monolinguals, is it?

> Can you send some examples?


subject: [Wikitech-l] International upgrades

body:
From: "Brion L. VIBBER" <brion at pobox.com>
> On ?a?, 2002-03-07 at 10:50, Jan Hidders wrote:
> > From: "Brion Vibber" <brion at pobox.com>
> > >
> > > Somewhat less solid was how to store the actual text internally: Lee
> > > suggested Latin-1 (or ASCII?) with HTML entities, I suggested UTF-8.
> >
> > We cannot index UTF-8.
>
> Nor HTML entities, naturally.

That's not so obvious. If you replace the &, # and ; with something that is
indexed like ' and _ then indexing would work. But like I said, I favour
UTF-8 anyway and we can solve the indexing problem with an extra column
where everything is more or less represented as entities anyway. (We could
even replace uppercase with lowercase there and have case insensitive
indexing.)

> [Incidentally; if we are to switch to UTF-8, we'll obviously want to do
> something about the fact that the current English wikipedia uses
> ISO-8859-1 high characters extensively. These pages can be converted
> fairly easily, either as a one time search & replace or as a
> normalise-an-old-page-when-we-first-load-it thing.]

I like the one-time-search-and-replace approach. No need to complicate
and/or slow down the run-time code with checks and translation code.

> Well, I was hoping there would be some evidence of some kind of
> consensus before anyone goes writing documents or code! :)

Of course. :-) I am still wondering what our great leader thinks of all
this.

> We can probably add this stuff to
>
http://meta.wikipedia.com/wiki.phtml?title=Proposed_Wikipedia_policy_on_fore
ign_characters

This page is more about the local policy on the English Wikipedia. I would
like to see a page with a title like "A common architecture for Wikipedias
in all languages". I'd start writing it, but work is really busy at the
moment.

> The only sane format for URLs would be url-encoded UTF-8. This is the
> recommended norm (http://www.w3.org/International/O-URL-and-ident.html),
> it is the most future-proof (can you imagine if we kept all our URLs in
> EBCDIC instead of ASCII because everybody still had links & bookmarks
> from their old IBM mainframe days?), and it allows links across
> languages to be consistently represented.

Completely agreed.

-- Jan Hidders


body:
On ven, 2002-03-08 at 04:07, Tomasz Wegrzanowski wrote:
> On Thu, Mar 07, 2002 at 11:34:53PM -0800, Brion L. VIBBER wrote:
> > On ??a??, 2002-03-07 at 22:07, Tomasz Wegrzanowski wrote:
> > > Just see articles about anything Japanese on English Wikipedia.
> > > They contain Japanese names of everything.
> >
> > Sure, but more often kanji than kana, so special kana markup wouldn't be
> > that big a win. See the thread "International Upgrades"; the vague plan
> > is to standardise the internal character set and present the wikipedias
> > in Unicode to capable browsers. (Please comment!)
>
> Uhm, right. But most non-japanese people don't know names of too many kanjis,
> so kanjis aren't that important. ;) On the other hand more people that
> it is usually though know kana, so it might be beneficial for them.

But, what are people who don't know much Japanese going to _do_ with
kana?

Speaking as someone with a very very poor command of the Japanese
language, my own usage of Japanese characters on the non-Japanese
wikipedias is limited to:
  * Demonstration of japanese characters in articles about the language
  * Showing the local form of a place, personal, or other name in
articles about Japan and Japanese culture

The former are a limited genre (Jimbo's "special case"), and the latter
are overwhelmingly kanji.

> Hmmm. Now I think that some general method would be more useful:
> &katakana_a; &kanji_b; &hebrew_c; or &cyrilic_d;

Hmm. Perhaps you should take this up with the w3 and get these put into
the next XHTML standard. :)

> > As a result, we should be able to use the customary input methods or
> > cut-n-paste to put any characters into any of the wikis, which is
> > certainly a lot easier than looking up entities or running text through
> > a UTF-8-to-entities convertor (which is what I currently do).
>
> Hmmm. Wouldn't that need some modifications to browsers ?

Only if you've got a really limited browser. (Perhaps Netscape 4, the
bane of web developers worldwide, or a text-mode browser in a non UTF-8
locale.)

Mozilla/Netscape 6, Internet Explorer 5+, Konqueror (if fonts are set up
right), you should have no problem. Configuring keyboards/input methods,
of course, is a system-dependent matter. (Japanese input is notoriously
difficult to set up on Unixish systems that aren't running a primarily
Japanese locale; it's quite easy on relatively current Mac or Windows
systems, though.)

-- brion vibber (brion @ pobox.com)


body:
On ven, 2002-03-08 at 10:26, Tomasz Wegrzanowski wrote:
> On Fri, Mar 08, 2002 at 10:07:58AM -0800, Brion L. VIBBER wrote:
> > That said, I'm still not convinced there's much usefulness in more
> > special codes that work on our wiki and nowhere else in the world; only
> > a fraction of the above use kana at all.
>
> *Anything* is better than using numerics.
> Many of them are mixed kana + kanji.
> That still saves half of the work.

What are you doing, looking up every character individually? No wonder
you're having trouble!

What I currently do is to type the desired text into yudit
(http://yudit.org) using its support for the kinput2 input method (or
cut-n-paste into yudit from another web page), save the file, and run it
through this little program:

#!/usr/bin/perl -p
# disassemble non-ASCII codes from UTF-8 stream

# borrowed from http://czyborra.com/utf/

#$format=$ENV{"UCFORMAT"}||'<U%04X>';
$format='&#%d;';
s/([\xC0-\xDF])([\x80-\xBF])/sprintf($format,
unpack("c",$1)<<6&0x07C0|unpack("c",$2)&0x003F)/ge;
s/([\xE0-\xEF])([\x80-\xBF])([\x80-\xBF])/sprintf($format,
unpack("c",$1)<<12&0xF000|unpack("c",$2)<<6&0x0FC0|unpack("c",$3)&0x003F)/ge;
s/([\xF0-\xF7])([\x80-\xBF])([\x80-\xBF])([\x80-\xBF])/sprintf($format,
unpack("c",$1)<<18&0x1C0000|unpack("c",$2)<<12&0x3F000|
unpack("c",$3)<<6&0x0FC0|unpack("c",$4)&0x003F)/ge;

Paste the output into the Wikipedia edit box, and presto!

If I have one name, it gets done at once. If I have two names, they get
done at once. If I put in a whole passage of text, it all gets done at
once. It would actually be *more* work for me to separately write out
the kana characters in special codes.

Once we've got the new system with Unicode up, you should be able to
type or paste the characters in directly (unless you have a very limited
browser, see my earlier post) and bypass all this rigamarole.

-- brion vibber (brion @ pobox.com)


body:
On Thu, Mar 07, 2002 at 11:34:53PM -0800, Brion L. VIBBER wrote:
> On ??a??, 2002-03-07 at 22:07, Tomasz Wegrzanowski wrote:
> > Just see articles about anything Japanese on English Wikipedia.
> > They contain Japanese names of everything.
>
> Sure, but more often kanji than kana, so special kana markup wouldn't be
> that big a win. See the thread "International Upgrades"; the vague plan
> is to standardise the internal character set and present the wikipedias
> in Unicode to capable browsers. (Please comment!)

Uhm, right. But most non-japanese people don't know names of too many kanjis,
so kanjis aren't that important. ;) On the other hand more people that
it is usually though know kana, so it might be beneficial for them.

Hmmm. Now I think that some general method would be more useful:
&katakana_a; &kanji_b; &hebrew_c; or &cyrilic_d;

I think that it won't need too many changes in parser.
Perl code:
Init:

%Entities =	{'&katakana_o;' => 'オ',
		...
		};

On HTML output:

s/(&[a-zA-Z0-9_]+;)/$Entities{$x}?$Entities{$x}:$x;/eg;

> As a result, we should be able to use the customary input methods or
> cut-n-paste to put any characters into any of the wikis, which is
> certainly a lot easier than looking up entities or running text through
> a UTF-8-to-entities convertor (which is what I currently do).
>
> -- brion vibber (brion @ pobox.com)

Hmmm. Wouldn't that need some modifications to browsers ?


from_name: Axel Boldt

subject: [Wikitech-l] User Contributions bug and Searching help

body:
I checked in two minor things:

* special_contributions.php had a bug where old contributions were
  ignored. I reformulated it as a single SQL query which lists all pages
  that a user has made non-minor edits on, excluding log and talk
  namespaces. I hope that this is the intended behavior.

* I added a link to [[wikipedia:Searching]] to all search error
  messages.

Axel


body:
On Fri, Mar 08, 2002 at 09:20:16AM -0800, Jimmy Wales wrote:
> Brion L. VIBBER wrote:
> > Sure, but more often kanji than kana, so special kana markup wouldn't be
> > that big a win. See the thread "International Upgrades"; the vague plan
> > is to standardise the internal character set and present the wikipedias
> > in Unicode to capable browsers. (Please comment!)
>
> Really?  There are kanji in articles about Japan?  I mean, articles
> other than articles about the language or other special cases?
>
> That seems odd to me.  I'm not opposed to it, necessarily, but it
> seems very odd.  I mean, there's no reason to expect that kanji will
> be useful to the vast majority of readers.
>
> Can you send some examples?

Murasaki Shikibu
Anime
Princess Mononoke
Neon Genesis Evangelion
Miyazaki Hayao
(and lot more)

In fact majority of Japan-related article have some kanjis.


body:
On Fri, Mar 08, 2002 at 10:07:58AM -0800, Brion L. VIBBER wrote:
> That said, I'm still not convinced there's much usefulness in more
> special codes that work on our wiki and nowhere else in the world; only
> a fraction of the above use kana at all.

*Anything* is better than using numerics.
Many of them are mixed kana + kanji.
That still saves half of the work.


subject: [Wikitech-l] #REDIRECT to non-existent pages

body:
I checked in a fix for the bug that caused a #REDIRECT to a
non-existent page to result in an edit conflict. It turns out that
unset() doesn't destroy global values, only local ones.

Axel


body:
On Fri, Mar 08, 2002 at 04:03:02PM -0800, lcrocker at nupedia.com wrote:
>
>
> >Hmmm. Now I think that some general method would be more useful:
> >&katakana_a; &kanji_b; &hebrew_c; or &cyrilic_d;
>
> If and when the W3C ever /standardizes/ these as HTML named
> entity references, we might use them.  Until then, I think it's
> better to be able to point to an officially sanctioned doc and
> say "we support these", and let people complain the the
> standards body.
> 0

W3C standarizes HTML, and I'm talking about Wiki markup.
Wiki named entities will be converted into HTML numeric entities
on output, so they have nothing to do with HTML.