Jump to content

Wikipedia talk:Manual of Style/Archive 180

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 175←Archive 178Archive 179Archive 180Archive 181Archive 182→Archive 185

Huge argument about short prepositions in titles (again)

See the current flare-up at WT:MOSCAPS over "like" vs "Like" (as a preposition) in titles of songs (and presumably other works, but this dispute usually comes from the pop-music crowd). Predictably, there's a huge pile of "MoS is subject to WP:CCPOL" nonsense, other failures to understand policy (especially the perennial "common name means common stylization" fallacy), claims along the lines of "that's not the style I know, thus MoS must be making up fake rules", the WP:SSF: "music magazines are reliable for rapper quotations and pop chart rankings, so they must also somehow be English language usage authorities if music is involved" fallacy, and other miscellaneous chaos. In reality, there are three well-documented style: never capitalize prepositions ("high academic"), capitalize them if five letters or more (mainstream English), and cap. them if only four letters (journo style). MoS has long taken the middle route, and I'm skeptical any rational rationale has been presented to change it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:28, 16 February 2016 (UTC)

Vertical citations vs. horizontal citations, both using <ref> style

I am currently having a discussion with Synthwave.94 (talk) on his talk page about vertical citations vs. horizontal citations, both using the <ref> style. I happen to use vertical because I find it easier to read, and edit, in case I make a mistake. I realize that the horizontal usage of the <ref> style is far more common, but I don't have any problem with the horizontal usage, and I don't ever change horizontal to vertical; I leave existing cites in place as they are. However, Synthwave.94 insists that all of the cites on the Money for Nothing (song) page must be horizontal. I don't believe that to be the case; described here, it seems to be that vertical and horizontal cites can co-exist peacefully on the same page. What say you, community? Rockypedia (talk) 13:32, 7 February 2016 (UTC)

