Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

Village pump technical   post
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla. Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.	Shortcuts: WP:VPT WP:VP/T
edit Frequently Asked Questions (FAQ) (see also: Wikipedia:Technical FAQ) Click "[show]" to the right of each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use Javascript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See b1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences. No, we will not add a spell-checker, or spell-checking bot. For spell-checking what is in the edit box, you can use a web browser like Firefox, which includes such spell checking. If you have problems making your fancy signature work, check Wikipedia:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. Also, it's surprisingly common for people to accidentally block the image server (upload.wikimedia.org) on Firefox. If the section edit links are being pushed down by floated images, check Wikipedia:How to fix bunched-up edit links. Problems loading the edit page: If you are asked to download a file (index.php) when trying to edit, or your browser launches an image editor when trying to edit, disable "Use external editor" on your MediaWiki user preferences. On the most recent version of MediaWiki (as of 21-May-2007), this is found under the "Editing" tab. Some ISPs use transparent proxies which cause problems logging in. If you find that you are automatically logged out just after you have logged in, and removing all your Wikipedia cookies does not fix the issue, try using the secure server (much slower) to bypass the proxy. This happens most often with some satellite ISPs (particularly HughesNet/DirecWay/DirecPC). Numbers listed in parentheses in the "Recent changes" section and in your watchlist are the number of added or removed bytes. Questions and suggestions related to www.wikipedia.org portal should go to Meta.
Please sign and date your post (by typing ~~~~ or clicking the signature icon: in the edit toolbar). Please add new topics to the bottom of this page.
« Older discussions | Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68

Centralized discussion
Proposals	Discussions	Recurring proposals
Proposal to require new users to have autoconfirmed status to create an article Proposal to rename Articles for Deletion to Articles for Discussion, include the discussion of mergers. Proposal for targeted flagging. Petitions to turn on, and not to turn on, the Flagged revisions extension. Discussion on adding language about schools to the organization notability guidelines. Proposal on creating a "Book" namespace. Discussion regarding the spam blacklist and reliability of sources Discussion of "self-promotion and indiscriminate coverage" in the Notability guideline. Discussion on retaining the restriction against using the string "bot" in usernames. Discussion on CfD speedy renaming criteria 6 (disambiguation fixes from an unqualified name). Discussion on refining Community de-adminship (aka Admin Recall) to formalize a RfC. Proposal for achieving infobox-template coherence of properties in Wikipedia(s) Discussion on promoting Wikipedia:Notability (academic journals) to guideline status Note: inactive discussions, closed or not, should be archived.
archive • talk • edit • history • watch

e · h · w · r  To-do:

[edit] Special:Notepad

I would like to see Special:Notepad be a private scratch-pad, possibly visible to privileged users, intended for people to keep working notes that aren't meant for the public eye. It's easier for me to keep my wiki-related notes on Wikipedia than on, say, a Google application or a local document, but I don't always want the public access that an on-wiki page has.

I'm not picky if this is a Special: page, a part of Preferences, or a user:-space page that is not readable to unprivilaged users. I'm soliciting feedback on the general concept of "private" space within Wikipedia.

Before I open a bug/feature request, I wanted some feedback. davidwr/(talk)/(contribs)/(e-mail) 21:26, 14 December 2009 (UTC)

For what it's worth, you can use the watchlist token for storing very very short notes to yourself, such as a tinyurl or something similar. davidwr/(talk)/(contribs)/(e-mail) 21:30, 14 December 2009 (UTC)

I support creating a private development space visible only to the user and to admins. A protected branch of user space feels most natural to me. It would allow user space content development without arguments about google indexing or the inappropriate use of nonfree content. As long as admins can see it, we can still avoid the worst problems of WEBHOST. Dragons flight (talk) 03:13, 15 December 2009 (UTC)

bugzilla:541#c2. --Splarka (rant) 08:19, 15 December 2009 (UTC)

I have a lot respect for Brion, but he is not employed by the WMF any more, and even when he was employed I'd like to think that he could generally be swayed by the desires of the community. Rather than simply referencing an old comment, could you actually give an opinion on the merits? If the primary concern is the use of private space for non-wiki activities, there are relatively easy ways to mitigate against that. Dragons flight (talk) 11:19, 15 December 2009 (UTC)

I support this. I'm not sure why admins would need access though. I'd rather limit access whereby admins can delete the space (for indef blocked users, for example), but not actually view it. I'd like to hear why people think admin access should be necessary. If they do need access, I'd like to see some strict rules about when it's appropriate to do so; namely that it almost never is, and perhaps implement a system to publicly log each viewing. For me, a private scratchpad would be useful, among other things, to store thoughts on disputes, other issues, and comment wording I plan to use in the future. Being that admins are also regular users who could be involved in those disputes, I wouldn't want them rifling through my stuff to gain an upper hand. Equazcion ^(talk) 11:39, 15 Dec 2009 (UTC)

If you've run out of dead trees, you could always use Google Docs or similar. Wikipedia is for collaborative work, not private notes. OrangeDog (τ • ε) 13:49, 15 December 2009 (UTC)

I can think of about 100 Wikipedia features that don't fit that definition. Wikipedia is for collaborative works as well as any tools that help editors accomplish that goal. As for the need for this particular one, versus using other text editors, it would help to be able to save and view notes specifically via mediawiki code and rendering. Equazcion ^(talk) 13:55, 15 Dec 2009 (UTC)

It's not necessary that admins can see it but if it's known that someone can see it, whether that someone is a small group like oversighters or a larger group like admins, it can help deter abuse or the perception of facilitating abuse. Your comments on admins needing to not examine them due to privacy or wiki-privacy issues are well noted. I imagine this had been available 2 weeks ago numerous editors would have used it to record notes related to the recent elections. davidwr/(talk)/(contribs)/(e-mail) 14:18, 15 December 2009 (UTC)

I'm not sure what kind of abuse could be perpetrated though, with a private space no one can see. If you personally attack someone there, who's gonna know, and why would it matter? The only possible damage I can see being done by allowing the space to be entirely private is some kind of technical hack; and on a page that can only be rendered by one account, it's doubtful any technical attack could actually be perpetrated. Equazcion ^(talk) 16:42, 15 Dec 2009 (UTC)

It could be used as a communications network by terrorists? –xeno^talk 16:46, 15 December 2009 (UTC)

Well, so could GMail, and it would be easier to use, too... ╟─TreasuryTag►ballotbox─╢ 17:06, 15 December 2009 (UTC)

Good point. I was focused on abuse of Wikipedia rather than laws. I can see the need for admin access, but would then like to see strict rules on viewings, and have those viewings publicly logged, so they can't just go in and read people's private notes on a whim. Equazcion ^(talk) 16:50, 15 Dec 2009 (UTC)

