Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
A blank line is being erroneously added or removed
Is there a bug that causes a stray blank line to be added between the last paragraph of the lead and the first subheader of any page? In this edit and this edit, I did not place my cursor on that part of the edit window, but someone else edited other parts of the top section of those articles a few hours before I did. LSGH (talk) (contributions) 15:07, 12 December 2020 (UTC)[reply]
Did you make a section edit of the lead section with a tool saying §ion=0? I think a section edit will automatically end the section with one blank line as the only blankspace, while a full page edit normally leaves whatever the editor did. Your first diff did not add a newline but remove a space. The second diff added a newline. PrimeHunter (talk) 15:28, 12 December 2020 (UTC)[reply]
@LSGH: When you click the link to edit a whole page at once, the edit box is filled with the wikitext of the page, then all whitespace (spaces, newlines, tabs and one or two other characters) is stripped from the bottom, and one newline is added; finally you are given control of the editing form. When you click Publish changes, the contents of the edit box are sent back, all whitespace is stripped from the bottom of the text, one newline is appended and it is saved. Any extra whitespace within the page is preserved as it stands. The effect of this is that no matter what you attempt to add to the bottom of a page in the way of whitespace, the bottom of the page ends "cleanly", but the gaps above section headings might be over-large if there were many blank lines in the source.
When you click the link to edit a single section (or one section including all descendant subsections), the edit box is filled with the wikitext of the section, then all whitespace is stripped from the bottom, and one newline is added; finally you are given control of the editing form. When you click Publish changes, the contents of the edit box are sent back, all whitespace is stripped from the bottom of the text, and it is inserted into the page with two newlines appended. The effect of this is that no matter what you attempt to add to the bottom of a section in the way of whitespace, the section as saved will have one blank line between the end of the text and the next heading or subheading.
@Redrose64: Does that leave editors no way to know how many bytes are being added or removed from the page before publishing the edit? When I do those kinds of edits, I would not leave any change in the number of bytes most of the time. However, those newlines appear to happen at random when another editor makes changes to the lead section before I do. If the newlines separate different sections by default, then where are those extra newlines coming from? LSGH (talk) (contributions) 03:30, 13 December 2020 (UTC)[reply]
Somebody removed a newline before the first section heading in [1], presumably in a full page edit which can only make automatic whitespace changes at the page end. You were the next to make a section edit of the lead section so MediaWiki restored the newline in your edit. PrimeHunter (talk) 17:44, 14 December 2020 (UTC)[reply]
@PrimeHunter: Thanks! I probably need to be more careful next time because I do not always look at the edit history before doing edits like those. It is possible that someone else edits the lead (such as this) but does not remove a newline at the end of that section. LSGH (talk) (contributions) 10:59, 19 December 2020 (UTC)[reply]
For the past few days, I no longer see the external link symbol (the little blue box with the arrow pointed N.E.) at the end of an EL. I see it if I log out. But when logged-in, it's missing. This is consistent on two different browsers. I don't recall changing any preferences recently. I am using Monobook. MB01:03, 13 December 2020 (UTC)[reply]
I would love to put my developer experience to use and contribute Wikipedia both in the form of user-scripts/gadgets and MediaWiki source code. The primary hindrance in doing so is how the JavaScript/ECMAscript standard of Wikimedia has not advanced since 2009, making it virtually impossible for anyone used the modern form and practices of the language to contribute.
I have to assume i'm not the only one who was stopped by this, and with the massive number of competent JS/ES devs who learned the language only in the past few years regularly working on open source software, there should be plenty that would happily contribute their time to Wikimedia and co. if it was more accessible to them.
Wikipedia:WikiProject JavaScript is suffering from a large lack of willing contributors, and there is obviously something wrong with that, seeing how JavaScript + TypeScript make up close to 30% of GitHubs projects (being ranked 1st and 5th respectively)[1]. SkSlick (talk) 19:31, 13 December 2020 (UTC)[reply]
It's not just about the support of the modern syntax. It's about the lack of all the modern creature-comforts JS/ES devs have become accustomed to; hard to navigate documentation, recommendation ancient practices, the use of obsolete frameworks like JQuery being used as the norm, antiquated tools that have been unmaintained for ages are recommended all over the place, a complete lack of code-maintenance and style guides, making any code incredibly hard to debug or maintain. Additionally the editor is severely lacking in features and there are zero ways to integrate with the tools that have become the status-quo because of their reliability and ease of use, topped off by a large non-modern API without type-definitions.
The tools you mention are a perfect example of this problem (NOTE: they ARE decently coded and follow general best-practices).
They aren't discoverable.
They are barely documented.
They pre-require good knowledge of the environment
They are relatively weakly maintained
They are one-man-operations someone created for themselves, and simply lack the drive and man-power to be the proper tools for the average developer. Transpilation and Bundling isn't the issue, pretty much every JS-dev is familiar enough with those, yet both tools require you to use their method, making them incompatible with other tools very fast (eg. they can't be used together if i'm interpreting it correctly). And a lot of JS/ES devs do have a prefered way of doing this step that might be completely antagonal to those methods. Pointing to these tools is nice and does help people, but it won't solve the underlying issues. These won't go away without major and coordinated effort.SkSlick (talk) 17:59, 14 December 2020 (UTC)[reply]
It would be helpful if you cite examples of what you're looking for. Documentation for the MediaWiki's JS interface is available at https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw (these docs are generated from JSDuck which is unmaintained, but come on it does the job pretty fine from a user point of view). antiquated tools that have been unmaintained for ages are recommended all over the place I don't think this is the case, where did you come across this? the use of obsolete frameworks like JQuery being used as the norm I think OOUI is currently used as the "norm". But Wikimedia is now working on adapting Vue.js as a frontend framework. Check out the recent WVUI project – it doesn't use any antiquated tools as far as I can see. a complete lack of code-maintenance and style guides Wikimedia does have a style guide, and there's eslint-config-wikimedia that can enforce them. But the style guide is used only for MediaWiki core and extensions. Userscripts/gadgets need not follow them (I personally don't because IMO the spaces in parens requirement is crazy). the editor is severely lacking in features and there are zero ways to integrate with the tools ... All serious dev work takes place in a local IDE, so I don't see the quality of the online editor of relevance. It's a lot better than the online editor on GitHub; in any case. topped off by a large non-modern API without type-definitions Non-modern, yes, but it's one of the most welcoming and resilient APIs you'll find on the internet! I have some generated type definitions for the API here. You can use Special:ApiSandbox for learning about API usage, though on this part, I have to agree it's quite non-intuitive and hard. I also have written some type definitions for mediawiki js interface if you're interested, though it's incomplete. – SD0001 (talk) 06:26, 15 December 2020 (UTC)[reply]
SD0001, I appreciate the extensive response. I'm don't just want to complain about it, I'm looking for concrete ways how things could be improved. And all this information helps getting the full picture.
But Wikimedia is now working on adapting Vue.js as a frontend framework. I read about it and I'm very happy about it. I checked it out now and I am absolutely delighted to say the least. Modern code with modern practices. I'm very much looking forward to the result.
Wikimedia does have a style guide, and there's eslint-config-wikimedia That's cool. There should be one for user scripts as well. I'm not very fond of eslint-config-wikimedia either. I can't stand tab-indenting by the life of me and I think unnecessary semicolons are an absolute eyesore (not looking forward to that discussion for a userscript style guide, lol). Personally I use standard/standard with various additions for TypeScript.
It's a lot better than the online editor on GitHub; in any case. You are right, I projected my frustration on the editor. It does its job well enough.
but it's one of the most welcoming and resilient APIs I can agree with that, but it would be great if there was a proper and well maintained typedef that includes doccomments etc.. These are a great start, tho.
You can use Special:ApiSandbox ... it's quite non-intuitive and hard. I came across it before, but I had no idea how to use it, so I have to agree with that. It would be cool to remedy these issues, but I don't know how much work that would be as I couldn't find the source repo. But this made me think of a point for improvement: It's quite hard to find the source for many wiki-related tools directly from Wikipedia. Maybe there should be a standard way of linking to it.
Many of these things aren't so bad on MediaWiki, but it can be rather hard to get there from Wikipedia if you're not familiar with it and the local pages are easier to find. There needs to be some discussion and planning on how to smartly remove all that dust. This problem is too large for someone to tackle on their own and if this doesn't happen, it will only get worse the longer it goes on.
I have previously generated some statistics that show when an individual editor tends to be active on Wikipedia (i.e. the time of day). I now cannot find how I did this. Does anyone know what I was looking at and tell me how to produce such a report again? ThanksThoughtIdRetired (talk) 07:36, 14 December 2020 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
There is a Wikipedia app for KaiOS phones. It was released in India in September. It can now be downloaded in other countries too. [2]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 December. It will be on non-Wikipedia wikis and some Wikipedias from 16 December. It will be on all wikis from 17 December (calendar).
Suppressing title attribute in final HTML of rendered wikilinks
Is there any way (in a template) to suppress or change the value of the title="Wikipedia:COI" in the <a href="/wiki/Wikipedia:COI" class="mw-redirect" title="Wikipedia:COI"> in the rendered output of [[Wikipedia:COI]]? Not something one would want to normally do, but the use-case here would be for when the link is inside a span, abbr, or other element that is trying to supply a more specific title= value. The browser always knows what link it's actually pointing at (and will report this if you have that feature turned on; most visual browsers do this in a footer at the bottom of the browser window). So, having it stuff this value into the <a ... title=...> attribute is not actually useful (or not always useful, anyway). — SMcCandlish☏¢ 😼 04:39, 15 December 2020 (UTC)[reply]
@SMcCandlish: seems like this is an ancient debate around here (see phab:T2542 from 2004 and other phab searches), AFAIK there is no way to change this from the wikitext and the general idea is that this attribute could possibly be helpful and is never harmful. Pointing out why it could be bad would likely have more weight in making a global change if you have good reasons? — xaosfluxTalk19:38, 15 December 2020 (UTC)[reply]
"Why this would be bad" is already implicit in what I said above: if you use a link inside something applying an explicit title to a span (or whatever) then the link's auto-generated and usually harmless but not actually very useful title clobbers that of the span (at least while one is hovering over the link, which in many cases may be the entire contents of the span). — SMcCandlish☏¢ 😼 00:11, 16 December 2020 (UTC)[reply]
@Xaosflux: Wasn't sure what you meant at first, but I redid the example, and found it working: Wikipedia:COI (in Chrome on Windows). I'm not sure I would describe this as a title collision; rather, it's normal cascade precedence at work: a later element or CSS instructions overriding what an earlier one did "wins". Are there known problems with this? I'm aware that just because it is spec-permissible and should work fine doesn't mean that it does work properly in all major browsers. Some of them have bugs galore. — SMcCandlish☏¢ 😼 00:20, 16 December 2020 (UTC)[reply]
@SMcCandlish: this may break common on-wiki things like the various popup previews, also in my initial tests it wasn't consistent for logged in / logged out users (but that may be some gadget or other script at play), also it seems some of our javascript may be entangled here, so results when js doesn't run also may vary. What does this mean: well you can screw around with it for fun, but I wouldn't go putting something built on that in to articles. — xaosfluxTalk01:06, 16 December 2020 (UTC)[reply]
I think it's gadgets or other script at play, since I also have different results, and use lots of that stuff. My testing so far with popup previews and the like is that "Enable page previews (quick previews of a topic while reading a page)" (under Preferences > Appearance > Reading preferences) is that the page preview overrides the tooltips, which is both expected (since it's injecting stuff with JS) and desirable (since it adds more functionality than a tooltip). Will still need to see what it does with other things like "Navigation popups" (under Preferences > Gadgets). I don't think this "hack" will be of any use for the template I'm working on now, but it might be of some use in templates (like some inline cleanup/dispute templates) that do more "fixed content" kind of things are are not dealing with user-supplied links. — SMcCandlish☏¢ 😼 01:26, 16 December 2020 (UTC)[reply]
Regardless, thanks for the notes. I'd more or less expected that this wasn't fixable at all, so the fact that there's at least some kind of a workaround is worth looking into, if for no other reason than to understand what it's doing and what issues can arise. E.g., we may have finally fixed the accessibility problem with tooltips generally, after several years of various, intermittent tweaking approaches; see Template:Tooltip/testcases. Wouldn't've been possible without multiple approaches to working around the problem, and lots of testing, and simply time. Actually, that test page is why I'm here asking about the above: One of the test cases (of using a link inside the template) actually produces the unusual result of better output for screen-reader users than for everyone else, because the accessibility bypass for the title content isn't subject to the link's auto-title overriding span's context-specific title. Heh. — SMcCandlish☏¢ 😼 00:11, 16 December 2020 (UTC)[reply]
@SMcCandlish:Wikipedia:COI (don't do this, but yes, create a template with <span class="plainlinks" title="{{{2|title}}}">[{{SERVER}}/wiki/{{urlencode:{{{1|url}}}|WIKI}} {{{1|}}}]</span> and that would work..) — Alexis Jazz (talk or ping me) 00:39, 16 December 2020 (UTC)[reply]
I'll have a look at that, too. In the interim, I have another issue or two to fix with Template:Tooltip/sandbox (handling three-param input properly), and then tracking down some behavior weirdness in different test-case scenarios. As I said above to Xaosflux, its probable that this link title workaround stuff won't even be of any use for the template in question, but only ones that supply pre-determined content, so "bigger" testing with various gadgets and such will require a different scenario (a template that provides a predetermined link and puts a predetermined tooltip on it). — SMcCandlish☏¢ 😼 01:31, 16 December 2020 (UTC)[reply]
Hiding content from extended-confirmed users
I just added a box at WP:Autoconfirmed that shows whether or not your current account is autoconfirmed. I'd like to do the same for extended-confirmed, the other group users may be wondering whether or not they're a part of. However, MediaWiki:Group-extendedconfirmed.css doesn't seem to have any class for non-ec users the same way there's unconfirmed-show at MediaWiki:Group-autoconfirmed.css, which I needed to make {{If autoconfirmed}}. Is there any way to get around this? I'm thinking I could try wrapping {{void}} in extendedconfirmed-show to negate it, but I'm not sure it'd work and it feels quite hacky. {{u|Sdkb}}talk18:58, 15 December 2020 (UTC)[reply]
That being said, autoconfirmed XOR extendedconfirmed is generally not true, it is possible to OR or AND these groups - you could just show multiple lines- something like "You are X, Y" and only include each of them based on if you are in the group (i.e. don't worry about "hiding" the you are autoconfirmed part when showing you are exc). — xaosfluxTalk19:15, 15 December 2020 (UTC)[reply]
Xaosflux, we point a lot of beginners to the access level page whenever we mention an access level, and "do I have X level of access?" is a question I suspect a large portion of visitors to the page have, so it would seem user-unfriendly not to give it to them there. Yeah, Special:Preferences does have it, too, but it only shows what you do have rather than what you don't, so there's a possibility someone not EC who goes there might get confused or at least have to work a bit to figure it out.
What I'd like is just a way to display "You are not extended confirmed" to non EC users. It sounds like I may need to make an interface request to do that? {{u|Sdkb}}talk19:33, 15 December 2020 (UTC)[reply]
@Sdkb: if you want a nifty box, you could include a few groups, and have a checkbox appear if you are in the group maybe (You are: Autoconfirmed; Extended Confirmed, Template Editor, Administrator.... (most common ones about what can you edit)). It's a different direction but possibly easier to implement. — xaosfluxTalk19:40, 15 December 2020 (UTC)[reply]
Hmm, that seems possible, but it'd require it to be together in a clump rather than sectioned. I think I'll go ahead and make the edit request (hopefully it doesn't distract from the other open interface-protected request, which is much more urgent). That box might be useful in some other circumstances, though, so if anyone wants to create it I'm sure we could find places to put it. Thanks for the help! {{u|Sdkb}}talk19:50, 15 December 2020 (UTC)[reply]
@ToBeFree: That's what it's supposed to look like? And if you log out or switch to an account that isn't extended confirmed, it should say "Not extended confirmed." Was it different in the quote box? (I noticed an issue with the height of the quote box if one of the texts doesn't fit on a single line, maybe you got that?) — Alexis Jazz (talk or ping me) 23:15, 15 December 2020 (UTC)[reply]
The sandbox works fine logged-out and logged-in. Can this be a line length thing? The "Not extended confirmed" text has to be longer than the "Extended confirmed" one? ~ ToBeFree (talk) 23:42, 15 December 2020 (UTC)[reply]
@ToBeFree: The other way around: the "You are extended confirmed" text must be longer. It simply always displays the text "Not extended confirmed" and if you are extended confirmed, the text "✓ Extended confirmed." covers that up. If the underlying text (Not extended confirmed) is longer, you get what you see in the screenshot. If the underlying text takes up two lines, you'd see the second line. If the covering message (✓ Extended confirmed.) has no background color, you get
garbage like this
trash like this
Here you see both texts in the same place because there is no background color to cover up the underlying text. — Alexis Jazz (talk or ping me) 00:18, 16 December 2020 (UTC)[reply]
I want to add a time-stamp to a subst thingy I made a while ago but
Here's the page: User:Shearonink/Holiday. I created this "Card" 3 years ago but was looking at it today prior to starting to send it out and I realized - eek! - that there is no time-stamp. I am somewhat tech-averse, so I do not understand how to add a time-stamp (heh, or even if it is possible). If some of you tech experts could take a look at the code and tell me how to fix it I'd appreciate that. PLEASE do not go ahead and just fix it yourself. I know that is probably easier but if I don't do it myself in the future I won't understand how to fix similar situations. Thanks & Cheers! Shearonink (talk) 19:11, 15 December 2020 (UTC)[reply]
@Shearonink: I'm assuming you are going to subst: this places, if so you can add a line that is something like this: ~~<noinclude></noinclude>~~<noinclude></noinclude>~. There are other ways too, but that should be easy to understand (test it in your sandbox). — xaosfluxTalk19:19, 15 December 2020 (UTC)[reply]
Five tildes (~~<noinclude></noinclude>~~<noinclude></noinclude>~) give you a timestamp without signature (as Xaosflux showed):
00:04, 16 December 2020 (UTC)
The noinclude code prevents the tildes from being parsed unless the page is substituted. There's also interesting stuff on mw:Help:Magic words but you probably won't need it for now:
{{<includeonly>subst:</includeonly>CURRENTMONTHNAME}} is here and {{<includeonly>subst:</includeonly>CURRENTYEAR}} was very.. special? Greetings from {{<includeonly>subst:</includeonly>REVISIONUSER}}.
December is here and 2020 was very.. special? Greetings from Alexis Jazz.
But maybe if you want to customize stuff. Here the "includeonly" will result in the magic words being substituted when you substitute the page, but not when saving the page. (because the substitution happens only when the page is included on another page) — Alexis Jazz (talk or ping me) 00:04, 16 December 2020 (UTC)[reply]
@Shearonink: Instead of "the New Year 2021 will be an improvement upon the old of 2020" you could say "the New Year '''{{<includeonly>subst:</includeonly>#expr: {{CURRENTYEAR}} + 1 }}''' will be an improvement upon the old of {{<includeonly>subst:</includeonly>CURRENTYEAR}}" as 1 + 1 is 2. Or with an exception for January (for slightly late wishes for a good new year), it could be written as "the New Year '''{{<includeonly>subst:</includeonly>#ifeq:{{<includeonly>subst:</includeonly>CURRENTMONTH}}|01|{{<includeonly>subst:</includeonly>CURRENTYEAR}}|{{<includeonly>subst:</includeonly>#expr: {{<includeonly>subst:</includeonly>CURRENTYEAR}} + 1 }}}}''' will be an improvement upon the old of {{<includeonly>subst:</includeonly>#ifeq:{{<includeonly>subst:</includeonly>CURRENTMONTH}}|01|{{<includeonly>subst:</includeonly>#expr: {{<includeonly>subst:</includeonly>CURRENTYEAR}} - 1 }}|{{<includeonly>subst:</includeonly>CURRENTYEAR}}}}". Sure it's easier to just update it manually every year, but your card could live on forever! — Alexis Jazz (talk or ping me) 14:10, 16 December 2020 (UTC)[reply]
My pet peeve: collapsing citations
The thing that irritates me the most, as a WP editor, is how nice, legible citations, such as (within braces that I'm omitting)
cite book
|editor-link=Robert W. Watson
|editor-first=Robert W.
|editor-last=Watson
|title=White House Studies Compendium
|volume=2
|first=Harold
|last=Holzer
|authorlink=Harold Holzer
|isbn=9781600215339
|chapter=New Glory for Old Glory: A Lincoln-Era Tradition Reborn
|url=https://books.google.com/books?id=mFDl3fo9iEQC&pg=PA316
|year=2007
|publisher=Nova Publishers
|pages=315–318, at p. 316
are collapsed into illegible goo, as in
cite book|editor-link=Robert W. Watson|editor-first=Robert W.|editor-last=Watson|title=White House Studies Compendium|volume=2|first=Harold|last=Holzer|authorlink=Harold Holzer|isbn=9781600215339|chapter=New Glory for Old Glory: A Lincoln-Era Tradition Reborn|url=https://books.google.com/books?id=mFDl3fo9iEQC&pg=PA316%7Cyear=2007%7Cpublisher=Nova Publishers|pages=315–318, at p. 316
I haven't searched for it, but I think there is a bot or some automated process that does this routinely.
There is NO reason to do this, that I can see. If you can see anything significant accomplished by it I'd appreciate being informed. It reduces the file size by only a miniscule, trivial amount.
The problem with doing this is that it makes my work in editing articles—other people's citations, and sometimes my own—harder and more prone to error. In this case I had to add a lot of information missing from the citation as I found it (https://en.wikipedia.org/w/index.php?title=Robert_Anderson_(Civil_War)&diff=994573267&oldid=991008436), and it's much easier to see what is there and what isn't if it isn't scrunched up.
Few people use ye olde vertical citations these days; they make the edit view of many articles incredibly difficult to read, with the odd word of text lost in an endless stream of citation lines. So I'm not sure how much sympathy I have. But reverting, quoting WP:CITEVAR can work, if you catch them before other changes are made. I'm not sure there is any bot, but there are certainly plenty of cite-bandits using automated editing tools. Johnbod (talk) 12:49, 16 December 2020 (UTC)[reply]
I am confused by your statement "they make the edit view of many articles incredibly difficult to read". With what intention or under what circumstances would you be reading the edit view? I thought one looked at edit view only when editing, not reading. For me it makes the edit view much easier, not to read, but to edit. deisenbe (talk) 13:04, 16 December 2020 (UTC)[reply]
That makes no sense. If you aren't wanting to edit the citation, spreading it out vertically should make it easier to find the actual prose text. That's in addition to making the citations themselves easier to edit. — Preceding unsigned comment added by Khajidha (talk • contribs) 20:12, 16 December 2020 (UTC)[reply]
I guess most users rarely edit existing references. They take up a lot more of the edit area in vertical format than horizontal so you can see less surrounding wikitext at a time and you need more scrolling to get past them. The first syntax highlighter at WP:HILITE writes parameter names in bold. PrimeHunter (talk) 12:59, 16 December 2020 (UTC)[reply]
That's certainly true for "most users". Unfortunately there is a small but prolific minority of drive-by cite-bandits who specialize in this, so one does see a lot of it. Johnbod (talk) 13:07, 16 December 2020 (UTC)[reply]
A citation collapsed in the above manner is more readable if there are spaces before pipes, like:
cite book |editor-link=Robert W. Watson |editor-first=Robert W. |editor-last=Watson |title=White House Studies Compendium |volume=2 |first=Harold |last=Holzer |authorlink=Harold Holzer |isbn=9781600215339 |chapter=New Glory for Old Glory: A Lincoln-Era Tradition Reborn |url=https://books.google.com/books?id=mFDl3fo9iEQC&pg=PA316 |year=2007 |publisher=Nova Publishers |pages=315–318, at p. 316
+1 for the spaces between fields. But also consider the syntax highlighter gadget to make text more visually distinguishable from templates. Regarding bots that change things, each a template can assert a preferred format that VisualEditor and possibly some other tools will respect. I can't find the formal doc on it, but search for "format" on Wikipedia:TemplateData/Tutorial for some examples. DMacks (talk) 14:26, 16 December 2020 (UTC)[reply]
That notation is especially annoying when it's a reference inside of a table or infobox. The table and citation parameters become practically indistinguishable. kennethaw88 • talk20:57, 16 December 2020 (UTC)[reply]
This has gotten way off my original topic: maintaining citation editability. Maybe if they were easier to edit more people would help maintain and correct them. All these exotic tools don't help me, or I don't see how they would. I want something simple: stop collapsing citations. deisenbe (talk) 21:42, 16 December 2020 (UTC)[reply]
Can you please take this to a forum other than VPT? This is not a technical issue. WP:CITEVAR exists for a reason, and this is not the place to argue the merits of one citation formatting style over another, whether that is the rendered style or the style of the code. – Jonesey95 (talk) 22:02, 16 December 2020 (UTC)[reply]
deisenbe, I am sorry for the difficulties you are having, but as a new editor in 2016, I learned my WikiGnome trade, by repairing and resolving reference problems on horizontal references. Because these were the only refs I had ever seen, I didn't find it difficult to learn to work on them, and "help maintain and correct them". We still need to use pipes and equal signs, so I don't think the vertical format is any easier than the horizontal format. It wouldn't have discouraged me, either way. I don't use any exotic tools, I just type the information. Yes, perhaps I need to explore some other tools....but I have been successful with the bare minimum. Tribe of TigerLet's Purrfect!04:22, 17 December 2020 (UTC)[reply]
The technical part of what I am asking: how do these citations get automatically changed, or semi-automatically, from the style I like and use to the collapsed style I find much more difficult. How does this happen? What bot(s), or whatever, do this? Something undoes my work and I don't know where to bring it up because I don't understand what is happening. My question is not why is it happening, my question is how does it happen. deisenbe (talk) 10:22, 17 December 2020 (UTC)[reply]
I'm not aware of a bot that goes around changing things from the style you like. I doubt one exists because there is no community consensus on this either way. But the changes could be facilitated using AWB (I guess, knowing little about AWB) or a script, making them much easier and faster to perform, and that usage wouldn't require community consensus. For what it's worth, my preference is unstacked ("collapsed") parameters, and I suspect you're about as likely to be persuaded by me as I am by you. Different minds, backgrounds, and skill sets produce different preferences, meaning that there is often no single best way. ―Mandruss☎11:12, 17 December 2020 (UTC)[reply]
There is no solid policy about the format of a large template - for example infoboxes tend to be spread out with one parameter per line and references tend to be compressed into the goo you speak of. The editors that are humans tend to be human and so disagree about most things – some editors will open up the goo to multi-line references and some will compress multi-line references down to goo. A lot of the time this is mildly annoying but not a major problem because references tend to be left as they were. As far as I know, the editors that are not human tend to leave reference templates mostly unmolested, but there are definitely gadgets that also disagree about some things. The gooification that you speak of is probably just caused by another human with a differing preference. However, if you can provide links to specific gadgets that are edit-squabbling then that is something that we really should address. — GhostInTheMachinetalk to me16:02, 17 December 2020 (UTC)[reply]
The preference for vertical citation templates is not one protected by CITEVAR per an RFC that is now some 2-3 years old. Your request that people stop is accordingly not one shared by the community on the topic. --Izno (talk) 16:39, 17 December 2020 (UTC)[reply]
Archiving references
My understanding is that if we run the "fix dead link" tool, and choose "Add archives to all non-dead references (Optional)", then the archives will be stored "offsite" (example: web.archive.org) in addition to being added to the article.
At some point, I think I learned that sponsoring the archived links on WP, increases both the article size and download time. So, depending on the number of citations, I have "Add[ed]archives to all non-dead references". Once complete, I have undone/reverted my edit. Reasoning: The references were now stored offsite, and would be available in future, if a link went dead. But the WP article wouldn't be increased in size (and download time for readers, etc.).
That process is basically pointless because since 2012/2015 (depending on when one counts) all links added to the main namespace in the English Wikipedia have been automatically archived (see Wikipedia:Link rot#Automatic archiving). I don't think it's at all worth the overhead. Graham8707:22, 17 December 2020 (UTC)[reply]
Graham87, Ah, this is helpful. I suspect that some of info I was reading in early 2016 may have been a bit outdated. I need to think this through a bit. It seems, per this page, that I should never encounter a dead link, and this has not been my experience. (At least in 2016, I recall encountering numerous 404 pages.) But, I sincerely thank you for the reply. Tribe of TigerLet's Purrfect!08:16, 19 December 2020 (UTC)[reply]
Since Firefox updated to v83 (now 84) the reason for closure box in the top right of the screen has lost some of it's styling/formatting. The screenshot is of an example in Firefox (top) compared with Chrome (botton). I'm using Modern skin on Windows 10, in any other browser the formatting is correct, it's just Firefox that has lost it. Swapping skin to Vector and clearing my common.css doesn't change things. Presumably it's something to do with the Firefox css but does anyone know what? Nthep (talk) 13:24, 17 December 2020 (UTC)[reply]
Get wiktext of a section in a past revision of an article?
Hi. If I have a really huge article and am looking at an old revision, it's kind of annoying how there's no edit link by sections so if I want to get the source of just one section I have to search through the whole page's editor. Is there a way to view just one section of an old revision of an article as wikitext, maybe some setting that adds in the edit buttons by headers? DemonDays64 (talk) 20:27, 18 December 2020 (UTC) (please ping on reply)[reply]
Follow up: Latex equations and text not showing up
I posted this message a few days ago and haven't received any response, so I'm going to bump it again.
I noticed since around yesterday that whenever I'd be on a mathematical or scientific article, the latex text straight up disappears. I have provided an example screenshot on the article Breadth-first search. I have isolated this problem solely to my Wikipedia account because the latex works fine when I view the page logged out, and the pages work on my phone too. I am not sure why this is happening because I have not installed any mods or plugins or gadgets lately to influence this behavior. Any idea why this is happening or what I can do? Thanks! Hummerrocket(talk)02:40, 19 December 2020 (UTC)[reply]
Need help with archiving at the page Wikipedia:Article Rescue Squadron – Rescue list. There are currently two archive boxes using different systems. The old system (User:lowercase sigmabot III the replacement for User:MiszaBot) had completely stopped working for unknown reason. I commented it out, and installed Cluebot III according to instructions and while it is now successfully saving archiving to page 23, the page name is "/Archives/_23" and not the configured "/Archive_23" .. so it doesn't show up in the standard archive index box. Thus I had to add a second box just for Cluebot III. Any ideas how to untangle this? -- GreenC03:32, 19 December 2020 (UTC)[reply]
As for ClueBot III, it wasn't archiving properly because it needed the page name written with a – HTML entity (see Wikipedia:Village pump (technical)/Archive 186#Archive confusion). As for Lowercase sigmabot III, it wasn't working because nobody had updated the page name in its archive parameter when the page was moved from a title with a hyphen to one with an en dash. I've moved the page back to using Lowercase sigmabot III and moved archive 23 to the right place. Graham8706:34, 19 December 2020 (UTC)[reply]
We have a little problem at Wikipedia:Administrators'_noticeboard/Incidents#Wilkja19_marking_all_edits_as_minor where an editor cannot seem to see any of our messages. I got the iOS app and did a small test, it looks like talk page messages do not trigger any alert in the iOS app (unlike on the desktop version, or even on mobile web), so the user does not even know we're trying to get in touch with them. If I remember correctly, there's some issue with block messages not getting through either. Anyone any ideas on how we can get the attention of this user and send them a message? Or is it simply not possible? It seems like the app is designed for readers, not editors, and I'm out of ideas here. ProcrastinatingReader (talk) 13:58, 19 December 2020 (UTC)[reply]
Template:MLBBioRet produces faulty punctuation when one attempts to add a citation. Is someone able to alter the punctuation on the template so that the citation follows the period? Or perhaps add a parameter to the template for a reference, that properly formats? Thanks in advance, SandyGeorgia (Talk) 14:07, 19 December 2020 (UTC)[reply]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 December. It will be on non-Wikipedia wikis and some Wikipedias from 16 December. It will be on all wikis from 17 December (calendar).
@ToBeFree: What does Not extended confirmed.look like to you? (it's probably just me screwing up CSS) — Alexis Jazz (talk or ping me) 22:55, 15 December 2020 (UTC)✓ Extended confirmed.
Here the "includeonly" will result in the magic words being substituted when you substitute the page, but not when saving the page. (because the substitution happens only when the page is included on another page) — Alexis Jazz (talk or ping me) 00:04, 16 December 2020 (UTC)
