Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Farvardyn (talk | contribs)
27 edits
Line 646: Line 646:
::{{ping|PrimeHunter}} Thanks, it worked. What if I want to do use (IF A & B both are empty) or not set? How this if clause should look like?
::{{ping|PrimeHunter}} Thanks, it worked. What if I want to do use (IF A & B both are empty) or not set? How this if clause should look like?
:::{{ping|Farvardyn}} <code><nowiki>{{#if:{{{A|}}}{{{B|}}}|At least one of A and B is set|A and B are both empty or not set}}</nowiki></code> [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 17:15, 4 May 2020 (UTC)
:::{{ping|Farvardyn}} <code><nowiki>{{#if:{{{A|}}}{{{B|}}}|At least one of A and B is set|A and B are both empty or not set}}</nowiki></code> [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 17:15, 4 May 2020 (UTC)

::{{ping|PrimeHunter}} Sorry, it still is not working when I tried to add some more options to the code. I updated Stackoverflow with my full code as here: https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired why it is happening again? Isn't it a bug in this feature? I highly appreciate if you look in my updated code there.
[[User:Farvardyn|Farvardyn]] ([[User talk:Farvardyn|talk]]) 06:15, 5 May 2020 (UTC)


==Is a fix needed==
==Is a fix needed==

Revision as of 06:15, 5 May 2020

 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.


Automatic redirects from non-breaking hyphens in page titles?

I was interested in doing a search-and-replace of 2019–20 coronavirus pandemic to replace all the hyphens in mentions of "COVID-19" and "SARS-CoV-2" with non-breaking hyphens[1] to prevent unwanted line breaks in the middle of those words. However, doing so broke a ton of wikilinks when I tried to preview the page, since it seems the software doesn't automatically redirect from non-breaking hyphens to breaking hyphens in page names, the same way it does for some capitalization differences. I can see this being an issue at other pages where one might want to make a similar fix, and even if I had fixed things manually at 2019–20 coronavirus pandemic, the issue would come back as the page evolves. So is there any chance we could do something to the automatic redirect software to take care of this? {{u|Sdkb}} talk 00:41, 22 April 2020 (UTC)[reply]

"COVID-19" and "SARS-CoV-2" are using hyphen-minuses instead of hyphens, so really titles with non-breaking hyphens and normal hyphens should redirect to the title with minus-hyphens. For example COVID-19 vaccine exists, but COVID‐19 vaccine and COVID‑19 vaccine do not. We could fix this by using a bot that would create the appropriate redirects and move the page to the version using hyphen-minuses when needed.– BrandonXLF (talk) 21:23, 22 April 2020 (UTC)[reply]
Some other solution would be better because using something other than a hyphen will confuse editors and break searching for "COVID-19" with the normal hyphen. Johnuniq (talk) 00:03, 23 April 2020 (UTC)[reply]
@BrandonXLF and Johnuniq: yikes, hyphen-world is complicated haha. Trying to get this straight: so hyphen-minus and hyphen are separate things. And the page titles are all at hyphen-minus. Is hyphen-minus also the grammatically correct option? Is hyphen-minus what you get when you press the button on the keyboard (and thus what people will be searching for)? A bot to fix this sounds fine, if it can't be done more directly than that. Do we know what allows redirects via miscapitalization to work, and could we replicate whatever process does that? This seems more analogous to that situation than anything else. {{u|Sdkb}} talk 07:58, 24 April 2020 (UTC)[reply]
Hyphen and hyphen-minus are the same thing. I wouldn't think there is anything a bot can fix. Johnuniq (talk) 08:01, 24 April 2020 (UTC)[reply]
@Johnuniq and Sdkb: They're different. Hyphen-minus (-) is the hyphen on the keyboard and can be used as a hyphen or as a minus sign whereas a hyphen (‐) is only used as a hyphen and is not used as much and its use is discouraged here on Wikipedia. – BrandonXLF (talk) 19:28, 24 April 2020 (UTC)[reply]
See hyphen-minus and hyphen. --Redrose64 🌹 (talk) 20:11, 24 April 2020 (UTC)[reply]
@BrandonXLF, Redrose64, and Johnuniq: Okay, so what we need then is a way to automatically redirect any title with a hyphen or non-breaking hyphen to a hyphen-minus. Any ideas on how to do that? I can't figure out how the software does it for capitalization — trying to go to foobar (with a lowercase f) just goes to Foobar (the page title) without even showing there was any redirect. {{u|Sdkb}} talk 01:14, 25 April 2020 (UTC)[reply]
User:AnomieBOT creates these redirects (EnDashRedirectCreator - "because titles with en-dashes are hard to type"). If there's a dash type missing, ping the botop. Primefac (talk) 23:11, 30 April 2020 (UTC)[reply]
@Anomie: would it be possible to have this bot also create redirects from non-breaking hyphens? {{u|Sdkb}} talk 05:24, 2 May 2020 (UTC)[reply]
I would oppose these generally. People will copy-paste whatever they can find, and in that case I actually don't think you should be replacing them at all. People will not understand what they have is non-breaking and having to teach the distinction is a time waste here. --Izno (talk) 12:41, 2 May 2020 (UTC)[reply]
@Primefac and Sdkb: AnomieBOT is currently approved only to create hyphen-minus-using (U+002D) redirects for titles containing en-dash (U+2013). It would be pretty easy to do the same for titles containing Unicode hyphen (U+2010), non-breaking hyphen (U+2011), and/or other similar characters, but I'd want to have a decent consensus (here or on WP:VPR) to point to before submitting the BRFA. Note I'm taking a wikibreak at the moment, so if such a consensus is reached please ping me again. Anomie⚔ 23:35, 2 May 2020 (UTC)[reply]
As an alternative, Sdkb, would it help to have a template, say {{nobl}}, that combines no-break with wikilink? E.g. {{nobl|SARS-CoV-2}}. Or is it just as easy to write explicitly {{nowrap|[[SARS-CoV-2]]}} → SARS-CoV-2, avoiding yet-another-template overload? You can pipe the link, but the source gets ugly with entity references, and confusing with lookalike characters: [[SARS-CoV-2|SARS&#x2011;CoV&#x2011;2]] and [[SARS-CoV-2|SARS‑CoV‑2]]. The difference between nowrap styling and displaying actual no-break-hyphen characters is what the user gets when copy-pasting rendered (not source) text. Pelagic (talk) – (08:32 Mon 04, AEST) 22:32, 3 May 2020 (UTC)[reply]
@Pelagic: Using the nowrap template seems like a good solution. And for many cases, we don't want to wikilink, so all the better that it's optional. My hesitation for adding it to the big COVID-19 pages is that many are already bumping up against the post-expand include size limit, and adding more template calls might push it over, which wouldn't be worth it for such a small change. {{u|Sdkb}} talk 22:37, 3 May 2020 (UTC)[reply]
It seems there isn't a super easy way to do this (for find-and-replace, there's also the issue of URLs within references being broken in some cases), so I think I'm going to just give up on it for now. {{u|Sdkb}} talk 22:38, 3 May 2020 (UTC)[reply]

Problem with Open Street Map integration

I'm not sure what the official name of the tool is, but I'm using the "Map all coordinatates using Open Street Map" link on Category:Wikipedia requested photographs in the Bronx. That gets you to here. The problem is that when you mouse over the links in the left-hand nav bar, the map automatically scrolls to the coordinates of each link. This is fine as long as you're at the default zoom. But, go to the link above, then click "+" a few times to zoom in several levels. Now, move the mouse over the nav bar; the map scroll around crazily to track whichever link you happen to be over at the moment. Uber-annoying. Does anybody know any way to stop it from doing that? -- RoySmith (talk) 21:33, 26 April 2020 (UTC)[reply]

I don't either, but it is annoying and has wasted my time too. It needs to be fixed.--Epiphyllumlover (talk) 02:21, 27 April 2020 (UTC)[reply]
That tool is maintained by DB111, Kolossos, and Plenz. If I remember correctly, that behavior is part of the map library, and I don't remember how configurable it is. It might be useful to convert the tool to a more modern library, but that takes work. --AntiCompositeNumber (talk) 16:28, 28 April 2020 (UTC)[reply]
I'm not a core maintainer of the tool, so I can't help. But I wrote a similar tool with subcategory capabilities, even though it won't help in your case, because it cannot handle talk pages. --DB111 (talk) 18:24, 28 April 2020 (UTC)[reply]
I hadn't heard about your tool, but I've already found it useful. It is more stable and doesn't jerk around. I wish there was a way to generate permalinks to settings besides location based categories. For example, it would be nice if one could wikilink to any single point directly with it set to view images from Wikimedia Commons. If someone could develop this, maybe Wikimedia Commons could switch to entirely using this tool when linking to coordinates.--Epiphyllumlover (talk) 20:56, 29 April 2020 (UTC)[reply]
It has different modes, if you omit all parameters it's a simple nearby tool, but you can also jump to a location. Take a look at the short documentation. --DB111 (talk) 12:16, 30 April 2020 (UTC)[reply]

Technical maintenance planned

Tracked in Phabricator
Task T250733

A maintenance operation will be performed on Thursday 30th April at 05:00 AM UTC.

It impacts all wikis and is supposed to last a few minutes.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Please help making your community aware of this maintenance operation.

Trizek (WMF), 18:04, 27 April 2020 (UTC)[reply]

@Trizek (WMF): Phab is a big place - perhaps a ticket number? — xaosflux Talk 18:45, 27 April 2020 (UTC)[reply]
Looks to be phab:T250733. — xaosflux Talk 19:50, 27 April 2020 (UTC)[reply]
There are three maintenance windows planned soon, Trizek sent a longer message to Wikitech-ambassadors describing them. --AntiCompositeNumber (talk) 16:22, 28 April 2020 (UTC)[reply]
Remember the first m:Server switch, which was a huge deal that caused almost half an hour of read-only mode? Now it seems that they've gotten it down to a few minutes, and hardly anybody notices. Whatamidoing (WMF) (talk) 16:08, 30 April 2020 (UTC)[reply]

Creating template redirects with parameters

Is there any way to create a redirect to a template that includes defined parameters? I'd like to have {{Don't ping}} redirect to {{Please ping|no}}. Just calling the template on the redirect page itself doesn't work because then it doesn't substitute properly. {{u|Sdkb}} talk 18:48, 27 April 2020 (UTC)[reply]

As in #redirect [[Template:Please ping|no]]? No. The closest you can get is to make the content of the 'redirect' page the particular template you are trying to use. You can also make the target template a subst version with some clever transcluding tricks; between the two, I think you will get where you are trying to. Unfortunately, I don't remember how exactly to make that trick work. --Izno (talk) 19:40, 27 April 2020 (UTC)[reply]
The main impetus behind my proposal was consolidating overproliferated templates (I'd like to make {{Please ping}} good enough that the four (4!) other duplicates can be merged into it, but that won't really be possible for ones like {{Nw}} unless I can get that to redirect to {{Please ping|Nw=yes}}. So duplicating at the redirect definitely wouldn't be my preference. Overall, this seems like it'd be a useful software feature to help combat the overproliferation of templates that make them so hard to maintain (just see e.g. Wikipedia:Current event templates) — they should all be merged). {{u|Sdkb}} talk 19:50, 27 April 2020 (UTC)[reply]
You'd have to make it a wrapper. Primefac (talk) 20:39, 27 April 2020 (UTC)[reply]
@Primefac: I just read through Wikipedia:Wrapper templates, but it's not all that thorough. Would you or someone else be able to show me how to use it in this case? I could then try updating the documentation to pay it forward to others. {{u|Sdkb}} talk 23:33, 27 April 2020 (UTC)[reply]
Well, if you want {{Don't ping}} to display {{Please ping|no}}, you make the content of the former equal to the latter. Another example is {{Exams}} being a wrapper for {{Wikibreak}}. Primefac (talk) 23:45, 27 April 2020 (UTC)[reply]
@Primefac: Ah, that's a million times simpler than the page made it seem. Thanks! I still had a little trouble with making the substitution safe but figured it out after some fiddling around in the sandbox. I'm going to go ahead and perform the consolidation as I mentioned above and here. If you have any issues with wordings being changed too much, feel free to let me know and we can make tweaks as needed. {{u|Sdkb}} talk 02:41, 28 April 2020 (UTC)[reply]
@Primefac: if I can badger you with another question about wrapper templates, is there a way to pass parameters not specified by the wrapper itself through them? For instance, I turned Template:Welcome-autosign into a wrapper a month ago, but I wasn't able to figure out how to get it so that you could use, say, {{Welcome-autosign|cookie=y}}. Is there a way to do that? {{u|Sdkb}} talk 00:19, 4 May 2020 (UTC)[reply]
In a word, no. If {{B}} is a wrapper for {{A}}, and A has a |p1=, the only way you can pass |p1= to A via B is if B specifically uses or includes the param in the call to A. Primefac (talk) 19:10, 4 May 2020 (UTC)[reply]
@Sdkb: You're looking for Module:Template wrapper. * Pppery * it has begun... 19:14, 4 May 2020 (UTC)[reply]

RfC: should the "Authority control" template continue to include MusicBrainz identifiers?

Should {{Authority control}} continue to include MusicBrainz identifiers? 08:34, 28 April 2020 (UTC)

Basics and technicalities

The {{Authority control}} template, usually found as last of the navigation templates at the bottom of Wikipedia articles, lists a series of internally linked authority control systems, each followed by an external link to the identifier for the topic of the Wikipedia article in that system. These are international systems of one-of-a-kind unique identifiers which as well distinguish topics with a similar name, as that they identify the preferential name for a topic within a system. Example (using Bibliothèque nationale de France identifiers):

  • Engelbert Humperdinck (composer) → BnF 13895404h
  • Engelbert Humperdinck (singer) → BnF 13970123h
  • Engelbert Humperdinck (album) → BnF 378510480

MusicBrainz is a WP:USERGENERATED website, which has separate pages on various music-related topics. The URL of each page ends on a multi-digit code, which works similarly as an identifier in an authority control system, e.g.:

Wikidata is the international authority control system of Wikimedia projects (including Wikipedias in all available languages, Wikimedia Commons, Wikisource, ...). It is recognised by other international authority control systems, e.g.: VIAF 71578307 links to Engelbert Humperdinck (Q55010). Likewise, MusicBrainz's page on the composer (see link above) links to that same Wikidata item. The Wikidata item on the composer is not accessed directly from the {{Authority control}} box at the bottom of the composer's article: the Wikidata item on the composer is accessed via the Wikidata item link in the left margin of the article (which is always present, whether or not the {{Authority control}} box is placed).

By default, an {{Authority control}} box placed in an article retrieves its content from the corresponding Wikidata item, that is: the box lists and links the authority control records of the systems accepted by the template (see list of tracking categories), when the corresponding Wikipedia item contains a value, a.k.a. property, of such an external authority control system. Values for external links in the box can be overridden locally, but once a value for the property has been defined in the Wikidata item, the listing and linking of the external authority control system can not be omitted from an {{Authority control}} box once it is placed in an article. For clarity: the RfC question is not about omitting authority control identifiers from Wikidata, but on whether or not MusicBrainz identifiers should be kept as tracking categories in Wikipedia's {{Authority control}} box.

Previous (much broader) RfC: Wikipedia:Village pump (policy)/Archive 148#RfC: authority control (Dec. 2018 to Feb. 2019: came to no conclusion about the MusicBrainz identifier which at that time was already included in the {{Authority control}} box).

Previous related discussions: Wikipedia:External links/Noticeboard/Archive 21#MusicBrainz (May-June 2018; "external link" aspect, discussion without formal closure: did not result in a change w.r.t. acceptability of linking to MusicBrainz pages as part of an "External links" list). Around the same time proposals regarding a selective display of some authority control identifiers, while omitting others, was extensively discussed at Template talk:Authority control/Archive 7#Suppressing local display via null parameters – without resulting in anything.

Last discussion on the topic (leading to this RfC): Template talk:Authority control#MusicBrainz

Survey

  • No – my main reason for this stance is the over-all low quality of too many MusicBrainz pages linked from Wikipedia (examples can be given if needed – in the preparation to this RfC I asked if *anyone* could give me an example of a good, or at least decent, MusicBrainz page, which remained an "unanswered question"); Note that that previous argument is about the *actual* low quality of these pages, not merely about their WP:USERGENERATED status, which is of course a further argument; Further the BBC website does not seem to link to Wikipedia via MusicBrainz very often any more (only one example where they currently do could be given in the preliminary talks, after I had already given a counterexample); Further, the argument that Wikipedia should link to MusicBrainz mainly for its "authority control" characteristics does not outdo Wikipedia's policy against organising linkfarms (WP:NOTLINKFARM – keep links such as MusicBrainz in the Wikidata system where they can be accessed after one click from the Wikipedia article); The actual MusicBrainz identifiers are *longer* than what is displayed in the authority control box, respectively "artist/30060b66-4ed3-47a5-89d7-cb4f13437441", "artist/62c28bc0-f696-4c50-8e54-5f8e9120bdb8" and "release-group/18d4abd6-580d-45f1-8ba6-1d2bb1ad245f" for the examples given in the "Basics and technicalities" summary above: in other words the MusicBrainz system is not *actually* an Authority control system unless these longer names are used, and currently the MusicBrainz identifiers are already considerably longer than those of other identifiers in the authority control box; I would be open to any system that defaults to "no MusicBrainz" in the {{Authority control}} template and allows local override for those who checked the corresponding MusicBrainz page as being decent enough to link from Wikipedia. --Francis Schonken (talk) 08:43, 28 April 2020 (UTC)[reply]
  • No. The template should link to a small group of reliable, high quality, relevant, non-commercial, non-wiki databases. Even without things liks musicbrainz, it has way too many useless links (for enwiki readers) already, links from national libraries which are not in English and not in a language or country relevant for the subject, but which happen to be an authority control. Links which are added by default should be very, very limited. Wikidata is the perfect location to function as linkfarm for all these, from the truly authoritative to the near-junk ones (Quora?); enwiki should restrict this to much less than we have now, and excluding things like the wiki Musicbrainz is a good start. See for example Odilon Redon, French 19th century artist, not a musician by any stretch: there are 28 links already in the authority control template there, including musicbrainz. Such linkfarms don't help our readers one bit (e.g. [2]), changing this to a select, limited group of truly useful links would be a serious improvement. Fram (talk) 08:01, 28 April 2020 (UTC)[reply]
  • No, although referred to as an open encyclopedia, Musicbrainz has lots of user generated content and I don't think it is actually a reliable source. Also we're not a link farm → Lil-℧niquԐ1 - (Talk) - 10:01, 28 April 2020 (UTC)[reply]
  • No – A lot is user-generated and therefore not a reliable source. —Ojorojo (talk) 13:41, 28 April 2020 (UTC)[reply]
  • No, per all the rationale given above.--3family6 (Talk to me | See what I have done) 14:07, 28 April 2020 (UTC)[reply]
  • No Low quality, user-generated "data" and completely circular (copies the Wikipedia article for the subject). It has no business being in an authority control any more than IMDb does, in fact less. Voceditenore (talk) 15:58, 28 April 2020 (UTC)[reply]
  • Yes. Firstly, I'm very disappointed in the amount of misinformation that has been used in this discussion and the preceding preliminary discussion, so I'll start with a point-by-point rebuttal of all the arguments presented in the previous comments.
    • Francis doesn't give any examples of low quality pages; "quality" seems to be subjective and undefined in his comment. The two most sensible ways to measure quality in this context would probably be completeness and correctness; most similar databases cannot achieve the former to begin with, and MusicBrainz does not frequently contain errors (contrary to Francis's implication). For example, if you go to the page for an artist like The Carpenters, data exists for multiple releases of all their studio albums, as well as a large number of their compilation albums, with information for each track on each release and tracks on multiple releases being deduplicated where necessary (that is, they all have unique identifiers). The data is incomplete (since it does not contain all of their singles and does not contain the information about every release or the full credits of every single recording and composition), but it isn't wrong, and the latter is a more useful measure since it would be unreasonable to expect a music database to be complete.
      • I would also note that all the examples that Francis was actually able to give at Template talk:Authority control#MusicBrainz were invalid because they were apparently dependent on misunderstandings of the user interface. In my second reply to him there I responded to those examples.
    • Why is it relevant that the BBC doesn't link to Wikipedia via MusicBrainz? It's largely a red herring because it confers no reliability either way.
    • The length of the identifiers is completely irrelevant to their reliability and I'm surprised that it was even mentioned. {{Authority control}} usually takes up less area on the page than the infobox (even with dozens of identifiers) and is much less noticeable. If someone actually wanted to complain about the format of the links they had years to do it before this RfC.
    • The identifiers are unique both with and without the prefixes, because MusicBrainz assigns 128-bit UUIDs randomly and they are expected to be unique over any vaguely reasonable timeframe (collisions are not expected until about 1015 IDs have been generated). I don't know if the software actually handles collisions, but it should be unnecessary for some millions of years. Removing the prefixes in no way makes MusicBrainz less of an authority control (although there are certainly better reasons to argue that it isn't).
    • Manual checking for MusicBrainz links is not necessary, because the site has not been demonstrated to be uniquely unreliable among the websites linked to in {{Authority control}}.
    • MusicBrainz is one of many databases in the AC template and does not by itself usually make a significant difference to the number of identifiers, unless there are no or only a few other identifiers (in which case it's obviously not clutter). If {{Authority control}} needs to be downsized then that can be achieved with a much broader RfC; removing MusicBrainz – or any other individual database – would do basically nothing to address the issue. The links to national libraries are irrelevant to this discussion. (This appears to be Fram's only argument?)
    • The fact that MusicBrainz is not a reliable source is irrelevant to its inclusion in the template, even though some AC databases can be treated as reliable secondary or tertiary sources, because the template hosts external links and not sources. The template does not have any policy- or guideline-defined inclusion criteria that do not apply to any other templates; even if the links to MusicBrainz are removed from {{Authority control}}, the MusicBrainz-specific external link templates will still exist and will continue to be used.
    • The fact that MusicBrainz quotes Wikipedia articles (automatically, through a caching system based on MusicBrainz's links to Wikidata and Wikipedia) has no bearing on whether or not it should be used in the template. It is primarily for the convenience of MusicBrainz users, and it does not affect the site in a way meaningful to its inclusion in {{Authority control}}. Jc86035 (talk) 07:09, 29 April 2020 (UTC)[reply]
  • (continued) Now that that's out of the way, this is why I would actually support the continued inclusion of MusicBrainz.
    • Firstly, there are no policies or guidelines which apply only to {{Authority control}}, which in terms of the applicable policies and guidelines can be treated primarily as an external link template. As such, since MusicBrainz external links will continue to be allowed regardless of the outcome of this RfC, there are no policy- or guideline-based reasons to disallow MusicBrainz links specifically.
    • MusicBrainz is sort of an oddball in the AC template, being the only website with user-generated content. However, this is not in and of itself a reason to remove it, because its inclusion can otherwise be justified, and the template does not have any guideline-defined inclusion criteria (other than those which were set by the previous RfC, which left the inclusion of MusicBrainz as an open question).
    • The purpose of {{Authority control}}, and AC in general, is to assign unique identifiers to entities. MusicBrainz generally accomplishes this, although this is obviously not unique to MusicBrainz. MusicBrainz identifiers, especially those for artists and works, are generally stable. In cases where there are duplicate entities, the older entity is usually the one retained. Additionally, artist identifiers are automatically removed after a week if they do not have any relationships to other entities, which means that they are always minimally identifiable; and MusicBrainz has a version control system which requires multiple users to agree for certain changes (including all destructive changes, such as merges and deletions).
    • There are several online databases which assign identifiers to musical works and associated entities, MusicBrainz being one of them. However, MusicBrainz is somewhat unique in seeking to create unique identifiers (whereas e.g. AllMusic does not clean up its duplicate track identifiers) and actually attempting to relate/link them in a structured manner. MusicBrainz is also by far the most comprehensive one to have a copyleft license, and likely as a result has many reusers of its data, the BBC being one of them. (The reason that the BBC gets mentioned in these discussions is that it directly uses MusicBrainz's identifiers and relationships as part of its content and URLs on a prominent part of its website.)
      • MusicBrainz's status of being the primary copyleft database in its field is somewhat similar to OpenStreetMap's status of being the primary copyleft map database. Although OpenStreetMap is also decidedly not a reliable source, it has nevertheless been used significantly throughout the Wikimedia projects, most notably in WikiMiniAtlas, GeoHack, and Kartographer and Kartotherian. The data of both projects has also been used by numerous third parties outside the Wikimedia projects.
    • There are several ISO identifiers for musical works: ISRC, ISMN and ISWC; these respectively correspond to MusicBrainz's recordings (one-to-one), works (not one-to-one) and works (one-to-one). (The AC template already links to an ISO identifier, ISIN.) However, using any of them in {{Authority control}} would likely be worse than using MusicBrainz, because their data is largely limited to products that were still being sold after the early 1990s, because ISRC and ISMN identifiers would rarely correspond one-to-one with Wikipedia articles, and because the primary ISWC website does not allow for direct links to identifiers. Furthermore, Wikidata's coverage of MusicBrainz is much broader than its coverage of these identifiers, so switching to another database would almost certainly result in a reduction in coverage. There are also no direct ISO analogues for the other six MusicBrainz types which the AC template currently uses.
    • While it's arguable that the AC template doesn't need any coverage of music-specific databases, it also doesn't necessarily need to link to any of the other databases that it links to. Additionally, it's often the case that MusicBrainz is the only existing identifier shown in {{Authority control}} for many pages (particularly albums) as a direct result of being the only domain-specific music database in the template.
    • In conclusion, MusicBrainz has a number of unique attributes due to its position as the primary copyleft music database, and its inclusion in {{Authority control}} can be justified due to those factors as well as the difficulty in being able to use a comparable amount of data from other music databases of comparable quality in the template. Jc86035 (talk) 07:59, 29 April 2020 (UTC)[reply]
  • Yes. Per Jc86035 - Premeditated (talk) 15:49, 29 April 2020 (UTC)[reply]
  • Yes - Jc86035 makes a lot of sense here. Thanks. Mike Peel (talk) 18:26, 29 April 2020 (UTC)[reply]
  • No per Fram and Voceditenore. Nikkimaria (talk) 02:28, 1 May 2020 (UTC)[reply]
  • Yes - per Jc86035. ‐‐1997kB (talk) 02:37, 2 May 2020 (UTC)[reply]
  • No - in the ones I’ve seen, the link to MB has not generally offered worthwhile content. Sergecross73 msg me 03:34, 5 May 2020 (UTC)[reply]

Discussion

global.css doesn't seem to be working here?

Resolved

Hi there! I have a global.css file. It does change how things look on meta and commons for example but not on en.wiki or fi.wiki. Neither of those non-compliant wikis has a common.css either. (The fi one used to however for what it's worth.) I wonder what the problem is. --Palosirkka (talk) 09:09, 28 April 2020 (UTC)[reply]

Works for me, on both enwiki and fiwiki. What browser do you have? Did you try to do purge if it's some problem with cache? Stryn (talk) 15:20, 28 April 2020 (UTC)[reply]
Interesting. I'm using Firefox ESR. I tried purging a page I then edited and no change. Did you mean that or some other page? Palosirkka (talk) 10:17, 29 April 2020 (UTC)[reply]
I figured it out, it was my own settings. Works fine now. Sorry for the noise. Striking out my question. Thanks for trying to help me User:Stryn! Palosirkka (talk) 11:23, 29 April 2020 (UTC)[reply]

Issues with watchlist

Greetings,

I am experiencing two separate and rather frustrating issues with my watchlist. I asked on the HD a few days ago and was directed here.

1) Any page I edit is automatically added to my watchlist despite the fact that "Add pages and files I edit to my watchlist" is unchecked in preferences.

2) Any page in my watchlist is subsequently removed from my watchlist permanently, the next time I edit the page.

Are these two problems related? How can I fix this? Thanks, Hillelfrei• talk • 15:07, 28 April 2020 (UTC)[reply]

Issue 1 was resolved by changing TW preferences. Still looking for an answer to Issue 2. Thanks, Hillelfrei• talk • 04:44, 30 April 2020 (UTC)[reply]

DisamAssist tool not being installed

I have added the DisamAssist tool code to my common.js page, then refreshed browser, yet the DisamAssit tool is not installed. Please help me to solve the issue. ImSonyR9 (talk · contribs) —Preceding undated comment added 17:07, 28 April 2020 (UTC)[reply]

@ImSonyR9: Remove that and try pasting {{subst:lusc|User:Qwertyytrewqqwerty/DisamAssist.js}} this. I also recommend using Twinkle via the Gadgets interface rather than loading it via the userscript (it's basically the same but whatever). --qedk (t 愛 c) 14:35, 29 April 2020 (UTC)[reply]

redirect mystery

When I click the link Jacob Brett, I get the article titled John Watkins Brett, about a telegraph engineer. There is -not- a redirection hatnote thingie at the top of the article. Any idea what is going on? Jacob seems to be the younger brother of John, per [3], fwiw. But I'm used to redirects being labelled as such. Thanks. 2602:24A:DE47:B270:DDD2:63E0:FE3B:596C (talk) 00:39, 29 April 2020 (UTC)[reply]

Followup: leaving this up in case other people experience it, but the phenomenon seems to have gone away for me: I get the redirect link now.
Resolved
2602:24A:DE47:B270:DDD2:63E0:FE3B:596C (talk) 00:44, 29 April 2020 (UTC)[reply]
When I click the link of a redirect - such as Jacob Brett - it follows the redir and shows the message
(Redirected from Jacob Brett)
If I follow any link and then return using the browser's "back" facility, that message is no longer shown when I have returned. It also disappears if I simply refresh the page (F5 in my browser) - perhaps you did that by accident. --Redrose64 🌹 (talk) 19:56, 29 April 2020 (UTC)[reply]

Unexpectedly rotated image

Please take a look at https://en.wikipedia.org/enwiki/w/index.php?title=Mary_Boquitas&oldid=930978789 You will see that the image is unexpectedly rotated sideways. It is not rotated that way on Wikimedia Commons, it was not that way when I added it to the article a few years ago. I even downloaded the image, re-uploaded it with a "2" after the name, no other changes, and it is not rotated. When you display them at 100px, neither is rotated. You can compare them on User:GRuban/Mary Boquitas. I temporarily replaced the image with the non-rotated copy in the article, but what is going on here, and more importantly what is the best way to fix it? --GRuban (talk) 11:24, 29 April 2020 (UTC)[reply]

I purged the file page on Commons and the problem went away (you may have to clear your browser cache—e.g. by Ctrl+F5—to see the effect). I don't know how it happened in the first place though. Nardog (talk) 11:30, 29 April 2020 (UTC)[reply]
Thanks! I captured the rotated version in the Internet Archive for posterity. https://web.archive.org/web/20200429114127/https://en.wikipedia.org/wiki/Mary_Boquitas --GRuban (talk) 11:45, 29 April 2020 (UTC)[reply]
GRuban, interestingly, even your archived shot has it displaying correctly for me. This is not the first time I've seen something like this, however. As an example, note the history of File:Jay-Z @ Shawn 'Jay-Z' Carter Foundation Carnival (crop 2).jpg; all of the versions display correctly for me even though the current one apparently replaced a wrongly rotated/distorted one. Home Lander (talk) 17:57, 29 April 2020 (UTC)[reply]
Yup, even the archive is correctly rotated for me too now. Which is worrisome. But the immediate problem is solved. --GRuban (talk) 19:50, 29 April 2020 (UTC)[reply]
It's all because of client-side caching. Your browser is lazy, so it tries as hard as possible to not actually have to download new content when you load a page.
If there's something's strange, on the interwebz? Who you gonna call? Cache busters! --AntiCompositeNumber (talk) 04:49, 30 April 2020 (UTC)[reply]
It's not "all because of client-side caching". If so the server-side purge would have had no effect. Nardog (talk) 18:10, 30 April 2020 (UTC)[reply]

Reminder: Technical maintenance planed‬

This is a reminder of the message sent on Monday 27th April.

A maintenance operation will be performed on Thursday 30th April at 05:00 AM UTC.

It impacts all wikis and is supposed to last a few minutes.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Please help making your community aware of this maintenance operation.

Thank you, Trizek (WMF) 15:05, 29 April 2020 (UTC)[reply]

What sort of plane are you using? -Roxy, the PROD. . wooF 15:20, 29 April 2020 (UTC)[reply]
I like the Jack plane - it looks like it means business, but if you treat it well, it'll serve you well. --Redrose64 🌹 (talk) 19:59, 29 April 2020 (UTC)[reply]

Color in Microsoft Edge

An example of the issue from here on Microsoft Edge 44.19613.1000.0

In Microsoft Edge (the original version, not the Chromium version), I noticed that text at the bottom of history, user contributions, or watchlist pages sometimes shows in black instead of the correct color, and hovering over a link in black will make it turn blue. Can this issue be fixed in MediaWiki? GeoffreyT2000 (talk) 01:54, 30 April 2020 (UTC)[reply]

Looks blue to me (I am using MS Edge Chromium as well). I do not know what you are talking about. Can you give more details? Like skin? Aasim 05:22, 30 April 2020 (UTC)[reply]
In the Vector skin, that is. Also, I am using the non-Chromium version of Edge. For anyone who is using non-Chromium Edge with the Vector skin, just look at the bottom of this page's latest 500 edits, and the timestamp; user page, user talk page, and user contributions links; and red and green size difference numbers in parentheses will appear black instead. I also tested Cologne Blue, Modern, Monobook, and Timeless, and found out that the issue does not occur in those skins. GeoffreyT2000 (talk) 18:36, 30 April 2020 (UTC)[reply]
GeoffreyT2000, happens for me too. I also attached a screenshot.– BrandonXLF (talk) 01:33, 1 May 2020 (UTC)[reply]

Archive.org

I'm not sure whether this belongs here since it's not a Wikipedia technical issue, but anyway... has anyone had issues using the Internet Archive specifically to archive tweets lately? I tried earlier today [4] for a tweet which is still live, and for some reason the archived copy says the tweet does not exist. Is there a gratis alternative? 209.166.108.199 (talk) 04:39, 30 April 2020 (UTC)[reply]

This is because of the new Twitter interface, which prevents the Wayback Machine from displaying pages correctly because the Wayback Machine doesn't handle JavaScript well. The easiest alternatives are to change your user agent and use the old Save Page Now so that it gets saved using one of the old interfaces, or to use archive.today. (For example, if you use a Firefox or Chrome add-on to change your user agent to that of Internet Explorer 11, or use curl or wget, viewing https://web.archive.org/save/https://twitter.com/HowieCarrShow will save the page using the previous Twitter interface.) Jc86035 (talk) 04:51, 30 April 2020 (UTC)[reply]

Technical maintenance but no server switch

I was alerted just today that there will be a technical maintenance that will affect all wikis (if my understanding of [5] is correct). The banner appeared only today, not since Monday, when it was supposedly announced. Unlike past occurences, there is no server switch like what happened at least thrice before. How is today's non-editing time going to be different from those server switches? Was this made necessary by the 502 and 504 errors that happened earlier this month? LSGH (talk) (contributions) 04:55, 30 April 2020 (UTC)[reply]

From the editors' perspective, the only difference is that it was much faster (just 81 seconds of read-only time). From the tech folks' perspective, I gather that it had something to do with a Certificate authority that was going to expire in June. Whatamidoing (WMF) (talk) 19:59, 30 April 2020 (UTC)[reply]
Thanks a lot. That was quite necessary to avoid any future complication. LSGH (talk) (contributions) 14:16, 3 May 2020 (UTC)[reply]

Combining RandomInCategory with PAGENAME

I'd like to create a link to a random level 4 vital article. However, it's not as simple as using Special:Randomincategory, since Category:All Wikipedia level-4 vital articles goes to the talk page, not the article itself, and I can't get Special:Randomincategory to play nice with {{PAGENAME}}. Help? {{u|Sdkb}} talk 00:36, 20 April 2020 (UTC)[reply]

Unfortunately you can't do that with just core mediawiki, but you could do it with a user script or an external tool. --AntiCompositeNumber (talk) 01:00, 20 April 2020 (UTC)[reply]
@AntiCompositeNumber: In that case, would there be an easy way to set up a category that duplicates Category:All Wikipedia level-4 vital articles but goes to the page itself instead? This is for this conversation, so using an individualized or off-wiki method isn't really an option that I can see. {{u|Sdkb}} talk 05:47, 21 April 2020 (UTC)[reply]
Bumping thread. {{u|Sdkb}} talk 09:59, 30 April 2020 (UTC)[reply]
Short answer: Yes. Long answer: Yes, but just because it's possible doesn't mean it's a good idea. A bot would have to maintain the category, or it would quickly fall out of date. A default gadget or &withJS link would be a better long-term solution than a bot. The best solution of course is to add the desired functionality to MediaWiki: for that, phab is thataway. --AntiCompositeNumber (talk) 20:39, 30 April 2020 (UTC)[reply]
@AntiCompositeNumber: I'm not sure I fully follow. What are you suggesting the phab ticket be? {{u|Sdkb}} talk 05:27, 2 May 2020 (UTC)[reply]

Category:Harv and Sfn multiple-target errors

Is there a way to tell which citations generate this category? The question is about paleotempestology. Jo-Jo Eumerus (talk) 11:04, 30 April 2020 (UTC)[reply]

@Jo-Jo Eumerus: See Category:Harv and Sfn template errors#Displaying error messages. 3rd method will work. Looks like it's from May et al. 2017. Headbomb {t · c · p · b} 11:18, 30 April 2020 (UTC)[reply]
If you follow Paleotempestology#CITEREFMayBrillLeopoldCallow2017, it takes you to the relevant two references. One should have 2017a, the other 2017b and then the short footnote updated to reflect which is meant. Headbomb {t · c · p · b} 11:20, 30 April 2020 (UTC)[reply]
Thanks. Found a different solution for the problem there. Jo-Jo Eumerus (talk) 11:27, 30 April 2020 (UTC)[reply]
This here is the proper way to fix things. Headbomb {t · c · p · b} 11:33, 30 April 2020 (UTC)[reply]
@Headbomb: ...except that that is not consistent with the rest of the article using ref tags for sources where only one page is employed. Jo-Jo Eumerus (talk) 11:49, 30 April 2020 (UTC)[reply]
From what I see, every citation is made through a shortened footnote save one and those to Google maps. This lone citation has likely been added against the existing style via the WP:RefToolbar or similar. Headbomb {t · c · p · b} 12:27, 30 April 2020 (UTC)[reply]
No, that was a deliberate decision when I expanded the article. The pre-expansion text had ref tags and didn't know anything about page numbers, so I decided to adopt a hybrid sfn+ref citation system. Jo-Jo Eumerus (talk) 12:53, 30 April 2020 (UTC)[reply]

XTools

Resolved

Whenever I try to use XTools it says "504 Gateway Time-out". Is it just me? ~~ CAPTAIN MEDUSAtalk 12:42, 30 April 2020 (UTC)[reply]

@CAPTAIN MEDUSA:  Works for me Recheck. --qedk (t 愛 c) 14:06, 30 April 2020 (UTC)[reply]
QEDK, It works now. It was down for a while. ~~ CAPTAIN MEDUSAtalk 14:10, 30 April 2020 (UTC)[reply]
I don't know about the 504 (I didn't get any such automated reports), but queries are running really slow right now which appears to be a side-effect of phab:T249188. — MusikAnimal talk 21:21, 30 April 2020 (UTC)[reply]
MusikAnimal, I get this now. ~~ CAPTAIN MEDUSAtalk 13:26, 1 May 2020 (UTC)[reply]
This time there was an automated report. Nothing immediately stands out as to what happened, but I'm investigating! There's a task at phab:T251595. I'll follow up there. — MusikAnimal talk 17:04, 1 May 2020 (UTC)[reply]

Thursday font change

Arrgh, WP:ITSTHURSDAY and in the last two minutes the font of diffs has changed to monospace, which is smaller and harder to read, causing an accessibility issue. The line height has increased, causing larger gaps between lines --Redrose64 🌹 (talk) 13:07, 30 April 2020 (UTC)[reply]

It actually now depends on "Edit area font style" in Preferences -> Editing. The Phabricator task is phab:T250393. – Majavah (t/c) 13:15, 30 April 2020 (UTC)[reply]
Right, Cop hold of this: 
.diff-editfont-monospace .diff-addedline,
.diff-editfont-monospace .diff-deletedline,
.diff-editfont-monospace .diff-context {
  font-family: sans-serif;
}
I put this in m:Special:MyPage/global.css but it can go in Special:MyPage/common.css or Special:MyPage/skin.css if you prefer. --Redrose64 🌹 (talk) 13:30, 30 April 2020 (UTC)[reply]
@Redrose64: Thank you so much for this! Double sharp (talk) 02:43, 1 May 2020 (UTC)[reply]
@Redrose64: thank you. That worked for me too. SarahSV (talk) 01:36, 5 May 2020 (UTC)[reply]
Hold on. I'm sure that Special:MyPage/skin.css should redirect me to Special:MyPage/monobook.css or Special:MyPage/vector.css as applicable, but it doesn't. When did that change? --Redrose64 🌹 (talk) 13:33, 30 April 2020 (UTC)[reply]
@Redrose64: that is a local hack, and seems to be broken - see MediaWiki_talk:Common.js#Redirect_skin.js_hack_broken_-_remove?. — xaosflux Talk 13:50, 30 April 2020 (UTC)[reply]

I have always used a monospaced font for both the editing area and diffs. But in the last few days I've noticed a font change in the diff area to something that's still monospaced but lighter and harder to read, almost like what Latin characters in an Asian font look like. The editing area is unchanged. Has anyone experienced the same? -- King of ♥ ♦ ♣ ♠ 13:55, 30 April 2020 (UTC) Huh, I just realized that my memory is totally disfunctional, and diffs have always been in a sans-serif font. Must be the Mandela effect... -- King of ♥ ♦ ♣ ♠ 18:06, 30 April 2020 (UTC)[reply]

Yes, edit window is unchanged but the diff typeface has definitely changed. - X201 (talk) 14:24, 30 April 2020 (UTC)[reply]
THE NEW FONT IST TERRIBLE --Killarnee (T•1•2) 15:05, 30 April 2020 (UTC)[reply]
Hideous. I fixed the diffs page ugliness per the directions above "Edit area font style" in Preferences -> Editing, but my edit window font is now tiny, much smaller than what I see on a page when I'm not editing it. Cyphoidbomb (talk) 15:07, 30 April 2020 (UTC)[reply]
meta:User:Killarnee/global.css Fixed.
And font size:
.diff-editfont-monospace .diff-addedline,
.diff-editfont-monospace .diff-deletedline,
.diff-editfont-monospace .diff-context {
  font-size: 90%;
}
--Killarnee (T•1•2) 15:17, 30 April 2020 (UTC)[reply]
Appreciated, Killarnee, but not fixed. My edit window font is still tiny. I can't even count how many indents to use unless I get up close. Cyphoidbomb (talk) 15:26, 30 April 2020 (UTC)[reply]
I even scaled it to 300%. User:Cyphoidbomb/global.css. Maybe it's something I'm doing wrong. Cyphoidbomb (talk) 15:29, 30 April 2020 (UTC)[reply]
You have to create the global css and js pages on meta (meta:User:Cyphoidbomb/global.css, like the global user page) --Killarnee (T•1•2) 15:31, 30 April 2020 (UTC)[reply]
This is absolutely not going to be intuitive for anybody else. I don't know nothin' about css. Also, now that i'm thinking about it, I sort of feel like my edit window displayed mono-spaced fonts. Isn't that the only way to get infobox parameters to align vertically on the equals = signs? Cyphoidbomb (talk) 15:38, 30 April 2020 (UTC)[reply]
Just created the meta page. Nothing happened. Cyphoidbomb (talk) 15:43, 30 April 2020 (UTC)[reply]
It works for me 😂 (300%)
Maybe this will help you: https://www.w3schools.com/css/default.asp --Killarnee (T•1•2) 15:53, 30 April 2020 (UTC)[reply]

Can somebody please, with some urgency, provide info on how to change it back? Thanks. -Roxy, the PROD. . wooF 16:42, 30 April 2020 (UTC)[reply]

+1. Call up the egg-heads working on a cure for COVID19 and tell them they have a new priority! Lugnuts Fire Walk with Me 16:48, 30 April 2020 (UTC)[reply]
Really, this is ugliness. I want my diffs readable again. --jpgordon𝄢𝄆 𝄐𝄇 16:55, 30 April 2020 (UTC)[reply]
I just read WP:ITSTHURSDAY and found a useful quote viz .. "so while you can provide a report, there is no guarantee it will be fixed the way you expect, if it needs fixing at all." Oh god. -Roxy, the PROD. . wooF 17:02, 30 April 2020 (UTC)[reply]
Noting here that the software update was reverted today due to an unrelated issue. – Majavah (t/c) 17:57, 30 April 2020 (UTC)[reply]
That's fixed it. Thanks! Lugnuts Fire Walk with Me 18:02, 30 April 2020 (UTC)[reply]
Amen. Cyphoidbomb (talk) 18:45, 30 April 2020 (UTC)[reply]
At the risk of breaking some hearts, the font change is expected to return as soon as the unrelated bug gets fixed.
I have two thoughts from the above conversation: First, if you remember the mw:Typography refresh from years ago, one of the things to remember is that we hate having our fonts changed ...for a week or two. After that, we pretty much get used to it, and it's okay. So you might want to wait a few days, and see whether the benefits (e.g., making it easier to see narrow punctuation) outweigh the costs. Second, I hate font changes at least as much as the average person, but I think the size is a bigger problem for me than the font itself. So it's possible that a few tweaks to the size and leading would give me (and perhaps some of you, too) the best of both worlds. Whatamidoing (WMF) (talk) 21:39, 30 April 2020 (UTC)[reply]
I, at least, still strongly dislike all of the changes that that refresh included, although I have resentfully accepted them. I seriously hope someone will engineer and provide a CSS way to cancel or reverse this diff change. —⁠烏⁠Γ (kaw) │ 22:36, 30 April 2020 (UTC)[reply]
I already did, at 13:30, 30 April 2020 (UTC) --Redrose64 🌹 (talk) 23:07, 30 April 2020 (UTC)[reply]
I can't follow that, unfortunately; I would need simple instructions. —⁠烏⁠Γ (kaw) │ 01:12, 01 May 2020 (UTC)[reply]
OK, here's "simple instructions". Create User:KarasuGamma/common.css with the content 
.diff-editfont-monospace .diff-addedline,
.diff-editfont-monospace .diff-deletedline,
.diff-editfont-monospace .diff-context {
  font-family: sans-serif;
}
* Pppery * it has begun... 03:04, 1 May 2020 (UTC)[reply]
Thank you. Hopefully this will work once that change is unfortunately finalized. —⁠烏⁠Γ (kaw) │ 07:34, 01 May 2020 (UTC)[reply]
I also wonder how many people stopped complaining because they switched back to Monobook. ;) Double sharp (talk) 02:40, 1 May 2020 (UTC)[reply]
I wonder how many people gave up because they couldn't follow "simple instructions." Sheesh. -Roxy, the PROD. . wooF 07:40, 1 May 2020 (UTC)[reply]
Indeed! No doubt Whatamidoing (WMF) can point to where this proposed change was approved by the/a community. Johnbod (talk) 21:48, 1 May 2020 (UTC)[reply]
@Johnbod: You may want to point out what makes you think that such changes would need some approval by the/a community. That would be news to me (and would not scale). Also see mw:Bug management/Development prioritization. (Note that I was not involved in making this change but am personally curious about understanding what such expectations are based on.) --AKlapper (WMF) (talk) 10:15, 4 May 2020 (UTC)[reply]
  • Other people will be better able to answer the previous point than me. Meanwhile the font change is back, but at a larger size, possibly even in response to the outcry among users. But it is still in the same unhelpful font, and will remain disliked. People might like to comment on whether this is more important than whatever the supposed problem the change fixed was. Johnbod (talk) 16:38, 4 May 2020 (UTC)[reply]
    • AKlapper (WMF), you asked Johnbod "what makes you think that such changes would need some approval by the/a community". This is the community's workplace. You wouldn't think much of an organization that suddenly moved its workers' desks around, or turned up during the night and messed up all their paperwork, or made the filing cabinets harder to open. Then asked in the morning "what makes you think such changes need your approval?"
      The point is we have to do a lot of diff reading, including long and complex ones, and we need to be able to do it quickly, often at a glance. This change makes that harder. SarahSV (talk) 18:30, 4 May 2020 (UTC)[reply]
    • AKlapper (WMF), I second SlimVirgin's point. This change makes it very much harder for editors to edit. It especially makes it harder for us to spot subtle vandalism. I wouldn't go to your workplace and change all the settings on your workstation and then tell you off for complaining about it, could the Foundation try to have the same respect for us? DuncanHill (talk) 18:45, 4 May 2020 (UTC)[reply]

Monday, redux

  • Blargh, it's back, and bigger than before, and on a Monday no less. Here's a modified version of the Special:MyPage/vector.css change shown above. I don't know if I have the font-size exactly right; I just played with it until I looked reasonable to me. If someone knows where to dig in the site-wide CSS to get the font-size setting exactly right, feel free to change this code to reduce confusion:
.diff-editfont-monospace .diff-addedline,
.diff-editfont-monospace .diff-deletedline,
.diff-editfont-monospace .diff-context {
  font-family: sans-serif;
  font-size: 88%;
}
Now back to actually improving Wikipedia. – Jonesey95 (talk) 16:45, 4 May 2020 (UTC)[reply]
I copied this into my vector.css and it didn't do anything, even after doing the instructions. I don't know but I might have to wait. I'm not perfect but I'm almost (talk) 17:01, 4 May 2020 (UTC)[reply]
It didn't work at first because I had my preferences to sans serif font in editing. But now it works. And stop fixing what's broke! I'm not perfect but I'm almost (talk) 17:06, 4 May 2020 (UTC)[reply]
Thanks a bunch. The new diff font is absolutely hideous, this code seems to make it look right. ♫ Melodia Chaconne ♫ (talk) 04:56, 5 May 2020 (UTC)[reply]
Yep, back again! Please can someone fix this? Thanks in advance. Lugnuts Fire Walk with Me 17:13, 4 May 2020 (UTC)[reply]
Could someone say how to fix this, please? It's harder to read diffs. SarahSV (talk) 17:56, 4 May 2020 (UTC)[reply]
@Lugnuts and SlimVirgin: Copy the code above into Special:MyPage/common.css (or m:Special:MyPage/global.css, for all projects) to change the font back. --Yair rand (talk) 18:03, 4 May 2020 (UTC)[reply]
Thanks, but I tried that and it still leaves a bit of a gap in the previews, etc. Lugnuts Fire Walk with Me 18:04, 4 May 2020 (UTC)[reply]
  • I spoke quite in length about why there should be an option before this change was implemented. Unfortunately, the change was still made without an option, I don't know what we can do about that anymore than just telling the developers we want an option at the Phabricator task: https://phabricator.wikimedia.org/T250393 Don't fix what ain't broke comes to mind here. :/ --qedk (t 愛 c) 18:39, 4 May 2020 (UTC)[reply]
    Thank God! Finally! This is a wonderful change! Thanks to the devs who implemented this after many horrible years of proportional fonts in diffs. This will make it so much easier to see things now. I can't tell you how overjoyed I am. Elizium23 (talk) 20:03, 4 May 2020 (UTC)[reply]

Primitive font in diff views

Suddenly, the article text in diff views is in a primitive-looking font, a bit like a 60's attempt to look futuristic. It's horrible. It's also got the letters f a r t o o f a r apart from each other. How do I get rid of it? Thanks, DuncanHill (talk) 18:34, 4 May 2020 (UTC)[reply]

See #Thursday font change above. --Masem (t) 18:35, 4 May 2020 (UTC)[reply]

Non-uniform distribution of namespaces in “pagelinks.sql” dump

I'm analyzing some Wikipedia data using the provided SQL dumps. Doing so, I noticed that in the “pagelinks” dump, all links in the 0 → 0 (main to main) namespace reside in the (roughly) first half of the dump, and none in the latter half (that's almost 30GB of text). I get the overall expected numbers of positive matches, so my counting method seems correct.

If someone more familiar with the database structure of Wikipedia/MediaWiki has an idea why this might be, I'd love to gain some insight. Does the pagelinks SQL dump get grouped/partitioned by namespace? — Preceding unsigned comment added by MSUGRA (talk • contribs) 15:42, 30 April 2020 (UTC)[reply]

Tooltip problem

The tooltip for reference [a] in Clearing_the_neighbourhood#Margot's_Π is too narrow to accomodate the equations. 89.172.8.118 (talk) 19:30, 30 April 2020 (UTC)[reply]

I have reported this problem at mw:Talk:Reference_Tooltips. That very long note may be better reformatted as a regular article section or a collapsible section (even though MOS says not to use collapsible text in general). – Jonesey95 (talk) 20:54, 30 April 2020 (UTC)[reply]
Thanks, I'm not sure where to report bugs around here :) 89.172.8.118 (talk) 21:26, 30 April 2020 (UTC)[reply]

Yellow and green open access icon

What is the difference between yellow and green open access icons of locks in references? I just saw a link to arXiv with a green lock icon that redirects to arXiv and shows "freely accessible" in tooltip. I remember yesterday seeing a yellow lock icon somewhere else that linked to the wikipage Open access. What do the different colors mean? 89.172.8.118 (talk) 21:25, 30 April 2020 (UTC)[reply]

If you mean the green lock in Recher, C.; et al. (2010). "Supersymmetry Approach to Wishart Correlation Matrices: Exact Results". arXiv:1012.1234. vs the yellow/orange lock in Open access icon, they mean the exact same thing. {{open access}} was never updated to the green lock, but probably should be. Headbomb {t · c · p · b} 21:33, 30 April 2020 (UTC)[reply]
Thanks for clearing that up. In the end I didn't click on that yellow link because I presumed it meant something like free for academics like ResearchGate or free to browse bits and parts on a crappy webpage like Google Books. It is counterintuitive. 89.172.8.118 (talk) 00:59, 1 May 2020 (UTC)[reply]

How to make two-column lists align but not make a table

For example: List of chancellors of the Queen's University, Belfast#Queen's University Belfast It appears that the names all share the same alignment except the last entry (because of the missing digits of the end year). How do we move Hillary Clinton over to make it the same as the others? Putting spaces in doesn't line it up exactly, and I don't think making a table is the preferred method, is it? Senator2029 “Talk” 01:24, 1 May 2020 (UTC)[reply]

A table would work fine actually. I tried ch and that seems to line it up in my browser/skin/zoom combination. Besides those, I just wouldn't care to be honest and not have any styling. It looks fine without being lined up on the colon. --Izno (talk) 01:33, 1 May 2020 (UTC)[reply]
For what it's worth, {{0}} is a lot better (and "easier to understand") than using a <span> across the entire thing. I updated the list, and it's essentially adding four invisible 0s. Primefac (talk) 02:52, 2 May 2020 (UTC)[reply]

Help regarding IA Bot

Hello everyone!

Can someone help me with a very problematic behavior regarding IA Bot? We use IA Bot on SqWiki (I'm an admin there) and it works fine but at some pages it keeps going on and on, archiving and unarchiving or doing some strange loop-kind of behaviors. At first I hoped it would sort itself out, then I hoped that maybe our links were problematic and someone interested in those articles would fix them in the near future. When none of this happened, I did write to Cyberpower678 countless of times but he appears to be too busy and many of my requests have been automatically archived without any solution to the problem.

These are some of the articles with problems:

Please, check the talk pages of those articles and you'll immediately understand what I'm talking about but you can check the article's history too for more information. (We have talk page messages set on and that's good because the problem is not with the messages themselves.)

Actually Cyber appeared to be very responsive at first and he helped me set up the bot for SqWiki. Since we have talk page messages set on, I kept monitoring the bot's activity closely for bugs or mistranslations and that's when I found out of this kind of behavior. As I said, I did write to him many times for help regarding this problem (and even some bugs related to its messages) but as he stated himself, he was very busy these months so those things just kept persisting. Since then, other articles have started to have the same problems as the ones above. Not knowing exactly what causes that kind of behavior (and therefore how to stop it), I've unfortunately stopped monitoring IA Bot's contributions for some months now. I returned now after some weeks to check the first article at the aforementioned list and it was a disaster. The bot is going crazy in there.

We've come to see the bot's work as very beneficial to our citations so we wouldn't want to set it off or exclude certain pages from its list of work (although I'm afraid we might be forced to consider those options too). Is there someone who can help me deal with problems regarding it other than the mentioned operators at the bots page? From past experience I know that some aspects of l18n regarding its use at our project have not been fully accomplished, and the initial deal was to fix and optimize those on the way as we discovered them (hence a continuous support would be the best option) but at this point, maybe just helping to fix behaviors like those mentioned above would be enough.

Normally I would have written at its operators but given the circumstances (to my knowledge, Kaldari doesn't deal much with it anymore and I've already written countless of times to Cyber already) I wrote here as a last resort. - Klein Muçi (talk) 03:27, 1 May 2020 (UTC)[reply]

Klein Muçi, entirely my fault for the lack of response. I have indeed been busy. Let me take a look at this problem. I will report back tomorrow. Please ping me if I forget. —CYBERPOWER (Around) 01:23, 2 May 2020 (UTC)[reply]
@Cyberpower678: I'm really sorry I had to write here but literally I didn't know what else to do except for stopping the bot altogether. I fully understand your lack of time since you do get requests from many projects in different languages. I was indeed hoping to find someone else to deal with it so I wouldn't put too much pressure on you (since you've told me yourself you needed help regarding the bot) and that's why I wrote here but... - Klein Muçi (talk) 01:46, 2 May 2020 (UTC)[reply]
@Cyberpower678: Friendly reminder. :) - Klein Muçi (talk) 17:25, 3 May 2020 (UTC)[reply]
Klein Muçi, I'm still here, but will have to push this to tomorrow. I'm in college which eats at my time as well, and I'm involved with finals right now. —CYBERPOWER (Chat) 00:10, 4 May 2020 (UTC)[reply]