I'm struggling to figure out what the use case for this would be. What kinds of private data are users working with that they would need to store it on Wikipedia (meaning it should be somehow Wikipedia-related)? Mr.Z-man 19:05, 16 December 2009 (UTC)

And why can that private data not be stored in a file on their own computer? Anomie⚔ 03:31, 17 December 2009 (UTC)

Hit lists? –xeno^talk 14:32, 17 December 2009 (UTC)

I can imagine things for which one really would want privacy for the sake of privacy, such as evidence for Arbcom, sockpuppet investigations, copies of off-Wiki correspondence relating to on-wiki work, etc. Other things could be made private because a user wants to work on them but they don't really belong on Wikipedia in their current form, such as various deleted pages. However, the main use I would see is in drafting. I don't know about you, but I find it embarrassing when people stumble across half finished pages that I have started to write. Unfinished content isn't really suitable for placement in article space because it is incomplete, and even in user space they can be found my looking at contribution lists or in some cases even by Google. Reluctance to show the world incomplete works is enough of a deterrent to me personally that I often avoid drafting new content on Wikipedia itself, but writing offline drafts means that I don't have easy access to seeing how the page will look. Do we need a private space for drafting? No. Obviously we can function without it. But at the same time I think it would be more friendly and convenient to have such a space. Dragons flight (talk) 14:58, 17 December 2009 (UTC)

Working in secret with no collaboration isn't very friendly. It could also lead to WP:OWNership issues. OrangeDog (τ • ε) 20:04, 18 December 2009 (UTC)

I honestly find this comment somewhat offensive. On the occasions when I work up new things from scratch, which admittedly isn't very often, I prefer to see that they are complete and somewhat polished before letting the world see and rewrite them. I care about the quality of my work, and unlike some Dogs, I have a real world persona linked to my account. If you prefer that every rough draft and scribble you write be public, then fine for you, but I think it's wrong to pretend that other Wikipedians don't sometimes want to write drafts in private before submitting text to Wikipedia. Dragons flight (talk) 20:25, 18 December 2009 (UTC)

No offence meant. I'm simply pointing out that this is an "encylopedia that anyone can edit", where "all ... content is edited collaboratively", where every edit (including this one) is "irrevocably" released under CC-BY-SA 3.0 and the GFDL, and "if you don't want your material to be edited mercilessly, don't submit it here". I just don't see how hosting private user content is compatible with this, nor what the problem is with storing private information somewhere other than a high-traffic public website. OrangeDog (τ • ε) 21:34, 18 December 2009 (UTC)

I have no strong feelings about this. I counsel folks to not write drafts of contentious user/project related things on wiki, because it generates more drama than necessary and may cause other problems (unfinished RfCs could be seen as threats, user conduct scratch pads have been interpreted as hit lists in the past, etc.). At the same time, Google docs, a regular text editor, or any word processor works fine for this. I can't imagine pushing strongly for some new feature which is wholly duplicated by so many existing external products, seeing as the primary need to have it "on-wiki" is gone when the space becomes private. Protonk (talk) 07:09, 20 December 2009 (UTC)

I could have good use of a private scratch-pad. I have my to-do list and notes off-wiki. But that means I don't have access to my notes when I am at my girlfriend's house, so then I can't do the work I do here. I know many Wikipedians who edit from different computers at different places.

Some of the reasons why I can't have my notes on my user page are these:

• Lots of people are watching my user page. When I have noted on my user page things I am planning to do, people have started to ask about it. Before I have even thought enough about it myself and written down any explanations.
• As soon as I add a link on my user page to a new template I am building people come there and start using it and questioning it, before I have even finished coding it and before I have documented it.
• I have notes about vandals I am investigating.
• I have notes about security problems in MediaWiki...

An on-wiki scratch pad could also have the benefit of having working wikilinks, something a text file on my hard disk or on some other server doesn't have.

I think that the personal scratch-pad needs to be visible to some users, for instance admins. Since otherwise people will use it to store any amount of text for other non-Wikipedia uses. (And it would be nice if the scratch-pad displayed a list of who had viewed it lately.) And the scratch pad probably should have some size limitation.

--David Göthberg (talk) 23:56, 23 December 2009 (UTC)

[edit] asae38hfhue

So, I noticed some characters flickering up as page source is rendered some time back, notably at the end of each blank line of long templates. Eventually I managed to capture them, they can be Googled to show that they have a strong link with WP but that's about it. Any ideas? Rich Farmbrough, 21:43, 20 December 2009 (UTC).

Can you be more specific? Where exactly are they appearing? Isn't the whole string similar to UNIQ28cf615b3f10792f-nowiki-0000000B-QINU? If yes, that would mean they are strip markers (whatever that means), see bug 17329http://bugzilla.wikimedia.org/show_bug.cgi?id=17329. Svick (talk) 22:22, 20 December 2009 (UTC)

@Rich: Huh? First you insert these characters [1], a day later you remove them again [2], and then nearly three weeks later you ask about their meaning here? (This article is the only pertinent Google hit for this character sequence, and then only on some external site that somehow has the first diff as an HTML page.) What's up? Lupo 09:09, 24 December 2009 (UTC)

[edit] Remove the "edit summary is too long" before saving

For example, a recent post of mine was "::::This seems to be pretty OK (like the one similar to this). Although the "He served 1939–1941" example needs to be thrown out and something saner picked instead. It seems essentially to be status quo + allowing for "Seifert–von Kampen". Which is much better than the status quo. ~~~~", which I copy-paste in the edit summary since the beginning of a post is a very quick way to summarize the post. However, this is longer than that 255 character limit (or whatever it is), changing the edit summary box in red as a warning (fine), and preventing me to make my post until I fixed the length (horrible!).

PLEASE revert to the old behaviour of simply truncating the summary (the warning is fine and should probably stay). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 16:45, 21 December 2009 (UTC)

I don't experience that problem, for me it just truncates and never gets red, just as usual.

I tried the Gadget "Allow up to 50 more characters in each of your edit summaries" but that doesn't cause it.

I also tested to use the beta version of Wikipedia. (See upper left corner of page "Try beta".) But that doesn't cause it either.

My guess is that it is one of the scripts your are loading in your User:Headbomb/monobook.js. Try remarking them all away, then wait one minute, then bypass your browser cache. I bet that your problem will be gone then. Then you have to add them one by one to figure out which it is, then contact the author of that script.

--David Göthberg (talk) 00:39, 24 December 2009 (UTC)

[edit] Fast switch between monobook and vector skin

Is it possible to switch between monobook and vector skin by just one or two mouseclicks? The way via “Try Beta” or "My preferences" is too long. --Leyo 09:25, 22 December 2009 (UTC)

You can change your skin temporarily by appending ?useskin=vector or ?useskin=monobook to the URL, but as soon as you click a link, you have your old skin back. Svick (talk) 12:04, 22 December 2009 (UTC)

