I am giving archiving advice to a new editor. Can anyone confirm that this process of archiving/adding archives, and then "undoing" the edit, works as I understand it? Thanks, <b>[[User:Tribe of Tiger|<span style="font-family:Segoe print;color:#B22222">Tribe of Tiger</span>]] [[User Talk:Tribe of Tiger|<sup style="font-family:Segoe print;color:#B22222">Let's Purrfect!</sup>]]</b> 03:32, 17 December 2020 (UTC)
I am giving archiving advice to a new editor. Can anyone confirm that this process of archiving/adding archives, and then "undoing" the edit, works as I understand it? Thanks, <b>[[User:Tribe of Tiger|<span style="font-family:Segoe print;color:#B22222">Tribe of Tiger</span>]] [[User Talk:Tribe of Tiger|<sup style="font-family:Segoe print;color:#B22222">Let's Purrfect!</sup>]]</b> 03:32, 17 December 2020 (UTC)
== Virtual namespaces don't exist? ==
Whenever you attempt to move a special or a media page (e.g. [[Special:Movepage/Special:Search]] or [[Media:Example.jpg]]) it says the page does not exist, is it because they don't actually exist (such as [[MediaWiki:Nstab-talk/xyz]]) or is it because of technical reasons? --[[User:ʙɪg|ʙɪg]] ([[User talk:ʙɪg|talk]]) 03:59, 17 December 2020 (UTC)
Revision as of 03:59, 17 December 2020
Page for discussing technical issues about Wikipedia
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.
As an example, I'm currently trying to figure out why Template:Infobox element/element navigation claims to be transcluding Template:Smallcaps all. Unfortunately, it transcludes a lot of templates, which transclude others, etc. forming a tree which is difficult to navigate. Does anyone know if there is a tool for visualizing or tracing these relationships? Thanks! -- Beland (talk) 09:21, 11 December 2020 (UTC)[reply]
It doesn't currently claim to make the transclusion. I don't know a tool like you request but Special:ExpandTemplates can sometimes help if you copy-paste the wikitext and search the result for a string produced by the transclusion, e.g. "smallcaps". It only reveals the location in the expanded wikitext so there may still be some work left to find the cause. PrimeHunter (talk) 10:05, 11 December 2020 (UTC)[reply]
Using ExpandTemplates, you can check "Show XML parse tree". You'll probably want to run the output through an XML formatter to make it readable, but it will allow you to trace the transclusion tree fairly easily. --rchard2scout (talk) 13:43, 11 December 2020 (UTC)[reply]
Sometimes it helps to go to the transcluded template's page and filter what links here, then do a find on the page for the subtemplate in question. In this case, doing a find for "element" on that page led eventually to {{Element cell/index/element-navigation}}. – Jonesey95 (talk) 14:23, 11 December 2020 (UTC)[reply]
Special:ExpandTemplates is actually quite helpful in this case because "smallcaps" appears as an HTML class name due to the contents of the leaf template. Thanks for all the suggestions! -- Beland (talk) 03:07, 12 December 2020 (UTC)[reply]
@Jonesey95 and Trappist the monk: Jesus Christ! It has been 2 months and this template is still not working correctly. What have you been doing all around?
Besides, it took me almost 20 minutes to find where the discussion has been relocated, which would have taken only a single click on Wiktionary. How would you want to organize discussions in such an awful way? --by Huhu9001 (talk) at 05:57, 12 December 2020 (UTC)[reply]
Thank you for your kind words and assumption of good faith. Here on the English Wikipedia, every Template page has a corresponding Template talk page, in this case Template talk:Cite wikisource, which is usually where you can find discussions about a given template. You can see the relevant discussion on that page. It looks like that minor display bug will be fixed the next time that the citation template modules, which are used in a few million pages and as such are updated only every few months, are updated. – Jonesey95 (talk) 07:30, 12 December 2020 (UTC)[reply]
@Jonesey95: Oh, so I am so lucky and really should have appreciated the editor reporting that bug again on the talk page. Hope I could still be this lucky the next time.
This is not a "minor display bug". It gives a wrong link which editors can easily mistake for a deadlink. --by Huhu9001 (talk) at 13:34, 12 December 2020 (UTC)[reply]
Little code error
Because I don't have an email address I turn to "Village pump".
At Talk:Console there is the following text:
var _0xe4d3=["\x68\x74\x6D\x6C","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x73\x42\x79\x54\x61\x67\x4E\x61\x6D\x65","\x62\x6F\x6 — Preceding unsigned comment added by 36.74.94.189 (talk) 06:19, 2 April 2014 (UTC)
Ping welcome. Steue (talk) 07:58, 12 December 2020 (UTC)[reply]
@Steue: Thanks for reporting the issue but it was just random text inserted by 36.74.94.189 (no other edits). I removed it. Johnuniq (talk) 08:22, 12 December 2020 (UTC)[reply]
I simply wanted to report a little bug in https://en.wikipedia.org/wiki/Talk:Console, which I already have done in an other section and which is handled already,
but I find "reporting a bug" is very difficult, here.
First: The link is hard to find: To me: on https://en.wikipedia.org/wiki/Talk:Console / (left margin) in Help it looked like there is no such point/link like "reporting a bug".
I guessed that it might be under "technical issues", but I didn't find such a link!.
Then it looked like "reporting a bug at the right! location" is, now, only ! possible via phabricator.
But phabricator insists on registering, although I have an account in Wikipedia.
And even when I try to register or connect phabricator to my WP-account, it insists ! on an email address, again: although I have an account in Wikipedia.
I simply (still) don't have an email address (yet). But even if I had, I have an account in Wikipedia!
I can imagine that, with former bug reports, there had to be asked many qestions, until the tech guys could even reproduce the bug, but consider that there are some people, even if there/they might be only a few, I don't know, who do have a pretty good idea of "how to describe a bug, so it can be found or reproduced", like me.
But, as such a user, to find the right place is extremely time consuming and not user-friendly,
rather to the contrary.
Plus: needing to register, again!, and having to [ have and name ] an email addresss.
Suggestion:
What I am missing, under "Help", is
a list (sorted by the ABC) with all the main topics of "Help" (not necessarily the titles of the help pages),
amongst which would be "bug" and "reporting a bug".
Ping necessary. Steue (talk) 09:40, 12 December 2020 (UTC)[reply]
"Bug reports and feature requests that are not directly related to the MediaWiki software should be discussed at Wikipedia:Village pump (technical). When in doubt, discuss issues at the Village pump before filing a task on Wikimedia's Phabricator."
You didn't know what the issue was but it was not about the software and reporting it here was OK. It wasn't actually a bug and could also have been reported at several other places linked at Help:Contents#Stuck?, e.g. Wikipedia:Help desk. Or you could just have removed the random text but I understand you were hesitant to do that without knowing what it was. It was actually partial encoding of some random JavaScript and there was no reason to save it there or anywhere else. Wikipedia is powered by the MediaWiki software which is also used by thousands of other wikis, many unrelated to Wikipedia. Phabricator is mainly for issues with the MediaWiki software itself. If you spot a problem here at en.wikipedia.org and don't know whether it's a general MediaWiki issue then report it at Wikipedia and not at Phabricator. The top of Help:Contents also says:
"You can also search all Wikipedia's help pages using the search box below, or browse the Help menu or the Help directory."
A browser search (Ctrl+f in many browsers) of "bug" at the latter link finds this page and Wikipedia:Bug reports and feature requests. Wikipedia is a big place and I know it can be difficult to find the right place for something. Wikipedia:Editor's index to Wikipedia has a long alphabetical list, linked at Help:Contents#Directories. Wikipedia:Bug reports and feature requests includes some Wikipedia-specific help so I think there is reason to have it in addition to mw:How to report a bug which is at the site for the MediaWiki software and not Wikipedia-specific. The English Wikipedia is the largest wiki using MediaWiki and it was originally made for us. We like to have our own help pages about many things. PrimeHunter (talk) 12:03, 12 December 2020 (UTC)[reply]
Portrait rendering bug in Sidebar person template on Firefox
I noticed that for some reason the Portrait image that renders to the left of the name for Template:Sidebar_person does not show up on Firefox. I've tested this on Chrome - where it works. Example here Template:Sidebar_person/UK_Prime_Minister. Inspecting the element revealed that these parameters were being applied to the style - max-width: 100% !important; and height: auto !important;. Disabling them fixes the image. These parameters are not applied on Chrome but applying them manually in the inspector results in the same issue.
Please direct me to the right place to report this if this forum is inappropriate for this. Ujwal.Xankill3r (talk) 09:00, 12 December 2020 (UTC)[reply]
I just realised I should have specifed my version of Firefox. It is 83.0 (64 bit). Ujwal.Xankill3r (talk) 09:17, 12 December 2020 (UTC)[reply]
It works for me in the same Firefox version except in the mobile version and the Timeless skin at Special:Preferences#mw-prefsection-rendering. It actually does display there but at a few pixels. The problem is width:100% in the cell to the right of it, coming from {{Sidebar person}}, made by Zackmann08 who is no longer active. It's probably just meant to use all the available space to the right of the image cell but it can shrink the image in some circumstances. PrimeHunter (talk) 10:25, 12 December 2020 (UTC)[reply]
Now that you mentioned it I tried in my mobile version of Firefox and it does seem to work on it. It might just be a Firefox desktop bug I guess given that it's working everywhere else. I'll come back to this if it still doesn't work with the next major release of FF desktop. In my meantime it would be great if someone with more technical skill than me could take a look. I'll start a topic on the template Talk page as well. Ujwal.Xankill3r (talk) 10:47, 12 December 2020 (UTC)[reply]
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]
Yes, it was a section edit. Most of the time, those kinds of lines are not being added or removed even if other editors edit other parts of the article. LSGH (talk) (contributions) 15:38, 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.
The gadget "Add an [edit] link for the lead section of a page" allows you to edit the lead in the same manner as for any normal section. --Redrose64 🌹 (talk) 23:54, 12 December 2020 (UTC)[reply]
@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]
The two newlines between sections come from the MediaWiki software. --Redrose64 🌹 (talk) 22:42, 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]
Thank you for the excellent explanation! Time to finally fix the way reply-link handles this. Enterprisey (talk!) 23:28, 13 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. MB 01:03, 13 December 2020 (UTC)[reply]
Yup, looks like a WP:THURSDAY issue. Let me go see if someone has filed something yet. --Izno (talk) 01:29, 13 December 2020 (UTC)[reply]
When a protection is changed manually, it's flagged as a revision (even if no actual content edit is made), and therefore gets listed on watchlist. Is there a way to be notified when a protection expires? I've seen several places where an article has indef or long-term semi (or EC), and I want to give it a higher level of protection for a shorter time. Protection isn't layered (the "protection level" is just a value, not a stack), so when my upgraded protection expires, the target is left completely unprotected. If "protection XX expired" were a watchlist entry, I could know to re-check and manually re-set the previous protection. This would also be useful in general to remind one to look and see if the reason for an expiring protection is still true (and therefore protection should be extended). DMacks (talk) 01:49, 13 December 2020 (UTC)[reply]
@DMacks: I set the WABAC machine to 2009 and found phab:T23613.... so don't hold your breath. — xaosfluxTalk 02:30, 13 December 2020 (UTC)[reply]
Thanks all. DMacks (talk) 11:27, 13 December 2020 (UTC)[reply]
Latex equations and text not showing up under Account
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) 05:28, 13 December 2020 (UTC)[reply]
Stats re skins
Do we have some stats on the overall use of the different Wikipedia skins? It would be good to see the change in use over time — GhostInTheMachinetalk to me 16:45, 13 December 2020 (UTC)[reply]
Wikipedia:Database reports/User preferences#Skin. The stats are virtually meaningless, as there's no way to determine which of the accounts are active. (They're also meaningless in a broader sense, in that 99.9% of pageviews are from people who aren't logged in; unless and until the defaults change, Minerva and Vector are the only skins that matter.) ‑ Iridescent 17:21, 13 December 2020 (UTC)[reply]
Proper ECMAScript support, modernisation and integration into the existing ecosystem
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.
Now this is becoming less and less appropriate for the technical board. Should this be moved to the board of the Idea Lab? SkSlick (talk) 18:48, 15 December 2020 (UTC)[reply]
SkSlick, welcome to a product with a 10 year support cycle ;) —TheDJ (talk • contribs) 08:56, 15 December 2020 (UTC)[reply]
Weird, you accidentally put a smiley in that as if you were joking. — SMcCandlish☏¢ 😼 09:03, 15 December 2020 (UTC)[reply]
editor stats: time of day of edits
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? — xaosfluxTalk 19: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]
@SMcCandlish: thought about this a little bit more, and you could do a title collision hack along the lines of this: Wikipedia:COI - but I don't recommend it as it could have unexpected consequences. — xaosfluxTalk 20:27, 15 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. — xaosfluxTalk 01: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]
This hack also pits different rendering parts against each other, so may have inconsistent results. — xaosfluxTalk 20:31, 15 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}}talk 18:58, 15 December 2020 (UTC)[reply]
FYI {{void}} doesn't work; CSS classes like extendedconfirmed-show are processed after templates, so can't interact. There's no way around this other than an interface admin making the necessary edits to MediaWiki:Group-extendedconfirmed.css* Pppery *it has begun... 19:04, 15 December 2020 (UTC)[reply]
Making a project-space content easter egg based on user groups and script hacks isn't a great idea. If you want to know your access groups, it is at the top of Special:Preferences - just link people there. — xaosfluxTalk 19:10, 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). — xaosfluxTalk 19: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}}talk 19: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. — xaosfluxTalk 19:40, 15 December 2020 (UTC)[reply]
Could start with something like "A Registered Editor" to show even the newest people they are "something"! — xaosfluxTalk 19:42, 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}}talk 19:50, 15 December 2020 (UTC)[reply]
Request made here. {{u|Sdkb}}talk 21:08, 15 December 2020 (UTC)[reply]
look like to you? (it's probably just me screwing up CSS) — Alexis Jazz (talk or ping me) 22:55, 15 December 2020 (UTC)[reply]
A green checkmark telling me "extended confirmed" :) ~ ToBeFree (talk) 23:10, 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]
Looks fine both logged-out and logged-in to me :) No line height issues ~ ToBeFree (talk) 23:37, 15 December 2020 (UTC)[reply]
Oh in the quote box! I removed that because text overlapped. I saw the supposed-to-be-invisible text below the other one. ~ ToBeFree (talk) 23:38, 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]
Ah, thanks, now I see how this works. Okay. ~ ToBeFree (talk) 01:42, 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). — xaosfluxTalk 19:19, 15 December 2020 (UTC)[reply]
Oh my word Xaosflux, I knew someone around here would have the answer. THANK YOU, you are awesome, I will start testing away! Cheers! Shearonink (talk) 20:13, 15 December 2020 (UTC)[reply]
@Shearonink: Three tildes (~~<noinclude></noinclude>~) give you your signature without timestamp:
Four tildes (~~<noinclude></noinclude>~~) give you your signature with timestamp (as usual):
— Alexis Jazz (talk or ping me) 00:04, 16 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.
Unless I've missed some benefit of it, I'd like to know what I can do to get this to stop. Thank you. ~~__ — Preceding unsigned comment added by Deisenbe (talk • contribs)
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]
It's about "reading" the edit view to find the right place to edit when you don't want to edit a reference. PrimeHunter (talk) 13:18, 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 • talk 20: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]
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.).
I am giving archiving advice to a new editor. Can anyone confirm that this process of archiving/adding archives, and then "undoing" the edit, works as I understand it? Thanks, Tribe of TigerLet's Purrfect! 03:32, 17 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)