Harv warning with no harv

Some time in the last little while, two or three weeks perhaps, I notice that many pages now have harv warnings on them. This is a bit annoying because there is no citeref on the text.

For instance, go to Newmarket Canal and scroll to the bottom. On my machine, I get "Harv warning: There is no link pointing to this citation. The anchor is named CITEREFDodge2009." As you can see by pressing Edit, there is no CITEREF on this entry, and there shouldn't be.

I suspect the problem is in the tool that is reporting these errors, not the page? If so, I no longer recall how to find what tool this is. Maury Markowitz (talk) 14:42, 1 May 2020 (UTC)[reply]

(EC) @Maury Markowitz: you'll want to update your scripts from User:Ucucha/HarvErrors.js to one one of those detailed at the top of User:Ucucha/HarvErrors. User:Svick/HarvErrors.js will suppress all such yellow warnings. User:Trappist the monk/HarvErrors.js will suppress all such warnings from articles that don't make use of shortened footnotes, and will also suppress them from Further reading and External link sections. Or you can add |ref=none to that citation like so, and it will suppress the CITEREF anchor generated by the template. Headbomb {t · c · p · b} 14:50, 1 May 2020 (UTC)[reply]

Worked like a champ! Maury Markowitz (talk) 15:12, 1 May 2020 (UTC)[reply]