You could write a script that gives you a button or link to do this. OrangeDog (τ • ε) 13:13, 22 December 2009 (UTC)

Thanks for the replies. I have been aware of the option suggested by Svick, but I would like to keep one skin till I click again. I was actually thinking of a script, but unfortunately I am not able to write such a script myself.

The main goal of the fast skin switch is to quickly enable/disable scripts/gadgets imported to these skins. --Leyo 16:28, 22 December 2009 (UTC)

Why switch skins for that? Better use a control that sets/unsets a cookie, and then you can conditionally load (sets of) scripts based on that. No need to switch a skin for that. —TheDJ (talk • contribs) 19:59, 22 December 2009 (UTC)

I tried something similar (on my de-WP account), but without success. Unfortunately, I am a beginner in JS. --Leyo 08:38, 23 December 2009 (UTC)

You can use another user account for that. And then access that account from a second browser.

Or you can use the secure server to access the second account. That lets you use different tools in different tabs in the same browser at the same time, since you can then run two different user accounts at the same time from the same browser.

To set that up do this: Open a new tab in your browser, go to Special:UserLogin, choose the secure server, create a new user account say "Leyo2". Then add whatever tools you want to that user account. Then when you use Wikipedia you can log in as Leyo to the normal servers, and as Leyo2 to the secure server. Nifty, isn't it? Oh, and don't forget to add some texts on the user page of Leyo2 that it is a secondary user account of Leyo, and redirect Leyo2's talk page to your normal talk page.

--David Göthberg (talk) 01:02, 24 December 2009 (UTC)

Thank you for this interesting suggestion (explained in detail). I would however like to use one account only.

I would like to know more about the proposal by TheDJ. I think this method could also be interesting for other users (as might be the proposal by David Göthberg, too). --Leyo 08:24, 24 December 2009 (UTC)

Yeah, TheDJ's suggestion to use a script to quickly load and unload the other scripts would be the most practical. However some javascript expert needs to code it up.

My method to use two accounts (in two browsers or with the secure server) is a bit clumsy and pretty annoying to use. By the way, my detailed description was mostly meant for the other readers of this page, since when we write a short explanation we usually get follow up questions, so I have gotten into the habit to write a full explanation from starters.

--David Göthberg (talk) 01:26, 26 December 2009 (UTC)

[edit] Image not visible

In trigonometric functions, I see the caption that accompanies this image, but I don't see the image itself. I do see the other image right above it. What's going on? Michael Hardy (talk) 17:35, 22 December 2009 (UTC)

....and now I find that when I add |250px here, then I can't see the image on this page, whereas I can when it's all alone, as above. The image above it in trigonometric functions also has that size restriction, but no such problem afflicts it. Michael Hardy (talk) 17:37, 22 December 2009 (UTC)

Perhaps your browser does not support .svg or .png? What browser/OS are you using? Intelligentsium 17:41, 22 December 2009 (UTC)

See instructions on purging images to solve this problem. I followed the steps at that page for your image, but I can't tell whether they worked or not because, as it says on my user page, I'm blind. Does the image work for you now? Graham87 06:05, 23 December 2009 (UTC)

It's still not working.

"Intelligentsium", does it work for you? If my browser fails to support .svg or .png, then why is the other illustration on that page, right above the one I pointed out, working normally for me? Michael Hardy (talk) 00:56, 24 December 2009 (UTC)

It's working for me, have you tried bypassing your cache? Svick (talk) 01:00, 24 December 2009 (UTC)

Just tried that. On the Google Chrome browser. Still not working. And the other image, just above it, still works normally. I've tried this one three different browsers now: two on my home computer, one on an on-campus linux machine with seamonkey. It fails on all of them. Michael Hardy (talk) 01:52, 24 December 2009 (UTC)

For whatever it's worth, I can see it using Firefox 3. Pcap ping 02:22, 24 December 2009 (UTC)

Do you have any ad blocking software that could be blocking that image in particular because of some text in its URL? Maybe this isn't very likely because you've attempted to view the image on two different machines, but it's worth a try. Graham87 02:43, 25 December 2009 (UTC)

Not that I'm aware of. Michael Hardy (talk) 21:41, 25 December 2009 (UTC)

[edit] Barnstar problem

Resolved.

Please look at User talk:Vossanova.Vchimpanzee · talk · contributions · 18:23, 22 December 2009 (UTC)

Look better? --Onorem♠Dil 18:28, 22 December 2009 (UTC)

Thanks.Vchimpanzee · talk · contributions · 18:29, 22 December 2009 (UTC)

[edit] iPhone and rollback

I find my iPhone handy for checking my watchlist when I have a few minutes to spare from other tasks. The problem I'm having is that there are so many links on the watchlist page that it is hard to scroll the touch-sensitive screen without occasionally hitting a link inadvertently. For the most part, that's a minor nuisance--I just cancel the page that's being loaded. But if I accidently hit a rollback link, there is no way to stop the resulting action. I've done this a few times now. I can rollback myself when I notice, but my fear is accidentally rolling back an edit without noticing. Ideally, I'd like a user option of having rollback ask for confirmation, or at least a way to turn rollback off and on. As more touch sensitive devices come on the market, I suspect others will encounter the same problem. I realize having rollback is considered a great privilege by some and I don't want to sound ungrateful, but all in all I'd rather be able to use my iPhone to edit than have rollback.--agr (talk) 21:38, 22 December 2009 (UTC)

If you want rollback removed, you can ask at WP:PERM. If you have any suggestions as to how this problem could be dealt with, please make them! My initial thought is a option to require confirmation of rollback, either with an OK/Cancel box, or a CAPTCHA or something? ╟─TreasuryTag►duumvirate─╢ 21:42, 22 December 2009 (UTC)

I had written a script for this (User:Zvn/confirmwatchlistrollback.js); haven't tested on iPhone though. --Zvn (talk) 21:55, 22 December 2009 (UTC)

Funny, got my iPod Touch a couple weeks ago and have made the same mistake at least twice.—NMajdan•talk 22:07, 22 December 2009 (UTC)

Yeah, I've made this same mistake on my extra-large touchpad as well, so it's not confined to small devices (though probably much more of a problem on them). An option to require an extra click for rollback is a good thing. — Gavia immer (talk) 22:15, 22 December 2009 (UTC)

Was this using the mobile site (I dunno how far that actually got) or the main site? If someone is using rollback and tabs, for example, I can see an extra click being a significant inconvenience. An option to require an extra click, or require confirmation on mobile devices would be awesome. :) Ale_Jrb^talk 22:36, 22 December 2009 (UTC)

It was the regular site. I think the watchlist would be too cumbersome on a mobile site, but I haven't tried it. For me, a user preferences option to require confirmation would be ideal. I think ok/cancel would be enough. I'll try to check out Zvn's script in the next day or so.-agr (talk) 23:17, 22 December 2009 (UTC)