Here is my take... You say you don't have a problem with the horizontal format... OK... so ask yourself whether it is really worth arguing about. If someone else insists on something you don't really care about, make the other editor happy by giving them a (petty) victory (to quote Star Wars: "Let the wookie win").
Another alternative (if you really find the horizontal format too difficult to work with) is to use the vertical format when you add information, but ask the other editor to follow up and "conform" your work to horizontal when you are done (that is called cooperative editing). Blueboar (talk) 14:57, 7 February 2016 (UTC)
It's not really about arguing for "my" format vs. "his" format. I'm actually looking for an answer here. Is the vertical format acceptable (pretty sure it is), and if it is, is it okay for it to co-exist with horizontal cites in the same article? (I don't know) I guess that's the question I'd really like to see answered, for future reference. Rockypedia (talk) 15:10, 7 February 2016 (UTC)
There is no compulsion to use either style. For myself, I am programmer-lazy and use horizontal, whilst recognising the superior presentation of vertical. As you say, horizontal is more prevalent. This is more a conduct issue than anything else; if all else fails, edit-war until one of you breaks 3RR and apply for a block.
However, you seem to be implicitly asking for some MoS guidance or prescription. There is none; both styles co-exist. I doubt there is any great desire to find a community consensus for one over the other via an RfC.
Possibly WP:RETAIN applies, though the effect is invisible to the reader. You may ask your fellow editor to stop behaving in such an egotistical fashion. --Pete (talk) 15:14, 7 February 2016 (UTC)
  • Both styles are entirely compatible and produce identical output. There will never be a guideline regarding cite code formatting, even one about having a consistent formatting style. Just keep adding sources any way you like, and if someone reformats them, think long and hard before reverting. For example, on any article I've been primary editor on, I'll be pretty protective about my vertical formatting. When I'm not the primary editor, I'll slap them in my way (or not) and let the more active editors on that page format it whatever their OCD gods tell them—you can't possibly "win" and nobody will sympathize with you for trying. Curly Turkey 🍁 ¡gobble! 21:18, 7 February 2016 (UTC)
Rockypedia doesn't understand his edits are unhelpful and that his time-wasting actions don't improve anything at all. I've been edited the article for a long time and this editor recently messed up introducing a badly formatted format (that I cleaned, as I usually do over the article I regularly take a look at). Synthwave.94 (talk) 23:57, 7 February 2016 (UTC)
Note that my actions fall under a standard clean up editing, which is perfectly accepted across the articles I've been editing on so far, but Rockypedia obviously doesn't seem to understand it. Synthwave.94 (talk) 00:02, 8 February 2016 (UTC)
Synthwave: Are you really claiming that Rocky's adding a citation to an article for a previously unreferenced claim was "unhelpful" or "messed up"... because the reference template call included more newlines than you'd prefer?
You'd prefer that an unref'd claim remain unreferenced rather than have Rocky add the ref in "vertical style"?
Seriously?
There is nothing "badly formatted" about the vertical style. A significant fraction of editors do prefer it. And you can't use "clean up" as a defense when nothing was "dirty" to begin with.
Ok, an incorrect parameter was used, but that could have been fixed without your introducing all of this drama.
Regarding your "I've been edited [sic] the article for a long time", please see WP:OWN.
I feel very strongly that edits that do not change the rendered page should just not be done. This includes not only this sort of template style twiddling but also "fixing" doubled spaces or spaces at the ends of paragraphs, changing "File:" to "Image:" or back, etc. Such edits are worse than unhelpful: They clutter up the edit history, often make the "differences" display hard to follow, and increase editor workload (because nearly every edit is checked up on by other editors). All with Absolutely. No. Benefit. to the reader.
But, sometimes, at the cost of annoying the editor whose work you're changing. (An editor who is willing and able to do the gruntwork of adding a citation is a valuable asset to the project. Someone who responds to such an editor by saying, in effect, "No! You may not help improve this article unless you use my exact style in the Wikitext! As it is your edit was unhelpful!"... not so much.)
If you care about the article, be grateful that any citation was added, and accept it as it was entered.
I would agree that there is a preference (only that, not a guideline) for complying with the template style, horizontal or vertical, that is already predominant in the article. But going in and changing it, for no other purpose than to make it fit your preference, simply compounds that offense. Please stop.
And please try to avoid accusations of mental incapacity, such as "Rockypedia obviously doesn't seem to understand it". Such comments violate WP:NPA, among other things, and so quite weaken any strength your position might have had. Jeh (talk) 00:55, 8 February 2016 (UTC)
(By the way... If such things can be considered a "personal style" then I'm told there is actually an ArbCom case that concluded that articles should not be changed just to change from one personal style to another. I haven't been able to find it, but I'll keep looking.) Jeh (talk) 00:56, 8 February 2016 (UTC)
@Synthwave.94: if you make an issue of this, you will inevitably lose, and will make a fool of yourself along the way. Curly Turkey 🍁 ¡gobble! 01:45, 8 February 2016 (UTC)
A significant ArbCom case in mid 2005: the BC/BCE debate. If two styles are equally acceptable, then they should not be arbitrarily changed to suit a personal preference.
Jeh, I disagree about not making changes that don't change the page visible to the reader. These can be marked as minor, if they are simple and uncontroversial. And often, as in the examples you mention, they are really just a waste of time. Wikipedia is not likely to need the disk space freed up by eliminating duplicate spaces. But sometimes, a bit of work can make a page clearer and easier to understand for future editors. Tables, for example. They can be very hard to work on if the lines are all run together. A bit of space in template fields to make them more legible. That sort of thing. There are editors who enjoy making these tedious and repetitive changes, and such wikignoming is not to be discouraged lightly. But it the result is disruption, as we see here, then action must be taken to end it, preferably by reasoned argument and presentation of facts. --Pete (talk) 03:45, 8 February 2016 (UTC)
@Skyring: I see your point. But when I see an edit to one of the articles I care about, and the diff shows section after section where no changes are obvious until I change my carefully calibrated monitor settings to "Appliance Showroom" levels of vividness, thus making the faint beige and blue slivers that denote deleted or added spaces easily visible... and they're all not in places where it helps reaadability of the wikitext, and I still have to look carefully to see that there were no other changes made in the, er, change, that's very annoying and wasting of my time. That's why I wrote as I did above. Jeh (talk) 20:41, 14 February 2016 (UTC)
Contrary to what Curly Turkey says above, WP:CITESTYLE says "While citations should aim to provide the information listed above, Wikipedia does not have a single house style, though citations within any given article should follow a consistent style" (my bold). The question is whether switching between vertical and horizontal represents a different style. Personally I think it does, so you should stick to the established style, especially after complaints have been made. Johnbod (talk) 04:04, 8 February 2016 (UTC)
In theory. In practice it seems that there is rarely any consistency within any article but one striving for or achieving GA status. This may be due to the (unnecessary) slog of hunting back to the first cite to see what its format was. And then modifying all following the first to conform. Perhaps a job for a bot, rather than an actual human subject to headaches? --Pete (talk) 04:12, 8 February 2016 (UTC)
Johnbod: CITEVAR is about citation styles that affect output (harv vs vancouver; including publishing location vs excluding it; short refs vs other styles, etc). If you look through the source code to a bunch of FAs it won't take you long to find some that mix code organization styles (such as vertical vs horizontal; {{sfn}}s and plain <ref>s). It's a total non-issue (though like I said I would slay anyone would tried to horizontalize my vertical cites in an article I was primary editor on). Curly Turkey 🍁 ¡gobble! 05:12, 8 February 2016 (UTC)
That's one view - it doesn't actually define what a "style" consists of, & there are plenty of reviewers who would disagree with that I think - see Skyring above. Of course many articles do mix elements of style, but if the point has been raised I think a strict interpretation should be used. Johnbod (talk) 12:13, 8 February 2016 (UTC)
If someone "cares too much" about template format, and both formats are acceptable, then a strict interpretation of WP:RETAIN solves the difficulty without any third person having to make a difficult value judgement. --Pete (talk) 16:49, 8 February 2016 (UTC)
@Johnbod: Skyring's example is about something that affects input. Horizontal/vertical formatting has zero effect on output. Ditto for putting two spaces between sentences, leaving spaces after headers, etc. It's a non-issue that requires no enforcement. Curly Turkey 🍁 ¡gobble! 22:29, 8 February 2016 (UTC)

@Jeh: The problem doesn't come from the fact this editor added a reference, it comes from the fact he reverted a good faith action (= cleaning up after another editor to follow an established style, which is perfectly permitted, and which is something I'm regularly thanked for). When I say "badly formatted", I refer to to the incorrect use of parameters. Entertainment Weekly is a magazine and therefore the parameters "cite journal" and "magazine" should be used. Dire Straits is a British band and the dmy format should be used all over the article. Is it so complicated to understand it ? There's a huge difference between taking care about this knid of details and "owning" an article (which is NOT the case in any way). It's a good thing this editor added a reference, but he should understand his edits can be modified by other editors such as me and that they shouldn't be reverted without a correctly justified reason (which is clearly NOT the case here). Synthwave.94 (talk) 19:10, 8 February 2016 (UTC)

@Curly Turkey: Loosing what ? I 'regularly clean up after other editors without being reverted. Your comment makes no sense. Synthwave.94 (talk) 19:10, 8 February 2016 (UTC)

The issue was presented as horizontal vs vertical spacing—in that context my comment makes perfect sense. I commented only on that issue—if Rockypedia has misrepresented the issue, then shame on him. Curly Turkey 🍁 ¡gobble! 22:29, 8 February 2016 (UTC)
It still doesn't give an extra right to Rockypedia to undo my edits. I regularly do the same thing across articles watched by numerous editors without receiving any negative comments about what I'm doing. In fact, I often see the opposite reaction ! Synthwave.94 (talk) 23:25, 10 February 2016 (UTC)
Yes, but it goes both ways. Curly Turkey 🍁 ¡gobble! 22:45, 11 February 2016 (UTC)

@Johnbod: Nice to see someone can understand these rules. Synthwave.94 (talk) 19:10, 8 February 2016 (UTC)

@Pete: Consistency is also used in articles without any labels, not simply GA and FA. Also a human like me can do this kind of task. And per MOS:RETAIN, the horizontal form should stay. Synthwave.94 (talk) 19:10, 8 February 2016 (UTC)

If Entertainment Weekly is a magazine, the correct cs1 template is {{cite magazine}}. It differs from {{cite journal}} in how it renders |volume=, |issue=, and the in-source locator parameters |page= and |pages=. {{cite journal}} is properly used for academic and scholarly periodicals so renders the parameters in a manner consistent with those communities.
—Trappist the monk (talk) 19:24, 8 February 2016 (UTC)
The {{cite magazine}} template is less than two months old. Has any effort been made to advertise it? Are magazines that were (correctly) using {{cite journal}} before being migrated somehow? Curly Turkey 🍁 ¡gobble! 22:31, 8 February 2016 (UTC)
The original cite was to a web page with a URL, not a paper magazine title, issue date, and page number. Therefore "cite web", which is what Rocky used originally, was appropriate. Jeh (talk) 22:51, 8 February 2016 (UTC)
Curly Turkey's right. {{Cite magazine}} is a new template and I was unaware of its existence. Synthwave.94 (talk) 23:25, 10 February 2016 (UTC)
@Jeh: No, {{cite magazine}} is more appropriate, as EW is a magazine and not a website. Synthwave.94 (talk) 23:25, 10 February 2016 (UTC)
@Synthwave.94: I disagree. EW is quite clearly both a magazine and a website. This particular reference is to the website. What I find at the URL given looks like a web page, not a scan from a magazine page. To be a reference to something in a magazine the ref would have to include a magazine issue date (not a web page date) and a page number. Jeh (talk) 23:34, 10 February 2016 (UTC)
The website publishes content from the magazine, including the reference used in "Money for Nothing". Also not all the parameters you can find on template pages should be completed. Synthwave.94 (talk) 23:41, 10 February 2016 (UTC)
I've used EW as a source, and I've always used the {{cite news}} template.SciGal (talk) 15:13, 11 February 2016 (UTC)
{{cite news}} should only be used for newspapers such as the New York Times. Synthwave.94 (talk) 16:20, 11 February 2016 (UTC)
See Help talk:Citation Style 1 for related more general discussion of this. The {{Cite web}} template is for sites that are not also something more specifically classifiable. For magazines that happen to be online, use {{Cite magazine}} or historically we did it with {{Cite journal}}, which I think some people thought was misleading. If it's a news news magazine (Time, Newsweek, etc.) you could also use {{Cite news}}, but some might object to that Basically, {{Cite magazine}} exists for a reason. If you cite the online copy of a book, use {{Cite book}}, not {{Cite web}}. If you cite something like the WhatWG FAQ, that's what {{Cite web}} is for.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:10, 11 February 2016 (UTC)
  • WP:RETAIN has no relevance here, because template directionality is unrelated in any way to English variety (dialect). WP:CITEVAR has nothing to do with whether templates are given vertically or not, either; it's about not switching back and forth between, say, Harvard and Vancouver referencing. Some templates, like infoboxes, are best done vertically. Some, especially those used in the middle of paragraphs of prose, are best done horizontally, because it's otherwise difficult to figure out the paragraph structure in the wikicode (understanding the flow of the article is more important that ease of cite template twiddling). Almost everyone does citations horizontally for this reason, and this overall consensus should generally be respected, even if MoS need not address it in particular (though there is no reason it couldn't.) The general principle behind RETAIN, ENGVAR, DATEVAR, CITEVAR, etc. is to default to what the first major contributor did (which may not even apply, if the FMC didn't use any of them) – but only if there are no compelling reasons to use one option vs. another and if consensus has not been achieved for a particular options. It's a myth that we normally do what the FMC did, and we need to rewrite these things to make this clearer; it's a last resort to stop an ongoing conflict. It's also a totally arbitrary and it could have been any other rule, like "default to the option that was used before the question arose", "use the option that appeared earliest, even in a stub", "use the option that has been there the longest", "use the option that is most consistent with usage in other articles", or 20 other choices. (We should probably have an RfC to pick one, because FMC is a really bad idea, as experience has proven.) It is not blanket license for WP:OWN, WP:VESTED, WP:STONEWALLING behavior; the FMC has absolutely no more say than anyone else over any aspect of the future development of the article, but quite a number of editors, even entire wikiprojects, believe otherwise. Anyway, if someone who is actively still among the developers of a particular article badly wants to use vertical citations, they should see whether the other editors are amenable to using list-defined references to keep their citation template code out of the paragraphs. If someone is not actively among the developers, but is just gnoming, they should probably not do anything to vertical citations if someone at that particular article objects, though it's normal and reasonable to change vertical ones in paragraphs to horizontal. I've been doing this on sight for years, and get reverted on it maybe once every 18 months.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:25, 10 February 2016 (UTC)
On the layout of citations, I fully support the above comments. I regularly change in-text references to list-defined references, which makes the source text much easier to read and hence to maintain and improve. I've never been reverted so far.
Abandoning the FMC principle for visible text is another matter. Where the English Wikipedia currently allows arbitrary choices, e.g. reference style or ENGVAR where there's no clear national link, there's no obvious alternative to determine which arbitrary choice to follow, and FMC seems as good as any. Peter coxhead (talk) 19:37, 10 February 2016 (UTC)
Now that (first point) is an entirely clear breach of WP:CITEVAR if some consensus is not obtained first, so please don't do that. Johnbod (talk) 03:07, 12 February 2016 (UTC)
The problems are that the FMC standard is often not actually applicable, e.g. if the FMC did not use any -our or -ize words, and it's even less often applicable to other WP:FOOVARs. The same "go with stability" intent of the FMC rules, which were poorly thought-out and having a lot of negative consequences, can be got at by some other route, even first appearance of one variant or another of the style in the article, or first appearance in post-stub development (which would probably be the FMC in most cases, but would allow for it being someone after that editor did their thing).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:58, 10 February 2016 (UTC)
@SMcCandlish: the solution to the ENGVAR question is to ask article creators or expanders to add a language template; I generally do if I create a "reasonably" sized article. It avoids later hassle. Personally I'd like to see every non-stub article labelled in this way. However, I note you've objected to such templates in the past. Peter coxhead (talk) 22:17, 10 February 2016 (UTC)
I definitly agree with SMcCandish. The vertical form is virtually only used for infoboxes, but not in the rest of an article, where the horizontal form is both more appropriate and more readable. Synthwave.94 (talk) 23:25, 10 February 2016 (UTC)
Not true—vertical cites are extremely common in list-defined refs, for example, as they are far easier to scan and manipulate. SMcCandlish is arguing that horizontal inline cites are less of an interruption of the flow of text than horizontal. He remarks himself that it's a tradeoff with the decreased readability of the cite itself. Curly Turkey 🍁 ¡gobble! 22:44, 11 February 2016 (UTC)
I hardly understand how the horizontal form decreases the readibility when used in an article. I always used horizontal cites and changed vertical cites into horizontal cites (including in list-defined lists) without any problem and without being said it was harder to read. Synthwave.94 (talk) 21:59, 13 February 2016 (UTC)
You're right—I just made that up, and I've formatted hundreds of articles that way just to be a prick. Curly Turkey 🍁 ¡gobble! 22:06, 13 February 2016 (UTC)
I didn't say you were a "prick", I only stated that I don't see how the vertical cites are better. Most editors I met so far use horizontal cites just like me, and not vertical cites. Synthwave.94 (talk) 22:19, 13 February 2016 (UTC)
Most editors do that because they don't know any better, not because they necessarily prefer it. That's my case—I began doing things the way everyone else was doing things, until I found a way that made more sense to me when I got sick of not being able to read cites quickly (or even being able to tell easily where they begin and end) when making large numbers of major changes to articles. Curly Turkey 🍁 ¡gobble! 22:27, 13 February 2016 (UTC)
But that wasn't really my point. I find vertical easier to read—you don't. That's good enough a reason not to police it, because you can't argue it with logic. Curly Turkey 🍁 ¡gobble! 22:29, 13 February 2016 (UTC)
Synthwave: You "hardly understand" how a wall-of-template-call is harder to read in the edit window than a tempalate call arranged with one parameter per line? In which form is it easier to find a given parameter, be sure it is associated with the particular call you want to modify and not an adjacent one, etc.? Hey, why don't we write all indexes, tables of contents, etc., in wall-of-text form—get rid of all the whitepace and ellipses and newlines and careful indentation and let the entries just fall where they may. Forget about alphabetizing the index, too. It will save so much room and work! Jeh (talk) 22:31, 13 February 2016 (UTC)
Just by the way, "no one has ever complained before" is a logical fallacy, simply an inversion of Argumentum Ad Populum (appeal to crowd). A point can be valid even if you've never heard it before.
You know, I would say "I never saw anyone argue so hard for doing unnecessary and, to some, unwanted work," but this is TALK:MOS, where we see exactly that on a daily basis. Jeh (talk) 22:31, 13 February 2016 (UTC)
It's not about logic. I think it's easier to read citations this way because everything's on some lines (most of the time two or three), but I recognize I first start using a vertical form with a sandbox to complete references before adding them in a specific article. Even editors who add vertical cites in articles I'm looking at usually don't complain about my clean up edits. To be honest I like the horizontal format and it can be used for absolutly everything, except for infoboxes because it's easier to modify these templates in a vertical form. Synthwave.94 (talk) 23:31, 13 February 2016 (UTC)
Well, I think it's easier to read vertically-formatted citations because each parameter is on its own line with everything not run together. And it can be used for absolutely everything, not excepting infoboxes. Why you opine that it is easier to modify template calls written in vertical form if they're infoboxes, but not references or other uses, I don't think I'll ever understand... but I don't need to. I'm not saying everything should be vertically formatted. And I'm certainly not arguing for changing horizontal to vertical. I just want you to leave the vertical formatting that you find in articles as you found it. Is that such a big ask? (The choice of template, cite web vs. cite magazine, is a side issue.) Clearly the person who wrote it preferred that form, and clearly this is a matter of personal preference, so who are you to say that your personal preference trumps anyone else's? Jeh (talk) 20:18, 14 February 2016 (UTC)
Cleaning up after someone else is permitted and Rockypedia started edit warring and blindly reverting instead of discussing the issue. He also modified the consistency of the article by doing so. Synthwave.94 (talk) 16:39, 16 February 2016 (UTC)
Note that WP:CITEVAR clearly supports what I'm saying, especially because "imposing one style on an article with inconsistent citation styles (...) [is] an improvement because it makes the citations easier to understand and edit". Synthwave.94 (talk) 16:47, 16 February 2016 (UTC)
Some excellent comments above. Reducing disruption is a big factor in calling on RETAIN or FMC. But seriously, how often do we have editwars over cite template directionality? Maybe there is room for a different way of making cites? Instead of putting the cite templates in the middle of text, wouldn't it be great to have some way of putting them all together (maybe in a popup) so that we're not distracted. We could easily find a source used previously and just add another pointer to it. Vertical templates interrupt the flow of text, but horizontal cites aren't exactly distraction-free, neither.
A pipe-dream, I guess, unless some developer is fired up to get this done? --Pete (talk) 20:05, 10 February 2016 (UTC)

(edit conflict)@Peter coxhead: I don't think there's any objection to the existence and use of templates to indicate which WP:ENGVAR an article is using. Rather, WT:MOS arrived at a consensus to a) deprecate them generating huge banners, either on talk pages or in editnotices; b) merge the divergent sets of them into something less obnoxious and mutually contradictory; and (IIRC) c) not have them for minority spoken dialects that verge on pidgins/creoles and which do not have standardized written forms that diverge in any important way from one of the major varieties; it's just territorial flag-waving to suggest that an article here is written in Barbadian or Philippine English. (That point "c" may have been in the pending TfM that got derailed; I forget if we actually resolved that question here, though a quick archive search will turn it up when needed.) Someone immediately forum-shopped it all to VP, in a misleading second RfC, and stalled it all out, but we should return to some form of cleanup. There would still be a potential WP:OWN problem, e.g. going to articles that one wants to push a nationalist PoV at, and changing the ENGVAR while they are still stubs, claiming to be the FMC, and slapping an ENGVAR template on them that isn't appropriate for the topic. But I suppose consensus can overturn ENGVAR at any article where people think this has been done and object to it. If the templates just invisible-categorize, and produce a present but non-shouting message about the dialect, in the editnotice, the OWN issue will probably be less of a concern.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:43, 11 February 2016 (UTC)
I don't quite see how this would be much more advantageous than list-defined references. Peter coxhead (talk) 22:17, 10 February 2016 (UTC)
Yeah, though I think some of the WikiData people are working hard on something along these lines. Whether people want it or not. >;-)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:11, 10 February 2016 (UTC)
Thanks, Peter C! I had no idea. As usual, way behind the curve. I don't suppose some bright spark has come up with a good solution to the broader question at hand? I think the template war is done for the time being, but where we have minor stylistic variations, FMC and RETAIN might actually work to enforce a style that none of the current editors on an article prefer; everyone checks back, sees everyone else dutifully using the same style as always used and follows suit. At least until some rebel arrives and doesn't cause a conflict when they use the other style. --Pete (talk) 23:30, 10 February 2016 (UTC)
The thing is: on a great many articles (including FAs) there is a mix of cite-directionality, and even cite methods (a mix of templates and <ref>...</ref> tags, for example). When it does not affect output, it should not be an issue—smack the editwarriors with a wet fish and move on. Curly Turkey 🍁 ¡gobble! 22:52, 11 February 2016 (UTC)
Indeed, but you'd be surprised how many editors are 100% convinced that it is absolutely a CITEVAR matter and that you may not alter citation template formatting in any ay if they object (even without any rason) and they claim to be the FMC, or more often, simply the most active recent editor at the page (or because their wikiproject said so, or because some other articles on the same topic are done this way, or any number of other non-rationales). It's a growing and not isolated problem, affecting much more than citation styles (there are a lot of different FOOVARs).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:27, 13 February 2016 (UTC)
To me, when considering between the horizontal-versus-vertical style, it definitely should not be something to edit war on, but it also doesn't demand the need to be consistent through an article. Unlike, say, the choice of dmy vs mdy, or the choice between US and UK English, or using cite templates verses harvard citations, where there clearly are visible effects to the user and thus need to be consistent and using RETAIN to avoid edit warring over that consistency, we're talking behind the scenes stuff here that has zero effect on the end user beyond the handful more bytes one version might take over the other. That said, if I came to an article that I didn't credit but was trying to make it a GA or FA and noticed a mix of styles between horizontal and vertical, I would likely take the time to clean that up. I would not want people to wikignome this approach, but if its part of a broad article cleanup, it should be fine.
On list-defined versus inline, that is definitely one that should be consistent, following RETAIN. While the end effect is invisible to the readers, it can impact editing by future editors if there is mix of list and inline. (Eg I personally prefer inline, and so may miss that there is a list-defined if I'm editing a section).
And on the different variations of cite templates that essentially produce the same output, I would agree this falls in the horizontal/vertical situation. Not something to wikignome or edit war at all, but may be part of a general quality cleanup. Consistent in the use of such templates is necessary, recognizing when some parameters are italicized and some not, or often as I've come to see, knowing the difference between the work and the publisher, and if you start IDing the publisher, you should do that universally for all other citations where that can be done. But that's a final quality check, not a fundamental thing that has to be fixed immediately. --MASEM (t) 23:18, 11 February 2016 (UTC)
WP:RETAIN pertains only to WP:ENGVAR. And "Not something to wikignome or edit war at all, but may be part of a general quality cleanup." is self-contradictory; you're equating WP:GNOME activities with editwarring, but they are general quality cleanup.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:35, 13 February 2016 (UTC)
There are those who use inline cites for things that are cited only once, and list-defined for cites they use multiple times—for example, an album article may use list-defined throughout, but inline for the box of ratings. I'd never tolerate that on an article I was tending, but there's absolutely nothing wrong with doing so, and there should be no attempt to police it. Curly Turkey 🍁 ¡gobble! 23:29, 11 February 2016 (UTC)
That, too, seems self-contradictory. If it doesn't need to be policed, it doesn't need you to police it at particular articles. :-) Anyway, I agree with you that that the rationale you outlined for a mixed style is a potentially valid one. People should not be engaging in bogus CITEVAR junk-waving about it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:35, 13 February 2016 (UTC)
By "wouldn't tolerate", I mean I'm more likely to be an asshole about it, not that I would seek enforcement. Curly Turkey 🍁 ¡gobble! 22:07, 13 February 2016 (UTC)
I've found that there's perhaps unwritten advice to avoid the use of defined inline citations within templates like infoboxes or review tables (using named templates which work either back to an inline or list defined). The biggest drawback here being that if you have a section of a table that can be hidden, and you bury the citation in that collapsible section, it may not show up on the page load, or you can't readily jump to where the reference is used in the footnote list. But otherwise if it is an isolated section of inlines while the rest use list format, that seems okay, but it's when there's a mix of inline and list in running prose that really should be fixed. --MASEM (t) 23:55, 11 February 2016 (UTC)
Perhaps, but I've seen (often) the same principal applied to the text body: inline templates for once-off cites, and list-defined for multiple-use ones. In the articles I tend, I'm OCD enough to make them all list-defined, but I can't justify the overhead simply for the sake of "consistency" when the output is exactly the same—I have to admit it's all about me, and it's unreasonable to enforce this Wiki-wide. There are enough hoops to jump through without policing something so fantastically inconsequential. Curly Turkey 🍁 ¡gobble! 00:15, 12 February 2016 (UTC)
I'm not seeing this as a major (or even minor) issue, but if we regard the Wikitext as the "code" for the displayed text, then it makes sense to have code that is as readable and easily-maintained as possible for the benefit of future editors. Computer programming was one industry where coding style guides were immensely helpful in keeping code legible. One didn't want a programmer to write huge slabs of code in a personal style, leave the project, and have replacements trying to maintain code that was written in a dense or oblique way. Sure, the program might run fine and display correctly, but when multiple programmers have to work on the same code over many years, it helps to have standards. Especially where we have contributors at varying levels of skill and experience. I see the situation here as somewhat analogous. For myself, I'm now going to be putting in more LDRs, especially when the same cite is reused. In verticle format. --Pete (talk) 00:42, 12 February 2016 (UTC)
Yes, many of us see the advantages—take a look at any of my FAs to see how OCD I can be with it. Enforcing it is another issue, though. An objection many bring against (for example) LDF (and templates such as my beloved {{sfn}}) is that they are newbie-unfriendly: it is not immediately obvious how they work, they require extra overhead, etc etc—which works against the idea that Wikipedia is "the encyclopaedia that anyone can edit". It's a legitimate concern and my use of these devices doesn't say I disagree with or dismiss these concerns. We don't want to scare off contributors simply because they have formatted a citation "wrong". Curly Turkey 🍁 ¡gobble! 01:06, 12 February 2016 (UTC)
I've just played around with LDR. Love it. Glad to have a new wikiarrow in the quiver. Usually where a new editor inserts a poorly formed source (often as a simple inline URL), another editor with more experience will come along eventually and tidy it up when they spot it, simply because it grates. I don't think enforcement is a problem; we probably have millions of references that could be improved in presentation. So long as folk don't go to war over them. --Pete (talk) 01:22, 12 February 2016 (UTC)
(edit conflict) Agreed with CT. There's a reason MOS, WP:CITE, etc., are just guidelines. They're mostly matters for gnoming by later editors, and do-it-well-the-first-time for experienced ones; they're not requirements that new editors must comply with. I'm happy if they just write good content with nomarkup at all, and cite bare URLs as sources.. Between gnomes and bots, we'll polish it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:40, 13 February 2016 (UTC)

