Wikipedia-l May 2003

wikipedia-l@lists.wikimedia.org

56 participants
67 discussions

*cough* Wikimedia (was: "interlingual use of image")
by Daniel Mayer 16 May '03

16 May '03

LDC wrote: > Images should not be shared among Wikipedias. it is our goal > to have each Wikipedia be complete and self-contained, except > for links to the Internet at large. Disk space is cheap--if > the same image appears in 10 wikis, then it should be uploaded > 10 times and linked locally in each. That way, when we make > a backup of each wiki, each backup contains the whole content. And how difficult would it be to add meta tags to each shared image for every language that links to it? Not very I imagine (what links here already works in a similar way). I already own Wikimedia.org (notice the "m") which would be a great place to have a centralized media repository (and non-profit too, BTW). Hard drive space isn't the only resource to consider here; more important is our human resources: The way it is now somebody has to go to where the image is located, copy the image onto their computer's hard drive, upload the image to a different language, edit the image's description page and then link to the image in the article. But if we had a centralized media repository then all the user has to do is make the wiki link. Done. -- Daniel Mayer (aka mav)

2 1

Re: Getting rid of nicknames
by Daniel Mayer 16 May '03

16 May '03

tc wrote: > I'd say that people have been seriously abusing the nickname function. > People really should not have nicknames that are significantly different > from their usernames. > > People should not use nicknames that closely resemble other people's > usernames. > > People should not use unpronounceable nicknames. > > People should not use nicknames that are made up of non-alphabetical > characters. I agree. We should therefore make a policy about this while keeping the ability to have nicknames. There is nothing wrong with my nick, no? It should be reasonably easy to associate a nickname with a user name. Doing otherwise was cute at first but after a while it does border on rudeness (however unintended). --Daniel Mayer (aka mav)

1 0

A vision for wiki syntax, documented
by Daniel Mayer 16 May '03

16 May '03

LDC wrote: >There's no provision for nested tables. I don't think >there's a good enough case for their necessity. Cell >backgrounds and borders can be done with styles. Well I and many other very hard-working Wikipedians think there is a very real need for nested tables. They are used in each these converted articles; organisms (that nested table has a border=0), countries, heads of state, elements, and sub-national entities. And this list doesn't include the many other non-project related nested tables. >> So if http://www.wikipedia.org/wiki/Beryllium >>cannot be replicated pretty much as-is in wikicode >>then I for will have a fit (I'm sure many others >>will join me). > >Yeah, that nested table is a nuisance. I'll have to >think about that. There are two nested tables; the obvious one in the isotopes section and the navigation nested table in the first cell of the larger table (which in turn has an image embedded in it). Both are necessary to the functioning of the table and are not a "nuisance" at all. >> An alternative solution is to only allow HTML >> syntax to be rendered if it is in a table:namespace >> page. > >As I said before, I want to eliminate the complexity, >not just move it around. I want newbies to have some >chance of being to edit the table as well as the >prose around it. Do you have /any/ idea about how much work would be undone and have to be redone in a diminished format if the document as is were implemented? Thousands of pages will be broken and many users, including me, may get fed-up with Wikipedia and leave. A table is going to be dense and intimidating to nontechnical users no matter what but tables are very useful when it comes to effectively presenting tabular data (something we have a lot of). Thus putting this complexity on a separate page seems to be a good compromise between preventing newbies from not being intimidated by hordes of markup and allowing more seasoned users the ability to present tabular data in a table. How the page functions for the reader is just as important as how it functions for the writer. And just as different writers have different abilities to contribute prose to an article, we have different coders with different abilities to add markup to articles. We don't dumb down the prose of articles to reach the lowest common denominator reader/writer (except for intro paragraphs) and we should not similarly dumb down the markup just to make things a bit easier for the lowest common denominator coder. Just segregate the tables from the prose and both the markup- phobic and the markup gurus will be happy (that's not to say that I advocate for full HTML support; just move the HTML off of the regular article page and into its own namespace). I would still like to know if a conversion script would be run. If not, then disabling HTML would make Wikipedia look badly broken with the displayed text of tens of thousands of instances of HTML markup. And all that would have to be re-coded in the new syntax by hand. If it is run then the script is going to mangle any table that has markup in it that is no supported in the proposed wikicode. Either way we are talking about changing masses of content that somebody is going to have to repair. Why in the world is it necessary to break so many things and therefore create so much added work? The negative side-effects of the proposed WikiSyntax will cause far more problems than it purports to solve, IMO. Please replicate in WikiCode the HTML we currently support (well, maybe not the obscure stuff that is hardly ever used) and/or create a table:namespace. -- Daniel Mayer (aka mav) PS - We've seem to have done fine during the past 2+ years with tolerating HTML where it makes sense (such as tables). __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

