Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 06:40, 16 September 2012 (Robot: Archiving 2 threads (older than 7d) to Wikipedia:Village pump (technical)/Archive 102.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org.

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.

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Syntax highlighter reboot

Hello all, it's been quite a while since I've been active on Wikipedia. How have you been? I have found that I don't nearly as much time for Wikipedia anymore, but I wanted to come back to improve the syntax highlighter I was working on:

The big advantage to my script over something like wikEd is that my script does the syntax highlighting as you type without messing up your browser's undo/redo function. One day I would love to see something like this integrated into the site by default; I think it would really help make editing Wikipedia more intuitive and help attract new editors.

I have successfully resolved many of the issues that plagued the script before. In particular, the performance is much improved and it now works consistently in both Firefox and Chrome. I've moved the description page for the script to Meta. Please check it out and let me know what you think. —Remember the dot (talk) 02:32, 18 August 2012 (UTC)[reply]

And Opera? :-) mabdul 00:43, 19 August 2012 (UTC)[reply]
Opera works better than it used to but it does not handle line breaks in textareas properly (it does not fully conform to the UAX14 standard) which can lead to misaligned highlighting. Generally though, it seems to work well and if you like Opera and don't mind the occasional weirdness feel free to use it! —Remember the dot (talk) 04:45, 20 August 2012 (UTC)[reply]
Hi Remember the dot, it would be lovely to see this based on the new parsoid model and the annotated edit DOM. It would then basically be an alternative to the new Visual Editor, a new style wikicode editor. I'd love to see something like that. —TheDJ (talk • contribs) 09:26, 21 August 2012 (UTC)[reply]
Interesting, I wasn't aware of the VisualEditor and Parsoid projects. My highlighter works differently because it does not replace the textbox with a rich text editor, thus avoiding breaking the browser's undo/redo function as wikEd and Parsoid do. Also, my highlighter is ready to go now--I'm using it as we speak. In the future it probably is going to need a more sophisticated wikitext parser, but the one it has now works great. —Remember the dot (talk) 23:54, 21 August 2012 (UTC)[reply]
I've just installed, and am generally loving it.
1 question: Does it have to be installed in our common.js or can it just as easily be placed in our vector.js ? You might want to clarify that in the docs. (Note: "I know enough to be dangerous" but am not sure if there'd be negative repercussions from the latter (beyond just not working in other skins). Also, if I have 50 tabs open, will having another/separate file to include, have minute performance impact? rambleramble.)
1 request: Could you add the "run-on-demand" feature? (see User:Anomie/linkclassifier#Usage, and this edit plus that for where Anomie added the on-demand function, in case that helps)
A few notes: I am using an older computer (using opera in ubuntu), and I tend to have numerous tabs open, and I'm already using a few page-highlighter scripts (ais523/highlightmyname2.js and ais523/adminrights.js); one/some of those factors are making Syntax highlight a bit sluggish, and timeout fairly frequently. I'll definitely keep using it though. Huge thanks!
Also, I just linked to this thread, in WP:VPR#Differentiating reference syntax in the editing window. ttfn, -- Quiddity (talk) 22:17, 28 August 2012 (UTC)[reply]
Glad you like it! Yes, you can put the script in vector.js etc. I tried to design the script to be as simple as possible, and I'm not sure I really want to add on/off buttons for each page. I'd be interested in hearing feedback from more users, and the script is open source so anyone can create their own version with more or less features. —Remember the dot (talk) 02:14, 29 August 2012 (UTC)[reply]
You will get much less feedback at Meta. I suggest you put it on English Wikipedia at User:Remember the dot/Syntax highlighter.js. This is a useful tool along with Reference Tooltips. See discussion here: User talk:Yair rand/ReferenceTooltips#Wish list. Edit link that takes one to reference wikitext.
I wanted to test this out on a long page with many detailed references. See Incarceration in the United States. I got this message:
Syntax highlighting on this page was disabled because your computer is too slow. The maximum allowed highlighting time is 150ms, and your computer took 161ms. If you are using Chrome or Safari, this could be because the syntax highlighter has to work around WebKit bug 17427. Try closing some tabs and programs and clicking "Show preview" or "Show changes". If that doesn't work, try a different web browser, and if that doesn't work, try a newer computer.
I suggest creating a second version (on English Wikipedia) with a 500ms max, and letting people decide which version to use. No one is going to mind a half-second delay if it saves them many seconds in finding references, etc.. I almost always have many pages open. I use a 20mbs broadband connection. My computer is fast with low ping. I kick ass in CrossFire. :)
OK. I looked at the intro section of Incarceration in the United States. It has many references. I would like a version of this gadget that only highlights references. This is a great tool. Thanks! A reference-only version would be great too. --Timeshifter (talk) 02:49, 29 August 2012 (UTC)[reply]
Did you take the error message's advice and try editing the page in Firefox? Firefox seems to execute the script about twice as fast on my computer and has no trouble with Incarceration in the United States. —Remember the dot (talk) 02:54, 29 August 2012 (UTC)[reply]
I am using Firefox. It is my default browser. You will not get many people to close windows. So the tool will not get used as much. I suggest you propose this as a gadget at Wikipedia:Gadget/proposals. --Timeshifter (talk) 02:57, 29 August 2012 (UTC)[reply]
Also try clearing the cache, I made a significant performance improvement literally as we've been talking. —Remember the dot (talk) 03:00, 29 August 2012 (UTC)[reply]
I did Ctrl-Shift-R when I installed it at User:Timeshifter/common.js. I and others are not going to do much more than that in order to use a gadget. There really is no need for the 150ms max for most people. People will uninstall the gadget if they think the gadget slows them down too much. Or they will use the faster version. 2 versions solve the problem for people who think it is too slow for them. --Timeshifter (talk) 03:09, 29 August 2012 (UTC)[reply]
I made changes after you installed the script, so you need to clear your cache again for them to take effect. —Remember the dot (talk) 04:32, 29 August 2012 (UTC)[reply]
It works for me now on that page! I still have many windows and tabs open too. --Timeshifter (talk) 05:10, 29 August 2012 (UTC)[reply]

(unindent) Further discussion:

Aiight, so I don't think anyone who isn't colourblind is likely to argue with the fact that a syntax highlighter is kind of needed, so thank you for actually implementing one. Once it is more stable and cross-browser compatible it should probably make a very helpful default gadget.

The style, though, is a little odd - why did you choose to go with changing the background colour instead of the text itself like is usually done in syntax highlighters? While this does work, it looks rather blocky and has a somewhat jarring effect when taking in the text as a whole, which wouldn't be an issue were the latter method used.

The colours themselves might also do with some more consideration - not just specific combinations, but also considering why the highlighting would be useful.

  • With things like italics and bolding, does the affected text need to be a different colour, or just the characters affecting it?
  • What do people need to pick out, and what do people want to ignore? Making those a different colour would help in both cases, but if people tend to do either, like with references, then making it a particularly bold colour would be unwise.
  • Template, link, and table beginnings and ends come to mind as things that need to stand out because people can easily forget to close things...

But what sort of complexity could be supported? Could an open tag with no close on the page highlight everything after it to emphasise that it isn't closed? Could template pieces be different colours, with brackets one, parameters another, and values a third, and then these be more muted when used inside a reference or a css definition? Or would that be insane? Mind, I'm not saying that last sort of thing is needed or necessarily even a good idea, just wondering if it would be possible at this stage. -— Isarra ༆ 06:25, 14 September 2012 (UTC)[reply]

Thank you for the feedback! Let me answer your easier questions first. I am investigating improvements to browser compatibility, but I expect it will take at least another month before I feel the script is ready to be made into a gadget. The script highlights the background instead of the text because any method that highlights the text itself breaks the undo/redo buttons. wikEd requires you to click a button to update its text highlighting so that it breaks the undo/redo button as little as possible; I wanted something that just works.
Malformed syntax like an opening tag without a closing tag does produce odd results that will make the mistake obvious. The script could also be revised to pick apart individual bits of templates or only highlight beginning and ending syntax, though my inclination is to keep it as simple as possible.
Finally, the script is fairly customizable right now, please feel free to try different color combinations and let me know what you think looks best. —Remember the dot (talk) 02:36, 15 September 2012 (UTC)[reply]

Templates and expansion depth

 Done 80% - more in progress. -Wikid77 18:44, 29 Aug, 15:56, 31 Aug., 00:09, 2 September 2012 (UTC)[reply]

I was pointed here for this query but I am sure there is a forum for techie template talk.

I have been around here a while but I have only now encountered the message Page exceeded the expansion depth when editing a page. Seems they all go to Category:Pages where expansion depth is exceeded. Currently about 16.000 pages in it. Two of the templates that seem to do it are {{Automatic taxobox}} and also {{atn}} when there is no following archive page. I am no expert on templates or coding but should this be sorted out? -- Alan Liefting (talk - contribs) 22:12, 20 August 2012 (UTC)[reply]

That is excessive. Categories marked as {{Monthly clean up category}} are also in there, and they should not be. Most likely a subtemplate somewhere has recently been edited to make it more complicated - perhaps by only a tiny amount - but just sufficient to tip all these pages over the limit of 40 levels. --Redrose64 (talk) 23:02, 20 August 2012 (UTC)[reply]
One of the templates common to all those subcats is probably causing it. -- Alan Liefting (talk - contribs) 23:25, 20 August 2012 (UTC)[reply]
I thought of that - I took Category:Article sections to be split from April 2012 as one case and 5th Avenue Theatre as the other - I determined that the problem still existed if I stripped out everything except {{Monthly clean up category}} from the former, and {{Infobox Theatre}} from the latter case. Then I determined which subtemplates these two templates both used - and the only one these two have in common is {{max/2}} which hasn't changed in years. --Redrose64 (talk) 23:37, 20 August 2012 (UTC)[reply]
I think you're on the wrong track. It's probably the use of various string manipulation templates in both pages. Anomie⚔ 00:58, 21 August 2012 (UTC)[reply]
See Wikipedia:Village pump (technical)/Archive 99#Raising issue again: Page exceeded the expansion depth, Wikipedia:Village pump (technical)/Archive 99#Page exceeded the expansion depth? and Wikipedia:Village pump (technical)/Archive 100#Possible problem with the Article Feedback tool for previous discussions. My comment from the last still seems to apply for articles: "Sampling of Category:Pages where expansion depth is exceeded shows the main culprits are now {{Infobox German location}} (whenever the image_plan/Lageplan parameter is set) and species using one of several templates (even without parameters), for example {{Automatic taxobox}}, {{Speciesbox}}, {{Ichnobox}} or {{virusbox}}." All the four mentioned species templates cause it without any parameters. PrimeHunter (talk) 01:33, 21 August 2012 (UTC)[reply]
So how do we fix it? -- Alan Liefting (talk - contribs) 06:58, 21 August 2012 (UTC)[reply]
Create less complicated templates, or wait for Scribunto to be deployed (but that is still a few months away). —TheDJ (talk • contribs) 08:52, 21 August 2012 (UTC)[reply]
  • Species articles seem ok, non-fatal depth error: From working on those {Automatic taxobox} articles, I think the article contents are ok as is, because the depth-exceeded error is non-fatal there, but a long-term fix would be fine (or rewrite with Lua script). However, {Infobox_German_location} can be fixed easily (see below) to use efficient Template:Strfind_short, which avoids the 40-level limit, to even reformat 40% faster. -Wikid77 (talk) 02:57, 29 August 2012 (UTC)[reply]

First one in the category: Category:1911 Britannica articles needing updates from August 2012. NewPP of that page: Highest expansion depth: 41/40.

(Curiousity: sister categories (e.g. June 2012) with 41/40 and so categorised too is not in this list - let's "hopothese" this is just catsort that went wrong). {{Monthly clean up category}} is very suspected indeed, it is the only code on the page.

Solved the August 2012 example, individual page. -DePiep (talk) 07:34, 22 August 2012 (UTC)[reply]

Could it be this: This newPP limit is new this way (added recently to the newPP list). And the tracking category is from 8 May 2012 [1] by PrimeHunter. Has the newPP change + its category only surfaced existing pages, whose problem did not show this explicitly? -DePiep (talk) 05:33, 22 August 2012 (UTC)[reply]

Also discussed at Infobox_German_location, May 2012. -DePiep (talk) 05:39, 22 August 2012 (UTC)[reply]
List of causing/suspected templates (see also notes above):
* (please expand list here)
-DePiep (talk) 05:59, 22 August 2012 (UTC)[reply]
Continued for the cleanup talks: Category talk. Category talk:Pages where expansion depth is exceeded#Existing templates to be reviewed. -DePiep (talk) 06:18, 22 August 2012 (UTC)[reply]
Still unexplained: {{Monthly clean up category}} has ~4700 transclusions, but only ~300 show up in the excess category (as Category pages, so on top). Now see example Category:1911 Britannica articles needing updates from June 2012. Page source newPP says: expansion depth 41/40, but the category is not added. (also tried ~nulledit to trigger March 2012 -- no effect AFAICS). -DePiep (talk) 07:34, 22 August 2012 (UTC)[reply]
Depth 41/40 sometimes allowed: For some cases, a reported depth of 41/40 does not trigger "exceeded" and, remember, the top level is 1, not zero, so that 40-nested is actually level 41, counted from "1". -Wikid77 13:11, 1 September 2012 (UTC)[reply]
  • Fix Infobox_German_location to use Strfind_short: I have created a fix for the depth-exceeded limit, in Template:Infobox_German_location/sandbox2, as the update to use efficient Template:Strfind_short (7 levels), rather than slow Template:Str_find (23 levels), to avoid the 40-level limit, also center the plan-map, and even reformat 40% faster. The NewPP markup will show only 31 levels used, and 10,100 fewer preprocessor nodes, saving 2-3 seconds (40%) on reformat time. I thank everyone, above, who noted the problems and suggested the string-handling templates had exceeded the limits, in these extremely complex templates which I have spent months analyzing and updating. -Wikid77 (talk) 02:57, 29 August 2012 (UTC)[reply]
 Installed, thanks. -Wikid77 23:08, 29 August 2012 (UTC)[reply]
 Installed, more fixes needed. -Wikid77 23:08, 29 August 2012 (UTC)[reply]
  • Beware Infobox_Theatre uses embedded Infobox_NRHP: Although infoboxes nested inside others might look good as keeping within the same box, when Template:Infobox_NRHP is set "embed=yes" inside {Infobox_Theatre}, then the expansion depth increases by 7 levels deeper. So, when using {Convert} inside the double-nested infoboxes, the depth reaches 42 deep. In such cases, {Convert} must be reduced by the round-value parameter "|1" or such to reduce nesting by 7 levels, back to 35 deep, inside the double-nested infobox. I have edited article "5th Avenue Theatre" to unnest the infoboxes, and avoid limit exceeded. -Wikid77 23:08, 29 August 2012 (UTC)[reply]
  • Essay WP:EXPANSION about reducing depth: I have written another essay, this time as general title "WP:Expansion depth limit" (WP:EXPANSION) to begin to explain more ways to keep the expansion levels, in various types of articles, from exceeding the limit. Also essay: "WP:Avoiding MediaWiki expansion depth limit". We need to de-mystify these issues, for quicker fixes, so that people do not wander for months in frustration at the bizarre "exceeded" messages. Otherwise, this could result in people overwhelmed by too much bizarreness. Long-term, we need to raise the depth limit of 40 to be 60 or 80 or such. -Wikid77 23:08, 29 August 2012 (UTC)[reply]
  • Bio/species articles use Template:Speciesbox: Although they appear to format correctly, the exceeded-limit message comes from Template:Speciesbox, which uses the huge Template:Taxobox/core with numerous parameters, and no obvious extravagance of overly nested if-else-else-else-else. By using Template:Italic_title, it uses {Str_find} which runs 23 levels deep, and perhaps that is the cause of some exceeded-limit messages. However, the whole of Template:Speciesbox always runs about 36-38 levels (of the 40-level limit), and hence some functionality is stopped in over 4,500 articles. There is no policy to "explain-your-complex-template" so we will need to write the operational notes for Template:Taxobox/core/sandbox2, to illustrate a template "call tree" to show which subtemplates are deeply nested to levels 36-38, and then use those notes to determine where to trim the huge monster, which probably needs to be reduced by just 2 or 3 levels more, as the first step. More: After drawing the call-tree, I found Template:Taxobox/taxonomy shows the taxon-name rows, and Template:Taxobox/taxonomy/3 causes the "exceeded-depth" and must be shortened below 33 levels. I have updated some template /doc pages to explain operation and submitted /sandbox updates to those templates at Template_talk:Taxobox, to fix the exceeded-depth. The trial Template:Speciesbox/sandbox2 can be used to test the fixes in any article, using all coordinated "/sandbox2" versions of templates. I think that completes this PUMPTECH topic for now. -Wikid77 (talk) 00:17/15:56, 31 Aug., revised 13:11/00:09, 2 September 2012 (UTC)[reply]

Great progress, and thanks for your persistence. Look like the taxobox is the main culprit now. Cheers. -- Alan Liefting (talk - contribs) 09:03, 7 September 2012 (UTC)[reply]

  • Multiple {Taxobox} depth problems: There are multiple depth problems after Template:Taxobox/core, so I am rewriting Template:Taxobox/taxonomy and Template:Get_regnum() and others in the 60-stack of taxon names. Many articles will then fit, but I think some others will still hit the depth limit. It is an overwhelmingly complex system, due to the lack of expansion-depth counts for each template; and perhaps the expected levels were 50 with the 41-level limit. Hence, many levels must be reduced to fit all cases. However, some can be fixed now by merely setting |taxon={{PAGENAME}}. -Wikid77 (talk) 23:35, 9 September 2012 (UTC)[reply]

Blinkity Blink!

I just ran across a username that looks like this:

~~Username~~ Talk Page

This is invoked with <span style="text-decoration: blink">.

Blink? BLINK?? BLINK??? After the pitched battle to Kill The Undead Thing in HTML, here it is, like a zombie, polluting WikiMarkup. Kill it. Kill it with Fire.

In case I was too subtle, I dislike the blink tag. see Blink element, [ http://catb.org/esr/html-hell.html ], [ http://www.mcli.dist.maricopa.edu/tut/tut17.html ], [ http://www.montulli.org/theoriginofthe%3Cblink%3Etag ], and [ http://boingboing.net/2010/04/08/blink-tag-considered.html ]. --Guy Macon (talk) 14:12, 26 August 2012 (UTC)[reply]

In my opinion, absolutely annoying and disruptive. Is is possible to simply approach the user and offer some guidance and constructive rationale for changing it? Cindy(talk to me) 14:31, 26 August 2012 (UTC)[reply]
Wikipedia:Signatures#Appearance and color. Per guideline, this is inappropriate. --Izno (talk) 14:34, 26 August 2012 (UTC)[reply]
Thanks for the guidline link. I will pass it on to the users (who I am choosing not to shame here). He is a reasonable fellow so there should be no problem.
To look at the larger picture, why do we allow blinking at all? There is only one use for it... --Guy Macon (talk) 14:43, 26 August 2012 (UTC)[reply]
We allow most if not all CSS. Simply because it is bad practice doesn't mean we shouldn't. It's a freedom that authors should have to use, if even it should only be used in the rarest of occasions. --Izno (talk) 14:47, 26 August 2012 (UTC)[reply]
Well, I also came over exactly the same signature and have exactly the same feelings. I hope there is a way to cut off such annoying markup, or at least disable it in preferences. — Dmitrij D. Czarkoff (talk) 15:54, 26 August 2012 (UTC)[reply]
For the record: I just found out that "text-decoration: blink;" part isn't recognized by my browser, so I see this:

~~Username~~ Talk Page

And I still find it overly annoying. — Dmitrij D. Czarkoff (talk) 16:22, 26 August 2012 (UTC)[reply]
It's Firefox only... Mozilla probably forgot to take it out of the Netscape codebase... or didn't they? — Edokter (talk) — 16:45, 26 August 2012 (UTC)[reply]
Probably left in for backwards compatability. It can be disabled in your browser by entering "about:config" into your address bar, clicking through the warning, entering "browser.blink_allowed" into the search box, and then double-clicking the line to change from true to false. Anomie⚔ 18:53, 26 August 2012 (UTC)[reply]

BTW, I think that [ http://catb.org/esr/html-hell.html ] should be promoted as signature formatting policy. — Dmitrij D. Czarkoff (talk) 18:44, 26 August 2012 (UTC)[reply]

Just did a quick test; blinks in Firefox, doesn't blink in IE, Chrome, Opera and Safari. (Latest versions, of course. I am pretty sure that if you go back far enough, Opera and IE will blink.) As for Wikimarkup allowing most if not all CSS, I can think of some clever forms of vandalism that would be invisible to most patrollers but visible to users using certain browsers:

Test 0: Test <-- Does anybody not see the word "Test" in bold here? (No CSS)
Test 1: Test <-- Does anybody not see the word "Test" in bold here? (visibility:hidden)
Test 2: Test <-- Does anybody not see the word "Test" in bold here? (display:none)
Test 3: Test <-- Does anybody not see the word "Test" in bold here? (font-size:1%)
Test 4: Test <-- Does anybody not see the word "Test" in bold here? (color:white; background-color:white)
Test 5: Test <-- Does anybody not see the word "Test" in bold here? (color:#fefefe; background-color:#ffffff)
Test 6: Test <-- Does anybody not see the word "Test" in bold here? (position:fixed; bottom:16383px; right:16383px)
In my opinion, Wikimarkup should restrict some CSS tricks. --Guy Macon (talk) 20:53, 26 August 2012 (UTC)[reply]

I see tests 0 and 3, spot tests 4 and 5 (I use modified color scheme) and don't see the rest of them. And I believe that such instances should be patrolled manually anyway — they show up in diffs. — Dmitrij D. Czarkoff (talk) 21:11, 26 August 2012 (UTC)[reply]
I think anyone who has a blink tag in their signature needs shooting, minimum. I mean some signatures are anti-social but that's the worst I've seen. Secretlondon (talk) 21:25, 26 August 2012 (UTC)[reply]
On FF13, I see Test 0, 4 and 5 show up on highlight, 1 is a blank space, 2, 3, and 6 don't even show the space for the word. --Nouniquenames (talk) 05:48, 27 August 2012 (UTC)[reply]
Perhaps we should have Wikipedia:Edit filter add a "styling added" tag to make it hard for patrollers to miss such things? I didn't realize we had so many filters until I ran across Special:AbuseFilter. --Guy Macon (talk) 21:56, 26 August 2012 (UTC)[reply]
Well, probably we should have edit filter for all or most CSS and HTML, and abuse filter for "blink" or "marque" within HTML or CSS... — Dmitrij D. Czarkoff (talk) 22:19, 26 August 2012 (UTC)[reply]
And for visibility:hidden, display:none, font-size:[>10%], color:white, color:#[e-f][*][e-f][*][e-f][*], position:fixed, etc? See Whac-A-Mole. :) --Guy Macon (talk) 22:31, 26 August 2012 (UTC)[reply]
These can have legitimate uses under some circumstances (collapsing, spans in extra large labels, templates with dark background, etc.), but when one tries to add <blink> or <marquee>, he is definitely trying to secure mass vision loss among Wikipedians. — Dmitrij D. Czarkoff (talk) 23:31, 26 August 2012 (UTC)[reply]
If you set a filter, you'll be surprised about how often we use these. Navboxes, infoboxes, user boxes article history and tons of other templates make actively use of many of these. If you want to patrol them, I don't think anyone will stop you, but I doubt it's anywhere near as problematic as you think. —TheDJ (talk • contribs) 12:09, 27 August 2012 (UTC)[reply]
Yes please stop the blinking. and while you're at it, the "background/blurring" technique that's been popping up lately - it makes it hard (for me at least) to read the signatures at all. - jc37 22:59, 26 August 2012 (UTC)[reply]
IMO signatures customization should be limited to choice of prefix ("-", "–", "—", "--", etc). — Dmitrij D. Czarkoff (talk) 23:21, 26 August 2012 (UTC)[reply]
Yep, I agree. We are all equals here so our signatures should reflect that. -- Alan Liefting (talk - contribs) 00:54, 27 August 2012 (UTC)[reply]
Very much agreed, with all 3 above. Personal aesthetics belong only on our Userpages, not forced on everyone everywhere.
(Although, a garish signature is often a handy warning-device, for anyone interacting with them... >.> ) -- Quiddity (talk) 23:13, 28 August 2012 (UTC)[reply]

See also: Wikipedia:Edit_filter/Requested#Abusable_CSS. —TheDJ (talk • contribs) 13:50, 27 August 2012 (UTC)[reply]

I'd suggest implementing User:Ais523/highlightmyname2.js as a gadget, possibly even turned-on by default. It replaces the only good reason to color one's own sig (making it visually stand out, so that you can scan down a long talkpage looking for your own comments, and any new replies). I've used it for years, with great satisfaction. My name is lime-green, whereever it appears in Wikipedia (talkpages, histories, etc) but nobody else has to see that, nor should they have to. -- Quiddity (talk) 23:13, 28 August 2012 (UTC)[reply]

I've started an RfC on signatures formatting at Wikipedia talk:Signatures#Simplifying signatures. — Dmitrij D. Czarkoff (talk) 00:13, 31 August 2012 (UTC)[reply]

Note also the draft policy at Wikipedia:Manual of Style/Accessibility/Signatures which I started some time ago, and which could be modified and adopted as a result of this RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:46, 3 September 2012 (UTC)[reply]

What about removing the ability to customise signature markup, add 

<span class="…"></span>

to the standard, and use User_style? Users could publish the css for their signature for others to copy. — Preceding unsigned comment added by Ζετα ζ (talk • contribs) 20:56, 8 September 2012 (UTC) Sorry everyone – yes it is me. » Ζετα ζ (talk) 22:21, 9 September 2012 (UTC)[reply]

I actually like slightly non-standard signatures, provided they're not in-yer-face hideous. It helps me to 'recognise' which people are involved in a discussion, and see an individual person's comments without having to use Find to locate their sig. I'm talking here about different colours, different fonts, maybe a surrounding box, etc. Not things which flash, ping, or go bump in the night ;P Pesky (talk) 06:36, 9 September 2012 (UTC)[reply]
In my opinion, the best answer is an option to turn off seeing sig customizations in my preferences, with "on" being the default. Plus, of course, a good trout slap for sigs that blink, look out of focus, etc. --Guy Macon (talk) 01:07, 10 September 2012 (UTC)[reply]

Could it be possible to watch move logs, deletion logs etc. separately?

Resolved
 – ···Vanischenu「m/Talk」 14:47, 9 September 2012 (UTC)[reply]

This question was first asked at the Help Desk (archived) which was not resolved there. Thanks to Vchimpanzee who guided me to ask here.

  1. Is there any way I can see move logs or deletion logs separately in Watchlist, RecentChanges, RecentChangesLinked or anything similar?
  2. Is it technically possible?
  3. And does it worth proposing to include them?

Thank you···Vanischenu「m/Talk」 22:26, 30 August 2012 (UTC)[reply]

  1. You can see the move log at Special:Log/move, and the deletion log at Special:Log/delete. These pages will show all moves and deletions, with the most recent listed first (like recent changes). I don't know any way to get anything similar for your watchlist or related changes, though.
  2. It should be technically possible for the developers to add an option to filter the watchlist or recent changes to only show logs. It might also be possible with a user script, though I don't know how.
  3. Proposing something is a good way to find out if anyone is interested. – PartTimeGnome (talk | contribs) 20:44, 4 September 2012 (UTC)[reply]

Thanks you so much. I will propose it, then.···Vanischenu「m/Talk」 14:47, 9 September 2012 (UTC)[reply]

A 64KiB template and automatic succession boxes

Further information: Project:Administrators noticeboard § Recreating content, and Project:Templates for deletion/Log/2009 April 6 § Template:NYRepresentatives

A 64KiB template and its technical impact are being discussed on the Administrators' Noticeboard. You can see the argument there, and at the prior templates for deletion discussion, for yourself so I won't repeat them. As a side effect, however, I have invented automatic succession boxes:

(Ignore the style issues. The Test2 Wikipedia has barely one skin installed.)

An automatic succession box works out where in the succession list, given as a table of data, the transcluding page is, and creates a succession box appropriate to that page. Articles don't get thousands of inbound links, there's no need for multiple templates or collapsible lists, and there's not as much pressure on the template expansion buffers. Also, as you can see, the workload is divided between a data module specific to the sucession and a generic code module that does the work of making the wikitext and can work with a wide range of succession types. Here are some mildly interesting statistics:

Revision 37727 of David Woodcock on the Test2 Wikipedia Revision 509983251 of Template:NYRepresentatives
NewPP limit report
  • Preprocessor node count: 8/1000000
  • Post-expand include size: 5618/2048000 bytes
  • Template argument size: 0/2048000 bytes
  • Highest expansion depth: 3/40
  • Expensive parser function count: 0/500
  • Lua time usage: 0.007s
  • Lua memory usage: 463 KB
 NewPP limit report
  • Preprocessor node count: 694/1000000
  • Post-expand include size: 21223/2048000 bytes
  • Template argument size: 12449/2048000 bytes
  • Highest expansion depth: 13/40
  • Expensive parser function count: 5/500

Uncle G (talk) 14:26, 31 August 2012 (UTC)[reply]

I have no idea why you are including these two table entries with NewPP limit reports. However, above it seems that in some test environment you are suggesting a complicated template that will call other templates. I am not sure if this alleviates the need to transclude multiple templates or not.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 15:46, 31 August 2012 (UTC)[reply]

Please tell me why you think that crappy layout in the test David Woodcock page that you propose counts as a substitute for a congressional navbox. It almost looks like infobox content.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 15:55, 31 August 2012 (UTC)[reply]
Have a look at other content in Category:United States House of Representatives delegations navigational boxes and see what we are trying to do.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 15:58, 31 August 2012 (UTC)[reply]
Why would you start this section and then not come and talk about the issue?--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 13:04, 4 September 2012 (UTC)[reply]

if you remain unwilling to discuss your suggested templates, I will revert to my own idea.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 13:51, 8 September 2012 (UTC)[reply]

I guess you are going to make me chase you down.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 06:51, 12 September 2012 (UTC)[reply]

Upcoming changes to the edit window (please read)

Hey all :).

the current editing interface

So, the new Micro Design Improvements team has been looking at various things to tweak to try and make Wikipedia's interface less clogged with stuff. One of these is improvements to the "edit" window, which I want to give you all a bunch of advance notice of - obviously, everyone uses it, and so I don't want to just drop it on enwiki without letting anyone know :). A couple of important disclaimers - first, if you're on anything other than vector, you shouldn't notice any difference in your browsing and editing experience. If you are on vector, but don't have the enhanced editing toolbar switched on, you'll see some changes, but one of them (removing the edit tools at the bottom) won't take effect. You'll only get the full package with both vector and the enhanced toolbar. With that in mind, here's a TL;DR bit on the changes that are part of this:

A mockup of the changes we are making (note; "watchlist this page" will still actually appear, the mockup is just slightly off).
  1. Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.
    Rationale: This line is primarily composed of guidance as to what sort of content is appropriate for Wikipedia. (Several projects moved such guidance here from MediaWiki:Edittools when this message was introduced after the license switch.) Having it below the edit window almost ensures that people will only read it after they have tried to make changes - it is of little use. On the other hand, if we move it above the edit window, we have an opportunity to educate people about what is or is not appropriate before they start writing.
  2. Removing the reference to a help page.
    Rationale: At first glance, this might appear counterintuitive. The logic is that the advanced editing toolbar (which all new users are presented with by default) already includes a link to a "cheat sheet" of markup. The help page linked in the text, on the English Wikipedia, is a similar cheat sheet, creating duplication and taking up unnecessary space.
  3. Removing half of the "if you do not want your writing..." line (MediaWiki:wikimedia-editpage-tos-summary) – that bit concerned with the Terms of Use – and moving the other half above the edit window.
    Rationale: Again, the message (even the legal text) has been customised by the English Wikipedia and several projects added here information/warnings previous shown in the edittools; the advice will be of most use if it is shown to a user before they have contributed. At the moment, this text is not only after the edit window but also after the "save page" button – people may not even see it before submitting their changes. The text relating to the Terms of Use is a duplication of the existing disclaimer, and one that Legal concludes serves no purpose.
  4. Moving the "by clicking Save Page..." text to below the edit summary window.
    Rationale: The action is related most closely to "save page". Under the current workflow, someone is presented with it, then presented with unrelated options (edit summaries), and only then given the "save page" button. Moving it more closely ties the advice to the action it relates to.
  5. Putting the lists of templates and hidden categories under small drop-down menus.
    Rationale: both elements have some use cases (for example, identifying subtle template vandalism), so we certainly don't want to remove them, but they're not much use for most editors: they just take up space and present users with a lot of text and links that serve (to them) no clear purpose. A nice middle ground is to stick them under dropdown menus: if they're wanted, they can easily be found – if not, they don't take up as much space.
  6. Removing the "edit tools" toolbar after "save page" (MediaWiki:Edittools).
    Rationale: A lot of the functionality here is duplicated in the enhanced editing toolbar, which has been enabled by default for new accounts for quite a while for a long time. In addition, its current placement makes it of little use: people are only presented with it after they've made their changes. This change won't appear if you don't have the enhanced toolbar on.

The screenshots to the right may provide a more useful comparison of "before" and "after"; again, most of you won't notice a change :). We also have it deployed on a prototype server here, which you may want to create an account on so you can see how it works in practice. If you've got any feedback, I'd love to hear it, be it positive or negative, and if you've got any more ideas for improvements we could make you can drop them here, on the Micro Design Improvements talkpage, or on my talkpage. We're probably not going to be deploying until the week of the 17th of September, to allow both community discussion and feedback and some time for browser testing, which is a good time to note (nice segue, Oliver!) that if you find any issues you should let me know, and I'll do my best to get them fixed. Thanks! Okeyes (WMF) (talk) 20:23, 5 September 2012 (UTC)[reply]

Looks good. No major issues that I can see. IRWolfie- (talk) 20:45, 5 September 2012 (UTC)[reply]
Looks good to me too. Bring on the Naysayers and doom and gloomers! :-) Kumioko (talk) 20:54, 5 September 2012 (UTC)[reply]
  • Is this only for English wikipedia, or why is this linked to a mediawiki page? Choyoołʼįįhí:Seb az86556 > haneʼ 20:57, 5 September 2012 (UTC)[reply]
    At the moment, this is only going to be deployed on enwiki; we don't want to fling the change out everywhere because it's a pretty big thing to be altering for every project. We'll hopefully ramp it out over time - first to other projects that request it, then to a wider userbase, then stick it as the default, so on, so forth. The location of the team page (MediaWiki.org) is because the team's projects overall are hopefully going to be for a much wider range of our wikis, and so it's not that appropriate to host it on an individual "in use" wiki. I appreciate this makes it slightly harded to follow the conversations - I'm looking for ways around this :S. Okeyes (WMF) (talk) 21:01, 5 September 2012 (UTC)[reply]
(OK. Once you get to other wikipedias, please keep in mind removing the edit-toolbar is in many cases a bad idea. Going through the list of all possible letters just to find the one you need each and every time is tedious, and typing Cherokee and Inuit is impossible without it. Choyoołʼįįhí:Seb az86556 > haneʼ 21:06, 5 September 2012 (UTC))[reply]
Heh; noted :). Does the enhanced toolbar not include that functionality? I can imagine it wouldn't for the particularly obscure characters (or those in non-westernised languages) but, generally-speaking, what is the "special characters" tab missing? Okeyes (WMF) (talk) 21:08, 5 September 2012 (UTC)[reply]
I'd note that Siebrand's team is working on mw:Universal Language Selector, which may help somewhat. Okeyes (WMF) (talk) 21:17, 5 September 2012 (UTC)[reply]
What you'd call obscure :P American letters, for example >> Ꭰ Ꭱ Ꭲ Ꭳ Ꭴ Ꭵ Ꭶ Ꭷ Ꭸ Ꭹ Ꭺ Ꭻ Ꭼ Ꭽ Ꭾ Ꭿ Ꮀ Ꮁ Ꮂ Ꮃ Ꮄ Ꮅ Ꮆ Ꮇ Ꮈ Ꮉ Ꮊ Ꮋ Ꮌ Ꮍ Ꮎ Ꮏ Ꮐ Ꮑ Ꮒ Ꮓ Ꮔ Ꮕ Ꮖ Ꮗ Ꮘ Ꮙ Ꮚ Ꮛ Ꮝ Ꮜ Ꮞ Ꮟ Ꮠ Ꮡ Ꮢ Ꮣ Ꮤ ᐊ ᐃ ᐅ ᐋ ᐄ ᐆ ᐸ ᐱ ᐳ ᐹ ᐲ ᐴ ᑉ ᑕ ᑎ ᑐ ᑖ ᑏ ᑑ ᑦ ᑲ ᑭ ᑯ ᑳ ᑮ ᑰ ᒃ ᒐ ᒋ ᒍ ᒑ ᒌ ᒎ ᒡ ᒪ ᒥ ᒧ ᒫ ᒦ ... etc. (can you even see those?) Instead of flooding the special characters-thing, just keep the edit toolbar. Choyoołʼįįhí:Seb az86556 > haneʼ 21:18, 5 September 2012 (UTC)[reply]
I can, yep :). Would the language selector not help? Okeyes (WMF) (talk) 21:22, 5 September 2012 (UTC)[reply]
I doubt it. It just wouldn't be worth it to this for the <200 people who'd actually use it. Just don't switch it off all of the sudden, that's all I was worried about. Choyoołʼįįhí:Seb az86556 > haneʼ 21:26, 5 September 2012 (UTC)[reply]
We'll try not to :). Like I said, we're not planning on scaling it out immediately - and when we do scale it out more widely I'm sure we can try to work together a CSS hack or opt-out for wikis that are going to struggle. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]
What are you using to generate the dropdown menus and what does it look like rendered in FF, Chrome, IE, etc? Protonk (talk) 21:12, 5 September 2012 (UTC)[reply]
This is a question for Rob Moen; I'll get him in here :). It renders very nicely in Firefox - I invite any and all to test the prototype and see!
Rob reports he wrote a jQuery module for it; it's at /trunk/extensions/Vector/modules/jquery.footerCollapsibleList.js :). Okeyes (WMF) (talk) 00:29, 6 September 2012 (UTC)[reply]
Do we really need to create yet one more script for collapsing things? Why not to use (improving if needed) the jQuery.makeCollapsible which is already available on MW? Helder 21:30, 6 September 2012 (UTC)[reply]
Aye, there are too many already. It's kind of scary, and makes getting fixes for any one only that much harder. -— Isarra ༆ 08:07, 7 September 2012 (UTC)[reply]

