→Discussion: Replying to Nikkimaria (using reply-link) |
m →Discussion: + |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 148: | Line 148: | ||
*:::::::If you aren't proposing that Muziekweb should be used in {{tl|Authority control}}, it's not relevant to this discussion. Both sites are currently already allowed as external links (by default) and are not going to be disallowed by this discussion, because that's not how you defined the RfC. I'm not going to respond further in this part of the thread since it's clearly off-topic and the arguments that you've presented have no relevance to the AC template. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 14:06, 7 May 2020 (UTC) |
*:::::::If you aren't proposing that Muziekweb should be used in {{tl|Authority control}}, it's not relevant to this discussion. Both sites are currently already allowed as external links (by default) and are not going to be disallowed by this discussion, because that's not how you defined the RfC. I'm not going to respond further in this part of the thread since it's clearly off-topic and the arguments that you've presented have no relevance to the AC template. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 14:06, 7 May 2020 (UTC) |
||
*To respond to an argument put forward by [[User:Jc86035|Jc86035]] and others: as an external links template AC is subject to [[WP:EL]]. The bar for inclusion/exclusion is not "this link is never ever appropriate"; it's rather "in the majority of cases where this identifier exists, would its inclusion meet [[WP:EL]]"? The fact that it meets EL in some specific cases is a minimum standard but not sufficient for default inclusion in 125k articles and counting. [[User:Nikkimaria|Nikkimaria]] ([[User talk:Nikkimaria|talk]]) 15:33, 9 May 2020 (UTC) |
*To respond to an argument put forward by [[User:Jc86035|Jc86035]] and others: as an external links template AC is subject to [[WP:EL]]. The bar for inclusion/exclusion is not "this link is never ever appropriate"; it's rather "in the majority of cases where this identifier exists, would its inclusion meet [[WP:EL]]"? The fact that it meets EL in some specific cases is a minimum standard but not sufficient for default inclusion in 125k articles and counting. [[User:Nikkimaria|Nikkimaria]] ([[User talk:Nikkimaria|talk]]) 15:33, 9 May 2020 (UTC) |
||
*:{{re|Nikkimaria}} Yes, but |
*:{{re|Nikkimaria}} Yes, but it would be necessary to demonstrate the inappropriateness of a majority of the links in order to exclude linking to the site on those grounds. I imagine this could be shown if it were the case, e.g. by random sampling of the links, but "inappropriate" would have to be well-defined in this context before this could be done. For example, if a page is out of date because an artist is known to have died and they are unintentionally stated to be living (which I imagine happens occasionally), would that be considered inappropriate under [[WP:ELNO]]'s second criterion? |
||
*:A careful reading of [[WP:ELNO]] would suggest that the vast majority of MusicBrainz's |
*:A careful reading of [[WP:ELNO]] would suggest that the vast majority of MusicBrainz's pages would be acceptable under the criteria in that section. MusicBrainz provides unique, interlinked identifiers and typically other data/links that the Wikipedia article wouldn't have, which means criterion 1 doesn't apply for most pages; even if the data is incorrect, criterion 2 doesn't necessarily apply even to pages with errors because the errors usually wouldn't be intentionally misleading; criterion 12 doesn't apply to MusicBrainz because it's well-established; and so on. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 15:56, 9 May 2020 (UTC) |
||
== Combining RandomInCategory with PAGENAME == |
== Combining RandomInCategory with PAGENAME == |
||
Line 702: | Line 702: | ||
I was using Firefox 64.0 (64-bit). [[User:SmileyTrek|SmileyTrek]] ([[User talk:SmileyTrek|talk]]) 17:59, 8 May 2020 (UTC) |
I was using Firefox 64.0 (64-bit). [[User:SmileyTrek|SmileyTrek]] ([[User talk:SmileyTrek|talk]]) 17:59, 8 May 2020 (UTC) |
||
:{{fixed}}. Hiding the template entirely is an unpleasant failure mode. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 18:06, 8 May 2020 (UTC) |
:{{fixed}}. Hiding the template entirely is an unpleasant failure mode. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 18:06, 8 May 2020 (UTC) |
||
Thank you very much. [[User:SmileyTrek|SmileyTrek]] ([[User talk:SmileyTrek|talk]]) 16:01, 9 May 2020 (UTC) |
Revision as of 16:01, 9 May 2020
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
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.
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)
- 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)- 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)- You'd have to make it a wrapper. Primefac (talk) 20:39, 27 April 2020 (UTC)
- @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)
- 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)- @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)
- @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)- 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) - @Sdkb: You're looking for Module:Template wrapper. * Pppery * it has begun... 19:14, 4 May 2020 (UTC)
- In a word, no. If {{B}} is a wrapper for {{A}}, and A has a
- Well, if you want {{Don't ping}} to display
- @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)
- You'd have to make it a wrapper. Primefac (talk) 20:39, 27 April 2020 (UTC)
- The main impetus behind my proposal was consolidating overproliferated templates (I'd like to make
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):
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)
- The claim that
"the BBC website does not seem to link to Wikipedia via MusicBrainz very often any more "
seems to based on a basic misunderstanding of how the BBC use Musicbrainz, and as such is a straw man argument. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 9 May 2020 (UTC)- Illustrating by an example, Pini di Roma (a composition with a Wikipedia article):
- Has a MusicBrainz page: "Pini di Roma, P 141 – Symphonic poem" at MusicBrainz (information and list of recordings)
- Has a BBC page – which does link to the Wikipedia article on the composition, but does not link to the aformentioned MusicBrainz page.
- ... which illustrates that BBC does not link to MusicBrainz very often. In fact, I couldn't find a single BBC page on a composition that links to MusicBrainz (although such pages usually link to Wikipedia). Note that it is also not possible to get from the MusicBrainz page on the Pini di Roma composition to the BBC page on the same topic. BBC pages on a composer seem to link to MusicBrainz more often... but such pages usually link to Wikipedia way higher on the page than where they link to MusicBrainz. The whole rationale of MusicBrainz pages being some sort of authority control system which brings Wikipedia and BBC nearer to each other seems, to say the least, a bit exaggerated. --Francis Schonken (talk) 15:18, 9 May 2020 (UTC)
- Illustrating by an example, Pini di Roma (a composition with a Wikipedia article):
- The claim that
- 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. [1]), changing this to a select, limited group of truly useful links would be a serious improvement. Fram (talk) 08:01, 28 April 2020 (UTC)
- 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)
- No – A lot is user-generated and therefore not a reliable source. —Ojorojo (talk) 13:41, 28 April 2020 (UTC)
- No, per all the rationale given above.--3family6 (Talk to me | See what I have done) 14:07, 28 April 2020 (UTC)
- 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)
"no business being in an authority control any more than IMDb does"
Indeed. We should add IMDb to {{Authority control}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 9 May 2020 (UTC)
- 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)
- 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.
- (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).
- The quality of MusicBrainz data may not be directly comparable to that of another database's data, because most similar databases do not make public and/or do not calculate statistics on their own reliability. However, from the available data, it can at least be shown that errors in MusicBrainz are routinely corrected. For example, it is public information that several MusicBrainz artists are merged each day (after the usual one-week waiting period), and that the process is scrutinized by experienced users such that there is sometimes consensus not to merge. (More information about edits can be seen by registered users.)
- 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)
- Yes. Per Jc86035 - Premeditated (talk) 15:49, 29 April 2020 (UTC)
- Yes - Jc86035 makes a lot of sense here. Thanks. Mike Peel (talk) 18:26, 29 April 2020 (UTC)
- No per Fram and Voceditenore. Nikkimaria (talk) 02:28, 1 May 2020 (UTC)
- Yes - per Jc86035. ‐‐1997kB (talk) 02:37, 2 May 2020 (UTC)
- 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)
- @Sergecross73: Do you have any examples in mind? (I'd also note that this is, strictly speaking, supposed to be more about the identifiers than the content.) Jc86035 (talk) 12:45, 6 May 2020 (UTC)
- Yes per Jc86035 who makes a good case for its inclusion and refutes the arguments presented against it. Thryduulf (talk) 15:48, 5 May 2020 (UTC)
- Yes Per Jc86035 and more. There are two significant misapprehensions in this and prior discussions; which through previously refuted reappear here as misrepresentations. Firstly, the point of including an identifier in {{Authority control}} is not to cite anything - so that the link might fail WP:RS is immaterial. Secondly, the point of inclusion is not to provide "worthwhile content" - the links after all, are not in the "External links" section, so WP:EL does not apply. The point of inclusion is to assert authority, in the sense used at Authority control; in other words to verify identity and aid disambiguation. And for that purpose MusicBrainz is perfectly good. more than good, in fact; it is so well-suited to the role that - among many others - the BBC - an august and well-scrutinised public body - use it for that purpose. Furthermore, for many musicians and ensembles, it is the only external identifier that we have. As such, its removal would be disruptive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:57, 9 May 2020 (UTC)
- Maybe have a bit more trust in the sister project that handles authority control across Wikimedia projects? Wikidata's authority control files are trusted by VIAF, Library of Congress and whatnot. Every Wikipedia page is linked to its authority file, so that should be enough for the authority control aspect, no? Maybe add a few that have authority control files on a broad range of topics in the {{authority control}} box, but I don't see a problem with authority control being handled at Wikidata exclusively for those topics that pass GNG, but are not listed by any of the other broad authority control handlers. --Francis Schonken (talk) 15:54, 9 May 2020 (UTC)
Discussion
- May I ask why VPT was chosen for this RFC? It's definitely not a technical issue. --AntiCompositeNumber (talk) 16:17, 28 April 2020 (UTC)
- Templates, and {{authority control}} is a template, are usually associated with the technical VP. The template is also programmed in Lua (Module:Authority control), which can only be changed if one has "technical competence" type of access permissions. Also, during preparation of this RfC the venue for the RfC was discussed, in which I defended VPT: see explanation there. --Francis Schonken (talk) 16:29, 28 April 2020 (UTC)
- I don't accept any of that. You seem to have been the only person in favour of VPT as the venue. In short: what the heck is this doing here, why is it not at Template talk:Authority control? --Redrose64 🌹 (talk) 19:40, 28 April 2020 (UTC)
- Oh, and while we're about it, it's not showing properly at Wikipedia:Requests for comment/Biographies (or any of the others), so you could make a case for VPT being the venue to request an explanation as to just why the RfC isn't showing in the listings, but people usually post questions like that to User talk:Legobot, User talk:Legoktm or Wikipedia talk:Requests for comment, where I explain the problem yet again. Hint: the RfC statement is not brief enough - that
{{collapse top}}
/{{collapse bottom}}
won't help either. --Redrose64 🌹 (talk) 19:51, 28 April 2020 (UTC)- That's a different matter, and would be glad with some assistance (that is, without changing the layout too much). --Francis Schonken (talk) 06:08, 29 April 2020 (UTC)
- Templates, and {{authority control}} is a template, are usually associated with the technical VP. The template is also programmed in Lua (Module:Authority control), which can only be changed if one has "technical competence" type of access permissions. Also, during preparation of this RfC the venue for the RfC was discussed, in which I defended VPT: see explanation there. --Francis Schonken (talk) 16:29, 28 April 2020 (UTC)
- Would someone please delete this whole RfC so it can be posted at WP:VPR or somewhere else. VPT is not the place for a 30-day RfC, particularly when it's not a VPT issue. Johnuniq (talk) 23:23, 28 April 2020 (UTC)
- This is not the first RfC here, e.g. Wikipedia:Village pump (technical)/Archive 175#RfC: Alteration of Account Creation Limits/Account Creator Rights, and as said, Lua templates are a technical topic. If you don't want RfCs here, see to it that it is documented somewhere clear, and that you have a consensus on it before implementing. As for this RfC, it would imho be disruptive to move it now. I could agree with an early closure (2 weeks or so), that is: if the !votes continue to be more or less unanimous as they do now. --Francis Schonken (talk) 06:08, 29 April 2020 (UTC)
- The issue is not with RfCs here in general. The issue is that RfCs should, as far as is practical, always be at the venue most applicable to the question being asked. This RfC question is about the content of a template, and so would be most appropriate at the template talk page or a project (talk) page relevant to that content. It would be appropriate here only if it was asking about technical aspects, e.g. of implementation but that the content in question is hosted on a lua template is completely irrelevant to the question being asked. Thryduulf (talk) 09:43, 29 April 2020 (UTC)
- See preliminary discussion: the previous RfC, which led to indecisiveness on the topic brought here, was "village pump" level, and holding an RfC on a topic that tries to outdo what was resulting from a previous RfC can hardly be held at a less visible place, in order not to be perceived as a more WP:LOCALCONSENSUS. And again, during the preparation process the venue was discussed. There were enough technical people following the discussion that could have brought any argument to initiate it elsewhere (the only suggestion to hold it elsewhere was given without rationale). So, I am sorry, and apologise for the inconvenience (although I see no explanation *why* it would be inconvenient), but oppose moving a well-prepared RfC elsewhere. --Francis Schonken (talk) 10:08, 29 April 2020 (UTC)
- The issue is not with RfCs here in general. The issue is that RfCs should, as far as is practical, always be at the venue most applicable to the question being asked. This RfC question is about the content of a template, and so would be most appropriate at the template talk page or a project (talk) page relevant to that content. It would be appropriate here only if it was asking about technical aspects, e.g. of implementation but that the content in question is hosted on a lua template is completely irrelevant to the question being asked. Thryduulf (talk) 09:43, 29 April 2020 (UTC)
- This is not the first RfC here, e.g. Wikipedia:Village pump (technical)/Archive 175#RfC: Alteration of Account Creation Limits/Account Creator Rights, and as said, Lua templates are a technical topic. If you don't want RfCs here, see to it that it is documented somewhere clear, and that you have a consensus on it before implementing. As for this RfC, it would imho be disruptive to move it now. I could agree with an early closure (2 weeks or so), that is: if the !votes continue to be more or less unanimous as they do now. --Francis Schonken (talk) 06:08, 29 April 2020 (UTC)
- Notifying the participants in the preliminary discussion who haven't commented yet: Nikkimaria, Tacsipacsi, Pigsonthewing. Jc86035 (talk) 08:14, 29 April 2020 (UTC)
- I've moved the thread below out of the Survey section since it's tangential to the RfC. Jc86035 (talk) 14:11, 7 May 2020 (UTC)
- Re. The Carpenters: if you'd think https://musicbrainz.org/artist/4580d83b-093e-4241-91fb-2dd71f5f1f3f a good external link, I'd prefer it to be displayed thus:
The Carpenters discography at MusicBrainz.
- in an "External links" section, than as a mere linked code number (MusicBrainz: 4580d83b-093e-4241-91fb-2dd71f5f1f3f) in the authority control box. Further,
The Carpenters at Muziekweb website.
- may be a better alternative in an external links section, for several reasons: e.g., data compiled by librarians (better than WP:USERGENERATED); record sleeves shown (without potential copyright violation issues, while a public library website); etc. Note that this website also has unique identification numbers, authority control style (what else would one expect from librarians?) More importantly, it is free-access, so in that sense certainly not less than MusicBrainz. This website is also publicity-free, at least more so than MusicBrainz which links to quite a few commercial websites. --Francis Schonken (talk) 11:46, 6 May 2020 (UTC)
- @Francis Schonken: Muziekweb only has one Wikidata property at the moment, Muziekweb performer ID (P5882), which is only used on 14,000 items (whereas MusicBrainz artist ID (P434) is used on 203,000). It also doesn't seem to have any data analogous to MusicBrainz's release groups, recordings, instruments or areas, and only has work/composition data for classical compositions. In terms of the breadth of data, it seems to have only about 300,000 albums/releases based on the highest used album IDs (an order of magnitude less than MusicBrainz's 2.5 million). While it certainly would be useful in its own right, its data isn't as well-interlinked as MusicBrainz's is because there isn't as much structural support for it. Jc86035 (talk) 12:44, 6 May 2020 (UTC)
- None of which is relevant for The Carpenters, i.e. the example you gave. I say that, on average, MusicBrainz has low to very low quality. The numbers you give only seem to illustrate that: it has "quantity" written all over, not "quality". Fine-tuning an external links section starts, on almost any Wikipedia article, with weeding out cruft. In too many cases, the MusicBrainz link would be part of the cruft that can be thrown out on sight, and if not, like in The Carpenters' case, it can likely be replaced with something better (which I illustrated – Muziekweb of course not being the only free-access music-related online database which offers good quality). All of this illustrates that we should *not* have a MusicBrainz link willy-nilly when the article has a standard authority control feature. --Francis Schonken (talk) 02:34, 7 May 2020 (UTC)
- @Francis Schonken: Could you explain clearly how you think the Carpenters' page on Muziekweb is higher quality than the MusicBrainz page?
- In response to the reasons you gave in the previous comment:
- Why would MusicBrainz be more prone to copyright issues? Neither site owns the copyright to the albums that they describe. Furthermore, because the Internet Archive hosts MusicBrainz's cover art, MusicBrainz is arguably less likely to be directly affected by copyright issues.
- In MusicBrainz, the cover art is shown on the pages for the releases (but not the release groups, since the cover art for different releases can be different). I believe there is a user script which also shows them on artist pages.
- It does probably help that their site is maintained by librarians, but that doesn't by itself make the site better for authority control. As aforementioned, their data is inherently less suitable for the AC template due to issues such as not having unique identifiers analogous to works and release groups.
- Linking to commercial sites doesn't invalidate a database, and Muziekweb also links to YouTube and Spotify in any case.
- I also don't see how that was irrelevant to the example. Muziekweb doesn't have unique identifiers for any of the Carpenters' works or albums that would be directly analogous to the Wikipedia articles or Wikidata items, so the AC template can't link to the albums/releases unless counterpart Wikidata items are created and support is created within the AC module for using the data on the Wikidata items for editions of publications. Jc86035 (talk) 08:31, 7 May 2020 (UTC)
- The Carpenters @ Muziekweb page has images; Carpenters @ MusicBrainz page has no images. → advantage Muziekweb
- WP:USERGENERATED websites, such as MusicBrainz, are more easily liable to have copyright issues than websites by public bodies such as public libraries. → advantage Muziekweb
- FYI, Internet Archive *has* copyright issues, so "Internet Archive hosts MusicBrainz's cover art" shoots in its own foot.
- I was speaking about "sleeves" (i.e. front & back of the sleeve), which Muziekweb has systematically for all recordings; that is not the same as "cover art" (i.e. front side of the sleeve), which is what MusicBrainz seems to have exclusively for the pages I saw. → advantage Muziekweb
- What are you going on about Muziekweb in the {{authority control}} template? I said MusicBrainz should be OUT of the AC template, while it may be acceptable as an external link in some cases, e.g. with the {{MusicBrainz artist}} template; I proposed Muziekweb as external link, i.e. outside the {{authority control}} box, as a viable replacement for such MusicBrainz link placed outside the {{authority control}} box. So I'm not going to reply to things I didn't suggest.
- Re. "Linking to commercial sites doesn't invalidate a database" – another strawman: if given the choice between a website that carries publicity (e.g. MusicBrainz), and one that doesn't (e.g. Muziekweb), we'd normally prefer the latter (per, e.g., WP:LINKSTOAVOID, which has nothing to do with the "validity of a database"). → advantage Muziekweb
- WP:USERGENERATED websites, such as MusicBrainz, are more easily liable to have copyright issues than websites by public bodies such as public libraries. → advantage Muziekweb
- --Francis Schonken (talk) 11:29, 7 May 2020 (UTC)
- If you aren't proposing that Muziekweb should be used in {{Authority control}}, it's not relevant to this discussion. Both sites are currently already allowed as external links (by default) and are not going to be disallowed by this discussion, because that's not how you defined the RfC. I'm not going to respond further in this part of the thread since it's clearly off-topic and the arguments that you've presented have no relevance to the AC template. Jc86035 (talk) 14:06, 7 May 2020 (UTC)
- The Carpenters @ Muziekweb page has images; Carpenters @ MusicBrainz page has no images. → advantage Muziekweb
- None of which is relevant for The Carpenters, i.e. the example you gave. I say that, on average, MusicBrainz has low to very low quality. The numbers you give only seem to illustrate that: it has "quantity" written all over, not "quality". Fine-tuning an external links section starts, on almost any Wikipedia article, with weeding out cruft. In too many cases, the MusicBrainz link would be part of the cruft that can be thrown out on sight, and if not, like in The Carpenters' case, it can likely be replaced with something better (which I illustrated – Muziekweb of course not being the only free-access music-related online database which offers good quality). All of this illustrates that we should *not* have a MusicBrainz link willy-nilly when the article has a standard authority control feature. --Francis Schonken (talk) 02:34, 7 May 2020 (UTC)
- @Francis Schonken: Muziekweb only has one Wikidata property at the moment, Muziekweb performer ID (P5882), which is only used on 14,000 items (whereas MusicBrainz artist ID (P434) is used on 203,000). It also doesn't seem to have any data analogous to MusicBrainz's release groups, recordings, instruments or areas, and only has work/composition data for classical compositions. In terms of the breadth of data, it seems to have only about 300,000 albums/releases based on the highest used album IDs (an order of magnitude less than MusicBrainz's 2.5 million). While it certainly would be useful in its own right, its data isn't as well-interlinked as MusicBrainz's is because there isn't as much structural support for it. Jc86035 (talk) 12:44, 6 May 2020 (UTC)
- Re. The Carpenters: if you'd think https://musicbrainz.org/artist/4580d83b-093e-4241-91fb-2dd71f5f1f3f a good external link, I'd prefer it to be displayed thus:
- To respond to an argument put forward by Jc86035 and others: as an external links template AC is subject to WP:EL. The bar for inclusion/exclusion is not "this link is never ever appropriate"; it's rather "in the majority of cases where this identifier exists, would its inclusion meet WP:EL"? The fact that it meets EL in some specific cases is a minimum standard but not sufficient for default inclusion in 125k articles and counting. Nikkimaria (talk) 15:33, 9 May 2020 (UTC)
- @Nikkimaria: Yes, but it would be necessary to demonstrate the inappropriateness of a majority of the links in order to exclude linking to the site on those grounds. I imagine this could be shown if it were the case, e.g. by random sampling of the links, but "inappropriate" would have to be well-defined in this context before this could be done. For example, if a page is out of date because an artist is known to have died and they are unintentionally stated to be living (which I imagine happens occasionally), would that be considered inappropriate under WP:ELNO's second criterion?
- A careful reading of WP:ELNO would suggest that the vast majority of MusicBrainz's pages would be acceptable under the criteria in that section. MusicBrainz provides unique, interlinked identifiers and typically other data/links that the Wikipedia article wouldn't have, which means criterion 1 doesn't apply for most pages; even if the data is incorrect, criterion 2 doesn't necessarily apply even to pages with errors because the errors usually wouldn't be intentionally misleading; criterion 12 doesn't apply to MusicBrainz because it's well-established; and so on. Jc86035 (talk) 15:56, 9 May 2020 (UTC)
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)
- 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)
- @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)
- Bumping thread. {{u|Sdkb}} talk 09:59, 30 April 2020 (UTC)
- 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)
- @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)
- @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)
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)
- 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)
- Right, Cop hold of this: 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)
.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context { font-family: sans-serif; }
- @Redrose64: Thank you so much for this! Double sharp (talk) 02:43, 1 May 2020 (UTC)
- @Redrose64: thank you. That worked for me too. SarahSV (talk) 01:36, 5 May 2020 (UTC)
- @Redrose64: Thanks for the code. David O. Johnson (talk) 23:35, 6 May 2020 (UTC)
- 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)
- @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)
- Right, Cop hold of this:
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)
- Yes, edit window is unchanged but the diff typeface has definitely changed. - X201 (talk) 14:24, 30 April 2020 (UTC)
- THE NEW FONT IST TERRIBLE --Killarnee (T•1•2) 15:05, 30 April 2020 (UTC)
- 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)
- meta:User:Killarnee/global.css Fixed.
- And font size:
- --Killarnee (T•1•2) 15:17, 30 April 2020 (UTC)
.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context { font-size: 90%; }
- 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)
- 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)
- 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)
- 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)
- Just created the meta page. Nothing happened. Cyphoidbomb (talk) 15:43, 30 April 2020 (UTC)
- 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)
- 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)
- THE NEW FONT IST TERRIBLE --Killarnee (T•1•2) 15:05, 30 April 2020 (UTC)
- Maybe this will help you: https://www.w3schools.com/css/default.asp --Killarnee (T•1•2) 15:53, 30 April 2020 (UTC)
- Maybe this will help you: https://www.w3schools.com/css/default.asp --Killarnee (T•1•2) 15:53, 30 April 2020 (UTC)
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)
- +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)
- Really, this is ugliness. I want my diffs readable again. --jpgordon𝄢𝄆 𝄐𝄇 16:55, 30 April 2020 (UTC)
- 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)
- Really, this is ugliness. I want my diffs readable again. --jpgordon𝄢𝄆 𝄐𝄇 16:55, 30 April 2020 (UTC)
- +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)
- Noting here that the software update was reverted today due to an unrelated issue. – Majavah (t/c) 17:57, 30 April 2020 (UTC)
- That's fixed it. Thanks! Lugnuts Fire Walk with Me 18:02, 30 April 2020 (UTC)
- Amen. Cyphoidbomb (talk) 18:45, 30 April 2020 (UTC)
- 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)
- 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)
- I already did, at 13:30, 30 April 2020 (UTC) --Redrose64 🌹 (talk) 23:07, 30 April 2020 (UTC)
- I can't follow that, unfortunately; I would need simple instructions. —烏Γ (kaw) │ 01:12, 01 May 2020 (UTC)
- OK, here's "simple instructions". Create User:KarasuGamma/common.css with the content * Pppery * it has begun... 03:04, 1 May 2020 (UTC)
.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context { font-family: sans-serif; }
- OK, here's "simple instructions". Create User:KarasuGamma/common.css with the content
- I can't follow that, unfortunately; I would need simple instructions. —烏Γ (kaw) │ 01:12, 01 May 2020 (UTC)
- I already did, at 13:30, 30 April 2020 (UTC) --Redrose64 🌹 (talk) 23:07, 30 April 2020 (UTC)
- I also wonder how many people stopped complaining because they switched back to Monobook. ;) Double sharp (talk) 02:40, 1 May 2020 (UTC)
- 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)
- 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)
- @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)
- @AKlapper (WMF): I don't know, maybe only just how everything else on WP works? ;) Double sharp (talk) 06:17, 5 May 2020 (UTC)
- @Double sharp: Simply repeating a statement does not answer my question where to find a reference for that statement... --AKlapper (WMF) (talk) 10:23, 7 May 2020 (UTC)
- @AKlapper (WMF): Simply: Wikipedia:Consensus. Yes, I'm aware that such changes by the developers are specifically exempted from it by WP:CONEXCEPT. But you'll find a few threads in the talk archives suggesting that I'm not alone in feeling uncomfortable about this, because it feels like a violation of the spirit of the consensus policy, even if not the letter. And no doubt this is what drives such expectations, although you'd have to ask Johnbod to know for sure. Double sharp (talk) 13:02, 7 May 2020 (UTC)
- (@Johnbod:: Ping for the above.) Double sharp (talk) 13:07, 7 May 2020 (UTC)
- Thanks! Personally speaking I'm also torn on this but as you already wrote there is WP:Consensus#Decisions not subject to consensus of editors. So I unfortunately still do not know why Johnbod wrote "approved by the/a community" above, implying that this would be some kind of requirement. For the records, the change was announced in meta:Tech/News/2020/17. --AKlapper (WMF) (talk) 13:20, 7 May 2020 (UTC)
- @Double sharp: Simply repeating a statement does not answer my question where to find a reference for that statement... --AKlapper (WMF) (talk) 10:23, 7 May 2020 (UTC)
- @AKlapper (WMF): I don't know, maybe only just how everything else on WP works? ;) Double sharp (talk) 06:17, 5 May 2020 (UTC)
- @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)
- 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)
- 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)
- 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)
- Amen. Cyphoidbomb (talk) 18:45, 30 April 2020 (UTC)
- That's fixed it. Thanks! Lugnuts Fire Walk with Me 18:02, 30 April 2020 (UTC)
- 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)
- 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)
- 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)
- The diff view font is awful and most certainly should be changed back. –Davey2010Talk 13:14, 5 May 2020 (UTC)
Something that would be interesting to check is how many active users have various things in their .css and .js pages specifically to rollback WMF-imposed changes they don't like. I guess it would be a rather nontrivial proportion. ;) Double sharp (talk) 06:22, 5 May 2020 (UTC)
- It looks fairly uncommon, especially if you exclude gadgets. Personally, I'm finding it easier to spot some things. With a monospace font, it's easier to see punctuation and the difference between similarly shaped letters such as I and l. I agree with User:SlimVirgin that the wide characters mean that fewer words appear in the same amount of space. Whatamidoing (WMF) (talk) 18:22, 5 May 2020 (UTC)
- Yes, the monospaces font makes it much easier to see punctuation changes, which was sometimes hard to see with the old fonts. I think the line spacing is the main problem. It looks much better with 1.2em (rather than 1.6em), with the padding on the highlighted text also reduced. — Jts1882 | talk 11:33, 7 May 2020 (UTC)
- I'm finding it harder to read punctuation at all, as the font is so small. That's despite implementing the changes recommended above & below. It's a big problem, hampering my editing considerably. Johnbod (talk) 12:34, 7 May 2020 (UTC)
- User:Johnbod, I think that the font size is meant to be the same as what you see in the mw:2010 wikitext editor (the editor most, but not all, editors see after clicking the Undo button). Is that what you're seeing? (You can check a list of the mw:editors if you're not sure which one you are using.) Whatamidoing (WMF) (talk) 16:35, 7 May 2020 (UTC)
- @Whatamidoing (WMF): I some time ago enlarged the edit window font because it was too small, using common.css
#wpTextbox1 {font-size: 110%;}
. If what you say is correct, it appears I have no choice but to do the same for diffs. What's the CSS for that? ―Mandruss ☎ 17:27, 7 May 2020 (UTC)- If you've implemented one of the changes above, you can set the font-size property to a larger percentage. For example:
- For those who want a tighter line spacing, you can specify the line-height property. isaacl (talk) 17:52, 7 May 2020 (UTC)
.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context { font-size: 110%; }
- @Whatamidoing (WMF): I some time ago enlarged the edit window font because it was too small, using common.css
- User:Johnbod, I think that the font size is meant to be the same as what you see in the mw:2010 wikitext editor (the editor most, but not all, editors see after clicking the Undo button). Is that what you're seeing? (You can check a list of the mw:editors if you're not sure which one you are using.) Whatamidoing (WMF) (talk) 16:35, 7 May 2020 (UTC)
- I'm finding it harder to read punctuation at all, as the font is so small. That's despite implementing the changes recommended above & below. It's a big problem, hampering my editing considerably. Johnbod (talk) 12:34, 7 May 2020 (UTC)
- Yes, the monospaces font makes it much easier to see punctuation changes, which was sometimes hard to see with the old fonts. I think the line spacing is the main problem. It looks much better with 1.2em (rather than 1.6em), with the padding on the highlighted text also reduced. — Jts1882 | talk 11:33, 7 May 2020 (UTC)
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)
- 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)
- 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)
- 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)
- Yep, back again! Please can someone fix this? Thanks in advance. Lugnuts Fire Walk with Me 17:13, 4 May 2020 (UTC)
- Could someone say how to fix this, please? It's harder to read diffs. SarahSV (talk) 17:56, 4 May 2020 (UTC)
- @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)
- 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)
- @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)
- 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)
Somehow, while the rest of the text is showing up fine for me with this fix, text added still shows up with the awful new font. Have I not put it in correctly? Double sharp (talk) 06:20, 5 May 2020 (UTC)
- @Double sharp: The selector
#pt-notifications
has no declaration block applied to it, so it's being interpreted as a required parent to the.diff-editfont-monospace .diff-addedline
, so the code won't run for anything that's not inside an added diff line inside a#pt-notifications
element. You can fix this by either re-adding the{display: none}
line you removed last week or by removing the#pt-notifications
line entirely. --Yair rand (talk) 21:16, 6 May 2020 (UTC)- @Yair rand: Thank you so much! That fixed it. Double sharp (talk) 03:46, 7 May 2020 (UTC)
I'd be happy with the new typeface if the font were a point or two larger. My eyesight isn't quite good enough for the current size. And I shouldn't need to apply personal CSS to get basic accessibility (which is, by the way, supposedly a WMF priority). ―Mandruss ☎ 12:47, 5 May 2020 (UTC)
Rather than change my common.css file directly, I created a separate CSS file and a Javascript file to load it so it can be managed by the script installer gadget. The script is User:Isaacl/script/diff-mono-font.js if anyone is interested in using it. If you don't have the script installer gadget enabled, see Wikipedia:User scripts § How do you install user scripts? for instructions on installing the script manually. Be aware though that the font used may change based on my own personal preference. If you find a font you like, you can clone the CSS file and script and set the font you want to use in the CSS file. isaacl (talk) 06:22, 6 May 2020 (UTC)
- Also be aware your IP will be shared with Google. @Isaacl: I would recommend adding a comment at User:Isaacl/script/diff-mono-font.js to warn users about this. — MusikAnimal talk 15:41, 6 May 2020 (UTC)
- Yes, my CSS file will retrieve the font from Google's web site if you don't have it installed already. (I may remove this later, in which case you will have to download and install one of the fonts listed in the CSS file, or default to whatever font is configured in your browser as the monospace font.) If you want to use a specific font and don't mind having your browser use it on other sites as well, you can use the CSS modifications others have proposed but change the font-family to "monospace", download and install the font you want to use, and change your browser configuration to use it as the monospace font. Alternatively after downloading and installing the font, you can use the CSS modifications but change the font-family to your preferred font. isaacl (talk) 16:18, 6 May 2020 (UTC)
- We do warn people that tweaking their scripts if they don't know what they are doing could compromise their account, and warn them especially that using import is even riskier. basically, for anyone asking about this now: if you import this in to your User:xxx/xxx.js page then isaacl can make your account do most anything they want in the future without you asking; forking it by copy-pasting the code will mean you trust what it is doing now, and isaacl's future changes (good or bad) won't go to you. And yes, if you include external links, they can be used to track you. — xaosflux Talk 16:24, 6 May 2020 (UTC)
- Sorry for not providing the appropriate caveats. Upon reflection, I no longer suggest using my scripts directly; Xaosflux is correct that the risk is high. I strongly encourage anyone to clone my changes to your own personal scripts if you want to be able to enable/disable them using the script installer, as I did. You can take out the @import statement now and download and install your font of choice, and trim down the CSS file to just include the font you want. (Is there a way for me to block my scripts from being used by others?) isaacl (talk) 16:40, 6 May 2020 (UTC)
- @Isaacl: There's nothing wrong with offering user scripts... there are thousands of them here. The risk you run with this script is the same you run with any other. It just wasn't obvious that this one sends your IP to Google, was my complaint. I see you've clarified that, so no concerns on my end. — MusikAnimal talk 16:53, 6 May 2020 (UTC)
- Yes, I know; but Xaosflux is correct on highlighting the general concerns and I can't in good conscience say that the benefit/risk ratio is all that high. I've removed the @import statement now to avoid the concern about third-party servers (to be honest, I think referrer information was a bigger problem; yes caching would have alleviated it but that of course is uncertain). isaacl (talk) 16:59, 6 May 2020 (UTC)
- I don't see the point. If people are unwilling to amend their common.css, why are they going to be more willing to amend their common.js? --Redrose64 🌹 (talk) 17:49, 6 May 2020 (UTC)
- Be careful, some of us are 63 years old, and not scriptkiddies. Some of us are even older. Imagine that. The word used shouldn't be "Unwilling" perhaps "unable" would be more suitable. Most of us are here to write an encyclopedia, not to become scriptkiddies. -Roxy the effin dog . wooF 17:57, 6 May 2020 (UTC)
- With the script installer gadget enabled, you don't have to edit your common.js file directly. An install link is shown on the user script page that you can click. If you're not willing to enable the script installer gadget, then I agree there isn't much point. (Personally I have no issues editing those files, but I like the ability to enable and disable the addition through the gadget.) isaacl (talk) 18:09, 6 May 2020 (UTC)
- I don't see the point. If people are unwilling to amend their common.css, why are they going to be more willing to amend their common.js? --Redrose64 🌹 (talk) 17:49, 6 May 2020 (UTC)
- Yes, I know; but Xaosflux is correct on highlighting the general concerns and I can't in good conscience say that the benefit/risk ratio is all that high. I've removed the @import statement now to avoid the concern about third-party servers (to be honest, I think referrer information was a bigger problem; yes caching would have alleviated it but that of course is uncertain). isaacl (talk) 16:59, 6 May 2020 (UTC)
- @Isaacl: There's nothing wrong with offering user scripts... there are thousands of them here. The risk you run with this script is the same you run with any other. It just wasn't obvious that this one sends your IP to Google, was my complaint. I see you've clarified that, so no concerns on my end. — MusikAnimal talk 16:53, 6 May 2020 (UTC)
- Sorry for not providing the appropriate caveats. Upon reflection, I no longer suggest using my scripts directly; Xaosflux is correct that the risk is high. I strongly encourage anyone to clone my changes to your own personal scripts if you want to be able to enable/disable them using the script installer, as I did. You can take out the @import statement now and download and install your font of choice, and trim down the CSS file to just include the font you want. (Is there a way for me to block my scripts from being used by others?) isaacl (talk) 16:40, 6 May 2020 (UTC)
- We do warn people that tweaking their scripts if they don't know what they are doing could compromise their account, and warn them especially that using import is even riskier. basically, for anyone asking about this now: if you import this in to your User:xxx/xxx.js page then isaacl can make your account do most anything they want in the future without you asking; forking it by copy-pasting the code will mean you trust what it is doing now, and isaacl's future changes (good or bad) won't go to you. And yes, if you include external links, they can be used to track you. — xaosflux Talk 16:24, 6 May 2020 (UTC)
- Yes, my CSS file will retrieve the font from Google's web site if you don't have it installed already. (I may remove this later, in which case you will have to download and install one of the fonts listed in the CSS file, or default to whatever font is configured in your browser as the monospace font.) If you want to use a specific font and don't mind having your browser use it on other sites as well, you can use the CSS modifications others have proposed but change the font-family to "monospace", download and install the font you want to use, and change your browser configuration to use it as the monospace font. Alternatively after downloading and installing the font, you can use the CSS modifications but change the font-family to your preferred font. isaacl (talk) 16:18, 6 May 2020 (UTC)
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)
- See #Thursday font change above. --Masem (t) 18:35, 4 May 2020 (UTC)
New Wikipedia font in diff preview boxes
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)
- @Davey2010: Hmm, you copied the wrong snippet from somewhere I guess.
- This was it:--qedk (t 愛 c) 20:09, 4 May 2020 (UTC)
.diff-editfont-monospace .diff-addedline, .diff-editfont-monospace .diff-deletedline, .diff-editfont-monospace .diff-context { font-family: sans-serif; font-size: 88%; }
- @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)- 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)
- 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)
- 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)
- @SlimVirgin, Redrose64, and Jonesey95: I love you all thank you os much!, I'm convinced the diff view isn't the same font but I can live with it, Hell of a lot better than the new font that's for sure!, Thanks to you 3 as well as everyone above for their help :), Thanks, –Davey2010Talk 22:08, 4 May 2020 (UTC)
Similar question, i guess: Has something changed in the way diffs are shown? I didn't edit yesterday, i think, so sometime between two days ago and today diffs are showing in a very different size and format and so on, that is not nearly as convenient for me to look at. I haven't made any edits in ages to any .js or .css files, so i can't have done anything wrongly. Any ideas, especially ideas on how i can get my previous view of diffs back? Happy days, LindsayHello 08:32, 5 May 2020 (UTC)
- GUESS WHAT????? -Roxy the effin dog . wooF 13:05, 5 May 2020 (UTC)
- Yes, what? Is it me you're shouting at? If so, i'm afraid you've lost me. This particular section, when i added my comment/question, was in a different spot on the page, so the context was entirely different. In addition, i have added the code to my .css file and the diffs still show in a different font from that they used to be in. If it was not me you were shouting at, then please ignore my explanation. Happy days, LindsayHello 15:43, 6 May 2020 (UTC)
- Wasn't you. It was a general complaint about Life, the Universe, everything and pointless font changes, and impossible to follow instructions. Additionally, it was frustration at the WMF fixing something that isn't broken, and nobody asked for. -Roxy the effin dog . wooF 15:46, 6 May 2020 (UTC)
- When this change first happened, I wondered if my browser was playing up, nope, it has been done deliberately. Not a fan of the new diff font.--♦IanMacM♦ (talk to me) 15:54, 6 May 2020 (UTC)
- No one does apparently but it's still up there. --qedk (t 愛 c) 15:54, 7 May 2020 (UTC)
- User:QEDK, it sounds like you missed Elizium23's comments above. Also, it's worth remembering that people who like it, or who don't care either way, have very little reason to come to this page to say so. Whatamidoing (WMF) (talk) 16:41, 7 May 2020 (UTC)
- No offense @Whatamidoing (WMF): but "no one" obviously does not mean no one, it means most people (here atleast). You are choosing to assume the opinion of the silent majority in the favour of the change instead of appropriately highlighting the complaints made here at the appropriate board, that's in extremely bad taste, imo. --qedk (t 愛 c) 16:49, 7 May 2020 (UTC)
- I have no idea what most people think. If there is a silent majority, then it hasn't spoken to me. Perhaps it hasn't yet decided what it thinks.
- I believe, based on research by other/non-wiki websites into website development, that when you change something as visible as the font, and as obvious as this change is, that it takes people a week or two of seeing the new thing to adapt.
- I can tell you that when I saw this the first time, I expected more complaints than have appeared, and I expected them to be universal. However, I was wrong, because apparently some of the non-English communities prefer this. Perhaps in addition to your language/script, it also depends upon how you use diffs? I imagine that the monospace font is handy for checking edits to templates, less convenient for reading the diffs of long comments on talk pages, but unimportant if you keep up with discussions by actually reading the page (instead of the diff column). I read a lot of busy pages in diff mode, so I'm finding that I'm somewhat more likely to ⌘F down to read long comments than before. But someone who doesn't read like I do might not even notice.
- Also, if you don't have your edit-window font set to monospace (Do you remember the editors complaining when that default changed here? But no complaints after the first couple of weeks...), then you probably didn't see any change. Whatamidoing (WMF) (talk) 19:01, 7 May 2020 (UTC)
- No offense @Whatamidoing (WMF): but "no one" obviously does not mean no one, it means most people (here atleast). You are choosing to assume the opinion of the silent majority in the favour of the change instead of appropriately highlighting the complaints made here at the appropriate board, that's in extremely bad taste, imo. --qedk (t 愛 c) 16:49, 7 May 2020 (UTC)
- User:QEDK, it sounds like you missed Elizium23's comments above. Also, it's worth remembering that people who like it, or who don't care either way, have very little reason to come to this page to say so. Whatamidoing (WMF) (talk) 16:41, 7 May 2020 (UTC)
- No one does apparently but it's still up there. --qedk (t 愛 c) 15:54, 7 May 2020 (UTC)
- When this change first happened, I wondered if my browser was playing up, nope, it has been done deliberately. Not a fan of the new diff font.--♦IanMacM♦ (talk to me) 15:54, 6 May 2020 (UTC)
- Wasn't you. It was a general complaint about Life, the Universe, everything and pointless font changes, and impossible to follow instructions. Additionally, it was frustration at the WMF fixing something that isn't broken, and nobody asked for. -Roxy the effin dog . wooF 15:46, 6 May 2020 (UTC)
- Yes, what? Is it me you're shouting at? If so, i'm afraid you've lost me. This particular section, when i added my comment/question, was in a different spot on the page, so the context was entirely different. In addition, i have added the code to my .css file and the diffs still show in a different font from that they used to be in. If it was not me you were shouting at, then please ignore my explanation. Happy days, LindsayHello 15:43, 6 May 2020 (UTC)
- GUESS WHAT????? -Roxy the effin dog . wooF 13:05, 5 May 2020 (UTC)
I use diffs primarily to spot vandalism, something not apparently of any importance to the Foundation accounts posting here, who only seem interested in talk pages and templates. The new font makes it harder. DuncanHill (talk) 19:07, 7 May 2020 (UTC)
- @DuncanHill: can you expand on how this makes it harder? I just pulled up recent changes and saw this edit, the vandalism is quite obvious still. — xaosflux Talk 19:22, 7 May 2020 (UTC)
- It's a harder font to read quickly. That was a particularly blatant piece of vandalism so not a great example. And no, before you ask, I'm not going to waste my time producing loads of diffs of vandalism and screenshotting them for you, not least because I can't do a "before and after". And also I don't believe the Foundation would take any notice. "We hear what you say but all the people who haven't said anything love the change, and so will you in time as we know your minds better than you do" is the line they are taking, as they always do. DuncanHill (talk) 19:30, 7 May 2020 (UTC)
- @DuncanHill: OK thanks - I went looking for an example of vandalism that was now hard to see in diff view, but after about 50 diffs I couldn't really find one - if you come across one perhaps you could drop the diff here? While we certainly can't fix things for every WMF project, or wikimedia core locally - we could possibly implement local tweaks to improve the experience, but would need to have some good use cases to build upon. — xaosflux Talk 19:53, 7 May 2020 (UTC)
- It's a harder font to read quickly. That was a particularly blatant piece of vandalism so not a great example. And no, before you ask, I'm not going to waste my time producing loads of diffs of vandalism and screenshotting them for you, not least because I can't do a "before and after". And also I don't believe the Foundation would take any notice. "We hear what you say but all the people who haven't said anything love the change, and so will you in time as we know your minds better than you do" is the line they are taking, as they always do. DuncanHill (talk) 19:30, 7 May 2020 (UTC)
- @Whatamidoing (WMF): People giving up complaining after one or two weeks does not translate to it being fine with them, they just don't see it as a choice. Even after multiple editors posted on Phabricator against it (and that is not common at all), the change was not reverted and nor was an option given to choose different styles. I understand that all changes cannot be notified but to railroad things after they are disliked is just plain mean. I had it set to monospace yeah, the 2010 editor forces monospace afaik, so in both spaces I'm stuck on that accord, not that I mind (the font is too big for me imo), but a lot of others do. I'm just trying to make opinions heard because everytime a change like this is forced upon us, we feel that you're taking away our right to choose, remember the survey which apparently had 4% opposition or something? Or the time that superprotect was decided? And finally little instances like these. The community really does not ask for a lot - we don't need flashy features, we just don't want things that are okay to be broken, is that so hard to ask? I hope you understand my viewpoint. I just hope you (or whoever is responsible for passing on feedback) really does their due diligence and takes the opinions here to heart and does what is required. --qedk (t 愛 c) 19:37, 7 May 2020 (UTC)
- User:QEDK, I believe that you will find that I have not claimed to be a mind reader. I started writing a longer explanation, but it's probably off topic for VPT, so if you're interested, then please drop by my user talk page in a few minutes. Whatamidoing (WMF) (talk) 21:54, 8 May 2020 (UTC)
- It astounds me that a major UI change was implemented with no apparent UI survey or testing in place. In my decades of involvement with software design and implementation, no company I've worked with would have done such a ham-handed job of making a glaring UI change. But then, the WMF has made it clear several times in the recent past that editors are taken for granted. Eggishorn (talk) (contrib) 19:38, 7 May 2020 (UTC)
- I'm not convinced that this is a "major" UI change. People who think changing one font in one place is a "major" change probably wants to get mw:Reading/Web/Desktop Improvements on their watchlists, because some moderate-to-major changes are planned for the coming year. Whatamidoing (WMF) (talk) 21:54, 8 May 2020 (UTC)
- And with that comment this just descended into complete unprofessionalism. It is never up to the developers in any competent software development organization to decide what is or is not a major change in UI. It neither should be up to en:wiki editors to be required to monitor meta for anything that affects their editing environment. To assert such is further evidence of WMF disconnect. I literally find monospaced fonts painfully difficult to read but my personal distress is not what I object to. It is the blasé assumption that that the WMF knows what is best without consultation. Eggishorn (talk) (contrib) 22:14, 8 May 2020 (UTC)
- Improvements for readers is different than improvements for editors; since there's no way to solicit most of the affected people, it's essential to rely on research, including A-B testing. I am also sympathetic to the argument that even for editors, there are a lot of features that are better designed through focus groups than community surveys. However choice of typeface is something text-based content creators have wanted over and over again, with everyone desiring a font that suits their own personal quirks. I can't imagine there is any research that editors using a monospaced font for editing would automatically attain a net benefit from a monospaced font over a sans-serif proportional font when viewing diffs. It's just too much of a personal choice. And unlike the interface for readers, where branding is an important factor, it plays no role for the diff viewer font. isaacl (talk) 23:17, 8 May 2020 (UTC)
- I'm not convinced that this is a "major" UI change. People who think changing one font in one place is a "major" change probably wants to get mw:Reading/Web/Desktop Improvements on their watchlists, because some moderate-to-major changes are planned for the coming year. Whatamidoing (WMF) (talk) 21:54, 8 May 2020 (UTC)
- It astounds me that a major UI change was implemented with no apparent UI survey or testing in place. In my decades of involvement with software design and implementation, no company I've worked with would have done such a ham-handed job of making a glaring UI change. But then, the WMF has made it clear several times in the recent past that editors are taken for granted. Eggishorn (talk) (contrib) 19:38, 7 May 2020 (UTC)
- FWIW, I think the change was quite reasonable, but the WMF did not handle the transition well. There should have been clear instructions on how to reverse the change posted right at the time of deployment. The unfortunate deploy-revert-redeploy also probably caused additional frustration. Style changes like this are always disruptive, even when they're positive changes, and efforts should be made to avoid messing up anyone's flow. --Yair rand (talk) 20:26, 7 May 2020 (UTC)
- @Yair rand: I did post instructions, not immediately it is true, but within half an hour of the change going live (25 minutes after, as far as I can determine). But if you read this thread from start to finish, it's surprising just how many participants clearly had not WP:READ what had already been posted and still asked for a fix even though I'd already done so. --Redrose64 🌹 (talk) 18:38, 8 May 2020 (UTC)
- I'm pretty sympathetic to the notion that there are some changes that should be done for the greater good even if there is a vocal dissenting minority. The typography refresh, for example, is something that benefited the large mass of anonymous Wikipedia readers. But if you look at any popular creation tool (such as integrated development environments) based around text, the user can customize the fonts used. If the initial release doesn't support this, I guarantee it'll be a top request. Back in the day, customizing an X11 configuration file was considered sufficient, but now people want to be able to do it more easily. It would have been desirable to invest the effort to allow the font used by the diff viewer to be configured, as it is for the edit area (I did forget how that was introduced). Yes, it would have meant some editors might have never learned how to configure the font to something more helpful for them, but they would have been no worse off than before. isaacl (talk) 22:53, 7 May 2020 (UTC)
- @Isaacl: IIUC, previously there was no way (other than direct editing of CSS) to specify a font for diffs, but this change made it so that the font for diffs is the same as the one chosen for the edit area, which can be customized at Special:Preferences#mw-prefsection-editing, and defaults to monospace. --Yair rand (talk) 00:12, 8 May 2020 (UTC)
- Can we revert back to pre-2014 fonts/sizes and anything new should be done via RFC ? ... Not saying WMF etc are useless but time and time again thing's are changed and like 80-90% of the project doesn't like those changes ..... It's OUR eyes that are being tortured to death with these fonts so we should atleast get a say on what looks/is fine and what isn't. –Davey2010Talk 23:04, 7 May 2020 (UTC)
A wild Courier appears!
In all seriousness, is there a reason why when I view diffs they are suddenly in Courier (or some similar serif monospaced) font? I find this type of font very difficult to read. This started this weekend for me with no changes to my .js or .css pages. I'm using monobook, if that makes any difference. Did I miss a technical change? Eggishorn (talk) (contrib) 21:14, 6 May 2020 (UTC)
- @Eggishorn: see this discussion. — J947 [cont] 21:20, 6 May 2020 (UTC)
Thanks for this. I was wondering the same, and thought it was my browser. For those reading, the font is now controlled in "Edit area font style" in Special:Preferences#mw-prefsection-editing. Rehman 04:35, 7 May 2020 (UTC)
- Should we drop a link to this in CD or something so that other editors know? There should be wider notice of this change and its fix, I think. Eggishorn (talk) (contrib) 05:35, 7 May 2020 (UTC)
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)
- @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)
- @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)
- ToeFungii, does this problem resolve when you edit in mw:safemode? Whatamidoing (WMF) (talk) 15:56, 4 May 2020 (UTC)
- @Nick Moyes:
- 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)
- 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)
- 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)
- 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)
- 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)
- I guess WP:WIKED doesn't support switching to the visual mode. I suppose you could talk to User:Cacycle (who controls that gadget) to see if he wants to support it. Whatamidoing (WMF) (talk) 18:37, 5 May 2020 (UTC)
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?
- Category:Articles with links needing disambiguation from april 2020 to Category:Articles with links needing disambiguation from April 2020 - no idea why this is coming out in lower case on Glossary of nautical terms
- Category:Foo to Category:X1 - something seems to have brought the Foo category back to life and it's populated by a lot of script pages that are near impossible to amend
All help would be much appreciated. Timrollpickering (talk) 11:46, 3 May 2020 (UTC)
- Fixed Category:Articles with links needing disambiguation from april 2020, which is caused by putting {{dn}} in {{term}}, which automatically lowercases its output to include an HTML ID (I resolved the disambiguation link). * Pppery * it has begun... 13:09, 3 May 2020 (UTC)
- 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)
- Please do; Category:Foo has caused various problems over the years. Timrollpickering (talk) 15:19, 3 May 2020 (UTC)
- Done. All came from the same old source. ~ Amory (u • t • c) 10:57, 4 May 2020 (UTC)
- Thank you. Timrollpickering (talk) 15:15, 4 May 2020 (UTC)
- Done. All came from the same old source. ~ Amory (u • t • c) 10:57, 4 May 2020 (UTC)
- Please do; Category:Foo has caused various problems over the years. Timrollpickering (talk) 15:19, 3 May 2020 (UTC)
Babel
- Category:User en-CA to Category:User en-ca
- Category:User en-GB to Category:User en-gb
- Category:User en-GB-3 to Category:User en-gb
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)
- If there are issues with users, that's for WP:ANI. --Izno (talk) 14:13, 3 May 2020 (UTC)
- 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)
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)
- @Sdkb: See this RfC for information. — J947 [cont] 23:16, 3 May 2020 (UTC)
- 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)- 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)
- 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)
- 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)
- 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
- Thanks for catching me up, J947! The line that stands out to me is the second clause of this:
- It's time that we put this into the FAQ. --Redrose64 🌹 (talk) 19:28, 4 May 2020 (UTC)
- See also Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces, but I suppose you meant this page's FAQ? Whatamidoing (WMF) (talk) 18:40, 5 May 2020 (UTC)
Allow mobile web editor to undo changes
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)
- Seems to be phab:T191706 – Majavah (t/c) 12:33, 4 May 2020 (UTC)
- Thanks, dude. Glad this is being worked on - feel free to close 120.20.170.114 (talk) 12:36, 4 May 2020 (UTC)
PetScan
Magnus Manske's invaluable Wikipedia:PetScan tool is down; could someone please investigate? -- The Anome (talk) 13:22, 4 May 2020 (UTC)
- 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)
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)
- @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)
- @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)
Farvardyn (talk) 15:49, 4 May 2020 (UTC)
- @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)
- @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)
- @Farvardyn:
- @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?
- @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)
- @Farvardyn: You have a newline between each
if
and they add up to blank lines. Start the nextif
on the same line the last ended like}}{{#if:
. PrimeHunter (talk) 11:15, 5 May 2020 (UTC)
- @Farvardyn: You have a newline between each
- @PrimeHunter: I tried that approach too and still not working properly! I updated source code here: https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired I appreciate if you check it. Isn't there a bug? Farvardyn (talk) 13:41, 5 May 2020 (UTC)
- @Farvardyn: Your code works for me:
- @PrimeHunter: I tried that approach too and still not working properly! I updated source code here: https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired I appreciate if you check it. Isn't there a bug? Farvardyn (talk) 13:41, 5 May 2020 (UTC)
بوردگیم کلاب | value1 | value2 |
---|
- User:PrimeHunter/sandbox9 is copied exactly from https://stackoverflow.com/questions/61595539/why-the-wiki-conditional-table-template-looks-weired and I also copied your call exactly. PrimeHunter (talk) 14:05, 5 May 2020 (UTC)
- @PrimeHunter: Sorry, I meant if I am calling more than one item it looks weird. Please try this call as it looks bad for me.
{{Shop|bazikade1=value1|bazikade2=value2|bazinovin1=value1|bazinovin2=value2|boardboard1=value1|boardboard2=value2}}
Please see this:
بازیکده | value1 | value2 |
---|---|---|
بازی نوین | value1 | value2 |
بردبرد | value1 | value2 |
Why it looks just in one row, instead of row by row? I appreciate your help. Thanks again. Farvardyn (talk) 05:53, 6 May 2020 (UTC)
- @Farvardyn: Whitespace is stripped from the beginning and end of parser function parameters. MediaWiki requires some table code to be at the start of a line so I have added non-displayed code (I chose nowiki) before newlines we don't want stripped.[2] PrimeHunter (talk) 11:14, 6 May 2020 (UTC)
- @PrimeHunter: Thanks a lot, May I ask to help for this problem to: https://stackoverflow.com/questions/61636062/why-pf-thubnails-cause-page-bad-looking
Sorry not directly here as I cannot upload screenshot and the code looks bad here. I highly appreciate your help. Farvardyn (talk) 13:22, 6 May 2020 (UTC)
- @Farvardyn: Special:Version does not show CommentStreams so mw:Extension:CommentStreams is not installed here. I don't know the extension. This page is actually only for Wikipedia and occasionally other Wikimedia wikis so the whole discussion is off topic. The top of the page says: "Questions about MediaWiki in general should be posted at the MediaWiki support desk." PrimeHunter (talk) 19:11, 6 May 2020 (UTC)
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)
- It's a documentation issue on the semi-protected Template:Infobox company/doc. Fixed by removing a non-displayed parameter from the demo call.[3] PrimeHunter (talk) 15:50, 4 May 2020 (UTC)
- Many thanks PrimeHunter. MarnetteD|Talk 15:58, 4 May 2020 (UTC)
Tech News: 2020-19
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.
I want to go retro by using this instead:
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)
- 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)
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)
- 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)- 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)- I'm going to blame the lack of syntax highlighting in <pre></pre> tags for that. --AntiCompositeNumber (talk) 03:16, 5 May 2020 (UTC)
- @AntiCompositeNumber and PrimeHunter: Thank you! Worked perfectly! Regarding the
>=/≥
signs, they are logically equal I believe, no? - Klein Muçi (talk) 14:53, 5 May 2020 (UTC)- Yes. ≥ is a special character and nearly all programming languages are restricted to ASCII characters so they say >= instead. Similarly for ≤ versus <= (or =< in rare cases). PrimeHunter (talk) 16:31, 5 May 2020 (UTC)
- @PrimeHunter: Thank you! - Klein Muçi (talk) 16:50, 5 May 2020 (UTC)
- More on that: for ≠ ≤ ≥ use <> <= >= respectively (a few languages use the two-letter acronyms NE, LE, GE instead of (or as well as) the two-character operators). --Redrose64 🌹 (talk) 18:05, 6 May 2020 (UTC)
!=
for not equal is also common. mw:Help:Extension:ParserFunctions##expr accepts both!=
and<>
. See also Relational operator#Standard relational operators for some other languages. PrimeHunter (talk) 19:04, 6 May 2020 (UTC)
- More on that: for ≠ ≤ ≥ use <> <= >= respectively (a few languages use the two-letter acronyms NE, LE, GE instead of (or as well as) the two-character operators). --Redrose64 🌹 (talk) 18:05, 6 May 2020 (UTC)
- @PrimeHunter: Thank you! - Klein Muçi (talk) 16:50, 5 May 2020 (UTC)
- Yes. ≥ is a special character and nearly all programming languages are restricted to ASCII characters so they say >= instead. Similarly for ≤ versus <= (or =< in rare cases). PrimeHunter (talk) 16:31, 5 May 2020 (UTC)
- @AntiCompositeNumber and PrimeHunter: Thank you! Worked perfectly! Regarding the
- I'm going to blame the lack of syntax highlighting in <pre></pre> tags for that. --AntiCompositeNumber (talk) 03:16, 5 May 2020 (UTC)
- Note that
get revision number of edit that you are making
I couldn't find any way to do this, and I think it must not exist because otherwise people would probably use it more. Basically I'd like some kind of magic word or variable that when you save the page, is expanded to the revision id of the revision being saved. I think that's different from {{REVISIONID}} which is expanded at rendering time, and which is now disabled (miser mode) on WMF wikis for performance reasons. The purpose is to make self-referential edits: i.e. there would be a template like "{{THISDIFF}}" which you can subst into an edit, which would turn into a permanent diff referring to the edit itself, and that would appear in the text. People could then click the diff to see what change you made in the edit. You normally wouldn't do that in an article, but on talk pages and the like, it's often useful to change something and include a link to what you changed. 2602:24A:DE47:B270:DDD2:63E0:FE3B:596C (talk) 09:36, 6 May 2020 (UTC)
- I think that's not possible as the revision ID is created automatically when the edit has been saved to the database, and so you can't include that in the data being saved. – Majavah (t/c) 09:40, 6 May 2020 (UTC)
- As it happens, I asked User:Catrope about this last November, and he said it was "pretty much impossible". I gather that it would require re-writing MediaWiki core to make it possible. phab:T14694#177118 from 2008 provides some information.
- This, by the way, is why we can't automagically include inline links to Special:Thanks or diffs on talk pages (e.g., to put Diff of this edit Thank for this comment after the timestamp). Whatamidoing (WMF) (talk) 18:19, 6 May 2020 (UTC)
Planned maintenance operation on May 7 @ 05:00 AM UTC
Hi, There's a planned maintenance operation that will be performed on Thursday 7th May at 05:00 AM UTC. CentralAuth-based services (rename account, change password, etc.) may not work. See also: phab:T251157. NB: This wiki will not go read-only during this operation. -- Kaartic correct me, if i'm wrong 11:08, 6 May 2020 (UTC)
Automatic Tags
I think that this is a question about automatic tagging in edit summaries. I see that an edit summary consists of two parts, the summary provided by the editor, and notes that are sometimes provided by the code. Where do I report concerns about the automatic tagging? This is not at all urgent. What seems to have happened has to do with Draft:Ute Lotz-Heumann. On 5 November 2019, I accepted this draft, which moved it to article space, and created a page in draft space that is a redirect to article space. The tag correctly says: New redirect. Another tag was then applied to the redirect that says, "Removed redirect". But the redirect was and is still there. As a result, six months later, today, 6 May 2020, an editor came and requested a speedy deletion of the redirect as [[WP:G13|an abandoned draft]. I have described this in more detail at Wikipedia_talk:WikiProject_Articles_for_creation#Weird_Incorrect_G13_tagging. So was the tag incorrect, and what should be done? Robert McClenon (talk) 13:59, 6 May 2020 (UTC)
- @Robert McClenon: the "removed redirect" tag related to this edit is a bit misleading perhaps - so you didn't remove text on that page about the redirect, however you did conceptually remove this page from being a redirect - by placing text before the redirect declaration readers would no longer be redirected. Admins can remove a tag from a revision if it is really needed, but in most cases it isn't a big deal. That specific tag appears to have come from the backend software, specifically
mw-removed-redirect
for being anEdits that change an existing redirect to a non-redirect
- which it was. — xaosflux Talk 14:13, 6 May 2020 (UTC)- Not sure what you were trying to do, but you probably shouldn't have made that edit at all - since those tags don't normally apply to redirects. If that was some sort of twinkle error - you will want to follow up with the twinkle maintainers still. — xaosflux Talk 14:20, 6 May 2020 (UTC)
- User:Xaosflux - I don't really remember what I was trying to do, since this was six months ago, but I would infer that I was trying to tag the article. I can't imagine why I would have tried to apply a tag to the redirect. What is the mechanism for reporting issues to Twinkle? Robert McClenon (talk) 14:36, 6 May 2020 (UTC)
- @Robert McClenon: Wikipedia:Twinkle#Quick_info has a "reporting bugs" section - but unless you can reproduce the problem now, it probably isn't worth chasing down 6 months later. — xaosflux Talk 14:48, 6 May 2020 (UTC)
- Robert McClenon, it'll be nigh impossible to pin down unless you remember exactly what happened, but my guess is that after you moved the draft to mainspace, you tagged the draft page without reloading it. That is, it was in your browser, possibly from the history tab or something where the content, unchanged since you moved it, so when that page and Twinkle were loaded it wasn't a redirect. I can look into making some additional checks, but it's generally a good idea when editing content to ensure you're editing the most recent version of the page. ~ Amory (u • t • c) 18:31, 6 May 2020 (UTC)
- User:Amorymeltzer - Yes, that is probably what happened. I accepted the draft, which does various things including moving it to mainspace, and invisibly creating a new page that is the redirect from draft space to article space. This is another lesson that I will try to keep in mind, which is that when moving a page or doing something that creates a page, be sure that you are where you think you are. Thank you. Robert McClenon (talk) 19:05, 6 May 2020 (UTC)
- Robert McClenon, it'll be nigh impossible to pin down unless you remember exactly what happened, but my guess is that after you moved the draft to mainspace, you tagged the draft page without reloading it. That is, it was in your browser, possibly from the history tab or something where the content, unchanged since you moved it, so when that page and Twinkle were loaded it wasn't a redirect. I can look into making some additional checks, but it's generally a good idea when editing content to ensure you're editing the most recent version of the page. ~ Amory (u • t • c) 18:31, 6 May 2020 (UTC)
- @Robert McClenon: Wikipedia:Twinkle#Quick_info has a "reporting bugs" section - but unless you can reproduce the problem now, it probably isn't worth chasing down 6 months later. — xaosflux Talk 14:48, 6 May 2020 (UTC)
- User:Xaosflux - I don't really remember what I was trying to do, since this was six months ago, but I would infer that I was trying to tag the article. I can't imagine why I would have tried to apply a tag to the redirect. What is the mechanism for reporting issues to Twinkle? Robert McClenon (talk) 14:36, 6 May 2020 (UTC)
- Not sure what you were trying to do, but you probably shouldn't have made that edit at all - since those tags don't normally apply to redirects. If that was some sort of twinkle error - you will want to follow up with the twinkle maintainers still. — xaosflux Talk 14:20, 6 May 2020 (UTC)
Hijacked?
Is the website in the infobox Very Long Baseline Array article hijacked? And is there a bot or something that can go around and fix that or something? Alanscottwalker (talk) 17:58, 6 May 2020 (UTC)
- @Alanscottwalker: The domain registration just expired afaics. No bot needed, just removed the site from the Wikidata entity. --qedk (t 愛 c) 18:04, 6 May 2020 (UTC)
- QEDK, I've re-added and corrected the official website claim on the Wikidata entry since the article had the updated version in its external links section. As for the bot...probably too much of a WP:CONTEXTBOT problem to be worthwhile. creffett (talk) 18:06, 6 May 2020 (UTC)
- @Creffett: updated it right after that. :) --qedk (t 愛 c) 18:06, 6 May 2020 (UTC)
Thanks. Alanscottwalker (talk) 18:46, 6 May 2020 (UTC)
Good article nominations
Apologies in advance if this has been sought previously but I'm looking for a bot or a script that will enable me to know how may GANs I have nominated and how many of them have been promoted to GA status. Any help would be great, thanks. The Rambling Man (Stay indoors, stay safe!!!!) 20:37, 6 May 2020 (UTC)
Phantom line breaks
I am having a hard time figuring out why there are a couple of line breaks at the bottom of The New American Poetry 1945–1960 (https://en.wikipedia.org/w/index.php?title=The_New_American_Poetry_1945%E2%80%931960&oldid=955271370). I figured it would be {{Schools of poetry}} having some stray line breaks in it but that's not it. (e.g. see the bottom of Dada, where it fits in nicely with navboxes above and below.) What am I missing here? How is this space here before the categories? Please {{ping}} me if you are smarter than I am and can figure out what's happening here. ―Justin (koavf)❤T☮C☺M☯ 22:05, 6 May 2020 (UTC)
- Fixed by removing a non-displayed character.[7] PrimeHunter (talk) 22:18, 6 May 2020 (UTC)
- PrimeHunter, What was this character? It's hard to search for it by its nature. How did you even find it? ―Justin (koavf)❤T☮C☺M☯ 22:48, 8 May 2020 (UTC)
- The right and left arrows in my Firefox often reveal there is something by not moving to the next visible character. I deleted it with backspace. Copy-paste to the "Characters" field at https://r12a.github.io/app-conversion/ and click "View in UniView" to see it's a thin space. PrimeHunter (talk) 23:20, 8 May 2020 (UTC)
- PrimeHunter, What was this character? It's hard to search for it by its nature. How did you even find it? ―Justin (koavf)❤T☮C☺M☯ 22:48, 8 May 2020 (UTC)
Color contrast
About a week ago, I was playing around with color contrast options on some "preference" page. I made a change, but it's too bright. I want to revert back to the default, but I can't locate the page where I had the options to change color contrast. Thanks for your help. --Rosiestep (talk) 05:56, 7 May 2020 (UTC)
- @Rosiestep: It sounds like a browser feature and not us. Does it happen if you log out? If so then try searching Google for
color contrast
and your browser name, or post to Wikipedia:Reference desk/Computing with the browser name. PrimeHunter (talk) 11:25, 7 May 2020 (UTC)- Thank you, @PrimeHunter:! You are right; it was on my MacBook Air. Resolved now. --Rosiestep (talk) 15:59, 7 May 2020 (UTC)
Template:Valid SVG links wrong URL
Hello!
{{Valid SVG}} (and {{Invalid SVG}}) links to the correct URL 9/10 times but sometimes the URL for some reason isn't rendered. For example at File:Fédération Internationale de l'Automobile (emblem).svg the template links to https://validator.w3.org/check?uri=http: when it should in fact link to https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/en/9/9a/Fédération_Internationale_de_l%27Automobile_%28emblem%29.svg . Can someone please fix this? The links are found by pressing "Valid" or "Invalid" in {{Valid SVG}} and {{Invalid SVG}} respectively. To find files with these templates see Category:Invalid SVGs and Category:Wikipedia images in SVG format.Jonteemil (talk) 05:57, 7 May 2020 (UTC)
- Hello Jonteemil. On first look, it seems like the links are broken if the file is hosted on Commons (such as the example above), and fine for those hosted locally. I will try to look into this, if no one else figures it out by then. Cheers, Rehman 06:08, 7 May 2020 (UTC)
- @Rehman: I think I found why... phab:T18474.Jonteemil (talk) 06:44, 7 May 2020 (UTC)
- Yes, makes sense. Rehman 06:59, 7 May 2020 (UTC)
- @Rehman: I followed instructions at mw:Help:Magic words#Page names: "One simple way to fix this is wrapping the pagename in
{{#titleparts:}}
from the ParserFunctions extension." so it's Done.Jonteemil (talk) 07:00, 7 May 2020 (UTC)
- @Rehman: I followed instructions at mw:Help:Magic words#Page names: "One simple way to fix this is wrapping the pagename in
- Yes, makes sense. Rehman 06:59, 7 May 2020 (UTC)
- @Rehman: I think I found why... phab:T18474.Jonteemil (talk) 06:44, 7 May 2020 (UTC)
List of articles in a wikiproject by size
How can I get a list of articles in a wikiproject sorted by size? something similar to already existing list of popular pages. Capankajsmilyo(Talk | Infobox assistance) 15:57, 7 May 2020 (UTC)
- WP:WikiProject Directory/All. --Izno (talk) 18:24, 7 May 2020 (UTC)
- I don't see where that lists articles by size. BD2412 T 18:40, 7 May 2020 (UTC)
- Perhaps User:MusikAnimal (WMF) or User:NKohli (WMF) could have the tech bot add the page size to that existing popular pages report? — xaosflux Talk 19:55, 7 May 2020 (UTC)
- @Xaosflux, Capankajsmilyo, and BD2412: While adding it to the popular pages report might be the most expedient solution, I think that's conflating two different things together. It seems to me that what's really needed here is a bot/template that can list all the pages of a given wikiproject (along with details like page creation date, size etc.). The popular pages list is capped at 500 or 1000 articles so it wouldn't give a complete list for a lot of wikiprojects. -- NKohli (WMF) (talk) 21:02, 7 May 2020 (UTC)
- I didn't interpret the request correctly, it appears. --Izno (talk) 22:22, 7 May 2020 (UTC)
- Perhaps User:MusikAnimal (WMF) or User:NKohli (WMF) could have the tech bot add the page size to that existing popular pages report? — xaosflux Talk 19:55, 7 May 2020 (UTC)
- I don't see where that lists articles by size. BD2412 T 18:40, 7 May 2020 (UTC)
- PetScan can output page bytes, and can sort output on size, so I think that'd cover it? ~ Amory (u • t • c) 21:15, 7 May 2020 (UTC)
- It seems set up to do that for articles in a category, but what about just a list of articles? BD2412 T 22:24, 7 May 2020 (UTC)
- (Hang on, I may have spoken too soon). BD2412 T 22:26, 7 May 2020 (UTC)
- So far all I'm getting is a 504 Gateway Time-out message. BD2412 T 22:39, 7 May 2020 (UTC)
- I've tried a bunch of routes of entry, and can't seem to get this to generate anything. BD2412 T 23:14, 7 May 2020 (UTC)
- The original request was for pages in a wikiproject, so pages in a category seems ideal? At any rate, the tool is down at the moment (at least for me?) so can't troubleshoot. ~ Amory (u • t • c) 10:00, 8 May 2020 (UTC)
- Special:PageAssessments can give you a list of articles in a WikiProject. Going by this data, you could write a query to get all of the articles sorted by size. For example quarry:query/44749, which lists members of WP:AMATEUR RADIO by size. Just fork that query and change the name accordingly (and refer to Special:PageAssessments if you're unsure you got the name right). — MusikAnimal talk 21:39, 8 May 2020 (UTC)
- The original request was for pages in a wikiproject, so pages in a category seems ideal? At any rate, the tool is down at the moment (at least for me?) so can't troubleshoot. ~ Amory (u • t • c) 10:00, 8 May 2020 (UTC)
reFill deadurl/url-status and a new userscript
It was suggested by MarnetteD to post this here.
in /backend/refill/formatters/citetemplate.py change template.add('deadurl', 'y')
to template.add('url-status', 'dead')
and find and replace "deadurl" with "url-status". In /backend/refill/models/citation.py change 'deadurl': bool,
to 'url-status': str,
.. probably. I literally looked at this for two minutes.
Unrelated but related, I herd U liek ciatations. So I made a userscript. It doesn't do everything reFill does (..YET), but some may find it helpful. It could be expanded later on. Add importScript('User:Alexis Jazz/FUC.js');
to your common.js to enable it. A new button will appear in the edit window near the "Watch this page" checkbox. As an example, clicking it and publishing the page results in these fixes. - Alexis Jazz 18:39, 7 May 2020 (UTC)
- Alexis Jazz, you might want to use something like User:BrandonXLF/Citoid (or you can do it yourself) for making more complete references, especially when the title isn't in the unfilled reference. – BrandonXLF (talk) 22:30, 7 May 2020 (UTC)
Can't get Audio file to Work
I can't get an audio file to work that's positioned right under the first photo under the header July 16 questioning in the wikipage titled 'Alexander Butterfield.'
I was using Firefox 64.0 (64-bit). SmileyTrek (talk) 17:59, 8 May 2020 (UTC)
- Fixed. Hiding the template entirely is an unpleasant failure mode. – Jonesey95 (talk) 18:06, 8 May 2020 (UTC)
Thank you very much. SmileyTrek (talk) 16:01, 9 May 2020 (UTC)