visual edit dropdown disappears

i've noticed (on article pages) the dropdown option to switch between visual and source editing disappears.it will apparently randomly appear and disappear even for the same page. I use firefox 75 64bit. I tried using opera and for the same page firefox won't have the dropdown while opera will. so i think it's a firefox issue. (I've cleared cache, cookies, etc).ToeFungii (talk) 20:28, 1 May 2020 (UTC)[reply]

@ToeFungii: I've not managed to reproduce that using Firefox 75.0 (64-bit) myself. Did the black pencil icon disappear during one single editing session, or between different sessions? What actions were you performing just before you noticed the dropdown editing option had disappeared, and can you recollect what action you were doing before it returned again. Was it on just one article, or many? Have you checked your Editing Settings in Preferences, and have you got 'editing mode' set to 'show me both editor tabs'? Knowing these things might assist someone to offer suggestions Nick Moyes (talk) 21:56, 1 May 2020 (UTC)[reply]
@Nick Moyes:
  • The pencil seems to disappear randomly and in multiple editing sessions. It disappears, or should say doensn't appear, upon clicking "edit source." If I publish while in visual mode, visual mode always seems to open the next time I edit.
  • In preferences I don't see in 'editing mode' the text you're talking about. There is 'Temporarily disable the visual editor while it is in beta' which is unchecked.
  • In 'Beta' the following are unchecked: 'New wikitext mode', 'Visual differences', 'Two column edit conflict'.
  • I've yet been able to replicate in Opera. So I think it may be just a firefox issue.
  • I've only been editing with an account for a month. I don't remember seeing it as an issue before a couple weeks ago, but I honestly can't swear to that as it was all so new.
