Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Cyrius (talk | contribs) at 15:16, 29 January 2005 (→SQL Queries). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


The technical section of the village pump is used to discuss technical issues. Bugs and feature requests should be made at MediaZilla: since there is no guarantee developers will read this page.

FAQ: Intermittent database lags can make new articles take some minutes to appear, and cause the watchlist, contributions, and page history/old views sometimes not show the very latest changes. This is an ongoing issue we are working on.

Details about the occasional slow speeds and deadlock errors: here

Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).

Start a new discussion in the technical section

 Policy Technical Proposals Idea lab WMF Miscellaneous 

Technical archive

Discussions older than 7 days (date of last made comment) are moved here. These dicussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Multiple category entries

For some reason, the article on Mount Andrus appears in Category:Mountains of Antarctica seven times, and in Category:Shield volcanoes six times. I can't see an obvious reason for the glitch, and it only appears in its other category (Volcanoes of Antarctica) once. Any ideas? Grutness|hello? 00:17, 5 Jan 2005 (UTC)

The same problem is happening at Category:Campaigns of the Main Eastern Theater of the American Civil War. Notice the two entries under B. --brian0918™ 01:18, 5 Jan 2005 (UTC)
Repaired. The category "article" was created twice. -- Cyrius|✎ 01:54, 5 Jan 2005 (UTC)
It must be a database error. I tried removing the category links and it only removed one of the duplicate entries in the category. —Mike 01:51, Jan 5, 2005 (UTC)
The reason it appeared in categories multiple times is that GarciaB managed to create the article about eight times. Each creation had slightly different categorization, which is why it appeared in different categories in different quantities. Now repaired. -- Cyrius|✎ 02:01, 5 Jan 2005 (UTC)

Could a similar problem be behind strange links with the Owen Marshall article? It only appears in categories once, but turns up twice in "What links here" lists. Grutness|hello? 05:50, 5 Jan 2005 (UTC)

Yes. Should now be repaired. -- Cyrius|✎ 06:27, 5 Jan 2005 (UTC)

And another one (sigh) - Brown Clee Hill. Just changed it from a geo-stub to a UK-geo-stub. It still appears 4 times in the geo-stub category, though - it should no longer be there at all. Grutness|hello? 13:41, 12 Jan 2005 (UTC)

I tried to fix Brown Clee Hill by deleting and restoring it, but now it doesn't appear in the categories it's supposed to. I'm not sure what's wrong.-gadfium 18:56, 12 Jan 2005 (UTC)

Is there an easy way for non-admins to fix hese things? I ask because I've found several more with similar problems; most recently, problems with Androscoggin River, Bykhov, and Fontinhas Grutness|hello? 10:21, 18 Jan 2005 (UTC)

Fixed Fontinhas. The other two look okay to me, maybe someone else already fixed them.-gadfium 18:51, 18 Jan 2005 (UTC)
Androscoggin River still lists in Category:Geography stubs, even though the stub message was removed from the article. Bykhov seems fine now, though - thanks to whoever fived that (and to Gadfium for fixing Fontinhas) Grutness|hello? 23:05, 18 Jan 2005 (UTC)

Category:Birds has a subcat (Category:Columbiformes) that is listed about twenty times. --DanielCD 21:44, 18 Jan 2005 (UTC)

Fixed. It struggled, and I lost most of the edit history. The database must be pretty sick.-gadfium 22:36, 18 Jan 2005 (UTC)

Add another: Vällingby, listed three times as a geography stub Grutness|hello?

Fixed.-gadfium 22:09, 20 Jan 2005 (UTC)

There are still problems with Androscoggin River and Bykhov (both appearing in geography stubs, although they have no template), and Mosteiros (Ponta Delgada) seems to have double category entries. Grutness|hello?

Spyware causing problems for editors

Today I've seen some problems caused by what seems like spyware on peoples computers. Both 172.189.29.158 and KeyserSoze have made positive edits that have had to be reverted after spurious HTML code was added into parts of the article. Fortunately MediaWiki prevents such code from working, displaying it instead. I'm thinking that the spam filter may need extension to prevent this from happening - there may be tons more editors that are trying to contribute but causing such problems. violet/riga (t) 00:28, 9 Jan 2005 (UTC) Just removed the code from the East Timor article thanks to a search for "onmouseover" at Google. There may be others but neither the inbuilt search nor Google are returning any for me at the moment. violet/riga (t) 00:38, 9 Jan 2005 (UTC)

If this kind of insert could be identified at edit time, it should be fairly easy to identify the offending browser config and aggregate for manual forwarding to the developers of the browser. The key is to make sure the developers are made aware and can develop a fix before too many browsers and websites are affected. Wikipedia is getting pretty huge now so we should be thinking in terms of establishing working relationships with browser (and cache) developers with a view to sharing tech fixes fast. --Tony Sidaway|Talk 00:48, 9 Jan 2005 (UTC)
If their contribution is part "positive", and part negative (spam, PoV, or anything else), shouldn't you edit the bad part, not revert the whole thing, Violet? You actually reverted away good contributions in order to get the apparently involuntary spam out, that seems like swatting mosquitos with a sledge hammer. Kaz 00:52, 9 Jan 2005 (UTC)
I did re-contribute what was added by some of the edits, but the amount of crap added makes it more difficult to spot the good parts – when it's a simple punctuation edit or something like that it may be hard to find. violet/riga (t) 12:53, 9 Jan 2005 (UTC)
Here's another example that I found and cleaned up [1] at List of villains. gK ¿? 08:13, 15 Jan 2005 (UTC)
It's a piece of spamware called Hyperlinker. See http://www.doxdesk.com/parasite/Hyperlinker.html for analysis. I suggest simply rejecting all edits containing links to serverlogic3.com. -- Naive cynic 02:31, 23 Jan 2005 (UTC)
Seconded. Alternatively, someone should come up with a template message with which we can politely notify people who are infected. Rhobite 03:58, Jan 25, 2005 (UTC)

Character Display

When I am viewing an article in Wikimedia/Wikipedia and it contains special characters (such as mathematical symbols or Asian language pages) what is display is the ⊂ character instead. How can I change this? I am using IE 6.0.2800.1106CO on the Windows 98 platform (heh, not by choice).

A specific example of this is the Set article. Under the category Subset this is what is displayed:

"... written A ⊆ B. If A is subset of B, and A is not equal to B, then A is called a proper subset of B, written A ⊂ B."

Unless I am mistaken, ⊂ should be something else.

Thank you, jtmendes jtmendes 02:17, 16 Jan 2005 (UTC)

This is due to an editor with a different browser not checking how they display in IE, as they should. Drop a note on Wikipedia: Wikiproject Mathematics to remind everyone. Deco 11:17, 16 Jan 2005 (UTC)
I have some problems with display of certain symbols when running Mozilla Firefox 1.0 on a Linux system (at least under KDE 3.3 if that makes a difference). <math>\emptyset</math>: and &empty;: ∅ should display two similar glyphs. However, between the Monobook skin, Firefox, and the font system, the second is rendered as the "AE" ligature. The font used with the classic skin seems to work fine. I suppose this is a font problem on my end, not a Wikipedia problem. I am not even sure how to figure out exactly what font Firefox is using or how to fix the problem. But, it's probably something that Wikipedians should be aware of. Maybe Monobook needs to use a different font that works more generally? Gwimpey 04:04, Jan 21, 2005 (UTC)