Uh, the whole POINT of rollback is the simplicity of a single click. Otherwise, it's not really any different than undo for most edits. That said, I've mentioned before about not wanting it on the watchlist page, and both times got firected to the script, so I guess that's the only way it's gonna happen. ♫ Melodia Chaconne ♫ (talk) 23:09, 22 December 2009 (UTC)

I know the whole point. That's why it would be an option. ╟─TreasuryTag►draftsman─╢ 23:26, 22 December 2009 (UTC)

Make an alt account without rollback for iPhone use? Intelligentsium 23:18, 22 December 2009 (UTC)

My solution was to add a stylesheet for iPod/iPhone use. My vector.js page has three sections: the functions themselves, and a section activating all the functions. That section has two halves, and one is chosen based on the browser. If it's an iPod/iPhone, the second half is chosen, and it includes a line importStylesheet('User:' + wgUserName + '/vector-ipod.css');. Then I remove rollback links from my watchlist on that CSS page, along with a few other tweaks—that admittedly I haven't polished much—like making the tabs bigger and removing the sidebar completely (unlike the toggle-able option for normal browsers). Is that a useful approach for anyone? {{Nihiltres|talk|edits}} 15:31, 23 December 2009 (UTC)

[edit] Creating anchors

I tried to use {{anchor}} and found the documentation unhelpful. Any recommendations for how to use {{anchor}}, or whether using html <span id="MYANCHOR"/> is better? Please comment at Template talk:Anchor#Usage is confusing (wrong?). Johnuniq (talk) 08:54, 23 December 2009 (UTC)

<span/> is invalid and is converted to <span></span> when it gets run through HTML Tidy. Putting {{anchor}} or <span></span> in the header have the issue of usually screwing up edit summaries. --MZMcBride (talk) 09:07, 23 December 2009 (UTC)

MZMcBride: No, using <span> tags doesn't screw up the edit summaries. So using <span> tags directly is the solution. But please, let's keep this discussion over at Template talk:Anchor#Usage is confusing (wrong?).

--David Göthberg (talk) 15:10, 23 December 2009 (UTC)

[edit] Formatting problem with bulleted lists by floaters?

Is there some more elegant way to deal with the following problem I have discovered with bulleted and numbered lists next to floating images and tables? (If you are using a very wide-screen monitor, I suggest varying the width of the browser window so you can see how the text moves around in relation to the floating table.)

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

• Bulleted Item for some reason is "outdented" next to floating table, in both Firefox and Internet Explorer, which looks downright wrong but there is no obvious solution as to whatever is causing this bizarre bullet-item formatting problem that is screwing up the page layout and document flow. (If you are using a very wide-screen monitor I suggest varying the width of the browser window so you can see how this text moves around in relation to the floater.)

• Bulleted Item for some reason is "outdented" next to floating table, in both Firefox and Internet Explorer, which looks downright wrong but there is no obvious solution as to whatever is causing this bizarre bullet-item formatting problem that is screwing up the page layout and document flow. (If you are using a very wide-screen monitor I suggest varying the width of the browser window so you can see how this text moves around in relation to the floater.)

• Bulleted Item for some reason is "outdented" next to floating table, in both Firefox and Internet Explorer, which looks downright wrong but there is no obvious solution as to whatever is causing this bizarre bullet-item formatting problem that is screwing up the page layout and document flow. (If you are using a very wide-screen monitor I suggest varying the width of the browser window so you can see how this text moves around in relation to the floater.)

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

A partial-fix (hack) I have discovered is to enclose the bulleted list in an extremely simple one-cell non-float table, such as:
{|
|-
|
* Item 1
* Item 2
* Item 3
|}
En-tabling the bulleted list fixes the page layout...... but by putting the entire list in a single large table, large bulleted paragraphs don't cleanly move to the left side of the page below a floating table:

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

The more complete fix (hack on a hack) I have discovered is to enclose each item in the bulleted list in its own one-cell non-float table, such as this:
{|
|-
|
* Item 1
|}
{|
|-
|
* Item 2
|}
{|
|-
|
* Item 3
|}

Bulleted items below the floating table/image now move out to the side of the browser window correctly, and whitespace is minimized:

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

So as you can see I have found a solution, but this hackery seems unnecessary on the part of article editors to make bulleted lists and floating tables/images work together cleanly. Also I don't feel comfortable leaving weird stuff like this in an article without some additional <!-- hidden text to explain to other editors what the heck is going on here -->.

Is there some better way to deal with the bulleted-list formatting by floaters? Is there something that can be done to the back-end code to fix this, so I don't need to manually hack page formatting like this? DMahalko (talk) 15:44, 23 December 2009 (UTC)

This is standard CSS behaviour with floating blocks and inline text (and list items +bullets are normal inline elements). And yes, it's horrendous behavior, and the guys in the CSS standards group better be very sorry about it, but that does not change anything. Your analysis was accurate and there is no other way to solve this problem as far as I know. —TheDJ (talk • contribs) 15:53, 23 December 2009 (UTC)

Since the page layout markup for lists are not directly created by editors, but instead use wikimedia's simplified markup, it appears possible for this CSS page rendering error to be "fixed" in the page rendering code...

Rather than:

* item foo

* item bar

Becoming:

<ul><li>item foo</li></ul>

<ul><li>item bar</li></ul>

It could be marked up as:

<table><tr><td><ul><li>item foo</li></ul></td></tr></table><br>

<table><tr><td><ul><li>item bar</li></ul></td></tr></table><br>

DMahalko (talk) 03:22, 24 December 2009 (UTC)

I give very little chances to a developer approving this. (Hacks like this are heavily frowned upon) —TheDJ (talk • contribs) 09:53, 24 December 2009 (UTC)

By appling a fix like this at the wikimedia code level, it at least allows for browser detection code so that if the CSS problem is fixed eventually, then the wikimedia software could check the browser version and not apply this hack to browsers newer than the current ones that (hopefully) won't need the hack.

If this can't/won't be approved at the developer level, I have no problem with manually applying this table-hack to every wrongly-formatted bulleted-list I can find....... hmmm, I see an incorrectly formatted bulleted list on TheDJ's user-page.. ;)

So just to be clear, nobody else cares if I am silently applying this table-fix/hack all over the place to every incorrectly-aligned bulleted list in every article, without any way to track the table-hack applications, and with no way to be forward-looking to an eventual future browser CSS fix?

(I suppose I could make a hidden category to track this so they can be removed someday if browsers ever do handle lists and floating tables correctly.)

DMahalko (talk) 23:36, 24 December 2009 (UTC)

Simply put, don't do this in articles. Perhaps an easier way to deal with this would be to float things right instead of left in problem places?... --Izno (talk) 23:52, 24 December 2009 (UTC)

