Jump to content

Wikipedia talk:Software updates

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Tillwe (talk | contribs) at 00:31, 3 August 2003. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This is talk about Wikipedia software updates, roughly sorted by login problems, toc, new edit feature and assorted other issues.

The Login

Login broken?

Did someone change the login code? I can't seem to login. When I try I get spit back to this page [1]

Is there something wrong with my account? Mbecker

Also, I wasn't able to edit this page until I canhed the url from http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Village_pump&action=edit to http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Village_pump&action=submit. There was an error preventing me from submitting before I did that.
Mbecker
Nevermind, everything seems to work fine now. MB 21:34 28 Jul 2003 (UTC)

Everything was seriously whacked for about half an hour. Think (from IRC) that Eloquence has fixed it up now. Evercat 21:38 28 Jul 2003 (UTC)

Login's still broken for me. I get invalid password. I even had it mail me a new password, and the new password mailed to me doesn't work either. --Delirium 00:28, 29 Jul 2003 (UTC) (aka Delirium)

Someone changed the MD5 code. I changed it back, it should work now.—Eloquence 00:31, 29 Jul 2003 (UTC)
I can log in now, though oddly it's my old password that works, not the random one that was just mailed to me. Is the reset-your-password code broken? --Delirium 00:34, 29 Jul 2003 (UTC)
Nope, the old password must always continue to work so random users cannot reset your password. The new password does not work because it was generated with the new code, and I just changed the code back.—Eloquence 00:42, 29 Jul 2003 (UTC)~

Login Problems