Stage names and real names

Thread retitled from "interesting query".
[I am revising the heading of this section from interesting query to Stage names and real names, in harmony with WP:TPOC (Section headings). Please see Microcontent: How to Write Headlines, Page Titles, and Subject Lines. The new heading facilitates recognition of the topic in links and watchlists and tables of contents.
—Wavelength (talk) 16:33, 16 February 2016 (UTC)]

Where a biography is about a person whose "real name" was rarely if ever used, and the title of the article is the "stage name", and where his children use his stage name as their surname, should the biography start off as "'Real name' who was known as 'stage name'" or should we say "'Stage name' born 'real name' as the first line of the lead? The case at hand is Henry Gibson but the contrary examples are George Burns and almost all celebrities whose real name differs from their stage name in current Wikipedia articles. Note this is inapplicable to such celebrities as The Undertaker as I doubt many think that it is his "real name" in any event<g>. Thank you. Collect (talk) 16:03, 16 February 2016 (UTC)

  • For an example of how this has been handled in the past... See Mark Twain. Not a "stage name", but analogous. Blueboar (talk) 18:00, 16 February 2016 (UTC)
  • It should probably relate strongly to known self-identification. George Burns became George Burns, it wasn't just a stage name. Samuel Clemens did not become Mark Twain. His wife didn't call him Mark; it was just a pen name. Dunno enough about Gibson/Bateman. Is there anything deeply biographical about him? What the kids do is not a good indication. Sometimes they rebel and revert to the original name, or pick a different one (Joe Hill (writer)). If there was a divorce one may use the father's name, another the mother's, or one may adopt the parent's stage name and another not (Charlie Sheen and Emilio Estevez). Sometimes they try to ride on the coattails of the parent and adopt as their legal name the parent's non-legal stage name. One of Bob Crane's sons calls himself "Bob Crane Jr." but has a different middle name, and he adopted the "Jr." after his father's death (which is when a real Junior would normally drop the appellation). And so on. Regardless, both names should be in the lead sentence, even if the order is flipped (e.g. at Winona Ryder). Ultimately, I don't think this necessarily is a MoS question, but a consensus-at-the-article one. Wikipedia:Manual of Style/Biographies#Names suggests to use later-then-birth-name order in the case of legal name changes but it doesn't strictly limit them to that order, and clearly isn't interpreted that way. We're often not sure if it was a formal legal name change (I don't think even the George Burns article has that info), and the very concept of the legal name change is a modern and [decreasingly] Western one.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:42, 17 February 2016 (UTC)

Quotations from audio/non-native English speaker

Resolved

I couldn't find any guideline on this whatsoever, as everything seems to pertain to written quotes—at least that's what I can gather. The question is: if I'm transcribing a quote, based entirely from audio, by a speaker whose English is slightly broken (they don't say "uhm" a lot, but their grammar is just a bit off), do I reproduce what they say verbatim; make corrections using "[sic]" every time; make corrections without; or write up both and provide the verbatim as a clickable inline note? Mac Dreamstate (talk) 12:07, 21 February 2016 (UTC)

Adding a multiple [sic] instances will give the impression that the speaker is being mocked. It would probably be more appropriate to give the transcription verbatim if it's parseable and has few errors, and follow it with a note like "[verbatim transcription]", or if it's hard to follow, use [square bracket corrections], just enough that it can be understood. If there are a lot of errors, it would make more sense to paraphrase. Think about how, say, National Geographic Channel handles this when someone like an Egyptian archaeologist with imperfect English is on-camera, who they've decided needs to be subtitled. It might look like "Egypt [has] many more mummies than people think we [do], though many [were] destroy[ed] in [the] late 19th and early 20th centur[ies]" if they said something like "Egypt have many more mummies than people think we does, though many is destroy in late 19th and early 20th century". Either version would be pretty jarring in encyclopedic prose and might again look like we're mocking the speaker, so I would almost certainly go with the paraphrase. We don't have a rule about this; it's just one editor's opinion.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:51, 22 February 2016 (UTC)
Great. I think I'll go with paraphrasing for the prose, and a verbatim transcription in the ref/notes. Mac Dreamstate (talk) 12:07, 22 February 2016 (UTC)

French Revolutionary Calendar dates

Resolved

Are there guidelines for French Revolutionary Calendar dates such as "18 brumaire 1799" in the article "Mélanie Hahnemann"? Conversion to the Gregorian calendar might be complicated. (I saw WP:OSNS.)
—Wavelength (talk) 01:25, 22 February 2016 (UTC)

Does that not refer to Coup of 18 Brumaire?
—Trappist the monk (talk) 01:41, 22 February 2016 (UTC)
"18 brumaire 1799" isn't a French Revolutionary Calendar date, since it contains a Gregorian year. The date intended is "18 brumaire VIII". What makes conversion complicated? "18 brumaire VIII" (or "18 brumaire an 8") is "9 November 1799" Gregorian and "29 October 1799" Julian. - Nunh-huh 01:56, 22 February 2016 (UTC)
Thank you both for your replies. I have revised the article accordingly.
—Wavelength (talk) 18:13, 22 February 2016 (UTC)

FYI: Abbreviations

Editors who watch this page may be interested or able to provide guidance in this VPP discussion on abbreviations . --Izno (talk) 02:05, 25 February 2016 (UTC)

RfC: How to word first paragraph of WP:PERTINENCE at MOS:IMAGES?

Opinions are needed on the following matter: Wikipedia talk:Manual of Style/Images#RfC: Which version to go with?. A WP:Permalink for it is here. Flyer22 Reborn (talk) 19:32, 25 February 2016 (UTC)

RfC: Amending MOS:JR on comma usage

Please see this RfC at the village pump. RGloucester — ☎ 23:35, 25 February 2016 (UTC)

Section merges

FYI
 – Pointers to relevant discussion elsewhere

Shortcut proposals

 Done

We have MOS:ID and MOS:IDENTITY which link to Wikipedia:Manual_of_Style#Identity

This is a multifaceted section with a general overview, then a subsection on arab-arabic and a subsection on gender identity.

I don't know how often the first one comes up but wondered if we could do a shortcut like MOS:ARAB to point to it?

In the second case perhaps something like (since MOS:GENDER is already taken) the acronym MOS:LEGSI (derived from "latest expressed gender identification", an important phrase there) so that it can be more easily referenced in discussions regarding things like the use of pronouns on biography articles? 184.145.18.50 (talk) 00:09, 15 February 2016 (UTC)

The Arab[ic|ian] question doesn't come up often enough to need a shortcut. There's been two years of recurrent invective about the gender-related material, sometimes with four proposals running at once on three different pages, and it's not over yet. That "latest expressed gender identification" material has been among the points of contention, so we shouldn't shortcut it that way; the wording could change at any time (and it's a bit clumsy, so change is likely). Even for really stable wording, shortcuts tend not to work well if they're not mnemonic and tied to everyday language. MOS:GENDERID & WP:GENDERID would probably be more likely to remain relevant long-term. I agree that block should have a direct shortcut. Other things need to be added to that section, the most obvious being "Irish" and "Jew", so the section could get longer, divided into ethnicity and gender sections.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:46, 16 February 2016 (UTC)
Yeah, "LEGSI" is not memorable or intelligible enough; MOS:GENDERID would be better. -sche (talk) 04:47, 22 February 2016 (UTC)
OK, I added the GENDERID ones. Now I should hit the gym; need to keep my legsi in shapesy. Heh.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:08, 26 February 2016 (UTC)

Commas and "Jr."

Moved to Wikipedia:Village pump (policy) § RfC: Amending MOS:JR on comma usage

I don't think we've looked at this in a while (like a year or longer), but we know it's a moving target, so it should be examined again. The main reason to not use commas in constructions like "Sammy Davis Jr. was..." is that "Jr[.]" and "Sr[.]", like "III", "fils", "the Younger", "the Great", are not parenthetic and nonrestrictive, but are restrictive by nature (George Foreman's sons notwithstanding); the comma usage with "Jr[.]" and "Sr[.]" (or their spell[ed|t]-out equivalents) is logically an error, unnecessary fiddliness as a convention, and inconsistent with every other usage in the same class. Well, unless you go back several generations; I've seen books from the 1920 and earlier that had things like "James Talbot Marston, the Third," and "Pliny (the Elder)", treating them rather pointlessly as parenthetic, but this usage is now obsolete. Another rationale against these commas, observed by Garner's Modern English Usage something like 20 years ago, is that dropping them makes for sane possessives: "Sammy Davis Jr.'s career...". There are other reasons, too, but I needn't list them all out right now.

I would say, if the commas are eschewed by both of MOS's two main, non-technical sources on academic, general English – Chicago Manual of Style (16th ed., pp. 322–323: "Commas are not required around Jr. and Sr.") and New Hart's Rules (2nd ed., p. 109: "the comma is not usual") – and we cannot identify a WP-specific need to retain this extraneous punctuation, MoS should drop it as well. I've already done a bunch of sourcing about what is the current state of "Davis Jr[.] was..." versus "Davis, Jr[.], was..." in major and not-so-major style guides; will polish it up tomorrow, and post it in article talk, where it can be used to improve relevant articles.

Additional highlights, as a preview: AP Stylebook abandoned the comma long ago, and even the stodgy New York Times Manual of Style and Usage has done so. Garner's (and the abridged Oxford ver.) side with no comma. The Gregg Reference Manual, Los Angeles Times Stylebook, and The Elements of Style have not used it in decades. British journalism (Guardian, Economist, The Times, BBC News, Telegraph, etc.) all eschew the comma (though Economist doesn't like to abbreviate it), as does AMA Manual of Style (M = Medical) and AMA Handbook of Business Writing (M = Management), Fowler's Modern English (ed. Burchfield), A Canadian Writer's Reference, and The Wall Street Essential Guide to Business style and Usage, and others. The previous ed. of what is now New Hart's, The Oxford Guide to Style, a.k.a. Oxford Style Manual pt. 1, preferred no comma, but allowed it to be used with "Jr." (that exact spelling) for American subjects. A couple are neutral on the matter, considering it optional, and many do not address the question at all, including the brand new Fowler's (ed. Butterfield). The only modern, intended-for-the-the-public guides (i.e., not internal house style documents) I can find in favor of the comma so far are the MLA Style Manual and Merriam-Webster's Concise Dictionary of English Usage; others in favor of it have dated to the mid-1990s or earlier. I'm missing only a few guides worth looking at, like Penguin Handbook (on order). PS: Zero sources I can find, even old ones, support using the commas with the British "Jr" (no dot), "Jnr" or "Jun."
 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:17, 15 February 2016 (UTC)

At most a year: December 2014, February 2015, March 2015. --Izno (talk) 12:18, 15 February 2016 (UTC)
Actual last RfC on this matter started in April 2015. It was at the village pump. RGloucester — ☎ 14:27, 15 February 2016 (UTC)
Plus, we have huge numbers of outright errors in articles that elect to include the comma but then forget to put the matching comma after when the sentence continues. Nearly all style and grammar books point out the need for the balancing the commas, as in any parenthetical aside or appositive, and point out that this is a common mistake. I can verify that it's common in WP, and no authority, our MOS or otherwise, would allow this. That's another of the reasons the "modern" style of just dropping the commas has been proposed by so many guides, and why WP editors had decided to adopt it here. It was my work to implement that consensus that attracted so many people attached to their commas to come and confuse the issue, and now we're back at a free-for-all with no clear path to correctness nor consistency. Dicklyon (talk) 17:52, 15 February 2016 (UTC)
Our guidance clearly says that the following comma is required, so no one can argue with that. It can be remedied. I think it is much too late to think about standardising on one rule or the other. As seen in the last RfC, that is unlikely to gain consensus, and would require massive change across thousands of articles. The best that we can do now is ensure that consistency within articles is achieved, and that the commas, if used, are used correctly. RGloucester — ☎ 18:31, 15 February 2016 (UTC)
"Our guidance clearly says that the following comma is required, so no one can argue with that." Oh, how quickly they forget. —sroc 💬 06:39, 17 February 2016 (UTC)
Please be more specific, regarding "our guidance," because if one takes "our guidance" to be authoritative Engish usage guides, the clear consensus is non-comma (and any argument based on a "Google Books search," such as found in the discussion linked by RGloucester, above, is flawed, due to the nature of the Google Books search engine algorithm and the motivations behind its formulation). (And a parenthetical point: my own proper name ends with "the third" and no comma has ever been involved; nor is a comma found in the name of my father, whose name ends with "junior.") Catsmoke (talk) 22:43, 24 February 2016 (UTC)

OK, so it's been almost a year. I've long been neutral on it, because I was trained to use the commas and they were thus personally familiar, but I also recognized that they could be dispensed with, and were prone to error. After doing the research on it, they appear to largely be dispensed with. Even Garner eschews it, and he is very defensive of traditional Americanisms, especially those favored in legal writing. It wouldn't "require" changes across a zillion articles just because MoS also eschewed it. MoS is just a guideline. What we would want is for the people to add it with less frequency and remove it with more frequency, exactly the same as we want people to use a non-breaking space between measurements and their units, or immediately before a spaced en dash. "It will require too many changes" is not a rationale against this kind of recommendation.

Anyway, if people can't think of a compelling reason to keep the commas, I think I'll assemble all the pro-and-con material for it and prepare another RfC for launch in the near-ish future. The reason this has never come to consensus before is almost certainly because it wasn't well-enough researched to show how much support there is for the comma-free usage and how little remaining for the comma usage; it just looked like a 50–50 choice, when it is not. After the sourcing run is used to improve the article, it should help make it clear that it's not an even, coin-toss matter. In cases where consensus has concluded that MoS should say something, but it ends up with a "sometimes people wanna do this and sometimes people wanna do that" pseudo-rule, we should replace it with something more concrete whenever it's practical to do so, or the line item serves no purpose. Enough time and change have come to pass in real-world English usage that this is probably one of the cases where we can. If there's a line item we never intended to say something concrete about, we should just remove it, since most of how to write English on WP is up to editorial discretion, and pseudo-rules that sit around for years and years are just dead code.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:28, 16 February 2016 (UTC)

