Wikipedia:Village pump (proposals)/Archive 124

So I'm not sure if this has already been asked in here...what about displaying permalinks for sections at mouseover of section-titles?

I'm not sure how these things are called (section-anchors?) - here's what I mean: https://i.imgur.com/UUQemyS.jpg
The site in that screenshot is: https://github.com/goldsmith/Wikipedia#installation - to see what I mean hover over the Installation-section.

I meantioned this in my upper proposal - if one had these anchors displayed at mouseover of sections one could also show a 2nd button there that at a clicks shows all the articles that link to that specific section.

Is the reason it's not already featured that articles have these "contents"-boxes which can be used to create permalinks for article-sections?

What do you think of this proposal?

--Fixut͉͇̞͖͉̼̭͉͓͑̈̉́͑ȗ̹̲ͨͮ̂̂̄ṙ̫̥͚͚̜͙͍̰́̈́ė̺̩̞̗̓̉ͧͩ̿ͤ̎̆ (talk) 19:04, 7 June 2015 (UTC)

We recently tried this, but for various technical malfunctions it had to be undone. See also phab:T18691, which has a ton of discussion. —TheDJ (talk • contribs) 23:38, 7 June 2015 (UTC)

Interesting that there were technical problems with this. I just tested and the test worked ... just adding the "#{{{section title}}" to the end of a permalink and it worked. The test case .. https://en.wikipedia.org/w/index.php?title=Samsung&oldid=666428903#Operations . So I think that this would be a suitable manual accomodation, and I'm sure that a script could be composed to generate these automatically. Not sure if this is a general solution, but it worked in this particular instance. --User:Ceyockey (talk to me) 03:18, 11 June 2015 (UTC)

Apologies if this has been discussed before but I propose that, given the existence of Commons and Wikilinks, there is no need for any wikipedia article to include a gallery. The danger being that inexperienced readers may believe that the gallery contains all images relating to the subject that the project holds when this is far from the case. Comments please S a g a C i t y (talk) 15:08, 2 June 2015 (UTC)

• Visual arts articles in particular benefit greatly from good use of galleries. You're not going to protect articles from newbies' shitty use of galleries any more than you'll protect them from newbies' shitty prose. The answer is to fix it, not to ban it. Curly Turkey ¡gobble! 20:20, 2 June 2015 (UTC)
  • Well gobbled. We have link templates to point readers to the relevant collection of images on Commons, so even if an article contains a gallery, chances are high that there will be a note "Wikimedia Commons has media related to <subject>" at the bottom of the page. And if inexperienced readers don't get such hints, that's no reason at all to penalise the rest by abolishing galleries. De728631 (talk) 20:30, 2 June 2015 (UTC)
  • I agree 100%. Curated galleries are a benefit to some articles. Galleries should not be banned because of poor implementations on some articles. AHeneen (talk) 01:43, 6 June 2015 (UTC)
• As a long-term user of Wikipedia, I understand the problems with galleries of indiscriminate images tacked on to the end of articles, as I've seen plenty and they can be bad. But used well, a gallery can definitely improve an article. The visual arts example given by Curly Turkey is a good one, and for example, the Pablo Picasso article would be poorer without a gallery of some of his works. But galleries can also be used very well in general subjects. See the article section Roman Britain#Roman rule is established, where a simple two-image gallery is used to good effect (and there's another just below). So no, I think it would be a bad move to get rid of galleries. Mr Potto (talk) 09:07, 3 June 2015 (UTC)
  • In the Roman Britain example would actually be better off using Template:Multiple image instead of a gallery. Using the template would eliminate the excessive gray border of those images and allow a single caption. AHeneen (talk) 01:43, 6 June 2015 (UTC)
    • The "excessive" gray border is the same border used on all thumbmails, and that {{multiple image}} doubles (one "excessive" gray border for the whole box, plus one for each image). If you want to eliminate the borders, then you use <gallery mode=nolines caption="Roman invasion of Britain"> in a gallery. (I'm not sure how to right-align it, though.) WhatamIdoing (talk) 00:19, 8 June 2015 (UTC)
• I concur with Mr Potto. The problem of galleries of indiscriminate visual clutter is the same as, e.g., the problem of someone dwelling on excessive detail about a biography subject's childhood, or any other form of over-inclusion: It's a
  WP:RELEVANCE matter of content determination and adjustment for discussion at a particular article's talk page, not indicative of a site-wide problem requiring sweeping change.  — SMcCandlish ☺ ☏ ¢
   ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:52, 4 June 2015 (UTC)

• Commons is a repository of all free images (in theory) on a subject. A galley is a select set of those images to provide some additional context on a subject. - Floydian ^τ _¢ 22:15, 6 June 2015 (UTC)
• Just to pile-on and agree with everyone else that abolishing galleries would be a terrible idea. For example, most major cancer articles now have mini-galleries with diagrams released for each main
  cancer stage (images all from Cancer Research UK). Examples: Lung_cancer#Staging, Endometrial_cancer#Staging, and so on Try picking up that information from the Commons categories! Much of Commons is a nightmare to use because of the vast numbers of unsorted images & the often insane categorization schemes, which few know how to negotiate. Galleries certainly can be misused, but in my experience examples of this have greatly declined since say 5 or 8 years ago. They are certainly vital for visually-oriented topics like art. Johnbod (talk
  ) 21:34, 12 June 2015 (UTC)

Some time ago I thought that many readers would benefit if we could embed simple interactive programs (widgets) into articles to help illustrate and explain the concepts within them. So I thought of a crude way to implement it and made a proposal here. However, maybe due to technical and conceptual immaturity, it didn't garner much support. So I took it to my home project, the Spanish Wikipedia. There it sparked some interest, and slowly we refined it and eventually implemented it. Today we have two wikiwidgets already deployed, you can check them out here and here.

Today I'd like to share with you the way we implemented it, and ask for your support to get it working here in the English Wikipedia. Basically, to get the wikiwidgets working we need three things.

First we need to create the Template:WikiWidget. That's easy, I just did it. Second, we need to add the following lines to MediaWiki:Common.js:

/**
 * Inserts WikiWidgets in the articles with the Template:WikiWidget
 * WikiWidgets serve to illustrate and explain interactively the concepts treated within articles
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).attr( 'data-wikiwidget' );
	importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
	importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
});

This code checks for the presence of the WikiWidget template in every page. When found, it loads the code of the wikiwidget named in the first parameter of the template. If the wikiwidget is called X, the loaded code will be MediaWiki:WikiWidget-X.js and MediaWiki:WikiWidget-X.css. So the third step is to add the code of one or both existing wikiwidgets to their proper pages in the MediaWiki namespace, that is:

• MediaWiki:WikiWidget-Formicarium.js
• MediaWiki:WikiWidget-Formicarium.css
• MediaWiki:WikiWidget-Vivarium.js
• MediaWiki:WikiWidget-Vivarium.css

You can find the code in the homonymous pages in the Spanish Wikipedia, or at the GitHub project here.

Besides the implementation, a bit of documentation will be needed for the template, at

While this would be interesting in theory, I have to oppose this on the principle that we shouldn't require JavaScript for page content. JavaScript can and should enhance site functionality, but shouldn't be strictly required whenever possible. {{Nihiltres|talk|edits}} 16:37, 26 May 2015 (UTC)

I also think this is a bad idea, for a number of reasons. Embedded JS raises serious performance, accessibility and security concerns. Performance in that running JS uses CPU cycles. Accessibility as many people disable JS; many more have browsers unable which don't support HTML5/JS which this needs. And security as having complex and arbitrary JS run on pages opens them up to all sorts of exploits. We can already do animations with animated GIF or movies, so there’s little need for it.--JohnBlackburne^words_deeds 16:52, 26 May 2015 (UTC)

Hi, thanks for your constructive criticism. The wikiwidgets don't make JavaScript necessary in any way. I forgot to mention this (sorry) but the second parameter of the WikiWidget template is the file to be shown when the wikiwidget isn't loaded. In fact, the file is always shown, it's just that it's replaced by the wikiwidget when the JavaScript code loads. If the code doesn't load for whatever reason, then the file will just stay there. This means that the JavaScript code isn't required at all, pages will render fine without it. Having JavaScript just enhances the user experience.

As to security, the development process of wikiwidgets is very similar to that of gadgets, yet we don't reject gadgets for security concerns. We just need code review, like with gadgets or any other piece of code, and this will be accomplished through the GitHub project.

Regarding performance, I can edit the existing wikiwidgets so that they don't start automatically, and we can establish this as a rule for further wikiwidgets. This would make them much less of a bother for those with weak CPUs.

I think that a wikiwidget isn't nearly the same as an image or a movie: it incorporates a key element to the learning process: interactivity. The existing wikiwidgets already show some of the potential (did you play with them for a while?), but there is a lot more to be discovered. Imagine other wikiwidgets for explaining the movements of the planets or other physical phenomena, and all those that we cannot imagine yet. The field is vast. But even if we never get beyond a few wikiwidgets, then a few is better than none, don't you think? We already have two available, all we need are a few lines of code to get them working. Cheers! --

talk

) 01:55, 27 May 2015 (UTC)

Your two demo links were impressive. They are very valuable additions to the articles. Unfortunately I don't think we can allow editors to inject arbitrary code into pages. It's a security issue. Alsee (talk) 02:56, 27 May 2015 (UTC)

Hi

talk

) 03:35, 27 May 2015 (UTC)

I do, and I suspect that anyone who knows anything about what

could be done by an admin who is careless (or whose account was hacked by someone malicious) will agree with me. We ought to require code review for popular gadgets—including every single change, not just when it's first enabled. Code review isn't fun, but it does prevent problems. WhatamIdoing (talk

) 08:50, 27 May 2015 (UTC)

talk

) 13:10, 27 May 2015 (UTC)

Gadgets have been mentioned but they have two key differences. First they are opt-in. They may start off as some editors personal tool, which they advertise and gets adopted. Eventually they may be added to preferences, but that's not a requirement, and many still exist as snippets of JS and CSS you add to your own common.js and .css or similar. This means they cannot affect editors who haven't enabled them and aren't aware of them. Second because of they way they work they are typically visible to editors using them across all pages. This means that problems with gadgets are almost always spotted and reported very quickly.

On the other hand problems in articles can go unnoticed and unreported for a very long time, weeks, months even years. At the moment these only damage the encyclopaedia, by lowering its average quality. But if JS widgets were allowed in page the potential for direct harm to readers is much much greater, which also increases the incentive to do harm, and to hide the nature of the damaging JS. Mandating a thorough code review would catch many if not most of these but that would be an immense amount of work, which we don't do for any other sort of content. JohnBlackburne^words_deeds 16:24, 27 May 2015 (UTC)

talk

) 18:58, 27 May 2015 (UTC)

No, the performance and accessibility issues are still issues: pages on WP currently load fine with no JS at all (though it's needed for many optional and editing features). But security is the main concern. We certainly don't want to require editors to sign up to and become familiar with GitHub to contribute. It has its uses but largely replicates what we have here already. E.g. instead of a commit history we have a page history. Instead of being able to fork here you can use a sandbox or sandboxes. And as far as we are concerned WP's mechanisms are stronger: we have e.g. user rights so not everyone can edit code. Anyone can sign up to GitHub. Users contributions here are tied to their accounts, useful for awarding rights and reviewing them. That would not be possible with GitHub contributions. And so on.JohnBlackburne^words_deeds 19:34, 27 May 2015 (UTC)

Ok

talk

) 02:16, 28 May 2015 (UTC)

Again the performance and accessibility issues are that it uses JavaScript. I am typing this on a relatively old (2006) laptop. Hardly ancient and it still works fine. Except many web sites are unusable due to JavaScript; they slow to a crawl, and/or start using 20% of CPU. Open two or three tabs and it can bring my whole machine to a halt. So I sometimes have to turn off JavaScript to browse them. Not WP though which works fine without JavaScript (though I loose some gadgets such as popups). Right now any WP page wastes no CPU cycles on JS whether reading or editing. If it did I would have to consider disabling JavaScript to view such pages, or not visiting them at all. Other people may not have that choice, or may not be aware of it, so may just find WP suddenly slow and stop visiting. Still others will disable JavaScript for other reasons: to disable adverts, or paywalls, or for general security reasons. And many will have older browsers which do not support the particular HTML/JS capabilities this depends on.

The point about Github is these are content, not parts of the WP software. And content is hosted on WP, or on Commons. This even includes source code, such as Lua, and a limited amount of JS such as MediaWiki:Common.js. Hosting it on GitHub would just exclude many editors from contributing, whether that's contributing code, checking and verifying code, or making suggestions for improvements. Given that GitHub largely duplicates what we have here it would seem perverse to host it there when it can be done very easily on WP with far better integration into WP systems and accessibility for WP editors.--JohnBlackburne^words_deeds 19:50, 28 May 2015 (UTC)

I'm adding a few quick comments here, to make sure that we're all using the same language:

• "Gadget" means "thing listed at Special:Gadgets". These are the scripts that you'll find in Special:Preferences#mw-prefsection-gadgets. If you create the same kind of thing, but it isn't listed there, then it is called a "user script".
• Gadgets can be, and sometimes are, enabled by default. At the moment, I count nine gadgets enabled by default in the list at MediaWiki:Gadgets-definition at the English Wikipedia (this is the page you [if you're an admin] change to add, remove, or re-configure all gadgets). The list of on-by-default gadgets include mostly Javascript (e.g., charinsert, RefToolbar, Reference Tooltips) and a couple of things with both Javascript and CSS (e.g., Teahouse, Featured Article links).
• Code review is a sort of (very) fully protected style of WP:Pending changes for code. The general idea is that I post my code revision, but nobody uses that code unless and until someone else (someone trusted) looks it over and agrees that my code is sensible and unlikely to break stuff.
• There is no way to require code review for any user script, any gadget, or any other page hosted on wiki. (Even if it could be applied to Javascript files or pages in the MediaWiki: namespace, Pending Changes never stops an admin from making live changes to a page.)
  • Exactly like user scripts, almost none of the gadgets at the English Wikipedia are fully (formally) code reviewed. This is because most of them are hosted directly on wiki, where your change to the page is live immediately, no matter what.
  • There is no way to prevent any admin from making immediate changes to what's in the list of gadgets or whether they're turned on by default. Other tech-savvy admins also watch the page, but your (any admin's) change to the gadgets page is live immediately, and if your typo breaks things, then it's broken for thousands of readers and editors immediately. There is currently no way to force code review for this page. Admins can optionally choose to post their suggested code in a sandbox or on the talk page, but there's nothing except their own fear of breaking things to require sensible measures like that.
  • Ditto for pages like MediaWiki:Common.js, which hosts what you might think of as "gadgets" that you're not allowed to opt out of. m:WikiMiniAtlas is a particularly relevant example, since it's code-reviewed using the same system that Felipe is proposing, it's enabled for everyone (with no ability to opt out, even), and it directly affects article content.
• The lack of code review for on wiki scripts has led to a variety of problems, usually minor, over the years. Here at the English Wikipedia, it's usually resolved within a few hours. At some of the smaller wikis, problems have persisted for years, and many of them are quite easily identified through basic code review. For example, in 2013, someone found and fixed a problem at a small Wikipedia that was due to someone pasting the same code twice into the common.js (or was it common.css?) file. This is the sort of problem that code review usually catches.

If you're interested in this problem, then I'll add that a system for code review for gadgets and other designated scripts could be implemented, but it would require more than a little bit of dev time. I don't know if it's likely to happen unless the larger communities request it. WhatamIdoing (talk) 15:19, 29 May 2015 (UTC)

Thanks for your contribution WhatamIdoing. I just checked and it seems like Gerrit has no repositories for gadgets! It looks like they are all developed via GitHub or some other code developing platform, or even through no platform at all (no code review). Indeed it would seem that organising and even centralising gadget development would be a good thing, but this is another issue (and a big one for sure). I may start a proposal at Wikimedia when I find the time. Anyway, back to the wikiwidgets, I told JohnBlackburne that I can probably move their development to Gerrit, but it would probably be easier to do that if we first implement wikiwidgets in the English Wikipedia, as doing so would add weight to the request to open repositories for them at Gerrit. Do you think that it would be better to move the development of wikiwidgets to Gerrit, or does it seem equally ok to you if it's done via GitHub?

talk

) 15:14, 5 June 2015 (UTC)

I have no preference between Gerrit and GitHub. I am satisfied with any platform that encourages code review. WhatamIdoing (talk) 20:35, 5 June 2015 (UTC)

I would actively oppose a policy that required using a proprietary service to contribute to Wikipedia. LFaraone 05:05, 14 June 2015 (UTC)

• Tenatively support: This would be very useful for all sorts of things. An immediate one that comes to mind is illustrating things in cue sports articles, with a virtual billiards, pool, or snooker table. My security hairs raised immediately too, along with those of others, but your answers so far seem adequate. I'm seeing some "damned if you do, damned if you don't" flawed reasoning in some of the security-related naysaying. We can't simultaneously expect that the ability to inject Javascript into pages must be strictly limited, then complain that it can't be strictly limited because that would impede editors from using this tool. It's perfectly fine to require people to use GitHub if that's what's it takes to do this securely. We do stuff like this all the time, like now all the interwiki stuff is done offsite at Wikidata, and I can't be bothered to figure out how to use it. There are 100,000 other things for me to do on WP, so no overall productivity to the project is lost; some people just become Wikidata-competent and some don't. The move of complex templates to Lua modules is the same; some editors choose to learn enough Lua to deal with it, others work on something else. I also don't buy the "we can't require Javascript" argument; it'd be a simple content guidelines matter to add a line somewhere saying not to build articles in such a way that they can't be understood without JS. This really isn't any different from adding videos and other supplementary material, and frankly WP is already greatly usability-impeded without Javascript, as are almost all modern, complex websites. JS support is just part of how the Web basically works, and has been since the late 1990s.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:33, 28 May 2015 (UTC)

Thanks for the tentative support

talk

) 15:14, 5 June 2015 (UTC)

I don't see any, really.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:29, 5 June 2015 (UTC)

• These examples show that the javascript is used differently to the rest of the javascript on wikipedia. Rather than a tool for editing (or reading) support, the javascript is the content. I think this is important and that this this javascript needs to be treated more like images to video than the rest of javascript (think: moving to commons, systematic approaches to finding display alternatives, etc.).
  Stuartyeates (talk
  ) 03:47, 28 May 2015 (UTC)

talk

) 15:14, 5 June 2015 (UTC)

I tend to concur, though it wouldn't hurt to ask over at Commons and see what the reaction is. These strike me as different and severable issues though. Where it's hosted has little to do with whether en.wiki should use this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:29, 5 June 2015 (UTC)

This sounds interesting, but I don't personally have resources to help out further. However I do want to make three suggestions here with regards to performance:

1. Don't auto-start. As Felipe pointed out, these widgets should only start computing things, creating DOM elements, bind event handlers, make HTTP requests, etc. until after the user has first performed some kind of interaction with the widget.
2. Don't auto-load. In fact, I'd like us to take it a step further and also don't call importScript/importStylesheet until after user interaction. Loading the code and stylesheets is still significant overhead in HTTP requests and consumer bandwidth usage. This means that, in order to eliminate these initial loads, we have to standardise the "start" button (or equivalent) as part of the WikiWidget provider gadget. E.g. a play button or some other simple interface. We don't have to be limited to just a single way to start a widget, but we should provide a finite number of them. This also makes it easier to maintain a consistent user interface since these "entry doors" will be controlled by the same gadget (the WikiWidgets provider).
3. Specify resources. Don't assume there will be a one JS and one CSS file. Instead, let the template declare which ones are expected to exist. Making a needless HTTP request that will only yield a 404 Not Found is a waste of resources.

Thanks for this great idea! --Krinkle (talk) 14:45, 9 June 2015 (UTC)

A discussion (RfC) for introducing a new CSD criterion for drafts that are blatantly unencyclopedic or

• Yes, as proposer Although I like reverse order when reviewing edits and discussions I am participating in, it is sometimes regrettably necessary to file 3RR/ANI/AE complaints to maintain a collaborative environment. Marshaling evidence for those filings is rather tedious, because (at least based on my current wiki skill) I have to manually cut and paste, and then reverse the order of the DIFFS. If there's a better way, please teach me. Otherwise, could we have an option (maybe in preferences, or a button somewhere) to reverse the displayed order?
  NewsAndEventsGuy (talk
  ) 11:55, 15 June 2015 (UTC)
  • ... You could always just start at the end of the history and work your way forwards. Anomie⚔ 12:30, 16 June 2015 (UTC)

    You mean when we arrange

    NewsAndEventsGuy (talk

    ) 12:36, 16 June 2015 (UTC)

    • Apparently I don't know what workflow you're using to obtain these diff lists that isn't involving right-clicking diff link or viewing it in the browser, copying the URL, then pasting and formatting it. Perhaps you should explain it. Anomie⚔ 13:06, 16 June 2015 (UTC)

Good idea. MY WORKFLOW

(A) Grab a block containing the good stuff - I used to go diff-by-diff, then realized it's easier to do a block cut and paste to an external wordprocessor

(B) Reverse the Wordprocessor order - I wrote a macro that does that

(C) Expunge the uninteresting diffs - step through the wikipedia page using the embedded links to decide which to keep and which to chop, and flip back and forth to the wordprocessor list making those changes

(D) Other things that have no bearing on this idea.

(E) Include result (clean diff list marching forward in time) as evidence in ANI/AE/ARB proceedings

If we could tell version and contrib history pages to display their diffs in chronological order, that would eliminate the need for B altogether which is good for editors with no programming skills of any kind, and it would greatly simplify step C, since both the source list and list under development are organized the same way (chronologically). Although I develop my lists off-wiki, the same points hold for those working in their wikipedia sandbox.

NewsAndEventsGuy (talk

) 13:44, 16 June 2015 (UTC)

• Support - we should certainly make things easier for users when possible - and I can clearly see that for some users, this would tend to make more sense. עוד מישהו Od Mishehu 11:48, 16 June 2015 (UTC)

Tvx1 13:51, 16 June 2015 (UTC)

Presently there is major difference with the layout of wikitables on the desktop site and on the mobile site. Most importantly, the mobile wikitable has no background color for its header cells and its border are brightly colored to the point that they are almost indistinguishable. This creates readability issues for the mobile wikitable. To illustrate this I have made a screenshot of table both in the desktop and the mobile version.

A wikitable on the desktop site

The same table on the mobile site

Therefore, I would like to propose the mobile wikitable's layout to be made the same as the desktop wikitable's, so as to have a uniform table style. Tvx1 19:21, 25 April 2015 (UTC)

Discussion (Uniform tables)

• First question: How exactly does this effect our readers and the encyclopedia? Second question: How do you propose to do this? — {{U|Technical 13}} (e • t • c) 22:37, 25 April 2015 (UTC)

Wikitable CSS is defined:

• Screen: mediawiki.legacy/shared.css
• Print: mediawiki.legacy/commonPrint.css
• Mobile: MobileFrontend/less/content/tables.less

-- Gadget850 ^talk 23:36, 25 April 2015 (UTC)

• The mobile site uses a different skin, "Minerva", specifically tailored to mobile devices. I suspect this colour scheme was carefully chosen for a good reason, and I haven't seen a good explanation of why the desktop site's table colour scheme is any better (or worse, for that matter) than the mobile scheme. As such I would oppose any changes. — This, that and the other (talk) 08:02, 27 April 2015 (UTC)

  This ^^^ Also that table uses colored background to communicate information, which is an accessibility problem. And the background of the table won't matter much to readability on my watch. Also why would things have to be visually consistent across multiple skins ? —TheDJ (talk • contribs) 14:41, 27 April 2015 (UTC)

  I can think of many reasons why it's impractical to have multiple layouts for the same tables. I'm not aware of every type of instance tables are used for on Wikipedia, so I can only talk about the one I'm involved with. I mainly edit in the

  here and here. Furthermore having different desktop and mobile layouts creates unnecessary complications for editing. Quite often a change of content in a table on desktop works fine on desktop, but creates problems on mobile. I can't see any good reason either why header cell can't have a background color on mobile. I can't give an answer to Technical 13's second question because I'm not adept enough with the site's programming language, so I simply can't point to which part of the CSS has to be changed nor to what it should be changed to. Tvx

  1 16:28, 27 April 2015 (UTC)

• Oppose any change, that is just the way the mobile site is supposed to look, and it doesn't look any worse (I honestly prefer it). I also think you forget that tables look unique in each different skin, (Similar colourful table in Modern, Cologne Blue, and MonoBook) that is just the way skins work. EoRdE6^{(Come Talk to Me!)} 00:11, 30 April 2015 (UTC)

  Also Vector (for those people who don't have it as default), and Mobile. --Redrose64 (talk) 08:10, 30 April 2015 (UTC)

  EoRdE6, I'm not talking about aesthetics here. I'm talking about accessibility and editing issues caused by the mobile version. The skins you link to only have some minor aesthetic differences which cause no problems with accessibility. Only the mobile version has some fundamental differences to the basic layout which cause these issues. Cell borders are almost indistinguishable, the wikitables have no basic background-color and neither do header cells (!). Also, 2014 Formula One season is not a good example to look at, because those articles' tables have been coded differently by an other editor to make them universal on mobile and desktop. 2013 Formula One season will give you a far better view on just how different those tables are. Tvx1 13:18, 30 April 2015 (UTC)

• So here are the facts that we've determined so far:
  • Every skin looks different.
  • Mobile's headers use bold and centered text, whereas Vector's use bold, centered text and with a gray background. One standard way of describing this difference is that Mobile has a higher contrast/easier readability, especially on very small/lower resolution screens (i.e., old smartphones).
  • Individual tables can be coded to different from the default. (Indeed, most of them are different from the default, because most of them are set to class="wikitable".)
• I'm not really sure that making every skin match every other skin is a good idea. WhatamIdoing (talk) 03:39, 17 May 2015 (UTC)
• I don't see the need for this. They are parts of two different skins, which are different for good reasons although not being part of the design process I do not know the reasons in detail. But changing just one element to make one skin look like another makes no sense, without considering the overall design and how it relates to other skins. Besides the above is a bad example: there are far more problems with the actual table than the underlying CSS/HTML. It looks more like something from a glossy magazine than an encyclopaedia, with all the colours, flags, repetition and bold text.--JohnBlackburne^words_deeds 14:28, 17 May 2015 (UTC)

• Although all skins have their variations, the mobile version is the ONLY one, as I have pointed out earlier, to have fundamental differences to the base style (e.g. header cells, borders) for reasons I don't know. The others just have a different "finish touch" but the BASE style is the same. Not so for the mobile one. So this is a case of making the mobile base style match the numerous other ones, and not of making them all the 100% exact same. I really can't understand how one can genuinely claim that the mobile one has a higher contrast? It's exactly the opposite. Because of the lack of header cell colors and clearly distinguishable borders it has much LESS contrast and as a result much reduced readability. That's why I made this proposal in the first place. If it's not clear, the mobile table is the one on the right in the picture above. Tvx1 16:45, 18 May 2015 (UTC)

Yes, that's a "higher" contrast. Black text on white background is "higher" contrast than black text on a gray background. WhatamIdoing (talk) 21:38, 20 May 2015 (UTC)

You're both right. Mobile has higher contrast for the text, but mobile gridding is pale-gray to the point of almost invisible. Alsee (talk) 08:37, 21 May 2015 (UTC)

And that's what I have trying to point out. Is there any objection to darkening the gridding? Tvx1 21:39, 5 June 2015 (UTC)

Allow me to give another, non-F1, example why I think the mobile setting is worse, because the one I gave so far was maybe not clear enough:

A a group of wikitables in a rally article on the desktop site

The same tables on the mobile site

Again, the mobile tables' outlines are barely visible through the mobile skins border, background-color and header cells' settings. Tvx1 19:21, 13 June 2015 (UTC)

On the log in form, there is a checkbox that says "Keep me logged in (for up to 30 days)". Instead, it should simply say "Keep me logged in", getting rid of the 30-day limit in parentheses, so that it keeps you logged in indefinitely.

I could be wrong, but I believe the way that actually works is that it keeps you logged in for thirty days even if you don't edit during those thirty days, then you get logged out, but if you do edit during that time it keeps you logged in for thirty days from the time of your most recent activity. I'm pretty sure that's how it works as I hardly ever have to log in, usually only if I've done a software update or cleared out cookies or soemthing like that.

talk

) 02:35, 13 June 2015 (UTC)

The log in screen used to keep people logged in for up to six months, but it had to be scaled back to 30 days for legal reasons. Namely, it's against the Terms of Service to use cookies for longer than 30 days, and since it's a cookie that keeps you logged in, they have to expire and log an account out every 30 days. Imzadi 1979 → 06:43, 15 June 2015 (UTC)

This is no longer true. I'm hoping that it will happen soon. Whatamidoing (WMF) (talk) 19:18, 16 June 2015 (UTC)

I do not know how or why this arose, but at present on Wikipedia American English seems to have become "English". British English and Canadian English are labelled as such, but in drop-down menus etc. the option for "English" is in fact American English. I appreciate that there are many millions of American English speakers, but there also many millions of speakers of other varieties of English. The English language has no recognised "standard variety", it has no government-backed defence of language purity like French has, and is unlikely ever to gain one. Wikipedia, therefore, is not reflecting the situation in the real world and is artificially imposing a spurious primacy on American English. From a purely personal view, as a native Englishman, born and living in England, I think my variety of English should be "English", if any variety is. However, what I propose is that the present "English", as a "language option", be replaced by "American English". As a result all major varieties of the English language would be treated in a fully egalitarian manner and a measure of uncertainty be removed. Urselius (talk) 19:31, 13 June 2015 (UTC)

I'm guessing slightly at the context here, but I think you're talking about what you see under special:preferences, in the "Internationalisation" section, in the "Language" drop-down box. Is that correct? If there are any other places this shows up, please clarify.

I agree this is odd. The box has mostly a list of ISO two- and three-letter language codes, but in a few cases narrowed down to a sub-locale. For English there are three locales offered, "en", "en-CA", and "en-GB". I agree that one would certainly expect en-US, and probably others as well, at least en-AU and maybe en-IE, en-NZ, en-SG, en-ZA, en-IN as well.

However I'm not so sure that the "en" locale is really "American English". If that's so, then why do I see the section spelled "Internationalisation" instead of "Internationalization"? Maybe the setting doesn't control that; I admit I haven't tried.

In any case this strikes me as a WP:Village pump (technical) issue. Why don't you try raising it there? If there's actually something that needs to be decided, you could come back. --Trovatore (talk) 19:52, 13 June 2015 (UTC)

"English" appears as an option in the location you mentioned, but also on the "Languages" option on the blue-coloured bar to the left of the text section when editing - for me it appears along with "British English" and "Scots". Whatever variety of English that is produced by clicking on this option, wherever it occurs, it is so ambiguous that it should be deleted in favour of having a selection of more defined options. The existence of a simple "English" option is very misleading. I imagine that many people click on "English" and then find that certain words are either spelt oddly or that some of their text spellings when editing are highlighted as being wrong. I cannot be the only person this has happened to. Given that options such as "British English" and "Canadian English" are available on these menus, that there is a simple "English" option renders the menu unsystematic at best. Perhaps the least confusing way to set out such menus would be in the form "English: American", "English: Canadian" etc. That way anyone looking for 'English' will find all available varieties together. Urselius (talk) 20:16, 13 June 2015 (UTC)

I went ahead and asked for you at Wikipedia:Village pump (technical)/Archive 137#Why no en-US locale in preferences?. I only talked about "preferences" since that was the only one I knew about. You might want to contribute to that discussion. --Trovatore (talk) 20:20, 13 June 2015 (UTC)

Thanks, Urselius (talk) 20:35, 13 June 2015 (UTC)

There is no spelling checker at the English Wikipedia. If what you type is being highlighted as "wrong", then it's your web browser that's doing it. Whatamidoing (WMF) (talk) 19:20, 16 June 2015 (UTC)

I have started a proposal at

Opinions are needed on the following matter:

I have noticed that the pt:Wikipedia can display references in a box with a scroll, as can be seen here, different from ours here. I don't know if this is the right place for a proposal of change, but if not, maybe one of you guys could take it to the proper place or people. That would be quite an interesting move ! Krenakarore ^TK 21:43, 13 June 2015 (UTC)

@Krenakarore: I'm not seeing the scroll box you described at that page, do you have a user preference checked or something which is enabling it? Sam Walton (talk) 22:09, 13 June 2015 (UTC)

What box? what scroll?—

Chat

:Offline 22:14, 13 June 2015 (UTC)

Bingo ! Compactar referências: Permite "barra de rolagem" (Scroll) em referências. So, that would be possible ! Krenakarore ^TK 22:18, 13 June 2015 (UTC)

Found that in Preferências->Gadgets, checked it. It reduced the number of references displayed from 233 to 36, but no way to scroll that I can see. I don't see the point anyway, since it sounds like it would simply replace one scroll action with a different one. ―Mandruss ☎ 22:41, 13 June 2015 (UTC)

However Mandruss, allocated in "Preferences", this gadget would allow users to make use of it or not. Besides, a long list of References would be displayed in a more concentrated form, enhancing the layout quality of this encyclopedia. As for the "but no way to scroll that I can see", I believe this only works when a number of references is reached. Best, Krenakarore ^TK 05:46, 14 June 2015 (UTC)

Sorry, I still fail to see how anything would be enhanced. Without the feature, I can fill my screen with references, assuming the article has enough of them; with it, I would be limited to viewing a fraction of that at a time — in your example Windsor Castle article, apparently only 36 out of 243 — even if it worked, which, as I said, it doesn't for me. I'd call that an anti-feature. Perhaps I'm just blind; please explain how it benefits a reader to have a scrollable part of the references and part of the notes on-screen at the same time, or a scrollable part of the references and part of the bibliography. ―Mandruss ☎ 10:18, 14 June 2015 (UTC)

@Krenakarore: I have changed your heading to something more descriptive than "Suggestion"; I hope you don't mind. ―Mandruss ☎ 10:40, 14 June 2015 (UTC)

Absolutely not Mandruss. Actually, you have just improved the title of the heading, which is the purpose here (better what I do and I'll return the favor). What I meant is that it might save space when we have long "lists" of references in this section, enhancing the appearance of the page (that's my work here, to better the quality of what I see and read). The example on the right shows a box and a scroll. The Notes section is above and Bibliography below, so I think it only works for this section. Nonetheless, if both sections (notes and references) occupy the same sub-section, they might well appear together.

You see, there are many interesting ideas put to the test or in current use in other Wikipedias. Maybe creating gadgets like "justify paragraphs" (which I make use of once I have never seen a book without alignment on the right, and I believe that does improve the quality of Wikipedia), might invite other users like me to edit articles. I really don't know if "Move section [edit] links to the right side of the screen", "Add a clock in the personal toolbar that displays the current time in UTC", or even our VisualEditor might benefit a reader, but in my humble opinion it's an improvement to the project. There will come a day when we users and reader alike will be able to watch holographic images come out of the screen, dance before our eyes in dynamic motion and stimulate our perception and understanding of what is worth seeing, believing, making, creating, thus changing our way to see the world. Krenakarore ^TK 19:57, 14 June 2015 (UTC)

Scrollable references have been discussed in the past (I'm afraid I don't have a quick link to the past discussions); they are discouraged because they can have a number of undesirable effects. Potential issues include:

• Incorrect, mangled, or broken display in some browsers;
• Incompatibilities or difficulties navigating with some accessibility tools (like screen readers for the blind);
• Incorrect or incomplete display of references when printing articles;
• Difficulties in rendering on small, low-resolution, or unusually-sized screens or windows;
• Probably a bunch of subtle but annoying things for editors reading, reviewing, or updating references.

As to justifying paragraphs on Wikipedia, there are good reasons not to do that on the web. Here are the first couple of links that Google throws up: [1], [2]. Essentially, rendering text on the fly, to be displayed on screens of arbitrary size (especially arbitrary width), without careful supervision and tweaking (hyphenation and so forth) tends to make text less readable. It's particularly hard on the dyslexic and the vision impaired. TenOfAllTrades(talk) 02:22, 15 June 2015 (UTC)

Different hearts beat on different strings. When I first came here was to mention the existence of this feature, not to convince others that it is a good idea. Wikipedia has many advantages over other websites, being the main one the possibility to choose between using or not this or that gadget. The title of the link you gave me (much appropriate by the way) is: "Never Justify Type on the Web". So, if justifying paragraphs were mandatory I would be inclined to agree with you, but once it isn't... I guess the same applies to the scrollable references, regardless the browser I were using - I am getting in touch with programmers at their Village Pump to know if there are complaints about the use of this gadget. Many users here are against infoboxes, but it's the very first thing that appear on my mobile ! All in all, if we'd drop every opportunity to experiment, we'd better bury this project after all. Krenakarore ^TK 16:05, 15 June 2015 (UTC)

To be clear, I don't have anything against individual users installing whatever gadgets they want, or opting in to whichever formatting changes they like. But the default display format for Wikipedia articles should be as friendly as possible to as wide a range of readers as possible—and should especially avoid doing things that are apt to make things difficult for readers already facing accessibility challenges. TenOfAllTrades(talk) 22:36, 15 June 2015 (UTC)

I would add that if some group finds a way to display reference lists in a non-default way, fine. But no one is making any commitments to such a group to support their preference. If some citation styles don't work with their special tools, tough luck; the outcome of this discussion shouldn't be viewed as requiring editors to alter any citation style to work with non-standard display tools. Jc3s5h (talk) 22:47, 15 June 2015 (UTC)

Definitely, I agree with you. I got in touch with the people at their Village Pump and they informed me that only a few editors justify paragraphs, me being the last to copy the code from mw:Snippets/Paragraph justification to my common.css today ! They also said that the scroll bar is important once there are articles with more than 100 or 200 references, and such distribution is impractical and extremely anti-aesthetic. Besides, the page about the criteria to create gadgets did not exist shortly before the proposal that resulted in the gadget creation. So, they believe that it's unlikely that a gadget to compress references in the English Wikipedia be created, since the problems it would introduce are enough so it does not pass the criteria for gadgets creation.

You said: "I don't have anything against individual users installing whatever gadgets they want". Could I create this gadget here (compacting references with a scroll bar) the way I did there today by copying that code to my commons.css, and which code would that be ? Krenakarore ^TK 23:21, 15 June 2015 (UTC)

 Done, thank you  !

This (and justification, etc.) are fine as optional gadgets, but shouldn't be pushed as defaults. This is far less trivial (for someone who wants this ref-squishing) than many current gadgets.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:12, 17 June 2015 (UTC)

Question: Would it benefit the project if sanctions other than blocks were noted in such a way that they would appear in an expanded sanctions log, rather like the current block log, but more comprehensive?

• Yes When I am deciding how to handle what I see as problematic behavior I like to check a user's past history with sanctions of all sorts. The block log is handy, but far from comprehensive, and while one can spelunk at ANI/AE/ARB for individual decisions, there's no list that I know of. It would be helpful if there were a simple way to track problem behaviors, because this would help us recognize long standing patterns when we encounter them for the first time with some editor we have just met. That in turn may be useful information to the community/admins/arbs when new complaints are filed. Your thoughts?
  NewsAndEventsGuy (talk
  ) 21:33, 13 June 2015 (UTC)
• Yes but with a different approach To be frank, I don't think something like this will get implemented into the core software. Block logs are for blocks, so if anything there'd be a "ban log" or "sanction log". All we need is an easy way to see if a user is under sanctions, and I've thought about this before. My idea was to have the wikidata item for
  WP:MOREMENU (or something similar) that will link to the corresponding arbcom page when you're viewing a page related to that user. One issue is wikidata is for all projects, where this would only apply to enwiki. So we could have the data here on enwiki we'd just need to be disciplined about the way it is structured in order for a script or bot to be able to parse it. — MusikAnimal ^talk
  21:54, 13 June 2015 (UTC)

I'm glad someone else is thinking about this, but I'm not enough of a wikinerd term of affection to have the slightest idea what you just said. I'll add one thing though.... ideally this would show current sanctions, but any sanctions, regardless of time. My purpose is pattern recognition, so old expired sanctions would still be relevant, maybe.

NewsAndEventsGuy (talk

) 22:04, 13 June 2015 (UTC)

Basically I mean it's probably best we implement this logging system ourselves rather than relying on WMF to add it to Special:Log, particularly since the system of sanctions/bans may be unique to enwiki. — MusikAnimal ^talk 00:33, 14 June 2015 (UTC)

• A way (any centralized location) to track sanctions would be very beneficial if done well, the problem is if it is used inconsistently or vaguely. If it is added, there needs to be a very clear way to determine what is added to the log to prevent certain users from appearing to have no problems due to entries not being added to their sanction log and others from appearing to be very problematic due to entries being added for minor things. It would also be beneficial to expand cases where thing are added to any "official" part of something that could lead to a sanction as long as it is very specific, for example, if someone names me in an ANI case but it is nothing happens, an entry could be added saying AN/I discussion (link) started by ExampleUser and another saying AN/I discussion (link) closed/archived with no support for action instead of just the first message, which could cause some users to believe there was a genuine problem. If there are any more proposals related to this, I ask that someone let me know, I am very interested in this idea. PHANTOMTECH (talk) 23:24, 13 June 2015 (UTC)

One simple way of ensuring consistency is to adopt a simple rule that no sanction can be enforced if it has not been added to (whatever log is created).

NewsAndEventsGuy (talk

) 23:47, 13 June 2015 (UTC)

That would effectively solve the problem of logging sanctions but to prevent people evading the log by agreeing to things like "voluntary" interaction bans when they think an "official" action is coming I think that things like being brought to ANI should be logged. The problem is people will continue to try to evade the system by trying to end the discussion before it gets to a logged event if the events are very specific or will cause over or under logging if the events are too vague, with some logging any discussion on a user's talk page where they provide some resistance and others not logging unless action is taken at ANI. I do think that an effective way of doing this can be found, perhaps quite easily, but want to stress its importance. PHANTOMTECH (talk) 00:04, 14 June 2015 (UTC)

I don't think we should log being brought to ANI, only link to the thread if it resulted in a sanction/ban. It would be up to the closing administrator or arbcom clerk to update the sanction log. — MusikAnimal ^talk 00:28, 14 June 2015 (UTC)

I agree with MusikAnimal; lots of ANIs are spurious, and the named eds are victims, not problems.

NewsAndEventsGuy (talk

) 00:39, 14 June 2015 (UTC)

If we don't log being brought to ANI, it allows genuine problems that simply don't have much support for action at the time to be hidden away. Bad faith ANI reports are a problem, and simply logging something like brought to AN/I for something as complicated as ANI would cause problems which is why logs should be specific, linking to the thread to allow reviewing users to see what actually happened and saying what action, if any, was taken to keep those who don't check from jumping to conclusions. A centralized location for logging only sanctions would be beneficial, but I have a feeling people will rely on it too much which could cause people to underestimate certain problems. PHANTOMTECH (talk) 00:51, 14 June 2015 (UTC)

• Before we even consider logging more things, we need a better way to address bad/erroneous blocks in the log. Current policy is that pretty much no matter how bad the block is, it can never be removed (despite having the technical ability to delete it). Before we start adding more undeleteable content to the logs, we need to find a good way of cleaning bad blocks (and overturned sanctions from this proposal) from the logs of innocent. Ideally this would be done with full transparency, while also removing the blemish from the log on casual glance. I would propose that we allow redaction of block/sanction log entries, either with the consent of both the admin who originally enacted the sanction, and the target of the sanction, or with a clear consensus at a notice board in favor of redaction; we would then create separate, manual log of entries redacted under this process. In the case of the consensus route, the standard should be that the block must have been bad, as a matter of policy, at the time made , and not where it was just decided to unblock later. The log would provide transparency to the process, while removing the bad sanction from immediate view when looking at the editor's log. Monty₈₄₅ 02:16, 14 June 2015 (UTC)

Removed logs could just be hidden from default view with a note attached about why it was removed. This would require a software change for block logs but would solve the issues caused by accidental or bad blocks staying in the block log, would be very transparent and would allow easy restoration in case of accidents. I agree with your idea for conditions where blocks should be removed. PHANTOMTECH (talk) 03:26, 14 June 2015 (UTC)

• Comment: The block log is generated by administrators using a specific tool. It is not a manually created log. Before going any further down this rabbit hole, perhaps someone should find out exactly what would be required in order to log certain decisions. Keep in mind there is a difference between actions (which can be logged), and decisions (which are not logged now, anywhere, for anything, except in manually created data). Thus, it seems to me, there may need to be an additional "button" for "other sanction" or something like that. Who's writing the software? Risker (talk) 03:40, 14 June 2015 (UTC)

There would have to be another button or special page which would have to be used manually each time we wanted something logged since many things we want logged don't have a specific associated action. If it's integrated properly into Wikipedia it will have to be done my a MediaWiki dev, if we decide to throw something together ourselves it can be done using scripts/gadgets or default gadgets with the minimum necessary being a script that allows adding logs and nothing needed for reading them. PHANTOMTECH (talk) 03:48, 14 June 2015 (UTC)

Maybe something involving a manual post to the editor's talk page that produces a filter, sort of like the current DS Alert system?

NewsAndEventsGuy (talk

) 08:45, 14 June 2015 (UTC)

• Oppose: We don't need a new way to shame and judge other editors. The present tools' ease of use is already unforgiving. If someone's being programmatically disruptive there are already enough ways to dig up the past. If admins think it's be useful for admin purposes only, I guess I wouldn't object to that. My main concern is that WP is already full of way, way too many grudges.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:15, 17 June 2015 (UTC)

Reasons:

1. Botching diacritics can be seen as very disrespectful by native speakers;
2. Botching diacritics can be a strong indication that the editor has little or no knowledge/acknoledgement of their functions and/or linguistic/cultural significance;
3. With new generations of computers and tablets becoming more and more available, the "I don't know how to type it" excuse is becoming no longer valid.

Based on the above reasons, I strongly propose that it's time for Wikipedia to completely abolish the "ignore the diacritics" rule (or convention or whatever). Cedric tsan cantonais 19:29, 5 May 2015 (UTC)

Strong support. I strongly agree with the reasons. --Luis150902 (talk | contribs) 18:28, 18 April 2016 (UTC)

What rule is that? Where have you seen it being applied? --Redrose64 (talk) 19:46, 5 May 2015 (UTC)

Presumably the guideline at

WP:DIACRITICS. Whic does not call to "ignore the Diacritics". -- Gadget850 ^talk

20:29, 5 May 2015 (UTC)

It might as well. Though the use of diacritics is "neither encouraged nor discouraged", the fact remains that we're instructed to make that decision off the back of English sources, which have - by and large and for the most part - omitted diacritics, for a variety of reasons.

talk

) 20:38, 5 May 2015 (UTC)

"we're instructed to make that decision" Where? -- Gadget850 ^talk 21:02, 5 May 2015 (UTC)

It's the first sentence of

talk

) 21:13, 5 May 2015 (UTC)

WP:NONENG

). If the common usage in English includes diacritics, that is what's used in the English Wikipedia. If the native language uses diacritics but English doesn't, then neither does the English Wikipedia.

However, the original poster seems to be referring to this diff, in which

WP:NONENG. --Ahecht (TALK
PAGE

) 21:18, 5 May 2015 (UTC)

@Ahecht Thank you. This is the very first convention that I seek to repeal. As for references, I would argue that if we are willing to look at sources in other languages (which, according to my experiences, are equally valid in English Wikipedia), there're plenty of sources indicating the correct use of diacritics. For example, in this news release by the Czech Ice Hockey Association, more than one NHL players, including Petr Průcha, David Krejčí and Zdeno Chára, are mentioned and the diacritics in theirs names. Also, the Czech were nice enough to keep all diacritics in players' names, regardless of the languages they're in. All these are making Wikipedia:Naming conventions (ice hockey), which tries to justify botching diacritics, invalid. Also, if TSN and ESPN are seen as valid sources, the Czech Ice Hockey Association just can't be any less valid. Cedric tsan cantonais 22:01, 5 May 2015 (UTC)

If the problem is specific to Wikipedia:Naming conventions (ice hockey), why discuss it here, not at Wikipedia talk:Naming conventions (ice hockey) (plus an advisory note to WT:WikiProject Ice Hockey). --Redrose64 (talk) 22:54, 5 May 2015 (UTC)

I wouldn't say that non-english sources are "equally valid in English Wikipedia".

WP:NONENG says "However, because this is the English-language Wikipedia, English-language sources are preferred over non-English ones whenever English sources of equal quality and relevance are available." --Ahecht (TALK
PAGE

) 23:23, 5 May 2015 (UTC)

The key words here are whenever English sources of equal quality and relevance are available". In terms of diacritics, I would argue that there are little or no English sources "of equal quality and relevance" available, due to my observation that many English sources, other than English Wikipedia, would already botch the diacritics before making their way into English Wikipedia and, therefore, cannot match the quality and relevance of certain non-English sources. Henceforth, my argument that certain non-English sources, like the news release I posted above, should be deemed equally valid in the case of diacritics.

Also, since my main focus is on Cantonese Wikipedia, I don't edit English Wikipedia as much and that's why I wasn't aware of the existence of Wikipedia:Naming conventions (ice hockey). But now that I know there's this convention, I'll start working on getting the "ignore the diacritics" part amended or abolished.Cedric tsan cantonais 00:08, 6 May 2015 (UTC)

You say "my observation that many English sources... botch the diacritics". You're saying English Sources are "botching" how things are written in English. Even if you're right, Wikipedia is not the place to try to

fix it. We follow the sources, we don't lead. Alsee (talk

) 05:44, 6 May 2015 (UTC)

I'm not "leading". I'm just cherry-picking the best sources to follow. In the case of diacritics, many non-English sources had proven themselves more trust-worthy than their English counterparts. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)

• As one of the parties of the compromise over on the hockey WikiProject, I've got two cents to throw in. The compromise was the truce in a long and contentious edit war involving many editors (myself included) and many articles. No one was really happy with it, and there've been a couple attempts over the years since to overturn it, but it's kept the edit warring down to a dull roar.

  My strong preference was then, and remains, to recognize that this is the English Wikipedia; not the Czech, not the French, not the Swedish or Finnish or Viet or any other national Wikipedia that commonly uses diacritics. The English language does not, for the most part, use diacritical marks. I would be thrilled to see

  WP:DIACRITICS extended project-wide, the hockey articles included. That being said, it's obvious from the guideline itself that private compromises have been enacted -- this MOS section dealing with Ireland-related articles, for one -- and I don't see any horde of editors coming in to force a change to go over any better than it would have on what I see from archives was a long and bitter dispute on those articles. Ravenswing
  01:59, 6 May 2015 (UTC)

• I have the same but opposite opinion as Ravenswing. I think they should be used everywhere because they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other. That being said, what Ravenswing says about it being a compromise is true. Diacritics have been an all out war at times on the wiki and the battle over them has left many people on both sides of the issue blocked and/or banned. As such the hockey project for hockey articles in the absence of a true wiki-wide consensus came to a consensus to damper down the edit warring that was constantly on going. It is a topic I generally recommend editors staying away from and usually counsel people to leave it like you found it in the same vein as ENGVAR. I would note the edit of mine being referenced above goes back farther than 2013, it was just added to that particular page at that point, however, it had been listed elsewhere for years before that. -DJSasso (talk) 13:52, 6 May 2015 (UTC)

• I would be shocked to see
  WP:DIACRITICS extended project-wide since that would be a major sign of collective ignorance. I'm considering adding reference(s) whenever I'm writing diacritics. This is kind of a last-resort measure but now that I know there's such strong opposition towards diacritics, I've got little choice. — Cedric tsan cantonais
  17:36, 6 May 2015 (UTC)

• I think many people would view something like that as being disruptive to make a
  point. Resolute
  20:17, 8 May 2015 (UTC)

• I see no reason to change anything here. I'd say 99.3% of the time diacritics aren't appropriate on the English Wikipedia because they are not in the English alphabet. I'll counter
  Talk:Hillary Rodham Clinton/April 2015 move request#Support. We're not using Hilarė Klėntuon because this is English, in the same light, diacritics don't belong on other names in English. Now, as for the claim that "the "I don't know how to type it" excuse is becoming no longer valid, I'm not buying that either, my English qwerty keyboard still doesn't support those characters without knowing the unicode values for each, and to expect anyone to have a huge chart on the wall or know which character means what is unreasonable. — {{U|Technical 13}} (e • t • c
  ) 04:13, 7 May 2015 (UTC)
  • And that is a strawman, Hilarė Klėntuon or Hillary Clintonová are not her name. If they were, and if they were what she used for her name, then yes they would be completely appropriate. You don't need a huge chart on the wall to know what the characters mean, if you don't know what they mean you ignore them just like you are seeking to do in print. As for typing it, its great that the edit box actually has them included so you don't have to know the unicode values, you just click a link. They aren't in the English Alphabet but they are in the English Orthography. -DJSasso (talk) 13:29, 7 May 2015 (UTC)
  • Have you ever visited any Vietnamese article? You might be nonplussed.
    talk
    ) 13:45, 7 May 2015 (UTC)
  • With all due respect, saying that they (diacritics) are not in the English alphabet only shows that you have nearly zero knowledge of English history. Back in the old days, "one, two, three, four" used to be written as "ān, twā, þrēo, fēowor" — and, still, I don't think anyone can argue that "these are not English words". As for typing, I use a QWERTY keyboard, too, but typing alphabets like áàêęçţčạẇėīōåøœæłțůžĉĝñẽã#€ëýȳÿ are almost as easy as one-two-three (and I don't even need to bring up the special character panel below the edit box). Of course, this took me quite a bit of practise, ḃůţ ħéÿ, ṗřæċťïşẽ ṁąḱęś ṕèřƒēçť! —Cedric tsan cantonais 16:24, 7 May 2015 (UTC)
    • Using that argument suggests that you have a poor knowledge of English history. You do understand, don't you, that however much the English alphabet was different half a thousand years ago, we're editing here on the English Wikipedia, not the Middle English Wikipedia? Your argument is the moral equivalent of claiming that Americans are still subjects of the British Crown, just because they happened to be a few centuries ago. Yogh, thorn, eth, and wynn haven't been in the English language in several centuries, and neither are diacritical marks. Ravenswing 11:43, 8 May 2015 (UTC)
      • New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais
        16:50, 8 May 2015 (UTC)
• Do I get this right,
  diacritical sign in the poor english language? European top footballers like Petr Čech, Tomáš Rosický, Tomáš Ujfaluši, Thomas Müller, Jérôme Boateng, André Schürrle, İlkay Gündoğan and so forth (I just looked up Čech and German) should be dumbed down as well? That would be a great loss. The article should be proper named, the dumbed-down diacritic-less version should be a redirect imho. Grüße vom Sänger ♫ ^(talk
  ) 14:01, 8 May 2015 (UTC)
  • Well, I would say the
    heavy metal umlat is less a problem of language, and more one of trademark. Resolute
    20:17, 8 May 2015 (UTC)

• This debate is ultimately a rehash of one that has long plagued the project. And, as with Ravenswing and DJSasso above, I am one of the editors that helped draft the compromise that brought about a truce in
  WP:HOCKEY's diacritics war. (The short version of the compromise is that NHL and NA team/league articles hide them, while European articles and all player articles show them.) At the time, I was one of the people with the "English Alphabet" mentality, but have subsequently 'switched sides' and favour their use. But from either perspective, and recognizing the overall lack of consensus, I think our compromise does a good job of maintaining order at this point in time. Though it should be noted that times are changing, as diacritical marks are slowly making appearances on NA team hockey jerseys, publications, etc. But that is in its infancy, and I don't see a need to revisit this now. Resolute
  20:17, 8 May 2015 (UTC)
  • I beg to differ, sir/madam. As the means of inputting diacritics became more and more easily accessible, I would argue that now is the time for the pro-diacritic side to at least make a push to popularise diacritics (provided that they're used correctly, of course). And by "making a push", I mean that the pro-diacritic side should initiate conversations in order to make diacritics more and more widely accepted. Also, I think now is the time to amend the rules so when pro-diacritic users open up new articles with diacritics, anti-diacritic users won't be able to mess things around in these new articles and push them back into the Old Régime. Cedric tsan cantonais 18:05, 10 May 2015 (UTC)
    • It is not Wikipedia's place to
      right great wrongs. Nor is it our place to popularize diacritics. I sympathize with your viewpoint, but it will be some time yet before the movement of technology reaches the point where a consensus will form in your favour on Wikipedia. Resolute
      18:08, 10 May 2015 (UTC)
      • In that case, I'll just keep telling others to "stop f*cking around on the pages that I opened", even though it wouldn't be likely for me to open up that many articles on English Wikipedia since Cantonese Wiki Projects remain my priority. — Cedric tsan cantonais 21:34, 10 May 2015 (UTC)
• The issue boils down to
  Stuartyeates (talk
  ) 22:05, 10 May 2015 (UTC)

  With all due respect,

  sir/madam, I prefer Unicode. :P — CÉDRIC TSÄN CANTONAIS

  SAYS NO TO I.P. EDITS! 17:31, 13 May 2015 (UTC)

• It feels weird to have this discussion without User:PBS involved. Also, why isn't this discussion about a general rule over at the talk page for the actual rule? WhatamIdoing (talk) 05:45, 17 May 2015 (UTC)

Thanks for the heads up WhatamIdoing. The title of this section says It's time to abolish the "Ignore the Diacritics" rule everywhere. There is not such rule what rules there are say follow usage in reliable English language sources.

The arguments based on

The sections of the MOS that covers usage within articles (other than the subject of an article) is

The fundamental problem here is exactly the same as spelling in general. If one reads a paragraph that contains an unusual spelling such as color/colour and it is not in ones own dialect it tends to look odd, and editors will wish to change it. This was the driving force behind the creation of the rule about

On the alphabet. When one is at school in the English speaking world the alphabet is the 26 letter of the alphabet song, it does not include "&" or any other character. Accent marks are not introduced to children until they learn a "Foreign" language (this includes words such as cafe/café which if the child notices will be explained ways as a foreign word not yet fully Anglicised), so consequently accent marks are seen by most English speakers as a foreign things (blame it on teachers). Now I know that some English speakers are passionate about using the "correct" accent marks on words but they (both the users and the letters) are often seen as eccentric or pretentious by monglot English speakers, (an example of this comes across on pronunciation as well for words like Porsche#Pronunciation of "Porsche" those who pronounce it the German way are assumed either to own one or want to own one).

Faced with the instability this problem of "it does not look right", the Wikipedia community has several options.

• No guidance at all and a local consensus for each article. This was ruled out for the same reason that
  MOS:ENGVAR
  exists. Article content becomes unstable as people care passionately about this issue and some will edit war over it, so the community needed to issues guidance that reflects a wider community view.
• Guidance that accent marks will never be used.
• Guidance that accent marks will always be used.
• Guidance based on a rule similar to the Economist guideline that those languages which a generally educated person in an English language country ought to know, eg French for the British, Spanish for Americans, (the Economist also includes German and Portuguese).
• Guidance based on English usage. The first advantage of this one is simple to implement and it is less arbitrary than the Economist rule eg why German and not Italian? The second advantage is it produces spellings with "least surprise" for the majority of readers and therefore probably causes the least annoyance. Third it is simple to understand and ties in with the concepts behind "Use commonly recognizable names" (
  WP:V
  .

So while following usage in reliable English language sources does not always produce the "best" results, it has proved a reasonable and sustainable method for settling disputes over the "best" spelling to use for many years, because using sources to prove a point is widely used when trying to reach a consensus in many areas of disagreement in on Wikiepdia talk pages. For example the initiator of this section uses a source to make a point:

"As far as I know,

New York Times, for example, is sticking to café

rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais"

This is how the policy is meant to work and it come naturally into play among experienced Wikipedians because it is so frequently used in debates about titles and content. And user:Cedric tsan cantonais when you wished to show that "café" is an English spelling you turned to an authoritative English language source; you did not use a French source such as here (the first page of who's survey seems to contradict your findings). But your point still stands, as does mine that when we as editors discuss the "correct" usage of "Cafe" and "Café" we turn to reliable English language sources to decide on English language usage, and that is what the policies and guidelines reflect. We may or may not disagree on which spelling we think looks better (is more correct), or whatever, but providing we are editing in good faith, even if we do not agree on those issues, we may well be able to agree on what is most frequently used in English reliable sources (even if we we are surprised by the finding and do not like the result). The guidance only breaks down when someone ignores usage (or plays the system by arguing that only sources that reflect their bias are reliable), because as editors editing in good faith, we can always go back to whatever the original usage was if reliable sources do not give a definitive answer. -- PBS (talk) 11:32, 17 May 2015 (UTC)

My two cents: Most of you are looking at this issue too narrowly. You're thinking of words or names in languages you're familiar with (like French in many of the examples), and think the only problem is diacritics on one or two letters. It isn't! Many other languages have have alphabets that have diverged more from the English (i.e, Latin) one than French did. These other languages have not only diacritics, but also additional or bizarrely modified letters, and worse, letters that look like English but are pronounced differently from their English cousin. The end of this spectrum are languages with completely different character shapes from English (e.g., Hebrew, Greek, Russian) or no alphabet at all (e.g., Chinese). At which point do we stop copying the topic's original native name, and start transliterating it into English? This is why we have an article called "Beijing", not "北京市", and "Pasha" not "paşa", because English speakers cannot read, and do not use, these foreign characters, so those are not useful as article names (but can appear in parantheses in the opening paragraph, of course). And if we do transliterate, it should be into some sort of commonly used English - not some phonetic alphabet. Check out http://en.wikipedia.org/wiki/Talk:Nazareth_Illit, where while everyone agreed that Hebrew names (in Hebrew letters) cannot be the name of English wikipedia articles, there was an argument whether the names of the articles should be some sort of theoretic transliteration nobody is familiar with, or the more commonly accepted simple transliteration into English.

87.69.227.74 (talk) 11:06, 18 May 2015 (UTC)

For those who claim that English uses its own "English alphabet", I have a simple message. There is no such thing as the ”English alphabet". English, like many other European languages, uses the Latin alphabet. It just doesn't use every possible letter available in that alphabet. Because of this convenience I myself, whose native language is Dutch, can read English without having to learn a different alphabet beforehand. And this example counts for any combination of languages which use the Latin alphabet. Russian, just like English, doesn't have its exclusive alphabet either. It uses the Cyrillic alphabet. Using or not using diacritics is not just a question of aesthetics, but actually one of spelling and, more importantly, pronunciation. Writing Petr Cech instead of Petr Čech provokes an entirely different and wrong pronunciation. Therefore we simply cannot ignore these characters. Transliterating should only between languages that use different alphabets or syllabaries (e.g. Kanji to Latin, Cyrillic to Latin,...). This is not the England (or even United States) wikipedia. This is an international encyclopedia, and this one is uses by many users, just like me, don't have English as a native language as well. Just claiming that all English speakers cannot read these "foreign" characters is blatantly ridiculous. We should really accept that millions of none native English speakers read this wikipedia as well. Therefore I support Cedric tsan cantonais's proposal to ditch this censoring of these characters which are even part of our alphabet. Tvx1 17:08, 18 May 2015 (UTC)

I agree with Tvx1's point. But I cannot let the claim 'There is no such thing as the ”English alphabet"' stand. Here is the English alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ. Here is the Polish alphabet: AĄBCĆDEĘFGHIJKLŁMNŃOÓPRSŚTUWYZŹŻ. Both are derived from the classical Latin alphabet ABCDEFGHIKLMNOPQRSTVXYZ. Maproom (talk) 06:14, 22 May 2015 (UTC)

FWIW, no "support" or "oppose" !vote will have much weight here unless a proper

WP:RFC is created. And I wish anyone who attempts it good fortune as I can tell you right now it will end as no consensus. Resolute

17:18, 18 May 2015 (UTC)

@

English Alphabet is derived, but contains its own extensions such as "W", other languages have their own alphabets derived from the Classical Latin Alphabet their own additions or subtractions. Those that are derived from the Classical Latin Alphabet can be amalgamated into what is today called the "Extended Latin Alphabet" (or "Latin Alphabet" for brevity), but whether that concept existed and was commonly used before 1960 and the need for a term in computer science I know not, however a search of Google books for "Extended Latin Alphabet" (About 1,740 results) tellingly returns "Extended Latin Alphabet Character Set for Bibliographic Use" ISO (1975) as the second oldest use of the term with one mention the year before.[5]. -- PBS (talk

) 10:16, 19 May 2015 (UTC)

Boy do I differ with Tvx1 on this one. This is an English based Wikipedia. That's why we have so many different language encyclopedias to choose from. We use English sourcing whenever possible and we use the English alphabet when English sources lead us in that direction. We don't complain when the Serbian Wikipedia does strange things to US spellings nor should they when we do the same. We simply follow the English sources and use what the sources show us. Fyunck(click) (talk) 09:56, 21 May 2015 (UTC)

(Totally OT, why not Fyunch(click)?) --Thnidu (talk) 03:37, 30 May 2015 (UTC)

Oppose further use of diacritics - Fyunck hits the nail squarely on the head. Let's review some basic realities and first principles:

1. This is the English language Wikipedia;
2. The English language Wikipedia is written in English to serve readers who read English;
3. English is the native tongue of the overwhelming majority of English language readers of Wikipedia;
4. The overwhelming majority of native English speakers are completely unfamiliar with the diacritics added to the Latin alphabet in the Croatian, Czech, Danish, Estonian, German, Hungarian, Latvian, Lithuanian, Norwegian, Polish, Serbian, Slovak, Slovene, Turkish, Vietnamese.
5. Only a small percentage of English-speaking specialists learn these languages in American, British or Commonwealth secondary schools and universities. To the extent Americans learn a foreign language in high school or university, the overwhelming majority study Spanish or French. In short, the overwhelming majority of native English speakers cannot read or write a foreign language that makes widespread use of diacritical marks.
6. The standard QWERTY keyboard in use throughout the English-speaking world does not include diacritics, and cannot produce diacritical marks without resort to the alternative ASCII alternative character sets -- which requires not only some understanding of spelling in the particular foreign language, but also knowledge of the ASCII character maps and ASCII character codes.
7. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should identify those differences in the first sentence of the lead of the article.
8. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should create redirects from spellings with diacritical marks to standard English article titles without diacritics.
9. None of this intended as a slight to our international readers whose first language is not English; we love y'all and we appreciate your readership and editorial contributions, but demanding that native English speakers adopt foreign orthography for the English language Wikipedia is a bit over-the-top. One can only imagine the reaction of editors of the German, Hungarian or Serbian Wikipedias if native English writers demanded that those Wikis adopt English spelling and a diacritics-free orthography for articles about American, Australian, British, Canadian, Irish, and New Zealand subjects.
10. Bottom line: Wikipedia should follow the standard majority practices of mainstream publications in the English language when comes to the use of foreign diacritics and orthography. That means omitting the diacritics in the vast majority of cases.

Dirtlawyer1 (talk) 11:39, 21 May 2015 (UTC)

I'm not convinced that diacritics posit any major problem to English speakers. Firstly, technical issues are pretty much non-existent: search engines have got no trouble finding these pages, and we've set up redirects from diacritic-less titles, etc. Secondly, if a speaker of English cannot parse the diacritics, would they not read the text as they normally would? What good does stripping Latin-alphabet names of their diacritics do?

talk

) 12:00, 21 May 2015 (UTC)

Correction, the standard QUERTY keyboard can produce diacritics simply if the correct operating system is used. It has been simple to include many diacritics on the Macintosh since its inceptions and mobile keyboards make it even easier. Not to detract from the argument though, Windows and Linux do not, allow the easy addition of diacritics.

With that said, the remainder of the arguments are sound and one is missing but alluded to in the conclusion: how do the majority of English-language sources present the name? 208.81.212.222 (talk) 18:19, 21 May 2015 (UTC)

Unfortunately, 208.81.212.222/Anonymous, getting "the correct operating system" is not a very convenient operation for a user who needs it. If you ain't got it, you ain't gonna get it with a "command-control-shift-alt-OS"! --Thnidu (talk) 03:53, 30 May 2015 (UTC)

It's not a question of creating problems, although I give up on many tennis player names once too many diacritics start pouring in. It's a question on what is used in English sources and what the title should be. I'm not saying we shouldn't also mention the foreign spelling, of course we should. But for normal everyday usage we should use standard English as sourced from English sources. If that tells us to use résumé instead of resume then that's what we use. If it tells us to use Zurich instead of Zürich then ditto. We let everyone know alternate spellings exist and move on. It even causes problems when trying to copy and paste a tennis player name from wikipedia into huge databases like the International Tennis Federation. Unless you use standard English it comes back as "not found." So I use a "follow the English sources" viewpoint. If there really aren't any English sources then we move out and use other sources at our disposal. But today we are forced, yes forced, to use diacritics in tennis player names, even if 99% of sources do not. Often even if a player has dropped the use of them herself. And we are not allowed to even mention that a standard English version exists in 99% of sources, lest the diacritic police come down on us like thunder. English versions of player names are banished forever per tennis RfC. I don't fight it anymore unless I can prove that a player uses the non-diacritic version on their own websites, facebook and twitter accounts. It just isn't worth it. I don't know what is taught in Canadian or Australian schools, but US schools don't teach them. They only let us know they exist because a few words still use them on occasion. Fyunck(click) (talk) 19:17, 21 May 2015 (UTC)

I just happened upon this because I was on the page for a different query. I do agree with the OP for the reasons given, and because that's what redirects are for. The article title (and text), whether for a person or a place name, etc., should always be spelled with whatever diacritics are used by the person or place, with however many redirects as may be useful to help people find the article. I honestly don't understand why this should be controversial. Milkunderwood (talk) 04:14, 23 May 2015 (UTC)

Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京? That's what your logic proposes, using the original language spelling. The other argument is that we follow the sources. If Reliable Sources say the moon is made out of cheese, then we say the moon is made out of cheese. If the sources are wrong, Wikipedia is not a place to

WP:RIGHTGREATWRONGS. Alsee (talk

) 18:42, 23 May 2015 (UTC)

Expanding my comment, Google Search finds zero hits at the New York Times for "Tomáš Berdych", but 1330 hits for "Tomas Berdych". An argument that the New York Times misspelled something 1330 times isn't an argument that belongs on Wikipedia. A global Google Search for "Tomáš Berdych" -"Tomas Berdych" gives 1.1 million hits, and eight of the top ten hits are English Wikipedia, Croatian Wikipedia, four Czech language hits, and a pair of twitter hits. A global Google Search for "Tomas Berdych" -"Tomáš Berdych" gives 3.2 million hits, and the only one that isn't an English Reliable Source is an instagram hit. Why the heck do we have this article at Tomáš Berdych?? New York Times, Google, and almost all English Language Reliable Sources say that Севасто́поль is spelled Sevastopol in English, and Tomáš Berdych is spelled Tomas Berdych in English. Alsee (talk) 19:43, 23 May 2015 (UTC)

Re: "Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京?" That's an obvious

campaign that's been going on for years by a handful of editors to rid Wikipedia and the rest of the English speaking world of the sinister menace of diacritics.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:27, 24 May 2015 (UTC)

• Comment (on original post and some responses to it): We're already mostly using diacritics where appropriate, and moving more toward doing so, despite years of tendentious
  WP:FORUMSHOPPING. This is a perennial waste of editorial time and energy.  — SMcCandlish ☺ ☏ ¢
   ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:27, 24 May 2015 (UTC)

Your argument is that the New York Times should stop translating Tomáš. Arguments about what the outside world should do, do not belong here. Alsee (talk) 01:58, 27 May 2015 (UTC)

@Alsee: I'll reply to this just so you know where the holes in your arguments are, but I'm collapsing it because they're obvious enough, no one else needs to wade through it.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:56, 28 May 2015 (UTC)

Tomas is not a "translation" of Tomáš, that would be Tomash, but a lazy simplification and disregard for proper pronunciation. Simply ditching important pronunciation marks is just lazy. The 2 dots above my nick change the pronounciation of the "a" from [a] to [ɛ]. These are definitely not the same letters. Grüße vom Sänger ♫ ^(talk) 17:38, 28 May 2015 (UTC)

Actually in US English those two dots mean absolutely nothing (same with the ü and ß. We pronounce things the way teachers or others pronounce things. It's not like we are taught about diacritics.... unless perhaps we take an advanced linguistics course at a university, or maybe we see them when taking a foreign language course. The few English words with them are taught as anomalies or perhaps a fancy way of doing things like when we occasionally see café on signs instead of the normal cafe. We are taught they eventually fade away as they become a hindrance to writing and reading. I don't know what is taught in Canadian, UK or Australian schools so perhaps it's different there? Fyunck(click) (talk) 18:23, 28 May 2015 (UTC)

My sig in proper diacritic-free version should be "Gruesse vom Saenger", as ä=ae, ö=oe and ß=ss (or sometimes sz, but not with the czech pronunciation ;).

There is only one way to proper pronounce a persons names, and that is in the native language of the named person, only with geographic objects there are sometimes real translations that deviate from the "real" one, like München/Munich or Moskow/Moskwa. So you either have to use diacritics, or transscribe it to plain letters with the same english pronunciation, that's or Tomash, not Tomas, or what other solutions do you know to get the proper pronunciation across? --Grüße vom Sänger ♫ ^(talk) 05:44, 29 May 2015 (UTC)

That's your own viewpoint and not backed up by 99% of sourcing. Your name spelling in English is usually what English sources tell us it is, not what you tell us it is. My family name in Polish is Kołodziej, in English it's Kolodziej. We don't spell it with a "w" here. And when older relatives travel back to Poland they may or may not switch back to Kołodziej. English is very versatile in that its letters take on all kinds of sounds without needing diacritics. If someone wants to make a Z sound like a K in English we simply tell people that's how we pronounce it. We don't re-spell it phonetically. However to avoid confusion we would drop the B looking letter and make it ss as with "Johann Strauss." Now of course, Wikipedia can do what it likes by consensus. If enough editors agree it can certainly follow non-English sources rather than English sources. It does that often. But that won't change the English language or how it's taught outside of Wikipedia. Fyunck(click) (talk) 06:13, 29 May 2015 (UTC)

If you move to a foreign country and want to use your name there in the native writing in that land you have to decide for yourself how to do this: Rewrite your name that the pronunciation of the new spelling fits to the right pronunciation or ditch the right pronunciation and keep the spelling. Or even translate if possible to something completely different sounding with the same meaning. I know of an example where two brothers did so in different ways in my home village: The dutch "u" ist pronounced like the german "ü", and their name derived from Holland and includen an "u". One decided to be pronounced with an "u", the other changed his name to an "ü". (I would have a problem with the same letter if I moved to Holland, I had to choose whether tu change the letter to "oe" to keep the proper pronunciation or keep the letter and thus change it.

But that has only tangential relation with this topic here, as here it's about peoples names that still live in that country and thus have only one proper pronunciation and no need to decide anything. It's up to enWP to decide whether to respect their names and proper pronunciations or not. Grüße vom Sänger ♫ ^(talk) 09:22, 29 May 2015 (UTC)

"There is only one way to proper pronounce a persons names, and that is in the native language of the named person" Which is going to be awfully inconvenient for English speakers who are addressing someone whose native language is tonal or click. Contrary to the assertion above, people's names do get translated: consider Wenceslaus I, Duke of Bohemia, known as Václav in Czech. The old Christmas carol isn't wrong for using the English instead of the Czech. People also change the pronunciation of their names. I know two people who have permanently changed the pronunciation of their names (one for the sole purpose of helping people figure out how to spell it), several that use translations of their names (e.g., Diego if you speak Spanish, but James if you speak English), and two that choose a different pronunciation depending upon the language. It's impossible to say that "there is only one proper way to pronounce a person's name" when the person is using three different pronunciations himself. WhatamIdoing (talk) 09:40, 29 May 2015 (UTC)

So what if some people translate their names in foreign languages? Many many more don't. And for those who don't we can only use the native spelling, unless their native writing system is different to our Latin writing (e.g. Cyrillic, Katakana, ...). In such a case we cannot avoid using a transliteration. And for people who did translate their names, we could use such a translation if it is backed by a reliable source. Tvx1 18:30, 30 May 2015 (UTC)

• Oppose further use of diacritics as per Dirtlawyer1 and Fyunck(click). I've responded to people above, but this is my base-level response to the original question. The original question and other commenters asserting that the majority of English Language Reliable Sources are "botching" the English Language is not a valid argument to make on Wikipedia. We should follow general English language practice of English language Reliable Sources. Diacritics (usually) do not belong in English language article titles and prose. Alsee (talk) 05:38, 29 May 2015 (UTC)

• REDIRECTs !! I have a strong preference for keeping diacritics per the original language in proper names, but I recognize that not everyone shares it. I propose that for pages whose titles include names in the Latin alphabet
  1. Ideally, the title of an article should use the proper diacritization of the name, per the original language.
  2. But if it doesn't— and there may be good reasons, e.g.,
     Hồ Chí Minh
     ).
  3. Partial diacritizations should also work, though not necessarily via a full redirect. This seems to be already covered, at least in part: typing Antonin Dvořák (with a plain "i") in the search box brings up three possibilities: Antonín Dvořák , Antonín Dvořák Theatre, and Antonín Dvořák Museum, all properly diacritized with "í".

--Thnidu (talk) 03:37, 30 May 2015 (UTC)

• Comment. What would be the next step ? A re-ignition of "The Dakota" war since Dakȟóta would be so more diacritic ? Pldx1 (talk) 10:04, 30 May 2015 (UTC)
• Comment. We should follow the kind of references a professional copy editor might consult.
  the guideline for geographic place names. This guideline looks like it was modeled on the recommendations given in the CMOS. Too hip to be cool (talk) 23:48, 30 May 2015 (UTC) Wikipedia:Sockpuppet investigations/Kauffner
• Comment. Excuse me for butting in on a subject I know nothing about (and care even less) but this page is now on my watchlist and I have a question. User:Cedric tsan cantonais claimed that diacritics were used in English in "the old days", presumably meaning Old English judging by the examples he gives. So how is it that I can see the diacritics in Wikisource's text of Beowulf, but they are entirely absent from the original manuscript? Perhaps the diacritics are just a modern affectation to aid pronunciation and were never really part of the language. SpinningSpark 19:52, 30 May 2015 (UTC)

  See Old_English#Orthography. Accoring to that, some 'runic' letters and a few diacritics were used in OE manuscripts, but modern transcriptions have added diacritics to preserve distinctions in sound that would have been clear to a reader of the day, but not to a modern reader. DES ^(talk) 20:40, 30 May 2015 (UTC)

  So the short answer is no, "one, two, three, four" were not written as "ān, twā, þrēo, fēowor" in the old days, at least not usually. SpinningSpark 00:27, 31 May 2015 (UTC)

  This is a fair query. From what I understand, Latin didn't really have them, or old Germanic. The better question would be why did many other languages decide to add them while English didn't? Specifically the romance languages. I don't think anyone knows why English or Anglo-Saxon didn't jump on the bandwagon when other languages started added them. Fyunck(click) (talk) 05:52, 31 May 2015 (UTC)

• Comment - the editors inputting on the
  WP:DIACRITICS wording reflects an anachronism in conflict with consensus across 100,000s of articles which consistently use diacritics - except for one blonde tennis player who was moved in a RM including a previous incarnation of community-banned sockmaster Wikipedia:Sockpuppet investigations/Kauffner‎ above - and it is that consistent MOS across 100,000s of articles, confirmed in RFC after RFC, which represents the editor reality of the encyclopedia not a guideline with (still amazingly) local consensus defenders some of whom just don't like the way modern hardback English full font books, and/or en.wp article corpus are. In ictu oculi (talk
  ) 22:33, 2 June 2015 (UTC)
• Comment, bordering on Support: I know this isn't the place to debate this, but since the same goofy things keep being said, I can't help making a few points:
  • To the people who keep saying "English has 26 letters and no diacritics": you're wrong. I'm a native speaker of English, and the language I use includes diacritics. I write "Susie Hawkins, née Butler". I write "à la peanut butter sandwiches". I'm not saying you're wrong for not using the diacritics, but by the same token, you can't say I'm wrong for using them.
  • The
    New York Times writes "naïve". The New Yorker
    writes "coöperate". You may find these to be affected usages typical of liberal northeast media that you may not care to read, but they're mainstream American media, so you really can't argue with them, either.
  • McDonald's, which is about as mainstream American as you can get, writes McCafé. (And you can get a Frappé there, whatever that is.)
  • [almost forgot] Noël Coward.
  • Support for diacriticful typography is incredibly widespread.
    7-bit ASCII
    is long gone.
  • People who don't know how to type diacritics when editing Wikipedia articles don't have to. Someone else will come along and fix them later.
  • People who don't like diacritics don't have to enter them, either. Someone else will come along and fix them later.
  • When reading, people who don't like diacritics can just ignore them. (If we can survive color/colour -- and we have to -- we should be able to survive this.)
  • The hockey article compromise (or the tennis article compromise, or whatever you want to call it) is a terrible crock.
  • The WP:MOS language on the matter is fine. The only problem is some number of strangely parochial (or downright xenophobic) editors who see red when they see diacritics and go around looking for excuses to remove them. (But the existence of the hockey/tennis compromise shows that, whether I like it or not, the number and/or vociferousness of those editors is evidently not small.) —Steve Summit (talk) 23:25, 10 June 2015 (UTC), updated 18:19, 11 June 2015 (UTC)

    The hockey compromise is really just a victim of the changing times on the wiki. It was very progressive when it was created. All over the wiki diacritics were being removed right left and centre. And notedly were also added in some. But it was the only place where there was anything in place to push for using them. It was then used by many other topics to argue for using them elsewhere on the wiki. So it seems antiquated now because it calls for not using them in one area, but really it was created with a progressive mindset in 2007 when there was a real war going on between the two sides on whether or not to use them on the wiki. The hockey compromise would be removed in a heartbeat if we had a new RfC that indicated that the wiki consensus had shifted to support using them since the last wiki-wide RfC finished 50-50 almost to the person a couple years ago on using them or banning them. -DJSasso (talk) 18:03, 11 June 2015 (UTC)

    Thanks for that perspective. —Steve Summit (talk) 18:19, 11 June 2015 (UTC)

    Someone please launch that RfC. I've done too many lately.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:33, 17 June 2015 (UTC)

• Stuartyeates (talk
  ) 21:17, 11 June 2015 (UTC)