What is going on now? I've just been logged out and can't log in (it won't recognise my password). Another person a while ago on AIM said they couldn't save an article. I got You have new messages sent to me telling me about non-existent messages. (It was hours since the last message and at least half an hour before my next one!) Wiki is doing strange strange things! User:FearÉIREANN

Can you login now? The new message should be the one from Camembert.—Eloquence 00:42, 29 Jul 2003 (UTC)
Yup. Am back (yippee!) [trying desparately to avoid edit conflicts] and got the message from the "Arch-communist". FearÉIREANN 00:54, 29 Jul 2003 (UTC)
Try logging in a few times, then try the wrong password a few times, and then the right one again. (No idea if that would help, can't hurt, anyway.) I kept getting a wrong password message, don't know why, managed to log in... כסיף Cyp 00:42, 29 Jul 2003 (UTC) (Posted after a few edit conflicts.)
I for one can't log in, tried everything I thought of for the last 15 minutes. -- Gutza 217.156.116.130 00:45, 29 Jul 2003 (UTC)
In any case, it took a while for me to log in, don't know if it was just because of trying a lot, or if I actually did something... Worked, after typing my password in Notepad, and copy/pasting it into the password box. Can imagine how the server would know that I did that, though... כסיף Cyp 00:48, 29 Jul 2003 (UTC)
Oh well, that seems to have done it after all, I've logged in successfully using the twisted method above. Thanks! -- Gutza 00:49, 29 Jul 2003 (UTC)

Table of contents

Table of contents - how to create

I've clearly missed something: how do I create a table of contents? I've tried going through the FAQs, without success. Vicki Rosenzweig

They're auto-generated from the section headings. --Delirium 00:47, 29 Jul 2003 (UTC)
Judging from the prefs page, they only appear when an article has more than three headings. --Camembert
Unless you turn them off with __NOTOC__

New formating on the non-English wikis

Can we get the new formating on the non-English wikis? I wouldn't want anyone to accuse wikipedia of anglocentrism or cultural imperialism or anything. -- AdamRaizen 01:14, 2003 Jul 29 (UTC)

See the mailing list. Erik says "I will update the English wiki to that version ASAP, where it will run for a few days. If it works fine, the other wikis will be updated as well.". Angela 01:19, 29 Jul 2003 (UTC)

When will we be able to translate it? There doesn't seem to be a lot, but there's Table of Contents, edit, hide, and show, which all has to do with the new section behavior. -- AdamRaizen 22:27, 2003 Jul 30 (UTC)

Confusing TOC with Date

TOC # system is confusing, as in "27 July 25, 2003" (see Current events). --Menchi 03:36, 29 Jul 2003 (UTC)

That page shouldn't have a TOC. Disabled.—Eloquence 03:40, 29 Jul 2003 (UTC)

TOC Table Cell Heading Centering

How about removing the align="center" of the Table of Contents header cell? When the TOC is in show mode, the heading doesn't look centered--it looks like it had a bad case of mistaken indentation. All other headers ==like this== aren't centered, so why should this be? --seav 04:33, Jul 29, 2003 (UTC)

Not sure what exactly you mean with "doesn't look centered". It looks centered here. I added the "center" property exactly because of some ugliness regarding the show/hide display (although I don't recall the exact details). Could you give me a screenshot of what you mean?—Eloquence 04:48, 29 Jul 2003 (UTC)
Technically it is centered, but visually, it doesn't look centered. (It probably takes a graphic designer to understand.) People can tell if a piece of text is centered in some arbitrary box if you can "visualize" the left and right edges of the box--between which lines text is supposed to be centered. If these lines are not obvious (it doesn't mean they have to be visible), then the centered text looks out of place.
In the case of the TOC, you can easily "see" the left edge, but it's not immediately obvious that there's a right edge since the right edge of the TOC text is ragged--some section headings are short and some are long. In some TOCs, the centered text looks like it's just indented, with no apparent reason why. (Someone might think, "Why is there space to the left of the 'Table of Contents', hmmm... maybe somebody forgot to remove the spaces there.") It's not apparently obvious that in fact the text is centered to the TOC box. (I actually had to look at the source code because I wondered why the text was "indented.")
Admittedly, this is just a minor aesthetic quibble that does not in any major way affect usability or functionality. But the solution is also a simple one--remove the center property. (I'm curious exactly how centering the text removes the "ugliness regarding the show/hide display.") --seav 08:24, Jul 29, 2003 (UTC)

TOC default conditions

The TOC makes articles look awkward. Now there is a large white space in the middle of the page for the TOC. This looks especially bad with the country template, where there is now a large space between the TOC on the left and the country table to the right. To remedy this, I suggest that the TOC be set as minimized by default. I don't think people are interested in the TOC if they can just scroll (for shorter articles). It takes up too much space! So if they do happen to be interested, they can just maximize it. I don't think keeping the TOC minimized will prevent people from using it if they desire to, while there is much to gain aesthetically.

--Jiang 06:21, 29 Jul 2003 (UTC)

I'll agree with that. -- Tim Starling 07:57, Jul 29, 2003 (UTC)
The TOC is only generated for articles with more than three headings. With a reasonable length of text per section, such articles are likely to benefit from the additional navigational structure. I do not see whitespace as a problem -- if you choose very short headlines, then you'll have to live with the consequences. After all, the section headings, e.g. "History", "Demographics", also have a lot of whitespace to the right of them because they are so short. Changing the default condition to hidden is problematic because it defeats the whole purpose of the POV -- an immediately clickable, visible list of the topics discussed in an article. It is also not really viable because the show/hide function is a JavaScript -- it won't even be visible in some browsers.
If an article is very short and it still has a TOC because it is based on a template, and you don't want the TOC to be generated, you can turn it off by adding "__NOTOC__", although I would prefer it if you added text to the sections instead.—Eloquence 07:48, 29 Jul 2003 (UTC)

Why not make a minimum entire article text length before the TOC shows up? When there is not substantial text, I guess people will prefer to scroll instead of looking at the TOC. But once substantial text is added, the TOC should automaticially appear (as opposed to manually adding and removing). I would like to avoid removing the TOC from short articles and putting them back in after the articles are lengthened. It should be automatic.

I find the TOC highly annoying and something I would only use if I were doing personal research on a very long article (and had to browse due to time constraints). Otherwise, I would either be reading the entire article as a first timer, or just exclusively checking the edits of another user. Can there be a user preference function to turn off all TOCs?

The country/state/organism, etc templates were all designed w/o the new TOC in mind. With the TOC, it just doesn't look right. (The white space is not that bad when there is no table to the side, but when there is, it's boxed in.)

I really don't see how it "defeats" the TOC's purpose. All the user has to do is execute a single click. You are assuming that most users would actually be using the TOC, which we cannot be certain of. It is better for those who elect to do so to take their own initiative to click the "show" button. And what worth is it accomodating those w/o javascript? At least a TOC exists for some people....

--Jiang 08:27, 29 Jul 2003 (UTC)

The minimum article length idea isn't bad. I'll see if I can hack that into the next version. In the meantime, if you find the TOC useless, I suggest you turn it off in your prefs.—Eloquence 11:08, 29 Jul 2003 (UTC)
I'd like to see the TOC in a sidebar - I think it would look really good there! But that's a question for skin designers, of course. :) Martin 09:09, 29 Jul 2003 (UTC)
I disagree... it would look really bad. Just imagine this page's TOC on the sidebar. Most TOCs are just too wide to fit in the sidebar, and that's not even counting the indentations of subsections. --seav 09:18, Jul 29, 2003 (UTC)
What I don't like about this new feature is the TOC below the first paragraphs of the article. It should be really on top, below the headline. Otherwise it's just chaotic, see Sociology for an example. Also there could be a preferences to generate a TOC if there are more than "n" headings and/or more than "m" KB text length. I'd like TOCs for really long pages like, say, "Village Pump", but not for every page with more than three headings. -- till we *) 10:20, Jul 29, 2003 (UTC)
Have a look at Lapis lazuli, the TOC is in a most peculiar position!
Adrian Pingstone 10:40, 29 Jul 2003 (UTC)
Well, strangely enough, the TOC was at the top by default until someone else suggested on Wikipedia-L that it should be put before the first section heading. That sounded like a good idea, because it encourages the writing of brief intro paragraphs and the proper use of sections. However, many articles are currently not written with that in mind. It's not hard to change them accordingly, so for now I'd say the behavior should stay as it is.—Eloquence 11:08, 29 Jul 2003 (UTC)
I very strongly agree with that. Each and every article needs to start with a proper introduction in the news style. The purpose of the intro is to broadly summarize the major points of the article - a kinda article in miniature (common in many encyclopedias). If such an intro sparks the interest of a person then they can look at the TOC and navigate to points they want to know more about. However, I disagree with you about having the TOC shown by default; the current implementation makes it very clear that a TOC exists when it is "hidden" and it is very intuitive on what to do to expand it (since it was designed so well). It is very useful, but at the same time it does create ugly lists and white space. For example, in World War I (a longish article) all you can see is the intro line and a TOC list - it is not immediately obvious that there is a lot of additional prose following the "list." --mav
But World War I is again an example for an article that has far too many headings. Furthermore, empirical usability studies show that users do not want to click in order to view navigational structures -- this is why many people disliked the "Special pages" dropdown. Navigational structures should either be there, or they should not be there, if you don't even know what the navigational structure shows, you have no incentive to view it. Lastly, hiding the TOC by default will only work for JavaScript enabled users, which is bad design because it treats different classes of users substantially differently.
I think what we are seeing now is the natural result of a feature being added that was never planned for. Many pages are currently not in a state to accommodate the TOC nicely -- they have too many or too few headings, too much nesting, too short section titles, too long section titles etc. These are really general structural problems that were simply less visible before the TOC (although I complained a lot about them whenever I saw them). We now need to fix up our existing pages, and when that's done, newly created ones will be written with the TOC in mind.—Eloquence 12:40, 29 Jul 2003 (UTC)
Surely there must be an article to serve as an example for us. Could you provide a link to one? --mav
You mean I'm supposed to show you an article that shows the TOC doesn't work? ;-) If you want to see a positive example, here is one: Circumcision. —Eloquence 13:05, 29 Jul 2003 (UTC)

It still has a hideous amount of white space - this gets really bad for users with higher res screens. I still think the default should be hide. --mav

Yep. If the default is not minimized, we will have redesign all the existing article templates (elements, countries, states, etc.). They were not built with the TOC in mind so the white space is made very obvious with the table to the right. --Jiang
I agree the TOCs should be minimized by default. I think the often long and complicated tables are a bit overwhelming, especially to new visitors. SimonP 14:22, Jul 30, 2003 (UTC)
I also agree. Make it so! MB 15:57, Jul 30, 2003 (UTC)

Any objections against setting in minimized by default (besides by Eloquence)? I don't see a high likelihood that a minimized TOC would prevent its use by users who really wanted to it. Why not disable all images because some people have slow modems? The benefits of minimizing the TOC exceeds the costs suffered by javascript users. How about an optional minimization function? Minimize it for pages with tables/alphabetical listings and don't minimze it for massive articles? --Jiang 19:53, 31 Jul 2003 (UTC)

I object to setting the default to minimized. I very strongly agree with Eloquence's statement above that "users do not want to click in order to view navigational structures". Angela 20:14, 31 Jul 2003 (UTC)

