Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Redrose64 (talk | contribs) at 20:11, 28 September 2020 (→‎Templates not rendering in ITN archives: yes). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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.


Toolbox
GA toolbox
Reviewing

Hi all, the two templates {{Peer review tools}} and {{Good article tools}} used in WP:GA and WP:PR seem to contain dead links. It seems like this is due to a problem on toolserver, maybe because the tools have moved URL? I was hoping a technical boffin around here who is in-the-know may be able to help out by correcting the links. Many thanks! --Tom (LT) (talk) 11:29, 17 September 2020 (UTC)[reply]

Which links in particular? (To wit, I've tried to remove the ones I know of that have caused issues previously.) --Izno (talk) 16:36, 17 September 2020 (UTC)[reply]
@Izno All of them. To me at least, they all redirect to 404 pages. --Tom (LT) (talk) 23:20, 18 September 2020 (UTC)[reply]
Ping. Still a problem that seems to be apparent for all peer reviews and good reviews. --Tom (LT) (talk) 04:07, 23 September 2020 (UTC)[reply]
You will need (apparently) to achieve consensus to remove the links or get in contact with the Toolserver project owner. --Izno (talk) 17:27, 23 September 2020 (UTC)[reply]
Toolserver has been down, permanently, since mid 2014. There's plenty on that matter in the archives of this page. I'm surprised it's taken six years for these links to be noticed as being dead. FWIW the "Toolserver project owner" was Wikimedia Deutschland. --Redrose64 🌹 (talk) 22:21, 23 September 2020 (UTC)[reply]
... I should have said Toolforge, the links to which do function in normal cases. --Izno (talk) 23:19, 23 September 2020 (UTC)[reply]
Great. I don't see the use in revitalising these links if noone has actually even tried to use them in the last 5 years - they clearly aren't seen as useful. I've commented out the links in both templates and, as I'm active at peer review, have also boldly added a link to Earwig's. --Tom (LT) (talk) 04:10, 24 September 2020 (UTC)[reply]
@Tom (LT): I'm a little confused, as I have used the links you commented out several times and they always worked for me. I'm pretty sure they have been used plenty of times. I'm guessing the Toolforge server was just down? Ovinus (talk) 17:51, 27 September 2020 (UTC)[reply]
Oh dear! I have tried the links on multiple articles over one to two weeks using multiple IP addresses, so that's really weird to hear. Can I confirm you have used these links in the last week or so? Perhaps a third editor can also try and see if those links are working. If they are, I am left feeling very confused.--Tom (LT) (talk) 06:09, 28 September 2020 (UTC)[reply]

Page views by Georgraphy

Hello all:

I was hoping to do an analysis, and was looking for geographical page view data -- is there some place where I can get it?

E.g. This link [1] or this one [2] has the page view data for an article / page. Is there some place where I can get the next level breakdown by geography as well?

Thanks, Ktin (talk) 00:13, 20 September 2020 (UTC)[reply]

@Ktin: No, this information is not publicly available for privacy reasons. Sorry. — MusikAnimal talk 20:59, 24 September 2020 (UTC)[reply]
MusikAnimal, makes sense. Thanks. Would this be available for pages like the main_page? Ktin (talk) 21:16, 24 September 2020 (UTC)[reply]
@Ktin: Country data is available for projects as a whole, see https://stats.wikimedia.org/#/en.wikipedia.org/reading/page-views-by-country/normal%7Cmap%7Clast-month%7C~total%7Cmonthly. I think offering country-level data for any given page is unlikely to happen. However, there is talk of creating a list of the most popular pages per country (phab:T207171), and those lists would certainly include the Main Page. I imagine the end result would be something like toolforge:topviews but with a way to filter by one or more countries. — MusikAnimal talk 22:05, 24 September 2020 (UTC)[reply]

Using GitLab for code review

As was recently mentioned in Tech News, the foundation is currently holding a consultation about moving development from Gerrit, the current code and patch review system, to GitLab (for reasons, other systems are not being considered). I'm in the working group steering this consultation and we are also very interested in the opinions of those outside the core development team. Bot writers, gadget developers etc. Do you have concerns or enthusiasm about gitlab ? Do you think you might contribute more or less or even if it might be easier for you to be informed with Gitlab instead of gerrit ? What do you think about the gerrit patch review system vs the gitlab pull request system ? Please take a minute to think about it and maybe leave some comments at mediawiki.org or if you really prefer to do so, leave them here and I will later summarise them there. —TheDJ (talk • contribs) 07:44, 21 September 2020 (UTC)[reply]

GitLab is a million times better than Gerrit. ProcrastinatingReader (talk) 13:20, 21 September 2020 (UTC)[reply]

Speaking of which, is it just me who find Phabricator a pain in the butt?

  • You have to learn a markup language that's neither MediaWiki's nor Markdown and seemingly has no application outside it;
  • the way to mark a task as a bug report is somehow not through adding a tag and hidden in the task creation form itself, not in the dropdown menu at the top (which I just learned can be configured), and it can't be done or undone retroactively (or can it be? if so, that proves my point);
  • the list of your subscriptions is not accessible from the profile page or menu but only from "Tasks & Bugs", and you have to make new queries if you ever want to change the grouping or sorting;
  • (un)subscription is public and gratuitously floods tasks' timelines;
  • mentioning someone adds them as a subscriber, so if they're not interested they have to unsubscribe, which again gratuitously populates timelines and could potentially discourage users from pinging others, not a good design for something whose whole purpose is collaboration;
  • no one knows what the "tokens" are for.

It looks like it has a rich set of features, which is probably why it was chosen in the first place, but the UI is so impenetrable it repels you. The consultation page says GitLab's issue tracker wouldn't be used, but then Phabricator could also use some improvement if we want to lower the bar to contribution IMHO. Nardog (talk) 19:06, 26 September 2020 (UTC)[reply]

All of those critiques of Phab seem like paper cuts. You should use Phab to report them... of course ;). --Izno (talk) 19:34, 26 September 2020 (UTC)[reply]
Not just you, phab also sucks. Trust enterprise to choose obscure, bad solutions to things. ProcrastinatingReader (talk) 20:03, 26 September 2020 (UTC)[reply]

Birthday boy

In the infobox for Joe Wicks (coach) there is a line of coding which reads

{{Birth date and age|1985|09|21|df=y}}

This generates his age as "34" but I would have thought it should be "35". After playing round with the coding I managed to get it to generate "35" but it's gone back to "34". If I enter his birthday as 20 September it gives age 35, so why does it fail to recognise his 35th birthday? The current age can also be generated using

{{birth date and age|1985|09|21}}

This generates age 35 in preview. According to [3] Joe was born in 1986 so the article age is correct, and the dab page also says "1986". In 2016 the article had 1985 in the lead and 1986 in the body. In 2018 the lead still said 1985 and this was the only reference. On 22 August 2019 someone changed "Category:1986 births" to "Category:1985 births". On 11 March 2020 the birth year was corrected to 1986. This year was shown when the infobox was added. On 23 June someone changed the birth year to 1985 in both places. I haven't edited the errors out because the issue of how an infobox can give an age of 34 when "21 September 1985" is coded remains unresolved. 92.19.171.232 (talk) 11:59, 21 September 2020 (UTC)[reply]