What's happening to Wikipedia?

Almost every time I try to save an edit, it sits around doing nothing for several minutes, then finally throws up the following: 

Sorry- we have a problem...
The wikimedia web server didn't return any response to your request.
To get information on what's going on you can visit #wikipedia.
An "offsite" status page is hosted on OpenFacts. 

--------------------------------------------------------------------------------

Generated Tue, 18 Jan 2005 21:12:13 GMT by maurus.wikimedia.org (squid/2.5.STABLE4-20040219.wp20050114.icpfix.nortt.S7)

Sometimes I have to try saving a page 20-30 times or more before it finally condescends to saving the edit instead of throwing up this message; sometimes when using the back button my edit is still there in the edit box, other times it is lost. Sometimes instead of doing the edit, half the article disappears (see e.g. the page history for pine nut) instead, requiring reverting. This has been going on for a week or ten days now. It is worst (by far) from mid afternoon to late evening UTC, but happens at all times of the day. What the f*** is going on, and is anything being done to solve the problem? At the present rate, it just isn't going to be worth attempting any more edits at all, given the time it wastes waiting, waiting and waiting. Is there anything I can do to send a stronger signal to wikipedia to improve the chances of the edit working (e.g. pressing the 'save page' button repeatedly? harder??)? - MPF 21:38, 18 Jan 2005 (UTC)

Yea, almost too slow to be a viable thing. I've found vandalism I cant revert because I cant save. frusterating. Have to put it on my watchlist and hope to fix it later. I dont expect this to save by the way... --DanielCD 21:41, 18 Jan 2005 (UTC)

I find that sometimes it comes back with this message even though the page save has worked. I alternate between retrying the save and loading the page history to see if it worked or not. I have never lost the text by hitting Back, or seen page text lost. — PhilHibbs | talk 13:40, 19 Jan 2005 (UTC)

It's a really deadly combination of problems. The one that chops off the bottom of an article is nasty, because the top of the article looks fine and you may have no idea what happened. Combined with the other problem (page is really saved, but you get an error message) it means that there is no consistent relationship either way between whether it looks like the page was saved and whether it really was! So we get people who saved successfully (but don't know it) trying again and then failing: that is, their first edit was (invisibly) OK, then they mess it up trying to "fix" it. -- Jmabel | Talk 19:17, Jan 19, 2005 (UTC)

Thanks; nice to know I'm not the only one affected. Anyone know why it is happening, and if (or when) it can be solved? (PS sorry about forgetting the end big slash in the header!!) - MPF 21:39, 19 Jan 2005 (UTC)
Genrally speaking, I find refreshing on the error page and resubmitting (in IE6) brings me back to a point where I can save again. Worth a try. Filiocht 10:43, Jan 20, 2005 (UTC)

This seems to have been fixed. Big thank you, mucho gracias, and merci beaucoup to whoever fixed it. Niteowlneils 21:57, 21 Jan 2005 (UTC)

I am still having more-than-occasional problems saving long articles. I normally use Firefox. Much though I hate to say it, I've tried experimenting with IE and do not seem to have the same problem there, at least not on the first couple of attempts. Has anyone else had a similar experience? -- Jmabel | Talk 18:54, Jan 22, 2005 (UTC)

what is the difference between Go and Search? Oatee 12:08, 19 Jan 2005 (UTC)