I also prefer to see the TOC without clicking. For people who do not like that, perhaps there can be a preference setting to get a minimized TOC, additional to the current two options of maximized TOC and no TOC. - Patrick 21:04, 31 Jul 2003 (UTC)

Spaces in TOC

I was wondering if it would be possible to have the TOC ignore spaces at the end of headers? ie very many headers are formatted 

== like this ==

instead of 

==like this==

The result is a space at the end of the link in the TOC, which looks ugly. Evercat 02:24, 30 Jul 2003 (UTC)


__TOCHERE__

Rather than a __TOCFLOAT__ tag, I'd prefer a tag that says *put the TOC here*. Then if I want to float it I can wrap it in a div - but I can also integrate it as part of a table, for example.

Just a thought. Martin 09:36, 30 Jul 2003 (UTC)

That's a good idea. I'll try that. I just hope it's not abused to circumvent the rather logical placement of the TOC before the first section.—Eloquence 11:41, Jul 30, 2003 (UTC)

Bug with Table of Contents generation

See Books of the Bible for a really oddly formatted heading and table of contents entry. (I'm not really sure where I should report this... but since the TOC feature was being discussed here...) Alpdpedia 22:57, 30 Jul 2003 (UTC)

  • The article had <nowiki>/</nowiki> in the title. It's seems ok now I removed it. Angela 23:25, 30 Jul 2003 (UTC)

Horizontal TOCs

Would there be any way to have TOCs for very short headings display horizontally. This is most useful for alphabetical lists. (for an example where this would be useful see List of poets). SimonP 17:57, Aug 1, 2003 (UTC)

TOC at the top

Could TOC placed at the very top of the articles, whether then just before the first section? If you watch pages with a floating table, like History of Germany and Oxygen, the outcome is awful. I guess this is just a minor change. wshun 22:07, 1 Aug 2003 (UTC)

TOC coexisting with tables

Could the TOC be tacked onto existing tables on the country/state/... templates and have the text wrap around them? This would cover up the existing white space. --Jiang

This might be doable using the __TOCHERE__ tag, which I wil implement, and putting it inside the table.—Eloquence 00:47, Aug 2, 2003 (UTC)

Automated Table of Contents

Moved from Wikipedia:Village pump:

In many Wikipedia pages there are Automated [Table of Contents]. But I can't see, from an editing view of the page, how this is done. Can we please have some instructions somehwere on how to put an Automated Table of Contents into a page. Thanks. RB-Ex-MrPolo 09:52, 29 Jul 2003 (UTC)~

This is a new feature under discussion. The TOC only shows up if their are at least three subheadings on the page. --Jiang 10:09, 29 Jul 2003 (UTC)
What I don't like about this new feature is the TOC below the first paragraphs of the article. It should be really on top, below the headline. Otherwise it's just chaotic, see Sociology for an example. -- till we *) 10:11, 29 Jul 2003 (UTC)
Please discuss the new changes at Wikipedia talk:Software updates and not here. --Jiang 10:13, 29 Jul 2003 (UTC)
Done that -- till we *)

New edit links / new edit features

When I click a link from the TOC, it dutifully brings me to that section, but the preceding edit link (that is the edit link for the section I chose from the TOC) is not visible, so I have to scroll back one screenful. A small matter, but illogical nonetheless. -- Cimon Avaro on a pogo-stick 01:28, Jul 29, 2003 (UTC)

I'm not sure what you mean. The edit link should be to the right of the section title. Can you create a screenshot?—Eloquence
Ah, now I see what you mean. I recommend using right click editing if your browser allows it.—Eloquence

Bug with new edit links?

Is there some problem created by the new edit links? Twice now somebody has edited this page and duplicated a whole lot of text in the process (see this diff and this one). I don't know what's causing it, but it's not happened before that I can remember. --Camembert

Can't reproduce. Could be an edit conflict thing. Let me know if you can verify this somehow.—Eloquence

Something's just gone weird with the edit links. They no longer edit the right section. When I tried to edit this section, it took me to the man-boy love thing instead. Angela 01:43, 29 Jul 2003 (UTC)

I got a message from Eloquence. My edit seemed to have caused some text duplication. What I did was: selected editing a section (which gave me the right section to edit), got edit conflicts few times, and had to copy-n-paste the part I wrote to the new window. I don't think I copied other parts, but not perfectly sure. Hope it helps. Tomos 01:56, 29 Jul 2003 (UTC)

Perhaps we should turn off these edit section links temporarily. -- Tim Starling 01:57, Jul 29, 2003 (UTC)

OK, if it just happens with edit conflicts I should have that fixed soon. I'll get right on it.—Eloquence


After reviewing the diff, etc., I have an idea about what happened.
When I get an edit conflict, I get the whole text, instead of the section that I was editing, on one of the edit boxes. I pasted my text into that window (with all sections) and saved, believing that the text will become the latest version. What happened instead was perhaps that the long multi-section text was saved as the new text for the section I initially choose to edit. Am I making sense? Tomos 02:02, 29 Jul 2003 (UTC)
You are correct -- the upper window was still treated as a section even though it contains the entire text. I just fixed it -- it should no longer happen.—Eloquence 02:06, 29 Jul 2003 (UTC)

Something weird just happened. I used the section edit feature (neato, BTW), wrote a message hit save, noticed an error in my text, hit stop before the edit posted, fixed the error, hit save and the result was the replacement of the whole page with just the section I was editing. See [2] --mav 14:28, 29 Jul 2003 (UTC)

Ugh, that's a bizarre bug. Let's see if I can track this one down. In the meantime please just save again in these cases.—Eloquence 14:32, 29 Jul 2003 (UTC)
OK, should be fixed now. Trying right here.. yep, works.—Eloquence 15:34, 29 Jul 2003 (UTC)

Section Editing feature requests

Editing section including subsections

I've mentioned this before on the test wiki but can we have section editing be able to edit the whole section? It makes no sense not to be able to edit the subsections of a section. I think the software should get the text to be edited up to the next same or higher-level heading (or end of text, if there's no matching heading)—not just simply to the next heading.

