subject:
[Wikipedia-l] What a wiki table syntax needs to do to work
 withcurrent   table layouts

in_reply_to: <3D147B050032079B@mail.epost.de> (added by postmaster@mail.epost.de)

body:
On Sun, 4 Aug 2002, Magnus Manske wrote:

> "Hr. Daniel Mikkelsen" <daniel at copyleft.no> wrote:

>>Is this really what we want? To have articles decide layout and colors? I think
>>this is a very scary development - this is the same thing that happened to the
>>web in the early days, and look where we are now! Next thing, we have
>>[[flash:fun.swf]]!

> IMHO, it is a Good Thing to have all articles within the same encyclopedia
> that deal with similar content to use similar layout.

Are you actually saing: "It is a Good Thing to have different layout for
different groups of articles within the same encyclopedia." ?

Because we already _have_ the same layout for similar content. Everything has
the same layout.

Perhaps you aren't thinking about layout, but items of content? Such as
specs for a country. There is no conflict between including such standard
content in all such articles, and avoiding the use of author-driven coloring
and layout.

> It would also help to develop a reputation as a source of knowledge, compared
> to a "random dump of factoids".

I just can't see how you reach this conclusion. Nothing exudes knowledge like
pure content, without bells and whistles, color and flash.

> Of course, an editor can still use it as the latter, but there should be an
> easy way to make wikipedia look a little more "organized" than the whole web.
> After all, we apply our own standards on content, why not on style and layout
> as well, where it makes sense?

Wikipedia already IS more "organized" than the whole web. Articles look the
same, work in the same interface, link cleanly to eachother, are available in
printable format, etc. The web, on the other hand, is a total mess of flash,
frames, incompatible "standards", bad layout, and abuse of markup (tables for
layout, etc.).

Why not apply our own standards on style and layout as well? Because there is
simply no need for this! Wikipedia is an encyclopedia, not a Powerpoint slide!
And because once you open up colors and layout it _will_ be abused. People
_will_ use colors to encode content (see the periodic table), which means we
_will_ lose the ability to transfer cleanly to other media (such as voice or
print).

In addition, as has been mentioned here again and again, layout and styling
will complicate markup, and this will scare away writers - and writers are more
important than readers.

If one must have differently colored tables in, say, plant articles and country
articles, then let that be a property of the article, not the tables. Then get
the Wikipedia programmers to add some kind of category system which in turn can
determine the style sheet used (by HTML) in the tables. Sounds horrible? I
agree, but this is basically the same as styling tables directly, only less
intrusive and more forward compatible.

Another thing I already find quite upsetting is the tendency to use right
aligned "floating" tables. What is the use of this? It disociates the table
from the page, making it much more difficult for an alternate rendering agent
to determine where to put it (when to read it out aloud, for instance).

Okay, I notice I'm getting myself worked up here, so I'll stop. But please,
can't you all see that this is the road to disaster?

-- Daniel


list: wikipedia-l

source: pipermail-mbox

from_name: daniwo59 at aol.com

subject: [Wikipedia-l] Protected Copernicus as Ermland Administrator and the Pruss...

body:
Thank you for doing that. I agree that that is probably the wisest answer to
this problem, though it was not something I could do myself as I was
involved. I am frustrated by what I consider to be revisionist spam, some of
it copyrighted, being posted here. I hope there is some solution.

Danny


from_name: Neil Harris

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work	withcurrent
 table layouts

body:
The Cunctator wrote:

>A wiki markup that's simple but able to handle reasonably fancy tables by
>employing stylesheets.
>
>The complicated Sainfoin table (http://www.wikipedia.com/wiki/Sainfoin)
>would be written as:
>
>[[table:plant
>[{                            Sainfoin                             }]
>[|                [image: OnobrychisViciifolia-thumb.jpg]          |]
>[{                  [[Scientific classification]]                  }]
>[|                      [[table:classification
>    [| [[Kingdom (biology)|Kingdom]]:   | [[Plantae]]          |]
>    [| [[Division (biology)|Division]]: | [[Magnoliophyta]]    |]
>    [| [[Class (biology)|Class]]:       | [[Magnoliopsida]]    |]
>    [| [[Order (biology)|Order]]:       | [[Fabales]]          |]
>    [| [[Family (biology)|Family]]:     | [[Fabaceae]]         |]
>    [| [[Genus]]:                       | '''''Onobrychis''''' |]
>    [| '''[[Species]]:'''               | '''''vicifolia'''''  |]
>                                   ]]
>|]
>[{            [[Binomial nomenclature|Binomial name]]             }]
>[|                  ''Onobrychis vicifolia''                      |]
>]]
>
>{ } is for th, | | is for td.
>
>
>
Yes, that's superb. I can read and understand it easily, and it should
be easy for people to grasp.

Neil


from_name: Hr. Daniel Mikkelsen

subject: [Wikipedia-l] Image text.

body:
Hi.

On the topic of transferring Wikipedia content to other media - is there a way
of giving pictures descriptions in the context of an article? Since a picture
can be used in several articles, the descriptions have to be part of each
article (since what it represents might vary from context to context).

Ideally, I'm looking for both an "alt"-text (to represent the picture when it's
not possible to display it, like "a map of Germany") as well as a subtext,
"Fig. 2. This diagram plots the growth of Wikipedia."

Is this possible to do with the [Image:] tag?

-- Daniel


from_name: Karen AKA Kajikit

subject: [Wikipedia-l] Query - does deleting an image delete the associated image page too?

body:
I just deleted mama.jpg which is a picture of somebody's rather cute
rat... it was listed on the 'votes for deletion' page and the image page
seems to still be there even though I just tried to delete it too. If
you click on the link it takes you to the page, which now has no text
and no image...

So does that page still exist or not?

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


from_name: Kurt Jansson

subject: [Wikipedia-l] Image text.

body:
> [...] as well as a subtext,
> "Fig. 2. This diagram plots the growth of Wikipedia."
>
> Is this possible to do with the [Image:] tag?

Together with a method for image justification in the tag, like
discussed some days ago, this would make tables for images completely
superfluous.

Kurt


from_name: Daniel Mayer

subject: [Wikipedia-l] Super simple table using preformatted text

body:
In all the wiki table syntax hoopla I think we have forgotten about the "p"
word; preformatted text. I spent a couple of hours creating a simple linear
HTML list at http://www.wikipedia.com/wiki/List_of_elements_by_name and then
Zoe created http://www.wikipedia.com/wiki/List_of_elements_by_symbol by using
preformatted text.

Unlike my table, Zoe's is /very/ easy to read in edit mode and is just what
an HTML unaware person would expect to see after hitting 'edit this page'.

In these cases it would be nice to have a way to justify this list,
optionally create a border around it and change the parsing on it to default
font instead of the hideous courier. Then making a table like that will be as
easy as it was with typewriters of old.

I tried to put some pre-formatted text I originally created on my palm-pilot
and then copied to http://www.wikipedia.com/wiki/Talk:Glycolysis into a table
so that it could be right justified and placed alongside the glycolysis
article but HTML tables treat the preformatting spaces as whitespace and
ignore it.

Would it be possible to change the font of preformated text and allow
preformatted text in tables (whatever the syntax)?

Just kicking around another idea.

--mav


subject: [Wikipedia-l] Image text.

body:
On Sun, 4 Aug 2002, Kurt Jansson wrote:

>> [...] as well as a subtext,
>> "Fig. 2. This diagram plots the growth of Wikipedia."
>> Is this possible to do with the [Image:] tag?

> Together with a method for image justification in the tag, like
> discussed some days ago, this would make tables for images completely
> superfluous.

For the record, I don't think images should be justified.

-- Daniel


from_name: tarquin

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
I suggest we formulate a policy on using SAMPA for pronunciation of words
In the long run, IPA might be nicer, since paper dictionaries &
encyclopedias use it. However, until there's good support for Unicode,
sampa is readable on any browser. If at some point we can switch, the
two are in direct correspondance.

I've started looking for articles which use pseudo-phonetic
transcriptions, & putting a list on
http://www.wikipedia.com/wiki/SAMPA/To_Do

We could make [[pronounced]] a redirect to SAMPA, or a simplified SAMPA
table page for ease of linking from articles which give pronunciation.


from_name: Pierre Abbat

subject: [Wikipedia-l] Copyright alert

body:
The pages [[Sic bo]] and [[Let it ride]] were copied from the website listed
on them, which has no indication that I could find of the copying policy.
Should they be deleted, or what?

phma


from_name: Jeroen Heijmans

subject: [Wikipedia-l] Protected Copernicus as Ermland Administrator and the Prussian Coin Reform

body:
I've just protected the page Copernicus as Ermland Administrator and the
Prussian Coin Reform, because Danny and Helga are adding and deleting
the contents back and forth. Although I think Danny is right in his
actions, I want it to be sorted out on the talk page instead of having
this constant editing. If I was wrong to do so, simply undo it, and I
will not do this again.

Jeroen Heijmans


subject: [Wikipedia-l] Need of content (was: What a wiki table syntax...)

body:
"Hr. Daniel Mikkelsen" <daniel at copyleft.no> wrote:

 > I just can't see how you reach this conclusion. Nothing exudes
knowledge like
 > pure content, without bells and whistles, color and flash.

 > Why not apply our own standards on style and layout as well? Because
there is
 > simply no need for this! Wikipedia is an encyclopedia, not a
Powerpoint slide!
 > And because once you open up colors and layout it _will_ be abused.
People
 > _will_ use colors to encode content (see the periodic table), which
means we
 > _will_ lose the ability to transfer cleanly to other media (such as
voice or
 > print).

Though bells and whistles may be wrong, adding structure and colours may be
very useful, _especially_ for an encyclopedia. I use an encyclopedia to look
up information. Therefore, I don't (always) quickly want to read through an
enourmous amout of data. A table with the animal kingdom to which this
species
belongs is a very quick way to find referenc information, and so is a
coloured
elements table with specific groups easily identifiable. I wouldn't even
consider
buying a plain text encyclopedia in my bookstore, would you?

As for the need to transfer to other formats: printed text can contain
colour as
well (or gray-shades, for that matter) and one can talk rather
colourfully ;-)
But seriously, if other formats were an issue at all, conversion should
take care
of this.

 > In addition, as has been mentioned here again and again, layout and
styling
 > will complicate markup, and this will scare away writers - and
writers are more
 > important than readers.

Are they? Well, I certainly hope the article I write are read!
Otherwise, I'll be
gone soon. Of course, we need writers, but I think we'll only scare away the
vandals, and not those really willing to contribute. There's a learning
curve,
but new editors are coming in all the time, and most people understand
that adding
in a complex structure takes some time to learn - and they do.