ToeFungii (talk) 01:47, 2 May 2020 (UTC)[reply]
ToeFungii, does this problem resolve when you edit in mw:safemode? Whatamidoing (WMF) (talk) 15:56, 4 May 2020 (UTC)[reply]
I'll test it and let you know. ToeFungii (talk) 17:07, 4 May 2020 (UTC)[reply]
I'd say based on a quick check that makes the problem go away.(I didn't notice before that it's the tool bar at the top of the edit frame that is actually disappearing). Based on reading the safemode that I have to find what's causing the problem. Can I get a little help with that? Is it something in my browser or some setting on wp? thanks. ToeFungii (talk) 17:26, 4 May 2020 (UTC)[reply]
ToeFungii, that's useful news, since it tells us where the problem is. It's almost certainly not something in your web browser (unless you have tons of extensions installed). It's probably caused by a user script. If you scroll down on the mw:safemode page, there's a basic list of the steps for figuring out which script is causing it. You don't seem to have installed any scripts manually, so it's probably a user-script gadget that you turned on in Special:Preferences. Maybe make a few screenshots of your prefs settings, reset everything to defaults, and see if that helps? If it does, then you can use the screenshots to figure out what you wanted to turn on/off again. Whatamidoing (WMF) (talk) 17:52, 4 May 2020 (UTC)[reply]
I tried turning off everything in gadgets and still had issue. Could it be something in Beta? I've reset all to default and I'll add slowly to see if I can id what caused the break. ToeFungii (talk) 18:06, 4 May 2020 (UTC)[reply]
Don't know if you keep a log, but if you do go ahead and close this. I've re-turned on a # of things and don't have it back to the look it had (I should have capture all the pref pages:() but the vis edit isn't broke and I actually now see some icons that I don't ever remember seeing before. The one thing that's really annoying is the preview of a wp link i see now as it is really odd, but over time i'll figure out what broke it and post it. Who knows, maybe i'll never break it again. ToeFungii (talk) 19:01, 4 May 2020 (UTC)[reply]
Whatamidoing (WMF), Found what is causing the break. pref-gadgets "wikEd: alternative full-featured integrated text editor for Firefox, Safari, and Google Chrome (documentation)". When I turn this on it breaks showing the vis/source edit.