I disagree. Each section should have a reasonable amount of text. If you don't want to add text to a section, don't create a new section.—Eloquence 02:49, 29 Jul 2003 (UTC)
Maybe I didn't express myself well. What I meant was, supposing we have the following stuff:
Header3
Some Text in section 3. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Header3.1
Some Text in section 3.1. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Header3.2
Some Text in section 3.2. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
I should be able to also edit sections 3.1 and 3.2 when I edit section 3. -- seav 03:56, 29 Jul 2003 (UTC)
I don't think so. That defeats the whole purpose of the feature, which is to edit about one screenful of text -- that should also be the average length of a section. You should not create a second level section and then just add one or two paragraphs below it.—Eloquence 04:00, 29 Jul 2003 (UTC)
At first blush, I agree with Seav's suggestion. I don't think that the average length of a section should be about one screenful of text - about half that, in general. I suggest that if a section has less than three sub-sections, then you should be able to edit the entire thing as one. If it has three or more sub-sections, then you should be able to edit the sub-sections individually. This would tie in nicely with the TOC defaults.
I'm happy to work with the current system for now, and I might change my mind over time. So don't take this as criticism - just my immediate reaction... Martin 08:56, 29 Jul 2003 (UTC)

Also, can a developer modify the Cologne Blue stylesheet so that all headings and not just H1 have font-size definitions? (So we can finally address the problem of ==this level heading== appearing too large (I think in IE browsers)) :) —seav 02:35, 29 Jul 2003 (UTC)

Could we have the first [edit] set aside in some way? Currently it blends in too much with the text. I suspect--but can't yet verify--that speech browsers would read the page wrong. e.g. on Joel and Ethan Coen I get the first line of text as the following:

Joel and Ethan Coen, commonly called simply The Coen Brothers in the film business, are United States directors best known for [edit]

Even offsetting the edit by a larger margin, or putting it in a small greyed box would help make it more immediately obvious that the edit link for the first section is not to be confused with article text.

A second request: visit the same page above for an example of broken numbering in a TOC. In no case should numbering reset to one because of moving up a header size; it should always +1 the previous value. In this case there is no previous value, so it's taken as zero; that could be solved by disallowing headers larger than the first, but, uh ... never mind. Too much hassle for too little gain. Koyaanis Qatsi

Couldn't the first [edit] positioned alongside the main title of the article? But on the other hand, that would imply (if the section includes subsection policy is implemented, which I would prefer) that the [edit] suggests to edit the whole article. Another idea -- couldn't the edit become a small inline image (a box with an e inside) placed in front of the text / the title? Like
[e] Main title            // edit would edit article

[e] bla  Main title blab blabalababla blab 
blabalababla blab blabalababla blab blabalababla blab 
blabalababla blab blabalababla blab blabalaba

blabalababla blab blabalababla blab blabalababla blab 
blabalababla blab blabalababla blab blabalaba

// edit would edit this intro section

[e] Section title 1

bla blab blabalababla blab blabalababla blab 
blabalababla blab blabalababla blab blabalababla 
blab blabalababla blab blabalaba

[e] Section title 2

bla blab blabalababla blab blabalababla blab 
blabalababla blab blabalababla blab blabalababla 
blab blabalababla blab blabalaba
I don't like the right-mouse-edit function (and also not the double-click edit function), because I use the right mouse button for other things often. And maybe a really small image (16x16 px) would be better than the floating word [edit]? -- till we *) 10:32, Jul 30, 2003 (UTC)
Regarding that image, I think a good idea would be to have a small left margin (like 25px) added to the space reserved for the article. Then we can, through CSS, place an absolutely positioned [edit] image beside the section header in the margin. Those without CSS will have the image just after the header. Special consideration would probably be needed for the edit link in intro paragraphs. --seav 11:35, Jul 30, 2003 (UTC)
I've experimented with a sample layout for the edit "button". Maybe we could put the images on the right side... and probably the image itself needs to be a little less conspicuous. But I think it's doable and shouldn't interfere with the article much. --seav 12:30, Jul 30, 2003 (UTC)
Changed the edit icon to a pencil as suggested by Tillwe. Looks much better and less obstrusive than the square with an 'E' --seav 15:46, Jul 30, 2003 (UTC)

1) Image: I have experimented with using an image. It looked good, but I didn't have a free one to use. If you can send me one, I'll use it (text browsers will interpret the ALT tag for the image).

2) Placement: Don't worry, text2speech browsers won't get confused by the placement of the first [edit] link. It's in a <DIV> tag. Text2speech browsers will simply read it before the actual text. That being said, it probably should not appear in the printable version ....

3) Right-button editing: It's obviously a matter of taste, but I don't buy any of the arguments against using this. In Mozilla at least, I don't use any relevant functionality -- I can open links by clicking them, open them in a new window by middle clicking them, do stuff regarding the text by selecting it and then right-clicking elsewhere in the browser window etc. And it's damn convenient. But whatever floats your boat -- that's what the [edit] links are for. —Eloquence 11:58, Jul 30, 2003 (UTC)