The Go button directly takes you to an article (if it exists). Clicking on the search button will produce a list of articles that contain the text you searched for. For eg. if you type "abcd"" and click on go, you will be taken to ABCD. If you click on Search, you will get a list of articles containing "ABCD" or "abcd". If the article doesn't exist, in case of Go button, you will be prompted to create one or put up a request. In case of search button, you will be given the options to search Wikipedia using Yahoo! and Google. utcursch 12:28, Jan 19, 2005 (UTC)
FWIW, the Yahoo and Google searches are only offerred when Wikipedia real-time search is disabled (it is disabled regularly when it impedes performance. Niteowlneils 21:55, 21 Jan 2005 (UTC)

Strange bug with editing sections

Check out this diff: [2]

I clicked on the edit link for the History section, but it treated what I was saving as though I was saving the whole article. At the time, it's also not showing an earlier edit I made to the whole page (due to the replication bug), so it may have thought I was still editing the whole page. I guess I'll only use the main edit link for now. --SPUI 22:39, 19 Jan 2005 (UTC)

I've been bitten when simultaneously editing two sections of one page in separate browser windows. The second submit wipes out changes from the first one, even though the sections don't intersect. —Michael Z. 01:22, 2005 Jan 21 (UTC)
Did you have an edit conflict with someone? That's when I've seen the whole article saved as a section within itself (seems to be a new bug, as I've never run into it before v1.4)? Niteowlneils 21:39, 21 Jan 2005 (UTC)

I suggest changing the HTML generation so that it implements Google's Preventing comment spam idea. This just means that when someone types: 

[http://www.spammer.com a link like this]

Instead of generating: 

<a href="http://www.spammer.com">a link like this</a>

WikiMedia should generate: 

<a href="http://www.spammer.com" rel="nofollow">a link like this</a>

While this doesn't eliminate spam, it'll help eliminate one of the incentives for spamming Wikipedia, because such pages won't have their rankings increased.

-- Dwheeler 00:18, 2005 Jan 20 (UTC)

This exact suggestion was made at Wikipedia:Village_pump_(proposals)#Stopping_Link_Spam_.2F_Comment_Spam. Several of us disagree with it, for reasons given there. I suggest that rather than discuss it in two places, we continue discussion there. -- Jmabel | Talk 00:39, Jan 20, 2005 (UTC)

It is currently turned on. If anyone reading this page doesn't like that, please go to the other page and comment. —Ben Brockert (42) 02:31, Jan 22, 2005 (UTC)
New spot to discuss: m:Meta:Nofollow. —Ben Brockert (42) 05:39, Jan 22, 2005 (UTC)
When happend that google became the standard deposity and creator. Since all the link in the page will have this tag it is more appropiate to use the robots.txt and the METAAnyFile 12:07, 25 Jan 2005 (UTC)

Bug: Bad end tags within templates

There seems to be a bug with the tables. When I was browsing and looked up Hydrofluoric acid, at the beginning of the article was the note , and at the text of the article was squeezed into a column directly above the data table. Similar investigation showed that this is now affecting all articles under the with the chemical infobox. I am unable to fix it. User:Ingoolemo/Sig 08:16, 20 Jan 2005 (UTC)

I am experiencing the same problem across multiple pages. It seems to affect templates. —Lowellian (talk) 08:28, Jan 20, 2005 (UTC)
To clarify, normally invisible end tags are showing up as text within templates. —Lowellian (talk) 08:38, Jan 20, 2005 (UTC)

Well, I've sorted that one by converting it to Wiki markup. Can you give some other examples? (This wasn't a template, just a table.) Noisy | Talk 10:09, Jan 20, 2005 (UTC)

A different database error

I hadn't been reporting this because I though it was the standard database error, but to my untrained eye it looks unrelated to the current Wiki go-slow. A couple of articles (namely Vicente López Partido, Vila de São Sebastião, and Viseu) have all returned the following: 

A database error has occurred
Query: SELECT * FROM `ipblocks` WHERE ipb_user=117878 
Function: Block::load
Error: 1142 select command denied to user: '[email protected]' for table 'ipblocks' (207.142.131.200)

Apologies if it is part of the same problem, but it looks like completely different messages to me, and it's only these three articles - all others are working fine. Grutness|hello? 11:31, 20 Jan 2005 (UTC)

Fixed it myself - it only happened when going from Category:Geography stubs to the pages. Got to the pages from a different direction and replaced the geo-stubs with identical ones. They seem to work fine now. weird. Grutness|hello? 22:56, 21 Jan 2005 (UTC)

Image problems

For some reason on my computer images are refusing to download, either the thumbnails or the full images.

It says at the bottom something along the lines of "Uploading (2 items)/monobook/skins" but nothing actually loads. I've noticed this problem on and off for several days now.

Also a few days ago I re-uploaded a larger versions of an image that was already there (Here}, although the image uploaded it hasn't registered it on the history, and it hasn't automatically thumbnailed it to 800X600px, I've noticed this on several other pictures I've uploaded in the last few days.

Is anyone else having this problem?, what's causing it/can be done about it. G-Man 22:52, 20 Jan 2005 (UTC)

It may be a problem related to robots.txt. What browser are yuo using? AnyFile 12:06, 25 Jan 2005 (UTC)

Subject/headline

When in "(comment)" mode, or "add section" edit mode, which I am in right now, it should render the section title as well when you push preview. - Omegatron 00:47, Jan 21, 2005 (UTC)

Terrible grey edit fields in Safari

Hey, who made the edit field and edit summary field grey? Way less contrast and harder on the eyes, while serving no discernible purpose. Please change it back! —Michael Z. 01:24, 2005 Jan 21 (UTC)

Am I the only one seeing this? As of today, my edit textarea, edit summary input field, and search input field look like they have background:#ddd; applied to them, instead of being white (although the Wikipedia login fields remain white). Only in monobook—the other skins still have white fields. I see this in Safari/Mac while logged in or not, but in Firefox the fields are still white.

I can't find the new rule in any of Wikipedia's style sheets, and I can't override it in my user monobook.css. Editing text on this medium grey field is infuriating; please help! —Michael Z. 2005-01-21 08:08Z

Can't find it at all in any of the CSS files. Does Safari have settings for styling of forms? Maybe you set those, and for some reason only in monobook it applies. You could try something like
textarea {color: black !important; background: white !important;}
to reset it. PS: your sig updates its time on each edit, including those by others, I doubt that is as intended. User:Anárion/sig 07:54, 21 Jan 2005 (UTC)
Safari doesn't have any such settings. I tried selectors like that, and more specific ones like #editform textarea and textarea [name="wpTextbox1"], but still no dice.
Oops on my new sig. I thought those values would be substituted. —Michael Z. 08:08, 2005 Jan 21 (UTC)
TomG removed the form button styling from the MonoBook css file. Gabriel Wicke 15:42, 21 Jan 2005 (UTC)
Not form buttons, form fields. Textareas and text inputs. I've rebooted my machine, and they're still grey. If I cancel a page load before it's quite finished, they are white even though most of the monobook.css styling is applied, so it must be caused by either
  • a javascript that's changing styles after the page loads.
  • a selector in a style sheet that's imported after monobook.css.
  • a selector near the end of a big style sheet.
There's no User:TomG. Do you mean User:Tom-? —Michael Z. 2005-01-21 17:22Z
Sorry, misunderstood you then (obviously didn't read carefully). -- Gabriel Wicke 00:30, 22 Jan 2005 (UTC)

Looks like User:Tom-'s been editing the style sheets, and neither monobook/main.css nor monobook.css validates. I've left him a message.

I am seeing this also, and I also Hate it. Please fix, my eyes are bad enough as it is ;-) Paul August ☎ 18:22, Jan 21, 2005 (UTC)

So I'm not insane. Hallelujah! —Michael Z. 2005-01-21 18:31Z
We can't comment on your sanity, but we can say you aren't the only one! I first noticed it last night. —Mike 02:19, Jan 22, 2005 (UTC)
I'm looking into this. Tom- 23:10, 21 Jan 2005 (UTC)

The boxes from hell

This is a general observation... putting stuff in unformatted boxes is notorious for making pages not 800x600 compliant eg:(Wikipedia_talk:Footnotes). Can someone enable wrapping in these boxes; or does that contradict their purpose of having no formatting? - RoyBoy [∞] 03:45, 21 Jan 2005 (UTC)

You mean pre boxes? like
this and this and this
and this?
I suggested putting those in autoscroll boxes, but nobody liked the idea, I guess. - Omegatron 05:10, Jan 21, 2005 (UTC)
http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css#pre_autoflow
Those are HTML <pre> elements, for preformatted text, and are supposed to appear exactly as entered. The problem is, of course, when someone puts in text that's not preformatted.
What if they were formatted with "width:95%; overflow:hidden;"? Then someone would quickly notice if the text needs to be wrapped, and they would never force the page larger than the viewport. Similar idea to autoscroll, but I would find a scrollbar visually obtrusive. Here's an actual example of text I found in a pre block:
3. It shall be lawful for the Queen, by and with the Advice of Her Majesty's Most Honourable Privy Council, to declare by Proclamation that, on and after the passing of this Act, the Provinces of Canada, Nova Scotia, and New Brunswick shall form and be One Dominion under the Name of Canada; and on and after that Day those Three Provinces shall form and be One Dominion under that Name accordingly.(4) 

4. Unless it is otherwise expressed or implied, the Name Canada shall be taken to mean Canada as constituted under this Act.(5)
And here it is hard wrapped to 72 columns. Just fits in an 800px wide window:
3. It shall be lawful for the Queen, by and with the Advice of Her
   Majesty's Most Honourable Privy Council, to declare by Proclamation
   that, on and after the passing of this Act, the Provinces of Canada,
   Nova Scotia, and New Brunswick shall form and be One Dominion under
   the Name of Canada; and on and after that Day those Three Provinces
   shall form and be One Dominion under that Name accordingly.(4)

4. Unless it is otherwise expressed or implied, the Name Canada shall be
   taken to mean Canada as constituted under this Act.(5)
—Michael Z.
Nice idea, but not everyone's using an 800px window. People with 1280px windows would edit something and it would look fine for them, but be unreadable for people with smaller browser windows. What's more, the text width depends on fonts, font settings, and other local configuration issues, so it might get copped off for one editor at 800px while looking great to another who is also at 800px. I'm afraid this isn't the solution. --fvw* 07:01, 2005 Jan 21 (UTC)
So how is that different from what we have now, except that no one will have to scroll back and forth 5 screens to read some text? PRE text will always have a fixed width, and if it's too wide then someone will find it and make it narrower, a sort of evolutionary "survival of the short enough". In other words, a long PRE block can only break itself, and not the whole page. —Michael Z.
That's the point of the autoscroll / overflow:auto. The entire page maintains its normal width, the preformatted text maintains its preformattedness, and it is still accessible in its entirety. I think the overflow:auto is the best solution, but does not work nicely in IE. Still, it could be added to the css and make it nicer for some users. Preformatted text shouldn't wrap, ever. That's the whole point of being preformatted. If text needs to be displayed in monospace, but wrappable, it should not be in pre tags. - Omegatron 16:35, Jan 21, 2005 (UTC)
The browser's scrollbar is always at the bottom of the screen and much more comfortable, especially if there are multiple overflowing boxes close to each other. It allows the user to scroll away the sidebar which isn't possible if inline scrollbars are forced. There are good reasons why browsers don't show scrollbars for pre's inline, please don't mess with it! -- Gabriel Wicke 00:38, 22 Jan 2005 (UTC)
I don't see these good reasons, but ok. If you like it that way. I much prefer an individual scrollbar for the occasional preformatted sections that overshoot the page, so I'm not scrolling my entire browser window while reading, and then trying to find my place again afterwards. Not to mention that the dashed lines walk right over the text in Firefox, which is ugly. Regardless, for people who want individual scrollbars and use a browser besides IE, just add
/* put scrollbar on pre sections instead of ugly cutoff/overlap in firefox */
pre { overflow: auto; }
to your User:username/monobook.css . By the way, this is the way it is done in several forums (such as http://www.linuxquestions.org), to handle preformatted code in threads, which is where I got the idea. - Omegatron 02:20, Jan 22, 2005 (UTC)
In the current case, reading the misformatted text is hard for some people. In the case you propose, reading the text is impossible for some people. Sounds like a regression to me. (What's more, the warning function of text being chopped off is just as strong or weak as the warning function of having a horizontal scrollbar. Both are rather hard to miss and very annoying, I doubt many people who would ignore the latter wouldn't ignore the former too). --fvw* 07:15, 2005 Jan 21 (UTC)
Whe can use pre {white-space: pre-wrap;} for modern browsers (pre {white-space: -moz-pre-wrap;} for Mozilla, IIRC). This will cause intelligent wrapping of pre boxes for people using very low resolutions. MSIE users should upgrade to a browser which is not based on six years old code. User:Anárion/sig 07:59, 21 Jan 2005 (UTC)
Fvw, you're right, it would be a bit more disruptive especially for non-editors, but if a user actually wanted to read the text, instead of spending 10 seconds scrolling horizontally, they may be prompted to take 30 seconds and improve the text.
Anárion, pre-wrap doesn't work in Safari yet, unfortunately, but they have been adding CSS 2 properties regularly. The following block has white-space: -moz-pre-wrap; white-space:pre-wrap; applied. Works nicely in Firefox. Hallelujah to exterminating MSIE/Win! —Michael Z. 2005-01-21 16:44Z
3. It shall be lawful for the Queen, by and with the Advice of Her Majesty's Most Honourable Privy Council, to declare by Proclamation that, on and after the passing of this Act, the Provinces of Canada, Nova Scotia, and New Brunswick shall form and be One Dominion under the Name of Canada; and on and after that Day those Three Provinces shall form and be One Dominion under that Name accordingly.(4) 

4. Unless it is otherwise expressed or implied, the Name Canada shall be taken to mean Canada as constituted under this Act.(5)
And just for reference, here's a scrolling PRE block:
3. It shall be lawful for the Queen, by and with the Advice of Her Majesty's Most Honourable Privy Council, to declare by Proclamation that, on and after the passing of this Act, the Provinces of Canada, Nova Scotia, and New Brunswick shall form and be One Dominion under the Name of Canada; and on and after that Day those Three Provinces shall form and be One Dominion under that Name accordingly.(4) 

4. Unless it is otherwise expressed or implied, the Name Canada shall be taken to mean Canada as constituted under this Act.(5)
Wow, okay I'm confused... but essentially its because CSS2 hasn't been implemented yet in browsers? - RoyBoy [∞] 04:51, 22 Jan 2005 (UTC)
  • In my opinion it is browser due to correctly format the page!! That is the spirit of html!AnyFile 12:05, 25 Jan 2005 (UTC)

Saving fast

Why is page saving suddenly 10 times faster than it usually is? And why haven't I gotten a single deadlock in the last 18 hours? This is unacceptable, I loved those deadlocks. Does anyone know what's going on? This lack of communication between the developers and me personally is a problem that seriously needs to be rectified. -- Anon

  • Hahaha. BLANKFAZE | (что??) 07:41, 21 Jan 2005 (UTC)
  • Hehe, it is pretty pleasant now, shame it's bedtime. I wouldn't have called the situation 18 hours ago "pleasant" though. Still, if this is not just one of those brief oases of excellent response times you insist on taunting us with, well done! --fvw* 07:42, 2005 Jan 21 (UTC)
    • I agree with fvw, if they're going to fix one problem, they may as well have the decency to fix every other problem simulataneously. Now it's just a non-sensical mish-mash of problems and the absence thereof. -- Anon
      • These comments just go to show you that, really, m:anonymous users should not be allowed to edit articles. Also, we need to make the definition of "article" clearer, so that it includes everything. And instead of "anonymous", I would prefer "annoying". But those are minor modifications we can make after establishing the policy. JRM 13:23, 2005 Jan 21 (UTC)
        • No one should ever be censored simply because someone finds them 'annoying'. This shouldn't become a place where only the accepted 'group think' is allowed.  :-) —Mike 02:31, Jan 22, 2005 (UTC)

British users going through Paris squids

Starting from today, British users of the en: wiki will be using caches located near Paris, France (which already serve English, French and multimedia content to users in France, Belgium, Luxembourg and Switzerland). This should improve performance a lot for anonymous users browsing content (especially for frequently accessed content), and improve the situation somewhat for logged-in users. David.Monniaux 14:03, 21 Jan 2005 (UTC)

One of the best headlines I've seen in a while... I was very tempted to add "...film at eleven!"

Convert "--" to em-dash

It would make editing articles a little easier if we could just type "--" whenever we want to place an "—" (em-dash). Just a thought. --Stevietheman 16:05, 21 Jan 2005 (UTC)

There was discussion about this. Someone wrote a script or whatever that automatically converted them, and it didn't work well and the idea was scrapped. I wish it were easier to find discussions... - Omegatron 16:30, Jan 21, 2005 (UTC)
Wikipedia talk:Manual of Style (dashes). —Korath (Talk) 18:15, Jan 21, 2005 (UTC)
I was meaning in terms of ongoing edits, e.g., if I type ~~~~ it will sign my name with a timestamp. I was thinking that if I type two hyphens together, the Wikipedia would automatically display it as an em-dash. --Stevietheman 06:53, 22 Jan 2005 (UTC)
I'm aware. :) It's discussed there, at length. (If you're suggesting it just convert -- for new edits, this'll break whenever a page with -- in it is edited.) —Korath (Talk) 07:15, Jan 22, 2005 (UTC)
But why would you ever have two hyphens ("--") if you didn't mean to type a dash? All I can think of is "----" for a horizontal rule, but that's okay as long as the code converts HRs before dashes. If you absolutely need "--" for some unusual example, just put <nowiki> tags around it. —Michael Z. 2005-01-22 17:20 Z
Yeah. Whatever happened to this? I looked at the discussion, and it seems it was just forgotten about. So what if it messed up the table markup? That is well defined markup. Program around it. Is there anything else it would conflict with? I don't see any other time that --, ---, and ---- would be used except en dashes, em dashes, and horizontal lines. - Omegatron 18:04, Jan 22, 2005 (UTC)
I thought the discussion got off-track with the idea of "--" -> en-dash and "---" -> em-dash. I honestly don't care if a regular hyphen is used in date ranges, as there is hardly any visual difference between a hyphen and an en-dash. Further, I believe most people intend to use the equivalent of an em-dash when they type two contiguous hyphens. --Stevietheman 19:20, 22 Jan 2005 (UTC)
HTML comments. —Ben Brockert (42) 04:27, Jan 23, 2005 (UTC)
While this discussion should probably be kept to the page it's on already (it's amazing how much discussion this tiny issue has generated), I think it's ridiculous to suppose there's some legitimate use for the double-dash that can't be automatically detected in almost all cases. In particular, neither our parsers nor our programmers are dumb enough to automatically convert the double-dash inside HTML comments into mdashes. Deco 04:43, 23 Jan 2005 (UTC)

Another proposal for www.wikipedia.org portal

Please come look and comment and improve on an idea I had for the multilingual portal at www.wikipedia.org -- see Catherine's design. Here's a mockup:

portal proposal
portal proposal

I'd really appreciate some feedback (and help with getting the graphics properly transparent and all). Thanks! Catherine\talk 06:47, 22 Jan 2005 (UTC)

  • I really, REALLY like your design. Especially when compared to what's currently the portal page. BLANKFAZE | (что??) 18:06, 22 Jan 2005 (UTC)
  • I like it a lot. There would be no sidebar, right? - Omegatron 18:08, Jan 22, 2005 (UTC)
  • Looks awesome! --Stevietheman 19:13, 22 Jan 2005 (UTC)
  • I like it a lot Catherine ! Very neat :-) SweetLittleFluffyThing
  • Looks like a proper entry page/cover of a book rather than a hack on monobook. Love it. --BesigedB (talk) 23:21, 22 Jan 2005 (UTC)
  • I like it a lot. However, this design does not work with some khtml-based browsers (Konqueror, though it might work with very recent versions of it, and perhaps Safari). Perhaps an image map would be safer. David.Monniaux 23:28, 22 Jan 2005 (UTC)
    • It works okay (now) for me with Konqueror 3.2.2. Alan Barrett has changed a bunch of the CSS - can you try again with your khtml browser and see if he's fixed things for it too? -- John Fader 15:37, 23 Jan 2005 (UTC)
      • Does not work with Konqueror 3.1, really horrible results. David.Monniaux 21:41, 23 Jan 2005 (UTC)
        • Still working on this -- it won't go live until we get it fixed. Catherine\talk 14:24, 29 Jan 2005 (UTC)
    • No image map for text, please! A table would be preferable to that, but hopefully the CSS can work in all the modern browsers plus MSIE/Win. —Michael Z. 2005-01-23 19:00 Z
      • Have you tested with Safari? I do not see how a table would help - for me, the image map would just be for the logo and 6 texts around. David.Monniaux 21:41, 23 Jan 2005 (UTC)
  • That's really nice. The only thing I would consider is left aligning the "10,000 - 50,000 articles" titles and text below the top part. Beautiful! --Alterego 23:34, Jan 22, 2005 (UTC)
  • Really cool-looking, although it perhaps de-emphasizes the Littlepedias (no differently than the current design does). Deco 04:40, 23 Jan 2005 (UTC)
  • Excellent. Can I suggest you add "background:white;" to the styles for the names surrounding the globe - this way, when the browser window is so narrow that these guys must overlap the globe, they're still legible (sure, it's ugly, but marginally less so than without the background specification). -- John Fader 04:50, 23 Jan 2005 (UTC)
    • Done.
  • Just to chime in - I love it too :) →Raul654 07:53, Jan 23, 2005 (UTC)
  • Me too ;-) And even table-free! -- Gabriel Wicke 11:51, 23 Jan 2005 (UTC)
  • Beautiful!User:Pt/sig 13:26, 23 Jan 2005 (UTC)
  • Wow! :ChrisG 21:47, 23 Jan 2005 (UTC)
  • That's a beauty. Awesome! — Gwalla | Talk 02:05, 24 Jan 2005 (UTC)
  • Very classy - lets go for it Apwoolrich 08:49, 24 Jan 2005 (UTC)
  • Gods Of - aherm... I mean, definitely very impressive. I would suggest adopting at least something like this. Works at least in the Konqueror 3.2.0 I am using - Skysmith 11:51, 24 Jan 2005 (UTC)
  • A truly extraordinary layout! Worthy not only of praise but of a new barnstar (graphicstar) for asthetic achievement in Wikipedia; of which you will be the first recipient, and designer if you wish ;'). BTW why are the edit section links incorrect? I had to click the section below to edit this one. - RoyBoy [∞] 00:04, 26 Jan 2005 (UTC)
  • Big thumbs up from me, too. Very nice design. Grutness|hello? 04:09, 26 Jan 2005 (UTC)
  • In a word: "Scweeeeeet!" Weaponofmassinstruction 04:28, 26 Jan 2005 (UTC)
  • Nice, but dare I ask if it works with links, other text-based browsers, and screen readers? Rhobite 04:34, Jan 26, 2005 (UTC)
    • Work on this is ongoing; we've worked out a few IE/CSS wrinkles and are looking for a little help from a Meta admin or developer in getting the search box set up in the middle of the page -- we're hoping to remove the sidebar. User:AlanBarrett has been working very hard to optimize the design for different browsers, but I don't know about text-based ones yet. If you can help, please comment at http://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_portal/Catherine -- we can use more eyeballs on this one. Thank you! Catherine\talk 06:22, 26 Jan 2005 (UTC)
  • Very well-done! Neutralitytalk 03:17, Jan 28, 2005 (UTC)
  • Excellent work. That's very nice! -SocratesJedi | Talk 18:34, 28 Jan 2005 (UTC)
  • It's attractive now, but as more languages reach the 50,000 article threshold, it's going to get more and more crowded around the globe. And it implies an elitism that shuts out the languages that cannot hover around the globe. GUllman 21:58, 28 Jan 2005 (UTC)
    • This design allows for the top 10, whatever the numbers may be (some are currently below 50k). What sort of design do you envision that would allow for continuous expansion? Catherine\talk 14:24, 29 Jan 2005 (UTC)