Without it though, it messes up at least when I tried to post a question in the TeaHouse. ToeFungii (talk) 20:50, 4 May 2020 (UTC)[reply]

Notification icons blurry rendering

Tracked in Phabricator
Task T251659

I don't know how the community feels about pixel peeping in UI elements, but here's a very minor nitpick about rendering of some of the notification icons (Commons category). They are originally 20x20 pixels SVG files. In the notifications UI they are rendered in size 30x30 pixels. Positions of some vertical and horizontal edges in these icons relate to the size 30x30 in such a way, that some edges are blurred. The size 30x30 pixels is set through the following CSS rule, which is independent of the skin (

): 

.mw-echo-ui-notificationItemWidget-icon img {
 height:30px;
 width:30px
}

Demo:

  • Green tickY OK
  • Slightly blurry edges, ordered roughly from most to least noticeable
  • Edges of the rounded rectangle
    Edges of the rounded rectangle
  • Top and bottom edges
    Top and bottom edges
  • Bottom left corner
    Bottom left corner
  • Bottom left corner
    Bottom left corner
  • Bottom edge
    Bottom edge
  • All horizontal edges
    All horizontal edges
  • Edge between two speech bubbles
    Edge between two speech bubbles
  • Edge between two speech bubbles
    Edge between two speech bubbles
  • Upper lip
    Upper lip