I hate it to be the one who answers to that, but "whatever floats your boat" is exactly the point -- Wikipedia should be useful not only with Mozilla and a specific set of clicks and keys which one person (the developer) has internalized, but also with every other browser, including Lynx, and every other common set of individual usages. But I do it that way, and it's comfortable just isn't a valid argument discussion usability. ((That's why I think [[[edit]]] links are great, and right-click-editing via JavaScript is something to special.)) -- till we *) 13:51, Jul 30, 2003 (UTC)
Uh, yeah, that's why I made right click editing an option and not the default.—Eloquence 13:56, Jul 30, 2003 (UTC)

Odd limitation of the section editing feature

The section editing feature in most cases does not work when the page is displayed with a table of differences between two versions (changes, cur, dif and last). More specifically, in something like

http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Village_pump&diff=0&oldid=1215566

(changes from a specified version) it does not work, but in

http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Village_pump&diff=0&oldid=0

(last change) it does.

This is somewhat inconsistent and inconvenient, requiring pressing "Current Revision". Is there a reason behind this? - Patrick 02:24, 1 Aug 2003 (UTC)

Can the new edit links on protected pages be disabled? It will just confuse newcomers who click on the links on the main page and are taken a subsection of the page, unable to edit. This may make them think that pages can't be edited at all.

Some of pages are just one liners. It seems awkward sometimes to have so many edit links cluttered on the right side of the page. Is this new system here for good?

--Jiang 04:05, 29 Jul 2003 (UTC)

I think sysops are the only ones who see edit links on protected pages. Also, you can turn off the feature in Special:Preferences. -- Notheruser 04:07, 29 Jul 2003 (UTC)
No, I signed off and the edit links were still there. When I tried to click on them, I was shown that particlar subsection of the page but in protected mode. --Jiang 04:17, 29 Jul 2003 (UTC)
Hmm, maybe the pages are cached? -- Notheruser 04:21, 29 Jul 2003 (UTC)
I'm not a sysop (unless nominated without my knowledge) and I suddenly see little [edit] marks all over the right hand side. I thought I'd done something wrong or it was a bug. What are hey? Marshman 04:14, 29 Jul 2003 (UTC)
See Wikipedia:Announcements for information about the recent changes to the software (that page will explain it better than I can). About the sysop comment, I was referring to protected pages (mainly the front page). -- Notheruser 04:21, 29 Jul 2003 (UTC)
Jiang, I cannot reproduce this. Logging out produces no [edit] links on the Main Page as expected. Please be sure to clear your cache before viewing the page after logging out.—Eloquence 04:46, 29 Jul 2003 (UTC)
Ok, my bad. --Jiang

Section edit feature

Quite a number of articles have short subsections and it now looks very unappealling to have so many edit links cluttered on the right hand side of the page. I propose that a subsection be a certain length before the edit button appears. In many instances, short subsections and introductions are inevitable.

Personally, I am opposed to having these edit links pop out throughout the article. There seems to be some psychological connotations involved. When one reads the article, s/he is constantly reminded "Anyone can edit this....don't trust this..." But since people have slow modems, and it may be more convenient to read/edit/read/edit in such a sequence, I don't object to the concept. I just think the number of links should be kept at a reasonable number. One sentence intros or section introductions should not have their own edit button. If the point is the break the article into chunks, there needs to be substantial chunks in the first place.

--Jiang 05:59, 29 Jul 2003 (UTC)

Yep, I agree. Whilst most of the new stuff is good (thanks developers), the section edit links are a net loss. --Robert Merkel 06:03, 29 Jul 2003 (UTC)
I disagree. The right solution in these cases is to reduce the number of sections, or to add text. The [edit] links merely make this problem, which existed before the feature was added, more visible. Headings are not a way to structure text if there is no text to be structured. Furthermore, the [edit] links are only visible for logged in users, who are likely to be interested in easier editing features, and if you find them visually unappealing, you can 1) turn them off, 2) turn on right click editing instead if you use a modern JavaScript-capable browser such as Mozilla or IE. In general, I really recommend using right click editing if you can -- it's a lot cleaner than those ugly [edit] links, but we can't make it the default because it won't work in many older browsers. That makes it all the more important to tell new users about the feature so they can give it a shot. —Eloquence 07:40, 29 Jul 2003 (UTC)
In some articles, the intro is inherently a one liner, with the subsections containing the bulk of the texts. How about the UCB article section under History, which contains no text? But since the links are only visible to logged in users, I drop my objections. These links do make the articles easier to edit, just more annoying to read. --Jiang 08:27, 29 Jul 2003 (UTC)
The UCB article was an excellent example for bad use of sections. It is completely wrong to add a section header for each frelling paragraph. That only makes the entire page look messy and difficult to read. Furthermore, section headers should always descend by one level, not by two as this one page did.—Eloquence 11:08, 29 Jul 2003 (UTC)
On this page, there's at least one edit link for a place with no text - and there's really no point in putting any text there either: the header is self-explanatory. For example, in the following situation:

Header 1

{no text}

Header 1.1

Text 1.1

Header 1.2

Text 1.2

We could have a single edit link for the text of header 1, the text of header 1.1, and Text 1.1. That's very much a subtle tweak-type thing, though - the basic concept looks sound. Martin 09:06, 29 Jul 2003 (UTC)

Autopaste section header into the edit summary?

Well the autopaste in the delete function is not directly to do with editing, so probably it cannot be directly applied here. Anyhow, would it be possible/useful to automatically paste the section header of the section you are section editing onto the summary line? How about the same for the "Subject/headline" of a "Post a comment" edit? -- Cimon Avaro on a pogo-stick 12:52, Jul 30, 2003 (UTC)

Uglyness of the new edit feature

I per chance used an old Netscape 4.78 today, and look how ugly the [edit] is there (and also inusable: Netscape 4.78 has the 32k problem, but I couldn't edit sections because the edit field was behind other text). So I write this on IE on the same machine. -- till we *) 2 Aug 2003

Screenshot of the new edit feature in Netscape 4.78 - sorry for the gif

Don't use Netscape 4, or turn off the feature when using it.—Eloquence

Nah, I don't think that's the solution. Okay, if one uses Netscape 4.x most of the time, one should turn off the feature. Okay. But AFAIK it's initially turned on, so if someone using an old Netscape becomes a Wikipedia member, the first thing (besides of ugly formated pictures, but that's a minor probleme) will be an totally useless and crappy [edit] right in the text of the headlines. I'm sure there must be a way to make this more backwards-compatible. If you want a technical solution, this could even be something like a Netscape 4.x-autodetection which disables the edit feature. -- till we *) 13:47, Aug 2, 2003 (UTC)
You're free to submit a patch. I don't care about obsolete browsers.—Eloquence

Inter-section Edit Conflicts

(moved to Wikipedia talk:Sections)

Right Click Editing

I would just like to say, that I really hate the right-click editing. Mostly because I can no longer right click on headings that are also links to open them in a new page. Could we make this a feature you can turn off in the user preferences? MB 01:11, Jul 30, 2003 (UTC)

Did you uncheck "Enable section editing by right clicking on section titles (JavaScript)"? -- Notheruser 01:16, 30 Jul 2003 (UTC)
Hmm, was that there earlier today? I swear it wasn't, cause I went looking for it. Thanks though, it was just what I wanted. MB 01:46, Jul 30, 2003 (UTC)
Yeah, it was there. A mere oversight, I guess? -- Notheruser 02:03, 30 Jul 2003 (UTC)
In IE you can open a new window by shift-clicking, in Mozilla by middle- or ctrl-clicking. -- Tim Starling 01:26, Jul 30, 2003 (UTC)

Post a comment

"Post a comment" feature -- Village pump should be a talk page

The Village pump as a talk page discussion

Moved from Wikipedia talk:Village pump


You may have noticed that there is now a "Post a comment" feature for talk pages. The advantages of this feature are:

  1. Appends directly to the page. No need to load whole page into edit window.
  2. Because it only appends, it can never cause an edit conflict.
  3. Encourages proper use of headlines -- this in turn makes replying easier because you can just edit the section instead of editing the whole page.

The Village Pump, unfortunately, is not in the Talk: namespace, so the "Post a comment" feature is not available there. I propose moving it into the Talk: namespace and redirecting the main page there. Any objections? —Eloquence 01:27, 29 Jul 2003 (UTC)

No objection. Should the same be done for the reference desk? Angela 01:36, 29 Jul 2003 (UTC)
Probably. These are both essentially discussion pages.—Eloquence


