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