Your suggestion seems unacceptable because it greatly limits the ability for editors to format pages that are dense with floating objects like the TOC, infoboxes, images, and various floating objects.

Many articles are way overloaded with stuff all along the right side that look horribly ugly and run float-images way out of alignment with the text, unless Template:Clear is used all over the place.

Requiring editors to force things to be right-justified just to make bulleted lists not look ugly is a severe editing and layout limitation, if there is this simple fix available for the problem. DMahalko (talk) 00:09, 25 December 2009 (UTC)

[edit] Templates to fix bullet alignment / tracking category

I suppose I could make templates which include a hidden tracking category within. I am not a programmer so these templates are probably not created correctly:

• Template:Indent-fix-begin
• Template:Indent-fix-end
• Hidden maintenance category: Category:List alignment fix next to floating tables

And how well does it work? Testing:

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table. Normal unbulleted text has correct spacing next to table.

Seems to work okay to me. Whaddaya think? DMahalko (talk) 00:02, 25 December 2009 (UTC)

[edit] Explanation

Per the CSS 2.1 spec, two types of boxes cannot overlap floats: a line box, and "a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible')". The reason for this is pretty straightforward. CSS deals only with boxes. Imagine what would happen if no box could overlap a float. Then if you have even a short float, it will cause any adjoining block element to squish horizontally for its entire width, leaving an unsightly gap under the float:

Instead, the block ignores the existence of the float, but each line is shrunk if necessary, so you get:

Pay close attention to where the blue border is. The enclosing block is really behind the float, but the text doesn't go there. Thus we get a much closer approximation to what we want.

Unfortunately, this causes a problem: the padding on the inside of the blue-bordered float is way to the left of the left edge of the line boxes. Usually this isn't noticeable, because you put a margin on the floating element:

The margin on the float forms part of the floated box, so the line boxes shrink to avoid it. The space on the left edge of the running text is caused by the float's margin where the float is, and by non-floated box's padding elsewhere.

Unfortunately, this causes problems in some hard-to-fix corner cases. We expect to see extra-large left padding on lists, but the margin you give to the float is fixed independent of whether a list is actually present. So if we have a list, it looks like:

Notice that the left padding is larger where the list's actual padding is used, but not where the float is. In this case you'd want to increase the right margin on the float:

IMO, this is the correct solution in our case. It's certainly much better than using table tags – or, as I did here, overflow:hidden, which achieves the same effect by creating a new block formatting context. The table-y solution gives the ugly blank space under the float I pointed out in my first example, so I'd strongly recommend it not be used. If you want to make manual tweaks so it looks better, increase the right margin on the float until it looks good (I used 1.5em here).

There's no obvious way to solve this on the spec level (at least, not obvious to me). What we would basically like is for the outer box to become no longer a box, like (simulated):