I don't like the way the subheading is linked to the edit summary. This feature could be useful in many cases where headings are not appropriate, for example posting a reply to a topic already started. Also, it would be nice to put in an HR before the heading.
Moving Village pump to talk is not ideal... The best thing I think would be to have a more formal set of article properties. The simplest UI would be commands of some kind at the top of the article, like the current TOC suppression. The properties we definitely need are:
  • TOC suppression
  • Leading lower case in title (very simple to code, as I've said before)
  • Talk page (allow append)
Ideally the syntax would be similar to the only other currently widely-used command -- #redirect. Perhaps #enable and #disable. e.g.


#disable toc
#enable lower case title
(posted via edit conflict) -- Tim Starling 01:46, Jul 29, 2003 (UTC)
I think it's a good idea to link subheadings and edit summaries. It encourages authors to write good headlines that summarize the content of their comments and avoids redundancy. Yes, "Post a comment" can be used to reply, but technically it shouldn't be used for anything but short replies (which need no summaries), because there's a risk that your reply ends at the bottom of a new thread -- not where you intend it to be placed. "Post a comment" ignores edit conflicts, which is convenient, but also makes this kind of result possible.
Instead, section editing should be used, which is only possible if people start using headings for their comments which, again, is encouraged by the "Post a comment" feature. Horizontal lines should be eliminated entirely. They look ugly and don't help at all in structuring the page.

The policy debate

As for the article properties thing, I dunno. IMHO namespaces should behave differently, and it is only logical to have discussion pages in the discussion namespace. Somewhat inconvenient to type, perhaps, but that can be fixed in other ways.—Eloquence 03:28, 29 Jul 2003 (UTC)
Since when do short replies need no summaries? -- Tim Starling 03:53, Jul 29, 2003 (UTC)
They don't -- that's what the "minor edit" checkbox is for. But as I said, if you want to write a reply with a summary, use the "edit section" feature.—Eloquence 04:03, 29 Jul 2003 (UTC)
That's what the "minor edit" checkbox is for? Not according to Wikipedia:How to edit a page it's not. You're imposing your editing style through a software change. Allowing an arbitrary edit summary would make the feature much more general. Instead of a prescription of how comments should be added, it would become a useful and versatile feature, applicable to many situations. -- Tim Starling 05:31, Jul 29, 2003 (UTC)
I'm not imposing anything. You're free not to use the "Post a comment" feature and to continue editing as before.—Eloquence 05:41, 29 Jul 2003 (UTC)
You are. Maybe you're not aware, but the changes you brought (after discussion on the lists, I'm sure about that) really imply changes in the way persons are supposed to use Wikipedia. That is, "edit"-section links encourage to edit only a section, they and the TOC encourage a spefic use of headings, the comment-function implies the usage of an "heading - text"-discussion style, norms like the 3-headers give a TOC and also the placement of the TOC in front of the first heading all encourage spefic styles of editing and writing. Of course, people can ignore or disable most of the new features. But nevertheless, articles will be written and edited with them in mind, and I am really a bit concerned if this connection between code and usability, not to say, social norms isn't seen by the developers. I'm not sure if Lawrence Lessig is right, but if he's right, Wikipedia could be a prime example (I'm referring to his general idea: "[T]he most significant of these four constraints on behavior in cyberspace is the analog to what I called architecture in real space: This I will call code. By code, I simply mean the software and hardware that constitutes cyberspace as it is—the set of protocols, the set of rules, implemented, or codified, in the software of cyberspace itself, that determine how people interact, or exist, in this space. This code, like architecture in real space, sets the terms upon which I enter, or exist in cyberspace. It, like architecture, is not optional.", [3]). -- till we *) 15:54, Jul 29, 2003 (UTC)

d::::::::There's a difference between encourage and impose. And the same arguments can be applied to the earlier revision of the code as well.—Eloquence 16:01, 29 Jul 2003 (UTC)

Sure. Don't take that personal. I even like the general idea of both secition editing and the TOC, even if I'd prefer a TOC more configurable by the user. But I see encourage and impose not as a dichotomy, rather as a continuum, and so I'm just trying to raise awareness for possible problems resulting out of this continuum. Software changes can be somewhere in the middle (as the current one, but they also could someday lean to the impose-side of things). Read this as a bit of an policy feature request, maybe. (My contributions on village pump re: decisions go in the same direction, I'd say) -- till we *) 16:08, Jul 29, 2003 (UTC)
No offense, but I spent a lot more time defending these features than coding them. First on the wikitech-l list, then on wikipedia-l, then on test.wiki, then on meta.wiki, and now on Wikipedia proper (some minor fallout on wikien-l). I'm sure there'll be lots of complaints from the non-English Wikipedians as well. Policy debates on Wikipedia are lengthy and annoying, and among the primary reasons important problems don't get fixed. People are extremely paranoid about "abuse of power" and want to participate in every decision even if they didn't invest a single second of their time in the actual implementation. All of them would love to have the entire team of developers at their disposal, ready to read their lips and fulfill their wishes.
Of course, after everything is said and done, usually the features go live with only minor changes because well, it turns out that developer X has actually invested some thought in what he did, and the last weeks were spent by others replicating these thought processes. After the second period of discussion when people suddenly notice that a decision has been made and they weren't involved (gasp), people get used to the features and stop complaining (although those who did not get exactly what they wanted will not tire to remind you how abusively you pushed your ideas through at every coming opportunity).
These discussions take most of the fun out of the programming part, so when I look at a new and exciting feature I might want to program, one of the first questions I ask myself is: Do I want to go through the trouble of justifying this? If anything, we need less debate and a more streamlined decision making process. I'm all for democracy, but you can't vote on how other people spend their time. —Eloquence 16:22, 29 Jul 2003 (UTC)
Thanks for your long answer. I understand that the way from feature idea and coding to acceptance in the Wikipedia community is long and thorny, but I believe that it has to be that way. Maybe one should write down some policy like "Wikepedia is not your programming playground" (a bit harsh), but especially if you take a big community like Wikepedia (with all the international off-spring), code (and therefor feature and usability) decisions can't be in the hand of developers only. One of the biggest probleme in software engineering as far as I understand is the mismatch between programmers ideas about usability and features and the users ideas about the same. Here with Wikipedia we have the possibilty to avoid such mismatches, and that is one of the strengths of open-source/free software development, especially with a big and lively community around. Just to illustrate my point: I can imagine the Microsoft programmer who had the idea to bring cute interactive assistants in MS Office products. Nice idea, nice proof of concept, and if you're annoyed, you can turn them off. If MS Word was the product of a community like Wikipedia is, there would be no interactive assistants, and that would be a good thing. And even so, nowadays MS Office users happily live with theirs assistants (or try to turn them off, and some actually turn them off).
But maybe, if there is really the long way -- tech-ml, broad-ml, test-wiki, meta-wiki, actual implementation --, and "end-users" come into contact with the new feature only in the last part, wouldn't it be good to change development policy in a way that not only allows all users to participate (which is possible now, everbody could go into the mls), but also helps them to become aware of new features early? That is another step added to work, but maybe it helps to avoid lengthy discussions after the implementation? For example, I just visited the test wiki and found their some testing for a category-name space. I never heard about this, and I don't know if this will become a feature soon. I even do not know if this was discussed somewhere (a quick scan of the test wiki didn't say something about it, at meta I haven't looked until now). But I'm pretty sure that if someday someone says that from this point on every article can (or has to) be included into a category, there will be much discussion. Why not discuss the necessarity and design of such big new features in the here and now, or give us "poor" end users ;-) at least a subtle hint, eh, link? -- till we *) 16:40, Jul 29, 2003 (UTC)

