Wikipedia talk:Manual of Style/Archive 183

Archive 180

Archive 181

Archive 182

Archive 183

Archive 184

Archive 185

→

Archive 190

Use curly apostrophes and quotes

I think Wikipedia should follow using curly/smart quotation marks and apostrophes. Possibly in VisualEditor would convert to smart/curly ones ("Text" would convert to “Text” automatically, and for apostrophes, it will convert from 'Text' to ‘Text’ (“smart” quotation marks and “smart” apostrophes). I think straight/dumb quotes and apostrophes look so weird, so curly/smart ones would be better. Also in WP a bot would convert straight to curly quotes. If you use VE, if you type ' and " whey will be converted to smart ones automatically. Thanks. 46.130.146.196 (talk) 16:08, 3 September 2016 (UTC)

that you think straight QMs and As "look so weird" is hardly a sufficient counter to the arguments given for the use of straight marks. (And I think straight marks look fine, particularly in the small-size san serif font that's the default here.) Jeh (talk) 16:21, 3 September 2016 (UTC)

Be nice. I think curlies look better too, but I know enough to know that ship sailed long ago. The OP has no way of knowing that. EEng 16:31, 3 September 2016 (UTC)

My ship sailed long ago too. Randy Kryn 19:02, 3 September, 2016

Dang, Randy... and I thought I was old! (j/k) Jeh (talk) 06:41, 4 September 2016 (UTC)

This was proposed (by me) only a few months ago and rejected. We probably shouldn't re-open this discussion more than once every year or two (maybe even longer) without a major new rationale, or it's going to be seen as tendentious lobbying. Basically, this is going to happen eventually, when all the technical problems with it are resolved, but not sooner.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:07, 4 September 2016 (UTC)

The technical impediment, and approaches to it

If I recall correctly, the issue is that in-page text searching in some browsers treats the string “foo” and the string "foo" as different. While this is desirable in a text editor used by coders, it probably is not when reading an article.

I would suggest that the way to expedite resolution of this issue would be to (perhaps with the help of others) identify what browsers have this problem, track down how to file bug reports against each affected browser at the various companies/projects that make them, and set up a page (here or elsewhere) tracking progress on getting this resolved by the various browser makers. These things can actually be resolved with such pressure. About a year ago, I got a contradiction between the W3C HTML5 Specification and the HTML/CSS Cheatsheet corrected, and have since reported the correction to WHATWG so they can correct their own HTML5 Living Standard (which is based on the Cheatsheet not the full Specification, and last I looked has not been updated yet on the matter in question, the use of the <cite>...</cite> element).

Failing that, I wonder whether Mediawiki-embedded Javascript could actually deal with this and other problems, by intercepting calls to the page-search feature and munging the data before it is submitted. I'm skeptical this approach is feasible, since the search feature is not part of the Document Object Model. But then again JS can be used to do other [mostly obnoxious] interface things like remove the tool bars and navigation buttons. So, it might be worth looking into.

Anyway, the point is, just demanding the change periodically isn't going to make it happen; fixing or working around the problems that prevent the change is what has to be done, if they're not just going to evolve away by themselves over time with increased browser consistency.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:07, 4 September 2016 (UTC)

A technically similar problem: copy-paste (or lack thereof) of CSS-generated material

We have similar problems with the copy-pasteability of lists; many browsers drop the numbers/bullets, and I worked up a technical solution for this problem, at Category:Copy-pasteable list templates, but it is not often used because its a set of templates, not the built-in list formatting wikicode.

This limitation is also true of other CSS-generated characters like quotation marks auto-provided by the <q>...</q> element. If it weren't "broken", we should be using this for inline quotations, and MOS should be recommending it. But the current behavior here is very undesirable: <q>This is a quotation.</q> gives: This is a quotation. In Opera on OS X, as just one test, the auto-generated quotation marks cannot be copy-pasted, and this really terrible for WP:REUSE. We can fix that one copy-paste problem by not having the element generate any quotation characters and require that those be done manually the way we already do them. This will require a change at MediaWiki:Common.css, then a bot that hunts down instances of <q>...</q> and replaces them with "<q>...</q>" if they do not already have quotation marks around them, or are not using inline CSS to provide non-English quotation marks for some special case where we're illustrating those (it would be best to replace such cases with Unicode characters for the guillemets or whatever, and not try to use the <q> element for that).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:07, 4 September 2016 (UTC)

Why not just "%" across all pages?

In the section on numbers, it says "Write 3%, three percent, or three per cent..." Why don't we use "%" by default? There are three good reasons: (1) It's a simple symbol that is recognized easily and globally. (2) It saves 6 (!) characters. (3) It solves the dilemma of having to choose between "percent" and "per cent". Since Wikipedia is all about finding common ground, I think that adopting "%" is an obvious case. Let me know if you support this. If not, I would love to hear reasons against "%" by default. EngvarB consistency (talk) 19:40, 2 September 2016 (UTC)

Because consistency isn't everything, and unless there's evidence MOS needs a rule on something, then it needs to not have a rule on that thing, because it's huge and clumsy enough as it is. Is there any evidence editors are wasting time arguing over this? (Saving characters is, of course, an absurd argument, except maybe in infoboxes and tables, where the guideline encourages use of % already.) EEng 20:07, 2 September 2016 (UTC)

But there is a rule already, it says: "Write 3%, three percent, or three per cent." What I'm saying is that it could just be "Write 3%". I have seen many articles with a "percent" here and a "per cent" there, and a "%" in between. It's less distracting for readers if there is one uniform style. That's the whole point of a Manual of Style. EngvarB consistency (talk) 20:58, 2 September 2016 (UTC)

For the same reason that we don't have the 'rule' say just "Write three percent". We don't force a style preference when there are multiple equally valid alternatives. The consistency issue is a different problem, and one for which we already have guidance. The opening section of Manual of Style states Style and formatting should be consistent within an article, though not necessarily throughout Wikipedia. Where more than one style is acceptable under the Manual of Style, editors should not change an article from one of those styles to another without a good reason. Edit warring over optional styles is unacceptable.[b] If discussion cannot determine which style to use in an article, defer to the style used by the first major contributor. If a style or similar debate becomes intractable, see if a rewrite can render the issue irrelevant. You can change articles with a "percent" here and a "per cent" there, and a "%" in between to use a consistent format without needing any more 'rules' than we already have. --RexxS (talk) 21:30, 2 September 2016 (UTC)

I think many would agree that the encyclopedia would be better if we settled on one choice or another (for this and many issues), but it would likely be impossible to settle on which choice that should be. We have accepted the compromise that individual articles should be consistent even if Wikipedia is not.  SchreiberBike | ⌨  21:45, 2 September 2016 (UTC)

Thanks for the answers. It makes more sense to me now. So the general rule is: always consistency within articles, in some cases across articles. I'm a bit surprised though that (if I understand the manual correctly) the default for quotations is "logical style", not typographical. I would have thought that quotation style would be a much more controversial issue to be standardized than for example "%"... EngvarB consistency (talk) 22:43, 2 September 2016 (UTC)

It was, trust me. EEng 22:46, 2 September 2016 (UTC)

The "3 percent" or "3 per cent" style, like "three%", is a sloppy mix-and-match of numeric versus spelled-out styles (cf. "a 3 cm worm", or a "three-cenitmeter worm" or "three-centimetre worm"). The divergent spellings per permitted per WP:ENGVAR; it's somewhat conventional though not universal to use per cent in British and some other forms of Commonwealth English dialects (I don't recall seeing it in Canada when I lived there, though).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:50, 3 September 2016 (UTC)

We can often go either way in Canada. See, eg, this directive for federal government translators, though I couldn't say with confidence that the "two-word spelling is more common in Canada" as it does. Graham (talk) 22:19, 3 September 2016 (UTC)

General rule of thumb with Canadian English: We can usually go either way with most spelling differences – we're too polite to correct anyone. Graham (talk) 22:23, 3 September 2016 (UTC)

Right! The hilarious book How to Be a Canadian has a whole chapter on all the ways to say "I'm sorry".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:49, 4 September 2016 (UTC)

5.9 Ampersand

There are a couple of cases listed in the main article on ampersand which are not mentioned in MOS:AMP

° In film credits for stories, screenplays, etc., & indicates a closer collaboration than and. The ampersand is used by the Writers Guild of America to denote two writers collaborating on a specific script, rather than one writer rewriting another's work. In screenplays, two authors joined with & collaborated on the script, while two authors joined with and worked on the script at different times and may not have consulted each other at all. In the latter case, they both contributed enough significant material to the screenplay to receive credit but did not work together.

° The ampersand can be used to indicate that the "and" in a listed item is a part of the item's name and not a separator (e.g. "Rock, pop, rhythm & blues, and hip hop").

I could be WP:BOLD and just add them in, but I wasn't sure if this applied to policies (as opposed to general articles). Almonaster (talk) 03:13, 31 August 2016 (UTC)

Thanks for asking. Yes, bold (but careful and thoughtful) editing even of policies and guidelines is OK; just don't be miffed if someone disagrees, reverts, and wants to see it discussed more first. It wouldn't hurt to pause and see if you get more reactions here though. Dicklyon (talk) 04:10, 31 August 2016 (UTC)

@Almonaster: I would be surprised if such a change went uncontested. I for one might question whether such fine distinctions, meaningful to perhaps one percent of readers, would be worth the increase in complexity and decrease in consistency, which are often overlooked or dismissed. ―Mandruss ☎ 04:45, 31 August 2016 (UTC)

Paragraph 2 of the introduction says: "Any new content added to the body of this page should directly address a style issue that has occurred in a significant number of instances."

—Wavelength (talk) 05:15, 31 August 2016 (UTC)

I agree about adding complexity and overly subtle distinctions, and that it's only worth making changes that actually address a significant problem. Now if only that approach had been taken re hyphens and dashes. N-HH talk/edits 11:29, 31 August 2016 (UTC)

I will readily concede that the R&B case can be dropped - if it arises then an editor would probably be aware of it and find a solution.

The film credits case, I think is more serious, particularly because it is not readily apparent unlesss you are familiar with the distinction. Would it be a "significant" problem when an editor who is unaware of this inadvertently changes the meaning of an article by blindly applying consistency rules?

Almonaster (talk) 22:36, 31 August 2016 (UTC)

Wikipedia uses semicolons for such distinctions, as described at MOS:SEMICOLON.

° Semicolons are used in addition to commas to separate items in a listing, when commas alone would result in confusion.

Confusing:	Sales offices are located in Boston, Massachusetts, San Francisco, California, Singapore, and Millbank, London, England.
Clear:	Sales offices are located in Boston, Massachusetts; San Francisco, California; Singapore; and Millbank, London, England.

—Wavelength (talk) 15:55, 31 August 2016 (UTC)

I was aware of that use of semicolons, but I fail to see how it assists in either of the two cases I was concerned about. Almonaster (talk) 22:36, 31 August 2016 (UTC)

"Rock; pop; rhythm and blues; and hip hop". Does that help you see? --RexxS (talk) 23:20, 31 August 2016 (UTC)

Yes, thanks. It seems unnatural to me, but it is a valid solution, and I would agree there is no need to change things just for this.

Do you have any suggestions for the accreditation case (see my reply to others above)?Almonaster (talk) 01:35, 1 September 2016 (UTC)

Do you have any suggestions for the accreditation case - Give us a real-life case, and we might have suggestions. Per Wavelength's first comment, we shouldn't add guidelines to address problems that haven't been demonstrated to a significant degree in actual article content. The dismissive/glib term (which I dislike) is "a solution in search of a problem". ―Mandruss ☎ 02:25, 1 September 2016 (UTC)

Serial comma works for me: "Rock, pop, rhythm and blues, and hip hop". All the best: Rich Farmbrough, 17:16, 1 September 2016 (UTC).

Agreed that will work for genres.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:58, 4 September 2016 (UTC)

Stick with the semicolon usage in infoboxes, and use "and" in running prose. If the collaboration was especially close, or someone rewrote someone else's script, these are facts WP would tell readers in plain English, not cagily hint at with typographic tricks almost no one would notice or understand. Wikipedia is not film credits, and is not written in the style of film credits. We shouldn't add such extremely topical nitpicks, since every other field may have different and conflicting "oh so special" uses for ampersands or whatever; see WP:SSF for an detailed explanation of why. We cannot account for them all since they conflict, and we should not try to, per WP:CREEP, since there could be hundreds of them for "&" alone. It's more important that WP be written consistently for a general audience that try to exactly parrot a specialist usage that is meaningless to anyone but specialists steeped in it. Attempts to do things like this very frequently erupt into protracted, productivity-sucking battlegrounds; there have been many of these, including attempts to capitalize the vernacular names of species of certain things (and then of all organisms) because journals in a few fields like to do it that way; many years of insistence on using a comma before "Jr." or "Sr." as the "only" "American" way to do it, when sources did not support such a notion after around the late 1980s; still-ongoing squabbles over pop-music orthography (& vs. "and", and "The" vs. "the" in names like "George Thorogood [and|&] [the|The] Destroyers"; capitalization of short prepositions and even "a", "and", etc., in song titles); and a zillion others. If it's not the way something from Oxford University Press or the University of California Press or some other major, high-end nonfiction publisher would do it, in a work for a general audience, it's probably a poor idea on Wikipedia. PS: Even for "close collaborations" that are notable and have articles as collaborations, we already almost entirely use "and" not "&" and this seems to be well-accepted and stable; e.g. Gilbert and Sullivan, Currier and Ives, and many, many others. There are a few "&" holdouts, like Simon & Garfunkel, and Crosby, Stills, Nash & Young, but these could be normalized via WP:RM. The problem with retaining them is they inspire more "&" everywhere; people will mistake it for "the Wikipedia style", exactly the problem that lead to trying to capitalize all species common names, and the current problem of people converting block quotations into decorative quote boxes (see RfC above).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:49, 1 September 2016 (UTC)

I quite often change "&" to "and", probably on a daily basis, and certainly prefer the "and". Yet I've never changed, nor think we should, a real world name of something which already includes the "&" (Dungeons & Dragons, Crosby, Stills, Nash & Young & such). That was, and still is, the problem found in the Jr. comma debates - since Wikipedia is an encyclopedia, and not a press or style guide, it should reflect the name rather than change it for style purposes. I would love to see all the "&"'s be gone, but not when they are part of an actual name of a film, group, song, or ice cream bar. As for Simon &and Garfunkel (I prefer Garfunkel and Oates), two of their studio album covers, Bridge over Troubled Water and Parsley, Sage, Rosemary and Thyme, contain "and", as do most of their collection including Simon and Garfunkel's Greatest Hits. Randy Kryn 23:08, 1 September 2016 (UTC)

Then we should definitely change that one to Simon and Garfunkel; per MOS:TM we don't retain a marketing stylization unless it's used consistently by the subject and by the RS (e.g. M&M's, where we also retain the questionable apostrophe since it's in the official name and virtually all RS retain it, unlike the ! in Pink (singer)'s P!nk logo or the caps in Sony's SONY logo. Dungeons & Dragons is a different case; we don't change & in the title of published works (and pretty much no one else does, off-WP, either). For bands, people are going to argue about this until the end of time. Bands are very often self-inconsistent, either generally, after a label change, or whatever. E.g. Siouxsie and the Banshees is spelled at least four different ways (and The, & the, & The on their albums, and not at all consistent in sources. While a few are consistent on albums, even in exact logos sometimes, they usually are not in sources, but are more consistent in RS than bands that aren't self-consistent. For my own playlists, I use & The as a convention consistently, just to distinguish cases that are not of the form "Name & The Somethings" but are phrases that happen to have "and the" in them, like "The Earth and the Starry Sky" or whatever. Then you have character substitution complications like Florence + The Machine (or is it + the?) It's headache inducing. I would rather we settled on exact thing, and used the standard "stylized as" parenthetical. It makes it easier for editors, for reader who figure out we have a standard a approach after seeing a few band articles, reflects actual sources usage (some do use the stylization, some don't), obeys MOS:TM (since some don't, default to non-stylized), yet preserves the official name in the lead sentence. An all-win situation. It's just a matter of what to standardized on. I think the most WP-consistent would be and the. Could also apply this by default (don't we already) to company names, again with MOS:TM exception that if almost all the sources consistently "honor" and & or + or whatever, we should too. The one thing we don't do is just say "WP:OFFICIALNAME always wins; the whole point of that page is that it's often a lower-rung concern at all.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:45, 3 September 2016 (UTC)

After looking further at the album and single covers and names, Simon and/or/& Garfunkel would be an obvious candidate for a name change. I think after that the question would again fall back on the names of Wikipedia articles on their compilation albums, which are inconsistent (and where editors like myself would want to retain the '&' on the pages which feature album covers which were published with it). Even the concert in Central Park album contains 'and' instead of '&', and overall it seems neither of the principals cared very much which way the name went. Randy Kryn 11:24, 4 September 2016 (UTC)

Yeah, the album names should retain "&" if published that way (and not republished with "and"). There are some cases (can't name them off top of head, but remember that they're in my playlist) where a song and its album share the same name except for an "&" versus "and" difference. Bands seem to like to do this "clever" stuff, e.g. Tool's "Ænema" and Ænima.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:56, 4 September 2016 (UTC)

Double spaces after period?

I have recently been removing double spaces after periods on various articles and than another editor came to my page and told me that it wasn't a good idea. I have never seen or heard about the use of "double spaces" in this day of age, and most of Google agrees with me, since when you search up "Should you put two spaces after a period?", most of the search results are against double spaces. The article Sentence spacing also says that "The desired or correct sentence spacing is often debated but many sources now say additional space is not necessary or desirable." I'd just like to get everyone's opinion, thanks. Hawkeye75 (talk) 06:22, 4 September 2016 (UTC)

Please don't edit to remove double spaces. All you do is make their defenders (I'm one, for full disclosure) angry, without actually making any visible change whatsoever to the rendered page. HTML already collapses multiple spaces, unless you use a "hard space" (for example,  ). I wish it didn't, but it does, so your edits don't make any difference except when viewing the source. --Trovatore (talk) 06:26, 4 September 2016 (UTC)

See no one explained to me that HTML removes double spaces automatically... I always use visual editing, so now I understand that it doesn't translate to the actual article. Hawkeye75 (talk) 06:30, 4 September 2016 (UTC)

Excuse me, but I absolutely did explain that in my first comment to you on this subject. I said that those edits of yours "do not affect the rendered text", and I also gave you an example to look at: "For example, the previous sentence has two spaces after it, while this one has just one. You'll notice that they render the same". (And they did, and do.) I also wrote there (again, in my original cmt to you) "While such edits do not affect the text seen by the reader..." (emph. added). I'm not sure how I could have been more clear. Jeh (talk) 06:38, 4 September 2016 (UTC)

A space takes one byte, so removing extra spaces reduces an article's size, and then it loads quicker. The benefits are more easily recognized when loading large articles. Because the extra space isn't rendered, as mentioned above, I'm not sure why people advocate its use within Wikipedia: All it does it take up more server space, unless I'm grossly mistaken. When push comes to shove, Hawkeye75, AutoWikiBrowser will be the tool to use to remove them all. Fdssdf (talk) 06:53, 4 September 2016 (UTC)

Correct imho. Not a huge difference, but they're a waste of bandwidth and server space. Just eliminate them. Using regex on AWB would be fairly easy. EvergreenFir (talk) 06:57, 4 September 2016 (UTC)

No, not correct, and Fdssdf is indeed "grossly mistaken". Anyone who thinks this has anything to do with performance, "server space", or anything else has no idea at all how any of this works. Stop tinkering and do something to actually contribute. EEng 07:11, 4 September 2016 (UTC)

The extra space is a contributing factor only to performance, even if negligibly. I'm not mistaken about that, even though you seemed to suggest it of I and EvergreenFir. The separate matter is whether they're worth addressing with AWB: A negligible existence is a negligible absence. Fdssdf (talk) 16:27, 4 September 2016 (UTC)

Oh, please. The extra spaces won't make a noticeable difference in page load time because a) they are not sent to the client's web browser anyway. The renderer converts the wikitext to HTML and excludes them in that step (you can verify this with the "view source" feature of your browser). And b) disk read time and rendering time at the server is far from the limiting factor in "page load time". Re disk space, removing them, in most cases I've seen, takes far more server space (for the entry in the edit history) than the removed spaces used up! The reason many people (including myself) like them is the same reason they're commonly used and even recommended in typescript: they make sentence boundaries in the edit window easier to see.

And re AWB, please see WP:AutoWikiBrowser#Rules_of_use, rule 4. You're not supposed to do that. Jeh (talk) 07:25, 4 September 2016 (UTC)

It's a pity there's no way of enforcing Rule 4. I checked my overnight watchlist changes and about a quarter of the edits were of the same level of pointlessness – adding/removing spaces, capitalizing wikilinked text, re-ordering template parameters, etc. More important than server resources, this wastes editor time. Peter coxhead (talk) 07:44, 4 September 2016 (UTC)

Oh, there are ways to enforce it. You suggest to the editor that they stop, pointing out rule 4; if they persist, try again; if they still persist, follow the complaint chain. AWB privileges have been revoked before. Jeh (talk) 10:06, 4 September 2016 (UTC)

Do be aware, though, that these minor changes are permitted as "ride-along" changes if something substantive is done in the same edit. The majority of time I see these minor changes being made by AWB, it's along with some actual correction that affects visible output. Just saying, beware filing a false report of abuse; it would probably be received like any other false accusation at another noticeboard.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:22, 4 September 2016 (UTC)

• Oppose. This is perennial "I wanna force everyone to code the way I do for subjective trivia reasons" rehash, repeatedly rejected. The double-spacing of sentences in wikicode makes the code easier to read, and has no effect on the rendered output. People are not (except perhaps under the rarest of circumstances) reading WP over 300-baud modems, so a few bytes of space characters would be totally irrelevant even on a regular webserver. But, as noted above, the MediaWiki parser strips them before it sends the page out, anyway. The MediaWiki and WMF developers have repeatedly told us that we never need consider server performance (software or hardware) for tiny matters like this. The things that matter in that respect are much more serious (details elided, per WP:BEANS). What is it with the sudden rash of "let's do misguided things to MoS" showing up all in a row?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:22, 4 September 2016 (UTC)

• Oppose actively removing of harmless double spaces. Any supposed (and un-provable) benefit has been more than offset by the space consumed by just this one discussion. Making changes with no effect just adds clutter to the change log, making the job of people reviewing changes harder. It has measurable detriments with zero measurable benefit. Let's not waste any more time on this. --A D Monroe III (talk) 16:50, 4 September 2016 (UTC)

Additional input needed to resolve RfC

FYI

 – Pointer to relevant discussion elsewhere

The MOS:COMPASS RfC at Talk:Eritrea#Location has turned circular and unresolveable, with about half a dozen parties sticking to their positions immovably no matter what is offered. I would suggest that an influx of fresh eyes on the matter would be of great benefit before it gets any more WP:LAME.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:38, 5 September 2016 (UTC)

It's certainly unfortunate any time a discussion re COMPASS starts wandering in circles. Maybe some fresh eyes can give it new direction and move the needle a little. EEng 01:42, 5 September 2016 (UTC)

Indeed!  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:07, 6 September 2016 (UTC)

Use of Palmarès as a heading

FYI

 – Pointer to relevant discussion elsewhere

I have opened a discussion on whether Palmarès (French for list of achievements or list of winners) should be the standard heading used for a cyclists results. Where can I seek opinions on this? Thanks. BaldBoris 20:22, 5 September 2016 (UTC)

I'm against everything French just on basic principle. EEng 03:10, 6 September 2016 (UTC)

Year-range example

The new consensus at MOS:DATERANGE is that in general year-ranges are XXXX–XXXX (4-year ending). The example at Wikipedia:Manual of Style#In ranges that might otherwise be expressed with to or through, which is intended to illustrate the choice of en-dash vs other dash-like symbols has been "the 1939–45 war". That is now contrary to the year-format style guideline. DATERANGE says there can be exceptions, but the given example does not seem to be one. And if the given example is an exception, then it's a poor choice (and unexplained) for a generic example. I am interested to hear from USer:RexxS, who undid my conversion (and USer:EEng's fix of my goof) to "the 1939–1945 war", a basis for continuing to use the now-against-MOS style here. DMacks (talk) 20:08, 4 September 2016 (UTC)

There's nothing to discuss. RexxS is simply behind the times -- see note at head of [1]. EEng 20:28, 4 September 2016 (UTC)

(edit conflict) The example at Wikipedia:Manual of Style#In ranges that might otherwise be expressed with to or through has been in place since Tony1 put it there in on 14 June 2007, and changing long-standing wording at the manual of style requires more than a cryptic edit summary. I'm not opposed to the new consensus for the guidance at DATERANGE, but some regard needs to taken of common usage. In the example in question, "1939–45" isn't simply a period of time, it's actually a title: "the 1939–45 war" and certainly to my reading, that feels much more normal that "the 1939–1945 war". This may be simply a regional thing, and others may find the 1945 more normal, but where this is not immediately clear, common courtesy suggests that it be discussed for the particular example, rather than fought out in an unproductive edit war. --RexxS (talk) 20:31, 4 September 2016 (UTC)

I'm not sure how a phrase of my intent, a link to another page with the specific problem, and an alternative solution is "cryptic", but now here we are. As my edit-summary and above comment invite, please propose a less "title-like"/"common use special case" example if you feel this one is an exception to the current general standard for writing the terminal year of a year-range. DMacks (talk) 20:53, 4 September 2016 (UTC)

The dispute here is over whether to change 1939–45 war to the 1939–1945 war, per the recent RfC scrapping the old guideline preferring XXXX-XX (with exceptions) in favor of preferring XXXX-XXXX all the time (with minor exceptions for things like football seasons and fiscal years) -- see the link I gave above. The purpose of the example is to illustrate that ndashes are used to express certain kinds of ranges, period; Rexxs' idea that the "1939–45 war" is some kind of special exception, or title, or something, has nothing to do with it, and is no business of this example. So to avoid the problem, I've boldly changed the example to Henry VIII reigned 1509–1547. If Tony1 gets the ping above, I'm sure he'll help us out here. EEng 21:29, 4 September 2016 (UTC)

(edit conflict) @DMacks: Thank you for politely engaging in debate on the point. The summary of the RfC was "The community has decided that four year date ranges (i.e. XXXX-XXXX) should be the default style used in Wikipedia. A limited number of exceptions apply to this. Firstly, when space is at a premium, such as in tables or infoboxes, 2 year date styles may be used. Secondly, applications such as sports seasons, fiscal years, and consecutive years use the two-year date range convention without problems. These applications can continue to do so. This list is not intended to be exhaustive, and exceptions can apply with a strong local consensus."

First, any wording used since 2007 in the MOS enjoys a strong local consensus, so I'm not unreasonable in asking you to follow the instructions at the top of the MOS page: "Any substantive edit to this page should reflect consensus. When in doubt, discuss first on the talk page." I appreciate that you may feel the RfC is the only consensus that needed to be reflected, but I disagree: local consensus such as here is a specific exception to the conclusions of the RfC.

Secondly, the use of "the 1939–45 war" is common enough as a Google search will reveal. I would speak of "the nineteen-thirty-nine forty-five war" and that is the natural way of thinking about it to me. Indeed, our article World War II links to Occupation of Poland (1939–45), has multiple uses of XXXX-XX year ranges in its section headings, and has several sources that use "1939–45" in their titles, so this isn't just something I've made up.

Now, I accept that others may find "the 1939–1945 war" more natural. Perhaps they didn't grow up in the immediate proximity of that war as I did. I don't know. It's also true that Occupation of Poland (1939–1945) is a redirect, so must be a plausible search term, and that our WWII article also uses "1939–1945" as do the titles of several other sources. To be fair, usage is split between the two variants, not just on Wikipedia, but in the outside world in this case. If you feel that our normal guidance of "Where more than one style is acceptable, editors should not change an article from one of those styles to another without a good reason. Edit warring over optional styles is unacceptable. If discussion cannot determine which style to use in an article, defer to the style used by the first major contributor." is not applicable here, then fair enough. It would be better, though, if we had more reasoned opinions available that just our two. --RexxS (talk) 21:54, 4 September 2016 (UTC)

@EEng: Thank you. Your edit changing the example to a date range that avoids my concerns is an excellent solution, in my humble opinion. I'm happy to close the debate in favour of that. (Although I should say that the issues of article titles, etc. may need more attention yet in order to implement the new consensus.) --RexxS (talk) 22:03, 4 September 2016 (UTC)

You're welcome. And since you're being so gracious I've recalled the unmanned killer drone, and even decided not to unfriend you. Have you visited The Museums? EEng 22:25, 4 September 2016 (UTC)

Agreed that a stock-phrase example is an exception. If there's something actually conventionally named "the 1939–45 War" in the same fashion as "the War of 1812", then don't change it. If it's just a description like "2000–2012 terrorist attacks in France", follow the guideline.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:07, 6 September 2016 (UTC)

Surely there's no objection to "the 2015–16 financial year" ... Tony (talk) 07:35, 6 September 2016 (UTC)

It appears that the point, and conclusion, of the RfC is there was such objection, but I didn't follow it all that closely after initial comments there. The gist appeared to be that habitual use of YYYY–YY format leads to things like "2009–10" which looks to many readers like "October 2009" not "2009–2010"; the hyphen and en dash are not distinct in all fonts. Even the exact case "2009–10 fiscal year" might be interpreted as "a fiscal year of 2009 ending in October rather in than some other month", I suppose. It's just two additional characters and won't kill anyone.  :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:29, 6 September 2016 (UTC)

Guideline against inconsequential edits?

I think there should be a guideline somewhere discouraging the making of inconsequential edits (defined as those that don't affect the rendered text). This would include space-twiddling of almost all sorts, don't use newlines/do use newlines, etc.

This is already stated for users of AWB but I see no reason why it shouldn't apply to all edits. A common response to complaints about such edits is "there's no rule against it!" Maybe there should be. Such edits clutter up the edit history, increase editor workload, and annoy some other editors (like @Trovatore: above, and me), all for no benefit to the reader.

Such a guideline probably doesn't belong at MOS - I just put it here because the preceding section suggests it. Jeh (talk) 06:51, 4 September 2016 (UTC)

While this idea may reduce "clutter", it would put a chilling effect on editors, and that would be harmful to the project. Also, do you include link-piping in this "inconsequential" definition? Fdssdf (talk) 07:03, 4 September 2016 (UTC)

Every rule or even guideline has a "chilling effect" on editors; it is something to consider, but not a reason to reject any idea out of hand. Personally I don't see why "Don't fix what isn't broken", with a list of fewer than a dozen examples of things often fixed but not broken, would be terribly chilling. Jeh (talk) 07:28, 4 September 2016 (UTC)

A "chilling effect" on editors who seem to spend most of their time making such edits would be a very good thing in my view. Peter coxhead (talk) 07:48, 4 September 2016 (UTC)

(It's amazing how many people keep arguing that there's something wrong with advice to not do "work" that does not improve Wikipedia one iota for the reader, but which adds to the workload of other editors, in some cases annoyingly so.)

I'm not sure what you mean by the second. I know what link-piping is, but what sort of change are you asking about? If you mean changing a word or phrase to make it a WL, no, that's not inconsequential - besides the fact that the link renders in blue, the behavior of the page is changed. If you're just changing the code for a WL to a different form, for example changing [[Example|examples]] to [[example]]s, yes, that's inconsequential and "fixing what isn't broken". But at least the change will be plainly obvious in the diff display. "fixed" double-spaces, not so much. Jeh (talk) 07:28, 4 September 2016 (UTC)

• Strong oppose. The last thing we need is a "don't you touch my article" rule that serves no purpose whatsoever other than enabling one editor to try to punish another for making good-faith edits. This would immediately be WP:GAMEd to start an enormous number of disputes alleging that all sorts of small changes qualify as "inconsequential" because a particular editor has low regard for fine distinctions that are important to others. If you find your watchlist being triggered too often by edits you don't care about, set it to ignore minor edits. We have a rule somewhere that we don't want WP:BOTs making such changes; the rationale for this is that bots going around editing thousands (or more than thousands) of articles at a time is a major drain on server resources and triggers many, many editors' watchlists all at once, so this should not be done for reasons that some editors might consider trivial. This "mass changes" rationale does not apply to manual edits and human editors, whom we do not treat like mindless automata. If an editor considers a spacing or other issue important, it's not someone else's job to castigate them for caring about something another individual isn't focused on. See higher up this very page for serious discussion of regular versus thin-spacing between numerals and superscripted citations; obviously some people care about it, while others would not. PS: I think I detect a whiff of the "no one may ever touch my citation formatting" pseudo-concern in this; even if that is not what motivated this request, proceeding with it would certainly re-enable a tremendous amount of disruptive cite-formatting disputation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:31, 4 September 2016 (UTC)

• Conditional support. WP already have a daunting number of rules new editors must somehow learn immediately; it's not good to add to them needlessly. Is this one needed? I think it is in one sense: I've seen new accounts used to make dozens of pointless edits in a rush to be auto-confirmed, apparently just for the purpose of evading page-protection. I certainly would not like a rule that would provide a rationale for reverting such edits; that would be making things worse in most cases. But something that states "don't waste others' time" with a lot of such edits, or something along that line, could be useful where the problem gets excessive. --A D Monroe III (talk) 14:33, 5 September 2016 (UTC)
  • That's not what this is about and would have no effect on that uncommon issue at all (anyone like that would simply hunt down it's/its typos or misspelling of "the" and "hte", making incontrovertibly constructive but also obviously trivial edits to rack up the needed numbers.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:16, 6 September 2016 (UTC)

• Strong oppose. There are lots of possibilities for beneficial changes to the "Wikitext" layout, formatting, spacing etc. that have no visible effect in the rendered article. Just one that comes to mind ... sometimes text is pasted in with line-breaks from the source. These remain in the "Wikitext", disrupting the flow of text in the text editor. I remove them on sight. This would apparently be against the guideline. 81.152.193.175 (talk) 22:08, 7 September 2016 (UTC)

Discussion about showing related articles (See also, categories, navboxes etc) on mobile

See Wikipedia:Village_pump_(technical)#Showing_related_articles.2C_especially_on_Mobile Jytdog (talk) 22:08, 7 September 2016 (UTC)

How to emphasize words in an already-italic text?

If a text is already italicized, how do I emphasize words in a text that’s already italic?

Example: This is a fantastic sentence.

If I want to emphasize the word “fantastic,” do I make it italic (but since it’s already italic, it returns to normal formatting), or do I make it bold?

Example one: This is a fantastic sentence.
Example two: This is a fantastic sentence.
―PapíDimmi (talk | contribs) 22:58, 7 September 2016 (UTC)

I say it's example one. EEng 00:10, 8 September 2016 (UTC)

Since italicizing quotes is optional, what scenario would this come up in? Primergrey (talk) 12:03, 8 September 2016 (UTC)

That is a fantastic question. EEng 14:26, 8 September 2016 (UTC)

Italicizing quotations isn't "optional"; it's expressly deprecated at both MOS:QUOTE and MOS:ITALICS. If it were italicized for a legit reason, like being non-English, and had something emphasized in it, the normal way to do this is to de-italicize. If the material quoted was emphasized in the original and also included something else emphasized on top of that (e.g. by boldfacing or underlining), then it would make sense to use {{strong}} to boldface that part.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:53, 8 September 2016 (UTC)

Emphasizing something that’s already emphasizing, and it’s already italic? Oh my… This is too much for me. I have to sit down.
―PapíDimmi (talk | contribs) 23:16, 8 September 2016 (UTC)

Actually, if you want to be a semantics mega-nerd, the way to really do a non-English quotation that contained emphasis would be He sarcastically said, "''{{lang|es|Mi casa no es {{em|style=font-style:normal|su}} casa.}}''", with italics and language markup (in that order) for the Spanish, then an {{em}} (or <em>...</em>) using CSS to de-italicize the emphasized part as visual counter-emphasis to the italics. :-)  I think I lot of people would just use the {{strong}} approach, not knowing the CSS geekery, and of course someone who doesn't care about this stuff at all would probably just do something like ...said "''Mi casa no es'' su ''casa.''" Anyway, it comes up so infrequently that MoS need not address it, and even most gnomes wouldn't bother with the CSS approach. Something I keep meaning to work on is an inline quotation template that uses the <q>...</q> element (which WP should be using), and, with CSS cascading, could auto-handle this sort of thing, e.g.: ...said, {{quote inline|lang=es|Mi casa no es {{em|su}} casa.}}, producing the same output as the "mega-nerd" version above.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:02, 11 September 2016 (UTC)

Updated "Scrolling lists and collapsible content" section

I've updated WP:MOS#Scrolling lists and collapsible content:

• Google's increased transcoding of WP articles for millions of people is a serious issue. (See Wikipedia talk:Manual of Style/Accessibility#Lightweight pages via Google.)
• Our mobile stats are now at about 45% of pageviews, and guesstimated to be over 75% of users at least some of the time.
• Copyedited; the section had a lot of unclear language in it.
• Updated to reflect current (desirable) usage; we use pre-collapsing, legitimately, for a few more things that just navboxes and redundant table cells.
• Moved the geekery into footnotes.
• Expanded the list of known "mobile-unfriendly" CSS classes.
• Distinguished between different types of accessibility issues and different user classes.
• Addressed why people sometimes want to collapse-box entire sections and what they should be doing instead (section better, rewrite trivia lists as encyclopedic prose, split an over-long article, remove indiscriminate junk).
• Told people how to test mobile accessibility easily.
• Cross-referenced key terms to guidelines and policies (remember that people almost always read MoS by section shortcuts, not from top to bottom).
• Put dos/don'ts in concrete terms.
• Reduced the excessive stressing about the spoilers thing; that hasn't been a controversy in years.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:24, 11 September 2016 (UTC)

PS: I mentioned this over at WT:MOSACCESS; it's possible this section should be ported over to that MoS subpage, including its footnotes, then re-summarized here in more clipped form.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:06, 11 September 2016 (UTC)

Proposed change to FAC MoS-compliance criteria

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Featured article candidates#MoS and featured-article criteria, a proposal to reduce the Featured Article Candidates criteria to include only a few limited points of compliance with the Manual of Style. It also includes side proposals to eliminate the MoS completely, or to pare it down to a single page with a small number of points.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:17, 12 September 2016 (UTC)

Spacing amendment for numbers

I would like to suggest a slight amendment to Wikipedia spacing. In the event that a reference follows a number, that a space or a comma (comma for main article, space for side info box where nothing follows e.g. membership figures) should be used to show the number and the reference number are not one and the same. It can be easy for people to become confused, especially people with reading difficulties such as dyslexia and this seems a small and simple change that can add clarity and help avoid confusion. -- (preceding by User:Helper201 at 4:21, 21 August 2016‎, restored from page rollback)

I'm not sure I exactly follow. Could you give an example? --Trovatore (talk) 20:16, 21 August 2016 (UTC)

It sounds like she's saying we should not have, say in an infobox, "Population: 187^[8]" (no space after the number 187) but rather "Population:187 ^[8]" (space after the number 187).

We can do this by hand now and people probably do, but since we do proscribe a space before a ref generally, it might be that we need to say "but not here!" somewhere. I would hope not though. Herostratus (talk) 20:46, 21 August 2016 (UTC)

Ah, I see. I guess I don't have much to add (but will anyway). Right, it seems perfectly reasonable to add a space in that situation, but I prefer not to clutter up the MoS with a million commonsense exceptions for unusual cases. The MoS says it's a guideline that allows for occasional exceptions. If there's evidence that people are being overly rigid about the no-space rule, then I suppose we might have to add an exception. --Trovatore (talk) 21:53, 21 August 2016 (UTC)

IF we agree that's a common-sense exception, we will in fact need to have a rule about it, otherwise people will remove that space on the strength of the general no-space rule (proof: it is happening today, ergo not everyone agrees that having the space there is obvious common sense). The rule need not be in the main MOS page, just in WP:MOSNUM where all the other nit-picks about numbers are. FWIW, I agree we should have this spacing exception, as long as the ref or other superscripted number is directly contiguous with a preceding numeral or other numerical construction (e.g. a formula), though not with numbers spelled out, like "seven".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:34, 22 August 2016 (UTC)

This is probably worst after a superscript: Area of a circle is πr² (although I guess this particular example would be set as math) Kendall-K1 (talk) 01:51, 22 August 2016 (UTC)

• For everyday numbers in normal text, no -- the superscripting and brackets make it clear what's going on, and even if a new user is momentarily confused, once you've read even just one article you'll get the hang of it and never be confused again. Math is a different matter, and as already noted that would be typeset anyway -- we could say something like "In the case of mathematical formulas, a space may be added where confusion [etc etc etc]". And to the extent anything like this is done, it should be a {{thinsp}}, not a regular space i.e. the first of the following, not the second

πr²  (thinsp)

πr²  (regular space)

(Yes, there's a difference, and yes it matters.) EEng 02:36, 22 August 2016 (UTC)

References

Agreed it should be a thin-space; I'd meant to make the same point and [ahem] spaced it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:56, 1 September 2016 (UTC)

Hello everyone. Thank you for your responses. I didn't have ideas about aspects such as mathematical equations, so I'm glad this discussion has been able to develop further. The initial aspect that brought me to this was number information in the info box on the right hand side of the page, where you would have say, 'population 567^[1]', rather I'd propose 'population 567 ^[1]'. Instead of no space between the number and the reference number where it may become confused.

This then lead me to observing in text references too, although they aren't always as applicable because sometimes the reference is placed at the end of the sentence, after the full stop, so the divide is clear and this would be unnecessary. I think for in text references a comma would be most applicable (unless as stated a full stop already divides where a sentence ends) because it would look neater than a space and there wouldn't be unnecessary gaps, e.g. 'town ABC has seen a population increase of approximately 500,^[2] people per year'. Whereas a space would be used for the info box as there is less information. Also if a bracket follows the number then in this instance I don't think the change is necessary; for example 'population increased (567)^[3]', would be fine. The reference could then directly follow as it could not be confused with the number.

Can't agree with a spurious comma. We would not write "...of 500, people per year." so we should not use a comma when we add a ref. Of course in this case "...of 500, people per year.^[3]" would be the thing anyway. It is unusual that a reference doesn't follow a comma or fullstop.

I would have some sympathy for a special layout for maths, where a typical text would put an equation or expression on its own line.

But even then we could just as well say:

By Euclid's theorem^[3]

${\begin{aligned}1+\sum _{i}\left\lfloor {\frac {x}{p_{i}}}\right\rfloor -\sum _{i<j}\left\lfloor {\frac {x}{p_{i}p_{j}}}\right\rfloor &+\sum _{i<j<k}\left\lfloor {\frac {x}{p_{i}p_{j}p_{k}}}\right\rfloor -\cdots \\\end{aligned}}$

rather than conflate the maths and the footnotes.

All the best: Rich Farmbrough, 21:30, 24 August 2016 (UTC).

Yes, the idea of adding a comma is a complete nonstarter. And I'll say again that the brackets, the superscripting, and the difference in color make it so no one can reasonably be confused for long. I appreciate the OP's concern about dyslexia and so on but I just don't see it. EEng 21:52, 24 August 2016 (UTC)

How about the addition of a space between a number and a reference in the info box on the right hand side? I can't see any negative aspect to this small change and I haven't seen anyone present one. I know some people may think its obvious but if it could help people and it doesn't have a negative impact I don't see any reason not to allow this.

• I don't have a strong opinion about permitting a space or some other separator. However, if we add a special case for this, let's also suggest that the situation should simply be avoided wherever possible. Something like: "When possible, avoid placing a reference directly adjacent to a numeral, as it may confuse readers. Consider rewording the sentence, replacing the numeral with a written number, or moving the reference to a different part of the sentence." Pburka (talk) 23:34, 26 August 2016 (UTC)

I'm sorry, but for simple standalone numbers (i.e. a string of Arabic numerals, not a mathematical formula that maybe ends with a numeric constant) I just don't see how anyone can reasonably be confused. I think we're worrying over nothing, at least for the case I've described, which comes up frequently in e.g. infoboxes. EEng 03:21, 28 August 2016 (UTC)

I agree with the idea of advising that people rewrite to avoid when possible; this is standard MoS advice about any potentially confusing construction.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:56, 1 September 2016 (UTC)
PS: Also agree that adding a comma is a no-go; that's semantically nonsensical.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:11, 3 September 2016 (UTC)

Fine to advise "rewrite where confusing", but we shouldn't be suggesting that The 1960 population was 123,000 and ... is confusing. It's not. EEng 23:05, 5 September 2016 (UTC)

As the discussion above indicates, not everyone agrees. Not sure what else to tell you. I'd never thought of it as confusing myself, but it certainly would be after a mathematical expressions, since someone could mistake it for something having to do with an exponent.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:01, 6 September 2016 (UTC)

My example was specifically that of a simple number, not a mathematical expression in which an exponent might be found. This covers the vast majority of cases. Where articles include mathematical expressions, there are mathematically inclined editors who will use there judgement and act accordingly. We don't need anything in MOS on this except maybe something like

Where there is danger of confusion e.g. ${\begin{aligned}1+\sum _{i}\left\lfloor {\frac {x}{p_{i}}}\right\rfloor \end{aligned}}$, rewrite to put the citation callout somewhere else.

(Not the best example nor best way of putting it, but you get the idea.) But I think even this is unnecessary: since there's nothing particularly pushing the callout into that bad location, we don't need a counterbalancing rule making it OK for editors to move it somewhere else as needed. EEng 17:43, 12 September 2016 (UTC)

About "MOS:NOTUSA"

(Clarify: I am talking about the paragraph linked by the MOS:NOTUSA shortcut.)

This paragraph claims: "US is more common in most other national forms of English." Is there any evidence for this? To me, as a Brit, "you-ess" sounds utterly American, and it is much more natural to call it USA. I am, of course not arguing with the situation for AmE, but the fact even that this shortcut (NOTUSA) had to be invented rather suggests that "USA" is indeed what it is called by many (at least non-American) people. Imaginatorium (talk) 19:32, 25 August 2016 (UTC)

I needed to read the paragraph of this section of the talk page to find out what it was talking about. When I simply read the heading, I thought the subject was whether WP:NOTUSA should re-direct to WP:WORLDVIEW because I thought it meant don't treat Wikipedia like it's a primary American encyclopedia, not don't use the USA abbreviation. Georgia guy (talk) 19:43, 25 August 2016 (UTC)

Imaginatorium: Lots of Americans use "USA" also. But mostly in relatively informal contexts — patriotic songs, sporting events, things of that nature. The "US" abbreviation better fits the formal tone of an encyclopedia. --Trovatore (talk) 20:00, 25 August 2016 (UTC)

Thanks for comments: I just clarified above (I hope). My point is that to me, it's the other way round: "US" is an American informality, whereas the full name of the country is "United States of America", abbreviated USA, and distinguished from various other sets of united states. I can see an argument that the Americans want it to be referred to without the 'A', and people should be able to decide their own names, but I think this should be clarified, or backed up by some evidence (e.g. a British style guide). Imaginatorium (talk) 04:50, 26 August 2016 (UTC)

I agree with Imaginatorium; there's nothing "informal" about the use of "USA" or "U.S.A." outside the United States. As just two examples, it's the standard abbreviation in the World Checklist of Selected Plant Families and World Spider Catalog, which is why you'll find this form all over Wikipedia in lists of plant and spider species. The MOS guidance on this subject is not neutral with regard to ENGVAR, as it should be. Peter coxhead (talk) 05:32, 26 August 2016 (UTC)

"US" is far preferable; "USA" is starting to sound distinctly old-fashioned ("USA Today"). Tony (talk) 06:47, 26 August 2016 (UTC)

"United States" is the standard form in Australia, required by our style guides. Hawkeye7 (talk) 06:32, 26 August 2016 (UTC)

Which "styleguides" are those? If you're referring what is disparagingly known as the "Snook Book", the federal govt thing, it's contemptible. Tony (talk) 06:47, 26 August 2016 (UTC)

In the past, I think "the US" would have been considered an informal shortened form of "the USA", but I'll have to agree with Tony that "the USA" is now becoming old-fashioned. As an American, what strikes me as odd is the lack of periods/full-stops after "U" and "S" [and "A"]. We always write, "the U.S." or "the U.S.A."  – Corinne (talk) 18:14, 28 August 2016 (UTC)

Who's "we"? That's something my father did, sure. It's more prevalent in the South, and among military, government and law people, but in great decline otherwise, probably because most US newspapers have abandoned it in headlines (except publishers those that use all-caps for headlines). I agree that it has changed within living memory; I remember a time when "the U.S." (with or without periods) was considered a little informal, but I'm going back to the early 1980s for that.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:27, 1 September 2016 (UTC)

That's a good example of the influence of ENGVAR on what seems old-fashioned. The full stops in "U.S.A." are very old-fashioned to me, being British, whereas "USA" merely seems more formal than "US". I'm in favour of allowing all four forms, so long as there is consistency within an article. Peter coxhead (talk) 19:17, 28 August 2016 (UTC)

Here in Yankeeland, "USA" is what cowboy-hat-wearing yokels chant when they hear we bombed someone again. Not exactly unrelated, it's also used in a sporting context. Its use as an abbreviation in general, formal writing verges on an exonym at this point, the way Germans feel about being called "German", I think. Heh.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:27, 1 September 2016 (UTC)

Style guides very commonly say to use "United States" as a noun, and "US" only in an adjectival construction ("US-based company", etc.), a rule WP should consider since it is so frequent and serves the purpose of clarity and avoidance of informal tone (or at least consider a version of it, e.g. "as an adjective, in tables, [etc. – whatever we think is needed for WP]"). Far too often, articles start with something like "JoeCo is a US weasel-shaving company...".

I've never seen a style guide outside the US say to spell it "U.S.", other than one newspaper's (maybe The Economist, I forget off the top of my head, and I have those books inaccessible right now due to some wall construction). An increasing number of American style guides have abandoned "U.S." for "US". Even the strongest bastion of that usage, outside the "U.S." government itself – American journalism – has turned radically inconsistent on the matter in the last decade, with the AP Sylebook abandoning the dots in headlines but retaining it in regular text, and some non-AP publishers doing the exact opposite, others using "US" exclusively, others "U.S." exclusively, and many (especially online) news sources being internally inconsistent on the matter. Many academic guides still favor "U.S.", except in the sciences, but they have slow update schedules (e.g. the last Chicago Manual of Style came out in 2010, and we're not likely to see a new one until at least 2018 but all accounts, possibly 2020). Even so, the very conservative Chicago itself now prefers "US". I've ever seen any style guide, anywhere, newer than the first half of the 20th century say to use "USA" or "U.S.A.", and even those that favor "U.S." and admit of "USA" ins some contexts say to avoid "U.S.A.", on the principle that conventional English practice is to drop the points from acronyms (anyone seen "N.A.T.O." since ca. 1984?); many specifically advise against the TLA version as archaic or colloquial. Its near-extinct use as an abbreviation in running prose should not be confused with its use a symbol in tabular data, like Olympic sports scores (IOC, FIFA, etc. use TLA country codes), the compressed data of field guides in which "US" might mean something else, in documents that use the three-letter ISO standard for all countries, etc.

As I indicated about a year go, we should eventually revisit whether to continue to permit "U.S." except in specific contexts (like U.S. government ones: "U.S. Secret Service", "U.S. Air Force", "U.S. Supreme Court", when these are abbreviated at all). We should reconsider whether consensus may change on this, maybe in another year or so, because of the rapidity with which real world usage has been shifting, the frequency with which people use "U.S." and "UK" side-by-side despite MoS saying not to, the countervailing infrequency with which anyone reverts a change of "U.S." to "US" in AmEng articles, etc. Per WP:CREEP we should eliminate rule-making that does not serve a clear purpose, and per common sense, a rule that amounts to "do whatever you want" in many circumstances isn't kind of pointless. We have the wording we have now as a hold-over from a 2000s, wishy-washy period in MoS's development when it was full of a lot of "meh, whatever" un-rule verbiage, and was prone to a lot more "my way the only way" editwarring. More editors understand today that MoS's purpose is a "pick something and stick with it instead of fighting about it forever" guideline for consistency, stability and dispute prevention, rather than a pseudo-article codifying what is "right" according to nationalist prescriptivism, or a descriptive-linguistics listing of every possible variation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:27, 1 September 2016 (UTC)

I'd like to point out that the full official name of the United Kingdom is the "United Kingdom of Great Britain and Northern Ireland". I haven't seen the unwieldy abbreviations "U.K.G.B.N.I." or "UKGBNI" used anywhere; Wikipedia editors seem happy with the simple abbreviation "UK". Similarly, the "United States of America" can be abbreviated as "US" without much confusion. Reify-tech (talk) 19:42, 3 September 2016 (UTC)

Well, there is easy confusion with just US -> see the united states ambiguity page, additional to the potential confusion with "us" (US_(disambiguation)). USA is more specific by just one cheap letter. USA is already internationally in wide use. "United States" is an informalism maybe valid and working inside the USA, but not outside. WP should give the international perspective, so we should support the more clear and specific USA instead of the informalism US and WOS#NOTUSA should be not WP recommended or required. Shaddim (talk) 08:50, 6 September 2016 (UTC)

No, there's no confusion. I think you know there isn't, really. It's true that Estados Unidos Mexicanos can be calqued as "Mexican United States", but using the phrase "United States" to mean Mexico, when writing in English, is essentially unheard of. All the other links in the "Countries" section of the disambiguation page are marked "Historical", "Proposed", or "Satirical".

"United States" is not an informalism. It is the name of the country. "United States of America" is also the name of the country, but is significantly less used. --Trovatore (talk) 14:47, 12 September 2016 (UTC)

Well, that and virtually all style guides say not to use "US" as a noun, except sometimes in news headlines and not often even then. People can't have it both ways. Either MoS is largely grounded in what other style guides (especially academic/book publishing ones) are doing, adjusting for WP-specific needs and consensus, or we're just making up random crap to suit our whims. Historically it has been the former, and I would strongly resist that changing.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:58, 6 September 2016 (UTC)

Wikipedia needs to be clear not just to readers in the USA, but to an international audience. "US" does create room from ambiguity in a way that "USA" does not. If other manuals of style indicate a preference for "US", I'd say this is one case where the need for clarity outweighs the need for consistency with other manuals of style. But as it happens, most non-US manuals prefer not to use "US" as a noun-form abbreviation of the USA. Rhialto (talk) 09:50, 12 September 2016 (UTC)

@SMcCandlish: "virtually all style guides" begs the question of which are relevant here. In an article marked as using American English, one set of style guides is relevant; in an article marked as using other variants, another set is relevant, as Rhialto rightly points out. MoS guidance could be ENGVAR specific, or we could look for a compromise appropriate to an international English encyclopedia, as we have done in other cases. The latter course would not be "making up random crap to suit our whims". As I've pointed out before, international databases giving plant and animal distributions generally use "USA" rather than "US", I guess because this form is less ambiguous, although I haven't found an explicit justification. Peter coxhead (talk) 10:14, 12 September 2016 (UTC)

I would think they're treating it as a symbol in a system, like the IOC, ISO, FIFA, etc., codes do, rather than as an abbreviation per se, much the way Pb is a symbol for lead, based on an abbreviation of Latin word for it, but not literally subjected to treatment as an abbreviation (e.g., it is never written "Pb." even in dialects in which an abbreviation must take a dot at the end). The problem with an ENGVAR-specific approach is that "U.S." is not consistently used in American publications, nor is it consistently avoided in non-American ones; it's simply somewhat more common in American ones, and declining in all of them, except in U[.]S[.] government-related usage (and it might even be declining there – I note that it's been abandoned since ca. the 1980s for things like USAF. "USA" or "U.S.A." isn't used in natural language by much of anyone in any context, only as a symbol in a system of symbols (usually other three-letter country codes of some sort).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:39, 13 September 2016 (UTC)

RfC on Wikipedian translation attribution

2 linked questions: (1) might it ever be appropriate to attribute a translation of a quoted text to an editor? and (2) if so, how?

Take this Vietnamese original and English version from Vietnamese poetry#Lục bát:

Trăm năm trong cõi người ta,
Chữ tài chữ mệnh khéo là ghét nhau.
Trải qua một cuộc bể dâu,
Những điều trông thấy mà đau đớn lòng.
Lạ gì bỉ sắc tư phong,
Trời xanh quen thói má hồng đánh ghen.

A century of life
Sees genius aye in strife with doom:
As hills for vales make room
These visions dire consume the soul.
Surprised by joy with dole?
Once-rosy cheek, heav'n's toll is paid.

References

So, WP:MOS#Foreign-language quotations states: "Indicate the original source of a translation (if it is available, and not first published within Wikipedia)". And WP:NONENG states, "In articles, the original text is usually included with the translated text when translated by Wikipedians, and the translating editor is usually not cited." (emphasis mine, in both cases)

So far, so good. However, given (1) that a huge number of verse quotations are either not cited or under-cited, and (2) the nature of the English version provided -- I should suspect on prima facie evidence that this is a published and unattributed (therefore plagiarized) translation. But that suspicion would be wrong, and I know because I wrote it. (Please, please: if you are upset that I have foisted a "poetic" rather than "literal" translation upon readers, I'm happy to discuss my reasons elsewhere... but that's not the topic of this RfC.)

Some kind of Wikipedian attribution might usefully clarify this situation. The only suggestion of this I've found is the interesting note at WP:NOTOR#Translation and contextualizing (2nd bullet, [note1]): "The credit for any new translation should be (tr:WP)." Now, this is just an essay, and I've never seen this suggestion put into practice (and I've looked). It is also an unfortunate choice of code in that "tr:WP" actually indicates the Turkish Wikipedia. Alternatively, I believe I also recall seeing something that looked like a Wikipedian attribution in a <!--comment--> (to me, that smells a little passive-aggressive).

Perhaps (if it is felt that some WP attribution might be appropriate) a template might be developed? This would provide uniformity and allow tracking. It might display a very brief note (possibly with link), while containing further information such as the editor(s) responsible (which might just sit in the underlying wikitext, or be available as hovertext, etc.). Thanks. Phil wink (talk) 04:37, 12 September 2016 (UTC)

Yeah, we definitely shouldn't be using "tr:WP". We don't need to credit translations to WP or to Wikipedians, any more than we need to attribute the paragraphs we write in English. The plagiarism thing is the same for translated text as it is for copy-pasting a definition from a dictionary without citing it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:42, 13 September 2016 (UTC)

Quote size

As everyone was having so much fun discussing quote boxes, I thought I'd open a separate thread here to enquire about any requirements for the size of quotes. Anyone care to take a look over at Cullercoats#Cullercoats Life Brigade House? Thanks. Martinevans123 (talk) 14:45, 15 September 2016 (UTC)

All I can see is "Format a long quote (more than about 40 words or a few hundred characters, or consisting of more than one paragraph, regardless of length) as a block quotation, indented on both sides." Is there really no upper limit? Martinevans123 (talk) 11:12, 16 September 2016 (UTC)

The WP:NFCC are the upper limit. --Izno (talk) 11:35, 16 September 2016 (UTC)

That quote comes from a wholly free (historical) source? (That guidance you link to says just "brief verbatim textual excerpts"?) Martinevans123 (talk) 11:43, 16 September 2016 (UTC)

If the source of the quotation is outside the copyright period, then there is no requirement on the length of the quotation. However, WP:WEIGHT and other aspects of WP:NPOV still apply (as well, perhaps, as WP:NOT). --Izno (talk) 12:05, 16 September 2016 (UTC)

Thanks, all quite subjective then. Nothing like a rough proportion of entire article size, etc. Martinevans123 (talk) 12:08, 16 September 2016 (UTC)

I suppose. There is also Wikipedia:Summary style. In general, I would expect a quotation the size appearing in that article to be trimmed to the information relevant for Wikipedia (per all of the above non-NFCC guidelines/policies), since we are building an encyclopedia and not a quote-house. Perhaps the quotation should be added at Wikiquote or Wikisource--though I'm not familiar on each of their policies/guidelines. --Izno (talk) 12:10, 16 September 2016 (UTC)

There's also Overusing quotations. I'd say an entire section full of a quote is a good example where "Quotes shouldn't replace plain, concise text." applies (2nd bullet of "Specific recommendations"). Robevans123 (talk) 21:58, 19 September 2016 (UTC)

National flags in lead

Editors reacting to flags in text – EEng

Diff

In my opinion the flags in the lead looks untidy. What I am wondering is does that edit go against Wikipedia guidelines? (Mobile mundo (talk) 16:51, 19 September 2016 (UTC))

Ugh, definitely not in the text of the lead. I'm not sure there's an explicit guideline against that, as it seems an unlikely thing for anyone to do. Infoboxes are another matter, especially in a sporting context, where there may be more leeway. WP:MOSFLAG does suggest generally avoiding them, although (as you may discover here) some people are more rigid about applying that principle than others. N-HH talk/edits 16:59, 19 September 2016 (UTC)

Ugh, definitely not in text anywhere in the article text proper. Tables, infoboxes -- maybe, as far as I'm concerned, but I believe there's been a lot of discussion about that and maybe some partial resolution. EEng 19:29, 19 September 2016 (UTC)

I join in the chorus of "ugh". If there's no specific provision in the MoS, it's certainly covered by "Wikipedia is an encyclopedia". No-one could possibly convince me that flag icons in text are encyclopedic. I trust someone will speedily remove them. Peter coxhead (talk) 20:08, 19 September 2016 (UTC)

WP:NOICONS. DrKay (talk) 20:12, 19 September 2016 (UTC)

They are a regular occurrence on PDC European Tour Event articles.(Mobile mundo (talk) 21:56, 19 September 2016 (UTC))

There a a few less now, and I've left a note for the originator. Robevans123 (talk) 12:09, 20 September 2016 (UTC)

Adding "ugh" to the chorus. And the flagicon lobby can get nasty if you remove them, which I do. Take this infobox: you stare at this mess for a while and wonder what the bullets signify (relative inferiority?), and why the Ethiopian Empire isn't bulletted. Has anyone tested what it looks like on a small mobile device? Flagicon are much overused on en.WP, and can look messy, even when badly handled in tables and infoboxes, and can give a misplaced emphasis on nationality. Tony (talk) 12:50, 20 September 2016 (UTC)

Putting paid to pull quotes... shall we?

It really seems that pull quotes are never used and that no one likes them. This seems manifest enough that I don't think we need to be bothered with an RfC on the matter. Instead, let's just remove all references to pull quotes.

I don't think we need to proscribe pull quotes since they are essentially never used, and per WP:BEANS why even mention it, it just clogs the MOS. We should just stop recommending them (by implication). If someone wants the MOS to actively prohibit pull quotes, that would be a separate discussion I think. You could do that later.

So here is what I propose to do presently. If anyone objects, say so soonest, and I will instead present the same as a proper RfC to be voted on and closed.

1) At MOS:BLOCKQUOTE (which is part of this WP:MOS page), strike through through the text shown below as bolded and struckthrough:

Format a long quote (more than about 40 words or a few hundred characters, or consisting of more than one paragraph, regardless of length) as a block quotation, indented on both sides. Block quotations can be enclosed in the {{quote}} template, or between a pair of <blockquote>...</blockquote> HTML tags. The template also provides parameters for attribution. Do not enclose block quotations in quotation marks (and especially avoid decorative quotation marks in normal use, such as those provided by the {{pull quote}} a.k.a.{{cquote}} template, which are reserved for pull quotes). Block quotations using a colored background are also discouraged.

2) Move {{Pull quote}} to {{Cquote}} to and {{Reduced pull quote}} to {{Rquote}} (these already exists as redirects). (In no wise am I saying that these might not be horrible templates that should be deleted or deprecated (Cquote already is deprecated), but that as long as they exist, since we are purging all recommendations to use pull quotes, they would need a new name.)

3) at {{cquote}}, redact parts of the main documentation section. Deletions are shown as bold strikethrough.

{{xt|This template is meant for pull quotes, the visually distinctive repetition of text that is already present on the same page. In most cases, this is not appropriate for use in encyclopedia articles.The Manual of Style guidelines for block quotations recommend formatting block quotations using the {{Quote}} template or the HTML <blockquote> element, for which that template provides a wrapper.

• Pull [Q]uotes work best when used with short sentences, and at the start or end of a section, as a hint of or to help emphasize the section's content.
• For typical pull quotes, especially those longer than the rest of the paragraph in which they are quoted, {{Cquote}} provides a borderless quote with decorative quotation marks, and {{Quote frame}} provides a bordered quote. Both span the article width.
• For very short pull quotes, {{Rquote}} (with decorative quotation marks) or {{Quote box}} (framed) can be used to set the quote off to either the right or left as in a magazine sidebar. This can be effective on essay pages and WikiProject homepages.

And edit the "Usage" section:

{{xt|For actual pull quotes, [T]his template provides a centered, borderless pull quote, with scalable decorative quotation marks, and optional attribution of the source of the quote. It can be used with or without the names of the parameters.

4) At {{Rquote}}, similar redactions to remove references to pull quotes while leaving the rest as untouched as possible.

5) At {{Quotebox}}, similar redactions to remove references to pull quotes while leaving the rest as untouched as possible.

6) At {{Quote frame}}, similar redactions to remove references to pull quotes while leaving the rest as untouched as possible.

I think that is all the references to pull quotes that we have, but if there are others that anyone can point out, those also to be hunted down and shot.

---

I don't think any comments in the nature of "Well, at the same time we should also do such-and-such" would be helpful. I am trying to do one small thing well here. The more geegaws you stick on the more likely you gather objections and then nothing gets done.

I'm looking for (but hoping against) any comments in the manner of "I object to this". I'll treat that as if I had made these changes and been reverted per WP:BRD and therefore go ahead with a RfC. Which will be tedious and effort-costly and with a forgone conclusion (no one likes pull quotes), so think before you object. If you object to some particular detail of wording, may I suggest letting this go through and then you make your detail changes after. Herostratus (talk) 18:02, 21 September 2016 (UTC)

• This is jumping the gun. Just because one camp canvassed and bloc voted in favor of a change they like doesn't mean that consensus has been achieved to stop treating pull quote templates as pull quote templates and enshrine them as alternatives to MoS's prescribed block quote template and code.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:42, 21 September 2016 (UTC)

OK. I'll take that as "I object" and we'll presently move to an RfC.

I guess an alternative to wording at points 3-4-5-6 would be remove all of {{Pull quote/boilerplate}} (that is, all of the text shown at point 3) except for the warning:

The problem with this being that useful information is also lost, such as what the template does. But it does have the virtue of simplicity while also removing all references to pull quotes. Would this be better? Herostratus (talk) 22:14, 21 September 2016 (UTC)

MOSBIO proposal needs more participation

Seeking more participation for my proposal at Wikipedia talk:Manual of Style/Biographies#A slight expansion of MOS:JR.

The proposal has been quiet for 10 days, stalemated around a relatively minor detail. To wit: After considering the recent changes to MOS:JR, which established a default of no comma in John Doe Jr., which of the following surname-first forms should be preferred: Doe, John Jr. or Doe, John, Jr.?

Your participation is needed. If you !vote, please first read all of the discussion, including that in the "Extended discussion" subsection. ―Mandruss ☎ 17:40, 28 May 2016 (UTC)

Restored this from archive since the proposal is still quiet after 39 days. Using Template:Do not archive until to prevent re-archive for 90 days, but that can removed if and when the proposal archives without resolution. It would be a shame to fail to make the main improvement, which has consensus, because of the stalemate on this minor issue. ―Mandruss ☎ 07:46, 25 June 2016 (UTC)

RFC: Gender-neutral language in templates

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I have discovered a lot of templates that when a user prefers to be "gender-neutral", the template will use "they" instead of "it", which looks like that there are multiple people using the same account.

These templates include several from the UAA series of templates, userboxes like this, and others.

I think that we should replace "they"s with "it"s, but want to know whether others agree.

NasssaNser (^talk/_edits) 11:38, 26 September 2016 (UTC)

• Oppose usage of "it" – That is an impersonal pronoun, many people would get offended by it. Personally, I wouldn't get offended but find it awkward. Singular they is becoming increasingly common, but not everyone will understand it – perhaps we can provide an option for traditional "he/she" and "him/her" or similar, but keep the option of singular they. nyuszika7h (talk) 11:54, 26 September 2016 (UTC)
• Certainly not "It" is not used in English for people. The use of "they" as a gender-neutral singular pronoun is widely accepted, although not universally. You can either write something like An editor, if they want ... or An editor, if he or she wants ... or An editor, if she or he wants ... but never An editor, if it wants .... Peter coxhead (talk) 11:56, 26 September 2016 (UTC)
• Strong Oppose. "It" in English is only ever used for animals, newborn babies, machinery, and inanimate objects. Using that pronoun for anyone capable of rationally editing wikipedia is inherently insulting. Rhialto (talk) 12:01, 26 September 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

page ranges...

At MOS:ENDASH, by implication from example it implies that page ranges should be truncated. In the subsection "In ranges that might otherwise be expressed with to or through" it gives a page range example as

pp. 211–19

(rather than "pp. 211-219"). This section is about en dashes, and the example is to show how the en dash is used rather than how we are supposed to show page numbers... but now I've run into an editor who went though an article and changed all the "pp. 211-219" type pages to "pp. 211–19", based on this example (I think the editor is only changing articles where both "pp. 211-219" and "pp. 211-19" are used, so that they will all use the same format, which fine; but being confronted with the question "what format shall I standardize the article on" is using the example given here at MOS:ENDASH as the answer.)

I object to this because if the format "pp. 211-219" is used, then I think the reader's though process is:

1. OK, pages 211 through 219

whereas with the format "pp. 211-19" it's more like

1. OK, pages 211 through 19
2. Wait, what? That's not right
3. Oh, they must mean pages 211 through 219

And so why make the reader use these extra clocks? Even if it takes the reader only a nanosecond to suss what the deal is (and we have a lot of readers and so that's a lot of nanoseconds), it's not like saving the occasional byte on the server matters that much these days. Right? And if not to save server space, what's the advantage?

Isn't this probably something left over from Ur and, being an en dash example, the numbering part was never thought through or discussed or consensus-adopted or intended to serve an as an example or even noticed until now? So is there any objection if I just go ahead and fix this? Or is there a counterargument and we need an RfC? Herostratus (talk) 03:17, 20 September 2016 (UTC)

I have to disagree with you there, I'm afraid. I think page ranges look much better in the 211–19 example. After all, we give year spans in the abbreviated, 1975–79 format (without needing to repeat the century). Also, take the case of huge reference books used as sources: without shortening the page range, we could end up with examples such as pp. 1034–1035 – which is pretty unsightly, imo, and unnecessary. JG66 (talk) 03:39, 20 September 2016 (UTC)

En dash and no elision of digits is pretty standard, I think, and my preference. Don't we have a recent RFC that decided not to do digit elision in general, even in years? So the MOS en dash section just needs to be updated. Dicklyon (talk) 03:44, 20 September 2016 (UTC)

Actually, per a recent RFC, date ranges with full years are preceded over trunicated years. Was at the villiage pump. And I disagree with truncating page ranges too, as there to much potential for excessive confusion or misreading. It doesn't really save anything, and there's really no benefit to truncating (the example isn't unsightly in my opinion at all; it's clear and concise. I applaud the bold fix already performed. oknazevad (talk) 03:46, 20 September 2016 (UTC)

I applaud that fix, too. If digit elision is to be discussed some place, it's certainly not in the endash section. Dicklyon (talk) 03:49, 20 September 2016 (UTC)

Oh well, I don't – I rue it! But what's an RFC on a point of editorial style doing at the Pump? JG66 (talk) 04:05, 20 September 2016 (UTC)

Anything can be at the pump. That's kinda it's point, to be a central clearing house so things are widely publicized so anyone who sees can chime in, instead of just the usual gang who frequent particular pages, as often happens with discussions. And it's not inappropriate per WP:NOTBURO, just to be crystal clear. oknazevad (talk) 04:09, 20 September 2016 (UTC)

Right, but one would expect to have seen a notification here at Talk:MOS, given that it's related to editorial style. Who knows, perhaps there was and I just missed it … Would you mind providing a link to the RFC? JG66 (talk) 04:24, 20 September 2016 (UTC)

It's at here. Don't know about notifications, but RFCs at the pump tend to show up on the central notifications template. oknazevad (talk) 18:15, 20 September 2016 (UTC)

Thanks, oknazevad. JG66 (talk) 16:03, 21 September 2016 (UTC)

• Since MOS:ENDASH is about how you're supposed to use an endash for ranges (and not e.g. a hyphen), not about what goes on either side of the endash, I've boldly changed [2] the example from pp. 211–19 to pp. 7–19, thus avoiding the question here in this section. EEng 19:37, 20 September 2016 (UTC)

Wikipe-tan approves! Herostratus (talk) 22:07, 20 September 2016 (UTC)

The MOS on whether to use full or truncated numbers in ranges (unfortunately silent on the issue of page numbers specifically) is here: Wikipedia:Manual of Style/Dates and numbers#Ranges – Finnusertop (talk ⋅ contribs) 22:19, 20 September 2016 (UTC)

It's silent on page numbers because (I think) page numbers rarely come up in article text proper, but rather in citations, and citation formats are allowed to vary widely (MLA, Chicago, yada yada yada) and specifically do vary on this elision question. EEng 01:21, 21 September 2016 (UTC)

In my view, the truncated form is much easier to read. Any reader who goes through the described "clockwork" for the first time (must be a kid) will adapt within seconds. Tony (talk) 01:26, 21 September 2016 (UTC)

I agree, but my point again is that anything we say here at WP:MOS and/or over at WP:MOSNUM will apply only outside citations/references. That's quite limited applicability, and people should know that before everyone gears up for another MOS fight to the death over it. EEng 01:33, 21 September 2016 (UTC)

FWIW, Chicago Manual of Style says digit elision is fine as long as two digits are carried forward. See here. Cbl62 (talk) 01:40, 21 September 2016 (UTC)

As far as I know, the shorter form is pretty much always used in scientific journal citations. Since journal articles are mostly not more than 100 pages, usually closer to 10, I suspect it is easier to read in the short form. References to books also likely don't reference so many pages. I notice that above, the suggestion is 211-19, and not 211-9, which could also work. As journal volumes easily get over 1000 pages, it could be 1211-19 vs. 1211-1219. The latter takes longer to read. Mostly, one either wants to know where to start, or how many pages long it is. Gah4 (talk) 14:57, 21 September 2016 (UTC)

"pretty much always used in scientific journal citations" probably exactly explains it: we have probably mindlessly inherited this habit from academia. But we are not an academic publication, we are a popular encyclopedia read by people from many walks of life.

If "the truncated form is much easier to read" that'd be different. I don't think it is because it requires an extra tick of mental processing to fill out the truncated form -- IMO. I don't know if there's an objective answer to this so it comes to opinion I suppose.

(What we really ought to put paid to is "pp.". Its probably a latinism -- "pp" is not a proper English abbreviation for "pages" (that would be be "pgs" or something) -- and anyway why abbreviate the short word "pages"? We don't abbreviate "author" as "au" and so on. Again, probably a silly habit unthinkingly inherited from the 19th and 20th centuries, and an egregious and needless barrier between our information and our readers's minds. We should be better than that. But that's another discussion.)

I do note that we no longer truncate years, and we have never truncated dates: it's always been "May 22-27" not "May 22-7". Nor would we truncate most other numbers ("90-95 parts per billion" not "90-5 parts..." and so on). We do it for page numbers because of mindless habit. Another word for following mindless habit is "being stupid". We shouldn't. Herostratus (talk) 15:28, 21 September 2016 (UTC)

Being stupid is two words, but who's counting? Anyway... Yet another word for following mindless habit is "Who gives a shit, pick one way to do it and get back to things that actually matter." EEng 15:57, 21 September 2016 (UTC)

I think that argument is deeply flawed. Aside from your comment regarding "an extra tick of mental processing to fill out the truncated form" (I mean, come one …), the style guide that Cbl62 cited actually qualifies that two digits should be carried forward in each instance, which negates your concerns about days of the year, 90-95 parts per billion, etc. JG66 (talk) 15:50, 21 September 2016 (UTC)

I believe the one people are used to, that they expect, is the one easiest to read. Consistently doing one or the other (why there is MOS) is best. If the usual form is to keep two digits, and dates never have more than two, that would explain that one. The distribution of year ranges isn't so obvious. I have thought more about page ranges in scientific journals, I don't know that it is more common there. I don't know the history of pp, but it seems common in library usage. Gah4 (talk) 15:46, 21 September 2016 (UTC)

OK. I don't agree. I don't see what's so wrong about wanting to save readers an extra tick of processing... however you believe that "the one people are used to, that they expect, is the one easiest to read" and I can't disprove that... so I don't think there could be a consensus on that.

I noticed that Wikipedia:Manual of Style/Dates and numbers#Ranges is really only about dates (it is within the section Wikipedia:Manual of Style#Dates, months and years) so it doesn't really provide guidance on number ranges that aren't dates. So we don't have any guidance on number ranges that aren't dates (now that EEng has (cleverly and properly IMO) redacted the example at MOS:NDASH).

Which fine. I'm seldom in favor of straighjacketing editors to one format. (It does mean that people rationalizing an article's refs so that they have the same format within that article have no guidance, so some will ellide page numbers and some will do the opposite... which the universe will survive.) It's not worth worrying about. As long as I'm not required to do things I personally consider reader-unfriendly (such as elliding page numbers) I'm happy. Herostratus (talk) 12:30, 22 September 2016 (UTC)

There is the field of library science where people study these things, but I don't, and don't know anyone who does. A somewhat quick search finds the Chicage Basic Style Guide specifically requesting not to repeat the hundreds digit. (No mention of four digit page ranges.) Journal article references typically reference the whole article, such that it is the first and last page of the article. Only the first page is really needed, but knowing how many pages there are is nice. Matching first and last is one check against typographic errors. For book references, it is usually part of a book, such that a range is needed. Gah4 (talk) 14:08, 22 September 2016 (UTC)

(@Herostratus: see PP: "Pages (plural), in publishing, from Latin paginae". From Acronym#Representing plurals and possessives: "In some languages, the convention of doubling the letters in the acronym is used to indicate plural words: [...] This old convention is still followed for a limited number of English abbreviations, such as SS. for "Saints", pp. for the Latin plural of "pages", paginae, or MSS for "manuscripts".". All completely unsourced, of course. Carcharoth (talk) 15:09, 22 September 2016 (UTC))

Right. So, it's from when people wrote in Latin. In other words, from the middle ages. I think a good rule of thumb would be "The Wikipedia is not a medieval manuscript". However, I think it would be impossible to change it... I can just imagine the arguments now: "Who are we to alter the sacred style handed down over the generations from the Venerable Bede himself" or whatever, with "But that is how Oxford dons/librarians/other pedants do it" which is just a devolvement from that. So I don't propose to try. Herostratus (talk) 15:56, 22 September 2016 (UTC)

My own preference here is to spell out the full page numbers. I always find it confusing when they're abbreviated. And in the end of academic/scientific publishing that I'm active in, I never see them shortened. Old conventions whose main use is saving paper don't make sense here, anyway. For the same reason I'd prefer "pages" to "pp" but that would be more difficult to convince other editors of, I think. —David Eppstein (talk) 17:35, 22 September 2016 (UTC)

I would also support "pages" in place of "pp." - the reasons for these abbreviations are obsolete. Our references are to provide means for our readers to find information, not to train them in reading <foo> style references. No one should have trouble reading "page" or "pages", the same is not true of "pp" (or even the stylised or abbreviated notations for volumes and issue numbers). All the best: Rich Farmbrough, 21:27, 22 September 2016 (UTC).

I would strongly oppose, because "pages" is conventionally used in bibliographies (and our templates) to refer to the number of pages in a book or article. We are here to educate the readers; save the dumbing down for the Simple English Wikipedia. Hawkeye7 (talk) 11:47, 24 September 2016 (UTC)

Wikipedia is not here to educate the readers. Primergrey (talk) 14:09, 24 September 2016 (UTC)

I would avoid any possibility of confusion by using the full page numbers (every digit). I feel it shows poor wikiquette to risk unnecessarily confusing readers. Also, JG66, MOS:DATERANGE specifically says to use the full year numbers with ranges, the only exception being consecutive years. So it should be 1975–1979, or 1975–76. - Reidgreg (talk) 17:13, 26 September 2016 (UTC)

No, the exception is consecutive years, or in infoboxes and tables where space is at a premium. Anyway, why are we still talking about this? The guideline takes no stand on this at all, so unless there's evidence we need a rule on this, we need to not have a rule on it. EEng 18:54, 26 September 2016 (UTC)

Well, the main reason to have a rule is to provide guidance to editors who are rationalizing a given article. We all agree (I assume) that if article has some pages in the format "pp. 1132-44" and some in the format "pp. 1132-1142" than it's called for, and valid WikiGnoming, to put all the page ranges in that article into one format or the other.

But which one? No guidance. Thus we have a situation where one editor is at one article changing all the "pp. 1132-44" to "pp. 1132-1144" and another editor is at another article changing all the "pp. 1132-1144" to "pp. 1132-44". We can live with that but its not ideal. Herostratus (talk) 22:20, 26 September 2016 (UTC)

This detail is a function of the particular citation format used in a given article, and MOS has always (for whatever reason) kept hands off citation formats. Do you have any evidence that editors are unable to work this out for themselves on each article, or that excessive time is being wasted relitigating the question over and over? EEng 22:46, 26 September 2016 (UTC)

Stick with full page numbers. A construction like "211-19" or worse yet "2008–11" is too easily mis-parsed as something else. WP is written for English-speakers, all of whom are familiar with "p." and its "pp." plural as conventional abbreviations (actually symbols; "pp." like "§§* isn't actually an abbreviation). No one is going to keel over and die if we spelled them out as "page" and "pages", but a certain camp (not surprisingly, greatly overlapping with the "give me decorative quote boxes or give me death" faction, and the "you didn't ask WikiProject [Whatever] for permission before editing our article" faction – it's all about exerting control and denying others any editorial rights at articles one feels proprietary about) will certainly act as if it's a life-or-death matter, and a lot of a needless drama would ensue. MoS has not "always" taken a hands-off approach to citation content. It was simply PoV-forked, into what is presently essentially an anti-MoS segment, at WP:CITEVAR. It is staunchly defended by people convinced that it is of paramount importance to permit exact duplication of off-WP citation styles (Vancouver, Harvard, Turabian, MLA, AMA, whatever) – or even totally made up one that exist no where but in one editor's imagination – and the vast majority of those that use anything but position after volume and issue to indicate page numbers do so with "p." and "pp." If MoS were to change to demand "page" and "pages", expect concentrated (low numbers) but non-stop resistance, and a consequent failure of anything to comply with the change, other than the default output of the CS1 templates (if you're lucky).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:18, 30 September 2016 (UTC)

Liberation lingo

Howzit all.

If this is not the right place to start this discussion, kindly redirect me elsewhere.

I work mostly on WikiProject MilHist related articles, and something I've increasingly noticed is the use of "liberation lingo", describing wars and conflicts as "liberation struggles" and the parties that waged them as "liberation movements". WP:VALUE says terms like "freedom fighter" are vale-laden labels which attempt to skew the readership's opinion, so my question is do the former two also fall into this category?

Liberation-this, or liberation-that is, I believe, an example of loaded language (except when used as a proper noun, such as National Liberation Front). It's use is common in describing the liberation of European territories from Nazi rule following WWII in the First World; however, in the Third World the word is mostly derived from communist terminology and used to denote a successful guerrilla war or an insurgency. Often both sides would claim to be fighting for freedom. Use of this language in that particular context is currently grossly pervasive in some areas of the encyclopedia. It doesn't help that the United Nations has a list of "liberation movements" it recognises, but then again the UN isn't subject to the rule of NPOV.

If indeed liberation lingo is an enormous breach of WP:VALUE as I suspect, we should add it to the list of terms to avoid.

Thanks, --Katangais (talk) 13:09, 29 September 2016 (UTC)

Is there any evidence that editors are not working this out for themselves without MOS' help? EEng 14:19, 29 September 2016 (UTC)

See Freedom fighter? Martinevans123 (talk) 14:29, 29 September 2016 (UTC)

There doesn't appear to be any precedent for resolving this, unlike "freedom fighter", which is one probable reason it's gotten out of hand. A straight answer is what the community needs: are the terms "liberation struggle" and "liberation movement" considered value-laden labels covered under WP:VALUE or not? --Katangais (talk) 14:50, 29 September 2016 (UTC)

Yes. Clearly very value-laden and biased terms. "Liberated" is always from the side of the conquering victor. We all accept that when the losing side was Nazi Germany, but can we hold it at that please? Dicklyon (talk) 04:52, 30 September 2016 (UTC)

I repeat: Is there any evidence that editors are not working this out for themselves without MOS' help? Absent that, why are we discussing this? EEng 05:37, 30 September 2016 (UTC)

I hope you're right, that this doesn't need more MOS involvement. But WP:VALUE isn't where such things are covered. Does anyone have the right link please? Dicklyon (talk) 06:14, 30 September 2016 (UTC)

Perhaps this is a question relative to MOS:WTW? Dicklyon (talk) 06:17, 30 September 2016 (UTC)

Agreed. This is exactly the kind of thing that WTW is for. While there's nothing at all wrong with discussing elements of that or any other MoS subpage at the main MoS talk page, direct additions to WTW that are specific to such a degree generally are hashed out at its own talk page.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:03, 30 September 2016 (UTC)

Okay, thanks. --Katangais (talk) 15:32, 30 September 2016 (UTC)

Oh, wait, I thought we were at WTW. I must be losing my mind. EEng 16:07, 30 September 2016 (UTC)

Increasing problems posed by translated articles

The launching of the WMF's translation tool (recently restricted to editors who have a certain number of edits on en.WP under their belt) seems to be behind a recent upsurge in articles that are either poorly written or not fully translated, and contain significant breaches of MOS. I'm seeing a lot of (date-of-birth-and-death) issues aside from the usual problems with massive overlinking and overcapitalisation.

I believe this worsening problem should be addressed using a multiple strategy. This might include at least (1) a system of brief instructions, built automatically into the translation tool process, concerning frequently occurring issues (I can list all of the low-hanging fruit if you want, from my extensive gnoming experience); and (2) a new effort to establish social infrastructure that would allow translaters to ask for the copyediting of translated articles, perhaps triaged given the current cascade. Maybe, also, an onwiki guide for style and formatting on en.WP could be created as a resource for translators.

Here's a recent example, before I fixed just a few things. My guess is that the text was machine translated and poorly fixed. Tony (talk) 04:26, 30 September 2016 (UTC)

Yes, pretty awful. @Buchbibliothek: actually did quite a few cleanup edits after creating it from a crude translation, but I think is not very skilled at English or MOS style, so left it in pretty bad shape. He does a whole lot of edits with edit summary containing "from dewiki" indicating addition of translated material; ask him if it's translated by him, by Google, or by something worse. In any case, it's not good. Maybe he needs to seek an a skillful and tolerant English-language partner. Dicklyon (talk) 04:49, 30 September 2016 (UTC)

A much worse problem with the example you provide, is the lack of sources. The creator should be told to stop and provide full sources for whatever he has done so far before providing any more translations. --Mirokado (talk) 09:02, 30 September 2016 (UTC)

I agree. I'll add a link to this page on the writer's talkpage, but will try to encourage more generally. Tony (talk) 09:26, 30 September 2016 (UTC)

Hello, when I came to enwiki, I translated in the beginning too much and too fast, but I tried to improve the articles, also with the language tool. I made an Excel file containing the articles I have to improve, unfortunately the example Hermann Willibald Fischer did not find the way to Excel. At the moment I do not translate, but just add sons and daughters to articles about towns. Sources in this article: Also the article in dewiki has only one ref. Maybe we should discuss whether translators can ask a mentor for help.Regards Buchbibliothek (talk) 21:42, 30 September 2016 (UTC)

How is this a MOS problem? Nothing you propose can be aided by changing the MOS, so isn't the better place WP:VPPOL or WP:VPM? --Izno (talk) 21:57, 30 September 2016 (UTC)