Dark Grey Text on light grey backgrounds or fills is considered accessible and easy to read. If we go any darker the color will compete with the left navigation bar and the text will be hard to read. So that was a bit of a constraint. See: http://uxmovement.com/content/when-to-use-white-text-on-a-dark-background/ Also here is the color pallete that is being used by the foundation: http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Color_Usage. We are are looking at testing this a little bit.Vibhabamba (talk) 00:13, 6 September 2012 (UTC)[reply]

The darkness already competes with the rest of the screen in the vector skin. -— Isarra ༆ 17:23, 6 September 2012 (UTC)[reply]

Some thoughts:

  • Overall this is much simpler and a nice improvement in terms of usability. Yay!
  • 'Cancel |' between two buttons looks weird.
  • That grey is annoyingly dark.
  • While I like the collapsing of the templates and hidden categories lists (and indeed have been using a version for awhile already, though it doesn't work nearly as well as I'd like either), I have some nitpicks with the particular implementation here.
    • The collapsing/uncollapsing animation is probably slower than it needs to be, but why does it need to be animated at all? This is technical stuff, which if we want to see it at all, probably want to see it immediately.
    • Remembering the collapsed/uncollapsed state with a cookie may not be the best approach, given how very many templates a lot of things have and that even if on some pages or in some cases the list merits uncollapsing, on most it really doesn't and just gets in the way. As such I would put forward that by default they should always start collapsed, regardless of how it was left on the last one. A UPO to have them start out open or maybe disable the collapsing entirely would be useful for some people, though.
    • There are times when it would be useful to have the list headers say how many things there are, so instead of 'View templates in this Page', it might say 'View 59 templates used on this page' or some such.
    • When there are only one or two templates on a page (or any random number <5), is it really worth collapsing them by default?
  • Geese.
  • I'm not sure moving the warning line to the top will make it less likely to be ignored; since the buttons are at the bottom it seems like people may pay more attention there, especially when there is less clutter there.