Someone's opened an RfC about this, at Wikipedia:Village pump (policy)#RfC: Amending MOS:JR on comma usage.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:03, 26 February 2016 (UTC)

Proposal: replace ambiguous "non-stub" wording in WP:RETAIN with something more definitive

  • When no English variety has been established and discussion cannot resolve the issue, the variety used in the first non-stub revision is considered the default.

Does anyone know why WP:RETAIN says "first non-stub revision" rather than "first revision"? The problem with saying non-stub is it introduces ambiguity because there are going to be differences of opinion about what constitutes a "stub" (and therefore a "non-stub"). An example of this is the current ongoing RM discussion at Talk:Humour, part of which centers on whether the revision in which the article first was changed from the American English variety to the Commonwealth English variety is a stub or a non-stub[1]. Reasonable arguments can be made for both sides, and that's the problem. The proper interpretation of WP:RETAIN, and therefore how it applies in this case, is unclear.

If we really don't care about variety - if it's truly a coin toss - then why not go back to the variety used at creation? Or to the first revision in which the variety can be identified?

Accordingly, I propose changing the above statement in WP:RETAIN to this:

  • When no English variety has been established and discussion cannot resolve the issue, the variety used in the first revision in which the variety can be identified is considered the default.

I believe this wording retains the original intent of this statement.

Comments? --В²C ☎ 17:17, 24 February 2016 (UTC)

  • Comment The issue that usually comes up amounts to WP:OWN; an editor who puts in a lot of work to improve a stub is generally reluctant to go back to an earlier ENGVAR just because one spelling in an earlier version – which may even not be present in the re-worked version – allows the ENGVAR to be identified. There's never going to be an absolute rule that can be followed clearly, as some ENGVARs are difficult to distinguish (e.g. "-ize" endings don't separate US and Oxford British English; US and Canadian English are only differentiated by a small set of words). What we should be doing, in my view, is encouraging editors to tag articles early on with the ENGVAR in use. Peter coxhead (talk) 17:28, 24 February 2016 (UTC)
  • Oppose – This is just Born2cycle's attempt to push his own view of the guidelines as they are written, so as to "win" arguments elsewhere. The present guidelines are entirely clear, and don't even apply to the Talk:Humour discussion in any case. RGloucester — ☎ 17:51, 24 February 2016 (UTC)
    Doesn't really seem like a reason to oppose. ErikHaugen (talk | contribs) 21:14, 24 February 2016 (UTC)
Yes, it does. There is no reason to facilitate the personal crusade of one user by changing guidelines that he dislikes. RGloucester — ☎ 22:22, 24 February 2016 (UTC)
Perhaps it's time you reviewed, WP:AGF, RGloucester, and WP:NOTBATTLEGROUND. Thank you. --В²C ☎ 00:00, 25 February 2016 (UTC)
You're the one making it a battleground, not me. I have no horse in this race. As said before, "assuming good faith" is not a suicide pact. It does not imply that one should not be wise to disruptive RGWs-style behaviour. Let's not forget that you were party to an arbitration case regarding edits to this very page, along with the "yogurt principle" nonsense. Much as with the "humour" business, you are creating "instability" where none exists. There is no argument here, about what is a stub or not. That's totally tangential to the spirit of RETAIN, and a canard that serves no purpose other than to advance your own skewed position. I don't like these kinds of games. When will you give it up and drop the stick? It's been years. RGloucester — ☎ 00:13, 25 February 2016 (UTC)
  • Support – I hate RETAIN, but if we're going to use it to avoid arguments like this we might as well formulate it in a way that makes it possible to avoid arguments like this. ErikHaugen (talk | contribs) 21:14, 24 February 2016 (UTC)
  • Oppose as the new wording, far from retaining the original intent as claimed, in fact changes the meaning for no good reason I can see. Stubs are important but are not the same as articles that people have spent time improving. Omnedon (talk) 01:47, 25 February 2016 (UTC)
  • Oppose – I get Erik's point, but I think he's not correct that this wording will avoid the arguments like in Humour. When a variety has been established for 12 years, there's no need to look before that for a reason to flip it. Dicklyon (talk) 05:10, 25 February 2016 (UTC)
  • Oppose. There is a purpose in the wording of WP:RETAIN: That it is impossible to say with accuracy what English variety is used in a stub version. It is entirely possible to write a stub that is accepted as British, American and Australian English. The article needs to grow to a certain size where analysis of language variation based on syntax, semantics, pragmatics and discourse can be made. Best regards, Codename Lisa (talk) 13:08, 25 February 2016 (UTC)
    • We're in agreement in principal. Doesn't the proposed wording accomplish this better than the current wording? I mean, doesn't "in the first revision in which the variety can be identified" more clearly mean "a certain size where analysis of language variation based on syntax, semantics, pragmatics and discourse can be made" than does (the vague and ambiguous) "the first non-stub revision"? --В²C ☎ 16:53, 25 February 2016 (UTC)
      • Unfortunately, no. It is wordy, and has jargon in it. Not everyone is eligible to determine this amount of scientific accuracy. Twelve-years-old school students edit Wikipedia and I doubt they even know what is pragmatics, let alone analyze it. As for the original proposal, given my experience, people simply claim "well, it can be identified from this revision" and give a one-sentence revision that has "colour" in it. You see, the current state of affair provides a tangible limit while the proposal says "it can be determined when it can be determined". Besides, the first non-stub revision is usually made by a major contributor. Best regards, Codename Lisa (talk) 05:53, 26 February 2016 (UTC)
        • All WP:POLICY pages have WP jargon in them. We resolve that with links. Wordiness is a matter of copy-editing. The fact that kids edit WP has never stopped us from requiring or recommending what we think should be, and it is not necessary that every editor do everything perfectly; where they err, the rest of the community will resolve it after the fact. 'Well, it can be identified from this revision" and give a one-sentence revision that has "colour" in it' isn't the current state of affairs; that's the proposal. The current state of affairs is to just look at the first non-stub version, and hope a dialect can be identified; it can't if there are no tell-tale words yet like "colour" vs. "color" or "car bonnet" vs. "car hood".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:24, 3 March 2016 (UTC)
  • Oppose To answer the question in the RfC: The wording non-stub was introduced to stop editors who are on a mission creating stubs of articles with a specific national spelling simply to reserve that article as a specific national verity of English. I am surprised, В²C, that you could not find such in the talk archives of this page as it has been discussed many times before. It added to the page with Revision as of 01:17, 30 October 2003. I know that at least once it was deleted (apparently without anyone noticing some time in the middle of June 2007) and I put it back (see Revision as of 13:06, 25 June 2007 ). -- PBS (talk) 18:35, 25 February 2016 (UTC)
This was my first thought exactly. I don't know as this has been a problem, though. But I can imagine someone going thru all the redlinked articles on (let's say) patrol boats (and there are many) and filling them in with "The XXXX is/was a patrol craft of the XXXX Navy. It was painted in various colours at various times" or something, and then Bob's your uncle regarding spelling in the article, forever. The proposed change would, in theory, allow this. So I'm leery. Herostratus (talk) 19:06, 25 February 2016 (UTC)

Ah, okay, thank you very much, PBS. That makes sense. Now, let me ask you this. Is this the kind of stub the concern is about? Per today's definition of WP:STUB ("too short to provide encyclopedic coverage of a subject") one can argue that it is a stub, but yet I suspect it contains sufficient content to not be an example of someone on a mission creating stubs just to establish ENGVAR. So maybe "in the first revision in which the variety can be identified" is not the best wording. How can we describe an article far enough along to not be of this concern, though perhaps not yet providing "encyclopedic coverage" of the subject? --В²C ☎ 21:17, 25 February 2016 (UTC)

"Not a stub". Omnedon (talk) 21:39, 25 February 2016 (UTC)
  • Oppose. The recent "humour" debate was the first time I'd seen possible ambiguity in the definition of a stub invoked in a debate about RETAIN, so I see no evidence that it's a significant problem that must be solved by changing a longstanding guideline. As to the guideline itself, it's easier and preferable to judge based on more established forms of an article, why I'm sure is why the MoS favors it; plus, as Codename Lisa, PBS, and and others have already noted, the proposed alternative is itself quite problematic. Finally, the version of "Humour" that B2C refers to can't reasonably be considered a non-stub under even a loose definition, so I question the "reasonable arguments both ways" claim – especially given that (per WP:STUB) articles on more complex or significant subjects must reach an even higher bar to be considered non-stub. ╠╣uw [talk] 01:16, 26 February 2016 (UTC)
  • Support because it eliminates any possible debate regarding what is or isn't a stub and makes the rule clear cut. Calidum ¤ 05:08, 26 February 2016 (UTC)
There is no "rule". The MoS does not consist of rules. There is only guidance. RGloucester — ☎ 13:56, 26 February 2016 (UTC)
We use "rule" pretty frequently in-context to mean "specific MoS line-item".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:01, 2 March 2016 (UTC)
  • Support, but continue refinement. As proposed elsewhere on this page, we need to gather up all these sometingRET and somethingVAR things, see what they are doing, normalize what they're doing with each other and (more importantly) with policy, then centralize the definitions in one place, and just have the different ENGVAR, DATEVAR, CITEVAR, DATERET, etc., etc., things cross-reference and apply it, instead of using divergent wording in a dozen places. It does lead to dispute, especially as these things WP:POVFORK from each other more and more. One thing is very, very clear, however: The "first major contributor" thing has been a total disaster. Even aside from the fact that the "FMC" is not always who set the ENGVAR (or whatever-VAR) to begin with, it has again and again been mistaken for license to WP:OWN, license to claim WP:VESTED status. Virtually no one on WP appears able to absorb the fact that defaulting to what the FMC did (past tense), if and only if consensus fails to be achieved, does not grant that editor magical supervoting rights with regard to anything about the article moving forward, including, even, more weight in the consensus discussion that could conclude without consensus and revert to the FMC choice. We really do need to tie this to something like what is being proposed here.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:52, 26 February 2016 (UTC) Revised: 09:08, 26 February 2016 (UTC)
    SMcCandlish, I do not follow how you support this proposal while simultaneously arguing against First Major Contributor (FMC), because you are supporting wording that simply moves what you describe as a problem from the FMC to the First Contributor (FC).
  • First Contributor is open to the abuse I mentioned above (Something you have not addressed).
  • In the Humor/Humour example at Talk:Humour (that lead to this RfC), the proposed wordingb in this Rfc simply moves the problem from the FMC to FC as the justification for the proposed move was that the page name is unstable, and so the page name ought to be based on FC rather than FMC as a default spelling (either because FC is better (as FMC is a needless complication) -- per this RfC suggested change), or that in fact the page used humor before humour when it was not a stub (even though erroneously it was labelled as a stub).
-- PBS (talk) 23:04, 2 March 2016 (UTC)
I can't agree. It changes it from false deference to a particular person, to deference to the edit in which the style is first even discernible. That makes eminent sense, and we should have done this the first time. The problem with FMC is the dwelling on who rather than what. No one has proposed (that I saw) any kind of "FC" rule, and I wouldn't support one if they did, for the very reason you would not. There is no "FC" in "the first revision in which the variety can be identified". I'm aware that the FMC wording in this one spot recently changed to "the first non-stub revision" which is an improvement but: a) it's unlikely this change will remain unchallenged by FMC "fans", especially GA/FA pursuers who feel excessively proprietary about "their" articles; b) it has not but nibbled at the FMC problem, which is spread throughout multiple guideline pages (see thread at or near the top of this talk page); and c) it's still an obvious general semantics error; there is no presumable relationship between the first non-stub edit and the first edit in which the style can be identified. I'm skeptical that it's an even slightly-better-than-average coincidence, and thus was never fair to begin with. Many stubs take a significant amount of work, thought, time, and wording, yet it may take only five minutes of drive-by additions of some additional sources and some sectional arrangement of pre-existing content to get rid of a stub tag without objection; that shouldn't be justification for pointedly flipping the dialect and then claiming FMC or first not-stub edit "status" in defen[c|s]e of being a language nationalism douchebag. It's silly and divisive that we would use such a criterion, no matter how we word it. Oh, and d) the "first non-stub version" or "FMC" take simply gives people who are "style warriors" an incentive to either add unsourced material to make their new stub look less stubby, or to editwar against it being stub-tagged. Tying it to first edit that established the style simply gives people an incentive to, e.g., use a word ending in -or vs. -our or vice versa, which is something that has no repercussions of any kind.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:30, 3 March 2016 (UTC)

MOS:LEAD dispute

FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Lead section#Disputing a major BOLDSYN change – vying proposals for addressing when to not boldface alternative names in the lead section.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:38, 6 March 2016 (UTC)

Allow a more structured, orderly listing of references

Wrong venue. Please move to Wikipedia talk:Citing sources
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Off-topic for MoS.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:13, 6 March 2016 (UTC)

PROBLEM: Editing Wikipedia articles is grossly, absurdly complicated by the exteme awkwardness of wading through a tangled swamp of references -- woven seamlessly in amongst the text -- to try and read and edit the article text, or (even more challenging) edit the references, themselves.

SOLUTION (already possible, but contractdicted by the Manual of Style): In the editing window, allow references to start at the beginning of the next line following the text they serve. Have the reference footnotes then appear, when viewed by readers of the article, immediately behind the served text, but with a blank space ahead of the footnote.

Wikipedia's system does actually allow text and references to be neatly segregated this way, and the result is

  • A much more readable article;
  • More easily read (and identified) footnote numbers (especially when multiple footnotes are in the same place), with easier distinguishing of pop-up balloons; and
  • Vastly easier editing, with fewer errors and far less wasted editor time (for both the generating editor and for subsequent editors of the same text and references).

CONFLICT: Currently, the Wikipedia Manual of Style, -- under section 9. Punctutation sub-section 9.15 Punctuation and footnotes -- says:

  • "Ref tags (<ref>...</ref>) are used to create footnotes (sometimes called endnotes or notes). The ref tags should immediately follow the text to which the footnote applies, with no intervening space. Any punctuation (see exceptions below) must precede the ref tags. Adjacent ref tags should have no space between them. Ref tags are used for explanatory notes, but are more often used for citation footnotes."

...and many Wikipedia editors are aggressively enforcing this standard (destructively, in my opinion). Let's discuss! ~ Zxtxtxz (talk) 03:10, 4 March 2016 (UTC)

Zxtxtxz: I sympathize with your experience of editing being "grossly, absurdly complicated by the exteme awkwardness of wading through a tangled swamp of references". That is certainly commonplace, and yet quite unnecessary. But your solution is just as confused as the milieu from which all this other confusion arises.

The particular point of the MOS that you refer is that the note links - the superscripted, bracketed numbers that get substituted for the actual notes are supposed to be closed up, without intervening spaces. (E.g., xxx[1] rather than yyy [2] or zzz. [3]) That is entirely a matter of not having any spaces before the initial <ref> tag, and is entirely separate from the content within the note, or how that content is organized. There is no "CONFLICT" (as you claim) with the MOS.