I wonder if it would make sense to slightly tweak these icons to avoid blurring them. —⁠andrybak (talk) 23:23, 1 May 2020 (UTC)[reply]

Thanks ⁠andrybak, this has been captured in Phabricator as task T251659. –Volker E. (WMF) (talk) 02:44, 2 May 2020 (UTC)[reply]

<ref name="foo">...</ref> generates <li id="cite_note-foo-#">...</li> in the reflist (where # is the ordinal of the note). So we can link to it as in see [[#cite_note-foo-#|this footnote]], but this will stop working, or need to be updated, whenever the position of the note changes, so I think we tend to just avoid the construction and refer to footnotes in more abstract ways.

But wouldn't it be fabulous if we could just link to a footnote on the same page by something like see [[#{{#refid:foo}}|this footnote]]? Or is this possible already? Nardog (talk) 00:35, 2 May 2020 (UTC)[reply]

Perhaps I am misunderstanding, but wouldn't text like "See note <ref name="foo"/>." work for an already named note? 24.151.50.175 (talk) 16:58, 3 May 2020 (UTC)[reply]
Yes and no. "See note [1]" doesn't work nearly as well as "See this note", given the superscript text is semantically non-essential (i.e. something you would skip if you were reading out loud). It would also create an unnecessary backlink ("^"). Nardog (talk) 22:10, 3 May 2020 (UTC)[reply]

Come to think of it, why do the anchors (#id) for named references have dynamic numbers at the end in the first place? Were it not for them, we would be able to reliably link to them not only on the same page but even from other pages. Nardog (talk) 22:10, 3 May 2020 (UTC)[reply]

Collapsing half a table

I'm working on an update to Template:Hatching table, whereby everything after the "Historical systems" row is collapsed. However, this doesn't really seem possible with what I know of tables. Posting here so that more enlightened brains can teach me something new, or confirm my suspicions. Primefac (talk) 02:54, 2 May 2020 (UTC) (please ping on reply)[reply]

Wikitable headings

Has it always been the case that the dividing lines between cells in headings have been missing in "wikitable" class tables, or is this a new thing? If it is a new thing, how do I get the lines back? SpinningSpark 17:12, 2 May 2020 (UTC)[reply]

I have only seen this when "Make sure that headers of tables remain in view as long as the table is in view" is enabled at Special:Preferences#mw-prefsection-gadgets. Is it the gadget causing it for you? It can be discussed at MediaWiki talk:Gadget-StickyTableHeaders.css. If it's not the gadget then please post an example where you see this, name your skin and browser, and say whether it happens when you log out. PrimeHunter (talk) 17:33, 2 May 2020 (UTC)[reply]
Yes, it was the gadget. I was also getting a really weird effect (before I turned the gadget off) with the table at the bottom of this sandbox history page. The row headings of the bottom half of the table (with the missing cells) were being pushed over the top half as the page was scrolled up. SpinningSpark 17:52, 2 May 2020 (UTC)[reply]

Wikimedia Error (AKA Wikimedia Foundation Error)

It's half a year, and the problem persists. Friday I had problems with this. Persistance of clicking on the "try again" and then, in the popup box, Retry, seems unfriendly to the edit community. Bang head against wall harder?

Now I'm documenting a specific (attempted) edit.

If you report this error to the Wikimedia System Administrators, please include the details below.
  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 857280943

Error: 503, Backend fetch failed at Sun, 03 May 2020 08:40:40 GMT

  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 849665645

Error: 503, Backend fetch failed at Sun, 03 May 2020 08:43:04 GMT

  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 849896892

Error: 503, Backend fetch failed at Sun, 03 May 2020 08:58:59 GMT

  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 853603024

Error: 503, Backend fetch failed at Sun, 03 May 2020 09:14:37 GMT

  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 883744841

Error: 503, Backend fetch failed at Sun, 03 May 2020 09:54:06 GMT

  • ## Request from 72.251.70.94 via cp1083 frontend, Varnish XID 888745235

Error: 503, Backend fetch failed at Sun, 03 May 2020 10:09:43 GMT

Signed... only one head, so can't try Two Heads (to bang) better than .. Pi314m (talk) 10:24, 3 May 2020 (UTC)[reply]

On what page did this occur? What were you doing (view, edit, preview)? Johnuniq (talk) 10:53, 3 May 2020 (UTC)[reply]
Edit on https://en.wikipedia.org/enwiki/w/index.php?title=List_of_cities_by_international_visitors Pi314m (talk) 17:33, 3 May 2020 (UTC)[reply]

Category redirects populated by templates, scripts and extensions

General

A number of populated category redirects have piled up that are impossible to fix with either the redirect maintenance bot or simple changes to the templates to move the contents over to the correct target. Does anyone have the technical knowledge to move over the contents of any of the following?

All help would be much appreciated. Timrollpickering (talk) 11:46, 3 May 2020 (UTC)[reply]

The user script pages are all because they have [[Category:Foo]] as an example somewhere. I think that back in the day (circa 2015?) these wouldn't be processed as links, and since they are all ancient, they were never reloaded to have the category on them. Recently, though, Krinkle mass-fixed some old variables. Pre/appending <nowiki> and </nowiki> respectively should work, as would inserting a colon in the link; if desired I can handle that. ~ Amory (u • t • c) 14:09, 3 May 2020 (UTC)[reply]
Please do; Category:Foo has caused various problems over the years. Timrollpickering (talk) 15:19, 3 May 2020 (UTC)[reply]
 Done. All came from the same old source. ~ Amory (u • t • c) 10:57, 4 May 2020 (UTC)[reply]
Thank you. Timrollpickering (talk) 15:15, 4 May 2020 (UTC)[reply]

Babel

These redirects are populated by users using the Babel extension with dialect codes that are not part of the overall system. This has been raised by me over several years and eventually a workaround was posted at Wikipedia talk:Babel#Category redirects; however one user doesn't like the outcome and insists first on reverting to the incorrect format and now threatening admins who try to fix it with being reported for vandalism. Their first suggestion of using lower case with Babel does not work and the Babel extension itself is impossible to amend for all but the deeply versed in code. I have asked for help at Extension talk:Babel but the extension does not appear to be monitored (there has been no reply at all for a month) so we have an impasse with the problem remaining. How can this be fixed? Timrollpickering (talk) 11:46, 3 May 2020 (UTC)[reply]

If there are issues with users, that's for WP:ANI. --Izno (talk) 14:13, 3 May 2020 (UTC)[reply]
I fear so but wanted to explore technical solutions first as a calmer solution. However this is a problem that's been flagged for nearly four years and the solution at Wikipedia talk:Babel#Category redirects is the only one that's ever been forthcoming so this may be a vain hope. Timrollpickering (talk) 10:58, 4 May 2020 (UTC)[reply]

Converting pseudo-namespaces to aliases

When I first learned about the pseudo-namespaces such as H: for Help: and T: for Template:, I tried using them, but they only rarely were set up. They don't seem to function anywhere near as well as the aliases built into the software. Is there any reason we haven't converted some of them to aliases? {{u|Sdkb}} talk 23:12, 3 May 2020 (UTC)[reply]

  • @Sdkb: See this RfC for information. — J947 [cont] 23:16, 3 May 2020 (UTC)[reply]
    Thanks for catching me up, J947! The line that stands out to me is the second clause of this: There is no consensus to treat such redirects (eg "T:" and "MOS:") as being as acceptable as "WP:" and "WT:", which work through software magic; whether the developers should be asked to make similar provisions for such shortcuts as they did for the project namespace is a matter for further discussion. Did anyone ever follow up on that? MOS: seems like a tricky case since it has a different meaning than Wikipedia:, so ignore that one, but for T:, H:, P:, and CAT:, I'd think we'd want to ask the developers to make them aliases. Would there be support for that? {{u|Sdkb}} talk 23:29, 3 May 2020 (UTC)[reply]
    The obvious reason for not making an alias of H: is that it would need a matching HT: and therein lies the problem: HT (or any case variant) is the language code for the Haitian Creole Wikipedia so [[ht:<something>]] creates an interwiki link to ht.wiki.
    —Trappist the monk (talk) 23:42, 3 May 2020 (UTC)[reply]
    Continuing this thought: tt → Tatar and pt → Portuguese. And yep, there is a tt.wiki and a pt.wiki.
    —Trappist the monk (talk) 23:52, 3 May 2020 (UTC)[reply]
    I wouldn't think aliases would be supported. It's one thing to expect people to absorb WP: and WT: which are common, but using H: instead of Help: is not useful, and T: is too mysterious for those who don't spend their days dreaming about templates. Similar for others. Johnuniq (talk) 23:46, 3 May 2020 (UTC)[reply]
    those who don't spend their days dreaming about templates you got me there haha... I guess I'll feel a little better about typing out "Template:" now that I know it's for the sake of the Tatars. ¯\_(ツ)_/¯ {{u|Sdkb}} talk 06:29, 4 May 2020 (UTC)[reply]
  • It's time that we put this into the FAQ. --Redrose64 🌹 (talk) 19:28, 4 May 2020 (UTC)[reply]

Allow mobile web editor to undo changes

Tracked in Phabricator
Task T191706

Hi, I'm usually logged in but when I'm on a different device or something I like to either use my alt or go anonymous.

I was hopping on Random article and later RC and after finding a vandal-esque edit, I tried to undo but couldn't find the option to undo, only manually edit the changes.

I understand bringing the undo button to the mobile app editor may invoke an influx of edit warring and all that jazz, but Undo is already available for desktop for all users. Happy editing!

P.S. Dunno if this should go here or on Proposals, move it there if needed 120.20.170.114 (talk) 12:27, 4 May 2020 (UTC)[reply]

Seems to be phab:T191706 – Majavah (t/c) 12:33, 4 May 2020 (UTC)[reply]
Thanks, dude. Glad this is being worked on - feel free to close 120.20.170.114 (talk) 12:36, 4 May 2020 (UTC)[reply]

PetScan

Magnus Manske's invaluable Wikipedia:PetScan tool is down; could someone please investigate? -- The Anome (talk) 13:22, 4 May 2020 (UTC)[reply]

It's been down for a while. A Wikimedia Cloud Services admin restarted it, which brought it back for a little while. Magnus is the sole maintainer, so he's the only one who can do the investigating. --AntiCompositeNumber (talk) 14:48, 4 May 2020 (UTC)[reply]
It's up again. Since it's not hosted at Toolforge, it cannot be put up for adoption by another maintainer either. --qedk (t 愛 c) 15:54, 4 May 2020 (UTC)[reply]

Conditional table looks weired.

Hi,

Here is my template code for conditional row: https://gofile.io/?c=KfrrxS (code.jpg)

If I use both rows it looks good. As here: https://gofile.io/?c=KfrrxS (good.jpg)

But if I use one of them, it looks weired, as here: https://gofile.io/?c=KfrrxS (bad.jpg)

How to fix it?

PS. Sorry I could not post any file here and image here. So I gave link. Please help.

Farvardyn (talk) 15:01, 4 May 2020 (UTC)[reply]

@Farvardyn: Post the code and calls as text so it can be tested. Your image is an unreadable mess of left-to-right and right-to-left text, and you don't even show any of the calls. Also say at which wiki the code runs. I guess it's not here when there is right-to-left text. And don't post the same question in multiple places. PrimeHunter (talk) 15:36, 4 May 2020 (UTC)[reply]


@PrimeHunter: Here is the source code. This is on my own personal wiki. Photos are here: https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired

I highly appreciate your help. {| class="wikitable" {{#if:{{{boardgameclub1|}}}| {{!}}- ! boardgameclub {{!}} {{{boardgameclub1}}} {{!}} {{{boardgameclub2}}} }} {{#if:{{{boardgamecenter1|}}}| {{!}}- ! boardgame center {{!}} {{{boardgamecenter1}}} {{!}} {{{boardgamecenter2}}} }} |}

And here is the usage: {{Shop| boardgameclub1=value1| boardgameclub2=value2 }} PS. It seems code is not visible unless otherwise you click for `Edit` to see it! Also You can find it on StackOverflow link I gave above. — Preceding unsigned comment added by Farvardyn (talk • contribs) 15:52, 4 May 2020 (UTC)[reply]

Farvardyn (talk) 15:49, 4 May 2020 (UTC)[reply]

@Farvardyn: Your code here has empty lines which aren't in your links. The problem goes away when I remove the empty lines here or copy your code from https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired. PrimeHunter (talk) 16:18, 4 May 2020 (UTC)[reply]
@PrimeHunter: Thanks, it worked. What if I want to do use (IF A & B both are empty) or not set? How this if clause should look like?
@Farvardyn: {{#if:{{{A|}}}{{{B|}}}|At least one of A and B is set|A and B are both empty or not set}} PrimeHunter (talk) 17:15, 4 May 2020 (UTC)[reply]
@PrimeHunter: Sorry, it still is not working when I tried to add some more options to the code. I updated Stackoverflow with my full code as here: https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired why it is happening again? Isn't it a bug in this feature? I highly appreciate if you look in my updated code there.

Farvardyn (talk) 06:15, 5 May 2020 (UTC)[reply]

Is a fix needed

I noticed that the {{Infobox company}} has a red error message in the example box that is to the right of the "short version" description. It reads "error: {{lang}}: text has italic markup". As the page is fully protected I can't examine the situation further. I don't know whether this is a problem or not so I brought it here for others to check on. Thanks for your time. MarnetteD|Talk 15:32, 4 May 2020 (UTC)[reply]

It's a documentation issue on the semi-protected Template:Infobox company/doc. Fixed by removing a non-displayed parameter from the demo call.[6] PrimeHunter (talk) 15:50, 4 May 2020 (UTC)[reply]
Many thanks PrimeHunter. MarnetteD|Talk 15:58, 4 May 2020 (UTC)[reply]

Tech News: 2020-19

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

  • Some wikis will be on read-only for a few minutes on 5 May. This will happen around 05:00 UTC. This is for database maintenance. [7]
  • Some wikis will be on read-only for a few minutes on 7 May. This will also affect CentralAuth. This can for example affect global renames, password changes, changing or confirming your email address and logging in to new wikis. This will happen around 05:00 UTC. This is for database maintenance. [8]

Changes later this week

  • You can get a notification when someone links to a page you created. You can soon turn these notifications off for individual pages. [9]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 May. It will be on non-Wikipedia wikis and some Wikipedias from 6 May. It will be on all wikis from 7 May (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

16:59, 4 May 2020 (UTC)

Automatic edit summaries

I noticed that changing redirect targets got a new AES two years ago. But since I like to what I call "go retro" as I did here, I would like to know if there is a way to make this standard.

(←Changed redirect target from X to Y)

I want to go retro by using this instead:

(←Redirected page to Y)

Is there a code I have to put or something?

I'm not perfect but I'm almost (talk) 17:14, 4 May 2020 (UTC)[reply]

The automatic edit summary is MediaWiki:Autosumm-changed-redirect-target. If you want it changed for everybody then you have to get that message changed. If you want your own edit summaries changed without entering them manually then I don't know whether some JavaScript could do it. It sounds complicated to detect automatically with a script which then inserts your wanted summary. I guess the MediaWiki feature cannot be used since it works after you click save and the edit is already being processed without a summary. PrimeHunter (talk) 17:25, 4 May 2020 (UTC)[reply]

New Wikipedia font in diff preview boxes

Also see Wikipedia:Village pump (technical)#Thursday font change.

Hi, Currently I'm using the previous Wikipedia font at User:Davey2010/vector.css (because I dislike the new one), Anyway now whenever I preview someones edits both preview boxes are now using the new font,
Is there a way around this ?,
FWIW the vector.css coding was copied from VP/T when people didn't like the font,
Anyway thanks, Regards, –Davey2010Talk 19:57, 4 May 2020 (UTC)[reply]

@Davey2010: Hmm, you copied the wrong snippet from somewhere I guess.
This was it:
.diff-editfont-monospace .diff-addedline,
.diff-editfont-monospace .diff-deletedline,
.diff-editfont-monospace .diff-context {
  font-family: sans-serif;
  font-size: 88%;
}
--qedk (t 愛 c) 20:09, 4 May 2020 (UTC)[reply]
@Davey2010: You didn't include the last } at the end when you copied it to your vector.css. --Yair rand (talk) 20:19, 4 May 2020 (UTC)[reply]
Hi QEDK, To my knowledge it was copied from here, Up until now the old font was used both in diff box and everywhere else, Also that code doesn't appear to work unless I've done something else wrong ?,
Thanks Yair rand - Readded the code and still nothing, Thanks, –Davey2010Talk 20:23, 4 May 2020 (UTC)[reply]
  • FWIW a whole of people here are using the exact same code as mine however by the looks of it people copied it all on the 4th April 2014, Also found a discussion here however that makes no mention of "bodyContent" (which is in the vector page) so I have no idea where I copied the code from, Thanks, –Davey2010Talk 20:43, 4 May 2020 (UTC)[reply]
I am experiencing the same issue when viewing diffs, and I did not make any recent edits to my vector.css. -- Black Falcon (talk) 20:31, 4 May 2020 (UTC)[reply]

ParserFunctions

Hello!

Can someone help me with a thing related to (I believe) parser functions?

I want to write something depending on the number of entries on a specific category.

The logic would be:

  • If there are 0 pages, say there are no pages;
  • If there is 1 page, say there is 1 page;
  • If there are more than 1 page, say there are X pages;

I tried using an #ifexpr function but it only takes 2 values if I'm not wrong and not three so... Is there any workaround to this? Maybe a better way to do it than what I'm doing? Or is there no way to accomplish this? I can show more details on the specific task if so needed. The point is to make grammar match automatically the status of the category.

Extra question: Do #ifexpr functions accept signs like ≤ and ≥ ? - Klein Muçi (talk) 01:48, 5 May 2020 (UTC)[reply]

Easiest way to do that would probably be
{{#switch:{{PAGESINCATEGORY:Example}}
  |0=There are no pages
  |1=There is 1 page
  |#default=There are {{PAGESINCATEGORY:Example}} pages
}}
You could also do
{{#ifeq:{{PAGESINCATEGORY:Example}}|0
  |There are no pages
  |There {{plural:{{PAGESINCATEGORY:Example}}|is|are}} {{PAGESINCATEGORY:Example}} {{plural:{{PAGESINCATEGORY:Example}}|page|pages}}
}}
You can use >= in expressions, but not ≥. I'd suggest taking a look at mw:Help:Extension:ParserFunctions. --AntiCompositeNumber (talk) 02:36, 5 May 2020 (UTC)[reply]
Note that {{PAGESINCATEGORY|Example}} is a template call so it requires Template:PAGESINCATEGORY to exist. On a wiki without such a template you need {{PAGESINCATEGORY:Example}} to use mw:Help:Magic words#PAGESINCATEGORY. PrimeHunter (talk) 03:02, 5 May 2020 (UTC)[reply]
I'm going to blame the lack of syntax highlighting in <pre></pre> tags for that. --AntiCompositeNumber (talk) 03:16, 5 May 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=954961617"