-— Isarra ༆ 21:33, 5 September 2012 (UTC)[reply]

I really like the remember of collapsed state. And given past experience with the sidebar and collapsibility, I think most other users would prefer remembering this as well. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)[reply]
I agree about remembering with the sidebar, but that is also effectively the same sidebar on every page; the same cannot be said for specific content. Different pages can have very different templates/hidden categories, and the remembering is not page specific - having uncollapsed the list on someone's talkpage does not mean one wants to see the list of every component template included in a content page's infobox. -— Isarra ༆ 22:59, 5 September 2012 (UTC)[reply]
Excellent point :). I'm going to add "remembering with the sidebar" to our to-do list as part of a greater "sticky settings" project for non-context-specific menus. Okeyes (WMF) (talk) 23:18, 5 September 2012 (UTC)[reply]
Cookies are really not helpful for me, as my browser clears them regularly. There needs to be an account setting or gadget to make the template info fully visible to troubleshoot template issues before this goes live, or dealing with them will be pain. Troubleshooting templates can often involved checking templates on multiple pages, and constantly unhiding them would be a pain. Monty845 23:26, 5 September 2012 (UTC)[reply]
Totally agreed :). So, we've now actually got two ways of remembering a setting; 1, cookies, which have a lot of problems, or 2, "sticky settings". These are basically hidden preferences options. So, for example, we could implement sticky settings here and it would remember it as a 'preference' - not one that appears in "my preferences", but something ever-present that doesn't go away when you clear your cookies. Okeyes (WMF) (talk) 23:57, 5 September 2012 (UTC)[reply]
The suggestion with the count on the collapsed header seems wonderful, we should probably implement that in core however. The animation should be removed in my opinion yes. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)[reply]
Your suggestion seems to be one more use case for the request to allow disabling interface animations.
I also like the idea of displaying the number of templates in the page when the list is collapsed. Helder 21:30, 6 September 2012 (UTC)[reply]
Hi Issara Thanks for your feedback. I helped Oliver out with this feature. Could you explain a bit more why the Cancel is feeling weird? Is it just visual or is it a workflow issue? We wanted to clearly separate the Save + Cancel from the Preview + Show changes. From some data analysis we have seen that quite a few users (both new and advanced) are using the preview feature. Eventually we hope to improve the workflow by moving the Preview to a more contextually appropriate position in the workflow. Also is the grey fill (bottom of the edit field) distracting? The reason we introduced a fill is that it lends finality to the edit workflow. Would be helpful to understand why its annoying. Thanks Vibhabamba (talk) 23:32, 5 September 2012 (UTC)[reply]
The cancel button just looks really weird like that, randomly between two buttons and with a sinlge | for no apparent reason. Don't know if it would affect workflow aside from maybe causing people to accidentally hit that instead of the preview button since that's where the preview button normally is, but on the other hand, what is contextually inappropriate about where the preview button is normally?
And when there is that much of it, the 'fill' is just too dark for the page. The colour itself ain't inherently bad, but that much of it results in a domination of the space of the page when the object in question should be no more dominating than the edit box itself. Look at a screenshot and zoom out; it becomes more immediately apparent when the details aren't present. -— Isarra ༆ 08:07, 7 September 2012 (UTC)[reply]
I agree that the Cancel Button looks a little strange. From instrumenting this page we have learned that both new and advanced users extensively use the Preview Button. Currently it comes after the Save action and falls below the page fold. If we create a clean grouping for save and cancel, eventually we can move Preview closer to the edit field, so a user can access preview without wandering away from the edit window. Do you have feedback/ suggestions around this..? Thanks Vibhabamba (talk) 22:35, 7 September 2012 (UTC)[reply]
We also want to upgrade to a simpler keyboard shortcut for it. Can you think of better (one? Vibhabamba (talk))
Suppose we did turn on the side-by-side preview and publishing things, it could look something like this. Nice, simple, and elegant. -— Isarra ༆ 03:40, 9 September 2012 (UTC)[reply]
The cancel button should really be just that - an actual button button, probably at the end of the others, since that way it would be (and is currently, for that matter) opposite in position from the edit button, the one from which it is technically the opposite. And I don't see why the buttons should be split up at all - they are all actions that can be taken with the open page, so reasonably they should be together so people can see what all their options are in one place, though that should be closer to the editbox itself, indeed. Something to consider might also be to repeat them at the top of the editbox - such that the page, from top down, might go something like this:
  • (preview or diff)
  • (any relevant editnotices)
  • short copyright etc disclaimer thing if needed
  • save cancel buttons
  • editbox
  • (charinsert edittools)
  • short further disclaimer/notes thing if needed
  • edit summary field and description, all on one line
  • (minor edit and watchlist checkboxes)
  • save preview diff cancel buttons
  • (transclusions list)
  • (hiddencats list)