Adding one consistent style to a group of articles will in fact make it
easier for
editors to work with them, since you can copy from other examples. The
benefit for
the reader should be obvious, I think.

 > Another thing I already find quite upsetting is the tendency to use right
 > aligned "floating" tables. What is the use of this? It disociates the
table
 > from the page, making it much more difficult for an alternate
rendering agent
 > to determine where to put it (when to read it out aloud, for instance).

You will notice that many of these tables contain rather factual
information that is
rather difficult to put in an article in a good running text (often the
country
article, f.e. contained a group of sentences like: "The capital is X.
The king is Y.
There are Z inhabitants." etc.). Nevertheless, these facts are sometimes
the only
thing people are interested in.

The entire idea of such tables is not new; many encyclopedias in print
also use
them.

 > But please, can't you all see that this is the road to disaster?

No, I can't.

Jeroen Heijmans


from_name: Lars Aronsson

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work
 withcurrent table layouts

body:
One thing I never liked about HTML tables is that I have to mark both
the beginning and the end of each cell, row, and table.  I've never
yet had the need for starting a new cell without closing the previous
one or ending a row without ending the cell.  Working with a
typewriter and the TAB key, or with tables in a word processor, I just
go to the next cell, I never have to both exit the current cell and
enter the new one.  When I write software that outputs HTML, I always
create the following four functions:

  table()     emits "

"
  nextcell()  emits "	"
  nextrow()   emits "

"
  endtable()  emits "

"

Parameters to these functions can set attributes to the emitted tags,
if there is such need.

Most suggestions here repeat the HTML/XML mistake of both opening
and closing each cell and line.   What you really need is the above
four primitives.  Forget XML.  A table could then look like this:

   '''Name'''      <tab>'''Instrument'''
<row>     Bill Clinton    <tab>Saxophone
<row>     Louis Armstrong <tab>Trumpet

Since
 and
 are required to match in pairs, you can
even include a table in the cell of another table, if need be.

   '''Name'''      <tab>'''Instrument'''
<row>     Bill Clinton    <tab>Saxophone
<row>     Louis Armstrong <tab>
'''Age''' <tab>Instrument
                               <row>  0-3       <tab>Drum
                               <row>  3-10      <tab>Guitarr
                               <row>  10- up    <tab>Trumpet

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Please test sound clips.

body:
I'd like to flesh out the policies on sounds, so I'd appreciate it if
a few of you could test things out a bit.  I cleaned up all the
[[Simon and Garfunkel]] articles and added a few samples (since I have
a good S&G collection to use).  Let me know how easy or hard it is to
set up your browser to hear them, whether or not they sound reasonably
good, and whether or not they take too long to download.  I can adjust
recommended encoder usage, recommended bitrates, etc., based on your
feedback.


from_name: Jan Hidders

subject: [Wikipedia-l] Parsing TeX to MathML

body:
On Sat, Aug 03, 2002 at 04:17:07PM +0200, Jens Frank wrote:
>
> I took a deeper look at MathML today. One thing seems to be a showstopper
> in the Moment: For Mozilla to render the MathML extensions the page must
> have Content-Type "text/xml" instead of "text/html". But in XML many of
> our pages are not valid, e.g. a line break has to be coded as
 in
> XML instead of
 in HTML. Mozilla's parser will stop and create an
> error message as soon as it finds an unmatched tag like
.

Interesting point. Although there are some tools to convert to XML such as
Tidy [ http://www.w3.org/People/Raggett/tidy/ ] this probably is another
argument for not having HTML mark-up.

-- Jan Hidders


from_name: Krzysztof P. Jasiutowicz

body:
On 04-08-2002, Jeroen Heijmans wrote thusly :
> I've just protected the page Copernicus as Ermland Administrator and the
> Prussian Coin Reform, because Danny and Helga are adding and deleting
> the contents back and forth. Although I think Danny is right in his
> actions, I want it to be sorted out on the talk page instead of having
> this constant editing. If I was wrong to do so, simply undo it, and I
> will not do this again.
Hello all,

I think that Helga is a bad soul in Wikipedia and she should be
counter-acted.

It is very well to voice your own point-of-view but after all it must be
NPOV.
There's a lot of effort put into reconcilitation between Polish and
German people. Younger generations are trying to move away from the past
and build on peaceful future in the common Europe.

I can see in my country that the Communist propaganda poisoned minds
of so many people. I only hope that the majority of Germans think
differently than Helga.

We witnessed in the Balkans what hatred and prejudice can do with longtime good
neighbours. Helga constant proclaiming that it was the German people who were persecuted and driven away from their homelands is making no good. The Polish communities in the east also where told by the Russians and the Polish Communists to take what they could carry and go westwards. There was no coming back.  We, the Polish, also have our Displaced Generation. It can be compared with the recent examples of ethnic cleansing.

I do not deny that thousands of Germans can have the feeling of a loss but
one can not weigh the tragedies of the both sides.

Regards,
kpj.


subject: [Wikipedia-l] What a wiki table syntax needs to do to work withcurrent table layouts

in_reply_to: <3D4D0766.8060905@planetunreal.com>; from tarquin@planetunreal.com on Sun, Aug 04, 2002 at 11:52:22AM +0100

body:
On Sun, Aug 04, 2002 at 11:52:22AM +0100, tarquin wrote:
> >
> > Another thing I already find quite upsetting is the tendency to use
> > right aligned "floating" tables. What is the use of this? It disociates
> > the table from the page, making it much more difficult for an alternate
> > rendering agent to determine where to put it (when to read it out aloud,
> > for instance).
>
> I second the comment on right-aligned tables.

I also second it, but with a small addendum. On my browser/screen
combination a non-floating figure will have a lot of valuable whitespace
left or right of it and such an article will therefore require less
scrolling or may even fit on one screen. So although I agree with Daniel
that the article itself should not determine if a figure floats or not, I
would like to have a skin or user option that has all figures floating to the
right (or left).

-- Jan Hidders


from_name: Brion VIBBER

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work withcurrent
 table layouts

body:
Lars Aronsson wrote:
> Brion VIBBER wrote:
>>Actually, that's not true in HTML; the <table> tag is the only one that
>>has to be closed. A lot of people close the others out of habit (I think
>
> As far as I know, the standard requires all table related tags to be
> closed,

Nope: tr, td, and th do not have to be closed.

See: http://www.w3.org/TR/html401/struct/tables.html

 > but some browsers (notably MSIE) manage to render the table
> even if the HTML code violates the standard.  HTML validators barf on
> tables with unbalanced tags.  Still, this is beside my point.

With _unbalanced_ tags, sure. With correctly structed tables with
omitted close tags, they would be in blatant disregard of the standard
if they barf.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Please test sound clips.

body:
lcrocker at nupedia.com wrote:
> I'd like to flesh out the policies on sounds, so I'd appreciate it if
> a few of you could test things out a bit.  I cleaned up all the
> [[Simon and Garfunkel]] articles and added a few samples (since I have
> a good S&G collection to use).  Let me know how easy or hard it is to
> set up your browser to hear them,

On my present system (Windows 2000; Mozilla 1.1b; Winamp w/ Ogg plugin)
I had to manually configure my browser to launch Winamp (or else save
the file to disk, then launch it from explorer).

 > whether or not they sound reasonably
> good,

They sound great as little sample clips go. Not like the reduced
sample-rate, mono crap you get on so many sites that are actually trying
to sell you music...

 > and whether or not they take too long to download.  I can adjust
> recommended encoder usage, recommended bitrates, etc., based on your
> feedback.

I would seriously recommend mentioning the file size (hence mental
estimate of download time for dial-up folks) and the fact that the
sample is in Ogg Vorbis format (hence a link to appropriate software).

Non-techheads who don't know what an "ogg" is and may not yet have
appropriate software installed aren't going to be enthused at the
mystery file that nothing will play.

-- brion vibber (brion @ pobox.com)


from_name: Toby Bartels

subject: [Wikipedia-l] Parsing TeX

body:
Jan Hidders wrote:

>Toby Bartels wrote:

>>(Contrary to popular opinion, I've never suggested $$x \le y$$.

>Sorry for that, I started that rumour, it seemed like a logical
>generalization of your idea and as such not a bad suggestion.

>>What I suggested was $$x$$ ≤ $$y$$, which won't fool any TeXer
>>into thinking that it's actual TeX; the markup is merely *inspired* by TeX.

>I would not be so sure: $$ *is* LaTeX mark-up.

Hence the inspiration.  But ≤ is not, much less outside of math mode.
One of the first things that a new TeXer learns is that
the fastest way to an error is writing something like $x$ \le $y$.
Of course, you're a TeXer too, so I should listen if you disagree,
but *I* don't see how anybody will be fooled.

>>The only thing that $$...$$ has over [[math:...]] is in the situation of a
>>very short formula like a single letter, and there it's better to use
>><var> instead of a gif *anyway*.

>I disagree strongly. That would mean that if I have a formula with one
>letter variables and two letter variables the first would be written as
><var> and the second as TeX within the same text. Always using LaTeX will
>look better and is more consistent.

I don't see why we should expect somebody to have a graphical interface
to read "Suppose that $$x$$ is a [[real number]]. Then ...".
That's reasonable for "If $$\int_a^b f(x)\,dx$$ exists, ...",
which is legible to hardly anybody except as a picture,
but the first will be mighty annoying to read if a voice reader
describes it as "image labelled "x"" or something.

There's another reason for having a simple method producing <var>
and a complicated method producing a PNG by calling LaTeX.
LaTeX is hardly more easy for a technophobe to learn than HTML,
and we don't want them to think that they can't edit a math expression
without learning LaTeX.  Tell them that [[math:]] is this huge PITA
(which can't be avoided with an integral) but that $$ is easy as pie.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Parsing TeX

body:
Lee Daniel Crocker (?) wrote:

>Formulas should be seen as "inclusions", so I prefer the [[math:
>syntax overall.  The software should look at the formula inside
>the brackets, and choose how to output it.  In particular, if it
>detects Mozilla it should output MATHML instead of calling TeX.
>Maybe if it's just a variable name, it could just output a <var>.

That would be nice if the system could be that intelligent.
This would work if we parsed the material before passing it to LaTeX,
which perhaps we should do anyway for security reasons.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Parsing TeX

body:
JeLuF wrote in part:

>$\sum_{i=1}$ and $$\sum_{i=1}$$ render to different images in TeX, for
>a good reason: keep lines with inline math as small as possible.
>[[math: ]]-Syntax currently renders everything in $$ ... $$ but displays
>it inline.

I'd rather default to rendering it in $ than rendering it in $$.

>So to get a display-formula you would have to do something like
>:[[math:\sum_{i=1}]]
>which is not realy a display formula, since the HTML generated is a
><BLOCKQUOTE> and not a <CENTER> of the formula,

There are LaTeX styles that display formulas left justified and indented;
it's no shame if we're one of them.  There is shame in using <blockquote>
for formatting purposes, of course, but that's a long lost battle.

>The namespace "math" makes it easy for the casual reader of the source
>to recognize that the character garbage to follow has something to do
>with mathematical markup. This schema can easily be expanded to provide
>more than just math markup, e.g. something like
>  [[barchart:(1999,37) (2000,45) (2001,60)]]
>which would fit perfectly into [[image:, [[media:, [[math: ...

Interesting ideas, but we do want to keep the simple things easily edited.
[[math:\int_a^b f(x)\,dx]] will look horrid no matter how we encode it,
but [[math:x]] should not.

>This misuse of namespaces does not look very 'wiki'.
>$ ... $ and $$ ... $$ look more similar to ''...'' and '''...'''.

I don't think that this is a misuse of namespaces at all.
The plan here is to draw up a PNG for each formula,
with some (like [[math:E = mc^2]]) used in several articles,
and this PNG will be a file on the server just like $$.
Why, we can even click the formula to ... I don't know what,
but maybe we'll think of something to do with it someday.

>I just took a look at MathML. May I assume that we are not wanting to write
>MathML to enter formulas instead of something TeXish?

It's worth remembering that MathML was never intended for human consumption.
When it's widely supported, then we can *output* it,
but we don't want to *input* it.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Advanced free linking

body:
Jan Hidders wrote:

>Perhaps curly braces arount the parts you don't want in the link name?:
>* [[English {language}]] --> [[English language|English]]
>* [[{George W.} Bush]] --> [[George W. Bush|Bush]]
>You could then even exclude multiple parts from the link name.

I'd rather put the braces around the part that we *do* want:
* [[{English} language]] --> [[English language|English]]
* [[George W. {Bush}]] --> [[George W. Bush|Bush]]
* [[{George }W. {Bush}]] --> [[George W. Bush|Bush]]
The last could be [[{George} W. {Bush}]] if we want to
make the parser smarter but slightly less flexible
(in a way that is implicit in Jan's version).

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] What a wiki table syntax needs to do to work with current table layouts

in_reply_to: <3D4BCE76.950152EA@labyrinth.net.au>; from kaji@labyrinth.net.au on Sat, Aug 03, 2002 at 10:37:10PM +1000

body:
On Sat, Aug 03, 2002 at 10:37:10PM +1000, Karen AKA Kajikit wrote:
>
> If you want to include fancy colours and styles, and you want the average
> user to be able to use them in a standardised way, then you really need to
> preset the tables (eg the taxonomy table that's being added to each
> animal/plant entry). It doesn't matter WHAT the actual coding is if the
> user can write [[table:taxonomy]] or [[table:elements]] or [[table:other]]
> or whatever at the top of their data and have that particular formatting
> applied to their basic table data.

This has made me rethink my position. Your opinion on this is very important
here since you represent here the group of users we should aim at. To make a
long story short, after reconsidering all the arguments, rereadings some
posts and a good night sleep I have come to the conclusion that the above
approach (a table mark-up with no formatting + a label that indicates the
type of the table and has formatting information associted with it) is
indeed the best approach.

I'm still left with two concerns, though, and I wonder what other's think
about it:

1. Since the table-types are in some sense part of the mark-up they should
   be small in number, stable and well-documented (in case somebody wants to
   define a transformation to another medium and/or format). One solution
   would be to consider the definitions of these styles as part of the code
   in the sense that they are defined and documented by a small set of style
   developers.

2. Sometimes people want to make a single formatted table such as the one in
   the Roulette article. It's a one-of-a-kind table but the formatting is
   important because it is actually an illustration. Making such tables is
   going to be very hard and maybe even impossible if normal users cannot
   create new table styles. Is this a problem or should such illustrations
   be done with figures anyway?

-- Jan Hidders


subject: [Wikipedia-l] 'Old Hands' -- spreading the power around

body:
Pierre Abbat wrote in part:

>Old hand: Three different old hands together can block an IP address or a
>user. Maybe three old hands voting to delete the same article, with no
>intervening edits of the article, can delete it.

I think that this is too few for blocking IP addresses.
Certainly we shouldn't implement that right away.
I'd like to devolve power slowly as mav suggested.
Whether we need to get rid of sysops entirely (I'd like to too) or not,
we can figure out as the devolution goes along.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Tarquin wrote:

>I suggest we formulate a policy on using SAMPA for pronunciation of words
>In the long run, IPA might be nicer, since paper dictionaries &
>encyclopedias use it. However, until there's good support for Unicode,
>sampa is readable on any browser. If at some point we can switch, the
>two are in direct correspondance.

I think that Evan Kirschenbaum's system is better for our purposes.

http://www.kirshenbaum.net/IPA/faq.html

More of the common European phonemes are easy to read here,
at a loss of the ability for precise phonetic transcription.
But then the possibility of precise transcription is returned
at the cost of using incomprehensible codes like <unx> ("unexploded").
Since we'll be wanting phonemes almost exclusively, this is good.

The downside is that we *don't* have a one to one correspondence with IPA,
but it's still possible to do machine translations later if desired,
with some ambiguity about which letters to use for phonemes.
(There's no ambiguity in the *meaning* of the symbols, however;
this is just the usual ambiguity in phonemic symbols,
deciding between /k/ and /x/ for a phoneme with both allophones.)

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Please test sound clips.

body:
> I would seriously recommend mentioning the file size (hence mental
> estimate of download time for dial-up folks) and the fact that the
> sample is in Ogg Vorbis format (hence a link to appropriate software).

I actually did have file sizes in earlier versions' I then discovered
that my encoder had a bug that was causing them to be larger than
necessary.  With the smaller files I saw less need to warn about large
file sizes.  But they're still 100K or so (and the largest is 200K),
so maybe the size should still be there.

But I strongly disagree that there should be any mention at all of the
format or a link to an explanation of it on pages that merely use
clips.  We certainly do need a page that explains how to hear them in
various OSs and browsers, but none of that should clutter a page that
merely uses sound as content.  The user's browser should help a
bit--it will report that the file being sent is of type
"application/x-ogg", and tell the user that a plugin or external
player is required.

Perhaps we could have something more visible on the main page or the
"how to use wikipedia" pages pointing to the page explaining how to
play Oggs.

P.S. I'm glad you find the sound quality good--but perhaps it doesn't
even need to be that good?  Would, say, a mono version at the same
quality or even a bit lower be sufficient as a sample?


in_reply_to: <B97161A5.2586%cunctator@kband.com>; from cunctator@kband.com on Sat, Aug 03, 2002 at 10:32:05AM -0400

body:
On Sat, Aug 03, 2002 at 10:32:05AM -0400, The Cunctator wrote:
> A wiki markup that's simple but able to handle reasonably fancy tables by
> employing stylesheets.
>
> The complicated Sainfoin table (http://www.wikipedia.com/wiki/Sainfoin)
> would be written as:
>
> [[table:plant
> [{                            Sainfoin                             }]
> [|                [image: OnobrychisViciifolia-thumb.jpg]          |]
> [{                  [[Scientific classification]]                  }]
> [|                      [[table:classification
>     [| [[Kingdom (biology)|Kingdom]]:   | [[Plantae]]          |]
>     [| [[Division (biology)|Division]]: | [[Magnoliophyta]]    |]
>     [| [[Class (biology)|Class]]:       | [[Magnoliopsida]]    |]
>     [| [[Order (biology)|Order]]:       | [[Fabales]]          |]
>     [| [[Family (biology)|Family]]:     | [[Fabaceae]]         |]
>     [| [[Genus]]:                       | '''''Onobrychis''''' |]
>     [| '''[[Species]]:'''               | '''''vicifolia'''''  |]
>                                    ]]
> |]
> [{            [[Binomial nomenclature|Binomial name]]             }]
> [|                  ''Onobrychis vicifolia''                      |]
> ]]

Looks very understandable to me. Just a few minor remarks:
- The style markup [[table:plant]] is very similar to something with a
  completely different meaning. Perhaps we should take Lee's suggestion here
  and use {{table:plant}} or even {table:plant} although I prefer to use
  double brackets for markup because single brackets are probably
  already in normal use somewhere.
- Be careful with the indented lines because these now have the meaning of
  <pre>...</pre> in the current markup.
- I don't if in CSS you can redefine a normal table rule as a header rule or
  a caption rule, but if you can the the [{ }] notation is superflous, and
  if you cannot then we probably need some extra notation for caption.
- The CSS for table:plant can probably already determine the formatting of
  the nested table, so table:classifiction is probablu superfluous.

> In theory, we could write
>        [[table:plant]]
> [{        Sainfoin          }]
> [| ''Onobrychis vicifolia'' |]
>
> instead, by using a blank-line rule to determine when tables end. That
> looks nicer and probably would be simpler to parse. But would be a bit
> less flexible. Do we need that flexibility? Not necessarily.

Actually, there's no problem here if you refine this rule such that a table
ends if a |] is not immediately followed by [| on this line or the next
line. In that case you don't lose any flexibility at all. However, you would
also have to adapt Lee's rule for defining a <DIV> section a little to allow
empty rules in tables.

-- Jan Hidders


subject: [Wikipedia-l] What a wiki table syntax needs to do to work withcurrent   table layouts

body:
On Sun, Aug 04, 2002 at 12:43:18PM +0200, Hr. Daniel Mikkelsen wrote:
>
> Okay, I notice I'm getting myself worked up here, so I'll stop. But please,
> can't you all see that this is the road to disaster?

I agree with many of your point but what is "this" in your sentence above? I
would say that the CSS + simple table mark-up without formatting nicely
separates formatting from content, so what do you think is wrong with it?

-- Jan Hidders


body:
On Sun, 4 Aug 2002, Jan Hidders wrote:

>> Okay, I notice I'm getting myself worked up here, so I'll stop. But please,
>> can't you all see that this is the road to disaster?

> I agree with many of your point but what is "this" in your sentence above? I
> would say that the CSS + simple table mark-up without formatting nicely
> separates formatting from content, so what do you think is wrong with it?

Sorry, I was worked up. With "this" I meant the move towards excessive table
syntax, and breakage of form-free content. I agree that CSS + simple table
markup is ideal.

-- Daniel


from_name: rose.parks at att.net

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Hello members..

In regard to the suggestion below - that pronunciations
be supplied in phonetics or pseudo-phonetics in SAMPA, I
find a number of problems.

First, American English and British English do not have
the same pronunciation for the same words, yet the two
are intermixed in the English wikipedia.

Second, no dictionary or encyclopedia offers phonetic or
pseudo-phonetic pronunciations. They offer some kind of
_phonemic_ pronunciation.

The decision to use SAMPA is not an obvious one. Very
few ordinary people are familiar with SAMPA symbols.
Probably British English speakers are much more aware of
the IPA, since it is used consistently in the Oxford
Press publications. American English speakers use
dictionaries that use a variety of pronunciation guides,
but all based on the IPA.

     I think any decisions on supplying pronunciations
require a great deal more consideration, before anything
is implemented.

              As Ever,

                 Ruth Ifcher

--

> I suggest we formulate a policy on using SAMPA for pronunciation of words
> In the long run, IPA might be nicer, since paper dictionaries &
> encyclopedias use it. However, until there's good support for Unicode,
> sampa is readable on any browser. If at some point we can switch, the
> two are in direct correspondance.
>
> I've started looking for articles which use pseudo-phonetic
> transcriptions, & putting a list on
> http://www.wikipedia.com/wiki/SAMPA/To_Do
>
> We could make [[pronounced]] a redirect to SAMPA, or a simplified SAMPA
> table page for ease of linking from articles which give pronunciation.
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
On Sun, Aug 04, 2002 at 11:45:11PM +0200, Hr. Daniel Mikkelsen wrote:
>
> Sorry, I was worked up. With "this" I meant the move towards excessive
> table syntax, and breakage of form-free content. I agree that CSS + simple
> table markup is ideal.

I'm wondering if it shouldn't be (server-side) XSL + simple table markup.
Does anybody of the CSS experts know if it is powerful enough to generate a
Demographics table as found on [[Netherlands]] from a simple demographics
table?

-- Jan Hidders


from_name: Jens Frank

body:
On Sun, Aug 04, 2002 at 09:24:36PM +0200, Krzysztof P. Jasiutowicz wrote:
> Hello all,
>
> I think that Helga is a bad soul in Wikipedia and she should be
> counter-acted.
>
> It is very well to voice your own point-of-view but after all it must be
> NPOV.
> There's a lot of effort put into reconcilitation between Polish and
> German people. Younger generations are trying to move away from the past
> and build on peaceful future in the common Europe.
>
> I can see in my country that the Communist propaganda poisoned minds
> of so many people. I only hope that the majority of Germans think
> differently than Helga.
>
> We witnessed in the Balkans what hatred and prejudice can do with longtime good
> neighbours. Helga constant proclaiming that it was the German people who were persecuted and driven away from their homelands is making no good. The Polish communities in the east also where told by the Russians and the Polish Communists to take what they could carry and go westwards. There was no coming back.  We, the Polish, also have our Displaced Generation. It can be compared with the recent examples of ethnic cleansing.
>
> I do not deny that thousands of Germans can have the feeling of a loss but
> one can not weigh the tragedies of the both sides.

Hello,

I'm a German, my father is from Silesia (,,Schlesien''). He was forced to move
away at the age of 8. He and his family went to a place in western germany
that is protestantic. As Silesians they were catholic. So nearly every member
of the church I grew up in was a displaced person or child of a DP.

In the time of uproar against the communist regim in Poland ( Walesa,
Solidarnosc, mid of the 1980s I think, ...) our church sent food pakets
to a Polish church. Many pakets were prepared by DPs, sending them also
in the regions of Poland they came from. They did the same the Americans
have done to Germany 35 years before.

Later, after the Iron Curtain was fallen, some of the older DPs went to
Poland to visit the place of their youth. They were glad to see the
church still standing, and sad that some other places do not exist any
more. Time's changing. After a week or two of holiday and sightseeing,
all of them came back.

Many of them would have the money to just buy back their old houses.
They don't do it. They're at home where they were living the last 40 years.
And they know it was against human rights to displace them. And it
would be the same crime to roll back history, to displace the Polish
people living in ,,their'' villages. Most of them also know that it
was the Communist Regime in Poland and mainly in Russia that is res-
ponsible for those actions and not the Polish people.

Many of the older people are in refugee associations (,,Fluechtlings-
verbaende''). They go there to see old friends they know from school.
They go there to talk in their Silesian dialect. And they go there
to see their old dances and dresses. Yes, there are some officials
there, and they say stupid things like "Silesian is ours". But they are
only a few, and many of their own people do not believe what those say.

The younger generation is seeing Poland in a different light.
They see it as a country that is on it's way into the European
Union. It's a country with a lot of economic difficulties,
many of them still being caused by the 40 years of communism
in Poland, a situation very similar to that in Eastern
Germany (the former GDR).

If one would ask people on the street, where Danzig is, I think
the results would be something like 95% saying "Poland" and
5% "unsure" (yes, even in Germany there are people who would
not find their own hometown on a map ...). I'm sure noone would
say that it's in Prussia. There is no Prussia today.

So no, I don't think Germans think the way Helga does.

----

Hmm, I did just want to write 3 or 4 lines to say that
Germans are not like Helga is. Now it became a small
essay already. I think I should stop now before it
becomes a book.

Best regards,

jens frank

----

BTW, the most interesting thing about Helga IMHO is that she
is not living in Germany or in her beloved Prussia but in the
US.


body:
Brion VIBBER wrote:
> Actually, that's not true in HTML; the <table> tag is the only one that
> has to be closed. A lot of people close the others out of habit (I think

As far as I know, the standard requires all table related tags to be
closed, but some browsers (notably MSIE) manage to render the table
even if the HTML code violates the standard.  HTML validators barf on
tables with unbalanced tags.  Still, this is beside my point.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


from_name: Ray Saintonge

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
tarquin wrote:

> I suggest we formulate a policy on using SAMPA for pronunciation of words
> In the long run, IPA might be nicer, since paper dictionaries &
> encyclopedias use it. However, until there's good support for Unicode,
> sampa is readable on any browser. If at some point we can switch, the
> two are in direct correspondance.
>
> I've started looking for articles which use pseudo-phonetic
> transcriptions, & putting a list on
> http://www.wikipedia.com/wiki/SAMPA/To_Do
>
> We could make [[pronounced]] a redirect to SAMPA, or a simplified
> SAMPA table page for ease of linking from articles which give
> pronunciation.

SAMPA may be readable by any browser, but is certainly not readable by
most humans.  Why should SAMPA's system of pseudo-phonetics be
preferable to those that are already used?  Apart from any article about
the history of SAMPA, the best place for this peculiar example of
eurocentrism is in the trash bin.

Eclecticology


from_name: Fred Bauder

subject: [Wikipedia-l] Less Is More

body:
At 09:48 AM 8/5/02 -0400, Ed Poor wrote:
>Tables ought to made as simple and unobtrusive as possible. I hope someone
finds an easy way to do this; or, at least, the easiest conceivable way. I
guess it will always be an "advance" feature for power users.

Tables are the responsibility of whoever puts them on a page. They need to
be suitable for display on commonly used browsers and computers. If they
won't display properly and the "power user" won't fix them they should be
deleted.

Fred Bauder


subject: [Wikipedia-l] Edit Wars

body:
At 09:54 AM 8/5/02 -0400, Ed Poor wrote:
>Locking a page is only a temporary solution to an edit war. It stops the
current battle, of course, but a better long-term solution is to teach
contributors how to write from the NPOV. I'm not saying that this is an
EASY solution, obviously. I myself have struggled mightily to learn how to
write neutrally, and I still fail occasionally on subjects dear to me (such
as Global Warming, which Axel has reverted in flames a few times :-).
>
>I've stepped in from time to time, as in the Eisenhower controversy,
trying to show how information that veers away from the consensus can be
included: usually by summarizing, creating a new article, or demoting
content to an external link.
>
>What do others think about the prospects for educating contributors to the
controversial pages, on how to write from the?

Prospects are dim in certain instances. Some folks have a lifetime
half-life on certain fixed ideas. A crank usually has a narrow focus so
even they can benefit from tips on technique. In instances where a
government in engaged in war or serious domestic conflict Wikipedia is just
a part of their psychological warfare operations, if they bother with us at
all.

But I continue to think a good [[controverial issue]] page would be helpful.

Fred Bauder


body:
>On 04-08-2002, Jeroen Heijmans wrote thusly :
>
>>I've just protected the page Copernicus as Ermland Administrator and the
>>Prussian Coin Reform, because Danny and Helga are adding and deleting
>>the contents back and forth. Although I think Danny is right in his
>>actions, I want it to be sorted out on the talk page instead of having
>>this constant editing. If I was wrong to do so, simply undo it, and I
>>will not do this again.
>>
I see that protecting a page to stifle debate as an abuse of sysop
status.  At present this is a blank page, and that makes the protection
even more silly.  If people want to continue the debate they can do so
by simply restarting the whole debate under a slightly different title
that respects the Wikipedia policy about capitalizing words in an
article title.

And what do opinions about the Polish Communist government have to do
with Copernicus in the 16th century.

Eclecticology


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
The plot thickens:

http://www.cs.brown.edu/~dpb/ascii-ipa.html

 > First, American English and British English do not have the same
pronunciation for the same words, yet the two are intermixed in the
English wikipedia.

I am not suggesting we start adding pronunciation *everywhere*, but that
we standardise pronunciation guides where they are given.

Some sort of IPA version has the huge advantage that the symbols can be
copied to *any* other Wikipedia in any language.


from_name: Poor, Edmund W

subject: [Wikipedia-l] Less Is More

body:
Tables ought to made as simple and unobtrusive as possible. I hope someone finds an easy way to do this; or, at least, the easiest conceivable way. I guess it will always be an "advance" feature for power users.

I like the tables on the U.S. President articles, because it gives a consistent set of links, but the placement of the table could be varied. Also, a consistent set of links could made without a table. Someone (maybe GayCommunist?) has a system of putting a line of links at the beginning of an article, to show its relationship to a large group of similar articles.

Ed Poor


subject: [Wikipedia-l] Edit Wars

body:
Locking a page is only a temporary solution to an edit war. It stops the current battle, of course, but a better long-term solution is to teach contributors how to write from the NPOV. I'm not saying that this is an EASY solution, obviously. I myself have struggled mightily to learn how to write neutrally, and I still fail occasionally on subjects dear to me (such as Global Warming, which Axel has reverted in flames a few times :-).

I've stepped in from time to time, as in the Eisenhower controversy, trying to show how information that veers away from the consensus can be included: usually by summarizing, creating a new article, or demoting content to an external link.

What do others think about the prospects for educating contributors to the controversial pages, on how to write from the?

Ed Poor


body:
On 05-08-2002, Jens Frank wrote thusly :
> On Sun, Aug 04, 2002 at 09:24:36PM +0200, Krzysztof P. Jasiutowicz wrote:
> > I think that Helga is a bad soul in Wikipedia and she should be
> > counter-acted.
> > It is very well to voice your own point-of-view but after all it must be
> > NPOV.
> > There's a lot of effort put into reconcilitation between Polish and
> > German people. Younger generations are trying to move away from the past
> > and build on peaceful future in the common Europe.
> > I can see in my country that the Communist propaganda poisoned minds
> > of so many people. I only hope that the majority of Germans think
> > differently than Helga.
> > We witnessed in the Balkans what hatred and prejudice can do with longtime good
> > neighbours. Helga constant proclaiming that it was the German people who were persecuted and driven away from their homelands is making no good. The Polish communities in the east also where told by the Russians and the Polish Communists to take what they could carry and go westwards. There was no coming back.  We, the Polish, also have our Displaced Generation. It can be compared with the recent examples of ethnic cleansing.
> > I do not deny that thousands of Germans can have the feeling of a loss but
> > one can not weigh the tragedies of the both sides.
> I'm a German, my father is from Silesia (,,Schlesien''). He was forced to move
> away at the age of 8. He and his family went to a place in western germany
> that is protestantic. As Silesians they were catholic. So nearly every member
> of the church I grew up in was a displaced person or child of a DP.
> In the time of uproar against the communist regim in Poland ( Walesa,
> Solidarnosc, mid of the 1980s I think, ...) our church sent food pakets
> to a Polish church. Many pakets were prepared by DPs, sending them also
> in the regions of Poland they came from. They did the same the Americans
> have done to Germany 35 years before.
> Later, after the Iron Curtain was fallen, some of the older DPs went to
> Poland to visit the place of their youth. They were glad to see the
> church still standing, and sad that some other places do not exist any
> more. Time's changing. After a week or two of holiday and sightseeing,
> all of them came back.
> Many of them would have the money to just buy back their old houses.
> They don't do it. They're at home where they were living the last 40 years.
> And they know it was against human rights to displace them. And it
> would be the same crime to roll back history, to displace the Polish
> people living in ,,their'' villages. Most of them also know that it
> was the Communist Regime in Poland and mainly in Russia that is res-
> ponsible for those actions and not the Polish people.
> Many of the older people are in refugee associations (,,Fluechtlings-
> verbaende''). They go there to see old friends they know from school.
> They go there to talk in their Silesian dialect. And they go there
> to see their old dances and dresses. Yes, there are some officials
> there, and they say stupid things like "Silesian is ours". But they are
> only a few, and many of their own people do not believe what those say.
> The younger generation is seeing Poland in a different light.
> They see it as a country that is on it's way into the European
> Union. It's a country with a lot of economic difficulties,
> many of them still being caused by the 40 years of communism
> in Poland, a situation very similar to that in Eastern
> Germany (the former GDR).
> If one would ask people on the street, where Danzig is, I think
> the results would be something like 95% saying "Poland" and
> 5% "unsure" (yes, even in Germany there are people who would
> not find their own hometown on a map ...). I'm sure noone would
> say that it's in Prussia. There is no Prussia today.
> So no, I don't think Germans think the way Helga does.
> ----
> Hmm, I did just want to write 3 or 4 lines to say that
> Germans are not like Helga is. Now it became a small
> essay already. I think I should stop now before it
> becomes a book.

Hello Jens and all,

Thank you for your reasurring e-mail.
I think our discussion is important in two ways.

1. it further stresses the value of the NPOV paradigm
2. Wikipedia is many things but with our little help it can, after a time,
rectify histories of our nations. I do hope that it will lead to better
understanding and peaceful coexistence.

Regards,
kpj.


subject: [Wikipedia-l] Edit Wars

body:
On Monday 05 August 2002 09:54, Poor, Edmund W wrote:
> Locking a page is only a temporary solution to an edit war. It stops the
> current battle, of course, but a better long-term solution is to teach
> contributors how to write from the NPOV. I'm not saying that this is an
> EASY solution, obviously. I myself have struggled mightily to learn how to
> write neutrally, and I still fail occasionally on subjects dear to me (such
> as Global Warming, which Axel has reverted in flames a few times :-).
>
> I've stepped in from time to time, as in the Eisenhower controversy, trying
> to show how information that veers away from the consensus can be included:
> usually by summarizing, creating a new article, or demoting content to an
> external link.
>
> What do others think about the prospects for educating contributors to the
> controversial pages, on how to write from the?

I think it's a good job for a wikipediatrician.

phma


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
tarquin wrote:
> I can't determine accurately how to say "CHOP-ek.".
> Did the writer mean "CHOP" like the word "chop"?

Probably. That's certainly my interpretation.

> Or does it rhyme with
> "SHOW"?

That would be CHO-pek or perhaps CHOPE-ek.

 > Or did they in fact *mean* "SHOW", since "CH" is soft in many
> languages?

But not in English.

> And for that matter, how does the writer pronounce the word "chop"?
> AmEng and BrEng have different vowels for that word.

I would expect that same difference to be reflected in their
*anglicized* pronunciation of "?apek". Am I wrong?

> "Hand-made" pronunciation guides are:
> * individual & idiosyncratic. Two people with the same accent may write
> different things, and may read them differently
> * non-portable: people speakling different accents will interpret them
> differently

Both true. The same is true of the pronunciations! IPA/SAMPA is even
more closely tied to the accent of the transcriber; it is thus useful
for describing the pronunciation of foreign words in the official or
prestige dialect, or specific dialectical variation, but a lot less
useful for describing English words and common anglicized pronunciations
of foreign names.

Jaap van Ganswijk wrote:
 > Unlike what is possible in a paper encyclopedium,
 > why not add a small wav file of someone
 > pronouncing the word correctly?

See [[Clitoris]] for an example: it has a link to [[SAMPA|pronounced]],
a SAMPA representation (correctly in [phonetic transcription brackets]),
an approximation in English orthography, and a wav file (should it be an
ogg?).

-- brion vibber (brion @ pobox.com)


from_name: Imran Ghory

subject: [Wikipedia-l] GNU FDL pictures?

body:
On 3 Aug 2002, at 21:21, Brion VIBBER wrote:

> koyaanisqatsi at nupedia.com wrote:
> > If I upload a picture and do not specify that I'm releasing it into
> > the public domain (and so release it implicitly under the GNU FDL
> > instead), can that picture be used only in works that are also GNU
> > FDL?  Or could it be reused in traditional, copyrighted works such
> > as newspapers?
> >
> > What does the GNU FDL say about this, if anything?  What constitutes
> > the article?  The text?  The image?  The layout?  All of the above?
> > Some of the above?
>
> This could theoretically fall under section 7:
>
> (snippet from http://www.gnu.org/copyleft/fdl.html)
> ----------------------------------------------------------------------
> --- 7. AGGREGATION WITH INDEPENDENT WORKS
>
> A compilation of the Document or its derivatives with other separate
> and independent documents or works

I don't think it applies as a newspaper article which includes a
relavent photo is clearly not a "separate and independent
documents or works".

Imran

--
TheOpenCD Project
Promoting Open Source on Windows
http://www.theopencd.org


list: wikitech-l

from_name: Jimmy Wales

subject: [Wikitech-l] Why there is no rsync yet ?

body:
Tomasz Wegrzanowski wrote:
> It should be easy to add, but it still hasn't been added.
> If it's just because Jimbo is too busy, could he give some other
> person access to Wikipedia server so that rsync can be set up ?

I'll get right on this.

>
> The fact that tarball is generated only once per day is serious
> problem for topological analysis that must be done in Polish
> Wikipedia to make optimal start page.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


subject: [Wikipedia-l] Link Syntax

body:
I agree with using curly braces to hide part a link:

+ put on the [[{One }Ring]]
= put on the [[One Ring|Ring]]
Shown as: put on the _Ring_

We could also use a second pipe character to delineate what we DO WANT TO SHOW, as follows:

+ bought an [[|English| language]] textbook
= bought an [[English language|English]] textbook
Shown as: bought an _English_ textbook

+ put on the [[One |Ring|]]
= put on the [[One Ring|Ring]]
Shown as: put on the _Ring_

+ called [[George |W|. Bush]]
= called [[George W. Bush|W]] during the campaign
Shows as: called _W_ during the campaign

What do you all think?

Ed Poor


subject: [Wikipedia-l] Language.php as a database

body:
>> Instead of including a file like [Language.php], you should
>> use some sort of database for the translation process...
>>
>> Suppose you want the user to press a button in a popup
>> window, addressing him in his own language, you would
>> write something like: "alert(x('Press the button'));"
>>
>>T he x-function would first check if the desired language
>> is English and if so, it would just return it's argument.
>> Otherwise it would consult the database and with the
>> help of the language that the user prefers it will
>> either come up with a translation or not and if not
>> will present the original English text. It will then
>> also put an a new entry in the database telling
>> people that this term needs to be translated to this
>> particular language. It could also put the term in
>> a general database with new terms that need to be
>> translated to all languages.

A few problems with the idea: first, there is not a one-to-one
correspondence bewteen English phrases and their translations.
There may be two or three places in the code that use the same
English text, but which would be different in a foreign language.
But that doesn't argue against a database, just that the database
needs to be indexed by the /use case/, not by the phrase itself.

>> Another point that concerns me is the size of the
>> current file. I guess that this file of around
>> 16 Kbyte is probably loaded and interpreted for
>> every page that is loaded from Wikipedia and may
>> perhaps account for how slow Wikipedia is at times?

No, no, it's precompiled and cached.  Converting to a
database for live access would be much slower, requiring
several API calls per page instead of what are now simple
memory lookups.

>>Other advantages of my system are, that the task
>>of the PHP programmers would become much easier,

I'm all for that of course; and maybe a database system could
be setup that generates a LanguageXx.php file as output, and
which could be added to by non-programmers.

>>Perhaps the translation tables could also be
>>used for other purposes or could be imported
>>from or be shared with other applications.

Again, translating isn't that simple.  Just because English
phrase "X" translates to French "Y" in one context doesn't mean
it will translate to the same phrase in another context.  Each
translation really needs a human to judge the result /as used/
in the software.

> That's a little more like what the old Usemod wiki code does
> (though with a separate include file with a big hash array
> rather than a database per se, and a function that checked the
> string against the hash, falling back on the given English string
> if there was no translation); I do find moving the English strings
> to a separate file confusing when working with the code,
> particularly as Lee isn't heavy on the comment usage.

That's exactly what the code is doing now; it looks up the string
in the hash table, and if it doesn't find it it falls back to
English.  Yes, I am a bit stingy in the comments--I'm of the
school that says if your code /needs/ comments it isn't very good
code, but I suppose a note here or there wouldn't hurt.

> We have a module installed (Alternative PHP Cache) that does this,
> or at least we did on the previous server. I _think_ it's still in
> place, but I could be wrong.

Yes, APC is running.  All the scripts are pre-compiled and cached
in shared memory.

> Group consensus; we can beat Lee into submission if need be, but
> I suspect he'd be amenable. I'm not sure if he reads this list
> regularly; try cross-posting to the tech list
> (wikitechl at nupedia.com) to make sure, and/or submit the idea to
> the feature request tracker:

I don't read intwiki regularly.  The thing that convinces me most
is code.  If you want the code to do something a certain way, you
either have to (a) convince me to do the work, or (b) do the work
yourself, and convince me to test and install it.  Guess which one
I prefer...


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Jaap van Ganswijk wrote:

>At 2002-08-05 17:03 +0100, tarquin wrote:
>
>>Paper encyclopedias expect their readers to learn the order of the letters of the alphabet. Learning SAMPA is relatively simple. While the table on [[SAMPA]] is increasingly complex, there is a shorter version on a sub-page which a link like [[pronounced]] should direct readers to.
>>It's a small effort to learn, for a large gain afterwards.
>>
>
>Unlike what is possible in a paper encyclopedium,
>why not add a small wav file of someone
>pronouncing the word correctly?
>
This is a much better idea than most attempts at divining pronunciation
into a strange set of symbols including highly accepted sets such as
IPA.  The .wav file would, of course, be by a native speaker of the
language.  It could also be a vehicle for understanding the precise
manner in which Americans don't speak English.

There would still be room for making written explanations about words
that are not pronounced in an intuitive manner, such as "mnemosyne" and
"more" when used to refer to a custom.

Eclecticology


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Ortolan88 wrote:
>This list seems to have a bias in favor of leaping into snake pits:
>tables, math formulas, SAMPA.  Next, musical notation?

May I suggest !!+_!1$8/2# for quarter notes, and, oh, !!+_!1$8/2#/2 for eighth notes?  You like it too?

Now for the crescendos and accidentals....

kq


from_name: Tom Parmenter

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
I contributed to the article [[Karel Capek]], including the sentence:

"For English speakers, the name is pronounced something like CHOP-ek."

Someone added:

"(or in SAMPA: ['tSApek])."

I appreciate the SAMPA addition, but I'll bet that for every English
speaker who can process ['tSApek] there are 100 (conservative
estimate, off by a factor of 10) who can process CHOPek and produce a
facsimile of his name for another English speaker.

Likewise SHO-pan, chai-KOV-sky, BAY-to-ven, TO-mas MONN, GER-teh, LOKH
LO-mond.

Capek's name doesn't get his little Czech checkmark anyway.  And
without a "schwa" we couldn't give the pronuciation even of most
English words, much less foreign words.

So even with SAMPA or some other scientific system, I believe we
should retain the option, or even requirement, to render
pronunciations, as needed, in non-standard, non-scientific,
not-truly-phonetic, phonetic English spellings.

This list seems to have a bias in favor of leaping into snake pits:
tables, math formulas, SAMPA.  Next, musical notation?

Tom Parmenter
Ortolan88

|From: Toby Bartels <toby+wikipedia-l at math.ucr.edu>
|Date: Sun, 4 Aug 2002 23:29:35 -0700
|
|Tarquin wrote:
|
|>I suggest we formulate a policy on using SAMPA for pronunciation of words
|>In the long run, IPA might be nicer, since paper dictionaries &
|>encyclopedias use it. However, until there's good support for Unicode,
|>sampa is readable on any browser. If at some point we can switch, the
|>two are in direct correspondance.
|
|I think that Evan Kirschenbaum's system is better for our purposes.
|
|http://www.kirshenbaum.net/IPA/faq.html
|
|More of the common European phonemes are easy to read here,
|at a loss of the ability for precise phonetic transcription.
|But then the possibility of precise transcription is returned
|at the cost of using incomprehensible codes like <unx> ("unexploded").
|Since we'll be wanting phonemes almost exclusively, this is good.
|
|The downside is that we *don't* have a one to one correspondence with IPA,
|but it's still possible to do machine translations later if desired,
|with some ambiguity about which letters to use for phonemes.
|(There's no ambiguity in the *meaning* of the symbols, however;
|this is just the usual ambiguity in phonemic symbols,
|deciding between /k/ and /x/ for a phoneme with both allophones.)
|
|
|-- Toby Bartels
|   <toby+wikipedia-l at math.ucr.edu>
|[Wikipedia-l]
|To manage your subscription to this list, please go here:
|http://www.nupedia.com/mailman/listinfo/wikipedia-l
|


subject: [Wikipedia-l] Edit Wars

body:
|
|But I continue to think a good [[controverial issue]] page would be
| helpful.
|

I wasn't a debater, and I haven't seen one of these things in awhile,
but intramural debate topics are set in advance and teams are expected to
be able to debate either side of an issue.  Each topic comes with a
sort of handbook on the topic, stating the main question, rebuttals,
responses to rebuttals, all in a fairly standard format.

How about a similar setup for these tough issues with strong feelings,
like so:

     Y, the article, describing the general situation while
     maintaining NPOV

	 Sidebar: The debate about Y
		  A-side
		  B-side

That way, the A's could state their case and in true wikipedia fashion
the B's could dive in on the A-side page and Talk:A-side and debate
what the A's *really* stand for, and the same thing could happen on
the B-side, with various points and rebuttals appropriately
distributed.  As a point became clearer and clearer (or time worked
its magic) the point could be promoted to the NPOV main article.

Just saying "This is a controversial issue" is kind of a cop out, but
some topics may never cool off, but the debate could be fairly
presented in a reasonable context.

Tom Parmenter
Ortolan-88

PS - Whether Helga is a malign force or deluded patsy (I'd opt for
someone who drank too deeply at the geneaology well), she doesn't have
a clue as to what makes an encyclopedia article.  Imagine an
articulate, clever Helga.


from_name: wiki pedista

subject: [Wikipedia-l] when will the language.php file ready to translate?

body:
Somebody (who)said in intlwiki-l that he would asks
for
translations to the language file once he had done one
or two more tweaks.
Will it be much longer?

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] policy suggestion: SAMPA

in_reply_to:
<3D4EA1C7.6020708@planetunreal.com> (message from tarquin on Mon,
	05 Aug 2002 17:03:19 +0100)

body:
|From: tarquin <tarquin at planetunreal.com>
|Date: Mon, 05 Aug 2002 17:03:19 +0100
|
|I can't determine accurately how to say "CHOP-ek.".
|Did the writer mean "CHOP" like the word "chop"? Or does it rhyme with
|"SHOW"? Or did they in fact *mean* "SHOW", since "CH" is soft in many
|languages?

Actually, it's pronounced "Throatwarbler-Mangrove".

I wrote: "For English speakers, the name is pronounced something like
CHOP-ek."  That seems modest and accurate (I discussed Capek with a
Czech at some length once and he knew who I was talking about.)

|And for that matter, how does the writer pronounce the word "chop"?
|AmEng and BrEng have different vowels for that word.

I surrender (and actually anticipated and made this argument more
concisely in my original note), but this strikes me as disingenuous.
The intimidating SAMPA table gives examples like { "as in London
English cat".  Would that be Cockney or BBC?  I don't speak
either. The best system for me would be to render it in Spanish,
Norwegian, or German, phonetic languages that I know how to
pronounce. (smiley)

[rest snipped]

|
|Tom Parmenter wrote:
|
|>This list seems to have a bias in favor of leaping into snake pits:
|>tables, math formulas, SAMPA.  Next, musical notation?
|>
|I don't think this is the same over-complexity as tables and maths
|formulae (may) prove to be. It's a common sense standardization, using
|an internationally-accepted system.
|

I first heard of it day before yesterday.  As Donald Knuth says, "The
great thing about standards is that there are so many of them."

Any kind of markup drives away writers, so the less the better.  I
grant you that SAMPA is a lesser case, but the big SAMPA page is
too complex and scary and the little SAMPA page doesn't cover enough.

In the end, I'm agreeable to all you say, but reluctantly so.  I think
I'll leave CHOP-ek in.

Tom P.


subject: [Wikipedia-l] Main Page.

body:
Yow.  I have no idea how that happened. I'll check the logs and
recover it from a dump (I did one this weekend).


subject: [Wikipedia-l] Main Page.

body:
Hr. Daniel Mikkelsen wrote:
> On Mon, 5 Aug 2002 lcrocker at nupedia.com wrote:
>>Looks like I'm the one who deleted it.
>
> :) Thank god! I was worried it was a database problem, Wikipedia coming apart
> at the seams.

The system is perfect. The problem can only be due to human error. ;)

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Main Page.

body:
Looks like I'm the one who deleted it.  I'll get it back as
fast as I can, and then I'll try to figure out how the hell I
did that.  I think it was trying to delete an image with an
empty name.


subject: [Wikipedia-l] Main Page.

body:
The deletion log says you did it--?  Or was that after it was discovered empty?  (that's what the comment attributed to you says).

Some time on Aug 3, it had 391776 pageviews (according to the google cache).  Right now it's reporting something like 24.

kq

You Wrote:
>Yow.  I have no idea how that happened. I'll check the logs and
>recover it from a dump (I did one this weekend).


from_name: Julie Hofmann Kemp

subject: [Wikipedia-l] Curly brackets and teaching the unteachable

body:
My vote is to leave pipelining as it is -- many newbies (and old hands)
have enough trouble figuring it out without adding more layers.

Re teaching the unteachable -- We'd all love to, but there are some
users, Fr. Jonat being one, who don't want to learn.  They want to say
what they want to say, and facts as the rest of us know them don't come
into it.  I personally think Helga's a special case -- She really does
care about making this a good site; she really believes her articles are
legitimate; she really believes that there is a conspiracy to hide the
truth; and her own personal losses color all of her political insights
and contributions.  It doesn't help that she's also willfully pig
ignorant of how to critically read any historical source, primary or
secondary, IM very fed up with her O; however, she isn't a vandal in the
true sense of the word, and usually is only borderline troll-like.  I
certainly can't in good conscience support banning her, but neither do I
believe she will ever change -- there is no rule against crap
contributions -- just tons of irritation.  The only sure thing is that
she will eventually ride her hobby horse elsewhere after accusing us of
twisting the TRUTH, and a couple of months from now, quietly return to
make changes until someone notices.

Another such person was ark, who seems to have taken his deMause-ian
theories and gone to play elsewhere.

On the bright side, I've found that almost all newbies respond favorably
to hints and direction to NPOV policy, how to make articles better,
etc., so I don't think it's an issue.   Lets keep in mind that, by and
large, the people here actually do want to cooperate and produce good
work -- it's just that lots of that happens without being noticed!!

Done pontificating now...

Jules


subject: [Wikipedia-l] Deletion of Main Page.

body:
Naturally, a few days after I argued that our deletion policy should
be less rigorous... :-)

Here's what seems to have happened: someone, somehow, managed to
upload an image that appeared in the logs with a blank name.  There's
a part of the script that fills in the title "Main Page" if no title
is given for some commands (that's so that, for example, "wiki.phtml"
gets you the main page if you don't specify a title).  Apparently,
that caused the system to think I wanted to delete the main page.

This is probably a bad idea.

I've locked the database and disabled the delete function for now.
When I finish restoring the main page from the tarball I made
yesterday, I'll unlock the database, but I'll leave delete disabled
until I can make it safer.


subject: [Wikipedia-l] Deletion of Main Page.

body:
lcrocker at nupedia.com wrote:
> I've locked the database and disabled the delete function for now.
> When I finish restoring the main page from the tarball I made
> yesterday, I'll unlock the database, but I'll leave delete disabled
> until I can make it safer.

On that note, note my feature request:
[ 591322 ] DB lock should have notice field
http://sourceforge.net/tracker/index.php?func=detail&aid=591322&group_id=34373&atid=411195

-- brion vibber (brion @ pobox.com)


body:
Yes, and it's always uplifting to see it when the occasional article develops from a stub into something comprehensive and well-written within a day or two.  That's almost always the result of cooperation between several people at once.

kq

JHK wrote:
>On the bright side, I've found that almost all newbies respond favorably
>to hints and direction to NPOV policy, how to make articles better,
>etc., so I don't think it's an issue.   Lets keep in mind that, by and
>large, the people here actually do want to cooperate and produce good
>work -- it's just that lots of that happens without being noticed!!


from_name: tarquin

subject: [Wikipedia-l] Link Syntax

body:
ave the pipe character for cases where the link name & display name are
completely different.
how about reversing: }{
so it's always anything that's on the "belly" side of a  { or } thats hidden

+ put on the [[One }Ring{]]
= put on the [[One Ring|Ring]]
Shown as: put on the _Ring_

+ called [[George }W{. Bush]]
= called [[George W. Bush|W]] during the campaign
Shows as: called _W_ during the campaign

Poor, Edmund W wrote:

>I agree with using curly braces to hide part a link:
>
>+ put on the [[{One }Ring]]
>= put on the [[One Ring|Ring]]
>Shown as: put on the _Ring_
>
>We could also use a second pipe character to delineate what we DO WANT TO SHOW, as follows:
>
>+ bought an [[|English| language]] textbook
>= bought an [[English language|English]] textbook
>Shown as: bought an _English_ textbook
>
>+ put on the [[One |Ring|]]
>= put on the [[One Ring|Ring]]
>Shown as: put on the _Ring_
>
>+ called [[George |W|. Bush]]
>= called [[George W. Bush|W]] during the campaign
>Shows as: called _W_ during the campaign
>
>What do you all think?
>
>Ed Poor
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>
>


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Special pages menu

body:
"Show "s and "List "s should be removed.
They are only distracting.


body:
Lars says:
Perhaps you mean Wend? The Vandals were a Germanic tribe that settled in
northern Africa, not northern Poland. The Wends lived in northern
Poland, but they were Slavs, not Germanic.
http://www.wikipedia.com/wiki/Wends
http://wwww.wikipedia.com/wiki/Vandal Or perhaps you just didn't mean
the "true" sense of the word.
Jules says:
AARGH!!  I meant in the true wiki sense of the word,
oh-even-more-pedantic-than-I one!  Besides, I think we all know now that
she is Old Prussian, descended straight from the legendary Widewuto..

:-))

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020805/08223773/attachment.htm


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
|X-Authentication-Warning: bryant.aronsson.se: lars owned process doing -bs
|From: Lars Aronsson <lars at aronsson.se>
|Content-Type: TEXT/PLAIN; charset=US-ASCII
|Sender: wikipedia-l-admin at nupedia.com
|X-BeenThere: wikipedia-l at nupedia.com
|X-Mailman-Version: 2.0.4
|Precedence: bulk
|Reply-To: wikipedia-l at nupedia.com
|List-Help: <mailto:wikipedia-l-request at nupedia.com?subject=help>
|List-Post: <mailto:wikipedia-l at nupedia.com>
|List-Subscribe: <http://www.nupedia.com/mailman/listinfo/wikipedia-l>,
|	<mailto:wikipedia-l-request at nupedia.com?subject=subscribe>
|List-Id: An unmoderated discussion of all things Wikipedia <wikipedia-l.nupedia.com>
|List-Unsubscribe: <http://www.nupedia.com/mailman/listinfo/wikipedia-l>,
|	<mailto:wikipedia-l-request at nupedia.com?subject=unsubscribe>
|List-Archive: <http://www.nupedia.com/pipermail/wikipedia-l/>
|Date: Mon, 5 Aug 2002 18:04:57 +0200 (CEST)
|
|Tom Parmenter wrote:
|> I contributed to the article [[Karel Capek]], including the sentence:
|> "For English speakers, the name is pronounced something like CHOP-ek."
|> Someone added:
|> "(or in SAMPA: ['tSApek])."
|
|Isn't the solution here to submit an MP3 file where you speak the
|name?  Isn't that what Microsoft Encarta would do?  Does your computer
|have a microphone?
|
|
|--
|  Lars Aronsson (lars at aronsson.se)
|  tel +46-70-7891609
|  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/
|
|[Wikipedia-l]
|To manage your subscription to this list, please go here:
|http://www.nupedia.com/mailman/listinfo/wikipedia-l
|

Instead of my naive transliteration/translation/rendering, we would
have my naive spoken rendering, lingering Valdosta, Georgia, accent
and all.


subject: [Wikipedia-l] policy suggestion: SAMPA

body:
I can't determine accurately how to say "CHOP-ek.".
Did the writer mean "CHOP" like the word "chop"? Or does it rhyme with
"SHOW"? Or did they in fact *mean* "SHOW", since "CH" is soft in many
languages?
And for that matter, how does the writer pronounce the word "chop"?
AmEng and BrEng have different vowels for that word.

The IPA (or a variant like SAMPA) is:
* portable. My Collins, Fowler's Modern English Usage, my French
Larousse -- they all use the IPA.
* international: the Esperanto, the German, the Spanish Wikipedias can
ALL use the same SAMPA transcription for the same article

"Hand-made" pronunciation guides are:
* individual & idiosyncratic. Two people with the same accent may write
different things, and may read them differently
* non-portable: people speakling different accents will interpret them
differently

Paper encyclopedias expect their readers to learn the order of the
letters of the alphabet. Learning SAMPA is relatively simple. While the
table on [[SAMPA]] is increasingly complex, there is a shorter version
on a sub-page which a link like [[pronounced]] should direct readers to.
It's a small effort to learn, for a large gain afterwards.

Tom Parmenter wrote:

>This list seems to have a bias in favor of leaping into snake pits:
>tables, math formulas, SAMPA.  Next, musical notation?
>
I don't think this is the same over-complexity as tables and maths
formulae (may) prove to be. It's a common sense standardization, using
an internationally-accepted system.


from_name: Jaap van Ganswijk

subject: [Wikipedia-l] Link Syntax

body:
At 2002-08-05 10:40 -0400, Poor, Edmund W wrote:
>I agree with using curly braces to hide part a link:
>
>+ put on the [[{One }Ring]]
>= put on the [[One Ring|Ring]]
>Shown as: put on the _Ring_
>
>We could also use a second pipe character to delineate what we DO WANT TO SHOW, as follows:
>
>+ bought an [[|English| language]] textbook
>= bought an [[English language|English]] textbook
>Shown as: bought an _English_ textbook
>
>+ put on the [[One |Ring|]]
>= put on the [[One Ring|Ring]]
>Shown as: put on the _Ring_
>
>+ called [[George |W|. Bush]]
>= called [[George W. Bush|W]] during the campaign
>Shows as: called _W_ during the campaign
>
>What do you all think?

I wouldn't introduce yet another form of bracket
besides (), [], {} and <>. Just figure out which
of these you can use. Also consider using one of
the quotes: '' "" ``.

I would refrain from using characters in the ASCII
set that may have different meanings in non-English
languages. As far as I know all the characters
32..95 are the same in all the sets.

Greetings,
Jaap


subject: [Wikipedia-l] Link Syntax

body:
At 2002-08-05 15:50 +0100, tarquin wrote:
>ave the pipe character for cases where the link name & display name are completely different.
>how about reversing: }{
>so it's always anything that's on the "belly" side of a  { or } thats hidden
>
>+ put on the [[One }Ring{]]
>= put on the [[One Ring|Ring]]
>Shown as: put on the _Ring_
>
>+ called [[George }W{. Bush]]
>= called [[George W. Bush|W]] during the campaign
>Shows as: called _W_ during the campaign

I wouldn't use brackets in this reversed way,
because it's very counter-intuitieve. Please
also consider that the expressions between
[[]]'s may become even more complicated over time.

Greetings,
Jaap


body:
Julie Hofmann Kemp wrote:

>Re teaching the unteachable -- We'd all love to, but there are some
>users, Fr. Jonat being one, who don't want to learn.  They want to say
>what they want to say, and facts as the rest of us know them don't come
>into it.  I personally think Helga's a special case -- She really does
>care about making this a good site; she really believes her articles are
>legitimate; she really believes that there is a conspiracy to hide the
>truth; and her own personal losses color all of her political insights
>and contributions.  It doesn't help that she's also willfully pig
>ignorant of how to critically read any historical source, primary or
>secondary, IM very fed up with her O; however, she isn't a vandal in the
>true sense of the word, and usually is only borderline troll-like.  I
>certainly can't in good conscience support banning her, but neither do I
>believe she will ever change -- there is no rule against crap
>contributions -- just tons of irritation.  The only sure thing is that
>she will eventually ride her hobby horse elsewhere after accusing us of
>twisting the TRUTH, and a couple of months from now, quietly return to
>make changes until someone notices.
>
>On the bright side, I've found that almost all newbies respond favorably
>to hints and direction to NPOV policy, how to make articles better,
>etc., so I don't think it's an issue.   Lets keep in mind that, by and
>large, the people here actually do want to cooperate and produce good
>work -- it's just that lots of that happens without being noticed!!
>
>Jules
>
I must commend the sensitivity that you show toward another
contributor's "pig ignorance" in the face of what is clearly a
frustrating experience.  You seem to recognize that misguided ideas
often come as sincerely from the heart.  Your students are indeed
fortunate if their essays and term papers receive the level of analysis
that you provided for HJ's Copernicus article.. Too many of our
colleagues are over-hasty with heavy-handed tactics.

Eclecticology


from_name: Lars Aronsson

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Tom Parmenter wrote:
> I contributed to the article [[Karel Capek]], including the sentence:
> "For English speakers, the name is pronounced something like CHOP-ek."
> Someone added:
> "(or in SAMPA: ['tSApek])."

Isn't the solution here to submit an MP3 file where you speak the
name?  Isn't that what Microsoft Encarta would do?  Does your computer
have a microphone?

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


subject: [Wikipedia-l] Edit Wars

body:
Ed Poor wrote:

>Locking a page is only a temporary solution to an edit war. It stops the
>current battle, of course, but a better long-term solution is to teach
>contributors how to write from the NPOV.

I agree.  I am ***VERY*** uncomfortable with locking articles.
My impression (only an impression) is that Helga cannot be taught,
but I would ban her IP long before I locked an article.
(And I'm not suggesting banner her; this is simply a comparison.)
Even if we're just going to lock articles for cooling down periods,
then this needs to be discussed and documented before it happens.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


body:
Hi Lee,

And the others.

At 2002-07-31 18:53 -0700, lcrocker at nupedia.com wrote:
>I'm not quite ready to solicit translations yet (there is still a
>feature or two I want to add first), but those of you who think you
>may be taking on the translation task might want to browse the new
>code base (see http://wikipedia.sourceforge.net ) and compare the
>files "Language.php" and "LanguageDe.php" to see what needs to be
>done and estimate the work (Magnus did it a couple of days).

I started a discussion about this language.php principle some
days ago on the Intlwiki-L suggesting that this problem could
perhaps better be solved using a translation database of some
sort.

When I asked how to properly propose this to the
programmers who matter, Brion VIBBER <brion at pobox.com>
was so friendly to point out that I dad to contact a
certain Lee or to propose it on this list. Well I guess
that you're that Lee, (alhough your proper name misses
from your message ;-).

The original thread was called:
'[Intlwiki-l] Wiki community in Hebrew'.

But here is the discussion in full (edited for
readibility):

I wrote:

--- start of my original message
>Looking at the code of language.php, I thought
>about my own ideas about localizing software in
>a more general way.
>
>Instead of including a file like this, you should
>use some sort of database for the translation process.
>Also instead of defining variables that hold strings,
>which are different for all the languages, you could
>just insert the English string into the source code
>and send it through a general translation process.
>
>Let me clarify this.
>
>Suppose you want the user to press a button in a popup
>window, addressing him in his own language, you would
>write something like: "alert(x('Press the button'));"
>
>The x-function would first check if the desired language
>is English and if so, it would just return it's argument.
>Otherwise it would consult the database and with the
>help of the language that the user prefers it will
>either come up with a translation or not and if not
>will present the original English text. It will then
>also put an a new entry in the database telling
>people that this term needs to be translated to this
>particular language. It could also put the term in
>a general database with new terms that need to be
>translated to all languages.
>
>People can translate the data in the database at
>their leisure doing as many terms as they like
>at a time, or only translate the terms that they
>are good at for example. They can also correct
>incorrect translations by others. It would work
>like the Wiki system itself.
>
>Another point that concerns me is the size of the
>current file. I guess that this file of around
>16 Kbyte is probably loaded and interpreted for
>every page that is loaded from Wikipedia and may
>perhaps account for how slow Wikipedia is at times?
>Assuming that say 50% of the users use English as
>their prefered language, the x() system would
>prevent the loading of this file or accessing
>the database for 50% of the files.
>
>Other advantages of my system are, that the task
>of the PHP programmers would become much easier,
>because they don't have to be bothered with having
>to keep adding to the include file and can work
>with the actual English strings instead of having
>to work with variable names.
>
>Perhaps the translation tables could also be
>used for other purposes or could be imported
>from or be shared with other applications.

--- end of my original message

The rest is organized by per resulting thread:

I wrote in my original message:
>Instead of including a file like this, you should
>use some sort of database for the translation process.
>Also instead of defining variables that hold strings,
>which are different for all the languages, you could
>just insert the English string into the source code
>and send it through a general translation process

Brion replied:

That's a little more like what the old Usemod wiki code does (though with a separate include file with a big hash array rather than a database per se, and a function that checked the string against the hash, falling back on the given English string if there was no translation); I do find moving the English strings to a separate file confusing when working with the code, particularly as Lee isn't heavy on the comment usage.

Upon which I replied back:
I was not (yet) talking about how to implement it,
but an associative array (called hash array by
some people ;-) is indeed one of the options.

One would have to make sure that the synchronisation
is handled properly and most PHP implementations
don't include the semaphore functions. Using an
MySQL database would have the advantage that it
synchronizes itself. But also that the database
could be used from other locations.

It also depends on what the average number of
strings is that the average page would want to
translate.

Anyway, I have no clear idea what the best
implementation would be. I also don't know how
the rest of Wikipedia is organized.

In my original message I wrote:
>People can translate the data in the database at
>their leisure doing as many terms as they like
>at a time, or only translate the terms that they
>are good at for example. They can also correct
>incorrect translations by others. It would work
>like the Wiki system itself.

Upon which Brion replied:
Not quite as radical as making the live source code editable by wiki. :) I think we probably should do something like this...

I wrote in my origimal message:
>Another point that concerns me is the size of the
>current file. I guess that this file of around
>16 Kbyte is probably loaded and interpreted for
>every page that is loaded from Wikipedia and may
>perhaps account for how slow Wikipedia is at times?
>Assuming that say 50% of the users use English as
>their prefered language, the x() system would
>prevent the loading of this file or accessing
>the database for 50% of the files.

Brion replied:
The PHP files are pre-compiled when first loaded; in theory, at least, they only need to be parsed the first time they're loaded after a software upgrade.

I replied back:
Aren't you confusing PHP with Python? Python precompiles
modules but PHP not, I think.

Brion replied again:
We have a module installed (Alternative PHP Cache) that does this, or at least we did on the previous server. I _think_ it's still in place, but I could be wrong.

Finally I asked:
Who has to decide on this? Lee? Is he around?
I haven't seen him post here since I was here
I think.

And Brion replied:
Group consensus; we can beat Lee into submission if need be, but I suspect he'd be amenable. I'm not sure if he reads this list regularly; try cross-posting to the tech list (wikitech-l at nupedia.com) to make sure, and/or submit the idea to the feature request tracker:

http://sourceforge.net/tracker/?atid=411195&group_id=34373&func=browse
(goody! more cryptic URLs)

--- end of quotes

I just thought that it would be quite easy to
generate the current language.php files from the
database regurarly (every night for example).
That would make the process guaranteed to be as
fast (or slow) as it is now. ;-)

Let me know what y'all think...

Greetings,
Jaap


subject: [Wikipedia-l] Link Syntax

body:
Tarquin wrote in part:

>+ called [[George }W{. Bush]]
>= called [[George W. Bush|W]] during the campaign
>Shows as: called _W_ during the campaign

O gods please no.
I would rather surround included material than excluded material,
but backwards brackets are just going to make newbies go nuts.

I'm beginning to think that we should just drop the idea.
It should only go forward if we find a system that's easy to read.
This isn't like tables and math that can't help but be complicated;
we should have a much lower tolerance in this situation.
(Of course, if others have better ideas, then I'll still listen.)

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: The Cunctator

subject: [Wikipedia-l] Deletion of Main Page.

body:
On 8/5/02 7:22 PM, "Brion VIBBER" <brion at pobox.com> wrote:

> lcrocker at nupedia.com wrote:
>> I've locked the database and disabled the delete function for now.
>> When I finish restoring the main page from the tarball I made
>> yesterday, I'll unlock the database, but I'll leave delete disabled
>> until I can make it safer.
>
It should also not be possible to delete locked pages. The page should be
unlocked before deletion--that would be a good safety measure.

Also, deletion should be "soft" in most cases.

Funny bug, there.


from_name: Toby Bartels

subject: [Wikipedia-l] policy suggestion: SAMPA

body:
Brion Vibber wrote:

>Tarquin wrote:

>>And for that matter, how does the writer pronounce the word "chop"?
>>AmEng and BrEng have different vowels for that word.

>I would expect that same difference to be reflected in their
>*anglicized* pronunciation of "????apek". Am I wrong?

IANAB (I am not a Brit), but I think that you are wrong.
But this doesn't invalidate your ultimate point;
it just means that the guide should say "CHAHP-ek" instead.

My vote is for listing English "phonetic" crap
(with an eye to including both Midwestern American
and BBC accents, which means in part NO SHORT "o"S),
SAMPA (or better yet, Kirschenbaum's system as mentioned earlier),
IPA in numbered HTML character entities that reference UNICODE,
and recording in OGG (or whatever).  If this is too long,
then I'd drop SAMPA first (ironically enough).

>See [[Clitoris]] for an example: it has a link to [[SAMPA|pronounced]],
>a SAMPA representation (correctly in [phonetic transcription brackets]),
>an approximation in English orthography, and a wav file (should it be an
>ogg?).

How are the phonetic brackets correct?  *I* don't pronounce it that way!
But change it to phonemic slashes, and suddenly I do.
Unless we're describing distinct dialects, brackets will always be wrong.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Parsing TeX

body:
Jan Hidder wrote:

>Toby Bartels wrote:

>>LaTeX is hardly more easy for a technophobe to learn than HTML,
>>and we don't want them to think that they can't edit a math expression
>>without learning LaTeX.

>Since all math will probably then be rewrittin in TeX anyway, that will be the
>situation anyhow.

That's exactly the situation that I want to avoid!
Why *shouldn't* it be easy to edit a math expression without knowing LaTeX?
That's the case now; you only need to know '' or <var>
(depending on whether I've edited the page significanlty or not,
and even this will become easier if we encode <var> as $$ or such).
I'm all for a system that makes complicated math easier to edit
(and easier to get right in the first place),
but not at the expense of the simple math that is the majority.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Edit Wars

body:
Yes, it's not very wiki, and since we agree it's not vandalism (only deeply misguided and ill-informed political evangelism) then there's no reason to ban her either.  Though she is frustrating.

kq

>I agree.  I am ***VERY*** uncomfortable with locking articles.
>My impression (only an impression) is that Helga cannot be taught,
>but I would ban her IP long before I locked an article.
>(And I'm not suggesting banner her; this is simply a comparison.)
>Even if we're just going to lock articles for cooling down periods,
>then this needs to be discussed and documented before it happens.
>
>
>-- Toby Bartels