You write: "...that is one of the strengths of open-source/free software development, especially with a big and lively community around." Actually, I would appreciate it if Wikipedia development would be a little more like other open source projects -- developers listen to users, but they have some room to make decisions.

"I can imagine the Microsoft programmer who had the idea to bring cute interactive assistants in MS Office products." I can't. Such ideas are not born in programmers' heads, they are born in marketing departments. That's why you don't have these cute interactive assistants in open source software.

Wikipedia is not a development playground, true, but developers already exercise control over each other's changes. The community should have a chance to voice objections when the feature is announced on wikipedia-l or wikitech-l (general objections), when it is put on test.wiki (specific implementation-related objections), and after that the discussion period should be mostly over and only bugs should be fixed. People who are not subscribed to the mailing lists should have no right to complain later, although it would be helpful to have at least a digest of the current ongoing events on the wiki. This, however, can be done by non-developers who volunteer for the task.—Eloquence 16:47, 29 Jul 2003 (UTC)

Are you saying the changes are here for good because no one spoke up earlier? That's ridiculous. Few people were aware of them happening and I'm sure would have spoken up earlier had they known about them. I personally do not subscribe to mailing lists because I want to avoid email clutter and I assume the info I would need would be announced to the general community. Are you punishing people for not being on the mailing list? What's important is that the community's interests are served, not some procedure you have never made aware of before is followed. Had people known about these changes, and the fact they would be discussed on the mailing lists, would have got some people speaking. --Jiang 03:18, 30 Jul 2003 (UTC)
I'm saying that if you want to be involved in debates related to policy and code, you should join the places where these matters are discussed: the Wikipedia mailing lists. The info you need -- that the software has been changed -- has been announced to the general community as soon as it happened. If you want to be involved in the debate, join the mailing lists. Simple, no?—Eloquence 06:34, Jul 30, 2003 (UTC)

Where is Waldo?

"You may have noticed that there is now a "Post a comment" feature for talk pages."

No, actually I hadn't noticed. Seriously. Where is that function supposed to be in relation to all the other buttons and links? This isn't one of those things for which you need that floating or fixed thing is it? I can get my screen to split into a text area and a function list down one side on one skin of one browser I use, but then I need a microscope to read the text. So, to seem as stupid as I probably am, where again is this "Post a comment" feature located on the screen? -- Cimon Avaro on a pogo-stick 10:36, Jul 29, 2003 (UTC)
Look to the left of your screen. It's right underneath "Edit this page" on the sidebar. --Jiang
Strangely, everything in that section of the sidebar except the "post a comment" link is mirrored at the bottom of each page. Not sure why that one's missing. --Delirium 16:22, Jul 30, 2003 (UTC)
Take a guess :-) —Eloquence

Layout changes

Heading size

The article titles appear smaller than before. What's up with that?

They are smaller.—Eloquence

Heading numbering

The TOC is neat - but it is numbered by default while the headings are not. IMO headings should be numbered by default using the same criteria as the TOC; headings are numbered if and only if there are more than three of them. It is real silly to have ==External links== labled as 1. --mav 13:23, 29 Jul 2003 (UTC)

There is an "Auto-number headings" feature in the preferences. Maybe this will do it? MB 14:12, 29 Jul 2003 (UTC)

Color Change

Was there any reason why pages in the wikipedia namespace now have a different background color? Was there something wrong with the old color? MB 14:00, 29 Jul 2003 (UTC)

What do you mean? There was no change in color - it was yellow before and is still yellow now. But the saturation of that color was reduced in order to be easier on the eyes. Bright yellow is fairly harsh. --mav 14:06, 29 Jul 2003 (UTC)
Yes, that is the change I am refering to. Where was this discussed? Or was it just a bold change by a developer? MB 14:12, 29 Jul 2003 (UTC)
On WikiTech-L after I saw a ugly metallic blue as one of Erik's tests on the test wiki (whose RC is listed on our RC, BTW - you should look at the test RC once in a while). I protested strongly and the compromise (which I really like, BTW) was to reduce the brightness of the background (this was the major complaint against it). But really - do the developers have to run a vote every time they do something? If you are interested in things as minor as the brightness of the background color then you should subscribe to WikiTech-L. Or at least Wikipedia-L --mav
Note that the yellow is the same as the pastel background on the Main Page.—Eloquence
FWIW, the difference between a plain white page and the new, paler yellow is quite subtle, at least to my eyes. The old color scheme had the advantage of providing an immediately obvious visual distinction between the two kinds of pages. -- Cjmnyc 06:07, 31 Jul 2003 (UTC)

New user preferences

Table of contents - preferences

About the new skin/layout/appearance/whateveryouwanttocallit: will there be/is there already some way to hide the little "edit" links at the top of each section of an article/page? And is there some discussion about this new layout somewhere? --Camembert

Check your prefs. If you use IE or Mozilla, you can use right click section editing instead of the [edit] links. Yes, the layout was discussed a lot on the mailing list, on Meta and on test.wiki.—Eloquence 00:29, 29 Jul 2003 (UTC)
I feel like a fool - I'd checked my prefs and somehow missed that option. Could you point me to a specific meta page about this (I don't read Wikipedia-L anymore, which would explain how I missed it all on there). Just curious. I think the changes are pretty good on the whole, by the way (though I expect I'll be turning most of the new features off, cos I'm a Luddite at heart). --Camembert
There was some discussion at m:Layout vote and on Wikipedia-L.—Eloquence 00:42, 29 Jul 2003 (UTC)
Thanks. --Camembert