Where parentheses indicate things that may show up depending on action taken, user preferences, who is editing, and the page in question. Aside from the extra disclaimer at the top (do we really need that anyway?), this is basically what you get with a default MediaWiki install (and even more so when the side-by-side preview and publishing labs features are enabled, which are pretty cool and also something we might want to consider here) when not cluttered up with an overabundance of warnings and disclaimers and 'Please note's. Frankly our main problem here is simply that we have so much stuff everywhere, which is unfortunately a problem with the entire project, manifesting not just in the interface, but in policies, templates, processes, even in the way people communicate. Nevermind everything else; one thing we really need to do is look into getting rid of all that extra clutter that has been added over the years, because nearly all of that is redundant and/or not actually helpful. -— Isarra ༆ 00:46, 9 September 2012 (UTC)[reply]
  • I understand the rationale behind removing the editing help button; however, I'd like to see a study performed to see if the button is being used before doing that. We could do the rest of the changeover and leave that in if we need time. I think it could work to do a 30 or 60 day study and (unless there's a better way to do it) turn that link into a new redirect to the intended page. Then count the visits to the redirect. In addition, removing the editing tools would be a mistake. The enhanced editing toolbar is enabled on my account and there are things that are not duplicated. I use the editing tools toolbar for a few things. Em dashes, nonbreaking spaces, and {{#tag:ref||group="nb"|name=""}}. I would support adding a new dropdown for wiki markup to the toolbar as an alternative. Ryan Vesey 21:43, 5 September 2012 (UTC)[reply]
    Expanding on the special characters is probably a good idea :). I disagree on the "if the button is being used" point, though. So, it's possible that some people are clicking it. That doesn't show it's a good thing - it just shows that we're presenting them with the option and they're taking advantage of it. When they click it, they're sent to a page that doesn't include anything that the "help" tab doesn't, doesn't include a few things the "help" tab does, and is in a much longer format (and requires to to go away from the edit window). I do like the idea of maybe turning it into a redirect to the help function in the toolbar, if we can do that and if there's a use case. Okeyes (WMF) (talk) 21:50, 5 September 2012 (UTC)[reply]
    See Wikipedia:Village_pump_(proposals)#Message_on_search_results_page for something that is clicked often, yet not really helping along users. A way to measure this is a good idea, but we need a different metric in that case I think. —TheDJ (talk • contribs) 22:05, 5 September 2012 (UTC)[reply]
    It is already possible to customise the WikiEditor's edit toolbar to add the buttons you need. And I think this is a better approach than not providing a way for users who do not use it to be able to remove that content (bug 11130, open since 2007). Helder 21:30, 6 September 2012 (UTC)[reply]
  • I do not object, which is surprising. Evanh2008 (talk|contribs) 23:13, 5 September 2012 (UTC)[reply]
  • Question about preference gadgets - There are at least a handful which interact with the html you are changing. Have you gone through and tested this will all the gadgets offered in Preferences? Also, how are you changing this just on Vector? Is there a way to override these interface messages just on one skin without changing them on the others? —Cupco 00:28, 6 September 2012 (UTC)[reply]
    The changes should only impact on Vector, yep. What preferences are you referring to? Okeyes (WMF) (talk) 00:30, 6 September 2012 (UTC)[reply]
    "Add two new dropdown boxes below the edit summary box with some useful default summaries" seems the most likely to be affected. —Cupco 10:43, 6 September 2012 (UTC)[reply]
    That, I haven't checked; I will :). But I think we're going to be horribly restrained in the future if we can only act when there's no conflict with any gadget anyone has created and got consensus on. Okeyes (WMF) (talk) 10:55, 6 September 2012 (UTC)[reply]
  • Very Good Nice clean layout and well organized. It gives priority to the text that needs it. It also fixes the wall-o-text that confuses less experienced users. Thanks to all involved. Good job. 64.40.54.83 (talk) 03:41, 6 September 2012 (UTC)[reply]

Save/Preview buttons should be higher

Currently, the position of the Save/Preview buttons, as below the rule-spam blurb, "By clicking the Save Page..." is extremely irritating for the amount of up/down scrolling needed to reach them. Instead, they should be just 2 lines below the edit-summary field, with blurb at end:

Edit summary (Briefly describe the changes you have made)
  [___________________________________________________________________]
  Preview of edit summary: (/* Upcoming changes to the edit window)
Template:J you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.

In general, when designing a computer interface, avoid putting common menu items "78 miles" away from the input/edit areas. To avoid accidental clicks, then 2 lines away is sufficient. Currently, the Save/Preview buttons are about 13 lines(!) away from the edit-area, which is like "79 miles" travel in the computer-mouse world. In fact, I had to scroll the screen several times just to view those buttons while writing this text. I understand that rule-spam is needed, at first, to explain the rules to people who read everything on a screen before clicking any buttons, but for the rest of the world, all those rule-spam blurbs are, well, spam cluttering the screen. Perhaps there could be a button: [Hide instructions]. Anyway, thanks for discussing the issues, even if the screen cannot be improved very much. People have talked about having custom edit-windows which would be better for veteran editors who get dizzy from all the unnecessary up/down scrolling to get the "Show changes" button. -Wikid77 (talk) 03:39, 6 September 2012 (UTC)[reply]

New editors need to be shown those warnings. Established editors can make them disappear, using the code at Wikipedia:Tip of the day/November 22, 2008 -- John of Reading (talk) 07:25, 6 September 2012 (UTC)[reply]
We can't actually put the disclaimer under the "save page" button; it's not a disclaimer :). That text is the formal release that allows us to use the content you're posting, and allows everyone else to use it, too - and so it has to go above the "save page" button (we had looked into simplifying it and legal said no). Having it below the save page buttons complicates whether or not it's actually been accepted if someone's hit save: they may not have (or could argue) that they didn't see it. I would strongly recommend against using a CSS hack to remove this, for those reasons. I'll give Legal a poke and see if they have any additional clarification or comment they can add here :). Okeyes (WMF) (talk) 10:31, 6 September 2012 (UTC)[reply]
Note no one is talking about any sort of site-wide CSS hack to hide it, or even a gadget. Just individual users, presumably knowing what they're doing, editing their Special:MyPage/common.css. See Wikipedia:Village pump (proposals)/Archive 69#Reducing boilerplate below edit box for a representative past discussion. Anomie⚔ 17:13, 6 September 2012 (UTC)[reply]

Any chance of moving the linked part of the "Edit summary" text, immediately above the Edit summary box, away from the beginning of the line? - I'm forever accidentally clicking the link when trying to enter an edit summary. - Arjayay (talk) 11:30, 6 September 2012 (UTC)[reply]

That's something we hope to look into in a second round of improvements :). One idea that people have suggested is trying to include that text in the edit summary box itself. So, the box would have grey text of "explain what changes you have made" in it that vanish as soon as you click it/start typing text in/whatever. Random idea, not fully thought-out yet; opinion? :). Okeyes (WMF) (talk) 11:47, 6 September 2012 (UTC)[reply]

I really dislike changes 1 and 6. Putting a disclaimer above the edit window strikes me as being more clutter rather than less. Just put it under the license line, like it was before. As for change 6, I much prefer the "edit toolbar" to the advanced toolbar for many functions. The advanced toolbar is great for citations, but when I need wikitext, I hate it because it requires a ton of very careful scrolling just to get anywhere, whereas the edit toolbar just requires selecting the proper dropdown menu and then no scrolling. It's much, much easier to use. Sven Manguard Wha? 02:48, 7 September 2012 (UTC)[reply]

I think I agree, if what you're saying is you like mw:Extension:CharInsert and don't want to see it removed. Hereabouts a lot of folk probably won't have much use for it, but some certainly do, and it is an effective interface for what it does. Frankly I'd say the approach Commons took to that is a good one - if folks want it, they can enable it with a gadget or some such. Otherwise there is no need to clutter things up. -— Isarra ༆ 08:07, 7 September 2012 (UTC)[reply]

Having such a huge gap between the editing box, the edit summary and the save / preview / show changes is really annoying. I'm used to click on "minor changes" and save by barely moving the mouse. No I have to find the buttons well below. Perhaps you could put both the "By clicking the "Save Page" button, you agree..." and "Please note: When you click Save page..." above the editing box. --NaBUru38 (talk) 19:40, 12 September 2012 (UTC)[reply]

This, we are fixing :). Okeyes (WMF) (talk) 00:32, 13 September 2012 (UTC)[reply]

Stupid question about other projects

Why exactly is this only for one skin on one wiki? Making technical changes like this, if they do not scale in the first place, seems like they would only confuse people further when moving between languages and projects, and the inherent complexity between the lot of them is already problematic.

And the rest just seems like it could be done by changing the relevant interface pages on-wiki, and maybe adding another for the top if need be? With the text itself under the editbox, removing as much as possible is always a good thing, but just moving it around likely won't help much. And putting some of it at the top won't help here anyway when some pages around can have up to three (or possibly even more) editnotice boxes there already, though on other projects which do not use editnotices, that could indeed be an improvement.

The template and hidden category collapsing, on the other hand, is not something enwp actually needs that much. It doesn't hurt, but in particular Commons comes to mind as one that really does need it - this sort of thing is entirely the norm, and it's not even due to badly-made or overly complicated templates, but instead just that everything needs to be templates in order to translate. The system works surprisingly well, but it also makes a bit of a mess of the transclusion lists, as you can see. The rest of text under their editbox is actually quite clean, however. Perhaps an example we might want to follow here? -— Isarra ༆ 17:23, 6 September 2012 (UTC)[reply]

It's for one skin on one wiki because we don't want to rock the boat at the moment :). To rephrase what you're asking; "why are you not applying changes that seem logical given the enwiki setup to a vast number of other projects doing their own thing?" If this is uncontroversial and people are interested in seeing it expanded, we can look into doing that. But deploying everywhere without letting the vast majority of people who are affected know is very much How We Used To Do Things and also How We Should Not Do Things. I'd like to see my team acting more responsibly than might be expected when it comes to keeping people in the loop, but this means a more gradual rollout. Always a tradeoff. Okeyes (WMF) (talk) 19:04, 6 September 2012 (UTC)[reply]
Okay, so there may be cause to wait to apply relevant changes to core, but these are still general interface changes on this wiki and the framework already exists for making such changes directly across all skins on the wiki end; any admin could do that following an RfC or whatever garnering sufficient community support. Why reinvent the wheel to tack them on top of the existing framework as a javascript override for just one skin when we could instead polish the wheel we have, change the actual text, and improve the general interface? Not only does the proposed approach take more work to implement and maintain (and time to load), it would also make it that much harder for folks to change anything in the future, especially since then changes will then be needed in two places - one in the js for this, and one in the interface messages for the other skins - assuming local admins will even have access to both. -— Isarra ༆ 08:07, 7 September 2012 (UTC)[reply]
If you can get widespread support to have these changes applied to every skin, I'm happy to polish the wheel. Until then, it has to be a gradual rollout. What I'm thinking is that as soon as we iron the bugs out, we have an RfC on "turn this on for everyone?" and see how it plays. Okeyes (WMF) (talk) 16:27, 7 September 2012 (UTC)[reply]
So why does cross-skin require a consensus, but one skin not? And how is a rollout of everything at once to one skin at a time better than a cross-skin rollout of one change at a time, with discussion of each individually? I only count four distinct changes here - refactoring the text, changing the colours, making the transclusion and category lists collapsible, and figuring out what to do with the charinsert edittools - so they could reasonably all be listed together, just as separate sections, perhaps, acted on individually? But with the approach of bundling the changes, the comments about each individual change are winding up all over the section, making following it quite difficult (and locating a specific thing in the middle of all this wikitext so as to reply to it even harder), and only doing it with vector seems like it would just lead to excluding the potential for in-progress feedback from the subset of users who don't use vector, which doesn't seem like it would make things any smoother. -— Isarra ༆ 00:46, 9 September 2012 (UTC)[reply]

Edit tools

So, I've seen a lot of commentary for people who don't want the edit tools (but don't have the enhanced toolbar and vector) or do want the edit tools, but do have that setup. I can see a couple of solutions:

  • Someone gadgetises the edit toolbar and we turn it off by default for new users, but on for existing users. We then just remove it from the MediaWiki namespace entirely. This has the advantage of requiring relatively little time at our end (which means it can be done fast). Alternately we can turn it off by default for everyone, but display a message in place of where it currently sits for a week or so in order to let people to know how to re-enable it.
  • We build "do you want this?" into the preferences menu. This is my least-preferred option; preferences are already highly cluttered, and we're looking at slimming them down, and it'll require more dev time at our end.

Opinions and thoughts? Okeyes (WMF) (talk) 16:27, 7 September 2012 (UTC)[reply]

Which edit tools/toolbars are you referring to here? Is it the Help:Edit toolbar or the mw:Extension:CharInsert box? The former, though it is generally called the 'edit toolbar', already has an option in the preferences to disable it, hence why I'm asking. -— Isarra ༆ 19:22, 7 September 2012 (UTC)[reply]
The latter. Okeyes (WMF) (talk) 19:27, 7 September 2012 (UTC)[reply]
Not that this really helps anything now, but we may want to figure out what to do with the edit toolbar on the editbox itself before worrying about the charinsert edittools, which exist as possibly redundant and possibly not depending on what happens with the toolbar. -— Isarra ༆ 00:46, 9 September 2012 (UTC)[reply]
I requested that last month at Wikipedia:Gadget/proposals#Edit tools. No replies so far... Helder 18:08, 10 September 2012 (UTC)[reply]
I've asked User:YuviPanda if he could gadgetise it; if and when he does I think we can WP:BOLDly stick it in :). Okeyes (WMF) (talk) 23:48, 11 September 2012 (UTC)[reply]
Thanks! If I didn't miss anything, the steps I provided there should be sufficient to implement this as a gadget. Helder 21:36, 12 September 2012 (UTC)[reply]

Deployment coming up

Hey all :). My apologies in advance (first for the short notice, and second for the inaccuracy of this compared to the public statement we made) but we'll be deploying this in probably the next couple of days. TL;DR, a misunderstanding about where and when things deploy meant that we have substantially fewer opportunities to throw out new code. I'll let people know as soon as changes are live (if they don't notice themselves). We'll get better at this, I promise :). Okeyes (WMF) (talk) 03:29, 13 September 2012 (UTC)[reply]

HTML5 is coming to Wikimedia Wikis...

We're going to be enabling HTML5 [2] on all Wikimedia wikis on Monday 17th September 18:00-20:00 UTC [3]. Just a heads up for anyone that might actually care. Reedy (talk) 22:08, 5 September 2012 (UTC)[reply]

Whether or not I care (I haven't decided yet), it's great to get heads up such as this and the edit window change a few posts back. Much to be encouraged. --Tagishsimon (talk) 22:14, 5 September 2012 (UTC)[reply]
<VP stalker>Thanks! </VP stalker> :). Okeyes (WMF) (talk) 22:32, 5 September 2012 (UTC)[reply]
Have to check again, but I think this should resolve issues with the new table sorter. How about HTML Tidy? ---— Gadget850 (Ed) talk 22:47, 5 September 2012 (UTC)[reply]
Is this causing <font> to disappear. If so, you might want to make a bigger announcement as it will affect alot of people's signatures. Bgwhite (talk) 00:05, 6 September 2012 (UTC)[reply]
Case in point ---> LadyofShalott 00:11, 6 September 2012 (UTC)[reply]
Will this cause any other markup (or other things) to not work? David1217 What I've done 00:18, 6 September 2012 (UTC)[reply]
No <font> will still work, and everything else should look the same except for some tiny browser-dependent positioning changes. Actual rendering depends on browser implementation, not the standard. However it will make any pages with font tags fail to validate when they might validate today. —Cupco 00:25, 6 September 2012 (UTC)[reply]
It has been reported before that <font> and <center> will no longer work on the changeover. Bgwhite (talk) 00:38, 6 September 2012 (UTC)[reply]
That's true, HTML5 relies on the CSS template to present items. Here are the elements I know about that are being removed from HTML: basefont, big, center, font, strike (<s></s>), tt, frame, frameset and noframes. There are probably more. Some parameters we use that are also going away are: charset, coord, archive, nowrap, valign, type, width and quote a few others. We should expect some really significant fallout from this "upgrade". Forgive my pessimism but I sincerely hope that more testing has been done than some of the previous "upgrades" or we are going to have a lot of fallout and problems. Kumioko (talk) 01:47, 6 September 2012 (UTC)[reply]
Could someone else confirm these, particularly someone who has tested them on the testwiki (i.e., "how WP will behave")? The center tag is used a lot in articlespace, and strike is used extensively in all sorts of discussion pages to "mark as removed" specific comments and as markup for content-deletion changes. DMacks (talk) 05:22, 6 September 2012 (UTC)[reply]
Based upon August's dump, (if I did it right) 30,013 articles use center, 208 articles use strike and 7,379 use font. Bgwhite (talk) 06:42, 6 September 2012 (UTC)[reply]
  • Elements will not stop working. Where implemented, MediaWiki will translate to make it HTML5 valid. Otherwise, it will just output the old tag or attribute and the page will not be valid, test2wiki:User:TheDJ shows that font and big will simply remain working. In the future more internal translation will be added to convert these to proper html5 as well.
  • So after we upgrade, we will have a lot of talk pages that are not valid HTML5. This is not considered to be a problem. However, ppl should stop using the font tag in their signatures and start using span. Not because otherwise stuff will break, but because they chose to write HTML in their signature, so they should make sure they use the appropriate HTML.
  • HTML5 mode has been the default for over 3 years now. Screenscraping has been illadvised for over 7 years now. Due to the huge amount of legacy user written code on en.wp however it has been incredibly difficult to make the switch, because, well because volunteers simply don't rewrite code until it breaks. I expect some things to break again, this is not a problem. People attending this forum will know how to fix them. What is important is that the biggest user-written tools have now been either converted or can expect to break because they didn't follow trough the last time the tool broke. Waiting longer probably won't spur the last group into action.
  • Yes, things break when this kind of thing comes to en.wp. The words 'do more testing' are often flung back at developers, but people forget that there simply is nothing remotely comparable to English Wikipedia. In terms of both content, community customization and community itself, en.wp is unique and will always be. —TheDJ (talk • contribs) 06:53, 6 September 2012 (UTC)[reply]
BTW. This doesn't mean that HTML5 won't be disabled again if required, like the last times. —TheDJ (talk • contribs) 07:42, 6 September 2012 (UTC)[reply]
  • I have one correction to that statement DJ. Some of us are aware of some of the problems mentioned above however attempts to replace the HTML tags or to fix them result in various editors getting upset that we are performing minor edits that don't change the rendering of the page or something like that. The resolution is clear to me to fix these and that is to do a bot or add some code to AWB to fix these things 1, 2 or a few at a time until they are done. I have done things in the past to clean this up and had users threatening to revoke my AWB access or even block me from editing. There are some things that can be done now, before we flip the switch but we are not allowed too without going to each article manually which frankly is extremely stupid. Kumioko (talk) 10:14, 6 September 2012 (UTC)[reply]
    • There is only reason to change 'new edits' and templates. At some point the core will be fully able to take these 'older' html4 elements and attributes and translate them into HTML5 equivalents. Also, there is no rush on this front. —TheDJ (talk • contribs) 12:02, 6 September 2012 (UTC)[reply]
Here is a document describing HTML features marked as obsolete in HTML5. My experience is that "obsolete" doesn't mean "these will stop working with immediate effect", but "these may not work in HTML5-compliant browsers, and validity checkers will complain, but there is nothing to prevent the browser authors from providing these features for the convenience of legacy code". So, for example, we should not introduce new uses of <tt>...</tt> but use <kbd>...</kbd>, <var>...</var>, <code>...</code>, or <samp>...</samp> instead; but there is not an immediate rush to "fix" existing uses. --Redrose64 (talk) 12:58, 6 September 2012 (UTC)[reply]
First I want to state that I understand what you are saying, both of you, but I don't like the habit that we have on WP of kicking the can down the road for the sake of maintaining obsolete code, templates, etc. just so that we don't do minor edits. Second, if not doing these edits causes problems in other applications such as browsers then they are not minor and third, by leaving them in place, we then have to do other types of work to compensate such as modifying the CSS templates to compensate. Leaving these items in place just perpetuates the problem. Users see it working and copy it, they get in the habit of using outdated techniques. We can do most of these changes with a bot, initially the edits might be fairly high but if we stay on top of it then they won't be that bad, especially if we do them at the same time as doing other edits. Otherwise we just have trash piling up in the corner and then at some point down the road when something else happens then we have to jump through hoops to fix a problem that should have been delt with long ago but no one wanted to take the time to do it right and just whitewashed it. Kumioko (talk) 13:58, 6 September 2012 (UTC)[reply]
You are adding complexity where it is not really required I think. Remember, you can't change past revisions, so whatever is in the database, will need to work ANYWAYS, regardless of what we use as 'current' practice. So the complexity should be in the core to make sure it's wikicode is displayed as HTML5. Also do not forget that HTML5 is a living standard. It has removed the obsolete marker from elements before and might still do it again (though less likely by the month). Quite a bit of restraint (in the region of years) is not an unwise when it comes to this revisioned wikicode of ours. For the same reason. <b> and <i> were actually obsolete for a long while, it would have been a shame if they had been removed everywhere (pretty much permanently) for nothing. Perhaps some time (far far future) when we have a sane Parsoid parser and a sane DOM model, we might be able rewrite past revisions into the new DOM model. Then I would be more supportive of your approach, but for now, I and I think many developers rather take it slow with the persisted data when it comes to HTML5. —TheDJ (talk • contribs) 14:46, 6 September 2012 (UTC)[reply]
I see what your saying but I also think that we should be able to develop a way to change these things by bot as necessary and develop a standard. Right now we say we have a standard but then have a million caveats and allow anything and then call it a standard. Once we implement a change then we should fix the things to conform to that. Also using your example <b> and <i> went away for a while but there was still a way to do it using other coding. It just wasn't using <b> and <i>. In the end its you folks decision but IMO it would be better to run a bot to align these changes when they are implemented and then adjust as necessary in the future rather than to accept everything may change and do nothing. Will it fix everything of course not, but as this is a major change it will give us a solid base from which to base a standard use of coding techniques based on current standards and we can adjust as necessary going forward. Of course we need to do some testing because not everything in HTML5's new coding may be supported in all apps such as older browsers but its something to consider. Kumioko (talk) 15:11, 6 September 2012 (UTC)[reply]
I think that it would be a mistake to have a bot editing wikitext to convert it to HTML5. The fact is, wikitext is not HTML, even though it allows use of a subset of HTML tags. ''' isn't valid HTML, any more than <s> will be under HTML5. Users don't have to worry about whether the parser emits <b>, <strong>, or <span style="font-weight: bold"> when it comes across three apostrophes. We shouldn't have to worry about using <s> either. --R'n'B (call me Russ) 15:39, 6 September 2012 (UTC)[reply]
Kumioko has a point. Correct the problem now while we have time. Removal of the tags will allow the removal the hack that keeps the tags going in the Mediawiki software. It makes sure all new edits use valid HTML5. There will be only one standard and not several. There are no downsides, only benifits from the removal of the tags from the articles. In the long run, this is the way to go. Bgwhite (talk) 18:03, 6 September 2012 (UTC)[reply]
Potential downsides to mass-editing to "fix" existing wikitext:
  • creating unnecessary edits for hundreds of thousands of pages (including talk pages and perhaps archive subpages), which would swamp watchlists and recentchanges lists during the conversion process
  • the risk that conversion would misinterpret wikitext in some cases (for example, on pages where there are complex transclusions, mismatched brackets, badly formatted text or unexpected formatting tags), causing pages to render incorrectly without being detected
  • confusion among established users as to which tags have ceased to work and which tags they ought to use to replace them.
But the MediaWiki parser already renders some legacy markup as modern HTML and/or CSS without having to change the article wikitext (as in Sanitizer::fixDeprecatedAttributes()), and this could be extended to a wider range of deprecated tags and attributes if there is a demonstrable benefit. So valid HTML5/CSS3 output is possible without any of the above disruption.
— Richardguk (talk) 22:59, 6 September 2012 (UTC)[reply]
  • As said above, talk pages would not be touched. We are left with ~308,000 pages. That is not many at all.
  • It is a straight foreword find-replace for the strike and center tags. Font tag (7,000 pages) would be different.
  • Confusion is already here. Do I use the font tag or span? So, there are multiple of ways to do one thing and more code has been created to fix tags that shouldn't be there. Why have Sanitizer::fixDeprecatedAttributes at all if there can be a good fix? How long will Sanitizer::fixDeprecatedAttributes stay around? To paraphrase a quote about developers, do not change anything until it breaks. Why not take the time to fix it properly now or end up with a quick fix in the future when it breaks. Bgwhite (talk) 00:17, 7 September 2012 (UTC)[reply]
It should also be noted that:
  • We wouldn't necessarily need to fix every problem by bot
  • Bot edits can be ignored easily by the users and should probably be marked as minor
  • We could use a standard edit message that would tip the users off to what was done so it would be further easier to ignore.
  • Adding additional hacks to the CSS style sheet will probably be needed your right, but we shouldn't rely on that or assume that we will be able to continue to fiddle with the CSS coding. Somethings are easier to mask than others.
  • Fixing these types of issues as they come up is an industry best practice employed at most major IT companies. Fairy dusting the code to hide the problems works, and will probably still be needed for the article histories. But if we stay on top of things and stop taking this there's no rush mentality then we'll never clean it up because people will still use it and copy it throughout the pedia forever.
  • The initial run will be the worst, but after that shouldn't be too bad. If we start by doing the ones with other problems first, then we can sweep up the rest to minimize the unnecessary edits. Many articles will have other problems that need to be fixed at the same time. Kumioko (talk) 01:07, 7 September 2012 (UTC)[reply]
  • Perhaps create more HTML templates or bot-edits: I was hoping the wikitable parser would translate the old keywords. However, if not, we can quickly write templates to mimic the reasonable keywords, such as {valign|top} to simulate "valign=top" or {font|color=blue}, and then perhaps run some bot-edits to call those templates, rather than the bureaucratic HTML5 (Horribly Twisted Mangled Language style="version:Five; more:later", sorry couldn't resist the joke). Meanwhile, the short tiny templates can run over 750 per second, so they will not slow pages even where not needed, but we just have to stop the rampant deletion of tiny templates. Perhaps make the short template names to be redirects of some long-winded template names, such as "{HTML_keyword/font}" and then they survive deletion because they are tedious to type and seem bureaucratically organized into tedious collections. Let's see if these tedious ones still exist:{Col-1-of-2}, {Col-2-of-2}, {Col-3-of-4}, yes tedious sets of even useless templates still survive deletion, etc. -Wikid77 (talk) 05:41, 6 September 2012 (UTC)[reply]
  • Comment: I don;t usually chip in here, but I have to say that I really think Kumioko's right, here. Whatever edits (bot) would be necessary to bring current versions of pages into line would be good; otherwise we are just piling up problems for the future. I see no reason why such edits couldn't be marked as minor, and as bot, so as not to swamp people's watchlists. I'm just kinda looking ahead to ten years down the line, when someone will be tearing their hair out and thinking "OMG, why didn't we fix this when it was so much smaller ...?" Brushing stuff under the carpet only works until there's so much fluff under there that it makes the floor surface lumpy and trips people up ;P Pesky (talk) 04:18, 9 September 2012 (UTC)[reply]
The obsolete tags will always be supported. There are literally millions of pages out there written in HTML3 which will never be upgraded, and therefore browsers will always support legacy HTML code, even when it doesn't validate against the latest committee standard. Obeying standards committees with few actual programmers on them is among the lowest priorities. —Cupco 03:54, 10 September 2012 (UTC)[reply]

1/6 3/5 "Symbols"

Hi all, under "Special Characters" can someone add or link to a 1/6 or 3/5 as a single character? Thanks so much! Marketdiamond (talk) 06:32, 6 September 2012 (UTC)[reply]

⅗⅙ HumphreyW (talk) 07:32, 6 September 2012 (UTC)[reply]
Excellent!! Thanks much! Marketdiamond (talk) 08:06, 6 September 2012 (UTC)[reply]
Note that MOS:FRAC says: "The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others." I'm not sure we should even keep the current Unicode fractions ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ at MediaWiki:Edittools.js and elsewhere. ½ is the only which is easily readable to me. PrimeHunter (talk) 10:13, 6 September 2012 (UTC)[reply]
Indeed, as a screen reader user, I can confirm this is a problem. FWIW the characters for ½, ¼ and ¾ read out fine here as they're part of ISO/IEC 8859-1, but the others certainly don't. Graham87 09:51, 7 September 2012 (UTC)[reply]
Eh, how does your screen-reader not understand say Unicode ⅔? I'd expect exactly that is not a problem. -DePiep (talk) 00:37, 10 September 2012 (UTC)[reply]
If Graham87 (talk · contribs) says that his screen reader has problems with these characters, I believe him without question. Just because a character has a Unicode character encoding, it doesn't necessarily imply that it is universally recognised.
To take a visual example: my PC has Windows XP, as does my mother's laptop; yet they each have problems displaying certain Unicode characters, but the problems differ. My PC displays certain Asian text, including Chinese and Japanese text, without problem, but fails to display part of one of the signatures on this page (specifically, the talk page link in Anomie⚔) - to me, it's a square containing the characters 2694. Conversely, my mother's laptop displays that talk page link, which is a pair of crossed swords, but won't display either Chinese or Japanese - these both show as rows of numbered squares.
Since it has been proven that different machines (with the same operating system) do not recognise the whole Unicode set, I don't expect that all screen readers will necessarily recognise the whole Unicode set either. --Redrose64 (talk) 12:17, 10 September 2012 (UTC)[reply]
I understand MOS:FRAC mentions accessibility because the fractions are likely illegible in regular fontsize. A screen reader does not use fontsize, so that aspect cannot be in play with Graham87. The other aspects mentioned (not picked up by a screen reader, and Unicode character not recognised by an OS/font setup) is not specific to these fraction characters. If it were that, there would be a more general restriction on Unicode characters. -DePiep (talk) 18:41, 10 September 2012 (UTC)[reply]
There are MANY characters that screenreader software does not understand (does not have an audio fragment for), this has nothing to do with them being unicode or not. Supporting all possible characters would probably be cost prohibitive and not to mention create a program of a dozen or so gigabytes. —TheDJ (talk • contribs) 22:14, 11 September 2012 (UTC)[reply]
Indeed, there is a patch for my screen reader, JAWS to teach it the audio representations for almost all Unicode characters, but every time I've tried to use it, it's ground my system to a halt (even when I copied it to the correct folder per the instructions on the site). Specialised sets of Unicode audio representations for things such as IPA and mathematics work much better, but I don't think they're widely used by general screen reader users. Graham87 07:27, 12 September 2012 (UTC)[reply]
So what is the lowest common denominator that Wikipedia should support? I don't mean to be nasty here, but is it possible that JAWS is not the best option for a screen reader? Perhaps we are not encouraging its development by stagnating upon the set of characters that we a permitted to write with? Or is it that JAWS is the best-of-breed and we just have to live with such restrictions? I really don't have any experience here so these are genuine questions I have. HumphreyW (talk) 22:42, 12 September 2012 (UTC)[reply]
I can't speak to the advantages or disadvantages of different screen readers (I assume Graham would know more about that), but JAWS (screen reader) is one of the most popular (the most popular?) screen reader in the world. We could also stop supporting IE because it sucks balls, but that wouldn't be fair to all the IE users out there. But as to what we should actually be doing, ½ was the only fraction I could read off the bat, and barely. I had to toggle the font higher three times before I could read most of the fractions at a comfortable distance. Someguy1221 (talk) 23:03, 12 September 2012 (UTC)[reply]
JAWS is one of the best Windows screen readers around, especially for working on the Internet. I'm not familiar enough with other operating systems to comment on them. Graham87 09:20, 13 September 2012 (UTC)[reply]

This page which is linked from the "On this day..." box has three occurrences of -->   <--. For me that renders as a box with 202F inside. Is there a policy or guide page that states which characters are considered acceptable, or not acceptable, to put into an article? HumphreyW (talk) 07:17, 13 September 2012 (UTC)[reply]

That character is a narrow no-break space, which is disallowed on Wikipedia for exactly that reason. I've replaced it with a regular non-breaking space. Ironically, although I'd copyedited that article earlier in the day, I didn't notice anything wrong with the characters, ironically because JAWS read them out as "space". I don't think there's a centralised list of allowed and disallowed characters; I think they're just mentioned in the various sections of the Manual of Style (e.g. non-breaking spaces, quotes, etc). Graham87 09:20, 13 September 2012 (UTC)[reply]
I have suggested to remove all fractions except ½ from MediaWiki:Edittools. Discussion at MediaWiki talk:Edittools#Proposal to remove fractions. PrimeHunter (talk) 22:32, 13 September 2012 (UTC)[reply]

Lua might seem slower but

The preliminary tests, on test2.wiki, with writing Modules in the Lua script seem to indicate only minor performance gains, certainly not 20x times faster for everything. However, there are several complicating factors:

  • Templates, copied verbatim, over to test2.wiki also seem 50%-90% slower, in many tests, day or night.
  • Other text, copied verbatim, over to test2.wiki seems to reformat 50%-90% slower, day or night.
  • Lua on enwiki might run 2x faster due to unforseen tuning improvements here.
  • Each might be faster, in some aspects, where Lua provides special features, or vice versa.
  • Mixtures might be even faster: perhaps combining markup templates and Lua script modules, carefully, might create a hybrid faster than either alone.
  • For computer technicians, writing a "standard" computer-language Lua script would be faster, for them, than learning "esoteric" arcane tricks of the error-prone template coding.
  • Competition and cooperation of text-formatting techniques, between the 2 languages, might lead to many unforseen improvements, in later months.

For faster articles, the ultimate solution is clear: almost any huge article with no templates reformats within 2 seconds. If all templates are hard-coded or wp:subst'ed within a major article, then it could be reformatted for any user-preference, such as default image-size higher than 220px, within 2 seconds. Numerous tests have shown that article "India" here, with all prior templates, reformats in 25-29 seconds due to using 801 templates, such as hundreds of Template:Citation and Template:Sfn. I have created several fast-cite versions of those templates which can reduce the reformat time of "India" to nearly 10 seconds; however, the bottom-line fact is that removing all templates allows "India" with hundreds of hard-coded footnotes, and all images, to reformat in only 1.5 seconds. Keep the huge nation infobox, and it becomes 2.5 seconds. The file servers really are lightning fast, and small templates run over 750 per second, but large templates are bizarrely slow as huge behemoths. For very popular articles, then hard-coded citations might be the best choice, while thousands of less-viewed articles can use cite-templates instead. However, until Lua is installed on enwiki, and the operational parameters are tuned for faster speeds, we still are unsure as to the live speed here. Then, long-term, we can investigate other methods of formatting data in articles, whether with improved templates or alternative modules coded in Lua script. Both systems have future potential. -Wikid77 (talk) 09:56, 6 September 2012 (UTC)[reply]

Tim yesterday committed his Lua profiler, which should help get a better grip on the exact numbers. —TheDJ (talk • contribs) 11:34, 6 September 2012 (UTC)[reply]
For the record, that was made on gerrit: 22710. Helder 18:17, 10 September 2012 (UTC)[reply]

Magic words question

I'm trying to make a userbox show the name of the user if the userbox is in the user OR User talk namespace, but just show the word editor if it's outside of those namespaces.

Here's the closest I came, but it didn't work (note, I have no idea what I'm doing):

{{#if: {{NAMESPACE}}=User talk | {{PAGENAME}} | editor}}

Can you help? Thanks!!!! Ocaasi t | c 01:00, 7 September 2012 (UTC)[reply]

You're pretty close. What you want is {{#ifeq:}} or {{#switch:}}. Desired implementation would either be:
{{#ifeq:{{{NAMESPACE}}}|User|{{{PAGENAME}}}|{{#ifeq:{{{NAMESPACE}}}|User talk|{{{PAGENAME}}}|editor}}}}
or
{{#switch:{{{NAMESPACE}}}|User|User talk={{{PAGENAME}}}|#default=editor}}
--Izno (talk) 02:04, 7 September 2012 (UTC)[reply]
Thanks! Will try it, very cool :) Ocaasi t | c 03:20, 7 September 2012 (UTC)[reply]
As you might have discovered, magic words take two brackets, not three: :
{{#switch:{{NAMESPACE}}|User|User talk={{PAGENAME}}|#default=editor}}
-DePiep (talk) 12:58, 8 September 2012 (UTC)[reply]
Oh, thank you! Yes, that's why it wasn't working! Ocaasi t | c 10:19, 11 September 2012 (UTC)[reply]

Problem with conversion of miles to kilometres when page is rendered as PDF

Resolved
 – Ruslik_Zero 07:06, 10 September 2012 (UTC)[reply]
Tracked in Phabricator
Task T42087

Please see Template talk:Convert#Problems with this template in Book namespace. It is not a problem with {{convert}}, nor with Book namespace, but something inside {{Infobox road/meta/length}} when rendered as a PDF. --Redrose64 (talk) 17:02, 7 September 2012 (UTC)[reply]

I've narrowed it down to the following bit of code in the {{rnd}} template
  • {{#expr:(1E5round0)E5}} which gives 10000000000.
Try converting User:WOSlinker/list to a pdf to see the error. -- WOSlinker (talk) 17:49, 7 September 2012 (UTC)[reply]
Thanks, I think if it were a couple of occassions on a couple of pages we could manually replace them but this is alot of transclusions on thousands of pages making it hard to replace them all. Kumioko (talk) 23:51, 7 September 2012 (UTC)[reply]
  • Try sandbox version: Someone might want to try Infobox road/meta/length/sandbox, the /sandbox version, which I have changed to round the result by {#expr: ...round...} rather than Template:Rnd, which can add trailing zeroes or x10 notation of huge numbers. The expansion depth will be reduced from 12 to 6 levels, of the 41-level limit, by omitting {rnd}. For miles/km, I think typical rounding is fine, without worry of trailing zeroes. If the sandbox makes matters worse, then just revert. In complex computerized procedures, often the quickest solution is to "try everything" as a shotgun approach, and use whichever of various options will solve the problem. Pure deduction of cause-effect connections can be very tedious and time-consuming, so try-everything might actually be faster to try multiple changes, rather than think how the internal procedures work to pinpoint the specific bug. -Wikid77 (talk) 05:02, 8 September 2012 (UTC)[reply]
  • Oh dear. I had hoped, that per WP:MULTI, people would comment at Template talk:Convert#Problems with this template in Book namespace, not here. Now we have three separate discussions going. --Redrose64 (talk) 15:45, 8 September 2012 (UTC)[reply]

Inflation calculator eliminating "thousand"

Couple questions. For this: ${{formatprice|{{Inflation|US|2500|1883}}}} it spits out $81,750. Anyway to make it show xyz,000 ? Also I have noticed that for calculations that have a dollar or fifty cents or penny for years prior to 1850 there is some symbol that spits out NDA or something I am guessing that the formula as written isn't capable of numbers less than $100? Any formula that is? Thanks. Marketdiamond (talk) 14:50, 8 September 2012 (UTC)[reply]

I tried to have the formula read but you can see it clearly in the "edit" space. Thanks. Marketdiamond (talk) 14:53, 8 September 2012 (UTC)[reply]
Fixed the formatting in your comment.
Try:
  • using the {{Inflation}} template's |r= parameter to specify the amount of rounding (positive numbers round to decimal places, negative numbers round to multiples of ten, 100, 1,000 etc – you can probably type different values of r if the magnitude varies a lot in different cases, so that some results are rounded more than others as appropriate);
  • using the {{formatnum:...}} "magic word" to format the number with commas separating the thousands.
So: ${{formatnum:{{Inflation|US|2500|1883|r=-3}} }} produces "$82,000".
— Richardguk (talk) 17:56, 8 September 2012 (UTC)[reply]
Thanks! This is working! However I also have a .04 from 1779 $ I have tried -5 and then -3 and still nothing though the $NVANaN thing disappeared. Any suggestions for a .04? Marketdiamond (talk) 19:29, 8 September 2012 (UTC)[reply]
Glad that's helping. Unfortunately, the template is relying on data for US inflation that only goes back to the year 1800. If you want the template to include older data, you might want to leave a comment at Template talk:Inflation or on the talk page of one of the template editors (the last editor to update the US data was User:Pascal666). — Richardguk (talk) 19:49, 8 September 2012 (UTC)[reply]
Thanks for all the help, I will take your suggestion. Just for kicks I plugged in 1800 and 1801 for the .04 and $4 and it is now spitting out 0 (which I know is incorrect). Not that it matters but is $10 or $100 the smallest amount it will convert to current value? Marketdiamond (talk) 19:59, 8 September 2012 (UTC)[reply]
You need to increase r to zero (for the amount in round dollars) or a positive value (r=1 to the nearest dime, r=2 to the nearest cent), because even after inflation the amount is less than $1. So ${{formatnum:{{Inflation|US|.04|1800|r=0}}}} produces "$1". Note also that there should be no bar |, only a colon, at the end of formatnum:. — Richardguk (talk) 20:51, 8 September 2012 (UTC)[reply]

Gotit, after you mentioned putting the - in I had blinders on for that, duh I got it now, excellent help, thanks a million! Marketdiamond (talk) 22:27, 8 September 2012 (UTC)[reply]

Before or after Inflation? :) Naraht (talk) 15:39, 11 September 2012 (UTC)[reply]
  • Could also Spellnum: Just a reminder that another numeric format is to show the price number in words, so:
  • {{Inflation|US|2500|1883|r=-3}} → 82000
  • {{spellnum|{{Inflation|US|2500|1883|r=-3}} }} → eighty-two thousand
That gets the "62" into words, along with "thousand". -Wikid77 (talk) 05:22, 12 September 2012 (UTC)[reply]
Thanks Wikid77 and Naraht . . . you deflated my inflated situation nicely! Marketdiamond (talk) 22:58, 15 September 2012 (UTC)[reply]

Why we have files like Category:Wikipedia image placeholders for image namespace?

Is it better than salting bad filenames? Bulwersator (talk) 15:02, 8 September 2012 (UTC)[reply]

When uploading files to Wikipedia, please use a file name that describes the content of the image or media file you're uploading and is sufficiently distinctive that no-one else is likely to pick the same name by accident.

Examples of good file names: (...)" (tested on File:1.jpg) Bulwersator (talk) 09:21, 11 September 2012 (UTC)[reply]

I agree that it is impractical to duplicate the images. It fills up Category:Public domain files ineligible for copyright with lots of almost identical copies, so it is harder to search that category. In my opinion, a better option to duplicating files would be to keep only one copy of the image and use redirects to that file instead. --Stefan2 (talk) 10:43, 11 September 2012 (UTC)[reply]
  • These could all be protected redirects instead of duplicate uploads. That prevents the individual files being categorized. That also makes prettification later on easy (e.g. the JPEG artifact issue for instance, to "fix" that a lot of uploads need to occur, whereas with a redirect only one). To ensure these are protected at all times something we can use {{R protected}} (or something like it) to auto-categorize unprotected ones. This method is fairly common on Wikimedia Commons (though many duplicates exist there as well, still). Krinkle (talk) 11:30, 11 September 2012 (UTC)[reply]
(Interesting how non-conflicting edits are sometimes merged when the edit window stays open a long time. Stefan2 already said this in the mean time :) Krinkle (talk) 14:17, 11 September 2012 (UTC))[reply]

Watch a category?

Tracked in Phabricator
Task T3710

To anyone's knowledge, has there ever been discussion about enabling users to watchlist all articles within a category? I mean single-click style. The Interior (Talk) 20:34, 8 September 2012 (UTC)[reply]

See also bugzilla: 1710. Helder 18:21, 10 September 2012 (UTC)[reply]
The RELC link Bulwersator examples comes close. 1. It can be a wikilink to the SPEC. 2. It does not watchlist their talkpages. For a stable category, one can create and maintain a list page (talkpages added, multiple categories and individual pages together). .../List of Articles. RELC: Special:RecentChangesLinked/.../List of Articles. -DePiep (talk) 11:59, 13 September 2012 (UTC)[reply]
Okay, thanks for the Related Changes tips. I'll use that for now and maybe create some sub-pages. I've never interacted with Bugzilla, should I leave a report about this discussion? I still think it (one-click category watch) would be a good thing to enable in the future. The Interior (Talk) 19:55, 15 September 2012 (UTC)[reply]

Wikipedia pages not formatted properly

Hi. I've been noticing that part of the Vector stylesheet doesn't load in my browser for some reason. 68.173.113.106 (talk) 02:33, 9 September 2012 (UTC)[reply]

Please give us an example of the pages you have the issue, maybe even a screenshot, and let us know what browser you use (and what version).  Hazard-SJ  ✈  05:26, 9 September 2012 (UTC)[reply]
First completely clear your cache if you haven't already. PrimeHunter (talk) 10:35, 9 September 2012 (UTC)[reply]

Another error on statistics

Resolved

This website, http://stats.grok.se/, is not reading any views after September 3, 2012. I wonder what is going on with the site. --George Ho (talk) 09:11, 9 September 2012 (UTC)[reply]

I might be doing something wrong but when I click that link it takes me to a "Enter a wikipedia article title and press Go" page. Is there a certain article you are referencing or even this exact wiki page? Thanks Marketdiamond (talk) 16:10, 9 September 2012 (UTC)[reply]
Just a comment it is all pages you enter from 2 September onwards. Henrik has not edited since 3 June.Blethering Scot 16:35, 9 September 2012 (UTC)[reply]
It's fixed now, with a ~week gap in data. —Cupco 03:55, 10 September 2012 (UTC)[reply]

A spacing insert

It is for a wiki userbox so it is a visual thing, is there some <> that makes additional space or void characters for spacing? Thanks! Marketdiamond (talk) 16:08, 9 September 2012 (UTC)[reply]

One of the ways is non-breaking space &nbsp; Example: 1  2   3    4     5. PrimeHunter (talk) 16:29, 9 September 2012 (UTC)[reply]
Thanks! have seen that, always wondered what it really meant! Marketdiamond (talk) 16:31, 9 September 2012 (UTC)[reply]

WikiLove customization

Hi, following User:Quadell/common.js/wikilove.js, I'm trying to add a type of WikiLove called 'Badges'. The mockup badge I'm using is at Wikipedia:BADGE/mockup. I'm having trouble getting anything to change in Wikilove, let alone actually delivering the Badge properly. My code is at User:Ocaasi/common.js. Can you help point me in the right direction? Once I have one example I'm pretty sure I can figure out the rest. Thanks! Ocaasi t | c 18:49, 9 September 2012 (UTC)[reply]

Looks like it's a load order issue. Will investigate. Kaldari (talk) 18:27, 10 September 2012 (UTC)[reply]
Thanks! Ocaasi t | c 18:40, 10 September 2012 (UTC)[reply]

It looks like something has changed recently regarding JS load order. If you add... 

mw.loader.using( 'ext.wikiLove.defaultOptions', function() {
...
} );

around your code, it should at least allow you to add new modules. You still won't be able to delete modules, however, as this will cause an error when the local wiki overrides are loaded. Kaldari (talk) 23:18, 10 September 2012 (UTC)[reply]

Works brilliantly! Now, do you have any idea how instead of an image+message I can deliver a template + message, as in {{Wikipedia:BADGE/mockup}} That would really be awesome. Either way, thanks! Ocaasi t | c 00:07, 11 September 2012 (UTC)[reply]

Table coloring help

Ok I have attempted several times to insert background colors into the standard wiki table headers:

! bgcolor="#ffdaba"test1 ! bgcolor="#ffffcc"test2 ! bgcolor="cyan"test3

but it is not coming back as coloring the whole field. Please help. Also how and what syntax do I use to get borders=0. Thanks. Marketdiamond (talk) 01:09, 10 September 2012 (UTC)[reply]

You need a | between the style and cell contents:
test1 test2 test3
74.74.150.139 (talk) 01:34, 10 September 2012 (UTC)[reply]
Thanks, this helps! Marketdiamond (talk) 03:02, 10 September 2012 (UTC)[reply]
On an aside, please use "style="background-color: #ffffcc" instead. bgcolor is a deprecated HTML attribute, style is not. --Izno (talk) 15:11, 10 September 2012 (UTC)[reply]
Thanks will do! Marketdiamond (talk) 22:57, 15 September 2012 (UTC)[reply]

Text wrap for pie chart template

I'd like to use the {{Pie chart}} template in an article, but it doesn't seem to allow text to wrap around it. Any suggestions? CanadianJudoka (talk) 05:02, 10 September 2012 (UTC)[reply]

Why do you think it doesn't allow text to wrap around it? Ruslik_Zero 07:57, 10 September 2012 (UTC)[reply]
Maybe you're viewing it on a browser where it's not rendering right, like mobles? Honestly I would upload a cropped screenshot or make an .svg file. That really doesn't look ready for prime time. —Cupco 08:38, 10 September 2012 (UTC)[reply]
Ruslik: I'm using the latest version of Chrome on Windows 7, and the template doesn't allow text to wrap around it no matter where I put it. Cupco: I did take a screen shot, but it seems like there should be a better way to do this on Wikipedia. How would you suggest that I make an SVG file? CanadianJudoka (talk) 14:47, 10 September 2012 (UTC)[reply]
SVG files may be created using software such as Inkscape, or a plain text editor. Here is an example from Scalable Vector Graphics (SVG) 1.1 (Second Edition) W3C Recommendation 16 August 2011, which shows how a two-slice pie chart may be constructed in SVG. --Redrose64 (talk) 15:21, 10 September 2012 (UTC)[reply]
Thanks. I really wish that there was a way to do this by just entering values and having the software draw a pie chart for me, which is why I like the idea of the pie chart template. Manually drawing one in Inkscape or taking the time to figure out the right set of instructions to draw one in SVG seems like a poor use of time. CanadianJudoka (talk) 15:46, 10 September 2012 (UTC)[reply]
  • Put pie in wikitable align=right: Just use the standard alignment technique, to box any item, by putting the pie chart in a wikitable, higher on the page, while adding the wrap-around text below the wikitable. Example:
         {| align=right
         | valign=top |
         {{Pie chart
            | thumb = | caption = Sizes chart |other = 
            | label1 = BIG    | value1 = 55 | color1 = blue
            | label2 = MEDIUM | value2 = 33 | color2 = red
            | label3 = SMALL  | value3 = 12 | color3 = orange
         }}
         |}
         This text should appear<br>to the left of the pie chart<br>and wrap
         down the page<br>while the pie chart remains<br>at the right-side.
See page Template:Pie_chart/sandbox, which has the above example, to run it on your browser. Remember anything can be boxed within the wikitable tokens "{| align=right" and "|}". The table goes above, and the text after the table, to format along the left side of the table. -Wikid77 (talk) 06:06, 12 September 2012 (UTC)[reply]
When I wrote the template, I included a thumb parameter for left- and right- aligning the pie chart, which the user says works. Unless there is something else to align along with the chart, I see no need to wrap a table around it. PleaseStand (talk) 14:50, 12 September 2012 (UTC)[reply]
Yes, it turns out that the problem was that I had left the 'thumb' parameter blank. Doing this defaults the chart to the left side of the screen and does not allow text wrapping. Setting the parameter to either 'left' or 'right' works fine, however. Thanks for the help. CanadianJudoka (talk) 06:53, 14 September 2012 (UTC)[reply]

Cat handler

I am puzzled by what has happened at Raleigh Moncrief. With this edit an IP tagged the article G5, in a peculiar way using {{db-meta}} and {{cat handler}}, neither of which I have met before. When WilyD removed the visble db template with this edit, that left "cat handler" in place, and the article was still listed at CAT:CSD. It was actually deleted, and later restored, but still showed at CAT:CSD until I removed "cat handler" this morning. JohnCD (talk) 10:43, 10 September 2012 (UTC)[reply]

I suspect that the IP typed {{subst:db-g5}}, so the article received a copy of the {{db-g5}} template. The template has two big pieces, one to generate the message box, and one to deal with the categories. -- John of Reading (talk) 10:58, 10 September 2012 (UTC)[reply]
That would explain it. I'm surprised it doesn't happen more often - one tends to type "subst" automatically. It's something I will look for when I find an article in CAT:CSD that doesn't seem to have a db template. Thanks, JohnCD (talk) 12:52, 10 September 2012 (UTC)[reply]

Poem extension updated

On September 24th, an updated version of the Poem extension will be deployed to English Wikipedia. Most of the changes are back-end, but there is one change that will effect the formatting of poems. Per the fix to Template:Bugzilla, colons inside <poem></poem> tags will no longer invoke definition list syntax, but instead will invoke a 1 em indentation via a span tag. The visual difference is minor, but some editors may want to make adjustments accordingly. Kaldari (talk) 18:30, 10 September 2012 (UTC)[reply]

If you use {{xtag}} to create the tag, it links to the help or extension page: <poem>. ---— Gadget850 (Ed) talk 22:55, 11 September 2012 (UTC)[reply]

Userbox table fix

I'm trying to make the userboxes on my userpage split into two rows so it doesn't require horizontal scrolling. Can you help me with a formatting tweak to the below code which would split the userboxes up? (nowiki's aren't there on my talk page).
<TABLE BORDER="0"><TR>
<TD>{{User:West.andrew.g/STiki UserBox 1}}</TD>
<TD>{{Userbox |border-c=#000 |border-s=1 |id-c=#FFDEAD |id-s=12 |id-fc=#FFF |info-c=#A9A9A9 |info-s=8 |info-fc=#FFE4E1 |id=[[File:Aidlogo.png|55px]] |info=This user is a regular member of [irc://irc.freenode.net/#wikipedia-en-help #wikipedia-en-help] on [[WP:IRC|IRC]].}}</TD>
<TD>{{User wikipedia/OTRSAccess}}</TD>
</TR><TR>
<TD>{{userbox|#CCCCFF|#F8F8FF|[[File:Handshake icon.svg|45px]]|This user is a member of '''[[Wikipedia:WikiProject Cooperation |Wikiproject Cooperation]]'''}}</TD>
<TD>{{User:Henrik/ubx/User contrib|20,000|Ocaasi}}</TD>
<TD>{{User WP GLAMPMA}}</TD>
</TR>
</TABLE>

Thanks! Ocaasi t | c 18:41, 10 September 2012 (UTC)[reply]

Just insert the red line. — Edokter (talk) — 19:06, 10 September 2012 (UTC)[reply]
Awesome. Thanks! Ocaasi t | c 19:52, 10 September 2012 (UTC)[reply]

A small number of the pages in Category:Articles with missing files have an ext link as a page name, i.e File:http://SomeRandomLink.com. Can these be fixed with AWB a bot? -- Alan Liefting (talk - contribs) 18:50, 10 September 2012 (UTC)[reply]

I will take this over to WP:BOTS. -- Alan Liefting (talk - contribs) 19:29, 11 September 2012 (UTC)[reply]

Making an infobox collapsible

I have tried unsuccessfully to make {{infobox D&D creature}} into a collapsible infobox, like {{Infobox video game}} which was locked with tabular formatting to allow the collapse. I don't believe that's a standard infobox option, but I would like to use the creature infobox on list pages and don't want to make the page overly long with full boxes, so collapsible ones make more sense. Can anyone with a bit of technical knowledge help with this? BOZ (talk) 19:55, 10 September 2012 (UTC)[reply]

One one hand, that seems like a dangerous precedent. I think MOS:COLLAPSE might need to be re-examined and tightened, otherwise the anti-infobox people are going to request collapsed-by-default infoboxes in more places, which often leads to unchecked/unseen content...
On the other hand, I think you're probably talking about merging many creature-stub-articles into a single creature-list-article, which as a mergist I'm fully in favour of. (Easier sourcing, easier searching, easier comparing, and less deleted topics, plus usually less cruft).
I'd much rather an alternate solution though. Possibly the old sprinkling of {{clear}} and whitespace between sections, as many merged-into-list pages do. —Quiddity (talk) 23:15, 10 September 2012 (UTC)[reply]
Well, I made it work, but whether or not it should be used, or when and where, are other matters. While I updated the documentation to reflect the change, perhaps this might be the sort of thing not worth documenting so as to help prevent abuse? I dunno. -— Isarra ༆ 23:33, 10 September 2012 (UTC)[reply]
Thanks! I will try to use it responsibly, if I use it at all. :) BOZ (talk) 13:47, 11 September 2012 (UTC)[reply]

Edit summary and Subject/headline funkiness

I have come to think of the Wikipedia technology as having mid-life mood swings. One moment it's fine, the next moment it's whacked, and later, it's back to normal as if nothing happened. This just changed on mine within the last half hour - Poof! Right out of the blue! The Subject line I see as I write this has visibly dropped and is now obscuring a bit of the edit toolbar. This one doesn't actually have an edit summary box below. When on articles that do, the edit summary also drops and obscures a bit below it. Since my system and browser didn't change, what kind of mood swing has the Wikipedia software gone through? Maile66 (talk) 00:04, 11 September 2012 (UTC)[reply]

And, yes, before anyone mentions it, I cleared my cache. So that isn't it. Maile66 (talk) 00:13, 11 September 2012 (UTC)[reply]
I'm not able to reproduce this. It would help if you could provide a few more details: 1) a screenshot of the actual issue, 2) browser/OS info, 3) info about preferences (e.g. which skin, with enhanced toolbar or old one), 4) info about gadgets or user scripts you're using.--Eloquence* 01:19, 11 September 2012 (UTC)[reply]
Thanks for posting here. As of this morning, it's no longer doing its funky-drop stuff. Everything is fine. Go figure. Maile66 (talk) 10:54, 11 September 2012 (UTC)[reply]
That's probably due to us reverting yesterday's deployment (see further below). That means the issue will likely re-appear when we re-deploy, so it would still be useful to have the aforementioned info, even if you can't take a screenshot of the problem right now.--Eloquence* 15:50, 11 September 2012 (UTC)[reply]
BTW, for future questions, how does one do a screen shot into the Village pump talk page? I know how to do a screen shot. I'm just not sure how to paste within Wikipedia text. I use Windows XP with Service Pack 3 (if that matters), Firefox 15.0.1, Modern skin, Enhanced edit toolbar. Editing gadgets: Citation Expander, HotCat, Provelt, wikiEd. There's other issues going on since early summer, when I was using earlier versions of Firefox. They seem to be getting worse:
  • Copy and Paste inserting on a new blank line, it inserts an extra blank line, and THEN does the insert
  • Repeating the "delete" key to remove characters - it removes the first character and then jumps to somewhere else and removes the wrong text.
  • Inserting a link or inline citation, either from the toolbar or from Provelt, fails most of the time. But when it does insert, it jumps to somewhere else on the page - often to a previous section - to do the insertion. I've had to click "Change" to find out if the insertion happened, and where it actually inserted in the document.
Maile66 (talk) 23:27, 11 September 2012 (UTC)::[reply]
The browser is immaterial, but I also have XP with SP3, so here's how I did some of my screenshots (see for example File:Vpt redrose64 thedj.PNG). On the problem screen, I pressed Print Screen which copies the entire screen into the cut/paste buffer. Then I started Microsoft Paint (which I believe is a standard feature of XP) and pressed Ctrl+V to paste in the whole screen. Then I selected the "Select" tool (the dotted rectangle at the top of the second column of the toolbar at left), used the mouse to outline the general area showing the problem, including some of the surrounding area for context, and Ctrl+C to copy to the cut/paste buffer. Then I went for Ctrl+N to start a new document (answering "No" to the question about saving changes). Then Ctrl+V to paste in the cropped section. Then I selected the "Ellipse" tool (bottom of the first column in the left toolbar), picked a distinctive colour from the palette (in this case red), and drew the ellipse to indicate the specific problem. You could draw an arrow if that is more suitable. Then I saved it as a PNG file, then uploaded it and gave it the license {{Wikipedia screenshot|logo=no}} (the |logo=no parameter means that the Wikipedia puzzleball at top left is not included). Then I linked it into the page in the normal way, see here. --Redrose64 (talk) 10:14, 12 September 2012 (UTC)[reply]
Most or all issues you're experiencing seem likely related to the gadgets you're using, e.g. wikEd, and it's generally best to leave a note for the gadget authors about any issues (usually the talk page of the wiki page linked in the preferences is a good place to start). Try disabling them all and re-enabling them individually to narrow down issues. Just for fun I tried enabling all these prefs and seeing if I could reproduce your earlier problem, but I still couldn't.--Eloquence* 07:59, 13 September 2012 (UTC)[reply]

Watchlist star

When you click on it, it happily spins but "never" changes to blue or white, let alone give you a message, although it does execute the requested action.--Bbb23 (talk) 00:46, 11 September 2012 (UTC)[reply]

This is a serious enough issue that we reverted today's deployment for now. It should now be fixed.--Eloquence* 01:36, 11 September 2012 (UTC)[reply]
It does, thanks. One aside. We should be able to make the bubble message that appears now when you add or remove a page from your watchlist go away (escape?), or failing that, it should fade after a bit. It covers up the whole area making it difficult to access certain portions of the menu. I often have to refresh the page just to make it disappear.--Bbb23 (talk) 12:27, 11 September 2012 (UTC)[reply]
For me (Windows Vista, Firefox 13) it fades away after about 5 seconds. -- John of Reading (talk) 12:37, 11 September 2012 (UTC)[reply]
Huh, I coulda sworn it didn't, but it certainly does now, thanks, John.--Bbb23 (talk) 22:36, 11 September 2012 (UTC)[reply]

When should Foreign character warning boxes be used?

Sorry if I'm in the wrong place—there are so many of these templates I couldn't find a single talk page which seemed proper for this discussion. I'm posting here since these the original purpose of these templates was to serve as technical warnings.

What is the proper use of {{Special characters}} and its derivatives, i.e. the templates in Category:Foreign character warning boxes? It seems reasonable that they shouldn't be included in articles where the foreign script in question appears only once in the first sentence, and they would be useful for articles discussing the language or its literature. But what about articles which mention several (read: less than a dozen) foreign names, but where the display of those names aren't essential to the understanding of the article itself (since the names are also represented in Latin script)? Their appearance is consistently aesthetically unappealing, whether placed below infoboxes or next to lead images. And there are even editors who apparently think that these boxes serve to list all the scripts which appear in an article. I know there are readers whose operating systems don't come pre-installed with non-Latin text support, but are these templates really still necessary? The context in which these foreign scripts appear should usually be enough for the reader to understand what they're supposed to show, whether or not it renders correctly. --115.67.34.95 (talk) 05:36, 11 September 2012 (UTC)[reply]

A common.js install script

I want to create a url which preloads a script that adds code to a user's common.js page.

Teahouse did this nifty trick using this code:

  • http://en.wikipedia.org/w/index.php?action=edit&preload=User%3AJtmorgan%2Fintroductions%2Ftemplate+left&editintro=&preloadtitle=&section=new&title=Special%3AMyPage%2Fcommon.js
  • Which loads: User:Jtmorgan/introductions/template_left
  • Which calls: importScript("User:Writ Keeper/Scripts/teahouseTalkbackLink.js");

So my version would be:

  • (Fixed version)http://en.wikipedia.org/w/index.php?action=edit&preload=User%3AOcaasi%2FWikiLoveinstall&editintro=&preloadtitle=&section=new&title=Special%3AMyPage%2Fcommon.js
  • Which loads User:Ocaasi/WikiLoveinstall
  • Which calls: importScript("User:Ocaasi/WikiLoveinstallscript.js");

I'm don't know what to do with User:Ocaasi/WikiLoveinstallscript.js. How do I go about crafting that code so that it automatically preloads the code that is on my common.js page (or on another subpage) into any user's common.js page. Thanks for any tips! Ocaasi t | c 11:52, 11 September 2012 (UTC)[reply]

Try http://en.wikipedia.org/w/index.php?action=edit&preload=User%3AOcaasi%2FWikiLoveinstall&editintro=&preloadtitle=&section=new&title=Special%3AMyPage%2Fcommon.js -- WOSlinker (talk) 12:35, 11 September 2012 (UTC)[reply]
Works like a charm! Do you have any idea what to do with User:Ocaasi/WikiLoveinstallscript.js? That's the core code and I have no clue how to make it call that code to be placed on someone's common.js page. Thanks so much for your help! Ocaasi t | c 12:39, 11 September 2012 (UTC)[reply]

Template rather than script

I also tried to preload the page with a template rather than a script. So:

  • http://en.wikipedia.org/w/index.php?action=edit&preload=%7B%7BUser%3AOcaasi%2FWikiLoveinstallscript.js%7D%7D&editintro=&preloadtitle=&section=new&title=Special%3AMyPage%2Fcommon.js

That should load {{User:Ocaasi/WikiLoveinstallscript.js}} into the editor's common.js editing screen. But... it's not working. This does work but as before the script doesn't yet know how to transfer the code from User:Ocaasi/WikiLoveinstallscript.js to common.js. Ocaasi t | c 15:43, 11 September 2012 (UTC)[reply]

That's not how preload works, I think. It doesn't accept wikitext as a parameter, only the title of a page; the specified page's source then gets dumped into the edit box. So, putting brackets in it isn't going to help. Are you trying to get the text {{User:Ocaasi/WikiLoveinstallscript.js}} to be put into the edit box, or are you trying to get the contents of the page User:Ocaasi/WikiLoveinstallscript.js (as if you did a substitution like {{subst:User:Ocaasi/WikiLoveinstallscript.js}}) into the page? If the latter, than you can just take out the brackets and it'll work. If the former, then you'd need to create a page that contains {<includeonly></includeonly>{User:Ocaasi/WikiLoveinstallscript.js}<includeonly></includeonly>} or something like that; the preloader will take out the includeonly tags, leaving only {{User:Ocaasi/WikiLoveinstallscript.js}} in the editbox, and use that. Writ Keeper ⚇♔ 16:26, 11 September 2012 (UTC)[reply]
Yes, I'm trying to get User:Ocaasi/WikiLoveinstallscript.js, but I hoped to do it as a transclusion if possible so that we could make changes on the fly.
EDIT: Something like http://en.wikipedia.org/w/index.php?action=edit&preload=User%3AWK-test%2Fsandbox&title=Special%3AMyPage%2Fcommon.js should do the trick. Writ Keeper ⚇♔ 16:29, 11 September 2012 (UTC)[reply]
That works. But it leaves some vulnerability if we need to change the code mid-course. So, again, transclusion would be ideal. If not, we just have to be really careful to get the code right and complete before people start adding it to their common.js pages. Ocaasi t | c 17:04, 11 September 2012 (UTC)[reply]
I'm currently using http://en.wikipedia.org/w/index.php?action=edit&preload=User%3AOcaasi%2FWikiLoveinstall&title=Special%3AMyPage%2Fcommon.js Ocaasi t | c 17:26, 11 September 2012 (UTC)[reply]
Right, so use importScript("User:Ocaasi/WikiLoveinstallscript.js"); as the Teahouse example did; that'll have the effect you're looking for. Writ Keeper ⚇♔ 18:07, 11 September 2012 (UTC)[reply]

Pages added to categories

How do I see what pages have been added to all of the categories that are on my watchlist? Is there a tool or template or what? This is not the same as watching all of the pages in a category. I simply want to know when pages are added to all of the categories on my watchlist. Thank you! Allen (Morriswa) (talk) 23:54, 11 September 2012 (UTC)[reply]

Go to the category page, for example Category:Cats. Then on the left side of the page, look for the Related changes link in the Toolbox section. Click it and you'll get a page like this Special:RecentChangesLinked/Category:Cats. It won't really tell you when pages are added to a category, but if you watch it closely enough, you'll be able to spot new articles. –Fredddie™ 01:08, 12 September 2012 (UTC)[reply]
Similar thread raised at Wikipedia talk:WikiProject Categories#Pages added to categories. --Redrose64 (talk) 10:22, 12 September 2012 (UTC)[reply]
It seems crazy that this can't be done at present, at least for category additions (the categorylinks table already includes a timestamp field which would easily allow tracking of additions since any given time; category link deletions could not be tracked without keeping a separate snapshot of former entries, or creating a hook each time a link is removed from the table). Are there any relevant toolserver tools at present? — Richardguk (talk) —Preceding undated comment added 11:04, 12 September 2012 (UTC)[reply]
Fredddie: Thanks for the temporary solution. However, I want to know what pages have been added to all of the categories that I am watching.
RedRose: Yes, this is the same topic thread on the Categories WikiProject. I just thought I'd spread my question around to try to get more responses.
Richardguk: Yes, it does seem "crazy" that this can't be done currently. This should be added as a default function in the MediaWiki software. Or, a gadget should be added to the "My preferences" page. Or, a link to make a page for this purpose (just like the myskin.js on the "My preferences" page) could be added to the "My preferences" page.
If any of you (or anyone else) has a real option to help me, please let me know. Thanks a lot in advance! Allen (Morriswa) (talk) 17:01, 12 September 2012 (UTC)[reply]

Still need parser function #set

When trying to reduce templates for the wp:Expansion depth limit, I keep noticing the need for an assignment operator of a "real language", such as a parser function "{{#set:xx|50}}" or without "#" as "{{set:xx|50}}" to set parameter {{{xx}}} to "50" inside the same template, not require a subtemplate to set the value of a parameter. I realize this simple function would make templates much easier to write, and could then run 10x faster, with an expansion depth of 4, rather than 40 levels, but surely we could invent some other problems to make editors miserable. Here's the deal: the assignment operator, to set the value of a variable, is the most common operator in small computer software programs (the procedure call is most-common in large software). So, anyway, the need for #set is the "elephant in the room" for "Why Johnny can't write templates"  without going wiki-insane. Who decides these issues, to add parser functions? -Wikid77 (talk) 06:35, 12 September 2012 (UTC)[reply]

Tim Starling —TheDJ (talk • contribs) 08:36, 12 September 2012 (UTC)[reply]
And of course it is being addressed, it's called Scribunto, you just choose not to accept the timetable in which it is being addressed. —TheDJ (talk • contribs) 08:54, 12 September 2012 (UTC)[reply]
See mw:Lua scripting for the timetable. PrimeHunter (talk) 10:44, 12 September 2012 (UTC)[reply]
There is an extension mw:Extension:Variables, not of much help on here though as its unlikely to be installed. --Salix (talk): 10:48, 12 September 2012 (UTC)[reply]
Thank you for the news. See note below, "Global variables by mw:Extension:Variables" -Wikid77 (talk) 04:43, 13 September 2012 (UTC)[reply]
(edit conflict) I think the rationale for preventing in-page assignment is that it changes the parser environment from stateless to stateful (apologies if I've misused the terminology), instead of relying solely on recursive expansion. Anyway, as TheDJ says, things are set(!) to change. If the imminent testing assessment goes well, Scribunto rollout is proposed for 2013Q1. — Richardguk (talk) 10:51, 12 September 2012 (UTC)[reply]
If there were any major parsing advantages by preventing in-page assignment of parameter values, then I would consider them less important, than the potential gains of storing a tedious result in a local parameter. Currently, we have many templates which repeat a calculation, or procedure, numerous times, or pass the result into a nested template, because the result cannot be stored in a local parameter. As a consequence of passing the result into another template, then any related parameters must also be passed, and we can get the 2x-slower templates which pass 200 parameters into a subtemplate because they cannot store the result of some complex calculations inside the current template. One of the worst problems has been the Template:Taxobox taxon-chains, where getting the greatgrandparent taxon of the grandparent taxon of the parent taxon (etc.) causes nested templates to run 35 deep, into other templates to reach 60-taxon depth. However, the careful use of nested subtemplates has allowed for 60-level taxon chains, within the current expansion depth limit of 40 nested levels. It is ironic however, that for years, one simple function as {{#set:taxon|{{taxonomy|{{{taxon}}}|code=parent }} could have avoided 30 levels of nested expansion depth, by the addition of one trivial parser function. -Wikid77 (talk) 03:53, 13 September 2012 (UTC)[reply]
  • Global variables by mw:Extension:Variables: An even better fix would be to install mw:Extension:Variables, which would define global variables which could span from the top article text into the various templates used. That would be awesome, to allow each article to set global preferences for how templates would function, based on the settings made inside the article text, rather than per-user preferences. In such a case, we could, indeed, have measurement conversions which displayed the Imperial or U.S. customary units first, in article text, simply based on a global variable which triggered the flipping of units. Even though enwiki is kept limited, with relatively little progress, it is refreshing to know how other people have radically expanded to make a MediaWiki installation produce clever, auto-customized results, through such simple, efficient extensions. O, brave new world, that has such creatures in it. I have seen the future, and it has returned. Thank you. -Wikid77 (talk) 04:43, 13 September 2012 (UTC)[reply]
    This extension is incompatible with template caching. Ruslik_Zero 06:23, 13 September 2012 (UTC)[reply]
    See also bugzilla:7865. --Redrose64 (talk) 14:41, 13 September 2012 (UTC)[reply]

I have noticed recently a problem where NAVBOX'es are extending far past the right of the browser window instead of having the elements wrap in a nice way. The navbox at the end of the Operation Nougat article is an example. This behavior is browser dependent. I see the behavior under Firefox 15 and an up-to-date Chrome but the navbox renders fine under Opera 12. I have seen this behavior quite frequently in the last few months although it only affects a small percentage of pages. Can someone shed some light on what is causing this? Jason Quinn (talk) 14:06, 12 September 2012 (UTC)[reply]

PS One more thing, if I view the actual NAVBOX template. It wraps just fine. Jason Quinn (talk) 14:07, 12 September 2012 (UTC)[reply]
As it happens, Operation Nougat displays the navbox overwide for me too. Firefox 15.0.1 has a neat feature in that if you view the page source (right-click and select "View Page Source", or press Ctrl+U), any "bad" HTML shows up in bright red. Looking at the page source for Operation Nougat confirms my suspicions: some of the HTML closing tags (</li></ul> or </div>) have been misplaced, and don't occur in the proper table cell.
It's not a problem with the navbox itself, but with the HTML Tidy feature of MediaWiki, see Wikipedia:Village pump (technical)/Archive 102#Are the HTML generators out of sync on some servers? and bugzilla:38273. The problem server is mw20. --Redrose64 (talk) 16:14, 12 September 2012 (UTC)[reply]
Great. Thanks, RedRose64. I didn't know about HTML Tidy before now. The reporter of bug 38273 says that reports started around July. This general time period is consistent with when I first started noticing these problems although I don't remember the exact month. It wasn't until now that I decided to investigate it. Sometimes in the past, just loading the page once or a few times would fixed the issue, which was confusing. Operation Nougat is working now so I suppose something got purged. Thanks for the reply. Jason Quinn (talk) 17:53, 12 September 2012 (UTC)[reply]

Circular Redirects

Just out of curiosity, what would happen if you placed redirect tags on two pages, each redirecting to the other? I thought about trying this in my sandbox, but decided it was a bad idea, in case the situation exploded and could not be undone. Thanks! Ebikeguy (talk) 14:55, 12 September 2012 (UTC)[reply]

Answer: nothing. I wondered about this myself a while ago, and had the same reluctance to try it. Redirects only happen one time; after you're redirected once, you don't get redirected again, even if you're left at another redirect page. This is why double redirects need to be fixed; it just dumps you at the second redirect, without making you continue along the chain to the intended target. Here, check it out. Writ Keeper ⚇♔ 15:07, 12 September 2012 (UTC)[reply]
Darn it, Pinky, I will have to search for a new way to take over the world. -The Brain, aka: Ebikeguy (talk) 15:16, 12 September 2012 (UTC)[reply]
Brain, we just tried to delete you; what are you doing coming back so quickly? Nyttend (talk) 00:45, 13 September 2012 (UTC)[reply]

Image class

File:Vandalism_San_Francisco.jpg

I am curious why one of these images has an 'image' class in its wrapping anchor tag but the second one does not? The only difference between them is |link= parameter. Is it a bug or intended behavior? Ruslik_Zero 19:18, 12 September 2012 (UTC)[reply]

It is not the image with the 'image' class, but the link. And one link has an image as a target, and the other link does not. —TheDJ (talk • contribs) 21:25, 12 September 2012 (UTC)[reply]
I changed the link in the second image to point to the image itself but still there is no image class. It appears that that the class disappears if nonempty link parameter is present. Ruslik_Zero 03:51, 13 September 2012 (UTC)[reply]
Lol, the system is not THAT smart, it doesn't actually look at the target file, just assumes that when you use link, you want to link to something different than the default, which is the image. —TheDJ (talk • contribs) 07:55, 13 September 2012 (UTC)[reply]
There appears to be bug report for this. Ruslik_Zero 06:48, 13 September 2012 (UTC)[reply]
These behavior is inconsistent. And currently the 'image' class is just useless. It is impossible to apply any consistent style to all anchor tags with images inside. Ruslik_Zero 10:09, 13 September 2012 (UTC)[reply]

Template editing

Hi, is there any good tool available for editing templates. I was looking for one that either shows syntax or enables you to hi-light or hop between matching brackets. Keith D (talk) 23:03, 12 September 2012 (UTC)iki[reply]

Gadget WikiEd highlights template syntax. Ruslik_Zero 04:12, 13 September 2012 (UTC)[reply]
Also meta:User:Remember the dot/Syntax highlighter. —Remember the dot (talk) 05:06, 13 September 2012 (UTC)[reply]
I have installed importScript('User:Ais523/bracketmatch.js');. I cannot find its maintenance page. -DePiep (talk) 07:09, 13 September 2012 (UTC)[reply]
Thanks, the first 2 do not really do much for heavy bracketed templates. The third one looks interesting so I installed it and appears to help trying to get things balanced up again. Keith D (talk) 11:45, 13 September 2012 (UTC)[reply]
Do come back if it doesn't work, I can write some manual lines. -DePiep (talk) 13:16, 13 September 2012 (UTC)[reply]

Release 1.20wmf11 re-deployed

Just a quick note that we re-deployed MediaWiki 1.20wmf11 (list of changes) today. This also includes an upgrade to jQuery 1.8.1 from 1.7.2 (release notes for 1.8.0; release notes for 1.8.1).--Eloquence* 01:53, 13 September 2012 (UTC)[reply]

Could this have broken the timeline extension? See Wikipedia:Help desk#Timeline display issues. There's a timeline at User:John of Reading/X2; go there, click "Edit", make a trivial change, "Preview" - and nothing is displayed. -- John of Reading (talk) 07:19, 13 September 2012 (UTC)[reply]
Probably related, yes; I know Aaron and Tim have been working on moving the timeline generated images to the new Swift storage system. I've opened Template:Bugzilla in case they're not aware of the breakage.--Eloquence* 07:41, 13 September 2012 (UTC)[reply]
Should be fixed now.--Eloquence* 05:18, 14 September 2012 (UTC)[reply]

ENWP image syntax usage

Has anybody run statistics on image sizing on ENWP? I'm interested to know what the most common image sizes are, versus how many people leave sizing to user preference (by using the thumb, frameless, frame, etc.). Also I'd be very interested to see how this evolves over time, as screen resolutions increase, but that would require an older data set which I doubt exists. ▫ JohnnyMrNinja 02:35, 13 September 2012 (UTC)[reply]

Tabs moved to bottom of page in Opera

Tracked in Phabricator
Task T42208

Since this morning, using Opera 12.02, all the tabs and user buttons have moved from the top of an article page to the bottom -- "Read", "Edit", "View history", and "My watchlist", "My contributions", etc. See screenshot. Has there been a change in the code since yesterday that could cause this? It's extremely annoying. Barsoomian (talk) 03:30, 13 September 2012 (UTC)[reply]

I'm not sure what could have caused that :S. I'll stick it in Bugzilla for you now :). What OS are you on? Okeyes (WMF) (talk) 03:31, 13 September 2012 (UTC)[reply]
Now tracking :). Okeyes (WMF) (talk) 03:33, 13 September 2012 (UTC)[reply]
Using Win2k (I know...). Also just noticed a similar problem with Google's search page, so it's more likely an Opera bug. Barsoomian (talk) 03:52, 13 September 2012 (UTC)[reply]
  • Okay, fixed it, an Opera "style" preference, ("View/Style/Disable positioning", CSS override I think) -- which I'm sure I didn't change, but now turned off and pages are back to normal. Can close the issue, thanks. Barsoomian (talk) 04:38, 13 September 2012 (UTC)[reply]

User:Mr.Z-man/closeAFD.js

It looks like something has broken User:Mr.Z-man/closeAFD.js (documentation) today, and I am guessing it is probably related to the upgrade of jQuery mentioned above. The dialogue that used to appear underneath the "edit" tab now appears in the very top left of the screen, so that the buttons are obscured by the Wikipedia logo. (So it's basically unusable.) Could someone who knows JavaScript take a look and try to figure out what's going on? Thanks — Mr. Stradivarius (have a chat) 09:56, 13 September 2012 (UTC)[reply]

Oh, and this is on Vector. — Mr. Stradivarius (have a chat) 09:58, 13 September 2012 (UTC)[reply]
I think this is the same issue as Wikipedia talk:WikiProject Articles for creation#unable to use WP:AFCH script and Wikipedia talk:WikiProject Articles for creation#unable to use WP:AFCH script#Moving the "reviewing" tray because both use User:Timotheus Canens/displaymessage.js. PleaseStand (talk) 10:34, 13 September 2012 (UTC)[reply]
I think if Timotheus Canens or another admin deletes both occurrences of .parent() from User:Timotheus Canens/displaymessage.js, the script will work how it should again. I think gerrit:19008 is what broke the script. PleaseStand (talk) 10:52, 13 September 2012 (UTC)[reply]
Ok, I've done the edit, and it looks like it works. Thanks! — Mr. Stradivarius (have a chat) 10:56, 13 September 2012 (UTC)[reply]

Sorting of CAT:ALLPROD

The sorting of page CAT:ALLPROD seems to be broken when I view it. It should be sorted alphabetically, but the entries for individual numbers which I assume should only list articles whose name starts with the appropriate number, include a random selection of entries. Example: under heading "0" I see 1-2-3 (game), 2008 England national rugby league team season, 2012 Luke Pomersbach molesting charges, Adriano Moké, Alen Halilović... Is this broken? --Colapeninsula (talk) 12:37, 13 September 2012 (UTC)[reply]

The sorting is deliberate. Template:Proposed deletion/dated contains [[Category:All articles proposed for deletion|{{mod|{{#time:j|{{{timestamp}}}}}|10}}{{PAGENAME}}]]. The code produces a leading digit for sorting. The digit should be the last in the day of the month of the nomination. This means editors going through the category can often see how long ago a page was nominated (31 or 1 may cause problems). Post to Template talk:Proposed deletion if you want to suggest a change. PrimeHunter (talk) 13:56, 13 September 2012 (UTC)[reply]

Broken image with a file now on commons

Tracked in Phabricator
Task T41615

The image File:Polygon types.svg has been moved to commons commons:File:Polygon types.svg and the file deleted here. Rather than get the normal redirection to the commons page you get (e.g. File:Assorted polygons.svg) I instead get "View or restore 11 deleted edits?" with a broken image. The image also appears broken in the article Polygon. Is there a way to fix this so we don't get a broken image in the article?--Salix (talk): 13:57, 13 September 2012 (UTC)[reply]

This is an issue caused by the switch to the new file storage backend. Waiting is all that is required (of users) for this to become fixed. —TheDJ (talk • contribs) 14:12, 13 September 2012 (UTC)[reply]

Wikipedia:Metadata needs help

I think this is a very important page, yet it is just a list. Could somebody try to add some prose to it, and generally make it more presentable? --Piotr Konieczny aka Prokonsul Piotrus| reply here 21:37, 13 September 2012 (UTC)[reply]

Protection log entries are obscured when a page is moved

I just noticed in answering a help desk post here that when a protected page is moved and the protection is moved with it, the protection log entry for the new title doesn't show the form of protection, only that the protection was moved. This means that to see form of the protection, you have to look at the log entry for the prior title.

Wouldn't it be cleaner if the log entry said something like "moved protection settings ([move=sysop] (indefinite)) from "Title 1" to "Title 2"..."? (addition in green). I have little experience with Bugzilla searches (to see if this already has been explored) or posting there so I thought I'd lay this out here for comment.--Fuhghettaboutit (talk) 21:48, 13 September 2012 (UTC)[reply]

bugzilla:38123 is closely related. PrimeHunter (talk) 22:03, 13 September 2012 (UTC)[reply]
Thanks. I have posted there and voted.--Fuhghettaboutit (talk) 23:16, 13 September 2012 (UTC)[reply]

restricted page needs redirect.

http://en.wikipedia.org/wiki/Pretty_lights has been deleted, and is locked for editing. It should redirect to http://en.wikipedia.org/wiki/Pretty_Lights. I can't add a redirect. --naught101 (talk) 00:55, 14 September 2012 (UTC)[reply]

Boy, was I surprised to see that I was the one who originally deleted that page. Anyway, redirect created. Someguy1221 (talk) 01:28, 14 September 2012 (UTC)[reply]

Two questions

I have two, entirely unrelated questions. I thought I'd ask them together, so I didn't have to open two threads.

  1. I'm sure this has been asked before, but I couldn't find the JavaScript to do it—how do you add a sidebar link (in this case I want it to be so that I can view all the logs for any given page)?
  2. When I rollback an edit on a page, the page isn't added to my watchlist, despite having "Add pages and files I edit to my watchlist" enabled in my preferences. Why is this happening?

If anyone can answer either of these questions, that would be great. Thanks, David1217 What I've done 01:24, 14 September 2012 (UTC)[reply]

User:Gadget850/Help:Sidebar is a work in progress. However, if you enable Preferences → Pending changes → Add page and user options to drop-down menus on the toolbar, then you get a Page tab at the top which includes page logs. ---— Gadget850 (Ed) talk 01:32, 14 September 2012 (UTC)[reply]
I like that gadget, but I wish it didn't make the history tab go away. Is there any way to change that? David1217 What I've done 02:16, 14 September 2012 (UTC)[reply]
History is a dropdown under the Page tab. ---— Gadget850 (Ed) talk 16:03, 14 September 2012 (UTC)[reply]
I know, but I want the history tab to be on its own, like it is without the gadget. David1217 What I've done 23:54, 14 September 2012 (UTC)[reply]
Never mind, I figured out how to do that (I should have looked at the script description page!) David1217 What I've done 00:11, 15 September 2012 (UTC)[reply]
  1. You can use the addPortletLink function to add links to the sidebar and other menus.
  2. Rollback bypasses normal editing procedures, including adding anything to your watchlist; if you want to add a page to your watchlist, you'll need to either edit it a different way (such as twinkle's rollback or another script serving that purpose) or manually watch it. -— Isarra ༆ 05:31, 14 September 2012 (UTC)[reply]
Thank you, Isarra, for the link and the explanation. David1217 What I've done 23:54, 14 September 2012 (UTC)[reply]

Page view referrals

I just noticed that one of the articles that I have been working on had a significant spike in views a couple of days ago, and I was wondering if there is any way to find out where the referrals are from (I assume the link was posted on a website). 'Page view statistics' does not seem to have this option. CanadianJudoka (talk) 06:56, 14 September 2012 (UTC)[reply]

2001:0:0:0:0:0:0:1

Is User:2001:0:0:0:0:0:0:1 a real user, or is it an IPv6 address like me? It appears when I tell Special:Listusers to search starting at 2001:18E8:2:1020:9A4:966F:1021:7F4A, complete with a log entry, but when I look at contributions I get the normal "Please note: these are the contributions from a user editing from an IPv6 address" warning, and the "log" link accessible from that page has no log entries at all. 2001:18E8:2:1020:9A4:966F:1021:7F4A (talk) 16:28, 14 September 2012 (UTC)[reply]

It's a valid IPv6 address. That said, no one has yet edited using that address, as evidenced by the empty log. elektrikSHOOS (talk) 16:48, 14 September 2012 (UTC)[reply]
There is a bit of strangeness there. The ListUsers page shows a user named "User:2001::1" created in 2006, long before that syntax meant anything special; but when you try to follow that link, the latest software thinks it has to be clever and takes you to User:2001:0:0:0:0:0:0:1 instead. -- John of Reading (talk) 16:57, 14 September 2012 (UTC)[reply]
That account must be renamed, as it was likely created before IPv6 was recognized by MediaWiki as valid IP addresses.--Jasper Deng (talk) 01:16, 15 September 2012 (UTC)[reply]
I think it would take a developer to do that. Every attempt to use administrative tools on that account sends me to 2001:0:0:0:0:0:0:0:1. I assume the rename function would face the same issues. So in fact, what has been pointed out here is likely an unblockable account. Did no one screen for IPv6-like account names before it was implemented on Wikipedia? Someguy1221 (talk) 01:32, 15 September 2012 (UTC)[reply]
No; for now it may be possible to stop the user from editing using an edit filter for such usernames. --Jasper Deng (talk) 01:41, 15 September 2012 (UTC)[reply]
I don't think the user can even log in. I get "Login error You have not specified a valid user name" when I enter that name at login with a random password. PrimeHunter (talk) 01:53, 15 September 2012 (UTC)[reply]

Font size

I am working on a table and I would like it to use a smaller font than the rest of the article so that it takes up less space. I've looked around, though, and I can't find a page that explains how to change the font size. Any suggestions? CanadianJudoka (talk) 23:10, 14 September 2012 (UTC)[reply]

Add style="font-size:...%;" to the table formatting. For example, to reduce the text to 90% of the usual size:
{| class="wikitable" style="font-size:90%;"
|-
! Example heading
|-
| Example text
|}
which produces:
Example heading
Example text
More guidance at Help:Table.
— Richardguk (talk) 00:52, 15 September 2012 (UTC)[reply]
Great, thanks for your help. CanadianJudoka (talk) 02:42, 15 September 2012 (UTC)[reply]
See Template:Resize
Also a related/current discussion at Wikipedia_talk:Manual_of_Style/Accessibility#Small_print. (Don't go too small. 90% is probably a good minimum) —Quiddity (talk) 20:30, 15 September 2012 (UTC)[reply]

Sync the time

How can I make the clock below be synchronized with GMT +8? 

<div style="border:1px solid #ccc; background: #fff; border-right:3px solid #ccc; border-bottom:3px solid #ccc; text-align: center; padding:3px; float:{{{1}}}; font-size: smaller; line-height: 1.3; margin-right: 4px;">
<div style="width:100%">{{CURRENTDAYNAME}}</div>
<div style="font-size: x-large; width: 100%;">{{CURRENTDAY}}</div>
<div style="width: 100%;"> {{CURRENTMONTHNAME}}</div>
<div style="background: #aaa; color: #000;">'''{{CURRENTTIME}}''' PHT</div>
</div></center></div>
<span style="border:1px solid black;padding:1px;">[[User:TruPepitoM|<font style="color:#1404bd;background:#de0100;">TruPepitoM</font>]][[User talk:TruPepitoM|<font style="color:#de0100;background:#1404bd;">Talk to us</font>]]</span>

TruPepitoMTalk To Me 00:29, 15 September 2012 (UTC)[reply]

Try this with {{#time: |+8 hours}} formatting instead of {{CURRENT...}}:
<div style="border:1px solid #ccc; background: #fff; border-right:3px solid #ccc; border-bottom:3px solid #ccc; text-align: center; padding:3px; float:{{{1}}}; font-size: smaller; line-height: 1.3; margin-right: 4px;">
<div style="width:100%">{{#time: l|+8 hours}}</div>
<div style="font-size: x-large; width: 100%;">{{#time: j|+8 hours}}</div>
<div style="width: 100%;"> {{#time: F|+8 hours}}</div>
<div style="background: #aaa; color: #000;">'''{{#time: H:i|+8 hours}}''' PHT</div>
</div></center></div>
<span style="border:1px solid black;padding:1px;">[[User:TruPepitoM|<font style="color:#1404bd;background:#de0100;">TruPepitoM</font>]][[User talk:TruPepitoM|<font style="color:#de0100;background:#1404bd;">Talk to us</font>]]</span>
PrimeHunter (talk) 00:43, 15 September 2012 (UTC)[reply]
The #time formatting is documented at mw:Help:Extension:ParserFunctions##time. PrimeHunter (talk) 00:55, 15 September 2012 (UTC)[reply]

Pushpin map

I'd like to create a pushpin map from this file File:Ipswich UK ward map 2010 (blank).svg . Are there instructions on how I can do this?

JASpencer (talk) 07:31, 15 September 2012 (UTC)[reply]

See Creating a new map template. Keith D (talk) 11:53, 15 September 2012 (UTC)[reply]
Now sorted. Thank you. JASpencer (talk) 17:45, 15 September 2012 (UTC)[reply]

Wikimedia Foundation error on first attempt to access each page

For each page, I'm getting a Wikipedia:Wikimedia Foundation error on the first attempt to access it on Wikipedia. The page loads correctly on subsequent attempts. What's going on? Firefox 15 on Windows 7. — DragonLord (talk/contribs) 15:32, 15 September 2012 (UTC)[reply]

Details about this error:
Request: POST http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=submit, from 10.64.0.139 via cp1010.eqiad.wmnet (squid/2.7.STABLE9) to () Error: ERR_CANNOT_FORWARD, errno [No Error] at Sat, 15 Sep 2012 13:45:43 GMT

— DragonLord (talk/contribs) 15:33, 15 September 2012 (UTC)[reply]

Note that this happened about 55 minutes ago, and I no longer get this error, but I'd like to know why this happened. — DragonLord (talk/contribs) 15:40, 15 September 2012 (UTC)[reply]
The error message stopped for a time but started again. In addition, editing generally is exceptionally slow, although there are intermittent periods of normal (or near normal) response times.--Bbb23 (talk) 17:49, 15 September 2012 (UTC)[reply]

Trouble logging in?

Is anyone else having very slow logins, not all the icons on the global login page loading, and issues staying logged in (i.e. login, go back to page being viewed, refresh and it says logged out)? - The Bushranger One ping only 17:13, 15 September 2012 (UTC)[reply]

And now I'm being occasionally logged out while browsing too. Sigh! - The Bushranger One ping only 17:18, 15 September 2012 (UTC)[reply]
Yes, this has been happening to me too. (I'm logged in via the secure server.) It looks like there is some kind of problem with the server connection going on and off. I've had trouble logging in, trouble saving an edit, and trouble with being logged out when changing from page to page. --Tryptofish (talk) 17:27, 15 September 2012 (UTC)[reply]
I'm not on the secure server, but I haven't had any login issues. — DragonLord (talk/contribs) 17:43, 15 September 2012 (UTC)[reply]
Update: No issues on the secure server, either. — DragonLord (talk/contribs) 17:57, 15 September 2012 (UTC)[reply]
Wikipedia is very slow to respond for me; it is suffering some problems with eiter the squids or an internal router. A Traceroute reveals no problem, but the above error indicates an internal connection issue. — Edokter (talk) — 18:09, 15 September 2012 (UTC)[reply]
Looks like some slow servers have been rebooted. — Richardguk (talk) 19:44, 15 September 2012 (UTC)[reply]

Ajax Quick Preview scripts and gadgets

Anyone uptodate or curious about AjaxPreview / QuickPreview / Live preview / etc ?

Please see WP:VPR#Previewing an edit using Javascript instead of the servers and give advice/feedback/synopsis.

(I listed as much as I could find, and have probably overwhelmed that thread with amateur research! >.< ) Thanks. —Quiddity (talk) 20:47, 15 September 2012 (UTC)[reply]

a mess: List of residences of Joseph Haydn

List of residences of Joseph Haydn: this article is a mess because of the pictures over the text: i'm not good enough with tables: can someone fix it? thanks 62.203.79.47 (talk) 23:09, 15 September 2012 (UTC)[reply]

I got rid of the quote box template to uncover the section edit links. The template might have been added to prevent the edit links from "bunching up", which is no longer a problem because of a 2010 change to Wikipedia's CSS code. Nevertheless, this article has too many images, and some ought to go. PleaseStand (talk) 00:00, 16 September 2012 (UTC)[reply]
thanks for the fixing + no, i don't think there are too many pics! 83.78.188.3 (talk) 06:37, 16 September 2012 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=512832372"