4 4

A vision for wiki syntax, documented
by Erik Zachte 16 May '03

16 May '03

I am for ease of use. I am against reduced functionality. When both objectives collide functionality should take prevalence. As someone said we should not make the lowest common denominator coder the norm. A separate table namespace seems a good compromise. I am curious how these controversies are resolved nowadays in this community. A few people state their opinion and developers make the final decision?

5 4

A vision for wiki syntax, documented
by Daniel Mayer 16 May '03

16 May '03

3 2

Mailing lists temporarily down
by Brion Vibber 15 May '03

15 May '03

In the fun and excitement it seems we've broken the mailing lists. :) This should be fixed shortly; in the meantime you can send mail on the lists by adding a "pliny." in front of the wikipedia.org in the address. -- brion vibber (brion @ pobox.com)

3 2

A vision for wiki syntax, documented
by Daniel Mayer 15 May '03

15 May '03

NOTE: This is the third time today I've sent this email and it still hasn't found its way into the archive. Hopefully this one will get through. LDC wrote: >There's no provision for nested tables. I don't think >there's a good enough case for their necessity. Cell >backgrounds and borders can be done with styles. Well I and many other very hard-working Wikipedians think there is a very real need for nested tables. They are used in each these converted articles; organisms (that nested table has a border=0), countries, heads of state, elements, and sub-national entities. And this list doesn't include the many other non-project related nested tables. >> So if http://www.wikipedia.org/wiki/Beryllium >>cannot be replicated pretty much as-is in wikicode >>then I for will have a fit (I'm sure many others >>will join me). > >Yeah, that nested table is a nuisance. I'll have to >think about that. There are two nested tables; the obvious one in the isotopes section and the navigation nested table in the first cell of the larger table (which in turn has an image embedded in it). Both are necessary to the functioning of the table and are not a "nuisance" at all. >> An alternative solution is to only allow HTML >> syntax to be rendered if it is in a table:namespace >> page. > >As I said before, I want to eliminate the complexity, >not just move it around. I want newbies to have some >chance of being to edit the table as well as the >prose around it. Do you have /any/ idea about how much work would be undone and have to be redone in a diminished format if the document as is were implemented? Thousands of pages will be broken and many users, including me, may get fed-up with Wikipedia and leave. A table is going to be dense and intimidating to nontechnical users no matter what but tables are very useful when it comes to effectively presenting tabular data (something we have a lot of). Thus putting this complexity on a separate page seems to be a good compromise between preventing newbies from not being intimidated by hordes of markup and allowing more seasoned users the ability to present tabular data in a table. How the page functions for the reader is just as important as how it functions for the writer. And just as different writers have different abilities to contribute prose to an article, we have different coders with different abilities to add markup to articles. We don't dumb down the prose of articles to reach the lowest common denominator reader/writer (except for intro paragraphs) and we should not similarly dumb down the markup just to make things a bit easier for the lowest common denominator coder. Just segregate the tables from the prose and both the markup- phobic and the markup gurus will be happy (that's not to say that I advocate for full HTML support; just move the HTML off of the regular article page and into its own namespace). I would still like to know if a conversion script would be run. If not, then disabling HTML would make Wikipedia look badly broken with the displayed text of tens of thousands of instances of HTML markup. And all that would have to be re-coded in the new syntax by hand. If it is run then the script is going to mangle any table that has markup in it that is no supported in the proposed wikicode. Either way we are talking about changing masses of content that somebody is going to have to repair. Why in the world is it necessary to break so many things and therefore create so much added work? The negative side-effects of the proposed WikiSyntax will cause far more problems than it purports to solve, IMO. Please replicate in WikiCode the HTML we currently support (well, maybe not the obscure stuff that is hardly ever used) and/or create a table:namespace. -- Daniel Mayer (aka mav) PS - We've seem to have done fine during the past 2+ years with tolerating HTML where it makes sense (such as tables).