The "tangled swamp of references" you refer to has nothing to do with any requirements of the MOS, it results simply and directly from the practice of most editors to put the entire, templated full citation (with ALL of the bibliographic details) of all references "in-line" in the body ("text") of the article. The easiest and (I think) overall best way of handling that problem is very, very simple: do not put full citations (templated or otherwise) into the body of the article. Put them into a separate section. (Commonly titled "References" or, better, "Sources".)

What goes "in-line" (immediately following the text to which they apply) is a short cite, containing just enough detail - typically author and year - to find the full citation in the Sources. This can (strictly speaking) be just plain text (e.g., "Smith 2004"), or implemented with the very handy {{Harv}} family of templates (e.g., "{{Harvnb|Smith|2004}}", which is simpler and clearer than the "named refs" you have been using). Such short cites can used directly in the text (so-called parenthetical referencing, or in a note as before.

Ask if you need assistance. ~ J. Johnson (JJ) (talk) 19:03, 5 March 2016 (UTC)

WP:LDR formatting also has the cleanup effect of moving full bibliographic info out of the main content and into the refs section. It does not require {{Harv}}, {{sfn}}, or other attempts at footnoted referencing with two sections of citations (short and long), a system many editors do not consider "simpler and cleaner" than LDR.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:03, 6 March 2016 (UTC)
I agree. This is a nonsensical "solution" for a not-a-problem, and there is no conflict with the MOS. The "tangled swamp" problem can be addressed at WT:CITE. ~ J. Johnson (JJ) (talk) 21:05, 5 March 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.

Article organization

It strikes (and annoys) me often, in articles that contain clear thematical sections, that quite a few users ignore those sections and drop their new information directly and only in the lead section. This ofcourse severely harms the consistency and surveyability of the article. People apparently are in a hurry, can’t be bothered to identify the appropriate (sub)section, and drop their ‘very important’ addition directly and only in the lead – which also makes those leads quite often grow and grow, to intimidating and abhorrent sizes.
To bring this ill-practice to the attention of everybody, I’ve ventured an addition in section 1.2 (Section organization). --Corriebertus (talk) 17:55, 6 March 2016 (UTC)

Some thoughts on sourcing style matters at Wikipedia

Lest another fractious, draining, and muddled "source the MoS!" campaign arise, and given the recent mega-drama about that, including a topic ban and now an indef block, I would like to remind us collectively that the sourcing work on questions of style, usage, grammar, spelling, punctuation, etc., should be done primarily for (and posted at the talk page of) one ore more of our relevant articles. Doing extensive sourcing to prove a point just for MoS is a non-productive exercise in writing documentation for documentation instead of doing real work. It's nice when proper, encyclopedic citation work can incidentally also improve MoS along the way, though.

When sourcing for articles, we have to be forthcoming about which editions we're using, and only cite the current ones except for clearly delineated historical purposes. The misuse of old style guides to advance PoV-laden and often nationalistic agendas has been far too common, both in and out of mainspace. Most of the major style guides aside from Chicago have been updated in the last 1–3 years, but some of their previous editions were more than a decade earlier; ones that old are not likely to be reliable for current style matters.

When citing Web style guides, they actually need to be reliable ones; user-generated content doesn't count (including wikis, forums, AllExperts.com, Yahoo! Answers, etc.). Self-published punditry doesn't either, though the language blogs of reputable experts can sometimes be used with caution for certain things if directly attributed as primary sources. House style publications are a mix of primary and tertiary but are still sometimes useful. Individual universities' and colleges' summaries of writing tips for students are tertiary at best, being rehash of the major style guides (they have about the same weight as introductory textbooks, which is low, per WP:Identifying reliable sources).

We also need to distinguish between journalistic, academic, and general-purpose style guides, along one axis, and between those intended for broad public use vs. internal house style along another, and sometimes also differentiate along a third axis of nationality (or other cultural sphere) of the intended market. Our failure to do this programmatically has a lot to do with why our articles on English are so inconsistent, with so few at WP:Good article or WP:Featured article level.

Be aware of the sharp distinction between university guides for student academic writing, and in-house guides for the institutions' own communications departments; the latter are public relations style guides, and are uniformly based on journalistic and marketing manuals, not formal, academic ones. There's also a big difference between the publication manuals of major publishers of academic journals, and a particular journal's style guide (when it really is in-house; many of them are just copies of their publishers'). Lastly, there's a similar distinction between government-produced manuals for the public like the Style Manual for Authors, Editors and Printers by the Australian Government Publishing Service, and internal guidelines like the U.S. Government Printing Office Style Manual.

If you are sourcing something in part for the Wikipedia:Manual of Style please remember that the primary purpose of the sourcing is to improve Wikipedia's articles. Beware performing one-sided, cherry-picked sourcing to make a point, and don't engage in MoS-related dispute in article talk pages, where that will be off-topic (save it for WT:MOS or one of the MoS subpages' talk pages).

[And a note about content policies' applicability to style PoV-pushing and OR in mainspace.]

  • See the sourcing runs I did at Talk:Acronym#All-caps versus sentence-case styles, for an approach to researching an English style/usage question comprehensively for an issue with some potential UK vs. US style divergence; and at Talk:Comma#In English: Commas used with "Jr[.]" and "Sr[.]", for an example when there could have been a difference between registers/genres of usage. The two approaches can easily be combined, simply by grouping the sources into more, narrower subsections. Doing it this way allows one to summarize various style trends but just following the sources in different markets, and thus know which sources to cite for what when working on the article text.
  • Forthcoming style guides: Already in pre-print are new editions of Garner's Modern English Usage, the MLA Handbook, and The Chicago Guide to Grammar, Usage, and Punctuation (the closest thing to a new edition of Chicago MoS that we're likely to see until at least 2017, but it will cover almost everything we care about). For those who have not caught up on Oxford, 11 May 2016 is the release date of New Oxford Style Manual (pre-orderable now); this is the combined volume of the current editions of New Hart's Rules and New Oxford Dictionary for Writers and Editors, and a good way to save on the cost (if you already have the 2014 separate editions, you're all set, since they're the same text). The 2016 AP Stylebook comes out mid-year as always (it's of near-zero use for WP:MOS purposes, but important for articles on English writing). I'm unaware of any other major announcements in this regard, and I check frequently. Also, last month there appeared The Write Style Guide for New Zealanders: A manual for business editing as a Kindle e-book (the paper one is not worth the cost); this short book from Write.co.nz may be the only NZ-specific style guide (mostly they use the Australian ones, from what I can tell). I have yet to find one for South African English.

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:20, 7 March 2016 (UTC)

RfC: Proposal to make unnecessary spoiling clearer in the WP:Spoiler guideline

Opinions are needed on the following matter: Wikipedia talk:Spoiler#RfC: Proposal to make unnecessary spoiling clearer in the guideline. A WP:Permalink for it is here. Flyer22 Reborn (talk) 19:06, 9 March 2016 (UTC)

Gender changes and deadnaming

It is my understanding that when individuals change gender, just like in any other change of name, Wikipedia articles keep referring to individuals by the names they were known under at the relevant time in question. While this is strictly speaking deadnaming, a practice generally frowned upon by trans people, in the case of people who were doing notable things before their gender change, such as the Wachowskis, Chelsea Manning or Caitlyn Jenner, the avoidance of deadnaming when Wikipedia articles talk about their achievements while they were living as their respective assigned gender would be tantamount to rewriting history and can lead to confusing and absurd-sounding statements. Matrix was directed by The Wachowski Brothers, not The Wachowskis, let alone The Wachowski Sisters, because that's what they went by at the time in public. So I looked for a guideline I can refer to when well-meaning editors change names retroactively, but neither MOS:IDENTITY, MOS:GENDERID nor WP:TRANS? directly and explicitly address this issue, and WP:BIRTHNAME only addresses a partial aspect of this issue. MOS:BIO#Changed names comes closest, but is easy to miss and doesn't have a shortcut. It also makes the qualification "in an article in which they are not the subject", which might be prone to misunderstanding – a mechanical find-and-replace routine on trans individuals' articles to remove all mentions of their deadname would certainly be unwarranted. --Florian Blaschke (talk) 18:15, 9 March 2016 (UTC)