The Companies House data gives 1985 so I would be inclined to leave things as they are (provided we can get the article to show his age as 35 rather than 34). 92.19.171.232 (talk) 12:08, 21 September 2020 (UTC)[reply]

I just purged the page and now it says 35. Nardog (talk) 12:14, 21 September 2020 (UTC)[reply]
Thanks. 92.19.171.232 (talk) 12:19, 21 September 2020 (UTC)[reply]
Anne Robinson and Serena Williams could also do with being purged. Is this a widespread phenomenon? 79.73.15.145 (talk) 15:56, 26 September 2020 (UTC)[reply]
Anne's age is now correct. 79.73.15.145 (talk) 15:57, 26 September 2020 (UTC)[reply]

Escaping a pipe character in system messages

Please can anyone advise on this issue. User:Awesome Aasim has requested that some system messages using {{fmbox}} are hardcoded as tables (like this) to avoid it breaking when a pipe character occurs. Hopefully he/she will be along to explain this better than I can. Is there any way that fmbox can be used successfully in these cases? — Martin (MSGJ · talk) 08:04, 22 September 2020 (UTC)[reply]

First, where is that breakage occurring, and how is it manifested? Second, this is sematically an improper use of a table element. --Redrose64 🌹 (talk) 08:32, 22 September 2020 (UTC)[reply]
The main issue is with the parameter $1 in system messages for the title blacklist. This is the parameter that is responsible for providing the regex that was tripped in the local or global blacklist. Because it can be frustrating for good-faith editors to know which filter tripped when they were creating a filter, this is more of a diagnostic that I suggested only be visible to extended-confirmed users. Unfortunately, because the regex sometimes includes a pipe character | it breaks many templates. I do not know if there is a way where this character can be accommodated without breaking any additional templates. If anyone more technical than me in MediaWiki knows, feel free to reply to this message.
(On a side note, this issue can easily be fixed if MediaWiki sent {{!}} instead to the parameter $1. This could maybe fixed in a bug request on Phabricator.) Aasim (talk) 08:39, 22 September 2020 (UTC)[reply]
$1 is not a regular template parameter, like {{{1}}}. Can this be solved by wrapping it in <nowiki>...</nowiki>? —⁠andrybak (talk) 10:11, 22 September 2020 (UTC)[reply]
@Awesome Aasim:, what do you think? — Martin (MSGJ · talk) 13:29, 25 September 2020 (UTC)[reply]
Can someone test the changes on test wiki first? If they work, then we can implement the nowiki change. Aasim (talk) 15:05, 25 September 2020 (UTC)[reply]

Self edit conflict

I'm having frequent edit conflicts with myself. This has plagued me previously and then mysteriously resolved itself. It is back. I asked for help previously and found that I'm not the only one with this issue and on one has a cure or workaround. My only recourse is to resolve the edit conflict by copying and pasting the entire article text. One previous suggestion was to reset my account preferences to defaults. I've done this and the problem persists. ~Kvng (talk) 14:39, 22 September 2020 (UTC)[reply]

