This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
It appears that both Wikipedia and Commons refuse to allow file uploads with similar names. For example, if a poor-quality file named blah.jpg exits, and I want to upload an SVG equivalent of better quality called blah.svg, none of the dialogs permits the file to be uploaded, even though the name is clearly different. The system tells me that a file by that name already exists, yet when I try to access the file named blah.svg, it isn't there, either on Wikipedia or on Commons. As recently as a few weeks ago, there was no issue in using the same base file name, as long as the file name extension wasn't the same and the file type was different. In some cases the the original file name is poorly chosen and it is desirable to give the vector replacement file a different name, but in other cases forcing the user to change the base name is simply chicanery. The way it originally worked, the dialog would simply warn the user that a file with a chosen name already existed, but it wouldn't absolutely prevent the user from uploading it. This bug needs to be fixed ASAP. — QuicksilverT@02:31, 3 April 2014 (UTC)
to confirm, if you upload via special:upload (not upload wizard) and check the ignore all warnings box, does it work? There is an open bug about not working with upwiz, but it should currently work with old upload form when ignoring warnings. Bawolff (talk) 21:38, 3 April 2014 (UTC)
That works — sort of. I got it to work on Commons just now via special:upload. Once the form has (improperly) decided that I'm trying to upload a file with the same name, even if I check the "Ignore any warnings" box, the form fields are all disabled. Then, I click the "Upload file" button, and it does upload, but the body of the page is blank and needs to be created manually. That's fine, if one is familiar with the page format and templates, but totally mystifying to a novice. I'm near-certain that the upload dialog didn't behave that way in the past, although at the moment I've been unable to find a recent example in either Wikipedia or Commons where I uploaded a SVG file with a base name identical to an existing PNG or JPG file, with the intention of replacing the raster file with an equivalent vector file in an article by just changing the file name extension from .png or .jpg to .svg. The system doesn't consider "blah.svg" the same file name as "blah.png", so why should the upload dialog treat them as being the same? The Unix-like operating system on which Wikipedia and Commons run is case-sensitive with respect to file names, so it would treat "blah.png" as a different file than "blah.PNG". It makes sense to block de novo uploads like that, differing only in the capitalisation of the extension. To me, though, it doesn't make any sense whatsoever for the upload scripts to block uploads where the file name extension is completely different, even when extension capitalisation is not used as a criterion. I'd like to see the rationale for it having been made so. Maybe there was no rationale: I may simply be a bad algorithm in the script. — QuicksilverT@22:00, 4 April 2014 (UTC)
I read a report from a logged out user (an IP address) recently that he could see hidden categories, and I have just logged out and can confirm this. This is unwanted behaviour. Is this already being logged (Bugzilla?) and solved? Fram (talk) 08:25, 3 April 2014 (UTC)
I'm not aware of a bug report. If reproducible, it would be nice if somebody could create a bug report in the Bugzilla bug tracker by following the instructions How to report a bug. Thanks in advance! --AKlapper (WMF) (talk) 10:14, 3 April 2014 (UTC)
I don't think it's a bug. See WP:HIDDENCAT 'Notice that "hidden" parent categories are never in fact hidden on category pages (although they are listed separately).', which was added with this edit - more than five years ago. --Redrose64 (talk) 10:24, 3 April 2014 (UTC)
It is noted (thanks, hadn't seen that), but I do believe it is a bug. I see no reason why hidden cats should be shown to logged out users when on categories, but not when on articles. Fram (talk) 10:31, 3 April 2014 (UTC)
I won't fix it, because I don't write code. When it comes to fixing, you're not blocked from Gerrit (just for the records). --AKlapper (WMF) (talk) 11:24, 4 April 2014 (UTC)
My post was a reply to your "it would be nice if somebody could create a bug report in the Bugzilla bug tracker by following the instructions ". I assumed that was obvious because a) it was the only post you made here, and b) I explicitly referred to Bugzilla. Apparently not though... So, for clarity: @AKlapper (WMF): why don't you create the bugzilla report yourself, instead of hoping that "somebody" here would do it? You have access to and supposedly some knowledge of Bugzilla, and are now aware of the situation... Fram (talk) 12:24, 4 April 2014 (UTC)
Strange. Why would anyone who can't or doesn't want to see hidden cats on articles, want to navigate hidden cats in categories? The request doesn't make sense to me. Fram (talk) 11:00, 3 April 2014 (UTC)
Because otherwise they can end up at pages where there is basically no content and no links out except for the page furnature on the left hand side and top of the screen. Stuartyeates (talk) 19:39, 3 April 2014 (UTC)
Examples? I don't believe we should have any non-hidden categories which are only categorized in hidden categories, that doesn't make any sense. I have never noticed such a thing, does this scenario really happen? Fram (talk) 08:31, 4 April 2014 (UTC)
IP's don't have the option to show hidden categories but may still want to navigate hidden categories, and they are usually only members of other hidden categories. If you go to a subcategory then you should have a navigation link back to the category you came from. Articles often have a large number of hidden maintenace categories which can be annoying if you don't want them. Categories for articles will rarely have more than one hidden category which is easier to live with. If a category is member of many hidden categories then it's usually a maintenace category and when you navigate those, you are probably interested in maintenace and want to see the hidden categories. PrimeHunter (talk) 13:25, 5 April 2014 (UTC)
Typography change
Split from above section
But this is a good opportunity to remind you that all the fonts are scheduled to change (for people using the default/Vector skin, which is most of us) in about an hour. WhatamIdoing (talk) 17:34, 3 April 2014 (UTC)
Arrgghh!!! Well 1/2 Arrrgghh, anyway!! I like the new font. It's in line with research that I read a while back that Calibri (and its near relatives) are the best online/computer screen fonts. BUT, BUT, the difference between regular print/script and LINKS is hard to see. VERY HARD. I know I'm shouting, but I think this is a BIG DEAL. Tapered (talk) 09:20, 4 April 2014 (UTC)
Known issue that should be fixed up as part of the move to Draft: space and the introduction of the new AfC wizard/reviewing scripts. — {{U|Technical 13}}(t • e • c)11:25, 5 April 2014 (UTC)
Error message load.php
I noticed this
Stack trace from load.php, function mw</<.log</log.warn, line 148. load.php:148
No idea about the context as no steps to reproduce were given, but that can normally be fixed by replacing a link starting with "http://" by only "//" so it becomes protocol independent. --AKlapper (WMF) (talk) 16:24, 5 April 2014 (UTC)
After clicking on the "Special characters" tab on accident while on the edit screen and it "dropping down", now every time I hit edit on any page the Special characters drop down starts in the down position instead of up and out of the way. I can't figure out a way for it to stay in the up position and out of my view. Thank you kindly for any ideas you may have one how to pin it back in place. Regards, —dainomite21:46, 5 April 2014 (UTC)
What happens when you click on the "Special characters" heading again or the triangle next to it? What is your browser? PrimeHunter (talk) 22:35, 5 April 2014 (UTC)
I believe that the normal behavior is to leave it in whatever state you last used it in. So if you manually close it, it should stay closed for all future editing sessions. (That's what haapens for me). If that's not happening for you, then please tell us more about your web browser and computer. Thanks, Whatamidoing (WMF) (talk) 23:20, 5 April 2014 (UTC)
Well since it seems to "default" in the down/expanded position when I click on the "Special characters" drop down it goes back up into its collapsed/"normal position"... until the time when I hit "edit" on another page then it starts off in the down/expanded position and the vicious cycle repeats. Also, even when i hit preview or show changes it goes back into the down/expanded position. I use SRWare Iron for my browser, version 27.0.1500.0 (201000). Hope this helps. —dainomite23:27, 5 April 2014 (UTC)
The editor uses cookies to keep track of state. Since this code hasn't been touched in ages and no else has complained, I suspect that SRWare which seems to be messing with cookies to keep you safer, missed a beat somehow, causing you to have a cookie that you cannot change the value of any longer. —TheDJ (talk • contribs) 23:36, 5 April 2014 (UTC)
I don't know who's responsible for this, and most people are out because it's the weekend, so your report is now T65586. In the meantime, if the problem persists through the usual cookie-clearing and whatever else you want to try, have you tried clicking the "Cite" menu? At least if the Cite menu were to stick open, it would take up less room than the special characters one. Whatamidoing (WMF) (talk) 23:39, 5 April 2014 (UTC)
Interesting. I did click the "Cite" menu and now that is persistent. Since it only takes up one line it's not too shabby but rather interesting that the drop down being expanded persists regardless of what menu header is clicked. —dainomite23:42, 5 April 2014 (UTC)
Interesting... I even switched computers (I was on my laptop previously) and now I'm on my desktop which has the same browser/version as the laptop and I still have the problem. Just more tidbits for whomever tinkers with that bug report. —dainomite05:53, 7 April 2014 (UTC)
images in Infobox Song
I've followed advice given above – Preferences → Gadgets → Vector classic typography (use only sans-serif in Vector skin) – returning Wikipedia pages to something approaching the pre-2 April version. Problem I'm finding now is the way an image is rendered in Infobox Song, as shown here. (My system's Mac OS X Lion 10.7.5, by the way.) I'm not sure how the same examples appear without the opt-out.
Can anything be done to avoid the unsightly formatting text appearing around these images? Thanks, JG66 (talk) 02:47, 6 April 2014 (UTC)
It's not a typography-related problem, as far as I can tell. I checked the documentation for {{Infobox single}}, which said to use just the file name (without wikilinking) in |Cover=, so I made this edit. It looks better to me now. – Jonesey95 (talk) 03:58, 6 April 2014 (UTC)
Okay, but without the wikilinking it's not possible to reduce images to a size that's suitable for the context. That example (like others) is only a face label from a 7" disc – not a whole disc – so it looks way over the top at full size, in my opinion.
Thanks very much for trying, but I don't think that's the answer at all. Is it not possible to fix the issue I mentioned without losing the resizing function? JG66 (talk) 04:30, 6 April 2014 (UTC)
I fixed the technical problem with the "unsightly formatting text", as you requested. I do not see a way to get the image resizing function that you request, but I am not an expert with infoboxes.
The infobox has no size parameter and always sets the size at 250px. The output of a template can be manipulated with {{replace}} as in {{replace|(infobox code)|250px|180px}} which would curently work in the example, but it's an unstable method and I don't recommend it unless it fixes a far more serious issue. PrimeHunter (talk) 11:43, 6 April 2014 (UTC)
Just a general question. Has Wikipedia changed its Typeface slightly recently? The characters are a bit different.--BabbaQ (talk) 11:35, 6 April 2014 (UTC)
Dear editors: Is there a way to tell the creation date of a web page? For example, THIS OLD DRAFT, created in February 2012, was copy-pasted to NASA Space Universe a month or so later. However, there is also http://www.linernotes.com/o/1/NASA_Space_Universe, and I am trying to determine whether the last one is copied from Wikipedia or visa versa. If the draft came first, a history merge (and a severe NPOV editing of the subsequent mainspace article) may be in order to show that. If the Liner Notes page came first, I guess the whole introductory paragraph will have to go from the article. I tried Firefox page info, but it only tells when the page was last edited, not when it was first created. —Anne Delong (talk) 12:12, 6 April 2014 (UTC)
Some web developers - but by no means all - helpfully include revision information, sometimes visibly, sometimes in the form of metadata within the HTML source (possibly <!-- ... --> hidden comments, possibly the <meta /> element) but there is no requirement or even a recognised format. Wikipedia pages include embedded comments like
<!-- Saved in parser cache with key enwiki:pcache:idhash:1192206-0!*!0!!en!4!* and timestamp 20140406004148 -->
but this gives the current revision, not the creation. In the absence of such information, you really need shell-prompt access on the servers which host the pages. All websites with any reasonable amount of security will prevent such access. --Redrose64 (talk) 13:29, 6 April 2014 (UTC)
Hi. Template:sockpuppet does not seem to recognise the username of the sockpuppeteer. It outputs the following message: An editor has expressed a concern that this account may be a sock puppet of User-multi error: "{{{1}}}" is not a valid project or language code (help)... See also: User talk:Wendylee885. Δρ.Κ.λόγοςπράξις18:15, 6 April 2014 (UTC)
I've fixed {{sockpuppet}} and restored the new version of {{user3}}. The sockpuppet template was using a user3 invocation like this: {{user3|Example|Example}}. The second "Example" is a leftover from before user3 used Template:User-multi, when it was used as a display value. However, that hasn't worked for years now. I've been updating all the user links templates to use equivalent syntax to {{user}}, which uses the second parameter as a project or language code to link to users on other projects. Invalid project or language codes result in an error, whereas there is no error if they are absent. Previously there was no error, as {{user-multi}} could not see the second parameter, but when I passed it through it thought it was a project code and duly reported it as an error. This could also be fixed by just not passing the parameter through, but for consistency's sake, I think passing it through and fixing the broken transclusions is the better solution. If anyone is interested to see which pages have errors on them, they are all in Category:UserLinks transclusions with errors. The category is suffering from job queue delays, though - archives should not be categorised with the new version of Module:UserLinks, for instance, but there are still quite a few left in the category. — Mr. Stradivarius♪ talk ♪03:38, 7 April 2014 (UTC)
Can the text of a template be varied based on the userrights of the editor who posts it? (e.g. different wording for admin / non-admin users). NE Ent22:48, 6 April 2014 (UTC)
You can add text that is admin specific using the class sysop-show. The following is only visible to sysops: To be used sparsely and not inside content END. It's used in a few maintenance templates. Similar technique is available for accountcreator, templateeditor and autoconfirmed. —TheDJ (talk • contribs) 22:59, 6 April 2014 (UTC)
Note that using those classes will result in it looking different based on who is reading it, rather than who is posting it. Jackmcbarn (talk) 23:27, 6 April 2014 (UTC)
That's probably not useful here; i read the question as "Can the final text, visible to the user to whom it was addressed, be different based on the accessrights of whoever posted it?"... Something like #switch on some magicword for those userrights. -- Jokes_Free4Me (talk) 23:31, 6 April 2014 (UTC)
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf21) was scheduled to be deployed to test wikis and MediaWiki.org on April 3, however it was temporarily put on hold due to localization issues. (calendar).
Typography Refresh was enabled on non-Wikipedia wikis on April 1, and on all Wikipedias on April 3. You'll only see it if you use the Vector skin.
CirrusSearch was enabled as the primary search method on over 400 non-Wikipedia wikis on April 2. [1]
Future software changes
A new special page (Special:TrackingCategories) will soon list all the tracking categories on a wiki. [2][3]
All Wikiquote projects will start using language links from Wikidata on April 8. [4]
The Hovercards feature will soon work with right-to-left languages. [5][6]
You will soon be able to download files directly from MediaViewer, the new multimedia tool. [7]
MediaViewer will be enabled for all users on MediaWiki.org on April 10. Comments are welcome.
You can help check that users can read CAPTCHAs in your language. [8]
I've been doing some work on the Lua/CSS/JS CodeEditor to make it and its toolbar a bit more usable, but I'm looking for some input on what YOU want in the toolbar
Some possible options are:
show invisible chars
search and replace
undo/redo
indent/unindent
Enable soft wrapping of lines
tab and page guides
Disable syntax checking/linting
Disable gutter/linenumbers
Select editor skin
Edit snippets
Go to line
A list of existing key commands is here And ACE itself has a demo site that shows a few of the options as well, if you want to experiment.
I've now got a button to show invisible characters, and a button to show the find and replace dialog and wondering where to go next. Of course most options are available already trough key commands but many people are not familiar with those, so what do you think should be in the toolbar, what do you think should NOT be in there, and do you have additional ideas to the ones I listed above. I can really use the input. —TheDJ (talk • contribs) 00:11, 26 March 2014 (UTC)
Wait, the editor has syntax checking that works? Right now I rely on a crude hack to have it.
"Go to line", indentation guides and indentation converter would be great. Also, remove buttons that are only relevant to wikitext. Keφr06:34, 26 March 2014 (UTC)
A patch to remove all the other buttons is being worked on, a patch for code completion is waiting for review and a patch to enable syntax checking is already merged (preview of the last available on beta labs) —TheDJ (talk • contribs) 07:26, 26 March 2014 (UTC)
Finally. Those forgotten commas were driving me nuts. How about stripping trailing whitespace from lines? I think it should even run automatically before saving a JS/CSS page.
Also, can the JS linter be customised or hooked somehow? For example, I would like to turn off warning about assignment-expressions in conditionals (I like using the if(m=/regex/.exec(s)) idiom). Or warn when using some specific symbols, like deprecated MediaWiki features. Keφr15:22, 26 March 2014 (UTC)
As long as it is supported in JSHint, then with this technique, we can make some 'initial' changes, or even you as a user can make some changes, by hooking into codeEditor's mw.hook event. (I should document that part btw). —TheDJ (talk • contribs) 15:56, 26 March 2014 (UTC)
Nothing to do with the toolbar, but could we make the font size a bit bigger? For me it is significantly smaller than the default wiki font size, so I have to change the browser font size every time I switch from wiki pages to CodeEditor if I want to avoid squinting. I'm not sure where the setting is best applied though. Also, is there a way to override the ctrl+R shortcut? I have been known to press that instead of ctrl+F, and it has made me lose work more than once, as on Firefox and Chrome it is the shortcut to refresh the page. Out of the toolbar buttons listed above, I think the most useful ones would be enable soft wrapping of lines, show invisible chars, search and replace, go to line, and indent/unindent. I don't see myself using disable gutter/line numbers or tab/page guides. Also, what does the "edit snippets" feature do? — Mr. Stradivarius♪ talk ♪12:29, 27 March 2014 (UTC)
We can, though for me it's already quite big (12px Monaco). I think that if you don't have the Monaco, it's probably significantly smaller. I'll think about how to solve that. With regards to the shortcuts, I plan on adding the dialog to warn you about unsaved changes, but currently it's conflicting with dialog of the plain wiki editor, so I need to spend some time refining it. But having that dialog should make the problem of keyboard shortcut conflicts less problematic I think. Edit snippets is a mode where you can maintain and keep templates that you can reuse. I'm not sure on how to do that yet, preferably they are saved to some userspace page. It will likely be last on my list, since there is plenty low hanging fruit for now. —TheDJ (talk • contribs) 12:50, 27 March 2014 (UTC)
Yes, having the dialog to warn about unsaved changes would do the trick. I don't think there's any need to make the edit snippets feature available for now, either. — Mr. Stradivarius♪ talk ♪13:28, 27 March 2014 (UTC)
Keep the font size as it is, please. These old eyes have no problem reading the text in the editor using Chrome.
Tool bar help menu should be appropriate to the code editor and should include the list of keyboard commands and perhaps links to css/js/lua references.
Screenshot of Wikipedia beta code editor in Chrome on Trappist the monk's winxp machineFont on my machine is completely different from yours. The code editor font and the font in this edit window (not the enhanced editor) are similar to each other. The beta code editor and the current code editor, for me, have similar fonts.
Every editor that supports Unicode should have a function to display the code (and perhaps name) of a character. This could be a character pointed to by the mouse, or the character at the cursor location. Jc3s5h (talk) 12:37, 27 March 2014 (UTC)
Remembered something now: relegate the "search and replace" function to another shortcut (Ctrl+H seems customary), instead of Ctrl+F twice. The rationale is that I often use Ctrl+F with the intention to simply move the keyboard focus to the search box, and sometimes I forget it was already there. — Keφr06:05, 31 March 2014 (UTC)
There are a couple of commands that have already been removed (not reassigned) for similar reasons. The problem with reassigning is that it also 'messes' with your expectations. I'm not sure what is better. —TheDJ (talk • contribs) 08:18, 31 March 2014 (UTC)
Another thing which would be great: Lua linter warning about globals other than built-ins (mw, table, ipairs, etc.), just like JSHint can do. Though this would probably require changes to Ace itself, and maybe even the underlying Lua parser. — Keφr14:02, 2 April 2014 (UTC)
I experience a weird behaviour by the CodeEditor when editing Lua modules. Most often I get a regular WP edit screen (plain text), but sometimes the edit screen opens in CE mode (with the numbered lines). This CE shows more often when trying (failing) to Save page with code errors, and after hitting the Changes button. I see no pattern, and can't tell if it is related to the changes discussed here. I have not actively changed my settings for the CE editor AFAIK (i'd like to use it though). Would it help if I make an extensive report here, or is is a beta-thing that will go away over time? -DePiep (talk) 15:14, 8 April 2014 (UTC)
Talk tab colour
A talkpage that is a redirectA talk page that only contains templates or is empty
copied from the Help desk, with small change of my own words, 14:30, 3 April 2014 (UTC)
Hello, when the word Talk of the talk page tab of an article is blue, I often click on it to see if there are any disagreements about the content of the article. I am used to do this as well when using Wikipedia to learn something, not only when editing.
On the English Wikipedia however, many talk pages only consist of a template with information about ratings, Wikiprojects, etc. I am not interested in those templates, so this causes many times a disappointment about unnecessary page loading. I once read that other people sharing this feeling made some gadget or so which changes the colour of 'Talk' in these cases. So there is not only red (when there is no talk page) and blue but also a third colour (green for example), for template-only 'Talk' pages. The word Talk only being blue when there is really talk.
I forgot to bookmark the place where I read this and now I can't find it any-more. Does anybody know about this?
As part of IEG project me and Ravid ziv wrote a user script similar to RefToolbar but for VisualEditor - it allows to easily add citations templates (Cite web/Cite book/Cite journal/Cite news). The scripts adds a "cite" option in toolbar, in which you can select a citation template, fill its parameters, and then it adds the template, within reference tag (<ref>) to article.
cite button
citation dialog (selecting template)
We think it can be very helpful for editors who use VisualEditor and makes it much easier to insert citations. To use the script add to your personal JS the following code:
{{subst:iusc|User:ערן/refToolbarVeLoader.js}}
We invite you to use and test it. You are welcome to suggest missing features or share other ideas that may improve the use of citations in VE (or a nice idea for icon ). Eran (talk) 14:55, 4 April 2014 (UTC)
Where do you want the feedback?
'month' is deprecated and will now give an error; 'date' now supports year, month year, season year and day month year/month day year. We are only keeping 'year' when a disambiguator is need for Harvard/shortened footnotes.
Unused parameters are added
Spacing around = is inconsistent (my preference is no space)
|coauthors= is also deprecated and will give an error.
I don't know if it would be better, but maybe using "first1" and "last1" would give people the idea that if they have more authors, they can add them in Preview mode using "first2", "last2", etc.
Is it possible to nag people when they try to add a parameter that requires another parameter? For example, |accessdate= requires |url=, and using |url= without a |title= will generate an error message.
I haven't tested it, but does your code properly encode characters like | and = when they are used in parameters where they would otherwise create errors? Using | within a parameters will create an "unnamed parameter" or "unsupported parameter" error. – Jonesey95 (talk) 16:14, 4 April 2014 (UTC)
Thanks for the feedback.
Deprecated parameters - We removed coauthors parameter. Where is the deprecated month parameter? (in which template?) the tool doesn't add it as far as we test (It is possible however to add additional parameter - all the supported parameters declared in the template documentation)
Empty/unused parameters - the tool doesn't add them any more to source code.
Spacing around = - it is the default convention the VE adds spacing. Both options are fine, but we want to be consistent with the rest of the VE (standard template dialog)
Regarding constraints between parameters (accessdate and url) - it isn't possible to specify complex constraints between parameters currently, but TemplateData allows to specify simple constraints (required/optional param) and sets of associated params.
Re constraints: {{cite web}} without |url= generates an error, so you could require that. It's OK to have |url= without |accessdate=, so you can't require them together, unfortunately. I do not see any other parameters in your code that are required or that interact, other than the ones I described above. Keep up the good work. – Jonesey95 (talk) 21:22, 4 April 2014 (UTC)
@ערן: There might be a slight problem here... I believe the VE team in collaboration with community feedback, has already put a lot of time and effort into an official and cross-wiki-utilizable "Citation feature" for VE. You can see details and discussion about that here: mw:VisualEditor/Design/Reference Dialog, and see yesterday's Metrics meeting overview of the feature (youtube at exact timestamp), and try it out at beta.wmflabs. Did you talk to the VE team about your work on this? Sorry to be the bearer of bad news :( –Quiddity (talk) 18:00, 4 April 2014 (UTC)
Quiddity, thanks for letting us know, it seems that there was some misunderstanding with the VE team and duplication of work, and we will talk with the VE team to integrate the benefits of our gadget (such as adding optional parameters easily), and the comments above to VisualEditor itself. He hope to see a core support for citation live in production in the near future. Eran (talk) 08:52, 5 April 2014 (UTC)
VE should have really had support for the cite templates before it launched. Glad to see this is being created. Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:48, 7 April 2014 (UTC)
VisualEditor did have support for citation templates when it was launched. What it didn't have was convenient support for citation templates: You had to add a reference, insert a template, hope that TemplateData was defined, insert each parameter separately, add each bit of data separately, and hope that you didn't forget anything.
It's better now, but what it really needs is autofilling. They're working on at the moment, but it sounds like it will be some months before that's truly complete. Whatamidoing (WMF) (talk) 21:29, 7 April 2014 (UTC)
You should also include {{Citation}} as a citation template. Like Jonesey95, I recommend |first1= and |last1=. I would differ from Gadget slightly in having a space after the "=" (and also preceding the vertical bars). A big point to consider: full citations need not, and in fact do not, always go into footnotes (<refs>...</refs>). If someone wants to add a citation in a "References" section you should allow a non-footnoted insertion into a list. ~ J. Johnson (JJ) (talk) 21:58, 8 April 2014 (UTC)
List of all namespaces on WMF wikis
Does anyone know where I can get hold of a list of all namespaces used on WMF wikis? It's just been pointed out to me that Module:Namespace detect will have problems on en.wikisource because they have a namespace named "Page". The module automatically detects namespace names, converts them to lower case, and allows them as parameter names. The problem is that there is also a "page" parameter that is used to set a page name for testing purposes. The next time I choose a default parameter name I'd like to avoid clashes like this one, so a comprehensive list would be very helpful. — Mr. Stradivarius♪ talk ♪05:32, 5 April 2014 (UTC)
As you know, there are hundreds of namespace names as translated for the other-language wikipedias. Beware namespace "Format:" for templates in Romanian Wikipedia, with hundreds of others: Clowan, Mal, Mall, Malline, Modele, Mudell, Patrono, Plantilia, Plantilla, Predloga, Προτυπο (Protypo), Sjabloon, Snið, Stampa, Templat, Template, Templet, Veidne, Vorlage, etc. (hundreds). Consider making parameter names as code-symbols or numbered, such as "pg=" or "v2=" or "&page=" with a leading ampersand for each parameter name, etc. -Wikid7707:59, 5 April 2014 (UTC)
Ok, so I'm now thinking of updating Module:Category handler, and that has the following parameters: "categories", "category2", "nocat", "subpage", "all" and "other". If any of those might conflict with any existing namespaces on any other wikis, they shouldn't be made into default parameters. However, every time we change a default parameter name it's going to mean an extra argument lookup, which has a performance cost. (And this is a very widely-used module, often with many uses on one page.) At the moment I'm thinking we should change "all" and "other" - does anyone else have any advice on the best thing to do? — Mr. Stradivarius♪ talk ♪07:01, 10 April 2014 (UTC)
Is this a thing?
For some reason I can no longer see the this user's sig [Windows7/Firefox]: ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼ Screenshot: [9]
It was me picking Unicode characters for my cat-face that aren't supported in the font you're using. While it looked fine in MacOS X (on my system, which is not vanilla), I just tested it in Windows 7 (not vanilla either, but not heavily customized) and got a "less bad" result (only missing the left whiskers), but that's bad enough. In nearly-vanilla Windows 8, the characters all show up, but the middle one looks like two separate characters and doesn't work for this idea, in the default font in Firefox, for non-logged in users at Wikipedia; same result when logged in with the Typography Refresh beta turned on. I've switched to a simpler kitteh in my current sig and worked around the middle-character problem by picking something else. Looks fine in Mac OS X, Windows 7, Window 8.
I don't know anything about a "known WindowsXP/Windows7 font change bug". Can you link to something specific? — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:17, 7 April 2014 (UTC)
I wish we had a Lua module where you could paste in a set of characters, or the unicode numbers from inside the box when they don't display, and get back a download link for a Wikipedia-recommended font to display them. I could code the module and paste in a data set... the problem is, I don't know where to find out what font to recommend! Wnt (talk) 22:56, 8 April 2014 (UTC)
User:Talk Special Pages Menu
Is there a menu available for User:Talk pages that lists the special pages for the respective user, or are we limited to writing it down, or memory? In other words, username/sandbox2 or /archives or /banner links, or whatever?? Atsme☯ talk13:11, 8 April 2014 (UTC)
If you mean you want a list of all your subpages, you can put the following on your user page: {{Special:PrefixIndex/User:Atsme/}}. — Edokter (talk) — 13:21, 8 April 2014 (UTC)
@PrimeHunter: What is the banner about at that page? It reads:
Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.Atsme☯ talk15:06, 8 April 2014 (UTC)
You don't need any of these scripts if you're prepared to make one extra click. When you're on a user page or user talk page, look for the "Page information" link in the sidebar. Click that; in the first box, look for the row "Number of subpages of this page". This should be bluelinked; click that. --Redrose64 (talk) 16:41, 8 April 2014 (UTC)
Propun să se creeze obligativitatea inserării informative a imaginilor care să conţină următoarele elemente:
--localitatea ex Bucureşti (Rom);
--Locul: strada şi denumirea instituţiei ex-cal Victoriei-Muzeul Naţional de Istorie a
României;
Deci: imagine>>> Bucureşti-cal Victoriei_Muzeul Naţional de Istorie a României.
Mai propun ca toate informaţiile editate in limba engleză a Wikipediei să fie inserate şi in limba română a Wikipediei.ro
Cu consideraţie, M Drosu — Preceding unsigned comment added by 89.39.206.89 (talk) 15:32, 8 April 2014 (UTC)
This page is for communication in English. I don't know Romanian and it's hard to tell exactly what you propose from the below machine translation by Google Translate. Wikipedia language editions are edited independently. PrimeHunter (talk) 15:50, 8 April 2014 (UTC)
Image Presentation Technique
I propose to create informative insertion obligation images containing the following elements:
- Eg city Bucharest (ROU);
- Location: the street and the name of ex-horse-Victoria National Museum of History
Romania;
So: >>> image Victoriei_Muzeul horse Bucharest Romanian National History.
Proposes that all information published in the English Wikipedia is inserted and the Romanian language Wikipediei.ro
regards, M Drosu
I'm a native speaker and it's still difficult to understand much of the message (it might be about an image-naming policy, but i can't be sure). But here it is, using a proper translation instead of an automated one: — Preceding unsigned comment added by Jokes Free4Me (talk • contribs) 16:21, 8 April 2014 (UTC)
Image Presentation Technique
I suggest to create the obligation of informative insertion of images containing the following elements:
- Locality, e.g. Bucharest (ROU);
- Place: the street and the name of the institution, e.g.- Victoriei Way- National Museum of History of Romania.
So: image >>> Bucharest-Victoriei Way_National Museum of History of Romania.
I also suggest that all information edited in the English Wikipedia to also be inserted in the Romanian language of-Wikipedia.ro
regards, M Drosu
What is the Mediawiki interface page for the "Watch this page" checkbox text?
Hello! Recently, the parameter |Animated= was added to the {{WikiProject Film}} template, in order to include articles in the Animated films work group. I have started to add the parameter to talk pages, however the articles are not being added to the project with the proper classification, since the Film project does not use the |importance= parameter. Therefore, they are showing up on the assessment table for animated films as "Other". I understand that this one is unique, because it's technically a work group of the Animation project, but none of the other Film task forces use importance. Is there any way to have these articles default to the importance for the {{WikiProject Animation}} template? Fortdj33 (talk) 13:06, 9 April 2014 (UTC)
@Redrose64:, I appreciate the information that you provided, when I asked you about this problem directly. I re-posted the question here, because I realized that the concern is really just how the data is displayed on the assessment table. Therefore, if a script can be added to modify the display of the table, no additional parameter on the project banner would be necessary. For example, something that would make articles default to the value of |film-importance=, if present on the {{WikiProject Animation}} template, and default to "NA" if the parameter is not present. Fortdj33 (talk) 21:02, 9 April 2014 (UTC)
Does anyone know whether the X users have enabled this feature (in Beta features, accessible from the top right of your page) indicates the X "on enwiki", or the X "across all wikiversions"? I'm wondering because the high numbers of enabled users doesn't seem to correspond with the number of active editors, or the number of editors who use a feature on enwiki. For VisualEditor, it claims "29,074 users have enabled this feature." which is extremely unlikely to be correct for enwiki only, and which is very misleading otherwise because it is enabled by default for most other wikis, no becaues 29,000 people actually want and use it. Fram (talk) 13:00, 4 April 2014 (UTC)
@Fram: The "Automatically enable" feature had a bug for many months that prevented it from working at all (bugzilla:60748, that was only fixed in late March, wmf19) and has a remaining bug (bugzilla:62815) whereby it only triggers if we "visit Special:Preferences, or whenever the 'GetPreferences' hook is run". So, the numbers prior to that time are accurate - ie. ~25,000+ editors did manually click the button to opt-in to VE, at Enwiki. HTH. –Quiddity (talk) 17:26, 4 April 2014 (UTC)
Yes, the discrepancy between how many users have supposedly actively enabled it, and how many users actually use it, is gigantic. No idea why... Fram (talk) 08:47, 11 April 2014 (UTC)
The number given is the number of accounts currently opted-in. It is not, unfortunately, the number of accounts opted-in that have ever used the feature, or the number of opted-in accounts that have edited (or even logged in) here recently. It is a bit like the problem with the number of people watching a page: a page can be on a thousand watchlists, but if those editors haven't logged in for years, then it's not actually being watched by anyone. Whatamidoing (WMF) (talk) 21:54, 11 April 2014 (UTC)
Old look
Sample
The strange template fonts (such as in "Competitor for Belarus" here or similar in Template:Egyptian Dynasty list) in my Mozilla browser appeared before the new April font rollout. I recall seeing less obtrusive template fonts before, so wonder what's going on. I tried vector.css, bypassed the cache, but nothing happened. Could anyone drop a hint? Brandmeistertalk17:04, 5 April 2014 (UTC)
I've worked out that your screenshot is from Darya Domracheva. Now that I know that, I can look at what templates are used; and I find that the culprit is {{MedalCountry}} where we have the line
! colspan="3" | '''Competitor for <span class="country-name">{{{1}}}</span>'''
that is, a table header cell which is boldfaced. Table header cells are normally boldface by default - they don't need the boldface markup ''' ''' as well, so this is a case of double-bold. As occasionally discussed on this page (and elsewhere), double-bold behaves inconsistently between browsers - and also depends upon installed fonts. To get a consistent appearance, remove the ''' ''' --Redrose64 (talk) 22:33, 5 April 2014 (UTC)
{{Egyptian Dynasty list}} is basically the same problem: boldface inside a table header cell. It's a nasty template: it's a mixture of Wikimarkup, raw HTML, and some inline CSS. It produces a one-column two-row table, with the cell in the first row being a header cell, and that in the second row being a data cell. The header cell is subdivided using several nested <div>...</div> and it ends with </div><div style="font-size: 100%"> both of which are unbalanced. Some of the inline CSS uses a property text-weight:bold; which I can't find in the CSS documentation; but there is some bolding using the <b>...</b> HTML, and also using the ''' ''' Wikimarkup. What it comes down to is again boldface within a table header - double-bolding. --Redrose64 (talk) 23:10, 5 April 2014 (UTC)
{{Egyptian Dynasty list}} is an old template, originally created in 2004, so no surprise it has some problems due to cruft. Is there any way to identify templates that have been around that long so someone could do a preventative check for the same? -- llywrch (talk) 16:55, 10 April 2014 (UTC)
Database query request
Could someone with SQL chops and access to a copy of the DB please produce me a list of all redirects in the Template namespace that have a target whose name begins with "Template:WikiProject"? Thank you in advance! — Scott•talk17:05, 5 April 2014 (UTC)
Ah yes, I forgot to report back here with what I had planned to do! Thanks for the offer; one of these days I shall finally get around to setting myself up at Tool Labs so that I don't have to ask other people to help out. :) — Scott•talk21:43, 7 April 2014 (UTC)
@PiRSquared17: Actually yes, I do have a request. Would you be able to produce me transclusion counts for the entries in this section, please? I see from the source of Jarry's tool that there's a templatelinks table that can be queried. — Scott•talk10:17, 8 April 2014 (UTC)
@Scott: Sorry for delay, just saw this. Here it is. Sorted by transclusion count. Thanks for the hint about templatelinks. I only included titles not beginning with either "WikiProject" or "WP". Do you want help with setting yourself up on Tool Labs? πr2 (t • c) 11:52, 8 April 2014 (UTC)
Ah, thanks again. No need to apologize, this isn't mission-critical stuff, and you've saved me a bunch of time. Thanks for the offer of help, too; I will take you up on it at some point. The main obstacle has been setting aside the time to really get "in the zone" for it, but I'm sure that will happen soon. — Scott•talk22:41, 10 April 2014 (UTC)
Cite menu on toolbar missing!
Fixed
I no longer have the "Cite" menu on my editing toolbar. There are the icons just above the text box for Bold text, Italic text, signature and timestamp, link, embedded file, reference, and drop-down menus for "Advanced", Special characters", and "Help". That is all. I use to have one that said "Cite". I am quite dependent on it. Please help! I've tried switching browsers from Chrome to IE, restarting the computer, and searching under "My Preferences". Chrisrus (talk) 06:07, 8 April 2014 (UTC)
Since today I have exactly the same issue (posted it at the help desk). I occasionally had this issue in the past and found that a page refresh or two was all it took to make it reappear but no amount of refreshes or restarting the computer helps this time.--Wolbo (talk) 09:56, 8 April 2014 (UTC)
I have the Vector skin and RefToolbar 2.0b. However, under the row of RefToolbar 2.0b I have two rows of buttons in the style of RefToolbar 1.0 so my toolbar looks like a mixture between these two and this is how it has appeared for some time (but with the 'cite' menu).--Wolbo (talk) 10:25, 8 April 2014 (UTC)
Solved. In my preferences section under 'Editing' - 'Editor' the setting 'Show edit toolbar (requires JavaScript)' was not selected. After selecting and saving the 'Cite' menu appears again. I had not manually changed this setting and don't know if before this issue it was selected or not.--Wolbo (talk) 10:39, 8 April 2014 (UTC)
Ah, that was actually one of things that the last change was fixing, forced loading of toolbars, even though people didn't have them enabled. —TheDJ (talk • contribs) 12:08, 8 April 2014 (UTC)
For the second time in as many days, I was logged out right in the middle of an edit. Last time it happened when I clicked "Save". And this time it happened when I clicked "Changes". And it logged me out globally, but when I log back in to English Wikipedia, it did not globally log me back in. Yes, I have checked "keep me logged in for..." And then wait a minute or two, and I'm magically logged back in globally.— Maile (talk) 21:09, 9 April 2014 (UTC)
I'm sorry to hear that you've had such a bad time of it. This is an annoying problem, and it creates a lot of work for OTRS. I've started wishing for a cookie-based pref setting that aggressively discourages logged-out editing. My idea is that if I edit from a computer, my prefs would leave a "scream loudly if you try to edit as an IP" cookie (expiring a few days or maybe a week after my mosr recent edit). Then when I'm logged out, it wouldn't be the small "Guess what, you were logged out" notice; it would be large and irritating and require clicking in six places and solving three CAPTCHAs and proving that you can divide by zero, or whatever it takes to get me to notice that I was logged out unexpectedly.
The first time was probably due to the Heartbleed bug, described above—a case of horrible timing. I don't know why it would have happened again, though. If it happens a third time, would you please post and let us know what your browser and OS are, and whether you've done anything about cookies that might make them suddenly disappear? Whatamidoing (WMF) (talk) 22:58, 9 April 2014 (UTC)
This happened to me several times yesterday after the change in certificates, and I reported it in #wikimedia-dev, where it was identified that it was affecting at least one other person in the channel at the time. Not sure there's much to be done about it - I caught it on enwiki but not all projects have the "you're editing logged out" message, so it's a nuisance. Risker (talk) 23:54, 9 April 2014 (UTC)
This is just guessing on my part but I suspect the login cookie invalidation didn't reach the entire server cluster at the same time. Your queries would reach an arbitrary server through some load balancing scheme, which means depending on which server you happened to get with a particular query, the cookie might work or it might not. I'd expect it will be sorted soon. 70.36.142.114 (talk) 04:25, 10 April 2014 (UTC)
Perhaps an explanation is found on Commons: Wikimedia Foundation servers have been updated since a vulnerability was discovered in the OpenSSL software. As a precaution, all Commons users were forced to log in again using new, secure version of the software. While there is no evidence of any breach of servers or loss of user data, the Wikimedia Foundation recommends that all users change their passwords to ensure maximum safety of their accounts.— Maile (talk) 11:58, 10 April 2014 (UTC)
Hand-shaped pointer instead of arrow
While reading arcuate fasciculus, I noticed that the arrow-shaped cursor had morphed into a pointing finger, while resting within the graphic image area, and also when the cursor is sitting on a URI. The arrow cursor remains on some pages, fortunately. I find that the pointing hand disturbs my reading, possibly due to its novelty. A cursory search of my preferences lists came up with no way I can see to reset the pointer back to the arrow. Can a less-exasperated editor guide me to the proper setting so I get back to my article? Thank you, --Ancheta Wis (talk | contribs)02:24, 10 April 2014 (UTC)
I'm just getting the usual wikilink finger on wikilinks themselves, nothing else (Firefox 28.0, Windows 8). I'm not sure what would be causing it for you, but it's not a global thing. Supernerd11:DFiremind^_^Pokedex02:31, 10 April 2014 (UTC)
To clarify, you see something similar to the one in this image when hovering over a link or image, correct? If so, that's the default for all links, so I'm not sure how you were getting arrows for links. ~huesatlum02:54, 10 April 2014 (UTC)
Apparently, it's hardware dependent: as you point out (pun intended), on a Windows 7, Firefox 28 box, I just found that it's a white hand, and it's a squished black hand for Chromebook/ Ubuntu Firefox 28, and there is no cursor at all on my tablet (using Puffin browser). So, if I want to avoid the cursor shifting shape while reading, I should stick to my tablet. To keep things looking the same across platforms, I should set my preferences to render the pages in desktop mode, rather than in mobile mode. --Ancheta Wis (talk | contribs)05:04, 10 April 2014 (UTC)
If you wanted to change it just on Wikipedia, you could custom css (the 'cursor' attribute); and perhaps using a Firefox addon you could change it across all websites. But it wouldn't be easy. - Jarry1250[Vacationneeded]11:38, 10 April 2014 (UTC)
@Ancheta Wis: Actually, it's fairly easy in Firefox. You just need to add this: a {cursor: default} into a new file located at "...\mozilla\firefox\xxxxx.default\chrome\userContent.css". If that doesn't make sense, try glancing through this guide (I've used the 1st example given in step#3 for many years) or this overview of the feature. HTH. –Quiddity (talk) 18:51, 11 April 2014 (UTC)
Wikimedia Traffic Analysis Report - Wikipedia Page Views Per Country - Trends
I don't know whether this is intentional, whether it is related to the recent typography change, or whether it is just because of my browser (Firefox 28.0), but for some reason the diff view on the English Wikipedia doesn't show yellow and blue highlighting anymore for me, making it hard to identify small changes in big paragraphs. On other wikis (I've tried Commons and the Dutch and French WPs) it still looks how it used to. Are there more people experiencing this, and does anyone know why? SiBr4 (talk) 13:12, 10 April 2014 (UTC)
It does that to me sometimes, too; I think it's just when the page doesn't load all the way (I sometimes can't use Twinkle, various scripts don't work, etc as well). Most of the time, reloading the page fixes it. Supernerd11:DFiremind^_^Pokedex14:14, 10 April 2014 (UTC)
I think I know which issue you are describing, though that's a different problem. In this case it showed the sidebar, user menu and page preview correctly, but the diff view lacked the colored boxes and highlights. This happened with every diff page I viewed this morning and stopped suddenly (maybe because of the page move I did this afternoon?) SiBr4 (talk) 15:40, 10 April 2014 (UTC)
template "ihwu" is useless
This board is for general technical issues of Wikipedia. Your renaming request for this specific template should be discussed at the template's talk page. De728631 (talk) 18:23, 10 April 2014 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm trying to rename template {{ihwu}} to {{ihw18}} (women's national under-18 ice hockey team) because "18" is the only category of women's youth ice hockey. So, the template {{ihwu}} is useless. In men's ice hockey similar "u"-template doesn't exist. There are following youth templates:
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
And now she's (I'm) regretting having done this. She (I) can't use English Wikipedia now, because every time she tries to (I try with the account called Sky6t, more precisely), the page would refresh to http://www.guokr.com/ :(
For the record, Zeroto/Sky6t: you could just disable the JavaScript in your browser temporarily, remove that code, save and then enable JavaScript again. Helder.wiki13:59, 11 April 2014 (UTC) PS: I needed help with something similar in the past (the save button disapeared after I edited my CSS... ).
Template:Winners problem
Template {{Winners}} is not applicable to youth national teams. Because it works like this: {{winners|sport|title|nation|opt. number of title|opt. flag variant}} and the youth teams need one parameter more, e.g. fbu|20 (for men's under-20 national football team) instead of fb (for men's national football team) So, I want to edit the template by this style (but I don't know how): if the sport-parameter is fbu or fbwu or bku or bkwu then use this variant {{winners|sport|age category|title|nation|opt. number of title|opt. flag variant}} instead of the default one. Can this be achieved? Who can help me? Maiō T. (talk) 16:22, 11 April 2014 (UTC)
Why not just add a fbu-20 version for the sport instead of adding a new parameter? (this can of course be expanded to any age bracket or sport) — {{U|Technical 13}}(t • e • c)18:21, 11 April 2014 (UTC)
@Technical 13: fbu-20 ... and what next? Men's fbu-19, fbu-18, fbu-17, fbu-21, fbu-23; women's fbwu-19, fbwu-18, fbwu-17, fbwu-21, fbwu-23, and almost the same number of templates for M & W basketball and possibly the other sports, too. Tens of templates. No, no. Maiō T. (talk) 19:19, 11 April 2014 (UTC)
To discuss map markers, see: "Talk:National_Constitution_Center" where the evidence is growing that some older browsers (IE7, IE8?) have the map marker shifted lower ("south") when the "caption=" is specified in {{Location_map}} (but not for captions in other map templates). We especially need users with access to IE7 to compare results and note which OS+browser versions (such as Windows Vista+IE7) have trouble with the map marker shifting one or two lines lower near the bottom of a map. Previously, a marker's div-tag needed "line-height:0" but perhaps other styles should be used to prevent the optional caption div-tag from shifting the marker lower in some browser. Discuss here or there, to keep the discussion going from year to year until solved. I will be gone for hours now. -Wikid77 (talk) 20:04, 11 April 2014 (UTC)
Globally logging in
How do I log into one WMF account (say, Wikimedia Commons) from another (say, Wikipedia)? I'm not sure whether it's the network I'm stuck on doing it or something else, but sometimes I get the "Please reload the page to automatically log in" message, and sometimes I don't and have to manually log in (which for whatever reason the login screen is always blocked, but most of the rest of Commons is hit-or-miss about whether I can get on or not). I've looked a lot in the View/Manage Global Account, but haven't been able to find a workaround. Does one even exist? Supernerd11:DFiremind^_^Pokedex23:32, 6 April 2014 (UTC)
Interesting question. You have a global account so moving from one project to another, you should automatically be logged in, at least most of the time. It may be something in your personal browser setup that prevents this from carrying over. Risker (talk) 23:43, 6 April 2014 (UTC)
@Supernerd11 and Risker: This has actually been happening since the implementation of SUL2. Sometimes you are automatically logged in. Other times not logged in. Also if javascript is disabled in your browser, you will have to manually log in. --Glaisher[talk]12:26, 12 April 2014 (UTC)
Template parameters
I'm trying to add two parameters to {{Infobox mtgset}}, but when I do, nothing changes. I've tried adding them both in the /doc page and the template page, but to no avail. I'm not very experienced with templates, and I've never done anything with the underlying code of them before, so could someone with a little more success offer some advice? Supernerd11:DFiremind^_^Pokedex02:45, 9 April 2014 (UTC)
Here's what I would do. Scroll to the bottom of the page and click to create a sandbox version of the template, then copy the whole template to the sandbox and add your changes there. Then click to create the testcases page and try using the new sandbox version of the template {{Infobox mtgset/sandbox}} there. Does that help, or do you need more detailed instructions? – Jonesey95 (talk) 03:45, 9 April 2014 (UTC)
@Supernerd11:, just in case, i think it might be worth it to always purge when testing templates. I've recently had an issue of having changed a template, forgot to purge, and the tests i've made were misleading because of that. -- Jokes_Free4Me (talk) 17:05, 9 April 2014 (UTC)
Another question: I've got the infobox to display the new parameters, but I'm not sure how to do a custom header. Is there a way to input a header at each page you need it? (There's "First set in the Innistrad block", but as far as I know, there's no way to have it go by order of the blocks). Supernerd11:DFiremind^_^Pokedex17:41, 11 April 2014 (UTC)
A certain user Cush asked this more vaguely above but I wanted to know specifically, do we have a moratorium? (A WMF employee reverting the disabling of the update on de.wiki "to give users time to try it out" would suggest that we do.) And if we do, how long is this time period?
If (or when) this discussion gets locked ideally I would like it to be by a member who is not a salaried employee of WMF. (The amounts of COI in all of this are alarming as it is.) Neitrāls vārds (talk) 22:26, 9 April 2014 (UTC)
Well, I'm neither salaried nor an employee, so perhaps I'll ask my question: Why on Earth would you expect this discussion to be locked? Is that common at the other projects you've worked on? It's rare at the English Wikipedia, and it's basically never done by WMF staff (unless there are lawyers involved).
As for what a sensible waiting period would be, it kind of depends on what your goal is. This kind of thing, even if it works exactly as designed for your computer, is a shock for a lot of users. Everything is different when the font changes. If you want people to have a fair opportunity to get over the initial shock and to make a thoroughly informed decision (e.g., to see how it works in tools they don't use very often), then the general rule of thumb for this type of change (on any website) is that you'd need to wait at least two weeks or so for daily users (longer for others). If you want to know more about first impressions, then of course you need to have the discussion immediately. So the real answer is that when to have the discussion depends on your goal. Whatamidoing (WMF) (talk) 23:19, 9 April 2014 (UTC)
Erm, Whatamidoing (WMF), why are you posting with a username restricted to WMF staffers if you are claiming you are not a WMF employee? Risker (talk) 23:42, 9 April 2014 (UTC)
Because, according to their user page, for the next couple of months, [they're] a part-time independent contractor for the WMF. Prkbably not a road that's necessary to go down. Writ Keeper⚇♔23:51, 9 April 2014 (UTC)
No, I think it is; in fact, Whatamidoing is a contract employee right now, and has been speaking on behalf of the WMF for months. If WAID wished to speak as an individual, then the right thing to do would be to log into their personal account and respond with that. Instead, they're using their WMF account to give the impression they're not a WMF staffer. It muddies the waters to use an account only granted to WMF employees (including contract employees) and then say they're not an employee. It's spitting in the face of the user who asked the question, it devalues the restriction on granting of accounts with the (WMF) suffix, and it seems that WAID is actually giving a personal opinion, which should be done with the non-WMF account anyway. Risker (talk) 00:04, 10 April 2014 (UTC)
As another WMFer, and one using his volunteer account, "spitting in the face of" seems a wee bit hyperbolic. Yes, WAMID made a mistake; those tend not to be cleared up with hyperbole. Moving swiftly on... Ironholds (talk) 01:42, 10 April 2014 (UTC)
Actually, Risker, I'm not an "employee" at all; I am an independent contractor, and that's not just a distinction that matters to the tax authority.
IMO if any editor is worried that such a reasonable question might be "locked" by WMF staff, then it is perfectly appropriate for any WMF staff who happens across it to point out that this particular worry is misplaced. If you'd seen it before I did, then I think you would have said much the same thing, because what I said is a factual description of the WMF's policy, not a personal opinion: WMF staff members don't "lock" community discussions, except under rare orders from the lawyers. Neitrāls vārds need not worry about that. Whatamidoing (WMF) (talk) 04:21, 10 April 2014 (UTC)
@Whatamidoing (WMF) "locked" was just the first thing that came to my mind to refer to the pale purple background and the message The following discussion is closed. Please do not modify it. that a couple of discussions above have been wrapped in. So, 2 weeks, that's something to work with. I do wonder after this period how the success of this update could be gauged? A call to all those voting to restore to give their opinions of whether they've grown to like it (and vice versa)? Perhaps an unobtrusive yet noticeable site-wide message (I think color:beige does wonders in this regard, if you ask me) because I think it is surprising how many people have found this vote given that you have to navigate through 2 pages between here and clicking the "Community portal." Quickly scanning I saw 2 "restore" votes by people wearing glasses (I wonder if this is representative of the general population) I suspect, however, that there may be more who we haven't heard from.
@Risker, the (WMF) kind of does give it away, if I say so! Well, at least there's an estimate of how long the "try out" period should be, now only "gauging its success" remains a question. (Strictly, if you ask me, an "Increase text size" menu item or better yet "A A A" (like pretty much any other site offering accessibility options) should have been the way to go. The latter being (at least initially) compatible with any script as physics and chemistry symbols, for example, are universal across languages.) Neitrāls vārds (talk) 04:45, 10 April 2014 (UTC)
I think this is a great idea. It's T26739 (T50946 for mobile).
Neitrāls vārds, I've got no connection to the Typography Refresh work, so I don't know everything on their minds. I haven't heard of a specific date, so all I can tell you is that two weeks is the industry norm for this type of change. I've also not heard of any plans to do user surveying. That could mean that there are no plans, or it could mean that there are plans that I don't know about. Speaking for myself, I believe that quick, simple surveys should be used for every user-facing deployment, and that dissatisfaction that is sustained beyond a reasonable adjustment period should result in reversal (or at least a partial reversal). Whatamidoing (WMF) (talk) 15:16, 10 April 2014 (UTC)
As pointed out in the ticket, we already have a gadget to change the font size User:Edokter/FontSizer.js. In my opinion, we should not have controls built in for stuff like this, browsers support this well enough. 10000 controls does not a better site make. —TheDJ (talk • contribs) 10:31, 13 April 2014 (UTC)
Keyboard accelerator for "watch page" missing from tooltip while in edit mode
I noticed that the keyboard accelerator (alt-shift-w) for "watch page" is missing in the tooltip in edit mode. It's there in non-edit mode. Not really sure off the top of my head way to go about fixing it. I noticed it in Vector but seems to affect all skins. Help adding it would be a good thing. (The accelerator does work in both non-edit and edit mode.) Jason Quinn (talk) 02:06, 10 April 2014 (UTC)
Confirmed as missing in edit mode (Windows XP, Firefox 28, MonoBook); but for me, Alt+⇧ Shift+W does nothing in edit mode so its absence is valid. --Redrose64 (talk) 10:06, 10 April 2014 (UTC)
Oh. It does do something - it toggles the "Watch this page" checkbox - the "watch" tab is unaffected until the save goes through. --Redrose64 (talk) 10:08, 10 April 2014 (UTC)
It's now toggling the "Watch this page" checkbox for me too. Last night however it was not doing this. It was toggling Vector's watch star. I did it like 50 times before posting. Now I cannot get it to do that. I don't know how or why the behaviour has changed but it has. Jason Quinn (talk) 21:13, 10 April 2014 (UTC)
PS Do you know if these tooltips are handled by the skin code or by Mediawiki itself? It's noticed a couple other minor issues with these tooltips and I may have to file a bugzilla report. Jason Quinn (talk) 21:15, 10 April 2014 (UTC)
The access keys are defined in the HTML generator of the skin, and the tooltips are updated to show OS dependent metakeys using the function updateTooltipAccessKeys in the javascript file resources//src/mediawiki/mediawiki.util.js of the MediaWiki source code. —TheDJ (talk • contribs) 09:34, 12 April 2014 (UTC)
...and even if we didn't, our US datacenters are in Ashburn, VA; Tampa, FL; and San Francisco, CA...none of which are in the affected zones in the linked image. --MarkTraceur (talk) 22:22, 11 April 2014 (UTC)
For the a while now, Internet Explorer 11 does not remember that I logged in (even in a new tab after having done so previously). But when I click "Log in", it suddenly remembers that I am logged in. It shouldn't be a cookie issue (cookies are always allowed for wikipedia.org and wikimedia.org), or related to the "Heartbleed" bug (problem existed before it was discovered). I even reset the browser to its default settings, and am still seeing the same behavior. Any thoughts? Niagara Don't give up the ship01:24, 11 April 2014 (UTC)
For more information, please see thread above. And this on Commons: Wikimedia Foundation servers have been updated since a vulnerability was discovered in the OpenSSL software. As a precaution, all Commons users were forced to log in again using new, secure version of the software. While there is no evidence of any breach of servers or loss of user data, the Wikimedia Foundation recommends that all users change their passwords to ensure maximum safety of their accounts.— Maile (talk) 12:24, 11 April 2014 (UTC)
I'm not sure how you got to wikidashboard.appspot.com from the English Wikipedia. When I went to Indian general election, 2014, clicked on "View history" and then clicked on "Revision history statistics" it opened this link to the article info tool on WMF Labs, which timed out and gave an internal error. I didn't see any links pointing to appspot.com. What steps did you take to get to the link you posted, and why are you concerned about it? — Mr. Stradivarius♪ talk ♪10:17, 11 April 2014 (UTC)
Is there some way I can turn off the Education Program article log so when it changes it won't be displayed on my watchlist? I seem to get a lot of them and it just clogs up my already overflowing watchlist. Example: (Education Program article log); 21:54 . . Southern Playerlistic (talk | contribs) removed themself as reviewer to article Piracy in the 21st century worked upon by Johnb742 as part of course Education Program:California Maritime Academy/Information Fluency in the Digital World (Spring 2014) Thanks, —dainomite22:54, 11 April 2014 (UTC)
I'm pretty sure I've seen a (succinctly-named) template that generates a blank/empty {{flagicon}} of usual proportions etc – but haven't managed to guess what it is or track it down. Help, please..? Sardanaphalus (talk) 03:56, 12 April 2014 (UTC)
An empty {{flagicon}} does the same thing. These templates work differently ({{flagicon}} adds a blank image, while {{noflag}} adds an empty span box), but look about the same:
How can I localize the File Upload Wizard to one of the sister Wikipedias? The current wizard there is Special:Upload, which should be replaced by File Upload Wizard. Especially, I need to know that how to activate file upload wizard in MediaWiki:Sidebar/toolbar. If so, I can look after rest of the work. I have enough rights there to take necessary action. Can anyone guide me on this?--AntonTalk06:46, 12 April 2014 (UTC)
Until a week ago, CodeEditor (the default editor for module pages, I understand) behaved a bit strange, like only randomly showing the layout with line numbers as advertised. Now since a few days, sometimes it folds the edit box at page opening into invisibility. That is, when the edit screen has been build up, there are only the top and bottom boxes. I must have done something wrong, but I have not ventured into setting changes AFAIK. At least I'd like to go back to the default settings, to have something stable & useful. Any suggestions? Any more info needed? -DePiep (talk) 19:16, 11 April 2014 (UTC)
i do not see the problems you describe. you can try and toggle "code mode" a couple of times on and off, by pressing the /* button - maybe it will kick it back to good behavior. other than that, unfortunately, i don't have anything. peace - קיפודנחש (aka kipod) (talk) 22:52, 11 April 2014 (UTC)
Clear cache & restart browser: For months, some users have noted garbled screens or lockups, and tried clearing cache with no luck at times; however, I think after deleting local cache files, a restart of a browser might clear the problems. In some cases, a few of the many thousands of CCS classes in use might be garbled in the browser cache files. It might help to think of the "Quantum Internet" like Schroedinger's cat, where webpages can exist and not exist at the same time, depending on how garbled the browser cache files are for various versions of the thousands of CSS classes in use. Remember, there are so many CSS classes, there is even one for class="center" among the many, many thousands which a browser might need to process, etc. -Wikid77 (talk) 00:07, 12 April 2014 (UTC)
Clearing the cache restored a functioning module editor, thanks (sorry I bothered you all without preparing my post with the obvious). What now remains is that the editor does not show the box with line-numbers layout (it shows plain text edit box). A convenience issue.
Now this happens: the wikEd icon (top-right) says in its title/mousehoover: Loading error - wikEd 0.9.124a G (March 08, 2014) Click to disable. Then:
When wikEd enabled, an edit click always gives the plaintext edit box (edit click = click the basic wiki "edit" tab).
When wikEd disabled, every second edit click produces the line-numbers layout (OK). If more systematic tests would clarify, please say so. -DePiep (talk) 10:52, 12 April 2014 (UTC)
Using Firefox 25.01 on OS 10.6.8, accented characters show up as bold and their kerning is off, both in headers and in ordinary text. Using Safari 5.1.10, only the kerning problem is visible if you look closely. See Japanese ironclad Fusō for an example.--Sturmvogel 66 (talk) 06:06, 12 April 2014 (UTC)
<includeonly>|</includeonly> can bloat the lengths of lines of (template) code significantly. Is there anything more succinct that can be used in its place..? Sardanaphalus (talk) 10:17, 12 April 2014 (UTC)
Yes, {{British Army Mounted Brigade/troops}} is a recent reminder. Apart from the bloat, though, I imagine multiple "<includeonly>|</includeonly>"s can make code look overly daunting to newcomers/novices, which is regrettable. (I imagine it did for me.) Thanks for your response, Sardanaphalus (talk) 11:40, 12 April 2014 (UTC)
If you write template documentation explaining the parameters and don't rely on the template page to be self-explanatory with automatically displayed parameter names then you can skip includeonly around the pipes. There are also many novices who don't know how to use an undocumented template where the template page displays "Ammunition Column, [[{{{ammun_hq}}}]]". PrimeHunter (talk) 12:19, 12 April 2014 (UTC)
[//www.google.com/searchbyimage?image_url=http:%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fb%2Fb6%2FChocolate_maccaroon_2014-04-13_00-25.jpg Google Images], which decidedly doesn't work: Google Images.
The Google search link is working fine for me. I'm seeing the Commons maccaroon picture in the Google search, which I presume is the correct behaviour. Maybe it's a browser cache issue? — Mr. Stradivarius♪ talk ♪16:14, 13 April 2014 (UTC)
Then {urlencode:} should inside {filepath:} and include the filename only, as only the filename needs encoding. — Edokter (talk) — 22:42, 13 April 2014 (UTC)
Your example Google Images only broke because you added an extra pair of //. Otherwise it works:: Google Images. As far as I can tell from experimentation, Google Images is forgiving and works both with and without the extra encoding. PrimeHunter (talk) 23:14, 13 April 2014 (UTC)
The TemplateData extension is still in development. The documentation states that sets are groups of parameters which are to be used together. I suspect that the intent is to list a group of parameters which would normally be presented to the user based on the user's selection of a type of sub-functionality from the template corresponding to the set name. Frankly, the documentation is not clear, and I am guessing.
You may find more helpful responses at Extension talk:TemplateData. However, given that you have started a thread then asking why the sets are no longer being displayed in the examples on mediawikiwiki:Extension:TemplateData, it appears you are already aware of that location.
@Sunpriat: Hello. Makyen is right, the sets functionality is not yet used in VisualEditor so we haven't documented it very heavily; the idea is to express how parameters go together, like "Longitude" and "Latitude" or "Year", "Month" and "Day. Jdforrester (WMF) (talk) 15:54, 14 April 2014 (UTC)
Endless Special:Search loop
Say I go to a page like User:Example 200, which doesn't exist. But I was actually trying to find someone with a much longer username I couldn't remember but had "Example 200" in it. Special:Search/User:Example 200 takes me in an endless loop back to Example 200. Another example: Windows xP. This is a simple grammar error. Special:Search/Windows xP takes you to Windows XP. But what if I was merely trying to search what articles Windows XP appears in? In a similar fashion, Special:Search/Windows XP also takes you straight to Windows XP without even an option to standard search it instead. KonveyorBelt22:02, 12 April 2014 (UTC)
It looks more likely to just be an innocent misunderstanding. I guess User:Spudgfsh doesn't know that {{replyto}} causes a notification – which happened when it was added, so deactivating it made no difference. PrimeHunter (talk) 19:34, 13 April 2014 (UTC)
Take a look at the before, it made the entire page invisible. All I did was try to make all of the page visible again. => Spudgfsh (Text Me!) 19:46, 13 April 2014 (UTC)
The edit [10] did no such thing. If the page was invisible for you at the time then it had another cause. For example, it's conceivable that a mistake was made in a template transcluded earlier on the page. Another time you can try a purge. PrimeHunter (talk) 19:55, 13 April 2014 (UTC)
When I delete pages, after a couple of seconds the tab I have the "Action complete" screen in closes itself, presumably using JavaScript. (For reference, latest Chrome on Windows.) Is this from some gadget I have switched on in my preferences? I can't work it out. It's pretty annoying. — Scott•talk11:44, 13 April 2014 (UTC)
The "action complete" tab didn't close for me just now when I deleted a page, so it's not a default thing, whatever it is. I'd check your browser add-ons first, followed by your gadgets. You can try disabling the add-ons, removing the gadgets, and bypassing your browser cache. That might help to narrow down the culprit. — Mr. Stradivarius♪ talk ♪16:22, 13 April 2014 (UTC)
Yeah. I can't imagine what add-on could be causing it (it literally only happens on that specific page on this website) so finding the culprit is going to be interesting. — Scott•talk17:22, 13 April 2014 (UTC)
The Africa Incubator has been redirected to a Museum page
Hello,
I am really hoping someone can help, and that I am at the correct place to ask this question. The WikiAfrica Incubator, which is a soft landing for newbie editors in Africa, has been obliterated by a redirect to an article about a museum in South Africa - the Montagu Museum (ironically, the article was originally created in the Incubator). I have checked the history hoping to revert it back to a previous edition, but for some reason all the logs for the home page of the Incubator seem to have disappeared; this is what I get when I go to the history of the redirect or the history of the page. I didn't think it was possible to do what this user did!!?
I have asked the original creator of the Incubator to help, but I am not sure how often he checks his email or userpage. The other pages do not seem to be affected, such as Help Desk and The step by step guide. Please let me know how I get the original WikiAfrica Incubator back? Looking forward to hearing from someone and finding a solution! Isla Haddow 15:00, 13 April 2014 (UTC)
further to posting the above, I checked my watchlist and found this "(Deletion log); 00:03 . . AnomieBOT III (talk | contribs) deleted page Wikipedia talk:WikiAfrica/Incubator (G8: Broken redirect to Montagu museum. If this bot is malfunctioning, please report it at User:AnomieBOT III/shutoff/BrokenRedirectDeleter)."
The problem was that the creator of the article moved the Incubator and then overwrote it, then on 30 March Orangemike incorrectly speedy deleted it, thus consigning the history of the Incubator to the trash. I've fixed it. — Scott•talk15:23, 13 April 2014 (UTC)
Scott•talk, you are amazing. thank you so much for doing that. Even given your explanation, I still don't understand as Lorinda did not create the Incubator, but it is back now, and I am a very happy person. Thank you! Isla Haddow 08:28, 14 April 2014 (UTC)
@Jokes Free4Me and Ancheta Wis: the use of {{wikicite}} is somewhat complicated; and in fact neither necessary nor desirable: notice the third and fourth paragraphs of its documentation - the ones beginning "This template is only needed for handwritten citations, or citations using non-standard citation templates ..." and "This template is not necessary if the citation uses a citation template ...". {{wikicite}} dates back to a time when {{citation}} etc. didn't create anchors within themselves.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
We are looking for contributors to help write new issues every week. If you would like to help, please contact us.
Recent software changes
The latest version of MediaWiki (1.23wmf22) was added to test wikis and MediaWiki.org on April 10. It will be added to non-Wikipedia wikis on April 15, and all Wikipedias on April 17 (calendar).
MediaViewer was enabled for all users on MediaWiki.org on April 10. It will be enabled for all users on the Catalan (ca), Hungarian (hu) and Korean (ko) Wikipedias and English Wikivoyage on April 17. Comments are welcome. [11][12][13]
You will now see only three options when you try to add a template parameter in VisualEditor; you will see other options after a click. [16]
The size changing controls in VisualEditor media editing dialog were simplified further.
The wikitext editor tab will now fold into a drop-down menu in the Vector skin if there is not enough space on your screen. [17][18]
Future software changes
The font used for body text on Wikimedia wikis will change to your system default sans-serif font. This temporary change will be enabled on all non-Wikipedia wikis on April 15, and on all Wikipedias on April 17. [19][20]
Files from Commons seen on another wiki will soon have a tab saying "View on Wikimedia Commons". The create tab will change to "Add local description" (see screenshot). [21]
An IRC discussion with the Wikimedia Foundation Multimedia team will take place on April 16 at 18:00 UTC on the channel #wikimedia-office on Freenode (time conversion). [31]
Problems
Wikimedia Foundation servers were updated after a security bug called Heartbleed was discovered last week. You should change your password as an extra precaution. [32]
Currently under preferences the max selectable thumb size in articles is 300px (the default being 250px ). On many of today's monitors that is not much larger than a postage stamp. Can we get that limit increased? Saffron Blaze (talk) 22:03, 20 March 2014 (UTC)
The default is 220px. Thumbnails are not ment to act as full size images; they are 'thumbnails' after all. Try the new Media Viewer beta. — Edokter (talk) — 22:25, 20 March 2014 (UTC)
Further, our non-free content policy, which uses low-resolution non-free images, would not allow for images to be displaed at much larger sizes. --MASEM (t) 22:28, 20 March 2014 (UTC)
Why the lecture as if I am an idiot? I know what thumbnails are intended to do. I am saying they too small to be of any use on high resolution monitors. It was fine when all we had was 1024x monitors but now the defaults are often higher than 2560x. Moreover I wasn't asking for full resolution images, just slightly larger thumbs so I could at least see enough detail to decide whether the image is even worth opening. As to the beta Media Viewer, how is that functionally different from clicking on a thumb? Even if I were to use the viewer I would still need the thumbs to be larger.
The issue of "fair use" is a red herring. I was not asking for the actual image to be larger just the thumbs in the articles. Moreover, there is no firm legal criteria on allowable resolutions for non-free content. The guidelines only mention that images should be rescaled as small as possible to still be useful as identified by their rationale, and no larger. The image size to respect this notion seems based on old criteria and predicated on lower resolution monitors. Saffron Blaze (talk) 22:53, 20 March 2014 (UTC)
In general, it is inappropriate to assume any particular window size. You are applying what is typical for you and desiring to push it onto everyone viewing a particular article when doing so might make the article look much worse to them than the inconvenience of having a relatively small thumbnail image is to you. When adjusting this sort of thing on an article it is a good idea to view the page in a window which you can resize to a variety of widths so you can find a compromise which is reasonable for everyone. Further, keep in mind that a considerable amount of WP readership is now on mobile devices which tend to have a much smaller number of pixels available to display content.
As an example of going the other direction, the mw:Typography refresh recently was intending to force all MediaWiki projects using the Vector skin to a maximum page width of 715px. Upon getting negative feedback, they relented. This is intended as an example to indicate that opinions vary greatly as to the "proper" size of the window to view anything. The reality is that we should adopt page layouts which look acceptable under a variety of conditions. — Makyen (talk) 23:55, 20 March 2014 (UTC)
I am not doing any such thing and I would appreciate people stop talking out of their arse. If you go to your preferences and select appearance then look at the file options you will see an option to select your preferred thumb size. Default as pointed out is 220px. The max you can select for yourself is 300px. This is the size you will see when a hard pixel size is not included in the wiki code for a thumbnail. These smaller resolutions were fine on lower resolutions monitors, but is becoming inadequate now with QHD and 4K monitors. I asked that users be able to select a larger thumb size for themselves... NOT everyone else. Saffron Blaze (talk) 00:39, 21 March 2014 (UTC)
I'm not sure I understand the problem here: On QHD/4K Monitors you would have to scale up the text anyway (otherwise it would be much too small to read). If you scale up the text your browser should also scale up the thumbnails for you (if it doesn't maybe check you browser settings). Therefore the thumbnail is shown much larger than 220px, even if the setting you mentioned is kept at it's default. Therefore problem solved, isn't it? Since the images have defined a srcset HTML attribute you won't just see an upscaled image but an actually a higher resolved version therefore even gaining quality. --Patrick87 (talk) 01:43, 21 March 2014 (UTC)
Your inability to understand the issue makes it seem clear you won't have the answer yet I am confronted with another patronizing response. The assumption in your response is wrong. I don't want the text to get larger, I just want the thumbs to be larger. Saffron Blaze (talk) 04:31, 21 March 2014 (UTC)
Text sizes are normally given in points, not hard pixel values. Hence, for text, a properly-configured system should use however many pixels are needed for the text to appear at the desired size. E.g. 12 pt text should appear at a height of about 1⁄6 of an inch. However, image sizes are given in pixels. The same number of pixels are used regardless of resolution, so the physical size of the image is smaller at higher resolutions. Zooming is not a solution, since it also affects the properly-sized text. – PartTimeGnome(talk | contribs)22:52, 22 March 2014 (UTC)
First off, I do apologize, I certainly misunderstood what you were asking about.
However, I strongly suggest that you step back and assume good faith on the part of other editors. In response to three different editors you have come back with a response that has a belligerent tone and indicated that you believed the editors were "lecture[ing] as if I am an idiot", "talking out of their arse", or giving you a "patronizing response". Of the three, perhaps you could characterize what I said as "talking out of [my] arse", but it is much more productive to say something like "You appear to have misunderstood what I was talking about. I was referring to the personal preference available from the Appearance tab in your Preferences."
As a side note, you might find it beneficial to ask a more generalized question about how others deal with having small images on high resolution monitors rather than locking yourself into only thinking about one way to solve the generalized problem. There are a variety of methods to solving, or at least alleviating, the problem. — Makyen (talk) 06:04, 21 March 2014 (UTC)
If all people ever do is lecture about things they don't even understand it gets annoying and frustrating. People spend more time in telling people why they are wrong than actually helping. It's the power culture here at WP. I am just tired of it. Thanks for another useless lecture that serves nothing other than to bolster your own ego. Your suggestion does not address my concern nor help me in any fashion. Saffron Blaze (talk) 10:42, 21 March 2014 (UTC)
Makyen, you were clearly talking out of your a**. "Under preferences the max selectable thumb size in articles is 300px ... Can we get that limit increased?". This is not regarding MOS, not regarding how it displays with others, and it is definitely not related to window size (except as it is related to the screen's absolute maximum). The question was clear. The initial answers were well out of left field. PrimeHunter's answer below is much more useful. — Crisco 1492 (talk) 11:33, 21 March 2014 (UTC)
Saffron, I understand your annoyance. Replying without understanding the question is a frequent problem when discussing technical matters. However, venting off at people who get it wrong is not constructive. It deters others who might be able to help. Politely saying that a response is unhelpful and discussing why is better; if you can get someone to understand the issue, there's still a chance they could help. Even where they can't help, there could be others who didn't understand at first who could assist once given further explanation. – PartTimeGnome(talk | contribs)23:22, 22 March 2014 (UTC)
I was hoping it would deter others from spouting wiki-isms and nonsense, as is all too frequent. I am indeed glad PrimeHunter wasn't scared off. Then again, he knew what he was talking about. Funny how that works. Saffron Blaze (talk) 23:36, 22 March 2014 (UTC)
Bugzilla:11118 - "Allow larger/user-specified thumbnail sizes" was closed as WONTFIX in 2008, apparently based on this 2007 statement by Brion Vibber: "That's not likely to happen; we'd prefer to reduce the number of available thumbnail sizes to save on bandwidth, cache, and thumb disk space."
Bugzilla:27839 - "Offer 460px and 620px as thumbnail size preferences" was a request for the French Wikipedia. It was first accepted but later reverted in 2013 by Antoine Musso as WONTFIX with the statement "The original request can not be fulfilled, that will cause too much stress on our caching and storage infrastructure. I have reverted the original fix with: https://gerrit.wikimedia.org/r/51182". That says: "Having different thumbnails sizes per wiki is not something we can properly support right now. Our cache and files infrastructure will end being filled with thumbs which are barely used beside on the french wiki."
Bugzilla:41712 - "hewiki asks to change default image sizes for thumb and gallery" was not about the maximal options but also had some relevant posts.
The English Wikipedia is the largest but perhaps a suggestion for larger thumb options should be at meta: and linked at other wikis? The max of 300 appears to be older than 2007. That seems like a long time considering the development in screen resolutions and storage prizes, but the number of files is growing and I don't know the involved costs. PrimeHunter (talk) 11:27, 21 March 2014 (UTC)
Since the new "Media Viewer" is being developed (which will requires the creation of a whole lot of new Thumbnails anyway) and srcsets are used as stated in my "useless and patronizing" answer above (that means thumbnails are already generated at sizes of 330px and 440px as alternatives to the standard size of 220px and similarly at 1.5x and 2x the size of the other selectable thumbnail sizes) I think in principle a big number of cached resolutions should already be available and storage space / RAM seems not to be that much of an issue any more. I think it would be important to choose the sizes wisely though (so the already cached versions can be reused and as few new thumbnails as possible need to be created/cached) and all projects should use the same values. However larger thumbnails require a lot more of space, maybe that's the reason many small sizes but no large sizes are available. --Patrick87 (talk) 15:58, 21 March 2014 (UTC)
Before bitching at you I tried the media viewer. It does nothing until you click on the image. What I was hoping for was to see the article itself illustrated with larger images. If I wanted larger images by clicking I can get that already. Perhaps I am missing something as the viewer is beta, but if the viewer is intended to provide larger thumbs at some point that would indeed meet the aim. Saffron Blaze (talk) 22:54, 21 March 2014 (UTC)
Blaze Saffron, I am trying to understand the issues you are raising. I offer my personal setup and experience with a section in one of the oldest WP articles, scientific method#Overview, specifically the Galileo image in the Overview section. The markup is in old-fashioned style, from about 10 years ago.
[[Image:Galileo.arp.300pix.jpg|thumb|150px|According to Morris Kline,... ]]
If I edit the wikilink so the width of the thumbnail is 450px, After clicking 'Show preview' I get the article, with Galileo embedded in it, but with Galileo's image increased in size (similarly, Galileo decreases if I edit the width of the thumbnail to, say 50px).
Is that what you are trying to accomplish for viewing on your hi-resolution display?
On the secondary monitor, the article is 22.5" wide, with Galileo's image width 2.4" wide when viewed with defaults.
My current secondary monitor is 24" diagonal, about 22.5" across, and 12.75 " high. The displayed resolution is 1366x768. I can view the secondary monitor without strain or magnification, while leaning back in my chair, a viewing distance of 48". The primary monitor is 11.6" diagonal, 10" across, about 5.6" high (a Chromebook, but I am running Ubuntu on it). I can read Wikipedia without strain on the Chromebook (I do lean forward when viewing the Chromebook), but the secondary monitor is essential when trying to read the details in stopped videos, for example.--Ancheta Wis (talk | contribs)00:34, 22 March 2014 (UTC)
Ancheta Wis, In the example you provided the markup has a hard pixel size of 150px. That is very unfortunate as it forces me to view that image at the forced size despite using a WQXGA+ monitor. If you remove that hard pixel size then people will see it at 220px unless they change the default setting in their preferences. A user can increase their default thumb size is to a max of 300px. On any monitor at QHD or above, that 150px image is but a tiny bit of colour and even at 300px it is barely acceptable, especially for landscape oriented images. I would find my reading and viewing of articles more rewarding if the thumbs were more like 400-450px. So, you essentially described the effect I want to achieve, but I don't want it done through hard pixel sizes as in your example (using hard pixel sizes is actually frowned upon in the WP MoS and image use policy). Does that answer your question? Saffron Blaze (talk) 04:21, 22 March 2014 (UTC)
Coming back from above, non-free images are not a red herring in this discussion. People reduce non-free to no more than 300px - for the most part - because no thumbnail presently can go above this size. If we increased the max thumbnail size that people would select, this would encourage (not via policy) for people to reduce only down to that size, which harms the free content mission and our fair use defense should that ever be challenged. Yes, free imagery doesn't have this problem but the max thumbnail size is irrespective of works being free or not. So there is more to this than just making WP look better for people with large monitors. --MASEM (t) 04:42, 22 March 2014 (UTC)
Actually "fair use" is anathema to the free cultural works movement because by definition "fair use" imagery is not actually free. That's why it is not hosted on Commons where "free to use" is taken literally. Regardless, I think your concerns over "fair use" image size is unwarranted when you see what sizes news media orgs use when applying "fair use" doctrine. The case law does not support your position as well. You are looking to restrict people's enjoyment and access to this project over the boogey man in the closet and we all know the bogey man does not exist. Saffron Blaze (talk) 18:10, 22 March 2014 (UTC)
It's not just "fair use" issues, it's our non-free policy. We are specifically more stricter than fair use so that we stay fair outside the point where the legal defense of fair use could be possibly challenged. One example is stressing we use smaller images to avoid our fair use taking from being too large and/or impact the commercial value. Thus why NFCC Policy is related to the thumbnail max size since we're not going to want to store images that are much larger than that. This is a mandate from the Foundation so this is not a boogeyman to worry about but part of the limitations that the Foundation has set for non-free use. --MASEM (t) 18:28, 22 March 2014 (UTC)
Even the strict image use guidelines for non-free content places the lower end at 320px and discusses images up to 1000px. Suggesting 300px is the upper end is not only wrong it is detrimental to the project. Saffron Blaze (talk) 18:55, 22 March 2014 (UTC)
I never said the max image size for NFC can be 300px, but that 300px is generally the max size because 1) for nearly all original media, this size is of sufficient reduction to be okay by fair use, and 2) the max thumbnail size is 300px and we shouldn't be uploading pics of normal aspect rations that go much above that. --MASEM (t) 19:24, 22 March 2014 (UTC)
Oh for crying out loud User:Masem, I can see why Saffron is frustrated when met with such responses. As you say, our restriction on non-free images is to ensure they are not detailed enough to have commercial value. This applies to the image we host, not the size as it appears on the user's display. If the underlying image is restricted at 300px, say, then displaying it as a thumbnail at 400px involves basic digital enlargement the same as someone using the Zoom feature on their browser, and not dissimilar to just moving their nose closer to the monitor, neither of which breaks any copyright laws. There is no fundamental reason why the fair-use cap cannot remain at 300px while the displayed thumbnail is 2 or 3x that if desired. If current guidelines/practice have conflated thumbnail size with free-use max then that is trivial to rectify. Let's not create imaginary obstacles.
While the web has moved forward towards recognising differing display abilities, Wikipedia has not advanced. I've not been impressed with the beta features and had to turn them off. I see more and more editors using hard pixel sizes and ignoring the standard thumb. This stores up a problem that is not trivial to fix. If the default/max thumb does not increase with technology then editors will find a way round it, and do, to the detriment of users stuck with older tech in the third world, say. Better that editors could choose small/medium/large for thumbnails and leave the user's preferences to sort it out (or better still, adaptable per display). Many of use use different monitors at various times. I have an 1920 x 1080 display on a laptop, a measly 1280 x 1024 at work, a super 2560 x 1440 in my study, a lowly 960 x 540 on my phone and 1920 x 1280 on a tablet. If storage/memory-use is an issue for caching (and I suspect it is less of an issue than it used to be) then fewer choices are the answer -- it should be straightforward to get stats on which sizes are widely used. Larger sizes aren't just a cosmetic issue -- the richer an image we can display the more our educational mission is served. A map or diagram with more readable legends, a building with more detailed features, a face with more character. Really, this is a discussion about a decade past its date. -- Colin°Talk19:38, 22 March 2014 (UTC)
I'm not complaining that a thumbnail that is scaled from a 300px to a larger size is a fair use issue. But what can happen is that if we do allow a larger size of thumbnail for all images, people that use the larger size, let's say, 450px will upload non-free thinking their image size is fine considering this thumbnail policy. And then others will follow to upload at this size, even though 300px is just fine otherwise. I won't deny that this argument alone is a potential slippery slope in considering the non-free aspect only, but it is a point in conjunction with the other arguments against the size increase (including the server limitations for thumbnails) to keep 300px as max. --MASEM (t) 20:52, 22 March 2014 (UTC)
I contend that your basic premise and concern that non-free content only be uploaded at 300px is baseless and bankrupt and not predicated on anything but a guess and a wave of the consensus hand. It has no legal standing and is not part of any policy statement from the WMF. However, I am willing to be proven wrong so I brought this issue to the WMF legal via Meta. Saffron Blaze (talk) 22:53, 22 March 2014 (UTC)
Again, I never said the maximum size a non-free could be uploaded is 300. But 300px is a good size to encourage uploaders to reduce their works to via the fact that thumbnail can never go larger than that (if no other size parameters are given), and thus better keeps us within the issues of fair use. There are certainly plenty of places for >300px non-free, but the issue I'm point out that we can maintain the average (this typically being covers of published media) at ~300px by noting that thumbnails max out there. If you increase the maximum size of thumbnails readers can set, that could potentially drive editors to upload at higher resolutions and that starts putting us more at risk, espcially when most art doesn't need to be at that size (per WP:NFCC#3a non-free should only be used at the size that is necessary.) --MASEM (t) 22:59, 22 March 2014 (UTC)
It is NOT a good size. 300px is too small. 400px or even 500px sizes are still small enough to respect fair use doctrine and they will not break the bank, particularly if they are being generated for the media viewer anyway. Saffron Blaze (talk) 23:27, 22 March 2014 (UTC)
(edit conflict) There seems to be a level of FUD about this argument to keep the maximum thumbnail size at 300px. It seems daft (to me at least) to impose such a major restriction out of fear and speculation that others could get thumbnail sizes mixed up with our non-free content policies. Even if they did, it can be fixed in the usual wiki way: upload a new copy of the image at a smaller size then delete the old version, while giving the original uploader a talk page message explaining why the original image size was inappropriate. – PartTimeGnome(talk | contribs)23:39, 22 March 2014 (UTC)
I tend to agree. Sorry Masem, but of reasons not to allow for larger thumbnail sizes in preferences, I do not find the NFCC argument compelling in the slightest. Resolute23:51, 22 March 2014 (UTC)
First, I am not trying to say "no we can't increase the thumbnail size above 300 px only due to NFC.", because as you've misintepreted what I've said, NFC does not have a hard limit, but we strongly encourage the 300px limit as a natural balance of the max available thumbnail size presently, and the nature of WP's policies to keep non-free use to minimum take and avoid endangering commercial opportunities. What I've been saying here is that considering the suggestion to increase the thumbnail size, the issue of NFC should be considered along with the stronger issues regarding the WMF's choice to keep thumbnails small to prevent stressing servers.
Second, this is not FUD. We presently are in no danger of any legal issues with NFC, but that's because we tell people to keep images small. If we suddenly had thumbs at, say, 500px, and suddenly 500px was commonly used for NFC uploads, we probably wouldn't be in any legal trouble but we are going against the Non-Free Resolution to minimize non-free use (as defined by policy). And of course, what happens when the next big screen resolution comes in and we want to get to 700px or higher? Remember, DVD resolution is around this size, so a screenshot at this size would be no longer respecting commercial copyright. This is why 300px is naturally a decent size to aim for for NFC images - for nearly all standard images one can imagine that would fall under NFC, this is far from challenging the commercial opportunity. Yes, even if we had 700px non-free images, the rest of non-free would help to be our fair use defense (education/transformation use, single images or frames, etc.), but this weeks how strict our NFC has been.
Yes, we could always fix uploads that are larger than 300px back down (we have a tag and category for that) , but one has to realize that non-free imagery, one of the few areas that the Foundation requires us to be proactive in, is woefully under-admined. This would be more work for us.
But again, I stress this is like the second or third reason to not change the thumbnail size, with a lot more weight on the first, primary argument of the stated server issues that would happen with larger sizes, given above. That factor has to be overcome first, before we talk the effects on NFC. --MASEM (t) 02:44, 23 March 2014 (UTC)
You keep stressing something that four other people have told you is baseless. Your concern has been weighed, measured in pixels and found wanting. Now, if server load is truly an issue I am sure someone will chime in and that will be that. However, as pointed out earlier, with media viewer development the availability of the larger thumbs may render both your concerns mooted. If that is the case then those same thumbs should be made available to those not using media viewer through larger pixel preference choices for thumb sizes on article pages. Saffron Blaze (talk) 03:04, 23 March 2014 (UTC)
BS, I have to refute the misstatements others are making on what I am saying (like the claim that I said the max NFC size was 300px, which I never said). And any change that has the potential to affect NFC handling has to be considered because this is mandated policy by the Foundation. It doesn't need to be determined now, but if you somehow get the Foundation to allow that change to thumbnail size, then we have to review that change in the NFC framework. That's all I'm saying - there are tied issues in this but they don't come into play until you have the larger thumbnail size possibility. --MASEM (t) 03:16, 23 March 2014 (UTC)
What you said was using thumbs larger than 300px would counter our non-free content usage guidelines and bring legal risk to the project. As a consequence it should be a factor is not allowing people to select larger thumb image sizes in their preferences as it would encourage people to upload non-free content at larger sizes. We understood you perfectly and found your rationale and concerns unfounded. Moreover, there is no "Foundation" policy that dictates image size for non-free content use. I invite you to prove me wrong on this issue. Regardless, the sizes being considered would never invoke the kind of concern you seem to be harboring. What stands as a guideline has been continually debated and subject to interpretation by the community for years. People use WP differently today than they did 10 years ago. They need choices to deal with all the various ways they access WP content. The old tired guidelines you keep espousing, if they actually exist, are not fulfilling that aim. Saffron Blaze (talk) 06:49, 23 March 2014 (UTC)
What I am saying, Masem, is that the NFCC argument is not even valid. There is no argument to be made at all to limit images sizes - and therefore limit Wikipedia's usability - due to an imaginary problem. Particularly given the basis of your argument: A non-free image at 500px would still be smaller, relative to users on high screen resolutions today than one at 300px was at what was a high resolution in 2007. This point is simply irrelevant to me. The question of bandwidth and other technical limitations is really the only one that should be persuasive here. Resolute03:14, 23 March 2014 (UTC)
Masem, if I didn't know you better, I'd say you were trolling. Several people have told you your argument is baseless. You've created an imaginary concern. Please drop it. If you don't, I suggest others treat Masem's concern as though he were trolling (which I'm absolutely not saying he is) and ignore it. It is not helping this discussion by creating a huge timesink irrelevance. Masem, if privately you still think your concern has any weight whatsoever, then please go chat with WMF legal and come back when the argument has some backbone. -- Colin°Talk10:05, 23 March 2014 (UTC)
I've been involved in the NFC area for the last 6 years - I know there is an issue here that is not obvious if you don't spend time in that area. It is not a direct legal concern but it does involve the Foundation's free content mission and how we have practiced that through NFC for the last 6 years since that Resolution was stated (And perhaps even earlier since en.wiki's NFC policy was the basis for how the Resolution was made). To restate, we don't have a hard (server or policy) px limit for non-free content, but we strongly encourage non-free images to be no larger than 300 px because with the 300 px max thumbnail, there's no reason to upload higher resolution images, and 300px is a good size that assuredly makes sure our fair use taking of commercial and copyrighted works stays small for the bulk of available copyrighted media. That is, we ask people to aim for about 0.1MP in image size (per WP:NFC). We obviously allow larger sizes, but higher resolutions require a justification in the non-free rationale about why the image needs to be that large. But I'd guess that right now, about 90% of our non-free images are tuned to the 300px/0.1MP size range. Should the max thumbnail size become 500px, and we make no change on what non-frees we have, we are either going to have the case that non-free images would be scaled up to 500px from their current size (which could make them blocky-looking), or that they would be fixed at a max size of 300px and appear small against all all free images. For the same reason this change was suggested - that on monitors with large resolution that the images look tiny - I can foresee a demand to increase the target non-free file size to 500px - doubling the number of pixels from 0.1MP and 0.2MP. For most non-free this is still probably nowhere close to tipping the fair use, but the issue becomes "where will this end"? What if people want 700px thumbnails (in general)? That's 5x increase in pixel count from 300px thumbs, roughly, and approaches the default size of many visual works.
Let me restate this is another way: should the thumbnail size increase, you cannot expect non-free images to follow. We are still going to aim to keep images around 300px/0.1 MP because that is a "right size" that balances all aspects, and still the thumbnail size that the majority of readers will not exceed. So as long as those that go to 500px understand that non-free will not follow, then there's no issue. But if you are expecting non-free policy to allow higher-resolution uploads to meet this new larger thumbnail size, then there's a major issue that has to be resolved.
I'm absolutely not trolling about this - this is a serious issue for non-free policy has it has been practiced. --MASEM (t) 15:31, 23 March 2014 (UTC)
Actually, even if you remove the whole issue of thumb sizes, your concern and adamant belief 300px/.1mb is the right size for NFC is also wrong and baseless, but this isn't the venue for that. Saffron Blaze (talk) 17:09, 23 March 2014 (UTC)
Masem, would it help if I said I was in no doubt that the maximum thumbnail size has no link whatsoever to acceptable sizes for non-free content? I would not expect any tolerance of larger non-free images due to a change in thumbnail sizes. I'm also not sure it's a good idea to encourage non-free uploads at 300px – they should be uploaded at the smallest size that allows them to be of use in the relevant article(s). For many images, this could be less than 300px. – PartTimeGnome(talk | contribs)23:28, 23 March 2014 (UTC)
Resolute, restricting the pixel size of non-free images is about restricting the amount of detail in the image, not their size relative to the monitor. (We can't do anything to restrict their physical size; people can easily zoom in.) – PartTimeGnome(talk | contribs)23:28, 23 March 2014 (UTC)
There is a non-direct but important connection between thumb sizes and how've handled non-free reductions due to the fact we encourage and/or require scaling to no larger than the largest possible thumb size to minimize non-free particularly those higher resolutions where it would not be used. As long as it understood that we at NFC will continue to encourage and enforce the 300px/0.1MP size regardless of how big the thumbnails for free images may go, then we're fine and the matter is nothing else. --MASEM (t) 23:50, 23 March 2014 (UTC)
It was nothing to begin with but your insistence has highlighted another problem not related to the OP. You have made it so abundantly clear that a baseless guideline at NFC is making a mockery of fair use doctrine. Its overly restrictive nature serves nothing other than someone's arbitrary belief. I will have to see about addressing that as well. Saffron Blaze (talk) 02:42, 24 March 2014 (UTC)
Clearly you aren't clear how important and the goals of NFC policy here. It is two fold: one: to encourage free content over non-free content and meet the free content mission, and two: to keep us as far from possible from tripping over the fair use defense in what non-free we offer. Size is a critical importance, because one aspect of fair use is to respect commercial opportunities, and thus reducing images to ~300px/0.1MP easily avoids treading on that. The combination of these two are summarized in NFCC#3b as well as the Foundation's resolution to minimize non-free taken. This is has been the case for 6+ years if not longer. This is why this is all connected to the thumbnail, because, as you are imply, you're going to be asking for larger NFC images to be used, and that will not fly. --MASEM (t) 02:56, 24 March 2014 (UTC)
Sure it will. If you build it they will come. Did you really think 300px as a guideline would last forever? It is not even founded in any case law. It's just a 7 year old wild ass guess made by a very small crew of involved editors. Certainly well meaning but getting out of date. Saffron Blaze (talk) 21:10, 25 March 2014 (UTC)
Can I suggest the discussion about max thumbnail size be rebooted void of any concerns about Fair Use image size thresholds. Let's discuss how best images can be displayed on Wikipedia articles given the variety of display sizes available to users. The opening suggestion is that for logged-in users, they should be allowed to set preferences higher than 300px. At present, there is no suggestion the default or the size used for non-logged-in users be increased. I think offering a higher threshold for preferences is a reasonable step. However, I'd also like the software to consider display size to offer some intelligent rendering. That surely is the best option when one may flip between a 100dpi 17" display at work to a 250dpi 9" tablet or a 220dpi 27" display at home. One thing I don't know is whether the page caches all thumbnail sizes available, or just those actually requested. If the latter, then my guess is that the choices used by logged-in users are a drop in the ocean compared to normal readers, and thus of little concern wrt hardware resources. -- Colin°Talk10:05, 23 March 2014 (UTC)
I see a lot of uncertainty in the sections above and little facts or context that matters. As can be seen from a few of the bugzilla tickets linked above, there are some technical considerations here. I'll try to explain:
The request of a higher default thumb size has been uttered quite a few times before. The foundation itself (or the designers it employs) have also shown interest in higher resolution thumbnails.
We need to remember that any thumbnail that is generated is a file that needs to be stored on a disk. The more available thumb sizes for users, the more files. This is also why the sysadmins don't want to cause too much more divergence between the different sites. There is a lot of diskspace, but that is no reason to 'waste' it.
To change default thumbsize for everyone, we are talking more than just a configuration change. To do so instantly would mean that the thumbnail servers need to render a file for almost every single image viewed just after the switch. This would significantly impact the stability of the website. As such sysadmins would have to do a staged switch, which is much more labor intensive
Regarding the beta media viewer. Yes this will result in a lot more thumbnails and it is a concern that is being taken into account with the design of the media viewer. The current thinking is that likely it is going to be something like size bucketing. That means that there will be a preselected set of sizes that the MMV will always use, regardless of your window size, and will simply use browser downscaling at the client size from a size that is 1 step larger than your window size requires.
Bucketing will possibly (or is already ???) used by the mobile website for the same reasons.
There is a chance that this bucketing technique will also be used for thumbnails in the normal website. Experiments need to show first though what are suitable sizes and if the quality of this process is not going to have too much of an effect on users.
There has even been some discussion if the 'buckets' should be pre rendered (even before the first user requests the image).
Most of all, as might be obvious from these points, this is not something you can 'do' at the English Wikipedia level, since it affects the infrastructure of all Wikimedia wikis to such a high degree. So the place to get this done is as always on wikitech-l mailinglist and of course the assortment of other places (mostly IRC and Mediawiki.org) where the developers and sysadmins operate and expect the progress to be SLOW, up until the time where there is a reason for WMF to allocate time and resources to the problem. —TheDJ (talk • contribs) 11:30, 23 March 2014 (UTC)
As far as I can tell, 300 has been the largest option at nearly all wikis since at least 2007. There must be many registered users who chose that long ago and caused generation of lots of 300px thumbnails for images used as thumbs with no size specification. If the default for everybody was changed from 220 to 300 then wouldn't that greatly reduce the server load right after the switch? Or maybe the default could be increased at different times for different wikis. I don't know whether that would require other sysadmin work than changing wgThumbLimits in InitialiseSettings.php more than once. PrimeHunter (talk) 12:10, 23 March 2014 (UTC)
True, but how do we get from here to there. I am not bugzilla literate enough and the process from idea to resolution is not clear. If I drop in over there with my wishlist they will likely see me as a fly buzzing in the room. Saffron Blaze (talk) 17:16, 23 March 2014 (UTC)
I suggest we take the opportunity given by the work on the Media Viewer / UI enhancements to improve thumbnails at the same time as their other features. If you read the feedback, the #1 problem is that it is too slow (the main reason I turned it off) and they are looking at caching. If they can cache large screen-filling images then there is no reason they can't cache smaller (or downsize from those rather than the original, as suggested above). The media team, despite getting some things wrong, do seem to be trying to improve WP's visual experience and considering multiple display issues. Talk to those working on these beta features, and see if they can raise a bugzilla report that won't just be ignored. They seem to like "user stories"
"As a WP reader, I want the article thumbnails to display appropriately for my screen size/resolution, so that I get the maximum detail visible while not overwhelming the article text."
"As a WP editor, I don't want to have to hard-code thumbnail size in order to ensure the detail on my map/diagram/photo is legible to most viewers." -- Colin°Talk11:12, 24 March 2014 (UTC)
Hey Colin. Thanks for looking into the Media Viewer development. I'm working a bit as a community liaison for Media Viewer's release. I hope you can contribute thoughts to developing that product. While Media Viewer deals with rending the image after you click on the thumbnail for a better visual experience, the development of Media Viewer is unrelated to how thumbnails are displayed on-wiki in terms of size. The only real interaction is with caching, as you noted. By all means continue on with the conversation about default thumbnail sizes here, on wikitech-l, bugzilla, or the many, many other places this conversation has taken place. However, it will have little to do with Media Viewer. Pardon the interruption :) Keegan (WMF) (talk) 21:21, 25 March 2014 (UTC)
which has (1) only five sizes being cached and (2) one size larger than what's currently available here? (The exact numbers could be adjusted based on Mobile's needs, etc., but the idea should be clear enough.) WhatamIdoing (talk) 16:25, 27 March 2014 (UTC)
It's mostly arbitrairy anyway. But you raise a good point. MediaWiki already support srcset for images, being used for 1.5x and 2x pixel aspect ratios. That means that for every thumbnail size, MW will also need to cache every thumbnail size three times. In case of a 220px image, an additional 330px and 440px version, and so on. So picking a few smart values to minimize caching would be a good idea, in which case: 150, 225, 300, 450. — Edokter (talk) — 21:31, 27 March 2014 (UTC)
Apologies if I am being daft, but you indicated earlier MWV had nothing to do with thumb sizes other than caching. So why would I want to have a conversation about thumb sizes at that multimedia list? Saffron Blaze (talk) 23:14, 29 March 2014 (UTC)
The multimedia list is not restricted to discussion about MWV. It is for discussion about all software that deals with multimedia (images, audio, video, etc) on Wikimedia sites. This includes the thumbnail support in core MediaWiki. – PartTimeGnome(talk | contribs)21:16, 30 March 2014 (UTC)
Although that is correct, given that there are ops related concerns to this issue, wikitech-l may still be a better venue than multimedia list. Bawolff (talk) 03:42, 9 April 2014 (UTC)
Ok, thanks. I must have misconstrued the front page's discussion of MWV. That said I can't see myself engaging again on this topic elsewhere. Trying to effect change on WP is just a recipe for grief and frustration as this episode only reiterated to me. Saffron Blaze (talk) 23:54, 31 March 2014 (UTC)
I've noticed that some sites are doing a strange thing where they write different code for Retina display browsers than others.[33] I can't help but feel that this is back-assedwards; if they want to break their web browser why should the developers have to write special code to fix it? Nonetheless, desperate for hits, it seems some do. Without suggesting any excessive degree of accommodation, it does provide an argument for letting thumbnails go bigger, I think. (I haven't actually done this coding though) Wnt (talk) 17:39, 1 April 2014 (UTC)
According to Certificate Patrol on my browser, several Wikipedia SSL certificates have been replaced. That could indicate that they were vulnerable and had to create new certificates. --cesarb17:57, 8 April 2014 (UTC)
Aye, we were vulnerable and have updated everything. We don't have any reason to believe we were compromised but as a security precaution we're going to be invalidating user sessions as well ( see wikitech-ambassadors email ). They are recommending people reset passwords but I don't think it's being forced right now. Jalexander--WMF21:13, 8 April 2014 (UTC)
@Magog the Ogre:My understanding is that all of the certificates were replaced earlier (last night I believe?) working under the assumption that they were compromised (there is no way to tell) but I will ensure that is correct. Jalexander--WMF02:09, 9 April 2014 (UTC)
@Jalexander:It seems that is not the case as of right now: [34] The *.wikipedia.org cert was issued in 2012 (or at least, that's the cert I'm seeing on https://wiki.riteme.site/ right now). Are you sure all of the certs have been revoked and reissued? --NYKevin19:41, 9 April 2014 (UTC)
I see the same wildcard certificate, dated 10/21/12. However, http://filippo.io/Heartbleed/ indicates that the server has been patched. So if the certificate was compromised in the past, there is a possibility of a MITM attack, but sessions are now supposedly secure against passive eavesdropping. 70.36.142.114 (talk) 21:33, 9 April 2014 (UTC)
@NYKevin:@Magog the Ogre: Sorry for the time it took to respond. I did confirm that we replaced all of the star certs. The reason you aren't seeing it (and neither are the tools to check the vulnerability) is that while the private/public keypair was changed (and hence the fingerprint) the 'not valid before' date remained the same (Oct 21 2012). For better or worse we don't have any choice over the matter, that's what our vender does when replacing certificates and so the only way to verify that it is different is to have a copy of the finger print from before the change. Jalexander--WMF22:32, 9 April 2014 (UTC)
From what I've read, one of the "features" of this bug is that exploitation leaves no traces in logs (see http://heartbleed.com/, under "Can I detect if someone has exploited this against me?"). Would a password reset for anyone with advanced privileges (>admin) be in order? MER-C02:53, 9 April 2014 (UTC)
From what I understand, the probability for this happening in our infrastructure is so implausible as to basically be considered impossible (without us having noticed). Users are being forced to re-login (as sessions are far more vulnerable) but passwords should be generally secure. (Of course this doesn't mean that you shouldn't change your password, especially if it's one you re-use on another site that may or may not already be patched against the vulnerability) ^demon[omg plz]04:49, 9 April 2014 (UTC)
It looks like the https pages are being served with a non-PFS cipher suite, which should be considered a weakness in its own right, that should be fixed. It means among other things, that passwords can be recovered from old recorded traffic, if the server private key was captured using heartbleed. I think of the types of entities capable of recording large volumes of old Wikipedia SSL traffic, and think 1) yes it's likely or at least plausible that they did it, and 2) they're not that likely to actually use the passwords, they want the data for other purposes. Overall I'd say don't panic, but yes, go ahead and change passwords. 70.36.142.114 (talk) 07:23, 9 April 2014 (UTC)
I believe there's research to suggest such practises reduce overall security. Also we're talking about an encyclopedia, not nuclear launch codes. Bawolff (talk) 17:15, 9 April 2014 (UTC)
Yes, it sometimes reduces overall security. People will cycle through the same set of passwords or make only minor changes (let's see, I need to change the password every quarter, must have a number and a capital letter, I can't reuse any of the previous three... Hmm, how about 1stQuarterPassword, 2ndQuarterPassword, 3rdQuarterPassword, and 4thQuarterPassword?). Also, because there is normally no warning when passwords are being reset, they pick something that they can think of quickly (Quick, I need a new password, um, um, Coffee! I'm drinking coffee right now! Okay, how about "Coffee1"?), without thinking about how secure it might be. Whatamidoing (WMF) (talk) 19:09, 9 April 2014 (UTC)
At Commons I saw the message
Wikimedia Foundation servers have been updated yesterday after a vulnerability was discovered in the OpenSSL software. As a precaution, all Commons users were forced to log in again using new, secure version of the software. While there is no evidence of any breach of servers or loss of user data, the Wikimedia Foundation recommends that all users change their passwords to ensure maximum safety of their accounts.
But it did not have any discussion link. Where to discuss this issue? Plus, a couple of months ago, they forced us to change password, again today we need to change password. It becomes very difficult (specially if we have to make changes in alll websites with same password) --Tito☸Dutta16:59, 9 April 2014 (UTC)
Note that this does feel like something we need a watchlist message for on en.wiki, as long as we can point to a WMF recommendation on what they did (eg any changed passwords now are after clearing the bad SSL libraries). --MASEM (t) 17:36, 9 April 2014 (UTC)
A couple of notes about the Commons sitenotice: a) it was added by a user there, not by WMF; and b) if you look in the edit history it's implicitly quite clear that WMF don't intend to escalate to forced password changes. ("based on their risk assessment, the WMF Ops & Platform teams don't consider notification via sitenotice essential"). That said, there have been at least two occurrences where passwords were force-changed; once in 2013, noted above, and a slightly weirder one in 2007 where a number of admin accounts were hijacked in very rapid succession and some other vulnerable ones were reset. Andrew Gray (talk) 09:41, 11 April 2014 (UTC)
Forced password change = end of my volunteer services on this site. Recommending is one thing, and strongly recommending for admins and higher is certainly in order... but forcing it? - Floydianτ¢18:01, 9 April 2014 (UTC)
Nobody is being forced to do anything. If you're not afraid of losing your account, feel free not to do anything :) It seems that the chance of anyone's account being actually compromised is rather minute. Matma Rextalk18:10, 9 April 2014 (UTC)
The only thing forced is that they cancelled all current sessions and are forcing you to relog in with your current password to refresh the session with the new SSL certs that avoid the heartbleed bug. It's a situation that every security effort is recommended the change but clearly no one is forcing WP editors to reset their passwords. --MASEM (t) 18:13, 9 April 2014 (UTC)
And even if they did decide to force you to change your password, why would that necessitate the end of your volunteer services on this site? If a website is forcing you to change your password, it's probably because there's a high likelihood that your password has been compromised, and therefore it's in everyone's best interest to change your password. ‑Scottywong| comment _18:41, 9 April 2014 (UTC)
I thought Floydian was reacting to the mention of a policy used by some corporations, that requires periodic password changes whether there is a suspected breach or not. IMHO for a site with really high security requirements, password-only authentication is a weak practice in its own right, and two-factor authentication should be required. At that point the password changes become less useful, so the practice can be considered obsolete. 70.36.142.114 (talk) 20:53, 9 April 2014 (UTC)
No, I'm just opposed to the idea that, for example, I need a number and uppercase letter in my xbox live password while my bank account is a four-digit number, no more, no less. I am responsible for my own security. If my account gets compromised, it is my fault, and website have no (zero, 0, zilch) liability in such a matter. By being forced to use various passwords, change them on a timely basis, or follow rediculous rules that determine my 20 lower-case letter password as "weak", I get to write passwords down on paper or on a computer file so I can remember all the damned things. I do not want wikipedia to go this way (and am relieved that it is not), and my protest against it, if it were to happen, would be to walk away after 10 years and nearly 30,000 edits. - Floydianτ¢00:12, 11 April 2014 (UTC)
Even if you're really willing to re-imburse a company for any expenses they incur in dealing with your compromised account (e.g. the spam), it's unlikely they'd have a process in place to accept it for many reasons including the fact that few people would be willing and regardless of the legal issues, it just doesn't make business sense to pursue people for most such costs. Not to mention I'm not sure how you'd even calculate the costs? (Calculating the costs could easily cost more than the costs themselves.) And let's not forget it could easily extend beyon the company itself. If your twitter, email or whatever account is compromised and you spam malware, a number of people, including people you don't even know could end up being affected, how you plan to work out what you're responsible and compensate them, I'm not particularly sure.
For that matter, it's unclear to me how you plan to compensate the volunteers and possible staff who may deal with any mess from your compromised account.
In other words, while you may have a point that such rules sometimes create more problems then they fix and are unfair to users of whatever service involved, your idea you're assuming all liability is just silly. No, when some account of yours is compromised you can be fairly sure someone (depending on the severity, plenty of people) will incur some cost from dealing with it which you won't compensate them for.
(In fact a funny related point, I don't know if you program and if you do, whether you are involved in any open source project. But let's say you are, if your account in some project is compromised, someone using your account submits or commits some dodgy code which lasts for 2 year and when it's found puts 17% of secure servers on the internet at risk. What sort of liability are you planning to assume in such a case? Zero because you'd have no liability (as you shouldn't) if you had intentionally submitted the code? And to be clear, this isn't a criticism of the people who submitted or committed the code involved in such a bug. Simply pointing out the idea you can magically assume all liability or that there would even always be agreement on what you should assume is highly flawed and that even if you did and there was agreement, it may not negate the negative effects from your compromised account.)
Yes, that would be affected by the same bug. That said, as discussed above, the likelihood that your password was intercepted by someone likely to misuse it doesn't seem high. Changing your password is recommended as a precautionary measure but it's a more important issue for advanced permission holders. If a normal user account gets compromised it's not a big deal--it gets blocked, bad edits are reverted, some effort is made to return control to you if there's a way to authenticate that you're the real owner, or in some cases you may have to enroll a new account and abandon the old one—not that big a deal in the scheme of things. 70.36.142.114 (talk) 22:12, 9 April 2014 (UTC)
Superscript numbers are going onto the next line of text
I have noticed a problem with superscript note numbers (references). Sometimes, when a superscript is at the end of a line of text, it is being pushed to the beginning of the next line of text, disconnecting it from the word it refers to. It looks like this:
The sky is blue. [1]
This should not be happening. A note number, like a quotation mark or period, should always be attached to text. Has anyone else noticed this problem? I usually use Firefox on Windows 7. --Albany NY (talk) 16:30, 14 April 2014 (UTC)
This can happen if there is white space between the note and the characters preceding it. See WP:REFPUNC for an explanation of where references should be placed.
If you have an example or a screen shot of an actual article that exhibits this problem even after it has been formatted to conform to REFPUNC, please post that information here. – Jonesey95 (talk) 18:09, 14 April 2014 (UTC)
Actually this is a problem that only happens in Internet Explorer as far as I know. Given there is no space in between (as Jonesey95 suggested), other Browsers (e.g. Firefox) keept text and reference together at this point. I'm afraid there's not much we can do about this on our side. This needs to be fixed by Microsoft. --Patrick87 (talk) 18:20, 14 April 2014 (UTC)
I don't have an example with a single reference, but this is maybe related: on Mechanics, there are three references together in the lede. If I change window size to 'push them over the edge', "Archimedes" and "[1]" stay together, and "[2]" and "[3]" stay together, but there will be a line break between "[1]" and "[2]". No idea if that's intended, there's nothing suspicious in the html. I'm using Firefox 28.0 on Ubuntu, Monobook. — HHHIPPO20:42, 14 April 2014 (UTC)
Excellent example! I can replicate your experience: I can make markers 2 and 3 jump together to the next line, but I am unable to make 3 jump by itself. I am also unable to make marker 1 separate itself from the word the precedes it. Firefox 28, Mac OS, Vector (with the typography opt-out). In Safari 6.1.3 for Mac OS, the markers always stay glued to the preceding word. Does anyone know the intended behavior here? – Jonesey95 (talk) 21:03, 14 April 2014 (UTC)
Each footnote marker is separately generated by Cite and there is no markup or styling that would keep them from wrapping. As best I see, it is browser dependent. I don't see any way to span a sequence of footnote markers. --Gadget850talk21:27, 14 April 2014 (UTC)
Using IE11 on Win7 with Monobook skin, I find that the "[3]" jumps, then the "[2]", then the "[1]", in case that helps. DH85868993 (talk) 21:34, 14 April 2014 (UTC)
It seems that IE is allowing linebreaks between each <sup>...</sup> pair, while FF keeps at least two of them together (or one together with the preceding word). I agree that generating html that forces the wanted behavior on all browsers would not be feasible, so it's up to Microsoft to fix IE or up to the users to pick their browser. Interestingly, FF even keeps each tag pair together in edit mode. — HHHIPPO22:26, 14 April 2014 (UTC)
That's unrelated IMO, the HTML strangely ends the list and starts a new paragraph, although i can't understand why, considering that the "getsurrey1" ref seems to be ok (no leading white-space)... -- Jokes_Free4Me (talk) 03:01, 15 April 2014 (UTC)
That newline before the last <noinclude> is the culprit. Either join the <noinclude> to the immediately-preceding }} (see the paragraph just after the bulleted list at WP:NOINCLUDE) or remove the empty <noinclude></noinclude> pair completely. --Redrose64 (talk) 07:10, 15 April 2014 (UTC)
Here's an example from Firefox 26 in Windows 7: File:Footnote problem.PNG. I have added information about the problem in Chrome and IE 11 on Windows to Jokes Free4Me's very useful chart. Is there anything Wikipedia can do to fix this problem? --Albany NY (talk) 16:43, 15 April 2014 (UTC)
Math text: PNG bug or MathJax feature?
Today I had a little problem with a math \text{ } construct when viewed in PNG. I had to make this change to make it work in PNG. No problem in Mathjax. Breakdown:
Syntax
Rendered
Behaviour
\text{ignore}
works in PNG and MathJax
\text{ignore 1/R}
works in PNG and MathJax
\text{ignore 1/R^2}
Failed to parse (syntax error): {\displaystyle \text{ignore 1/R^2}}
While I can see it on the (pre-reverted) page in question, I find that I cannot see any Mathjax rendering in the table for the first three options on Firefox 29. Maybe that is why it is pushing an error. — trlkly23:11, 14 April 2014 (UTC)
I noticed some poor spacing on the WikiCon banner under the monobook skin today. There appears to be no whitespace between the bottom of the banner and the page title, which makes the title harder to read and just doesn't look good. Is anybody else having this issue? I encountered the problem while using the latest version of Chrome on a Windows 7 computer. Novusunatalk23:47, 14 April 2014 (UTC)
Like that banner, I don't think this is really very much padding. The margin on the banner seems to be 1px and 0.1em, which is even less. Wnt (talk) 04:58, 15 April 2014 (UTC)
The padding shouldn't affect it. The spacing between the banner's border and the heading immediately below should be based upon their margins; see "Box dimensions" in the CSS 2.1 spec. --Redrose64 (talk) 08:19, 15 April 2014 (UTC)
Nice trick. I have added &useskin=vector to your Vector link so it also displays in Vector for users with other skins. PrimeHunter (talk) 22:58, 15 April 2014 (UTC)
I have long kept as one of my toolbar favourites my user edit counter. For past few weeks it appears to be unreadable and I notice the edit counter statistics tool (under View History page) is inaccessible. Obviously it is not just me affected, but I do miss having ready access to the pie chart and the tally of articles edited that this kept. (Inconvenient when you want to mention editorial 'milestones' on your user page. I am in the 2000+ bracket.) Is there another tool in the offing or available?Cloptonson (talk) 20:03, 15 April 2014 (UTC)
Once in a while, Popups does make it look like you're seeing oversighted revisions, for different reasons, but you're not really. This thread pops up here a lot. Jackmcbarn (talk) 19:51, 16 April 2014 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Thread retitled from "Oversighted revisions still visible via Popups".
I don't know if this is a huge leak or a caching issue, but I have found that oversighted revisions are still visible via Popups. (NOT telling how for the moment.) Who do I contact to address this? — Edokter (talk) — 15:21, 16 April 2014 (UTC)
Bugs with security implications should be reported to security(at)wikimedia.org or filed under the "Security" product in Bugzilla. says it right at the top of the page... I haven't been able to reproduce this, though; you sure? Writ Keeper⚇♔15:35, 16 April 2014 (UTC)
I mailed them already (I asked on IRC). There are certain steps you need to follow to reproduce the bug, but I'm not telling here. — Edokter (talk) — 15:47, 16 April 2014 (UTC)
Okay, cool. I'd suspect it's a cache thing, unless you have some pretty crazy steps, but the experts'll handle it one way or another. Writ Keeper⚇♔15:52, 16 April 2014 (UTC)
Tested another borwser; no leak there, so cleared the cache, and the info was gone. I thought Popups doesn't cache. — Edokter (talk) — 17:31, 16 April 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The caption parameter hasn't been assigned, at least not this month, but you added a second empty caption parameter.[36] The last assignment of a parameter overrides any earlier assignment so I guess you only assigned the first in preview. PrimeHunter (talk) 19:26, 16 April 2014 (UTC)
I received my first geonotice today, but sadly an incorrect one. Problem seems to be that my window.Geo object is broken, but only on my Watchlist page. It looks like this:
Our MediaWiki:Geonotice.js code reacts badly to this. It seems the Geo object was created this way by https://bits.wikimedia.org/static-1.23wmf21/extensions/CentralNotice/modules/ext.centralNotice.bannerController/bannerController.js which has code in there to create the Geo object from a cookie, which for me is "GeoIP=::::v6;" Reproducible on the Watchlist, but on this page here the Geo object is correct. Clearing the domain cookies (and logging back in) does not change the situation, GeoIP cookie is set again. I've stopped looking farther than this. The "v6" makes me assume this is an IPv6 issue, but I've used IPv6 for a while now and noticed this for the first time today so I'm guessing there was a recent related change? Amalthea23:49, 16 April 2014 (UTC)
@Amalthea: Our geolocation provider does not support IPv6. Our Geonotice.js indeed did not handle this particular situation well, but this change should at least make sure that you don't get to see an incorrect geonotice if we don't know the coordinates. P.S. the Geo object comes from: this script and can be cached with a cookie by central notice, but the watch list notice does not depend on the central notice cookie. —TheDJ (talk • contribs) 13:19, 17 April 2014 (UTC)
Table formatting
I have an image and some text in one row of the table I'm creating at List of Eurasian Nuthatch subspecies. It looks a mess. I can force the text above or below the image using break, but ideally I would like it neatly to the left (or the right, doesn't really matter). I don't want to create another column for the image because there will only be one more in the whole table. I'm sure this is possible, but I don't know how to code it. Thanks Jimfbleak - talk to me?09:10, 17 April 2014 (UTC)
You can float it on the right by using |right| - that is, instead of [[File:Sitta europaea -Kent, England-8.jpg|100px]] use [[File:Sitta europaea -Kent, England-8.jpg|right|100px]]; similarly |left|. More at WP:EIS. --Redrose64 (talk) 09:21, 17 April 2014 (UTC)
@Jimfbleak: I would assume other images will follow, later, so it's best to have a separate column. Please consider using a table for each row (and another for the header). You can see an example at {{Horse stats table row }}. That moves the table markup out of the article, making life easier for other editors. With care, such tables can be made generic, and used on other "list of subspecies" articles. It's also possible to make each row emit metadata - I can do that for you; just ping me, or do so if you need help with the tables themselves. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:33, 17 April 2014 (UTC)
@Pigsonthewing: I've used an extra column previously in other tables, and it would be easy enough to do that. Realistically though, we have images for the two subspecies that are widespread in Europe, and most of the others are very restricted in range or occur in Central Asia and Siberia. I'd be surprised if we ever get an image for most of the others. Incidentally, I looked in the Japanese and Korean Wikipedia articles for Eurasian Nuthatch, and even they use images of the European forms Jimfbleak - talk to me?12:53, 17 April 2014 (UTC)
Checked my browser to see if I'd somehow disabled javascript - it's still active. I'm out of ideas now, bring on the technical geniuses... Yunshui雲水10:21, 17 April 2014 (UTC)
Everything is working on my end. Try clearing your cache or disabling all gadgets and scripts one by one. — Edokter (talk) — 11:02, 17 April 2014 (UTC)
Interestingly, it's also proving impossible to save any changes to the Gadgets tab - I can uncheck boxes easily enough, but after saving and going back in, they're ticked again. Does seem to be Chrome specific; leastways everything still seems normal in Firefox. Yunshui雲水11:48, 17 April 2014 (UTC)
Yesterday, around 16:00 UTC, I enabled Preferences → Gadgets "Navigation popups: article previews and editing functions pop up when hovering over links"; after a couple of hours, finding that the box kept getting in the way, I decided to disable it again. That took three attempts: each time that I went back to Preferences → Gadgets I found that the checkbox was still ticked. Firefox 28, not checked today. --Redrose64 (talk) 11:50, 17 April 2014 (UTC)
The latest version - Version 34.0.1847.116 m - is causing problems for other Chrome users, hopefully they will fix it soon. Dougweller (talk) 12:23, 17 April 2014 (UTC)
It's finally working for me now, over an hour after disabling gadgets and scripts etc. Thanks for that advice, but I'm not sure it was necessarily the answer, given the amount of time since then. Maybe a coincidence but the slow, slow loading speed has also suddenly improved for me. JG66 (talk) 12:58, 17 April 2014 (UTC)
This page, which is where you'd expect to find editors best versed in such matters, currently has several user sigs which do not meet web accessibility standards: unreadable small fonts, poor contrast between text and backgound, and so on - no to mention being garishly distracting to the general reader. Please consider whether your sig is a help or a hindrance to others; and set a good example to your fellow editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:41, 17 April 2014 (UTC)
Fonts too large in Opera 12.02
Hello. I am new to this, but just wanted to add a comment for the programming team that the recent font changes are extremely unpleasant. I'm using Opera 12.02 and the fonts look way too large. I never had a problem with the fonts prior to the recent change. I have tried multiple computers and still have the same trouble reading the Wikipedia entries.
As a temporary fix I have to set the zoom on the page to 90%, but then that makes the fonts too small. Even though small, I still find it easier to read than the current fonts.
Define "way too large". The font size has been effectively increased by one pixel with the typography update. — Edokter (talk) — 16:45, 17 April 2014 (UTC)
Page protection logs
Perhaps there is a more appropriate place to pose this question? On Sam Houston, these two edits put temporary page protection on the page. This edit removed it today when it expired. When you go into Page/Page Logs/Page Protection, the history of that page protection is not there. So, if page protection is required again - and it will be, as this is a high IP vandalism page - a sysop will possibly look at the protection log to see what went before, and they won't see anything before 2011. Why isn't the page protection picking up this recent log?— Maile (talk) 18:36, 17 April 2014 (UTC)
Sysops will see it. I think you're misreading the history a bit here. What happened is that, in January, Ged UK put the page on pending changes protection for three months, which is reflected in this edit. It's been three months since then, so the protection automatically expired today, without anyone intervening to "remove" the protection. Since the page is no longer protected, Cyberbot II came along and removed the "this page has been protected" template, but Cyberbot II's edit didn't (and can't) actually affect the page's actual state of protection; it merely reflected it. Ged UK's initial action doesn't show up in the protection log because, strictly speaking, it wasn't protection in the sense of either semi- or full-protection; it was pending changes, which is tracked in a separate log, here. The page protection interface, which is what admins use to actually protect things, displays both logs, so Ged UK's actions will still be visible to any admin seeking to protect the page, through either method. Writ Keeper⚇♔18:47, 17 April 2014 (UTC)
Not just Chrome this time. I'm using Firefox 28.0 and have lost Twinkle, browsing preferences e.g. open external links in new tab, edit link to top section, etc in the last hour. Was OK before that, same editing session, haven't adjusted anything on PC. Tried re-saving prefs but didn't make any difference. cheers, Struway2 (talk) 12:24, 18 April 2014 (UTC)
I've been noticing similar things too. It looks like there have been general problems with JavaScript today. Probably nothing to worry about unless it keeps happening or it happens for an extended period of time. — Mr. Stradivarius♪ talk ♪12:54, 18 April 2014 (UTC)
Edit link for the top section disappeared
Why has the [edit] link for the lead section gone? I checked, and the option Add an [edit] link for the lead section of a page in Preferences/Gadgets/Appearance is still checked. Btw, I noticed the old style of displaying diffs with the old yellow/green colors is also gone, despite me having Display diffs with the old yellow/green colors and design checked in Preferences/Gadgets/Appearance. What's going on here? -- ToshioYamaguchi12:26, 18 April 2014 (UTC)
Seems like your link to bits.wikimedia.org, which serves all the CSS and JavaScript, is not optimal. This usually resolves itself. — Edokter (talk) — 12:54, 18 April 2014 (UTC)
In recent times, I have been pondering the possibility of leaving Wikipedia. Not because I'm losing interest in it, but because I'm spending too much time here, mainly because diffs take a lot of time to load on my computer. To give an example, the page [37] took about 26 seconds to load. Fortunately, most load faster, but not that much. Since my watchlist includes several thousands of pages, I need a lot of time to keep up with everything that's happening to the pages that I'm interested in. What is to blame? My Internet connection? My Internet browser? My computer? Should I switch to AWB? Or is Wikipedia slow by default? Toccata quarta (talk) 16:58, 10 April 2014 (UTC)
Just a few seconds here as well. Toccata quarta, what part of the world are you connecting from? This might be a problem that can be dealt with by the Wikimedia technical staff, and such problems often depend on geographic location. For my part, things were very slow on Wikipedia for about an hour last night, I'd say about 8pm Japan Standard Time, but they have returned to normal now. And also, is this a one-off problem, does it happen all the time, or does it recur at certain times each day? This kind of information will help us and the tech staff to troubleshoot the problem. — Mr. Stradivarius♪ talk ♪18:22, 10 April 2014 (UTC)
I do not use popups and live in Central Europe. I clicked on the diff a few minutes ago and it took about 23 seconds to load. @PiRSquared17: thank you for the suggestion. The page loaded in about seven seconds. I will try out that setting. Toccata quarta (talk) 06:12, 11 April 2014 (UTC)
Browsers like Firefox or Google Chrome have a "Developer Tools" area which can display which parts of a webpage take how many (milli)seconds to load. Might be helpful to track down the problem. --AKlapper (WMF) (talk) 11:41, 11 April 2014 (UTC)
That would be "Display source", "Display page source", or something similar, for those who don't know. At the very bottom of the source you'll see something like what I saw: Served by mw1018 in 7.077 secs. —DoRD (talk) 12:12, 11 April 2014 (UTC)
@DoRD: That gives you how long the Wikimedia servers take to prepare and serve the whole page - it bears little relation to how long your browser takes to load the page and all of its components (images, CSS files, javascript etc.), which is what AKlapper (WMF) is referring to. In Firefox 28, bring down the "Tools" menu, where you will find a "Web developer" item, which leads to a submenu with a dozen or more options. --Redrose64 (talk) 15:22, 11 April 2014 (UTC)
I'm well aware of that menu, obviously, but I don't know which (if any) of the tools I have will show the total load time for a page. —DoRD (talk) 15:47, 11 April 2014 (UTC)
Try Tools → Web Developer → Network. With that enabled, clicking "[edit]" for this section has informed me that its 13 requests took 4.09 seconds to complete. --Redrose64 (talk) 17:52, 11 April 2014 (UTC)
It took 9s for me (Firefox 28) with no scripts and with some cruft adblocked. I remember having the impression there was a bug in Wikipedia's diff rendering code that could make it run slower than it should. I haven't had the time to investigate carefully though. 70.36.142.114 (talk) 18:08, 14 April 2014 (UTC)
When I first checked the category, there were well over 10,000 articles. I forget the exact figure; it may have been between 12,000 and 14,000. Now, there are 1,147 - an improvement of more than 90%.
I don't know what to do about the aliased parameters, other than make them consistent. I don't speak Greek: the main thing to decide is whether "clubs" means "σύλλογοι" or if it means "ομάδες".
Thx! Now are only 843 articles. I will wait untill tomorrow and I will tell you. There must be less than 100. Xaris333 (talk) 20:18, 16 April 2014 (UTC)
if I put the symbol → in front of the team to have →TEAM NAME ? The easy way was to write all the teams for the least again with the symbol in front of them [41]. But this is not good.
to do the same thing with a specific word in the end of the team name (after a single space)?
If you're using the template directly, you could just use →{{ft|team}} to prepend an arrow. Within the template you could also add an "arrow" parameter and put {{#if:{{{arrow|}}}|→}} before the {{#switch}} function, so an arrow can be added using {{ft|team|arrow=yes}}. This is handy if you want to use the template indirectly, such as in the infobox you linked to. A more general {{{prefix}}} parameter is also possible.
Looking at the template code, I think you want the team name with suffix to be piped to the team article. That could again be done as an additional parameter, but that will break the template on pages using the name with suffix as first parameter, putting them in the new tracking category. If that's not a problem, the syntax for the pipe link would be something like {{#if:{{{suffix|}}} | [[Team name|Team name {{{suffix}}}]] | [[Team name]]}}. SiBr4 (talk) 08:38, 17 April 2014 (UTC)
@Xaris333: The way you first added it, it should work, but it still relies on the duplicated #switch cases with arrows. With the #if part before the sub-template invocation, like you did here, the duplicate team names are not necessary (unless you expect people to still use {{ft|→team}} instead of the new {{ft|team|arrow=yes}}). Could you please be more specific about what it is doing wrong? SiBr4 (talk) 21:16, 17 April 2014 (UTC)
If you want the infobox to always show the arrow in front of the flagicon, the parameter |arrow=yes should be added to the {{ft}} template in the infobox. If the arrow shouldn't be there by default but one should be able to add it, you should use |arrow={{{arrow|}}} in order for {{Πληροφορίες ποδοσφαιριστή|arrow=yes}} to work. I don't know what the use of these arrows is in the first place, so you should decide in which cases it should be added. SiBr4 (talk) 21:40, 17 April 2014 (UTC)
OK. I just added a LOT of arrow parameters to the infobox template. Now you can add an arrow to each individual team template using |currentclub=Team|currentclubarrow=yes, |club1=Team|club1arrow=yes, |youthclubs1=Team|youthclubs1arrow=yes, etc., etc. SiBr4 (talk) 22:18, 17 April 2014 (UTC)
There are a lot of pages in the tracking category because they still include the arrow in the first parameter. Such pages need to be updated to use the new parameters instead. AWB should be able to do that. SiBr4 (talk) 11:14, 18 April 2014 (UTC)
@SiBr4: I have corrected a lot by hand. I don't know how to do it with AWB, so I will continue by hand. May I ask you something similar? I want, if I write |managerclubs1=Arsenal |managerclubs1assistantcoach=yes to show Arsenal (assistant coach). Pls explain to me how to do it, or just edit the template for managerclubs1 and I will do the rest. Xaris333 (talk) 14:36, 18 April 2014 (UTC)
That doesn't require any change to the Ft template, since you can just append text to the team with flag within the infobox. The coding depends on which parameter values you want the template to accept:
{{#ifeq:{{{managerclubs1assistantcoach|}}}|yes|(assistant coach)}} to accept only "yes";
{{#switch:{{{managerclubs1assistantcoach|}}}|yes|ναι|1=(assistant coach)}} to accept multiple values, such as the English and Greek words for "yes" or a logical "1";
{{#if:{{{managerclubs1assistantcoach|}}}|(assistant coach)}} to accept any non-empty text, including words like "no". SiBr4 (talk) 14:54, 18 April 2014 (UTC)
@Xaris333: I've made the change myself. The code adds the text "(assistant coach)" if the parameter value is equal to "yes", so to add the text to the infobox in an article, add the parameter |managerclubs1assistantcoach=yes, |managerclubs2assistantcoach=yes, etc. Because the text is added outside the Ft template, it should not result in articles ending up in the tracking category. SiBr4 (talk) 15:34, 18 April 2014 (UTC)
It keeps taking me to Mihail Maculeţchi most of the time. It will take me to some other page, then back to Mihail Maculeţchi, then Mihail Maculeţchi again, then some other page, then back to Mihail Maculeţchi. About 2/3 of the time it takes me to that one page. I had never even visited that page before now. I tried closing the browser and reopening it but it's still doing it. Only on this computer though. Has this ever happened to anyone else? 93.209.55.56 (talk) 15:18, 17 April 2014 (UTC)
Since I posted that yesterday, it stopped doing that and started working again BUT THEN this morning it started doing it AGAIN, this time on a different page New Age Vaudeville!! It goes to new age vaudeville more than half the time I click random article! Again, not doing it on my other computer.
Burmese script
Until fairly recently (I don't know exactly when), I could see the Burmese script at Burmese alphabet and similar articles. Nothing has changed at my end that I'm aware of, but the letters are all now a bunch of boxes with their Unicode values. If I clip & paste into Word, they display properly, so there's nothing wrong with my fonts. Has something changed in the WP CSS that would affect Burmese? I'm on MS 7 with up-to-date FF. Burmese doesn't display on IE either, but then it never did. — kwami (talk) 20:46, 17 April 2014 (UTC)
Probably a couple months. I created the Burmese Braille article back in November.
WP-my looks fine in text, links, and tabs, but I get boxes for section headings (those areas with a darkened background on the main page, titles and section headings in the articles). But I also get boxes in my url window, so maybe something happened to my browser? — kwami (talk) 21:58, 17 April 2014 (UTC)
Couple of months is a little vague, but last year we had some trouble with webfonts for the Universal Language Selector, which were then disabled. You can enabled webfonts again in language settings; under fonts, enable "Download fonts when needed". — Edokter (talk) — 22:46, 17 April 2014 (UTC)
Thanks. Where is that?
Problem is, I have the fonts. If I copy the boxes and past them in Word, they're fine, and they display on WP-my. When I go to Burmese web sites, I get the boxes, and again they display fine when copied. FF does not have a Burmese setting, and I can't unchoose my settings for 'other language'. How do you get it to display? — kwami (talk) 23:28, 17 April 2014 (UTC)
On the sidebar, under the Wikipedia logo, at the very bottom (assuming you don't have any scripts which change the order). Should be about 600 pixels south of the Wikipedia logo. — Crisco 1492 (talk) 03:23, 18 April 2014 (UTC)
Oh, that 'Languages'! I had no idea that cog was there. Yes, it works now. I'm still puzzled as to why FF doesn't know to use my installed fonts, but at least I can read the articles again. Thanks! — kwami (talk) 05:15, 18 April 2014 (UTC)
In Burma they typically access the web by cellphone--if you already have a USB modem device, it's not possible to buy a SIM card for it--so maybe it's in the apps somewhere, or the mobile comes already configured for the country's language?
I checked the Languages cog box for "automatically download fonts" and can now see the Burmese Braille article with the Burmese text rendered correctly--but don't see any Burmese text in any headings. If this font is no longer enabled by default, is there some way to put the instructions for enabling the font in the article somewhere, maybe in the infobox? —Neotarf (talk) 05:48, 18 April 2014 (UTC)
It's just weird that browsers would not support a major language like Burmese, assuming you have the fonts. — kwami (talk) 07:28, 18 April 2014 (UTC)
Also, with the language option enabled, other languages are lost, including many that use the basic Latin alphabet. (I assume this is why it's not enabled by default.) — kwami (talk) 07:46, 18 April 2014 (UTC)
Google translate doesn't do Burmese, not to mention the Karen languages. I'm assuming it's because Burma/Myanmar has been so isolated for so many decades. It is really only in the last year that it has opened up to limited tourism, due to ceasefires in some areas.
It's not being worked on: nothing on Toolserver is (see archives). If there is no equivalent on Labs, the tool's owner should be informed. Unfortunately, we don't have a chm (talk·contribs) on English Wikipedia. --Redrose64 (talk) 08:25, 18 April 2014 (UTC)
Is it possible to change back to the old font? Can you do it manually? The new font is too big, I have to zoom out all the time.. 62.50.178.88 (talk) 17:01, 18 April 2014 (UTC)
If you're using a plugin like Stylish, you can install this CSS. If you have an account, you can add add it to/import it from your vector.css. πr2 (t • c) 17:26, 18 April 2014 (UTC)
When working on Semi-protected edit requests, as listed at User:AnomieBOT/SPERTable, I often encounter requests to update peoples ages, which are set to automatically update, based upon the date of birth. The most recent request was at Talk:Chance The Rapper which was requested today, although the person's birthday was 2 days ago. Whenever I look at the article, following one of these requests, it always shows the correct age, but I cannot imagine so many semi-protected edit requests unless other people see the wrong age, When, in UTC, do these ages update? Or do they need some other trigger, such as a visit to the page, to "force" an update? Arjayay (talk) 18:28, 18 April 2014 (UTC)
I'm not clear "whenever the page's cache is invalidated" occurs. Are we saying that the reader visits the page, finds the date is wrong, and files an update request, but visiting the page forces the update? Arjayay (talk) 18:39, 18 April 2014 (UTC)
Caches are updated when pages (or templates included in it) are edited, are no longer in the cache (roughly not visited for 30 days or more) or when they are purged. That is as rough a description as possible. Alternatively you could say, the time or frequency with which calculated information is up to date is not guaranteed and should not be depended upon being up to date when authoring such information in the page. —TheDJ (talk • contribs) 18:57, 18 April 2014 (UTC)
Can a template generate potential references, that aren't realized unless cross-referenced?
I'm wondering if we can code info boxes to generate references that are only realized if they're called somewhere in the text.
An example is at Shinji language. The language info box generate reference footnotes for some of the language codes added at the bottom, such as Guthrie (Maho 2009). This can be cross-referenced in the article (as it is: fn 2). Others are only generated if they are cross-referenced in the population reference field. For example, if the ISO 639-3 code is supplied, it creates a direct link, but no footnote, since it's not being used as a reference for anything in particular. However, if "e17" (for Ethnologue, 17th ed.) is written in the ref field, a footnote is generated to Ethnologue, based on that ISO code.
Now, in this case (Shinji), there is no ISO code. Linguist List has an ad-hoc code, and they are discussed in the text. I can call this if I enter "linglist" in the ref field, which I've done (fn 1). However, that means I'm using it in the info box as a reference that no speaker data is available, which isn't true. I could create a footnote manually. However, it would be nice to have a footnote appear if I cross-referenced it, but not otherwise. That is, if I put a value in the linglist field in the box, there would be that direct link but no visible footnote, but if I call "ref name=linglist" in the text, a footnote would appear, based on the code entered in the info box. We don't want footnotes all the time, because Linguist List is a very poor source, and we don't want to suggest it's reliable.
The equation appears to be showing properly at this time. It's possible that it was queued to be generated and wasn't done at the time you viewed the page. Nakon06:43, 19 April 2014 (UTC)
I was doing some long-overdue cleanup in Duga-3 when I noticed that several new articles had been spun off that consisted of nothing other than bits cut from the main article. I was going to simply REDIR them back to main when I noticed some hints in the source text. See Duga-3_(eastern)_receiver for instance.
The apparent problem is that the Wikimaps layer will only create one pin per article. Is this actually true? If so, is there a way to fix this without resorting to a new article?
That doesn't seem a good reason to create a separate article - if it's the only justification it should be merged back. To show multiple locations on Google maps there's {{GeoGroup}}. If the sub-location is sufficiently interesting then surely there's an image of it, or one in e.g. Geograph we can add to Commons, then tag that and add it to the article. That will enable the article to be found. But I don't think we should create forks just to generate links from Google Maps.--JohnBlackburnewordsdeeds19:32, 19 April 2014 (UTC)
I'm looking at GeoGroup now… but where does one use a GeoGroup? It seems like it's trying to link multiple articles into one? I want to do the opposite, so to speak. Maury Markowitz (talk) 20:50, 19 April 2014 (UTC)
You can see GeoGroup here. It generates points for maps from the page. But it doesn't put them on the global map. I don't think there's any way to do that. I doubt Google would want it, single articles generating multiple points on their map. It would greatly clutter their map; the page I linked to earlier for example has over 100 locations, a lot bunched together on top of each other.--JohnBlackburnewordsdeeds22:30, 19 April 2014 (UTC)
For GeoGroup yes. Try it and have a look at the URL it generates: it basically passes a list of points to Google Maps by calling a tool on toolserver that extracts them from the article on the fly. So quick (quicker than it takes many WP pages to load) that you don't notice all the work it's doing. Apart from that you probably only need to use proper coords, i.e. {{coord}}, to make sure they're detected.--JohnBlackburnewordsdeeds00:33, 20 April 2014 (UTC)
Compare the appearance of e.g. "2.5 Equatorial ←→ galactic" in the TOC vs. in the body of Celestial coordinate system. For me, at least, the characters in between "Equatorial" and "galactic" look like arrows in the TOC, and like < and > signs in the body of the article. It Is Me Heret / c21:19, 18 April 2014 (UTC)
Combination of four Google Chrome screenshots at different zoom levels on Windows Vista
I have the same problem in all five tested browsers in Windows Vista. At certain sizes the horizontal lines in ← → in level 3 headers disappear, including the default zoom. If I zoom either in or out then it reappears but disappears again at further zooming out. It's visible for level 4 headers at default zoom but not at some other zoom levels. PrimeHunter (talk) 22:19, 18 April 2014 (UTC)
It looks fine on my Mac, but I'm sure that User:Steven (WMF) would appreciate some screenshots (on wiki or by email), if someone has a few minutes.
That was due to the 'thumb' parameter, resulting in a floating box inside the infobox, where only the 'A' would fit beside the image. — Edokter (talk) — 15:52, 19 April 2014 (UTC)
I have made four screenshots of the below headers at different zoom levels and placed them together. At 100% the level 3 header is missing the horizontal arrow lines. At 90% both headers have them. At 75% the level 3 is missing again. At 67% the level 4 is missing but level 3 is visible. These are the zoom levels Chrome gives when you hit Ctrl+- three times. PrimeHunter (talk) 22:06, 19 April 2014 (UTC)
I'm slightly baffled. That is plain old Arial and should not exhibit this behaviour. I'm tempted to throw this on a video driver issue. How long have you had this problem? (Noting that the typography has reverted back to 'sans-serif', but the font-size has remained at 0.875em.) — Edokter (talk) — 01:17, 20 April 2014 (UTC)
I haven't noticed this problem before. I investigated it after seeing the report here. If I enable the "Vector classic typography" gadget then the horizontal lines in the arrows in both below headers are visible in Firefox (my normal browser) at default zoom (my normal zoom), but disappear at some other zoom levels. PrimeHunter (talk) 22:12, 20 April 2014 (UTC)
Level 3 header: ← →
Level 4 header: ← →
Keep me logged in (for up to 30 days)
Keep me logged in (for up to 30 days) says the wiki.riteme.site login page, but it never happens for me anymore, regardless of browser. It does not happen on Internet Explorer, Mozilla Firefox, Google Chrome, Opera, or Safari. Making sure cookies are turned on does not seem to help. In 2013 it worked fine. I am using Windows 7.--DThomsen8 (talk) 15:26, 19 April 2014 (UTC)
Are you logging into different computers or browsers? I understand that if you login to Browser A, then login to Browser B (or computer B), that it automagically logs you out of Browser A. Whatamidoing (WMF) (talk) 15:45, 19 April 2014 (UTC)
I generally stay logged in on 3 computers and about 8 browsers, I have noticed a slight tendency to get logged off recently, one might think this is to do with token invalidation,but it doesn't seem consistent enough for that. All the best, RichFarmbrough, 00:57, 20 April 2014 (UTC).
Auto-logout every few hours when active: I have also noticed the "30-day login" dropping the username several times a day (on IE or Firefox separately), regardless of how many pages viewed or edited (at least 40 pages edited before auto-logout). I left a computer running for 2 days, inactive, and it held the username those 2 days plus several hours upon returning. At first I thought it an April Fools joke, to pretend the MediaWiki software was a pile of convoluted crap, but it really is that twisted; fortunately, it can also drop the username in 2 Frankenfonts. -Wikid7716:24, 20 April 2014 (UTC)
Request for article statistics list on WP:Physiology
Another user, CFCF, has created this very useful wikiproject, for a group of articles that are currently underattended. This complements the two existing projects (WP:MED and WP:ANATOMY), and I'm a participant. It's hard to get the project going without an idea of what articles are under our scope. I was wondering how we could get the list of articles and the stats on them up for WP:Physiology? I'd be very grateful for any assistance. --LT910001 (talk) 01:58, 20 April 2014 (UTC)
Currently there are about 12 articles in the project - see this special page. The simplest way to move on is
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
We are looking for contributors to help write a new issue every week. If you would like to help, please contact us.
Recent software changes
The latest version of MediaWiki (1.24wmf1) was added to test wikis and MediaWiki.org on April 17. It will be added to non-Wikipedia wikis on April 22, and all Wikipedias on April 24 (calendar).
CirrusSearch was enabled as a beta feature on 27 new wikis on April 18. [46][47]
Problems with various fonts in SVG files were fixed last week. Files that use DejaVu Sans Condensed, DejaVu Serif Condensed, DejaVu Sans Light, Kochi Gothic and Kochi Mincho fonts now show correctly. [48][49][50][51]
The page view statistics site developed by Henrik (stats.grok.se) should now work faster. [52]
You can read a summary of the Wikimedia technical report for March 2014. [53]
VisualEditor news
If you try to add a category which redirects to another category, VisualEditor will now suggest adding the target category directly. [54][55]
VisualEditor tabs will no longer appear on Education Program pages. [56][57]
You can now use VisualEditor on Meta-Wiki and the French Wikinews by enabling it in your preferences. [58][59][60]
Future software changes
MediaViewer will be enabled for all users on the Czech (cs), Estonian (et), Finnish (fi), Hebrew (he), Polish (pl), Romanian (ro), Slovak (sk), Thai (th) and Vietnamese (vi) Wikipedias on April 24. Feedback is welcome. [61]
Edits by anonymous users will now be marked with a new CSS class (mw-anonuserlink). This way, you can easily make those edits use a different color, font or background. [62][63]
The user preference to remember login will soon be removed from all wikis. The edit review preferences will be moved to the recent changes tab, and the preference for the WikiLove tool will be moved to the editing tab. [64][65][66][67]
You will soon be able to give parameters to preloaded templates. [68][69]
You will soon be able to use CodeEditor in read-only mode on pages that you cannot edit. [70][71]
An IRC discussion about Phabricator will take place on April 22 at 03:30 AM UTC on the channel #wikimedia-office on freenode (time conversion). [73]
Problems
For about 40 minutes on April 17, there were problems with page loading due to high server load.
There is a problem with the rendering of formulas with MathJax. If you enabled MathJax in your preferences, you might need to turn it off and on again. [74]
I asked the same question three months ago, with the reply that it isn't. You could use AWB to search for articles using a template directly (see my user subpage for examples), but I don't think it's possible to track direct transclusions with parser functions and tracking categories only. SiBr4 (talk) 14:41, 21 April 2014 (UTC)
Given the very high number of indirect transclusions, your best best would be to use a dump analyser. You could do this yourself or get someone else to do it, but it would almost certainly be more of a "one off" kind of a thing than a tracking category. I see there is a prototype tool to assist with this, but it doesn't seem to be production ready yet. - Jarry1250[Vacationneeded]15:20, 21 April 2014 (UTC)
Citation template in RefToolbar sometimes disappears
Ever so often the cite dropdown vanishes. I know I'm not the only one. Any idea why this happens? It could be another Chrome issue but not related to the ones yesterday which were more general. Thanks. Dougweller (talk) 05:31, 19 April 2014 (UTC)
I was seeing RefToolbar 2.0a. I'm just realizing that a few weeks ago, I had added some sort of .js to my account. Might one set of code knocked out the other? (I've told my account to reset, in preferences, which has restored the Cite feature, so I might not be able to trace what plugin was causing the issue.) -- Zanimum (talk) 00:10, 21 April 2014 (UTC)
If you are unable to edit .js pages in general then do you have wikEd and if so, have you tried disabling it on the icon to the top right? If code in vector.js is preventing you from editing .js pages then try changing skin to remove the code, or use this MonoBook link. You already import User:Writ Keeper/Scripts/massRollback.js in User:Dougweller/common.js which is loaded in all skins, so there is no reason to add it to your vector.js. If you want specific edits to your js files and cannot edit them then an admin can do it, but say precisely what you want. PrimeHunter (talk) 01:30, 22 April 2014 (UTC)
Thanks. But I am an Admin so thus should be able to edit my js files. Disabling wikEd didn't help. However, the link you gave me, this, worked. Much appreciated. Dougweller (talk) 13:16, 22 April 2014 (UTC)
Search info
If I put a quote in a search, such as "and and" I get lots of "and"s. I thought that if you enclosed a string in quotes that would be all you would get. Jodosma (talk)19:48, 21 April 2014 (UTC)
I'm not sure how it is with the old search backend, but with the new one it works so that when there is no match, it will start showing things that match within a certain degree of fuzziness. So locations where "and" is close to another "and", but not directly next to it. —TheDJ (talk • contribs) 07:31, 22 April 2014 (UTC)
With the new search backend, which you can enable on the "Beta" tab at Special:Preferences, you can append "tilde zero" to insist that there are zero words between the two "ands", thus: "and and"~0. This search gives 2426 results. You can read about this new feature here. -- John of Reading (talk) 08:11, 22 April 2014 (UTC)
From talk page to the article
Hello. With many templates, articles and articles talk pages are included to a category. Is there a way by insering a template to talk page, to have the article categorized and not the talk page itself? Xaris333 (talk) 00:51, 22 April 2014 (UTC)
I have discovered a floating issue that prevents certain multimedia objects from floating above others. It occurs only if:
there are multiple multimedia objects on one side of the page
the multimedia object on the other side comes after the other ones in the source code
The first multimedia object on the latter side of the page won't float above the last multimedia object on the former. See here for an example. Can it be fixed? If not, I can just add to help pages about images guidelines on how to get around it. Esszet (talk) 01:09, 22 April 2014 (UTC)
Can it be fixed anyway so that you don't have to use {{stack}}? I'd never heard of it before yesterday, and I imagine there are a lot of editors who are likewise unfamiliar with it.
{{flagicon|Morocco}} () is not displaying properly for me using IE11 on Windows 7 - what I see looks like a striped hyphen in the middle of the flagicon frame. Does it appear correct on other browsers/OS? Thanks. DH85868993 (talk) 10:30, 22 April 2014 (UTC)
Do you mean you don't have "Permanent link" under Tools in the left pane? I still have it, but shortly ago I didn't have the "Print/export" menu or any of "Create a book", "Download as PDF", "Printable version". They have all come back. PrimeHunter (talk) 15:52, 22 April 2014 (UTC)
Oh. Now I get it. Just go to Special:PermanentLink on its own and you'll see what I mean. I was expecting it to produce a simple interface, much like Special:Thanks. Sorry, could have been a better description of the "problem", I genuinely thought that was some kind of 404 error. — Scott•talk16:17, 22 April 2014 (UTC)
Has anyone noticed that at least one instance of the maps with coordinates is broken? I noticed it on this template and am wondering if it is occurring on other pages besides this template. Did something change somewhere, or is this part of a larger problem? Kevin Rutherford (talk) 22:43, 22 April 2014 (UTC)
I was about to write 'broken how?' but then I purged it and suddenly all the icons are flush with the left edge, with labels some visible some not so still thinking the icons are placed in the middle. Strange.--JohnBlackburnewordsdeeds22:54, 22 April 2014 (UTC)
With font-downloading enabled, I could see Burmese script, but not a lot of things in Latin script. Latin transliterations in language templates, for example, as at Wiktionary (e.g. entries 3 & 5 at wikt:er#Mandarin, also the Manx etymology below it, and the Low German entry above it, which are all replaced by black spaces; also mamni taká and Baam at the top of my watch page today, in the 'words wanted' section, which I couldn't see there but could copy & paste here). So a couple days ago I disabled the fonts. Now I can no longer see Burmese, but I still can't see the Latin stuff. How do I fix that? — kwami (talk) 23:14, 22 April 2014 (UTC)
CSS/JS request
Im looking for a way to highlight URLS to specific domains with a colored background, and I dont know enough about CSS/JS to do it. Werieth (talk) 17:05, 22 April 2014 (UTC)
@Writ Keeper: Thanks, however it doesnt do what Im looking for. I was hoping to highlight references and such that contain said a given domain. It works for internal links that contain the text, but external links on wiki are not affected. :( — Preceding unsigned comment added by Werieth (talk • contribs) 17:37, 22 April 2014 (UTC)
@Werieth: Ah, it's just getting overridden by other things. Try slapping in an "!important", like a[href*="news.yahoo"] { background-color: Red !important; }. Writ Keeper⚇♔17:45, 22 April 2014 (UTC)
Font size and style
What happened to the font? Suddenly, everything's a little bigger, as if I'd accidentally zoomed in with Internet Explorer, but the browser zoom is 100% just like normal. Page titles and section titles, including "Font size and style" here, are suddenly Times New Roman or another serif font, not the old sans serif font. I've looked at lots of pages, and it's all the same. 2001:18E8:2:28CA:F000:0:0:CB89 (talk) 19:22, 3 April 2014 (UTC)
Came here to complain about the same thing. Why have all article titles been replaced with a serif font? Not only is this inconsistent with the conventional online/Internet practice of all-sans-serif text (which is the convention by which Wikipedia has long adhered), this is also the EXACT OPPOSITE of standard print practice (sans serif for headlines, serif for text), and seems to have been arbitrarily imposed upon the community without any wider consensus (and don't say, "it's been in beta for a while" -- only a very, very small percentage of the wider community participated in the beta). At the least, can someone provide an example line of CSS on how to get the old article title font back? —Lowellian (reply) 19:32, 3 April 2014 (UTC)
Web is not the same as print, so the sans-serif headers/serif text does not necessarily apply to the web. Wikipedia also abandoned serif-only long ago; all remaining skins use sans-serif only. How about giving it 24 hours? — Edokter (talk) — 19:40, 3 April 2014 (UTC)
You said "all remaining skins use sans-serif only". That's not true and EXACTLY what we're complaining about: why have the titles and headings been replaced with serif text when the rest of the site uses sans-serif text? —Lowellian (reply) 20:08, 3 April 2014 (UTC)
Can't we do this the normal way, with well publicised votes which see if there's consensus? Thanks, Matty.00719:50, 3 April 2014 (UTC)
I did see the "changing typeface" notice beforehand, but I didn't think it would look like this...holy crap! this is ugly and cartoonish. Thank goodness for the .css script above.--William ThweattTalkContribs19:51, 3 April 2014 (UTC)
Can we get an opt-in gadget for users who want to go back to the old vector style? This would be better than having lots of forks of the proposed CSS... Helder.wiki20:26, 3 April 2014 (UTC)
I just noticed this. It is a bit...strange. Mostly I was just wondering if my eyes were okay. I mean it's not -bad-, but...don't fix what ain't broke :P TangoFett (talk) 19:58, 3 April 2014 (UTC)
NOT easier to read. Not wide enough, to sharp, to thin, and it takes much more energy to read and concentrate. Makes it more difficult to concentrate on the text and read it. Hafspajen (talk) 20:01, 3 April 2014 (UTC)
If anyone is asking me now, it looks like small small thin and very vertical letters that makes your head hurt. Hafspajen (talk) 20:13, 3 April 2014 (UTC)
Yeah, I'm still on monobook and thus this doesn't affect me but I've noticed the change as well on other computers. Infoboxes don't look pretty good with this new font style IMO. Connormah (talk) 20:19, 3 April 2014 (UTC)
Adding that code to vector it cames out Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page. eh, sad. Hafspajen (talk) 20:21, 3 April 2014 (UTC)
I'm a bit confused... everyone's complaining about the font, but the fonts are all fine for me. (Note that I was already using Arimo and Tinos as my default sans and sans-serif fonts.) For me, it's just unbearably huge... ?Cloudchased (talk) 12:18, 6 April 2014 (UTC)
Support changing back to original font
If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
I encourage anyone complaining to create a screenshot of what it looks like for you, put that online and report your operating system and browser. That makes it much more likely that problems get dealt with. —TheDJ (talk • contribs)
I second this. I will personally make sure any bugs with the choice of fonts get dealt with. The problem with fonts is they look different depending on your operating system, browser and what fonts are installed on your system. It's possible one of the fonts is simply not rendering how it should on your display. Please include a screenshot, your browser and your operating system and I'm confident we will discover weird edge cases that can easily be resolved. Jdlrobson (talk) 05:45, 4 April 2014 (UTC)
I'm sorry, but this is not about 'dealing with problems and bugs', it is about whether we should just change back. Telling us to create a screenshot and report our OS and browser doesn't negate the validity of supporting a revert. And I am saying this as someone who hasn't (yet? only seen the stuff on my linux desktop) seen a single one of the issues mentioned with weird rendering and narrowness, but still disagrees with the changes. Cathfolant (talk) 05:00, 5 April 2014 (UTC)
As was already said, if it ain't broke.... Matty.007
Note that link doesn't actually show what you see. To show us what you see, you'll need to take a screenshot and upload the image somewhere (that somewhere can even be here). Anomie⚔13:37, 4 April 2014 (UTC)
Man, and I hoped you would see it, some do... Well, I will explain then = much MUCH smaller letters then before. Squeezed up, 4 times as high then wide. The lines are thinner, thickness of hair. It kind of vibrates when I trying to read it... Hafspajen (talk) 00:31, 5 April 2014 (UTC)
I agree with the if it ain't broke, don't fix it rationale above. The new font is indeed much harder to read and more straining to the eye than the old appearance. Please reverse this change. -- ToshioYamaguchi20:28, 3 April 2014 (UTC)
It looks like the bold font is not loaded, and the italic font is not loaded. This causes faux-bold and faux-italics. Especially the faux-bold does not look good, see the bold "e". Also the normal "f". It creates a very busy, jagged and off-looking page. (Chrome + Windows = screenshot) Ahappylittletree (talk) 20:33, 3 April 2014 (UTC)
The old font was legible, simple and clean. The new one is harsh on the eyes and the spacing makes it rather difficult to read. I have had to tinker with my settings to be able to comfortably read more than a few lines at a time. If this font was used in a book (for example), there is no way it could be put on the market at nobody would be able to read it. The same standards of legibility should apply for a major website. This isn't some idiot's personal site from 1996 - this is a significant online resource and it should be presented with as much simplicity as possible. OwnBrand (talk) 20:37, 3 April 2014 (UTC)
Until I saw this thread, I thought someone had been playing with the font settings and screwed something up. Now it turns out this is actually by design? Wow. This needs to be reversed, quickly; it's embarrassing!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 3, 2014; 20:42 (UTC)
So, it's not a late April Fools joke? - why do we have to endure these things? - no doubt someone will claim it was "consulted" about - hidden away somewhere where nobody looks. Arjayay (talk) 20:51, 3 April 2014 (UTC)
I also thought something was wrong with my browser. It evokes the bare-HTML style of the early Web, but without the readability. What's next, frames? It looks like Citizendium with less professional titles. It's simply hideous. Not that the Foundation gives a crap what we think.... Lagrange61321:00, 3 April 2014 (UTC)
Restore. To reiterate points that I made earlier, not only are the new titles/headings inconsistent with the conventional online/Internet practice of all-sans-serif text (which is the convention by which Wikipedia has long adhered), this is also the EXACT OPPOSITE of standard print practice (sans serif for headlines, serif for text), and seems to have been arbitrarily imposed upon the community without any wider consensus. —Lowellian (reply) 21:05, 3 April 2014 (UTC)
Hi Lowellian. To address a couple points... you bring up normal standards of sans vs. serif in print or Web. There are differences between the two, as you note, but the reasoning for the serif headers is really clearly articulated in the Signpost and the extensive FAQ about the changes. On the point about wider consensus: this change was beta tested on an opt-in basis by thousands of editors. Over the last five months, we've been collecting feedback (100+ discussion threads, for instance) and substantially changed what's released today based on editor feedback across wikis. Steven Walling (WMF) • talk21:16, 3 April 2014 (UTC)
The articulated reasoning (to make titles/headers stand out from the rest of the text) is flawed: using serif headlines over sans-serif text does make titles/headers stand out, but in a bad (clashing/discordant) way, which is why this scheme is not practiced either online (all-sans-serif text) or in print (which uses the opposite, sans-serif headlines over serif text). And the people in the beta are not equivalent to the wider community; to claim they are is to ignore selection bias. —Lowellian (reply) 20:08, 5 April 2014 (UTC)
I had assumed that someone had screwed up the font settings accidentally and it would be fixed within the hour. When I found out it was deliberate, I immediately put Kephir's CSS fixes into my vector.css. The serif headings in particular are absolutely horrendous. (I don't care if other websites have done it before successfully—I don't like it in this specific instance with this specific choice of fonts.) And no, I was not notified of the impending change, because they didn't run one of those top-of-the-page banners like they do for policy changes. "Thousands of editors" is a drop in the bucket compared to the total number of Wikipedia users. « Aaron Rotenberg « Talk « 21:37, 3 April 2014 (UTC)
The change has been available as a beta feature for a few months now. We've done multiple blog posts and informed mailing lists about this. Do you have ideas how else to do this? Vibhabamba (talk) 22:06, 3 April 2014 (UTC)
I don't use beta features, I don't read the Wikimedia blogs regularly, and I don't subscribe to mailing lists. Like I said, though, I do pay attention to more "push"-style notifications, including talk page notifications and the top banner. I know that getting people notified about changes is a persistent problem; almost every sitewide change (including ones I like personally) draws a stream of "I wasn't informed!" complaints like this. What I'd really like is a less obtrusive form of notification than the top banner that still allows almost every Wikipedia user who might be interested to be notified about and participate in upcoming changes before they occur. Something like a sidebar with community news headlines, on by default but with easy opt-out for people who don't want to read it? « Aaron Rotenberg « Talk « 22:19, 3 April 2014 (UTC)
Also, just to further clarify: the reason I don't pay attention to any of the things you mentioned is that they are all opt-in. Many more people would get notified if we had a notification system that was opt-out, without being too annoying. « Aaron Rotenberg « Talk « 22:25, 3 April 2014 (UTC)
Aaron, thanks for the feedback. Do you think you might have tried the beta if there were notifications about new beta releases? We updated the beta feature several times, and I think many people missed that because there weren't push-style notifications related to each update. Steven Walling (WMF) • talk23:07, 3 April 2014 (UTC)
I absolutely would have tried the beta if I was notified that a sitewide typography change was being considered, and I would probably have given (much less vitriolic!) feedback. Also, thank you Edokter for adding the opt-out gadget! « Aaron Rotenberg « Talk « 23:34, 3 April 2014 (UTC)
@Steven Walling (WMF): Err, push notifications for every iteration of every beta feature would be awful, and would lead to most people opting out of or ignoring the flood of notifications that would result (e.g. banner blindness). But a push notification that this was going to be enabled by default, along with updating the beta feature to show what the change would actually look like without extra changes, would have been much more helpful. I recall this advice was given to you before this rollout, too, but was apparently ignored. Anomie⚔13:38, 4 April 2014 (UTC)
Objectively? That's hard. Though: Arimo was updated less than a year ago with "improved hinting", so it already needed an update to improve legibility before this. Also see the screens posted (not every OS or browser renders this font without legibility problems) Ahappylittletree (talk) 22:36, 3 April 2014 (UTC)
Readability was certainly better with the old design. Now the text often seems somehow blurry to me and lacks the previous clarity. Gestumblindi (talk) 21:53, 3 April 2014 (UTC)
Actually, I agree with that revert. I'm one who has a negative reaction to change in general (and this in particular on those wikis where I haven't been using Monobook), but I don't agree that admins should be overriding it in the site-wide CSS for everyone. Creating a gadget for people to opt out is a much better plan. Anomie⚔13:44, 4 April 2014 (UTC)
I'm somewhat torn... I like the changes to the titles and headers, but the body text is to thin and I am having all I can do to read it. That being said, I support reversion of this change back to what it was. If you want to release a new Vector2 skin with this other font set, that is fine and I'm sure would cause the least headaches. You can even change it to site default for all I care... — {{U|Technical 13}}(t • e • c)22:36, 3 April 2014 (UTC)
Yes, absolutely awful. On default zoom the letters are too squat and far apart, zoom in one level and the lines are practically on top of each other. Completely pointless and self-indulgent change for change's sake. Apologies for half-copied text from Talk:Main Page, which is where the vast majority of Wikipedia readers - i.e. those that don't edit - will have heard about this. --77.102.114.99 (talk) 22:44, 3 April 2014 (UTC)
Whatever the merits (?) of this new font, it is downright rude to just drop it on us without warning. That the "mob" here is angry is entirely attributable to yet another botched rollout. ~ J. Johnson (JJ) (talk) 22:49, 3 April 2014 (UTC)
Regarding "without warning"... There has been a watchlist notice for several days before this change happened, I posted on this Village Pump days before it happened, and there were two articles in the Signpost about it. Pretty much the only other things we could have done would be to either use a banner or to message all editors directly. Do you think we should have done that? Steven Walling (WMF) • talk23:04, 3 April 2014 (UTC)
I think that the WMF did a better job with this rollout than with the VE rollout, so there is evidence of learning there. I think that with this project, and much more so with VE, there was a lack of interim notifications that said "Beta 2.0 of the foobar has been released. Please come try it and provide feedback." With VE, and again with the typo refresh, I tried it when it was first announced, saw that it needed a TON of work, and turned it off. As far as I remember, the next Watchlist notification (which is probably the best way to get frequent editors' attention without being obtrusive) was a few days ago. Additional interim notifications may be helpful. – Jonesey95 (talk) 23:19, 3 April 2014 (UTC)
Please either change it back, or make this "new" setting another skin that we can choose (in addition to the previous settings), and preferably NOT the default skin. Steel1943 (talk) 23:09, 3 April 2014 (UTC)
I agree with this. Please add the old Vector as a selectable theme in preferences. I don't mind if this is the new default, but I'd just like to select the previous Vector (as Vector-old?) and not have to come up with a CSS fix that fixes every little change while making sure it doesn't have unintentional side effects (because of using !important to override changes, etc). The Son of Man (talk) 23:40, 3 April 2014 (UTC)
I have the gadget enabled for now, but it doesn't revert everything and it uses Javascript. I have JS enabled most of the time, but sometimes I have it off (when coming from a site with obnoxious scripts, for example) and so I still end up being hit with the new changes. Adding a new skin that's just the same exact Vector as a few days ago shouldn't be that hard and would give everyone who doesn't like the new changes a quick, simple fix. The Son of Man (talk) 00:22, 4 April 2014 (UTC)
I initially liked the article font (not so much the serif font used for the titles), but after seeing how terrible bold/italics look...no. I'm changing my vote. ProtossPylon23:24, 3 April 2014 (UTC)
New font sucks. Unreadable on my display. (As a rule, condensed fonts should never be used for general purpose text! If the advantages outweighed the disadvantages, "condensed" would be the "standard", and "standard" would be "expanded", don'tcha think?) Utterly dumbfounded that this could pass any sort of committee review. Not that "you" care, but the site looks amateurish as hell, now. Succinctly: it just looks like someone made a mistake. Hopefully this ridiculous change will be reverted and soon. (And privileges for making changes of this nature should be revoked for whomever is responsible, as they have demonstrated BEYOND-ABYSMAL judgement in this matter.)BlackmailedIntoRegistering (talk) 23:36, 3 April 2014 (UTC)
It looks horrible. (And from other users' screenshots it looks like I had it better than some, as the measures I have already taken to block self-indulgent typographical tomfoolery on the web in general prevented the fancy fonts from being used.) I have applied User:Kephir/vector.css and now it is back to normal. Thanks, Kephir!
As has been said many times above: If it ain't broke, don't fix it. There was nothing wrong with the old style. This new style is far too widely spaced and is consequently harder to read. It also looks like a Peter and Jane book. My immediate thought when I first saw it was that the CSS had somehow become corrupted in loading. It does not look like an intentional change; it looks like a bug.
And it does not wash to bang on about "it was tested on thousands of editors, an insignificant percentage of the millions who use wikipedia" or "it was announced months ago in a locked filing cabinet in a disused lavatory with a sign on the door saying Beware of the Leopard." It is plain from previous comments that I am far from the only one who had not the faintest notion it was going to happen. "Did you see the Signpost..." The what? I never even knew that existed until I saw the above link. Same goes for all the other "obvious" places it was announced. As I said, I initially thought it was a bug. I only found out what was going on by googling wikipedia css changes. These announcement platforms may be "obvious" to those who implement the changes but they are entirely obscure to Joe Bloggs users like me. (Some users have mentioned the "top banner"; I vaguely remember that, but only vaguely, because I blocked it a long long time ago for getting in my face and being a pain in the neck.) It is well known that users of complex systems by and large only learn about the bits they need to do whatever it is they want to do, so it should be no surprise that people treat wikipedia in this way too.
Registered users at least would be more effectively notified by sending an email, but there appears to be no option to receive such emails.
There are multiple ways of getting e-mail notifications about changes like this, such as subscribing to a WMF mailing list or the WMF blog via RSS, but I don't know of any that only include upcoming potential changes and not a lot of other noise. I can sympathize with wanting to block the top banner, since it's usually very obtrusive. That's why I was arguing for a more subtle sitewide notification system above. « Aaron Rotenberg « Talk « 23:54, 3 April 2014 (UTC)
Change back as accessibility for those with visual problems has been lowered - the opposite of what we should be doing - also multiple fonts on the same page is not user friendly. I have used Preferences → Gadgets → Vector classic typography (use only sans-serif in Vector skin) but many others will not be aware of the new option nor will non registered readers. -- Moxy (talk) 00:13, 4 April 2014 (UTC)
The old font was a beautiful pixel font. This makes it very sharp and easy to read. The new font, for me at least, is heavily anti-aliased, making it look out of focus. My eyes hurt when trying to read it. That's an objective criticism for you, and I don't really see how anyone can claim a heavily anti-aliased font is better than a pixel font at small font sizes. --Muzer (talk) 00:17, 4 April 2014 (UTC)
Different situations at different PC's. If it ain't broke, don't break it. At one it made the body very difficult to read, a narrow font. For anybody who is on the edge, this makes it unreadable.North8000 (talk) 00:52, 4 April 2014 (UTC)
WP:BRD You were bold, we don't like it, so revert and let the discussions commence - then both sides can hold their heads up high and agree that; there was inadequate discussion, a lack of information for us to kn ow this was happening, no consultation with editors who had not taken part (14k out of several million is indeed NOT a large enough sample size), that MediaWiki is not our boss, and that it works for us - this is not an oligarchy yet (as far as I know) Chaosdruid (talk) 01:09, 4 April 2014 (UTC)
Text readability is diminished with a larger font, and its typeface looks less encyclopedic. Readers who have trouble reading Wikipedia can zoom their browsers in at 110% to produce the same effect instead. CR4ZE (t • c) 01:26, 4 April 2014 (UTC)
Another dreadful change. Just dreadful. Is the WMF's agenda now to force people to create accounts in order to get access to legible versions of Wikipedia articles? The new body text looks to me like what happened in a library I volunteered at a few years back, when somebody set a batch of new widescreen monitors to the wrong resolution. A few years back I was lucky enough to sit in on a presentation by Stephen L. Carter about education, who said (roughly) that the typography designers have been coming up with since at least the turn of the millennium may look nice, but in the long term, both in print and on screen, has proved to be less readable and, even worse, leads to weaker long-term memory retention of the content. That's not what we should want here. Hullaballoo Wolfowitz (talk) 01:27, 4 April 2014 (UTC)
The new body text font's too wide, and the Georgia used in titles looks unprofessional and is distracting. Tezero (talk) 02:29, 4 April 2014 (UTC)
Seriously. I spent a good five minutes twiddling with browser settings, because it did not even occur to me that someone would do this on purpose. This is the en.wikipedia village pump; can we please change the local default back to the original settings while WMF works their stuff out? VQuakr (talk) 02:40, 4 April 2014 (UTC)
I personally don't like it, and think the old font was perfectly fine. However, it does not go without saying that I strongly believe the developers are not getting the respect they deserve from our community. I think many of the above comments are failing to assume good faith on the foundation's part. They are not doing anything along the lines of holding projects hostage.--Jasper Deng(talk)03:19, 4 April 2014 (UTC)
Fully agree. I strongly support changing it back. It looks absolutely terrible. I actually spend quite a lot of time on Wikipedia and I had no clue this was even being considered (granted I only work on editing the site, not reading every single technical debate/idea/change/etc). It's very unpleasant to read, like physically unpleasant. And from what I can gather, there was no real endeavor at altering users to the potential change (such as a site wide notice, like when they're asking for donations) which I find a rude - best of intentions I know, but still. Coinmanj (talk) 03:30, 4 April 2014 (UTC)
I don't care about the actual font as much as I care about the font size. Sure, bigger font should be an option for those who want or need it. Forcing it on all of us without an opt-out other than a gadget is reprehensible behavior from any organization. The bigger font causes many problems for me; most importantly, it makes columned displays nearly impossible to read on my screen (1280x800) due to how narrow the columns must be. This is a huge issue for us users with small monitors who use Wikipedia both to read and edit. That being said, although I don't care about the font itself as much, it still seems to be completely arbitrary and now much harder to read and navigate than it was. I echo the above posters who say that this is obviously not an improvement. I see absolutely no possible way that this new font could improve browsing experience for anyone, including the print-disabled; as for the size issue, that should be an option anyways in preferences, even without this typography "refresh". Tl;dr though; change the font back to the original for readability purposes and make an option to change font size. That should please everybody, I think. StringTheory11 (t • c) 04:07, 4 April 2014 (UTC)
You may be interested then in the fact that fixed numbers of columns have recently been deprecated in {{reflist}}, in favor of columns based on the font size and screen space available. See that template's talk page for discussion. Anomie⚔13:53, 4 April 2014 (UTC)
Per my comments on mediawiki. Also I don't know how much this matters but I don't like the look of the new fonts either. Now off to toss my override code up here as well. Cathfolant (talk) 04:15, 4 April 2014 (UTC)
The original font/size was more compact, more attractive, more "encyclopedic" dare I say. Articles now appear larger and I believe will scare off readers. Image captions now bleed into other sections. It's just a terrible idea. Also I echo the comments above that the new font is literally painful to read. - HappyWaldo (talk) 04:54, 4 April 2014 (UTC)
It looks like you're getting "Liberation Sans Narrow" rather than one of the fonts actually specified, which is somewhat strange. Apparently you somehow have that installed but not regular Liberation Sans (it probably came with some other software you installed); you might try finding a full version of Liberation Sans or Arimo to try out. Anomie⚔11:27, 5 April 2014 (UTC)
Just wanted to report: Yes, that's exactly what happened to me: "Liberation Sans" was installed in 4 variations (bold, italic,...) , but all of them were "Narrow". 1st aid was to remove them all (did help, system fell back to Arial). 2nd help was to install the correct fonts from the source (linked to from Liberation. I assume that some software installed these narrow fonts. Among my suspects are OpenOffice, LibreOffice, Inkscape and stuff like that. --Pyrometer (talk) 11:17, 7 April 2014 (UTC)
Support changing it back. As a former Web designer, I saw right away why so many users are complaining. The new CSS font stack SHOULD NOT HAVE listed Helvetica ahead of Arial for sans-serif body text. Any seasoned Adobe user or Web designer knows that Adobe apps always attempt to install Adobe fonts, including Helvetica, which render with very poor hinting and kerning at any size below 20px when put through the Windows ClearType rasterizer. This issue has been widely known since the mid-1990s; I remember this was a huge problem in Web design even back in the days of Windows GDI and dial-up modems. There are many blog posts out there on this issue, such as this one. And everyone installs Adobe Reader nowadays because so many corporate, government, and nonprofit sites use Acrobat to publish reports and data. Take a look at screenshots of Adobe Helvetica 10px and 12px as shipped with Reader as rendered by Windows ClearType in Windows Internet Explorer or Google Chrome, and it'll become very clear why half the Internet is screaming that Wikipedia went crazy ugly all of a sudden. Interesting how the new CSS stack looks okay in Firefox, probably because they use their own Azure rendering engine with subpixel rendering that has its own interesting way of rendering Helvetica. --Coolcaesar (talk) 07:08, 4 April 2014 (UTC)
As noted below, I stand corrected, this is HP's problem (Hewlett-Packard Helvetica version 1.3), not Adobe's. But either way, because HP has such a huge portion of the market share for printers, WP needs to adapt to the fact that HP's widely deployed version of Helvetica isn't hinted correctly. --Coolcaesar (talk) 13:15, 4 April 2014 (UTC)
Support changing it back. The new font is too big for me, so I had to scale down font size on my computer to be able to read comfortably. Hoevever, this causes problem for me when I go into edit mode where I find the text difficult to read. There should be some options about fonts, font size etc. Regards, Iselilja (talk) 07:25, 4 April 2014 (UTC) I have now been helped by the opt-out option though; so thanks for that. Iselilja (talk) 07:54, 4 April 2014 (UTC)
It seems the WMF is not willing to learn anything from all the disasters the produced within the last years (image filter, VE, ATF), they don't ask the community ether a changement is appreciated. While serifes in longer texts might be easier to read in titles they're doing the contrary, they make it harder, and having tw different fonts is ugly. Then the font is much lighter, more gray, it makes it very difficult to read for me. Obviously they forgot on people with glasses. Last but not least, as a partly Wikinewsian, I observe that much more article titles now break (titles of Wikinews articles tend to be much longer then in Wikipedia). Not good. It seems the changement wasn't a thoroughly thought-through decision. Please revert back soon. --Matthiasb (talk) 07:27, 4 April 2014 (UTC)
My main issue is that the new font size causes layout disaster to all templates/tables (e.g. WP:RDT) which are susceptible to increased font size. If one wants larger text, they can use their browser's zoom in function which posts smaller problem to the article layout. -- Sameboat - 同舟 (talk) 07:44, 4 April 2014 (UTC)
Chances are that they were broken for some readers anyway, since the "old font" was just "whatever font your browser is configured to use when asked to use any generic sans-serif font". Anomie⚔13:59, 4 April 2014 (UTC)
Please change it back. There is too much spacing on the titles/headers and it looks TERRIBLE. -- — Preceding unsigned comment added by 216.116.9.47 (talk • contribs)
I support changing back. The new font is not heavy enough and I (subjectively) find it much, much harder to read. It also looks quite unprofessional in my opinion. Moreover, on science page with formulas, there's a heavy clash between the new font and the font used in the formulas. If it ain't broke... Can we just revert and then have the new style as an option? Ollivier (talk) 09:32, 4 April 2014 (UTC)
I guess I could get used to it, and sometimes change is good. But in this case I do find it harder to read and personally prefer the old. Robvanvee11:00, 4 April 2014 (UTC)
This new font is an absolute eyesore and VERY hard to read, I start squinting as soon as the page loads. I'm seriously done editing on wikipedia if it stays. This is what it looks to me in Windows XP and the newest Firefox version (notice all the fs being randomly fat). --Feuerrabe (talk) 11:11, 4 April 2014 (UTC)
I do not see how this change increases legibility or aesthetics of Wikipedia pages. Everything is bold now and it looks like crap (I use the Vector theme). I find this superfluous change highly disturbuing and unprofessional and would go even so far as to demand a ban from Wikipedia for life for whoever made this change. ♆ CUSH ♆11:19, 4 April 2014 (UTC)
The new font is really hard to read. Anyway, editors can get away with scripts if they wish to, but what about our readers? Was there any feedback (the sort of Article feedback tool or surveys, not the kind of discussions on hidden talk pages) from ip users conducted? How can we know what the readers feel? It will be bad if they have to live with a wikipedia they don't like. If there has not been any feedback I think it is very important to conduct a survey. Fauzan✆ talk✉ email12:17, 4 April 2014 (UTC)
Restore: This new style is worse than the old one. I didn't see any need for a change. Also serifs for headings is a big no-no. Please change it back.Destruktor5000 (talk) 12:49, 4 April 2014 (UTC) Edit: Readability has also deteriorated. The lower bows of lower-case "a" in titles is so thin, it looks like a printer has run out of ink. See here: Win 7 & IE 10.Destruktor5000 (talk) 13:22, 4 April 2014 (UTC)
I was in the middle of working on an article and all of a sudden the font changed. I thought "wow, what did I do accidentally to turn everything into such a mess?" It took me a while to realise that it was a site wide change and no accident, somebody actually thought this was a good idea. What was wrong with the way it was before? Look how ridiculous a book title as the title of an article looks now -Martyrs of Palestine - it 's like an olde tyme embroidery sampler done by an old lady in 1840. Why did they just drop this change on everyone all of a sudden without giving anyone a chance to comment?Smeat75 (talk) 12:58, 4 April 2014 (UTC)
I haven't many contributions in this wiki but I have more 9 400 in french WP and I have SUL. Because this presentation is in WP-fr too, I can observe problems. Indeed, although the title is good, the body of article is in character who gives an impression of vagueness. --Gratus (talk) 13:04, 4 April 2014 (UTC)
Restore fonts: (edit conflict) (edit conflict) These Frankenfonts are so bizarre, with serif header titles joining the underline hr rule bar, or the reverse with arial headers at "*" bullets, while replies are Times New Roman or such. The peculiar fonts should be kept a user choice in each user's vector.css page. -Wikid7713:09, 4 April 2014 (UTC)
The new typeface looks horrible and is very hard to read (see screenshot to the right). --SelfishSeahorse (talk) 14:40, 4 April 2014 (UTC)Excerpt from the homepage of the German Wikipedia on 2014-04-04 to demonstrate problems with the new typeface (Microsoft Internet Explorer 9 on Windows 7)
Restore and have a vote before making this permanent! It looks awful (see my screenshot, Chrome, Windows 7; I have font smoothing switched off to improve performance, which makes it look especially bad, but was fine for the old layout), should have been raised before, and any problems with the old font were a problem with the generic san-serif displayed by web browsers, and should be addressed to them not patched up by us. ‑‑xensyriaT14:47, 4 April 2014 (UTC)
Please restore. I'm just a random viewer of wikipedia. I do not edit, nor do I want to register on the site just so I can use gadgets and css changes to restore the font to something readable. The proposed workarounds and opt-outs to fix a blunder in design is missing the point. The body font is too narrow and the vertical lines are too closely spaced. This makes it difficult to scan. It is heavily anti-aliased which leads to a sense that the text is 'blurry'. Those are objective issues. Like many here, I thought that this was an April Fools joke because the changes are so awful that I literally thought it was a joke. That a site such as wikipedia (which I love and easily spend an hour on per day) made such a huge mistake and changed to a font that literally hurts my eyes to read boggles my mind. — Preceding unsigned comment added by 76.226.162.220 (talk) 15:08, 4 April 2014 (UTC)
Restore. I agree with above, I have no registered username, but please ask the community before making things permanent. I'm not exaggerating: this really hurts my eyes. I'm using Firefox on Windows 7, looks similar to the Chrome screenshot above. Let's hope it will change, I can't just add a script to every computer I use Wikipedia on... I'm not saying change it bad, but firstly ask (poll on front page even), secondly test out different fonts and lastly, better be sure consensus is the change should be done before just making it permanent.93.125.198.182 (talk) 15:17, 4 April 2014 (UTC)
Restore. Chrome and Firefox on windows XP both render the normal "f" almost as a bold "f", and the bold "a" and "e" are difficult to read. Mitchan (talk) 15:25, 4 April 2014 (UTC)
Restore or rethink because of accessibility issues that don't seem to have been taken into consideration. I get an instant migraine looking at it and it would be impossible to edit or to read here with the new font. I use monobook skin so not a problem for me, but I think the issues about hurting eyes is serious and even though it's been tested (somehow my eyesight is so poor I missed the announcements!), it's possible that the outlier cases of people who are really affected weren't considered. File:Screen shot font change.jpg. Something odd going on with the letter "i" abutting adjacent letters. Victoria (tk) 16:12, 4 April 2014 (UTC)
Restore I also am getting a headache from the font appearing on Wikipedia. I've had to create that css page (didn't really know what I was doing but it seems to have worked minimally) but I am not always logged in. I can barely look at a Wikipedia page now and find myself turning my face away from the screen automatically. I've included my system info on the feedback/font page so won't include it here, just came to vote. StefanijaSili (talk) 16:56, 4 April 2014 (UTC)
Restore The new style seems to have all sorts of problems. I use Firefox on Ubuntu 13.10, and the problems I face do not seem to be as bad as those on some operating systems/browsers. Still, while I'm impartial to the serif headings, the new body text is worse. It is now needlessly larger, taking up more space (but the sidebar was weirdly made too tiny!). The forms are elongated and wispier, so that even though the letters are larger and less text can fit onto the screen, they are harder to read! Before: http://i.imgur.com/SRhF19Y.png After: http://i.imgur.com/yr4rj67.png— Preceding unsigned comment added by Aibara (talk • contribs) 17:29, 4 April 2014 (UTC)
Restore It looks like this: http://i.imgur.com/zjjDnRs.png to me (firefox, windows 7), and reading it makes my eyes hurt. Seriously, who thought 'Liberation Sans Narrow' was a good font choice? 152.23.165.193 (talk)
No one did... this is something to investigate (though I suspect you have Liberation Sans Narrow, but not the regular Liberation fonts installed). — Edokter (talk) — 20:00, 4 April 2014 (UTC)
Support new style is ugly, and such a change was made without a Wiki-wide request for input despite it affected every single user. Darkwarriorblake (talk) 20:07, 4 April 2014 (UTC)
Restore the old font. To me, the font looks like it would be appropriate on the Wiktionary, but not Wikipedia. It looks like a dictionary's font; I much prefer the old font when compared to the new one. Seattle (talk) 21:10, 4 April 2014 (UTC)
Support I wanted to give it a couple of days to see if I'd get used to it and to have a chance to read over some of the other arguments. Fundamentally I agree with much of what the oppose says, but I must also adhere to my preference and I am having a difficult time adjusting. Now this seems like the typical old person line, "I don't like change" but I actually find the replacement font inferior in many ways. I think if professional design help is to be sought, a superior design must be the root cause for change. That is totally a matter of opinion, but I am finding the rationale behind why it was changed to not be true at all. I fully realize nothing will come of this poll -- I suppose I wish that if such a sweeping change is to be made that the foundation should have sought overall community input. Maybe I missed the notice but if the beta testers were the only trial and feedback base for this change then it's well known that they represent a very esoteric and small group with in the community. They probably don't even makeup a good sample of the "readership" demographically. Lastly it seems some technical considerations, the strong point of the beta testers, were not investigated hence why a broader base has proven to be more important for inclusion for such an important change. Mkdwtalk21:18, 4 April 2014 (UTC)
So the font looks on Windows XP!Restore I like the font on ubuntu, but have the same problems on windows that Mitchan has mentioned.--Sinuhe20 (talk) 21:36, 4 April 2014 (UTC)
Sorry to have missed the original announcement and comment period, but the serif titles and section heads look ugly to me, and I would support changing them back. —Steve Summit (talk) 22:05, 4 April 2014 (UTC)
Restore the old font. I don't see any benefit to readers. Too wide field of vision required. And accessibility to people with low visual impairment may be more difficult. Franz53sda (talk) 22:48, 4 April 2014 (UTC)
Restore old appearance as default. I don't use Vector but on my monitor the test pages have far too much interline space and the body font is over large, which makes it harder to read articles, especially ones above a short stub. I suspect it's also making problems with image captions, though the test page I've viewed had no images. This seems to have been customised to those with vision difficulties without thoughts to the readability of the majority who don't. Perhaps this, or something similar, could be offered as a style for the visually impaired? Espresso Addict (talk) 22:54, 4 April 2014 (UTC)
Restore The mix of sans-serif and serif looks out of place, especially in section headings. (IDC re: page title). Gadgets and CSS hacks to undo this are not suitable, I shouldn't have to login with every browser I may read WP on to correct this item. Wikipedia is one of the top 10 busiest websites in the world, forward facing changes like this should not be buried in a software update discussion at MediaWiki.org. Agree that many other changes were for the better, but this serif font is not one of them. --Robert.Labrie (talk) 23:18, 4 April 2014 (UTC)
Restore the old way. People above are talking about how "unreadable" this is. I strongly suspect none of them have done any actual readability studies (i.e. controlled speed vs. comprehension tests). So, I'm not going to say it's unreadable. But, I will say it's ugly. A subjective comment? Sure, but that's the way I see it.
Restore What kind of design team brings out a complex change without a fully implemented and tested way to disable the change for those of us getting eyestrain from the new style? I've already tried the new opt-out checkbox in Preferences, but I can't see that it has any effect. Yes, I know that I can start testing other skins. Hey, here is an idea, how about a skin called "Vector skin" that works exactly like the old vector skin? I've been heard to say before, the most dreaded words in the grocery store are "new and improved". Unscintillating (talk) 00:57, 5 April 2014 (UTC)
Restore The new typography is a disaster that makes Wikipedia look like a ransom note. Definitely need to do away with the unprofessional look of a serif font with text figures for H1 and H2, the decreased contrast (especially bad when reading off of LCDs in daylight) and the incompatibility with non-cleartype systems. For me the larger bread text also reduces readability but if there's a consensus for that aspect of the change I'd say it's tolerable, as long as it's consistently applied also to the UI elements in the left and top margin. The current subtle difference between the two makes it look as if it's a mistake. —WinTakeAll💬05:00, 5 April 2014 (UTC)
Rollback Ugh, main body text looks spindly & wispy..like a document printed in draft mode. This looks like a change that was approved by a self-selected group that all wanted change. As an non-account I've viewed the changes on a home desktop, home laptop, public library (all various windows/IE/ffox) & it looks like shit on all of 'em. 94.195.46.224 (talk) 05:37, 5 April 2014 (UTC)
Support Not that the old vector design was good, but this is worse. For me, and unlike the WMF, I admit that's the only way I can judge. Neither I nor the WMF have tested it on the usual run of unaffiliated readers. DGG ( talk ) 05:55, 5 April 2014 (UTC)
Restore Per Caesar. Besides, it is so ugly I do not even want to go read articles. Why was this done anyway, how about some consensus next time before making such a large change. THIS is consensus. Put it back75.73.114.111 (talk) 07:33, 5 April 2014 (UTC)
I commented below that I liked the look of the new headers at least when browsing in Safari but in looking again the text within the articles actually hurts my eyes looking at the default text in vector. The original text though in my opinion was always too small, which is why I usually use firefox with my own font and size settings.♦ Dr. Blofeld11:39, 5 April 2014 (UTC)
The serif heading, an the serif block quotes and huge quotation mark glyphs around blockquotes have to go. The latter violate MOS here, and it's wrong on other levels (not all types of quotations use the same level or style of quotation marks, and some already have them inside as part of the content. WMF can do whatever it wants with MW (hardcoding double-quote glyphs for blockquote is still dirt-stupid, because it wrecks non-English usage), but WP's own implementation of MW needs to undo at least these changes. There are probably other problems I haven't noticed yet. — SMcCandlish ☺☏¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼ 12:14, 5 April 2014 (UTC)
Restore. It ain't broke, don't fix it. The Serif heading font has a visible anti-aliasing issue, which I don't recall the previous Sans Serif heading font having (I've had font smoothing switched on for the entire time). In this instance, I would rather that the technical editors spent more time being less technical and more encyclopedic, particularly with regard to stub articles. I'm using FF28 on Win7HP with cleartype switched on, otherwise all default. EP111 (talk) 12:57, 5 April 2014 (UTC)
Restore. The most immediate concern for me is that when less fits on a page at one time, it gives a most unwanted advantage to those who like to say that articles and sections are too long. Broad overview and skimming of large encyclopedic topics takes time. SMcCandlish also makes a great point that you're confusing content and presentation from the point of view of those who see the quotation marks as part of the content. Last but not least there is a process issue: the whole point of having "skins" is to allow personal choice. When you decide to radically change a skin, you should create the new skin with a new name (maybe "Vector2") and give people the chance to try it out. Then you get feedback and see if you want to take the bigger step of making Vector2 the site default. Then, after a long delay, if use of Vector falls below some threshold, you can consider discontinuing the old skin. P.S. Whatever else, please, just don't mess with my MonoBook. Wnt (talk) 13:04, 5 April 2014 (UTC)
Restore, please ... and quickly. A lot of our students had trouble with this on Friday. We don't have the option of going around fucking about with the prefs for hundreds of accounts and computers. You can say this change was "visible" to many users as much as you want, but you're only deluding yourselves. VE Mk2 in all but name. Black Kite (talk) 14:03, 5 April 2014 (UTC)
Restore. The font used is important for the entire readership of Wikipedia. If it ain't broke, don't fix it. Given that some unregistered users have come here to talk about readability issues with the new font, I think we should change it back. (Personal reaction to the new font: nope.avi + switches to Monobook. Beginning to like it, honestly. Ah, such fond memories of using it some years ago. Don't really wanna change back, unless the old font returns.) Double sharp (talk) 15:40, 5 April 2014 (UTC)
Restore. It looks dreadful. The leading in the new quote boxes expands the text to such an extent, they start to dominate the page. Overall, it did my head in so much, I thought I was losing vision in one eye. JG66 (talk) 17:49, 5 April 2014 (UTC)
Changing my vote to restore. I initially opposed the poll, given how I could just customize my personal CSS to restore the old look. Seeing how a rollback CSS was never planned concurrently with such bold changes, however, I have to change my vote. Whisternefet19:29, 5 April 2014 (UTC)
Restore - I agree that a typography refresh is warranted, however, this particular 'refresh' was very poorly devised, and looks downright horrid. I think it is time to go back to the drawing board, and come up with something that suits the needs of the project. RGloucester — ☎19:56, 5 April 2014 (UTC)
Restore – the motivations escape me (I regularly use Ctrl + + when I want to lean back and read from a distance with a USB mouse.) Supposition that people with vision issues wouldn't have found a way is borderline patronizing. Neitrāls vārds (talk) 20:56, 5 April 2014 (UTC)
That is exactly the point. The font can be fixed easily. The attitude that is behind this change cannot. Wikipedia has now become as intrusive as Google. ♆ CUSH ♆21:09, 5 April 2014 (UTC)
Restore Speaking as one who has reading glasses positioned at several locations in my home I was able to read the previous font just fine. This new one, though marginally larger, is much more difficult to read. MarnetteD | Talk21:16, 5 April 2014 (UTC)
Restore I support changing the font back, as not everyone needs to have a big font and such a mix a fonts with so many bugs, and which is more difficult to read. NemesisIII (talk) 21:20, 5 April 2014 (UTC).
Restore. Although I am normally one of the "Wikiluddites" that User:Jayron32 referred to below, I am not against font changes per se. However, this particular change was not done well. My own specific complaints about the new fonts are few. The font is too large and the colo(u)r is a shade too light which strains my eyes. I can solve these by shrinking the text via CTRL + but since the font size of the toolbars is relatively smaller, it then makes them a little difficult to read. My bigger issue was how the changes were tested and implemented. I am a frequent reader and contribute a bit, but because I don't read the newsletters or wherever else this change was posted, I never knew of the change until it after it had happened. Evidently other registered users had the same experience. (This does not even include the vast pool of non-registered readers who it is highly unlikely would have known.) The "you should have known" arguments are just a version of blaming the customer for a bad product. WMF, own up to this fuckup, retract the changes and give them a proper hearing with a flashy banner just like you do when you want my money. — AjaxSmack02:50, 6 April 2014 (UTC)
I just had a useless banner add reading "WikiConference USA will be held on May 30 - June 1, 2014." pop up. Why not use those for things that are actually important to the vast majority of readers. — AjaxSmack03:11, 11 April 2014 (UTC)
Restore - I've stuck with monobook all these years and I'm glad I did. But I have been introduced to the new look and it's so out of sync with common sense so here I am with my comment: serif is hard on the eyes so I avoid it. --Rosiestep (talk) 03:25, 6 April 2014 (UTC)
Restore - I'm just a user/reader, but I use this wonderful, democratic site at least twenty times a day. My complaint is mainly with the text bodies, rather than the headings. The text is truly difficult to read. The preference code offered here is apparently to change the headings. The text is the biggest problem for me. Also, I am not a programmer and have been able to only make small edits, which is fine, but I don't know how to insert code like that offered on this page. Please, Please, all you who are skilled at editing these pages, and seem to know the politics here, get the old format back. I will ever be in your debt. Smaxam (talk) 04:36, 6 April 2014 (UTC)
Restore body font to sans-serif (from Liberation) and change back font size to 0.80-0.84em. The new font looks childish and is very hard to read (words are too much spaced out). Piotr Jurkiewicz (talk) 09:39, 6 April 2014 (UTC)
Restore - I beg of you. As a former newspaper person; I feel compelled to say that this is an unsettling font. I have never liked serif and I cannot be forced to learn to like it now. This looks as if your pages broke out with prickIy spines. I agree with Rosiestep above. Serif font is hard on the eyes. Make it go away. Fylbecatuloustalk12:42, 6 April 2014 (UTC)
Restore. Ugly, ugly, ugly. Either all serif or all sans-serif, none of this in-between crap. At least give us some choice. IgnorantArmies13:14, 6 April 2014 (UTC)
Restore - When this change came in I tried changing the zoom on my browser to get the size back to where is was, I personally prefer the old font as well. The biggest problem I have with the size is that it makes reading articles, checking watch lists and general editing more difficult. It means less content per screen and therefor less ability to read as much/edit as much per screen which reduces the readability and edibility of wikipedia. It should be optional how big the font is, but if that is not possible it should be smaller as a rule as users can zoom in or use magnifiers if they so choose, AFAIK there is no ability to get a shrinker for a browser but it is possible to get a magnifier. Sport and politics (talk) 10:56, 7 April 2014 (UTC)
Restore - I find the serif headers combined with sans serif body text very unusual, and therefore very, very distracting. -Well-restedTalk02:18, 8 April 2014 (UTC)
Restore This new look is ugly, childish and unprofessional. Who in their right mind would use a different font for titles and text (with a good reason)? Jimp10:04, 8 April 2014 (UTC)
Restore - I have perfect eye vision but I can hardly read a article with the current front. Not to mention the watchlist. Frankly it is all a mess right now.--BabbaQ (talk) 17:21, 8 April 2014 (UTC)
I actually think the titles/headers look much better now with a different font although I think they're a little too large it's the text within the articles which is substandard.♦ Dr. Blofeld10:45, 8 April 2014 (UTC)
Restore font size. I don't think Wikipedia should appeal to people with an attention span of barely a paragraph or 140 characters. The larger font size requires way too much scrolling and eye movements. At least be consistent and reduce the font size of the other text on the page as well so I can use the browser's zoom functionality to get a readable appearance. 130.83.33.136 (talk) 14:00, 8 April 2014 (UTC)
(Weak) Restore — "weak" because I realize others may have more persuasive reasons than simply aesthetics. Just from a "look and feel" perspective, I don't like it. I tried it for a few days, but it just looks kind of "wrong". I miss the old skin. And when I go to Preferences/Gadgets and select "Classic Typography Vector Skin" I see the new look for a moment before any page loads. Meteor sandwich yum (talk) 18:20, 8 April 2014 (UTC)
Restore. Another user who finds the larger font sizes harder to read. At first I thought it was a mistake or my browser had zoomed in by accident but then found out it was intentional. I also had no idea of the change before it took place. At least it hasn't been done to the other skins, like MonoBook (yet). —StalwartUK02:18, 10 April 2014 (UTC)
Restore the old font, please. As a person who is knowledgeable about the reading process, I can tell you that the shape of the letters in a font affect the speed with which people can read. Except for beginners, readers don't look at the individual letters in the words when reading, but instead learn to perceive whole words and even phrases by their general shape and configuration. There is considerable scientific evidence to back this up. The old font had letters that fit together smoothly in a way that facilitated whole-word recognition, allowing the eye to pass smoothly and swiftly over the text. Serif fonts are best for this on paper, but don't always render as clearly on screens. The more rounded and pleasantly shaped letters of the new font call individual attention, and in some cases the eye dwells instead on the white space between the letters, making the reading slower, and requiring more concentration to progress through the text. The title font, while stylish, is distractingly different from the body text and seems unnecessarily large. —Anne Delong (talk) 03:05, 11 April 2014 (UTC)
Regretful support for rolling back locally, and encouragement to the WMF to roll the fonts back to plain sans-serif for both body and headings on all wikis. I have given it a week to bed in, but it still seems like no improvement over the old typography; in fact, the mixture of some serif headings and sans-serif body and the other headings still looks ugly, and the old-style figures in headings are very much worse. It isn't broken on my system, but just look at the volume of complaints on any Wikimedia wiki—particularly non-Latin ones, and don't forget the 90-9-1 principle—and it's obvious that a lot of readers saw unacceptable results, and given the complexity of the configuration space I'm not sure there aren't more major bugs lurking. Telling people reporting breakage to uninstall font X is not a sufficient solution. (How do we plan to reach non-technical users? Are people who want the fonts installed, for whatever reason, expected to maintain two configurations and switch back and forth to browse Wikipedia? What about users who don't have administrator access on their machines?) The use of non-free fonts is also troubling: there's a significant difference between requesting a generic font but shrugging our shoulders if the client uses a non-free one, and requesting a named non-free font specificially ahead of free ones. I have difficulty squaring that with Wikipedia's mission to promote free content. I understand there are technical reasons, but this is why I suggest returning to asking for a generic sans-serif and leaving it up to the client to pick an appropriate font that a) works, b) appropriately handles languages which do not use Latin scripts, and c) will not unnecessarily encourage the use of non-free content. (The spacing and size changes I'm not concerned about: again, I can't see them as an improvement, but at least they're not harmful.) Facing the Sky (talk) 10:52, 11 April 2014 (UTC)
Restore - I am a user who is posting here because I cannot find any forum on this site for people like me to post opinions on the font change. First, there are a few here who are adamant that sans serif fonts are better on the Internet than serif. Why? Although the experience of reading on a screen is somewhat different than reading paper print, I don't think it's that different. Serif fonts were invented to make identifying letters easier. They've been around for centuries. The use of sans serif for text bodies is, I think, recent. And is that simply the tyranny of "cool"? Second, there are some here who rail against mobs and personal preferences. And I thought Wikipedia was a bastion of democracy. Well, mobs having personal preferences are people using this site, and what they want should count. To call us "mobs" sounds pretty undemocratic to me. There is an amazing democracy of accuracy here, unlike anything else I have ever seen. The truth will out, sooner or later, and so if we wait long enough, maybe the original font will return. However, in the meantime, I have found a Wiki page where the Idiot font seems appropriate: https://wiki.riteme.site/wiki/Dick_and_Jane. By the way, all you sans freaks, keep in mind that this page in edit mode, and all of your programming code, is all done in Courier, which, ahem, has serifs. Smaxam (talk) 07:16, 17 April 2014 (UTC)
Restore. The body text font, Neue Helvetica or whatever it is, looks fine viewed with Firefox v.28, HOWEVER, it is a disaster viewed with Google Chrome v.34 (my preferred browser), and with IE v.11, all on my Win7 boxes with a Samsung, Dell, and ViewSonic monitors. The kerning (spacing between letters) of the font on Chrome and IE makes text very unpleasant to read. Especially bad is the kerning following lower case "d", "l", "r", and "t" (which appears to be none at all); most characters that follow them literally fuse with them making goofy, hard-to-read ligatures. Two charcters in the font in these two browers are in and of themselves poorly drawn: lower case "k", which is very narrow, and the lower case bold "m", which has uneven spacing between the stems. ---- I don't know the technical issues involved, but why weren't fonts that are universally compatible with all major browsers and operating systems selected? --- I could rant further, but won't because there seems to be plenty of other complaints. PLEASE RESTORE THE OLD FONTS ASAP. Choosing Wikipedia fonts that are only compatible with FireFox was an idiotic decision.Charvex (talk) 07:28, 17 April 2014 (UTC)
Restore. I thought I'd get used to it, but every day I miss the readability and scannability of the old typography. With the larger text I find myself scrolling much more. And with the newly introduced inconsistency between bread text and UI text, UI text becomes unreadable if I zoom out to a reasonable bread text size. And what's with the inconsistent fonts between section headings and subsection headings? Subsection headings now look more prominent than section headings. I understand there are technical ways to work around these new problems for motivated technical users who create accounts and change settings and program CSS, but what about the 99% that just want to read or scan an article? 2602:30A:C0AC:1C70:BC07:DBCD:7F40:27E (talk) 09:37, 20 April 2014 (UTC)
Please Restore. I was not aware of the impending font changes, there was no user notice inviting people to test the beta. The proper thing to do would have been a controlled beta test for all users, and you would have found that most people prefer the old font. Karpouzi (talk) 16:09, 21 April 2014 (UTC)
Oppose changing back to original font
If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
Oppose poll Because polls of angry mobs don't give useful statistics, and only those unhappy tend to show up on locations like this in situations like this. —TheDJ (talk • contribs) 20:29, 3 April 2014 (UTC)
Comment - It is not angry mobs, but it is people's opinions. Shouldn't we listen to what people want to say? It is something that affects each and everyone of us, actually. Hafspajen (talk) 03:28, 4 April 2014 (UTC)
Conditional oppose. I like the new font, but the new title font needs to go. I almost threw up in my mouth when I saw that big ugly serif font juxtaposed against everything else. ProtossPylon20:31, 3 April 2014 (UTC)
Oppose poll this feature went through a huge discussion process. If people weren't involved they should make sure they get more involved in future. I worry reverting this change will result in nothing ever changing in Wikipedia and a loss of faith in the beta features process, no innovation and will ruin morale of all those involved in the discussion process. Also the change from my perspective is beautiful. Jdlrobson (talk) 21:20, 3 April 2014 (UTC)
I missed the discussion on our non-English Wikipedia. As of right now this font is causing me accessibility issues (I have enough trouble reading the text to stop reading and to stop editing). I love redesigns, and beauty is often a matter of taste, but this typography is causing me problems and is not too usable. Ahappylittletree (talk) 21:33, 3 April 2014 (UTC)
I work on putting content into articles and creating new articles on WP, nobody got my attention to tell me or ask my opinion of this impending change, you did not do a good job of getting that news to everybody, you should have put one of those banners that comes up across everybody's watchlist, that's the only way I see such things. I worry reverting this change will result in nothing ever changing in Wikipedia - why should things change for change's sake? a loss of faith in the beta features process I don't even know what that is, but whoever put this change through ought to have faith lost in them no innovation and will ruin morale of all those involved in the discussion process - there is nothing good about "innovation", ie messing around with things that don't need messing around with, just for itself. Apparently you are saying there is a project on WP which is devoted to thinking up "innovations" for stuff that is just fine the way it is and they will have their feelings hurt if this change is rejected. Tough. Also the change from my perspective is beautiful. the change from my perspective sucks.Smeat75 (talk) 13:12, 4 April 2014 (UTC)
I strongly oppose reverting the changes. I'm not saying I am blindly supportive of all the changes, but the overall effect is to have a consistent font scheme, especially across different systems. This is a much better situation than the one preceding it. If people take issue with the particulars, they are free to adjust them personally via their personal vector.css pages. {{Nihiltres|talk|edits}}21:56, 3 April 2014 (UTC)
Oppose poll Too much impassioned prattle here because the questions users are addressing in this forum are too arcane for them to fully grasp. The really interesting feedback lies not in opinions users express on launch day, but in their behavior over time. Deploy, measure, improve, repeat. Agile, y'know? 76.109.141.132 (talk) 22:08, 3 April 2014 (UTC)
Oppose It was a little weird at first (I had my font set to the quite small Calibri before) but having used the beta for a week or so it has grown on me. I do think the slightly increased size and leading is more readable once you get used to it. the wub"?!"22:39, 3 April 2014 (UTC)
Oppose Beta was extensive. Lots of notice was given to roll-out. The new default does what it advertises in the way of readability. Win for the developers. Saffron Blaze (talk) 22:54, 3 April 2014 (UTC)
Oppose We need the site to look better and we need to start accepting more creative answers and get professional design help doing so. And in doing so, perhaps we gain more diversity in editors the process. Jooojay (talk) — Preceding undated comment added 23:08, 3 April 2014 (UTC)
Oppose: Honestly, I prefer the new layout, and with the gadget to turn it back to the old font if you want, I see no reason to switch away from here. I know, I know, WP:ILIKEIT isn't a valid argument, but I don't know how else to put it. Supernerd11:DFiremind^_^Pokedex00:07, 4 April 2014 (UTC)
I think the deployment of the new typography changes was well handled and for the better. But what I really want to say is that this poll has a problem with selection bias. Anyone who likes this change, or is indifferent, is far less likely to head to VPT and comment than anyone who dislikes the change. (That's what TheDJ is saying, I think.) — This, that and the other (talk)00:14, 4 April 2014 (UTC)
On the contrary, the beta had an even more severe problem with selection bias, since the consensus it supposedly established was only informed by the small minority of users who entered the beta. By contrast, the people complaining now are from the entire community, since this change was forced onto everybody. —Lowellian (reply) 20:18, 5 April 2014 (UTC)
The same Wikiluddites show up anytime any change is ever made. The more I read the comments of the people who want to change this back, the more convinced I am WMF made the right decision in the first place. --Jayron3201:46, 4 April 2014 (UTC)
Per TheDJ. This is silly. Although I hate serif fonts and think the change should be reverted, I loathe making software decisions by mob rule. ^demon[omg plz]01:52, 4 April 2014 (UTC)
Per others. Not a good reason for mob rule. Also, I still use Monobrook because most of Vector sucks. This change isn't one of them, and I sort of which I had it by default on Monobrook. Resolute02:04, 4 April 2014 (UTC)
I have been trying out the new fonts in beta since the Signpost article came out and discovered I am able to reduce my zoom from 125 % to 110 % so there's an obvious improvement in readability for the weak of eye. Less zoom means that more of the article fits on the page, which is good. On my set-up (Toshiba laptop running Vista) it works better in Firefox than in Chrome. -- Diannaa (talk) 02:22, 4 April 2014 (UTC)
Interesting. I had just the opposite experience: my font is smaller and narrower and thereby less readable. I was using Verdana, a screen font specifically designed for screen readability, and it worked great on my Firefox/Mac combination. The new font (I have been unable to identify it; I copied a section of text into Word and changed it to Helvetica Neue, Helvetica, and Arial without finding a match) is smaller, much narrower, and aliased. I suspect that some of the different results that people are reporting are due to font interactions such as mine. I have enabled the "opt-out" gadget for now, and everything is fine again. I look forward to a more refined version of this typography refresh that addresses problems such as the one I experienced. (I do like the new spacing between lines; the old mix-and-match spacing always bothered me.) – Jonesey95 (talk) 03:07, 4 April 2014 (UTC)
That was my experience too when using Chrome. At 125% zoom the letters are clunky and horrible, and at 110% they are too small - illegible. But I got it to work in Firefox. Chrome is a better browser though for several reasons (handles scripts better, does searches better), so now that there's a gadget available for "classic Vector" I will be opting out of this change, at least for now. -- Diannaa (talk) 03:23, 4 April 2014 (UTC)
Thanks for the link. It will probably help others diagnose their font issues. I am using Liberation Sans, which I didn't know I had installed. It's pretty, but Verdana is much more suitable for screen reading, at least with my OS and browser combination. – Jonesey95 (talk) 14:49, 4 April 2014 (UTC)
Oppose These changes are tested on millions of users and based on sound, common typographic principles. Well-tested changes shouldn't be reversed because of a vocal minority's taste, or a knee-jerk opposition to WMF making changes. MAssaf (talk) 02:28, 4 April 2014 (UTC)
Oppose poll Nothing good ever comes from immediate polling based on knee-jerk reactions and I Don't Like It So You Shouldn't Have It. This is a good read. Spoken as a volunteer. Keegan (talk) 03:01, 4 April 2014 (UTC)
Oppose This work has been trialed for 6 months, creates consistency between desktop and mobile. The size change is very critical for non latin scripts. Vibhabamba (talk) 04:34, 4 April 2014 (UTC)
Oppose Your getting an amazing service. If you are editor there are bigger things to worry about. Let designer's do their job. Get a life. — Preceding unsigned comment added by 70.36.196.229 (talk • contribs) 23:48, 3 April 2014
Looks good and very readable! Plus: it improves the overall look and feel, since it reuses the same font as used in the Wikipedia Logotype! Good job!--86.103.213.5 (talk) 08:22, 4 April 2014 (UTC)
oppose A gadget has been created for those who do not like it to opt out. Move on , leave this issue alone and get back to building an encyclopedia. Personally, I find the new font looks better than the old font... --Mdann52talk to me!10:56, 4 April 2014 (UTC)
This does not look horrible on my system. Oppose changing back, typography refresh is as easy to turn off as any other feature. It has a feedback channel.
If you would like new features (visual editor, typography refresh) to be easier to turn off, design and propose your thing for them all.
If you don't like current font, please use the typography refresh beta channel, not a village pump. Do proper multi-project outreach to gather comprehensive view on your subject put constructively.
Admittedly I don't appreciate you abusing the bulk of people who don't like new features through mailing lists@DGarry (WMF): for example. Okay, many won't like. They shouldn't complain here, they can give feedback at the feature's feedback channel.
Admittedly I don't appreciate it being removed from the beta tab. It provides easy access to disable and share feedback.
I like the new font for body text. The headings still look a little weird to me, but that will pass and I understand the rationale for using serif font there. older ≠ wiser12:25, 4 April 2014 (UTC)
Per TheDJ. Personally, I find I have to give myself some time to overcome the "Oh no, change!" reaction. For example, I recently uninstalled some fonts and installed others on my system which resulted in Gmail using a different font for me (Arimo rather than Arial). It took a while, but I've stopped being distracted by the "different" look. For the same reason, I haven't gone and changed my fonts or skin on mediawiki.org or other wikis where I've been using Vector to see how it goes after a few weeks before forming an opinion. Anomie⚔14:07, 4 April 2014 (UTC)
Oppose, both because polls like this are not the way to make software decisions and because I actually like the typography refresh. My initial reaction was "Ugh, this looks awful". But now that I've tested it for a few days, I'm actually thinking of permanently switching my skin from Monobook to Vector for the sole reason of using the updated typography. It really does make the site look a lot more readable. Note: I am WMF staff, but in my staff role I was not involved in the development of the typography refresh in any way, shape or form. Comment made solely as a volunteer. --(ʞɿɐʇ) ɐuɐʞsǝp18:52, 4 April 2014 (UTC)
Nah leave it. Let the WMF design team fix what is broken, if anything. This project is just one project, and the WMF needs to be able to prod along design development on all projects. Otherwise, as we've seen, individual projects like en.wp have a tendency to get stuck in the ugly past because many users are change-averse. Nathan T 20:10, 4 April 2014 (UTC)
Oppose; the new changes have reasoning behind them and it seems to be sensible stuff. Personally, I don't much like it now, but I am very, very sure that I simply won't notice by next week and by May I'll look at a screenshot of the old style and wince. (This is exactly the same reaction I had to Vector over Monobook). Overly-fast negative response to change is one of our weakest points, and this seems a great example of it. Andrew Gray (talk) 20:28, 4 April 2014 (UTC)
Good to know that the local flash mob showed up with their pitchforks and torches. In a month, no one will notice that the fonts have changed. --Guerillero | My Talk23:35, 4 April 2014 (UTC)
Good to know that the impending change was widely circulated, with a lengthy preview period before it was made default. Oh, wait, it wasn't! Ergo we're not an angry mob, but rather people who were totally blindsided by a change. Thanks. --Robert.Labrie (talk) 23:42, 4 April 2014 (UTC)
How do you even expect that one of our 30,000 visitors a minute somehow comes to know that a (possibly disastrous) font change is on way, and then at the same time knows a certain "Mediawiki" exists, and at the the same knows that there is such and such (talk) page and the same time knows some guys over there are willing to welcome their opinion? We editors can get away with scripts or preferences if we wish to, but what about our readers? Was there any feedback (the sort of Article feedback tool or surveys, not the kind of discussions on hidden talk pages) from ip users conducted? How can we know what the readers feel? How many of our readers use HD monitors, have installed opensource fonts, love Helvetica, to derive some benifit out of all this? Fauzan✆ talk✉ email08:04, 5 April 2014 (UTC)
Agree with Fauzan. A talk page at MediaWiki.org is hardly widely circulated. There are banners for donations, for wikimania, and for the wiki picnic, but you couldn't do a "Preview our new look and feel" banner? Come on. --Robert.Labrie (talk) 11:55, 5 April 2014 (UTC)
I've probably visited the mediawiki only a handful of times at best... Would I go there pre-emptively to read about an upcoming project wide change so I can get my feedback in time? The font roll out was largely first time the vast majority of editors that it affected found out about it. The feedback and testing should have been equally as broad. Mkdwtalk19:30, 5 April 2014 (UTC)
Another ridiculous over-dramatic response. I don't like the new font. I find it harder to read. I expressed my opinion. OK? I do not appreciate being labelled as part of a "mob". 86.176.213.239 (talk) — Preceding undated comment added 00:02, 5 April 2014 (UTC)
Flash mobs are organized. Every dissenter on this page, from admins to casual users, came here as individuals. I think it's disrespectful to cast off their thought-out concerns as a "mob" mentality. - HappyWaldo (talk) 01:07, 5 April 2014 (UTC)
Oppose; There was a bug for Windows 7 Professional 63512 where ClearType was an issue, it looks like it's fixed now so I'd say keep on the good work. - Martín
The Typography Refresh is good. Don't revert. The larger font is more readable, and that's the direction of the web in general. Larger screens—larger fonts. The wider line spacing makes the text more readable as well, and it's particularly good for Wikipedia, because we have a lot of footnote references and a lot of text in non-Latin scripts which need wider lines. Headings in serif make quite a lot of sense to me as well. There are always more things to improve, but this is a step in the right direction. It's not just a matter of taste, because this was successfully tested with thousands of people as well. (Disclaimer: I also happen to be a paid developer in the WMF, and the people who implemented this change are my colleagues and friends.) --Amir E. Aharoni (talk) 08:15, 5 April 2014 (UTC)
I Oppose changing rolling back the design changes. Design decisions are better left to designers. No committee vote in the world will ever lead to a usable design, since there is always some reluctance to get used to the new and the different. I'm sure all those uncomfortable with the new design will start liking it soon. There are a lot of things that the designers must have taken into account after a long period of testing, and an inconsiderate knee-jerk reaction could deprive us of those benefits that would soon become apparent. Give it some time. thegodofbigthings (talk) 10:50, 5 April 2014 (UTC)
Comment I hadn't noticed any changes on firefox as I have it set with my own font but I often browse wiki on safari as I like the reader and my opinion is that the new article headers at least are an improvement and look more stylish, although I agree that the text in the articles itself looks a bit strange and blurry.♦ Dr. Blofeld11:37, 5 April 2014 (UTC)
oppose poll We had a a test with over 10,000 participants, and who knows how many more reading and deciding not to participate. A beta link on top of every page that every editor should have noticed. A writeup in Signpost. A straw poll with only 1% the number of active participants, never mind the much larger number aware of the update, cannot and should not be allowed to roll back this exceptionally well tested and advertised update. As already noted if you don't like the update there are many things you can do depending on exactly what you dislike about it.--JohnBlackburnewordsdeeds13:28, 5 April 2014 (UTC)
I'm pretty sure they said it was a trial and 10,000 people would have seen the changes. Not participants or that they gave feedback. And if the statistic is true that 1% of those people "participated" in some sort of feedback you're talking about an insanely small number of people. According to Wikipedia:Statistics, in a given month there are approximately 116,835,000 visitors. I don't even know how low of a percentile that represents against the readership. The changes should have been as widely posted as the donation banner and a rapid feedback multiple choice poll with a side by side comparison been done. Mkdwtalk19:43, 5 April 2014 (UTC)
The trial was on an opt-in basis only, via Beta Features. 800 editors here, and more than 14,000 total, opted-in to the changes, and the number grew over the five months of the beta. As for who gave feedback: you can see for yourself at the Talk page and it's two archives that there were more than 100 threads of feedback which we've responded to, before we launched. There were also extensive discussions on the public community mailing lists for design and technical issues. We released three major different versions of the beta based on community feedback, and continue to make bug fixes since we released. As for a banner and poll: we release new software every single week on Wikimedia projects. This is one of the changes that is a default across all wikis. Running a poll beforehand is simply not feasible for every new feature or change. Wikimedia projects have hundreds of millions of readers every month, and there are more than 70,000 active editors. Asking a majority of people their opinion is not only not possible, but even if we didn't we would not get a major representative sample of readers. That doesn't mean we didn't take this change seriously, slowly, and didn't actually get any feedback from people who use the site every day. Steven Walling (WMF) • talk23:33, 5 April 2014 (UTC)
Steven when breaking your figures down to percentage wise against daily readers, active or and semi active editors your figures represent nowhere near a consensus, of the people who opted in how many removed it after opting it, how many gave you active feedback that they liked the change, how many told the WMF that they felt it should be permanent, Did the WMF actively try to engage the 14.000 editors to get the full information on this, as you say not everyone unless directly asked posts to a talk page. The figures when broken down aren't impressive at all.Blethering Scot (talk) 00:20, 6 April 2014 (UTC)
What exactly was the purpose of forcing this change on every Wikipedia visitor on the planet? This change came as a bad surprise to almost everyone. Why was it necessary in the first place?
I do not understand how such a major change could be made without regard for how it will look on different browsers and operating systems. ♆ CUSH ♆00:10, 6 April 2014 (UTC)
Cush have you taken a look at the summary of changes and FAQ for this? It goes in a lot of detail about the problems to be solved, and why new element was selected and tested. We most certainly did not do this "without regard for how it will look on different browsers and operating systems". Steven Walling (WMF) • talk00:44, 6 April 2014 (UTC)
steven (WMF) yes I have read the summary of changes and FAQ. So what about the "legible and beautiful" part? Wikipedia now looks like the very first website attempt of an amateur in the 1990s. What tests have you conducted yourself? How could you have missed the all-bold look? ♆ CUSH ♆16:35, 6 April 2014 (UTC)
Oppose Everything should be switched by default to serif fonts. Sans-serif fonts fail to distinguish between "l", "1", "|", "I" properly. If we can't determine what page we're on by reading the title, what's the point? -- 70.24.250.235 (talk) 04:36, 8 April 2014 (UTC)
That would be a horrible idea. Serif fonts don't have a reputation for being slick/readable: I find it much harder to read them, to be honest. Cloudchased (talk) 23:14, 9 April 2014 (UTC)
I preferred the Arimo font at a smaller size (I was already using as my browser's default font), but I guess I'm still fine with this. Cloudchased (talk) 23:14, 9 April 2014 (UTC)
Discussion
I have been using this typography since it started being tested in beta and I have come to like it. My eyesight is not so good and I find it helps. Of course, it should not be aimed specifically for people like me but it is an aspect worth considering. I personally did not favour removing numbers from the sections in the table of contents (and I fed back on this) but I am still seeing numbers here so maybe that change was reverted. So, for me, I appreciate the change. Thincat (talk) 20:24, 3 April 2014 (UTC)
Well, "people like you" (and soon me too, maybe) were part of the reason, apparently, so that's a very valid comment. Drmies (talk) 20:31, 3 April 2014 (UTC)
There are obviously significant differences in perception or in the rendering between different systems because my eyesight is also not great and I find the new font harder to read, not easier. 109.147.187.61 (talk) 02:49, 4 April 2014 (UTC)
Hey Matty.007... I just wanted to address two things:
Regarding bugs, it is not possible for the font change to cause links to break. The code changes do not touch link behavior or styles at all. The link you mention in your draft seems to be working for me?
Have you checked out the Signpost piece about this? This change happened not just on English Wikipedia, but all versions of Wikipedia and other projects. It's been tested for five months, by more than 10,000 people here on this wiki alone. We had more than 100 discussion threads gathering feedback from the community across all wikis.
I think that when you take the great deal of discussion and iteration in to account, it feels a little hasty and contradicting WP:POLL to hold a straight-up vote when there was a long process based around consensus-building and testing by editors. Steven Walling (WMF) • talk20:29, 3 April 2014 (UTC)
But did you specifically test the most common scenario of all that I hinted at above? Specifically, a standard Windows system without any of the open-source craziness, but with Microsoft Office, Adobe Reader, and Internet Explorer installed. The vast majority of billions of barely computer-literate users out there still won't touch OpenOffice or LibreOffice with a ten-foot pole, and in the corporate world, most systems are rigorously locked down with Access Control Policies by understaffed, overworked IT departments who can barely keep MS Office running as is. Which means, if you specify Arimo, Liberation Sans, and Helvetica Neue, there is no way that more than a few percent of the WP user base is actually going to see those fonts. And then if you specify Helvetica before Arial on a Windows system running Adobe Reader (and keep in mind 75% of the computers out there run Windows), then Adobe Helvetica is what the vast majority of the WP user base is going to see by default, which looks absolutely hideous on Windows systems at less than 20 point, with or without ClearType turned on. That's a classic error and something most experienced Web designers learned to avoid back in the late 1990s, back when Acrobat was first taking off. There are screenshots all over the Web demonstrating how horrible Helvetica renders on most Windows systems at 10 or 12 point. I've added a screen capture to the right to illustrate the problem; if you had stress-tested the new CSS font stack from any FedEx Office or low-end public library system, the error should have been obvious. This whole debacle reminds me of my third favorite Bond film, Tomorrow Never Dies. Specifically, James Bond's words to Elliot Carver at the climax: "You forgot the first rule of mass media, Elliot! Give the people what they want!" --Coolcaesar (talk) 08:17, 4 April 2014 (UTC)
There are some mistaken assumptions I need to correct. 1) Adobe Reader hasn't come with a Helvetica (or substitute) for over 15 years now. If you see Helvetica on a stock Windows system, then something/someone else installed a bad Helvetica copy. It is safe to asume Windows does not have Helvetica, and is mapped to Arial. Helvetica is in the font stack to target Apple systems. 2) Default Windows installation since Vista have font smoothing enabled by default, just like ohter OSes, so i think we may asume that has become the default. Asuming there are no 'funky' fonts installed, the new font stack should show Arial. Those that do have Arimo/Liberation fonts (usually by way of OpenOffice), should see those fonts nicely rendered which font smoothing. Only with font smoothing disabled will you see problems, as non-Microsoft fonts are not optimized for display without smoothing. It is hardly worth the trouble optimizing fonts for pixel displays because they are rarely used anymore. Only the older MS fonts are optimized for that; their ClearType collection fonts (Calibri etc.) do not render well on pixel displays either. — Edokter (talk) — 12:05, 4 April 2014 (UTC)
Hi Edokter. Turning off font smoothing is an accessibility feature. Some people have trouble reading smoothed fonts, some people get headaches. People don't use this feature so they can have ugly fonts and something to complain about. It's there to disable for a reason.
If you want to target Mac, you can use Helvetica Neue. Computers with Helvetica Neue will generally have Helvetica. PC's with Helvetica (for use in Photoshop print) will usually not have Helvetica Neue. Windows support for rendering Helvetica is atrocious. Helvetica does NOT make any sense to keep in the font stack.
I have font smoothing turned ON. OpenOffice installed a version of Arimo. I see really crappy fonts.
Those with Libertine installed see really really crappy fonts, and unreadable fonts with smoothing turned off.
On the matter of: It takes some getting used to... If you read Wikipedia now for a long time and then read an Arial site, your eyes almost go cross-eyed: It's contagious! (Which leads me to believe there is a cognitive issue here too: I trained some neurons to scan Arial text for 15 years reading the web, these neurons are now crying faul) Ahappylittletree (talk) 16:39, 4 April 2014 (UTC)
Well, I stand corrected. Turns out it's not Adobe's fault, it's Hewlett-Packard's fault. I just manually traced this and it turns out the copy of Helvetica that's rendering locally is from the Hewlett-Packard screen font version of Helvetica, which is automatically installed by many (but not all) Hewlett-Packard printer drivers. (That would explain why this issue has been recurring for almost 20 years on a variety of Windows systems of all shapes and sizes, since Hewlett-Packard has the dominant market share for printers on the West Coast of the U.S., as in most areas of the world.) It's Hewlett-Packard Helvetica version 1.3, copyright 1992-1997. That version dates back to the dawn of the modern subpixel rendering age, which explains why the font hinting is so terrible. But the fact is that the Wikimedia Foundation has to adjust to what the majority of users have, which is HP printers and HP drivers, not the other way around. Telling people to change printers is not going to cut it. --Coolcaesar (talk) 13:01, 4 April 2014 (UTC)
And I almost forgot to add the most important point of all; WP is a nonprofit site competing for users' limited funds and attention, which means you need to always keep in mind what keeps readers happy on the largest percentage of systems. If WP stays with a stylesheet that is unreadable on about 65% of the systems out there (and most users are passive users who are too damn busy to figure out how to set up a WP account and customize WP's appearance), the Wikimedia Foundation can kiss its audience and donations goodbye. Which means EVERY major design change should be deliberately stress-tested on the most common plain vanilla, last-generation computer configurations out there (which I acknowledge is a pain in the neck). Beta testers aren't much help because most of them by definition live on the bleeding edge of technology. --Coolcaesar (talk) 08:46, 4 April 2014 (UTC)
I'm not one to complain about what goes on in changing the appearance of the site, and doing so most undoubtedly makes developers' jobs more stressful. But, I feel I must say I dislike the new font. It simply doesn't appear as clean. Now, I won't ask for it to be reverted simply because I don't like it. It would be nice, however, to have a gadget in "Preferences" to go back to the old font. That's just my two cents. Tyrol5[Talk]20:33, 3 April 2014 (UTC)
@Steven (WMF): Would a preference not be a possibility, not everyone has the same eyes and some text fonts impair/hurt more than others. For instance i find the new font to be worse for my eyesight than the original. Forcing one over an other isn't the best idea or practice in reality.BletheringScot21:09, 3 April 2014 (UTC)
I have an issue - I added the vector code to get the old font, but in the edit interface, I have some alternate font; is there a way to get the old editing window font too? GoPhightins!21:31, 3 April 2014 (UTC)
Hmm. The preferences related to the editing interface should not be changed at all. Can you hard refresh to clear your cache, and maybe share a screenshot with me? I will try to help debug. Steven Walling (WMF) • talk21:51, 3 April 2014 (UTC)
So Steven, about 8,000 editors on this wiki opted-in to try it, out of 48,310,517. That's roughly what, 0.017% of this wiki's users? Since you said it's been being tested for almost five months, I'm less inclined to base those stats on users active in the last month, but even if we do, 8,000 out of 122,731 (6.518%) isn't really that spectacular of a number either... — {{U|Technical 13}}(t • e • c)12:24, 4 April 2014 (UTC)
From what i can tell, those 14k and 8k numbers are actually counting the people who tried beta. But the way i read the question, it asked about how many of the users who were exposed to the change (being in the beta) gave specific feedback that they like it (or at least kept the new fonts enabled, in case no such feedback was collected)? -- Jokes Free4Me (talk) 18:36, 4 April 2014 (UTC)
This is not only about webdesign, it is also about how the WMF treats Wikipedia users. We were not asked beforehand whether we would approve a different typography at all. It was tested in Beta status which means that the vast majority of users did not even learn about the changes coming up. I tried it out and switched beta typography off immediately because the TOC was completely unusable. The WMF will not succeed in imposing changes of this magnitude without a prior community consensus. We've been here when you tried to force users to work with the visual editor only, and failed. I suggest you switch back the serif headings to sans, and leave the rest as is now. Please think again. Thanks.--Aschmidt (talk) 21:59, 3 April 2014 (UTC)
I looked at the redesign rationale, and the screenshots there (coupled with the use of Helvetica as a fallback, which renders horribly on Windows) lead me to believe this redesign was done on a Mac or Linux. Chrome + Windows show all sorts of typography errors like faux bolding, different spacing, poor hinting, poor anti-aliasing and references hugging image-borders above them. See: Screenshot. Where can I contribute to get this fixed? The old situation on Linux + Firefox looks poor indeed, but could easily be handled by putting "nimbus sans l" in front of "arial". The same with "helvetica neue" for Mac. Ahappylittletree (talk) 22:10, 3 April 2014 (UTC)
Hey Ahappylittletree. The FAQ lists all the browsers and operating system combinations we tested this on. We did test the change on laptops with Windows and Chrome. Our developers do tend to either use Linux or OS X, but we always test on Windows since they're obviously very predominant among all Wikipedia users. Steven Walling (WMF) • talk22:47, 3 April 2014 (UTC)
Hi Steven Walling. I found the problem that is causing the font weirdness. To reproduce: Install Arimo 400. Do not install Arimo 700 (bold) or Arimo italics. This will cause the body text to render in Arimo and uses faux-bold or faux-italics for the rest. I don't see a cheap fix for this. My use case may be rare, but it is what it is, and really hampers legibility. Thanks, Ahappylittletree (talk) 23:25, 3 April 2014 (UTC)
@Steven Walling (WMF) Another unforeseen problem is users who installed Arimo before the "improved hinting"-update from May 2013. Windows 7 (standard no font-smoothing) may show these users something like this: Arimo beta on Windows 7 with smoothing off (BTW: Segoe may be a far better fallback than Helvetica, one being optimized for web, the other a print font that fares really badly on Windows) Ahappylittletree (talk) 00:34, 4 April 2014 (UTC)
Two condions must be met for that to happen: 1) user must have turned off font-smoothing/ClearType, which is enabled by default since Vista, and 2) user must explicitly install Arimo, which is an exceptional situation in itself. Usually, people that do install fonts like Arimo know what they are doing and know how to make it display properly. — Edokter (talk) — 00:38, 4 April 2014 (UTC)
1) Yes, I once turned it off (it is a valid configuration option, though I don't know exact stats). I also still use the classic accessibility theme. Should I change my settings so I can read Wikipedia again? 2) Arimo is not loaded from Google Webfonts right? So if installing Arimo is an exceptional situation, why even include it? To install all variants of Arimo or to install only a single variant shouldn't be so different (the latter causing problems). Installing a font is easy. Figuring out why Wikipedia won't display readable text almost a year later is a bit more difficult. Forcing me to install all variants, uninstall Arimo 400, or add a stylesheet to my user preferences, so I will see legible text only when I am logged in, is... not user-friendly. Once again, appreciate all the work, but also once again: I am not creating edge cases just to be a pain. This happened to be my use case. Ahappylittletree (talk) 01:06, 4 April 2014 (UTC)
Edit: I never explicitly installed Arimo 400. Arimo 400 (and only Arimo 400, no other variant) is installed by OpenOffice. So this may not be a rare use case at all. Ahappylittletree (talk) 01:24, 4 April 2014 (UTC)
If you have OpenOffice, you also have all variants of Liberation Sans, which are actually another version of Arimo. So if you have Liberation Sans, you can safely disable or remove Arimo. It may still render not so well, but free fonts were never designed with no-font-smoothing in mind. Only MS fonts (to their credit) have decent display quality without font-smooting, because they were specifically designed and hinted for grid-pixel displays. — Edokter (talk) — 01:42, 4 April 2014 (UTC)
We can perhaps continue this convo at my talk page? Wikipedia says: After 3.4 the GPL-licensed Liberation fonts were removed and replaced by the Apache-licensed ChromeOS fonts Arimo (sans serif), Tinos (serif) and Cousine (monospace). OpenOffice will also use the default fonts of the running operating system.. I really think that a fresh Windows 7 install with the latest OpenOffice will cause the exact problems I show in my screenshots. No manual installing fonts. No turning of Cleartype/font smoothing. [79][80]Ahappylittletree (talk) 02:00, 4 April 2014 (UTC)
Hi User:Steven (WMF)! Thank you for listening. The test wiki did show me Arimo still, but if I remove it from the stack with developer tools, the problem indeed goes away entirely. Thank you. Another screenshot to help you fix issues (it shows different zoom levels 90%, 100% and 110% in Chrome, Win7 Arimo installed all variants, font smoothing on.) — Preceding unsigned comment added by Ahappylittletree (talk • contribs) 02:29, 5 April 2014 (UTC)
Many people are automatically resistant to change in all its forms. I don't have a particular problem with this change, except that only page header and section header fonts seem to have been changed. Sub-sections still use the sans-serif font, which looks more than a little odd. I would have thought it would not be at all beyond the technical capabilities of the coders to have enabled a simple toggle in user preferences for serif/sans-serif in headings and/or indeed body text. Perhaps that could be considered as a future enhancement? regards, Lynbarn (talk) 23:28, 3 April 2014 (UTC)
@Whisternefet: That would probably have to be me (or a mediawiki admin) - could you point me to where these margin and padding values are? I'm sorry it's looking unpleasant but I don't know anything about the values or where to find them so I can't fix them, especially since I'm apparently not seeing what you're seeing - things look ok to me. Maybe it got changed back? Cathfolant (talk) 22:45, 4 April 2014 (UTC)
@Cathfolant: It's mostly the header margins and paddings that are looking off for me. h2 used to have 1.6 margin-bottom, now its 1.3, making it too tight with the body text and references when I import your CSS. #bodyContent should be 0.8em, not 0.875em. Also, making sans-serif universal overrides the user setting for edit areas. It's all nitpicks from there on out, though. Hopefully you can restore everything by looking at the variables here, as suggested. Otherwise, I'm switching to Monobook. Whisternefet00:05, 5 April 2014 (UTC)
Hello, I am a Opera user and it seems that the new appearance is not the same in Opera than with other browsers. Whereas in Firefox letters are tight, with Opera they are as round as the former fonts, but a bit bigger it seems. Moreover, whereas some headlines in Firefox tend to overlap (Main Page of French Wikipedia for instance), everything is fine in Opera. I don't know if this is worthy of note but anyway... Regards, Oie blanche (talk) 01:39, 4 April 2014 (UTC)
If you are using Windows and happen to have fonts from the Liberation family installed, the pages are going to look awful. I suggest you remove the Liberation fonts and you'll be left with the usual Arial text, just a tad larger than before. I think it looks good enough. Took me a while to figure that out! The CSS style sheets are a bit hard to read. 151.24.96.16 (talk) 02:55, 4 April 2014 (UTC) Valerio, user.
Given that the above vote is unlikely to bring the WMF to change anything, I still think it useful to see what the people this affects think about the change. Thanks, Matty.00709:29, 4 April 2014 (UTC)
I've already registered my discontent with this but in the constructive spirit of Wikipedia, I thought it was best for you to see for yourselves what my problem is. I am using Firefox and Windows 7. http://s22.postimg.org/u15674mz5/Hideous_Font1.png Incidentally, the screenshot looks smaller than actual size and actually looks a bit more balanced than the 'real' view on my screen but I still think it's very ugly and difficult to read. OwnBrand (talk) 10:59, 4 April 2014 (UTC)
Why was this not implemented as a completely new separate skin?
Are the developers all amnesiacs that they cannot remember the wars that break out every single time they change the default way that established users see and use WP? Give the noobs the "new improved better faster cooler" stuff and stop pissing off the hard core of established editors. Roger (Dodger67) (talk) 13:14, 4 April 2014 (UTC)
I use the Cologne Blue skin. It looks far better than either the "before" or "after" version of things that everybody is all huffy about. If you don't like the look, just turn it off! Carrite (talk) 16:04, 4 April 2014 (UTC)
So they didn't entirely revert to the old version, they simply removed Liberation Sans. That font in particular seems to be causing bugs. Matty.007 when you visit Catalan Wikipedia, does it look okay to you? I'm concerned that that font in particular may be causing problems for Windows XP and Windows 7 users. We may remove it. Steven Walling (WMF) • talk
I am not sure about the typeface change, maybe bad, maybe good, only giving it a try will tell. But I am almost sure that turning the font colour into grey is a very bad idea. I have not checked the CSS, but it is #252525 (RGB) on a screen-shot I did just now. It is notoriously harder to read to me (Opera 12.16, Linux some.thing). - Nabla (talk) 19:58, 4 April 2014 (UTC)
If my non-opted out screen was as the image in this 'discussion' section, I would not have a problem and would not vote for a reversion. But it is not. It is not nearly that readable. It is obvious from the feedback page that there are several technical issues. If it were possible for me to read the font, there would be no issue - the change was made for a inclusive technical reason. The implementation of that change, however, seems to be wreaking havoc on the various systems. At the very least can someone responsible for the changes create a page where users can be directed to try different things to make their font readable again? The worst thing that could be done would be to ignore the fact that there are technical issues. It isn't just a 'preference' in many cases that I can see, it is a browser(or whatever)/wikipedia script glitch that is creating several different problems across the various browsers. I would even be happy if my font appeared as the Hideous_Font picture above. It just isn't that good. Hoping someone will help the various, mystified users (including readers). StefanijaSili (talk) 21:02, 4 April 2014 (UTC)
"I don't like change."
There is a good and bad change. I am okay with the good, but this new font, Arimo, is good or bad for some people. Freedom of fonts are the core of Wiki, a bad font may hurt the reader.
Wikipedia is global, not only English but for all languages. People (anon and registered users) must have the right to choose the fonts of their choice -- Arimo, sans-serif, serif, or etc. Please respect their choice.
This change was hardly “small tweaks to body content fonts, text size, text color, and spacing between elements”! I don’t mind the change to a serif font for the level 1 and 2 headings, but I don't care for the increased body text size (and has the leading been increased as well?), and the lighter overall “colour” (weight) of the text reduces overall contrast that makes it just that much more of a strain to read. Useddenim (talk) 12:30, 5 April 2014 (UTC) (For what it's worth, I did review the “proposed” changes and tried to comment on 10 January, but Edokterdeletedmy edit.)
"Restore, please ... and quickly. A lot of our students had trouble with this on Friday. We don't have the option of going around fucking about with the prefs for hundreds of accounts and computers. You can say this change was "visible" to many users as much as you want, but you're only deluding yourselves. VE Mk2 in all but name. Black Kite (talk) "
Totally true, they are delusional and not respect the freedom of other humans.
Please add an option for all people, anon and registered, to change the font to their favorite. Not just 1 font, but for headers and etc.
The best thing would be to revert the change, let the community discuss the change and make meaningful technical suggestions that do not force the new obtrusive style on readers. And give an extensive ban to whoever made such an unnecessary change that has so much unwanted impact in all Wikipedias on the planet. ♆ CUSH ♆20:18, 5 April 2014 (UTC)
"Polling_is_not_a_substitute_for_discussion"
Polling and discussion are substitutions for only polling or only discussion... alone. Keep both and for every vote you do, discuss right next near the vote. — Preceding unsigned comment added by FoureychEightess (talk • contribs) 20:20, 6 April 2014 (UTC)
Was there any feedback and intimation (the sort of Article feedback tool or surveys, not the kind of discussions on hidden talk pages on media wiki) from ip users conducted? How can we know what the majority of readers feel?
What was done, knowing that logged out readers don't have a Beta or Preferences tab?
What was done to ensure that users don't get headaches or eye strains as reported by many above?
Most readers use Win XP, with standard Arial font. What was done to ensure these users who dont have high definition displays, don't know about opensource fonts, whose computers don't support Helvetica or opensource (madness?) don't feel the problems of (old?) technology?
Here, it is stated that Wikipedia states: "This haphazard set of defaults created a lot of readability issues that have not been consistently addressed, until now." I think the situation is completely reverse. Also, "It starts to point to [the question], why aren't there open-source typefaces with ubiquitous language support?" What do our readers care about opensource? All they wan't is a wikipedia they can legibly read.
7. Considering that 80% of above are in favour of reverting, don't you think that the beta processes need to involve more people, and logged out readers, specially for such wide changes? -- Fauzan✆ talk✉ email15:32, 7 April 2014 (UTC)
Break
Steven (WMF) can you address the accessibility issues that are being raised. A number of people have reported that the changes cause eye strain, "hurt the eyes"; in my case it causes an instant headache. These are not insignificant issues, and though they might only affect a small subset of editors, in the end should be investigated. I don't know whether you can see it, but in the screenshot I took yesterday File:Screen shot font change.jpg there are some odd spacing issues - for instance the letter "i" tends to butt up against an adjoining letter and seemingly disappear. In the end, all this project and website offers is reading material to our readers, and a place to work and write, without pay, for those of us who produce content. If it's difficult to read then that's a problem. If it's difficult to write, then that too is a problem. I've been quite active in the past number of months yet somehow missed all the notifications about this. Was there a watchlist notification? Those typically are quite prominent and hard to overlook. Thanks. Victoria (tk) 01:24, 6 April 2014 (UTC)
Yes, that would have been helpful. I see it was added on April 2, but says it will display until 9 February? Adding on April 2 didn't really give much time for discussion for a change that went live the next day. Unless I'm completely missing something. Regardless, the accessibility issues imo should be looked into. Thanks btw for the link. Victoria (tk) 12:01, 6 April 2014 (UTC)
Future
¿Is this the future Wikipedia's screenshot —page 3—? If it is so, maybe the change of the typography is not a big deal... I mean, in comparation. Greetings from esWiki. Albertojuanse (talk) 21:56, 3 April 2014 (UTC)
Pissing crikey! "Meet Kim"? I would rather meet the sharp edge of a giant machete than corrode my eyeballs on that muck. Seriously, I thought Wikipedia was one of the last bastions of sanity, reason and information in a digital world that is becoming increasingly narcissistic and obsessed with the illusion of interactivity (i.e. to conceal the creeping anti-democratic impulses in western culture) but if that is the future of the internet, I will be returning to pen and paper. OwnBrand (talk) 23:45, 3 April 2014 (UTC)
I only looked through part of that pdf but the very clear impression I get from it is that it is describing some form of social networking/easy-file-sharing etc type website. Not wikipedia. I already dislike the thanks feature and have hidden the thanks links in my common.css, as I believe that if you really want to thank someone for something, you should just go to their talk page and post a message maybe even saying why you're thanking them rather than just a vague 'thank you for your edit'. (In fact, there is a rather unflattering article on illogicopedia with that very title, though it's talking about a different extension.) Having nice little buttons to click and do things easily is a convenience and can be useful, and I realise that many of us dislike change simply because it is change, but I think there is a point when conveniences become so convenient they are rendered mindless. Cathfolant (talk) 22:40, 4 April 2014 (UTC)
FYI: Edit-war between German community and WMF on Typography refresh
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
FYI: Font refresh has been deactivated on German Wikipedia. Most users had complained about it and said they didn't like it.--Aschmidt (talk) 22:05, 3 April 2014 (UTC)
FYI2: WMF seeks a conflict with the German community. Steven Walling has reverted the deactivation of typography refresh. This is outrageous. I ask you to refrain from such action and to apologise to the German community. WMF has no right to change the typography of our project without seeking prior consensus.--Aschmidt (talk) 22:42, 3 April 2014 (UTC)
Aschmidt, not sure why'd you bring up German Wikipedia stuff on English Wikipedia? Anyway, I left DaB. (the admin involved) a note about it and said I was not interested in edit warring. Reverting someone's bold change once is not an edit war. It's a part of the normal BRD cycle. I asked DaB. to talk about it more and give people (including readers) a chance to try the changes for at least a few days. Steven Walling (WMF) • talk22:45, 3 April 2014 (UTC)
Actually its fairly enlightening that the WMF has to edit war to keep their poorly thought out product back in production. This reminds me of the VE disaster all over again. The WMF rolls out something that the local communities dont want, they ask for a reversal, the WMF says screw you, your having it if you want it or not, and eventually the community decides to make an end run and disable it via local css or js. Werieth (talk) 22:53, 3 April 2014 (UTC)
I don't really view them as the same. Local Vector CSS was made just for the purpose we're discussing: local overrides. I fully expect that some communities will tweak or change the styles over time. All I asked DaB. was to give it a chance, since we spent a lot of time trying to gather feedback and test it first. Steven Walling (WMF) • talk23:01, 3 April 2014 (UTC)
Steven, I bring this up here because this is where it belongs. I again ask you to refrain from such action. It is impolite, and you are not eligible to act like this on German Wikipedia. So would you please self-revert and apologise to German users?--Aschmidt (talk) 22:50, 3 April 2014 (UTC)
(edit conflict)Steven - Ermmm, not sure bringing up BRD helps your argument - the WMF made a bold change to the type face, DaB. reverted and so then it should have been discussed. What you've done is effectively BRRD. Now I think your argument of letting it run a few days probably has merit but relying on BRD to make your argument does not seem a good idea. Dpmuk (talk) 22:51, 3 April 2014 (UTC)
Oh, and I appreciate that the WMF really does seem to have made a proper attempt to get community input on this. I seem to have missed the notice about the testing so communication can possibly still get better (or I may have just been blind) but it does seem like you got comments from a good number of people. Hence while, from what I can see (I normally use monobook), I consider it a bad idea I think implementing it was quite reasonable. Dpmuk (talk) 22:55, 3 April 2014 (UTC)
Yeah I think the recent update was not really very bold. We took five months to test it, providing it on an opt-in basis to gather feedback from the ~14,000 people who opted to try the change. The change was made very after a lot of input from users across wikis and has changed a lot over time. We also have tried this out first with mobile readers, who represent about 20% of our pageviews every month. Steven Walling (WMF) • talk22:57, 3 April 2014 (UTC)
FYI: This is in the middle of the night European time, so you won't get much of a reaction until tomorrow. I'd like to add, however, that the WMF is about to lose its face. Again. And this makes me sad because we have already wasted our time and our energy on many conflicts like these over the past few years instead of working together on our common goals. Very sad to see that happen again. So, good night to San Francisco. We have a problem.--Aschmidt (talk) 23:06, 3 April 2014 (UTC)
This is reprehensible! It is bad enough that this has happened on the English Wikipedia but abusing the power of the English language website to make enormous changes on other languages' sites is truly disgusting. Although I am only a very small part of this website, I would like to apologise on the behalf of all English speaking people for our arrogance. This disgusts me too and I am sure you have the solidarity of many of our Anglophone editors. Additionally, as you can see from this page, there is far from a consensus on the use of this typeface on the English language Wikipedia and I very much doubt we have heard the end of this. If democracy has any value any more, I expect these changes to be quietly forgotten by those who run the website. Regards, OwnBrand (talk) 23:50, 3 April 2014 (UTC)
Hi OwnBrand. The "power of the English language website" doesn't really factor in. I can edit site CSS/JS globally as a member of Wikimedia Foundation technical staff. It is not related to local English Wikipedia elected admins. Local admin rights here do not extend to any other wikis, and permissions like that are separate for much the same reasons you talk about. Steven Walling (WMF) • talk00:01, 4 April 2014 (UTC)
Steven Walling (or any other WMF activist), please refrain from making any changes to the look of the German Wikipedia in advance of having got a consenus of the German Wikipedia community. The way of seeking a consensus is described in de:WP:Meinungsbilder, I am sure there are people in the WMF capable to translate it. Thanks. --Matthiasb (talk) 07:36, 4 April 2014 (UTC)
Stop it! All of you! I'm from German Wikipedia, I dislike most of Typography refreshs features but I totally agree with what Steven Walling did. DaB' changes to vector.css were a stupid solo action without any consent. Modifying global vector.css to "fix" things to one's personal likings is a no-go! There was plenty of discussion going on regarding typography refresh and everybody who cares had the possibility to at least voice his/her opinion. Most people that are complaining now didn't care. So for now accept the changes, look at them neutrally, decide what you might learn to like and what you will never be able to live with and discuss in a friendly manner. Anyway this is about the German Wikipedia, so it has no place here on English Wikipedia. Go home, calm down, and figure it out together there when you're ready! --Patrick87 (talk) 09:31, 4 April 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Gadget to opt-out
Hey all. Thanks to Edokter, there is now a gadget under the Appearance section of gadget preferences. This will change back to the old sans-serif style in Vector, if you like. This should making opting out easier for anyone who wants to. Steven Walling (WMF) • talk23:11, 3 April 2014 (UTC)
Sorry for not advertising this, but I was qurious to see how badly people wanted such an option to go look for it (and I didn't want to seem unappriciative). This gadget reset some core changes like font family, size and color. Other changes such as line height and margins etc. are not reverted, becuase I think they are in fact beneficial. — Edokter (talk) — 23:41, 3 April 2014 (UTC)
May I get those line height and margins for my own personal CSS? I just enabled the gadget, but the spacing still looks hideous for me. Whisternefet23:52, 3 April 2014 (UTC)
All the links in that section are inaccessible as of now; it also seems that page rendering is messed up for MediaWiki. Whisternefet03:28, 4 April 2014 (UTC)
Not sure how it's supposed to work, so i can't pinpoint what's wrong with it, but it is absolutely useless for me: it messes up the font size in my Monobook (while the description did say "in Vector skin", apparently there's no "only" before that, so it might affect other skins too...), and if i switch to Vector it doesn't actually change anything. -- Jokes Free4Me (talk) 01:03, 4 April 2014 (UTC)
Don't use this gadget under Monobook. The typography refresh does not apply to Monobook (only Vector, as does the gadget), so nothing should have changed for you. — Edokter (talk) — 01:06, 4 April 2014 (UTC)
Yes, i know the monobook skin didn't change, but i want to have the gadget already turned-on if i will ever want to change from monobook to vector. Plus, the current name is misleading, IMO. -- Jokes Free4Me (talk) 16:25, 4 April 2014 (UTC)
I'm sorry guys, this shouldn't be an opt-out via gadget thing. As I said above, and I see others have said the same, feel free to create a new skin with this new look and set it as the wiki default (although some opposed that), but classic vector should stay classic vector and should not be changed like this. — {{U|Technical 13}}(t • e • c)00:21, 4 April 2014 (UTC)
Fully agreed - especially as the gadget creates its own problems:- the new fonts load and are visible before the gadget converts the fonts back, causing a delay and then a "jump" on the screen, which quickly brings on a headache and would give a migraine if I carried on using it. Arjayay (talk) 08:10, 4 April 2014 (UTC)
I am having the same problem with the gadget as Arjayay - a delay causing it to flick on the 'new' typography before flicking to the 'old version' - and it has very quickly given me a headache! Couldn't something along the lines of Technical 13's suggestion of setting up different skins be utilised? SagaciousPhil - Chat09:42, 4 April 2014 (UTC)
The problem with a large segment of the community immediately opting out of changes pushed down from WMF is that our experienced editors will always be seeing something different than new users. Over time, as the established editor base continues to opt-out of this, or that, helping new users with their experience becomes difficult because the helper and the helpee will see different things. –xenotalk13:26, 4 April 2014 (UTC)
No use whatsoever to those of us who don't edit and don't have accounts. (As it happens, I do have an account, but I no longer login into it.) A typical example of Wikicrats forgetting that Wikipedia editors are a tiny minority of Wikipedia users, and Wikipedia policy should have them in mind, not us. --93.152.83.69 (talk) 13:41, 4 April 2014 (UTC)
I'm amazed that this was implemented without an opt-out feature to restore Wikipedia to how it looked before already in place. But, however bad it looks to me, I don't want to change my display to be any more different than necessary to how the readers will see pages. Please make this feature opt-in, rather than force it on your users until they no longer complain. ‑‑xensyriaT15:00, 4 April 2014 (UTC)
I'm not sure if the foundation can pull the statistics about how many people opt out. It seems problematic if the people who do a considerable amount of the maintenance and editing (the top 3000 editors) fundamentally see the site differently than the readership. They'll essentially be optimizing everything for the old style (if it turns out a large portion of people opt out). Mkdwtalk05:00, 5 April 2014 (UTC)
what we perhaps really need to suit editor preferences is a easy way to alter some of the key elements individually, without finding the specific css lines that we need to modify: essentially a selection box for different settings, such as all word processing programs have used for the past 30 years or so, (I know which ones I would pick to change--the first is to use the highest available contrast, black, not grey; the second is to use a font for text that distinguishes letters and numbers, the third is to use text=serif and headings=sansserif, with a smaller distinctive size for the main headings than either the old or the new vector. I can't claim everyone would agree, but why should they? My own priority is seeing as much text as I can at a time with clarity, and what I need isn't the same on different monitors. At the least, perhaps a simplifed guide to the basic css setting for the common elements?
As for reader preferences, there's no way to find out without properly studying the readers: I note A/B testing was rejected because of the impossibility of testing all combinations, but that's not a reason to abandon completely the idea that other people might actually know what they want. Skill is figuring out what to test, not using what looks good to oneself. DGG ( talk ) 05:31, 5 April 2014 (UTC)
This opt-out doesn't work! I've tried the Monobook skin. I don't care if you revert all the new changes, or add a new "Vector skin" skin that is really the old skin, or upgrade this opt-out to fully restore the old skin, or give us some elaborate css code to implement. But please stop tinkering around with fontstacks for Windows 7 until there is a real solution for what is now causing physical symptoms for some of us. Unscintillating (talk) 08:45, 5 April 2014 (UTC)
The information below is that the CSS requires re-rendering the display, thus adding a flicker. Not everyone can tolerate flicker, and I'm one who cannot. I have turned off the opt-out, and put strike-out through the suggestions above to upgrade the opt-out or provide a CSS code solution. Unscintillating (talk) 19:19, 5 April 2014 (UTC)
You could try: User:Begoon/override-typography-refresh (instructions are there). It was really just for my personal use, so it's not real sophisticated, but it works for me, for now, with no "flicker". It's not a gadget, and it's not my code (thank Cathfolant), it requires adding a couple of lines to the start of your Special:MyPage/vector.css, and I can't guarantee it will work when WMF update the code, or I break the thing, but there it is, if you want to try it you're welcome. Begoontalk19:37, 5 April 2014 (UTC)
The @import didn't seem to work, but after I copied your code into my vector.css I finally got some relief. Not sure that everything is back to normal, but this is a big improvement. Thanks, Unscintillating (talk) 13:25, 6 April 2014 (UTC)
You're welcome - as I said the CSS is mainly Cathfolant's code - I only made a couple of tweaks. I'm using the @import to avoid having to paste the thing on Commons, Meta etc in its entirety, and keep them all updated. It works well for me, not sure why not for you - for a second I thought that might be because you're not logged in as me - but that shouldn't make a difference - I can see it logged out at [81] - if you see the css as text there too it should have worked, I think. Glad it helps a bit, anyway - just copy-pasted. Begoontalk15:00, 6 April 2014 (UTC)
The opt-out gadget makes things worse! On every page load I see a flash of the new typography disaster first, then it re-renders with the original sane typography. This scary animation slows down page loads and gives me a headache. —WinTakeAll💬12:17, 5 April 2014 (UTC)
I've tested the opt-out and I only saw a FOUC on the very first page load. Just a matter of updating local browser cache perhaps? --Nemo13:49, 6 April 2014 (UTC)
Looking more closely at the comment above, Edokter states that the so-called opt-out doesn't even try to restore line height and margins. Unscintillating (talk) 13:25, 6 April 2014 (UTC)
Why has the opt-out gadget been removed again? At least it does not appear in my Preferences/Gadgets section.--SiriusB (talk) 14:58, 11 April 2014 (UTC)
Yes, of course I had switched it on. I had already looked for it before switching to Monobook after the circulating reverting CSS scripts have shown error messages in the editor. However, I noticed not that the gadget option seems top appear irregularly. Are there any relevant cache contents which are not always cleared when I click the "reload page" button (even with the additional cache-clearing tricks mentioned at the Gadgets page!) in the browser? I had similar problems even outside Wikipedia, but only at very selected pages (e.g. the Fink project page, which continues to show different content on different computers...).--SiriusB (talk) 15:37, 11 April 2014 (UTC)
I know this is kind of radical — I'm certainly not expecting everyone to jump up and say "sure, let's do that!" but I'd just like to point out another option.
The reason I would personally like it is that there is an awkward conflict right now in technical articles with equations. Variable names are not so nice in sans fonts (hard to distinguish I from l, for example), and for that reason, things like the {{math}} template use serif. When these are mixed with sans fonts in running text, they look frankly appallingly bad, just vomitous (see e (mathematical constant) for an absolutely egregious example). For that reason, I oppose {{math}} in any article where it's not already established, but if we went to all serif, my objection would go away.
Now, as I say, I know it's kind of a radical suggestion, and I don't really expect everyone to say we should do this big change just for the benefit of articles with equations. However, if there were a constituency for it for other reasons, this is why I would join it. --Trovatore (talk) 00:13, 4 April 2014 (UTC)
How can you put aesthetics over legibility? You acknowledge that math in sans-serif is, by any definition, unreadable. Yet you will oppose the only method available (to editors) to remedy that illegibility. I just don't understand. — Edokter (talk) — 01:02, 4 April 2014 (UTC)
No, that's reading way too much into what I "acknowledge". Sans-serif for math is perfectly usable, with a restricted character set. Note that the de-facto standard for slide presentations in mathematics, the Beamer class, uses sans by default.
If you absolutely have to have "I" as a variable name (standard for a few things) then yeah, in that article, you might have to go with serif. But I see no reason at all to prefer e over e in running text, not if there isn't some other aspect of that article that requires one of the problematic characters. --Trovatore (talk) 01:07, 4 April 2014 (UTC)
Fwiw, I'm not sure why {{math}} exists - we already have <math> tags which do basically the same thing. Also fwiw wikipedia did originally use sans-serif at least if the so-called Nostalgia skin is an accurate reflection of the original appearance. (also I didn't realise you got an edit conflict when it was in another section...) Cathfolant (talk) 14:48, 4 April 2014 (UTC)
Except <math> is totally unsuitable for inline math, and will be so until MathJax is served as the default to all users. — Edokter (talk) — 16:40, 4 April 2014 (UTC)
It's true, <math> inline is butt-ugly, possibly even worse than {{math}}. My hierarchy goes something like this: (i) if possible, don't use mathematics inline, because there's no good solution as long as the rest of the text is in sans, but (ii) if you really have to, then use HTML, with italics for variable names, unless (iii) you really need a variable that's unclear in sans, in which case as a last resort {{math}} and {{mvar}} may be the least bad option. --Trovatore (talk) 23:48, 4 April 2014 (UTC)
Technical reasons favor sans-serif fonts: To show capital "i" we have template {{ibeam}}: Ɪ, as an option. For the overall legibility, the serif fonts (such as Times New Roman) have been shown to work in monotype spacing to help join letters as words; however, for proportional spacing a sans-serif font (such as Arial) can be easier to read, with less eyestrain. Also, I think it has been shown that Arial font is less likely to cause rivers in print, but perhaps the proportional spacing is the greater factor to avoid print-rivers. Another advantage of sans-serif fonts is the legibility of small-font display, where the serif fonts tend to reduce as muddled "flyspecks" in pixel-based rendering (small Times New Roman: "more mere mass" versus Arial: "more mere mass") but perhaps not if the display were a zoom of non-pixel technology. A sans-serif font should have a special capital "I" to contrast with lowercase ell "l". -Wikid77 (talk) 15:22, 4 April 2014 (UTC)
Apart from the fact that mixing Courier with sans-serif is even 'worse' the mxing Times in sans-serif, these separate template do not contribute to consistency and ease of editing. Math needs to have a consistent look across Wikipedia, and all these templates are mostly ad-hoc reactions of bad typography to begin with; they only propagate bad typography further. Math needs to look like math across the board, and legibility must be the key factor, no matter aesthetically displeasing it may be to some. — Edokter (talk) — 15:50, 4 April 2014 (UTC)
As for consistency, that is important within an article, much less important on an inter-article basis. That's a general principle at Wikipedia. Legibility is certainly key, but sans-serif math is quite legible with the exception of a few bad characters. There is no way that mixing sans and serif inline can ever be good typography. --Trovatore (talk) 21:18, 4 April 2014 (UTC)
Hopefully I'm putting this in the right place – without cleartype turned on (and using W7, FF28, 1680*1050 res), the new design is very difficult to read. I don't mean a simple "I don't like it" (which I admittedly don't, as the previous font was much easier to read without the cleartype feature), but most letters have a 'line width' of one pixel, while some are 'two pixels wide' and they almost look bold, e.g. vertical lines of both upper- and lowercase F, making for a messy text with seemingly randomly highlighted characters. Whatever happens to the new design, perhaps consider this issue as well. 89.176.87.169 (talk) 07:20, 4 April 2014 (UTC)
Seconded. See my screenshot for just how awful it is in Chrome, Windows 7 (I had no problems when san-serif was used). Please consider the effect this will have for all users. ‑‑xensyriaT15:04, 4 April 2014 (UTC)
I do have to say this, don't be offended please. But why do you have ClearType disabled? Only older MS fonts look somewhat decent without smoothing. Cleartype has been the standard for Windows for ten years now, and disabling it is like having a new color TV set to black-and-white. — Edokter (talk) — 15:57, 4 April 2014 (UTC)
This configuration was already like that when I started using the lab where I noticed these bold fs... Itis not something I or other students can change, because it requires administrative rights. Helder.wiki16:46, 4 April 2014 (UTC)
Cleartype is not, repeat not an unalloyed improvement. On many (probably most) systems, it produces significant blurring, and a large number of users dislike it. To users who work with colour and/or are sensitive to colour, Cleartype is simply a shortcut to eyestrain. Many users turn it off immediately on getting a new system because sharp, clear text is essential to them, and this is exactly what the misnamed technology called "Cleartype" fails to deliver. Mandating Cleartype to use Wikipedia is a very user-hostile act and not in keeping with the Wikipedia mandate. Tannin (talk) 08:59, 6 April 2014 (UTC)
This has basically made Wikipedia unreadable. I've increased my font size because reading tiny, tiny text at 9,000,000 ppi is hard. This is the result. Cleartype is off because reading rainbow-colored, blurry text is also hard. Personally, I'll just use the override, but I felt the need to comment since the point of this update was to INCREASE accessibility and readability, not decrease it.
Travis Daily (talk) 19:38, 4 April 2014 (UTC)
Thank you! I'd have a second look at "Helvetica" too. Also may be good to note that ZoomText has this in their documentation: "Windows Vista preferences allow you to enable ZoomText's logon support and disable Windows ClearType font smoothing for improved quality of ZoomText's magnified text."— Preceding unsigned comment added by Ahappylittletree (talk • contribs) 03:02, 5 April 2014 (UTC)
@Edokter:. Asking why people are disabling font smoother is quite rude in my book. Many readers turn it off for the sake of performance. You really sounded like "people should get a good enough device to enable this function otherwise accept the gritty font or leave". -- Sameboat - 同舟 (talk) 00:33, 5 April 2014 (UTC)
Cleartype is not supported via RDP in Windows XP/Server 2003 [82], and needs to be explicitly enabled client side for newer versions of windows [83]. Also, I don't use RDS but it looks like enabling it is a bit of a pain for RDS [84]. I browse inside RDP sessions all the time. --Robert.Labrie (talk) 00:44, 5 April 2014 (UTC)
Update
Hi everyone. Since users on Windows 7 and XP were reporting significant issues with Liberation Sans and Arimo for body text, we've put in place a temporary fix for English Wikipedia. Please do refresh and see if this improves things, particularly if you're on Windows. We will replace this local fix with a default update on Monday, when software deployments can resume. Steven Walling (WMF) • talk00:43, 5 April 2014 (UTC)
I can report, at least on my Firefox/Mac OS setup, that my display is using Helvetica Neue now instead of Liberation Sans. The font itself looks better — I'm not sure if it's as good as Verdana was; I'll have to live with it for a while — but only if I go to "View->Zoom In" two or three times to enlarge the very small default text size.
The noticeably gray text is harder to read than the black text was before. I feel like it's causing more eyestrain, which is the opposite of the intended effect.
I can also report that the "opt-out" gadget in my Preferences is no longer working for me. I unchecked it, saved, and checked it again, and I still have Helvetica Neue. I would like an option to use my former sans serif font, which worked great, while these very basic bugs are being worked out in the "production beta" testing period. Please let me/us know how to opt out again, and feel free to drop a Watchlist notification on us when these basic bugs have been fixed. Thanks for the hard work. I feel confident that the end product will be good, but right now, I would like my old body font and font color back so that I can get back to the work I do, which is editing Wikipedia. – Jonesey95 (talk) 01:13, 5 April 2014 (UTC)
The gadget has partly stopped working because of the edit to our Vector.css. As that measure is temporary, I have added a temporary measure of my own, so the gadget should work again. — Edokter (talk) — 01:26, 5 April 2014 (UTC)
FYI Steven Walling: I actually tried "Arial", "Liberation Sans", "Helvetica Neue" and even "Helvetica LT Pro" side by side during my testing of Typography refresh. I'm afraid to say that on my machine (Windows 7, Firefox 28, ClearType turned on, 100% font size) actually "Arial" and "Liberation Sans" were the only acceptable fonts with regards to hinting. While the Helvetica variants might look good on high resolution displays / when zoomed, their hinting is inferior. Therefore they are hardly readable on normal displays with standard text size. So if you want to remove "Liberation Sans" for Windows users, continue with also removing Helvetica variants since those are even worse than Liberation. --Patrick87 (talk) 02:08, 5 April 2014 (UTC)
You want to be carefull not to remove too much. I don't know how widespread Helvetica Neue is on Windows, but I suspect it is virtually nil. So if we leave that in while dropping Helvetica, Windows should revert to Arial and Mac will happily use Helvetica Neue. On the other hand, Helvetica is often mapped to other helv-like fonts on Linux. I wish we could build on a system where we can target fontstacks per platform. — Edokter (talk) — 02:26, 5 April 2014 (UTC)
I just tested, and removing just Helvetica from the new "fixed" stack works for me (XP - Chrome 33 - ClearType on), leaving in Helvetica Neue is no issue, since, as suggested, I don't have that. Patrick is correct that leaving Helvetica in the stack is suboptimal - with it the font is very poorly rendered, with many of the previously described issues. So poor I wouldn't use it (looks like Ahappylittletree's screenshot below). I would need to override that - so you can take this as another "vote" from me, at least, to lose "Helvetica" from the "new" stack. I would imagine Patrick's and my experience is probably very common for Windows users - especially, of course, the many, many "not logged in" readers and editors, who don't have the luxury of gadgets or vector.css, and will just see the poorly rendered site. Begoontalk09:05, 5 April 2014 (UTC)
Heh. WONTFIX. Thanks, I smiled. That would help some, granted - but the average Joe Bloggs reader, clicking Google result no. 1, isn't going to install a gadget even if he can, or even knows one exists (how?). He'll just see a badly rendered font/page, and that will be his wikipedia experience for today. The default needs to work out of the box. Right now it doesn't. But it did, prior to this. Begoontalk18:49, 5 April 2014 (UTC)
Thank you very much for the quick fix and the update! I can report the problems have gone away for me. Mac: Will use helvetica neue (no problem). pc: Will use helvetica when it is installed (problem. Caused by certain programs, drivers, or manual font installs), will use helvetica neue when it is installed (no problem. Optimized for web). Will use arial when no helvetica installed (no problem, at least, not for me). Linux: If Helvetica is often mappen to other helv-like fonts I don't know, you may try "Nimbus Sans L" if you want to specify a font for Linux. Thanks again! — Preceding unsigned comment added by Ahappylittletree (talk • contribs) 04:07, 5 April 2014 (UTC)
What about if you want to restore the new type changes. Is it possible at the moment? I see no option in Preferences. I was very happy with the type update and had not a single readability issue. - Shiftchange (talk) 07:39, 5 April 2014 (UTC)
@Steven (WMF): How "convenient", that the Windows users' issues forced you to do exactly what you wanted to do all along. IMO the right thing to do would be to revert back to plain "sans-serif" while you prepare a new iteration, not this crap that's already been well opposed on wikitech-l. Anomie⚔11:42, 5 April 2014 (UTC)
I can't disagree with your assessment, Anomie, of the "right" thing to do. "sans-serif" worked, and was legible. Given the quite evident issues, the obviously sane thing to do is to revert to that for the sake of just plain usability, while all these lovely "post-mortems" go on. Foremost in my mind are the "readers" who use Windows and don't log in. Many of them now see horridly rendered fonts. Unless they care enough, and are technical enough, to use site-specific css (and that would be far from easy, or simply impossible, for many) they now just have a sub-par experience. They'll just shrug and think - "oh, wikipedia looks like a bag of crap now - I wonder why?" This is our "front window". That's poor. Luckily for me, and thanks to Cathfolant and others, I can retain the old look while this rumbles along, with User:Begoon/vector.css. They can't, and our "front window" display is a mess. We should be better than this. Begoontalk18:22, 5 April 2014 (UTC)
To me the problem seems to be only the text colour. The font face work for me, the font size varies so much across sites I am already use to change zoom without even thinking about it (Ctrl-+ or Ctrl--, done). But dark grey (#252525) is too light. How is decreased contrast better for readability / usability than high contrast. I am really asking. I did a few sites (completely amateur) and I am working on one right now (or I should be :-) so I am curious on where can I access studies saying dark grey on white is more, or as much, readable than black on white (actually very, very, light grey, but that choice seems fine, to reduce 'glow'). Can anyone help with a WP-CSS incantation for custom vector.css that turns the text black? A simple p {color: #000000} doesn't seem to work. - Nabla (talk) 12:02, 5 April 2014 (UTC)
Hey Nabla. See Why did we change the body text color? from the FAQ. TL;DR: this still has the best possible rating on objective measures of contrast and accessibility, and it balances the need for high contrast with the fact that pure black on white (or vice-versa) produces greater eye strain than very dark grey on pure white. Steven Walling (WMF) • talk23:44, 5 April 2014 (UTC)
Thank you, Steven (WMF). A few notes... My bookmarks still pointed to WCAG 1.0, updated! :-) A detail: the background is not #FFFFFF as the FAQ says, but #F6F6F6, accordingly the contrast would be 14.2:1, not 15.3:1, if my calculation is correct, nevertheless well within the 7:1 level for a AAA level of contrast in WCAG 2.0. A reply playing the WCAG card is a strong reply, in sharp contrast with some poor replies I've seen before, so maybe I my judgement was too harsh too. I have defended (loudly :) the implementation of WCAG on other places (not WP) so I like to see that WP looks at it, and thus I'll accept a "within WCAG AAA limits" as a good enough standard. I also agree - though that is one man's view - that too much contrast, pure black on white, is not ideal. For myself, I use black on almond(??), #000000 on #EEEEDD (on the emacs text editor) and #000000 on #FFEECC (on terminal windows), but I wouldn't recommend that, probably wouldn't be very popular :-) Just pointing that though having good contrast, maybe the overall lightness of the almost white background is what is making it (a little) harder for me to read. And I bet we could chose some pairs of colours well within the 7:1 ratio that would not be that good (WCAG's page itself uses black on white). Anyway, thanks. - Nabla (talk) 01:39, 6 April 2014 (UTC)
PS: at first glance I would lose my bet. After all it is not that easy to find a pair (dark font, white background) that looks extremely bad within the 7:1 ratio. - Nabla (talk) 02:10, 6 April 2014 (UTC)
PPS: inspired by the FAQ's CSS suggestion, div#content.mw-body {color:#000000}, seems to be enough to make the font go back to black. And that _is_ a relief - Nabla (talk) 02:29, 6 April 2014 (UTC)
At least on my Windows-based display, the "local fix" no longer looks like a display malfunction, although it remains less legible than the pre-"upgrade" displays. Hullaballoo Wolfowitz (talk) 17:11, 5 April 2014 (UTC)
Not sure but it seems related: characters after a "ș" become larger (bold?), e.g. ACS Poli Timișoara (to me the "șoara" bit is darker than the rest. Opera 12.16, Linux, and adding font-family: sans-serif; to my custom.css makes it back normal, apparently. - Nabla (talk) 02:57, 6 April 2014 (UTC)
Thanks. In my case it results in Arial on Windows 7 (instead Liberation Sans - I have got LibreOffice installed, see bug 63591) and Nimbus Sans L on Ubuntu 12.04 (instead Liberation Sans too). In my opinion it looks much better now, especially on Windows (on Linux too, but the difference is less noticeable). Good job. I am looking forward to this change being introduced in global Mediawiki. However, I still think that the new font size is too big, but I can understand that choice having in mind growing screen resolutions. Piotr Jurkiewicz (talk) 14:43, 6 April 2014 (UTC)
Thank you for listening. At least now I know for me personally the font type is not the issue, I'm still getting headaches reading Wikipedia (and only Wikipedia). I guess I'll have to live with that, as nothing seems off or different in the text. In the editor it's fine though, somehow that doesn't cause any problems (even with the different font).
Edit; found the problem, somehow my browser doesn't display black text as black. Even with ClearType turned off, it seems it has a problem with Wikipedia. Though enabling ClearType definitely makes it worse. Another debugging session then, at least the WMF isn't to blame in this regard. 93.125.198.182 (talk) 14:49, 8 April 2014 (UTC)
Excerpt from de:Subtraktion on 2014-04-10 to demonstrate problems with the new typeface (Microsoft Internet Explorer 9 on Windows 7)
I don't see any difference. Text ist still barely readable on IE9/Win7. Furthermore, I've just remarked that the minus sign isn't displayed at all (see screenshot on the right; there should be a minus sign between the quotation marks „“). I hope this typeface problem gets fixed/reverted soon. --SelfishSeahorse (talk) 18:39, 10 April 2014 (UTC)
I currently have Windows 7 / IE 11. Moreover, I have Google Chrome. I keep both open and edit from each for various reasons that are not related to this thread. Both pages are burning my eyes. The glare is horrendous. I need sunglasses to read it. I have set the brightness on my monitor down to 15%. Even so, when I leave home my eyesight is degraded and remains so. Everything looks hazy and unclear. I have now changed my skin to Modern for at least the time being. I would have liked the larger font...Someone up page asked why wasn't this just developed and served up as a new and different skin. I echo that thought. Fylbecatuloustalk15:17, 12 April 2014 (UTC)
Technical experiment
I want to conduct a technical experiment, using a gadget, that will target each OS separately, and give them the OS best option. Windows would get plain Arial, Mac would stick with Helvetica Neue. I don't know what font would serve Linux best: Liberation Sans or Nimbus Sans L? If the 'Helvetica look' is the goal, then Nimbus is the obvious choice, but Liberation may have better Unicode/glyph support. So, need input on that. If this works, I want to investigate a server-side solution. — Edokter (talk) — 13:51, 5 April 2014 (UTC)
While I understand your intentions for such a feature I think it's not an appropriate approach to solve the current dispute. It's again a fix for a problem that could have been avoided in the first place (e.g. by a more appropriate / better tested font stack or by accepting that there is no "universal"font stack for all systems and dropping it completely). Requiring any JavaScript for such a fundamental design property as font family is ridiculous. If you start there, we'll quickly end up with the same fiasco than with ULS's "autonym font". Breaking things that always worked acceptable in the first place and "fixing" them with tons of JavaScript is just not worth the effort. In the end you would waste your time on something rather unnecessary! --Patrick87 (talk) 17:35, 5 April 2014 (UTC)
The long term solution would not require javascript; it would simply serve the font stack based on OS. The gadget is merely for testing. But I am also beginning to see that this update has misfired. The font stack has absolutely no concern for non-latin scripts, where I suspect most non-latin projects have local font stacks in place anyway (though some are complaining about the Georgia/Times headers). If you want to serve the 'perfect' font stack, you would ultimately have to maintain a matrix of platforms and scripts around the world. — Edokter (talk) — 17:48, 5 April 2014 (UTC)
Out of interest: How would a font stack per platform without JavaScript work? Can one do it with pure CSS? Actually that was what I proposed in the very beginning of the Typography refresh beta phase, because already back then I was of the opinion there was no "one for all" solution. Back then I was laughed at though for being too pessimistic... --Patrick87 (talk) 18:12, 5 April 2014 (UTC)
It would work something like this, but then server side, by analyzing the user agent header like jQuery.client does, and then appending the appropriate class to the HTML element. Then all you need to do is compose the various font stacks using the proper platform selectors like this:
html,body{font-family:sans-serif;//Default}html.platform-win,html.platform-winbody{font-family:Arial,sans-serif;}html.platform-mac,html.platform-macbody{font-family:"Helvetica Neue",Helvetica,sans-serif;}html.platform-linux,html.platform-linuxbody{font-family:"Liberation Sans","Nimbus Sans L",sans-serif;}
.
(edit) Come to think of it, it could even be done without the platform class and simply have ResourceLoader/LESS serve you the right stack. — Edokter (talk) — 18:49, 5 April 2014 (UTC)
Originally yes, but without the class, the page remains the same and only the CSS is changed. (I don't know how that is cahced though.) — Edokter (talk) — 18:01, 7 April 2014 (UTC)
Proposal
Given that, as editors, we have the option (although inconvenient) of choosing which font we want, through gadgets, skins, and the like. Readers don't and I feel that is unfair. I propose a survey of readers with the choice (and an example) of both current and the past font; the one with the most votes becomes standard, the other an opt in gadget/skin for editors. I don't know if this is feasible, but at the Picture of the Year competition voting on Commons, the voting was done with a pop up box, similar to requests for feedback on sites such as the BBC or the Telegraph. It probably wouldn't be too hard to enable it for all readers to be able to vote. Thanks, Matty.00711:16, 5 April 2014 (UTC)
I second this suggestion, it should be something that reaches all users of Wikipedia. I guess, had this been done before or simultaneously with the rollout, quite a bit of the discussion drama may also have been prevented.--Destruktor5000 (talk) 13:31, 5 April 2014 (UTC)
Good idea; perhaps this should be a policy of giving all readers a poll of "Better"/"Worse"/"Didn't notice" and a link to give more feedback whenever there's a design/typography change, to get a sense of how well received it is. This would also be a PR coup for WMF. ‑‑xensyriaT15:26, 5 April 2014 (UTC)
Voting is not really the most efficient, representative, and practical way of making software changes on a site this big. There are 400 million people reading Wikimedia sites a month, 70,000 or more of which edit at least five times. Our sites are in dozens of different languages (hundreds actually, if you consider small minority languages). The vast majority of these people do not have the expertise or interest to learn wikimarkup, register accounts, or frankly even take the time to respond to surveys like this. We have never successfully surveyed a majority of Wikimedia readers or editors, even when we do it without using a wiki page. Even if we could, it's not likely to produce an objective measure of whether something is really better or not. People tend to answer surveys based on personal preference, rather than what might balance the needs of many different kinds of users across languages, projects, as well as for both editors and readers. Balancing those needs, gathering feedback, and making decisions that do the most good for the widest possible swath of users is why the Wikimedia Foundation employees software engineers, designers, and product managers like myself. We've spent the last five months doing that, and we're continuing to listen to that feedback after we've launched. That includes readers, even if they couldn't have access to the Beta Features that logged-in users do. (Also: we've actually had this exact same font style on our mobile site for more than a year, which represents 20% of all our pageviews). Steven Walling (WMF) • talk00:00, 6 April 2014 (UTC)
Steven Walling unfortunately the way the WMF tend to do things never represents strong community consensus, you tend to just go with it and take the considerable flac later. The WMF haven't despite saying they had learnt from projects such as The AFT one, in which it utterly failed to listen to the community effectively and listen to the mass amount of feedback that it was given and then shutting down engineering time on it with out doing any of the work suggested, which ultimately meant you had wasted the whole communities time and energy. Your way of attempting to generate a consensus does not work as this does not represent an overall consensus, now you either get a consensus through an enwiki RFC with a site notice or you ask for reader feedback, or both. Doing nothing unfortunately leaves us with the lame duck guide to site improvements that the WMF are at the moment, and balking at the idea of people trying to do that when you failed isn't helpful.BletheringScot00:09, 6 April 2014 (UTC)
Scot, I feel like you're referring only to English Wikipedia here. Remember that this change is a default across all wikis. I do agree that it's much easier to poll or otherwise ask users about releasing software when it's one project we're talking about. We released this typography update as a part of the software that runs hundreds of wikis, including all language editions of Wikipedia. That's why I was talking about the problem of surveys applied at scale. Steven Walling (WMF) • talk01:23, 6 April 2014 (UTC)
Umm... Why would answering a simple question require someone to "learn wikimarkup" and/or "register accounts"?! Personal preference is all that should matter. -- Jokes Free4Me (talk) 13:46, 6 April 2014 (UTC)
PS: As for the font being in-place on mobile devices, i think noone will contest that this could be okay for that platform. Just don't force it on desktops without getting feedback from outside the beta... -- Jokes Free4Me (talk) 13:49, 6 April 2014 (UTC)
@Jokes Free4Me: It doesn't require learning wikimarkup or registering an account. That is a red herring. You are right: it's about opinions. A real test of the new typography could be as simple as just setting up a table in a mall with two computers set to the same article — one with the current typography and another with the proposed new typography — and just asking folks to look at the article on each computer and saying which they prefer. In just a day or two, you'd have many hundreds of real-world opinions (data) for the price of just some lollipops to give to people who complete the survey. And if we wanted to be real scientific, we'd isolate and test individuals aspects of the topography change. The discussion isn't about markup or registering accounts, it's about people's opinion on what looks good. Jason Quinn (talk) 17:16, 6 April 2014 (UTC)
@Steven Walling (WMF): I'm sure this wasn't what you meant, but your response reads to me as: "Yes, if it were just for one project we could do proper consultation and user research, but since this was for "hundreds of wikis" we decided that wasn't feasible, or too hard, so we'd have to just be the judge ourselves". The fact that the number of users is huge doesn't reduce your obligation for research and consultation - it increases it. You guys were a bad judge when it came to implement VE, and you've been a bad judge on this occasion too. Introducing a change that, by default, gave Windows users worldwide a poor experience, was misjudged. You've backpedalled and fixed it a bit (Helvetica is still awful), and that's to your credit.
I guess my question is this: Given the demonstrated failure of WMF, repeatedly, to make these large scale changes successfully, what is your ongoing plan to reform WMF decision making from "little village" to "global", and how will you integrate that with the communities? It's relevant here because this is a recurring theme, used again to justify an unpopular change, although I guess, in the long term, the discussion might need to be taken elsewhere. Begoontalk18:22, 6 April 2014 (UTC)
In my opinion as a volunteer, the only technical valid answer that would satisfy the criteria of the community on this front is one of: Spent millions to develop software, or just stop developing software. I think neither is acceptable, and the community just needs to learn that true development is trough iteration, giving taking etc. I mean, it's not like all our articles are FA quality in one go. —TheDJ (talk • contribs) 21:04, 6 April 2014 (UTC)
They're not, I agree. We can edit and improve them, though, they're not imposed by fiat. I think you're comparing apples and oranges.
I do sympathise with the developers. I've been in that role. The problem is not that it isn't "right first time", it's the stubborn insistence that it was, despite all evidence, the insistence that the user must be wrong, and, despite what Jimmy says on his talkpage, we can't "just roll it back and try again". It's only a co-operative "iterative" change if we're allowed to iterate too.
We don't have that power. Jimmy thinks we're not being fair to the developers, and making their lives hard. Maybe. Senior jobs on one of the top 10 websites in the world will perhaps not be easy. Sorry. It's a warm kitchen.
We can't fix it ourselves. We have to fight tooth and nail for sanity. Look at the VE discussions. Look at the length of this discussion. It could have all been over in one reply - "oops, sorry, that doesn't work properly, does it? We'll fix that and try again in a week or so." That's the disconnect. There's an attitude thing, and that needs to change, probably on both "sides".
But it does need to change. They're paid (by us, indirectly) to understand that, we are not. That may seem like a cheap shot, but I think it's food for thought. The "community managers", "community liaisons" etc need to lead this change, with us, and with their colleagues at WMF - or what is it they do on our behalf? We'll be here again. Begoontalk14:44, 7 April 2014 (UTC)
Real problems will always be dealt with, if need be by the volunteer developers (trust me, there is precedent). Let us however not forget that at any moment we have a few thousands of burg reports open and despite that the website functions reasonably well.
Personally I'm happy that the foundation developers don't just roll over willy nilly but actually look into problems and determine why they exist and what needs to be done to counter them. I think that is very sane and proper leadership. Also, as much as you guys climb the barricades, remember that to some degree, StevenW has to fulfill the same kind of advocacy/defensive role for his development team as the community members here serve their community. In my experience a lot of the problems have to do with eloquence. People have a lot of trouble describing what and why they consider something a problem. That also makes it very difficult for people to distill the noise from the real problems. The second problem is that a large group of people just don't want to be bothered, making it very difficult to gather their feedback with anything but a full deploy (i mean 29000 ppl..._). This is nothing new, the whole internet has that problem. Improve sure, but let us stop being so extremely defensive and sometimes outright offensive (a better dialog might also start with ourselves). Weekend is over, let them get to work. —TheDJ (talk • contribs) 18:14, 7 April 2014 (UTC)
What is this stuff about leadership? The WMF (let alone its programmers) are not in charge of us. They work for us and for the encyclopedia. If they do something that makes a large portion of the community upset, they have made a mistake. And I argue that the reason for such mistakes because they are not following established Wikipedia policies.
A core concept of Wikipedia is that, while you can be WP:BOLD in making changes, you roll them back if there is controversy. This change has more controversy than the most controversial articles on Wikipedia, and yet the change was not rolled back. The community blowback is entirely the WMF's fault for not following the community-determined best practices. We figured out long ago that sticking to your guns will flare up any controversy. That's why WP:BRD exists.
The WMF has stated a desire to ignore editor consensus (claiming that it doesn't represent what the readers want). And we can't influence who is actually part of the WMF. So our only choice as editors is to be the fly in the ointment--to provide immediate negative consequences to changes we think are detrimental to the encyclopedia. If we were engaged as equals, the tenor of the conversation could be much less confrontational. The reason people get so upset is that they feel they have to in order to get their voices to be heard.
The change in the tone of the conversation starts not with us but with them. If we tone it down before then, we are in effect agreeing with how things currently work. Until we are working together, we will always feel like we have to stand up or be rolled over. We shouldn't feel like we're having to beg our WMF (progamming) superiors to listen to us. — trlkly22:08, 14 April 2014 (UTC)
Proposal (2)
I think a lot of the conversation around the choice of font misses the point. We can have a vote about which font is best, and we will never get an agreement. One of the key differences between print media and the web is the latter's philosophy (from the days of Mosaic) that the reader chooses the layout, not the author (or publisher). In the corporate world, branding requirements often demand the use of specific fonts. But a community-based reference site like Wikipedia should not impose any such restrictions. I propose that the CSS be changed to specify a font-family of sans-serif only, i.e., no specific font name. Also, the font-size should not be specified, i.e., the browser will display body text in the default (medium) size. This way, each user will see Wikipedia in the font of their choice and the size of their choice, i.e., whatever font and size settings they have set in the browser. The only choice made by Wikipedia is to display everything in a san-serif font (which is more readable on screens, as opposed to print).
P.S. It is OK (even advisable) to specify a line-height to add some leading, since this enhances readability, especially when there is a lot of text. This should be done in relative units, not absoloute units, so it respects the reader's size settings.
Hello, since few days ago a curious bug appears to me and only in the English Wikipedia!? I use Win7 and FF 28. I know I can change the font but I would report this issue (as you can see right, this bug appears also logged out). What can this be??? (I'm from the German Wiki) -- πϵρήλιο17:35, 7 April 2014 (UTC)
@Perhelion: I tested this on Win7 and FF28 as well and can't replicate this (screenshot). Could this be a browser extension, gadget, or personal CSS style you have enabled? Checking in incognito/private browsing mode might help. Steven Walling (WMF) • talk00:26, 8 April 2014 (UTC)
Hello @Steven:, I found the reason fortuitously!! Because this bug appears now also in the German Wiki and also in Chrome/IE and I saw that the standard font group (Arimo,"Liberation Sans" was removed) was changed today. It is the incompatibility of the font Helvetica Neue (/Helvetica) with Windows 7! Here are the bug-reports:Chrome,Firefox,Firefox, maybe IE9 on generally Helveticamicrosoft and you can google all. I think this is a bad bug for Wikipedia!? But the good thing is "Helvetica Neue" is not a standard font from Windows7. The additional difference to Chrome / IE and Firefox is that in FF the whole text is bold (zoom 100%). Can you/someone now reproduce that (I've also read there are could be also different "Helvetica Neue")? -- πϵρήλιο01:30, 8 April 2014 (UTC)
Two days on
OK. The weekend is over. Wikipedia still looks like crap on every browser on Win7/8. Will now someone revert this ridiculous change? ♆ CUSH ♆17:58, 7 April 2014 (UTC)
You'd of thought they'd revert the day we all disagreed with it but as usual no one gives a toss about what the community thinks! ... As clearly proven with this and VE. Anyway I wouldn't hold your breath!. -→Davey2010→→Talk to me!→19:26, 7 April 2014 (UTC)
Cush, if you really can't personally stand it, this is why personal CSS and Edokter's gadget exist. You have options if you don't like site defaults. Steven Walling (WMF) • talk00:20, 8 April 2014 (UTC)
Polish Wikipedia entry page with no font correctionSorry, that is an unacceptable attitude from a product manager. Of course I can change my vector.css and I have, but this is not about me. You obviously do not give a crap about the millions of visitors that are not registered and have no option to change the appearance of their Wikipedia. Besides being all in bold font now, in all eastern European Wikipedias (and I suppose in many others) non-latin1 and special characters are not displayed by your new font and are substituted from a different font. That is technical incompetence. Even after over a week it is still messed up. I am a web developer and in the company I work for you would be in serious trouble for messing up trivial technical issues like this and then being undiscerning about it. ♆ CUSH ♆06:54, 14 April 2014 (UTC)
Screenshot of Polish Wikipedia main page, Firefox and Windows 7@Cush: When users report issues, we have to be able to replicate them to make sure that they in fact do impact a large number of users. In this case, the excessive bolding that you see in the screenshot is not something I am seeing when testing on Windows, Mac, or Linux. (See the screenshot I just provided.) Can you tell me what Firefox version you're using? There is also no reason why special characters in Latin languages would display in a separate font. You should be getting Arial, unless you disable it or have a version of Helvetica installed. Steven Walling (WMF) • talk21:25, 14 April 2014 (UTC)
Update: Hi everyone. I just wanted to let you know that we've updated the body text font settings. Liberation Sans and Arimo are now removed, and the font stack is "Helvetica Neue, Helvetica, Arial, sans-serif". Most users should not see any change due to this, with the exception of users who had those two previous fonts installed. We removed them due to bug 63512, where Windows users (especially those without font smoothing turned on) had significant problems with readability with Liberation Sans or Arimo. Thanks for your understanding and patience so far, as we've worked to address any issues after the new release. Please do let me know if you find the experience improved now, or if you encounter any new issues. Steven Walling (WMF) • talk00:19, 8 April 2014 (UTC)
It might be useful for someone from WMF to start a new section on this page listing the most frequently-reported issues, how they have been addressed, what issues are still left to address (Are old Helvetica fonts still a problem? Cleartype? ), and what information people should provide if they still have problems. If you're feeling bold, you could even explain some of the WONTFIX issues that people are complaining about as well. Encourage people to stick to technical issues, since this is a technical forum. Mixing the technical issues with the (obvious, at least in hindsight) process issues muddies the waters and may interfere with resolving the remaining technical problems. – Jonesey95 (talk) 03:26, 8 April 2014 (UTC)
When it comes to iterating on this, we are focusing on functional issues, especially accessibility, browser-specific issues, and non-Latin languages like Chinese, Japanese, and Korean. If anyone has purely aesthetic complaints still, they are of course free to log in and personalize their experience via the opt-out gadget for Vector, personalizing their skin CSS, or choosing one of the other skins available. The default typography on Wikipedias has to serve everyone. That doesn't mean we actually can please everyone individually, especially if even by now you're not used to the new look. This is why we allow you to customize your experience on the site. Steven Walling (WMF) • talk05:06, 14 April 2014 (UTC)
Though aesthetic issues are not technical, most of our readers don't have the choice, unlike us who are logged in. Why don't you guys do a sort of survey, and put up a banner on top or a tool like article feedback on bottom so readers can directly state their opinion? Yes we can't please everyone, but I don't think we know what is the opinion of the majority of our logged out readers. Any way, you guys have more expertise in this area. -- Fauzan✆ talk✉ email06:00, 14 April 2014 (UTC)
@Stephen: this is exactly what I am talking about. You aren't engaging us as fellow users but as someone who is in charge, telling us the way things have to be. A founding principle of Wikipedia is that we are all equal. You just have some privileges we don't. You do not get to determine what is best for everyone. You claim that you have to consider everyone's opinions, but every time we suggest any way to figure out what that is, you have an excuse for why that wouldn't work. What you wind up doing is asserting that the opinions of the WMF programmers are what the majority wants.
It may not give you perfect information, but voting would actually give you some information and thus you could actually assert factually that you are doing things for everyone. You may actually believe that you are doing what is best for Wikipedia, but the road to hell is paved with good intentions. Deciding for readers or editors what they want is a perilous road to go down. Wikipedia is as large as it is because we work with consensus. The last thing you want is for people to leave because they don't feel they have a voice. — trlkly22:44, 14 April 2014 (UTC)
Help - my old font gadget disappeared
It's still in the gadget section, but it doesn't work. Anyone else experiencing this? It's working in edit mode though, but not it reading mode. Regards, Iselilja (talk) 09:19, 8 April 2014 (UTC)
Yes, that is basically the intended effect. Your 'current' version is using Nimbus Sans L (which is Linux' substitute for Helvetica). I don't know what the right side font is (which is your default sans-serif font), but it looks like Rockwell, which is actually a slab serif. I should have spotted DejaVu Serif. — Edokter (talk) — 17:09, 8 April 2014 (UTC)
AzaToth The font you're seeing probably feels bolder because the letterforms are more compact. We compensate for the large, dense blocks text though by changing the font color (from pure black to very dark grey) and by increasing the size by one size. Steven Walling (WMF) • talk08:36, 11 April 2014 (UTC)
AzaToth Nimbus Sans L has no hinting hence the blurry boldness, your default font is DejaVu Serif or Bitstream Vera Serif which have hinting (for CRT) hence the ultra sharpness. Steven (WMF) Yes, Nimbus Sans L has more compact glyphs but a compact design could be hinted, be sharp and crisp, compact glyphs it’s not the cause. --Moyogo/ (talk)18:26, 15 April 2014 (UTC)
Nimbus Sans does have hinting. DejaVu Serif has slightly better hinting on Linux (for which it is optimized), but not so good on Windows. Azatoths DejaVu Serif example uses sub-pixel rendering by the way; there is no such think as "CRT" hinting. — Edokter (talk) — 19:23, 15 April 2014 (UTC)
How can readers figure out what's going on?
How can a reader (or editor) command his/her browser to tell him/her what font is in use at any particular spot in a Wikipedia window? Really an issue for all environments, but I'll settle for Windows 8.1 and Firefox 28.0 Jc3s5h (talk) 15:46, 11 April 2014 (UTC)
Right-click on the text in question, and select "Inspect Element". This opens two panes at the bottom of the screen. In the right-hand pane, click the "Fonts" tab. The middle row here might say "Arial Bold system", "Microsoft Sans Serif system", "Courier New system" etc. Ignore the word "system" - that tells you that it's a font that exists on your system. The rest is the font name - Arial Bold, Microsoft Sans Serif, Courier New. Press F12 to close those panes. --Redrose64 (talk) 16:45, 11 April 2014 (UTC)
The question mentioned Firefox 28, so that's what I used to prepare my reply. For current versions of Safari (presumably on an Apple), I can't say: I have Safari 5, which was the last version released for Windows - but that has no feature equivalent to "inspect element". --Redrose64 (talk) 17:35, 11 April 2014 (UTC)
Yeah unfortunately not all browsers have the same support for easily showing what fonts are rendered. Updated versions of Firefox is the easiest across all operating systems, per what Redrose64 said. Others require an extension to view this easily, like WhatFont in Chrome. Steven Walling (WMF) • talk18:16, 11 April 2014 (UTC)
Safari 6 has the "inspect element" item, but I can't find an easy way to locate the font. In Firefox, it says I'm seeing Helvetica Neue, and presumably it's the same on both (since it's the same computer). But what's I'd been hoping to find was the font size, because they're not the same in the two browsers. WhatamIdoing (talk) 21:48, 11 April 2014 (UTC)
In Firefox, get to "Inspect Element" as above, but instead of selecting the "Fonts" tab, select the "Computed" tab to its left. That gives an alphabetical list of CSS properties: in there you should find font-size:. If it's not there, you need to get to the next HTML level outwards - I know exactly how to do this but it's difficult to explain. On my browser, to the left of the "Computed" tab there's a "Rules" tab; to the left of that is a magnifying glass icon; to the left of that is a > button; to the left of that is a row of chevron-shaped buttons. Most have pale grey text on a mid grey background, but one will be mid blue on a dark grey background. That represents the HTML element that you right-clicked on. If you click the chevron to its left, it will change to mid-blue on dark grey and the content of the "Computed" tab will change to show the properties of the immediately-enclosing HTML element. Keep going to the left until you find one where font-size:is listed; don't go any further out. --Redrose64 (talk) 22:53, 11 April 2014 (UTC)
Thank youJokes Free4Me Right, in Safari 5 (having enabled "Show Develop menu in menu bar" at Cogwheel → Preferences → Advanced), you would right-click on the text, select "Inspect Element" which opens two panes. In the right-hand pane, uncollapse the "Computed Style" heading. You then have an alphabetical list of properties; you're looking for font-family: and font-size:. If you don't see these, enable "Show inherited" to the right of the heading. You might see font-family: 'Linux Libertine', Georgia, Times, serif; - unfortunately, that doesn't tell you which font is being displayed, because it's the list of fonts (in descending order of preference) that the webpage would like to be used. Which one is actually used depends upon the installed fonts on your system. For example, if you don't have Linux Libertine installed on your system, but do have both Georgia and Times, the text will be displayed using Georgia, but you'll still see Linux Libertine listed first. It won't use Times, because that's listed after Georgia. --Redrose64 (talk) 15:08, 12 April 2014 (UTC)
In Windows 7 where Arial Black is bundled, I don't know if it's the typography Refresh enabled the black bold font weight when bold wiki markup of three apostrophes and the CSS styling of font-weight:bold (not other weight value) are affecting the text like this "<span style="font-weight:bold">'''extra bold'''</span>". This creates an unexpected effect identical to 900 font weight (<span style="font-weight:900">900 font weight</span>). This happens an awful lot in table header where the text is generated from text template which already changed the font weight with 3-apostrophe markup. IMO, if someone wants "black" bold, it should be achieved only via CSS styling rather than this unusual combination of CSS and wiki markup. -- Sameboat - 同舟 (talk) 00:02, 12 April 2014 (UTC)
It's not an "unusual combination of CSS and wiki markup" that causes this: the HTML emitted by <span style="font-weight:bold">'''extra bold'''</span> is <span style="font-weight:bold"><b>extra bold</b></span> where the visible effect is just the same. The CSS spec allows for more than one level of boldness above (and below) "normal" weight (see the font-weight property in CSS 3), and the <b>...</b> element doesn't mean "use boldface" or "use a specific weight" - it means "draw attention to this text", which most browser vendors interpret as "use a font weight that is bolder than the current font weight". Some fonts have only two weights - normal and bold; others have three or more. If a two-weight font is in use, then text marked up in the manner described will appear similar to text marked up as <span style="font-weight:bold">bold</span> and also similar to text marked up as '''bold'''. But if the font family is changed to one which supports two or more weights that are bolder than "normal", you will see a difference.
Typography refresh changed the font families; it didn't change the way that bold markup is processed. There should be no need to use explicit boldface markup in a table header: see #Old look elsewhere on this page. --Redrose64 (talk) 09:12, 12 April 2014 (UTC)
The real issue is that many editors ignored this behavior while designing text template with bold font (c.f. the infobox header and Transfers section of Kalininskaya Line) and only noticed the actual effect until TR compulsively define the font family which provides higher font weight (Arial family with "Black" variant) than the usual boldface. I don't know if there's any good reason to allow bolder than bold font for "drawing attention" in Wikip(m)edia. I think it has little to no harm to cap the emphasis level at conventional bold in the font-weight:bold+<b> structure without ruling out font-weight:900 for "drawing maximum attention". -- Sameboat - 同舟 (talk) 09:43, 12 April 2014 (UTC)
FYI:Collection of most frequently reported issues, solutions, and proposals
OK, so no one from WMF did it, I have collected most issues, solutions and proposals I came across in tabular format. Please update it if you think something should be added or removed. It will then be easier to review what needs to be done. -- Fauzan✆ talk✉ email18:34, 12 April 2014 (UTC)
For actual technical issues (rather than just complaints based on personal preference) these are tracked like all issues in Bugzilla (bugzilla.wikimedia.org), which tracks issues across Wikimedia projects. The master tracking bug for the typography update is here. There is also the cross-wiki Talk page for the feature. Remember that this is not specific to English Wikipedia, it's the default across all language editions of Wikipedia, as well as other projects like Commons. Discussions like this one on VPT or on another more specific Talk page are very helpful, but we don't just track issues here because site defaults like this impact all wikis. Steven Walling (WMF) • talk04:49, 14 April 2014 (UTC)
مساعدة
انا مستخدم من ويكيبيديا العربية اريد أن اعرف كيف جعلتم الاسماء المخالفة مثلاً(التي تحتوي على البريد الالكتروني)لا تستطيع ان تسجل في ويكيبيديا الانكليزية هل هو مرشحح أساءة اما ماذا (اريد ان انقله الى ويكيبيديا العربية)ارجوا الاجابة بالغة العربية--Zen alramahi (talk) 17:08, 22 April 2014 (UTC)
Translation: "I am a user from Arabic Wikipedia. I want to know how did you make the inappropriate usernames, for example, (that contain email address) not able to register in English Wikipedia. Is it an abuse filter or what? (I want to move it to Arabic Wikipedia.) Please answer in Arabic." --Meno25 (talk) 21:33, 22 April 2014 (UTC)
A tilde plus trema diacritic is used for this in the Extensions to the IPA: [n͋] is an alveolar nareal fricative, with no airflow out of the mouth, while [v͋] is an oral fricative (a [v]) with simultaneous nareal frication. No known natural language makes use of nareal consonants.
This combination of phonetic diacritics, described as tilde plus trema, displays incorrectly in Helvetica, as two tildes stacked vertically.
That sounds like it's a font problem, and I can pretty much tell you exactly what happened. The ͋ diacritic has a unicode code point of U+034B, while the ͌ diacritic is U+034C. I bet they got conflated when the font was created, and they are both so rarely used that nobody noticed. VanIsaacWScont04:58, 23 April 2014 (UTC)
Wait, so in Helvetica, the glyph for U+034B displays as the glyph of U+034C ? If someone can hand me as much background info as possible on that (specifications by the unicode group preferred), I'll file a developer bugreport with Apple on that problem. —TheDJ (talk • contribs) 12:05, 23 April 2014 (UTC)
I'm saying that Thnidu's font seems to have it wrong. But I wouldn't file any sort of bug report until I knew where his/her copy of Helvetica came from, which version it is, etc. VanIsaacWScont17:16, 23 April 2014 (UTC)
Check your font
Tilde w/ dots: ͋v Double tilde: ͌v
Firefox 28.0 and Safari 7.0.3 under MacOSX 10.9.2: both display as double-tildes, but the "tilde with dots" glyph is slightly larger than the "double tilde" glyph. --Carnildo (talk) 23:39, 23 April 2014 (UTC)
I was trying to sort an article under (lower case) "e" but on the category page it was sorted under (capital) "E". Does anyone have any suggestion as to how to get around this? Here's the category: Category:English lexical sets. I'd wanted to sort DRESS lexical set under "e" since that's the IPA symbol (not "E"). Jimp12:48, 23 April 2014 (UTC)
We make use of a collation where A and a are grouped under the same sort key. In the majority of cases this is extremely useful. Unfortunately for your specific case, that means that there it is not possible to list E and e under a different sortkey. They will be ordered separately inside the sortkey group, but they will all share the same group, which is in this case starts with E and is thus called E. —TheDJ (talk • contribs) 13:35, 23 April 2014 (UTC)
We used to have case-sensitive cat sorting, with "a" sorting after "Z"; but it was altered to case-insensitive just over three years ago, in early March 2011 with MediaWiki 1.17. --Redrose64 (talk) 16:55, 23 April 2014 (UTC)
This was an unfortunate consequence of the community not being able to make integrated sensible decisions. All the best: RichFarmbrough, 00:40, 24 April 2014 (UTC).
Likewise, Wikipedia is not a bureaucracy means that there's no need to put closing templates on decade old discussions where the primary link has gone red. In my opinion, it muddies the historic record by introducing a template that didn't exist at the time of the discussion, so I recommend not doing that. If you really feel that it needs clarifying, you can add a hatnote. — Scott•talk10:21, 24 April 2014 (UTC)
Wikipedia email not working when I send but works when others send to me
I changed my email in preferences to a new one a few weeks ago and AFAICT it's not working, but only when I send messages to another user; it works when people send messages to me. It's a rather standard Yahoo email address, - no strange characters; in fact it's seven roman alphabet characters, all lowercase, followed by two numbers AT yahoo.com, like johndoe99@yahoo.com. About a week ago I emailed another user who said they never got it. They then emailed me using the Wikipedia facility and I did get it, so I know Wikipedia actually recognizes the correct email I have set. As a test, I sent myself two emails using the Wikipedia interface over an hour ago and got neither.
Also I have my preferences set to "Send me copies of emails I send to other users" and when I send emails, the similar box on the email page that says "Email me a copy of my message" is also ticked. I have never gotten a single copy of an email I have sent in the past few weeks and I've sent a few, including one earlier today (that I now expect, won't reach its intended recipient). Yes, I am checking both spam and trash folders. I am simply not receiving. Could it be something in my various interface tweaks, scripts, my use of Monobook? Any ideas?--Fuhghettaboutit (talk) 00:41, 24 April 2014 (UTC)
Crap. Thanks for the info. Looks like I'm opening a new gmail account today.--Fuhghettaboutit (talk) 10:42, 24 April 2014 (UTC) P.S. just as confirmation, I set up a Gmail account, sent out the email I had sent earlier, got the copy as I'm supposed to, and got a reply which indicated that the prior email sent through Yahoo! was never received.--Fuhghettaboutit (talk) 12:27, 24 April 2014 (UTC)
This is serious. Is the Foundation considering a workaround like some sort of cooperation with Yahoo, or writing Yahoo "sender" addresses in the mail body and not the sender field which could be something like "noreply@wikimedia.org"? And how about warning users with Yahoo addresses? At a minimum, we should add info about this to email help pages like Help:Email confirmation and Wikipedia:Emailing users, but most users will not see that, and the issue affects all wikis. MediaWiki:Prefs-help-email is displayed at Email options at Special:Preferences, but a warning to all users without knowing whether they have Yahoo would probably be too much. PrimeHunter (talk) 11:10, 24 April 2014 (UTC)
I'm contemplating creating a series of mathematical bibliography articles. The bibliography entries tend to exist in BibTeX (a very good thing). These should be converted to UTF-8 in the article (this is for author and journal names, not the occasional mathematical notation). This is straightforward in vim+python, but I'm wondering if there's a better way. Here's an example of a partially-fixed BibTeX entry:
Note that I've already done the code to get the "á" in "Pál" and the "ő" in "Erdős", but I've not yet done the work to convert "Vojt\v{e}ch {Jarn\'{\i}k}}" to "Vojtěch {Jarník}".
I'm guessing I'm not the first person to need a LaTeX->UTF8 source translator. Any ideas other than writing my own?
For some reason the gadget (Special:Preferences#mw-prefsection-gadgets) under "Appearance" titled "Add a "Sandbox" link to the personal toolbar area" isn't working for me anymore. This seems to have changed sometime in the last couple of hours because the "Sandbox" link in my toolbar is no longer there. Anyone know what might have happened? Thanks, —dainomite08:53, 24 April 2014 (UTC)
Paradoctor (talk) 19:58, 5 April 2014 (UTC)
Done. Enjoy using it. -- Jokes_Free4Me (talk) 22:08, 6 April 2014 (UTC)
Fixed
I no longer have the "Cite" menu on my editing toolbar. There are the icons just above the text box for Bold text, Italic text, signature and timestamp, link, embedded file, reference, and drop-down menus for "Advanced", Special characters", and "Help". That is all. I use to have one that said "Cite". I am quite dependent on it. Please help! I've tried switching browsers from Chrome to IE, restarting the computer, and searching under "My Preferences". Chrisrus (talk) 06:07, 8 April 2014 (UTC)
Moved to Template talk:Ihwu
).
Western Sahara (
at the top right? PrimeHunter (talk) 22:56, 11 April 2014 (UTC)
Comment: I've started a thread about creating a Sitenotice regarding this. It Is Me Here t / c 19:19, 15 April 2014 (UTC)
Sealand ref-superscript jumps to the beginning of the new line. XXN (talk) 00:56, 15 April 2014 (UTC)
Arsenal (assistant coach). Pls explain to me how to do it, or just edit the template for managerclubs1 and I will do the rest. Xaris333 (talk) 14:36, 18 April 2014 (UTC)
Fixed Special:Diff/605135493. See Template:Old_AfD_multi#Parameters. --Glaisher [talk] 11:35, 21 April 2014 (UTC)
) is not displaying properly for me using IE11 on Windows 7 - what I see looks like a striped hyphen in the middle of the flagicon frame. Does it appear correct on other browsers/OS? Thanks. DH85868993 (talk) 10:30, 22 April 2014 (UTC)
Resolved. We've updated the settings to avoid body fonts that render poorly without ClearType. Steven Walling (WMF) • talk 23:47, 5 April 2014 (UTC)
Current
Without the new specified font face
![[9]](http://neotarf.files.wordpress.com/2014/04/smcc-sig-screenshot.png){kind=link}
![[34]](http://i.imgur.com/zKrgxvR.png){kind=link}
.jpg){kind=link}
Thank you Jokes Free4Me Right, in Safari 5 (having enabled "Show Develop menu in menu bar" at Cogwheel → Preferences → Advanced), you would right-click on the text, select "Inspect Element" which opens two panes. In the right-hand pane, uncollapse the "Computed Style" heading. You then have an alphabetical list of properties; you're looking for 