1 0

Re: [WikiEN-l] Application for sysop status & the assocation of Wikipedians
by Anthere 15 May '03

15 May '03

--- "Alex T." <alex756(a)nyc.rr.com> wrote: > From: "Anthere" <anthere6(a)yahoo.com> > I don't understand your response are you saying > that you are not conerened something because you > do not understand it? I did not really understand everything in the content of your page on meta. I hope someone will comment it, so it will become clearer. I also think this does not belong to the english list, unless there is need to show the association does only concern the english wikipedia. (I think that "I did not > really > understood it" is not proper English) Yes. You are right :-) I did not really understand it I have not understood it Really, this was not clear Perhaps did I not understand it very well I think I misunderstood it Misunderstanding is under way Pick up you choice This further make me think I am not concerned :-) > alex756 > > > > I...err...well...looked at that page...and must > > admit...I did not really understood it :-(( > > > > My only feeling is that I was not concerned by it > :-( > > > > > > > > __________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo. > > http://search.yahoo.com > > _______________________________________________ > > WikiEN-l mailing list > > WikiEN-l(a)wikipedia.org > > http://www.wikipedia.org/mailman/listinfo/wikien-l > > > > _______________________________________________ > WikiEN-l mailing list > WikiEN-l(a)wikipedia.org > http://www.wikipedia.org/mailman/listinfo/wikien-l __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

1 0

SCO vs. IBM
by Kurt Jansson 15 May '03

15 May '03

We should follow the SCO vs. IBM case closely, because in a few years there might be a similar attempt to sue Wikipedia. For the paranoids among us: Maybe the Encycloedia Britannica employees have already begun entering masses of EB snippets into Wp articles ... ;-) From http://www.sco.com/scosource/letter_to_linux_customers.html : "As you may know, the development process for Linux has differed substantially from the development process for other enterprise operating systems. Commercial software is built by carefully selected and screened teams of programmers working to build proprietary, secure software. This process is designed to monitor the security and ownership of intellectual property rights associated with the code. By contrast, much of Linux has been built from contributions by numerous unrelated and unknown software developers, each contributing a small section of code. There is no mechanism inherent in the Linux development process to assure that intellectual property rights, confidentiality or security are protected. The Linux process does not prevent inclusion of code that has been stolen outright, or developed by improper use of proprietary methods and concepts." "As a consequence of Linux’s unrestricted authoring process, it is not surprising that Linux distributors do not warrant the legal integrity of the Linux code provided to customers. Therefore legal liability that may arise from the Linux development process may also rest with the end user."

1 0

A vision for wiki syntax, documented
by Lee Daniel Crocker 14 May '03

14 May '03

Here's the URL: <http://www.piclab.com/cgi-bin/wiki.pl?Wikipedia_Text_Syntax> A few points to note: While the document may seem complex because it attempts to be rigorously specified, the final syntax is actually simpler than what we have now. For one thing, ALL HTML is forbidden; the things we use it for now can be replaced by the major new features: table syntax and styles. Half the document describes how we deal with lists, which we are already doing, but which is hard to specify. Styles, in particular, hide a lot of complexity. With a good toolbox of style classes in the standard stylesheet, users can do a lot of things by simply calling them by name without having to know how they work. This document does not specify how particular stylesheets get attached to particular documents--that too is an implementation detail the user shouldn't have to deal with. Another simplification is that link syntax is unified: they all use "[[...]]" now, whether external or internal, and all use "|". I came to agree with those who said that users would expect quote marks for italic and bold to span input lines, so I allowed that, and close them only at the end of paragraphs. I'm not married to the blockquote thing--it's just a trial baloon, but I think it would be useful. Note that math equations are now integrated, rather than being an add-on; this is so that styles can be applied to them as well. Also, the "$$" syntax seemed more consistent with the rest of the syntax, and will be familiar to TeXies. So as I said, this is a vision. I invite comment and criticism. But I think it's important to Wikipedia's future that we do a good job of this. -- Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Wikipedia-l May 2003