Congratulations to all the contributors to today's featured article. You deserve a lot of applause, recognition and appreciation. What a interesting and wonderful article.
Trying to explain why your edits on Casino Royale were reverted (not by me, I am slow but would have done the same thing.) Fixed image sizes are not good because readers have different devices and different preferences. If you have to change image size, use "upright="multiplier, for example upright=1.2, for an image a bit larger than normal. Exceptions are userboxes and infoboxes. -- Gerda Arendt ( talk) 12:04, 13 April 2015 (UTC)
Thank you for the message, i am trying to remove some disturbing data from the article named Islam, writer should know that there is no concept of painting in photos in ISLAM, By posting such things in the wiki articles can create some serious troubles to the Muslims, and can confuse the readers kindly have a glance on the Painting in the Article.
Really, I think we could engage in open debate until our star burns out, without changing anyone's mind. As I indicated in my last comment, we will need a tie-breaker in the form of expert opinions or an RfC. If it's RfC, I'd suggest saving your debate for that. Even then, you should state your position clearly one time and keep further comments selective and brief, lest the discussion become so large that no new arrivals have the time to read and comprehend all of it. I write this only because I know you to be receptive to suggestions (most newer editors believe they already know everything they need to know). When I find some time I'll find a good barnstar for you. ― Mandruss ☎ 12:36, 16 April 2015 (UTC)
![]() |
The Excellent New Editor's Barnstar A new editor on the right path | |
Amazing progress as an editor in only 40 days, eager to learn and to collaborate, keeps a level head in a debate, committed to improving Shooting of Walter Scott. A promising editing future. ― Mandruss ☎ 17:16, 16 April 2015 (UTC) |
WP:NOCONSENSUS In discussions of proposals to add, modify or remove material in articles, a lack of consensus commonly results in retaining the version of the article as it was prior to the proposal or bold edit. However, for contentious matters related to living people, a lack of consensus often results in the removal of the contentious matter, regardless of whether the proposal was to add, modify or remove it. Jim1138 ( talk) 00:48, 17 April 2015 (UTC)
Greetings Nøkkenbuer! I made some changes with respect to the linking at article Buer. I was wondering if you are familiar with MOS:LINK? Especially the subsections WP:LINKSTYLE and WP:SEAOFBLUE. Anyway, I try to explain in concise :-) See, if we want to link, let's say, a place called "Riverside, California", instead of linking to both [[Riverside]] and [[California]] separately, we should link to either [[Riverside, California]] directly or through a pipelink [[Riverside|Riverside, California]]. That's WP:LINKSTYLE in a nutshell.
According to WP:SEAOFBLUE, we shouldn't place separate wikilinks one next to another, but use a more specific one instead. For example, if we have three locations: "Upper East Side", "Manhattan", and "New York City", instead of linking to all three separately ([[Upper East Side]], [[Manhattan]], [[New York City]]), we should link to the most specific one, which is "Upper East Side" ([[Upper East Side|Upper East Side, Manhattan, New York]]) in this case. I know, that overlaps greatly with WP:LINKSTYLE. That was my own example though, and maybe not the best one. The manual of style uses [[Ireland|Irish]] [[Chess]] [[Champinship]] instead.
Anyway, I think the whole idea of those rules is to help the readers to distinguish between the relevant and the overtly-general ones, and enable carefully selected linking. For example, in the article Buer, [[Blessed are the Sick]] provides lots of information, whereas [[LP record|LP]] doesn't even discuss the theme, Buer. Well, that's just my own pondering though, but... :-)
I would be happy to answer any questions you might have though! Happy weekend and cheers! Jayaguru-Shishya ( talk) 17:17, 17 April 2015 (UTC)
Let's move this here, as we're cluttering a public space with a one-on-one conversation.
Here's why removing all unnecessary spaces from a citation is a bad thing. It's about the number of opportunities for natural line breaks in the edit window. When there are no "extra" spaces, the software is more often forced to split a parameter value at the end of a line. This is usually a URL in |url=
or |archiveurl=
, because they are very long values with no imbedded spaces. URLs are less likely to be split at the end of a line if they are allowed to begin at the start of a line. A split URL is harder to read and to work with.
Just from observation, it seems many editors don't care about that issue, or about anything regarding coding of citations (or about anything regarding coding, as long as it works from the reader's perspective). This is the Whutever editing philosophy.
Those who care no doubt often come from the programming world, as I do, and they have varying ideas and personal preferences. The one I and some others subscribe to is one extra space before each pipe character, and no others. Thus (1) there will be an opportunity for a line break before each parameter, and (2) no parameter value will be separated from its parameter name. There will never be a line break between a parameter name and its preceding pipe character, which is in keeping with the output of the {{
para}}
template as in the second paragraph above.
There are other citation-related personal prefs as well, like whether to use |author=
versus |first=
and |last=
. This one falls into the category of things that affect what the reader sees, and therefore should be consistent within an article. For these things, one's personal preference has no bearing except when they create an article and get to choose its local conventions.
Other personal prefs have no effect on what the reader sees, such as the choice between |newspaper=
, |work=
, and related parameters, and thus any need to go around "fixing" those things is mostly just an anal compulsion that is treatable with medications.
Although many of us have our personal preferences that we use when creating a citation, the experienced among us don't go around "fixing" these things on an article-wide basis, as that would imply that "my personal preferences are better than your personal preferences". I sometimes can't resist doing it with individual citations I'm already fixing, such as in
this edit. I was converting |author=
to the article's convention of |first=
and |last=
. But I couldn't help "fixing" some other things while I was at it.
So, in summary and generally speaking, unless something makes a real, practical difference, I try to leave it alone, as we have more than enough other insignificant things to battle over.
I seem to have become more verbose since you showed up. :) ― Mandruss ☎ 10:28, 18 April 2015 (UTC)
where the only person reading your drivel is you! Joking aside- That's not a joke; see WP:TLDR. I confess to skipping large swaths of your comments at NPOVN; I seem to have an ADD problem that prevents me from staying focused that long. And many people just don't care to take the time. If you want to be read, try to be more be concise, although I understand it's not a trivial matter to change one's natural tendencies. ― Mandruss ☎ 16:55, 18 April 2015 (UTC)
Did you decide not to make links of citation parameters in the Scott article? I've lost touch with that. The last I recall is that I said it shouldn't be done with VE; is that why it was dropped? If you don't do that, I'll probably remove all existing such links, as the article should be consistent in that regard. ― Mandruss ☎ 18:15, 28 April 2015 (UTC)
Just wanted to compliment you on your clear and well written response there. Dougweller ( talk) 09:05, 19 April 2015 (UTC)
See my proposal and feel free to weigh in. (concisely! ;) ― Mandruss ☎ 12:58, 19 April 2015 (UTC)
Is there a higher authority? Can I appeal to anyone? I feel like I'm being stonewalled because someone has a personal bias. Timothyjosephwood ( talk) 21:13, 20 April 2015 (UTC)
We regret to inform you that your color nomination, #347BFF/white, failed the WCAG AA contrast test for Normal Text and has been withdrawn. Please reply here if you have any questions. Thank you,― Mandruss ☎ 01:31, 21 April 2015 (UTC)
Regarding your objection in your edit summary here, please note that my edit summary clearly indicates that I reverted to your edit. I did not revert your edit, nor did I claim to. Please read the edit summary more carefully in future. Thanks.-- Jeffro77 ( talk) 10:33, 21 April 2015 (UTC)
Sorry, I misread your last edit, which was a dummy edit. My revert was unnecessary. Must learn to look closer. I and others generally begin dummy edit editsums with the link: dummy edit. ― Mandruss ☎ 15:13, 21 April 2015 (UTC)
Need your help with a test. Did you receive a ping from my talk page just before this? ― Mandruss ☎ 15:45, 21 April 2015 (UTC)
WP:Manual_of_Style#Linking "As much as possible, avoid linking from within quotes, which may clutter the quotation, violate the principle of leaving quotations unchanged, and mislead or confuse the reader." Thanks for asking. See you on the wiki. -- WeijiBaikeBianji ( talk, how I edit) 02:49, 22 April 2015 (UTC)
Red Slash said: "it's been widely reported and everyone will want to know it."
When a closer sees the words "everyone will want to know it", I think he will ignore Red Slash's !vote, as Wikipedia editing has very little to do with giving readers what they want to know. Tabloids give readers what they want to know. know. Besides, people who want to know it will find it in the body, so what does that have to do with the lead? Maybe Red Slash didn't mean it the way it sounded, but I don't see how it could be in any way connected to policy or established editing principles. I'd suggest not adding clutter responding to clearly incompetent !votes. ―
Mandruss
☎
09:54, 23 April 2015 (UTC)
You've already found one supporter at Ayers Rock. CaesarsPalaceDude ( talk) 06:15, 24 April 2015 (UTC)
Hi, Nøkkenbuer. You asked a couple questions during this discussion on @ Guy Macon:'s Talk page which I never got around to answering. I didn't intend to be rude; I was waiting to see if similar discussion would arise at the RfC and didn't want to duplicate the conversation. Anyway, you wondered "why you claim that Christian atheism is considered a religion, since I see no mention of it as such in the Wikipedia article". When I said Christian atheism is indeed categorized as a religion, I was referring to the Wikipedia category link at the bottom of that article: Christianity and other religions. Since the article does explain that Christian atheists still adhere to other 'beliefs', just not the one about the existence of a God (or in some cases, believe that God has died), I think the categorization is valid. It can also be described as a "theological position", but the two definitions are not mutually exclusive. When I referred to your assertion about "irreligious but still otherwise adheres to Christianity" being nonsensical because adherence to Christian beliefs is the definition of religious, you responded: "it's as nonsensical as Christian atheism or Cultural Christian. It simply implies that someone adheres to Christian principles, beliefs, or culture, but rejects the religion and its institution. It's not extremely common, but it occurs." I think, perhaps, the examples you've picked do not support your assertion as well as you have hoped. A Christian atheist is still religious, while a Cultural Christian is not (according to our articles on each). Adherence to Christian beliefs does indeed mean religious, so my point that when you say someone adheres to Christian beliefs "but rejects the religion" is nonsensical, it is rather evident. I think much of the confusion, and the core of the disagreement, stems from your position that atheism is a form of irreligiousness, while my understanding of atheism is that it specifically relates only to belief in deities, and otherwise has no bearing on a person's religiousness. Regards, Xenophrenic ( talk) 17:21, 24 April 2015 (UTC)
They are as much a religion as is capitalism ...I'm quite convinced that capitalism is a religion; the state is the Church and Wall Street is its Mecca. We all must follow capitalist teachings dutifully, lest we be consigned to a life of hell on this very earth. Indeed, the Church will actively persecute any and all denouncers of the faith. Come to think of it, capitalism is the only religion with consequences - a supra-religion? [Apologies for the interlude; I'll show myself out.] Alakzi ( talk) 14:18, 25 April 2015 (UTC)
Re your edit summary
here (and subsequent edits):
That was me. In my summary I linked to pages that hopefully explain why, but it’s because that isn’t paragraph spacing, at least not so far as the wiki software and web browsers are concerned. We use colons to indent replies, but it’s actually
a form of list, like *
or #
lists. Blank lines between items cause them to be rendered as multiple separated lists (rather than multiple items in the same list). For instance, one such break in one of your comments generates the following HTML:
… far more difficult than expected.</dd> </dl> </dd> </dl> </dd> </dl> </dd> </dl> </dd> </dl> <dl> <dd> <dl> <dd> <dl> <dd> <dl> <dd> <dl> <dd>Similarly, we should specify …
This can be problematic, and particularly disorienting for users of
screen readers that read out each list opening and closing. So that’s why I made that edit. Hope that all makes sense!
—
174.141.182.82 (
talk)
00:14, 26 April 2015 (UTC)
You could simply begin each indented paragraph with a <p>
(paragraph) tag, which should give you the same spacing you’re looking for.
Like so.
::::… blah blah blah. {{ pb}} <!--That’s {{ pb}} for the reader’s readability (it does this), and the commented-out blank line for my own if needed. Both methods produce much cleaner code, but this one also keeps my whole comment in a single list item so it doesn’t read as multiple comments. But really, wikimarkup is just kinda bad for how we’ve come to use Talk pages. As for appropriateness, WP:TPO says that fixing formatting errors is okay. This is definitely a formatting error, and one that’s potentially disruptive to some users. At any rate, thanks for hearing me out! — 174.141.182.82 ( talk) 01:01, 26 April 2015 (UTC)
-->Lorem ipsum …
{{
pb}}
from hereon out. Have a great day! ―
Nøkkenbuer (
talk •
contribs)
16:33, 26 April 2015 (UTC)Please see the draft for conscription I have posted under Alright Then in Talk:Sexism. The working version is available on my sandbox if you want to join us on editing it. There's no reason for multiple people to be working on multiple forks from the same first draft. Timothyjosephwood ( talk) 00:36, 26 April 2015 (UTC)
Sup. From the looks of your userpage, you might be from a scandinavian country. — Preceding unsigned comment added by JKruger13 ( talk • contribs) 22:09, 26 April 2015 (UTC)
TL;DR ... [1] maybe you can try and be a bit more concise? - Cwobeel (talk) 01:00, 29 April 2015 (UTC)
The article has now been re-edited by me, and I believe its structure is better than it was here when you called attention to its unconventional nature at the article's talkpage. In subsequent discussions there I largely supported your position and agreed with the argument that we should be using FA music articles as our models for improving Ayers Rock (band). I would like to thank you for your contributions to that discussion and hope that you are pleased by its current structure. shaidar cuebiyar ( talk) 07:36, 22 May 2015 (UTC)
You are being contacted because of your participation in the proposal to create a style noticeboard. An alternate solution, the full or partial endorsement of the style Q&A currently performed at WT:MoS, is now under discussion at the Village Pump. Darkfrog24 ( talk) 21:33, 22 May 2015 (UTC)
There is an RfC that you may be interested in at Template talk:Infobox country#RfC: Religion in infoboxes of nations. Please join us and help us to determine consensus on this issue. -- Guy Macon ( talk) 14:32, 17 June 2015 (UTC)
Regarding your recent edit on the lead section of the Dog intelligence page, the sentence that you deleted was neither uncited nor irrelevant - it was in the text of the article with its citation and it was in context with the previous sentences, and it is a direct quote. You might acquaint yourself with WP:CITELEAD as citation is not required in the lead. William Harris • talk • 09:27, 22 July 2015 (UTC)
Per WP:Notifications#Triggering events/Mentions and MW:Manual:Echo#Technical details, your edit here probably didn't notify Hgilbert. Cheers Jim1138 ( talk) 09:56, 31 December 2015 (UTC)
There is an RfC at Template talk:Infobox#RfC: Religion in infoboxes concerning what should be allowed in the religion entry in infoboxes. Please join the discussion and help us to arrive at a consensus on this issue. -- Guy Macon ( talk) 22:54, 17 January 2016 (UTC)
I have reverted some of your edits to this article, specifically the use of brackets around ellipses. Please see the manual of style. Cheers! 🖖 ATinySliver/ ATalkPage 00:27, 11 February 2016 (UTC)
An ellipsis does not normally need square brackets around it, because its function is usually obvious—especially if the guidelines above are followed." As for the precision you note above, "
this is usually only necessary if the quoted passage also uses three periods in it to indicate a pause or suspension." Would I recommend you not add them any more? Yes. Would I suggest you revert the ones you've done? No.
Just letting you know, I have completed the page swap that you requested :) — Frosty ☃ 12:06, 13 April 2017 (UTC)
This is to inform you that an attempt is being made to overturn an RfC that you voted on (2 RfCs, actually, one less than six months ago and another a year ago). The new RfC is at:
Specifically, it asks that "religion = none" be allowed in the infobox.
The first RfC that this new RfC is trying to overturn is:
The result of that RfC was "unambiguously in favour of omitting the parameter altogether for 'none' " and despite the RfC title, additionally found that "There's no obvious reason why this would not apply to historical or fictional characters, institutions etc.", and that nonreligions listed in the religion entry should be removed when found "in any article".
The second RfC that this new RfC is trying to overturn is:
The result of that RfC was that the "in all Wikipedia articles, without exception, nonreligions should not be listed in the Religion= parameter of the infobox.".
Note: I am informing everyone who commented on the above RfCs, whether they supported or opposed the final consensus. -- Guy Macon ( talk) 03:07, 26 June 2017 (UTC)
Sorry, I don't know what kittens are for, but I just wanted to let you know that I really like your comments on Talk:John_A._McDougall ! Well-reasoned, detailed, calm, and professional, even in the face of angry editors!
Sjb0926 (
talk)
01:45, 21 January 2018 (UTC)
Moved from Veganism Talk page, as this is not about veganism. -- Zefr ( talk) 20:21, 26 February 2018 (UTC)
Hey Zefr, I noticed that you did some editing to the NIH reference on Vitamin B12. I was the one who filled out that citation and made the changes you seem to have partially reverted, so I am naturally curious about your rationale. Was my edit, or at least the parts which you reverted, inappropriate and why if so?
Just to clarify, I added the archive as part of my usual citation cleanup to prevent
link rot and preserve a snapshot of the cited material to ensure that changes in the source itself do not accidentally undermine the point of its citation in the article. I added the author
parameter per my interpretation of the template documentation at
Cite web § Authors and
§ Publisher and because I have never seen the publisher
parameter defined in that way in any citation I have encountered. My addition of access-date
is for obvious reasons; I understand that it might not be required for this particular source, as may be the case with webpage archival, but I consider it good practice to include anyway. Do you believe I am mistaken about any of the aforementioned? Is there some precedent or policy about which I am not aware?
I am not disputing your edit so much as I am asking for clarification. Of course, I prefer the content of my edit be retained, but I might as well ask for your opinion here rather than just revert it. I also understand that this may seem like a rather minor issue, but this is typical editing behavior on my part, both generally and within this particular article (see my other citation edits). As a result, this minor issue actually has significant importance about the citation style in this article, especially since I have cleaned up and filled out multiple citations in this way and intend to do so with others. If you take issue with such edits, as you seem to have done here, then perhaps you could inform me about why I should change my editing behavior. Thanks for your time. ― Nøkkenbuer ( talk • contribs) 06:00, 26 February 2018 (UTC)
author
beyond the aforementioned is because the documentation specifies it is appropriate "to hold the name of a corporate author", which I took to mean that non-person entities are allowed (unless I misunderstand what is meant by "corporate author"). Do you disagree? If so, then given you described it as a "department" (and since this was my second choice), do you think the ODS might be better placed under
department
, despite being left undefined in the
Cite web documentation? There is a brief definition in
Cite news § Periodical, which is almost certainly applicable in Cite web, but that doesn't provide much clarity either. Would that be better in your opinion? As for archival, is there any issue with including it anyway despite perhaps not being necessary? I fail to understand why, as a general practice, one should ever exclude archival so long as there are not specific reasons for doing so, especially since
WP:LR states that (my emphasis) "[e]ditors are encouraged to add an archive link as a part of each citation".Lastly, more generally, do you take any issue with me otherwise filling the citations in this article as I have been? If so, and you suspect more reversions will be likely, then some attempt at addressing it now might be appropriate. If not, then after whatever decision is made about this particular citation, I will just proceed with my usual editing. Naturally, my questions are not just about this specific citation, but about this issue as a basis for informing better editing practice overall, so I hope you do not take this is just pedantry on my part. ― Nøkkenbuer ( talk • contribs) 17:37, 26 February 2018 (UTC)
author
is at best a dubious parameter for something like the ODS and that, upon retrospect, department
would have been better if it is added anywhere outside publisher
at all. I only opted for the former since it was more common, it seemed to qualify, and the latter was even less clearly defined.As for the archival parameters, I would still retain them in this instance (and almost any other instance) because I consider an archived copy of the exact page that was used for the citation to be more important than excluding the information on the basis of code minimization. Given that you seem to disagree, though, and favor the latter over the former, I will just leave the citation as it currently is (after readding the access-date
). I have no interest in disputing this just to make a point and risk it being mistaken as
POINTy, and I recognize that this NIH article will probably not be going anywhere for the rest of Wikipedia's life. Whether this particular citation lacks it does not matter much at this time, so I'll just
drop it.Again, I appreciate your input. Have a great day! ―
Nøkkenbuer (
talk •
contribs)
22:57, 26 February 2018 (UTC)I have started the draft here :) Étienne Dolet ( talk) 03:01, 27 February 2018 (UTC)
Generally we stay away from these journals as there have been concerns raised about them. Best Doc James ( talk · contribs · email) 03:38, 25 March 2018 (UTC)
Well... I concur ;-)
It is true that increase in intra ocular pressure can cause vision loss. However that is also a "logical" elaboration... Which I did call sophism; sorry about it.
That kind of statement is of nature to instigate fear; and in the case of the given article, it might never happen.
Indeed the intraocular pressure increase is in the range of normal variation [actually it might be variation between individuals, and not variation in time, so I might be wrong on that point, I'm not a doctor].
So, even though I do share the opinion it is a bad thing, I believe it is an overstatement to say it can lead to vision loss in that specific circumstance.
I believe that a specific source, pointing to actual vision loss, in that specific circumstance, would be required: like, does an increase of 2.79 mm Hg, sustained in time, would lead to significant vision reduction. Does the 2.79 mm Hg persist in time? How long? Would several consecutive injection lead to cumulative effect? Those are to be assessed by further investigations IMO.
Feel free to revert my change. I like the idea that gluco-corticoid II injection should be dealt with utter care. However I fear that overstatement could compromise the overall credibility of the article.
Best, Chris — Preceding unsigned comment added by 82.121.15.217 ( talk) 14:01, 18 April 2018 (UTC)
Since the previous wording (without the clause) in the Osteoarthritis article did not detail the significance of this study nor why it would matter that an association between intra-articular knee injections with triamcinolone and increased intraocular pressure was noted, I decided to include that clause so that the reader would understand its importance from the article text alone. To do so, I simply restated, in different words, what was already in the cited source.With that said, I have no particular opinion about its inclusion nor even about this topic, about which I personally know little. I had not considered the concerns you have expressed, however, since my focus was on simply explaining the importance of the study with its own claims and not whether the explanation itself might be mistaken as fearmongering. I appreciate you pointing this out, since although I do not personally see that as much of a concern, I see how it might be and understand that the exclusion of that statement might therefore be warranted.If you still think that the vision loss clause ought to be excluded, then either you or I can also remove it from where I transferred that text and citation in Triamcinolone § Side effects. I will await your input and if you would rather me remove it, just let me know and I will do so. Thank you.On an unrelated note, I want to say that your edit was obviously constructive and that this talk page message you left me demonstrates a commitment to that constructive approach, at least to me. I appreciate that and invite you to consider creating an account, which provides many benefits that may interest you. Of course, you don't have to do so and can continue to contribute to Wikipedia as an IP address. Naturally, it is entirely up to you; however, especially given the prejudice some users have against unregistered users, I would hate it if your contributions were reverted or prejudged simply because the "account" was an IP address. Regardless, I wish you the best and look forward to whatever further input you may have. ― Nøkkenbuer ( talk • contribs) 17:15, 18 April 2018 (UTC)BACKGROUND: Intraarticular steroid injections are a common first-line therapy for severe osteoarthritis, which affects an estimated 27 million people in the United States. Although topical, oral, intranasal, and inhalational steroids are known to increase intraocular pressure in some patients, the effect of intraarticular steroid injections on intraocular pressure has not been investigated, to the best of our knowledge. If elevated intraocular pressure is sustained for long periods of time or is of sufficient magnitude acutely, permanent loss of the visual field can occur.
Thank you for your edit generalizing my mention of the editor NoteTab. David Spector ( talk) 20:44, 24 April 2018 (UTC)
Just wanted to let you know that I'm the assistant editor in Chief of The Signpost and read your feedback on the last issue's opinion piece by Hurricanehink. Your detailed explanation of the content you like and want to see more of is appreciated. We are thinking hard about this in the context of improving, reinvigorating and sustaining a great publication, and your input means a lot. ☆ Bri ( talk) 19:27, 30 May 2018 (UTC)
You probably saw my revert edit summary, but in case not: Please do not do this. It makes the code extremely difficult to read for humans, for zero benefit of any kind whatsoever. — SMcCandlish ☏ ¢ 😼 19:14, 24 June 2018 (UTC)
This is also not helpful (actually worse than unhelpful). Code syntax highlighting is for making blocks of code easier to parse by visually organizing different code elements by type, e.g. so that variables are distinct from neighboring commands/functions/elements). It has the opposite effect when applied to a single word of code inline in regular text; people wonder "
WhyTF is this text green?" The proper markup for inline code is <code>...</code>
(or templates that use it like {{
tlx}}
). —
SMcCandlish
☏
¢ 😼
19:37, 24 June 2018 (UTC)
PS: Lest I sound excessively critical, highlighting can be helpful in "extended" inline cases like this (your edit, combined with my restoration of readable CSS). :-) — SMcCandlish ☏ ¢ 😼 19:44, 24 June 2018 (UTC)
<code>
provides. Tangentially, and much less importantly, it beautifies the code in a way that I think is appealing to readers and can even attract those who are otherwise disinterested in coding to the practice. In fact, I think that highlighting code syntax, even within prose, has no downside in virtually any situation, especially when compared with <code>
, because the improved visual display provides readers and editors with more readable code that technically decreases ambiguity.Regarding the potential confusion that inline syntax highlighting might cause for readers, I think that syntax highlighting is both intuitive and obvious even for those completely unfamiliar with coding. The entire purpose of syntax highlighting is to improve human readability by clearly indicating the syntax such that it is distinct from other syntax and from non-code text. I think this is true regardless of whether it is embedded within prose, including where a {{
tag}} or <code>
might be used. This is especially so since, as mentioned above, the situations in which it is almost always used are either within articles and documentations which are about syntax-highlightable code or otherwise include a nearby syntax-highlighted code block.When it comes to backend template documentation in particular, I suspect that Wikipedians as a group are much less likely to be confused by syntax highlighting than the average reader, especially those who edit the source and rely on template documentation. This is even more relevant now that wikitext syntax highlighting is already used by a large percentage of Wikipedians, primarily thanks to
Syntax highlighter and
Wikitext editor syntax highlighting. Since Wikipedians are the ones who are most likely to even find template documentation, particularly those engaged in editing that requires some familiarity in basic coding, I considered inline syntax highlighting in template documentation to be the least controversial changes to
boldly make among these sorts of edits.I am not aware of any policy, guideline, or essay that discourages such syntax highlighting usage; that absence was partly what encouraged me to proceed on what I believed were the merits of my rationale. Are there any of which I am not aware? If not, then is this just your personal recommendation? I value that, too; I am just trying to understand whether this issue had been addressed elsewhere. If you still think I should avoid editing like this in the future, or even to begin self-reverting those kinds of changes throughout Wikipedia (such as in
Template:Quote/doc), then I suppose I can. I naturally see these edits as constructive improvements, though, so I am hesitant to do so, especially when it is unclear to me what damage I am doing.(
TL;DR) My rationale for these kinds of edits is to ensure consistent syntax highlighting and to take full advantage of its benefits. I see no downside in doing so; if anything, it can beautify the text and attract people to the beauty of that code while improving the experience for both readers and editors. I think syntax highlighting is intuitive and obvious to understand, especially for Wikipedians but also for those ignorant of basic coding, so I do not think such potential confusion is much of a concern. This is especially so for obscure backend technical articles like template documentations, doubly so because of coding competence and syntax highlighting popularity among Wikipedians. Is there any policy, guideline, or essay that is relevant here? I am aware of none. I can stop or begin self-reverting, but I do not understand what damage I am doing here, since I think these are constructive improvements. Thank you for any further input.P.S. – Regarding
this edit of mine and
your subsequent change, the compressed version without the spaces is actually necessary for full <
syntaxhighlight>
highlighting. I assume that this is because the syntax highlighting makes it human-readable beyond what simple spacing does, so the spacing is superfluous. For example, compare the following:Markup | Renders as |
---|---|
<syntaxhighlight lang="CSS" inline>margin-top:0;margin-bottom:-0.5em;</syntaxhighlight> |
|
<syntaxhighlight lang="CSS" inline>margin-top: 0; margin-bottom: -0.5em;</syntaxhighlight> |
|
<
syntaxhighlight>
. —
Nøkkenbuer (
talk •
contribs)
00:50, 25 June 2018 (UTC)
<strong>...</strong>
". The green of that looks pretty much just like {{
bxt}}
(which conveys something like "please definitely use this green example material"). We're not trying to tell people what markup to insert and how to format it; we're just trying to tell them the template uses the <strong>
element. The syntax highlighting is an actual benefit – when it works properly – in blocks of code (including inline ones with multiple differently-highlighted things in them), but it isn't helpful otherwise, especially when all it does is colorize one thing without a reason that'll be clear to the reader, most especially if it conflicts with other markup we've been using much longer. like the {{
xt}}
template group. I.e., we already had a coherent approach to code markup before <
syntaxhighlight>
even existed, and while the latter is useful for some things (when not broken), it's not a hammer for which every potential problem is an identical nail.That is, hyper-consistency toward syntaxhighlight isn't taking account of a) whether it actually works for a particular example, b) context (including editorial intent and reader interpretation), or c) conflicts with other consistencies implemented for other (sometimes more important) reasons. This kind of "consistency conflict" is one that we encounter frequently in "style" matters more broadly. An important consideration for mainspace in particular is that
WP:MOS, like all professional-grade, formal-writing style guides, is dead-set against introducing extraneous stylization of any kind, and is minimalist for good reasons (especially
MOS:Accessibility ones, but others as well, including
MOS:TONE,
WP:NOT#BLOG, and others.) For example, the
HTML element article has pretty much forever been using markup like '%block;
and %inline;
are groups within the HTML DTD that group elements as being either "block-level" or "inline".' It's unobtrusive, helpful, and what W3C and WHATWG actually recommend and intend. We later started marking up the code blocks with the then-new <
syntaxhighlight>
. As long as it works properly, this is (for the reasons you've written about above) also arguably helpful (honestly, I'd like to see an accessibility analysis of the color choices, but I presume on good faith that one has been done at some point). However, someone since then has done something not helpful at all: they've gone around and put <
syntaxhighlight>
around every single thing, in mid-sentence, where they can get it to do anything. This is causing "outbursts" of pointless color all over the place, and even producing sentences with grossly inconsistent markup, as in 'Lists with <ul><li> ...
are %block;
elements ...' Not helpful to any readers, and not an encyclopedic approach. It's just haphazard decoration for its own sake and needs to be undone. (I've raised the issue at that article's talk page.) To the extent someone thinks this is some kind of a consistency/conformity improvement, they're making a mistake; it's a type of
hypercorrection that fails to take into account context, intent, and effect. When all of MoS is indicating not to apply extraneous stylization, we don't need to add a special line-item for each imaginable form of extraneous stylization, or MoS would be 10 times longer than it is and no one would read it or remember any of it.
—
SMcCandlish
☏
¢ 😼
12:32, 25 June 2018 (UTC)
<
syntaxhighlight>
and templates that utilize it, such as {{
code}}, are infrequently used and especially rare within prose—at least, properly used and when compared to alternatives like <code>
, {{
tag}}, and so on. Consequently, there is not much use case history beyond the basics that can discover them, especially in edge cases. This is compounded by the fact that simply using <code>
is far more common, both because the extension is new and somewhat more complex and because the latter HTML markup is a decades-old international standard. In my usage of the extension and its implementation in templates like {{
code}}, I have noticed various problems, as well. For example:<code>
, which seems like a pointless inconsistency in the visual display;<ref>...</ref>
in {{
code}} will create a reference unless <
nowiki />
s are used break the code, in which case direct <
syntaxhighlight>
markup with the inline
attribute is less complex and verbose;|style=
using {{
para}} as shown in
Template:Quote/doc § Vanishing quotes (
permanent link), though this limitation is at least understandable given how difficult that may be to code; and<var>...</var>
markup into highlighted syntax that is not itself then escaped and highlighted, which makes highlighting code with properly marked variables impossible, but this is again another limitation that I understand may be infeasible to address (especially given this is a limitation with <
pre>
as well).In an article, we're using color – very sparingly – for a tiny handful of quite specific things, and even this has its detractors. Introducing more of it in main article text is confusing for readers who expect only a very narrow class of directly "actionable" things in the article to be colored text. It's essentially the same UX and usability problem as making icons that look like buttons but which are not. Another way of looking at it: We have lots of color markup templates that we use internally for special purposes, like {{
strongbad}}
and the {{
xt}}
family, and {{
tq}}
, but we do not use them in articles, because it's the wrong output context for such visual gimmicks. (It's actually no possible to use some of them in mainspace, and they probably all need that namespace test installed.)
The "consistency" of having one or two-word bits of source inline in a sentence match the colorful SH layout of a large code block is a consistency we don't need, rather like putting pepperoni on an apple pie because they're both baked round things. It's possible to apply this markup inline it but it usually doesn't serve a useful function, and interferes with more important consistencies and goals. By way of another analogy: there's a real-world fad to arrange bookshelves by the color of the books' spines, to create an interesting decorative effect. But only someone who doesn't actually read these books and just has them as décor would ever do such a thing, since it makes finding a particular volume next to impossible. (I know from experience; I dated someone who did this. It didn't work out.) The in-prose markup and presentation (already marked up with <code>
semantically anyway) serves a completely different function from code-block markup, as arranging books by topic or author (or the latter within the former) rather than by color has a different function that arranging them in color patterns to turn one's book wall into an artistic display. (Not a perfect analogy, since the code block SH isn't artistic but functional, just differently functional – yet using it inline is mostly and often entirely decorative not functional).
Sorry if this is repetitive with the above; it's been a while since the discussion was active.
—
SMcCandlish
☏
¢ 😼
02:46, 20 July 2018 (UTC)
color markup templates", since their functions are irrelevant for mainspace article contexts. That is not the case for syntax highlighting, especially in articles and documentations that display syntax-highlightable code and particularly in those that already have syntax-highlighted code blocks. So, how specifically is this expanded use of inline syntax highlighting harming user experience or human readability, both of which syntax highlighting is intended to improve?The best I can tell is that you seem to believe I am using syntax highlighting outside of what you believe to be its proper context. It is upon that conviction that rests the conflict in our perspectives regarding the functionality and value of the expanded (or "
misuse[d]") syntax highlighting I had been implementing, since the "context" for syntax highlighting to me is simply any context in which syntax-highlightable code is used (with exceptions) whereas you favor a more restricted context that is generally confined to code blocks and complex code strings (with exceptions). That is why I consider syntax highlighting to be strictly an enrichment of the text that "
has no downside in virtually any situation" and why you consider it "
a type of hypercorrection that fails to take into account context, intent, and effect". In a sense, I have an "inclusionist" approach to inline syntax highlighting for which exceptions to a highlighted norm require justification and you have an "exclusionist" approach to it for which exceptions to the more restricted norm require justification.Like I stated before elsewhere, I think I understand your perspective and why you maintain it. For you, the function of syntax highlighting is to improve human readability of code in contexts wherein the code's syntax and structure are sufficiently complex that colorizing them does so. That is an uncontroversial and accepted evaluation of syntax highlighting, one with which I also agree. That was also the extent of my position on syntax highlighting since learning about it years ago, which only recently changed after I considered the relationship between inline and block code and what effects inline syntax highlighting might have. That led to my present position.For me, the enrichment that syntax highlighting provides in such restricted cases also extends to all inline code, including simple code, and this extension reciprocally reinforces the original enrichment that syntax highlighting provides in complex code. Doing so resolves the contradictions and ambiguities in the relationship between the inline and block code texts, as well, which were introduced by the more restricted use of syntax highlighting. Thus, the primary benefit of this extended and expanded use of syntax highlighting is to address problems in the context itself, in the second-order relationships between first-order components in the texts. That is basically what ensuring consistency as a functional attribute (rather than an aesthetic one, though they are not mutually exclusive) is about.From the perspective of the casual reader who is unfamiliar with programming or markup of any kind, I think the result of these abstruse contextual alterations is a more intuitive user experience that no longer has needless complexity and lingering ambiguity between inline code and block code texts. That reader may still ask "Why is this text a different color?", but that is a question applicable to all syntax highlighting. With all code syntax highlighted, though, the reader will no longer ask "Why is this code colored while that code is not?".Syntax highlighting as currently deployed is technically unable to provide such a total syntax highlighting due to some of the limitations described above, but that is why I encourage improving the extension rather than rolling back the expanded inline deployment. The latter just maintains the original state of affairs with the same problems I believe I have identified. Unfortunately, it seems that the latter has occurred given your changes at HTML element (and elsewhere?), despite what appears to have been both implicit consensus at the article (including before I arrived) and no consensus at the now-archived WT:MOS discussion (one user had no specific comment on this issue, but supported your general proposal; the only other uninvolved participant seemed to support the expanded use of syntax highlighting). Nonetheless, I have not returned to that sort of syntax highlighting editing since there is other work to be done, though I still maintain the same position. Moreover, I will not restore any syntax highlighting that has been removed, at least not unless and until this is resolved with consensus-based support for doing so.Given this sustained disagreement and the lack of input from uninvolved users when informal talk page discussions were initiated about it, an RfC or some other resolution process may be due now. I have explained (and almost certainly overexplained) my position enough at this point, so if any such resolution process is initiated, I will simply refer others to these initial discussions unless summaries are required. Is that acceptable for you?Lastly, thank you again for your time and willingness to discuss these matters at length. This matter is not urgent, so feel free to take some time before replying, as well, if you decide to do so. Have a great day / night. — Nøkkenbuer ( talk • contribs) 20:25, 1 August 2018 (UTC)
{{
!xt}}
and {{
talk quote}}
and {{
strongbad}}
). Even the limited use of inline color has detractors; the
WP:SEAOFBLUE principle has us linking much less than we could (possibly should – people debate this), just to avoid colorizing more of the text.By contrast, you want there to be consistency within the article (and presumably across articles) such that <cite>...</cite>
appears exactly like that, no matter what context in which is appears. I sympathize. I'm legendary around here for "pushing" consistency arguments. "Oh, no, here come that consistency guy again." People in various wikiproject verge on actual hatred of me because I agitate against their
WP:CONLEVEL-problematic attempts to fork a "special" naming pattern, layout, spelling, punctuation, etc. away from site wide norms. The difference is that <cite>...</cite>
looking like that is just arbitrary. It's not a consistency WP actually needs, that readers want or which will be meaningful to them. The semantic job is done by plain <code>
markup around code example. Colorizing it further serves no contextual purpose where it found, inline, but it does interfere with the contextual purpose of color we already use inline (especially red and blue).<nowiki>...</nowiki>
</code>
Conceptually, this entire issue is basically identical to the one that led to the creation of the
MOS:ICONS guideline (in any thing like its present form; I would know, since I wrote it
[2]!) There was a habit of sticking flag icons before/after country names (or as stand-ins for them) at every opportunity. Fans of the idea were convinced that if it was okay/useful to do it in one context (e.g. an Olympic medals table, a context in which flag icons are consistently used in the real world), then it must be okay to do it at every mention of a country in an infobox, a list, a table, a navbox ... and why not at first occurrence, at least, in the prose itself? What started as the
WP:FLAGCRUFT essay was fast tracked into the
MOS:FLAGS guideline. Shortly thereafter it became the
MOS:ICONS guideline: We found that people were doing things like inserting things like
I-35 in mid-sentence in articles to mark up highways, and similar things were being done with railway lines, train stations, and a zillion other things. All for the same iffy rationale: If we're doing it in the junction table in the infobox or some other data-presentation context, why shouldn't we do it everywhere, including in sentences? The community rejected the idea. The guideline was then expanded to cover Unicode/ASCII dingbats and other things that aren't technically icons (unless they are the actual topic of the material, of course, e.g. at
Quotation marks or
Dagger (typography) we have to illustrate the glyphs under discussion). Then it was extended to include emoji. Now we have an open discussion about extending it again to cover things like
BR being used in mid-sentence (that's done entirely with HTML and CSS, an image-free way to simulate a graphical icon).
That's really not any different from <cite>
: Use of markup to create extraneous decorative appearance, in the name of being consistent with actually appropriate use of color in presentation of complex data. It's a tiny, pointless consistency that bollixes up the much grander consistency of simple, readable prose, with inline color used for a single, specific, predicable purpose across the whole site.
PS: I'm generally in favor of using {{
code}}
in inline multi-part code samples; you may have noticed that I preserved this at
HTML element to the extent possible despite the trouble it causes in the edit-view wikimarkup syntax highlighter (and my work over there recently was an overhaul
[3], not just a "get rid of this coloring" tweak). But people are actually likely to object to even that much of it, when used in mid-sentence that way.
PS: I hope this wasn't very repetitive; we've gone over this "consistency philosophy conflict" or whatever we want to call it at such length and in some many pages I forget exactly what's been said before.
—
SMcCandlish
☏
¢ 😼
22:12, 1 August 2018 (UTC)
<br />
", yet we opt for the latter. I still do not think this is decorative, since syntax highlighting in the way I was adding is more comparable to the functions of syntax highlighting in code blocks or the gray background boxes around <code>
s than to the decoration of icons and so on.Nonetheless, I am only aware of one user attempting to implement syntax highlighting in the way I had been, namely myself, and attempts at attracting more attention to it have thus far been met with little interest. Additionally, regardless of whether this use of syntax highlighting is (exactly) comparable to the issues which led to the development of
MOS:ICONS, the similarities between the two are enough that I suspect those who do not maintain my position will find it persuasive. If this issue were to be the subject of an RfC, I now anticipate the response to be generally in opposition even if a more restricted support for it in articles such as
HTML and
HTML element develops. I prefer explicit consensus here to at least clearly indicate the community's opposition to the less restricted syntax highlighting I had been implementing; however, given the fact that vaguely similar issues in the past have been met with consensus against them, and that I now anticipate consensus against it here as well, it is probably counterproductive to push for any at this time. Anyway, since the technical limitations with <
syntaxhighlight>
presently render the sort of total syntax highlighting I support infeasible, my case for consistency here is severely weakened. This is especially so when the color scheme and scope used by the extension appear to be largely arbitrary and inconsistent with syntax highlighting implementations used even within Wikipedia (such as wikitext highlighters).Lastly, this is frankly not a big enough deal. Sure, it's inconsistent to me and not what I prefer, but I don't see either visual display to be obviously confusing or disruptive to the prose (unlike icons). The best-case scenario one can reasonably achieve with the implementation of a more total syntax highlighting is somewhat better site-wide consistency which addresses a marginal second-order concern that, as you noted, neither readers nor even other editors appear to be wanting. My proposal may be a solution, but it is for a problem that is not significantly acknowledged as one (and is even disputed as one), and so probably seems to many as a case of the former in search of the latter.With that said, I once again appreciate your discussing this with me. In particular, I appreciate your detailed replies, whose explanations have been clear and compelling enough for me to reconsider my position. My proposed syntax highlighting usage is at best a minor stylistic change whose improvement is disputed and whose interest from the community is almost nonexistent. Perhaps that will change and some other editor will have a similar proposal in the future, but until then, this is not worth further consideration. Thank you for your time. —
Nøkkenbuer (
talk •
contribs)
19:45, 5 August 2018 (UTC)
<
syntaxhighlight>
extension is improved, I'll probably just find other stuff to do and not bother with inline syntax highlighting within articles. —
Nøkkenbuer (
talk •
contribs)
01:14, 16 August 2018 (UTC)
{{
code}}
template to highlight markup fragments has a strong tendency to break syntax highlighting in the wikieditor. For example:
{{code|lang=html|code=<ul><li> ...}}
{{code|lang=html|code=<ul><li> ...}}
<ul><li> ...
{{
tag|code|o}}
markup (as I just did with that template – self-referential loop!) or by hand tweaking it, e.g. "Using a backslash is invalid markup, a common error by MS Windows users: <code><nowiki><\code></nowiki></code>
". —
SMcCandlish
☏
¢ 😼
02:46, 20 July 2018 (UTC)
<
syntaxhighlight>
HTML extension itself with an inline
attribute would not cause this, since the closing tag must be defined.As for escaping markup within {{code}}, that seems to be an issue with <
syntaxhighlight>
itself since escaped characters do not work within any present implementation of the extension, block or inline. As you probably already well-know, characters can be escaped using <
pre>
s, so it's not like this is an unfixable limitation. Perhaps another phabricator ticket (or two) is due? —
Nøkkenbuer (
talk •
contribs)
20:25, 1 August 2018 (UTC)
{{
code}}
is that it only accepts raw input; there appears to be no way to escape anything, including as HTML character entities – it just gives you the character entity codes not the character. It's a very "blunt instrument" and even its own documentation suggests other approaches for various situations. The idea that it could become a general standard, for use in mainspace, just isn't viable. —
SMcCandlish
☏
¢ 😼
22:12, 1 August 2018 (UTC)
apologies, copied the ref from the "research on meditation" article; did not realise it did not work here . JCJC777 (talk) 19:07, 24 June 2018 (UTC) JCJC777 ( talk) 00:58, 25 June 2018 (UTC)
I'd prefer if you didn't refactor Signpost pages just to add square brackets for ellipses. Per MOS:ELLIPSIS, "An ellipsis does not normally need square brackets around it, because its function is usually obvious." There is no other style guidance especially for the publication that I know of. ☆ Bri ( talk) 22:27, 29 June 2018 (UTC)
There's a much simpler replacement for:
[[Wikipedia:Page name#Section name|Wikipedia:Page name § Section name]]
It's:
{{
slink|Wikipedia:Page name#Section name}}
May it serve you well. — SMcCandlish ☏ ¢ 😼 18:18, 19 July 2018 (UTC)
{{
slink|Wikipedia:Page name|Section name}}
but I got it fixed so it parses the # syntax. —
SMcCandlish
☏
¢ 😼
01:49, 20 July 2018 (UTC)
![]() |
The Signpost Barnstar | |
I would like to thank you on behalf of the editorial team for all the hard work you put in behind the scences for The Signpost. It's very much appreciated.. Kudpung กุดผึ้ง ( talk) 02:27, 1 August 2018 (UTC) |
Thanks for your diligent work on the citations in this issue! Be aware that these come from a Zotero library. (As part of the production process for Recent Research/the Wikimedia Research Newsletter, we use Zotero's automated import function to generate an entry from the publications' web pages, and then Zotero's Wikipedia export feature to generate the citation templates you saw.) This library is also used in other ways (e.g. in the past Dario and I have published an annual corpus of all the research publications covered during that year, and together with Masssly we aim to do so again). Unfortunately your improvement work will be lost for that purpose; at least I don't know of an easy way to backport such changes into Zotero again. But if you are interested in working directly at the source instead, we could give you access to the Zotero library - just let me know.
In any case, thanks again!
Regards, Tbayer (WMF) ( talk) 14:30, 1 August 2018 (UTC)
lost for that purpose", but if you mean that it is not retained during syndication, during publication of the "
annual corpus", or it is otherwise only preserved at the Signpost copy, I don't mind since my initial motivation for editing was with the understanding that it only affects that local copy. Only within the past few days, as I learned more about the Meta Research newsletter, did I discover that last month's issue included the changes I made.Relatedly, on the latter topic, I noticed at its history page that it was cleaned up by you and Masssly. Much of it involved localizing the publication to Meta, particularly the wikilinks and templates. Now that I'm aware of this, I don't mind localizing it at m:Research:Newsletter, as well, especially since it appears that much of it involved code I added or modified. I wouldn't want my changes to produce more need for cleanup and review, which is contrary to the point of those changes.Regarding access to the Zotero library to edit the source directly, my immediate concern is that it may be well beyond my competence in coding of any kind, which is currently limited to MediaWiki and HTML. I can generally understand what is going on in other markup and programming languages, but I do not consider myself at all skilled at coding with them beyond minor copy-and-paste modifications. Moreover, I am completely unfamiliar with Zotero and only learned about its existence recently. Unless the editing process at Zotero is basically similar to the VisualEditor or Wikidata, wherein there are data fields I can fill and modify without having to directly manipulate any JavaScript or install any software or whatever; or it otherwise accepts MediaWiki markup; I discourage giving me access because I am almost definitely not competent enough to be helpful at this time. Regardless, thanks for the offer. — Nøkkenbuer ( talk • contribs) 17:50, 1 August 2018 (UTC)
Hello, Thank you for your message. Having looked more thoroughly at the article it is obviously of high quality and should be rated at least B. The removal of the Americas project is because I assumed that every article in the Indigenous peoples of North America project would not be included in it. That way the two projects could economise on the amount of editing of Talk pages. In practice it seems that this represents what generally happens. The Americas project has less than 4000 articles but the North American one has over 10,200.-- Johnsoniensis ( talk) 15:49, 5 August 2018 (UTC)
I continued the discussion in the Teahouse, because I didn't know any other way to keep George Van Valkenberg in the loop. His personal information would be original research, but he might suggest other topics or names to use in searching for citations. The notability of Project Harvest Moon (PHM) probably rests on its role as a precursor to private enterprise's role is space exploration. When the project died (July 1972), another initiative, "Mankind One" (also ill-fated), sprang from its ashes. I don't plan to follow "the Committee for the Future" beyond 1972. As it stands at the moment, PHM may prove an orphan. Hope that will change. Anobium625 ( talk) 15:37, 17 August 2018 (UTC)
Thanks for the "external link" explanation in the Teahouse. Yes, as a subscriber, I paid for all my sources. I now have enough names and topics to seek external sources. Anobium625 ( talk) 15:49, 17 August 2018 (UTC)
Greetings Nøkkenbuer,
You've recently posted on my so-called "talk page" and have voiced a few concerns. I've decided to respond to you via this weird goatesque message, because this way I can be sure my message will get across (I think?). If I edited my talk-page I wasn't really sure how exactly would you be notified and I don't know how to create a new topic on your talk page (I could only edit a pre-existing topic and I didn't want to fiddle with your talk page like that). So I guess this will have to do.
Firstly, thank you for the kind but undeserved words. I am evidently not a good editor, my technical/IT skills are abhorrent and (as you have noticed) my manner of communication is sometimes confusing. I am specifically referring to the unreferenced quotation marks here.
In some places where I've used quotations that an author has explicitly said, I cite the work in which they've said it. In other times, I use quotations to emphasize a certain keyword, when I figure that itallics (or just itallics) won't do the trick. This is how I usually proceed with emphasis in personal writings, but I understand that this can be regarded as quite confusing in a wikipedia article. My apologies for this inconvenience, I shall try to adress and re-edit the issues as soon as I am able.
"I noticed that some of your paragraphs lacked any references and it was unclear whether they were supported by any of the references you did include."
A correct observation indeed. My intention was that, by referencing a specific paragraph, the rest would be assumed to be stemming from the same source. I thought that if I referenced the entire text, it could result in larger confusion. But this assumption seems to have been false.
Another reason why I say your compliments are undeserved is because I do not consider myself an expert on the particular topics. I've read a few books that deal specifically with these topics and it just so happened that I noticed that precisely these topics were lacking in information and clarity. This is why I decided to edit them and add some depth into them. If someone does decide to revert/re-edit them before I check the references, I do hope they leave the crucial information or at the very least supply their own proper version of the crucial information.
Once again, thank you for the warm welcome and thank you for your time!
Sinveil ( talk) 00:43, 20 August 2018 (UTC)
Sinveil (
talk)
00:33, 20 August 2018 (UTC)
[[User:Sinveil]]
would ping you. It can also be
piped, as with [[User:Sinveil|text]]
, and it will still work. For discussions, however, many users use a template method, such as {{
user link}}
, the shortcut of which is {{
u}}
. (Templates do not work in edit summaries, so using it in one won't ping anyone.) For example, check the text of "Hello
Sinveil!" while in edit mode; it uses that template and is technically what notified you in this reply.Humility is often a result of having developed competence in something, so yours won't fool me. Don't worry or
be ashamed of your current unfamiliarity with
MediaWiki syntax and Wikipedia editing, or with any of the other potential
newbie mistakes you might commit. Your account isn't even a day old! If anything, that not being the case would be
cause for suspicion. Be proud that you're learning; you can save feeling embarrassed for when you check your early edits a few years from now.With that said, on the matter of your edits, I entirely sympathize with your concerns about citing sources at the end of a paragraph when not all of the paragraph is properly sourced. In such situations, however, it's probably better to have at least some reference to support something in the paragraph placed somewhere therein, since sourcing takes precedence over
text–source integrity. Anyone wishing to
verify the claims can figure out what it supports; they can't do that when there is no source! Additionally, in a way, citing a source at the end of every paragraph at the very least is better text–source integrity than not doing so. There are also some rather technical and obscure templates that can assist there, but that's not important right now; they're almost never used, anyway. If you don't even have a source for any of the other content you're adding in a paragraph, though, then that is probably a good reason to not add that other stuff until you do for the reasons I explained before.Reading "a few books that deal specifically with these topics" is frankly more than probably most editors in the edit histories of articles have done, especially the minor contributors. Regardless, expertise is something that needs no teacher, and simply being familiar with a subject due to having read literature about it is already very valuable for an editor to have. What's important is that an editor is invested in understanding and improving that which they are editing, which has already been demonstrated by you from your first edit.On the matter of addressing these sourcing concerns, please don't panic as if the world will end tomorrow. It's good to address these concerns with due haste, but being unduly hasty is not only stressful but may worsen the quality of your attempts to do so! If you are reverted while you are doing so, or if you are regardless, take it in stride and discuss it if you think you should. If you are at an impasse with an editor, there are various ways of achieving dispute resolution. The focus is on improving the encyclopedia, which includes improving one's own edits. So long as you do that, and you make sure to listen, engage, an explain yourself in a civil way (like you have done thus far), I don't think you should be at all concerned about any enforcement coming your way. As for the behavior of other editors, though, well... some do bite.Lastly, to emphasize it once more, feel free to ask me any time if you want any help, or check out the other venues for asking questions. Wikipedia would be nothing without it's editors, so retaining the good ones can more important than editing itself. — Nøkkenbuer ( talk • contribs) 02:14, 20 August 2018 (UTC); edited at 02:22, 20 August 2018 (UTC)
Thanks for the welcome! I thought I would try my at hand at helping to improve some of the subjects I am knowledgeable in as I use Wikipedia probably every day. So, as they say, leave it better than you found it, right?
I appreciate the heads up on my edits. I will keep practicing on the various Wiki functions and hopefully can become a valuable editor for the community.
Alevings1 ( talk) 14:47, 24 August 2018 (UTC)
Hi Nøkkenbuer, thanks for the message. Certainly not overwhelming; but I am genuinely ridiculously busy at the mo, so excuse me if I kiss a couple of points. First, I appreciate your epistemological and pragmatic avoidance of concurring in mt claim to be her daughter; but may I politely point out that googling the two names should confirm this claim, at least to the satisfaction of the pragmatist.
Oddly, I thought I had entered her in Wikipedia; but if as you say I didn't then yes I certainly signed up to eliminate the early inaccuracies. Further to that, I also see that I may be seen as biased (I do like her poetry and consider it under-exposed at the moment). But I would really like to know whence other than from me or my son or cousin you would look for information. Her publishers, John Rolph and Harry Chambers, are both dead; there are no biographies, and the obits were all written by people who called me for the facts. There will be a few ex-colleagues and more ex-pupils; they do not know, for example, her educational history...
As for the Indian perpetration - no, that is not me! I divine as you do that he has fished up a picture online without realising that clicking IMAGES on a Google search gives images that are not all, or most, (or even any) of the person whose name you've input. I am angry about this. Yes, it is a pic of me; yes, I could at some time appear myself in Wikipedia (it is possible given that I am an actor and a writer who have just got into my stride after a few decades of mothering); and yes, it IS copyright; I think it is a headshot or a publicity pic for a local reading. That's the one on the darkish background. I only haven't contacted Wikimedia before because I am so damn busy. The other image is NOT me or my mother, but a complete stranger. At a guess, her forename is Rosamund.
I'd like to know what bits of bio I added you are planning to remove. Seems a shame if you lose hard information. She was at Central in 1952/3 along with Judi Dench; they both did the teachers' course. Vanessa Redgrave was a contemporary too. She never went back into acting; sadly I think as she would have got more joy from it than she did from her marriage. I do not suggest that as an inclusion. As a professional editor myself, chiefly of academic texts, I appreciate the need for care. Please, though, bear in mind my remarks above. As my mother told me just about everything (not always ideal); I do know more about her life than anyone alive now, and nothing is written that has not come from me. If you wish, knock out the point about the three full-time pursuits she had that made it not so easy to write a lot; I can see that as slightly biased, if true and pertinently still characteristic of married female writers. Incidentally, I have just been contacted by an American house wanting to publish a Selected Poems, so she may enjoy a resurgence. Oueeza ( talk) 19:24, 25 August 2018 (UTC)
{{
Request edit}}
template. Even if what you state is not verifiable, if the inaccuracy is not sourced in the article, then it can simply be removed.With that said, please only respond (or even read this!) when it's a good time for you, even if that's in a few days or a week or so. You can also
email me if you prefer that or if it's something you'd rather not post publicly here for all to see. I don't intend to be going anywhere anytime soon, and I intend to help improve your mother's article well into the near-future, so I'll probably be available to assist you with these matters from here on out, so long as you're interested in my long-winded assistance. Now, onto the rest of your message...Part of why I play a bit coy with your identity is because
Wikipedia's policy on harassment includes an "
outing" section that I am very careful to respect. In engaging in that way, I am technically providing a shred of
plausible deniability to protect your privacy and, on the chance that someone is impersonating you, to avoid contributing to that impersonation through validation. I did indeed do some basic research, though.Where a random editor like me would look to find information about a subject's life is usually in
reliable sources that can be
cited to
verify the information. For example, like I said on your talk page in reply to
Graeme Bartlett, I am currently gathering sources to undergo a significant rewrite and expansion of your mother's article. I am doing this with information I found in a variety of sources, mainly obituaries that provide in-depth coverage about her life. I have only done some basic research, so what I have found may just be the tip of it, but thus far I have found some excellent information in a
2005 obituary in
The Independent, another
2006 obituary by
Alan Brownjohn in
The Guardian, yet another
2006 obituary in
The Times, a
1992 review of Stanhope's Lapidary in
Critical Survey (via
JSTOR), and a
1984 mention of Stanhope in Serials Review. That alone is more than sufficient sourcing to confirm Stanhope's
Wikipedia-defined notability, provide significant details about her life and legacy, and even provide some information about her poetry in particular. As more sources are found, the article can continue to be expanded to include them.This is how articles on Wikipedia are created, expanded, and improved, including biographies of people who are no longer living or lived so long ago that anyone who directly knew them is long dead. For example, consider the following
Featured articles on poets:{{
Copyvio}}
(a speedy deletion for copyright violation) on both the
first and
second images after finding the original sources for both. I also noted on both that they are incorrectly named, so they should be deleted soon enough. In the very unlikely chance that they aren't, they will probably at least be renamed, though I'm very confident they'll be deleted as copyright violations. So, on the matter of the images, that should be considered effectively resolved. Regardless of what occurs, I'll ping you with an update on the results.On an unrelated note, I noticed that there is a similarly named account,
Oueezer (
talk ·
contribs), whose only edits are at the
Rosamund Stanhope article, as well. Is this one of your accounts? If so, then it's best if you declare that whenever you reply (again, no rush!). Please keep in mind that
alternative accounts are allowed, but under certain restrictions, and generally having multiple active accounts is discouraged. I have my guesses for why the account exists if it is indeed yours, all innocuous, but I might as well ask anyway. Again, have a great day / night and please take your time to respond. Your professional life comes first; I don't mind waiting. Anyway like I said, I'm busy, too! —
Nøkkenbuer (
talk •
contribs)
00:21, 26 August 2018 (UTC)
[4] (sorry you were dragged into this). Kudpung กุดผึ้ง ( talk) 08:39, 30 August 2018 (UTC)
In the original NASA caption for File:Cosmic ‘Winter’ Wonderland.jpg, they say "optical data from the SuperCosmos Sky Survey (blue) made by the United Kingdom Infrared Telescope". But UKIRT doesn't appear to have an optical sensor. I think that SuperCosmos Sky Survey's optical data was from scanning plates of other telescopes' surveys. It's described in further detail here. This is probably too detailed to adjust The Signpost's Featured content again, but it bugs me. ☆ Bri ( talk) 17:55, 30 August 2018 (UTC)
created by NASA Chandra X-ray Observatory and Spitzer Space Telescope, NASA-German Aerospace Center ROSAT telescope, and United Kingdom Infrared Telescope; and nominated by The NMI User", which seems to be the case even if the optical data do not derive from UKIRT; and the alt text states that the image is a "
[p]hotograph of nebula NGC 6357 false-colored based on X-ray, infrared, and optical data", which is correct regardless of the optical data source.Whatever error might exist regarding the source of the optical data, that is a problem for the description page at Commons—and the NASA page from which we got the description (where it explicitly that states the optical data are from UKIRT). It should of course be corrected if indeed erroneous, but it's beyond the scope of The Signpost and we are not republishing anything incorrect here. — Nøkkenbuer ( talk • contribs) 14:55, 31 August 2018 (UTC); edited at 15:03, 31 August 2018 (UTC)
[a]lthough seeing in the infrared, the UKIRT was large for an optical telescope and signaled a coming focus on this part of the spectrum that only grew in the coming decades." Similarly, this 1995 abstract briefly mentions UKIRT being fitted with an experimental adaptive optics system developed by the University of Hawaii in January 1994.After some consideration, however, perhaps we're just presuming too much of what "optical" means in this context? Optics include infrared wavelengths in its definition, at least according to our article, so "optical" may not necessarily mean the visible spectrum here. Although the wording at the description page and NASA article are ambiguous and unclear, they might mean that the image was produced by UKIRT using the optical data from all sources? I'm not very familiar with these matters, so maybe there are some technical definitions for these terms that I do not know. I also don't have much confidence in this interpretation, but I'm trying to be generous here.In any case, this is now bugging me, too, Bri. It does not help that my web search results are such that it's almost as if this is a fact that is just too obvious (or minor) to report, so others only make statements that imply or suggest it without explicating UKIRT's relationship to optical observations. — Nøkkenbuer ( talk • contribs) 15:42, 31 August 2018 (UTC); last edited at 15:51, 31 August 2018 (UTC)
I don't know what this may indicate or clarify in this situation, but it seems sufficiently similar to this that I might as well mention it. — Nøkkenbuer ( talk • contribs) 15:59, 31 August 2018 (UTC); edited at 16:03, 31 August 2018 (UTC)Infrared photometry and spectroscopy from the United Kingdom Infrared Telescope (UKIRT), and optical data from various facilities are combined with archival data to understand the nature of these candidates. High signal-to-noise near-IR spectra obtained from UKIRT have enabled us to study the optical depth effects in the hydrogen emission lines of these stars.
Thanks for your cleanup on
Incel! I've been a Wikipedian for a while but only learned of {{'"}}
because of your edits—thanks!
GorillaWarfare
(talk)
07:35, 9 September 2018 (UTC)
Hey!
I just read Cam. Opt. alleged "last response" and, in all honesty, I am quite surprised by that nasty transphobia, but apart from that it just seems bitter. I'd be willing to apologize for any kind of rudeness, starting with me, and hoping they would as well. Though, my points and criticisms still stand, of course. What are your thoughts on the matter? JulkaK ( talk) 18:26, 9 September 2018 (UTC) (last edit because the paragraph didn't work 18:27)
Your edits to whatever I come up with for the Signpost have always been an improvement. I need to learn more about formatting from your examples. Please feel free to edit anything that I write. Best Regards, Barbara ✐ ✉ 23:26, 28 September 2018 (UTC)
Hi, I saw you brought over the COI notice from The Optical Society talk page. I just wanted to let you know that User:Jmiller1455 no longer works for The Optical Society. Not sure its necessary to include that account. - Tinynull ( talk) 06:36, 11 October 2018 (UTC)
{{
help me}}
at the top of the section and someone should eventually come along to assist you. Again, thanks for your contributions! —
Nøkkenbuer (
talk •
contribs)
18:41, 12 October 2018 (UTC)profusely apologize for the delay but happily, my piece is nearing completion.There's lot more than that meets to the eye and will be jotted in the yet-to-be-written-conclusion.Post that, there will be extensive copyediting and formatting stuff:-) You are invited to chime in. ∯WBG converse 16:54, 25 October 2018 (UTC)
Regarding [[User talk:SMcCandlish#Categorization consensus|this, I would say that now that we have hidden categories, any category of that sort no longer needs to be relegated to the talk page. Pushing it to talk was what we did before we could hide categories from readers (other than those who create an account and change their prefs to opt-in to seeing these maintenance categories). I would keep the talk page placement for cases of reader-unhelpful maint. categories that have yet to be converted to hidden, though the better solution would be to make them hidden. 2601:643:8300:C96D:CD15:305A:C81B:4798 ( talk) 02:43, 27 October 2018 (UTC)
72 hours was right before I created the English Wikiquote. So it seemed a bit like putting my thumb on the scale. GMG talk 13:35, 27 October 2018 (UTC)
Just so you don't waste time on something that's done automatically: I'm not positive but I think this is unnecessary -- this is copied by the publishing scripts. ☆ Bri ( talk) 15:44, 27 October 2018 (UTC)
I have changed the appearance of my signature. Barbara ✐ ✉ 10:52, 31 October 2018 (UTC)
Bonjour If you want to complete Grunya Sukhareva biography: Other ref: How history forgot the woman who defined autism. https://www.spectrumnews.org/features/deep-dive/history-forgot-woman-defined-autism/
and Sukhareva—Prior to Asperger and Kanner https://www.researchgate.net/publication/274317752_Sukhareva-Prior_to_Asperger_and_Kanner
I don't master the subject to do it myself.
Regards, LaMèreVeille ( talk) 18:20, 18 November 2018 (UTC)
Hello, Nøkkenbuer. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.
If you wish to participate in the 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery ( talk) 18:42, 19 November 2018 (UTC)
Hi, just checking in to see if you are around and willing to help with The Signpost this issue. We have about a week to wrap up prior to the 2 December publication deadline. Thanks! ☆ Bri ( talk) 00:24, 24 November 2018 (UTC)
Hello Nøkkenbuer - After removing the entry for Steven S. Rosenfeld from List of scientific misconduct incidents because it had no sources, I noted on the revision history for Steven S. Rosenfeld the summary statement that you "might return some day to do some cleanup." I have yet to find any RS on the alleged scientific misconduct, so if that "cleanup" involves AfD, I would be supportive. Although this isn't close to a priority for me (or you either I gather), I thought I'd leave you this note because I certainly do not mean to step on your toes by removing the list entry. JoJo Anthrax ( talk) 17:25, 21 December 2018 (UTC)
![]() |
The 2018 Cure Award |
In 2018 you were one of the top ~250 medical editors across any language of Wikipedia. Thank you from Wiki Project Med Foundation for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a user group whose mission is to improve our health content. Consider joining here, there are no associated costs. |
Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 17:41, 28 January 2019 (UTC)
You are invited to join the discussion at
Wikipedia:Templates for discussion/Log/2020 September 15 § Template:Use shortened footnotes.
Peaceray (
talk)
05:21, 15 September 2020 (UTC)
A discussion is taking place to address the redirect
Degeneration. The discussion will occur at
Wikipedia:Redirects for discussion/Log/2021 October 8#Degeneration until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion.
Sangdeboeuf (
talk)
20:09, 8 October 2021 (UTC)
Congratulations to all the contributors to today's featured article. You deserve a lot of applause, recognition and appreciation. What a interesting and wonderful article.
Trying to explain why your edits on Casino Royale were reverted (not by me, I am slow but would have done the same thing.) Fixed image sizes are not good because readers have different devices and different preferences. If you have to change image size, use "upright="multiplier, for example upright=1.2, for an image a bit larger than normal. Exceptions are userboxes and infoboxes. -- Gerda Arendt ( talk) 12:04, 13 April 2015 (UTC)
Thank you for the message, i am trying to remove some disturbing data from the article named Islam, writer should know that there is no concept of painting in photos in ISLAM, By posting such things in the wiki articles can create some serious troubles to the Muslims, and can confuse the readers kindly have a glance on the Painting in the Article.
Really, I think we could engage in open debate until our star burns out, without changing anyone's mind. As I indicated in my last comment, we will need a tie-breaker in the form of expert opinions or an RfC. If it's RfC, I'd suggest saving your debate for that. Even then, you should state your position clearly one time and keep further comments selective and brief, lest the discussion become so large that no new arrivals have the time to read and comprehend all of it. I write this only because I know you to be receptive to suggestions (most newer editors believe they already know everything they need to know). When I find some time I'll find a good barnstar for you. ― Mandruss ☎ 12:36, 16 April 2015 (UTC)
![]() |
The Excellent New Editor's Barnstar A new editor on the right path | |
Amazing progress as an editor in only 40 days, eager to learn and to collaborate, keeps a level head in a debate, committed to improving Shooting of Walter Scott. A promising editing future. ― Mandruss ☎ 17:16, 16 April 2015 (UTC) |
WP:NOCONSENSUS In discussions of proposals to add, modify or remove material in articles, a lack of consensus commonly results in retaining the version of the article as it was prior to the proposal or bold edit. However, for contentious matters related to living people, a lack of consensus often results in the removal of the contentious matter, regardless of whether the proposal was to add, modify or remove it. Jim1138 ( talk) 00:48, 17 April 2015 (UTC)
Greetings Nøkkenbuer! I made some changes with respect to the linking at article Buer. I was wondering if you are familiar with MOS:LINK? Especially the subsections WP:LINKSTYLE and WP:SEAOFBLUE. Anyway, I try to explain in concise :-) See, if we want to link, let's say, a place called "Riverside, California", instead of linking to both [[Riverside]] and [[California]] separately, we should link to either [[Riverside, California]] directly or through a pipelink [[Riverside|Riverside, California]]. That's WP:LINKSTYLE in a nutshell.
According to WP:SEAOFBLUE, we shouldn't place separate wikilinks one next to another, but use a more specific one instead. For example, if we have three locations: "Upper East Side", "Manhattan", and "New York City", instead of linking to all three separately ([[Upper East Side]], [[Manhattan]], [[New York City]]), we should link to the most specific one, which is "Upper East Side" ([[Upper East Side|Upper East Side, Manhattan, New York]]) in this case. I know, that overlaps greatly with WP:LINKSTYLE. That was my own example though, and maybe not the best one. The manual of style uses [[Ireland|Irish]] [[Chess]] [[Champinship]] instead.
Anyway, I think the whole idea of those rules is to help the readers to distinguish between the relevant and the overtly-general ones, and enable carefully selected linking. For example, in the article Buer, [[Blessed are the Sick]] provides lots of information, whereas [[LP record|LP]] doesn't even discuss the theme, Buer. Well, that's just my own pondering though, but... :-)
I would be happy to answer any questions you might have though! Happy weekend and cheers! Jayaguru-Shishya ( talk) 17:17, 17 April 2015 (UTC)
Let's move this here, as we're cluttering a public space with a one-on-one conversation.
Here's why removing all unnecessary spaces from a citation is a bad thing. It's about the number of opportunities for natural line breaks in the edit window. When there are no "extra" spaces, the software is more often forced to split a parameter value at the end of a line. This is usually a URL in |url=
or |archiveurl=
, because they are very long values with no imbedded spaces. URLs are less likely to be split at the end of a line if they are allowed to begin at the start of a line. A split URL is harder to read and to work with.
Just from observation, it seems many editors don't care about that issue, or about anything regarding coding of citations (or about anything regarding coding, as long as it works from the reader's perspective). This is the Whutever editing philosophy.
Those who care no doubt often come from the programming world, as I do, and they have varying ideas and personal preferences. The one I and some others subscribe to is one extra space before each pipe character, and no others. Thus (1) there will be an opportunity for a line break before each parameter, and (2) no parameter value will be separated from its parameter name. There will never be a line break between a parameter name and its preceding pipe character, which is in keeping with the output of the {{
para}}
template as in the second paragraph above.
There are other citation-related personal prefs as well, like whether to use |author=
versus |first=
and |last=
. This one falls into the category of things that affect what the reader sees, and therefore should be consistent within an article. For these things, one's personal preference has no bearing except when they create an article and get to choose its local conventions.
Other personal prefs have no effect on what the reader sees, such as the choice between |newspaper=
, |work=
, and related parameters, and thus any need to go around "fixing" those things is mostly just an anal compulsion that is treatable with medications.
Although many of us have our personal preferences that we use when creating a citation, the experienced among us don't go around "fixing" these things on an article-wide basis, as that would imply that "my personal preferences are better than your personal preferences". I sometimes can't resist doing it with individual citations I'm already fixing, such as in
this edit. I was converting |author=
to the article's convention of |first=
and |last=
. But I couldn't help "fixing" some other things while I was at it.
So, in summary and generally speaking, unless something makes a real, practical difference, I try to leave it alone, as we have more than enough other insignificant things to battle over.
I seem to have become more verbose since you showed up. :) ― Mandruss ☎ 10:28, 18 April 2015 (UTC)
where the only person reading your drivel is you! Joking aside- That's not a joke; see WP:TLDR. I confess to skipping large swaths of your comments at NPOVN; I seem to have an ADD problem that prevents me from staying focused that long. And many people just don't care to take the time. If you want to be read, try to be more be concise, although I understand it's not a trivial matter to change one's natural tendencies. ― Mandruss ☎ 16:55, 18 April 2015 (UTC)
Did you decide not to make links of citation parameters in the Scott article? I've lost touch with that. The last I recall is that I said it shouldn't be done with VE; is that why it was dropped? If you don't do that, I'll probably remove all existing such links, as the article should be consistent in that regard. ― Mandruss ☎ 18:15, 28 April 2015 (UTC)
Just wanted to compliment you on your clear and well written response there. Dougweller ( talk) 09:05, 19 April 2015 (UTC)
See my proposal and feel free to weigh in. (concisely! ;) ― Mandruss ☎ 12:58, 19 April 2015 (UTC)
Is there a higher authority? Can I appeal to anyone? I feel like I'm being stonewalled because someone has a personal bias. Timothyjosephwood ( talk) 21:13, 20 April 2015 (UTC)
We regret to inform you that your color nomination, #347BFF/white, failed the WCAG AA contrast test for Normal Text and has been withdrawn. Please reply here if you have any questions. Thank you,― Mandruss ☎ 01:31, 21 April 2015 (UTC)
Regarding your objection in your edit summary here, please note that my edit summary clearly indicates that I reverted to your edit. I did not revert your edit, nor did I claim to. Please read the edit summary more carefully in future. Thanks.-- Jeffro77 ( talk) 10:33, 21 April 2015 (UTC)
Sorry, I misread your last edit, which was a dummy edit. My revert was unnecessary. Must learn to look closer. I and others generally begin dummy edit editsums with the link: dummy edit. ― Mandruss ☎ 15:13, 21 April 2015 (UTC)
Need your help with a test. Did you receive a ping from my talk page just before this? ― Mandruss ☎ 15:45, 21 April 2015 (UTC)
WP:Manual_of_Style#Linking "As much as possible, avoid linking from within quotes, which may clutter the quotation, violate the principle of leaving quotations unchanged, and mislead or confuse the reader." Thanks for asking. See you on the wiki. -- WeijiBaikeBianji ( talk, how I edit) 02:49, 22 April 2015 (UTC)
Red Slash said: "it's been widely reported and everyone will want to know it."
When a closer sees the words "everyone will want to know it", I think he will ignore Red Slash's !vote, as Wikipedia editing has very little to do with giving readers what they want to know. Tabloids give readers what they want to know. know. Besides, people who want to know it will find it in the body, so what does that have to do with the lead? Maybe Red Slash didn't mean it the way it sounded, but I don't see how it could be in any way connected to policy or established editing principles. I'd suggest not adding clutter responding to clearly incompetent !votes. ―
Mandruss
☎
09:54, 23 April 2015 (UTC)
You've already found one supporter at Ayers Rock. CaesarsPalaceDude ( talk) 06:15, 24 April 2015 (UTC)
Hi, Nøkkenbuer. You asked a couple questions during this discussion on @ Guy Macon:'s Talk page which I never got around to answering. I didn't intend to be rude; I was waiting to see if similar discussion would arise at the RfC and didn't want to duplicate the conversation. Anyway, you wondered "why you claim that Christian atheism is considered a religion, since I see no mention of it as such in the Wikipedia article". When I said Christian atheism is indeed categorized as a religion, I was referring to the Wikipedia category link at the bottom of that article: Christianity and other religions. Since the article does explain that Christian atheists still adhere to other 'beliefs', just not the one about the existence of a God (or in some cases, believe that God has died), I think the categorization is valid. It can also be described as a "theological position", but the two definitions are not mutually exclusive. When I referred to your assertion about "irreligious but still otherwise adheres to Christianity" being nonsensical because adherence to Christian beliefs is the definition of religious, you responded: "it's as nonsensical as Christian atheism or Cultural Christian. It simply implies that someone adheres to Christian principles, beliefs, or culture, but rejects the religion and its institution. It's not extremely common, but it occurs." I think, perhaps, the examples you've picked do not support your assertion as well as you have hoped. A Christian atheist is still religious, while a Cultural Christian is not (according to our articles on each). Adherence to Christian beliefs does indeed mean religious, so my point that when you say someone adheres to Christian beliefs "but rejects the religion" is nonsensical, it is rather evident. I think much of the confusion, and the core of the disagreement, stems from your position that atheism is a form of irreligiousness, while my understanding of atheism is that it specifically relates only to belief in deities, and otherwise has no bearing on a person's religiousness. Regards, Xenophrenic ( talk) 17:21, 24 April 2015 (UTC)
They are as much a religion as is capitalism ...I'm quite convinced that capitalism is a religion; the state is the Church and Wall Street is its Mecca. We all must follow capitalist teachings dutifully, lest we be consigned to a life of hell on this very earth. Indeed, the Church will actively persecute any and all denouncers of the faith. Come to think of it, capitalism is the only religion with consequences - a supra-religion? [Apologies for the interlude; I'll show myself out.] Alakzi ( talk) 14:18, 25 April 2015 (UTC)
Re your edit summary
here (and subsequent edits):
That was me. In my summary I linked to pages that hopefully explain why, but it’s because that isn’t paragraph spacing, at least not so far as the wiki software and web browsers are concerned. We use colons to indent replies, but it’s actually
a form of list, like *
or #
lists. Blank lines between items cause them to be rendered as multiple separated lists (rather than multiple items in the same list). For instance, one such break in one of your comments generates the following HTML:
… far more difficult than expected.</dd> </dl> </dd> </dl> </dd> </dl> </dd> </dl> </dd> </dl> <dl> <dd> <dl> <dd> <dl> <dd> <dl> <dd> <dl> <dd>Similarly, we should specify …
This can be problematic, and particularly disorienting for users of
screen readers that read out each list opening and closing. So that’s why I made that edit. Hope that all makes sense!
—
174.141.182.82 (
talk)
00:14, 26 April 2015 (UTC)
You could simply begin each indented paragraph with a <p>
(paragraph) tag, which should give you the same spacing you’re looking for.
Like so.
::::… blah blah blah. {{ pb}} <!--That’s {{ pb}} for the reader’s readability (it does this), and the commented-out blank line for my own if needed. Both methods produce much cleaner code, but this one also keeps my whole comment in a single list item so it doesn’t read as multiple comments. But really, wikimarkup is just kinda bad for how we’ve come to use Talk pages. As for appropriateness, WP:TPO says that fixing formatting errors is okay. This is definitely a formatting error, and one that’s potentially disruptive to some users. At any rate, thanks for hearing me out! — 174.141.182.82 ( talk) 01:01, 26 April 2015 (UTC)
-->Lorem ipsum …
{{
pb}}
from hereon out. Have a great day! ―
Nøkkenbuer (
talk •
contribs)
16:33, 26 April 2015 (UTC)Please see the draft for conscription I have posted under Alright Then in Talk:Sexism. The working version is available on my sandbox if you want to join us on editing it. There's no reason for multiple people to be working on multiple forks from the same first draft. Timothyjosephwood ( talk) 00:36, 26 April 2015 (UTC)
Sup. From the looks of your userpage, you might be from a scandinavian country. — Preceding unsigned comment added by JKruger13 ( talk • contribs) 22:09, 26 April 2015 (UTC)
TL;DR ... [1] maybe you can try and be a bit more concise? - Cwobeel (talk) 01:00, 29 April 2015 (UTC)
The article has now been re-edited by me, and I believe its structure is better than it was here when you called attention to its unconventional nature at the article's talkpage. In subsequent discussions there I largely supported your position and agreed with the argument that we should be using FA music articles as our models for improving Ayers Rock (band). I would like to thank you for your contributions to that discussion and hope that you are pleased by its current structure. shaidar cuebiyar ( talk) 07:36, 22 May 2015 (UTC)
You are being contacted because of your participation in the proposal to create a style noticeboard. An alternate solution, the full or partial endorsement of the style Q&A currently performed at WT:MoS, is now under discussion at the Village Pump. Darkfrog24 ( talk) 21:33, 22 May 2015 (UTC)
There is an RfC that you may be interested in at Template talk:Infobox country#RfC: Religion in infoboxes of nations. Please join us and help us to determine consensus on this issue. -- Guy Macon ( talk) 14:32, 17 June 2015 (UTC)
Regarding your recent edit on the lead section of the Dog intelligence page, the sentence that you deleted was neither uncited nor irrelevant - it was in the text of the article with its citation and it was in context with the previous sentences, and it is a direct quote. You might acquaint yourself with WP:CITELEAD as citation is not required in the lead. William Harris • talk • 09:27, 22 July 2015 (UTC)
Per WP:Notifications#Triggering events/Mentions and MW:Manual:Echo#Technical details, your edit here probably didn't notify Hgilbert. Cheers Jim1138 ( talk) 09:56, 31 December 2015 (UTC)
There is an RfC at Template talk:Infobox#RfC: Religion in infoboxes concerning what should be allowed in the religion entry in infoboxes. Please join the discussion and help us to arrive at a consensus on this issue. -- Guy Macon ( talk) 22:54, 17 January 2016 (UTC)
I have reverted some of your edits to this article, specifically the use of brackets around ellipses. Please see the manual of style. Cheers! 🖖 ATinySliver/ ATalkPage 00:27, 11 February 2016 (UTC)
An ellipsis does not normally need square brackets around it, because its function is usually obvious—especially if the guidelines above are followed." As for the precision you note above, "
this is usually only necessary if the quoted passage also uses three periods in it to indicate a pause or suspension." Would I recommend you not add them any more? Yes. Would I suggest you revert the ones you've done? No.
Just letting you know, I have completed the page swap that you requested :) — Frosty ☃ 12:06, 13 April 2017 (UTC)
This is to inform you that an attempt is being made to overturn an RfC that you voted on (2 RfCs, actually, one less than six months ago and another a year ago). The new RfC is at:
Specifically, it asks that "religion = none" be allowed in the infobox.
The first RfC that this new RfC is trying to overturn is:
The result of that RfC was "unambiguously in favour of omitting the parameter altogether for 'none' " and despite the RfC title, additionally found that "There's no obvious reason why this would not apply to historical or fictional characters, institutions etc.", and that nonreligions listed in the religion entry should be removed when found "in any article".
The second RfC that this new RfC is trying to overturn is:
The result of that RfC was that the "in all Wikipedia articles, without exception, nonreligions should not be listed in the Religion= parameter of the infobox.".
Note: I am informing everyone who commented on the above RfCs, whether they supported or opposed the final consensus. -- Guy Macon ( talk) 03:07, 26 June 2017 (UTC)
Sorry, I don't know what kittens are for, but I just wanted to let you know that I really like your comments on Talk:John_A._McDougall ! Well-reasoned, detailed, calm, and professional, even in the face of angry editors!
Sjb0926 (
talk)
01:45, 21 January 2018 (UTC)
Moved from Veganism Talk page, as this is not about veganism. -- Zefr ( talk) 20:21, 26 February 2018 (UTC)
Hey Zefr, I noticed that you did some editing to the NIH reference on Vitamin B12. I was the one who filled out that citation and made the changes you seem to have partially reverted, so I am naturally curious about your rationale. Was my edit, or at least the parts which you reverted, inappropriate and why if so?
Just to clarify, I added the archive as part of my usual citation cleanup to prevent
link rot and preserve a snapshot of the cited material to ensure that changes in the source itself do not accidentally undermine the point of its citation in the article. I added the author
parameter per my interpretation of the template documentation at
Cite web § Authors and
§ Publisher and because I have never seen the publisher
parameter defined in that way in any citation I have encountered. My addition of access-date
is for obvious reasons; I understand that it might not be required for this particular source, as may be the case with webpage archival, but I consider it good practice to include anyway. Do you believe I am mistaken about any of the aforementioned? Is there some precedent or policy about which I am not aware?
I am not disputing your edit so much as I am asking for clarification. Of course, I prefer the content of my edit be retained, but I might as well ask for your opinion here rather than just revert it. I also understand that this may seem like a rather minor issue, but this is typical editing behavior on my part, both generally and within this particular article (see my other citation edits). As a result, this minor issue actually has significant importance about the citation style in this article, especially since I have cleaned up and filled out multiple citations in this way and intend to do so with others. If you take issue with such edits, as you seem to have done here, then perhaps you could inform me about why I should change my editing behavior. Thanks for your time. ― Nøkkenbuer ( talk • contribs) 06:00, 26 February 2018 (UTC)
author
beyond the aforementioned is because the documentation specifies it is appropriate "to hold the name of a corporate author", which I took to mean that non-person entities are allowed (unless I misunderstand what is meant by "corporate author"). Do you disagree? If so, then given you described it as a "department" (and since this was my second choice), do you think the ODS might be better placed under
department
, despite being left undefined in the
Cite web documentation? There is a brief definition in
Cite news § Periodical, which is almost certainly applicable in Cite web, but that doesn't provide much clarity either. Would that be better in your opinion? As for archival, is there any issue with including it anyway despite perhaps not being necessary? I fail to understand why, as a general practice, one should ever exclude archival so long as there are not specific reasons for doing so, especially since
WP:LR states that (my emphasis) "[e]ditors are encouraged to add an archive link as a part of each citation".Lastly, more generally, do you take any issue with me otherwise filling the citations in this article as I have been? If so, and you suspect more reversions will be likely, then some attempt at addressing it now might be appropriate. If not, then after whatever decision is made about this particular citation, I will just proceed with my usual editing. Naturally, my questions are not just about this specific citation, but about this issue as a basis for informing better editing practice overall, so I hope you do not take this is just pedantry on my part. ― Nøkkenbuer ( talk • contribs) 17:37, 26 February 2018 (UTC)
author
is at best a dubious parameter for something like the ODS and that, upon retrospect, department
would have been better if it is added anywhere outside publisher
at all. I only opted for the former since it was more common, it seemed to qualify, and the latter was even less clearly defined.As for the archival parameters, I would still retain them in this instance (and almost any other instance) because I consider an archived copy of the exact page that was used for the citation to be more important than excluding the information on the basis of code minimization. Given that you seem to disagree, though, and favor the latter over the former, I will just leave the citation as it currently is (after readding the access-date
). I have no interest in disputing this just to make a point and risk it being mistaken as
POINTy, and I recognize that this NIH article will probably not be going anywhere for the rest of Wikipedia's life. Whether this particular citation lacks it does not matter much at this time, so I'll just
drop it.Again, I appreciate your input. Have a great day! ―
Nøkkenbuer (
talk •
contribs)
22:57, 26 February 2018 (UTC)I have started the draft here :) Étienne Dolet ( talk) 03:01, 27 February 2018 (UTC)
Generally we stay away from these journals as there have been concerns raised about them. Best Doc James ( talk · contribs · email) 03:38, 25 March 2018 (UTC)
Well... I concur ;-)
It is true that increase in intra ocular pressure can cause vision loss. However that is also a "logical" elaboration... Which I did call sophism; sorry about it.
That kind of statement is of nature to instigate fear; and in the case of the given article, it might never happen.
Indeed the intraocular pressure increase is in the range of normal variation [actually it might be variation between individuals, and not variation in time, so I might be wrong on that point, I'm not a doctor].
So, even though I do share the opinion it is a bad thing, I believe it is an overstatement to say it can lead to vision loss in that specific circumstance.
I believe that a specific source, pointing to actual vision loss, in that specific circumstance, would be required: like, does an increase of 2.79 mm Hg, sustained in time, would lead to significant vision reduction. Does the 2.79 mm Hg persist in time? How long? Would several consecutive injection lead to cumulative effect? Those are to be assessed by further investigations IMO.
Feel free to revert my change. I like the idea that gluco-corticoid II injection should be dealt with utter care. However I fear that overstatement could compromise the overall credibility of the article.
Best, Chris — Preceding unsigned comment added by 82.121.15.217 ( talk) 14:01, 18 April 2018 (UTC)
Since the previous wording (without the clause) in the Osteoarthritis article did not detail the significance of this study nor why it would matter that an association between intra-articular knee injections with triamcinolone and increased intraocular pressure was noted, I decided to include that clause so that the reader would understand its importance from the article text alone. To do so, I simply restated, in different words, what was already in the cited source.With that said, I have no particular opinion about its inclusion nor even about this topic, about which I personally know little. I had not considered the concerns you have expressed, however, since my focus was on simply explaining the importance of the study with its own claims and not whether the explanation itself might be mistaken as fearmongering. I appreciate you pointing this out, since although I do not personally see that as much of a concern, I see how it might be and understand that the exclusion of that statement might therefore be warranted.If you still think that the vision loss clause ought to be excluded, then either you or I can also remove it from where I transferred that text and citation in Triamcinolone § Side effects. I will await your input and if you would rather me remove it, just let me know and I will do so. Thank you.On an unrelated note, I want to say that your edit was obviously constructive and that this talk page message you left me demonstrates a commitment to that constructive approach, at least to me. I appreciate that and invite you to consider creating an account, which provides many benefits that may interest you. Of course, you don't have to do so and can continue to contribute to Wikipedia as an IP address. Naturally, it is entirely up to you; however, especially given the prejudice some users have against unregistered users, I would hate it if your contributions were reverted or prejudged simply because the "account" was an IP address. Regardless, I wish you the best and look forward to whatever further input you may have. ― Nøkkenbuer ( talk • contribs) 17:15, 18 April 2018 (UTC)BACKGROUND: Intraarticular steroid injections are a common first-line therapy for severe osteoarthritis, which affects an estimated 27 million people in the United States. Although topical, oral, intranasal, and inhalational steroids are known to increase intraocular pressure in some patients, the effect of intraarticular steroid injections on intraocular pressure has not been investigated, to the best of our knowledge. If elevated intraocular pressure is sustained for long periods of time or is of sufficient magnitude acutely, permanent loss of the visual field can occur.
Thank you for your edit generalizing my mention of the editor NoteTab. David Spector ( talk) 20:44, 24 April 2018 (UTC)
Just wanted to let you know that I'm the assistant editor in Chief of The Signpost and read your feedback on the last issue's opinion piece by Hurricanehink. Your detailed explanation of the content you like and want to see more of is appreciated. We are thinking hard about this in the context of improving, reinvigorating and sustaining a great publication, and your input means a lot. ☆ Bri ( talk) 19:27, 30 May 2018 (UTC)
You probably saw my revert edit summary, but in case not: Please do not do this. It makes the code extremely difficult to read for humans, for zero benefit of any kind whatsoever. — SMcCandlish ☏ ¢ 😼 19:14, 24 June 2018 (UTC)
This is also not helpful (actually worse than unhelpful). Code syntax highlighting is for making blocks of code easier to parse by visually organizing different code elements by type, e.g. so that variables are distinct from neighboring commands/functions/elements). It has the opposite effect when applied to a single word of code inline in regular text; people wonder "
WhyTF is this text green?" The proper markup for inline code is <code>...</code>
(or templates that use it like {{
tlx}}
). —
SMcCandlish
☏
¢ 😼
19:37, 24 June 2018 (UTC)
PS: Lest I sound excessively critical, highlighting can be helpful in "extended" inline cases like this (your edit, combined with my restoration of readable CSS). :-) — SMcCandlish ☏ ¢ 😼 19:44, 24 June 2018 (UTC)
<code>
provides. Tangentially, and much less importantly, it beautifies the code in a way that I think is appealing to readers and can even attract those who are otherwise disinterested in coding to the practice. In fact, I think that highlighting code syntax, even within prose, has no downside in virtually any situation, especially when compared with <code>
, because the improved visual display provides readers and editors with more readable code that technically decreases ambiguity.Regarding the potential confusion that inline syntax highlighting might cause for readers, I think that syntax highlighting is both intuitive and obvious even for those completely unfamiliar with coding. The entire purpose of syntax highlighting is to improve human readability by clearly indicating the syntax such that it is distinct from other syntax and from non-code text. I think this is true regardless of whether it is embedded within prose, including where a {{
tag}} or <code>
might be used. This is especially so since, as mentioned above, the situations in which it is almost always used are either within articles and documentations which are about syntax-highlightable code or otherwise include a nearby syntax-highlighted code block.When it comes to backend template documentation in particular, I suspect that Wikipedians as a group are much less likely to be confused by syntax highlighting than the average reader, especially those who edit the source and rely on template documentation. This is even more relevant now that wikitext syntax highlighting is already used by a large percentage of Wikipedians, primarily thanks to
Syntax highlighter and
Wikitext editor syntax highlighting. Since Wikipedians are the ones who are most likely to even find template documentation, particularly those engaged in editing that requires some familiarity in basic coding, I considered inline syntax highlighting in template documentation to be the least controversial changes to
boldly make among these sorts of edits.I am not aware of any policy, guideline, or essay that discourages such syntax highlighting usage; that absence was partly what encouraged me to proceed on what I believed were the merits of my rationale. Are there any of which I am not aware? If not, then is this just your personal recommendation? I value that, too; I am just trying to understand whether this issue had been addressed elsewhere. If you still think I should avoid editing like this in the future, or even to begin self-reverting those kinds of changes throughout Wikipedia (such as in
Template:Quote/doc), then I suppose I can. I naturally see these edits as constructive improvements, though, so I am hesitant to do so, especially when it is unclear to me what damage I am doing.(
TL;DR) My rationale for these kinds of edits is to ensure consistent syntax highlighting and to take full advantage of its benefits. I see no downside in doing so; if anything, it can beautify the text and attract people to the beauty of that code while improving the experience for both readers and editors. I think syntax highlighting is intuitive and obvious to understand, especially for Wikipedians but also for those ignorant of basic coding, so I do not think such potential confusion is much of a concern. This is especially so for obscure backend technical articles like template documentations, doubly so because of coding competence and syntax highlighting popularity among Wikipedians. Is there any policy, guideline, or essay that is relevant here? I am aware of none. I can stop or begin self-reverting, but I do not understand what damage I am doing here, since I think these are constructive improvements. Thank you for any further input.P.S. – Regarding
this edit of mine and
your subsequent change, the compressed version without the spaces is actually necessary for full <
syntaxhighlight>
highlighting. I assume that this is because the syntax highlighting makes it human-readable beyond what simple spacing does, so the spacing is superfluous. For example, compare the following:Markup | Renders as |
---|---|
<syntaxhighlight lang="CSS" inline>margin-top:0;margin-bottom:-0.5em;</syntaxhighlight> |
|
<syntaxhighlight lang="CSS" inline>margin-top: 0; margin-bottom: -0.5em;</syntaxhighlight> |
|
<
syntaxhighlight>
. —
Nøkkenbuer (
talk •
contribs)
00:50, 25 June 2018 (UTC)
<strong>...</strong>
". The green of that looks pretty much just like {{
bxt}}
(which conveys something like "please definitely use this green example material"). We're not trying to tell people what markup to insert and how to format it; we're just trying to tell them the template uses the <strong>
element. The syntax highlighting is an actual benefit – when it works properly – in blocks of code (including inline ones with multiple differently-highlighted things in them), but it isn't helpful otherwise, especially when all it does is colorize one thing without a reason that'll be clear to the reader, most especially if it conflicts with other markup we've been using much longer. like the {{
xt}}
template group. I.e., we already had a coherent approach to code markup before <
syntaxhighlight>
even existed, and while the latter is useful for some things (when not broken), it's not a hammer for which every potential problem is an identical nail.That is, hyper-consistency toward syntaxhighlight isn't taking account of a) whether it actually works for a particular example, b) context (including editorial intent and reader interpretation), or c) conflicts with other consistencies implemented for other (sometimes more important) reasons. This kind of "consistency conflict" is one that we encounter frequently in "style" matters more broadly. An important consideration for mainspace in particular is that
WP:MOS, like all professional-grade, formal-writing style guides, is dead-set against introducing extraneous stylization of any kind, and is minimalist for good reasons (especially
MOS:Accessibility ones, but others as well, including
MOS:TONE,
WP:NOT#BLOG, and others.) For example, the
HTML element article has pretty much forever been using markup like '%block;
and %inline;
are groups within the HTML DTD that group elements as being either "block-level" or "inline".' It's unobtrusive, helpful, and what W3C and WHATWG actually recommend and intend. We later started marking up the code blocks with the then-new <
syntaxhighlight>
. As long as it works properly, this is (for the reasons you've written about above) also arguably helpful (honestly, I'd like to see an accessibility analysis of the color choices, but I presume on good faith that one has been done at some point). However, someone since then has done something not helpful at all: they've gone around and put <
syntaxhighlight>
around every single thing, in mid-sentence, where they can get it to do anything. This is causing "outbursts" of pointless color all over the place, and even producing sentences with grossly inconsistent markup, as in 'Lists with <ul><li> ...
are %block;
elements ...' Not helpful to any readers, and not an encyclopedic approach. It's just haphazard decoration for its own sake and needs to be undone. (I've raised the issue at that article's talk page.) To the extent someone thinks this is some kind of a consistency/conformity improvement, they're making a mistake; it's a type of
hypercorrection that fails to take into account context, intent, and effect. When all of MoS is indicating not to apply extraneous stylization, we don't need to add a special line-item for each imaginable form of extraneous stylization, or MoS would be 10 times longer than it is and no one would read it or remember any of it.
—
SMcCandlish
☏
¢ 😼
12:32, 25 June 2018 (UTC)
<
syntaxhighlight>
and templates that utilize it, such as {{
code}}, are infrequently used and especially rare within prose—at least, properly used and when compared to alternatives like <code>
, {{
tag}}, and so on. Consequently, there is not much use case history beyond the basics that can discover them, especially in edge cases. This is compounded by the fact that simply using <code>
is far more common, both because the extension is new and somewhat more complex and because the latter HTML markup is a decades-old international standard. In my usage of the extension and its implementation in templates like {{
code}}, I have noticed various problems, as well. For example:<code>
, which seems like a pointless inconsistency in the visual display;<ref>...</ref>
in {{
code}} will create a reference unless <
nowiki />
s are used break the code, in which case direct <
syntaxhighlight>
markup with the inline
attribute is less complex and verbose;|style=
using {{
para}} as shown in
Template:Quote/doc § Vanishing quotes (
permanent link), though this limitation is at least understandable given how difficult that may be to code; and<var>...</var>
markup into highlighted syntax that is not itself then escaped and highlighted, which makes highlighting code with properly marked variables impossible, but this is again another limitation that I understand may be infeasible to address (especially given this is a limitation with <
pre>
as well).In an article, we're using color – very sparingly – for a tiny handful of quite specific things, and even this has its detractors. Introducing more of it in main article text is confusing for readers who expect only a very narrow class of directly "actionable" things in the article to be colored text. It's essentially the same UX and usability problem as making icons that look like buttons but which are not. Another way of looking at it: We have lots of color markup templates that we use internally for special purposes, like {{
strongbad}}
and the {{
xt}}
family, and {{
tq}}
, but we do not use them in articles, because it's the wrong output context for such visual gimmicks. (It's actually no possible to use some of them in mainspace, and they probably all need that namespace test installed.)
The "consistency" of having one or two-word bits of source inline in a sentence match the colorful SH layout of a large code block is a consistency we don't need, rather like putting pepperoni on an apple pie because they're both baked round things. It's possible to apply this markup inline it but it usually doesn't serve a useful function, and interferes with more important consistencies and goals. By way of another analogy: there's a real-world fad to arrange bookshelves by the color of the books' spines, to create an interesting decorative effect. But only someone who doesn't actually read these books and just has them as décor would ever do such a thing, since it makes finding a particular volume next to impossible. (I know from experience; I dated someone who did this. It didn't work out.) The in-prose markup and presentation (already marked up with <code>
semantically anyway) serves a completely different function from code-block markup, as arranging books by topic or author (or the latter within the former) rather than by color has a different function that arranging them in color patterns to turn one's book wall into an artistic display. (Not a perfect analogy, since the code block SH isn't artistic but functional, just differently functional – yet using it inline is mostly and often entirely decorative not functional).
Sorry if this is repetitive with the above; it's been a while since the discussion was active.
—
SMcCandlish
☏
¢ 😼
02:46, 20 July 2018 (UTC)
color markup templates", since their functions are irrelevant for mainspace article contexts. That is not the case for syntax highlighting, especially in articles and documentations that display syntax-highlightable code and particularly in those that already have syntax-highlighted code blocks. So, how specifically is this expanded use of inline syntax highlighting harming user experience or human readability, both of which syntax highlighting is intended to improve?The best I can tell is that you seem to believe I am using syntax highlighting outside of what you believe to be its proper context. It is upon that conviction that rests the conflict in our perspectives regarding the functionality and value of the expanded (or "
misuse[d]") syntax highlighting I had been implementing, since the "context" for syntax highlighting to me is simply any context in which syntax-highlightable code is used (with exceptions) whereas you favor a more restricted context that is generally confined to code blocks and complex code strings (with exceptions). That is why I consider syntax highlighting to be strictly an enrichment of the text that "
has no downside in virtually any situation" and why you consider it "
a type of hypercorrection that fails to take into account context, intent, and effect". In a sense, I have an "inclusionist" approach to inline syntax highlighting for which exceptions to a highlighted norm require justification and you have an "exclusionist" approach to it for which exceptions to the more restricted norm require justification.Like I stated before elsewhere, I think I understand your perspective and why you maintain it. For you, the function of syntax highlighting is to improve human readability of code in contexts wherein the code's syntax and structure are sufficiently complex that colorizing them does so. That is an uncontroversial and accepted evaluation of syntax highlighting, one with which I also agree. That was also the extent of my position on syntax highlighting since learning about it years ago, which only recently changed after I considered the relationship between inline and block code and what effects inline syntax highlighting might have. That led to my present position.For me, the enrichment that syntax highlighting provides in such restricted cases also extends to all inline code, including simple code, and this extension reciprocally reinforces the original enrichment that syntax highlighting provides in complex code. Doing so resolves the contradictions and ambiguities in the relationship between the inline and block code texts, as well, which were introduced by the more restricted use of syntax highlighting. Thus, the primary benefit of this extended and expanded use of syntax highlighting is to address problems in the context itself, in the second-order relationships between first-order components in the texts. That is basically what ensuring consistency as a functional attribute (rather than an aesthetic one, though they are not mutually exclusive) is about.From the perspective of the casual reader who is unfamiliar with programming or markup of any kind, I think the result of these abstruse contextual alterations is a more intuitive user experience that no longer has needless complexity and lingering ambiguity between inline code and block code texts. That reader may still ask "Why is this text a different color?", but that is a question applicable to all syntax highlighting. With all code syntax highlighted, though, the reader will no longer ask "Why is this code colored while that code is not?".Syntax highlighting as currently deployed is technically unable to provide such a total syntax highlighting due to some of the limitations described above, but that is why I encourage improving the extension rather than rolling back the expanded inline deployment. The latter just maintains the original state of affairs with the same problems I believe I have identified. Unfortunately, it seems that the latter has occurred given your changes at HTML element (and elsewhere?), despite what appears to have been both implicit consensus at the article (including before I arrived) and no consensus at the now-archived WT:MOS discussion (one user had no specific comment on this issue, but supported your general proposal; the only other uninvolved participant seemed to support the expanded use of syntax highlighting). Nonetheless, I have not returned to that sort of syntax highlighting editing since there is other work to be done, though I still maintain the same position. Moreover, I will not restore any syntax highlighting that has been removed, at least not unless and until this is resolved with consensus-based support for doing so.Given this sustained disagreement and the lack of input from uninvolved users when informal talk page discussions were initiated about it, an RfC or some other resolution process may be due now. I have explained (and almost certainly overexplained) my position enough at this point, so if any such resolution process is initiated, I will simply refer others to these initial discussions unless summaries are required. Is that acceptable for you?Lastly, thank you again for your time and willingness to discuss these matters at length. This matter is not urgent, so feel free to take some time before replying, as well, if you decide to do so. Have a great day / night. — Nøkkenbuer ( talk • contribs) 20:25, 1 August 2018 (UTC)
{{
!xt}}
and {{
talk quote}}
and {{
strongbad}}
). Even the limited use of inline color has detractors; the
WP:SEAOFBLUE principle has us linking much less than we could (possibly should – people debate this), just to avoid colorizing more of the text.By contrast, you want there to be consistency within the article (and presumably across articles) such that <cite>...</cite>
appears exactly like that, no matter what context in which is appears. I sympathize. I'm legendary around here for "pushing" consistency arguments. "Oh, no, here come that consistency guy again." People in various wikiproject verge on actual hatred of me because I agitate against their
WP:CONLEVEL-problematic attempts to fork a "special" naming pattern, layout, spelling, punctuation, etc. away from site wide norms. The difference is that <cite>...</cite>
looking like that is just arbitrary. It's not a consistency WP actually needs, that readers want or which will be meaningful to them. The semantic job is done by plain <code>
markup around code example. Colorizing it further serves no contextual purpose where it found, inline, but it does interfere with the contextual purpose of color we already use inline (especially red and blue).<nowiki>...</nowiki>
</code>
Conceptually, this entire issue is basically identical to the one that led to the creation of the
MOS:ICONS guideline (in any thing like its present form; I would know, since I wrote it
[2]!) There was a habit of sticking flag icons before/after country names (or as stand-ins for them) at every opportunity. Fans of the idea were convinced that if it was okay/useful to do it in one context (e.g. an Olympic medals table, a context in which flag icons are consistently used in the real world), then it must be okay to do it at every mention of a country in an infobox, a list, a table, a navbox ... and why not at first occurrence, at least, in the prose itself? What started as the
WP:FLAGCRUFT essay was fast tracked into the
MOS:FLAGS guideline. Shortly thereafter it became the
MOS:ICONS guideline: We found that people were doing things like inserting things like
I-35 in mid-sentence in articles to mark up highways, and similar things were being done with railway lines, train stations, and a zillion other things. All for the same iffy rationale: If we're doing it in the junction table in the infobox or some other data-presentation context, why shouldn't we do it everywhere, including in sentences? The community rejected the idea. The guideline was then expanded to cover Unicode/ASCII dingbats and other things that aren't technically icons (unless they are the actual topic of the material, of course, e.g. at
Quotation marks or
Dagger (typography) we have to illustrate the glyphs under discussion). Then it was extended to include emoji. Now we have an open discussion about extending it again to cover things like
BR being used in mid-sentence (that's done entirely with HTML and CSS, an image-free way to simulate a graphical icon).
That's really not any different from <cite>
: Use of markup to create extraneous decorative appearance, in the name of being consistent with actually appropriate use of color in presentation of complex data. It's a tiny, pointless consistency that bollixes up the much grander consistency of simple, readable prose, with inline color used for a single, specific, predicable purpose across the whole site.
PS: I'm generally in favor of using {{
code}}
in inline multi-part code samples; you may have noticed that I preserved this at
HTML element to the extent possible despite the trouble it causes in the edit-view wikimarkup syntax highlighter (and my work over there recently was an overhaul
[3], not just a "get rid of this coloring" tweak). But people are actually likely to object to even that much of it, when used in mid-sentence that way.
PS: I hope this wasn't very repetitive; we've gone over this "consistency philosophy conflict" or whatever we want to call it at such length and in some many pages I forget exactly what's been said before.
—
SMcCandlish
☏
¢ 😼
22:12, 1 August 2018 (UTC)
<br />
", yet we opt for the latter. I still do not think this is decorative, since syntax highlighting in the way I was adding is more comparable to the functions of syntax highlighting in code blocks or the gray background boxes around <code>
s than to the decoration of icons and so on.Nonetheless, I am only aware of one user attempting to implement syntax highlighting in the way I had been, namely myself, and attempts at attracting more attention to it have thus far been met with little interest. Additionally, regardless of whether this use of syntax highlighting is (exactly) comparable to the issues which led to the development of
MOS:ICONS, the similarities between the two are enough that I suspect those who do not maintain my position will find it persuasive. If this issue were to be the subject of an RfC, I now anticipate the response to be generally in opposition even if a more restricted support for it in articles such as
HTML and
HTML element develops. I prefer explicit consensus here to at least clearly indicate the community's opposition to the less restricted syntax highlighting I had been implementing; however, given the fact that vaguely similar issues in the past have been met with consensus against them, and that I now anticipate consensus against it here as well, it is probably counterproductive to push for any at this time. Anyway, since the technical limitations with <
syntaxhighlight>
presently render the sort of total syntax highlighting I support infeasible, my case for consistency here is severely weakened. This is especially so when the color scheme and scope used by the extension appear to be largely arbitrary and inconsistent with syntax highlighting implementations used even within Wikipedia (such as wikitext highlighters).Lastly, this is frankly not a big enough deal. Sure, it's inconsistent to me and not what I prefer, but I don't see either visual display to be obviously confusing or disruptive to the prose (unlike icons). The best-case scenario one can reasonably achieve with the implementation of a more total syntax highlighting is somewhat better site-wide consistency which addresses a marginal second-order concern that, as you noted, neither readers nor even other editors appear to be wanting. My proposal may be a solution, but it is for a problem that is not significantly acknowledged as one (and is even disputed as one), and so probably seems to many as a case of the former in search of the latter.With that said, I once again appreciate your discussing this with me. In particular, I appreciate your detailed replies, whose explanations have been clear and compelling enough for me to reconsider my position. My proposed syntax highlighting usage is at best a minor stylistic change whose improvement is disputed and whose interest from the community is almost nonexistent. Perhaps that will change and some other editor will have a similar proposal in the future, but until then, this is not worth further consideration. Thank you for your time. —
Nøkkenbuer (
talk •
contribs)
19:45, 5 August 2018 (UTC)
<
syntaxhighlight>
extension is improved, I'll probably just find other stuff to do and not bother with inline syntax highlighting within articles. —
Nøkkenbuer (
talk •
contribs)
01:14, 16 August 2018 (UTC)
{{
code}}
template to highlight markup fragments has a strong tendency to break syntax highlighting in the wikieditor. For example:
{{code|lang=html|code=<ul><li> ...}}
{{code|lang=html|code=<ul><li> ...}}
<ul><li> ...
{{
tag|code|o}}
markup (as I just did with that template – self-referential loop!) or by hand tweaking it, e.g. "Using a backslash is invalid markup, a common error by MS Windows users: <code><nowiki><\code></nowiki></code>
". —
SMcCandlish
☏
¢ 😼
02:46, 20 July 2018 (UTC)
<
syntaxhighlight>
HTML extension itself with an inline
attribute would not cause this, since the closing tag must be defined.As for escaping markup within {{code}}, that seems to be an issue with <
syntaxhighlight>
itself since escaped characters do not work within any present implementation of the extension, block or inline. As you probably already well-know, characters can be escaped using <
pre>
s, so it's not like this is an unfixable limitation. Perhaps another phabricator ticket (or two) is due? —
Nøkkenbuer (
talk •
contribs)
20:25, 1 August 2018 (UTC)
{{
code}}
is that it only accepts raw input; there appears to be no way to escape anything, including as HTML character entities – it just gives you the character entity codes not the character. It's a very "blunt instrument" and even its own documentation suggests other approaches for various situations. The idea that it could become a general standard, for use in mainspace, just isn't viable. —
SMcCandlish
☏
¢ 😼
22:12, 1 August 2018 (UTC)
apologies, copied the ref from the "research on meditation" article; did not realise it did not work here . JCJC777 (talk) 19:07, 24 June 2018 (UTC) JCJC777 ( talk) 00:58, 25 June 2018 (UTC)
I'd prefer if you didn't refactor Signpost pages just to add square brackets for ellipses. Per MOS:ELLIPSIS, "An ellipsis does not normally need square brackets around it, because its function is usually obvious." There is no other style guidance especially for the publication that I know of. ☆ Bri ( talk) 22:27, 29 June 2018 (UTC)
There's a much simpler replacement for:
[[Wikipedia:Page name#Section name|Wikipedia:Page name § Section name]]
It's:
{{
slink|Wikipedia:Page name#Section name}}
May it serve you well. — SMcCandlish ☏ ¢ 😼 18:18, 19 July 2018 (UTC)
{{
slink|Wikipedia:Page name|Section name}}
but I got it fixed so it parses the # syntax. —
SMcCandlish
☏
¢ 😼
01:49, 20 July 2018 (UTC)
![]() |
The Signpost Barnstar | |
I would like to thank you on behalf of the editorial team for all the hard work you put in behind the scences for The Signpost. It's very much appreciated.. Kudpung กุดผึ้ง ( talk) 02:27, 1 August 2018 (UTC) |
Thanks for your diligent work on the citations in this issue! Be aware that these come from a Zotero library. (As part of the production process for Recent Research/the Wikimedia Research Newsletter, we use Zotero's automated import function to generate an entry from the publications' web pages, and then Zotero's Wikipedia export feature to generate the citation templates you saw.) This library is also used in other ways (e.g. in the past Dario and I have published an annual corpus of all the research publications covered during that year, and together with Masssly we aim to do so again). Unfortunately your improvement work will be lost for that purpose; at least I don't know of an easy way to backport such changes into Zotero again. But if you are interested in working directly at the source instead, we could give you access to the Zotero library - just let me know.
In any case, thanks again!
Regards, Tbayer (WMF) ( talk) 14:30, 1 August 2018 (UTC)
lost for that purpose", but if you mean that it is not retained during syndication, during publication of the "
annual corpus", or it is otherwise only preserved at the Signpost copy, I don't mind since my initial motivation for editing was with the understanding that it only affects that local copy. Only within the past few days, as I learned more about the Meta Research newsletter, did I discover that last month's issue included the changes I made.Relatedly, on the latter topic, I noticed at its history page that it was cleaned up by you and Masssly. Much of it involved localizing the publication to Meta, particularly the wikilinks and templates. Now that I'm aware of this, I don't mind localizing it at m:Research:Newsletter, as well, especially since it appears that much of it involved code I added or modified. I wouldn't want my changes to produce more need for cleanup and review, which is contrary to the point of those changes.Regarding access to the Zotero library to edit the source directly, my immediate concern is that it may be well beyond my competence in coding of any kind, which is currently limited to MediaWiki and HTML. I can generally understand what is going on in other markup and programming languages, but I do not consider myself at all skilled at coding with them beyond minor copy-and-paste modifications. Moreover, I am completely unfamiliar with Zotero and only learned about its existence recently. Unless the editing process at Zotero is basically similar to the VisualEditor or Wikidata, wherein there are data fields I can fill and modify without having to directly manipulate any JavaScript or install any software or whatever; or it otherwise accepts MediaWiki markup; I discourage giving me access because I am almost definitely not competent enough to be helpful at this time. Regardless, thanks for the offer. — Nøkkenbuer ( talk • contribs) 17:50, 1 August 2018 (UTC)
Hello, Thank you for your message. Having looked more thoroughly at the article it is obviously of high quality and should be rated at least B. The removal of the Americas project is because I assumed that every article in the Indigenous peoples of North America project would not be included in it. That way the two projects could economise on the amount of editing of Talk pages. In practice it seems that this represents what generally happens. The Americas project has less than 4000 articles but the North American one has over 10,200.-- Johnsoniensis ( talk) 15:49, 5 August 2018 (UTC)
I continued the discussion in the Teahouse, because I didn't know any other way to keep George Van Valkenberg in the loop. His personal information would be original research, but he might suggest other topics or names to use in searching for citations. The notability of Project Harvest Moon (PHM) probably rests on its role as a precursor to private enterprise's role is space exploration. When the project died (July 1972), another initiative, "Mankind One" (also ill-fated), sprang from its ashes. I don't plan to follow "the Committee for the Future" beyond 1972. As it stands at the moment, PHM may prove an orphan. Hope that will change. Anobium625 ( talk) 15:37, 17 August 2018 (UTC)
Thanks for the "external link" explanation in the Teahouse. Yes, as a subscriber, I paid for all my sources. I now have enough names and topics to seek external sources. Anobium625 ( talk) 15:49, 17 August 2018 (UTC)
Greetings Nøkkenbuer,
You've recently posted on my so-called "talk page" and have voiced a few concerns. I've decided to respond to you via this weird goatesque message, because this way I can be sure my message will get across (I think?). If I edited my talk-page I wasn't really sure how exactly would you be notified and I don't know how to create a new topic on your talk page (I could only edit a pre-existing topic and I didn't want to fiddle with your talk page like that). So I guess this will have to do.
Firstly, thank you for the kind but undeserved words. I am evidently not a good editor, my technical/IT skills are abhorrent and (as you have noticed) my manner of communication is sometimes confusing. I am specifically referring to the unreferenced quotation marks here.
In some places where I've used quotations that an author has explicitly said, I cite the work in which they've said it. In other times, I use quotations to emphasize a certain keyword, when I figure that itallics (or just itallics) won't do the trick. This is how I usually proceed with emphasis in personal writings, but I understand that this can be regarded as quite confusing in a wikipedia article. My apologies for this inconvenience, I shall try to adress and re-edit the issues as soon as I am able.
"I noticed that some of your paragraphs lacked any references and it was unclear whether they were supported by any of the references you did include."
A correct observation indeed. My intention was that, by referencing a specific paragraph, the rest would be assumed to be stemming from the same source. I thought that if I referenced the entire text, it could result in larger confusion. But this assumption seems to have been false.
Another reason why I say your compliments are undeserved is because I do not consider myself an expert on the particular topics. I've read a few books that deal specifically with these topics and it just so happened that I noticed that precisely these topics were lacking in information and clarity. This is why I decided to edit them and add some depth into them. If someone does decide to revert/re-edit them before I check the references, I do hope they leave the crucial information or at the very least supply their own proper version of the crucial information.
Once again, thank you for the warm welcome and thank you for your time!
Sinveil ( talk) 00:43, 20 August 2018 (UTC)
Sinveil (
talk)
00:33, 20 August 2018 (UTC)
[[User:Sinveil]]
would ping you. It can also be
piped, as with [[User:Sinveil|text]]
, and it will still work. For discussions, however, many users use a template method, such as {{
user link}}
, the shortcut of which is {{
u}}
. (Templates do not work in edit summaries, so using it in one won't ping anyone.) For example, check the text of "Hello
Sinveil!" while in edit mode; it uses that template and is technically what notified you in this reply.Humility is often a result of having developed competence in something, so yours won't fool me. Don't worry or
be ashamed of your current unfamiliarity with
MediaWiki syntax and Wikipedia editing, or with any of the other potential
newbie mistakes you might commit. Your account isn't even a day old! If anything, that not being the case would be
cause for suspicion. Be proud that you're learning; you can save feeling embarrassed for when you check your early edits a few years from now.With that said, on the matter of your edits, I entirely sympathize with your concerns about citing sources at the end of a paragraph when not all of the paragraph is properly sourced. In such situations, however, it's probably better to have at least some reference to support something in the paragraph placed somewhere therein, since sourcing takes precedence over
text–source integrity. Anyone wishing to
verify the claims can figure out what it supports; they can't do that when there is no source! Additionally, in a way, citing a source at the end of every paragraph at the very least is better text–source integrity than not doing so. There are also some rather technical and obscure templates that can assist there, but that's not important right now; they're almost never used, anyway. If you don't even have a source for any of the other content you're adding in a paragraph, though, then that is probably a good reason to not add that other stuff until you do for the reasons I explained before.Reading "a few books that deal specifically with these topics" is frankly more than probably most editors in the edit histories of articles have done, especially the minor contributors. Regardless, expertise is something that needs no teacher, and simply being familiar with a subject due to having read literature about it is already very valuable for an editor to have. What's important is that an editor is invested in understanding and improving that which they are editing, which has already been demonstrated by you from your first edit.On the matter of addressing these sourcing concerns, please don't panic as if the world will end tomorrow. It's good to address these concerns with due haste, but being unduly hasty is not only stressful but may worsen the quality of your attempts to do so! If you are reverted while you are doing so, or if you are regardless, take it in stride and discuss it if you think you should. If you are at an impasse with an editor, there are various ways of achieving dispute resolution. The focus is on improving the encyclopedia, which includes improving one's own edits. So long as you do that, and you make sure to listen, engage, an explain yourself in a civil way (like you have done thus far), I don't think you should be at all concerned about any enforcement coming your way. As for the behavior of other editors, though, well... some do bite.Lastly, to emphasize it once more, feel free to ask me any time if you want any help, or check out the other venues for asking questions. Wikipedia would be nothing without it's editors, so retaining the good ones can more important than editing itself. — Nøkkenbuer ( talk • contribs) 02:14, 20 August 2018 (UTC); edited at 02:22, 20 August 2018 (UTC)
Thanks for the welcome! I thought I would try my at hand at helping to improve some of the subjects I am knowledgeable in as I use Wikipedia probably every day. So, as they say, leave it better than you found it, right?
I appreciate the heads up on my edits. I will keep practicing on the various Wiki functions and hopefully can become a valuable editor for the community.
Alevings1 ( talk) 14:47, 24 August 2018 (UTC)
Hi Nøkkenbuer, thanks for the message. Certainly not overwhelming; but I am genuinely ridiculously busy at the mo, so excuse me if I kiss a couple of points. First, I appreciate your epistemological and pragmatic avoidance of concurring in mt claim to be her daughter; but may I politely point out that googling the two names should confirm this claim, at least to the satisfaction of the pragmatist.
Oddly, I thought I had entered her in Wikipedia; but if as you say I didn't then yes I certainly signed up to eliminate the early inaccuracies. Further to that, I also see that I may be seen as biased (I do like her poetry and consider it under-exposed at the moment). But I would really like to know whence other than from me or my son or cousin you would look for information. Her publishers, John Rolph and Harry Chambers, are both dead; there are no biographies, and the obits were all written by people who called me for the facts. There will be a few ex-colleagues and more ex-pupils; they do not know, for example, her educational history...
As for the Indian perpetration - no, that is not me! I divine as you do that he has fished up a picture online without realising that clicking IMAGES on a Google search gives images that are not all, or most, (or even any) of the person whose name you've input. I am angry about this. Yes, it is a pic of me; yes, I could at some time appear myself in Wikipedia (it is possible given that I am an actor and a writer who have just got into my stride after a few decades of mothering); and yes, it IS copyright; I think it is a headshot or a publicity pic for a local reading. That's the one on the darkish background. I only haven't contacted Wikimedia before because I am so damn busy. The other image is NOT me or my mother, but a complete stranger. At a guess, her forename is Rosamund.
I'd like to know what bits of bio I added you are planning to remove. Seems a shame if you lose hard information. She was at Central in 1952/3 along with Judi Dench; they both did the teachers' course. Vanessa Redgrave was a contemporary too. She never went back into acting; sadly I think as she would have got more joy from it than she did from her marriage. I do not suggest that as an inclusion. As a professional editor myself, chiefly of academic texts, I appreciate the need for care. Please, though, bear in mind my remarks above. As my mother told me just about everything (not always ideal); I do know more about her life than anyone alive now, and nothing is written that has not come from me. If you wish, knock out the point about the three full-time pursuits she had that made it not so easy to write a lot; I can see that as slightly biased, if true and pertinently still characteristic of married female writers. Incidentally, I have just been contacted by an American house wanting to publish a Selected Poems, so she may enjoy a resurgence. Oueeza ( talk) 19:24, 25 August 2018 (UTC)
{{
Request edit}}
template. Even if what you state is not verifiable, if the inaccuracy is not sourced in the article, then it can simply be removed.With that said, please only respond (or even read this!) when it's a good time for you, even if that's in a few days or a week or so. You can also
email me if you prefer that or if it's something you'd rather not post publicly here for all to see. I don't intend to be going anywhere anytime soon, and I intend to help improve your mother's article well into the near-future, so I'll probably be available to assist you with these matters from here on out, so long as you're interested in my long-winded assistance. Now, onto the rest of your message...Part of why I play a bit coy with your identity is because
Wikipedia's policy on harassment includes an "
outing" section that I am very careful to respect. In engaging in that way, I am technically providing a shred of
plausible deniability to protect your privacy and, on the chance that someone is impersonating you, to avoid contributing to that impersonation through validation. I did indeed do some basic research, though.Where a random editor like me would look to find information about a subject's life is usually in
reliable sources that can be
cited to
verify the information. For example, like I said on your talk page in reply to
Graeme Bartlett, I am currently gathering sources to undergo a significant rewrite and expansion of your mother's article. I am doing this with information I found in a variety of sources, mainly obituaries that provide in-depth coverage about her life. I have only done some basic research, so what I have found may just be the tip of it, but thus far I have found some excellent information in a
2005 obituary in
The Independent, another
2006 obituary by
Alan Brownjohn in
The Guardian, yet another
2006 obituary in
The Times, a
1992 review of Stanhope's Lapidary in
Critical Survey (via
JSTOR), and a
1984 mention of Stanhope in Serials Review. That alone is more than sufficient sourcing to confirm Stanhope's
Wikipedia-defined notability, provide significant details about her life and legacy, and even provide some information about her poetry in particular. As more sources are found, the article can continue to be expanded to include them.This is how articles on Wikipedia are created, expanded, and improved, including biographies of people who are no longer living or lived so long ago that anyone who directly knew them is long dead. For example, consider the following
Featured articles on poets:{{
Copyvio}}
(a speedy deletion for copyright violation) on both the
first and
second images after finding the original sources for both. I also noted on both that they are incorrectly named, so they should be deleted soon enough. In the very unlikely chance that they aren't, they will probably at least be renamed, though I'm very confident they'll be deleted as copyright violations. So, on the matter of the images, that should be considered effectively resolved. Regardless of what occurs, I'll ping you with an update on the results.On an unrelated note, I noticed that there is a similarly named account,
Oueezer (
talk ·
contribs), whose only edits are at the
Rosamund Stanhope article, as well. Is this one of your accounts? If so, then it's best if you declare that whenever you reply (again, no rush!). Please keep in mind that
alternative accounts are allowed, but under certain restrictions, and generally having multiple active accounts is discouraged. I have my guesses for why the account exists if it is indeed yours, all innocuous, but I might as well ask anyway. Again, have a great day / night and please take your time to respond. Your professional life comes first; I don't mind waiting. Anyway like I said, I'm busy, too! —
Nøkkenbuer (
talk •
contribs)
00:21, 26 August 2018 (UTC)
[4] (sorry you were dragged into this). Kudpung กุดผึ้ง ( talk) 08:39, 30 August 2018 (UTC)
In the original NASA caption for File:Cosmic ‘Winter’ Wonderland.jpg, they say "optical data from the SuperCosmos Sky Survey (blue) made by the United Kingdom Infrared Telescope". But UKIRT doesn't appear to have an optical sensor. I think that SuperCosmos Sky Survey's optical data was from scanning plates of other telescopes' surveys. It's described in further detail here. This is probably too detailed to adjust The Signpost's Featured content again, but it bugs me. ☆ Bri ( talk) 17:55, 30 August 2018 (UTC)
created by NASA Chandra X-ray Observatory and Spitzer Space Telescope, NASA-German Aerospace Center ROSAT telescope, and United Kingdom Infrared Telescope; and nominated by The NMI User", which seems to be the case even if the optical data do not derive from UKIRT; and the alt text states that the image is a "
[p]hotograph of nebula NGC 6357 false-colored based on X-ray, infrared, and optical data", which is correct regardless of the optical data source.Whatever error might exist regarding the source of the optical data, that is a problem for the description page at Commons—and the NASA page from which we got the description (where it explicitly that states the optical data are from UKIRT). It should of course be corrected if indeed erroneous, but it's beyond the scope of The Signpost and we are not republishing anything incorrect here. — Nøkkenbuer ( talk • contribs) 14:55, 31 August 2018 (UTC); edited at 15:03, 31 August 2018 (UTC)
[a]lthough seeing in the infrared, the UKIRT was large for an optical telescope and signaled a coming focus on this part of the spectrum that only grew in the coming decades." Similarly, this 1995 abstract briefly mentions UKIRT being fitted with an experimental adaptive optics system developed by the University of Hawaii in January 1994.After some consideration, however, perhaps we're just presuming too much of what "optical" means in this context? Optics include infrared wavelengths in its definition, at least according to our article, so "optical" may not necessarily mean the visible spectrum here. Although the wording at the description page and NASA article are ambiguous and unclear, they might mean that the image was produced by UKIRT using the optical data from all sources? I'm not very familiar with these matters, so maybe there are some technical definitions for these terms that I do not know. I also don't have much confidence in this interpretation, but I'm trying to be generous here.In any case, this is now bugging me, too, Bri. It does not help that my web search results are such that it's almost as if this is a fact that is just too obvious (or minor) to report, so others only make statements that imply or suggest it without explicating UKIRT's relationship to optical observations. — Nøkkenbuer ( talk • contribs) 15:42, 31 August 2018 (UTC); last edited at 15:51, 31 August 2018 (UTC)
I don't know what this may indicate or clarify in this situation, but it seems sufficiently similar to this that I might as well mention it. — Nøkkenbuer ( talk • contribs) 15:59, 31 August 2018 (UTC); edited at 16:03, 31 August 2018 (UTC)Infrared photometry and spectroscopy from the United Kingdom Infrared Telescope (UKIRT), and optical data from various facilities are combined with archival data to understand the nature of these candidates. High signal-to-noise near-IR spectra obtained from UKIRT have enabled us to study the optical depth effects in the hydrogen emission lines of these stars.
Thanks for your cleanup on
Incel! I've been a Wikipedian for a while but only learned of {{'"}}
because of your edits—thanks!
GorillaWarfare
(talk)
07:35, 9 September 2018 (UTC)
Hey!
I just read Cam. Opt. alleged "last response" and, in all honesty, I am quite surprised by that nasty transphobia, but apart from that it just seems bitter. I'd be willing to apologize for any kind of rudeness, starting with me, and hoping they would as well. Though, my points and criticisms still stand, of course. What are your thoughts on the matter? JulkaK ( talk) 18:26, 9 September 2018 (UTC) (last edit because the paragraph didn't work 18:27)
Your edits to whatever I come up with for the Signpost have always been an improvement. I need to learn more about formatting from your examples. Please feel free to edit anything that I write. Best Regards, Barbara ✐ ✉ 23:26, 28 September 2018 (UTC)
Hi, I saw you brought over the COI notice from The Optical Society talk page. I just wanted to let you know that User:Jmiller1455 no longer works for The Optical Society. Not sure its necessary to include that account. - Tinynull ( talk) 06:36, 11 October 2018 (UTC)
{{
help me}}
at the top of the section and someone should eventually come along to assist you. Again, thanks for your contributions! —
Nøkkenbuer (
talk •
contribs)
18:41, 12 October 2018 (UTC)profusely apologize for the delay but happily, my piece is nearing completion.There's lot more than that meets to the eye and will be jotted in the yet-to-be-written-conclusion.Post that, there will be extensive copyediting and formatting stuff:-) You are invited to chime in. ∯WBG converse 16:54, 25 October 2018 (UTC)
Regarding [[User talk:SMcCandlish#Categorization consensus|this, I would say that now that we have hidden categories, any category of that sort no longer needs to be relegated to the talk page. Pushing it to talk was what we did before we could hide categories from readers (other than those who create an account and change their prefs to opt-in to seeing these maintenance categories). I would keep the talk page placement for cases of reader-unhelpful maint. categories that have yet to be converted to hidden, though the better solution would be to make them hidden. 2601:643:8300:C96D:CD15:305A:C81B:4798 ( talk) 02:43, 27 October 2018 (UTC)
72 hours was right before I created the English Wikiquote. So it seemed a bit like putting my thumb on the scale. GMG talk 13:35, 27 October 2018 (UTC)
Just so you don't waste time on something that's done automatically: I'm not positive but I think this is unnecessary -- this is copied by the publishing scripts. ☆ Bri ( talk) 15:44, 27 October 2018 (UTC)
I have changed the appearance of my signature. Barbara ✐ ✉ 10:52, 31 October 2018 (UTC)
Bonjour If you want to complete Grunya Sukhareva biography: Other ref: How history forgot the woman who defined autism. https://www.spectrumnews.org/features/deep-dive/history-forgot-woman-defined-autism/
and Sukhareva—Prior to Asperger and Kanner https://www.researchgate.net/publication/274317752_Sukhareva-Prior_to_Asperger_and_Kanner
I don't master the subject to do it myself.
Regards, LaMèreVeille ( talk) 18:20, 18 November 2018 (UTC)
Hello, Nøkkenbuer. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.
If you wish to participate in the 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery ( talk) 18:42, 19 November 2018 (UTC)
Hi, just checking in to see if you are around and willing to help with The Signpost this issue. We have about a week to wrap up prior to the 2 December publication deadline. Thanks! ☆ Bri ( talk) 00:24, 24 November 2018 (UTC)
Hello Nøkkenbuer - After removing the entry for Steven S. Rosenfeld from List of scientific misconduct incidents because it had no sources, I noted on the revision history for Steven S. Rosenfeld the summary statement that you "might return some day to do some cleanup." I have yet to find any RS on the alleged scientific misconduct, so if that "cleanup" involves AfD, I would be supportive. Although this isn't close to a priority for me (or you either I gather), I thought I'd leave you this note because I certainly do not mean to step on your toes by removing the list entry. JoJo Anthrax ( talk) 17:25, 21 December 2018 (UTC)
![]() |
The 2018 Cure Award |
In 2018 you were one of the top ~250 medical editors across any language of Wikipedia. Thank you from Wiki Project Med Foundation for helping bring free, complete, accurate, up-to-date health information to the public. We really appreciate you and the vital work you do! Wiki Project Med Foundation is a user group whose mission is to improve our health content. Consider joining here, there are no associated costs. |
Thanks again :-) -- Doc James along with the rest of the team at Wiki Project Med Foundation 17:41, 28 January 2019 (UTC)
You are invited to join the discussion at
Wikipedia:Templates for discussion/Log/2020 September 15 § Template:Use shortened footnotes.
Peaceray (
talk)
05:21, 15 September 2020 (UTC)
A discussion is taking place to address the redirect
Degeneration. The discussion will occur at
Wikipedia:Redirects for discussion/Log/2021 October 8#Degeneration until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion.
Sangdeboeuf (
talk)
20:09, 8 October 2021 (UTC)