New user preferences

Anyone want to summarize the new prefs at Wikipedia:User preferences help?—Eloquence 08:06, 29 Jul 2003 (UTC)

Interface elements like special pages and search buttons

Special pages

Could we please have a "special pages" link (on the page itself, not just in the quickbar, which not everyone uses)? There seems to be plenty of spare space at the top where it could go. --Zundark 07:54, 30 Jul 2003 (UTC)

Could we please not. Martin 09:28, 30 Jul 2003 (UTC)
There needs to be a simple way for people to get to their watchlist, for example. --Zundark 11:54, 30 Jul 2003 (UTC)

Search button

What happened to the Search button? All we seem to have now is the Go button, which is much less useful. --Zundark 07:54, 30 Jul 2003 (UTC)

Disabled due to server load (see the Announcements for July 29). In the meantime I use Google with a "site:www.wikipedia.org" qualifier. --Delirium 07:59, Jul 30, 2003 (UTC)

Optimization and Speed, Searching

I use these two features a lot and I am wondering if they are optimized in any way so as to not use too many cycles in db queries. Are they cached or saved somehow in the article entry? I use them a lot and I wonder if I should use them more sparingly. Dori 18:06, 31 Jul 2003 (UTC)

The tables are indexed and queries should be reasonably fast, feel free to use them as you see fit. "Watchlist" is more problematic.—Eloquence 21:35, Jul 31, 2003 (UTC)
Couldn't we have a sorted RC based on whether or not a page is watched by the user? It sure would be neat to track all the changes made to the articles I watch from some time index (just like on RC). --mav 21:44, 31 Jul 2003 (UTC)
Good idea, but our main problem is optimizing the queries to be faster -- to that end, it doesn't matter much how we display the changes. This and the search are really our two big problems -- the rest of the site is reasonably fast, as you can see now that the search is entirely disabled.—Eloquence 21:56, Jul 31, 2003 (UTC)
Speaking of searching ; as a temporary stop gap I think it would be a good idea to redirect search queries to Wikipedia Google search. IMO, an encyclopedia with out some type of text search is not very useful when you are trying to look up facts. --mav 22:01, 31 Jul 2003 (UTC)
Brion has some ready-made solution for this somewhere, I also want to hear his opinion on why exactly even minimal search queries bogged down the whole system after Pliny crashed. He'll be back tomorrow.—Eloquence 22:17, Jul 31, 2003 (UTC)
The google search would be very good indeed. Is there anyway it could be integrated into the site instead of just having a link to google (I mean you enter the search from wikipedia, but then it can go to google for the results)? Dori 04:15, 1 Aug 2003 (UTC)
Yeah, I use the watchlist too to see if someone "messes up" some article I care about or to follow up on something. I don't know much about db's so I was just shooting off there. Glad to know at least two out of three things I use doesn't cause too many problems :) Dori 04:15, 1 Aug 2003 (UTC)
One more thing I just thought of with regard to the watchlist. I often check the what links here on an article I am keeping a tab on, because every time another article that has a link to it is edited and saved I get a new entry in that list. Maybe it could be done so that an "invisible link" is added to each article that you want to watch to a special page on one's user pages. Then you could just check what links to that user page and you'll get something similar to the watchlist. Would this be doable, more efficient, complicated, etc? Dori 04:22, 1 Aug 2003 (UTC)
With regard to the Watchlist, would it be possible to have a page that lists all the pages that a user has added to his watchlist. In that page you could have three options: one that activates it (Watch), one that deactivates it (Stop watching), and one that removes it (also stops watching). The option in the articles would then add it and activate it. Right now, I might not even be aware that I am watching a page until I see it appear in my watchlist; at that point I load the article, and select Stop watching. It would be much easier to have a page that handles this.
Another idea, would be to limit the number of active articles on the watchlist. I know this would not be terribly popular, but it would alleviate some of the load. I think I'm done, hope someone reads this :) Dori 17:36, 1 Aug 2003 (UTC)

Speed

Moved from Wikipedia:Village pump:

Is it just me or does Wikipedia seem real fast right now? Has something changed? If so - me like. :) --mav 06:29, 29 Jul 2003 (UTC)

It could be my link table optimisation, or it could be your imagination. I'm not sure because we never worked out exactly how much time link updates were taking. BTW, you should probably avoid undeleting for a few days. Eloquence has a feeling I might have broken it, and I haven't checked it out yet. -- Tim Starling 07:48, Jul 29, 2003 (UTC)
The new link update code definitely helped (section editing could also have a minor effect), and the two major slowdowns today were from an inconsiderate sysop who ran (really) idiotic queries. No more sysop queries to bog us down are a good thing. I think they should be disabled on all wikis with more than 10K articles -- right now the Germans or the French can still bog us down because their DBs are already quite large. Then we need to optimize the search and the watchlist and we have a decent response time. For the next couple of months ;-) —Eloquence 07:54, 29 Jul 2003 (UTC)

Where to discuss changes?

Discussion of changes

Moved from Wikipedia:Village pump:

Can a page be set up so the entire community can discuss the new changes? I'm sure different people have different opinions and not everyone likes the new scheme. I have a couple concerns, but is village pump the place to voice them? --Jiang 05:04, 29 Jul 2003 (UTC)

This is a wiki -- go ahead and create one. Wikipedia talk:Software updates, for example.—Eloquence 05:21, 29 Jul 2003 (UTC)
Okay, I moved everything over there. -- Tim Starling 05:54, Jul 29, 2003 (UTC)

Odd Intentations

Odd intentations with the new software

Moved from Wikipedia:Village pump:

Since the new software has been installed, I see that several (but not all) articles have an odd one-character indentation in the first line. I can't find anything in the text that would cause this. I'm using IE 6.0. RickK 03:21, 30 Jul 2003 (UTC)

OK, I looked at the same pages with Netscape 4.7, and I don't see the indentations. RickK 03:47, 30 Jul 2003 (UTC)
I don't know the technical details, but it's connected to the right-floating [edit] buttons. (On some pages, you get a similar effect when there's a right-floating image at the beginning of a paragraph.)
—Paul A 04:55, 30 Jul 2003 (UTC)
The solution is one or two blank lines between the top and the first paragraph in the wikisource, alternatively between the interlanguage-links and the first paragraph. The blank lines are certainly less disturbing the than the unintended space - as a remedy until it's somehow worked around through a software fix.
-- Ruhrjung 12:48, 2 Aug 2003 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Software_updates&oldid=1232708"