:I just wanted to voice my concern as well. The new font is nearly unreadable for me in Firefox 25 on Windows 8 on a 1080p 24 inch LCD monitor. I've resorted to user CSS to change it back. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Kimsey0|Kimsey0]] ([[User talk:Kimsey0|talk]] • [[Special:Contributions/Kimsey0|contribs]]) 22:39, 18 November 2013 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
:I just wanted to voice my concern as well. The new font is nearly unreadable for me in Firefox 25 on Windows 8 on a 1080p 24 inch LCD monitor. I've resorted to user CSS to change it back. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Kimsey0|Kimsey0]] ([[User talk:Kimsey0|talk]] • [[Special:Contributions/Kimsey0|contribs]]) 22:39, 18 November 2013 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
-- YES - WHAT HAPPENED TO THE FONT OF LANGUAGES ? ? ? - the font has changed to something that requires "font smoothing" -- I thought that the previous use of Arial was just fine, now the list is almost unreadable!!
-- YES - WHAT HAPPENED TO THE FONT OF LANGUAGES ? ? ? - the font has changed to something that requires "font smoothing" -- I thought that the previous use of Arial was just fine, now the list is almost unreadable!! <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/24.6.95.77|24.6.95.77]] ([[User talk:24.6.95.77|talk]]) 06:02, 19 November 2013 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to securitywikimedia.org or filed under the "Security" product in Bugzilla.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
The interlanguage links have changed their font-family. They used to be in the same font-family as the rest of the page (Arial), but now they are something called "Autonym" which is apparently pulled from
It appears to be a result of <div id="p-lang" class="portlet" role="navigation">...</div>. The trouble with that font is that it's indistinct (Windows XP, Firefox 24, MonoBook) - it's blurred, with blue and red fringing, particularly on tall thin letters like lowercase i and l - see screenshot at right. Arial, by contrast, is sharp-edged without fringing. This isn't just English Wikipedia; it's others too e.g. French. --Redrose64 (talk) 21:13, 1 November 2013 (UTC)[reply]
#p-lang ul { font-family: inherit; } should reset the font its original value. I agree the font does not render well at all on Windows. — Edokter (talk) — 22:48, 1 November 2013 (UTC)[reply]
...I find it hard to believe that there are very many computers out there that don't have Arial... thanks Redrose64 for the fix script (and btw, it works if you have it all on a single line in the skin.css as well). - The BushrangerOne ping only23:56, 1 November 2013 (UTC)[reply]
It's not a script, it's a CSS rule. CSS is very tolerant of whitespace - generally speaking, if a newline is permitted, a space is permitted instead - and most spaces may be removed. In fact, in that particular CSS rule, only one of the spaces is mandatory - the one before ul - so you can put
"inherit" is better because you don't need to specify any font; it resolves to the parent elements font, which is whatever the rest of the page uses. — Edokter (talk) — 14:54, 2 November 2013 (UTC)[reply]
I know; but I was replying to The Bushranger, who was replying to me, so I repeated my example changing only the whitespace. I could have used
#p-langul{font-family:inherit;}
but this would not have illustrated the whitespace elimination quite so well, because there were other changes not related to whitespace. --Redrose64 (talk) 19:20, 2 November 2013 (UTC)[reply]
I liked the idea of using the native-language name, but in practice it made things so much harder for me to find (as a monolingual reader who occasionally wants to check out various other language examples) - I'd often have to mouse-over each of the links, looking for the 2letter prefix that looked familiar or correct. –Quiddity (talk) 20:08, 2 November 2013 (UTC)[reply]
Using some zooming, I just realized Autonym is based on FreeSans, possibly the worst rendering open source font out there. I realize FreeSans has extensive unicode support, but if possible, Autonym should source its glyphs from Nimbus Sans L (which is what FreeSans is based on). — Edokter (talk) — 10:41, 10 November 2013 (UTC)[reply]
It is ironic that a change specifically intended to make this list more readable has gone and made it less legible. I'm surprised that there isn't more of a fuss about this. Presumably the more vocal techies have larger screen resolutions and are unaffected. SFB11:57, 10 November 2013 (UTC)[reply]
I missed this thread and posted down below. It's a ghastly choice of font. I'm working on a 17" CRT monitor, and I'd hate to think what it looks like on anything smaller. It may look better on LCD, but I doubt it. Peridon (talk) 17:43, 11 November 2013 (UTC)[reply]
It looks awful everywhere. I've got a nice big flat widescreen and it still hurts to look. Luckily I have SidebarTranslate, so I don't ever need to see it (shameless plug). equazcion→18:01, 11 Nov 2013 (UTC)
I just wanted to voice my concern as well. The new font is nearly unreadable for me in Firefox 25 on Windows 8 on a 1080p 24 inch LCD monitor. I've resorted to user CSS to change it back. — Preceding unsigned comment added by Kimsey0 (talk • contribs) 22:39, 18 November 2013 (UTC)[reply]
-- YES - WHAT HAPPENED TO THE FONT OF LANGUAGES ? ? ? - the font has changed to something that requires "font smoothing" -- I thought that the previous use of Arial was just fine, now the list is almost unreadable!! — Preceding unsigned comment added by 24.6.95.77 (talk) 06:02, 19 November 2013 (UTC)[reply]
Superfluous line-break in template
Hello.
Could someone help identify where there's an unnecessary line-break in {{Year in Norway}}. The line-break is transcluded, which makes the articles that use the template look a bit awkward.
I removed some line breaks between categories that seemed extraneous, which fixes the issue in tests, but the whitespace is still showing up when this template is used just after {{Use dmy dates}} (as seems to be the case with most of its uses). equazcion→11:59, 3 Nov 2013 (UTC)
This seems to be caused by the line break in the code before the wikitable begins. Since that wikitable code needs to be at the beginning of its own line, I can't find a way to get rid of the whitespace, aside from chopping off everything that comes before it (which does effectively remove the whitespace in these articles, FYI). This seems like it might be a common issue for templates so maybe someone knows of a solution I'm unaware of. equazcion→12:07, 3 Nov 2013 (UTC)
I've managed to fix it. That was a tricky one. A single line break before the table is fine, the problem was caused by having two consecutive line breaks before the table. The first line break is not in the template itself, but in the articles that use it (between the {{Use dmy dates}} and {{Year in Norway}} templates). The fix was to put something between those line breaks to stop them being consecutive, but that doesn't cause a visible gap itself. An empty <nowiki/> tag did the trick. – PartTimeGnome(talk | contribs)16:33, 3 November 2013 (UTC)[reply]
The real problem was the text before the beginning of the table, which introduces a whiteline before the {| class=. See the warning about whitelines on WP:NOINCLUDE. I moved the text to the beginning of the template, and removed the <includeonly> tag. The obvious minus being that the page Template:Year in Norway itself now looks ugly. Debresser (talk) 09:08, 5 November 2013 (UTC)[reply]
I think you've misunderstood the warning at WP:NOINCLUDE. It refers to white space before <noinclude>, after </noinclude>, after <includeonly> or before </includeonly>, warning that said white space will be included in the template's output. There wasn't any white space on either side of the <includeonly> tags you removed. I tested re-adding them without making any other change, and the template still displayed correctly in the article 1972 in Norway (I didn't save this test).
Also, your changes moved text inside the table, but before the first table row, which is neither valid nor logical. The error text is intended to be shown outside the infobox, so should not be inside the table. Your changed worked in articles thanks to HTML Tidy fixing the invalid markup by moving it outside the table. If you'd tried this at Special:ExpandTemplates (where HTML Tidy does not run), invalid HTML is generated due to a <span> tag between <table> and the first <tr>. W3C's validator reports "Start tag span seen in table. Cannot recover after last error. Any further errors will be ignored.". (There are two other errors reported by the validator, but those are down to HTML generated by MediaWiki itself, unrelated to the template.)
Since your changes generated invalid HTML and messed up the appearance of the template page itself, I have undone them. (I completed your move of the category to the doc page. The doc page is the right place for categories.)
PS: I see you made several attempts before you found something you liked. Please don't make test edits on a live template. You can see what effect your changes will have on another page without saving by using the "Preview page with this template" options beneath the edit box. – PartTimeGnome(talk | contribs)23:57, 5 November 2013 (UTC)[reply]
<includeonly>...</includeonly> is bad template engineering to begin with. You should just have a dummy default variable value in <noinclude>...</noinclude> tags in the #if conditional, like {{{1|<noinclude>dummy year</noinclude>}}}. Then you can include a default value for {{{1|}}} so that the template displays on its own page. VanIsaacWSVexcontribs00:37, 6 November 2013 (UTC)[reply]
I agree with you completely that one template per line is the standard, and looks good. I was surprised you didn't see the whiteline: it is the break between the end of the remark about the red warning text and the beginning of the table with {|. That is why I moved the warning inside the template. Even conceptually, I think the warning is not out of place inside the template proper, as you claim above. The biggest minus I see is that the template page became real ugly. Debresser (talk) 01:17, 6 November 2013 (UTC)[reply]
Er... I did see that. See my first post in this section: "A single line break before the table...". As I think you realised, a line break is required before a table unless it is the first thing in the template. This is not normally a problem since a single line break does not create a gap; it is only when combined with another line break from the transcluding page that a gap appears. Since it is clearly no-one's intent that these two line breaks should combine to make a gap, I added the <nowiki/> to stop them combining. (Perhaps in a more logical markup language, code from inside and outside a template would not be allowed to combine like this.)
I think there might be an argument for showing the error message inside the table, but it would have to be done properly so it actually displayed inside the table rather than being moved out again by HTML Tidy. Another idea would be to replace the table with the error message, since nothing else in the template makes sense if the parameter was omitted.
I know that the template becoming ugly was because the <includeonly> tags were removed. But that in its turn was done to remove the whiteline before the beginning of the template. You really don't need to speak with me as though I am making my first edit on intricate templates, and then perhaps you will also understand me better. Debresser (talk) 02:12, 8 November 2013 (UTC)[reply]
My apologies. I tend to be rather verbose, and I understand how I might seem like that. I'm not very good at adjusting my tone for the person I'm talking to. I do not consider you to be a beginner at template editing.
I guess you didn't see my other reply below? I already addressed your claim that removing the <includeonly> tags eliminated whitespace. (Sorry if I confused matters by making multiple replies in a single edit last night.) – PartTimeGnome(talk | contribs)21:39, 8 November 2013 (UTC)[reply]
@PartTimeGnome See below (now above—PTG) for my response. Just wanted to mention here that I did not err in my reference to WP:NOINCLUDE, and it is precisely that whiteline issue I was referring to. Just that often people don't recognize the whiteline. Debresser (talk) 01:24, 6 November 2013 (UTC)[reply]
(I have moved your response above, to be immediately after the post to which you were responding.) One of us is misunderstanding that WP:NOINCLUDE bit, we both understand it but don't understand each other, or we're both thoroughly confused . I did test that taking your latest version of {{Year in Norway}} and re-adding the <includeonly> tags did not cause any gaps to appear. For example, see how that appears in "1972 in Norway", one of the articles that displayed a gap before either of us edited the template. – PartTimeGnome(talk | contribs)23:23, 7 November 2013 (UTC)[reply]
The unnatural extra code can be avoided by moving the code generating the warning after the table. There will obviously not be a whiteline, while the warning will still be displayed in the same position. Debresser (talk) 01:53, 8 November 2013 (UTC)[reply]
I would strongly oppose the addition of stray code to template. First of all because another user will surely remove it sooner or later, not knowing why it is there. Secondly, because it is ugly. It is against all rules of coding to do such things. But the main reason is that there is a simpler solution to the problem: put all the invisible templates right after each other without any spaces between them. See User:John of Reading/Sandbox where I did so and the whitespaces are gone. We could add a warning about this to the documentation of certain templates like {{Use dmy dates}} and others, but even if there would be an extra space, this is not a big problem. Debresser (talk) 11:42, 4 November 2013 (UTC)[reply]
Alternatively, since templates like {{use dmy dates}} or {{use British English}} do nothing except categorise, put them with the other cats - at the bottom. Any spurious blank lines which may be generated will be much less obtrusive in such a position. There is precedent for this, since templates like {{coord|display=title}} which place their output somewhere other than the actual position of the template, are typically placed at the bottom as well. --Redrose64 (talk) 11:52, 4 November 2013 (UTC)[reply]
There are problems with that. {{multiple issues}} is for enclosing cleanup message boxes: requests to fix the article, to be removed when the fix has been done; when all have been done, and when there are none left to fix, {{multiple issues}} gets removed as well. By contrast, {{use dmy dates}} and similar are not requests to fix the article - they are permanent indicators of the article's writing style. If the article has no cleanup issues, and you add
Regarding someone possibly removing the code because it is not clear what it does, an <!-- editor comment --> will fix that. (I'd hope administrators would show more care editing a fully protected template, but maybe I hope for too much... )
On the point about ugliness, I agree, but I couldn't think of a better way to do it. There is much that is ugly about MediaWiki's markup language, so we often have to do ugly things to get the job done.
As for the "simpler" solution: good luck getting editors to use the templates all on one line. Many editors find placing each template on a separate line to be more intuitive, as evidenced by the many pages where this is the case. Generally, templates should be designed to be easy for editors to use, rather than expecting editors to adapt to their quirks. Templates should try to hide the complexities of wiki markup from the people that use them. One template per line is certainly easier to read. Keep the ugly stuff in a template so other editors don't need to worry about it.
One template per line is consistent with how categories are normally used (given the main purpose of the templates is categorisation): categories are typically one-per-line too. Also note that the current behaviour is inconsistent: where the template outputs a category, it is safe to use one per line. Where it outputs nothing, it will cause a gap. Code that looks fine in article space will show with gaps when copied to a user sandbox (because the categories are suppressed in userspace). – PartTimeGnome(talk | contribs)23:00, 5 November 2013 (UTC)[reply]
I agree that templates are best placed on consecutive lines. I still strongly oppose the addition of code for the purpose of avoiding whitelines. It is a counter-intuitive non-solution. If the problem, i.e. a whiteline, should arise in any given article, it should be taken care of on an ad hoc basis, just like we did with the Year in Norway template. Debresser (talk) 17:07, 9 November 2013 (UTC)[reply]
It is counter-intuitive, but I don't think an intuitive solution exists. I don't think "non-solution" is the right word, since it does solve the blank line issue. Why should this be solved over and over on a case-by-case basis when it can be solved once for all cases? The editors using the templates might not know how to fix the unwanted blank lines. If we fix it in the template, they would never be troubled by the problem in the first place.
I called it a "non-solution" because it is only a workaround. The real problem is the existence of whitelines, in the code of the other templates or simply in the articles if the templates are placed on different lines. The alternative proposal is the same as the first, with an added explanation. — Preceding unsigned comment added by Debresser (talk • contribs) 08:00, 11 November 2013 (UTC)[reply]
It is a workaround, but it's better than nothing. I didn't think you'd like my tweaks any better, but figured I'd give it a try anyway.
I think it's too late for the ideal solution of modifying the wiki mark-up language to be more sensible. The real problem is the inconsistent behaviour: when the template outputs a category or a <nowiki/>, it can be used one-per-line without a gap (even though there is no visible output). When the template outputs nothing, the line it is on is treated as blank so causes a gap. My workaround resolves this inconsistency. I think the behaviour many editors expect is that a line with a template should not leave a gap unless the template contains a gap. – PartTimeGnome(talk | contribs)22:57, 11 November 2013 (UTC)[reply]
Question: instead of outputting a non-intuitive <nowiki />, what would happen if it output a soft space? This should be possible using the HTML entity   --Redrose64 (talk) 00:31, 12 November 2013 (UTC)[reply]
I agree that this is better than a closing tag without an opening tag, which was, as Redrose64 put it mildly, non-intuitive. Adding an explanatory remark also helps. Even though I prefer to keep the problem in some cases, when it can be removed by good coding of templates like we did with Years in Norway, I do see the advantages of removing the problem, even with a workaround. Debresser (talk) 00:38, 14 November 2013 (UTC)[reply]
That's not what I said. The post to which you refer states "a non-intuitive <nowiki />" - <nowiki /> is not a closing tag (which would be </nowiki>); it is an empty-element tag, one that opens and immediately closes - it is an element that has no content. The syntactic difference is that a closing tag has the slash first; an empty-element tag has the slash last.
I meant that by using <nowiki /> it is not clear what is intended. The normal use of nowiki is in a construct like <nowiki>[[link]]</nowiki> so that Wiki markup is not processed but displayed as plain text, so when somebody sees <nowiki /> which is exactly equivalent to <nowiki></nowiki> they might think "what's the point of preventing wiki markup from being processed when there's none actually there?" But by using   it's (I hope) clearer that something is intended, even if it's not obvious why a normal keyboard space has not been used. --Redrose64 (talk) 00:59, 14 November 2013 (UTC)[reply]
Since yesterday there has been a problem with saving edits to User:RoslynSKP/Southern Palestine Offensive. When the edit is saved, instead of going back to the article, the Wikimedia foundation error notice appears. Then by backtracking and hitting reload the edit finally appears. Is there any way of fixing this problem? --Rskp (talk) 04:46, 4 November 2013 (UTC)[reply]
The page is too complicated to finish rendering before the connection times out. After a next visit, parts of the page have been cached, and rendering will be faster, so that's why it works on other pageviews. This is a common problem with overly complex pages. The advise is to simplify the page using fewer and less complex templates (which include references). —TheDJ (talk • contribs) 09:51, 4 November 2013 (UTC)[reply]
TheDJ. You mean a number of references is still an issue in this with Lua, and that it is more so when refs are used in a template? -DePiep (talk) 07:54, 5 November 2013 (UTC)[reply]
Thanks for that. Yes, it is very long, but it only has one template plus the refrences. I'm in the process of cutting it down. --Rskp (talk) 01:04, 5 November 2013 (UTC)[reply]
The article has been shortened down to 169,000 bytes but its still showing the error every save. The Information for "User:RoslynSKP/Southern Palestine Offensive" page shows 109 transcluded templates. Is there any way of getting rid of some of these? --Rskp (talk) 01:46, 10 November 2013 (UTC)[reply]
That page has 84 calls to {{convert}} which is a complex template. If you want to give it a try, you could do a "search and replace" to change each "convert|" to "convert/sandboxlua|" which would cause the converts to use Module:Convert that is still under development (groan). However, it should be fine for temporary use and chances are that {{convert}} will use the module in a couple of weeks (although I've been saying that for a while). Using the module reduces the CPU time usage from 8.369 to 4.308 seconds when previewing the current page. Johnuniq (talk) 04:02, 10 November 2013 (UTC)[reply]
A first step would be to try my suggestion, so I edited User:RoslynSKP/Southern Palestine Offensive to replace the convert templates, although I used {{convert/q}} ("quick") which was created recently for use on an article where {{convert}} was apparently causing the page to time out (the "/q" and "/sandboxlua" templates currently do the same thing). I checked the displayed text before and after the change, and there is only a single difference, namely where the new template has reported that one of the converts is invalid. To see that, search the page for "convert" (the displayed page, not the wikitext). You possibly want to change the output "g" (grams) to "impgal" (imperial gallons), or omit "|g" for the default which is imperial and US gallons. Johnuniq (talk) 05:50, 11 November 2013 (UTC)[reply]
I have seen this problem posted by someone else on one or another help page but now I can't find it. For the past few days (since around the end of October) I've been unable to do any meaningful editing of wikipedia pages on a computer I regularly use that runs IE8 (it's not mine and I don't have the option to change browser). If I scroll down, the text runs all over the place. If I enter anything in the search box, it doesn't show up. I can't use any drop-down menu. I daresay the answer to this is that IE8 is old and has stopped working (I've already changed to Chrome on my home PC), but I just wanted to check.Deb (talk) 19:02, 4 November 2013 (UTC)[reply]
I've got FF25 and it's been working fine for me since the upgrade a couple days ago. Have you both tried rebooting your PCs yet? equazcion→18:13, 5 Nov 2013 (UTC)
In your case, it is probably the IE8 browser. Is there a compatibility mode that you can turn on? Or anyway to get someone to upgrade the browser on that PC/laptop? Funandtrvl (talk) 18:32, 5 November 2013 (UTC)[reply]
Please delete the word "probably" in the above post - you should be supporting IE8. The above posts exemplify WP's arrogance towards IE - the original post is about IE, but immediately switches to concern about Firefox. Arjayay (talk) 19:27, 5 November 2013 (UTC)[reply]
I'm guessing Jarry1250 was referring more to IE8 being a few years old, rather than it merely being IE. equazcion→19:37, 5 Nov 2013 (UTC)
As the original poster states "a computer I regularly use that runs IE8 (it's not mine and I don't have the option to change browser)". Many editors are still using XP, so cannot use IE9 or IE10. The current versions of IE are not supported either - I use IE10 and haven't been able to use the cite templates on the Ref Toolbar for months, whilst the search and replace hasn't worked on IE for years. Wikipedia wonders why so many experienced editors are leaving - I'm not claiming any great contributions, 44K edits over 6 years, but if anything is likely to cause me to quit it is the combination of implementing half tested software (I'm being very generous with the half) and the arrogance towards users of IE Arjayay (talk) 20:03, 5 November 2013 (UTC)[reply]
If you just assume that people are aware problems exist, they will never get fixed, especially when it comes to IE problems, as few tech-y people use it. I just tested Reftoolbar in IE10 and it worked fine, so the problem may be specific to your browser configuration, or a conflict with a user script or gadget (try it logged-out).
There are at least 5 major non-mobile browsers, each of which has a slightly different implementation of HTML, JS, and CSS, and they also vary between versions of the same browser. According to [1] there are currently 13 different browser/version combinations with more than 1% usage share. Compare this to traditional application development where it's generally only necessary to get things to work on a handful of platforms and where the implementation of programming languages are generally held to common standards and you can see some of the challenges of web design.
Keep in mind that things like Reftoolbar, Popups, and wikEd are not WMF projects, they were and are fully developed by community volunteers, often only 1 or 2 people. Mr.Z-man20:26, 6 November 2013 (UTC)[reply]
I just logged in to the Wikipedia on a WinXP PC running IE 8 and could not replicate any of the above issues. Let's try to move away from that "what browser you should/should not use" and get to what exactly is happening on the original user's PC. Tarc (talk) 20:10, 5 November 2013 (UTC)[reply]
I don't think anyone's actually focusing on which browser to use, other than Arjayay, who is just assuming others are. I'm thinking Deb has some local PC issue. You could try following the cache clearing instructions. When I get wonky browser behavior and none of the usual methods seem to work, I use CCleaner to perform a nice scrubbing, which works a large percentage of the time. It's a free program, though you do need to install it generally -- not sure if you have the ability to do that. equazcion→20:36, 5 Nov 2013 (UTC)
I'll try and get a screen print tomorrow. I did do the cache clearing thing but it didn't make any difference. Unfortunately, of all the websites I access regularly, this problem is only occurring with wikipedia. Deb (talk) 20:40, 5 November 2013 (UTC)[reply]
There's more people with this problem. Seems to me like every fifth (or even every third) IE8 user is unable to use the site. I'm currently editing with Chrome tho. I can't use IE8 on XP or Windows 7. There's nothing all that odd about the way it looks, so I don't see how a screenshot is going to help you.
When loading any page, it loads a blank page. Sometimes the previous page stays on screen until I minimize and maximize again, which makes the page blank.
In compatibility mode, the page does seem to get loaded, but none of the links work; it's impossible to highlight text (it's sort of like a picture, instead of text) and scrolling completely messes up the page, creating vertical lines all over the window.
Can't provide a screenshot, but on looking at my watchlist, everything is fine for the first 2-3 entries, and then from that point everything else on the screen is long vertical streaks leading from characters. IE8 on WinXP. Only resolution is to close the window; more than once it's frozen the browser entirely. Risker (talk) 19:00, 6 November 2013 (UTC)[reply]
When I look at a page, it appears normal until I try to scroll down - then it goes berserk, much as you describe. Deb (talk) 19:37, 6 November 2013 (UTC)[reply]
Posting via IE8 here now. I've been trying to reproduce these errors but so far no dice. Deb, if you could, can you list the gadgets you have enabled -- or just try disabling all of them, bypass your chache, and see if stuff clears up? equazcion→20:04, 6 Nov 2013 (UTC)
I guess that answers that, then :) Gadgets are in your Preferences, they're extra tools and tweaks you can enable. If you don't know what they are then it's safe to assume you have the defaults only. equazcion→20:49, 6 Nov 2013 (UTC)
Gadgets are the settings listed at Preferences → Gadgets. A big problem with that list - not just the fact that there are so many (over 50) - is that several of them are opt-out, so will have been enabled without you being aware of the fact. So if you make a list of enabled gadgets, you may actually be listing several that the majority of people also have (probably without realising it). The Gadgets enabled by default (i.e. opt-out gadgets) are:
(D)Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)
Deb explains that in her original post, Konveyor Belt. equazcion→20:49, 6 Nov 2013 (UTC)
IE 8 is the default browser on the corporate machine I use at work. (I work as a contractor at a very well-known technology company. I can't say which, but their products are doubtlessly in the computers everyone here is using. Unless you are using exotic hardware.) I could use another browser with the work computer & take my chances with with IT, but I don't use most of the gadgets or fancy add-ons available for Wikipedia, & another browser would fix certain problems while introducing another set. No browser software is completely free of gotchas of some shape or flavor. -- llywrch (talk) 17:59, 7 November 2013 (UTC)[reply]
i do not think the problem described have anything to do with IE. to the original poster: please try to see if same problems exist when you are logged out. once you see they do not happen in this case, you probably want to go over Special:MyPage/common.js and Special:MyPage/vector.js (or monobook, if this is the skin you use), and eliminate stuff, until the behavior disappear. you can then bring stuff back in until the behavior returns - at this point you found the culprit. clearly wikipedia is compatible with IE8, with some limitations (i.e., some things do not work with ie8, such as displaying references in columns, some features related to "universal language", visual editor and such), but the basic functionality works with IE8 and even with IE7 (probably once you go to 6 and below, things stop working, and the same is probably true for ancient versions of netscape.... peace - קיפודנחש (aka kipod) (talk) 21:10, 6 November 2013 (UTC)[reply]
I already checked Deb's .js files, they're empty. equazcion→21:18, 6 Nov 2013 (UTC)
Perhaps it's a geo located central or geonotice or something that is causing the breakage... That would explain why only some people are seeing this. —TheDJ (talk • contribs) 09:33, 7 November 2013 (UTC)[reply]
Hmm maybe the new big ugly donation thing is doing it? equazcion→12:57, 7 Nov 2013 (UTC)
I'm trying to get the donation thing to come up again for me but I'm not sure how. I think I hid it when it initially came up. I logged out and cleared cache and cookies, but it still won't show up. Ironic, that. equazcion→13:05, 7 Nov 2013 (UTC)
deb, risker, stfg, could you post your general locations so we can check for geo notices that might be causing this? equazcion→13:28, 7 Nov 2013 (UTC)
(edit conflict) Even though all the current geonotices appear to be simple lines of text with nothing more complex than wikilinks, it is interesting that you're both in the UK. My next step would generally be to see what happens when these users disable javascript altogether. It may be a teensy bit involved for those not accustomed to technical settings but this shows how to do it, if any of the sufferers feel like giving it a try. equazcion→17:42, 7 Nov 2013 (UTC)
I see all three geonotices just fine. Disabling javascript is interesting. Diffs accessed through https work fine when it's disabled and the problem reappears when it's re-enabled. OTOH, my problem with the misplaced tabs (item 3 in the #Diff and other problems (probably IE8) section) reappears when javascript is disabled, and goes away again on re-enabling. --Stfg (talk) 19:32, 7 November 2013 (UTC)[reply]
Southern Ontario, Canada. I did try to take screenshots when the "striping" occurred, but the screenshots show a blank page, and not what I see on the screen. However, after taking the screenshot and trying to download it, when I returned to the Wikipedia screen, it was completely blank, and I had to close the browser to get back on. Risker (talk) 17:41, 7 November 2013 (UTC)[reply]
Southern Ontario shouldn't be getting any current geonotices. The nearest active one is CHFNov13: "Wikipedians are invited to the GLAM Café at the Chemical Heritage Foundation to meet, talk, and edit. We provide the space, the coffee, and the snacks: you provide ideas and enthusiasm! On the second Tuesday of each month, starting November 12, 2013. " --Redrose64 (talk) 18:52, 7 November 2013 (UTC)[reply]
I did succeed in taking a screenshot although it doesn't look quite like it did on screen. But no one seems interested in looking at it. Actually, I'm not so concerned about my own position because I can still edit at home - what worries me is that there could be a lot of potential users out there who wouldn't dream of trying to edit but can't now access wikipedia to look at articles.Deb (talk) 18:07, 7 November 2013 (UTC)[reply]
You could upload it via Special:Upload. Click the "Browse" button to locate the screenshot file, enter something like "Screenshot of IE8 glitch" for the "Destination filename", and enter anything for the description -- I can take care of that afterwards. I'd be interested in seeing it just in case it could tell us something. equazcion→18:13, 7 Nov 2013 (UTC)
Thanks for doing that Deb :) I placed it at the top of the this discussion for future reference. It looks like the display isn't updating properly as you scroll down, and is rather just cascading shadows of the same screen. Is this similar to what's happening to Stfg and Risker? equazcion→21:10, 7 Nov 2013 (UTC)
Stfg, you seem to have a few things in your common.js and vector.js files. I would try removing them and bypassing your cache to see if any of those are causing the diff problem. equazcion→21:23, 7 Nov 2013 (UTC)
I've sometimes seen the same sort of thing on IE8. Have you tried toggling the browser's "compatibility mode" button (the torn-page icon at the right end of the address bar, beside the reload button)? LeadSongDogcome howl!22:25, 7 November 2013 (UTC)[reply]
I've tried completely emptying my common.js and vector.js (and didn't forget to bypass the cache :), but even with them completely empty, the situation is the same. In compatibility mode, it's slightly different: the top screenful displays, but scrolling and page movement keys have no effect at all (in normal mode, I get the same as shown in deb's screenshot). Has anyone any thoughts about the fact that this only happens with htpps diffs, while normal http diffs behave fine? (And is this the case for deb too? The screenshot doesn't show the title bar.)
I've had the problem ever since trying to play an OGG file on 2 November 2013. Got a "Do you want to run this application" security warning. Does anyone know what was installed & how to get rid of it. When I go use IE 8 on a different user name on the same PC, Wikipedia works fine. --Chaswmsday (talk) 10:01, 8 November 2013 (UTC)[reply]
Something has been fixed! I haven't been able to test it on XP yet, but I can now use IE8 on Windows 7 again. GMRE (talk) 13:08, 9 November 2013 (UTC) No change on XP. :( GMRE (talk) 23:55, 9 November 2013 (UTC)[reply]
Ugh. Still doesn't work for me. But I created a user, then answered "yes" to the same prompt from the OGG file with no problem. Has anyone had any luck eliminating IE problems with what appears to be the preferred fix: turning the IE "Window feature" OFF, then back ON? --Chaswmsday (talk) 11:53, 11 November 2013 (UTC)[reply]
What is this "Window feature", and how do you turn it off and on again? As far as I can see, nothing has been fixed. Wikipedia pages accessed through https still have the scrolling problem. I haven't accessed any OGG files for ages, and I don't believe that's related. --Stfg (talk) 16:51, 11 November 2013 (UTC)[reply]
I'm running IE 8 under Windows 7. Since IE 8 isn't directly able to be uninstalled, one recommended fix for IE problems is to go into Control Panel: Programs and Features, then choose "Turn Windows features on or off". Inside that, you're supposed to de-select IE 8. Those giving this advice recommend having some alternate browser in place just in case you can't get IE back. You next reboot, then go back into "Windows features" and RE-select IE 8. This supposedly causes your PC to find a fresh install... I'm wondering if this process works in a general sense, not just limited to the particular Wikipedia problem(s) at issue.
RE the points made below, I've disabled Javascript with no better outcome. I also just now tried to scroll a very short Wikipedia article with the same poor result.
The reason I've been suspicious about the OGG file is that the failures began immediately after my attempt to play the OGG. The executable/Wiki markup or whatever was generated didn't work right, as the OGG never played, so maybe something else ran or some setting was inadvertently FUBARed. (That's what I don't like about Microsoft's supposed "Recovery" process. Errors I've encountered in the past seem to have more to do with some mis-set parameter under User/AppData, and thus not corrected by Recovery, not with the programs themselves.) And my own UserName (the PC's administrator) is the only one that messed up. --Chaswmsday (talk) 00:35, 12 November 2013 (UTC)[reply]
Today I installed a copy of IE8 on XP in my VirtualBox in hopes of finding what might be causing this. Unfortunately i was unable to reproduce. I don't know how to help any further, if a problem is this localized to certain users it becomes very hard to figure out what the problem might be. If i look at the screenshot that Deb is providing though, then that issue very much looks like a screen buffer problem. Do you see this problem more often on very large pages compared to smaller pages ? There can be many causes for such a problem. A bug in the application itself, mouse (scroll) drivers and graphics drivers are all often to blame. If i google a bit I also see some indications of that a bug like this was introduced in XP Service Pack 3 for some people (and never fixed). —TheDJ (talk • contribs) 21:42, 11 November 2013 (UTC)[reply]
I did the same thing, vmware, and was unable to reproduce -- although I did get some slight buffer-type glitches. On initial setup of IE8 where it asks you about default search engines and whatnot, when the window disappeared and I was at Wikipedia, a big blank white box was left in its place, with Wikipedia around it. It cleared up instantly on refresh though. equazcion→21:49, 11 Nov 2013 (UTC)
PS. Stfg reported one major issue cleared up by disabling Javascript. Deb didn't try that but her issue sounds about the same, and I have feeling that would do it for her. Both users report this began somewhat recently. I'm wondering if there's maybe simply more javascript around right now and is making the browser work too hard? Or something. equazcion→21:53, 11 Nov 2013 (UTC)
That does indeed seem possible. I'm on XP SP3, so what TheDJ mentioned above rings a bell. I don't think this particular problem depends on page size, but IE8 is very slow indeed on large pages in any case (WP:FAC takes forever). I agree with TheDJ that it's tough when it affects so few users, and you can't be expected to spend the rest of your lives on this. Perhaps the time has come for me to bite the bullet and use another browser for Wikipedia access. Thank you both very much, TheDJ and Equazcion, for the time and effort you've put into tackling this. Regards, --Stfg (talk) 09:24, 12 November 2013 (UTC)[reply]
I mentioned pagesize, because it might relate to required memory usage (both to make the page [CPU] and to update it's drawing [GPU]). And higher memory usage on either might be a trigger for this specific problem to become visible to the user. Just a thought. —TheDJ (talk • contribs) 09:58, 12 November 2013 (UTC)[reply]
Woohoo! 'Bout time something did :) I'm not sure what at Wikipedia would've been triggering active scripting, but who cares, as long as it worked :) equazcion→08:44, 14 Nov 2013 (UTC)
Well found, Deb. There's a horrible price to pay, though. Turning off active scripting disables navigation popups, Ucucha's duplinks tool, Dr pda's prosesize tool, ... I can't work without those. Actually, why is there so much https around anyway? For example, inter-language links from articles are ordinary http links, but when you click on one, the target page loads as https. What ever for? --Stfg (talk) 09:42, 14 November 2013 (UTC)[reply]
I didn't realize "Active Scripting" is how IE8 refers to Javascript. I posted the instructions for disabling Javascript more for trying to find the problem, rather than as a fix -- Stfg is correct that there may be some features you've relied on at Wikipedia that could be gone with Javascript disabled. But obviously if it's a choice between this and not being able to use Wikipedia at all (from work), then it might be a good solution until someone figures out something better... equazcion→10:20, 14 Nov 2013 (UTC)
If you have turned off "Always use a secure connection while logged in" at Preferences, that only affects that particular Wiki, and so the interlanguage links going out from it become http:. Once you click one of them, you're then served pages according to your prefs (and site settings) on the Wikipedia that you are now viewing. If you want to use http: on all of the Wikipedia languages and Wikimedia projects, you need to switch that off individually on all the languages/projects that you are likely to visit. Some do not have this setting and are permanently https: --Redrose64 (talk) 16:37, 14 November 2013 (UTC)[reply]
Yes, it's true, I'm going to have to keep switching it on and off in order to use other websites properly (gmail for example), but it's better than not being able to use wikipedia at all! Deb (talk) 11:12, 14 November 2013 (UTC)[reply]
So I saw somewhere where someone tried to notify me with a lowercase u. In other words, they used {{u|Biosthmors}} instead of {{U|Biosthmors}} but I didn't get a notification, I don't think. Is this a bug? Is it tracked? Can someone test it and see if it notifies me or not? Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 12:25, 7 November 2013 (UTC)[reply]
Screenshot of the new Beta Features preferences page.Media Viewer shows images in large and full size.
We're pleased to announce the first release of Beta Features, a new program that lets you try out new features before they are released widely. Beta Features is intended as a digital laboratory where community members can preview upcoming software and give feedback to help improve them. This special preference page lets designers and engineers experiment with new features on a broad scale, but in a way that's not disruptive.
One of the first beta features we will be testing together is Media Viewer, which aims to improve your viewing experience by displaying images in larger size and with less clutter than the current file info page. This first version 0.1 is still in early stages of development, but we invite community feedback right away on this discussion page, so we can improve it together in coming months. For a sneak peek at the next version 0.2 of the Media Viewer, check out these first mockups.
Beta Features and Media Viewer are now ready for early testing by logged-in users on MediaWiki.org, on Wikimedia Commons and on Meta.Wikimedia.org. Based on test results, we aim to release these beta features on all wikis worldwide on 21 November, 2013.
Here are some of the other beta features in our pipeline:
VisualEditor Formulæ — edit algebra or equations on your pages (only on MediaWiki.org)
Typography Refresh — make text more readable (scheduled for release Thursday, 14 November)
Would you like to try out Beta Features and Media Viewer now? After you log in on MediaWiki.org, Commons or Meta, a small 'Beta' link will appear next to your 'Preferences'. Click on it to see features you can test, check the ones you want, then click 'Save'. Learn more on the Beta Features page.
Beta Features and Media Viewer were developed by the Wikimedia Foundation's Multimedia team, in collaboration with the Design, Mobile and VisualEditor teams. Along with other developers, we will be adding new features to this experimental program every few weeks. We are very grateful to all the community members who advised these projects — and look forward to many more productive collaborations in the future. :)
With all due respect (and not being sarky there...), if I saw that under a G11 tag, I'd delete it on sight... I'll look in, but you might not really be including me in the invite (bearing in mind my frequent underpoliteness at times on this page. Peridon (talk) 18:56, 8 November 2013 (UTC)[reply]
To clarify in case the above isn't clear, VisualEditor like other parts of the Wikimedia software will be using Beta Features to introduce new features, for testing and feedback before they are made available to everyone. For the English Wikipedia, and other wikis where VisualEditor is available but not yet by default, VisualEditor itself will be a "Beta Feature", as well as the new features coming along (initially, formula editing and maybe in-line language editing). Jdforrester (WMF) (talk) 00:44, 9 November 2013 (UTC)[reply]
Thanks for your comment, Peridon. We welcome clear feedback on how to improve these Beta Features :) We are passing on specific recommendations to our development team, so they can evaluate them for future releases. For now, we are fixing the most urgent bugs, and will be rolling out more tweaks and new features in coming weeks, with our next release due on 21 November, and more updates in December. If you have any more suggestions or questions, you are welcome to post them here, and/or on this discussion page. I am out of office until 19 November, but you can contact our community liaison Keegan (WMF) or lead developer Mark Homquist with any urgent requests. Thanks again for helping us improve this tool! Fabrice Florin (WMF) (talk) 03:04, 12 November 2013 (UTC)[reply]
Wikimedia error, site very slow, looks like when Internet first developed
I just got a Wikimedia error when I tried to go to any page on the site. I forgot to make a note of the number. Then I got a Gateway Time-Out error. Eventually, I got to the page I wanted. I was getting from one page to another just fine for the most part, then the site was very slow. On both the Technical Village Pump and on the page where I am now, fonts and blue links look like they did when the Internet was new, before anyone tried making pages appear more interesting.— Vchimpanzee· talk·contributions·18:35, 8 November 2013 (UTC)[reply]
Every Wikipedia page is built from many more than one computer file: besides the file which shows the layout and text of the actual page, the other files mainly comprise images, style sheets and scripts. When certain servers are slow, the files that are requested from them may fail to be sent back before your browser gives up. If one of those files is a CSS file (a style sheet that describes the normal page styling for Wikipedia), your browser cannot format the page using that styling and so falls back on its defaults. These look like 20th century internet because style sheets were not generally used until HTML 4 was released in late 1997. --Redrose64 (talk) 20:33, 8 November 2013 (UTC)[reply]
I have been getting sporadic "Wikimedia Foundation Error"s for a few days. I thought it meant my edit had to be repeated -- but so far that is not the case. Here is a message I got a few minutes ago:
Wikimedia Foundation Error
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes... XOttawahitech (talk) 15:49, 13 November 2013 (UTC)[reply]
Yes, I've been getting those too, at odd intervals, on pages of various sizes. The first thing to do is to check your contributions - try to do this in another browser tab or window, if your browser provides such features; this saves disturbing the tab where the error occurred. If the edit that you attempted appears at the top of your contribs, all well and good; if it doesn't, return to the tab with the error, back out and try to save again. A second attempt is usually sufficient; if that doesn't work, or if it happens on more than one smallish page, it's a sign that the servers are busy. Go have some coffeee and try later. --Redrose64 (talk) 17:24, 13 November 2013 (UTC)[reply]
@Redrose64:I have been getting those with increasing intensity, or at least so it seems. Coupled with the general slowness (?) of the site, it is definitely reducing my ability to contribute. Just wondering if this is effecting others' contributions as well. Are there pertinent statistics anywhere? Thanks in advance, XOttawahitech (talk) 15:37, 15 November 2013 (UTC)[reply]
Image in infobox rendering incorrectly after it has been updated in commons
I am working on the page Hat Works. On 8th November, the image File:Hat Works.jpg in the infobox showed a lot of tarmac and little of the supject. I went to Commons, downloaded, cropped and replaced the image. Simply it went from a portrait to a landscape. Back to Hatworks, and the new image was there but stretched to occupy original portrait format in the infobox. Ouch. Re loaded the page still the same. Loaded the page on a different computer- the stretch image was there too.
Edit the page to see if there was some fixed parameter in the infobox. In the edit mode- the image was rectified. I did a dummy edit and saved. The page came up correctly this time. Tested the same on the other computer and it was fixed there too. Not a serious problem- I am just reporting it to assist.
For what it is worth the browser is 24.0 Firefox for Linux Mint on the main machine and on the second 24.0 Firefox for Ubunt canonical. Skin monobook. -- Clem Rutter (talk)10:41, 9 November 2013 (UTC)b[reply]
New twist. I clicked on an open tab on the browser to get en:wp Hat Works again. (Trying to get the Google Map of the area- through a known geotagged image). Page looked normal- clicked on said image to get to commons- the 'old image opened" but squashed to fit the new format. (that was from en:wp). I did a browser page reload- and it rectified 'new image- new format'. Clicked icon for Commons- and again I got the correct b'new image- new format'. -- Clem Rutter (talk)00:27, 12 November 2013 (UTC)[reply]
Date dependent template?
Is it possible to have date dependent templates? For example, I just added a new announcement to Wikipedia:WikiProject Basketball/Women's basketball. I added the new item template to mark it, but would like that to go away after, say two weeks. Is there a way to display one things before a specified day and other thing (in this case blank) after that date? — Preceding unsigned comment added by Sphilbrick (talk • contribs) 14:42, 10 November 2013 (UTC)[reply]
Template:Expiry can do this. However, the announcement might still show after the expiry date you set, because MediaWiki caches page content. The announcement would disappear next time someone did something to invalidate the cache, such as editing the page, purging the page, or editing a template used on the page. (There might be a delay for the latter case; it can take a while for template changes to work through the job queue.) – PartTimeGnome(talk | contribs)21:58, 10 November 2013 (UTC)[reply]
Is there a gadget or script that would notify / stop the user from adding a reference if it is already linked to on that page. Its easy to spot if the article only has a few refs, but if there is say a 100 its not so easy.BletheringScot19:19, 11 November 2013 (UTC)[reply]
Something as simple as manually searching for the URL in the whole article source should work. Maybe that's lame, but at least that's what I usually do. :) -- Dsimic (talk) 19:45, 11 November 2013 (UTC)[reply]
Again though not so easy on a larger article, the instances I'm looking at are articles with a higher than average ref count. Just thought a warning of some kind through a script or gadget would be extremely useful to stop unnecessary duplication of refs and although negligible a wee bit of server space.BletheringScot19:54, 12 November 2013 (UTC)[reply]
Yeah looked at AWB before, not that i knew it had that option but don't think it runs on a mac, which all of my tech fleet is. Wonder what the script is, might take a look through and see if i can find it.BletheringScot20:11, 12 November 2013 (UTC)[reply]
I'm getting slowness and intermittent failure to load CSS and javascript features. Reporting from NYC now. Back to you. equazcion→19:50, 11 Nov 2013 (UTC)
From the wikitech IRC and twitter feed: "Switching 588 wikis to 1.23wmf3 in one go seems to have upset the bits app server pool". So it is known and being worked on. The deploy process has changed slightly this time round and it seems a performance bottleneck has been reached because of this. As always, recovering might require bypassing your browser cache. —TheDJ (talk • contribs) 19:55, 11 November 2013 (UTC)[reply]
The MiszaBot settings at the BLP noticeboard seem OK. I checked the FAQ and verified there are no blacklisted links, etc. But it seems to be stuck, a lot of threads are way overdue for archiving and the page is getting big. Not being very acquainted with how the bot works, I thought I'd see if there's anyone more experienced here that can help. §FreeRangeFrogcroak22:57, 11 November 2013 (UTC)[reply]
@Dsimic: I think you saw SineBot, which is not an archiving bot. FRF, right now there is a bit of a kerfuffle about archiving -- MiszaBot hasn't been running for a month and, while a replacement has apparently been coded, it's still not approved. Legoktm was running a version of the archival script that MiszaBot used for a while, but it appears that he's disabled it -- Lego, could you chime in here? Theopolisme(talk)23:10, 11 November 2013 (UTC)[reply]
I'm not running the bot anymore, and we're just waiting for Sigma's to be done, he's doing some stress testing of the bot in weird situations right now IIRC. Legoktm (talk) 23:12, 11 November 2013 (UTC)[reply]
I've been adding ClueBot configs to a bunch of noticeboards as it's showing signs of life lately. It looks like it's not running quite as often as it used to, but it's been keeping the Village Pumps pretty well maintained. I just added a config at BLPN. equazcion→01:30, 12 Nov 2013 (UTC)
@Theopolisme: On second thought, please have a look at this edit. It was performed by ClueBot III on 11 November 2013, and it removed (archived?) 23 discussions (around 67 KB of text) from this talk page, according to the diff. Hm, thoughts? It seems to be some kind of an archiving process. -- Dsimic (talk) 15:21, 12 November 2013 (UTC)[reply]
I added a ClueBot configuration to BLPN, so the same thing should happen there in the next day or so. Yes, that was an automatic archiving edit. ClueBot is the only archiving bot that's currently up and running, though it's running a little slower than archivers normally run. It's been doing a fairly good job at this page and the other Village Pumps though. equazcion→15:27, 12 Nov 2013 (UTC)
I clicked on the java update icon in the bottom right corner of the computer screen to try and update java but it said the lastest version of java was already installed on my computer, and yet video files in Wikipedia in internet explorer 9 will still refuse to play. Perhaps it might be better for Wikipedia to evolve to have video files be youtube videos displayed directly on wikipedia with a link at the bottom right corner of the video screen for watching on youtube. If a youtube video that was used as a video file on wikipedia gets deleted, the entire link to that video file in the article should get deleted by itself without any human action causing its deletion, not have it so that once you click play on the video, the video screen shows a sad face with text saying that it was deleted. Blackbombchu (talk) 05:39, 12 November 2013 (UTC)[reply]
YouTube videos are an issue; They often do not meet our licensing requirements (I am aware of severalMany videos on YouTube that are copyvios), therefore it would not be appropriate. What does this page say is your Java version, and what operating system do you use? --Mdann52talk to me!13:36, 12 November 2013 (UTC)[reply]
Second class citizens
If I edit as an IP address and receive messages, I get a detailed notification: "you have new messages from 5 users (last changes)". If I am logged in, I simply get "you have new messages". Can we please stop treating registered users as second class citizens and provide with them with the same information that IP addresses receive? — RHaworth (talk·contribs) 10:47, 12 November 2013 (UTC)[reply]
Actually, if you click on the red "1" beside the message (added by echo, you can see more information than you got from the OBOD. The only thing it doesn't give you is the link to the diff, but it tells you who left the message and where, so you have just as much information as before. --Mdann52talk to me!11:07, 12 November 2013 (UTC)[reply]
I didn't really understand this answer. I haven't tested whether RHaworth's claim is correct, but if it's true that IPs get to see their number of new messages right away and registered users don't, then I think that should be corrected. It's time we registered users got to feel just as important is anonymous ones. equazcion→11:18, 12 Nov 2013 (UTC)
A screenshot of the Notification view This is what I see; I can't see why registered users are feeling like "Second class citizens" when they can see who left them messages even after they click through on the OBOD, and have the rest of the functions registered users get with Echo.... --Mdann52talk to me!13:30, 12 November 2013 (UTC)[reply]
Not sure why you put "the only thing it doesn't give you is the link to the diff", since there is a "View changes" link against all of the notifications show in your screenshot. --Redrose64 (talk) 15:03, 12 November 2013 (UTC)[reply]
I got treated as a second class citizen too. Back in those days when I used to edit wikipedia articles without an account, I used to be able to see a list of all edits I ever made on a talk page, but now I can't see a list of all signed edits to a talk page I made when I was signed in. That problem should get fixed. I should also get notified in the notification box when ever anybody makes an edit to a section that contains the link Blackbombchu. Blackbombchu (talk) 17:12, 12 November 2013 (UTC)[reply]
People who picked a username that starts with a small letter are also treated like second class citizens because I picked the username blackbombchu but was instead given the username Blackbombchu. Blackbombchu (talk) 17:18, 12 November 2013 (UTC)[reply]
The new talk notifications are a real problem for me: I don't get them. When someone edits my talk page I get the red "1" at the top of the page (which I can miss), but nothing else. The orange bar seen by many registered editors relies on JavaScript, but since I browse without JavaScript I don't see it. The classic "Orange Bar Of Doom" (OBOD) for IP address users, on the other hand, works in any browser (it does not use JavaScript). I very much understand the "second class citizen" feeling – it seems ridiculous that something that works for me logged out doesn't work when logged in.
For some of the background behind this, see Wikipedia:Notifications/New message indicator#Background. Short form: The WMF deployed Echo as a new-and-improved notification system for registered users (IP address users were unaffected). As part of this, they removed the orange bar notification without giving a replacement. Understandably, this caused a bit of a stink. Despite pressure from the community, the WMF refused to restore this feature, but eventually agreed to develop a new orange bar for registered users, which is what we have today. Since registered users were not getting talk notifications, there was pressure to develop the replacement quickly. I believe one of the reasons it was written using JavaScript was to get it done quickly.
Ideally, I'd like to see the new orange bar implemented without JavaScript (I'm not sure if that's technically difficult). My next preference would be to have the option to switch back to the classic OBOD, so I could at least get talk notifications! (But that won't happen due to WMF politics.) – PartTimeGnome(talk | contribs)22:51, 12 November 2013 (UTC)[reply]
Now now, let's not get sarcastic. This is the technical page, our last refuge from the drama of all other places. I would post a bug myself, but I don't feel familiar enough with the situation. PartTimeGnome, you seem to have a pretty firm handle on it, so you may want to do the honors. Seems like our best bet for getting it fixed. No big deal if you don't want to though. equazcion→23:27, 12 Nov 2013 (UTC)
I think the original complaint in this thread is referring to bugzilla:56475 - If so, it's #10 in the list of bugs at Wikipedia talk:Notifications#Echo - selected open bugs and feature requests. There is one staff dev still working through critical Echo bugs, but I'm not sure if this one is on his list of priorities (I shall prod the people who demand his time), or perhaps another dev will come to the rescue. Fwiw, there are a lot of potential improvements that could be made to Echo (hence I tried to collate that list), some big and some small. Letting each other know which ones we want (so that the devs can prioritize), and what exact specifications they should have (so that the devs don't spend time implementing something that then gets rejected by the previously silent part of the community), is the fastest route to consensus and action. –Quiddity (talk) 23:44, 12 November 2013 (UTC)[reply]
Starting new section at WP:NFCR no longer leaves a 'new section' edit summary
When I start a new section at WP:NFCR, there is no longer an edit summary saying new section. The wikilink in the section heading in the edit summary is also new. The wikilink might even be useful, but why is the default summary omitted now? Also, wikilinks in the section header are no longer visible as blue links in preview, but instead display as This is a header with a [[wikilink]]. I would prefer if the preview displayed the wikilink as it would appear as if the edit were saved. -- ToshioYamaguchi12:20, 12 November 2013 (UTC)[reply]
I cannot reproduce what you describe. How do you start the new section? Do you use editing tools? Does the same happen when you are logged out? PrimeHunter (talk) 12:32, 12 November 2013 (UTC)[reply]
It's because of that script of mine that you installed, Toshio. You need to enter a summary yourself now :) My bad. I'll work on getting the default back in there for blank summaries. equazcion→12:41, 12 Nov 2013 (UTC)
I think I did it, and addressed the issue of header links not showing up in previews. Let me know if you see any issues, but since this is confined to a user script it should probably go on my talk page or to the script doc talk page. equazcion→13:25, 12 Nov 2013 (UTC)
Dark blue over the word "wikicode" to the point where I can hardly see it
Ah, those links should probably be buttons... However automatic loading of "jQuery UI" was disabled in the last MediaWiki Update, therefore the necessary CSS is missing. --Patrick87 (talk) 13:55, 12 November 2013 (UTC)[reply]
This affects all Buttons that were styled using "jQuery UI". The best workaround is probably to add
/** * Load jquery.ui.button if used in content * for backward-compatibilty * Should potentially be removed/replaced with mediawiki.ui, when that is loaded on each page */mw.hook('wikipage.content').add(function($content){if($content.find('.ui-button').length){mw.loader.load('jquery.ui.button');}});
I don't know whether another color was intended but it's easily readable for me and works as it should. The dark blue is the page you are on so it doesn't have a link like the others. I constructed a similar example below. We are on Wikipedia:Village pump (technical) so Technical is dark blue and not linked. PrimeHunter (talk) 14:10, 12 November 2013 (UTC)[reply]
Now I see readable buttons sometimes and other times see no buttons and unreadable dark blue for the page I'm on. Maybe it depends on caching. PrimeHunter (talk) 14:18, 12 November 2013 (UTC)[reply]
Styles and javascript are acting totally wonky right now. I mentioned this in a section above. It's been happening since earlier today. Sometimes they fail to load and other times old versions are being used. Someone said it's likely being caused by some mass MediaWiki version migration across dozens or hundreds of wikis. I'd wait til later and try testing this again. equazcion→14:31, 12 Nov 2013 (UTC)
The dark blue is because {{Help pages header}} (which creates the About Welcome Help menu (etc.) links at the top of H:Cheatsheet) uses {{clickable button 2}}, and that is designed to "grey out" a link if it points back to the page that you're currently viewing. It does that by setting style="background-color:#008". It is however a violation of WCAG if the text colour is not readable against the background, even if a "greyed out" effect is intended. But I don't see why the normal Wikipedia method was not used - if I put a link pointing right back to this page, the background is unchanged but the foreground becomes boldface black, and most people are used to that. --Redrose64 (talk) 16:08, 12 November 2013 (UTC)[reply]
As for {{clickable button 2}}, I think this should not inject an inline style that looks wrong without the rest of the jQuery button styling. It makes the links look ugly and unreadable when JavaScript is disabled (or fails to run for any reason). Since the jQuery styling is added by JavaScript, the dark blue background should be added the same way. (Or alternatively, just get rid of it. I don't know what the buttons should look like, so I'm not sure if they look better with or without it.) – PartTimeGnome(talk | contribs)23:26, 12 November 2013 (UTC)[reply]
Odd notification
Is there a reason this edit should have triggered a notification for me that "Mr.Z-man mentioned you on..."? I'm not listed in that diff at all. Or am i misunderstanding how notifications work? It's not a thing i pay much attention to, but if i'm going to start getting entirely irrelevant notifications i'll have to develop a purposeful blind spot to that little number. Cheers, LindsayHello15:20, 12 November 2013 (UTC)[reply]
On the page Utrecht an anonymous IP inserted remarks that obviously shouldn't be there, notably about people called Lewys, Damian and Sara, but when I clicked "edit" to remove these remarks, the remarks didn't show. Which in my view was very odd. The IP that added the remarks, was blocked already. ClueBot NG appears to have tried to revert it, but that wasn't enough. Strangely enough. Kudpung กุดผึ้ง resolved this for now but suggested I'd post a message here, as he suspected the page might be hacked. What's happening here? Who can help us? Mark in wiki (talk) 09:27, 13 November 2013 (UTC)[reply]
The vandalism could not be removed by normal editing. I removed it by restoring to the last unvandalised version. Very odd. But the page history appears to be working correctly now. Kudpung กุดผึ้ง (talk) 09:32, 13 November 2013 (UTC)[reply]
I doubt it was anything more than a caching issue. You were seeing a more recent version during editing than you were during viewing. There was server stuff going on yesterday and the database got locked a few times, might have something to do with it. I doubt it was a hack, but I could be wrong. equazcion→09:35, 13 Nov 2013 (UTC)
It doesn't seem to be broken for me, at least not technically (USA). equazcion→10:11, 13 Nov 2013 (UTC)
Seems ok now but for about half an hour I couldn't retrieve anything, or occasionally got a page that looked like it was missing the style sheet. Most frustrating. Nurg (talk) 10:28, 13 November 2013 (UTC)[reply]
I'm thinking about puppies. Though that may be getting away from the point. equazcion→13:00, 13 Nov 2013 (UTC)
In the US and this seems to have been happening rather consistently for me in the Special and File namespaces at least (and the edit page as well) for the day. - Purplewowies (talk) 20:08, 14 November 2013 (UTC)[reply]
Been happening to me in the US for the last 2-3 hours, off and on, back and forth. First noticed when I tried to open Commons and got that message you get when servers are down. Same with Wikisource. English Wikipedia. Now, it's sporadically slow in bringing up pages, Special and File namespaces look like no style sheet and no skin. Right now, the edit window looks like it does not connect with style sheet, skin, preferences, all gone. Then it goes back to normal. Back and forth, back and forth.— Maile (talk) 20:24, 14 November 2013 (UTC)[reply]
Ditto for U.S. for last couple of hours. Looks like an overload problem — page gets rendered without the full formatting, perhaps because something has timed out. ~ J. Johnson (JJ) (talk) 21:17, 14 November 2013 (UTC)[reply]
Quick way to get a list of all entries in a category
Hi. Is there a way to get a list produced from all the entries in a single category? For example, from this category on the German Wikipedia, is it possible to do a straight export/list? If there was only a couple of pages, I could do a copy & paste, but this has 5,000+ entries. Happy for it to be put in a sub-page of my sandbox. Thanks. LugnutsDick Laurent is dead12:51, 13 November 2013 (UTC)[reply]
Go to de:Spezial:Exportieren, and in the first box "Seiten aus folgender Kategorie hinzufügen" (which may be titled "Add pages from category" depending on your language setting), paste in the full category name (with or without the namespace), and then click Hinzufügen (or Add). The larger box will then fill with all the page names in that category, which you may mark and copy if you just need the page names. Click Seiten exportieren (or Export) to export the content of all those pages as an XML file. --Redrose64 (talk) 15:28, 13 November 2013 (UTC) amended Redrose64 (talk) 10:34, 14 November 2013 (UTC)[reply]
Greetings. I process the pagecount and projectcount statistics made available by the WMF. Whoever amasses these files and members of the analytics team might be interested to know of an anamoly I spotted recently. The projectcounts-20131111-190001 file has this bizarre "r0w 4r0wonly@en 1 156" line (snip below). It has never appeared before, but it was enough to break my parsing engine.
Clicking on an image thumbnail will show the image page. If the image is a SVG, the image page used to have the option to render the SVG as a PNG of various sizes (2000px, 1000px, and a couple of others). That option seems to have disappeared within the last week or two. Is it a browser feature (it happens to me on IE10 and Chrome), a mediawiki change or some other factor? Astronaut (talk) 21:33, 13 November 2013 (UTC)[reply]
(edit conflict) If you want to see the links on enwiki, you can add the following javascript code to your common.js:
Extended content
/** * SVG images: adds links to rendered PNG images in different resolutions * * @author Krinkle, 2012-2013 * @deprecated in 1.18 */functionSVGThumbs(){varfile=document.getElementById('file');// might fail if MediaWiki can't render the SVGif(file&&mw.config.get('wgIsArticle')&&mw.config.get('wgTitle').match(/\.svg$/i)){varthumbu=jQuery(file).find('img:first').attr('src');if(!thumbu){return;}functionsvgAltSize(w,title){varpath,a;// Example:// - https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png// - https://upload.wikimedia.org/wikipedia/commons/thumb/7/70/Example.png/116px-Example.png// - https://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Gerrit_patchset_25838_test.svg/200px-Gerrit_patchset_25838_test.svg.png// - https://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Gerrit_patchset_25838_test.svg/langde-200px-Gerrit_patchset_25838_test.svg.pngpath=thumbu.replace(/\/(lang[a-z-]+-)?\d+(px-[^\/]+$)/,'/$1'+w+'$2');a=document.createElement('A');a.setAttribute('href',path);a.appendChild(document.createTextNode(title));returna;}varp=document.createElement('p');p.className='SVGThumbs';vari18n={'be-tarask':'Гэтая выява ў фармаце PNG у іншых памерах: ','be-x-old':'Гэтая выява ў фармаце PNG у іншых памерах: ',bn:'এই চিত্রটি অন্যান্য প্রস্থের মধ্যে PNG হিসেবে রূপান্তরিত: ',en:'This image rendered as PNG in other widths: ',de:'Dieses Bild im PNG-Format in folgenden Breiten: ',cs:'Tento obrázek jako PNG v jiné velikosti: ',cy:'Caiff y ddelwedd hon ei chynhyrchu mewn PNG yn y lled canlynol: ',fa:'رندر پی\u200cان\u200cجی این تصویر در اندازه\u200cهای دیگر: ',fr:'Cette image restituée en PNG dans d’autres tailles : ',hy:'Այս պատկերը մատուցված որպես ՓիԷնՋի այլ լայնքերով՝ ',id:'Gambar ini dijadikan PNG dengan lebar berbeda: ',min:'Gambar ko dijadian PNG jo leba babedo: ',ml:'ഈ ചിത്രം PNG ആയി ലഭ്യമാകുന്ന മറ്റ് വലിപ്പങ്ങൾ: ',mk:'Сликава како PNG во други големини: ',nl:'Deze PNG-afbeelding in andere groottes: ',pt:'Esta imagem renderizada como PNG em outros tamanhos: ','pt-br':'Esta imagem renderizada como PNG em outros tamanhos: ',sl:'Prikaži to sliko v PNG-zapisu v drugih velikostih: ',sv:'Denna bild i PNG-format i olika storlekar: ',tr:'PNG olarak işlenen bu görüntünün diğer genişlikleri: ','zh-hans':'该图像转换为PNG格式的其他尺寸：','zh-hant':'該圖像轉換為PNG格式的其他尺寸：',};varptext=i18n[mw.config.get('wgUserLanguage')]||i18n.en;p.appendChild(document.createTextNode(ptext));varl=[200,500,1000,2000];for(vari=0;i<l.length;i++){p.appendChild(svgAltSize(l[i],l[i]+'px'));if(i<l.length-1){p.appendChild(document.createTextNode(', '));}}p.appendChild(document.createTextNode('.'));varinfo=$(file.parentNode).find('div.fullMedia').get(0);if(info){info.appendChild(p);}}}$(SVGThumbs);
Alternatively, if you aren't too picky about widths, MediaWiki links to a few png renders by default sometimes (see below). For example, at File:Test.svg, there is a line that reads
Size of this preview: 321 × 599 pixels. Other resolutions: 128 × 240 pixels | 257 × 480 pixels.
These links can be clicked for pngs rendered in the listed sizes. You can then just modify the url with your desired width...for example, clicking on the 257 x 480 px link takes me to https://upload.wikimedia.org/wikipedia/commons/thumb/b/bd/Test.svg/257px-Test.svg.png -- you can just change the width in the url to https://upload.wikimedia.org/wikipedia/commons/thumb/b/bd/Test.svg/1000px-Test.svg.png (or whatever size you desire). Theopolisme(talk)23:30, 13 November 2013 (UTC)[reply]
I'm not an SVG expert -- do you know why this is? I assume it's based on the "nominal size" (set in one's vector graphics editor?) already being "thumbnail-sized". So in that case right-clicking on the image preview, choosing "Open image in new tab", and then changing the width in the url works just as well. Theopolisme(talk)02:09, 14 November 2013 (UTC)[reply]
There are various ways of editing a SVG file, some people use a graphics editor like Inkscape or Adobe Illustrator, other (like me) use a plain text editor to create and edit the SVG file, and a web browser to view the result (not Internet Explorer 9 or earlier, not sure about IE 10). SVG has no concept of thumbnails, nor of thumbnail sizes. The various "thumbnails" that you see on file description pages are actually PNG files converted from SVG by the Wikimedia "RSVG" software. RSVG isn't 100% exact: for example, at File:Third angle projection symbol.svg#filehistory you will see three attempts to get a particular image uploaded - each attempt was compliant with the SVG standards, but RSVG didn't recognise certain features and so the first two attempts were unsatisfactory. The first one failed (look at how the lines cross at the centre of the circles) because the SVG standard specifies that a dashed line be described as a list of values, and also allows those values to be separated with either spaces or commas, but RSVG doesn't like having the values separated by spaces. The second one failed (it has a transparent background) because RSVG doesn't recognise a style= attribute on the <svg> tag, although it is explicitly permitted by the standard.
SVG files that do not incorporate a bitmap are fully scalable (those that incorporate a bitmap are also scalable, but the results for the bitmapped portions can be disappointing - see the older of the two attempts at File:BSicon UKLC.svg#filehistory). All SVG files have dimensions - primarily because SVG uses an infinite canvas, so we need to specify just which portion of that canvas actually constitutes the drawing that is to be shown. For example, File:BSicon STRrg.svg looks like a 90° circular arc, but it is in fact a complete circular ring - the dimensions have been carefully chosen so that three-quarters of the ring lie outside the visible area. Specifically, the ring is of radius 250 and is centred at 500,500; but since the visible area of the drawing is defined as 500x500 with an origin at 0,0 only the upper left quarter of the ring lies inside the visible area. Notice that this is 500 unspecified units of length, and not 500 pixels, 500 em, or 500 inches - but it could be any of these. --Redrose64 (talk) 10:27, 14 November 2013 (UTC)[reply]
So, is this a change to mediawiki software or browser related? @Edokter and Theopolisme: Why do I now need to put a bit of script in common.js when the png links were there on both Commons and en.wikipedia until quite recently? Astronaut (talk) 18:37, 14 November 2013 (UTC)[reply]
Here's another trick which is probably simpler than anything above. Assuming that your operating system is Microsoft Windows:
visit any page where the image is displayed at any size
Redrose, I'm not asking for various ways to get a svg rendered as a png, nor am I interested in various tricks or javascript solutions. I'm asking what happened to the png rendering options that were already there for all svg images until quite recently. Did some mediawiki software change remove the options or maybe my recent upgrade to IE 10 took that option away? I really shouldn't have to ask the same question three times. Astronaut (talk) 13:59, 15 November 2013 (UTC)[reply]
They were never here; you are confused with Commons. They have a script that adds those links. You may have visited a Commons image page unknowingly when you clicked an image in an article. — Edokter (talk) — 21:21, 15 November 2013 (UTC)[reply]
logged-out way too often
I don't know if ayone else has noticed this, but, at least for me, I seem to get logged out automatically several times a day. I'm not clearing cookies or anything, but still, one minute i'm posting on a user talk page, do something else for 10 minutes, come back, and i'm already logged out. it gets rather annoying, having to log in several times a day, to say the least. -- Aunva6talk - contribs21:34, 13 November 2013 (UTC)[reply]
idk if logging in on my other computer logs me out here, but it's been going on for a couple weeks now. both chrome on win7 64, and firefox on win8 pro 64... -- Aunva6talk - contribs04:36, 14 November 2013 (UTC)[reply]
IE by itself is not a great sample size. Note that there was a Windows Update on both Tuesday and today - the first one may have toughened up IE in some not-widely-reported way: idle sessions or some such. In the meantime, do try any one of Firefox, Chrome or Opera. I only use these, and I get logged out about once every 30 days, right on schedule. Addendum: You may wish to ask on IRC #wikipedia-tech if there have been problems in any particular geographic area. --Lexein (talk) 04:53, 14 November 2013 (UTC)[reply]
A Windows update? Might that explain why since early (UTC) on 13 November, svchost.exe has been using up 50% of the CPU time, even if I reboot? I'm on Windows XP SP3. --Redrose64 (talk) 15:20, 14 November 2013 (UTC)[reply]
I couldn't find any clear indication on our end that something is wrong, so I'm a bit stumped. Do you continue to get logged out? I made some logs more verbose, so if you report back specific times in which this problem appears we'll be able to investigate it further. --Ori.livneh (talk) 06:40, 14 November 2013 (UTC)[reply]
well, I'mlogged in on my laptop, but i'm pretty sure that it's never logged me out like this before. we'll see if i'm logged out when I get back to my desktop, but it happened yesterday, between 2pm and 4pm central, without any external logon... -- Aunva6talk - contribs16:20, 14 November 2013 (UTC)[reply]
Logging out on one device will log you out on all devices. But that hasn't changed recently, so if the occurrence is suddenly higher, then that's probably not the case. Last week we also had some memcache issues, which may caused some sessions to be dropped. AFAIK, those have been fixed though, so if this is continuing, we can rule that out as well. I'll check and see if IE10 has made in changes in the last release that could have affected how it handles our login. CSteipp (talk) 16:44, 14 November 2013 (UTC)[reply]
Dear tech people: Each time today when I have been on the WP:Teahouse/Questions page, I keep getting an error messasge "A script is unresponsive". This happens even when I am just typing in the search box, as well as when I try to respond to a question. Firefox (25.0) also reports that it is not responding for a few seconds before recovering. If I close the dialogue box by clicking on the "X", then I can continue with my editing, but the error message appears again with the next edit or other operation. It doesn't happen on any other page, and restarting the browser has no effect. —Anne Delong (talk) 04:07, 14 November 2013 (UTC)[reply]
Cannot reproduce the problem with the same browser and same version (on Fedora Linux). Do you have any special Gadgets installed? Does the problem also happen in Firefox safe mode and/or with a fresh profile? --AKlapper (WMF) (talk) 10:08, 14 November 2013 (UTC)[reply]
Yes, I have gadgets. Here is my setup:
Browsing: *Navigation popups *Open external links in a new tab/window *Twinkle *Suppress display of the fundraiser banner *"Ask a question" feature for the Wikimedia Foundation's "Teahouse" project *Reference Tooltips
Watchlist: *Display pages on your watchlist that have changed since your last visit in bold.
Editing: *Add two new dropdown boxes below the edit summary box with some useful default summaries *Citation expander *Dot's syntax highlighter, *HotCat *Yet Another AFC Helper Script *Form for filing disputes at the dispute resolution noticeboard *CharInsert
Appearance: *Add a "Sandbox" link to the personal toolbar area. *Add page and user options to drop-down menus on the toolbar. *Change the "new section" tab text to instead display the much narrower "+". * Display an assessment of an article's quality as part of the page header for each article. *Widen the search box in the Vector skin.
Advanced: *Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms (uses API), as well as wildcard prefix searches
Or, if you meant Firefox gadgets, the only things that I have specifically added are Greasemonkey and AVG SiteSafety.
I know this isn't the place to ask, but I'm not sure whatever graphics lab we have would be responsive, but I was wondering if somebody could do me a favour and make me a montage based on something like User:Dr. Blofeld/Copenhagen montage?, ideally two rows of 4 underneath to main panorama?♦ Dr. Blofeld08:06, 14 November 2013 (UTC)[reply]
Very strange error message on article Interstate 10 in Texas, which occurs only while logged in
Suddenly today while viewing a fairly random article, Interstate 10 in Texas, I've been getting an error message that I've never seen before in 7+ years of heavy Wikipedia use and editing (I've been an admin since 2007). The page takes a very long time to load (around a minute) and the only content below the title is this (cut & pasted from the page source):
Sorry, the servers are overloaded at the moment.
Too many users are trying to view this page.
Please wait a while before you try to access this page again.
Timeout waiting for the lock
The entire text of the article is missing completely. I can view its talk page and history just fine, but trying to view an older version from the history does not work properly either.
All of the dozens of other WP articles and pages that I've been viewing today are loading properly, except this one article Interstate 10 in Texas. And the problem only occurs if I am logged in, not if I log out and view the same page as an anon IP, in which case it loads normally and completely. Just for testing, I tried logging in using my alternate account User:Seattle_Skier2, and the same error still occurs using that account. I've also tested using two different browsers (Safari and Chrome, both on Mac OS X), and the problem is the same in both browsers.
Are other users getting the same error message right now on Interstate 10 in Texas when viewing that page while logged in? Is this a common problem that I somehow have never seen and don't know about?
There are a lot of templates on that page, which is probably what is causing the issues. We are working on a Lua replacement for the most complicated of the templates, and we hope to have it done soon; it's hit a few snags, but we're actively working on it. --Rschen775409:11, 14 November 2013 (UTC)[reply]
I'm seeing a problem with US highway articles in general in the last 24–48 hours, but I can't pinpoint a specific cause. I have Interstate 196 at WP:FAC, and I'm currently working on U.S. Route 31 in Michigan. I-196 does not use a lot of the templates, yet editing other sections unrelated to {{jct}} or the {{jctint}} series triggers the server timeout when I save an edit. I can edit the References section to make the article display in multiple columns, something that doesn't involve the templates at all, and the error appears. As far as I can tell, none of the road-specific templates have been edited, so whatever has changed is not with the template code, leading me to believe it is something with the server configurations not the templates.
I just loaded I-10 in TX, and I didn't get that error message. Yes, the page takes a while, but it's not a short page since that's the longest state segment of any Interstate in the country. Imzadi 1979→09:17, 14 November 2013 (UTC)[reply]
Imzadi1979, which section you edit doesn't make much of a difference to timeouts. After saving an edit, MediaWiki re-parses the whole page, not just the section you've edited. Which section you were editing often has nothing to do with which section was most to blame for the timeout. – PartTimeGnome(talk | contribs)23:23, 14 November 2013 (UTC)[reply]
@PartTimeGnome: that might be, but the point is this. When the templates haven't been changed, why would articles that never timed out suddenly start? Also, why would the servers re-parse untouched sections of the article? Imzadi 1979→04:38, 15 November 2013 (UTC)[reply]
I have no answer for your first question. I don't know what has changed to trigger this issue. Sorry.
As for the second question, this is the way MediaWiki is designed. The parser cache does not cache sections independently, only whole pages, so the whole page must be re-parsed even if just a small part changes. Also, the parser needs information from previous sections that might affect the section you are editing (the most obvious example is <references/>, which uses earlier <ref> tags). Furthermore, changes in one section can affect subsequent sections (often accidental, though I have seen some creative uses of this). Updating the table of contents also requires a full page parse. A wiki system could be designed to treat sections as separate objects that can be cached independently, but that's not the wiki system we have. – PartTimeGnome(talk | contribs)21:40, 15 November 2013 (UTC)[reply]
Wikilinks look different when I am logged-in versus logged-out
When I am logged-in, wikilinks are underlined and distinct from other text, whereas when I am logged-out, wikilinks are not underlined and are quite faded, unless I move the mouse to the word -- in which case the underline appears. Is this an intentional feature? --Ben Best19:51, 14 November 2013 (UTC)[reply]
Probably. When you are logged in, the display is governed by your preferences settings. When you are logged out, you will get your browser's default behavior. RudolfRed (talk) 20:07, 14 November 2013 (UTC)[reply]
While you are in preferences, please check your Preferences → User profile → Signature settings. Either disable the "Treat the above as wiki markup" option or edit your signature to link to your user, user talk or contributions page. (At least one of these links is required by WP:SIGLINK. Disabling "Treat the above as wiki markup" allows MediaWiki to add the links for you.) I've fixed your signature above to link to your user page. – PartTimeGnome(talk | contribs)23:42, 14 November 2013 (UTC)[reply]
Still not working. Tried also in Safari, so this does not appear to be a browser issue. None of my Wikipedia prefs, browser settings, or computer settings have been changed recently. Kudpung กุดผึ้ง (talk) 21:10, 14 November 2013 (UTC)[reply]
JS and CSS have been acting weird for a couple days now. They said originally it was caused by something they were doing with the servers. I don't know if that's still what's going on, but I'm still getting intermittent style and js losses. equazcion→23:04, 14 Nov 2013 (UTC)
Status of #wikipedia-tech is "Status: JS/CSS loading issues" - it's on the radar, although not being discussed at this very second ;).(Not now.--12:15, 15 November 2013 (UTC)) --Lexein (talk) 03:24, 15 November 2013 (UTC)[reply]
It would be good if this could be fixed as soon as possible. Many busy users, especially admins and other maintenance users, such as vadalism, new page patrollers, and SPI and COPYVIO detectives have become accustomed to using these scripts and gadgets and rely heavily on them. Kudpung กุดผึ้ง (talk) 03:48, 15 November 2013 (UTC)[reply]
Secure site default
Suddenly, half way through an editing session, all my links to http://en.wikipedia are automatically connecting me to https://en.wikipedia. I'm using W7 IE10 & Vector.
My preferences are still set not to connect to the secure site. I trust this isn't the same "accidental" side effect we had about 10 weeks ago, which took about 4 weeks to fix, after someone loaded some half-tested software. (Could you please avoid the usual caustic comments about why would anyone still use IE, or use an unsecure site, it has all been explained before.) Thanks - Arjayay (talk) 10:17, 15 November 2013 (UTC)[reply]
28 hours later, and everything is still connecting to the secure site, despite the URL in the link being to the standard site. When is this likely to be addressed? - Arjayay (talk) 14:28, 16 November 2013 (UTC)[reply]
Some Firefox users needed to delete certain cookies, as described at Wikipedia:Village pump (technical)/Archive 116#Help Needed: Problems due to Secure site change; this may be the case for IE as well. I don't know how to delete individual cookies in IE, but if there is such a function, you could try doing that. There may be cookies at more than one domain, not just for obvious ones like en.wikipedia.org and commons.wikimedia.org, but also for domains such as login.wikimedia.org Be warned, that if IE only permits deletion on a per-domain basis, deletion of all cookies for any one of these domains may cause you to become logged out, so be prepared to log in again. --Redrose64 (talk) 16:50, 16 November 2013 (UTC)[reply]
But why would IE's cookies change half way through an editing session? The last time this happened, on 27 September (please see archive here), it was due to some problem introduced by software changes, (Bugzilla Bug 54626) which had to wait 2 weeks to be corrected. I don't pretend to understand Bugzilla reports, but is this not a repeat of the same problem? Arjayay (talk) 17:33, 16 November 2013 (UTC)[reply]
Technical problem
I have encountered problems in some recent edits on a couple of pages. Tried to make routine additions to Wayfarer (dinghy) of the following text: "An optional [[Asymetrical spinnaker]] and [[spinnaker chute]] is available; also available is a "sail patch" which provides flotation for the mast in the vent of a capsize (and particularly to prevent mast inversion {{ndash}}turtling." I did not intentionally touch anything in the footnotes. When I save it all of the footnotes were eliminated, which certainly was not my intention. I can't figure this out. Not sure if it is unique to me, a browser problem (I use Firefox, or if there is an issue on Wikipedia. I will also report this to the Village Pump technical people. 7&6=thirteen (☎)13:40, 15 November 2013 (UTC)[reply]
Your edits seem to be removing all HTML tags. I've had this happen to me before on rare occasions, but never quite figured out what did it. Out on a limb, I'm assuming one of our many malfunctioning scripts must be to blame. I see you have a DYK script in your monobook.js, which you may want to try removing just to rule that out. There could be a gadget that's malfunctioning too, so you may want to try disabling those. equazcion→15:43, 15 Nov 2013 (UTC)
The edits remove all tags (anything in <...>) and some words. [4] removed the words travel, Airport, makeup, silver, Pitt, Boxing, Gold. What is your skin and browser? Do you have any browser extensions? Please stop editing articles until this is resolved. Your edits have to be reverted. PrimeHunter (talk) 16:07, 15 November 2013 (UTC)[reply]
I don't use a text editor. I do this all by hand. I uninstalled Firefox and reinstalled it, but the problem persists. I feel very badly about any damage I have caused to our project, although I can assure you it was entirely not anything I knowingly did. So far as I know, I don't have any Wikipedia gadgets.
Don't feel bad. Your contributions show it has only happened for a few days and I have cleaned up the remaining cases. Which Firefox version? Any Firefox addons? See https://support.mozilla.org/en-US/kb/disable-or-remove-add-ons for how to check it. If you click "Show changes" before saving then accidental removals may be displayed but it's not guaranteed. If you check the page history each time and selfrevert in case of problems then you can continue editing articles and hope the problem goes away. It's harder to revert when others have edited the article since. PrimeHunter (talk) 20:36, 15 November 2013 (UTC)[reply]
I turned off every "gadget" (there was only one) and now seem to be editing without (as yet) discernible problems. That may have been the problem. Sadly, my new Firefox version is letting through all kinds of pop-ups, but that is another story. 7&6=thirteen (☎)20:47, 15 November 2013 (UTC)[reply]
Which gadget was it? equazcion→21:09, 15 Nov 2013 (UTC)
I don't remember. Sorry. It would be whatever the default selection would be, I think. It went away, briefly. Then it returned.
My computer was infected with some very persistent malware which was highjacking firefox. Now that I got that removed, it seems to be working better. I used malwarebytes antimalware, which uncovered bugs that my Norton Systemsworks was missing. This seems to have helped. 7&6=thirteen (☎)18:38, 18 November 2013 (UTC)[reply]
PortalandPortal2Rocks, I gave this a shot but wasn't successful. It's a big script, as it also uses functions from User:Pyrospirit/metadata.js, and there's a lot of spaghetti going on. I had trouble parsing through it all to find the possible issue(s), but I believe I did at least combine the relevant bits into one script and simplified some things. My draft copy is User:Equazcion/assesslinks.js, in case anyone else wants to give it a shot with my work as a head start. equazcion→15:24, 16 Nov 2013 (UTC)
This proposal is not for me, but for everyone. A lot of people had issues on this, and posted on village pump. Well, only 3, in fact. But still, thanks for the effort. PORTALandPORTAL2rocks 15:32, 16 November 2013 (UTC)[reply]
Rendering issue
rendering problem IE vs Chrome in Win XP
I am seeing a consistent rendering problem with all family tree templates. I tried converting one to chart, but this didn't help. See example. Jane (talk) 15:34, 15 November 2013 (UTC)[reply]
Hmm. Thanks for testing! I guess this is a pretty old computer. I am running Chrome 32.0.1700.6 and seeing the problem on all pages using either the template Familytree or Chart. Jane (talk) 21:53, 15 November 2013 (UTC)[reply]
Clearly a developer with a sense of humour. The pool is the total # of resources of available set aside for a task. The queue is - obviously - the line of tasks waiting to access those resources (using FIFO, LIFO, whatever). Apparently, the lineup for resources was either overly-full, or had an error ES&L12:10, 17 November 2013 (UTC)[reply]
We use ⟨angle brackets⟩ on a lot of language pages, enough to include them under 'symbols' in the edit window (between the guillemets and the currency signs). However, it seems that WinXP and maybe Vista does not support them. These are the characters generated with <math>\langle ... \rangle</math> There are two other Unicode entries for angle brackets, one pair in the Miscellaneous Technical block, and one in Chinese punctuation. The problem is that if you enter the Western ones directly, WP changes them to the Chinese ones, which screws up the character spacing. You can get around this by substituting &#...; codes, but if anyone copies and pastes those, they get converted to the Chinese block. To illustrate:
Code
Code display
Direct display
Misc. Tech.
〈 〉
...〈...〉...
...〈...〉...
⟨ ⟩
...⟨...⟩...
...⟨...⟩...
Chinese
〈 〉
...〈...〉...
...〈...〉...
HTML entities
⟨ ⟩
...⟨...⟩...
As you can probably see, only the top left cell has Western spacing.
Is this a bug in WP, and can we fix it so that we have angle brackets to use in our articles that hopefully are supported by XP & Vista? — kwami (talk) 16:05, 16 November 2013 (UTC)[reply]
Interesrting. It seems to be somewhat intentional (even the spaces are added). You can also use the ⟨ and ⟩ entities: ... ⟨...⟩ ... They are not converted. — Edokter (talk) — 16:34, 16 November 2013 (UTC)[reply]
In HTML5 ⟨ and ⟩ are supposed to correspond to U+27E8 and U+27E9 (mathematical angle brackets), which are distinct from U+2329/U+232A/U+3008/U+3009. If/when browsers will implement this, though, I don't know. Anomie⚔17:25, 16 November 2013 (UTC)[reply]
I also note that the latest Unicode standard specifically says U+2329 and U+232A are deprecated (see http://www.unicode.org/charts/PDF/U2300.pdf), and that the math tag version you mention above () should actually be using U+27E8 and U+27E9 (⟨ ... ⟩) (and with the MathJax math render, this does in fact seem to be the case). Anomie⚔17:03, 16 November 2013 (UTC)[reply]
Thanks. So as long as we don't allow them to be decomposed, or have just the right fonts installed, we're fine, otherwise they become CJK. — kwami (talk) 17:10, 16 November 2013 (UTC)[reply]
I'm not sure what exactly you're saying there, but it sounds wrong. You can try to use 〈 and 〉 all over the place, but if people change them to the literal characters 〈 and 〉 I'd recommend not edit warring over it. Anomie⚔17:25, 16 November 2013 (UTC)[reply]
It messes up the formatting when that happens, so I'd prefer a way of displaying the brackets that doesn't produce that result. Looks like we're out of luck. — kwami (talk) 17:34, 16 November 2013 (UTC)[reply]
We've started a template {{angle bracket}} to keep all the articles in line. Some computers do not support the math-A symbols, but do support the math code (last and first items listed on the talk page). It seems this might be a problem w WinXP, but not everyone w XP seems to have a problem. Does anyone here know what the issue is? It would be best not to use the math code, cuz that slows down page loading. — kwami (talk) 13:53, 17 November 2013 (UTC)[reply]
Okay, thanks. We've got a user insisting that it's the OS, not the browser, and that we reformat our articles so that he can read them. — kwami (talk) 15:43, 17 November 2013 (UTC)[reply]
Not knowing/showing the character is one thing. But with me, the pair ⟨ ⟩ shows ⟨ ... ⟩ in a grey (or transparent?) color, inline. It is the only two characters that I see doing this. (In other fonts, they even are invisible; test). I use FF 25 atop WinXP SP2,3. No fonts installed manually AFAIK. -DePiep (talk) 16:23, 17 November 2013 (UTC)[reply]
Again, depends on browser/OS combination. For me (XP/Chrome), those on the Help:IPA page use MATHEMATICAL LEFT ANGLE BRACKET and MATHEMATICAL RIGHT ANGLE BRACKET, which show quite clear for me, but the ⟨ and ⟩ display as LEFT-POINTING ANGLE BRACKET and RIGHT-POINTING ANGLE BRACKET, which are quite faded, probably as a result of font-smooting without proper hinting for those characters. — Edokter (talk) — 17:09, 17 November 2013 (UTC)[reply]
Pages inaccessible using IE8
I reported a problem a few weeks ago regrading trying to access River Usk using IE8 as a browser but didn't get a solution to the problem back then. I now find that I can't access Bristol Channel either using IE8. I can get them both using Chrome and no other pages that I've tried to access give this problem - just these two. have done the usual clearing of caches, and have also tried to access them on different machines - same negative result - I get thrown off the site and then end up with a message page saying that 'we were unable to return you to Wikipedia'. Any ideas? Any solutions, other than the obvious one of 'change your browser'? Given that all other WP pages work fine in IE8, I feel these two should also. cheers Geopersona (talk) 22:12, 16 November 2013 (UTC)[reply]
I'm using Windows XP (home version) if that's relevant though the other machine which had the same problem was using Windows 7 using IE8 too. Geopersona (talk) 22:23, 16 November 2013 (UTC)[reply]
Rover Scarab loaded fine in IE8, but Bristol Channel crashed it, but it loads fine in Firefox. When trying to load the Usk in IE8, I noticed it connecting briefly to 91.?.?.? (too quick to see any more). Is this normal? I've not noticed it on anything else connected with Wikipedia. I tried to load from a URL not a search engine link. Peridon (talk) 12:02, 17 November 2013 (UTC)[reply]
Some JavaScript is crashing IE8 (loads fine with JS disabled), can't figure out which script; it even crashes when debugging. — Edokter (talk) — 12:26, 17 November 2013 (UTC)[reply]
I've got it. I investigated with a web debugger (Fiddler2), blocking loading of scripts and loading them one-by-one: IE 8 crashes on Bristol Channel as soon as MediaWiki:Common.js/IEFixes.js is loaded. I'll leave it to you to find out why :) Matma Rextalk 12:44, 17 November 2013 (UTC) (Also, for whoever else digs into this – you can't reliably use the debug mode (?debug=1) because of another IE8 issue, tracked as Template:Bug. That is only relevant in debug mode, though, and most likely does not cause this particular issue here. Matma Rextalk12:46, 17 November 2013 (UTC))[reply]
Well, it's not hlist, so it must be some other ancient snippet of code that triggers an unrecoverable error, probably fixIEScroll . How to find out? — Edokter (talk) — 13:03, 17 November 2013 (UTC)[reply]
Fixed. I decided to remove the core reason from hlist (non-wrapping list items), and all its associated IE fixes that caused more trouble than I am willing to accept at this time. A horizontal list item wraps over two lines? Tough! — Edokter (talk) — 13:45, 17 November 2013 (UTC)[reply]
Thanks to all involved. I don't use IE myself, but I know that a lot of people do. (Firefox for me, with Chrome on one phone and something called Browser on the other.) Peridon (talk) 15:42, 17 November 2013 (UTC)[reply]
Thanks Guys! Not being at all techie, I don't pretend to understand what caused the problem was, nor how you fixed it but am grateful that you have. cheers Geopersona (talk) 16:06, 17 November 2013 (UTC)[reply]
Writ Keeper has a general purpose script that adds a talkback link (|TB|) after all links to user talk pages which can be installed by adding {{subst:js|User:Writ Keeper/Scripts/talkbackLink.js}} to your Special:MyPage/common.js. Alternatively, it would be trivial to fork the code of HelpDeskTBLinks and create a version that runs only on the CHU page. Would that be beneficial? Theopolisme(talk)23:25, 16 November 2013 (UTC)[reply]
Thanx for the response, I was going to see if I (a self-taught dev.) could adapt HelpDeskTBLinks for use at WP:CHU/S, but I put that off until I could see what level of response I got here. I will load {{subst:js|User:Writ Keeper/Scripts/talkbackLink.js}} and check it out, I'm thinking a gadget would be best, I've helped at other pages where this function would also be helpful ie. WP:PERM, WP:FFU and I'm sure there's others. Mlpearc (powwow)00:15, 17 November 2013 (UTC)[reply]
Making a script activate only in certain namespaces/pages is pretty easy. I could tweak the generic talkbackLink script to do that, but I'd just need to know which namespaces/pages you need it to activate on. equazcion→04:30, 17 Nov 2013 (UTC)
WP:CHU I believe. Mlpearc, if you'd like the learning experience, you can just make a copy of the HelpDeskTBLinks script in your userspace and then modify the first line, changing the page titles as necessary. Let us know if you need additional help! Theopolisme(talk)04:35, 17 November 2013 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Problems
There was a problem caused by too many requests to the database on November 14. [5]
Future
MediaWiki 1.23wmf4 was added to test wikis on November 14. It will arrive to non-Wikipedia wikis on November 19 and all Wikipedia wikis on November 21 (calendar).
The new Search tool (CirrusSearch) will be added to *.wikimedia.org, Wikimania and Wikisource wikis on November 19, and Wiktionary wikis on November 21 (except where it's already available). Once it is added, you can test it by adding &srbackend=CirrusSearch to the address of the search results page. It will become the main search engine on Wikivoyage wikis on November 21. [6]
The MassMessage tool will be added to all wikis on November 19 instead of November 14. It will make it simpler to send messages across wikis. [7]
I received an email telling me that my account had been compromised etc. but I didn't pay any attention to it as I was under a three month ban then, now as my ban is well over and as i tried to log in I couldn't, I saw a screen with a hidden password already there, am asked to type new passwords but then I got an error message to the effect that I didn't have the permission to edit the page etc. I tried forgot password too, i received a password in my email but couldn't log in, tried forgot password one more time without success. I think I deleted the email I received. I could of-course create a new account but I am a little attached with my username. Please help. 103.29.99.176 (talk) 17:10, 18 November 2013 (UTC)[reply]
The Wikimedia legal team invites you to participate in the development of the new Wikimedia trademark policy.
The current trademark policy was introduced in 2009 to protect the Wikimedia marks. We are now updating this policy to better balance permissive use of the marks with the legal requirements for preserving them for the community. The new draft trademark policy is ready for your review here, and we encourage you to discuss it here.
We would appreciate if someone would translate this message into your language so more members of your community can contribute to the conversation.
Looking for technical mentors and tasks for Google Code-in
Hi, I'm one of the Wikimedia org admins at mw:Google Code-in. We are looking for technical tasks that can be completed by students e.g. rewrite a wikitext template in Lua, update a gadget, document the functionality of a bot... We also need mentors for these tasks. You can start simple with one mentor proposing one task, or you can use this program to organize a taskforce of mentors with the objective of getting dozens of small technical tasks completed. You can check the current Wikimedia tasks here. The program started today, but there is still time to jump in. Give Google Code-in students a chance!--Qgil (talk) 01:22, 19 November 2013 (UTC)[reply]
wikimedia.org or filed under the "Security" product in Bugzilla.
. I did test that taking your latest version of {{Year in Norway}} and re-adding the <includeonly> tags did not cause any gaps to appear. For example, see how that appears in "1972 in Norway", one of the articles that displayed a gap before either of us edited the template. – PartTimeGnome (talk | contribs) 23:23, 7 November 2013 (UTC)
. You mean a number of references is still an issue in this with Lua, and that it is more so when refs are used in a template? -DePiep (talk) 07:54, 5 November 2013 (UTC)
Done Bug 56974. – PartTimeGnome (talk | contribs) 00:17, 13 November 2013 (UTC)
Fixed. I decided to remove the core reason from hlist (non-wrapping list items), and all its associated IE fixes that caused more trouble than I am willing to accept at this time. A horizontal list item wraps over two lines? Tough! — Edokter (talk) — 13:45, 17 November 2013 (UTC)