Please note, Marcika has started a vote on whether to make this design the live one -- vote ends February 11. It might be a little early since we haven't yet worked out the Konqueror 3.1 bugs, but I think that's a temporary stumbling block, not an idea-killer. Please come offer your comments and opinions at the polling place. Thanks! --Catherine\talk 14:24, 29 Jan 2005 (UTC)

a section edit at the intro para

i guess that would be helpful. sometimes i want to modify the intro para, but i have to load the whole article. just think if the article's long enough and the speed's sucking enough...... --User:Yacht (talk) 06:11, Jan 24, 2005 (UTC)

Yes yes! Very good idea. - Omegatron 14:52, Jan 24, 2005 (UTC)
Yes, I would appreciate that too. For some reason I feel more secure if I'm just editing a section. But I hear that editing the whole article is faster than just a section. Go figure. —Michael Z. 2005-01-22 16:54 Z
Workaround: open the first section, and then change &section=1 to &section=0 in the address bar of your web browser as here. User:Anárion/sig 17:02, 24 Jan 2005 (UTC)
Yeah, that's a workaround but it should still be implemented. - Omegatron 17:44, Jan 24, 2005 (UTC)
I have thought about that several times. Such a feature would be very helpful.User:Pt/sig 22:19, 24 Jan 2005 (UTC)
I compleately agree!! AnyFile 12:04, 25 Jan 2005 (UTC)
YesYesYes. Especially for those of us still working with browsers whose editing behavior is -- ahem -- less than optimal. -- Antaeus Feldspar 18:49, 25 Jan 2005 (UTC)
Pleeeease? With strawberry icing on top???? It's an even bigger problem with talk pages (including User talk pages), where you don't have the option of editing the whole page (again you have to kludge it by opening section 1 and changing the "1" to "all". (Being able to directly edit an entire talkpage - even if only your own user talk page - would be another Good Thing [tm]). Grutness|hello? 11:45, 27 Jan 2005 (UTC)

Shell

hello,

hello. m new to unix. could anybody tell me why do we always boot up in KDE when we start the Fedora. Even if we make bash shell as a default shell, it is always seen when we open the terminal session.

hi. in the apple menu, select system preferences. then click accounts, and choose the startup items tab. uncheck KDE and close the window. And it's a good idea to restart while holding the clover and option keys, to rebuild the desktop.
KDE has an apple menu? Doesn't Apple Computer have that trademarked? — Gwalla | Talk 17:52, 24 Jan 2005 (UTC)
Just a little joke for old Mac users. I found it amusing that someone was asking for operating system support here. —Michael Z. 2005-01-22 16:54 Z
To give a serious answer, I suspect your answer has to do with the runlevel of the system. Probably a script that automatically runs at startup tells the computer "these guys want to run at level 5!" and other scripts tell it that KDE is the graphical manager you want to use when running at level 5. Which scripts, specifically? And how do you change those scripts? That, I'm afraid, is something I don't know. -- Antaeus Feldspar 18:47, 25 Jan 2005 (UTC)

I assume that you want your system to boot to a text-mode login, not to a graphical login. You need to edit the file /etc/inittab (You'll need to be root to do so), and change the line which looks like this: id:5:initdefault: to id:3:initdefault:. This should work on almost any Linux system. On most, the /etc/inittab file has a comment on what that number means, but you can also look at runlevel as a previous user commented.

If I am assuming wrong, and you want to boot not to KDE but to a different window manager such as Gnome, there should be a pull-down on the login screen which gives you that option. Sorry, but I'm running Mandrake at the moment, and my Fedora machine isn't plugged in, so I can't describe it to you in detail. If you are automatically logged in, so you don't see the login screen at all, post again here and someone will step you through in more detail.-gadfium 21:30, 25 Jan 2005 (UTC)

Stub threshold

Is there any news on the old stub threshold/purple link feature? Is it coming back? Tuf-Kat 03:19, Jan 25, 2005 (UTC)

  • I didn't know it was gone. BLANKFAZE | (что??) 03:58, 25 Jan 2005 (UTC)
    • It's been gone for me since the 1.4 upgrade. Skin issue maybe? Antandrus 04:04, 25 Jan 2005 (UTC)
      No. The devs deactivated it because it's bad for performance — basically, checking each article's size against the user's prefs just to know how to render the link is effort better spent on something else. I also believe they were sort-of hoping nobody would notice. :-) If you really can't live without it, try contacting the devs; ideas have been tossed around for improving this, but don't hold your breath. JRM 12:11, 2005 Jan 25 (UTC)
      If showing stublinks as a different color degrades performance, I'm absolutely fine not showing stublinks. Anything that improves performance gets my Yea. Antandrus 03:17, 26 Jan 2005 (UTC)

Funny thing. I was just blathering on about this idea over on Edit_Display_Mode_for_links. I can understand the performance issue, but had wondered about simply checking for templates. If the article has a stub or disambig template inside, could the link show up as a different color? (thanks Omegatron) Just using the templates might sidestep the issue of checking file size, etc. --Bookandcoffee 20:46, 25 Jan 2005 (UTC)

No, because this would just require an even more arduous check for whether such a template is included in the article, or conceivably a category check (which might be faster; I don't know the DB structure). The central problem of every link requiring a check and a potential update on every rendering seems to remain. Except for checking whether an article is there at all (redlink), any rendering decision based on the article contents is slow. But I'm not a dev, so I might be speculating out of my arse here. :-) JRM 14:21, 2005 Jan 27 (UTC)

Welcome templates

I'm just wondering: I just created a couple of welcome templates for new users and placed them in my username subspace - {{User:Asbestos/Welcome}} and {{User:Asbestos/Welcome2}}. This seems to work fine. However, I noticed that some other users seem to have their personal welcome template in Wikipedia's template space, e.g. Template:Infrog welcome. Which is standard usage? Does it make a difference? And can just anyone put just anything in WP's template space? Thanks! — Asbestos | Talk 11:08, 25 Jan 2005 (UTC)

It's as standard as you want it to be (i.e. nothing is compulsory). See the (somewhat sinister sounding) Wikipedia:Welcoming committee and (much nicer) Wikipedia:Standard user greeting. -- John Fader 17:37, 25 Jan 2005 (UTC)
Thanks! — Asbestos | Talk 18:16, 25 Jan 2005 (UTC)

Using CSS to change default font to Arial Unicode MS

I'm trying to achieve something reasonably simple (I think) which is to make "Arial Unicode MS" the default font. I've added something into User:Muntfish/monobook.css but it doesn't seem to have the required effect (yes I have emptied my cache etc). Articles with unusual characters (archaic Cyrillic letters such as Fita) still don't display properly. Any assistance would be appreciated. I'm using MS IE 6 by the way (yes, I know, get Firefox, but that's not an option here...) Thanks. munt fish 12:33, 2005 Jan 25 (UTC)

You forgot to quote the font string (which you must do since it contains spaces), and the selector html>body does not work in MSIE due to its many bugs. Use instead:
body {font-family: 'Arial Unicode MS', Arial, Helvetica, sans-serif;}
hth, User:Anárion/sig 12:46, 25 Jan 2005 (UTC)
The Wiki engine messes up single quotes in font declarations; turns them into ( \' ), which doesn't work (for me). The quotes are recommended by the specification, but they are not required as long as the only whitespace in a font name is single spaces.
  1. Try waiting a day. No matter how much I purge and refresh (oh, the imagery!), I find that my monobook.css seems to stay cached at Wikipedia for a while.
  2. I haven't looked, but maybe you need a more specific declaration. Try one of the following:
 body { font-family: Arial Unicode MS, Arial, Helvetica, sans-serif !important; }
 
 div#bodyContent { font-family: Arial Unicode MS, Arial, Helvetica, sans-serif; }
 
 div#bodyContent { font-family: Arial Unicode MS, Arial, Helvetica, sans-serif !important; }
—Michael Z. 2005-01-22 16:54 Z
Thanks Michael, that got it. I had already tried with and without quotes on the font name (without success) -probably should have mentioned that first time round. I figured it would be something to do with the selector, but didn't have enough wiki knowledge (or time to delve into the CSS) to know what to change it to. munt fish 13:08, 2005 Jan 26 (UTC)

Database query syntax error

I had the following error today, at 9:46:14 AM CET (8:46:14 AM UTC) 

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

   SELECT cur_id FROM `cur` WHERE cur_namespace='2' AND cur_title='Sam_Hocevar' LIMIT 1

from within function "LinkCache::addLinkObj". MySQL returned error "2013: Lost connection to MySQL server during query (10.0.0.2)".

The requested URL was http://en.wikipedia.org/w/index.php?title=Fritz_Haber&curid=174645&action=history . Since it is related to the history, it might be related to the known problems with it, but since I didn't see this mentioned, I thought I add it, in case it might help tracking down the problem.

--S.K. 18:25, 25 Jan 2005 (UTC)

Numbering indent

Is there a way to use the numbered list and disable the default indenting? My goal is to provide more room for the text in the list on Kashan. Obviously doing the numbers manually would work, but someone would likely come by and wikify it again. - RoyBoy [∞] 23:54, 25 Jan 2005 (UTC)

Not really (well, there is, with scary CSS, but please don't do that). You'd be much better off distributing the images more evenly. One thing I would do on Kashan is to ditch the number list altogether, and either just have the sections as paragraphs or make them sections (===) in their own right. Spread the images around, maybe make the thumbnails a bit smaller, and all should work well. Make sure to check with your browser narrowed (ideally to 800 pixels wide) to make sure your new layout doesn't go bonkers when viewed on a small screen. -- John Fader 00:11, 26 Jan 2005 (UTC)
  • I don't see an obvious reason why you couldn't use an unnumbered list which may have a smaller indent. Either way, it is always good to remember that there are multiple skins (and some people have their own skin) for Wikipedia. If we all started hard-coding CSS styles, the Wikipedia becomes less flexible for the skins. —Mike 04:03, Jan 26, 2005 (UTC)
Why are those numbered? Unless you're indicating the order they were built, or making a map key, there doesn't seem to be any significance to the numbers. —Michael Z. 2005-01-22 16:54 Z

Standards for tables

I'm a big fan of tables, for far too many reasons to bother to write out. So I find myself confused when I go looking for the recommended way to do tables in the Wiki.

If I punch "Editing help" at the bottom of an editing page, I'm quickly taken to this section, which tells me there's two ways to do tables. Good. When I follow the link, I find descriptions for three ways of doing tables. Hm. There's also a second link with some more information, but also a lot of overlap. Also, I'm not finding these pages very well organized, just from the way the thoughts are organized. I'm not complaining too much, because I don't want someone to say "Be bold! Re-write them yourself!" :-)

Reading these pages, I see that for tables the Wiki supports XHTML (which to me means HTML 4.01), and HTML (which might mean the HTML3 Table Model or the HTML4 Table Model), and the Wiki pipe format (which seems quite nice to me). But I also see that not all of the HTML contstructs are supported. And there's lots about elements, but very little about permitted attributes of those elements.

Is there a complete and correct page devoted to what is supported and unsupported in tables, in each of the two or three available ways? I like the pipe format a lot for most tables (simple and easy for others to maintain), and I'd prefer XHTML for some tables (powerful, verifiable, and cut-and-paste-able to other documents). I'm hoping there's an article I've missed as I was trolling through pages.

DanielVonEhren 00:53, 26 Jan 2005 (UTC)

The wiki (pipe) syntax is a relatively new feature in mediawiki, and so lots of legacy tables are still left using HTML markup. Ideally these will all eventually end up being changed to the pipe syntax. Even more ideally, someone will write a bot that does it automatically. Anyway, the most definative documentation should be m:Help:Table. -- John Fader 01:01, 26 Jan 2005 (UTC)
...which doesn't really answer your question, meaning I think that "it's not documented". It does show that someone has written the bot I wanted, however. -- John Fader 01:03, 26 Jan 2005 (UTC)
Can someone please at least comment on my table editing proposal?  :-) I even made examples! I don't care if you say it's stupid; just say something...
Wikipedia:Village_pump_(proposals)#External_table_namespace - Omegatron 01:27, Jan 26, 2005 (UTC)

Redirects

How about the software identifying wiki-links-to-redirects automatically, in the way it already does wiki-links-to-nowhere (it changes to ...edit)? This would help avoid unnecessary redirects. Just a thought... Rd232 00:59, 27 Jan 2005 (UTC)

But the redirects are important. They let Google know that e.g., the text of the page titled "East Germany" is also relevant to "German Democratic Republic", "GDR", "Deutsche Demokratische Republik", and "East German". Google considers page titles and text in the URL. —Michael Z. 2005-01-22 16:54 Z
Not sure whether you've misunderstood me, or you're suggesting a reason not to resolve redirects which I've not heard before. I meant changing A link that points to a redirect X to A link that points directly at the ultimate target Y, which would be easier if redirects were identified on the page with the wikilink. I wasn't proposing to abolish the redirect page which links X to Y. I thought such standardisation/avoidance of unnecessary redirects was policy. Rd232 08:26, 27 Jan 2005 (UTC)
Right. Google considers both the link text (which in your example will read X), and the URL (which will also read X, unless the link is adjusted as you suggest, then it would read Y). Google has to know that both the names X and Y are headings for the article. Or else searches for X wouldn't work as well as searches for Y.
If you look at Google search results for "German Democratic Republic" on Wikipedia, you'll see that the East Germany page shows up several times at different URLs. This shows that Google sees all those names as being associated with the same text.
If all of the links to GDR were changed to links to "East Germany", then searches for GDR would be less likely to show the East Germany page, or at least show it further down the list. —Michael Z. 2005-01-27 09:32 Z

Old user contributions

Today I wanted to look up the contributions made by one Wikipedian several months ago. Unfortunately, the Wikipedian in question is a prolific writer, so I had to wade back some 2000 edits in their contribution list to find the work I was looking for. Is there any way of looking up, say, "Contributions by User:X up to October 31, 2004" (picking a date at random here), and if so, how? If not, is there any way of adding this feature to the system? Grutness|hello? 05:50, 27 Jan 2005 (UTC)

It won't help you at the moment, but admins can run read-only queries against the database. If you know SQL, that would be the way to go.-gadfium 06:15, 27 Jan 2005 (UTC)
Actually admins can't do SQL queries any more. Ask a developer, such as User:Jamesday, why this is so. - Mark 09:19, 29 Jan 2005 (UTC)
It would help if there were a search box on the contributions page and history pages, like there is Special:Log/delete. — Asbestos | Talk 10:32, 27 Jan 2005 (UTC)

Display images from another wiki

Is there a way to display an image from Wikipedia on Wikisource? I can't figure out the exact syntax. Thanks. --brian0918&#153; 16:41, 27 Jan 2005 (UTC)

Can't do it. Commons images can be displayed elsewhere, but otherwise there's no interwiki access to images. Have to download it from one and upload to the other. -- Jmabel | Talk 18:50, Jan 27, 2005 (UTC)
Or even better, download it from one and upload it to commons. -Aranel ("Sarah") 20:15, 27 Jan 2005 (UTC)

Mechanism for long articles over 32K? User-selectable page maximum? Autosectioning?

The Encyclopaedia Britannica, 11th Edition, has at least one article—on the Bible—which is over one megabyte in length. Wikipedia is not paper, but Wikipedia is not the Britannica 3 Micropaedia, either. Or shouldn't be. The fact that Wikipedia is not paper should be liberating, not restricting.

Is there a technical fix? What I have in mind is a mechanism that allows the article itself to be as long as desired, within reason, but has a mechanism on top of it for breaking it into chunks of any desired size. The chunks would be based on any existing sections, plus automatic mechanisms for splitting sections longer than the page size, and combining sections if several will fit on one page.

Suppose you have a User Preference for a maximum page size of 32K. Suppose you have an article consisting of sections a=8K, b=8K, c=8K, d=16K, e=2K, f=80K. When you open the article, it displays just the Table of Contents... with part f displayed as "part f-page 1, part f-page 2, and part f-page 3," followed by sections a, b, c, and a "Next Page" link. Click on "Next Page" and you get parts d and e. "Next page" gets you page f, part 1; then page f, part 2; then page f, part 3.

Someone with a maximum page size set to 200K gets the whole megillah (well? isn't that an appropriate word here?) on a single page.

Or something like that. Dpbsmith (talk) 19:53, 27 Jan 2005 (UTC)

Is it really a problem? Old browsers will disappear and eventually it will never be a problem, except for the user who has to load and read and overview a very long page.
Also, I think the size recommendation is a good thing to encourage Summary style; we have an implied recommendation to break down articles and summarize those in sections. This benefits the reader. ✏ Sverdrup 23:21, 27 Jan 2005 (UTC)

Entry Templates

I'm using a wiki for an internal product development knowledge base where I work. As the prospective users are not yet familiar with wikis and I would like to maintain some semblance of order, it would be nice to have templates for certain types of articles that could be automatically loaded into the edit window without having to use subst: followed by a save, followed by an edit.

What would be optimal is to use a web form (within the wiki) to collect the basic data (article name, too) and then create the article with all the formatting that they can then edit further. It would appear to get this done will require some wiki hacking, but are there any examples of this out there that I can take a look at?

Also, is there a better place to ask this question? I've looked around the Meta site, but couldn't find an appropriate place there. —BradleyEE 21:14, 27 Jan 2005 (UTC)

Try asking at http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

Firefox compliance

I've been using Firefox more often because of its multitasking ease... however I routinely notice Firefox has some minor bugs on how it interprets Wikipedia... like here, @ 800x600 text is overlapped a bit by a picture. Should I bother fixing that, or should I wait for Firefox to debug? - RoyBoy [∞] 00:57, 28 Jan 2005 (UTC)

Looks fine in my Firefox (Mac) and Safari, at various window widths. Can you describe exactly what overlaps? —Michael Z. 2005-01-28 15:20 Z
The Wikipedia site is basically written to be compliant in modern browsers like Firefox because the entirety of the site is written in CSS. There are not a whole lot of people who still run 800*600 resolutions, or at least not as many as that run 1024*768 or higher. Therefore you'll find a lot of sites that don't look as well in lower resolutions. BLANKFAZE | (что??) 17:12, 28 Jan 2005 (UTC)
I simply fix pages that aren't 800x600 compliant. Here is the problem, it is a bug that I've seen routinely. One of several bugs involving pictures that I've noticed since switching from IE6. - RoyBoy [∞] 17:21, 28 Jan 2005 (UTC)
This seems to be happening when the margin of the "Swiss balls" floating box on the right pushes the "bench press" box down from the top of its paragraph, only at certain window widths. In Firefox/Mac the top of the box touches the content area of the line of text, giving about 2px clearance below the descenders. In Safari it touches the bottom of the leading, giving about 5-6px clearance. This looks like a browser quirk at the level of system-specific text rendering. It may be possible for a developer to trouble-shoot the style sheets to work around this, but it may be a lot of work for little benefit.
Are you using Firefox 1.0? If you narrow the window further, does the box's top-line always go through the middle of a line of text, or does it float down pixel-by-pixel? —Michael Z. 2005-01-28 17:54 Z
Now you're talking. Yes 1.0, no floating pixel-by-pixel... it simply wraps normally and is eventually is shoved to the side by the above paragraph when expected, but always cutting text in the middle until then. - RoyBoy [∞] 18:28, 28 Jan 2005 (UTC)
The floating div has class="thumb tleft" applied. The following style sheet rules apply [3] (among others). Weird thing is that border-width. (too bad the style sheet won't validate) —Michael Z. 2005-01-28 19:29 Z
div.tleft {
   float: left;
   margin-right:0.5em;
   border-width: 0.5em 1.4em 0.8em 0;
}

div.thumb {
   margin-bottom: 0.5em;
   border-style: solid; border-color: White;
   width: auto;
}
div.thumb div {
   border:1px solid #cccccc;
   padding: 3px !important;
   background-color:#f9f9f9;
   overflow: hidden;
}
div.thumb div a img {
   border:1px solid #cccccc;
}
div.thumb div div.thumbcaption {
   border: none;
   text-align: left;
   line-height: 1.4em;
   padding: 0.3em 0 0.1em 0;
}

Sweet Jesus on a snow-mobile! As a programmer I should have learned to be more curious, maybe I'll reinstate the view source button on my toolbar. Oh... Firefox doesn't have one! Sacrilage! Thx Michael, your going on my User list! :'D And if you know anybody over at Firefox, tell'em to put in a view source icon. And on a personal note, wouldn't 1.1em look a little sleeker, a little sexier on the left-right margins? Yaknow, us poor 800x600 boys only have so much to work with here. - RoyBoy [∞] 22:11, 28 Jan 2005 (UTC)

push Ctrl + U or go to View > 'Page Source' or press Alt, v, o. --Alterego 02:28, Jan 29, 2005 (UTC)
Thx, came across that after my frustation with the toolbar customizer, but doesn't look as pretty as an icon. Firefox's parsing of the source with color is a nice touch though. Friggin Microsoft being lazy. LoL! Zest... nice touch to the soapbox. - RoyBoy [∞] 02:43, 29 Jan 2005 (UTC)

pounds per square inch of air pressure vs foot pounds of torque

Question: Is there a formula to convert PSI to Foot lbs of torque or force? Example: If 90 psi is applied to a pnuematic strapping tensioner how many foot lbs of torque would have to be applied to a manual tensioner to achieve the same tensioning results? Could this also be measured as Units of Force? John Fredrickson @ [email protected]

You need more information; what is the 90psi acting on (for example, a pneumatic cylinder one inch in diameter will produce a force of pi r^2, about 70 pounde of force). So if you know the dimensions of the pneumatic cylinder you can calulate the force that 90PSI creates. For torque you need the moment arm; force * lever length = torque.

SQL Queries

When will SQL queries be reinstated to admins? Raul654 told me that it is permanently disabled but obviously he is joking, since that would represent an agglomeration of developer powers in a situation where developer numbers are decreasing. If the SQL queries are not going to be reinstated in the next few days, then I need a developer to construct and run a query on my behalf listing all images I have uploaded to Wikipedia (some may be listed under my old username "Mark Ryan"), so I can go through and tag them to ensure they don't get deleted in the Big Purge of unverified images. - Mark 09:37, 29 Jan 2005 (UTC)

As a workaround, search [4] for "image:". --SPUI 09:52, 29 Jan 2005 (UTC)
Thanks :) That solves my problem for now, but still, when will SQL be back? Not all queries can be easily replicated by the software in this manner. - Mark 09:57, 29 Jan 2005 (UTC)
He's not joking. They've been disabled for a very long time because a single poorly written query run on the live servers can bring the whole site to a grinding halt. -- Cyrius|✎ 15:16, 29 Jan 2005 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=9764973"