Please check what happens by using the following procedure to publish/save edits after previewing them: in the edit summary box, write a message then press Enter. That will save the edit (assuming you haven't done anything to disable the default behavior). The aim is to determine whether that gives a different result from using a mouse to click Publish changes. Johnuniq (talk) 23:35, 22 September 2020 (UTC)[reply]
@Kvng: (1) Are you using WP:wikEd (would be enabled under Special:Preferences#mw-prefsection-gadgets)? (2) If not, are you double-clicking the "publish" button? (3) If not, do you perhaps have an failing pointing device that's sending spurious double clicks? Suffusion of Yellow (talk) 23:40, 22 September 2020 (UTC)[reply]
I have wikEd enabled in preferences but I leave it disabled except temporarily when I need one of its features. I have definitely gotten these edit conflicts with wikEd disabled. I am definitely not double-clicking the "publish" button and if I had a pointing device issue I'm sure I would have noticed it on other applications. To publish edits I use Enter in the summary box or the Shift-Alt-S shortcut. I may occasionally use the mouse. I will see if I can make any connections between save method and edit conflicts. ~Kvng (talk) 16:00, 23 September 2020 (UTC)[reply]
I did not get any self edit conflicts yesterday or this morning. This is the same pattern as previously. The problem just mysteriously goes away at some point. ~Kvng (talk) 16:37, 25 September 2020 (UTC)[reply]
Now two full days and 50 edits with no issues. This has been fixed through no action on my part. I sure would like to know what it is because, based on past experience, I'm confident it will be back. The only theory I have is that it is associated with datacenter failovers. I beleive these edit conflicts happen after Wikipedia has been put into read-only mode for this sort of maintenance and testing. ~Kvng (talk) 19:04, 27 September 2020 (UTC)[reply]
@Kvng: I suspect some of the conflicts were caused by wikEd. WikEd, for me, really does try to submit every edit twice, but usually (not always) the browser blocks one of the submits. See Wikipedia:Village_pump (technical)/Archive 183#Nonexistent edit conflicts. I have no idea about the others; perhaps another script is double-submitting? I also don't know why the problem comes and goes; it could just be the clustering illusion, or it could have something to do with the type of edits you are making at the time. @Cacycle: Any possibility of looking at the patches in the archived thread? Suffusion of Yellow (talk) 21:55, 27 September 2020 (UTC)[reply]
Who knows, but intermittent issues are another sign of failing hardware. I was a skeptic on that point but became a believer when I gave that advice (try another mouse) to someone here many months ago. A week after that, I started getting self-conflicts with no other signs of mouse trouble. I have spares and changing the mouse eliminated the problem. Johnuniq (talk) 23:31, 27 September 2020 (UTC)[reply]
What I get from the archived discussion is
  1. I'm not crazy
  2. My mouse is probably fine
  3. Wiked is suspect
What I don't get is
  1. Do I need to disable Wiked in preferences or if just disabling it in the edit interface is sufficient? I suspect, based on my experience that the former is required. Sad.
  2. Why does this come and go? ~Kvng (talk) 01:28, 28 September 2020 (UTC)[reply]

Edit conflicts with yourself?

Do edit conflicts only get detected between different users? I've been trying to force edit conflicts (so I could test some aspects of how they behave) and was surprised to discover I couldn't generate one by editing User:RoySmith/sandbox logged in as myself in two different windows. If I opened an incognito window and logged in as RoySmith-testing, I could then easily generate conflicts. -- RoySmith (talk) 23:49, 22 September 2020 (UTC)[reply]

In theory, it should be impossible to conflict with yourself. The later edit will just save, with no attempt at a three-way merge. In practice, it can sometimes happen, as the above section shows. My guess is it only happens when the edits are submitted a fraction of second apart, but I don't really know. Suffusion of Yellow (talk) 23:51, 22 September 2020 (UTC)[reply]
On second thought, it looks like a self-conflict can happen during a section edit. From EditPage.php:
             // An edit conflict is detected if the current revision is different from the
             // revision that was current when editing was initiated on the client.
             // This is checked based on the timestamp and revision ID.
             // TODO: the timestamp based check can probably go away now.
             if ( ( $this->edittime !== null && $this->edittime != $timestamp )
                 || ( $this->editRevId !== null && $this->editRevId != $latest )
             ) {
                 $this->isConflict = true;
                 if ( $this->section == 'new' ) {
                     if ( $this->page->getUserText() == $user->getName() &&
                         $this->page->getComment() == $this->newSectionSummary()
                     ) {
                         // Probably a duplicate submission of a new comment.
                         // This can happen when CDN resends a request after
                         // a timeout but the first one actually went through.
                         wfDebug( __METHOD__
                             . ": duplicate new section submission; trigger edit conflict!" );
                     } else {
                         // New comment; suppress conflict.
                         $this->isConflict = false;
                         wfDebug( __METHOD__ . ": conflict suppressed; new section" );
                     }
                 } elseif ( $this->section == ''
                     && $this->edittime
                     && $this->revisionStore->userWasLastToEdit(
                         wfGetDB( DB_MASTER ),
                         $this->mTitle->getArticleID(),
                         $user->getId(),
                         $this->edittime
                     )
                 ) {
                     # Suppress edit conflict with self, except for section edits where merging is required.
                     wfDebug( __METHOD__ . ": Suppressing edit conflict, same user." );
                     $this->isConflict = false;
                 }
             }
Suffusion of Yellow (talk) 00:01, 23 September 2020 (UTC)[reply]
Suffusion of Yellow, Interesting, thanks. But, to take a step back, what I'm really trying to figure out is what happened with this edit. I edit-conflicted with Graywalls, thought I had properly resolved it using the Visual Editor's EC-resolution tool, but what ended up happening was deleting the white space between paragraphs, which ran them together. See this perma-linked version.
I've been trying to figure out what happened, but I've been unable to reproduce that behavior. I can now get edit conflicts (by using two accounts), but I still can't reproduce the whitespace removal. -- RoySmith (talk) 00:17, 23 September 2020 (UTC)[reply]
My situation (above) is very simple. I edit and I get an edit conflict. I see no other adjacent activity from anyone else in history. I will try to determine whether this only occurs on section edits. ~Kvng (talk) 15:08, 23 September 2020 (UTC)[reply]
I'm getting edit conflicts with self on non-section (whole article) edits. ~Kvng (talk) 16:02, 23 September 2020 (UTC)[reply]

Is there a script that highlights or corrects redirects?

Hi all, I've been editing navboxes recently and quite a few terms link to redirect pages. I was wondering if there is a script that could highlight these or fix them for me? This would be particularly useful because often due to moves and mergers terms used may be out of date, or worse there may be several terms linking to the same page, and I'd like an easy way to work out which ones I need to focus on. Does anyone know if there is such a script already? Cheers --Tom (LT) (talk) 04:21, 23 September 2020 (UTC)[reply]

For highlighting, see User:Anomie/linkclassifier. Headbomb {t · c · p · b} 04:43, 23 September 2020 (UTC)[reply]
Helpful! Thanks. --Tom (LT) (talk) 06:40, 23 September 2020 (UTC)[reply]
@Tom (LT): Something a little less heavy for highlighting/require less setup would be similar to what I have in User:Izno/common.css (.iznoredirects is for temporary addition to a long table or page that could use some redirect resolution, so you can ignore that line if you prefer). --Izno (talk) 17:23, 23 September 2020 (UTC)[reply]

How does notifications ignore work?

In the Notification section of my Preferences, I've added The Only Way Is Essex (series 26) to the "Muted pages for page link notifications" (I created it as a redirect, and now that it's an article, I was getting notifications about it). But I just received a notification that the page was tagged with link rot- this shouldn't have happened. Does the muted pages take some time to work? I only added this page to the muted pages about 4 hours beforehand. Or is it a bug? Joseph2302 (talk) 12:33, 23 September 2020 (UTC)[reply]

Get ready for horizontal scrollbars with Wikipedia's "New Look"

The Wikipedia "New Look" is coming: Wikimedia Blog: "New Look".

There are some nice features, like collapsible left sidebar. Then, there's the fixed-width content window, leading to horizontal scrollbars at browser widths less than the one they specify. "New Look" is currently active at French Wikipedia. Also at fr-wikt, eu-wiki, fa-wiki, he-wiki, pt-wiki. Mathglot (talk) 22:51, 23 September 2020 (UTC)[reply]

I hate to be grumpy and rude (no, really!), but it is clear to me that none of the people who worked on these "Desktop Improvements" has professional experience with UIs or usability. Looking at the Collapsible sidebar animation I see the sidebar disappearing and reappearing, with no reuse of the real estate it occupied. What good is that? According to that blog post, it's supposed to "improve usability and focus by allowing people to concentrate on the content itself"; I'd concentrate better without all that wasted space in my windows, which, in the collapsed case, is of absolutely no use to me at all.
The maximum line width "feature" appears to be similarly disrespectful of the user's needs, by forcing (what will probably appear to be arbitrary) wastages of space. I thought fixed-width design went out 10 years ago. Or was that only among clued professionals? Grumble, grumple, harrumpf, get off my lawn you consarned kids... — JohnFromPinckney (talk) 00:10, 24 September 2020 (UTC)[reply]
There's a professional UX designer and a UX engineer on the team working on this. I suspect they do, in fact, have professional experience with UIs/usability. Anyway, no projects except the volunteering early-adopter wikis are getting this before next year, per the FAQ. --Yair rand (talk) 00:57, 24 September 2020 (UTC)[reply]
Maximum line widths continue to be part of current web layout design (people still have trouble tracking text beyond a certain line length). Responsive web design will use techniques to rearrange page components appropriately as the screen size changes. (I haven't looked at the prototype changes, so have no comments on whether or not the design is responsive.) isaacl (talk) 02:27, 24 September 2020 (UTC)[reply]
Anyone with any experience trying to inspect now-you-see-me-comma-now-you-don't elements in a side-panel of their browser can attest that "responsive web design" is the antichrist. ―cobaltcigs 22:28, 27 September 2020 (UTC)[reply]
@JohnFromPinckney: I believe the justification for the fixed-width is that it's easier for people to continue reading from one line to the next when the text column isn't huge. This is why newspapers have all their text in columns since it would be difficult to go from one line to the next across a huge sheet of paper. The reason for the resurgence in fixed-width designs is due to the high resolution of monitors these days (creating the same problem as the newspapers' giant sheets of paper). I'm not a designer though, so please take all of my comments with a grain of salt. Kaldari (talk) 23:32, 27 September 2020 (UTC)[reply]
Apple's hi-res display on the iPhone also catalyzed responsive web design, as it was a very high resolution display but with a very small physical screen, breaking previous designer assumptions. As browsing increasing moved to phones, sidebars were replaced with bottom bars, and entries in menu bars became links to sections on one big scrolling page, as that design is readily adaptable to different screen sizes. isaacl (talk) 00:21, 28 September 2020 (UTC)[reply]
Newspapers have fixed-width columns because Linotype machines had a fixed slug width which could not be adjusted, although they were made in different widths so two different newspapers might have a different number of columns for the same paper size. The slugs were fairly narrow because the metal (lead) used to cast the slug would sag under its own weight if made too wide. --Redrose64 🌹 (talk) 12:08, 28 September 2020 (UTC)[reply]
Thanks, Kaldari. I have no doubt the reading of some material can be made easier with shorter lines of text. That's not my complaint (nor the complaint of the majority who've whined about it up at MediaWiki. Nevertheless, the standard response of the fine folks at MW seems to be, "but, no, the research shows..."). My complaint is, the implementation of fixed width prohibits me from using my computer the way I want to. If I want to widen my window (for example, to reduce the height of my window and see other info above/behind/below while still viewing the same content in WP), I should be able to productively do so. And if I want to more easily read some difficult text, I should be able to narrow my window, because I believe 100% that certain texts are more legible with shorter line-widths. The point is, I (and all other WP-users) should be able to use my/or devices as we see fit. We've got the power already, WM wants to take this flexibility away. — JohnFromPinckney (talk) 19:13, 28 September 2020 (UTC)[reply]
From what I understand, special pages, such as the watchlist and contribution pages do expand. That would certainly be useful for reading watchlists where someone has left a long edit summary. Dreamy Jazz talk to me | my contributions 19:28, 28 September 2020 (UTC)[reply]
I always put the web page inspector into its own window. isaacl (talk) 23:37, 27 September 2020 (UTC)[reply]
Kaldari, the change to a fixed width is great, in my view. It makes it much easier to place images and quote boxes. SarahSV (talk) 23:42, 27 September 2020 (UTC)[reply]
I'm not sure what the goal is here, but it seems like introducing a "known" screen width will encourage various "visual editor" fallacies. For example, it still would not be safe for editors to assume:
  • That sizing a floating image to exactly match the apparent "height" of the paragraph of text next to it (let's say 12 lines appears to be exactly 228px) makes it "safe" to float another image on the opposite side of the next paragraph (without having to worry about an ugly gap when the {{clear}} tag is used, or ugly "sandwiched" text when it isn't used),
  • That the 960px is the "correct" width for a panoramic photo of some city's skyline,
  • That a specific number of <gallery> images (perhaps six) will fit on one row (or worse, that knowing this magic number makes the relevance of each particular photo secondary to avoiding a remainder),
And we really don't want them to.
Consistent layout results would still be a lost cause in practice, because different clients will select different fonts to satisfy (vague) body { font-family: sans-serif; font-size: x-small; } CSS defaults, which may or may not be overridden on a per-user basis anyway. For consistent results, you'd have to hard-code it to an absolute font-size, provide the name of some font that everyone has, and probably a handful of other things like margins, padding, and line-height (someone please tell me what else I've forgotten) whose default values might differ from one client to the next. Obviously, the more specific you get, the more you alienate users who liked the way it looked before. Sure, you can always advise the hard of seeing to zoom in and out with ctrl+mouse-wheel in their browser, but that won't have consistent results either. Some programs will resize "everything" (and mess up gallery wrapping, plus attempts at full-width images) while others will resize "text only" (and mess up floating image layout). Others might do something in-between (test this, in fact).
I suppose the only foolproof solution would be to introduce a viewing mode which renders each article inside a scrolling PDF viewer box (similar to Google Books or Scribd, but with clickable links). This would introduce additional concerns about about vertical space and page-breaks, and generally suck for this type of content. But at least it would look the same for everyone. Achieving a deterministic "print-friendly" "perfect" "what-you-see-is-what-everybody-sees" layout may echo some aspirations of the "Book" namespace, for those interested in actually doing so (I'm not).
My strategy would be to avoid making any assumptions about the client side at all, except that every possible html output will absolutely look bad for somebody somewhere. This can be mitigated by using floating images more sparingly, and without trying to be so goddamn feng-shui clever about their arrangement. I figure if it matters that much, you probably have too many. ―cobaltcigs 07:22, 28 September 2020 (UTC)[reply]

This VPT section was intended more as just a notification of something going on at mediawiki. If you have comments that you would like people involved with the project to see or respond to, the project discussion page is here: mw:Talk:Reading/Web/Desktop Improvements. Mathglot (talk) 04:12, 24 September 2020 (UTC)[reply]

Thanks for sharing this, Mathglot. I did notice the team have said they plan to remove the minimum width soon, so the horizontal scrollbars on narrower windows should no longer be a problem. the wub "?!" 09:58, 25 September 2020 (UTC)[reply]
Browsing tests on the above-mentioned wikis suggest this only affects the vector skin (which, in my humble opinion, looks like donkey ass and was totally unusable even before this) and not monobook. So hopefully they'll leave it at that. ―cobaltcigs 22:28, 27 September 2020 (UTC)[reply]
From a technical perspective, we can add a gadget to remove what is the largest complaint (fixed width) - and if we really wanted to we could make it default... — xaosflux Talk 13:39, 28 September 2020 (UTC)[reply]
Some of it seems cooler than other stuff. The table of contents is quite interesting. Not sure the collapsible nav as implemented is an improvement, but as an idea it certainly is. Seems a bit weird that the width of the page does not resize as a result - leaves a bit of a void. Would make sense to have it collapsed by default though, probably. All of those links are useless to the average reader. ProcrastinatingReader (talk) 14:08, 28 September 2020 (UTC)[reply]

Randomising names in a list

G'day all, I have a situation where there is disagreement about what order some names should go in the infobox of an article about a war. Reliable sources are not very helpful in determining an order of importance and of course there are different factors to consider where one leader may be more important in one respect, and another leader more important in a different respect. My question is, is there a way of formatting a plain list within a field in an infobox that would present the names in a random order each time it was viewed? Thanks, Peacemaker67 (click to talk to me) 03:08, 24 September 2020 (UTC)[reply]

Sure can!
{{#invoke:random|bulleted_list|egg|sausage|spam}}
gives
  • spam
  • sausage
  • egg
See Module:Random for more tricks. Hawkeye7 (discuss) 03:31, 24 September 2020 (UTC)[reply]
Thanks Hawkeye, I shouldn't be surprised that you would know how to do it. Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)[reply]

Interesting idea, and it begs the question about unconscious ordering bias in lists. There probably is an attention bias towards the first and last entries in a list. It is a testable hypothesis. And feuds over pecking order show there is a supposed bias editors are trying to leverage. A is better than C better than F .. unless F is the anti-hero. And so on, it's ingrained in mental maps. Could see it being used for things like award shortlists. -- GreenC 03:38, 24 September 2020 (UTC)[reply]

Thanks, yes it is an issue in some situations, GreenC. In this case there is considerable systemic bias involved IMHO, as well as feuding sides... Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)[reply]

The names could be randomized, as is done with the arbitration committee elections, for example. But I think it is a bad idea to have randomly changing lists in articles. I think it would be better to find some neutral order, like alphabetical. isaacl (talk) 03:40, 24 September 2020 (UTC)[reply]

The problem with alphabetical is that reverse alphabetical is often the response, and both benefit one side or another in a dispute. Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)[reply]
The guidance from the manual of style is the "most basic form of organization is alphabetical or numerical". There isn't really a good argument for reverse alphabetical in an encyclopedia article. isaacl (talk) 04:06, 24 September 2020 (UTC)[reply]
OK, I see you're talking about the leaders of World War II... The country names really should be listed, not just flags, and maybe some numeric criterion (as I see has been suggested on the talk page) based on the countries could be agreed upon. isaacl (talk) 04:18, 24 September 2020 (UTC)[reply]
Correct, but the issue is that consensus on a metric doesn't seem likely. All sorts of factors are in play. Peacemaker67 (click to talk to me) 04:31, 24 September 2020 (UTC)[reply]
Status quo can stay in place, then, until enough editors agree on something. These are really short lists; it doesn't make much practical difference. isaacl (talk) 04:34, 24 September 2020 (UTC)[reply]
It's bad for the website caching to need to deal with a random order. Please generally avoid that in live articles. --Izno (talk) 04:12, 24 September 2020 (UTC)[reply]
What practical effect is there? Peacemaker67 (click to talk to me) 04:17, 24 September 2020 (UTC)[reply]
Because of caching, the order remains the same until the page is edited or purged. Caching takes precedence over randomisation, so randomisation in articles shouldn't have an adverse effect on Wikipedia's performance. — Mr. Stradivarius ♪ talk ♪ 12:16, 24 September 2020 (UTC)[reply]
<Queue people making small edits until the cache contains their preferred version.>
I think randomizing lists in a live article is not a good idea. Two people accessing the same revision of an article should see the same content, in the same order. –xenotalk 12:20, 24 September 2020 (UTC)[reply]
I agree. Don't see anything wrong with alphabetical, this strikes me as a solution in search of a problem. Nardog (talk) 14:05, 24 September 2020 (UTC)[reply]
For articles, don't think this should be attempted - the presentation order of content is a purely editorial matter and this sort of structure will make it harder for editors to manage the content - especially when using visual editor and expecting a WYSIWYG result. — xaosflux Talk 14:37, 24 September 2020 (UTC)[reply]
Random would seem to provoke the reader to question the meaning of the order, and why it would change. Then there's the performance issue, too. Alpha is reasonable. Another option in a list of belligerents is by date of engagement. —[AlanM1 (talk)]— 19:38, 24 September 2020 (UTC)[reply]
  • Agreed that alphabetical should be sufficient. Feel free to take the consensus from here to the page; unless there's some important context we've missed, it overrides the more local consensus per WP:CONLEVEL. I'd add that it's confusing for readers to see one order and then find a different order next time they visit the page. {{u|Sdkb}} talk 20:19, 24 September 2020 (UTC)[reply]

Category:Pages with non-numeric formatnum arguments

Does anyone know how this category is being populated? In Marlborough, Calgary, it seems to come from the {{Infobox settlement}} parameter elevation_m = 1075, but I can't really figure out anything beyond that. kennethaw88 • talk 19:45, 24 September 2020 (UTC)[reply]

Well, the category page has been created now, but it was a redlink for a while, and it only had 250 members when I saw it first. It's still a mystery to me where it is being populated. kennethaw88 • talk 21:43, 24 September 2020 (UTC)[reply]
Category:Pages with non-numeric formatnum arguments is now hidden, which helps, but the issue seems to be in {{infobox_settlement/lengthdisp}}. I can't get it to behave at all — GhostInTheMachine talk to me 22:44, 24 September 2020 (UTC)[reply]
It's due to use of {{INR Convert|2.5|c}} but I can't investigate further at the moment. Johnuniq (talk) 23:56, 24 September 2020 (UTC)[reply]
The category is populated for example when formatnum is used with "1,234" instead of "1234" (I tried on User:Seudo/test). According to a user on the French Wikisource, this was not the case a few days ago. Besides, {{formatnum:1,234}} used to produce « 1 234 » and it now produces « 1,234 ». If I understand correctly, this category is useful because {{formatnum:1,234}} is incorrect anyway. But maybe someone could confirm that the behaviour of formatnum has changed recently... Seudo (talk) 21:57, 26 September 2020 (UTC)[reply]
This category was created by gerrit:626024, which was merged on the 15th, and deployed around the 24th. * Pppery * it has begun... 17:30, 27 September 2020 (UTC)[reply]
When formatnum is given a correctly formatted negative number, e.g. {{formatnum:−9000000}}, it assigns this error category. See T237467. This apparent false positive currently applies to {{US Census population}}, which shows population declines, so many articles transcluding that template appear in this category.
Does anyone know a different way to do what formatnum does, but that accepts negative numbers as input? It would be great to get articles transcluding {{US Census population}} out of this error category. – Jonesey95 (talk) 19:00, 28 September 2020 (UTC)[reply]
Of course the best thing to do is to fix formatnum, but a template can do this as a stop-gap:
{{#invoke:String|replace|{{formatnum:{{#invoke:String|replace|−9000000|^[—–−]|-||false}}}}|^-|−||false}} → −9,000,000
Yeah, crude and ugly ...
—Trappist the monk (talk) 19:13, 28 September 2020 (UTC)[reply]

Infoboxes not using Template:Infobox mapframe?

Just found out about {{Infobox mapframe}}, which seems to be used in a lot of infoboxes. It seems much better than the old way, where coordinates were displayed on maps that could only be set from specified modules with coordinates and scale of the map baked in. But it isn't used, for example, in {{Infobox island}}. What's up with that? What would need to happen in order for the islands infobox to be update to use a mapframe (instead of the old one)? Is there a reason why we've chosen to keep the old one, or is it just that nobody's gotten around to all the infoboxes yet? {} 06:47, 25 September 2020 (UTC)[reply]

No-one has gotten to implementing the recent RFC on mapframes. --Izno (talk) 13:00, 25 September 2020 (UTC)[reply]
I've been adding them to some slowly, like station and settlement. Due to Q2 in the RfC, some talk discussion needs to be had on the location I think, which slows the process down a bit. A consensus to default to pushpin location, if exists, might've been handy. ProcrastinatingReader (talk) 20:07, 27 September 2020 (UTC)[reply]

Changes lost on accidentally navigating away from edit window

Every time I accidentally navigate out of the edit mode (such by clicking on a link in the preview), and go back, I find all my changes are lost and I've to start from scratch, which is extremely frustrating. I'm pretty sure this wasn't the case some time back – the edits used to get recovered. I'm wondering if it's something wrong with wikipedia or at my end? I'm using Chrome on Windows, if that matters. – SD0001 (talk) 07:01, 25 September 2020 (UTC)[reply]

There's an editing preference for that: "Warn me when I leave an edit page with unsaved changes". Also, on some browsers, you can go back to earlier pages including showing the wikitext in the edit box that you never saved. Johnuniq (talk) 07:44, 25 September 2020 (UTC)[reply]

Visual editor sometimes completely stuck on loading

This seems to have just started happening a few weeks ago. Are there things in my settings or preferences I should reset to default in case it is something I have changed such as adding scripts? Chidgk1 (talk) 07:28, 26 September 2020 (UTC)[reply]

@Chidgk1: I would suggest trying the steps mentioned at mw:Help:Locating broken scripts. If it still doesn't work, you'll want to file a bug on Phabricator. Kaldari (talk) 23:10, 27 September 2020 (UTC)[reply]

Copy-and-paste translation problem in editable content of non-English language

Hello VP, yesterday I created an article "List of Oteckovia episodes". I wanna expand "Episode" section, with bring "Part" section information from its Slovak language for TV series Oteckovia. Unfortunately, my Google Translation couldn't translate it to English language as I entered editing session. I desired to copy-and-paste the Slovak language when words completely translated to English, but I can't do this. I also raised this at help desk for their help. I acknowledged that this community stands for technical issues. In short, can you do the following by yourself.

1. Copy the Part section of listed episodes in List of Oteckovia episodes to List of Oteckovia episodes
2. Remember that this copy-and-paste method is complied with translation to English.

Thank you The Supermind (talk) —Preceding undated comment added 22:40, 26 September 2020 (UTC)[reply]

Tables, row headers, and accessibility

Hello all,

Per WP:DTT, row and column headers are recommended for use in tables used in articles on Wikipedia. However, it's unclear whether this is a suggestion or a recommendation or a mandatory requirement. I personally think that both should be made mandatory unless there is some very good reason not to include them. This will help ensure that people whose screen reader software does not already associate the rows/columns with the first cell in such row/column are able to easier understand the content of a table. I am not proposing a mass removal of tables without headers or a mass change of tables currently used in articles either, but I do feel that it should be clarified in the MOS, fixed when it is happened upon by an editor aware of it, and be grounds for adding headers to tables already in place.

One issue with this proposal is that currently, row headers are rendered by most browsers as bold, with a different background, and with centered text. For a variety of reasons, it is often desirable to have the row header simply display as a regular cell - for which the table class of "plainrowheaders" exists. Unfortunately, however, this only removes the bolding and removes the forced centering of text - it does not change the background color to be that of a normal cell. This means that even when the table has a class of "plainrowheaders" there is still a noticeable and sometimes undesirable difference between the row header and the rest of the row. For this reason, I recommend that row header cells be given the "background: #f8f9fa;" style when the table as a whole uses the "plainrowheaders" class. This could (to my knowledge) be accomplished by changing the below section in MediaWiki:common.css. For the main reason of the appearance and the likely disagreement as to requiring row headers if there is no easy way to limit their change in appearance, the first proposal is contingent on this one.

Changes proposed, in more detail.

Current MediaWiki:common.css 

/* Normal font styling for wikitable row headers with scope="row" tag */
.wikitable.plainrowheaders th[scope=row] {
	font-weight: normal;
	/* @noflip */
	text-align: left;

Proposed MediaWiki:common.css 

/* Normal font styling for wikitable row headers with scope="row" tag */
.wikitable.plainrowheaders th[scope=row] {
	font-weight: normal;
	background: #f8f9fa;
    /* @noflip */
	text-align: left;

Current MOS on tables §Overview of basics§Row & column headers Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.

§Overview of basics§Layout of table headers As can be seen in the example above, row headers are formatted by default as bold, centred and with a darker background. This is the common behavior across the Internet, and the default rendering in most browsers. In some circumstances it might be desirable to apply a style customized for a specific case. The class plainrowheaders will apply left-aligned and normal-weight formatting so that editors do not feel the need to override the header formatting with inline CSS declarations for each cell. Used by itself, plainrowheaders will make headers appear similar to unmodified data cells, except for the darker background.

Proposed MOS on tables §Overview of basics§Row & column headers Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request. Row and column headers should be used in all data tables present in articles.

§Overview of basics§Layout of table headers As can be seen in the example above, row headers are formatted by default as bold, centred and with a darker background. This is the common behavior across the Internet, and the default rendering in most browsers. In some circumstances, it may be preferable for row headers to be displayed as a normal cell. The class plainrowheaders will modify the table to cause row headers to appear as a normal cell - so that editors do not feel the need to override the header formatting with inline CSS declarations for each cell.

I tried looking a lot to see if there had been any reasoning for not including this in the class when it was created, but I couldn't find any. I will post at MediaWiki talk:common.css and at the talk pages of the relevant MOS pages regarding this proposal - but I'm not sure if there's more I should do for proposing such a large change. Thanks in advance for considering/discussing. -bɜ:ʳkənhɪmez (User/say hi!) 02:44, 27 September 2020 (UTC)[reply]

I support the lighter row-header background color for plainrowheaders class. But only if the data cells' background color is white as with class=mw-datatable. There needs to be contrast between header cells and data cells. [Later note: I was falling into the desire of some MOS warriors to have only way to do many things. Choice is better. People can choose to use class=mw-datatable or not. To distinguish header cells or not. It makes no difference to blind users using screen readers. They can't see the background color. Their screen readers see <th> and scope=row. But the lighter row header background color is better for the visually impaired, and for people like me. See discussion.]
Berchanhimez, please see related discussion:
Talk:COVID-19 pandemic by country and territory#Pandemic by region table. Format choice
From: Template:Color box {{color box|color|text|text color}}:
 f8f9fa - proposed background color by Berchanhimez for plainrowheaders 
Table below is from the table button in the wikitext advanced edit bar.
  • class="wikitable"
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example
  • Added class=mw-datatable to table below.
Run cursor over rows to see rows highlight. Note that the data cells are white. I prefer that for better contrast when screen brightness is turned down. When screen brightness is turned down everything turns grayer. This added grayness (for whatever reason) can make things difficult for the visually impaired. It bothers me too. I keep screen brightness turned down to 80% almost all the time except for video viewing.
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example
  • Added class=plainrowheaders and scope=row to table below.
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example
  • Same table but without class=mw-datatable
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example


  • class="wikitable mw-datatable plainrowheaders". Also added proposed row header background color (#f8f9fa).
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example
--Timeshifter (talk) 05:02, 27 September 2020 (UTC)[reply]
  • Not sure I like the distinction between a row header and a column header, when both are headers. However, I just found out about mw-datatable which is really good. Not sure why the default isn't with this set on, and any table which is of type presentation can set it to that which will disable this. presentation is a far less common type. This can even be backwards compatible with making a new default class of wikitable2. --Gonnym (talk) 10:18, 27 September 2020 (UTC)[reply]
    @Gonnym and Timeshifter:, Thanks for the comments. I'll point out that nobody is going to be forced to use this class - just as nobody is now. You're also correct that in many cases a row header should be distinguishable from the surrounding cells. This is especially true for many of the tables on the COVID-19 pandemic by country and territory page. However, there are also times where the first cell in a row should be labeled as a header, but it does not need to be distinguishable from the other cells in the row - that's the entire reason for the class plainrowheaders to exist. I am merely proposing that we make "plain row headers" do what it suggests it should. Right now, "plainrowheaders" results in "normal text on a different background" - which is definitely not plain. The only current way for an editor to use row headers (for accessibility) and to have them look like normal cells involves each cell getting its own style="background: #f8f9fa;" - which is not only less efficient and harder for editors, but it makes the edit window a lot harder to use.
    Personally, I think it may be an issue because I have seen quite a few tables with "scoped column headers" (i.e. where they're properly constructed with scope="col" explicitly) but not the same for rows. I think a large reason for this may be due to the fact that the editor does not wish to have "row headers" highlighted over regular cells in any way, thus they try class="plainrowheaders", see that it doesn't work (i.e. it leaves the background color changed), and so they give up and don't use row headers. Again, I'm not proposing to change the default in any way - just to change this one class to actually do what it says it will do (make them plain cells). I will say I don't know that adding more table classes is going to work, and in fact I suspect it may be detrimental - I still have no clue how many table classes there actually are, but I know it's somewhere upwards of 10 and likely many more, and I have to look up anything other than wikitable mw-sortable floatright to use them right. Adding another class will just likely hardly get used and thus not do much for this issue. -bɜ:ʳkənhɪmez (User/say hi!) 10:56, 27 September 2020 (UTC)[reply]
    CSS allows us to style anything anyway we like. That does not mean we should. Accessibility isn't only for people with sight impairment. If you create a table which has the table header cell looks exactly like a table data cell, that also makes my reading and understanding of it harder, and I can see it. The fact that editors don't use scope or proper code isn't new. A lot of users don't know and also a lot don't care. Take a look a most reality television articles and you will see all kind of tables - most of which aren't accessible. Just to make my point "official", I'd oppose changing how plainrowheaders currently work. --Gonnym (talk) 11:05, 27 September 2020 (UTC)[reply]
    Gonnym, Thanks. I was also pointed to a discussion from 2010 about it so apparently I'm not the first to have this idea. Sorry for the time waste here guys, but thanks for opining regardless. -bɜ:ʳkənhɪmez (User/say hi!) 14:46, 27 September 2020 (UTC)[reply]
    I'm (still) with Gonnym; I oppose the suggested changes. Berchanhimez says, ... in many cases a row header should be distinguishable from the surrounding cells. I believe the correct statement is, "in all cases a row header should be distinguishable from the surrounding cells." — JohnFromPinckney (talk) 18:22, 27 September 2020 (UTC)[reply]

I struck out some of my first post, and added a later note. I was falling into the desire of some MOS warriors to have only way to do many things. Choice is better. People can choose to use class=mw-datatable or not. To distinguish header cells or not. Background color makes no difference to blind users using screen readers. They can't see it. Their screen readers see <th> and scope=row.

Regardless of whether class=mw-datatable is used or not, the lighter row header background color is better for the visually impaired, and for people like me. See discussion. I believe that some MOS warriors don't care about this problem for the visually impaired and for me. They would rather have conformity, and no change in "The Rules". Even if the supposed reason for these accessibility rules is to help the visually impaired. I do not have the more severe definition of visual impairment: Impairment that approaches functional blindness. I just have normal vision problems of nearsightedness, farsightedness, presbyopia, and astigmatism. And my eyes can't handle screen brightness set at 100%.

The bottom line is that the left table below is much better than the right table. For the detailed discussion about shading, bolding, blue links, contrast, and WCAG standards, see this discussion.

Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example
Caption text
Header text Header text Header text
Example Example Example
Example Example Example
Example Example Example

--Timeshifter (talk) 04:27, 28 September 2020 (UTC)[reply]

Gadget: "Require confirmation before performing rollback on mobile devices"

The 2nd gadget in browsing tab, titled "Require confirmation before performing rollback on mobile devices", doesn't seem to actually do anything for me. I think it is User:MusikAnimal/confirmationRollback-mobile by MusikAnimal. Is it just me or is it broken? If the latter, any other way to get rollback confirmations on mobile? The button is massive (many times the size of diff or something) and all over watchlist etc, I've hit it a few times myself accidentally. Thanks. ProcrastinatingReader (talk) 19:57, 27 September 2020 (UTC)[reply]

Syncing WikiLove barnstars with local templates

mw:Extension:WikiLove is, apparently, commonly used for handing out barnstars. We also have our local barnstars, at Wikipedia:Barnstars#General_barnstars. Some of these are in sync with the extension, others are not (e.g. the extension uses label "The Technical Barnstar", whereas we locally use {{The da Vinci Barnstar}} (with alt option)). It's a very small issue, but just wondering if there's some neat way we can keep the two in sync? The extension unfortunately seems to use 'phrases' as pages, not templates (and MediaWiki:WikiLove.js as central config), so I don't think we can just create each MediaWiki page and point it to the template. It'd also be neat to give some control to community (or limit to TEs, if need be) to be able to add/remove/modify the barnstars shown. Also pinging @Kaldari and MSGJ: who might know. ProcrastinatingReader (talk) 20:04, 27 September 2020 (UTC)[reply]

@ProcrastinatingReader: It's easy to add new barnstars to WikiLove (regardless of whether they have a template or not). If you look at the MediaWiki:WikiLove.js page on MediaWiki.org you can see how they added a Translator Barnstar there. The MediaWiki:WikiLove.js page on Commons has more examples, adding the Tireless Contributor Barnstar and Copyright Watcher Barnstar. You can also delete barnstars if they aren't relevant here. (See the bottom of the Commons page for examples of deleting barnstars.) But yes, you do need Administrator or Interface Editor rights to modify the MediaWiki:WikiLove.js page. Kaldari (talk) 22:57, 27 September 2020 (UTC)[reply]
Kaldari, well, it can be edited by admins but I mean more in the sense that there's WikiLove extension barnstars that have the same purpose as our local ones, but with different names (eg "The Technical Barnstar" v "The da Vinci Barnstar"). I think it's a bit confusing (took me a while to figure out that the former was coming from an extension). And the limitation to sysops only, to edit, I think may make it used less (our WikiLove.js is far more empty than the Commons one). I think some way to have it in sync with our local barnstars, via a template, and also modifiable as such, would be an improvement. One thought I had was perhaps a template with a switch returning particular values to the MediaWiki pages, since the extension only exposes the phrases and not the full template for editing, but this wouldn't add the ability to add/modify barnstars. ProcrastinatingReader (talk) 14:11, 28 September 2020 (UTC)[reply]

Distinguishing between variables defined and variables defined and set to something

I'd like to design a template that behaves in the following way:

How do I code this? I'm not sure how conditional expressions like #if handle the difference between just defining "header" (as in the second example) and defining it and setting it equal to something (as in the last example). {{u|Sdkb}} talk 23:20, 27 September 2020 (UTC)[reply]

There is no such thing as a parameter defined without being set. {{subst:the_template|header}} is equivalent to {{subst:the_template|1=header}}. * Pppery * it has begun... 23:27, 27 September 2020 (UTC)[reply]
@Pppery: I'm not sure I have the terminology quite right with "defined" and "set". But what I'm trying to do is the above. Are you saying that that is impossible? I feel like I do recall some templates that have behaved differently between {{subst:sample_template|1=foobar}} and {{subst:sample_template|foobar}}. {{u|Sdkb}} talk 23:43, 27 September 2020 (UTC)[reply]
No, it's not impossible. My point was more that what you are doing is inventing a non-standard parameter convention, while phrasing it as if it were standard. What you are trying to do can be accomplished by {{{header|{{#ifeq:{{{1}}}|header|DEFAULT_HEADER|NO_HEADER}}}}}. However, I think that syntax is confusing, and it would be cleaner to do something like {{yesno|{{{header|}}}|no=NO_HEADER|yes=DEFAULT_HEADER|def={{{header}}}}}, which turns "|header=yes", and other yes-like values (as defined by Template:Yesno) into the default header, and turns |header=no and other no-like values (including the empty string) into no header, while leaving any unrecognized values as it. It's somewhat difficult to discuss this in the abstract, so it may help to point to a specific template you are trying to implement. * Pppery * it has begun... 00:03, 28 September 2020 (UTC)[reply]
Pppery, thanks! I'll go with the cleaner suggestion. The application is to a few different templates in the user warning space, such as {{Ping fix}}. {{u|Sdkb}} talk 04:13, 28 September 2020 (UTC)[reply]

Questions regarding page views / analytics

Hello all:

Had a few questions regarding page views / analtyics, and was wondering what was the best place to ask those questions. I know, I had posted a question re: geographic slices of traffic, and MusikAnimal had helped answer, that we didn't have that ability.

Follow-up questions:

1. Is there a way to get referral information for a page. Specifically % page views by referring page. E.g. %page views coming in from Main_Page, %page views from Article A etc.

2. Also, I was slicing some comparative analytics and this chart caught my attention. link to chart. Do we know what happened at the end of April that caused that dip? If this was a change in measurement, did that cascade to the article pages as well?

Greatly appreciate pointers to a different group, if that is a better place to ask these questions.

Thanks, Ktin (talk) 01:05, 28 September 2020 (UTC)[reply]

  1. Nope. There might be a Phab task somewhere for it.
  2. Yes. Automated was created. The views associated were accordingly recategorized.
--Izno (talk) 01:13, 28 September 2020 (UTC)[reply]

Listing additions/removals of a category

Is there a tool that allows you to see recent additions and removals of a category? I recently realized you could make this if you used the Recentchanges API, but I wonder if there already is one. Nardog (talk) 14:22, 28 September 2020 (UTC)[reply]

@Nardog: add the category to your watchlist, then on your watchlist uncheck the "hide page categorization" box. — xaosflux Talk 14:26, 28 September 2020 (UTC)[reply]
@Xaosflux: I already do that, I'm asking if there's a way to list them per category without having to watch it because categories with frequent traffic can easily overflood the watchlist. Nardog (talk) 14:31, 28 September 2020 (UTC)[reply]
Go to Preferences → Recent changes, and disable "Hide categorization of pages"; and at Preferences → Watchlist, disable "Hide categorization of pages". --Redrose64 🌹 (talk) 14:29, 28 September 2020 (UTC)[reply]
@Redrose64: What I said to Xaosflux. Nardog (talk) 14:41, 28 September 2020 (UTC)[reply]
For a specific category, the categorymembers API can be used with sorting set by timestamp. For example, here's the 100 latest additions to Category:Living people. – SD0001 (talk) 16:06, 28 September 2020 (UTC)[reply]

Implement "smart" custom toggles which act based on their state

Do you know how long an enhancement request takes to be reviewed at Phabricator? I created a task, phab:T262622, more than two weeks ago and it still hasn't been commented. I don't know the workflow there, so if such change would likely take longer, would it be adequate to implement the request (given it's accepted) here (at the MediaWiki namespace)? The script linked in the task is my sandbox. I will change it sometime to just make it support a new behavior and not modify existing. Already posted something similar in WP:VPR but had no reply. Alexiscoutinho (talk) 16:13, 28 September 2020 (UTC)[reply]

@Alexiscoutinho: much like the encyclopedia content, there is no deadline for enhancement requests - they are done by volunteers. Asking for something is fine - but the only way to ensure that it actually gets done would be to do it yourself (write a patch, test it, upload it) - otherwise you have to wait to see if a volunteer developer is interested on your request. Sometimes these get worked on "quickly" (i.e. under a month), while there are some requests that have been open for over 10 years. — xaosflux Talk 16:26, 28 September 2020 (UTC)[reply]
@Xaosflux: Does this mean I can self-assign a task? Alexiscoutinho (talk) 16:29, 28 September 2020 (UTC)[reply]
Yes, you can self-assign a task, but you cannot self-merge (perhaps, obviously). Getting review time is a pain, AIUI, but if the case is good (see below comment), in the realm of possible. --Izno (talk) 17:00, 28 September 2020 (UTC)[reply]
@Alexiscoutinho: Phabricator tasks can sit for a long time, especially, as with your apparent problem article, when it's not obvious what the problem is or if the solution you have apparently devised is actually fixing the root of the problem. To pick on the specific, the COVID articles are in-general pathological in their assumptions about article size, rendering software, etc etc. Is adding to the already (for-Wikipedia) sizeable Javascript load these lines of software actually necessary for all articles? Especially when we have WP:MOSCOLLAPSE? --Izno (talk) 17:00, 28 September 2020 (UTC)[reply]
@Izno: I think my task description clearly explains the problem and even gives some examples to aid visualization. The solution/script I provided does fix the root of the problem although there is a less invasive way it can be implemented and which I will in the near future. I didn't want to say it was THE solution because I would expect more experienced coders to review it and maybe even find a better solution. If the change was implemented in MediaWiki core, it wouldn't increase too much the plugin's number of lines. If it was implemented temporarily in the MediaWiki namespace it would only boost the number of loaded JS lines in the pages that have {{Medical cases chart}}. I think WP:MOSCOLLAPSE doesn't apply here because the collapsing doesn't hide very important info, it just tidies the layout. Furthermore, no info would be omitted on mobile as collapsing is fully disabled in that case. Alexiscoutinho (talk) 17:33, 28 September 2020 (UTC)[reply]
I think my task description clearly explains As someone looking at it from the outside, no. --Izno (talk) 17:43, 28 September 2020 (UTC)[reply]
@Izno: Well then, when I update my script I'll try to rephrase the description. Alexiscoutinho (talk) 18:04, 28 September 2020 (UTC)[reply]
Yes, it should be recast. Perhaps in a user story template kind of fashion. --Izno (talk) 18:07, 28 September 2020 (UTC)[reply]
I think I have a basic idea what the Phab ticket is asking for, however following the scheme in mw:How to report a bug and structuring the task in separate sections is always welcome so others could also get a better grip. For general info on why tickets often remain open and uncommented, see mw:Bug management/Development prioritization. Thanks! --AKlapper (WMF) (talk) 18:40, 28 September 2020 (UTC)[reply]

Templates not rendering in ITN archives

Hello, is there a maximum number of templates per page? The ITN archives are large pages and recently we've noticed that the templates aren't expanded for all occurrences in the page. Consider the August 2020 archive. Someone said that there is an upper bound on the number of templates. Is this true? I didn't see anything obviously broken on that August 2020 page. --LaserLegs (talk) 20:05, 28 September 2020 (UTC)[reply]

@LaserLegs: Yes, WP:TLIMIT. --Redrose64 🌹 (talk) 20:11, 28 September 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=980846099"