@Florian Blaschke: This is addressed unambiguously at MOS:GENDERID: "Any person whose gender might be questioned should be referred to by the pronouns, possessive adjectives, and gendered nouns that reflect that person's latest expressed gender self-identification. This applies in references to any phase of that person's life, unless the subject has indicated a preference otherwise." In other words, Wikipedia does not practice deadnaming, regardless of the time period being discussed. Kaldari (talk) 20:11, 10 March 2016 (UTC)
You are wrong; just search Wikipedia for "Bruce Jenner". This guideline only applies in the subject's own article. --Florian Blaschke (talk) 20:15, 10 March 2016 (UTC)
In other words, it does not apply in articles such as... Georgia guy (talk) 21:14, 10 March 2016 (UTC)
The whole idea of "deadnaming" is largely OR when applied to subjects here; only in a few cases do we have a provable and unambiguous statement from a subject that they consider their former name to be "dead" and that any use of it is some kind of stress or insult to them. The noise about this on WP is largely a matter of hype and overreaction by "allies", not TG themselves, trying too hard.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:24, 10 March 2016 (UTC)
Do you mean, a trans woman should be referred to by her male birth name for some purposes other than "don't re-word direct quotations"?? If so, what are these situations?? Georgia guy (talk) 21:31, 10 March 2016 (UTC)
Of course they should, but this isn't the place to try to create a list of every imaginable circumstance. The obvious current- events example is Jenner, who never won any sporting events as a woman or under the name Caitlyn. Our present compromise of writing something like "Bruce (now Caitlyn) Jenner" is adequate. We're not going to falsify facts and pretend that a woman namer Caitlyn won men's Olympic medals. Why is this even a question?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:26, 15 March 2016 (UTC)
Now, do you (SMcCandlish) know how experts understand transgender people?? Caitlyn Jenner was born with the wrong body, but she never was a man; she has always had her female brain structure. This is how experts understand transgenderism. Do you really think transgenderism works by arbitrarily wanting to change your gender?? Georgia guy (talk) 15:34, 15 March 2016 (UTC)
The "experts" are widely divided on this question; the idea that a TG person was born in the wrong body and never "was" their birth sex, and that this is entirely about "brain structure" (which are not even the same argument; you're mix-and-matching) are hotly debated topics in multiple fields. It is not WP's place to "pick a side" in those debates. Our own articles on the topic seem to be covering this semi-well, though with some clear biases. MOS's role within WP is to lay out style recommendations that increase reader comprehension of our material, preserve its accuracy, and reduce editorial strife.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:05, 16 March 2016 (UTC)
What other belief is common by experts?? Are there some experts who believe transgenderism works by arbitrarily wanting to change your gender?? Georgia guy (talk) 13:38, 16 March 2016 (UTC)
Reductio ad absurdum? I'll pass. Such a discussion is off-topic here, anyway. The wide variety of nature vs. nurture, genetics vs. choice, predestiny vs. gradual change, etc., arguments that range across psychology, sexology, human anatomy, zoology, anthropology, sociology, cognitive science, neurology, philosophy, gender studies, embryology, psychiatry, human evolutionary ecology, and a dozen+ other fields (plus politics, religion, and other more subjective matters) should be covered neutrally in our article. Its talk page is a good place to work on that, but even that is WP:NOTAFORUM for debate or advocacy. Anyone with any experience with real TG people knows that the individual experience varies widely as does one's approach to, feelings about, and perception of earlier life. I can't stress this enough: The attempt to impose One True Way of looking at TG is as offensive to many TG people as denying that their circumstance is real/legitimate. It's exactly the same thing as the denial of bisexuality and attempts by homosexual activists to "claim" them as "really" gay (and by heterosexuals to dismiss them as such), in the 1980s–1990s when bisexuals started to assert themselves as a collective voice and got the "B" added to GLBT (or whatever longer formulation you prefer; there are so many variants now I've lost track). It basically comes down to: X has no business telling Y what is "real" about their sexuality, and Y cannot impose their inner feelings on the matter onto every other mind in the entire world; a necessary consequence of this is that there is no one single way to approach these matters, and this is a fact we have to deal with in ways that support our encyclopedic mission, not in ways that only accept one WP:TRUTH.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:57, 16 March 2016 (UTC)
when discussing a person's achievements in a historical context, we can refer to them using a historical name.
You mean, a transgender person should be referred to by their gender of rearing when talking about old historical events of their life?? Georgia guy (talk) 22:49, 10 March 2016 (UTC)
Please do not put words in my mouth. I did not mention gender at all... I said that people can be called by historical names in historical contexts. Names do not equate to gender. It is quite possible for a woman to be named (for example) "Bruce" at one point in her life, and "Caitlyn" at another point.
The issue of "deadnaming", and the use of historic names of transgendered people was the topic of a very extensive series of RFCs a while ago... they took place here at WT:MOS, and at the WP:VPP page. Suggest you review the relevant archives, read those discussions, and familiarize yourself with the consensus that emerged from them. It will save you (and everyone else) a lot of frustration. Blueboar (talk) 01:52, 11 March 2016 (UTC)
Given that those discussions were overrun with gender-studies and language-change activist meatpuppets, those discussions didn't tell us much, other than that despite the organized advocacy, consensus was not reached for what they were pushing. I still recall a "with 'allies' like you ..." comment from an actual TG participant in that discussion at VP, which ran concurrently with attempts by the same not-really-editors, who have declared themselves others' spokespeople, to impose a new "harassment policy" that made no sense. Well, it also tells us to be on the lookout for further attempts to misuse WP as a platform for similar WP:GREATWRONGS campaigning by such special interests groups. We already have a policy against harassment, and we already have a guideline that respects asserted gender within encyclopedic limits (like don't falsify history).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:26, 15 March 2016 (UTC)
I didn't realize that the guidelines had been changed since last year. It's unfortunate that we now recommend an inconsistent approach, but I guess I'm a little late to complain. Kaldari (talk) 01:06, 15 March 2016 (UTC)
It's not like the current wording is set in stone. But attempting to adjust it tends to open cans of worms. Any proposal to do so will have to be very well-thought-out, and not sacrifice the encyclopedic needs of the project and its readers just because a certain wheel won't stop squeaking. The interesting thing is that no actual self-identifying TG editors seem to have an issue with the current guideline. Whether external activists from GLAAD like it or not is extraneous and irrelevant.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:26, 15 March 2016 (UTC)

Where are editors directed not to change the wording of quotations?

In my editing, I've encountered this many times: some article quotes a passage from a noted scholar; some WP editor gets unhappy with the wording that the scholar used and then edits the passage to fix the perceived shortcoming -- without even putting in square brackets to indicate the change.

I'm always a little shocked to see this. At least in my training you just don't change a quoted scholarly passage for mere stylistic reasons -- this is a form of lying, because the quotation marks are a promise to the reader that you really are quoting your source. If you do make a change, it's supposed to be limited to the purpose of situating a quotation in context, and you're required to use square brackets to mark the change.

Is there some place in the Manual of Style that says something along these lines? I searched and couldn't find it. We do have discussion of how to format bracketed material appearing within quotations, but that's something different (and at some level, I think, less important) than the more basic ban on unacknowledged alteration of quotations. Thanks in advance for any hints on this. Opus33 (talk) 03:05, 15 March 2016 (UTC)

MOS:QUOTE states "Quotations must be verifiably attributed, and the wording of the quoted text should be faithfully reproduced." Jc3s5h (talk) 03:25, 15 March 2016 (UTC)
But MOS:QUOTE also states, "Where there is good reason to change the wording, enclose changes within square brackets (for example, [her father] replacing him, where the context identifying 'him' is not included in the quotation: 'Ocyrhoe told [her father] his fate'). If there is a significant error in the original statement, use [sic] or the template {{sic}} to show that the error was not made by Wikipedia. However, trivial spelling and typographic errors should simply be corrected without comment (for example, correct basicly to basically and harasssment to harassment), unless the slip is textually important." I occasionally change quotes when I think the text I am adding is clearer or otherwise helpful, but I always enclose the change within brackets (unless maybe if dealing with a typo). Flyer22 Reborn (talk) 04:15, 15 March 2016 (UTC)
Concur with Flyer22. When people change quotes to use different words, without bracketing the change, it's usually because they didn't notice it's part of a quote. I've long thought that using a wrapper template for inline quotes might help. Guess I can make one, see if people like it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:27, 15 March 2016 (UTC)
Thank you. MOS:QUOTE seems to be just what I need. Opus33 (talk) 04:41, 15 March 2016 (UTC)
There's also the Typographic conformity section to consider, which does seem to permit more changes, based on the principle of whether it makes a difference when read aloud. I'm used to marking changes of case with [..], but something like Smith said "[t]he two species have been confused" isn't the approved style; a change from "The" to "the" should be made without marking it. Peter coxhead (talk) 16:16, 15 March 2016 (UTC)
That's being discussed in another thread above in more detail. Many if not most scholarly styles, and especially ones that involve textual analysis and criticism (which WP is, in gathering external source material and combining the gist, and sometimes directly quoted pieces, of it all into a new, summarizing work), don't make case changes like that without square-bracketing them. Chicago Manual of Style (16th ed.) covers this at &sect.;13.6, though it recognizes that this style is not used in all publications. New Hart's Rules (2nd ed.) basically contradicts itself at §9.3.1 (a silent change of case deemed "permissible") and 9.3.2 (corrections always go in square brackets), and doesn't draw a distinction like CMoS does between textual analysis and other fields (recent editions of Hart's have taken a wishy-washy turn, and more often describe alternatives rather than recommend one). I've encountered the use-the-brackets rule many times in the course of researching quotation punctuation matters, so I'll add this capitali[s|z]ation question to my sourcing run for Quotation marks in English (which was almost finished, but adding this will draw it out a bit). As an anecdotal point, I've habitually been using the square brackets for such changes, and cannot think of a time anyone has reverted me on it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:25, 16 March 2016 (UTC)
I'm one of the editors who would do something like Smith said "[t]he two species have been confused" when it came to the letter of a word. For example, in 2014, with this edit, you can see Pingumeister removing brackets I used. And, with this edit, you can see him thanking me for expanding the section regardless. I replied, "If you're wondering why I used brackets, it's per MOS:QUOTE, but I guess not using brackets is fine in this case." I've been slow to stop using brackets like that. Flyer22 Reborn (talk) 18:03, 16 March 2016 (UTC)
I just changed one instance with this edit. Flyer22 Reborn (talk) 18:53, 16 March 2016 (UTC)
This is why I think changing the capitalization (even with brackets) is usually bad idea :) Kaldari (talk) 23:34, 16 March 2016 (UTC)
I'm happy with the instruction not to put downcased sentence-initial letters in square brackets (unless it really is important to the original intended meaning). The Oxford guide also says to do that (and incidentally says not to use leading or trailing ellipsis points unless absolutely necessary to the original meaning). As little obstruction as possible while scrupulous attention to honesty is the way. Allowable typographical changes (silent) are another good thing, as MOS prescribes. Let's distinguish "wording" from things that need to be harmonised/translated and that will have no bearing on meaning ... dashes, weird quote marks, font, font-size, straight/curly glyphs ... these should not be explicitly flagged. Tony (talk) 03:29, 17 March 2016 (UTC)
Tony1, when it comes to the edit you made here, shouldn't the brackets be between "we obviously" since I skipped some of the commentary? Flyer22 Reborn (talk) 06:02, 17 March 2016 (UTC)

Consolidating "first major contributor" and ENGVAR, DATEVAR, etc., advice; normalizing it with policy

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Newer thread opened at page bottom; related discussion at WT:CITE  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:23, 22 March 2016 (UTC)

It's become a basically WP:PERENNIAL problem that many editors' present interpretation of WP:CITEVAR, WP:ENGVAR, WP:DATEVAR, and other FOOVARs, most or all of which have similar but inconsistent "first major contributor" rule, is leading to conflicts with policy, consensus process, and common sense. It's forgivable that this keeps coming up, because of these guideline segments' poorly constructed, mutually contradictory, and overly restrictive wording. But it's not excusable to let it continue indefinitely; this needs to be resolved.

WP:Editing (like WP:Ignore all rules) is a policy. No one needs "permission" to attempt to make an improvement, and no dispute exists until someone raises one. WP doesn't even impose a rule against bold changes to policy pages themselves, just advice that urges caution and suggests that reversion is likely without it (plus, BRD exists for a reason). Meanwhile, certain PoV-pushing or just incompetent behavior that these provisions have attempted to address can be genuinely disruptive. But that's no reason to enact mutually inconsistent and policy-violating "rules"; these need to be examined and brought back into line with actual Wikipedia norms. Guidelines reflect best practices arrived at by consensus and actual practice among the experienced editors who form the editing community; they don't try to dictate changes to them (see WP:POLICY), especially ones that don't make sense and are not workable within the existing system.

Some examples of problems:

  • The "first major contributor" rules are frequently mistaken to mean that nothing of an article-wide nature that was decided on-the-fly by the FMC, back when – who may not have even given any consideration to the matter at all – can be changed without something on the scale of an RfC. The FMC is not even in a position to show up to the discussion and say "As the FMC, what I want is...". The analysis is about and only about what was done; it's a status quo ante stability default for when consensus is failing to decide what should be done in the present.
  • Worse yet, the disparate FMC provisions are often interpreted to mean that the FMC (or by extension a wikiproject in which the FMC is participating, or the small pool of editors who pushed an article to Good or Featured level, are invested with a perpetual supervote about everything to do with "their" article; I encounter this "hands off!" view at least half a dozen times per week, in article style discussions, at RM, in arguments over infoboxes and navboxes, etc. Even the fact that ArbCom cases have affirmatively stated that wikiprojects and other insular groups of (or individual) editors cannot force their way at articles at which they claim an interest, this behavior goes unchecked, and it's due in part to the poor wording of the FOOVAR provisions.
  • It is counter to multiple policies and the foundational "mercilessly edited" principle at WP:Five pillars. It was never the intent of the FMC idea to try to set up a "first class editor" regime. It is just an arbitrary fall-back to be used if 1) a dispute arises, and 2) normal consensus discussion does not resolve it. But several FOOVARs are no longer worded this way, and have crept into legislating just such a regime.
Some cases specific to particular FOOVARs
  • CITEVAR: As just one example, the fact that Peter coxhead (and I, and many others) can change articles to list-defined references formatting without being reverted except rarely at an individual article, demonstrates that the conversion is not controversial, but routine maintenance, especially at large and complex articles. (And this is code formatting, not a "citation style"; Harvard vs. Vancouver references, etc., are citation styles, and at least in theory WP:CS1 vs. WP:CS2 are citation styles for CITEVAR purposes, though people freely mix the two without incident, and the CS1 templates now handle CS2 output.) Even from a basic logic standpoint, the "must pre-establish consensus for a change" view is faulty, since it would effectively be impossible to ever improve WP citation markup, layout and processes in any way, because all well-developed articles already have a "citation style" in the coding sense (i.e. citation formatting), and such improvements would be changing them without page-by-page "micro-consensus". Such an interpretation would make every attempt at systematic improvement stillborn (except at stubs?). This is obviously inconsistent with several additional policies, including WP:LOCALCONSENSUS, WP:CCC, and WP:NOT#BUREAUCRACY.
  • ENGVAR: If an article is written in American English for no particular reason other than who got there first, but has stronger historical ties to the UK than to the US (and not a major English dialect of its own, like Australian or Canadian, in which WP articles are written), it's entirely reasonable for someone to switch the dialect, if they do it consistently and carefully (e.g. the article on Liberia should be in American English, not British). If a dispute arises, consensus discussion will almost always sort it out. If it fails to do so, then default to the choice once made by the FMC
  • DATEVAR: If the dates in an article's citations are written in ISO style (which is a permissible style for some purposes on WP), but the rest of the article is using D_M_Y dates, there is nothing controversial about converting the cite dates to D_M_Y, unless and until someone raises controversy about it in a particular case, with an actual reason beyond WP:WIKILAWYERing. I've been making that change for years, in the course of various WP:GNOME cleanup, and only been reverted on it one time, by someone who had no rationale for the revert other than waving their hand at DATEVAR and CITEVAR, and who had various other disputes with me and was obviously just trying to hound me off "his" article.
  • I could list a more, but this outlines the nature of the issue in probably sufficient detail.
It would be of value to identify all these FOOVAR provisions that deal with "first major contributor" or "status quo ante" as a dispute resolution mechanism, and see about normalizing them with each other and with actual policy, consolidating them into a single guideline page to which all the FOOVAR sections refer and with which they are made consistent, and which took all of these issues and more into account. The number of problems their present poorly thought-out wording is collectively causing are multiplying, and they've been diverging more over time, instead of converging into consistent advice with predictable and community-desirable results.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:23, 13 February 2016 (UTC)

These rules were put in place to avoid disruption. If they are now promoting disruption, then it is time for them to be re-examined. It is like saying that my grandfather bought a Ford, my family has always bought Fords, therefore my son should buy a Ford, even if a Porsche or a Jeep or a Tesla is a better fit for his needs.
A general instruction of the FOOVAR type may be found in the second paragraph of WP:MOSNUM, which otherwise manages to avoid vagueness throughout. --Pete (talk) 19:43, 13 February 2016 (UTC)
Yeah, that might be our model text.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:39, 14 February 2016 (UTC)
It should be sufficient to make it explicit that FMC is a last resort in FOOVARs where actual dispute is otherwise deadlocked. I rewrote ukiyo-e a few years ago from scratch. I don't know or care what ENGVAR it was in before I took it on—I simply did it in CanEng, nobody disputed it, and now it's an FA. Changing the ENGVAR at this point would be stupid, pointless disruption and couldn't seriously be challenged on the grounds of FMC. Curly Turkey 🍁 ¡gobble! 22:21, 13 February 2016 (UTC)
Agreed; "make it explicit that FMC is a last resort in FOOVARs where actual dispute is otherwise deadlocked" is exactly what the intent of these FOOVARs was, but several of them have sneaked off in the middle of the night into the WP:OWN back yard and have to be tucked back in bed. We also need to account for the fact that an article can be C or even B class then fall moribund for many years. Many, many thousands of these even pre-date the existence of WP:ENGVAR, even of MOS itself. If someone comes along to some marginal non-stub than had a major contributor in 2003, we really should not give a damn if they decide to change the EngVar in a non-stupid way in the course of writing an A-class article ready for GA there, even if they did not have to start from scratch. The entire present conception of FMC/*VAR as some kind wiki-shellac is an entirely un-wiki approach. "Everything on Wikipedia is subject to change, except random style whims of an editor who retired in 2009, on an article no one's bothered with beyond minor copyediting since then"? No.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:39, 14 February 2016 (UTC)
Looking at the paragraph mentioned above, I see, "The Arbitration Committee has ruled that editors should not change an article from one guideline-defined style to another without a substantial reason unrelated to mere choice of style, and that revert-warring over optional styles is unacceptable." References are given to the pertinent ArbCom rulings. Perhaps we should gain guidance from ArbCom before reinterpreting their repeated injunction? Is it sufficient reason to reformat citations or change the English variant simply because "it looks better this way"? --Pete (talk) 23:09, 13 February 2016 (UTC)
Per WP:BRD, if it doesn't get disputed, sure. Curly Turkey 🍁 ¡gobble! 23:11, 13 February 2016 (UTC)
That's the rub, though. Several of the FOOVAR passages have drifted over time in a way that tries to "wiki-criminalize" that. Yet we don't want the principle to apply so broadly that the CanEng at the ukiyo-e article or other FAs is seen as "fair game". Explicitly mentioning that probably GA and definitely FA status is a sign to exercise extra caution, and seek consensus rather than be blindly bold, is probably the way to go here.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:39, 14 February 2016 (UTC)
Some articles are total disasters and a firm hand in rewriting top to bottom while keeping the existing sources etc. is to be welcomed rather than discouraged, I think. How to distinguish between genuine improvements and style preference mass changes could be tricky. One person with good intentions can do a lot of damage. Fully support finding a centralised policy and pointing to it from various places. Make things as clear as possible. Tidy up the jungle a little. --Pete (talk) 16:55, 14 February 2016 (UTC)
If someone reverts, it should end there per BRD. If nobody reverts, then it's not a problem, so why create drahmah over it? Otherwise we're back to Square One—are you going to report me for being dick enough to unilaterally make ukiyo-e CanEng? Curly Turkey 🍁 ¡gobble! 21:59, 14 February 2016 (UTC)
Hmm, well, it might well not end there. BRD's just an essay, and if someone takes a miserable, PoV stub, and works it into a solid B-class article full of well-sourced information, and the PoV-pushing stub author reverted, I wouldn't expect BRD to be followed. I've done this many times myself, and I always normalize to whatever English variety seems to match the subject better. So, no, no one should "report" or revert you for imposing CanEng on an article about a topic that doesn't have any strong ties to any English variety. (W/r/t Japan, the only reasonable case I can think of is that Okinawa articles should maybe be in AmEng, because of the strong and long-term American presence there, including American ESL programs. But that "tie" argument wouldn't apply to articles on Okinawa's pre-modern history/culture.)
(edit conflict) No, we don't need to go ask ArbCom; they wouldn't hear the case anyway. ArbCom does not set WP:POLICY (including guidelines), they only interpret extant policy, and only to resolve behavioral problems, not content disputes (including internal content disputes in projectspace). It's our job to craft the policy in a way that is internally consistent, is common-sensical, and takes ArbCom's hint when it comes to what disputes rise to case level and thus should be forestalled if possible. That's why I'm being explicit here that the *VAR guidelines need to be consolidated and repaired, not eliminated. It would throw the baby out with the bathwater to have some RfC to remove these rules, or pull the intended teeth out of them, just because some problems have come up. They just need to be steered back toward their intent, and kept there. The best way to do that is to centralize one defining rule, and then have only applied interpretations of it at all the ENGVAR, DATEVAR, CITEVAR, etc., loci. I would suggest that WP:RETAIN is the right shortcut for this, and that it should live in the main MOS, as a top-level section, with ENGVAR being a subsection of it, and cross-references to all the other *VARs, which would be tweaked to conform with the consolidated wording. None of them should be laying out new "rules", only circumstantially applying the one rule.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:39, 14 February 2016 (UTC)
I can see that it could be valuable "identify all these FOOVAR provisions that deal with "first major contributor" or "status quo ante"" and consider which are best phrased or embody best practice. It might not be necessary to normalise all of them or consolidate them into a single guideline. A single guideline that covered all the FOOVARs might turn out to be rather complicated to write and to introduce, and it might be enough to focus on bringing best practices and phrasings into the most problematic FOOVARs. Could we simply start with identification and review before deciding on the appropriate action, and not ask people to sign up for the whole program you've outlined in advance? NebY (talk) 15:14, 14 February 2016 (UTC)
Sure. What I mean by centralization and normalization (as I outlined just above in a different post in this thread) is specifying the general rule in one place: what the nature of the problem is, the steps to take, definitions, in what sorts of situations the principle applies and when it doesn't, etc. Then ensure that the separate *VARs on various pages are not divergent from it and each other, and no more redundant than is absolutely necessary. The contextual details would live there; we're already really good at summarizing the gist in MOS proper and leaving it to subpages to flesh out the nitty-gritty bits. WP has worked out a system of laying out a rule in one policy or guideline page, then explaining its topical/situational applicability in others, with a cross-reference to the main rule and not trying to WP:POVFORK various competing rules. This serves us well, and it is long overdue to be applied here. Very bad things happen when we do not (e.g. when incremental POV-forking of capitalization rules in about 6 different guidelines led to an eight-year-long dispute about the capitalization of common names of species). So, let's take steps to ensure that doesn't happen again.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:39, 14 February 2016 (UTC)
Thanks - it's a very interesting idea and I think I understand it better now. Should we collate all the existing *VARs onto a single page for comparison and discussion? NebY (talk) 20:08, 14 February 2016 (UTC)
@NebY: Certainly, or just do it here and use {{collapse top}} and {{collapse bottom}} around them. If we need to sandbox with them we could do that on a sub-page of this talk page, to we don't keep triggering everyone's watchlist. I think there are at least 5 of these sections, squirreled away in various places.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:49, 16 February 2016 (UTC)
Done, in heading. I'm skeptical anyone reading this is unaware of the use of "*" as a variable, or can't figure out that FMC = 'first major contributor", so that should probably be sufficient, no?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:31, 21 February 2016 (UTC)

I suggest that driving around Wikipedia, looking for articles to convert to your favorite style, with no particular interest in the long-term well being of the article, is inherently antagonistic, and is the kind of behavior that the ARBCOM rulings are directed against. The guidelines should continue to discourage this behavior.

Also, I maintain this is the wrong forum to discuss CITEVAR. Jc3s5h (talk) 12:16, 3 March 2016 (UTC)

  1. I don't think anyone here is seriously proposing such an annoying road trip
  2. I really do think that SMcCandlish's idea to centralise discussion is excellent and his exposition of the present problems powerfully persuasive. If this is not the optimal place for such a centralised discussion, where is, please? BushelCandle (talk) 19:54, 22 March 2016 (UTC)
Well, the discussion is in fact forked; both pages are hashing out the same questions. Politics. Anyway, I"m going that this entire thread, since don't need THREE open.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:23, 22 March 2016 (UTC)

First, finding them all

These are the ones I remember at nearly midnight, off the top of my head. Please flesh out the list.

Also with wording that may be implicated:

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:58, 26 February 2016 (UTC) Updated.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:03, 21 March 2016 (UTC)

Side discussion about citation styles

Stale
 – Discussion died off.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

@ McCandlish you wrote above "Peter coxhead (and I, and many others) can change articles to list-defined references formatting without being reverted". I'd revert such a change because they are nasty, and complicated, both for new editors to understand and for experienced editors to maintain. The problem is that once articles get up into the hundreds of citations: does one add a citation to the bottom of the list (although they support text is inserted into the middle of the article), or does one maintain the list in alphabetic order? What does one do to the list when a paragraph is moved from one section down to another? How does one deal with one book that is cited many times with different page numbers pages? etc etc!

Using short references with an ordered list of long citations in a references section is much easier to maintain and more intuitive for editors new to Wikipedia citations. -- PBS (talk) 23:19, 2 March 2016 (UTC)

@PBS: how references are best laid out in wikitext depends very much on the length of the article, how much in-paragraph referencing there is, etc. There's no perfect solution. "Standard" in-wikitext references are fine when most references are at the end of whole paragraphs; list-defined and "sfn" references with a bibliography are better for heavy in-paragraph referencing. If by "short references" you mean "sfn"-type ones, even they make maintenance difficult once urls are present: look at the wikitext of Asparagales#Pre-Darwinian, for example. Replacing {{sfn|ps=none|Adanson|1763|loc=[http://www.biodiversitylibrary.org/item/6958#page/596/mode/1up Liliaceae: V Asparagi pp. 51–52]}} with something like <ref name=Adan63pp5152/> would make life much easier for later editors (not that I would dream of changing Michael Goodyear's wikitext!).
The real issue is that we all have our own ideas of what makes an article much easier to maintain and more intuitive for editors new to Wikipedia (citations or whatever). However, we don't really know; what research has been done? I would be amazed if {{sfn|ps=none|Adanson|1763|loc=[http://www.biodiversitylibrary.org/item/6958#page/596/mode/1up Liliaceae: V Asparagi pp. 51–52]}} could be shown to be easier than <ref name=Adan63pp5152/>, but I may be wrong. Peter coxhead (talk) 07:21, 3 March 2016 (UTC)
Well, since I'm being called out here - yes I do find maintenance much easier with {{sfn}} and a bibliography. And perhaps more to the point, more portable to over lapping or related articles. But I do agree that sfn's that are not that short if they include a section title and a page link present a different challenge and I'm always looking for ways to make them shorter. Maybe some citation style that allows one to blend the two in one template? Parenthetically, I agree with all the comments here about people who drive around changing citation styles for the sake of it, without any obvious benefit to the end user. I have also encountered the hands-off phenomenon, having been sharply informed my style was not WP, without justification. On the other hand with articles otherwise in good shape, I am usually careful to inspect and respect the existing style, although Peter and I have had our differences at times, and we can and should all learn from each other! --Michael Goodyear (talk) 18:26, 3 March 2016 (UTC)
(edit conflict) I'm skeptical this is the place for an in-depth discussion of the merits of different citation styles. I don't know of many editors that that have PBS's difficulties with LDRs. What order to put them in a matter for consensus at the talk page, to the extent anyone cares, and would be easy to figure out simply from looking at them. It doesn't pose any difficulties for noobs, because they can simply insert the citation where ever they want, and if anyone cares to maintain the LDR format, they can move it later. The software does not care. Two-section, split-up referencing with {{sfn}} is actually much more difficult for new users, and even for many old hands. I've been here ten years and it still gives me fits. So, obviously this is entirely subjective, either way. And the {{sfn}} system is not the only way to deal with sources that have to be cited numerous times in the same article; {{rp}} is much simpler and easier (some people just don't like it because it makes the rendered superscript citation note longer). But it's all a moot point; Peter and I were not talking about converting pages that use the "short citations" system ({{sfn}} tags linking to a first section of short citations in turn referencing a second list of longer ones), and turning that into LDR. Rather we're talking about pages that just use inline <ref>{{cite journal| full citation details here }}</ref> in mid-paragraph, and a plain <references /> or {{reflist}} in a single references section (or an article with slopping, un-<ref>ed, untemplated attempts at sourcing). It's actually almost unbearably tedious to convert the "short" references system to anything else, and it's not what we were talking about. So, there basically is no PBS vs. SMcC & Pc citation style dispute to be had here. Hooray for that!  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:06, 3 March 2016 (UTC)
Peter, I did not suggest using {{sfn}} or any of the other templates when using short citations--all that is needed for most short citations is {{author year, page-number}}. Personally I do use the {{sfn}} templates, but they are by no means essential. As to the hyper links question, I place them into the long citation in the references section (which may or may not use {{citation}} or {{cite book}} style templates. I do this to keep the short citations as short as possible, precisely to avoid cluttering up the text with confusing and bulky url strings, which make paragraphs harder to read in edit mode.
Over the last weekend, I ran an AWB script over pages that contain the {{EB1911}} template that contain certain parameters. When I run such an AWB script it often takes me off into what for me are byways, looking at hundreds of pages outside the articles I usually see via my watch list. In this case, one that I viewed and changed was New York City, which has many paragraphs that are very difficult to read in edit mode because of the long (mostly templated) citations embedded into them, and while I agree that such an article would benefit from a clean-up of the citations, I do not think that using list defined references is the best way to solve this issue, because it would moving 500 citations into what would be a list that is difficult to maintain.
You did not address any of the points I raised against lists, and in fact I think you pulled in an example of a problem when you introduced <ref name="Adam63pp5152">. That is fairly clear name tag (although personally I would name tag it slightly more clearly (see below)), but it raises two issues:
  1. I have seen articles where the name tag selected has been sequential eg: <ref name=GG2-B-01>, <ref name=GG3-H-06>, <ref name=GG3-H-08> <ref name=GG3-H-09, <ref name=GG3-H-10> etc[2]. This makes maintenance more difficult, leading to the need to introduce guidance on how to make the tags meaningful in the context of use within the body of an article. No such additional guidance is needed with short citations as they are self documenting by simply adding the recommended visible information. Although I do acknowledge that with inline short citations (as with inline long citations) that are repeated, and are not using {{sfn}} they may have named ref..tags that are not meaningful, it is unusual for an inexperienced editor to be tempted to name them sequentially.
  2. In the example you gave <ref name="Adam63pp5152"> what do you put into you list when there are other references to the same book, but to different pages (eg <ref name="Adam 1763,p. 101">), do you include a full citation to the book in your list each time a new page is cited, or do you start to use short citations in the list, or (shudder!) do you use the template {{rp}}?
I do think that list defined references can be useful, and I sometimes use them in conjunction with {{notelist}}, because it allows bulky footnotes to be moved out of the text where they can be confusing when viewed inline (eg see the article Battle of Berlin), but for inline citations, I think that lists are needlessly complicated and difficult to maintain.
@SMcCandlish you wrote "It doesn't pose any difficulties for noobs, because they can simply insert the citation where ever they want, and if anyone cares to maintain the LDR format, they can move it later. The software does not care." If the citations are not added to the list in a know sequence, how does one easily spot duplicates when there are hundreds of citations (as in New York City (which currently has duplicates))? With an alphabetical author list in a References section duplicates are obvious and can be eliminated. The References section also acts a useful bibliography, something that an list generated by {{reflist}} is not so easily perceived to be.
-- PBS (talk) 13:25, 3 March 2016 (UTC)
As far as urls in sfns go, that is one of the reasons I have switched to listing chapters seperately from the overall work --Michael Goodyear (talk) 18:31, 3 March 2016 (UTC)
As noted above, this is a side issue, and we're getting away from the original point (I plead guilty to helping!). We all have our preferred way of handling references, and it's not useful to discuss these here, I think. The original point was about taking full references out of wikitext, whether this is to a list-defined reference or by using a "Notes+Bibliography" approach, both of which are useful in appropriate contexts. I can't see why moving a full reference should ever be frowned on: given that a short form will be present in the wikitext if the reference is used again, why could it ever be a problem that the first use is only present as a short form? Peter coxhead (talk) 13:45, 3 March 2016 (UTC)
Personally, I prefer approaches that put the full reference in a different section from the text. But I imagine that those who like the full reference mixed in with the text would argue that they only have to edit one window rather than two, if a new full reference is being added. Jc3s5h (talk) 14:13, 3 March 2016 (UTC)
The eventual solution will be to store all this in wikidata, after we have better tools, that give us citation info in a pop-up or something. Anyway, I would respond to several of the points addressed to Peter but should let him do so first if he wants. As to the question asked of me: Duplicate cites are not a problem limited to LDR (I was cleaning up a forest of them only the other day in Anna Sui). It's just a manual cleanup thing, and it really doesn't matter much. It's not a serious problem, either at the volume of incidence level, or in magnitude of effect level. It's actually still policy-compliant sourcing, it just adds redundant code and redundant output for the user. Of all WP's sourcing problems, it's near the bottom of the list. It's best handled (at least as to identification) by bots, looking for duplicate URLs, duplicate work titles with one or more duplicate author parameters, etc. That said, yes, I prefer alpha order in LDRs for the reason you give (and to make finding and editing them easier); I was not suggesting I'm opposed to that in any way. There's simply no policy requirement that anyone adding a citation has to follow that or any other sourcing style matter. That's all I was saying. So, no matter what the sourcing style is, people will always just paste URLs in, in situ, and we always just have to deal with it later. No citation style is better or worse in this regard. Well actually the "short" (actually, long, in two senses) two-section system is actually worse, because pasted-in situ cites will always appear in the first section for short cites, and have to be even more painstakingly recoded than they would be in the un-forking systems.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:45, 4 March 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.

Better coding: Another digression

Stale
 – Discussion died off.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Side comment on the side thread: The above bits about how some name= values in ref tags are easier to parse that others, and thus editors are apt to change them, is one reason why they should always be given in the form <ref name="foo">, not <ref name=foo>. If someone changes this to <ref name=foo bar>, even MediWiki will not handle it properly. It is a wrong to presume that noob editors are all XML experts and understand that an XML value with a space in it must be quoted; most of them probably don't even know what XML is. Another reason is that it's actually invalid XML to not quote any value that does not consist entirely of numerals; <ref name=foo> is a code portability problem for WP:REUSErs, even if MediaWiki's parser itself does not barf. Another such error is doing <ref name="foo"/> instead of <ref name="foo" /> (same goes for <br> and <br/> → <br />). The <ref name="foo" /> format is always correct, 100% of the time. A similar thing is that <tt>...</tt> no longer exists in HTML; use semantic tags like <code>...</code> (or <span style="font-family:monospace;">...</span> if it's purely presentational/decorative with no semantic meaning). "It looks fine in my browser" (i.e., because the MediaWiki installation on en.wp is configured to compensate on the fly before generating the final HTML) is not good enough. WP is increasingly, not decreasingly, having its material re-used by others, in ways we do not anticipate, and we should not make this a buggy and frustrating exercise just because we're sloppy coders. I fix these problems on sight, but people need to stop creating more of them.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:02, 4 March 2016 (UTC)

I made a comment disagreeing with some of the above at WP:BOTREQ#Replacing the <tt> element; I'll add that <ref> isn't XML so your choice to apply the rules of that language to <ref> doesn't make for a convincing case that everyone must do so. --Izno (talk) 13:25, 4 March 2016 (UTC)
Why do you think it's not XML?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:15, 6 March 2016 (UTC)
@SMcCandlish: see Special:Version#mw-version-parser-extensiontags and Help:Strip markers, which lists the "XML-like" tags used by the MediaWiki software. The ref tag is not XML; it just looks like it. Hence it does not have to follow XML syntax. Peter coxhead (talk) 13:32, 6 March 2016 (UTC)
This seems like hair-splitting and over-interpretation. Internally, it may not be being processed as XML, but it's still in XML form, so any external reuse outside of MediaWikia will expect it to follow the same syntax, and it does for a reason. It's obviously so close internally that even <ref name=foo bar /> (no quotes) breaks. Another way of looking at this: If we're being careful to not write 1997-style garbage code in every other way, it makes no sense for us to just say "this particular tag is an exception – go head and be really sloppy and inconsistent, even if external tools will probably choke on it." Given how many people are convinced that WP isn't reliable for bupkuss other than lists of sources to re-use, I find it implausible that people are not trying frequently to write tools to take our citation and convert them to something else, like their own preferred citation DB format. No reason to make this more painful for them. I guess if we had a bot doing auto-cleanup, it wouldn't matter; people could be (temporarily) sloppy. Another reason that we should bother (either personally or with a bot) is that if people see sloppy ref coding it will inspire them to be sloppy about other coding. This is already obviously the case, so the answer is, equally obviously: If it looks like XML or HTML, treat it like it is.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:07, 6 March 2016 (UTC)
Unfortunately, it's more complicated than you imply. Take the br element:
  • In "old" HTML, only <br> is correct.
  • In XML and hence XHTML, <br/> is well-formed, as is <br />. The latter is recommended purely to support legacy user agents, and is probably much less necessary now.
  • In HTML 5, <br/> and <br /> are not well-formed; void elements like br must only have a start tag and must not have an end tag/marker, so only <br> is well-formed. (See here.)
Hence I think it's harder to know what to recommend than you imply. In reality, any tool to extract information from wikitext will have to be able to cope with all kinds of variability. Peter coxhead (talk) 18:05, 6 March 2016 (UTC)
Way to strawman there. It's normal in discussions to point out inaccuracies--since your broader point (that we should mark it up in such and such a fashion) is predicated partially on the inaccuracy, I pointed out the inaccuracy. I happen to agree with you that in the general case we could or should recommend that it be marked up in an XML-like fashion, but this is only due to the fact you present: that ref name=a b only catches other refs named ref name=a and not the intended ref name=a b. I otherwise agree with Peter (save the statement that they are not well-formed when they include the slash; see bullet Start tags item 5 of provided specification: Optionally, a "/" character, which may be present only if the element is a void element., which implies <br/> is a valid Html 5 tag). --Izno (talk) 13:24, 7 March 2016 (UTC)
Right. A few billion pages would be invalid if <br /> were not well-formed in HTML5. I have my issues with W3C and WHATWG, but give 'em some credit. :-) Anyway, I'm not trying to straw many anyone. My point is that if the parser so perfectly emulates XML behavior that it chokes on things like unquoted attribute values with spaces in them – something it very easily could have been written to compensate for – we should just treat it as XML. It's clear that they're engineering this to behave as if it were. At some point an emulator effectively is what is it emulating. What I meant by hair-splitting and over-interpretation is that the difference is philosophical not practical. Maybe I should not have brought this up here; MoS peeps never seem to want to do anything to establish code style standards, despite the fact that many editors want them and that some de facto ones have already clearly evolved. Maybe we should establish that in Help: namespace or something.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:31, 7 March 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.
FYI
 – Pointer to relevant discussion elsewhere.

Many of the problems pointed out in the [original] thread here have come to a head at Wikipedia talk:Citing sources#Instruction creep in WP:CITEVAR, implicating at least 4 policies in these *VAR and *RETAIN provisions.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:56, 6 March 2016 (UTC)

Moving forward

I'm going to open a new thread at #Cleaning up and normalizing MOS:ENGVAR, WP:CITEVAR, etc. about next steps; the archiver bot seems to want to put this old thread away, which is fine.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:22, 22 March 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.

Formatting numbers and the decimal marker

I would like to suggest Wikipedia adopt the ISO (International Standards Organisation) standard for numbers in English Articles. In effect since the 22nd CGPM (2003, Resolution 10) (General Conference on Weights and Measures), this is a standard published by the International Committee for Weights and Measures BIPM (French: Bureau International des Poids et Mesures), The NIST (National institute of Standards and Technology) in the United States and various other standards agencies in the world. A list of the 57 countries that have adopted this standard are listed here: http://www.bipm.org/en/about-us/member-states/ [1]

Basically, it makes the Point on the line or the Comma on the line the decimal separator in all numbers and stipulates that that each 3 digits be separated by a small space and not a comma to facilitate reading. In Microsoft Word this is accomplished by holding down shift and then hitting the space key. This keeps the numbers sequence together. The format applies to numbers either side of the decimal marker.

Example: 9 123 456,789 12 Shown in the BIPM brochure on page 133, paragraph 5.3.4 [2] and in the NIST brochure page 42 paragraph 5.3.4 [3].

The text from the BIPM publication is:

5.3.4 Formatting numbers, and the decimal marker

The symbol used to separate the integral part of a number from its decimal part is called the decimal marker. Following the 22nd CGPM (2003, Resolution 10), the decimal marker “shall be either the point on the line or the comma on the line.” The decimal marker chosen should be that which is customary in the context concerned. If the number is between +1 and −1, then the decimal marker is always preceded by a zero. Following the 9th CGPM (1948, Resolution 7) and the 22nd CGPM (2003, Resolution 10), for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer. For numbers in a table, the format used should not vary within one column.

Presently the Wikipedia Manual of Style [4] recommends the comma as the grouping symbol and the decimal marker as the period/full point which is at odds with the above international standard. This leads to confusion when read by English readers in countries where this is not the norm. The standard was adopted in South Africa in the 1970’s (I lived there then) and is widely used. However most people elsewhere seem unaware of the standard. The SI allows the unit symbol to change every 3 digits; pico, nano, micro, milli, (unit), Kilo, Mega, Giga, Tera, etc., etc. [5] uses the same 3 digit grouping.

My recommendation is that Wikipedia MOS adopt this International standard and completely delete the Grouping with Commas and allow the decimal to be a comma or a point on the line. Grouping by fives should not exist unless someone can show me an international standard for it. Avi8tor (talk) 11:07, 20 March 2016 (UTC)

References

  1. ^ http://www.bipm.org/en/about-us/member-states/
  2. ^ http://www.bipm.org/en/publications/si-brochure/
  3. ^ http://www.nist.gov/pml/pubs/sp330/
  4. ^ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers#Decimal_points
  5. ^ http://images.google.fr/imgres?imgurl=http%3A%2F%2F4.bp.blogspot.com%2F_wovX12shpLo%2FTJrXV-gwFJI%2FAAAAAAAAAAM%2FdQpnSEMvgZk%2Fs1600%2F600px-Prefixes.png&imgrefurl=http%3A%2F%2Fjsmbchemistry.blogspot.com%2F2010_09_01_archive.html&h=312&w=600&tbnid=hIoLEKiXkQu3BM%3A&docid=66ut6OBIRcDiyM&ei=p2_sVt3hMof7afT7pOAO&tbm=isch&iact=rc&uact=3&dur=529&page=1&start=0&ndsp=22&ved=0ahUKEwid0erVk8vLAhWHfRoKHfQ9CewQrQMIITAB
  • Oppose - since the vast majority of our readers still use the traditional presentation, adopting this standard will cause more confusion than it will resolve. Suggest that we revisit in a few years, to see if common usage actually changes.
    "My car gets 20 rods to the hogs head, and that's the way I like it." - Abe Simpson. Blueboar (talk) 14:41, 20 March 2016 (UTC)
  • Oppose. I might reconsider after
    1. When the ISO publishes a standard that isn't meant only for megaorganizations, they sell it at a reasonable price AND
    2. NIST at least get the rest of the federal government to follow their recommendations; if their own government ignores them, we should too. Jc3s5h (talk) 15:12, 20 March 2016 (UTC)
  • Strongly oppose permitting a comma as the decimal marker. This would be very confusing in an English encyclopaedia. Very strongly oppose anything like "The decimal marker chosen should be that which is customary in the context concerned." --Boson (talk) 15:46, 20 March 2016 (UTC)
  • Comment: As I understand it, use of thin spaces is currently permitted, but might present accessibility problems. --Boson (talk) 15:46, 20 March 2016 (UTC)
  • I'm not sure what you're proposing exactly, but I'd be all for removing both comma and point as separators and only use a thin-space. That way, there can be no confusion. -- [[User:Edokter]] {{talk}} 16:01, 20 March 2016 (UTC)
  • Support - with the understanding that in the English context the decimal marker is the point. Never having commas avoids any chance of misunderstanding them as decimal markers.−Woodstone (talk) 16:48, 20 March 2016 (UTC)
  • Oppose This is the English Wikipedia, not French. And haven't we been through all this before? --Redrose64 (talk) 19:57, 20 March 2016 (UTC)
  • Support
    Blueboar states: “The majority of our readers use the traditional presentation” I must have missed that survey, when is the next one? Do Wikipedia readers presently have a choice? The Wikipedia Manual of Style makes the choice mute, hence the suggestion.
    Jc3s5h states: the standard is published for only megacorporation’s. Is there some citation for this statement? The standard has been adopted by consensus by 57 countries, for ordinary people, it’s a national standard apparently in all English language countries, I myself have been using it since 1980 (36 years) without realizing it was a published international standard. It makes a lot more sense; it is easier to read large number. It avoids confusion between the use of the decimal point or the comma. If someone from South Africa read the number 1,234 he might think it was “1 point 234” whereas someone in the UK might think it’s 1 thousand, two hundred and thirty four. Hence the recommendation. I am frustrated by the computer industry giving extremely long numbers that took 30 seconds to comprehend whether it was mega, giga or terabytes they were stating. For a couple of years there was a sign in Aspen Colorado that for 10 years I thought stated “Airport 2 miles”. What it actually said was .2 miles. I totally missed the leading zero (which was missing) and the small faded decimal point. I imagine many people thought the same. If it had been a comma with a leading zero I might have seen and understood the sign completely. This is why we need this standard.
    Boson, The comma as a decimal marker is used in many cultures and my billions of people. ISO standards are reached by consensus to simplify interpretation. Roman numerals were customary in Europe for about 700 years after Arabic numerals were introduced into Europe. Now that Arabic numerals are the norm, try doing math in Roman numerals. We have to adapt to more rational ways of presenting numbers.
    Woodstone, never having commas as the divider for every 3 digits would obviate any confusion whether or not the decimal marker was the point or the comma.
    Redrose64, this is a standard adopted in 10 English speaking countries up to 35 years ago, it has nothing to do with the French, have we been thru this before? Can you provide a link?
    A thousand years ago, there was no punctuation, you had to read and interpret the written word. Numbers were Roman numerals. Times change and humans adopt new standards. The SI has now been adopted by every nation on the planet, even the USA, https://www.law.cornell.edu/uscode/text/15/205b hence System International. It is difficult to change the direction of a ship the size of the USA, especially when individual members of congress work to undermine laws that have been passed by the entire congress and signed into law by the president.
    Wikipedia should adopt this for its Manual of style precisely because it's an international standard.
    Avi8tor (talk) 14:11, 22 March 2016 (UTC)
    External organizations do not tell us what we may or may not do. We write for our reader base, period. We often adopt technical standards, but only when they do not conflict so sharply with common writing practices as to produce a "WTF?" reaction in most readers. PS: The comma a decimal separator is irrelevant on English Wikipedia (except in direct quotations of non-English material). PPS, re: "I must have missed that survey" – Don't be a hyperbolic smartaleck. We know our user-base well. If we do things that don't make sense to them, they "fix" it whether it's broken or not. "Surveys" would be completely superfluous.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:16, 22 March 2016 (UTC)
    @Avi8tor: This comes up at WT:MOSNUM every few months, so we certainly have been through it before. See for example Wikipedia talk:Manual of Style/Dates and numbers/Archive 151#Grouping of digits; Wikipedia talk:Manual of Style/Dates and numbers/Archive 149#Display resolution consistency (or not?); Wikipedia talk:Manual of Style/Dates and numbers/Archive 149#Rounding to 3 decimals after the point -> possible confusion with thousands separator. We must not disregard accessibility, see for example the comment by Graham87 (talk · contribs) at Wikipedia talk:Manual of Style/Dates and numbers/Archive 148#Use of spaces for grouping digits and screen readers. --Redrose64 (talk) 10:56, 23 March 2016 (UTC)
  • Oppose for now, but there are potential compromises (one not available yet, and one templated). Firth the "no": This format is unparseable, confusing gibberish to the vast majority of en.wiki readers, surely well over 90%, unless this format is being taught in schools in the UK, US, Canada, Australia, etc., today, which I doubt very seriously. Many people very literally have no idea what it means, and will believe it to be a string of unrelated, discrete numbers which an unknown relationship.

    Now the first "maybe": If this can be reduced to hair-spacing – hair space character between these pipes | | – so that the numbers are grouped much closer together, the likelihood of confusionis at least an order of magnitude lower, yet the intended effect of digit grouping preserved. A thin space – | | – is not good enough; it renders exactly or almost same size as a regular space in a large number of fonts. The problem: As of 2015 some browser/OS combinations still in common use were not rendering the hair space character, despite it having been in Unicode for years, and giving a garbage character instead. This is obviously not acceptable output. I know for a fact that this was the result, because I used this character between the em dash and the speaker/author name in citation templates and got multiple complaints before I was even done putting it in all of them. I'm extremely skeptical this situation has changed in 8 months or that it will in two years. But ask again in 2018. If we can do it then without impacting a significant user population, we can try it out and see what the reaction is.

    Second "maybe": In the interim, we can use a template that accepts input like {{foo|939|239|235|012|.|390|239|78}}, and it can use CSS to kern the digit groups to hair-spaced width. I would be surprised if this template doesn't exist, but also surprised if it's not using full width spaces, and confusing the living #$%@ out of many million of readers.

    TL;DR version: Technologically and sociologically too soon.

    PS: I can't see us ever adopting the comma as the decimal point. This simply is not English usage.
     — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:16, 22 March 2016 (UTC)

    Re interim, {{val}} can do that, except smarter. --Izno (talk) 17:29, 22 March 2016 (UTC)
    Nice.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:59, 22 March 2016 (UTC)
  • I've been using the space in Microsoft Word and Excel since they came out so Microsoft must be using code for it. As I mention previously "Shift + Space" in Word will give you a space that will keep digits together so the digits keep together. In Excel go to Format cell, number and check the box with Use 1000 separator. I forget when Microsoft office came out but obviously Microsoft was aware of this standard from the beginning, and I've been using it since the early 1990's or over 20 years. Note that most all programs default to American standards on paper size, margins, etc. I set up my computers Control panel>Clock language and region>change_the_date,_time_or_number_format>additional settings to give the decimal symbol as the comma and the digit grouping symbol as the space. This format only shows on my computer. When a spreadsheet is read on another computer it defaults to their format.
  • As for English speakers, My father was using the comma format in the 1980's, he was an engineer in South Africa, this is when I found out about the standard, so obviously many other English and Afrikaans speaking South Africans were using it, probably Australians also. Realise the English content on Wikipedia is read by people in countries that have adopted and presently use this number format.Avi8tor (talk) 08:19, 23 March 2016 (UTC)
  • Support space separators: the only downside I can see is the unlikelihood of wide adoption. Is there a template for autoformatting? Curly Turkey 🍁 ¡gobble! 09:11, 23 March 2016 (UTC)
  • Oppose for accessibility reasons, as noted above by Redrose64. The spacing templates that don't present accessibility problems would be very difficult to use for new users. Graham87 14:10, 23 March 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Archive_180&oldid=1137418921"