But then the large blue-bordered region is no longer a box. CSS deals only with boxes; introducing anything that's not a box would cause enormous conceptual complications both for authors and implementers. So we have to sort of fake it. It works pretty well except for corner cases like this. Browsers are not going to "fix" this: it's not a bug in their implementations, and changing how this model works on any fundamental level would break sites all over the place. If any more convenient workaround is ever introduced, it would likely be tied to a new CSS property to enable the new behavior, whatever that might be (I can't think what).

To reiterate for those who didn't read all that: increase the right margin on the floated box, don't try using tables or similar. (And if you did want to use tables, overflow:hidden on each list item would probably be easier.) —Simetrical (talk • contribs) 19:52, 25 December 2009 (UTC)

[edit] Padding doesn't work with non-list text

The problem with adding padding as you are suggesting is that it also pushes over non-list content in a way that still looks wrong. Yes, you are giving more room for bullets and numbering, but the margin position is still wrong compared to non-list text.

To me it appears that enclosing each list item in its own non-float table is still the least-ugly way to deal with the formatting issues, until the SSL spec can be changed to fix this annoyance. DMahalko (talk) 05:21, 26 December 2009 (UTC)

Hmm, you're right. Using overflow:hidden to create a new block formatting context seems like a better tactic for short list items, while for very long list items you'd want to change the float's margin. There's no good solution here, though. —Simetrical (talk • contribs) 23:54, 26 December 2009 (UTC)

[edit] Wikipedia Mobile

The mobile survey that Wikipedia posted on Google Docs is having technical issues and I was unable to successfully submit a survey. For this reason I have copied and pasted the 'comments" section from the survey onto here.

I would like to point out that the mobile site has a problem on my second generation IPod touch (using Safari). When i open an article and rotate my device horizontal from the vertical position, a third of the screen stays the way it was before, also if i click a link to a new article while in this horizontal position, that part of the screen, again, freezes and stays on the previous article as if the screen was still vertical. i find myself clicking "view this page on regular Wikipedia" for almost every article (or fixing the problem by rotating my IPod touch vertical and then back horizontal again.) one more thing, i was UNABLE to do this survey on my device (didn't respond after "submit" ) and am currently doing it on my desktop. I love you guys and will donate soon when i set up paypal! keep the ads away!

Thanks, Danny —Preceding unsigned comment added by Dninyo (talk • contribs) 20:58, 23 December 2009 (UTC)

I have relayed this to the developer of the mobile interface. —TheDJ (talk • contribs) 10:03, 24 December 2009 (UTC)

[edit] {{dts}} not appearing

Every National Register of Historic Places list has a dates column, using {{dts}}, for when places were put on the Register. For the past few hours, this template has been displaying exactly nothing: as you can see at National Register of Historic Places listings in Beaver County, Pennsylvania, the "Date listed" column appears to be blank. The template hasn't been vandalised, the code still recognizes it (try sorting the column for proof), and it likewise fails to appear when I try to put the template in non-table prose text in other articles. Any idea what's wrong? Nyttend (talk) 23:08, 23 December 2009 (UTC)

I see the first row with the date of October 24, 1996. ---— Gadget850 (Ed) ^talk 23:12, 23 December 2009 (UTC)

{{Dts/fmt}} was vandalized by an anonymous editor. It should be fixed now. Svick (talk) 23:18, 23 December 2009 (UTC)

That's a pretty insightful vandal, figuring out how to vandalise a semiprotected page while not logged in and making it seem that the page wasn't vandalised. Thanks for the help; I've never quite figured out much in the template namespace. I've semiprotected that template and the one to which it's a redirect. Nyttend (talk)

In that case, you might want to semiprotect other subpages of that template (except /doc and /sandbox*). Svick (talk) 23:32, 23 December 2009 (UTC)

All done; thanks for the pointer. Nyttend (talk) 23:49, 23 December 2009 (UTC)

[edit] Secure server

Currently most links to other Wikimedia projects (like Wiktionary) point to the normal servers, even when the user is using the secure server. I am now updating the links in the MediaWiki interface and in other places such as the Main Page and the sister project templates. I make it so users on the secure server see secure links, while users on the normal servers see normal links.

This means I am editing many high-visibility places, and that I am doing a site wide change, so I am announcing this in case anyone has any comments about it. See Wikipedia talk:Secure server#Sister project links for more on this and to discuss it.

--David Göthberg (talk) 01:25, 24 December 2009 (UTC)

[edit] Embedding Google Street View images onto Wikipedia pages

Google Street View is a great source for images of many places. It is a way to obtain images without having to physically go to these places camera-ready, something that is not always easy to do.

Google indeed authorizes their maps and street view images to be used on one's websites. But this is under the condition that the HTML be embedded straight onto the site and that a screenshot not be uploaded. You can read about this in detail on this page where it says:

If you want to use Content from Google Maps, Google Earth, Street View, etc. on your website, embed it within the site rather than uploading screenshots. This means the Content will be loaded directly from Google's servers, and will automatically have appropriate attribution.

Now, is there a way that Google's images can be added to Wikipedia pages in a manner that complies with this? If not, can Wikipedia be made so this is possible? Sebwite (talk) 01:55, 24 December 2009 (UTC)

Because the images must remain on Google's servers, this effectively is saying that derivative works are prohibited; all images here, other than fair-use, must permit derivative works, so I doubt that the technical side of doing this really matters. Nyttend (talk) 05:43, 24 December 2009 (UTC)

[edit] Some trouble with multi-prefix search

I've installed a multi-prefix search form at WT:ROMANIA to search through the previously fragmented notice boards. But it doesn't seem to work quite right. For instance searching for abroad returns a bunch of pages, but searching for Badea (a Romania name, but not using any diacritics) returns nothing, even though it definitely appears on some of those pages, e.g. here. Does anyone know what might cause this? Pcap ping 02:17, 24 December 2009 (UTC)

Your example Wikipedia:Romanian Wikipedians' notice board/Archive 11 was created 8 hours ago and has not been indexed by the search function yet so neither abroad nor Badea is found there by searching. Do you know of other pages where Badea occurs? PrimeHunter (talk) 02:40, 24 December 2009 (UTC)

Don't think so. You're right that Badea is found at the previous location [3] of that contents before I archived it. Pcap ping 02:42, 24 December 2009 (UTC)

However, that's not the only anomaly. The word "checkuser" is found in archives 8 and 10, but not in 9, where it also appears. Kinda strange. I'll try again in some 24 hours see if the indexing gets sorted out. Pcap ping 02:47, 24 December 2009 (UTC)

This is the same issue. "checkuser" is found in two old pages but not in a page created 11 hours ago. Note that Archive10 in the search is the old Wikipedia:Romanian Wikipedians' notice board/Archive10 while archive 9 in your link is the new talk archive Wikipedia talk:Romanian Wikipedians' notice board/Archive 9. PrimeHunter (talk) 03:07, 24 December 2009 (UTC)

Pohta, PrimeHunter is right that it seems the pages in question have not yet been indexed, but also, you need to search the main noticeboards as well as the archives. You can do this by specifying the prefix without the ending "/". Example: a prefix of "User talk:Stmrlbs" will search all pages starting with "User talk:Stmrlbs" - this means the main talk pages and all talk page archives because the archivs start with "User talk:Stmrlbs/" - which means they also start with "User talk:Stmrlbs". However if you specify a search prefix of "User talk:Stmrlbs/", then you will only search the archives, because the main talk page does not begin with "User talk:Stmrlbs/". I have changed the search prefixes on WT:Romania to inlude the main pages. Please check to make sure that this is what you want. The problem is now you will find "Badea"... on the main noticeboard page, because that is where it was when it was last indexed. And.. unfortunately, there is no software function to tell you if something was on a main page on a certain date, then what archive is it in now? For that matter, there is no housekeeping function in Wikipedia to update links going to text that has been archived.. which, imo, is a real weakness in wikipedia. But.. that's the way it is. Sorry. stmrlbs|talk 04:11, 24 December 2009 (UTC)

It looks like the indexing kicked in, and the search works correctly now. Thank you both for your help. Pcap ping 19:48, 24 December 2009 (UTC)

[edit] Orange links

I forget now where I saw it, but there was a guide to the different colors of links of Wikipedia, and orange wasn't on it. I have seen this color in at least two situations, although there might not be consistency in how the color change happens.

On one occasion today, a link was orange after I had clicked on it, though usually it's purple in those situations. Also, when making major improvements to an article or creating a new one, I find that when previewing, as I check each link to make sure it works properly, the next link for me to check turns orange.Vchimpanzee · talk · contributions · 22:32, 24 December 2009 (UTC)

That's nothing to do with Wikipedia, it's your Internet browser. If you click on a link, move the mouse away, and un-click, the link will be orange. ╟─TreasuryTag►constabulary─╢ 22:33, 24 December 2009 (UTC)

Even with article improvement?Vchimpanzee · talk · contributions · 22:52, 24 December 2009 (UTC)

I don't understand what you mean, "even with article improvement?" – if you click and drag away from any link, on any website (Wikipedia, Google, Department for Energy and Climate Change etc.), it will go orange. ╟─TreasuryTag►quaestor─╢ 22:55, 24 December 2009 (UTC)

The article (still being previewed) has new links which I have never tried. So after I try one, the next link for me to try, going left to right, is orange.Vchimpanzee · talk · contributions · 23:00, 24 December 2009 (UTC)

I guess it is the browser. While going through a cycle of clicking on links and then going back where I was, I see an orange link for where I just was.Vchimpanzee · talk · contributions · 18:06, 25 December 2009 (UTC)

It's the browser. Orange is the color for an "active" link (ie: when you're actually clicking it). EVula // talk // ☯ // 18:12, 25 December 2009 (UTC)

What EVula said. Most people don't realize that this happens because they finish clicking. :) --Izno (talk) 18:23, 25 December 2009 (UTC)

I think youwere looking for Wikipedia:Link color. ---— Gadget850 (Ed) ^talk 18:47, 26 December 2009 (UTC)

[edit] Odd Firefox text search problem

Moved from Wikipedia talk:Village pump Svick (talk) 00:53, 25 December 2009 (UTC)

I seem to be having an odd problem recently searching for text within English-language Wikipedia pages on a Firefox browser. For example, within Andalusian independentist conspiracy (1641), it will not find Portugal. Doesn't seem to be a problem outside Wikipedia of even in es-wiki. Closed & re-opened browser, still having the problem. It might imaginably be something about a widget I use, but I haven't knowingly added any lately. Has anyone else experienced something similar? Any insights would be welcome. - Jmabel | Talk 00:46, 25 December 2009 (UTC)

Are you sure you don't have case sensitivity on and searching for “portugal” (note the small p)? It works okay for me in Firefox on that article. Svick (talk) 00:56, 25 December 2009 (UTC)

That turned out to be precisely it. I was just coming here to say I'd worked it out, but your comment preceded me. - Jmabel | Talk 01:30, 25 December 2009 (UTC)

[edit] Scottish island infobox map

Several people have raised the issue of maps such as on Barra and Rùm not appearing in IE8. Discussion. Can anyone cast some light on the problem? Finavon (talk) 10:57, 26 December 2009 (UTC)

For me, the maps display in normal mode in IE8 but usually not in compatibility mode. If I drag the mouse over the blank space in compatibility mode then the space where the map should be becomes completely blue and a blue arrow pointing up-right in a box appears outside the space. Placing the mouse on the arrow (no click needed) causes the map to display. PrimeHunter (talk) 12:09, 26 December 2009 (UTC)

The maps generally don't display for me, but I don't see any IE "Compatibility Icon" (the "torn page" icon) displayed for these pages. I'm assuming that this means I'm viewing them in "normal" mode? 81.129.128.20 (talk) 13:54, 26 December 2009 (UTC).

I always see the torn page icon to the right of the address bar on any page when I run IE8 whether compatibility mode is activated or not. The option is also in the page menu. There I see the torn page icon when it is in "normal" mode and a checkmark when it is in compatibility mode. PrimeHunter (talk) 17:15, 26 December 2009 (UTC)

Oh. According to the IE help, "If Internet Explorer recognizes a webpage that is not compatible, you will see the Compatibility View button ["torn page" icon] on the Address bar." I see this sporadically for some sites, but I don't recall seeing it for any Wikipedia pages, and I certainly don't get it for the problem Scottish island pages. I assumed this was because IE did not recognise any incompatibilities in those pages. I can force Compatibility View for the Wikipedia site via the menu option, but it does not appear to make any difference to the display (or in my case non-display) of the maps. All it seems to do is cause IE to crash a lot. 86.133.242.124 (talk) 00:25, 27 December 2009 (UTC).

IE8 is not my normal browser but after testing it on many pages I found a couple where the torn page icon was not at the address bar. Have you tried the mouse dragging thing? Hold down left click and drag the mouse to the right on the space where the map should be displayed. PrimeHunter (talk) 00:55, 27 December 2009 (UTC)

Yes, that works for me as you described earlier. When I hover the mouse over the blue "accelerators" arrow after having selected the blank space, the map appears. 86.133.242.124 (talk) 01:14, 27 December 2009 (UTC).

PrimeHunter, Finavon.. have you guys tried logging out ? Might be that there is a difference in IP vs. registered behaviour. (/me suspects the relative bodyContent that is applied when a sitenotice is active) —TheDJ (talk • contribs) 11:30, 27 December 2009 (UTC)

[edit] Question about this title: Oahspe: A New Bible

I use Watchlist sorter which sorts by namespace, and this article seems to have a namespace all of its own. Any ideas why? The colon in the title? Thanks. Dougweller (talk) 12:35, 26 December 2009 (UTC)

Yes, it's the colon. The source code of watchlist sorter even has the following comment: //This will fail for articles which contain ":" in name. Svick (talk) 14:27, 26 December 2009 (UTC)

Thanks. Dougweller (talk) 06:39, 27 December 2009 (UTC)

[edit] Javascript link in personal appeal header

Fail. —Preceding unsigned comment added by 92.28.188.226 (talk) 17:09, 26 December 2009 (UTC)

[edit] Template parameter default value

I created a new template here:http://en.wikipedia.org/w/index.php?title=Template:Hstrong%27s&action=edit. the code looks like this:
[http://www.htmlbible.com/sacrednamebiblecom/kjvstrongs/STRHEB{{{1|0}}}.htm#S{{{1}}}{{{2}}} {{{3}}}]
and it works fine 99% of the time. but to be perfect the first parameter (which i use twice) must, in the first instance, have a default value of 0 and in the second instance it must have a default value of null. but when i run {{Hstrong's||10|result}} the result is 'result˄' where the expected result would be 'result'. (note the 0 after the STRHEB)
Lemmiwinks2 (talk) 00:13, 27 December 2009 (UTC)

I have fixed your template. And here's the explanation:

Template parameters really have three states: undefined (not fed at all), empty but defined (fed but with no content, as in an empty string ""), and "has data".

When you feed {{Hstrong's||10|result}} then you are feeding an empty but defined parameter 1. But the parameter pipe trick you used for that parameter "{{{1|0}}}" only returns the default value 0 when parameter 1 is undefined (when it hasn't been fed at all). To make it return 0 for both an empty but defined, or a not defined parameter 1, do like this:

{{#if: {{{1|}}}    <!--Check if parameter 1 has data-->
| {{{1}}}    <!--Parameter 1 has data, use it-->
| 0    <!--Parameter 1 is empty or undefined, use a default value-->
}}

Note that you must use "{{#if:{{{1|}}}", not "{{#if:{{{1}}}". That is, there must be a pipe "|" in the if-usage, otherwise the if-case sees the literal string "{{{1}}}" instead of an empty string "" when parameter 1 is undefined.

For the second usage of parameter 1 in your code, the "#S{{{1}}}{{{2}}}" part, I assume you mean you want to simply get "#S" when parameter 1 and 2 are empty or undefined. Then do like this: "#S{{{1|}}}{{{2|}}}". That means when they are undefined they fall back to an empty string, and when they are defined but empty they instead return their content which happens to also be an empty string.

So we are working with empty and undefined stuff here, its pretty tricky.

--David Göthberg (talk) 01:52, 27 December 2009 (UTC)

Yes. that fixes it. thank you. :-) Lemmiwinks2 (talk) 02:42, 27 December 2009 (UTC)

I think in this case it might be easier to work with named parameters rather than positional parameters - something like:

[http://www.htmlbible.com/sacrednamebiblecom/kjvstrongs/STRHEB{{{page|0}}}.htm#S{{{page|0}}}{{{digit1|0}}}{{digit2|0}}}]

with named parameters there's less confusion - you'd have to feed it a blank entry specifically to get a blank. incidentally, is there a reason why you're entering the last two digits as independent variables rather than as one variable? --Ludwigs2 02:21, 27 December 2009 (UTC)

the last parameter is the text to show in the link. the first parameter is the page and the second parameter is the number within the page. page must default to 0 in the first instance only. in the second instance it must default to null. Lemmiwinks2 (talk) 02:33, 27 December 2009 (UTC)

ah. then just delete the zero in the second instance (chagned digit1 &digit 2 to more sensible names, as well):

[http://www.htmlbible.com/sacrednamebiblecom/kjvstrongs/STRHEB{{{page|0}}}.htm#S{{{page|}}}{{{number}}}{{text}}}]

[edit] How to create a shortened version of a template that uses a table

I would like to create an option for a shortened version of a template that uses a table; the example is here and here. Unfortunately, I have not been able to get this process to work with templates that have tables, where we want to display only part of the table content in the shortened version. The template that this is intended for is one that is regularly updated, which is why it is preferable to use a shortened version of one template, rather than to create two separate templates. Any help with figuring this out would be greatly appreciated!--Pharos (talk) 02:14, 27 December 2009 (UTC)

I updated your sandbox with a table that does what you want. Here's the code for anyone else that reads this later:

<table class="wikitable">
<tr>
<td> Cell A
<td> Cell B
{{#ifeq: {{lc: {{{short|}}} }} | yes
| <!--Short version, do nothing-->
| <!--Long version-->
  <tr>
  <td> Cell C
  <td> Cell D
}}
</table>

It uses HTML table notation instead of wikitable notation, so we don't get pipe "|" problems inside the #ifeq. It is usually not necessary to add ending </td> and </tr> tags, since MediaWiki fixes that for us. But if you take cell content as parameters, then you might need ending </td> tags. Then do like this: "<td> {{{1|}}} </td>", not this: "<td>{{{1|}}}</td>", to avoid some tricky whitespace problems. Do not put the ending </td> tags on a separate line, that also causes sneaky whitespace and padding problems.

"{{lc: }}" lower cases the "short" parameter, in case people do the mistake to feed "short=Yes" or "short=YES".

--David Göthberg (talk) 03:11, 27 December 2009 (UTC)

You should not make assumptions about what the mediawiki software will or will not fix "for you". It can change and often without notification. —TheDJ (talk • contribs) 11:27, 27 December 2009 (UTC)

The reason I often leave out the end <td> and <tr> tags in my examples is that humans tend to place them wrongly and mess them up in any number of ways. Among other things as I described above, even if you place them where most users would expect to be "correct" you get whitespace and padding problems. While when you let MediaWiki handle it you usually don't get those whitespace and padding problems. So MediaWiki does a better job than the human editors.

--David Göthberg (talk) 11:53, 27 December 2009 (UTC)

[edit] Will this bug ever be fixed?

Hi

Could someone with some influence PLEASE, PLEASE try to get the stupid bugs in Wikipedia's diff generation fixed. Here is a typical example:

http://en.wikipedia.org/w/index.php?title=Goodwin_Sands&action=historysubmit&diff=334191631&oldid=334190790

There are only minor changes to odd words throughout this section, but the code is obviously getting confused at the outset because an extra line has been inserted at the start. Then it flags virtually the whole section as having changed.

This bug has been outstanding for YEARS. It is so dumb, and so annoying, it drives me nuts. Would someone PLEASE try to get it fixed. Thank you! 86.133.242.124 (talk) 02:51, 27 December 2009 (UTC).

ha! See below. Similar bug. ~ R.T.G 04:19, 27 December 2009 (UTC)

I've seen this plenty of times, too. It is very misleading. I submitted a bug report on this: bugzilla:21953. Please vote on it if you want it noticed. stmrlbs|talk 05:05, 27 December 2009 (UTC)

I'm sorry, the diff I gave below is a good example of a bug, significant new text not highlighted in the diff, but I won't be posting my email on a public page again. I have had useless stupid flooding on multiple emails (receive 100s unsolicited emails a day!). I had an email with my own name on it but rubbish@info.info decided to inform me of unrequited rubbish for ever. I have an SUL. My username idents me as good as my email and you can email me on the hush without ever seeing my email@add. If they fix it so that I can log in without displaying email I will vote and post this diff. Otherwise I won't. ~ R.T.G 11:59, 27 December 2009 (UTC)

Create a throwaway/single-purpose Yahoo account or the like.--Father Goose (talk) 12:48, 27 December 2009 (UTC)

[edit] Diffs

I need to see this[4] as a diff rather than an undefined red paragraph and a black one, which on examination, has significant changes in the middle. Current highlighting does not even almost highlight a diff in some edits at all and yet there are new words and links and etc.. Obviously that is probably a core program area. Nonetheless - that diff is an example of diff showing no diff although diff.. If I wanted to I could change a large 200 word paragraph and the diff would show nothing as if the paragraph had been moved only rather than changed in the actual diff. I can find the !significant! difference between those paragraphs (see diff) but my computer and wiki does not which is, after all, defeating the point of diffs in the strongest way possible. Diffs without diffs tells us no diffs and yet... hmmm... please show diffs if they are existing rather than red paragraphs, for any truly able tech help, thank you. Without... thank you anyway but should report anything possible for a fix, probably old post but, should repost. ~ R.T.G 04:16, 27 December 2009 (UTC)

[edit] Return/get first word of page title

Would it be possible through the use of a template or any other means to be able to quote the certain words from a page's title? Consider this page's title for example "Village pump (technical)". Is it possible by some means to write a code so that the word "Village" is written/returned? (or if this 'code' or whatever is placed on some other page it writes/returns the first word from the title) Thanks.--72.241.13.250 (talk) 05:31, 27 December 2009 (UTC)

You can use the template {{first word}} I just created. Svick (talk) 10:38, 27 December 2009 (UTC)

[edit] Can we change spacing/font in the box in which we edit articles?

I don't know about anyone else, but I find it frustratingly difficult to try to edit articles in the actual box in which the actual editing takes place... the font is small, it is single spaced and, most annoying, the html-type tags and references make it hard to tell what is actually going to appear in the article. A lot of references are really long so when you try to read paragraphs in the editing box its difficult to tell where one sentence ends and another begins independent of things inside of reference tags... I'm not sure I'm explaining this adequately, or making any sense... but I'm sure other people are annoyed by this!

When I try to edit a long article with lots of grammatical problems I like to just read through it in the actual box where I can make edits, but all the html tags and references clutter everything up so much that it is just very difficult to read...

Is there some way to improve this? For example, why can't it be more like editing posts in some forums on other websites where we could actually highlight text and italicize it (or bold it, etc) so that it shows up as italicized in the edit box rather than having to use apostrophes? If regular internet forums allow for this why can't Wikipedia do it? Is there anyway to improve the system for adding citations so that we don't have to put the entire bibliographic reference in the paragraph with the html tag around it? Could we make edit boxes double spaces so they are easier to read? Any ideas? The Way (talk) 06:53, 27 December 2009 (UTC)

You can use list-defined references to define references inside <references> (or {{reflist}}) and only point to them in the text.

You can change the appearance of Wikipedia for yourself by editing your monobook.css page (or vector.css if you use the beta skin). For example, to make the font of edit box larger, put #wpTextbox1 { font-size: 125% } there. Svick (talk) 11:00, 27 December 2009 (UTC)